feat(editors/subscription): add subscription supervision support

[juancho0202]

closes #942

[JakobVogelsang]

@juancho0202 I did first tests and so far have seen a bug that need to be fixed in this PR:
When a new supervision logical node is created we need to make sure that the inst attribute is unique. At the moment, the inst is not existing for the new element LN.

[JakobVogelsang]

@juancho0202 Another thing I have found: subscription from DATA BINDING does not add any supervision information to the sink IED

[JakobVogelsang]

I have found one functional issue and some little code related stuff but nothing big. One thing that I would ask you for: use empty lines to make the code read better. Some long function are hard to digest at the moment.

[danyill]

Thank you for your patience with this PR.

I have not looked at the code (at all) but have finally done a little user testing with an ICT. The test was:

• configure GOOSE and SMV mappings between a Schweitzer SEL-411L-2 and an NR PCS-221S relay using OpenSCD
• open in SEL Architect to see if they are recognised
• since they are not, modify the XML by hand to the point where SEL Architect will recognise the supervision LNs

The results are... not great and very likely what Jakob expected when we started this.

• goCBRef is insufficient to instantiate the supervision and SEL Architect does not recognise it.
• Once I add all the fields in the LNodeType that seem to be required, the file will still not save without errors relating to the esel namespace.
• Deleting the OpenSCD (hand-modified) supervision and recreating it in SEL Architect appears to work but the file remains with errors.
• Basically, SEL Architect does not support an SCT creating supervision nodes.
• Even if we were to make the supervision pluggable the requirements of SEL Architect are too expansive and relate to their own namespace so I think that changes must be made within the ICT before it is feasible to consider this.

For OpenSCD and this PR (for discussion):

• The supervision instance didn't appear to be created for the LSVS LN. I have not investigated why.
• These results perhaps indicate that we should disable supervision by default or find a whitelisting/blacklisting approach based on platform/software/devices tests.
• I would like to go back to SEL with some comments and see if they are willing to improve SEL Architect.
• My files used for testing and a write-up are attached: LGOS_LSVS_SEL_and_NR_v0.01.zip
• For the write-up, extract the zip file and open LGOS_LSVS_SEL_and_NR_v0.01.html. @JakobVogelsang could you see if you agree. If so I'll take this up with SEL. For our engineering workflow we could do the supervision as a final step in an ICT but I would prefer this to be in the domain of the SCT.

I propose to do a test like this for Siemens, NR and GE in the next few weeks, but it will take me some time... Hopefully this is helpful in the meantime. Has anyone done a test like this with Siemens or other IEDs?

[JakobVogelsang]

Good evening @danyill, THANK you very much for this detailed test! I love the level of detail you are adding.

Before you approach SEL to allow this feature, and you should, one more detail. Acc. to the standard, there as a way vendors can express whether instantiated data is processed. This can be done through valKind and valImport attributes. See an example how this is done in SIEMENS

<DOType id="SIPROTEC5_DOType_ORG_external_V09.30.01_V09.30.01" cdc="ORG">
   <DA name="setSrcRef" bType="ObjRef" valKind="RO" dchg="true" fc="SP" valImport="true"/>
</DOType>

For this feature to work, valImport must be true and valKind either RO or Conf.
In the fields you provided, this looks like:

<DOType  id="ORG_0_2" cdc="ORG">
   <DA name="setSrcRef" bType="ObjRef" dchg="true" fc="SP"/>
</DOType>

This means however that we cannot expect the vendor to accept this. SEL clearly expressed that this value instantiation is read back into the ICT.

I did test with DIGSI 9.30 and at least the update of LGOS and LSVS seems to work. We will do an online test in the next weeks to prove. I am confident however that is works.

I would propose therefore to still try to not overcomplicate the feature as when we did our work properly in the SEL there will not be any subscription supervision added.

@juancho0202 please forgive me this! It is in the requirements of this issue but I did not test yet nor have added it to the test files. So as a reminder this is the requirement

Check if the IED allows instantiating values DataTypeTemplates>LNodeType[lnClass="LGOS"]>DO[name="GoCBRef"]>DA[name="setSrcRef"] has attributes valKind=Conf/RO and valImport=true.

[danyill]

Somewhat incidentally, but perhaps in our upcoming supervision editor, we could add to the story a way of ensuring that the user is not confused about why some IEDs will provide supervision and others will not.

IED manufacturers do not declare this, and I think we could provide an interface which shows the "calculated capability" and usage of LGOS and LSVS LNs.

[JakobVogelsang]

LGTM. I have by hand tested the last two open issues and i works. From my point of view it can be merged