IEC 62056 DLMS/COSEM seminar DLMS Application...

device

languagemessagespecification

IEC 62056 DLMS/COSEM seminar

DLMS Application services EUW 2014, Amsterdam

Győző Kmethy, DLMS UA, President

Victoria Varjú, DLMS UA, Support manager Bas Roelofsen, DNV GL, Consultant

DLMS seminar EUW 2014 – Application layer 1

device


Agenda


• 13:00 Registration • 13:30 DLMS/COSEM overview • 14:00 COSEM model news • 15:00 Coffee break • 15:30 DLMS services news • 16:00 Security extensions • 16:30 DLMS/COSEM communication profiles • 16:45 DLMS projects and interoperability testing • 17:00 Tools, demo, quiz • 17:15 Q/A • 17:30 End of the program

device


The Green Book

The Green Book specifies:

• how to connect client and server application processes

• how to access data and how to transport the messages

• how to apply cryptographic protection

• messaging patterns: pull and push

• communication profiles i.e. using DLMS/COSEM over various communication media

• Edition 8 published 7th July 2014


device


DLMS/COSEM Application layer- new developments


Green Book Ed. 7:2009

COSEM-OBIS

Green Book Ed. 7.3:2013

COSEM-OBIS

Green Book Ed. 8:2014

COSEM-OBIS

IEC 62056- 5-3

Ed. 1:2013

DLMS/COSEM Application

layer

IEC 62056-5-3 Ed. 2:2015


layer

IEC 62056- 5-3

Ed. 3:2015


layer

• Symmetric key cryptography

• S-FSK PLC profile

• DataNotification service (Push operation)

• General Block Transfer mechanism

• General protection APDUs

• Composable services: encoding – general protection – general block transfer

• ACCESS service (unified GET-SET-ACTION) • Public key cryptography • E2E security third party – meter • XML schema

device


Client-server environment SERVICE.request/ .indication SERVICE.response/ .confirm

Client application

(e.g. Head End System)

Server application (e.g. meter)

Application layer

N-layer

Physical layer

N-1 layer

Application layer

N-layer

Physical layer

N-1 layer

Application layer

N-layer

Physical layer

N-1 layer

Application layer

N-layer

Physical layer

N-1 layer

ACSE Association Control

Service Element

xDLMS COSEM object related services

General services

Profile 1

Profile 2

Profile n

SERVICE.request SERVICE.response

• • •

Transport media

PSTN, GSM, Internet, PLC,

xDxy

device


COSEM (ACSE + xDLMS) services

General-Block-Transfer: can be applied on any long protected or unprotected APDU between client and server. Provides streaming and lost block recovery

xDLMS services • provide access the COSEM objects: read/write attributes, execute methods • Request / Response: GET / Read, SET / Write / Unconfirmed Write, ACTION,

ACCESS (unified -GET, -SET, -ACTION) • Unsolicited: EventNotification / InformationReport, DataNotification • May carry unprotected or protected COSEM data

ACSE (Association Control Service Element) services • COSEM-OPEN, -RELEASE, -ABORT • establish associations between applications running in meters and central

systems. Associations determine the rules of data exchange

General protection: Can be applied on any service in a layered / multi-level fashion by any party (see the security module of the seminar) • General-Ciphering: compression, authenticated encryption using AES-GCM • General-Signing: Elliptic Curve Digital Signature Algorithm (ECDSA)

Green Book 8

Green Book 8

Green Book 7.3

device


Messaging patterns between client and server

Client Server

.request

.response

Pull operation

.indication

Push operation

• 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 DataNotification service


device


COSEM-OPEN service: application association establishment

Physical layer

Intermediate layers

Application layer

Object model

ACSE xDLMS Protocol stack

•xDLMS context •conformance block

(list of services) •APDU length

Application context • referencing method • use of ciphering

Authentication mechanism • LLS: password • HLS: challenge-response

• Application Associations (AAs) determine the rules of the message exchange between client and server

• Contexts are configured in the server

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

• AAs may be pre-established


device


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

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

• To access attributes and methods, they must be referenced – Logical name referencing: { class_id, instance_id, attribute_id / method_id } – Short name referencing: named variable

• xDLMS services are carried by APDUs – specified using ASN.1 abstract syntax – encoded in A-XDR (IEC 61334-6) – XML schema is also specified

C4 01C1 00 0906 0101480700FF

<GetResponse>

<GetResponsenormal>

<InvokeIdAndPriority Value=“C1" />

<Result>

<Data>

<OctetString Value="0101480700FF" />

</Data>

</Result>

</GetResponsenormal>

</GetResponse>


device


ACCESS

Common xDLMS services for all objects

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

data; selective access possible – Response: supplies the (list of)

data with data type – Requests and responses must be

paired in the DCS • ACCESS service is a unified GET /

SET / ACTION. Response can be self-descriptive

• Event notification • DataNotification (Push) • Common service set for all objects:

– new interface classes use the same services

Name

Attribute 1

Object

...

Attribute n

Method(s)

Read

Write

UnconfWrite

G E T

S E T

A C T I O N

Interoperable and future proof DLMS seminar EUW 2014 – Application layer 10

Green Book 8

device


Referencing: Logical name – Short name

x = base_name

x + 8

x + n*8

x+ ...

x + offset

ACTION / ACCESS method {class_id, logical_name, method_id}

Mapping

Class_id, version

Attribute(s)

1. logical_name

2. Attribute 2

n. Attribute n

Specific method(s)

1. Method 1

n. Method n

Read / Write / Unconfirmed Write {named variable}

GET / SET / ACCESS attribute {class_id, logical_name, attribute_id}

• Interoperability: List of services supported is negotiated between client and server


device


xDLMS conformance block

read write unconfirmed-write

information-report

parametrised-access

multiple-references

get set selective-access event-notification action

attribute0-with-set priority-management attribute0-with-get

block-transfer-with-action

block-transfer-with-get block-transfer-with-set

general-protection general-block-transfer read write unconfirmed-write reserved reserved attribute0-with-set priority-management attribute0-with-get

block-transfer-with-action

information-report data-notification access parametrized-access get set selective-access event-notification

reserved

action

block-transfer-with-get block-transfer-with-set

1 2 3 4 5 6 7 8 9

10

13

15 16 17 18 19 20 21 22

0

23

11 12

multiple-references 14

• Allows negotiation of the capabilities

• Services for SN referencing

• Services for LN referencing

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

• The server accepts what can be supported: logical AND between proposed and supported ex: Read and Write: 180000

• Conformance block should be meaningful!

New conformance bits allocated


device


Access service

• ACCESS service is a unified GET / SET / ACTION service • Introduced to minimize number of exchanges by combining

different kinds of requests: “one stop shopping” – Example: identify meter – read registers – read profiles – close billing

period – synchronize clock – improves efficiency

• It allows: – sending a list of requests and receiving a list of responses using a single

message exchange – have many outstanding requests: Long-Invoke-Id-And-Priority – controlling how the requests are processed: continue or break on error – getting self-descriptive responses: references can be mirrored

Green Book 8


device


Comparison of services

COSEM object

Atribute #1

Methods

Atribute #n Atribute #2

Data

GET References and Data

SET

ACTION ACCESS

• ACCESS includes a list of GET / SET ACTION requests and related responses • It may be self-descriptive: the response may include the request references


References

Result

References and Data

Results and Data

References and Data

References, Results and Data

COSEM object

Atribute #1

Methods


COSEM object

Atribute #1

Methods


COSEM object

Atribute #1

Methods


device


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-Specification 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 } DLMS seminar EUW 2014 – Application layer 15

device


The Access-Response service

• Partial ASN.1 specification

Access-Response-Specification ::= CHOICE { access-response-get [1] Access-Response-Get, access-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, 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


DataNotification service

• Unsolicited service used for Push operation

Push object

Attribute #1

Attribute #n Attribute #2

Data

Green Book 7.3


device


Block 2 Block n Block 1

Concept of composable messages

xDLMS APDU

• Initially service-specific ciphering and block transfer was available • With composable messages encoding, ciphering and block transfer are

decoupled thus reducing complexity • General protection APDUs allow protecting any message by any party recursively • General block transfer APDUs allow transporting any long message

Cryptographic protection 1

Cryptographic protection 2

Green Book 7.3


device


General Block Transfer (GBT)

“Classical” block transfer: • is service specific • is unidirectional: blocks are sent

or received by client • provides no streaming: reception

of each block has to be confirmed • does not support lost block

recovery • ciphering is applied on the blocks

Green Book 7.3

General-Block Transfer: • is not service specific: can be

applied to any APDU • is bidirectional (useful with

ACTION, ACCESS) • provides streaming (several

blocks without confirmation) • supports lost block recovery • ciphering is applied to complete

unciphered APDU


device


General block transfer

DLMS/COSEM client

DLMS/COSEM server

LB = 0, STR = 1, W =3, BN = 1, BNA = 0

LB = 0, STR = 1, W = 3, BN = 2, BNA = 0

LB = 0, STR = 0, W = 3, BN = 3, BNA = 0

LB = 0, STR = 1, W = 1, BN = 1, BNA = 1

LB = 1, STR = 0, W = 1, BN = 3, BNA = 4

LB = 0, STR = 1, W = 1 BN = 2, BNA = 1

LB = 1, STR = 0, W = 3, BN = 2 , BNA =2

LB = 0, STR = 1, W = 3, BN = 3, BNA = 2

LB = 1, STR = 0, W = 3, BN = 4, BNA = 2

BN = Block number BNA = BlockNumber ACK LB = Last Block STR = Streaming W = Window size

Green Book 7.3


device


The General-Block-Transfer APDU

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 advertise -- streaming bit 6 0 = No Streaming active, 1 = Streaming active -- last-block bit 7 0 = Not Last Block, 1 = Last Block Block-Control ::= Unsigned8


device


General ciphering, General signing

“Classical” ciphering • is service specific • uses pre-established keys • authentication and encryption • client-server only • single layer of protection

Green Book 8

General ciphering • is not service specific: can be

applied to any - plain or ciphered - APDU

• can use compression • can use pre-established keys or

keys are established as part of the transaction

• client-server or third-party server • multiple layers can be applied

General signing • can be applied to any APDU • client-server or third-party server • multiple layers can be applied

For more, see the Security module


device


Building the messages

• services to access the objects

• and protocols to transport the information

Name

Attribute 1

Object

...

Attribute n

Method(s)

GET

SET

ACTION

Report

C4010009060101480700FF

COSEM Application

... Data link layer

Physical layer

COMM. MEDIA

COSEM Application

... Data link layer

Physical layer

COSEM Application

... Data link layer

Physical layer

Value Type / Length

Result (success)

Service

xDLMS APDU (GET-response)

23

device


Efficient encoding of xDLMS APDUs: A-XDR

For example: 12345678

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

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

Value Scaler Unit

Type codes are always sent

k Wh

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


device


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

C001C1 //Get.request normal, invoke_id, priority 0003 // class_if = 3, register 0101480700FF //logical name 1.1.72.7.0.255 0100 //get attribute 1 (logical name) no selective access C401C1 //Get.response normal, invoke_id, priority 000906 //data, octet string(6) 0101480700FF //logical name 1.1.72.7.0.255, L3 voltage inst. C001C1 0003 0101480700FF 0200 //Get attribute 2, value C401C1// 000600000905 //data double long unsigned,2309D C001C1 0003 0101480700FF 0300 //Get attribute 3, scaler_unit C401C1 // 000202 //data, structure of 2 elements

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


device


Optimization of data access

Logical name

Attribute 2

Attribute n

Method 1

Method n

Logical name

Attribute 2

Attribute n

Method 1

Method n

Logical name

Attribute 2

Attribute n

Method 1

Method n

Logical name

Attribute 2

Attribute n

Method 1

Method n

• Objective: meet media specific restrictions, minimize overhead and number of round trips • Tools

• selective access: access just to relevant portion of the data • Compact array encoding • “Compact data” IC: send data to template • compression • APDU length can be negotiated • block transfer: allows transporting long APDUs in fragments

• lower layer segmentation may also be available (e.g. HDLC, M-Bus profile)

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

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

• ACCESS service: list of any requests / responses

• GET {attribute_0}: delivers all attributes of an object


device


Services, messages and mechanisms - 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

Client / server environment Pull and push messaging patterns DLMS messages can be transported over any media Interoperable: Context negotiation, conveying data types Efficient: separation of data and metadata, with-list

services, selective access, efficient encoding, templates, compression


IEC 62056 DLMS/COSEM seminar DLMS Application...

Documents

Transcript of IEC 62056 DLMS/COSEM seminar DLMS Application...