The other day somebody from the user community posted a comment on this blog. The issue discussed is on Interoperability and Replacement of an IEC 61850 compliant IED by another one:
"That is exactly what we users want: not just be able to have different IEDs from (possibly) different vendors cooperating in our substations, but also be able to replace an IED by another one that is functionally equivalent (or superior, or maybe just similar, this being the utilty’s internal issue) regardless of what the other system components are, and in the easiest possible way."
First of all, the Replacement of an IEC 61850 compliant IED mainly depends on the implementation of the standard (which subsets, ..., restrictions) and on the configuration of the system.
Replacement could be very easy but also be a bit complicated. One example shows the impact of the implementation (restriction) and one shows the impact of the configuration.
Restricted implementation: Suppose that an IED A (to be replaced) has 10 Logical Devices to model the application. IED B (to replace IED A) has only the possibility to support five (5) Logical Devices; the restriction is done during the design of the IED.
The system engineer has configured the IEDs and the information flow between them, e.g., the flow from IED A to other IEDs. The designed information flow between IED A and other IEDs is like a Contract. This contract says that IED A has 10 LDs and underlying LNs and DataObjects. The LD name are used to designate the DataObjects; the LN-Reference contains the LD-Name. A DataSet could have members from all 10 LDs (this could be "written" in the contract).
If the IED B has only five (5) LDs then the designation of the DataObjects will likely be different - it requires a modified Contract! The Clients (Subscriber) have to take these changes of the designation into account. This may require a re-configuration of the Clients (Subscriber).
Click HERE for a PIXIT document providing some information about an IED, e.g. restriction of GOOSE messages that can be sent (<= 16) ...
Don' forget: Everything is limited!!
Configuration of the system: Even if IED A and IED B have the same signal designations (same model) it could be that the "old contract" defines a flow as follows: the information to be reported or goosed is defined in a very big DataSet (e.g, of 100+ members). IED B may only support DataSets with a maximum of 50 members. As a consequence the "contract" has to be modified to create two (or more) DataSets and two or more ControlBlocks. The Clients (Subscriber) have to take this into account.
The "easiest possible way" means to apply the same "contract" (flow configuration) for IED A and IED B. If IEDs would be quite flexible with regard to the "contracts" then a replacement would be quite easy.
By the way, the question, which "contract" we could write depends on the vendors' implementations and the way how people configure systems, BUT not on the standard!
The utility requirement could be modified as follows: "to replace an IED by another one that is functionally equivalent (or superior, or maybe just similar, this being the utilty’s internal issue) AND that uses the same "Contract" of the information flow between the two IEDs, regardless of what the other system components are."
Posts
