961   SED file, references export

Created: 21 Dec 2012

Status: Not Applicable

Part: Part 6 (2009-12; Edition 2)

Links:

Page: 16 / 107

Clause: 5.5 / 10.3

Paragraph: c) / 1st paragraph

Category: No impact on this part

Issue

In an SED file, the current interpretation seems to be that if System Configurator tool A exports IED A via SED file to System Configurator tool B, it must also export all its IEDs referenced as clients by its GoCBs/RCBs.
If this is implemented, if we have data exchanges which span several substations, I can end up with an inordinate amount of IED references that serve no purpose.

An example: Let us assume that I am owner/engineer of a small MV substation with 9 Bays/9 IEDs, out of which there are 7 Line Feeders. Each Line feeder has a Distance Protection with a remote connection with GOOSE Data Exchange with another substation. At the same time I have an interlocking/double-command-blocking/(whatever) scheme configured so that all other 8 IEDs in my substation are GOOSE Clients.

Let us assume that all other substations have exactly the same setup. So if I receive an SED file from the substation at the other end of my first line, it will have to include the IED which I actually need and 8 IEDs as references (because they are referenced by its GoCBs).

I will end up with having 7 (lines) * 9 IEDs (1 really needed, 8 for reference purposes) foreign IEDs in my project. So my final tally is as follows: 8 own IEDs, 7 foreign IEDs which I actually connect with and need, 56 foreign IEDs for reference purposes which I neither need nor want, because they just clog up my project.

Additionally there is a security issue: in the age of IT security any data exchange in a network-based system should be limited to the absolutely necessary. In the above example, I receive much more information about foreign substations that I do not need (even in case of GoCB clients only, the problem is worse, if I also resolve inputs sections). Customers may not accept this to the extent that they may even forbid the data exchange via SED files, if they include such a lot of information.

Proposal

Reformulate the SED file description, so that SED files are allowed to have “soft” references, i.e. references that do not resolve within the file (like an IID file).
When exporting an SCD file, I must strip those soft references as an SCD file must not contain unresolved references.

As an exporting System Configurator tool I proceed as follows:
•if I export an IED of which I am the owner with engRights “fix”, I may strip all soft references as they are not needed.
•if I export an IED of which I am the owner with engRights “dataflow”, I must include all clients/inputs as soft references, as they are needed to evaluate limits defined by services).
•if I re-export an IED of which I am not the owner with engRights “dataflow”, after export I set this IED to engRights “fix” in my own project. At the same time, I strip all unneeded soft references (as I cannot change anything anymore, they are not needed anymore for limit evaluation).
•if I re-export an IED of which I am not the owner with engRights “fix”, they had their soft-references stripped on import, so I do not need to deal with it.

As an importing System Configurator tool I proceed as follows:
•if I import an IED of which I am not the owner with engRights “fix”, I may strip all soft references as they are not needed.
•if I export an IED of which I am not the owner with engRights “dataflow”, I must include all clients/inputs as soft references, as they are needed to evaluate limits.
•if I re-import an IED of which I am the owner (with any engRights), I expect all references to resolve. If my own IED has a foreign IED as client, this foreign IED must be included in the SED file.

So after finishing all data exchanges, I have in my own System Configurator tool a number of foreign IEDs with engRights “fix” and all unresolving references stripped. I can export an SCD file with all references resolved.

The only time that deserves special consideration is the moment when my own System Configurator tool contains one or several foreign IEDs with “dataflow” rights. For an SCD export in that period, I can proceed as follows:
•If the SCD Export serves as a temporary storage of my configuration, I can potentially leave soft references as they are.
•If the SCD export serves as a data exchange with an IED configurator tool, it must be consistent. In this case it must strip the unresolved references. However, I need the same mechanism when exporting a foreign IED in an SED file, so there is very little additional effort required.

Discussion Created Status
Not accepted. Part 6 Clause 10.3 states that referenced IEDs shall also be exported, however this may be restricted to that part of the IED needed to resolve the reference. Furtheron, it is not demanded that all references inside an IED must be exported togehter with the IED. E.g. IED references are needed in report control blocks to uniquely identify the instance of an RCB type, but not in GOOSE or SV control blocks. References at GOOSE control blocks, which are not needed to describe the interface to be communicated, can be removed at SED export. In the example above this means that the references in the GOOSE CBs can be removed; if the GOOSE CB shall not be used as interface (e.g. interlocking related GOSOE is normally not needed for line protection), the whole GCB can be removed. In general, for security and (engineering)simplicity reasons only those IED data should be exported which the other system tool needs and is allowed to use to configure its application. 03 Jan 13 Not Applicable

 

Privacy | Contact | Disclaimer

Tissue DB v. 21.10.16.1