Comparison of DLMS / COSEM, SML and IEC 61850 communication protocols for smart metering applications
Communication technologies are 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 smart metering of consumption. The following protocols are considered: DLMS / COSEM, SML (Smart Message Language), as well as MMS and SOAP mapping of IEC 61850. This paper focuses on the use of these protocols in conjunction with the TCP / IP stack. The protocols are first compared against quality criteria, for example, the ability to synchronize time, etc. After that, the size of messages is compared and the coding efficiency is analyzed.
AMI (Advanced metering infrastructure) is an integrated system of intelligent metering devices, communication networks and data management systems, which includes two-way communication between the service provider and the consumer.
The number and size of AMI systems is growing rapidly. They consist of smart metering devices that are located in homes and that have two-way communication with the service provider. The introduction of such systems is mainly related to 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 on intelligent networks [2, 3]. But so far, most of the installed AMI equipment uses proprietary protocols that do not meet 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 reduce the cost of equipment.
This article compares four different application-level protocols used for smart metering. These are the SML protocol ( Smart Message Language, IEC 62056-58 Draft ) [4], DLMS / COSEM ( IEC 62056-53 [5] and IEC 62056-62 [6]), as well as MMS [7] and SOAP [8] display for IEC 61850 standard.
')
Previously, protocols for smart metering have already been analyzed from various points of view. Thus, in [9], a general overview of the most common protocols for smart metering of consumption at all levels is presented. In [11], the DLMS / COSEM is compared with IEC 60870-5-104. A detailed analysis of the DLMS / COSEM is given in [12]. This article for the first time compares the DLMS / COSEM, SML and IEC 61850 protocols in terms of quality criteria and coding efficiency.
The article is organized as follows. The second section discusses the general network topologies used in the field of smart metering of consumption. Indicates 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 in question. Conclusion is the conclusion.
To organize communications in AMI systems use different network topologies. However, most topologies can be obtained from the general form shown in Figure 1 . In this figure, gas, electricity, water and heat meters are connected to the so-called "house gateway", through which the interface to the outside world is realized. In most cases, this gateway is actually integrated into the meter. It should be noted that gas, water and heat meters are special in the sense that they are mainly powered by independent sources. This feature should be taken into account when selecting communication protocols for line ( b ). The gateway (or electricity metering device) can connect to the data collection system on the side of the service provider either directly via the Internet connection ( s ) or through a data hub ( d and e ) - where d is usually either a power line or a wireless solution radius of action.
Figure 1 - Communication topology for intelligent metering of consumption
The application layer protocols discussed in this article can use the TCP / IP protocol stack for data exchange; therefore, they are suitable for communication via an Internet connection ( with and e ), and can also be used for data exchange in 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, such as IEC 61334-5. SML supports data exchange over serial line and M-Bus protocol. MMS and SOAP do not support additional lower layer protocols.
This section describes the qualitative criteria by which protocols will be analyzed and compared in the fourth section.
Application layer protocols used for smart metering of consumption can be compared against their support for the transfer of information of various types. 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 this case, the connection or association is established only by the client. The server represents the device that stores the metering data (for example, the metering device itself), and the client is the 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, the two objects between which information is transferred have equal opportunities. At any time, an object can play the role of a client or server. This principle allows a more flexible use of the protocol, as metering devices have the ability to send data to other devices without the need for a client to establish a connection.
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 ( for example , metering device). This model is built using an object-oriented approach and acts as a visible information interface for the client. The client can extract 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 extracted interface object model simplifies the data exchange mechanism, in the sense that the client can be programmed to automatically correspond to different 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 in terms of the security of AMI systems. The protocol may have built-in security mechanisms, for example, encryption, or it may leave this procedure for lower layer 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 great work on the standardization of smart metering of consumption [15]. Until now, SML is rarely used outside of Germany, but this situation may change if efforts to promote the SML protocol as an international standard are successful. Nevertheless, it will be useful to compare the international standards DLMS \ COSEM and IEC 61850 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 access services to it. SML, to define the hierarchical structure of messages, uses a form similar to ASN.1. Messages are encoded with a special code that will be considered in the fifth section. There may be two types of messages, or a request, or a response. However, a “reply” 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 their associated digital signatures. In addition, it is possible to transfer a new firmware image and synchronize the clock, however these procedures are described in other standards ( for example , [14]).
SML does not have built-in security mechanisms with the exception of simple “username” and “password” fields in SML messages. SSL / TLS can be used to transmit data over TCP / IP.
The 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], the DLMS / COSEM can be used to transmit data via TCP / IP and UDP / IP.
DLMS / COSEM is based on a strict 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 establishing the association, the DLMS client can access the interface object model located in the server. Once the association is 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 transfer of digital signatures along with the measurement data, and also does not support downloading a new firmware version. However, this functionality will be supported in the future. Already, there are objects for carrying out the operation of updating the firmware described in Blue Book 10 of the editors. Digital signatures support is under construction, this is the responsibility of the DLMS UA organization.
DLMS / COSEM includes authentication and privacy services based on symmetric encryption. However, this protocol does not support TLS / SSL, which could be used to implement the above-mentioned services using an asymmetric key. Support for asymmetric encryption is under development, and the second working group of the thirteenth technical committee of the CENELEC organization is working on this.
The MMS and SOAP mapping of IEC 61850 does not differ in terms of supporting the qualitative criteria that are considered in this paper. Therefore, all of the following will be true for both protocols.
IEC 61850 is a group of standards developed specifically for use in substation automation. The standard has now been expanded, and now it covers 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 standards used for commercial accounting. IEC 61850 is used where there are no commercial accounting requirements. This distinction between commercial accounting and other types of accounting seems to be more political than technical. There are no technical reasons not to use IEC 61850 as a protocol for commercial accounting.
IEC 61850 works on the same principles of the client-server architecture as DLMS / COSEM. The server contains an interface object model that is available through standardized services. How exactly the transmission of these services will take place depends on which mapping is used (for example, MMS or SOAP).
The IEC 61850 interface object model consists of freely composable logic devices (LD). Logical devices consist of one or more logical nodes (LN). IEC 61850-7-4, for measurement, defines the MMRT logic 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. For time synchronization, both MMS and SOAP mapping use SNTP protocol.
When an MMS mapping is used, the server can send data without an explicit request, via 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 any 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 the interface object model, and thus this protocol does not emphasize standardization at the functional level. On the one hand, this gives more flexibility in the use of the protocol, on the other, means that the details (for example, the message types supported by the devices) must be defined in other standards in order to guarantee interoperability. SML is the only protocol that supports digital signatures.
Table 1 - Comparison of SML, DLMS / COSEM and IEC 61850 Protocols
DLMS / COSEM has the advantage over SML because 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 security-related functionality is limited only to the use of encryption with a symmetric key. If metering devices combined their measurement results with digital signatures, one way or another, they would need asymmetric keys and could use the same key pairs for SSL / TLS, if it were allowed.
Compared to other standards, IEC 61850 can be used not only for smart metering of consumption, but also for other intelligent network applications. However, at present, there is not enough interest to make this protocol more functional for smart metering applications.
In the previous section, the protocols were analyzed regarding 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 different types of information using different message structures and different encryption schemes. For this reason, one operation, namely access to the readings of the instantaneous values, was chosen to compare the protocols in the next subsection, after which there is a subsection devoted to different encryption schemes.
Obtaining instantaneous values ​​of measured values ​​is a fundamental operation supported by all protocols. For this reason, this operation was chosen as the basis for comparison.
First we give a description of the mechanism for obtaining evidence from metering devices for each protocol, and then compare the size of their messages. The four protocols under consideration 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 size of the TCP SDU ( Service Data Unit ) is calculated depending on the number of requested measured values. Several parameters in the request and response messages have a variable length. For this reason, the parameters with the shortest long are always selected. In addition, using the protocols in question, you can request a sufficiently large amount of data. Therefore, in order to compare the protocols, a query for the measurement values ​​in the form of four bytes of integers will be considered. The packet size is determined in part from the implementation of the actual communication protocols [21] and traffic capture, and also partially using analytical models.
For SML, the size of the TCP SDU of the 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 no pre-parameterized parameters, the size of GetListReqPDU in bytes for transmitting x values ​​using the SML Binary Encoding 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
The composition and size of the 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)
The composition and size of the 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)
The composition and size of the TCP SDU SOAP:
SOAP Req = SOAP Header + SOAP Req XML = 197 + 236
SOAP Res = SOAP Header + SOAP Res XML = 113 + (175 + 32x)
The resulting message sizes are shown in table 2 . In addition, the size of the response message is shown as a graph in Figure 2 . This figure shows that DLMS and MMS are the most efficient protocols in terms of message size. However, it should not be forgotten that the DLMS and IEC 61850 require an association in order to exchange messages. The SML protocol does not require an association. The overhead costs associated with establishing an association were not taken into account for these calculations. However, they can be neglected if the association is established once and maintained for a long period of time.
Table 2 - The size of the TCP data field 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 the encodings directly.
The MMS protocol uses ASN.1 BER encoding to encode messages. DLMS / COSEM also uses BER encoding for association messages, but after establishing an association, special encoding rules are used, the so-called A-XDR, defined in [22]. A-XDR rules have been developed to reduce the amount of information compared to BER and apply only to the encoding of the ASN.1 subset. The SML protocol, in turn, also defines new encoding rules called SML Binary Encoding. The goal is still the same as that of A-XDR - reducing the size of a message 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, when available, the type and length are encoded in one byte. In A-XDR, the fields of value types and length are generally omitted where possible.
The three considered binary encodings are compared by encoding the GetDataValues ​​MMS response message. Table 3 shows the number of bytes required to encode the various components of an MMS message.
Table 3 - Comparison of message lengths with different encodings (in bytes)
As shown in Table 3, A-XDR requires the least amount of bytes to encode a packet. A-XDR encodes as efficiently as BER, and in some cases, with the exception of unselected additional fields, even better. SML Binary Encoding does not encode with the least number of bytes for all cases. This is due to the fact that 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 for the application-level protocol used for smart metering of consumption were identified. 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 the size of the message showed that the 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, however SML Binary Encoding has significant drawbacks when encoding tags for the selection of ASN.1 elements. A-XDR does a good job of reducing the costs caused by type and length fields.
In the future, it would be interesting to make a similar comparison for promising protocols such as ZigBee Smart Energy 2.0 and ANSI C12.19.
AMI (Advanced metering infrastructure) is an integrated system of intelligent metering devices, communication networks and data management systems, which includes two-way communication between the service provider and the consumer.
I. Introduction
The number and size of AMI systems is growing rapidly. They consist of smart metering devices that are located in homes and that have two-way communication with the service provider. The introduction of such systems is mainly related to the achievement of the following three goals:
- Providing consumers with information about their consumption and costs, thus contributing to more economical use of resources;
- Redistribute resource use from periods of high load to periods of low load.
- Creating an infrastructure that can be readily used by other intelligent network applications in distribution networks.
Communication in smart metering devices is the subject of several standardization works ( for example, [1]) and part of national roadmaps on intelligent networks [2, 3]. But so far, most of the installed AMI equipment uses proprietary protocols that do not meet 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 reduce the cost of equipment.
This article compares four different application-level protocols used for smart metering. These are the SML protocol ( Smart Message Language, IEC 62056-58 Draft ) [4], DLMS / COSEM ( IEC 62056-53 [5] and IEC 62056-62 [6]), as well as MMS [7] and SOAP [8] display for IEC 61850 standard.
')
Previously, protocols for smart metering have already been analyzed from various points of view. Thus, in [9], a general overview of the most common protocols for smart metering of consumption at all levels is presented. In [11], the DLMS / COSEM is compared with IEC 60870-5-104. A detailed analysis of the DLMS / COSEM is given in [12]. This article for the first time compares the DLMS / COSEM, SML and IEC 61850 protocols in terms of quality criteria and coding efficiency.
The article is organized as follows. The second section discusses the general network topologies used in the field of smart metering of consumption. Indicates 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 in question. Conclusion is the conclusion.
Ii. Communication topology of intelligent metering systems
To organize communications in AMI systems use different network topologies. However, most topologies can be obtained from the general form shown in Figure 1 . In this figure, gas, electricity, water and heat meters are connected to the so-called "house gateway", through which the interface to the outside world is realized. In most cases, this gateway is actually integrated into the meter. It should be noted that gas, water and heat meters are special in the sense that they are mainly powered by independent sources. This feature should be taken into account when selecting communication protocols for line ( b ). The gateway (or electricity metering device) can connect to the data collection system on the side of the service provider either directly via the Internet connection ( s ) or through a data hub ( d and e ) - where d is usually either a power line or a wireless solution radius of action.
Figure 1 - Communication topology for intelligent metering of consumption
The application layer protocols discussed in this article can use the TCP / IP protocol stack for data exchange; therefore, they are suitable for communication via an Internet connection ( with and e ), and can also be used for data exchange in 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, such as IEC 61334-5. SML supports data exchange over serial line and M-Bus protocol. MMS and SOAP do not support additional lower layer protocols.
Iii. Qualitative criteria
This section describes the qualitative criteria by which 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 against their support for the transfer of information of various types. For AMI systems, as a rule, communication technologies are needed to transfer the following types of information:
- Measurement results . Naturally, all the considered protocols support the transmission of measured data (energy, power, voltage, volume, etc.). But the protocols can differ in their support of such types of information as:
- Load profiles The metering device can store load profiles ( for example , with a resolution of 15 minutes). Therefore, the protocols should be able to transfer these profiles, if necessary with appropriate time stamps;
- Digital Signature . Measurement results can be signed with digital signatures 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 are promptly switched, based on a schedule, between tariff registers.
- Firmware Update . Since gateways or metering devices, as well as their communication modules are becoming more and more complex, the function of remote firmware update looks quite useful, allowing to correct errors or add new functionality.
- Information about the cost . The transfer of cost information can be implemented in several ways. An analysis of various approaches to the transfer of tariffs and a comparison of the protocols was made in [13]. This article does not analyze the protocols for their tariff support.
B. The possibility of proactive transfer
Application layer protocols can follow the strict client-server principle; in this case, the connection or association is established only by the client. The server represents the device that stores the metering data (for example, the metering device itself), and the client is the 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, the two objects between which information is transferred have equal opportunities. At any time, an object can play the role of a client or server. This principle allows a more flexible use of the protocol, as metering devices have the ability to send data to other devices without the need for a client to establish a connection.
C. The presence 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 ( for example , metering device). This model is built using an object-oriented approach and acts as a visible information interface for the client. The client can extract 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 extracted interface object model simplifies the data exchange mechanism, in the sense that the client can be programmed to automatically correspond to different 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 in terms of the security of AMI systems. The protocol may have built-in security mechanisms, for example, encryption, or it may leave this procedure for lower layer 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 great work on the standardization of smart metering of consumption [15]. Until now, SML is rarely used outside of Germany, but this situation may change if efforts to promote the SML protocol as an international standard are successful. Nevertheless, it will be useful to compare the international standards DLMS \ COSEM and IEC 61850 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 access services to it. SML, to define the hierarchical structure of messages, uses a form similar to ASN.1. Messages are encoded with a special code that will be considered in the fifth section. There may be two types of messages, or a request, or a response. However, a “reply” 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 their associated digital signatures. In addition, it is possible to transfer a new firmware image and synchronize the clock, however these procedures are described in other standards ( for example , [14]).
SML does not have built-in security mechanisms with the exception of simple “username” and “password” fields in SML messages. SSL / TLS can be used to transmit data over TCP / IP.
B. DLMS / COSEM
The 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], the DLMS / COSEM can be used to transmit data via TCP / IP and UDP / IP.
DLMS / COSEM is based on a strict 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 establishing the association, the DLMS client can access the interface object model located in the server. Once the association is 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 transfer of digital signatures along with the measurement data, and also does not support downloading a new firmware version. However, this functionality will be supported in the future. Already, there are objects for carrying out the operation of updating the firmware described in Blue Book 10 of the editors. Digital signatures support is under construction, this is the responsibility of the DLMS UA organization.
DLMS / COSEM includes authentication and privacy services based on symmetric encryption. However, this protocol does not support TLS / SSL, which could be used to implement the above-mentioned services using an asymmetric key. Support for asymmetric encryption is under development, and the second working group of the thirteenth technical committee of the CENELEC organization is working on this.
C. IEC 61850
The MMS and SOAP mapping of IEC 61850 does not differ in terms of supporting the qualitative criteria that are considered in this paper. Therefore, all of the following will be true for both protocols.
IEC 61850 is a group of standards developed specifically for use in substation automation. The standard has now been expanded, and now it covers 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 standards used for commercial accounting. IEC 61850 is used where there are no commercial accounting requirements. This distinction between commercial accounting and other types of accounting seems to be more political than technical. There are no technical reasons not to use IEC 61850 as a protocol for commercial accounting.
IEC 61850 works on the same principles of the client-server architecture as DLMS / COSEM. The server contains an interface object model that is available through standardized services. How exactly the transmission of these services will take place depends on which mapping is used (for example, MMS or SOAP).
The IEC 61850 interface object model consists of freely composable logic devices (LD). Logical devices consist of one or more logical nodes (LN). IEC 61850-7-4, for measurement, defines the MMRT logic 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. For time synchronization, both MMS and SOAP mapping use SNTP protocol.
When an MMS mapping is used, the server can send data without an explicit request, via 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 any 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 the interface object model, and thus this protocol does not emphasize standardization at the functional level. On the one hand, this gives more flexibility in the use of the protocol, on the other, means that the details (for example, the message types supported by the devices) must be defined in other standards in order to guarantee interoperability. SML is the only protocol that supports digital signatures.
Table 1 - Comparison of SML, DLMS / COSEM and IEC 61850 Protocols
DLMS / COSEM has the advantage over SML because 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 security-related functionality is limited only to the use of encryption with a symmetric key. If metering devices combined their measurement results with digital signatures, one way or another, they would need asymmetric keys and could use the same key pairs for SSL / TLS, if it were allowed.
Compared to other standards, IEC 61850 can be used not only for smart metering of consumption, but also for other intelligent network applications. However, at present, there is not enough interest to make this protocol more functional for smart metering applications.
V. Analysis of effectiveness
In the previous section, the protocols were analyzed regarding 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 different types of information using different message structures and different encryption schemes. For this reason, one operation, namely access to the readings of the instantaneous values, was chosen to compare the protocols in the next subsection, after which there is a subsection devoted to different encryption schemes.
A. Access to instantaneous readings
Obtaining instantaneous values ​​of measured values ​​is a fundamental operation supported by all protocols. For this reason, this operation was chosen as the basis for comparison.
First we give a description of the mechanism for obtaining evidence from metering devices for each protocol, and then compare the size of their messages. The four protocols under consideration use the following methods to access instantaneous readings:
- SML defines a GetList message to get instantaneous values ​​of measured values. The request message contains the names of the parameters or parameter lists to be read. The response contains the requested list of values. Two scenarios will be analyzed:
- The SML metering device or gateway is pre-parameterized with a list of parameters that should be read together. Thus, in order to get all the parameters / values ​​associated with the list name, it is enough to send the name of this list to the server.
- 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 to get instant readings. Get-Request may contain a list of so-called COSEM Attribute Descriptors, uniquely identifying the exact parameters that must 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 dataset containing an arbitrary number of data points can be created dynamically. Subsequently, the data set can be obtained quite effectively 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 size of the TCP SDU ( Service Data Unit ) is calculated depending on the number of requested measured values. Several parameters in the request and response messages have a variable length. For this reason, the parameters with the shortest long are always selected. In addition, using the protocols in question, you can request a sufficiently large amount of data. Therefore, in order to compare the protocols, a query for the measurement values ​​in the form of four bytes of integers will be considered. The packet size is determined in part from the implementation of the actual communication protocols [21] and traffic capture, and also partially using analytical models.
For SML, the size of the TCP SDU of the 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 no pre-parameterized parameters, the size of GetListReqPDU in bytes for transmitting x values ​​using the SML Binary Encoding 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
The composition and size of the 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)
The composition and size of the 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)
The composition and size of the TCP SDU SOAP:
SOAP Req = SOAP Header + SOAP Req XML = 197 + 236
SOAP Res = SOAP Header + SOAP Res XML = 113 + (175 + 32x)
The resulting message sizes are shown in table 2 . In addition, the size of the response message is shown as a graph in Figure 2 . This figure shows that DLMS and MMS are the most efficient protocols in terms of message size. However, it should not be forgotten that the DLMS and IEC 61850 require an association in order to exchange messages. The SML protocol does not require an association. The overhead costs associated with establishing an association were not taken into account for these calculations. However, they can be neglected if the association is established once and maintained for a long period of time.
Table 2 - The size of the TCP data field 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 the encodings directly.
The MMS protocol uses ASN.1 BER encoding to encode messages. DLMS / COSEM also uses BER encoding for association messages, but after establishing an association, special encoding rules are used, the so-called A-XDR, defined in [22]. A-XDR rules have been developed to reduce the amount of information compared to BER and apply only to the encoding of the ASN.1 subset. The SML protocol, in turn, also defines new encoding rules called SML Binary Encoding. The goal is still the same as that of A-XDR - reducing the size of a message 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, when available, the type and length are encoded in one byte. In A-XDR, the fields of value types and length are generally omitted where possible.
The three considered binary encodings are compared by encoding the GetDataValues ​​MMS response message. Table 3 shows the number of bytes required to encode the various components of an MMS message.
Table 3 - Comparison of message lengths with different encodings (in bytes)
As shown in Table 3, A-XDR requires the least amount of bytes to encode a packet. A-XDR encodes as efficiently as BER, and in some cases, with the exception of unselected additional fields, even better. SML Binary Encoding does not encode with the least number of bytes for all cases. This is due to the fact that 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 for the application-level protocol used for smart metering of consumption were identified. 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 the size of the message showed that the 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, however SML Binary Encoding has significant drawbacks when encoding tags for the selection of ASN.1 elements. A-XDR does a good job of reducing the costs caused by type and length fields.
In the future, it would be interesting to make a similar comparison for promising protocols such as ZigBee Smart Energy 2.0 and ANSI C12.19.
Bibliography
- E. Commission, “CENELEC” and “CENELEC”, “Mar. 2009
- NIST, “NIST Framework 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 - tariff control - part 53: COSEM application layer,” 2006.
- “IEC 62056-62 - intercom meter reading, tariff and load control - part 62: Interface classes,” 2006.
- “IEC 61850-8-1 ed1.0 - communication networks and subsystems - 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: Mapping to communication profile,”
- 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, “Degree response architecture: Integration into the distribution system,” in Smart Grid Communications (2010), 2010 , pp. 501–506.
- A. Zaballos, A. Vallejo, M. Majoral, and J. Selga, “AMR over PLC standards, Power Delivery, IEEE Transactions on, vol. 24, no. 2, pp. 604-613, 2009.
- T. Otani, “Next-Generation Power Grid,” for Smart GridComm, 2010 First IEEE International Conference on, 2010, pp. 67–72.
- S. Feuerhahn, M. Zillgith, and C.Wittwer, “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.
- “COSEM transport layers for IPv4 networks,” 2006.
- “IEC 61850-7-410 ed1.0 - communication networks and power engineering automation systems - 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 power plants - information models,” Dec. 2006
- “IEC 61850-7-420 ed1.0 - communication networks and systems for power automation automation systems - part 4-420: 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.
Source: https://habr.com/ru/post/305048/
All Articles