Justification
for
 ANSI Standard C12.19

1.	Standard Objectives
ANSI Standard C12.19 was developed by utilities, meter vendors, third party vendors and consultants with various objectives. Most of these objectives were voiced many times during the more than fifty days of meetings which produced the final document.  While cost related objectives were not voiced, it became clear that the standard had to support both the simplest and the most elaborate meter products. These objectives are not stated in the document but they were honored by the participants.  It is the honoring of those objectives and not the detailed technical decisions that produced the value found in the initial publication of  C12.19-1997.   

Utility objectives included:
•	Provide a single standard which permits a single set of software to configure, control, and read independently developed meters from all meter and recorder manufacturers..
•	Eliminate the need for maintaining separate meter test and programming systems for each manufacturer from whom the utility buys meters and recorders.
•	Reduce or eliminate the cost of incorporating new metering products into inventory. Including upgrades to third party software. 
•	Force the cost of basic metering functions to a low commodity level by means of standards.
•	Allow utilities to each customize the way they apply the same meter based on internal needs and practices.
•	Encourage continued innovation and technology advances by the manufacturers

Manufacturer objectives included:
•	Provide a standard which is practical and truly acceptable to the utilities.
•	Reduce the cost of having new products supported by third party software vendors and reduce the time to market.
•	Insure the ability to innovate and differentiate products from our competitors.
•	Prevent standards from limiting internal product design and innovation.
•	Allow scalability from the simplest kWh meter to the most complex.
•	Allow accelerated acceptance of new products by utilities.
•	Focus initial details on metering functionality which has been tested in the marketplace.

Consultant objectives included:
•	Provide a standard that embraces the latest and best in technologies.
•	Assure applicability to a broader range of meter product than those currently in the market.
•	Provide room for innovation by clients.

2.	
Standard Elements
The C12.19 tables standard effort is intended to provide functionally oriented, self defining data structures for metering type equipments.  The standard applies these parameters to expand and contract tables and to add or delete functional features. For example,  table 22 (current register data) may range in size from 3 bytes to over 17 Megabytes. Note that for currently available very complex meters the maximum size for table 22 is on the order of 500 - 800 bytes.

Protocols today provide information transport services in a variety of forms. The C12.19 effort decided very early to minimize the required information services and settled on two. These services are READ and WRITE of data groupings known as “tables.” Even control actions were covered by defining a special “procedure table.” A WRITE to the procedure table would result in execution of the process or procedure specified in data written to that table. 

In order to allow user interpretation of differences in manufacturer design decisions, a second special table was defined. This configuration table indicates in simple, compact form what data structures are available for use and what the basic rules for interpretation are.  This table, often referred to as simply “table zero,” paved the way for rapid resolution of manufacturer biases that could have otherwise wrecked the process.
Four general types of tables were defined;  standard, manufacturer, pending, and user tables.

2.1	Standard Tables
Standard tables are tables whose detailed structure is defined within the C12.19 document.  Standard tables are divided into functional sets or “decades”.  The special tables noted above are defined in the first decade. The special table that implements procedures is table number 7. The procedures are similarly distinguishable into standard and manufacturer procedures.

2.1.1	Standard Procedures
Standard procedures are those procedures defined within the C12.19 document.  These serve as the basis for control type direction of the meter.  An example of a simple standard procedure is “demand reset”. Some procedures may be augmented with data. An example of a standard procedure with data is “set time” where the data is the new value for time.

2.1.2	Manufacturer Procedures
Manufacturer procedures are procedures defined by each manufacturer.  The structure of these procedures are identical to standard procedures, however, the procedure codes, action taken, and any accompanying data is defined by each manufacturer.  As with manufacturer tables, these procedures are used to introduce innovations,  provide functions not yet included in C12.19, or maintain proprietary processes.
   
2.2	Manufacturer Tables
Manufacturer Tables are tables whose structure is defined by individual manufacturers.  There are no rules restricting definition of these tables.  These tables can be described in C12.19 Syntax and thus still be exercised by the same software which supports the standard defined tables. The intent is for these tables to be used by manufacturers to introduce innovations and or protect proprietary data structures.

2.3	Pending Tables
Pending Tables are inactive standard and/or manufacturer tables whose contents are to replace the contents of their active counterpart upon occurrence of a specified event.

2.4	User Tables
User Tables are a subset of standard tables (in decade 80) whose contents can be controlled by the utility or other user.  These tables allow meter use differentiation between utilities.

3.	Table Description Syntax
Early in the C12.19 effort it was decided to establish a rigid syntax for describing the data structures for the tables to minimize misunderstandings.  This syntax was loosely based on the programming language PASCAL. The syntax includes conditionals which add or delete structures. 
As a cross-check on the table definitions one of the participants developed an interpreter for the C12.19 syntax.  Between standards meetings the table descriptions in the most recent draft document would be “tested” and the results were used to evaluate the accuracy of the document. What evolved was a robust syntax or “language” for describing metering type data structures. 
The interpreter itself grew to be include the ability to assemble and disassemble data blocks using the C12.19 syntax. Finally, transport protocol support was added to the interpreter/parser and a test tool for C12 protocol based products was born.   
Individual participants in the standards process simultaneously discovered that they could use the same syntax to describe data structures in existing products.  This means that manufacturer’s tables can be described using the same syntax and the parser used to interpret or generate the meter data. 

4.	Achieving Interoperability for Dissimilar Meters
Interoperability for dissimilar meters is achieved using software based on the paradigm of  this parser based tool.  This single software tool has been used successfully to-date by every manufacturer known to have worked on C12.19 compatible meters.  These implementations included both standard and manufacturer tables and procedures.   At least two other software packages have been developed using the same principals and have each successfully supported meters from multiple manufacturers.  
Multiple examples of the strength of the process exist. In one, ABB received a software module from a subcontractor for adding a new functionality to a meter product.  The subcontractor had no knowledge of C12.19 and had generated the supporting data structures independently. Upon receipt of the software module, the firmware engineer: 
a)	loaded the firmware into the meter, 
b)	re-wrote the accompanying data structure description into the C12.19 syntax as manufacturer’s tables,  and 
c)	added an ACSII file to the PC containing the software tool.  
Within an hour after receipt of the firmware module,  the engineer was using the tool to read and write the new data structures. 
5.	Conclusions
ABB has reviewed the published standard in detail.  There are a few  typo errors in the standard (including one on the front cover).  The errors are not significant.  The allowance of manufacturer defined tables and procedures prevents even any substantive error which may be found in the document from having a significant impact on interoperability.  The only manufacturer who has stated that his data structures cannot be represented in C12.19 has now seen those data structures described in C12.19 syntax as a manufacturer’s table.  These facts indicate that manufacturer tables, described in C12.19 syntax, may be the most important key to achieving interoperability in the metering industry.  It is apparently fear of the un-investigated and not the C12.19 standard that is the current blocking agent.  
ABB therefore concludes that acceptance of C12.19 in a timely manner is imperative for the achievement of interoperability in the deregulated environment of California.  This period should be 2 years following the publication (public availability) of the standard, to allow manufacturer’s who were not active participants in the standards process ample time to comply.

The following table provides a list of standards for the MC Subgroup’s discussions on 4/28/98:  

Table 1:  List of Standards
Standards | Applicable for DA? | Required in CPUC’s D97-12-048 | Proposed Requirements | Recommended effective date | Comments

ANSI C12.19-1997, Utility Industry End Device Data Table
(BOX #3)

Yes

No

Conditional “yes” as noted in Comments column

March 20, 2000 (Two years following date of publication. Published by IEEE on March 20, 1998 )

Applied to all new meter types seeking approval following the effective date. Solid state meters are currently sold and installed in California will be grandfathered and not required to comply with ANSI C12.19. In addition all meters accepted in the state prior to the effective date will also be grandfathered.

ANSI C12.21, Protocol Specification for Telephone Modem (not approved)
(BOX #1)

Yes

No

No

NA

Applied to telephone modem only.

ANSI C12.22, Meter Interface to Network Protocol Gateway (not approved)
(BOX #1)

Yes

No

No

NA

Applied to network only.