Communication
Standard Between
AMI Application and
Metering Infrastructure
developed for ENERGA-Operator SA
Version: 0.03
Date: 2011-07-31
Contents
1
2
3
Glossary of terms and acronyms ..................................................................................................... 5
Introduction ..................................................................................................................................... 8
Concept for the communication standard in DSO ........................................................................... 9
3.1
Assumptions for the communication standard ........................................................................ 9
3.1.1
3.1.2
3.2
Overall concept of the communication standard ................................................................... 10
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
4
Categories, Identifiers and Statuses of Meter Use Cases ...................................................... 20
List of Meter Use Cases ........................................................................................................ 21
Analysis of Meter Use Cases ................................................................................................. 21
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
Installation Category ..................................................................................................... 23
Configuration Category ................................................................................................. 30
Readouts Category......................................................................................................... 34
Control Category ........................................................................................................... 38
Reporting Category ....................................................................................................... 43
DCSML communication protocol ................................................................................................. 45
5.1
5.2
Description of Messages........................................................................................................ 45
Protocol Grammar ................................................................................................................. 45
5.2.1
5.2.2
5.2.3
5.2.4
6
Area of communication between SAK and concentrators ............................................. 11
Area of communication between concentrators and meters .......................................... 11
Area of communication between SAK and meters ....................................................... 12
Traffic prioritization ...................................................................................................... 13
Digital signatures ........................................................................................................... 17
Concept of transport ...................................................................................................... 17
Meter Use Cases ............................................................................................................................ 20
4.1
4.2
4.3
5
General assumptions ........................................................................................................ 9
Technical assumptions..................................................................................................... 9
Basic definitions of SML data structures ...................................................................... 46
Basic structures of DCSML data ................................................................................... 53
DCSML Functions – associated with the operation of a concentrator .......................... 55
DCSML functions – associated with the operation of a meter ...................................... 57
Examples of queries and responses in DCSML (in APDU and source forms) ............................. 61
6.1
6.2
ASN.1 definition ................................................................................................................... 61
Examples ............................................................................................................................... 63
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
6.2.6
6.2.7
6.2.8
Example 1-1-1 ............................................................................................................... 63
Example 1-1-4 ............................................................................................................... 65
Example 1-5-1 ............................................................................................................... 67
Example 1-5-4 ............................................................................................................... 69
Example 5-1-1 ............................................................................................................... 71
Example 5-1-4 ............................................................................................................... 74
Example 5-5-1 ............................................................................................................... 79
Example 5-5-4 ............................................................................................................... 83
Document title: Communication Standard Between AMI Application and Metering Infrastructure
2 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 for 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 Category ................................................................................................. 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 title: Communication Standard Between AMI Application and Metering Infrastructure
3 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 notation............................................................................................ 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 APDU 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 title: Communication Standard Between AMI Application and Metering Infrastructure
4 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,
mixing 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 infrastructure.
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, broadcast). 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 meters
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 title: Communication Standard Between AMI Application and Metering Infrastructure
5 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 Network encompassing the devices
within the Intelligent Building infrastructure, equipped with remote
control and data providing functionalities (heating, air conditioning,
household appliances and radio/TV equipment). In addition, HAN
may be comprised of PCs and house terminals used for monitoring
electricity consumption and managing the devices and meters.
Metering Infrastructure
Technical infrastructure, including hardware and software, whose
purpose is to provide adequate communication between recipients of
electricity and DSO, including information on electricity
consumption. The Metering Infrastructure connects to the Application
System via the Intermediating Infrastructure. The Metering
Infrastructure will be comprised of power meters and concentrators as
well as other devices connected to them, including HAN devices and
meters of other utilities.
KDL
Metering Data Concentrator
KDLP
Metering Data Concentrator – Program.
LE
Electricity Meter.
LPU
Meter Use Case.
nN
Low voltage.
OBIS
Object Identification System – system of coding the COSEM model
objects.
OSI
Open System Interconnection. – standard defined by the ISO and
ITU-T organizations, describing the network communication
structure.
PKI
Public Key Infrastructure – structure of trust, based on confirmation
of authenticity with use of certificates issued by the hierarchy of
certification offices.
PLC
Power Line Communication/Carrier – communication technique
allowing to remotely send the data via the electricity cables.
PRIME
PoweRline Intelligent Metering Evolution – open specification
defining communication in the lowest layers of the communication
system after PLC, from the terminal devices (meters) to the data
concentrator located in the medium-voltage/low-voltage transformer
station.
SAK
Acquisition System.
SML
Smart Message Language – application layer protocol developed by
the MeKo project group, designated to support, among other things,
two-way data exchange with the electricity meters.
The MeKo project group is comprised of the following: Dr. Neuhaus
Document title: Communication Standard Between AMI Application and Metering Infrastructure
6 z 90
Term
Explanation
Telekommunikation GmbH, E.ON Mitte AG, E.ON Netz GmbH,
Emsycon GmbH, EnBW Vertriebs und Servicegesellschaft mbH,
Landis+Gyr GmbH, RWE Rhein-Ruhr Netzservice GmbH.
MV
Medium voltage.
SSH
Secure Shell – standard of communication protocols used in the
TCP/IP computer networks, in the client – server architecture. It is
used for connecting to the remote computer, and provides encryption
and allows authentication of the user by many methods.
S-FSK
Spread Frequency Shift Keying – one of the techniques for
transmitting the data through the PLC network.
TCP/IP
Transmission Control Protocol/Internet Protocol – set of transmission
(TCP) and network (IP) layer protocols providing a unified method of
sending the data in various types of networks.
TLS (Transport Layer Security) – extension of the SSL (Secure
Socket Layer) protocol, adopted as Internet standard, which aims at
providing confidentiality and integrity of data transmission and
ensuring authentication; it is based on asymmetric ciphers and
certificates of X.509 standard.
Web Services Resource Transfer – protocol based on the popular
WebServices technology used in case of data exchange between the
applications operating in the TCP/IP network, created under the
DSMR standard.
TLS/SSL
WS-RT
xDLMS
Extended DLMS – extension of the DLMS protocol to the
DLMS/COSEM standard defined by norm IEC 62056-53.
XML
Extensible Markup Language – it is a markup language used for
describing the data. It is the method of presenting the hierarchical
structure of nodes and their attributes in the form of a "flat" text file
with a precisely defined structure.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
7 z 90
2 Introduction
This document is an excerpt from the document entitled "Communication Standard Between 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.
This document presents:

use cases for communication 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
postulated
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 title: Communication Standard Between AMI Application and Metering Infrastructure
8 z 90
3 Concept for the communication standard in DSO
In this chapter we have presented 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 assumptions 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 devices 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 responses),
b. minimize network traffic between SAK and KDL (type broadcast and multicast
messages).
2. KDL is "non-transparent" 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 unified 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 inserted 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. ciphering,
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 title: Communication Standard Between AMI Application and Metering Infrastructure
9 z 90
7. We propose to use prioritization at the level of lower communication layers as well as the
application layer.
3.2 Overall concept of the communication standard
Communication standard should be reviewed in the following areas.
COSEM
OBJECTS
COSEM
OBJECTS
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.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
10 z 90
SAK - KDL
KDL - LE
KDLP - LE
COSEM Application
Layer
COSEM Application
Layer
COSEM Application
Layer
DCSML
DLMS
DLMS
Wrapper Layer
TLS
UDP
TCP
PN/EN 61334-4-32
UDP
TCP
IP
IP
(PLC SN, WiMax,
GPRS))
PRIME MAC
PLC OFDM
PLC OFDM
GPRS, …
PRIME PHY
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
functionalities 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 binary 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 communication 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 standard.

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 PRIME specification,
Document title: Communication Standard Between AMI Application and Metering Infrastructure
11 z 90
o
o
o

the standard does not breach patent rights of third parties,
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 data, 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),
it 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 provides 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 communication 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 as well as the group of those
electricity meters which will be queried 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 layer 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 other 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 quantity of meters. Moreover, there can be
Document title: Communication Standard Between AMI Application and Metering Infrastructure
12 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 broadly 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 attributes 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
emergency situations). [See Figure 6]
Document title: Communication Standard Between AMI Application and Metering Infrastructure
13 z 90
sd PULL
SAK
KDL
LE
Get data()
ack()
Get data()
Send data()
Send data()
ack + disconnect()
(from SAK Actors)
(from SAK Actors)
(from SAK Actors)
Figure 3: Diagram of the sequence – single communication session PULL
sd PULL PULL
SAK
KDL
LE
Get data()
ack + disconnect()
Get data()
Send data()
Get data()
Send data()
ack + disconnect()
(from SAK Actors)
(from SAK Actors)
(from SAK Actors)
Figure 4: Diagram of the sequence – two communication sessions PULL + PULL
Document title: Communication Standard Between AMI Application and Metering Infrastructure
14 z 90
sd PULL PUSH
SAK
KDL
LE
Get data()
ack + disconnect()
Get data()
Send data()
Send data()
ack + disconnect()
(from SAK Actors)
(from SAK Actors)
(from SAK Actors)
Figure 5: Diagram of the sequence – two communication sessions PULL + PUSH
sd PUSH
SAK
KDL
LE
ALARM()
ALARM()
ack + disconnect()
(from SAK Actors)
(from SAK Actors)
(from SAK Actors)
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
available, 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 for 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 related to communication with the individual meters should be
performed by KDL firstly.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
15 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, such
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 by 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 finalized. 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 accepting
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 QoS 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 enable 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 several levels, below
we would like to present the options of configuring the tasks:
No.
1.
2.
3.
4.
Performance of the task
PULL
PULL + PULL
PULL + PUSH
PUSH
Priority
YES
YES
YES
NO
QoS
YES
YES
YES
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 processing 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 title: Communication Standard Between AMI Application and Metering Infrastructure
16 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 lower 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. readout 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 higher 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 + results
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 signatures
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
I.
Concept of transport
Transport of data on the Acquisition Server – Concentrator path
The DCSML (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 queries 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 APDU 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 algorithm 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 title: Communication Standard Between AMI Application and Metering Infrastructure
17 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 against 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 AES
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 the 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 – Acquisition 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 used 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 important 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 their 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 approx. 60
thousand Concentrators, there exists the risk of occurrence of significant percentage of incorrect
Document title: Communication Standard Between AMI Application and Metering Infrastructure
18 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 the 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 fragment 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 same 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.
Details of network infrastructure management policy must be consistent with DSO's corporate policy
in that regard.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
19 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 Infrastructure.
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 should 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 Meter Use Cases
Code
Name
I
Installation
K
O
S
Configuration
Readout
Control
Z
Notification
Description
LPUs for installation and deinstallation of KDL and LE, exchanges,
software updates, etc.
LPUs related to configuration of KDL and LE.
LPUs for readouts of metering data.
LPUs requiring that requests controlling the devices' operation be
sent to LE and/or KDL.
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 existing 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 title: Communication Standard Between AMI Application and Metering Infrastructure
20 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 title: Communication Standard Between AMI Application and Metering Infrastructure
21 z 90
2. It has been assumed that, by principle, data will be transferred from KDL to SAK immediately
after their completion 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 from
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 subsequent 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 situation 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 exchanged data will depend on specific solutions
of the individual manufacturers as well as the results of further analytical and design work.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
22 z 90
4.3.1
Installation Category
The below diagram presents the Meter Use Cases in Installation Category.
uc Installation Category
LPU01 Installation
of new LE,
reporting of LE after
failure
LPU03 No
communication with LE
LPU05 Update
of LE software
LPU02 Installation
of new KDL
LPU04
Shutdown / Failure of
KDL
LPU06 Update
of KDL software
Figure 7. LPU in Installation Category
Document title: Communication Standard Between AMI Application and Metering Infrastructure
23 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
sd LPU01 Installation of new LE, reporting of LE after power failure
CAZ
SAK
KDL
KDL2
LEn
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 alarm ()
7. DCAttentionResponse()
8. DCAttentionRequestt()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
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 different 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.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
24 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 diagram
sd LPU02 Installation of new KDL
CAZ
SAK
KDL
LE1
(from LPU Actors)
(from LPU Actors)
1. DCGetParamResponse()
2. Info on reporting of KDL()
3. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
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
sd LPU03 No communication with LE
CAZ
SAK
KDL
LE1
(from LPU Actors)
(from LPU Actors)
1. DCAttentionResponse()
2. Checking the LE status()
2. Checking the LE status()
3. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
Figure 10. Sequence diagram for LPU03
Document title: Communication Standard Between AMI Application and Metering Infrastructure
25 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
switched 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 readout 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 of 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
KDL
LE1
1. Servicing mode()
2. DCAttentionResponse()
3. DCAttentionRequest()
4. Shutdown()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Document title: Communication Standard Between AMI Application and Metering Infrastructure
26 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.
sd LPU04 Shutdown / Failure of KDL – without servicing mode
CAZ
SAK
KDL
LE1
1. Failure or shutdown()
2. DCGetParamRequest()
3. Checking KDL status()
3. Checking KDL status()
4. DCGetParamRequest()
5. Sending information on the problem()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
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 status 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 moment of switching to new software,
 transferring software to the meter, setting up the moment of switching to new software
version,
 confirmation of execution.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
27 z 90
Sequence diagram
sd LPU05 LE software update
SAK
KDL
LE1
LE2
LEn
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()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors) (from LPU Actors)
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 identifiers 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 of execution.
Sequence diagram
Document title: Communication Standard Between AMI Application and Metering Infrastructure
28 z 90
sd LPU06 KDL software update
SAK
KDL
LE1
1. DCFirmwareRequest()
2. DCAttentionResponse()
3. Software update()
4. DCGetParamResponse()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
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.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
29 z 90
4.3.2 Configuration Category
The below diagram presents the Meter Use Cases in Configuration Category.
uc Configuration Category
LPU07 Configuration of
LE
LPU09 Definition
of subscription
LPU08 Configuration of
KDL
LPU20
Synchronization /
change of LE time
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.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
30 z 90
Sequence diagram
sd LPU07 LE configuration
SAK
KDL
LE1
LE2
LEn
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()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)(from LPU Actors)
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 parameters 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 configuration 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 successfully 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
o
o
o
of maximum waiting time for responses from LE,
of concentrator time (forcing synchronization of time with the use of NTP),
of the method of performing the readouts ("push" mode or "pull" mode),
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 algorithm will be executed.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
31 z 90
Sequence diagram
sd LPU08 KDL configuration
SAK
KDL
LE1
1. DCSetParamRequest()
2. DCAttentionResponse()
3. New data activation()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
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 acceptance – 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, LPU11 "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 (broadcast).
Scope
Includes:




creation of new subscription definition,
change of subscription definition,
deactivation of subscription,
removal of subscription.
Execution of actions defined by the subscription is covered by LPU12.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
32 z 90
Sequence diagram
sd LPU09 Subscription Definition
SAK
KDL
LE1
1. DCSubscribeRequest()
2. DAttentionResponse()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Figure 18. Sequence diagram for LPU09
1. New subscription is configured in SAK, and then proper definition is sent to KDL.
Configuration may consist in creating the new definition, change of definition's parameters
(e.g. LE lists for which that definition prevails), deactivation or permanent removal of the
definition.
2. Definition is configured in KDL. KDL sends the confirmation of subscription configuration to
SAK.
Execution of subscription is described in use case LPU12.
4.3.2.4 LPU20: LE time synchronization / change
Scope
 LE time synchronization
 setting the LE time
Sequence diagram
sd LPU20 LE time synchronization / change
CAZ
SAK
KDL
LE1
1. DCMeterSetParamRequest()
2. LE time readout()
2. LE time()
3. Calculation of departure of LE time from KDL time()
4. DCMeterAttentionResponse()
5. Info on departure greater than permitted ()
6. Setting the time()
7. Confirmation of setting the time()
8. DCMeterAttentionResponse()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Figure 19. Sequence diagram for LPU20
Document title: Communication Standard Between AMI Application and Metering Infrastructure
33 z 90
1. SAK initiates LE time synchronization / change.
2. KDL reads LE time.
3. KDL calculates difference between LE time and KDL time.
a. the difference is smaller or equal than the set permissible time difference (KDL
parameter). Go to item 4.
b. the time difference is greater than the set permissible time difference. Go to item 6.
4. KDL informs SAK about greater than permissible time difference.
5. SAK informs CAZ about greater than permissible time difference.
6. KDL sets the LE time.
7. LE confirms that the time has been set.
8. KDL sends the confirmation to SAK that the order of time synchronization / change has been
executed.
4.3.3 Readouts Category
The below diagram presents the map of Meter Use Cases in Readouts Category.
uc Readouts Category
LPU10 Readout
from LE registers
LPU11 Readout of data from
KDL
LPU14 Checking
connection with LE
LPU13 Readout
of LE configuration
LPU15 Checking
connection with KDL
Figure 20. LPU in Readouts Category
4.3.3.1 LPU10: Readout of data from LE
Scope
 Readout of metering data and non-metering data.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
34 z 90
Sequence diagrams
sd LPU10 Readout of LE registers - "push" mode
SAK
KDL
LE1
LE2
LEn
(from LPU Actors)
(from LPU Actors)
1. DCMeterGetDataRequest()
2. DCAttentionResponse()
3. Data request()
4. Sending the requested data()
3. Data request ()
4. Sending the requested data ()
5. DCMeterGetDataResponse()
6. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Figure 21. Sequence diagram for LPU10 – "push" mode
1.
2.
3.
4.
5.
6.
SAK requests that KDL gathers the contents of registers from LEs.
KDL confirms the receipt of the request.
KDL generates adequate request for the relevant LEs.
LEs deliver the relevant data to KDL.
KDL delivers the gathered data.
SAK confirms the receipt of data.
sd LPU10 Readout of LE registers - "pull" mode
SAK
KDL
LE1
LE2
LEn
(from LPU Actors)
(from LPU Actors)
1. DCMeterGetDataRequest()
2. DCAttentionResponse()
3. Data request ()
4. Sending the requested data ()
3. Data request ()
4. Sending the requested data ()
5. DCAttentionRequest()
6. DCMeterGetDataResponse()
7. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Figure 22. Sequence diagram for LPU10 – "pull" mode
Document title: Communication Standard Between AMI Application and Metering Infrastructure
35 z 90
1.
2.
3.
4.
5.
6.
7.
SAK requests that KDL gathers the contents of registers from LEs.
KDL confirms the receipt of the request.
KDL generates adequate request for the relevant LEs.
LEs deliver the relevant data to KDL.
SAK requests that the data gathered by KDL be delivered.
KDL delivers the gathered data.
SAK confirms the receipt of data.
4.3.3.2 LPU11: Readout of configurations and data from KDL
Scope
 sending from SAK to KDL the message with the request to send the specified data:
o of configuration,
o of event logs,
o of routing tables,
o of gathered meter data before the moment of their "normal" delivery, for example,
should it become necessary to switch off KDL (see LPU04)
 sending the requested data from KDL to SAK.
Sequence diagram
sd LPU11 Readout of data from KDL
SAK
KDL
LE1
1. DCGetParamRequest()
2. DCGetParamResponse+DCMeterGetDataResponse()
3. DCAttentionRequest+DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Figure 23. Sequence diagram for LPU011
1. SAK sends to KDL the message with the request to provide data.
2. KDL sends to SAK the response containing the relevant data.
3. SAK confirms the receipt of data.
4.3.3.3 LPU13: Readout of LE configuration
Scope
 Readout of LE configuration parameters:
o calendar (zones),
o limitation of power,
o contactor status (switched off, switched on, secured),
o time,
Document title: Communication Standard Between AMI Application and Metering Infrastructure
36 z 90

o defining the moments of registering the data in profiles/archives,
o defining the structure of complex registers (profiles, archives),
o other.
Readout of event log.
Sequence diagrams
sd LPU13 LE configuration readout - "push" mode
SAK
KDL
LE1
LE2
LEn
(from LPU Actors)
(from LPU Actors)
1. DCMeterGetParamRequest()
2. DCAttentionResponse()
3. Configuration request()
4. Sending the requested data ()
3. Configuration request ()
4. Sending the requested data ()
5. DCMeterGetParamResponse()
6. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Figure 24. Sequence diagram for LPU13 – "push" mode
1.
2.
3.
4.
5.
6.
SAK requests that KDL performs readout of data from LEs.
KDL confirms the receipt of the request.
KDL generates adequate request for the relevant LEs.
LEs deliver the relevant data to KDL.
KDL delivers the gathered data.
SAK confirms the receipt of data.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
37 z 90
sd LPU13 LE configuration readout - "pull" mode
SAK
KDL
LE1
LE2
LEn
(from LPU Actors)
(from LPU Actors)
1. DCMeterGetParamRequest()
2. DCAttentionResponse()
3. Configuration request ()
4. Sending the requested data ()
3. Configuration request ()
4. Sending the requested data ()
5. DCAttentionRequest()
6. DCMeterGeParamResponse()
7. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Figure 25. Sequence diagram for LPU13 – "pull" mode
1.
2.
3.
4.
5.
6.
7.
SAK requests that KDL performs readout of data from LEs.
KDL confirms the receipt of the request.
KDL generates adequate request for the relevant LEs.
LEs deliver the relevant data to KDL.
SAK requests that the data gathered by KDL be delivered.
KDL delivers the gathered data.
SAK confirms the receipt of data.
4.3.3.4 LPU14: Verification of connection with LE
Scope
 readout of serial number register from LE,
Sequence diagrams
Sequence diagram is given in the description of case LPU10.
4.3.3.5 LPU15: Verification of connection with KDL
Scope
 readout of identification number register from KDL,
Sequence diagram
Sequence diagram is given in the description of case LPU11.
4.3.4 Control Category
The below diagram presents the map of Meter Use Cases in Control Category.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
38 z 90
uc Control Category
LPU16 Direct
communication between SAK and LE
(transparent concentrator mode)
LPU12 Execution
of Subscription
LPU17 Restart KDL
Figure 26. LPU in Control Category
4.3.4.1 LPU12: Execution of subscription
Subscription is an order for cyclical performance of certain actions. They may involve the following:


delivery of specified data by LE to SAK,
changes of configuration in LE.
Scope
 cyclical execution of readouts from LE,
 cyclical execution of LE configuration changes.
The cyclical tasks resulting from definition of subscription are generated by KDL. They may be
performed in the "push" or "pull" mode.
Sequence diagrams
sd LPU12 Subscription readout in the "push" mode
SAK
KDL
LE1
LE2
LEn
1. Data readout request()
2. Sending the requested data ()
1. Data readout request ()
2. Sending the requested data ()
3. DCMeterGetDataResponse()
4. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors) (from LPU Actors)
Figure 27. Sequence diagram for LPU012 – readout in the "push" mode
1. On the basis of subscription definitions, KDL generates data readout requests and sends them
to LE.
2. LEs send the requested data.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
39 z 90
3. KDL sends the gathered data to SAK.
4. SAK confirms the receipt of data.
sd LPU12 Subscription readout in the "pull" mode
SAK
KDL
LE1
LE2
LEn
1. Data readout request ()
2. Sending the requested data ()
1. Data readout request ()
2. Sending the requested data ()
3. DCAttentionRequest()
4. DCMeterGetDataResponse()
5. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors) (from LPU Actors)
Figure 28. Sequence diagram for LPU012 – readout in the "pull" mode
1. On the basis of subscription definitions, KDL generates data readout requests and sends them
to LE.
2. LEs send the requested data.
3. SAK requests that the gathered data be delivered.
4. KDL sends the gathered data to SAK.
5. SAK confirms the receipt of data.
sd LPU12 LE subscription configuration change in the "push" mode
SAK
KDL
LE1
LE2
LEn
1. Configuration change request()
2. Configuration change confirmation()
1. Configuration change request ()
2. Configuration change confirmation ()
3. DCMeterAttentionResponse()
4. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors) (from LPU Actors)
Figure 29. Sequence diagram for LPU012 – change of data in the "push" mode
Document title: Communication Standard Between AMI Application and Metering Infrastructure
40 z 90
1. On the basis of subscription definitions, KDL generates configuration change requests and
sends them to LE.
2. LEs confirm configuration change.
3. KDL sends the confirmation for configuration change to SAK.
4. SAK confirms the receipt of confirmation (for the purpose of closing the logical transaction
initiated by KDL).
sd LPU12 LE subscription configuration change in the "pull" mode
SAK
KDL
LE1
LE2
LEn
1. Configuration change request ()
2. Configuration change confirmation ()
1. Configuration change request ()
2. Configuration change confirmation ()
3. DCAttentionRequest()
4. DCMeterAttentionResponse()
5. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors) (from LPU Actors)
Figure 30. Sequence diagram for LPU012 – readout in the "pull" mode
1. On the basis of subscription definitions, KDL generates configuration change requests and
sends them to LE.
2. LEs confirm configuration change.
3. SAK requests that KDL confirms confirmation changes in LEs.
4. KDL sends the confirmation for configuration change to SAK.
5. SAK confirms the receipt of confirmation (for the purpose of closing the logical transaction
initiated by KDL).
4.3.4.2 LPU16: Direct communication with LE (transparent concentrator mode)
One of the requirements of DCSML is that it would be possible to send the messages to LE in
transparent concentrator mode. This means that there must exist the possibility for SAK to formulate
an instruction in such form which will not be interpreted by KDL but it will be understandable to LE.
Such instruction is decapsulated by KDL and then it is sent to LE. And the other way around:
responses obtained from LE are encapsulated by KDL in DCSML and sent to SAK.
Scope
 SAK sends the message to KDL which may be addressed to one, many or all LEs,
 decapsulation of message by KDL and sending it to LEs,
 KDL gathers responses from LEs, encapsulates them and sends them to SAK.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
41 z 90
Sequence diagram
sd LPU16 Direct communication between SAK and LE (transparent concentrator mode)
SAK
KDL
LE1
LE2
LEn
1. DCMeterTransparentRequest()
2. DCAttentionResponse()
3. Decapsulation of DLMS from DCSML()
4. Sending DLMS()
5. Sending back the response in DLMS()
4. Sending DLMS()
5. Sending back the response in DLMS()
6. Capsulation of DLMS in DCSML()
7. DCMeterTransparentResponse()
8. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Figure 31: Sequence diagram for LPU016
1.
2.
3.
4.
5.
6.
7.
8.
SAK sends the instruction to KDL in the APDU DLMS form packaged in DCSML.
KDL confirms the receipt of the instruction.
KDL performs decapsulation from DCSML of the instruction formulated in APDU DLMS.
KDL sends the decapsulated instruction to LE.
LEs reply to KDL in the APDU DLMS form.
KDL performs encapsulation of the reply in DCSML
KDL sends the encapsulated responses in DCSML to SAK.
SAK confirms the receipt of data.
4.3.4.3 LPU17: Restart of KDL
Scope
 KDL restart forced by SAK.
Sequence diagram
Restart is performed upon SAK's initiative. Restart takes place through setting appropriate parameters
in KDL which will trigger restart immediately or on the specified moment.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
42 z 90
sd LPU17 KDL restart
SAK
KDL
LE1
1. DCSetParamRequest()
2. DCAttentionResponse()
3. Restart()
4. DCAttentionResponse()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Figure 32. Sequence diagram for LPU17
1.
2.
3.
4.
SAK sends to KDL the message with the request to perform restart.
KDL confirms the receipt of the message.
KDL restart occurs.
KDL reports to SAK that restart has been performed.
4.3.5 Reporting Category
The below diagram presents the map of Meter Use Cases in Reporting Category.
uc Reporting Category
LPU18 Reporting
of alarm by LE
LPU19 Reporting
of alarm by KDL
Figure 33. LPU in Reporting Category
4.3.5.1 LPU18: Reporting of alarm by LE
Scope
 reporting of alarm by LE
Document title: Communication Standard Between AMI Application and Metering Infrastructure
43 z 90
Sequence diagram
sd LPU18 Reporting of alarm by LE
SAK
KDL
LE1
1. Reporting of alarm ()
2. DCMeterAttentionResponse()
3. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Figure 34. Sequence diagram for LPU18
1. LE reports alarm to KDL.
2. KDL reports alarm from LE to SAK.
3. SAK confirms the receipt of alarm.
4.3.5.2 LPU19: Reporting of alarm by KDL
Scope
 reporting of alarm by KDL
Sequence diagram
sd LPU19 Reporting of alarm by KDL
SAK
KDL
LE1
1. DCAttentionResponse()
2. DCAttentionRequest()
(from LPU Actors)
(from LPU Actors)
(from LPU Actors)
Figure 35. Sequence diagram for LPU19
1. KDL reports alarm to SAK.
2. SAK confirms the receipt of alarm.
Document title: Communication Standard Between AMI Application and Metering Infrastructure
44 z 90
5 DCSML communication protocol
The DCSML communication protocol was developed as an extension of the SML protocol (language)
functionality. In order to ensure communication with data concentrators (KDL), a set of additional
features was defined to ensure cooperation of SAK with KDL.
DCSML is used for communication between SAK and KDL. Also, it is a medium enabling transport
of DLMS / COSEM protocol structures, which facilitates:

transmission of data read from COSEM objects in LE to SAK,

if necessary encapsulation of DLMS/COSEM commands at the SAK level, for KDL to
transmit them directly to LE (DCMeterTransparent command).
5.1 Description of Messages
Based on the analysis of commands and data provided, a list of DCSML messages was developed
which is presented in the table below.
Table 4. DCSML Message List
Message
DCAttentionRequest
DCAttentionResponse
DCFirmwareRequest
DCGetParamRequest
DCGetParamResponse
DCMeterAttentionResponse
DCMeterFirmwareRequest
DCMeterGetDataRequest
DCMeterGetDataResponse
DCMeterGetParamRequest
DCMeterGetParamResponse
DCMeterSetParamRequest
DCMeterTransparentRequest
DCMeterTransparentResponse
DCSetParamRequest
DCSubscribeRequest
Meaning
Transmission of information, request, etc. Typical application includes a
request to read collected data in the "pull" mode. Also confirmation of
information receipt.
Notification of an alarm, confirmation of data receipt or execution of request,
response to DCAttentionRequest.
Request to update software in KDL.
Request to read configuration and/or collected meter data from KDL.
Response with KDL configuration data.
Acknowledgement of data receipt or request execution by individual LEs.
Request to update software in LE.
Request to read data from LE.
Response with data read from LE.
Request to read configuration from LE.
Response with LE configuration data.
Request to change configuration of LE.
Request to send data to LE in the APDU DLMS format.
Response with LE data in the APDU DLMS format.
Request to change configuration of KDL.
Request to create, change, delete or deactivate a subscription definition.
The message list is given in Appendix 2 in the "DCSML" worksheet.
In the "LPU" worksheet, each individual LPU has been linked to DCSML messages that will be used
to execute them.
The "LPU <=> DCSML" worksheet presents the matrix of connections between LPU and DCSML
messages.
5.2 Grammar of the Protocol
Document title: Communication Standard Between AMI Application and Metering Infrastructure
45 z 90
Due to the requirement for concentrators to be capable of working with meters from different
manufacturers, it was assumed that the meters used will be compliant with the COSEM model. This
means that logical devices, where COSEM objects are defined, are modeled in a physical device. Each
object belongs to a certain interface class and is identified by OBIS code.
A DLMS / COSEM protocol is used to communicate with COSEM meters. It has been designed to
record and transmit all data identified with OBIS codes, that is all data recorded in electricity meters.
For this reason, implementation of the DCSML protocol enables the following operations of the
application layer:


Creating COSEM objects in LE based on interface classes defined in LE, removing those
objects.
Performing the following types of operations on COSEM objects:
o GET – get value of a COSEM object attribute, e.g. daily profile of values recorded
every 15 minutes, the actual voltage, etc.,
o PUT – set the value of a COSEM object attribute, such as metering tariffs, calendar
used, etc.,
o ACTION – run the method defined in a COSEM object.
Parameters and results of these operations are also encapsulated in DCSML messages to be passed
between KDL and SAK.
5.2.1
Basic definitions of SML data structures
The concept of grammar for the DCSML protocol syntax is based on the solutions used in the SML
protocol. DCSML is an extension of the SML protocol with additional functions. Functions of the
SML protocol can be used equally with functions of the DCSML protocol. Therefore, in the
description of grammar of the DCSML protocol we use the basic data structures (type) which are the
same as in the original SML protocol. This applies to the following range of definitions of basic SML
data structures:


















OctetString
Integer8
Integer16
Integer32
Integer64
Unsigned8
Unsigned16
Unsigned32
Unsigned64
Boolean
List of …
EndOfSmlMessage
SML_Time
SML_TimeStamp
SML_Value
SML_ValueEntry
SML_Unit
SML_Message
Document title: Communication Standard Between AMI Application and Metering Infrastructure
46 z 90










SML_TreePath
SML_Tree
List_of_SML_Tree
List_of_SML_ObjReqEntry
SML_ObjReqEntry
List_of_SML_ProfObjHeaderEntry
List_of_SML_ProfObjPeriodEntry
List_of_SML_ValueEntry
SML_ProfObjHeaderEntry
SML_ProfObjPeriodEntry
Description of grammar of the DCSML protocol is presented in the same notation as was used in the
description of SML (document: SML Smart Message Language Version1.03). The description uses the
following characteristics defining the method of proceeding and interpreting the structures of elements
in brackets:




CHOICE – means the possibility to choose one and only one element in brackets. The element
must have its own unique code - TL field defining the type of the element (all the basic data
types are assigned a unique TL code (TL-Field)
SEQUENCE – means that all the structure elements included in brackets are to be used,
SEQUENCE OF – means an unlimited list of repetitive elements in brackets,
OPTIONAL – means that the element specified by this characteristics does not have to be used
in the structure.
All the basic data types used in SML have a uniquely defined TL-Field. The size of a TL-Field is 1
byte (8 bits). Data type and data length expressed in terms of the number of bytes is encoded in this
field. In TL-Field, the 4 most significant bits encode data type, while the 4 least significant bits encode
information about the size of data in bytes. TL-Field is designed in such a way that, if the size of data
described by TL-field is greater than 14 bytes then the most significant bit is set to 1 and it means that
the next byte field after TL-Field carries additional information on data length. If additional bytes of
TL-Field are used then the 4 bits of the first byte which specify data field length should be moved to
the left by 4, while 4 bits from the next byte of the TL-Field should be added on the right. Thus, the
maximum data field length of 254 may be encoded in 2 bytes of the TL-Field.

Encoding TL-Field (first byte)
Table 5. Significance of bits in the first byte of the TL-Field
Bit index
MSB
b7
The next byte is the extended TL-Field
1
The next byte is the value of data
0
Encoding Octet String data type
X
Encoding Boolean data type
0
Encoding Integer data type
X
Encoding Unsigned data type
X
Encoding List of ... data type
X
The next byte allows you to define additional 1
data types – reserved
Reserved for the future
X
6
X
X
0
1
1
1
1
1
5
X
X
0
0
0
1
1
0
4
X
X
0
0
1
0
1
0
3
X
X
L
L
L
L
L
L
2
X
X
L
L
L
L
L
L
1
X
X
L
L
L
L
L
L
LSB
b0
X
X
L
L
L
L
L
L
0
0
1
L
L
L
L
Document title: Communication Standard Between AMI Application and Metering Infrastructure
47 z 90
Bit index
MSB
b7
6
X
0
X
0
Reserved for the future
Reserved for the future
X - bit without significance (any bit value)
L - data length bits (length in bytes)

5
1
1
4
0
1
3
L
L
2
L
L
1
L
L
LSB
b0
L
L
1
X
X
L
L
L
L
L
LSB
b0
X
X
L
L
L
L
L
TL-Field encoding (each subsequent byte)
Table 6. Significance of bits in subsequent bytes of the TL-Field
Bit index
The next byte is the extended TL-Field
The next byte is the value of data
4 bits used as data length
Reserved for the future
Reserved for the future
Reserved for the future
Reserved for the future
MSB
b7
1
0
X
X
X
X
X
6
X
X
0
0
0
0
1
5
X
X
0
0
1
1
X
4
X
X
0
1
0
1
X
3
X
X
L
L
L
L
L
2
X
X
L
L
L
L
L
5.2.1.1 OctetString
OctetString
{
TL-Field
data)
dataValue
::= SEQUENCE
0x0z
(‘z’
=
number
of
bytes
0xAA..0xNN
(0xAA – oldest byte,
0xNN – youngest byte)
of
}
5.2.1.2 Integer8
Integer8
{
TL-Field
dataValue
}
::= SEQUENCE
0x52
0xYY
5.2.1.3 Integer16
Integer16
{
TL-Field
dataValue
::= SEQUENCE
0x53
0xAA 0xBB
(0xAA – oldest byte,
0xBB – youngest byte,
Size: Big Endian)
}
5.2.1.4 Integer32
Integer32
{
TL-Field
dataValue
::= SEQUENCE
0x55
0xAA 0xBB
0xCC 0xDD
(0xAA – oldest byte,
Document title: Communication Standard Between AMI Application and Metering Infrastructure
48 z 90
0xDD – youngest byte,
Size: Big Endian)
}
5.2.1.5 Integer64
Integer64
{
TL-Field
dataValue
::= SEQUENCE
0x59
0xAA..0xHH
0xAA – oldest byte,
0xHH – youngest byte,
Size: Big Endian)
}
5.2.1.6 Unsigned8
Unsigned8
{
TL-Field
dataValue
}
::= SEQUENCE
0x62
0xYY
5.2.1.7 Unsigned16
Unsigned16
{
TL-Field
dataValue
::= SEQUENCE
0x63
0xAA 0xBB
(0xAA – oldest byte,
0xBB – youngest byte,
Size: Big Endian)
}
5.2.1.8 Unsigned32
Unsigned32
{
TL-Field
dataValue
::= SEQUENCE
0x65
0xAA 0xBB
0xCC 0xDD
(0xAA – oldest byte,
0xDD – youngest byte,
Size: Big Endian)
}
5.2.1.9 Unsigned64
Unsigned64
{
TL-Field
dataValue
::= SEQUENCE
0x59
0xAA..0xHH
0xAA – oldest byte,
0xHH – youngest byte,
Size: Big Endian)
}
5.2.1.10 Boolean
Boolean
{
TL-Field
dataValue
::= SEQUENCE
0x42
0xAA
(0x00 = ‘false’
other value = ‘true’)
Document title: Communication Standard Between AMI Application and Metering Infrastructure
49 z 90
}
5.2.1.11 List of …
List of…
{
TL-Field
}
::= SEQUENCE
0x7z
(‘z’ = number of elements)
::= 0x00
(0x00 = no TL-Field
= end)
5.2.1.12 EndOfSmlMessage
EndOfSmlMessage
5.2.1.13 SML_Time
SML_Time
{
secIndex
timestamp
::= CHOICE
0x01
0x02
Unsigned32
SML_Timestamp
}
secIndex
Time in seconds, counted number of seconds
timestamp
SML_Timestamp (in seconds)
5.2.1.14 SML_TimeStamp
SML_TimeStamp time is based on a second. SML_TimeStamp counted from time 01.01.1970
00:00:00 (reference time of UNIX systems).
SML_TimeStamp
::= Unsigned32
5.2.1.15 SML_Value
SML_Value
{
Boolean-Value
Byte-List
8-Bit-Integer
16-Bit-Integer
32-Bit-Integer
64-Bit-Integer
8-Bit-Unsigned
16-Bit-Unsigned
32-Bit-Unsigned
64-Bit-Unsigned
}
::= IMPLICIT CHOICE
Boolean
OctetString
Integer8
Integer16
Integer32
Integer64
Unsigned8
Unsigned16
Unsigned32
Unsigned64
5.2.1.16 SML_ValueEntry
SML_ValueEntry
{
value
valueSignature
}
::= SEQUENCE
SML_Value
SML_Signature
OPTIONAL
5.2.1.17 SML_Signature
Document title: Communication Standard Between AMI Application and Metering Infrastructure
50 z 90
Signature is used to set the profile signature, parameter or values. Signatures vary for different
individual system implementations.
SML_Signature
OctetString
5.2.1.18 SML_Unit
The table of numerical values assigned to respective physical units is provided in the documents
describing the DLMS (PN-EN 62056-62).
SML_Unit
::= Unsigned8
5.2.1.19 SML_Message
The basic structure of a SML message is used to send queries and responses in the communication
process using the SML protocol.
SML_Message
{
transactionID
groupID
abortOnError
messageBody
crc16
endOfSmlMsg
}
::= SEQUENCE
OctetString
Unsigned8
Unsigned8
SML_MessageBody
Unsigned16
EndOfSmlMsg
5.2.1.20 SML_TreePath
SML_TreePath
{
Path_Entry
}
::= SEQUENCE OF
OctetString
5.2.1.21 SML_Tree
SML_Tree allows you to obtain various information about parameters. Because of the tree structure
and the child_list field, we can get information about:



a single parameter,
a parameter with a list of dependent parameters,
a parameter with a list of dependent parameter trees,
Parameter name is an appropriate OBIS code.
SML_Tree
{
parameterName
parameterValue
child_list
}
::= SEQUENCE
OctetString
SML_ProcParValue
List_of_SML_Tree
OPTIONAL
OPTIONAL
5.2.1.22 List_of_SML_Tree
List_of_SML_Tree
{
tree_Entry
::= SEQUENCE OF
SML_Tree
Document title: Communication Standard Between AMI Application and Metering Infrastructure
51 z 90
}
5.2.1.23 List_of_SML_ObjReqEntry
List_of_SML_ObjReqEntry
{
object_List_Entry
}
::= SEQUENCE OF
SML_ObjReqEntry
5.2.1.24 SML_ObjReqEntry
Name of the parameter whose value is to be read (OBIS code).
SML_ObjReqEntry
::= OctetString
5.2.1.25 List_of_SML_ProfObjHeaderEntry
List_of_SML_ProfObjHeaderEntry
{
Header_List_Entry
}
::= SEQUENCE OF
SML_ProfObjHeaderEntry
5.2.1.26 List_of_SML_ProfObjPeriodEntry
List_of_SML_ProfObjPeriodEntry
{
Period_List_Entry
}
::= SEQUENCE OF
SML_ProfObjPeriodEntry
5.2.1.27 List_of_SML_ValueEntry
List_of_SML_ValueEntry
{
Value_List_Entry
}
::= SEQUENCE OF
SML_ValueEntry
5.2.1.28 SML_ProfObjHeaderEntry
The structure describes properties of a single parameter whose value or valueset we read. Information
included in SML_ProfObjHeaderEntry are static for a specified parameter named objname.
SML_ProfObjHeaderEntry
{
objName
unit
scaler
}
::= SEQUENCE
OctetString
SML_Unit
Integer8
5.2.1.29 SML_ProfObjPeriodEntry
The structure is used to return a set of values of parameters specified in the list
List_of_SML_ProfObjHeaderEntry in association with a specified value of LE time when the
data was measured. Data consistency signature may be assigned to a set of LE data from a specified
time.
SML_ProfObjPeriodEntry
{
valTime
status
value_List
periodSignature
}
::= SEQUENCE
SML_Time
Unsigned64
List_of_SML_ValueEntry
SML_Signature
Document title: Communication Standard Between AMI Application and Metering Infrastructure
OPTIONAL
52 z 90
5.2.1.30 SML_MessageBody
Definition of the SML_MessageBody syntax has been extended to include additional message
structure types. The definition of SML_MessageBody retains the previous types of structures defined
in SML (IDs from 0x00000100 to 0x0000FF01).
SML_MessageBody
::= CHOICE
{
OpenRequest
[0x00000100]
OpenResponse
[0x00000101]
CloseRequest
[0x00000200]
CloseResponse
[0x00000201]
GetProfilePackRequest
[0x00000300]
GetProfilePackResponse
[0x00000301]
GetProfileListRequest
[0x00000400]
GetProfileListResponse
[0x00000401]
GetProcParameterRequest
[0x00000500]
GetProcParameterResponse [0x00000501]
SetProcParameterRequest
[0x00000600]
SetProcParameterResponse [0x00000601]
AttentionResponse
[0x0000FF01]
DCFirmwareRequest
[0x10000300]
DCGetParamRequest
[0x10000400]
DCGetParamResponse
[0x10000401]
DCSetParamRequest
[0x10000500]
DCSubscribeRequest
[0x10000600]
DCAttentionRequest
[0x10000700]
DCAttentionResponse
[0x10000701]
DCMeterGetDataRequest
[0x10000800]
DCMeterGetDataResponse
[0x10000801]
DCMeterGetParamRequest
[0x10000900]
DCMeterGetParamResponse
[0x10000901]
DCMeterSetParamRequest
[0x10001000]
DCMeterTransparentRequest [0x10001100]
DCMeterTransparentResponse[0x10001101]
DCMeterFirmwareRequest
[0x10001200]
DCMeterAttentionResponse [0x10001301]
}
SML_PublicOpen.Req
SML_PublicOpen.Res
SML_PublicClose.Req
SML_PublicClose.Res
SML_GetProfilePack.Req
SML_GetProfilePack.Res
SML_GetProfileList.Req
SML_GetProfileList.Res
SML_GetProcParameter.Req
SML_GetProcParameter.Res
SML_SetProcParameter.Req
SML_SetProcParameter.Res
SML_Attention.Res
DCFirmware.Req
DCGetParam.Req
DCGetParam.Res
DCSetParam.Req
DCSubscribe.Req
DCAttention.Req
DCAttention.Res
DCMeterGetData.Req
DCMeterGetData.Res
DCMeterGetParam.Req
DCMeterGetParam.Res
DCMeterSetParam.Req
DCMeterTransparent.Req
DCMeterTransparent.Res
DCMeterFirmware.Req
DCMeterAttention.Res
5.2.2 Basic structures of DCSML data
The basic structure of DCSML data with fundamental grammar structures of the SML protocol form
the basis describing all the grammatical structures of DCSML queries and responses.
5.2.2.1 List_of_DCSML_ServerID
Structure of the data server ID list (LE).
List_of_DCSML_ServerID
{
serverID
{
serverID
::= SEQUENCE OF
OctetString
Data server ID (LE).
Document title: Communication Standard Between AMI Application and Metering Infrastructure
53 z 90
5.2.2.2 DCSML_ServerIDData
Set of data returned for a particular LE
DCSML_ServerIDData
{
serverID
header_List
period_List
}
serverID
::= SEQUENCE
Data server ID (LE).
header_List
List of headers describing a parameter (standard SML structure)
period_List
List of parameter values (standard SML structure)
OctetString
List_of_SML_ProfObjHeaderEntry
List_of_SML_ProfObjPeriodEntry
5.2.2.3 List_of_DCSML_ServerIDData
List of structures DCSML_ServerIDData.
List_of_DCSML_ServerIDData
{
serverIDAnswers
}
::= SEQUENCE OF
DCSML_ServerIDData
5.2.2.4 DCSML_ServerIDParams
Set of information required to record specific parameters from a specified meter.
DCSML_ServerIDParams
{
serverID
parameterTree
}
serverID
::= SEQUENCE
Data server ID (LE).
parameterTree
Tree of LE parameters with their values
OctetString
SML_Tree
5.2.2.5 List_of_DCSML_ServerIDParams
List of structures DCSML_ServerIDParams.
List_of_DCSML_ServerIDParams
::= SEQUENCE OF
{
serverParams
DCSML_ServerIDParams
}
5.2.2.6 DCSML_MeterAttention
Attention message from a single LE.
DCSML_MeterAttention
{
serverID
attentionNo
attentionDetails
}
::= SEQUENCE
OctetString
OctetString
SML_Tree
Document title: Communication Standard Between AMI Application and Metering Infrastructure
OPTIONAL
54 z 90
serverID
Data server ID (LE).
attentionNo
Code of message transmitted by that message.
attentionDetails
Structure enabling the transfer of additional attributes that are required
in a given case.
5.2.2.7 List_of_DCSML_MeterAttention
List of messages DCSML_MeterAttention for a specified group of (multiple) LEs.
List_of_DCSML_MeterAttention
{
meterStatus
}
::= SEQUENCE OF
DCSML_MeterAttention
5.2.2.8 DCSML_CycleTime
DCSML_ReadCycleTime
{
::= CHOICE
cycle
dayofmonth
0x01
0x02
SML Time
Unsigned8
}
5.2.2.9 DCSML_IndexTime
DCSML_IndexTime
{
::= CHOICE
time
index
0x01
0x02
SML Time
Unsigned16
}
5.2.3
DCSML Functions – associated with the operation of a concentrator
5.2.3.1 DCFirmware
DCFirmware.Req
{
priority
startTime
rawData
}
::= SEQUENCE
Unsigned8
SML_Time
Octet String
priority
Task priority.
startTime
Date when KDL is to reload the firmware.
rawData
Raw data – package of data containing firmware for KDL.
5.2.3.2 DCGetParam
DCGetParam.Req
{
::= SEQUENCE
Document title: Communication Standard Between AMI Application and Metering Infrastructure
55 z 90
priority
parameterTreePath
Unsigned8
SML_TreePath
}
DCGetParam.Res
{
parameterTreePath
parameterTree
}
priority
Task priority.
parameterTreePath
KDL parameter tree.
parameterTree
Parameter tree with parameter values.
::= SEQUENCE
SML_TreePath
SML_Tree
5.2.3.3 DCSetParam
DCSetParam.Req
{
priority
function
startTime
parameterTreePath
parameterTree
}
::= SEQUENCE
Unsigned8
Unsigned8
SML_Time
SML_TreePath
SML_Tree
OPTIONAL
priority
Task priority.
function
startTime
Code specifying the actions to be performed: e.g. creation and
configuration of a new object, modification of parameter values,
object removal (bit encoding, which means that it is several
commands can be made with a single command).
Date indicating the time when KDL should change the settings.
parameterTreePath
IDs of KDL parameters to be set.
parameterTree
Values of KDL parameters to be set.
5.2.3.4 DCSubscribe
DCSubscribe.Req
{
priority
listserverID
subscribeID
function
beginTime
endTime
readCycleTime
sendCycleTime
dataTreePath
dataTree
}
priority
::= SEQUENCE
Unsigned8
List_of_DCSML_ServerID
Octet String
Unsigned8
SML_Time
SML_Time
DCSML_CycleTime
DCSML_CycleTime
SML_TreePath
SML_Tree
OPTIONAL
OPTIONAL
OPTIONAL
OPTIONAL
OPTIONAL
Task priority
Document title: Communication Standard Between AMI Application and Metering Infrastructure
56 z 90
listserverID
subscribeID
Function
List of data servers (LE), for which subscription is to be created,
changed, deactivated or removed.
Subscription ID.
dataTreePath
Code indicating the actions to be performed on the definition of the
subscription.
Beginning time of the subscription period (commencement of
subscription); if the parameter is not stated then the concentrator then
the concentrator should begin subscription when the order is received.
End time of the subscription period (end of subscription); if the
parameter is not stated then the concentrator then the concentrator
should continue subscription until it is canceled or deactivated.
Parameter to be entered: subscription cycle (time interval in minutes or
a specific day of the month).
Parameter to be entered: collected data sending cycle (time interval in
minutes or a specific day of the month). If the parameter is not stated
then data will be sent immediately after they are collected.
IDs of configured LE parameters or subscribed data.
dataTree
Values of LE parameters to be set in subscription.
beginTime
endTime
readCycleTime
SendCycleTime
5.2.3.5 DCAttention
DCAttention.Req
{
priority
attentionNo
attentionDetails
}
::= SEQUENCE
DCAttention.Res
{
priority
attentionNo
attentionDetails
}
priority
Task priority.
::= SEQUENCE
Unsigned8
OctetString
SML_Tree
Unsigned8
OctetString
SML_Tree
OPTIONAL
OPTIONAL
attentionNo
Code of message transmitted by that DCAttention message.
attentionDetails
Structure enabling the transfer of additional attributes that are required
in a given case.
5.2.4
DCSML functions – associated with the operation of a meter
5.2.4.1 DCMeterGetData
DCMeterGetData.Req
{
priority
subscribeID
listserverID
beginindextime
::= SEQUENCE
Unsigned8
Octet String
List_of_DCSML_ServerID
DCSML_IndexTime
Document title: Communication Standard Between AMI Application and Metering Infrastructure
OPTIONAL
57 z 90
endindextime
parameterTreePath
DCSML_IndexTime
SML_TreePath
OPTIONAL
}
DCMeterGetData.Res
{
subscribeID
parameterTreePath
listserverIDData
}
priority
Task priority.
subscribeID
Subscription iD (optional parameter).
listserverID
List of data servers (LE).
beginindextime
Beginning time of the queried period or initial data index.
endindextime
End time of the queried period or final data index.
parameterTreePath
LE parameter tree.
listserverIDData
List of responses with data from servers (LE).
::= SEQUENCE
Octet String
SML_TreePath
List_of_DCSML_ServerIDData
OPTIONAL
5.2.4.2 DCMeterGetParam
DCMeterGetParam.Req
::= SEQUENCE
{
priority
Unsigned8
listserverID
List_of_DCSML_ServerID
parameterTreePath
SML_TreePath
}
DCMeterGetParam.Res
::= SEQUENCE
{
parameterTreePath
SML_TreePath
listserverIDParams
List_of_DCSML_ServerIDParams
}
listserverID
List of data servers (LE).
parameterTreePath
LE parameter tree.
listserverIDParams
List of responses with parameters from servers (LE).
5.2.4.3 DCMeterSetParam
DCMeterSetParam.Req
{
priority
function
startTime
parameterTreePath
listserverParams
}
::= SEQUENCE
Unsigned8
Unsigned8
SML_Time
OPTIONAL
SML_TreePath
List_of_DCSML_ServerIDParams
priority
Task priority.
function
Code specifying the actions to be performed: e.g. creation and
configuration of a new COSEM object, modification of parameter
Document title: Communication Standard Between AMI Application and Metering Infrastructure
58 z 90
parameterTreePath
values, COSEM object removal; action call (bit encoding, which means
that it is several commands can be made with a single command).
Date when LEs are to change the settings. If the parameter is not set
parameter switching occurs immediately.
LE parameter tree.
listserverParams
List of LEs with the list of parameters read from LE.
startTime
5.2.4.4 DCMeterTransparent
DCMeterTransparent.Req
{
::= SEQUENCE
priority
serverID
rawData
Unsigned8
Octet String
Octet String
}
DCMeterTransparent.Res
{
serverID
rawData
}
priority
Task priority.
::= SEQUENCE
Octet String
Octet String
serverID
Data server ID (LE).
rawData
Raw data – package of data to be sent to LE (or a response from LE) in
the APDU DLMS format.
5.2.4.5 DCMeterFirmware
DCMeterFirmware.Req
{
priority
listserverID
startTime
rawData
}
::= SEQUENCE
Unsigned8
List_of_DCSML_ServerID
SML_Time
Octet String
priority
Task priority.
listserverID
List of data servers (LE).
startTime
Date specifying when LE is to reload the firmware.
rawData
Raw data – package of data containing firmware for LE.
meterList
List of the structure describing the LE firmware replacement status.
5.2.4.6 DCMeterAttentionResponse
DCMeterAttention.Res
{
attentionID
}
::= SEQUENCE
List_of_DCSML_MeterAttention
Document title: Communication Standard Between AMI Application and Metering Infrastructure
59 z 90
attentionID
List of messages from multiple LE meters
Document title: Communication Standard Between AMI Application and Metering Infrastructure
60 z 90
6 Examples of queries and responses in DCSML (in APDU and
source forms)
This chapter presents sample test data used in the tests and the resulting APDU. All the examples
pertain to the DCSML language.
The APDU examples presented in this appendix were generated using a tool written in Java. The tool
works in such a way that, based on a definition in ASN.1, objects for individual APDUs are created in
the application and populated with data. Then a file with APDU is generated. The tool based on a
generally available freeware library is described in document P.1.4., item 7.4.
The APDUs presented below were generated for 1 and 5 meters in the following situations (x meaning
the number of meters):
1. Query for a single value and its reading (hereinafter denoted as x-1-1).
2. Query for a profile with a single value (a column) and a reading of a 15-minute hourly profile
(4 readings recorded every 15 minutes) (hereinafter denoted as x-1-4).
3. Query for 5 values and their reading (hereinafter denoted as x-5-1).
4. Query for a profile with a 5 values (columns) and a reading of a 15-minute hourly profile (4
readings recorded every 15 minutes) (hereinafter denoted as x-5-4).
The document contains the following examples:
1. Contents of the ASN.1 definition file which was used to generate the examples included in
this document.
2. Documentation of the cases listed above for 1 and 5 meters.
a. APDU queries in a hexadecimal form and, for easier analysis, in a parenthesis form.
b. APDU responses in a hexadecimal and parenthesis form.
c. For easier analysis in the parenthesis form, the numbers (time and data) were recoded
to a hexadecimal form.
It should be noted that the tools used offer encoding to a standard BER format. The SML standard
used slightly optimized BER encoding – where possible, Type and Length are encoded in a single
byte. This offers potentially additional possibilities to reduce the size of the APDU file.
6.1 ASN.1 definition
Below you will find the definition of grammar used to generate the examples provided underneath.
The definition is given in the ASN.1 notation
DCSMLTest DEFINITIONS AUTOMATIC TAGS ::= BEGIN
INTEGER8
UNSIGNED8
UNSIGNED16
UNSIGNED32
UNSIGNED64
::=
::=
::=
::=
::=
INTEGER (-128..127)
INTEGER (0..255)
INTEGER (0..65535)
INTEGER (0..4294967295)
UNSIGNED32
SMLPublicOpen-Req
{
clientId
serverId
}
::= SEQUENCE
OCTET STRING,
OCTET STRING OPTIONAL
Document title: Communication Standard Between AMI Application and Metering Infrastructure
61 z 90
SMLPublicOpen-Res
{
clientId
serverId
}
::= SEQUENCE
DCMeterGetData-Req
{
listserverID
subscribeID
questionID
answerID
beginTime
endTime
parameterTreePath
}
::= SEQUENCE
DCMeterGetData-Res
{
subscribeID
questionID
answerID
parameterTreePath
listserverIDAnswers
}
::= SEQUENCE
SMLPublicClose-Req
{
globalSignature
}
::= SEQUENCE
SMLPublicClose-Res
{
globalSignature
}
::= SEQUENCE
SMLTreePath
::= SEQUENCE OF OCTET STRING
ListOfSMLHeader
::= SEQUENCE OF SMLHeaderEntry
ListOfSMLPeriod
::= SEQUENCE OF SMLProfObjPeriodEntry
SMLProfObjPeriodEntry
::= SEQUENCE
OCTET STRING,
OCTET STRING OPTIONAL
List-of-DCSML-ServerID,
OCTET STRING OPTIONAL,
UNSIGNED32,
UNSIGNED16,
UNSIGNED32 OPTIONAL,
UNSIGNED32 OPTIONAL,
SMLTreePath
OCTET STRING OPTIONAL,
UNSIGNED32,
UNSIGNED16,
SMLTreePath,
List-of-DCSML-ServerIDAnswers
SMLSignature OPTIONAL
SMLSignature OPTIONAL
{
valTime
status
valueList
UNSIGNED32,
UNSIGNED64,
ListOfSMLValueEntry
}
ListOfSMLValueEntry
::= SEQUENCE OF UNSIGNED16
SMLHeaderEntry
{
objName
unit
scaler
}
::= SEQUENCE
SMLSignature
::= OCTET STRING
List-of-DCSML-ServerID
::= SEQUENCE OF OCTET STRING
OCTET STRING,
INTEGER8,
INTEGER8
List-of-DCSML-ServerIDAnswers ::= SEQUENCE OF DCSML-ServerIDAnswers
DCSML-ServerIDAnswers
{
serverID
::= SEQUENCE
OCTET STRING,
Document title: Communication Standard Between AMI Application and Metering Infrastructure
62 z 90
header-List
period-List
SEQUENCE OF SMLHeaderEntry,
SEQUENCE OF SMLProfObjPeriodEntry
}
Figure 36: Definition of grammar in ASN.1 notation
6.2 Examples
6.2.1
Example 1-1-1
6.2.1.1 Query
offset
00000000
00000010
00000020
00000030
00000040
00000050
0
30
34
54
45
35
A3
1
24
34
4B
52
E6
83
2
80
35
44
2D
83
A6
3
10
35
54
52
02
07
4
43
81
57
56
55
04
5 6 7 8 9 10 11 12 13 14
4C 49 45 4E 54 2D 5A 33 44 57
10 53 45 52 56 45 52 2D 5A 55
42 30 33 A0 12 04 10 53 45 52
4C 47 35 39 55 31 34 82 04 0F
31 84 04 4D F0 9F FF 85 04 4D
05 31 2E 38 2E 30 30 00 00 00
Figure 37: Response 1-1-4 in the APDU form
15
59
31
56
89
F0
00
ascii
0$€.CLIENT-Z3DWY
4455•.SERVER-ZU1
TKDTWB03 ...SERV
ER-RVLG59U14‚..‰
5ćƒ.U1„.Mđź˙….Mđ
Łƒ¦...1.8.00....
The figure above shows the contents of the generated APDU in a hexadecimal and a character form.
BER encoding has been applied, more precisely: encoding implemented in a generally available
"ASN.1 to Java Compiler" tool by ASNLab.
A description of the contents of that APDU follows; accuracy according to data that could be
identified:
30
24
80
10
43 to 35
81
10
30
33
A0
12
04
10
53
82
04
0F
83
02
55
84
04
4D
85
04
4D
A6
07
04
to 34
to E6
31
to FF
to 83
SEQUENCE SMLPublicOpen-Req
number of bytes in SEQUENCE (36)
unidentified
number of bytes in clientId (16)
clientId (CLIENT-Z3DWY4455)
unidentified
number of bytes in serverId (16) (SERVER-ZU1TKDTWB03)
SEQUENCE DCMeterGetData-Req
number of bytes in SEQUENCE (51)
SEQUENCE OF listserverID
number of bytes in SEQUENCE OF (18)
unidentified
number of bytes of the first (and in this case the last)
element of listserverID (16)
first element of listserverID (SERVER-RVLG59U14)
unidentified
number of bytes in questionID (4)
questionID (260650470)
unidentified
number of bytes in answerID (2)
answerID (21809)
unidentified
number of bytes in beginTime (4)
beginTime (1307615231)
unidentified
number of bytes in endTime (4)
endTime (1307616131)
SEQUENCE OF parameterTreePath
number of bytes in SEQUENCE OF (7)
unidentified
Document title: Communication Standard Between AMI Application and Metering Infrastructure
63 z 90
05
number of bytes of the first (and in this case the last)
element of parameterTreePath (5)
OBIS code (1.8.0)
SEQUENCE SMLPublicClose-Req
number of bytes in SEQUENCE (0)
end of data
supplementation to the multiple of 4 bytes
31 to 30
30
00
00
00 00 00
It should be stressed again that in the case of DCSML a slightly more efficient APDU encoding will
be used, applied to APDU in the SML language.
SMLPublicOpen_Req {
CLIENT-Z3DWY4455,
SERVER-ZU1TKDTWB,
}
DCMeterGetData_Req {
listserverID {
SERVER-RVLG59U14,
}
260650470 [HEX: 0F 89 35 E6],
21809 [HEX: 55 31],
1307615231 [HEX: 4D F0 9F FF] (Thu Jun 09 12:27:11 CEST 2011),
1307616131 [HEX: 4D F0 A3 83] (Thu Jun 09 12:42:11 CEST 2011),
parameterTreePath {
1.8.0,
}
}
SMLPublicClose_Req {
}
Figure 38: Query 1-1-1 in ASN.1 notation
6.2.1.2 Response
offset
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
0
30
34
54
4E
10
34
01
04
1
24
34
4B
97
53
A1
01
02
2
80
35
44
A3
45
0F
A2
02
3
10
35
54
07
52
30
11
6B
4
43
81
57
04
56
0D
30
0B
5 6 7 8 9 10 11 12 13 14
4C 49 45 4E 54 2D 5A 33 44 57
10 53 45 52 56 45 52 2D 5A 55
42 30 4D 81 04 50 29 4B 35 82
05 31 2E 38 2E 30 A4 38 30 36
45 52 2D 52 56 4C 47 35 39 55
80 05 31 2E 38 2E 30 81 01 05
0F 80 04 4D F0 9F FF 81 01 08
30 00 00 00 00 00 00 00 00 00
Figure 39: Response 1-1-1 in the APDU form
15
59
31
02
80
31
82
A2
00
ascii
0$€.CLIENT-Z3DWY
4455•.SERVER-ZU1
TKDTWB0M•.P)K5‚.
N—Ł...1.8.0¤806€
.SERVER-RVLG59U1
4ˇ.0.€.1.8.0•..‚
..˘.0.€.Mđź˙•..˘
...k.0..........
SMLPublicOpen_Res {
CLIENT-Z3DWY4455,
SERVER-ZU1TKDTWB,
}
DCMeterGetData_Res {
1344883509 [HEX: 50 29 4B 35],
20119 [HEX: 4E 97],
parameterTreePath {
1.8.0,
}
DCSML_ServerIDAnswers {
SERVER-RVLG59U14,
{
Document title: Communication Standard Between AMI Application and Metering Infrastructure
64 z 90
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307615231 [HEX: 4D F0 9F FF] (Thu Jun 09 12:27:11 CEST
2011),
8,
{
27403 [HEX: 6B 0B],
}
}
}
}
}
SMLPublicClose_Res {
}
Figure 40: Response 1-1-1 in ASN.1 notation
6.2.2
Example 1-1-4
6.2.2.1 Query
offset
00000000
00000010
00000020
00000030
00000040
00000050
0
30
49
39
45
A6
B3
1
24
45
34
52
88
DF
2
80
56
49
2D
83
A6
3
10
42
32
55
02
07
4
43
81
36
4D
17
04
5 6 7 8 9 10 11 12 13 14
4C 49 45 4E 54 2D 38 5A 4A 31
10 53 45 52 56 45 52 2D 43 4F
45 30 33 A0 12 04 10 53 45 52
36 30 4A 4D 59 44 34 82 04 5B
C3 84 04 4D F0 A5 CF 85 04 4D
05 31 2E 38 2E 30 30 00 00 00
Figure 41: Response 1-1-4 in the APDU form
15
34
47
56
25
F0
00
ascii
0$€.CLIENT-8ZJ14
IEVB•.SERVER-COG
94I26E03 ...SERV
ER-UM60JMYD4‚.[%
¦ˆƒ..Ă„.MđĄĎ….Mđ
łß¦...1.8.00....
SMLPublicOpen_Req {
CLIENT-8ZJ14IEVB,
SERVER-COG94I26E,
}
DCMeterGetData_Req {
listserverID {
SERVER-UM60JMYD4,
}
1529194120 [HEX: 5B 25 A6 88],
6083 [HEX: 17 C3],
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST 2011),
1307620319 [HEX: 4D F0 B3 DF] (Thu Jun 09 13:51:59 CEST 2011),
parameterTreePath {
1.8.0,
}
}
SMLPublicClose_Req {
}
Figure 42: Query 1-1-4 in ASN.1 notation
6.2.2.2 Response
offset
0
1
2
3
4
5
6
7
8
9
10 11 12 13
14
15
ascii
00000000
00000010
00000020
00000030
30
49
39
02
24
45
34
65
80
56
49
9A
10
42
32
A3
43
81
36
07
4C
10
45
04
49
53
30
05
45
45
81
31
4E
52
82
2E
54
56
81
38
2D
45
04
2E
31
4F
C4
30
34
47
82
6B
0$€.CLIENT-8ZJ14
IEVB•.SERVER-COG
94I26E0•‚•.IHUÄ‚
.ešŁ...1.8.0¤m0k
38
52
49
30
5A
2D
48
A4
4A
43
55
6D
Document title: Communication Standard Between AMI Application and Metering Infrastructure
65 z 90
00000040
00000050
00000060
00000070
00000080
00000090
000000A0
80
44
82
A2
01
81
B0
10
34
01
05
08
01
5B
53
A1
01
02
A2
08
81
45
0F
A2
03
04
A2
01
52
30
46
00
02
05
08
56 45 52 2D 55 4D 36 30 4A 4D
0D 80 05 31 2E 38 2E 30 81 01
30 10 80 04 4D F0 A5 CF 81 01
D6 28 30 0F 80 04 4D F0 A9 53
02 2B CA 30 10 80 04 4D F0 MOD
02 03 00 9D 8F 30 0F 80 04 4D
A2 04 02 02 59 8B 30 00 00 00
Figure 43: Response 1-1-4 in the APDU form
59
05
08
81
D7
F0
00
€.SERVER-UM60JMY
D4ˇ.0.€.1.8.0•..
‚..˘F0.€.MđĄĎ•..
˘....Ö(0.€.Mđ©S•
..˘...+Ę0.€.Mđ¬×
•..˘....ťŹ0.€.Mđ
°[•..˘...Y‹0....
SMLPublicOpen_Res {
CLIENT-8ZJ14IEVB,
SERVER-COG94I26E,
}
DCMeterGetData_Res {
1229477316 [HEX: 49 48 55 C4],
26010 [HEX: 65 9A],
parameterTreePath {
1.8.0,
}
DCSML_ServerIDAnswers {
SERVER-UM60JMYD4,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59
2011),
8,
{
54824 [HEX: D6 28],
}
}
SMLProfObjPeriodEntry {
1307617619 [HEX: 4D F0 A9 53] (Thu Jun 09 1:06:59 PM
2011),
8,
{
11210 [HEX: 2B CA],
}
}
SMLProfObjPeriodEntry {
1307618519 [HEX: 4D F0 AC D7] (Thu Jun 09 13:21:59
2011),
8,
{
40335 [HEX: 9D 8F],
}
}
SMLProfObjPeriodEntry {
1307619419 [HEX: 4D F0 B0 5B] (Thu Jun 09 1:36:59 PM
2011),
8,
{
22923 [HEX: 59 8B],
}
}
}
Document title: Communication Standard Between AMI Application and Metering Infrastructure
CEST
CEST
CEST
CEST
66 z 90
}
}
SMLPublicClose_Res {
}
Figure 44: Response 1-1-4 in ASN.1 notation
6.2.3
Example 1-5-1
6.2.3.1 Query
offset
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
0
30
4E
4C
45
57
F0
38
30
1
24
33
44
52
5C
A9
2E
04
2
80
5A
53
2D
83
53
30
05
3
10
50
54
47
03
A6
04
37
4
43
81
48
54
00
23
05
2E
5 6 7 8 9 10 11 12 13 14
4C 49 45 4E 54 2D 45 4B 4C 44
10 53 45 52 56 45 52 2D 4F 4B
54 30 50 A0 12 04 10 53 45 52
45 35 31 4C 34 42 32 82 04 5D
9A F6 84 04 4D F0 A5 CF 85 04
04 05 31 2E 38 2E 30 04 05 32
35 2E 38 2E 30 04 05 36 2E 38
38 2E 30 30 00 00 00 00 00 00
Figure 45: Response 1-5-4 in the APDU form
15
46
53
56
0B
4D
2E
2E
00
ascii
0$€.CLIENT-EKLDF
N3ZP•.SERVER-OKS
LDSTHT0P ...SERV
ER-GTE51L4B2‚.].
W\ƒ..šö„.MđĄĎ….M
đ©S¦#..1.8.0..2.
8.0..5.8.0..6.8.
0..7.8.00.......
SMLPublicOpen_Req {
CLIENT-EKLDFN3ZP,
SERVER-OKSLDSTHT,
}
DCMeterGetData_Req {
listserverID {
SERVER-GTE51L4B2,
}
1561024348 [HEX: 5D 0B 57 5C],
39670 [HEX: 9A F6],
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST 2011),
1307617619 [HEX: 4D F0 A9 53] (Thu Jun 09 1:06:59 PM CEST 2011),
parameterTreePath {
1.8.0,
2.8.0,
5.8.0,
6.8.0,
7.8.0,
}
}
SMLPublicClose_Req {
}
Figure 46: Query 1-5-1 in ASN.1 notation
6.2.3.2 Response
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
30
4E
4C
03
2E
2E
10
32
24
33
44
00
38
30
53
A1
80
5A
53
98
2E
04
45
4B
10
50
54
63
30
05
52
30
43
81
48
A3
04
37
56
0D
4C
10
54
23
05
2E
45
80
49
53
30
04
35
38
52
05
45
45
81
05
2E
2E
2D
31
4E
52
BA
31
38
30
47
2E
54
56
81
2E
2E
A4
54
38
2D
45
04
38
30
81
45
2E
45
52
7C
2E
04
87
35
30
4B
2D
ED
30
05
30
31
81
4C
4F
10
04
36
81
4C
01
44
4B
F9
05
2E
84
34
05
46
53
82
32
38
80
42
82
0$€.CLIENT-EKLDF
N3ZP•.SERVER-OKS
LDSTHT0•ş•.|í.ů‚
..˜cŁ#..1.8.0..2
.8.0..5.8.0..6.8
.0..7.8.0¤•‡0•„€
.SERVER-GTE51L4B
2ˇK0.€.1.8.0•..‚
Document title: Communication Standard Between AMI Application and Metering Infrastructure
67 z 90
00000080
00000090
000000A0
000000B0
000000C0
000000D0
000000E0
01
01
30
0D
30
46
00
01
30
0D
80
21
02
D9
30
0D
80
05
80
02
D2
0D
80
05
37
04
50
30
80
05
36
2E
4D
D1
00
05 32 2E 38 2E 30 81 01 07 82
35 2E 38 2E 30 81 01 08 82 01
2E 38 2E 30 81 01 04 82 01 01
38 2E 30 81 01 01 82 01 01 A2
F0 A5 CF 81 01 08 A2 16 02 02
02 03 00 BE F1 02 02 0A 2F 02
00 00 00 00 00 00 00 00 00 00
Figure 47: Response 1-5-1 in the APDU form
01
01
30
23
55
03
00
..0.€.2.8.0•..‚.
.0.€.5.8.0•..‚..
0.€.6.8.0•..‚..0
.€.7.8.0•..‚..˘#
0!€.MđĄĎ•..˘...U
F..PŃ...ľń.../..
.ŮŇ0............
SMLPublicOpen_Res {
CLIENT-EKLDFN3ZP,
SERVER-OKSLDSTHT,
}
DCMeterGetData_Res {
2095911161 [HEX: 7C ED 10 F9],
39011 [HEX: 98 63],
parameterTreePath {
1.8.0,
2.8.0,
5.8.0,
6.8.0,
7.8.0,
}
DCSML_ServerIDAnswers {
SERVER-GTE51L4B2,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
SMLHeaderEntry { 2.8.0, 7, 1 }
SMLHeaderEntry { 5.8.0, 8, 1 }
SMLHeaderEntry { 6.8.0, 4, 1 }
SMLHeaderEntry { 7.8.0, 1, 1 }
}
{
SMLProfObjPeriodEntry {
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST
2011),
8,
{
21830 [HEX: 55 46],
20689 [HEX: 50 D1],
48881 [HEX: BE F1],
2607
[HEX: 0A 2F],
55762 [HEX: D9 D2],
}
}
}
}
}
SMLPublicClose_Res {
}
Figure 48: Response 1-5-1 in ASN.1 notation
Document title: Communication Standard Between AMI Application and Metering Infrastructure
68 z 90
6.2.4
Example 1-5-4
6.2.4.1 Query
offset
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
0
30
4E
4A
45
E8
B3
2E
04
1
24
38
49
52
FF
DF
30
05
2
80
48
56
2D
83
A6
04
37
3
10
34
32
39
02
23
05
2E
4
43
81
44
49
5E
04
35
38
5 6 7 8 9 10 11 12 13 14
4C 49 45 4E 54 2D 56 34 56 41
10 53 45 52 56 45 52 2D 38 41
33 30 4F A0 12 04 10 53 45 52
31 53 44 41 44 33 53 82 04 52
E9 84 04 4D F0 A5 CF 85 04 4D
05 31 2E 38 2E 30 04 05 32 2E
2E 38 2E 30 04 05 36 2E 38 2E
2E 30 30 00 00 00 00 00 00 00
Figure 49: Response 1-5-4 in the APDU form
15
35
32
56
F7
F0
38
30
00
ascii
0$€.CLIENT-V4VA5
N8H4•.SERVER-8A2
JIV2D30O ...SERV
ER-9I1SDAD3S‚.R÷
č˙ƒ.^é„.MđĄĎ….Mđ
łß¦#..1.8.0..2.8
.0..5.8.0..6.8.0
..7.8.00........
SMLPublicOpen_Req {
CLIENT-V4VA5N8H4,
SERVER-8A2JIV2D3,
}
DCMeterGetData_Req {
listserverID {
SERVER-9I1SDAD3S,
}
1391978751 [HEX: 52 F7 E8 FF],
24297 [HEX: 5E E9],
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST 2011),
1307620319 [HEX: 4D F0 B3 DF] (Thu Jun 09 13:51:59 CEST 2011),
parameterTreePath {
1.8.0,
2.8.0,
5.8.0,
6.8.0,
7.8.0,
}
}
SMLPublicClose_Req {
}
Figure 50: Query 1-5-4 in ASN.1 notation
Document title: Communication Standard Between AMI Application and Metering Infrastructure
69 z 90
6.2.4.2 Response
offset
0
1
2
3
4
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000A0
000000B0
000000C0
000000D0
000000E0
000000F0
00000100
00000110
00000120
00000130
00000140
00000150
30
4E
4A
82
2E
2E
10
53
01
01
30
0D
8F
17
51
A2
02
MOD
02
4D
26
30
24
38
49
02
38
30
53
A1
01
30
0D
80
30
61
02
18
03
D7
4A
F0
7E
00
80
48
56
02
2E
04
45
4B
30
0D
80
05
22
02
02
02
00
81
65
B0
02
00
10
34
32
0E
30
05
52
30
0D
80
05
37
80
03
10
03
99
01
02
5B
03
00
43
81
44
A3
04
37
56
0D
80
05
36
2E
04
00
33
00
C8
08
03
81
00
00
5
6
7
8
9
10 11 12 13 14 15
4C 49 45 4E 54 2D 56 34 56 41
10 53 45 52 56 45 52 2D 38 41
33 30 82 01 26 81 04 12 96 6D
23 04 05 31 2E 38 2E 30 04 05
05 35 2E 38 2E 30 04 05 36 2E
2E 38 2E 30 A4 81 F4 30 81 F1
45 52 2D 39 49 31 53 44 41 44
80 05 31 2E 38 2E 30 81 01 05
05 32 2E 38 2E 30 81 01 07 82
35 2E 38 2E 30 81 01 08 82 01
2E 38 2E 30 81 01 04 82 01 01
38 2E 30 81 01 01 82 01 01 A2
4D F0 A5 CF 81 01 08 A2 17 02
83 A0 02 03 00 8C 43 02 03 00
30 23 80 04 4D F0 A9 53 81 01
CD E3 02 02 04 92 02 03 00 94
02 03 00 9B BC 30 20 80 04 4D
A2 15 02 02 1F 1D 02 02 2A 0C
00 88 7D 02 02 48 D3 30 22 80
01 08 A2 17 02 03 00 C3 09 02
E4 38 02 03 00 A3 71 02 02 58
00 00 00 00 00 00 00 00 00 00
Figure 51: Response 1-5-4 in the APDU form
SMLPublicOpen_Res {
CLIENT-V4VA5N8H4,
SERVER-8A2JIV2D3,
}
DCMeterGetData_Res {
311848279 [HEX: 12 96 6D 57],
526 [HEX: 02 0E],
parameterTreePath {
1.8.0,
2.8.0,
5.8.0,
6.8.0,
7.8.0,
}
DCSML_ServerIDAnswers {
SERVER-9I1SDAD3S,
{
SMLHeaderEntry { 1.8.0,
SMLHeaderEntry { 2.8.0,
SMLHeaderEntry { 5.8.0,
SMLHeaderEntry { 6.8.0,
SMLHeaderEntry { 7.8.0,
}
{
SMLProfObjPeriodEntry {
1307616719 [HEX:
2011),
8,
{
5,
7,
8,
4,
1,
1
1
1
1
1
35
32
57
32
38
80
33
82
01
01
30
81
02
B3
08
CD
F0
02
04
02
7B
00
ascii
0$€.CLIENT-V4VA5
N8H4•.SERVER-8A2
JIV2D30‚.&•..–mW
‚...Ł#..1.8.0..2
.8.0..5.8.0..6.8
.0..7.8.0¤•ô0•ń€
.SERVER-9I1SDAD3
SˇK0.€.1.8.0•..‚
..0.€.2.8.0•..‚.
.0.€.5.8.0•..‚..
0.€.6.8.0•..‚..0
.€.7.8.0•..‚..˘•
Ź0"€.MđĄĎ•..˘...
.a...ƒ ...ŚC...ł
Q...30#€.Mđ©S•..
˘....Üă...’...”Ü
...™Č...›Ľ0 €.Mđ
¬×•..˘.......*..
.Je...ˆ}..HÓ0"€.
Mđ°[•..˘....Ă...
&~...ä8...Łq..X{
0...............
}
}
}
}
}
4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST
Document title: Communication Standard Between AMI Application and Metering Infrastructure
70 z 90
5985
33696
35907
45905
4147
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
17
83
8C
B3
10
61],
A0],
43],
51],
33],
}
}
SMLProfObjPeriodEntry {
1307617619 [HEX: 4D F0 A9 53] (Thu Jun 09 1:06:59 PM CEST
2011),
8,
{
56547
1170
38108
39368
39868
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
DC
04
94
99
9B
E3],
92],
DC],
C8],
BC],
}
}
SMLProfObjPeriodEntry {
1307618519 [HEX: 4D F0 AC D7] (Thu Jun 09 13:21:59 CEST
2011),
8,
{
7965
10764
19045
34941
18643
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
1F
2A
4A
88
48
1D],
0C],
65],
7D],
D3],
}
}
SMLProfObjPeriodEntry {
1307619419 [HEX: 4D F0 B0 5B] (Thu Jun 09 1:36:59 PM CEST
2011),
8,
{
49929
9854
58424
41841
22651
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
C3
26
E4
A3
58
09],
7E],
38],
71],
7B],
}
}
}
}
}
SMLPublicClose_Res {
}
Figure 52: Response 1-5-4 in ASN.1 notation
6.2.5
Example 5-1-1
6.2.5.1 Query
offset
0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15
00000000
00000010
00000020
00000030
30
5A
4F
45
24
5A
35
52
80
4C
37
2D
10
52
35
31
43
81
43
30
4C
10
52
32
49
53
30
46
45
45
7C
58
4E
52
A0
57
54
56
5A
4F
2D
45
04
5A
4C
52
10
53
4A
2D
53
04
32
4D
45
10
54
56
52
53
59
48
56
45
ascii
0$€.CLIENT-LJ2TY
ZZLR•.SERVER-MVH
O575CR0| Z..SERV
ER-102FXWOZS..SE
Document title: Communication Standard Between AMI Application and Metering Infrastructure
71 z 90
00000040
00000050
00000060
00000070
00000080
00000090
000000A0
52
53
04
38
31
04
2E
56
45
10
39
46
4D
38
45
52
53
04
43
F0
2E
52
56
45
10
36
A5
30
2D
45
52
53
82
CF
30
35 33 32 55 56 55 51 32 51 04
52 2D 30 51 33 59 41 59 36 4F
56 45 52 2D 49 47 4D 49 4A 4A
45 52 56 45 52 2D 42 4B 45 43
04 25 93 B7 52 83 03 00 D5 4C
85 04 4D F0 A9 53 A6 07 04 05
00 00 00 00 00 00 00 00 00 00
Figure 53: Response 5-1-4 in the APDU form
10
33
45
52
84
31
00
RVER-532UVUQ2Q..
SERVER-0Q3YAY6O3
..SERVER-IGMIJJE
89..SERVER-BKECR
1FC6‚.%“·Rƒ..ŐL„
.MđĄĎ….Mđ©S¦...1
.8.00...........
SMLPublicOpen_Req {
CLIENT-LJ2TYZZLR,
SERVER-MVHO575CR,
}
DCMeterGetData_Req {
listserverID {
SERVER-102FXWOZS,
SERVER-532UVUQ2Q,
SERVER-0Q3YAY6O3,
SERVER-IGMIJJE89,
SERVER-BKECR1FC6,
}
630437714 [HEX: 25 93 B7 52],
54604 [HEX: D5 4C],
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST 2011),
1307617619 [HEX: 4D F0 A9 53] (Thu Jun 09 1:06:59 PM CEST 2011),
parameterTreePath {
1.8.0,
}
}
SMLPublicClose_Req {
}
Figure 54: Query 5-1-1 in ASN.1 notation
6.2.5.2 Response
offset
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000A0
000000B0
000000C0
000000D0
000000E0
000000F0
00000100
00000110
00000120
00000130
0
30
5A
4F
82
01
46
30
CF
45
0F
A2
03
51
38
F0
10
39
01
04
42
1
24
5A
35
03
1C
58
81
81
52
30
12
00
33
2E
A5
53
A1
01
02
4B
2
80
4C
37
00
30
57
01
01
56
0D
30
98
59
30
CF
45
0F
A2
02
45
3
10
52
35
C2
37
4F
05
08
45
80
10
0E
41
81
81
52
30
11
58
43
4
43
81
43
29
80
5A
82
A2
52
05
80
30
59
01
01
56
0D
30
6D
52
5
4C
10
52
A3
10
53
01
05
2D
31
04
37
36
05
08
45
80
0F
30
31
6
49
53
30
07
53
A1
01
02
35
2E
4D
80
4F
82
A2
52
05
80
37
46
7
45
45
82
04
45
0F
A2
03
33
38
F0
10
33
01
05
2D
31
04
80
43
8
4E
52
01
05
52
30
12
00
32
2E
A5
53
A1
01
02
49
2E
4D
10
36
9
54
56
34
31
56
0D
30
CD
55
30
CF
45
0F
A2
03
47
38
F0
53
A1
10
2D
45
81
2E
45
80
10
79
56
81
81
52
30
12
00
4D
2E
A5
45
0F
11
4C
52
04
38
52
05
80
30
55
01
01
56
0D
30
F8
49
30
CF
52
30
12
4A
2D
14
2E
2D
31
04
37
51
05
08
45
80
10
A2
4A
81
81
56
0D
13
32
4D
7F
30
31
2E
4D
80
32
82
A2
52
05
80
30
4A
01
01
45
80
14
54
56
04
A4
30
38
F0
10
51
01
05
2D
31
04
36
45
05
08
52
05
15
59
48
A6
82
32
2E
A5
53
A1
01
02
30
2E
4D
80
38
82
A2
2D
31
ascii
0$€.CLIENT-LJ2TY
ZZLR•.SERVER-MVH
O575CR0‚.4•..•.¦
‚..Â)Ł...1.8.0¤‚
..07€.SERVER-102
FXWOZSˇ.0.€.1.8.
0•..‚..˘.0.€.MđĄ
Ď•..˘....Üy07€.S
ERVER-532UVUQ2Qˇ
.0.€.1.8.0•..‚..
˘.0.€.MđĄĎ•..˘..
..˜.07€.SERVER-0
Q3YAY6O3ˇ.0.€.1.
8.0•..‚..˘.0.€.M
đĄĎ•..˘....ř˘06€
.SERVER-IGMIJJE8
9ˇ.0.€.1.8.0•..‚
..˘.0.€.MđĄĎ•..˘
...Xm07€.SERVERBKECR1FC6ˇ.0.€.1
Document title: Communication Standard Between AMI Application and Metering Infrastructure
72 z 90
00000140 2E 38 2E 30 81 01 05 82 01 01 A2 12 30 10 80 04 .8.0•..‚..˘.0.€.
00000150 4D F0 A5 CF 81 01 08 A2 05 02 03 00 86 D9 30 00 MđĄĎ•..˘....†Ů0.
Figure 55: Response 5-1-1 in the APDU form
SMLPublicOpen_Res {
CLIENT-LJ2TYZZLR,
SERVER-MVHO575CR,
}
DCMeterGetData_Res {
343868582 [HEX: 14 7F 04 A6],
49705 [HEX: C2 29],
parameterTreePath {
1.8.0,
}
DCSML_ServerIDAnswers {
SERVER-102FXWOZS,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST
2011),
8,
{
56441 [HEX: DC 79],
}
}
}
DCSML_ServerIDAnswers {
SERVER-532UVUQ2Q,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST
2011),
8,
{
38926 [HEX: 98 0E],
}
}
}
DCSML_ServerIDAnswers {
SERVER-0Q3YAY6O3,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST
2011),
8,
{
63650 [HEX: F8 A2],
}
}
Document title: Communication Standard Between AMI Application and Metering Infrastructure
73 z 90
}
DCSML_ServerIDAnswers {
SERVER-IGMIJJE89,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST
2011),
8,
{
22637 [HEX: 58 6D],
}
}
}
DCSML_ServerIDAnswers {
SERVER-BKECR1FC6,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST
2011),
8,
{
34521 [HEX: 86 D9],
}
}
}
}
}
SMLPublicClose_Res {
}
Figure 56: Response 5-1-1 in ASN.1 notation
6.2.6
Example 5-1-4
6.2.6.1 Query
offset
0
1
2
3
4
5
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000A0
30
5A
4F
45
52
53
04
38
31
04
2E
24
5A
35
52
56
45
10
39
46
4D
38
80
4C
37
2D
45
52
53
04
43
F0
2E
10
52
35
31
52
56
45
10
36
A5
30
43
81
43
30
2D
45
52
53
82
CF
30
4C 49 45 4E 54 2D 4C 4A 32 54
10 53 45 52 56 45 52 2D 4D 56
52 30 7C A0 5A 04 10 53 45 52
32 46 58 57 4F 5A 53 04 10 53
35 33 32 55 56 55 51 32 51 04
52 2D 30 51 33 59 41 59 36 4F
56 45 52 2D 49 47 4D 49 4A 4A
45 52 56 45 52 2D 42 4B 45 43
04 25 93 B7 52 83 03 00 D5 4C
85 04 4D F0 A9 53 A6 07 04 05
00 00 00 00 00 00 00 00 00 00
Figure 57: Response 5-1-4 in the APDU form
6
7
8
9
10 11 12 13 14 15
59
48
56
45
10
33
45
52
84
31
00
ascii
0$€.CLIENT-LJ2TY
ZZLR•.SERVER-MVH
O575CR0| Z..SERV
ER-102FXWOZS..SE
RVER-532UVUQ2Q..
SERVER-0Q3YAY6O3
..SERVER-IGMIJJE
89..SERVER-BKECR
1FC6‚.%“·Rƒ..ŐL„
.MđĄĎ….Mđ©S¦...1
.8.00...........
Document title: Communication Standard Between AMI Application and Metering Infrastructure
74 z 90
SMLPublicOpen_Req {
CLIENT-LJ2TYZZLR,
SERVER-MVHO575CR,
}
DCMeterGetData_Req {
listserverID {
SERVER-102FXWOZS,
SERVER-532UVUQ2Q,
SERVER-0Q3YAY6O3,
SERVER-IGMIJJE89,
SERVER-BKECR1FC6,
}
630437714 [HEX: 25 93 B7 52],
54604 [HEX: D5 4C],
1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST 2011),
1307617619 [HEX: 4D F0 A9 53] (Thu Jun 09 1:06:59 PM CEST 2011),
parameterTreePath {
1.8.0,
}
}
SMLPublicClose_Req {
}
Figure 58: Query 5-1-4 in ASN.1 notation
6.2.6.2 Response
offset
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000A0
000000B0
000000C0
000000D0
000000E0
000000F0
00000100
00000110
00000120
00000130
00000140
00000150
0
30
5A
4F
82
01
46
30
CF
45
0F
A2
03
51
38
F0
10
39
01
04
42
2E
4D
1
24
5A
35
03
1C
58
81
81
52
30
12
00
33
2E
A5
53
A1
01
02
4B
38
F0
2
80
4C
37
00
30
57
01
01
56
0D
30
98
59
30
CF
45
0F
A2
02
45
2E
A5
3
10
52
35
C2
37
4F
05
08
45
80
10
0E
41
81
81
52
30
11
58
43
30
CF
4
43
81
43
29
80
5A
82
A2
52
05
80
30
59
01
01
56
0D
30
6D
52
81
81
5 6 7 8 9 10 11 12 13 14
4C 49 45 4E 54 2D 4C 4A 32 54
10 53 45 52 56 45 52 2D 4D 56
52 30 82 01 34 81 04 14 7F 04
A3 07 04 05 31 2E 38 2E 30 A4
10 53 45 52 56 45 52 2D 31 30
53 A1 0F 30 0D 80 05 31 2E 38
01 01 A2 12 30 10 80 04 4D F0
05 02 03 00 CD 79 30 37 80 10
2D 35 33 32 55 56 55 51 32 51
31 2E 38 2E 30 81 01 05 82 01
04 4D F0 A5 CF 81 01 08 A2 05
37 80 10 53 45 52 56 45 52 2D
36 4F 33 A1 0F 30 0D 80 05 31
05 82 01 01 A2 12 30 10 80 04
08 A2 05 02 03 00 F8 A2 30 36
45 52 2D 49 47 4D 49 4A 4A 45
80 05 31 2E 38 2E 30 81 01 05
0F 80 04 4D F0 A5 CF 81 01 08
30 37 80 10 53 45 52 56 45 52
31 46 43 36 A1 0F 30 0D 80 05
01 05 82 01 01 A2 12 30 10 80
01 08 A2 05 02 03 00 86 D9 30
Figure 59: Response 5-1-4 in the APDU form
15
59
48
A6
82
32
2E
A5
53
A1
01
02
30
2E
4D
80
38
82
A2
2D
31
04
00
ascii
0$€.CLIENT-LJ2TY
ZZLR•.SERVER-MVH
O575CR0‚.4•..•.¦
‚..Â)Ł...1.8.0¤‚
..07€.SERVER-102
FXWOZSˇ.0.€.1.8.
0•..‚..˘.0.€.MđĄ
Ď•..˘....Üy07€.S
ERVER-532UVUQ2Qˇ
.0.€.1.8.0•..‚..
˘.0.€.MđĄĎ•..˘..
..˜.07€.SERVER-0
Q3YAY6O3ˇ.0.€.1.
8.0•..‚..˘.0.€.M
đĄĎ•..˘....ř˘06€
.SERVER-IGMIJJE8
9ˇ.0.€.1.8.0•..‚
..˘.0.€.MđĄĎ•..˘
...Xm07€.SERVERBKECR1FC6ˇ.0.€.1
.8.0•..‚..˘.0.€.
MđĄĎ•..˘....†Ů0.
SMLPublicOpen_Res {
CLIENT-GO0A3OBPF,
SERVER-XADE3KLQA,
}
DCMeterGetData_Res {
Document title: Communication Standard Between AMI Application and Metering Infrastructure
75 z 90
2078902676 [HEX: 7B E9 89 94],
8750 [HEX: 22 2E],
parameterTreePath {
1.8.0,
}
DCSML_ServerIDAnswers {
SERVER-QS9YICBYI,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
42429 [HEX: A5 BD],
}
}
SMLProfObjPeriodEntry {
1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST
2011),
8,
{
58574 [HEX: E4 CE],
}
}
SMLProfObjPeriodEntry {
1307618518 [HEX: 4D F0 AC D6] (Thu Jun 09 13:21:58 CEST
2011),
8,
{
62488 [HEX: F4 18],
}
}
SMLProfObjPeriodEntry {
1307619418 [HEX: 4D F0 B0 5A] (Thu Jun 09 13:36:58 CEST
2011),
8,
{
12680 [HEX: 31 88],
}
}
}
DCSML_ServerIDAnswers {
SERVER-9CSFCRDH5,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
53621 [HEX: D1 75],
}
}
SMLProfObjPeriodEntry {
Document title: Communication Standard Between AMI Application and Metering Infrastructure
76 z 90
1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST
2011),
8,
{
15381 [HEX: 3C 15],
}
}
SMLProfObjPeriodEntry {
1307618518 [HEX: 4D F0 AC D6] (Thu Jun 09 13:21:58 CEST
2011),
8,
{
57326 [HEX: DF EE],
}
}
SMLProfObjPeriodEntry {
1307619418 [HEX: 4D F0 B0 5A] (Thu Jun 09 13:36:58 CEST
2011),
8,
{
28371 [HEX: 6E D3],
}
}
}
DCSML_ServerIDAnswers {
SERVER-2KBGFPDQA,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
2127
[HEX: 08 4F],
}
}
SMLProfObjPeriodEntry {
1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST
2011),
8,
{
12857 [HEX: 32 39],
}
}
SMLProfObjPeriodEntry {
1307618518 [HEX: 4D F0 AC D6] (Thu Jun 09 13:21:58 CEST
2011),
8,
{
18283 [HEX: 47 6B],
}
}
SMLProfObjPeriodEntry {
1307619418 [HEX: 4D F0 B0 5A] (Thu Jun 09 13:36:58 CEST
2011),
8,
{
Document title: Communication Standard Between AMI Application and Metering Infrastructure
77 z 90
28557 [HEX: 6F 8D],
}
}
}
DCSML_ServerIDAnswers {
SERVER-C0IO84PZS,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
39227 [HEX: 99 3B],
}
}
SMLProfObjPeriodEntry {
1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST
2011),
8,
{
44251 [HEX: AC DB],
}
}
SMLProfObjPeriodEntry {
1307618518 [HEX: 4D F0 AC D6] (Thu Jun 09 13:21:58 CEST
2011),
8,
{
23239 [HEX: 5A C7],
}
}
SMLProfObjPeriodEntry {
1307619418 [HEX: 4D F0 B0 5A] (Thu Jun 09 13:36:58 CEST
2011),
8,
{
24035 [HEX: 5D E3],
}
}
}
DCSML_ServerIDAnswers {
SERVER-EQWS32GHO,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
57436 [HEX: E0 5C],
}
}
SMLProfObjPeriodEntry {
1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST
Document title: Communication Standard Between AMI Application and Metering Infrastructure
78 z 90
2011),
8,
{
637
[HEX: 02 7D],
}
}
SMLProfObjPeriodEntry {
1307618518 [HEX: 4D F0 AC D6] (Thu Jun 09 13:21:58 CEST
2011),
8,
{
51808 [HEX: CA 60],
}
}
SMLProfObjPeriodEntry {
1307619418 [HEX: 4D F0 B0 5A] (Thu Jun 09 13:36:58 CEST
2011),
8,
{
8985
[HEX: 23 19],
}
}
}
}
}
SMLPublicClose_Res {
}
Figure 60: Response 5-1-4 in ASN.1 notation
6.2.7
Example 5-5-1
6.2.7.1 Query
offset
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000A0
000000B0
000000C0
0
30
33
4B
56
45
10
30
46
30
84
31
38
30
1
24
4C
47
45
52
53
04
56
4C
04
2E
2E
30
2
80
56
4E
52
56
45
10
41
32
4D
38
30
00
3
10
33
43
2D
45
52
53
04
45
F0
2E
04
00
4
43
81
43
39
52
56
45
10
49
A5
30
05
00
5 6 7 8 9 10 11 12 13 14
4C 49 45 4E 54 2D 45 46 42 46
10 53 45 52 56 45 52 2D 54 50
45 30 81 98 A0 5A 04 10 53 45
53 32 50 45 4F 34 4E 46 04 10
2D 41 43 49 58 47 57 35 4E 57
45 52 2D 35 50 34 4E 52 38 32
52 56 45 52 2D 41 31 57 32 52
53 45 52 56 45 52 2D 48 4B 38
82 04 23 80 E1 43 83 03 00 F4
CE 85 04 4D F0 A9 52 A6 23 04
04 05 32 2E 38 2E 30 04 05 35
36 2E 38 2E 30 04 05 37 2E 38
00 00 00 00 00 00 00 00 00 00
Figure 61: Response 5-5-4 in the APDU form
15
33
41
52
53
04
55
33
5A
B4
05
2E
2E
00
ascii
0$€.CLIENT-EFBF3
3LV3•.SERVER-TPA
KGNCCE0•˜ Z..SER
VER-9S2PEO4NF..S
ERVER-ACIXGW5NW.
.SERVER-5P4NR82U
0..SERVER-A1W2R3
FVA..SERVER-HK8Z
0L2EI‚.#€áCƒ..ô´
„.MđĄÎ….Mđ©R¦#..
1.8.0..2.8.0..5.
8.0..6.8.0..7.8.
00..............
SMLPublicOpen_Req {
CLIENT-EFBF33LV3,
SERVER-TPAKGNCCE,
}
DCMeterGetData_Req {
listserverID {
SERVER-9S2PEO4NF,
SERVER-ACIXGW5NW,
Document title: Communication Standard Between AMI Application and Metering Infrastructure
79 z 90
SERVER-5P4NR82U0,
SERVER-A1W2R3FVA,
SERVER-HK8Z0L2EI,
}
595648835 [HEX: 23 80 E1 43],
62644 [HEX: F4 B4],
1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST 2011),
1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST 2011),
parameterTreePath {
1.8.0,
2.8.0,
5.8.0,
6.8.0,
7.8.0,
}
}
SMLPublicClose_Req {
}
Figure 62: Query 5-5-1 in ASN.1 notation
6.2.7.2 Response
offset
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000A0
000000B0
000000C0
000000D0
000000E0
000000F0
00000100
00000110
00000120
00000130
00000140
00000150
00000160
00000170
00000180
00000190
000001A0
000001B0
000001C0
000001D0
000001E0
000001F0
0
30
33
4B
82
2E
2E
80
4E
82
01
01
30
25
00
1C
52
05
32
2E
38
2E
A5
02
80
55
82
01
01
30
24
74
02
1
24
4C
47
02
38
30
10
46
01
01
30
0D
30
82
02
2D
31
2E
38
2E
30
CE
03
10
30
01
01
30
0D
30
EF
03
2
80
56
4E
4E
2E
04
53
A1
01
30
0D
80
23
05
03
41
2E
38
2E
30
81
81
00
53
A1
01
30
0D
80
22
02
00
3
10
33
43
BD
30
05
45
4B
30
0D
80
05
80
02
00
43
38
2E
30
81
01
01
EC
45
4B
30
0D
80
05
80
02
C5
4
43
81
43
A3
04
37
52
30
0D
80
05
37
04
02
B9
49
2E
30
81
01
01
08
A2
52
30
0D
80
05
37
04
78
5D
5
4C
10
45
23
05
2E
56
0D
80
05
36
2E
4D
23
24
58
30
81
01
04
82
A2
02
56
0D
80
05
36
2E
4D
48
30
6
49
53
30
04
35
38
45
80
05
35
2E
38
F0
58
30
47
81
01
08
82
01
16
02
45
80
05
35
2E
38
F0
02
81
7
45
45
82
05
2E
2E
52
05
32
2E
38
2E
A5
02
81
57
01
07
82
01
01
02
5C
52
05
32
2E
38
2E
A5
03
84
8
4E
52
02
31
38
30
2D
31
2E
38
2E
30
CE
03
84
35
05
82
01
01
A2
02
4F
2D
31
2E
38
2E
30
CE
00
80
9
54
56
DB
2E
2E
A4
39
2E
38
2E
30
81
81
00
80
4E
82
01
01
30
23
02
02
35
2E
38
2E
30
81
81
BE
10
10
2D
45
81
38
30
82
53
38
2E
30
81
01
01
D1
10
57
01
01
30
0D
30
18
02
50
38
2E
30
81
01
01
B9
53
11
45
52
04
2E
04
02
32
2E
30
81
01
01
08
9F
53
A1
01
30
0D
80
21
02
24
34
2E
30
81
01
01
08
02
45
12
46
2D
1A
30
05
A8
50
30
81
01
04
82
A2
02
45
4B
30
0D
80
05
80
03
94
4E
30
81
01
04
82
A2
03
52
13
42
54
14
04
36
30
45
81
01
08
82
01
18
03
52
30
0D
80
05
37
04
00
30
52
81
01
08
82
01
17
00
56
14
46
50
D7
05
2E
81
4F
01
07
82
01
01
02
00
56
0D
80
05
36
2E
4D
E8
81
38
01
07
82
01
01
02
CB
45
15
33
41
12
32
38
86
34
05
82
01
01
A2
03
E5
45
80
05
35
2E
38
F0
87
85
32
05
82
01
01
A2
02
A7
52
ascii
0$€.CLIENT-EFBF3
3LV3•.SERVER-TPA
KGNCCE0‚.Ű•...×.
‚.N˝Ł#..1.8.0..2
.8.0..5.8.0..6.8
.0..7.8.0¤‚.¨0•†
€.SERVER-9S2PEO4
NFˇK0.€.1.8.0•..
‚..0.€.2.8.0•..‚
..0.€.5.8.0•..‚.
.0.€.6.8.0•..‚..
0.€.7.8.0•..‚..˘
%0#€.MđĄÎ•..˘...
.‚...#X...Ńź...ĺ
....ą$0•„€.SERVE
R-ACIXGW5NWˇK0.€
.1.8.0•..‚..0.€.
2.8.0•..‚..0.€.5
.8.0•..‚..0.€.6.
8.0•..‚..0.€.7.8
.0•..‚..˘#0!€.Mđ
ĄÎ•..˘........č‡
...ě˘..\O..$”0•…
€.SERVER-5P4NR82
U0ˇK0.€.1.8.0•..
‚..0.€.2.8.0•..‚
..0.€.5.8.0•..‚.
.0.€.6.8.0•..‚..
0.€.7.8.0•..‚..˘
$0"€.MđĄÎ•..˘...
tď..xH...ľą...˧
...Ĺ]0•„€.SERVER
Document title: Communication Standard Between AMI Application and Metering Infrastructure
80 z 90
00000200 2D 41 31 57 32 52 33 46 56 41 A1 4B 30 0D 80 05 -A1W2R3FVAˇK0.€.
00000210 31 2E 38 2E 30 81 01 05 82 01 01 30 0D 80 05 32 1.8.0•..‚..0.€.2
00000220 2E 38 2E 30 81 01 07 82 01 01 30 0D 80 05 35 2E .8.0•..‚..0.€.5.
Figure 63: Response 5-5-1 in the APDU form
SMLPublicOpen_Res {
CLIENT-EFBF33LV3,
SERVER-TPAKGNCCE,
}
DCMeterGetData_Res {
437573394 [HEX: 1A 14 D7 12],
20157 [HEX: 4E BD],
parameterTreePath {
1.8.0,
2.8.0,
5.8.0,
6.8.0,
7.8.0,
}
DCSML_ServerIDAnswers {
SERVER-9S2PEO4NF,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
SMLHeaderEntry { 2.8.0, 7, 1 }
SMLHeaderEntry { 5.8.0, 8, 1 }
SMLHeaderEntry { 6.8.0, 4, 1 }
SMLHeaderEntry { 7.8.0, 1, 1 }
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
33285 [HEX: 82 05],
9048
[HEX: 23 58],
53663 [HEX: D1 9F],
58652 [HEX: E5 1C],
47396 [HEX: B9 24],
}
}
}
DCSML_ServerIDAnswers {
SERVER-ACIXGW5NW,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
SMLHeaderEntry { 2.8.0, 7, 1 }
SMLHeaderEntry { 5.8.0, 8, 1 }
SMLHeaderEntry { 6.8.0, 4, 1 }
SMLHeaderEntry { 7.8.0, 1, 1 }
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
536
[HEX: 02 18],
Document title: Communication Standard Between AMI Application and Metering Infrastructure
81 z 90
59527
60578
23631
9364
[HEX:
[HEX:
[HEX:
[HEX:
E8
EC
5C
24
87],
A2],
4F],
94],
}
}
}
DCSML_ServerIDAnswers {
SERVER-5P4NR82U0,
{
SMLHeaderEntry { 1.8.0,
SMLHeaderEntry { 2.8.0,
SMLHeaderEntry { 5.8.0,
SMLHeaderEntry { 6.8.0,
SMLHeaderEntry { 7.8.0,
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX:
5,
7,
8,
4,
1,
1
1
1
1
1
}
}
}
}
}
4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
29935
30792
48825
52135
50525
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
74
78
BE
CB
C5
EF],
48],
B9],
A7],
5D],
}
}
}
DCSML_ServerIDAnswers {
SERVER-A1W2R3FVA,
{
SMLHeaderEntry { 1.8.0,
SMLHeaderEntry { 2.8.0,
SMLHeaderEntry { 5.8.0,
SMLHeaderEntry { 6.8.0,
SMLHeaderEntry { 7.8.0,
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX:
5,
7,
8,
4,
1,
1
1
1
1
1
}
}
}
}
}
4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
24847
58828
26551
3180
41280
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
61
E5
67
0C
A1
0F],
CC],
B7],
6C],
40],
}
}
}
DCSML_ServerIDAnswers {
SERVER-HK8Z0L2EI,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
SMLHeaderEntry { 2.8.0, 7, 1 }
SMLHeaderEntry { 5.8.0, 8, 1 }
Document title: Communication Standard Between AMI Application and Metering Infrastructure
82 z 90
SMLHeaderEntry { 6.8.0, 4, 1 }
SMLHeaderEntry { 7.8.0, 1, 1 }
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
63424
45317
60807
8757
49005
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
F7
B1
ED
22
BF
C0],
05],
87],
35],
6D],
}
}
}
}
}
SMLPublicClose_Res {
}
Figure 64: Response 5-5-1 in ASN.1 notation
6.2.8
Example 5-5-4
6.2.8.1 Query
offset
0
1
2
3
4
5
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000A0
000000B0
000000C0
30
43
38
56
45
10
44
57
49
84
31
38
30
24
56
4B
45
52
53
04
58
34
04
2E
2E
30
80
43
33
52
56
45
10
57
55
4D
38
30
00
10
52
50
2D
45
52
53
04
30
F0
2E
04
00
43
81
48
39
52
56
45
10
30
A5
30
05
00
4C 49 45 4E 54 2D 4C 36 48 42
10 53 45 52 56 45 52 2D 5A 36
37 30 81 98 A0 5A 04 10 53 45
43 33 35 34 59 41 46 57 04 10
2D 36 47 43 4C 49 43 43 44 31
45 52 2D 4F 44 5A 38 39 4A 4B
52 56 45 52 2D 55 50 42 33 35
53 45 52 56 45 52 2D 49 43 5A
82 04 3E 8D A8 35 83 03 00 C9
CE 85 04 4D F0 B3 DE A6 23 04
04 05 32 2E 38 2E 30 04 05 35
36 2E 38 2E 30 04 05 37 2E 38
00 00 00 00 00 00 00 00 00 00
Figure 65: Response 5-5-4 in the APDU form
6
7
8
9
10 11 12 13 14 15
45
36
52
53
04
4B
57
39
13
05
2E
2E
00
ascii
0$€.CLIENT-L6HBE
CVCR•.SERVER-Z66
8K3PH70•˜ Z..SER
VER-9C354YAFW..S
ERVER-6GCLICCD1.
.SERVER-ODZ89JKK
D..SERVER-UPB35W
WXW..SERVER-ICZ9
I4U00‚.>Ť¨5ƒ..É.
„.MđĄÎ….MđłŢ¦#..
1.8.0..2.8.0..5.
8.0..6.8.0..7.8.
00..............
SMLPublicOpen_Req {
CLIENT-L6HBECVCR,
SERVER-Z668K3PH7,
}
DCMeterGetData_Req {
listserverID {
SERVER-9C354YAFW,
SERVER-6GCLICCD1,
SERVER-ODZ89JKKD,
SERVER-UPB35WWXW,
SERVER-ICZ9I4U00,
}
1049471029 [HEX: 3E 8D A8 35],
51475 [HEX: C9 13],
Document title: Communication Standard Between AMI Application and Metering Infrastructure
83 z 90
1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST 2011),
1307620318 [HEX: 4D F0 B3 DE] (Thu Jun 09 13:51:58 CEST 2011),
parameterTreePath {
1.8.0,
2.8.0,
5.8.0,
6.8.0,
7.8.0,
}
}
SMLPublicClose_Req {
}
Figure 66: Query 5-5-4 in ASN.1 notation
6.2.8.2 Response
offset
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000A0
000000B0
000000C0
000000D0
000000E0
000000F0
00000100
00000110
00000120
00000130
00000140
00000150
00000160
00000170
00000180
00000190
000001A0
000001B0
000001C0
000001D0
000001E0
000001F0
00000200
00000210
00000220
0
30
43
38
82
2E
2E
80
46
82
01
01
30
81
02
02
A2
02
81
78
F0
02
F1
43
05
82
01
01
A2
02
03
52
00
F0
7D
80
1
24
56
4B
02
38
30
10
57
01
01
30
0D
8C
46
03
16
57
01
45
B0
02
80
44
82
01
01
30
81
03
00
81
EE
MOD
02
04
2
80
43
33
21
2E
04
53
A1
01
30
0D
80
30
C2
00
02
2E
08
02
5A
1C
10
31
01
01
30
0D
8F
00
87
01
F9
D6
02
4D
3
10
52
50
A1
30
05
45
4B
30
0D
80
05
21
02
F4
03
02
A2
03
81
F9
53
A1
01
30
0D
80
30
DD
92
08
02
81
24
F0
4
43
81
48
A3
04
37
52
30
0D
80
05
37
80
02
B8
00
03
16
00
01
02
45
4B
30
0D
80
05
24
1C
02
A2
02
01
DD
B0
5 6 7 8 9 10 11 12 13 14
4C 49 45 4E 54 2D 4C 36 48 42
10 53 45 52 56 45 52 2D 5A 36
37 30 82 04 EC 81 04 69 8A D5
23 04 05 31 2E 38 2E 30 04 05
05 35 2E 38 2E 30 04 05 36 2E
2E 38 2E 30 A4 82 04 B9 30 81
56 45 52 2D 39 43 33 35 34 59
0D 80 05 31 2E 38 2E 30 81 01
80 05 32 2E 38 2E 30 81 01 07
05 35 2E 38 2E 30 81 01 08 82
36 2E 38 2E 30 81 01 04 82 01
2E 38 2E 30 81 01 01 82 01 01
04 4D F0 A5 CE 81 01 08 A2 16
49 31 02 02 59 F9 02 03 00 AB
30 21 80 04 4D F0 A9 52 81 01
F2 18 02 02 37 37 02 02 53 44
00 A6 9C 30 21 80 04 4D F0 MOD
02 02 77 DB 02 03 00 84 A8 02
FA 3D 02 02 00 CC 30 21 80 04
08 A2 16 02 02 2F 1D 02 02 4C
03 00 F2 C6 02 03 00 88 8A 30
52 56 45 52 2D 36 47 43 4C 49
30 0D 80 05 31 2E 38 2E 30 81
0D 80 05 32 2E 38 2E 30 81 01
80 05 35 2E 38 2E 30 81 01 08
05 36 2E 38 2E 30 81 01 04 82
37 2E 38 2E 30 81 01 01 82 01
80 04 4D F0 A5 CE 81 01 08 A2
02 03 00 9A 56 02 03 00 A6 CA
03 00 91 C3 30 20 80 04 4D F0
15 02 02 69 9B 02 02 51 C2 02
49 A8 02 02 29 65 30 21 80 04
08 A2 16 02 02 2E 9B 02 03 00
02 02 4F EE 02 03 00 AB 8D 30
5A 81 01 08 A2 17 02 03 00 E3
Figure 67: Response 5-5-4 in the APDU form
15
45
36
E5
32
38
EE
41
05
82
01
01
A2
02
52
08
02
D6
02
4D
7E
81
43
01
07
82
01
01
19
02
A9
03
4D
F1
22
90
ascii
0$€.CLIENT-L6HBE
CVCR•.SERVER-Z66
8K3PH70‚.ě•.iŠŐĺ
‚.!ˇŁ#..1.8.0..2
.8.0..5.8.0..6.8
.0..7.8.0¤‚.ą0•î
€.SERVER-9C354YA
FWˇK0.€.1.8.0•..
‚..0.€.2.8.0•..‚
..0.€.5.8.0•..‚.
.0.€.6.8.0•..‚..
0.€.7.8.0•..‚..˘
•Ś0!€.MđĄÎ•..˘..
.FÂ..I1..Yů...«R
...ô¸0!€.Mđ©R•..
˘....ň...77..SD.
.W....¦ś0!€.Mđ¬Ö
•..˘...wŰ...„¨..
xE...ú=...Ě0!€.M
đ°Z•..˘.../...L~
...ů...ňĆ...ˆŠ0•
ń€.SERVER-6GCLIC
CD1ˇK0.€.1.8.0•.
.‚..0.€.2.8.0•..
‚..0.€.5.8.0•..‚
..0.€.6.8.0•..‚.
.0.€.7.8.0•..‚..
˘•Ź0$€.MđĄÎ•..˘.
...Ý....šV...¦Ę.
..‡’...‘Ă0 €.Mđ©
R•..˘...i›..QÂ..
.îů..I¨..)e0!€.M
đ¬Ö•..˘....›...ń
}..$Ý..Oî...«Ť0"
€.Mđ°Z•..˘....ă•
Document title: Communication Standard Between AMI Application and Metering Infrastructure
84 z 90
SMLPublicOpen_Res {
CLIENT-L6HBECVCR,
SERVER-Z668K3PH7,
}
DCMeterGetData_Res {
1770706405 [HEX: 69 8A D5 E5],
8609 [HEX: 21 A1],
parameterTreePath {
1.8.0,
2.8.0,
5.8.0,
6.8.0,
7.8.0,
}
DCSML_ServerIDAnswers {
SERVER-9C354YAFW,
{
SMLHeaderEntry { 1.8.0, 5, 1 }
SMLHeaderEntry { 2.8.0, 7, 1 }
SMLHeaderEntry { 5.8.0, 8, 1 }
SMLHeaderEntry { 6.8.0, 4, 1 }
SMLHeaderEntry { 7.8.0, 1, 1 }
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
18114 [HEX: 46 C2],
18737 [HEX: 49 31],
23033 [HEX: 59 F9],
43858 [HEX: AB 52],
62648 [HEX: F4 B8],
}
}
SMLProfObjPeriodEntry {
1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST
2011),
8,
{
61976 [HEX: F2 18],
14135 [HEX: 37 37],
21316 [HEX: 53 44],
22318 [HEX: 57 2E],
42652 [HEX: A6 9C],
}
}
SMLProfObjPeriodEntry {
1307618518 [HEX: 4D F0 AC D6] (Thu Jun 09 13:21:58 CEST
2011),
8,
{
30683 [HEX: 77 DB],
33960 [HEX: 84 A8],
30789 [HEX: 78 45],
64061 [HEX: FA 3D],
204
[HEX: CC],
Document title: Communication Standard Between AMI Application and Metering Infrastructure
85 z 90
}
}
SMLProfObjPeriodEntry {
1307619418 [HEX: 4D F0 B0 5A] (Thu Jun 09 13:36:58 CEST
2011),
8,
{
12061
19582
7417
62150
34954
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
2F
4C
1C
F2
88
1D],
7E],
F9],
C6],
8A],
}
}
}
DCSML_ServerIDAnswers {
SERVER-6GCLICCD1,
{
SMLHeaderEntry { 1.8.0,
SMLHeaderEntry { 2.8.0,
SMLHeaderEntry { 5.8.0,
SMLHeaderEntry { 6.8.0,
SMLHeaderEntry { 7.8.0,
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX:
5,
7,
8,
4,
1,
1
1
1
1
1
}
}
}
}
}
4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
56604
39510
42698
34706
37315
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
DD
9A
A6
87
91
1C],
56],
CA],
92],
C3],
}
}
SMLProfObjPeriodEntry {
1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST
2011),
8,
{
27035
20930
61177
18856
10597
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
69
51
EE
49
29
9B],
C2],
F9],
A8],
65],
}
}
SMLProfObjPeriodEntry {
1307618518 [HEX: 4D F0 AC D6] (Thu Jun 09 13:21:58 CEST
2011),
8,
{
11931
61821
9437
20462
43917
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
2E
F1
24
4F
AB
9B],
7D],
DD],
EE],
8D],
Document title: Communication Standard Between AMI Application and Metering Infrastructure
86 z 90
}
}
SMLProfObjPeriodEntry {
1307619418 [HEX: 4D F0 B0 5A] (Thu Jun 09 13:36:58 CEST
2011),
8,
{
58256
15518
40582
40451
31787
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
E3
3C
9E
9E
7C
90],
9E],
86],
03],
2B],
}
}
}
DCSML_ServerIDAnswers {
SERVER-ODZ89JKKD,
{
SMLHeaderEntry { 1.8.0,
SMLHeaderEntry { 2.8.0,
SMLHeaderEntry { 5.8.0,
SMLHeaderEntry { 6.8.0,
SMLHeaderEntry { 7.8.0,
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX:
5,
7,
8,
4,
1,
1
1
1
1
1
}
}
}
}
}
4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
17488
52224
41762
17906
38778
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
44 50],
CC],
A3 22],
45 F2],
97 7A],
}
}
SMLProfObjPeriodEntry {
1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST
2011),
8,
{
6706
40163
13280
61217
17106
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
1A
9C
33
EF
42
32],
E3],
E0],
21],
D2],
}
}
SMLProfObjPeriodEntry {
1307618518 [HEX: 4D F0 AC D6] (Thu Jun 09 13:21:58 CEST
2011),
8,
{
16208
26068
14902
39920
26979
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
3F
65
3A
9B
69
50],
D4],
36],
F0],
63],
Document title: Communication Standard Between AMI Application and Metering Infrastructure
87 z 90
}
}
SMLProfObjPeriodEntry {
1307619418 [HEX: 4D F0 B0 5A] (Thu Jun 09 13:36:58 CEST
2011),
8,
{
28938
874
27005
56566
30630
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
71
03
69
DC
77
0A],
6A],
7D],
F6],
A6],
}
}
}
DCSML_ServerIDAnswers {
SERVER-UPB35WWXW,
{
SMLHeaderEntry { 1.8.0,
SMLHeaderEntry { 2.8.0,
SMLHeaderEntry { 5.8.0,
SMLHeaderEntry { 6.8.0,
SMLHeaderEntry { 7.8.0,
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX:
5,
7,
8,
4,
1,
1
1
1
1
1
}
}
}
}
}
4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
37388
45669
61276
12436
46896
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
92
B2
EF
30
B7
0C],
65],
5C],
94],
30],
}
}
SMLProfObjPeriodEntry {
1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST
2011),
8,
{
49294
23480
7800
28070
18557
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
C0
5B
1E
6D
48
8E],
B8],
78],
A6],
7D],
}
}
SMLProfObjPeriodEntry {
1307618518 [HEX: 4D F0 AC D6] (Thu Jun 09 13:21:58 CEST
2011),
8,
{
52907
40185
8909
10991
60658
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
CE
9C
22
2A
EC
AB],
F9],
CD],
EF],
F2],
Document title: Communication Standard Between AMI Application and Metering Infrastructure
88 z 90
}
}
SMLProfObjPeriodEntry {
1307619418 [HEX: 4D F0 B0 5A] (Thu Jun 09 13:36:58 CEST
2011),
8,
{
42543
51178
53586
55569
64530
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
A6
C7
D1
D9
FC
2F],
EA],
52],
11],
12],
}
}
}
DCSML_ServerIDAnswers {
SERVER-ICZ9I4U00,
{
SMLHeaderEntry { 1.8.0,
SMLHeaderEntry { 2.8.0,
SMLHeaderEntry { 5.8.0,
SMLHeaderEntry { 6.8.0,
SMLHeaderEntry { 7.8.0,
}
{
SMLProfObjPeriodEntry {
1307616718 [HEX:
5,
7,
8,
4,
1,
1
1
1
1
1
}
}
}
}
}
4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST
2011),
8,
{
11298
29078
28706
19155
30849
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
2C
71
70
4A
78
22],
96],
22],
D3],
81],
}
}
SMLProfObjPeriodEntry {
1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST
2011),
8,
{
58615
61694
8230
22636
15448
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
E4
F0
20
58
3C
F7],
FE],
26],
6C],
58],
}
}
SMLProfObjPeriodEntry {
1307618518 [HEX: 4D F0 AC D6] (Thu Jun 09 13:21:58 CEST
2011),
8,
{
15493
52823
54491
34185
5962
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
3C
CE
D4
85
17
85],
57],
DB],
89],
4A],
Document title: Communication Standard Between AMI Application and Metering Infrastructure
89 z 90
}
}
SMLProfObjPeriodEntry {
1307619418 [HEX: 4D F0 B0 5A] (Thu Jun 09 13:36:58 CEST
2011),
8,
{
28791
22704
1492
13972
16694
[HEX:
[HEX:
[HEX:
[HEX:
[HEX:
70
58
05
36
41
77],
B0],
D4],
94],
36],
}
}
}
}
}
SMLPublicClose_Res {
}
Figure 68: Response 5-5-4 in ASN.1 notation
Document title: Communication Standard Between AMI Application and Metering Infrastructure
90 z 90