What To Look for When Selecting ANSI Protocol Meters

By Ted York

Click here to enlarge image

As the industry settles into the new ANSI metering standards and major metering manufacturers develop and introduce ANSI Protocol Meters (APMs), it is important to know how to select the optimum ANSI-compliant metering solution. APMs use ANSI metering standards C12.18, C12.19 and C12.21 (Table 1). ANSI standards C12.18 and C12.21 define communications protocols that provide an open standard for optical port and telephone communications. ANSI C12.19 forms the basis for common industry data structures and provides a common industry “vocabulary” for meter data communications.

Click here to enlarge image

APMs allow users to reach new levels in flexible metering capability. The open meter designs and common support software promise increased efficiency in meter operations, but all APMs are not created equal. While current APM designs are based on the same ANSI standards, inclusion of some protocol services in ANSI C12.18 and most data structures or “tables” in ANSI C12.19 are optional. Meter manufacturers will each select which portions of these standards to support, which portions to replace and which standards to extend. Before purchasing, the user should review each meter’s application of the standards.

Realizing APM designs would vary, the Association of Edison Illuminating Companies (AEIC) examined the standards and published a guideline (AEIC Guidelines for Implementation of ANSI C12.19-1997), which is available at www.aeic.org/meter_service. A simpler approach is to adopt a policy that states, “If an ANSI C12 protocol standard covers a function implemented in the meter, the meter should perform the function in the standard way.”

General Guidelines

Click here to enlarge image

At the heart of the ANSI C12.19 standard is a set of defined standard tables and procedures. Collected metering data and control parameters are stored in the tables while procedures provide a method of invoking actions in the meter, such as resetting the demand. In general, the more dependent the ANSI meter design is on standard tables and standard procedures, the more universal the meter becomes in application (Table 2). The functional structures defined within the ANSI standards are similar in efficiency to but much more powerful than equivalent functions found in meters that employ proprietary communications protocols. However, there are pitfalls to avoid.

Avoiding Potential Problems

Users should avoid or very carefully evaluate “almost implementations” where standard tables, procedures or protocol services are partially implemented with non-standard tweaks to standard features. These implementations can cause confusion and make it difficult or impossible to use common software to communicate with multiple meter products. If standard tables or procedures are used in a meter, they should either follow the standard or be re-defined as manufacturer-specific structures. Non-standard protocol services should be totally avoided (Table 2). They will cause more problems for the user than they are worth.

Though the standards were given much thought and review during development, it is generally agreed that standard tables 10 through 16 in ANSI Standard C12.19 leave a lot to be desired. These tables control the definition of measurement sources within the meter. Utilities and manufacturers in both the United States and Canada have called for improvements. The problems center on standard table 16, which forces other tables in this area to be much larger than necessary. Users will be better off with a meter that does not try to use all of these tables, but instead replaces one or more of them with manufacturer-designed tables. A good start would be a manufacturer’s substitute for table 16, designed to reduce the required size of standard tables 12 through 15.

Insist on EDL Files

Each meter delivery should be accompanied (or preceded) by an End Device Language (EDL) text file that fully describes every user-accessible table and procedure (Table 2). EDL is the C12.19 syntax used to describe tables and procedures in the meter. If dissimilar meters are present in a shipment, there should be a file covering each style of meter in the shipment. These files should include both standard and manufacturer-defined tables and procedures. By providing a definition of how each meter is organized and how it talks to the outside world, EDL files maximize the opportunity to use a single software package to read and routinely program all ANSI meters purchased.

It is expected that manufacturers will keep selected tables and procedures proprietary for handling such issues as functionality upgrades or manufacturing tests. These processes are normally performed by the manufacturer’s own software. It is fine if this information is not included in the EDL file, but it is also important that the user be able to perform routine reprogramming and data retrieval without access to the data structures omitted from the EDL file.

Even if the user initially plans to use manufacturer-provided software to read and program the meters, verified EDL files are crucial to opening the metering business to increased productivity.

Prior to any volume delivery, the user should evaluate a sample of each new meter style and its applicable EDL file together using TstBench (Table 2). TstBench, developed by NERTEC (www.nertec.com), is test software that interprets EDL files and uses them to read and write information in ANSI meters. Most APM developers use or have used TstBench as a development or test tool.

Look For Product Flexibility

A major strength of the standard tables is the capability to expand and collapse data tables in a meter, based on user-set configuration parameters (Table 2). Collapsing tables can eliminate the transfer of unused or un-interesting data fields, speeding up the data retrieval process. It is reasonable to accept a minimal function, consumption-only meter with a very rigid data table structure. Most meters however, should support the dynamic re-sizing of internal data tables in accordance with the user’s specified configuration parameters. This feature can save substantial time and communications costs when reading or re-programming a large number of meters.

The ANSI standards also allow for increased value ranges for some common variables (Table 2). Examples include traditional meter variables like demand interval length, time-of-use (TOU) seasons and rate tiers. The C12.19 standard supports demand intervals as short as one minute and as long as 45 days. Historically, ANSI meter manufacturers have supported a maximum of four seasons (spring, summer, fall and winter), but C12.19 defines a data structure that supports up to 15 seasons. Thus the traditional season parameter now can be used to divide the rate year into smaller segments, such as a different set of TOU switch times for each month. Likewise, while most domestic TOU rate structures still use only two or three rates (on-peak, off-peak and shoulder), C12.19 permits up to eight rates, which is consistent with some international requirements. While the need for some of the extended ranges is still questionable, some users may favor meters that support higher limits on these variables. As discussed above, in most cases, the meter also should permit the appropriate data tables to be collapsed when these extended values are not needed.

Important Features to Consider

The desired features depend on the type of meter involved. All the flexibility of a complex meter is not needed on a simple meter. However, use of ANSI protocols even in simple meters still presents advantages over proprietary designs (Table 2). Some of the most desirable features include:

  • Billing Data. Collection of billing or tariff data is always important, so presenting that data in a standard format adds to the value of any meter. Even more valuable is the ability to change the parameters that control what billing data is collected, using standardized data structures. As complexity increases, the meter also should maximize the ways it can make snapshots of the collected billing data at desired times. For these reasons, it is suggested that the meter support most of the standard tables defined in C12.19 where the common billing data can be stored.
  • Present Values. While the standard supports a “present value” table, the need for this information should be evaluated on a user-by-user basis. The value of this table could improve if the manufacturer includes instrumentation measurements for quick retrieval.
  • Interval Data Recording. The C12.19 standard adds consistency and substantial value to interval data recording. While interval data recording is normally an option, it is recommended that any meter providing this capability use the tables and formats defined in the standard. The optimum APM would support most of the standard tables for this function, including the ability to support optional multiple data sets. The use of extended interval status is also encouraged since it eliminates the need to externally correlate interval data with an event log.

  • Security Considerations. Deregulation increases the number of agencies that require access to data within the meter. There is a need to increase data access flexibility, which makes use of the security scheme defined in the ANSI protocols highly desirable. Especially needed are the non-hierarchical password schemes, which ANSI C12.19 allows. The user should look for a broad capability to define and modify both passwords and access definitions. In addition, the manufacturer needs to assure that the user cannot permanently lock himself out of the meter by applying a faulty security scheme. If authentication or encryption is used, itshould also conform to the C12 standards.
  • User-Defined Tables. The time it takes to retrieve data from a meter can be very costly. APMs that support user-defined tables (UDTs) allow the user to shorten the time required to read a meter. UDTs let the user define customized tables made up of pieces of other tables in the meter. For example, if standard tables 23, 3, and 55 (current tariff data, meter status and time state) are normally read, a single UDT that is a combination of all or part of each of these tables could be defined instead. Then a meter reading system can request all of the desired data from a single table rather than making three requests. The key is that the user must be able to define these tables.

  • Logging. Two standard log types are defined in the ANSI standard: event and history. These logs are structurally identical. Two general applications were envisioned. One was a log that monitors internal actions or “events” detected within the meter. The standard includes an excellent list of events to be logged. The other application was a log to track communication-based activity, such as changes in configuration or procedure execution. This second log application is of special interest in the Canadian market, but can benefit any user. Either log may be configured to support either of these applications or a mix of the two roles. While the manufacturer may inlude other logs in the meter, a good design should start by including these two. As with other functions, it is important that the user be able to select what is actively logged.
  • Power Quality Monitoring. Power quality (PQ) monitoring functionality was not mature enough to be included when the ANSI communications standards were published. A good design should include the manufacturer’s own power quality monitoring solution. The recommended activity should at least include the ability to check the service wiring and provide notification of out-of-range conditions. If possible, the power quality measurements should be available as sources for interval data recording. Until the standard includes power quality processes, the meter should still include those processes in forms at least partially programmable through manufacturer-supplied or EDL based third party software.


With multiple meter manufacturers now providing ANSI protocol meters and the capabilities of these products improving, it is time for the industry to move to APMs. This should accelerate the eventual exclusion of proprietary technology meters. As this transition occurs, more software tools to fully support APMs will become available. To take advantage of this next paradigm shift in metering, the suppliers and potential users of this technology must focus on the acquisition of metering products that provide the most benefits. Purchasing based on thoughtful APM evaluations will serve as strong feedback to all meter manufacturers. The net effect will be to encourage development of new metering products that further increase operational productivity. The prospect of a win-win for the entire metering industry is now in sight.

Ted York has 36 years experience designing data collection systems and products, including 27 years in the metering industry with ABB and Westinghouse.


Previous articleELP Volume 79 Issue 1
Next articleGas suppliers refusing sales, Pacific Gas & Electric says

No posts to display