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

Tentative Design, for discussion

AreaType

AreaType-s are defined/contained in an iidm:Network and allow data engineer to describe the type of areas that will be instantiated in the Network.

AreaType is an iidm:Identifiable, a new iidm:IdentifiableType.AREA_TYPE is introduced.

Examples of AreaTypes are:

• Control Area
• Scheduling Area
• Bidding Zone
• Control Block
• Organizational region such as GeographicalRegion, SubGeographicalRegion, Capacity Coordination Region, Outage Coordination Region, ...
• Automaton protected zone
• Load Areas & generation areas
• (Note that Country & TSO could as well fit in there)

PowSyBl does not pre-define any AreaType, user can adapt to their specific use case. An AreaType has no specific attribute - AreaType mostly only needs to extend iidm:AbstractIdentifiable fields (interface methods actually).

Note: TODO subnetwork & merge handling

Area

An Area is defined by:

• (unique) ID and other attributes from iidm:AbstractIdentifiable
• An AreaType (mandatory)
• a target AC Net Interchange (MW, load sign convention, optional)
• a net interchange tolerance (MW, optional)

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

• define area boundaries,
• and/or, assign the area to equipments or equipment containers.

Area boundaries

Boundaries may be attached to Area-s, a given boundary is a Terminal and may be added by providing:

• A tie-line, with the side specified.
• A DanglingLine, with indication if DC or AC.
• Any connectable Terminal, with indication if DC or AC.

Area assignment

The following iIDM concepts may be assigned zero, one, or multiples areas:

• Containers:
  • SubNetwork
  • Substation
  • VoltageLevel
• Equipments:
  • Connectable

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

To resolve the Area having a given AreaType for a given object:

• first the area definitions in the object itself are searched (highest priority)
• then the containing VoltageLevel is searched
• then the containing Substation is searched
• then the containing SubNetwork is searched (lowest priority)

In most cases, assigning the Area to the SubNetwork is sufficient.

Area methods, interface

TODO, e.g.:

• getLoads, getGenerators, ...
• getBoundaries
• getTotalNetInterchange (AC+DC)
• getTotalNetACInterchange (AC only)

iIDM (de)serialization

TODO

[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.