introduction to tdl and edl for use by ami systems ... · › ami to any-network comm. module: ieee...

Presentedby

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-8634Fax: +1-403-203-7071e-mail: [email protected]: 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.ca2

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

DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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™DefinitionsANSI C12.22 StandardAMI Network™ communication architectureANSI C12.19 Tables' structure

› ANSI C12.19 syntaxPublished Table definition syntaxTable elements and constants values used to describe metering device instancesTable 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.ca3


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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:0001: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:0019:00

OFF PEAK

MID PEAK

ON PEAK

OFF PEAK

MID PEAK

ON PEAK

SUMMER

WINTER

www.fdos.ca5


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 DisconnectRemote 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.ca6


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

ANSI C12.19 + ANSI C12.22Performance 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.ca10


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Using StandardsANSI C12.19 + ANSI C12.22 + IEC 61850

to Meet the Totality of Requirements

www.fdos.ca11


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Flashback… CEBus Architecture

APPLICATION

SESSION

TRANSPORT

NETWORK

DATA LINK

PHYSICAL

1990’s CEBus architectureCEBus is based on the OSI “Reduced Stack” model which includes only four of the seven layers:

› Application Layer› Network Layer› Data Link Layer› Physical LayerMost 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

Laye

r S

yste

m M

anag

emen

t

INFRARED

FIBER OPTIC

COAX

POWER LINE

RF

TWISTED PAIR

www.fdos.ca13


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Flashback… IEC/TC57 Reference

Source: UCA Users Group, Power Point Presentation, Kay Clinard, IEC 61850 TC57 Scope, 2001.

www.fdos.ca14


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

IEC61850 Substation ArchitectureStation 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.ca15


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

StandardAMI™

IEEE 1701/ANSI C12.18ProtocolSpecificationfor ANSI Type 2optical port

Physical Port

IEEE 1702/ANSI C12.21ProtocolSpecificationfor telephoneMODEMcommunication

IEEE 1703/ANSI C12.22ProtocolSpecification for Interfacing to DataCommunicationNetworks

IEEE 1377/ANSI C12.19 Utility Industry End Device Data TableData Representation

Transfer Protocol

AMR Functionality

Local

Telephone

Any-Net (two-way

AMR Functionality: AEIC Guidelines –Compliance certification requirementsMC IS-E-01 –Event loggers for metering devices and systems

Data Representation: IEEE 1377 / ANSI C12.19 –Binary raw data, EDL/XML Data, TDL knowledgeCommunication: 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 NetworkIEEE P1704 –Communication Module for interoperability

& one-way & Blurts)

Mechanical IEEE 1704/3 Comm. ModuleANSI OPType 2

AEIC / MC / AMI Guidelines Utility Compliance Requirement for ANSI C12 Standards

IEC 61850IEC 61850

IEC 61850IEC 61850

www.fdos.ca16


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 levelCommon 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.ca17


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

The Application Layer is the KeyThe 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.ca18


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

An IEEE 1703 / ANSI C12.22 Node

C12.19 Device

ApplicationProcess

Layer (7-5)

TablesEPSEMACSE

Layers (1-4)

ConnectionTo NativeNetworkInterface

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

…An IEEE 1703 / ANSI C12.22 Node

C12.19 DeviceApplication

ProcessLayer (7-5)

TablesEPSEMACSE

Layers (1-4)

ConnectionTo NativeNetworkInterface

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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

SideLayer 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.ca21


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Connecting Nodes to Comm. Modules

C12.19 Device

Application Layer (7-5)

C12.19 TablesC12.22 EPSEMC12.22 ACSE

Layers (1-4)

C12.22 Layer 4C12.22 Layer 2C12.22 Layer 1

Layers (1-4)


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


C12.22 EPSEMC12.22 ACSE(Auto Register,

Resolve)

Layers (1-4)of NativeNetwork



of NativeNetwork

www.fdos.ca22


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Functional Requirements of AnyComm. 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, andforward 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.ca23


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

…Functional Requirements of aComm. 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 FunctionC12.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.ca24


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Getting a Meter on the AMI Network

C12.22Relay

C12.22Relay

C12.22Master Relay

WAN

PWR OutageNotification Host

UTILITYAuthentication Host

BILLINGNotification 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.ca26


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Getting a Host on the AMI Network

C12.22Relay

C12.22Relay

C12.22Master Relay

WAN

Peer ApplicationNotification Host

Service ProviderAuthentication Host

SupervisoryNotification 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 ApplicationHost

www.fdos.ca27


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 relaysC12.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.ca28


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

C12.22 Relays Build AMI Networks

C12.19 DeviceApplication Layer (7-5)


Layers (1-4)

To NativeNetworkInterface

Layers (1-4)

To NativeNetwork

Interface X

Layers (1-4)

To NativeNetwork

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 AppApplication Layer (7-5)


C12.22 Node Y.1

(e.g.Zigbee)



Layers (1-4)


C12.22 Node Y.2

www.fdos.ca29


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

C12.22 Gateways Bridge AMI Networks



Layers (1-4)


Layers (1-4)

To NativeNetwork

Interface X

Layers (1-4)

TCP/IPReduced Stack 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



IEC 61850 Client

(e.g.Internet)

IEC 61850 Server


Map 68150 IEC GSSE message to/from C12.19

Elements

May share the same “wire”

Layers (1-4)

TCP/IPReduced Stack over Ethernet


68150 AppMMS or GSSE

messages.

www.fdos.ca30


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

StandardAMI™ Topology

C12.22Host

C12.22Master Relay

C12.22Node

OtherDevice

C12.22Gateway

C12.22Device

C12.22 CommModule

C12.22Gateway

OtherDevice

C12.22Local Port

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

C12.22Relay

C12.22 CommModule

C12.22 CommModule

C12.22Node


C12.22Device

C12.22 CommModule

C12.22 CommModule

C12.22Local Port

C12.22RelayC12.22

Node


C12.22Master Relay

ProviderApTitle Server

Internet

Host (AMR)C12.22

Device ClassRegistry

C12.22Local Port

C12.19 Registry Server

C12.19 AppC12.19 App

C12.19 App

C12.19 App

C12.19 App

C12.19 App

www.fdos.ca32


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

C12.22 Messages Realize theCore 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.ca33


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

…Serving Multiple Applications

C12.22Relay

C12.22Relay

Service ProviderMaster Relay

AMI

C12.22 PWR OutageNotification Host

C12.22 UtilityAuthentication Host

C12.22 BillingNotification 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.3Sec Mech=.3

C12.19 Device ClassContext: 2.16.124.113620.1.19

C12.22 ApplicationContext: 2.16.124.113620.1.22

C12.22 ApTitle Root Context: 2.16.124.113620.1.22.0

C12.22 Security Mechanismcontext:

2.16.124.113620.1.22.2AMI 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 C

12.2

2 N

etw

ork

Seg

men

t

⎬⎫

⎭

= 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.ca35


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

…A C12.22 Network is Actually Very Simple

Master Relay

Relay

NodeHost

Node Node Node Host

C12.22 Network Segment 1

C12.22 Network Segment 2

C12.22 Network

Bridge

RouterHost

NodeNode

⎬⎫

⎭

www.fdos.ca36


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Serving Multiple Organizations

C12.22Relay

C12.22Relay

Provider 100Master Relay

AMI

C12.22 PWR OutageNotification Host

C12.22 UTILITY 1Authentication Host

C12.22 Utility 1 AMRNotification 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 200Master Relay

C12.22 Utility 2Authentication Host

C12.22 Utility 2 AMRNotification 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.ca37


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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), orC12.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.ca38


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 Message60 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.00A <service-length>40 <full-write>00 03 <tableid>=Std Table 300 04 <count>=4 bytes00 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 300 04 <count>00 08 00 00 ANSI C12.19 <data>F8 <cksum>

Total bytes transmitted = 14

www.fdos.ca39


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Managing Authenticity, Reliability and Audit-Trail

www.fdos.ca40


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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), andthe C12.22 Master Relay is granted permission from a C12.22 Authentication Host to register the applicant, andthe C12.22 Master Relay is willing to register the applicant, andall C12.22 Relays that lay between the registering node and its peers agree to service the applying node, andthe data encoded by the registering node is authenticated by the C12.22 Authentication Host using information that is not transmitted over the network, alternativelyencryption 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.ca42


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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), ortriple DES with Cipher Block Chaining (DESede/CBC), orAES128/CTR, orexternally defined (as per registered security mechanism).

› In the context of an ANSI C12.19 standard deviceTables may be password protected, andaccessible 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.ca43


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

…Access to Table Data is also Role-basedDecade 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 groupTable 41 - Actual Security Limiting

Table 00 - General Configurationpermission

ANSI C12.22 Network access, authentication and

encryption validated ok.

Table 42 - Security

andDefine/Validate

group association

Request Granted

Table 46 - Ext. Key

(C12.22)

5

4

32

1

www.fdos.ca44


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

…Table Data Privacy is Role-based

Role 0

= A

MR

ROle 1

= LR

Role 2

= P

OER

23

61

62

63

64

21

05

03

00

Role 0

= A

MR

Role 1

= L

RRole

2= P

OER

Access Roles settingTable 43 + 44

Access controlTable 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 Configuration03: Device Mode Status05: Device Identification21: Actual Register Limits23: Current Register Data61: Actual Load Profile Limits62: Load Profile Control63: Load Profile Status64: 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 43and 44 after the perimeter and authentication requirements were met.

www.fdos.ca45


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

…Security Policy Management› Security management is confined to the programming of the C12.19

DeviceANSI C12.19 Security TablesANSI C12.19 History and Event logger tables need to be implemented.ANSI C12.19 Network TablesANSI 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.ca48


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 ExtendedSource

Relays Quality ofservice

0 1 2 3 4 5 6 7

8 9 10 11 12 13 15

Extended

14

User DefinedDemand ResponseOne-wayDevices

16

Table Data is encoded in binary for transmission, Enterprise data exchangeData model is defined by the Standard, extensible by vendors and encoded in XML

www.fdos.ca49


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 143TBL 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.ca50


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 blurtED

Any Network

for CLASSData C12.19 Encoded

C12.19 Tables

www.fdos.ca51


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

…System Evolution Management

DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 registeredof the C12.19

universal identifierDevice Class (data model)

www.fdos.ca53


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

C12.19 Table DataDecade 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.ca54


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 DataDecade No. Decade Name Provides

www.fdos.ca55


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Minimal Requisition Requirements for a StandardAMI™ Device

a. Utility industry end device data tablesIEEE 1377 / ANSI C12.19-2008, the common data format for StandardAMI™ Devices.

b. Network Protocol for the transmission of TablesIEEE P1703 / ANSI C12.22-2008, Protocol for Interfacing to Data Communication Networks.

c. Local Optical port access with 100% availability to the operatorRequest 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 modelProvides 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 relaysEnables plug-and-play deployment and inter-utility communication that facilitate utility asset sharing, testing, audit and validation.

www.fdos.ca56


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

ANSI C12.19 Tables

C12.19Master Station

An End-Device is the closest device

to the point of measurement, which holds the Utility Industry

Standard Tables

C12.19Master 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.ca57


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

The ANSI Standards C12 Protocol Suite

IEEE 1701/ANSI C12.18ProtocolSpecificationfor ANSI Type 2optical port

Physical Port

IEEE 1702/ANSI C12.21ProtocolSpecificationfor telephoneMODEMcommunication

IEEE 1703/ANSI C12.22ProtocolSpecification for Interfacing to DataCommunicationNetworks

IEEE 1377/ANSI C12.19 Utility Industry End Device Data TableData Representation

Transfer Protocol

AMR Functionality

Local

Telephone

Any-Net (two-way

AMR Functionality: AEIC Guidelines –Compliance certification requirementsMC IS-E-01 –Event loggers for metering devices and systems

Data Representation: IEEE 1377 / ANSI C12.19 –Binary raw data, EDL/XML Data, TDL knowledgeCommunication: 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 NetworkIEEE P1704 –Communication Module for interoperability

& one-way & Blurts)

Mechanical IEEE 1704/3 Comm. ModuleANSI OPType 2

AEIC / MC / AMI Guidelines Utility Compliance Requirement for ANSI C12 Standards

IEC 61850IEC 61850

IEC 61850IEC 61850

www.fdos.ca58


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

ANSI Standard C12 Transport Protocols

Public orPrivate WAN

ANSI Std. C12.22Relay

PBX / TelephoneModem

C12.19 MeteringData Acquisition

ANSI Std. C12.18 Point-to-Point Communication Protocol

C12.21 Telephone Communication Protocol

ANSI Std. C12.22Relay

ANSI Std. C12.19 End-Devices

C12.22 Network Communication Protocol

+ ANSI Std. C12.19Gateway =

C12.19Meter

LegacyMeter or Other

Any Network Protocol

ANSI Std. C12.22 NetworkCommunication

Protocol

ANSI Std. C12.21 MODEM Protocol

Which containTables

A.K.A.End-Device

www.fdos.ca59


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

The C12 AMR Deployment

View

Direct Access C12.18 / Telephone C12.21

C12.19 M eter G atew ay

Application

C12.22 Relay

Private or Public W AN

C12.19 Autom ated M eter Reading System

Intranet

PVC / Internet

RF/PO T/LAN

Com m M odule

RF/PO T/LAN

Com m M odule

IM O /Utility/Agents C12.19 Data O bject System s

C12.19 tunneling over C12.18/21 or C12.22

C12.19/C12.22 Registry

C!2.22 M aster Relay

C12 Registry Services for Real-Tim e access to M eter Data M odel, Security Data M odel and Node Nam es

www.fdos.ca60


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Visible Componentsof a Gas Meter

CommunicationData Port

MeasurementsMultipliers and Units

Displayed Registers

MechanicalSeal

NamePlate

Internal

OtherIndicators

Lots of GASControls

www.fdos.ca61


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Corresponding Data Componentsof a Gas Meter

Lots of GAS

CommunicationProtocols

Meter SettingsCalibration & Configuration

Data SourcesData Type Identification

Registers & Display Controls

Tariff & RateSchedules

AccessControl and Validation

AccessLogs &

Set Limits, Peak

CustomerInformation

and User Names

& Multipliers

Demand Controls

Audit Trail

www.fdos.ca62


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Visible Componentsof an Electricity Meter

Reset

CommunicationData Port

MeasurementsMultipliers and Units

Displayed Registers

MechanicalSeal

NamePlate

Controls

FlowIndicator

www.fdos.ca63


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Corresponding Data Componentsof an electricity meter

Reset

CommunicationProtocols

Meter Settings& Configuration

Data SourcesData Type Identification

Registers & Display ControlsTariff & RateSchedules

AccessControl and Validation

AccessLogs &

Set Limits, Peak

CustomerInformation

and User Names

& Multipliers

Demand Controls

www.fdos.ca64


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

A T

able

is J

ust L

ike

a T

ax

For

m

www.fdos.ca65


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

End Device (C12.19 Device) Table Types

• Standard TablesThose data types, structures and groups of structures whose functions and contents are fully defined and documented by the C12.19 Standard.

• Manufacturer TablesThose data types, structures and groups of structures whose functions and contents are fully defined and documented by the C12.19 Device manufacturer.

• User Defined TablesA collection of tables that aggregate elements from other Manufacturer and Standard Tables; other than User Defined Tables.

• Pending TablesStandard 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.ca66


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

End-Device Standard Tables Assignments

› Standard Table GroupingGeneral Configuration table, 00Dimension limiting tables 10/11, 20,21,..., X0,X1Identification 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.ca67


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

End-Device Standard Tables Data Model


User Defined Load control RTP

Time & Load Profile

Networking

Time-Of-Use


Relays Quality ofservice

0 1 2 3 4 5 6 7

8 9 10 11 12 13 15

22

A Table Function Limiting Tables

Extended

14

User DefinedDemand ResponseOne-wayDevices

16

A Decade

GeneralConfigurationTable

ANSI C12.22-2008ANSI C12.21-1999 / ANSI C12.19-2008

New in ANSI C12.19-2008

ANSI C12.19-1997

www.fdos.ca68


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

End-Device tables activation


User Defined Load control

Time & Load Profile

Network

Time-Of-Use


Relays Qualityof service

0 1 2 3 4 5 6 7

8 9 10 11 12 13 15



Time & Load Profile

Network

Time-Of-Use



0 1 2 3 4 5 6 7

8 9 10 11 12 13 15

Active Tables

Activation Event

Pending Tables

or ActivationTime

Extended

14

User Defined

www.fdos.ca70


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

End-Device Tables Extension Data Model (cont...)

› User defined tablesDefined 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.ca74


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Table Definition SyntaxAssuming 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 SyntaxTABLE 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.ca75


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

C12.19 Device Table Data Access Rules

Read Table

or

Write Table

Go ahead

Make My Dayif you can

Did youask forpermission?

www.fdos.ca79


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Access to Table Data



Time & Load Profile

Network

Time-Of-Use



0 1 2 4 5 6 7

8 9 10 11 12 13 15

Read

Write

UT

ILIT

Y D

AT

AB

AS

E

3

C12.19 can deliver very large payloads.

Do we have toread/write thewhole thing?

Partial Table Read and Partial Table Write is possible.

www.fdos.ca80


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 orSET member)

• Master Station• TDL declaration• TDL reference• EDL element name

• 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• EDL element name

• 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.ca83


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Navigating Table Data Elementselement names, octet-offset/count and element-index/count

Table Data DescriptionExample

Datum size

(octets)

Offset Index

relative to TYPE_2_RCD

TYPE TYPE_1_RCD = PACKED RECORD

IDENTIFIER_1 : UINT32; 4 1 1.0IF (CONDITION) THEN

IDENTIFIER_2 : UINT16; 2 optional 5 1.1END;

IDENTIFIER_3 : UINT8; 1 5 or 7 1.2END;

TYPE TYPE_2_RCD = PACKED RECORD

IDENTIFIER_4 : UINT8; 1 0 0IDENTIFIER_5 : TYPE_1_RCD; 5 or 7 1 1

END;

Element Name

Derived TypeName

“Built-in” Type

Derived Type

www.fdos.ca84


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 RECORDSBIT FIELDs of 8/16/32 bits

› SETs (boolean flags)› ARRAYs (collections)› Run-time defined types

CHARacter and STRINGNon-integer numbers

www.fdos.ca85


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Built-in Elementary Data Representation

› DefineData format for transmission.Intrinsic precision for specified data type.

› Encoding includesRepresentation of signed integers.Representation of non integers.Representation of character data.Representation of time and data values.Transmission data order

www.fdos.ca86


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

What Do the C12.19 Standard and Manufacturer Tables Include?

Everythingunder the Sun

www.fdos.ca87


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

What is really inside an end-device?

Will everythingunder the sunfit inside my4 bit micro

processor?

No dad!Just use whatyou need.

www.fdos.ca88


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

What is really inside an End-device?

Not a 4 bit micro-processor!

www.fdos.ca89


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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 wehave tomemorizethis?

www.fdos.ca91


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Group Exercise on Table Selections

Based on the previous slide list the Table Decades which might be required tooperate 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.ca93


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Table Definition Syntax... More details

www.fdos.ca94


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

TABLE Definition ExampleAssuming 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.


The TDL equivalent is

<table number=“52” name=“CLOCK_TBL” type=“CLOCK_STATE_RCD”/>

www.fdos.ca97


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

PACKED RECORD example (publication)

TYPE MANUFACTURER_IDENT_RCD = PACKED RECORDMANUFACTURER : 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.ca99


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

PACKED RECORD Transmission OrderA field is an element or final-element

Field 1 (UINT32):

Field 2 (UINT8):

Field 3 (UINT24):

Field 4 (UINT16):

Little endian transmission:

Field 1Field 2Field 3Field 4

Big endian transmission:

Field 1Field 2Field 3Field 4

0123

0

0

0

1

1

2

0123001201

3210021010

www.fdos.ca101


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Primitive Data Types

DefiningWord

Description TDL/EDL SchemaType

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Primitive Data TypesDefining

WordDescription TDL/EDL Schema

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Binary and Character Data Types

› CHARs are governed by

DefiningWord

Description TDL/EDL SchemaType

BINARY An atomic array of UINT8 xsd:hexBinary

STRING An atomic array of CHAR xsd:string

CHAR_FORMAT Implementation of data type CHARTDL/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.ca104


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Non-integer Data TypeNI_FORMAT1 orNI_FORMAT2 Implementation of data type NI_FMAT1 or NI_FMAT2

TDL/EDL SchemaType

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Date and Time Data TypesHTIME_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 aboveTDL 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-bitminutes + sub-minutes)

not applicable

4 Universal time relative to 1970 GMT expressed as a counter (32-bitseconds + sub-seconds)

not applicable

www.fdos.ca106


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

BIT FIELD Example (publication)

TYPE STATUS_BFLD = BIT FIELD OF UINT16IF ACT_TIME_TOU_TBL.SEPARATE_SUM_DEMANDS_FLAG THEN

CURR_SUMM_TIER : UINT(0..2);CURR_DEMAND_TIER : UINT(3..5);

ELSECURR_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.ca108


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Bit Field Statement

Grammar DefinitionTDL 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 successivebits. 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 successivebits. 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 isalways zero (0).

xsd:unsignedInt fixed (0)

www.fdos.ca109


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

BIT FIELD OF UINT16 Transmission Order

15

Little endian transmission:

Big endian transmission:

Bits8 to 15

Bits0 to 7

Bits0 to 7

Bits8 to 15

CURR_SUMM_TIERor CURR_TIER

CURR_DEMAND_TIERor FILLER

SPECIAL_SCHDACTIVE

TIER_DRIVESEASON

01

01

0

10

1234567891011121314

www.fdos.ca111


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

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”/>

www.fdos.ca112


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

ARRAY Element Order

Single dimension ARRAY:

ARRAY[5]

00 01 02 03

10 11 12 13

20 21 22 23

ARRAY[3,4]

Multiple dimensions ARRAY:

000102031011121320212223

0 1 2 3 4

01234

Note:Transmission order independent of the architecture(Little / Big endian)

Deprecated

Deprecated

www.fdos.ca113


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

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 ” />

www.fdos.ca114


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

SET Bit Order

SET[3]:

Transmission order:Bits

8 to 15Bits0 to 7

0 1 2

Bits16 to 23

012

Note:Transmission order independent of the architecture(Little / Big endian)

1501234567 1011121314 23 202122 19 16171889

www.fdos.ca115


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

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

www.fdos.ca116


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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;


www.fdos.ca117


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Deployment Strategy for TDL/EDL AMI

C1219TDL-xxxx.xml (.0)

C1219TDL.xsl

Table Processor

C1219EDL.xsd

C1219TDLSchema.xsd

DefaultSet.xml

AMI Application

EDClassTDL.xml(.a.b.c.d)

EDClassEDL.xml

www.naedra.org

AMR Data Acquisition

C1219Section9.doc

www.fdos.ca119


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

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.

www.fdos.ca120


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

C1219TDLSchema.xsd Elements

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

ProviderRoot

ApTitle

C12R

ANSI C12.19/MC12.19/IEEE-1377 Standards for Page 12Utility Industry End Device Data Tables

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"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"title="AMERICAN NATIONAL STANDARDC12.19-1997 Utility Industry End Device Data Tables"version="1.0"standard="http://www.ansi.org/1997/C12.19-1997"registry="NAEDRA"isoBranch="2.16.124.113620.1.19"deviceClass="0.1.0.0">

<decade name="TIME_OF_USE_DEC" number="5" label="Time-of-use tables"><description>

The tables in this decade provide information related to end device Date and Time and Time Of Use (TOU) operation.

</description>

<table name="CLOCK_STATE_TBL" number="55" type="CLOCK_STATE_RCD" label="Clock state table"><description>

This table provides the end device real time clock information.</description><bitField name="STATUS_BFLD" type="UINT16">

<description>Array of status entries of each TOU set.</description><if condiion="ACT_TIME_TOU_TBL.SEPARATE_SUM_DEMANDS_FLAG">

<then><subElement name="CURR_SUMM_TIER" type="UINT"

startBitInclusive="0" endBitInclusive="2"><description>

Active tier corresponding to summations. This variable is only used when the capability flag ACT_TIME_TOU_TBL.-SEPARATE_SUM_DEMANDS_FLAG (Table 51) = TRUE.

</description></subElement><subElement name="CURR_DEMAND_TIER" type="UINT"

startBitInclusive="3" endBitInclusive="5"><description>

Active tier corresponding to demands. This variable is only used when the capability flag ACT_TIME_TOU_TBL.SEPARATE_SUM_DEMANDS_FLAG (Table 51) == TRUE.

</description></subElement>

Table-Set Definitionsfor

AMERICAN NATIONAL STANDARD C12.19-1997Utility Industry End Device Data Tables

Version 1.02.16.124.113620.1.19.0.1.0.0

Reference Standard: http://www.ansi.org/1997/C12.19-1997Registered to: NAEDRAISO Branch: 2.16.124.113620.1.19End-Device relative class: .0.1.0.0 (Standard class)

9.1 Decade 5: Time-of-use tables (TIME_OF_USE_DEC)The tables in this decade provide information related to end device Date and Time and Time Of Use (TOU) operation.

9.1.1 Standard defined typesNone defined outside tables.

9.1.1.1 Standard table 55 : Clock state table (CLOCK_STATE_TBL)This table provides the end device real time clock information.

9.1.1.2 Standard table 10: Defined types

TYPE STATUS_BFLD = BIT FIELD OF UINT16IF ACT_TIME_TOU_TBL.SEPARATE_SUM_DEMANDS_FLAG THEN

CURR_SUMM_TIER : UINT(0..2);CURR_DEMAND_TIER : UINT(3..5);

ELSECURR_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;

TYPE CLOCK_STATE_RCD = PACKED RECORDCLOCK_CALENDAR : LTIME_DATE;TIME_DATE_QUAL : CLOCK_TBL.TIME_DATE_QUAL_BFLD;STATUS : STATUS_BFLD;

END;

TABLE 55 CLOCK_STATE_TBL = CLOCK_STATE_RCD;

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

ProviderRoot

ApTitle

C12R

ANSI C12.19/MC12.19/IEEE-1377 Standards for Utility Industry End Device Data Tables


</then><else>

<subElement name="CURR_TIER" type="UINT" startBitInclusive="0" endBitInclusive="2"><description>

Number representing the tier that is currently active in the meter. This vari-able is only used when the capability flag ACT_TIME_TOU_TBL.-SEPARATE_SUM_DEMANDS_FLAG (Table 51) = FALSE.

</description></subElement><subElement name="FILLER" type="FILL"

startBitInclusive="3" endBitInclusive="5"/></else>

</if><subElement name="TIER_DRIVE" type="UINT"

startBitInclusive="6" endBitInclusive="7"><description>Tier drive source code.</description>

<enumerator><enum value="0" text="Tier selection is controlled by

CALENDAR_TBL.TIER_SWITCHES (Table 54)"/><enum value="1"

text="Tier selection is not controlled by this standard"/><enum value="2"

text="Tier selection is not controlled by this standard"/><enum value="3"

text="Tier selection is not controlled by this standard"/></enumerator>

</subElement><subElement name="SPECIAL_SCHD_ACTIVE" type="UINT"

startBitInclusive="8" endBitInclusive="11"><enumerator>

<enum value="0" text="Special schedule 0 active"/><enum value="1" text="Special schedule 1 active"/><enum value="2" text="Special schedule 2 active"/><enum value="3" text="Special schedule 3 active"/><enum value="4" text="Special schedule 4 active"/><enum value="5" text="Special schedule 5 active"/><enum value="6" text="Special schedule 6 active"/><enum value="7" text="Special schedule 7 active"/><enum value="8" text="Special schedule 8 active"/><enum value="9" text="Special schedule 9 active"/><enum value="10" text="Special schedule 10 active"/><enum value="11" text="Special schedule 11 active"/><enum value="15" text="No special schedule active"/>

</enumerator>

Identifier /sub-identifer Value Definition

STATUS_BFLD Array of status entries of each TOU set. CURR_SUMM_TIER Active tier corresponding to summations. This

variable is only used when the capability flag ACT_TIME_TOU_TBL.-SEPARATE_SUM_DEMANDS_FLAG (Table 51) = TRUE.

CURR_DEMAND_TIER Active tier corresponding to demands. This variable is only used when the capability flag ACT_TIME_TOU_TBL.-SEPARATE_SUM_DEMANDS_FLAG (Table 51) = TRUE.

CURR_TIER Number representing the tier that is currently active in the meter. This variable is only used when the capability flag ACT_TIME_TOU_TBL.-SEPARATE_SUM_DEMANDS_FLAG (Table 51) == FALSE.

TIER_DRIVE Tier drive source code. 0 Tier selection is controlled by

CALENDAR_TBL.TIER_SWITCHES (Table 54).

1 Tier selection is not controlled by this standard2 Tier selection is not controlled by this standard3 Tier selection is not controlled by this standard

SPECIAL_SCHD_ACTIVE0 Special schedule 0 active.1 Special schedule 1 active.2 Special schedule 2 active.3 Special schedule 3 active.4 Special schedule 4 active.5 Special schedule 5 active.6 Special schedule 6 active.7 Special schedule 7 active.8 Special schedule 8 active.9 Special schedule 9 active.10 Special schedule 10 active.11 Special schedule 11 active.15 No special schedule active.

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

ProviderRoot

ApTitle

C12R

ANSI C12.19/MC12.19/IEEE-1377 Standards for Page 12Utility Industry End Device Data Tables


</subElement><subElement name="SEASON" type="UINT"

startBitInclusive="12" endBitInclusive="15"><description>Current end device season number.</description>

</subElement></bitField><packedRecord name="CLOCK_STATE_RCD">

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

Identifier /sub-identifer Value DefinitionSEASON Current end device season number.

CLOCK_STATE_RCDCLOCK_CALENDAR Current end device time.

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

ProviderRoot

ApTitle

C12R

ANSI C12.19/MC12.19/IEEE-1377 Standards for Utility Industry End Device Data Tables


www.fdos.ca125


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

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.

www.fdos.ca126


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

Regaining Interoperability and Multi-sourced Capability

Is specifying ANSI C12.19 compliance on a purchase order enough?

› ANSI C12.19 is about possibilitiesOptions for measurementsOptions for functionsOptions for capabilitiesOptions for operationetc.

› Guidelines is about collective users making selections from the available possibilitiesChosen measurements of interestChosen functions desiredChosen capabilities soughtChosen operations desiredetc.

... to enjoy the benefit of economy of scale...

www.fdos.ca127


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

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.

www.fdos.ca128


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

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.

www.fdos.ca129


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

C12.19 Evolution vs. Internet Growth

1992 1996 2000 2004 2006

Number of Internet Hosts

ANSI C12.18

ANSI C12.19/IEEE1377

ANSI C12.21

MC IS/IP-E-01-E

ISO/IEC 62056-62

350M

300M

250M

200M

150M

100M

50M

0

400M

450M

500M

2007

Hobbes' Internet Timeline Copyright (c) 1993-2006 by Robert H Zakon

ANSI C12.18 /IEEE1701 (R2006)

ANSI C12.21/IEEE1702 (R2006)

AEIC 1.0

ANSI C12.22/IEEE1703 (2008)ANSI C12.19/IEEE1377 (2008)AEIC 2.0 (2008)

SCE / E-100 SSM

1986

“Tucker Tables”Accepted by SEE(South Eastern

Electric Exchange)

www.fdos.ca130


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

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 expectationsperformance expectationsVerification 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.

www.fdos.ca131


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

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.

www.fdos.ca132


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

The Success Pyramid

SOR

DOE, MC, AMISCE, UTILITIES

Standards, AEIC Guidelines,Accreditation, User Group

Registry, Testing, Training

Better Performing Utilities & Compliant Vendors

General Statement Of Requirements

Dept. Of Energy, Measurement Canada,UtilityAMI, Southern California Edison and interested Utilities

StandardAMI™

Specific Requirements tabulated by US

Deployment

Benefits

www.fdos.ca133


DeviceClass

SecurityMechanism

ProviderRoot

ApTitle

SecurityMechanism

DeviceClass

ProviderRoot

ApTitle

C12R

The End