TC 57
Technical Committee 57
POWER SYSTEMS MANAGEMENT AND
ASSOCIATED INFORMATION EXCHANGE
CIM user Group Meeting October 2010 San Francisco
1
TC 57
TC 57 – WG16
Cim Market Extensions for EU
CIM and ENTSO-E Market EDI harmonization
For transmission market EDI
leveraging a Common approach for derivating CIM into
XML exchanged data
EDF prototypes to support it.
Cyril Effantin EDF R&D
cyril.effantin@edf.fr
CIM user Group Meeting October 2010 San Francisco
TC 57
Agenda
Introduction
Aims of the IEC ENTSO-E
Market EDI
standards harmonization
Methodological framework
Short methodology examples
 EDF Prototypes to support the methodology
Conclusion
CIM user Group Meeting October 2010 San Francisco
3
TC 57
ENTSO-E (European Network of
Transmission System Operators for Electricity http://www.entsoe.eu/
 Harmonization Works started in 2005 within IEC-ETSO
collaboration (European Transmission System Operators)
 from July 2009, ETSO is now fully merged into ENTSO-E
ENTSO-E: 42 TSOs from 34 countries
~ 500 million citizen served
650 GW Generation
230 000 km EHV-HV lines
1 500 000 km MV/LV lines
Demand: 3 000 TWh/year
Exchanges: 300 TWh/year
Investments by 2030
for T&D: ~500G€
CIM user Group Meeting October 2010 San Francisco
5
)
TC 57
Strategic targets
 Market unbundling has distributed Business Processes across various
Energy Stakeholders, typically :
 Scheduling
 Capacity allocation and nomination
 Reserve management
 Customer switching
 Settlement Calculations…
 This however requires coordination of standards across stakeholders
 Standardisation is a key element for IT Total Cost of Ownership
reduction through :
 Harmonization of business processes
 Improved component reusability
 Market Interfaces
 Reduced integration costs
CIM user Group Meeting October 2010 San Francisco
7
Aims of IEC - ENTSO-E Market EDI
standards harmonization
TC 57
CIM Market Extension CME creation
Mainly north American vision of the market in 2003
Taking into account European market design : OTC Over the counter market
not modelled
Harmonization benefits
Integrating the European market standard defined by ENTSO-E Market EDI works
into IEC
•
•
•
•
•
•
Harmonized European role model
Enhance IEC standards with business processes
Many business processes already modelled by ENTSO-E
Extensive business exchanged messages
Reuse of the ENTSO-E implementation guides
Building of a working framework based on UN/Cefact specification
Hosting the European profile as IEC international standards
Taking advantage of the standardization community
CIM user Group Meeting October 2010 San Francisco
8
TC 57
How to achieve the convergence work ?
Building of the CME (CIM Market Extensions)
Energy
Market
Scheduling
Operations
Reservation
Financials
North American IEC Profile
2 IEC
WG 16 - 62325
WG14 - 61968
Task forces
WG13 - 61970
CIM
CIM
Market
CIM
Distribution Part
Extensions
Transmission Part
Methodological
Framework
European IEC Profile
ENTSO-E
ENTSO-E
ENTSO-E
ENTSO-E
ESS
ECAN
ERRP
ESP
+
Harmonized ENTSO-E EbIX EFET Role
model
CIM user Group Meeting October 2010 San Francisco
9
The ENTSO-E ebIX EFET Harmonized
Role Model
TC 57
Role Model
Domains:
green: dual responsibility
Clear ETSO responsibility
Red undefined
Roles:
Clear ETSO responsibility
Blue EBix responsibility
Business actor dual responsibility
operates and maintains
Meter
1..n
Meter operator
0..1
Meter administrator
1. Harmonisation of vocabulary
2. Definition of terms
3. Identification of roles and domains
Grid operator
1
Is operated by
Operates
Control entity
1
Part of
1..n
Metering point administrator
1..n
n
Metering grid area
RWEnet
E-ON
RTE
Eltra
Elia
Tennet
REE
NGC
Contains
Metering point
1..n
1..n
0..n
has
Local metering
point
1..n
1..n
Meters
UCTE
Control
area
Control
block
is composed of
1..n
is composed of
n
Coordination
center zone
1..n
is composed of
manages
manages
manages
Is composed of
1..n
1..n
UCTE interconnected group
Is composed of
Maintains meters
Exchange
metering point
0..1
1
Controlled by
administers meter information for
Register
RWEnet
E-ON
RTE
Eltra?
Elia
Tennet
REE
NGC
connects
has
Administrates
Some control balance
areas are under another
and do not report to a
higher control entity than
the first
Seeland (island of
Copenhagen)
Bornholm (DK island
connected to SE)
belong to different
control balance areas
but the same market
balance area
Is composed of
0..n
0..n
Unit
Functional
group
1..n
belong to
Market balance area
(netted) control area exchange
schedule (CAX)
1..n
(Netted) control block exchange schedule
(CBS)
1
1..n
Production
metering point
Consumption
metering point
Controls financially
Balance
group
control area operator
1..n
(netted) inter
block exchange
schedule (CBS)
(netted) inter area exchange schedule
(CAX)
sends invoicing information to
Billing agent
Control block operator
operates
coordination center operator
Netted inter center exchange
schedule (CCT)
Imbalance settlement responsible
may be financially responsible for
collects data from
Market operator
must have
(netted) balance exchange schedule (CAX)
controls
Sends metering information
Is balance responsible for
declares constraints to
Sends metered data
Identification
Functional domains
Reports schedules to
Makes contracts with
Deals within
sends schedules to
Provides
capacity for
Sends finalised schedules to
Sends validated metered data
provides bids to
Metered data collector
Metered Data Responsible
Metered data aggregator
1
Balancing Area
sends schedules to
Receives capacity from
Local market
area
System operator
Trades externally with
Sends data to
Balance responsible party
sends schedule to
Trades internally with
Is composed of
Exchanges cross border capacity (CAS)
Germany
sends schedule to
Capacity
market area
obtains category profiles from
provides available transfer capacity
Profile maintenance party
Pyrennées
(France-Spain)
TenneT
Auction
England Wales
Facilitates
Production responsible party
Consumption responsible party
Supplies to
RTE - RWE
border
Operates
Is contracted with
may have grid usage contract with
Grid access provider
Allocated
capacity area
1
Is contracted with
Provides access to
Market area
CBT
Transmission capacity allocator
Balance supplier
Operates
National area
Certificate area
Common
capacity area
Trade responsible party
1
Has a balance delivery contract with
is contracted with
has a firm energy contract with
Nordpool
ETSO
CBT
Nordpool
France
Germany
Spain
Dutch certificat
market
uses
Party connected to the grid
Identification
Roles of actors
Producer
Consumer
Identification
geographical domains
Grid Connecting Party
CIM user Group Meeting October 2010 San Francisco
Capacity Area
10
TC 57
The ENTSO-E
Market EDI
Role Model
the ENTSO-E concepts behind the scene
Information flow approach
different
An actor
Can have
System operator
Balance responsible party
Imbalance settlement responsible
Control block manager
…
All Roles that are possible may be
found in the ETSO Role Model
ROLES
In the same process
Balance responsible schedule
Allocated capacity schedule
Control block area schedule
Confirmation report
Finalised schedule
Regulation data
Imbalance report
Day ahead scheduling
Intra day
Transits
System operation closure
Metered data aggregation
Imbalance settlement
And he may exchange different types of document
All documents use 100% compatible XML Schemas and DTDs
15
Version 2 Release 0 ETSO Standard Presentation 2005-06
CIM user Group Meeting October 2010 San Francisco
11
TC 57
Example of ENTSO-E Market EDI
UML Business Processes
CIM user Group Meeting October 2010 San Francisco
12
TC 57
How to achieve the convergence work ?
Building of the CME (CIM Market Extensions)
Energy
Market
Scheduling
Operations
Reservation
Financials
North American IEC Profile
2 IEC
WG 16 - 62325
WG14 - 61968
Task forces
WG13 - 61970
CIM
CIM
Market
CIM
Distribution Part
Extensions
Transmission Part
Methodological
Framework
European IEC Profile
ENTSO-E
ENTSO-E
ENTSO-E
ENTSO-E
ESS
ECAN
ERRP
ESP
+
Harmonized ENTSO-E EbIX EFET Role
model
CIM user Group Meeting October 2010 San Francisco
13
TC 57
Common Methodological framework
based on UN/Cefact CCTS
UN/Cefact (United Nations/Centre for Trade Facilitation and Electronic Business)
CCTS (Core Component Technical Specification)
• CCTS Gives a working framework to
enhance semantic, interoperability in
electronic data exchanges
• In particular, it helps to link business
processes data exchanges with a ex: ENTSO-E Scheduling Process
common global information model
(such as the CIM model)
CIM user Group Meeting October 2010 San Francisco
14
Common methodological framework
TC 57 inspired from UN/Cefact CCTS
(Core Component Technical Specification) standard
2
3
(Sub-Set,
Constraints, restrictions)
4
Contextual Model
or Business
Information Entity
( Profiles )
Information Model
or Core
Components
( CIM )
Message Conceptual
Model
or
Message
Assembly
(Exchanged at
app interfaces)
CIM extensions
Technological derivation
XSD, OWL,RDFS, SQL …etc
Business Process
Study:
1
Exchanged Data
analysis
Ex: outage
Management
DMS
CIM user Group Meeting October 2010 San Francisco
5
Validation
Implementation Message Model
ou
Syntax Binding
XML Exchanged Data
OMS
15
Application to WG16
Market Domain
Information Model
TC 57CIM + Market
Extensions CME
(Extended CIM)
Profiling Derivation
BasedOn
Profiling the CIM
Contextual Model Based on a parent model
Regional
Contextual Model
With eventual restrictions.
No additions possible to the parent model
BasedOn
Document
Contextual Model
Implementation Derivation
Message
Assembly
Model
Message
Implementation
syntactic
Model
CIM user Group Meeting October 2010 San Francisco
Message Conceptual Model
XSD
16
Information Model
TC 57
Extended CIM
Profiling Derivation
Contextual
Model
…
Style Market
Profile 1
Style Market
Profile N
Regional
Contextual
Models
Schedule
Contextual Model
…
Bid Contextual
Model
Document
Contextual
Models
Implementation Derivation
Message
Assembly
Model
Schedule Assembly
Model
Message
Implementation
syntactic
Models
CIM user Group Meeting October 2010 San Francisco
XSD
Bid Assembly
Model
XSD
17
WG16
Modeling TC 57
Rules
Methodological framework
UML Information
Model
UML Information
Profiles
Business Processes
projects
Document
Contextual Models
Message
Assembly
Message
Implementation
syntactic Models
Extended CIM
North American Style Market
Profile
European Style Market
Profile
Scheduling
Schedule
Document
Capacity
Allocation
Reserve
Management
Confirmation
Document
Schedule
Document message
Confirmation
Document
Message
XSD Schedule
Document
XSD Confirmation
Document
CIM user Group Meeting October 2010 San Francisco
Settlement …
18
TC 57
Model Derivation by the
example
CIM LEVEL
la ss CIM Informa tion Mode l
IdentifiedObject
Common: : Docume nt
+
+
+
+
+
+
+
+
category: String [0..1]
createdDateTime: AbsoluteDateTime [0..1]
docStatus: Status [0..1]
lastModifiedDateTime: AbsoluteDateTime [0..1]
revisionNumber: String [0..1]
status: Status [0..1]
subject: String [0..1]
title: String [0..1]
IdentifiedObject
InfCommon: : Ma rke tRole
IdentifiedObject
Common: : Orga nisa tion
+ Organisations
+ Document
0..*
+ Organisation
+
0..* +
CIM user Group Meeting October 2010 San Francisco
postalAddress: StreetAddress [0..1] 0..*
streetAddress: StreetAddress [0..1]
+ MarketRoles
«informative»
+
status: Status [0..1]
«Suppressed»
0..* + kind: MarketRoleKind [0..1]
«proposed»
+ type: String [0..1]
19
TC 57
Model Derivation by the
example
European Style Market Profile
la ss CIM Informa tion Mode l
IdentifiedObject
Common: : Docume nt
+
+
+
+
+
+
+
+
category: String [0..1]
createdDateTime: AbsoluteDateTime [0..1]
docStatus: Status [0..1]
lastModifiedDateTime: AbsoluteDateTime [0..1]
revisionNumber: String [0..1]
status: Status [0..1]
subject: String [0..1]
title: String [0..1]
IdentifiedObject
InfCommon: : Ma rke tRole
IdentifiedObject
Common: : Orga nisa tion
+ Organisations
+ Document
0..*
+ Organisation
+
0..* +
postalAddress: StreetAddress [0..1] 0..*
streetAddress: StreetAddress [0..1]
+ MarketRoles
+
status: Status [0..1]
«Suppressed»
0..* + kind: MarketRoleKind [0..1]
«proposed»
+ type: String [0..1]
«informative»
cla ss Europe a n Style Ma rke t Profile
«ACC»
ESMPCla sse s: : Docume nt
{root,leaf}
+
+
+
+
+
+
aliasName: ID_String [0..1]
category: MessageKind_String [0..1]
createdDateTime: AbsoluteDateTime [0..1]
docStatus: Doc_Status [0..1]
revisionNumber: VersionCode_String [0..1]
title: ID_String [0..1]
+ sender_organisation
1
+ receiver_organisation
1 +
+ subject_organisation
«ACC»
ESMPCla sse s: : Orga nisa tion
{root,leaf}
aliasName: PartyID_String
«ACC»
ESMPCla sse s: : Ma rke tRole
{root,leaf}
+ marketRole
0..1
+
type: MarketRoleKind_String
0..1
CIM user Group Meeting October 2010 San Francisco
20
TC 57
Model Derivation by the
example
cla ss CIM Informa tion Mode l
European Style Market Profile
cla ss ESMPPrimi. . .
IdentifiedObject
Common: : Docume nt
+
+
+
+
+
+
+
+
category: String [0..1]
createdDateTime: AbsoluteDateTime [0..1]
docStatus: Status [0..1]
lastModifiedDateTime: AbsoluteDateTime [0..1]
revisionNumber: String [0..1]
status: Status [0..1]
subject: String [0..1]
title: String [0..1]
cla ss ESMPDa ta Type s
«Datatype»
Me ssa ge Kind_String
{root,leaf}
«primitive»
String
{root,leaf}
+
value: MessageTypeList
ta gs
ETSOBusinessTerm = MessageType
cla ss Europe a n Style Ma rke t Profile
«ACC»
ESMPCla sse s: : Docume nt
{root,leaf}
+
+
+
+
+
+
aliasName: ID_String [0..1]
category: MessageKind_String [0..1]
createdDateTime: AbsoluteDateTime [0..1]
docStatus: Doc_Status [0..1]
revisionNumber: VersionCode_String [0..1]
title: ID_String [0..1]
+ sender_organisation
1
+ receiver_organisation
1 +
+ subject_organisation
«ACC»
ESMPCla sse s: : Orga nisa tion
{root,leaf}
aliasName: PartyID_String
«ACC»
ESMPCla sse s: : Ma rke tRole
{root,leaf}
+ marketRole
0..1
+
type: MarketRoleKind_String
0..1
CIM user Group Meeting October 2010 San Francisco
21
TC 57
Model Derivation by the
example
Contextual Message for Schedule Document
cla ss Europe a n Style Ma rke t Profile
«ACC»
ESMPCla sse s: : Docume nt
{root,leaf}
+
+
+
+
+
+
aliasName: ID_String [0..1]
category: MessageKind_String [0..1]
createdDateTime: AbsoluteDateTime [0..1]
docStatus: Doc_Status [0..1]
revisionNumber: VersionCode_String [0..1]
title: ID_String [0..1]
+ sender_organisation
«ACC»
ESMPCla sse s: : Orga nisa tion
{root,leaf}
1
+ receiver_organisation
1 +
+ subject_organisation
+ marketRole
0..1
aliasName: PartyID_String
«ACC»
ESMPCla sse s: : Ma rke tRole
{root,leaf}
+
type: MarketRoleKind_String
0..1
cla ss Sche dule Conte xtua l Me ssa ge Mode l
«ABIE»
Sche dule Conte xtua l Mode l: :
Docume nt
{root,leaf}
+
+
+
+
aliasName: ID_String
category: MessageKind_String
createdDateTime: AbsoluteDateTime
revisionNumber: VersionCode_String
+ sender_organisation
«ABIE»
Sche dule Conte xtua l Mode l: :
Ma rke t_Orga nisa tion
1
+ receiver_organisation
1
+ subject_organisation
+ marketRole
{root,leaf}
+
aliasName: PartyID_String
0..1
CIM user Group Meeting October 2010 San Francisco
«ABIE»
Sche dule Conte xtua l Mode l: :
Ma rke tRole
{root,leaf}
1
+
type: MarketRoleKind_String
22
Model Derivation by the
example
TC 57
Schedule Document Assembly level
cla ss Sche dule Conte xtua l Me ssa ge Mode l
«ABIE»
Sche dule Conte xtua l Mode l: :
Docume nt
{root,leaf}
+
+
+
+
aliasName: ID_String
category: MessageKind_String
createdDateTime: AbsoluteDateTime
revisionNumber: VersionCode_String
+ sender_organisation
«ABIE»
Sche dule Conte xtua l Mode l: :
Ma rke t_Orga nisa tion
1
+ receiver_organisation
1
+ subject_organisation
+ marketRole
{root,leaf}
+
«ABIE»
Sche dule Conte xtua l Mode l: :
Ma rke tRole
{root,leaf}
aliasName: PartyID_String
0..1
1
+
type: MarketRoleKind_String
cla ss Sche dule Conte x tua l Me ssa ge Mode l
«MBIE»
Docume nt
+
+
+
+
+
+
+
+
+
+
aliasName: ID_String
category: MessageKind_String
createdDateTime: AbsoluteDateTime
receiver_organisation.aliasName: PartyID_String
receiver_organisation.marketRole.type: MarketRoleKind_String
revisionNumber: VersionCode_String
sender_organisation.aliasName: PartyID_String
sender_organisation.marketRole.type: MarketRoleKind_String
subject_organisation.aliasName: PartyID_String [0..1]
subject_organisation.marketRole.type: MarketRoleKind_String [0..1]
CIM user Group Meeting October 2010 San Francisco
23
TC 57
One more complicated ENTSO-E
message derived through the
methodology
cla ss ESMP Sche dule Docume nt Asse mbly
«MBIE»
Docume nt
{root,leaf}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
aliasName: ID_String
category: MessageKind_String
createdDateTime: AbsoluteDateTime
domain_energyArea.aliasName: AreaID_String [0..1]
matchingPeriod_timeSchedule.startDateTime: AbsoluteDateTime [0..1]
matchingPeriodtimeSchedule.endDateTime: AbsoluteDateTime [0..1]
process.classificationType: ClassificationKind_String
process.processType: ProcessKind_String
receiver_organisation.aliasName: PartyID_String
receiver_organisation.marketRole.type: MarketRoleKind_String
revisionNumber: VersionCode_String
sender_organisation.aliasName: PartyID_String
sender_organisation.marketRole.type: MarketRoleKind_String
subject_organisation.aliasName: PartyID_String [0..1]
subject_organisation.marketRole.type: MarketRoleKind_String [0..1]
+ timeSeries
XML NDR
Naming and Design Rules
0..*
«MBIE»
Time Se rie s
{root,leaf}
+
+
+
+
+
+
+
+
+
+
+
+
+
agreement.aliasName: ID_String [0..1]
agreement.category: CapacityContractKind_String [0..1]
aliasName: ID_String
businessType: BusinessKind_String
in_energyArea.aliasName: AreaID_String [0..1]
in_organisation.aliasName: PartyID_String [0..1]
measurementPoint.aliasName: MeasurementPointID_String [0..1]
objectAggregation: ObjectAggregationKind_String
out_energyArea.aliasNAme: AreaID_String [0..1]
out_organisation.aliasName: PartyID_String [0..1]
product: EnergyProductKind_String
unit.name: MeasurementUnitKind_String
version: VersionCode_String
+ regularIntervalSchedule
1
+ reason_activityRecord
«MBIE»
Re gula rInte rva lSche dule
endTime: AbsoluteDateTime
startTime: AbsoluteDateTime
timeStep: Seconds
+ timePoint
0..1
«MBIE»
Time Se rie s_ActivityRe cord
{root,leaf}
{root,leaf}
+
+
+
XSD
+
+
category: ReasonCode_String
reason: String [0..1]
1..*
«MBIE»
Re gula rTime Point
{root,leaf}
+
+
sequenceNumber: Integer
value1: Float
CIM user Group Meeting October 2010 San Francisco
24
TC 57
Proposed CIM Extensions
 With Scheduling and Capacity Allocation processes
studies we have the following new CIM classes :
 Process
 TimeSeries
 BidTimeSeries
 Auction
 Price
 MeasurementPoint
CIM user Group Meeting October 2010 San Francisco
25
TC 57
Proposed CIM Extensions inside
IEC62325 package
CIM user Group Meeting October 2010 San Francisco
26
TC 57
CIM Issues about
combined shared CIM packages
CIM user Group Meeting October 2010 San Francisco
27
TC 57
EDF Prototypes to support the
modelling methodology
 Choice to develop EA’s addins
 Addressing the following features :
 CIMValidator :
• validation of UML Profiles, contextual models and UML message
assembly
• BasedOn Traceability builder between the stack of UML models
 CIMSync : Synchronize UML Models (profiles, contextual,
assembly) with the CIM when an CIM evolution is made.
 ENTSO-e XSD Builder : production of XSD models from
UML Message assembly compliant with ENTSO-e.
CIM user Group Meeting October 2010 San Francisco
28
Information Model
TC 57CIM + Market
EDF Prototypes
Extensions CME
(Extended CIM)
Profiling Derivation
BasedOn
Regional
Contextual Model
BasedOn
CIMValidator
CIMSync
Document
Contextual Model
Implementation Derivation
Message
Assembly
Model
Message
Implementation
syntactic
Model
Message
Conceptual Model
XSD
CIM user Group Meeting October 2010 San Francisco
ENTSO-e XSD Builder
29
Information Model
TC 57CIM + Market
CIMSync
Extensions CME
(Extended CIM)
Profiling Derivation
BasedOn
Regional
Contextual Model
BasedOn
Document
Contextual Model
Implementation Derivation
Message
Assembly
Model
Message
Implementation
syntactic
Model
Message
Conceptual Model
Legend
XSD
Syncrhonize / Propagate
UML Evolutions
An Evolution is made in UML CIM or
Profiles
CIM user Group Meeting October 2010 San Francisco
30
Information Model
TC 57CIM + Market
CIMSync
Extensions CME
(Extended CIM)
Profiling Derivation
BasedOn
Regional
Contextual Model
BasedOn
Document
Contextual Model
Implementation Derivation
Message
Assembly
Model
Message
Implementation
syntactic
Model
Message
Conceptual Model
Legend
XSD
Syncrhonize / Propagate
UML Evolutions
An Evolution is made in UML CIM or
Profiles
CIM user Group Meeting October 2010 San Francisco
31
A few ScreenShots : CIMValidator
TC 57
UML Models
Stack
cla ss Sche dule Conte xtua l Me ssa ge Mode l
«ABIE»
Sche dule Conte xtua l Mode l: :
Docume nt
{root,leaf}
+
+
+
+
aliasName: ID_String
category: MessageKind_String
createdDateTime: AbsoluteDateTime
revisionNumber: VersionCode_String
cla ss ESMP Sche dule Docume nt Asse mbly
+ sender_organisation
«MBIE»
1
+ receiver_organisation
1
+ subject_organisation
+
0..1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Docume nt
«ABIE»
Sche dule Conte xtua l Mode l: :
aliasName: ID_String
Ma
rke t_Orga nisa tion
category:
MessageKind_String
{root,leaf}
createdDateTime: AbsoluteDateTime
domain_energyArea.aliasName: AreaID_String [0..1]
matchingPeriod_timeSchedule.startDateTime: AbsoluteDateTime [0..1]
matchingPeriodtimeSchedule.endDateTime: AbsoluteDateTime [0..1]
process.classificationType: ClassificationKind_String
process.processType: ProcessKind_String
receiver_organisation.aliasName: PartyID_String
receiver_organisation.marketRole.type: MarketRoleKind_String
revisionNumber: VersionCode_String
sender_organisation.aliasName: PartyID_String
sender_organisation.marketRole.type: MarketRoleKind_String
subject_organisation.aliasName: PartyID_String [0..1]
subject_organisation.marketRole.type: MarketRoleKind_String [0..1]
{root,leaf}
aliasName: PartyID_String
+ timeSeries
«ABIE»
Sche dule Conte xtua l Mode l: :
Ma rke tRole
{root,leaf}
+ marketRole
1
+
type: MarketRoleKind_String
0..*
«MBIE»
Time Se rie s
{root,leaf}
+
+
+
+
+
+
+
+
+
+
+
+
+
agreement.aliasName: ID_String [0..1]
agreement.category: CapacityContractKind_String [0..1]
aliasName: ID_String
businessType: BusinessKind_String
in_energyArea.aliasName: AreaID_String [0..1]
in_organisation.aliasName: PartyID_String [0..1]
measurementPoint.aliasName: MeasurementPointID_String [0..1]
objectAggregation: ObjectAggregationKind_String
out_energyArea.aliasNAme: AreaID_String [0..1]
out_organisation.aliasName: PartyID_String [0..1]
product: EnergyProductKind_String
unit.name: MeasurementUnitKind_String
version: VersionCode_String
+ regularIntervalSchedule
1
+ reason_activityRecord
«MBIE»
Re gula rInte rva lSche dule
+
+
+
endTime: AbsoluteDateTime
startTime: AbsoluteDateTime
timeStep: Seconds
+ timePoint
0..1
«MBIE»
Time Se rie s_ActivityRe cord
{root,leaf}
{root,leaf}
+
+
category: ReasonCode_String
reason: String [0..1]
Detailed Report
1..*
«MBIE»
Re gula rTime Point
{root,leaf}
+
+
sequenceNumber: Integer
value1: Float
Overview/summary
Report
CIM user Group Meeting October 2010 San Francisco
32
A few ScreenShots : ENTSO-e XSD
TC 57Builder
Assembly Model
CIM user Group Meeting October 2010 San Francisco
XSD
Model
33
A few ScreenShots : ENTSO-e XSD
TC 57Builder
Generated
XSD
Model
CIM user Group Meeting October 2010 San Francisco
34
TC 57
Feedback on the
common methodological approach
 Un/Cefact based methodology facilitated the CIM
ENTSO-E Market EDI harmonization.
 Having a whole information model giving the next step
for future European work, EDI harmonization.
 The methodological framework reduced the number
of added new classes into the CIM to cover all
ENTSO-e market exchanged messages through their
business processes.
 Supporting the methodology with prototypes gives a real
proof of concept.
CIM user Group Meeting October 2010 San Francisco
35
TC 57
Thank you for your attention.
CIM user Group Meeting October 2010 San Francisco