Een productiedirecteur met wie we vorig jaar spraken, had een eenvoudige vraag: "Hoeveel maanden duurt het voordat uw AI-systeem de eerste motor voor een storing behoedt?" Het antwoord was ongemakkelijk maar eerlijk: dat hangt ervan af hoe lang u al data verzamelt. Minder dan zes maanden — dan is een jaar waarschijnlijk nog niet genoeg.
Voorspellend onderhoud (Predictive Maintenance, PdM) behoort tot de domeinen waar AI/ML aantoonbare resultaten levert. Een reductie van ongeplande uitvaltijd met 30 – 50 % is een getal dat terugkeert in projecten uit uiteenlopende industriële sectoren. Tegelijkertijd is dit een domein waar marketing-hype en werkelijke productieresultaten verder uit elkaar liggen dan waar ook. Dit artikel schetst waar een ML-model echt waarde toevoegt, aan welke datavoorwaarden u moet voldoen en wanneer het verstandiger is te beginnen met regelgebaseerde logica.
Wat voorspellend onderhoud werkelijk oplost
Traditioneel onderhoud werkt in twee modi: reactief (u repareert na een storing) en preventief (u vervangt op basis van een tijdschema, ongeacht de werkelijke staat). Beide hebben duidelijke zwaktes — reactief onderhoud genereert ongeplande stilstand, preventief onderhoud leidt tot voortijdige vervanging van onderdelen die nog jaren mee hadden kunnen gaan.
Voorspellend onderhoud voegt een derde modus toe: u grijpt in op het moment dat een machine daadwerkelijk begint te degraderen, niet eerder en niet later. In de praktijk betekent dit:
- Continue dataverzameling via sensoren (trillingen, temperatuur, akoestische emissie, stroomspectrum)
- Anomaliedetectie of directe schatting van de resterende levensduur (RUL — Remaining Useful Life)
- Waarschuwing aan operators met een voorsprong van doorgaans 3 – 14 dagen vóór de verwachte storing
Het werkt goed op machines met een goed gekarakteriseerd degradatieproces — lagers, elektromotoren, compressoren, pompen, tandwielkasten. Juist bij deze typen machines zijn de frequentiespectren van trillingen een betrouwbare informatiedrager over slijtage.
Waar een ML-model werkelijk waarde toevoegt
Anomaliedetectie zonder labels
Het meest universele startpunt is het trainen van een model uitsluitend op de normale toestand van de machine. Het model leert de verdeling van het "gezonde" signaal, en iedere afwijking — ook een die nog niemand eerder heeft gezien — activeert een alert. Technisch gaat het om autoencoders of methoden zoals Isolation Forest, of Vision Transformers getraind op trillingsspectragrammen.
Voordeel: u heeft geen historische faaldata nodig. Nadeel: een hogere false positive-rate in de eerste maanden, totdat de drempelwaarden zijn gekalibreerd op de specifieke machine.
Foutclassificatie en RUL-schatting
Als u voldoende historische data heeft — en dat is het sleutelwoord — kan een model het specifieke type storing classificeren en de resterende levensduur schatten. Hier worden cijfers gehaald van 88 – 97 % nauwkeurigheid bij goed geïnstrumenteerde machines na 6 – 12 maanden dataverzameling. Maar deze cijfers komen uit benchmark-datasets, niet noodzakelijkerwijs uit het eerste jaar in productie bij uw specifieke machine.
Multimodale signaalsamenvoering
De combinatie van trillingen, temperatuur, akoestische emissie en stroomspectrum in één model levert aanzienlijk betere nauwkeurigheid dan benaderingen met één sensor. In de praktijk betekent dit meer sensoren en een robuustere datapipeline, maar bij kritieke machines is de investering gerechtvaardigd.
Generatieve synthetische data voor zeldzame storingen
Een van de grootste problemen bij PdM: catastrofale storingen zijn zeldzaam. Het model krijgt onvoldoende voorbeelden te zien. De aanpak die bewezen werkt, is het genereren van synthetische failure events met behulp van GAN of diffusiemodellen — zo kunt u de trainingsset kunstmatig uitbreiden op plaatsen waar echte data simpelweg ontbreekt.
Datavoorwaarden — wat de verkoper u niet vertelt
Vóór enige beslissing over het inzetten van een ML-oplossing moeten de volgende vragen worden beantwoord:
- 1.Hoe lang verzamelen we al sensordata? — Minder dan zes maanden betekent een cold start-probleem. Het model weet niet wat "abnormaal" is, omdat het onvoldoende normale toestanden en seizoensgebonden variaties heeft gezien.
- 2.Zijn failure events geregistreerd? — Datums en typen storingen moeten in het systeem staan. Zonder deze data is het onmogelijk een foutclassificatiemodel of RUL-model te trainen.
- 3.Is de data gesynchroniseerd? — Sensoren, SCADA, ERP en onderhoudslogs moeten consistente tijdstempels hebben. Één uur verschil tussen bronnen kan het volledige model ontregelen.
- 4.Wat is de bemonsteringsfrequentie? — Trillinganalyses vereisen typisch honderden Hz. Temperatuur volstaat eenmaal per minuut. Een te laag bemonsteringsfrequentie verhult het probleem.
- 5.Is de data schoon? — Dode sensoren, vastgelopen waarden, communicatieonderbrekingen. Datakwaliteit is in de praktijk een groter probleem dan de keuze van het model.
We hebben projecten gezien waarbij een bedrijf betaalde voor een ML-platform voordat de dataverzamelingspipeline op orde was. Het resultaat: het model werd getraind op ruis en de eerste alarmen waren false positives. Dat ontneemt klanten snel het vertrouwen in het systeem — een slechtere situatie dan wanneer PdM helemaal niet bestond.
Wanneer een eenvoudiger regel volstaat
Een ML-model is niet altijd de juiste keuze. Er zijn scenario's waarbij een regelgebaseerd systeem of statistische procescontrole (SPC) hetzelfde of een beter resultaat levert voor een fractie van de kosten:
- Machines met ondubbelzinnige drempelwaarden — als een motor opwarmt tot 95 °C, is dat een alarm. Daarvoor heeft u geen neuraal netwerk nodig.
- Nieuwe machine zonder historische data — een model heeft niets om op te trainen, regels werken vanaf dag één.
- Weinig machines van hetzelfde type — ML-modellen presteren slecht bij een kleine steekproef.
- Gereguleerde processen met auditeerbaarheid — de regel "alarm bij overschrijding van X" is eenvoudig uit te leggen aan een toezichthouder. Een black-box model veel minder.
De verstandige weg: begin met regels en SPC, verzamel data, en wanneer u 12+ maanden geschiedenis heeft met voldoende failure events — dan loont het om ML te overwegen.
ROI-realiteit: wat u wel en niet moet meetellen
Marketingmateriaal vermeld een reductie van ongeplande uitval met 30 – 50 %. Deze cijfers zijn realistisch — maar het kost tijd om ze te bereiken. Een realistische ROI-berekening moet rekening houden met:
Aan de batenkant: - Lagere kosten per ongeplande stilstand (uurtarief van de lijn × gemiddelde uitvalduur × frequentie) - Verlengde levensduur van onderdelen — minder voortijdige vervangingen - Lagere veiligheidsvoorraden van reserveonderdelen
Aan de kostenkant: - Sensorinfrastructuur (retrofitting van oude machines is kostbaar) - Datapipeline en integratie met SCADA/ERP - Licenties of interne ontwikkeling van het ML-platform - Tijd voor modelkalibratie — de eerste 3 maanden met false positives zijn weinig productief - Doorlopend modelbeheer (drift, nieuwe machines, firmware-updates)
Op basis van tientallen implementaties zien we dat de break-even doorgaans pas in jaar 2 – 3 valt, niet in jaar 1 — wanneer vanaf nul wordt geïmplementeerd. Als u een bestaand OPC-UA- of SCADA-systeem heeft met schone historische data, kunt u sneller zijn.
Hiermee hangt ook de budgetvraag voor hardware samen — meer hierover in het artikel AI Copilot voor operators, waar we de economie van edge AI-apparaten bespreken.
Integratie met bestaande systemen
Voorspellend onderhoud is geen geïsoleerde module — het moet worden aangesloten op uw bestaande systemen:
- CMMS/EAM (Computerized Maintenance Management System) — een PdM-alert moet automatisch een work order genereren, niet alleen een melding in een dashboard. Als een operator het alarm handmatig moet overtypen in het CMMS, wordt het systeem al snel niet meer gebruikt.
- SCADA / OPC-UA — standaardprotocollen voor industriële data; de meeste moderne PdM-platforms ondersteunen deze native.
- ERP — de koppeling met bestellingen van reserveonderdelen is essentieel voor een gesloten keten.
Een architectuur waarbij PdM als silo staat met een eigen dashboard zonder koppeling aan operationele processen, is een van de meest voorkomende oorzaken waarom projecten de verwachte ROI niet halen. Over de integratie van BMS-systemen met de SCADA-laag leest u meer in het artikel over BMS, KNX en Loxone.
Digitale tweeling en multi-agentbenaderingen
In de huidige generatie PdM-oplossingen duikt een nieuwe architectuur op: de digitale tweeling van een machine gecombineerd met AI-agents. In plaats van één classificatiemodel heeft u een netwerk van agents — één verzamelt en reinigt data, een tweede classificeert het type degradatie, een derde simuleert de resterende levensduur op een fysisch machinemodel, een vierde genereert aanbevelingen voor het technisch personeel.
Deze aanpak is krachtiger dan een enkelvoudig ML-model, maar ook kostbaarder om te implementeren en te opereren. Het loont waar de machine voldoende waardevol is (CNC-centrum, turbine, compressorstation) en waar een verkeerde voorspelling werkelijk hoge kosten met zich meebrengt. Voor gewone pompen in een secundaire kring is het overdimensionering.
Over de architecturen van multi-agentsystemen schrijven we uitgebreider in AI in de praktijk: multi-agentsystemen.
Voorspellend onderhoud vs. AI-visuele inspectie — waar ligt de grens
Voorspellend onderhoud en visuele inspectie zijn twee verschillende domeinen, ook al vallen beide onder "AI in de industrie". PdM werkt met tijdreeksen van sensordata en beantwoordt de vraag wanneer een machine uitvalt. Visuele inspectie werkt met beeldmateriaal en beantwoordt de vraag of een specifiek onderdeel al dan niet een defect heeft. Meer over visuele inspectie vindt u in AI visuele kwaliteitscontrole.
Interessant is dat deze domeinen beginnen samen te vloeien — trillingsspectragrammen worden verwerkt door visuele modellen (CNN), camerasystemen volgen tegelijkertijd temperatuurprofielen. Multimodale samenvoering is de richting waar het hele vakgebied naartoe beweegt.
Veelgestelde vragen
Hoe lang duurt het voordat een PdM-systeem betrouwbaar functioneert?
Reken in de praktijk op 6 – 12 maanden vanaf de start van de dataverzameling tot de eerste betrouwbare voorspellingen. De eerste 3 maanden worden gekenmerkt door een hogere false positive-rate (circa 10 – 15 %), totdat het model is gekalibreerd op de specifieke machine en haar operationele cycli. Deze tijd kan worden verkort als u archief-historische data uit het SCADA-systeem heeft — maar die moet schoon en gesynchroniseerd zijn met de onderhoudslogs.
Zijn gewone industriële IoT-sensoren voldoende voor PdM?
Sensoren zijn slechts de eerste stap. Even belangrijk is het waarborgen van consistente tijdsynchronisatie, betrouwbare gegevensoverdracht zonder uitval, en correcte opslag met een retentie van minimaal 2 jaar. De meeste mislukkingen bij PdM-projecten hangen niet samen met de modelkeuze, maar met een gebrekkige datapipeline — dode sensoren, vastgelopen waarden, tijdsverschuivingen tussen bronnen.
Wanneer is ML zinvoller dan regels?
Een ML-model loont wanneer u ten minste 12 maanden schone sensordata heeft met voldoende geregistreerde failure events, een voldoende aantal machines van hetzelfde type, en een degradatieproces dat niet triviaal kan worden gevangen door een eenvoudige drempelwaarde. Voor machines met een ondubbelzinnige grenswaarde (temperatuur, druk, stroom) zijn regels eenvoudiger, auditierbaarder en even effectief.
Wat is de werkelijke voorspellingsnauwkeurigheid?
Onder ideale omstandigheden — een goed geïnstrumenteerde machine, 6 – 12 maanden data, terugkerende storingstypen — worden waarden van 88 – 97 % nauwkeurigheid gerapporteerd. Deze cijfers zijn voornamelijk afkomstig uit benchmark-datasets en gecontroleerde studies. In het eerste jaar van echte productie bij nieuwe machines moet u rekenen op een lagere nauwkeurigheid, totdat het model seizoensgebonden variaties en verschillende bedrijfsmodi heeft geabsorbeerd.
Moet ik het volledige CMMS-systeem vervangen om PdM te kunnen inzetten?
Nee. De meeste moderne PdM-platforms kunnen via API of standaardconnectoren worden geïntegreerd in bestaande CMMS- en ERP-systemen. Het is essentieel dat een PdM-alert automatisch een work order genereert — handmatig overtypen is op lange termijn onhoudbaar. Als uw CMMS geen API heeft, bestaan er doorgaans middlewareoplossingen die deze brug slaan zonder dat het systeem vervangen hoeft te worden.
*Als u overweegt of en hoe u voorspellend onderhoud in uw productie wilt inzetten, beoordelen wij graag de staat van uw sensorinfrastructuur en data — en vertellen u rechtstreeks of het zinvol is te beginnen met ML, of dat een andere stap meer voor de hand ligt. Neem contact met ons op voor een vrijblijvend adviesgesprek.*