UNLIMITED FREE
ACCESS
TO THE WORLD'S BEST IDEAS

SUBMIT
Already a GlobalSpec user? Log in.

This is embarrasing...

An error occurred while processing the form. Please try again in a few minutes.

Customize Your GlobalSpec Experience

Finish!
Privacy Policy

This is embarrasing...

An error occurred while processing the form. Please try again in a few minutes.

NEMA - ANSI C12.22

Protocol Specification for Interfacing to Data Communication Networks

active, Most Current
Buy Now
Organization: NEMA
Publication Date: 1 January 2012
Status: active
Page Count: 216
scope:

Initially, communications with electronic devices consisted of transporting memory data via proprietary protocols that were unique to each manufacturer. The desire for interoperability and support for multiple manufacturers by reading and programming systems created a need for standardization of data formats and transport protocols.

The first step was to standardize data formats. Internal data was abstracted as a set of Tables. A set of standard Table contents and formats were defined in ANSI C12.19/MC12.19/IEEE 1377, "Utility Industry 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 protocol was developed to transport table data over an optical connection. The ANSI C12.18/ MC12.18/IEEE 1701 protocol include an application language called Protocol Specification for Electric Metering (PSEM) that allows applications to read and write Tables. The "Protocol Specification for Telephone Modem Communication" (ANSI C12.21/MC12.18/IEEE 1702) was then developed to allow devices to use PSEM to transport Tables over telephone modems.

This Standard extends the concepts of ANSI C12.18/MC12.18/IEEE 1701, ANSI C12.21/MC12.18/IEEE 1702, and ANSI C12.19/MC12.19/ IEEE 1377 Standards to allow transport of Table data over any reliable networking communications system. Note that in this use of the word, "reliable" means that for every message sent, the sender receives a response at its option: either a positive acknowledgment or an error message. That is, messages cannot fail silently in a reliable network (see discussion of Reliable Stream Transport Service in IPPA [B1]).2

In addition, this Standard describes an optionally exposed point-to-point interface between a C12.22 Device and a C12.22 Communications Module designed to attach to "any" network. The terms "C12.22 XXXX" (e.g., C12.22 Device) were introduced by ANSI C12.22-2008. These terms can be interchangeably replaced with the terms "IEEE 1703 XXXX"; i.e., the IEEE 1703 Device is the same as the ANSI C12.22 Device and the IEEE 1703 Communication Module is the same as the C12.22 Communication Module. However, since this Standard was originally developed under the auspice of ANSI C12 SC17 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 (ANSI C12.19 Devices) and network protocols.

Specific goals identified by the committee in the creation of this Standard were:

a) Defining a Datagram that can convey ANSI C12.19 data Tables through any network

This was accomplished by:

- Assuming that the data source is ANSI C12.19 data Tables

- Defining the Application Layer services (language)

b) Providing a full stack [ISO/IEC 7498-1] definition for interfacing a C12.22 Device to a C12.22 Communication Module

This was accomplished by:

- Defining the physical interface requirements between the C12.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-point communication to be used over local ports such as optical ports or modems

This was accomplished by defining a Layer 4 (transport) and Layer 2 (data link)

d) Providing support for efficient one-way messaging (blurts)

This was accomplished by:

- Defining a compact message format that can be easily transformed into a standard ANSI C12.22 Datagram

- Assuring that all needed layers defined in this standard can support 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 was accomplished by:

- Defining different types of nodes such as C12.22 Relay, C12.22 Master Relay, C12.22 Host, C12.22 Authentication Host, C12.22 Notification Host, and C12.22 Gateway

- Defining the roles and responsibilities of each of these C12.22 Nodes

f) Providing data structure definitions in support of this protocol

This was accomplished by:

- Defining an ANSI C12.19 Decade to be used by C12.22 Nodes

- Defining an ANSI C12.19 Decade to be used by C12.22 Relays

- Defining new procedures in support of this protocol

- Defining a new Table for enhanced security

1 Information on references can be found in clause 2.

2 Numbers in brackets correspond to those of the bibliography in Annex K.

Document History

ANSI C12.22
January 1, 2012
Protocol Specification for Interfacing to Data Communication Networks
Initially, communications with electronic devices consisted of transporting memory data via proprietary protocols that were unique to each manufacturer. The desire for interoperability and support...
January 1, 2012
Protocol Specification for Interfacing to Data Communication Networks
Initially, communications with electronic devices consisted of transporting memory data via proprietary protocols that were unique to each manufacturer. The desire for interoperability and support...
January 1, 2008
Protocol Specification For Interfacing to Data Communication Networks
The NEMA Smart Meter Package provides the requirements and guidance on electricity metering, watt hour meter sockets, device data tables, meter interfacing to data communication networks and type 2...

References

Advertisement