Communication Standard Between AMI Application and Metering ...

rabidwestvirginiaΔίκτυα και Επικοινωνίες

26 Οκτ 2013 (πριν από 3 χρόνια και 10 μήνες)

195 εμφανίσεις







Communication
Standard Between
AMI

Application and
Meter
ing

Infrastructure

developed for
ENERGA
-
Operator SA

Version
:
0
.
0
3

Dat
e
:
2011
-
07
-
3
1




Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

2

z
90

Contents

1

Glossary of terms and acronyms

................................
................................
.............................

5

2

Introduction
................................
................................
................................
...........................

8

3

Concept for the communication standard in DSO

................................
................................
.....

9

3.1

Assumptions for the communication standard
................................
................................
...

9

3.1.1

General assumptions

................................
................................
...............................

9

3.1.2

Technical assumptions
................................
................................
.............................

9

3.2

Overall concept of the communication standard
................................
...............................
10

3.2.1

Area of communication between SAK and concentrators

................................
..........
11

3.2.2

Area of communication between concentrators and meters
................................
........
11

3.2.3

Area of communication between SAK and meters

................................
....................
12

3.2.4

Traffic prioritization

................................
................................
...............................
13

3.2.5

Digital signatures

................................
................................
................................
...
17

3.2.6

Concept of transport

................................
................................
...............................
17

4

Meter Use Cases

................................
................................
................................
...................
20

4.1

Catego
ries, Identifiers and Statuses of Meter Use Cases

................................
...................
20

4.2

List of Meter Use Cases

................................
................................
................................
.
21

4.3

Analysis of Meter Use Cases

................................
................................
..........................
21

4.3.1

Installation Category

................................
................................
..............................
23

4.3.2

Configuration Category

................................
................................
..........................
30

4.3.3

Readouts Category

................................
................................
................................
.
34

4.3.4

Control Category
................................
................................
................................
....
38

4.3.5

Reporting Category

................................
................................
................................
43

5

DCSML communication protocol

................................
................................
..........................
45

5.1

Description of Messages

................................
................................
................................
45

5.2

Protocol Grammar

................................
................................
................................
.........
45

5.2.1

Basic definitions of SML data structures
................................
................................
..
46

5.2.2

Basic structures of DCSML data

................................
................................
.............
53

5.2.3

DCSML Functions


associated with the operation of a

concentrator

.........................
55

5.2.4

DCSML functions


associated with the operation of a meter

................................
....
57

6

Examples of queries and responses in DCSML (in APDU and source forms)

............................
61

6.1

ASN.1 definition

................................
................................
................................
...........
61

6.2

Examples

................................
................................
................................
......................
63

6.2.1

Example 1
-
1
-
1

................................
................................
................................
.......
63

6.2.2

Example 1
-
1
-
4

................................
................................
................................
.......
65

6.2.3

Example 1
-
5
-
1

................................
................................
................................
.......
67

6.2.4

Example 1
-
5
-
4

................................
................................
................................
.......
69

6.2.5

Example 5
-
1
-
1

................................
................................
................................
.......
71

6.2.6

Example 5
-
1
-
4

................................
................................
................................
.......
74

6.2.7

Ex
ample 5
-
5
-
1

................................
................................
................................
.......
79

6.2.8

Example 5
-
5
-
4

................................
................................
................................
.......
83


Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

3

z
90

Tables

Table 1. Glossary of terms and acronyms
................................
................................
........................

5

Table 2. Categories of Meter Use Cases

................................
................................
.........................
20

Table 3. Meter Use Cases with "A" status.

................................
................................
.....................
21

Table 4. DCSML Message List

................................
................................
................................
.....
45

Table 5. Significance of bits in the first byte of the TL
-
Field

................................
...........................
47

Table 6. Significance of bits in subsequent bytes of the TL
-
Field

................................
....................
48

Figures

Figure 1. Areas of communication in the AMI system

................................
................................
....
10

Figure 2. Areas of communication in the AMI
system


layers of the protocol

................................
.
11

Figure 3: Diagram of the sequence


single communication session PULL
................................
.......
14

Figure 4: Diagram of the sequence


two communication sessions PULL + PULL

...........................
14

Figure 5: Diagram of the sequence


two communication sessions PULL + PUSH

...........................
15

Figure 6: Diagram of the sequence


single communication session PUSH

................................
......
15

Figure 7. LPU in Installation Category

................................
................................
..........................
23

Figure 8. Sequence diagram for LPU01


correct situation

................................
..............................
24

Figure 9. Sequence diagram for LPU02

................................
................................
.........................
25

Figure 10. Sequence diagram fo
r LPU03

................................
................................
.......................
25

Figure 11. Sequence diagram for LPU04


servicing mode

................................
.............................
27

Figure 12. Sequence diagram for LPU04


without servicing mode

................................
.................
27

Figure 13. Sequence diagram for LPU05

................................
................................
.......................
28

Figure 14. Sequence diagram for LPU06

................................
................................
.......................
29

Figure 15. LPU in Configuration Category
................................
................................
.....................
30

Figure 16. Sequence diagram for LPU07

................................
................................
.......................
31

Figure 17. Sequence diagram for LPU08

................................
................................
.......................
32

Figure 18. Sequence diagram for LPU09

................................
................................
.......................
33

Figure 19. Sequence diagram for LPU20

................................
................................
.......................
33

Figure 20. LPU in Readouts Category

................................
................................
...........................
34

Figure 21. Sequence diagram for LPU10


"push" mode

................................
................................
.
35

Figure 22. Sequence diagram for LPU10


"pull" mode

................................
................................
..
35

Figure 23. Sequence diagram for LPU011
................................
................................
......................
36

Figure 24. Sequence diagram for LPU13


"push" mode

................................
................................
.
37

Figure 25. Sequence diagram for LPU13


"pull" mode

................................
................................
..
38

Figure 26. LPU in Control Category

................................
................................
..............................
39

Figure 27. Sequence diagram for LPU012


readout in the "push" mode

................................
..........
39

Figure 28. Sequence diagram for LPU012


readout in the "pull" mode

................................
...........
40

Figure 29. Sequence diagram for LPU012


change of data in the "push" mode

...............................
40

Figure 30. Sequence diagram for LPU012


readout in
the "pull" mode

................................
...........
41

Figure 31: Sequence diagram for LPU016

................................
................................
.....................
42

Figure 32. Sequence diagram for LPU17

................................
................................
.......................
43

Figure 33. LPU in Reporting Ca
tegory

................................
................................
..........................
43

Figure 34. Sequence diagram for LPU18

................................
................................
.......................
44

Figure 35. Sequence diagram for LPU19

................................
................................
.......................
44

Figure 36: Definition of grammar in ASN.1 notation

................................
................................
......
63

Figure 37: Response 1
-
1
-
4 in the APDU form

................................
................................
................
63

Figure 38: Query 1
-
1
-
1 in ASN.1 notation

................................
................................
.....................
64

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

4

z
90

Figure 39: Response 1
-
1
-
1 in the APDU form

................................
................................
................
64

Figure 40: Response 1
-
1
-
1 in ASN.1 notation

................................
................................
................
65

Figure 41: Response 1
-
1
-
4 in the APDU form

................................
................................
................
65

Figure 42: Query 1
-
1
-
4 in ASN.1 notation

................................
................................
.....................
65

Figure 43: Response 1
-
1
-
4 in the APDU form

................................
................................
................
66

Figure 44: Response 1
-
1
-
4 in ASN.1 notation

................................
................................
................
67

Figure 45: Response 1
-
5
-
4 in the APDU form

................................
................................
................
67

Figure 46: Query 1
-
5
-
1 in ASN.1 notation

................................
................................
.....................
67

Figure 47: Response 1
-
5
-
1 in the APDU form

................................
................................
................
68

Figure 48: Response 1
-
5
-
1 in ASN.1 notation

................................
................................
................
68

Figure 49: Response 1
-
5
-
4 in the APDU form

................................
................................
................
69

Figure 50: Query 1
-
5
-
4 in ASN.1 notation

................................
................................
.....................
69

Figure 51: Response 1
-
5
-
4 in the APDU form

................................
................................
................
70

Figure 52: Response 1
-
5
-
4 in ASN.1 notation

................................
................................
................
71

Figure 53: Response 5
-
1
-
4 in the APDU form

................................
................................
................
72

Figure 54: Query 5
-
1
-
1 in ASN.1 nota
tion

................................
................................
.....................
72

Figure 55: Response 5
-
1
-
1 in the APDU form

................................
................................
................
73

Figure 56: Response 5
-
1
-
1 in ASN.1 notation

................................
................................
................
74

Figure 57: Response 5
-
1
-
4 in the APDU form

................................
................................
................
74

Figure 58: Query 5
-
1
-
4 in ASN.1 notation

................................
................................
.....................
75

Figure 59: Response 5
-
1
-
4 in the APDU form

................................
................................
................
75

Figure 60: Response 5
-
1
-
4 in ASN.1 notation

................................
................................
................
79

Figure 61: Response 5
-
5
-
4 in the APDU form

................................
................................
................
79

Figure 62: Query 5
-
5
-
1 in ASN.1 notation

................................
................................
.....................
80

Figure 63: Response 5
-
5
-
1 in the APDU form

................................
................................
................
81

Figure 64: Response 5
-
5
-
1 in ASN.1 notation

................................
................................
................
83

Figure 65: Response 5
-
5
-
4 in the APD
U form

................................
................................
................
83

Figure 66: Query 5
-
5
-
4 in ASN.1 notation

................................
................................
.....................
84

Figure 67: Response 5
-
5
-
4 in the APDU form

................................
................................
................
84

Figure 68: Response 5
-
5
-
4 in ASN.1 notation

................................
................................
................
90





Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

5

z
90


1

Glossary
of terms and acronyms

Table
1
. Glossary of terms and acronyms

Term

Explanation

AES

Advanced Encryption Standard


symmetric block cipher adopted by
the National Institute of Standard and Technology.

AES
-
GCM 128

Advanced
Encryption Standard


Galois/Counter Mode


GCM is a
double
-
functionality cipher and authentication mode. AES performs
10 (128
-
bit key) substitution
-
permutation cipher rounds. They consist
of preliminary substitution, permutation matrix (mixing of rows,
mi
xing of columns) and modification with 128
-
bit key.

AMI

Advanced Metering Infrastructure.

Comprehensive system of meters, communication systems and
applications for gathering, storing and analyzing the metering data
and managing the metering infrastructur
e.

APDU

Application layer Protocol Data Unit

Application

Centralized AMI application


responsible for gathering and
managing the metering data

ASN.1

Abstract Syntax Notation One


standard used to describe the
structures designated for representation,
coding, transmission and
decoding of data

BER

Basic Encoding Rules


method of coding the data described by the
ASN.1 specification

CA

Certification Authority


institution of trust, office of certification

CBP

Central Metering Database

CAZ

Central
Managing Application.

Certificate

Public key and information on the entity's identity signed digitally by
the office of certification

COSEM

Companion Specification for Energy Metering


set of specifications
compiled by DLMS UA defining the IT model of
the facilities,
including, among other things, electricity meters

DCSML

Data Concentrator Smart Message Language


communication
protocol constituting an extension of standard SML specification to
include additional functionalities (e.g. multicast, broadc
ast). Created
for the purpose of implementation of the AMI System in DSO

DLMS

Device Language Message Specification


communication
-
oriented
application layer protocol designed to support, among other things,
two
-
way data exchange with the electricity met
ers

DSO

Distribution System Operator

GSM

Global System for Mobile Communications (originally, Groupe
Spécial Mobile)


mobile telephony standard

GPRS

General Packet Radio Service


method of sending data in packets in
Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

6

z
90

Term

Explanation

GSM networks

GZIP

Program used for

file compression, based on the Deflate algorithm,
constituting a combination of LZ77 algorithms and Huffman coding
algorithm

HAN

Home Area Network


Home Netwo牫 encompassing the devices
within the 䥮telligent 䉵ilding in晲fst牵ctu牥, equipped with 牥mot

cont牯l and data p牯viding 晵nctionalities ⡨eating, ai爠conditioning,
household appliances and 牡dio/TV equipment⤮ 䥮 addition, HAN
may be comp物sed o映P䍳 and house te牭inals used 景爠monitoring
elect物city consumption and managing the devices and met
e牳.

Mete物ng 䥮晲fst牵ctu牥

Technical in晲fst牵ctu牥, including ha牤ware and so晴wa牥, whose
pu牰ose is to p牯vide adequate communication between recipients of
elect物city and

DSO, including in景牭ation on elect物city
consumption. The Mete物ng 䥮晲fst牵c
tu牥 connects to the Application
System via the 䥮te牭ediating 䥮晲fst牵ctu牥. The Mete物ng
䥮晲fst牵ctu牥 will be comprised o映powe爠mete牳 and concent牡to牳 as
well as othe爠devices connected to them, including HAN devices and
mete牳 o映othe爠utilities.

䭄K

Mete物ng Data 䍯ncent牡tor

KDLP

Mete物ng Data 䍯ncent牡to爠


P牯g牡m.



Elect物city Mete爮

LPU

Mete爠Use 䍡se.



Low voltage.

O䉉B

Object 䥤entification System


system o映coding the 䍏SEM model
objects.

OSI

Open System 䥮te牣onnection.


standa牤 de晩ned by the 䥓O and
䥔U
-
T o牧anizations, desc物bing the netwo牫 communication
st牵ctu牥.

PKI

Public Key 䥮晲fst牵ctu牥


st牵ctu牥 o映t牵st, based on con晩牭ation
o映 authenticity with use o映ce牴i晩cates issued by the hie牡牣hy of
ce牴i晩cation o晦fces.

PLC

Power Line Communication/Carrier


communication technique
allowing to 牥motely send the data via the elect物city cables.

P剉RE

Powe剬ine 䥮telligent Mete物ng Evolution


open specification
de晩ning communication in the lowest
laye牳 o映the communication
system a晴er PL䌬 晲fm the te牭inal devices ⡭ete牳⤠to the data
concent牡to爠located in the medium
-
voltage/low
-
voltage t牡ns景牭e爠
station.

SAK

Acquisition System.

SML

Sma牴 Message Language


application laye爠p牯tocol devel
oped by
the MeKo p牯ject g牯up, designated to suppo牴, among othe爠things,
two
-
way data exchange with the elect物city mete牳.

The MeKo p牯ject g牯up is comprised o映the 景llowing: D爮 Neuhaus
Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

7

z
90

Term

Explanation

Telekommunikation GmbH, E.ON Mitte AG, E.ON Netz GmbH,
Emsycon G
mbH, EnBW Vertriebs und Servicegesellschaft mbH,
Landis+Gyr GmbH, RWE Rhein
-
Ruhr Netzservice GmbH.

MV

Medium voltage.

SSH

Secure Shell


standa牤 o映 communication p牯tocols used in the
T䍐/IP compute爠netwo牫s, in the client


se牶e爠architectu牥. 䥴
i
s

used 景爠connecting to the 牥mote compute爬 and p牯vides enc特ption
and allows authentication o映the use爠by many methods.

S
-
䙓F

Sp牥ad F牥quency Shi晴 Keying


one o映 the techniques 景爠
t牡nsmitting the data th牯ugh the PL䌠netwo牫.

T䍐/䥐

T牡nsmission

䍯nt牯l P牯tocol/Inte牮et P牯tocol


set o映transmission
⡔䍐⤠and netwo牫 ⡉(⤠laye爠p牯tocols p牯viding a unified method of
sending the data in va物ous types o映netwo牫s.

TLS/SSL

TLS ⡔牡nspo牴 Laye爠 Secu物ty⤠


extension o映 the SSL ⡓ecu牥
Socket Laye
爩rp牯tocol, adopted as 䥮te牮et standa牤, which aims at
p牯viding confidentiality and integrity o映 data t牡nsmission and
ensu物ng authentication; it is based on asymmet物c ciphe牳 and
ce牴i晩cates o映X.509 standa牤.


-


Web Se牶ices 剥sou牣e T牡nsfe爠


p牯tocol based on the popula爠
WebSe牶ices technology used in case of data exchange between the
applications ope牡ting in the T䍐/IP netwo牫, created unde爠 the
DSM删standa牤.

xDLMS

Extended DLMS


extension o映 the DLMS p牯tocol to the
DLMS/䍏SEM standa牤
de晩ned by no牭 䥅䌠62056
-
㔳5

XML

Extensible Ma牫up Language


it is a ma牫up language used 景r
desc物bing the data. 䥴 is the method o映p牥senting the hie牡牣hical
st牵ctu牥 o映nodes and thei爠att物butes in the 景牭 o映a "flat" text file
with a p牥cisely

de晩ned st牵ctu牥.




Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

8

z
90

2

Introduction

This document is an excerpt from

the

document entitled "
C
ommunication
Standard B
etween the
Application and the Metering Infrastructure" (version 2.00).

The document contains the concept and
the
basic assumptions for the

communication standard with a
proposed
custom
DCSML communication protocol created
especially
for Energa
-
Operator SA's needs.
The standard takes into account the needs and characteristics of the AMI System.

Th
is document presents
:



use cases for communicat
ion between the Application and the Metering Infrastructure,



description of messages,



grammar

of the protocol
,



examples of
queries

and
responses

in DCSML (in the APDU and source form).



Development of the communication standard takes into account the
guidelines included in the
following document:

[1]

Stance of the President of ERA in the matter of requirements for intelligent metering and billing
systems implemented by OSD E, taking into account the purpose and the proposed support
mechanisms for the postu
lated market model. ERA 2010.
http://www.ure.gov.pl/download.php?s=1&id=4295P1.3 AMI Application. Concept of the
Integrated Application System. Central Managing Application. 2011.05



Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

9

z
90

3

Concept for the communication standard in DSO

In this chapter we have pr
esented the assumptions which were adopted for work on the proposed
communication standard, and presented the concept of the standard based on the assumptions adopted.

3.1

Assumptions for the communication standard

3.1.1

General assumptions

The following general ass
umptions were adopted:

1.

It must ensure sufficient functionality to meet all the requirements of the AMI System in DSO.

2.

It must be open to all metering devices, not just power meters (natural gas, water, heat
meters).

3.

It must ensure communication between dev
ices of various manufacturers (which use that
standard).

4.

It should be precisely defined so as to ensure conducting of tests guaranteeing cooperation
between the devices.

5.

It must ensure communication between:

a.

KDL and SAK


if readings take place through KDL

(PLC).

b.

LE and SAK


if readings are performed directly by SAK (GPRS, GSM, LAN/WAN).

In addition, in order to prevent the path to the author's solution from being closed, it is proposed that
the following recommendations are met, however they are not
mandatory.

1.

The protocol should be regulated by the standards, in order to guarantee its openness and
development.

2.

Usage of the protocol should be verified through prior large
-
scale implementations.

3.1.2

Technical assumptions

The following technical assumptions
were adopted:

1.

Due to limited throughput of connections between KDL and SAK, it is necessary to:

a.

minimize the size of the message (
queries

and
response
s),

b.

minimize network traffic between SAK and KDL (type broadcast and multicast
messages).

2.

KDL is "non
-
tran
sparent" which means that SAK communicates with KDL in the manner
minimizing the network traffic (see the assumption above), and KDL is responsible for
optimal organization of communication with LE.

3.

The manner of SAK's communication with LE should be unifi
ed regardless of the
communication channel used. Accordingly, if the meter does not communicate with the
infrastructure through PLC (but through e.g. GPRS) and therefore there will be no KDL
between LE and SAK, Program Concentrator will be functionally ins
erted in KDL's place
which will fulfill KDL's functions.

4.

SAK has to be able to send to LE the message in the "transparent KDL" mode.

5.

It is necessary to properly secure the data through the following:

a.

authentication,

b.

authorization and access rights,

c.

cipheri
ng,

d.

data integrity (control and error correction mechanisms).

6.

We propose to use open solutions as far as implementation of data security measures is
concerned.

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

10

z
90

7.

We propose to use prioritization at the level of lower communication layers as well as the
appli
cation layer.


3.2

Overall concept of the communication standard

Communication standard should be reviewed in the following areas.


Figure
1
. Areas of communication in the AMI system


1.

Area I


communication between the SAK system and KDL


communication will be
conducted through the connection based on TCP/IP with minimum throughput of 64 kbit/s (in
one of two basic communication techniques: PLC MV or WiMax).

2.

Area II


communication between KDL
and LE


communication will be conducted through
connection in PLC technology.

3.

Area III


communication between the SAK system and LE


communication will be
conducted through the connection based on TCP/IP through GPRS with throughput of 30


80 kbit/s.


COSEM
OBJECTS

COSEM
OBJECTS

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

11

z
90


Figure
2
. Areas of communication in the AMI system


layers of the protocol

3.2.1

Area of communication between SAK and concentrators

We propose development and implementation of
language and standard of communication with the
concentrator based on structures and solutions used in SML (Smart Message Language). Definition of
SML is based on ASN.1 notation which allows to expand basic available functions to include new
functionalitie
s which we need. Therefore we propose adaptation of SML for the purposes of this
project.

Grouped SML messages (application layer protocol) are sent in the form of binary files
-
streams in
which SML messages are encoded in accordance with ASN.1 to the binar
y form. Writing format based
on XML will not be used because files have large sizes and the time of processing and interpretation
of contents of XML files by computer systems is very long.

Due to the fact that the proposed language of communication between

SAK and KDL is based on
SML, we would like to propose to name that language DCSML


Data Concentrator Smart Message
Language.

In the presentation layer for sending DCSML files, TLS or SSL protocol will be used as standard
security measure for communicatio
n between the Application System and the concentrator. TLS/SSL
provide the mechanisms of user authentication and encoding of the sent content on the basis of AES
128 cryptographic algorithm.

3.2.2

Area of communication between concentrators and meters

We propose

to use open, normalized communication standards in the layer of communication between
KDL and meters. In the physical and data connection layer we recommend to use the PRIME protocol,
and in the application layer


we recommend to use the DLMS/COSEM stand
ard.



The PRIME physical layer and data connection layer protocol is adequate because it has the
following features:

o

it is a
well
-
defined

and described standard,

o

there are several laboratory centers in the world which certify hardware for
compliance with PR
IME specification,

SAK
-

KDL

KDL
-

LE

KDLP
-

LE

COSEM Application
Layer



COSEM Application
Layer

COSEM Application
Layer


(PLC SN, WiMax,
GPRS))

PLC OFDM

DCSML





PN/EN 61334
-
4
-
32

Wrapper Layer

UDP



TCP




GPRS, …

DLMS

PRIME MAC

PRIME
PHY

DLMS

PLC OFDM

IP

IP

TLS

TCP



UDP



Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

12

z
90

o

the standard does not breach patent rights of third parties,

o

it is a modern solution which is based on the technique of OFDM modulation in the
physical layer; in addition, it is characterized by small markup on the size of
transmitted da
ta, control of errors in MAC PDU frames and dynamic adaptation of
the network's logical structure for the purpose of optimizing the communication and
in the situations involving disruptions and/or damages of individual network nodes
(mesh
-
type networks),

o

i
t provides data transmission security mechanisms.



The DLMS/COSEM application layer protocol is adequate because it has the following
properties:

o

it is a defined standard which is developed and maintained by DLMS User
Association,

o

verification of compliance

with the standard consists in performance of several tests
defined in DLMS User Association's Yellow Book,

o

it has a concise format of APDU data packets as compared to other protocols used in
metering communication (e.g. IEC1107, IEC61056
-
21, etc.),

o

it pro
vides all the necessary packet security mechanisms (authentication,
authorization, ciphering and data integrity),

o

it provides description of metering data for various types of utilities supplied
(electricity, water, heat, natural gas).

The standard communi
cation technologies recommended for the layer of communication between
concentrators and power meters serve the following purposes:

1.

Providing replaceability of metering equipment coming from various suppliers on the market,
and therefore ensuring
independence from a single supplier which could try to dictate its own
prices in the future.

2.

Eliminating problems related to disruptions in communication with devices operating in
various PLC technologies within the same electricity segment.

3.

Utilization of

knowledge and long experience of manufacturers and associations developing
the standard solutions which have been captured in the norms.

3.2.3

Area of communication between SAK and meters

Due to preservation of unified form of communication with concentrators a
s well as the group of those
electricity meters which will be qu
eried
directly by the SAK system and because of the TCP/IP
communication protocol of the transportation layer, also in this case we are planning to use the
DCSML protocol as the application la
yer protocol in communication between SAK and the program
concentrator (KDLP).

For the purpose of unifying communication between SAK and LE i.e. for the purpose of covering with
the proposed standards also those LEs which may (or must) communicate with oth
er channel than
PLC, it was assumed that in such cases communication would take place via the Program Concentrator
(KDLP). The advantage of such solution involves separation of the process of communication with the
meters outside of the Acquisition System.

It is assumed that at the present time communication takes
place through that path in case of approx. 2% of all power meters. However, one cannot be certain that
the number of meters which conduct communication in that path will not increase in the future
.
Moreover, during implementation of metering infrastructure it may turn out that there are locations
(geographic areas) in which it will not be possible to use PLC. Separation of Program Concentrator
KDLP will make it possible to use larger than assumed q
uantity of meters. Moreover, there can be
Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

13

z
90

more than one KDLP in the system in various geographic locations and on many hardware items
(workstations).

We propose to use open, normalized communication standards in the layer of communication between
KDLP and
meters. We recommend to use the complete DLMS/COSEM standard. Due to the fact that
GPRS connections with TCP/IP are used, DLMS wrapper captured in the DLMS/COSEM standard
should be used in the presentation layer.

3.2.4

Traffic prioritization

The purpose of broad
ly understood traffic prioritization is to ensure the option of sending messages
with various degree of importance and in different time regimes, so that transmission of less important
messages would not block more important ones.


Before describing rules
and execution of traffic prioritization, the assumptions for the executed (and
therefore prioritized) Tasks were given.

3.2.4.1

Tasks

The following assumptions concerning the Tasks were accepted:


1.

The Tasks have the following characteristics:

a.

they may include one
or several activities,

b.

if the tasks include several activities, the sequence of their performance should be
specified,

c.

the tasks may be addressed to one, many (multicast) or all (broadcast) meters.

2.

The Task may be ordered by CAZ to SAK in the following way
:

a.

instruction to perform the task issued on one
-
off basis to one or several meters (to be
performed immediately or in the future)

b.

instruction, issued to one or several meters on one
-
off basis, to perform cyclical task
(e.g. daily subscription)

3.

The main att
ributes of single task are as follows:

a.

priority: standard, high, critical (standard priority is accepted as default),

b.

manner of execution:

i.

single communication session: PULL (intended for execution of short tasks
within a single meter e.g. switch off the
contactor).

[See
Figure
3
]

ii.

two communication sessions: PULL + PULL (intended for execution of
complex tasks, assuming that it will be decided that SAK
will read the
results); the first session includes sending the task to KDL, the second


sending the results to SAK. [See
Figure
4
]

iii.

two communication sessions: PULL + PUSH (intended for execution of
complex tasks, assuming that it will be decided that KDL will read the
results); the first session includes sending the task to KDL, the second


sending the results to SAK. This method is
the basic method used in mass
readout of data from LE. [See
Figure
5
]

iv.

single communication session: PUSH (for readout of event data concerning
emergen
cy situations). [See
Figure
6
]

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

14

z
90


Figure
3
: Diagram of the sequence


single communication session PULL



Figure
4
: Diagram of the sequence


two communication sessions PULL + PULL




sd PULL

SAK

(from SAK Actors)

KDL

(from SAK Actors)

LE

(from SAK Actors)

Get data()

ack()

Get
data()

Send data()

Send data()

ack + disconnect()



sd PULL PULL

SAK

(from SAK Actors)

KDL

(from SAK Actors)

LE

(from SAK Actors)

Get

data()

ack + disconnect()

Get data()

Send data()

Get data()

Send data()

ack + disconnect()

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

15

z
90


Figure
5
: Diagram of the sequence


two communication sessions PULL + PUSH



Figure
6
: Diagram of the sequence


single communication session PUSH


4.

Configuration of the manner of
executing the tasks will take place on the side of the CAZ
system, with reservation that only system Administrator will have access to configuration of
the manner of executing the task (p. 3b) and the users will only choose specific tasks from the
availabl
e, previously configured list.

3.2.4.2

Prioritization rules

The following options for parameterization of priorities were specified as part of data exchange
process:

1.

Priority on the level of SAK
-
KDL communication and processing by KDL (KDL
-
LE
communication)

2.

QoS fo
r data on the TCP/IP level

Priority
on the level of SAK
-
KDL communication allows to determine which tasks on the central
level concerning communication with Concentrators and Meters will be processed firstly.
Priority
also allows to determine which tasks r
elated to communication with the individual meters should be
performed by KDL firstly.



sd PULL PUSH

SAK

(from SAK Actors)

KDL

(from SAK Actors)

LE

(from SAK Actors)

Get data()

ack + disconnect()

Get data()

Send data()

Send data()

ack + disconnect()



sd PUSH

SAK

(from SAK Actors)

KDL

(from SAK Actors)

LE

(from SAK Actors)

ALARM()

ALARM()

ack + disconnect()

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

16

z
90

QoS for data on the TCP/IP level

is a recommendation for communication sessions (provided that
this mechanism is supported by the concentrator) which are initiated by the Concentrators for the
purpose of sending the results to SAK. Contrary to the possibility of queuing tasks in SAK, suc
h
option is not available if transmission is initiated in the opposite direction (KDL

SAK), therefore if
priorities are assigned at the data packet (QoS) level, the results of tasks specified as urgent will be
delivered and they will be processed further b
y SAK with first priority.


Priorities may accept the following values:

1.

Standard
, in normal mode for the flow of typical information for which no high time regimes
have been set

2.

High
, for the flow of information with high degree of importance which should
be delivered
promptly

3.

Critical
, for the flow of information with the highest degree of importance e.g. for the purpose
of voiding the performance of high priority tasks


to be used in specific cases.

Processing will firstly include tasks with the highest
priority and then with high priority. The tasks
with standard priority will be performed last.


It should be also noted that if a task of higher priority emerges, other tasks which are being performed
at that time will not be aborted and they will be final
ized. However, next tasks with smaller priority
will not be commenced. Tasks of higher priorities will start to be accepted for execution only after the
required resources are freed. After the last task of higher priority is accepted, the process of accept
ing
tasks of lower priorities will start.


If QoS is utilized on the level of TCP/IP packets, priority will be the number in the range 0
-
65535.
Management of QoS parameter is carried out by the concentrator. It is recommended that three
priorities on the Q
oS level corresponding to the priorities defined for the application layer be serviced
through the concentrator. The number defining the priority should be the parameter which is remotely
configurable on the concentrator (from the SAK level). In order to e
nable the mechanism's operation,
the URG flag should be set on the level of the TCP/IP packet and the numerical value representing the
priority should be configured.


Due to the fact that the tasks and priorities may be executed in different ways on severa
l levels, below
we would like to present the options of configuring the tasks:

No.

Performance of the task

Priority

QoS

1.

PULL

YES

YES

2.

PULL + PULL

YES

YES

3.

PULL + PUSH

YES

YES

4.

PUSH

NO

YES


Priorities may be configured for tasks carried out as

part of single communication sessions (PULL)
and as part of double communication sessions (double PULL as well as PULL + PUSH). Priority
involves communication on the SAK
-
KDL contact with respect to queuing the tasks and their
processing as well as proces
sing of data by KDL, including communication on the KDL
-
LE contact.

The priority cannot be configured for transmission of emergency events in the PUSH mode because
due to high importance of the events, these tasks are processed by SAK with first priority.


In order to enable the execution of prioritization mechanisms, it is recommended to implement the
following mechanisms on the Concentrators:

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

17

z
90

1.

Parallel handling of TCP/IP session on the level of communication between SAK and KDL
should be implemented on the

concentrator.

2.

If it receives another parallel task (SAK
-
KDL session of higher priority), the Concentrator
should freeze the execution of current tasks with lower priority until the task of higher priority
is finalized.

3.

In case of another parallel SAK
-
KDL
session with the same priority, the concentrator should
enable parallel processing of all tasks with the same priority.

4.

If several SAK
-
KDL sessions appear, where one of them will have a higher priority than the
others, the tasks of other sessions with lowe
r priority should be put on hold until the
performance of the task of higher priority session is finalized.

5.

If the Concentrator stops the performance of the task, it should finalize the performance of
atomic operation on the level of the PLC network e.g. r
eadout of a single parameter from the
given Meter, before beginning to perform the activities as part of a different task of higher
priority.

6.

In case of performance of tasks as part of individual communication sessions, the appearance
of another task of hi
gher priority should not stop the performance of that first task so as not to
stop the unnecessarily initiated SAK
-
KDL session. The tasks which are stopped should be
only the ones which are performed as part of double communication sessions (order + result
s
readout).


In case of direct communication between SAK and the meters, communication will take place through
the program concentrator and the above
-
described rules for the case of communication SAK


Concentrator


Meter will be applied.

3.2.5

Digital signatur
es

Means of securing the SAK
-
KDL communication involve the TLS/SSL mechanism based on the keys
of the PKI infrastructure. CA should be provided by IT DSO services.

3.2.6

Concept of transport

I.

Transport of data on the Acquisition Server


Concentrator path

The DCS
ML (Data Concentrator Smart Message Language) protocol, which is the modification of
SML from the standpoint of optimization of processing for the needs of implementation of the AMI
system in DSO, was used for exchange of data in the application layer.

The

protocol enables flexible definition of
querie
s and
responses
to
such queries
. It is a platform for
exchange of data in the standardized manner on the Acquisition Server


Concentrator path. The data
i.e. the tasks as well as the results are formed into A
PDU elementary binary units which are designated
for sending in a unified form from the Acquisition Server (SAK) to the Concentrator (KDL) or in the
opposite direction.

As part of the session layer of the ISO OSI model, the TLS/SSL protocol with the AES al
gorithm was
used as the data stream layer, as well as authentication with public and private keys. The process of
setting up a connection is as follows:

1.

Connecting the Acquisition Server with the Concentrator on the level of TCP/IP sockets on
the specified

port.

2.

Authentication:

a.

AMI server initiates connection with the concentrator and sends a random number

b.

Concentrator sends its certificate (public key) and a random number to the server

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

18

z
90

c.

AMI server sends its certificate (public key) to the concentrator

d.

AMI
server generates the session key (used in ciphering of AES), ciphers it with the
concentrator's public key and sends it to the concentrator

e.

AMI server signs the previously mentioned random numbers with its own private key

f.

Concentrator deciphers the session

key with its own private key (the fact of having the
deciphered session key i.e., in consequence, having the private key consistent with the
public key, is the proof of the concentrator's identity)

g.

Concentrator verifies the signature sent by AMI server ag
ainst the server's public key
(correctness of the signature is the proof that the AMI server has a private key
consistent with the public key i.e. confirms the server's identity)

h.

The authenticated parties commence the transmission of data with use of the A
ES
algorithm and the key mentioned in item 4.

i.

If there is an error in authentication (e.g. incorrect keys), the Acquisition Server and
the Concentrator will immediately break the connection at the TCP/IP level.

3.

Setting up the ciphered transmission session
on the basis of the symmetric key and conducting
cyclical dialog:

a.

Acquisition Server sends a demand in the form of APDU data packet,

b.

Concentrator sends a response in the form of APDU data packet,

c.

Transmission session is closed.

It is possible to optimize t
he authentication process by removing the need to each time exchange the
public keys (they are stored locally on the side of SAK and KDL), provided that it is technically
possible to carry out such algorithm.


II.

Transport of events on the Concentrator


Acqu
isition Server path

In the application as well as transportation layer, the two
-
way communication is symmetric.
Communication takes place through the DCSML protocol (described in chapter
0
), secured by
TLS/SSL protocol.

Due to the fact that events are asynchronous, it is possible that there will be a large number of attempts
to make a connection during a short period of time. Load balancer will be use
d on the side of the
acquisition server, whose tasks will include distribution of load between the individual nodes of the
SAK cluster which will independently process the reported events.

The presence of many SAK nodes and distribution of load are not imp
ortant to the Concentrator from
the point of view of communication. Concentrator makes a connection to the previously defined
address of the Acquisition Server as if it were a single server.


III.

Requirements of the network infrastructure

Communication between

Acquisition Servers and Concentrators takes place at the level of TCP/IP. In
order to ensure that the concentrator or meter will be addressed unequivocally (in case of 2% of meters
with which communication will be conducted directly), it will be necessary

to assign them with unique
IP addresses in the global scale of the DSO network. There are two options of assigning IP addresses


statically and dynamically. The first method assumes manual configuration of network parameters on
the concentrators before t
heir installation in the field. The second one assumes using DHCP servers for
automatically assigning the IP addresses and other network configuration parameters.

Due to large scale of the undertaking and the fact that it will be necessary to configure app
rox. 60
thousand Concentrators, there exists the risk of occurrence of significant percentage of incorrect
Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

19

z
90

configurations resulting from human errors. Therefore it is also recommended to automatically assign
the IP addresses via the DHCP servers.

1.


Fulfillment of the following requirements will ensure departure from manual configuration of
IP addresses of the Concentrators on the assembly tables in favor of automatic configuration:
assigning the concentrators with IP addresses by DHCP servers from t
he global address pool
intended for the metering equipment. The global address pool is understood as the pool of
addresses dedicated to the metering infrastructure within the DSO network, however this does
not mean that it will be necessary to use the frag
ment of the Internet global address pool.

2.

Automatic reservation of IP addresses for each MAC address of the concentrator (or the meter
from the 2% pool) so that such address would be the same in case of next requests to assign
the IP address sent by the sa
me device.

3.

Storing the reservations of addresses for 90 days if there is no activity of the devices. Only if
the devices are inactive for a longer period of time the IP address may be released and
assigned to a different concentrator (or the meter from the

2% pool)

4.

Synchronization of reservations of IP addresses between the DHCP servers in such way so as
to ensure that unique addresses are assigned to the individual devices. Or possibly using a
single DHCP central server for the entire metering network.

Det
ails of network infrastructure management policy must be consistent with DSO's corporate policy
in that regard.



Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

20

z
90

4

Meter Use Cases

In this chapter we presented the results of analytical work associated with the defined cases of usage of
the Metering Infrast
ructure.

The list of Meter Use Cases was compiled.

For each case, the messages and other data exchanged between SAK, KDL and LE were analyzed.

On the basis of the results of this analysis, the syntax of DCSML was developed i.e. a set of messages
which shou
ld be sufficient for servicing all the identified Meter Use Cases (LPU).

4.1

Categories, Identifiers and Statuses of Meter Use Cases

The table below presents categories which were defined for Meter Use Cases.


Table
2
. Categories of Me
ter Use Cases

Code

Name

Description

I

Installation

LPUs for installation and deinstallation of KDL and LE, exchanges,
software updates, etc.

K

Configuration

LPUs related to configuration of KDL and LE.

O

Readout

LPUs for readouts of metering data.

S

Control

LPUs requiring that requests controlling the devices' operation be
sent to LE and/or KDL.

Z

Notification

LPUs executed through alarm being reported by LE and KDL. This
category was highlighted because LPUs related to it require special
flow of
messages between the devices.


The following was assigned to each LPU:



Identifier,



Category,



Status.

The identifier has the following structure: LPUnna, where:



LPU is constant,



nn is a number (with a zero which does not have the meaning); due to the fact
that the list will
be updated, LPUs may be removed from it, hence the nn numbers do not necessarily have to
be the subsequent numbers,



a is a small letter (optional) which makes it possible to insert new LPUs in the logical
sequence between the already exi
sting LPUs.

Statuses may have the following values:



A


active LPU, to be serviced in the first version of DCSML,



B


LPU to be serviced in the future,



W


doubtful LPU, a decision as to its existence should be made in the course of further
analytical work
,



X


voided LPU, logically removed from the LPU list; it is not physically removed from the
list so as to prevent its identifier from being used once again which could lead to confusion.

In the later analysis related to DCSML project, only LPUs with "A"
status were taken into account.

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

21

z
90

4.2

List of Meter Use Cases

The table below contains the list of LPUs with "A" status.


Table
3
. Meter Use Cases with "A" status.

ID

Name

LPU01

Installation of new LE, reporting of LE after power
failure

LPU02

Installation of new KDL

LPU03

No communication with LE

LPU04

KDL Shutdown/Failure

LPU05

Update of LE's software

LPU06

Update of KDL's software

LPU07

LE configuration

LPU08

KDL configuration

LPU09

Definition of subscription

LPU10

Readout of LE registers

LPU11

Readout of configurations and data from KDL

LPU12

Execution of subscription

LPU13

Readout of LE configuration

LPU14

Verification of connection with LE

LPU15

Verification of connection with KDL

LPU16

Direct communication
with LE (transparent concentrator mode)

LPU17

Restart of KDL

LPU18

Reporting of alarm by LE

LPU19

Reporting of alarm by KDL

LPU20

LE time synchronization / change


The full list of Meter Use Cases


with specification of the Category


is contained in

Appendix no. 2
to this document in "LPU" Sheet.

4.3

Analysis of Meter Use Cases

The following was specified for each LPU:

1.

Scope.

2.

Exchanged data and messages (sequence diagrams).

On the sequence diagrams, the exchange of data between SAK and KDL was described
with the
proposed DCSML messages. Under the diagrams, the descriptions of the individual flows were placed,
where the subsequent points correspond to the subsequent flows labeled with point numbers.


The following rules of communication between SAK and KDL

were adopted:

1.

The key objective to be achieved is the minimization of data flows with simultaneous
minimization of waiting time for replies from LE.

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

22

z
90

2.

It has been assumed that, by principle, data will be transferred from KDL to SAK immediately
after their c
ompletion in KDL. For this purpose, the "push" method will be used i.e. sending
the data from KDL to SAK without waiting for request from SAK.

3.

It will be possible to perform readouts of data from LE using the "pull" mode. Enforcement of
the "pull" mode
will be possible:

a.

at the level of a single Task involving readout of data from LE


in such case, the
Task will be provided with the "execution in the pull mode" attribute,

b.

at the KDL level


in such case, the "execute the Tasks involving readout of data f
rom
LE in the pull mode" value will be set in KDL's configuration parameters,

c.

at the SAK level


in such case, all the Tasks involving readout of data from LE will
be provided with the "execution in the pull mode" attribute,

d.

at the Subscription level


in
such case, all the Tasks involving readout of data from
LE generated by KDL as part of Subscription will be provided with the "execution in
the pull mode" attribute.

4.

In the KDL configuration, the maximum waiting time for completing a response from LE will
be defined. After this time is exceeded, KDL will transfer the data collected by that moment to
SAK


regardless of how many LEs responded by that moment.

5.

After receiving a reply from KDL, SAK will verify the completeness of the data received. If
they are
incomplete, it will take proper actions such as verification of LE's status in CAZ (on
the basis of data from SID), checking the connection with LE or once again asking for the
missing data.

6.

In the subscription mode, KDL is the initiator of tasks in the su
bsequent cycles. Information
on subscription requests is recorded in SAK and KDL so that SAK would be able to control
whether the maximum time for sending the data by KDL has not been exceeded.

7.

It has been assumed that LE may be seen by only one KDL. The s
ituation in which the same
LE is reported by different KDLs will be considered erroneous and it should be reported with
critical priority to CAZ.

8.

Tasks related to readout of data from LE, configuration and replacement of LE's firmware
may be addressed to:

a.

a single LE,

b.

many LEs (multicast),

c.

all the LEs (broadcast).


Note: The objective of the conducted analysis was to develop a language of communication between
SAK and KDL. For this reason, the sequence diagrams pertain only to communication between SAK
and
a single KDL and the meters serviced by that KDL. This analysis does not cover the method of
generating the type multicast and broadcast DCSML commands aimed at individual KDLs on the
basis of orders received by SAK from the Central Managing Application.


The sequence diagrams for the individual Meter Use Cases presented in the later part of the document
should be treated as proposed method of exchanging the data between the individual LPU actors. In
reality, details concerning the sequence as well as the e
xchanged data will depend on specific solutions
of the individual manufacturers as well as the results of further analytical and design work.

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

23

z
90

4.3.1

Installation Category

The below diagram presents the Meter Use Cases in Installation Category.




Figure
7
. LPU in Installation Category







uc
Installation Category

LPU01 Installation

of new LE,

reporting of LE after

failure

LPU02 Installation

of new KDL

LPU03 No

communication with LE

LPU04

Shutdown / Failure of

KDL

LPU05 Update

of LE software

LPU06 Update

of KDL

software

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

24

z
90

4.3.1.1

LPU01: Installation of new LE, reporting of LE after failure

Scope



new LE reporting to KDL,



reporting of LE to KDL after power failure/schedule power shutdown.

Sequence
diagrams


Figure
8
. Sequence diagram for LPU01


correct situation



1.

LE reports to KDL as new or after failure. The report contains the LE identifier and the code
of the message associated with the report. The code

of the reporting message indicates the
reason for LE's reporting to KDL.

2.

KDL checks whether LE is in its routing table.

a.

If LE has reported itself as a new one and it is not in the routing table => go to item
no. 7.

b.

If LE has reported itself after failure
and exists in the routing table => go to item no.
7.

3.

KDL sends to SAK the information on the report from LE and the problem related to it.

4.

SAK checks whether the new LE is in the routing table of a different KDL.

5.

If LE is in the routing table of a differen
t KDL, then SAK
queries

this KDL to make sure that
LE is accessible from two KDLs.

6.

If such situation occurs, then SAK will send a high priority alarm to CAZ.

7.

KDL notifies SAK that LE has reported to it.

8.

SAK sends to KDL the confirmation of data receipt.




sd LPU01 Installation of new LE, reporting o
f
LE
after power failure

SAK

(from LPU Actors)

KDL

(from LPU Actors)

LEn

(from LPU Actors)

CAZ

(from LPU Actors)

KDL2

(from LPU Actors)

1. Reporting of LE()

2. Checking whether LE
is in the
routing

table
()

3. DCAttentionResponse()

4. Checking whether LE is in the routing table of a different

KDL()

5. DCAttentionRequest()

5. DCAttentionResponse()

6. High priority
a
larm ()

7. DCAttentionResponse()

8. DCAttentionRequestt()

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

25

z
90

If a new LE reports, CAZ will make a decision as regards the readout and the scope of read data.



4.3.1.2

LPU02: Installation of new KDL

Scope



reporting of KDL (new or after scheduled shutdown/failure) to SAK,



KDL agreeing the configuration with SAK.

Sequence dia
gram


Figure
9
. Sequence diagram for LPU02


1.

KDL reports to SAK. In the report, it provides its identification data.

2.

SAK notifies CAZ about KDL's reporting.

3.

SAK sends a response to KDL. In case of new concentrator, it sends the configuration
data.

4.3.1.3

LPU03: No communication with LE

Scope



deinstallation of LE,



emergency situations causing loss of connection to LE.

Sequence diagram


Figure
10
. Sequence diagram for LPU03



sd LPU02 Installation of new KDL

SAK

(from LPU Actors)

KDL

(from LPU Actors)

LE1

(from LPU Actors)

CAZ

(from LPU Actors)

1. DCGetParamResponse()

2. Info on reporting of KDL()

3. DCAttentionRequest()



sd LPU03 No communication with LE

SAK

(from LPU Actors)

KDL

(from LPU Actors)

LE1

(from LPU Actors)

CAZ

(from LPU Actors)

1. DCAttentionResponse()

2. Checking the LE status()

2. Checking the LE status()

3. DCAttentionRequest()

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

26

z
90


1.

KDL identifies LE as problematic (no
communication). Sends to SAK the notification about
that fact, stating the data of the problematic LE.

2.

SAK checks the LE status in CAZ (on the basis of data from SID).

3.

SAK sends to KDL the information concerning the problematic LE. LE could have been
switc
hed off, taken down, etc.


in such case KDL ends the attempts to initiate communication
with that LE.

CAZ makes a decision with regard to strategy for further communication.


4.3.1.4

LPU04: KDL Shutdown/Failure

Scope



Service (the following scenario is conditioned

on KDL having adequate functionality):

o

the fitter changes KDL's status to "under servicing" through a local interface,

o

a notification is sent to SAK about the fact that KDL's status has been changed to
"under servicing" which may trigger KDL to perform re
adout of all the data that have
not yet been read (see LPU11),

o

KDL's operating system is closed,

o

after the message of completion of the closing process (local), the disassembly or
servicing will take place,

o

after completion of service and restart, KDL will

inform SAK that it is active (see
LPU02).



Failure: An emergency situation, failure of the concentrator hardware preventing the
functioning of the operating system, KDL service which does not have the above
-
described
functionality, failure of the channel o
f communication with KDL;

o

failure of KDL or shutdown of the concentrator by the technician,

o

SAK makes an attempt to reinstate communication (parameter of time and number of
attempts),

o

SAK checks KDL's status in CAZ (on the basis of data from SID),

o

if there

is no information in CAZ about scheduled servicing of KDL, it will change
the channel to backup


provided that it is available; after the specified time, it will
report the failure to CAZ,

Sequence diagrams




sd LPU04 Shutdown / Failure of KDL


servicing mode

SAK

(from LPU Actors)

KDL

(from LPU Actors)

LE1

(from LPU Actors)

1. Servicing mode()

2. DCAttentionResponse()

3. DCAttentionRequest()

4. Shutdown()

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

27

z
90

Figure
11
. Sequence diagram for LPU04


servicing mode


1.

The fitter changes KDL's status to "under servicing" through a local interface. It waits for a
response from KDL confirming that the process of informing SAK about the planned
interruption has been completed.

2.

KDL informs SAK that there will

be interruption in communication.

3.

SAK confirms the receipt of this information.

4.

The fitter disassembles KDL or performs service tasks.



Figure
12
. Sequence diagram for LPU04


without servicing mode


1.

Failure of KDL occurs or it is switched off by the fitter.

2.

SAK ascertains lack of communication. Attempts to make a connection to KDL


unsuccessfully.

3.

SAK checks the KDL st
atus in CAZ (on the basis of data from SID).

4.

If there is no information in CAZ about the scheduled service and the backup channel of
communication with KDL has been determined, SAK will try to initiate a connection through
that channel.

5.

If attempts to make

a connection are unsuccessful, SAK will inform CAZ about situation
which has occurred.


4.3.1.5

LPU05: Update of LE's software

Scope



setting up the software image in KDL and issuing an instruction through SAK to KDL to
replace software in LE, specifying the momen
t of switching to new software,



transferring software to the meter, setting up the moment of switching to new software
version,



confirmation of execution.



sd LPU04 Shutdown / Failure of KDL


without servicing mode

SAK

(from LPU Actors)

KDL

(from LPU Actors)

LE1

(from LPU Actors)

CAZ

(from LPU Actors)

1. Failure or shutdown()

2. DCGetParamRequest()

3. Checking KDL status()

3. Checking KDL status()

4. DCGetParamRequest()

5. Sending information on the problem()

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

28

z
90

Sequence diagram


Figure
13
. Sequence diagram for LPU05


1.

SAK sends to KDL the software image for LE, specifying the time of update.

2.

KDL sends to SAK the confirmation of receipt of software image.

3.

KDL sends the software image to LE, specifying the time of
update. The following activities
are performed for all LEs to which the new software was sent.

4.

LE sends to KDL the confirmation of receipt of software image.

5.

KDL sends to SAK the confirmation of receipt of software image through individual LEs.

6.

In the
designated time, LE performs software update and notifies KDL about this fact, while at
the same time sends the identifier of the installed software version.

7.

KDL informs SAK about the fact that software has been updated in the individual LEs, stating
the i
dentifiers of the installed software versions.


4.3.1.6

LPU06: Update of KDL's software

Scope



setting up the software image in KDL and issuing an instruction through SAK to KDL to
replace software, specifying the moment of switching to new software,



confirmation o
f execution.

Sequence diagram



sd LPU05 LE software update

SAK

(from LPU Actors)

KDL

(from LPU
Actors)

LE1

(from LPU Actors)

LE2

(from LPU Actors)

LEn

(from LPU Actors)

1. DCMeterFirmwareRequest()

2. DCAttentionResponse()

3. Sending the software()

3. Sending the software ()

3. Sending the software ()

4. Software receipt

confirmation ()

4. Software receipt

confirmation ()

4. Software receipt

confirmation ()

5. DCMeterAttentionResponse()

6. Update confirmation()

6. Update confirmation ()

6. Update confirmation ()

7. DCMeterAttentionResponse()

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

29

z
90


Figure
14
. Sequence diagram for LPU06


1.

SAK sends the software image to KDL, specifying the time of update.

2.

KDL sends to SAK the confirmation of receipt of software image.

3.

KDL performs update of its software and works on the new software
starting from the
specified moment.

4.

KDL sends the identifier of the installed software version to SAK.






sd LPU06 KDL software update

SAK

(from LPU Actors)

KDL

(from LPU Actors)

LE1

(from LPU Actors)

1. DCFirmwareRequest()

2. DCAttentionResponse()

3. Software update()

4. DCGetParamResponse()

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

30

z
90

4.3.2

Configuration Category

The below diagram presents the Meter Use Cases in Configuration Category.




Figure
15
. LPU in Configuration Category


4.3.2.1

LPU07: LE configuration

Scope



Change of LE
configuration parameters:

o

calendar (zones),

o

limitation of power,

o

change of contactor status (switching it off, securing it),

o

synchronizing or setting the time

o

defining the moment of registering the data in profiles/archives,

o

defining the structure of
complex registers (profiles, archives),

o

displaying the message on the LE display,

o

sending the message to HAN,

o

other.





uc Configuration Category

LPU07
Configuration of

LE

LPU08 Confi gurati on of

KDL

LPU09 Defi ni ti on

of subscri pti on

LPU20

Synchroni zation /

change of LE ti me

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

31

z
90

Sequence diagram



Figure
16
. Sequence diagram for LPU07


1.

SAK sends to KDL the request to set specific parameters in LE. The request may contain the

moment as of which the new parameters are to go into effect.

2.

KDL generates the parameterization request for all LEs stated in the request sent by SAK.

3.

LE confirms the execution of the request (or its acceptance


if the moment as of which the
new paramete
rs are to go into effect has been set).

4.

After receiving confirmations from all LEs, KDL will confirm to SAK that the data have been
transferred.

5.

If the moment as of which the new parameters are to go into effect has been set, LE will
activate the new confi
guration at the moment defined in the request (the new data will begin to
prevail as at that moment).

Usually after LPU07, LPU13 "Readout of LE configuration" will be performed for the purpose of
verifying whether the new configuration has been successfull
y installed in LE. The decision as to
conducting the readout will be made by CAZ.


4.3.2.2

LPU08: KDL configuration

Scope



change

o

of maximum waiting time for responses from LE,

o

of concentrator time (forcing synchronization
of time
with
the
use of NTP),

o

of the
method of performing the readouts ("push" mode or "pull" mode),

o

of other concentrator parameters.

Synchronization of KDL's time with SAK's time will be carried out with use of NTP mechanisms. If
this protocol is not implemented in KDL, an alternative algor
ithm will be executed.




sd LPU07 LE configuration

SAK

(from LPU Actors)

KDL

(from LPU Actors)

LE1

(from LPU Actors)

LE2

(from LPU Actors)

LEn

(from LPU Actors)

1. DCMeterSetParamRequest()

2. Configuration change request()

2. Configuration change request ()

3. Request execution/acceptance confirmation()

3. Request execution/acceptance confirmation ()

4.
DCMeterAttentionResponse()

5. New configuration activation()

5. New configuration activation()

Document tit le: Communication Standard Between AMI Applicat ion and Metering Infrastructure

32

z
90

Sequence diagram


Figure
17
. Sequence diagram for LPU08


1.

SAK sends to KDL the request to set specific parameters. The request may contain the
moment as of which the new parameters are to go into effect.

2.

KDL confirms the execution of the request (or its ac
ceptance


if they are to go into effect as
of the specified moment).

3.

If the moment as of which the new parameters are to go into effect has been set: It will
activate the new configuration at the moment specified in KDL's request.

Usually after LPU08, LPU
11 "Readout of configurations and data from KDL" will be performed for
the purpose of verifying whether the change of configuration was successful.


4.3.2.3

LPU09: Definition of subscription

Subscription has the following basic attributes:



identifier,



scope of
delivered data,



frequency and schedule of data registration (from LE to KDL),



frequency and schedule of data delivery (from KDL to SAK),



obligation start time,



obligation end time.

Subscription may be assigned to one LE, many LEs (multicast) or to all LEs