Plain language summary
Interoperability is the ability of two systems to exchange information with each other (technical), to understand it (informational) and to interpret and integrate it purposefully into business functions and processes (organizational). In a distributed system of systems, such as the Smart Grid, it is logistically not possible for each system to coordinate with each other in regard to their respective interfaces, as this would lead (in a worst-case scenario) to an (design and development) complexity of N x M interfaces.
The integration of new systems would thus result in a multitude of individual projects with excessive costs in Capex and Opex. Therefore, standards, that enable collaboration or so-called interoperability without friction caused by individual integration projects, are crucial. Although a large number of such standards already exist in the energy sector, the realization of interoperability often remains a challenge. To identify new opportunities and potentials and thus support and improve the interoperability of future initiatives, this article compares different methods that are used to achieve interoperability in the energy domain.
Introduction to interoperability improvement
The decarbonisation of energy supply drives the decentralization of energy production and therefore the need for digitalization of the energy sector. This leads to an integrated System-of-Systems where ICT systems and smart devices from various stakeholders with heterogeneous systems have to interact seamlessly and reliably with each other in order to provide a stable power supply. Consequentially, one of the main challenges is to enable and to secure long term interoperability between the (digital) systems in Smart Grids.
Motivation and problem statement
Following the classification of systems given by Haberfellner et al.1, the electric power grid evolves from a massively interconnected system into a complex system2. While the traditional power grid, as a massively interconnected system, is characterized by a certain level of diversity, variety and scale, the Smart Grid as a complex system is additionally characterized by a dynamic/alterable structure1,2. As a consequence, the traditional engineering paradigms can no longer be applied effectively and efficiently and the necessity for standardization becomes increasingly crucial as the system becomes more dynamic3. These additional dynamics imply that the System-of-Systems as a whole requires the capability to reorganize or reconfigure its structure and, therefore, to build and destroy links between the constituent systems dynamically4. Such capability, however, can only be realized by appropriate standards that facilitate seamless integration and reduce the distance for integration5.
Most of these systems, however, were never designed to be integrated. The different domains and heterogeneous systems along the energy conversation chain as well as the different levels of their automation chains are characterized by different requirements, understanding of the problem and, therefore, preferred solutions6. As a consequence, interfaces are traditionally negotiated between the communicating systems based on their specific requirements, leading to proprietary solutions. Proprietary solutions, however, may work fine for their specific requirements, but prevent the (seamless) integration of additional systems7, necessitates individual integration and maintenance efforts and increases the overall complexity of the System-of-Systems8. As a result, the unnecessary high integration costs are slowing down progress and spread of smart technologies within the energy sector due to the often insufficient interoperability and interchangeability of digital systems from various vendors5,9. As Figure 1 illustrates, the distance to integrate decreases with the degree of standardization. Moreover, as sustainable Smart Grid solutions will have to cope with the integration of an unpredictable amount of heterogeneous systems in the foreseeable future, the ability for seamless integration and plug-and-play mechanisms will become indispensable. Therefore, reducing the distance to integrate has a direct impact on the integration costs of all future initiatives5. It creates well-defined integration points in a system of automation components and enterprise systems that allow for new automation components and businesses to connect. This can enable one automation component to be substituted or interchanged for another with a reasonable amount of effort; it can also provide a path to upgrade automation components in a localized fashion that preserves overall integrated system operation5. For this reason, the Levels of Conceptual Interoperability Model (LCIM)10, for instance, distinguishes the capability for interoperation of non-homogeneous systems between integratability, interoperability and composability on seven maturity levels.
Figure 1. Distance to integrate, reproduced with permission from 5.
Copyright 2008, GridWise® Architecture Council (GWAC).
In order to embrace the capability for seamless integration, the individual systems require a common understanding on the technical (syntax), informational (semantics) and the organizational (pragmatics) level. However, although a number of standards have already been established to promote interoperability in the energy sector (e.g. the Common Information Model), these standards alone cannot guarantee practical interoperability. Since standards are usually written in natural language, they can be misinterpreted. Moreover, it cannot be excluded that the standard may be ambiguous, contain gaps or even contain errors and contradictions. Thus, allowing different interpretations and, therefore, implementations of the same standard. As a consequence, it is not uncommon that even if several systems implement the same standard, they are not fully interoperable to each other. For this reason, ordinary compliance tests to the standard are not sufficient. It is mandatory to test the independent systems for their practical interoperability to each other.
Objectives
The main objective of this study is to contribute to the reduction of the distance for integration. Correspondingly, the central question is:
This article will therefore present and discuss various approaches for designing System-of-Systems, different approaches for enabling and verify the ICT-interoperability in Smart Grids and motivate the need for interoperability improvements in the energy sector.
In order to answer this question, this study examines and consolidates how various initiatives and other sectors/domains deal with interoperability issues of digital (ICT) systems and assesses what can be learned from them.
Organization of this paper
Subsequently, different case studies with different approaches, methods and/or practices are presented, compared and analysed in order to get a comprehensive overview. The paper is organized in seven sections as follows:
Introduction and the need for interoperability improvements.
Methodology of the performed case study research.
Background and domain of System-of-Systems in respect to Smart Grids.
Different approaches to realize, document and verify interoperability.
Case studies on how standards are adapted by the industry in order to improve ICT-interoperability.
A comparison and analysis of the various approaches based on the findings of the previous two sections.
A conclusion of all results from theory and practice within a comparative summary and critical appraisal.
Methodology
The case study research was performed in accordance to Yin11. In order to address the traditional concerns over case study research, Yin proposes six phases or steps: plan, design, prepare, collect, analyze and share.
Phase one emphasizes a thorough literature research in order to identify the relevant situation, the research questions and to decide whether the case study is the right method to apply. Accordingly, a literature research was performed first based on the guideline provided by vom Brocke12. However, as the research questions were pre-determined, the aim was a preliminary investigation to assess whether case study research is the right methodology, rather than a rigorous literature review. In essence, eight databases (IEEE, SpringerLink, Emerald, AIS, Informs, ACM, EconBiz and Science Direct) were searched for the terms “Smart Grid” and “Interoperability” within the title and abstract with time period from 2014 to 2020. The general selection criterion was a direct relation to the integration of cross-vendor systems and the associated interoperability issues, challenges and solutions within the electric energy system. The key insights were identified, summarized and presented. The results of the preliminary literature research reflected the initial assumption of interoperability related issues and associated opportunities that makes the case study research as a comparative approach an appropriate choice; as these are especially suitable too answer the “how” questions11. The second phase focuses on the design of the study. Based on the already given research question of “How to improve the interoperability of digital (ICT) systems in the (electric) energy sector?” the path to answer this question needs be determined. For this purpose, the scheme of the Smart Grid Interoperability Maturity Model (SG IMM), that provides appropriate evaluation criteria, was adapted. Based on these evaluation criteria, a schema representing the data to be extracted was developed within the third phase. The schema generally comprises the individual process steps and the associated activities as well as the key characteristics (e.g. applied standards or methodologies) for realizing interoperability under consideration of the different governance areas: management, documentation, integration and testing9. Furthermore, potential case studies are screened and selected during this step. For this purpose, the results of the preliminary literature research were taken into account as well as results from discussions and interviews with domain experts from the ISGAN (International Smart Grid Action Network) initiative. The most important selection criterion for a case study was that the case study does not only describe a concrete integration project, but a generally applicable methodology that facilitates interoperability between the heterogeneous solutions of independent vendors. The fourth steps concerns the general requirements in regard to the so-called sources of evidence that needs to be considered when compiling the data. These sources were enriched within the scope of additional backward research as well as supplementary literature research in terms of referenced standards and publications. The identified sources were then carefully read and the required information manually extracted, taking into account the previously defined criteria. After the study has been designed and executed, the fifth phase deals with the processing and analysis of the results. For an appropriate analysis, all identified dimensions were compared in a matrix. By contrasting the methods already in use with those that exist but are not yet established, a gap analysis can be performed. As a result of this analysis, the current state-of-the-art of the industry can be identified and the currently unrealized potentials (the gaps) and, therefore, future opportunities are highlighted. Finally, all results are composed in accordance to Yin11 and shared within the scope of this contribution.
Background discussions on Smart Grid digitization
The Smart Grid as a System-of-Systems
In order to categorize and highlight the various challenges posed to the engineering of Systems-of-Systems and, subsequently, to the engineering of Smart Grids, there are a number of different classifications, which categorize the System-of-Systems in accordance to the problem under investigation. In this way, the different classifications represent different perspectives and challenges of the same subject. While Haberfellner et al.1 emphasizes the increasing dynamics and heterogeneity, which highlights the need for interoperability and standardization on the technical level, Maier13 distinguishes Systems-of-Systems based on the socio-technical perspective, which implicitly describes why the standardization within Systems-of-Systems becomes increasingly problematic with the increasing dynamics and heterogeneity. Since the engineering of Systems-of-Systems can vary fundamentally in its scope and complexity, Maier distinguishes Systems-of-Systems by the way they are managed and governed, as depicted in Figure 2. Based on Maier’s classification, the overall consent within the discipline of systems engineering is that collaborative Systems-of-Systems, such as the Smart Grid, are the most challenging14–17. Due to the managerial and organizational independence of their constituent systems, these systems are challenged by a so-called wicked problem complexity. With its origin from social planning, these types of problems cannot be solved correctly or wrongly, just good or bad with a reference to a point of view18.
Figure 2. System-of-Systems classification, reproduced with permission from 21.
Copyright 2015, Ian Sommerville.
A solution to a wicked problem depends on how the problem is framed and is always coupled to other problems from different perspectives. In the case of such collaborative System-of-Systems, the System-of-Systems is composed of autonomous and self-sufficient subsystems. These constituent systems are useful systems by their own, having their own development, objectives and resources19. Although the constituent systems are collaborating in order to meet shared goals, they have their own prioritized business objectives accompanied by their own point of view. Consequentially, every system has, due to its operational and managerial independence, its own individual starting point, requirements, understanding of the problem and, thus, preferred solution based on the value it expects to get from the different actions20. However, an acceptable solution for one system will most likely result in an unacceptable result for another system. In consequence, the absence of a central authority and leadership leads to the situation that there is no holistic perspective on the System-of-Systems6,21.
Without a control and evolution mechanism as an adequate standardization4, the interacting constituent systems usually agree upon the lowest common denominator20,22, which eventually leads to a multitude of proprietary solutions, a proliferation of interfaces and, thus, an arbitrary development of the Smart Grid.
Interoperability in Smart Grids
GWAC-Stack. Following the Open Systems Interconnection (OSI) reference model, interoperability is often considered as a mainly technical issue. However, since the OSI reference model was officially introduced as early as 1983 , the main issue and, consequentially, the focus at that time was on technical connectivity and data transmission23. In order to highlight the problems and associated challenges for Smart Grids as a collaborative System-of-Systems beyond technical issues and, thus, to promote the communication and development of common standards, the GridWise® Architecture Council (GWAC) defined the so-called GWAC-Stack (depicted in Figure 3). This framework divides the three levels of interoperability “Technical”, “Informational” and “Organizational” into eight categories and the cross-cutting issues that have to be considered across all interoperability levels.
Figure 3. The GWAC-Stack in accordance, reproduced with permission from 5.
Copyright 2008, GridWise® Architecture Council (GWAC).
Organizational interoperability serves, for example, the integration capability of cross-system business processes and objectives, so that holistic Smart Grid workflows can be interlinked while taking into account the national and international regulatory. This results in the interoperability levels:
Economic/regulatory policy: A shared understanding of political and economic objectives in policies and regulations.
Business objectives: A shared understanding of strategical and tactical business objectives between organizations.
Business procedures: A shared understand the scope and mission of the functions.
Semantic interoperability is required so that messages can not only be transmitted and processed technically, but also be unambiguously understood and adequately processed on the basis of a shared information model which reflects a common meaning and context. This results in the interoperability levels:
Business context: A shared understanding of the information for specific functions/business Use Cases.
Semantic understanding: A shared definition of the structure of the messages and, thus, of the contents and messages that are exchanged.
Technical interoperability defines the basic connectivity and, therefore, the actual communication and serves (in accordance with the seven layers of the OSI reference model) to establish physical and logical connections as well as the data transmission. This includes the interoperability levels:
Syntactic interoperability: A shared understanding of message data structures.
Network interoperability: A standardized mechanism for exchanging messages between multiple systems over different networks.
Basic connectivity: A mechanism for establishing the physical and logical connections between systems.
If not all levels of interoperability are considered equally, this leads to a gap at the syntactic, semantic and/or pragmatic level and consequently to increased integration efforts and a higher error rate.
Smart Grid Interoperability Maturity Model. In accordance to GWAC, in order to achieve interoperability a coordinated process between all parties is required, while improving interoperability requires an additional continuous improvement process and a community culture that is sensitive to interoperability concerns9. Therefore, the GWAC additionally developed the Smart Grid Interoperability Maturity Model (SG IMM)9. Maturity models provide the means to measure status and progress, analyse gaps and prioritize efforts to improve the situation in a continuous improvement cycle. Correspondingly, the SG IMM is intended to provide a means of assessing progress in interoperability in the Smart Grid community and to promote an interoperability-conscious culture with individual and joint roadmaps for improvement.
The SG IMM, thus, takes a holistic System-of-Systems perspective and consolidates the core characteristics that contribute to the improvement of interoperability in a simplified framework. As a result, it can be used to evaluate, assess and compare the cross-organizational interoperability or the maturity of the overall Smart Grid initiative under consideration of the three levels of interoperability (“Technical”, “Informational” and “Organizational”) and their cross-cutting issues.
Based on the collective experience from systems engineers, architects and/or integrators of complex systems, the quality requirements/criteria for the evaluation of the respective maturity levels are consolidated in Table 1.
Table 1. Criteria for assessing level of maturity, reproduced with permission from 9.
Copyright 2011, GridWise® Architecture Council (GWAC).
| Governance |
|---|
| Management | Documentation | Integration | Testing |
|---|
| 1. Initial | • Management is ad hoc | • Documentation is
ad hoc | • Integration is a unique
experience | • Testing is ad hoc |
| 2. Managed | • Management by
project agreement | • Documentation in a
project specification | • Integration is repeatable,
with customization
expected | • Tested in accordance
to a plan with results
captured |
| 3. Defined | • Managed by
community agreement | • References community
standard with some
customization | • Integration is repeatable
with predictable effort | • Tests exist for
community with
certification
• Members claim
compliance to standard |
4. Quantitatively
managed | • Processes ensure
currency and
interoperation | • References a
community standard
w/o customization | • Integration metrics
are defined and
measurements collected
• Reference implementations
exists | • Community test
processes demonstrate
interoperability
• Members claim
interoperable
conformance |
| 5. Optimizing | • Managed by a
community quality
improvement process | • Adopts an open,
community standard | • Integration metrics used
for improvement of the
standard | • Test processes are
regularly reviewed and
improved |
The different dimensions or aspects that are able to improve the interoperability are consolidated for this purpose. A direct comparison of these key concepts shows that the different concepts also address different issues associated with interoperability:
Management: An adequate standardization governance serves the improvement and the overall acceptance of standards. Moreover, an adequate governance prevents the development of proprietary solutions and the consequent arbitrary growth of interfaces.
Documentation: A technology-independent representation of the communicating systems allows a net-centric conceptualization of the overall Smart Grid ICT-architecture, supports the coordination processes between the various actors and facilitates the derivation of implementation strategies (especially requirements and design) for the individual Use Cases.
Integration: Strict, consistent and unambiguous specification of standard-based interfaces at all levels of interoperability to prevent assumptions and misunderstandings during implementation.
Testing: Since standards are partly written in a natural language, misunderstandings cannot be fully prevented. In order to confirm the practical interoperability between two independent systems or implementation, it must be validated under strict test specifications.
State-of-the-art: key concepts to facilitate interoperability
This section examines and documents how standardization activities are organized in different parts of the world, e.g. by the IEC at international level and M/490 to CEN/CENLEC and ETSI at European. The different approaches on how to realize, document and verify interoperability will be presented. The main focus will be particularly on the use of appropriate tools and methodologies, such as the Smart Grid Architecture Model (SGAM) and the IEC 62559-2 Use Case template - since both facilitate interoperability in the energy system.
Additionally, different approaches in other domains will also be presented and compared, e.g. the Healthcare (Integrating the Healthcare Enterprise), Internet of Things (IoT) or Industry 4.0 (Asset Administration Shells) sector.
Standardization and interoperability in Smart Grid
IEC 62559-2 Use Case methodology. Use Cases usually serve as one of the first building blocks for system specification in software and systems engineering processes and provide a sound foundation by facilitating the elicitation, collection, analysis and documentation of requirements. According to ISO/IEC 19505-2:2012, a Use Case is defined as follows:
“A Use Case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.” - ISO/IEC 19505-2:201224
Thus, Use Cases address business-related issues and specify the behaviour within different scenarios (e.g. communication patterns or different outcomes) that the subject can perform in collaboration with one or more actors24.
As the collaboration of multiple autonomous and independent subsystems represents a central aspect for the realization of Smart Grid-solutions, the overall project managements requires a structured, organised and unified way to describe the various Use Cases of the Smart Grid and its components25. Accordingly, the IEC Syc Smart Energy developed the so-called Use Case methodology which has been specified within the IEC 62559-226. The IEC 62559 Use Case methodology provides a standardized way to describe and specify such relationships. The so-called “Use Case template” provides a general description as well as the means to specify individual contents of the Use Case in more detail, such as the actors, exchanged information objects and further requirements associated to the Use Case. Hence, the Use Case methodology is used to describe the complex energy system solutions of the actors with their different perspectives, to characterize the interactions between the components and, therefore, to prevent interoperability issues between all systems at an early stage25. Thus, by focusing on the different perspectives of a Use Case, the IEC 62559-2 Use Case template promotes a common understanding and, therefore, interoperability between all involved actors.
Interoperability profiles. As most standards tend to allow a certain degree of flexibility in order to remain adaptable for the broad community, it is not uncommon that even if different systems implement the same standard, they are not necessarily interoperable to each other. In addition, a standard can be interpreted in different ways, deliberately adapted to individual requirements or applied in different versions. Correspondingly, the concept of the so-called interoperability profiling serves the development of consistent, unambiguous and strict specifications of the interoperability requirements for a given Use Case27.
Basic Application Profiles (BAP) are based on domain-specific descriptions of basic application functions and are intended to represent a recommended implementation of the substation automation functions defined in IEC 61850. Consequentially, BAPs can be regarded as a subset of the respective standard which strictly and exclusively specifies only mandatory elements by (mainly) adding constraints that must be implemented in order to realize the given Use Case. Furthermore, analogous to the Use Case methodology, multiple independent profiles can be used as building blocks in order to implement other more complex applications by combining them.
While BAPs provide an implementation strategy, the so-called Basic Application Interoperability Profiles (BAIoP) extends this strategy with adequate testing approaches at different levels (e.g. unit, integration, and acceptance tests) which are intended to ensure interoperability. As a consequence, BAIoPs also includes additional information about inter alia the device configuration and test configuration, test cases for the BAPs, specific service descriptions and engineering frameworks for the development of data models and communication infrastructures, which together enable the testing of a proposed system.
Smart Grid Architecture Model. With the aim of identifying gaps in Smart Grid standardization, the Smart Grid Architecture Model (SGAM) was developed by the Smart Grid Coordination Group/Reference Architecture Working Group (SG-CC/RA) within the European standardization mandate M/490 as a holistic perspective on Smart Grid Architectures27. With the main focus on improving the standardization activities and, therefore, on improving the interoperability between the various systems of the electric power supply, the SGAM framework combines the different domains of the physical subdivisions of the energy value chain (based on the NIST Conceptual Model28) with the different zones of the energy management (based on the automation pyramid). By combining the domains and zones of the electric energy system, the resulting (SGAM) plane is able to reflect the entire energy conversation chain of a Use Case, which allows a system-oriented view and mapping of the individual components of the Smart Grid and, thus, holistic analysis of the overall architecture. Additionally, the SGAM framework complements the plane with different perspectives, the so-called interoperability layers (based on the GWAC-Stack9) which are consolidated in a three-dimensional framework as depicted in Figure 4. By representing the interactions between the individual components of a given Use Case, the SGAM is particularly suitable for the representation of the overall Smart Grid architecture and its associated interoperability requirements between the constituent systems. In order to adequately represent the interoperability requirements as defined by the GWAC-Stack while preserving the applicability of the framework, the eight interoperability categories of the GWAC-Stack have been consolidated to the five layers as depicted in Figure 5.
Figure 4. Smart Grid Architecture Model (SGAM), reproduced with permission from 27.
Copyright 2012, European Committee for Standardization (CEN).
Figure 5. Grouping the GWAC-Stack into the SGAM interoperability layers, reproduced with permission from 27.
Copyright 2012, European Committee for Standardization (CEN).
In this way, the SGAM is able to leverage a common understanding of the overall Smart Grid architecture, the responsibilities as well as the communication paths with its associated interfaces and interoperability requirements between all constituent systems. Although the SGAM reduces misunderstandings and their associated interoperability problems, it does not necessarily prevent the development of proprietary solutions. Thus, in order to prevent proprietary solutions and, therefore, to prevent an arbitrary growth (from a System-of-Systems perspective), the so-called IEC 62357 Seamless Integration Reference Architecture (SIA) provides appropriate guidance for decision-makers. The SIA uses broadly established standards and allocates them within the SGAM Framework in accordance with the respective domains and zones they apply to. As a result, if individual components of a Smart Grid are also represented in SGAM, the SIA can be used to derive the recommended standards for the respective components. Moreover, on the basis of analyses of the SGAM model, possible gaps in the ICT architecture, especially in terms of integration/interoperability between systems, can be identified at an early stage, thus enabling an efficient and cost-effective implementation due to facilitating the capability for a seamless integration.
Standardization and interoperability in other domains
Interoperability is not a unique problem of the energy domain. It is a challenging problem in all IT-supported domains, since most legacy IT as well as operational technology systems were originally developed as isolated stand-alone solutions, which now need to be integrated to a larger System-of-Systems. Due to unique general conditions, however, different domains are only comparable to a limited extent. For example, the military capabilities are less dependent on "voluntary" collaboration, due to a certain degree of an overarching governance and authority and, thus, a significantly reduced socio-technical/wicked complexity.
Various other domains, in turn, build on the methodologies provided by the energy sector itself, such as the smart city sector with the Smart City Infrastructure Architecture Model (SCIAM), the maritime sector29 with the Maritime Architecture Framework (MAF) or agricultural sector30 with the Agricultural Architecture Framework (AAF)31.
In a direct comparison, however, two approaches can be identified that could make a decisive contribution to improving interoperability in the energy sector: the Integrating the Healthcare Enterprise (IHE) initiative of the healthcare sector as a pioneer for interoperability issues and the novel concept of the Asset Administration Shells (AAS) of the Industrial Internet of Things (IIoT) sector.
Integrating the healthcare enterprise. The IHE32 is a global non-profit initiative that aims to ensure a secure and coherent transfer of information between the involved IT in the healthcare sector, which is comprised of a variety of unique methods. The first difference compared to other standardization activities or initiatives is that IHE was formed by an association of medical information system manufacturers and, thus, was and is driven by industrial stakeholders. Accordingly, the IHE is not about the development of basic standards but rather about facilitating existing standards and bringing together the various healthcare IT system users and suppliers within a more professional and collaborative environment33. For this purpose, the IHE developed a holistic approach which has since been established within the ISO/TR 28380-1 standard34.
Centrally, this process includes a holistic approach in terms of governance, documentation, implementation and testing35. Accordingly, the IHE follows a community driven approach whereby the domain and technical experts from industry decide which Use Cases are critical.
Based on these Use Cases, the technical experts jointly elaborate the detailed specifications for the respective communications and their various transactions by using only established standards as HL7 and DICOM. For this purpose, the IHE approach relies on the public development and availability of the so-called integration profiles, which are essentially similar to the BAPs of the 61850 standard of the energy sector. In the case of IHE approach, however, these profiles are only one component of their superior technical framework. Technical frameworks are rigorously structured documents which provide a comprehensive informative as well as normative guidance for implementing the defined integration capabilities of a dedicated a business case, so that interfaces can be completely understood, without any restrictions and inconsistencies. Once the technical frameworks are fully specified, they are adapted by the industry.
In order to verify the practical interoperability of the different implementation of the vendors, peer-to-peer tests are carried out at carefully planned and supervised Connectathons. A Connectathon, as a socio-technical methodology, enables a wide range of stakeholders to collaborate agilely during a full week face-to-face. The Use Case driven Integration Profiles, which specify the requirements for the communication process, allow to perform cross-system interoperability tests under real environmental conditions and, moreover, to jointly identify, discuss and eliminate errors on site and in depth. The discrepancies identified in the process serve as feedback to improve the Integration Profiles. By these means, the annual IHE Connectathon provides vendors with a platform to test and verify the interoperability of their systems based on the technical frameworks. The interoperability tests themselves are organized and executed with the support of Gazelle – a dedicated test platform developed by the IHE optimized for interoperability tests36. Analogous to BAIoPs of the 61850 standard, well-defined test processes, communication procedures as well as success and failure scenarios according to the integration profiles are implemented in Gazelle for each Use Case, which serve to test the manufacturers' systems against each other according to the test specification. Finally, the test results of successful participations of the Connectathon are annually published – which system is interoperable to which other system in which Use Case.
Industry 4.0 (I4.0) components and AAS. Although the interoperability-associated challenges of the energy domain are comparable to those of the IIoT, they are not identical due to different general conditions. As, for example, the context or the business case of energy-related systems can be specified upfront. IIoT-related systems, in contrast, are embedded within business cases/processes that are not known in advance. Consequentially, in order to succeed on the market, IIoT-related components require to be composable. In accordance with LCIM10, the composability of a component or a system is the ability to be reused in different configurations in different scenarios in different business cases. Thus, composability is described by LCIM as the highest maturity level of interoperability and can be considered as the equivalence to the capability of seamless integration at a plug-and-play level. To reach this maturity level of interoperability, the concept of I4.0 components was developed.
The essential concept of the I4.0 components and their corresponding AAS is to encapsulate all assets within unified and self-descriptive representation with standardized, secured and controllable interfaces37. These components are able to describe the respective asset in a minimal but sufficient way with respect to their Use Cases. For this purpose, however, AAS focus on the System Use Case (SUC) instead of the Business Use Case (BUC). In reference to SGAM, this means that the business layer remains undefined and the focus is placed on the function layer. The encapsulation of the assets allows a system to remain individual internally but uniform externally. Based on standardization activities, such as the eCl@ss for the specification of master data and semantics, all respective functionalities and properties of a SUC are specified in a technology-independent way38.
From an ICT perspective, there is no difference whether, for example, flexibility is provided by a biogas plant at the prosumer level, a Virtual Power Plant (VPP) at the Distributed Energy Resources (DER) level or by a neighbouring distribution network39. Although all systems realize the same SUC, they are usually not interoperable with the other communication partners without additional integration efforts due to the integration profiles which are based on different BUCs. If these interfaces are harmonized at SUC level, composability of the individual systems could also be achieved. The adaption of such rigorous separation between system and BUCs could improve the quality of interoperability in the long term.
Case studies
This section focuses on international case studies, which describe how standards are adapted by the industry in order to improve ICT-interoperability. For this purpose, the three case studies "Integrating the Energy System Austria", “CIM profiling and proof of interoperability within the scope of CIM interoperability test activities (CIM Connectathons)” and “SGILab des Joint Research Centre (JRC) of the European Commission”, which aim to improve the interoperability in the energy sector, are presented in this section. When selecting the three case studies, it was crucial that these not only describe a concrete integration project, but rather a generally applicable methodology that supports concrete integration projects in improving their interoperability.
For the purpose of comparison, the case studies, their static key characteristics as well as their dynamic process activities are extracted, assessed against the SG IMM maturity requirements presented in Table 1 and then presented in a brief summary.
Case study: Integrating the Energy System (IES) Austria
The objective of the research project “IES Austria – Integrating the Energy System” is the development of a holistic and modular process chain capable of enabling interoperability in the Smart Grid across all development phases - requirements engineering, design, development and testing40. Based on a preliminary analysis of this project, which showed that the IHE approach already addresses the overall process of software and systems engineering, the IES project aimed to adapt the IHE methodology to the energy sector, under consideration of the domain-specific characteristics. A direct comparison revealed that the most significant distinction was the strong focus on the testing phase with the "Gazelle" open-source test machine and the Connectathon as a socio-technical event to validate the practical interoperability between two or more systems within a given Use Case41. Consequentially, the IES successfully developed Smart Grid related technical frameworks, installed and configured a Gazelle test machine instance and also successfully hosted a small scale Connectathon. Now, IES provides a common understanding and a unified framework to develop and reuse solutions for data exchange40.
Table 2 summarizes the four sequential phases of the IES approach, while Table 3 summarizes the facilitated key characteristics under consideration of the SG IMM requirements.
Table 2. Case study: Integrating the Energy System (IES) Austria summarized process and activities (extracted from 42).
| Step | Phase | Activities |
|---|
| 1. | Identify Use Cases where interoperability is an
issue and specify these by identifying system
borders and requirements. | • Assign an interoperability issue to a domain
• Write a business overview
• Describe business functions
• Reuse existing integration profiles where possible |
| 2. | Jointly identify how interoperability issues can
be prevented and specify the requirements
normatively as integration profile. | • Evaluate which standards can be used to fullfil the Use Case requirements
• Specify the process to realize a business function
• Define the actors and transactions
• Draw an actors-transactions diagram
• Specify additional communication and security requirements |
| 3. | Test independent prototype solutions against
each other on annual plugfest and iteratively
improve the integration profile. | • Add test cases, procedures, description and criteria to test environment
• Create and integrate/implement conformity validation tools
• Execute test cases with at least two independent peer vendors
• Validate recorded messages/traces and log evaluated test results |
| 4. | Publish interoperability test results for each
participant/vendor. | • Publish which vendors successfully tested an integration profile
• Get written approval of interoperable implementation |
Table 3. Case study: Integrating the Energy System (IES) Austria summarized key characteristics (extracted from 42).
CIM = Common Information Model, Business Application Interoperability Profile, SGAM = Smart Grid Architecture Model, UML = Unified Modeling Language.
| Management | + Community driven based on industrial interests.
+ Offers process support for the specification of the technical frameworks e.g. through moderated
workshops where users and manufacturers jointly determine the requirements and functionalities.
+ All the specifications / integration profiles are freely accessible online.
+ Integration profiles are continuously improved based on the Connectathon results. | Maturity
(Estimated) |
| 5 |
| Documentation | + Uses public repositories.
+ Uses the IEC 62559-2 Use Case template.
+ Uses SGAM and UML.
+ Uses technical frameworks.
+ Uses only established best practices and standards, which solve Use Case-related interoperability
issues as e.g. CIM or IEC 61850. | 5 |
| Integration | + Publication of integration statement. Such statements tell the customers which specific Use Cases
and integration profiles a given system is designed to support.
+ Reference implementations are used.
- Integration metrics are only used indirectly. | 4 to 5 |
| Testing | + Uses the Gazelle as a testing platform for conformance testing, interoperability testing and
documentation.
+ Hosts of annual recurring Connectathons.
+ Uses rigorous test specifications which are derived from the integration profiles. These are
comparable (but not based on) BAIoPs.
+ Publishes the test results. | 5 |
In addition to the four phases, it should also be recognized that (although not explicitly named as a phase) there is a transition phase or period between phase 2 and 3. This transition envisages a six-month preparation period, which allows the industry to implement the published integration profiles and the test organizers to complete the necessary preparations for the Connectathon42.
Case study: CIM profiling and proof of interoperability within the scope of CIM IOP test activities (CIM Connectathons)
DIN-Connect is an innovation promotion program owned by DIN and DKE as national IEC bodies. It aims to promote innovation using the instruments of normalization and standardization. New standardization projects are to be initiated and innovative research results transferred to the market. Consequentially, the so-called Anwendungsregel (application rules) do not serve the purpose of standardization, but rather the provision of guidelines in accordance with common best practices and standards in order to facilitate industrial adaption43.
The application rule on “CIM Profiling and proof of interoperability within the scope of CIM interoperability test activities at CIM Connectathons”, therefore aimed to adapt and facilitate the learnings from IES with a special focus on CIM and CIM profiling. However, the objective was not to develop a separate approach, but a guideline that integrates the CIM profiling activities appropriately into the overall IES process. Accordingly, the technical frameworks and their integration profiles, which were developed under the guidance of this application rule, can be fully integrated and jointly managed within the scope of IES activities. Table 4 summarizes the four sequential phases of the approach, while Table 5 summarizes the facilitated key characteristics under consideration of the SG IMM requirements.
Table 4. Case study: CIM Profiling and Connectathons summarized process and activities.
BUC = Business Use Case, CIM = Common Information Model.
| Step | Phase | Activities |
|---|
| 1. | Use Case: First of all, BUC have to be identified,
which require communication with other systems
and therefore have an interoperability relevant Use
Case. | • Description of the business scenario and the functions required for
implementation (Business Functions).
• Identification and description of the system boundaries, system context
and requirements.
• Description and specification of the concrete business functions and
the actors involved.
• Specification of the communication processes or transactions required
to implement the business functions. |
| 2. | CIM profile: It must then be specified (and possibly
identified) how the interoperability problem
previously identified in the BUC can be prevented or
eliminated. | • Specification of transaction contents as CIM profile.
• Specification of the transactions as an interoperability profile.
a. Splitting the CIM profile into payloads.
b. Adding CIM headers and technical connection setup.
• Generation of instance data for prequalifying interoperability tests. |
| 3. | Interoperability testing: After the specified
Integration Profiles have been implemented by
several independent systems, interoperability can be
tested in the scope of Connectathons. | • Use Case-based testing of prototypes and the independently
implemented Integration Profiles.
• Specification of test cases and test sequences according to the
Integration Profiles.
• Creation of test cases, procedures, descriptions and criteria within the
test environment. |
| 4. | Test results: The test results of the Connectathon
are to be published for each participant. | • Freely available publication of the interoperability test results of all
participants. |
Table 5. Case study: CIM Profiling and Connectathons summarized key characteristics and information.
CIM = Common Information Model, IES = Integrating the Energy System.
| Management | + Community driven based on industrial interests.
+ Joint identification of interoperability-relevant business Use Cases and functions. | Maturity (Estimated) |
| (4 to 5)* |
| Documentation | + Recommends public repositories.
+ Uses the IEC 62559-2 Use Case template.
+ Uses Technical Frameworks.
+/- Uses only CIM standards based on IEC 61970, IEC 61968 and IEC 62325. | (4 to 5)* |
| Integration | + Reference implementations are used.
+ Expects instance data (of the respective profiles) for automated conformance tests
as pre-qualification. | (4 to 5)* |
| Testing | + Recommends a community driven and rigorous testing process and general
conditions in compliance and within the scope of IES Connectathons. | (4 to 5)* |
Case study: SGILab of the Joint Research Centre (JRC) of the European Commission
The Smart Grid Interoperability Laboratory (SGILab) of the Joint Research Centre of the European Commission44 with locations in Petten (Netherlands) and Ispra (Italia) is a platform to enable interoperability tests for Smart Grid components. This is done in the form of experimental procedures, simulations and emulators according to accepted standards. The SGILab is a hardware laboratory with different storage devices, loads and generators, which map the power grid by means of various simulations and also implement the ICT infrastructure and test new business cases and services. It is also linked to other hardware labs in the Netherlands and Italy (partly with simulators to provide distribution and transmission networks).
The goal of the hardware laboratory is to provide a real-time simulation for the power grid so that hardware tests can be performed to verify that the components can be integrated into the power grid and that they are interoperable. External manufacturers will also be given access to test their products for interoperability.
The JRC SGILab focuses more on the interoperability of technological (hardware/software) implementations according to proposed standards used in conjunction with applicable reference architectures. Table 6 summarizes the six sequential phases of the approach, while Table 7 summarizes the facilitated key characteristics under consideration of the SG IMM requirements.
Table 6. Case study: SGILab summarized process and activities (extracted from 44).
BAIoP = Business Application Interoperability Profile, BAP = Business Application Profile.
| Step | Phase | Activities |
|---|
| 1. | Use Case elaboration: description of
the functionality of physical devices in
the form of Use Cases, which should be
tested in a special case | • Specify the first set of Use Cases that can be performed in the laboratory, based on the
availability of test beds and on the methodology of interoperability testing.
• Selection of the equipment under test: Define a physical device that communicates with other devices.
• Existing repositories should be examined and existing Use Cases selected. |
| 2. | Basic application profiles creation | • Related to the described functionality in the Use Cases BAPs are created, which are used as building blocks to implement a
standard.
• Selecting the standards applicable to the specific profile.
• Profiling of the semantic and syntactic models: specify in detail how a particular standard (or set of standards) is to be used
and which options from the standards are used in which way. |
| 3. | Basic Application Interoperability Profile
creation | • Selection of test cases for the described functionality in relation to the BAPs.
• Developing the BAIoP
• Add the device configuration, the test configuration with communication infrastructure (topology), the BAP related
test cases, the specific capability descriptions and the engineering framework for data modelling (instances) and the
communication infrastructure (topology, communication service mapping)
• Definition of number of BAIoPs based on BAPs possible combinations. |
| 4. | Statistical design of experiments | • By means of Use Cases, BAPs and BAIoPs, test cases are specified for the physical devices, providing step-by-step
instructions for execution.
• In addition, the accompanying test documentation is created.
• Assemble the experiment: the external conditions for the test are analyzed and provided in the laboratory to make the test
results comparable. |
| 5. | Testing | • Conformance testing: The implementation/device in concern is tested against a test tool or a reference implementation of
the respective standard.
• Interoperability testing: verify that implementations actually work and interact effectively to achieve the expected results.
• Simulating or imitating real-world scenarios to detect potential functional or communicational incompatibilities and to
illustrate the effects of a lack of conformity or compatibility. |
| 6. | Statistical analysis of experiments | • Analysis of test results and experiment design.
• The results are documented and the Use Cases, BAPs and BAIoPs are adjusted if inaccuracies or errors are detected during
the tests. |
Table 7. Case study: SGILab summarized key characteristics and information (extracted from 44).
BAIoP = Business Application Interoperability Profile, SGAM = Smart Grid Architecture Model, SGILab = Smart Grid Interoperability Laboratory, UML = Unified Modeling Language.
| Category | Key methodologies and characteristics | Maturity
(Estimated) |
|---|
| Management | + Uses public repositories. | 2 to 3 |
| Documentation | + Uses public repositories.
-/+ Uses SGILab Use Case templates (an adoption / deviation of the IEC 62559-2 Use Case
template), which focuses on the semantic and syntactic interoperability.
+ Uses SGAM and UML.
- Does not specify the organizational interoperability. | 4 |
| Integration | + Uses SGILab Use Case templates which focuses on the semantic and syntactic interoperability.
+ Uses reusable integration profiles based on BAPs.
+ Reference implementations are used.
+ Integration metrics are recorded. | 4 to 5 |
| Testing | + Uses a testing platform for conformance testing, interoperability testing and documentation.
+ Uses strict test specifications which are derived from the integration profiles (BAIoP).
+ Analysis and publication of test results.
- Does not test the organizational interoperability. | 4 to 5 |
Gap analysis
After presenting the core concepts, methodological approaches as well as case studies that contribute to reduce the distance for integration, these are first analyzed against the maturity requirements of the SG IMM (see Table 1).
The diversity of the different aspects that contribute to a sustainable interoperability must be considered equally in the process. Although it has to be taken into account that all aspects are mutually complementary, the analysis requires a distinction between the interoperability levels, the governance areas and the methodologies and frameworks that are designed to promote interoperability. If the established and presented methods are compared to the interoperability framework of the SG IMM, this results in a suitable evaluation scheme, which allows comparison of the individual methods according to the requirements of the SG IMM criteria. Thus, for an appropriate analysis, all identified dimensions were compared in a matrix (Table 8):
the interoperability categories (technical, informational and organizational),
the SG IMM evaluation criteria (interoperability governance areas) and
the identified standards or best practices.
In order to provide a more comprehensive overview of the consolidated results in Table 8, a distinction was made between those methods that can be regarded as widely established by corresponding de facto standards and those potential methods that have been successfully tested but have not yet been widely adopted in the energy sector.
Table 8. Methodologies classified in accordance to the SG IMM requirements and interoperability categories.
SG IMM = Smart Grid Interoperability Maturity Model.
| | De facto standard | Future opportunities |
|---|
Interoperability
level | Governance
area | IEC 62559-2 Use Case
methodology | Smart Grid
Architecture Model | Integration profile
(e.g. Business
Application Profile) | Test specification
(e.g. Business
Application
Interoperability Profile) | (Technical)
Committee
(community driven) | Technical framework
(consolidated) | Connectathon
(or plugfest)
|
|---|
| Organizational | Management | | | | | (++) | | |
| Documentation | ++ | + | | | | (++) | |
| Integration | + | + | + | | | (++) | (+) |
| Testing | | | | + | | | (++) |
| Informational | Management | | | | | (++) | | |
| Documentation | + | + | ++ | | | (++) | |
| Integration | + | + | ++ | | | (++) | (+) |
| Testing | | | | + | | | (++) |
| Technical | Management | | | | | (++) | | |
| Documentation | + | + | ++ | | | (++) | |
| Integration | + | + | ++ | | | (++) | (+) |
| Testing | | | | + | | | (++) |
Management: Although it can be observed in the various initiatives and projects that the management of standards, documentation, integration and testing is usually handled in a project-specific manner, initiatives such as IES (or, for example, the European Network of Transmission System Operators for Electricity (ENTSO-E) for Transmission System Operators (TSO) communication) can be identified as exceptions. However, the energy domain currently lacks an overall accepted, collaborative and community driven governance which supports the development and documentation of adequate technical frameworks and respective integration profiles in accordance to community requirements and provides the necessary means for integration tests.
Management requirements/future opportunities based on identified best practices:
Provision of a repository for technical frameworks.
Integration profiles/technical frameworks are published and freely available to foster a wide adoption by industry.
Integration profiles/technical frameworks are managed in collaboration by the community to foster the overall acceptance of the industry.
Documentation: As Table 8 shows, the energy domain already provides most of the necessary methods. However, although these methods complement each other, they are often considered independently. For example, the concept of the technical framework is not superior to existing methods, but provides a higher-level structure to harmonize the individual artefacts of the individual methods in a more standardized and structured fashion, which consolidates all interoperability levels and serves as a full-fledged integration guide.
Documentation requirements/future opportunities based on identified best practices:
• Are always based on established standards or best practices to prevent proprietary solutions.
• Concretize the applied standard and only specify mandatory aspects to prevent interpretations.
• Adoption of technical frameworks:
Although the application or development of profiles are common in the energy sector, such profiles usually focus only on semantic and syntactic interoperability of a system Use Case. The missing perspective on pragmatic interoperability can be adequately complemented by the IEC 62559-2 Use Case template and the SGAM methodology.
However, in order to specify the relationships and to promote a consistent and standardized higher-level structure between the individual documents with regard to the SUC of the profiles, the BUCs and business functions, the additional usage of technical frameworks is recommended.
Testing: As the IHE shows, an annual Connectathons or Plugfests contributes to the continuous and community driven improvement of the specifications and the general acceptance by industry. The IES case study showed that this holistic approach also works in the energy system and has received positive resonance.
Testing requirements/future opportunities based on identified best practices:
Periodical organization of Connectathons or Plugfests where independent manufacturers can test their practical interoperability against each other.
Use conformance testing as a prerequisite for interoperability testing.
Add test cases, procedures, description and criteria to the test environment/platform based on the demands of the community.
- Execute interoperability test cases with at least two independent peer vendors.
- Validate recorded messages/traces and log evaluated test results.
- Documenting and publishing the test results of the Connectathon for each system and tested Use Case.
Integration: Integration profiles or specifications are a crucial part of the documentation, for testing and, consequentially, for the repeatable integration with predictable effort.
However, interoperability is traditionally realized bottom-up – from the technical level to the organizational level. The AAS approach of the I4.0 domain shows that this paradigm should be broken with. If BUCs are separated from their underlying SUC, this allows a reconfigurability. Different but well-defined system Use Cases, each representing a business function, with also well-defined interfaces can be reused in different BUCs.
Integration requirements/future opportunities based on identified best practices:
Development and usage of integration profiles (e.g. BAPs).
Usage of profile- and Use Case-based simulators to enable pre-qualifying tests and to reduce basic errors in advance.
Adoption of test specifications (e.g. BAIoPs) as an integral part of integration profiles/technical frameworks, which contains the creation of test cases, procedures, descriptions and criteria within the test environment.
Based on the results as well as the case studies, Table 9 provides a consolidated overview of the overall process for a continuous improvement of interoperability and the respective methodologies from Table 8 embedded within the phases.
Table 9. Consolidated overview of the process for continuous improvement of interoperability in compliance with the SG IMM level 5 requirements.
| Process/Phase |
|---|
(1.) (2.) (3.) (4.)
 |
|---|
| Core activities |
• Identify and document Use Cases
and their requirements where
interoperability is an issue | • Identify available standards or
best practices to solve this issue
• Develop and publish technical
specifications | • Develop test specifications (pre-condition)
• Prepare (configure) the test platform /
testbed
• Test and document the results | • Use the testing results to improve the
specifications
• Publish the results |
| Artefacts (Output) |
• IEC 62559-2 Use Case templates
• Smart Grid Architecture Model | • Technical framework
• Integration profiles (e.g. Basic
Application Profile) | • Test specification (e.g. Basic Application
Interoperability Profile)
• Test results | • Integration statements (which system
has a plug-and-play interoperability with
which other system in which Use Case) |
| General conditions |
• Publication within freely accessible
repository
• In collaboration of technical experts
from the industry / community | • Publication within freely
accessible repository
• In collaboration of technical
experts from the industry/
community | • Provision of a testing platform (e.g.
Gazelle)
• Different vendors have implemented the
previously published integration profiles of
the same Use Case | • Freely accessible repository result-
browser |
In a direct comparison of the case studies, it can be noticed that the process presented in Table 9 is entirely in line with the IES approach as presented in Table 2. Although all presented case studies pursue a comparable approach, only the IES approach fully meets the SG IMM requirements for maturity level 5. This, however, is not surprising, as IES was able to benefit from many years of experience of the IHE initiative. Table 10 shows how the different phases of the different case studies are arranged in comparison to Table 9.
Table 10. Mapping the case study processes.
DIN = Deutsches Institut für Normung (German Institute for Standardization), IES = Integrating the Energy System, SGILab = Smart Grid Interoperability Laboratory.
| Phase |
|---|
| Identification | Profiling | Testing | Publishing |
|---|
| IES | 1 | 2 | 3 | 4 |
| DIN-Connect | 1 | 2 | 3 | 4 |
| SGILab | 1 | 2 | 3 | 4 | 5 | 6 | / |
The DIN Connect approach builds on the IES approach and adapts it to CIM-specific traits, thereby only limiting its generality. While the SGILab, on the other hand, describes a process comparable to IES, but follows a more rigid or formal approach which neglects the socio-political issues. The SGILab focuses on interoperability, which is tested by simulators of the counter components45. Thus, although the conformance to a standard or an integration profile is tested, the extent to which two real systems from two manufacturers are interoperable is not fully clarified - since, for example, socio-technical issues as misunderstandings or faulty implementations of the communicating systems cannot be taken into account by the simulators.
Conclusion
This review was dedicated to the question “how to improve the interoperability in Smart Grids” with the aim to identify opportunities beyond the state-of-the-art approaches in order to reduce the cost for integration in future initiatives. Correspondingly, this contribution provided an overview of the issues related to interoperability in Smart Grids as a collaborative System-of-Systems and the state-of-the-art approaches from different domains and case studies to address those. For this purpose, the presented key concepts and case studies were benchmarked against the SG IMM level 5 maturity requirements, which served as the basis for a subsequent gap analysis. Based on the results, it can be concluded that the electric energy system could highly benefit from the many years of experience gained in the healthcare sector and from the novel concepts of the I4.0 domain.
The summarized conclusion as well as a final critical appraisal is presented below.
Comparative summary
While the capability for seamless integration is subject to various challenges, the problem, however, is not the lack of adequate standards – suitable standards, solutions and/or best practices are available for the energy domain. The problems arise due to the absence of a governance and its resulting implications. The lack of an authority which has “control” over the System-of-Systems prevents the development of holistic and system-independent solutions. Moreover, the wicked complexity of the problem makes it increasingly difficult to find a consensus beyond the lowest common denominator22,46. However, it can be observed that community-driven management approaches are suitable alternatives to cope with these kinds of wicked problems. This way, not only has the IHE initiative been able to establish itself as a driver for interoperability in the health care sector, but the IES project showed that this approach is also finding positive resonance in the energy sector. In this respect, the community-based approach does not only increase general acceptance, but also facilitates the ability to adapt to changing business needs and technological developments with an increased agility compared to traditional standardization bodies. Furthermore, it must also be taken into account that no standard or key concept alone can guarantee interoperability. For example, CIM or IEC 61850 describes suitable information models that are able to represent the relevant Use Cases, but they do not define a context and therefore do not guarantee pragmatic interoperability.
The case studies and experiences from the healthcare sector show that these individual methodologies complement each other and in combination are able to improve interoperability significantly. For example, the IEC 62559 Use Case methodology is suitable to provide the context on an abstract BUC level as well as on a more concretized SUC for the implementation of business functions by defining precise communication processes in a structured way. However, the IEC 62559 Use Case methodology is only suitable to a limited extent for defining the individual transactions of a business function, so that the complementary use of interoperability/integration profiles is recommended. As this in turn leads to a variety of inhomogeneous documents representing different aspects of the interoperability requirements, a unified structure seems to be appropriate, as the technical framework of the IHE or the IES initiative shows. Consequentially, the key concepts do not serve to develop missing standards, but to facilitate the coordination of interoperability issues between the constituent systems. In this way, the concept of profiling/documentation can be highlighted from both theory and practice as the core principle that requires appropriate governance serves as the basis for test activities. In order to perform interoperability tests beyond simple conformance tests, it is required that two vendor-independent systems have implemented the same integration profile of a Use Case. For this purpose it is mandatory to publish the integration profiles in a freely accessible way which allows a third party (with appropriate preparation time) to implement the profiles and to test them against each other within an appropriate test event. The Connectathon (sometimes referred to as Plugfest) is an annual event that brings together the various providers who have implemented the previously published Integration Profiles. In accordance with the IHE all test runs are evaluated by independent experts35. Once a system has successfully passed all necessary tests, the vendor is allowed to publish an integration statement. Such statements tell the customers which specific Use Cases and integration profiles a given system is designed to support. Furthermore, the results of the Connectathon are not only used to validate products, but also to validate and improve the integration profiles for future iterations and, consequentially, in combination substantially reduces the distance for integration.
Critical appraisal
Although the concept or approach of Connectathons realizes a certain degree of plug-and-play interoperability by providing a "proof of interoperability" for two independent systems that share a reciprocal Use Case, the ability for plug-and-play interoperability, however, is limited to the specific systems of the respective manufacturer that were tested; leading to the long-term drawback that as the number of heterogeneous systems increases, the number of tests required also increases by N x M required tests in total as shown in Table 11.
Table 11. Example of required tests in total.
Number of systems
implement component
A of a Use Case (N) | Number of systems
implement component
B of a Use Case (M) | Required tests for
each component A
system | Required total for
each component
B system | Required
tests in
total |
|---|
| 4 | 1 | 1 | 4 | 4 |
| 4 | 2 | 2 | 4 | 8 |
| 4 | 4 | 4 | 4 | 16 |
| 6 | 4 | 4 | 6 | 24 |
| … | … | … | … | … |
As a result, proving the interoperability becomes increasingly time-consuming and costly as the number of participating systems increases. Moreover, as the Smart Grid as a System-of-Systems is able to take on an unprecedented scale in the number of its elements3,47, it can be assumed that a peer-to-peer based testing approach will eventually lead to a bottleneck until they can no longer be sufficiently performed within Connectathons. While the Connectathon approach can be considered best practice in the current and still young phase of the Smart Grid systems lifecycle, it presumably becomes increasingly inefficient and ineffective as the Smart Grid grows in scale.
In order to achieve “true” plug-and-play interoperability in the sense of composability and, therefore, remove the time-consuming tests for each additional system, the prequalification of interoperability tests must become more automatable. Although there is a need for more research on this issue, this could be achieved by fostering a conceptual alignment - while practical tests confirm that two systems are aligned on the four five LCIM levels, the systems tend to remain misaligned at the dynamical and conceptual interoperability level, which is not covered by the SGAM or IEC 62559 Use Case methodology48. The AAS approach has the potential to address this misalignment and therefore foster automatable interoperability tests; this, however, remains an open research question and requires further investigation.
Data availability
The authors acknowledge that the data supporting the findings of this study are available within the article. However, the data sources that support and/or correspond to this study can be traced as follows:
The data sources that support and confirm the findings of this case study are openly available in 42. Additional data about the case study can be freely accessed in 42 at https://doi.org/10.3390/en11123375. Further data sources that are support the findings of this study are available within the article49,50.
