Dispelling the (irrational) fear or uncertainty about using GOOSE and all things IEC 61850

© Copyright Rod Hughes Consulting Pty Ltd
Rod Hughes Consulting
General Web Site
 
Applications
Home
Innovations and
Solutions Home

A bit about
Rod Hughes
 Link to this page...

The URL in the browser address bar is volatile and may be broken at any time.

To obtain a link to this page, click the <<Share>> button top-right of the screen.

  

Note - if the navigation pane on the left of this window is not visible, click the 2-pane icon on the top bar



There are many who have an unjustified and irrational fear of IEC 61850 GOOSE. 


Lets assume that the circuit breaker itself is still wire based trip coil rather than an intelligent device with just a LAN port (they are coming ...).


If you have a relay contact output it is simply "on" or "off". 
You need one contact for every individual status that you want to send to some other location.
Modern IEDs have thousands of individual "bits of information"  .. and I do mean bits as status on/off, operated/not operated, started/not started, healthy/not healthy ...

You then connect wires for that one signal from certain device-specific terminals to some other device-specific terminal.
If you change the relay "10 years later" or want to add an extra circuit connection, ALL that engineering drawing and physical connection and physical testing has to be TOTALLY REDONE .. hence the possibility of "human error" is perpetuated forever.
Note CIGRE TB 246 in its opening chapter says protection only has a life of 20 years c.f. >40 for the switchgear
And you probably never know if that wire has broken, or fallen off.

And one last ridiculous excuse: "Besides.... IEC 61850 has a lot of "weird LAN and jargon stuff" I don't know ...."

WIRES

... a LOT of repeat HUMAN activity,

... a LOT of HUMAN UNDERSTANDING of vendor-specific proprietary information (several thousands of pages of manuals!)

.. a LOT of repeat engineering and operational RISK

.. a LOT of upfront and continuing COST


It makes NO SENSE!

A GOOSE contains the same function on/off status as the relay contact.
If you have to replace or add relays, you just copy/paste that configuration that has been working for the last 1, 5, ..20, 50 years
.. and it does not matter if it is a newer version relay from the same vendor, or a totally different vendor ...
All you need to do is prove the relay is physically "working" and is talking on the LAN is working and test any new functionality you have added.
AND .. you permanently KNOW that EVERY signal is always getting to where it is needed because of the GOOSE Heartbeat.
AND .. if you use HSR or PRP, your GOOSE does not get lost in the substation (My Papers and Contributions https://ideology.atlassian.net/l/c/VCgbBXPs #RH27P) due to of a LAN failure because it travels by two simultaneous different paths.
AND .,.. if you use a "super-resilient" LAN (Architectures - Star, Ring, Duplicated, Redundancy, bumpless PRP, bumpless HSR??? https://ideology.atlassian.net/l/c/mw3b5n8i ), even a failure of the LAN does not impair the operation in any way retaining FULL duplicate operation if one path fails.

Yes IEC 61850 is new technology and jargon to every "newbie" ... none of us were born knowing IEC 61850 and jargon .. or what device 50, 51 or 7F is or how to wire a trip circuit monitor which MANY still get wrong Trip Circuit Monitoring (a.k.a. Supervision)!
... but here I am over 60 years old and still learning about power systems in general, protection operation ... and yes, LAN technology, jargon and how to use IEC 61850 ..
Isn't that what Engineers are supposed to do to find better ways to do things with lower CAPEX and OPEX cost and more reliable outcomes?! 🤦‍♂️

GOOSE

  1. Human activity, and hence potential for human error minimised.  IEC 61850 Applications https://ideology.atlassian.net/l/c/jN4d0skp

  2. HUMAN understanding replaced by common SEMANTICS for ALL vendors

  3. Engineer it once, reuse it forever:
    PTRC.stVal.Op is ALWAYS the status in the GOOSE sent to the XCBR.Pos to cause the trip (wires or LAN to the CB).
    ... even to the extent of having proven you can send GOOSE for <<Bay1_PTRC.stVal.Op>> being sent to <<Bay1_XCBR.Pos>>, just copy that to Bay2, Bay3, ... BayN  by just changing the prefixes!.
    No need for extensive wire point-to-point on every bay.
    When a device fails or you ad dan extra bay, just copy the SAME configuration to the new device.
    Or in your next project at a different substation, possibly with different relays, it is STILL <<Bay1_PTRC.stVal.Op>> being sent to <<Bay1_XCBR.Pos>>!
    .. and regardless of whether the IED that contains the XCBR Logical Node has wired output to the CB Trip coil, or the CB itself is intelligent with "internal XCBR" and a LAN connection.

  4. TransGrid (Australia's largest Transmission Utility) have reported in 2016 savings of 30% on the cost of the SUBSTATION (just as I forecast as the potential from as far back as 2008).
    According to ABB, using IEC 61850 at the outset can reduce the cost of your secondary system refurbishments from 70% of the cost of a new system to just 30%!


As an engineering community we should simply ask how many different ways can I get a signal from relay A to relay B .. and are that they different? or is it much the same process but far better? 
This is what I eluded to in describing it all as a different engineering process when I contributed to some of Chapter 2 of CIGRE Technical Brochure 326:
https://e-cigre.org/publication/326-the-introduction-of-iec-61850-and-its-impact-on-protection-and-automation-within-substations
and my catch phrase"

IEC 61850 is a vendor-agnostic engineering process to configure IEDs to exchange information

Wires

GOOSE

signal-by-signal

Vendor‑agnostic signal-by-signal

(i.e. before you even decide which relays to buy

Vendor-agnostic pre-engineered, pre-tested multi-signal GOOSE and MMS functions created in your Vendor‑agnostic library made by your Vendor‑agnostic engineering tool that has already used in all your previous projects

e.g.  Vendor Independent Engineering Tool - Specification, Configuration

Wade through the vendor-specific manual to find the vendor-specific semantic of the function

look up which the individual bit of information you need to send (the vendor-agnostic Logical Nodes and specific Data Object/Attribute which you quickly learn to recognise forever)

Publish by A


Subscriber in relays B, C, D ....

Wade again through the logic diagrams (default or modified?) to find which contact it is connected to

Add those bits to a GOOSE (existing or new) as a new element in the Dataset

Protection Operate


<<Bay1_PTRC.Op.stVal>>


<<Bay1_XCBR.Pos>

<<Bay1_RBRF>> 

<<Bay1_RREC>>

<<RBDR>>

CB Trip

Start CB Fail

Start Autoreclose

Seq Of Events

Repeat those steps for the other relay
Draw a wire from one contact output to one opto inputConfigure the other relay to listen (subscribe) for that specific GOOSE and element of the GOOSE

Repeat for the next signal

Repeat for the next signal

Install said wire

Load configuration files, connect both IEDs to the LAN

Test said wire

Check relay B is receiving the heartbeat GOOSE

Redraw erroneous wireReconfigure
Install correct wireReload files

Fingers crossed said wire never is broken or falls off (you only know at the next round of full operational testing or an unwanted blackout)

Configure alarm in relay B to tell you if the message ever stops arriving

Repeat for the next signal

Repeat for the next signal

Repeat for the next Bay with different wire numbering

Copy configuration file to the next Bay with different Bay number

Repeat for the next project with different numbering &/or different numbering

Repeat for the next project with different substation name


So why the unjustified irrational fear of IEC 61850 and GOOSE???  .... usually because it is "different" and they have not sought out good advice and training.

Should our engineering career be marked by ignoring problems, or by finding reliable technology improvements.

.. and just to be clear, you can do all your function engineering within the IED with the HUGE semantics and engineering benefits of IEC 61850, but still just have the IED function status issued via IED contacts .. just not so many outputs as you can pack into one or as many different GOOSE as you want.

And I haven't even mentioned

  • Condition Monitoring (cables, lines, towers, switchgear, transformers, motors, wind, solar, storage, hydro, diesel, electric vehicles ....),
  • Asset Management,
  • Automation,
  • Control,
  • SCADA,
  • Microgrids,
  • Smart grid ...

I grew up on induction disc relays, the introduction of the world's first microprocessor overcurrent relay, the emergence of digital relays, then numerical and the intelligent communicating relays ... I would say at the heart I am a traditional protection guy ...
I was 45 years old when I first heard of IEC 61850 when it was "launched" at CIGRE Paris Session 2004 (a very lucky turn of events in my career that I was there).

You may have gathered that I am even more now than then (read my Chapter 2 of CIGRE TB 326 2007) convinced of the benefits .. no, the IMPERATIVE of using IEC 61850 !
https://e-cigre.org/publication/326-the-introduction-of-iec-61850-and-its-impact-on-protection-and-automation-within-substations

If you need help to work where to start, please contact me.
I provide advisory, strategy and specification consulting and training services as well as can put you in touch with other specialists that may be more local if I can't support you (have passport, will travel)



Course contact
Are you in need of specific training:
  • Protection Systems Engineering
  • IEC 61850 Engineering

I provide a range of courses for company-specific in-house training and occasional public invitation courses.  Contact me for details.


 

Contact Me

Email Me

A phone call is nearly always welcome depending on the time of night wherever I am in the world.
Based in Adelaide UTC +9:30 hours e.g.

April-SeptemberNoon UK = 2030 Adelaide
October-March:Noon UK = 2230 Adelaide

  Office + 61 8 7127 6357
  Mobile + 61 419 845 253


Extra Notes:

Disclaimer
No Liability:
Rod Hughes Consulting Pty Ltd accepts no direct nor consequential liability in any manner whatsoever to any party whosoever who may rely on or reference the information contained in these pages.  Information contained in these pages is provided as general reference only without any specific relevance to any particular intended or actual reference to or use of this information. Any person or organisation making reference to or use of this information is at their sole responsibility under their own skill and judgement.

No Waiver, No Licence:
This page is protected by Copyright ©
Beyond referring to the web link of the material and w
hilst the information herein is accessible "via the web", Rod Hughes Consulting Pty Ltd grants no waiver of Copyright nor grants any licence to any extent  to any party in relation to this information for use, copy, storing or redistribution of this material in any form in whole or in part without written consent of Rod Hughes Consulting Pty Ltd.