Je hebt een architectuur getekend. De diagrammen kloppen, de protocollen zijn gekozen, de netwerksegmentatie staat op papier. Iedereen heeft getekend. En dan sta je op de fabrieksvloer, het is 7 graden, de PLC praat niet met je broker, en de monteur die het paneel heeft bedraad heeft de RS-485 A en B verwisseld.
Welkom bij commissioning 😄
Nu moet ik eerlijk zijn: bij de grote machinebouwers is dit allang geen verrassing meer. Een Siemens, een Rockwell, een ABB — die hebben hun FAT- en SAT-processen zo ver gestandaardiseerd dat commissioning geen onbekend terrein meer is. Honderden projecten, honderden engineers, honderden keer dezelfde fouten gemaakt en in procedures gevangen.
Maar de meeste projecten waar het misgaat, zijn geen standaard machinebouwprojecten. Het zijn startups die hun eerste productielijn optuigen en nog niet weten wat er bij een SAT komt kijken. Het zijn unieke trajecten: een besturingssysteem voor een specifiek proces, een integratie tussen een legacy PLC en een nieuw SCADA-platform, of een monitoringsysteem dat drie leveranciers en twee protocollen moet overbruggen.
Daar is geen volwassen SAT-template dat je zomaar van de plank trekt. Daar moet je zelf nadenken over risico’s, randvoorwaarden, afhankelijkheden en fallback. En precies daar gaat het vaak mis.
Commissioning is het moment waarop je ontdekt of je die puzzel goed hebt opgelost.
Het eerlijkste moment in elk project
Commissioning en Site Acceptance Testing (SAT) zijn de eerlijkste fases in een technisch project. Niet omdat ze laten zien hoe mooi je ontwerp is — maar omdat ze genadeloos blootleggen wat je hebt aangenomen.
Elk architectuurdiagram is een model van de werkelijkheid. En elk model laat dingen weg. Dat is geen fout, dat is de functie van een model. Maar tijdens commissioning betaal je de rekening voor alles wat je hebt weggelaten.
De kabellengte die op papier geen onderwerp was, maar in de praktijk net te lang blijkt voor betrouwbare signaalintegriteit.
De 24V-voeding die na veertig meter kabelrun nog maar 22,3V meet.
De sensor die volgens het datasheet prima functioneert tot 85°C, maar waarvan de behuizing niet bestand is tegen de wekelijkse drukwas van de klant.
Het zijn zelden de grote ontwerpbeslissingen die je parten spelen. Het zijn de randvoorwaarden die niemand heeft uitgesproken omdat ze “vanzelfsprekend” waren.
Twee werelden, één kabel
Het kernprobleem bij commissioning van OT/IT-systemen is dat je twee werelden verbindt die fundamenteel anders denken over tijd, falen en verantwoordelijkheid. In de IT-wereld is een verbinding up of down. Als die down is, heb je redundantie, een fallback of een retry. Deployment is meestal reversibel. Je kunt een rollback doen. In de OT-wereld is een klep open of dicht. Een pomp draait of staat stil. Een verwarming schakelt wel of niet. En als je de verkeerde keuze maakt, loopt er stoom uit, bevriest er een leiding of valt een proces stil. Daar doe je geen rollback.
Tijdens commissioning sta je precies op dat snijvlak. Je test niet alleen of systemen werken — je test of ze samen werken, onder omstandigheden die geen van beide werelden volledig heeft gespecificeerd.
Ik heb dat letterlijk meegemaakt bij het commissionen van een de-icing besturingssysteem voor de luchtinlaat van een energiecentrale. Het systeem moest automatisch de verwarming aansturen op basis van buitentemperatuur en luchtvochtigheid, zodat ijsvorming op het inlaatrooster de centrale niet stillegde. Op papier was het eenvoudig: sensor leest condities, controller berekent risico, actuator schakelt.
In de praktijk liep ik tegen iets aan dat geen enkel architectuurdiagram had gevangen: het verschil tussen de dynamiek van de besturing en de fysica van ijsvorming.
De sensor reageerde in milliseconden. De ijsvorming speelde zich af over minuten. Maar de gevolgen van te laat schakelen waren niet in minuten op te lossen.
Als er eenmaal ijs op het rooster zat, was je te laat. De verwarming moest dus al inschakelen voordat de condities kritiek werden, op basis van een trend die je in de sensordata moest herkennen. Dat inzicht stond niet in het diagram. Het werd pas zichtbaar toen ik met een vochtmeter naast het inlaatrooster stond.
SAT is geen checklist, het is een onderhandeling
De meeste SAT-documenten die ik tegenkom zijn gestructureerd als een veredelde afvinklijst.
Punt 4.3.2: “Verifieer dat het systeem alarm genereert bij sensoruitval.”
Vinkje. Door naar 4.3.3.
Dat is niet wat SAT zou moeten zijn.
SAT is het moment waarop je als engineer de klant laat zien: dit is wat je hebt gekocht, en dit is hoe het zich gedraagt in jouw omgeving, onder jouw condities.
Dat is fundamenteel anders dan een checklist aflopen. Het is een demonstratie van begrip.
En daarbij gaat het lang niet altijd om de techniek. De lastigste SAT-momenten die ik heb meegemaakt gingen niet over systemen die niet werkten, maar over operators die het systeem niet vertrouwden. Technisch klopte alles. Data kwam door. Alarmen triggerden op de juiste drempels. De koppelingen deden wat ze moesten doen.
Maar de mensen die ermee moesten werken waren gewend aan hun eigen manier van kijken, hun eigen ritme, hun eigen informatiebronnen. Een nieuw systeem dat technisch identieke data toonde, maar op een andere manier presenteerde, was voor hen operationeel een totaal andere ervaring.
Dan verschuift de SAT van “werkt het?” naar:
Vertrouwen de gebruikers het genoeg om erop te handelen?
Dat is een vraag die je niet beantwoordt met een testprotocol. Die beantwoord je door naast de operator te gaan staan, te luisteren, en het systeem aan te passen tot het past bij hun manier van werken.
Wat geen architectuurplaat je vertelt
Na genoeg projecten waarin ik met een laptop en een multimeter op locatie heb gestaan, zijn er een paar patronen die steeds terugkomen.
De documentatie liegt, maar niet expres.
Iedereen documenteert met de beste intenties. Maar documentatie beschrijft het systeem zoals ontworpen, niet zoals gebouwd.
Tijdens commissioning ontdek je elke afwijking: de monteur die een kabelgoot anders heeft gerouteerd omdat de originele route geblokkeerd was door een buis die niet op de bouwtekening stond. De PLC die een andere firmwareversie heeft dan gespecificeerd omdat die versie niet meer leverbaar was. De sensor die op een andere plek hangt omdat de oorspronkelijke positie in de praktijk onbereikbaar bleek. Geen van die afwijkingen is per se fout. Maar elk ervan kan je inbedrijfstelling vertragen.
Test niet het systeem, test de integratie.
Elk individueel component is waarschijnlijk al getest door de leverancier. Jouw taak tijdens commissioning is niet om te verifiëren dat een sensor meet of een klep schakelt.
Jouw taak is om te verifiëren dat de hele keten werkt:
sensor → signaal → controller → logica → actuator → fysisch effect → terugkoppeling
Elke overgang tussen componenten is een potentieel faalscenario. Dat is waar je testscenario’s op richt.
Neem een terugtrekplan mee.
Elk commissioning-protocol zou een sectie “fallback” moeten hebben.
Als het nieuwe systeem niet doet wat het moet doen, hoe ga je terug naar de vorige situatie? In IT is dat een rollback. In OT is dat soms letterlijk: draden los, oud systeem weer aanklemmen, handmatig bedienen tot je het probleem hebt opgelost.
Dat plan moet klaarliggen voordat je begint met testen.
De klant test mee, of je faalt.
Commissioning zonder de operator erbij is zinloos. Niet omdat je hun goedkeuring nodig hebt — die komt bij de SAT — maar omdat zij de randvoorwaarden kennen die niet in de specificatie staan.
“Die klep trilt altijd een beetje als de druk boven de 6 bar komt.” “In de winter condenseert er water op die sensorbehuizing.” “Na een stroomuitval moet je die pomp handmatig ontluchten.” Die informatie zit niet in je P&ID. Die zit in de operator.
De waarde die niemand ziet
Commissioning en SAT zijn fases die vaak worden onderschat in projectplanningen. Ze worden ingepland als “twee weken testen” aan het einde van een project, als buffer die je kunt inkorten wanneer de bouw uitloopt.
Dat is precies verkeerd om.
Commissioning is geen restpost. Het is de fase waarin je ontwerp-aannames confronteert met de fysieke werkelijkheid. En die werkelijkheid is altijd rijker, rommeliger en specifieker dan je model.
Ja, dat maakt projecten duur. Vooral bij startups en eerste-keer-opdrachtgevers merk je dat de offerte soms schrikt.
Waarom betaal ik het drievoudige voor een sensor die ik bij een elektronicawinkel voor een tientje kan kopen?
Waarom staan er drie dagen commissioning in de planning voor een systeem met acht sensoren?
Waarom moet daar een engineer bij zijn als alles toch al getest is?
Ik heb een boot, en daar leer je dat antwoord snel. Elk onderdeel op een boot lijkt drie tot vijf keer zoveel te kosten als het equivalent bij de bouwmarkt. Een slangklem. Een schakelaar. Een stuk lijn. Maar als je op zee bent in slecht weer, met twee meter golven en een motor die je terug naar de haven moet brengen, dan wil je niet de goedkope slangklem die na zes maanden zout water loslaat. Dan wil je het onderdeel dat gespecificeerd, getest en geschikt is voor die omstandigheden.
In industriële systemen is dat niet anders.
De sensor die drie keer zo duur is, is niet alleen drie keer zo duur omdat er een merknaam op staat. Hij is duurder omdat hij gekalibreerd wordt geleverd. Omdat de meetonzekerheid gedocumenteerd is. Omdat er een traceerbaar kalibratiecertificaat bij zit. Omdat de fabrikant garandeert dat hij doet wat het datasheet zegt — ook na jaren in een omgeving met trillingen, stof, vocht en temperatuurwisselingen. Die extra kosten zitten niet alleen in het onderdeel. Ze zitten in de zekerheid dat je commissioning niet ontspoort omdat hardware zich anders gedraagt dan gespecificeerd.
En datzelfde geldt voor tijd.
Die drie dagen commissioning zitten niet in het drukken op knoppen. Ze zitten in het doorlopen van de keten. In het vinden van afwijkingen voordat ze productieproblemen worden. In het herkennen van aannames die op papier logisch waren, maar op locatie niet kloppen. In het meenemen van operators, leveranciers en klant in één werkende werkelijkheid.
Commissioning kost tijd — niet omdat je slecht hebt ontworpen, maar omdat de werkelijkheid altijd meer dimensies heeft dan je model. En commissioning kost geld — niet omdat engineers duur zijn, maar omdat je betaalt voor zekerheid op het moment dat het systeem moet werken.
De engineers die hier goed in zijn, zijn niet per se de beste architecten of de beste programmeurs. Het zijn mensen die comfortabel zijn met ambiguïteit. Die een foutmelding op een HMI-scherm kunnen lezen, en tegelijkertijd luisteren naar het geluid dat een pomp maakt. Die weten wanneer een afwijking een bug is, en wanneer het een eigenschap is van de installatie die je moet respecteren.
Het is het minst glamoureuze deel van het vak.
Geen whiteboards. Geen architectuurplaten. Geen clean code.
Gewoon jij, een systeem, en de vraag: werkt dit, hier, nu, voor deze mensen?
Dat is de vraag die ertoe doet.