SCADA middenspanningsstation: telemetrie & remote switching – eisen netbeheerders, cybersecurity en ontwerpkeuzes

SCADA in een middenspanningsstation is in de praktijk vaak hét verschil tussen “alleen aansluiten” en “echt kunnen sturen en beheren”. Zeker met netcongestie, curtailment-afspraken, flexcontracten en steeds meer PV/EV/BESS achter de aansluiting. Een goed ontwerp voorkomt dat je later (bij acceptatie of inbedrijfname) alsnog moet ombouwen aan relais, signaallijsten, communicatie of cybersecurity.

Wil je dit direct goed neerzetten (inclusief signaallijst, RTU-keuze, FAT/SAT en netbeheerder-afstemming)? M2E kan het automatiseringsdeel integraal meenemen binnen het ontwerp- en oplevertraject van jouw MS-station, aansluitend op de totale stationengineering en commissioning. Bekijk bijvoorbeeld onze engineering- en aansluittrajectdiensten of laat je IV/bedrijfsvoering borgen via IV-schap.

Focus zoekwoord: SCADA middenspanningsstation

Waarom SCADA/telemetrie & remote switching nu “must-have” worden

Waar SCADA vroeger vooral bij grotere industriële netten hoorde, is het nu ook bij klantstations (PV, laadpleinen, BESS, datacenters, tuinbouw) relevant door:

Netcongestie en curtailment: je moet productie/verbruik kunnen begrenzen en aantoonbaar maken wat je doet.
Bedrijfszekerheid: sneller storingen lokaliseren, trends zien en onderhoud plannen.
Veilig schakelen op afstand: alleen als techniek, processen en verantwoordelijkheden kloppen.
Compliance: netbeheerder-eisen, meetketen, opleverdossier, logging en beheerorganisatie.

Relevante contextartikelen binnen onze kennisbank (voor het totaalplaatje): inbedrijfname van een compactstation, netcode-eisen bij PV en netcongestiestrategieën. ([m2e.nl](https://m2e.nl/kennisbank/stappenplan-inbedrijfname-compactstation?utm_source=openai))

1) Welke SCADA/telemetrie-functionaliteiten je in de praktijk nodig hebt

De “juiste” set functies is use-case afhankelijk. In bijna alle projecten zien we deze bouwblokken terug:

1.1 Meten & registreren (realtime + trends)

Elektrische grootheden: U/I, P/Q/S, cos φ, f, kWh/kVArh (afhankelijk van meetconcept), fase-onbalans.
PQ-meting / power quality: harmonischen (THD), dips/sags, flicker (waar relevant of contractueel vereist).
Trenddata: 1s/10s/1min resolutie (bewust kiezen), retentie (bijv. 1–3 jaar) en export.

1.2 Alarmeren & storingsdiagnose

Schakelstatussen: open/dicht, veer gespannen, motorstoring, interlock actief, lokale/remote stand.
Beveiligingsalarmen: trip, start, blokkeer, relais-gezond, CT/VT-fout, meetverlies.
Hulpvoeding & omgeving: UPS/DC, batterijspanning, deurcontact, rook/water/temperatuur (afhankelijk van stationtype).

1.3 Remote switching (schakelen op afstand)

Remote switching is geen “extra knop” maar een veiligheidsfunctie. In de praktijk heb je minimaal nodig:

Remote/local-selectie (hardwired en zichtbaar op locatie).
Positieve terugmelding van schakelstand en (waar relevant) aardingsschakelaar.
Interlocks (mechanisch én logisch) om onveilige handelingen te blokkeren.
Command logging (wie, wat, wanneer, resultaat).

1.4 Vermogensbegrenzing / curtailment

Bij congestieprojecten is curtailment vaak de echte driver voor telemetrie. Denk aan:

Setpoints: P-limiet, Q-setpoint, cos φ, ramp rates.
Feedback: daadwerkelijk geleverd/afgenomen vermogen vs setpoint.
Fail-safe gedrag: wat doet de installatie bij communicatieverlies?

1.5 Verschillen per use-case (praktisch)

PV (zonnepark / groot dak): nadruk op curtailment, Q-regeling, PQ-meting en aantoonbaarheid richting netbeheerder. Telemetrie/signaallijst en tijdsync worden vaak expliciet onderdeel van het opleverdossier. ([m2e.nl](https://m2e.nl/kennisbank/netcode-eisen-zonnepark-middenspanning?utm_source=openai))
BESS: naast curtailment ook SoC, PCS-status, beschikbaarheid, black-start/stand-by logica (projectafhankelijk) en extra aandacht voor fault ride-through in samenhang met beveiligingsinstellingen. ([m2e.nl](https://m2e.nl/kennisbank/bess-middenspanning-aansluiting?utm_source=openai))
Laadplein: load balancing, piekbewaking, alarmering op transformator/LS-velden, en duidelijke fallback (veilig én operationeel).
Datacenter: redundantie (A/B feeds), zeer strikte alarmfilosofie, integratie met BMS/DCIM en hoge eisen aan beschikbaarheid, tijdsync en logging.
Tuinbouw: veel schakelmomenten, seizoensprofielen, en behoefte aan snelle storingsdiagnose (spanningskwaliteit en beschikbaarheid).

2) Architectuurkeuzes: RTU/PLC, IED’s, protocollen, tijdsynchronisatie en redundantie

De kernvraag in engineering: waar “landt” de waarheid? In het beveiligingsrelais (IED), in een RTU/PLC, of in een bovenliggend EMS/SCADA?

2.1 RTU/PLC versus “alles in IED’s”

RTU/PLC als concentrator: handig voor I/O bundelen, protocolconversie, lokale logica (bijv. fallback/curtailment), en eenduidig beheer van communicatie.
IED-first (beveiligingsrelais als bron): efficiënt bij moderne relais met uitgebreide meetwaarden, SOE (sequence of events) en communicatie, maar let op: vendor-lock-in en uniformiteit over meerdere velden.
Hybride (vaak beste): IED’s voor bescherming + RTU voor stationfuncties, alarms, environment, remote access en koppelingen.

2.2 Protocollen (praktische relevantie in klantstations)

IEC 60870-5-104: veel gebruikt richting netbeheerder/regelcentrum-achtige omgevingen; geschikt voor telemetrie, commands en SOE.
DNP3: internationaal gangbaar in utilities/OT; sterk in events en robuuste telemetrie (afhankelijk van landschap).
Modbus (RTU/TCP): veel toegepast voor meters, omvormers, PCS’en; eenvoudig maar let op security en datamodellering.
IEC 61850: relevant bij stationautomatisering en IED-communicatie (GOOSE/MMS), vooral bij complexere stations en hogere eisen aan interoperabiliteit.

Belangrijker dan “welk protocol” is: datamap, naming conventions, tijdsync, testbaarheid en beheer.

2.3 Tijdsynchronisatie (vaak onderschat)

Als je events en trips wilt reconstrueren (of discussies met netbeheerder wilt voorkomen), heb je betrouwbare tijd nodig:

NTP is vaak voldoende voor telemetrie/trends.
PTP / IRIG-B kan nodig zijn bij hoge nauwkeurigheid of uitgebreide SOE-analyse.
Leg vast: tijdbron, fallback, en hoe drift wordt gemonitord.

2.4 Redundantie: wat is “genoeg”?

Redundantie is use-case afhankelijk. Denk aan:

Communicatie: dual-SIM 4G/5G, tweede route via glasvezel, of redundante switches.
Voeding: UPS/DC met monitoring (accuspanning, autonomy).
SCADA/servers: redundant waar downtime direct geld of veiligheid raakt (datacenters/industrie).

2.5 Communicatieroutes: koper, glasvezel, 4G/5G

Glasvezel: hoge bandbreedte en galvanische scheiding; vereist goede patchdiscipline, OT-switches en duidelijke overdracht van beheer.
Bekabeld koper (Ethernet): prima intern in station, maar let op EMC, aarding/afscherming en segmentatie.
4G/5G: snel te realiseren, maar vraagt extra aandacht voor VPN, SIM-beheer, antenneplaatsing en beschikbaarheid.

3) Netbeheerder- en klantstation-koppeling: verantwoordelijkheden, overdrachtgrenzen en acceptatie

Bij een SCADA middenspanningsstation lopen twee werelden door elkaar: netbeheerder (publiek net) en klantinstallatie (privaat). De valkuil: aannemen dat “de communicatie later wel kan”.

3.1 Overdrachtgrenzen: wie is waarvoor verantwoordelijk?

Netbeheerder: eisen aan aansluiting/veiligheid/bedrijf, acceptatiepunten, en (afhankelijk van situatie) eisen aan meet- en telemetrie-inrichting.
Klant/eigenaar: beheerorganisatie (IV), bedieningsbevoegdheden, cybersecurity, onderhoud, en beschikbaarheid van data richting eigen EMS of netbeheerder (als afgesproken).
Integrator (bijv. M2E): engineering, implementatie, FAT/SAT, documentatie en aantoonbaarheid bij oplevering.

3.2 FAT/SAT voor automatisering: wat test je wanneer?

FAT (Factory Acceptance Test): protocoltest (simulator), signaalmapping, alarmteksten, command-handling, tijdsync, logging, failover-scenario’s.
SAT (Site Acceptance Test): end-to-end met echte I/O, interlocks, lokale/remote, communicatie naar SCADA/EMS, en scenario’s bij communicatie-uitval.

In onze kennisbank over PV en inbedrijfname zie je dat telemetrie/signaallijsten en FAT/SAT-rapportage steeds vaker expliciet terugkomen als onderdeel van het opleverdossier. ([m2e.nl](https://m2e.nl/kennisbank/netcode-eisen-zonnepark-middenspanning?utm_source=openai))

3.3 Wat moet je vroeg uitvragen in het aansluittraject?

Neem deze punten mee in je projectstart (voorkomt redesign):

Welke telemetriepunten (meetwaarden/statussen/commands) verwacht de netbeheerder of meetdienst?
Welke protocollen en communicatiemedia zijn toegestaan?
Welke eisen gelden voor tijdsynchronisatie en SOE?
Welke curtailment-aansturing is vereist (setpoint, responstijd, fail-safe)?
Wat is de gewenste overdrachtgrens (demarcatie): kast, patchpanel, managed switch, router, VPN?
Welke acceptatietests verwacht men (format, meetpunten, bewijsvoering)?

Tussentijdse CTA: Wil je voorkomen dat telemetrie/SCADA de kritieke pad wordt richting spanningszetting? Laat M2E een SCADA/telemetrie-scope review doen als onderdeel van je stationontwerp (inclusief signaallijst, I/O en FAT/SAT-plan). Dit sluit direct aan op onze diensten voor inkoopstation/klantstation conform PvE en engineering. ([m2e.nl](https://m2e.nl/oplossingen/inkoopstation-klantstation-netbeheerder?utm_source=openai))

4) Cybersecurity by design voor SCADA in middenspanningsstations

Remote switching en telemetrie vergroten het aanvalsoppervlak. Cybersecurity “achteraf” toevoegen is duur en leidt tot discussie bij beheer en audits. Ontwerp daarom vanaf dag 1 met OT-security als randvoorwaarde.

4.1 Segmentatie: OT ≠ IT

Zonering: scheid station-OT (IED/RTU/PLC) van kantoor-IT en van internet.
Conduits: alleen noodzakelijke datastromen, expliciet gefilterd (firewallregels), geen “any-any”.
DMZ: voor koppelingen met cloud/EMS of remote service (jump host, historizer, proxy).

4.2 Remote access: veilig én beheersbaar

VPN met sterke authenticatie (bij voorkeur MFA), per rol/partij, en tijdgebonden toegang.
Jump server / bastion in OT-DMZ: geen directe RDP/engineering tooling naar IED’s vanaf laptops.
Break-glass-procedure voor storingen (wie mag wanneer inloggen, met welk logboek).

4.3 Logging, monitoring en forensics-light

Command- en login-logging (RTU, router, firewall, SCADA).
Tijdsync consistent voor alle logs.
Bewaartermijnen en export naar SIEM (indien organisatie dat heeft).

4.4 Patchbeleid & hardening

Asset inventory: welke firmware/software draait waar?
Patchvensters en teststrategie (zeker bij IED/PLC).
Hardening: ongebruikte services uit, default accounts weg, sterke wachtwoorden/keys, secure config backups.

4.5 Kaders (praktisch)

In Nederland zien we dat organisaties hun OT-beveiliging vaak ophangen aan gangbare industriële kaders (zoals IEC 62443-principes) en interne IT-security policies. Belangrijk: vertaal dit naar concrete engineering-eisen (zonering, remote access, logging, patchproces) die je kunt testen tijdens FAT/SAT.

5) Praktische checklist voor engineering & oplevering

Onderstaande checklist helpt om van “we willen SCADA” naar “het werkt, is veilig, en is acceptabel voor beheer en netbeheerder” te gaan.

5.1 Signaallijst (telemetriepunten)

Meetwaarden: P/Q/U/I/f, kWh (indien beschikbaar), THD/PQ (indien vereist).
Schakelstanden: CB/lastscheider, aardingsschakelaar, local/remote, interlock actief.
Beveiliging: trip, start, blokkeer, relais-fout, DC-fout, CT/VT-fout.
Aux: deur, rook/water/temp, UPS status.
Commands: open/dicht (met permissives), reset, setpoints (curtailment/Q).

5.2 I/O-lijst en mapping

Bron per signaal (IED/RTU/meter/PCS/omvormer).
Type (DI/DO/AI/AO, protocol-point, quality-bit).
Schaling, eenheden, deadbands, update rates.

5.3 Alarmfilosofie

Prioriteiten: trip/veiligheid, urgent, waarschuwing, informatie.
Suppressie: voorkom alarmstorms (bijv. communicatieverlies geeft niet 200 onderliggende alarms).
Actiegericht: elk alarm heeft een eigenaar en handelingsperspectief.

5.4 Fallback bij communicatie-uitval

Wat blijft lokaal autonoom werken (beveiliging altijd lokaal).
Wat gebeurt er met curtailment-setpoints bij link-down?
Hoe wordt her-connecting gedaan (ramp, setpoint restore, command lockout)?

5.5 FAT/SAT testplan (automatisering)

Point-to-point test (alle signals + quality).
Remote switching permissives en interlocks bewezen.
Event logging/SOE + tijdsync verificatie.
Cyber: VPN/MFA, logging, rollen/rechten, hardening-check.

5.6 Opleverdossier & beheerorganisatie (IV/VP/werkvergunningen)

As-built schema’s (SLD, besturingsschema’s), netwerktekening (OT-zones/DMZ).
Configuratieback-ups (RTU/PLC, firewall/router, SCADA project).
Wachtwoord-/keybeheerproces (niet “in de kast geplakt”).
Beheerprocedures: wie mag schakelen, hoe worden werkvergunningen en bedieningshandelingen geregistreerd.

Voor de borging van de beheerrol in de praktijk (aanwijzingen, procedures, werkverantwoordelijkheid) kan IV-schap uitbesteden uitkomst bieden, zeker als je remote switching gaat toepassen. ([m2e.nl](https://m2e.nl/diensten/iv-schap-installatieverantwoordelijkheid?utm_source=openai))

Samenvatting

Een SCADA middenspanningsstation ontwerp draait niet alleen om “data uitlezen”, maar om een totaalplaatje: functies per use-case (meten/alarmeren/schakelen/curtailment), een robuuste architectuur (RTU/IED/protocol/tijdsync/redundantie), duidelijke demarcatie met netbeheerder (uitvragen + FAT/SAT), én cybersecurity by design (segmentatie, remote access, logging, patch/hardening). Met een praktische checklist (signaallijst, I/O, alarmfilosofie, fallback en opleverdossier) voorkom je vertraging bij acceptatie en krijg je een station dat ook écht beheersbaar is.

Harde CTA: laat je SCADA-scope en ontwerp reviewen

Wil je zekerheid dat jouw telemetrie/SCADA en remote switching netbeheerder-proof, cybersecure en testbaar wordt opgeleverd? Neem contact op met M2E voor een engineering review of complete realisatie (incl. FAT/SAT-plan, signaallijst en opleverdossier). Combineer dit desgewenst met IV-schap voor veilige bedrijfsvoering.

Interne links (diensten/gerelateerd):

FAQ (voor featured snippets)

Wat betekent SCADA in een middenspanningsstation?

SCADA in een middenspanningsstation is de combinatie van telemetrie (meten, alarmeren, trends) en bediening (bijv. remote switching en setpoints voor curtailment) via een RTU/PLC en/of IED’s, gekoppeld aan een bovenliggend SCADA/EMS-systeem.

Welke telemetriepunten zijn minimaal nodig?

Minimaal worden vaak P/Q/U/I/f, schakelstanden (open/dicht, local/remote), trip/alarmstatus van beveiligingen, DC/UPS-status en communicatie-gezond gemonitord. De exacte lijst hangt af van use-case en netbeheerderafspraken.

Welke protocollen worden het meest gebruikt voor telemetrie in klantstations?

In de praktijk komen IEC 60870-5-104, Modbus (TCP/RTU), DNP3 en – bij meer geavanceerde stationautomatisering – IEC 61850 voor. De keuze hangt af van eisen van netbeheerder, gebruikte IED’s/RTU en integratie met je EMS/SCADA.

Kan ik veilig schakelen op afstand in een middenspanningsstation?

Ja, mits je remote/local-selectie, interlocks, positieve terugmeldingen, command logging, werkprocessen (IV/WV/werkvergunningen) en cybersecurity (segmentatie en beveiligde remote access) goed ontwerpt én test tijdens SAT.

Wat moet ik vooraf uitvragen bij de netbeheerder?

Vraag vroegtijdig uit: gewenste telemetriepunten, toegestane protocollen/communicatiemedia, eisen voor tijdsynchronisatie en logging, curtailment-aansturing (setpoints/fail-safe), overdrachtgrens (demarcatie) en acceptatietesten (FAT/SAT en bewijsvoering).

Wat gebeurt er bij communicatie-uitval?

Beveiligingen blijven lokaal functioneren, maar telemetrie en remote control vallen weg. Je moet vooraf vastleggen wat curtailment-setpoints doen (hold/zero/last-known), hoe heraansluiting gebeurt en hoe operators worden gealarmeerd. Dit hoort in je fallback- en alarmfilosofie.