‘RecorDER’ is a collaboration between National Grid, UK Power Networks, SP Energy Networks and Electron to develop and demonstrate an asset register for Energy Resources. The project seeks to define, assess and pilot a blockchain-based asset register, enabling parties to use and reference a shared data set of generation and flexibility resources. The project aims to pilot a Minimum Viable Product (MVP) and, where possible, determine requirements for a full-scale deployment in future iterations of the project.
Objectives
At the end of the project, we will understand:
- Whether a shared asset register for flexibility assets will
o Enhance whole-electricity-system visibility
o Facilitate easier trading of assets across transmission and distribution
o Enhance efficiency of data transfer
o Improve data quality and accuracy
o Enable more efficient and dynamic registration of assets
- Whether a blockchain solution can
o provide a flexible, innovative architecture for a shared asset register
o provide a secured validated permissions architecture to manage asset data
- What investment and effort will be required to roll out the register across GB
Learnings
Outcomes
The Technology, Governance, and Legal reports generated in the first half of the project informed the prototype’s Data Model, which was agreed upon by project partners and led to the development of the prototype platform. All three reports can be found on the RecorDER project page of Smarter Networks portal.
The functioning prototype platform demonstrated, linking SWRR data from UKPN and SPEN, and published ESO STOR contract data. Concluding the project Electron hosted a demonstration to interested project partners, covering:
- Governance and Permissioning – managing access to open, shared, and private data within the same dataset.
- Asset Visibility linking data through a unique ID for each asset
- Contract Linkage – Potential to link contracts relating to that asset
The recorded demonstration can view here:
- https://players.brightcove.net/867903724001/default_default/index.html?videoId=6197968269001
Technology Review Summary
A technology review was undertaken at the beginning of the project to provide an early stage gate to determine whether to continue with the exploration of a blockchain-based asset register.
Baringa found potential benefits in having one version of the truth, trust in the verifiable provenance of data and clarity of accountability. Specific concerns were raised regarding the security, reliability and scalability of the technology.
They also identified a number of issues that need to be addressed regardless of the technology, including governance, privacy and GDPR. These were also addressed by the subsequent Governance and Legal reports as part of the project.
Governance Review Summary
GemServ researched and recommended the design for a governance framework created in three phases:
- Establishment – This phase defines roles and responsibilities of platform participants through a Target Operating Model.
- Operation – This phase defines the governance required for platform management.
- Termination - This phase explores termination procedures.
Key findings:
The following approach was proposed for the governance framework to define how the project partners use the Asset Register:
- Design Objectives; prioritised to deliver transparency, security, responsiveness, adaptability and scalability.
- Organisation; designed to be based on Permissioned Blockchain and Proof of Authority and overseen by Trusted Root.
- Governance; designed to support the design objectives listed above and organisation through Principles-based Regulation and effective Decision-Making and provides for User Representation, Flexibility and Innovation.
- Lifecycle; A continuous Lifecycle of Establishment (establishing roles, responsibilities, requirements, verification processes etc), Operation (defining change management, platform maintenance, on-going compliance etc), and Termination (legal requirements, termination processes, decomissioning) applied to Participants, Processes, Technology and Data as a governance framework.
A “flexible governance” model was recommended, that starts principle-based and moves to a prescriptive governance framework, once becoming established, for the following two reasons:
- RecorDER is in early stages of development, a blockchain based approach has not been used before, nor have the proposed use cases been explored previously. It has therefore been encouraged to start with a principle-based governance to allow expanding on areas as practical application is put into place.
- A flexible approach allows for further innovation and possibility of future use cases.
Governance in respect to blockchain was encouraged to co-exist with traditional legal and regulatory framework, having some aspects of governance “on-chain” and some aspects “off-chain”.
Legal Review Summary
Pinsent Masons was subcontracted to consider the legal and regulatory impediments to sharing data in the energy sector, and specialist Swora was subcontracted to research the implications of REMIT specifically.
Key findings:
- Publicly available data reduces the competition law risk but may still be subject to GDPR.
- Disclosure of private data requires consent and may require regulatory change.
- There should be alignment between Supplier Licence Conditions and network codes.
- Permissioning should ensure data is only available to appropriate parties.
- The legal report was used to inform DCP350, which places additional requirements on DNOs to collect asset data and publish in the SWRR, and was included in the revised submission. This will enable the publication of MPAN data in the SWRR.
Data Model Architecture
Partners agreed upon a Data Model structured through registries for user types and roles, permissions and unique asset IDs. The data model utilises asset data published by each network from the ENA’s System Wide Resource Register Project. All information stays in its original databases (e.g. the DSO/ESO databases) and never enters another central repository, unless required.
The platform returns data from across datasets via APIs, governed by smart contract permissions.
- Assets - The asset smart contract as a shared unique identifier for each asset
- Contracts - KYC (Know Your Customer) smart contract for identity validation
- Data Owners -Data Access Controller smart contract for access to datasets
Assets:
- Assets are not represented directly in the SWRR source data – they are aggregated by resource type at site level.
- We instead implement ‘Virtual assets’, creating a unique virtual asset for each resource type that is listed in the SWRR registers. The ‘Virtual assets’ bridge assets and trading units.
- Asset types are taken from the permitted resource types from the SWRR data.
Contracts
- Limited service data published through the SWRR project can be linked to the published asset lists.
- Service contracts are between an asset_controller (assumed to be the site_owner in SWRR data) and either a DSO or ESO. A mapping table has been implemented to enable a service_contract to reference multiple virtual_assets.
- Connection agreements are implemented as a contractual agreement between a site_owner (customer) and a DSO. Each connection agreement will reference a single site.
- In reality a connection_agreement and service_contract would likely be held with different legal entities; we have simplified this relationship by only implementing ESOs and DSOs in this version of the data model.
- Licence areas have been implemented at a site level in this version, see further notes on supply point connections in the Network section.
Network
- Network reinforcement data is not currently published. Network_reinforcements can be associated with a virtual asset that is ‘accepted’ and store the reinforcement_reference that is maintained by the relevant network company.
- Partial supply_point data are available in the current SWRR registers, however MPAN data is unavailable. Supply point connections have been implemented in a separate table to enable easier separation of connection data in future versions.
- Subsequent versions of the model will look to implement a more sophisticated model for supply_points and their network connection data.
- In the proposed network connection structure, assets would be grouped by their inverter (where possible) and their MPAN instead of directly to site data.
- MPANS in turn would reference a supply point, either primary, bulk or grid supply point.
- This would enable a more accurate and flexible representation of assets, which would separate the asset and network connection data and allow suitable parties to master relevant data (e.g. aggregators control asset information and networks maintain connection relationships).
The Platform Prototype
The platform prototype delivered the three use cases set out in the Data Model Work Package.
Key Findings
- Overlapping interests in assets makes a distributed approach suitable for coordination
- Underlying data structure needs to be improved to facilitate links. Publishing MPANs is a necessary, but insufficient step, to facilitate links to assets.
- Common unique reference minimises need for static central register
- A federated architecture where data is maintained by the data owner, but shared widely in a consistent manner, can create a dynamic, living breathing data set that evolves organically and maintains their relationships with other data sets that enrich the single, shared view.
- Contract linking requires mapping MPANs to assets & trading units:
- There is no natural link between STOR (as an example of contract data published by trading unit) and SWRR (as an example of asset data identifiable only at MPAN, site or grid connection).
- Aggregators and retailers need to share this data
- Publication of MPAN (DCP350 and ESO update to Salesforce) will help but full real-time visibility- including smaller assets- needs more data from aggregators and retailers.
Lessons Learnt
The project was initiated at the same time as a number of energy industry data initiatives including the Energy Data Task Force and SWRR. As a result, the background in which the project was being developed was evolving rapidly. While the project was engaged with these initiatives, better coordination leading to clearer alignment would have been beneficial. The cross-industry Modernising Energy Data group, involving BEIS, Ofgem and InnovateUK is now starting to address the coordination of initiatives.
This project took place in parallel to the development of the SWRR. While the decision was taken early in the project to use the SWRR data as the DNO dataset, the scope and format of the SWRR was not finalised for another 6 months. The RecorDER legal review contributed to the specification, particularly the decision to where the definition was not fixed until the first publication. Key fields were redacted, and the project was only able to use open, public data for the demonstration. It may have been more appropriate to agree desired future datasets, rather than be constrained by the current publicly available data. The decision to use only publicly available data meant that any data able to definitively link datasets, such as MPAN, was redacted. In order to align with the legal recommendations, the project principles were demonstrated using arbitrary links and definitions of private data within the datasets.
RecorDER coordinated with the Open Networks SWRR team to define the questions that both projects needed to answer within the legal work package. It was found that open questions did not result in simple, clear answers, and a better approach would have been to define more specific questions.
The innovative approach to the coordination of asset register developed in the RecorDER project was demonstrated by a number of use cases described in the following section, which were either quite conceptual, or served as the building blocks for more concrete use cases. It would have been beneficial to have defined a specific use case that demonstrated more clearly benefit to the industry.
It is now widely recognized that one of the key uses of asset registration data is to facilitate wider participation in flexibility markets. However, with the emergence of multiple market platforms, the cost of repeating the registration process is an impediment. RecorDER would enable the separation of asset registration into markets from the markets themselves, enabling coordination of asset registration into multiple markets from a single platform. Demonstrating this use case would have been a more accessible and tangible output for the project.
The technology and governance work package was undertaken at an early stage in the project, and were only applied to concepts and ideas. It may have been beneficial for the reports to have been written at the end of the project to assess the developed prototype, or for an iterative process to inform the development and design, and then to review once it was built; however, the process was done so to assess the feasibility of the project, particularly of blockchain as a suitable building block.
