Automation systems

[olperr1]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem?

No

What kind of change does this PR introduce?

Feature

What is the current behavior?

No automation systems are available in the IIDM.

What is the new behavior (if this is a feature change)?
This PR introduces a first type of automation systems: the overload management systems.

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

If you had define 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();

Other information:

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
9 Code Smells

76.4% Coverage
0.0% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[annetill]

I have made some small changes following the meeting we have. Now:

• We just have a double for current limit for each tripping ;
• I have removed the low/high limit because not clear enough when we talk about current. I understand that we have a potential need (for this iidm version, or could be later ?) to check the active power flow direction at monitoring terminal (positive vs negative, or same charging vs generating, etc.). What is the best way to model that?

[geofjamg]

This comment is also available for the other tripping impl.
I can see 2 issues:

• we use the Identifiable in the setter and getter and not the ID like for monitoredElementId. We have to be consistent.
• the difficulty that we have by using the Identifiable is that we need to manager in the implementation the cleaning in case if the Identifiable removal. Otherwise you will have a link to a dead object, which is bad for a String but even worst if we keep a link to a removed Identifiable.

[olperr1]

You are right.

As discussed together:

• It will be better to introduce a global mechanism to address the problem of referenced network elements removal (deferred for now);
• As a first step, I will replace the Identifiable by a String in the trippings. This won't have an impact on the IIDM serialization result so it will be possible to use Identifiables later without having to publish a new IIDM version.

[sonarcloud]

Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

2 New issues
0 Security Hotspots
97.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud