From Integration Profiles to Interoperability Testing for Smart Energy Systems at Connectathon Energy

energies Article From Integration Profiles to Interoperability Testing for Smart Energy Systems at Connectathon Energy Marion Gottschalk 1,*, Gerald Franzl 2,* , Matthias Frohner 3,* and Richard Pasteka 3,* and Mathias Uslar 1,* 1OFFIS e.V., 26121 Oldenburg, Germany 2AICO EDV-Beratung GmbH, 1030 Vienna, Austria 3 Department of Biomedical, Health and Sports Engineering, University of Applied Sciences Technikum Wien, 1200 Vienna, Austria *Correspondence: [email protected] (M.G.); [email protected] (G.F.); [email protected] (M.F.); [email protected] (R.P.); [email protected] (M.U.); Tel.: +49-441-9722-226 (M.G.); +43-2245-824-48 (G.F.); +43-1333-4077-354 (M.F.); +43-1333-4077-893 (R.P.); +49-441-9722-128 (M.U.) Received: 31 October 2018; Accepted: 28 November 2018; Published: 2 December 2018   Abstract: The project Integrating the Energy System (IES) Austria recognises interoperability as key enabler for the deployment of smart energy systems. Interoperability is covered in the Strategic Energy Technology Plan (SET-Plan) activity A4-IA0-5 and provides an added value because it enables new business options for most stakeholders. The communication of smart energy components and systems shall be interoperable to enable smooth data exchange, and thereby, the on demand integration of heterogeneous systems, components and services. The approach developed and proposed by IES, adopts the holistic methodology from the consortium Integrating the Healthcare Enterprise (IHE), established by information technology (IT) vendors in the health sector and standardised in the draft technical report ISO DTR 28380-1, to foster interoperable smart energy systems. The paper outlines the adopted IES workflow in detail and reports on lesson learnt when trial Integration Profiles based on IEC 61850 were tested at the first Connectathon Energy instalment, organised in conjunction with the IHE Connectathon Europe 2018. The IES methodology is found perfectly applicable for smart energy systems and successfully enables peer-to-peer interoperability testing among vendors. The public specification of required Integration Profiles, to be tested at subsequent Connectathon Energy events, is encouraged. Keywords: interoperability; smart energy systems; use cases; IEC 62559; SGAM; TOGAF; integration profiles; IHE; testing; gazelle; connectathon 1. Introduction The energy transition refers to the migration toward solely renewable energy sources (RES) feeding the power grid. Their diverse size, their fluctuating production potential, their total number and their intrinsic heterogeneity makes it somewhat difficult to meet legacy grid requirements and challenges the reliable grid control. Solar energy drives all renewable sources. The sun enables the growth of plants, propels the weather system and thereby the wind and the water cycle, which in addition to photo-voltaic panels and mirror based systems are utilised to generate green secondary energy by wind turbines, hydroelectric power plants, and bio-gases. However, these primary sources are fluctuating, they are not available in the same amount at all times [ 1 ]. In Figure 1, an overview of the central participants of a Smart Grid are shown. Energies 2018,11, 3375; doi:10.3390/en11123375 www.mdpi.com/journal/energies Energies 2018,11, 3375 2 of 26 Figure 1. The Smart Grid: Services based on Information and Communication Technology (ICT) are added to the established energy management paradigm to support efficient grid control in the presence of distributed energy resources (DER). Figure 1also sketches the communication demand among the participants required to safely operate the grid. For safe operation, it is necessary to constantly balance the power grid by assuring that at any time the energy production meets the consumption. To better integrate small and less control-able distributed energy resources (DER), these assets can be yoked into Virtual Power Plants (VPP). A VPP commonly combines many different DER to constitute a virtual plant that can communicate as one entity with energy markets and grid operators, the latter being local Distribution System Operators (DSOs) and possibly transnational Transfer System Operators (TSOs) [ 2 – 4 ]. The aggregation reduces the communication interfaces to external partners and enables more flexible energy production and consumption management in defined areas. Internal as well as external communication interfaces, data models and operation protocols need to be sensibly specified to allow the integration of DER from different vendors. Thus, interoperability [ 5 , 6 ] is a key factor to successfully integrate distributed RES and smart DER in the energy distribution and grid control, which constantly improved over many decades. Integrating novel energy sources and services is, therefore, a big challenge. The individual components of any smart energy system rely on seamless cooperation, i.e., on exchanged information used to reliably support the operation of physically connected system of systems (SoS) being the power grid. The deployment of a Smart Grid is possible when vendors and customers work together to establish joint solutions, where smart energy systems’ interaction is feasible. Organisations like the IEC and VHPready recognised that and develop basic application profiles utilising joint consortia consisting of different vendors (cf. Sections 2.6 and 2.7). The Austrian Project Integrating the Energy Systems (IES) [ 7 ] adapted the IHE methodology from the healthcare sector to match the energy domain by specifying exemplary use case centric interfaces for energy systems and by establishing an interoperability testing framework, the annual Connectathon Energy. The main goal of IES is to provide a workflow for the energy domain that fosters interoperable energy system components required for the communication in Smart Grids. The core contributions of the work performed are: •Transferring the IHE methodology into the energy domain, •Providing a test environment to specify and document test cases and test sequences, •Validation of the IES methodology via exemplary profiles for VPPs based on IEC 61850. The IES workflow and the results from the Connectathon Energy presented in the following are an extension of the conference poster abstract [ 8 ]. The proposed workflow is explained in more detail, from profiling to testing. In the following Section 2, the considered methodologies and some Energies 2018,11, 3375 3 of 26 other works in the field of interoperability are outlined. The IES workflow is introduced in Section 3 and Sections 4and 5describe the major steps. The validation of the IES workflow is presented and discussed in Section 6. Section 7concludes the paper providing an outlook on further envisaged and progressing steps toward a general application of the methodology. 2. Related Work The concept and methods applied by the project Integrating the Energy System are based on recent research results and recommendations on achieving interoperable IT solutions and the Single Digital Market envisaged by the European Commission [ 9 ]. These are briefly outlined in the following subsections. 2.1. The IEC 62559 Use Case Methodology The IEC has standardised the Use Case Methodology from the European mandate M/490 in the series IEC 62559 [ 10 ]. The methodology describes complex systems functionalities, actors and processes in a structured way. The methodology is used to analyse requirements and to detect standardisation gaps; e.g., in data models and protocols. Use Cases are first building blocks in software engineering to specify systems. The system functionality is approached from a static and a dynamic point of view: involved actors and system boundaries are considered static and relations between the actors contributing to a Use Case show dynamic aspects [1,11]. With the IEC 62559 Use Case Methodology, use cases are textually described in a template by application and implementation experts. The template is specified in IEC 62559-2 . The other three parts of the standard series classify the operational use of the methodology, possible tool-support, and best practices. For the template, an XSD schema is defined to enable content exchange between different tools [ 10 ]. The template contains the eight parts shown in Table 1. The first two parts can be defined by domain experts: it provides the management perspective. The technical requirements are specified by application and implementation experts in parts three to six. The last two parts are jointly completed where necessary. Based on the structured Use Case description, technical specifications can be derived; i.e., architecture models (cf. Section 2.2) and interface specifications (cf. Section 4.2). Table 1. The eight parts of the Use Case template—content and viewpoint. Use Case Template Content Viewpoint 1 Description General info: identifier, name, non-technical description, boundaries, objectives, etc. management perspective 2 Diagram Visual representation of the Use Case: e.g., UML Use Case Diagrams, Sequence Diagrams. 3 Technical details List of actors (humans/systems) involved in the Use Case with brief role explanation. 4 Step-by-step analysis Technical description of implementation: data exchanged, information objects, requirements. ICT experts 5 Information exchanged List of information objects exchanged between actors. 6 Requirements List of requirements that have to be adhered to actors and information objects. 7 Common terms and definitions Glossary of the Use Case: define the terms used. stakeholders (if necessary) 8 Custom information Further information/explanation that cannot be addressed elsewhere. Energies 2018,11, 3375 4 of 26 2.2. The Smart Grid Architecture Model (SGAM) For visualising connections within Use Cases, the Smart Grid Architecture Model (SGAM) can be applied. The SGAM resulted from the European Mandate M/490 , where the GridWise Architecture Council (GWAC) stack became adopted for the Smart Grid domain [ 12 , 13 ]. The SGAM is a three-dimensional visualisation, presented in Figure 2, that helps to identify components and their relations. An example application is later shown in Section 4.1. Figure 2. The Smart Grid Architecture Model [ 12 ]: a three-dimensional positioning scheme to identify and confine features and systems of smart grids, c CEN/CENELEC, reproduced with permission. From the top to the bottom, five layers are used to consider different interoperability aspects (viewpoints). It starts with the Business Layer, where regulatory and economic structures, business models and processes are positioned. On the next layer, the functional view, the functionalities are located. The required functionalities result from analysing different Use Cases. On the Information Layer, the used and exchanged information is considered; i.e., the Use Case specific semantic for functions and services to enable an interoperable information exchange. Therefore, information objects and canonical data models are positioned here. On the Communication Layer, protocols and mechanisms for the information exchange between actors are positioned; i.e., the data channel specification. The Component Layer is the lowest level and covers the individual entities that contribute to the Smart Grid. It includes autonomous systems, connected components, atomic applications, and any kind of smart devices. Each layer spans all domains along the energy conversion chain, from generation to consumption, as well as the control and management zones, from process until market control and management, respectively [14]. The energy conversion chain starts with the generation of electric energy that is typically connected to the transmission system. The transmission is the infrastructure and organisation that distributes the electricity over long distances to major industry and cities. The distribution represents the infrastructure and organisation that distributes the electricity to customers within a specific region. Distributed Energy Resources (DER) are comparably small power plants feeding electricity into the distribution grid. At the Energies 2018,11, 3375 5 of 26 end of the chain, customer premises refers to the industrial, commercial, and residential facilities of energy consumers. The aggregation, separationand utilisation of the information used to manage the power system is governed by organisational and legal rules on participating in the energy sector. In the market zone, possible market operations along the energy conversion chain are considered; e.g., energy and capacity trading. The enterprise zone covers commercial and organisational processes and services; e.g., customer contracting and billing. The operational zone refers to power system control operations for the generation, the transmission and the distribution systems. The station zone aggregates data and functions from the field zone, which describes the equipment to protect, control, and monitor physical processes and power flows. In the process zone, physical, chemical, and spatial transformation of energy, the applied physical/mechanical/electrical equipment, is represented [14]. 2.3. The Open Group Architecture Framework (TOGAF) The concept considering different viewpoints on an architecture is also used by The Open Group in their Architecture Framework (TOGAF) [ 15 ]. This logical cyclic process for developing an architecture is depicted in Figure 3. It is a widespread and mature enterprise architecture development framework that covers three high-level viewpoints; i.e., business,information system and technology architecture [ 1 , 15 ]. The business architecture addresses management and planning; e.g., business strategies, governance, and organisation. The information system architecture can be divided into data and application centric views. The former supports database designers, administrators and systems engineers to structure an organisation’s logic, its data assets and resources. The latter addresses system and software engineers describing the logic of the system; i.e., the business processes. The technology architecture describes the hardware and software capabilities to implement business needs; i.e., data and application services [1]. Requirements Management A: Architecture Vision B: Business Architecture C: Information System Architecture D: Technology Architecture E: Opportunities and Solutions F: Migration Planning G: Implementation Governance H: Architecture Change Management Preliminary: Framework and Principles Figure 3. The Open Group Architecture Framework: a logical, cyclic, step-by-step requirements elicitation guideline. The cyclic TOGAF process consists of eight steps plus a preliminary step and a central constantly used, as shown in Figure 3. A possible application of the steps is described in Sections 4and 4.2. In brief: A preliminary phase takes place to identify enterprise-specific frameworks or principles before the architecture development starts. The first step in the actual architecture development is Energies 2018,11, 3375 6 of 26 the architecture vision. It is about the definition of the envisioned architecture scope and analysis of stakeholders and their needs. Defined objectives are the basis for architecture viewpoints. Following the first step, the business, the information systems, and the technology architectures are developed. Base thereon the initial implementation is planned in opportunities and solutions. During migration planning, an implementation and migration plan is developed, which include the definition of working packages and building blocks. Implementation governance addresses the supervision of the implementation; e.g., check whether the implementation meets the objectives. The TOGAF process ends with the step architecture change management, where based on monitoring and verifying the reactions a subsequent iteration of the process may be triggered. The requirements management action is connected to every step because it covers the requirement monitoring necessary in parallel to each step. 2.4. Integrating the Healthcare Enterprise (IHE) Formed by healthcare professionals and industrial partners the IHE initiative aims to empower secure and coherent transfer of information between involved computer systems. The ability of a system to communicate with other products or systems, whose interfaces are completely understood, without any restrictions, is a basic concept of interoperability. The IHE initiative defines interoperability profiles based on existing standards (e.g., DICOM, HL7), creating a framework for interoperability testing definitions. Each profile contains the definition of involved actors, transactions and their mutual relationship in terms of information transfer. The experts supervised interoperability testing events, called Connectathons, take place annually [16,17]. The IHE process consists of four steps: 1. Critical aspects of information transfers are identified and thereby relevant Use Cases defined. 2. IHE profiles are jointly developed to detail every communication via established standards. 3. Vendors develop systems that implement the communication as specified in IHE profiles. 4. The interoperability of a vendor’s system is peer-to-peer tested at Connectathon events. 2.5. Gazelle—A Test Platform for Interoperability Testing Gazelle is the name of the test bed used at the IHE Connectathons since 2006 [ 18 ]. It provides the means for mainly two flavours of software testing: (1) interoperability testing and (2) conformance testing [ 19 ] as shown in Figure 4. Meanwhile, the list of features supported by Gazelle has risen. From the test organisation perspective, this tool is used to register the companies, the systems under test (SUT), and their implementer. On the other hand, it provides Gazelle with the Integration Profiles that can be tested (including relevant actors and transactions) and the related test case definitions. To capture exchanged data, Gazelle provides a proxy that is configured to log all messages exchanged between SUTs participating in a test case. The logged messages (traces) can be validated for syntactic and semantic compliance in a subsequent step using the validation services available in Gazelle or from external sources. The Gazelle Transformation Service facilitates binary to XML transformation by means of DFDL (Data Format Description Language) schemata. Figure 4. Testing interoperability and validating the conformance with Integration Profiles. Energies 2018,11, 3375 7 of 26 Finally, the Gazelle platform documents the result of every conducted test step and hosts the Connectathon results and a Products Registry for successfully tested products that achieved an Integration Statement. 2.6. IEC Basic Application Profiles The Smart Grid Mandate M/490 developed a concept to achieve interoperability by using existing standards. The concept is named Basic Application Profiles (BAP) [ 20 ]. BAPs define elements in modular frameworks for specific Use Cases of energy systems—a standard set for an application. Contrary to common standards, the BAP specification contains only mandatory aspects that have to be implemented to realise the Use Case and enable interoperability [ 21 ]. Use Cases address business problems identified by vendors and customers who need a solution for as specific issue in a given environment. To solve it, every feature is divided into elementary parts, which can be recombined to define more complex Use Cases. A profile consists of a profile name, requirements, boundaries and scalability, standards and specifications, communication network topology, and best practices. Each BAP can be used as building blocks that, in combination with others, realises complex applications (cf. Sections 2.3 and 4.2.1 where the concept of building blocks is also used). An extension of BAPs are Basic Application Interoperability Profiles (BAIOP) [ 22 ] based on the V-Model [ 23 ]. BAPs provide an implementation strategy and BAIOPs contain an approach for testing on different levels (e.g., unit, integration, system, and acceptance testing) that also considers interoperability. Therefore, further specifications are defined with BAIOPs: device configuration, test configuration, test cases for the BAPs, specific capability descriptions and engineering frameworks for data modelling and communication infrastructures, which together enable the testing of a proposed system. 2.7. VHPready VHPready e.V. [ 24 ] is an alliance, founded by stakeholders of the energy industry targeted to specify an industry-standard enabling interoperable communication in the field of virtual heat and power plants. The communication is based on IEC 60870-5-104 [ 25 ] or IEC 61850-7-420 [ 26 ]. Based on these standards and identified Use Cases, VHPready defines a set of data points that specify needed data objects either from IEC 61850 or 104. Based on the specified restrictions, VHPready compliant systems can be modelled and implemented. Moreover, the list of data points enables a mapping between the two different standards. VHPready focuses on the interoperable communication between DER and a VPP operator (aggregator) and does not consider issues with other assets and entities of the energy system that may be needed to fulfil related Use Cases that reach beyond the boundaries of managing a VPP. 3. IES Workflow Overview The project IES migrates and adopts the established and matured IHE methodology on achieving interoperable IT based healthcare systems. All started with incompatible digital X-ray images (radiology) in 1999 and by today covers many areas and achieved wide acceptance in the US, Europe, and East Asia. For example, the Austrian digital health record database [ 27 ] is entirely based on public IHE Integration Profiles. The generality and success of the methodology motivates the migration into the energy sector with similar security demands, market structure and regulatory governance. The IES methodology realises the four basic steps shown in Figure 5, which evidently split up into many more intermediate steps [28]. A moderate expansion yields: 1. Identify Use Cases where interoperability is an issue and specify these by identifying system borders and requirements [11]: •Write a Business Overview (define actors, the environment and the general issue), • Describe Business Functions (apply the Use Case Methodology and draw UML use case diagrams), Energies 2018,11, 3375 8 of 26 •Reuse Integration Profiles where possible (save specification and test effort). 2. Jointly identify how interoperability issues can be prevented and specify the requirements normatively as Integration Profile [19]: •Evaluate which standards can be used to fulfil the Use Case requirements, •Specify the process to realise a Business Function (UML sequence diagram), •Define the actors and transactions (decompose Meta-Actors into modules), •Describe the role of the individual actors (modules), •Draw an Actors-Transactions Diagram (decompose the process into steps), •Draw detailed UML sequence diagrams per transaction (steps sequence), •Specify additional communication and security requirements. 3. Test independent prototype solutions against each other on annual plugfest and improve the Integration Profiles until it is fixed [29]: •Specify test cases and test sequences according to Integration Profile specification, •Integrate test cases, procedures, and documentation in test environment (Gazelle), •Create or integration conformity validation tools (e.g., Schematron), •Develop simulators as dummy pre-Connectathon test partner (optional), •Execute test cases with at least two independent peer vendors, •Validate recorded messages/traces and log passed test results (neutral monitor), 4. Publish successful test results: who has successfully tested which Integration Profile [29], •Publish which vendors successfully tested an Integration Profile (Result Browser), •Get written approval for successful implementation (Integration Statements). INTEROPERABILITY & CONFORMANCE TESTING SPECIFY Test cases COLLABORATE in rolling process PUBLISH SUBMIT New use cases SUBMIT New use cases IMPLEMENT Profiles TEST Software prototypes USE CASE CENTRIC TECHNICAL FRAMEWORKS COOPERATIVE WORKFLOW REGISTRY OF INTEROPERABLE PRODUCTS CONNECTATHON ENERGY PARTICIPATE PARTICIPATE CONSULT Registry SUBMIT Interoperable energy IT solutions www.iesaustria.at INTEGRATION PROFILES SOFTWARE DEVELOPMENT USER / PURCHASERS VENDORS / DEVELOPERS DEFINE Use Cases NORMATIVE USE Existing standards SPECIFY Profiles PUBLISH Specifications CONNECTATHON RESULTS & INTEGRATION STATEMENTS BASED ON EXISTING STANDARDS ISO, ETSI, IEEE, IEC, VHPready… BASED ON IHE METHODOLOGY (ISO/TR 28380) BASED ON OPEN SOURCE IHE TESTBED GAZELLE VENDORS PURCHASERS WORKFLOW BASED ON GOOD EXPERIENCE BUY SELL BOARDS COMMITTEES GOVERNANCE MARKETPLACE FOR INTEROPERABLE PRODUCTS Figure 5. The IES process to interoperability are, in brief, four steps: identify → specify → test → sell. Integration Profiles shall be living documents that improve and grow until they become stable. The core idea of the methodology is lively cooperation between the users and vendors. All stakeholders shall participate in the process as peers and contribute jointly to the development of demand oriented solutions. Sometimes, interoperability can be achieved most reliably with very simple means that work fine for many. In contrast to certification, where one system is tested against a set of rules or a single reference system, here the implementer from different vendors test their solutions among each other. Energies 2018,11, 3375 9 of 26 All peers participating in a test case have a common goal: they want to ultimately pass the test. A multi-day plugfest provides the environment and time to learn and make corrections prior to the final decisive test. Implementer can talk to each other and jointly identify why something does not work as it should. Such issues are often based on different interpretation of the Integration Profiles, which demands amendment of the text. Comments and errors recorded at the test event are the most valuable and powerful input to improve Integration Profiles. This feedback is practice driven and supports the advancement of the Integration Profiles in becoming a good basis for interoperable systems that can be integrated in the bigger system-of-systems. 3.1. Process Coordination and Control The committees of IHE are instruments that manage and implement the industry integration process. Their importance may be concealed by results, being the Integration Profiles produced and test events organised. However, it requires coordination and cooperation to achieve interoperability. It is important that a committee is addressable, so tasks can be forwarded to it and its decisions are accepted by all stakeholders. Committees fulfil required roles that demand certain skills, which are presented in this section. Different skills are fundamental to execute the various management tasks that coordinate and control the IES process. Committees, depicted in the centre of Figure 6as connected circles stating the skills grouping foreseen, manage the topics related to profile preparation and test execution, shown on the left and right sides, respectively. Figure 6. Functional Committees: coordinating, managing, and executing bodies that drive and manage the IES based process to integrate energy enterprises. Functional roles are defined to manage the integration process by the committees. Experts can serve in one, two or all roles, depending solely on skills they actually contribute. Participants in committees shall be voluntary delegates from institutions, companies, and enterprises interested in interoperable solutions. The planning committee and the technical committees are the main working bodies. The planning committee assigns Integration Profiles to Technical Frameworks and is responsible for organising testing events, including the decision whether profiles are ready for testing either as trial or mature Integration Profile. The technical committees are the task forces writing Integration Profiles and specifying test scenarios, i.e., test cases and sequences, and providing tools like the test platform Gazelle (cf. Section 2.5) and its components (proxy, simulators, evaluators, as well as the logging, reporting and documenting means and repository), essential to reliably execute test cases. In addition, the domain coordination board, composed of experts covering all domains, is in between and resides slightly above. It determines which domain a Technical Framework shall be assigned to. Moreover, it supports technical committees by proposing cross-domain reuse of existing Integration Profiles to prevent the development of redundant Integration Profiles. Thereby, the technical solutions landscape is also harmonised across frameworks, simplifying interoperability beyond domain borders. Energies 2018,11, 3375 16 of 26 and dogmatism because the actual implementation shall be technology-neutral and remains a vendor decision. Sometimes, for specific customer demands, deviations from the generic approach are required. For example, options provided by a standard that differ from those specified in Volume Two may be implemented on customer or vendor demand. Such options, which do not comply with the generic specifications in Volume Two, shall be specified in Volume Three. Similarly, deviations enforced by regional legislation are to be specified in Volume Four. These extra Volumes are solely provided to allow deviations without spoiling the generic definition. Evidently, they shall be kept to the absolute minimum truly required. The next step in developing products is combining the individual functional actors specified with the Integration Profiles into the Meta-Actors that realise the Business Functions defined in Volume One (i.e., step F and G in TOGAF and system integration in the V-model). This may be environment and variant dependent, and is consequently not part of the Technical Framework. The same applies for the last step H in TOGAF (and also the first, being A), which is performed by the system planner that decides which features to buy and how to integrate them in the existing system architecture. 4.2.1. Relation to TOGAF and EIRA Architecture Building Blocks The sequential separation into individual parts is typical for top-down approaches, as are the Use Case Methodology [ 10 ] or the TOGAF Architecture Development Method [ 15 , 31 , 33 ]. What we call Business Functions, or more precisely the individual features a Meta-Actors shall or may implement, are the Architecture Building Blocks (ABBs) in TOGAF/EIRA nomenclature. Their normative specification, the ABB_spec, is alike the IES Integration Profile. The Solution Building Blocks (SBBs) are the chosen standards, the exemplary specified transactions and the provided implementation examples, as shown in Figure 13. Figure 13. The Open Group Building Blocks: coarse relation of Business Function, Integration Profiles, etc. to Architecture and Solution Building Blocks used by TOGAF/EIRA. Note that SBBs are always examples only. How a vendor achieves the fulfilment of an ABB_spec, which here implements the specifications stated in an IES Integration Profile, is not relevant for the interoperability. Only what is actually required for interoperability needs normative specification. Having noticed that modern standards offer a plurality of options to realise certain features, all based on the same technical background but with many options, it appears straightforward to use the features that a standard offers as solution building blocks. These can than be bundled (grouped) with Integration Profiles, as shown in Figure 14. Their usage shall be constrained by the calling Integration Profile, such that interoperability is achieved precisely as required for the related Business Function. Energies 2018,11, 3375 17 of 26 Business Function 1 ... Business Function n Integration Profile 1 Integration Profile 2 Integration Profile i Integration Profile j Common Feature a Common Feature b Common Feature z Standard A (Technology) ... Standard Z (Technology) derive from bundle into extract from X Figure 14. Common Features: bundling highly flexible features as provided by modern standards. These solution building blocks we call a Common Feature (CF). They represent best practice solutions or excerpts from standards. They may refer to a single standard only, and shall provide the full flexibility available. To specify a feature of a standard as individual CF is only economic if this CF is used by many Integration Profiles. However, if that is the case, CF saves redundant specification of similar usage of the same feature in multiple Integration Profiles. CF may be used to specify parts of the conformance tests. The more restrictive interoperability tests, and the conformance to the Use Case specific, Business Function related, restrictions, obligations, and constraints, cannot be derived from CF because these are specified in the Integration Profiles only. Therefore, for the remaining discussion, we assume generally that tests are derived from Integration Profiles, presuming that requirements and specifications from bundled in profiles and CF are completely considered for every Integration Profile. 5. Testing the Interoperability and Profile Implementation Conformance The IES approach on interoperability and Integration Profile conformance testing is the central pillar of the IES methodology, as shown in Figure 15. The Technical Framework, containing the Integration Profile definitions introduced in Section 4, specifies the requirements on how different assets (actors) exchange information to implement the functionality required to realise a Business Function, and thereby enable a business case. The well established IHE methodology underlines the essential importance of peer-to-peer testing to ensure interoperability between systems. Publicly available test results serve as proof of a system’s compliance with the specifications evaluated when passing a defined test case. When a software vendor passes all test cases defined for an Integration Profile, an Integration Statement can be requested. This document formally proves that the component it is issued for has successfully passed all defined tests to evaluate the implementation’s compliance with the listed specifications (Integration Profiles). The Integration Statement enables the vendor to promote its products, makes offers to tenders requesting compliance to listed profiles and convinces customers that the product can be integrated in an existing infrastructure. Specifications may include uncertainty, such that vendors may implement specifications in divergent ways. To overcome this issue, peer-to-peer interoperability testing between independent developed systems is necessary. This kind of software test is most effective when a system from vendor A is tested directly against a system from an independent vendor B, as shown in Figure 16. To perform this, IHE hosts the Connectathon test events, which are an established and proven means to ensure the interoperability of systems beyond company boundaries [29]. Energies 2018,11, 3375 18 of 26 Figure 15. The three pillars of the IES approach: identification and specification, peer-to-peer testing, public available specifications and results (Open Access). Figure 16. Peer-to-peer interoperability testing: independent implementations get connected and their cooperation is evaluated, including verification of exchanged messages (formats and contents). The Connectathon test events are scheduled annually in Europe, the US and East Asia. The implementer of different vendors come together for a whole week and test whether information can be exchanged according to IHE Integration Profiles between their prototype implementations. These Connectathon events bring together the implementer for discussions and gives the community a forum for the validation of stated IHE specifications. Technically, IHE provides the test bed Gazelle [ 34 ]. This web-based tool provides, aside from event organisation functionalities, the features needed for test case management, system management, data traffic logging, message and sequence validation, and test documentation. Gazelle’s validation uses primary XML validation methodologies, i.e., the validation services check the XML payload: if it is well-formed, whether the payload adheres to specifications specified in XML schema files, and if additional formatting rules are fulfilled, using XML-Schematron validation. Since the example VPP profiles specify the use of IEC 61850 compliant data objects exchanged using MMS to generate and transport data, here the payload is binary encoded. To validate the exchanged messages using Gazelle’s validation services, the binary encoded data need to be transferred into an XML representation. Therefore, the Data Format Description Language (DFDL) [ 35 ] and a Daffodil-Transformation [ 36 ] are used for the example. DFDL is an XML schema like a definition language extending classics schema file with additional information on how single bytes, and even bits, shall be interpreted in a form of annotations. Daffodil-Transformation is an open source tool that processes the binary data and generates XML files based on the specifications stated in a DFDL file. Gazelle already includes capabilities for this transformation step and, therefore, only the DFDL files need to be defined to create XML files from the logged messages containing binary encoded information. The resulting XML files can be further validated with the common Gazelle tools. Energies 2018,11, 3375 19 of 26 An essential features of the test-bed Gazelle is its capability to record messages that are exchanged between the systems under test (SUT). To use this feature called Proxy, the SUT needs to be configured not to communicate with test partners indirectly via the Proxy, as shown in Figure 17. System A 192.168.4.11 System C 192.168.4.23 Proxy IP 192.168.3.2 10300 n . . . 102 Proxy Ports Gazelle Proxy Consumer Port Direct Communication Line 10301 System B 192.168.4.22 102 Consumer Port Figure 17. Derailing communication via Gazelle proxy service: port numbers are assigned to the systems prior testing, transferred messages are captured to undergo validation. The proxy needs to be configured to assign all the corresponding endpoints to test instances and SUTs, such that messages received from a SUT are logged and in parallel forwarded to the correct receiving SUT. Logged messages can be forwarded to Gazelle’s validation tools (or external validation options). Only during this last step the Daffodil-Transformation stated above is applied to gain an XML representation of the message content for the actual validation. 6. Realisation of the IES Workflow First trial peer-to-peer testing sessions have shown that interoperability between vendors is possible by using Integration Profiles demonstrated at the first IES Connectathon in conjunction with the IHE Connectathon 2018 in the Hague, Netherlands. Four different vendors have successfully implemented the following Transactions from trial Integration Profiles, and passed the according interoperability tests: • Send MMXU: specifies how measured values are sent from a DEUC to DEUOP or VPPOP using the IEC 61850 logical node MMXU. • Send FSCH: specifies how a functional schedule is sent from a DEUOP or VPPOP to a DEUC using the IEC 61850 logical node FSCH. • Send DRCT: specifies how DER controller characteristics are transferred from a DEUC to a DEUOP or VPPOP according to IEC 61850. 6.1. Test Setup for Interoperability Testing at the Connectathon 2018 Exchanged messages are recorded using the proxy of a dedicated Gazelle instance. The Gazelle instance is installed at the University of Applied Sciences Technikum Wien in Vienna, Austria. The local area network (LAN) used at the Connectathon floor for testing the energy components is managed by the IES team, independent from the IHE floor-LAN. The Gazelle instance running in Vienna is connected using a virtual private network (VPN) connection, as shown in Figure 18. This enables the recording and validation of exchanged messages via the Gazelle instance running on servers in Vienna. Gazelle management and configuration are performed via the Gazelle web interface. Energies 2018,11, 3375 20 of 26 VPN Router System A System B VPN Router Gazelle Test Bed VPN Tunnel Validation Service Transformation Service Proxy Figure 18. Schematic set-up for interoperability testing: directional communication is routed through the VPN connection to capture, transform and validate messages using the according Gazelle tools. 6.2. Interoperability testing Result—Send Functional Schedule Test steps are defined for selective interoperability test scenarios. In general, the sequence diagram shows the required information exchange steps that need to be performed during a given testing instance. The transaction Send Functional Schedule (Send FSCH) is shown in Figure 19. The according test scenario evaluates the communication between VPPOP or DEUOP (System A) and DEUC (System B): Figure 19. Sequence diagram sketch for the in total eleven test steps to be evaluated for the transaction sends FSCH in accordance with IEC 61850. The data packages transferred between system A and B are captured via the Gazelle Proxy and undergo transformation into an XML representation, according to a predefined DFDL schema that converts the ASN.1 encoded binary data blocks into ASCII text. Based on this, conformity assessment as shown in Figure 20 (a screenshot from the external evaluation tool) is performed in three steps, each resulting in either pass or fail. First, the XML document adherence to the XML 1.0 syntax rules (well-formed) is inspected. Secondly, the document is checked against the associated XSD schema. The last step includes content validation applying rules defined in a Schematron. Energies 2018,11, 3375 21 of 26 Figure 20. External validation service result showing conformity assessment for captured messages. An overview of the interoperability test-results achieved at the Connectathon 2018 is shown in Figure 21 (screenshot from Gazelle). The systems under test supporting given Integration Profiles are listed: Send Measured Values (SMV), Send Planned Schedule (SPS), and Send Asset Configurations (SAC), Their role is either the Initiator or Responder actor, depending on which entity starts the communication. Information about the required number of independent test-runs for receiving an integration statement and the list of different test instances conducted is shown. Individual steps can be opened in the user interface and manually inspected. Altogether, the interoperability testing in the energy domain performed at the Connectathon 2018 comprised of twenty-one tests instances for the three Integration Profiles. Four DEUC and three VPPOP prototypes/systems from four different manufacturers were tested. Figure 21. Connectathon 2018 test-results: the VPPOP, DEUOP and DEUC communication interfaces from four different manufacturers were tested on interoperability and compliance with the SMV, SPS and SAC Integration Profile (Gazelle screenshot). Energies 2018,11, 3375 22 of 26 7. Conclusions and Outlook The research presented is based on the design research principle by Hevner et al. [37]. The main principle of the approach taken is to point out the utility of an artefact for a given scope and problem. The scope was to find a meaningful canonical, standardised process to create profiles for interfaces between components of Smart Grids. As of now, no such process existed in the domain of electrical engineering in the context of Smart Grids. There is no standardised way for system-of-systems based interoperability testing. However, a well established design artefact in from of the IHE (Integrating the Healthcare Enterprise) concept existed. The healthcare domain has similar problems motivated form the view of system-of-systems integration. However, it uses different processes, protocols, and data formats and ontology. A particular challenge was to establish these for the Smart Grid domain and to do a first trial of the well-established healthcare originated methodology in the energy domain. Since this particular aspect is not in the scope of the EU and its European Interoperability Framework (EIF), going vertical with established methods, we conducted the first Connectahon Energy using the IHE Gazelle successfully. This has proven to be a first proof of concept and was considered successful form the healthcare experts. Time will show how many interfaces and use cases will emerge with IES compliant profiles to be tested in the coming years. Based on the experience from the first Connectathon Energy in the Hague 2018, including the preparation time for this test event, one of the lessons learned is strengthening and aligning the test specification within Gazelle with the Integration Profile development. Companies participating in the Connectathon Energy in the Hague reported that some assertions need to be made more restrictive. Besides the refinement of specifications, Gazelle’s feature for pre-Connectathon testing should be considered; i.e., before a face-to-face test event, vendors want to run conformance tests using the IES Gazelle instance by uploading captured message contents/traces for validation. Feedback gathered at Connectathon Energy events will be considered for upcoming events. Besides updated and new test specifications, web-calls shall be scheduled to support interested and registered companies with detailed technical information on how to prepare best and how Gazelle tools can be accessed and used prior to the event. Concerning the upcoming Connectathon Energy end of January 2019 in Vienna, more trial profiles for interoperability and conformance testing have been prepared and are ready to be tested. The new profiles specify how to communicate metered values and schedules using the IEC 60870-5-104 standard in accordance with specification efforts from VHPready. The IES activity has resulted in becoming part of work done within the ISGAN initiative. The main objective of ISGAN Annex 6 is to establish a long-term vision for the development of future sustainable power systems. The Annex 6 on Power Transmission & Distribution Systems focuses on system-related challenges, with an emphasis on technologies, market solutions, and policies that contribute to the development of system solutions. The work is carried out by a global network of experts and is managed in four Focus Areas: Expansion Planning and Market Analysis,Technology Trends and Deployment,System Operation and Security, and Transmission and Distribution System Interactions. The active dissemination of the IES methodology is an integral part. IES Europe is listed as activity A4-IA0-5 in the European Strategic Energy Technology-Plan (SET-Plan) as an Implementation Plan Increase the resilience and security of the energy system [ 38 ]. This listing supports the opportunity to specify IES Technical Frameworks and Integration Profiles in the course of international R&D projects with great visibility. Author Contributions: All of the authors have read and approved the final manuscript. The individual contributions of the authors are: 1. Introduction, G.F.; 2. Related Work, M.G., G.F., M.F., R.P. and M.U.; 3. IES workflow overview, M.G. and G.F.; 4. Technical Frameworks, M.G. and G.F.; 5. Testing the interoperability and profile implementation conformance, M.F. and R.P.; 6. Realization of the IES workflow, M.F. and R.P.; 7. Outlook, M.F. and M.U. Funding: This research was funded by the Austrian Climate and Energy Fund (KLIEN) managed by the Austrian Research Promotion Agency (FFG), under contract number 853693 within the e!MISSION program, 2nd call, of the Austrian Federal Ministry for Transport, Innovation and Technology. Energies 2018,11, 3375 23 of 26 Acknowledgments: The presented work is part of the project Integrating the Energy Systems (IES) Austria supported by the Austrian Climate and Energy Fund (KLIEN) managed by the Austrian Research Promotion Agency (FFG). We thank all team members of the IES project for the support to write this contribution. Conflicts of Interest: The authors declare no conflict of interest. Abbreviations The following abbreviations are used in this manuscript: ABB Architecture Building Block ABB_spec ABB Specifications ACM Association for Computing Machinery BAP Basic Application Profile BAIOP Basic Application Interoperability Profiles CEN European Committee for Standardization CENELEC European Committee for Electrotechnical Standardization CF Common Feature CG Coordination Group CO2 Carbon Dioxide DER Distributes Energy Resource DEU Distributed Energy Unit DEUC Distributed Energy Unit Controller DEUOP Distributed Energy Unit Operator DFDL Data Format Description Language DICOM Digital Imaging and Communications in Medicine DRCT DER Controller Characteristics DSO Distribution System Operator DTR Draft Technical Report EIRA European Interoperability Reference Architecture ETSI European Telecommunications Standards Institute FFG Austrian Research Promotion Agency FIP Functional Integration Profile FSCH Functional Schedule GWAC GridWise Architecture Council HL7 Health Level 7 ICT Information and Communication Technology ID Identification IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineering IES Integrating the Energy Systems IHE Integrating the Healthcare Enterprise IP Internet Protocol ISGAN International Smart Grids Action Network ISO International Standardization Organization IT Information Technology KLIEN Austrian Climate and Energy Fund LAN Local Area Network M/490 European Mandate 490 MMXU Measurements OASIS Organization for the Advancement of Structured Information Standards PHR Personal Health Record RA Reference Architecture R&D Research and Development RES Renewable Energy Source SAC Send Asset Configuration SBB Solution Building Blocks Energies 2018,11, 3375 24 of 26 SET Strategic Energy Technology SETIS Strategic Energy Technologies Information System SG Smart Grid SGAM Smart Grid Architecture Model SMV Send Measured Values SoS System of Systems SPS Send Planned Schedule SUT Systems Under Test TF Technical Framework TOGAF The Open Group Architecture Framework TSO Transmission System Operator UML Unified Modelling Language VPN Virtual Private Network VPP Virtual Power Plant VPPOP Virtual Power Plant Operator XML Extensible Markup Language XSD XML Schema Definition References 1. Uslar, M.; Specht, M.; Daenekas, C.; Trefke, J.; Rohjans, S.; Gonzalez, J.M.; Rosinger, C.; Bleiker, R. Standardization in Smart Grids; Springer: Berlin/Heidelberg, Germany, 2013. 2. Ramchurn, S.D.; Vytelingum, P.; Rogers, A.; Jennings, N.R. Putting the ‘Smarts’ into the Smart Grid: A Grand Challenge for Artificial Intelligence. ACM 2012,55, 86–97. [CrossRef] 3. Kroposki, B.; Johnson, B.; Zhang, Y.; Gevorgian, V.; Denholm, P.; Hodge, B.M.; Hannegan, B. Achieving a 100% Renewable Grid: Operating Electric Power Systems with Extremely High Levels of Variable Renewable Energy. IEEE Power Energy Mag. 2017,15, 61–73. [CrossRef] 4. Steg, L.; Shwom, R.; Dietz, T. What Drives Energy Consumers? Engaging People in a Sustainable Energy Transition. IEEE Power Energy Mag. 2018,16, 20–28. [CrossRef] 5. IEEE Standards Board. IEEE Standard Glossary of Software Engineering Terminology; Technical Report; Standards Coordinating Committee of the Computer Society of the IEEE: Los Alamitos, CA, USA, 1990. 6. Merriam-Webster Incorporated. Definition of Interoperability. Available online: https://www.merriamwebster.com/dictionary/interoperability (accessed on 25 May 2018). 7. IES Team. IES—Integrating the Energy System. Available online: www.iesaustria.at (accessed on 30 October 2018). 8. Gottschalk, M.; Franzl, G.; Frohner, M.; Pasteka, R.; Uslar, M. Structured workflow achieving interoperable smart energy systems. Energy Inform. 2018. [CrossRef] 9. European Commission. Digital Single Market. Available online: https://ec.europa.eu/commission/ priorities/digital-single-market_en (accessed on 30 May 2018). 10. IEC 62559-2:2015. Use Case Methodology—Part 2: Definition of the Templates for Use Cases, Actor List and Requirements List; IEC TC8 Standard; IEC: Geneva, Switzerland, 2015. 11. Gottschalk, M.; Uslar, M.; Delfs, C. The Use Case and Smart Grid Architecture Model Approach: The IEC 62559-2 Use Case Template and the SGAM Applied in Various Domains; SpringerBriefs in Energy; Springer: Berlin/Heidelberg, Germany, 2017. 12. CEN-CENELEC-ETSI Smart Grid Coordination Group. First Set of Standards; Technical Report; CEN-CENELEC-ETSI Smart Grid Coordination Group: Brussels, Belgium, 2012. 13. Englert, H.; Uslar, M. Europäisches Architekturmodell für Smart Grids-Methodik und Anwendung der Ergebnisse der Arbeitsgruppe Referenzarchitektur des EU Normungsmandats M/490. In Proceedings of the Tagungsband VDE-Kongress, Stuttgart, Deutschland, 5–6 November 2012; Technical Report. 14. SG-CG/RA. Smart Grid Reference Architecture; Technical Report; CEN-CENELEC-ETSI Smart Grid Coordination Group: Brussels, Belgium, 2012. 15. The Open Group. TOGAF Version 9—The Open Group Architecture Framework (TOGAF), 9th ed.; The Open Group: San Francisco, CA, USA, 2009. Energies 2018,11, 3375 25 of 26 16. Urbauer, P.; Sauermann, S.; Frohner, M.; Forjan, M.; Pohn, B.; Mense, A. Applicability of IHE/Continua components for PHR systems: Learning from experiences. Comput. Biol. Med. 2015 ,59, 186–193. [CrossRef] [PubMed] 17. Noumeir, R. Integrating the healthcare enterprise process. Int. J. Healthc. Technol. Manag. 2008 ,9, 167. [CrossRef] 18. IHE International. Gazelle—eHealth Test Framework for Interoperability. Available online: https://gazelle. ihe.net/ (accessed on 30 October 2018). 19. Frohner, M.; Gottschalk, M.; Franzl, G.; Pasteka, R.; Uslar, M.; Sauermann, S. Smart Grid Interoperability Profiles Development. In Proceedings of the 2017 IEEE International Conference on Smart Grid Communications, Dresden, Germany, 23–26 October 2017. [CrossRef] 20. Smart Grid Mandate. Methodologies to Facilitate Smart Grid System Interoperability through Standardization, System Design and Testing. Available online: https://www.google.com. tw/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=2ahUKEwie3vD7_ _3eAhXCEnAKHRGNCyoQFjAAegQIAxAB&url=https%3A%2F%2Fwww.researchgate.net% 2Fpublication%2F322752190_Smart_Grid_Interoperability_Testing_Methodology_A_Unified_Approach_ Towards_a_European_Framework_for_Developing_Interoperability_Testing_Specifications&usg= AOvVaw1MICQd3PD5VnSUZxHksKpy (accessed on 30 October 2018). 21. Wolfgang, B.; Heiko, E. Basic Application Profiles for IEC 61850. 2013. Available online: https://docstore. entsoe.eu/Documents/RDCdocuments/BAP_concept_TC57WG10.pdf (accessed on 30 October 2018). 22. Masera, Marcelo. The Role of Interoperability in the Digital Energy Vision. 2017. Available online: https://www.etip-snet.eu/wp-content/uploads/2017/06/2.-The-role-of-Interoperability-MarceloMasera.pdf (accessed on 30 October 2018). 23. Forsberg, K.; Mooz, H.; Cotterman, H. Visualizing Project Management—Models and Frameworks for Mastering Complex Systems, 3rd ed.; John Wiley & Sons, Inc.: Hoboken, NJ, USA, 2005; pp. 108–116, 242–248, 341–360. 24. Industry Alliance VHPready e.V. VHPready. Available online: https://www.vhpready.com/ (accessed on 30 November 2018). 25. IEC 60870-5-104—Telecontrol Equipment and Systems—Part5-104: Transmission Protocols—Network Access for IEC 60870-5-101 Using Standard Transport Profiles. Available online: https: //www.google.com.tw/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved= 2ahUKEwj81rL6_v3eAhUJfnAKHSfIBgYQFjABegQIBhAB&url=https%3A%2F%2Fwebstore.iec.ch% 2Fpublication%2F3746&usg=AOvVaw2LLUacS4XK_It0q8rsKXnt (accessed on 30 October 2018). 26. IEC 61850-7-420:2009—Communication Networks and Systems for Power Utility Automation—Part 7-420: Basic Communication Structure—Distributed eNergy Resources Logical Nodes. Available online: https://www.google.com.tw/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved= 2ahUKEwiZo4jE_v3eAhXYQd4KHX35Ab4QFjAAegQIBRAB&url=https%3A%2F%2Fwebstore.iec.ch% 2Fpublication%2F6019&usg=AOvVaw2BLqlPG9vYoFh7SuXlbmGj (accessed on 30 October 2018). 27. Eisl, Hubert. ELGA Erfolgreich Gestartet. 2016. Available online: http://ihe-austria.at/elga-erfolgreichgestartet/ (accessed on 30 October 2018). 28. Franzl, G.; Frohner, M.; Gottschalk, M.; Reif, V.; Koch, G.; Berger, A. Interoperabilität im Datenaustausch in der Energiewwirtschaft—Vom Use Case zum Test der Integrationsprofile. In Proceedings of the Symposium Energieinnovation 2018, Graz, Austria, 14–16 February 2018. [CrossRef] 29. IHE Europe. Whitepaper on Connectathon. The IHE Connectathon. What Is It? How Is It Done? Version 004. Available online: https://www.google.com.tw/url?sa=t&rct=j&q=&esrc=s&source=web&cd= 3&cad=rja&uact=8&ved=2ahUKEwjU-t_q_f3eAhWI62EKHT46BAsQFjACegQICBAC&url=https%3A% 2F%2Fwww.ihe-europe.net%2Fsites%2Fdefault%2Ffiles%2FWhitePaper_Connectathon_2016.pdf&usg= AOvVaw3vNVAnPQmRWdfV5aSS8e5h (accessed on 30 October 2018). 30. ISO DTR 28380-1: Health Informatics—IHE Global Standards Adoption—Part 1: Process. Available online: https://www.google.com.tw/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved= 2ahUKEwil7-W3_f3eAhUYIIgKHcYsBFYQFjAAegQIAhAB&url=https%3A%2F%2Fwww.iso.org% 2Fstandard%2F63383.html&usg=AOvVaw1iuYOVXKoGsFrnfKhE6ucA (accessed on 30 October 2018). 31. Europa Analytics. An Introduction to the European Interoperability Reference Architecture (EIRA) v2.1.0. Available online: https://joinup.ec.europa.eu/sites/default/files/distribution/access_url/2018-02/ b1859b84-3e86-4e00-a5c4-d87913cdcc6f/EIRA_v2_1_0_Overview.pdf (accessed on 30 October 2018).