Generic Area model in iIDM

[jeandemanged]

Describe the current behavior

iIDM (today) v1.12 supports the following which somewhat mimics areas:

• Specifying the Country of a Substation
• Specifying the TSO of a Substation
• Adding geographical tags per Substation (simple list of string)
• Subnetworks (available since v1.11)

Describe the expected behavior

Although above data model fits most simple use cases, it comes with limitations for real world cases:

• smallest granularity is a Substation
• the area boundaries are not explicitly listed
• a geographical tag is nothing more than a string
• no possibility to distinguish between a Dangling Line representing an AC interconnection vs. a DC Converter modeled through a simple Equivalent Injection

We propose to introduce a generic "area" concept in iIDM v1.13, separated from the above-mentioned features which will remain as is.

Describe the motivation

• Area Interchange Control in LoadFlow
• Security Analysis, Rebalancing in contingency state based on control blocks
• Security Analysis, Countertrading Remedial Actions based on Bidding Zones
• Zonal automatons

Extra Information

AreaType

AreaType-s are modeled by a simple string attribute in Area.

PowSyBl does not pre-define any AreaType, user can adapt to their specific use case.

Examples of AreaTypes are:

• "ControlArea",
• "SchedulingArea",
• "BiddingZone"
• "ControlBlock"
• "OrganizationalRegion" such as GeographicalRegion, SubGeographicalRegion, Capacity Coordination Region, Outage Coordination Region, ...
• "AutomatonProtectedZone"
• (Note that Country & TSO could as well fit in there)

Note: for a later iIDM version, AreaType-s could be an iidm:Identifiable (using a new iidm:IdentifiableType.AREA_TYPE)and defined/contained in an iidm:Network and allow data engineer to describe the type of areas that will be instantiated in the Network. Those instances would not follow the very hierarchical geographic relationship that other Identifiable-s have, and could exist in several subnetworks and in a mergedNetwork. How to handle properly such transverse instance remains to be defined.

Area

An Area is defined by:

• (unique) ID and other attributes from iidm:AbstractIdentifiable
• An areaType (String, mandatory)
• a target AC Interchange (MW, load sign convention, optional)

Then depending on use case, an Area may be used to:

• define area boundaries (using the AreaBoundary datamodel)
• and/or, assign the area to voltage levels

AreaBoundary

An AreaBoundary is defined by

• Either a Connectable's Terminal, OR a DanglingLine's Boundary (these two options are mutually exclusive)
• and and ac boolean attribute to indicate if the area boundary is to be considered AC or DC

Area assignment

VoltageLevel-s may be assigned zero, one, or multiples areas.

A VoltageLevel object may have only one Area of a given AreaType.
Defining two areas of the same AreaType on the same VoltageLevel is forbidden and rejected.

Networks and Subnetworks are not assigned to area. Their getAreas methods return all of their known Area-s, which may include several Area-s of the same areaType.

Network merge

Two network with the same Area (ie Area-s with the same ID) cannot be merged.
The merge will fail with an error, as it does for all Identifiable-s with conflicting IDs.

iIDM (de)serialization

serialisation to iIDM versions <= 1.12 will not export area related objects/fields.

[annetill]

After a first look at the PR and reading again the issue:

• Why do we need the area type to be an identifiable?
• Getting the target AC net Interchange (MW, load sign convention, optional) or the net interchange tolerance (MW, optional) is specific to the type of area and I don't understand why we put that in the generic Area interface. We need areas for automaton systems, we are not going to put the needed attributes in the same interface. Do I miss something?
• We already have a Boundary object: for a good understanding of the iidm model, we must use the same wording. Point have no meaning in iidm (maybe in CGMES): we have terminals, nodes, boundaries, buses.
• What is the purpose of public enum BoundaryPointType with HVDC, PAIRED_AC, UNPAIRED_AC and IGNORED_AC ? If the terminal belongs to an HVDC line, it is a DC border, else it is AC. And what means paired, unpaired, ignored? If we have a terminal of a dangling line, it is easy to know if it is paired of not. In which cases it is different ? If it is ignored, why do you need the boundary "point" in the list ?

[m-guibert]

Hello @annetill, thank you for the feedbacks !
The answers are :

• It is useful to have the Identifiable structure on AreaType-s, with a name, alias, existing serde, etc. Also, using a AreaType instead of a simple String helps ensuring the consistency and unicity of each AreaType
• Those attributes are needed for the AIC computations. They are optional so they won’t impact any other Area usages. Storing them as optional attributes in Area-s seems much cleaner and more practical than storing them in an Area extension.
• The whole "boundaryPoint" model was a WIP and has since been modified. About the paired/unpaired, it can indeed be computed. And ignored elements just won't be added to the Area. So we now use a simpler structure: a BoundaryTerminal record, with just a boolean to indicate if the terminal if on an AC or DC line.

[annetill]

Just for me, as a reminder of a similar need from our side https://github.com/powsybl/powsybl-core/blob/main/cgmes/cgmes-extensions/src/main/java/com/powsybl/cgmes/extensions/CgmesControlArea.java.