July 7, 2016 at 11:48Comparison of DLMS / COSEM, SML and IEC 61850 communication protocols for smart metering applications
- Transfer
Communication technology is playing an increasingly important role in the growing AMI market. The article is a complete analysis and comparison of four application-level protocols used for intelligent consumption accounting. The following protocols are considered: DLMS / COSEM, SML (Smart Message Language), as well as MMS and SOAP mapping IEC 61850. The work focuses on the use of these protocols in conjunction with the TCP / IP stack. Protocols are first compared with respect to qualitative criteria, for example, the possibility of time synchronization, etc. After that, the size of messages is compared and the coding efficiency is analyzed.
AMI (Advanced metering infrastructure) is an integrated system of smart metering devices, communication networks and data management systems, which includes two-way communication between a service provider and a consumer.
The number and size of AMI systems is growing rapidly. They consist of smart metering devices located in homes and supporting two-way communication with a service provider. The introduction of such systems is mainly associated with the achievement of the following three goals:
Communication in smart metering devices is the subject of several standardization works ( for example, [1]) and part of national roadmaps dedicated to smart grids [2, 3]. But so far, most installed AMI equipment uses proprietary protocols that do not comply with open or international standards. In the future, however, it is necessary to focus on open standards. This will create competition in the free market and lead to lower equipment costs.
This article compares four different application layer protocols used for smart metering. These are SML ( Smart Message Language, IEC 62056-58 Draft ) protocol [4], DLMS / COSEM ( IEC 62056-53 [5], andIEC 62056-62 [6]), as well as MMS [7] and SOAP [8] mapping for the IEC 61850 standard.
Previously, protocols for smart metering of consumption have already been analyzed from various points of view. So, in [9] a general overview of the most common protocols for intelligent consumption metering at all levels is presented. In [11], DLMS / COSEM is compared with IEC 60870-5-104. A detailed analysis of DLMS / COSEM is given in [12]. This article is the first to compare DLMS / COSEM, SML, and IEC 61850 protocols for quality criteria and coding efficiency.
The article is organized as follows. The second section discusses the general network topologies used in smart metering. It is indicated where the protocols in question can be used. The third section discusses the qualitative criteria by which protocols are analyzed and compared in the fourth section. The fifth section analyzes the message size and coding efficiency of the protocols under consideration. The conclusion is a conclusion.
To organize communications in AMI systems, various network topologies are used. However, most topologies can be obtained from the general form shown in Figure 1 . In this figure, gas, electricity, water, heat meters are connected to the so-called “home gateway”, through which an interface to the outside world is realized. In most cases, this gateway is actually integrated into the meter of electric energy. It should be noted that gas, water and heat meters are special in that they are mainly powered by autonomous sources. This feature should be considered when choosing communication protocols for the line ( b) The gateway (or electricity meter) can be connected to the data collection system on the side of the service provider either directly through the Internet connection ( c ) or through the data concentrator ( d and e ) - where d is usually a power line or a wireless medium solution radius of action.
Figure 1 - Communication topology for intelligent consumption metering
The application layer protocols discussed in this article can use the TCP / IP protocol stack for data exchange, therefore they are suitable for organizing communication via an Internet connection ( c and e ), and can also be applied for exchanging data on local networks such as Ethernet and WiFi ( a) In addition, some of the protocols under consideration support data exchange using other lower-level protocols. DLMS / COSEM supports data exchange via UDP, HDLC, M-Bus, as well as various power line communication protocols, for example IEC 61334-5. SML supports serial communication and the M-Bus protocol. MMS and SOAP do not support additional lower layer protocols.
This section describes the qualitative criteria by which the protocols will be analyzed and compared in the fourth section.
Application layer protocols used for smart metering of consumption can be compared with respect to their support for transmitting information of various kinds. For AMI systems, as a rule, communication technologies are needed to transfer the following types of information:
Application layer protocols can follow the strict client-server principle, in which case a connection or association is established only by the client. The server is a device that stores the data of the meter (for example, the meter itself), and the client is a device that wants to access this data or set any parameters in the server device.
Protocols can also be based on the peer-to-peer principle, in this case, two objects between which information is transmitted have equal opportunities. At any time, an object can play the role of a client or server. This principle allows more flexible use of the protocol, since metering devices have the ability to send data to other devices without the need for a connection from the client.
In client-server architecture-oriented protocols, DLMS / COSEM and IEC 61850, the server contains what is called an interface object model that represents the server device ( e.g.metering device). This model is built using an object-oriented approach and acts as a visible information interface for the client. The client can retrieve the interface object model in a standardized way using the protocol and thus do not need to know in advance about the exact structure and functionality of the server. In this case, they say that the server describes itself. On the one hand, the retrievable interface object model simplifies the data exchange mechanism, in the sense that the client can be programmed to automatically match various models. On the other hand, this model consolidates the client-server structure, since the server always contains an interface object model.
Most installed smart metering devices require more attention to the security of AMI systems. The protocol may have built-in security mechanisms, for example, encryption, or it may leave this procedure for lower-level protocols, for example, TLS (Transport layer security).
SML ( Smart Message Language ) was developed as part of the SyM 2 ( Synchronous Modular Meter ) project [14]. The SML protocol is widely used in Germany and is part of a large work on the standardization of smart consumption metering [15]. Until now, SML has rarely been used outside of Germany, but this may change if efforts to promote the SML protocol as an international standard are successful. However, it will be useful to compare the international DLMS \ COSEM and IEC 61850 standards with the SML protocol. Since such a comparison can lead to valuable improvements in the considered international standards.
SML differs from DLMS / COSEM and IEC 61850 in that it defines messages, instead of defining an interface object model and its access services. SML uses a form similar to ASN.1 to define the hierarchical structure of messages. Messages are encoded with a special cipher, which will be discussed in the fifth section. There can be two types of messages, or a request, or a response. However, a “response” message can be sent without a request. Thus, SML does not follow the strict principles of the client-server architecture and metering devices can issue proactive messages.
The message format supports the transfer of load profiles and associated digital signatures. In addition, it is possible to transfer a new firmware image and clock synchronization, however, these procedures are described in other standards (for example , [14]).
SML does not have built-in security mechanisms, with the exception of the simple username and password fields in SML messages. SSL / TLS can be used to transmit data over TCP / IP.
DLMS ( Device Language Message Specification ) and COSEM ( COmpanion Specification for Energy Metering ) together form the DLMS / COSEM application layer protocol [5] and the interface model for metering applications [6]. Using the intermediate layer defined in [16], DLMS / COSEM can be used to transmit data via TCP / IP and UDP / IP.
DLMS / COSEM is based on a rigorous, client-server architecture. The server is a metering device, and the client is a device that accesses the metering device. The client, for example, may be a gateway or data collection device on the side of the service provider. Other options are also possible, for example, when the server is located directly in the gateway, and the client is on the side of the service provider.
Before exchanging information containing actual measurements, it is necessary to establish a so-called association. This operation is initiated by the client. After the association is established, the DLMS client can access the interface object model located in the server. Once established, the DLMS server can send notifications to the client without an explicit request.
DLMS / COSEM supports clock synchronization and transfer of measurement profiles. Until now, the DLMS / COSEM described in [5] and [6] does not support the transmission of digital signatures along with measurement data, and also does not support the downloading of a new version of firmware. However, this functionality will be supported in the future. Already now there are objects for the operation of updating the firmware described in the blue book of the 10th edition. Support for digital signatures is in the works, this is done by DLMS UA.
DLMS / COSEM includes authentication and privacy services based on symmetric encryption. However, this protocol does not support TLS / SSL, with the help of which it would be possible to implement the services mentioned above using an asymmetric key. Support for asymmetric encryption is under development, the second working group of the thirteenth technical committee of CENELEC is engaged in this.
MMS and SOAP mapping of IEC 61850 do not differ in terms of supporting the quality criteria that are considered in this paper. Therefore, all of the above will be true for both protocols.
IEC 61850 is a group of standards designed specifically for use in substation automation. To date, the standard has been expanded to cover hydropower management [17], wind turbines [18] and other distributed energy resources [19]. In [19], the DLMS / COSEM and ANSI C12.19 standards are referred to as the standards used for commercial accounting. IEC 61850 applies where there is no commercial accounting requirement. This distinction between commercial accounting and other types of accounting seems to be more political than technical. Since there are no technical reasons not to use IEC 61850 as a protocol for commercial accounting.
IEC 61850 operates on the same principles of client-server architecture as DLMS / COSEM. The server contains an interface object model that is accessible through standardized services. How exactly these services will be transferred depends on which display is used (for example, MMS or SOAP).
The IEC 61850 Interface Object Model consists of freely composable logic devices (LDs). Logical devices consist of one or more logical nodes (LN). IEC 61850-7-4, for measurement, defines the MMRT logical node. Together with logging and / or reporting services, these logical nodes can be used to transfer load profiles. Digital signatures are not part of the logical node and therefore are not supported. The firmware update mechanism is also not supported by this standard. Both MMS and SOAP mapping use the SNTP protocol to synchronize time.
When MMS mapping is used, the server can send data without an explicit request through the IEC 61850 reporting engine. The association and thus the open TCP socket connection must be initiated by the client in advance. SOAP mapping does not support active server reporting.
Neither MMS nor SOAP mapping has built-in security mechanisms. This functionality is left to the TLS / SSL protocol, as recommended in [20].
Table 1 provides information on the support of certain qualitative criteria of the protocols under consideration. The main difference between the SML protocol and the other two protocols is that SML is not based on an interface object model and, therefore, this protocol does not attach particular importance to standardization at the functional level. On the one hand, this gives more flexibility in the use of the protocol, on the other hand, it means that details (for example, message types supported by devices) must be defined in other standards in order to guarantee interoperability. SML is the only protocol supporting the transfer of digital signatures.
Table 1 - Comparison of SML, DLMS / COSEM and IEC 61850 Protocols
DLMS / COSEM has the advantage over SML in that it is already an international standard that is widely used in Europe. Numerous teams are working to add the missing options to this standard. The fact that DLMS / COSEM defines its own security mechanism is not necessarily an advantage. Since the functionality related to security is limited only by the use of encryption with a symmetric key. If metering devices combined their measurement results with digital signatures, then one way or another, they would need asymmetric keys and could use the same key pairs for SSL / TLS, if this were allowed.
IEC 61850, in comparison with other standards, can be used not only for smart metering of consumption, but also for other smart grid applications. However, at present, there is little interest in making this protocol more functional for smart metering applications.
In the previous section, the protocols were analyzed with respect to quality criteria. This section provides an analysis of the effectiveness of various protocols. In particular, the total number of bytes transmitted by each protocol is considered. In this case, protocol comparison is not a trivial task, because all protocols support the transfer of various types of information using different message structures and different encryption schemes. For this reason, one operation, namely access to the readings of instantaneous values, was chosen to compare the protocols in the next subsection, after which there is a subsection devoted to various encryption schemes.
Obtaining instantaneous measured values is a fundamental operation supported by all protocols. For this reason, this operation was chosen as the basis for comparison.
First, we describe the mechanism for obtaining readings from metering devices for each protocol, and then compare the size of their messages. The four protocols in question use the following methods to access instantaneous readings:
Next, the message sizes of the corresponding requests and responses are determined. More precisely, the equations are determined by which the TCP SDU ( Service Data Unit ) size is calculated depending on the number of requested measured values. Several parameters in request and response messages are of variable length. For this reason, the parameters with the shortest length are always selected. In addition, using the protocols in question, a sufficiently large amount of data can be requested. Therefore, in order to compare the protocols, we will consider a query for measurement values in the form of four bytes of integers. The packet size is determined in part from the implementation of the actual communication protocols [21] and traffic capture, and also in part using analytical models.
For SML, the size of the TCP SDU of request and response messages is calculated as follows:
SML Req = SML TP V 1 + OpenReq + GetListReq + CloseReq + StuffedBits
SML Res = SML TP V 1 + OpenRes + GetListRes + CloseRes + StuffedBits
SML can potentially be used with different encoding schemes, but in practice, only binary SML Binary Encoding is used. For a scenario with non-parameterized parameters, the size of GetListReqPDU in bytes for transferring x values, using binary SML Binary Encoding, can be calculated as follows:
SML Req = 16 + 28 + 30x + 19 + 0
SML Res = 16 + 27 + 45x + 19 + 0
The following equations are valid for a scenario with pre-parameterized parameters:
SML Req = 16 + 28 + 30 + 19 + 0
SML Res = 16 + 27 + (26 + 19x) + 19 + 0
Composition and size of TCP SDU DLMS / COSEM, when transmitting x values is described by the following equations:
DLMS Req = TCP Wrapper + GetReqWithList = 8 + (4 + 11x)
DLMS Res = TCP Wrapper + GetResWithList = 8 + (4 + 6x)
Composition and size of TCP SDU MMS:
MMS Req = RFC 1006 and ISO 8073 + ISO 8327 Session + ISO Presentation + MMS GetListReqPDU = 7 + 4 + 9 + 44
MMS Res = RFC 1006 and ISO 8073 + ISO 8327 Session + ISO Presentation + MMS GetListResPDU = 7 + 4 + 9 + (10 + 6x)
Composition and TCP SDU SOAP Size:
SOAP Req = SOAP Header + SOAP Req XML = 197 + 236
SOAP Res = SOAP Header + SOAP Res XML = 113 + (175 + 32x)
The received message sizes are shown in Table 2 . In addition, the size of the response message is shown in graph form in Figure 2 . This figure shows that DLMS and MMS are the most effective protocols in terms of message size. However, do not forget that DLMS and IEC 61850 require an association in order to exchange messages. SML does not require association. The overhead associated with establishing an association was not accounted for for these calculations. However, they can be neglected if the association is established once and maintained for a long period of time.
Table 2 - TCP data field size in bytes as a function of the number of requested values (x).
Figure 2 - The size of the response message
All protocols, MMS, DLMS / COSEM and SML, use byte binary encoding to encode their messages. This section compares encodings directly.
MMS uses ASN.1 BER encoding for message encoding. DLMS / COSEM also uses BER encoding for association messages, however, after the association is established, special encoding rules, the so-called A-XDR, defined in [22] are used. A-XDR rules have been developed to reduce the amount of information compared to the BER and apply only to coding a subset of ASN.1. The SML protocol, in turn, also defines new encoding rules called SML Binary Encoding. The goal is the same as A-XDR - reducing message size compared to BER. When using BER encoding, usually one byte is required for the field responsible for the type of value, and one byte for the field containing information about the length of the encoded value. In the case of SML Binary Encoding, if possible, type and length are encoded in one byte. In A-XDR, value type and length fields are generally omitted wherever possible.
The three binary encodings examined are compared by encoding the MMS response message GetDataValues. Table 3 shows the number of bytes needed to encode the various components of an MMS message.
Table 3 - Comparison of message lengths for different encodings (in bytes)
As can be seen from table 3, A-XDR requires the least number of bytes to encode the packet. A-XDR encodes as efficiently as BER, and in some cases, with the exception of unselected additional fields, is even better. SML Binary Encoding does not encode with the least number of bytes for all cases. This is due to the fact that the tags in the selection are encoded with at least two bytes. All the “efficiency” of A-XDR and SML Binary Encoding is associated with type and length fields. Actual values are encoded with an equal number of bytes.
In this work, the most significant qualitative criteria were determined for the application-level protocol used for intelligent consumption accounting. A comparison of the DLMS / COSEM, SML, and IEC 61850 protocols showed that there is no single protocol that is best in all aspects. Analysis and comparison of message size showed that DLMS and MMS IEC 61850 are clearly superior to all others. Both DLMS / COSEM and SML use special encodings for more efficient encoding than BER, but SML Binary Encoding has significant drawbacks when encoding ASN.1 element selection tags. A-XDR does a good job of reducing costs caused by type and length fields.
In the future, it would be interesting to make a similar comparison for such promising protocols as ZigBee Smart Energy 2.0 and ANSI C12.19.
AMI (Advanced metering infrastructure) is an integrated system of smart metering devices, communication networks and data management systems, which includes two-way communication between a service provider and a consumer.
I. Introduction
The number and size of AMI systems is growing rapidly. They consist of smart metering devices located in homes and supporting two-way communication with a service provider. The introduction of such systems is mainly associated with the achievement of the following three goals:
- Providing consumers with information on their consumption and costs, thus contributing to a more economical use of resources;
- Redistribution of resource use from periods of high load to periods of low load.
- Creating an infrastructure that can be readily used by other smart grid applications in distribution networks.
Communication in smart metering devices is the subject of several standardization works ( for example, [1]) and part of national roadmaps dedicated to smart grids [2, 3]. But so far, most installed AMI equipment uses proprietary protocols that do not comply with open or international standards. In the future, however, it is necessary to focus on open standards. This will create competition in the free market and lead to lower equipment costs.
This article compares four different application layer protocols used for smart metering. These are SML ( Smart Message Language, IEC 62056-58 Draft ) protocol [4], DLMS / COSEM ( IEC 62056-53 [5], andIEC 62056-62 [6]), as well as MMS [7] and SOAP [8] mapping for the IEC 61850 standard.
Previously, protocols for smart metering of consumption have already been analyzed from various points of view. So, in [9] a general overview of the most common protocols for intelligent consumption metering at all levels is presented. In [11], DLMS / COSEM is compared with IEC 60870-5-104. A detailed analysis of DLMS / COSEM is given in [12]. This article is the first to compare DLMS / COSEM, SML, and IEC 61850 protocols for quality criteria and coding efficiency.
The article is organized as follows. The second section discusses the general network topologies used in smart metering. It is indicated where the protocols in question can be used. The third section discusses the qualitative criteria by which protocols are analyzed and compared in the fourth section. The fifth section analyzes the message size and coding efficiency of the protocols under consideration. The conclusion is a conclusion.
II. Communication topology of smart metering systems
To organize communications in AMI systems, various network topologies are used. However, most topologies can be obtained from the general form shown in Figure 1 . In this figure, gas, electricity, water, heat meters are connected to the so-called “home gateway”, through which an interface to the outside world is realized. In most cases, this gateway is actually integrated into the meter of electric energy. It should be noted that gas, water and heat meters are special in that they are mainly powered by autonomous sources. This feature should be considered when choosing communication protocols for the line ( b) The gateway (or electricity meter) can be connected to the data collection system on the side of the service provider either directly through the Internet connection ( c ) or through the data concentrator ( d and e ) - where d is usually a power line or a wireless medium solution radius of action.
Figure 1 - Communication topology for intelligent consumption metering
The application layer protocols discussed in this article can use the TCP / IP protocol stack for data exchange, therefore they are suitable for organizing communication via an Internet connection ( c and e ), and can also be applied for exchanging data on local networks such as Ethernet and WiFi ( a) In addition, some of the protocols under consideration support data exchange using other lower-level protocols. DLMS / COSEM supports data exchange via UDP, HDLC, M-Bus, as well as various power line communication protocols, for example IEC 61334-5. SML supports serial communication and the M-Bus protocol. MMS and SOAP do not support additional lower layer protocols.
III. Quality criteria
This section describes the qualitative criteria by which the protocols will be analyzed and compared in the fourth section.
A. Support for various types of information
Application layer protocols used for smart metering of consumption can be compared with respect to their support for transmitting information of various kinds. For AMI systems, as a rule, communication technologies are needed to transfer the following types of information:
- Measurement results . Naturally, all considered protocols support the transmission of measured data (energy, power, voltage, volume, etc.). But protocols can differ in their support for such types of information as:
- Load profiles . The meter can store load profiles ( for example , with a resolution of 15 minutes). Therefore, protocols should be able to transfer these profiles, if necessary with appropriate time stamps;
- Digital signature . Measurement results can be digitally signed in order to prove data integrity to third parties.
- Clock synchronization information . Time synchronization is important for metering devices that store load profiles or for metering devices that quickly switch, based on a schedule, between tariff registers.
- Firmware update . As gateways or metering devices, as well as their communication modules, are becoming increasingly complex, the remote firmware update function, which allows you to fix errors or add new functionality, looks quite useful.
- Cost information . The transmission of cost information can be implemented in several ways. An analysis of various approaches to the transfer of tariffs and comparison of protocols was made in [13]. This article does not analyze the protocols regarding their tariff support.
B. Possibility of proactive transfer
Application layer protocols can follow the strict client-server principle, in which case a connection or association is established only by the client. The server is a device that stores the data of the meter (for example, the meter itself), and the client is a device that wants to access this data or set any parameters in the server device.
Protocols can also be based on the peer-to-peer principle, in this case, two objects between which information is transmitted have equal opportunities. At any time, an object can play the role of a client or server. This principle allows more flexible use of the protocol, since metering devices have the ability to send data to other devices without the need for a connection from the client.
C. Availability of an interface object model
In client-server architecture-oriented protocols, DLMS / COSEM and IEC 61850, the server contains what is called an interface object model that represents the server device ( e.g.metering device). This model is built using an object-oriented approach and acts as a visible information interface for the client. The client can retrieve the interface object model in a standardized way using the protocol and thus do not need to know in advance about the exact structure and functionality of the server. In this case, they say that the server describes itself. On the one hand, the retrievable interface object model simplifies the data exchange mechanism, in the sense that the client can be programmed to automatically match various models. On the other hand, this model consolidates the client-server structure, since the server always contains an interface object model.
D. Built-in security mechanisms
Most installed smart metering devices require more attention to the security of AMI systems. The protocol may have built-in security mechanisms, for example, encryption, or it may leave this procedure for lower-level protocols, for example, TLS (Transport layer security).
IV. Qualitative Analysis
A. SML
SML ( Smart Message Language ) was developed as part of the SyM 2 ( Synchronous Modular Meter ) project [14]. The SML protocol is widely used in Germany and is part of a large work on the standardization of smart consumption metering [15]. Until now, SML has rarely been used outside of Germany, but this may change if efforts to promote the SML protocol as an international standard are successful. However, it will be useful to compare the international DLMS \ COSEM and IEC 61850 standards with the SML protocol. Since such a comparison can lead to valuable improvements in the considered international standards.
SML differs from DLMS / COSEM and IEC 61850 in that it defines messages, instead of defining an interface object model and its access services. SML uses a form similar to ASN.1 to define the hierarchical structure of messages. Messages are encoded with a special cipher, which will be discussed in the fifth section. There can be two types of messages, or a request, or a response. However, a “response” message can be sent without a request. Thus, SML does not follow the strict principles of the client-server architecture and metering devices can issue proactive messages.
The message format supports the transfer of load profiles and associated digital signatures. In addition, it is possible to transfer a new firmware image and clock synchronization, however, these procedures are described in other standards (for example , [14]).
SML does not have built-in security mechanisms, with the exception of the simple username and password fields in SML messages. SSL / TLS can be used to transmit data over TCP / IP.
B. DLMS / COSEM
DLMS ( Device Language Message Specification ) and COSEM ( COmpanion Specification for Energy Metering ) together form the DLMS / COSEM application layer protocol [5] and the interface model for metering applications [6]. Using the intermediate layer defined in [16], DLMS / COSEM can be used to transmit data via TCP / IP and UDP / IP.
DLMS / COSEM is based on a rigorous, client-server architecture. The server is a metering device, and the client is a device that accesses the metering device. The client, for example, may be a gateway or data collection device on the side of the service provider. Other options are also possible, for example, when the server is located directly in the gateway, and the client is on the side of the service provider.
Before exchanging information containing actual measurements, it is necessary to establish a so-called association. This operation is initiated by the client. After the association is established, the DLMS client can access the interface object model located in the server. Once established, the DLMS server can send notifications to the client without an explicit request.
DLMS / COSEM supports clock synchronization and transfer of measurement profiles. Until now, the DLMS / COSEM described in [5] and [6] does not support the transmission of digital signatures along with measurement data, and also does not support the downloading of a new version of firmware. However, this functionality will be supported in the future. Already now there are objects for the operation of updating the firmware described in the blue book of the 10th edition. Support for digital signatures is in the works, this is done by DLMS UA.
DLMS / COSEM includes authentication and privacy services based on symmetric encryption. However, this protocol does not support TLS / SSL, with the help of which it would be possible to implement the services mentioned above using an asymmetric key. Support for asymmetric encryption is under development, the second working group of the thirteenth technical committee of CENELEC is engaged in this.
C. IEC 61850
MMS and SOAP mapping of IEC 61850 do not differ in terms of supporting the quality criteria that are considered in this paper. Therefore, all of the above will be true for both protocols.
IEC 61850 is a group of standards designed specifically for use in substation automation. To date, the standard has been expanded to cover hydropower management [17], wind turbines [18] and other distributed energy resources [19]. In [19], the DLMS / COSEM and ANSI C12.19 standards are referred to as the standards used for commercial accounting. IEC 61850 applies where there is no commercial accounting requirement. This distinction between commercial accounting and other types of accounting seems to be more political than technical. Since there are no technical reasons not to use IEC 61850 as a protocol for commercial accounting.
IEC 61850 operates on the same principles of client-server architecture as DLMS / COSEM. The server contains an interface object model that is accessible through standardized services. How exactly these services will be transferred depends on which display is used (for example, MMS or SOAP).
The IEC 61850 Interface Object Model consists of freely composable logic devices (LDs). Logical devices consist of one or more logical nodes (LN). IEC 61850-7-4, for measurement, defines the MMRT logical node. Together with logging and / or reporting services, these logical nodes can be used to transfer load profiles. Digital signatures are not part of the logical node and therefore are not supported. The firmware update mechanism is also not supported by this standard. Both MMS and SOAP mapping use the SNTP protocol to synchronize time.
When MMS mapping is used, the server can send data without an explicit request through the IEC 61850 reporting engine. The association and thus the open TCP socket connection must be initiated by the client in advance. SOAP mapping does not support active server reporting.
Neither MMS nor SOAP mapping has built-in security mechanisms. This functionality is left to the TLS / SSL protocol, as recommended in [20].
D. Comparison
Table 1 provides information on the support of certain qualitative criteria of the protocols under consideration. The main difference between the SML protocol and the other two protocols is that SML is not based on an interface object model and, therefore, this protocol does not attach particular importance to standardization at the functional level. On the one hand, this gives more flexibility in the use of the protocol, on the other hand, it means that details (for example, message types supported by devices) must be defined in other standards in order to guarantee interoperability. SML is the only protocol supporting the transfer of digital signatures.
Table 1 - Comparison of SML, DLMS / COSEM and IEC 61850 Protocols
DLMS / COSEM has the advantage over SML in that it is already an international standard that is widely used in Europe. Numerous teams are working to add the missing options to this standard. The fact that DLMS / COSEM defines its own security mechanism is not necessarily an advantage. Since the functionality related to security is limited only by the use of encryption with a symmetric key. If metering devices combined their measurement results with digital signatures, then one way or another, they would need asymmetric keys and could use the same key pairs for SSL / TLS, if this were allowed.
IEC 61850, in comparison with other standards, can be used not only for smart metering of consumption, but also for other smart grid applications. However, at present, there is little interest in making this protocol more functional for smart metering applications.
V. Performance analysis
In the previous section, the protocols were analyzed with respect to quality criteria. This section provides an analysis of the effectiveness of various protocols. In particular, the total number of bytes transmitted by each protocol is considered. In this case, protocol comparison is not a trivial task, because all protocols support the transfer of various types of information using different message structures and different encryption schemes. For this reason, one operation, namely access to the readings of instantaneous values, was chosen to compare the protocols in the next subsection, after which there is a subsection devoted to various encryption schemes.
A. Access to instantaneous readings
Obtaining instantaneous measured values is a fundamental operation supported by all protocols. For this reason, this operation was chosen as the basis for comparison.
First, we describe the mechanism for obtaining readings from metering devices for each protocol, and then compare the size of their messages. The four protocols in question use the following methods to access instantaneous readings:
- SML defines a GetList message to obtain instantaneous measured values. The request message contains the names of the parameters or lists of parameters to be read. The response contains the requested list of values. Two scenarios will be analyzed:
- The SML meter or gateway is pre-parameterized with a list of parameters that must be read together. Thus, in order to get all the parameters / values associated with the list name, it will be enough to send the server the name of this list.
- The metering device or gateway is not pre-parameterized and explicit requests are required to obtain the desired readings.
- DLMS / COSEM defines a GET service for instant readings. Get-Request may contain a list of so-called COSEM Attribute Descriptors, which uniquely determine the exact parameters that should be read. The answer, in this case, contains a list of parameter values without repeating the associated descriptor.
- IEC 61850 offers services for managing and accessing so-called data sets. Thus, a data set containing an arbitrary number of data points can be created dynamically. Subsequently, the data set can be obtained quite efficiently using the GetDataSetValue service.
Next, the message sizes of the corresponding requests and responses are determined. More precisely, the equations are determined by which the TCP SDU ( Service Data Unit ) size is calculated depending on the number of requested measured values. Several parameters in request and response messages are of variable length. For this reason, the parameters with the shortest length are always selected. In addition, using the protocols in question, a sufficiently large amount of data can be requested. Therefore, in order to compare the protocols, we will consider a query for measurement values in the form of four bytes of integers. The packet size is determined in part from the implementation of the actual communication protocols [21] and traffic capture, and also in part using analytical models.
For SML, the size of the TCP SDU of request and response messages is calculated as follows:
SML Req = SML TP V 1 + OpenReq + GetListReq + CloseReq + StuffedBits
SML Res = SML TP V 1 + OpenRes + GetListRes + CloseRes + StuffedBits
SML can potentially be used with different encoding schemes, but in practice, only binary SML Binary Encoding is used. For a scenario with non-parameterized parameters, the size of GetListReqPDU in bytes for transferring x values, using binary SML Binary Encoding, can be calculated as follows:
SML Req = 16 + 28 + 30x + 19 + 0
SML Res = 16 + 27 + 45x + 19 + 0
The following equations are valid for a scenario with pre-parameterized parameters:
SML Req = 16 + 28 + 30 + 19 + 0
SML Res = 16 + 27 + (26 + 19x) + 19 + 0
Composition and size of TCP SDU DLMS / COSEM, when transmitting x values is described by the following equations:
DLMS Req = TCP Wrapper + GetReqWithList = 8 + (4 + 11x)
DLMS Res = TCP Wrapper + GetResWithList = 8 + (4 + 6x)
Composition and size of TCP SDU MMS:
MMS Req = RFC 1006 and ISO 8073 + ISO 8327 Session + ISO Presentation + MMS GetListReqPDU = 7 + 4 + 9 + 44
MMS Res = RFC 1006 and ISO 8073 + ISO 8327 Session + ISO Presentation + MMS GetListResPDU = 7 + 4 + 9 + (10 + 6x)
Composition and TCP SDU SOAP Size:
SOAP Req = SOAP Header + SOAP Req XML = 197 + 236
SOAP Res = SOAP Header + SOAP Res XML = 113 + (175 + 32x)
The received message sizes are shown in Table 2 . In addition, the size of the response message is shown in graph form in Figure 2 . This figure shows that DLMS and MMS are the most effective protocols in terms of message size. However, do not forget that DLMS and IEC 61850 require an association in order to exchange messages. SML does not require association. The overhead associated with establishing an association was not accounted for for these calculations. However, they can be neglected if the association is established once and maintained for a long period of time.
Table 2 - TCP data field size in bytes as a function of the number of requested values (x).
Figure 2 - The size of the response message
B. Comparison of binary encodings
All protocols, MMS, DLMS / COSEM and SML, use byte binary encoding to encode their messages. This section compares encodings directly.
MMS uses ASN.1 BER encoding for message encoding. DLMS / COSEM also uses BER encoding for association messages, however, after the association is established, special encoding rules, the so-called A-XDR, defined in [22] are used. A-XDR rules have been developed to reduce the amount of information compared to the BER and apply only to coding a subset of ASN.1. The SML protocol, in turn, also defines new encoding rules called SML Binary Encoding. The goal is the same as A-XDR - reducing message size compared to BER. When using BER encoding, usually one byte is required for the field responsible for the type of value, and one byte for the field containing information about the length of the encoded value. In the case of SML Binary Encoding, if possible, type and length are encoded in one byte. In A-XDR, value type and length fields are generally omitted wherever possible.
The three binary encodings examined are compared by encoding the MMS response message GetDataValues. Table 3 shows the number of bytes needed to encode the various components of an MMS message.
Table 3 - Comparison of message lengths for different encodings (in bytes)
As can be seen from table 3, A-XDR requires the least number of bytes to encode the packet. A-XDR encodes as efficiently as BER, and in some cases, with the exception of unselected additional fields, is even better. SML Binary Encoding does not encode with the least number of bytes for all cases. This is due to the fact that the tags in the selection are encoded with at least two bytes. All the “efficiency” of A-XDR and SML Binary Encoding is associated with type and length fields. Actual values are encoded with an equal number of bytes.
VI. Conclusion
In this work, the most significant qualitative criteria were determined for the application-level protocol used for intelligent consumption accounting. A comparison of the DLMS / COSEM, SML, and IEC 61850 protocols showed that there is no single protocol that is best in all aspects. Analysis and comparison of message size showed that DLMS and MMS IEC 61850 are clearly superior to all others. Both DLMS / COSEM and SML use special encodings for more efficient encoding than BER, but SML Binary Encoding has significant drawbacks when encoding ASN.1 element selection tags. A-XDR does a good job of reducing costs caused by type and length fields.
In the future, it would be interesting to make a similar comparison for such promising protocols as ZigBee Smart Energy 2.0 and ANSI C12.19.
List of references
- E. Commission, “M / 441 EN, standardization mandate to CEN, CENELEC and ETSI in the field of measuring instruments for the development of an open architecture for utility meters involving communication protocols enabling interoperability,” Mar. 2009.
- NIST, “NIST framework and roadmap for smart grid interoperability standards, release 1.0,” 2010.
- DKE, “Die deutsche normungsroadmap E-Energy / Smart grid,” Apr. 2010.
- SP Group, “Smart message language (SML) v. 1.03, ”Dec. 2008.
- “IEC 62056-53 - data exchange for meter reading, tariff and load control - part 53: COSEM application layer,” 2006.
- “IEC 62056-62 - data exchange for meter reading, tariff and load control - part 62: Interface classes,” 2006.
- “IEC 61850-8-1 ed1.0 - communication networks and systems in substations - part 8-1: Specific communication service mapping (SCSM) - mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO / IEC 8802-3, ”May 2004.
- “IEC 61400-25-4 ed1.0 - wind turbines - part 25-4: Communications for monitoring and control of wind power plants - mapping to communication profile," 2008.
- KD Craemer and G. Deconinck, “Analysis of state-of-the-art smart metering communication standards,” Leuven, 2010.
- S. Mohagheghi, J. Stoupis, Z. Wang, Z. Li, and H. Kazemzadeh, “Demand response architecture: Integration into the distribution management system,” in Smart Grid Communications (SmartGridComm), 2010 First IEEE International Conference on, 2010 , pp. 501-506.
- A. Zaballos, A. Vallejo, M. Majoral, and J. Selga, “Survey and performance comparison of AMR over PLC standards,” Power Delivery, IEEE Transactions on, vol. 24, no. 2, pp. 604-613, 2009.
- T. Otani, “A primary evaluation for applicability of IEC 62056 to a Next-Generation power grid,” in Smart Grid Communications (Smart-GridComm), 2010 First IEEE International Conference on, 2010, pp. 67–72.
- S. Feuerhahn, M. Zillgith, and C. Wittwer, “Standardized communication of Time-of-Use prices for intelligent energy management in the distribution grid,” in VDE Kongress 2010 - E-Mobility, Leipzig, Germany, Nov. 2010.
- SyMProjectGroup, “SyM - general specification for synchronous modular meters,” Oct. 2009.
- VDE, “Lastenheft MUC - multi utility communication, version 1.0,” May 2009.
- “IEC 62056-47 - data exchange for meter reading, tariff and load control - part 47: COSEM transport layers for IPv4 networks,” 2006.
- “IEC 61850-7-410 ed1.0 - communication networks and systems for power utility automation - part 7-410: Hydroelectric power plants - communication for monitoring and control,” Aug. 2007.
- “IEC 61400-25-2 ed1.0 - wind turbines - part 25-2: Communications for monitoring and control of wind power plants - information models,” Dec. 2006.
- “IEC 61850-7-420 ed1.0 - communication networks and systems for power utility automation - part 7-420: Basic communication structure - distributed energy resources logical nodes," Oct. 2009.
- “IEC / TS 62351-1 ed1.0 - power systems management and associated information exchange - data and communications security - part 1: Communication network and system security - introduction to security issues," May 2007.
- “OpenMUC - software platform for energy gateways,” www.openmuc.org , 2011. [Online]. Available: www.openmuc.org
- “IEC 61334-6 - distribution automation using distribution line carrier systems - part 6: A-XDR encoding rule,” 2000.