Moise

Introduction to TDL and EDL for Use by AMI
Systems Deployed with ANSI C12.19 Tables

and ANSI C12.22 Networks
Presented
by
Avygdor Moise, Ph.D.
Future DOS Research & Development Inc.
Enablers of plug & play AMI solutions that work
303-6707 Elbow Drive SW,
Calgary, Alberta,
Canada T2V 0E5
Tel: +1-403-616-8634
Fax: +1-403-203-7071
e-mail: avy@fdos.ca
web: http://www.fdos.ca
Presentation Outline
› Overview of StandardAMI™
Ø Definitions
Ø ANSI C12.22 StandardAMI Network™ communication
architecture C1219TDL.xsl SiteData.xml AMR System
Ø ANSI C12.19 Tables' structure C1219TDLSchema.xsd
›
Input Data
ANSI C12.19 syntax Registrar

C1219TDL-2008.xml
Ø Published Table definition syntax C1219EDL-2008.xsd

Import/Export Data
ExportData.xml
DefaultSet.xml
Ø Table elements and constants values used to AMR Application
describe metering device instances Vendor-TDL.xml(.a.b.c.d)
Ø Table Definition Language (TDL) Vendor Vendor-EDL.xml(.a.b.c.d) Remote User Application
Ø Exchange Data Language (EDL) Vendor-EDL.xsd
Ø Documents used to register an End Device's Registrar Vendor-Doc.pdf

data model Registry
› By-products and benefits derived from
registering an ANSI C12.19 data model using TDL and EDL
› Q&A
Provider
Root Security
Mechanism
ApTitle
C12R
Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.
2 Device
Class
www.fdos.ca
Definitions: AMI
› Advanced Metering Infrastructure (AMI)

Ø Advanced Metering1: “Advanced metering is a metering system that records customer consumption [and
possibly other parameters] hourly or more frequently and that provides for daily or more frequent transmittal of
measurements over a communication network to a central collection point.”
Ø Advanced Metering Infrastructure: “AMI is defined as the communications hardware and software and
associated system and data management software that creates a network between advanced meters and utility
business systems and which allows collection and distribution of information to customers and other parties
such as competitive retail providers, in addition to providing it to the utility itself.”
› Time-based pricing and demand response (DR)
Ø Demand Response1: “The planning, implementation, and monitoring of activities designed to encourage
customers to modify patterns of electricity usage, including the timing and level of electricity demand. DR
covers the complete range of load-shape objectives and customer objectives, including strategic conservation,
time-based rates, peak load reduction, as well as customer management of energy bills.”
Ø Demand Response2: “Changes in electric usage by end-use customers from their normal consumption patterns
in response to changes in the price of electricity over time, or to incentive payments designed to induce lower
electricity use at times of high wholesale market prices or when system reliability is jeopardized.”
1. U.S.
Federal Energy Regulatory Commission (FERC). Provider
Security
2. North American Electric Reliability Corporation (NERC)
Root
ApTitle
Mechanism
C12R
3 Device
Class
www.fdos.ca
Definitions: Time of Use
› Time of Use
Ø Time-Based Rate: “A retail rate in which customers are charged different prices for different times during the
day. Examples are time-of-use (TOU) rates, real time pricing, hourly pricing, and critical peak pricing.”
Ø Time-of-use (TOU) Rate: “A rate with different unit prices for usage during different blocks of time, usually
defined for a 24 hour day. TOU rates reflect the average cost of generating and delivering power during those
time periods. Daily pricing blocks might include an on-peak, partial-peak, and off-peak price for non-holiday
weekdays, with the on-peak price as the highest price, and the off-peak price as the lowest price.”
Ref: Ontario Energy Board
SUMMER
ON PEAK
MID PEAK
OFF PEAK
WINTER
ON PEAK
MID PEAK
OFF PEAK
00:00 01:00 0200 03:00 04:00 05:00 06:00 0700 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 00:00
Provider
Root Security
Mechanism
ApTitle
C12R
4 Device
Class
www.fdos.ca
Definitions: Load Control
› Load Control
Ø Premise Device/Load Control Interface or Capability: “The ability of the AMI network to communicate directly
with a device located on the premises of the ultimate customer, which may or may not be owned by the utility.
These might include a programmable communicating thermostat or a load control switch.”
Ø Direct Load Control: “A DR activity by which the program operator remotely shuts down or cycles a customer’s
electrical equipment (e.g. air conditioner, water heater) on short notice. Direct load control programs are
primarily offered to residential or small commercial customers”.
› Remote Disconnect
Ø Remote Connect/Disconnect: “The ability to physically turn on or turn off power to a particular billing or revenue
meter without a site visit to the meter location.”
Provider
Root Security
Mechanism
ApTitle
C12R
5 Device
Class
www.fdos.ca
Definitions: Performance
› Quality of Service
Ø Power Quality Monitoring: “The ability of the AMI network to discern, record, and transmit to the utility instances
where the voltage and/or frequency were not in ranges acceptable for reliability.”
› According to NERC…
Ø Reliability: “The degree of performance of the elements of the bulk electric system
that results in electricity being delivered to customers within accepted standards and
?
in the amount desired. Reliability may be measured by the frequency, duration, and
magnitude of adverse effects on the electricity supply.”
Ø Adequacy: “The ability of the electric system to supply the aggregate electrical
demand and energy requirements of the customers at all times, taking into account
scheduled and reasonably expected unscheduled outages of system elements.”
Ø Security: “The ability of the electric system to withstand sudden disturbances such
as electric short circuits or unanticipated loss of system elements.
Ø Bulk Electric System: “The portion of an electric utility system that encompasses the electrical generation
resources, transmission lines, interconnections with neighboring systems and associated equipment, generally
operated at voltages of 100 kilovolts or higher.”
Provider
Root Security
Mechanism
ApTitle
C12R
6 Device
Class
www.fdos.ca
Definitions: Audit
› Event Loggers3
Ø Event Loggers for Electricity Metering Devices and Systems that have a “configuration capability, but access is
controlled by a software switch as a minimum.”
Ø “An event logger is required to secure sealable parameters that are accessible through the configuration
capabilities and access to the configuration capability must be controlled by a software switch as a minimum.”
Ø The event log is: “protected from alteration, modification, replacement, substitution, and unauthorized erasure,
seizure or deletion.”
Ø Downloaded event logs must be: “subjected to the same integrity and security
requirements as that of the original (embedded) log… (and) downloading shall
not result in erasure, or loss of the information in the remote event log.”
Ø It is not be possible to: “reprogram the device or download the event log without
creating an entry in the event log and it shall not be possible to create an entry in
the event log without reprogramming the device or downloading the event logger.
These requirements apply in all circumstances including deliberate attempts to
disable the event logger.”
Ø Downloadable Signed Event Logger: (for details see) “Audit Trail Implementation Guide for MC C12.19 (ANSI
C12.19 /IEEE 1377, Utility Industry Standard Tables).”
3.
Measurement Canada, IS-E-01-E, 2003
Provider
Root Security
Mechanism
ApTitle
C12R
7 Device
Class
www.fdos.ca
Definitions: LUM
› LUM: Legal Unit of Measure
› UOM: Physical Unit of Measure
› The calculation of LUM4 and time-related demand may be performed outside an approved
meter, through generic computer billing systems5.
The accuracy of time-related demand calculation is dependent on the security and integrity of the commodity
consumption data provided by telemetering systems.
There is a need to safeguard the security and integrity of the consumption data being transported outside an
approved meter.
LUMs calculated outside of an approved and verified meter shall be capable of being validated.
› LUMs fall into two categories:
Ø Source LUM (SLUM): “An approved and verified legal unit of measure extracted from an
approved and verified meter. Examples: Wh, VARh, VAh, joule, W, Var, VA.”
Ø Processed LUM (PLUM): “A legal unit of measure that has been derived outside an
approved and verified meter from one or more SLUMs, recognized unit of measure,
metrology constants or multipliers (as applicable), through a mathematical algorithm.”
4. Established Legal Units of Measurement (LUM) for time-related demand outside an approved meter as well as establishment of methodologies
pertaining to the determination of VA demand and VA-hour energy.
5.
Draft Recommendations for Establishing Electricity LUM Outside an Approved Meter, Measurement Canada, 2007
Provider
Root Security
Mechanism
ApTitle
C12R
8 Device
Class
www.fdos.ca
ANSI C12.19 + ANSI C12.22
Performance Expectation
› Support Advanced Metering Infrastructure
› Support Time-based pricing and Demand Response
› Support Load Control and Remote Disconnect
› Support Quality of Service and Reliability
› Support Security
› Support Secured Audit System and Event Logs
› Support External Calculation that are secured, validated and traceable
to the source
› Support the exchange of meaningful and actionable information
› Provide common understanding of the meaning of information
› Achieve industry-wide, nation-wide and world-wide interoperability
Provider
Root Security
Mechanism
ApTitle
C12R
9 Device
Class
www.fdos.ca
Using Standards
ANSI C12.19 + ANSI C12.22 + IEC 61850
to Meet the Totality of Requirements
Provider
Root Security
Mechanism
ApTitle
C12R
10 Device
Class
www.fdos.ca
Meter Communication in a Multitude of
Network and Media
› AMI Network: IEEE 1703 / ANSI C12.22 (OSI Layer 7 Services)
› AMI Payload: IEEE 1377 / ANSI C12.19 (OSI Layer 7 Data) C&I Building Energy
› AMI to Any-network Comm. Module: IEEE 1703 / ANSI C12.22

Management Systems
(OSI Layer 1-4) + IEEE 1704 Mechanical

› AMI to Substation Automation: IEEE 1703 /
ANSI C12.22 Comm. Module
Gateway + IEC 61850
› AMI Local-port End-device AMI Network Substation Automation
Configuration: IEEE 1703 / ANSI & SCADA IEDs
C12.22 Local Port
› AMI Network-Segment to Network
Segment Route management: IEEE 1703 /
ANSI C12.22 Relay
› AMI Network Management, Emergency Response, Residential Metering
Utility System Access, User Access: IEEE 1703 /
ANSI C12.22 Master Relay, Authentication Host and
Notification Host AMI Interface
Provider
Root Security
Mechanism
ApTitle
C12R
11 Device
Class
www.fdos.ca
Flashback… CEBus Architecture
1990’s CEBus architecture ISO Open Systems ANSI/IEA-600 Model and
CEBus is based on the OSI Interconnection ANSI C12.19 over ANSI
“Reduced Stack” model which Model C12.22
includes only four of the seven APPLICATION APPLICATION
Layer System Management

layers:
PRESENTATION
› Application Layer
› Network Layer SESSION
› Data Link Layer TRANSPORT
› Physical Layer NETWORK NETWORK
Most functions of the Transport, DATA LINK DATA LINK
Session and Presentation Layers
have been added either in the PHYSICAL PHYSICAL
Application Layer or the Network
Layer. CEBus also include a Layer TWISTED PAIR
System Management element that POWER LINE
resides beside all four layers. COAX

FIBER OPTIC
INFRARED
RF
Provider
Root Security
Mechanism
ApTitle
C12R
12 Device
Class
www.fdos.ca
Flashback… IEC/TC57 Reference
Source: UCA Users Group, Power Point Presentation, Kay Clinard, IEC 61850 TC57 Scope, 2001.
Provider
Root Security
Mechanism
ApTitle
C12R
13 Device
Class
www.fdos.ca
IEC61850 Substation Architecture
Station Bus - 10/100/1000 MB Ethernet
IEEE 1703 / ANSI C12.22 Gateway
AMI Network
Source: IEC 61850 Communication Networks and Systems In Substations: An Overview for Users, by
Drew Baigent, Mark Adamiak (GE Multilin) and Ralph Mackiewicz (SISCO, Inc.), SIPSEP 2004.
Provider
Root Security
Mechanism
ApTitle
C12R
14 Device
Class
www.fdos.ca
StandardAMI™
AMR Functionality: AEIC Guidelines –Compliance certification requirements
MC IS-E-01 –Event loggers for metering devices and systems
Data Representation: IEEE 1377 / ANSI C12.19 –Binary raw data, EDL/XML Data, TDL knowledge
Communication: IEEE 1701 / ANSI C12.18 –Point to point (ANSI Type II, “snicker net”)
IEEE 1702 / ANSI C12.21 –Telephone modem (pots)
IEEE 1703 / ANSI C12.22 –One-Way, Two-Way Any Network
IEEE P1704 –Communication Module for interoperability
AMR Functionality AEIC / MC / AMI Guidelines Utility Compliance Requirement for ANSI C12 Standards
Data Representation IEEE 1377/ANSI C12.19 Utility Industry End Device Data Table
IEEE 1701/ IEEE 1702/ IEEE 1703/

ANSI C12.18 ANSI C12.21 ANSI C12.22
Protocol Protocol Protocol
Specification Specification Specification for
Transfer Protocol for ANSI Type 2 for telephone Interfacing to
optical port MODEM Data
communication Communication
Networks
IEC 61850
Mechanical Physical Port Telephone ANSI OP
Type 2 IEEE 1704/3 Comm. Module
Local Any-Net (two-way IEC 61850
& one-way & Blurts)
Provider
Root Security
Mechanism
ApTitle
C12R
15 Device
Class
www.fdos.ca
Additional Standards Required
› ISO/IEC Standard 62056-62-2001 (OBIS/COSEM) incorporates the ANSI C12.19 Data (Tables)
Model.
› IEC 61850 Communication Networks and Systems In Substations can (should) be
implemented side-by-side or underneath the ANSI C12.19 Architecture at the AMI level
Ø Common Data Classes can be mapped into C12.19 Elements and Final Elements.
Ø Logical Nodes can be mapped into ANSI C12.22 Nodes, “mail boxes” and C12.19 Devices.
Ø Specific Communications Service Mappings and Ethernet transport can be mapped to ANSI C12.22
communication services.
ØThis is not to say that any generic ANSI C12.22 should be used instead of IEC 61850.
ØThis is to say that once the sub-station real-time SCADA requirements are met through the
deployment of IEC 61850 over Ethernet, it is best integrated with the upstream Enterprise AMI
using a system-wide implementation of ANSI C12.19 over ANSI C12.22 that meets the totality of
requirements.
› ITU-T Rec. X.237 bis | ISO/IEC 15955, Connection-less ACSE implemented by ANSI C12.22.
› ITU-T Rec. X.227 bis | ISO/IEC 15954, Connection-mode.
› ITU-T X.680 | ISO/IEC 8824, Abstract Syntax Notation One.
› ITU-T X.690 | ISO/IEC 8825, ASN.1 Encoding Rules.
› IANA, Internet Assigned Numbers Authority, registered TCP/UDP port 1153: C1222 ACSE.
Provider
Root Security
Mechanism
ApTitle
C12R
16 Device
Class
www.fdos.ca
The Application Layer is the Key
The application layer of the OSI model is the level of the system
that is visible to the user application. The procedures defined
within this layer deliver to the user’s application the services
needed to process data.
› IEEE 1377 / ANSI C12.19 defines in detail the data model
(End-device Classes), but only provides guidance to
implementers about the services needed to interact with 7
object instances End-device Classes. APPLICATION
› IEEE 1377 / ANSI C12.19 shares this layer with Layer 7,6,5
PRESENTATION 6
(services) of the IEEE 1703 / ANSI C12.22 to form the core
communication language. 5
SESSION
› To avoid confusion we refer to the IEEE 1377 / ANSI C12.19
portion of the Application Layer as the Application Process TRANSPORT 4
and IEEE 1703 / ANSI C12.22 portion of the Application
Layer as the Application Language (ACSE+EPSEM). NETWORK 3
› Parameter translation is needed when mapping between
the Application Process to/from Application Language to DATA LINK 2
realize its service requests and responses.
PHYSICAL 1
Provider
Root Security
Mechanism
ApTitle
C12R
17 Device
Class
www.fdos.ca
An IEEE 1703 / ANSI C12.22 Node
C12.22 Node
C12.19 Device
Application C12.22 Node: “A point on the (AMI) network that attaches to a
Process C12.22 Network Segment. C12.22 Nodes contain one or more
Layer (7-5) C12.22 Applications. Each C12.22 Node shall have a unique
Tables
ApTitle on a C12.22 Network.”
EPSEM C12.19 Device: “A C12.22 Node that contains (IEEE 1377 / ANSI
ACSE
C12.19) Tables.”
C12.22 Application: An application entity that implements a set of
Local Port Layers (1-4)
services and procedures that permit one or more devices to
Connection interact within the AMI framework of a C12.22 Network. A
To Native C12.22 Application Process may contain C12.19 Tables.
Network
Interface C12.22 Network Segment: “A collection of C12.22 Nodes that
can communicate with each other without forwarding
messages through a C12.22 Relay.”
C12.22 Network Segment
Provider
Root Security
Mechanism
ApTitle
C12R
18 Device
Class
www.fdos.ca
…An IEEE 1703 / ANSI C12.22 Node
C12.22 Node
C12.22 Relay: “A C12.22 Node that provides address resolution,
C12.19 Device Datagram segmentation and optionally Message forwarding
Application services to other C12.22 Nodes (which may be located on the
Process different C12.22 Network Segments).”
Layer (7-5)
Local Port: “A physical interface that is directly attached to the
Tables
EPSEM
C12.22 Node; or a physical interface that is located in the
ACSE immediate vicinity of the C12.22 Node and attached to it by
means of a dedicated short signal path (e.g. cable). The main
purpose of the Local Port is to provide direct access to the
Local Port Layers (1-4)
Application Process of the C12.22 Node…”
Connection Native Network: Not defined by IEEE 1703 / ANSI C12.22.
To Native
Network A transport service that can be used deliver C12.22 Message
Interface payloads. Example: TCP, UDP, ZigBee, BACNet, DNP,
LONWorks, DLMS…)
C12.22 Network Segment
Provider
Root Security
Mechanism
ApTitle
C12R
19 Device
Class
www.fdos.ca
Nodes, Devices and Comm. Modules
C12.22 Nodea C12.22 Devicea C12.22 Comm. Modulea
Native
OSI Layer Network
Defined Generic AMI Node Local Port on the Node Device Side Side
Layer 7 C12.19 + EPSEM + ACSE C12.19 + EPSEM + ACSE C12.19 + EPSEM + ACSE Defined Not Defined
b (Register,
Segmentation Sub-layer Segmentation Sub-layer Segmentation Sub-layer
Resolve)c
Layer 6 Not Defined Null Null Null Not Defined

Layer 4 Not Defined Defined Defined Defined Not Defined
d
only for ANSI Type 2
a. If it contains Tables then it is also a C12.19 Device.

b. Guarantees delivery of arbitrarily large messages over any native network.
c. These services are on behalf (the identity of) the C12.22 Device. A C12.22 Comm. Module may also have an independent presence on the
AMI Network by instantiating its own instance of Layer 7 of an C12.22 Node.
d. Provide backward compatibility with ANSI C12.18 (R2006).
Provider
Root Security
Mechanism
ApTitle
C12R
20 Device
Class
www.fdos.ca
Connecting Nodes to Comm. Modules
C12.22 Node
C12.22 Device C12.22 Comm. Module

C12.19 Device C12.22 Communication Module
Application Application Application
Layer (7-5) Layer (7-5) Layer (7-5)
C12.22 Dev.
Local Port C12.22 EPSEM of Native
C12.19 Tables
C12.22 EPSEM C12.22 ACSE Network
C12.22 ACSE (Auto Register,
Resolve)
Layers (1-4) Layers (1-4) Layers (1-4)

of Native
C12.22 Layer 4 C12.22 Layer 4 Network
C12.22 Layer 2 C12.22 Layer 2
C12.22 Layer 1 C12.22 Layer 1 C12.22 Layer 4
C12.22 Layer 2
C12.22 Layer 1
C12.22 Device to C12.22 Comm. Module Connector C12.22 Network Segment

Provider
Root Security
Mechanism
ApTitle
C12R
21 Device
Class
www.fdos.ca
Functional Requirements of Any
Comm. Module
› Implement layers 1 through 4 of ANSI Standard C12.22 on the C12.22 Device interface side.
› Implement layers 1 to 7 on the network side as needed.
› Implement the TLS6 Negotiate service to maximize packet sizes at start-up.
› Implement TLS Link Control service recognition of RELOAD_CONFIG_FLAG parameter.
› Optionally implement the TLS Get Configuration service at start-up and upon receipt of a
Link Control service requests with RELOAD_CONFIG_FLAG set.
› Honor all directives received following the invocation of the TLS Get Configuration service.
› Implement emission of empty packets to enable the attached C12.22 Device to detect the
presence of the C12.22 Communication Module.
› Unless specifically addressed to the C12.22 Communication Module (and permitted by the
C12.22 Device)
Ø forward all incoming datagrams from the C12.22 Network to the C12.22 Device, and
Ø forward all incoming datagrams from the C12.22 Device to the C12.22 Network.
6.
Transport Layer Service (TLS) of OSI Layer 4, the Transport Layer.
Provider
Root Security
Mechanism
ApTitle
C12R
22 Device
Class
www.fdos.ca
…Functional Requirements of a
Comm. Module
› Implement the capability to register (associated) the C12.22 Device on the C12.22 Network.
› Implement the capability to manage (keep alive) the C12.22 Registration on behalf of the
C12.22 Device.
› Implement datalink level routing in support of data-link packet forwarding to Local Ports or
other C12.22 Communication Modules that are attached to its local C12.22 Device.
› Physical Interface shall be a 6-wire RJ11 Jack (typical part AMP520250-2 for both
the C12.22 Device and C12.22 Communications Module as per ANSI/TIA-968-A-2002). Front View
› The physical interface signals (ANSI C37.90.1-2002, ANSI C62.41-2002)
C12.22 Device C12.22 Comm.
Pin # Signal Function (DTE) Module (DCE) Performance 1 2 3 - 5 6
1 RxD Receive Data Input Output 256 kbits/seca
2 TxD Transmit Data Output Input 256 kbits/seca
3 RESET Comm. Module Reset Output Input >50 ms
4 HSCD High-speed cable detect Input Input >256 kbits/seca
5 VPLUS Comm. Module Power Output Input 1.5W at 5-12Vdc max. 1m @ 256kbits/sec.
6 GND Common Ground Common Ground Common Ground
a. 256kbits/sec up to 1m, or up to 4Mbits/sec with high-speed cable.
Provider
Security
Root Mechanism
ApTitle
C12R
23 Device
Class
www.fdos.ca
Pre-assigned C12.22 Node Local Ports
Local Port Number Description
0 The C12.22 Application of the C12.22 Node.
1 Default Local Port. (for local access and configuration)
2 Alternate Local Port (for local access and configuration)
3 Default LAN/WAN interface (interface 0).
4 Alternate LAN/WAN interface (interface 1).
5 Default POT MODEM (interface 2)
6 Alternate POT MODEM (interface 3)
7-12 Reserved.
13-28 Manufacturer Assigned
29 Reserved (to avoid confusion with start of packet).
30-31 Reserved for future expansion.
Provider
Root Security
Mechanism
ApTitle
C12R
24 Device
Class
www.fdos.ca
Getting a Meter on the AMI Network
5 Utility
Service Verification Notification
C12.22 3 UTILITY PWR Outage BILLING
Master Relay Authentication Host Notification Host Notification Host
4 Approve registration
WAN
2 Broadcast registration request
6 Registration complete, Appliance is on-line
C12.22 C12.22
Relay Relay
1 Power-up appliance
Provider
Root Security
Mechanism
ApTitle
C12R
25 Device
Class
www.fdos.ca
Getting a Host on the AMI Network
5 Utility
Service Verification Notification
C12.22 3 Service Provider Peer Application Supervisory
4 Approve registration
WAN
2 Broadcast registration request to be associated on the AMI Network
6 Registration complete, granted access to AMI network
C12.22 C12.22
Relay Relay
1 Start-up
Client Application
Host
Provider
Root Security
Mechanism
ApTitle
C12R
26 Device
Class
www.fdos.ca
About: C12.22 AMI Relays and Gateways
› But first about Networks…
Ø C12.22 Network: An AMI communication network that is composed of C12.22 Network Segments
interconnected using C12.22 Relays.
Ø A C12.22 Network includes at least one C12.22 Master Relay.
› Now about relays
Ø C12.22 Master Relay: “A C12.22 Relay that operates at the top of a hierarchy of
relays. It provides registration services of all devices in its domain. It is also
responsible for issuing registration service queries to C12.22 Authentication Hosts
and De-registration service requests and notifications to C12.22 Notification Hosts
when registering a C12.22 Node.”
Ø C12.22 Gateway: “A C12.22 Node that translates the ANSI Standard C12.22
protocol to/from other protocols.”
Ø C12.22 Relays bridge between network segments, therefore they are hardware
solutions.
Ø C12.22 Master relays provide network administration functions, therefore they are
software solutions.
Ø C12.22 Gateways may be simple C12.22 Nodes (if they do not need to bridge across network segments)
otherwise the need to implement a C12.22 Relay.
Ø A C12.22 Relay has at least two physical points of presence on the AMI Network.
Ø A C12.22 Gateway and A C12.22 Master Relay have at least one physical point of access on the AMI Network.
Provider
Root Security
Mechanism
ApTitle
C12R
27 Device
Class
www.fdos.ca
C12.22 Relays Build AMI Networks
C12.22 Node X.2 C12.22 Node X.1 C12.22 Node Y.1 C12.22 Node Y.2
C12.19 Device C12.22 Relay App C12.19 Device

Application Application Application
Layer (7-5) Layer (7-5) Layer (7-5)
C12.19 Tables C12.19 Tables C12.19 Tables

C12.22 EPSEM C12.22 EPSEM C12.22 EPSEM
C12.22 ACSE C12.22 ACSE C12.22 ACSE
Layers (1-4) Layers (1-4) Layers (1-4) Layers (1-4)
To Native To Native To Native To Native

Network Network Network Network
Interface Interface X Interface Y Interface
C12.22 Network Segment X C12.22 Network Segment Y

(e.g.Zigbee) (e.g. Internet)
Provider
Root Security
Mechanism
ApTitle
C12R
28 Device
Class
www.fdos.ca
C12.22 Gateways Bridge AMI Networks
C12.22 Node X.2 C12.22 Node X.1 IEC 61850 Client IEC 61850 Server
C12.19 Device A C12.19 App to IEC 61850 App Gateway

Application Application Application Application
Layer (7-5) Layer (7-5) Layer (7-5) Layer (7-5)
C12.19 Tables C12.19 Tables Map 68150 IEC 68150 App
C12.22 EPSEM C12.22 EPSEM GSSE message MMS or GSSE
C12.22 ACSE C12.22 ACSE to/from C12.19 messages.
Elements
Layers (1-4) Layers (1-4) Layers (1-4) Layers (1-4)
To Native To Native TCP/IP TCP/IP

Network Network Reduced Stack Reduced Stack
Interface Interface X over Ethernet over Ethernet
C12.22 Network Segment X May share the same “wire” Ethernet

(e.g.Internet)
Provider
Root Security
Mechanism
ApTitle
C12R
29 Device
Class
www.fdos.ca
AMI Network Application and Roles
› C12.22 Host: “A C12.22 Node that may be a C12.22 Authentication Host or C12.22
Notification Host or both. A Host typically runs on a computer instead of within an embedded
system” (e.g. a meter, a master station, a client portal, a billing system, an emergency
response application).
Ø C12.22 Authentication Host: “A C12.22 Host that is an authoritative administrative host for a registering
C12.22 Node in the C12.22 Master Relay domain.
The C12.22 Authentication Host may be embedded inside a C12.22 Master Relay or it may be a separate
C12.22 Node on the network.
There may be one or more C12.22 Authentication Hosts operating under the domain of a single C12.22
Master Relay.
Registration with C12.22 Master Relays can only succeed if at least one C12.22 Authentication Host accepts
registration on behalf of a C12.22 Node by a C12.22 Master Relay.”
Ø C12.22 Notification Host: “A C12.22 Host, which contains an application that needs to be notified when
C12.22 Nodes are registered for the first time (“first” here means an actual registration7…”
7. Priorto communicating data, nodes must establish a relationship, or an association, to the network. Only after an association is established can
the node exchange data with another node. The process of establishing or maintaining an association is managed by the C12.22 Registration
service.
Provider
Root Security
Mechanism
ApTitle
C12R
30 Device
Class
www.fdos.ca
StandardAMI™ Topology
C12.22
C12.22 Other
Local Port
Device Device
C12.19 App C12.19 App
C12.22 Comm C12.22
C12.22 C12.22 C12.22 C12.22 Other Module Gateway
Host Master Relay Node Gateway Device
C12.22 Network Segment 1 (Any LAN or WAN)
C12.22 C12.22 C12.22

C12.22 Comm
Local Port Local Port Host (AMR)
Module
C12.19 App
C12.19 App Registry
C12.22
Relay C12.22 C12.19 App Internet Device Class
Device
C12.22 Comm
Module C12.22 Comm C12.22 Comm
C12.22 Module Module C12.19 Registry Server
Node
Provider
ApTitle Server
C12.19 App
C12.22 C12.22
C12.22 Relay Master Relay
Node

Provider
Root Security
Mechanism
ApTitle
C12R
31 Device
Class
www.fdos.ca
C12.22 Messages Realize the
Core AMI Requirements
› C12.22 Message: “Any notice, service request, service response or
device status sent from one C12.22 Node to another C12.22 Node for the
purpose of communication across a C12.22 Network…”
Ø C12.22 Messages are encapsulated in Datagrams.
Ø Messages may be of any length, and independent of the packet-size and timing
constraints that may be imposed by the underlying network.
Ø Reliable transmission of messages does not depend on the ability of the network to
maintain long lasting connections. In fact the shortest connection required has to last
as long as it takes to complete the transmission of a single segment of a message.
Ø Messages are encapsulate in one or more connectionless-mode ACSE PDUs8.
Ø Messages may operate over one-way and two-way networks
› Datagram: “A self-contained, independent entity of application data carrying sufficient
information to be routed from the source Application Layer to the destination Application
Layer.”
8.
Association Control Service Element Protocol Data Units.
Provider
Root Security
Mechanism
ApTitle
C12R
32 Device
Class
www.fdos.ca
Serving Multiple Network Entities and
Application Entities
› A properly functioning AMI network cannot utilize a network-specific addressing scheme.
› ANSI C12.22 uses an addressing scheme that is a property of AMI
only and its subscribers - the ApTitle.
Ø There is no practical limit to the size or range of an ApTitle.
Ø ApTitles may be encoded absolutely or relatively using ISO Absolute and Relative
Universal Identifiers.
Relative ApTitles are not unique within the broad context of a C12.22 Network,
C12.22 Network Segment.
Absolute ApTitles are unique within the broad context of a C12.22 Network and
any of its C12.22 Network Segments.
Root ApTitles form the prefix of relative ApTitle and need to be registered with
the C12.22 Network service provider.
ApTitles may contain Sub-branch (mail-boxes) of a registered ApTitle.
Sub-branches can be used to communicate with Node’s application services.
Sub-branches may be used to provide proxy services by C12.22 Relay for Nodes they service.
Provider
Root Security
Mechanism
ApTitle
C12R
33 Device
Class
www.fdos.ca
…Serving Multiple Applications
Service Provider C12.22 Utility C12.22 PWR Outage C12.22 Billing C12.19 Device Class
Master Relay Authentication Host Notification Host Notification Host Context: 2.16.124.113620.1.19
.100 .100.20 .100.21 .100.22
A C12.22 Network Segment
⎭ C12.22 Application
C12.22 Internet Network Segment Context: 2.16.124.113620.1.22
⎬ AMI
Provider‘s Relative ApTitle Node’s Relative ApTitle C12.22 ApTitle Root Context:
2.16.124.113620.1.22.0
Network C12.22 Security Mechanism

2.16.124.113620.1.22.0.100.21
context:
AMI Physical Network is Transparent Absolute ApTitle of this Node
⎫ 2.16.124.113620.1.22.2
.100.1
C12.22 Internet Network Segment .100.3
C12.22 C12.22
Relay Relay
.200.2 .300.4
C12.22 Wireless Network Segment C12.22 PLC Network Segment
.200.1000 .200.1001 .200.1002 .200.1003 .300.1004 .300.1005 .300.1006 .300.1007
ED Class = .0.1 ED Class = .0.1 ED Class = .0.2 ED Class =.73.84.82.78 ED Class = .0.1 ED Class = .0.1 ED Class = .7.2 ED Class =.71.62.32.3
Sec Mech=.3
= 2.16.124.113620.1.19.73.84.82.78 = 2.16.124.113620.1.22.2.3
Provider
Root Security
Mechanism
ApTitle
C12R
34 Device
Class
www.fdos.ca
…A C12.22 Network is Actually Very
Simple
Master Relay
C12.22 Network Segment 1
⎫
C12.22 Network
Bridge Host Node
⎬
Relay
⎭
Router
Host
C12.22 Network Segment 2
Node Node Node Host

Node Node
Provider
Root Security
Mechanism
ApTitle
C12R
35 Device
Class
www.fdos.ca
Serving Multiple Organizations
Provider 100 C12.22 UTILITY 1 C12.22 PWR Outage C12.22 Utility 1 AMR
.100 .100.20 .100.21 .100.22
Register with .100 if willing to accept .100 access for .200 network
segment.
AMI Forward resolutions to all but .100.1006 destinations to .100
Network Provider 200 C12.22 Utility 2 C12.22 Utility 2 AMR
Master Relay Authentication Host Notification Host
.200 .200.20 .200.22
.100.1 .200.1
C12.22 C12.22
Relay .200.1000 registers with .200.2, Relay .100.1006 registers with .200.2
which registers with .200 which registers with .200,
.100.2 .200.2 which registers with .100
.100.1000 .100.1001 .100.1002 .100.1003 .200.1000 .200.1001 .100.1006 .200.1002
Provider
Root Security
Mechanism
ApTitle
C12R
36 Device
Class
www.fdos.ca
Supporting One-way Devices
› The C12.22 Standard supports two types of one-way messages in support of one-way
communication
Ø Unsolicited C12.22 Network messages to (from) the C12.22 Network from (to) any node on the C12.22
Network.
Ø Unsolicited or triggerable9 short messages (“blurts” or <short-pdu>s) on a C12.22 Network Segment.
› Standard one-way messages may be issued by any node on the C12.22 Network.
› “Blurts” may only be communicated between
Ø Cooperating nodes on a single C12.22 Network Segment (Example: C12.19 Meter and a Data Concentrator),
or
Ø C12.22 Device and its C12.22 Communication Module (Example: a C12.19 Meter and its wireless
communication interface).
Ø Ultimately it is the responsibility of the C12.22 Communication Module to translate the “blurts” to/from C12.22
Network messages (Example: If a pole-top data concentrator collects blurts from devices then the meters may
send out blurts, the data concentrator will collect the blurt, then convert them to fully blown C12.22 Messages
when transmitting to an upstream host that resides on the C12.22 Network.
9.
Example for use in drive-by AMR.
Provider
Root Security
Mechanism
ApTitle
C12R
37 Device
Class
www.fdos.ca
10
One-way Message vs. Blurt
C12.22 Network Message C12.22 Blurt
60 2E <acse-pdu>
A2 05 <called-AP-title-element>
80 03 17 A1 21 <called-AP-title>=.23.4257
A6 05 <calling-AP-title-element>
80 03 17 A3 54 <calling-AP-title>=.23.4567 17 A3 54 <calling-AP-title>=.23.4567
A7 03 <calling-AE-qualifier-element>
02 01 04 NOTIFICATION = "true"
A8 03 <calling-AP-invocation-id-element>
02 01 03 <calling-AP-invocation-id>=3
BE 14 <user-information-element>
28 12 <user-information-external>
81 10 <user-information-octet-string>
90 <epsem-control>
14 00 00 00 <ed-class>=.20.0.0.0 14 <ed-class>=.20.0.0.0
0A <service-length>
40 <full-write> 40 <full-write>
00 03 <tableid>=Std Table 3 00 03 <tableid>=Std Table 3
00 04 <count>=4 bytes 00 04 <count>
00 08 00 00 ANSI C12.19 <data> 00 08 00 00 ANSI C12.19 <data>
F8 <cksum> F8 <cksum>
Total bytes transmitted = 47 Total bytes transmitted = 14
10. It is not the intent of the presenter to dwell into the depths of the ANSI C12.22 or ANSI C12.19 protocols, as this is the subject-matter of another
course.
Provider
Root Security
Mechanism
ApTitle
C12R
38 Device
Class
www.fdos.ca
Managing Authenticity, Reliability and
Audit-Trail
Provider
Root Security
Mechanism
ApTitle
C12R
39 Device
Class
www.fdos.ca
C12.19+C12.22 Security Capability
› The core of the Standard’s security model is based on the assumption that the underlying
network transport protocol (below the C12.22 Network) does not provide for security.
› The Standard’s security model guarantees full interoperability across any network.
› Security in this context covers the following elements:
Ø Perimeter Security: Provides the means to control access to the C12.22 Network so that only legitimate users
and information can pass through the C12.22 Network.
Ø Data Privacy: Provides the means to protect the information from eavesdropping, and to provide
authenticated, confidential communication.
Ø Identity: Provides for the reliable and accurate identification of the C12.22 Network users, hosts, applications,
services, and resources.
Ø Monitoring: Provides the means to detect and report intrusion and/or alteration to the information transmitted
over the C12.22 Network and the information stored in the user’s data management systems.
Ø Policy Management: While AMI Network and AMR requirements vary from utility-to-utility, state-to-state and
country-to-country, the Standards provide the means to manage the security policy, interoperability, to meet or
exceed local security needs; and to meet the needs of an ever growing network.
Ø Evolution Management: Provides for managing change in order to prevent
misinterpretation of the meaning of information exchanged.
› ANSI C12.19 and ANSI C12.22 should be used together to achieve an effective, interoperable
security for AMI.
Provider
Root Security
Mechanism
ApTitle
C12R
40 Device
Class
www.fdos.ca
…Perimeter Security
› Perimeter security is maintained through the use of the C12.22 Registration Service.
› A C12.22 Node cannot have a presence on a C12.22 Network unless:
Ø The applying node can find a path to a C12.22 Master Relay in order to be registered
(associated with the network), and
Ø the C12.22 Master Relay is granted permission from a C12.22 Authentication Host to
register the applicant, and
Ø the C12.22 Master Relay is willing to register the applicant, and
Ø all C12.22 Relays that lay between the registering node and its peers agree to
service the applying node, and
Ø the data encoded by the registering node is authenticated by the C12.22
Authentication Host using information that is not transmitted over the network, alternatively
Ø encryption services are possible for the paranoid AMI implementation, but this may break interoperability
among C12.22 Relays, Master Relays and Notification Hosts.
› Initial configuration of C12.22 Nodes is possible through C12.22 Local Ports.
› Source and target ApTitle filtering11 is provided to prevent relaying and DOS12 attacks on a
per-interface basis at the C12.22 Network Segment level.
11.
Typically implemented by C12.22 Relays.
12.
Denial of Service (DOS)
Provider
Root Security
Mechanism
ApTitle
C12R
41 Device
Class
www.fdos.ca
…Data Privacy and Access
› AMI data privacy is protected at two levels:
Ø By the C12.22 Network.
Ø By the C12.19 Device security tables.
› The C12.22 Network data privacy is supported through strong data
encryption.
Ø The encryption protocol does not impact on the ability of C12.22 Relays to propagate the C12.22 Message to
its destination.
Ø The encryption protocol does not require the C12.22 Relays to understand the content of the message.
Ø The encryption protocol does not prevent segmentation/reassembly of the C12.22 Message.
Ø The encryption protocols used by C12.22 Node are:
Data Encryption Standard with Cipher Block Chaining (DES/CBC), or
triple DES with Cipher Block Chaining (DESede/CBC), or
AES128/CTR, or
externally defined (as per registered security mechanism).
› In the context of an ANSI C12.19 standard device
Ø Tables may be password protected, and
Ø accessible table elements that are considered “sensitive” may not be transmitted in plain text (for example one
may not be able to retrieve the actual passwords from a compliant ANSI C12.19 Device).
The above rule is applicable if when using other communication protocols, such as ANSI C12.18 or ANSI
C12.21.
Provider
Root Security
Mechanism
ApTitle
C12R
42 Device
Class
www.fdos.ca
…Access to Table Data is also Role-based
Decade 4 - Security Tables
Table 40 - Dimension Table 43 - Default Table 44 - Access

Security Limiting Access Control for Control for table and
Table 41 - Actual
table and group group
Security Limiting
Table 00 - General
4
Table 42 - Security
Configuration
permission
3
2 Table 45 - Key
and (C12.18 or C12.21)
Define/Validate
group association
5
Table 46 - Ext. Key
(C12.22)
Request Granted
1
ANSI C12.22 Network
access, authentication and
encryption validated ok.
Provider
Root Security
Mechanism
ApTitle
C12R
43 Device
Class
www.fdos.ca
…Table Data Privacy is Role-based
Annotations:
Note: Some implementers confuse between Authentication and Role-based Security. Role- AMR: Automated meter reading for billing
based security is what is ultimately granted to a user of C12.19 Tables according to Tables 43 purposes.
and 44 after the perimeter and authentication requirements were met. LR: Load Research.
POER:Power Outage Emergency Response.
ANSI C12.19 Tables:

Access Roles setting 00: General Configuration
Table 43 + 44 03: Device Mode Status
ER
R 1= R
e AM
PO
05: Device Identification
e LR
R 0=
2=
Table Number 21: Actual Register Limits

e
23: Current Register Data

ol
ol
ol
R
00
61: Actual Load Profile Limits
Access control 62: Load Profile Control
03
Table 42 63: Load Profile Status
ER
R 1= R
PO
05 64: Load Profile Data Set 1
le AM
e LR
=
R 0=
21 Passwords
2
e
ol
ol
O
23
R
61 r3ad3r
62 r3s3arch3r
63 pow3erman
64 sup3rvisor
Provider
Root Security
Mechanism
ApTitle
C12R
44 Device
Class
www.fdos.ca
…Identity
› ANSI C12.22 provide mechanisms that ensure that all C12.22 Messages can be
authenticated.
› The protocol provides for:
Ø Sessionless-mode Authentication: This authenticates the source of the payload data that arrives
asynchronously outside the confines of a secured session.
Ø Session-mode Authentication: This authenticates the source of the payload data that arrive synchronously
within the confines of a secured session (transaction).
Ø ApTitle Authentication: This provides additional information that enables the recipient to discover whether the
source and target addresses (ApTitle) are authentic (not modified in route)
Ø Backward compatibility mode with ANSI C12.21 protocol.
Ø ESN13 Registration authentication of registering C12.22 Nodes.
13. ElectronicSerial Number (ESN) is the wireless technology serial number which binds a C12.22 Network device to the native (possibly
wireless) network technology which it rides on.
Provider
Root Security
Mechanism
ApTitle
C12R
45 Device
Class
www.fdos.ca
…Security Monitoring
› All operations may be logged and time stamped using the ANSI C12.19 Event and History
loggers.
› Out of bound conditions can trigger the emission of C12.22 exception reports14 to any
number of C12.22 Notification Hosts.
Ø Modification to metrological tables.
Ø Intrusion attempts.
Ø Changes to device operating mode.
› Normal operation-data may be tagged and authenticated so that it is possible to:
Ø Maintain a chain of custody for the AMR for the life of the device.
Ø Validate the source of the AMR data.
Ø Detect off-line tampering with the delivered AMR data.
14.
See ANSI C12.22 Exception Report Tables. These enable delivery of exception reports to specific hosts as needed.
Provider
Root Security
Mechanism
ApTitle
C12R
46 Device
Class
www.fdos.ca
…Security Policy Management
› Security management is confined to the programming of the C12.19
Device
Ø ANSI C12.19 Security Tables
Ø ANSI C12.19 History and Event logger tables need to be implemented.
Ø ANSI C12.19 Network Tables
Ø ANSI C12.19 Exception Report Tables.
Ø ANSI C12.19 Relay Tables.
› A C12.19 Device may be a Meter, Relay, Master Relay, Authentication
Host and Notification Host.
› Each type of C12.19 Device needs to be considered when planning a security policy.
› The implementation of the policy may be simplified when the underlying network provides
significant protection.
› Regardless of the strength of the underlying (native) network one should never delegate the
AMR data security, integrity and traceability (e.g. C12.19 Event Logger) to the native network.
Provider
Root Security
Mechanism
ApTitle
C12R
47 Device
Class
www.fdos.ca
Utility Industry Tables: Device Class.0.2
0 1 2 3 4 5 6 7
Configuration Source Register Display Security Time & Load Profile Event Log
Time-Of-Use
8 9 10 11 12 13 14 15 16
User Defined Telephone Extended Load control RTP Networking Relays Extended Quality of One-way
Source Demand Response User Defined service Devices
Table Data is encoded in binary for transmission, Enterprise data exchange

Data model is defined by the Standard, extensible by vendors and encoded in XML
Provider
Root Security
Mechanism
ApTitle
C12R
48 Device
Class
www.fdos.ca
User Defined Data Models and Blurts
Reading
ED Addr ED Class C12.18 PSEM EUDT Table Write Request n bits
Registered Data Model (token code)
ED Node Relative ApTitle Identifies the reference TDL/EDL files to be obtained from the registry.
TBL 0 TBL 1 TBL 11 TBL 12 TBL 15 TBL 27 TBL 28 TBL140 TBL 141 TBL 143
With EUDT knowledge, Master Station has

information about where the data elements
belong in the Formal data structures in the “virtual
meter”.
Provider
Root Security
Mechanism
ApTitle
C12R
49 Device
Class
www.fdos.ca
Device Class Registration = Information
ED EUDT blurt
Token
Any Network
SRC CL T# Data as EUDT
C12.22 Host
C12.19 Master Stn
C12.19 Tables
Any AMR App HHF EDL

Enterprise Data L
19 T D
C 12. 9 E DL
1
Data C12.19 Encoded C12.
LA S S
f or C
Provider
Root Security
Mechanism
ApTitle
C12R
50 Device
Class
www.fdos.ca
Putting It All Together
C1219TDL.xsl UtilSiteData.xml AMR System
C1219TDLSchema.xsd
Input Data
C1219TDL-2008.xml
Registrar
C1219EDL-2008.xsd ExportData.xml
Import/Export Data
DefaultSet.xml
MDMS Application
Vendor-TDL.xml(.a.b.c.d)
Vendor Vendor-EDL.xml(.a.b.c.d) Remote User Application
Vendor-EDL.xsd
Registrar Vendor-Doc.pdf
Registry
AMI System
Provider
Root Security
Mechanism
ApTitle
C12R
51 Device
Class
www.fdos.ca
…System Evolution Management
3) The registered root ApTitle of the 2) The registered universal identifier of
C12.22 service provider or organization. the security mechanism deployed by the
C12.22 Node.
The network service
provider may deploy When the Mechanism Name
Provider
C12.22 Master Relays Root Security
Security Element is set to
Mechanism
to service the assigned ApTitle 2.16.124.113620.1.22.2 the ANSI
area on behalf of a Standard C12.22 security
utility. ApTitle Root context is mechanism are used (DES/CBC,
2.16.124.113620.1.22.0 DESede/CBC or AES128/CTR). Implicit
Multiple Master Relays can be support is also provided for ANSI C12.21
deployed to link diverse systems. Security Mechanisms.
Device
1) The registered Class universal identifier
of the C12.19 Device Class (data model)
deployed by the C12.19 Host application process.
C12.19 Application device class context is
2.16.124.113620.1.19. This is the Table Object Model.
Provider
Root Security
Mechanism
ApTitle
C12R
52 Device
Class
www.fdos.ca
C12.19 Table Data
Decade No. Decade Name Provides
0 General Configuration C12.19 Device global configuration, control and setup information. Also defines operational
procedures (e.g. Demand Reset)
1 Data Source Describes the data sources, units of measure, scalars and multipliers used throughout.
2 Register (data) Where the actual simple and TOU register data values are placed. AMR starts here.
3 Local Display Provides configuration and control information for local and alternate displays.
4 Security Provides configuration management for the C12.19 Device access security and authentica-
tion key management. Security is Roles based.
5 Calendar Time and Provides for time setup (R2008 has a high precision time), schedule and calendar setting for
Time-of-use autonomous device control and TOU.
6 Load Profile Four independent load-profile recorders. Each may have 1-255 channels.
7 History & Event Logs Used to monitor any system activity and record important events. Also has a secure proto-
col for the management and off-line maintenance of an Audit-trail and traceable metrology
data downloads.
8 User Defined Provides up to 6 simple data collection tables that can aggregate Final Element data from
any table for transmission.
9 Telephone Control See ANSI C12.21-1999 / ANSI C12.19-2008 Telephone Standard
10 Extended Source Similar to Decade 1, provides for more flexibility in source selection and an increase in the
number of source. Decade 1 and Decade 10 are mutually exclusive.
11 Load Control and Pricing Provides support for Load Control, Demand Response costing and Prepayment.
Provider
Root Security
Mechanism
ApTitle
C12R
53 Device
Class
www.fdos.ca
C12.19 Table Data
Decade No. Decade Name Provides
12 Network Control Manages all aspects of Network Access relating to any of ANSI C12.22-2008.
13 Relay Control Provides additional services for C12.22 Nodes that are also C12.22 Relays.
14 Extended User Defined Provides a significant capability to collate Final Elements from any table down to the bit-
level for the purpose of transmission. There may be up to 2040 such convenience tables.
15 Quality Of Service Provides for power quality and wave-form capture services.
16 One Way Devices Provides for configuration management for simple one-way radio devices.
Provider
Root Security
Mechanism
ApTitle
C12R
54 Device
Class
www.fdos.ca
Minimal Requisition Requirements for a
StandardAMI™ Device
a. Utility industry end device data tables
IEEE 1377 / ANSI C12.19-2008, the common data format for StandardAMI™ Devices.
b. Network Protocol for the transmission of Tables
IEEE P1703 / ANSI C12.22-2008, Protocol for Interfacing to Data Communication Networks.
c. Local Optical port access with 100% availability to the operator
Request IEEE P1703 / ANSI C12.22-2008 to facilitate local configuration
management, laboratory testing, audit-trail validation and asset management.
d. Registered data models (Table syntax) using TDL/EDL (xml) for each
C12.19 Device model
Provides machine readable information that enables any AMI system to interface with any
standards-based meter.
e. Register security model when not using a predefined IEEE P1703 / ANSI C12.22-2008
security
f. Register network addresses, nodes and relays
Enables plug-and-play deployment and inter-utility communication that facilitate utility asset
sharing, testing, audit and validation.
Provider
Root Security
Mechanism
ApTitle
C12R
55 Device
Class
www.fdos.ca
ANSI C12.19 Tables
The closest device to

the sensor or control
An within
point End-Device is
a metering
the closest device
application communi-
tosystem
cation the point of is
which
measurement,
compliant with the
which
Utilty holds the
Industry End
Utility Industry
Device Data Tables
Standard Tables
C12.19
Master Station
Provider
Root Security
Mechanism
ApTitle
C12R
56 Device
Class
www.fdos.ca
The ANSI Standards C12 Protocol Suite
AMR Functionality: AEIC Guidelines –Compliance certification requirements
MC IS-E-01 –Event loggers for metering devices and systems
Data Representation: IEEE 1377 / ANSI C12.19 –Binary raw data, EDL/XML Data, TDL knowledge
Communication: IEEE 1701 / ANSI C12.18 –Point to point (ANSI Type II, “snicker net”)
IEEE 1702 / ANSI C12.21 –Telephone modem (pots)
IEEE 1703 / ANSI C12.22 –One-Way, Two-Way Any Network
IEEE P1704 –Communication Module for interoperability
AMR Functionality AEIC / MC / AMI Guidelines Utility Compliance Requirement for ANSI C12 Standards
Data Representation IEEE 1377/ANSI C12.19 Utility Industry End Device Data Table
IEEE 1701/ IEEE 1702/ IEEE 1703/

ANSI C12.18 ANSI C12.21 ANSI C12.22
Protocol Protocol Protocol
Specification Specification Specification for
Transfer Protocol for ANSI Type 2 for telephone Interfacing to
optical port MODEM Data
communication Communication
Networks
IEC 61850
Mechanical Physical Port Telephone ANSI OP
Type 2 IEEE 1704/3 Comm. Module
Local Any-Net (two-way IEC 61850
& one-way & Blurts)
Provider
Root Security
Mechanism
ApTitle
C12R
57 Device
Class
www.fdos.ca
ANSI Standard C12 Transport Protocols
ANSI Std. C12.19 End-Devices
Which contain
Tables Any Network Protocol
C12.22 Network Communication Protocol ANSI Std. C12.22

Public or
Relay
Private WAN
ANSI Std. C12.21 MODEM Protocol ANSI Std. C12.22

PBX / Telephone Relay
Modem
ANSI Std. C12.22 Network
Communication
Protocol
C12.21 Telephone Communication Protocol C12.19 Metering
Data Acquisition
ANSI Std. C12.18 Point-to-Point Communication Protocol
A.K.A.
+ =
ANSI Std. C12.19
Gateway
End-Device
Legacy C12.19
Meter or Other Meter
Provider
Root Security
Mechanism
ApTitle
C12R
58 Device
Class
www.fdos.ca
The C12 AMR
Deployment C 12.19 tunneling over C 12.18/21 or C 12.22
View R F/PO T/LAN
C om m
Private or
Public W AN
M odule
C 12.19
C 12.22 R elay PVC /
Internet
Autom ated
M eter
R F/PO T/LAN R eading
C om m
System
M odule Intranet
C 12.19 M eter
G atew ay
D irect Access C 12.18 /Telephone C 12.21 Application
C 12 R egistry Services forR eal-Tim e

access to M eterD ata M odel,Security
C 12.19/C 12.22 D ata M odeland N ode N am es
R egistry
IM O /U tility/Agents
C !2.22 C 12.19 D ata O bjectSystem s
M aster R elay
Provider
Root Security
Mechanism
ApTitle
C12R
59 Device
Class
www.fdos.ca
Visible Components
of a Gas Meter
Other
Indicators
Internal
Controls Lots of GAS
Measurements
Multipliers and Units
Name
Plate Mechanical
Seal
Displayed Registers
Communication
Data Port
Provider
Root Security
Mechanism
ApTitle
C12R
60 Device
Class
www.fdos.ca
Corresponding Data Components
of a Gas Meter Meter Settings
Calibration & Configuration
Customer Registers & Display Controls

Information
Lots of GAS Data Sources

Access Data Type Identification
Logs & & Multipliers
Audit Trail
Access
Tariff & Rate Control and Validation
Schedules
Communication
Protocols
Set Limits, Peak and User Names
Demand Controls
Provider
Root Security
Mechanism
ApTitle
C12R
61 Device
Class
www.fdos.ca
Visible Components
of an Electricity Meter
Controls
Reset
Displayed Registers
Flow
Indicator
Measurements
Name Multipliers and Units
Plate
Mechanical
Communication Seal
Data Port
Provider
Root Security
Mechanism
ApTitle
C12R
62 Device
Class
www.fdos.ca
Corresponding Data Components
of an electricity meter
Meter Settings
& Configuration
Set Limits, Peak
Demand Controls
Reset
Registers & Display Controls
Tariff & Rate
Schedules
Data Sources
Data Type Identification
& Multipliers
Access
Access
Logs &
Control and Validation
Customer
Information Communication
Protocols
and User Names
Provider
Root Security
Mechanism
ApTitle
C12R
63 Device
Class
www.fdos.ca
A Table is Just Like a Tax
Form
Provider
Root Security
Mechanism
ApTitle
C12R
64 Device
Class
www.fdos.ca
End Device (C12.19 Device) Table Types
• Standard Tables
Those data types, structures and groups of structures whose functions and contents are fully
defined and documented by the C12.19 Standard.
• Manufacturer Tables
Those data types, structures and groups of structures whose functions and contents are fully
defined and documented by the C12.19 Device manufacturer.
• User Defined Tables
A collection of tables that aggregate elements from other Manufacturer and Standard Tables; other
than User Defined Tables.
• Pending Tables
Standard Tables and Manufacturer Tables that do not actively partake in the active instance of the
C12.19 Device controlling program, but are scheduled to become an active instance of the C12.19
Device controlling as some future time.
Provider
Root Security
Mechanism
ApTitle
C12R
65 Device
Class
www.fdos.ca
End-Device Standard Tables Assignments
The closest device to
› Standard Table Grouping the sensor or control
Anwithin
End-Device is
point a metering
Ø General Configuration table, 00 the closest device
application communi-
Ø Dimension limiting tables 10/11, 20,21,..., X0,X1 to the point
cation system which of is
measurement,
compliant with the
Ø Identification tables (05, 06)
Utilty Industry the
which holds End
Ø Description tables (01, 02, 06) UtilityData
Device Industry
Tables
Standard Tables
Ø Status tables (03, 04)
Ø Procedure tables (07, 08)
Ø Metering application tables (X2.. X9)
Provider
Root Security
Mechanism
ApTitle
C12R
66 Device
Class
www.fdos.ca
End-Device Standard Tables Data Model
ANSI C12.19-1997
A Table Function Limiting Tables

New in ANSI C12.19-2008
A Decade 22
0 1 2 3 4 5 6 7
General
Time-Of-Use
Configuration
Table
8 9 10 11 12 13 14 15 16
User Defined Telephone Extended Load control RTP Networking Relays Extended Quality of One-way
Source Demand Response User Defined service Devices
ANSI C12.21-1999 / ANSI C12.19-2008 Provider

ANSI C12.22-2008
Root Security
Mechanism
ApTitle
C12R
67 Device
Class
www.fdos.ca
End-Device Tables Activation Model
• Table Use Case Classification

– Active tables (the active instance of the data or program)
– Pending activation tables (a future instance of the data or program)
• Pending Table Control and Status
– Table 04, pending status
– Procedures 13 and 14, activate pending tables
– Procedures 15 and 16, clear (deactivate) pending tables
Provider
Root Security
Mechanism
ApTitle
C12R
68 Device
Class
www.fdos.ca
End-Device tables activation Pending Tables
Activation Event
or Activation
Time
0 1 2 3 4 5 6 7
Time-Of-Use
0 1 2 3 4 5 6 7
Time-Of-Use
8 9 10 11 12 13 15
User Defined Telephone Extended Load control Network Relays Quality
Source of service
8 9 10 11 12 13 14 15
User Defined Telephone Extended Load control Network Relays Extended Quality
Source User Defined of service
Active Tables
Provider
Root Security
Mechanism
ApTitle
C12R
69 Device
Class
www.fdos.ca
Transmission Guidelines for Pending
Tables
• Data read from or written to a pending table is identical in format to the data read from or written to
active tables (may it be Standard or TYPE PE_STIME_DATE_RCD = PACKED RECORD
Manufacturer defined) CASE GEN_CONFIG_TBL.TM_FORMAT OF
• During transmission, Pending Tables are 0: RESERVED: ARRAY[5] OF FILL8;
prefixed with a fixed length activation record 1: YEAR : BCD;
known as the “pending event description”. MONTH : BCD;
• The pending event description is not

DAY
HOUR
: BCD;
: BCD;
included in element offset or element index MINUTE : BCD;
calculation in the request of a partial read or 2: YEAR : UINT8;
write. MONTH : UINT8;
• When using the offset/octet-count method the DAY : UINT8;
C12.19 Application Process shall not HOUR : UINT8;
include the pending header length in the MINUTE : UINT8;
octet offset or count of the request. 3: U_TIME : UINT32;
•
FILL : FILL8;
When using the element index/count method, END;
C12.19 Application Process shall not END
include the pending header element index Provider
Root Security
Mechanism
ApTitle
C12R
70 Device
Class
www.fdos.ca
Transmission Guidelines of Pending
Tables
TYPE EVENT_STORAGE_RCD = PACKED RECORD
TYPE STATUS_BFLD = BIT FIELD OF UINT8
CASE EVENTS_SELECTOR.EVENT_CODE OF
EVENT_CODE : UINT(0..3);
0: PE_STIME_DATE = PE_STIME_DATE_RCD;
SELF_READ_FLAG : BOOL(4);
1: WEEKS : UINT8;
DEMAND_RESET_FLAG : BOOL(5);
DAYS : UINT8;
RESERVED : FILL(6..7);
HOURS : UINT8;
END;
MINUTES : UINT8;
SECONDS : UINT8;
MEMBER EVENTS_SELECTOR = STATUS_BFLD;
2: MFG_CODE : ARRAY[5] OF UINT8;
END;
• Pending tables may be written distinctively. END;
• There is no process that guarantees delivery of a TYPE PENDING_EVENT_DESC_RCD = PACKED RECORD
specific pending table when read from a C12.19 EVENTS_SELECTOR : STATUS_BFLD ;
EVENT_STORAGE: EVENT_STORAGE_RCD ;
Device.
END;
• Implementation shall assume a maximum stacking
of 1 pending table per active table (TDL documents MEMBER PENDING_EVENT_DESC =
this limit). PENDING_EVENT_DESC_RCD ;
Provider
Root
ApTitle
Security
Mechanism
Pseudo Syntax as per User Guide
C12R
71 Device
Class
www.fdos.ca
End-Device Tables Extension Data Model
• Manufacturer defined tables
– Manufacturer proprietary tables structure and table elements.
– Manufacturer proprietary procedures, procedure parameters and responses.
– Manufacturer proprietary fields (status, source definition tables, display tables, security
tables).
– (Best practices shall) contain tables and fields that are not provided directly or indirectly
by Standard tables, procedures or fields within Standard tables.
– (Best practices shall) describe tables and table elements in terms of the C12.19
Standard Syntax and elements deployed data types.
– (Best practices) AMR shall be delivered using data formats as per table 00, data order
and formatting rules.
– (Best practices) Extensions and restrictions shall be documented using the
C12.19 Document Form (table syntax and definitions).
– (Best practices) shall register the C12.19 Device Class.
Provider
Root Security
Mechanism
ApTitle
C12R
72 Device
Class
www.fdos.ca
End-Device Tables Extension Data Model
(cont...)
› User defined tables
Ø Defined by Decade 8, user defined Tables.
Ø Extended user defined tables (new table type in ANSI C12.19-2008).
Ø Make references to any Formal Standard or Manufacturer defined table element available in the End-device.
Ø Provide data collation from more than one End-device instance.
Provider
Root Security
Mechanism
ApTitle
C12R
73 Device
Class
www.fdos.ca
Table Definition Syntax
Assuming that CLOCK_STATE_RCD has been defined elsewhere as a clock state related data
structure, the following table syntax defines the clock state data table known as “Clock Table”
ANSI C12.19 Standard Table Publication Syntax

TABLE 52 CLOCK_TBL = CLOCK_STATE_RCD ;
ANSI C12.19 (V2.0) Table Registration Syntax (TDL)

<table name=“CLOCK_TBL” type=“CLOCK_STATE_RCD”/>
Data can only be instantiated by the TABLE (<table>) constructor.
Data Elements can only be transported from instantiated Tables.
Table Elements can be accessed through transportation or offline instances
(EDL) or assumed Default Sets.
Provider
Root Security
Mechanism
ApTitle
C12R
74 Device
Class
www.fdos.ca
Complete Table Definition (as published)
TYPE TIME_DATE_QUAL_BFLD = BIT FIELD OF UINT8
DAY_OF_WEEK : UINT(0..2);
DST_FLAG : BOOL(3);
GMT_FLAG : BOOL(4);
TM_ZN_APPLIED_FLAG : BOOL(5);
DST_APPLIED_FLAG : BOOL(6);
FILLER : FILL(7..7);
END;
TYPE CLOCK_STATE_RCD = PACKED RECORD

CLOCK_CALENDAR: LTIME_DATE;
TIME_DATE_QUAL: TIME_DATE_QUAL_BFLD;
END;
TABLE 52 CLOCK_TBL = CLOCK_STATE_RCD;
Provider
Root Security
Mechanism
ApTitle
C12R
75 Device
Class
www.fdos.ca
Complete Table Definition (as registered
using TDL/XML)
<bitField name= “TIME_DATE_QUAL_BFLD” type= “UINT8”>

<subElement name= “DAY_OF_WEEK” type= “UINT” startBitInclusive= “0” endBitInclusive= “2”/>
<subElement name= “DST_FLAG” type= “BOOL” startBitInclusive= “3”/>
<subElement name= “GMT_FLAG” type= “BOOL” startBitInclusive= “4”/>
<subElement name= “TM_ZN_APPLIED_FLAG” type= “BOOL” startBitInclusive= “5”/>
<subElement name= “DST_APPLIED_FLAG” type= “BOOL” startBitInclusive= “6”/>
</bitField>
<packedRecord name= “CLOCK_STATE_RCD”>
<element name= “CLOCK_CALENDAR” type= “LTIME_DATE”/>
<element name= “TIME_DATE_QUAL” type= “TIME_DATE_QUAL_BFLD”/>
</packedRecord>
<table name= “CLOCK_TBL” number= “52” type= “CLOCK_STATE_RCD”/>
Provider
Root Security
Mechanism
ApTitle
C12R
76 Device
Class
www.fdos.ca
Complete Table Enterprise Data Import/
Export (using EDL/XML)
<edl>
<data>
<CLOCK_TBL>
<CLOCK_CALENDAR>2000-03-02T10:20:00-07:00</CLOCK_CALENDAR>
<TIME_DATE_QUAL>
<DAY_OF_WEEK>1</DAY_OF_WEEK>
<DST_FLAG>false</DST_FLAG>
<GMT_FLAG>false</GMT_FLAG>
<TM_ZN_APPLIED_FLAG>true</TM_ZN_APPLIED_FLAG>
<DST_APPLIED_FLAG>false</DST_APPLIED_FLAG>
</TIME_DATE_QUAL>
</CLOCK_TBL>
</data>
</edl>
Provider
Root Security
Mechanism
ApTitle
C12R
77 Device
Class
www.fdos.ca
C12.19 Device Table Data Access Rules
Read Table Go ahead

Did you or Make My Day
ask for if you can
permission? Write Table
Provider
Root Security
Mechanism
ApTitle
C12R
78 Device
Class
www.fdos.ca
Access to Table Data Do we have to
read/write the
whole thing?
0 1 2 3 4 5 6 7
Time-Of-Use
Write Partial Table Read
Read and Partial Table
Write is possible.
8 9 10 11 12 13 15
UTILITY DATABASE
User Defined Telephone Extended Load control Network Relays Quality
Source of service
C12.19 can deliver very large payloads.
Provider
Root Security
Mechanism
ApTitle
C12R
79 Device
Class
www.fdos.ca
What about procedure execute?
READ
or
WRITE
is all you need !!!

Write to Table 7 - “Procedure Initiate”
Read from Table 8 - “Procedure Response”
› The Standard implies but does not define time-states and operational
characteristics...
› Best practices shall assumes one-level stacking and n-private sessions
operation.
Provider
Root Security
Mechanism
ApTitle
C12R
80 Device
Class
www.fdos.ca
Terminology for Referencing
Table Elements
Element: The union of all of the Atomic Elements, which
share the same index prefix. An Element can be a
simple type, derived type, a SET, an ARRAY, a
selection from an ARRAY or a selection from a SET.
Sub-Element: A subset of an Atomic Element (Terminal Element in ANSI C12.19-1997), that is
a single bit of a SET, or a member of a BIT FIELD.
Final Element: An Element or Sub-element that is expressed using an ANSI C12.19 built-in
data type. Calculations and analysis can only be performed on Final Elements.
Atomic Element: A restricted subset of an Element that is the smallest component that can be
transmitted as an integral number of octets without loss of its meaning or
interpretation during transmission, in accordance with octet ordering and bit
packing defined in Table 0.
Table: Functionally related application data Elements, grouped together into a single
data structure for transport. A table is also implicitly an Element.
Provider
Root Security
Mechanism
ApTitle
C12R
81 Device
Class
www.fdos.ca
Reference Methods for Table Elements
Reference By Name By Index By Octet Offset
Element • Master Station • Master Station • Master Station

(any non BIT
FIELD) • TDL declaration • Communication • Communication
• EDL element name
Sub-Element • Master Station • Master Station • Master Station
(BIT FIELD or
SET member)
• TDL declaration • Communication
• TDL reference (Use at own peril!
• EDL element name May be rejected by
C12.19 Device)
Final Element • Master Station • Master Station • Master Station
(build-in type that
delivers value) • TDL declaration • Commutation (if not • Communication (if
• TDL reference a BIT FIELD or SET a BIT FIELD or SET
• EDL element name member) member, will return
octets or may be
rejected by meter)
Provider
Root Security
Mechanism
ApTitle
C12R
82 Device
Class
www.fdos.ca
Navigating Table Data Elements
element names, octet-offset/count and element-index/count
Table Data Description Datum Offset Index
Derived Type Example size
Name (octets) relative to
TYPE_2_RCD
TYPE TYPE_1_RCD = PACKED RECORD
IDENTIFIER_1 : UINT32; 4 1 1.0
Element Name IF (CONDITION) THEN
IDENTIFIER_2 : UINT16; 2 optional 5 1.1
END;
IDENTIFIER_3 : UINT8; “Built-in” Type 1 5 or 7 1.2
END;
TYPE TYPE_2_RCD = PACKED RECORD

IDENTIFIER_4 : UINT8; 1 0 0
Derived Type
IDENTIFIER_5 : TYPE_1_RCD; 5 or 7 1 1
END;
Provider
Root Security
Mechanism
ApTitle
C12R
83 Device
Class
www.fdos.ca
Built-in Final-element Data Types
› Integers (8, 16, 24 ... 64 bits signed and unsigned)
› Floating point numbers (single and double precision)
› Fixed point numbers (binary and BCD)
› Binary data
› Derived types
Ø PACKED RECORDS
Ø BIT FIELDs of 8/16/32 bits
› SETs (boolean flags)
› ARRAYs (collections)
› Run-time defined types
Ø CHARacter and STRING
Ø Non-integer numbers
Provider
Root Security
Mechanism
ApTitle
C12R
84 Device
Class
www.fdos.ca
Built-in Elementary Data Representation
› Define
Ø Data format for transmission.
Ø Intrinsic precision for specified data type.
› Encoding includes
Ø Representation of signed integers.
Ø Representation of non integers.
Ø Representation of character data.
Ø Representation of time and data values.
Ø Transmission data order
Provider
Root Security
Mechanism
ApTitle
C12R
85 Device
Class
www.fdos.ca
What Do the C12.19 Standard and
Manufacturer Tables Include?
Everything
under the Sun
Provider
Root Security
Mechanism
ApTitle
C12R
86 Device
Class
www.fdos.ca
What is really inside an end-device?
No dad!
Just use what
you need.
Will everything
under the sun
fit inside my
4 bit micro
processor?
Provider
Root Security
Mechanism
ApTitle
C12R
87 Device
Class
www.fdos.ca
What is really inside an End-device?
Not a 4 bit micro-processor!
Provider
Root Security
Mechanism
ApTitle
C12R
88 Device
Class
www.fdos.ca
So…
How big is the tables universe?
… and how do we manage its size?
… and how do we inform
others about what we’ve done?
Provider
Root Security
Mechanism
ApTitle
C12R
89 Device
Class
www.fdos.ca
End-device Tables Construction Do we
have to
Rules
memorize
this?
› A maximum of 8160 tables are divided into 4080 standard and 4080 manufacturer
defined tables. Each group of 4080 is sub-divided into 2040 active and 2040 pending
tables.
› Standard tables are grouped in units of 10 based on their function.
› Manufacturer tables may be grouped into units of 10, but the Standard is not clear about it
(best practices expect this).
› The number of Tables present in an end device is determined by reading Standard
table 0, General Configuration.
Ø Unused tables do not have to exist in the end device.
Ø Unused conditional fields, within tables, shall not be transported.
Ø Zero length arrays shall not be transported.
Ø Bit Fields are transported Atomically as per their defining type
› Dimension and function limiting values can be supplied through the use of default
sets tables.
› Choice of data formats and transmission order should be left to the manufacturer of
the end device, but it shall be correctly indicated in Standard table 0,
General Configuration.
› Standard table 0, General Configuration shall be available for reading with
no restriction (best practices expect this). Provider
Root
ApTitle
Security
Mechanism
C12R
90 Device
Class
www.fdos.ca
A Standards Compliant Electricity Design
Requirements of a Watthour Meter
An Example
• Mechanical Specification for a watthour meter: (Just as you do it now), e.g. 60HZ, 240V, S Base, 2
element, 5 dials, ±0.1% accuracy, 0.1 - 10 amps including primary & secondary displays, etc.
• Optical port communications shall utilize ANSI C12.22-2008.
• Data delivery and management in accordance with C12.19-2008 or C12.19-1997.
• Data shall be in the form of Standard Tables wherever standards already provide data
structure and management tools.
Provider
Root Security
Mechanism
ApTitle
C12R
91 Device
Class
www.fdos.ca
Group Exercise on Table
Selections
Based on the previous slide list the Table Decades which might be required to
operate such a meter.
• Decade 0 - Configuration • Decade 5 - Time & TOU

• Decade 1 - Sources • Decade 6 - (recorder) Profile
• Decade 2 - (data) Registers • Decade 7 - History (logger)
• Decade 3 - (local) Display • Decade 8 - User Defined
• Decade 4 - (access) Security • Decade 9 - Telephone
Provider
Root Security
Mechanism
ApTitle
C12R
92 Device
Class
www.fdos.ca
Table Definition Syntax
... More details
Provider
Root Security
Mechanism
ApTitle
C12R
93 Device
Class
www.fdos.ca
Background
› Before describing the table construction syntax rules it is important to introduce the basic
principles that govern the table description language and its intended use.
› The description of table data has been accomplished through the use of a “Pascal” like data
description language.
› This is the “look and feel” of the published Standard, also known as the “Document Form”.
› The syntax is not 100% machine parsable, but it is 100% human readable.
› The second release of ANSI C12.19 provides a machine parsable syntax that is based on
XML.
› The XML syntax is referred to as Table Definition Language (TDL) and is known as the “XML
Form”.
› The “Pascal” like syntax and annotations can be generated by computer from the XML Form.
Provider
Root Security
Mechanism
ApTitle
C12R
94 Device
Class
www.fdos.ca
TABLE Definition
› Tables are used to group related simple types, arrays, packed records and bit fields together
into a single structure.
› A declaration of TABLE instantiates a PACKED RECORD that is identified within.
› Tables may be used to represent metering data in an AMI system for use by billing systems
and audit trail management.
› The binary representation of the tables can be transported using any C12 communication
protocol, such as ANSI C12.22.
› The binary representation of a Table does not have to exist physically within a meter, it is
used only for transmission.
› EDL (End-device-Exchange Data Language) may be used to import, export table values in a
manner that is independent of any communication protocol or data formats used by the
meter.
TABLE <table-number> <tbl-identifier> = <rcd-identifier> ;
Provider
Root Security
Mechanism
ApTitle
C12R
95 Device
Class
www.fdos.ca
TABLE Definition Example
Assuming that CLOCK_STATE_RCD has been defined elsewhere as a clock state related data structure,
the following syntax is published by the Standard to creates the clock state data table known as
CLOCK_TBL.
TABLE 52 CLOCK_TBL = CLOCK_STATE_RCD;
The TDL equivalent is
<table number=“52” name=“CLOCK_TBL” type=“CLOCK_STATE_RCD”/>
Provider
Root Security
Mechanism
ApTitle
C12R
96 Device
Class
www.fdos.ca
PACKED RECORD
› Packed records are used to group basic data types, arrays, packed records, sets and bit
fields
› The packing implies that there is no space (transmission buffer) used to pad the records in-
between data elements (i.e. the most compact efficient storage structure possible is used).
› A packed record can contain one or more IF statements or SWITCH statements to modify its
transmission structure based upon specified conditions.
› Elements that are excluded by an IF or SWITCH clauses are not addressable by the AMI
system
› Zero length arrays are not addressable by the AMI system.
› Elements are transmitted in the order which they are defined by the Table syntax.
Provider
Root Security
Mechanism
ApTitle
C12R
97 Device
Class
www.fdos.ca
PACKED RECORD example (publication)
TYPE MANUFACTURER_IDENT_RCD = PACKED RECORD
MANUFACTURER : STRING(4);
ED_MODEL : STRING(8);
HW_VERSION_NUMBER : UINT8;
HW_REVISION_NUMBER : UINT8;
FW_VERSION_NUMBER : UINT8;
FW_REVISION_NUMBER : UINT8;
IF GEN_CONFIG_TBL.ID_FORM THEN
MFG_SERIAL_NUMBER: BCD(8);
ELSE
MFG_SERIAL_NUMBER: STRING(16) ;
END;
END;
Provider
Root Security
Mechanism
ApTitle
C12R
98 Device
Class
www.fdos.ca
PACKED RECORD example (TDL)
<packedRecord name="MANUFACTURER_IDENT_RCD">
<element name="MANUFACTURER" type="STRING" length="4"/>
<element name="ED_MODEL" type="STRING" length="8"/>
<element name="HW_VERSION_NUMBER" type="UINT8"/>
<element name="HW_REVISION_NUMBER" type="UINT8"/>
<element name="FW_VERSION_NUMBER" type="UINT8"/>
<element name="FW_REVISION_NUMBER" type="UINT8"/>
<if condition="GEN_CONFIG_TBL.ID_FORM != 0">
<then>
<element name="MFG_SERIAL_NUMBER" type="BCD" length="8"/>
</then>
<else>
<element name="MFG_SERIAL_NUMBER" type="STRING" length="16"/>
</else>
</if>
</packedRecord> Provider
Root Security
Mechanism
ApTitle
C12R
99 Device
Class
www.fdos.ca
PACKED RECORD Transmission Order
A field is an element or final-element
Field 1 (UINT32): 3 2 1 0
Field 2 (UINT8): 0
Field 3 (UINT24): 2 1 0
Field 4 (UINT16): 1 0
Little endian transmission: 1 0 2 1 0 0 3 2 1 0
Field 4 Field 3 Field 2 Field 1
Big endian transmission: 0 1 0 1 2 0 0 1 2 3
Field 4 Field 3 Field 2 Field 1
Provider
Root Security
Mechanism
ApTitle
C12R
100 Device
Class
www.fdos.ca
Primitive Data Types
Defining Description TDL/EDL Schema
Word Type
INT8 Eight bit signed integer (-128..+127). xsd:byte
INT16 Sixteen bit signed integer (-32768..32767). xsd:short
INT24 Twenty-four bit signed integer (-8388608..+8388607). xsd:int
INT32 Thirty-two bit signed integer (-2147483648..+2147483647). xsd:int
INT40 Forty bit signed integer (-549755813888..+549755813887). xsd:long
INT48 Forty-eight bit signed integer xsd:long
(-140737488355328..+140737488355327).
INT56 Forty-eight bit signed integer xsd:long
(-36028797018963968..+36028797018963967).
INT64 Sixty-four bit signed integer xsd:long
(-9223372036854775808..+9223372036854775807).
Provider
Root Security
Mechanism
ApTitle
C12R
101 Device
Class
www.fdos.ca
Primitive Data Types
Word Type
UINT8 Eight bit unsigned integer (0..255). xsd:unsignedByte
UINT16 Sixteen bit unsigned integer (0..65535). xsd:unsignedShort
UINT32 Thirty-two bit unsigned integer (0..4294967295) xsd:unsignedInt
UINT40 Forty bit unsigned integer (0..1099511627775). xsd:unsignedLong
UINT48 Forty-eight bit unsigned integer (0..281474976710655). xsd:unsignedLong
UINT56 Forty-eight bit unsigned integer (0..72057594037927935). xsd:unsignedLong
UINT64 Sixty-four bit unsigned integer (0..18446744073709551615). xsd:unsignedLong
FLOAT32 Single precision floating point real number, per IEEE Standard 754-1988. xsd:float
FLOAT64 Double precision floating point real number, per IEEE Standard 754-1988. xsd:double
FILL8 Eight bits of zeroes, used as space holder or filler. xsd:unsignedByte
FILL16 Sixteen bits of zeroes, used as space holder or filler. xsd:unsignedShort
FILL24 Thirty-two bits of zeroes, used as space holder or filler. V2.0 xsd:unsignedInt
FILL32 Thirty-two bits of zeroes, used as space holder or filler. xsd:unsignedInt
FILL64 Sixty-four bits of zeroes, used as space holder or filler. xsd:unsignedInt
BCD One 8 bits value containing two decimal digits or separators. xsd:string (restricted)
Provider
Root Security
Mechanism
ApTitle
C12R
102 Device
Class
www.fdos.ca
Binary and Character Data Types

Word Type
BINARY An atomic array of UINT8 xsd:hexBinary
STRING An atomic array of CHAR xsd:string
› CHARs are governed by

TDL/EDL Schema
CHAR_FORMAT Implementation of data type CHAR Type
1 ISO character set (8 bits) xsd:string encoding="UTF-8"
2 ISO 8859/1 or ECMA-94 Latin 1 character set (8 bits) xsd:string encoding="UTF-8"
3 UTF8 xsd:string encoding="UTF-8"
Provider
Root Security
Mechanism
ApTitle
C12R
103 Device
Class
www.fdos.ca
Non-integer Data Type
NI_FORMAT1 or TDL/EDL Schema
NI_FORMAT2 Implementation of data type NI_FMAT1 or NI_FMAT2 Type
0 FLOAT64 xsd:double
1 FLOAT32 xsd:double
2 FLOAT_CHAR12 xsd:double
4 A fixed point number that is transmitted as an INT32. xsd:double
5 FIXED_BCD6 xsd:double
7 INT24 xsd:double
8 INT32 xsd:double
9 INT40 xsd:double
10 INT48 xsd:double
11 INT64 xsd:double
NI_FORMAT1 xsd:double
NI_FORMAT1 xsd:double
Provider
Root Security
Mechanism
ApTitle
C12R
104 Device
Class
www.fdos.ca
Date and Time Data Types
HTIME_DATE Date up to second (e.g.: 1999/10/10 01:01:01.0) xsd:dateTime
LTIME_DATE Date up to second (e.g.: 1999/10/10 01:01:01) xsd:dateTime
STIME_DATE Date up to minute (e.g.: 1999/10/10 01:01 xsd:dateTime
HTIME Time of the day with sub-second resolution (e.g.: 01:01:01.002) xsd:dateTime
TIME Time of the day with seconds resolution (e.g.: 01:01:01) xsd:dateTime
STIME Time of the day with minutes resolution (e.g.: 01:01) xsd:dateTime
DATE Date (e.g.: 1999/10/10) xsd:dateTime
RDATE Recurring date (e.g.: each December 25) xsd:unsignedShort
TDL Schema
TM_FORMAT Implementation of data types defined above Type
1 Discrete BCD fields not applicable
2 Discrete UINT8 fields not applicable
3 Universal time relative to 1970 GMT expressed as a counter (32-bit not applicable
minutes + sub-minutes)
4 Universal time relative to 1970 GMT expressed as a counter (32-bit not applicable
seconds + sub-seconds)
Provider
Root Security
Mechanism
ApTitle
C12R
105 Device
Class
www.fdos.ca
BIT FIELD Statement
› Some data requirements do not efficiently utilize the space using the primitive data types,
described in earlier sections.
› Data types can be described with bit field definitions, using a bit field value range notation.
› Multiple occurrences of these statements are grouped logically (packed) together so that the
group ends on octet boundary.
› For purposes of description (and transmission), the bit field is treated as the unsigned
integer object.
› A bit-field can contain one or more IF statements or SWITCH statements to
modify its structure based upon specified conditions.
› Sub-elements that are excluded by an IF or SWITCH clause are not
addressable by the AMI system
Provider
Root Security
Mechanism
ApTitle
C12R
106 Device
Class
www.fdos.ca
BIT FIELD Example (publication)
TYPE STATUS_BFLD = BIT FIELD OF UINT16
IF ACT_TIME_TOU_TBL.SEPARATE_SUM_DEMANDS_FLAG THEN
CURR_SUMM_TIER : UINT(0..2);
CURR_DEMAND_TIER : UINT(3..5);
ELSE
CURR_TIER : UINT(0..2);
END;
TIER_DRIVE : UINT(6..7);
SPECIAL_SCHD_ACTIVE : UINT(8..11);
SEASON : UINT(12..15);
END;
Provider
Root Security
Mechanism
ApTitle
C12R
107 Device
Class
www.fdos.ca
Bit Field Statement
TDL Schema
Grammar Definition Type
BOOL(<value>) Boolean bit field having the value zero (0) for FALSE or one (1) xsd:boolean
for TRUE, in bit position <value>.
INT(<value>..<value>) Signed binary integer represented by a range of successive xsd:int
bits. The range <value>..<value> represents the “start” and
“end” bit positions of the integer in the bit field.
UINT(<value>..<value>) Unsigned binary integer represented by a range of successive xsd:unsignedInt
bits. The range <value>..<value> represents the “start” and
“end” bit positions of the unsigned integer in the bit field.
FILL(<value>..<value>) Fill bits represented by a range of successive bits. The range xsd:unsignedInt fixed (0)
<value>..<value> represents the “start” and “end” bit posi-
tions of the fill area in the bit field. The value of the fill bits is
always zero (0).
Provider
Root Security
Mechanism
ApTitle
C12R
108 Device
Class
www.fdos.ca
BIT FIELD example (TDL)
<bitField name="STATUS_BFLD" type="UINT16">
<if condition="ACT_TIME_TOU_TBL.SEPARATE_SUM_DEMANDS_FLAG">
<then>
<subElement name="CURR_SUMM_TIER" type="UINT" startBitInclusive="0" endBitInclusive="2"/>
<subElement name="CURR_DEMAND_TIER" type="UINT" startBitInclusive="3" endBitInclusive="5"/>
</then>
<else>
<subElement name="CURR_TIER" type="UINT" startBitInclusive="0" endBitInclusive="2"/>
<subElement name="FILLER" type="FILL" startBitInclusive="3" endBitInclusive="5"/>
</else>
</if>
<subElement name="TIER_DRIVE" type="UINT" startBitInclusive="6" endBitInclusive="7"/>
<subElement name="SPECIAL_SCHD_ACTIVE" type="UINT" startBitInclusive="8" endBitInclusive="11"/>
<subElement name="SEASON" type="UINT" startBitInclusive="12" endBitInclusive="15"/>
</bitField>
Provider
Root Security
Mechanism
ApTitle
C12R
109 Device
Class
www.fdos.ca
BIT FIELD OF UINT16
Transmission Order
1 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SEASON TIER_DRIVE CURR_SUMM_TIER

SPECIAL_SCHD or CURR_TIER
ACTIVE CURR_DEMAND_TIER
or FILLER
Little endian transmission: 1 0

Bits Bits
8 to 15 0 to 7
Big endian transmission: 0 1
Bits Bits
0 to 7 8 to 15
Provider
Root Security
Mechanism
ApTitle
C12R
110 Device
Class
www.fdos.ca
ARRAYs
› Multiple repetitions of the same data type used to describe a single variable can be
grouped together in an array.
› An array may have one or more dimensions.
› The array dimension indices are separated by commas
› ANSI C12.19-2008 implements 1-D arrays only
› Array indices start with zero, representing the first element of the dimension.
› Transmission of ARRAY elements begins with lower indices.
Example:
NEW_TIME_DATE: ARRAY[30] OF TIME_DATE_QUAL_BFLD;
<array name=“NEW_TIME_DATE” dimension=“30” type=“TIME_DATE_QUAL_BFLD”/>
Provider
Root Security
Mechanism
ApTitle
C12R
111 Device
Class
www.fdos.ca
ARRAY Element Order
00 01 02 03 Deprecated
ARRAY[5] 0 1 2 3 4 ARRAY[3,4] 10 11 12 13
20 21 22 23
Single dimension ARRAY: 4 3 2 1 0
Deprecated
Multiple dimensions 23 22 21 20 13 12 11 10 03 02 01 00
ARRAY:
Note:Transmission order independent of the architecture

(Little / Big endian)
Provider
Root Security
Mechanism
ApTitle
C12R
112 Device
Class
www.fdos.ca
SETs
› A SET defines a collection of related boolean.
› The number of bits in the set is eight times the set size in octets.
› The first bit in the set is reference as 0 (Example: ED_MFG_STATUS[0]).
Example
ED_MFG_STATUS:SET(GEN_CONFIG_TBL.DIM_MFG_STATUS_USED);
<set name=“ED_MFG_STATUS”
dimension=“GEN_CONFIG_TBL.DIM_MFG_STATUS_USED * 8 ” />
Provider
Root Security
Mechanism
ApTitle
C12R
113 Device
Class
www.fdos.ca
SET Bit Order
SET[3]: 0 1 2
7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16
Transmission order: 2 1 0
Bits Bits Bits
16 to 23 8 to 15 0 to 7
Note:Transmission order independent of the architecture

(Little / Big endian)
Provider
Root Security
Mechanism
ApTitle
C12R
114 Device
Class
www.fdos.ca
Identifiers
Any identifier is a label that must match the Regular Expression:
“[A-Z][A-Z0-9]*([_][A-Z0-9]+)*”
i.e. it shall begin with an upper case letter then shall be constructed from any combination of
upper case letters, digits with single underscore acting as separators. The ‘_’ cannot be
followed by another ‘_’. This rule allows for defining or referencing the following:
› Primitive data type (otherwise known as a build-in types e.g. INT8, CHAR);
› TABLEs (whose identifier name ends with _TBL);
› PACKED RECORDs (whose identifier name ends with _RCD) or
› BIT FIELDs (whose identifier name ends with _BFLD)
› Enumerators (whose identifier name ends with _ENUM)
› Constants (enum members whose identifier name ends with _CNST)
› Decades (whose identifier name ends with _DEC)
› Procedures (whose identifier name ends with _PROC)
However, Table Element names (none of the above) must be matched against the above
regular expression with no suffixes and may not match a primitive type.
Provider
Root Security
Mechanism
ApTitle
C12R
115 Device
Class
www.fdos.ca
Complete Table Definition
(as published)
TYPE TIME_DATE_QUAL_BFLD = BIT FIELD OF UINT8
DAY_OF_WEEK: UINT(0..2);
DST_FLAG: BOOL(3);
GMT_FLAG: BOOL(4);
TM_ZN_APPLIED_FLAG: BOOL(5);
DST_APPLIED_FLAG: BOOL(6);
END;

CLOCK_CALENDAR: LTIME_DATE;
TIME_DATE_QUAL: TIME_DATE_QUAL_BFLD;
END;
TABLE 52 CLOCK_TBL = CLOCK_STATE_RCD; Provider

Root Security
Mechanism
ApTitle
C12R
116 Device
Class
www.fdos.ca
Complete table definition (as
registered using TDL/XML)
<bitField name= “TIME_DATE_QUAL_BFLD” type= “UINT8”>

<subElement name= “DAY_OF_WEEK” type= “UINT” startBitInclusive= “0” endBitInclusive= “2”/>
<subElement name= “DST_FLAG” type= “BOOL” startBitInclusive= “3”/>
<subElement name= “GMT_FLAG” type= “BOOL” startBitInclusive= “4”/>
<subElement name= “TM_ZN_APPLIED_FLAG” type= “BOOL” startBitInclusive= “5”/>
<subElement name= “DST_APPLIED_FLAG” type= “BOOL” startBitInclusive= “6”/>
</bitField>
<packedRecord name= “CLOCK_STATE_RCD”>
<element name= “CLOCK_CALENDAR” type= “LTIME_DATE”/>
<element name= “TIME_DATE_QUAL” type= “TIME_DATE_QUAL_BFLD”/>
</packedRecord>
<table name= “CLOCK_TBL” number= “52” type= “CLOCK_STATE_RCD”/>
Provider
Root Security
Mechanism
ApTitle
C12R
117 Device
Class
www.fdos.ca
Deployment Strategy for TDL/EDL
AMI www.naedra.org
C1219TDL.xsl
Table Processor
C1219TDLSchema.xsd
C1219TDL-xxxx.xml (.0)
EDClassTDL.xml(.a.b.c.d)
DefaultSet.xml C1219EDL.xsd C1219Section9.doc
AMI Application
AMR Data Acquisition EDClassEDL.xml
Provider
Root Security
Mechanism
ApTitle
C12R
118 Device
Class
www.fdos.ca
TDL/EDL
• C1219TDLSchema.xsd - The core schema files for validating table definition syntax and meta-
data.
• C1219TDL-xxxx.xml - The Standard tables syntax and meta-data using XML, for publication year
xxxx.
• C1219TDL.xsl - The XSLT file that defines how a C1219TDL-xxxx.xml document is formatted for
publishing Section 9 of ANSI C12.19 Standard.
• EDClassTDL.xml - The end-device table extension, expressed in TDL-XML.
• C1219EDL.xsd - The end-device data description schema that is automatically generated by a
table processor from the supplied C1219TDL.xml and/or EDClassTDL.xml.
• DefaultSet.xml - The Standard default-set-used file that is validated using C1219EDL.xsd schema.
• C1219EDL.xml - An end-device data file that is validated using C1219EDL.xsd schema
• C1219Section9.doc - A formatted document that is placed in section 9 of ANSI C12.19 Standard,
the published text. This document is produced by XSL using the C1219TDL.xml and C1219TDL.xsl
to produce the document product.
Provider
Root Security
Mechanism
ApTitle
C12R
119 Device
Class
www.fdos.ca
C1219TDLSchema.xsd Elements
Provider
Root Security
Mechanism
ApTitle
C12R
120 Device
Class
www.fdos.ca
Required element name Required attribute name XML keyword TDL Default value Optional attribute value document text.
Optional element name Optional attribute name C12.19 keyword or symbol C12.19 built-in type
<tdlxmlns="http://www.naedra.org/2008/C1219TDLSchema" Table-Set Definitions

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
title="AMERICAN NATIONAL STANDARDC12.19-1997 Utility Industry End Device Data
for
Tables" AMERICAN NATIONAL STANDARD C12.19-1997
version="1.0" Utility Industry End Device Data Tables
standard="http://www.ansi.org/1997/C12.19-1997"
registry="NAEDRA" Version 1.0
isoBranch="2.16.124.113620.1.19" 2.16.124.113620.1.19.0.1.0.0
deviceClass="0.1.0.0">
Reference Standard: http://www.ansi.org/1997/C12.19-1997
Registered to: NAEDRA
ISO Branch: 2.16.124.113620.1.19
End-Device relative class: .0.1.0.0 (Standard class)
<decade name="TIME_OF_USE_DEC" number="5" label="Time-of-use tables"> 9.1 Decade 5: Time-of-use tables (TIME_OF_USE_DEC)
<description> The tables in this decade provide information related to end device Date and Time and
The tables in this decade provide information related to end device Date and Time Of Use (TOU) operation.
Time and Time Of Use (TOU) operation.
</description> 9.1.1 Standard defined types
 None defined outside tables.
<table name="CLOCK_STATE_TBL" number="55" type="CLOCK_STATE_RCD" 9.1.1.1 Standard table 55 : Clock state table (CLOCK_STATE_TBL)
label="Clock state table"> This table provides the end device real time clock information.
<description>
This table provides the end device real time clock information. 9.1.1.2 Standard table 10: Defined types
</description>
<bitField name="STATUS_BFLD" type="UINT16"> TYPE STATUS_BFLD = BIT FIELD OF UINT16
<description>Array of status entries of each TOU set.</description> IF ACT_TIME_TOU_TBL.SEPARATE_SUM_DEMANDS_FLAG THEN
CURR_SUMM_TIER : UINT(0..2);
<if condiion="ACT_TIME_TOU_TBL.SEPARATE_SUM_DEMANDS_FLAG">
CURR_DEMAND_TIER : UINT(3..5);
<then> ELSE
<subElement name="CURR_SUMM_TIER" type="UINT" CURR_TIER : UINT(0..2);
startBitInclusive="0" endBitInclusive="2"> FILLER : FILL(3..5);
<description> END;
Active tier corresponding to summations. This variable is only used when the TIER_DRIVE : UINT(6..7);
capability flag ACT_TIME_TOU_TBL.-SEPARATE_SUM_DEMANDS_FLAG SPECIAL_SCHD_ACTIVE : UINT(8..11);
SEASON : UINT(12..15);
(Table 51) = TRUE.
END;
</description>
</subElement>
<subElement name="CURR_DEMAND_TIER" type="UINT" CLOCK_CALENDAR : LTIME_DATE;
startBitInclusive="3" endBitInclusive="5"> TIME_DATE_QUAL : CLOCK_TBL.TIME_DATE_QUAL_BFLD;
<description> STATUS : STATUS_BFLD;
Active tier corresponding to demands. This variable is only used when the END;
capability flag ACT_TIME_TOU_TBL.SEPARATE_SUM_DEMANDS_FLAG
(Table 51) == TRUE. TABLE 55 CLOCK_STATE_TBL = CLOCK_STATE_RCD;
</description>
</subElement> Provider
Provider
Root
Security
Mechanism
ApTitle
C12R
ANSI C12.19/MC12.19/IEEE-1377 Standards for Page 12
Utility Industry End Device Data Tables
</then> Identifier /sub-identifer Value Definition

<else>
<subElement name="CURR_TIER" type="UINT" STATUS_BFLD Array of status entries of each TOU set.
startBitInclusive="0" endBitInclusive="2"> CURR_SUMM_TIER Active tier corresponding to summations. This
<description> variable is only used when the capability flag
Number representing the tier that is currently active in the meter. This vari- ACT_TIME_TOU_TBL.-
able is only used when the capability flag ACT_TIME_TOU_TBL.- SEPARATE_SUM_DEMANDS_FLAG (Table
SEPARATE_SUM_DEMANDS_FLAG (Table 51) = FALSE. 51) = TRUE.
</description> CURR_DEMAND_TIER Active tier corresponding to demands. This vari
</subElement> able is only used when the capability flag
<subElement name="FILLER" type="FILL" ACT_TIME_TOU_TBL.-
startBitInclusive="3" endBitInclusive="5"/> SEPARATE_SUM_DEMANDS_FLAG (Table
</else> 51) = TRUE.
</if> CURR_TIER Number representing the tier that is currently
<subElement name="TIER_DRIVE" type="UINT" active in the meter. This variable is only used
startBitInclusive="6" endBitInclusive="7"> when the capability flag
ACT_TIME_TOU_TBL.-
<description>Tier drive source code.</description>
SEPARATE_SUM_DEMANDS_FLAG (Table
<enumerator>
51) == FALSE.
<enum value="0" text="Tier selection is controlled by
TIER_DRIVE Tier drive source code.
CALENDAR_TBL.TIER_SWITCHES (Table 54)"/> 0 Tier selection is controlled by
<enum value="1" CALENDAR_TBL.TIER_SWITCHES (Table
text="Tier selection is not controlled by this standard"/> 54).
<enum value="2" 1 Tier selection is not controlled by this standard
text="Tier selection is not controlled by this standard"/> 2 Tier selection is not controlled by this standard
<enum value="3" 3 Tier selection is not controlled by this standard
text="Tier selection is not controlled by this standard"/> SPECIAL_SCHD_ACTIVE
</enumerator> 0 Special schedule 0 active.
</subElement> 1 Special schedule 1 active.
<subElement name="SPECIAL_SCHD_ACTIVE" type="UINT" 2 Special schedule 2 active.
startBitInclusive="8" endBitInclusive="11"> 3 Special schedule 3 active.
<enumerator> 4 Special schedule 4 active.
5 Special schedule 5 active.
<enum value="0" text="Special schedule 0 active"/>
<enum value="2" text="Special schedule 2 active"/> 8 Special schedule 8 active.
<enum value="6" text="Special schedule 6 active"/> 15 No special schedule active.
<enum value="15" text="No special schedule active"/>
</enumerator> Provider
Provider
Root
ApTitle
Security
Mechanism
C12R
</subElement> Identifier /sub-identifer Value Definition

<subElement name="SEASON" type="UINT" SEASON Current end device season number.
startBitInclusive="12" endBitInclusive="15">
<description>Current end device season number.</description>
</subElement>
</bitField>
<packedRecord name="CLOCK_STATE_RCD"> CLOCK_STATE_RCD
CLOCK_CALENDAR Current end device time.
<element name="CLOCK_CALENDAR" type="LTIME_DATE">
<description>Current end device time.</description>
</element>
<element name="TIME_DATE_QUAL"
type="CLOCK_TBL.TIME_DATE_QUAL_BFLD"/>
<element name="STATUS" type="STATUS_BFLD"/>
</packedRecord>
</table>
</decade>
</tdl>
Provider
Provider
Security
Root Mechanism
ApTitle
C12R
Provider
Provider
Security
Root Mechanism
ApTitle
C12R
Toward Effective AMI
› Past (and present) AMR implementations introduced a bewildering array of proprietary
solutions.
› Vendors (meter manufacturers, meter readers, software suppliers and at times utilities)
created diverse products.
› Most vendors are fiercely protective of their protocols and data formats.
› Competitive market pressure, downsizing and deregulation resulted in loss of domain
expertise.
The Net Result
› Utilities were and still are unable to establish a highly competitive or efficient AMR practice.
› Following the transition into the digital age utilities lost the ability to inter-operate their multi-
sourced appliances (meters) and applications (billing and meter reading software), just like
they did in the past.
› Utilities may not be able to respond effectively to rapidly changing technology.
The Solution is StandardAMI™
› Look at IEEE 1377 / ANSI C12.19 and related C12 protocols as a complete suite of managed
standards that should be used to produce a verifiable solution that delivers your AMI needs.
› Invoke Guidelines as a reference framework for testing for C12.19 compliance.
Provider
Root Security
Mechanism
ApTitle
C12R
125 Device
Class
www.fdos.ca
Regaining Interoperability
and Multi-sourced Capability
Is specifying ANSI C12.19 compliance on a purchase order enough?
› ANSI C12.19 is about possibilities
Ø Options for measurements
Ø Options for functions
Ø Options for capabilities
Ø Options for operation
Ø etc.
› Guidelines is about collective users making selections from the available possibilities
Ø Chosen measurements of interest
Ø Chosen functions desired
Ø Chosen capabilities sought
Ø Chosen operations desired
Ø etc.
... to enjoy the benefit of economy of scale...
Provider
Root Security
Mechanism
ApTitle
C12R
126 Device
Class
www.fdos.ca
e.g. AEIC Guidelines Implementation
Assumptions
› Application of these Guidelines should be done with respect to the specific needs of the
utility user at all times.
› These Guidelines are a living document and should be subject to
review, modification and continued improvement by the utility users.
› The AEIC Users Group should be responsible for revision control of
the AEIC guidelines document.
› The Guidelines are provided for information only and no warranty or
guarantee should be made or implied regarding their use.
› The Guidelines do not specify a manufacturing process.
› Utilities will utilize these Guidelines for the purpose of purchase order
specifications on a voluntary basis.
Provider
Root Security
Mechanism
ApTitle
C12R
127 Device
Class
www.fdos.ca
Guidelines as a Framework for
Accreditation
› Guidelines are a framework and an accreditation criteria for
ANSI C12.19/IEEE 1377/MC12.19 based meters for users and
testers of this technology.
› The three Standards are identical because of mutual
memorandum of understanding that exists among the three
organizations, ANSI, IEEE and Measurement Canada (Legal
Metrology Branch).
› The Standards are generically referenced throughout as
“C12.19”.
› The C12.19 standard relies on complementary ancillary
suite of standards to handle communications
methodologies using interfaces such as optical port,
telephone, and any-area network.
› Compliance with these Guidelines also implies compliance
with C12.19 and the ancillary suite of communications
standards.
Provider
Root Security
Mechanism
ApTitle
C12R
128 Device
Class
www.fdos.ca
C12.19 Evolution vs. Internet Growth
Number of Internet Hosts
Hobbes' Internet Timeline Copyright (c) 1993-2006 by Robert H Zakon
500M
ANSI C12.22/IEEE1703 (2008)

450M
ANSI C12.19/IEEE1377 (2008)
AEIC 2.0 (2008)
400M
SCE / E-100 SSM
350M
MC IS/IP-E-01-E
300M
ISO/IEC 62056-62
250M
ANSI C12.18 /IEEE1701 (R2006)
200M
ANSI C12.21 ANSI C12.21/IEEE1702 (R2006)
“Tucker Tables” 150M

ANSI C12.19/IEEE1377
Accepted by SEE
(South Eastern 100M AEIC 1.0
Electric Exchange) ANSI C12.18
50M
1986 1992 1996 2000 2004 2006 2007
Provider
Root Security
Mechanism
ApTitle
C12R
129 Device
Class
www.fdos.ca
The Guidelines’ C12 Objectives
› Reduce the complexity of meter reading through the reduction of variations in the
implementation and interpretation of the ANSI C12.19 suite of Standards.
› Establish a user's expectation for “best practices” for implementers of the ANSI C12.19 suite
of Standards.
› Provide definite interpretation, from a Utility’s perspective, for terms and definitions that are
defined vaguely, undefined or may be optional according to the C12.19 suite of Standards.
› Provide guidelines for the uniform definition, display, transportation and interpretation of
metering logical and legal measures by stating:
Ø implementation expectations
Ø performance expectations
Ø Verification expectation
› Establish pass/fail acceptance criteria for the C12.19 metering and supporting
communication technology.
› Establish a high expectation of uniformity in meters and ancillary metering equipment in
regard to interchangeability and interoperability from a utility user point of view.
Provider
Root Security
Mechanism
ApTitle
C12R
130 Device
Class
www.fdos.ca
Disclosure Requirements
› Full information is expected to be provided by the vendor to the utility owner of a device.
› This information should minimally include the registered device class.
› Any missing information could be obtained by reading the device then by referencing the
registered data of the device.
› It shall be possible to programme, read and write to a device strictly using the interpretation
of IEEE 1377 / ANSI C12.19 / MC1219 in accordance with the AEIC Guidelines without the
necessity to engage in a non-disclosure agreement.
Provider
Root Security
Mechanism
ApTitle
C12R
131 Device
Class
www.fdos.ca
The Success Pyramid
SOR General Statement Of Requirements
Specific Requirements tabulated by US

DOE, MC, AMI Dept. Of Energy, Measurement Canada,
UtilityAMI, Southern California Edison
SCE, UTILITIES and interested Utilities
Standards, AEIC Guidelines, StandardAMI™

Accreditation, User Group
Registry, Testing, Training Deployment
Better Performing Utilities & Compliant Vendors Benefits
Provider
Root Security
Mechanism
ApTitle
C12R
132 Device
Class
www.fdos.ca
The End
Provider
Root Security
Mechanism
ApTitle
C12R
133 Device
Class
www.fdos.ca

Moise

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Moise

Uploaded by

Copyright:

Available Formats

Introduction to TDL and EDL for Use by AMI

Systems Deployed with ANSI C12.19 Tables

Ø ANSI C12.19 Tables' structure C1219TDLSchema.xsd

ANSI C12.19 syntax Registrar

Ø Published Table definition syntax C1219EDL-2008.xsd

describe metering device instances Vendor-TDL.xml(.a.b.c.d)

Ø Table Definition Language (TDL) Vendor Vendor-EDL.xml(.a.b.c.d) Remote User Application

Ø Exchange Data Language (EDL) Vendor-EDL.xsd

Ø Documents used to register an End Device's Registrar Vendor-Doc.pdf

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

› Advanced Metering Infrastructure (AMI)

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

› AMI to Any-network Comm. Module: IEEE 1703 / ANSI C12.22

(OSI Layer 1-4) + IEEE 1704 Mechanical

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Layer System Management

resides beside all four layers. COAX

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

IEEE 1703 / ANSI C12.22 Gateway

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

IEEE 1701/ IEEE 1702/ IEEE 1703/

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

C12.22 Network Segment

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

C12.22 Network Segment

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Layer 6 Not Defined Null Null Null Not Defined

a. If it contains Tables then it is also a C12.19 Device.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

C12.22 Device C12.22 Comm. Module

Layers (1-4) Layers (1-4) Layers (1-4)

C12.22 Device to C12.22 Comm. Module Connector C12.22 Network Segment

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

6 Registration complete, Appliance is on-line

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

6 Registration complete, granted access to AMI network

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

C12.19 Device C12.22 Relay App C12.19 Device

C12.19 Tables C12.19 Tables C12.19 Tables

Layers (1-4) Layers (1-4) Layers (1-4) Layers (1-4)

To Native To Native To Native To Native

C12.22 Network Segment X C12.22 Network Segment Y

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

C12.19 Device A C12.19 App to IEC 61850 App Gateway

Layers (1-4) Layers (1-4) Layers (1-4) Layers (1-4)

To Native To Native TCP/IP TCP/IP

C12.22 Network Segment X May share the same “wire” Ethernet

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.

C12.22 Network Segment 1 (Any LAN or WAN)