LF Energy Webinar: Carbon Data Specifications: Mechanisms to Improve Data Access/Standardization in the Energy Industry

This LF Energy webinar took place June 20, 2024. It featured:
-Alex Thornton, LF Energy
-Hallie Cramer, Google
-Daniel Roesler, UtilityAPI
-Henry Richardson, WattTime

In response to the urgency and scale required to effectively address climate change, open source solutions offer significant potential for driving innovation and progress. Currently, there is a growing demand for standardization and interoperability in energy data and modeling. Open source standards and specifications within the energy sector can also alleviate challenges associated with data fragmentation, transparency, and accessibility. At the same time, it is crucial to consider privacy and security concerns throughout the development of open source platforms.

This webinar will delve into the motivations behind establishing LF Energy’s Carbon Data Specification Consortium. It will provide an overview of the draft specifications and the ongoing progress made by the respective working groups.

Three primary specifications will be discussed:
-Discovery and client registration, emphasizing transparent processes and secure and private access
-Customer data, centering around customer tariffs, bills, energy usage, and full consumption disclosure
-Power systems data, focusing on grid data, inclusive of transmission and distribution networks, generation, intergrid power flows, and market settlement data

1. Carbon Data Specifications Mechanisms to Improve Data Access and Standardization in the E lectricity Sector

2. Antitrust Policy Notice Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at linuxfoundation.org/antitrust-policy . If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

3. The importance of open standards in the energy sector Alex Thornton, Executive Director at LF Energy

4. LF Energy accelerates the energy transition by building communities to develop open technologies and standards.

5. CI/CD technical architecture design CI environment delivery Release engineering services Project planning, build & system go-live Delivery of project collaboration solutions, domain registrations & websites Building large, thriving, sustainable ecosystems Value Neutral Management Developer Recruitment and Relations Training Content IT Beyond Version Control Community Programs Support and Resources Define problem project/code solving Recruit widely deployed projects/communities Curate projects with natural adjacency to existing project Demonstrate where project fits in to broader tech innovation Provide home for IP assets Define a governance structure for decisions Separate business decisions from technical Curate sense of identity superseding individuals or firms Maintain IT infrastructure In person Meetups Events Hackathons 3 rd Party Events Evangelism Online Email lists and calls/meetings IRC/Slack Github, Gitlab, etc. Stackoverflow 3rd party repos Technical Code samples Getting started guides How to’s/FAQ API/SDK Research & Comms Case Stud ies Whitepapers Empirical studies Webinars Social & blogs Engage Massive Open Online Course (EdX) Webinars Snackable learning Train eLearning Classroom learning Subscription learning Certify Skills based testing Ongoing engagement Advocate/Influence Programs Rewards/Recognition Startup/Incubator Engagement Student programs PR/AR Self Service FAQ Forum Knowledgebase Onboarding Community/Responsive Slack/IRC Email Stackoverflow IT operations/Release Mgmt Standards IPR Monitoring Document prep & advancement Liaison programs Conformance programs

6. LF Energy Members

7. Why do we need standards?

8. Why do we need standards? Standards facilitate interoperability and safety. Without consistent, international standards, interoperability and scalability are hard! Source: https://www.gearpatrol.com/archive/a118234/guide-to-plugs-and-sockets-by-country/

9. Why do we need standards? The electric grid is the largest and most complex machine ever made. It’s a system of systems. We operate in a global economy with multi-national companies and trade across borders. Standards ensure these technical and economic systems function and thrive.

10. Traditional approach to standards Deliberate, consensus-driven approach ensures participants are comfortable with resulting standards and will adopt them. This approach works quite well, especially with relatively stable hardware ecosystems.

11. Why do we need open standards? Driven by digitalization and decarbonization goals, the electric grid is changing fast. Conservatively slow and closed standards process sometimes isn’t fast enough to keep up with the pace of change and incorporate all necessary expertise. Open standards are fast, agile, facilitate widespread contribution and adoption, and meet the pace demanded of the digital energy transition. Graphic: DOE 2020 Smart Grid System Report https://www.energy.gov/sites/default/files/2022-05/2020%20Smart%20Grid%20System%20Report_0.pdf

12. Open approach to standards Community specification process increases speed, agility, and pool of expertise available to contribute. Specification is eventually submitted to standard body to become formally recognized. Software reference implementations of the standard reduce variance of interpretations and duplication of effort in implementation.

13. Governance of open standards Project charter defines the scope for collaboration, legal structure and governance model A license determines how the specification can be used Defined governance framework provides long-term, structured decision-making

14. Linux Foundation and open standards The Linux Foundation has tools to make setting up well-structured standards projects easier: Community Specification : provides a “standards-organization-in-a-repo.” All you have to do is clone or copy the Community Specifications repository, fill in a few details, and get started. Joint Development Foundation : provides the corporate and legal infrastructure to enable groups to quickly establish and operate lightweight collaborations to develop technical specifications, standards, and source code. We’re an approved submitter to ISO , with success submitting standards such as OpenChain ISO/IEC 5230:2020 . We’re also formal partner of ETSI .

15. Summary Standards ensure technical and economics systems function and thrive. Open standards are fast, agile, and transparent. Open standards have clearly defined governance structures. The Linux Foundation has success partnering with standards bodies such as ISO and ETSI.

16. Project Motivation: Why Google got involved Hallie Cramer , Technical Program Manager at Google

17. Google’s Energy Journey

18. Why 100% Annual Renewable Energy Matching is Not Enough

19. Interest in the CDSC

20. Aiming to accelerate pathways to grid decarbonization by providing data that is:

21. Better data is a foundational building block to develop the solutions needed for any clean energy future.

22. Tour of discovery and connectivity specs Daniel Roesler, CTO at UtilityAPI

23. The problem: Getting data once is easy Getting data at scale is hard

24. What's hard about getting utility customer data at scale? Need way more data nowadays than just the customer's bills or monthly kwh Most customers have no idea how to get their data needed for analysis Individual customer data is private and sensitive and requires consent to get Fragmented across many utilities and other central authorities Data formats are mostly ad-hoc or proprietary with little documentation Hard to find what utilities offer what methods of access and what vendors can qualify Many don't offer digital methods of access (paper forms or manual processes only) For those that do have digital access, vendor registration is often slow, complex, and expensive Existing standards for digital access are proprietary, complex, and have major gaps Regulatory oversight is highly complex because current specifications require expert knowledge

25. Soooo… what are the components of a scalable connectivity standard?

26. What are the components of a scalable connectivity standard?

27. Discovery Find what utilities and other central entities that offer data access. What are the components of a scalable connectivity standard?

28. Discovery Find what utilities and other central entities that offer data access. Registration + Connectivity Sign up and establish connections with utilities. What are the components of a scalable connectivity standard?

29. Discovery Find what utilities and other central entities that offer data access. Registration + Connectivity Sign up and establish connections with utilities. CDSC-WG1-01 ("Server Metadata") What are the components of a scalable connectivity standard?

30. Discovery Find what utilities and other central entities that offer data access. Registration + Connectivity Sign up and establish connections with utilities. CDSC-WG1-01 ("Server Metadata") CDSC-WG1-02 ("Client Registration") What are the components of a scalable connectivity standard?

31. CDSC-WG1's Connectivity Specifications: CDSC-WG1-01 ("Server Metadata") How utilities and other centralized entities can disclose what data and capabilities they offer. CDSC-WG1-02 ("Client Registration") How vendors can register, onboard, and manage their connectivity with utilities and other centralized entities.

32. CDSC-WG1's Connectivity Specifications: CDSC-WG1-01 ("Server Metadata") How utilities and other centralized entities can disclose what data and capabilities they offer. CDSC-WG1-02 ("Client Registration") How vendors can register, onboard, and manage their connectivity with utilities and other centralized entities. From: https://daniel-utilityapi.github.io/Customer-Data/specs/cdsc-wg1-02/overview From: https://daniel-utilityapi.github.io/Customer-Data/specs/cdsc-wg1-01/overview

33. Who can benefit from these connectivity specifications?

34. Other specifications! Our first two specifications ( CDSC-WG1-01/02 ) can be used by other standards to streamline third party service provider registration and onboarding (DER, EE, EV, DR, etc.). For example, our Customer Data specification ( CDSC-WG1-03 ) uses these connectivity specs as its base. By unblocking service provider registration and onboarding, we accelerate adoption of new innovative programs, grid flexibility, and deployment of clean energy technologies.

35. Tour of customer data specs Daniel Roesler, CTO at UtilityAPI

36. What are the components of a scalable customer data access standard? Discovery Find what utilities and other central entities that offer data access. Registration + Connectivity Sign up and establish connections with utilities. CDSC-WG1-01 ("Server Metadata") CDSC-WG1-02 ("Client Registration")

37. What are the components of a scalable customer data access standard? Discovery Find what utilities and other central entities that offer data access. Registration + Connectivity Sign up and establish connections with utilities. Authorization Get individual customer consent to access their data. CDSC-WG1-01 ("Server Metadata") CDSC-WG1-02 ("Client Registration")

38. What are the components of a scalable customer data access standard? Discovery Find what utilities and other central entities that offer data access. Registration + Connectivity Sign up and establish connections with utilities. Authorization Get individual customer consent to access their data. Data Access Retrieve authorized customer data in a standardized format. CDSC-WG1-01 ("Server Metadata") CDSC-WG1-02 ("Client Registration")

39. What are the components of a scalable customer data access standard? Discovery Find what utilities and other central entities that offer data access. Registration + Connectivity Sign up and establish connections with utilities. Authorization Get individual customer consent to access their data. Data Access Retrieve authorized customer data in a standardized format. CDSC-WG1-01 ("Server Metadata") CDSC-WG1-02 ("Client Registration") CDSC-WG1-03 ("Customer Data")

40. CDSC-WG1's Customer Data Specifications: CDSC-WG1-03 ("Customer Data") How vendors can obtain customer authorization and how the authorized customer data should be formatted. Target use cases: Carbon Accounting Decarbonization Projects Distributed Grid Flexibility Building Benchmarking From: https://daniel-utilityapi.github.io/Customer-Data/specs/cdsc-wg1-03/overview

41. How you can get involved!

42. How to get involved: Visit our website: https://customerdata.carbondataspec.org/ Join the mailing list. Attend the working group meetings. Give feedback on the specification drafts.

43. Tour of power systems data specs Henry Richardson, Senior Analyst at WattTime

44. Power System Data Spec Intent “D efine an open specification for raw electric power system data to facilitate a systematic and more accurate approach to report grid emissions.” Creating a unified specification for data retrieved from power system operators, including: Generation mix Power imports and exports Power market data Delivery capacities and/or constraints Power generation emissions

45. Key Concepts T opology levels: The hierarchy of resource levels in relation to the other resource types. (ex. Interconnection, Balancing Authority Area, Zone, Transmission Node/Substation, Generating Plant, Meter, et). PowerSystemResource (PSR): A specific resource within the power system, which could range from the balancing authority to individual power plants

46. Power System Data Spec Structure System Level Information: /power-system-resources/list-topology-levels /power-system-resources/list-resources /power-system-resources/list-prices Power System Resource ‘Static’ Information: /power-system-resource/{id}/topology (GET) /power-system-resource/{id}/describe (GET) /power-system-resource/{id}/capacity (GET) /power-system-resource/{id}/transmission-capacity (GET) Power System Resource Timeseries Information: /power-system-resource/{id}/timeseries/emissions (GET) /power-system-resource/{id}/timeseries/generation (GET) /power-system-resource/{id}/timeseries/demand (GET) /power-system-resource/{id}/timeseries/imports (GET) /power-system-resource/{id}/timeseries/exports (GET) /power-system-resource/{id}/timeseries/price (GET) /power-system-resource/{id}/timeseries/curtailment (GET)

47. Open Questions Is price definition sufficient? Is the spec’s treatment of prices, using a defined price set, sufficient to address different wholesale prices that may arise? https://github.com/carbon-data-specification/Power-Systems-Data/issues/112 Should imports and exports be combined for a given PSR? How should imports and exports be treated? https://github.com/carbon-data-specification/Power-Systems-Data/issues/111 Is the solution to transmission robust? Can the transmission capacity endpoint be merged with the sibling hierarchy endpoint? How is transmission discoverable? Should transmission be a PSR? https://github.com/carbon-data-specification/Power-Systems-Data/issues/111

48. Q&A