Initially, communications with electronic devices consisted oftransporting memory data via proprietary protocols that were uniqueto each manufacturer. The desire for interoperability and supportfor multiple manufacturers by reading and programming systemscreated a need for standardization of data formats and transportprotocols.
The first step was to standardize data formats. Internal datawas abstracted as a set of Tables. A set of standard Table contentsand formats were defined in ANSI C12.19/MC12.19/IEEE 1377, "UtilityIndustry End Device Data Tables."1
In the "Protocol Specification for ANSI Type 2 Optical Port"Standard (ANSI C12.18/MC12.18/IEEE 1701), a point-to-point protocolwas developed to transport table data over an optical connection.The ANSI C12.18/ MC12.18/IEEE 1701 protocol include an applicationlanguage called Protocol Specification for Electric Metering (PSEM)that allows applications to read and write Tables. The "ProtocolSpecification for Telephone Modem Communication" (ANSIC12.21/MC12.18/IEEE 1702) was then developed to allow devices touse PSEM to transport Tables over telephone modems.
This standard extends the concepts of ANSI C12.18/MC12.18/IEEE1701, ANSI C12.21/MC12.18/IEEE 1702, and ANSI C12.19/MC12.19/ IEEE1377 standards to allow transport of Table data over any reliablenetworking communications system. Note that in this use of theword, "reliable" means that for every message sent, the senderreceives a response at its option: either a positive acknowledgmentor an error message. That is, messages cannot fail silently in areliable network (see discussion of Reliable Stream TransportService in IPPA [B1]).2
In addition, this standard describes an optionally exposedpoint-to-point interface between a C12.22 Device and a C12.22Communications Module designed to attach to "any" network. Theterms "C12.22 XXXX" (e.g., C12.22 Device) were introduced by ANSIC12.22-2008. These terms can be interchangeably replaced with theterms "IEEE 1703 XXXX"; i.e., the IEEE 1703 Device is the same asthe ANSI C12.22 Device and the IEEE 1703 Communication Module isthe same as the C12.22 Communication Module. However, since thisstandard was originally developed under the auspice of ANSI C12SC17 WG1, the document terminology is based on C12.22 terms.
Furthermore, this standard defines a methodology to capture,translate, and transmit one-way device messages (blurts).
This standard defines interfaces between IEEE 1377 Devices (ANSIC12.19 Devices) and network protocols.
Specific goals identified by the committee in the creation ofthis standard were:
a) Defining a Datagram that can convey ANSI C12.19 data Tablesthrough any network
This was accomplished by:
â€” Assuming that the data source is ANSI C12.19 dataTables
â€” Defining the Application Layer services (language)
b) Providing a full stack [ISO/IEC 7498-1] definition forinterfacing a C12.22 Device to a C12.22 Communication Module
This was accomplished by:
â€” Defining the physical interface requirements between theC12.22 Device and the C12.22 Communication Module
â€” Defining the interface lower layers [ISO/IEC 7498-1]: 4(transport), 3 (network), 2 (data link), and 1 (physical)
c) Providing a full stack definition for point-to-pointcommunication to be used over local ports such as optical ports ormodems
This was accomplished by defining a Layer 4 (transport) andLayer 2 (data link)
d) Providing support for efficient one-way messaging(blurts)
This was accomplished by:
â€” Defining a compact message format that can be easilytransformed into a standard ANSI C12.22 Datagram
Assuring that all needed layers defined in this standard cansupport one-way messaging
e) Providing network architecture compatible with this protocol(some architectural concepts were derived from HCCS 1 [B5], HCCS 2[B6], HCCS 3 [B7], DND [B4], IPPA [B1], and TCPCE [B2]) This wasaccomplished by:
â€” Defining different types of nodes such as C12.22 Relay, C12.22Master Relay, C12.22 Host, C12.22 Authentication Host, C12.22Notification Host, and C12.22 Gateway
â€” Defining the roles and responsibilities of each of theseC12.22 Nodes
f) Providing data structure definitions in support of thisprotocol This was accomplished by:
â€” Defining an ANSI C12.19 Decade to be used by C12.22Nodes
â€” Defining an ANSI C12.19 Decade to be used by C12.22Relays
â€” Defining new procedures in support of this protocol
â€” Defining a new Table for enhanced security
The Utility Industry has a need for a standard that provides anoperable "plug-and-play" environment for field devices (e.g.,meters, communication modules, and Utility systems). The purpose ofthis standard is to define the network framework and means totransport the Utility End Device Data Tables via any Local-area /Wide-area network for use by enterprise systems in a multi-sourceenvironment.
This standard is intended to accommodate the concept of anadvanced metering infrastructure such as that identified by theOffice of Electricity Delivery and Energy Reliability of the U.S.Department of Energy; the Smart Metering Initiative of the OntarioMinistry of Energy (Canada); and the stated requirements ofMeasurement Canada for the approval of a metering device for use inCanada.
1 Information on references can be found in clause2.
2 Numbers in brackets correspond to those of thebibliography in Annex K.
- Product Code: NEMA
- Availability: In Stock