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 ?