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.
But it is fair to ask : "what is IEC 61850?" | Info |
|---|
The Standard is | Tip |
|---|
| ... 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" | | Tip |
|---|
But |
| Info |
|---|
... 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.
|