Introduction

The energy transition toward renewable energy sources (RES) is urgently needed. Fossil fuels that artificially add CO2 to the atmosphere are no sustainable primary energy source. More RES, like solar, wind and water energy, shall be used to generate electrical energy. These energy sources are fluctuating, they are not available in the same amount at all times. To efficiently utilize RES, a mix of these sources and close cooperation and management of a wide range and number of individual power generating assets is required. Therefore, interoperability is essential.

Interoperability (IEEE Std 610.12– 1990 1990; Merriam-Webster Incorporated 2018) is a key factor for a successful integration of Smart Energy systems into the established energy distribution management. To reliably operate such a huge physically connected system of systems, individual components need to cooperate. Integrating Smart Energy services like Virtual Power Plants (VPPs) demands comparably effective cooperation of introduced systems (Ramchurn et al. 2012; Kroposki et al. 2017), among each other and in respect to established grid control mechanisms. Therefore, specifications are needed that sensibly specify data models and protocols to achieve a seamless data exchange between independent systems. Here, the VPP serves as application example.

Vendors and customers have to be sure that system interaction works, before going operational in the field. If this is ensured, the deployment of VPPs and other Smart Grid solutions from different vendors is possible, which would greatly support a fast and dynamic energy transition via the open competition of different solutions. A holistic process that supports vendor-neutral interoperability among different solutions and systems is the core objective of the project Integrating the Energy System (IES) Austria.

In section “IES workflow”, the IES workflow is introduced. The testing process and the 1st Connectathon Energy are presented in section “Connectathon Energy 2018 at The Hague”. The IES workflow validation and first findings of the Connectathon Energy are summarized in section “Realization of the IES workflow (trial)”. Section “Outlook” concludes the paper providing an outlook on the next steps in establishing IES.

IES workflow

The project IES attempts to migrate and adopt an established methodology on achieving interoperable IT systems delivered from different vendors. The methodology has matured over many years in the medical sector, starting with digital X-ray images (radiology) in 1999, and by today achieved wide acceptance in the US, Europe and East Asia. The methodology implements the four basic steps shown in Fig. 1.

  1. 1.

    Identify use cases where interoperability is an issue and specify these by identifying system borders and requirements (Gottschalk et al. 2017).

  2. 2.

    Jointly identify how certain interoperability issues can be prevented best and specify it normatively as Integration Profile (Frohner et al. 2017).

  3. 3.

    Test independent prototype solutions against each other on annual plugfest and improve the Integration Profile until it is firm (IHE Europe 2016).

  4. 4.

    Publish successful testing activity: who has successfully tested an Integration Profile, which products implement which Integration Profiles (IHE Europe 2016).

Fig. 1
figure 1

IES Process in brief: The four basic steps of the methodology to achieve interoperability

Full size image

The core idea of this methodology is lively cooperation. Integration Profiles shall be living documents that improve and grow until they become stable. In practice, the basic steps split up into a number of individual steps (Franzl et al. 2018). Users and vendors participate in the process as peers and jointly contribute to developing demand-oriented solutions.

When it comes to testing the individual implementation of profiles, all peers participating in a test case have a common goal: they want to ultimately pass the test. The IHE Connectathon (plugfest) provides the environment and time to learn and make corrections prior to running the final, recorded and monitored, test. Comments on errors revealed at the Connectathon are the most valuable and powerful input to improving the Integration Profiles. This feedback is practice driven and supports the Integration Profiles in becoming a most reliable basis for interoperable systems development (IHE Europe 2016).

The process coordination and control of the IES process is handled by peer committees, e.g., industry delegates. They manage and implement the industry integration process, as performed by IHE. Their influence may be subsidiary and hidden by the shining results, being Integration Profiles and test events organized, but it requires coordination and cooperation to achieve interoperability. Committees are a way to support the required socializing among industries. The formal requirement for a committee is that it shall be addressable, so tasks can be forwarded to it, and that its decisions are jointly accepted. If one person can assume a committee’s task, that person can be it. Committees fulfill required roles, which demand certain skills.

To coordinate and control the IES process, different skills are essential to execute various management tasks. The foreseen skills-grouping (i.e., the committee composition) is depicted in the center of Fig. 2. These committees constitute functional roles required to execute the process. Experts may serve in one, two or all, depending solely on the skills they actually contribute.

Fig. 2
figure 2

Functional composition of Integration Profiles, Managing Committees, and Integration Testing

Full size image

The main working bodies are the planning committee and the technical committees. The former assigns Integration Profiles to Technical Frameworks (TF) and organizes testing events, which includes the decision whether profiles are ready for testing, either as trial or mature Integration Profile. The latter are task forces writing Integration Profiles and specifying test scenarios and tools. In between and slightly above the two resides the domain coordination, consisting of experts covering all domains. This board decides which domain a TF shall be assigned to and support technical committees in proposing cross-domain reuse of existing Integration Profiles.

A TF is dedicated to a Business Case, e.g., the operation of a VPP, which belongs to a Business Domain, here the electrical energy production, distribution, regulation, and market area. The structure of the TF is divided into two volumes: The first part describes the informative view by a business case overview and business functions that result from Use Cases with interoperability issues. The second part contains normative solutions grouped into Integration Profiles, which contain the message exchange, specified as Transactions, and the Actors (software modules) that perform it as depicted on the left side of Fig. 2.

Connectathon Energy 2018 at The Hague

Integration Profiles specify requirements on how different assets (actors) exchange information in order to comply with, and support, the larger business cases. Vendors who implement these specifications may conduct conformance tests within their companies ensuring that their implementation meets their requirements. These tests only ensure that implemented software products provide functionalities in a way the vendor interpreted specifications. If there is interpretation potential, different vendors can implement the same specifications differently. To overcome this hazard, peer-to-peer interoperability testing among independent vendors is necessary. IHE supports this kind of testing at the annual Connectathon test events (IHE Europe 2016), where vendors come together for a whole week and test whether information can be exchanged according to IHE Integration Profiles between their systems, comprising interoperability and conformance tests, as shown on the right side in Fig. 2. At the same time, the Connectathon brings implementers together for discussion, and provides the community a forum for validating the stated specifications. Technically, IHE provides the test bed Gazelle (IHE Europe 2018), which is a browser-based tool that provides features for test-case management, system management, test-case documentation, and test-validation, among others.

Gazelle’s validation tools are primary using XML validation methodologies, i.e. the validation services check the XML payload if it is well-formed, whether the payload adheres to the specification stated within an XML schema file, and if specified business rules are correctly considered using XML schematron validation. Another feature of Gazelle is its capability to capture messages that are exchanged between systems under test (SUT), utilizing a specifically designed proxy server. To use this feature, the SUTs are configured to communicate via Gazelle’s proxy, as shown in Fig. 3. Within the proxy, corresponding forwarding rules need to be configured, i.e., a message received at the proxy at a specified port is on-the-fly logged and forwarded to the receiving SUT. The logged messages are handed over to Gazelle’s internal or external validation tools.

Fig. 3
figure 3

The alternative communication between systems via Gazelle proxy service. The port numbers are assigned to the systems prior to start the testing session. Subsequently, the transferred messages are captured and undergo further validation

Full size image

Realization of the IES workflow (trial)

At the IHE Connectathon 2018 in The Hague, Netherlands, the 1st peer-to-peer testing sessions of systems from four vendors were conducted, successfully proofing the applicability of the methodology and the Gazelle testbed. The interoperability tests performed at this test event were: sending data from an IEC 61850 client to an IEC 61850 server and vice versa, representing communication examples as they occur among the systems of a VPP. More precisely, sending configuration data from VPP assets to the VPP operator, sending a schedule from the VPP operator to VPP assets, and pulling measurement values from VPP assets. A core aim of the 1st Connectathon Energy was to test the configuration of the Gazelle testbed and its application in the energy domain using exemplary Integration Profiles, made publicly available on the IES project website (IES project website 2018).

The test environment at the Connectathon floor was a dedicated local area network (LAN), managed by the IES team independent from the LAN used by the medical systems participating in the IHE Connectathon Europe. The exchanged messages, as defined by exemplary Integration Profiles, have been recorded using the proxy of a dedicated Gazelle instance installed in Vienna, Austria, at the University of Applied Sciences Technikum Wien. The proxy was connected over the public Internet using a virtual private network (VPN) tunnel, as shown in Fig. 4.The Gazelle tools to configure and manage test-cases were accessed using the web interface, for which no VPN tunnel was required. This setup enabled recording and validation of exchanged messages on site in The Hague, using the machine running in Vienna.

Fig. 4
figure 4

Schematic set-up for interoperability testing between two systems. The one-directional communication via VPN connection is captured, transformed and validated by Gazelle

Full size image

Outlook

Based on experiences from the 1st Connectathon Energy in The Hague 2018, including the preparation time for this test event, one lesson-learned is that iterative refining of specifications within Gazelle and in Integration Profiles is rather inevitable. Participants reported that assertions and requirements need to be formulated more restrictive, and that Gazelle’s feature for pre-Connectathon testing should be utilized to run conformance tests in advance of the face-to-face test event. Vendors that claim, that an interface is implemented according to the IES Integration Profile specification, are encouraged to upload the generated message’s content to Gazelle for validation purposes. However, a first test-set with different vendors was successfully built and the Gazelle installation could be tested. The 2nd Connectathon Energy will be a dedicated event in Vienna, 28th to 31st January 2019, independent of IHE. New Integration Profiles shall be tested with more vendors. Further information can be found on the IES website (IES project website 2018).

The efforts of the IES Austria project team have succeeded in being considered by the ISGAN initiative. An objective of ISGAN Annex 6 is to establish a long-term vision for the development of future sustainable power systems (ISGAN International Smart Grid Action Network 2011). IES Europe is listed as activity A4-IA0–5 in the European Strategic Energy Technology-Plan (SET-Plan). The SET-Plan pursues implementation plans for key actions, like increasing resilience and security in the energy system (Temporary Working Group 4 2018), where IES Integration Profiles may play an important role. This listing supports the opportunity to include the specification of IES Integration Profiles in the course of international R&D projects with great visibility.