uc planning, district architecture requirements and tested ... · v1.0 30-09-2017 final enexis team...

UC planning, District architecture requirements and tested innovations

Version 1.0

Deliverable D7.1 & D7.2

31/10/2017

Ref. Ares(2017)5334424 - 31/10/2017

https://extranet.enexis.nl/sites/H2020/Gedeelde%20%20documenten/H2020%20documenten/Deliverables/D7.1%20%20D7.2_District%20architecture%20requirements%20and%20tested%20innovations.docx


D7.1 & D7.2

InterFlex – GA n°731289 of 66

ID & Title : D7.1 D7.2_District architecture requirements and tested innovations

Version : V1.0 Number of pages :

69

Short Description

In the deliverable D7.1 D7.2 the system architecture for InterFlex in the Netherlands is described to meet the requirements stated in the three use cases. The grid architecture of the demo site in Strijp-S is explained in relation to these use cases. Furthermore, a detailed description of the actors, roles and functions of the different components is included.

Revision history

Version Date Modifications’ nature Author

V1.0 30-09-2017 Final Enexis Team

Accessibility

☒Public ☐ Consortium + EC ☐ Restricted to a specific group + EC

☐ Confidential + EC

Owner/Main responsible

Name(s) Function Company Visa

Marcel Willems Project leader Enexis

Author(s)/contributor(s): company name(s)

Rik Fonteijn: Enexis Patrick Rademakers: Elaad Daphne Geelen: Enexis Bob Ran: TNO Paul Klapwijk: Enexis Olga Westerlaken: Enexis Joost Laarakkers: TNO Marcel Willems: Enexis

Reviewer(s): company name(s)

Ingmar Leisse : E.ON Alexander Krüger: E.ON Luis Hernández: E.ON

Approver(s): company name(s)

Company Name(s)

Enedis C Dumbs

Work Package ID WP 07 Task ID T1 & T2


D7.1 & D7.2


EXECUTIVE SUMMARY.

This report describes the district architecture requirements tested innovation and use case planning for the Interflex project in the Netherlands, Eindhoven Strijp-S area. The partners for the Interflex project organisation in the Netherlands are Enexis, TNO and Elaad. Enexis is the second largest Dutch DSO, TNO is Dutch research and development organisation and Elaad is a knowledge centre on smart mobility. The Strijp-S area in Eindhoven is one of the focus areas within the city for design & technology innovations it the region. The goals for demonstration is the research how a DSO can use flexibility to have a cost effective grid infrastructure. To do this the following set of project goals is formed:

Use flexibility for grid management purposes

Scalable solution & architecture

Design and implement functional & business layer: flexibility trading

Implement open market architecture for flexibility

Determine merit order for flexibility

To achieve these goals a model is designed to describe the systems and mechanisms on

operational, enterprise and market levels, which enable the provision of ancillary services

to the distribution grid via a flexibility market.

With this model we want to test:

Technical innovations on ICT systems and communication,

Organizational innovations on market mechanisms, contractual agreements and

business models.

To measure this we use a set of KPIs on:

Availability % of time during which the storage is available (NL 1 & 2, NL: >90%

(battery-based storage)

Efficiency Battery-based storage efficiency (NL 1, NL: 85% SSU)

Impact on the grid % of shifted energy; Contribution to load shedding; Contribution

to ancillary services, NL 1 & 2, NL: 10%

Potential to shift demand share of energy/power displaced for each type of

flexibility, NL 2, NL: 5% (in overall grid)

Local peak load reduction % of decrease on ratio P-peak / P-average at MV feeder

level (third level area) NL 1 & 2, NL: 20%

Available power flexibility

The system architecture is based on systems that are connected with a set of open interfaces and protocols. These systems will facilitate the different roles and functions that are described for the open flex market. The systems are developed or adapted with different market parties who see the deployment as a business opportunity. In the model different roles and functions are described in relation with the flexibility market model.

D7.1 & D7.2


These roles are:

Distribution System Operator (DSO)

Commercial Aggregator (CA)

Local Aggregator (LA)

Charge Point Operator (CPO)

DER owner

Functions:

Grid Management System (GMS)

Flexibility Aggregation Platform (FAP)

Local Infrastructure Management System (LIMS)

Charge Point Management System (CPMS)

As stated in the grant agreement three use cases are the starting points for the project in the Netherlands. These use cases planning are described in detail in this report. The use cases are:

Enabling ancillary services, congestion management, voltage support for PV

integration using centralized, grid-connected storage systems to improve grid

observability of prosumers, promoting batteries in multi-service approach.

Enabling the optimal activation of all available local flexibilities offered by the locally

installed EVSE’s for congestion management.

Validating technically, economically and contractually the usability of an integrated

flex market based on a combination of static battery storage and EV chargers.

The district architecture is defined using SGAM methodology on 5 layers (component, communication, information, function and business). The grid architecture of the Strijp-S area is drawn on LV feeder level.

D7.1 & D7.2


TABLE OF CONTENT

EXECUTIVE SUMMARY. ................................................................................... 3

TABLE OF CONTENT ..................................................................................... 5

LIST OF FIGURES ......................................................................................... 7

NOTATIONS, ABBREVIATIONS AND ACRONYMS ....................................................... 8

1. INTRODUCTION .................................................................................. 10

2. PROJECT CONTEXT & GOALS .................................................................. 12

2.1. The Dutch InterFlex Demonstration ...................................................... 12

2.2. Goals of the demonstration ................................................................ 12

2.3. Tested innovations .......................................................................... 13

2.4. KPIs ............................................................................................ 14

2.5. Demonstration location .................................................................... 15

3. SYSTEM ARCHITECTURE ........................................................................ 17

3.1. Architecture requirements ................................................................. 17

Key architecture requirements: .................................................... 17

Privacy & Security by Design ....................................................... 17

3.2. High level architecture overview ......................................................... 18

Steps to define the system architecture .......................................... 19

System architecture interfaces..................................................... 22

Adding the business layer to the architecture ................................... 24

3.3. Roles and functional components involved .............................................. 25

Roles ................................................................................... 26

Functional Components ............................................................. 28

4. USE CASE DESCRIPTIONS ....................................................................... 29

4.1. Use case 1 .................................................................................... 29

Scope ................................................................................... 29

Objectives ............................................................................. 29

4.2. Use case 2 .................................................................................... 30

Scope ................................................................................... 30

Objectives ............................................................................. 30

4.3. Use case 3 .................................................................................... 31

Scope ................................................................................... 31

Objectives ............................................................................. 31

5. DISTRICT ARCHITECTURE ...................................................................... 32

D7.1 & D7.2


5.1. Smart Grid Architecture Model ............................................................ 32

SGAM ................................................................................... 32

Component layer ..................................................................... 33

Communication layer ................................................................ 37

Information layer ..................................................................... 37

Function layer ........................................................................ 40

Business layer ......................................................................... 40

5.2. Distribution grid topology .................................................................. 43

6. RISK MANAGEMENT ............................................................................. 48

7. REFERENCES ..................................................................................... 49

8. APPENDICES ...................................................................................... 50

8.1. Appendix 1 – Use case diagrams ........................................................... 50

Use case 1 ............................................................................. 50

Use case 2 ............................................................................. 58

Use case 3 ............................................................................. 62

D7.1 & D7.2


LIST OF FIGURES

Figure 1 – Geographical location Strijp-S, Eindhoven (the Netherlands) 16 Figure 2 – Impression of Strijp-S (figure from [4]) 16

Figure 3: Schematic overview privacy by design (figure from [5]) 18 Figure 4: Possible relations between market roles, from Smart Grid Task Force Grid report:

‘Regulatory Recommendations for the Deployment of Flexibility ‘ [1] 19 Figure 5 - COTEVOS Reference Architecture [7] 20 Figure 6 - Aggregation in the COTEVOS service oriented architecture 21

Figure 7 - InterFlex top level architecture for Eindhoven, Netherlands 22 Figure 8 - The full USEF interaction model 23 Figure 9 - Core principle of OSCP Open Smart Charge Protocol 24 Figure 10 - Contract, billing and settlement in the InterFlex system for Eindhoven 25

Figure 11 – Roles, systems and interactions in the InterFlex system for Eindhoven 26 Figure 12 - InterFlex top level architecture (use case sections) 32 Figure 13 – SGAM component layer use case #1 34 Figure 14 - SGAM component layer use case #2 35

Figure 15 - SGAM component layer use case #3 36 Figure 16 - SGAM integral communication layer 38 Figure 17 - SGAM integral information layer 39 Figure 18 - SGAM integral function layer 41

Figure 19 - SGAM integral business layer 42 Figure 20 - Generic overview of Dutch MV networks, distinguishing MV transmission and

distribution cables, and MV substations & (MV/LV) distribution stations. Figure from [17] 44 Figure 21 - Schematic overview of the MV network of Strijp-S 45 Figure 22 - Geographical overview of the MV network of Strijp-S (red marked area) 46

Figure 23 – Diagram Use case 1 – Improve grid flexibility using Central Storage Unit 51 Figure 24 –Sequence diagram use case 1 – SSU is charged by PV 52

Figure 25 –Sequence diagram use case 1 – SSU is charged by supplier (flex request) 53 Figure 26 –Sequence diagram use case 1 – Voltage support 55

Figure 27 –Sequence diagram use case 1 – Power quality 57 Figure 28 – Diagram Use case 2 – Improve grid flexibility using EV 59 Figure 29 –Sequence diagram use case 2 – EV use preferences allows flexibility 60 Figure 30 – Diagram Use case 1 – Usability of an integrated flex market 62 Figure 31 –Sequence diagram use case 3 – Integrated Flex Market 63

Figure 32 –Sequence diagram use case 3 – Emergency scenario 65

Table 1 – List of acronyms 8 Table 2 - MV/LV substations equipped with DA(LI) measurements, including information on

type of substation, rated power, outgoing feeders (including dedicated), and number of

connected customers 47 Table 3 – Steps sequence diagram – SSU is charged by PV 52 Table 4 – Steps sequence diagram – SSU is charged by supplier (flex request) 54

Table 5 – Steps sequence diagram – Voltage support 55 Table 6 – Steps sequence diagram – Power quality 57 Table 7 – Steps sequence diagram – EV use preferences allows flexibility 60 Table 8 – Steps sequence diagram – Integrated Flex MarketScenario Name : 63 Table 9 – Steps sequence diagram – Emergency scenario 65

D7.1 & D7.2


NOTATIONS, ABBREVIATIONS AND ACRONYMS

The table below provides an overview of the notations, abbreviations and acronyms used in

the document.

Table 1 – List of acronyms

B2B Business to Business

BRP Balance Responsible Party

CA Commercial Aggregator

COTEVOS

Concepts, capacities and Methods for Testing EV Systems and their Interoperability within the Smart Grids

CP Charge Point

CPMS Charge Point Management System

DA

Distribution Automation (Enexis specific system)

DALI Distribution Automation Light (Enexis specific system)

DAM Day-ahead market

DER Distributed Energy Resources

DSO Distribution System Operator

EC European Commission

EC-GA European Commission Grant Agreement

EED Energy Efficiency Directive

EFI Energy Flexibility Interface

EG3 Expert Group 3

eMI3 eMobility ICT Interoperability Innovation

EMSP Electro Mobility Service Provider

ESCO Energy Service Company

EU European Union

EV Electric Vehicle

EVSE Electric Vehicle Supply Equipment

FAN Flexible power Alliance Network

FAP Flexibility Aggregator Platform

GA General Assembly

GMS Grid Management System

GWP General Work Package

HV High Voltage (grid)

ICT Information and Communication Technology

KPI Key Performance Indicator

LA Local Aggregator

LIMS Local Infrastructure Management System

LV Low Voltage (grid)

MV Medium Voltage (grid)

NL Netherlands

OCA Open Charge Alliance

OCPP Open Charge Point Protocol

D7.1 & D7.2


OSCP Open Smart Charging Protocol

OT Operation Technology

PC Project Coordinator

PTU Program Time Unit

PV PhotoVoltaics

RTU Remote Terminal Unit

SC Steering Committee

SGAM Smart Grid Architecture Model

SGEMS

Sub-Group to foster the creation of an Electro-mobility Market of Services

SGTF Smart Grids Task Force

SME Small Medium Enterprise

SSU Smart Storage Unit

STF Sustainable Transport Forum

TC Technical Committee

TD Technical Director

THD Total Harmonic Distortion

TSO Transmission System Operator

USEF Universal Smart Energy Framework

WP Work Package

WPL Work Package Leader

D7.1 & D7.2


1. INTRODUCTION

Scope of InterFlex in the Netherlands.

95% of all renewable energy sources are connected to the distribution grid. Governments in

Europe are giving priority to millions of charging points and stations for growing electric

transport in the coming decades. Behavior of consumers and technology change rapidly. In

this context, the grid must be able to count on a system that addresses local needs and

developments.

InterFlex aims to develop the next generation of smart networks in Eindhoven and elsewhere

in Europe to speed up the energy transition.

In the InterFlex project, different research areas come together:

Flexibility (decentralized power management, electric cars, storage, smart charging)

in the local area

Multi-service approach to storage systems (including development services) and the

required regulation (who does what)

Electric mobility as flexible storage for the network

Substitution and interoperability of storage systems and the role of IT systems in a

flexible network.

InterFlex has a term of 36 months. The partners will implement local innovations as

quickly as possible, as agreed.

InterFlex in Eindhoven.

The pilots in Eindhoven, led by Enexis, take place at Strijp-S. Here, all the elements of the

smart grid will be tested, it's the combination of local storage, EV, smart loading, smart

meters and distribution automation. Together with ElaadNL, Enexis is the leading partner

for the development of smart charging in Europe (Enexis developed a charging protocol

that became the norm in Europe).

Enexis works closely with ElaadNL, TNO and the municipality of Eindhoven for the

project.Enexis demonstrated at the start the approach to the project, together with partners

ElaadNL, TNO and the municipality of Eindhoven. ElaadNL and TNO will build a

technologically smart grid platform with open interfaces in InterFlex, creating a flexible grid

based on new business models.TNO can focus on previously acquired knowledge and

technology from international projects. ElaadNL introduces knowledge about charging

infrastructure, interfaces and algorithms in such networks.

About Enexis

As the regional distribution system operator, Enexis reliably distributes affordable electricity

and gas to 2.7 million and 2.3 million customers respectively in the provinces of Groningen,

Drenthe, Overijssel, Noord-Brabant and Limburg. The company is responsible for the

installation, maintenance, development and management of its electricity and gas grids.

Enexis connects partners, local authorities and in-house knowledge, to contribute to the

realisation of the Energy Agreement. Moreover, Enexis actively encourages customers in

their energy-saving efforts, including through the Buurkracht programme. Enexis employs

around 4,500 people.

D7.1 & D7.2


About E-LaadNL

ElaadNL is the knowledge and innovation center in the field of (smart) charging

infrastructure in the Netherlands. ElaadNL has been working from the beginning in the e-

mobility field and gained great practical knowledge about charge infrastructure and now

focusses on ‘connecting’ the charge infrastructure to (different stakeholders in) the

electricity-system. ElaadNL is founded by the DSO’s in the Netherlands. ElaadNL is active in

a lot of open ‘practical’ developments such as e-clearing.net (www.e-clearing.net) and

developed the Open Charge Point Protocol (OCPP) (www.openchargealliance.org ).

About TNO

More than 3000 professionals at TNO apply their knowledge to realise smart solutions for

complex challenges. These innovations contribute to a sustainable enforcement of the

competiveness of industry and welfare of society. They partner with more than 3000

companies and organisations home and abroad, including SMEs. For example from the Theme

Energy they contribute to a sustainable, efficient and secure energy supply. For more

information on TNO and the other social themes they focus on, refer to www.tno.nl/en/

In this document we describe the system architecture that is developed with the project

partners.

Starting point for the definition of the architecture was a distributed architecture based on

open standards (USEF, EFI, Open ADR) and systems that are connected with open protocols.

With this philosophy we are able to use the knowledge and the systems on the market and

adapt this for InterFlex. Together with market parties we are going to define the functional

specifications in detail and also build the systems. The market parties involved also stated

that they are interested in a commercial deployment of the system.

D7.1 & D7.2


2. PROJECT CONTEXT & GOALS

2.1. The Dutch InterFlex Demonstration

In the Dutch InterFlex demonstration we research how a DSO can use flexibility to have a

cost effective grid infrastructure. One approach for instance is using flexibility for congestion

management purposes. In the EU the role of the DSO is restricted; it can, simply put, manage

the physical grid but taking on (possible) commercial roles such as an aggregator of flexibility

is really beyond its scope. An external aggregator party is needed to operate flex sources in

its network directly and trade that flexibility with a DSO. An aggregator can obtain flexibility

in several ways, one option is to install their own flexibility assets in the grid. Another

possibility is to aggregate the energy flexibility of end users, for instance smart storage unit

(use case 1) and EV owners (use case 2).

The demonstration focusses on both the technical realization of the usage of flexibility for

grid management purposes, as well as the realization of the business layer of flexibility

trading between the DSO and aggregators. The desired outcome of the demonstration is to

have a scalable and viable systems architecture and scalable and positive business cases for

all stakeholders involved.

Within the demonstration the concept of flexibility marketplace is introduced. This

marketplace can be used by aggregators to offer their flexibility to buyers. In the scope of

the demonstration the buyers typically are network operators. The network operators use

the market place to purchase flexibility based on their needs and preferences. A straight

forward preference could be lowest price, however a higher priority need could be the

guarantee of delivery. A scalable flexibility marketplace enables multiple parties in the same

role (aggregator, DSO, etc.). In this demonstration we will look at the commercial aspect of

the aggregator role, the trading of flexibility on the market, as well as the technical aspect:

the management of EV’s and other devices, and actually aggregating their flexibility to have

offerings with sufficient impact.

By looking explicitly at these different aspects of the aggregator role we will acquire the

necessary knowledge about the mechanisms of pricing (the marginal price of flexibility of

different flexibility resources), accumulating flexibility and the merit order of flexibility.

2.2. Goals of the demonstration

The overall aim of the demonstration is to research how a DSO can use flexibility to maintain

power quality in the grid economically. And create scalable and positive business cases for

all stakeholders involved. To do this the following set of project goals is formed:

Use flexibility for grid management purposes:

Within the demonstration energy flexibility should be used for grid management purposes.

This could be: congestion management and/or other power quality increasing measures.

Scalable solution & architecture:

The proposed solution should be scalable such that it can be rolled out widely throughout

the Dutch energy system (and possibly also in other EU countries’ energy systems) after the

demonstration. This means that all relevant stakeholders must be involved and there is a

D7.1 & D7.2


clear separation of roles in the demonstration. The involvement and contribution of each

stakeholder should be consistent with their role ambitions within the energy system. By

designing the demonstration in such a way, the architecture and business models may

continue to exist and evolve in the ‘real world’, beyond the lifecycle of this project.

Design and implement functional & business layer: flexibility trading

Since the demonstration is not only a functional showcase, the business layer should be

developed too. This means that realistic contracts should be described between the

stakeholders. Furthermore, the value exchange must be realistic.

Implement open market architecture for flexibility:

In order to enable an open market where multiple aggregators can trade flexibility with one

or more DSOs, existing market models, frameworks and open standards should be considered

a basis for the implementation of the market.

Determine merit order for flexibility:

By trading flexibility from different resources on the flexibility market, insight will be

acquired about the marginal price of flexibility of different flexibility resources,

accumulating this information will result in a merit order of flexibility.

2.3. Tested innovations

The innovations that are tested in this project are systems and mechanisms on operational,

enterprise and market levels, which enable the provision of ancillary services to the

distribution grid via a flexibility market. Flexibility market models in themselves and the

associated technical and organizational aspects are not mature yet. Putting these ideas into

practice in the InterFlex demonstration naturally leads to new solutions (while building on

existing solutions) for this particular demonstration and, as set out in the above mentioned

goals, potentially in scalable solutions for an open market architecture for flexibility

markets. We make a distinction in technical and organizational innovations for this project.

Technical innovations aiming for improvement of:

- ICT-systems for grid monitoring and distribution automation

- ICT-systems for monitoring, control and market processes related to the flexibility

sources, loads and generation in the demonstration:

o Community energy storage

o PV-generation

o Charging points for electric vehicles

- Communication interfaces and information exchange between the ICT-systems and

with flexibility sources, loads and generation.

Organizational innovations:

- Flexibility market mechanisms

- Contractual agreements between the involved parties (i.e. DSO, commercial

aggregators and technical aggregators)

- Agreements and mechanisms to deal with conflicting goals concerning flexibility

requirements

D7.1 & D7.2


- Business models1 for aggregators providing ancillary services to DSOs based on

flexibility market trading

- Business model for DSOs for the use of a flexibility market for congestion

management and power quality

The KPIs described in the following section are used for the validation of the implemented

solutions.

2.4. KPIs

In InterFlex the implemented products and services will contribute to improve the

performance of the smart grids. The expected performances are estimated through Key

Performance Indicators. A preliminary set of KPIs has been defined to monitor the

performance of the demonstrations. For the demonstration in Eindhoven, The Netherlands,

the starting point for this project was to aim at measuring the following demonstration KPIs:

Availability % of time during which the storage is available (NL 1 & 2, NL: >90%

(battery-based storage)

o In this demonstration this is the SSU (Smart Storage Unit)

o Optionally if measurement are available also availability of assets and data

can be calculated

Efficiency Battery-based storage efficiency (NL 1, NL: 85% SSU)

Impact on the grid % of shifted energy; Contribution to load shedding; Contribution

to ancillary services, NL 1 & 2, NL: 10% (shedding; based on ratio capacity of the

battery versus network consumption in the defined area) 10% (Ancillary services)

Potential to shift demand share of energy/power displaced for each type of

flexibility, NL 2, NL: 5% (in overall grid)

o The types of availability in this demo are EVs and the SSU

Local peak load reduction % of decrease on ratio P-peak / P-average at MV feeder

level (third level area) NL 1 & 2, NL: 20%

o More specific: this will be measure on the basis of 15 minute values (highest

value of the day, and the average of all 15 min intervals of the day)

Besides these demonstration KPIs one key KPI has been added and a few are being considered

to be added:

A new key KPI is the KPI on available power flexibility

o The available power flexibility in a defined period (e.g. per day) that can be

allocated by the DSO at a specific grid segment (congestion point),

measured in MW. This in relation with the total amount of power in the

specific grid segment in the same period.

A KPI on power quality is foreseen: voltage measurement (average per 15 min or 5

min)

1 There is not one clear definition of a ‘business model’ as described in [20]. For this project we adopt the following: « a business model is a description of how your business runs » (Joan Magretta cited in [20]) and Alex Osterwalder’s approach « His nine-part “business model canvas” is essentially an organized way to lay out your assumptions about not only the key resources and key activities of your value chain, but also your value proposition, customer relationships, channels, customer segments, cost structures, and revenue streams — to see if you’ve missed anything important and to compare your model to others. » (Alex Osterwalder cited in [20]).

https://hbr.org/2013/05/a-better-way-to-think-about-yo/

D7.1 & D7.2


o To be measured at begin feeder, or middle, or end, or PV entry point, or

EVSE locations, or SSU location, whatever available.

Forecasting is a crucial function in the system (mainly aggregator and DSO) therefor

we want to measure Forecasting quality (EV, PV, system, ….)

o This is the deviation from actual load compared to forecasted load

Ability to integrate intermittent energy (PV, wind)

o This has been added since one of the overarching goals of this project is to

enable integrating large share of renewables exceeding 50% by 2030

o Based on available and measured data the definition how to measure this is

still to be defined

Flexibility value, if feasible per type of flexibility (EV, SSU)

o For the DSO flexibility has a cost, but reflects a value in their business case

to delay or prevent investment

o Flexibility sold by aggregators to DSO is an income from them, but reduce

the value of the total portfolio.

o Depending on business model and available data these values can be defined

in detail and measured.

2.5. Demonstration location

Eindhoven is the 5th largest city in the Netherlands, and traditionally a very industrialized

high tech region. It is home to one of the biggest research and development communities in

Europe, and birth place to successful multinationals such as Philips, ASML and DAF trucks.

In 2016, the Eindhoven region was responsible for 25% of all Dutch exports, and 36% of all

private Dutch R&D investments are done in this region [2]. The city of Eindhoven welcomes

Innovation initiatives and facilitates where it can. One of the focus areas within the city for

design & technology innovations it the region known as Strijp-S. This is a former Philips

Industrial complex, which now houses a wide variety of start-ups. The location, its

infrastructure and the innovative community mindset make it a perfect location for the

Dutch demonstration for the InterFlex project.

Strijp-S has an area of 0.3 km2 within the city of Eindhoven [3]. Figure 1 illustrates the

geographical location in relation to other main cities in the EU.

In the first half of the 20th century, Strijp-S developed itself as an industrial site, facilitating

various factories of the company Philips on its terrain. After Philips moved out in the

beginning of the 21st century, the area began redevelopment. Various old factories got

renovated, and newly developed apartment buildings got added.

Currently, the area is mostly a mix of mainly SMEs and residential buildings. As of the 1st of

January, 2017, Strijp-S has 830 inhabitants [3], a number that is growing with the newly

planned and build apartment buildings. Figure 2 gives an impression of the current state of

the demonstration site.

D7.1 & D7.2


Figure 1 – Geographical location Strijp-S, Eindhoven (the Netherlands)

Figure 2 – Impression of Strijp-S (figure from [4])

D7.1 & D7.2


3. SYSTEM ARCHITECTURE

3.1. Architecture requirements

Key architecture requirements:

Be able to unlock, use and control flexibility coming from local

generation/consumption, especially EVs and storage systems

Enabling congestion management and other ancillary services to DSOs

Independent aggregator role should be included

Enabling an integrated flexibility market on different levels: technical, economical

and contractual

Clear separation of concerns per role, is a kind of architecture design principle for

separating it into distinct areas or systems, such that each area is able to addresses

a separate concern (or goal or requirement).

Scaling-up should be feasible in the real world: so not a centralized system that

collects all data from every stakeholder role for unconstrained direct access (in a

huge database), as used often in pilots and demos

Aligned with smart grid and eMobility reference architectures and related

(standardization) groups and organizations like:

o Smart Grid Mandate M/490

o STF-SGEMS: Sustainable Transport Forum - Sub-Group to foster the creation

of an Electro-mobility Market of Services

o eMI3: eMobility ICT Interoperability Innovation

o OCA: Open Charge Alliance

o FAN: Flexiblepower Alliance Network

o USEF: Universal Smart Energy Framework

Use of open models, interfaces, and standards (of these groups and organizations)

like:

o SGAM from M/490 (the Smart Grid Architecture Model)

o EFI: Energy Flexibility Interface from FAN

o USEF interfaces

o OSCP (Open Smart Charging Protocol) and/or OCPP (Open Charge Point

Protocol) from OCA

The architecture should be able to also address security and privacy (see section

3.1.2)

The Flexibility Aggregation Platform (FAP) should use local flexibility sources and

exploit these on energy and other (flexibility) markets

Open flexibility market design (so every stakeholder/aggregator can participate)

Privacy & Security by Design

Part of this innovation is collecting research data. When doing this it is important to include

privacy & security from the start, or “by design”. This way it is not an obstacle for

implementation and the implementation will meet the required Dutch standards.

For Privacy by Design, the following eight principles will be used:

D7.1 & D7.2


Figure 3: Schematic overview privacy by design (figure from [5])

These eight principles are divided in two categories, process and data related. The process

related principles are “inform”, “control”, “enforce” and “demonstrate”, the other four,

“minimise”, “separate”, “aggregate” and “hide” are data related. The latter will be applied

to the Dutch research data and used as a starting point when designing the systems.

For security by design a risk analysis will be executed once the architecture has been

defined. For Operation Technology (OT) security a risk analysis was done for DALI devices

based on the ISA 99 standard (IEC 62443). In short this boils down to identifying threats and

vulnerabilities, calculating the risk by determining impact and likelihood and defining and

implementing counter measures.

For IT security a similar approach will be used. Since IT security also includes B2B

communication, the result of the privacy by design analysis will also be used as an input to

determine the IT security level and corresponding countermeasures.

3.2. High level architecture overview

In order to identify the roles and responsibilities in the demonstration a high level

architecture is sketched. Crucial for the system architecture is the inclusion of an aggregator

role. Aggregation can mean a lot, in general it is a way of collecting, even in the energy

domain there are different views and definitions (also depending on regulation). In the Dutch

InterFlex demonstration the definition of the Smart Grids Task Force (SGTF) Expert Group 3

[1] is followed, this definition is published in their report [1]. This definition is chosen

because it is a complete and clear definition. The expert group consists of more than 40

experts from this smart grid field. This aggregator definition is as follows:

D7.1 & D7.2


Aggregator: A legal entity that aggregates the load or generation of various demand

and/or generation/production units. Aggregation can be a function that can be met

by existing market actors, or can be carried out by a separate actor. EED (Energy

Efficiency Directive): aggregator’ means a demand service provider that combines

multiple short-duration consumer loads for sale or auction in organized energy

markets.

In the same document, this expert group describes possible relations between market roles

and an aggregator. This figure shows possible relations between existing market roles and

an aggregator.

Figure 4: Possible relations between market roles, from Smart Grid Task Force Grid report: ‘Regulatory Recommendations for the Deployment of Flexibility ‘ [1]

Since the aggregator acts in the commercial domain it is often called a Commercial

Aggregator (CA), which we will also use in this project and document. Besides the

Commercial Aggregator we also define the role of the Local Aggregator (LA), this is the role

that collects and bundles geographically local flexibility and hands this flexibility over to a

Commercial Aggregator which exploit its value on energy and flexibility markets.

Steps to define the system architecture

In InterFlex for the Dutch Demonstration we will integrate EVs and their charge flexibility.

The Sustainable Transport Forum (STF) has in 2016 set up a Sub-Group to foster the creation

of an Electro-mobility Market of Services (SGEMS) [6].

The main objectives for the subgroup are:

D7.1 & D7.2


1. To define interoperability for charging points

2. To recommend standards and procedures for the deployment of electro-mobility

services

3. To propose guidance for a European framework for an electromobility market of

services

This subgroup is in the process of adopting the COTEVOS eMobility Reference Architecture

from the figure below.

Figure 5 - COTEVOS Reference Architecture [7]

In this COTEVOS reference architecture, the e-mobility roles and the interfaces toward each

other are depicted. The Energy Supplier communicates on energy and the DSO on capacity

constraints towards the EMSP and/or EVSE operator. In case we add a Commercial Aggregator

to this architecture. The CA will procure flexibility from devices (EVs) and offers it to the

DSO, an explicit functionality can be recognises, one that is also identified in the more

detailed service oriented architecture of COTEVOS as Commercial Aggregation Service. This

can be seen in Figure 6.

COTEVOS made multiple possible mappings of services to roles. In one the service mapping:

the EVSE Operator executes the Smart Charging services, communicates with the

aggregator/flexibility operator and the DSO as depicted in the figure below.

D7.1 & D7.2


Figure 6 - ] COTEVOS, “Set-up of the reference architectures in some of COTEVOS’

infrastructures” 14-11-2014.

Link:

http://cotevos.eu/wp-content/uploads/2015/05/Set-up-of-the-reference-architectures-in-some-of-COTEVOS’-infrastructures-FULL-VERSION.pdf

In InterFlex we need to be even more generic since more type of loads than only EVs will be

present (e.g. battery storage). The EVSE operator or EMSP are restricted to EV and therefore

will not perform this, the DSO needs to be able to negotiate with all forms flexibility, not

only EVs. Therefore an explicit addition of an aggregator role is chosen. This role interacts

with the DSO and the energy market or supplier.

This brings us to the core InterFlex Architecture for the Dutch demonstration in the figure

below. The architecture is designed to enable the existence of multiple aggregators in the

system. For bundling of the non-EV flexibility we added another system called LIMS (Local

Infrastructure Management System) this LIMS performs the local aggregation. We explicitly

not named it Energy Management System since the management of Energy (flexibility) will

be transferred to the next level (commercial aggregator), which can optimize the energy

and capacity management based on value.

http://cotevos.eu/wp-content/uploads/2015/05/Set-up-of-the-reference-architectures-in-some-of-COTEVOS'-infrastructures-FULL-VERSION.pdf

http://cotevos.eu/wp-content/uploads/2015/05/Set-up-of-the-reference-architectures-in-some-of-COTEVOS'-infrastructures-FULL-VERSION.pdf

D7.1 & D7.2


Figure 7 - InterFlex top level architecture for Eindhoven, Netherlands

Note that this architecture does not contain an (experimental) system with a large database

in the middle as being done in other demonstration and pilots, in order to be able to access

all data and react on those. This is done to keep the functional responsibilities of the

subsystem bounded to the responsibilities of the roles, therefore the proposed architecture

is deployable in ’the real world’. This makes the InterFlex architecture not more complex,

but the interfaces need to be designed better and up-front, as a result it is better scalable

for future roll-out.

System architecture interfaces

After defining the (sub)systems in the high level architecture, the interfaces between the

subsystems can defined. The CPMS and LIMS communicate the available flexibility towards

the commercial aggregators, they make their plan/program for the next period (based on

energy markets) and communicate the program to the DSO. If a grid capacity reduction is

required the GMS of the DSO requests that to the aggregators. After this has been settled

devices to adapt their the aggregator controls the consumption/production of devices that

offered the flexibility, to execute the desired program.

D7.1 & D7.2


A framework that has worked out such an interface between the DSO and Aggregator in an

integrated context is the Universal Smart Energy Framework (USEF). The figure below

depicts the full USEF interaction model [8]:

Figure 8 - The full USEF interaction model

Another option or alternative for the interface between aggregator and DSO system is OSCP,

the Open Smart Charging Protocol [9]. OSCP 1.0 is officially released in May 2015. OCA

adopted this OSCP. After several review rounds and an implementation, version 1.0 is ready

for use. The protocol can be used to communicate a 24-hour prediction of the local available

capacity to the Charge Spot Operator (or another local load controller). The Service Provider

will fit the charging profiles of the electrical vehicles within the boundaries of the available

capacity, see the figure below.

D7.1 & D7.2


Figure 9 - Core principle of OSCP Open Smart Charge Protocol

In Figure 7 - InterFlex top level architecture for Eindhoven, Netherlands the InterFlex top

level architecture for the Eindhoven demonstration is shown. The figure reveals that a

protocol is required to communicate energy flexibility between the CA and LA. A possible

communications protocol for this interface is the Energy Flexibility Interface (EFI) (from

Flexiblepower Alliance Network), as being further described in [10]. We have chosen to

include this protocol since is also being used and tested with the PowerMatcher demand

response technology, a Smart Grid and Transactive Energy Solution. Furthermore, EFI also

contains flexibility models for EV and batteries. Another protocol which can be considered

for this function is OpenADR.

They have not released interface standards, but delivered Another standardization group

related to EV architectures, use cases and standards is eMI3: eMobility ICT Interoperability

Innovation where applicable we will use these.

Adding the business layer to the architecture

So far we have addressed the architecture on system level and functional layer (according

to SGAM). But also the business layer is in scope and needs to be addressed.

D7.1 & D7.2


The figure below depicts the roles/stakeholder from the business layer, and their relation

on contract (the phase before de real-time data ICT interfaces) and billing and settlement

(the phase after real-time).

Charge Point

Operator

CPMSCharge Point

Management System

StorageOperator

CBMSCentral Battery

Management System

Aggre-gator

Distr. System

Operator

AGGR-PAggregator Platform

Demand & Supply

ELMSElectric Load

Management SystemGMS

Grid Management System

LIMSLocal Infrastructure

Management System

CPMSCharge Point

Management System

FAPFlexibility Aggregator Platform

E-flex à ß Control signal


StorageOperator

Charge Point

Operator

Distr. System

Operator

Aggre-gator

F contractFlex (euro) à

E, F contractElektra (euro) à ß Flex (euro)

Interflex NL - roles, systems and communication

ß D-prog/confirmation à Flex request à Flex (euro) à

F contractFlex (euro) à

Figure 10 - Contract, billing and settlement in the InterFlex system for Eindhoven

Scalability

To verify scalability, we sketch below a possible future scenario for the Netherlands.

A scenario is that there are a few LIMS and CPMS per big city, and that one LIMS/CPMS

manages/connect thousands of devices. In case every Dutch household would have 2 flexible

devices (and EV and one heat pump) (totalling 16 million), and 20 LIMS system and 20 CPMS

would be available one LIMS/CPMS would have 400k devices. Not a small number, but an

amount that should be feasible to manage.

Suppose further (for the Netherland in 2050) 10 energy suppliers, 20 commercial aggregators

and 5 DSOs. If the total distribution network would have 100.000 congestion points, on

average one congestion point would contain 80 EVs and 80 other flexible loads. This number

seems high enough to ensure enough available flexibility (we do not foresee congestion

points with less than 10 (smaller) flexible loads)

3.3. Roles and functional components involved

Section 3.1 & 3.2 introduce the motivation and considerations of the Eindhoven

demonstration’s high-level system architecture (Figure 11). This architecture facilitates a

D7.1 & D7.2


local flexibility market. Commercial aggregators participate in this market to offer flexibility

to buyers (e.g. BRPs, TSOs, DSOs), both ahead of time (e.g. day-ahead) and near real time.

In this local flexibility market, the DSO will have a role different than its traditional role.

Contrary to the DSO’s traditionally neutral market position, within this demonstration the

DSO will actively participate in the local flexibility market, in order to procure flexibility for

grid management purposes.

A number of systems are implemented with as goal to facilitate a local flexibility market.

Furthermore, independently operable roles are defined. Section 3.3 will describe all roles

and functional components based on the high-level architecture as shown in Figure 11. The

roles can be found under subsection 3.3.1, whereas the functional components can be found

under subsection 3.3.2.

GMSGrid Management System


Management System

CPMSCharge Point

Management System


ß D-prog/confirmation à Flex request à


StorageOperator

Charge Point

Operator

Distr. System

Operator

Aggre-gator




Aggre-gator

Aggre-gator

Central battery

PVOwner

PVsystem

SolarV2G

Solar car

Community

StrijpDC houses






Charge point

Datalake

Figure 11 – Roles, systems and interactions in the InterFlex system for Eindhoven

Roles

Distribution System Operator (DSO):

As defined in [1], the role of the DSO is operating, maintaining, and where necessary

developing the distribution system in its territories, including the interconnections to the

higher level systems. This includes ensuring the availability of sufficient grid capacity and

making sure the system’s stability criteria are met.

D7.1 & D7.2


Within the Eindhoven demonstration, the DSO will participate on a local flexibility market,

in order to procure flexibility for grid management purposes. Through the GMS (see section

3.3.2) the DSO interacts with the systems of the commercial aggregators, and accesses the

local flexibility market.

Commercial Aggregator (CA):

Based on section 3.2, the role of the commercial aggregator is described as a demand service

provider that combines multiple short-duration flexibility sources for sale or auction in

organized energy markets. This can be for example flexibility for DSO, TSO, BRP, or energy

trade on day-ahead or intraday market). The flexibility is obtained through contracts with

local aggregators.

Within the Eindhoven demonstration project, the general term for a CA ICT-system is FAP

(Flexibility Aggregation Platform). This is the system that on one side aggregates flexibility

from LAs and on the other side offers that aggregated flexibility to flexibility market parties.

For more information on this system, see section 3.3.2.

Local Aggregator (LA):

The role of the local aggregator is to collect and bundle (geographically) local flexibility into

a bigger aggregated flexibility offering, and to provide this to a commercial aggregator

(which in turn exploits the flexibility’s value on energy- and flexibility markets). In order to

obtain flexibility sources for its asset portfolio, the LA has interactions and contracts with

DER and EV owners.

Within the Eindhoven demonstration, we use two different names for the ICT-system of a

LA. The generic term is LIMS, a Local Infrastructure Management System. Additionally, we

also use the term CPMS, which is exactly the same as a LIMS but dedicated to managing

charge points for EVs. This is done because CPMS is a widely accepted system acronym and

using LIMS in the charge point context could cause confusion. See section 3.3.2 for more

information on these systems.

Note: we are describing roles here. Distinguishing between different roles doesn’t mean that

a single party cannot combine multiple roles. It is very conceivable that some market parties

will wish to combine roles like CA and LA, where other parties may wish to specialize in one

role. The same holds true for their ICT-systems. If a party combines multiple roles the ICT-

system interactions between those roles becomes something internal to that party. In that

case only the external interactions of the systems belonging to those roles are relevant for

interoperability.

Charge Point Operator (CPO):

The role charge point operator is a specialisation of the role local aggregator, dedicated to

managing local infrastructure of type charge point for EVs. For more information, see LA.

DER owner:

This is the owner of the DER or flexibility source (for example, but not limited to, smart

storage unit, solar PV, charge points). The DER owner is responsible for strategic scheduling,

and getting a contract with a local aggregator to ensure exploitation of the flexibility

sources.

D7.1 & D7.2


Functional Components

Grid Management System (GMS):

The grid management system is a DSO operated system, interacting with the FAPs of

contracted commercial aggregators.

The GMS makes sure distribution grid constraints (e.g. capacity, voltage) are monitored, and

- in case a constraint violation is expected – flexibility is procured from the commercial

aggregators.

Flexibility Aggregation Platform (FAP):

The flexibility aggregation platform is a system with which a commercial aggregator

aggregates the flexibility assets from contracted local aggregators, and offers this flexibility

to market parties such as (but not limited to) DSOs, TSOs, and BRPs. To this end, the FAP

interacts with the GMS, LIMS, CPMS, and various market parties’ systems outside of the scope

of the Eindhoven demonstration.

Local Infrastructure Management System (LIMS):

The local infrastructure management system is a system operated by a LA. It provides

flexibility to the contracted CAs by providing the FAPs with a single interface to all the

available flexibility – or DER – sources connected to the LIMS.

Charge Point Management System (CPMS)

The charge point management system is a system operated by a CPO. It offers the flexibility of the connected charge points to the contracted CAs by providing the FAP with an interface to unlock this flexibility.

D7.1 & D7.2


4. USE CASE DESCRIPTIONS

The Dutch use cases were already described in specific use case documents. In this chapter

contains the scope and objectives. For the use case diagrams see Appendix 1.

4.1. Use case 1

Scope

Enabling ancillary services, congestion management, voltage support for PV integration using

centralized, grid-connected storage systems to improve grid observability of prosumers,

promoting batteries in multi-service approach.

In scope:

- Battery infrastructure and deployment - Congestion management - Voltage support for PV integration - Multi-service approach - Local Infrastructure Management System

Out of scope:

- Other ancillary services (is not in pilot, but aggregator can use the battery for ancillary services if part of its business model)

- Power quality improvement (other than voltage support) - Domestic battery systems

Objectives

Small headline:

This use case conceptualizes, implements the systems and interactions necessary to achieve

a stable grid through flexibility using Smart Storage Unit and PV systems.

By implementing use case 1, Enexis and the involved aggregators test and validate the

application of a smart storage unit for the following purposes:

- Congestion management - Energy trading / portfolio management through spot market, imbalance market

and/or ancillary service provision - Power quality improvement (voltage support) upon request from DSO

Specific: Design local infrastructure management systems and extend aggregators platform to

translate DSO requirements (based on real-time measurements or predictions) into actual

load balancing and voltage control requests.

Measurable: Battery-based storage efficiency (KPI_NL1).

Percentage of time during which the storage is available (KPI_NL2).

The percentage of shifted energy, contribution to load shedding

and ancillary services (KPI_NL3).

D7.1 & D7.2


Share of energy/power displaced for each type of flexibility (KPI_NL4).

Percentage of decrease on ratio Peak/average at MV feeder level (third level area)

(KPI_NL5).

Assignable:

Technical/local aggregator (with its LIMS) and commercial aggregators (with its FAP) have a

primary role to implement this capability in their systems. Initiation of this functionality can

be done by DSO (flex requirements/request) and aggregators (change in availability of

resources).

The DSO is responsible for availability: Smart Storage unit (SSU), PV systems, LIMS, GMS (incl.

grid measurements from distribution automation boxes and smart meters).

The commercial aggregator is responsible for availability: FAP

TNO is responsible for interoperability and interchangeability of the systems.

Realistic: Flexibility availability by using locally available Smart Storage Unit and PV systems.

Time-related:

When the Smart Storage Unit and PV systems are in place and the aggregator systems have

been developed and/or adapted, see project planning.

4.2. Use case 2

Scope

Enabling the optimal activation of all available local flexibilities offered by the locally

installed EVSE’s for congestion management. This is done by allowing the DSO, that monitors

the grid, to send flexibility requests towards commercial aggregators that will, through

interacting with the CPO, end up as adapted charging schedules on EVSE’s, making the

necessary flexibility happen.

In scope:

- EV infrastructure - Chain process from EV driver (preferences) to DSO (requirements) through roles and

protocols that are necessary to make the flexibility happen

Out of scope:

- Non EV infrastructure - Other ancillary services - Commercial viability is part of use case WP7_3

Objectives

This use case conceptualizes and implements the systems and interactions necessary to

achieve a stable grid through flexibility using EV systems.

D7.1 & D7.2


By implementing use case 2, DSO/CPO/involved aggregators test and validate a technical

framework for realizing DSO requested flexibility from EVs in order to prove the concept and

develop knowledge on the applicability and the future scalability of the concept.

By implementing use case 2, DSO/CPO/involved aggregators will gain an in-depth

understanding on how flexibility can be managed between DSOs and multiple aggregators

and how the required systems should interact.

By implementing use case 2, the involved aggregators can validate the maturity (and

shortcomings) of communication chain and its protocols, so we can propose changes and

extensions to the relevant standardization bodies.

4.3. Use case 3

Scope

Validating technically, economically and contractually the usability of an integrated flex

market based on a combination of static battery storage and EV chargers.

Multiple Aggregators offer flexibility from different flexibility sources (Smart Storage Unit,

EV chargers) on a flexibility market so that the DSO can procure flexibility from multiple

parties for grid supporting services (e.g. congestion management). All contracts and

transactions needed for the procurement of flexibility will be described. Furthermore,

agreements between the parties about the availability of energy flexibility services will be

described in a service level agreement (SLA). The needed contracts, transactions and SLAs

will be formed in the implementation of this use case.

Out of scope:

Other ancillary services

Objectives

By implementing use case 3, DSO and involved aggregators test and validate a technical

framework for trading flexibility between multiple aggregators and DSO in order to prove

the concept and develop knowledge on the applicability and the future scalability of the

concept.

By implementing use case 3, DSO and involved aggregators will gain an in-depth

understanding on how flexibility can be traded between DSO and multiple-Aggregators and

how the required contracts and transactions can be formed and handled.

By implementing use case 3, the involved aggregators can validate the proposition for trading

flexibility for multi-goal to multi-party(e.g. congestion management + spot market trading).

Therefore, gain knowledge on the monetary value of flexibility for their business.

D7.1 & D7.2


Figure 12 - InterFlex top level architecture (use case sections)

5. DISTRICT ARCHITECTURE

5.1. Smart Grid Architecture Model

SGAM

Smart grid projects often have relatively complicated architecture models, due to the wide

diversity of topics that need to be covered (e.g. physical infrastructure, information

technology infrastructure, interfacing with different partners). In order to provide a uniform

representation of the high-level architecture over the various topics, the smart grid

architectural model (SGAM) is used.

SGAM utilizes a three dimensional model, with a two dimensional base field. This base pane

covers the different domains and zones of the power system. On the horizontal axis the five

domains are covering the electrical energy conversion chain (bulk generation, transmission,

distribution, DER, and customer premises), and on the vertical axis zones are representing

the hierarchical levels for management of the power system (process, field, station,

operation, enterprise, and market) [12].

GMSGrid Management System


Management System

CPMSCharge Point

Management System




StorageOperator

Charge Point

Operator

Distr. System

Operator

Aggre-gator




Aggre-gator

Aggre-gator

Central battery

PVOwner

PVsystem

SolarV2G

Solar car

Community

StrijpDC houses






Charge point

Datalake

Use case 2

Use case 1

Use case 3

D7.1 & D7.2


The third dimension is created by adding various layers, describing the aspects of a smart

grid. The bottom field provides the physical infrastructure of the smart grid (component

layer), the remaining layers are covering the communication protocols, information

exchange, main functions of clusters of infrastructure, and the business opportunities of the

smart grid [12].

Typically, each smart grid use case can be translated into a SGAM. However, since at WP7’s

demonstration site Strijp-S, use case 3 is the integral market overlaying use case 1 and 2, a

single model for the SGAM is chosen. In this model, the differentiation on use case level is

made for the component layer to demonstrate the difference in the infrastructural scope of

the use cases. The remaining layers are integrally described, as the principle information is

the same for the various use cases (just with a different scoping regarding the components).

One additional remark should be made. In order to ensure readability of the SGAM diagrams,

it is chosen to not explicitly add interactions with roles and systems in the generation,

transmission and customer premises domains, as these roles and systems are not part of the

design of InterFlex, but rather an implied given. To illustrate this with an example,

interactions between FAP and BRP or day-ahead market (DAM) are not included in the SGAM.

It is assumed the responsibility of the FAP to have this information as a given.

Component layer

In the process zone of the distribution domain, a simplified representation of the MV and LV

network on the demonstration site are visualized. On various locations in the distribution

network (feeders, MV/LV transformer) distribution automation systems are integrated (DA &

DALI). Section 5.2 elaborates further on these systems and the measurements taken, and

the specific locations of these measurements. This distribution network continues into the

DER domain, where the DER are connected.

The various devices in the process zone (both the distribution automation systems of the

distribution domain, and the inverters and charge points in the DER domain) are

communicating with the outside world using remote terminal units (RTUs) or controllers.

In the distribution domain, these RTUs are connected to the operational systems of the DSO.

For the demonstration on Strijp-S, these operational systems are providing the GMS with

measurements in the distribution level.

In the DER domain, the RTUs are connected to the LIMS (use case 1 & 3) and to the CPMS

(use case 2 & 3). The LIMS & CPMS and the GMS are connected through a commercial

aggregator party, using the system called the flexibility aggregator platform (FAP).

Figure 13, Figure 14, and Figure 15 show the SGAM component layer for use case 1, use case

2, and use case 3 respectively.

D7.1 & D7.2


Use case 1

Figure 13 – SGAM component layer use case #1

D7.1 & D7.2


Use case 2

Figure 14 - SGAM component layer use case #2

D7.1 & D7.2


Use case 3

Figure 15 - SGAM component layer use case #3

D7.1 & D7.2


Communication layer

In the communication layer (Figure 16), two types of standards can be distinguished. On the

one hand, a standard dictating the means of communication (the carrier, or the ‘how’) is

described, on the other hand the standard dictating the messages exchanged (the content,

or the ‘what’ and ‘when’).

Between the different systems within the operation, enterprise, and market zones, the

communication carrier applied is Ethernet TCP/IP, both within a local network and over the

internet. The DSO communicates with the distribution automation systems over the GRPS

network, as does the CPMS with the underlying charge points.

As both DSO/distribution automation and the CPMS/charge points interaction are developed

systems, the standards for the necessary exchange of messages is also known already. For

the DSO/distribution automation, IEC 60870-5-104 is applied. The CPMS and charge points

communicate with OCPP. The market framework implemented between GMS, FAP and

LIMS/CPMS is USEF (see [13]for more information on USEF).

The interaction between LIMS and the underlying DER (or flexibility sources) is mostly

undefined. This depends mostly on the choice of the DER in question, and will be part of the

design process of the LIMS. Future scaling to a larger set of different types of flexibility

source most likely forces support for a variety of protocols to be implemented in the LIMS,

especially since DER at this time do not have a universally adapted standard interface [14].

Information layer

Figure 17 shows the SGAM information layer. The for the demonstration site relevant

information exchange takes place in the station zone and above. Through the distribution

automation systems, measurement data (15 minute averaged values) are provided to the

operational systems of the DSO. The GMS is able to obtain these measurements up to the

PTU before the currently active one (t-1).

Between GMS, FAP and CPMS/LIMS the information exchange is related to the sequence

diagram. More information on the sequence diagram can be found in Appendix 1 – Use case

diagrams. The information exchange between CPMS and LIMS, and connected CPs and DER

(i.e. SSU and PV installation) is in turn information regarding load profiles and

measurements.

D7.1 & D7.2


Figure 16 - SGAM integral communication layer

D7.1 & D7.2


Figure 17 - SGAM integral information layer

D7.1 & D7.2


Function layer

Figure 18 visualises the function layer. Components and systems are here clustered into high-

level functional blocks, resulting in four blocks. The operational system and infrastructure

of the DSO provides in data acquisition necessary for the function of the GMS.

The GMS has as main function to procure flexibility for grid management purposes. The grid

management purposes within this demonstration are congestion management and voltage

support.

This flexibility is obtained through the FAP systems of the commercial aggregators. This FAP

has as function to aggregate flexibility/DER, and trade this flexibility. Within the scope of

the demonstration, this trading is done with the DSO, however this can also be the TSO, BRP

and/or energy markets.

The LIMS and CPMS are providing the FAP with the flex sources, resulting in a main function

to control those flex sources (DER control).

Business layer

The top layer of the SGAM (Figure 19, the business layer) distinguishes three actors, directly

involved in the scope of WP7. These actors are the distribution system operator, commercial

aggregator, and local aggregator (see section 3.3 for a definition of these actors). Between

those actors two main business transactions can be distinguished, namely flex trading

between DSO and commercial aggregator, and flex asset provision & procurement between

commercial- and local aggregator.

D7.1 & D7.2


Figure 18 - SGAM integral function layer

D7.1 & D7.2


Figure 19 - SGAM integral business layer

D7.1 & D7.2


5.2. Distribution grid topology

In the SGAM diagrams, a simplified representation of the distribution grid of the

demonstration site Strijp-S is given. In order to give a more complete overview of size of the

distribution grid onsite, the measured substations and their capacity & outgoing LV feeders,

and geographical distribution a concise overview is presented in this section.

As the SGAM overview visualises, Enexis distinguishes two levels of substation automation,

namely Distribution Automation (DA) and Distribution Automation Light (DALI). Within the

scope of InterFlex, both systems provide measurement data of the respective substation

transformers (LV side) and outgoing LV feeders.

Distribution Automation provides Enexis’ control centre with (near) real time measurements

and remote operation possibilities. Furthermore, 15 minutes averaged measurements are

provided of the following parameters [15]:

Phase voltage (single phase to neutral)

Phase currents (all phases)

Total active power

Total reactive power

DA is installed in (for Enexis) strategic MV substations, potentially on both transformer and

outgoing feeders. The remaining MV substations are eligible for Distribution Automation

Light. In contrast to DA, DALI does not provide remote operation possibilities or (near) real

time field measurements. DALI only provides in 15 minutes averaged measurements, which

are taken for a broader parameter set, namely:

Phase voltage (all phases to neutral)

Phase currents (all phases)

Active power (per phase and total)

Reactive power (per phase and total)

Energy (bi-directional)

THD (per phase current)

In order to provide an insight of the locations for which measurement equipment is installed,

the distribution grid on the demonstration location needs to be introduced first. In the

Netherlands, MV distribution grids are typically designed as a ring structured network.

Operation of these networks is however mostly done based on a radial structure, with an

open point at a predefined point in the ring structure [16].

Figure 20 gives a generic overview of a typical Dutch MV network. Transmission cables

connect the local MV substation with the HV transmission grid through a HV/MV substation.

From this MV substation, various ring networks with normally open point feed the LV

networks through MV/LV distribution stations [17]. These distribution stations can be either

in the public domain (the network on the secondary side of the station is directly operated

by the DSO) or in the private domain (the connected customer has responsibility for the

network at the secondary side of the substation).

D7.1 & D7.2


Figure 20 - Generic overview of Dutch MV networks, distinguishing MV transmission and

distribution cables, and MV substations & (MV/LV) distribution stations. Figure from [17]

This radially operated ring structure with normally open points is also applicable in the case

of the demonstration location Strijp-S. In the area of Strijp-S, four MV rings can be

distinguished, of which one is responsible for the majority of the connected loads. The MV

rings are not entirely limited to the geographical location of Strijp-S, but in some occasions,

surpass this area. This is the result of historical design choices in this area [18].

Figure 21 gives a schematic overview of the MV distribution network of the demonstration

site Strijp-S, while Figure 22 visualises the geographical location of the stations within the

demonstration location Strijp-S.

On the left-hand side of Figure 21, the MV substation’s busbar is visualised, with the outgoing

MV distribution feeders and corresponding distribution stations. Each of the outgoing feeders

(the orange arrows in Figure 21) from the MV substation will be equipped with DA, providing

measurement data on the MV respective feeder. Within the main feeding ring, an additional

three substations (the orange circles in Figure 21) are selected as strategic distribution

stations, and are therefore also equipped with DA. In these three stations, the outgoing LV

feeders are measured with DALI. Furthermore, 30 stations (both in the public and private

domain) are equipped with a DALI measurement installation. DALI is also installed in the

distribution stations outside of the Strijp-S geographical area, but within the MV ring.

D7.1 & D7.2


Figure 21 - Schematic overview of the MV network of Strijp-S

D7.1 & D7.2


Figure 22 - Geographical overview of the MV network of Strijp-S (red marked area)

Without going into the detail of the physical LV network of Strijp-S, a number of key

indicators of the network beyond the (MV/LV) distribution stations is given in Table 2. This

table summarizes all the stations equipped with DA(LI) measurements, and indicates the

total rated power of the distribution station, whether the station is in the public or private

domain, how many outgoing LV feeders the station has (and the amount of those which is a

dedicated feeder for a single, large, customer). Data from [18]. Another of the indicators is

the number of connected customers per distribution station. For Strijp-S this is typically a

mix of households (mostly apartment buildings) and SMEs.

The vast majority of the LV network consists of 150mm2 aluminium cables. This leads to a

theoretical maximum current per feeder of 250A, which is the maximum sizing of the fuse

dictated by design policy [19]. The practical maximum is not determined for each individual

feeder, but will be limited to those feeders in which flexibility sources are included within

the scope of InterFlex. At this time, those locations are not yet known.

D7.1 & D7.2


Table 2 - MV/LV substations equipped with DA(LI) measurements, including information on

type of substation, rated power, outgoing feeders (including dedicated), and number of connected customers

Substation name Type (public/private)

Σ Rated power

Outgoing feeders

Of which dedicated

Connected customers

Comment

Anton Oost Public 630 kVA 9 4 80 Anton West Public 630 kVA 11 5 79 Beukendael Public/Private 1260 kVA 1 1 2 Bouwaansluiting Space S

Private 400 kVA N/A N/A 1 To be disbanded#

Evoluon Private 1390 kVA N/A N/A 1 Evoluon koude Private 400 kVA N/A N/A 1 Gerard Oost Public 630 kVA 7 0 79 Ir Kalfstraat Public 630 kVA 8 1 214 Larixplein Public 400 kVA 6 1 228 Laboratoriumstraat Public 630 kVA 5 0 171 Nieuw Lucas College Private 1000 kVA N/A N/A 1 Nieuw Space-S Public T.b.d. T.b.d. T.b.d. 402 Planned Philips Natlab Private 630 kVA N/A N/A 1 PopEi Private 400 kVA N/A N/A 1 Provisorium Strijp Public 630 kVA 2 0 1 SAU-B2 Public 630 kVA 6 4 9 SBP Public 630 kVA 6 1 86 SEU-Philips Private 800 kVA N/A N/A 1 SEY-Philips Private 630 kVA N/A N/A 0* SFF-Philips Private 1260 kVA N/A N/A 1 SFH1-Philips Private 4230 kVA N/A N/A 0* SFH2-Philips Private 2000 kVA N/A N/A 0* SFH4 Private 630 kVA N/A N/A 0* SFJ-Philips Private 1000 kVA N/A N/A 1 SFS-Philips Private 2000 kVA N/A N/A 1* SK Public 630 kVA 1 0 2 Spoorzone Public 630 kVA 5 0 137 Planned SWA-Philips Private 400 kVA N/A N/A 1 SX-Philips Private 400 kVA N/A N/A 1 Trudo Monumenten C3

Private 2000 kVA N/A N/A 1

Veemgebouw 1 Public 630 kVA 8 6 86 Veemgebouw 2 Private 250 kVA 2 2 2 WKO DEC KLOKGEBOUW

Private 630 kVA N/A N/A 1

*) MV ring with marked substations are administratively a single point of connection with

one EAN-code #) Temporary connection facilitating the construction site

D7.1 & D7.2


6. RISK MANAGEMENT

Risk management is this project is done according the risk management dashboard supplied

by the overall InterFlex project organisation.

Ongoing the project we identified a few other risks. These are:

ID RF Risk factors Short nameProbabilit

y

Value of

probabilityImpact

Value of

impactCriticality (P x I)

Level

of risk

Risk

Respons

e

Mitigation action

GA_R

_WP7

_11

Acceptance of batteries from

local authorities and local

stakeholders

Regulation Low 1 High 5 5Mediu

m

Preventi

onInform and raise awareness

GA_R

_WP7

_12

Safety risk Effect of failure:

Impact on goods and persons

Severity: High Probability:

Low

Safety Low 1 High 5 5Mediu

mavoid Having a storage operator

GA_R

_WP7

_13

Technical risk Effect of failure:

The new functionalities of the

battery-based storage

system do not perform as

expected Severity: Medium

Probability: Low

Technical issues low 1 medium 3 3 LowPreventi

on

Tests of new functionalities in the test

platform of Enexis before the

demonstration in Eindhoven

GA_R

_WP7

_14

Low recruitment of customers

(EV-users) challenging the

meaningfulness of results

Customers'engage

mentHigh 5 Medium 3 15 High

Preventi

on

Motivation plan : targeted recruitment

campaign, raise awareness compare

date with other groups

GA_R

_WP7

_15

Low engagement of

participants, resulting in the

reduction of the demo's

impact

Customers'engage

mentLow 1 Medium 3 3 Low

Mitigatio

n

Motivation plan : targeted recruitment

campaign, raise awareness compare

date with other groups

GA_R

_WP7

_16

Technical risk regarding the

new functionalities of the

battery-based storage

(system would not perform as

expected)

Technical issues Low 1 Medium 3 3 LowMitigatio

n

Tests of the charge modulation (smart

charging) in the test platform of ElaadNL

before the demonstration in Eindhoven

GA_R

_WP7

_17

Complexity of the flexibiity

aggregator platform (FAP)

Technical

complexityLow 1 Medium 3 3 Low

Preventi

on

Tests of the FAP in the test platform of

ElaadNL before the demonstration in

Eindhoven

GA_R

_WP7

_18

Complexity of the flexibiity

aggregator platform (FAP)

combining two sources and

aggregators

Technical

complexityLow 1 Medium 3 3 Low

Preventi

on

Tests of the FAP in the test platform of

ElaadNL before the demonstration in

Eindhoven

ID Risk title Description of risk Probability Impact Impact description Risk management (prevention) plan Risk response

Weight

(probability

*impact)

R_WP7_1 Consumer involvement

Getting the consumers involved in the project to get

actual data 30 4 High impact

Involvement of Strijp_S

communities en mundicipals to

get cunsumers profiles. reduce 120

R_WP7_2

Contracting subcontractors in relation with

tender regulation Enexis

Defining detailed specifications and also tender on

these for actual design isn's allowed in the standard

procedure of Enexis. 100 4 High impact

Defining alternative methode

with legal and purchaser. Exploit 400

R_WP7_3 Contribution Enexis specialists. Deploiment of Enexis specialists in the project 30 5 High impact Time managment en prioritaion Exploit 150

R_WP7_4 Delivery of SSU Delivery time of SSU is longer then expacted 100 2 Low impact Accept 200

D7.1 & D7.2


7. REFERENCES

[1] Smart Grid Task Force, “Regulatory Recommendations for the Deployment of Flexibility - EG3 REPORT,” 2015.

[2] F. de Zeeuw, “CPB miskent economisch belang Brabant,” E.D., 2010. [Online]. Available: http://www.ed.nl/mening/cpb-miskent-economisch-belang-brabant~aab7988a/. [Accessed: 23-Aug-2017].

[3] Eindhoven, “Eindhoven in Cijfers.” [Online]. Available: https://eindhoven.buurtmonitor.nl/jive/. [Accessed: 10-Aug-2017].

[4] Strijp-S, “Strijp-S Ontwikkeling.” [Online]. Available: http://strijp-s.nl/nl/ontwikkeling. [Accessed: 10-Aug-2017].

[5] J.-H. Hoepman, “Privacy Design Strategies,” in ICT Systems Security and Privacy Protection, 428th ed., Springer, 2014, pp. 446–459.

[6] European Commission, “Sustainable Transport Forum (STF) - European Commission.” [Online]. Available: https://ec.europa.eu/transport/themes/urban/cpt/stf_en. [Accessed: 28-Aug-2017].

[7] COTEVOS, “Business Opportunities for Interoperability Assessment of EV Integration,” 2016.

[8] USEF foundation, “Usef Energy – Universal Smart Energy Framework.” [Online]. Available: https://www.usef.energy/. [Accessed: 28-Aug-2017].

[9] Open Charge Alliance, “Open Smart Charging Protocol 1.0.” [Online]. Available: http://www.openchargealliance.org/protocols/oscp/oscp-10/. [Accessed: 28-Aug-2017].

[10] Flexiblepower Alliance Network, “Energy Flexibility Interface.” [Online]. Available: https://fan-ci.sensorlab.tno.nl/builds/fpai-documentation/development/html/EFI.html. [Accessed: 31-Aug-2017].

[11] eMI3, “Scope & Objectives | eMI3.” [Online]. Available: http://emi3group.com/objectives/. [Accessed: 28-Aug-2017].

[12] CEN/CENELEC/ETSI Joint Working Group on Standards for Smart Grids, “CEN-CENELEC-ETSI Smart Grid Coordination Group: Smart Grid Reference Architecture,” 2012.

[13] U. Foundation, “USEF: The Framework Explained,” Brussels, 2015. [14] M. Van Den Berge, M. Broekmans, B. Derksen, A. Papanikolaou, and C. Malavazos,

“Flexibility provision in the Smart Grid era using USEF and OS4ES,” in 2016 IEEE International Energy Conference, ENERGYCON 2016, 2016.

[15] Enexis, “Eza-2001.R Distributie Automatisering binnen MS-infrastructuur Enexis,” 2016.

[16] P. van Oirsouw, Netten voor distributie van elektriciteit. Arnhem: Phase to phase, 2011.

[17] M. O. W. Grond, “Computational Capacity Planning in Medium Voltage Distribution Networks,” Eindhoven University of Technology, 2016.

[18] D. Sijberden, “Interflex Strijp-S selectie stations DA/DALI,” 2017. [19] Enexis, “Eea-0204.K Ontwerpkaders LS&OV,” 2017. [20] A. Ovans, “What Is a Business Model?,” 2015. [Online]. Available:

https://hbr.org/2015/01/what-is-a-business-model. [Accessed: 31-Aug-2017].

Document Title


8. APPENDICES

8.1. Appendix 1 – Use case diagrams

For detailed description of the use case diagrams below see the three use case WP7 documents. Abbreviations: BRP = Balance Responsible CPMS = Charge Point Management System FAP1 = Flexibility Aggregator Platform (with EV contract) FAP2 = Flexibility Aggregator Platform (with Battery contract) GMS = Grid Management System LIMS = Local Infrastructure Management System OCPP = Open Charge Point Protocol OCPI = Open Charge Point Interface SSU = Smart Storage Unit

Use case 1

Document Title


Diagram of the use case

Figure 23 – Diagram Use case 1 – Improve grid flexibility using Central Storage Unit

Sequence diagrams

Smart Storage Unit is charged by local solar system:

Document Title


LIMSSSU

1) Update SSU Status (available)

6) Control Signal (charge)

Update SSU Status

Control Signal (charge)

7) Update SSU Status (full)

Use case 1 Scenario PS1 – SSU is charged by PV

FAP

4) Flex Offer

2) UC 3 step 4 - Update SSU Status (available)

5) UC 3 step 18 - Send Power File

Option 1:

Option 2:

8) UC 3 step 4 - Update SSU Status (full)

GMSSee also UC 3

PV system

3) Flex Offer

Update PV status

9) UC 3 step 8 - Validate Energy Prognosis

Figure 24 –Sequence diagram use case 1 – SSU is charged by PV

Table 3 – Steps sequence diagram – SSU is charged by PV

Scenario Name :

Step No.

Event Description of Process/Activity

Information Producer

Information Receiver

Information Exchanged

Service Requirements

Communication Media

Communication Means

1 Update SSU Status (available)

The SSU sends its latest status information towards the LIMS.

SSU LIMS SSU Status Update

Get Security, Privacy,

GPRS SSU specific


Use case 3 step 4: The LIMS sends its latest status information towards the FAP. With this information the FAP creates an expected power consumption profile (A-prognosis).

LIMS FAP SSU Status Update


Fibre Protocol (e.g. OpenADR or EFI)

3 Flex Offer The PV system has flexibility available and sends an offer to the LIMS.

PV system

LIMS Flex Offer Get Security, Privacy,

Fibre PV specific

4 Flex Offer The LIMS sends its latest status information towards the FAP. With this information the FAP creates an expected power consumption profile (A-prognosis).

LIMS FAP Flex Offer Get Security, Privacy,

Fibre Protocol (OpenADR or EFI)

Document Title


Scenario Name :

Step No.






Communication Media

Communication Means

5 Send Power File

Use case 3 step 18: The FAP sends the power consumption for the next period to the LIMS

FAP LIMS Power Profile Allocation

Create Security, Privacy,


6 Control Signal (charge)

The LIMS sends a control signal to the SSU to start charging

LIMS SSU Control signal


GPRS SSU specific

7 Update SSU Status (full)




GPRS SSU specific






9 Validate Energy Prognosis

Use case 3 step 8: The FAP sends the expected power consumption profile for congestion area 1 (Energy prognosis) to the GMS.

FAP GMS Energy prognosis


Fibre Protocol (e.g. USEF)

Smart Storage Unit is charged by supplier (flex request):

Use case 1 Scenario PS2 – SSU is charged by Supplier (flex request)

LIMSSSU FAPGMS

See also UC 3PV system

1) Update SSU Status (available)2) UC 3 step 4 - Update SSU Status (available)

3) Flex Request (for SSU)

4) Confirmation5) UC 3 step 18 - Send Power File

6) Control Signal (charge)

7) Update SSU Status (full)

8) UC 3 step 4 - Update SSU Status (full)


Figure 25 –Sequence diagram use case 1 – SSU is charged by supplier (flex request)

Document Title


Table 4 – Steps sequence diagram – SSU is charged by supplier (flex request)

Scenario Name :

Step No.






Communication Media

Communication Means





GPRS SSU specific






3 Flex request (for SSU)

The FAP sends a flex request to the GMS for charging the smart storage unit (t solve a problem)

FAP GMS Flex Request



4 Confirmation The GMS sends a confirmation of the flex request

GMS FAP Confirmation



5 Send Power File





6 Control Signal (charge)


LIMS SSU Control signal


GPRS SSU specific





GPRS SSU specific

8 UC 3 step 4 - Update SSU Status (full)





9 UC 3 step 8 - Validate Energy Prognosis





Voltage support:

Document Title


LIMSSSU FAPGMS

See also UC 3

8) Update SSU Status (empty) 9) UC 3 step 4 - Update SSU Status (empty)


Use case 1 Scenario PS3 – Voltage support

1) UC 3 step 11 - Flex Request

2) UC 3 step 13 - Flex Offer

3) UC 3 step 14 - Flex Procurement

4) UC 3 step 18 - Send power file

5) Update SSU Status (discharging)

6) Control Signal (discharge)


Total SSUCritical

boundary

PV system

Figure 26 –Sequence diagram use case 1 – Voltage support

Table 5 – Steps sequence diagram – Voltage support

Scenario Name :

Step No.






Communication Media

Communication Means

1 Flex request

Use case 3 step 11: The DSO sends a Flex request to FAP in order to request flexibility during the expected congestion period.

GMS FAP Flex Request



2 Flex Offer Use case 3 step 13: The FAP has flexibility during the expected congestion period and sends an offer to the DSO.

FAP GMS Flex Offer Create Security, Privacy,


3 Flex Procurement

Use case 3 step 14: The DSO evaluates the received flex offers, determines that FAP offered flexibility the cheapest. So the DSO sends a flex procurement message to FAP.

GMS FAP Flex Procurement



4 Send Power File





Document Title


Scenario Name :

Step No.






Communication Media

Communication Means

5 Update SSU Status (discharging)





6 Control Signal (discharge)

The LIMS sends a control signal to the SSU to start discharging

LIMS SSU Control Signal


GPRS SSU specific





GPRS SSU specific

8 Update SSU Status (empty)




GPRS SSU specific











Power quality:

Document Title


LIMSSSU FAPGMS

See also UC 3

8) Update SSU Status (empty) 9) UC 3 step 4 - Update SSU Status (empty)


1) UC 3 step 11 - Flex Request

2) UC 3 step 13 - Flex Offer

3) UC 3 step 14 - Flex Procurement

4) UC 3 step 18 - Send power file


6) Control Signal


Critical boundary

Inverter

Use case 1 Scenario PS4 – Power Quality

PV system

Figure 27 –Sequence diagram use case 1 – Power quality

Table 6 – Steps sequence diagram – Power quality

Scenario Name :

Step No.






Communication Media

Communication Means

1 Flex request

Use case 3 step 11: The DSO sends a Flex request to FAP in order to request flexibility during the expected congestion period.

GMS FAP Flex Request



2 Flex Offer Use case 3 step 13: The FAP has flexibility during the expected congestion period and sends an offer to the DSO.

FAP GMS Flex Offer Create Security, Privacy,


3 Flex Procurement

Use case 3 step 14: The DSO evaluates the received flex offers, determines that FAP offered flexibility the cheapest. So the DSO sends a flex procurement message to FAP.

GMS FAP Flex Procurement



4 Send Power File





Document Title


Scenario Name :

Step No.






Communication Media

Communication Means






6 Control Signal


LIMS SSU Control Signal


GPRS SSU specific





GPRS SSU specific





GPRS SSU specific











Use case 2


Document Title


Figure 28 – Diagram Use case 2 – Improve grid flexibility using EV

Sequence diagram

Document Title


If: User preferences known

FAPCPMSGMS

See also UC 3

Use case 2 Scenario PS1/AS1 – EV user preferences allows flexibility

Charge point

4) SetChargingProfile(OCPP)

2) UC 3 step 1 - Update EV Status (charging)(OCPI)

3) UC 3 step 19 - Send Power File*(OCPI)


1) Start Transaction(OCPP)

UC 3 step 7-10-12‘Flex agreement’

6) Stop Transaction(OCPP) 7) UC 3 step 1 - Update EV Status (finished)

(OCPI)

5) Metering values(OCPP)

User preferences

* For Vehicle2Grid the same method applies, only charge direction is inverted

Figure 29 –Sequence diagram use case 2 – EV use preferences allows flexibility

Table 7 – Steps sequence diagram – EV use preferences allows flexibility

Scenario Name :

Step No.






Communication Media

Communication Means

1 Start Transaction

EV user connects his EV to a charge point and initiates a charging session

Charge Point

CPMS Charge status

Create (transaction)

EV connected

GPRS/Network cable

OCPP

2 Update EV Status (charging)

Use case 3 step 1: The CPMS sends its latest status information towards the FAP. With this information, the FAP creates an expected power consumption profile (A-prognosis).

CPMS FAP EV Status Update



3 Send Power File


FAP CPMS Power Profile Allocation



Document Title


Scenario Name :

Step No.






Communication Media

Communication Means

4 SetChargingProfile

CPMS transmits a charging schedule to charge point

CPMS Charge Point

Charge schedule

Change (schedule)

Transaction ongoing

GRPS/Network cable

OCPP

5 Metering Values

Charge point periodically transmits charging session metering values

Charge Point

CPMS Meter values

Report Transaction ongoing

GRPS/Network cable

OCPP

6 Stop Transaction

EV user ends a charging session at the charge point and disconnects the EV

Charge Point

CPMS Charge status

Change (transaction finished)

Transaction ongoing

GRPS/Network cable

OCPP

7 Update EV Status (finished)

Use case 3 step 1: The CPMS sends its latest status information towards the FAP. With this information, the FAP creates an expected power consumption profile (A-prognosis).

CPMS FAP EV Status Update








Document Title


Use case 3


Figure 30 – Diagram Use case 1 – Usability of an integrated flex market

Sequence diagram

Integrated flex market:

Document Title


Figure 31 –Sequence diagram use case 3 – Integrated Flex Market

Table 8 – Steps sequence diagram – Integrated Flex MarketScenario Name :

Step No.






Communication Media

Communication Means

1 Update EV Status

The CPMS sends its latest status information towards the FAP1. With this information, the FAP1 creates an expected power consumption profile (A-prognosis).

CPMS FAP1 EV Status Update




The FAP1 sends the calculated Energy prognosis to its BRP.

FAP1 BRP1 Energy prognosis



3 Acknowledge Energy prognosis

After validating the Energy prognosis the BRP sends an acknowledgement to the FAP1

BRP1 FAP1 Acknowledgement



4 Update SSU Status

The LIMS sends its latest status information towards the FAP2. With this information, the FAP2 creates an expected power consumption profile (A-prognosis).

LIMS FAP2 SSU Status Update




The FAP2 sends the calculated Energy Prognosis to its BRP.

FAP2 BRP2 Energy Prognosis



6 Acknowledge Energy Prognosis

After validating the Energy Prognosis the BRP sends an acknowledgement to the FAP1




Document Title


Table 8 – Steps sequence diagram – Integrated Flex MarketScenario Name :

Step No.






Communication Media

Communication Means


The FAP1 sends the expected power consumption profile for congestion area 1 (Energy prognosis) to the GMS.

FAP1 GMS Energy prognosis




The FAP2 sends the expected power consumption profile for congestion area 1 (Energy prognosis) to the GMS.

FAP2 GMS Energy prognosis



9 Validate Capacity

The DSO evaluates the expected load on congestion point 1 with the help of its load forecast together with the received Energy prognosis. The DSO determines an expected congestion.

GMS GMS - - Constrains

- -

10 Flex Request

The DSO sends a Flex request to FAP1 in order to request flexibility during the expected congestion period.

GMS FAP1 Flex Request



11 Flex Request

The DSO sends a Flex request to FAP2 in order to request flexibility during the expected congestion period.




12 Flex Offer The FAP1 has flexibility during the expected congestion period and sends an offer to the DSO.

FAP1 GMS Flex Offer Create Security, Privacy,


13 Flex Offer The FAP2 has flexibility during the expected congestion period and sends an offer to the DSO.



14 Flex Procurement

The DSO evaluates the received flex offers, determines that FAP2 offered flexibility the cheapest. So the DSO sends a flex procurement message to FAP2.

GMS FAP2 Flex Procurement



15 Update Energy Prognosis

The FAP2 accepts the flex procurement and updates its power consumption profile.

FAP2 FAP2 - Create Constrains

- -


The FAP2 sends the calculated Energy Prognosis to its BRP.

FAP2 BRP2 Energy Prognosis



17 Acknowledge Energy Prognosis

After validating the Energy Prognosis the BRP sends an acknowledgement to the FAP1




18 Send Power Profile

The FAP2 sends the power consumption for the next period to the LIMS

FAP2 LIMS Power Profile Allocation





FAP1 CPMS Power Profile Allocation



Document Title


Emergency scenario:

Figure 32 –Sequence diagram use case 3 – Emergency scenario

Table 9 – Steps sequence diagram – Emergency scenario

Document Title


Scenario Name :

Step No.






Communication Media

Communication Means

1 Flex Request

The DSO sends a Flex request to FAP1 in order to request flexibility directly (emergency occurred)




2 Flex Request

The DSO sends a Flex request to FAP2 in order to request flexibility directly (emergency occurred)




3 Flex Offer The FAP1 has flexibility during the congestion period and sends an offer to the DSO.



4 Flex Offer The FAP2 has flexibility during the congestion period and sends an offer to the DSO.



5 Flex Procurement

The DSO evaluates the received flex offers, that he needs all the offered flex. So the DSO sends a flex procurement message to FAP1.




6 Flex Procurement

The DSO evaluates the received flex offers, that he needs all the offered flex. So the DSO sends a flex procurement message to FAP2






FAP1 LIMS Power Profile Allocation





FAP2 CPMS Power Profile Allocation



uc planning, district architecture requirements and tested ... · v1.0 30-09-2017 final enexis team...

Documents