Waarom het laatste manuele proces voor OT-systemen een pipeline nodig heeft
De kloof tussen hoe OT-teams vandaag implementeren en hoe ze kunnen implementeren, is helemaal geen technologisch probleem. De technologie is er al en het bewijs is overweldigend.
Wat ons dan tegenhoudt om ermee te beginnen? Enkel en alleen de beslissing.
Een boodschap van onze CTO
Bedankt om de tijd te nemen om dit artikel te lezen. We bekijken wat de feiten zeggen, welke platformen ondersteuning bieden en wat een haalbare volgende stap kan zijn.
We zijn benieuwd naar uw mening. Is er een onderwerp dat u graag verder onderzocht ziet? Laat het ons weten.
Blijf nieuwsgierig.
Philip De Keulenaer
Chief Technology Officer bij Agidens
Integratie en implementatie blijven de meest manuele, foutgevoelige en duurste fases van elk SCADA- of PLC-project.
Een decennium aan empirisch onderzoek in IT toont duidelijk aan dat automatisering van pipelines voor integratie en oplevering leidt tot frequentere implementaties, minder fouten en sneller herstel. OT-leveranciers beginnen hierop in te spelen, maar de mate waarin ze daar klaar voor zijn, verschilt sterk.
OT-systemen lopen op deze best practices zo’n 20 jaar achter. Dat roept twee belangrijke vragen op: kan OT de overstap maken naar meer geautomatiseerde pipelines voor integratie en implementatie? En belangrijker nog: moet dat ook?
De manuele realiteit van OT-implementatie
Vraag eender welke SCADA-engineer hoe een verandering van ontwikkeling naar productie gaat en het antwoord is opvallend vaak hetzelfde.
Een engineer ontwikkelt op een lokale kopie van het systeem, die hopelijk goed overeenkomt met wat er effectief in productie draait. Veranderingen worden handmatig vastgelegd, vaak in een Word-document met screenshots.
Implementatie betekent vervolgens inloggen op een ontwikkelstation, logregels één voor één vergelijken met het live-systeem en objecten over het scherm verslepen. Zelfs voor een kleine verandering kan de voorbereiding en implementatie al snel tot vijf keer meer tijd kosten dan de ontwikkeling zelf.
In grotere teams komt daar nog een ander probleem bij: coördinatie. Basisconcepten zoals versiebeheer en het samenvoegen van verschillende codetakken worden nauwelijks ondersteund. Engineers werken op kopieën van systemen en spreken tijdens teammeetings af wie welke blokken, bestanden of schermen mag bewerken. Dat systeem is verre van waterdicht. Daarom worden extra controles ingebouwd, zoals back-ups op SharePoint en gedetailleerde, manueel bijgehouden change logs.
De gevolgen zijn groot. PLC- en SCADA-systemen programmeren brengt verrassend veel administratie rond integratie en implementatie met zich mee. Dat verhoogt de kosten en verlengt de doorlooptijd. Implementaties worden foutgevoeliger, duurder en complexer, waardoor ze ook minder vaak plaatsvinden. Operators moeten daardoor soms maanden wachten op zelfs kleine quality-of-lifeverbeteringen.
Case studies
Kleine veranderingen aan het SCADA-systeem
Een engineer opent Studio 5000 om een kleine verandering uit te voeren voor een klant in de voedingsindustrie.
De ontwikkeling zelf neemt ongeveer een uur in beslag: een nieuw scherm en een handvol logische aanpassingen.
Elke verandering legt ze onderweg vast in een Word-document. Daarin houdt ze bij welke blokken ze heeft aangepast, welke schermen gewijzigd zijn en voegt ze screenshots toe. Alleen al het documenteren neemt meer tijd in beslag dan de ontwikkeling zelf.
Ze test alles op een lokale kopie die gebaseerd is op een drie dagen oude back-up van de productieomgeving. Wanneer het tijd is om te implementeren, logt ze in op het ontwikkelstation van de klant. Vervolgens overloopt ze haar change log item per item naast het live-systeem en versleept ze schermen en objecten van het ene systeem naar het andere. Ondertussen vinkt ze alles zorgvuldig af in haar document. Dit gebeurt rechtstreeks op het live-systeem, terwijl de productie gewoon doorloopt.
Totale tijd: twee dagen. Ontwikkeling: ongeveer één uur. Effectieve implementatie: ongeveer één uur. De rest gaat naar documenteren en zorgvuldig controleren.
Traceerbaarheid van veranderingen
Acht engineers werken aan een groot Wonderware SCADA-project. Ze werken elk aan verschillende delen van de code, voeren wijzigingen door en controleren die aan de hand van een centrale versie.
Wanneer ze inloggen, voert het systeem een compilatie uit om syntaxfouten op te sporen. Verder zijn er geen geautomatiseerde controles en is er geen praktische manier voor een lead engineer om wijzigingen te controleren voordat ze worden samengevoegd.
Op vrijdag implementeert het team een reeks wijzigingen in de productieomgeving. Op maandag meldt operations dat een optie die de week voordien nog correct werkte, zich plots anders gedraagt. De oorzaak: de productieomgeving was enkele weken eerder gepatcht en bevatte een kleine fix die niet meer in het systeem zat. De nieuwe implementatie had die fix overschreven zonder dat iemand het merkte.
Er is geen eenvoudige manier om de geïmplementeerde versie te vergelijken met de productieomgeving. De lead engineer moet reconstrueren wat er gebeurd is aan de hand van SharePoint-back-ups, de change log en wat het team zich nog herinnert van de implementatie.
De simpelste vraag in engineering heeft geen betrouwbaar antwoord: wat is er veranderd?
De geschiedenis herhaalt zich
De realiteit van OT-implementatie vandaag lijkt sterk op die van IT zo’n twee decennia geleden. IT-ontwikkeling heeft sindsdien grote stappen gezet, vooral op het vlak van tools die de integratie, testing en implementatie van nieuwe software ondersteunen.
Daaruit groeide het principe van Continuous Integration & Continuous Deployment (CI/CD): pipelines die steunen op een breed ecosysteem van tools zoals Git voor versiebeheer, Docker voor implementatie in verschillende containers, Jenkins voor pipelines en ELK voor monitoring. Vaak worden die omgevingen beheerd door een gespecialiseerde DevOps-engineer.
Belangrijk onderzoek wijst op twee opvallende vaststellingen bij bedrijven die sterk inzetten op CI/CD:
- Bedrijven die sneller nieuwe features implementeren, ondervinden minder problemen en herstellen sneller dan bedrijven die trager implementeren.
- Uitgebreide goedkeuringstrajecten leiden niet tot minder uitval. Ze zorgen wel voor een langere doorlooptijd, minder frequente implementaties en een langere hersteltijd.
Het is dan ook niet verrassend dat meer dan 80% van de softwarebedrijven CI/CD-werkwijzen gebruikt en dat de markt voor DevOps-engineers jaarlijks met meer dan 20% groeit.
Meer dan 80% van de softwarebedrijven gebruikt CI/CD-werkwijzen en de markt voor DevOps-engineers groeit jaarlijks met meer dan 20%.
Het door Google ondersteunde DORA [1] (DevOps Research & Assessment) onderzoekt de impact van DevOps op de productiviteit van softwareteams. De resultaten zijn opvallend:
- 182 keer meer implementaties per jaar dan laag presterende teams
- 127 keer kortere lead time van aanvang tot productie
- 8 keer lager uitvalspercentage
- 2.293 keer sneller herstel na een mislukte implementatie
Voor wie vertrouwd is met de voorzichtige cultuur van OT voelt dat misschien tegenstrijdig aan: snelheid hoeft niet ten koste te gaan van stabiliteit. De snelste teams blijken net de meest stabiele te zijn. Teams die vaker implementeren, falen minder en herstellen sneller.
In hun invloedrijke boek Accelerate [2] stellen Forsgren, Humble en Kim vast dat externe, formele goedkeuringstrajecten, change advisory boards en manuele sign-offs een negatieve impact hebben op lead time, implementatiefrequentie en hersteltijd. Tegelijk is er geen aantoonbare positieve relatie met het uitvalspercentage.
Manuele goedkeuringen vertragen het proces zonder het veiliger te maken.
Dat betekent niet dat goedkeuring overbodig is in veiligheidskritieke omgevingen. Wel dat die goedkeuring deel moet uitmaken van de pipeline, in plaats van er als een aparte bureaucratische stap bovenop te komen.
[1] dora.dev/research/publications
[2] Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press. — Chapter 4, in the section on change approval processes
Een mogelijke blauwdruk voor een oplossing
De enterprise IT-industrie heeft de basis gelegd om nieuwe software snel, goedkoop en veilig op te leveren via CI/CD-pipelines. De belangrijkste principes daarvan kunnen ook naar OT worden doorgetrokken.
Continuous Integration betekent dat elke verandering, of het nu gaat om een aanpassing aan PLC-logica, een HMI-scherm, een alarmdrempel of een gatewayconfiguratie, wordt vastgelegd in een gedeeld systeem voor versiebeheer.
Bij elke wijziging worden automatisch tests uitgevoerd. Compileert het project? Worden tagreferenties correct opgelost? Zijn de alarmlimieten consistent? Slagen de automatische tests? Fouten worden zo meteen opgespoord en lead engineers kunnen eenvoudig nakijken en reageren op wat hun teams opleveren.
Continuous Deployment betekent dat het traject van ontwikkeling tot productie geautomatiseerd en volledig traceerbaar verloopt. Configuratieverschillen tussen omgevingen worden als code behandeld, in plaats van als manuele stappen. Implementatiescripts plaatsen automatisch de juiste software op de juiste infrastructuur, met volledige logs van alle acties en mogelijke problemen.
De realiteit staat vandaag nog ver af van een echt CI/CD-proces. Twee belangrijke vragen houden de adoptie ervan voorlopig tegen: kan het, en moet het?
Is het technisch mogelijk?
| Ignition 8.3 | TIA Portal | WinCC Unified | Win CC OA | PCS7 | Studio 5000 | TwinCAT 3 | CODESYS | AVEVA Sys. Plat. | |
| Versiecontrole (native text format) | ⚠️ | ⚠️ | ❌ | ✅ | ❌ | 🔧 | ✅ | ⚠️ | ❌ |
| Geautomatiseerde build & validatie | ⚠️ | 🔧 | ❌ | 🔧 | ❌ | ⚠️ | ⚠️ | ❌ | ❌ |
| Test automatisering & simulatie | ⚠️ | ⚠️ | ❌ | 🔧 | ❌ | ⚠️ | ⚠️ | ❌ | ❌ |
| Implementatie automatisering (API) | ✅ | 🔧 | ❌ | 🔧 | ❌ | ✅ | ⚠️ | ❌ | ❌ |
| Config als code / env. management | ✅ | ❌ | ❌ | 🔧 | ❌ | ❌ | ❌ | ❌ | ❌ |
| Container & orchestration | ✅ | ❌ | ❌ | 🔧 | ❌ | ❌ | ❌ | ❌ | ❌ |
Kan het?
Gelukkig hebben OT-leveranciers die evolutie intussen opgepikt. Elk groot platform beweegt richting Git-ondersteuning, tekstgebaseerde formaten en API-gedreven implementatie. Inductive Automation heeft Ignition 8.3 bijvoorbeeld opnieuw ingericht met file-based configuratie en REST API’s. Siemens introduceerde Git-compatibele exports in TIA Portal V21. Rockwell publiceerde dan weer een CI/CD-referentiearchitectuur.
Ondanks de huidige beperkingen liggen er dus ook kansen. Naarmate leveranciers nieuwe mogelijkheden toevoegen, is het aan engineers om die in de praktijk te gaan gebruiken. Zelfs binaire back-ups kunnen in Git worden opgeslagen. Tekstuele exports kunnen, waar ondersteund, met een eenvoudig Python-script gecontroleerd worden op bijvoorbeeld de consistentie van tags. Ook de opkomst van coding agents biedt nieuwe mogelijkheden om complexe OT-codebases te evalueren. Web-based SCADA-systemen kunnen dan weer automatisch getest worden met frameworks zoals Playwright of Cypress.
OT-leveranciers maken CI/CD mogelijk. Engineers moeten deze tools nu vertalen naar werkbare workflows.
Moet het?
Continuïteit is zonder twijfel de grootste prioriteit voor elk OT-systeem. Dat is meteen ook een belangrijk verschil met veel IT-systemen. In OT staat tijd rechtstreeks gelijk aan geld. Dertig minuten productiestilstand kan al snel neerkomen op minstens 2% minder inkomsten voor die dag.
Daar komt bij dat OT-platformen vaak zeer gevoelige fysieke processen aansturen. Als die niet goed beheerd worden, kunnen de gevolgen ernstig zijn, van explosies en vervuiling tot risico’s voor de volksgezondheid. Engineers en klanten hebben daarom terecht de reflex ontwikkeld om zeer voorzichtig om te gaan met veranderingen in de productieomgeving.
Toch lijkt dat op het eerste gezicht in te gaan tegen het DORA-onderzoek dat we eerder bespraken. Snelle en frequente veranderingen leiden daar net tot minder problemen. Kunnen we die les rechtstreeks doortrekken naar OT? Dat weten we vandaag simpelweg niet. De praktijk laat nog niet toe om dat overtuigend te bewijzen.
Een manier om daar verandering in te brengen, is CI/CD stapsgewijs toe te passen. Niet in de eerste plaats om sneller te implementeren, maar om het proces controleerbaar en herhaalbaar te maken. CI/CD zet manuele processen bijvoorbeeld om in uitvoerbare code en verkleint zo het risico op menselijke fouten. Audit logs leggen exact vast wat werd geïmplementeerd, waar en wanneer, waardoor manueel bijgehouden registraties minder nodig worden. Geautomatiseerde codechecks kunnen bovendien helpen om fouten vroeger op te sporen, bijvoorbeeld tijdens FAT- en SAT-procedures.
In OT gaat CI/CD in de eerste plaats niet over sneller implementeren. Het gaat erom elke verandering veiliger, herhaalbaar en volledig traceerbaar te maken.
Ja, we kunnen. En ja, we zouden het moeten doen.
We zijn ervan overtuigd dat CI/CD-processen een plaats hebben binnen OT-ontwikkeling. De industrie beweegt duidelijk in die richting, al gaat verandering in OT traditioneel traag en moeizaam.
We denken dat die evolutie nu aan het versnellen is. AI-gedreven ontwikkeling verlaagt de drempel om nieuwe tools te bouwen die ook met legacyplatformen kunnen werken, bijvoorbeeld voor code-evaluatie, simulatie en testing.
De situatie verandert snel. Wie relevant wil blijven, moet er nu mee aan de slag. Niet door snelheid voorop te zetten, maar door eerst te focussen op veiligheid.
Veiligheid eerst
CI/CD-processen zijn binnen IT vaak een veiligere, snellere en goedkopere manier om software te implementeren. Voor OT moet veiligheid eerst komen. Dat betekent elke verandering bijhouden, bugs vroeg opsporen en controleerbaar bewijs opbouwen dat aansluit bij industriële standaarden.
De voordelen van snellere implementaties en lagere kosten volgen daarna vanzelf.
Start nu
De mogelijkheden worden uiteraard beperkt door wat OT-platformen vandaag toelaten. Toch kunnen er al kleine stappen gezet worden.
Dat kan bijvoorbeeld door een Ignition-project in een Git-repository te beheren of code quality scripts te bouwen bovenop een Rockwell L5X-bestand. Zulke kleine stappen helpen om een CI/CD-werkwijze op te bouwen en maken tegelijk duidelijk waar verdere innovatie nodig is.
Case study: CI/CD voor een gereguleerde MedTech-omgeving
Ignition 8.3 bewaart alle gatewayconfiguraties als bestanden op schijf, in plaats van in een interne database. Daardoor kan alles in Git worden opgenomen: databaseconnecties, tags, schermen, alarm pipelines, gatewayopties enzovoort. Engineers kunnen exact zien wat er veranderd is, wie de wijziging heeft doorgevoerd en waarom, net zoals een softwareteam dat kan.
Een team dat een 21 CFR Part 11-compliant MedTech-applicatie ontwikkelde, gebruikte die mogelijkheid om een volledige CI/CD-workflow op te zetten. Eén Git-repository bevatte alle informatie over de volledige omgeving. Engineers werkten op feature branches, dienden pull requests in voor peer review en voegden goedgekeurde wijzigingen samen in een gedeelde development branch.
Release candidates werden gebouwd, automatisch getest en via dezelfde pipeline geïmplementeerd in een QA-omgeving voor validatie. Daarna werden ze gepromoveerd naar productie. De deployment modes van Ignition maken dat praktisch haalbaar met één repository voor alle omgevingen. De basisconfiguratie blijft dezelfde, terwijl omgevingsspecifieke verschillen, zoals database-endpoints of gesimuleerde apparaten, automatisch worden verwerkt wanneer de gateway draait in development, QA of productie.
Het resultaat: implementaties zijn snel en herhaalbaar. Terugdraaien betekent simpelweg terugkeren naar de vorige Git-commit. Elke wijziging krijgt een volledig audit trail, van feature request tot productie. Precies wat een 21 CFR Part 11-auditor moet kunnen zien. Het team besteedt daardoor meer tijd aan engineering en minder aan documentatie en het manueel migreren van elementen.
Zet het gesprek verder
Laat ons pipelines en werkwijzes creëren die SCADA-implementatie van een zwak punt omvormen tot een sterkte.