Elke moderne fabriek staat vol met PLC's — programmeerbare logische controllers die transportbanden aansturen, temperaturen bewaken, producten tellen en kleppen regelen. Ze doen hun werk betrouwbaar, dag in dag uit. Maar de data die ze genereren? Die blijft meestal opgesloten, onzichtbaar voor iedereen zonder een SCADA-licentie of een achtergrond in ladder-logica.
In dit artikel laat ik zien hoe Python de kloof kan overbruggen tussen de operationele technologie (OT) wereld van PLC's en de informatietechnologie (IT) wereld van databases, dashboards en machine learning. Of je nu een eenvoudig live overzicht voor de productievloer wilt of een volledige analytics-pipeline, Python is de lijm die het mogelijk maakt — zonder iets te vervangen dat al werkt.
De IT/OT-kloof: waarom die bestaat en waarom het ertoe doet
Loop een willekeurig productiebedrijf binnen en je vindt twee werelden die nauwelijks met elkaar communiceren. Aan de ene kant is er OT — de PLC's, HMI's en SCADA-systemen die de fabriek draaiende houden. Aan de andere kant is er IT — de ERP-systemen, databases en bedrijfstools die het management gebruikt om beslissingen te nemen. De kloof daartussen is niet alleen technisch; hij is ook cultureel. OT-engineers geven prioriteit aan uptime en determinisme. IT-teams geven prioriteit aan flexibiliteit en datatoegang. Beide hebben gelijk, en beide zijn nodig.
Het probleem is dat waardevolle productiedata — cyclustijden, uitvalpercentages, energieverbruik, machinestatus — aan de OT-kant zit zonder een eenvoudige manier om het bij de mensen te krijgen die het nodig hebben. Productiemanagers vertrouwen op papieren logboeken of weekrapporten. Kwaliteitsengineers downloaden handmatig CSV-bestanden uit SCADA. En het managementteam neemt beslissingen op basis van data die dagen of weken oud is.
Python zit perfect in het midden. Het is flexibel genoeg om OT-protocollen zoals Modbus en OPC UA te spreken, maar krachtig genoeg om databases te vullen, dashboards te bouwen en analyses uit te voeren. Het vervangt de PLC of SCADA niet — het vergroot hun bereik naar de IT-wereld.
Communicatieprotocollen: hoe je met een PLC praat
Voordat je iets nuttigs kunt doen met PLC-data, moet je de data eruit krijgen. Dat betekent dat je een van de industriële communicatieprotocollen moet spreken die de PLC ondersteunt. De twee meest gangbare zijn Modbus en OPC UA, en elk heeft verschillende sterktes.
Modbus (TCP / RTU)
- Eenvoudig, beproefd protocol uit 1979
- Ondersteund door vrijwel elke PLC op de markt
- Lees/schrijf registers direct via adres
- TCP-variant draait over standaard Ethernet
- RTU-variant gebruikt RS-485 serieel
- Geen ingebouwde beveiliging of discovery
- Python-bibliotheek: pymodbus
OPC UA
- Moderne, platformonafhankelijke standaard
- Rijk datamodel met types en hiërarchie
- Ingebouwde beveiliging (encryptie, authenticatie)
- Ondersteunt subscriptions voor event-driven data
- Beschikbare datapunten dynamisch browsen
- Complexer op te zetten dan Modbus
- Python-bibliotheek: opcua / asyncua
Mijn vuistregel: Als de PLC al een OPC UA-server aanbiedt (de meeste moderne WAGO-, Siemens- en Beckhoff-PLC's doen dat), gebruik dan OPC UA — het is meer gestructureerd en veiliger. Als je werkt met oudere apparatuur of eenvoudige sensoren, is Modbus TCP vaak het snelste pad. In veel praktijkprojecten gebruik ik beide, afhankelijk van de machine.
MQTT als middleware: producers en consumers ontkoppelen
Zodra je data kunt lezen van een PLC, sta je voor een ontwerpvraag: moet je Python-dashboard rechtstreeks verbinden met de PLC, of moet er iets tussenin zitten? Voor een enkele machine in een kleine opstelling werkt een directe verbinding prima. Maar zodra je meerdere machines hebt, meerdere consumers (dashboard, database, alerting), of netwerkstoringen netjes wilt opvangen, wil je een message broker.
MQTT is de standaardkeuze in industrieel IoT. Het is lichtgewicht, ondersteunt quality-of-service-niveaus en ontkoppelt dataproducers (de PLC-lezers) van dataconsumers (dashboards, databases). Een klein Python-script leest van de PLC via Modbus of OPC UA en publiceert de waarden naar een MQTT-broker. Een willekeurig aantal consumers kan zich vervolgens abonneren op de topics die ze nodig hebben, zonder dat de PLC het weet of er iets van merkt.
Deze architectuur schaalt prachtig. Een nieuwe machine toevoegen betekent één extra publisher-script. Een nieuw dashboard toevoegen betekent één extra subscriber. Verder verandert er niets. De broker (Mosquitto is mijn gebruikelijke keuze) regelt de routering en buffering.
De datapipeline stap voor stap opbouwen
Hier is de praktische workflow die ik in de meeste projecten volg. Het is bewust incrementeel — elke stap levert op zichzelf waarde, dus je hoeft niet de hele pipeline te bouwen voordat je resultaten ziet.
Identificeer de datapunten
Praat met de operators en de PLC-programmeur. Welke registers bevatten de waarden die je nodig hebt? Wat zijn de datatypes, eenheden en update-snelheden? Documenteer alles in een eenvoudig spreadsheet voordat je één regel code schrijft.
Lezen en valideren
Schrijf een klein Python-script dat die registers leest en naar de console print. Controleer of de waarden overeenkomen met wat het HMI laat zien. Dit vangt byte-volgorde-problemen, schaalfactoren en verkeerde adressen vroeg op.
Publiceer naar MQTT
Wikkel de lezer in een loop, publiceer elke meting naar een MQTT-topic met een timestamp. Nu kan elke consumer op het netwerk de data in real time benaderen zonder de PLC rechtstreeks aan te raken.
Opslaan in een time-series database
Abonneer je op de MQTT-topics en schrijf de data naar een time-series database zoals InfluxDB of TimescaleDB. Dit geeft je historie, trendanalyse en de mogelijkheid om willekeurige tijdsperiodes op te vragen.
Visualiseer
Verbind een dashboard-tool (Grafana, een custom webapplicatie, of zelfs een simpele Python Dash-applicatie) met de database. Bouw de weergaven die operators en managers daadwerkelijk nodig hebben — niet alles wat je kúnt tonen, maar wat hen helpt beslissingen te nemen.
Belangrijke les: Stap 1 en 2 alleen al kunnen een dag kosten. Stap 3-5 kosten een paar dagen extra. Binnen een week kun je een werkende pipeline hebben van PLC tot dashboard. Dat is snel genoeg om waarde te bewijzen voordat iemand de investering in twijfel trekt.
Real-time vs batch: het juiste ritme kiezen
Niet elk datapunt hoeft elke seconde bijgewerkt te worden. Een veelgemaakte fout is om alles als real-time te behandelen, waardoor het netwerk en de database overlopen met data waar in werkelijkheid niemand in real time naar kijkt. Ik verdeel data in drie niveaus:
Real-time (< 1 seconde)
Veiligheidskritische waarden, actieve alarmen, machinestatus. Deze moeten direct zichtbaar zijn. Gebruik MQTT met QoS 1 en een live dashboard-widget.
Near-real-time (1-60 seconden)
Productietellers, temperaturen, doorstroomsnelheden. Elke paar seconden bijwerken is voldoende. Dit dekt de meeste operationele dashboards en trendgrafieken.
Batch (minuten tot uren)
Energietotalen, dienstsamenvattingen, kwaliteitsrapporten. Geaggregeerde data die periodiek berekend wordt. Sla ruwe data op en bereken samenvattingen op een schema.
Het juiste niveau kiezen voor elk datapunt houdt het netwerkverkeer beheersbaar, de database-omvang redelijk en de dashboard-prestaties vlot. Te frequent pollen van een PLC kan zelfs de regelcyclus verstoren, dus controleer altijd de aanbevelingen van de PLC-programmeur voor veilige polling-intervallen.
Data-opslag: waarom time-series databases ertoe doen
Je kunt PLC-data opslaan in een gewone SQL-database, en voor kleine opstellingen werkt dat prima. Maar zodra je tientallen datapunten elke paar seconden logt over meerdere machines, begint een general-purpose database moeite te krijgen. Time-series databases zijn precies ontworpen voor dit patroon: grote volumes tijdgestempelde data met snelle writes en efficiënte range queries.
InfluxDB is mijn standaardkeuze voor de meeste projecten. Het verwerkt hoge write-doorvoer, comprimeert historische data automatisch en integreert native met Grafana. Voor projecten die SQL-compatibiliteit of complexe joins met bedrijfsdata nodig hebben, is TimescaleDB (een PostgreSQL-extensie) een uitstekend alternatief — je krijgt time-series-prestaties met de volledige kracht van SQL.
Welke je ook kiest, denk vroeg na over retentiebeleid. Ruwe data met 1-seconde resolutie genereert gigabytes per maand. Na een paar weken heb je zelden granulariteit op secondeniveau nodig — minuut- of uurgemiddelden volstaan. Stel automatische downsampling in zodat de database snel blijft en opslagkosten beheersbaar blijven.
Dashboards en visualisatie
Het dashboard is waar al het werk zijn vruchten afwerpt. Het is de interface tussen de data en de mensen die beslissingen nemen. Ik heb verschillende benaderingen gebruikt, en de juiste hangt af van het publiek en de complexiteit van het project.
Grafana
- Uitstekend voor time-series data en trends
- Native InfluxDB- en MQTT-ondersteuning
- Snel op te zetten met kant-en-klare panels
- Ingebouwde alerting (e-mail, Slack, webhook)
- Het beste voor technische of semi-technische gebruikers
Custom webdashboard
- Volledige controle over layout en branding
- Afgestemd op specifieke werkprocessen
- Beter voor niet-technische eindgebruikers
- Kan bedrijfslogica en navigatie integreren
- Meer ontwikkelinspanning vooraf
Voor de meeste industriële projecten begin ik met Grafana omdat het binnen uren waarde levert. Als het project groeit en het publiek verschuift van engineers naar managers, bouw ik een custom dashboard dat complexiteit verbergt en focust op de drie of vier cijfers die daadwerkelijk beslissingen sturen.
Beveiliging: vergeet het fabrieksnetwerk niet
Op het moment dat je een PLC verbindt met iets op het IT-netwerk, wordt beveiliging cruciaal. PLC's zijn ontworpen om betrouwbaar te zijn, niet veilig. De meeste Modbus-verbindingen hebben helemaal geen authenticatie. Dat betekent niet dat je geen veilig systeem kunt bouwen — het betekent dat je zorgvuldig moet nadenken over de netwerkarchitectuur.
Netwerksegmentatie
Houd het OT-netwerk fysiek of logisch gescheiden van het IT-netwerk. Je Python-gateway zit in een DMZ ertussenin, met firewallregels die alleen het specifiek benodigde verkeer toelaten.
Read-only toegang
In de meeste analytics- en dashboard-scenario's hoef je alleen te lezen van de PLC. Configureer je verbinding als read-only en blokkeer schrijfcommando's op protocolniveau. Geef een dashboard nooit de mogelijkheid om een setpoint te wijzigen.
Gebruik OPC UA waar mogelijk
OPC UA ondersteunt standaard TLS-encryptie en certificaatgebaseerde authenticatie. Het is ontworpen voor precies dit soort toepassingen. Als beveiliging een punt van aandacht is (en dat zou het moeten zijn), heeft OPC UA sterk de voorkeur boven Modbus.
Opschalen: van één machine naar een hele fabriek
Een veelvoorkomend traject dat ik zie: iemand bouwt een Python-script dat één PLC leest en data toont op een scherm naast de machine. Het werkt prima. Dan vraagt de baas: "Kunnen we dit voor alle 12 machines doen?" Dit is waar architectuur ertoe doet.
De sleutel is om elk onderdeel onafhankelijk te houden. Eén reader-script per machine (of per PLC), die allemaal publiceren naar dezelfde MQTT-broker. Eén database die van alle topics ontvangt. Een of meer dashboards die uit de database trekken. Een machine toevoegen betekent één extra reader-script deployen en een dashboard-panel toevoegen. Verder hoeft er niets te veranderen.
Voor deployment gebruik ik doorgaans Docker-containers op een kleine industriële PC (een fanless mini-PC of zelfs een Raspberry Pi 4 voor lichtere belastingen). Elk reader-script draait in zijn eigen container, met automatische herstart bij falen. De MQTT-broker, database en Grafana krijgen elk hun eigen container. Docker Compose bindt het allemaal samen in één configuratiebestand dat iedereen kan deployen.
Praktische tip: Begin met één machine en zorg dat het goed werkt. Maak vervolgens het reader-script een template zodat het toevoegen van een nieuwe machine slechts een kwestie is van het kopiëren van een configuratiebestand met het nieuwe PLC-adres en registeroverzicht. Ik heb fabrieken gezien die in twee weken van nul naar volledige dekking gingen zodra het template bewezen was.
Veelgemaakte fouten en geleerde lessen
Na het bouwen van meerdere van dit soort pipelines zijn hier de fouten die ik het vaakst zie — inclusief fouten die ik zelf heb gemaakt.
Veelgemaakte fouten
- De PLC te snel pollen waardoor de regelcyclus verstoord raakt
- Byte-volgorde negeren (big-endian vs little-endian) bij het lezen van float-waarden
- Geen foutafhandeling voor netwerkonderbrekingen — het script crasht stilletjes
- Alles opslaan op maximale resolutie voor altijd
- Eerst het dashboard bouwen en dan pas de pipeline
- De PLC-programmeur niet vroeg genoeg erbij betrekken
Wat goed werkt
- Begin met de 3-5 belangrijkste datapunten, niet alles
- Valideer metingen tegen het HMI voordat je ze vertrouwt
- Implementeer reconnectie-logica met exponentiële backoff
- Gebruik retentiebeleid vanaf dag één
- Bouw de pipeline eerst end-to-end, verbreed hem daarna
- Ga bij operators zitten om te begrijpen wat ze daadwerkelijk willen zien
De belangrijkste les: Dit is niet primair een softwareproject. Het is een communicatieproject. De Python-code is rechttoe rechtaan. Het moeilijke deel is begrijpen welke data er is, wat het betekent en welke beslissingen het moet ondersteunen. Besteed de eerste dag aan praten met mensen, niet aan code schrijven.
Conclusie: Python als brug
Python is bij uitstek geschikt om de IT/OT-kloof te overbruggen. Het spreekt industriële protocollen, het heeft rijke bibliotheken voor dataverwerking en visualisatie, en het is toegankelijk genoeg dat één engineer de hele pipeline kan bouwen en onderhouden. Je hebt geen team van softwareontwikkelaars nodig of een duur middleware-platform. Een goed gestructureerde Python-applicatie, een message broker en een time-series database kunnen jarenlang opgesloten productiedata ontsluiten.
Het resultaat is niet alleen een mooi dashboard. Het is het vermogen om vragen te beantwoorden die voorheen onbeantwoordbaar waren: Hoe lang heeft machine 3 vorige dinsdag daadwerkelijk gedraaid? Wat is de trend in gemiddelde cyclustijd over de afgelopen maand? Welke dienst heeft het laagste uitvalpercentage? Deze antwoorden sturen betere beslissingen, en betere beslissingen leiden tot betere producten.
Geïnteresseerd in het verbinden van je PLC's met een moderne data-stack? Ik werk met WAGO, Siemens en andere PLC-platformen en kan een complete pipeline opzetten — van protocolintegratie tot een dashboard dat je team daadwerkelijk gaat gebruiken. Neem contact op voor een vrijblijvend kennismakingsgesprek.