search

trolie / spec

Transmission Ratings and Operating Limits Information Exchange
https://trolie.energy/
Other
3 stars 2 forks source link

include optional "determining factors" for `forecast-period-proposal`? #61

Closed catkins-miso closed 7 months ago

catkins-miso commented 7 months ago

@getorymckeag I was relayed a specific request:

optional fields for solar irradiance (day/night status) and temperature could be included in the TROLIE spec, to be submitted by Ratings Providers, as additional context with the rating proposal submitted by the Ratings Provider?

I think this could be easily accommodated as an option field here https://github.com/trolie/spec/blob/1.0.0-wip/docs/_data/components/schemas/forecast-limit-period.yaml#L11

We do already have support for vendor-specific extensions on the limit output: https://github.com/trolie/spec/blob/1.0.0-wip/docs/_data/components/schemas/limit-provenance.yaml#L29

We could (should?) adopt this for inbound proposals, too, so the question comes down to if this should be a vendor extension or if determining factors should be considered first class attributes for interop. I'm inclined to support temp and activeInsolation? (or similar) as optional attributes on limits.

catkins-miso commented 7 months ago

Is the CIM Measurements model appropriate for this? image image

getorymckeag commented 7 months ago

Is the CIM Measurements model appropriate for this? image

For Forecasts? I don't think I get it. On the original question, I think that temperature and active insolation are probably good additions. Can we think of a term more plain-spoken than "insolation" though? I know it's precise, but 90% of the people looking at it will have to look it up nearly every time they see it. Me included.

catkins-miso commented 7 months ago

On the original question, I think that temperature and active insolation are probably good additions. Can we think of a term more plain-spoken than "insolation" though? I know it's precise, but 90% of the people looking at it will have to look it up nearly every time they see it. Me included.

In https://github.com/trolie/spec/pull/63/files I propose a very generic way to represent additional inputs, delegating the definition of conventions for input representation to a particular exchange, i.e., to the RC hosting the TROLIE instance.

We could express a preference in the specification for how to represent sun-is-shining-on-conductor as Boolean and/or temp-in-Fahrenheit as float, but I think this data should be defined to be informational by this specification, so the proposed basic structure is appropriate.