ADDRESS European Project
Integration of Active Demand
Eric Lambert, Cyril Effantin, EDF R&D
UCA CIMUg
Prague May 2011
CIM usage, one year after
Active Distribution network with full integration of Demand and distributed energy RESourceS
Agenda
 Introduction
 Methodological working framework
for Interoperable information exchanges
 Results





Role Model
Use Cases Modeling
CIM-ADDRESS Information Model
CIM-ADDRESS XML Messages
Prototype testing interoperability through SOA + IEC61968-1-2 standards
 Conclusion and next steps
2
ADDRESS : what is it ?
ADDRESS : Some results
Some results from the ADDRESS European project:
- Deliver a technical and commercial
framework for the development of Active
Demand and for the market-based
exploitation of its benefits
-
-
Active Demand: active participation of
domestic and small commercial consumers
in system markets and the provision of ADDRESS
link
services to the different participants
adaptation
AGGREGATOR
Different levels
MARKETS
DSO
AND CONTRACTS
MV – LV
of optimization
transfos
and aggregation
Energy Supply
DG & RES
Architecture based on the concept of
Demand flexibility aggregation
and
B
Retailer
provi sion
Trader
of services
ALANCING
R
E SP ONSIB LE
P
Sub
ADDRESS
station
adaptation
DMS
ARTY
TSO
Centralized Generation
OUR MISSION : Promote Standards, Method and Tools to insure interoperability
Keep It Simple !
4
Promoting and using standards in ADDRESS
TC8 PAS 62559
UML notation
Expressing
the
WHAT
UML « Role Model »
Message Payload : Common Information model
Promote CIM profiles (61970-452/456, 61968-13)
Methodology & Tools
HOW
Expressing
the WHAT ?
Expressing the WHAT ?
ADDRESS PROCESS ARCHITECTURE DIAGRAM
Methodological working framework
 From Use Cases down to message modeling
 Leveraging interoperability in communication
between ADDRESS components
One Business Example before to start
Standardized AD products
AD Products
Typical example
Conditionality
Scheduled
Unconditional
re-profiling (SRP) (obligation)
Conditional reprofiling (CRP)
Conditional
(option)
Bi-directional
conditional reprofiling (CRP-2)
Conditional
(option)
The aggregator has the obligation to provide a specified demand
modification (reduction or increase) at a given time to the product buyer.
The aggregator must have the capacity to provide a specified demand
modification during a given period. The delivery is called upon by the
buyer (similar to a reserve service)
The aggregator must have the capacity to provide a specified demand
modification during a given period in a bi-directional range [ -y, x ] MW,
including both demand increase and decrease. The delivery is called
upon by the buyer of the AD product (similar to a reserve service).
Power
Negotiation gate
closure
Re-profiling
activation time
(CRP only)
Re-profiling
volume
time
Re-profiling duration
Re-profiling availability interval (CRP only)
AD Product/service
description:
– power delivery charac.
– “use cases” approach
Energy
payback
for the 31 AD services
8
AD PRODUCT
ΔCdecrease
ΔCdecrease
(MW)
(MW)
C decrease
PayBack
Effect
t
t
PayBack
Effect
C increase : ex: shift of consumption
Aggregated Curves
ΔCdecrease
(MW)
C decrease
Macro Load Area
PayBack Effect
HV/MV substation
(MW)
MV/LV subs tation
MV/LV subs tation
t
t
C increase
Load Area
Load
Area
Load
Area
Load Area
9
Methodology to leverage interoperability in
ADDRESS message exchanges
DSO
TSO
Centralized
Producer Retailer
Message Service Bus : Single Common Semantic for
Message Payload
IEC CIM
Aggregator
Energy Box
Market
…
Interface for external data interchanges
Internal Applications
10
ADDRESS
Actor
Interface for external data interchanges
Internal Applications
11
Message
Service
Bus
ADDRESS
Actor
Interoperability based on SOA integration
Message Payloads
XSD
Encapsulation in services
WSDL
API Automated Generation
Contract First
Plugged Into
ESB
12
Use Case
Definition
(text)
Modeling
Methodological
Framework : 5 Steps
Find Business Objects
in CIM model or
extend CIM
UML Use Case
Definitions WP1,WP2,WP3, WP5
1
2a
2b
3
T4.4 UML needs for
Message Payload Definition
from WP1, WP2,WP3,WP5
IEC WG14 Verb + payload
Define Message Payloads from
4 CIM-ADDRESS
WP4
T4.4
responsible
for 3,4,5
Generate
XML XSD
5
CIM-ADDRESS
UML Information Model
13
Results
From Use Cases down to Message Modeling
 Models
– UML Role Model
– UML Use Cases definition based on IEC TC57 WG14 conventions
– CIM-ADDRESS UML information Model
– XML messages definition for the use cases information exchanges
 Demonstrating Interoperability
– Prototype leveraging SOA + IEC61968-1-2 standards
ADDRESS Actors glossary
Consumer
«flow»
+dispatch AD activation signals to EnergyBox
MarketSystemOperator
+Provide AD Services
«flow»
Meter
EnergyBox
+send market signals
+Offer AD Services
+send consumer information
Market Operations
+Request AD
Services
+offer other possible services
Aggregator
+send market signals
+deliver AD Products
Sensitiv ity Matrix
Analysis
Technical Verification
Imbalance
Management
Active Demand Buyers
Deregulated Players
Intermediaries
BalanceResponsibleParty
LargeConsumer
Regulated Players
TraderAndBrocker
1..*
Coordination for AD Service
procurement and technical
faisability Verification
Retailer
1
Producers
DistributionSystemOperator
TransmissionSystemOperator
CentralisedProducer
DecentralisedProducerOrProductionAggregator
15
ProducerWithRegulatedTariffs
5 Reusable Core Use Cases
uc Use cases
configuration:
Configure load
areas
operations:
Exchange flexibility
tables
Clear AD market
Validate technical
feasibility
Activ ate AD
product
16
Configure Load Areas
Macro Load Area
HV/MV substation
MV/LV subs tation
MV/LV subs tation
Load Area
Load
Area
Load
Area
Load Area
17
Configure Load Areas
sd Configure load areas
(TransmissionSystemOperator)
TSO
(DistributionSystemOperator) 1..*
DSO
(Aggregator) 0..*
AGG
CREATED(MacroLoadAreaConfig)
CREATED(LoadAreaConfig)
loop update
CREATED(MacroLoadAreaConfig)
TSO assigns each (DSOs') load area to a macro load area and communicates this information to the
[redefinition of load areas]
DSOs.
Payload:
List of macro load areas:
UPDATED(MacroLoadAreaConfig)
- macro load area ID and optionally
name
- list of connection points between the DSO's and the TSO's network:
- ID and name (name here could be, for instance, a substation name, or something similar, to
UPDATED(LoadAreaConfig)
allow the DSO to associate the name with the ID).
CREATED(LoadAreaConfig)
DSO assigns each consumerUPDATED(LoadAreaConfig)
to a load area and communicates this information to the aggregators.
Payload:
List of load areas:
- load area ID
- list of consumer connection points to the DSO's network:
- connection point ID only (it is important to not disclose any name to the aggregator).
Note: Names are never communicated here, for the protection of privacy.
18
Clear Active Demand Market
20
Designing common XML structures : CIM
Message Types
Message Types
LoadAreaConfig
FlexibilityTables
ADBiddingProcess
ADSchedules
Message Noun
MacroLoadAreaConfig
LoadAreaConfig
TSOFlexibilityTables
DSOFlexibilityTables
ADBiddingProcess
DemandADBids
SupplyADBids
ADMarketClearings
AggrClearedADBids
DSOClearedADBids
TSOValidatedADBids
DSOValidatedADBids
ADActivation
23
Overview of the CIM-ADDRESS Information Model
cl a ss A DSchedul eDet a i l
C ur v eA xi s::Ser i esA xi s
+Series
+
0..1 +
count: Integer [0..1]
spec: CurveAxisSpec [0..1]
+ADScheduleSeries 1
IdentifiedObject
A DSchedul e
+ADScheduleTime 1
+Time
1
1
1
1
C ur v eA xi s::Regul a r Ti meA xi s
+
+
+
interval: DateTimeInterval [0..1]
spec: CurveAxisSpec [0..1]
timeStep: Seconds [0..1]
1
1
+ADScheduleVolume
+ADSchedulePrice
+ADScheduleBPrice
+ADScheduleFlexUp
+ADScheduleFlexDown
+Volume
0..1
C ur v eA xi s::Q ua nt i t y A xi s
+Price
0..1
+
+BookingPrice
0..1
spec: CurveAxisSpec [0..1]
+QuantityAxis
1
+FlexibilityUp
+FlexibilityDown
1..*
+QuantityDatas
0..1
0..1
24
C
+
+
+
Building XML schemas (XSD) for ADDRESS
Messages Types
cl a ss A DSchedul eDet a i l
C ur v eA xi s::Ser i esA xi s
+Series
+
0..1 +
count: Integer [0..1]
spec: CurveAxisSpec [0..1]
+ADScheduleSeries 1
IdentifiedObject
A DSchedul e
+ADScheduleTime 1
+Time
1
1
1
1
C ur v eA xi s::Regul a r Ti meA xi s
+
+
+
UML CIM-ADDRESS
Information Model
interval: DateTimeInterval [0..1]
spec: CurveAxisSpec [0..1]
timeStep: Seconds [0..1]
1
1
+ADScheduleVolume
+ADSchedulePrice
+ADScheduleBPrice
+ADScheduleFlexUp
+ADScheduleFlexDown
+Volume
0..1
C ur v eA xi s::Q ua nt i t y A xi s
+Price
0..1
+
+BookingPrice
0..1
spec: CurveAxisSpec [0..1]
+QuantityAxis
1
+FlexibilityUp
0..1
+FlexibilityDown
0..1
1..*
+QuantityDatas
C ur v eA xi s::Q ua nt i t y Da t a
+
+
+
sequenceNumber: Integer [0..1]
seriesNumber: Integer [0..1]
value: Float [0..1]
XSD for messages types
CIMTool Project
25
Prototype testing interoperability through
SOA + IEC61968-1-2 standards
OpenESB
Actor1
Axis
Actor2
AXIS
XML
IEC61968-1-2
IEC61968-1-2
IEC61968-1-2
Business
Service
Orchestration BPEL
WebService
Interface
26
Conclusion
Feedback from the regulated package [JOSEBA JIMENO (TECHNALIA)]
Towards Field Tests…
Final word
CIM used for ADDRESS regulated players
(TSO, DSO)
CIM models have been used as input and outputs for:
– State Estimation
– Validation of AD products
– Load area definition
– Generation forecasting
– Etc.
–
–
–
–
–
–
For the State Estimator the following information has been modeled:
Equipment at MV level: ACLineSegment, PowerTransformer,
SynchronousMachine, ComformLoad etc.
Equipment at LV level: Combination of real equipment as in the MV level and
equivalents (EquivalentBranch, EquivalentNetwork, etc.)
Topology for MV and LV using ConnectivityNode and TopologicalNode
Generation forecasts: An extension to CIM has been used as provided by ABB
(QuantityAxis, QuantityData etc)
Measurements: Analog, AnalogValue, Quality etc.
Network state: SvVoltage, SvInjection, SvPowerFlow
Use of CIM for the regulated ADDRESS actors
Advantages of using CIM
– It is a very complete model providing support for
many different applications (from SE to AD
validation)
– UML modeling and the use of CIMTool are very
useful
Issues found
– CIM allows multiple ways of modeling the same
thing. This brings the need to agree between the
different developers about common profiles
– The model is quite complex and it takes some time
to learn it
– The need of XML parsing and RDF navigation can
be resource consuming
How to Implement the WHAT ?
Simulation platform + Field Tests
Stakes
• Minimize Gaps
• Minimize iterative loops
• Field tests requirements
Field Test
=
integration
with some
real
application
TSO
Adapter
DSO
Adapter
Retailer
API
API
API
Adapter
Centralized
Producer
Adapter
API
Message Bus : CIM-Address Messages
API
Adapter
Aggregator
API
Adapter
Energy Box
API
Adapter
market
API
Adapter
…
Final Word !
Use Case MANAGEMENT is essential : UC LIFE CYCLE
We have to distinguish between
– What is/can be done at IEC level
– What is/can be done during interoperability tests conducted by Users
Associations
– What is/can be done during a EUROPEAN PROJECT with Field test
– ADDRESS is the first European FP7 project using CIM
Thanks for your attention
Questions ?