1817   Management of private XML namespace needs to be clarified

Created: 23 Mar 2022

Status: Discussion (red)

Part: Part 6 (2019; Edition 2.1)

Links:

Page: 44

Clause: 8.3.8

Paragraph: 3

Issue

This paragraph indicates that all unknown data defined in an IED shall be kept and exported by an SCT.

But paragraph 8.3.5 indicates that only data put in Private section shall be kept, and SICS statement S18 for keeping extensions outside Privates is optional

It already exists devices which use private XML namespaces as attribute as per SCLCoordinates example.

Proposal

Need to clarify if keeping any private data in IED, even outside Private section, is mandatory or optional.

Discussion Created Status
If we approve it as editorial, the comment or an attachment to the TISUE should clearly state the changes to be made 11 Oct 22 Discussion (red)
Based on experts' discussions, it appears that it is not recommended to add an additional possibility to express private data as Private element has been designed for this purpose and all conformant SCTs already support this feature.

A new statement will be added for ICTs to be sure that any extension put outside Private elements shall not cause any problem if they disappear in an SCD.

This also apply to private extension put in communication section (either inside or outside of Private element) as it is clearly discouraged to use them in section 8.3.6 Note : "Due to the engineering process as described in clause 5 IED configurators should not put Private elements into the Communication section".

The statement will be put in ICT definition and in SICS
05 Oct 22 Approval (Editoral)
1) if the ICT requires the extension to be present for its correct operation -> it shall define it in the context of a Private Element.
There is already a way to maintain the information, there is no need to create another way.

2) If the ICD is providing 3 Subnetworks, it does not mean that the 3 Subnetwork are preserved in the SCD file. However the 3 ConnectedAP shall remain in the communication secttion. May have been moved to other project related subnetworks.

3) Based on 2, if the ICT requests to have communication related maintained information, it shall create them at the ConnectedAP and not at the Subnetowrk level.
02 Aug 22 Discussion (red)
There is some clarification needed for elements in common SCL sections. Just one example: The ICD has 3 Subnets W1, W2, W3. The Project SCD has 2 Subnets : "StationBus" and "ProcessBus". What is the SCD supposed to do with eXML entries below W1, W2, and W3? 28 Jul 22 Discussion (red)
The change proposed is a workaround for only part of the problem. Even with this change, it is permitted for an SCT to remove non-SCL XML namespaces from the generated SCD file, which an ICT may require to be present for its correct operation.

I believe a more complete solution is possible in the future, EITHER:
1. Make it mandatory for SCT (and other tools) to correctly import, maintain and export non-SCL XML namespaces (including private/vendor XML namespaces and transitional XML namespaces), OR
2. Make it mandatory for a conformant ICT and its corresponding IED to still operate correctly if the SCT does remove the non-SCL XML namespaces from the SCD file.

Both are technically possible, and able to be conformance tested.
27 Jul 22 Discussion (red)
need clarification 01 Jun 22 Accepted

 

Privacy | Contact | Disclaimer

Tissue DB v. 22.10.13.1