Drie dromen voor een andere fabriek

Er zijn drie dingen die iedereen die ooit een industriële machine heeft opgestart zich minstens één keer heeft afgevraagd. Drie dingen die niet hardop worden gezegd omdat ze utopisch lijken. Dit artikel zet ze op een rij.

Een scène, om mee te beginnen

Nachtdienst, afdeling X. Een lijn stopt. Het HMI-paneel toont een code: E-1423. De handleiding staat in een kast op drie gebouwen afstand. De technicus die die machine kent, is op vakantie. De operator heeft twee opties: de helpdesk bellen – die misschien de volgende ochtend reageert – of gokken. In de hele geïndustrialiseerde wereld herhalen zich 's nachts honderden keren scènes als deze.

Het probleem is niet dat er een handleiding ontbreekt. Er zijn er te veel. Het probleem is dat de machine heel goed weet wat ze nodig heeft – de druksensor vertelt haar al dertig seconden dat er iets mis is – maar ze kan geen taal spreken die de operator begrijpt, en als ze dat wel kan, vertelt ze het probleem in plaats van de oplossing. "Druk buiten bereik" is geen nuttige zin om drie uur 's nachts. "Controleer de V12-klep van het luchtcircuit, deze is waarschijnlijk vastgekleefd" is dat wel.

Hier begint het werk dat we doen. Geen nieuwe PLC. Geen mooiere HMI. Een andere manier om te denken over wat de software zou moeten zijn die een machine in 2026 laat bewegen. En drie vaste ideeën – noem ze gerust dromen – die we proberen bij elkaar te houden.

Droom nummer één: automatiseren zonder te programmeren

Industriële automatisering, zoals die er vandaag de dag uitziet, vereist een zeer specifieke figuur: iemand die kan programmeren in een taal – de IEC 61131-3 familie, met zijn ladder-, function block- en structured text-dialecten – die in de rest van de softwarewereld vrijwel nergens anders wordt gebruikt. Wie die talen kent, is zeldzaam, duur en heeft bijna altijd drie weken achterstand.

De paradox is dat degene die de machine echt kent, vaak niet de programmeur is. Het is de afdelingshoofd, de ervaren onderhoudstechnicus, de integrator die twintig vergelijkbare installaties heeft geïnstalleerd. Deze mensen weten wat de machine moet doen. Ze hebben geen zin om een programmeertaal uit de jaren '90 te leren om dit uit te leggen.

Het idee is om de keten om te draaien. Softwareontwikkelaars schrijven herbruikbare componenten – motion control, sensorbeheer, operationele sequenties – één keer, in moderne en algemene programmeertalen. De machine-integrator programmeert ze niet: hij stelt ze samen, en specificeert mondeling of schriftelijk wat de machine moet doen. Een groot taalmodel – een LLM – fungeert als vertaler: het neemt de functionele specificatie van de integrator en zet deze om in een uitvoerbare configuratie, door de reeds geschreven en geteste componenten te assembleren.

Het is niet de fantasie van "AI die de code voor je schrijft". Het is iets bescheidener en realistischer: AI die je specificatie leest en kiest, uit gecertificeerde componenten, hoe deze te combineren. De kritieke code – die een as met een cyclus van 5 milliseconden beweegt – blijft door een mens worden geschreven, in een taal die determinisme en betrouwbaarheid garandeert. Maar die code wordt één keer geschreven en honderd keer hergebruikt.

Droom nummer twee: de machine die zichzelf kent

Vandaag de dag praten machines weinig, en slecht. Een alarm is een numerieke code. Een diagnose is een reeks LED's. Een log is een binair bestand dat alleen de fabrikant kan openen. De kennis van hoe die machine werkt, met die toleranties, na die duizend cycli, zit in het hoofd van een persoon, of in een PDF ergens.

De tweede droom is dat de machine zichzelf kent. Niet in mystieke zin — in heel concrete zin: de technische documentatie, de procesparameters, typische foutgevallen, de interventieprocedures bevinden zich niet langer in een kast of op een aparte documentenserver, maar in de machine zelf, leesbaar door de eigen software. En als er iets misgaat, zegt de machine niet "fout 1423". Hij zegt "de klep V12 is waarschijnlijk vastgekleefd, je zou die moeten controleren; ondertussen kan ik doorgaan in een gedegradeerde modus met 60% van de snelheid".

Het verschil zit tussen een passief object dat signaleert en een actief object dat voorstelt. De eerste laat het probleem aan de operator over. De tweede pakt het samen met hem aan.

Dit vereist twee niet vanzelfsprekende zaken. Ten eerste dat de kennis van de machine – historisch bewaard in handleidingen, elektrische schema's, CAD-tekeningen en het hoofd van technici – wordt geformaliseerd en geïntegreerd in het systeem. Ten tweede dat het systeem een gesprekspartner heeft die een gesprek kan voeren: opnieuw een LLM, hier gebruikt niet om code te genereren, maar om symptomen te vertalen in begrijpelijke acties, in de taal van degene die voor het paneel staat.

Nogmaals, het is geen magie. Het is gewoon betere, beter geïndexeerde documentatie, en een conversationele interface erbovenop. Maar het verandert alles voor wie de nachtdienst draait.

Droom nummer drie: software die overal draait

De derde droom is de meest technische en, paradoxaal genoeg, de meest politieke. Vandaag de dag is industriële automatisering een wereld van gesloten ecosystemen. Elke grote PLC-fabrikant heeft zijn eigen taal, zijn eigen ontwikkelomgeving, zijn eigen hardware, zijn eigen drivers, zijn eigen netwerk van wederverkopers. Van leverancier wisselen betekent alles opnieuw schrijven.

De ambitie hier is om een softwaresysteem te bouwen dat op generieke hardware draait – een industriële mini-pc, een embedded controller, een server in de kelder – waarbij de hardware wordt gekozen op basis van budget en benodigde prestaties, en niet op basis van welk merk PLC de deal heeft gewonnen. Een Linux besturingssysteem in real-time versie, communicatiekaarten gebaseerd op open standaarden (EtherCAT op alles), softwarecomponenten in moderne talen voor de deterministische delen en in meer flexibele talen voor de niet-deterministische delen.

De regel, en hier wordt de utopie concreet: hardware moet invloed hebben op de prestaties, nooit op de betrouwbaarheid. Dezelfde logica moet op een minder krachtige machine op dezelfde manier werken – alleen langzamer. Als de cyclustijd van 5 naar 10 milliseconden gaat, beweegt de as met dezelfde precisie maar met de halve snelheid. Nooit "bijna gelijk". Nooit "het werkt behalve in dat geval". Hetzelfde systeem, dezelfde beslissingen, dezelfde garanties.

Dit is het punt waarop ervaren ingenieurs beginnen te lachen. Ze weten heel goed dat real-time moeilijk is, dat Linux niet is geboren als een real-time systeem, dat LLM's niet draaien op een Raspberry Pi, en dat het mengen van verschillende talen in dezelfde stack meer valkuilen heeft dan tutorials beloven. Ze hebben gelijk. Maar de richting is die, en de bouwstenen om het te bouwen – de real-time extensies van de Linux kernel, volwassen open-source EtherCAT stacks, LLM's die beginnen te draaien op bescheiden hardware – bestaan, vandaag de dag, voor het eerst allemaal samen.

Waarom "utopie"

Utopie is een eerlijk woord. Geen van deze drie dingen is vandaag de dag een afgewerkt product. De eerste vereist LLM's die betrouwbaar genoeg zijn om in een productieomgeving te worden gebruikt, en we staan nog aan het begin. De tweede vereist een enorme hoeveelheid formalisering van industriële kennis, die vandaag de dag bijna allemaal informeel is. De derde vereist het bouwen van open alternatieven tegenover gesloten ecosystemen die twintig jaar voorsprong hebben.

Maar de drie dromen samen, op een rij gezet, schetsen een duidelijke richting: automatisering waarin hardware een commodity is, software herbruikbaar is, kennis is ingebed in de machine, en de rol van de PLC-programmeur – vandaag de dag een knelpunt van een hele industrie – niet verdwijnt, maar verschuift naar waar het echt nodig is, namelijk het eenmalig schrijven van de basiscomponenten.

In de artikelen die volgen, zullen we de stukken van deze puzzel beschrijven die we aan het bouwen zijn. Eén voor één, zonder te beloven dat de puzzel compleet is. Dat is hij niet. Maar het ontwerp begint zichtbaar te worden.