uc planning, district architecture requirements and tested ... · v1.0 30-09-2017 final enexis team...
Post on 30-Sep-2020
0 Views
Preview:
TRANSCRIPT
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
D7.1 & D7.2
InterFlex – GA n°731289 Page 2 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
InterFlex – GA n°731289 Page 3 of 66
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
InterFlex – GA n°731289 Page 4 of 66
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
InterFlex – GA n°731289 Page 5 of 66
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
InterFlex – GA n°731289 Page 6 of 66
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
InterFlex – GA n°731289 Page 7 of 66
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
InterFlex – GA n°731289 Page 8 of 66
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
InterFlex – GA n°731289 Page 9 of 66
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
InterFlex – GA n°731289 Page 10 of 66
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
InterFlex – GA n°731289 Page 11 of 66
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
InterFlex – GA n°731289 Page 12 of 66
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
InterFlex – GA n°731289 Page 13 of 66
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
InterFlex – GA n°731289 Page 14 of 66
- 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]).
D7.1 & D7.2
InterFlex – GA n°731289 Page 15 of 66
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
InterFlex – GA n°731289 Page 16 of 66
Figure 1 – Geographical location Strijp-S, Eindhoven (the Netherlands)
Figure 2 – Impression of Strijp-S (figure from [4])
D7.1 & D7.2
InterFlex – GA n°731289 Page 17 of 66
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
InterFlex – GA n°731289 Page 18 of 66
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
InterFlex – GA n°731289 Page 19 of 66
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
InterFlex – GA n°731289 Page 20 of 66
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
InterFlex – GA n°731289 Page 21 of 66
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.
D7.1 & D7.2
InterFlex – GA n°731289 Page 22 of 66
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
InterFlex – GA n°731289 Page 23 of 66
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
InterFlex – GA n°731289 Page 24 of 66
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
InterFlex – GA n°731289 Page 25 of 66
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
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
InterFlex – GA n°731289 Page 26 of 66
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
LIMSLocal Infrastructure
Management System
CPMSCharge Point
Management System
FAP Flexibility Aggregator Platform
ß D-prog/confirmation à Flex request à
E-flex à ß Control signal
StorageOperator
Charge Point
Operator
Distr. System
Operator
Aggre-gator
Interflex NL - roles, systems and communication
FAPFlexibility Aggregator Platform
FAP Flexibility Aggregator Platform
Aggre-gator
Aggre-gator
Central battery
PVOwner
PVsystem
SolarV2G
Solar car
Community
StrijpDC houses
E-flex à ß Control signal
E-flex à ß Control signal
E-flex à ß Control signal
ß D-prog/confirmation à Flex request à
ß D-prog/confirmation à Flex request à
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
InterFlex – GA n°731289 Page 27 of 66
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
InterFlex – GA n°731289 Page 28 of 66
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
InterFlex – GA n°731289 Page 29 of 66
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
InterFlex – GA n°731289 Page 30 of 66
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
InterFlex – GA n°731289 Page 31 of 66
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
InterFlex – GA n°731289 Page 32 of 66
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
LIMSLocal Infrastructure
Management System
CPMSCharge Point
Management System
FAP Flexibility Aggregator Platform
ß D-prog/confirmation à Flex request à
E-flex à ß Control signal
StorageOperator
Charge Point
Operator
Distr. System
Operator
Aggre-gator
Interflex NL - roles, systems and communication
FAPFlexibility Aggregator Platform
FAP Flexibility Aggregator Platform
Aggre-gator
Aggre-gator
Central battery
PVOwner
PVsystem
SolarV2G
Solar car
Community
StrijpDC houses
E-flex à ß Control signal
E-flex à ß Control signal
E-flex à ß Control signal
ß D-prog/confirmation à Flex request à
ß D-prog/confirmation à Flex request à
Charge point
Datalake
Use case 2
Use case 1
Use case 3
D7.1 & D7.2
InterFlex – GA n°731289 Page 33 of 66
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
InterFlex – GA n°731289 Page 34 of 66
Use case 1
Figure 13 – SGAM component layer use case #1
D7.1 & D7.2
InterFlex – GA n°731289 Page 35 of 66
Use case 2
Figure 14 - SGAM component layer use case #2
D7.1 & D7.2
InterFlex – GA n°731289 Page 36 of 66
Use case 3
Figure 15 - SGAM component layer use case #3
D7.1 & D7.2
InterFlex – GA n°731289 Page 37 of 66
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
InterFlex – GA n°731289 Page 38 of 66
Figure 16 - SGAM integral communication layer
D7.1 & D7.2
InterFlex – GA n°731289 Page 39 of 66
Figure 17 - SGAM integral information layer
D7.1 & D7.2
InterFlex – GA n°731289 Page 40 of 66
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
InterFlex – GA n°731289 Page 41 of 66
Figure 18 - SGAM integral function layer
D7.1 & D7.2
InterFlex – GA n°731289 Page 42 of 66
Figure 19 - SGAM integral business layer
D7.1 & D7.2
InterFlex – GA n°731289 Page 43 of 66
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
InterFlex – GA n°731289 Page 44 of 66
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
InterFlex – GA n°731289 Page 45 of 66
Figure 21 - Schematic overview of the MV network of Strijp-S
D7.1 & D7.2
InterFlex – GA n°731289 Page 46 of 66
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
InterFlex – GA n°731289 Page 47 of 66
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
InterFlex – GA n°731289 Page 48 of 66
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
InterFlex – GA n°731289 Page 49 of 66
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
InterFlex – GA n°731289 Page 50 of 66
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
InterFlex – GA n°731289 Page 51 of 66
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
InterFlex – GA n°731289 Page 52 of 66
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
2 Update SSU Status (available)
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
Get Security, Privacy,
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
InterFlex – GA n°731289 Page 53 of 66
Scenario Name :
Step No.
Event Description of Process/Activity
Information Producer
Information Receiver
Information Exchanged
Service Requirements
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,
Fibre Protocol (e.g. OpenADR or EFI)
6 Control Signal (charge)
The LIMS sends a control signal to the SSU to start charging
LIMS SSU Control signal
Create Security, Privacy,
GPRS SSU specific
7 Update SSU Status (full)
The SSU sends its latest status information towards the LIMS.
SSU LIMS SSU Status Update
Get Security, Privacy,
GPRS SSU specific
8 Update SSU Status (full)
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
Get Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
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
Create Security, Privacy,
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)
9) UC 3 step 8 - Validate Energy Prognosis
Figure 25 –Sequence diagram use case 1 – SSU is charged by supplier (flex request)
Document Title
InterFlex – GA n°731289 Page 54 of 66
Table 4 – Steps sequence diagram – SSU is charged by supplier (flex request)
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
2 Update SSU Status (available)
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
Get Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
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
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
4 Confirmation The GMS sends a confirmation of the flex request
GMS FAP Confirmation
Get Security, Privacy,
Fibre Protocol (e.g. USEF)
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,
Fibre Protocol (e.g. OpenADR or EFI)
6 Control Signal (charge)
The LIMS sends a control signal to the SSU to start charging
LIMS SSU Control signal
Create Security, Privacy,
GPRS SSU specific
7 Update SSU Status (full)
The SSU sends its latest status information towards the LIMS.
SSU LIMS SSU Status Update
Get Security, Privacy,
GPRS SSU specific
8 UC 3 step 4 - Update SSU Status (full)
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
Get Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
9 UC 3 step 8 - 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
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
Voltage support:
Document Title
InterFlex – GA n°731289 Page 55 of 66
LIMSSSU FAPGMS
See also UC 3
8) Update SSU Status (empty) 9) UC 3 step 4 - Update SSU Status (empty)
10) UC 3 step 8 - Validate Energy Prognosis
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)
7) Update SSU Status (discharging)
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.
Event Description of Process/Activity
Information Producer
Information Receiver
Information Exchanged
Service Requirements
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
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
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,
Fibre Protocol (e.g. USEF)
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
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
4 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,
Fibre Protocol (e.g. OpenADR or EFI)
Document Title
InterFlex – GA n°731289 Page 56 of 66
Scenario Name :
Step No.
Event Description of Process/Activity
Information Producer
Information Receiver
Information Exchanged
Service Requirements
Communication Media
Communication Means
5 Update SSU Status (discharging)
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
Get Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
6 Control Signal (discharge)
The LIMS sends a control signal to the SSU to start discharging
LIMS SSU Control Signal
Create Security, Privacy,
GPRS SSU specific
7 Update SSU Status (discharging)
The SSU sends its latest status information towards the LIMS.
SSU LIMS SSU Status Update
Get Security, Privacy,
GPRS SSU specific
8 Update SSU Status (empty)
The SSU sends its latest status information towards the LIMS.
SSU LIMS SSU Status Update
Get Security, Privacy,
GPRS SSU specific
9 Update SSU Status (empty)
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
Get Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
10 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
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
Power quality:
Document Title
InterFlex – GA n°731289 Page 57 of 66
LIMSSSU FAPGMS
See also UC 3
8) Update SSU Status (empty) 9) UC 3 step 4 - Update SSU Status (empty)
10) UC 3 step 8 - Validate Energy Prognosis
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
7) Update SSU Status (discharging)
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.
Event Description of Process/Activity
Information Producer
Information Receiver
Information Exchanged
Service Requirements
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
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
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,
Fibre Protocol (e.g. USEF)
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
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
4 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,
Fibre Protocol (e.g. OpenADR or EFI)
Document Title
InterFlex – GA n°731289 Page 58 of 66
Scenario Name :
Step No.
Event Description of Process/Activity
Information Producer
Information Receiver
Information Exchanged
Service Requirements
Communication Media
Communication Means
5 Update SSU Status (discharging)
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
Get Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
6 Control Signal
The LIMS sends a control signal to the SSU to start charging
LIMS SSU Control Signal
Create Security, Privacy,
GPRS SSU specific
7 Update SSU Status (discharging)
The SSU sends its latest status information towards the LIMS.
SSU LIMS SSU Status Update
Get Security, Privacy,
GPRS SSU specific
8 Update SSU Status (empty)
The SSU sends its latest status information towards the LIMS.
SSU LIMS SSU Status Update
Get Security, Privacy,
GPRS SSU specific
9 Update SSU Status (empty)
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
Get Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
10 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
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
Use case 2
Diagram of the use case
Document Title
InterFlex – GA n°731289 Page 59 of 66
Figure 28 – Diagram Use case 2 – Improve grid flexibility using EV
Sequence diagram
Document Title
InterFlex – GA n°731289 Page 60 of 66
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)
8) UC 3 step 7 - Validate Energy Prognosis
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.
Event Description of Process/Activity
Information Producer
Information Receiver
Information Exchanged
Service Requirements
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
Get Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
3 Send Power File
Use case 3 step 19: The FAP sends the power consumption for the next period to the LIMS
FAP CPMS Power Profile Allocation
Create Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
Document Title
InterFlex – GA n°731289 Page 61 of 66
Scenario Name :
Step No.
Event Description of Process/Activity
Information Producer
Information Receiver
Information Exchanged
Service Requirements
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
Get Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
8 Validate Energy Prognosis
Use case 3 step 7: The FAP sends the expected power consumption profile for congestion area 1 (Energy prognosis) to the GMS.
FAP GMS Energy prognosis
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
Document Title
InterFlex – GA n°731289 Page 62 of 66
Use case 3
Diagram of the use case
Figure 30 – Diagram Use case 1 – Usability of an integrated flex market
Sequence diagram
Integrated flex market:
Document Title
InterFlex – GA n°731289 Page 63 of 66
Figure 31 –Sequence diagram use case 3 – Integrated Flex Market
Table 8 – Steps sequence diagram – Integrated Flex MarketScenario Name :
Step No.
Event Description of Process/Activity
Information Producer
Information Receiver
Information Exchanged
Service Requirements
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
Get Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
2 Validate Energy Prognosis
The FAP1 sends the calculated Energy prognosis to its BRP.
FAP1 BRP1 Energy prognosis
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
3 Acknowledge Energy prognosis
After validating the Energy prognosis the BRP sends an acknowledgement to the FAP1
BRP1 FAP1 Acknowledgement
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
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
Get Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
5 Validate Energy Prognosis
The FAP2 sends the calculated Energy Prognosis to its BRP.
FAP2 BRP2 Energy Prognosis
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
6 Acknowledge Energy Prognosis
After validating the Energy Prognosis the BRP sends an acknowledgement to the FAP1
BRP2 FAP2 Acknowledgement
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
Document Title
InterFlex – GA n°731289 Page 64 of 66
Table 8 – Steps sequence diagram – Integrated Flex MarketScenario Name :
Step No.
Event Description of Process/Activity
Information Producer
Information Receiver
Information Exchanged
Service Requirements
Communication Media
Communication Means
7 Validate Energy Prognosis
The FAP1 sends the expected power consumption profile for congestion area 1 (Energy prognosis) to the GMS.
FAP1 GMS Energy prognosis
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
8 Validate Energy Prognosis
The FAP2 sends the expected power consumption profile for congestion area 1 (Energy prognosis) to the GMS.
FAP2 GMS Energy prognosis
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
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
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
11 Flex Request
The DSO sends a Flex request to FAP2 in order to request flexibility during the expected congestion period.
GMS FAP2 Flex Request
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
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,
Fibre Protocol (e.g. USEF)
13 Flex Offer The FAP2 has flexibility during the expected congestion period and sends an offer to the DSO.
FAP2 GMS Flex Offer Create Security, Privacy,
Fibre Protocol (e.g. USEF)
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
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
15 Update Energy Prognosis
The FAP2 accepts the flex procurement and updates its power consumption profile.
FAP2 FAP2 - Create Constrains
- -
16 Validate Energy Prognosis
The FAP2 sends the calculated Energy Prognosis to its BRP.
FAP2 BRP2 Energy Prognosis
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
17 Acknowledge Energy Prognosis
After validating the Energy Prognosis the BRP sends an acknowledgement to the FAP1
BRP2 FAP2 Acknowledgement
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
18 Send Power Profile
The FAP2 sends the power consumption for the next period to the LIMS
FAP2 LIMS Power Profile Allocation
Create Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
19 Send Power Profile
The FAP1 sends the power consumption for the next period to the LIMS
FAP1 CPMS Power Profile Allocation
Create Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
Document Title
InterFlex – GA n°731289 Page 65 of 66
Emergency scenario:
Figure 32 –Sequence diagram use case 3 – Emergency scenario
Table 9 – Steps sequence diagram – Emergency scenario
Document Title
InterFlex – GA n°731289 Page 66 of 66
Scenario Name :
Step No.
Event Description of Process/Activity
Information Producer
Information Receiver
Information Exchanged
Service Requirements
Communication Media
Communication Means
1 Flex Request
The DSO sends a Flex request to FAP1 in order to request flexibility directly (emergency occurred)
GMS FAP1 Flex Request
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
2 Flex Request
The DSO sends a Flex request to FAP2 in order to request flexibility directly (emergency occurred)
GMS FAP2 Flex Request
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
3 Flex Offer The FAP1 has flexibility during the congestion period and sends an offer to the DSO.
FAP1 GMS Flex Offer Create Security, Privacy,
Fibre Protocol (e.g. USEF)
4 Flex Offer The FAP2 has flexibility during the congestion period and sends an offer to the DSO.
FAP2 GMS Flex Offer Create Security, Privacy,
Fibre Protocol (e.g. USEF)
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.
GMS FAP2 Flex Procurement
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
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
GMS FAP2 Flex Procurement
Create Security, Privacy,
Fibre Protocol (e.g. USEF)
7 Send Power Profile
The FAP1 sends the power consumption for the next period to the LIMS
FAP1 LIMS Power Profile Allocation
Create Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
8 Send Power Profile
The FAP2 sends the power consumption for the next period to the LIMS
FAP2 CPMS Power Profile Allocation
Create Security, Privacy,
Fibre Protocol (e.g. OpenADR or EFI)
top related