The need for a more sustainable energy system is leading to more electric energy generation being connected to low voltage (LV) distribution grids. At the same time, due to accelerated growth in electric mobility and heat pumps, more and more energy consumed by end customers is supplied via LV distribution grids. These developments cause distribution networks to become less predictable and make them subject to much higher changes in supply and demand. Therefore, additional flexibility will be needed to keep such systems operating with high quality of service. The required flexibility could be provided by distributed generators as well as flexible loads. This leads to the question of how these flexibilities can be activated by distribution system operators when needed. A digital interface between distribution system operator and device operator could be implemented to communicate flexibility requirements. In this work, three possible deployment scenarios for such a digital interface are presented. A market review of available standards and commonly implemented communication protocols was conducted to identify potential candidates for the standardization of such an interface.
Notes
F. Bouda and T. I. Strasser are OVE members.
Publisher’s Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
1 Introduction
Bidirectional digital interfaces between grid customers and distribution system operators (DSOs) enable new possibilities to optimize grid usage. A pool of experts centered around Österreichs Energie, the Austrian representation of the energy sector, started working on a bidirectional digital interface for secure communication between DSOs and grid customers in March 2022. The pool consists of more than 50 experts from industrial manufacturers, DSOs, energy suppliers, charge point operators, the regulatory body, and the research area.
In the first project phase in 2022, the project members carried out a broad investigation of the possibilities for a bidirectional digital grid customer interface in Austria. Multiple architectures were developed and described in use cases. The focus was on one use case, where the DSO sends constraints on power values to the grid customer facilities in a grid emergency. This use case is essential for DSOs to be able to allow the connection of additional distributed generators and loads to the grid if the grid is already fully utilized. In order to be able to determine the network bottlenecks, the DSO must install more sensors and intelligence in the network. To avoid or resolve the overload situation, the DSOs are then able to transmit constraints on actual power values to customer facilities. These facilities can be electric vehicle supply equipment (EVSE), heat pumps (HP), photovoltaic (PV) inverters, or stationary electric batteries. In addition to the customer interface, the DSO must also install more sensors in the grid and build up the necessary IT infrastructure.
Advertisement
An analysis of relevant communication protocols for the implementation of the digital interfaces was performed by the AIT Austrian Institute of Technology GmbH, which is described in this work. In addition to the technical considerations, the legal situation was investigated, and suggestions for necessary legal adaptations were developed, such as the definition of “state of emergency” for the grid. The detailed report of the expert pool and the full AIT-study can be found in [22]. In the next project phase in 2023, further security and process requirements will be investigated as a basis for detailed specification of the digital interfaces, their implementation, cost assessment and comprehensive field validation.
The evaluation of communication standards for different application areas in the smart grid domain has been the topic of several studies in the past. From DeBlasio et al. [1] presenting an analysis of standards that are within the scope of the smart grid, to Wargers et al. [2] showing different capabilities of selected standards for unlocking in-home flexibility. As well as that, Palensky et al. [3] have provided an analysis of the most important building automation standards and the most important standards in the power system domain.
Even more interesting to real-world applications of selected standards are governmental bodies going ahead with the selection of standards to unlock flexibility within the customer domain. California has selected IEEE 2030.5 to be the default communication standard [4] for the communication with smart inverters, that are connected to distribution grids there. The official guideline on how to implement the IEEE 2030.5 smart inverter profiles in accordance with Rule 21 has been released by the SunSpec Alliance [5].
The communication standards that were considered in this study were based on these related works as well as input from past projects and expert knowledge of the power system industry.
Advertisement
Section 2 provides an overview of the methodology used in this evaluation as well as an overview of possible deployment scenarios for a customer-level interface. Section 3 provides detailed information on all evaluated standards and protocols. The results are then discussed in Sect. 4, before the work is concluded in Sect. 5 and further work is discussed.
2 Technology evaluation methodology
For the evaluation of the different communication standards for the implementation of a digital DSO customer interface, literature research of different scientific projects, [6, 7] their results, and standard texts were carried out. This approach is well suited to collect and compare known properties of the standards. However, implementation-specific categories can only be partially evaluated by this. For the evaluation of different communication standards, a pre-selection of standards was first made. The selected standards were examined under consideration of several evaluation categories. The categories and their evaluation classifications are explained in more detail in the following paragraphs.
Four different categories were defined with respect to which the standards were to be analyzed. The categories that were selected are General, Operational, and Technology specific categories.
2.1 Evaluation categories
In the following paragraphs, the different categories for the evaluation are outlined, and the most important subcategories are presented in detail.
2.1.1 General categories
For a general evaluation of the standards, several aspects were selected, such as distribution, origin, and available open-source implementations. While the current distribution of certain standards can give a sense of how much a standard is applied in the field, a much more interesting metric for future implementations is the development that can be seen in the distribution of the standard in academia and industry. The values that were assigned to the individual standards were determined from the information that was able to be found in literature as well as through general information on projects and implementations such as California Rule 21 [5].
The origin of a standard is important to consider as it can show for which purpose and from whom a standard was developed. Another important factor for future developments is the availability of open-source implementations that could help spread a standard or technology much more rapidly than when every implementation must be custom-made. If a prominent open-source implementation of a standard exists, it can serve as a reference to test all other implementations against, helping in the quicker development as well.
Table 1
General Categories used for the evaluation
General Categories
Current Distribution
How much the standard is being applied currently in its field
Distribution development
How the distribution of a standard is developing, whether it is being applied more or less over time
Origin – Application
What application the standard/protocol was originally intended and created for
Origin – Organization
What type of organization created the standard/protocol
Open-source implementations
Are there considerable open-source efforts regarding the implementation of this standard/protocol
Table 2
Operative Categories used for the evaluation
Operative Categories
Data Resolution
What resolution of data is the standard/protocol made for
Data Intensity –
Communication
How large are single messages from this standard/protocol
Communication architecture
What communication architecture is followed within the standard/protocol
Manipulatable data size
What size of data can be manipulated using a single message using the standard/protocol
Table 3
Technology-specific Categories used for the evaluation
Technology specific Categories
Extendability –
Communication Partners
How easily extendable a system based on the standard/protocol is, with regards to adding new communication partners
Extendability – Data points
How easily extendable a system based on thestandard/protocol is, with regards to adding new data points
Service and Resource Discovery
Whether the standard/protocol offers some for of asset or resource discovery capabilities
Modernity
How “modern” the communication architecture of the standard/protocol is
Information Technology/Operational Technology
Whether the standard/protocol originated as an IT or OT communication technology
2.1.2 Operative categories
During the operation of a communication system based on a specific protocol or standard, there are several factors that can be considered relevant.
To make the best use of available network resources, which could be limited, the protocol or standard needs to minimize the transmitted message overhead. On the other hand, the standard needs to be able to communicate important information as quickly as needed, therefore offer good time resolution of the transmitted data.
The employed messaging paradigms are different between the different standards and protocols, some being easier to administer for a lot of communication partners than others. No direct evaluation was possible on the basis of the messaging paradigms, ranging from good to bad. The specific messaging paradigms were collected and are presented in the results section.
Another important factor for the control of distributed energy resources (DER) is the amount of data that can be manipulated with a single message, meaning whether the standard has the capabilities to transmit schedules, or whether it is mostly used for single data point manipulations.
2.1.3 Technology-specific categories
The technologies and protocols that make up a communication standard are very important for the implementation of a communication infrastructure that should be used to leverage DER flexibility.
The first category that was investigated is the extendibility of a communication system, based on the technologies that are used in a specific standard, with regards to the integration of further communication partners.
Secondly, it was analyzed how well the underlying data models could be extended, either in future when further stakeholders want to use the same interface, or when additional functionality is needed.
Thirdly it was investigated whether a form of service and/or resource discovery was included in the standard, that could lead to a reduction in the time that is needed for potential system (re-)configurations.
It was analyzed how “modern” the different communication architectures are, both with regards to the employed application layer protocols as well as how widely used the employed communication concepts are. Standards that are based on widely used web-technologies were considered to be more modern than others. This category should provide an idea of how future-prone the communication standards are.
At last, we give an evaluation of whether the standard/protocol comes more from the operational technology (OT) world or the information technology (IT) world. This is important to consider when interfaces connect intelligent electronic devices within different networks, maybe even from different organizations or owners.
2.2 Deployment scenarios for a customer level DSO interface
This section provides information on the potential communication architectures within the scope of this review, as well as the involved stakeholders.
Three different deployment scenarios were considered—an overview is presented in Fig. 1.
Fig. 1
Deployment scenarios for a customer level DSO interface
×
In the first deployment scenario, the communication between DSO and components at the customers’ site is performed by using already existing communication infrastructure channels. In particular, the communication between the aggregator and the customer is already established or will be established between the aggregator and the customer, whereas the communication between the DSO and the aggregator has to be defined (including the interfaces).
The second developed deployment scenario describes the direct control of customer appliances through a central interface that is operated and administered by the DSO directly.
Finally, a deployment scenario was considered that implied a gateway (e.g., separate hardware device or part of existing hardware with additional software functionality) at the customer premises that handles the local connection of customer appliances through a local interface. This gateway device would be managed by the DSO directly and would have access to both, the DSO network (central interface in Fig. 1) as well as the local area network to which all the devices are connected (local interface in Fig. 1).
Not all reviewed communication standards can be considered for all the interfaces in Fig. 1. There are upsides to using an industry standard that is already widely used for the local interface. However, there is no universally adopted standard that is applicable to all domains. This might lead to the necessity of providing different local interfaces for components from different domains (electric vehicle charging, photovoltaics/battery, heat pump, etc.), as all of them have different communication interfaces that are widely used across different equipment manufacturers. The central communication interface, especially in deployment scenario 3, could allow for the introduction of a classical OT protocol that is already widely adopted and well-understood in the DSO domain.
3 Results
The results were gathered from reviewing relevant standard texts from the selected communication standards as well as reviewing some of the work that was found in the literature on the different standards within the scope.
An overview of the different standards can be found in Sect. 3.1. Sect. 3.2 shows tabular overviews of the reviewed category types.
3.1 Reviewed standards
The following passages provide an overview of the results for each of the reviewed standards.
3.1.1 IEC 61850
Originally, the IEC 61850 set of standards was created for the purpose of substation automation by Technical Committee TC57 of the International Electrotechnical Commission (IEC).
The standard is supposed to facilitate communication between intelligent electronic devices (IED) from different suppliers. A concept that applies well to the smart grid. Since its first release, the standard has been extended to provide data models for distributed energy resources (DER) and technical reports have been released on how to integrate DER and electric vehicle (EV) charging infrastructure in an IEC 61850-compliant communication infrastructure [8]. IEC 61850 provides generic application layer-oriented specifications which are being mapped onto different transportation-oriented protocols. The most used application protocol is the manufacturing message specification (MMS) which was originally developed for industrial manufacturing process automation. Other available mappings are XMPP, which is not yet widely adopted, and GOOSE, which is mostly applied for time-critical data transfer in substation environments.
The hierarchical data model provided with the IEC 61850 standard is the most extensive of any of the evaluated standards. The IEC 61850 data model is structured in an object-oriented way, making use of similarities between different device groups. Physical devices can consist of several logical devices (LD), which in turn can consist of several logical nodes (LN), that are then represented by data and data attributes. The data attributes are based on common data classes (CDC), providing even more reusability of concepts throughout the IEC 61850 data model.
Security measures are not part of the IEC 61850 standard, but an extensive list of measures to create secure communication via IEC 61850 is presented in IEC 62351, that provides different cyber security measures.
3.1.2 Modbus TCP/IP
The Modbus protocol was created in the late 1970s for communication with PLCs (programmable logic controllers). It is considered the first fieldbus protocol in the world. Originally developed as a serial protocol it has been mapped over time to Ethernet-based communication; referred to as Modbus TCP/IP.
Many smart devices offer a local interface based on Modbus TCP. Because of this prevalence of Modbus TCP/IP in local control of energy-relevant devices, it could provide a way to reach a lot of devices across several domains and from different vendors.
The simplicity of local APIs implemented with Modbus TCP comes with its own caveats. Especially with regard to cyber security aspects, the Modbus protocol has several drawbacks. The protocol has several vulnerabilities that have been shown in the literature [9].
3.1.3 SunSpec
Originating from the industry consortium SunSpec Alliance, the SunSpec Specification standardizes the structure of Modbus Clients for DER. The communication is commonly based on Modbus TCP, but other modes of Modbus can be used as well [10].
The use of the SunSpec specification for Modbus to provide a way to communicate with devices over a local device interface is widely adopted in the domain of photovoltaic (PV) and battery storage inverters.
The data model used in SunSpec is adopting the IEC 61850 data model for PV and batteries. The data points from this data model are mapped to Modbus registers.
More recently the SunSpec alliance has released a mapping of the data points provided in the Modbus specification to a RESTful API. However, this “web service API” specification has been in “TEST” status since it’s been first published in 2019 [11].
The Modbus version of SunSpec does not include sufficient security measures, as the Modbus protocol itself cannot be considered secure.
3.1.4 IEEE 2030.5
The IEEE 2030.5 originated from the development of the ZigBee Alliance Smart Energy Profile (SEP). The IEEE 2030.5 standard extends upon the SEP version 2.0 and includes extensive data models from IEC 61850 and SunSpec for the integration and control of DER. The application layer communication is based on the very widespread web protocol HTTP. The IEEE 2030.5 is implemented as a RESTful application programming interface (API) [12], therefore, it is based on the internet protocol (IP) and can be routed over any standard IP-based network.
3.1.5 OpenADR (IEC 62746)
OpenADR was created to communicate price changes to customers and to incentivize demand response (DR) for DER. The OpenADR profile specification is part of the OASIS Open Energy Interoperation specification, which was released in 2011 [13].
Since then, the IEC has also adopted OpenADR as an IEC standard [14]. The standard introduces the concept of virtual top nodes (VTN) and virtual end nodes (VEN) that are used to make communication over several organizational levels possible. In this concept, a DSO (here VTN) could issue a limiting profile to several aggregators (VEN), which in turn could act as a VTN themselves when forwarding the information to customers that would act as VEN in this case. OpenADR has been applied to set up grid-friendly electric vehicle charging programs in research projects [15].
The communication is based on HTTP or XMPP on the application layer, and the architecture of VEN and VTN is REST-like. They don’t implement a full RESTful API, but typical HTTP commands can be used to manipulate and inspect data like in a REST API.
Together with the EEBus initiative the OpenADR alliance has put forth a white paper sketching the use of the two protocols to realize a DSO interface for DER in the field [16].
3.1.6 EEBus
The EEBus initiative was started in 2012 after a German Federal Ministry of Economic Affairs and Climate Actions (BMWK) lighthouse project. The initiative includes several manufacturers of energy-relevant devices as well as interest groups and research institutions.
It is intended to create the possibility for cross-domain communication with energy management systems (EMS) using a single communication standard. While there are several applications in research projects [17], no figures could be found on the actual market penetration of EEBus.
The architecture of EEBus is based on WebSockets, allowing full two-way communication channels between EMS and DER [11].
3.1.7 OCPP
The Open Charge Point Protocol (OCPP) targets electric vehicle charging automation. It is widely used by charge point operators (CPOs) for public charging in Europe. Charging stations communicate with the so-called charging station management system via OCPP. The Open Charge Alliance, originated in the Netherlands, developed OCPP [15].
Version 2.0.1 adds additional functions like plug&charge and advanced diagnostics, but in many cases version 1.6 is still in use. Bidirectional charging will be fully supported in version 2.1, which is still under development. Since OCPP 2.0.1 uses the WebSocket protocol and Transport Layer Security (TLS), applications can fulfil state-of-the-art process and security requirements.
While the CPO coordinates EV charging with OCPP, the DSO would most likely use a second, non-domain-specific protocol to inform the CPO about possible grid congestions. Otherwise, the DSO would need to implement multiple domain-specific protocols for other flexible loads or DER. Depending on the application, the second protocol could be e.g., IEEE 2030.5 or OpenADR.
3.1.8 IEC 60870-5
The IEC 60870 suite of standards is generally applicable to process automation in the field of energy systems and is very well established in several areas. The messages that are sent via the IEC 60870 are freely definable and the protocol does not define a data format for specific use cases. Rather the standard defines the way the link layer frames are constructed to allow for different types of data transmission operations.
The first application of the IEC 60870 was the part 5‑101 that focuses on serial communication between the involved partners. At a later stage, the standard was extended to make use of TCP/IP networks and this type of communication was released in part 5‑104.
This part of the standard would allow for communication directly with devices at the customer premises, over IP-based networks.
The IEC 60870‑5 does not include sufficient security measures [18], and additional security measures were released in the IEC 62351 standard, as for the IEC 61850.
3.1.9 DNP3
The DNP3 (Distributed Network Protocol) was created in1993, as a communication protocol between remote terminal units (RTU) and supervisory control and data acquisition (SCADA) systems in an industrial setting. It is a classical OT protocol and does not have many considerations with regards to security in its original release form. The IEC 62351 security measures can be applied to DNP3 as well, to make it usable in combination with modern ICT systems.
3.2 Overview of Evaluation Results
The presented protocols have been evaluated with respect to the aspects mentioned in Sect. 2. Each of the aspects has been summarized in a separate table.
3.2.1 General categories
The results of the analysis for the general categories can be found in Table 4. Old standards such as DNP3, IEC 60870-5-104 or Modbus TCP/IP show a large distribution currently, the applications of these standards tend to decline as new technologies emerge. For DNP3 and IEC 60870-5-104, for example, few open-source implementations exist.
Table 4
General evaluation categories for the communication standards, evaluation scale: ++ very good, + good, ~ adequate, − inadequate
Standard
Distribution
Current
Distribution
Development
Origin
Application
Origin
Organization
Open-Source – Implementations
IEC 61850
+
~
Substation automation, power utility automation
Standardization Organization
+
IEEE 2030.5
+
+
Control of DER
Standardization Organization
−
OpenADR (IEC 62746)
~
+
Incentivizing of DER
Open-Source Initiative
++
EEBus
~
+
Control of DER
Industry
Consortium
−
SunSpec
+
+
Control of DER
Industry
Consortium
+
OCPP 2.0.1
+
+
Control of EV charge equipment
Industry
Consortium
++
DNP3
++
−
Automation
Industry
−
IEC 60870-5-104
++
~
Automation
Standardization Organization
~
Modbus TCP/IP
++
−
Automation
Industry
+
Newer communications standards tend to be better customized to certain use-cases. Looking at OpenADR for example, this standard focuses directly on incentivizing customers and DER to be controlled in a certain way. Offering possibilities for direct control of assets as well as communicating price schedules to let decentralized management systems optimize the DER operation themselves.
3.2.2 Operative categories
The results of the evaluation regarding the operative categories are presented in Table 5.
Table 5
Operational evaluation categories for the communication standard, evaluation scale: ++ very good, + good, ~ adequate, − inadequate
Standard
Data Resolution
Data Intensity – Communication
Communication Architecture
Manipulatable data size
IEC 61850
++
+
Service-based, publish subscribe, Server/client
Single point, profiles
IEEE 2030.5
+
~
REST/REST-like
Single point, profiles
OpenADR (IEC 62746)
+
~
REST/REST-like
Single point, profiles
EEBus
+
+
WebSockets, duplex communication
Single point, profiles
SunSpec
+
+
REST or client pull
Single point
OCPP 2.0.1
+
+
WebSockets, duplex communication
Single point, profiles
DNP3
++
~
Server/client
Single point
IEC 60870-5-104
++
+
Server/client
Single point
Modbus TCP/IP
+
+
Server/client,
client pull
Single point
For the implementation of a customer interface to address in-home flexibilities, the time resolution of the communication is not the most important factor. Some standards, like IEC 61850, offer close to real-time capabilities, which is not necessary for the purpose that is considered within this paper.
Different messaging paradigms are used throughout the investigated standards. IEEE 2030.5 and OpenADR use REST(-like) server/client architecture as a communication architecture, which itself is based on data transmission via HTTP.
EEBus and OCPP use WebSockets to create full duplex communication channels on top of a TCP connection. The data exchanged is standardized and data can be formatted as JSON or XML. IEC 61850 has a service-oriented approach to message exchange. DER units operate IEC 61850 Servers implementing different services that Clients could then use. The IEC 61850 also defines a publish/subscribe pattern for event-based messaging.
Both DNP3 and IEC 60870‑5 both follow the client/server paradigm, with which different messaging patterns could be implemented. On the one hand, this offers flexibility for the implementation, on the other hand, this makes it difficult to streamline over many involved stakeholders and potential implementations.
Modbus TCP/IP, which is also used in SunSpec, also implements a classical Server/Client communication architecture. The communication is usually initiated by the Modbus Client and the server would then executes the respective actions. In the case of DERs, the DER would implement a Modbus Server and a Client would connect to it and modify, read, or write data.
3.2.3 Technology specific categories
The expandability of the system with respect to additional communication partners was found to be very well realizable with all investigated standards and their underlying protocols. As they are all meant to create communication channels between many participating parties, this result is not surprising.
With regards to extendibility of the data models, there is more variability. All the investigated standards offer some way of extending the respective data models, but some are more flexible than others.
IEEE 2030.5 and EEBus offer a way to automatically detect resources and their services, when they are in a common network. This functionality is based on multicast DNS (mDNS) [19], allowing them to detect devices and services without a preconfigured DNS server.
OpenADR, offers the possibility of implementing service discovery on the virtual top node (VTN) side of the communication, using XMPP service discovery functionalities [20].
IEC 61850 provides a standardized format for describing functions and services in the system configuration language (SCL), which can be shipped with devices and then used for automatic service discovery.
Some of the reviewed standards are based on state-of-the-art web technologies, that are very commonly used in IT applications. These standards either require the implementation of REST or WebSockets-based communication architecture. Both REST and WebSockets are based on the HTTP/HTTPS application layer protocol.
Older standards like DNP3 or IEC 60870‑5 use application protocols that are not as widespread and are not considered state of the art in the IT world.
The detailed results regarding the technology specific evaluation categories are shown in Table 6.
Table 6
Technology specific evaluation categories for the communication standards; evaluation scale: + good, ~ adequate, − inadequate
Standard
Extendability Communication partners
Extendability data model
Service and Resource Discovery
Modernity Technology
Information Technology/Operation Technology
IEC 61850
+
+
Service discovery with SCL
−
OT (IT)
IEEE 2030.5
+
+
Service and resource discovery with mDNS
+
IT
OpenADR (IEC 62746)
+
+
Service discovery with XMPP
+
IT
EEBus
+
+
Service and resource discovery with mDNS
+
IT
SunSpec
+
+
No
−
OT (IT)
OCPP 2.0.1
+
~
No
+
IT
DNP3
~
~
No
−
OT
IEC 60870-5-104
+
+
No
−
OT
Modbus TCP/IP
+
+
No
−
OT
4 Discussion
The presented results have shown advantages and disadvantages of the different investigated standards and protocols. It can be difficult to find the best-suited protocol or communication standard to implement a particular solution, but all the reviewed standards can be used to implement parts of a communication infrastructure to control or incentivize DERs.
In general, any of the presented standards and protocols can be used to implement a system capable of communicating grid limitations to an end customer.
Protocols from that originated as OT protocols might be better suited for the implementation of an interface that remains within the network of a single organisation, as would be the case for the central interface in deployment scenario 3. On the other hand, IT technologies might be best suited for the implementation of interfaces that communicate information across several networks, as would be the case for the central interface in the first deployment scenario between DSO and aggregator for example.
Such a convergence between OT and IT systems in the management of modern power systems could prove beneficial in many ways, while opening new challenges, especially regarding cyber security aspects [21].
What purpose the communication really has might influence the choice of one protocol over another. Should additional stakeholders be able to use the communication interface for other purposes than DSOs using the flexibility for the stabilization of the grid? If the interface will only be used by the DSO, and there are no other use cases for the same interface, a classical OT protocol would fit the requirements for the interface best. On the other hand, if the same interface should be used by different stakeholders, an IT protocol might be better suited.
What reaction time is required from the DERs to an activation signal? A system that relies only on flexibility that is activated through this interface, for its stability would have more stringent requirements for the availability and reaction times, than a system where this flexibility activation is used as a last resort or as part of a bigger stabilisation strategy.
Should the communication happen over the public internet, or will there be a network exclusively for the purpose of communication with DER operators? Whenever several networks, that maybe even span over organisational borders, are within the communication chain, standards based on IT protocols, would be better suited.
What number of communication partners will need to be handled, and how much data will need to be transmitted every second? The expected size of the data stream could result in implications on the systems the interface will have to interact with, such as a distribution management system.
Such questions will need to be answered before an informed decision for or against a certain standard can be made for the implementation of a customer-level interface.
5 Conclusion
This work has presented a concise review of available communication standards and protocols in the smart grid domain which could be used to control energy-relevant intelligent devices in the field.
Many different aspects need to be considered when designing a communication system that can transfer information to different stakeholders and across organizational borders.
The deployment scenarios that were presented in Sect. 2.2 show different communication paths that could be selected to realize similar flexibility communication and activation systems. This diversity in options leads to a broad range of possible technologies that could be employed.
When there is a single communication system to realize all deployment scenarios, we see both IT protocols and standards that are based on IT protocols to have an edge on OT technologies, especially when the components are connected to communication networks that are operated by different organizations or owners.
There are many upsides to achieving a large consensus on what protocols or standards should be used for the implementation of such an interface. A widespread standard interface would be beneficial for equipment manufacturers, aggregators, end customers as well as distribution system operators, as all involved stakeholders could benefit from economies of scale.
Regional differences in communication systems used for distributed flexibility activation could generate extensive interoperability issues.
Next steps in creating a standardized customer interface include validation of standard and/or protocol combinations in simulative studies before moving on to field trials with appropriate solutions. As the communication system will interact with critical infrastructure, extensive cyber security analysis will have to accompany all developments towards a reference architecture.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
Publisher’s Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
