Limit reductions API

[olperr1]

Describe the current behavior

During security analyses, we cannot detect when a specific limit is almost reached.
The default LimitViolationDetector can be configured to support a limit reduction, but this reduction is applied to every limit.

For instance, we can configure the security analysis to return limit violations when the current is greater than 95% of the limit value, but it applies to all the limits of all the network elements, and thus we can not configure the reduction to be 90% for a specific branch and 100% for all the other branches.

Describe the expected behavior

I. Description

General description

During security analyses, it should be possible to apply different limit reductions depending on several criteria:

• the limit type (current, active power or apparent power)
• the use cases: for monitoring only or for actions
• the contingency context (pre-contingency, after a specific contingency or after all contingencies, ...)
• concerning specific network elements (branches, three windings transformers, ...), which could be described by the following criteria:
  • a set of their ids
  • their countries
  • their nominal voltages
• their limit characteristics:
  • the limit type: permanent or temporary
  • their acceptable duration (for temporary limits)
    • equal to a specific value
    • inside an interval.

These criteria can be cumulative (several can be used at the same time to define a limit reduction).

Because a limit can validate the criteria of several limit reductions, the order the limit reductions are declared is important. We will consider that the limit reduction to apply for a limit is the last encountered when reading them from start to end.

Note that these reductions are taken into account when determining the action to apply during security analyses with remedial acitons. For instance, if for a branch the reduced limits are violated but not the original limits and if a remedial action was defined, this one will be applied.

Criteria details

1. Limit type

The type of the limits on which to apply the reduction must be specified (mandatory item). Types to support are:

• CURRENT: for current limits;
• ACTIVE_POWER: for active power limits;
• APPARENT_POWER: for apparent power limits.

2. Use cases (Monitoring or action)

The reduction may applies:

1. for monitoring only: when a limit is associated with an action and a reduction is applied for monitoring only, if the encountered value is between the reduced limit value and the original limit value, the action should not be applied;

2. for action: when a limit is associated with an action and a reduction is applied for action, if the encountered value is between the reduced limit value and the original limit value, the action should be applied.

This behavior will be described as a boolean monitoringOnly. When it is true, the 1. case is used, else the 2..

3. Contingency context

Zero or one contingency context can be specified. It contains:

• a type among:
  • ALL: corresponding to all contingencies and pre-contingency situations;
  • NONE: corresponding to pre-contingency situations;
  • SPECIFIC: corresponding to a specific contingency situation;
  • ONLY_CONTINGENCIES: corresponding to all contingency situations (without the pre-contingency one).
• and when the type is SPECIFIC, the id of the contingency.

When no contingency context is present, the default is to use the ALL policy.

4. Network elements

We can define the network elements whose limits will be affected by the limit reductions in using several criteria:

• a set of the network elements' ids
• one or two countries (respectively for elements with one or two substations)
• their nominal voltages, by defining an intervals for each of the voltage levels

If no network elements is specified, the limit reduction applies to all of them.

5. Limit duration characteristics

Zero or several duration criteria can be specified. Each one contains:

• a type among:
  • PERMANENT: corresponding to permanent limits only;
  • TEMPORARY: corresponding to temporary limits only.
• and when the type is TEMPORARY, one of the following options to restrict them according to their acceptable duration:
  • ALL: to select all temporary limits, regardless their acceptable duration;
  • EQUALITY: to select the temporary limits whose acceptable duration is equal to a specified value, with:
    • value: the said value.
  • INTERVAL: to select the temporary limits whose acceptable duration is within an interval, with:
    • lowBound and highBound: minimum and maximum duration, each can be null;
    • lowClosed and highClosed: is the interval open (false) or closed (true) on respectively the lower and the upper boundaries? This attribute is facultative if the corresponding bound value is null.

When no duration criteria are present, the reduction should be applied to all permanent and temporary limits.

When several duration criteria are specified, the limit reductions applies to each one. For instance, if both criteria PERMANENT and (TEMPORARY ; EQUALITY ; 600) are defined, the limit reduction will apply to permanent limits and 600s limits.

Point of attention

Having two limits L1 and L2 on the same network element, if L1 has a smaller acceptable duration, we expect L1 to have a higher value than L2.

After limit reductions application, the value of L1 may be lower than the one of L2.

For instance, with the following limits on a line (ordered by ascending values):

• L2 : acceptable duration = 20min. ; value = 90MW
• L1 : acceptable duration = 1min. ; value = 100MW

and the following limitReduction:

• LR : limitsTime=60 ; ratio = 0.8

After the application of the limit reductions, we have the following limits:

• L1' : acceptable duration = 1min. ; value = 80MW
• L2 : acceptable duration = 20min. ; value = 90MW

This could lead to problems with the actual code (see for instance LimitViolationUtils.getOverload(LoadingLimits, double, float)).

For now, we will ignore the presence à L2 and only consider L1' in our algorithms. When retrieving the limits of an element, a pre-processing should thus be done to order to work only with the limits to consider.

Application

API update

These limit reduction definitions will be added as a new parameter of SecurityAnalysis.Runner.runAsync(…) and of SecurityAnalysisProvider.run(…).

Using these data

Concept

During the analysis, when the limits of a network element are examined, the reductions must apply. The analysis must then work on an altered copy of the original limits, obtained in applying the limit reductions and in removing the unwanted limits (see section "Point of attention").

Important note: the limits in the network must NOT be modified. (Since the limit reductions are not the same for every contingency context, it will be difficult anyway to determine the values to use.)

When limit violation filters and limit reductions are both defined, the filter should have the prevalence. For instance, if the filter is defined with a minimum base voltage of 90kV and if a current limit reduction is defined for a 63kV line, no violations must be detected, regardless of the line's current. In load flow implementations where the filters are applied before detecting the violations (such as powsybl-open-loadflow), the reductions should not be applied for an identifiable if a filter excludes it.

Utility classes

To compute the reduced limits, a new utility object, a ReducedLimitsComputer, will be created. Different implementations will be available:

• a "no reduction" one, which will juste return the original limits without applying any reductions;
• an abstract one, taking a generic parameter F, which will process the limit reduction definitions and compute the reduced limits of objects of type F;
• an implementation of this abstract class, working with IIDM network elements.

ReducedLimitsComputer objects will have a method
<T> T getLimitsWithAppliedReduction(F networkElement, ThreeSides side, LimitType limitType)

with:

• T: the type of the limits;
• networkElement: the type of the network element to process;
• side: the side of the network element;
• limitType: the limit type (ACTIVE_POWER, CURRENT...).
  The reduction definitions will be used to create this object

NB: The studied network element is handed over via an interface.
Adapters will be implemented to turn existing network element representations (for example IIDM) into implementations of the NetworkElementInterface. This interface should contain methods to retrieve the following data from the network element:

• its id;
• its country(ies);
• its voltage level(s).
  This is a necessary step to allow users to use the getLimitsWithAppliedReduction in an IIDM context or in an OLF context (or in another context).

II. Concept of code

Classes

Limit reduction definitions

    public class LimitReductionList {
        private List<LimitReduction> limitReductions;
    }

    public class LimitReduction {
        private double value;
        private LimitType limitType;
        private List<ContingencyContext> contingencyContexts;
        private List<BranchCriterion> branchCriteria;
        private List<LimitDurationCriterion> durationCriteria;
    }

Contingency contexts

These classes already exist in the contingency-api module.

Equipment criteria

Similar criteria already exist to specify contingency lists, in the contingency-api module. Some code may probably be shared between these two functionalities (see the content of com.powsybl.contingency.contingency.list.criterion and the corresponding (de)serialization - CriterionSerializer and CriterionDeserializer).

Limit duration criteria

General types and interface

    public enum LimitDurationType {
        PERMANENT,
        TEMPORARY
    }

    public interface LimitDurationCriterion {
        LimitDurationType getType();
    }

Permanent duration criterion

    public class PermanentDurationCriterion implements LimitDurationCriterion {
        public static final LimitDurationType TYPE = PERMANENT;
    }

Temporary duration criteria

    public enum TemporaryDurationCriterionType {
        ALL,
        EQUALITY,
        INTERVAL
    }

    public abstract class TemporaryDurationCriterion implements LimitDurationCriterion {
        public static final LimitDurationType TYPE = TEMPORARY;
        public abstract TemporaryDurationCriterionType getComparisonType();
    }

    public class AllTemporaryDurationCriterion extends TemporaryDurationCriterion {
        public static final TemporaryDurationCriterionType COMPARISON_TYPE = ALL;
    }

    public class EqualityTemporaryDurationCriterion extends TemporaryDurationCriterion {
        public static final TemporaryDurationCriterionType COMPARISON_TYPE = EQUALITY;
        private double value;
    }

    public class IntervalTemporaryDurationCriterion extends TemporaryDurationCriterion {
        public static final TemporaryDurationCriterionType COMPARISON_TYPE = INTERVAL;
        private Double lowBound;
        private Double highBound;
        private boolean lowClosed;
        private boolean highClosed;
    }

(De)serialization

The limit reductions should be serializable and deserializable in JSON.

Here is an example of a JSON serialized limit reduction list:

{
  "version" : "1.0",
  "limitReductions" : [ {
    "value" : 0.8,
    "limitType" : "CURRENT",
    "monitoringOnly" : false,
    "contingencyContext" : {
      "contextType" : "SPECIFIC",
      "contingencyId" : "contingencyId1"
    },
    "equipmentCriteria" : [ {
      "type" : "lineCriterion",
      "version" : "1.0",
      "name" : "list1",
      "countryCriterion" : {
        "type" : "TWO_COUNTRY",
        "countries1" : [ "FR" ],
        "countries2" : [ "BE" ]
      },
      "nominalVoltageCriterion" : {
        "type" : "SINGLE_NOMINAL_VOLTAGE",
        "voltageInterval" : {
          "nominalVoltageLowBound" : 370.0,
          "nominalVoltageHighBound" : 410.0,
          "lowClosed" : true,
          "highClosed" : true
        }
      }
    }, {
      "type" : "twoWindingsTransformerCriterion",
      "version" : "1.0",
      "name" : "list2",
      "countryCriterion" : {
        "type" : "SINGLE_COUNTRY",
        "countries" : [ "DE" ]
      },
      "nominalVoltageCriterion" : {
        "type" : "TWO_NOMINAL_VOLTAGE",
        "voltageInterval1" : {
          "nominalVoltageLowBound" : 200.0,
          "nominalVoltageHighBound" : 230.0,
          "lowClosed" : true,
          "highClosed" : true
        },
        "voltageInterval2" : {
          "nominalVoltageLowBound" : 100.0,
          "nominalVoltageHighBound" : 120.0,
          "lowClosed" : true,
          "highClosed" : true
        }
      }
    } ]
  }, {
    "value" : 0.7,
    "limitType" : "CURRENT",
    "monitoringOnly" : true,
    "contingencyContext" : {
      "contextType" : "NONE"
    },
    "equipmentCriteria" : [ {
      "type" : "identifierCriterion",
      "version" : "1.0",
      "name" : "list3",
      "identifiers" : [ "line-1", "transfo-2" ]
    } ],
    "durationCriteria" : [ {
      "type" : "TEMPORARY_EQUALITY",
      "version" : "1.0",
      "value" : 7200
    }, {
      "type" : "TEMPORARY_INTERVAL",
      "version" : "1.0",
      "lowBound" : 1200,
      "lowClosed" : true,
      "highBound" : 6000,
      "highClosed" : false
    }, {
      "type" : "TEMPORARY_INTERVAL",
      "version" : "1.0",
      "highBound" : 600,
      "highClosed" : true
    } ]
  } ]
}

In this example, the limit reductions defined are:

• 1st:
  • Concerns current limits
  • For action use case
  • After the contingency "contingencyId1"
  • For:
    • all the 400kV lines between France (FR) and Belgium (BE)
    • all the German (DE) 220kV / 110kV two windings transformers
  • For every limit (permanent and temporary)
  • Value of the reduction: 0.8
• 2nd:
  • Concerns current limits
  • For monitoring only use case
  • In pre-contingency situation
  • For "line-1" and "transfo-2"
  • For the temporary limits with an acceptable duration:
    • = 7200s
    • in [1200 ; 6000[ s
    • <= 600s
  • Value of the reduction: 0.7

Describe the motivation

No response

Extra Information

• For the contingency descriptions, PowSyBl has a notion of ContingencyContext, which is used for sensitivity factors description and in the operator strategies. It proposes the 3 cases:

  • ContingencyContextType.ALL;
  • ContingencyContextType.NONE;
  • ContingencyContextType.SPECIFIC.
    But it doesn't already support the ONLY_CONTINGENCIES. This policy should be added.

• Regarding the previous point, the support of the ONLY_CONTINGENCIES policy should be also added in powsybl-open-loadflow.