1 Introduction

Interoperability is a key requirement for the digitalisation of processes that involve different systems and sectors. Openly available specifications enable cost-effective system integration across vendor and sector boundaries. Modern standards often include optional features to provide application and implementation flexibility to cover a wider filed. However, interoperability can be achieved only if the usage of optional features is harmonised across integrated systems. Use case specific integration profiles achieve exactly that. These profiles are compiled into a framework referring to a business domain to be harmoniously reused. They specify which features of which standard shall be used to design solutions (actors) that contribute to particular processes (transactions). A transparent profiling process involves all stakeholders, fosters friendly competition, achieves investment protection, ensures improved market acceptance, and increases product and solution smartness [1].

The project IES Austria “Integrating the Energy System” [2] adapted the ISO TR 28380 profiling process established by Integrating the Healthcare Enterprise (IHE) in the medical IT sector [3], where for example the European Health Data Space (EHDS) [4] and the Austrian health record ELGA [5] are based on processes specified as IHE integration profiles. The adapted methodology outlined in the IES Cookbook [6] provides a tailor-made approach offering suggestions for every step of the process necessary to achieve seamlessly interoperable solutions for particular use cases.

New profile drafts are jointly developed in the course of the transnational funded ERA-Net SES projects SONDER and R2EC, and the national e!MISSION projects c‑Flex and UCERS, solving exemplary use cases and challenges. Collaborative R&D implies the cooperation of different stakeholders toward a novel solution. The individually contributed expertise complements each other and yields different views from requirements to realisation. This is exactly the knowledge transfer needed for IES integration profiles. A major aspect for innovation diffusion is the ease of integration or substitution in existing environments [7]. IES Integration Profiles achieve exactly that. They are open access and state the essence for replicability [8]. The project IRS-Cargo adapted the profiling approach for the railway sector [9], in another conservative operation technology (OT) stronghold where now information technology (IT) needs to be integrated to achieve end-to-end process digitalisation.

Section 2 sketches the IES process and key features, in particular the characteristic difference to common standard and regulatory conformity certification processes. Section 3 to 5 introduce three new integration profiles developed in best possible accordance to the IES methodology. Experiences from applying the IES approach in this initial phase of the process are summarised in Sect. 6, comprising the shared conclusions and lessons learned.

2 The key to open interoperability

The National Interoperability Framework Observatory (NIFO) describes an interoperability model which is applicable to all digital public services and may also be considered as an integral element of the interoperability-by-design paradigm [10]. It includes four layers of interoperability: legal, organisational, semantic and technical, a cross-cutting ‘integrated public service governance’ layer, and a background layer covering general interoperability governance. In a more IT/OT centric fashion these layers can be transferred into five layers that loosely relate to the layers of the SGAM, the Smart Grid Architecture Model [11, 12]:

  • Legal interoperability: Business requirements (contractual and regulatory)

  • Semantic interoperability: Common understanding of information exchanged

  • Syntactic interoperability: Common encoding and formatting of information

  • Technical interoperability: Common interfaces and procedures to exchange information

  • Operational interoperability: Reliability of information exchange and execution

The later on presented profile examples cover the mentioned layers as needed and as good as possible yet. Not every use case refers to all layers. Thus, the IES methodology needs to be applied smartly and not by the letter down to the last bit. Whether integration profiles are specified sufficiently detailed, or need to be amended, is finally assessed during the peer-to-peer testing, when inconsistent understanding and gaps become apparent. Gathering feedback on any issues concerning the specifications from the participants is essential. At first, every new profile is published as trial version. Only after three independent peers have tested their implementation against other peers successfully, a trial profile may become mature. At that point it is assumed that compliant designed components can be integrated out-of-the-box with other accordingly designed components into a cooperative system-of-systems. Not necessarily plug-and-play, but configurable to interact seamlessly. For perfect interoperability, i.e., entirely obstacle free integration, all applied standards would need to be publicly available. However, in the energy sector standards are not public in general, but accessible to whoever purchases a license upfront.

The IES methodology relies on the pillars show in Fig. 1, which contribute hand-in-hand toward achieving interoperability: (1) Joint writing of integration profiles involving as many contributing stakeholders as possible, (2) early prototype implementation testing among peers preventing sunken costs of misinterpretation, (3) testing success records and a public repository of products that claim to be compliant. Note that tests based on prototypes and executed by peers clearly do not qualify for product certification. That can be added a posterior, as a final step in the product development process, but obviously needs to be performed at qualified laboratories, and executed by neutral personnel against accredited reference systems.

Fig. 1
figure 1

The three pillars of the IES methodology and the peer-to-peer focus [6]

Full size image

The core of the IES methodology is the peer-to-peer testing where everything comes together. To test how different components communicate and mutually use the exchanged information, we need specifications: (A) Profiles that tell how and when information shall be exchanged and (B) test cases that assess whether information exchange and responses are correctly realised for the particular use case. Integration profiles are specified top-down and application centric, in contrast to standards aiming toward universality. Profiles specify only what is necessary to achieve the cross-system functionality needed for a specific use case, i.e., the details that need to be known by the communicating components, which anyhow can be observed on the receiver side. How these features are implemented inside vendor black-boxes shall not be specified, restricted or revealed.

To support legacy system integration, every profile that reached maturity remains available forever, even when no more requested for testing. Only the test participants decide which version of a profile is tested, i.e., which they implement. Attractive profiles prosper and unpopular gather dust, thereby achieving implicit selection of the fittest. The profile drafts sketched next are early trial versions. Their attractiveness has yet to be verified.

3 Managing an Energy Storage System (ESS) using IEC 61850

Several ongoing R&D projects joined forces to maximise viewpoints and resources. First, common understanding needed to be achieved on what could energy communities be, realising the plurality of possibilities and identifying common integration challenges. These have been published as IES Technical Framework on Local Energy Communities (TF-LEC) Vol. 1 [13]. Since than, the members of the involved R&D projects, namely cFlex, SONDER, and R2EC, worked on specifying this profile, assuming that coordinated energy storage is an essential feature for optimised energy sharing across an energy community. End of 2021, the 2nd edition of the IEC 61850-7-420 standard focusing on distributed energy resources (DER) has been released. It defines two logical nodes (LNs) that appear essential for Renewable Energy Communities (REC). First, the mixed resource LN (DMDR) required to cover any combination of assets managed, which may be used cascaded, and second the storage LN (DSTO), on which the IEC 61850 Storage Integration Profile is focused. Figure 2 shows the transactions required for the storage management use case.

Fig. 2
figure 2

Actors-Transactions-Diagram to manage an ESS using the IEC 61850 Storage LN [15]

Full size image

The battery management (forward energy planning) needs to be settled ahead of time, whereas the control of the power charged or discharged (actual power control) is performed just-in-time. Thus, two communication cycles exist in parallel. Transaction (1) is rather evident, monitoring of storage asset parameters. Using IEC 61850 this is achieved by specifying an accordingly composed dataset, which is managed by a report control instance. Transaction (2) “Offer Storage Flexibility” is yet out of the scope because offering flexibilities is an ongoing research topic [14]. Thus, the existence of (2) and related requirements are yet noted only. Transaction (4) is actually executed by a schedule controller instance (FSCC), a functional node that executes functional schedules (FSCHs). Transaction (3) refers to a profile from the IES Austria project and adds some additional IEC 61850 features learned. The sequence diagram in Fig. 3 shows the required steps.

Fig. 3
figure 3

Sequence-Diagram for transaction (3) on transferring and enabling a schedule [15]

Full size image

First, an FSCH instance is configured inside the EMNG (energy manager) black-box, where a client copy is present, and mirrored to the STOM (storage manager) black-box by IEC 61850 client-server connectivity. To trigger the validity check by the STOM actor, the EnaReq flag needs to be set. If validity is granted, the FSCH state changes to enabled and the FSCH can be executed by the FSCC. If not, the SchEnaErr data object of the FSCH tells the reason using Enum-flags. To realise for example the STOC actor, several ‘adjacent’ IEC 61850 LNs are required, as shown in Fig. 4.

Fig. 4
figure 4

IEC 61850 LNs required to configure the storage control (STOC) actor [15]

Full size image

Explaining every LN would be excessive here, where we focus on the methodology and its utility. However, the three figures from the integration profile on storage integration show the top-down approach and how detailed profile specifications can become, where needed. Actually, much time was lost on discussing IEC 61850 basics. In that respect, the lack of experts that know how to use IEC 61850 in practice is critical. Yet, it cannot be assure that the stated specifications are concise, they were tested among different software tools only, not with real hardware connected.

4 Signalling the current grid state with RGB traffic light

The next TF-LEC Integration Profile presented shows that profiles can be specified in different depth, depending on technology readiness and need. Where only a single communication protocol is in use, the profiles shall mention it, but needs not specify it. Same applies for situations where any communication protocol/technology can be used, as it applies for the public grid state signalling outlined in [16]. Thus, IES Integration Profiles can vary in detail and style, but always consist of normative/harmonising specifications. The growing number of profiles made available one-by-one constitute Vol. 2 of a technical framework [15]. Options, where essentially needed, may demand a Vol. 3, and regionally mandatory adjustments constitute a Vol. 4, as in [17].

Having addressed the usage of distributed storage assets to respond to requests, either just in time or via optimised day-ahead schedules, as for example outline in [18], we identified the lack for some information on the current grid state to enable a responsive, grid friendly, behaviour. Considering end-customer owned renewable energy sources (RES), widely distributed across the low voltage grid level, it appears that three colours (good, alert, and alarm) are insufficient. For example, if peak PV-production causes curtailment of green energy generation it is wise to increase the consumption from the local grid, e.g., charge a local ESS and use that energy later when less green electricity is generated, to relieve a little the local generation curtailment. If there is too much load and load shedding imminent, a prosumer might insert generated energy instead of charging a private EES.

The grid traffic light signal specified in Fig. 5 is composed of three bits: Red indicating any alarm situation, either locally enforced load shedding or generation curtailment. Blue indicates power flow from the next higher transformer toward lower grid levels and end-customers. Green indicates local generation, either reversed power flow toward higher grid levels, or a significantly reduces energy flow from higher grid levels. For this profile, the harmonisation targets on common understanding, interpretation, and response to the signals, and less on the communication means. The signal needs to be distinct to achieve the harmonised response that yields the grid friendly behaviour intended.

Fig. 5
figure 5

Interpretation of colour signals from the RGB Grid Traffic Light [15]

Full size image

When which light glows is finally determined by the local distribution system operator (DSO) only. Evidently, if the grid supply is disconnected (the load shed), neither green nor blue shall be alight, only red may glow. In case the power flow across the transformer is reversed, i.e., more power is inserted locally than is consumed, blue shall be off, and only green shall glow. If in the region covered no power is locally inserted, green shall be off, and only blue may glow. These rules limit, but do not exactly determine, the green and blue light setting. Any threshold in between the boundaries is possible and can be used to fit the customer response to grid needs. During green light only, grid tariffs might be waived, and incentives alike may be implemented to purge the customers to respond as intended on a cellular level. This behaviour shall support a save and still efficient grid utilisation that maximises the local RES connection capacity and renewable power insertion.

5 Receiving metered energy data from the AMI operator

Legal data exchange among stakeholders involved in the energy system is often harmonised by national regulations. This also applies for Austria, where the automated data exchange among stakeholders is managed by a data exchange platform (EDA). The national requirements and conventions are specified in a dedicated national Technical Framework, which is written in German for better understanding by the local stakeholders and policy makers. Yet, there is no global specification, and thus this first attempt may become a blueprint for others if adopted beyond national boundaries.

Figure 6 shows the directly involved stakeholders and indicates the key data exchanges needed to start and run a renewable energy community. Briefly, the data exchange is based on a complex process and XML-scheme, the CR_MSG process [20] and the Consumption Record XML scheme [21]. The overhead is typical for XML and provides a lot of redundant information required to check the correctness and sanity of the received meter-data set.

Fig. 6
figure 6

EDA based automated data exchange in Austria (based on [19])

Full size image

However, to establish and run an Energy Community, many more processes are required. These are summarised in Fig. 7. The transactions (processes) and the data formats (XML-schemata) are specified by ebUtilities, and can be publicly accessed from their webpage [22]. Only the actor needs remain to be specified, and consequentially is specifying these operational needs for an automated Energy Community management the core aim of the national technical framework.

Fig. 7
figure 7

ebUtilities processes to establish and run Energy Communities in Austria (based on [19])

Full size image

6 Lessons learned and conclusions drawn

First and throughout the process, common understanding of the diverse interoperability needs shall be maintained, e.g., using the TOGAF methodology [23]. Second, focusing on the transaction and not the individual realisation is hard to achieve among engineers primarily focused on realisations, but latter leads to standard conformity, which here is not the topic. Third, the intention of profiles is easily lost: Profiles are not written for scientific rigour, but for the engineers designing components that shall communicate with peer systems from other vendors out-of-the-box. These issues and the lack of process experience prevented a more productive cooperation. Participants waited for the others to tell what is needed, causing a circular choke. Design thinking did not happen, indicating a team exercise to be better trained. Without practical creativity skills, joint profile writing is nearly impossible, in particular if those that have solid expertise do not participate or are too anxious to share their experience. Such behaviour leads to loosely stitched monographies, not a joint result.

A question mark should be added in the end of the article’s title, if we only consider the effort and unsure future adoption by vendors and regulation bodies. But for medical IT, it took a decade to achieve momentum and nearly two decades to become a requirement for some public tenders. Thus, the approach is still appealing, even though the publicists seemingly gave up quite early. The railway sector investigates an adoption of the IHE methodology in the project IRS Cargo [9], where a first trial profile addresses the “Path request and Path allocation” use case applying the new EU directive 2021/541 [24]. Both, the energy sector and the railway sector, showed that a legal directive on European level can serve as a starting point. The settled legal requirements than trigger a new profile stating the derived semantic, syntactic, technical and operational needs for interoperability.

However, peer-to-peer testing is the true heart of the IHE/IES/IRS methodology, and that shall drive the voluntary development of profiles in the long term. For now, to solve the hen-egg-problem that no testing without profiles raises no attraction for writing profiles, R&D projects offer a suitable environment to develop profiles. Not for the benefit of the methodology, but to deliver sustainable results in a structured form, such that they can be revived and replicated beyond the R&D project. If that is achieved, profile writing is a success straight away. Thus, profiling should be encouraged by funding bodies, e.g., a common practice, to achieving impactful results and interoperable solutions. Practically, the method is applicable likewise for every sector where digitalisation is envisaged.