Business rules for Rating Proposal patch updates

[travis-qualus]

FERC 881 requires 240 hours of rolling rating forecasts for each resource. But once a forecast for a given hour is provided to the RC, and if it doesn't change for several days, does it need to be provided again?

In other words, will the API itself validate that all forecast hours are provided in a patch update, or will it only fail if a required forecast hour is expected but has never been provided? Or will it check for missing hours? That assumes the business logic is running in the back end (eg LEP) not in the API layer.

Is it theoretically possible to only provide new or updated hours, rather than all 240 hours of every resource every hour?

Somewhat related question, if there are issues calculating an AAR for a given hour (such as forecast unavailability) is there a way to tell the RC (within the Forecast Proposal) that the rating for that hour is NA or BAD, and to revert to the Seasonal Rating for that hour?

[catkins-miso]

once a forecast for a given hour is provided to the RC, and if it doesn't change for several days, does it need to be provided again?

The forecast has to be updated every hour. If it doesn't change for some extent of periods in a given forecast proposal, the period-start and period-end could cover the entire extent. For example if the rating doesn't change at all you'd have one entry for the facility with period-start = hour 1 and period-end = hour 240.

I think the Order's requirement at issue is that the forecast be updated every hour and provided to the Transmission Provider, e.g., MISO. I don't think we should incorporate any "sustain this rating" semantics in the forecast proposal. We have temporary AAR exceptions and seasonal overrides to address that kind of circumstance.

will the API itself validate that all forecast hours are provided in a patch update, or will it only fail if a required forecast hour is expected but has never been provided? Or will it check for missing hours? That assumes the business logic is running in the back end (eg LEP) not in the API layer.

We hope to create a suite of conformance tests that pin things like this down, but the spec has semantics that are meant to reflect that TROLIE should accept partial success for an overall proposal, see https://trolie.energy/example-narratives/submitting-forecasts.html#invalid-forecasts-for-individual-resources-should-be-tolerated However, as that article notes, the forecast for a particular facility must be complete to be accepted.

if there are issues calculating an AAR for a given hour (such as forecast unavailability) is there a way to tell the RC (within the Forecast Proposal) that the rating for that hour is NA or BAD, and to revert to the Seasonal Rating for that hour?

If I understand the use case you have in mind, the client can still send forecast proposals, so they should propose the appropriate recourse rating in their forecast. This is a good call out though, because there's no affordance in the proposal to indicate that the period is using a recourse rating. The TROLIE spec has a separate affordance to define temporary AAR exceptions (including retroactively) for other use cases, but I think it's worth looking into simplifying the client's job here and just allowing the recourse rating reason to be supplied in-line with the proposal. What do you think @getorymckeag? /cc @crossMISO

[travis-qualus]

The easiest way to implement (from the TO perspective) is simply brute force - recalculate and provide all 240 hours of ratings every hour. And that is probably what we will do. But we were looking at optimizations where we don't bother to recalculate ratings for certain resources or hours if the underlying weather forecast doesn't change for those hours. Anyway, perhaps something for the future.

Similarly, the TOs are implementing logic to use a 'backstop' rating if a weather forecast is unavailable (or bad). So if the ratings calculation engine can't calculate a new rating for a given hour from new weather data, they could either a) use the prior forecast, b) revert to the seasonal rating, or c) some other rule. Perhaps the markets themselves will define the rules for those scenarios?

Trolie doesn't really provide a way to indicate the 'quality' of the rating, so I guess that assumes the TO needs to ensure a rating is provided even if its overly conservative seasonal backup.

[catkins-miso]

Perhaps the markets themselves will define the rules for [recourse rating] scenarios?

I don't think that is likely. I think the Order commends using a seasonal rating as the recourse rating when the AAR cannot be calculated. MISO created room in its tariff filing to use a different rating for reliability purposes, but the recourse rating should be provided by the TO (Ratings Provider). Only when there is a communications outage and the TO provided ratings go stale are there other considerations (which are beyond the scope of TROLIE).

Trolie doesn't really provide a way to indicate the 'quality' of the rating,

Yes, as I mentioned in my previous reply to this issue, "there's no affordance in the [ratings] proposal to indicate that the period is using a recourse rating." I think this may be an oversight. From the Transmission Provider perspective, we have an obligation to include in the archive the reason why the provided rating was not an AAR as noted previously. That can be achieved with temporary AAR exceptions, but it's an extra step that I think can be avoided in the case of ratings proposals that don't contain AARs (either RT or Forecast).

I guess that assumes the TO needs to ensure a rating is provided even if its overly conservative seasonal backup.

Yes, the Ratings Provider (TO) is expected to fulfill the Ratings Obligation (240 valid hourly ratings per facility per hour) by the Clearinghouse Provider. Not to do so is considered a communications failure and triggers the aforementioned processes at the TP to deal with stale/missing ratings.