tIED: updateIED does not update setSrcRef DAIs

[danyill]

I've been testing the rename IEDs function with some ICTs.

I believe we don't update the setSrcRef with rename IEDs in general.

<DOI name="InRef1">
    <DAI name="setSrcRef">
        <Val>XAT_232_P1PRO/DC10CILO10.EnaOpn.stVal</Val>
    </DAI>
</DOI>

Should we be generally processing a file's object references on a rename?

Perhaps this setSrcRef may be a bug in my CID file (it was hand crafted) and there shouldn't be IED references within the Val

[danyill]

We should update LDNames as part of an IED rename:

[danyill]

I will prepare a PR for these in the next few days for this and outline the methodology.

This will likely replace our current approach for control block references for LGOS/LSVS as well and provide a more generic functionality.

I worry that it may also be quite a lot slower, but we'll see 😉

[danyill]

Here would be the basic methodology to be refined during implementation:

1. Begin by searching the DataTypeTemplates section for object
   references. These are the candidates which will need replacement in
   the file if the have a fully qualified object reference including an
   IED Name.

   These can be identified by querying Data Attributes with a basic
   type of object reference. These must be within a data object type
   with the CDC of "ORG":

   doc.querySelectorAll(":root > DataTypeTemplates > DOType[cdc='ORG'] > DA[bType='ObjRef']").
   

2. We must store the id for the parent logical node type and the data
   object name:

   • DA.parentElement.getAttribute('name') = DOType[name]

   • DA.parentElement.getAttribute('id') = DOType[id]

     and then query for actual LNodeType which includes this:

     doc.querySelectorAll(`:root > DataTypeTemplates > LNodeType > DO[type='DOType.id']
     

   We will use these later to confirm they are definitely object
   references. They could be stored as Map<LNodeType[id]:DOI[name][]>

3. Then we must go through each IED including the one being renamed.
   We must process each LN and LN0 with the appropriate lnType and
   DOI[name] entry and retrieve the object references.

   doc.querySelectorAll(":root > IED > AccessPoint > Server > LDevice > LN[id="stored id"] > DOI[name='stored name'], :root > IED >  AccessPoint > Server > LDevice > LN0[id="stored id"] > DOI[name='stored name'] > DAI[name='setSrcRef']")
   

4. We could choose to make an enormous query of these or somehow
   process all the DOIs with the correct name — I’m not sure what the
   most efficient manner is.

5. For each DAI we then definitely have an object reference as the text
   content of the <Val> element.

6. If it is a fully qualified IED object reference I expect it to be of
   the form LDName/ where LDName = ${IED[name]}${LDevice[inst]}

7. We must then test that our existing IED[name] matches and that if
   this matches then that the LDevice[inst] also matches (an actual
   LDevice[inst] within that IED). If it does, we replace those
   characters and move along.

8. We could also whitelist certain DOI names and we could also do some
   namespace checks??? I am not planning to do these in the initial
   implementation.

9. For now I’m assuming we don’t put object references in the
   DataTypeTemplates themselves but that may not be entirely true
   (seems to be for the devices we use so that can be a later addition
   as required).

[Sander3003]

Quetions: Does the IEC61850 both support relative and absolute path names?

[danyill]

We discussed at refinement today.

We thought that it would be best to index object references and have an scl-lib option to "respect" permissions (valKind/valImport) but to default to updating any object reference that we think might break as a result of, say an IED name update.

However some IED manufacturers are known not to accept control block reference updates in LGOS/LSVS Go/Sv-CBRefs so this logic should be retained.

I'll first try and do an acceptable implementation for updateIED and then if it seems like a good idea we could then do a more efficient updateIEDs.

It is still possibly that my use case is a little pathological but object references are used by manufacturers in various ways and it's allowed within the standard to fully qualify them so we should check.