Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

webinar recap and Q&A #55

Merged
merged 9 commits into from
Feb 27, 2024
Merged
Show file tree
Hide file tree
Changes from 8 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion cspell.json
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,9 @@
,"TROLIE"
,"Vernova"
,"SCADA"
,"ENTSO"
,"CGMES"
],
"ignoreWords": ["AMPL"],
"ignoreWords": ["AMPL", "autoplay"],
"import": []
}
6 changes: 3 additions & 3 deletions docs/Gemfile.lock
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
GEM
remote: https://rubygems.org/
specs:
activesupport (7.1.3)
activesupport (7.1.3.2)
base64
bigdecimal
concurrent-ruby (~> 1.0, >= 1.0.2)
Expand Down Expand Up @@ -206,7 +206,7 @@ GEM
gemoji (~> 3.0)
html-pipeline (~> 2.2)
jekyll (>= 3.0, < 5.0)
just-the-docs (0.7.0)
just-the-docs (0.8.0)
jekyll (>= 3.8.5)
jekyll-include-cache
jekyll-seo-tag (>= 2.0)
Expand All @@ -216,7 +216,7 @@ GEM
kramdown-parser-gfm (1.1.0)
kramdown (~> 2.0)
liquid (4.0.4)
listen (3.8.0)
listen (3.9.0)
rb-fsevent (~> 0.10, >= 0.10.3)
rb-inotify (~> 0.9, >= 0.9.10)
mercenary (0.3.6)
Expand Down
153 changes: 153 additions & 0 deletions docs/community-events/20240221-Intro-to-TROLIE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,153 @@
---
title: Introduction to TROLIE webinar
parent: Community Events
---

# Summary

On February 21, 2024 the maintainers conducted a webinar hosted by LF Energy to
introduce the project to the broader community. The replay page is [here][recap].

<iframe width="560" height="315" src="https://www.youtube.com/embed/RRXwD8nyokc?si=qtT_ofwjmpGJITX6" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

## By the Numbers

* RSVPs: 209
* Participants: 144
* Questions asked: 14

The audience posed some great questions, **thank you**! We didn't have time to
get to most of them, so we're answering them here. In some cases we've edited
the original question for clarity, based on our reading of them.

# Q & A

### Does the TROLIE interface handle day/night ratings?

No. The use of day vs night ratings, as required by the FERC order,
applies to the use of temperature-to-rating lookup tables to derive forecast ratings. However, the current TROLIE design assumes that the entity computing the ratings has included the day vs night assumption into the numbers submitted for forecast ratings via https://trolie.energy/spec#tag/Rating-Proposals/operation/patchRatingForecastProposalForProvider. This allows for other methodologies to be used, and also allows the ratings provider, if
desired, to make their own determination as to when day and night switch.

There are multiple ways to interpret this question that could imply
useful extensions to TROLIE:

1. Is it important to track whether the rating provided is based on a
day or night rating? Is this a common use case for interop?
2. Currently, the exchange of temperature-to-rating tables is not in TROLIE scope. Should it be?
Is this a common enough interop need?

Please submit further questions, or propose TROLIE scope changes at https://github.com/trolie/spec/issues.

### How does CIM relate to the TROLIE Specification?

The maintainers are familiar with CIM, and it has influenced the development of
[TROLIE Concepts](https://trolie.energy/concepts). However, not all TROLIE
Concepts had an acceptable analogue in CIM and the traditional toolchain and
serialization conventions of CIM, e.g., RDF XML, do not align well with the
typical technology stack of a modern REST API. In short, TROLIE borrows what is
most useful from CIM's semantics while specifying a very conventional web API
using JSON media types.


<h3>Branches in our system model are nominated by a "From Bus" and a
"To Bus"; they are not assigned a (synthetic) unique identifier. How will we
be using the `resource-id` field to identify a branch when branches are not
assigned a single identifier?</h3>

We created a new issue for this: [#54](https://github.com/trolie/spec/issues/54).
Please join the discussion there.

<h3> How are Monitoring Sets, Transmission Facilities and Segments defined and
updated by Ratings Provider? What are the validation rules? How are they
coordinated with network model updates</h3>

TROLIE is intentionally agnostic to how server and client implementations update
their network models, or whether these data entities are part of the network model
at all, or updated via some other means. The validation rules provided are also
up to individual implementations.

We understand that this is may be disappointing, because maintenance of
network model databases and orchestrating their roll out can be
challenging, especially across entities.

Exchanging model data is _not_ in the scope of TROLIE. This is an incredibly
complex problem that likely requires its own set of defined protocols, standards,
discussions and vendor adoption, much like the
Common Grid Model Exchange Standard (CGMES) used in the
ENTSO-E (https://www.entsoe.eu/data/cim/cim-for-grid-models-exchange/).

As of this writing, the processes to update, exchange and orchestrate network model
updates in North America are highly fragmented. TROLIE does not attempt to solve this problem.

However, instead, we recognize this fragmented landscape as a reality that users of TROLIE must
navigate. In the short term, please consult appropriate vendors, reliability coordinators
or partners on how their specific software behaves. In addition, we have created issue
https://github.com/trolie/spec/issues/57 to document recommended validation rules and model
coordination best-practices for TROLIE implementers.

### Would TROLIE be a cloud-based solution?

TROLIE is agnostic to where servers are hosted. The specification will work whether clients or
servers are hosted either on-premise or in a public cloud.

Specific vendor products and reliability coordinator implementations will of course be more opinionated.

### Does the specification allow for UTC timestamps?

Yes. TROLIE timestamps use the RFC 3339 format (https://www.rfc-editor.org/rfc/rfc3339).
This format is daylight savings-safe, as shown by example at https://trolie.energy/daylight-savings.

The example referenced above however shows timestamps in local time zones. The common way to specify UTC is
to use a "Z" character instead of a UTC offset as a suffix, like in the following example, which evaluates to 7am EDT:

2025-11-01T11:00:00Z


<h3>How are the status/state of Real-Time and Forecast snapshots communicated
via TROLIE interfaces? How can we know from the TROLIE interface that a new
update for the snapshot values is available?</h3>

including the restriction of the TROLIE Specification to classic REST patterns
caindy marked this conversation as resolved.
Show resolved Hide resolved
and HTTP/1.1. Thus, we don't specify WebSockets, Server Sent Events, or
recommend HTTP long-polling, instead relying on the [Conditional GET
pattern](https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests)
mediated by rate limiting.

We've created an issue to document using this pattern with TROLIE; see [issue
#56](https://github.com/trolie/spec/issues/56).


### Can you provide an implementation timeline? Is there an environment for us to test?

The TROLIE Specification is currently a WIP, and we are working on defining
[milestones](https://github.com/trolie/spec/milestones) for 1.0. Among these
milestones will be comprehensive examples. However, since the TROLIE project
*does not intend* to develop a server implementation, we refer you to the
appropriate Reliability Coordinator for more information about integration
testing.

### Our RTO will need to send annual day/night times so each member uses the exact time to define day/night; can TROLIE support that?

This is currently out of scope of TROLIE. As of now, TROLIE does not include anything
related to weather data. Whether these timestamps represent weather data that should come from
somewhere else, or they are truly key in orchestrating ratings exchange across providers in a common way is an interesting debate.

If this is desired in TROLIE, the need should probably be driven by the RTO by
reaching out to one of the project contributors,
their vendor, and/or submitting a proposal to https://github.com/trolie/spec/issues.

### Does TROLIE handle the exchange of AARs between a Ratings Provider (TOP) using amps and an Clearinghouse Provider (RC) using MVA?

The TROLIE supports the exchange of various kinds of ratings, including apparent
power, current, reactive power, etc., so it supports specifying quantities with
the appropriate units, including amps and MVA. However, the specification does
*not* require the RC to accept any particular kind of rating, so the Ratings
Provider and the Clearinghouse Provider will need to pre-determine the
appropriate units. The TROLIE Specification is designed to be flexible enough to
accommodate most anticipated situations, such an RC only allowing for apparent
power as inputs and sending apparent power as outputs, as well as an RC allowing
for current and power factor as inputs. We have a [number of tasks
identified](https://github.com/trolie/spec/issues/43) to properly document this
feature.

[recap]: https://community.linuxfoundation.org/events/details/lfhq-lf-energy-presents-webinar-introduction-to-trolie
10 changes: 10 additions & 0 deletions docs/community_events.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
---
title: Community Events
nav_order: 7
has_children: true
---

# Community Events

Below you'll find information about upcoming and previous events in the TROLIE
community.
5 changes: 4 additions & 1 deletion docs/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ For general announcements and discussion, subscribe to our [Email List <i class=

> **Project News** <i class="fa-solid fa-bullhorn"></i>
>
> We had 144 participants at our <a href="https://community.linuxfoundation.org/events/details/lfhq-lf-energy-presents-webinar-introduction-to-trolie/">Intro to TROLIE</a> webinar hosted by LF Energy on February 21st, 2024. The replay is now available for those who were unable to attend.
> The replay and Q&A is now available for the [Intro to TROLIE][intro_webinar] webinar.


# Introduction
Expand All @@ -38,3 +38,6 @@ The project’s specific aims are:


We are committed establishing a vendor-neutral specification and building an inclusive community.


[intro_webinar]: ./community-events/20240221-Intro-to-TROLIE