From aa754d200569da6945f35f6150efc10126cfd769 Mon Sep 17 00:00:00 2001 From: Christopher Atkins Date: Tue, 22 Oct 2024 16:51:49 +0000 Subject: [PATCH] updated article --- .../20240118-Pulling-into-the-Station.md | 80 +++++++++++++++++-- .../20240330-Forecasting-API-stable.md | 2 +- .../20240701-RealTime-API-stable.md | 2 +- 3 files changed, 76 insertions(+), 8 deletions(-) diff --git a/docs/community-events/20240118-Pulling-into-the-Station.md b/docs/community-events/20240118-Pulling-into-the-Station.md index 4de97148..5e4d4718 100644 --- a/docs/community-events/20240118-Pulling-into-the-Station.md +++ b/docs/community-events/20240118-Pulling-into-the-Station.md @@ -4,7 +4,7 @@ parent: Community Events --- {: .announcement } -Join us on Wednesday October 30th 2024 for the webinar [A Lap Around TROLIE 1.0](javascript:alert('TODO'))! +Join us on Wednesday November 20th, 2024 at 1:30pm ET for the webinar [A Lap Around TROLIE 1.0](javascript:alert('TODO'))! # Pulling into the Station--TROLIE 1.0 Nears Journey's End @@ -31,11 +31,79 @@ Since our last [Community Post](../community-events/), we've accomplished a lot. ## Supported Use Cases -TODO: copy use cases from previous announcements and add the balance +Let's discuss these changes in terms of the use cases they support, starting with the +simplest conceptually, but perhaps the most difficult to specify. + +### Seasonal Ratings + +The concept of a [seasonal rating](../concepts.md#seasonal-ratings) differs +significantly from one grid operator to the next: Some operate to a seasonal +rating that changes monthly, while others are obliged to newly develop four +uniquely determined seasonal ratings per Order 881. Moreover, the calendar dates and times +that bracket these seasons can occur at any time in the calendar. Clearly there is +no canonical "Fall" when it comes to seasonal ratings. In fact, one Transmission Owner's Fall season +may begin and end at different times of year depending on the location of the transmission facility. + +By examining the invariants of seasonal ratings, the TROLIE specification has +defined both a slim and detailed format for seasonal ratings proposals and +seasonal limits snapshots that is sufficiently general to address all of these +scenarios. + +### Managing Temporary AAR Exceptions and Seasonal Overrides + +Quoting the [specification](https://trolie.energy/spec#tag/Seasonal-Overrides): + +> A Seasonal Override is an instruction to use a temporary static rating set in +> lieu of any concurrent Seasonal Rating for a given segment. +> +> A typical use case is a so-called "de-rate" due to temporary clearance issue +> for a transmission facility that is exempt from providing AARs. Exempt +> facilities normally operate against a seasonal rating, yet rather than provide a +> seasonal ratings schedule update, the Ratings Provider could send a Seasonal +> Override. During the provided duration of the override, the Transmission +> Provider would operate to the Seasonal Override rather than any ratings that +> would have been used from the seasonal rating schedule. +> +> In contrast, for a segment that is not exempt from providing AARs, the Ratings +> Provider would issue a Temporary AAR Exception to the Clearinghouse Provider to +> address a clearance issue or other temporary operating condition that calls for +> a static rating. + +In previous community updates, we've called out Forecast and Real-Time use cases. +We include those here along with additional scenarios that have been addressed. + +### Regional Clearing + +On interties between Transmission Providers (TP), there is an additional timing +consideration. While each TP will obtain the [locally-limiting ratings](../concepts.md#locally-limiting-rating) for their end of the tie on +their own time, in order to operate to the same [limits along the seam](../concepts.md#globally-limiting-rating), the TPs must exchange their +[regionally-limiting ratings](../concepts.md#regionally-limiting-rating)(RLRs) as soon as possible +after they've determined those RLRs. + +TROLIE calls this [RC-to-RC Reconciliation](../articles/RC-to-RC-reconciliation.md). + +### Forecasting Use Cases + +* Submitting Forecast Ratings Proposals +* Obtaining Forecast Ratings Proposal Status +* Obtaining Forecast Limits Snapshots, including: + - Normal snapshots that provide just the determined limits + - Detailed snapshots that provide all of the inputs used by the Clearinghouse + Provider to determine the limits, including all proposals and overrides. +* Slim proposals and snapshots that leverage information in the header to reduce the verbosity of the ratings / limits. + +### Real-Time Use Cases + +* Submitting Real-Time Ratings Proposals +* Obtaining Real-Time Ratings Proposal Status +* Obtaining Real-Time Limits Snapshots, including: + - Normal snapshots that provide just the determined limits + - Detailed snapshots that provide all of the inputs used by the Clearinghouse + Provider to determine the limits, including all proposals and overrides. +* Slim proposals and snapshots that leverage information in the header to reduce the verbosity of the ratings / limits. + ## Call to Action -TODO: -* Calling all vendors! Please reach out to the maintainers with questions -* Join the webinar -* ... \ No newline at end of file +* Calling all vendors! Please reach out to the maintainers with questions. +* Join the webinar on November 20th and bring your questions / concerns. diff --git a/docs/community-events/20240330-Forecasting-API-stable.md b/docs/community-events/20240330-Forecasting-API-stable.md index a1e7c165..15c11d48 100644 --- a/docs/community-events/20240330-Forecasting-API-stable.md +++ b/docs/community-events/20240330-Forecasting-API-stable.md @@ -26,7 +26,7 @@ Implementors should consider the specification stable in its support of the foll * Submitting Forecast Ratings Proposals * Obtaining Forecast Ratings Proposal Status * Obtaining Forecast Limits Snapshots, including: - - "Slim" snapshots that provide just the determined limits + - ~~Slim~~ Normal snapshots that provide just the determined limits - Detailed snapshots that provide all of the inputs used by the Clearinghouse Provider to determine the limits, including all proposals and overrides. diff --git a/docs/community-events/20240701-RealTime-API-stable.md b/docs/community-events/20240701-RealTime-API-stable.md index 4d337c6c..40effaab 100644 --- a/docs/community-events/20240701-RealTime-API-stable.md +++ b/docs/community-events/20240701-RealTime-API-stable.md @@ -29,7 +29,7 @@ Implementors should consider the specification stable in its support of the foll * Submitting Real-Time Ratings Proposals * Obtaining Real-Time Ratings Proposal Status * Obtaining Real-Time Limits Snapshots, including: - - "Slim" snapshots that provide just the determined limits + - ~~Slim~~ Normal snapshots that provide just the determined limits - Detailed snapshots that provide all of the inputs used by the Clearinghouse Provider to determine the limits, including all proposals and overrides.