From 943131ef7796a2b0be15eaa3bbdee3cb25ddc3d7 Mon Sep 17 00:00:00 2001 From: Tory McKeag Date: Fri, 2 Aug 2024 18:57:33 -0700 Subject: [PATCH 1/9] Added concepts for seasonal, conditional ratings --- docs/Gemfile.lock | 2 +- docs/concepts.md | 32 ++++++++ docs/decision-log/conditional-ratings.md | 50 +++++++++++++ .../decision-log/seasonal-ratings-schedule.md | 75 +++++++++++++++++++ docs/images/ComplexSeasonalSchedules.svg | 21 ++++++ 5 files changed, 179 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/images/ComplexSeasonalSchedules.svg diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock index 5a6c239..787af1b 100644 --- a/docs/Gemfile.lock +++ b/docs/Gemfile.lock @@ -235,7 +235,7 @@ GEM pathutil (0.16.2) forwardable-extended (~> 2.6) public_suffix (4.0.7) - racc (1.8.0) + racc (1.8.1) rake (13.2.1) rb-fsevent (0.11.2) rb-inotify (0.11.1) diff --git a/docs/concepts.md b/docs/concepts.md index b1c5f0e..1a384e5 100644 --- a/docs/concepts.md +++ b/docs/concepts.md @@ -99,6 +99,24 @@ anticipated to be a rating provided by the Ratings Provider separately, such as the effective seasonal rating, a verbal override, or even a previously forecasted rating. +### 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). + ## Power System Resource, or simply _Resource_ A term borrowed from CIM, in the context of TROLIE, a "Resource" is an object of @@ -205,3 +223,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. Queries and submittals of seasonal ratings are done in terms of start and end dates, and +TROLIE servers may decide how to enforce their adherance 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..d528108 --- /dev/null +++ b/docs/decision-log/conditional-ratings.md @@ -0,0 +1,50 @@ +--- +title: Conditional Seasonal Ratings +parent: Decision Records +--- + +## Status + +* Status: `Specification-in-progress` +* 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. The most frequent examples are 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 best practice 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 + +TODO: Link to an example article once the seasonal rating structure is complete. \ 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..a89db7d --- /dev/null +++ b/docs/decision-log/seasonal-ratings-schedule.md @@ -0,0 +1,75 @@ +--- +title: Seasonal Ratings +parent: Decision Records +--- + +## Status + +* Status: `Specification-in-Progress` +* 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_ anually. 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 unaforementioned 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. + +TROLIE server implementations may reject proposals that do not adhere to the Transmission Provider's business rules and practices. + + +## Consequences + +TODO: Add link to specification and examples after they have been added. 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 From f581a2fa2576c34f49e57042e4da536e9b22e17a Mon Sep 17 00:00:00 2001 From: Tory McKeag Date: Fri, 2 Aug 2024 19:05:06 -0700 Subject: [PATCH 2/9] Cleaned up spelling errors --- cspell.json | 1 + docs/concepts.md | 4 ++-- docs/decision-log/seasonal-ratings-schedule.md | 4 ++-- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/cspell.json b/cspell.json index 86229d0..65f3858 100644 --- a/cspell.json +++ b/cspell.json @@ -12,6 +12,7 @@ "dictionaryDefinitions": [], "dictionaries": [], "words": [ + "adherance", "affordance" ,"auditability" ,"brotli" diff --git a/docs/concepts.md b/docs/concepts.md index 1a384e5..2618781 100644 --- a/docs/concepts.md +++ b/docs/concepts.md @@ -235,5 +235,5 @@ Even if seasons across two Transmission Providers have the same name, such as "s 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. Queries and submittals of seasonal ratings are done in terms of start and end dates, and -TROLIE servers may decide how to enforce their adherance to specific named seasons that they use. +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 adherance to specific named seasons that they use. diff --git a/docs/decision-log/seasonal-ratings-schedule.md b/docs/decision-log/seasonal-ratings-schedule.md index a89db7d..1920954 100644 --- a/docs/decision-log/seasonal-ratings-schedule.md +++ b/docs/decision-log/seasonal-ratings-schedule.md @@ -25,7 +25,7 @@ grid operators may assign seasonal ratings to well-known named seasons such as ` 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_ anually. In practice, the times they may be changed 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`: @@ -39,7 +39,7 @@ TROLIE will add support for a seasonal clearinghouse, using the same pattern as 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 unaforementioned systems, or any combination of these into account. +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: From 05a33bf41ca50d2d08e5cd845e43ea0ecc6fc58a Mon Sep 17 00:00:00 2001 From: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> Date: Thu, 26 Sep 2024 11:41:00 -0700 Subject: [PATCH 3/9] 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> --- docs/concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts.md b/docs/concepts.md index 2618781..2fd8c3b 100644 --- a/docs/concepts.md +++ b/docs/concepts.md @@ -236,4 +236,4 @@ the start and end dates may differ. TROLIE is designed to be agnostic to these 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 adherance to specific named seasons that they use. +TROLIE servers may decide how to enforce adherence to specific named seasons that they use. From fe9732c92b292781f7ae809557ff7dcd712b6032 Mon Sep 17 00:00:00 2001 From: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> Date: Thu, 26 Sep 2024 11:41:08 -0700 Subject: [PATCH 4/9] 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> --- cspell.json | 1 - 1 file changed, 1 deletion(-) diff --git a/cspell.json b/cspell.json index 65f3858..86229d0 100644 --- a/cspell.json +++ b/cspell.json @@ -12,7 +12,6 @@ "dictionaryDefinitions": [], "dictionaries": [], "words": [ - "adherance", "affordance" ,"auditability" ,"brotli" From e479fe274d9ce8994508e1b628e4fc90eb825e86 Mon Sep 17 00:00:00 2001 From: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> Date: Thu, 26 Sep 2024 11:41:29 -0700 Subject: [PATCH 5/9] 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> --- docs/decision-log/conditional-ratings.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decision-log/conditional-ratings.md b/docs/decision-log/conditional-ratings.md index d528108..91da4a3 100644 --- a/docs/decision-log/conditional-ratings.md +++ b/docs/decision-log/conditional-ratings.md @@ -18,7 +18,7 @@ electrons. However, to add additional complexity, the wires are close enough tog 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 best practice to take the configuration into account +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. From 522b7f8bb4e069984a820d77f5670fbe3f1db506 Mon Sep 17 00:00:00 2001 From: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> Date: Thu, 26 Sep 2024 11:41:38 -0700 Subject: [PATCH 6/9] 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> --- docs/decision-log/conditional-ratings.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decision-log/conditional-ratings.md b/docs/decision-log/conditional-ratings.md index 91da4a3..7143ad2 100644 --- a/docs/decision-log/conditional-ratings.md +++ b/docs/decision-log/conditional-ratings.md @@ -11,7 +11,7 @@ parent: Decision Records ## Context There are certain transmission lines that can have different ratings depending on their -configuration. The most frequent examples are underwater lines with cables packed tightly in +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 From 23d3cc05c15e0a381037984cf077d36610f58fc4 Mon Sep 17 00:00:00 2001 From: Tory McKeag Date: Thu, 26 Sep 2024 11:47:17 -0700 Subject: [PATCH 7/9] Filled in gaps --- docs/Gemfile.lock | 8 +- docs/decision-log/conditional-ratings.md | 4 +- .../decision-log/seasonal-ratings-schedule.md | 30 +-- ...easonal-ratings-proposals-conditional.json | 175 ++++++++++++++++++ docs/example-narratives/seasonal-ratings.md | 116 ++++++++++++ 5 files changed, 316 insertions(+), 17 deletions(-) create mode 100644 docs/example-narratives/examples/seasonal-ratings-proposals-conditional.json create mode 100644 docs/example-narratives/seasonal-ratings.md diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock index 6aadcbe..3f4ebb5 100644 --- a/docs/Gemfile.lock +++ b/docs/Gemfile.lock @@ -35,8 +35,9 @@ GEM ffi (>= 1.15.0) eventmachine (1.2.7) execjs (2.9.1) - faraday (2.11.0) + faraday (2.12.0) faraday-net_http (>= 2.0, < 3.4) + json logger faraday-net_http (3.3.0) net-http @@ -99,7 +100,7 @@ GEM activesupport (>= 2) nokogiri (>= 1.4) http_parser.rb (0.8.0) - i18n (1.14.5) + i18n (1.14.6) concurrent-ruby (~> 1.0) jekyll (3.10.0) addressable (~> 2.4) @@ -211,6 +212,7 @@ GEM gemoji (>= 3, < 5) html-pipeline (~> 2.2) jekyll (>= 3.0, < 5.0) + json (2.7.2) just-the-docs (0.10.0) jekyll (>= 3.8.5) jekyll-include-cache @@ -268,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/decision-log/conditional-ratings.md b/docs/decision-log/conditional-ratings.md index d528108..2c9f2b1 100644 --- a/docs/decision-log/conditional-ratings.md +++ b/docs/decision-log/conditional-ratings.md @@ -5,7 +5,7 @@ parent: Decision Records ## Status -* Status: `Specification-in-progress` +* Status: `accepted` * Issue Link: [GitHub Issue](https://github.com/trolie/spec/issues/129) ## Context @@ -47,4 +47,4 @@ the facility ID with an ID for each possible condition. ## Consequences -TODO: Link to an example article once the seasonal rating structure is complete. \ No newline at end of file +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 index 1920954..3f85764 100644 --- a/docs/decision-log/seasonal-ratings-schedule.md +++ b/docs/decision-log/seasonal-ratings-schedule.md @@ -5,7 +5,7 @@ parent: Decision Records ## Status -* Status: `Specification-in-Progress` +* Status: `accepted` * Issue Link: [GitHub Issue](https://github.com/trolie/spec/issues/14) ## Context @@ -19,10 +19,10 @@ reasons, many of these tools and processes will need to continue to be supported 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: +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 4 +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. @@ -53,7 +53,8 @@ snapshots and a clearinghouse have multiple benefits for seasonal ratings: 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. +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. @@ -61,15 +62,20 @@ 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. +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. +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. +TROLIE server implementations may reject proposals that do not adhere to the Transmission +Provider's business rules and practices. ## Consequences -TODO: Add link to specification and examples after they have been added. +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 From e2381f0390805d8758d5c6397152f5387a103032 Mon Sep 17 00:00:00 2001 From: Tory McKeag Date: Thu, 26 Sep 2024 11:51:24 -0700 Subject: [PATCH 8/9] Re-orged concepts --- docs/concepts.md | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/concepts.md b/docs/concepts.md index 70d55e5..fbd676f 100644 --- a/docs/concepts.md +++ b/docs/concepts.md @@ -99,24 +99,6 @@ anticipated to be a rating provided by the Ratings Provider separately, such as the effective seasonal rating, a verbal override, or even a previously forecasted rating. -### 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). - ## Power System Resource, or simply _Resource_ A term borrowed from CIM, in the context of TROLIE, a "Resource" is an object of @@ -192,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 From 661cff9572a9df2ed171fc50fd0c915523aa08a2 Mon Sep 17 00:00:00 2001 From: Tory McKeag <143734462+getorymckeag@users.noreply.github.com> Date: Thu, 26 Sep 2024 12:53:15 -0700 Subject: [PATCH 9/9] 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> --- docs/decision-log/seasonal-ratings-schedule.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decision-log/seasonal-ratings-schedule.md b/docs/decision-log/seasonal-ratings-schedule.md index 3f85764..d5ad177 100644 --- a/docs/decision-log/seasonal-ratings-schedule.md +++ b/docs/decision-log/seasonal-ratings-schedule.md @@ -20,7 +20,7 @@ FERC 881 creates a practical need to be able to share these ratings in a more st 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 4 +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: