deliverable d2 - flexiciency-h2020.eu · energy services demonstrations of demand response,...

energy services demonstrations of demand response, FLEXibility and energy efficIENCY based on metering data

Deliverable D2.2

Definition of project overall system architecture

V1.6

This project has received funding from the

European Union’s Horizon 2020 research and innovation programme

under grant agreement n° 646482

Ref. Ares(2016)1587519 - 04/04/2016

D2.2 – Definition of project overall system architecture v1.6

FLEXICIENCY GA n° 646482 of 61

D2.2 – Definition of project overall system architecture

Document Information

Programme Horizon 2020 – Cooperation / Energy

Project acronym FLEXICIENCY

Grant agreement number 646482

Number of the Deliverable D2.2

WP/Task related [WP2 / T2.2]

Type (distribution level) PU Public

Date of delivery [23-03-2016]

Status and Version Version 1.6

Number of pages 61 pages

Document Responsible Karima Boukir – ERDF

Author(s) Karima Boukir – ERDF

Bruno Traverson – EDF R&D

Tarik Loiseau – ERDF

Reviewers Jessika Stromback – Joule Assets

Lars Garpetun – Vattenfall

Jan Cupal - Verbund



Revision History

Version Date Author/Reviewer Notes

0.1 31/12/2015 Karima Boukir

Bruno Traverson

Draft

0.8 28/01/2016 Karima Boukir

Bruno Traverson

First circulation to the

consortium

0.9 08/02/2016 Reviewed by

Vattenfall,

SAP/UL

Second circulation to the

consortium

0.10 12/02/2016 Reviewed by Jessica

Stromback

Joule

Third circulation to the

consortium

1.0 23/02/2016 2nd Review by Vattenfall

on 19th feb

4th Circulation

Last version for Official review

1.2 29/02/2016 ERDF adjustments

(PODs)

5th Circulation

1.3 08/03/2016 Review by VERBUND on

4th March

6th Circulation

1.4 11/03/2016 Review by UL for Service

description Form, on 10th

March

7th Circulation

1.5 14/03/2016 Review by ENEL on 14th

March

8th Circulation

1.6 23/03/2016 Technical manager, minor

changes on 17th March

9th Circulation



Executive summary

Major DSOs are working together with market players and other stakeholders within the Horizon 2020 – LCE-07-2014 project FLEXICIENCY to develop a technical model in order to achieve a market place based on meter data exchange. Standardized interfaces will be developed to integrate the platforms of different players. A virtual ICT environment (called Market Place) will catalyze the interactions between relevant stakeholders and encourage cross-country and cross-player access to innovative energy services based on metering data. 5 large-scale demonstrations will be carried out (in Austria, France, Italy, Spain and Sweden) to demonstrate the facilitation and acceleration of deployment of novel services in the electricity retail markets, ranging from advanced monitoring to local energy control, and flexibility participation.

The FLEXICIENCY system consists of four building blocks: the Market Place, the DSO platforms, the service providers’ platforms, and the field components.

This document describes the architecture of the FLEXICIENCY project, looking at functional and non functional requirements, mainly for B2B interactions (between DSO and Service Platforms), including the Market Place as a contact point and IT innovative platform to be developed. A common architecture framework is defined and requirements are listed for data and service exchange at EU level, addressing data privacy and interoperability, among regulated and unregulated energy players. This document includes 5 main sections:

Architecture Vision.

Business Architecture.

Information System Architecture.

Standardization Guidelines.

System Requirements. Requirements will in particular address the system matching with high level Architecture principles of FLEXICIENCY objectives:

Stakeholders Collaboration, facilitating data provision for energy services deployment.

Data privacy and Security, respecting EU and country data privacy policies.

Transparency and quality management, assuring nondiscriminatory access to new Market Players.

Interoperability and Standardization, allowing plug and play of B2B platform connections.

Flexible and Modular Solution, letting more flexibility for energy actors to reuse the IT modules and expand them after the project for future exploitation.

This document defines the technical scope of common areas to be shared within the project. It provides guidelines and starting point for implementation, feeding the WP4 tasks (market Place development) and B2B Platform interfaces development. During implementation process, some points will need to be extended or refined to better specify their content. It is, however, highly recommended to respect these guidelines which are necessary for project robustness. Acknowledgments The FLEXICIENCY Consortium Members are hereby acknowledged for their contribution and participation in the project, in particular: Enel, Endesa, Vattenfall, Verbund AG, SAP SE, University Of Ljubljana, Siemens, Joule Assets, Cybergrid GMBH, Kiwi Power Ltd, EDSO for smart grids. A special thank you to the reviewers and to: Stephane Dotto (SAP), Friedrich Schwarzlaender (SAP), Rok Povše (UL) and Georg Reininghaus (Verbund) for their technical support.



Table of contents

Revision History .............................................................................................................................. 3

Executive summary ......................................................................................................................... 4

Table of contents ............................................................................................................................ 5

List of Figures ................................................................................................................................. 7

List of Tables .................................................................................................................................. 8

1 Introduction ............................................................................................................................. 9

1.1 Scope of the document ..................................................................................................... 9

1.2 Notations, abbreviations and acronyms .......................................................................... 10

2 Project Overview ................................................................................................................... 10

3 Architecture Vision ................................................................................................................ 13

3.1 Stakeholder Collaboration ............................................................................................... 14

3.1.1 The Business Service Objectives ............................................................................. 14

3.1.2 Stakeholders – Their Roles and Concerns ............................................................... 14

3.2 Data privacy and Security ............................................................................................... 15

3.3 Transparency .................................................................................................................. 15

3.4 Interoperability & Standardization ................................................................................... 15

3.5 Flexible & Modular Solution ............................................................................................ 16

4 Business Architecture ............................................................................................................ 17

4.1 Process Steps to be addressed ...................................................................................... 17

4.2 Business Interactions - Roles and Services .................................................................... 17

4.3 Business Interactions – Data Flows ................................................................................ 18

4.4 Market Place Functions .................................................................................................. 19

4.4.1 Registration Management ........................................................................................ 20

4.4.2 Service Catalogue Management .............................................................................. 20

4.4.3 Traceability .............................................................................................................. 20

4.5 Regulated Environment – Functions ............................................................................... 21

4.5.1 Get DSO Identification from electricity bill inputs - REGDSOID ................................ 21

4.5.2 Get DSO Localization from geographic inputs - REGDSOLOC ................................ 22

4.5.3 Customer Consent Feedback - REGCNSFBK ......................................................... 22

4.5.4 Customer Consent by Regulated side - REGCNS ................................................... 23

4.5.5 Data Service provision by Regulated side - REGDATP ............................................ 23

4.5.6 Support Service Provision by Regulated side - REGSUPP ...................................... 24

4.6 Unregulated Environment Functions ............................................................................... 24

4.6.1 Data Service Request by Unregulated side - UNRDATR ......................................... 24

4.6.2 Support Service Request by Unregulated side – UNRSUPR ................................... 24

4.6.3 Data Service provision by Unregulated side - UNRDATP ........................................ 24



4.6.4 Support Service provision by Unregulated side - UNRSUPP ................................... 24

4.6.5 Customer Consent by Unregulated side - UNRCNS ................................................ 25

4.7 B2B Agreement - B2BAGR ............................................................................................. 25

5 Information System Architecture ........................................................................................... 26

5.1 Roles played by the Actors in the current project ............................................................ 26

5.2 The sub-systems ............................................................................................................ 27

5.2.1 Market Place, DSO & ESO Platform Description ...................................................... 27

5.2.2 Market Place, DSO & ESO Platform Responsibilities ............................................... 28

5.2.3 Process Steps Mapped to Environment ................................................................... 30

6 Standardization Guidelines.................................................................................................... 30

6.1 Constraints ..................................................................................................................... 30

6.2 Interoperability and Standard adoption ........................................................................... 31

6.2.1 Interface for the Market Place System ..................................................................... 32

6.2.2 Interface for the B2B interactions ............................................................................. 33

6.3 Architecture Supporting the Process ............................................................................... 33

7 System Requirements ........................................................................................................... 34

7.1 Requirements on the Market Place System .................................................................... 35

7.2 Requirements on the Market Place interactions .............................................................. 37

7.3 Requirements on the B2B interactions ............................................................................ 38

8 Conclusions .......................................................................................................................... 39

9 References ............................................................................................................................ 40

9.1 Project Documents ......................................................................................................... 40

9.2 External Documents........................................................................................................ 40

10 APPENDIX ............................................................................................................................ 41

10.1 System Use Cases List ............................................................................................... 41

10.2 Registration Form in the Market Place ......................................................................... 43

10.3 Service description Form in the Market Place .............................................................. 44

10.4 Actors List as stated in the SUCs ................................................................................ 47

10.5 DSO List in EU ............................................................................................................ 52

10.6 Standard References .................................................................................................. 55

10.6.1 TOGAF Methodology ............................................................................................... 55

10.6.2 IEC – CIM ................................................................................................................ 55

10.6.3 MADES .................................................................................................................... 56

10.6.4 Green Button / OAuth2 ............................................................................................ 56

10.6.5 Modsarus Modelling ................................................................................................. 57

10.7 Examples of Architecture Principles ............................................................................ 59



List of Figures Figure 1 - FLEXICIENCY system architecture ............................................................................... 11 Figure 2 - Example of Data Provision Service (Source Vattenfall) ................................................. 12 Figure 3 - Regulated and Unregulated environments .................................................................... 16 Figure 4 - Customer Consent - Mechanism Diagram .................................................................... 23 Figure 5 - Contract packaging structure and Agreement stages in FLEXICIENCY ........................ 26 Figure 6 - Platform Interactions between Market Place, DSO & ESO for a regulated data service provision ....................................................................................................................................... 29 Figure 7 - Market Place implementation based on SAP Hana Cloud Platform ............................... 34 Figure 8 - SquaRE Quality Model .................................................................................................. 35 Figure 9 - TOGAF Methodology .................................................................................................... 55 Figure 10 - An overview of business objectives (in green boxes), and their interactions with Business Use Cases ..................................................................................................................... 57 Figure 11 - An example of interaction between Business Use Case and System Use Cases. ....... 58



List of Tables Table 1 - Acronyms list.................................................................................................................. 10 Table 2 - Main Architecture vision axis .......................................................................................... 14 Table 3 - FLEXICIENCY Business Services towards End consumer............................................. 14 Table 4 - Motivation of Stakeholders in future exploitation of DSO Platform .................................. 15 Table 5 - Main chronological steps in B2B interactions applied for metering data provision .......... 17 Table 6 - Services Mapped to Architecture principles .................................................................... 18 Table 7 - Business Objects to be standardized within FLEXICIENCY ........................................... 19 Table 8 – DSO Identification via Electricity Bill – examples in EU ................................................. 22 Table 9 - Roles played by the actors as described in D2.1/SUCs .................................................. 27 Table 10 - Platform Description for Market Place, DSO & ESO ..................................................... 28 Table 11 - Platform Responsibilities for Market Place, DSO & ESO .............................................. 29 Table 12 - SUCs stating common & shared services for Market Place, DSO & ESO .................... 30 Table 13 - Process steps and related provider/consumer platforms .............................................. 30 Table 14 - Architecture principle for Exchanged Information ......................................................... 32 Table 15 - Business Objects used in the Market Place interface ................................................... 32 Table 16 - Business Objects used in the B2B interface ................................................................. 33 Table 3 - FLEXICIENCY Business Services towards End consumer............................................. 34 Table 17 - Architecture principle for Component reusability and simplicity .................................... 35 Table 18 - Requirements on the Market Place System ................................................................. 37 Table 19 - Requirements on the Market Place interactions ........................................................... 38 Table 20 - Requirements on the B2B interactions ......................................................................... 38 Table 21 - List of System Use Cases ............................................................................................ 42 Table 22 - Registration Form for new Market Player ..................................................................... 43 Table 23 – Service Description Form ............................................................................................ 46 Table 24 - Actors used in FLEXICIENCY System Use Cases ....................................................... 51 Table 25 - DSO Mapping in some EU countries ............................................................................ 54



1 Introduction In FLEXICIENCY’s Description of Works, a task 2.2 has been set up to provide Definition of the requirement for services – Definition of the system architecture. This report is the deliverable D2.2 ‘Definition of project overall system architecture’, responding to task2.2 which: will describe the system architecture of the whole project, the functional and non-functional requirements, allowing the provision of the envisaged services. Attention will be focused on integration and interface issues (with existing equipment). Requirements will in particular address the need for standardization, non-discriminatory accessibility to all players in the market (including new players) and interoperability. Possible barriers will be highlighted, such as regulatory limitations or additional requirements such as cyber security and data privacy issues.’

The functional specifications devised in the task2.2 will feed WP4 (development of the Market Place).

1.1 Scope of the document

This document aims at defining a common architecture framework and requirements for data and service exchange at EU level, addressing data privacy and interoperability, among regulated and unregulated energy players. We applied the Enterprise Architecture Standard TOGAF® (The Open Group Architecture Forum). This framework enables organizations to effectively address critical business needs, mainly by:

Ensuring that everyone speaks the same language.

Avoiding lock-in to proprietary solutions by standardization. In this document, Requirements are set up for business and IT efficiency, dealing with 3 main parts:

TOGAF - A: Architecture Vision.

TOGAF - B: Business Architecture.

TOGAF - C: Information System Architecture. Requirements will in particular address the system matching with high level Architecture vision:

Stakeholders Collaboration, facilitating data provision for energy services deployment.

Data privacy and Security, respecting EU and country data privacy policies.

Transparency and quality management, assuring nondiscriminatory access to new Market Players.

Interoperability and Standardization, allowing plug and play of B2B platform connections.

Flexible and Modular Solution, letting more flexibility for energy actors to reuse the IT modules and expand them for future exploitation.

During the project, the architecture and implementation content are expected to move and be adjusted in order to reach a common understanding and technical feasibility of the project. The main inputs of this report have been collected from the System Use Cases in [Deliverable D2.1] and from several presentations and exchanges through workshops organized by FLEXICIENCY partners. The content of this document is organized as follows:

• An overview and the context of the project are reported in chapter 2. • The Architecture vision is described in Chapter 3, including main stakes, roles and

concerns of the stakeholders. • The main business interactions that are going to be implemented and standardized

are presented in chapter 4. • Chapter 5 is dedicated to the Information System based on three main blocks:

Market Place sub system, the DSO and Service provider Platforms.

http://w1.opengroup.org/getinvolved/forums/architecture




• Chapter 6 identifies the business objects to be exchanged and standardized. A list of references to be adopted is also provided.

• Chapter 7 gathers the requirements to be respected by the three sub systems. • Conclusions are reported in chapter 8.

1.2 Notations, abbreviations and acronyms

API Application Programming Interface

Demo Demonstration/Trial

DoA Description of the Action

DR Demand Response

DSO Distribution System Operator

EDSO European Distribution System Operators for Smart Grids (non-profit association)

ESCO Energy Service Company or Energy Saving Company

ESO Energy Service Operator

EU European Union

GA Grant Agreement

IPR Intellectual Property Rights

KPI Key performance Indicator

LV Low Voltage

MP Market Place

MV Medium Voltage

PAS Publicly Available Specification

POD Point Of Delivery

PV Photovoltaic

SGAM Smart Grid Architecture Model

SUC System Use Case

SW Software

TSO Transmission System Operator

WP Work Package

TOGAF The Open Group Architecture Forum

Table 1 - Acronyms list

2 Project Overview Major DSOs are working together with market players and other stakeholders within the Horizon 2020 – LCE-07-2014 project FLEXICIENCY to develop a technical model in order to achieve a market place based on meter data exchange. Standardized interfaces will be developed to integrate the platforms of different players. A virtual ICT environment (called Market Place) will catalyze the interactions between relevant stakeholders and encourage cross-country and cross-player access to innovative energy services based on metering data. 5 large-scale demonstrations will be carried out (in Austria, France, Italy, Spain and Sweden) to demonstrate the facilitation and acceleration of deployment of novel services in the electricity retail markets, ranging from advanced monitoring to local energy control, and flexibility participation.




The overall concept is represented in Figure 1. It consists of four building blocks: the Market Place, the DSO platforms, the service providers’ platforms, and the field components.

Figure 1 - FLEXICIENCY system architecture

The DSO (or any Regulated metering data operator) platforms will be enhanced in the project leveraging on existing systems and infrastructures in order to provide any interested stakeholder with smart metering data in a non-discriminatory way.

Several Service platforms (IT platforms from different types of market players, mainly Unregulated Service providers towards end Customer) are interested in having access to metering data, subject to customer consent validation.

The following diagram, illustrates the main interactions between different sub systems, from consumer service acceptance to service delivery, while crossing FLEXICIENCY system for Metering data exchanges between DSO and Energy Service Company and their respective platforms.



Figure 2 - Example of Data Provision Service (Source Vattenfall)

While the main vision behind the project is to make data from regulated metering data operators available to Energy Service Companies to allow the creation and execution of new services, additional data can also be provided by other non-regulated players, e.g. asset owners and operators. The objective of the Market Place is to connect actors in the market to accelerate the provision of services based on data accessibility, both from regulated and non-regulated sources. Data exchanged via the Market Place relates to metering data (Energy consumption & Generation) and also other data such as sensors reading (temperature or any data related to metoffice), forecast, device consumptions, generations, EV status of charge and time of start. All data flows will be implemented by peer to peer communications, i.e. the Market Place will be a contact point between stakeholders but physical data transfer is performed point to point (directly from platform to platform). Two modular configurations are foreseen, according to the required stakes, business responsibilities and implementations:

Regulated Environment (MP Service providers are Regulated Actors):

1. Only metering data and support services provided by regulated operators (DSO, TSO, and any other regulated Metering data managers).

2. Service requesters are any player in EU that provide services to B2C, with a valid Customer Consent, using standardized processes for data transmission.

3. Specific requirement on data privacy applying EU policy. 4. Interoperability and standardized B2B data exchange, compliant with IEC/CIM. 5. Common unique platform that delivers metering data services to any player at

EU/National level, not in competition with others, but could grow by adding EU regulated partners progressively



6. Market Place regulated by an EU/National Regulator and operated by a regulated entity (e.g. DSOs/DSOs Association, Regulators/Association of Regulators, Single Buyers)

Unregulated Environment (MP Service providers are Unregulated Actors):

1. Data (from unregulated players) made available via the MP. 2. Services of data accessibility (from unregulated side) and also other services

(tools and methodologies) 3. Specific requirements for unregulated players, especially for Service provider

registration, and data privacy protection (see requirement for data scope). 4. Deregulated platform facing an IT competition (i.e. several Market Places either

at EU or national level possible) 5. Market Place operated by other players (e.g. EU association) (but still neutrally).

The System Use Cases (SUCs) and the five demonstration projects that will be carried out on field are described in the deliverable D2.1.

3 Architecture Vision The main driver of this project is to create a standard and open way to provide and collect electricity consumption data around the European market. This will allow energy service providers to build innovative services around this data using the FLEXICIENCY platform. Requirements will in particular address the matching with high level Architecture vision, such as:

Stakeholders Collaboration, facilitating data provision, especially Smart Metering upcoming data, for the deployment of the following energy services :

o Advanced Monitoring o Local Energy Control o Flexibility Participation

Data privacy and Security, respecting EU and country level data privacy policies.

Transparency and quality management, assuring nondiscriminatory access to new Market Players, by offering recording, tracking and audits services.

Interoperability and Standardization, allowing plug and play of B2B platform connections. A list of common services and common data exchange interactions is extracted from all SUCs to make the best reuse of different ‘local/demo’ contributions.

Flexible and Modular Solution, letting more flexibility for energy actors to reuse the IT modules and expand resulting sub systems after the project, at a minimum of cost. This will also allow more freedom in future extensions integrating upcoming rules which may impact the system in its evolutions.

The main Architecture vision principles are summarized in the following table. The whole architecture of the project is driven by these principles as fundamentals to be checked through whole steps of the project, especially the design and implementation stages, which will be carried out in the WP4.

Vision Principle Concern/Target/Motivation

Stakeholders Collaboration

Facilitation of data provision, especially Smart Metering upcoming data, for the deployment of the following energy services :

o Advanced Monitoring o Local Energy Control o Flexibility Participation



Data privacy and Security

Respect of EU and country level data privacy policies

Transparency and quality management

Assures, by auditing/checking/recording/tracking services, the control for nondiscriminatory access to new Market Players

Interoperability and Standardization

Allows smooth and cost effective B2B platform connections, minimizing their effort for interfacing to the system.

Flexible and Modular Solution

Provide a more flexible and reusable system components, valuable for future exploitation at a minimum of cost.

Table 2 - Main Architecture vision axis

3.1 Stakeholder Collaboration

3.1.1 The Business Service Objectives

FLEXICIENCY Project deals with 3 main business objectives for service delivery towards the end consumer. These objectives need to be fulfilled by the targeted architecture solution.

Name Description

Advanced Monitoring Enhance customer awareness and empower them to become a more active player

Local Energy Control Local energy optimization and modulation, together with value added services

Flexibility Participation Aggregate customers to enable new services to the market and the energy system

Table 3 - FLEXICIENCY Business Services towards End consumer

3.1.2 Stakeholders – Their Roles and Concerns

A generic actor (with minimum of rights) in FLEXICIENCY is called a ‘Market Player’. It must have a direct or indirect link with the delivery of the 3 main business objectives towards the end consumer, as described in the table above.

The actors are classified in 3 main families, according to their stakes, roles and potential interest in the use of FLEXICIENCY. They are listed as follows: Regulated players: Energy Regulated Player: DSO, TSO or any Metering Data Manager. Unregulated players:

Energy Unregulated Player: Retailer, ESCO, Aggregator.

Industrial Player: technology providers, manufacturers, energy asset (such as PV, sensors, etc) owners.

Energy IT & Business Consultancy providing tools, simulations and methodologies.

Public bodies:

Research Institute: University or any independent research body.

Public Body: EU, Energy Regulators, Local Authorities, Energy Associations. The main Motivation of Stakeholders in the exploitation of FLEXICIENCY DSO Platform is

described in table 4 (as stated in D11.3 ‘Exploitation plan’).



ENERGY REGULATED PLAYERS (DSO, TSO or any Metering Data Manager)

DSOs would evolve their role as data manager and market facilitator by publishing their Services on an EU portal (Market Place). Moreover, alongside market facilitation, the availability of both historical and real time data would benefit and enhance internal DSO applications such as real time grid optimization, network observability and forecasting. Higher grid observability (both in terms of load and generation) would also benefit coordination between DSOs and TSOs, especially in the perspective of the implementation of demand response at larger scale and the participation of distributed generation in the management of the electricity system.

ENERGY UNREGULATED PLAYER (Retailer, ESCO, Aggregator)

Alongside final customers consulting their consumption and generation data, market players (such as retailer, aggregator, ESCO) are the actors most likely to exploit the data accessibility made possible through the implementation of DSO platforms (and related interoperable interfaces) by developing new services based on such data.

INDUSTRIAL PLAYERS (technology providers, manufacturers, business consultant)

Industrial players may develop further solutions to advance technology and applications on the basis of the data made available.

RESEARCH INSTITUTES

Research institutes may use data made accessible with customer consent for business and market modeling, prototyping of new devices for services, customer profiling and data analytics, etc.

PUBLIC BODIES (EU, Energy Regulators, Local Authorities, Energy Associations)

Public bodies, such as Municipalities, can exploit the data accessibility enabled through the DSO platforms to improve city planning and use data collected from different type of sources also to activate new services to their citizens.

Table 4 - Motivation of Stakeholders in future exploitation of DSO Platform

3.2 Data privacy and Security

With the upcoming Smart Metering deployment, the data privacy regulation is currently discussed within EU and different countries to manage the policy and regulation in metering data governance & management. For this purpose, the project will focus on data security and especially on the Customer Consent Collection/Revocation for the use of its data. Likewise, the security and privacy of data generated in other assets beside DSO meters has to be maintained and is considered.

3.3 Transparency

To respect regulatory rules for non-discriminatory service accessibility especially within the regulated environment, and to better assess the quality of the system responses, any relevant steps of the process will be recorded and tracked. The gathered data will allow qualified auditors to extract statistics for technical and non-technical assessments.

3.4 Interoperability & Standardization

Towards plug and play B2B platform connections, a list of common services and common data exchange interactions is extracted from all SUCs to make the best reuse of different ‘local/demo’ contributions. Standardization in processes, content, formats and communication protocols are adopted for:



Service Catalogue.

Customer Consent.

B2B Service Agreements.

Data exchange.

3.5 Flexible & Modular Solution

Because the energy sector is changing, the targeted system has to be open and flexible for future changes at a minimum of cost. This flexibility is given to the system to be better leveraged after the project for further exploitation needs. These evolutions are likely to have different orientations for 2 major actor sets: regulated and unregulated. Therefore, the whole system must be structured into regulated and unregulated independent environments, building two modular configurations, according to their business responsibilities and implementation needs.

Regulated Environment, where only Regulated Actors are B2B Service providers on the Market Place.

Unregulated Environment, where only Unregulated Actors are B2B Service providers on the Market Place.

Figure 3 - Regulated and Unregulated environments

While service providers are separated in 2 different environments, any B2B service requester has

a unique access to FLEXICIENCY platform and could get different services from both regulated

and unregulated sides, as if it was in the same platform.



4 Business Architecture The following chapters are about business Services and Processes, while business objects are included in the deliverable D2.3 [REF D2.3].

4.1 Process Steps to be addressed

In this section, the scenarios between registered Market Players (Providers /Requesters) are listed, in a chronological way for an example of metering data provision. This includes the Market Place interactions and B2B interactions (DSO and Service Platforms interactions). The following scenarios categories are not included:

- B2C interactions : Customer (end consumer) and Energy Service Platform (ESO) interactions scenarios.

- Platform internal scenarios such as DSO platform data calculation, Service platform data collection.

Scenario name Scenario description Main

Actor

1. Service Registration DSO registers a Business Service Offer on the Market Place (the offer is a set of services of the same type. Through the registration process, the provider includes everything needed to automatically generate an contract agreement such as duration options, prices etc)

Market Place DSO

2. Service Search ESO searches for Business Services on the Market Place Market Place ESO

3. Service Request ESO requests a service through the Market Place (this is related to the MP Service Subscription , as a wish list from the

requester)

Market Place ESO

4. Service Provider Identification

The Market Place identifies the Service providers (mainly DSOs)

Market Place

5. Service Subscription ESO subscribes to each DSO services in the Market Place (this is related to the B2B Service Subscription. B2B contract agreement is generated, the provider is informed by the market place)

Market Place ESO

6. Service Activation The ESO requests a service activation from the DSO, for a given list of PODs and proof for customer consent. (Contract agreement attached to the service offer is generated and signed, the Service is activated for a given list of PODs)

ESO DSO

7. Customer Consent Check

The DSO collects & checks the compliance of customer data consent for the related service to be activated

DSO

8. Data calculation The DSO extracts/calculates the individual/aggregation data.

DSO

9. Data transmission The DSO sends individual/aggregated consumption data to the ESO according to their agreement. (to a repository address for instance depending on B2B arrangements)

DSO

10. Data collection The ESO collects the data sent by the DSO (from a repository address for instance)

ESO

Table 5 - Main chronological steps in B2B interactions applied for metering data provision

4.2 Business Interactions - Roles and Services

After setting up, the main vision principles and major interaction steps between the stakeholders, we can deduce main services of the shared system and distribute roles & responsibilities among the actors (Market Place, DSO and ESO). This step is prior to the Information System



requirements, which will be developed in the next section. The services mapping with the architecture vision highlights their contribution in achieving this vision.

Actor Services & Responsibilities Architecture Vision

Market Place

- Registration / Authentication

- Documentation

Collaboration,

Data Privacy & Security

Transparency

- Service Catalogue Management

- Service Subscription

Interoperability and Standardization of B2B Service Catalogue

Interoperability and Standardization of B2B Service Offer Agreement

- Recording, tracking, Audits Transparency

- Split up Regulated and Unregulated environments

- DSO Identification/Localization/Mapping (in the regulated environment)

Flexible & Modular Solution

Collaboration

DSO

- Data Custodian

- Manage Customer Consent

Data privacy and Security

- Manage Service Offer

- Manage B2B agreement

- Manage Service delivery (data transmission)

Interoperability and Standardization of B2B Service Agreements and of

B2B Data Service Exchange

- Send notifications to MP for traceability Transparency

ESO

- Specify Localization inputs to the Market Place allowing DSO localization (e.g. via POD filter)

Collaboration

- Respect Customer Consent process Data privacy and Security

- Manage Service Subscription (resp. Offer)

- Specify data to the service provider

- Manage B2B agreement

- Manage Service Reception (data collection)

Interoperability and Standardization of B2B Service Agreements and of

B2B Data Service Exchange

- Send notifications to MP for traceability Transparency

Table 6 - Services Mapped to Architecture principles

4.3 Business Interactions – Data Flows

In the deliverable D2.3, five data sets have been determined to cover the main standardized data exchanges. We recall here those data flows and map them with the Architecture vision, in order to deploy the right attention and means for these objects.



Data set Business Objects Architecture vision to match

Market Place and Market Players (Market Place Interactions with B2B)

MKP-ADD - Market Place Location MKP-DES - Market Place Description

MPL-REG - Market Player Registration MPL-ADD – Market Player Location

Stakeholders Collaboration Flexible & Modular Solution Data privacy and Security

MPL-DES - Market Player Description MPL-AUT - Market Player Authentication

Service Offer and Subscription (Market Place Interactions with B2B)

MKP-SRV-OFF – Market Place Service Offer MKP-SRV-SUB – Market Place Service Subscription B2B-SRV-SUB – B2B Service Subscription

Transparency Interoperability & Standardization (of B2B Service Catalogue)

MKP-SRV-DES – Market Place Service Description

Customer Consent (B2B-B2C-B2B Interactions)

CUS-CON-DES – Customer Consent Description CUS-CON-ACK – Customer Consent Acknowledgement

CUS-CON-REV – Customer Consent Revocation

Data privacy and Security Interoperability & Standardization (of Customer Consent)

Service Activation (B2B Interactions)

DSO-REQ – DSO Service Activation Request DSO-CNF – DSO Service Activation Acknowledgement

USP-REQ – Unregulated Service Activation Request

Interoperability & Standardization (of B2B Service Agreements)

USP-CNF – Unregulated Service Activation Acknowledgement

IND-DAT-SEL - Individual Data Selection AGG-DAT-SEL - Aggregate Data Selection SRV-ACT-AGR – Service Activation Agreement

Service Provision (B2B Interactions)

IND-DAT-VAL - Individual Data Value

IND-DAT-ACK - Individual Data Acknowledgement

Interoperability & Standardization (of B2B Data Service Exchange)

AGG-DAT-VAL - Aggregate Data Value AGG-DAT-ACK - Aggregate Data Acknowledgement

TECH-FLEX-REQ – Technical Validation Request

TECH-FLEX-RESP - Technical Validation Response

Table 7 - Business Objects to be standardized within FLEXICIENCY

4.4 Market Place Functions

The main services of the Market Place are mainly about: Registration, Service Management, Networking, Look up, Tracking, Logging, Reporting, Monitoring, Auditing. We can group them in 3 sets:

Registration Management

Service Catalogue Management



Traceability: Tracking/Reporting The Market Place should offer Pre and Post processing functions with an ease of use to allow options to the market players, and data extractions for Audits and KPIs establishment. In the following section, some services towards market players are stated for FLEXICIENCY pilots. As stated previously (Principle for Flexible & Modular Solution), the architecture must be flexible giving a room for further services to be implemented after the project.

4.4.1 Registration Management

In order to access the Market Place functionalities end-users have to register. A registration procedure is described through a form provided in the appendix. It states the status of the company and the roles which will be acted through the Market Place. The section 5 describes the major roles played in FLEXICIENCY demos.

4.4.2 Service Catalogue Management

Each market players (such as a DSO, Retailer, ESCO, Aggregator) will have access to a Service Management Console that will enable the management (registration, edit, removal) of the services offered on the Market Place.

Any service offered on the market place will have to go through a registration process that will consist of a wizard, where the market player offering the service will have to:

Provide information about the service, such as service category, service name, service description, service end-point, service technical documentation and examples, etc.

Decide whether they want to pass a validation process. In case they decide not to pass the validation, the provided service is not “live” (visible) to other players. They can trigger the validation process later in the service management console. The service validation process, when triggered, starts an interaction with a registered service and performs certain checks to ensure that the services and interfaces are compliant with the standard defined in the Market Place. If the validation process is passed, then the service can be marked as “live”, so it becomes visible by other market players in a Service Catalogue.

Decide whether they would like to send/receive notification to/from a certain group of Market Place market players that new service is available.

Search by keyword – the market player defines a keyword and the Market Place will return a list of services containing this keyword in one of the service attributes. The keyword can be included in the service name, service description, tag etc.

Filtering – the market player can further narrow down the number of results by defining filters. Filters can be set for example on categories (only services assigned to a certain category are selected), on location (only services available in certain country are listed), etc.

Sorting and paging – results can be sorted by predefined attributes, for example by the date and time of registration.

4.4.3 Traceability

There will be two different areas of tracking to be implemented in the Market Place environment:



For the communication and interaction of any user with the Market Place itself (e.g. to register or to look for some services) and for setting up the relations between market players. In particular:

o All the accesses to the MP will be logged for further evaluation.

o The exchange of messages among market players will be documented in the MP beside the messages themselves. This documentation includes identification, authorization of the communication given by the participants. There will also be support messages for the handshake in the communication like receipts and error notifications and monitoring of replies (according to the relevant system use cases). In case of errors or missing replies notifications/alerts will be sent to the relevant parties.

4.5 Regulated Environment – Functions

The functions handled by the regulated side (mainly DSO, TSO, Metering operators) are provided in this section. The following 3 first functions are provided by the Market Place, while the last ones are provided within the B2B system.

4.5.1 Get DSO Identification from electricity bill inputs - REGDSOID

Major EU countries have several DSOs that cover the country. These are mainly located in geographic areas. However, Retailers/ESO/aggregators may have customers located throughout the whole country (and across Europe) without knowing the exact DSO who is managing each of their customer’s data. Further to the common services listed above, the Market Place will have to manage a specific service in the Regulated environment to identify the DSOs with a given information extracted from customer bills (mainly PODs or postcode, see SUC WP2_7 in D2.1). Depending on the country organization, a sufficient input (found in the electricity bill) could be enough to find out which DSO is the related data custodian. This function of Identification will be implemented in the Market Place, for at least the Countries that are collaborating in this project. After receiving a search request from the Service Platform (ESO), the Market Place identifies the DSOs fitting with the search criteria and provides the list with the contact information to Service Platform. The service requester has to provide a list of localization information for its customers to the MP and receives the matching to the corresponding service providers (DSO). The market player is also informed, where no match could be found (for instance if smart metering data are missing in the localized area, or when the area is not covered by a registered DSO in FLEXICIENCY, etc). This function can also be run independently just to explore the DSOs covering the customer portfolio prior to service request. The following table provides example of PODs mapping (source FLEXICIENCY partners) without exposing the entire POD digits neither whole customer’s address. This means the customer identity is fully protected, while its data custodian could be identified.



Country DSO Map in the Country Number in total

POD example (unique code for every measuring point) Coding which identifies the DSO: (Yes/No), and how

Austria No major DSO About 160 DSO in total

AT.008100.08010.0O6G56M11SN51G21M24S YES : the POD is enough to find out the related DSO (via 6 first digits)

France ERDF About 130 DSO in total

22 416 049 076 398 NO DSO coding. INSEE code (from the address) provides a unique DSO

Italy Enel Distribuzione About 150 DSO

IT001E151624936 YES : the POD is enough to find out the related DSO (via 3 first digits)

Spain Endesa Distribución About 333 DSO in total

ES 0031 103686223001VV0F LL DDDD CCCCCCCCCCCCEENT YES : the POD is enough to find out the related DSO (via 4 first digits)

Sweden Vattenfall Eldistribution AB About 160 DSOs

735999100015544875

YES : DSO code is 3 digits from the 7th

Code = 100 (for Vattenfall Eldistribution AB)

Slovenia (UL)

No major DSO 5 DSOs in total

2-812345 X-ABCDEF, X corresponds to the DSO (X=2, 3, 4, 6, 7) ABCDEF: Is just a unique 6 digit number for every measuring point. YES : the POD is enough to find out the related DSO (via the first digit)

Table 8 – DSO Identification via Electricity Bill – examples in EU

4.5.2 Get DSO Localization from geographic inputs - REGDSOLOC

Further to the common services listed above, the Market Place will have to provide a specific service in the Regulated area to map DSOs with a given geographic localization (as any online mapping, by country or region or department or even a street). This function is described in the SUC WP2_7 in D2.1. In this case, the Market Player does not have customer portfolio and is looking for DSOs for first contact or help for potential request (for market exploration or aggregated data). In this case, the Market Player can identify the DSOs who cover the targeted geographic areas. The market player will end up with a big or short list of DSOs (including their contacts), depending on the granularity of its inputs. For instance if the targeted country is France: Input = France MP Output = 130 DSOs Input = Town MP Output = 1 to 2 DSOs Input = code INSEE (little area) MP Output = 1 unique DSO Lists of DSOs per country are publicly available most of the time (see the related table in the appendix). However, each EU country does not always provide a unique identification for a given geographic mesh. For instance, in Austria, we cannot assure a unique DSO even on a street (with a given POD, the related DSO is unique). In this case, the market player can just contact each of the listed DSOs provided by the market place for the needed information. FLEXICIENY’s Partners and potential future users will have to collaborate closely with market place developers to populate this function by providing information such those given in the table 7.b.

4.5.3 Customer Consent Feedback - REGCNSFBK

Further to the common services listed above, the Market Place will have to manage a specific service in the Regulated area to track the customer data consent collections, by storing the notifications sent by the Market players. This will allow statistics assessment (percentage of success for data consent per country or Market Player for instance.)



Customer Consent success trace is recorded in the Market Place. The result of the provision of the customer consent for data usage is (indirectly) tracked on the Market Place via the B2B communication.

4.5.4 Customer Consent by Regulated side - REGCNS

In order to provide individual data, in compliance with the regulatory framework and relevant rules regarding cyber security and data protection, the DSO will have to check the compliance of the customer consent, prior to any data transmission to a MP service requester. An example scenario is the case in which a DSO has to provide a customer’s metering data to a Retailer that is willing to use these data to offer to the customer energy efficiency services. In this scenario the customer must authorize the DSO to transfer the data from its platform to the Service platform. Implementation is specific for each country: As Data Privacy is managed on country level, we assume that customer consent will be specific to each country on practical point of view. However, looking at international standards such as [GREENBUTTON] and IEC Working groups [IEC/WG 6] the process will likely look as the diagram below illustrates it. This mechanism is standardized and shared within the project (in SUC D2.1/WP2-10). It is stated as a prerequisite for any use case which involves the customer consent for data use.

Figure 4 - Customer Consent - Mechanism Diagram

4.5.5 Data Service provision by Regulated side - REGDATP

This is about the Data delivery service described in the D2.1. The service of data delivery can be offered on the market place both by regulated and unregulated actors and can cover the exchange of historical data, real time data, forecast, raw data, processed data, etc. DSOs (or the regulated meter operator) will particularly supply metering data, and results of any processing (i.e. forecasts, aggregated data, etc.) at a given frequency.

The regulated Data provider will have to implement the REGDATP function to interface to the Market Place and to allow Data delivery from its Platform to the Service Platform (unregulated Service Requester).

sd Customer consent v 5

Market Player

(from Provide

Individual Data)

DSO

(from Provide

Individual Data)

Customer

(from Provide

Individual Data)

Customer consent request()

Request to collect customer consent()

Customer consent (I1)

Customer acknowledgement(I2)

ESO acknowledgement(I3)



4.5.6 Support Service Provision by Regulated side - REGSUPP

The Service support is related to ‘service exchange’ as stated in D2.1. It can be offered on the market place both by regulated and unregulated actors.

Regulated players can be DSOs offering a service of flexibility technical validation for the deployment of Active Demand programs.

This function needs to be implemented to interface to the Market Place and may be delivered as a report which can simply be sent by email on B2B basis.

4.6 Unregulated Environment Functions

The functions handled by the unregulated side (mainly retailers, Aggregators, ESOs, ESCOs, PV manufacturers, EV battery manufacturers) are provided in this section.

4.6.1 Data Service Request by Unregulated side - UNRDATR

The requesters of data delivery services can use these data either to provide their final customers with B2C services (i.e. advanced monitoring, local energy control or flexibility) or to deliver other B2B services (such as support service for helping business decisions). The unregulated Data Requester will have to implement the UNRDATR function to allow Data collection from the DSO Platform to the Service Platform (unregulated Service Requester).

4.6.2 Support Service Request by Unregulated side – UNRSUPR

Unregulated players can ask to DSOs a service of flexibility technical validation for the deployment of Active Demand programs.

This service may be delivered as a report which can simply be sent by email on B2B basis.

4.6.3 Data Service provision by Unregulated side - UNRDATP

Unregulated asset (data) owners (e.g. ESCOs, PV manufacturers, EV battery manufacturers, etc. can supply other types of data (data from field components, weather data, etc). The unregulated Data provider will have to implement the UNRDATP function to interface to the Market Place and to allow Data delivery from its Platform to the Service Platform (unregulated Service Requester).

4.6.4 Support Service provision by Unregulated side - UNRSUPP

This is about exchange services (as stated in D2.1), such as tools, methodologies, Business assessments, needed to achieve final customer services (advanced monitoring, local energy control or flexibility). This function needs to be implemented to interface to the Market Place and may be delivered as a report which can simply be sent by email on B2B basis.



4.6.5 Customer Consent by Unregulated side - UNRCNS

In order to provide individual data, in compliance with the regulatory framework and relevant rules regarding cyber security and data protection, the B2B Service Provider of data will have to check the compliance of the customer or asset owner consent, prior to any data transmission to a MP Service Requester. An example scenario is the case in which a B2B Service Provider has to provide a customer’s heat pump operation data to an ESCo that is willing to use these data to include the customers’ asset into an aggregated pool of flexible assets to provide Grid Services. In this scenario the owner must authorize the Service Provider to transfer the data.

4.7 B2B Agreement - B2BAGR

When contact is established via the Market Place, the B2B sides will get through: 1. High level Contract agreement. 2. Service contract agreement. 3. Data specification contract agreement (called also activation of the service). 4. Data flow transmission.

The B2B agreement gets through a process of 3 different layers stated in a chronological way (there might be exceptions depending on product description): Stage 1 (Service Offer): Terms & Conditions given by a Service Provider on the Market Place when it publishes a service offer. It is the Contract Layer 1 (via Market Place).

Stage 2 (Service Specific): Specific terms and conditions applying to a given service attached to the main Service Offer. It is Contract Layer 2 (via Market Place) which provides specific Service Description (referring to Service Offer conditions and subject to its success). The service offer is related to a category called service type in D2.3, such as:

Individual Metering data, or

Aggregated data, or

Service Support. Stage 3 (Service Activation): each service is activated by the Service Provider on PODs provided by the Service Requester. Customer consent management and regular PODs refreshments are managed in this step. This is the Contract Layer 3 (via B2B Interaction). Data can be further specified if the published service is not enough detailed or does not match the need of the requester.

In the Figure 5, the provider published an offer of N services. The requester has subscribed to services: 1, 2, 4 and N. The Service 2 has been chosen but has not been activated yet. The service 3 has not been chosen (no subscription). The activation has been done twice on service 1 (one time with list 1 of PODs, and the second with list 2).



Figure 5 - Contract packaging structure and Agreement stages in FLEXICIENCY

5 Information System Architecture

5.1 Roles played by the Actors in the current project

In the current FLEXICIENCY project, ‘DATA Provision by the regulated side’ function is the main active role, played by DSOs as B2B data providers and ESOs as B2B data consumers. Some support services are provided by the regulated side (for network security or data checking) and unregulated side such as Industrials may provide further data and some consultancy may provide simulations on business assessments for the deployment of energy business services. Public bodies such as: EU, Regulators, Municipalities etc. may play ‘passive role’, as Auditors of the whole system, via post processing feedback analysis from a such system. Research institutes are potential users in the future but have no active user role in the current project. The following table presents the different roles played by the major actors, collected from the System Use Cases (SUC), which are listed in the appendix (38 in total: 30 about the demos and 8 about the MP). For more information about SUCs, we refer to the deliverable D2.1 [REF D2.1].



Actors Roles SUCs Nb

REGULATED PLAYERS

Regulated Data Service Provider

Individual Metering data

Aggregated data

Data analytics

All

Regulated Support Service Provider

Technical validation of a DR for network security

1

UNREGULATED PLAYERS

Regulated Data Service Requester

Individual Metering data

Aggregated data

Data analytics

All

Regulated Support Service Requester

Technical validation for network security

1

Unregulated Data Service Provider

Data records from assets

Weather data records.

1

Unregulated Support Service Provider

Tools, simulations, methodologies

3

Public bodies Auditor (passive/indirect role)

Check, audit, feedback analysis, reporting

Table 9 - Roles played by the actors as described in D2.1/SUCs

According to TOGAF methodology, only roles that are covered by the SUCs of FLEXICIENCY (cf. D2.1) could be included in the architecture scope. Looking at table 9, major SUCs are about Metering data provision by DSOs (using a DSO Platform), while ESOs are requesting these data (using a SERVICE Platform), see figure 1. The 2 Platforms will have both to interconnect to the Market Place and between them (peer to peer). When contact is established through the Market Place, the B2B sides will get through:

1. Contract agreements, 2. Data specification, and finally 3. Data flow transmission.

We will use from now the names DSO and ESO to address the IT interactions and implementation requirements. A part for regulated actors specificities, the requirements apply to any data service provider (as for the DSO) and to any data service requester, providing energy services towards the consumer (as for the ESO). The DSO is using a ‘DSO Platform’ to manage the metering data provision to external requesters. The ESO is using a ‘Service Platform’ to manage its data requests and acquisition from the DSO. Any platform, providing data services, equals a DSO platform in terms of Market Place connection and functionalities except those special of regulated actors.

5.2 The sub-systems

5.2.1 Market Place, DSO & ESO Platform Description

This section describes the project stakeholders. In bold platform related stakeholders that will interact within the system. Their role will be described in the next sections.



Name Description

Market Place

The Market Place is a Contact Point for business deals between stakeholders of the electricity retail markets. The main service is about data exchange from DSO to ESO.

Market Place Platform Pan-European platform to support approaches developing new services for the development of electricity retail markets.

Market Player

A Market Player could be any B2B company which has a direct/indirect link with the provision of energy services towards end consumer in:

Advanced monitoring,

Local Energy Control,

Flexibility Participation In general, a system interacting with the Market Place.

DSO

Acronym for Distribution System Operator. According to the Article 2.6 of the Directive: "a natural or legal person responsible for operating, ensuring the maintenance of and, if necessary, developing the distribution system in a given area and, where applicable, its interconnections with other systems and for ensuring the long-term ability of the system to meet reasonable demands for the distribution of electricity". Moreover, the DSO is responsible for regional grid access and grid stability, integration of renewable at the distribution level and regional load balancing.

DSO Platform A platform managed by DSO that will implement the interfaces and processes in order to communicate with the other stakeholders. A DSO platform will be responsible to provide metering data.

ESO Acronym for Energy Service or Saving Operator. Organization offering energy services to the customer (end consumer).

Service Platform

A platform managed by an ESO, the platform implements the interfaces and processes in order to communicate with the other stakeholders. A Service platform will be responsible to request a data based on some criteria and to consume data provided by a DSO platform.

Table 10 - Platform Description for Market Place, DSO & ESO

5.2.2 Market Place, DSO & ESO Platform Responsibilities

The purpose of this section is to describe the actors in scope of the target architecture. The description includes the roles and responsibilities of each actor. In order to reach the main business objectives (Advanced Monitoring, Local Energy Control and Flexibility Participation), three stakeholders need to put in place communication processes. The stakeholders are the following:

- DSO Platform: main role is metering data management and provision. - Service Platform: main role is service request and data management. - Market Place: main role is contact facilitation and service catalogue management (service

registration, lookup, publish/request/subscribe) Please note that, data management are platform internal roles and out of scope of this document. The following figure outlines the processes to be built between stakeholders. The processes steps details will be described in the next section.



Market Place

DSO Platform Service Platform

Services:

- Request

- Subscription

- Search

Service Registration

Data Request

Data Transmission

Figure 6 - Platform Interactions between Market Place, DSO & ESO for a regulated data service provision

Actor Role Responsibilities SUCs

Market Place Platform

Service catalog management

- Provide DSO list and localization to Service Platform

- Provide DSO the ability to register a service - Publish the registered DSO service - Provide Service Platform the ability to subscribe to

a service

- WP2_7

- WP2_1

- WP2_2

- WP2_3

DSO Platform

Service Provider Data Provider

- Register to Market Place - Register Service offer - Check Service Platform data request - Check Customer Consent compliance - Provide data provision confirmation - Deliver consumption data - Send acknowledgment/notification to Market

Place for relevant steps.

- WP2_1

- WP2_4

- WP2_10

- Demo SUCs

Service Platform

Service requester Data consumer

- Register to Market Place - Subscribe to Services - Request services from the Market Place - Request services from the DSO (after MP

identification) - Request data from DSO (after DSO confirmation)

with service parameters - Send acknowledgment to DSO after receiving

data. - Send acknowledgment/notification to Market

Place for relevant steps.

- WP2_1

- WP2_4

- WP2_10

- WP2_3

- Demo SUCs

Table 11 - Platform Responsibilities for Market Place, DSO & ESO

Platform responsibilities, commonly shared within FLEXICIENCY project are described in related SUCs included in D2.1.The following table gathers the list of those SUCs.

Code Title

WP2_1 New market player enrolls in the market place

WP2_2 Market participant manage its services & Market participant “pass” a MP certification

WP2_3 Market Player enrolls to a new service

WP2_4 Service activation

WP2_5 Service Requester requests the service stop

WP2_6 Service Requester requests the service cancellation



WP2_7 Identification of MP service providers based on localization input

WP2_8 Service Provider requests statistics regarding service execution

WP2_9 Manage ancillaries services

WP2_10 Collect customer consent for transmission

WP2_11 Revoke customer consent for transmission

WP2_12 Technical Set-up and Validation

WP2_13 Market player service requester quits a subscribed service

Table 12 - SUCs stating common & shared services for Market Place, DSO & ESO

5.2.3 Process Steps Mapped to Environment

The purpose of this section is to cross-reference the business processes, in scope, to the business and technology environment.

Process step Provider actor Consumer actor

Market Place Interactions

Market Player Registration Market Place DSO Platform

Market Player Registration Market Place Service Platform

Service registration Market Place DSO Platform

Service search Market Place Service Platform

Service request Market Place Service Platform

Service Providers Identification Market Place Service Platform

Service Subscription Market Place Service Platform

Service Offer Agreement (package of term & conditions + service offer selections)

Market Place Service Platform & DSO Platform

B2B Interactions

B2B Service Activation trigger (data options + list of PODs)

Service Platform Service Platform

Customer Consent Validation DSO Platform Service Platform

B2B Service Activation Contract (related to offer Agreement + data options + valid POD list)

DSO Platform Service Platform

Data calculation DSO Platform Service Platform

Data transmission DSO Platform Service Platform

Data collection DSO Platform Service Platform Table 13 - Process steps and related provider/consumer platforms

6 Standardization Guidelines In the current section, according to the TOGAF Architecture Framework, implementation and standardization guidelines are provided, including the interfaces content to be standardized.

6.1 Constraints

The target architecture must consider requirements described in the next section of this document during all project phases. Beside these requirements, and in order to reach the business goals defined earlier, the following technical constraints must be considered: Performance oriented constraints

- Market Place platform must be up and running in almost 24/7 basis (99.9 availability).



- All service requests must be processed and answered in real time (less than 5 seconds) by the target platform. For most of the services this constraint will be fulfilled.

However, there will be some innovative services to be demonstrated and also non instantaneous services to be delivered, for which such time constraints can be relaxed. For example:

The DSO localization service on the Market Place.

For some B2B data services (for e.g. aggregated consumption data), the DSO answer can be sent with some delay, known upfront (as stated in the related B2B agreement). This delay is due to data calculation processing constraints.

For some dedicated Service support (such as business case or network analysis study), which will need a duration time to be performed.

Technology oriented constraints

- Data formats and communication protocols must be defined in order to guarantee interoperability between actors.

- For B2B interactions, the technological choice must enable real time and delayed processing.

- Communication between stakeholders must be secure and encrypted. The security mode and encryption level will be defined in the next sections.

6.2 Interoperability and Standard adoption

Interoperability is provided by the implementation of standard interfaces in the MP and in the

platforms of the Market Place end-users. Each new Market Place end-user will be provided with

guidelines and services from the MP to implement these interfaces that cover standards for data

formats and communication protocols.

The interfaces are relevant for the following communication relations:

Communication internal to the MP

Communication between the market players and the MP

B2B communication between Market Place end-users

B2C communication between Market Place end-users (DSO or Service Platform) and final customers is out of scope (except for customer consent for data usage).

The main guideline for the use of standards in the relevant communication is the MADES guideline

from ENTSO-E, which is more and more relevant in the EU-energy sector. (The current version is

available on the ENTSO-E website : https://www.entsoe.eu)

For the development of standard data formats regarding the business content for the

communication with the MP and the B2B communication, the following existing industry standards

are taken into account as a starting and reference point. It means the project team will leverage

and reuse those standards, when applicable, for formatting each data exchange object listed in

D2.3 [D2.3]. If some data remains uncovered by the provided standards, the development team

will have to define those gaps, in collaboration with the project partners.

CIM: (Technical Committee TC57, esp. WG 16 on Standards related to energy market communications)

IEC 60870-5-104, IEC 61850, IEC WG6 (System Comity for Smart Energy)

https://www.entsoe.eu/



United Nation EDIFACT: http://www.unece.org/cefact/edifact/welcome.html (mainly subset used for the commercial communication in the energy sector of liberalized markets e.g. in the change of supplier process, master data exchange, meter data exchange)

OpenADR: http://www.openadr.org (esp. relevant for business information regarding distributed renewable energy resources)

OAuth2 standard (http://oauth.net/documentation) for managing authentication and customer consent (also inspired by US Green Button).

JSON architecture model for data formats. RFC 7159. The JavaScript Object Notation (JSON) Data Interchange Format, March 2014 (http://www.rfc-editor.org/info/rfc7159)

The following principle [IBM] will drive the implementation of the data exchange:

Name P2 - Exchanged information

Statement Partners may exchange information. Therefore, information shared between different partners depends on the security levels established for that particular set of information.

Rationale Necessary access to accurate information is essential.

Implications To enable information exchange, a common set of policies, procedures and standards must be developed and followed to regulate information management and both short-term and long-term access. Normalized data models and metadata that define such shared environments must be developed in addition to repository to store the metadata and make it accessible. The information-exchange principle is constantly confronted with the information security principle. Information exchange must not compromise the confidentiality of information under any circumstance.

Table 14 - Architecture principle for Exchanged Information

6.2.1 Interface for the Market Place System

The following table gives the list of the Business Objects exchanged with the Market Place System (refer to D2.3), the direction and the protocol support for these objects.

Data Set Business Objects Direction Protocol Support

Market Place and Market Players

MKP-DES - Market Place Description Market Place -> Market Player HTTPS

MPL-REG - Market Player Registration Both directions HTTPS

MPL-ADD - Market Player Location Market Player -> Market Place HTTPS

MPL-DES - Market Player Description Market Player -> Market Place HTTPS

MPL-AUT - Market Player Authentication Market Player -> Market Place HTTPS

Service Offer and Subscription

MKP-SRV-OFF – Market Place Service Offer Both directions HTTPS

MKP-SRV-SUB – Market Place Service Subscription B2B-SRV-SUB – B2B Service Subscription

Both directions HTTPS

MKP-SRV-DES – Market Place Service Description


Table 15 - Business Objects used in the Market Place interface

http://www.unece.org/cefact/edifact/welcome.html

http://www.openadr.org/

http://oauth.net/documentation)

https://www.rfc-editor.org/rfc/rfc7159.txt

http://www.rfc-editor.org/info/rfc7159



6.2.2 Interface for the B2B interactions

The following table gives the list of the Business Objects exchanged in the B2B interactions (refer to D2.3), the direction and the protocol support for these objects.

Data Set Business Objects Direction Protocol Support

Customer Consent

CUS-CON-ACK – Customer Consent Acknowledgement

DSO-> Market Player

OAuth 2.0

CUS-CON-REV – Customer Consent Revocation

DSO-> Market Player

OAuth 2.0

Service Activation

DSO-REQ – DSO Service Activation Request Market Player -> DSO

HTTPS

DSO-CNF – DSO Service Activation Acknowledgement

DSO-> Market Player

HTTPS

USP-REQ – Unregulated Service Activation Request

Market Player -> DSO

HTTPS

USP-CNF – Unregulated Service Activation Acknowledgement

DSO-> Market Player

HTTPS

IND-DAT-SEL - Individual Data Selection Both directions HTTPS

AGG-DAT-SEL - Aggregate Data Selection Both directions HTTPS

SRV-ACT-AGR – Service Activation Agreement


Service Provision

IND-DAT-VAL - Individual Data Value DSO-> Market Player

JSON format. Data sent by HTTPS or SFTP

IND-DAT-ACK - Individual Data Acknowledgement


HTTPS

AGG-DAT-VAL - Aggregate Data Value DSO-> Market Player

JSON format. Data sent HTTPS or SFTP

AGG-DAT-ACK - Aggregate Data Acknowledgement


HTTPS

TECH-FLEX-REQ – Technical Validation Request

DSO-> Market Player

HTTPS

TECH-FLEX-RESP - Technical Validation Response


HTTPS

Table 16 - Business Objects used in the B2B interface

6.3 Architecture Supporting the Process

The following diagram describes FLEXICIENCY building blocks and their interactions for metering data service delivery (http://cired.net/publications/cired2015/papers/CIRED2015_0631_final.pdf). The interactions between FLEXICIENCY components must be encrypted and secured by using SFTP, HTTPS and TLS. All internet connections are secured by applying international ISO security standards. This diagram also highlights the Web portal access provided to FLEXICIENCY Market players through SAP Hana cloud environment [Hana Cloud].

http://cired.net/publications/cired2015/papers/CIRED2015_0631_final.pdf



Figure 7 - Market Place implementation based on SAP Hana Cloud Platform

7 System Requirements Three main objectives needs to be fulfilled by the target architecture solution in order to address the different scenarios described in previous the section. We repeat here the business objectives as stated in table 3.

Name Description

Advanced Monitoring Enhance customer awareness and empower them to become a more active player

Local Energy Control Local energy optimization and modulation, together with value added services

Flexibility Participation Aggregate customers to enable new services to the market and the energy system

Table 3 - FLEXICIENCY Business Services towards End consumer

In order to reach these goals, the target architecture solution must respect at least the following technical requirements:

The communication between stakeholders should be standardized, open and secure.

Market Place internal services should handle business requirements of all Market Players. Example of internal services: Market Player registration, ESO subscription, etc.

We will use the SquaRE Quality Model (from ISO/IEC), as shown in the figure 8, to classify the requirements into standardized quality categories.



Figure 8 - SquaRE Quality Model

Furthermore to apply the ‘Reusability and simplicity’ principle (table 17, source IBM), the Market Place must be split up into 2 main and independent modules:

Regulated Module (where the service provider is a regulated actor, mainly for data metering provision) and

Unregulated Module (where the service provider is an unregulated actor, providing data,

tools and methodology services)

The project will respect the following architecture principle as stated below:

Name P4 - Component reusability and simplicity

Statement The enterprise architecture is built over low-coupling, reusable, modular components that implement services. Systems architecture must be as simple as possible to maintain yet meet all business and corporate requirements. Whenever complexity is required, it must be encapsulated to promote simplicity of solutions built on the architecture.

Rationale Reusable components represent opportunities to reduce IT development times and costs. Reusable components leverage investments in current systems. Modular components increase the systems' capacities to adapt to different evolution needs, because the change is isolated from affected modules.

Implications The architecture establishes standards and guidelines to develop system components. Table 17 - Architecture principle for Component reusability and simplicity

7.1 Requirements on the Market Place System

Title Description Quality category

EU Member A Market Player must belong to the European Community. Functional Suitability

Qualified Member

A Market Player must be qualified. It has to go through a light process to get qualified. It will be asked for a proof of company registration, and a purpose of playing in FLEXICIENCY such as having a direct or indirect role in delivering business energy services in :

Advanced monitoring,

Functional Suitability



Local Energy Control,

Flexibility Participation An example of a Form for registration is provided in the appendix of this document. Qualified DSOs and ESOs by existing energy market can be Market Players

Qualified Service Provider

A Market Place Service Provider is already a qualified market player who needs further qualification as a service provider (e.g. a DSO for data metering provision). It has to go through a strong process to get qualified, proving its ability to deliver services within the scope of direct or indirect role in delivering business energy services.


Market Player Representation

A Market Player may be represented by one single or several representatives.


Market Player Implementation

A Market Player Representative may be a system or a human person.


Market Place No Access

A B2C customer (end consumer) can not be a Market Player (should never have access to the Market Place).


Pushing adverts The Market Place offers an option for acceptance to receive pushing services.


Market Place modular implementation

The Market Place must be split up into 2 main and independent modules :

Regulated Module (where the service provider is a regulated actor, mainly for data metering provision) and

Unregulated Module (where the service provider is an unregulated actor, providing data, tools and methodology services)

Maintainability/Modularity

Unique Identification

The Market Place system must guarantee uniqueness for all exchanged identifiers.


Data Access Security

Data access must be regulated by authentication and authorization rules for both cloud or on premise installations. (to be listed)

Security

Transaction visibility

Transaction reporting/tracking are only be seen by the B2B actors involved in the agreement

Security

Communication documentation

Documentation for registration and interfacing with the Market Place and towards other IT service platforms (DSO and ESO) must be available on the Market Place.

Operability

Market Place update

Published information on the Market Place is up to date (e.g.: services, localization, Market Players, etc.) For instance : Daily Refreshment of data (by night for instance)


Identification of service providers

Market Place must with minimum of localization information, (for example area, town, street, POD filters) be able to identify the service providers (DSOs) to the service requester (ESO).


No POD information

Some service requester may provide PODs for DSO localization. However, the Market Place should never store any POD neither any information related to it, such as attached services.

Security

SLA respect The Market Place must respect the SLA requirements defined for each Demo. (example: response time)

Performance efficiency

Tracking, Recording and logs

The Market Place must provide services of: tracking, recording and logging requested by Market Players. Mainly all the interactions within the market place and at B2B level is traceable. The Market Player is involved to provide options, granularity of content and notifications when agreed on B2B side.

Operability



Audit and Reporting

The Market Place must provide services of: reporting/Audits/Statistics requested by Auditors such as Regulators or any qualified body.

Operability

Options of use

Options (such as recording/tracking, pushing adverts, etc.) are suggested by the Market Place, with an ease of use at some stages, such as: registration, service request. Some options may be applicable during the B2B agreement, such as regular notifications (to the Market Place) for the data delivery.

Operability

Data Encryption

Data must be transmitted in encrypted form. Preference to put Secured interactions (https) and respect of Hana cloud environment for Market Place messages. A protection will be set up against hacking : nobody could act as somebody else, etc.

• SAP HANA DB Services provides a very secure environment for your company's data. Each HANA-client (here DSO or Service Platform) is assigned to a VLAN. Multiple services under the same account are assigned to the same VLAN. Therefore, a HANA-client will need to know just one user id/password combination for the services under that account. Instructions for setting up the VPN access to your SAP HANA Infrastructure Services can be found in the Quick Start Guide.

• Data stored in SAP HANA is protected via regular SAP HANA security capabilities (authentication and authorization).

• Shipping of the HANA- data between the HANA-Client site and the SAP HANA DB Services is handled securely via encryption, if applicable. The HANA – client is responsible for encrypting and decrypting the data. Hence, only the HANA-client has access to un-encrypted data.

Security

Table 18 - Requirements on the Market Place System

7.2 Requirements on the Market Place interactions


Validated profile

The ESO has to access to the DSO data with a validated profile by the Market Place.

Operability

Systems Information

The data exchange implies that accessibility information (IP address, ports, ...) must be configured in advance


Included data scope

Data to be exchanged in the systems only includes: metering data (consumption and production data), weather, forecast, sensors readings, control data for smart devices, device consumptions


Excluded data scope

In the systems, it is excluded to exchange data on: living information or any other personal information on habits, data not relevant for energy




monitoring, local energy control or flexibility services

Data Format Standardized Format has to be used for exchanged data for B2B interactions, and interaction with Market Place

Operability

Precise Data Typing

Data types have to be precisely defined. Example: date in GMT format with time zone, amount in euros, POD structure per DSO…


Date time format

All date time must follow the format: DD/MM/YYYY hh:mm:ss CET Functional Suitability

General conditions Contract

A High level (1 layer) of B2B contract (Agreement) has to be established before any Service Request. Include general conditions addressed to every qualified Market Player to a service.


Specific Service Contract

A second layer (more specific) service agreement has to be defined on more precise way, regarding the description of the B2B service and the way to deliver the service (documentation, data detail, technical interaction, SLA, aggregation, portfolio description …). Signing the generic contract (AGR-HLV) is a prerequisite for the Specific contract (AGR-SPC).


Service Activation

Service Activation is done on B2B side. The Market Place should never deal with any service activation.


Table 19 - Requirements on the Market Place interactions

7.3 Requirements on the B2B interactions


Commands propagation

The commands must be propagated to the service requester in maximum 5 seconds from their generation on the DSO / ESO platforms


Anonymous identifier

The ESO request data to the DSO with the POD as a customer identifier instead of the real name.

Security

Validated customer consent

The ESO will access to individual consumption/generation data always with customer consent.

Security

Data Format Standardized Format has to be used for exchanged data for B2B interactions, and interaction with Market Place

Operability

B2B data exchange

Prior to any B2B exchange, actors have established technical communication for exchange.


Data Definition Data have to be defined into details between the B2B actors Functional Suitability

Contract Activation

After Service Offer agreement (done on the Market Place), the last activation service is done on B2B interaction. The service requester will have to provide the list of PODs to the Service Provider, with validated customer consent, when mandatory.


Table 20 - Requirements on the B2B interactions



8 Conclusions This work was about setting up project and system conditions for electricity metering data provision among different EU actors. It started by collecting different point of view and expertise, looking at each interest of different partners in their businesses, their concerns and their motivation in innovating through FLEXICIENCY. The needed requirements from the delivered system have been gathered to achieve the main targeted business objectives. The architecture vision has been structured into 5 simple sets:

1. Stakeholders Collaboration, 2. Data privacy and Security, 3. Transparency, 4. Interoperability and Standardization, 5. Flexible and Modular Solution.

Guidelines, roles & responsibilities have been provided towards the stakeholders (hence towards their IT Platforms) to support and contribute to the success of the project as a whole. Common areas to be shared between the subsystems have been defined, allowing a standardization of services and data exchanges. During implementation (in the next WP4 tasks), this standardization process must carry on, using these guidelines and further deeper description. Content of messages will be more developed to support the interactions between the main users of FLEXICIENCY either from Regulated or Unregulated side of Energy Market.



9 References

9.1 Project Documents

FLEXICIENCY/ D2.1 : Definition of services and use cases description

FLEXICIENCY/ D2.3 : Data model and interfaces

FLEXICIENCY/D11.3: Exploitation plan

FLEXICIENCY paper http://cired.net/publications/cired2015/papers/CIRED2015_0631_final.pdf

9.2 External Documents

Togaf ® Architecture

IEC Standardization

CIM Standardization

Green Button

ENTSOE / MADES

ENTSOE/Glossary

SGCG : Smart Grid Coordination Group

[IBM] http://www.ibm.com/developerworks/rational/library/enterprise-architecture-financial-sector

SAP Hana Cloud

http://www.ibm.com/developerworks/rational/library/enterprise-architecture-financial-sector

http://www.ibm.com/developerworks/rational/library/enterprise-architecture-financial-sector



10 APPENDIX

10.1 System Use Cases List

Code Title

WP2_1 New Market Player enroll in the market place

WP2_2 Market participant manage its services & Market participant “pass” a MP certification

WP2_3 Market player enrolls to a new service

WP2_4 Service activation

WP2_5 Service Requester requests the service stop

WP2_6 Service Requester requests the service cancellation

WP2_7 Identification of MP service providers based on localization input

WP2_8 Service Provider requests statistics regarding service execution

WP2_9 Manage ancillaries services

WP2_10 Collect customer consent for transmission

WP2_11 Revoke customer consent for transmission

WP2_12 Technical Set-up and Validation

WP2_13 Market player service requester quits a subscribed service

WP5_1 To provide consumers with metering data

WP5_3 Optimization of the demand/grid

WP5_4 To provide custom feedback

WP5_5 To provide consumers with notifications

WP5_6 Manage Loads to reduce energy consumption keeping predefined comfort level

WP6_1 Provision of individual data consumption

WP6_2 Provide consumption load curves aggregated on a defined scope

WP6_3 Provide Demand Response Potential based on aggregated load curves

WP7_1 Provide the customers with advanced information for awareness purpose retrieved from DSO and Service Provider field components

WP7_2 Provide the users with basic information for awareness purpose retrieved from the DSO components

WP7_3 Provide customers with alarms and notifications retrieved from DSO and Service Provider field components

WP7_4 Provide the final users with alarms and notifications based on the information retrieved from the DSO components

WP7_5 Allow Customer to manage loads to reduce/shifts the energy consumption

WP7_6 Measurement and verification of energy savings

WP7_7 Manage PV+Storage system maximizing its profitability

WP7_8 Control of electrical vehicle charge operation according to client preferences

WP7_9 Optimal LV distribution network operation supported by flexibility services

WP8_1 Alert me if something is wrong - real time

WP8_2 Alert me if something is wrong - next day



WP8_3 Energy efficiency advice - realtime

WP8_4 Energy efficiency advice

WP8_5 Home control

WP9_1 Publish Flexibility platform SaaS offer

WP9_2 Provision of Flexibility offers on Market place

WP9_3 Provide customers with consumption data merged from ESCo, DSO, and PV System Operator sources

WP10_1 Business case valuation and optimization based on meter data Table 21 - List of System Use Cases



10.2 Registration Form in the Market Place

Stakeholder/Actor Basic Information: EU Country (Headquarter): Type of your organization: Energy REGULATED Player : DSO TSO Metering Data Manager Other : Energy UNREGULATED Player: Retailer ESCO Aggregator Other : Industrial Player: Energy Device Manufacturer Technology provider Other : Research Institute: University Other PUBLIC Body: EU Energy Regulator Local Authorities Energy Association (EDSO, ENTSOE, ACER) Other : Company Registration certificate (SIRET N° in France, …) : Optional (any information which facilitates the qualification): Registration Proof in any EU Energy Market or Data Exchange Platform (TSO, Power Exchange, …) : if any please provide documents, …

Aims/Role for registration Auditor (Check, audit, feedback analysis, reporting ) Unregulated Service Requester (Please provide your purposes)

Advanced Monitoring Local Energy Control

Flexibility Regulated Data Service Provider (Please provide the service types)

Individual Metering data Aggregated data Data analytics

Other: Regulated Support Service Provider (Please provide the service types)

Technical validation for DR Other:

Unregulated Service Provider (Please provide the service types) Data records (sensors, PV, weather, …) Tools

Other:

Options Agree to receive pushing advertisement Agree the record of the following information

Service negotiations steps …

IT Platform Automated: please provide end points information (for Set up and validation of interfaces,

connection) : …

Human Web access

Table 22 - Registration Form for new Market Player



10.3 Service description Form in the Market Place

The FLEXICIENCY project team had a workshop on Market Place B2B services. This following form (provided by SAP and UL) allowed the collection of service descriptions from different partners. This was a useful input for the work done in this document.

1. Organizations involved

WP/Demo:

Organizations: Contact persons (e-mail):

Is it “As is” or “To be” template description? : As Is To Be

*List the organizations and corresponding contact persons involved in your Demo WP.

2. Services Please describe all services registered on Flexiciency Market Place (services that will be exchanged between market participant and not service description with final customer). Please copy this table for each service used in your Demo.

Service description

Countries of service execution: Name of the service: Organization responsible for the service: Type of your organization which provides the service: DSO Retailer ESCO Other: Type of organizations which will consume your service: DSO Retailer ESCO

Other: Person(s) responsible for the service and email(s): Service keywords: Short service description (to explain to a dummy what are you providing; this is the service “packaging”) :

Service lifecycle stage: Planned In Development Released

*Indicate the lifecycle stage of the services.

Service version: *In case that your service already exists, please provide the current service version, for example: 1.1. or v1.1

Service category: Data services

Individual data aggregated data

Control services Individual

Privacy: Publicly available service Private availability

*Please indicate whether the service will published privately or publicly.



aggregated

Other: *Note: What is the category for your service? This is proposed initial categorization, please add other service categories or subcategories to fit your services.

Payment model: Service which is free to use Paid service

*Please what is the payment model for your service?

Description of Service delivery: - - - *Please provide a more detailed description of the service purpose, goals and functionality.

Pre-conditions for service invocation: Valid consent from the end-customer Service is available at specific location

identified by a specific ID: POD Postal code Other:

Other: *What are the pre-conditions that must be fulfilled, before the communication can be performed?

Device used to collect the data - - - *Please provide what devices are used to collect the data. For example: smart meter, gateway, energy box, etc. Data (to be) exposed / delivered: - storable data - data subscription - - *What data are you exposing with this service? Provide more detailed information in lines. If no data is exposed, you can leave the field empty.

Service invocation pattern: On demand (triggered by application or

user) Event driven

event description: Push-style

push event description: Periodically

period:

Other: *Please indicate the invocation pattern.

Standard used for data format / model:

Specified by the protocol Green Button Data Other: Not available

*Please provide the data format for the data exchanged. In case no data is exchanged, you can select “Not available”. If data format defined as a part of the protocol used, than select “Specified by the protocol”.

Protocol and service type between the client (for example Retailer) and service (for example DSO):

RESTful web services, Based on a protocol:

CIM IEC 60870-5-104 OpenADR 2.0 Other: *If your service is based on certain protocol, then check, what type of web service is this protocol based on. Please also indicate the standard used for the communication. Structure of the formats

Operations/functions/actions (to be) exposed/delivered: - -

Documentation: Documentation is available

URLs:



- - *What are the operations/functions of the service? In case, your services are not data-oriented, but rather control of functionality, than this list will be different from the one provided earlier under “Data to be exposed”.

*If you already have some documentation for your service available, please provide the URL links to the documentation.

System level security between the client and service

None Data transport (signing) Data transport (encryption) Access control Other:

*Please define the system level security between the client (for example Retailer) and the service (for example DSO).

Service endpoint: *What is the address (URL) where your service can be invoked?

Service evaluation (SLA) requirement for feedback:

This service evaluation should be preformed Share the evaluation results with the community *Indicate, if evaluation of the services should be performed and if the results should be reported to the community.

Describe the service SLA: - - - - *Describe the attributes of the Service Level Agreements that will be proposed and that can be used for evaluation. For example: The specify for each data exposed what is the frequency, the frequency of data delivery (monthly, daily), volume of data etc.

Other notes: Table 23 – Service Description Form



10.4 Actors List as stated in the SUCs

Different actors and roles have been used in the SUCs to describe the Demos that will be carried out in the project. Actors used in FLEXICIENCY System Use Cases which interact with either Market Place or B2B are described in the following list. Each role and a source for its definition are provided, when covered by a standardized glossary such as ENTSOE, SGCG, etc.

Actor name

Actor description

Roles Played in FLEXICIENCY Platforms (MP, DSO, ESO)

Sources

THE MARKET PLACE AREA

Market place

the Market Place is a contact point for business deals between stakeholders of the electricity retail markets

source DoA of FLEXICIENCY

Market Place Platform

IT platform including Market Place functionalities

FLEXICIENCY SUCs

Market Place Operator

Operator of the Market Place FLEXICIENCY SUCs

Market player A user representing a company who register / access to the market place, like an Organization who is qualified and certified to play on Electricity Market (e.g. Retailer, DSO, TSO, ESO).

The market player can play as a service requester or a service provider role in the Market Place.

FLEXICIENCY SUCs

MP Service provider

Provide services through the Market Place

FLEXICIENCY SUCs

MP Service requester

Consume services through the Market Place

FLEXICIENCY SUCs

Business Administrator

An employee working for the company that owns the market place

FLEXICIENCY SUCs

Business information receiver

Actor / entity who will be in charge to decide to enroll or not a new market player following the market place scope

FLEXICIENCY SUCs

THE REGULATED B2B AREA

DSO Acronym for Distribution System Operator. According to the Article 2.6 of the Directive: "a natural or legal person responsible for operating, ensuring the maintenance of and, if necessary, developing the distribution system in a given area and, where applicable, its interconnections with other systems and for ensuring the long-term ability of the system to meet reasonable demands for the

ENERGY REGULATED PLAYERS Data Custodian. Metering Data Manager. Business Data Service Provider.

Sources : SGCG/EG3



distribution of electricity". Moreover, the DSO is responsible for regional grid access and grid stability, integration of renewables at the distribution level and regional load balancing.

DSO Platform It is about the DSO system supporting metering infrastructure and other systems necessary to the DSO to manage load curves. IT platform of DSO to manage own data and interact with Market Place and B2B Service Provider. DSO Platform archives online consumption data making it available for third parties, makes elaboration on these data

IT Support for metering Data Management of the DSO

FLEXICIENCY SUCs

Metering Data Manager

The Metering Data Manager is a Macro-Role, including: Metered Data Aggregator A party responsible for the establishment and qualification of metered data from the Metered Data Responsible. This data is aggregated according to a defined set of market rules. Metered Data Responsible A party responsible for the establishment and validation of metered data based on the collected data received from the Metering System Operator. The party is responsible for the history of metered data for a Metering Point. Metering Point Administrator A party responsible for registering the parties linked to the metering points in a Metering Grid Area. It is also responsible for maintaining the Metering Point technical specifications. It is responsible for creating and terminating metering points. Other Metered Data User Relationship Manager Respond to regulatory changes and expand the range of Smart-related services offered to actors of the Electric Power System (not

Generic role as for the DSO in FLEXICIENCY

[Source : ENTSO-E role model]



Grid Users/ Suppliers/BRPs). The possibility to provide regulated services based on data management and provision in order to facilitate national en local public policies and enable customer empowerment.

Metered Data User

Metered Data User that is authorized to acquire Energy Usage Information from the Metering Data Manager

Generic role as for the ESO in FLEXICIENCY

THE UNREGULATED B2B AREA

ESO or ESP or ESCo

Acronym for Energy Service Operator (or Provider) Organization offering energy services to the consumer. Acronym for Energy Saving/Service Company The Energy Service Company delivers Energy related services to end customers. An ESCO is a natural or legal person that delivers energy services and/or other energy efficiency improvement measures in the user's facility or premises, and accepts some degree of financial risk in doing so. The payment for the services delivered is based (either wholly or in part) on the achievement of energy savings or energy efficiency improvements (also for renewable energy projects) and of other agreed performance criteria.

ENERGY UNREGULATED PLAYERS Business Service Data Requester B2C energy service Provider

Source : SGCG/SMCG

Service Platform (ESCo Service Platform, or ESO Platform)

IT platform of ESCo to deliver the B2C Service to the customer and to interact with Market Place and B2B Service Provider. In some cases, it archives online consumption data taken from DSO Platform and other data coming from consumer premises (e.g. sensors/actuators), makes elaboration on these data.

IT Support in B2B Interaction for data collection

FLEXICIENCY SUCs

Flexibility service provider

Flexibility service provider is market player such as Retailer who manages Flexibility platform, aggregates flexibilities, and provides flexibility offers on the market place underlying flexibility products as for offer acceptance.

UNREGULATED B2B service provider Tools Support services

FLEXICIENCY SUCs

Flexibility

Flexibility platform provider owns Flexibility platform software,

Registers Flexibility

FLEXICIENCY SUCs



platform provider

establishes interfaces with Market place and DSO and SP Platform and Deploys Flexibility platform SaaS environment as for request for other Market actors (Retailers). IT platform deployed as SaaS for market players (Retailers) to provide aggregation services and interact with Market place.

platform SaaS interacting with Market place and on B2B

PV System Operator

Operator of PV Inverter Systems with data connection;

UNREGULATED B2B service provider as an INDUSTRIAL PLAYER Business Data Service Provider

FLEXICIENCY SUCs

PV System Operator Platform

IT Platform of PV System Operator

IT Platform interacting with Market place and on B2B

FLEXICIENCY SUCs

Supplier

Entity that offers contracts for supply of energy to a consumer (the supply contract). Within this role it will initiate DSM activities NOTE: In some countries referred to as Retailer

As an ESO Source : ENTSOE Role model

Retailer (=Supplier)

Entity selling electrical energy to consumers - could also be a grid user who has a grid connection and access contract with the TSO or DSO. In addition, multiple combinations of different grid user groups (e.g. those grid users that do both consume and produce electricity) exist. In the remainder of this document, the terms customer/consumer and grid user are used interchangeably where appropriate. Retail energy sales company: a natural or legal person that sells energy to final customers.

As an ESO Source (SGCG/ EG3) Source Directive 2006/32/EC

Aggregator Aggregator means a legal entity which is responsible for the operation of a number of Demand Facilities by means of Demand Aggregation.

Offers services to aggregate energy production from different sources (generators) and acts towards the grid as one entity, including local aggregation of

As an ESO source (ENTSOE/ NC

DCC, SGCG) Source (SGCG/EG 3)



demand (Demand Response management) and supply (generation management). In cases where the aggregator is not a supplier, it maintains a contract with the supplier.

THE B2C AREA

Consumer (called also Customer)

End user of electricity, gas, water or heat. NOTE: As the consumer can also generate energy using a Distributed Energy Resource, it is sometimes called the "Prosumer". A party that consumes electricity.

This actor has indirect role by providing its data custodian the consent for a third party to use its data for a given service

Source SGCG Source ENTSOE /Harmonized Role Model)

Prosumer A Consumer who also generates energy using a Distributed Energy Resource.

Table 24 - Actors used in FLEXICIENCY System Use Cases



10.5 DSO List in EU

This list has been gathered by FLEXICIENCY partners to share how DSOs can be identified, either geographically or through customer bill.

Country Major DSO if any Number in total

Please provide how to identify the DSO, via the electricity bill

France ERDF About 130 DSO in total

22 426 049 078 938 NO autonomous DSO coding Use the address and extract the INSEE code (from the Post Code), which has a direct link to a DSO (1 INSEE code is related to 1 DSO) The Web site of ADEEF (Association des Distributeurs d’électricité de France) provides the related DSO to each postcode http://listegrd.adeef.fr (annuairegrd_cartographie) Use the department mapping (95 in France Metropole) The Web site of ADEEF (Association des Distributeurs d’électricité de France) provides the related sublist of INSEE code (municipalities) and the related DSO to each postcode. We can also use the listing function of ELD (Entreprises Local de Distribution), which provides the list of all DSOs and filtering them par department for instance http://www.repertoire-eld.com/accueil.asp

Italy

Enel Distribuzione About 150 DSO

IT001E151624936 The three numbers after “IT” identify the relevant DSO, according to http://download.terna.it/terna/0000/0383/68.pdf Use the address and extract the Post Code (CAP), which has a direct link to a DSO (1 CAP code is related to 1 DSO)

Austria

No major DSO About 160 DSO in total

AT.008100.08010.0O6G56M11SN51G21M24S The complete POD consists of 33 alphanumeric digits. First 2: Country, always AT Next 6 (numeric): DSO Identification (“Verteilnetzbetreibernummer”) Next 5 (numeric): ZIP-Code (“Postleitzahl”) Next 20 (alphanumeric): core POD number (“Zählpunktnummer”). A list with DSO identification is attached and available on the web: http://www.apcs.at/apcs/marktteilnehmer/netzbetreiber_letztstand.xls Here is a screenshot of the POD description in the technical annexes to the electricity market rules (Technical and Organisational Rules for system operators and users (TOR), part F): http://www.e-control.at/documents/20903/-/-/7fc39f90-3a45-4aab-bb2b-9e7ce0058ad0

http://listegrd.adeef.fr/

http://www.repertoire-eld.com/accueil.asp

http://download.terna.it/terna/0000/0383/68.pdf

http://www.apcs.at/apcs/marktteilnehmer/netzbetreiber_letztstand.xls

http://www.e-control.at/documents/20903/-/-/7fc39f90-3a45-4aab-bb2b-9e7ce0058ad0

http://www.e-control.at/documents/20903/-/-/7fc39f90-3a45-4aab-bb2b-9e7ce0058ad0



The structure of the POD is described above. It should by definition contain the ZIP-Code, but in reality it is omitted in many cases. Example:

Here the DSO is “Wiener Stromnetz” but the ZIP-Code part of the POD is filled with blanks. Customer may recognize the right information (Zip Code): AT.001000.01160.00000001000009191688 For many customers, especially in the larger cities, it is easy to identify the DSO (mostly associated to the local Stadtwerke), but many smaller DSO exist all over the country. Even in the same street neighbors might end up with different network operators in some cities or villages. There is no public available register or any means to determine the DSO based on the address. Reverse-engineered databases exist, but are not freely available. A company Selectra SARL is running a service where you can select the DSO, but it seems not to be complete … http://stromliste.at/verzeichnis

Spain

Endesa Distribución About 333 DSO in total

ES 0031 103686223001VV0F LL DDDD CCCCCCCCCCCCEENT LL corresponds with the country (normative-UNE-EN ISO 3166-1) ->ES - Spain DDDD corresponds with the DSO name published by REE ->Endesa-0031

DDDD

CCCC CCCC CCCC region identifier EE specific user identifiers NT specific user identifiers

Slovenia (UL)

5 DSOs:

2-812345 X-ABCDEF , X corresponds to the DSO: 2-Elektro Celje d.d. 3- Elektro Ljubljana d.d 4-Elektro Maribor d.d. 6-Elektro Gorenjska d.d. 7-Elektro Primorska d.d.

http://stromliste.at/verzeichnis



ABCDEF: Is just a unique 6 digit number for every measuring point.

Sweden Vattenfall

Eldistribution AB About 160 DSOs

1) Country and industry, (utilities in Sweden) 2) DSO company 3) Consecutive number 4) Control number

Table 25 - DSO Mapping in some EU countries



10.6 Standard References

10.6.1 TOGAF Methodology

We applied the TOGAF standard framework [TOGAF] for system architecture. This document includes the 3 first parts:

TOGAF - A: Architecture Vision.

TOGAF - B: Business Architecture.

TOGAF - C: Information System Architecture. The main middle part is about requirements.

Figure 9 - TOGAF Methodology

10.6.2 IEC – CIM

The IEC – CIM (Common Information Model) is a set of standards to enable System integration and Information exchange based on UML (Unified Modeling Language). It aims to cover the whole value chain of the electric power Sector.

CIM: (Technical Committee TC57, esp. WG 16 on Standards related to energy market communications). The CIM standards are continuously evolving to meet the changing requirements for data exchange, which are increasing in both frequency and type, with higher RES integration and the introduction of smart grids. Specific ENTSO-E CIM standards have been defined to ensure the suitability of the CIM for ENTSO-E and to reflect the complexity of TSO data exchanges)



The IEC 61968 series of standards extend the CIM to meet the needs of electrical distribution, where related applications include distribution management system, outage management system, planning, metering, work management, geographic information system, asset management, customer information systems and enterprise resource planning.

The TC 57 is also a standard to be reused by FLEXICIENCY project https://webstore.iec.ch/searchform&ComNumber=57.

10.6.3 MADES

As the guideline reports “MADES is a specification for a decentralized common communication

platform based on international IT protocol standards:

From a business application (BA) perspective, MADES specifies software interfaces to

exchange electronic documents with other BAs. Such interfaces mainly provide means to

send and receive documents using a so-called “MADES network”. Every step of the

delivery process is acknowledged, and the sender can request about the delivery status of

a document. This is done through acknowledgement, which are messages returned back to

the sender. This makes MADES networks usable for exchanging documents in business

processes requiring reliable delivery.

MADES also specifies all services for the business application (BA); the complexities of

recipient localisation, recipient connection status, message routing and security are hidden

from the connecting BA. MADES services include directory, authentication, encryption,

signing, message tracking, message logging and short-term message storage.

The purpose of MADES is to create a data exchange standard comprised of standard protocols

and utilizing IT best practices to create a mechanism for exchanging data over any TCP/IP

communication network, in order to facilitate business to business information exchanges as

described in IEC 62325-351 and the IEC 62325-451 series.”

10.6.4 Green Button / OAuth2

The OAuth2 standard (http://oauth.net/documentation) is one of selected protocols for managing authentication and customer consent (to collect and to use data). This standard represents a good fit to our project cases. It includes basic authentication/authorization procedures, but it also includes procedures that allow the customer to grant access to its data by an external application and to manage the provided grants.

An example scenario is the case in which a DSO has to provide a customer’s metering data to a Retailer that is willing to use these data to offer to the customer energy efficiency services. In this scenario the customer must authorize the DSO to transfer the data from its platform to the Retailer’s platform. This authorization is covered by the Oauth2 specification.

The implementation of this authentication procedure is inspired by the Green Button Initiative

(http://www.greenbuttondata.org/). “Green Button uses the NAESB Energy Services Provider

Interface (ESPI) standard (REQ.21) to create a standardized process and interface for the

exchange of a retail customer’s energy usage information between their designated data custodian

(i.e. distribution company) and an authorized third party service provider. Providing a consistent

method for the authorization of third party access to retail consumer’s usage information and a

standardized interface for the exchange of the that information. The NAESB ESPI standard

provides model business practices, use cases, models and an XML schema that describe the

mechanisms by which the orchestrated exchange of energy usage information may be enabled.

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

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

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

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

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

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

https://webstore.iec.ch/searchform&ComNumber=57

http://oauth.net/documentation)

http://www.greenbuttondata.org/



The NAESB standards development effort was conducted with the support of the National Institute

of Standards & Technology and the Smart Grid Interoperability Panel and serves as an extension

of the NAESB Energy Usage Information Model developed at the request of NIST and the SGIP”1

10.6.5 Modsarus Modelling

The FLEXICIENCY project team had a workshop on practicing Modsarus® tool (supporting Model Driven Development from Smart Grid Standard [email protected]). We used some modeling modules to better share a common understanding and the high level structure of the project. The schemes below illustrate the system use cases mapping per demo.

Figure 10 - An overview of business objectives (in green boxes), and their interactions with Business Use Cases

1

http://en.openei.org/wiki/Green_Button_Developer#Energy_Services_Provider_Interface_.28ESPI.29

mailto:[email protected]



Figure 11 - An example of interaction between Business Use Case and System Use Cases.



10.7 Examples of Architecture Principles

The purpose of this section is to describe the principles that can be used in order to define the target architecture. These principles are extracted from http://www.ibm.com/developerworks/rational/library/enterprise-architecture-financial-sector

Name P1 - Compliance with standards and policies

Statement Corporate information management processes must comply with all applicable policies and regulations

Rationale The information management corporate policy must comply with internal policies and regulations.

Implications The company must ensure compliance with all policies and regulations regarding data conveyance, retention, and management. Efficiency, need, and common sense are not the only incentives. Changes in standards and regulations might lead to changes in processes or application.

Name P2 - Exchanged information

Statement Partners may exchange information. Therefore, information shared between different partners depends on the security levels established for that particular set of information.

Rationale Necessary access to accurate information is essential.

Implications To enable information exchange, a common set of policies, procedures and standards must be developed and followed to regulate information management and both short-term and long-term access. Normalized data models and metadata that define such shared environments must be developed in addition to repository to store the metadata and make it accessible. The information-exchange principle is constantly confronted with the information security principle. Information exchange must not compromise the confidentiality of information under any circumstance.

Name P3 - Information security

Statement Information is protected based on integrity, availability, confidentiality, incontestability, and authenticity. Every piece of information is submitted to a security assessment based on those five factors.

Rationale Open information exchange and disclosure must be balanced with the need to restrict the availability of confidential, proprietary, and sensitive information. Current regulations require data.

Implications The security restrictions must be identified and implemented at the data level, not at the application level. Security must be planned in data elements from the beginning, rather than added later. Systems, data, and technologies must be protected against unauthorized access and handling. The source of information must be protected against unauthorized or accidental modifications, fraud, catastrophes, or disclosure.

Name P4 - Component reusability and simplicity



Statement The enterprise architecture is built over low-coupling, reusable, modular components that implement services. Systems architecture must be as simple as possible to maintain yet meet all business and corporate requirements. Whenever complexity is required, it must be encapsulated to promote simplicity of solutions built on the architecture.

Rationale Reusable components represent opportunities to reduce IT development times and costs. Reusable components leverage investments in current systems. Modular components increase the systems' capacities to adapt to different evolution needs, because the change is isolated from affected modules.

Implications The architecture establishes standards and guidelines to develop system components.

Name P5 - Adaptability and flexibility

Statement Adaptability and flexibility reduce the complexity and promote integration, which improves the business activities. Excessive customization increases costs and reduces the ability to adapt.

Rationale Adhering to this principle has several benefits: - Allows the infrastructure to support changes that frequently occur in business

processes within the company. - Renders the infrastructure more adaptable to IT changes and IT market

strengths. - Allows the improvement of business processes. - Promotes a simpler and faster system integration process, with less revision

processes - Allows systems to evolve to meet business needs and changes

The goal is to avoid dependency failures that can result from highly coupled applications.

Implications Adaptability and flexibility performance metrics must be established. The development of applications based on components must be promoted and facilitated. A minimum number of suppliers, products, and configurations must be maintained to allow maximum flexibility when implementing changes. Excessively complex configurations of components, undue customized tuning, and hardware and software customization based on transient, local, or other conditions must all be avoided.

Name P6 - Low-coupling interfaces

Statement Interfaces have low coupling and are self--described

Rationale Low-coupling interfaces are preferable, because when interfaces between independent applications are highly coupled, they are less generic and more susceptible to causing unwanted, secondary effects when they are changed.

Implications Low coupling means that the services (APIs, for example) are conceived with no affinity to a certain service consumer. Therefore, the service is completely uncoupled to a service consumer. However, the service consumer is dependent of the service (that is, contains references for service interfaces). The service is also responsible for exception treatment. The result is a low-coupling architecture.



Name P7 - Adherence to functional domains

Statement The business rules and functionality of a system are consistent with the mission of that system. There is complete adherence to the functional domain in which the system is located.

Rationale The purpose of this principle is to avoid functional redundancy between systems. Functional redundancy can cause loss of data integrity and increase maintenance costs related to the redundant business rule.

Implications Systems must be located in proper functional domains, with explicit definition of the manager in charge of the functional domain. Each new functionality request must be submitted to the respective manager.

Name P8 - Interoperability

Statement Software and hardware must follow established standards that promote data, application, and technology interoperability.

Rationale Standards help ensure coherence, thus improving the ability to manage systems, raise user satisfaction, and protect current IT investments, thus maximizing return on investment and reducing costs.

Implications Interoperability and industry standards must be followed unless there is a mandatory business reason to implement a non-standard solution.

____________________________