Skip to content

Bundelen van aanwezige kennis, noden en problematieken (WP1)

1. Inleiding

Het TETRA‑project MLOps4ECM focust op het toepassen van machine learning operations (MLOps) voor edge‑gebaseerde condition monitoring in industriële omgevingen.

Waar veel bedrijven vandaag al experimenteren met data‑analyse en machine learning, blijven de stap naar productie en het duurzaam beheren van modellen op edge hardware vaak moeilijk. Dit project wil die kloof verkleinen door tools, richtlijnen en demonstratoren aan te reiken die aansluiten bij de praktijk van Vlaamse bedrijven.

Werkpakket 1 (WP1) heeft als doel om de startpositie van de begeleidingsgroep en de bredere doelgroep in kaart te brengen. Concreet:

  • Inventariseren we welke kennis er al aanwezig is rond machine learning, DevOps/MLOps en condition monitoring.
  • Brengen we in kaart welke potentiële toepassingen bedrijven voor ogen hebben, met focus op deployment op edge devices.
  • Verduidelijken we de belangrijkste noden en verwachtingen ten aanzien van MLOps voor edge condition monitoring.

De inzichten uit WP1 vormen de inhoudelijke basis voor de verdere werkpakketten (handleidingen, use cases, demonstratoren ...) en dienen tegelijk als terugkoppeling naar de begeleidingsgroep in de vorm van dit rapport.

2. Aanpak

De inventarisatie in WP1 steunt op drie complementaire bronnen: een online bevraging, 1‑op‑1 gesprekken/bedrijfsbezoeken en interne projectbronnen (startvergadering, notities).

2.1 Online aanvangsbevraging

Aan het begin van het project werd een online vragenlijst verstuurd naar de leden van de begeleidingsgroep.

De bevraging peilde onder meer naar:

  • huidige ML‑toepassingen en gebruikte softwaretools,
  • aanwezige kennis rond machine learning, DevOps, MLOps en condition monitoring,
  • lopende projecten rond condition monitoring met ML,
  • reeds draaiende ML‑modellen in operations en hoe die vandaag onderhouden / gemonitord worden,
  • typische toepassingen en hardwareplatformen waarop bedrijven modellen willen laten draaien,
  • noden en verwachtingen ten aanzien van het project (gewenste outputs, workshops, documentatie).

De antwoorden van de deelnemende organisaties dienden als eerste, gestandaardiseerde snapshot van kennis, toepassingen en noden op het moment van projectstart.

2.2 1‑op‑1 gesprekken en bedrijfsbezoeken

Op basis van de bevraging werden met een aantal bedrijven 1‑op‑1 gesprekken georganiseerd (voornamelijk via Teams, enkele ook on‑site).

In deze gesprekken werd dieper ingegaan op:

  • de concrete context van het bedrijf (sector, type producten of diensten, rol in de waardeketen),
  • bestaande ervaring met machine learning (vision, tijdsreeksen, andere) en data‑engineering,
  • bestaande DevOps‑praktijken en infrastructuur (versiebeheer, CI/CD, containerisatie, monitoring),
  • hardware‑omgeving voor deployment (PLC, IPC, embedded Linux, microcontrollers, GPU/NPU, cloud),
  • praktische uitdagingen rond deployment en onderhoud (connectiviteit, realtime‑eisen, schaalbaarheid),
  • toekomstige noden en de manier waarop zij hopen dat MLOps4ECM hen kan ondersteunen.

Deze individuele gesprekken vormen de gedetailleerde onderbouw van dit onderzoeksrapport.

Naast de bevraging en de 1‑op‑1 gesprekken werden ook de startvergadering en andere contactmomenten gebruikt om de bevindingen te toetsen en aan te vullen.

3. Deelnemende organisaties

3.1 Overzicht van de deelnemende organisaties

De begeleidingsgroep van MLOps4ECM weerspiegelt een breed industrieel ecosysteem rond machine learning en condition monitoring. In het onderzoek zijn volgende types organisaties actief betrokken:

  • industriële eindgebruikers en machinebouwers/OEM's,
  • integratoren en AI/automatisatie‑consultants,
  • technologie‑ en platform-leveranciers,
  • onderwijs‑ en onderzoeksinstellingen.

Deze mix is cruciaal voor het projectdoel: MLOps‑methoden en tools moeten tegelijk relevant zijn voor bedrijven die de technologie bouwen, de technologie integreren én de technologie uiteindelijk inzetten op de werkvloer, met ondersteuning vanuit onderwijs en onderzoek.

3.2 Typologie van de organisaties

Om de resultaten van de bevraging en de gesprekken bruikbaar te structureren, delen we de deelnemende organisaties in vier hoofdgroepen in. Elke groep heeft een eigen invalshoek op MLOps voor edge condition monitoring.

  1. Industriële eindgebruikers en machinebouwers/OEM's
    Dit zijn bedrijven die machines en productielijnen ontwerpen of uitbaten, vaak met sterk mechanische en procesmatige expertise:
    • bedrijven die zelf machines of toestellen bouwen voor bijvoorbeeld textiel, voeding of landbouwvoertuigen,
    • productiebedrijven die complexe continue processen of installaties beheren. Hun focus ligt op betrouwbaarheid, efficiëntie en onderhoudbaarheid van machines, met ML als middel om kwaliteit en beschikbaarheid te verbeteren.
    • Voorbeelden in dit project: Araani, Bekaert, CNH Industrial, L.E.T. Automotive, MARELEC, Summa nv, Televic, Vandewiele
  2. Integratoren en AI/automatisatieconsultants
    Dit zijn engineeringbedrijven die oplossingen bouwen op maat van eindklanten:
    • integratie van PLC/IPC‑gebaseerde automatisatie met vision of sensordata,
    • ontwikkeling van ML‑modellen en pipelines als onderdeel van grotere projecten,
    • advies rond architectuur, data‑platformen en tooling. Zij hebben doorgaans een brede kijk op technologie en tooling, en zien veel verschillende omgevingen bij klanten.
    • Voorbeelden in dit project: CTRL Engineering, Leap Technologies, Orise (Yazzoom), Superlinear (Radix), Vintecc
  3. Technologie‑ en platformleveranciers
    Dit zijn leveranciers van:
    • industriële hardwareplatformen (PLC's, IPC's, edge devices),
    • software‑ en MLOps‑platformen voor deployment en monitoring van AI‑modellen in industriële context. Ze bieden generieke bouwblokken aan (hardware, runtimes, modelmanagers, monitoringtools) die door integratoren en eindgebruikers ingevuld worden.
    • Voorbeelden in dit project: Beckhoff Automation, Siemens
  4. Onderwijs‑ en onderzoeksinstellingen
    Hogescholen en universiteiten die:
    • praktijkgericht onderzoek doen rond AI, edge computing en automatisatie,
    • opleidingen aanbieden waarin DevOps, ML en edge‑technieken aan bod komen,
    • fungeren als brug tussen de academische stand van zaken en industrieel toepasbare oplossingen.
    • Voorbeelden in dit project: KU Leuven, VIVES, Howest, Odisee, Thomas More

In de volgende hoofdstukken spreken we zoveel mogelijk in termen van deze categorieën, zodat individuele antwoorden van bedrijven niet herleidbaar zijn tot bedrijfsgevoelige uitspraken, maar de grote lijnen per groep duidelijk worden.

4. Aanwezige kennis, infrastructuur, toepassingen en noden

Dit hoofdstuk bundelt de belangrijkste bevindingen uit de bevraging en de gesprekken. De structuur volgt de kernonderdelen van WP1: aanwezige kennis, technische infrastructuur, huidige en potentiële toepassingen, en de belangrijkste noden.

4.1 Kennis rond machine learning en data‑analyse

Over de vier categorieën heen zien we een sterke variatie in maturiteit rond machine learning:

  • Bij integratoren en AI‑consultants is ML‑kennis doorgaans goed uitgebouwd:
    • ervaring met supervised en unsupervised learning voor zowel vision als tijdsreeks‑toepassingen,
    • gebruik van moderne frameworks zoals PyTorch en TensorFlow,
    • inzet van eigen platforms voor anomaly detection en procesoptimalisatie,
    • routine in het werken met grote datasets en verschillende dataformaten (bijvoorbeeld COCO voor vision).
  • Bij technologie‑ en platformleveranciers is ML‑kennis vaak gekoppeld aan hun eigen oplossingen:
    • uitgewerkte stacks voor AI‑inference op edge devices,
    • voorbeelden en oplossingen voor predictive maintenance en kwaliteitscontrole,
    • diepgaande kennis van de performantie‑impact van modellen op specifieke hardware.
  • Bij eindgebruikers en OEM's is de situatie gemengd:
    • sommige hebben al concrete ML‑toepassingen in productie (bijvoorbeeld vissoort‑detectie, predictive maintenance op motoren of aandrijvingen),
    • andere bevinden zich in een verkennende fase, met beperkte interne ML‑expertise en/of afhankelijkheid van externe partners.
  • Onderwijs‑ en onderzoeksinstellingen beschikken over methodologische kennis en onderzoeksresultaten, maar willen deze verder vertalen naar repliceerbare industriële workflows en voorbeeldcases.

Samengevat: in de doelgroep is voldoende ML‑kennis aanwezig om betekenisvolle cases uit te werken, maar die kennis is ongelijk verdeeld. Integratoren en platformleveranciers lopen voorop, sommige eindgebruikers en OEM's willen vooral aansluiting vinden bij wat "state of the art maar haalbaar" is.

4.2 Kennis rond DevOps, CI/CD en software‑infrastructuur

DevOps‑ervaring blijkt een belangrijke troef, maar is net als ML‑kennis asymmetrisch verdeeld:

  • Verschillende organisaties (vooral integratoren, OEM's met sterke softwareteams en platformleveranciers) rapporteren ervaring met DevOps‑praktijken:
    • versiebeheer met Git, GitLab, Azure DevOps,
    • CI/CD‑pipelines voor build, test en deployment van software,
    • gebruik van Jenkins of GitLab CI voor geautomatiseerd testen,
    • eerste stappen in containerisatie met Docker of Kubernetes voor ontwikkeling en/of deployment.
  • Een andere groep (voornamelijk klassieke productiebedrijven en kleinere eindgebruikers) heeft wel ervaring met softwaredeployment en IT‑beheer, maar minder met moderne DevOps‑tools en ‑processen:
    • updates gebeuren vaak nog manueel,
    • logging en monitoring zijn minder gestandaardiseerd,
    • releasebeheer is deels ad‑hoc of sterk gekoppeld aan hardware‑cycli.

Belangrijk is dat meerdere bedrijven expliciet aangeven dat ze DevOps‑kennis in huis hebben, maar dat de stap naar MLOps (data‑ en modelversiebeheer, experiment‑tracking, modelmonitoring, retraining) nog in opbouw is.

Dit bevestigt dus de hypothese uit de aanvraag: MLOps4ECM kan bouwen op bestaande DevOps‑praktijken, maar moet helpen om die uit te breiden naar het ML‑domein.

4.3 Kennis rond MLOps‑specifieke aspecten

MLOps‑specifieke kennis (model lifecycle management, monitoring, retraining en tooling) bevindt zich bij de meeste bedrijven nog in een vroeg stadium, met enkele duidelijke voorlopers:

  • Enkele partijen gebruiken al experimenteer‑ en trainingsplatformen zoals DeterminedAI, Neptune of eigen tooling voor experiment‑tracking, data‑beheer en modeltraining.
  • Er zijn voorbeelden van modelmonitoring en driftdetectie in centrale omgevingen (bijvoorbeeld binnen een eigen anomaly‑detectieplatform), maar minder op resource‑beperkte edge devices.
  • Platformleveranciers bieden gestandaardiseerde MLOps‑componenten aan (model managers, inference servers, monitoringscomponenten) die specifiek ontworpen zijn voor industriële omgevingen.
  • Tegelijk geven veel bedrijven aan dat:
    • automatische deployment van modellen nog niet is uitgewerkt, of slechts gedeeltelijk,
    • gestructureerde monitoring van modelperformantie en datadrift ontbreekt of sterk manueel is,
    • er nood is aan praktische best practices voor MLOps op de edge.

Er is een duidelijke vraag naar concrete MLOps‑flows: hoe van data en experimenten naar betrouwbare, beheersbare deployment en monitoring gaan, in omgevingen waar connectiviteit en resources beperkt zijn.

4.4 Kennis rond condition monitoring en sensortechnologie

Wat betreft condition monitoring is de kennis in de doelgroep over het algemeen sterk aanwezig, zeker bij eindgebruikers, OEM's en integratoren:

  • Er lopen projecten rond:
    • trillingsanalyse van motoren en aandrijvingen,
    • monitoring van stroom‑ en spanningsprofielen,
    • gebruik van accelerometers, temperatuur‑ en andere proces‑sensoren,
    • kwaliteitscontrole via vision in productieomgevingen.
  • Verschillende bedrijven hebben ervaring met:
    • het plaatsing en kiezen van sensoren,
    • het interpreteren van signalen en tijdsreeksen,
    • het opzetten van data‑logging‑infrastructuur (lokaal of op een server).

In veel gevallen is de stap naar ML‑gebaseerde condition monitoring logisch maar nog niet volledig gezet: de sensoren en datastromen zijn aanwezig, maar de systematische koppeling met ML‑modellen en MLOps‑processen dient verder uitgewerkt te worden.

4.5 Typische hardware‑ en systeeminfrastructuur

De hardware‑ en systeemomgeving bij de deelnemende organisaties is zeer uiteenlopend, wat de relevantie van een MLOps‑for‑Edge perspectief bevestigt:

  • PLC's en industriële PC's (IPC's)
    • Veel bedrijven werken met PC‑based PLC‑platformen en industriële PC's voor real‑time besturing en data‑verwerking.
    • ML‑inference gebeurt vandaag al op IPC's voor sommige vision‑toepassingen. PLC‑integratie van ML is in opbouw.
  • Embedded Linux‑systemen en GPU/NPU‑devices
    • Embedded Linux‑boxen, soms met GPU of NPU, worden gebruikt voor zwaardere ML‑taken of vision op de edge.
    • Er is belangstelling voor Jetson‑achtige systemen en vergelijkbare hardware om inference dichter bij de bron uit te voeren.
  • Microcontrollers
    • Voor bepaalde toepassingen (bijvoorbeeld eenvoudige time‑series‑analyse, counting, basic anomaly detection) is er interesse in microcontroller‑gebaseerde oplossingen, al zijn concrete deployments nog beperkt.
  • Cloud en centrale servers
    • Training gebeurt meestal op krachtige servers of in de cloud.
    • De combinatie van centrale training en edge‑deployment is een terugkerend patroon.
  • Connectiviteit
    • In meerdere sectoren (schepen, voertuigen, treinen) is connectiviteit onregelmatig of beperkt:
      • modellen moeten offline kunnen blijven werken,
      • data kan slechts gespreid of batchgewijs gesynchroniseerd worden,
      • updates verlopen via gecontroleerde vensters (bijvoorbeeld in haven, depot, onderhoudsstop).

Deze diversiteit aan hardware en connectiviteitseisen onderstreept de nood aan flexibele MLOps‑patronen, die niet enkel voor always‑online datacenters gelden, maar specifiek rekening houden met edge‑constraints.

4.6 Huidige ML‑toepassingen en deploymentpraktijken

Binnen de doelgroep zien we twee dominante toepassingsfamilies:

  • Vision‑toepassingen
    • kwaliteitscontrole en sortering in de voedingsindustrie,
    • visuele inspectie op testmachines of R&D‑lijnen,
    • detectie en classificatie van objecten, componenten of defecten.
  • Tijdsreeks‑toepassingen
    • condition monitoring van motoren, pompen en aandrijvingen,
    • analyse van trillingen, stroom‑ en spanningssignalen,
    • gebruik van multi‑sensor‑data (accelerometers, temperatuur, GNSS/IMU, ...) in bijvoorbeeld railtoepassingen.

Qua deploymentpraktijken:

  • Veel modellen draaien vandaag op centrale servers of industriële PC's in of nabij de installatie.
  • Deployment op PLC's of resource‑beperkte edge devices is in opkomst, maar vraagt nog optimalisatie (modelgrootte, realtime‑gedrag, integratie in bestaande besturingslogica).
  • Cloud‑only oplossingen zijn voor condition monitoring vaak minder wenselijk vanwege latency, bandbreedte of vertrouwelijkheid. Hybride architecturen (edge‑inference met periodieke sync naar een centrale omgeving) zijn een concept dat vaak werd aangehaald.

Hoewel we hier niet mikken op een volledig overzicht van alle toepassingen, is duidelijk dat de combinatie ML + edge + condition monitoring in meerdere sectoren al concreet is, zij het vaak nog met een beperkte of ad‑hoc MLOps‑omkadering.

4.7 Noden en verwachtingen

Over de verschillende categorieën heen keren een aantal noden en verwachtingen telkens terug:

  • Conceptueel en pragmatisch kader voor MLOps
    • helder overzicht van de bouwstenen van een MLOps‑flow voor edge condition monitoring,
    • best practices rond lifecycle‑beheer, model-updates en monitoring in een industriële context.
  • Tooling‑en infrastructuurnoden
    • inzicht in welke open‑source en commerciële tools relevant zijn in welke situatie,
    • voorbeelden van combinaties van tools (data‑versiebeheer, experiment‑tracking, modelregistry, deployment, monitoring),
    • architecturen voor typische hardware‑scenario's (PLC/IPC, embedded Linux, microcontroller).
  • Voorbeelden, handleidingen en workshops
    • concrete hands‑on voorbeelden die aansluiten bij de realiteit van de bedrijven (vision, tijdsreeks, beperkte connectiviteit),
    • handleidingen die niet enkel tools tonen, maar ook de afwegingen en trade‑offs duidelijk maken,
    • workshops die bedrijven toelaten om met hun eigen context in het achterhoofd met MLOps‑concepten te experimenteren.
  • Rol en bijdrage van de verschillende categorieën
    • eindgebruikers en OEM's willen vooral haalbare use case zien die zij (eventueel met partners) kunnen adopteren,
    • integratoren zoeken naar herbruikbare blokken en duidelijke grenzen tussen verantwoordelijkheden (wie beheert wat?),
    • technologieleveranciers willen hun platformen gepositioneerd zien binnen een breder MLOps‑ecosysteem,
    • onderwijs‑ en onderzoeksinstellingen willen de resultaten kunnen vertalen naar onderwijs en lange‑termijn onderzoeksagenda's.

De doelgroep is duidelijk niet zozeer op zoek naar één "magische tool", maar naar praktijkgerichte MLOps‑patronen die toepasbaar zijn op verschillende hardware‑ en organisatieprofielen.

5. Synthese

De voorgaande bevraging laat toe om de uitgangssituatie van de begeleidingsgroep rond MLOps voor edge condition monitoring scherp te stellen:

  • Er is een brede en diverse groep organisaties betrokken, gaande van eindgebruikers en OEM's, over integratoren en platformleveranciers, tot onderwijs‑ en onderzoeksinstellingen. Deze mix garandeert dat de projectresultaten relevant zullen zijn over de volledige industrie heen.
  • De kennisbasis rond machine learning en DevOps is reëel maar ongelijk verdeeld: integratoren en technologieleveranciers lopen voorop, een deel van de eindgebruikers en OEM's staat nog aan het begin. MLOps‑specifieke praktijken (lifecyclebeheer, modelmonitoring, retraining) zijn vaak nog beperkt of ad‑hoc.
  • Op vlak van hardware en infrastructuur is er een duidelijke focus op industriële PC's, PLC's en embedded Linux‑systemen, met groeiende interesse in GPU/NPU‑edge devices en microcontrollers. Connectiviteit is niet altijd gegarandeerd, wat edge‑gerichte MLOps‑patronen essentieel maakt.
  • De huidige en potentiële toepassingen situeren zich vooral in vision en tijdsreeks‑gebaseerde condition monitoring, met concrete vragen rond schaalbare deployment, betrouwbaarheid en onderhoudbaarheid van modellen op de edge.
  • De belangrijkste noden en verwachtingen gaan over:
    • een helder en pragmatisch MLOps‑kader voor edge condition monitoring,
    • inzicht in tooling‑combinaties en voorbeeld architecturen,
    • concrete handleidingen en workshops die de kloof dichten tussen theorie en industriële realiteit.

Deze bevindingen bevestigen de relevantie van de plannen uit het aanvraagdossier. Dit rapport levert de praktijkgebonden inventarisatie waarop de verdere werkpakketten kunnen bouwen.