Digital-twinsoftware voor productie: een checklist voor kopers

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

Digital-twinsoftware voor productie houdt een model synchroon met live data. Een checklist om platforms, kant-en-klare tools, beveiliging, kosten en onderhoud met elkaar te vergelijken.

Automatically translated with AI from the original post. Read the English original

Digital-twinsoftware voor productie bouwt een model van een machine, een lijn of een fabriek en houdt dat model verbonden met echte data, zodat je kunt zien wat er draait, problemen kunt voorspellen of een wijziging kunt testen voordat je hem doorvoert. Dit artikel is bedoeld voor productiemanagers die aanbiedingen moeten vergelijken die allemaal dezelfde termen gebruiken. Het herhaalt de basis van wat een twin is niet; het geeft je een checklist om software te kiezen, van wat die minimaal moet bevatten tot wat het je kost om hem draaiende te houden.

Belangrijkste punten

• NIST noemt drie essentiële elementen van een twin: hoogfrequente sensordata, betrouwbare industriële IoT-connectiviteit en simulatiemodellen voor voorspellingen. Software moet die dekken of samenwerken met partners die dat doen.
• Azure Digital Twins is een platformservice voor twin-graphs, geen kant-en-klare fabrieksapplicatie. Microsoft zegt bovendien dat het verschilt van de preview van de Fabric digital twin builder.
• Bepaal eerst of je een platform nodig hebt om op te bouwen of een kant-en-klare tool voor een specifieke vraag. Het antwoord bepaalt namelijk wie het werk doet en wat het kost.
• ISO 23247-1 geeft een overzicht en algemene principes van een digital-twinframework voor productie. Dat helpt om met leveranciers een gedeelde woordenschat af te spreken.
• Reken naast licenties ook op kosten voor data-integratie, modelvalidatie en onderhoud, en beperk een eerste pilot tot één lijn en één beslissing.

Wat moet digital-twinsoftware voor productie minimaal bevatten?

Begin met een definitie die leveranciers niet kunnen oprekken. NIST beschrijft een digital twin als een dynamische, datagedreven virtuele voorstelling die het fysieke tegenhangerdeel nauwkeurig repliceert, ermee verbonden is en ermee gesynchroniseerd blijft. Volgens NIST is een twin geen statisch model. Daarnaast noemt het drie essentiële elementen die de getrouwheid, bruikbaarheid en levensduur bepalen: hoogfrequente sensordata, betrouwbare industriële IoT-infrastructuur voor connectiviteit en geavanceerde simulatiemodellen voor voorspellende analyse.

Vertaal die drie elementen naar vragen die je bij elk product kunt stellen:

1. Data erin. Welke bronnen leest het uit: machinebesturingen, sensoren, MES, ERP, spreadsheets? Hoe vaak wordt het ververst? Wie bouwt en onderhoudt elke verbinding?
2. Een model dat betekenis heeft. Hoe is de fabriek beschreven: assets, lijnen, processen, relaties? Kunnen jullie eigen mensen die beschrijving aanpassen als het proces verandert?
3. Analyse erbovenop. Toont het alleen actuele waarden, of kan het voorspellen, simuleren en scenario’s vergelijken? Is dat onderdeel van het product, of is het een apart project?

Voeg daar twee praktische eisen aan toe: mensen moeten de resultaten kunnen lezen (dashboards, rapporten, meldingen), en toegang moet op basis van rollen worden geregeld. Laat een product een van de vijf onderdelen weg, vraag dan wie die levert.

Welke soorten software worden als digital twin verkocht?

Het label digital twin dekt heel verschillende dingen. Verdeel aanbiedingen in vier groepen voordat je prijzen vergelijkt.

• Platforms om op te bouwen. Ze leveren de onderdelen om een model op te slaan, data te koppelen en te bevragen. Jij of een partner bouwt de oplossing er bovenop.
• Kant-en-klare productietwins. Ze komen met een klaar datamodel voor productie, bijvoorbeeld voor planning, simulatie of optimalisatie van een fabriek, en vragen minder ontwikkelwerk.
• Asset- en conditietwins. Ze richten zich op de gezondheid van machines en gebruiken sensordata om slijtage en afwijkingen op te sporen.
• Ontwerp- en inbedrijfstellingstwins. Ze testen indelingen en besturingslogica voordat de apparatuur wordt geïnstalleerd.

Een tool uit de ene groep beantwoordt een andere vraag dan een tool uit een andere groep. Een conditietwin vertelt je niet of een nieuw shiftmodel je achterstand wegwerkt, en een productiesimulatie vertelt je niet wanneer een lager stukgaat. Leg eerst je beslissing vast en kies daarna de groep.

Wat levert een platform als Azure Digital Twins je op?

Azure Digital Twins is het voorbeeld van Microsoft. Volgens Microsoft Learn is het een platform als service voor het bouwen van twin-grafen op basis van digitale modellen van omgevingen, zoals gebouwen, fabrieken of energienetwerken. Je definieert je domeinvocabulaire in de Digital Twins Definition Language (DTDL), een taal die op JSON lijkt, en twins zijn instanties van die modellen. Relaties tussen twins vormen de graf, die je kunt bevragen als een actuele, live weergave. IoT Hub kan apparaatdata leveren, REST-API's en connectors kunnen gegevens uit bedrijfssystemen aanvoeren, en event routes kunnen twindata doorsturen naar andere Azure-diensten voor analyse.

Voor een koper zijn er twee dingen belangrijk. Ten eerste is dit een bouwsteen. Het slaat het model op en verbindt het. De what-if-logica van een productiesimulatie, met wachtrijen, omsteltijden en shiftkalenders, is een ander stuk software, en het resultaat moet je zelf of met een partner ontwikkelen. Ten tweede maakt de pagina duidelijk dat Azure Digital Twins verschilt van de Fabric digital twin builder (preview) en van IoT Hub device twins. Controleer welke van de twee een collega of leverancier bedoelt voordat je er plannen op maakt.

Geschiedenis is een aparte stap. De graf is een live beeld, en de pagina van Microsoft over datageschiedenis legt uit dat je een instantie koppelt aan een Azure Data Explorer-cluster om grafupdates in de tijd vast te leggen, met een Event Hubs-namespace ertussen. Ook staat erin dat berichten die datageschiedenis uitstuurt, worden gefactureerd onder de dimensie berichtenprijs. Met andere woorden: "we willen de trends van vorige maand zien" voegt componenten en een kostenpost toe. Stel elke leverancier dezelfde vraag: waar wordt de geschiedenis opgeslagen en wat kost dat?

Bouw je op een platform of koop je een kant-en-klare tool?

Gebruik deze vragen om te beslissen.

• Hoe specifiek is je vraag? Voor een afgebakende productievraag, zoals capaciteit, bezetting of productmix, komt een kant-en-klare tool meestal sneller tot een antwoord. Voor een brede, langetermijn digitale basis over veel soorten assets geeft een platform meer flexibiliteit.
• Wie gaat het werk doen? Een platform vraagt om ontwikkelaars of een partner. Reken hun tijd mee. Een kant-en-klare tool verschuift het werk naar configuratie en datavoorbereiding.
• Hoe uniek is je proces? Hoe ongebruikelijker je proces, hoe belangrijker een flexibel model wordt. Standaardstromen passen beter bij kant-en-klare tools.
• Hoe lang wil je het gebruiken? Een model dat jaren meegaat, heeft een eigenaar en een budget voor wijzigingen nodig. Vraag wie het bijwerkt wanneer je een productfamilie toevoegt of een lijn verplaatst.
• Wat heb je al in huis? Als je IT-team al een cloudplatform beheert en er een datateam is, past een platformbouw misschien. Als je geen van beide hebt, is een kant-en-klare tool waarschijnlijk de realistischere route.

Voor iedereen is er geen juist antwoord. Veel fabrieken komen uit bij beide: een platform voor de gedeelde datafundering en een kant-en-klare tool voor één specifieke beslissing. Plan de koppeling daartussen vanaf het begin.

Hoe controleer je connectiviteit en standaarden?

Een twin is alleen nuttig als er data binnenkomt en resultaten naar buiten komen. Vraag hoe de software verbinding maakt met apparatuur van verschillende leeftijden en fabrikanten.

Een veelgebruikte route is OPC UA. De OPC Foundation beschrijft het als een manier om data van fabrieks- en procesbesturingsapparaten naar bedrijfssystemen te brengen, met nadruk op beveiliging, betrouwbaarheid en werking over platformen heen, en zegt dat het in 2011 de IEC 62541-standaard werd. Een leverancier die OPC UA spreekt, kan doorgaans veel machines uitlezen zonder maatwerkdrivers, al heeft oudere apparatuur mogelijk gateways of extra sensoren nodig.

Voor het raamwerk zelf is ISO 23247-1 het eerste deel van de norm "Digital twin framework for manufacturing". ISO vermeldt dat het in oktober 2021 is gepubliceerd, met een overzicht en algemene principes, inclusief termen, definities en eisen van het raamwerk. Je digitale twin bouw je er niet mee, maar je team en je leveranciers krijgen er wel dezelfde woordenschat mee. Vraag of de architectuur van een leverancier ernaar verwijst en wat dat in de praktijk betekent, niet alleen in een presentatie.

Vraag ook naar de randen van het systeem:

• Kun je je model en je data exporteren in een open formaat?
• Koppelt het aan je ERP, MES en rapportagetools, bijvoorbeeld Power BI, zonder maatwerk voor elk rapport?
• Wat gebeurt er als een datafeed stopt? Een twin die met volle overtuiging oude waarden blijft tonen, is slechter dan een twin die een gat laat zien.

Hoe beoordeel je beveiliging en toegang?

Een twin verbindt systemen die voorheen gescheiden waren: machines, productieorders en misschien leveranciersdata. Daarmee wordt het pad groter dat een aanvaller kan gebruiken, en groeit de kring van mensen die je proces kunnen inzien.

Stel deze vragen schriftelijk:

• Wie kan welke delen van het model zien en bewerken? Is de toegang op rollen gebaseerd, en kan die worden beperkt per fabriek of lijn?
• Waar wordt data opgeslagen, wie beheert die opslag en wat gebeurt er met de data als je weggaat?
• Hoe worden wijzigingen in modellen vastgelegd, en kun je terugdraaien?
• Over welke beveiligingscertificeringen beschikt de leverancier, en wat is hun reikwijdte? Een certificaat voor het bedrijf dekt niet automatisch het product dat je koopt.
• Hoe komen updates en patches bij het systeem terecht, en wie is daarvoor verantwoordelijk?

Als je data deelt met klanten of leveranciers, vraag dan aan je klanten of zij specifieke beveiligingsbeoordelingen eisen voordat je iets koppelt.

Wat kost het echt, en hoe meet je de waarde?

De licentiekosten zijn het zichtbare deel. De rest komt meestal later:

• Sensoren, gateways en netwerkwerk voor machines die geen digitale output hebben.
• Datavoorbereiding: opschonen, mappen en afspraken maken over definities tussen systemen.
• Het bouwen van het model en het valideren ervan aan de hand van echte resultaten.
• Clouddierbruik, zoals berichtenvolumes en opslag voor historische data.
• Mensen die het model na elke proceswijziging onderhouden.
• Training voor de mensen die de resultaten gebruiken.

Vraag elke leverancier om één pilotlijn over drie jaar te prijzen, inclusief al het bovenstaande. Vergelijk totalen, niet abonnementen.

Bepaal de meetwaarde voordat je begint. Koppel die aan de beslissing die de twin ondersteunt: ongeplande stilstand op de pilotlijn, doorlooptijd, planningsnauwkeurigheid, omsteltijd, uitval of onderhoudsinspanning. Leg minstens enkele weken een nulmeting vast, draai de pilot en vergelijk daarna. Als je geen getal kunt noemen dat moet bewegen, ben je nog niet klaar om te kopen.

Hier is een hypothetisch voorbeeld. Een fabrieksmanager wil weten of een tweede ploeg op een assemblagecel een terugkerende achterstand zou wegwerken. Daarvoor is geen live machinedata nodig. Een simulatie op basis van routings, cyclustijden en agenda's kan die vraag direct beantwoorden. Een conditiebewakingstwin met een sensorprogramma zou een veel groter project zijn en de vraag helemaal niet beantwoorden. De goedkoopste tool die de beslissing beantwoordt, wint.

Hoe houd je een twin in de loop van de tijd accuraat?

Fabrieken veranderen, en een twin die niet wordt bijgewerkt, loopt uit de pas met de werkelijkheid. Stel daarom vroeg regels op.

1. Wijs een eigenaar aan voor elk model, met een plaatsvervanger.
2. Versioneer het model. Leg vast wie wat en waarom heeft gewijzigd, en behoud de mogelijkheid om terug te draaien.
3. Koppel modelwijzigingen aan fabrieksveranderingen. Een nieuwe productfamilie, een verplaatste machine of een gewijzigd shiftpatroon vraagt om een modelreview.
4. Valideer regelmatig. Vergelijk de output van de twin met echte resultaten over een recente periode en noteer de afwijkingen.
5. Schaal stap voor stap op. Voeg de volgende lijn pas toe als de eerste een eigenaar, een gevalideerd model en een meetbaar resultaat heeft. Ga je naar meerdere fabrieken, standaardiseer dan de kerndefinities van data en sta gecontroleerde lokale afwijkingen toe.

Veelgemaakte fouten

• Software kopen voordat je de beslissing hebt benoemd die het moet ondersteunen.
• Licentieprijzen vergelijken en integratie, validatie en onderhoud negeren.
• Een platform kiezen terwijl een kant-en-klaar pakket de vraag al zou beantwoorden, of andersom.
• Een 3D-weergave accepteren als bewijs van een digitale tweeling terwijl live data die niet aanstuurt.
• Niet nagaan wat er gebeurt als een datafeed uitvalt.
• Het model zonder eigenaar laten nadat het projectteam verder is gegaan.
• Beginnen met de hele fabriek in plaats van met één productielijn.

Waar Polaris bij past

Als je eerste vraag gaat over planning en what-if-beslissingen, dan is iFAKT Polaris een optie om te bekijken. iFAKT omschrijft Polaris als AI plus een digitale tweeling voor productie, die ERP-data combineert met een digitale tweeling van de productie. De module Polaris Designer zet invoerdata zoals ERP-data, procestijden, resourcestructuren en beperkingen om in een productie-proces-resourceknowledgegraph die dient als single source of truth. De module Polaris Simulator bouwt hierop voort om het productiesysteem virtueel te testen, inclusief scenario's voor capaciteit, bezetting en buffers. Het is gericht op beslissingen over productieplanning, niet op conditiebewaking van afzonderlijke machines, dus pas het eerst aan op je vraag.

Gerelateerde onderwerpen om verder te verkennen

• Standaarden en interoperabiliteit: hoe OPC UA, andere protocollen en ISO 23247 samenwerken in een gemengd machinepark.
• Middleware en integratie: digitale tweelingen koppelen aan ERP, MES en SCADA zonder een apart koppelpunt voor elk rapport.
• Modelbeheer: versiebeheer, toegangsrollen en reviewcycli voor modellen die veranderen.
• Schalen over meerdere fabrieken: centrale versus lokale modellen en hoe je de datadefinities gelijk houdt.
• Totale kosten en rendement: hoe je een kostenoverzicht over drie jaar opstelt en een meting voor en na een pilot.

Volgende stap

Schrijf de ene beslissing op die je met een digitale tweeling wilt ondersteunen, en het getal dat moet veranderen als het werkt. Neem die pagina mee naar je volgende gesprek met een leverancier en vraag elke leverancier hoe hun software voor digitale tweelingen in de productie dit zou beantwoorden op één pilotlijn, met welke data, tegen welke totale kosten over drie jaar.