PROVIDING SMART METERING DATA SERVICES THROUGH AN EU MARKET PLACE

This paper describes the architecture of the FLEXICIENCY project, looking at functional and non-functional requirements, for B2B interactions (mainly between DSO and Data Requester), including the Market Place as a contact point and IT innovative platform to be developed. A common architecture framework is defined and requirements are listed for data and service exchange at EU level, addressing data privacy and interoperability, among regulated and unregulated energy players.


INTRODUCTION
Major European DSOs are working together with market players and other stakeholders within the Horizon 2020 -LCE-07-2014/grant n° 646482 project FLEXICIENCY to develop a technical Platform in order to achieve a market place based on meter data exchange.This joint market place will simplify interactions within the retail market and enable cross-country access to innovative energy services based on metering data.This platform will make advanced monitoring, local energy control and flexibility management much easier.It will enable service providers to access the data they need (subject to consumer consent) to provide personalized services to consumers or aggregate flexibility participations.For such a system, data security requirements have to be applied by every IT component to guarantee strong customer authentication and data privacy respect.The FLEXICIENCY IT system, as presented in the Figure 1, consists of three building blocks: the Market Place, the DSO platforms (mainly Data Provider) and the energy service provider platforms (mainly Data Requesters).
The authors are consortium partners and acknowledge project members at the end of this paper.For more about FLEXICIENCY project, we refer to its website [5] and a CIRED paper [4].This paper defines the technical scope of common areas to be shared within the whole System.Towards plug and play B2B platform connections, a list of common services and common data exchange interactions is extracted from Use cases to make the best reuse of different demo contributions.Standardization in processes, content, formats and communication protocols are adopted for 5 main components of the system.Requirements will in particular address the system matching with high level Architecture principles of FLEXICIENCY objectives.
Finally, the paper provides guidelines and standardized components for future implementation of this collaborative project.

FLEXICIENCY -BUSINESS ARCHITECTURE
The FLEXICIENCY-WP2 aims at defining a common architecture framework and requirements for data and service exchange at EU level, addressing data privacy and Paper 0225 CIRED 2017 interoperability, among regulated and unregulated energy players.This framework enables organizations to effectively address critical business needs, mainly by:  Ensuring that everyone speaks the same language;  Avoiding lock-in to proprietary solutions by standardization.

Architecture Vision
To avoid any deviation during the project, an architecture vision to be respected by every component of the system was defined and it is structured into 5 principles, fitting to FLEXICIENCY scope:

Regulated / Unregulated Structure
Because the energy sector is changing, the targeted system has to be open and flexible for future changes at a minimum of cost.This flexibility is given to the system to be better leveraged after the project for further exploitation needs.These evolutions are likely to have different orientations for 2 major actor sets: regulated and unregulated.Therefore, the whole system must be structured into regulated and unregulated independent environments, building two modular configurations, according to their business responsibilities and implementation needs.

MAIN PROCESSES IN FLEXICIENCY
To achieve a common understanding of the project, different processes have been detailed (as stated in the table below).

Scenario name Scenario description
1. Service Registration DSO registers a Business Service Offer on the Market Place (The offer is a set of services of the same type.Through the registration process, the provider includes everything needed to generate a contract agreement such as duration, options, prices etc).

Service Search
ESO searches for Business Services on the Market Place.

Service Request
ESO requests a service through the Market Place (This is related to the MP Service Subscription , as a wish list from the requester).

DSO Localization
The Market Place identifies the Service providers.

Service Subscription
ESO subscribes to each DSO services in the Market Place (This is related to the B2B Service Subscription.B2B contract agreement is generated, the provider is informed by the market place).

Service Activation
The ESO requests a service activation from the DSO, for a given list of PODs and proof for customer consent.

Customer Consent Check
The DSO collects (via ESO mainly) & checks the compliance of customer data consent for the related service to be activated.

Data Calculation
The DSO extracts/calculates the individual/aggregation.data.

Data Transmission
The DSO sends individual/aggregated consumption data to the ESO according to their agreement.(to a repository address for instance depending on B2B arrangements).

Data Collection
The ESO collects the data sent by the DSO (from a repository address for instance).

COMPONENTS FOR STANDARDISATION
Furthermore, common areas to be shared between the subsystems were defined (through use cases described in [2]), allowing a standardization of services and data exchanges in: processes, structures, formats and communication protocols, in particular dealing with:

Service Catalogue (via Market Place)
The core functionalities provided by the Market Place are commonly defined for any EU Market Player.Hence, these are standardised in the system through use cases defined in [2]:  New Market Player enroll in the market place  Service Provider manage its services  Service Provider "pass" an integration certification  New Market Player enrolls to a new service  Market Player requester quits a subscribed service

DSO Localisation (via Market Place)
Identification of MP service providers is based on localization input and is specific at country level.
Major EU countries have several DSOs that cover the country.These are mainly located in geographic areas.However, a service requester (retailers/ESO/aggregators) may have customers located throughout the whole country (and across Europe) without knowing the exact DSO who is managing each of their customer's data.The service requester has to provide a list of localization information for its customers (POD or geographic data extracted from the electricity bill) to the MP to be able to receive a matching list of data custodians (DSO).

B2B Agreements (via Market Place & B2B)
When contact is established via the Market Place, the B2B sides will get through:

Customer Consent (ESO-Customer-DSO)
In order to provide individual data, in compliance with the regulatory framework and relevant rules regarding cyber security and data protection, the DSO will have to check the compliance of the customer consent, prior to any data transmission to a MP service requester.Inspired from Green Button mechanism, Protocol OAuth2 is adopted for authentication processes.We refer to [1] & [2] for more details.

B2B Data exchange (DSO-ESO)
This is about the Data delivery service described in [3].
The service of data delivery can be offered on the market place both by regulated and unregulated actors and can cover the exchange of historical data, real time data, forecasted data, raw data, processed data, etc.
DSOs (or the regulated meter operator) will particularly supply metering data, and results of any processing (i.e.forecasts, aggregated data, etc.) at a given frequency.
Common business objects are listed and modeled through UML diagrams in [3], towards standardized format to be built.

IT SYSTEM REQUIREMENTS
The project followed the SquaRE Quality Model, requirements are described in [1] ranging from functional suitability to data security.A summarized list is provided below:

WHOLE PROCESS ILLUSTRATION
The following diagram, illustrates the main interactions between different sub systems, from consumer service acceptance to service delivery, while crossing FLEXICIENCY system for Metering data exchanges between DSO and Energy Service Company and their respective platforms, more information is given in [1].Guidelines, roles & responsibilities have been provided towards the stakeholders (hence towards their IT Platforms) to support and contribute to the success of the system as a whole.Common areas to be shared between the subsystems have been defined, allowing a standardization of services and data exchanges.During implementation, this standardization process must carry on, using these guidelines and further deeper description.Content of messages will be more developed to support the interactions between the main users of FLEXICIENCY either from Regulated or Unregulated side of Energy Market.

Figure 1 :
Figure 1:B2B Interactions through a Market Place for Metering Data Provision

Figure 4 :
Figure 4: Example of Data Provision Process

. Flexible Solution for Future Exploitation: the
Regulated Environment, where only Regulated Actors are B2B Service providers on the Market Place.These are mainly DSO, TSO or any Metering Data Manager. Unregulated Environment, where only Unregulated Actors are B2B Service providers on the Market Place.These are mainly Retailer, ESCO, Aggregator, or any technology providers.
The 3 main involved parts are the Market Place (as Contact Point), the DSO platform (as Data Provider) and the ESO platform (as Data Requester).Both Data provider and Data requester are Market Players.Platforms) to support and contribute to the success of the project as a whole.