Netcode-eisen zonnepark op middenspanning (MV): beveiliging, anti-eilandbedrijf, meting & oplevering (end-to-end gids)

Netcode eisen zonnepark middenspanning: waarom gaat het hier zo vaak mis?

Een PV-park (zonnepark of groot dak-PV) dat op middenspanning (MV) wordt aangesloten, is niet alleen een “kabel + station”-project. Je krijgt te maken met netcode- en netbeheerder-eisen die direct bepalen: welke beveiligingen je toepast, welke relais-instellingen zijn toegestaan, hoe je meting en telemetrie inricht, en welke bewijsvoering je moet aanleveren bij oplevering.

Als je dit pas laat in het project dichttimmert, is de kans groot op: afkeur bij netbeheerder-acceptatie, extra engineeringsrondes, ombouw aan station/relays en vertraging in inbedrijfname.

Zacht CTA (inleiding): wil je ontwerp en oplevering in één keer “netbeheerder-proof” krijgen? M2E ondersteunt met MV-engineering, beveiligingscoördinatie, meting/telemetrie en commissioning als integraal traject.

Interne links (gerelateerd)

1) Welke netcode-/netbeheerder-eisen spelen typisch bij MV-PV?

De exacte eisen verschillen per netbeheerder en per aansluitpunt (netconfiguratie, kortsluitvermogen, selectiviteit, spanningsniveau 10/20 kV, etc.). Toch zie je bij MV-PV vrijwel altijd dezelfde “blokken” terugkomen. Het belangrijkste is dat je deze eisen vertaalt naar concrete instellingen op omvormers én op de interfacebeveiliging.

1.1 Anti-eilandbedrijf (Loss of Mains) & afschakeltijden

Een kernpunt bij decentrale opwek is dat de installatie niet onbedoeld een eiland mag blijven voeden als het openbare net wegvalt. In de praktijk wordt anti-eilandbedrijf geborgd met een combinatie van:

Netbewaking (U/f-criteria) en een snelle tripketen (interfacebeveiliging → hoofdschakelaar/vermogensschakelaar).
Actieve detectie door omvormers (fabrikant-specifiek) en/of centrale detectie (afhankelijk van projectafspraak).
Eventueel aanvullende criteria zoals ROCOF en vector jump (zie hieronder).

Vertaling naar instellingen: leg in je beveiligingsfilosofie vast welke functie de LoM-detectie doet (omvormer, interface-relay of beide) en welke uitgang daadwerkelijk de netkoppeling verbreekt (trip van MV-schakelaar / interface breaker). Zorg dat afschakeltijden aantoonbaar binnen de eisen vallen, inclusief relaisvertragingen, uitgangscontacten, tripspoel en mechanische schakeltijd.

1.2 ROCOF en vector jump: nuttig maar ook risicovol

ROCOF (Rate Of Change Of Frequency) en vector jump worden vaak genoemd in PV-projecten omdat ze eilandbedrijf sneller kunnen detecteren dan alleen U/f-bewaking. Tegelijk zijn ze gevoelig voor “false trips” bij netgebeurtenissen (schakelen, foutopruiming, grote vermogenssprongen).

Praktische aanpak:

Stem met netbeheerder af of ROCOF/vector jump verplicht, toegestaan of juist afgeraden is op jouw aansluitpunt.
Als je ze toepast: onderbouw de gekozen drempels/vertragingen en testbaarheid (SAT).
Voorkom dat ROCOF/vector jump “boven” selectiviteit gaat hangen (zodat je bij normale netverstoringen niet onnodig uitvalt).

1.3 Spannings- en frequentiebanden (U/f) + afschakelkarakteristieken

MV-PV moet binnen afgesproken spannings- en frequentiebanden blijven en bij overschrijding op een gedefinieerde manier afschakelen of vermogen reduceren (afhankelijk van afspraken). Dit vertaalt zich naar:

U<, U> (en vaak ook U<< / U>>), met bijbehorende tijden.
f<, f> (en soms f<< / f>>), met bijbehorende tijden.
Afstemming tussen omvormer-instellingen en interfacebeveiliging (wie tript wanneer?).

Vertaling naar instellingen: maak één “master settings”-tabel waarin je per functie vastlegt: meetpunt (VT/CT), drempel, tijd, resetgedrag, en welke schakelaar wordt aangestuurd. Voeg ook toe: wie eigenaar is van de instelling (EPC, omvormerleverancier, stationbouwer) en hoe wijzigingen worden beheerd (versiebeheer).

1.4 Blindvermogenregeling: Q(U) / cos φ / spanningsondersteuning

Netbeheerders vragen bij MV-opwek vaak om blindvermogenfunctionaliteit: bijvoorbeeld cos φ-regeling of Q(U)-karakteristiek voor spanningsbeheersing. Dit raakt direct je ontwerp omdat je moet borgen:

waar de regeling “zit” (per omvormer, plant controller, centrale regelaar);
welke meetwaarde leidend is (MV-bus, PCC/overdrachtspunt, LV-zijde);
welke grenzen gelden (Q-limieten, P-prioriteit vs Q-prioriteit).

Vertaling naar instellingen: definieer de Q(U)-curve of cos φ setpoints in overleg met netbeheerder én netstudie-resultaten. Leg in het opleverdossier vast hoe gemeten wordt dat de regeling doet wat is afgesproken (acceptatietest met meetrapport).

1.5 Foutdoorgang / LVRT (waar van toepassing)

Afhankelijk van netcode-afspraken en aansluitcategorie kan gevraagd worden om fault ride-through (bijv. LVRT) en gecontroleerd gedrag bij spanningsdips. Dit is bij inverters technisch mogelijk, maar vereist heldere afstemming: wanneer moet je blijven hangen, wanneer juist afschakelen, en hoe voorkom je dat beveiligingen elkaar “tegenwerken”.

Vertaling naar instellingen: borg dat LVRT-gedrag van de omvormers consistent is met interfacebeveiliging (die anders alsnog tript). Testbaar maken is essentieel: leg meetmethodiek en acceptatiecriteria vast in het SAT-plan.

2) Beveiligingsarchitectuur: interfacebeveiliging vs veldbeveiligingen

Voor MV-PV draait beveiliging om twee doelen tegelijk: netveiligheid (eisen netbeheerder) én installatiebescherming (eigen assets). De valkuil is dat men óf te veel vertrouwt op omvormerbeveiligingen, óf juist een “klassiek” MV-beveiligingsconcept kopieert zonder rekening te houden met invertergedrag.

2.1 Typische opbouw

Interfacebeveiliging (PCC/overdrachtspunt): functies die de netbeheerder wil zien en waarmee de totale installatie kan worden losgekoppeld.
Veldbeveiligingen: beveiliging per afgaand veld (trafo-velden, kabelvelden, ring, railkoppeling) voor selectieve foutopruiming binnen je eigen MV-installatie.
Omvormer-/stringniveau: interne omvormerbeveiliging en plant control (beperkte bijdrage aan netselectiviteit).

2.2 Relaiskeuze en functies (praktisch)

Voor MV-PV zie je in de praktijk vaak een numeriek relais met combinaties van:

Overstroom (I>, I>>) en aardsluiting (Ig/Io, afhankelijk van aardingssysteem en netafspraken).
Spanning/frequentie (U/f) en eventueel ROCOF/vector jump voor LoM.
Beveiliging op richting (directional) waar terugvoeding en netconfiguratie dit vereisen.
Logica/interlocking, tripketenbewaking en storingsregistratie (SOE/oscillografie).

Belangrijk: maak de grens helder tussen netcode-gedrag (meestal interface) en interne installatiebeveiliging (velden). Meng dit niet zonder reden: het maakt afstemming en testen onnodig complex.

2.3 Selectiviteit met omvormers: de grootste valkuil

Inverters leveren vaak een beperkte en kortdurende kortsluitbijdrage vergeleken met roterende generatoren. Daardoor kunnen klassieke overstroominstellingen “blind” worden, vooral bij fouten verderop in het net of bij hoge impedanties.

Veelvoorkomende issues:

Niet aanspreken van overstroombeveiliging omdat foutstroom te laag/te kort is.
Ongewenste trip van interfacebeveiliging (te gevoelig) waardoor interne fouten niet selectief worden afgehandeld.
Geen duidelijke richting (power flow wisselt), waardoor directional beveiligingen verkeerd geconfigureerd worden.

Mitigaties (conceptueel):

Laat je netstudie/kortsluitstudie expliciet modelleren met invertergedrag (min/max bijdrage, duur, control-limieten).
Overweeg waar nodig spanningsafhankelijke functies (U-criteria) in combinatie met stroomcriteria in plaats van alleen “I>”.
Gebruik storingsregistraties (oscillografie) en SOE om bij commissioning snel te kunnen aantonen wat er gebeurt.

Tussentijdse CTA (midden): twijfel je of je beveiligingsconcept selectief blijft met beperkte inverter-foutstroom? M2E kan een beveiligingsfilosofie + instelrapport opstellen en afstemmen met netbeheerder, inclusief testplan voor commissioning.

3) Meting & telemetry: CT/VT, kWh/kvArh, SCADA en tijd

Bij MV-opwek is meting niet alleen voor facturatie; het is ook bewijsvoering (afname/teruglevering, Q/P gedrag, events) en vaak een harde netbeheerder-eis voor bedrijfsvoering.

3.1 Meettransformatoren (CT/VT): keuze en consequenties

CT/VT ratio’s moeten passen bij maximaal vermogen én meetnauwkeurigheid bij deellast.
Klasse (meting vs beveiliging) en burden (VA) moeten kloppen met bekabeling, meters en relais.
Let op het verschil tussen meter-CT/VT (facturatie) en beveiligings-CT/VT (relays). Combineer alleen als het aantoonbaar mag en technisch klopt.

3.2 Energiemeting: kWh én kvArh (blindenergie)

Afhankelijk van contract en netbeheerderregime kan registratie van zowel actieve energie (kWh) als reactieve energie (kvArh) relevant zijn, zeker als Q(U)/cos φ verplicht is. Zorg dat je meetketen dit ondersteunt en dat telwerken en richting (import/export) eenduidig zijn.

3.3 Telemetrie/SCADA-koppelingen: wat wordt meestal gevraagd?

Veel MV-opwekprojecten moeten data aanleveren aan netbeheerder of meetverantwoordelijke. Denk aan:

actueel vermogen (P), blindvermogen (Q), spanning (U), stroom (I), frequentie (f);
statussen: hoofdschakelaar open/dicht, trip/alarm, beschikbaarheid;
event- en storingsmeldingen (SOE);
optioneel: setpoint-ontvangst (bijv. Q of cos φ) afhankelijk van afspraken.

Tip: maak vroeg een signaallijst (IO-list) en leg vast via welke interface (protocol/RTU/gateway) dit gaat lopen. Dit voorkomt dat je in de realisatiefase nog “even” een gateway of time sync moet toevoegen.

3.4 Tijdsynchronisatie & registraties (SOE/oscillografie)

Bij acceptatie en bij incidenten wil de netbeheerder (en jijzelf) gebeurtenissen kunnen reconstrueren. Dan is tijdssynchronisatie essentieel voor:

Sequence of Events (SOE) met milliseconde-resolutie (afhankelijk van systeem);
oscillografie uit beveiligingsrelais;
correlatie met omvormerlogs en plant controller.

Leg vast: tijdbron (bijv. NTP/PTP/GPS), architectuur en verantwoordelijkheden (OT/IT), én test dit in SAT.

4) Oplevering & bewijsvoering: FAT/SAT, testplan en opleverdossier

De snelste route naar energielevering is een oplevering die controleerbaar en traceerbaar is. Netbeheerders willen niet alleen “het werkt”, maar ook: wat is gebouwd, wat is ingesteld, en hoe is het getest?

4.1 FAT/SAT: wat test je waar?

FAT (Factory Acceptance Test): paneelbouw, relaisconfig, I/O, logica, simulaties, documentcontrole.
SAT (Site Acceptance Test): primaire injectie waar relevant, ketentesten (trip), interlocks, communicatie/telemetrie, synchronisatie, functionele netcode-tests (voor zover mogelijk).

4.2 PV-specifiek beproevingsplan (functioneel)

Naast “klassieke” MV-tests hoort er bij MV-PV een PV/omvormer-specifieke set testen bij. Denk aan:

Tripketen test: van meetwaarde/trigger (U/f/LoM) tot werkelijk openen van MV-schakelaar, incl. terugmelding.
Interlocking: mechanisch/elektrisch (schakelstanden, aardingsschakelaar, sleutelsystemen waar toegepast).
Anti-eilandbedrijf teststrategie: praktisch uitvoerbaar, met heldere acceptatiecriteria.
Q(U)/cos φ gedrag: setpoint/curve demonstratie met meetrapport (P/Q/U aan PCC).
Alarmen & logging: SOE, omvormerlogs, gateway/SCADA, tijdsync.

4.3 Opleverdossier (‘as-built’) dat netbeheerders doorgaans vragen

Concrete deliverables die in MV-PV projecten vaak het verschil maken:

Single Line Diagram (as-built) en kabellijsten.
Beveiligingsfilosofie + instelrapport (alle drempels/tijden/logicaversies).
Testplannen en testrapporten (FAT/SAT), incl. meetwaarden en bewijs van tripketen.
Meetketen-documentatie: CT/VT gegevens, meterconfig, telwerken, ijk-/kalibratie waar van toepassing.
Communicatie/telemetrie: signaallijst, protocolbeschrijving, netwerkdiagram, time sync opzet.
Aarding & veiligheid: aardingsontwerp, meetrapporten en oplevercriteria (stap/aanraak waar van toepassing).

5) Praktische checklist per fase (concept → ontwerp → netstudie → realisatie → inbedrijfname)

Fase 1 — Concept / haalbaarheid

Bepaal PCC en eigendomsgrens (netbeheerder vs klant) en kies het juiste stationconcept (inkoopstation/klantstation).
Inventariseer netbeheerder-eisen (TAV + project-specifieke aanvullingen) en leg ze vast als requirements.
Maak een eerste keuze: plant controller ja/nee, Q(U)/cos φ strategie, telemetrie-scope.

Fase 2 — Ontwerp (basic/detailed engineering)

Werk een beveiligingsarchitectuur uit (interface vs velden) + selectiviteitsfilosofie.
Definieer CT/VT-plan (ratio, klasse, burden, scheiding meting/beveiliging).
Maak een concept insteltabel (U/f/LoM/Q-regeling) en zet versiebeheer op.
Maak telemetrie I/O-list + tijdsync-ontwerp (NTP/PTP/GPS) en koppel dit aan SAT.

Fase 3 — Netstudie(s) en afstemming

Laat kortsluit-/loadflowstudies inverter-realistich modelleren (min/max foutbijdrage en duur).
Verifieer selectiviteit: interne fouten vs netfouten; voorkom dat interface alles “wegtript”.
Leg definitieve setpoints vast voor Q(U)/cos φ en eventuele LVRT-voorwaarden.

Fase 4 — Realisatie / bouw

Voer FAT uit op relaispanelen (logica, I/O, signalering, registraties).
Controleer CT/VT aansluitingen (polariteit, aarding secundair, kortsluitbruggen CT).
Valideer dat as-built tekeningen realtime worden bijgewerkt (geen “achteraf”-dossier).

Fase 5 — Inbedrijfname / oplevering

Voer SAT uit met meetrapporten (tripketen, interlocking, telemetrie, time sync).
Test Q(U)/cos φ gedrag aan PCC met reproduceerbare scenario’s.
Lever een compleet opleverdossier op (instellingen, testresultaten, as-built, logs).
Plan een gezamenlijke acceptatie met netbeheerder inclusief “bewijsstukkenlijst”.

Samenvatting

Netcode eisen zonnepark middenspanning komen in de praktijk neer op één ding: vertaal regels naar aantoonbare engineering-keuzes. Dat betekent een helder onderscheid tussen interfacebeveiliging en veldbeveiligingen, een selectief concept dat rekening houdt met beperkte inverter-foutstroom, een meet- en telemetrie-architectuur met goede tijdsynchronisatie, en een opleverdossier met testbare bewijsvoering (FAT/SAT).

Harde CTA (conclusie): wil je vertraging en afkeur bij oplevering voorkomen? Neem contact op voor een MV-PV netcode & opleveringsscan of vraag direct een offerte aan voor engineering, instelrapporten, testen en commissioning.

FAQ (featured snippets)

Wat zijn de belangrijkste netcode eisen voor een zonnepark op middenspanning?

Meestal gaat het om anti-eilandbedrijf (LoM), spannings- en frequentiebewaking (U/f), eisen rond blindvermogen (Q(U) of cos φ), telemetrie/registratie en een aantoonbaar getest beveiligings- en tripconcept. Projectspecifiek kunnen ROCOF/vector jump en fault ride-through (LVRT) meespelen.

Waar plaats je de interfacebeveiliging bij MV-PV?

In de regel bij het overdrachtspunt/PCC (in of nabij het inkoopstation), zodat de totale PV-installatie via één keten kan worden losgekoppeld conform netbeheerder-eisen. De exacte invulling hangt af van eigendomsgrens en TAV-afspraken.

Waarom is selectiviteit lastig bij omvormerparken op middenspanning?

Omdat inverters vaak een beperkte en kortdurende kortsluitstroom leveren. Daardoor werken klassieke overstroombeveiligingen niet altijd zoals bij transformatoren met “sterke” foutbronnen. Dit moet je ondervangen met een passend beveiligingsconcept en realistische netstudies.

Welke meetgegevens en telemetrie worden meestal gevraagd door de netbeheerder?

Vaak: P, Q, U, I, f, energietelwerken (kWh/kvArh), status van hoofdschakelaar, storings-/tripmeldingen en betrouwbare tijdregistratie (SOE). De exacte punten en protocollen verschillen per netbeheerder en project.

Welke documenten horen in een opleverdossier voor MV-zonnepark aansluiting?

Minimaal as-built SLD/tekeningen, kabellijsten, beveiligingsfilosofie en instelrapport, FAT/SAT testrapporten (incl. tripketen), meetketendocumentatie (CT/VT/meter), telemetrie/signaallijst en tijdsync-opzet, plus relevante aarding- en veiligheidsrapporten.