feat(editors/subscriber/later-binding): add input requirement check

[JakobVogelsang]

Closes #867

Check that the selected data and a later binding external reference match in terms of their CDC and bType specification.

[danyill]

Just one real question/comment from me.

[danyill]

The changes look good.

I have, I think found an issue in testing some files although it may be unrelated to this new feature and more related to some other later binding issue which I keep seeing but haven't nailed down and I must investigate.

I have created a more minimal example:

XAT_Prot2_Preconfigured_Check (1).scd.zip

For IED XAT_232_P2, there exists an unmapped ExtRef:

<ExtRef desc="RxExtIn1" intAddr="RxExtIn1;/Ind/stVal" pServT="GOOSE" pDO="Ind" pDA="stVal"/>
<ExtRef desc="RxExtIn1" intAddr="RxExtIn1;/Ind/q" pServT="GOOSE" pDO="Ind" pDA="q"/>

Both stVal and q have preconfigured restrictions (I manually removed the pre-existing mapping).

I expect on the right-hand side that the q values are greyed out because the bType for a general (boolean) and a quality value (Quality) are distinct.

I can look at this in more detail for some time if this is not clear enough -- but perhaps I have misunderstood?

[JakobVogelsang]

The ExtRef is missing pLN. So far we do not restrict so long not all four attributes pLN, pDO, pDA and pServT are not given. Do you think this is incorrect @danyill ?

[danyill]

The ExtRef is missing pLN. So far we do not restrict so long not all four attributes pLN, pDO, pDA and pServT are not given. Do you think this is incorrect @danyill ?

Thank you for looking.
This whole referencing system is dubious as you point out.

I think Part 6, 9.3.13 allows for partial pXX referencing:

In this case any values at pDO and possibly pDA allow to specify the CDC
respective attribute type expected for this intAddr. Together with lnClass this allows to specify
a functionally expected input. The desc attribute allows to give it additional informal meaning,
the serviceType attribute the intended service quality. If at least the pDO attribute is specified,
then a missing pDA attribute includes at least all the operational value attribute(s) of the DO,
i.e. stVal, mag, t, q etc. It might allow binding of additional attributes supported by the service
type.

And also:

Specifying expected inputs (input templates) of logical devices or logical nodes from
the view of the IED configuration tool. The intAddr attribute shall be set to a non empty
value. The pDO might specify the needed input CDC via a standardized DO name,
additional pDA values might indicate the expected data type of an attribute and the
pLN might document the expected function providing the input. pServT might provide
the expected service type for this input value. These attribute values, if supplied by the
IED configurator, shall not be modified by the system configurator. A system
configurator binding to these input templates must assure that the CDC specified by
pDO and, if given, the attribute (base) type specified by pDA are met. For a final
engineered data flow also the pServT, if given, shall be met by the serviceType value.

This seems to indicate that pLN can be optional.

As long as we have a "relaxed" approach where the provision of pXX but not finding a match allows subscriptions to be done I think we are all good. We can improve this feature in future on request or as the need arises.

I do see some benefit in being able to specify only pDO and pDA because it means that the quality items will be nicely greyed out when mapping operate or state values which is pleasant from a UI point of view.

I think we should merge this unless you would like to do more 👍

[JakobVogelsang]

I would merge this as is. It goes easy on the fully specified restriction at the moment. I think this in the future we will see more vendors using all attributes than the other way around. To make the implementation adjust more with the idea in the standard, I would propose another algorithm that goes something like this.

1. get all DO, SDO based on the pDO
2. filter for option lnClass but at least filter DO, SDO used by the subscribing IED
3. map to DOTypes cdc.
4. filter all null and or undefined
5. put into Set.
6. take the first entry. There should be only one

for data attributes

1. get all DA, BDA based on the pDA
2. filter for optional lnClass but at least filter DA, BDA used by the subscribing IED
3. optional filter for given
4. map to DAs and BDAs bType.
5. filter all null and or undefined
6. put into Set.
7. take the first entry. There should be only one

That could be fast search but also not really reliable. LN to DO to DA is clear, but the other way around is not. However, we want to not be restrictive if we are not sure, so this would even fit the concept.