From da622ccde387cbdbb4472f9dbd6c165ae5715e0a Mon Sep 17 00:00:00 2001 From: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> Date: Thu, 26 Sep 2024 12:55:55 -0700 Subject: [PATCH] Added concepts for seasonal, conditional ratings (#137) * Added concepts for seasonal, conditional ratings * Cleaned up spelling errors * Update docs/concepts.md Co-authored-by: Christopher Atkins <57670484+catkins-miso@users.noreply.github.com> Signed-off-by: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> * Update cspell.json Co-authored-by: Christopher Atkins <57670484+catkins-miso@users.noreply.github.com> Signed-off-by: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> * Update docs/decision-log/conditional-ratings.md Co-authored-by: Christopher Atkins <57670484+catkins-miso@users.noreply.github.com> Signed-off-by: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> * Update docs/decision-log/conditional-ratings.md Co-authored-by: Christopher Atkins <57670484+catkins-miso@users.noreply.github.com> Signed-off-by: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> * Filled in gaps * Re-orged concepts * Update docs/decision-log/seasonal-ratings-schedule.md Co-authored-by: Christopher Atkins <57670484+catkins-miso@users.noreply.github.com> Signed-off-by: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> --------- Signed-off-by: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> Co-authored-by: Christopher Atkins <57670484+catkins-miso@users.noreply.github.com> --- docs/Gemfile.lock | 2 +- docs/concepts.md | 32 ++++ docs/decision-log/conditional-ratings.md | 50 +++++ .../decision-log/seasonal-ratings-schedule.md | 81 ++++++++ ...easonal-ratings-proposals-conditional.json | 175 ++++++++++++++++++ docs/example-narratives/seasonal-ratings.md | 116 ++++++++++++ docs/images/ComplexSeasonalSchedules.svg | 21 +++ 7 files changed, 476 insertions(+), 1 deletion(-) create mode 100644 docs/decision-log/conditional-ratings.md create mode 100644 docs/decision-log/seasonal-ratings-schedule.md create mode 100644 docs/example-narratives/examples/seasonal-ratings-proposals-conditional.json create mode 100644 docs/example-narratives/seasonal-ratings.md create mode 100644 docs/images/ComplexSeasonalSchedules.svg diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock index 26f2dc9..3f4ebb5 100644 --- a/docs/Gemfile.lock +++ b/docs/Gemfile.lock @@ -270,7 +270,7 @@ GEM concurrent-ruby (~> 1.0) unicode-display_width (1.8.0) uri (0.13.1) - webrick (1.8.1) + webrick (1.8.2) PLATFORMS x86_64-linux diff --git a/docs/concepts.md b/docs/concepts.md index b0b3d79..fbd676f 100644 --- a/docs/concepts.md +++ b/docs/concepts.md @@ -174,6 +174,24 @@ a distinct data set from Proposals. Proposals may be queried as well as submitted, so that the rating provider's original input data is always kept separately from the in-use ratings. +## Seasonal Ratings + +Seasonal Line Ratings, or simply Seasonal Ratings in TROLIE, are based on the +formal definition in the pro forma attachment M of FERC order 881, which states: + +> (3) "Seasonal Line Rating" means a Transmission Line Rating that: + +> (a) Applies to a specified season, where seasons are defined by the Transmission Provider to include not fewer than four seasons in each year, and to reasonably reflect portions of the year where expected high temperatures are relatively consistent. + +> (b) Reflects an up-to-date forecast of ambient air temperature across the relevant season over which the rating applies. + +> (c) Is calculated annually, if not more frequently, for each season in the future for which Transmission Service can be requested. + +Seasonal ratings are used as [Recourse Ratings](#recourse-ratings) in a TROLIE context, as described above. They also may be used for other purposes that go beyond the AAR timeline, +such as planning and other long-term studies. + +Seasonal Ratings are defined against [Seasons](#seasons). + ## Seasonal Overrides A seasonal override is submitted by a Ratings Provider in order to instruct the @@ -222,3 +240,17 @@ Another typical Monitoring Set would be that which nominates the complete footprint for the Transmission Provider. A natural choice for the `monitoring-set` identifier is the NERC id of the entity that defines the `monitoring-set`, if applicable. + +## Seasons + +According to pro forma attachment M of FERC 881, a season has the following definition: + +> ... where seasons are defined by the Transmission Provider to include not fewer than four seasons in each year, and to reasonably reflect portions of the year where expected high temperatures are relatively consistent. + +In practical terms, Transmission Providers have a wide variety of Seasons that they operate to. +Even if seasons across two Transmission Providers have the same name, such as "summer", +the start and end dates may differ. TROLIE is designed to be agnostic to these definitions as much as +possible, so that the data may be exchanged in a more accurate and precise manner. While seasonal "aliases" +such as "winter" may sometimes be provided as hints, seasonal rating schedules are ultimately defined in terms +of start and end dates. Seasonal ratings in TROLIE are represented in terms of start and end dates, and +TROLIE servers may decide how to enforce adherence to specific named seasons that they use. diff --git a/docs/decision-log/conditional-ratings.md b/docs/decision-log/conditional-ratings.md new file mode 100644 index 0000000..3358466 --- /dev/null +++ b/docs/decision-log/conditional-ratings.md @@ -0,0 +1,50 @@ +--- +title: Conditional Seasonal Ratings +parent: Decision Records +--- + +## Status + +* Status: `accepted` +* Issue Link: [GitHub Issue](https://github.com/trolie/spec/issues/129) + +## Context + +There are certain transmission lines that can have different ratings depending on their +configuration. A commonly cited example is underwater lines with cables packed tightly in +trays, where certain combinations of the conductors may be turned on and off. Switching +conductors on and off obviously changes the amount of copper that can carry +electrons. However, to add additional complexity, the wires are close enough together +that they can heat each other up as well, and the overall rating must take this into +account. Therefore, each possible combination will have a unique rating. + +When computing AARs however, it is necessary to take the configuration into account +so that the AAR accounts for the actual or forecasted configuration of the line. Therefore, +no special accommodation needs to be considered for AAR exchange in TROLIE. + +However, for seasonal ratings, the configuration of the line cannot be +forecasted accurately for use as a recourse rating. A separate rating must be +provided for each configuration, so that the right rating may be used based on the +configuration of the line. + +This decision records a strategy for these "conditional" ratings in TROLIE. + +## Decision + +TROLIE will contain no specific schema elements to represent conditional ratings. +For lines that require conditional ratings, TROLIE servers must expose unique +resource identifiers representing each condition / permutation of the configuration. + +This follows from the similar precedent set by the decision +for [directional ratings](directional-ratings.md). + +### Conditional-Resource Naming +Much like the problem in naming directional ratings, there is currently no consistent +approach as to how these "conditions" are represented. TROLIE implementations will +be left on their own to implement a convention for these names, likely concatenating +the facility ID with an ID for each possible condition. + + +## Consequences + +An example is provided in [the seasonal ratings examples](../example-narratives/seasonal-ratings.md). \ No newline at end of file diff --git a/docs/decision-log/seasonal-ratings-schedule.md b/docs/decision-log/seasonal-ratings-schedule.md new file mode 100644 index 0000000..d5ad177 --- /dev/null +++ b/docs/decision-log/seasonal-ratings-schedule.md @@ -0,0 +1,81 @@ +--- +title: Seasonal Ratings +parent: Decision Records +--- + +## Status + +* Status: `accepted` +* Issue Link: [GitHub Issue](https://github.com/trolie/spec/issues/14) + +## Context + +While the primary focus of FERC 881 is AARs, the [seasonal ratings](../concepts.md#seasonal-ratings) +still play an important role. In practice, these are used in planning and other non-operational studies +in addition to their role as recourse ratings in operations. + +Today, seasonal ratings are managed using various tools, and often tied to network model update processes. For various +reasons, many of these tools and processes will need to continue to be supported as they are today. However, +FERC 881 creates a practical need to be able to share these ratings in a more structured way, implying that +some support for seasonal ratings makes sense in TROLIE, even if it is optional. + +However seasonal rating interop is challenging, because the definition and meaning of each season differs +between grid operators. The definition for [seasons](../concepts.md#seasons) in the FERC 881 context is +quite flexible. While internally, grid operators may assign seasonal ratings to well-known named seasons +such as `Fall`, the practices around `Fall` ratings can differ significantly between grid operators: + +* Assumed start and end dates can be different. +* The FERC order specifies only that they must be updated _at least_ annually. In practice, the times they may be changed can be different. + +The diagram below illustrates an example of rating providers with different season definitions. Consider the challenges +for `Transmission Provider 1` to exchange seasonal ratings with `Ratings Provider A` and `Transmission Provider 2`: +![Complex, Interweaving Seasonal Schedules](../images/ComplexSeasonalSchedules.svg) + +This decision record describes seasonal rating support in TROLIE. + +## Decision + +TROLIE will add support for a seasonal clearinghouse, using the same pattern as used by forecasted and +real-time ratings. Support for either accepting proposals or querying snapshots is technically optional, +although it is likely most Transmission Providers must support at least sharing +their snapshots of in-use seasonal ratings. In practice, clearinghouse implementations may take seasonal proposals, +seasonal ratings from modeling systems, seasonal ratings from other systems, or any combination of these into account. + +The familiar TROLIE concepts of proposals, +snapshots and a clearinghouse have multiple benefits for seasonal ratings: + +* While there are no EMS operator overrides or topology conditions to consider like there would be with AARs, there are still jointly-owned facilities and tie lines where multiple ratings may be submitted by different Ratings Providers. +* Some Transmission Providers may elect to manually validate proposed seasonal ratings before using them, as is common in existing practices. The distinction between proposal and in-use snapshot provides a discrete step in the overall data flow where such manual validation may be inserted if desired. + + +### Defining Seasonal Ratings by Date Instead of Season Names + +Seasonal ratings in TROLIE will always be defined via start and end dates, rather than named seasons such +as `Fall` or `Summer`. This way, the definition of what a rating provider is +submitting or a transmission provider is presenting +can be more transparent and precise, and is not explicitly coupled to any one entity's +choices as to their season definitions. + +The pre-defined "named" seasons that are included in proposal and snapshot definitions are included in headers, +but only provided as interop debugging hints. + +### Alignment of Seasons and Flexibility of TROLIE Server Implementations +Defining seasonal ratings in terms of start and end dates creates great flexibility in the shape of seasonal ratings that may be exchanged. + +However, the specification explicitly **does not** imply that TROLIE servers **must** accept +seasonal ratings of any arbitrary start and end date at any time. Transmission Providers +implementing TROLIE are ultimately free to decide how flexible they want to be. + +For example, a Transmission Provider may choose only to accept seasonal ratings that +match that Transmission Provider's pre-defined season start and end dates. Proposals + for these seasons may then need to submitted before some cut-off time determined by + the implementer. Such proposals may be rejected using an HTTP 422 response, in + much the same fashion to forecasts. + +TROLIE server implementations may reject proposals that do not adhere to the Transmission +Provider's business rules and practices. + + +## Consequences + +Seasonal rating support is implemented in the TROLIE [specification](../spec#tag/Seasonal). diff --git a/docs/example-narratives/examples/seasonal-ratings-proposals-conditional.json b/docs/example-narratives/examples/seasonal-ratings-proposals-conditional.json new file mode 100644 index 0000000..d0226c2 --- /dev/null +++ b/docs/example-narratives/examples/seasonal-ratings-proposals-conditional.json @@ -0,0 +1,175 @@ +{ + "proposal-header": { + "source": { + "last-updated": "2025-10-31T15:05:43.044267100-07:00", + "provider": "UTILITY-A", + "origin-id": "5aeacb25-9b65-4738-8a00-ac10afa63640" + }, + "default-emergency-durations": [ + { + "name": "emergency", + "duration-minutes": 240 + } + ], + "power-system-resources": [ + { + "resource-id": "8badf00d-145-in-service", + "alternate-identifiers": [ + { + "name": "EMS.Name.145-in-service", + "authority": "TO-NERC-ID" + } + ] + }, + { + "resource-id": "8badf00d-145-out-of-service", + "alternate-identifiers": [ + { + "name": "EMS.Name.145-out-of-service", + "authority": "TO-NERC-ID" + } + ] + } + ] + }, + "ratings": [ + { + "resource-id": "8badf00d-145-in-service", + "periods": [ + { + "season-name": "WINTER", + "period-start": "2024-11-15T00:00:00-05:00", + "period-end": "2025-03-01T00:00:00-05:00", + "continuous-operating-limit": { + "mva": 160 + }, + "emergency-operating-limits": [ + { + "duration-name": "emergency", + "limit": { + "mva": 165 + } + } + ] + }, + { + "season-name": "SPRING", + "period-start": "2025-03-01T00:00:00-05:00", + "period-end": "2025-06-15T00:00:00-05:00", + "continuous-operating-limit": { + "mva": 160 + }, + "emergency-operating-limits": [ + { + "duration-name": "lte", + "limit": { + "mva": 165 + } + } + ] + }, + { + "season-name": "SUMMER", + "period-start": "2025-06-15T00:00:00-05:00", + "period-end": "2025-09-01T00:00:00-05:00", + "continuous-operating-limit": { + "mva": 160 + }, + "emergency-operating-limits": [ + { + "duration-name": "lte", + "limit": { + "mva": 165 + } + } + ] + }, + { + "season-name": "FALL", + "period-start": "2025-09-01T00:00:00-05:00", + "period-end": "2025-11-15T00:00:00-05:00", + "continuous-operating-limit": { + "mva": 160 + }, + "emergency-operating-limits": [ + { + "duration-name": "lte", + "limit": { + "mva": 165 + } + } + ] + } + ] + }, + { + "resource-id": "8badf00d-145-out-of-service", + "periods": [ + { + "season-name": "WINTER", + "period-start": "2024-11-15T00:00:00-05:00", + "period-end": "2025-03-01T00:00:00-05:00", + "continuous-operating-limit": { + "mva": 160 + }, + "emergency-operating-limits": [ + { + "duration-name": "emergency", + "limit": { + "mva": 165 + } + } + ] + }, + { + "season-name": "SPRING", + "period-start": "2025-03-01T00:00:00-05:00", + "period-end": "2025-06-15T00:00:00-05:00", + "continuous-operating-limit": { + "mva": 160 + }, + "emergency-operating-limits": [ + { + "duration-name": "lte", + "limit": { + "mva": 165 + } + } + ] + }, + { + "season-name": "SUMMER", + "period-start": "2025-06-15T00:00:00-05:00", + "period-end": "2025-09-01T00:00:00-05:00", + "continuous-operating-limit": { + "mva": 160 + }, + "emergency-operating-limits": [ + { + "duration-name": "lte", + "limit": { + "mva": 165 + } + } + ] + }, + { + "season-name": "FALL", + "period-start": "2025-09-01T00:00:00-05:00", + "period-end": "2025-11-15T00:00:00-05:00", + "continuous-operating-limit": { + "mva": 160 + }, + "emergency-operating-limits": [ + { + "duration-name": "lte", + "limit": { + "mva": 165 + } + } + ] + } + ] + } + ] +} diff --git a/docs/example-narratives/seasonal-ratings.md b/docs/example-narratives/seasonal-ratings.md new file mode 100644 index 0000000..9095778 --- /dev/null +++ b/docs/example-narratives/seasonal-ratings.md @@ -0,0 +1,116 @@ +--- +title: Seasonal Ratings +parent: Usage Examples +nav_order: 6 +toc: true +--- + +{: .nb } +This article assumes some familiarity with HTTP in general and RESTful +APIs in particular ([background](../articles/trolie-for-ems-and-ot)). + + +### Scenario Quick Links +{:.no_toc} + +* toc +{:toc} + +## Simplified Example: Transmission Owner Sends Seasonal Ratings with `curl` + +If a Transmission Owner is their own Ratings Provider, they must update their seasonal ratings +and send them to their transmission provider at least annually. + +TROLIE provides the +[patchSeasonalRatingsProposal](../spec#tag/Seasonal/operation/patchSeasonalRatingsProposal) +operation for this purpose. + +**NOTE: Support for this function is an optional part of the TROLIE specification. Transmission Owners / Rating Providers should check with their transmission provider for the method they specifically support for sending seasonal ratings to the transmission provider.** + +Assume the Transmission Owner creates a file called `input.json` containing +their ratings. An example of the required format for the file is given below. + +```json +{% include_relative examples/seasonal-ratings-proposals-patch.json %} +``` + +The format is one of TROLIE's supported media types named +`application/vnd.trolie.seasonal-rating-proposal.v1+json`. This example illustrates +submission of a year's worth of seasons. + + +### Pushing `input.json` to TROLIE with `curl` +{:.no_toc} + +Given the above `input.json`, run the following command to send it to the TROLIE server: + +```bash +curl -d @input.json \ +-X PATCH \ +-H "Content-Type: application/vnd.trolie.seasonal-rating-proposal.v1+json" \ +-H "Accept: application/vnd.trolie.seasonal-ratings-proposal-status.v1+json" +-o output.json \ +"https://trolie.example.com/rating-proposals/seasonal" +``` + +If this submission is successful, `output.json` will contain the contents of the +response from TROLIE. The format of the response is defined by another TROLIE +media type: `application/vnd.trolie.seasonal-ratings-proposal-status.v1+json`. An +example of this response format is given below: + +```json +{% include_relative examples/seasonal-ratings-proposal-status.json %} +``` + +## Season Definitions and Names +The examples above refer to specific named seasons as assumed by the submitter. `WINTER`, +for example, is shown to start on November 15th, ending on March 1st of the following year. + +In many existing OT systems, seasonal ratings are modeled as a simple lookup table, with +the name of each season as a key. However, such representations aren't sufficient for TROLIE; the +definitions of these seasons differ between all of TROLIE's various stakeholders, so the season names +have no consistent meaning. Instead, to support interop, the intended start and end times +of each rating are specified. The `season-name` field is only there to provide a hint as +to the submitter's intent. + +It is ultimately up to the Transmission Provider and TROLIE server implementer as to the flexibility +they will allow in seasonal ratings submissions relative to the Transmission Provider's season +conventions used in operations. The Transmission Provider may elect to be quite liberal, allowing +ratings providers to define their own seasons. Alternatively, the TROLIE server may refuse to accept +submissions that don't match the Transmission Provider's pre-defined seasons exactly. + +Ratings Providers should check with specific Transmission Providers for rules and expectations for +how seasonal ratings may be submitted. + +## Client Errors and Obligations + +Client errors are handled in much the same way as with forecast ratings, as described in +[Forecast Submittal](submitting-forecasts.md). A submittal may have partial success, meaning that +some resources are valid and the proposal for that resource will be saved. A validation error for +a resource implies that no data was saved for that resource. + +Obligations also work in a similar fashion as they do to forecasts. However, rather than being targeted +at a particular forecast window, incomplete obligations should indicate ratings that have not been +been submitted for seasons in the upcoming year as required by the FERC order. + +## Conditional or Configuration-Based Seasonal Ratings + +Some underground or underwater lines have different ratings based on the line's configuration. These +lines include cables that are packed tightly together and may be turned on or off depending on +configuration. Since these lines are packed tightly together, they create a heating effect on one +another. Therefore, the overall line may have very different ratings depending on the configuration. + +For AARs, it is typically assumed that the current configuration (or forecasted configuration) is +accounted for in the AAR. + +However, for seasonal ratings, the configuration cannot be forecasted. Therefore, separate seasonal +ratings must be provided for each allowed configuration combination of the line. These are called +"conditional" ratings in ISO New England's footprint. + +The pattern for conditional seasonal ratings in LEP is similar to the way +[directional ratings](directional-ratings.md) work. Each possible configuration simply represents +a separate resource in TROLIE, as shown in the example proposal submission below: + +```json +{% include_relative examples/seasonal-ratings-proposals-conditional.json %} +``` \ No newline at end of file diff --git a/docs/images/ComplexSeasonalSchedules.svg b/docs/images/ComplexSeasonalSchedules.svg new file mode 100644 index 0000000..79d2012 --- /dev/null +++ b/docs/images/ComplexSeasonalSchedules.svg @@ -0,0 +1,21 @@ + + + + + + + + June 1July 1August 1September 1Transmission Provider 1 "Summer" RatingsTransmission Provider 2 "Summer" RatingsRatings Provider A "June" RatingsOctober 1 \ No newline at end of file