Voorspellend onderhoud betekent onderhoud plannen op basis van de werkelijke conditie en het gedrag van een asset, in plaats van op een vaste kalender. Internationaal heet het predictive maintenance, en het steunt op data die de asset en de systemen eromheen vaak al produceren. Daarmee is meteen gezegd wat dit artikel anders maakt dan de meeste stukken over dit onderwerp: het gaat niet over een onderhoudspakket aanschaffen, maar over de data die je al hebt en wat daarvoor nodig is.
Drie vormen van onderhoud, en wat ze kosten
En nu het eerlijke verhaal: voor veel assets is preventief onderhoud gewoon prima. Een vast interval voor iets goedkoops dat zelden faalt, hoef je niet slimmer te maken. Voorspellend onderhoud loont bij assets waar uitval duur of gevaarlijk is: de tunnel, de terminal, het gemaal.
Welke data je nodig hebt (en waarschijnlijk al hebt)
Vier bronnen vormen samen het beeld.
- Sensordata uit de asset zelf. Stroomverbruik, temperatuur, trilling, druk: de signalen die slijtage verraden.
- Logdata uit de besturingssystemen. PLC’s en SCADA registreren schakelmomenten, foutcodes en afwijkingen die je in sensordata alleen niet ziet.
- Netwerktelemetrie. Een installatie die hapert, kondigt zich op het netwerk vaak eerder aan dan in het proces.
- De storingshistorie uit je onderhoudssysteem. Wat ging er eerder kapot, wanneer, en wat ging eraan vooraf? Dit is je referentiemateriaal.
De eerste drie komen meestal al ergens langs, alleen in verschillende systemen met verschillende tijdstempels. Het werk zit niet in het voorspellen, maar in het samenbrengen, en in de vraag hoe je die data veilig uit je OT-omgeving haalt.
Waarom predictive maintenance zelden op het model stukloopt
De meeste voorspellend-onderhoudsprojecten stranden niet op het algoritme. Ze stranden op datakwaliteit, en wel op drie voorspelbare manieren.
- Te weinig storingshistorie om op te trainen. Kritieke assets falen gelukkig zelden, dus zijn er weinig voorbeelden van hoe falen eruitziet.
- Tijdstempels die niet synchroon lopen. Als de sensor, de PLC en het onderhoudssysteem elk hun eigen klok hanteren, kun je oorzaak en gevolg niet meer op één tijdlijn leggen.
- Assets die pas gaan loggen als er al iets mis is. Foutcodes zijn geen conditiedata. Je wilt weten hoe gezond gedrag eruitziet, niet alleen hoe kapot eruitziet.
Onze ervaring, zonder omwegen: met een half jaar goede data kom je verder dan met een geavanceerd model op vuile data. Begin dus bij de data, niet bij het algoritme.
In de praktijk: tunnels en terminals
Vialis past dit toe op een tunnel in de A4. Sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen; webhooks starten vervolgacties zoals het inplannen van onderhoud. Het effect: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de case study Vialis (pdf).
Bij Rotterdam World Gateway (RWG), een van de meest geautomatiseerde containerterminals ter wereld, zat het probleem niet in een gebrek aan data maar aan zichtbaarheid: data lag verspreid over logsystemen, applicaties, leverancierssystemen en OT. Door die stromen in Splunk te correleren ging de start van een probleemanalyse van uren naar minuten en veranderde stilstand van verrassing in beheersing. Lees de case study RWG (pdf).
Een realistisch stappenplan
- Kies een asset waar uitval echt pijn doet. Niet de makkelijkste, maar de duurste storing van vorig jaar.
- Inventariseer welke data die asset nu al produceert. Sensoren, besturing, netwerk, onderhoudssysteem, meestal meer dan je denkt.
- Breng die data samen op één tijdlijn. Zelfde klok, zelfde identifiers. Dit is tachtig procent van het werk.
- Leg de storingshistorie ernaast en zoek patronen met het blote oog. Wat zag je in de dagen voor elke storing? Vaak springt het patroon eruit zonder code.
- Automatiseer pas als je het patroon zelf herkent. Een model moet bevestigen wat jij al snapt. Dit advies krijg je van softwareleveranciers niet, en het scheelt je een mislukt project.
Voorspellend onderhoud is geen product dat je koopt, maar een werkwijze die je opbouwt, en die valt of staat met de continuïteit van kritieke systemen eronder. Voor de servicelaag daarboven is ITSI en service-monitoring het gereedschap.
