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 two-way 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 index-count 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 <byte>, and ending with a stop bit. The start bit is transmitted first. Bits within each byte are transmitted least significant bit first.

<byte> ::= {An eight-bit quantity.} <msbyte> ::= <byte> {most significant byte} <lsbyte> ::= <byte> {least significant byte} <word24> ::= <msbyte><byte><lsbyte> <word16> ::= <msbyte><lsbyte>

4.2. 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.

<requests> ::= <ident> | {Identification Service request} <read> | {Read Service request} <write> | {Write Service request} <logon> | {Logon Service request} <security> | {Security Service request} <logoff> | {Logoff Service request} <negotiate> | {Negotiate Service request} <wait> | {Wait Service request} <terminate> {Terminate Service request} <responses> ::= <ident-r> | {Identification Service response} <read-r> | {Read Service response} <write-r> | {Write Service response} <logon-r> | {Logon Service response} <security-r> | {Security Service response} <logoff-r> | {Logoff Service response} <negotiate-r> | {Negotiate Service response} <wait-r> | {Wait Service response} <terminate-r> {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:

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

<ok> ::= 00H {Acknowledge Application Layer response

indicating no problems, request accepted.}

<err> ::= 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.}

<sns> ::= 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.}

<isc> ::= 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.}

<onp> ::= 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}

<iar> ::= 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.}

<bsy> ::= 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.}

<dnr> ::= 07H {Data Not Ready This Application Layer error

indicates that request was unsuccessful because the requested data is not ready to be accessed.}

<dlk> ::= 08H {Data Locked This Application Layer error

indicates that the request was unsuccessful because the data cannot be accessed.}

<rno> ::= 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.}

<isss> ::= 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:

<ident> ::= 20H Response: The responses <isss>, <bsy>, and <err> indicate a problem with the received service request. The response <ok> 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.

<ident-r> ::= <isss> | <bsy> | <err> | <ok><std><ver><rev><feature>*<end-of-list> <std> ::= <byte> {Code identifying reference

Standard. The codes are defined as follows:

00H = ANSI C12.18 01H = Reserved 02 = ANSI C12.21 H

03H = ANSI C12.22 04H - FFH = Reserved A C12.18 Device shall return 00H.} <ver> ::= <byte> {Referenced Standard version

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

7

ANSI C12.18 – 2005

<rev> ::= <byte> {Referenced Standard revision

number. This value shall be zero (0).}

<feature> ::= <device-class> | <device-identity> {Features available.} <end-of-list> ::= 00H {End of list indicator.} <device-class> ::= 06H <universal-id> {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.}

<universal-id> ::= <absolute-uid-element> | <relative-uid-element> {The C12.19 Device Class encoded as

an absolute or relative registered universal object identifier.}

<absolute-uid-element> ::= 06H <uid-length><absolute-uid> {The absolute encoding of the

C12.19 Device Class; e.g., 1.2.840.10066.0.<relative-uid>, 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.19-1997 or the DEVICE_CLASS as defined by Version 2 of ANSI C12.19.}

<relative-uid-element> ::= 0DH <uid-length><relative-uid> {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 <uid-length> 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.19-1997 or the DEVICE_CLASS as defined by Version 2 of ANSI C12.19, with assumed 00H trailing pad.}

<uid-length> ::= <byte> {Length of number of bytes that

follow. This value shall range between 00H to 7FH.}

<absolute-uid> ::= <byte>+ {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-uid> ::= <byte>+ {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.}

<device-identity> ::= 07H <identity-length><identity> {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 <device-identity> 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.}

<identity-length>::= <byte> {Length of number of bytes that

follow in <identity>. This value shall range between 00H to 7FH.}

<identity> ::= <char-format><identification> {Provides for disclosure of the

C12.19 Device identification.} <char-format> ::= <byte> {The character encoding format of

the bytes which make up <identification>. 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 <device-class>. When the <device-class> feature is not supplied in this <ident> response, the value of <char-format> shall be set to 01H, and <identification> shall be encoded according to ISO 7-bit coded character set for information interchange, per ISO/IEC 646 (1991).}

<identification> ::= <byte>* {The C12.19 Device identification

string encoded and transmitted according to <char-format>. 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.

<read> ::= <full-read> | <pread-index> | <pread-offset> | <pread-default> <full-read> ::= 30H <tableid> <pread-index> ::= <read-index-type><tableid><index>+<element-count> <read-index-type> ::= 31H | {1 <index> included in request} 32H | {2 <index> included in request} 33 | {3 <index> included in request} H

34H | {4 <index> included in request} 35H | {5 <index> included in request} 36 | {6 <index> included in request} H

37H | {7 <index> included in request} 38H | {8 <index> included in request} 39H {9 <index> included in request} <pread-default> ::= 3EH {Transfer default Table as defined

by the C12.19 Device.} <pread-offset> ::= 3FH <tableid><offset><octet-count> <tableid> ::= <word16> {Table identifier as defined in

ANSI C12.19.} <offset> ::= <word24> {Offset into data Table in bytes.

Offset 0000H is the offset to the first table element of the Table selected by <tableid>.}

<index> ::= <word16> {Index value used to locate start

of data. Index 0000H is the index of the first Table element of the Table selected by <tableid>.}

<element-count> ::= <word16> {Number of Table elements to read

starting at the requested index.} <octet-count> ::= <word16> {Length of Table data requested

starting at Table <offset>, in bytes.}

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

<read-r> ::= <nok> | <ok><table-data> <table-data> ::= <count><data><cksum>

11

ANSI C12.18 – 2005

<count> ::= <word16> {Length of <data> returned, in

bytes.} <data> ::= <byte>* {The returned Table data including

the optional pending header as per ANSI C12.19, when requested.}

<cksum> ::= <byte> {2's compliment checksum computed

only on the <data> portion of <table-data>. 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/octet-count 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.

<write> ::= <full-write> | <pwrite-index> | <pwrite-offset> <full-write> ::= 40H <tableid><table-data> <pwrite-index> ::= <write-index-type><tableid><index>+<table-data> <write-index-type> ::= 41H | {1 <index> included in request} 42 | {2 <index> included in request} H

43H | {3 <index> included in request} 44H | {4 <index> included in request} 45 | {5 <index> included in request} H

46H | {6 <index> included in request} 47H | {7 <index> included in request} 48 | {8 <index> included in request} H

49H {9 <index> included in request} <pwrite-offset> ::= 4FH <tableid><offset><table-data>

12

ANSI C12.18 – 2005

<tableid> ::= <word16> {Table identifier, as defined in ANSI Standard C12.19.}

<offset> ::= <word24> {Offset into data Table, in bytes.

Offset 0000H is the offset to the first element of the Table selected by <tableid>.}

<index> ::= <word16> {Index value used to locate start

of data. Index 0000H is the index of the first element of the Table selected by <tableid>.}

<table-data> ::= <count><data><cksum> <count> ::= <word16> {Length of <data> to be written, in

bytes. This includes the optional pending header length as defined by ANSI C12.19.}

<data> ::= <byte>* {The Table data elements including

the optional pending header as per ANSI C12.19, when requested.}

<cksum> ::= <byte> {2's compliment checksum computed

only on the <data> portion of <table-data>. The checksum is computed by summing the bytes (ignoring overflow) and negating the result.}

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

<write-r> ::= <nok> | <ok>

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 <user-id> parameter is a code, optionally stored by the C12.18 Device, indicating the identity of the operator requesting the creation of a session. The <user-id> may be inserted in

13

ANSI C12.18 – 2005

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

<logon> ::= 50H <user-id><user> <user-id> ::= <word16> {User identification code. This

field is transferred to USER_ID in Procedure 18 of C12.19.}

<user> ::= <byte>+10 {10 bytes containing user

identification} Response: The responses <isss>, <iar>, <bsy> and <err> indicate a problem with the received Logon Service request. The response <ok> indicates the Logon Service was successfully completed and the session was established.

<logon-r> ::= <isss> | <iar> | <bsy> | <err> | <ok>

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 <password> 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.

<security> ::= 51H <password> <password> ::= <byte>+20 {20-byte field containing password}

14

ANSI C12.18 – 2005

Response: The responses <sns>, <isss>, <bsy> and <err> indicate a problem with the received Security Service request. The response <ok> indicates the Security Service was successfully completed and the access permissions associated with the password were granted.

<security-r> ::= <sns> | <isss> | <bsy> | <err> | <ok>

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.

<logoff> ::= 52H Response: The responses <isss>, <bsy>, and <err> indicate a problem with the received Logoff Service request. The response <ok> indicates the acceptance of the Logoff Service and the cessation of the session established by the Logon Service.

<logoff-r> ::= <isss> | <bsy> | <err> | <ok>

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

<negotiate> ::= <baud-rate-selector><packet-size><nbr-packets> <baud-rate>*

<baud-rate-selector>::= 60H | {No <baud rate> included in

request. Stay at default baud rate} 61H | {1 <baud rate> included in request} 62 | {2 <baud rate> included in request} H

63H | {3 <baud rate> included in request} 64H | {4 <baud rate> included in request} 65H | {5 <baud rate> included in request} 66H | {6 <baud rate> included in request} 67H | {7 <baud rate> included in request} 68H | {8 <baud rate> included in request} 69H | {9 <baud rate> included in request} 6AH | {10 <baud rate> included in

request} 6BH {11 <baud rate> included in

request} <packet-size> ::= <word16> {Maximum packet size supported, in

bytes. This value shall be in the range of 64 - 8192 bytes, inclusive.}

<nbr-packets> ::= <byte> {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.}

<baud-rate> ::= 00 | {Externally defined} H

01H | {300 baud} 02H | {600 baud} 03 | {1200 baud} H

04H | {2400 baud} 05H | {4800 baud} 06 | {9600 baud} H

07H | {14400 baud} 08H | {19200 baud} 09 | {28800 baud} H

0AH | {57600 baud} 0BH | {38400 baud} 0C | {115200 baud} H

0DH | {128000 baud} 0EH {256000 baud} 0FH – FFH {reserved}

Response: The responses <sns>, <isss>, <bsy> and <err> 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 <ok> indicates the Negotiate Service request was accepted and all new settings now apply to both devices. The data following the <ok> 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.

<negotiate-r> ::= <sns> | <isss> | <bsy> | <err> | <ok><packet-size><nbr-packets><baud-rate>

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 <time> 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:

<wait> ::= 70H <time> <time> ::= <byte> {Suggested wait period in seconds. The value 0 does not affect the

channel settings.} Response: The responses <sns>, <isss>, <bsy>, and <err> indicate a problem with the received Wait Service request and time-out is not extended. The response <ok> indicates the service request was accepted and the time-out is extended to the value requested.

<wait-r> ::= <sns> | <isss> | <bsy> | <err> | <ok>

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.

<terminate> ::= 21H Response: The responses <sns> and <err> indicates a problem with the received Terminate Service request and the channel remains open. The response <ok> 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.

<terminate-r> ::= <sns> | <err> | <ok>

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 sub-elements 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 <element-count> equal to one (1) will deliver

the whole selected element. 3. For the purpose of binary transmission, <index>+ 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 <index>+ to indicate the desired access level of an indexed selection within the Table element hierarchy.

5. When <element-count> is greater than one (1), the application shall return up to <element-

count> elements at the same or lower hierarchical level of the <index>+ used to initiate the request traversing all element types serially.

6. When <element-count> 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 <index>+ used to initiated the request..

7. The number of numeric segments that make up the <index>+ defines the initial hierarchical

level for element serialization and for <element-count> interpretation. 8. As a part of a Read Service request, <element-count> equal to zero (0) shall be interpreted

as ALL data starting from the <index>+ to the end of the Table requested. 9. As a part of a response, <count> equal to zero (0) shall be interpreted as NO data was

received. 10. As a part of a Write Service request, <count> shall correctly represent the actual number of

bytes to be written, including the optional pending header, at the hierarchical level of the selection start <index>+.

11. As a part of a Read Service request, <element-count> 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 <element-count> 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 <index>+ of an element that is higher or lower in hierarchy relative to the <index>+ 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 <index> = 1.0 <element-count> = 2

<index> = 1, <element-count> = 2 or <index> = 1.0, <element-count> = 4

<index> = 1.2.0, <element-count> = 4

<index> = 1.2, <element-count> = 4 or <index> = 1.2.0, <element-count> = 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 (Selected) 1.2 (Selected)

2 2 (Selected) 2 (Selected) 2 (Selected)

3.0 3.0 3.0 (Selected) 3.0 (Selected)

3.1.0 3.1.0 3.1.0 (Selected) 3.1.0 (Selected)

3.1.1 3.1.1 3.1.1 3.1.1 (Selected)

3.2 3.2 3.2 3.2

4 4 4 4

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

1. An <offset> sets up a start of selection into a Table object relative to the beginning of the Table.

20

ANSI C12.18 – 2005

2. An <offset> 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 <count> is greater than one (1), the application shall return no more than <count>

octets from <offset> 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 <count> 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 <count> shall be adjusted to reflect the actual number of octets transferred in the response.

5. As a part of a request, <count> equal to zero (0) shall be interpreted as ALL data starting

from the <offset> to the end of the Table requested. 6. As a part of a response, <count> equal to zero (0) shall be interpreted as NO data was

received. 7. As a part of a Write Service request, <count> 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, <octet-count> 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: 8 data bits, 1 start bit, 1 stop bit, no parity DATA TYPE: Asynchronous, serial bit (start-stop), half duplex DATA POLARITY: LED on, start bit, space, logical zero (0) LED off, stop bit, mark, logical one (1), quiescent state DATA RATE: 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.

NUMBER OF PACKETS: At least one (1) packet is required although more are negotiable.

PACKET SIZE: Default packet size is 64 bytes, although a larger size can be negotiated.

CHANNEL TRAFFIC TIME-OUT: 6 seconds

22

ANSI C12.18 – 2005

INTER-CHARACTER TIME-OUT: 500 milliseconds RESPONSE TIME-OUT: 2 seconds TURN-AROUND DELAY: 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: 9600 baud NUMBER OF PACKETS: 1 PACKET SIZE: 64 bytes

4.7.2. Packet

<packet> ::= <stp><identity><ctrl><seq-nbr><length><data><crc> <stp> ::= EEH {Start of packet character.} <identity> ::= <byte> {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.21-1999.

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.}

<ctrl> ::= <byte> {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 to 1: DATA_FORMAT 0 = C12.18 or C12.21 1 = C12.22 2 = Reserved 3 = Reserved C12.18 Compliant implementations

shall set Bits 0 and 1 to zero (0).}

<seq-nbr> ::= <byte> {Number that is decremented by one

(1) for each new packet sent. The first packet in a multiple packet transmission shall have a <seq-nbr> 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).}

<length> ::= <word16> {Number of bytes of data in

packet.} <data> ::= <byte>* {<length> 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.}

<crc> ::= <lsbyte><msbyte> {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 <ack>. 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 <ack> shall be issued by the receiving device to the transmitting device for each valid packet received.

<ack> ::= 06H A <nak> shall be issued by the receiving device to the transmitting device for each packet received that:

(1) begins with <stp>, and (2) must be followed by five (5) additional bytes followed by <length> 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.

<nak> ::= 15H

4.7.6. Retransmission

The same packet shall be transmitted if a <nak> 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 <ack>.

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 <nak>. 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 <ack> or <nak> 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 <ack> or <nak> 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

OPTICAL REFERENCE PLANE

C L

C L

DIA..992 .984

1.55 DIA. MIN CLEARANCE FOR MATING DEVICE

DIA., RECEIVER TRANSMISSION PATH

DIA., TRANSMITTER TRANSMISSION PATH.205 .175

.205

.175

.835

.825

.244/.280 SYMMETRICAL

OPTICAL PATH

MOUNTING SURFACE

.160 MIN.

FRONT VIEW SIDE VIEW

Notes: 1. All dimensions in inches 2. Not to scale

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

27

ANSI C12.18 – 2005

OPTICAL REFERENCE PLANE

C L

C L

DIA. 25.20 24.99

39.37 DIA. MIN. CLEARANCE FOR MATING DEVICE

DIA., RECEIVER TRANSMISSION PATH

DIA., TRANSMITTER TRANSMISSION PATH5.21 4.45

5.21 4.45

21.21 20.96

6.20/7.11 SYMMETRICAL

OPTICAL PATH

MOUNTING SURFACE

4.06 MIN.

FRONT VIEW SIDE VIEW Notes:

1. All dimensions in mm. 2. 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 OFF Condition d2 = 10 mm (± 1 mm) 250 <Eø/T <7500 µW/cm2 Eø/T <10 µW/cm2

d2 = 25 mm (± 1 mm) 85 <Eø/T <7500 µW/cm2 Eø/T <10 µW/cm2

Test Receiver

d2

d1

Optical axis of the transmitter

Transmitted Beam

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 OFF Condition d2 = 10 mm (± 1 mm) 1000<Eø/R <7500 µW/cm2 Eø/T <10 µW/cm2

d2 = 25 mm (± 1 mm) 1000 <Eø/R <7500 µW/cm2 Eø/T <10 µW/cm2

Test Transmitter

d2

d1

Optical axis of the receiver

Transmitted Beam

Optical Reference Plane (Surface of metering device optical port)

Receiver in the metering device

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 <sns> 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 (<feature>) 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) C12.18 DEVICE (METER)

LAYER 7 LAYER 2

INDEX AND

CHANNEL DIRECTION LAYER 2 LAYER 7

IDENTIFICATION REQUEST OUT PACKET 1 1

2 ACK IDENTIFICATION REQUEST IN

3 PACKET 1 IDENTIFICATION RESPONSE OUT

IDENTIFICATION RESPONSE IN ACK 4

NEGOTIATE REQUEST OUT PACKET 1 5

6 ACK NEGOTIATE REQUEST IN

7 PACKET 1 NEGOTIATE RESPONSE OUT

NEGOTIATE RESONSE IN ACK 8

LOGON REQUEST OUT PACKET 1 9

10 ACK LOGON REQUEST IN

11 PACKET 1 LOGON RESPONSE OUT

LOGON RESPONSE IN ACK 12

SECURITY REQUEST OUT PACKET 1 13

14 ACK SECURITY REQUEST IN

15 PACKET 1 SECURITY RESPONSE OUT

SECURITY RESPONSE IN ACK 16

READ REQUEST OUT PACKET 1 17

18 ACK READ REQUEST IN

19 PACKET 1 READ RESPONSE OUT

ACK 20

21 PACKET 2

ACK 22

23 PACKET 3

READ RESPONSE IN ACK 24

LOGOFF REQUEST OUT PACKET 1 25

26 ACK LOGOFF REQUEST IN

27 PACKET 1 LOGOFF RESPONSE OUT

LOGOFF RESPONSE IN ACK 28

TERMINATE REQUEST OUT PACKET 1 29

30 ACK TERMINATE REQUEST IN

31 PACKET 1 TERMINATE RESPONSE OUT

TERMINATE RESPONSE IN ACK 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.

<std> = 00 <ver> = 02 <rev> = 00 <packet-size> = 0040 (64 bytes) <nbr-packets> = 04 (4 packets) <baud-rate> = 08 (19200 baud) <user-id> = 1111 <user> = 01 02 03 04 05 06 07 08 09 0A <password> = 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12

13 14 <table-id> = 0000 <offset> = 000010 <count> = 0096 (150 bytes) <data> = 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12

13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96

34

ANSI C12.18 – 2005

1) EE 2) 06 3) EE 4) 06 5) EE 6) 06 7) EE 8) 06 9) EE 10) 06 11) EE 12) 06 13) EE

01014) 06 15) EE 16) 06 17) EE 18) 06 19) EE

0101D1

20) 06 21) EE

363525F0

22) 06 23) EE

6E68A8

24) 06 25) EE 26) 06 27) EE 28) 06 29) EE

00 00 00 0001 20 13 10

00 00 00 0005 00 00 02 00 00 C6 B5

00 20 00 0005 61 0040 04 08 8A 5F

00 20 00 0005 00 0040 04 08 7D F5

00 00 00 000D 50 1111 0102030405060708090A CA 33

00 00 00 0001 00 11 31

00 20 00 0015 51 2030405060708090A0B0C0D0E0F1011121314 86 27

00 20 00 0001 00 80 51

00 00 00 0008 3F 0000 000010 0096 B0 7F

00 C0 02 0038 00 0096 2030405060708090A0B0C0D0E0F101112131415161718191A1B1CE1F202122232425262728292A2B2C2D2E2F303132333435 BA 8E

00 A0 01 0038 738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505135455565758595A5B5C5D5E5F606162636465666768696A6B6C6D 47

00 80 00 002A F707172737475767778797A7B7C7D7E7F80818283848586878889B8C8D8E8F90919293949596 C3 BD B1

00 20 00 0001 52 17 20

00 20 00 0001 00 80 51

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) Base State—This is the state at which communication begins. At this point the default data transmission parameters apply.

b) ID State—Once the C12.18 Device has been identified, this is the state that is entered. c) 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 <ok> 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, <ok> 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, <ok> 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, <ok> 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

Figure C-1: Communication State Diagram

Terminate

Wait

Write

Read

Terminate

Wait

Negotiate

Logoff

Logon

Security

ID state

Session state

38

ANSI C12.18 – 2005

ANNEX D - Compatibility

INFORMATIVE

1996

1996

1 2

2005

2005

Figure D-1: C12.18 Device Compatibility Diagram Key:

Path 1 (solid line): Backward compatible for the Reader; Forward compatible for the Device.

Path 2 (dashed line) : Forward compatible for the Reader; Backward compatible for the Device.

D.1 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 <sns> shall be generated for any service that is not

supported. For case 3, the response code <sns> 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:

… <security> ::= 51H <password> … The response <ok> indicates the security service was successfully completed and the access permissions associated with the password were granted. <security-r> ::= <err> | <bsy> | <isss> | <ok>

It is clear that the change fails to allow for the response code <sns> (Service Not Supported), then any implementation of <security> may respond with <security-r> if and only if there is a condition that can successfully generate an <ok> response for a given <security> request. If there is no possibility for the <security> service to operate or be made to operate correctly for this device then the <sns> 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 two-way 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