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
4 comments:
Dear Karlheinz:
I am very happy that the ‘interchangeability’ topic, far from being a taboo, is openly discussed here.
I absolutely agree with you that ‘everything is limited’, but limitations should arise from the fact that you cannot always avoid a trade-off between benefits that are at the same time desirable and mutually incompatible, not from a fundamental lack of the interoperability standards and its implementation at the IED design phase.
Let me explain this point. The user wants flexibility and, at the same time, ease of implementation. However, an infinite degree of both is not generally achievable, and that is why (coming back to the TV set example), before effective replacement of set A by set B, the user will surely have to perform some tasks like channel-tuning, etc. Obviously you cannot expect a device to come out from factory having exactly the configuration desired by a final user thay is still undetermined.
The same goes for IEDs: easy replacement is a goal, yes, but not an absolute goal if you also want to have a degree of flexibility.
On the other hand, imagine that, prior to effective replacement, you also have to reconfigure THE OTHER devices, i.e. those which were already there, communicating with the replaced IED. In my view, this would be the result of something going wrong with either
i) the implementation of the international standard in the new device (too restrictive, so that it cannot be configured in a way that is straight away ‘transparent’ to the old devices), or,
ii) the international standard itself (too unrestrictive, so as to permit such IED to be still standard-compliant),
Of course here I grant you that some issues cannot be completely anticipated by the international standard or the IED design: mainly size issues such as how many ítems of this or that category (logical devices, datasets, dataset members, etc.) the IED supports. Such particulars should always have to be addressed by each utility at the time of designing its local standards and settling its vendor agreements. However, you will probably agree that you can establish a set of ‘reasonable minima for those maxima’, so that 99 % of potential installations are feasible using only IEDs comprised thereby.
At the E3 Group we believe that the IEC 61850 standard still has some run ahead before it reaches the ideal trade-off point between restrictiveness and flexibility. We wish to cooperate with the rest of the IEC 61850 community so that the standard (or its implementation) evolves in a way that meets the users’ requirements. To achieve such goal, the first step is to express those requirements. Well, that is what we are here for! The E3 Group specification document is available (just like everything that is important and is IEC-61850-related) at this resource. Interested readers must go to a June 16, 2010 post, from where a link will lead them to the document.
Regards,
Julio Dominguez
SAS user and utility representative at the E3 Group (Spain)
The TV is not a good analogy in isolation. It can work straight out of the box (assuming it has the same voltage supply and the same plug for the power point) by running the set up routine and immediately replace the old TV. However can it be used with my DVD player, video cassette player, and hook into my surround sound system and connect to my internet cable downloads ….?
I cannot replace my TV in this system without checking (engineering) the physical interfaces HDMI/RGB/coax…) and signal standards (PAL vs NTSC) etc. If all my fancy gear assumes the TV has an HDMI input then there is no possibility the TV could ever work if I only bought a replacement TV with only an RGB or coax input - and you can’t blame the TV or the other system suppliers for that lack of incompatibility – it is purely my ill-informed choice when I bought the TV. The problem is always how things connect and talk to each other starting with whether they have the required functionality.
In terms of IEC 61850 I see so many utilities buying pieces of the system with a one line statement added to their conventional IED procurement spec which says “and it shall be IEC 61850 compliant”.
There are so many analogies here – if I sent 2 people to 2 different shops – one to buy a nut and one to buy a bolt, they are just as likely to come back with a 10mm nut and 8mm bolt – both are compliant to the spec I gave them but totally useless in combination. Then add a whole lot of other criteria of how they are going to be used -- left/right thread, metrix/SAE/whitworth, hex/screw head, length, full thread/shank…..
So it is with IEC 61850 compliance. ALL that the conformance certificate says is “whatever the vendor has chosen to implement is not failing against the standard”. This gives us confidence that if we choose to use one of its implemented features it has been done correctly. It does not give us the confidence to be able to apply it incorrectly.
Rod Hughes
(rgh@rodhughesconsulting.com)
I have to comment on Julio’s second reason of what could have gone wrong if a system is not working.
The Standard is clear – just read Part 1, chapter 1. It has never set out to achieve that any device could be disconnected and replaced by another device without engineering.
I implore all users to properly understand the clause in Chapter 1
“The purpose of the Standard is neither to standardise, nor limit in any way, the functions involved in substation operation nor the allocation within the substation automation system”
Clearly “blind interchangeability” is not the objective of the Standard. Hence Julio’s second “thing to go wrong” suggestion that the Standard could be too unrestrictive is in fact exactly what the Standard sets out to be as TOTALLY unrestrictive!! If it becomes restrictive we will forever be constrained to the solutions we have today.
I agree with Julio, we don’t want to have to reconfigure existing devices in the system just to replace or add a new device to the system. This requires smart selection of devices that comply to the Standard AND to the application (buying a Ford car is compliant to road standards but is it left or right hand drive? How many passenger seats does it need? …). It also means smart engineering making sure the messages I want to send are universally understandable eg a CBF trip message could be “trip bay 1, trip bay 2 …” and hence needs all devices to be reconfigured when I add an 8th bay and an extra part to the message “trip bay 8”. This is better handled by a message which says “trip bus 1” and simply have each device know which bus it is connected to. Smart engineering is vital. “Pick and pray” equipment selection certainly won’t work.
The last point to comment on is the engineering process itself. Some specifications are popping up which suggest that the SCD file is created by combining CID files. This is arguably the limitation and reality of a vendor tool which simply wishes to configure a single device and hence go from ICD direct to CID- although the system will work (with a lot of effort), this is NOT the engineering process of Part 6. Following this approach will result in a ‘partial SCD’ which has no information with respect to how the functions relate to the primary plant arrangement (the substation section created by the SSD file first) and consequently you can’t create a new bay for an expanded substation just by copying an n existing bay and all its elements– what I call REUSASBLE ENGINEERING. Part 6 requires that the CID file be created as a subset of the SCD. So if we want to make the engineering of the substation maintenance or augmentation easier for the future, the Systems Integrator has to use tools that will achieve it.
Rod Hughes
(rgh@rodhughesconsulting.com)
I have to comment on Julio’s second reason of what could have gone wrong if a system is not working.
The Standard is clear – just read Part 1, chapter 1. It has never set out to achieve that any device could be disconnected and replaced by another device without engineering.
I implore all users to properly understand the clause in Chapter 1
“The purpose of the Standard is neither to standardise, nor limit in any way, the functions involved in substation operation nor the allocation within the substation automation system”
Clearly “blind interchangeability” is not the objective of the Standard. Hence Julio’s second “thing to go wrong” suggestion that the Standard could be too unrestrictive is in fact exactly what the Standard sets out to be as TOTALLY unrestrictive!! If it becomes restrictive we will forever be constrained to the solutions we have today.
I agree with Julio, we don’t want to have to reconfigure existing devices in the system just to replace or add a new device to the system. This requires smart selection of devices that comply to the Standard AND to the application (buying a Ford car is compliant to road standards but is it left or right hand drive? How many passenger seats does it need? …). It also means smart engineering making sure the messages I want to send are universally understandable eg a CBF trip message could be “trip bay 1, trip bay 2 …” and hence needs all devices to be reconfigured when I add an 8th bay and an extra part to the message “trip bay 8”. This is better handled by a message which says “trip bus 1” and simply have each device know which bus it is connected to. Smart engineering is vital. “Pick and pray” equipment selection certainly won’t work.
The last point to comment on is the engineering process itself. Some specifications are popping up which suggest that the SCD file is created by combining CID files. This is arguably the limitation and reality of a vendor tool which simply wishes to configure a single device and hence go from ICD direct to CID- although the system will work (with a lot of effort), this is NOT the engineering process of Part 6. Following this approach will result in a ‘partial SCD’ which has no information with respect to how the functions relate to the primary plant arrangement (the substation section created by the SSD file first) and consequently you can’t create a new bay for an expanded substation just by copying an n existing bay and all its elements– what I call REUSASBLE ENGINEERING. Part 6 requires that the CID file be created as a subset of the SCD. So if we want to make the engineering of the substation maintenance or augmentation easier for the future, the Systems Integrator has to use tools that will achieve it.
Rod Hughes
(rgh@rodhughesconsulting.com)
Post a Comment