Migration guide v6.2.0

Breaking changes

IIDM

Automation systems: Overload management systems

If you have defined your own IIDM implementation, you should implement the following methods:

• in your Network implementations:

  • Iterable<OverloadManagementSystem> getOverloadManagementSystems()
  • Stream<OverloadManagementSystem> getOverloadManagementSystemStream()
  • int getOverloadManagementSystemCount()
  • OverloadManagementSystem getOverloadManagementSystem(String id)

• in your Substation implementation:

  • OverloadManagementSystemAdder newOverloadManagementSystem()
  • Iterable<OverloadManagementSystem> getOverloadManagementSystems()
  • Stream<OverloadManagementSystem> getOverloadManagementSystemStream()
  • int getOverloadManagementSystemCount()

New "Ground" injection

If you have defined your own IIDM implementation, you should implement the following methods:

• in your Network implementations:

  • Iterable<Ground> getGrounds()
  • Stream<Ground> getGroundStream()
  • int getGroundCount()
  • Ground getGround(String id)

• in your VoltageLevel implementation:

  • GroundAdder newGround()
  • Iterable<Ground> getGrounds()
  • Stream<Ground> getGroundStream()
  • int getGroundCount()

• in your TopologyVisitor implementation:

  • void visitGround(Ground connectable)

Reactive power control mode for ration tap changers

If you have defined your own IIDM implementation, you should implement the following methods:

• in your RatioTapChanger implementations:

  • RegulationMode getRegulationMode()
  • RatioTapChanger setRegulationMode(RatioTapChanger.RegulationMode regulationMode)
  • double getRegulationValue()
  • RatioTapChanger setRegulationValue(double regulationValue)

• in your RatioTapChangerAdder implementations:

  • RatioTapChangerAdder setRegulationMode(RatioTapChanger.RegulationMode regulationMode)
  • RatioTapChangerAdder setRegulationValue(double regulationValue)

Besides, ValidationUtil.checkRatioTapChangerRegulation methods take an additional parameter: regulationMode, the regulation mode (note that targetV parameter was also renamed in regulationValue).

Steps replacement on a tap changer

If you have defined your own IIDM implementation, you should implement the following methods:

• In your PhaseTapChanger and RatioTapChanger implementations:
  • ... stepsReplacer().

Notification system for extensions

If you have defined your own implementation of NetworkListener without inheriting DefaultNetworkListener, you should implement the following methods:

• void onUpdate(Identifiable<?> identifiable, String attribute, String variantId, Object oldValue, Object newValue)
  • This method previsouly existed with a default implementation which was removed
• void onExtensionCreation(Extension<?> extension)
• void onExtensionAfterRemoval(Identifiable<?> identifiable, String extensionName)
• void onExtensionBeforeRemoval(Extension<?> extension)
• void onExtensionUpdate(Extension<?> extendable, String attribute, Object oldValue, Object newValue)

Secondary voltage control notifications

The SecondaryVoltageControl extension was refactored to use the newly introduced notification system for extensions.

Creation

To create a new SecondaryVoltageControl extension, you should now use a builder:

• Before:

SecondaryVoltageControl control = network.newExtension(SecondaryVoltageControlAdder.class)
         .addControlZone(new ControlZone("z1",
                                         new PilotPoint(List.of("NLOAD"), 15d),
                                         List.of(new ControlUnit("GEN", false), new ControlUnit("GEN2"))))
         .add();

• After:

SecondaryVoltageControl control = network.newExtension(SecondaryVoltageControlAdder.class)
             .newControlZone()
                 .withName("z1")
                 .newPilotPoint()
                     .withBusbarSectionsOrBusesIds(List.of("NLOAD"))
                     .withTargetV(15d)
                 .add()
                 .newControlUnit()
                     .withId("GEN")
                     .withParticipate(false)
                 .add()
                 .newControlUnit()
                     .withId("GEN2")
                 .add()
             .add()
         .add();

Custom implementations

If you have defined your own implementation of SecondaryVoltageControl, you should:

• define custom implementations for PilotPoint, ControlUnitand ControlZone, and their respective adders. The default implementations which were provided were transferred in iidm-impl to benefit from the notification system;
• remove your implementation of SecondaryVoltageControlAdder.addControlZone(ControlZone controlZone);
• implement SecondaryVoltageControlAdder.newControlZone().

The easiest way to do it is to can take your inspiration from the implementation classes located in iidm-impl.

Permanent limit mandatory

We did it! From this version, we add a check to ensure that when a connectable has temporary loading limits, it has a defined permanent limit. Note that it does not mean that a permanent limit is required for all equipments that could have one. In order to ensure compatibility with previous IIDM version, if the permanent limit is missing, we fix it with a percentage of the lowest (in value) temporary limit, by default 100%. This percentage is configurable at import: for a different value, please use iidm.import.xml.missing-permanent-limit-percentage parameter.

Connectable connect/disconnect

Starting from this release the four following methods have been added to Connectable interface

boolean connect();
boolean connect(Predicate<Switch> isTypeSwitchToOperate);
boolean disconnect();
boolean disconnect(Predicate<Switch> isSwitchOpenable);

Hence, if you have defined your own implementation of Connectable, you need to implement these methods.

Connection/disconnection notifications

When using the default IIDM implementation, at terminal connection/disconnection:

• the "connection" notifications that were emitted are replaced:
  • at connection by:
    • a "beginConnect" notification before the connection. Its oldValue contains the previous connection state of the terminal;
    • a "endConnect" notification after the connection. Its newValue contains the final connection state of the terminal;
  • at disconnection by:
    • a "beginDisconnect" notification before the disconnection. Its oldValue contains true if the terminal was previously disconnected, false otherwise;
    • a "endDisconnect" notification after the disconnection. Its newValue contains true if the terminal is now disconnected, false otherwise;
• the "connected" notifications are replaced by "connected" + side number notifications. The content of their oldValue and newValue attributes is unchanged.

If you have defined your own IIDM implementation, you should implement the following methods:

• in your Terminal implementations:
  • ThreeSides getSide()

Security analysis

Terminals connection action

The LineConnectionAction has been removed and replaced by TerminalsConnectionAction. With this new remedial action, we can open or close one Terminal, given by an element id and a side (instance of ThreeSide). The side is optional: in that case, the remedial action means that the terminals of the element will be all opened or all closed. The element can be any connectable (line, transformers, injection, etc.). If the element is a TieLine, terminals refer to the underlying dangling lines' terminals. If the element is a HvdcLine, the terminals refer to the converter stations' terminals. In case of a two-terminal element, remember to use utility method to convert a ThreeSide in a TwoSide if you apply the remedial action on the network.

Quality

Runtime dependencies

TODO or delete

Deprecated methods clean-up

TODO or delete

The following deprecated methods have been deleted:

• TODO()

The following deprecated enum types have been deleted:

• TODO