MethodPDF Available

The IES Cookbook - Enabling interoperability the IES way - Edition 0.8

January 2019

DOI:10.13140/RG.2.2.13780.86409

Authors:

Gerald Franzl

University for Continuing Education Krems

Marion Gottschalk

Richard Pasteka

University of Applied Sciences Technikum Wien

Foster openly interoperable energy systems enabling broad stakeholder cooperation in the requirements analysis and prototype testing phases. Vision is predictive interoperability among systems developed by vendors independently and composed into system-of-systems fulfilling use-case specific customer demands. The method specifies stakeholder cooperation, no technical solution.

The three pillars of the IES methodology

…

The IES process in four steps: identify → specify → test → sell.

…

IES timing is centred on the annual Connectathon Energy

…

Plurality of desirable expertises in IES teams and committees

…

Figures - uploaded by Gerald Franzl

Content may be subject to copyright.

Content uploaded by Gerald Franzl

Content may be subject to copyright.

The IES Cookbook

Enabling interoperability the IES way

Edition 0.8 – 21st January 2019

S O F T W A R E

A I

C O

The project IES is part of the ’e!MISSON’ program’s 2nd call funded via the Austrian Climate and Energy Fund (KliEn),

managed by the Austrian Research Promotion Agency (FFG) under contract number 853693. IES is powered by the

Climate & Energy Fund within the program ’Energy Research 2015’.

Document Title: The IES Cookbook

Authors: Gerald Franzl, Richard Pasteka, Marion Gottschalk

Version: 0.8

Date: 21st January 2019

File name: IES_cookbook.pdf

Change history:

2019.01.21 ofﬁcial release for publication (print and distribute)

2019.01.28 publicly presented at Connectathon Energy 2019, Vienna, Austria

This cookbook is intended for IES participants and addresses all aspects of the IES process, from agreeing on

an interoperability issue to organising the annual Connectathon Energy event. The different focus is reﬂected

by dedicated parts. It starts with Integration Proﬁle Development because without proﬁles all other parts are

meaningless. Where no own experience recommends amendments, the steps are based on established IHE

practice (www.ihe.net) and common sense.

The IES-Austria project team are:

•Technology Platform Smart Grids Austria

1060 Vienna, Austria

•Tiani Spirit GmbH

1220 Vienna, Austria

•FH Technikum Wien

1200 Vienna, Austria

•OFFIS e.V.,

26121 Oldenburg, Germany

•AICO EDV-Beratung GmbH

2122 Ulrichskirchen, Austria

S O F T W A R E

A I

C O

•Sprecher Automation GmbH

4020 Linz, Austria

This IES cookbook is ﬁrst published end of January 2019 in the course of the Connectathon Energy 2019,

Vienna, Austria. It concludes the national funded IES Austria project. Currently, it has no ISBN or DOI assigned.

Alike all IES documents, the IES cookbook shall be a living document, that may be adjusted to consider

feedback and changing environmental conditions. Being the ﬁrst published version, this edition has trial

status indicated by a version number less than one.

This work is licensed under a Creative Commons “Attribution-ShareAlike 4.0 International” licence.

T  

Table of contents

Executive Summary 1

Abstract ............................................................................ 1

IESworkﬂow ........................................................................ 2

Shortnarrativeonprocessbasics ...................................................... 3

Beneﬁts–implicitandexplicit ......................................................... 3

Frameworkstructure .................................................................. 4

Processtiming ....................................................................... 5

Crosscuttingcollaboration ............................................................. 6

Getincontact–getinvolved ........................................................... 6

I Integration Proﬁle Development 7

1 Explain the Business ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ application experts 7

1.1 State the interoperability demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Identify Interoperability Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Evaluate solution options ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ system architects 8

2.1 Deﬁne functional actors and transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 State constraints and requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Choose existing practices and international standards . . . . . . . . . . . . . . . . . . . . 8

3 Specify Integration Proﬁle ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ implementation experts 9

3.1 Deﬁne the Interoperability Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 List standards and best practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Specify architecture building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Specifytransactions...................................... 10

3.5 Specifyactors......................................... 11

4 Publish new speciﬁcations ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ domain experts 12

4.1 Publishfortrialtesting .................................... 12

4.2 Publish a revision – achieve maturity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

II Integration Proﬁle Testing 14

5 Prepare for testing ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ testing experts 14

5.1 Deﬁnetestscenarios ..................................... 14

5.2 Specify test sequences and reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.3 Create simulators (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.4 Preparevalidationtools .................................... 16

6 Testing at Connectathon Energy ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ implementer 16

6.1 Testingeventpreparation ................................... 17

6.2 Executepeer-to-peertesting.................................. 17

6.3 Get impartial success validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7 Publish success ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ testing management 18

7.1 Show success in Results Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7.2 Issue Integration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7.3 Get listed in products repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

The IES Austria team

T  

III Integration Proﬁle Management 20

8 Proﬁle proposal & revision ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ IES community 20

8.1 Establish a Technical Committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8.2 Evaluateaproposal ...................................... 21

9 Proﬁle assignment & release ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ domain experts 22

9.1 Establish a Planning Committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9.2 Support from Domain Coordination Committee . . . . . . . . . . . . . . . . . . . . . . . . 23

10 Connectathon Energy organisation ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ event experts 23

10.1 Attendeemanagement .................................... 23

10.2 Event preparation and execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

10.3 Side events, catering and IES marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

IV Appendix 27

ADocumenttemplates ................................................................. 27

BFlexible decomposition of speciﬁcations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

CProﬁle complexity recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

DCertiﬁcation approaches and examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

EDeﬁnitions .......................................................................... 29

FAbbreviations ........................................................................ 31

ListofFigures ....................................................................... 31

Acknowledgements ................................................................... 31

References .......................................................................... 32

The IES cookbook cba

The IES Cookbook

Enabling interoperability the IES way

21st January 2019

Executive Summary

Abstract

Integrating the Energy System (IES) recognises interoperability as a key enabler for the deployment

of smart energy systems, enabling new business options. Interoperability, is covered in the SET-Plan

activity A4-IA0-5 and the ISGAN Annex 6: Power Transmission & Distribution Systems.

Smart energy systems rely on trustworthy means to smoothly exchange digital information.

Interoperable products enable heterogeneous systems and services based on components from any

vendor offering solutions and devices tested according to the IES rules. Smart energy systems can

be customised and adjusted on demand.

The stakeholder process proposed and maintained by IES [1], adopts the holistic IHE methodology

standardised in ISO DTR 28380-1 [2]. This methodology evolves and spreads since 1999, driven by

IT vendors from the health sector intending to achieve interoperable IT components for healthcare.

The brain of the approach are the Integration Proﬁles, which normatively state how to combine and

implement established standards and good practice. The heart is the testing activity at an event

called Connectathon Energy because it is about connectivity. The legs that shall get interoperable

products to the market, are the Results Browser and the Integration Statements issued to state that

a vendor offers compliant IT solutions.

Figure 1: The three pillars of the IES methodology

These core parts constitute the three pillars shown in Figure 1. Together, they foster sustainable and

efﬁcient development and deployment of interoperable components for smart energy systems.

Finally, the creators of interoperable solutions and components are the hands that make interoper-

ability ﬂourish. In this cookbook, the steps and procedures of the IES process are outlined together

with narrative explanation, reasoning, options and some background information.

E S

IES workﬂow

The IES process is structured in the four basic steps shown in Figure 2, which split up into many

intermediate steps and recursions presented in this cookbook.

Figure 2: The IES process in four steps: identify →specify →test →sell

1. Identify Use Cases where interoperability is an issue and specify these by identifying system

borders and requirements [3].

•Assign an interoperability issue to a domain (identify where the issue belongs to)

•Write a Business Overview (deﬁne actors, the environment and the general issue)

•Describe Business Functions (use the Use Case Method and UML use case diagrams)

•Reuse Integration Proﬁles where possible (save speciﬁcation and test effort)

2. Jointly identify how interoperability issues can be prevented and specify the requirements

normatively as Integration Proﬁle [4].

•Evaluate which standards can be used to fulﬁl the Use Case requirements

•Specify the process to realise a Business Function (UML sequence diagram)

•Deﬁne the actors and transactions (decompose Meta-Actors into modules)

•Describe the role of the individual actors (modules)

•Draw an Actors-Transactions Diagram (visualise interaction)

•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 iteratively

improve the Integration Proﬁles [5].

•Specify test cases and test sequences according to Integration Proﬁle speciﬁcation

•Add test cases, procedures, description and criteria to test environment (Gazelle [6])

•Create and integrate/implement conformity validation tools (e.g., Schematron)

•Develop and offer remote pre-Connectathon dummy test partners (optional)

•Execute test cases with at least two independent peer vendors

•Capture data transmitted during peer-to-peer communication (e.g., trace via proxy)

•Validate recorded messages/traces and log evaluated test results (impartial monitor)

4. Publish interoperability test results for each participant/vendor [5].

•Publish which vendors successfully tested an Integration Proﬁle (Results Browser)

•Get written approval of interoperable implementation (Integration Statements)

2 The IES cookbook cba

S    

Short narrative on process basics

Integration Proﬁles shall be living documents that are meant to be iteratively improved. Technical

Frameworks shall continually grow to solve more and more issues of the business domain they cover.

As technology evolves, new Integration Proﬁles may complement the existing. Obsolete proﬁles

remain available as reference for legacy system integration attempts.

The core idea of the IES methodology is agile cooperation between stakeholders: among users and

technicians, scientists and engineers, managers, etc. All shall participate as peers and contribute

jointly to the development of demand oriented solutions. Interoperability may be achieved reliably

with simple means that work ﬁne for many.

The IES approach foresees that the implementer from different vendors test their solutions among

each other, in a safe environment and in an early development stage.

All peers participating in a test case have a common goal: eventually they all want to pass the test.

A multi-day plugfest provides the environment and time to track down errors and make corrections

prior the 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 Proﬁles,

which demands understanding and amendment of the ambiguous text stating a requirement. The

comments and errors recorded at the test event are most valuable to improve Integration Proﬁles.

This feedback is practice driven and supports the advancement of the Integration Proﬁles.

Beneﬁts – implicit and explicit

Public Integration Proﬁles yield increased development efﬁciency and market access:

•proﬁles provide clear answers to questions on possible options

•proﬁle conformity allows small companies to offer sub-systems to integrate

•vendors need only one interface/solution to make their product interoperable

Contributing to Integration Proﬁle development yields individual advantages:

•contributing parties can inﬂuence the solution design

•customers can make sure that proﬁles match their needs

•knowing speciﬁcations early enables foresighted development

•trust and respect among peers from working together on solutions

Testing solution prototypes at a Connectathon Energy yields these beneﬁts:

•testing with peers helps to identify and solve interpretation problems early

•test partners help each other to pass the tests eventually (common goal)

•ambiguous speciﬁcations are jointly identiﬁed and reported for correction

•public testing success can convince customers (Results Browser – optional)

•proﬁle compliance listing for products (Integration Statements – on demand)

Integration Statements optionally added to the public Products Registry:

•a shared, neutral, still valuable, marketing and advertisement option

•publicity for companies that launch products they might not be known for

•system purchasers can ﬁnd matching components by comparing listed products

→Integration Statements list the Integration Proﬁles a product supports. They become essential if

tenders request certain proﬁles, which is a clear advantage for customers because they can precisely

specify what ﬁts into their infrastructure without going deep into technical details.

The IES Austria team 3

E S

Framework structure

Technical Frameworks are a collection of documents according to the structure shown in Figure 3.

They are developed strictly top-down, starting with a global Domain Overview (the business

environment), followed by the Business Overview, outlining an application (business scenario) or

service (business segment). This Business Overview introduces the region covered by the Technical

Framework at hand, and is the ﬁrst part to complete. For example, operating a VPP is in all possible

variants a business use-case, whereas energy system security is a service that may be relevant for

several applications.

Domain Overview

Technical Framework xy

Vol.1

Business Overview

(operation basics, targets, issues)

Business Functions

(def.: meta-actors, interop. issues, sol. architecture)

Vol.2

Integration Proﬁles

(spec.: Interop. Use Case →impl. requirements)

Transactions

(communication procedures)

Actors

(software modules)

Component Layer

Communication Layer

Information Layer

Function Layer

Business Layer

SGAM layering

Figure 3: The IES Document Structure: roughly incorporating the ﬁve SGAM Layers [7].

Depending on the individual business design, different features are required. According to SGAM

layering, we call them Business Functions. For example, telling a remote generator (DER asset) the

production schedule for the next day, is a Business Function. Also predicting the demand schedule

for the next day is a business function. However, if a Business Function does not involve cooperation

with other entities, than it does not rise interoperability issues and needs no Integration Proﬁle.

→Incorrectly implemented calculations and data handling within an entity cause operational

malfunction, but not necessarily an interoperability issue. Interoperability, as we interpret it, covers

issues that reside in the cooperation.

Technical Frameworks consist of two basic Volumes, as shown in Figure 3. Volume 1 is purely

informative and outlines the environment that the Integration Proﬁles from Volume 2 are addressing.

Concluding the informative Volume 1, Actors-Transactions Diagrams visualise the situation, i.e.,

the required cooperation of the business entities (meta-actors) involved, and thereby indicate the

Integration Proﬁles required. Volume 2 is a collection of normative Integration Proﬁles (speciﬁcations)

and supportive information.

Amendment is required when new Integration Proﬁles become added to a Technical Framework.

Integration Proﬁles specify a canonical solution for an issue that relates to a Business Function.

Commonly, a new section and Actors-Transactions Diagram is added to Volume 1.

4 The IES cookbook cba

P 

Process timing

The date of the annual Connectathon Energy determines the timing. The timeline in Figure 4 refers

to the established practice from IHE.

-7

-6

-5

-4

-3

-2

-1

Connectathon Energy

months prior Connectathon Energy

months after Connectathon Energy

Use Case proposals

name interoperability issues

Shortlist most demanded

assign planning committees

Post work plans

invite the IES community

Jointly evaluate solution options

establish technical committees

Post new Use Cases

for review by IES community

Collect feedback on newly deﬁned Use Cases

integrate feedback and write proﬁle speciﬁcations

Post new Integration Proﬁles

for review by IES community

Collect feedback on new/revised Integration Proﬁles

integrate feedback and ﬁnish proﬁle speciﬁcations

Release proﬁles for implementation

Assign ressources to planned implementations

decide what to test at upcoming event

start pre-testing, provide feedback on test plans

Systems registration

closure of systems and proﬁles registration

Attendees registration

closure of participant registration →billing

Announcement of IES proﬁles that cannot be tested

due to insufﬁcient number of system registrations

Deadline for pre-Connectathon testing

evaluate pre-testing results uploaded

Publish success

update Results Browser

Integration Statements

issue and add to repository

Integration Proﬁle Development

Connectathon Energy Participation

Figure 4: IES timing is centred on the annual Connectathon Energy

At ﬁrst, the IES community collects and rates interoperability issues. When a core team of experts

agreed to contribute towards solving one of these, the intended endeavour (work plan) shall be

disclosed to the IES community two months in advance of the upcoming Connectathon Energy. Until

the Connectathon Energy, the contributing partners survey ideas for solutions by collecting options,

standards and good practice examples. Potential solution concepts for the most interesting proﬁle

ideas can be presented at Connectathon Energy side-events to engage and involve more experts.

One month later, the Use Case shall be completely formulated and posted for an open review. At this

time the task force working on the speciﬁcations can go into speciﬁcation details and shall post the

resultant Integration Proﬁle two months later, again for open review. Another two months later, the

proﬁle shall be published and is thereby announced ready for implementation.

If a sufﬁcient number of Connectathon Energy participants register systems for testing the new

proﬁle, the testing becomes scheduled. Commonly, trial proﬁles needs to be revised based on the

feedback collected. If only minor adjustments are needed, the proﬁle becomes announced mature

and is offered for regular testing and subsequent Integration Statements.

Independent whether a proﬁle is new, revised, or stable, it can only be offered for testing at the

Connectathon Energy if the required number and type of peers registered systems for testing a

particular proﬁle. However, unannounced ad-hoc testing of trial proﬁles may be possible, if the test

plans are available on cite.

The IES Austria team 5

E S

Crosscutting collaboration

IES focuses on the plurality that arises in the context of the system-of-systems interoperability

challenge. Development teams working toward solutions need different skills and experiences to

achieve the holistic IES targets. Figure 5 uses triples to express the plurality demand.

Figure 5: Plurality of desirable expertises in IES teams and committees

To consider 









normation need – systems coordination – components architecture

domain coherence – application utility – implementation efﬁciency

testcase design – interoperability assessment – conformance validation

The IES process is intended to foster the development of interoperable solutions and services that

increase the number and variety of products on the market, such that customised and increasingly

heterogeneous systems-of-systems can be composed.

IES offers the means to test early prototypes among peers in a safe environment outside the

development lab, which clearly supports the development. Per proﬁle certiﬁcation achieves the same

target, but does not offer this add-on beneﬁt.

Peer-to-peer tests do not qualify for issuing certiﬁcates. Therefore, interoperability certiﬁcation is

not replaced by IES because the former requires accredited test facilities to perform certiﬁcation

level testing. IES Integration Statements assert that the vendor successfully demonstrated a proﬁle

compliant implementation with the tested prototype or product.

Get in contact – get involved

Joining the IES community is easy, just express the wish to stay informed. News and participation

opportunities will be distributed to the entire IES community. Wherever possible, feel free to address

an IES representative to discuss interoperability issues, the process and visions.

IES Europe shall soon unite many IES activities. Until than, and aside from national initiatives that take

over regional management tasks, the Technology Platform Smart Grids Austria lead by Dr. Angela

Berger, will serve as contact point for all enquiries.

Dr. Angela Berger, Managing Director

Technology Platform Smart Grids Austria

Homepage:

www.iesaustria.at

e-mail: ies@smartgrids.at

6 The IES cookbook cba

I Integration Proﬁle Development

The identiﬁcation of an interoperability issue is the ﬁrst step to be taken. Issues shall be thoroughly

analysed and discussed among experts to avoid misclassiﬁcation of problems that are not related to

interoperability. For example: component malfunction, system misconﬁguration, and environmental

effects.

Integration Proﬁles are the normative parts of a Technical Framework. Their assignment can be done

initially, prior writing the speciﬁcation, but not before the Use Case is clearly speciﬁed. The process of

adding and the subsequent management of Integration Proﬁles, Technical Frameworks and testing

events, is presented in Part III.

Finally, note that here an existing Technical Framework is assumed and that the intention is to add

speciﬁcations for a new Business Function identiﬁed to bear interoperability issues. That a capable

group of experts participates in the endeavour is also presumed. How to start a new Technical

Framework and how to best constitute a speciﬁcation task force to write new Integration Proﬁles

(a Technical Committee), are presented in Part III.

1 Explain the Business ◦◦◦◦◦◦◦◦◦◦◦◦◦ application experts

State the application scenario where interoperability issues exist or may occur. Use a language that

managers and technicians understand likewise.

1.1 State the interoperability demand

•Identify the Business: Explain setting characteristics and common variants.

→Add to Volume 1 Business Overview – integrate it if not already there.

•Deﬁne generic Meta-Actors: Identify actor roles and name them.

•Identify Business Functions: Explain interactions among Meta-Actors on the business level.

→Be generic: Make sure that the majority of business variants is covered by the identiﬁed

Business Functions without requiring exceptions.

→Add the result as new section at the end of Volume 1.

1.2 Identify Interoperability Use Cases

•Name the features: State what is (a) required to realise the Business Function, and (b) has

potential for interoperability issues. Consider section 3 when specifying names.

→Features that have no direct inﬂuence on exchanged data are considered to be Business

Use Cases that need not be speciﬁed here.

→Integration Proﬁles may solve isolated issues each, here called Interoperability Use Cases.

Decomposing the Business Function reveals the isolated issues later on solved by one or

more Integration Proﬁles.

•Draw a Use-Case-Diagram: Show how Meta-Actors are participating in Interoperability Use

Cases (i.e., issues).

•Draw an Actors-Transactions Diagram: Show how Meta-Actors are connected by interac-

tions (i.e., Transactions) to be speciﬁed in Volume 2.

→Add these diagrams at the end of the new section in Volume 1.

The IES Austria team 7

I I P D

2 Evaluate solution options ◦◦◦◦◦◦◦◦◦◦◦ system architects

Best practice examples often guide the way to possible solutions for speciﬁc issues. If a plethora of

Integration Proﬁles already exists, these represent best practice examples and shall be re-used where

possible. Standards are commonly dedicated to an application ﬁeld, but may be migrated into new

ﬁelds with minor amendments. Only if the options at hand are known, the best, most practical, least

expensive solution for the Integration Proﬁle can be chosen.

2.1 Deﬁne functional actors and transactions

→Actor naming: Use self-explanatory names. Consider that send/request, set/get, and

push/pull are synonyms used in different engineering disciplines. The implicit demand for

interdisciplinary coordination prohibits a rigorously common language. Experts are assumed

to know the different meanings that identical terms may have to different audiences and shall

use concise language avoiding ambiguous terms.

→SGAM interface between functional and information level.

•Decompose Meta-Actors: Deﬁne the roles of Meta-Actors in respect to the Interoperability

Use Cases identiﬁed.

→Identify the initiator and the responder of a communication, plus intermediate roles like

relaying, aggregating, and logging.

•Split business level transactions into components: Commonly there are authorisation and

authentication, action requests, reception conﬁrmation, notiﬁcations, and possibly many

more.

→Drawing a ﬂow-chart may be required to consider alternative paths and loops in case

of complex communication patterns. Later on, sequence diagrams are drawn for each

component. So here we need not go into the least bit.

2.2 State constraints and requirements

→Knowledge about these is important to structure the subsequent speciﬁcation efforts.

However, this list can change and most likely will, until new Integration Proﬁles become

mature.

→SGAM interface between information and communication level.

•Identify communication constraints: For example, necessary trigger events, valid system

state, conditional state machines, environmental conditions, and so on.

•State all possible requirements: For example communication securing, access control,

logging demand, etc.

→If needed, decompose these as speciﬁed in 2.1. For example into: setup secure channel,

close secure channel, connect to authentication service, request authorisation, open logging

repository, log commands with user identity and timestamp, and so on. Most commonly,

these add on functionalities are covered by existing Integration Proﬁles and established

standards. The decomposition here is than required to specify the alignment of actors and

transactions with those deﬁned in the imported speciﬁcations.

2.3 Choose existing practices and international standards

•Bundle existing Integration Proﬁles: Compose a bundling table to identify the Integration

Proﬁles (and CF) that are reused as integral part of the new Integration Proﬁle. How they

are actually included is speciﬁed with the transactions and actors deﬁnition. See Appendix B

on the principle. Reused pieces of bundled Integration Proﬁles and CF are referenced and

become adjusted to the needs of the here relevant Business Function.

8 The IES cookbook cba

 S I P ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦  

→Many of the identiﬁed requirements may haven been solved for some other Business

Function already. Reusing proﬁles harmonises the solutions landscape and improves

homogeneity within a system-of-systems.

•Deﬁne the international standards to be used: Decide which standards shall be used and

specify the release (version/year) the speciﬁcations refer to. Provide a table, comparable to

the bundling table, if different standards are required for the different Interoperability Use

Cases covered in the Integration Proﬁle.

→Integration Proﬁles may cover any collection of issues, from a single Interoperability Use

Case up to an entire Business Function. Applying the standardised Use Case Methodology

recommends one proﬁle per Interoperability Use Case. In practice, that may not be economic.

Being living documents, proﬁles may be split into independent parts in the course of maturing.

•Specify the best practice to be implemented: If no existing proﬁles nor international

standards can solve an issue, the solution needs to be speciﬁed within the proﬁle. Some best

practice solution becomes a de-facto industry standard for those that aim at proﬁle conform

implementation.

→Specify the best practice (i.e., the technique) as detailed as possible. Be aware

that proﬁles become open access documents ("Attribution – Share Alike 4.0 International"

cba). No copyright or intellectual property protected material may be enclosed in its

entirety, these may be referenced and cited only.

→Naturally, no proprietary protected non-free solution or part thereof qualiﬁes for achieving

interoperability in open heterogeneous environments.

3 Specify Integration Proﬁle ◦◦◦◦◦◦◦◦◦◦implementation experts

This endeavour follows the Use Case Methodology (IEC 62559)[8], and thereby uses the Smart

Grid Architecture Model (SGAM) [7, 9] and The Open Group Architecture Framework (TOGAF) [10]

to structure the process minimising the risk to overlook important requirements.

→Use Case tools are often based on TOGAF for the sake of completeness. The V-model [11] is not

so speciﬁc in the tasks and issue topics to consider, but also guides through the top-down approach.

The more complex European Interoperability Reference Architecture (EIRA) [12] is based on a similar

approach, and IHE standardised their top-down approach in ISO/TR 28380 [2].

→For simplicity of understanding, without restricting a more efﬁcient requirement and solution

aggregation and decomposition outlined in Appendix B, henceforth singular comprehensive Integra-

tion Proﬁles are assumed, where all requirements and speciﬁcations are contained in a single linear

document addressing a solitary Interoperability Use Case.

3.1 Deﬁne the Interoperability Use Case

•Name it: Specify an ID (alphanumeric code) and an explanatory name (text). This ID shall

be the same as the indicator (and name) used in the Use-Case-Diagram and the Actors-

Transactions Diagram in Volume 1.

•Describe the interoperability issue: Provide a narrative that concisely explains the issue

solved, using terms and language understood by non-experts (end users, managers and

directors, sales representatives).

•Assign actors and transaction: Deﬁne the actors and transactions that solve the issue if

implemented according to the speciﬁcations stated later on.

→Names only: Inserted here to gain an overview, and for quick access to where these are

actually speciﬁed. Provide hyperlinks, if possible.

The IES Austria team 9

I I P D

3.2 List standards and best practice

•List standards: Specify one-by-one the standards used to solve the Interoperability Use Case.

Brieﬂy validate the selection and state which parts are used for what purpose.

→Include version/year and if possible, info on how to get access to the used standard.

Brieﬂy cite the essential parts required to implement the speciﬁcations stated later on.

•List other sources: Specify the best practice examples used to solve issues. Include a brief

outline and a reference to your sources. If existing Integration Proﬁles get bundled, list them

here as well.

→If there is no accessible source, specify the practice in detail as far as required to

implement the speciﬁcations stated later on. Possibly add a dedicated annexe and reference

it.

3.3 Specify architecture building blocks

•Decompose the Actors-Transactions diagram: Provide a table listing all functional actors

and transactions deﬁned in 2.1, named in 3.1, and show how the Meta-Actors are composed of

these. For example, use an extended Actors-Transactions diagram showing the components

of Meta-Actors and Transactions, to be speciﬁed later on.

•Introduce functional actors: Provide a brief narrative explaining in easy words what features

the actor implements and what it is responsible for (requirements).

•Introduce transactions: Provide a brief narrative explaining in easy words what the

transaction does and how that aim is achieved. Name involved actors, communication

protocols used, and basic steps to be performed.

•Actor role options: State all the roles that Meta-Actors can have and relate them to the actors

and transactions that the different roles require to perform the intended tasks.

→Synonyms: List exchangeable role identiﬁcation terms where supportive for better

understanding among engineering disciplines.

•Information ﬂow, steps, sequences: Explain how a transaction transfers information

between the actors it involves. Draw a Sequence Diagram and explain each step. Deﬁne

triggers and mandatory sequencing where needed.

→The detailed speciﬁcation follows in 3.4.

•State technical constraints: Provide a brief narrative explaining in simple words the

communication channels to be used (e.g.: IP, Eth, LTE, PLC), message types and protocols

to handle data (e.g.: TCP, HTTP, XML, MMS, ASN.1), operational bounds and limitations (e.g.:

latencies, synchronisation, bit-error-rates), hardware interfaces, and whatever is required.

•Explain security measures: Provide a brief narrative explaining in simple words what

is foreseen and required for sufﬁcient prevention from malicious and accidental attacks

(e.g.: access control, authentication and authorisation, data encryption, key management,

access and message logging, required redundancy, fault detection, anomaly handling, fraud

prevention).

3.4 Specify transactions

•Scope of transaction: Explain textually the interaction between two or more actors covered

by the transaction speciﬁed. Include hints and exceptions where necessary.

10 The IES cookbook cba

→Every sequence of actions that is step-by-step executed by different actors, represents a

transaction to be speciﬁed. Commonly, each transaction covers a consecutive sequence of

actions that for the related use case and business function cannot be split up into smaller

parts reasonably. For example, the setup of a secure data connection consists of several

sub-sequences, which could be speciﬁed as individual transactions (e.g., key exchange). For

a use-case, the sub-sequence has no meaning if not embedded in the entire setup process.

However, such sub-sequences may be imported from other Frameworks; e.g., a secure energy

systems framework, which include a proﬁle for private key management servers, for which

the key exchange of two clients is a complete transaction.

•Roles interaction: List all involved actors in a table and brieﬂy describe their role dependent

interaction. If required, state into which Meat-Actors they shall be integrated.

→Same as in subsection 3.3 but here with reversed viewpoint.

•List applied standards: Specify which standards are used and which parts and options

thereof. Cite the essential features as much as required for correct implementation.

•Draw Interaction Diagram: Show the interaction that the transaction speciﬁes by a UML

sequence diagram.

→Try to consider all sequence diagram aspects deﬁned by the Object Management Group

(

www.omg.org

) to seamlessly describe the data ﬂow between each pair of actors.

•Decompose the transaction into steps: Based on the sequence diagram describe every step,

one-by-one. Include for each step: intention, expected actions and responses. Use a ﬂow-

chart to show alternative paths and loops.

•Assign triggers, conditions and requirements to steps: Specify triggers, conditions and

requirements for each step.

•Specify message semantics: For each step describe and depict the composition of the

message.

→The message content may be encoded in a structured ASCII ﬁle or some data ﬁle attached

to the message, a structured byte-block provided by the used message type, or is implicit to

the message type (e.g., hello message, ping message).

•Specify expected responses: Describe possible results of the transaction; i.e., intended

behaviour changes of actors in the course of the transaction and afterwards.

→Possibly a response matrix is needed to cover all possible message contents and actor

states that may occur.

•Specify the security demand: List technical, operational and legal requirements on the

protection of exchanged information. E.g.: encryption strength and protocol to be used for

some or all message contents.

•Specify operational constraints: List transaction features that need to be fulﬁlled for safe

system operation. E.g.: worst case transaction latencies, process robustness, recovery

performance, etc.

3.5 Specify actors

•Scope of actor: Explain textually the role of the actor. This should be rather simple because

at this level of detail an actor should have only one primary task. For example, very basic,

initiate communication and respond to communication.

→Location less (virtual) actors: If necessary, an actor can be abstract. For example, a cloud

repository or a swarm service. The integration of a distributed actor (its components) with

other actors may cause additional requirements to be stated.

The IES Austria team 11

I I P D

•Specify message policy: (a) For every message the actor can send, specify the conditions

and pre-requisitions under which the message can be created and sent to speciﬁc other

actors (roles). (b) For every message the actor may receive, specify the correct response.

No action needs to be stated where applicable as the correct response.

→The correct responses may depend on the received content, and may be state dependent.

The request-response ’matrix’ can be multi-dimensional. However, these details are

commonly speciﬁed by the used standard and need not be listed here if there is no

corresponding ambiguity in the standard.

•Specify the security demand: List technical, operational and legal requirements on the

availability and protection of actor features. E.g., access control, redundancy demand,

intrusion detection, authentication, authorisation of communication partners, etc.

•Specify operational constraints: List actor features that need to be fulﬁlled for safe

cooperation. E.g.: message buffer size, message loss probabilities, bit-error-rates, fault

protection, resilience, robustness, availability, restart performance, etc.

4 Publish new speciﬁcations ◦◦◦◦◦◦◦◦◦◦◦◦ domain experts

Once an Integration Proﬁle has been written to the likes of all participating experts, it needs to be

published and in consequence tested at an event called Connectathon Energy. Please refer to Part III

and Part II on managing Integration Proﬁles and Testing at Connectathon Energy events respectively.

Figure 4 in depicts the timing of these activities. Prior testing according prototypes need to be

implemented, which the participating vendors most likely did already in parallel to specifying, to sort

out technical speciﬁcation errors early.

→Note, IES proﬁles are public (i.e., CC BY 4.0) and it is in the best interest of all to attract more

peers for early testing. Once knowledge about a speciﬁcation is disclosed, anybody may implement

it. IES does not manage the implementation.

→Reference Implementations and Simulators: Requirements on developing so called Reference

Implementations that guarantee to fulﬁl all speciﬁcations without any restrictions on functionality,

and Simulators, being remote accessible dummy peers, required to perform pre-Connectathon testing,

may be speciﬁed in a dedicated part or document to come.

4.1 Publish for trial testing

•Hand over: The implementation experts forward the new Integration Proﬁle to the framework

and domain management.

•Assign to a Technical Framework: If not already done, domain and application experts shall

ﬁnally identify the framework the new proﬁle ﬁts into.

•Formal check: IES domain and application experts decide if a new proﬁle is sober, is correctly

assigned and conforms with IES policies and requirements.

•Amend Volume 1: The new Integration Proﬁle may require changes in Volume 1 of the

Technical Framework it is assigned to. Make sure the new proﬁle is considered in the Actors-

Transactions Diagram that links Volume 1 with the Integration Proﬁles speciﬁed in Volume 2.

•Release for trial testing: Application experts decide if the proposed speciﬁcations are sound

and can be released for trial testing.

•Trigger test preparation: The release of a proﬁle triggers the test preparation (step 5 in

Part II) and the announcement of the new proﬁle (task 10.1 in Part III).

12 The IES cookbook cba

 P   ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦  

4.2 Publish a revision – achieve maturity

•Hand over: The implementation experts forward the revised Integration Proﬁle to the

framework and domain management.

•Formal check: IES domain experts decide if the revised proﬁle has sufﬁciently considered

the feedback that made the revision necessary.

•Release for mature testing: Application experts decide if the speciﬁcations achieved

maturity and either release it for mature testing or call for another trial testing cycle.

•Trigger test adoption: The release of a revision triggers the test preparation (step 5 in Part II)

and announcement of the renewed proﬁle (task 10.1 in Part III).

The IES Austria team 13

II I P T

II Integration Proﬁle Testing

According to the V-model [11], test scenario and testing requirements shall be deﬁned in parallel to

decomposing and specifying the problem top-down. Testing at the plugfest called Connectathon

refers to early integration testing, i.e., whether interfaces were compatibly implemented.

It is important to note that testing at a Connectathon does not replace the system veriﬁcation and

validation tests with or without the customer involved, nor any certiﬁcation on standard conformance.

For latter the interoperability tests are insufﬁcient because they cover features required for a certain

use-case only, not all the features speciﬁed in a standard. The former, system veriﬁcation and

validation, depends on the actual composition of a system-of-systems in the ﬁeld. However, if the

existing components were successfully tested, there exists a high potential that a new system that

passed the same tests can be successfully integrated with less hassle.

→Test platform: In the following we refer to the test platform Gazelle from IHE Europe [6]. This

platform has been found feasible, but a different tool may be used similarly.

→Prototype testing: When a system implements a new Integration Proﬁle and is tested amongst

peers for the ﬁrst time, it is usually not a fully developed product. The implementer come to the event

with their prototypes to identify shortcomings together with implementation and performance issues.

The prime intentions are to identify misinterpretation of requirements early and to resolve them on

site with the help of peers, at least long before product development is ﬁnished. It requires faith to

go testing with peers having a prototype only, but it yields great rewards (win-win).

5 Prepare for testing ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ testing experts

Test scenarios and sequences are based on the use-case and the speciﬁcations deﬁned in an

Integrating Proﬁle. In total, they shall cover all aspects speciﬁed, but no more.

→Negative tests: Especially for security and safety requirements, it is important to design a

sufﬁcient number of negative tests. For example, tests that are passed if the system does not respond

to erroneous and malicious requests. Not all possible attacks can be tested, it is therefore important

to choose the most critical and those that cover a broad attack spectrum.

→Gazelle web-browser GUI: All test deﬁnitions and reports shall be made available to the testing

peers by Gazelle Test Management, in accordance to their role in the test.

5.1 Deﬁne test scenarios

•Analyse Business Function: First read the description of the Business Function that the

Integration Proﬁle relates to. Understand the demand on the business level.

→Test scenarios shall be practice oriented.

•Sketch typical communication: Draw a sequence diagram for the test ﬂow, being the

sequence of test cases to be executed (or copy from proﬁle if applicable).

→Highlight if a test case prepares the environment for a subsequent test case; i.e., state

whether the order matters.

•Specify evaluation criteria: Test requirements shall be clearly deﬁned and the minimal

requirements for successfully passing a test determined.

→Highlight mandatory and optional test criteria, where latter exist.

•State test environment constraints: Textually describe the conditions and requirements

that need to be fulﬁlled to execute the tests of a test scenario. For example, the required

IT infrastructure and test case speciﬁc adjustments.

14 The IES cookbook cba

 P   ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦  

→The content of messages exchanged over an end-to-end encrypted connection cannot

be evaluated on proﬁle conformance. Therefore, encryption possibly enforced by regulation

in the ﬁled, needs to be deactivated on purpose for certain test cases.

→Testing whether an encrypted connection can be set up according to proﬁle speciﬁcation

shall be speciﬁed in a dedicated test case. Where regional regulation demands encryption,

these test cases are mandatory and have strict priority: no passing of any test case that in

the ﬁeld demands an encrypted connection, if setting up a secure connection according to

speciﬁcations fails.

5.2 Specify test sequences and reports

•Analyse Integration Proﬁle: See the speciﬁcation of the Integration Proﬁle to derive test

cases and their steps. Each test case shall cover one feature, possibly in a certain system

state. Each test case shall be split up into steps that challenge the communicating systems

under test on certain aspects of the feature tested.

→Draw ﬂow charts and/or test tables to concisely deﬁne complex test sequences and

multi-dimensional response checking respectively. I.e.: The correct response may depend

on previous messages received and the systems’ current state.

•Specify test communication sequence: For every test case specify the sequence of mes-

sages to be sent, received, and processed. Include optional and required acknowledgements

as well as the correct answers/responses to requests.

→Specify the content of test messages where it is required to determine if the receiving

system correctly responds. For example, specify that in the ﬁrst step a valid content shall

be sent, in the following n steps invalid content that covers unacceptable content and not

interpretable (incorrect formatted) content.

•Prepare a template to record and store test reports: Based on the deﬁned test cases and

test steps prepare a compact template to record test results. During test execution this

template shall be provided by Gazelle’s user interface.

→Both, automated and manual recording of results is possible. Manual recording means

that the test peers individually record the results by entering them via the Gazelle Test

Management user interface (web-browser based GUI).

5.3 Create simulators (optional)

•Virtual test peer: Implement a software that mimics the behaviour of peer systems (roles)

as far as required to perform trial conformity checks. The tool shall create dummy messages

and responses similar to a real system but does not have to process messages contents.

→Dummy messages: The created and responded messages need not be practically feasible

in an operational sense. E.g., the same answer to the same type of message independent of

the messages content is sufﬁcient to verify that the message was received and logged for

content validation.

→What matters is the ability to send, receive and respond to messages, to offer a remote

sparring partner for pre-testing.

•Gazelle integration: Simulators are conﬁgured and made available for testing. If conﬁgu-

ration on the simulator side is required, e.g., port setting, than the simulator needs a web-

browser GUI. In any case, the simulator is an individually addressable (connectable) software

instance and shall be invoked independently for each peer connecting a prototype with it.

→Independent instance: Each connection to a simulator shall be isolated from other

connections to the same simulator (different instance).

The IES Austria team 15

II I P T

•Extension to simulated environment: If for all sub-systems of a test scenario simulators are

available, it might be possible to setup a simulated environment and replace one simulator

by the system under test (i.e., hardware-in-the-loop testing).

→To achieve a simulated environment, the simulators need to be more realistic models and

implemented according to IES speciﬁcations. In that case, the simulators may be considered

Reference Implementations of the according actors and roles.

5.4 Prepare validation tools

•Reception tabbing or proxy server: Either a proxy server is used to record all the messages

exchanged between the systems under test in each direction, or the receiving peer needs to

impartially log all received payload on behalves of the sending peer.

→Recording at reception side needs trust, recording at the sender side is prune to cheating.

Gazelle provides a proxy server that test-case speciﬁcally logs message-ﬂows, such that

multiple tests may be in progress simultaneously without interfering.

•Message decoding and conversion: The messages exchanged are encoded in a format

(syntax) speciﬁed in the Integration Proﬁle. To verify the context with Gazelle tools, these

need to be converted into readable text (i.e., XML format).

→Readable XML: If no automated content checking is available, the peers can manually

check message contents by opening the XML ﬁle in the browser. Therefore, all data shall be

converted into meaningful text, i.e., binary numbers into readable ASCII ﬁgures.

→Data Format Description Language (DFDL) is an Open Grid Forum proposed recommen-

dation (

https://www.ogf.org/documents/GFD.207.pdf

→Implicitly, conversion tests on correct encoding: If the conversion into ASCII text fails or

delivers unexpected results, the message was probably faulty encoded by the source.

•Rules to determine correct content: Specify the rules applicable on the contents of the XML

ﬁles, e.g., a Schematron (

https://en.wikipedia.org/wiki/Schematron

). The rules

result from the Integration Proﬁle speciﬁcations and may be correlated from step to step.

→Message sequences: To check whether a system’s response is correct, the essential part

of a transaction speciﬁed in the Integration Proﬁle (i.e., the sequence of messages) needs

to be checked on consistency. Multiple messages may therefore be converted into a single

XML document.

•Gazelle integration: Validation tools that perform the message content veriﬁcation can

be integrated in Gazelle (as software tool or bidirectionally linked). Recorded message

sequences can be sent via Gazelle to the validation tool and the veriﬁcation result is

automatically added to the test protocol.

→External tools: Veriﬁcation results from tools not integrated in Gazelle shall be copied into

the report manually.

6 Testing at Connectathon Energy ◦◦◦◦◦◦◦◦◦◦◦ implementer

This part covers the steps an implementer is required to perform to successfully attend peer-to-peer

interoperability testing at a Connectathon Energy event. >From system registration to executing test

cases until test result validation by impartial monitors.

→How to organise a Connectathon Energy event is covered in III section 10.

16 The IES cookbook cba

6 T  C E ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ 

6.1 Testing event preparation

•Registration: To register, the peers need to express which actors and roles from which

Integration Proﬁles they want to test at the event (system registration).

→Reference implementation: Vendors with an already approved product may offer it to new

peers attending with newly implemented components. However, reference implementations

shall be open source alike all IES tools.

•Test cases and peers announcement: Shortly after the registration deadline, the test

management team announces the testing schedule, containing scheduled times and dates,

the test cases and the participating peers, based on the attendees wishes expressed with

registration.

→Only tests with sufﬁcient number of registered peers are made available for testing.

→Preferences on peers for testing are in general not allowed or considered.

•Component testing: If a simulator for the required communication partners is available, the

implementer are advised to use them to test whether the messages they send conform with

proﬁle speciﬁcations.

→Pre-event tests with simulators offer format (encoding) veriﬁcation only. These are

recommended to sort out basic errors prior connecting the prototypes with those of peers.

At the event, problems that result from the combination of attending peers are in the testing

focus, not malfunctions detectable without peers easily.

→Attending the event with a components that are known to be not ready for testing, may

prevent peers from having success at the event.

6.2 Execute peer-to-peer testing

•Follow testing schedule: Test scenarios and cases shall be performed with the foreseen

peers according to the testing schedule announced by the test management.

→The schedule assures that if all peers pass all tests, all peers are successful with the

tests foreseen in the schedule. A sufﬁcient number of repetitions with different peers is in all

cases scheduled.

•Execute test sequences: The sequence of test cases and steps per test case are provided

by Gazelle. In general they may be executed in any order.

→Note that sometimes the system state needed for test cases and steps may be bound to

the previous tests. Either follow the recommended sequence or make sure that the system

is ready to correctly execute tests.

•Record test results: In general, test results are to be manually conﬁrmed by the peers

participating in test cases. Recorded message ﬂows are commonly automatically assigned

and provided for veriﬁcation tools. If otherwise instructed by the test case description, copy

recorded messages into Gazelle prior invoking a veriﬁcation tool.

→External veriﬁcation: If foreseen by the test case, use an external veriﬁcation tool. How to

perform the validation should be explained in the information on the test case within Gazelle.

•Repeat test cases: If something went wrong, i.e., a test or message veriﬁcation failed, the

peers can repeat test cases (steps) as often as needed to sort out the problem.

→System state: When repeating test cases and steps be aware that some tests may require

speciﬁc initial system states to be successfully executable.

→In some cases, if possible at all, it may be wise to proceed in the sequence and ﬁnd out

what caused the problem afterwards. Seek help from your testing preers if you are not sure

what went wrong. Your peers may face the same problem, so join ingenuity to track down

the problem.

The IES Austria team 17

II I P T

→Arrange new testing time with your peers if testing shall be postponed to a later time

because you need to make changes that cannot be performed on-the-ﬂy.

•Ad-hoc testing sessions: Commonly, the planned testing schedule leaves gaps for on

demand testing. This is arranged peer-to-peer on the ﬂoor, and provides the option to ﬁnd

alternative peers to pass the planned tests.

→Ad-hoc testing draft implementations in a state most likely not good enough to pass test

cases is an option to check the current implementation among friends.

6.3 Get impartial success validation

To assure trustworthy test results, every test case needs to be validated by a unbiased

monitor. The monitor is an expert that is not associated to any one of the participating peers.

Monitors conﬁrm successful testing, may give hints on possible problem sources, but cannot

help in solving an issue.

•Get a monitor: If you are sure you passed a test case, than mark the test case in Gazelle

being ready for validation. This automatically informs an eligible monitor. The monitor will

than come to your place.

→At the Connectathon Energy the monitors are located on a central table and can be easily

identiﬁed by wearing a distinct piece of clothing. If no monitor shows up in due time, ask why.

•Support the monitor: Show the monitor the tests you performed. Monitors have their own

web-based GUI and have access to all information recorded by the Gazelle testbed. If in doubt,

the monitor may request the repetition of a test case. Do so and explain for example why the

results differ from the results expected in the test deﬁnition.

→If you convince the monitor that the response is correct for the situation you test and does

not challenge interoperability, than the monitor my conﬁrm success (e.g., the test deﬁnition

may be based on a different scenario).

•Success veriﬁcation: If the monitor is convinced that all test steps of a test case and all test

cases of a test scenario were successfully passed (according to speciﬁcation), the monitor

marks the test cases and scenario in Gazelle as veriﬁed.

→Feedback: If peers or the monitor identify problems residing in the proﬁle or test

speciﬁcations, these shall be noted in the feedback option provided by Gazelle. Thereby, the

feedback is destined directly to people responsible for the speciﬁcations.

7 Publish success ◦◦◦◦◦◦◦◦◦◦◦◦◦◦ testing management

The team responsible for all testing, e.g., the Monitors, check the recorded results in Gazelle and

awards the participants that successfully tested proﬁles.

7.1 Show success in Results Browser

•Check test success: If all tests related to an Integration Proﬁle were passed successfully

and with a sufﬁcient number of independent peers, the attending peer is awarded a star for

that Integration Proﬁle.

→Exceptions: The number of necessary repetitions may be adjusted in case the foreseen

number of repetitions was not possible due to environmental conditions, e.g., a foreseen test

partner cancelled attendance and there were no alternatives available on the ﬂoor.

•Mark test accomplishments: In the vendor vs. proﬁles matrix add a star in each ﬁeld where

a vendor successfully tested a proﬁle at the event.

18 The IES cookbook cba

 P  ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦  

→Testing prototypes does not allow to mention products here. Success at the Connec-

tathon Energy states that the vendor has the knowledge to correctly implement the Integration

Proﬁle he was awarded for.

→Multiple years of successful testing adds to vendor reputation.

7.2 Issue Integration Statements

•List supported proﬁles: A vendor can issue an Integration Statement for a product (name

and version/year) that implements a successfully tested prototype.

→To get an Integration Statement issued by IES ofﬁcials, the vendor needs to come with the

ﬁnished product to a Connectathon Energy and pass all tests again. This seems not foreseen

in IHE and can be considered surplus if the vendor needs certiﬁcations that attest basically

the same.

•Dubious Integration Statements: If IES fellows detect suspicious Integration Statements,

they are encouraged to forward the information to the IES ofﬁce.

7.3 Get listed in products repository

•Public repository: Integration Statements can be uploaded in a public accessible repository

for broad visibility.

→Feedback: Not only can system purchasers ﬁnd compatible products from this list, they

also may leave comments on the products if the vendor wishes to.

•Maintain accuracy of repository: Once a year, the vendors of listed product will be

encouraged to remove products no more on sale. Vendors that vanished or do not respond,

will be removed by the IES ofﬁce.

→There are no mature IES proﬁles yet, so there is no need for a repository yet. Its power

comes with the number of products contained.

The IES Austria team 19

III I P M

III Integration Proﬁle Management

What is developed and tested decides the IES community. Who is this community? All participating in

both, the development of proﬁles and bringing products/prototypes for testing to the Connectathon

Energy. Why? Because only if there is a sufﬁciently broad demand for some speciﬁcation there

will be enough peers that volunteer to write speciﬁcations and implement prototypes to perform

interoperability tests among each other.

How Integration Proﬁles are developed and how their implementation is tested is outlined in Part I

and II, respectively. What remains, is managing how the work performed by different teams of

volunteers is embedded in a maximally self-maintained IES environment.

→Note that the speciﬁed management tasks are based on visions, guesses, and practice copied

from IHE. The IES management tasks shall be adaptive, i.e., community driven. Only the aim and the

fundamental principles shall persist for sustainability reasons.

→Management platform: Many of the required management features are provided by the test

platform Gazelle from IHE Europe [6]. This platform has been found feasible, a different tool may

be used similarly.

8 Proﬁle proposal & revision ◦◦◦◦◦◦◦◦◦◦◦◦ IES community

If the number of independent peers wishing to test a new/revised proﬁle is insufﬁcient, the proﬁle

cannot be successfully tested and is withdrawn in task 10.1. Commonly, four independent peers need

to bring prototypes or (sub-)systems supporting a new/revised proﬁle to a Connectathon Energy for

successful testing.

→The three independent peers constraint is in place to implicitly prevent any proprietary solutions

that would compromise the aim of IES for open interoperable systems-of-systems in the energy

domain, not hindering any vendor from proposing an idea.

8.1 Establish a Technical Committee

•Find development partners: If the urge to solve an interoperability issue is sufﬁciently high

it should be easy to ﬁnd partners in the IES community with the same aim. Get in contact with

peers and convince your company that it is economic to actively participate in joint solution

speciﬁcation.

→Beneﬁts: Early notion, joint forces, cooperation, learn from each other, support the

solution you prefer. Refer to the Beneﬁts section in the Executive Summary for details.

→Currently, the IES community is small and ﬁnding peers is not as easy as it should be. Use

your contacts and networks, address recent project partners and friendly competitors at fairs,

events and conferences to increase the number of addressable peers. The IES management

team advertises IES and organises complimentary events (as far as funding can be achieved)

to support the IES community growth.

•Organise cooperation: Agile cooperation will result from the common aim if the committee

covers all expertises required to specify a solution and is composed of peers willing to achieve

a sustainable solution. To assure that, exclusion of distracting and non-supportive partners

needs to be agreed and a priory clariﬁed that an exclusion is no personal issue. Commonly,

insufﬁcient backing in the company causes peers to lack the required power and time to

truly contribute. While working toward solutions, technical committees shall meet frequently.

Meetings shall start with a brief individual progress report followed by open tasks to be

addressed next (purely coordination). A shared document repository is encouraged to ease

the information exchange.

→IES timeline: The given dates, the development progress, and the support from team

members determines the required meeting frequency. (cf. Executive Summary)

20 The IES cookbook cba

8 P  &  ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦ IES 

→Telemeetings save time and costs, face-to-face meetings can be organised efﬁciently in

the course of the Connectathon Energy. However, the kick-off meeting of newly established

committees shall be face-to-face (if possible) to establish a social team spirit.

8.2 Evaluate a proposal

•Publish in IES community: As shown in the timeline presented in Figure 4, disclosing new

proﬁles is a three steps task. First, the deﬁned Interoperability Use Case shall be posted for

review and comments from the IES community. Second, the speciﬁcations shall be posted

for review and comments because only after the Use Case is clear the speciﬁcations can

be holistically evaluated. In the third step, the new Integration Proﬁle is published as open

access document (cba).

→Only after the collected feedback has been considered and integrated are the Use Case

deﬁnition and the Integration Proﬁle speciﬁcations made publicly visible. Publishing triggers

the preparation of test plans and the implementation of new speciﬁcations by vendors from

outside the IES community.

→Revision: Integration Proﬁles shall be withdrawn from testing if a required correction is

considered fundamental. Corrections in the speciﬁcations after publication always require to

announce a revision and performing the complete proﬁle development process.

→Minor corrections: Grammar and writing issues may be corrected on-the-ﬂy by authorised

peers (e.g., the original authors) in the online provided documents according to the agreed

versioning procedure, i.e., incrementing the sub-version index and stating the change and the

author in the document history.

→Trial proﬁles: If a new Integration Proﬁle is ﬁrst released, it is released for trial

implementation only. In that case, the documents shall be conclusive, but need not have

the rigour of mature proﬁles. Also the timing is more ﬂexible if the peers from the technical

committee are sufﬁcient to do successful testing among them. Note, Integration Statements

may not be issued for Integration Proﬁles in trial state. Trial testing is performed aiming at

testing the proﬁle, not the preliminary implementation.

•Collect feedback: To eliminate minor faults and short-sighted speciﬁcations, both, new Use

Case descriptions and Integration Proﬁle speciﬁcations shall be posted for an open review

process. Here, open means non blinded. Only registered users from the IES community shall

see drafts and are allowed to comment. All comments and recommendations shall be signed;

no anonymous access granted.

→Web-tool: To efﬁciently collect feedback from the IES community a web-based sharing

of drafts is encouraged. If the Gazelle platform [6] can provide this, it shall be used in

general because it already includes user identiﬁcation and eases coordination with test case

development. If some other tool is used for test management, the registration and participant

mamagement features need to be provided similarly.

•Evaluate: Whether author or reviewer, focus on interoperability, i.e., the cooperation issues

among systems. Are all aspects of interoperability covered? Are legal, semantic, syntactic,

technical, and operational aspects considered? Also check for surplus conﬁnement; the

freedom of developers to choose how to implement features shall not be artiﬁcially

constrained.1

→Implementation details of individual actors shall not be restricted where not directly

relevant for the realisation of the interaction speciﬁed for the Use Case.

•Decision: After the review and request for comments phase, the authors of speciﬁcations

are empowered to decide by a qualiﬁed majority vote whether speciﬁcations are ready to be

published for trial or mature testing.

1The exemplary proﬁles shall show the structuring only, they are not complete in the here claimed sense.

The IES Austria team 21

III I P M

→It is the authors work and their blame if they decide wrong. They own the success versus

failure balance and can take reasonable risks. Outsiders miss the intrinsic drive and may be

improvident or overcautious depending on their personal risks only.

→Decisions shall be strictly restricted to facts and the achieved feedback. Personal

animosities and company policies shall not interfere.

→No feedback is also a kind of feedback, as are inappropriate feedback and phantom

contributions intended to delay and obscure actions.

→A team of experienced IES afﬁliates (e.g., domain experts) shall be empowered to sort out

dubious contributions, to assess reasons for insufﬁcient feedback, and to draw ﬁnal decisions

when requested by the authors or the community.

9 Proﬁle assignment & release ◦◦◦◦◦◦◦◦◦◦◦ domain experts

As already mentioned, a committee composed of experienced IES participants shall supervise the

activities and support the other teams. It is therefore slightly above the two others, as shown in the

central part of Figure 5.

As outlined in Figure , i.e., Figure 4, the ideas for new proﬁles shall be shortlisted to focus on the most

interesting and most needed. The experts proposing a new proﬁle are evidently convinced that their

idea most relevant. To make a fair selection, a neutral body shall hear the arguments and capture the

market needs to rank proposals.

Based on the presented idea, the domain experts shall propose the reuse of existing proﬁles and

decide which framework the new proﬁle ﬁts into. Once the framework is selected, the Planning

Committee takes over. In case a new Technical Framework shall be started, the domain experts

shall moderate the establishment of a new Planning Committee responsible for the new framework.

→Every Integration Proﬁle needs to be assigned to exactly one Technical Framework. Existing

frameworks may be split into independent parts when convenient and technically reasonable.

→Proﬁles shall be reused via bundling across frameworks wherever possible to minimise the

speciﬁcation demand and the solution plurality. Siblings of proﬁles shall be prevented.

9.1 Establish a Planning Committee

•Find a diversiﬁed stakeholder team: The initiators of a new proﬁle idea shall in general be

considered as members of the planning committee. However, coverage of relevant market

sectors, envisaged application and system users and architects, and evidently the potential

vendors, shall be assured.

→Roles: A single committee member may cover several roles. This person than shall wear

several hats and needs to switch roles in discussions, which may require exceptional skills

when discussion is needed among roles represented by the same person.

→In theory, a single person could constitute an entire committee, given this person provides

the necessary skills and experiences, and is commonly accepted in this distinguished godlike

position.

•Organise cooperation: Planning committees shall meet on a regular basis in alignment with

the timeline presented in Figure 4. The proposers of new proﬁles, as well as any other

community member raising a hand, shall be given sufﬁcient time and attention to present

their arguments. Decision shall be documented and openly available to the IES community.

→Moderation: The Planning Committee has mostly monitoring and moderation tasks. It is

responsible for the consistency of the framework as a whole, and in particular on Volume 1.

22 The IES cookbook cba

 C E  ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦  

→Volume 1: Committee members shall contribute an even share to Volume 1 to assure

that all stakeholders are covered. Technical aspects shall be coordinated with the Technical

Committees responsible for the proﬁles. In that respect, semantic consistency is a Planning

Committee responsibility.

9.2 Support from Domain Coordination Committee

•Train and monitor committees: Senior members with a lot of experience concerning issues

that may arise along the path (i.e., in the course of the entire IES process) are encouraged to

share their knowledge and serve as guiding body represented in the Domain Coordination

Committee. The main task is to advise less experienced members and in particular the

planning and technical committees.

→Principles and norms: The Domain Coordination Committee is also the reference source

to assure that the IES principles and norms are respected.

•Identify proﬁle ambiguity and re-usability: Every community member is an expert on his

own. The IES community is in general invited to point out any issues they detect in deﬁnitions

and speciﬁcations. This feedback is the fuel that propels draft ideas into solid broadly

accepted and respected speciﬁcations.

→Cross domain view: In addition, commonly long before the entire IES community, the

Domain Coordination Committee shall comment on ambiguities and possible re-usability of

proﬁles when they are addressed to rank the ideas in subsection 8.2.

•Recommend framework re-organisation: Changing the structure of an existing framework

may not be welcome by those that manage it. If the Domain Coordination Committee gets

aware that strains toward reorganising condense, they shall support the Planning Committee

throughout the change process.

→Change coaching: Changes are a painful but often inevitable necessity. Lead from outside

less personal issues need to be faced. However, make sure that all members of affected

committees are involved and their arguments taken serious from planning till implementation

and evaluation. Only together the pain is spread and less of a burden.

10 Connectathon Energy organisation ◦◦◦◦◦◦◦◦◦ event experts

Whether big or small, a plugfest alike the Connectathon Energy requires preparation, from attendee

management and support to infrastructure provisioning and general location logistics. The

organisation quality has a considerable impact on the success and reputation of the event.

→All timing is based on the IES timeline (Figure 4) and may be adjusted individually (i.e., per proﬁle)

if there is need and common acceptance from the involved peers, the test experts, and the event

organisation team. Transparency is granted by public announcement in Gazelle.

→Publicity: The Connectathon Energy events provide a good platform to publicly present the

IES methodology toward better interoperability, the advantage of interoperable systems in general,

and the proﬁles available now and in the near future. These aspects are primarily addressed by

the side-events mentioned in subsection 10.3. In the focus of the IES cookbook on Integration

Proﬁle development, these activities represent dissemination and publication efforts, which today

are required just as much as technical rigour.

10.1 Attendee management

•Advertise proﬁles for testing: According to the IES timeline, new proﬁles become advertised

seven months prior the upcoming event. These shall be actively highlighted to raise

attraction.

The IES Austria team 23

III I P M

→All proﬁles available in Gazelle (new, mature, and legacy) are implicitly advertised without

further notice.

•Register systems and proﬁles to be tested: Until four months prior the event, vendors can

tested with no constraints yet.

→Specifying the proﬁles intended to be tested, is the core part of the system registration

process and constitutes its necessity.

•Attendance registration and billing: One month after system registration closes, also the

attendee registration closes. In general, each system registration includes two places (table

space and chairs on the Connectathon Energy ﬂoor) to execute the registered tests in the

course of the event. More places can be registered on demand.

→Once systems and places are known, an invoice shall be issued and settled within

common business terms prior the event. Only paid attendees get ﬂoor access clearance.

On-site payment option may be provided only if the local infrastructure and organiser can

handle it securely.

→There is no on-site registration for the Connectathon Energy test-ﬂoor. However, on-site

registration for side-events (10.3) may be offered on behalf of the organiser.

•Announce proﬁles not to be tested: Based on system registrations, i.e., the proﬁles intended

for being tested, the event management identiﬁes the proﬁles that cannot be tested due to

an insufﬁcient number of registered peers, and informs the registered attendees until two

months in advance of the event.

→There is no need to announce which proﬁles will be tested, only those that were intended

but cannot be executed need to be made public.

→Informing affected attendees in advance offers them the opportunity to invite peers to

add these proﬁles to their system registration (prior the deadline though).

•Evaluate pre-Connectathon testing results: Some test cases require successful testing of

some features prior attending the event. These tests can be performed remote using Gazelle

tools or external tools. The recorded or uploaded results need to be stored and veriﬁed in

Gazelle until one month prior the event.

10.2 Event preparation and execution

•Decide and announce upcoming Connectathon Energy venue: Location and date of the next

event shall be discussed and decided by the IES grandees (Domain Coordination Committee)

and interested event organisers. Public announcement is achieved primarily via the IES

homepage. Side events, i.e., the supporting programme, shall be announced by the event

organiser on his or her behalf (see subsection 10.3).

→The decision is best achieved in the course of the previous Connectathon Energy, i.e., one

year in advance, such that it can be announced on site to all attendees and from there on in

all media, i.e., the IES homepage.

•Event infrastructure requirements: Choose the venue such that it matches with the

expected number of participants, provides all essential features, and supports somehow

all other requirements. Required features that are not provided by the venue need to be

contributed by the event organisers.

→Essential features are:

•Weatherproof room to operate sensible prototypes

•Stable electricity with sufﬁcient capacity

•Trustworthy access restriction measures

•Adequate restrooms (toilets)

•Possibility to reliably receive and securely store equipment sent upfront

24 The IES cookbook cba

 C E  ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦  

→Other features are: Room heating and/or cooling, sufﬁciently powerful and stable Internet

access, catering facilities, presentation rooms for side events, wardrobe service, meeting

spots, quiet areas, and so on.

•Setup test ﬂoor: Setup the isolated test LAN connected to the Gazelle instance used to run

all tests. Provide ample table space, minimum ∼0.5 m²per booked ﬂoor place.

→Respect privacy of attendees: Assure that attendees are grouped such that each vendor

is an island where no competitor can peek into without being noticed.

→Assure security of the test LAN: Assign a sufﬁcient number of qualiﬁed network

administrators to anticipate and ﬁx issues prior serious harm is done.

•Social event: Aside from the political gala dinner organised by the IES grandees for their

network of inﬂuencers and decision makers (10.3), the event organiser shall offer the test-

ﬂoor attendees a private event toward the end of the plugfest to release some pressure and

intensify fresh contacts. This may be combined with a short city-tour if offered by local

authorities.

→Socialising: The engineers participating in the test-ﬂoor shall be rewarded for the efforts

contributed by attending the event in its whole duration, i.e., being available for peers to

execute test cases, actively supporting more interoperability.

→What is remembered: It is perfectly common that some tests fail when prototypes or trial

proﬁles are addressed. A nice and private event among the attendees that worked with each

other for several days, is in any case a positive image they bring back home and remember

when anticipating the next Connectathon Energy attendance.

10.3 Side events, catering and IES marketing

•Organise side events: Compose a small diversiﬁed program (single track) composed of

presentations, panels and workshops on Integration Proﬁle related topics for event visitors

and decision makers that are not directly involved in the testing activities at the ﬂoor. Consider

that the primary addressed auditorium are the executives of vendors and customers that IES

wants to contribute to developing new IES proﬁles and to participate in peer-to-peer systems

testing (→foster paid ﬂoor attendance).

→What is IES and how may IES evolve: Present the basic idea and procedures, possibly

followed by a panel discussion on improvement options and visions.

→New proﬁles: Present the proﬁles that were developed recently, and pending ideas for new

proﬁles and amendments of existing proﬁles (e.g., as workshops).

→VIP tours: Organise timed tours to the testing-ﬂoor for event visitors to show and explain

the action on the ﬂoor. Keep some distance to regular attendees so the tours do not disturb

them too much in their testing and bug solving endeavours.

→Conference/Symposium (optional): Choose a hot topic and invite renown experts to

talk about the future of the energy system, recent developments, fears and business

opportunities. The conference/symposium shall be organised entirely by the event host at

his or her discretion.

•Catering and Gala dinner: Organise adequate catering for the attendees of the ﬂoor and the

visitors at the side events. While all ﬂoor attendees may mingle with event visitors, latter have

no access to the ﬂoor centric catering.

→Catering at the ﬂoor: Consider that ﬂoor attendees have work to do on individual

schedules. Water, coffee, tee and snacks shall be provided at any time, and lunch over an

extended time span, e.g., two hours plus. If a stationary venue catering facility (canteen) is

available, lunch vouchers may be an option. No food on the ﬂoor, sensible systems shall

no be jeopardised. Catering areas (as well as smoking areas) shall provide a utile space for

private discussions among peers, e.g., tables, chairs, etc.

The IES Austria team 25

III I P M

→Visitor catering: Water, coffee and tee shall be offered throughout the day. Snacks and

lunch shall be served as scheduled in the program. Light dishes cause less fatigue.

→Gala dinner: A special event for the invited experts and executives from vendors and

customers participating in IES and all the ofﬁcers and functionaries visiting the event. If

possible get the dinner funded by a local vendor or authority. This event is most beneﬁcial

for the event host because he or she meets the important people. For the ofﬁcers and

functionaries it is a welcome favour that offers some networking opportunities.

•Public relations and IES marketing: The Connectathon Energy is the ﬁgurehead of IES. It is

the most outstanding and visible signpost of IES besides the IES web page. The achievements

at the Connectathon Energy fortify the IES process with evidence. Therefore, all marketing is

concentrated on and around the Connectathon Energy.

→The Connectathon Energy event itself is the most valuable IES advertising column and

deserves an adequate and sustainable quality experience optimisation!

In advance of the event:

•Advertise the side events in an adequate form on trustworthy channels.

•Use social media in a professional fashion to raise awareness (link to IES homepage).

•Publish the program (agenda) as soon as possible via the IES homepage.

During the event:

•Assure that the signage at the venue sites fulﬁls all guidance needs.

•Keep the on-line program up-to-date & advertise special highlights (reminders).

•Say thank you to all participants, visitors, and the staff enabling the event.

After the event:

•Offer presentations and other presented digital content for download (asap).

•Analyse received feedback on recommended improvements →discuss & document.

•Conclude the event with a decent report published via the IES homepage.

IES supports open source because it is assumed to be the fastest way toward a wide

spread knowledge distribution. No artiﬁcial barriers. However, there is high potential for

misunderstanding because the approach is very different compared to common practice (i.e.,

certiﬁcation). It takes time to change established habits.

→Public relations and dissemination are the tools to foster comprehensive understanding

of IES: the intention, the tools and processes, and the achievable results.

26 The IES cookbook cba

IV Appendix

A Document templates

Complimentary document templates are available for Volume 1, Volume 2, Integration Proﬁles, and

Common Features. If support is required, get in contact with IES partners (ies@smartgrids.at). 2

→https://www.smartgrids.at/integrating-the-energy-system-ies/download.html

B Flexible decomposition of speciﬁcations

Each Integration Proﬁle solves primarily an interoperability issue of a targeted Business Function, but

may be reused via bundling it into an Integration Proﬁle that contributes to solving other Business

Functions. Graphically, this is shown in Figure 6, where also the option to further reduce speciﬁcation

redundancy via Common Features is considered.

Business

Function 1 ... Business

Function n

Integration

Proﬁle 1

Integration

Proﬁle 2

Integration

Proﬁle i

Integration

Proﬁle j

Common

Feature a

Common

Feature b

Common

Feature z

Standard A

(Technology) ... Standard Z

(Technology)

derive from

bundle

into

extract from

Figure 6: Proﬁle Bundling and Common Features: avoid redundant speciﬁcation.

→Common Features: 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 Proﬁles, as shown in Figure 6. Their actual implementation

shall be constraint by the calling Integration Proﬁle, such that interoperability is achieved precisely as

required for the Business Function the Integration Proﬁle relates to.

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

ﬂexibility available. CF are economic if a CF is used by many Integration Proﬁles. In that case, CF

save redundant speciﬁcation of similar usages of the same feature. Modular proﬁles and CF may

also be composed into complex holistic proﬁles using the approach presented in [13].

CF can be used to partially derive conformance tests. The more restrictive interoperability tests, and

the conformance to the Use Case speciﬁc, Business Function related, restrictions, obligations, and

constraints, cannot be derived from a CF because these are speciﬁed in the Integration Proﬁle only.

2To be replaced by IES Europe mail account asap.

The IES Austria team 27

IV A

C Proﬁle complexity recommendations

The complexity of Integration Proﬁles shall be limited to feasible speciﬁcation and implementation

effort. The IHE has formulated according recommendations and procedures that shall be applied

likewise (

https://wiki.ihe.net/index.php/Process

→IHE International Principles of Governance [14]

→IHE Proﬁle Design Principles and Conventions [15]

D Certiﬁcation approaches and examples

The IES scope is to establish a meaningful canonical, standardised process to create proﬁles 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 concept exists, the IHE

(Integrating the Healthcare Enterprise) approach.

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 is to establish these for the Smart Grid domain and to promote 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, IES conducted the ﬁrst Connectathon Energy together

with IHE Europe in Den Hague, The Netherlands, successfully using the IHE Gazelle test platform.

This ﬁrst proof of concept was considered successful form the healthcare testing experts. Time will

show how many interfaces and use cases will emerge with IES compliant proﬁles to be tested in the

coming years.

→IES does not certify interoperability: Testing at Connectathon Energy is among peers and on

prototype level, i.e., in an early development stage. This does not qualify for certiﬁcation level testing.

Interoperability certiﬁcation is commonly offered speciﬁcally for a certain standard or technology.

An example comparable in issues plurality are Bluetooth proﬁles (

https://en.wikipedia.org/

wiki/List_of_Bluetooth_profiles

). The diverging plurality of possible requirements for

different technical frameworks makes a global interoperability certiﬁcate unachievable.

Exemplary approaches and opportunities for certiﬁcation and comparable assessments:

•IEC 61850 University:

http://www.61850university.com/

•OpenADR:

https://www.openadr.org/certification-process

•OPC foundation:

https://opcfoundation.org/certification

•TÜV Süd Group:

https://www.tuv-sud.com/industries/power-energy/

smart-grid

•TÜV Rheinland:

https://www.tuv.com/de/deutschland/gk/produktpruefung/

smart_home_smart_grid_de/smart-home-smart-grid.html

•Smart Grid Interoperability Laboratory (SGIL):

https://ec.europa.eu/jrc/en/

research-facility/smart-grid-interoperability-laboratory

•EU Interoperability Centre:

https://ec.europa.eu/jrc/en/research-facility/

european-interoperability-centre-electric-vehicles-and-smart-grids

28 The IES cookbook cba

E D

E Deﬁnitions

•Actor: Is a functional software component of a system that executes transactions with other actors

as deﬁned in an Integration Proﬁle.

•Actors-Transactions Diagram: Is the visualization of the relationship between (meta-)actors where

the connecting transactions specify the interaction.

•Business Case: Is an economic viable realisation of a product/service idea/technique.

•Business Function: Is a comprehensible functional piece required to realise a Business Case.

•Business Overview: Is the narrative explanation of a Business Case including realisation variants

and environmental aspects.

•Committee: Is a functional role within a community that is commonly taken by group of experts who

perform the assigned tasks jointly.

•Common Feature: Is the speciﬁcation of a single feature taken from a standard or good practice to

be used (bundled) in Integration Proﬁles.

•Conformance Testing: Is a stand-alone process to ensure that the implementation conforms to

speciﬁed standards and proﬁles, i.e., the implementation’s outputs and responses are checked

against patterns and rules.

•Connectathon Energy: Is a plugfest where components of different vendors are not hacked but

connected to evaluate the interoperability among them.

•Domain Overview: Is the speciﬁcation and explanation of the environment and constraints that

identify and limit a business/market sector (domain).

•Feedback: Is a subjective information returned voluntarily. Recommendations, observations,

comments, rating, grades, likes, hints, criticism, and praise, are typical examples.

•Integration Proﬁle: Is the speciﬁcation required to realise a part of a Business Function (or

combination thereof related to a single task) in an interoperable fashion (normalised).

•Integration Statement: Is the summary of the Integration Proﬁle testing that the prototype modules

of a speciﬁc pruduct (family/version) successfully passed.

•Interoperability [ITU-T Y.101, ITU-T M.60]: Is the ability of two or more systems (applications,

products, services) to exchange information and mutually make use of it.

•Interoperability testing [ITU-T Z.450]: Is assessing the ability of two or more systems to exchange

information and to make mutual use of the information exchanged.

•Interoperability Use Case: Is a part of a Business Function that relies on data exchange between

different actors (i.e., where interoperability is at risk).

•Meta-Actor: Is the composition of actors that joins all the functional components (actors) needed

to integrate locally the functionalities (transactions) required for a Business Function.

•Monitor (at Connectathon event): Is a neutral person (testing expert) that veriﬁes if a test case has

been successfully passed by validating the recorded success.

•Layer: Is a functional grouping in the style of the generic ITU-T X.200 model. Connecting layers via

interfaces enables adaptable system architectures.

•Peer-to-peer: Identiﬁes non-hierarchical cooperation among equally empowered entities.

•Technical Framework: Is the hierarchy of documents that introduce, deﬁne and specify how to

implement functionalities and features such that interoperability is achieved.

•Prototype testing: Is the testing of implementations in a state where adjustments and amendments

can be directly integrated right away.

•Sequence Diagram: Is a UML conform interaction visualisation that shows different processes or

objects (actors) as parallel vertical lines, and the messages exchanged in order of occurrence as

horizontal arrows (time progresses top to bottom).

The IES Austria team 29

IV A

•Simulator: Is a virtual test peer that provide the essential features to perform conformance tests.

Typically used for pre-Connectathon tests but insufﬁcient to assess interoperability.

•System-of-systems: Is a system that results from the cooperation of different systems without

implicit central control. Typically a complex of individual control systems and diverse objectives.

•Transaction: Is the speciﬁcation of a set of messages (1..n) exchanged among a group of actors

that realise the Use Case speciﬁc information exchange (in one or both directions, in a strict or loose

order) as speciﬁed by an Integration Proﬁle.

•Use Case: Is a list of actions or event steps required to achieve a distinct goal, typically deﬁning the

interactions between a role (an actor in UML terminology) and a system. The actor can be a human

or some other external system.

•Use Case Methodology: Is the approach to identifying and exchangeable documenting requirements

based on TOGAF as speciﬁed in IEC 62559.

•Use-Case-Diagram: Is the UML conform visualization of a Use Case showing the relationship

between users and the different use cases in which they are involved.

•Validate: Is to ofﬁcially prove/state that something is true or correct.

•Verify: Is to show or agree that something is true or correct.

•Volume: Is used to group different components of a Technical Framework such that different experts

can focus on different Volumes.

•The meaning of “shall” and alike: Throughout the IES documents we use the following terms and

synonyms to express if a constraint or requirement is essential, mandatory, optional, or possible:

◦must be, has to be →essential: unavoidable

◦needs to be, shall be →mandatory: required

◦should be, can be, may be →optional: good to have

◦could be, might be →possible: likely not useful

If you consider shall be as the key token to express what is mandatory, then the others can be

substituted without loss of accuracy. However, the priority or importance of the constraints and

recommendations remains unaffected, even though prioritization might be generally questioned

because all the so prioritized features are mandatory, and the term mandatory supports no

comparative degrees.

→Please refer to RFC 2119 (

http://www.faqs.org/rfcs/rfc2119.html

) and IEEE stan-

dard document structure subsection 6.4.7 (

https://standards.ieee.org/about/policies/

opman/sect6.html

) for more precise recommendations to follow.

30 The IES cookbook cba

F A

F Abbreviations

ADR Automated Demand Response

ASCII American Standard Code for Information Interchange

ASN Abstract Syntax Notation

CF Common Feature

DER Distributed Energy Resource

DFDL Data Format Description Language

DLNA Digital Living Network Alliance

EIRA European Interoperability Reference Architecture

Eth Ethernet

GUI Graphical User Interface

HTTP Hypertext Transfer Protocol

ID Identiﬁer

IEC International Electrotechnical Commission

IES Integrating the Energy Systems

IHE Integrating the Healthcare Enterprise

IP Internet Protocol

ISO International Standardization Organization

IT Information Technology

LAN Local Area Network

LTE Long Term Evolution

MMS Manufacturing Message Speciﬁcation

OPC Open Platform Communications

PLC Power Line Communication

SET Strategic Energy Technology

SGAM Smart Grid Architecture Model

TCP Transport Control Protocol

TOGAF The Open Group Architecture Framework

UML Uniﬁed Modelling Language

VPP Virtual Power Plant

XML Extensible Markup Language

List of Figures

Figure 1 The three pillars of the IES methodology 1

Figure 2 The IES process in four steps 2

Figure 3 The IES Document Structure 4

Figure 4 IES timing centred on annual Connectathon Energy 5

Figure 5 Plurality of desirable expertises in IES teams and committees 6

Figure 6 Proﬁle Bundling and Common Features 27

Acknowledgements

The tremendous effort made by the members of the IES Austria project team, who participated to their

best in nearly thirty workshop meetings, periodic teleconferences and on-demand communication,

and the valuable contribution of perfectly complementary expertises, are acknowledged with thanks.

The signiﬁcant contributions made by individual researcher and teams, the organisation efforts of

the project lead and co-lead and the numerous contacts greatly promoted the approach in the energy

systems community, which is to be acknowledged likewise. Finally, the innovators that participate

with personnel at the ﬁrst Connectathon Energy events earn our highest respect for bravery and

endurance, and many thanks for the valuable hints and feedback.

The IES Austria team 31

R

References

[1] M. Gottschalk, G. Franzl, M. Frohner, R. Pasteka, and M. Uslar, “From integration proﬁles to interoperability

testing for smart energy systems at connectathon energy,” Energies, vol. 11, p. 3375, Dec 2018.

http:

//dx.doi.org/10.3390/en11123375

[2] “ISO DTR 28380-1: Health Informatics - IHE Global Standards Adoption - Part 1: Process.”

https://www.

iso.org/obp/ui/#iso:std:63383:en

[3] M. Gottschalk, M. Uslar, and C. Delfs, 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,

2017.

http://dx.doi.org/10.1007/978-3-319-49229-2

[4] M. Frohner, M. Gottschalk, G. Franzl, R. Pasteka, M. Uslar, and S. Sauermann, “Smart grid interoperability

proﬁles development,” in 2017 IEEE International Conference on Smart Grid Communications (SmartGrid-

Comm), pp. 189–194, Oct 2017.

http://dx.doi.org/10.1109/SmartGridComm.2017.8340674

[5] IHE Europe, “The IHE Connectathon. What is it? How is it done? Version 006.,” 2018.

https://www.

ihe-europe.net/sites/default/files/WP_Connectathon_2019_0.pdf

[6] IHE International, “Gazelle - eHealth test framework for interoperability.”

https://gazelle.ihe.net/

[7] CEN-CENELEC-ETSI Smart Grid Coordination Group, “First Set of Standards,” tech. rep., 2012.

online,

ftp://ftp.cen.eu/EN/EuropeanStandardization/HotTopics/SmartGrids/

FirstSetofStandards.pdf

[8] IEC 62559-2:2015, “Use case methodology – Part 2: Deﬁnition of the templates for use cases, actor list

and requirements list,” 2015.

https://webstore.iec.ch/publication/22349

[9] SG-CG/RA, “Smart Grid Reference Architecture,” tech. rep., CEN-CENELEC-ETSI Smart Grid Coordi-

nation Group, 2012.

ftp://ftp.cencenelec.eu/EN/EuropeanStandardization/HotTopics/

SmartGrids/Reference_Architecture_final.pdf

[10] The Open Group, TOGAF Version 9 - The Open Group Architecture Framework (TOGAF). 9 ed., 2009.

https://www.opengroup.org/togaf

[11] K. Forsberg, H. Mooz, and H. Cotterman, Visualizing Project Management – Models and Frameworks for

Mastering Complex Systems. John Wiley & Sons, Inc., 3rd edition ed., 2005.

https://www.wiley.

com/WileyCDA/WileyTitle/productCd-0471648485.html

[12] Europa Analytics, “An introduction to the European Interoperability Reference Architecture (EIRA) v2.1.0,”

tech. rep., Europa Analytics, 2016.

https://joinup.ec.europa.eu/sites/default/files/

distribution/access_url/2018-02/b1859b84-3e86-4e00-a5c4-d87913cdcc6f/EIRA_

v2_1_0_Overview.pdf

[13] M. Masi, T. Pavleska, and H. Aranha, “Automating smart grid solution architecture design,” in 2018

IEEE International Conference on Communications, Control, and Computing Technologies for Smart

Grids (SmartGridComm), pp. 1–6, Oct 2018.

http://dx.doi.org/10.1109/SmartGridComm.2018.

8587457

[14] C. Carr, “IHE international, incorporated principles of governance.”

https://www.ihe.net/

wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf

[15] “IHE proﬁle design principles and conventions.”

https://wiki.ihe.net/index.php/IHE_

Profile_Design_Principles_and_Conventions

32 The IES cookbook cba

The IES process in some more detail

•Specifying a Proﬁle has four steps: identify the issue, agree on a solution, specify the solution, publish a new proﬁle.

•Testing Proﬁles has three steps: specify test cases, prepare test tools, execute testing.

•Results has two steps: show who succeeded implementing which proﬁles, state which products support which proﬁles.

•To manage all that, experienced teams constitute dedicated committees that take on the required process management roles.

This work is licensed under a Creative Commons “Attribution-ShareAlike 4.0

International” licence.

Contact:

Dr. Angela Berger, Managing Director

Technology Platform Smart Grids Austria

Homepage:

www.iesaustria.at

e-mail: ies@smartgrids.at

S O F T W A R E

A I

C O

Technical Framework on Local Energy Communities (TF-LEC) Vol.1 Version 0.5 - First trial release

Preprint

Full-text available

Jan 2021

The Technical Framework on Local Energy Communities (TF-LEC) is a structured compilation of informative and normative specifications compiled according to the IES (Integrating the Energy System – www.iesaustria.at) recommendations and template. This Vol.1 summarises and clarifies the Local Energy Communities Business Case considered henceforth, including environmental constraints and envisioned opportunities to integrate energy consumers and distributed energy resources (DER) in the short term balancing of energy supply and demand. The Vol.1 closes with the informative specification of operational functionalities (Business Functions) and the naming of the independent IT systems that interact (Meta-Actors).

Interoperability as a key factor for digitalisation — a success story for cross-sector knowledge transfer

Article

Full-text available

Jun 2023

Crafting organizational security policies for critical infrastructures: an architectural approach

Article

Full-text available

May 2024
JSSS

Critical infrastructures (CIs) are an essential enabler of a nation's well-being and span a multitude of sectors. It is critical to ensure their resilience and protection against security threats, straight from the design phase. Nowadays, CIs take the form of complex socio-technical systems, which rely heavily on digital technology and off-the-shelf components, introducing challenges due to non-composability of security properties. A comprehensive approach for their protection integrates physical security, cybersecurity, risk management, and collaboration with the stakeholders, as they play a key role in identifying and managing vulnerabilities and in the impact evaluation of potential security breaches. Other key requirements in the context of CIs are interoperability, automation and governance, which are often neglected in the process of crafting security policies, as this takes as input the system as-is and disregards architectural design considerations. In this paper, we propose a methodology that takes care of the inter-dependencies between security goals in a given CI and the relevant countermeasures for its subsystems. Our approach considers the relationships between the CI subsystems, focusing on organizational security objectives and the requisite countermeasures to achieve these objectives. The methodology is supported by a context-independent Reference Model for Information Assurance and Security, which can be applied across diverse critical sectors. To complement the methodology, we propose a formal language that enables the verification of the fulfillment of the security goals in a specific solution architecture. The aim is to enable and support CI security, promoting resilience and adaptability in the face of evolving threats. Leveraging the formal language, the proposed methodology can be integrated into an open-source automated tool-chain for the validation of composite systems. Through these contributions, we effectively address the unique security challenges inherent in CI, facilitating automation and interoperability to enhance security and governance in these crucial domains.

Initiating an IES based Technical Framework on Local Energy Communities

Conference Paper

Sep 2020

The ambitious climate goals of the European Union to complete the transition toward an entirely renewable energy supply request new balancing concepts to better cope with the required increase of distributed and volatile energy sources. Energy Communities could be an enabler thereto, the idea being that the community management coordinates heterogeneous energy assets, owned and operated by community members, to jointly utilise their resources internally and thereby reduce external grid load. In this paper we present an analysis of functional requirements to initiate a new technical framework for Energy Communities. This first functional description of Energy Community management aiming on community internal energy balancing is provided as a starting point for integration profiles development according to the Integrating the Energy System (IES) approach.

Automating Smart Grid Solution Architecture Design

Conference Paper

Full-text available

Oct 2018

The Energy sector and Smart Grids face great interoperability challenges, with virtual power plants (VPPs) being a major representative. In this paper, we present a methodology that automates and facilitates the design of solution architectures, producing a structured approach for building interoperable complex systems. Building on solid approaches that incorporate theory and practice of the healthcare enterprise and the Smart Grid sector, our methodology automates critical and time-consuming design steps that are currently performed manually. To accomplish the automation, we enhance and formalize validated principles and frameworks, but moreover, we introduce novel mechanisms to cater for architecture solution correctness, completeness and cohesiveness. The proposed methodology is applied to a VPP use case to demonstrate the applicability of such an architectural approach to other domains as well. An implementation tool of the methodology is also provided to support the practicality of the approach and to enable testability and result-reproducibility.

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

Article

Full-text available

Dec 2018

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.

Smart Grid Interoperability Profiles Development

Conference Paper

Oct 2017

The Use Case and Smart Grid Architecture Model Approach - The IEC 62559-2 Use Case Template and the SGAM applied in various domains

Book

Jan 2017

This book introduces readers to the fundamentals of the IEC 62559 Use Case Methodology, explains how it is related to the Smart Grid Architecture Model (SGAM), and details how a holistic view for both architecture and requirements engineering can be achieved. It describes a standardized and holistic approach to requirements engineering for smart grid projects based on work conducted in the context of the EU M/490 standardization mandate. Over the last years, this method has been established in Europe as the basic building block of requirements engineering in the utilities sector. The authors present a canonical, structured approach that users can apply to the Use Case Methodology and the SGAM, as well as open tools for this purpose. The application in various domains outside the smart grid is also discussed, as it can be used for critical infrastructures or system-of-systems domains like Industrie 4.0 and Ambient Assisted Living. Accordingly, the book also presents various architecture models for different fields of application, like EMAM, SCIAM, RAMI 4.0, and MAF.

The IHE Connectathon. What is it? How is it done? Version 6

Ihe Europe

IHE Europe, "The IHE Connectathon. What is it? How is it done? Version 6.," 8. https://www. ihe-europe.net/sites/default/files/WP_Connectathon_2019_0.pdf.

First Set of Standards

Cen-Cenelec-Etsi Smart

CEN-CENELEC-ETSI Smart Grid Coordination Group, "First Set of Standards," tech. rep.,,,,,. online, ftp://ftp.cen.eu/EN/EuropeanStandardization/HotTopics/SmartGrids/ FirstSetofStandards.pdf.

Visualizing Project Management -Models and Frameworks for Mastering Complex Systems

K Forsberg
H Mooz
H Cotterman

K. Forsberg, H. Mooz, and H. Cotterman, Visualizing Project Management -Models and Frameworks for Mastering Complex Systems. John Wiley & Sons, Inc., rd edition ed., . https://www.wiley. com/WileyCDA/WileyTitle/productCd-0471648485.html.

An introduction to the

Europa Analytics

Europa Analytics, "An introduction to the European Interoperability Reference Architecture (EIRA) v..," tech. rep., Europa Analytics, 6. https://joinup.ec.europa.eu/sites/default/files/ distribution/access_url/2018-02/b1859b84-3e86-4e00-a5c4-d87913cdcc6f/EIRA_ v2_1_0_Overview.pdf.

IHE international, incorporated principles of governance

C Carr

C. Carr, "IHE international, incorporated principles of governance." https://www.ihe.net/ wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf.

Gazelle -eHealth test framework for interoperability

Ihe International

IHE International, "Gazelle -eHealth test framework for interoperability." https://gazelle.ihe.net/. [ ] CEN-CENELEC-ETSI Smart Grid Coordination Group, "First Set of Standards," tech. rep., . online, ftp://ftp.cen.eu/EN/EuropeanStandardization/HotTopics/SmartGrids/ FirstSetofStandards.pdf.

The IES Cookbook - Enabling interoperability the IES way - Edition 0.8

Abstract and Figures

Recommended publications

Intervention or Collaboration ? Rethinking Information and Communication Technologies for Developmen...

Proposal of a multi-scale modelling framework for a product-centric enterprise information system

Case Study Part III: Creating Use Cases for Public Health Information

IHE RO: Interoperable Data Standards for Radiation Oncology