Professional Documents
Culture Documents
Ansi C1218 PDF
Ansi C1218 PDF
18-2005
PROTOCOL SPECIFICATION
FOR
ANSI TYPE 2 OPTICAL PORT
Accredited by
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
i
ANSI C12.18 – 2005
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
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:
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:
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
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
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
ISO/IEC 646 (1991), Information Technology - ISO 7-Bit Coded Character Set For Information
Interchange
3.1. Definitions
For the purposes of this Standard, the following definitions are made:
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.
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.4. Table
Functionally related data elements, grouped together into a single data structure for transport as
defined by ANSI C12.19.
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.
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.
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:
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.
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>
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.
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.
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
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 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:
5
ANSI C12.18 – 2005
6
ANSI C12.18 – 2005
20H-7FH {Codes shall not be used to avoid confusion with request codes.}
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.
Request:
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.
7
ANSI C12.18 – 2005
8
ANSI C12.18 – 2005
9
ANSI C12.18 – 2005
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.
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.
11
ANSI C12.18 – 2005
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.
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.
12
ANSI C12.18 – 2005
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.
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.
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.
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.
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.
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.
The Logoff Service provides for an orderly shutdown of the session established by the Logon
Service.
Request:
Following a Logoff Service request, the communication channel will retain the parameters
previously established.
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.
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.
Request:
15
ANSI C12.18 – 2005
<baud-rate-selector>::=
60H | {No <baud rate> included in
request. Stay at default baud rate}
61H | {1 <baud rate> included in request}
62H | {2 <baud rate> included in request}
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}
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.
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.
Request:
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.
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.
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.
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.
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:
• The positional number of the first element of a PACKED RECORD is assigned the
value zero (0).
• 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.
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.
The following are examples for the use of the Index/Element-Count method to select data.
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.
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.
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”.
Null layer. The C12.18 Device will not provide queuing capabilities for service requests.
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.
Null layer.
Null 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.
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.
22
ANSI C12.18 – 2005
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.2. Packet
23
ANSI C12.18 – 2005
Bit 0 to 1: DATA_FORMAT
0 = C12.18 or C12.21
1 = C12.22
2 = Reserved
3 = Reserved
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.
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
An <ack> shall be issued by the receiving device to the transmitting device for each valid packet
received.
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.
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
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.
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.
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
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.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
Notes:
1. All dimensions in inches
2. Not to scale
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
Notes:
1. All dimensions in mm.
2. Not to scale
DATA POLARITY: LED on, start bit, space, logical zero (0)
LED off, stop bit, mark, logical one (1), quiescent state
The wavelength of the radiated signals in both directions is between 800 nm and 1,000 nm
(infrared).
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.
d1 = 5 mm (± 1 mm)
d1
Test Receiver
Transmitted Beam
d2
Optical Reference Plane
(Surface of metering device optical port)
Transmitter in the
metering device
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:
d1 = 5 mm (± 1 mm)
Test Transmitter
Transmitted Beam
d2
Optical Reference Plane
(Surface of metering device optical port)
Receiver in the
metering device
d1
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
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.
5. The light levels defined in Section 4.8.3, Light Levels, shall be met.
31
ANSI C12.18 – 2005
INFORMATIVE
32
ANSI C12.18 – 2005
INDEX
C12.18 CLIENT (HANDHELD) C12.18 DEVICE (METER)
AND
CHANNEL
LAYER 7 LAYER 2 LAYER 2 LAYER 7
DIRECTION
33
ANSI C12.18 – 2005
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
<nbr-packets> = 04 (4 packets)
<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
<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 00 00 00 0001 20 13 10
2) Å 06
3) Å EE 00 00 00 0005 00 00 02 00 00 C6 B5
4) Æ 06
5) Æ EE 00 20 00 0005 61 0040 04 08 8A 5F
6) Å 06
7) Å EE 00 20 00 0005 00 0040 04 08 7D F5
8) Æ 06
9) Æ EE 00 00 00 000D 50 1111 0102030405060708090A CA 33
10) Å 06
11) Å EE 00 00 00 0001 00 11 31
12) Æ 06
13) Æ EE 00 20 00 0015 51
0102030405060708090A0B0C0D0E0F1011121314 86 27
14) Å 06
15) Å EE 00 20 00 0001 00 80 51
16) Æ 06
17) Æ EE 00 00 00 0008 3F 0000 000010 0096 B0 7F
18) Å 06
19) Å EE 00 C0 02 0038 00 0096
0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C
1D1E1F202122232425262728292A2B2C2D2E2F303132333435 BA 8E
20) Æ 06
21) Å EE 00 A0 01 0038
363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F5051
52535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D
F0 47
22) Æ 06
23) Å EE 00 80 00 002A
6E6F707172737475767778797A7B7C7D7E7F80818283848586878889
8A8B8C8D8E8F90919293949596 C3 BD B1
24) Æ 06
25) Æ EE 00 20 00 0001 52 17 20
26) Å 06
27) Å EE 00 20 00 0001 00 80 51
28) Æ 06
29) Æ EE 00 00 00 0001 21 9A 01
Figure B-1: Packet Transmission Example
35
ANSI C12.18 – 2005
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
ID state
Negotiate
Wait
Terminate
Logon
Session state
Read
Write
Security
Wait
Terminate
Logoff
38
ANSI C12.18 – 2005
ANNEX D - Compatibility
INFORMATIVE
1996 2005
2 1
1996 2005
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.
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.
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:
…
<security> ::= 51H <password>
…
The response <ok> 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 <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
INFORMATIVE
(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:
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:
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
42