IEC 61850 en GOOSE-berichten — snelle peer-to-peer beveiligingscommunicatie tussen relais

De gids over lijndifferentieelbeveiliging (87L) via een glasvezelkanaal en de gids over teleprotectie (85) — permissive/blocking-schema's via een afstandsbeveiliging behandelen beide communicatie tussen relais op verschillende stations. Dit artikel behandelt communicatie binnen één station: hoe moderne numerieke relais (IED's, Intelligent Electronic Devices) onderling en met het stationsautomatiseringssysteem communiceren via IEC 61850, en in het bijzonder via het GOOSE-protocol.

Drie communicatiediensten binnen IEC 61850

IEC 61850 ("Communication networks and systems for power utility automation") definieert een gestandaardiseerd datamodel voor beveiligings- en schakelfuncties (elke functie is een "logical node", bijvoorbeeld XCBR voor een vermogensschakelaar of PTOC voor een tijdsafhankelijke overstroombeveiliging) en drie communicatiediensten die op ditzelfde datamodel zijn gebaseerd:

• MMS (client-server): het reguliere rapportage- en besturingsverkeer tussen een IED en het stationsautomatiserings- systeem of SCADA — vergelijkbaar met traditionele RTU-communicatie, maar met een gestandaardiseerd objectmodel in plaats van fabrikantspecifieke registeradressen.
• GOOSE (Generic Object Oriented Substation Event): snelle, peer-to-peer-communicatie rechtstreeks tussen IED's, bedoeld voor tijdkritische gebeurtenissen (trip-commando's, schakelstand, vergrendelsignalen).
• Sampled Values (SV, IEC 61850-9-2): continu gestreamde, gedigitaliseerde stroom- en spanningswaarden vanaf een merging unit, als digitaal alternatief voor conventionele koperbedrading vanaf stroom- en spanningstransformatoren (zie ook de gids over CT-beveiligingsklasse en knikpuntspanning voor de conventionele, analoge tegenhanger van dat signaal).

GOOSE: rechtstreeks over Ethernet, zonder routering

Een GOOSE-bericht wordt rechtstreeks op laag 2 van het OSI-model over het Ethernet verstuurd (Ethertype 0x88B8), zonder IP-adressering, als een multicast-bericht dat door alle IED's in hetzelfde Ethernet-segment (of dezelfde VLAN) kan worden ontvangen. Dat maakt GOOSE ongerouteerd — het blijft binnen het lokale stations-Ethernet — maar wel zeer snel: een statusverandering (bijvoorbeeld een trip-commando of een schakelstandwijziging) wordt in de orde van enkele milliseconden op het netwerk gezet, aanzienlijk sneller dan via het client-server-verkeer van MMS mogelijk zou zijn.

Het herhaalschema: betrouwbaarheid zonder bevestiging

GOOSE kent, in tegenstelling tot MMS, geen bevestiging (acknowledgement) op applicatieniveau — de verzendende IED weet niet zeker of een ontvanger het bericht daadwerkelijk heeft verwerkt. In plaats daarvan compenseert IEC 61850-8-1 dit met een herhaalschema: bij een statuswijziging wordt het bericht eerst met een zeer korte tussenpoos meermaals herhaald (bijvoorbeeld elke paar milliseconden), waarna de tussenpoos geleidelijk oploopt tot een stabiel, "rustig"-interval van typisch enkele seconden zolang er geen nieuwe wijziging optreedt. Dit stabiele herhaalbericht functioneert als een heartbeat: elke GOOSE-boodschap bevat een "Time Allowed to Live" (hoelang de ontvanger het laatst ontvangen bericht als geldig mag beschouwen), en als er geen nieuw bericht binnenkomt vóór die vervaltijd verstrijkt, weet de ontvangende IED dat de communicatie zelf is weggevallen — ook zonder dat er ooit een expliciete foutmelding is verzonden.

Let op: dit heartbeat-mechanisme is de reden waarom een GOOSE-verbinding geen aparte "communicatie-OK"-controle nodig heeft zoals een klassiek hardwarecontact — het ontbreken van het periodieke rustbericht zelf ís de storingsmelding.

Waarom dit koperbedrading vervangt

Vóór IEC 61850 werden functies zoals blokkeringssignalen tussen velden, standmeldingen van schakelaars naar aangrenzende IED's, of intertrip-commando's bij een railrangeerbeveiliging, allemaal via fysieke koperbedrading tussen relais gerealiseerd — met de bijbehorende bekabelings-, test- en onderhoudslast. GOOSE vervangt veel van die harde bedrading door een softwarematig gedefinieerde peer-to-peer-boodschap over hetzelfde Ethernet-netwerk waarop ook MMS- en SV-verkeer loopt, wat de bekabeling in een station aanzienlijk kan verminderen, maar de verantwoordelijkheid voor correcte werking verschuift van fysieke bedrading naar het Ethernet-netwerkontwerp zelf.

Netwerkdiscipline: de keerzijde van minder koper

Omdat GOOSE ongerouteerd, niet-bevestigd en tijdkritisch is, stelt een betrouwbare GOOSE-implementatie strenge eisen aan het onderliggende Ethernet-netwerk:

• Prioritering: GOOSE-verkeer wordt doorgaans met een hoge IEEE 802.1Q-prioriteitstag gemarkeerd, zodat netwerkswitches het voorrang geven boven minder tijdkritisch verkeer op hetzelfde netwerk.
• Netwerkredundantie: omdat een GOOSE-bericht op applicatieniveau niet wordt bevestigd of opnieuw aangevraagd, wordt netwerk- redundantie doorgaans op laag 2 zelf opgelost — bijvoorbeeld via PRP (Parallel Redundancy Protocol) of HSR (High-availability Seamless Redundancy) uit IEC 62439-3, die een bericht gelijktijdig over twee onafhankelijke paden versturen zodat uitval van één pad geen enkel bericht kost.
• Interoperabiliteit via SCL-bestanden: de configuratie van welke IED welke GOOSE-berichten van welke andere IED's afneemt (en welk logisch signaal daarachter zit) wordt vastgelegd in gestandaardiseerde SCL-bestanden (.icd, .cid, .scd) — bedoeld om IED's van verschillende fabrikanten binnen hetzelfde station interoperabel te configureren.

Let op: IEC 61850 vervangt niet automatisch elke vorm van hardwarebedrading — veel installaties combineren GOOSE voor tijdkritische logica met conventionele bedrading voor kritieke functies waar een extra, fysiek onafhankelijk pad gewenst is, of tijdens een gefaseerde migratie waarbij oudere IED's nog geen IEC 61850 ondersteunen.

Praktische relevantie

Bij het ontwerpen, uitbreiden of onderhouden van een station met IEC 61850-gebaseerde IED's is het van belang te onderkennen dat de betrouwbaarheid van GOOSE-gebaseerde beveiligingsfuncties net zo sterk afhangt van het Ethernet-netwerkontwerp (prioritering, redundantie, VLAN-scheiding tussen procesbus en stationsbus) als van de IED's zelf — een netwerkwijziging die op het eerste gezicht alleen IT-verkeer lijkt te raken, kan onbedoeld ook tijdkritische GOOSE-signalering beïnvloeden.

Veelgemaakte fouten

1. GOOSE-verkeer zonder prioriteringstagging over hetzelfde netwerk sturen als niet-tijdkritisch IT-verkeer — bij netwerkcongestie kan dit de aankomsttijd van een trip-signaal vertragen.
2. Aannemen dat het uitblijven van een expliciete foutmelding betekent dat de GOOSE-communicatie werkt — zonder monitoring van het heartbeat-mechanisme (Time Allowed to Live) kan een weggevallen verbinding onopgemerkt blijven.
3. SCL-configuratiebestanden van verschillende IED's niet consistent bijwerken bij een wijziging — een GOOSE-abonnement dat naar een verouderde dataset-definitie verwijst, kan tot een stille configuratiemismatch leiden.
4. Netwerkredundantie behandelen als een IT-aangelegenheid los van de beveiligingsfunctie, terwijl PRP/HSR-ontwerp voor GOOSE-verkeer net zo'n kritiek onderdeel van het beveiligingsontwerp is als de relaisinstellingen zelf.

Gerelateerd

• Lijndifferentieelbeveiliging (87L) via een glasvezelkanaal
• Teleprotectie (85) — permissive/blocking-schema's bij afstandsbeveiliging
• Stroomtransformator beveiligingsklasse (5P/10P) en knikpuntspanning
• Glasvezeltypen — single-mode versus multi-mode (OS2, OM1-OM5)