Achieving interoperability

Interoperability is one of the key objectives of IEC 61850.

So why is there so much anecdotal complaint that it doesn't work?

I don't believe it is a problem of the Standard itself, but rather how we choose to use it.  This is the conundrum of a Standard that is like a box of Lego that has to suit every possible type of application, rather than buying a specific selection of Lego to build a "pirate ship" or a "space ship".

Firstly the Standard sets out to define the aspects that you need to know that help you, the user, to select and configure devices that might suit your application.  This is evident from the very start of the Standard in IEC 61850-1:
"The purpose of the Standard is neither to standardise (nor limit in any way) the functions involved in operation of the substation nor their allocation in the Substation Automation System"

If you have any perceptions that IEC 61850 or IEDs compliant to IEC 61850 will automatically suit what you want to do, you are fundamentally wrong! 
It is not "automatic interoperability" - it is about the information you need to know that allows you to select the devices that will be interoperable in your application.

So to the issue of achieving interoperability.  It should be straight forward.
After all, when we construct a Dataset with a single bit as a 0 or a 1 representing say PTOC.Op.stVal of the Publisher - well, that is pretty hard to not be interoperable with anything else as a Subscriber that can tell the difference between a 0 and a 1 !

The complexities come in with the Optional Data Objects/Attributes that may or may not be present in the particular chosen Publisher IED.
If your scheme requires a certain DO/DA but that is not part of the vendors implementation - well, it is just not going to work - obvious really!

So this is where we MUST understand what we are buying.
To achieve interoperability in your application, the Standard anticipates this with the requirement for the MICS document (Model Implementation Conformance Statement) to be provided by the vendor (it is not a confidential document despite some vendors reluctance to provide it) - this is basically a human readable version of the ICD file that tells you what LN/DO/DA are implemented. 

You should also look at the PICS (Protocol Implementation Conformance Statement) which tells you whether it supports GOOSE, Sampled Values, MMS commands and even down to things like Select Before Operate or File Transfer etc - if it can't send or receive the required command (e.g. Select Before Operate with Enhanced Security) or information (e.g. providing Buffered Reporting) because it is not a supported part of its protocol, then again it just won't work
And not to forget the PiXIT and TICS documents.

So that leads to my latest phrase:
"You have no right to expect to get what you do not specify"
You might get lucky if you don't specify it, but if you actually need the a phase operation of the PTOC in a dataset, whilst PTOC implementations have Mandatory inclusion of PTOC.Op.general, you had better make sure that the IED has a data model including PTOC.Op.phsA - i.e you have to drill down into IEC 61850-7-4 and then into -7-3 to find that .phsA is Optional under the ACT Common Data Class so some vendors might not provide it and they still conform to the Standard.
i.e. you have to know your functional requirement in detail and then specify it.

But if for some reason you don't specify what you need and you don't get it - please don't blame the Standard for your poor choice, nor blame it for having too many options!

Hence the proposed ISD file is a great enhancement to the MICS - this is basically a file that once you've decided what data model you need, apart from reading all the MICS, you can issue the ISD which is your specification view of the ideal ICD you would like from the vendors.  You then have the possibility of using tools to evaluate the compatibility of the IED to your requirement.

Remember IEC 61850-6 identifies three types of tools you should be using - the System Specification Tool (SST), the System Configuration Tool (SCT) and the various vendor-specific IED Configuration Tools (ICT).
The various ICT have naturally been in common use since the release of the Standard in 2004 - the vendors need to make sure you can make their boxes work so you buy their boxes.

But have you ever tried to build a house using just one tool?  It is really hard and severely constrains the type of house you build!  This is arguably at least part of the reason ENTSO-E came out with their original  Statement 2012-04-13 that has led to their round of work.

Hence advanced vendor-independent engineering tools such as Helinks provides the ability as an SST and SCT (one of the few available) which can also be used to derive an ISD file as part of your project or even generic substation specification.

(The ENTSO-E tool is presumably doing much the same thing as Helinks by also wrapping up a library of ENTSO-E functions as a BAP suited to the ENTSO-E members standardised functions.
I guess it remains to be seen if the ENTSO-E tool is universally applicable to other utilities/asset owners/system integrators required functions.)

Helinks provides the ability to do system specifications totally independently of knowing which IEDs are going to be used.  This also includes the ability to produce your own function libraries.

Then when you have completed your System Configuration stage to produce the vendor-independent SCD file, you can then decide which vendor IEDs are going to be used and with one click, it "adjusts" the mapping of the signals according to how that vendor has implemented GOOSE and GGIO - even identifying for you where there is any mismatch

But back to the problem at had - interoperability.

Another aspect that has caused us all so much hassle for interoperability is the famous GGIO.
Due to an unfortunate grammatical error in the sequence of two words in IEC 61850-7-4  Ed1, GGIO became prevalent in many IEDs that all virtual signals egressing or ingressing the IED via the comms port were mapped via a GGIO - the words of the Standard were "device processes".  This was interpreted as anything that the device does has to be mapped via a GGIO, however this destroys all benefits of a common semantic.

Ed 2 fixed the definition of GGIO to reverse the order of the words as "process devices" - i.e. it is essentially now "illegal" to map a LN DO/DA via a GGIO since the LNs are clearly not physical world things (process devices) that have no existing semantic LN definition in the S, T, X, Y, or Z groups.
Note Ed 2 goes even more specifically that GGIO cannot be used to map any other functions that are not "real world things":
"This node shall be used only to model in a generic way process devices that are not predefined by the groups S, T, X, Y, or Z."
i.e. LNs only exist in the virtual world so mapping information from one LN to/from a GGIO is totally incorrect/"illegal". 
i.e. you can use GGIO correctly to represent the position of a door being open or closed, or the control to turn a light on or off since there is no LN for a door or a light
Refer this discussion Say No to GGIO

Extra Notes: