Interoperability - not Interchangeability

First and MOST IMPORTANTLY, IEC 61850 does NOT provide Interchangeability !!!
Please refer Part 1, Ch4, 2nd para (both Ed 1 and Ed2):
"Interchangeability is beyond this communication standard"

We must be careful not to create unrealistic expectations of IEC 61850 as a solution to "world peace and hunger"!

What IEC 61850 DOES provide is the engineering process and configuration requirements for two functions to communicate with each other INTEROPERABLY

http://en.wikipedia.org/wiki/Interoperability :
"Interoperability is a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation."

In other words, it provides the ability for REUSABLE ENGINEERING of how you can make configurations for two functions talk to each over an Ethernet communication infrastructure (cat5/6, fibre, WiFi, radio - perhaps not carrier pigeons !) regardless of whose IEDs are chosen to be involved. This does not mean "any IED can be directly replaced by any other IED"

You can say that IEC 61850 is one of the first (new) CHECK POINTS for INTERCHANGEABILITY in that the replacement IED has to support the same data model and the same communications services as the previous IED (just check their ICD files).

That being the case then the specific old IED's IEC 61850 IED configuration section contained in the SCD (repeat for emphasis "in the SCD" !!) can be used by the new IED's IED Configurator Tool to create the CID for loading into the new IED.

• This means the new IED's IED Configurator Tool MUST support importing an SCD - some don't!
• Moreover, this also means that the SCD file MUST EXIST from your previous engineering process!

OBVIOUS, but I dare say probably not properly true for pretty much most of the projects done around the world to date.

IEC 61850 the "wrong" way

Note that if the original engineering process merely took an ICD and created multiple instances of that file (most likely incorrectly call CID since they probably have no Substation section binding and no communication section information of the other IEDs it is talking to) then you will NOT have the equivalent of an SCD.

This approach is often referred to as "bottom-up" engineering and generally based on ONLY using the individual vendor's IED Configurator Tool (ICT) defined in Part 6 of the Standard. 
The ICT is one of three such tools defined in the Standard ... but as I often say you can't build a house or an F1 racing car with only two types of screw drivers!
I refer to it as "bottom-to-bottom" or "bottom-to-mess"! 

In principle, and with a lot of manual "intervention" in the engineering process, it is quite possible to eventually "make it work" as a system ... that "intervention" is often the reason for most of the criticism of IEC 61850 and comments like "interoperability does not work".  

Taking several such CID and 'adding' them together does not necessarily, certainly not easily, create an SCD.

"CID"1 + "CID"2 + "CID"3 << SCD
... or many definitions would appear multiple times because they were defined in each vendor tool's CID .. consider wanting to change one thing but forgetting to change it everywhere!

Further, such "CID" files not as subsets of SCD (noting they may not really be true CID) created by the old IED IED Configurator Tool may or may not be accepted as imports to the new IED Configurator Tool - e.g. the old IED's IED Configurator Tool may create the IED section to use the ".Type" field for one particular purpose (since that purpose is not prescribed within IEC 61850 except that it exists), whilst the new IED's tool may require that use to appear in ".desc"

Hence we see the comments by ENTSO-E and VLGPO where early IEC 61850 systems were not easily expandable as the users had hoped.

IEC 61850 the "right" way

However CID1 as created by the IED Configurator Tool as subset of an SCD is the correct CID file. Hence properly created SCD IS the ONE SOURCE OF TRUTH.

Part 6 of the Standard is fundamentally based on

1. First creating and SSD file defining substation structure and functions.
2. Then evolving that to an SCD file with every physical device instance and communication configuration between them
3. THEN creating the individual CIDs for each physical device as subsets of teh SCD

This is referred to as top-down" engineering.

If these IEC 61850 principles and processes weren't used at the outset, you can't really expect subsequent engineering processes (proper IEC 61850 or otherwise) could 'blindly' take up the original engineering and do some scheme modification, system augmentation or IED replacement.

What does Interoperability mean in practice - what is IEC 61850 trying to achieve?

If we think about a relay sending a protection operation status to a bay controller (or perhaps direct to an intelligent interface switchgear IEC 62271-3),

Apart from the substation name and bay name, it is always the same named piece of information (Logical Node.DataObject.DataAttribute semantic) being put in a GOOSE message and the same message being subscribed to in each bay

Alpha_Bay1_PTRC.Op.stVal is a 1 or 0 of whether the Prot function has operated or not

Alpha_Bay1_XCBR.Pos is the indication of whether the CB should be closed or open

So if the relay published the status of the protection element Alpha_Bay1_PTRC.Op.stValin a GOOSE message named “GOOSE1”

...and the CB interface is configured to subscribe to that message and change the CB position accordingly ...

Now image if in another bay (or another project in another substation) we have another relay (perhaps different vendor) and a different CB interface (perhaps different vendor), simply change Bay1 which is changed on receipt of te message from Alpha_Bay1_PTRC.Op.stVal protection device containing Alpha_Bay4_PTRC.Op.stVal ... all we need is to have is Alpha_Bay4_XCBR.Pos subscribe to that same GOOSE1 being published in that substation

So apart from naming the substation and bay prefix, EVERYTHING is the same!!

So ..

... how many times do you have to test the complete scheme signal exchange if you are only changing a prefix when you copy one device config into another bay???

....... and then consider the protection settings for all the different functions and all the proprietary names that we used to have for Pickup, I>, Istage1 ....

.........and the hundreds of functions in any one relay these days

Note .. nowhere in that configuration is the vendor selection identified!

So it is all VENDOR AGNOSTIC.

In fact I can create the entire communication system without even knowing which vendors I will select!

You can even test all that signal exchange in a simulator BEFORE you get any hardware, even using the specific hardware capability files to see what it actually does.

• All you have to do is make sure the relay vendor provides the PTRC Logical Node and the interface vendor provides the PTRC Logical Node.
• And then click another button to identify your SCADA I/O list .. even import that into your SCADA graphics tool!
• And if you want to replace one vendor with another, you can focus, even use tools, to evaluate whether the replacement device has the necessary functionality as the first one ... or create a "shopping list" file of the required IED capabilities (watch out for the upcoming IED Specification Description ISD file that some SST and SCT tools already provide)

Compare all that to the engineering effort (i.e. a VERY human-error prone process for wires) drawings with wire numbers, installation of wires, terminal numbers, point-to-point testing, being commissioned ..

I have long said (almost 20 years now) IEC 61850 is More, Faster, Less, Less, Higher, Lower .... IEC 61850 Applications

But recently I have upped my rhetoric to emphasise that it is ALL about eliminating repetitive human error in wire based engineering .. repetitive from one step to the next, and from one project to the next.

Which also leads in to another favourite saying of mine ... Say No to GGIO
Some vendors and indeed some asset owners have taken an approach of "mapping" every function via a GGIO Logical Node. 
First such mapping is specifically contrary to the principles defined in Part 5 and in Part 7-4 (Edition 2) of the Standard that GGIO is ONLY for mapping of wire‑based signals (the "real world" .. and only where there is no equivalent semantically defined Logical Node that is self‑defining. As example, because "GGIO59234.Alm1" (or is it "GGIO3.Alm3916"?) is not used for the same purpose (or perhaps not at all!) in every system "world-wide", you MUST use PDIF.Op for an electromechanical differential relay output contact wired into the input of an IEC 61850 IED,
or because "GGIO3845.SPCSO65" might be different elsewhere, XCBR.Pos is the CB position signal provided to the output contact of the IEC 61850 IED.

The whole point of IEC 61850 semantics (Part 7-x) is that they INHERENTLY tell you as a human being what that piece of information is!
You don't have to find some look up table to know!
It is not different for different vendors or different asset owners!

Interchangeability is still an engineering issue

Now back to the second part of INTERCHANGEABILITY engineering really is all about (definitely not plug and play): physically disconnecting one device and putting another in its place!

This has NOTHING to do with configuring the communications between the devices! Answer for "What is IEC 61850"

Physical replacement of a box has many requirements beyond the configuration of the function that communicate with each other. These non-IEC 61850 requirements include:

• Physical dimensions
• Wire I/O requirements
• Wire I/O terminal mappings to LNs
• # of LEDs and specific allocation (not part of IEC 61850 data model)
• # of  push buttons and allocation
• Menu facilities and language
• proprietary scheme logic configuration and and associated tool configuration file import/export.

So lets not criticise IEC 61850 for not solving interchangeability!

But it does allow us to focus on what the changes are that we need to engineer!!

Page link: https://rhconsult.tiny.us/ykzp5v7k

Extra Notes: