Wat is schaalbaarheid?
Schaalbaarheid is het vermogen van een systeem, netwerk of applicatie om toenemende belasting, zoals meer gebruikers, datavolumes, netwerkverkeer, locaties of productiecapaciteit, op te vangen zonder dat prestaties, stabiliteit of beheerbaarheid significant verslechteren. Binnen OT, industriële automatisering en OT-convergentie is schaalbaarheid een cruciaal ontwerpprincipe. Industriële omgevingen groeien vaak van geïsoleerde productielijnen naar verbonden ecosystemen met duizenden assets, realtime datastromen, cloudkoppelingen en analytics. Schaalbaarheid speelt daarbij op elke laag: van PLC-systemen en netwerken tot SCADA-platformen, historians, IIoT-platformen, databases, edge computing, monitoring en cybersecurityarchitecturen.
🧠 Waarom is schaalbaarheid belangrijk in IT/OT?
Traditionele OT-systemen werden ontworpen voor een vaste installatie die vaak twintig jaar of langer nauwelijks veranderde. Met Industrie 4.0 stijgt het aantal verbonden systemen sterk, en een architectuur die dat niet aankan, leidt tot prestatieproblemen, netwerkcongestie, hogere latency, beheercomplexiteit en uiteindelijk onbetrouwbare productieprocessen.
Groei ontstaat in vrijwel elk domein:
| Domein | Voorbeeld van groei |
|---|---|
| Productielijnen | Extra machines of een nieuwe lijn |
| Energiebeheer | Nieuwe meetpunten en submeters |
| SCADA | Meer assets, schermen en gelijktijdige clients |
| Historian | Toenemende datastromen en langere bewaartermijnen |
| Netwerken | Meer OT-devices en verkeer naar IT en cloud |
| IIoT | Sensoruitbreiding en nieuwe use cases |
⚙️ Wat is het verschil tussen verticaal en horizontaal schalen?
Verticaal schalen (scale up) betekent meer capaciteit in hetzelfde systeem: meer CPU, meer geheugen, snellere opslag of een zwaardere server. Horizontaal schalen (scale out) betekent extra systemen toevoegen: extra servers, brokers, databases of load-balanced services.
| Kenmerk | Verticaal schalen | Horizontaal schalen |
|---|---|---|
| Aanpak | Bestaande server zwaarder maken | Extra nodes naast elkaar |
| Voordelen | Eenvoudig, beperkte wijzigingen in de architectuur | Hogere beschikbaarheid, betere redundantie, flexibel |
| Nadelen | Hardwarelimieten, single point of failure, hogere kosten per stap | Complexere architectuur, synchronisatie, meer netwerkverkeer |
| Typisch in OT | Eén SCADA-server of historian upgraden | Brokerclusters, gescheiden I/O- en front-endservers |
Horizontaal schalen kent ook een grens: volgens de wet van Amdahl (1967) beperkt het deel van een taak dat niet parallel kan, zoals een centrale database-lock, de winst van extra nodes. Toch wordt horizontale schaalbaarheid binnen moderne OT-platformen steeds belangrijker.
🏭 Hoe schalen SCADA, historians en MES?
SCADA-systemen, historians en MES lopen tegen dezelfde groeifactoren aan: meer tags, meer clients, hogere pollingfrequenties, groeiende historische opslag en hogere alarmvolumes. Dat laatste is een veiligheidsrisico: volgens ISA-18.2 en EEMUA 191 is er sprake van een alarm flood bij meer dan 10 alarmen per 10 minuten per operator. Goed alarmmanagement moet dus meegroeien met het aantal assets.
Belangrijke architectuurkeuzes:
| Component | Schaalbaarheidsmaatregel |
|---|---|
| Historian | Gedistribueerde opslag, compressie, tiering per site |
| SCADA-servers | Redundantie en scheiding van I/O- en clientbelasting |
| Alarmservers | Load balancing en alarmrationalisatie |
| Databases | Clustering en partitionering |
Ter indicatie noemt Inductive Automation in zijn sizinggids voor Ignition ongeveer 5.000 tags en 10 clients op 2 cores en 4 GB RAM, en 100.000 tags en 75 clients op 8 cores en 16 GB. Daarboven adviseert de leverancier een scale-out-architectuur met aparte I/O- en front-endgateways, of een hub-and-spoke-model waarin edgegateways per site data bufferen en doorsturen naar een centrale hub.
Het licentiemodel bepaalt vaak meer dan de techniek wat groei kost. WinCC Runtime wordt verkocht in pakketten PowerTags (bijvoorbeeld 128, 2.048, 8.192 of 65.536), terwijl Ignition per server wordt gelicenseerd met onbeperkt tags en clients. Voor opslag wordt vaak een time-series database zoals InfluxDB gebruikt, met Grafana als schaalbare visualisatielaag.
🔄 Hoe helpen Unified Namespace en publish-subscribe bij schaalbaarheid?
Klassieke SCADA vraagt data cyclisch op bij elke besturing (polling). Bij honderden besturingen en meerdere afnemers groeit het aantal punt-tot-puntverbindingen met het aantal bronnen maal het aantal afnemers, omdat elke afnemer zijn eigen verbindingen opent. In een Unified Namespace publiceren bronnen hun data één keer naar een centrale broker, alleen bij wijziging (report by exception), en kunnen MES, SCADA, analytics en cloud zich daarop abonneren.
Binnen het Industrial Internet of Things spelen hierbij een aantal standaarden:
- MQTT - MQTT 3.1.1 is sinds 2016 ISO/IEC 20922; MQTT 5.0 (OASIS, maart 2019) voegde shared subscriptions toe om berichten over meerdere afnemers te verdelen
- Sparkplug - Sparkplug 3.0 is sinds oktober 2023 de internationale norm ISO/IEC 20237 en standaardiseert topics, payloads en statusbeheer
- OPC UA PubSub - sinds versie 1.04 (februari 2018) kent OPC UA naast client/server ook publish-subscribe, onder meer over MQTT en AMQP
- Apache Kafka - vaak gebruikt als schaalbare streaminglaag tussen OT-brokers en IT-platformen
Schaalbaarheidsfactoren van een broker zijn het aantal topics, het aantal clients, de berichtdoorvoer en de gekozen MQTT QoS-niveaus (0, 1 of 2). De open-source broker Mosquitto draait op één node zonder clustering en past goed bij een site of de edge; voor grote aantallen verbindingen zijn clusterbrokers nodig. EMQX toonde in 2022 100 miljoen gelijktijdige MQTT-verbindingen op een cluster van 23 nodes. Event-driven OT-architecturen vereisen zorgvuldig ontwerp van topics en redundante brokers om bottlenecks te voorkomen.
🌐 Wat begrenst schaalbaarheid in OT-netwerken en protocollen?
OT-netwerken groeien door digitalisering en connectiviteit. Aandachtspunten zijn bandbreedte, latency, jitter, broadcast- en multicastverkeer en segmentatie.
| Technologie | Functie |
|---|---|
| VLAN | Segmentatie en beperking van broadcastdomeinen |
| QoS | Prioritering van kritiek verkeer |
| Redundantie | Beschikbaarheid bij uitval van links of switches |
| Industrial Ethernet | Hoge prestaties in het veld |
| TSN | Deterministische communicatie op standaard ethernet |
Niet alle protocollen schalen even goed:
| Protocol | Schaalbaarheid | Reden |
|---|---|---|
| MQTT | Hoog | Publish-subscribe via broker, report by exception |
| OPC UA | Hoog | Client/server en PubSub, rijk informatiemodel; sessies per server zijn wel begrensd |
| Modbus TCP | Beperkt | Polling, maximaal 125 registers per leesopdracht, geen informatiemodel |
| Profibus | Beperkt | Maximaal 126 adressen, 32 stations per segment zonder repeater |
| ProfiNET | Hoog | Ethernetgebaseerd, schaalt met switches en topologie |
| Ethernet IP | Hoog | Ethernetgebaseerd, ondersteunt multicast-I/O |
Onvoldoende netwerkcapaciteit veroorzaakt netwerkcongestie, packet loss, vertraagde besturing en onbetrouwbare HMI’s. Waar deterministisch gedrag vereist is, mag groei van IT-verkeer nooit ten koste gaan van besturingsverkeer.
☁️ Welke rol spelen edge computing en de cloud?
Edge Computing verwerkt data lokaal en vermindert daarmee de belasting op centrale databases, WAN-verbindingen, cloudplatformen en historians. Voordelen zijn lagere latency, minder cloudverkeer en betere beschikbaarheid: een edgegateway met store-and-forward buffert data als de verbinding wegvalt. Veelgebruikte edgecomponenten zijn Node-RED, lokale MQTT-brokers, lokale analytics en edge-historians, vaak als containers in Docker of Kubernetes.
Cloudplatformen bieden elasticiteit, dynamische resources en geautomatiseerde scaling. Binnen OT staan daar latency, compliance, cybersecurity, determinisme en beschikbaarheid tegenover. Daarom ontstaan hybride architecturen waarin realtime besturing lokaal blijft en analytics naar de cloud gaat.
📈 Hoe beheert u datagroei en databases?
Digitalisering zorgt voor sterke groei van industriële data uit IIoT-sensoren, historians, netwerkmonitoring, security-logging en machine-learning-datasets. Uitdagingen zijn opslagcapaciteit, retentiebeleid, queryperformance, backupvensters en replicatiebelasting. Technieken om dat beheersbaar te houden zijn downsampling, compressie, edge filtering en data-lifecyclemanagement.
| Platform | Eigenschap |
|---|---|
| InfluxDB | Schaalbare time-series opslag |
| PostgreSQL | Relationele opslag, met extensies ook voor tijdreeksen |
| Elasticsearch | Horizontaal schaalbare log- en zoekanalyse |
| Historian-platformen | Industriële procesdata met compressie |
Belangrijke ontwerpkeuzes zijn partitionering, replicatie, query-optimalisatie, datacompressie en high availability.
🔐 Hoe schaalt cybersecurity mee?
Meer OT-assets, netwerksegmenten, cloudkoppelingen, remote access en leveranciersintegraties maken cybersecurity complexer. Maatregelen die handmatig per apparaat worden ingericht, schalen slecht.
| Maatregel | Doel |
|---|---|
| Zero Trust | Gedistribueerde beveiliging zonder impliciet vertrouwen |
| Microsegmentatie | Kleinere aanvalsvlakken |
| RBAC | Centraal en rolgebaseerd toegangsbeheer |
| SIEM | Centrale monitoring van logs en events |
| MFA | Sterkere authenticatie |
Sinds 15 augustus 2026 geldt in Nederland de Cyberbeveiligingswet (Cbw), de Nederlandse implementatie van NIS2. Een schaalbare securityarchitectuur maakt het eenvoudiger om bij groei aan de zorgplicht en meldplicht uit die wet te blijven voldoen.
⚠️ Welke problemen ontstaan bij slechte schaalbaarheid?
| Probleem | Gevolg |
|---|---|
| Overbelaste servers | Trage schermen en vertraagde opdrachten |
| Netwerkcongestie | Communicatieverlies en time-outs |
| Historian-overbelasting | Dataverlies zodra de buffer vol is |
| Alarm flooding | Overbelaste operators |
| Databasebottlenecks | Vertraagde analyses en rapportages |
Typische oorzaken zijn een slechte architectuur, onderdimensionering, inefficiënte queries, te hoge pollingfrequenties en overmatige logging. Meet daarom throughput, responstijd, latency, CPU- en geheugengebruik. Binnen kritieke infrastructuren hebben schaalbaarheidsproblemen direct impact op veiligheid en continuïteit.
🔄 Wat is het verschil tussen schaalbaarheid en beschikbaarheid?
| Aspect | Schaalbaarheid | Beschikbaarheid |
|---|---|---|
| Focus | Groei ondersteunen | Continuïteit |
| Doel | Capaciteitsuitbreiding | Storingsbestendigheid |
| Technieken | Clustering, scaling | Redundantie, failover |
| Risico | Prestatieverlies | Downtime |
In OT moeten beide samengaan: een geclusterde broker schaalt én blijft beschikbaar bij uitval van een node.
🧭 Hoe ontwerpt u een schaalbaar IT/OT-systeem?
- Bepaal de groeiscenario’s - aantal tags, clients, sites en datavolume nu en over tien jaar.
- Controleer licentiemodellen - per tag, per client of per server; reken uitbreiding vooraf door.
- Kies een modulaire architectuur - segmentatie, edgeverwerking, event-driven communicatie en gedistribueerde componenten.
- Ontkoppel bronnen en afnemers - via een Unified Namespace of streaminglaag in plaats van punt-tot-puntkoppelingen.
- Test de prestaties - loadtests op verwachte belasting, stresstests boven de limiet en duurtests over dagen, bij voorkeur in een testomgeving.
- Monitor en plan capaciteit - volg trends in CPU, opslag en berichtdoorvoer en grijp in vóór knelpunten.
Een waterschap dat tientallen gemalen centraliseert, kan bijvoorbeeld per gemaal een edgegateway met buffer plaatsen en de data via een broker naar centrale SCADA en analytics sturen. Zulke schaalbare architecturen ondersteunen IIoT, predictive maintenance, cloudanalytics en digital twins, en maken schaalbaarheid een vast onderdeel van industriële architectuur en lifecyclemanagement.
❓ Veelgestelde vragen
Wat is het verschil tussen schaalbaarheid en elasticiteit?
Schaalbaarheid is het vermogen van een systeem om groei op te vangen door capaciteit toe te voegen. Elasticiteit is het automatisch op- en afschalen van die capaciteit op basis van actuele vraag, zoals in cloudplatformen. Een elastisch systeem is dus altijd schaalbaar, maar een schaalbaar OT-systeem is lang niet altijd elastisch.
Hoeveel tags kan een SCADA-server aan?
Hoeveel tags een SCADA-server aankan, hangt af van hardware, scanfrequentie, historisering en het aantal clients. Ignition geeft als richtwaarde ongeveer 100.000 tags met 75 clients op een server met 8 cores en 16 GB geheugen. Daarboven worden I/O-taken en clientbelasting over meerdere servers verdeeld.
Is MQTT schaalbaarder dan OPC UA?
MQTT schaalt goed voor grote aantallen apparaten en afnemers, omdat een broker berichten verdeelt en bronnen alleen bij wijziging publiceren. OPC UA client/server is per server beperkt in sessies, maar OPC UA PubSub kan ook over MQTT lopen. In de praktijk worden beide gecombineerd: OPC UA dicht bij de machine en MQTT voor schaalbare distributie.
Waarom beperkt het licentiemodel de schaalbaarheid?
Veel SCADA- en historianpakketten rekenen per tag of per client, waardoor elke uitbreiding nieuwe licentiekosten oplevert. Daardoor worden extra meetpunten soms bewust niet ontsloten, ook als de techniek dat wel aankan. Een schaalbaarheidsanalyse moet daarom altijd het licentiemodel meenemen.
Hoe test u de schaalbaarheid van een OT-systeem?
De schaalbaarheid van een OT-systeem test u met loadtests op verwachte belasting, stresstests boven die belasting en duurtests over langere tijd. Gebruik daarbij gesimuleerde tags of berichten in een testomgeving, zodat de productie niet wordt verstoord. Meet throughput, responstijd, latency en resourcegebruik.
Kan de cloud de schaalbaarheid van OT oplossen?
De cloud lost schaalbaarheid van opslag, analytics en rapportage goed op door elastische capaciteit. Realtime besturing blijft echter lokaal vanwege latency, determinisme en afhankelijkheid van de internetverbinding. Een hybride architectuur met edge en cloud is daarom de gangbare oplossing.
📌 Samengevat
Schaalbaarheid bepaalt of een IT/OT-omgeving kan groeien in tags, clients, sites en data zonder dat prestaties, betrouwbaarheid of veiligheid lijden. Combineer horizontale schaalbaarheid, publish-subscribe met een Unified Namespace, edgeverwerking en een passend licentiemodel, en toets het ontwerp vooraf met prestatietests.