One of my biggest objections is against anyone referring to "IEC 61850 protocol"

IEC 61850 Protocol Does Not Exist!!!
The title is "Communication networks and systems .."
It does not say "protocol"!

IEC 61850 is not a mere protocol.

External commentaries - Click here to expand...

PAC World magazine http://www.pacw.org/issue/autumn_2009_issue/iec_61850_update/iec_61850_status_update.html
“SCADA protocols like IEC 60870-5-101/-104 and the derivate DNP3 support the standardized exchange of data like a double point or an analog value with quality information and time stamp. IEC 61850, while supporting that as well, does much more.”
“SCADA Systems Benefit from IEC 61850” http://blog.iec61850.com/2011/02/scada-systems-benefit-from-iec-61850.html
"IEC 61850 allows protection and control functionality in the substation to be modelled into different logical nodes, and grouped under different logical devices. This saves considerable time in implementing new protection devices because you do not have to map device points to SCADA points as in the case of DNP protocol."
“IEC 61850 versus DNP3” http://blog.iec61850.com/2010/11/cost-for-iec-61850-versus-dnp3-or-iec.html
“What else do we want to compare? The other features are defined in IEC 61850 only. Comparison means: IEC 61850 HAS them - the others don't HAVE them. That's it”

But it is fair to ask : "what is IEC 61850?"

IEC 61850 is ...

... a vendor-agnostic system-engineering process (from specification to implementation to operation and into maintenance) to configure IEDs to be able to communicate between them to monitor, protect, control and manage infrastructure associated with electrical networks.

or more concisely ... "An engineering process to configure IEDs to communicate"

... But

we should also consider "Why bother?" .. we have been engineering substation secondary systems for "100 years" and SCADA for >40 years .. surely we know what we are doing and know how to do it well.
As a protocol, we have been happy with ModBus or DNP3.0 or IEC 60870-5-1xx ....
But those "mere protocols "Do No Protection" (my favourite humorous quip about DNP (Distributed Network Protocol)

And we have to consider the EXPLOSION of "Internet of Things" i.e. pieces of information about the power system that needs to be communicated from one device to other devices and systems.
So engineering ...
Human activity ...
Human interpretations of information
Vendor specific (human) definitions and implementations
Human schemes
Human drawings
Human connection of wires
Humans writing test procedures
Humans following those test procedures ...

.... then do the same thing from scratch over and over and over .. with different potential errors each time, with different vendors and different versions in te next Bay or Substation
.... or perhaps needing to replace an old or unsuitable device to implement some new applications.

HUMAN ERROR potential all over the place ...

How much human activity? .... IEC 61850 Applications

So what if we could engineer something ONCE
... and create a TRUE scheme configuration (not just a drawing template) that is "universal" and repeatable by copy/paste (without renumbering wires) across all vendors and for all future Bays, and Substations?
We could focus on engineering the new functions without having to re-engineer the wire-connections to suit the new device .. or even test those functions again!

Eliminate Human Error using proven configurations that are already in service copied to th next Bay or Substation ... with only the name of the Bay that has to change!
Interoperability - not Interchangeability "What does Interoperability mean in practice - what is IEC 61850 trying to achieve?"

Now ... THAT is "Why Bother!

Please note the sequencing of the Parts of the Standard as an indication of the way in which the Standard should be applied ... - many fall into the trap of going straight to Part 8 or 9 where the different real time messages (MMS / GOOSE / Sampled Values) are defined, but our objective should not be simply to boast "we have a GOOSE in the substation".

Part 3: Physical requirements of the IED for environmental withstand including temperature etc., EMC, auxiliary supply ranges etc. (N.B.: a device can comply to just IEC 61850-3 without having any IEC 61850 functionality)

Part 4: a project management methodology

Part 5: the definition of the system communication requirements in the substation

Part 6: the prescription of the engineering environment for configuring of functions (which is ultimately supplied in IEDs) to communicate with other functions interoperably

Part 7: a set of defined object structures with semantics of what could need to be communicated

Part 8 and Part 9 There are two principal types of communication processes for the real time communication between the functions (supplied in IEDs)
       Client-Server communications mechanisms Part 8-1:
                       SCADA master-slave command/polling
                       server event triggered reporting to the client
         Publisher-Subscriber communication mechanism
                        Part 8-1 repetitive retransmission of the status of a function with fast repetition of that changed status when an event occurs (GOOSE)
                        Part 9-2 (and independent IEEE Guideline 9-2LE) for continuous transmission of instantaneous Sampled Values
         Across all of these above (IEC 61850 Part 8-1 and 9-2) is the mapping onto TCP/IP Ethernet networks to actually get the message from device A to device B, C, D.... This is where the confusion of a protocol stems from.

Just "limiting" the definition of IEC 61850 to some small part of Part 8-1 and 9-2 as being a "protocol" clearly misses the whole point of IEC 61850 with the inevitable poor experiences.

Ignoring Parts 3, 4, 5, 6 and 7 in projects and specifications is quite possibly (probably) going to lead you into the same sorts of problems that have been reported by ENTSO-E as 41 transmission utilities in Europe following their first 8 years of using IEC 61850.

Browser not supported