diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock index 0ac5d21..87f12e5 100644 --- a/docs/Gemfile.lock +++ b/docs/Gemfile.lock @@ -1,7 +1,7 @@ GEM remote: https://rubygems.org/ specs: - activesupport (7.1.3.2) + activesupport (7.1.3.4) base64 bigdecimal concurrent-ruby (~> 1.0, >= 1.0.2) @@ -14,16 +14,16 @@ GEM addressable (2.8.6) public_suffix (>= 2.0.2, < 6.0) base64 (0.2.0) - bigdecimal (3.1.7) + bigdecimal (3.1.8) coffee-script (2.4.1) coffee-script-source execjs coffee-script-source (1.11.1) colorator (1.1.0) commonmarker (0.23.10) - concurrent-ruby (1.2.3) + concurrent-ruby (1.3.3) connection_pool (2.4.1) - dnsruby (1.72.0) + dnsruby (1.72.1) simpleidn (~> 0.2.1) drb (2.2.1) em-websocket (0.5.3) @@ -33,11 +33,11 @@ GEM ffi (>= 1.15.0) eventmachine (1.2.7) execjs (2.9.1) - faraday (2.9.0) + faraday (2.9.2) faraday-net_http (>= 2.0, < 3.2) faraday-net_http (3.1.0) net-http - ffi (1.16.3) + ffi (1.17.0) forwardable-extended (2.6.0) gemoji (3.0.1) github-pages (228) @@ -95,7 +95,7 @@ GEM activesupport (>= 2) nokogiri (>= 1.4) http_parser.rb (0.8.0) - i18n (1.14.4) + i18n (1.14.5) concurrent-ruby (~> 1.0) jekyll (3.9.3) addressable (~> 2.4) @@ -205,7 +205,7 @@ GEM gemoji (~> 3.0) html-pipeline (~> 2.2) jekyll (>= 3.0, < 5.0) - just-the-docs (0.8.1) + just-the-docs (0.8.2) jekyll (>= 3.8.5) jekyll-include-cache jekyll-seo-tag (>= 2.0) @@ -223,11 +223,11 @@ GEM jekyll (>= 3.5, < 5.0) jekyll-feed (~> 0.9) jekyll-seo-tag (~> 2.1) - minitest (5.22.3) + minitest (5.24.0) mutex_m (0.2.0) net-http (0.4.1) uri - nokogiri (1.16.3-x86_64-linux) + nokogiri (1.16.6-x86_64-linux) racc (~> 1.4) octokit (4.25.1) faraday (>= 1, < 3) @@ -235,12 +235,13 @@ GEM pathutil (0.16.2) forwardable-extended (~> 2.6) public_suffix (4.0.7) - racc (1.7.3) - rake (13.1.0) + racc (1.8.0) + rake (13.2.1) rb-fsevent (0.11.2) - rb-inotify (0.10.1) + rb-inotify (0.11.1) ffi (~> 1.0) - rexml (3.2.6) + rexml (3.3.0) + strscan rouge (3.26.0) rubyzip (2.3.2) safe_yaml (1.0.5) @@ -252,17 +253,14 @@ GEM sawyer (0.9.2) addressable (>= 2.3.5) faraday (>= 0.17.3, < 3) - simpleidn (0.2.1) - unf (~> 0.1.4) + simpleidn (0.2.3) + strscan (3.1.0) terminal-table (1.8.0) unicode-display_width (~> 1.1, >= 1.1.1) typhoeus (1.4.1) ethon (>= 0.9.0) tzinfo (2.0.6) concurrent-ruby (~> 1.0) - unf (0.1.4) - unf_ext - unf_ext (0.0.9.1) unicode-display_width (1.8.0) uri (0.13.0) webrick (1.8.1) diff --git a/docs/decision-log/rt-vs-forecast-ratings.md b/docs/decision-log/rt-vs-forecast-ratings.md new file mode 100644 index 0000000..9ab9a3d --- /dev/null +++ b/docs/decision-log/rt-vs-forecast-ratings.md @@ -0,0 +1,120 @@ +--- +title: Real-Time and Forecast Ratings as Distinct Data Sets +parent: Decision Records +--- + +## Status + +* Status: `Committed` +* Issue Link: [GitHub Issue](https://github.com/trolie/spec/issues/100) + +## Context + +The primary driver for TROLIE is exchange of the 240-hour-ahead forecast AAR +data as required by FERC 881. While the ability to forecast data is new with +the FERC order, the ability to have line ratings that change based on +temperature is a technology that has been around for some time, if not used in +such a ubiquitous way mandated by the order. + +However, some Transmission Providers may interpret the first of that 240 hours +as being the "current" hour (aka hour "0"). This is not naturally a forecast. +Since this first hour is to be used in real-time operations, therefore +representing the current time, it should be based on observed ambient +conditions, rather than weather forecasts. Since this data is used for +real-time operations and most commonly represents the latest observed vs +forecast state, TROLIE refers to these as `Real-Time` ratings. + +Traditional real-time AAR/DLR systems have used SCADA telemetry protocols for +ratings exchange. Since real-time ratings are derived from observed weather +measurements, fitting them into the "measurement"-oriented model used by these +protocols is somewhat natural. Existing ratings exchanges between Transmission +Providers and Ratings Providers typically use ICCP for this purpose. TROLIE +must assume this method will continue to exist as part of the FERC 881 +landscape. + +TROLIE could take various stances on real-time ratings. Obvious options +include: + +* Ignore them entirely, assuming that all real-time rating exchange is the + domain of SCADA protocols such as ICCP. +* Pack them into the forecast payload, so that the first hour (hour 0) + implicitly represents real-time ratings. +* Model them as a separate concept altogether. + +Note that any use of real-time ratings in TROLIE scope must not be mutually +exclusive to ICCP usage. In practice, ICCP will stay around, so TROLIE would +serve as an optional alternative for some users to submit ratings, and/or an +alternate way to get current in-use limits. + +This decision documents strategy for representing real-time ratings in TROLIE. + +## Decision + +TROLIE will include a real-time ratings operations and a real-time ratings +clearing house that is distinct from the one for forecast ratings, but uses +similar concepts. + +### Why Expose Real-Time Ratings to TROLIE? + +Many of the structural advantages of the REST technology used by TROLIE over +traditional OT data exchanges are documented in this +[article](../articles/trolie-for-ems-and-ot.md). While real-time ratings do map +more naturally to SCADA protocols, there are still some advantages in terms of +the flexibility of the data structure. For example, real-time limit snapshots +include a "detailed" media type much like the forecast ratings do, which would +be prohibitively difficult to model over ICCP. In addition, some transmission +providers may decide that this data is best offloaded from their SCADA systems +and ICCP gateways as those systems scale and are challenged by other changes in +the power grid. Finally, this becomes accessible for rating provider systems +that do not have easy access to ICCP gateways, which are expensive to install +and may be difficult to justify only for ratings exchange. + +### Optional Support Scenarios + +Not all TROLIE implementations will be required to support real-time ratings. +They must be able to coexist alongside ICCP implementations, and some grid +operators may elect to only use ICCP, only use TROLIE, or use both for different +ratings providers. In addition, TROLIE implementations may elect to support +read of real-time snapshots for transparency uses or downstream readers, but +*not* the submission of real-time proposals. + +### Real-Time Ratings as a Distinct Data Exchange + +Rather than implicitly pack real-time ratings into "hour 0" in the forecast, +TROLIE separates real-time ratings into a distinct data exchange. There are +several reasons for this: + +* The concepts (forecast and real-time) have misalignments that make them + awkward to use together. For example, there isn't necessarily a "time" + associated with the real-time ratings; new proposal values are simply + reflections of the latest measurements. By making the differences explicit, + we can make the separate data exchanges more semantically direct, and + therefore simpler. + +* The reasonable frequency for producing real-time ratings is very different + than for forecast ratings. There is likely no reason to publish forecasts + more than once an hour, as updated forecasts are unlikely to improve accuracy. + In contrast, real-time ratings are based on real, observed temperature + changes, which _can_ certainly change within the hour. This increased + frequency also allows TROLIE to support DLRs as well as AARs, as changes to + real-time proposals could simply be conveyance of sensor data. + +* The usage of forecast and real-time ratings by the ratings provider is also + quite different. Real-time ratings are forwarded on to state estimator, + real-time markets and generation dispatch processes. These processes run + frequently and react to new ratings at a much finer granularity than one hour. + Forecast ratings, however, are used in slower processes, such as look-ahead + unit commitment and dispatch, day-ahead markets, outage coordination, and + transmission scheduling. These processes are less able, if they are able at + all, to leverage data generated at a finer frequency than one hour. + +Note that this does not prohibit a transmission provider and TROLIE server +implementation from using the first hour of a forecast in place of a real-time +rating if no such feed is available. + + +## Consequences + +TROLIE real-time operations are defined under the `Real-Time` tag of the TROLIE +[specification](https://trolie.energy/spec#tag/Real-Time). As mentioned above, +TROLIE servers may optionally implement these operations.