1. Standards, models and conceptual approach Per Øyvind Berg-Knutsen
The Norwegian Elhub
Standards, models and conceptual approach
Per Øyvind Berg-Knutsen
Statnett SF

2. Standards, models and conceptual approach Per Øyvind Berg-Knutsen
The Norwegian Elhub
Standards, models and conceptual approach
Per Øyvind Berg-Knutsen
Statnett SF

3. Agenda Introduction to the Elhub project
Elhub and the Norwegian power utility market
Developing Elhub core models
Information assets developed
Transforming Elhub processes into standard messages
CIM-ebIX harmonisation
Harminization needs

4. The current Norwegian power utility market… 4 3 2 1
DSO's … D C B A
Suppliers
About 130 DSOs
About 110 energy suppliers
About 2.8M metering points
~1M business processes per year
(supplier changes, customer moves, masterdata updates)

5. The current Norwegian power utility market… 4 3 2 1 D C B A
DSO's
Suppliers
About 130 DSOs
About 110 energy suppliers
About 2.8M metering points
~1M business processes per year
(supplier changes, customer moves, masterdata updates)

6. The future Norwegian power utility market
"today everyone talks with everyone"
"Everyone talks with Datahub"
DSO's
Suppliers … 4 3 2 1 D C B A
HUB
DSO's
Suppliers 1 A
Metered values
Master data
End-user inform.
Switching
Moving
Settlement data 2 B to 3 C 4 D … …
Elhub will include DATA storage in addition to being a communications hub

7. Key aspects of Elhub processes
Processing time
Is data available?
Data processing: After-the-fact
Settlement and reconciliation
Reporting
Preliminary and final processing
Business processes:
Future (holding)
Current (being executed)
Past (reversals) No
Yes
Preliminary processing
Final processing
Assumed or empirical values
Actual metered values

8. Introduction to the Elhub project
go-live
The Elhub is scheduled to go live on 1 October 2016
The Elhub will be the authoritative source on such data in the market, although the Metered Data Collector will be collecting these from the meters
Statnett will be setting up a data hub (Elhub) for storing collecting metered data from AMS meters to be installed in the market by 2019
The project has currently a public tender for an overall solution for the Elhub
The basis for all of the following information has been shared with and in the market, although most in Norwegian
The considerations leading up to decisions have been developed in cooperation with parties in the market
Data responsibility shift from market actors to Elhub
2019: AMR transformation complete
Status: Public tender for solution
Models and descriptions exist in Norwegian
Documents developed in cooperation with market actors

9. Regional cooperation and influence
Regional harmonization
HNR – Harmonised Nordic Retail market
NBS – Nordic Balance Settlement
Wide consensus on common market bases an processes
SE, DK, FI, NO
Denmark
Developed a data hub in 2012
Cooperation provide Elhub with vital experiences
Business process similarities
Sweden, Finland
Starting up
Expect significant business process similarities

10. Standards and needs in Elhub
Considerations
One format type only, i.e., xml-based interfaces
One namespace only, i.e., one common standard used
Redesigned business processes in the market
Modeling business process transactions
Process meter values – meter reads and metered values
Need: CIM-ebIX harmonized models and format specifications

11. Existing standards vs. Elhub needs
Wholesale market area
Market business process area
Electric utility
Customer area
CIM functional coverage
ENTSO-E functional coverage
ebIX functional
coverage

12. Existing standards vs. Elhub needs
Wholesale market area
Market business process area
Electric utility
Customer area
Elhub needs
CIM functional coverage
ENTSO-E functional coverage
ebIX functional
coverage
ebIX functional
coverage

13. Elhub in a CIM context National adaptations to ebIX
Elhub functional area
Business processes
Metered data collection
ENTSO-E functional coverage
ebIX functional
coverage
Data storage
Nordic Balance Settlement
Settlement & Reconcil.
Calc. & Aggreg.

14. Elhub model coverage and approach
Elhub functional area
Top-down approach
Required data for market processes
Calculations
What, why, and to which parties?
Resulting information assets:
Elhub base models
Market entity state model
Data exchange messages
Business processes
Metered data collection
Data storage
What, why, and to which parties?
What; exchanged information decided by the market processes, incl. metered data collection
Why; governed by the need for unique identification and data retrieval across market parties
Which parties; governed by the current and future roles to be active in the market
Settlement & Reconcil.
Calc. & Aggreg.

15. Elhub model coverage and approach
Elhub functional area
Top-down approach
Required data for market processes
Calculations
What, why, and to which parties?
Resulting information assets:
Elhub base models
Market entity state model
Data exchange messages
Business processes
Metered data collection
Data storage
Settlement & Reconcil.
Calc. & Aggreg.

16. Elhub base models Role model – defining roles and their associations
Information model – defining internal information entities and their logical relations
Security model – defining key considerations for access to information entities by different roles as defined in the role model

17. Elhub base models Role model – defining roles and their associations
Information model – defining internal information entities and their logical relations
Security model – defining key considerations for access to information entities by different roles as defined in the role model

18. - The Elhub Role Model
Based on the ENTSO-E, as well as the Norwegian EDIEL role models
Reduced to cover the Elhub scope
Extends and introduces new roles
Catering for adjustments in a post-Elhub market
Extended to support single-invoice market models
Extended to support energy certificates and taxations
Extendable to support wholesale market models

21. Elhub base models Role model – defining roles and their associations
Information model – defining internal information entities and their logical relations
Security model – defining key considerations for access to information entities by different roles as defined in the role model

22. - The Elhub Information Model
Model representation
Aggregated physical entities on which the market is operating
Metering Points, Metering Grid Areas, Market Balance Areas
Business entites in the market (i.e., entity roles used, cf. the Elhub Role model)
TSOs, Energy Suppliers, Third Parties
Customers with their personal data
Relationships between entities and parties
Balance Supply contracts
Grid Access contracts

23. Key definitions Term Description Term Description
Balance Supplier in the Metering Grid Area
A link that indicates which Balance Suppliers are active in a Metering Grid Area, i.e., that can supply energy for Metering Points in the relevant Metering Grid Area. This is linked to the Metering Point rather than the Metering Grid Area to be able to distinguish between different Balance Responsible Parties for various functions (e.g. production and consumption) in the same Metering Grid Area.
Grid access contract
A Metering Point's grid access and settlement are represented through this class, which constitutes a connection between the Metering Point, Grid Access Provider and consumer.
This class represents sensitive market information only to a limited extent. It is nevertheless subject to appropriate protection against access and changes.
Balance supply contract
Balance supply is handled through this class. In addition to comprising the necessary connections to the Balance Supplier, Metering Point and consumer, it is a prerequisite in the market that a Grid Access Contract has been signed before a balance supply contract is entered into.
This class represents commercially sensitive information associated with the Balance Supplier’s customer portfolios, and is protected accordingly.
Customer information
All personal data and/or sensitive information about people and/or companies have been put in this class, to ensure that the proper protection can be implemented – with regard to access, as well as mechanisms for this, such as encryption.
Address information
Addresses will have two purposes in the model – it provides facility addresses and physical locations for Metering Points, as well as addresses for consumers, including home addresses, invoice addresses etc. Depending on the purpose, encryption may be considered as a protective measure also for this class.
Taxation profile
A taxation profile which is mandatorily linked to each Metering Point and associated consumer. This will also be a class for handling other aspects that are unique for each connection between a Metering Point and a customer, such as Industry Code.
Term
Description
Accounting Point
The smallest entity under balance responsibility and/or where a change of supplier can take place. This can be a physical or logical point.
Balance Responsible Party
A role that has a contract for providing financial security and balance responsibility with the Imbalance Settlement Responsible for a Market Balance Area, entitling the party to operate in the market. This is the only role allowing a party to purchase and sell energy on a wholesale level.
Balance Supplier
The de facto definition in the Norwegian market is that this role markets the total energy purchased by a Party connected to the grid.
Exchange Point
A Metering Point that measures energy exchange between grid areas. An Exchange Point can be connected to the main grid as well as underlying grids.
Grid Access Provider
A role responsible for providing access to the grid and its use for consumption or production to a party connected to and within a grid.
Market Balance Area
A geographic area consisting of one or more Metering Grid Areas with common market rules for how the settlement responsible party carries out balance settlement and which has the same price for imbalance.
A Market Balance Area may also be defined based on bottlenecks in the grid.
Metered Data Responsible
A role responsible for the establishment and validation of metered data from the Metered Data Collector. The role is responsible for submitting updated Metering Point values to Elhub.
Metering Grid Area
A Metering Grid Area is a physical area where consumption, production and exchange can be metered. The Metering Grid Area is delimited by meters for periodic measurement of input to and withdrawal from the area.
The Metering Grid Area can be used to establish the sum of profile-metered Metering Points and grid loss.
Metering Point
A point where energy products are measured
Party connected to the grid
A role which may either consume or produce energy based on an established grid access contract with a Grid Access Provider, and a power supply contract with a Balance Supplier.
Supplier of last resort
This is a specialisation of the role Balance Supplier. The role is responsible for selling energy to consumers who have not entered into energy supply contracts via a Balance Supplier.
Third party
A role that can carry out services on behalf of a Party connected to the grid.

24. Market parties involved
Actors involved
Market structure information
Personal information

26. Elhub base models Role model – defining roles and their associations
Information model – defining internal information entities and their logical relations
Security model – defining key considerations for access to information entities by different roles as defined in the role model

27. - The Elhub Security Model
Metered values = personal information
Names and identities must be protected
Contracts are commercially sensitive information
Third parties expected to become key players
Solution: Two levels of access:
Implicit access
explicit access

28. Elhub model coverage and approach
Elhub functional area
Top-down approach
Required data for market processes
Calculations
What, why, and to which parties?
Resulting information assets:
Elhub base models
Market entity state model
Data exchange messages
Business processes
Metered data collection
Data storage
Settlement & Reconcil.
Calc. & Aggreg.

29. Elhub model coverage and approach
Elhub functional area
Top-down approach
Required data for market processes
Calculations
What, why, and to which parties?
Resulting information assets:
Elhub base models
Market entity state model
Data exchange messages
Business processes
Metered data collection
Data storage
Settlement & Reconcil.
Calc. & Aggreg.

30. Market modelling
Metering point state model – basis for all market processes, defining valid actions in the market on a particular entity
Market process descriptions – specific market implementations of processes affecting information items and entity states

31. - Metering point State Model
Aggregated from:
Physical state (metering point)
Contractual binding to Grid Access Provider (DSO)
Contractual binding to Balance Supplier
Combined and simplified for Elhub purposes…

33. State model properties
2 (3) physical states
3 contractual states
10 aggregated states
31 state transformations

34. Logical market process messages
Process descriptions using "process components"
"Process components" = logical message structures
per market party, with parameters
46 process components => 36 physical Elhub messages
133 combinations: Process components and parameters

36. Elhub model coverage and approach
Elhub functional area
Top-down approach
Required data for market processes
Calculations
What, why, and to which parties?
Resulting information assets:
Elhub base models
Market entity state model
Data exchange messages
Business processes
Metered data collection
Data storage
Settlement & Reconcil.
Calc. & Aggreg.

37. Elhub model coverage and approach
Elhub functional area
Top-down approach
Required data for market processes
Calculations
What, why, and to which parties?
Resulting information assets:
Elhub base models
Market entity state model
Data exchange messages
Business processes
Metered data collection
Data storage
Settlement & Reconcil.
Calc. & Aggreg.

38. Data exchange messages
99 message and parameter combinations
59 directly linked to process components
45 reply messages
16 invoke entity state changes
7 with conditional state changes

39. Data exchange messages
Message names follow ebIX standard with extended descriptive names
Messages are composed from two parts: Header and Payload
Header define market party and process bindings, including
Document Type Description (UN/CEFACT and ebIX codes)
Business Process Description (ebIX codes only)
Payload contain key data elements, structured into xml entites
37 ebIX based entities used or adapted for national use (not final)

40. Example xml message: RequestStartOfSupply
Contents, e.g., type definitions and formats of each message are currently being defined in more detail, based on ebIX base classes
Definitions are being developed using Sparx Enterprise Architect
<?xml version="1.0" encoding="UTF-8"?>
<rsm:RequestStartOfSupply xmlns:rsm="un:unece:260:data:EEM" xmlns:xsi="
xsi:schemaLocation="un:unece:260:data:EEM elhub_RequestStartOfSupply.xsd">
            <rsm:HeaderEnergyDocument>
                        <rsm:Identification> </rsm:Identification>
                        <rsm:DocumentType listAgencyIdentifier="6">392</rsm:DocumentType>         
                        <rsm:Creation> T09:30:47Z</rsm:Creation>
                        <rsm:SenderEnergyParty>
                                   <rsm:Identification schemeAgencyIdentifier="9"> </rsm:Identification>
                        </rsm:SenderEnergyParty>
                        <rsm:RecipientEnergyParty>
                                   <rsm:Identification schemeAgencyIdentifier="9"> </rsm:Identification>
                        </rsm:RecipientEnergyParty>
            </rsm:HeaderEnergyDocument>
            <rsm:ProcessEnergyContext>
                        <rsm:EnergyBusinessProcess listAgencyIdentifier="260">E03</rsm:EnergyBusinessProcess>
                        <rsm:EnergyBusinessProcessRole listAgencyIdentifier="6">DDQ</rsm:EnergyBusinessProcessRole>
                        <rsm:EnergyIndustryClassification>23</rsm:EnergyIndustryClassification>
            </rsm:ProcessEnergyContext>
            <rsm:PayloadMPEvent>
                        <rsm:StartOfOccurrence> T00:00:00Z</rsm:StartOfOccurrence>
                        <rsm:MeteringPointUsedDomainLocation>
                                   <rsm:Identification schemeAgencyIdentifier="9"> </rsm:Identification>
                        </rsm:MeteringPointUsedDomainLocation>
                        <rsm:BalanceResponsibleInvolvedEnergyParty>
                                   <rsm:Identification schemeAgencyIdentifier="9"> </rsm:Identification>
                        </rsm:BalanceResponsibleInvolvedEnergyParty>
                        <rsm:BalanceSupplierInvolvedEnergyParty>
                                   <rsm:Identification schemeAgencyIdentifier="9"> </rsm:Identification>
                        </rsm:BalanceSupplierInvolvedEnergyParty>        
            </rsm:PayloadMPEvent>
</rsm:RequestStartOfSupply>

41. CIM-ebIX harmonisation
Levels of harmonization:
Market framework (legal and regulatory)
Market models and -entity states
Overall processes and sequences

42. Key model development considerations
Regulatory
Processes & calculations
Market structure
Privacy and security
Market model
The model should represent the market at a sufficient level to mirror key market properties.
Privacy and security
Key aspects of security and privacy must be maintained.
Security aspects must be ensured.
Process calculations
The model must cater for needs of aggregating and calculating data.
Message content
Messages should have well-defined content and format descriptions.
Standards reuse
Where relevant, existing standards in the market will be reused unless specifically renewed.
Performance
The system will use large quantities of data with strict requirements on processing time.
Market
Performance
Message content
Standards

43. Model development considerations - full
Area
Description
Key origin
Rationale and/or implication
Market area model
The model will provide for an appropriate structure for data storage and retrieval.
Regulatory and market
Metered data must be made available by 09:00 next day.
The model will represent a correct market structure.
Privacy by Design
Key aspects of security and privacy must be maintained. See relevant section of next chapter.
Regulatory
Only approved access to information (including metered data) must be allowed.
Personal information will be separated in order to facilitate appropriate protection of such data.
Calculations and aggregation
The model must cater for needs of aggregating and calculating data.
The market requires that a number of calculations are being performed for balancing energy supplies. Basis for these calculations, as well as results must be handled by the model.
Message content
New messages and content will be provided by the Elhub.
Market needs
Message content will be mirrored into the information model, and vice-versa to ensure consistency.
Note that XML has been decided in favor of the existing UN/CEFACT format.
Standards reuse
Where relevant, existing standards in the market will be reused unless specifically renewed.
Elhub design
Where appropriate, additional properties must be added to entities in order to ensure compliance with current market standards.
This includes the suggested use of UUID for referencing.
System performance
The system will use large quantities of data with strict requirements on processing time.
The model must provide opportunities for parallel processing and separation of tasks, consistent with an object oriented and –structured approach.
Multi-domain
A system will handle multiple distinct sets of information with absolute separation within a single installation.
Due to widespread changes in the energy markets (and the Nordic energy markets in particular), the Norwegian Elhub will be one of several similar organizations in the region. The solutions may, therefore, benefit from the possibility to handle multiple areas (countries) with absolute separation in the same installation. Also, cf. separate section in next chapter.
Entity properties
Entity properties will be described in relevant detail in the information model.
Modelling needs
Cf. message content. Entities will be described at a corresponding level in order to mirror message content and referential integrity considerations.
Future proof
The system will be operational for a long time with numerous changes being implemented.
In order to facilitate future changes, the model will consist of many simple entities which may be combined in a configurable way in order to handle marked model and technical change requests in a timely and cost-efficient manner.

44. Questions? Per Øyvind Berg-Knutsen
Architect, Elhub project / Principal at Devoteam Consulting