Created: 21 Dec 2012
Status: Not Applicable
Part: Part 6 (2009-12; Edition 2)
Page: 16 / 107
Clause: 5.5 / 10.3
Paragraph: c) / 1st paragraph
Category: No impact on this part
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.
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.