Add support for directional ratings

[getorymckeag]

Certain segments in the model should support separate ratings for "in" and "out" directions, based on the assumption that the network model contains metadata for which direction "in" and "out" represents.

[caindy]

I'm wondering if this can be punted to modeling by treating directional ratings as belonging to distinct ~facilities~ resources?

Put another way, where something cares about the resource "Line1 A-to-B" being the same transmission facility as "Line1 B-to-A", can we use alternate name or perhaps a vendor extension to correlate them? I think for interop the receiver is going to have a distinct ratings obligation for both "Line1 A-to-B" and "Line1 B-to-A", if they are expecting directional ratings.

[getorymckeag]

I'm wondering if this can be punted to modeling by treating directional ratings as belonging to distinct facilities?

Put another way, where something cares about the resource "Line1 A-to-B" being the same transmission facility as "Line1 B-to-A", can we use alternate name or perhaps a vendor extension to correlate them? I think for interop the receiver is going to have a distinct ratings obligation for both "Line1 A-to-B" and "Line1 B-to-A", if they are expecting directional ratings.

I'd like to think about this a bit. Technically, what you're suggesting is actually how RTDYN models it internally. HOWEVER, I think it's confusing, and directional ratings are a common enough concept that it feels to me like it deserves first-class status.

[caindy]

directional ratings are a common enough concept that it feels to me like it deserves first-class status.

I feel the same way, and certainly we need a definitive and satisfactory answer to, "How does TROLIE accommodate directional limits?"

What I suggested is something like "A unique resource can be defined and precoordinated for each direction of a transmission facility." I left unspecified how those two resources could be related to each other, but that's just modeling, too. We've essentially done the same thing with segments and transmission facilities; the ratings proposal doesn't need to specify the the resource-id of the Transmission Facility, only the segment's.

In the Ratings Obligation profile, we can allow any resource to have an associated Ratings Obligation, and optionally resources can be composed of other resources:

The clearinghouse provider can be viewed as a ratings provider, too: We've already established that provenance will need to permit the clearinghouse provider as rating source when a recourse rating was employed, and now we can make explicit that the clearinghouse provider has a ratings obligation for the facility that the segments roll up into. Thus, in the above we have one ratings obligation per resource in the model.

Important aside: There's been a subtle semantic shift in the recent changes. A rating is a set of proposed limits for a particular power system resource during a certain (time) period. Accordingly, we use "continuous limit" and "emergency limits" to describe the values proposed by the ratings provider.

Let's consider a jointly-owned facility with multiple ratings providers that used directional ratings. The ratings obligation profile could have a Transmission Facility that is composed of two directional resources that are in turn composed of segments. In the detailed snapshot, the directional resources would have the appropriate two segments in their respective provenance. The resource-id of 'A-to-B' and 'B-to-A' is how the snapshot consumer is going to assign the appropriate limits in their own system.

The alternative I guess looks something like this: As a snapshot consumer you'd have the transmission facility's resource id, then look for the "ends", i.e., from='substation A' to='substation B', to determine which limit to assign to your directional limit holder. Of course, substations have the same alternate names problem, so I suppose we need to add substations as modeled resources, but then we'd just have from='resource id (A)' to='resource id (B)' and we're back to pre-negotiating.

That's just one way of doing making directional ratings explicitly part of the semantics, yet I think any approach must make "ends" explicit in the schema, so they're equivalent for my purposes. Now, both parties are assumed to have shared knowledge of an implicit topology, so there's no need to be able to recover a connectivity model from a limits snapshot. (That's just a reasonable non-objective; I'm not considering security.) What structure then do we need? I think the answer is about debuggability and operability not functional correctness. So far, I don't think the exchange needs to be topology aware, and that would seem to include "ends".

Somewhat of a tangent, but something related to consider:

Let's say the resource-id=LineA sent by the Ratings Provider Foo is their identifier for a transmission facility, i.e., Line A. On the modeling side as a clearinghouse provider Bar, we might have name=LineA, authority=Foo nominate a Segment for Line A while name=LineA, authority=Bar nominates the line itself (for which we as the clearinghouse provider have the ratings obligation), so the proposal and the snapshot use resource-id=LineA.

Everything hinges on pre-coordinating names for things, but the alternative is coordinating the topology to some extent. I'll initiate some discussions internally about this topic. I'm most interested in working validating the scenario where one party uses directional ratings but the other doesn't. (Update: I don't think this is actually realistic.)

[catkins-miso]

@getorymckeag sharing an example of using only the From/To bus and a circuit id to identify directional ratings. This is very simplistic, but I thought a concrete example would add to the discussion. Again, this works with what we already have so doesn't require adding anything to the semantics to explicitly identify "ends" for a facility.

{
    "proposal-header": {
        "source": {
            "last-updated": "2024-03-5T15:05:43.044267100-07:00",
            "provider": "X-AMPL-TO"
        },
        "default-emergency-durations": [
            {
                "name": "emergency",
                "duration-minutes": 60
            }
        ],
        "power-system-resources": [
            { "resource-id": "BusA BusB 1" },
            { "resource-id": "BusB BusA 1" },
            { "resource-id": "BusA BusB 2" },
            { "resource-id": "BusB BusA 2" }
        ]
    },
    "ratings": [
        {
            "resource-id": "BusA BusB 1",
            "periods": [
                {
                    "period-start": "2025-11-02T01:00:00-05:00",
                    "period-end": "2025-11-02T02:00:00-05:00",
                    "continuous-operating-limit": {
                        "mva": 160
                    },
                    "emergency-operating-limits": [
                        {
                            "duration-name": "emergency",
                            "limit": {
                                "mva": 165
                            }
                        }
                    ]
                }
            ]
        },
        {
            "resource-id": "BusB BusA 1",
            "periods": [
                {
                    "period-start": "2025-11-02T01:00:00-05:00",
                    "period-end": "2025-11-02T02:00:00-05:00",
                    "continuous-operating-limit": {
                        "mva": 161
                    },
                    "emergency-operating-limits": [
                        {
                            "duration-name": "emergency",
                            "limit": {
                                "mva": 165
                            }
                        }
                    ]
                }
            ]
        },
        {
            "resource-id": "BusA BusB 2",
            "periods": [
                {
                    "period-start": "2025-11-02T01:00:00-05:00",
                    "period-end": "2025-11-02T02:00:00-05:00",
                    "continuous-operating-limit": {
                        "mva": 162
                    },
                    "emergency-operating-limits": [
                        {
                            "duration-name": "emergency",
                            "limit": {
                                "mva": 165
                            }
                        }
                    ]
                }
            ]
        },
        {
            "resource-id": "BusB BusA 2",
            "periods": [
                {
                    "period-start": "2025-11-02T01:00:00-05:00",
                    "period-end": "2025-11-02T02:00:00-05:00",
                    "continuous-operating-limit": {
                        "mva": 163
                    },
                    "emergency-operating-limits": [
                        {
                            "duration-name": "emergency",
                            "limit": {
                                "mva": 165
                            }
                        }
                    ]
                }
            ]
        }
    ]
}

[caindy]

relates to #54