Moise.pdf

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
Introduction to TDL and EDL for Use by AMI
Systems Deployed with ANSI C12.19 Tables
and ANSI C12.22 Networks
Introduction to TDL and EDL for Use by AMI
Systems Deployed with ANSI C12.19 Tables
and ANSI C12.22 Networks

www.fdos.ca
2
Copyright © 2008, Future DOS R&D Inc. All Rights Reserved.
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Presentation Outline
C1219EDL-2008.xsd
C1219TDL.xsl
C1219TDLSchema.xsd
DefaultSet.xml
ExportData.xml
Vendor-Doc.pdf
Vendor-TDL.xml(.a.b.c.d)
Vendor-EDL.xml(.a.b.c.d)
C1219TDL-2008.xml
Vendor-EDL.xsd
Import/Export Data
SiteData.xml
Input Data
Registrar
Vendor
Registrar
AMR Application
Remote User Application
Registry
AMR System
› Overview of StandardAMI™
Ø Definitions
Ø ANSI C12.22 StandardAMI Network™ communication
architecture
Ø ANSI C12.19 Tables' structure
› ANSI C12.19 syntax
Ø Published Table definition syntax
Ø Table elements and constants values used to
describe metering device instances
Ø Table Definition Language (TDL)
Ø Exchange Data Language (EDL)
Ø Documents used to register an End Device's
data model
› By-products and benefits derived from
registering an ANSI C12.19 data model using TDL and EDL
› Q&A

www.fdos.ca
3
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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).
2. North American Electric Reliability Corporation (NERC)

www.fdos.ca
4
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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
00:00 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 20:00 21:00 22:00 23:00
19:00
OFF PEAK
MID PEAK
ON PEAK
OFF PEAK
MID PEAK
ON PEAK
SUMMER
WINTER

www.fdos.ca
5
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.”

www.fdos.ca
6
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.”
?

www.fdos.ca
7
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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

www.fdos.ca
8
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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

www.fdos.ca
9
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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

www.fdos.ca
10
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Using Standards
ANSI C12.19 + ANSI C12.22 + IEC 61850
to Meet the Totality of Requirements

www.fdos.ca
11
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Meter Communication in a Multitude of
Network and Media
AMI Network
AMI Interface
C&I Building Energy
Management Systems
Substation Automation
& SCADA IEDs
Residential Metering
› AMI Network: IEEE 1703 / ANSI C12.22 (OSI Layer 7 Services)
› AMI Payload: IEEE 1377 / ANSI C12.19 (OSI Layer 7 Data)
› AMI to Any-network Comm. Module: IEEE 1703 / ANSI C12.22
(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
Configuration: IEEE 1703 / ANSI
C12.22 Local Port
› AMI Network-Segment to Network
Segment Route management: IEEE 1703 /
ANSI C12.22 Relay
› AMI Network Management, Emergency Response,
Utility System Access, User Access: IEEE 1703 /
ANSI C12.22 Master Relay, Authentication Host and
Notification Host

www.fdos.ca
12
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Flashback… CEBus Architecture
APPLICATION
SESSION
TRANSPORT
NETWORK
DATA LINK
PHYSICAL
1990’s CEBus architecture
CEBus is based on the OSI
“Reduced Stack” model which
includes only four of the seven
layers:
› Application Layer
› Network Layer
› Data Link Layer
› Physical Layer
Most functions of the Transport,
Session and Presentation Layers
have been added either in the
Application Layer or the Network
Layer. CEBus also include a Layer
System Management element that
resides beside all four layers.
ISO Open Systems
Interconnection
Model
PRESENTATION
APPLICATION
NETWORK
DATA LINK
PHYSICAL
ANSI/IEA-600 Model and
ANSI C12.19 over ANSI
C12.22
Layer
System
Management
INFRARED
FIBER OPTIC
COAX
POWER LINE
RF
TWISTED PAIR

www.fdos.ca
13
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Flashback… IEC/TC57 Reference
Source: UCA Users Group, Power Point Presentation, Kay Clinard, IEC 61850 TC57 Scope, 2001.

www.fdos.ca
14
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
IEC61850 Substation Architecture
Station Bus - 10/100/1000 MB Ethernet
AMI Network
IEEE 1703 / ANSI C12.22 Gateway
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.

www.fdos.ca
15
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
StandardAMI™
IEEE 1701/
ANSI C12.18
Protocol
Specification
for ANSI Type 2
optical port
Physical Port
IEEE 1702/
ANSI C12.21
Protocol
Specification
for telephone
MODEM
communication
IEEE 1703/
ANSI C12.22
Protocol
Specification for
Interfacing to
Data
Communication
Networks
IEEE 1377/ANSI C12.19 Utility Industry End Device Data Table
Data Representation
Transfer Protocol
AMR Functionality
Local
Telephone
Any-Net (two-way
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
& one-way & Blurts)
Mechanical IEEE 1704/3 Comm. Module
ANSI OP
Type 2
AEIC / MC / AMI Guidelines Utility Compliance Requirement for ANSI C12 Standards
IEC 61850
IEC 61850
IEC 61850
IEC 61850

www.fdos.ca
16
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
17
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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
object instances End-device Classes.
› IEEE 1377 / ANSI C12.19 shares this layer with Layer 7,6,5
(services) of the IEEE 1703 / ANSI C12.22 to form the core
communication language.
› To avoid confusion we refer to the IEEE 1377 / ANSI C12.19
portion of the Application Layer as the Application Process
and IEEE 1703 / ANSI C12.22 portion of the Application
Layer as the Application Language (ACSE+EPSEM).
› Parameter translation is needed when mapping between
the Application Process to/from Application Language to
realize its service requests and responses.
APPLICATION
PRESENTATION
SESSION
TRANSPORT
NETWORK
DATA LINK
PHYSICAL
7
6
5
4
3
2
1

www.fdos.ca
18
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
An IEEE 1703 / ANSI C12.22 Node
C12.19 Device
Application
Process
Layer (7-5)
Tables
EPSEM
ACSE
Layers (1-4)
Connection
To Native
Network
Interface
C12.22 Node
C12.22 Network Segment
Local Port
C12.22 Node: “A point on the (AMI) network that attaches to a
C12.22 Network Segment. C12.22 Nodes contain one or more
C12.22 Applications. Each C12.22 Node shall have a unique
ApTitle on a C12.22 Network.”
C12.19 Device: “A C12.22 Node that contains (IEEE 1377 / ANSI
C12.19) Tables.”
C12.22 Application: An application entity that implements a set of
services and procedures that permit one or more devices to
interact within the AMI framework of a C12.22 Network. A
C12.22 Application Process may contain C12.19 Tables.
C12.22 Network Segment: “A collection of C12.22 Nodes that
can communicate with each other without forwarding
messages through a C12.22 Relay.”

www.fdos.ca
19
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…An IEEE 1703 / ANSI C12.22 Node
C12.19 Device
Application
Process
Layer (7-5)
Tables
EPSEM
ACSE
Layers (1-4)
Connection
To Native
Network
Interface
C12.22 Node
Local Port
C12.22 Relay: “A C12.22 Node that provides address resolution,
Datagram segmentation and optionally Message forwarding
services to other C12.22 Nodes (which may be located on the
different C12.22 Network Segments).”
Local Port: “A physical interface that is directly attached to the
C12.22 Node; or a physical interface that is located in the
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
Application Process of the C12.22 Node…”
Native Network: Not defined by IEEE 1703 / ANSI C12.22.
A transport service that can be used deliver C12.22 Message
payloads. Example: TCP, UDP, ZigBee, BACNet, DNP,
LONWorks, DLMS…)

www.fdos.ca
20
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Nodes, Devices and Comm. Modules
C12.22 Nodea
a. If it contains Tables then it is also a C12.19 Device.
C12.22 Devicea
C12.22 Comm. Modulea
OSI Layer
Defined Generic AMI Node Local Port on the Node Device Side
Native
Network
Side
Layer 7 C12.19 + EPSEM + ACSE
Segmentation Sub-layerb
b. Guarantees delivery of arbitrarily large messages over any native network.
C12.19 + EPSEM + ACSE
Segmentation Sub-layer
C12.19 + EPSEM + ACSE
Segmentation Sub-layer
Defined
(Register,
Resolve)c
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.
Not Defined
Layer 6 Not Defined Null Null Null Not Defined
Layer 4 Not Defined Defined Defined Defined Not Defined
Layer 2 Not Defined Defined Defined Defined Not Defined
Layer 1 Not Defined Defined
only for ANSI Type 2d
d. Provide backward compatibility with ANSI C12.18 (R2006).
Defined Defined Not Defined

www.fdos.ca
21
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Connecting Nodes to Comm. Modules
C12.19 Device
Application
Layer (7-5)
C12.19 Tables
C12.22 EPSEM
C12.22 ACSE
Layers (1-4)
C12.22 Layer 4
C12.22 Layer 2
C12.22 Layer 1
Layers (1-4)
C12.22 Layer 4
C12.22 Layer 2
C12.22 Layer 1
C12.22 Communication Module
C12.22 Comm. Module
C12.22 Device to C12.22 Comm. Module Connector
C12.22 Dev.
Local Port
C12.22 Node
C12.22 Device
Application
Layer (7-5)
C12.22 EPSEM
C12.22 ACSE
(Auto Register,
Resolve)
Layers (1-4)
of Native
Network
C12.22 Layer 4
C12.22 Layer 2
C12.22 Layer 1
Application
Layer (7-5)
of Native
Network

www.fdos.ca
22
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
23
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…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).
› The physical interface signals (ANSI C37.90.1-2002, ANSI C62.41-2002)
Pin # Signal Function
C12.22 Device
(DTE)
C12.22 Comm.
Module (DCE) Performance
1 RxD Receive Data Input Output 256 kbits/seca
a. 256kbits/sec up to 1m, or up to 4Mbits/sec with high-speed cable.
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
6 GND Common Ground Common Ground Common Ground
1 2 3 - 5 6
Front View
max. 1m @ 256kbits/sec.

www.fdos.ca
24
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
25
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Getting a Meter on the AMI Network
C12.22
Relay
C12.22
Relay
C12.22
Master Relay
WAN
PWR Outage
Notification Host
UTILITY
Authentication Host
BILLING
Notification Host
5 Utility
3
Service Verification
6 Registration complete, Appliance is on-line
1 Power-up appliance
2 Broadcast registration request
Notification
4 Approve registration

www.fdos.ca
26
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Getting a Host on the AMI Network
C12.22
Relay
C12.22
Relay
C12.22
Master Relay
WAN
Peer Application
Notification Host
Service Provider
Authentication Host
Supervisory
Notification Host
5 Utility
3
Service Verification
6 Registration complete, granted access to AMI network
1 Start-up
2 Broadcast registration request to be associated on the AMI Network
Notification
4 Approve registration
Client Application
Host

www.fdos.ca
27
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
28
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
C12.22 Relays Build AMI Networks
C12.19 Device
Application
Layer (7-5)
C12.19 Tables
C12.22 EPSEM
C12.22 ACSE
Layers (1-4)
To Native
Network
Interface
Layers (1-4)
To Native
Network
Interface X
Layers (1-4)
To Native
Network
Interface Y
C12.22 Node X.2
C12.22 Network Segment Y
C12.22 Node X.1
C12.22 Network Segment X
(e.g. Internet)
C12.22 Relay App
Application
Layer (7-5)
C12.19 Tables
C12.22 EPSEM
C12.22 ACSE
C12.22 Node Y.1
(e.g.Zigbee)
C12.19 Device
Application
Layer (7-5)
C12.19 Tables
C12.22 EPSEM
C12.22 ACSE
Layers (1-4)
To Native
Network
Interface
C12.22 Node Y.2

www.fdos.ca
29
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
C12.22 Gateways Bridge AMI Networks
C12.19 Device
Application
Layer (7-5)
C12.19 Tables
C12.22 EPSEM
C12.22 ACSE
Layers (1-4)
To Native
Network
Interface
Layers (1-4)
To Native
Network
Interface X
Layers (1-4)
TCP/IP
ReducedStack
over Ethernet
C12.22 Node X.2
Ethernet
C12.22 Node X.1
C12.22 Network Segment X
A C12.19 App to IEC 61850 App Gateway
Application
Layer (7-5)
C12.19 Tables
C12.22 EPSEM
C12.22 ACSE
IEC 61850 Client
(e.g.Internet)
IEC 61850 Server
Application
Layer (7-5)
Map 68150 IEC
GSSE message
to/from C12.19
Elements
May share the same “wire”
Layers (1-4)
TCP/IP
ReducedStack
over Ethernet
Application
Layer (7-5)
68150 App
MMS or GSSE
messages.

www.fdos.ca
30
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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. Prior to 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.

www.fdos.ca
31
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
StandardAMI™ Topology
C12.22
Host
C12.22
Master Relay
C12.22
Node
Other
Device
C12.22
Gateway
C12.22
Device
C12.22 Comm
Module
C12.22
Gateway
Other
Device
C12.22
Local Port
C12.22 Network Segment 1 (Any LAN or WAN)
C12.22
Relay
C12.22 Comm
Module
C12.22 Comm
Module
C12.22
Node
C12.22
Device
C12.22 Comm
Module
C12.22 Comm
Module
C12.22
Local Port
C12.22
Relay
C12.22
Node
C12.22
Master Relay
Provider
ApTitle Server
Internet
Host (AMR)
C12.22
Device Class
Registry
C12.22
Local Port
C12.19 Registry Server
C12.19 App
C12.19 App
C12.19 App
C12.19 App
C12.19 App
C12.19 App

www.fdos.ca
32
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
33
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
34
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…Serving Multiple Applications
C12.22
Relay
C12.22
Relay
Service Provider
Master Relay
AMI
C12.22 PWR Outage
Notification Host
C12.22 Utility
Authentication Host
C12.22 Billing
Notification Host
Network
.100.21 .100.22
.100.20
.100
.200.2
.100.1
.300.4
.100.3
.200.1003
.200.1002
.200.1001
.200.1000 .300.1007
.300.1006
.300.1005
.300.1004
Node’s Relative ApTitle
Absolute ApTitle of this Node
Provider‘s Relative ApTitle
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
C12.19 Device Class
Context: 2.16.124.113620.1.19
C12.22 Application
Context: 2.16.124.113620.1.22
C12.22 ApTitle Root Context:
2.16.124.113620.1.22.0
C12.22 Security Mechanism
context:
2.16.124.113620.1.22.2
AMI Physical Network is Transparent
C12.22 Wireless Network Segment C12.22 PLC Network Segment
C12.22 Internet Network Segment
C12.22 Internet Network Segment
A
C12.22
Network
Segment
⎬
⎫
⎭
= 2.16.124.113620.1.19.73.84.82.78 = 2.16.124.113620.1.22.2.3
2.16.124.113620.1.22.0.100.21

www.fdos.ca
35
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…A C12.22 Network is Actually Very
Simple
Master Relay
Relay
Node
Host
Node Node Node Host
C12.22 Network Segment 1
C12.22 Network Segment 2
C12.22 Network
Bridge
Router
Host
Node
Node
⎬
⎫
⎭

www.fdos.ca
36
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Serving Multiple Organizations
C12.22
Relay
C12.22
Relay
Provider 100
Master Relay
AMI
C12.22 PWR Outage
Notification Host
C12.22 UTILITY 1
Authentication Host
C12.22 Utility 1 AMR
Notification Host
Network
.100.21 .100.22
.100.20
.100
.100.2
.100.1
.200.2
.200.1
.100.1003
.100.1002
.100.1001
.100.1000 .200.1002
.100.1006
.200.1001
.200.1000
Provider 200
Master Relay
C12.22 Utility 2
Authentication Host
C12.22 Utility 2 AMR
Notification Host
.200.22
.200.20
.200
Register with .100 if willing to accept .100 access for .200 network
segment.
Forward resolutions to all but .100.1006 destinations to .100
.100.1006 registers with .200.2
.200.1000 registers with .200.2,
which registers with .200,
which registers with .100
which registers with .200

www.fdos.ca
37
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
38
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
One-way Message vs. Blurt10
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.
C12.22 Network Message
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
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
0A <service-length>
40 <full-write>
00 03 <tableid>=Std Table 3
00 04 <count>=4 bytes
00 08 00 00 ANSI C12.19 <data>
F8 <cksum>
Total bytes transmitted = 47
C12.22 Blurt
17 A3 54 <calling-AP-title>=.23.4567
14 <ed-class>=.20.0.0.0
40 <full-write>
00 03 <tableid>=Std Table 3
00 04 <count>
00 08 00 00 ANSI C12.19 <data>
F8 <cksum>
Total bytes transmitted = 14

www.fdos.ca
39
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Managing Authenticity, Reliability and
Audit-Trail

www.fdos.ca
40
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
41
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…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)

www.fdos.ca
42
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…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.

www.fdos.ca
43
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…Access to Table Data is also Role-based
Decade 4 - Security Tables
Table 44 - Access
Control for table and
group
Table 45 - Key
(C12.18 or C12.21)
Table 40 - Dimension
Security Limiting
Table 43 - Default
Access Control for
table and group
Table 41 - Actual
Security Limiting
Table 00 - General
Configuration
permission
ANSI C12.22 Network
access, authentication and
encryption validated ok.
Table 42 - Security
and
Define/Validate
group association
Request Granted
Table 46 - Ext. Key
(C12.22)
5
4
3
2
1

www.fdos.ca
44
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…Table Data Privacy is Role-based
R
o
l
e
0
=
A
M
R
R
O
l
e
1
=
L
R
R
o
l
e
2
=
P
O
E
R
23
61
62
63
64
21
05
03
00
R
o
l
e
0
=
A
M
R
R
o
l
e
1
=
L
R
R
o
l
e
2
=
P
O
E
R
Access Roles setting
Table 43 + 44
Access control
Table 42
pow3erman
r3s3arch3r
r3ad3r
sup3rvisor
Table Number
Passwords
Annotations:
AMR: Automated meter reading for billing
purposes.
LR: Load Research.
POER:Power Outage Emergency Response.
ANSI C12.19 Tables:
00: General Configuration
03: Device Mode Status
05: Device Identification
21: Actual Register Limits
23: Current Register Data
61: Actual Load Profile Limits
62: Load Profile Control
63: Load Profile Status
64: Load Profile Data Set 1
Note: Some implementers confuse between Authentication and Role-based Security. Role-
based security is what is ultimately granted to a user of C12.19 Tables according to Tables 43
and 44 after the perimeter and authentication requirements were met.

www.fdos.ca
45
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…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. Electronic Serial 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.

www.fdos.ca
46
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…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.

www.fdos.ca
47
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…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.

www.fdos.ca
48
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Utility Industry Tables: Device Class.0.2
Configuration Source Register Display Security Event Log
User Defined Load control RTP
Time & Load Profile
Networking
Time-Of-Use
Telephone Extended
Source
Relays Quality of
service
0 1 2 3 4 5 6 7
8 9 10 11 12 13 15
Extended
14
User Defined
Demand Response
One-way
Devices
16
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

www.fdos.ca
49
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
User Defined Data Models and Blurts
ED Addr ED Class C12.18 PSEM EUDT Table Write Request n bits
Reading
ED Node Relative ApTitle
Registered Data Model (token code)
Identifies the reference TDL/EDL files to be obtained from the registry.
TBL 0 TBL 1 TBL 11 TBL 12 TBL140 TBL 141 TBL 143
TBL 15 TBL 27 TBL 28
With EUDT knowledge, Master Station has
information about where the data elements
belong in the Formal data structures in the “virtual
meter”.

www.fdos.ca
50
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Device Class Registration = Information
SRC CL T# Data as EUDT
C12.22 Host
C12.19 Master Stn
Any AMR App
C12.19 TDL
C12.19 EDL
HHF EDL
Token
Enterprise Data
EUDT blurt
ED
Any Network
for CLASS
Data C12.19 Encoded
C12.19 Tables

www.fdos.ca
51
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Putting It All Together
C1219EDL-2008.xsd
C1219TDL.xsl
C1219TDLSchema.xsd
DefaultSet.xml
ExportData.xml
Vendor-Doc.pdf
Vendor-TDL.xml(.a.b.c.d)
Vendor-EDL.xml(.a.b.c.d)
C1219TDL-2008.xml
Vendor-EDL.xsd
Import/Export Data
UtilSiteData.xml
Input Data
Registrar
Vendor
Registrar
MDMS Application
Remote User Application
Registry
AMR System
AMI System

www.fdos.ca
52
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
…System Evolution Management
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
2) The registered universal identifier of
the security mechanism deployed by the
C12.22 Node.
When the Mechanism Name
Element is set to
2.16.124.113620.1.22.2 the ANSI
Standard C12.22 security
mechanism are used (DES/CBC,
DESede/CBC or AES128/CTR). Implicit
support is also provided for ANSI C12.21
Security Mechanisms.
3) The registered root ApTitle of the
C12.22 service provider or organization.
The network service
provider may deploy
C12.22 Master Relays
to service the assigned
area on behalf of a
utility. ApTitle Root context is
2.16.124.113620.1.22.0
Multiple Master Relays can be
deployed to link diverse systems.
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.
1) The registered
of the C12.19
universal identifier
Device Class (data model)

www.fdos.ca
53
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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
Time-of-use
Provides for time setup (R2008 has a high precision time), schedule and calendar setting for
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.

www.fdos.ca
54
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.
C12.19 Table Data
Decade No. Decade Name Provides

www.fdos.ca
55
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
56
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
ANSI C12.19 Tables
C12.19
Master Station
An End-Device is
the closest device
to the point of
measurement,
which holds the
Utility Industry
Standard Tables
C12.19
Master Station
The closest device to
the sensor or control
point within a metering
application communi-
cation system which is
compliant with the
Utilty Industry End
Device Data Tables

www.fdos.ca
57
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
The ANSI Standards C12 Protocol Suite
IEEE 1701/
ANSI C12.18
Protocol
Specification
for ANSI Type 2
optical port
Physical Port
IEEE 1702/
ANSI C12.21
Protocol
Specification
for telephone
MODEM
communication
IEEE 1703/
ANSI C12.22
Protocol
Specification for
Interfacing to
Data
Communication
Networks
IEEE 1377/ANSI C12.19 Utility Industry End Device Data Table
Data Representation
Transfer Protocol
AMR Functionality
Local
Telephone
Any-Net (two-way
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
& one-way & Blurts)
Mechanical IEEE 1704/3 Comm. Module
ANSI OP
Type 2
AEIC / MC / AMI Guidelines Utility Compliance Requirement for ANSI C12 Standards
IEC 61850
IEC 61850
IEC 61850
IEC 61850

www.fdos.ca
58
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
ANSI Standard C12 Transport Protocols
Public or
Private WAN
ANSI Std. C12.22
Relay
PBX / Telephone
Modem
C12.19 Metering
Data Acquisition
ANSI Std. C12.18 Point-to-Point Communication Protocol
C12.21 Telephone Communication Protocol
ANSI Std. C12.22
Relay
ANSI Std. C12.19 End-Devices
C12.22 Network Communication Protocol
+
ANSI Std. C12.19
Gateway =
C12.19
Meter
Legacy
Meter or Other
Any Network Protocol
ANSI Std. C12.22 Network
Communication
Protocol
ANSI Std. C12.21 MODEM Protocol
Which contain
Tables
A.K.A.
End-Device

www.fdos.ca
59
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
The C12 AMR
Deployment
View
Di
r
ectAccess C12.
18 /Tel
ephone C12.
21
C12.
19 M et
er
G at
ew ay
Appl
i
cat
i
on
C12.
22 Rel
ay
Pr
i
vat
e or
Publ
i
c W AN
C12.
19
Aut
om at
ed
M et
er
Readi
ng
Syst
em
I
nt
r
anet
PVC /
I
nt
er
net
RF/
PO T/
LAN
Com m
M odul
e
RF/
PO T/
LAN
Com m
M odul
e
I
M O /
Ut
i
l
i
t
y/
Agent
s
C12.
19 Dat
a O bj
ectSyst
em s
C12.
19 t
unnel
i
ng overC12.
18/
21 orC12.
22
C12.
19/
C12.
22
Regi
st
r
y
C!
2.
22
M ast
erRel
ay
C12 Regi
st
r
y Ser
vi
ces f
orReal
-
Ti
m e
access t
o M et
erDat
a M odel
,Secur
i
t
y
Dat
a M odeland Node Nam es

www.fdos.ca
60
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Visible Components
of a Gas Meter
Communication
Data Port
Measurements
Multipliers and Units
Displayed Registers
Mechanical
Seal
Name
Plate
Internal
Other
Indicators
Lots of GAS
Controls

www.fdos.ca
61
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Corresponding Data Components
of a Gas Meter
Lots of GAS
Communication
Protocols
Meter Settings
Calibration & Configuration
Data Sources
Data Type Identification
Registers & Display Controls
Tariff & Rate
Schedules
Access
Control and Validation
Access
Logs &
Set Limits, Peak
Customer
Information
and User Names
& Multipliers
Demand Controls
Audit Trail

www.fdos.ca
62
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Visible Components
of an Electricity Meter
Reset
Communication
Data Port
Measurements
Multipliers and Units
Displayed Registers
Mechanical
Seal
Name
Plate
Controls
Flow
Indicator

www.fdos.ca
63
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Corresponding Data Components
of an electricity meter
Reset
Communication
Protocols
Meter Settings
& Configuration
Data Sources
Data Type Identification
Registers & Display Controls
Tariff & Rate
Schedules
Access
Control and Validation
Access
Logs &
Set Limits, Peak
Customer
Information
and User Names
& Multipliers
Demand Controls

www.fdos.ca
64
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
A
Table
is
Just
Like
a
Tax
Form

www.fdos.ca
65
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
66
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
End-Device Standard Tables Assignments
› Standard Table Grouping
Ø General Configuration table, 00
Ø Dimension limiting tables 10/11, 20,21,..., X0,X1
Ø Identification tables (05, 06)
Ø Description tables (01, 02, 06)
Ø Status tables (03, 04)
Ø Procedure tables (07, 08)
Ø Metering application tables (X2.. X9)
An End-Device is
the closest device
to the point of
measurement,
which holds the
Utility Industry
Standard Tables
The closest device to
the sensor or control
point within a metering
application communi-
cation system which is
compliant with the
Utilty Industry End
Device Data Tables

www.fdos.ca
67
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
End-Device Standard Tables Data Model
User Defined Load control RTP
Time & Load Profile
Networking
Time-Of-Use
Telephone Extended
Source
Relays Quality of
service
0 1 2 3 4 5 6 7
8 9 10 11 12 13 15
22
A Table Function Limiting Tables
Extended
14
User Defined
Demand Response
One-way
Devices
16
A Decade
General
Configuration
Table
ANSI C12.22-2008
ANSI C12.21-1999 / ANSI C12.19-2008
New in ANSI C12.19-2008
ANSI C12.19-1997

www.fdos.ca
68
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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

www.fdos.ca
69
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
End-Device tables activation
User Defined Load control
Time & Load Profile
Network
Time-Of-Use
Telephone Extended
Source
Relays Quality
of service
0 1 2 3 4 5 6 7
8 9 10 11 12 13 15
Time & Load Profile
Network
Time-Of-Use
Telephone Extended
Source
Relays Quality
of service
0 1 2 3 4 5 6 7
8 9 10 11 12 13 15
Active Tables
Activation Event
Pending Tables
or Activation
Time
Extended
14
User Defined

www.fdos.ca
70
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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
Manufacturer defined)
• During transmission, Pending Tables are
prefixed with a fixed length activation record
known as the “pending event description”.
• The pending event description is not
included in element offset or element index
calculation in the request of a partial read or
write.
• When using the offset/octet-count method the
C12.19 Application Process shall not
include the pending header length in the
octet offset or count of the request.
• When using the element index/count method,
C12.19 Application Process shall not
include the pending header element index
TYPE PE_STIME_DATE_RCD = PACKED RECORD
CASE GEN_CONFIG_TBL.TM_FORMAT OF
0: RESERVED: ARRAY[5] OF FILL8;
1: YEAR : BCD;
MONTH : BCD;
DAY : BCD;
HOUR : BCD;
MINUTE : BCD;
2: YEAR : UINT8;
MONTH : UINT8;
DAY : UINT8;
HOUR : UINT8;
MINUTE : UINT8;
3: U_TIME : UINT32;
FILL : FILL8;
END;
END

www.fdos.ca
71
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Transmission Guidelines of Pending
Tables
TYPE STATUS_BFLD = BIT FIELD OF UINT8
EVENT_CODE : UINT(0..3);
SELF_READ_FLAG : BOOL(4);
DEMAND_RESET_FLAG : BOOL(5);
RESERVED : FILL(6..7);
END;
MEMBER EVENTS_SELECTOR = STATUS_BFLD;
• Pending tables may be written distinctively.
• There is no process that guarantees delivery of a
specific pending table when read from a C12.19
Device.
• Implementation shall assume a maximum stacking
of 1 pending table per active table (TDL documents
this limit).
TYPE EVENT_STORAGE_RCD = PACKED RECORD
CASE EVENTS_SELECTOR.EVENT_CODE OF
0: PE_STIME_DATE = PE_STIME_DATE_RCD;
1: WEEKS : UINT8;
DAYS : UINT8;
HOURS : UINT8;
MINUTES : UINT8;
SECONDS : UINT8;
2: MFG_CODE : ARRAY[5] OF UINT8;
END;
END;
TYPE PENDING_EVENT_DESC_RCD = PACKED RECORD
EVENTS_SELECTOR : STATUS_BFLD ;
EVENT_STORAGE: EVENT_STORAGE_RCD ;
END;
MEMBER PENDING_EVENT_DESC =
PENDING_EVENT_DESC_RCD ;
Pseudo Syntax as per User Guide

www.fdos.ca
72
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
73
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
74
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
75
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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;

www.fdos.ca
76
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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”/>

www.fdos.ca
77
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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>

www.fdos.ca
78
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
C12.19 Device Table Data Access Rules
Read Table
or
Write Table
Go ahead
Make My Day
if you can
Did you
ask for
permission?

www.fdos.ca
79
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Access to Table Data
Time & Load Profile
Network
Time-Of-Use
Telephone Extended
Source
Relays Quality
of service
0 1 2 4 5 6 7
8 9 10 11 12 13 15
Read
Write
UTILITY
DATABASE
3
C12.19 can deliver very large payloads.
Do we have to
read/write the
whole thing?
Partial Table Read
and Partial Table
Write is possible.

www.fdos.ca
80
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
81
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
82
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Reference Methods for Table Elements
Reference By Name By Index By Octet Offset
Element
(any non BIT
FIELD)
• Master Station
• TDL declaration
• EDL element name
• Master Station
• Communication
• Master Station
• Communication
Sub-Element
(BIT FIELD or
SET member)
• Master Station
• TDL declaration
• TDL reference
• Master Station • Master Station
• Communication
(Use at own peril!
May be rejected by
C12.19 Device)
Final Element
(build-in type that
delivers value)
• Master Station
• TDL declaration
• TDL reference
• Master Station
• Commutation (if not
a BIT FIELD or SET
member)
• Master Station
• Communication (if
a BIT FIELD or SET
member, will return
octets or may be
rejected by meter)

www.fdos.ca
83
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Navigating Table Data Elements
element names, octet-offset/count and element-index/count
Table Data Description
Example
Datum
size
(octets)
Offset Index
relative to
TYPE_2_RCD
TYPE TYPE_1_RCD = PACKED RECORD
IDENTIFIER_1 : UINT32; 4 1 1.0
IF (CONDITION) THEN
IDENTIFIER_2 : UINT16; 2 optional 5 1.1
END;
IDENTIFIER_3 : UINT8; 1 5 or 7 1.2
END;
TYPE TYPE_2_RCD = PACKED RECORD
IDENTIFIER_4 : UINT8; 1 0 0
IDENTIFIER_5 : TYPE_1_RCD; 5 or 7 1 1
END;
Element Name
Derived Type
Name
“Built-in” Type
Derived Type

www.fdos.ca
84
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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

www.fdos.ca
85
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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

www.fdos.ca
86
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
What Do the C12.19 Standard and
Manufacturer Tables Include?
Everything
under the Sun

www.fdos.ca
87
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
What is really inside an end-device?
Will everything
under the sun
fit inside my
4 bit micro
processor?
No dad!
Just use what
you need.

www.fdos.ca
88
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
What is really inside an End-device?
Not a 4 bit micro-processor!

www.fdos.ca
89
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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?

www.fdos.ca
90
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
End-device Tables Construction
Rules
› 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).
Do we
have to
memorize
this?

www.fdos.ca
91
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
92
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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 1 - Sources
• Decade 2 - (data) Registers
• Decade 3 - (local) Display
• Decade 4 - (access) Security
• Decade 5 - Time & TOU
• Decade 6 - (recorder) Profile
• Decade 7 - History (logger)
• Decade 8 - User Defined
• Decade 9 - Telephone

www.fdos.ca
93
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Table Definition Syntax
... More details

www.fdos.ca
94
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
95
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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> ;

www.fdos.ca
96
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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”/>

www.fdos.ca
97
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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.

www.fdos.ca
98
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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;

www.fdos.ca
99
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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>

www.fdos.ca
100
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
PACKED RECORD Transmission Order
A field is an element or final-element
Field 1 (UINT32):
Field 2 (UINT8):
Field 3 (UINT24):
Field 4 (UINT16):
Little endian transmission:
Field 1
Field 2
Field 3
Field 4
Big endian transmission:
Field 1
Field 2
Field 3
Field 4
0
1
2
3
0
0
0
1
1
2
0
1
2
3
0
0
1
2
0
1
3
2
1
0
0
2
1
0
1
0

www.fdos.ca
101
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Primitive Data Types
Defining
Word
Description TDL/EDL Schema
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
(-140737488355328..+140737488355327).
xsd:long
INT56 Forty-eight bit signed integer
(-36028797018963968..+36028797018963967).
xsd:long
INT64 Sixty-four bit signed integer
(-9223372036854775808..+9223372036854775807).
xsd:long

www.fdos.ca
102
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Primitive Data Types
Defining
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)

www.fdos.ca
103
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Binary and Character Data Types
› CHARs are governed by
Defining
Word
Type
BINARY An atomic array of UINT8 xsd:hexBinary
STRING An atomic array of CHAR xsd:string
CHAR_FORMAT Implementation of data type CHAR
TDL/EDL Schema
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"

www.fdos.ca
104
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Non-integer Data Type
NI_FORMAT1 or
NI_FORMAT2 Implementation of data type NI_FMAT1 or NI_FMAT2
TDL/EDL Schema
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

www.fdos.ca
105
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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
TM_FORMAT Implementation of data types defined above
TDL Schema
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
minutes + sub-minutes)
not applicable
4 Universal time relative to 1970 GMT expressed as a counter (32-bit
seconds + sub-seconds)
not applicable

www.fdos.ca
106
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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

www.fdos.ca
107
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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);
FILLER : FILL(3..5);
END;
TIER_DRIVE : UINT(6..7);
SPECIAL_SCHD_ACTIVE : UINT(8..11);
SEASON : UINT(12..15);
END;

www.fdos.ca
108
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
Bit Field Statement
Grammar Definition
TDL Schema
Type
BOOL(<value>) Boolean bit field having the value zero (0) for FALSE or one (1)
for TRUE, in bit position <value>.
xsd:boolean
INT(<value>..<value>) Signed binary integer represented by a range of successive
bits. The range <value>..<value> represents the “start” and
“end” bit positions of the integer in the bit field.
xsd:int
UINT(<value>..<value>) Unsigned binary integer represented by a range of successive
bits. The range <value>..<value> represents the “start” and
“end” bit positions of the unsigned integer in the bit field.
xsd:unsignedInt
FILL(<value>..<value>) Fill bits represented by a range of successive bits. The range
<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).
xsd:unsignedInt fixed (0)

www.fdos.ca
109
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
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>

www.fdos.ca
110
Device
Class
Security
Mechanism
Provider
Root
ApTitle
Security
Mechanism
Device
Class
Provider
Root
ApTitle
C12R
BIT FIELD OF UINT16
Transmission Order
15
Little endian transmission:
Big endian transmission:
Bits
8 to 15
Bits
0 to 7
Bits
0 to 7
Bits
8 to 15
CURR_SUMM_TIER
or CURR_TIER
CURR_DEMAND_TIER
or FILLER
SPECIAL_SCHD
ACTIVE
TIER_DRIVE
SEASON
0
1
0
1
0
1
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

Moise.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a Moise.pdf

Similar a Moise.pdf (20)

Último

Último (20)

Moise.pdf