Security analysis with remedial actions

[flo-dup]

• Do you want to request a feature or report a bug? Feature

• What is the current behavior? The security analysis API can not take into account any remedial actions.

• What is the expected behavior? The security analysis API does take into account remedial actions:

  • remedial actions which occur on the constraints of the pre-contingency state
  • remedial actions specific to any contingency which occur on constraints of the post-contingency state following that contingency
  • global remedial actions which occur on post-contingency state for all contingencies

• What is the motivation / use case for changing the behavior? Simulate and test the remedial actions which might be executed by operators

[flo-dup]

What do we call a remedial action? We could see it as a Scenario or RemedialScenario object containing

• the (optional) contingency id which preceded if any
• the limit violation which triggered that scenario
• a list of NetworkModification which is applied one after another unless the limit violation is not occuring anymore

(note that each networkModification can itself be a list of modifications through NetworkModificationList)

[flo-dup]

We need to map a list of remedial actions to any LimitViolation encountered. A way to do that would be to have a ScenarioProvider single extra argument in SecurityAnalysis::run. The two following methods are then needed for that provider:

List<Scenario> getPreContingencyScenarios(LimitViolation limitViolation);
List<Scenario> getPostContingencyScenarios(LimitViolation limitViolation, Contingency contingency);

[sylvlecl]

Entry point Indeed we should add an argument to the run method of security analysis providers, something like:

interface SecurityAnalysisProvider {
    CompletableFuture<SecurityAnalysisReport> run(...., List<Scenario> scenarios);
}

Modelling principles

Since one of the primary goal will be to be able to translate all the logic to an external tool, and to exchange that logic between applications, we cannot rely on a java interface such as the ScenarioProvider, we really need to have basic models (POJOs) that we can convert to another data model or format.

So a basic model of scenarios could be:

class Scenario {
    String id;  // is it needed, in addition to the contingency ? we could have different scenarios for 1 contingency
    Contingency contingency;
    Action action;  // Do we need a list here or do we consider a list of actions
                // must be formulated as an aggregated action?
}

class Action {  // Not an interface, it's really a base class for our action models
    String id;
    NetworkModification toNetworkModification();  // Not obvious it should be here:
            // could be used by a java implementation, but could also be outside of that class
}

class OpenSwitchAction { // An exemple of actual action
    String switchId;
}

It already raises some questions:

• do we repeat the definition of contingencies and actions inside scenarios, or do we only have IDs of contingencies and actions here ? Second option seems to make sense to not repeat ourselves
• do we allow multiple scenarios for 1 contingency ? For me yes, it's a necessary feature.

Condition modelling

Since we want remedial actions to be applied only under certain circumstances, we not only need to have action models, but also models for the condition that will trigger or not the implementation of the action. Here again, we need data objects, not an interface.

The condition modelling from powsybl-action-dsl, based on an expression tree, could almost be re-used as is.

However, we may need to replace the Network***Node in particular the method nodes, which are aimed towards use with reflection.

A condition would be part of a scenario:

class Scenario {
    String id;  // is it needed, in addition to the contingency ? we could have different scenarios for 1 contingency
    Contingency contingency;
    Condition condition;  // under which circumstances do I want to trigger my action
    Action action;  // Do we need a list here or do we consider a list of actions
                // must be formulated as an aggregated action?
}

Serialization

All the models described above must be serializable to/from a versioned JSON format, like contingencies already are.

Extensibility

Do we want third-party users to be able to extend the model with their own types of actions and conditions ? If so, we probably just need to take care to have an entry-point to define JSON serialization for those additional classes.

It may take the form of services that would define additional jackson modules.

[sylvlecl]

So we have agreed on the following things, mainly going into the simplification direction:

• No remedial action simulation on N situation, for now, only post contingency actions
• Only 1 action by scenario
• Contingencies and actions are defined in flat list, an referenced by their ID in scenarios
• Multiple scenarios can reference the same contingency
• We keep condition model as simple as possible for now: only a limited set of conditions, based on the presence of limit violations
• To be confirmed: renaming scenario to OperatorStrategy in order to specify with as little ambiguity as possible what it's meant to represent (for example, not automaton actions)
• In result, we add a list of scenarios results, independent from the post contingency results
• Actions will not provide any conversion to NetworkModification
• We start with a limited set of actions: switch action, load modification action, list of actions action

Below are draft models following those principles.

Scenario model

In the end, we would have the following scenario model:

class Scenario {
    String id;
    String contingencyId;
    Condition condition;  // under which circumstances do I want to trigger my action
    String actionId;
}

Action model We could start with:

class Action {  // Not an interface, it's really a base class for our action models
    String id;
}

class SwitchAction extends Action {
    String switchId;
    boolean open;
}

class ActionList extends Action {
    List<Action> actions;
}

Conditions model

For now we will only have very simple conditions:

• 1 condition "always true"
• 1 condition "for any violation"
• 1 condition "for violations on a given network element"

class Condition {
    String getType();  // if needed, or maybe an enum ?
}

class TrueCondition extends Condition {
// always simulate the associated action
}

class AnyViolationCondition extends Condition {
// simulate the associated action as soon there is any violation
}

class ViolationCondition extends Condition {
    // simulate the associated action if there is a violation on any of those network elements
    List<String> subjectIds; 
}

Simulation function

The run method will thus receive 2 additional arguments:

interface SecurityAnalysisProvider {
    CompletableFuture<SecurityAnalysisReport> run(...., List<Action> actions, List<Scenario> scenarios);
}

Result

The result will contain a new list of result for scenarios:

class SecurityAnalysisResult {
    ....
    List<ScenarioResult> getScenariosResults();
    ScenarioResult getScenarioResult(String scenarioId);
}

class ScenarioResult {
    // Same fields as post contingency result but:
    Scenario scenario; // instead of contingency
}

[Hadrien-Godard]

Hello everyone,

Some of us are very interested by this issue and want to add some thoughts about it.

Regarding the actions, it could be useful to have various action types such as redispatching of generation/load, PST tap position switch and HVDC set point switch. It implies that actions are very different from one another, and not limited to topological actions. Of course it is compatible with the current proposed framework with something like:

class GenerationRedispatchingAction extends Action { Map<String, double> generationSwitchById; }

For the conditions model, it could be useful if some conditions are linked to violations and also to the specific status of some network elements. For example the load through a line is above a given threshold. Maybe something like that could extend proposed model:

class LineThresholdViolationCondition extends ViolationCondition{ // simulate the associated action if there is a violation on any of those network elements and if another set of conditions is satisfied List<String> subjectIds; Map<String, double> thresholdById; }

To conclude, it could be useful to have a solution that does not imply that actions have to be switches opening/closure and that conditions have to be line outages.

Hadrien