Presentation is loading. Please wait.

Presentation is loading. Please wait.

Standards, models and conceptual approach Per Øyvind Berg-Knutsen

Similar presentations


Presentation on theme: "Standards, models and conceptual approach Per Øyvind Berg-Knutsen"— Presentation transcript:

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

19

20

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

25

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…

32

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

35

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="http://www.w3.org/2001/XMLSchema-instance" 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


Download ppt "Standards, models and conceptual approach Per Øyvind Berg-Knutsen"

Similar presentations


Ads by Google