LF Energy Webinar: Introduction to TROLIE

This webinar recording introduces potential users in the energy industry to the communications specification defined by TROLIE, an LF Energy project aiming to establish an open conformance standard and cultivate a software ecosystem to accelerate the implementation of reliable, secure, and interoperable systems for the exchange of transmission facility ratings and related information. With FERC Order 881 being implemented next year in the United States, most organizations involved in the operation of the transmission system in North America now need to exchange ratings and related information in an automated, frequent manner. This project will help accelerate their implementation and simplify interoperability.

This webinar provides a technical introduction as well as "how to" content from the perspective of TROLIE's primary users - reliability coordinators and transmission owners.

The webinar was presented by Christopher Atkins of MISO and Tory McKeag of GE Vernova.

Learn more about the TROLIE project at https://lfenergy.org/projects/trolie/.

1. Introduction to TROLIE Christopher Atkins – MISO Tory McKeag – GE Vernova

2. Agenda Project Overview Interoperability Supports Reliability TROLIE Accelerates Interoperability Roadmap Getting Involved

3. Project Overview

4. What is TROLIE? T he Transmission Ratings and Operating Limits Information Exchange (TROLIE) is an open source project whose mission is to design and promulgate an open standard for communicating transmission ratings , operating limits, and related information. The project was created to promote interoperability between entities working together to ensure compliance with FERC Order 881. To that end, TROLIE has three targeted outputs: An OpenAPI Specification that defines how clients and servers interact A Conformance Program to help demonstrate server compatibility with the specification An open commons for the development of TROLIE API clients

5. TROLIE is not … a compliance standard enforced by FERC, NERC, or any other organization, nor an API server implementation that competes with the several vendor offerings in this space.

6. Who is TROLIE? An open source community using a lightweight governance model called Community Specification .

7. What does TROLIE specify? Primary Interactions & Concepts Real-time, Forecast, and Seasonal Rating Exchange for Power System Resources Temporary Exceptions HTTP Conventions API Security Best Practices

8. Interoperability Supports Reliability

9. An Interop Story Isobel is an ISO . Rita is an RTO . Owen is a Transmission Owner. Remy is a REMC. Opal is a Transmission Operator. Rich is a non-FERC jurisdictional RC .

10. Jointly-Owned Intertie Remy submits the most limiting ratings of their owned equipment to Rita Rich submits ratings to Isobel Owen delegates their ratings obligation to Opal Opal submits ratings to Rita Isobel and Rita need to exchange the most limiting facility ratings from their region to determine the most limiting global rating

11. Clearinghouse Concept

12. The Simplest Use Case Rita’s responsibilities include Use real-time, forecast and seasonal ratings from Opal in operational decisions (EMS, markets, outage coordination, planning, etc.) Potentially determine limits based on stability analysis. Opal’s responsibilities include Compute real-time and forecast ratings at least hourly for use in operations, determine seasonal ratings, and share all with Rita. Use the same limits as Rita in operations.

13. Plenty of Interop Challenges Minimally, Rita needs to deploy new software for computing and publishing forecast ratings. Real-time rating publishing may also be needed, or an existing implementation expanded. Both parties need an agreed technology protocol for the data exchange. Rita needs to know exactly what data to expect from Opal, so that she can determine if she’s missing something. Both parties need to agree on the names for the components of the network model they will exchange. What if the systems that compute or use different kinds of ratings (real-time, forecast, seasonal) use different names for elements of the model? Cyber security concerns (networks, authentication) What do both parties do in case of a communications blackout? Opal needs to determine if Rita can ever override the ratings provided, and if he needs to get the in-use limit back. Both parties must agree on how exceptions to the AAR (forecast and real-time) processes are shared and stored.

14. As Complexity Goes up, Challenges Pile On What if there are multiple owners of the facility? What about tie lines between reliability coordinators? What if parties use different units to represent ratings (MVA vs amps vs MW + PF)? What if parties use different durations/terminology for emergency ratings in their operations procedures? What if a transmission owner sits in multiple RC footprints? What if an entity has multiple roles in different parts of their network (RC for themselves vs TO in other RC’s footprint vs RC for other TOs)? What if I don’t have any FERC 881 responsibility for line in a neighboring footprint, but the limit of that line affects my flows? What if our timeline windows for forecast ratings don’t align?

15. Complexity added by Vendor Landscape Vendor 1 makes EMS and market software Vendor 2 makes EMS and outage management software Vendor 3 makes transmission line sensor solutions Vendor 4 makes ratings computation solutions

16. TROLIE Accelerates Interoperability

17. Who should use TROLIE? Organizations Required to Receive Ratings Transmission Providers (as defined by FERC) ISO/RTOs, other RCs Organizations Required to Send Ratings Transmission Owners ISO/RTO/RC members Neighboring ISO/RTO/RCs Vendors of Systems That Use ratings, such as EMS, markets, other operational planning tools Produce ratings, such as EMS, forecasting, sensor systems Store ratings for historical archive People Developers Architects Supporting engineers Reliability Coordinator Transmission Owner Transmission Operator Vendor A TROLIE Server Vendor B TROLIE Client In-house developed TROLIE Client

18. Using the TROLIE Specification TROLIE specification defined with OpenAPI Defines a RESTful web service contract – communication is JSON over HTTPS Exchange divided into client and server roles Servers are typically Transmission Providers / Reliability Coordinators Clients are typically Transmission Owners, Reliability Coordinator members, etc. Many tools available to work with OpenAPI specifications in almost any popular programming language - https://openapi.tools/ Use the resources and specification available on the web https://trolie.energy/ - complementary material and usage examples https://trolie.energy/spec - specification user interface and explorer https://trolie.energy/openapi.yaml - formal specification file

19. By Example- Using TROLIE for Forecast AARs Submit forecast AARs to a server: https://trolie.energy/example-narratives/submitting-forecasts.html Query the in-use forecast AARs from a server: https://trolie.energy/example-narratives/in-use-forecasts.html

20. Key TROLIE Domain Concepts https://trolie.energy/concepts

21. Roadmap

22. TROLIE Project Goals Accelerate the implementation of Order 881 by: Building tools (specifications, SDKs, compatibility toolkits) to help construct interoperable ratings exchange software; Writing documentation to construct a shared language, design and practices; Building a community of practitioners to pull forward perspectives and requirements from Order 881 integration projects before they are discovered late.

23. Roadmap Functional areas still to be covered Directional ratings Minor refinements to various areas in spec (real-time ratings, AAR exceptions) Seasonal ratings “Peer” Profile (handle neighboring RCs, tie lines) Additional examples, doc enhancements Additional security guidance Conformance/Compatibility Test Tooling Client SDKs

24. Getting Involved

25. Join our Community! We want more grid operators and solution vendors Help us improve shared language Discover requirements Fill gaps Help us think through the hard problems in the scope What are the consequences of the data exchanges? What interactions are really required? Document corner cases to allow ratings to be up to date in all systems and consistent. Find mismatches between technical needs and procedures and agreements

26. Many Ways to Interact with the Community As a consumer , simply use TROLIE Implement software that leverages the specification and tools Leverage the documentation for support and ramp up Requires no obligation to TROLIE project beyond industry standard open source license agreements Community Specification License (CSL 1.0) for specification Apache Software License (ASL 2.0) for software As a critic , comment on TROLIE Create and comment on GitHub issues against https://github.com/trolie/spec . Requires a free GitHub account. No obligation to TROLIE project.

27. More Ways to Interact with the Community As a contributor , improve TROLIE Submit source code, specifications or documentation changes via GitHub pull requests. Requires signing contributor license agreement based on Community Specification License ( CSL) 1.0. As an editor , improve TROLIE documentation We hope to have a lighter version of the contributor role that is only focused on improving documentation, and therefore does not necessarily require signing the contributor agreement. As a maintainer , drive TROLIE Join regular technical steering committee (TSC) rhythms to drive roadmap, make key decisions on TROLIE direction. May or may not overlap with contributor role.