iec 62056 dlms/cosem workshop part 2:part 2:...

device

languagemessagespecification

IEC 62056 DLMS/COSEMworkshop

Part 2: Overview of main conceptsPart 2: Overview of main conceptsMETERING, BILLING & CRM/CIS EUROPE 2013

Amsterdam14th October 2013

Gyozo Kmethy, DLMS UA, President

TPAK2_DLMS_Concepts Slide No: 1

y y, ,

device

languageContents messagespecification

Contents

• Application modelling: the COSEM model• Messaging: the DLMS/COSEM Application layerg g pp y• Information security, end-to-end• Communication profilesCommunication profiles• Conformance testing and compliance certification• Int’l standardization and Companion specificationsInt l standardization and Companion specifications• Some characteristics of DLMS/COSEM• SummarySummary


device

languageVocabulary messagespecification

Vocabulary

• DLMS, “Device Language Message Specification”• application layer protocol• generalized concept for abstract modelling of communication• generalized concept for abstract modelling of communication

entities; specifies abstract object-related messaging services and protocols;

• COSEM “Companion Specification for Energy Metering”• COSEM, Companion Specification for Energy Metering• functional data model: models the functionality of the meter,

as seen at the interfaces; withOBIS th Obj t id tifi ti t d f bj t i• OBIS, the Object identification system used for object naming

• xDLMS (extended DLMS)• extension to DLMS

TPAK2_DLMS_ConceptsTPAK2_DLMS_Concepts Slide No: 3

device

languageDLMS/COSEM basics messagespecification

DLMS/COSEM basics

Standard for multi-utility, multi-media meter data exchange for

ll li ti t

70+ meter manufacturers have350 meter types certifiedall application segments 350 meter types certified

IEC 62056 / EN 13757-1IEC 62056 / EN 13757 1

National standards and companion specifications

Millions of meters installed, major smart metering projects

Interoperability on device level DLMS User Associationby common “language” 280+ members worldwide


device

languageDLMS/COSEM scope messagespecification

DLMS/COSEM scope

All applications

All energy types

All applications– driven by use cases

All market segments

Multiple mediap- driven by technology evolution


device

languageThe 3 step approach messagespecification

The 3 step approach

1. Modeling COSEM Interface Objects• Data model, to view the meter

Register 0..n Class_id=3, Version=0Attribute(s) Data Type Min Max Def1. logical_name (static) octet-string2 value (dyn ) instance specific

,functionality at its interface(s)• COSEM objects• OBIS Identification

Protocol Services to access

2. value (dyn.) instance specific3. scaler-unit (static) scal_unit_typeMethod(s) m/o1. reset o

• OBIS Identification system

• Messaging method to communicate with the model

2. Messaging

Protocol Services to access attributes and methods

Communication Protocol

Messages:

communicate with the model and to represent data as a series of bytes (APDUs)T t ti th d t

C0 01 00 03 01 01 01 08 00 FF 02

gService_Id( Class_Id, Instance_Id, Attribute_Id/Method_Id )

Encoding: (APDU)

• Transportation method to carry the messages between the metering equipment and the data collection system

3. Transportingdata collection system

Separation of application model and protocol: “orthogonality”


device

language

The DLMS/COSEM standardization framework message

specificationstandardization framework

IEC 62056-1-0 DLMS/COSEM standardization framework

IEC 62056-6-2 COSEM interface classes, IEC 62056-6-1 OBIS

IEC 62056-5-3 DLMS/COSEM Application layerAssociation, Access, Data protection and Block transfer services

Comm. profiles Comm. profiles Neighbourhood Comm. Profiles

Lower layer standards

IEC 62056-21 pWide Area Networks

IEC 62056-9 series

gNetworks

IEC 62056-8EN/TS 52056-8

series

Local Networks

IEC 62056-7 series

6-3-1, 6-42, 6-46, 6-47IEC 61334

EN, ITU-T, RFC

• New edition of the IEC 62056 suite in 2013 is in line with Blue Book Edition 11 and Green Book Edition 7


• To be in line with Blue Book Ed. 11, Amendment to IEC 62056-6-1 and IEC 62056-6 and IEC 62056-5-3 will be initiated

device

languageIEC 62056 DLMS/COSEM messagespecification

IEC 62056 DLMS/COSEM

Application modelling: gthe COSEM model


device

languageThe Blue Book messagespecification

The Blue Book

• Specifies the functional data model of the meter as seen through its interfacesg

• Using the object oriented approach, it specifies COSEM objects that interact with each other to realize the functions required

• The objects – and the data they hold – are identified by the OBIS codes

• Edition 11 released 27th August 2013

• Contains all recent additions for smart metering and advanced gas metering


device

languageObject modelling messagespecification

Object modelling

Th NAME tt ib tThe NAME attributeidentifies the data

Attribute 1

NAME Meaning

Data type

Any real-world things can be described by some

tt ib tAttribute 2

...

yp

Value rangeattributes

Each attribute has a meaning a data type Using the object means:

Attribute n

Method 1

meaning, a data typeand a value range

Methods allow performing...to read or write the attributes

Using the object means:

...

Method n

Methods allow performing operations on attributes

...to invoke the methodsAttributes and methods constitute an object


device

languageModelling, from reality to abstractionmessagespecification

g, y

Register

Interface classObject 1N 1 Register

Logical nameValue

Name 1Value

Scaler unit

Object 2Name 2

Scaler_unitReset

Active energy T1 1234 kWh

_

1234

ValueScaler_unit

Class name

Template

Reactive energy total 0123 kvarh

• All data in the meter are mapped to objects

Class nameLogical nameAttribute 2

• The objects provide the meter’s functional model• Similar objects make up an interface class (IC)• Each IC has a specific set of attributes and methods

Attribute nMethod 1M th d

GET/SET/ACTION...

p• All ICs are accessed with the same xDLMS services Method n


device

languageData model applies to all energy typesmessagespecification

pp gy yp

Template Interface classThree phase import

Objects

Class name Register

Σ Li A+ totalValuescaler_unitRegister 1Three phase import active energy1.0.1.8.0.25540153Class name

Logical name

Attribute 2

Registerlogical_name

value

40153 kWh

Attribute n

Method 1

Method n

scaler_unit

resetMeter volume

Register 2Forward undisturbed meter volume7.0.1.0.0.255,Method n

Valuescaler_unit

7.0.1.0.0.255, 7086 m3

• The same interface classes can be used for all energy types and for configuration and parameters

• OBIS codes are energy type specificTPAK2_DLMS_Concepts Slide No: 12

device

languageFlexibility: Tailor made meters from standard blocksmessagespecification

y

Standard object library

LDN Register

Clock

Profile

LDN Register

Assn.

1.0.1.8.0.255 12345 kWh

Mgmt Logical device

SAP

ScheduleMgmt. Logical device

LDN

SAP RegisterRegister

Register

• Standard building blocks to build the model of meters of any complexity

Assn. Comm.

model of meters of any complexity

• Mandatory objects: 2

• Logical Device Name, Association RegisterRegister Profile

P fil

Logical device #2

LDNg ,

• Residential meters: few 10 objects

• Industrial meters: few 100 objects

RegisterRegister

Clock Schedule

Profile

Assn.

LDN


device

languageSelf-description at object level messagespecification

Self description at object level

1 0 1 8 0 255 12345 kWh

Hold configuration &

1.0.1.8.0.255 12345 kWh

Mgmt. Logical deviceSAPHolds list of

logical devices

Identifies the

Hold configuration & identification data

Hold communication f

LDN

Assn

SAP RegisterRegister

Register

Comm.Identifies the source of the data

• Hold the list of

channel setup info

Hold measurement

Assn.

Logical device #2

Comm.

objects available, with version info and access rights

Provide context Each attribute delivers

Hold measurement values

Logical device #2Register

RegisterRegister

ProfileProfileLDN

• Provide context information

Each attribute delivers type and valueAssn. Clock ScheduleAssn.

Objective: minimize dependence on manufacturer specific informationTPAK2_DLMS_Concepts Slide No: 14

Aus Datenschutzgründen wurde das automatische Herunterladen dieser externen Grafik von PowerPoint verhindert. Klicken Sie auf der Statusleiste auf 'Optionen', und klicken Sie dann auf 'Externe Inhalte aktiv ieren', um diese Grafik herunterzuladen und anzuzeigen.

device

languageWide range of applications messagespecification

Wide range of applicationsEnergy / demand tariffs Billing

(historical Load profiles, data series

data)

Instantaneous values Power quality Line&transformer losses

Gas energy measurement I/O Control …and many more


device

languageApplications – Data model - Protocol messagespecification

Applications Data model Protocol

Mapping

OBIS Object identification system

COSEM Interface classesA

Energy typeB

ChannelC

QuantityD

ProcessingE

ClassificationF

Historical

pp g

COSEM Interface classesC la s s n a m e C a r d in a l i t y A tt r ib u te (s ) D a ta T y p e 1 . lo g ic a l_ n a m e (s ta t ic ) o c te t -s t r in g 2 . … . . ( . . ) … .. 3 . … … ( . . ) … .. S p e c if ic M e th o d (s ) ( i f r e q u ir e d ) m /o

xDLMS messaging servicesCOSEM A li ti l

1 . … .. … .. 2 . … . . … ..

servicesCOSEM Application layer

OSI / Internet lower layersProtocol data units


device

languageCOSEM interface classes – main categoriesmessagespecification

g

Time / event boundData storage• Data

Register

Time / event bound control• Clock

Schedule• Register• Profile

• Schedule• Scripts• Register monitor

Mgmt. objects• Association

Comm. setup• Local port• Association

• SAP• Logical dev. name• Security setup

• Local port• Modem• Internet•M Bus• Security setup

• Image transfer•M-Bus• PLC


device

language

New or modified COSEM interface classes Part 1 message

specificationCOSEM interface classes – Part 1B a s e

D a tac la s s _ id : 1

A s s o c ia t io n S N c la s s_ id : 1 2

C lo c k c la s s_ id : 8

R e g is te rc la s s _ id : 3

E x te n d e d re g is te rc la s s_ id : 4

A s s o c ia t io n L N c la s s_ id : 1 5

S A P A s s ig n m e n t c la s s_ id : 1 7

S c r ip t ta b le c la s s_ id : 9

S c h e d u le c la s s_ id : 1 0

D e m a n d re g is te r c la s s_ id : 5

S p e c ia l d a y s ta b le c la s s_ id : 1 1

A c tiv ity c a le n d a rl id 2 0

R e g is te r a c t iv a t io n l id 6

Im a g e tra n s fe r c la s s_ id : 1 8

P u s h s e tu p l id 4 0

P ro fi le g e n e r ic c la s s _ id : 7

U ti l i ty ta b le s

c la s s_ id : 2 0c la s s _ id : 6

R e g is te r m o n ito rc la s s_ id : 2 1

S in g le a c t io n s c h e d u le

S e c u r ity s e tu p c la s s_ id : 6 4

c la s s_ id : 4 0

R e g is te r ta b le c la s s _ id : 6 1

U til i ty ta b le s c la s s _ id : 2 6

S in g le a c t io n s c h e d u lec la s s_ id : 2 2

P a ra m e te r m o n ito rc la s s_ id : 6 5

S ta tu s m a p p in g c la s s _ id : 6 3

D is c o n n e c t c o n tro lc la s s_ id : 7 0

S e n s o r m a n a g e rc la s s_ id : 6 7

TPAK2_DLMS_Concepts Slide No: 18D a ta s to ra g e A c c e s s c o n tro l a n d m a n a g e m e n t

L im ite rc la s s_ id : 7 1

T im e a n d e v e n t b o u n d c o n tro l

IC s u n c h a n g e d N e w IC s o r n e w v e rs io n s o f e x is t in g IC s

device

language


specificationCOSEM interface classes – Part 2Base

IEC l l t t M d fi ti IEC t i t d i (1) tTCP UDP tIEC local port setupclass_id: 19

IEC HDLC setup

Modem configurationclass_id: 27

Auto answer

IEC twisted pair (1) setupclass_id: 24

TCP-UDP setupclass_id: 41

IPv4 setup EURIDISclass_id: 23 class_id: 28

Auto connectclass_id: 29

class_id: 42

M-Bus slave port setupclass_id: 25

IPv6 setupclass_id: 48

EURIDIS

MAC address setupclass_id: 43

GPRS modem setupclass_id: 45

IEC 8802-2 LLC Type 1 setup class_id: 57

M-Bus clientclass_id: 72

PPP setupclass_id: 44

IEC 8802-2 LLC G3 NB setup class_id: 58

Wireless Mode Q channel setup class_id: 73

GSM Diagnosticclass_id: 47

SMTP setupclass_id: 46

IEC 8802-2 LLC Type 3 setup class_id: 59

M-Bus master port setupclass_id: 74

Lower layers Internet PSTN / GSM / GPRS M-Bus


ICs unchanged New ICs or new versions of existing IC

device

language


specificationCOSEM interface classes – Part 3

Z igB ee S A S sta rtupS -FS K P H Y &M A C se tup

B ase

61334-32 LLC S S C S se tup

G 3 N B O FD M P LC M A C laye r coun te rs g p

c lass_id : 101

Z igB ee S A S jo inc lass_id : 102

P H Y &M A C se tupc lass_id : 50

S -FS K A ctive in itia to rc lass_ id : 51

S S C S se tupc lass_ id : 80

P R IM E N B O FD M P LC P hy laye r coun te rs

c lass id : 81

M A C laye r coun te rsc lass_ id : 90

G 3 N B O FD M P LC M A C se tupc lass id : 91

Z igB ee S A S A P S fragm en ta tion

c lass_id : 103

S -FS K M A C sync tim eou ts

c lass_id : 52

c lass_ id : 81

P R IM E N B O FD M P LC M A C se tupc lass_ id : 82

c lass_ id : 91

G 3 N B O FD M P LC 6LoW P A N adap ta tion

laye r se tup c lass_ id : 92

Z igB ee N e tw o rk C on tro l

c lass_ id : 104

S -FS K M A C coun te rs

c lass_id : 53

P R IM E N B O FD M P LC M A C functiona l pa ram s

c lass_ id : 83

Z igB ee Tunne l se tupc lass_id : 105

IE C 61334-4-32 LLC se tup

c lass_id : 55

S FS K

P R IM E N B O FD M P LC M A C coun te rs

c lass_ id : 84

P R IM E N B O FD M P LC S -FS K R epo rting system lis t

c lass_ id : 56

P R IM E N B O FD M P LC M A C ne tw o rk adm in. da ta

c lass_ id : 85

P R IM E N B O FD M P LC A li ti id tifi ti IC h d N ew IC s o r new ve rs ions

TPAK2_DLMS_Concepts Slide No: 20Z igbeeS -FS K P LC

A pp lica tion iden tifica tionc lass_ id : 86

P R IM E N B O FD M P LC G 3 N B O FD M P LC

IC s unchanged o f ex is ting IC

device

languageExample: Object model of a simple metermessagespecification

p j p

Measurement values

Li Active power C = 1

Electricity, A = 1Channel, B = 0

Li Active power, C = 1Time integral 1, energy, D = 8

f f Li A+, energy, current value, 1.0.1.8.0.255

Number of power failures in all three phases, 0.0.96.7.0.255

Logical device name, 0.0.42.0.0.255Parameters

Data exchange control objectsMeter constants, 1.0.0.3.x.255

Configuration program version number, 1.0.0.2.0.255g ,

Data exchange control objectsAssociation objects, 0.0.40.0.x.255Communication channel setup objects

Error object, 0.0.97.97.0.255


device

languageParameter monitor – new interface class messagespecification

Parameter monitor new interface classParameter monitor 0…n class_id = 65, version = 0

Attributes Data type Min. Max. Def. Short name

1. logical_name (static) octet-string x

2. changed_parameter structure x + 0x08

3. capture_time date-time x + 0x10

4. parameter_list array x + 0x18

Specific methods m/o

1. add_parameter (data 0 x + 0x20

2. delete_parameter (data) 0 x + 0x28

• monitor a list of COSEM object attributes holding parameters

f• allows building an audit trail of parameter changes• changed_parameter: holds the identifier and the value of the most recently

changed parameter – can be logged in a logbookg p gg g

• capture_time: provides data and time information showing when the value of the changed_parameter attribute has been captured

• parameter_list: holds the list of attributes that hold the parameter to be monitored


device

languageM-Bus client – new version messagespecification

M Bus client new versionM-Bus client 0...n class_id = 72, version = 1



2 mbus port reference (static) octet-string x + 0x082. mbus_port_reference (static) octet string x + 0x08

3. capture_definition (static) array x + 0x10

4. capture_period (static) double-long-unsigned x + 0x18

5. primary_address (dyn.) unsigned x + 0x20

6. identif ication_number (dyn.) double-long-unsigned x + 0x28

7 manufacturer id (dyn ) long-unsigned x + 0x30

•M-Bus protocol parameters are 7. manufacturer_id (dyn.) long-unsigned x + 0x30

8. version (dyn.) unsigned x + 0x38

9. device_type (dyn.) unsigned x + 0x40

10. access_number (dyn.) unsigned x + 0x48

11. status (dyn.) unsigned x + 0x50

12 alarm (dyn ) unsigned x + 0x58

pmapped to attributes• M-Bus functions are mapped to methods

12. alarm (dyn.) unsigned x + 0x58

13. configuration (dyn.) long-unsigned 0 x + 0x60

14. encryption_key_status (dyn.) enum 0 x + 0x68


1. slave_install (data) o x + 0x60

2. slave_deinstall (data) o x + 0x68

3. capture (data) o x + 0x70

4. reset_alarm (data) o x + 0x78

5. synchronize_clock (data) o x + 0x80

6. data_send (data) o x + 0x88

• In line with EN 13757-3:2012

• new configuration attribute contains information about the encryption mode and the number of encrypted bytes

7. set_encryption_key (data) o x + 0x90

8. transfer_key (data) o x + 0x98

new configuration attribute contains information about the encryption mode and the number of encrypted bytes

• new encryption_status attribute provides information on the status of the encryption key


device

languageClient user identification – new version messagespecification

Client user identification new version

• New attributes / methods in “Association SN” / “Association LN” ICs• user_list attribute contains the list of users allowed to use the AA

managed by the “Association SN” / “Association LN” instance

array user_list_entryuser_list_entry ::= structure{

user_id: unsigned,user_name visible-string

}

• user_id is carried by calling-AE-invocation-id field of the AARQ APDU >> extension to Green Book

• current_user attribute holds the identifier of the current user• add_user / remove_user methods manage users• an empty user list disables the function• an empty user_list disables the function


device

languagePush setup IC – new interface class messagespecification

Push setup IC new interface class

Push setup 0...n class_id = 40, version = 0

Attribute (s) Data type Min. Max. Def. Short name( ) yp


2. push_object_list (static) array x + 0x08

3. send_destination_and_method (static) structure x + 0x10

4 communication window (static) array x + 0x184. communication_window (static) array x + 0x18

5. randomisation_start_interval (static) long-unsigned x + 0x20

6. number_of_retries (static) unsigned x + 0x28

7. repetition_delay (static) long-unsigned x + 0x30


h bj t li t ifi th li t f tt ib t t b h d


1. push (data) m x + 0x38

• push_object_list specifies the list of attributes to be pushed

• selective access to • structures

• arrays e.g. profile buffers: recent periods, recent entries, columns of profile buffers

• push occurs in communication windows, with random delays and retries


device

language

Modelling a complex function – Push –with a set of interface classes message

specificationwith a set of interface classesDLMS/COSEM server

COSEM LDNClock

ProfilesRegisters

3456789 Push triggers

Push Single action schedule

Wh x 103

Push setup 1

push_object_list

d d ti ti

Push setup 2

push object listPush setup 3

Push triggers xDLMS DataNotification

service

Single action schedule

Push Script table

script 1

send_destination_and_method

push method

push_object_list


push method

push_object_list


push method

Push setup n

push_object_list


Push destination e.g.

DLMS/COSEM client

• Set up and manage pushing data by COSEM servers (the metering device) to COSEM clients (head end system)

Register monitor(s)

Alarm register, Alarm descriptor

script 2

script n

script 3

push methodpush method

clients (head end system) Local trigger

(e.g. event, push button)

p

execute method


device

languageAuto answer – new version messagespecification

Auto answer new versionAuto answer 0...n class_id = 28, version = 2



2. mode (static) enum x + 0x08

3. listening_window (static) array x + 0x10

4. status (dyn.) enum x + 0x18

5. number_of_calls (static) unsigned x + 0x20

6. number_of_rings (static) nr_rings_type x + 0x28

7. list_of_allowed_callers (static) array x + 0x30


• Allows modeling how the device manages the “Auto answer”function of the modem i e answering of incoming calls


function of the modem, i.e. answering of incoming calls• list_of_allowed_callers allows checking the calling number and to distinguish

between normal and wake-uplist_of_allowed_callers_element ::= structure{caller_id: octet-string,call type: enumcall_type: enum}


device

languageAuto connect – new version messagespecification

Auto connect new versionAuto connect 0...n class_id = 29, version = 2

Attributes Data type Min. Max. Def. Short nameAttributes Data type Min. Max. Def. Short name


2. mode (static) enum x + 0x08

3. repetitions (static) unsigned x + 0x10

(static)4. repetition_delay (static) long-unsigned x + 0x18

5. calling_window (static) array x + 0x20

6. destination_list (static) nr_rings_type x + 0x28


• Allows modeling the management of data transfer

1. connect (data) o x + 0x30

• Allows modeling the management of data transfer from the device to one or several destinations

• mode attribute provides new modes: permanently connected, permanently connected within calling window, usually disconnected

• connect method allows to connect when device is otherwise disconnected: canconnect method allows to connect when device is otherwise disconnected: can be invoked remotely (SMS, clip call) or locally


device

languageIEC twisted pair setup – new version messagespecification

IEC twisted pair setup new version

IEC twisted pair (1) setup 0...n class_id = 24, version = 1



2. mode (static) enum 0 1 x + 0x08

3. comm_speed (static) enum (2) (7) (2) x + 0x10

4. primary_address_list (static) primary_address_list_type x + 0x18

5. tabi_list (static) tabi_list_type x + 0x20


• Allows configuring communication channels

I li ith IEC 62056 31 2013• In line with IEC 62056-31:2013

• Supports DLMS/COSEM

• Allows speed negotiation up to 9 600 Baud

• Supports segmentation and reassembly

• Interface can be enabled / disabledTPAK2_DLMS_Concepts Slide No: 29

device

languageGSM diagnostic – new interface class messagespecification

GSM diagnostic new interface class

GSM diagnostic 0…n class_id = 47, version = 0



2. operator (dyn.) visible-string x + 0x08

3. status (dyn.) enum 0 255 0 x + 0x10

4. cs_attachment (dyn.) enum 0 255 0 x + 0x18

5. ps_status (dyn) enum 0 255 0 x + 0x20

6 ll i f (d ) ll i f t + 0 306. cell_info (dyn.) cell_info_type x + 0x30

7. adjacent_cells (dyn.) array x + 0x38

8. capture_time (dyn.) date-time x + 0x40

Specific methods m/oSpecific methods m/o

• allows monitoring selected parameters and logging these in a GSM diagnostic profile


device

languageIPv6 setup class – new IC messagespecification

IPv6 setup class new ICIPv6 setup 0…n class_id = 48, version = 0


1 logical name (static) octet-string x1. logical_name (static) octet-string x

2. DL_reference (static) octet-string x + 0x08

3. address_config_mode (static) enum 0 x + 0x10

4. unicast_IPv6_addresses array x + 0x18

5. multicast_IPv6_addresses (static) array x + 0x20

6. gateway_IPv6_addresses (static) array 0 x + 0x28

7. primary_DNS_address (static) octet-string 0 x + 0x30

8 secondar DNS address (static) octet string 0 + 0 388. secondary_DNS_address (static) octet-string 0 x + 0x38

9. traffic_class (static) unsigned 0 63 0 x + 0x40

10. neighbor_discovery_setup (static) array x + 0x48


1. add_IPv6_address (data) o x + 0x60

2. remove_IPv6_address (data) o x + 0x68

• Communication profiles that currently• Communication profiles that currently

specify using IPv6

• Narrow band OFDM PLC for PRIME networks

N b d OFDM PLC f G3 PLC• Narrow band OFDM PLC for G3-PLC networks

device

language

Interface classes to set up data exchange over PRIME narrow band OFDM PLC networks new message

specificationPRIME narrow-band OFDM PLC networks – new

• ITU-T G.9904 Management Information Base mapped to COSEM objects g pp jattributes / methods

• “61334-4-32 LLC SSCS setup”,

• “PRIME NB OFDM PLC Physical layer counters”

• “PRIME NB OFDM PLC MAC setup”: see 4.11.6

• “PRIME NB OFDM PLC MAC functional parameters”

• “PRIME NB OFDM PLC MAC counters”

“PRIME NB OFDM PLC MAC t k d i i t ti d t ”• “PRIME NB OFDM PLC MAC network administration data”

• “PRIME NB OFDM PLC Application identification”

The DLMS/COSEM narro band OFDM PLC profile for PRIME net orks is• The DLMS/COSEM narrow band OFDM PLC profile for PRIME networks is specified in prTS 52056-8-4 (see next page)

• Lower layers – PHY, MAC, Convergence – are specified in ITU-T G.9904


device

language

Interface classes to set up data exchange overG3 PLC narrow band OFDM PLC networks new message

specificationG3-PLC narrow-band OFDM PLC networks – new

• ITU-T G.9903 Management Information Base mapped to COSEM objects attributes / methodsobjects attributes / methods

• “G3 NB OFDM PLC MAC layer counters”

• “G3 NB OFDM PLC MAC setup”• G3 NB OFDM PLC MAC setup

• “G3 NB OFDM PLC 6LoWPAN adaptation layer setup”

The DLMS/COSEM narrow band OFDM PLC profile for G3 PLC• The DLMS/COSEM narrow band OFDM PLC profile for G3-PLC networks is specified in prTS 52056-8-5

• Lower layers – PHY MAC Convergence – are specified in ITU-TLower layers PHY, MAC, Convergence are specified in ITU T G.9903


device

languageZigBee ® setup ICs – example of a ZigBee ® networkmessagespecification

g p p g

• Use case: transport DLMS messages between HES and DLMS/COSEM p gmeter over a gateway and a ZigBee local network


device

languageZigBee ® setup ICsmessagespecification

g p

••ZigBee SAS Startup (class_id 101, version: 0);

Zi B SAS J i ( l id 102 i 0)•ZigBee SAS Join (class_id 102, version: 0);

•ZigBee SAS APS Fragmentation (class_id 103, version: 0);

•ZigBee Network Control (class_id 104, version: 0);

•ZigBee Tunnel Setup (class_id 105, version: 0).


device

languageOBIS data identification system messagespecification

OBIS data identification system

OBIS 'value group' A B C D E F

• Six value groups in a

0...255Quantity

0..126Historical values

Six value groups in a hierarchical structure

• Meaningful combinations standardised

0...64Channel

0...255Classification

e.g. tarification

• see next page

• Reduced codes: display and standard readout

0...15Medium

0...255Processing e.g.

integration

Example 1Electricity

1Channel

1 Σ Li A+

8Time int. 1

2Rate 2

255Current


device

languageCOSEM object definitions file messagespecification

COSEM object definitions file

• Object definitions excel file– http://www.dlms.com/documentation/listofstandardobiscodesandmain

tenanceproces/index.html

• Used by the Conformance Test Tool ( dat file)• Used by the Conformance Test Tool (.dat file)• OBIS helper: http://icube.ch/obishelper/obishelper.html


device

languageEvolutive messagespecification

Evolutive

• COSEM model can be extended to meet new requirements, while maintaining backward compatibilityg p y

• Extensions may specify– new OBIS codes– new versions of existing interface classesnew versions of existing interface classes

• Association object list provides the interface class version– new interface classes

• messaging services are common for all existing and future classesmessaging services are common for all existing and future classes• The COSEM model, the DLMS application layer and the

communication profiles can be extended independently


device

languageInnovation and competition messagespecification

Innovation and competition• To facilitate innovation and competition, specific

elements are allowedelements are allowed– manufacturer specific– country specificy p– consortia specific

• Specific elements may beifi i f d d IC ( ifi OBIS d )– specific instances of standard ICs (specific OBIS code)

– specific attributes or methods– specific interface classesp

• Information on specific elements has to be made available

• For standard features, manufacturer specific “hacks” are not allowed: requires discipline


device

languageCOSEM model properties summary messagespecification

COSEM model properties summary

Application modelling: COSEM interface objects Multi-energy: same interface classes for all energy types Multi energy: same interface classes for all energy types Self-descriptive: list of objects, access rights, data types – no

dependence on manufacturer information Efficient:Efficient:

data can be organized to profiles (similarly to „spreadsheets”) selective access to data of interest

Data identification: OBIS codes (logical name) Data identification: OBIS codes (logical name) Energy type specific identifiers Unambiguous data identification

F d l d lli li i Future developments: modelling new applications

TPAK2_DLMS_ConceptsTPAK2_DLMS_Concepts Slide No: 40

device



DLMS application layer services and messagesservices and messages


device

languageThe Green Book messagespecification

The Green Book• Specifies how to access data and how to transport the resulting messages over the communication media

• DLMS application layer services allow establishing secure associations between applications running in meters and centralapplications running in meters and central systems, and accessing COSEM objects to read / write data and execute actions remotely

• Pull and push operation is supported

• Also specifies how application data and messages are protected using cryptographic algorithms

C i ti fil if h• Communication profiles specify how DLMS/COSEM is used over various communication channels and media

• Edition 7 published 22nd December 2007Edition 7 published 22 December 2007

• Amendment 2 published 18th January 2012

• Amendment 3 will be published in November 2013


2013

• Edition 8 is in preparation

device

languageClient-server environment messagespecification

Client server environmentSERVICE.request/ .indicationSERVICE response/ confirm

Clientapplication

ServerapplicationSERVICE.response/ .confirmapplication

(e.g. Head End System)pp

(e.g. meter)

P fil 1 Profile 2 Profile n

SERVICE.request SERVICE.response

Application ApplicationApplication ApplicationACSE xDLMS

Profile 1 Profile 2 Profile n

pplayer

pplayer

pplayer

pplayer

ACSEAssociation Control

Service Element

xDLMSCOSEM object related services

General services

N-layer

N-1 layer

N-layer

N-1 layer

N-layer

N-1 layer

N-layer

N-1 layer

Physicallayer

Physicallayer

Physicallayer

Physicallayer• • •

Transportmedia

PSTN, GSM, Internet, PLC,

xDxy TPAK2_DLMS_Concepts Slide No: 43

device

languageDLMS services messagespecification

DLMS services

Association services: COSEM-OPEN, -RELEASE, -ABORT• provided by the Association Control Service Element (ACSE) to establish associations

between applications running in meters and central systems. Associations determine the rules of data exchange

COSEM object attribute / method related services• provided by the xDLMS ASE to access the COSEM objects: read/write attributes, execute methods

• Request / Response: GET / Read, SET / Write / Unconformed Write, ACTION, ACCESS (unified -GET, -SET, -ACTION)

• Unsolicited: EventNotification / InformationReport, DataNotification

• May carry unprotected or protected COSEM data

General protection services: Can be applied on any service in a layered / multi-level fashion by any party• General-Ciphering: compression authenticated encryption using AES-GCM

General-Block-Transfer service can be applied on any long protected or unprotected

General Ciphering: compression, authenticated encryption using AES GCM

• General-Signing using Elliptic Curve Digital Signature Algorithm (ECDSA)


pp y g p pservice between client and server

device

languageMessaging patterns between client and servermessagespecification

g g p

Pull operation

.request

.response

Client ServerPush operation

.indication

• Pull operation: Client requests, server responds. Uses request / response type services

• Push operation: Server sends pre-defined information to pre-defined destinations on pre-defined conditions using unsolicited services


device

languageMessaging end-to-end messagespecification

Messaging end to end


device

language

COSEM-OPEN service: application association establishment message

specificationapplication association establishmentObject model Application context

• referencing method

Application layer • use of ciphering

Authentication mechanism

• LLS: password

ACSE xDLMS • xDLMS context

f bl k

LLS: password

• HLS: challenge-response

Protocol stack

• conformance block (list of services)

• APDU length

Physical layer

Intermediate layers • Layer parameters e.g.:

• PDU length

• window size

• Application Associations determine the rules of the message exchange

• Contexts are configured in the server


g

• Client proposes contexts. The server may accept or reject if does not fit

device

languagexDLMS services to access the objects messagespecification

xDLMS services to access the objects• xDLMS services access attributes and methods of COSEM

objectsobjects– Read / Write attributes– Invoke methods (perform an action)

To access attributes and methods they must be referenced• To access attributes and methods, they must be referenced– Logical name referencing: { class_id, Instance_id, attribute / method_id }– Short name referencing: named variableDLMS i i d b APDU• xDLMS services are carried by APDUs– specified using ASN.1 abstract syntax– encoded in A-XDR (IEC 61334-6)

Future: encoded in XML

<GetResponse>

<GetResponsenormal>– Future: encoded in XML

C4 01C1 00 0906 0101480700FF

<InvokeIdAndPriority Value=“C1" />

<Result>

<Data>C4 01C1 00 0906 0101480700FF <OctetString Value="0101480700FF" />

</Data>

</Result>

</G tR l></GetResponsenormal>

</GetResponse>TPAK2_DLMS_Concepts Slide No: 48

device

language

Example: Get attributes of L3 voltage object using the GET service (LN referencing) message

specificationusing the GET service (LN referencing)

C001C1//Get.request normal, invoke_id, priority0003// class_if = 3, register0101480700FF//logical name 1.1.72.7.0.2550100//get attribute 1 (logical name) no selective accessC401C1//Get.response normal, invoke_id, priority000906//data, octet string(6)0101480700FF//logical name 1.1.72.7.0.255, L3 voltage inst.

C001C1 0003 0101480700FF 0200//Get attribute 2, valueC401C1//000600000905//data double long unsigned,2309D

C001C1 0003 0101480700FF 0300//Get attribute 3, scaler_unitC401C1//000202//data, structure of 2 elements

0FFF//integer, FF (-1 in 2’s complement)>>2309x0,1 = 230,91623//enum 23H=35D, Volts


device

languageReferencing: Logical name – Short namemessagespecification

g gGET / SETattribute {class_id, logical_name, attribute_id}

Class_id, version

Attribute(s) Read / Write / x = base_name

x + 8Mapping

1. logical_name

2. Attribute 2

Unconfirmed Write{named variable}

x + n*8

x+ ...

n. Attribute n

Specific method(s)

1 Method 1 x ...

x + offset

1. Method 1

n. Method n

ACTIONmethod {class_id, logical_name, method_id}

I t bilit Li t f i t d i ti t d b t li t d• Interoperability: List of services supported is negotiated between client and server


device

languageCommon xDLMS services for all objectsmessagespecification

j

• Client-server environment– Request: identifies the (list of)

data; selective access possibleGET

SET

ACTI

– Response: supplies the (list of) data with data type

– Requests and responses must be paired in the DCSN

Object

Read

T ION

be paired in the DCS• Event notification• Common service set for all

objects:

Name

Attribute 1

...

Read

Write objects:– new interface classes can be

easily added

...

Attribute n

Method(s)UnconfWrite

f f Interoperable and future proofTPAK2_DLMS_Concepts Slide No: 51

device

languageNew: the Access xDLMS service messagespecification

New: the Access xDLMS service

• Unified GET / SET / ACTION serviceUnified GET / SET / ACTION service– Allows sending a list of requests and receiving all responses

in a single message– Long-Invoke_Id-And_Priority allows many outstanding

requests– Self-descriptive response can be requestedSelf descriptive response can be requested


device

languageThe Access-request service messagespecification

The Access request service• Partial ASN.1 specification

Access-Request-Specification ::= CHOICE{

access-request-get [1] Access-Request-Get,access-request-set [2] Access-Request-Set,access-request-action [3] Access-Request-Action,access-request-get-with-selection [4] Access-Request-Get-With-Selection,access-request-set-with-selection [5] Access-Request-Set-With-Selection

}

List-Of-Access-Request-Specification ::= SEQUENCE OF Access-Request-Specificationq p q p

Access-Request-Body ::= SEQUENCE{

access-request-specification List-Of-Access-Request-Specification, access-request-list-of-data List-Of-Data

}Access-Request ::= SEQUENCE{

long-invoke-id-and-priority Long-Invoke-Id-And-Priority,date-time OCTET STRING,access-request-body Access-Request-Body

}


device

languageThe Access-Response service messagespecification

The Access Response service

• Partial ASN.1 specificationp

Access-Response-Specification ::= CHOICE{

access-response-get [1] Access-Response-Get,t [2] A R S taccess-response-set [2] Access-Response-Set,

access-response-action [3] Access-Response-Action}

List-Of-Access-Response-Specification ::= SEQUENCE OF Access-Response-Specification

Access-Response-Body ::= SEQUENCE{

access-request-specification [0] List-Of-Access-Request-Specification OPTIONAL,Specification OPTIONAL,

access-response-list-of-data List-Of-Data,access-response-specification List-Of-Access-Response-Specification

}Access-Response ::= SEQUENCE{{

long-invoke-id-and-priority Long-Invoke-Id-And-Priority,date-time OCTET STRING,access-response-body Access-Response-Body

}


device

languageThe General-Block-Transfer servicemessagespecification

• Allows transporting long, unprotected or protected xDLMS messages between client and server

• Allows bi-directional transfer• Allows streaming• Allows streaming

General-Block-Transfer ::= SEQUENCE{{

block-control Block-Control,block-number Unsigned16,block-number-ack Unsigned16,block-data OCTET STRING

}-- Use of Block-Control-- window bits 0-5 window advertisewindow bits 0 5 window advertise -- streaming bit 6 0 = No Streaming active,

1 = Streaming active-- last-block bit 7 0 = Not Last Block,

1 = Last Block1 Last BlockBlock-Control ::= Unsigned8


device

languagexDLMS conformance block messagespecification

xDLMS conformance blockgeneral-protectiongeneral-block-transfer

reserved12

0 • Contains the services supported

readwriteunconfirmed-write

general block transferreadwriteunconfirmed-writereserved

23456

• Services for SN referencing

• Services for LN referencing

attribute0-with-setpriority-managementattribute0-with-get

reservedattribute0-with-setpriority-managementattribute0-with-get

789

10The conformance block is proposed

New conformance bits allocated

i f ti tmultiple-referencesblock-transfer-with-action

block-transfer-with-getblock-transfer-with-setblock-transfer-with-action

i f ti t

block-transfer-with-getblock-transfer-with-set

13

15

1112

multiple-references 14

• The conformance block is proposedby the Client. ex: All SN services: 1C0320

• Client and the Server negotiate conformanceinformation-report

parametrised-accessget

information-reportdata-notificationaccessparametrized-accessget

1516171819

• Client and the Server negotiate conformanceblock: logical AND between proposed and supportedex: Read and Write: 180000get

setselective-accessevent-notificationaction

getsetselective-accessevent-notificationaction

1920212223

ex: Read and Write: 180000

• The conformance block should be meaningful!actionaction 23 g


device

languageOptimization of data access messagespecification

Optimization of data access

Logical nameLogical name

L i l

• GET-WITH-LIST {list of attributes}: delivers a list of attribute values

Attribute 2

Attribute n

Method 1

g

Attribute 2

Attribute n

Logical name

Attribute 2

Attribute n

Logical name

Attribute 2

• GET {attribute}: delivers the value of a single attribute

• GET {attribute 0}: delivers Method 1

Method nMethod 1

Method n

Attribute n

Method 1

Method n

Attribute n

Method 1

Method n

{ _ }all attributes of an object

Method n

• Objective: comply with media specific restrictions, minimize overhead and number of round trips

• Tools:

• selective access: access just to relevant portion of the data

• block transfer: allows transporting long APDUs in fragments

• also lower layer segmentation may be available (e.g. HDLC)

APDU l th b ti t d• APDU length can be negotiated


device

languageEfficient encoding of xDLMS APDUs: A-XDRmessagespecification

g

For example: 12345678k Wh

Value Scaler Unit

30 31 32 33 34 35 36 37 38 6B 57 68ASCII

06 00 BC 61 4E 02 02 0F 03 16 1EA-XDR

Type codes are always sent

• Generally, only the value has to be sent, the scaler_unit is optional (different attribute in DLMS/COSEM > metadata)


device

languageBuilding the messages messagespecification

Building the messages

• services to access • and protocols to the objects transport the

informationObj t GET

Name

Attribute 1

Object GET

SET

COSEM Application

...COSEM Application

COSEM ApplicationAttribute 1

...

Attribute nACTION

Data link layer

Physical layer

...Data link layer

Physical layer

...Data link layer

Method(s) Report COMM. MEDIA

Physical layerPhysical layer

xDLMS APDU

C4010009060101480700FF

xDLMS APDU

ValueType / Length

Result (success)

Service


device

languageMessages and services - summary messagespecification

Messages and services summary

Green Book specifies messages for Establishing Application associations: the ACSE services Accessing COSEM objects: the xDLMS services Protecting the messages Transporting long messages in blocks

Cli t / i t Client / server environment Pull and push messaging patterns DLMS messages can be transported over any mediag p y Interoperable: Context negotiation, conveying data types Efficient: separation of data and metadata, with-list servcies,

selective access encodingselective access, encoding


device



Information securityInformation security


device

languageWhere security is required? messagespecification

Where security is required?

• Sensitive data read from or sent to the meter– E.g. consumption, debtE.g. consumption, debt

• Critical commands sent to the meter (e.g. supply control, activation of new parameters, key transfer)

• Firmware upgrade


device

languageGeneral security requirements messagespecification

General security requirements

• Authentication of communicating partners• Controlling access rights depending on the role of the client• End-to-end security between third party and server• Protection of COSEM data and xDLMS messages• Multi level protection applied / verified by different entities• Multi-level protection applied / verified by different entities• Configurable security suites (what algorithms?) and policies (what

protection?)• Only approved security algorithms: NIST, FIPS• Well defined key management

S it l d l t• Security logs and alerts• Physical security (out of Scope of DLMS/COSEM)


device

languageDLMS/COSEM security toolbox messagespecification

DLMS/COSEM security toolbox

• Authentication of communicating partners• Authentication of communicating partners– client only (LLS, Low-Level Security authentication)– client / server (HLS, High-Level Security authentication)

• Access rights– Client rights to access COSEM object attributes and methods, depending on

its role

• DLMS message and COSEM data security– Authenticity, integrity, confidentiality

• Key management• Security event logs


device

languageAuthentication security messagespecification

Authentication security

ServerClient LLS ServerClientCtoS

Server

LLS Secret

Client LLS secret

Server

HLS secret (S)

ClientStoC

f(StoC)

f(CtoS)

HLS secret (S)

• Authentication: identification of the partners before data exchange• Identification elements: system title Service Access Point (SAP) client user id• Identification elements: system title, Service Access Point (SAP), client user id• Authentication procedures

– no security: „public” access, no identification takes placeLLS L L l S it th ti ti id tifi li t b d– LLS, Low Level Security authentication: server identifies client by password

– HLS, High Level Security authentication: mutual identification • exchange challenges • exchange result of processing the challenge• exchange result of processing the challenge

• Different Associations may use different Authentication processes• All Association events may be logged in Event logs


The relationship between the authentication and data exchange phase is shown on the next slide

device

languageDLMS/COSEM Client

DLMS/COSEMServer

Application Associations (AAs) pre-configured in Server: Application- Authentication- DLMS- Security-context, Access rights

messagespecification

Client Server

COSEM-OPEN.request {Client SAP, Server SAP, Proposed contexts, (System title), (Certificate), (Client user)}No

Phase 1: AA establishment

Check proposed /

COSEM-OPEN.response {Client SAP, Server SAP), Negotiated contexts, (System_title), (Certificate)}

authenticationsecurity

COSEM-OPEN.request {Client SAP, Server SAP, Proposed contexts (System title) (Certificate) (Client user) Password}

Apply negotiated contexts

Ch k d /Proposed contexts, (System title), (Certificate), (Client user), Password}LLS

authenticationCOSEM-OPEN.response {Client SAP, Server SAP,

Negotiated contexts, (System title), (Certificate)}

Check proposed /Apply negotiated

contexts

COSEM-OPEN request {Client SAP Server SAP

HLSauthentication

Response to challenge f (StoC)

Check proposed /Apply negotiated

contexts

COSEM OPEN.request {Client SAP, Server SAP, Proposed contexts, (System title), (Certificate), (Client user), CtoS}

COSEM-OPEN.response {Client SAP, Server SAP, Negotiated contexts, (System title), (Certificate), StoC}

Response to challenge f (StoC)

Response to challenge f (CtoS)

(Protected) DLMS service .request(s)Phase 2:Message

(Protected) DLMS service .response(s)

COSEM-RELEASE.request (Client SAP, Server SAP)

COSEM-RELEASE.response (Client SAP, Server SAP)

gexchange

Phase 3:AA release

Release


Release contexts

device

languageAccess control: object list and access rightsmessagespecification

MeterActivity

“Utility A” deviceActivityActivityActivityActivity

j _ g

Associations Registers Profiles ClockActivity

CalendarAssociations Registers Profiles Clock

W

ActivityCalendarAssociations Registers Profiles ClockActivity

CalendarAssociations Registers Profiles Clock

R

ActivityCalendarAssociations Registers Profiles ClockActivity

Calendar

“meter operator” device

Associations Profiles Clock

“Utility B” device

Associations Registersdevice

Door Keeper

Utility AUtility AUtility ATelephone

GSMPLCInternet

xDxy

Meter Operator

Utility AUtility AUtility A

Utilit BxDxy Utility B

• Managed by Association LN / Association SN objects

Object list pro ides the list of COSEM objects their attrib tes and methods isible in the gi en Association


• Object_list provides the list of COSEM objects, their attributes and methods visible in the given Association

• Access_rights determine the cryptographic protection required

device

languageMessage protection messagespecification

Message protection

• Cryptographic protection to messages –DLMS APDU d i t txDLMS APDUs – during transport• authentication to ensure authenticity (legitimate

) d i t it fsource) and integrity of messages• encryption to ensure confidentiality

th ti t d ti t id b th• authenticated encryption to provide both• digital signature: authentication and non-

repudiationrepudiation


device

languageSecurity context messagespecification

Security context

Determines the rules for applying / verifying security

• Security suite: set of cryptographic algorithms– Symmetric key: AES-GCM AES Key WrapSymmetric key: AES GCM, AES Key Wrap– Public key: Elliptic Curve Digital Signature, EC Diffie-Hellman Key Agreement

• Security policy: protection to be applied to the request and the response (generally i e for all requests and all responses)response (generally, i.e. for all requests and all responses)

• Security material: symmetric and asymmetric keys, initialization vectors, nonces

• Access rights– read / write /execute– protection to be applied to request and response on attribute / method levelprotection to be applied to request and response on attribute / method level

• DLMS/COSEM provides the necessary security tools

S


• Security suites and policies have to be selected according to the project needs

device

languageDLMS/COSEM security suites messagespecification

y

• DLMS/COSEM uses security algorithms selected by NSA (National Security Agency) Suite B, using approved FIPS / NIST standards


device

languageAES-GCM ciphering and compression messagespecification

AES GCM ciphering and compressionReconstructed

informationSecurity Control

byte, SCOriginal information

(xDLMS APDU or COSEM data)

SC C bit 7 1Compression Compression Decompression

Authentication only AAD = SC II AK II (C) InformationSC-A: bit 4=1

SC-C: bit 7=1Compression Compression

Compressed information

Decompression

AES Galois / Counter AES Galois / CounterEK EK

Encryption only

(C) InformationAuthenticated encryption

(C) Information

AAD = SC II AK

Fail

P P

AAD = nullSC-E: bit 5=1

SC-AE: bit 4, 5=1

A

(C) Information

AES Galois / Counter mode

authenticated encryption

AES Galois / Counter mode

authenticated decryption

(C) information T IC

C AT C T

SC

ICSys-T ICSys-T

Ciphered Information: Authentication only

IV IV

AAD = SC II AK II (C) InformationLEN

Ciphertext

T

IC

IC

SC

SC

Ciphered Information: Encryption only

Ciphered Information: Encryption + Authentication

AAD = SC II AK

AAD = null

Ciphertext

LEN

LEN

SH

(C) Information: Compressed information A = AAD P = PlaintextAK =Authentication key SC = Security control byteC = Ciphertext SH = SC II IC Security headerEK = Encryption key Sys-T = System title (originator)

Additional Authenticated Data AAD (Associated data) contains:- Authentication only: SC II AK II (C) Information;- Encryption only: Null

SH


EK Encryption key Sys T System title (originator)IC = Invocation counter T = Authentication tag IV = Sys-T II IC Initialization vector

Encryption only: Null- Authenticated encryption: SC II AK

device

languageSecurity implementation messagespecification

Security implementation• Association objects control access rightsCOSEM li ti rights

• Security setup objects control security suite&policy and manage keys

COSEM application process

Association object

Security setup obejcts

Application obejcts

• Association Control Service Element (ACSE) controls contexts

• Application contextDLMS/COSEM application layer

Service response + security options

Service request+ security status

• LN or SN referencing

• ciphered / unciphered APDUs

• Authentication mechanism

ACSE xDLMS ASE Security

context

• LLS / HLS authentication

• xDLMS context: list of services(Protected) APDUs

Verify / remove / apply protection

Lower layers Security context: controls verifying / removing / applying protections as defined by the access rights and the security policy, using the security suite


and security material

device

languageData security extensions – in work messagespecification

Data security extensions in work

Further extend the possibilities to cryptographically protect messages and data h dexchanged

That is:

• Add protection of COSEM data and xDLMS messages between client-server and third p gparty-server

• xDLMS message protection client-server already in use

• Add public key algorithms• Add public key algorithms• Elliptic curve digital signature

• Elliptic curve Diffie-Hellman key agreement

• Two key sizes: symmetric 128 / 256 bit, asymmetric P-256 / P-384• Interoperability through using NSA Suite B algorithms

• Add new general protection services that can be applied in a layered manner to anyAdd new general protection services that can be applied in a layered manner to any xDLMS service (APDU)

• General-Ciphering

• General Signing


• General-Signing

device

languageGeneral-Ciphering-Service (1) messagespecification

General Ciphering Service (1)

General-Ciphering ::= SEQUENCE{

t ti id OCTET STRINGtransaction-id OCTET STRING,originator-system-title OCTET STRING,recipient-system-title OCTET STRING,

idate-time OCTET STRING,other-information OCTET STRING,key-info Key-Info OPTIONAL,ciphered-service OCTET STRING

}


device

languageGeneral-Ciphering-Service (2) messagespecification

General Ciphering Service (2)


device

languageGeneral-Signing-Service (1) messagespecification

General Signing Service (1)

General-Signing ::= SEQUENCE{

transaction-id OCTET STRING,originator-system-title OCTET STRING,recipient-system-title OCTET STRING,date-time OCTET STRING,other-information OCTET STRING,service OCTET STRING,signature OCTET STRING

}


device

languageGeneral-Signing-Service (2) messagespecification

General Signing Service (2)


device

languageCryptographic protection of COSEM datamessagespecification

yp g p p

• Use case: critical data have to be kept secret to the client (HES)

• The objective is to re-use the solutions for protecting DLMS h bj l lxDLMS messages on the object level

• This work has been just started• The strategy is to re-apply the concepts for message

protection on COSEM object level


device

languageSymmetric key and their management messagespecification

Symmetric key and their management

DLMS/COSEM key type Key establishment Owner Use

Master key, KEK

Out of bandKey Encrypting Key (KEK) for (new) master key, global keys or for ephemeral ciphering keysKey agreement

Key wrap

client and server

Global unicast encryption key, GUEK

Key agreement

Block cipher key for unicast xDLMS APDUs or for COSEM DataKey wrap

Global broadcast key, GBEK

Key agreement Block cipher key for broadcast xDLMS APDUs or for COSEM DataKey wrap

(Global) Authentication key, GAK

Key agreementPart of Additional Authenticated Data to the ciphering process of xDLMS APDUs or COSEM dataKey wrap

Key transport client and serverDedicated key

Key transport

in xDLMS-Initiate.request APDU

client and server (during the

lifetime of an AA)

Block cipher key of unicast xDLMS APDUs within an established AA

Ephemeral data

Key identification

Sender and Block cipher key for messages exchanged between a server andKey wrapEphemeral data encryption key

Sender and recipient

Block cipher key for messages exchanged between a server and a client or a server and a third party via the client

y p

Key agreement

Key derivation


device

languageManagement of symmetric keys (example)messagespecification

g y y ( p )

1290

DCS

12901290

1290Concentrator

• Encryption keys:• Global key: used in several sessions (AAs); unicast - broadcast

• global unicast key encrypts dedicated key• Dedicated key: used in a single session (AA), then destroyed

• Authentication key (optional with GCM)Authentication key (optional with GCM)• Global, unicast and broadcast

• Master key: pre-established, used only to wrap global keys


device



Communication profiles


device

languageCommunication profiles messagespecification


COSEM object modelApplication layer: common in any communication profile

COSEM A li ti l

COSEM object model communication profile

• connection between the metering and data collection applications

th fCOSEM Application layer

Connection Messaging

• prepares the messages for transport

• encoding

Lower Lower Lower

• block transfer

• cryptographic protection

layersMedia 1:PSTN, GSM

layersMedia 2:TCP/IP

layersMedia n Lower layers ensure that he

messages are correctly delivered

GSM Identification of the profile used by the meter ensures interoperability (available in 3-layer HDLC profile)

Profile 1 Profile 2 Profile n


device

languageCommunication profiles messagespecification


• Communication media independent data model: COSEMCommunication media independent data model: COSEM

• Application layer common for all profiles: DLMS

• Media dependent connection manager: e g TCP conn managerMedia dependent connection manager: e.g. TCP conn. manager

• Media specific lower layers

• Communication profiles driven by technology evolution:Communication profiles driven by technology evolution:– Narrow-band OFDM PLC for PRIME networks, promoted by the PRIME Alliance

– Narrow-band OFDM PLC for G3-PLC networks, promoted by the G3-PLC AllliPLC Allliance

– SMITP / B-PSK PLC, promoted by Meters&More

– AMC-SS PLC promoted by Siemens– AMC-SS PLC, promoted by Siemens

– ISO/IEC 12139-1 BPL profile, proposed by Korea

– RF mesh profile, proposed by the USp p p y


device

languageSmart metering system reference architecture

messagespecification


device

languageCommunication profiles for WAN (G1) messagespecification

Communication profiles for WAN (G1)

catio

nel

ling

IEC 62056-6-2 / IEC 62056-6-1 / EN 13757-1COSEM / OBIS d l

App

lim

odca

tion

yer

COSEM / OBIS model

IEC 62056-5-3

App

lic lay

ort /

ay

er

DLMS/COSEM Application layer

IEC 62056-47

Tran

spo

Net

wor

k l

IEC 62056 46er

IEC 62056 47COSEM TP

wrapper / TCP-UDP / IPV4 / IPv6

IP support layersGPRS ADSLA

C

IEC 62056-46 HDLC

IEC 62056-42

LLC

laye

GPRS, ADSLEthernet,

Phy

+ M

Ala

yer

Public WAN

Phy layer

IEC TC 13 ETSI M2MIEC TC 13 ETSI M2M


device


DLMS/COSEM communication profiles for neighbourhoodprofiles for neighbourhood networks: the C interface


device

languageNB OFDM PLC profile for PRIME networks: prTS 52056-8-4 messagespecification


device

languageNB OFDM PLC profile for G3-PLC networks: prTS 52056-8-5 messagespecification


device

languageSMITP B-PSK PLC profile: prTS 50568-8 messagespecification

p p

COSEM A li tiDiscovery and Registration

DLMS/COSEM Application layer

COSEM Application processEN 62056-6-1, EN 62056-6-2

Discovery and RegistrationApplication ProcessClause 4.7, Annex B

Discovery and RegistrationACSE and xDLMS ASE

EN 62056-5-3

APDUs Carried by CL-DATA services

Application LayerClause 8

COSEM SMITP B-PSK-based convergence layer

Clause 4

DR-PDUsCarried by

DL-DATA services

CLPDUs Carried by DL-DATA services

Data link layer

B-PSK LLC sub layerCLC/prTS 50568-4 clause 5

B-PSK MAC sub layerCLC/prTS 50568-4 clause 6

P_DATA services


B-PSK Physical layerCLC/prTS 50568-4 clause 7

device

languageAMC-SS PLC profile: prTS 52056-8-7 messagespecification

p p


device

languageHigh speed PLC ISO/IEC 12139-1 profilemessagespecification

g p p


device



Conformance testingand compliance certificationand compliance certification


device

languageConformance testing messagespecification

Co o a ce test g

• Purpose: to verify correct implementation in meters (DLMS/COSEM servers)

• Protocol and object model tests• Protocol and object model tests• Helps product development

– Optional log module provides detailed, human readable information• Helps system integration• Self testing or third party testing

A ibl t DLMS UA b• Accessible to any DLMS UA member under fair and equal terms


device

languageTest tool architecture messagespecification

Test tool architecture

Test Workstation System under test (SUT)COSEM Server

COSEM Test Client

Test Device

COSEM

Test programs

COSEM

Device application

Test Client stack

ServerStack

Physical IF Physical IFPDU-s

• Remote test method: Observation and analysis of protocol data units 7EA00A00020023215314B77E7EA00A00020023215314B77E

7EA00A2100020023734CE77E


device

languageProcess implementation messagespecification

Process implementation

• Automatic test execution by th f t thi d tthe manufacturer or third party tester

• Verification / certification: Test plans

DLMS UA

Association

1.8.1.3 12345.67 Testroutines

CTI Testroutines

cTest

routines

Test reportobject

c

Test reportTest report

COSEM compliant

p


device

languageApplication layer tests messagespecification

Application layer tests

Test suiteCOSEM Application layer

Test groupAPPL_IDLE

Test groupAPPL_OPEN

Test groupAPPL_DATA_LN

Test groupAPPL_DATA_SN

Test groupAPPL_REL

Test groupAPPL_IDLE_P

Test groupAPPL_

DATA_LN_P

Test groupAPPL_

DATA_SN_N

Test groupAPPL_REL_N

Test groupAPPL_

DATA_LN_N

Test cases Test cases Test cases Test casesTest casesTest cases


device

languageCOSEM object tests messagespecification

COSEM object tests

Validity of logical names• Validity of logical names• Access rights to

attributes

Test suiteCOSEM interface objects

attributes• Attribute types• Methods not tested

COSEM_X_Y• Methods not tested –

would change the MUT• Multiple references Multiple referencesMultiple references• Presence of mandatory

objects Mandatory objectsobjects• Objects found are listed

Mandatory objects


device

languageConformance assessment process messagespecification

Conformance assessment process

Start

Preparation for testing:IUT & CTT

Test selection andCTI

Test operations

parametrization

Test campaigns:one for each communication

CTI

one for each communicationprofile and application

context

C f t t t &Conformance test report &log

End


device

languageDLMS Certified products and manufacturersmessagespecification

p

250300350

Certified products

100150200250 p

Manufacturers

050

100

2002 2004 2006 2008 2010 2012

Manufacturers

2002 2004 2006 2008 2010 2012

• IEC 62056 published in 2002, 2006, 2013

• CTT released in 2002, CTT version 3 in 2013

• To date (2013 Q III) 350+ certificates, 70 manufacturers


device

languageConformance testing & certification messagespecification

Conformance testing & certification

• Test plans & Certification: DLMS UA TECHNICAL REPORT

C i S ifi ti

TECHNICAL REPORT

C i S ifi ti

• Sales: EURO DCS– 70+ CTT licenses, 13 third party test labs

Companion Specificationfor Energy Metering

COSEM

Companion Specificationfor Energy Metering

COSEM

• 70+ manufacturers, 350+ Certificates Conformance TestTool - Specification

DLMS User Association

Conformance TestTool - Specification

DLMS User Association

device languagemessagespecification




device

languageExamples of test reports messagespecification

Examples of test reports


device

languageExample Certificate messagespecification

p

C tifi t li t d• Certificates listed at www.dlms.com

•Meter type + LDNyp

• Manufacturer

• Test house

•Test information

•Test report is available from the manufacturer


device



Future evolution


device

languageDLMS/COSEM future evolution messagespecification

DLMS/COSEM future evolution

Modelling: new applications e.g. payment metering, block tariff contract management…

Security: public key algorithms, end-to-end security

Messaging: unified ACCESS service, compression, XML

Transportation: new media e.g. OFDM PLC, wireless mesh network,

D i b t t i j t

Link to ERP systems and smart grids: harmonization of IEC 62056 COSEM with IEC 61968 CIM and IEC 61850

Driven by smart metering projects


device

languageIEC 62056 standard roadmap messagespecification

IEC 62056 standard roadmap


device


Some important characteristics of DLMS/COSEMDLMS/COSEM


device

languageOpenness messagespecification

Openness

• Specification is– publicly available

i t ti ll t d di d IEC CENELEC CEN– internationally standardised: IEC, CENELEC, CEN, – Adopted as National standard in several countries– no IP rights apply on any standardsg pp y y

• DLMS UA membership open to all at nominal fee– participation in technical work

t i i d t h i l t– training and technical support– conformance testing is available at equal and fair terms– forum for exchanging best practicesg g p

• No royalties• Supported by many meter and system providers worldwide


device

languageManageability messagespecification

Manageability

• Role based access via Associations– possibility to change scope of access (access rights)– various contexts and security policies

• Data organization and access tools• Data organization and access tools– profiles to get several data with a single request– with-list commands, to minimize round trips

D l d f h d l T iff• Download of schedules e.g. Tariff program• Invocation of scripts• Firmware download and activation• Security key managements• Event management• Alarms and EventNotification• Alarms and EventNotification• Matching communication network properties

– baud rates, window sizing, segmentation, block transfer


device

languageInter...what? messagespecification

Inter...what?• Interoperability: ability of diverse systems to work together

syntactic: ability to exchange data protocols formats– syntactic: ability to exchange data - protocols, formats– semantic: data exchange produces (agreed) useful results

• Interconnectivity: all, what has to be connected, can be connected (physical and abstract level)connected (physical and abstract level)

• Interchangeability: elements providing the same function• Reaching true interoperability

– open international standards– companion specifications to reduce options, and to specify project

specific elements that cannot be specified internationally– conformance testing– partnership and co-operation– disciplinep


device

languageInteroperability messagespecification

Interoperability

• Standards-based interoperability enables competitioncompetition– Systems and equipment from multiple sources

High system integration costs can be avoided– High system integration costs can be avoided


device

languageCompanion specifications messagespecification

Companion specifications• International standards

if h t b d– specify what can be agreed on– specify few mandatory elements– leave choices for flexibilityy

• Companion specifications to close interoperability gaps– fix choices to optimize performance and costs– specify elements that must be present to support project use

cases– specify project specific elements (e.g. events)– specify processes for data exchange– should be jointly specified by project participants

Examples: Dutch DSMR French Linky Spanish T5 Indian– Examples: Dutch DSMR, French Linky, Spanish T5, Indian, Saudi Arabian, Italian Gas, IDIS....


device

languageCompanion spec. example - The IDIS projectmessagespecification

p p p p j

I iti t d b I k It d L di G• Initiated by Iskraemeco, Itron and Landis+Gyr

• learning from Dutch, French, Spanish projects

Objecti e create a market for standard f nctionalit meters• Objective: create a market for standard functionality meters

• Commitment to produce IDIS meters

• Companion specification to IEC 62056 DLMS/COSEM• Companion specification to IEC 62056 DLMS/COSEM

• only selections made: nothing modified, nothing added

• IDIS interoperability testIDIS interoperability test

• IDIS meters pass DLMS conformance test

• Publicly available, anybody can make IDIS metersPublicly available, anybody can make IDIS meters

• http://idis-association.com/


device

languageClosing the gap with companion specificationsmessagespecification

g g p p p

Proprietary interface

Proprietary interface

Integration costs

R M

interface interface

Standard StandardIntegration

ME

TER

SY

STE

MStandard interface

Standard interface

Integration costs

Standard interface +Companion specification

Standard interface +Companion specificationCompanion specification Companion specification

Courtesy IDIS


device

languageDLMS/COSEM: The standard of first choicemessagespecification

Data models messaging methods and protocols, with enhanced security for meter data exchangewith enhanced security, for meter data exchange

Multi-utility and multi-media Self-descriptive, negotiable features Efficient data organization and access Metersof any complexity, from standard building

blocksblocks Covers smart metering needs Balance between flexibility and overhead O i t ti l t d d id l t d Open, international standard, widely supported Supports innovation and competition Future proof

i t i k th l

p Testable interoperability

…in metering, we speak the same languageTPAK2_DLMS_Concepts Slide No: 114

iec 62056 dlms/cosem workshop part 2:part 2:...

Documents