ANSI-C1218

ANSI C12.18-2005

AMERICAN NATIONAL STANDARD PROTOCOL SPECIFICATION FOR ANSI TYPE 2 OPTICAL PORT

Accredited Standard Committee on Electricity Metering, C12 Accredited by American National Standards Institute Approved May 2, 2006

ANSI C12.18 – 2005 American National Standards Institute, Inc. Approval of an American National Standard requires verification by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effort be made toward their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in the name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the American National Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute.

Published by National Electrical Manufacturers Association 1300 N. 17th Street, Rosslyn, Virginia 22209 Copyright © 2005 National Electrical Manufacturers Association All rights including translation into other languages, reserved under the Universal Copyright Convention, the Berne Convention for the Protection of Literary and Artistic Works, and the International and Pan American Copyright Conventions. No part of this publication may be reproduced in any

i

ANSI C12.18 – 2005 form, in an electronic retrieval system or otherwise, without prior written permission of the publisher. Printed in the United States of America

ii

ANSI C12.18 – 2005 TABLE OF CONTENTS 1.

SCOPE................................................................................................................................. 1

2.

REFERENCES ................................................................................................................... 1

3.

DEFINITIONS AND SYNTAX .......................................................................................... 1 3.1. DEFINITIONS....................................................................................................................... 1 3.1.1. C12.18 Client ............................................................................................................ 1 3.1.2. C12.18 Device .......................................................................................................... 1 3.1.3. Point-to-point Communications.............................................................................. 2 3.1.4. Table........................................................................................................................... 2 3.2. DOCUMENT SYNTAX ....................................................................................................... 2

4.

PROTOCOL DETAILS...................................................................................................... 3 4.1. ORDER OF TRANSMISSION ............................................................................................. 3 4.2. LAYER 7—APPLICATION LAYER ..................................................................................... 4 4.2.1. Data Structure........................................................................................................... 4 4.2.2. Protocol Specifications for Electric Metering (PSEM) ........................................ 4 4.3. LAYER 6—PRESENTATION LAYER ............................................................................... 21 4.4. LAYER 5—SESSION LAYER.......................................................................................... 21 4.5. LAYER 4—TRANSPORT LAYER .................................................................................... 22 4.6. LAYER 3—NETWORK LAYER ....................................................................................... 22 4.7. LAYER 2—DATA LINK LAYER ....................................................................................... 22 4.7.1. Basic Data ............................................................................................................... 22 4.7.2. Packet ...................................................................................................................... 23 4.7.3. Duplicate packets ................................................................................................... 24 4.7.4. CRC selection ......................................................................................................... 25 4.7.5. Acknowledgment .................................................................................................... 25 4.7.6. Retransmission ....................................................................................................... 25 4.7.7. Time-out................................................................................................................... 25 4.7.8. Delays ...................................................................................................................... 26 4.8. LAYER-1—PHYSICAL LAYER........................................................................................ 27 4.8.1. Physical.................................................................................................................... 27 4.8.2. Basic Data ............................................................................................................... 28 4.8.3. Light Levels ............................................................................................................. 28

5.

COMPLIANCE.................................................................................................................. 30

ANNEX A - COMMUNICATION EXAMPLE (LAYER 7 AND LAYER 2) ......................... 32 ANNEX B - PACKET TRANSMISSION EXAMPLE ............................................................ 34 ANNEX C - SERVICE SEQUENCE STATE CONTROL..................................................... 36 ANNEX D - COMPATIBILITY.................................................................................................. 39 D.1 BACKWARD COMPATIBILITY WITH PREVIOUS VERSIONS OF THE STANDARD................... 39 D.2 FORWARD COMPATIBILITY WITH NEXT VERSIONS OF THE STANDARD ............................ 39 ANNEX E - HISTORICAL BACKGROUND .......................................................................... 41

iii

ANSI C12.18 – 2005 E.1 FOREWORD OF C12.18-1996 AND C12.18-1996 (R2002).......................................... 41

iv

ANSI C12.18 – 2005 Foreword (This foreword is not part of American National Standard for Protocol Specification for ANSI Type 2 Optical Port, ANSI C12.18-2005.) This American National Standard provides an open-platform communications protocol for twoway communication with a metering device through an ANSI Type 2 Optical Port. The protocol is written to conform to the OSI seven-layer stack. Long-time readers of ANSI C12.18 will discover many editing changes to this version of the Standard. The Working Group chose to improve the clarity of the text as an aid to the reader while retaining the Normative elements in the manner of previous publications. The 2005 revision of this Standard was considered in the context of the so-called “protocol suite” of ANSI standards: C12.18, C12.19, C12.21 and C12.22 (draft). Changes made were included only after assuring that existing devices implementing C12.18 would continue to remain compatible with the 2005 revision. This revision has corrected an error in the original standard: the impossibility of using indexcount for table access. Other concepts addressed include compliance, backward and forward compatibility, the use of reserved fields, the Identification Service, packet size and the toggle bit. Finally, some alignment with the draft C12.22 standard was performed to meet the goal of producing a coherent suite of protocol standards. Suggestions for improvement to this Standard are welcome. They should be sent to: National Electrical Manufacturers Association Vice President of Engineering 1300 North 17th Street Suite 1847 Rosslyn, VA 22209 This Standard was processed and approved for submittal to ANSI by Accredited Standards Committee for Electricity Metering C12. At the time the committee approved this Standard, the C12 Committee had the following members: Tom Nelson, Chairman Paul Orr, Secretary Michael Anderson Ed Beroset Ron Breschini Curt Crittenden David Ellis Cruz Gomez Bob Hughes

v

ANSI C12.18 – 2005 Lawrence Kotewa Francis Marta John McEvoy Herman Millican James Mining Avygdor Moise Tim Morgan Roy Moxley D. Young Nguyen Lauren Pananen Aaron Snyder Richard Tucker Scott Weikel Working Group 4 of Subcommittee 17 that developed the Standard consisted of: Aaron Snyder, Chairman Peter Martin, Vice Chairman Norbert Balko, Editor Michael Anderson Ed Beroset Martin Burns Janice Jennings Lawrence Kotewa Robert McMichael Avygdor Moise Vuong Nguyen Terry Penn Bin Qiu Richard Tucker Michel Veillette Virginia Zinkowski

vi

ANSI C12.18 – 2005

Protocol Specification for ANSI Type 2 Optical Port 1. Scope This Standard details the criteria required for communications between a C12.18 Device and a C12.18 Client via an optical port. The C12.18 Client may be a handheld reader, a portable computer, a master station system or some other electronic communications device. This Standard provides details for a complete implementation of an OSI 7-layer model. The protocol specified in this document was designed to transport data in Table format. The Table definitions are in ANSI C12.19 Utility Industry End Device Data Tables. 2. References ANSI C12.19, Utility Industry End Device Data Tables ANSI C12.21, Protocol Specification for Telephone Modem Communication ISO/IEC 646 (1991), Information Technology - ISO 7-Bit Coded Character Set For Information Interchange ISO/IEC 7498-1 (1994), Information Technology - Open Systems Interconnection - Basic Reference Model: The Basic Model ISO/IEC 8825-1 (2002), Information Technology - ASN.1 Encoding Rules: Specification Of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) And Distinguished Encoding Rules (DER) ISO/IEC 13239 (2002), Information Technology - Telecommunications And Information Exchange Between Systems - High-Level Data Link Control (HDLC) Procedures 3. Definitions and Syntax 3.1.

Definitions

For the purposes of this Standard, the following definitions are made: 3.1.1. C12.18 Client

An electronic communication apparatus that attaches to the ANSI Type 2 Optical Port of a C12.18 Device and implements communication according to the protocol specification of this Standard. 3.1.2. C12.18 Device

1

ANSI C12.18 – 2005 An electronic communication apparatus that implements an ANSI Type 2 Optical Port for communication according to the protocol specification of this Standard. 3.1.3. Point-to-point Communications

Point-to-point communications is defined as communication between two devices through a single optical interface. 3.1.4. Table

Functionally related data elements, grouped together into a single data structure for transport as defined by ANSI C12.19. 3.2.

Document Syntax

Describing data definitions is usually accomplished within the confines of a given language and the grammar rules of that language. Since the data definitions embodied within this Standard are meant to be independent of specific language and, hopefully, capable of being implemented within the confines of any language, a method for describing the data definitions must be developed. A modified form of the Backus-Naur Form (BNF) will serve as the basis for building the descriptions used to construct the data definitions. The modified form of BNF has the following definitions: Symbol

Meaning

<>

A string contained inside angle brackets is called a non-terminal. That is, while it may be viewed as a single unit, it can and should be redefined as consisting of one (1) or more simpler elements.

::=

This symbol is read as “is defined as.” The non-terminal which occurs on the left hand side (LHS) of this symbol consists of the elements (non-terminals, terminals, or a combination of the two) found on the right hand side (RHS). A line containing an LHS, ::=, and an RHS is known as a production rule.

|

The vertical bar is an “OR” symbol. The OR symbol always occurs on the right hand side of a production where the left hand side can be defined in more than one way. The OR bar separates valid alternative right hand sides.

[]

A symbol enclosed in square brackets is optional. The production is valid whether or not it is included.

*

The superscript asterisk is known as the Kleene star. A symbol followed by the Kleene star may occur zero (0) or more times without violating the grammar.

+

The superscript plus sign is known as the Kleene cross. A symbol followed by the Kleene cross must occur one (1) or more times.

2

ANSI C12.18 – 2005

+n

A symbol followed by the Kleene cross and any number “n” represents “n” occurrences of the symbol.

{}

The curly braces are used to enclose comments within the descriptions. Comments have no impact on the productions.

4. Protocol Details Following the guidelines established by the OSI seven-layer model, the protocol described in this Standard provides three (3) functions: 1) Establishment and modification of the communication channel 2) Transport of information to and from the C12.18 Device 3) Orderly closure of the communication channel when communications are complete Three (3) layers are used to provide these communication capabilities. These are the Physical, Data Link and Application layers. With the default conditions established by this Standard, the communication channel is considered always available once the physical connection has been completed. The required Identification Service is used to obtain the protocol version and revision in use by the C12.18 Device. Certain communication parameters may be modified through the use of the Negotiate Service in the Application Layer. The Negotiate Service is optional and, if not implemented in the C12.18 Device or not used during actual communications, the communication channel parameters shall remain at the default settings specified by this Standard. Device implementers are strongly encouraged to implement this service. Once the C12.18 Device identification and communication parameters have been established, the Application Layer provides Logon, Security and Logoff services for session activation, access control and deactivation, Read and Write services for issuing data transmission requests, a Terminate service for shutdown of the communication channel, and a response structure that provides information regarding the success or failure of the service requests. An example of a typical communications session would consist of the following services with appropriate responses, in the order listed: Identification, Negotiate, Logon, Security, Reads or Writes, Logoff and Terminate. Note that this brief example does not detail the packet structure or other aspects of the protocol. Annex and Annex B contain examples with more detail. 4.1.

Order of Transmission

Within the syntax definitions, multiple parameters shall be transmitted in the order as shown, from left to right.

3

ANSI C12.18 – 2005 Service parameters in all layers within the protocol definition are transmitted most significant byte first. The order of transmission of data field parameters within Tables is dictated by the Table structure. Bytes are transmitted in frames. Each frame consists of a start bit, followed by , and ending with a stop bit. The start bit is transmitted first. Bits within each byte are transmitted least significant bit first.

4.2.

::= ::= ::= ::= ::=

{An eight-bit quantity.} {most significant byte} {least significant byte}

Layer 7—Application Layer

The Application Layer provides the set of services and data structures required to support C12.18 Devices for purposes of configuration, programming and information retrieval. 4.2.1. Data Structure

This protocol shall transport Table structures as defined in ANSI C12.19. 4.2.2. Protocol Specifications for Electric Metering (PSEM)

This Standard defines nine (9) Protocol Specifications for Electric Metering (PSEM) services. Each service consists of a request and a response. Each of these requests and responses is described in the following service sections.

::= | | | | | | | |

{Identification Service request} {Read Service request} {Write Service request} {Logon Service request} {Security Service request} {Logoff Service request} {Negotiate Service request} {Wait Service request} {Terminate Service request}



::= | | | | | | | |

{Identification Service response} {Read Service response} {Write Service response} {Logon Service response} {Security Service response} {Logoff Service response} {Negotiate Service response} {Wait Service response} {Terminate Service response}

4.2.2.1. Request Codes

4

ANSI C12.18 – 2005 PSEM requests always include a one-byte request code. Code numbers are represented in hexadecimal format as follows: 00H-1FH

Codes shall not be used to avoid confusion with response codes

20H-7FH

Codes in this range signify request codes

80H-FFH

Codes shall be reserved for protocol extensions

4.2.2.2. Response Codes PSEM responses always include a one-byte response code. These codes are listed below in a suggested order of priority. When more than one response code is capable of indicating the error response condition of a C12.18 Device or a C12.18 Client, the response code having the highest priority (from left to right) is as follows:

::= |||||||||

For example, if Standard Table 05 of a C12.18 Device is read-only and it is encoded in nonvolatile memory then a Write service request to Table 05 would fail. The C12.18 Device may consider the following codes as suitable responses: to indicate an error condition or to indicate that the data is locked in memory and cannot be changed, to indicate that the action requested was not appropriate for this device design or to indicate that the table access permission are “read-only” under the current security policy. The correct response would be as it is the highest priority among , , and . However, if there is a mechanism for providing write access to Table 05, then should not be considered. Therefore, the response code becomes . Responses:

::=

00H

{Acknowledge Application Layer response indicating no problems, request accepted.}



::=

01H

{Error This Application Layer error code is used to indicate rejection of the received service request. The reason for the rejection is not provided.}



::=

02H

{Service Not Supported This Application Layer error response will be sent to the device when the requested service is not supported. This error indicates that the message was valid, but the request could not be honored.}



::=

03H

{Insufficient Security Clearance

5

ANSI C12.18 – 2005 This Application Layer error indicates that the current authorization level is insufficient to complete the request.}

::=

04H

{Operation Not Possible This Application Layer error will be sent to the device which requested an action that is not possible. This error indicates that the message was valid, but the message could not be processed. Covers conditions such as: invalid length, invalid offset}



::=

05H

{Inappropriate Action Requested This Application Layer error indicates that the action requested was inappropriate. Covers conditions such as write request to a read-only table or an invalid table id.}



::=

06H

{Device Busy This Application Layer error indicates that the request was not acted upon because the device was busy doing something else. The operation may be retried at a later time with success, as the data may then be ready for transportation during this active communication.}



::=

07H

{Data Not Ready This Application Layer error indicates that request was unsuccessful because the requested data is not ready to be accessed.}



::=

08H

{Data Locked This Application Layer error indicates that the request was unsuccessful because the data cannot be accessed.}



::=

09H

{Renegotiate Request This Application Layer error indicates that the responding device wishes to return to the ID or Base State and renegotiate communication parameters.}



::=

0AH

{Invalid Service Sequence State This Application Layer error indicates that the request is not accepted at the current service sequence state. For more

6

ANSI C12.18 – 2005 information on service sequence states, see Annex C, Service Sequence State Control.} 0BH-1FH

{Undefined response codes.}

20H-7FH

{Codes shall not be used to avoid confusion with request codes.}

80H-FFH

{Codes shall be reserved for protocol extensions.}

4.2.2.3. Identification Service The Identification Service shall be the first service issued upon C12.18 Device power-up, following a PSEM Terminate Service response, or Channel Traffic Time-out, and returns the version and revision of the protocol where the version is positioned left of the decimal indicating a major change and the revision is positioned right of the decimal indicating a minor change. It may also return a device class or device identity. Since this service is always issued prior to the Negotiate Service, the size of the returned response shall never exceed the default packet size. The Identification Service is a required service. The Identification Service shall be initiated only by a C12.18 Client. Request:

::= 20H

Response: The responses , , and indicate a problem with the received service request. The response indicates the Identification Service request was accepted and the version and revision are included in the response. Implementers shall ensure that the response fits within a single 64-byte packet.

::= | | | *



::=

{Code identifying reference Standard. The codes are defined as follows: 00H = ANSI C12.18 01H = Reserved 02H = ANSI C12.21 03H = ANSI C12.22 04H - FFH = Reserved A C12.18 Device shall return 00H.}



::=

{Referenced Standard version number. Previous versions shall be Version 1. This version shall be Version 2.}

7

ANSI C12.18 – 2005



::=

{Referenced Standard revision number. This value shall be zero (0).}



::= | {Features available.}



::= 00H



::= 06H

{End of list indicator.}

{A Universal Identifier that uniquely identifies a C12.19 Device Class object for early detection of the device class as per MANUFACTURER as defined in Table 00 of ANSI C12.19-1997 or the DEVICE_CLASS as defined by Version 2 of ANSI C12.19. The C12.19 Device Class shall be supplied when the C12.19 Device Table 00, GEN_CONFIG_TBL, is readable immediately following the Logon Service. When C12.19 Device Class is provided, it shall not be preceded by features with codes that are less than 06H.}

::= | {The C12.19 Device Class encoded as an absolute or relative registered universal object identifier.}

::= 06H {The absolute encoding of the C12.19 Device Class; e.g., 1.2.840.10066.0., encoded as described in ISO/IEC 8825-1 (2002), Basic Encoding Rules (BER). The last 4 bytes of this identifier shall be identical to the values delivered in the C12.19 Table elements MANUFACTURER as defined in Table 00 of ANSI C12.191997 or the DEVICE_CLASS as defined by Version 2 of ANSI C12.19.} ::= 0DH {The relative encoding of the C12.19 Device Class relative to the universal identifier 1.2.840.10066.0, encoded as described in ISO/IEC 8825-1 (2002), Basic Encoding Rules (BER). The shall range between 00H to 04H resulting in up to 4 bytes being transmitted. These 4 bytes

8

ANSI C12.18 – 2005 shall be identical to the C12.19 Table elements MANUFACTURER as defined in Table 00 of ANSI C12.191997 or the DEVICE_CLASS as defined by Version 2 of ANSI C12.19, with assumed 00H trailing pad.}

::=

{Length of number of bytes that follow. This value shall range between 00H to 7FH.}



::= +

{Absolute object identifier encoded as described in ISO/IEC 8825-1 (2002), Basic Encoding Rules (BER). The size of this field shall not exceed 127 bytes.}



::= +

{Relative object identifier encoded as described in ISO/IEC 8825-1 (2002), Basic Encoding Rules (BER). The size of this field shall not exceed 4 bytes.}

::= 07H {An Identifier that uniquely identifies a C12.19 Device in the application space of the C12.19 Device. This provides for early detection of the device identification element as per IDENTIFICATION of Table 05, DEVICE_IDENT_TBL, or DEVICE_ID found in Table 06 of ANSI C12.19. The C12.19 feature shall be supplied when the C12.19 Device Table 05 or Table 06 are readable immediately following the Logon Service. When C12.19 Device identification is provided, it shall not be preceded by features with codes that are less than 07H.} ::=



::=



::=

{Length of number of bytes that follow in . This value shall range between 00H to 7FH.}

{Provides for disclosure of the C12.19 Device identification.} {The character encoding format of the bytes which make up . Its interpretation shall be according to the relevant ANSI C12.19 Standard data model referenced by

9

ANSI C12.18 – 2005 the C12.19 registered Device Class feature . When the feature is not supplied in this response, the value of shall be set to 01H, and shall be encoded according to ISO 7-bit coded character set for information interchange, per ISO/IEC 646 (1991).} ::= *

{The C12.19 Device identification string encoded and transmitted according to . If the C12.19 Device ID_FORM in Table 00 is set to BCD, then the BCD digits shall be transmitted as their text equivalent also encoded as per char-format>. For example, assuming that the C12.19 Device GEN_CONFIG_TBL.ID_FORM is BCD and the Device GEN_CONFIG_TBL.CHAR_FORMAT is ISO 7 bit ASCII, as per ISO/IEC 646 (1991), then the BCD digits 00H 01H 02H 03H 0AH 04H 0DH 05H 06H 07H shall be transmitted as the character sequence “123-4.567”. The C12.19 application shall logically pad this string with trailing spaces as needed to fill the identification field width of the C12.19 Device.}

4.2.2.4. Read Service The Read Service is used to transfer Table data to the requesting device and shall be initiated only during a session that was successfully established using the Logon Service. At least one (1) form of the Read Service is required to be supported by a C12.18 Device. Request: The Read Service request supports both complete and partial Table transfers. The retrieval of a portion of a Table is possible through the use of both index/element-count and offset/octet-count methods. The complete rule set for using these methods is enumerated in Sections 4.2.2.12, Partial Table Access Using the Index/element-count Method, and 4.2.2.14, Partial Table Access Using the Offset/octet-count Method, respectively. Codes 30H–39H, 3EH and 3FH are the Read Service request codes. Request code 30H specifies a complete Table transfer. Request codes 31H through 39H specify a partial Table transfer using 1

10

ANSI C12.18 – 2005 to 9 indices. Request code 3EH specifies a default Table transfer. Request code 3FH specifies a partial Table transfer using the offset/octet-count method.

::= | | |



::= 30H



::= +



::=

31H 32H 33H 34H 35H 36H 37H 38H 39H

| | | | | | | |

::= 3EH

{1 {2 {3 {4 {5 {6 {7 {8 {9



included included included included included included included included included

in in in in in in in in in

request} request} request} request} request} request} request} request} request}

{Transfer default Table as defined by the C12.19 Device.}



::= 3FH



::=

{Table identifier as defined in ANSI C12.19.}



::=

{Offset into data Table in bytes. Offset 0000H is the offset to the first table element of the Table selected by .}



::=

{Index value used to locate start of data. Index 0000H is the index of the first Table element of the Table selected by .}

::=

{Number of Table elements to read starting at the requested index.}



{Length of Table data requested starting at Table , in bytes.}

::=

Response: Responses of type indicate a problem with the received Read Service request. The response indicates the Read Service was accepted and the data is part of the response.

::= |



::=

11

ANSI C12.18 – 2005



::=

{Length of returned, in bytes.}



::= *

{The returned Table data including the optional pending header as per ANSI C12.19, when requested.}



::=

{2's compliment checksum computed only on the portion of . The checksum is computed by summing the bytes (ignoring overflow) and negating the result.}

4.2.2.5. Write Service The Write Service is issued to transfer Table data to the target device and shall be initiated during a session that was successfully established using the Logon Service. The Write Service is an optional service. Request: The Write Service request allows both complete and partial Table transfers. The modification of a portion of a Table is possible through the use of both index/element-count and offset/octetcount methods. The complete rule set for using these methods is enumerated in Sections 4.2.2.12 and 4.2.2.14, respectively. Codes 40H–49H and 4FH are the Write Service request codes. Request code 40H specifies a complete Table transfer. Request codes 41H through 49H specify a partial Table transfer using 1 to 9 indices. Request code 4FH specifies a partial Table transfer using the offset/octet-count method.

::= | |



::= 40H



::= +



::=

41H 42H 43H 44H 45H 46H 47H 48H 49H

| | | | | | | |

{1 {2 {3 {4 {5 {6 {7 {8 {9



included included included included included included included included included

in in in in in in in in in

request} request} request} request} request} request} request} request} request}

::= 4FH

12

ANSI C12.18 – 2005

::=

{Table identifier, as defined in ANSI Standard C12.19.}



::=

{Offset into data Table, in bytes. Offset 0000H is the offset to the first element of the Table selected by .}



::=



{Index value used to locate start of data. Index 0000H is the index of the first element of the Table selected by .} ::=



::=

{Length of to be written, in bytes. This includes the optional pending header length as defined by ANSI C12.19.}



::= *

{The Table data elements including the optional pending header as per ANSI C12.19, when requested.}



::=

{2's compliment checksum computed only on the portion of . The checksum is computed by summing the bytes (ignoring overflow) and negating the result.}

Response: Responses of type indicate a problem with the received Write Service request. The response indicates the Write Service was successfully completed and the data was successfully transmitted to the requesting device.

::= |

4.2.2.6. Logon Service The Logon Service establishes a session without establishing access permissions. The Logon Service is a required service. The Logon Service shall be initiated only by a C12.18 Client. Request: The parameter is a code, optionally stored by the C12.18 Device, indicating the identity of the operator requesting the creation of a session. The may be inserted in

13

ANSI C12.18 – 2005 the Event and History Logs as defined in ANSI C12.19. The field provides the name of the operator requesting the access to the device. The Logon Service has the following format:

::= 50H



::=

{User identification code. This field is transferred to USER_ID in Procedure 18 of C12.19.}



::= +10

{10 bytes containing user identification}

Response: The responses , , and indicate a problem with the received Logon Service request. The response indicates the Logon Service was successfully completed and the session was established.

::= | | | |

4.2.2.7. Security Service The Security Service is provided for setting access permissions and shall be initiated only during a session that was successfully established using the Logon Service. The Security Service is an optional service. The Security Service shall be initiated only by a C12.18 Client. Request: A password is used as a means to select access permissions. This service request shall only be sent during a session. If the password tables are supported by the C12.18 Device, the field, will be compared with the PASSWORD elements of SECURITY_TBL (Table 42) of ANSI C12.19. The number of bytes validated shall be 20 or the value of the element PASSWORD_LEN found in ACT_SECURITY_LIMITING_TBL (Table 41), whichever is smaller.

::= 51H



::= +20

{20-byte field containing password}

14

ANSI C12.18 – 2005 Response: The responses , , and indicate a problem with the received Security Service request. The response indicates the Security Service was successfully completed and the access permissions associated with the password were granted.

::= | | | |

4.2.2.8. Logoff Service The Logoff Service provides for an orderly shutdown of the session established by the Logon Service. The Logoff Service is a required service. Request: Following a Logoff Service request, the communication channel will retain the parameters previously established.

::= 52H

Response: The responses , , and indicate a problem with the received Logoff Service request. The response indicates the acceptance of the Logoff Service and the cessation of the session established by the Logon Service.

::= | | |

4.2.2.9. Negotiate Service The Negotiate Service provides the mechanism for reconfiguring the communication channel for communication parameters differing from the default values specified in this Standard. The Negotiate Service is an optional service. The Negotiate Service shall be issued only after the Identification Service and before the Logon Service. The negotiated parameters shall remain in effect until re-negotiated or the communication channel is closed. The Negotiate Service shall be initiated only by a C12.18 Client. Request:

15

ANSI C12.18 – 2005



::=

*

::= 60H | 61H 62H 63H 64H 65H 66H 67H 68H 69H 6AH

{No included in request. Stay at default baud rate} {1 included in request} {2 included in request} {3 included in request} {4 included in request} {5 included in request} {6 included in request} {7 included in request} {8 included in request} {9 included in request} {10 included in request} {11 included in request}

| | | | | | | | | |

6BH



::=

{Maximum packet size supported, in bytes. This value shall be in the range of 64 - 8192 bytes, inclusive.}



::=

{Maximum number of packets this layer is able to reassemble into an upper layer data structure at one time. The value zero (0) is reserved for future standard extension.}



::= 00H 01H 02H 03H 04H 05H 06H 07H 08H 09H 0AH 0BH 0CH 0DH 0EH 0FH

{Externally defined} {300 baud} {600 baud} {1200 baud} {2400 baud} {4800 baud} {9600 baud} {14400 baud} {19200 baud} {28800 baud} {57600 baud} {38400 baud} {115200 baud} {128000 baud} {256000 baud} {reserved}

| | | | | | | | | | | | | | – FFH

Response: The responses , , and indicate a problem with the received Negotiate Service request and that the communication channel will maintain its current settings.

16

ANSI C12.18 – 2005 The response indicates the Negotiate Service request was accepted and all new settings now apply to both devices. The data following the indicates the new settings. If the target cannot accept the Negotiate Service request baud rates, the original baud rate will be echoed in the response.

::= | | | |

4.2.2.10.Wait Service The Wait Service is used by either of the communicating devices to maintain an established communication channel during idle periods, thus preventing automatic termination. The Wait Service temporarily extends the channel traffic time-out to the specified in the request upon acknowledgement of the Wait Service request. The channel traffic time-out will be reset to the default value once the next PSEM Request or PSEM Response is received by the target of this service. The Wait Service is an optional service. Request:

::= 70H



::=

{Suggested wait period in seconds. The value 0 does not affect the channel settings.}

Response: The responses , , , and indicate a problem with the received Wait Service request and time-out is not extended. The response indicates the service request was accepted and the time-out is extended to the value requested.

::= | | | |

4.2.2.11.Terminate Service The Terminate Service provides for an immediate cessation of the communication channel and aborts an open session, and implicitly invokes the Logoff Service. The Terminate Service is an optional service. Request: The Terminate Service may be used to terminate either partially or fully established communication channels for reasons such a excessive errors, security issues, internal error 17

ANSI C12.18 – 2005 conditions, end of session, or other reasons as set by the device manufacturer. When the Terminate Service is invoked within an open session, any or all session-oriented transactions may be lost or may be rolled back to values that existed at the start of session.

::= 21H

Response: The responses and indicates a problem with the received Terminate Service request and the channel remains open. The response indicates the service request was accepted and the channel will return to default settings as stated in Section 4.7.1.1, Default Settings, upon receipt of a positive acknowledgment.

::= | |

4.2.2.12.Partial Table Access Using the Index/element-count Method 1.

An index sets up a start of selection into a Table object relative to the beginning of the Table, where PACKED RECORD, BIT FIELD, SET, ARRAY, STRING, IF and CASE are defined in ANSI C12.19, as follows: •

Each member of a PACKED RECORD gets a unique number.

•

The positional number of the first element of a PACKED RECORD is assigned the value zero (0).

•

The positional number of subsequent elements in the same PACKED RECORD is incremented by one (1) for each subsequent element in the PACKED RECORD.

•

Each sub element of a BIT FIELD is assigned a unique positional number.

•

The positional number of the first sub element of a BIT FIELD is assigned the value zero (0).

•

The positional number of subsequent sub elements in the same BIT FIELD is incremented by one (1) for each subsequent sub element in the BIT FIELD, independent of the bit range assigned to the sub element.

•

Positional numbers are assigned independently of any IF or CASE statements that may be present inside PACKED RECORDs or BIT FIELDs, as if the elements or subelements where not enclosed within any IF or SWITCH statements.

•

For non-final elements one level of index is appended to the index of the parent’s element index for use in selections. 18

ANSI C12.18 – 2005

•

Selection of Boolean members within a SET are referenced in the same manner as members of a single dimensional array.

•

For elements of an ARRAY one level of index is appended to the index of the array’s element for each dimension (as per BNF.dim) for use in selections into entries of the ARRAY.

2.

Selection based on an index method using equal to one (1) will deliver the whole selected element.

3.

For the purpose of binary transmission, + cannot select into a sub-element or final elements that are not atomic, with the exception of SETs, where the first octet selected for transmission is that computed by integer division of the atomic index number requested by 8, and the number of elements is the number of bits requested.

4.

For the purpose of transmission, an indexed selection into a non-existing element shall result in an "Inappropriate Action Requested" error. However, it is allowed to append zeros at the end of an + to indicate the desired access level of an indexed selection within the Table element hierarchy.

5.

When is greater than one (1), the application shall return up to elements at the same or lower hierarchical level of the + used to initiate the request traversing all element types serially.

6.

When is greater than the number of elements available for transmission, the number of elements transmitted will be limited to the maximum number elements available at the same or lower hierarchical level of the + used to initiated the request..

7.

The number of numeric segments that make up the + defines the initial hierarchical level for element serialization and for interpretation.

8.

As a part of a Read Service request, equal to zero (0) shall be interpreted as ALL data starting from the + to the end of the Table requested.

9.

As a part of a response, equal to zero (0) shall be interpreted as NO data was received.

10.

As a part of a Write Service request, shall correctly represent the actual number of bytes to be written, including the optional pending header, at the hierarchical level of the selection start +.

11.

As a part of a Read Service request, represents the maximum number of elements requested.

19

ANSI C12.18 – 2005 12.

Any element excluded from the data stream through the use of the IF or CASE conditional statements shall not be a candidate for transmission and not be counted.

13.

Any element excluded from the data stream through the use of zero-length ARRAYs, SETs, STRINGs, BINARYs shall not be a candidate for transmission and not be counted.

14.

Any element whose size is zero (0) shall not be a candidate for transmission and not be counted.

15.

The counts elements and not octets.

16.

If the respondent application does not support the transmission elements at the requested index level, or the respondent application cannot deliver the element requested from an ARRAY the respondent application shall assert the error condition "Inappropriate Action Requested". The requester may then attempt a retry of the Read or Write Service request on an + of an element that is higher or lower in hierarchy relative to the + of the failed attempt.

4.2.2.13.Index Count Access Method Examples The following are examples for the use of the Index/Element-Count method to select data. Example 1

Example 2

Example 3

Example 4

= 1.0 = 2

= 1, = 2 or = 1.0, = 4

= 1.2.0, = 4

= 1.2, = 4 or = 1.2.0, = 5

0

0

0

0

1.0

(Selected)

1.0

(Selected)

1.0

1.0

1.1

(Selected)

1.1

(Selected)

1.1

1.1

1.2

1.2

(Selected)

1.2

2

2

(Selected)

3.0

3.0

3.1.0

3.1.0

(Selected)

1.2

2

(Selected)

2

(Selected)

3.0

(Selected)

3.0

(Selected)

3.1.0

(Selected)

3.1.0

(Selected) (Selected)

3.1.1

3.1.1

3.1.1

3.1.1

3.2

3.2

3.2

3.2

4

4

4

4

(Selected)

4.2.2.14.Partial Table Access Using the Offset/octet-count Method 1.

An sets up a start of selection into a Table object relative to the beginning of the Table.

20

ANSI C12.18 – 2005 2.

An zero (0) is the octet offset to the first octet of the first element in the Table as prescribed by the object data type and the value of DATA_ORDER, found in the GEN_CONFIG_TBL (Table 00).

3.

When is greater than one (1), the application shall return no more than octets from used to initiate the request traversing all element types serially, where each element will be transferred according to its type and the value of DATA_ORDER, found in the GEN_CONFIG_TBL (Table 00).

4.

When is greater than the number of octets available for transmission, the number of octets transmitted will be limited to the maximum number octets available. The response shall be adjusted to reflect the actual number of octets transferred in the response.

5.

As a part of a request, equal to zero (0) shall be interpreted as ALL data starting from the to the end of the Table requested.

6.

As a part of a response, equal to zero (0) shall be interpreted as NO data was received.

7.

As a part of a Write Service request, shall correctly represent the actual number of octets requested to be written starting at the Table offset requested including the optional pending header.

8.

As a part of a Read Service request, represents the maximum number of octets.

9.

Elements that are not present in the Table by virtue of them being excluded from the data stream through the use of zero-length ARRAYs, SETs, STRINGs, BINARYs or BCDs shall not be candidates for transmission and not be counted.

10.

Any element whose size is zero (0) shall not be a candidate for transmission and not be counted.

11.

The octet counter counts octets and not elements.

12.

If the respondent application does not support the transmission of octets at the requested offset, the respondent application shall assert the error condition "Inappropriate Action Requested”.

4.3.

Layer 6—Presentation Layer

Null layer. The C12.18 Device will not provide queuing capabilities for service requests. 4.4.

Layer 5—Session Layer

21

ANSI C12.18 – 2005 Null layer. Communications between devices over the optical port communications path will be connection oriented and consist of a single session. A session is defined to begin with the acceptance of the Logon Service and terminates with the acceptance of either the Logoff Service or the Terminate Service. 4.5.

Layer 4—Transport Layer

Null layer. 4.6.

Layer 3—Network Layer

Null layer. 4.7.

Layer 2—Data Link Layer

Services of upper layers are transported in one (1) or many packets. Each packet is variable in length but cannot exceed a maximum packet size. The maximum packet size has a default value when the communication channel is opened. The maximum packet size can be changed through the use of the Negotiate Service. For each packet received, a positive or negative acknowledgment is sent by the target device. This acknowledgment consists of a single byte transmitted outside of the packet structure. If the requester does not receive an acknowledgment before the Response Time-out, or a negative acknowledgment is received, the same packet is re-transmitted up to three (3) times. After the third retry attempt, the requester should assume termination has occurred. 4.7.1. Basic Data

Communication channel settings are specified below. The baud rate, number of packets, and packet size each have a default setting which applies at the initiation of communication. These settings may be changed through the Negotiate Service. Negotiated channel settings will return to defaults as a result of the terminate service or Channel Traffic Time-out. DATA FORMAT: DATA TYPE: DATA POLARITY: DATA RATE:

NUMBER OF PACKETS: PACKET SIZE: CHANNEL TRAFFIC TIME-OUT:

8 data bits, 1 start bit, 1 stop bit, no parity Asynchronous, serial bit (start-stop), half duplex LED on, start bit, space, logical zero (0) LED off, stop bit, mark, logical one (1), quiescent state The maximum transmitting speed shall be at least 9600 baud. Selection codes have been arranged for the following baud rates: 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 28800, 38400, 57600, 115200, 128000, 256000 or externally defined. Additional selection codes have been reserved for future assignment. At least one (1) packet is required although more are negotiable. Default packet size is 64 bytes, although a larger size can be negotiated. 6 seconds 22

ANSI C12.18 – 2005 INTER-CHARACTER TIME-OUT: RESPONSE TIME-OUT: TURN-AROUND DELAY:

500 milliseconds 2 seconds 175 microseconds

In the event of a collision (C12.18 Client and C12.18 Device are transmitting at the same time), the C12.18 Device shall cease transmission and wait for the transmission from the C12.18 Client. 4.7.1.1. Default Settings DATA RATE: NUMBER OF PACKETS: PACKET SIZE:

9600 baud 1 64 bytes

4.7.2. Packet

::=



::= EEH

{Start of packet character.}



::=

{C12.19 Device (end device, table driven communication card, etc.) identity. It identifies the C12.19 Device in both the request and response packets. The individual C12.19 Device identities must be in the range 00H to FEH and can be specified by PSEM identify field in Global Parameters Table (Table 92) of ANSI C12.211999. The value FFH is reserved for ANSI C12.21 calling party use. It shall not be used by this protocol. The C12.19 Device shall use its own identity byte or 00H in the response when addressed with an identity other than 00H; otherwise, the response identity byte shall be 00H.}



::=

{Control field. Bit 7. If true (01H) then this packet is part of a multiple packet transmission. Bit 6. If true (01H), then this packet is the first packet of a multiple packet transmission, and Bit 7 shall also be true.

23

ANSI C12.18 – 2005 Bit 5. Represents a toggle bit to reject duplicate packets. This bit shall be toggled for each new packet sent. Retransmitted packets keep the same state as the original packet sent. It should be noted that the initial state of the toggle bit is not specified and could initially be either zero (0) or one (1). Bits 4 to 2, Reserved. The bits shall be set to zero (0) by the transmitter. Bit 0 = 1 = 2 = 3 =

0 to 1: DATA_FORMAT C12.18 or C12.21 C12.22 Reserved Reserved

C12.18 Compliant implementations shall set Bits 0 and 1 to zero (0).}

::=

{Number that is decremented by one (1) for each new packet sent. The first packet in a multiple packet transmission shall have a equal to the total number of packets minus one (1). A value of zero (0) in this field indicates that this packet is the last packet of a multiple packet transmission. If only one (1) packet in a transmission, this field shall be set to zero (0), and Bit 7 and Bit 6 shall be set to zero (0).}



::=

{Number of bytes of data in packet.}



::= *

{ number of bytes of actual packet data. This value is limited by the maximum packet size minus the packet overhead of 8 bytes. This value can never exceed 8183.}



::=

{CCITT CRC standard polynomial X16 + X12 + X5 + 1.}

4.7.3. Duplicate packets

A duplicate packet is defined as a packet whose identity, toggle bit and valid CRC are identical to those of the immediate previous packet. If a duplicate packet is received by the target device, the device shall disregard the duplicate packet and return an . Upon entry into Base State, 24

ANSI C12.18 – 2005 the toggle bit in the first packet may assume any state and the duplicate packet rejection mechanism shall be suppressed until receipt of the first valid packet while in Base State. 4.7.4. CRC selection

The CRC selected for implementation is the CCITT CRC standard polynomial X16 + X12 + X5 + 1. The method for calculation and insertion is the HDLC standard per ISO/IEC 13239 (2002) Annex A. In the PSEM frame, there is no opening flag as referenced in ISO/IEC 13239 (2002) Annex A. The PSEM start of packet character EEH is included in the CRC calculation. The result of the CRC calculation shall be transmitted least significant byte first per the ISO/IEC 13239 (2002) Annex A. 4.7.5. Acknowledgment

A positive or negative acknowledgment is used by the communicating devices to indicate either acceptance or rejection of a single packet. An shall be issued by the receiving device to the transmitting device for each valid packet received.

::= 06H

A shall be issued by the receiving device to the transmitting device for each packet received that: (1) begins with , and (2) must be followed by five (5) additional bytes followed by bytes followed by two (2) additional bytes, and (3) is completely received without any intervening inter-character time-outs, and (4) contains some other error.

::= 15H

4.7.6. Retransmission

The same packet shall be transmitted if a is received, an invalid character is received, or the acknowledge time-out elapses. After three (3) consecutive retries, automatic termination shall occur. If a duplicate packet is received by the target, the target shall disregard the duplicate packet and return an . 4.7.7. Time-out

4.7.7.1. Channel Traffic Time-out

25

ANSI C12.18 – 2005 The C12.18 Device shall terminate communications after waiting some period of time for a valid PSEM Request or PSEM Response. This period of time, defined as the default Channel Traffic Time-out, shall be six (6) seconds. It may be temporarily modified by the Wait Service. Termination of communication due to Channel Traffic Time-out has the same effect of a successful invocation of the Terminate Service. 4.7.7.2. Inter-character Time-out The recipient of the packet shall handle the case when the end of a packet is lost. Inter-character Time-out is defined as the minimum amount of time the recipient shall wait between bytes within a packet when receiving data over the communication channel. The recipient shall wait at least this amount of time before it ceases to wait for the remaining bytes of the packet and sends a . The Inter-character Time-out shall be 500 milliseconds. 4.7.7.3. Response Time-out The sender of the packet shall handle the condition where the or is lost. Response Time-out is defined as the minimum amount of time the sender shall wait after a packet is sent to receive an or over the communication channel. If this amount of time elapses, the sender shall send the packet again, unless the retry attempts counter has reached its maximum allowed value. The Response Time-out shall be two (2) seconds. 4.7.8. Delays

4.7.8.1. Turn-around Delay The Turn-around Delay is the minimum delay the recipient must wait after receiving a packet and before sending a positive or negative acknowledge. The Turn-around Delay shall be 175 microseconds.

26

ANSI C12.18 – 2005

4.8.

Layer-1—Physical Layer

4.8.1. Physical

.205

DIA., TRANSMITTER TRANSMISSION PATH

.175 .205

DIA., RECEIVER TRANSMISSION PATH

.175 .160 MIN.

OPTICAL REFERENCE PLANE .835 .825

C L OPTICAL PATH

C L .992

.244/.280 SYMMETRICAL

MOUNTING SURFACE

DIA.

.984 1.55 DIA. MIN CLEARANCE FOR MATING DEVICE

FRONT VIEW

SIDE VIEW

Notes: 1. 2.

All dimensions in inches Not to scale

Figure 4-1: External View ANSI Type 2 Optical Port

27

ANSI C12.18 – 2005

5.21

DIA., TRANSMITTER TRANSMISSION PATH

4.45 5.21

DIA., RECEIVER TRANSMISSION PATH

4.45 4.06 MIN.

OPTICAL REFERENCE PLANE 21.21 20.96

C L OPTICAL PATH

C L 25.20

6.20/7.11 SYMMETRICAL

MOUNTING SURFACE

DIA.

24.99 39.37 DIA. MIN. CLEARANCE FOR MATING DEVICE

FRONT VIEW

SIDE VIEW

Notes: 1. 2.

All dimensions in mm. Not to scale

Figure 4-2: External View ANSI Type 2 Optical Port 4.8.2. Basic Data

The Physical Layer data setting is specified below. DATA POLARITY:

LED on, start bit, space, logical zero (0) LED off, stop bit, mark, logical one (1), quiescent state

4.8.3. Light Levels

4.8.3.1. Optical Characteristics The wavelength of the radiated signals in both directions is between 800 nm and 1,000 nm (infrared). 4.8.3.2. Transmitter Characteristics

28

ANSI C12.18 – 2005 With reference to Figure 4-3: Test Arrangement for the Transmitter, the transmitter in the C12.18 Device generates a signal with a radiation strength Eø/T over a defined circular reference surface (optically active area) of diameter d1. The test receiver is on the optical axis of the transmitter at a distance d2 from the optical reference plane on the C12.18 Device. The following limiting values apply: The reference temperature is 23°C (±2°C). d1 = 5 mm (± 1 mm) Both conditions shall be met: ON Condition 250
d2 = 10 mm (± 1 mm) d2 = 25 mm (± 1 mm)

OFF Condition Eø/T <10 µW/cm2 Eø/T <10 µW/cm2

Optical axis of the transmitter

d1 Test Receiver

Transmitted Beam

d2 Optical Reference Plane (Surface of metering device optical port)

Transmitter in the metering device

Figure 4-3: Test Arrangement for the Transmitter 4.8.3.3. Receiver Characteristics With reference to Figure 4-4: Test Arrangement for the Receiver, a test transmitter, located on the optical axis, and positioned at a distance d2 from the optical reference plane of the C12.18

29

ANSI C12.18 – 2005 Device, generates a signal with a radiation strength Eø/R over a defined circular reference surface (optically active area) with a diameter d1 at the optical reference plane. The receiver shall respond to test signals as follows: The reference temperature is 23°C (±2°C). d1 = 5 mm (± 1 mm) Both conditions shall be met: ON Condition 1000
d2 = 10 mm (± 1 mm) d2 = 25 mm (± 1 mm)

OFF Condition Eø/T <10 µW/cm2 Eø/T <10 µW/cm2

Optical axis of the receiver

Test Transmitter

Transmitted Beam

d2

Optical Reference Plane (Surface of metering device optical port)

Receiver in the metering device

d1

Figure 4-4: Test Arrangement for the Receiver 4.8.3.4. Environmental Lighting Condition The optical path (data transmission) shall not be affected by surrounding light with an intensity of up to 16,000 lux (light composition comparable with daylight, including fluorescent light). 5. COMPLIANCE A C12.18 Device is considered to be in compliance with this Standard if all of the following conditions are met:

30

ANSI C12.18 – 2005 1.

The C12.18 Device shall: − accept and act upon all service requests as defined in Section 4.2, Layer 7 Application Layer; − respond with a if a requested service is optional and it is not supported; − minimally support Identification, Logon, Logoff and at least one (1) form of Read. Any service defined in this Standard, when implemented, shall comply with the C12.18 service description.

2.

Section 4.7, Layer 2 - Data Link Layer, must be adhered to in its entirety.

3.

The C12.18 Device is compliant with this Standard if zero (0) features () are supported in the Identification Service.

4.

The physical dimensions defined in Section 4.8.1, Physical, shall be met.

5.

The light levels defined in Section 4.8.3, Light Levels, shall be met.

31

ANSI C12.18 – 2005

ANNEX A - Communication Example (Layer 7 and Layer 2) INFORMATIVE

Figure A-1: Communication Example, shows an example of a communications session between a C12.18 Client (handheld) and a C12.18 Device (meter) in which a table is read. ANNEX B Packet Transmission Example, Figure B-1: Packet Transmission Example, shows the actual packet data transmission of this example.

32

ANSI C12.18 – 2005

C12.18 CLIENT (HANDHELD) LAYER 7

LAYER 2

IDENTIFICATION REQUEST OUT

PACKET 1

IDENTIFICATION RESPONSE IN NEGOTIATE REQUEST OUT

NEGOTIATE RESONSE IN LOGON REQUEST OUT

LOGON RESPONSE IN SECURITY REQUEST OUT

SECURITY RESPONSE IN READ REQUEST OUT

INDEX AND CHANNEL DIRECTION

Å 2

ACK

Å 3

PACKET 1

4 Æ

PACKET 1

5 Æ

PACKET 1

Å 6

ACK

Å 7

PACKET 1

PACKET 1

LOGON RESPONSE OUT

Å 14

ACK

SECURITY REQUEST IN

Å 15

PACKET 1

LOGOFF RESPONSE IN TERMINATE REQUEST OUT

TERMINATE RESPONSE IN

SECURITY RESPONSE OUT

17 Æ Å 18

ACK

Å 19

PACKET 1

READ REQUEST IN READ RESPONSE OUT

20 Æ PACKET 2

22 Æ

ACK

24 Æ

PACKET 1

25 Æ

PACKET 3

Å 26

ACK

Å 27

PACKET 1

LOGOFF RESPONSE OUT

Å 30

ACK

TERMINATE REQUEST IN

Å 31

PACKET 1

ACK

28 Æ

PACKET 1

29 Æ

ACK

LOGON REQUEST IN

16 Æ

Å 23

LOGOFF REQUEST OUT

NEGOTIATE RESPONSE OUT

Å 11

Å 21

READ RESPONSE IN

NEGOTIATE REQUEST IN

ACK

13 Æ

ACK

IDENTIFICATION RESPONSE OUT

9 Æ

PACKET 1

ACK

IDENTIFICATION REQUEST IN

Å 10

12 Æ

PACKET 1

LAYER 7

8 Æ

ACK

ACK

LAYER 2

1 Æ

ACK

ACK

C12.18 DEVICE (METER)

LOGOFF REQUEST IN

TERMINATE RESPONSE OUT

32 Æ

Figure A-1: Communication Example

33

ANSI C12.18 – 2005

ANNEX B - Packet Transmission Example INFORMATIVE

Figure B-1: Packet Transmission Example, shows the actual packet data being transmitted in Figure A-1: Communication Example, in ANNEX A - COMMUNICATION EXAMPLE (LAYER 7 AND LAYER 2). Numbers 1) – 32) refer to the numbers in Figure A-1: Communication Example. All values are specified in hexadecimal format. The following arbitrary information was used.

=

00



=

02



=

00



=

0040 (64 bytes)



=

04 (4 packets)



=

08 (19200 baud)



=

1111



=

01 02 03 04 05 06 07 08 09 0A



=

01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14



=

0000



=

000010



=

0096 (150 bytes)



=

01 13 25 37 4F 61 73 85

02 14 26 38 50 62 74 86

03 15 27 39 51 63 75 87

04 16 28 40 52 64 76 88

05 17 29 41 53 65 77 89

06 18 2A 42 54 66 78 90

07 19 2B 43 55 67 79 91

08 1A 2C 44 56 68 7A 92

09 1B 2D 45 57 69 7B 93

0A 0B 0C 1C 1D 1E 2E 2F 30 46 47 48 58 59 5A 6A 6B 6C 7C 7D 7E 94 95 96

0D 1F 31 49 5B 6D 7F

0E 20 32 4A 5C 6E 80

0F 21 33 4B 5D 6F 81

10 22 34 4C 5E 70 82

11 23 35 4D 5F 71 83

12 24 36 4E 60 72 84

34

ANSI C12.18 – 2005 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13)

Æ Å Å Æ Æ Å Å Æ Æ Å Å Æ Æ

14) 15) 16) 17) 18) 19)

Å Å Æ Æ Å Å

20) Æ 21) Å

22) Æ 23) Å

24) 25) 26) 27) 28) 29)

Æ Æ Å Å Æ Æ

EE 00 00 00 0001 20 13 10 06 EE 00 00 00 0005 00 00 02 00 00 C6 B5 06 EE 00 20 00 0005 61 0040 04 08 8A 5F 06 EE 00 20 00 0005 00 0040 04 08 7D F5 06 EE 00 00 00 000D 50 1111 0102030405060708090A CA 33 06 EE 00 00 00 0001 00 11 31 06 EE 00 20 00 0015 51 0102030405060708090A0B0C0D0E0F1011121314 86 27 06 EE 00 20 00 0001 00 80 51 06 EE 00 00 00 0008 3F 0000 000010 0096 B0 7F 06 EE 00 C0 02 0038 00 0096 0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C 1D1E1F202122232425262728292A2B2C2D2E2F303132333435 BA 8E 06 EE 00 A0 01 0038 363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F5051 52535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D F0 47 06 EE 00 80 00 002A 6E6F707172737475767778797A7B7C7D7E7F80818283848586878889 8A8B8C8D8E8F90919293949596 C3 BD B1 06 EE 00 20 00 0001 52 17 20 06 EE 00 20 00 0001 00 80 51 06 EE 00 00 00 0001 21 9A 01 Figure B-1: Packet Transmission Example

35

ANSI C12.18 – 2005

ANNEX C - Service Sequence State Control INFORMATIVE

PSEM communications is defined as a series of “Service Sequence States.” The use of each service may be restricted to one (1) or more states. Specific services also cause transitions between states. The transition is implemented upon positive acknowledgement of the service. The recognized states include. a) b) c)

Base State—This is the state at which communication begins. At this point the default data transmission parameters apply. ID State—Once the C12.18 Device has been identified, this is the state that is entered. Session State—When a successful logon has been completed, this is the state achieved.

The relationship between PSEM services and service sequence states is: Identification Service requests are accepted at the Base State only. Acceptance of an Identification Service response transitions communications to the ID State. The Identification Service cannot originate from the C12.18 Device. Wait Service requests are accepted in the ID and Session States. Acceptance of these requests do not result in any sequence state changes. The Wait Service can originate from either end of the communication channel. Negotiate Service requests are accepted in the ID State only. Acceptance of these requests do not result in any sequence state changes. Negotiated services are not implemented until after acceptance. The Negotiate Service cannot originate from the C12.18 Device. Logon Service requests are accepted at the ID State only. Acceptance of a Logon Service request, transitions communications to the session state. This service cannot originate from the C12.18 Device. Security Service requests are accepted at the Session State only. Acceptance of these requests do not result in any sequence state changes. The Security Service cannot originate from the C12.18 Device. Read and Write Service requests are accepted in the Session State only. Acceptance of these requests do not result in any sequence state changes. These services can originate from either the C12.18 Device or the C12.18 Client. Logoff Service requests are accepted at the Session State only. Acceptance of a Logoff Service request, transitions communications to the ID State. This service can originate from either the C12.18 Device or the C12.18 Client.

36

ANSI C12.18 – 2005 Terminate Service requests are accepted at the ID and Session States. Acceptance of a Terminate Service request, transitions communications to the Base State. This service can originate from either the C12.18 Device or the C12.18 Client.

37

ANSI C12.18 – 2005 Base state

Identification

ID state Negotiate Wait Terminate Logon

Session state

Read Write Security Wait Terminate Logoff

Figure C-1: Communication State Diagram

38

ANSI C12.18 – 2005

ANNEX D - Compatibility INFORMATIVE

1996

2005

2

1

1996

2005

Figure D-1: C12.18 Device Compatibility Diagram Key: Path 1 (solid line): Path 2 (dashed line) : D.1

Backward compatible for the Reader; Forward compatible for the Device. Forward compatible for the Reader; Backward compatible for the Device.

Backward compatibility with previous versions of the Standard

Any future revision of this Standard shall be backward compatible with the previous two (2) revisions of the Standard as defined by the 5-year ANSI revision cycle requirement. D.2

Forward compatibility with next versions of the Standard

39

ANSI C12.18 – 2005 The following forward compatibility criteria shall be used when extending this standard: 1. The following forward compatibility criteria shall be used when extending this Standard. Services may be: 1. defined as new; 2. omitted; 3. required where it had been optional; 4. optional where it had been required. For cases 2 and 4, the response code shall be generated for any service that is not supported. For case 3, the response code shall not be generated for any required service. Example of case 4: Assume that the Security Service was originally defined as follows: 4.2.2.7 Security Service The Security Service is identical to that in C12.18-1996, except that it is now optional. Also assume that ANSI Standard C12.18-1996 states: … …

::=

51H

The response indicates the security service was successfully completed and the access permissions associated with the password were granted. ::=

| | |

It is clear that the change fails to allow for the response code (Service Not Supported), then any implementation of may respond with if and only if there is a condition that can successfully generate an response for a given request. If there is no possibility for the service to operate or be made to operate correctly for this device then the shall be generated. This enable this Standard to extend another or be modified consistently where some required services in one revision or referenced standard become inoperative or optional in other. 2. No tables, procedures or data types shall be introduced or modified by this Standard. These items are to be instead proposed for ANSI C12.19. 40

ANSI C12.18 – 2005

ANNEX E - Historical Background INFORMATIVE

E.1

Foreword of C12.18-1996 and C12.18-1996 (R2002)

(This foreword is not part of American National Standard for Protocol Specification for ANSI Type 2 Optical Port, ANSI C12.18-1995.) This American National Standard provides an open platform communications protocol for twoway communication with an electronic metering device or an electromechanical metering device with an added electronic board. The communications is specified to pass through an ANSI Type 2 Optical Port. The protocol is written to conform to the OSI seven-layer stack. Suggestions for improvement to this standard are welcome. They should be sent to: National Electrical Manufacturers Association Vice President of Engineering 1300 North 17th Street Suite 1847 Rosslyn, VA 22209 This standard was processed and approved for submittal to ANSI by Accredited Standards Committee for Electricity Metering, C12. At the time the committee approved this standard, the C12 Committee had the following members: R.S. Turgel, Chairman Christopher F. Merther, Secretary Cruz Gomez H. Jones Lauren Pananen Timothy Vahlstrom Clark Smith James Mining Joe Blackmer John McEvoy Dan McAuliff Herman Millican Tom Drew Ray Stevens Francis Marta James Schlatter John Lauletta

41

ANSI C12.18 – 2005 Warren Germer Edmund Hoffman Ahn Mai Ralph Fahmy Subcommittee 17 that developed the standard consisted of: Lynnda K. Ell, Chairwomen John Lauletta, Vice Chairman Michael Anderson Ellen Edge Lynnda Ell Bill Gibson Bruce Johnson Larry Kotewa Tempe Lampe Avy Moise Terry Penn Wes Ray Clark Smith Chris Stanfield George Stephens Paul Taylor Kurt Wiechert Michel Veillette

42