Post on 08-Jan-2016
description
ADDRESS European ProjectIntegration 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
2
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
ADDRESS : what is it ?
ADDRESS : Some results
4
Retailer
BALANCING RESPONSIB LE PARTY
DG & RES
Trader
Centralized Generation
AGGREGATOR
Different levels
of optimization
and aggregation
MARKETS
AND CONTRACTS
Energy Supply
and
provision
of services
TSO
DSO
ADDRESS
adaptation
DMS
ADDRESS
link
adaptation
MV – LV
transfos
Sub
station
Retailer
BALANCING RESPONSIB LE PARTY
DG & RES
Trader
Centralized Generation
AGGREGATOR
Different levels
of optimization
and aggregation
MARKETS
AND CONTRACTS
Energy Supply
and
provision
of services
TSO
DSO
ADDRESS
adaptation
DMS
ADDRESS
link
adaptation
MV – LV
transfos
Sub
station
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 services to the different participants
- Architecture based on the concept of Demand flexibility aggregation
OUR MISSION : Promote Standards, Method and Tools to insure interoperability Keep It Simple !
Promoting and using standards in ADDRESS
TC8 PAS 62559
UML notation
UML « Role Model »
Message Payload : Common Information modelPromote CIM profiles (61970-452/456, 61968-13)
Methodology & Tools
ExpressingtheWHAT
HOWExpressingthe 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
8
time
Power
Negotiation gate closure
Energy payback
Re-profiling volume
Re-profiling duration
Re-profiling availability interval (CRP only)
Re-profiling activation time
(CRP only)
AD Products Conditionality Typical example
Scheduled re-profiling (SRP)
Unconditional (obligation)
The aggregator has the obligation to provide a specified demand modification (reduction or increase) at a given time to the product buyer.
Conditional re-profiling (CRP)
Conditional (option)
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)
Bi-directional conditional re-
profiling (CRP-2)
Conditional (option)
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).
One Business Example before to start Standardized AD products
AD Product/service description:
– power delivery charac.
– “use cases” approach
for the 31 AD services
9
AD PRODUCTΔCdecrease
(MW)
PayBack Effect
t
ΔCdecrease
(MW)
PayBack Effect
t
C decrease
C increase : ex: shift of consumption
Load Area
Macro Load Area
HV/MV subs tation
MV/LV subs tation
Load Area
MV/LV subs tation
Load Area Load Area
ΔCdecrease
(MW)
t
PayBack Effect (MW)
t
Aggregated Curves
C decrease
C increase
10
Interface for external data interchanges
Aggregator
Internal Applications
Energy Box Market …
Message Service Bus : Single Common Semantic for Message Payload
DSO TSOCentralized Producer Retailer
Methodology to leverage interoperability in ADDRESS message exchanges
IEC CIM
11
Interface for external data interchanges
Internal Applications
ADDRESS Actor
12
ADDRESS Actor
Message PayloadsXSD
Encapsulation in servicesWSDL
Plugged IntoESB
API Automated GenerationContract First
Message Service
Bus
Interoperability based on SOA integration
13
Modeling Methodological Framework : 5 Steps
WP4T4.4responsible for 3,4,5
2b
Use CaseDefinition(text)
1 2a
UML Use CaseDefinitions WP1,WP2,WP3, WP5
Find Business Objectsin CIM model orextend CIM
3
CIM-ADDRESS UML Information Model
T4.4 UML needs for Message Payload Definition from WP1, WP2,WP3,WP5IEC WG14 Verb + payload
Define Message Payloads from CIM-ADDRESS4
5
Generate XML XSD
ResultsFrom 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
15
uc Abstract View
Active Demand Buyers
Deregulated Players
Active Demand Providers
Regulated Players
Producers
Intermediaries
Aggregator
Imbalance Management
EnergyBoxMeter
Technical Verification
Market Operations
MarketSystemOperator
Sensitiv ity Matrix Analysis
BalanceResponsibleParty
CentralisedProducer
DecentralisedProducerOrProductionAggregator
ProducerWithRegulatedTariffs
TraderAndBrocker Retailer
LargeConsumer
Consumer
DistributionSystemOperator TransmissionSystemOperator
+send market signals +Offer AD Services
«flow»
1
Coordination for AD Serviceprocurement and technicalfaisabil ity Verification1..*
+Provide AD Services
+dispatch AD activation signals to EnergyBox
«flow»
+deliver AD Products
+send consumer information
+offer other possible services
+Request ADServices
+send market signals
ADDRESS Actors glossary
16
5 Reusable Core Use Casesuc Use cases
Clear AD market
Configure load areas
configuration:
operations:Exchange flexibility
tablesValidate technical
feasibility
Activ ate AD product
17
Configure Load Areas
Load Area
Macro Load Area
HV/MV subs tation
MV/LV subs tation
Load Area
MV/LV subs tation
Load Area Load Area
18
sd Configure load areas
0..*(Aggregator)AGG
1..*(DistributionSystemOperator)DSO
(TransmissionSystemOperator)TSO
loop update
[redefinition of load areas]
CREATED(MacroLoadAreaConfig)
CREATED(LoadAreaConfig)
UPDATED(MacroLoadAreaConfig)
UPDATED(LoadAreaConfig)
UPDATED(LoadAreaConfig)
Configure Load Areas
CREATED(MacroLoadAreaConfig) TSO assigns each (DSOs') load area to a macro load area and communicates this information to the DSOs. Payload: List of macro load areas: - 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 allow the DSO to associate the name with the ID).
CREATED(LoadAreaConfig)
DSO assigns each consumer 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.
20
Clear Active Demand Marketsd Clear AD market
0..*(Aggregator)AGG
(MarketSystemOperator)MSO
0..*(ActiveDemandBuyer)ADBuyer
TSO, DSO
Use cases : Validate technical feasibility
Use cases : Exchange flexibility tables
CREATED(ADBiddingProcess)
CREATED(ADBiddingProcess)
CREATED(DemandADBids)
CREATED(SupplyADBids)
doMarketClearing()
CREATED(ADMarketClearings)
CREATED(ADMarketClearings)
23
Designing common XML structures : CIM Message Types
Message Types Message NounLoadAreaConfig MacroLoadAreaConfig
LoadAreaConfigFlexibilityTables TSOFlexibilityTables
DSOFlexibilityTablesADBiddingProcess ADBiddingProcessADSchedules DemandADBids
SupplyADBidsADMarketClearingsAggrClearedADBidsDSOClearedADBidsTSOValidatedADBidsDSOValidatedADBidsADActivation
24
Overview of the CIM-ADDRESS Information Model
class Overview
Network Configuration
IdentifiedObject
ADSchedule
ADBid
+ kind: ADBidKind [0..1]+ product: ADProductKind [0..1]
«enumeration»ADBidKind
supply demand
IdentifiedObject
LoadModel::LoadGroup
IdentifiedObject
LoadModel::EnergyArea
{xor}
«Compound»Common::DateTimeInterval
+ start: AbsoluteDateTime [0..1]+ end: AbsoluteDateTime [0..1]
ADMarketClearing
+ kind: ADMarketClearingKind [0..1]
«enumeration»ADMarketClearingKind
acceptedAsIs acceptedWithModification rejected
IdentifiedObject
ADBidding
+ bidReceivingPeriod: DateTimeInterval [0..1]
«Compound»CurveAxis::CurveAxisSpec
+ name: String [0..1]+ description: String [0..1]+ kind: AxisKind [0..1]+ unitSymbol: UnitSymbol [0..1]+ currencySymbol: Currency [0..1]+ multiplier: UnitMultiplier [0..1]
LoadModel::ConformLoad
LoadModel::NonConformLoad
ConductingEquipment
Wires::EnergyConsumer
LoadModel::ConformLoadGroup
LoadModel::NonConformLoadGroup
LoadModel::LoadArea
LoadModel::SubLoadArea
«enumeration»ADProductKind
srp crp crp2
ADFlexibility
IdentifiedObject
ADBidApplicationPeriod
+ interval: DateTimeInterval [0..1]
IdentifiedObject
ADObject
ADDRESS : ADScheduleDetail
+ADFlexTableQ1
+FlexibilityQ 0..1
+ADFlexTableP1
+FlexibilityP 0..1
+SubLoadArea 1
+LoadGroups 1..*
+LoadArea
1
+SubLoadAreas
1..*
+LoadGroup 0..1
+EnergyConsumers 0..*
+LoadGroup 0..1
+EnergyConsumers 0..*
+ADObjects
0..*
+DsoLoadArea
0..1
+ADBidding
1+ApplicationPeriods
1..*
+ADMarketClearing0..1
+ADBids
1..* +ADBidQ1 +ADScheduleQ 0..1
+ADBidP1 +ADScheduleP 0..1
+ADBids 0..*
+ADBidding 1
+ADObjects
0..*
+TsoLoadArea 0..1
class ADScheduleDetail
IdentifiedObject
ADSchedule
CurveAxis::QuantityAxis
+ spec: CurveAxisSpec [0..1]
CurveAxis::RegularTimeAxis
+ interval: DateTimeInterval [0..1]+ spec: CurveAxisSpec [0..1]+ timeStep: Seconds [0..1]
CurveAxis::QuantityData
+ sequenceNumber: Integer [0..1]+ seriesNumber: Integer [0..1]+ value: Float [0..1]
CurveAxis::SeriesAxis
+ count: Integer [0..1]+ spec: CurveAxisSpec [0..1]
+QuantityAxis
1 +QuantityDatas
1..*
+ADScheduleVolume1
+Volume 0..1+ADScheduleFlexUp
1
+FlexibilityUp 0..1
+ADScheduleFlexDown
1
+FlexibilityDown 0..1
+ADSchedulePrice
1
+Price 0..1
+ADScheduleBPrice
1
+BookingPrice 0..1
+ADScheduleTime
1 +Time
1
+ADScheduleSeries 1
+Series
0..1
25
Building XML schemas (XSD) for ADDRESS Messages Types
class ADScheduleDetail
IdentifiedObject
ADSchedule
CurveAxis::QuantityAxis
+ spec: CurveAxisSpec [0..1]
CurveAxis::RegularTimeAxis
+ interval: DateTimeInterval [0..1]+ spec: CurveAxisSpec [0..1]+ timeStep: Seconds [0..1]
CurveAxis::QuantityData
+ sequenceNumber: Integer [0..1]+ seriesNumber: Integer [0..1]+ value: Float [0..1]
CurveAxis::SeriesAxis
+ count: Integer [0..1]+ spec: CurveAxisSpec [0..1]
+QuantityAxis
1 +QuantityDatas
1..*
+ADScheduleVolume1
+Volume 0..1+ADScheduleFlexUp
1
+FlexibilityUp 0..1
+ADScheduleFlexDown
1
+FlexibilityDown 0..1
+ADSchedulePrice
1
+Price 0..1
+ADScheduleBPrice
1
+BookingPrice 0..1
+ADScheduleTime
1 +Time
1
+ADScheduleSeries 1
+Series
0..1
UML CIM-ADDRESS Information Model
CIMTool Project
XSD for messages types
26
Prototype testing interoperability through SOA + IEC61968-1-2 standards
OpenESBActor1Axis
Actor2AXIS
WebService Interface
Orchestration BPEL
Business Service
IEC61968-1-2IEC61968-1-2
IEC61968-1-2
XML
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
sd Clear AD market
0..*(Aggregator)AGG
(MarketSystemOperator)MSO
0..*(ActiveDemandBuyer)ADBuyer
TSO, DSO
Use cases : Validate technical feasibility
Use cases : Exchange flexibility tables
CREATED(ADBiddingProcess)
CREATED(ADBiddingProcess)
CREATED(DemandADBids)
CREATED(SupplyADBids)
doMarketClearing()
CREATED(ADMarketClearings)
CREATED(ADMarketClearings)
pkg External data exchanges
Use cases
+ Configure load areas
+ Exchange flexibil i ty tables
+ Clear AD market
+ Validate technical feasibil i ty
+ Activate AD product
AD = Active Demand
Player systems
+ ADBuyer
+ AGG
+ DSO
+ MSO
+ TSO
The described use cases are documenting only the external electronic exchanges of data between actors. Interactions with the human actors, as well as the modell ing and timing of internal business processes is out of scope of this model and document; these are the subject of other ADDRESS work packages, and their dedicated use cases.The used UML artefacts are aligned with the IEC TC57 representations.
Field Test=
integration with some
real application
TSO DSO
Aggregator Energy Box
Retailer
market
Centralized Producer
Message Bus : CIM-Address Messages
…
Adapter
APIAdapter
APIAdapter
APIAdapter
API
AdapterAPI
AdapterAPI
AdapterAPI
AdapterAPI
Final Word !
Use Case MANAGEMENT is essential : UC LIFE CYCLEWe 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 ?