SlideShare a Scribd company logo
1 of 27
Introduction to
TROLIE
Christopher Atkins – MISO
Tory McKeag – GE Vernova
Agenda
● Project Overview
● Interoperability Supports Reliability
● TROLIE Accelerates Interoperability
● Roadmap
● Getting Involved
Project Overview
What is TROLIE?
The 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
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.
Who is TROLIE?
An open source community
using a lightweight
governance model called
Community Specification.
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
Interoperability
Supports
Reliability
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.
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
Clearinghouse Concept
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.
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.
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?
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
TROLIE
Accelerates
Interoperability
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
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
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
Key TROLIE Domain Concepts
● https://trolie.energy/concepts
Roadmap
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.
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
Getting Involved
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
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.
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.

More Related Content

Similar to LF Energy Webinar: Introduction to TROLIE

DSO-LG 2021 Reboot: Policy As Code (Anders Eknert)
DSO-LG 2021 Reboot: Policy As Code (Anders Eknert)DSO-LG 2021 Reboot: Policy As Code (Anders Eknert)
DSO-LG 2021 Reboot: Policy As Code (Anders Eknert)Michael Man
 
From class to architecture
From class to architectureFrom class to architecture
From class to architectureMarcin Hawraniak
 
Cloud native policy enforcement with Open Policy Agent
Cloud native policy enforcement with Open Policy AgentCloud native policy enforcement with Open Policy Agent
Cloud native policy enforcement with Open Policy AgentLibbySchulze
 
why is the idea of a standard network protocol such as the OSI refer.pdf
why is the idea of a standard network protocol such as the OSI refer.pdfwhy is the idea of a standard network protocol such as the OSI refer.pdf
why is the idea of a standard network protocol such as the OSI refer.pdfbermanbeancolungak45
 
Understanding Open Protocols in Building Automation
Understanding Open Protocols in Building AutomationUnderstanding Open Protocols in Building Automation
Understanding Open Protocols in Building AutomationSchneider Electric
 
LFN-Porto-multi-cloud-interaction-model-2022.pptx
LFN-Porto-multi-cloud-interaction-model-2022.pptxLFN-Porto-multi-cloud-interaction-model-2022.pptx
LFN-Porto-multi-cloud-interaction-model-2022.pptxyairmodernlife
 
Observability for Application Developers (1)-1.pptx
Observability for Application Developers (1)-1.pptxObservability for Application Developers (1)-1.pptx
Observability for Application Developers (1)-1.pptxOpsTree solutions
 
Asynchronous Frameworks.pptx
Asynchronous Frameworks.pptxAsynchronous Frameworks.pptx
Asynchronous Frameworks.pptxganeshkarthy
 
OIF Interop: The Key to Unlocking the Benefits of SDN
OIF Interop: The Key to Unlocking the Benefits of SDNOIF Interop: The Key to Unlocking the Benefits of SDN
OIF Interop: The Key to Unlocking the Benefits of SDNDeborah Porchivina
 
Leveraging Open Standards to Build Highly Extensible Autonomous Systems
Leveraging Open Standards to Build Highly Extensible Autonomous SystemsLeveraging Open Standards to Build Highly Extensible Autonomous Systems
Leveraging Open Standards to Build Highly Extensible Autonomous SystemsICS
 
Learnings from Developing a New B2B SaaS Product (Suryaveer Lodha (Sunny) Pro...
Learnings from Developing a New B2B SaaS Product (Suryaveer Lodha (Sunny) Pro...Learnings from Developing a New B2B SaaS Product (Suryaveer Lodha (Sunny) Pro...
Learnings from Developing a New B2B SaaS Product (Suryaveer Lodha (Sunny) Pro...IT Arena
 
Manage Microservices Chaos and Complexity with Observability
Manage Microservices Chaos and Complexity with ObservabilityManage Microservices Chaos and Complexity with Observability
Manage Microservices Chaos and Complexity with ObservabilityNGINX, Inc.
 
Open source presentation enterprise ireland 2010
Open source presentation enterprise ireland 2010Open source presentation enterprise ireland 2010
Open source presentation enterprise ireland 2010Tim Willoughby
 
Designing Apps for Runtime Fabric: Logging, Monitoring & Object Store Persist...
Designing Apps for Runtime Fabric: Logging, Monitoring & Object Store Persist...Designing Apps for Runtime Fabric: Logging, Monitoring & Object Store Persist...
Designing Apps for Runtime Fabric: Logging, Monitoring & Object Store Persist...Eva Mave Ng
 
On making standards organizations & open source communities work hand in hand
On making standards organizations & open source communities work hand in handOn making standards organizations & open source communities work hand in hand
On making standards organizations & open source communities work hand in handBenjamin Cabé
 

Similar to LF Energy Webinar: Introduction to TROLIE (20)

DSO-LG 2021 Reboot: Policy As Code (Anders Eknert)
DSO-LG 2021 Reboot: Policy As Code (Anders Eknert)DSO-LG 2021 Reboot: Policy As Code (Anders Eknert)
DSO-LG 2021 Reboot: Policy As Code (Anders Eknert)
 
From class to architecture
From class to architectureFrom class to architecture
From class to architecture
 
Cloud native policy enforcement with Open Policy Agent
Cloud native policy enforcement with Open Policy AgentCloud native policy enforcement with Open Policy Agent
Cloud native policy enforcement with Open Policy Agent
 
why is the idea of a standard network protocol such as the OSI refer.pdf
why is the idea of a standard network protocol such as the OSI refer.pdfwhy is the idea of a standard network protocol such as the OSI refer.pdf
why is the idea of a standard network protocol such as the OSI refer.pdf
 
Understanding Open Protocols in Building Automation
Understanding Open Protocols in Building AutomationUnderstanding Open Protocols in Building Automation
Understanding Open Protocols in Building Automation
 
LFN-Porto-multi-cloud-interaction-model-2022.pptx
LFN-Porto-multi-cloud-interaction-model-2022.pptxLFN-Porto-multi-cloud-interaction-model-2022.pptx
LFN-Porto-multi-cloud-interaction-model-2022.pptx
 
Observability for Application Developers (1)-1.pptx
Observability for Application Developers (1)-1.pptxObservability for Application Developers (1)-1.pptx
Observability for Application Developers (1)-1.pptx
 
Asynchronous Frameworks.pptx
Asynchronous Frameworks.pptxAsynchronous Frameworks.pptx
Asynchronous Frameworks.pptx
 
Go at uber
Go at uberGo at uber
Go at uber
 
OIF Interop: The Key to Unlocking the Benefits of SDN
OIF Interop: The Key to Unlocking the Benefits of SDNOIF Interop: The Key to Unlocking the Benefits of SDN
OIF Interop: The Key to Unlocking the Benefits of SDN
 
Microservices
MicroservicesMicroservices
Microservices
 
Design time governance
Design time governanceDesign time governance
Design time governance
 
Leveraging Open Standards to Build Highly Extensible Autonomous Systems
Leveraging Open Standards to Build Highly Extensible Autonomous SystemsLeveraging Open Standards to Build Highly Extensible Autonomous Systems
Leveraging Open Standards to Build Highly Extensible Autonomous Systems
 
Learnings from Developing a New B2B SaaS Product (Suryaveer Lodha (Sunny) Pro...
Learnings from Developing a New B2B SaaS Product (Suryaveer Lodha (Sunny) Pro...Learnings from Developing a New B2B SaaS Product (Suryaveer Lodha (Sunny) Pro...
Learnings from Developing a New B2B SaaS Product (Suryaveer Lodha (Sunny) Pro...
 
Manage Microservices Chaos and Complexity with Observability
Manage Microservices Chaos and Complexity with ObservabilityManage Microservices Chaos and Complexity with Observability
Manage Microservices Chaos and Complexity with Observability
 
Open source presentation enterprise ireland 2010
Open source presentation enterprise ireland 2010Open source presentation enterprise ireland 2010
Open source presentation enterprise ireland 2010
 
FICO Open Shift presentation
FICO Open Shift presentationFICO Open Shift presentation
FICO Open Shift presentation
 
Designing Apps for Runtime Fabric: Logging, Monitoring & Object Store Persist...
Designing Apps for Runtime Fabric: Logging, Monitoring & Object Store Persist...Designing Apps for Runtime Fabric: Logging, Monitoring & Object Store Persist...
Designing Apps for Runtime Fabric: Logging, Monitoring & Object Store Persist...
 
On making standards organizations & open source communities work hand in hand
On making standards organizations & open source communities work hand in handOn making standards organizations & open source communities work hand in hand
On making standards organizations & open source communities work hand in hand
 
Soa 2013
Soa 2013Soa 2013
Soa 2013
 

Recently uploaded

Oauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoftOauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoftshyamraj55
 
BT & Neo4j _ How Knowledge Graphs help BT deliver Digital Transformation.pptx
BT & Neo4j _ How Knowledge Graphs help BT deliver Digital Transformation.pptxBT & Neo4j _ How Knowledge Graphs help BT deliver Digital Transformation.pptx
BT & Neo4j _ How Knowledge Graphs help BT deliver Digital Transformation.pptxNeo4j
 
Working together SRE & Platform Engineering
Working together SRE & Platform EngineeringWorking together SRE & Platform Engineering
Working together SRE & Platform EngineeringMarcus Vechiato
 
Designing for Hardware Accessibility at Comcast
Designing for Hardware Accessibility at ComcastDesigning for Hardware Accessibility at Comcast
Designing for Hardware Accessibility at ComcastUXDXConf
 
AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101vincent683379
 
WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024Lorenzo Miniero
 
Structuring Teams and Portfolios for Success
Structuring Teams and Portfolios for SuccessStructuring Teams and Portfolios for Success
Structuring Teams and Portfolios for SuccessUXDXConf
 
WSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptxWSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptxJennifer Lim
 
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdfIntroduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdfFIDO Alliance
 
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...CzechDreamin
 
Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...
Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...
Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...CzechDreamin
 
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdfLinux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdfFIDO Alliance
 
Google I/O Extended 2024 Warsaw
Google I/O Extended 2024 WarsawGoogle I/O Extended 2024 Warsaw
Google I/O Extended 2024 WarsawGDSC PJATK
 
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdfSimplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdfFIDO Alliance
 
ECS 2024 Teams Premium - Pretty Secure
ECS 2024   Teams Premium - Pretty SecureECS 2024   Teams Premium - Pretty Secure
ECS 2024 Teams Premium - Pretty SecureFemke de Vroome
 
Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...
Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...
Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...FIDO Alliance
 
IESVE for Early Stage Design and Planning
IESVE for Early Stage Design and PlanningIESVE for Early Stage Design and Planning
IESVE for Early Stage Design and PlanningIES VE
 
Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024Patrick Viafore
 
ERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage IntacctERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage IntacctBrainSell Technologies
 

Recently uploaded (20)

Oauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoftOauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoft
 
BT & Neo4j _ How Knowledge Graphs help BT deliver Digital Transformation.pptx
BT & Neo4j _ How Knowledge Graphs help BT deliver Digital Transformation.pptxBT & Neo4j _ How Knowledge Graphs help BT deliver Digital Transformation.pptx
BT & Neo4j _ How Knowledge Graphs help BT deliver Digital Transformation.pptx
 
Working together SRE & Platform Engineering
Working together SRE & Platform EngineeringWorking together SRE & Platform Engineering
Working together SRE & Platform Engineering
 
Designing for Hardware Accessibility at Comcast
Designing for Hardware Accessibility at ComcastDesigning for Hardware Accessibility at Comcast
Designing for Hardware Accessibility at Comcast
 
AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101
 
Overview of Hyperledger Foundation
Overview of Hyperledger FoundationOverview of Hyperledger Foundation
Overview of Hyperledger Foundation
 
WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024
 
Structuring Teams and Portfolios for Success
Structuring Teams and Portfolios for SuccessStructuring Teams and Portfolios for Success
Structuring Teams and Portfolios for Success
 
WSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptxWSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptx
 
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdfIntroduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
 
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
 
Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...
Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...
Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...
 
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdfLinux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
 
Google I/O Extended 2024 Warsaw
Google I/O Extended 2024 WarsawGoogle I/O Extended 2024 Warsaw
Google I/O Extended 2024 Warsaw
 
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdfSimplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
 
ECS 2024 Teams Premium - Pretty Secure
ECS 2024   Teams Premium - Pretty SecureECS 2024   Teams Premium - Pretty Secure
ECS 2024 Teams Premium - Pretty Secure
 
Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...
Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...
Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...
 
IESVE for Early Stage Design and Planning
IESVE for Early Stage Design and PlanningIESVE for Early Stage Design and Planning
IESVE for Early Stage Design and Planning
 
Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024
 
ERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage IntacctERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage Intacct
 

LF Energy Webinar: Introduction to 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
  • 4. What is TROLIE? The 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
  • 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
  • 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
  • 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
  • 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
  • 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.

Editor's Notes

  1. Remy owns and operates the green bits. Opal owns and orange bits and is the BA. Rich owns the blue bits. Owen owns the pink. Rita is the RC for Remy and Opal. Isobel is the RC for Rich.
  2. Plan here is to walk through both Usage examples, perhaps coordinating the reason TOs WOULD query the in-use forecasts.
  3. Using follow up from the examples, walk through concepts