NL 
EN
Waar het allemaal begon, NASA
Het concept van de digital twin (ook wel digitale tweeling) is eenvoudig: het is een digitale tegenhanger van iets in de fysieke wereld, bijvoorbeeld een fysiek object of proces, in combinatie met een informatiestroom die digitale tegenhanger up-to-date houdt met de fysieke wereld. Hoewel de term digitale tweeling voor het eerst werd gebruikt in 2002 door John Vickers van NASA, is het concept zelf al veel ouder en wordt het sinds de jaren ‘70 door NASA toegepast.
Om te begrijpen wat een digital twin is, is het allereerst belangrijk om het verschil te weten tussen statische modellen of simulaties, en digital twins. De NASA ontdekte de noodzaak voor de digital twin tijdens het Apollo 13 ruimteprogramma, toen NASA-ingenieurs na lancering niet langer konden vertrouwen op hun modellen van de Apollo 13 raket. Deze waren niet meer representatief omdat het ruimtevaartuig was veranderd als gevolg van de blootstelling aan de ruimte. Om dit probleem op te lossen gebruikten zij de live-data om een up-to-date model van het ruimtevaartuig bij te houden. Dit model, de digital twin van het ruimtevaartuig, kon vervolgens gebruikt worden voor het nemen van real-time beslissingen zodra er een incident optrad.
Nu is de digital twin niet alleen toe te passen in de ruimtevaart, maar ook voor andere fysieke activa en processen die gemonitord moeten worden. Neem bijvoorbeeld het productieproces van een industriële bakkerij; het productieproces wordt eerst gemodelleerd en wordt vervolgens geïmplementeerd. Echter, na verloop van tijd zal de daadwerkelijke supply chain gaan afwijken van het oorspronkelijke model. Bijvoorbeeld, een van de leveranciers van de bakkerij kan zijn leveringstarieven wijzigen waardoor er andere leveranciers betrokken raken. Wanneer dit gebeurt, en het proces verandert ten opzichte van het model, dan weten we niet meer precies hoe deze functioneert, waar de knelpunten zitten en hoe we het proces kunnen optimaliseren.
De oplossing hiervoor is de digital twin. Door de data vanuit het productieproces te verwerken tot een live state, kunnen beslissingen altijd worden genomen op basis van de huidige omstandigheden en niet op basis van wat er in het verleden is gebeurd. In geval van de bakkerij stelt de digital twin ons bijvoorbeeld in staat om op basis van de actuele leveringspercentages te bepalen of we van leverancier moeten veranderen om de productie op pijl te houden. Deze beslissingen kunnen we handmatig nemen op basis van het model, of we kunnen het model integreren met andere toepassingen, zoals een applicatie die de leverancier van een bestelling bepaald op basis van de huidige leveringspercentages.
Omdat onze digital twin voortdurend wordt bijgewerkt, kunnen we zelfs pro-actief reageren op veranderingen in de digital twin door automatisch acties te ondernemen zodra dit nodig is. Bijvoorbeeld door onmiddellijk ingrediënten te bestellen bij een andere leverancier wanneer we merken dat de leveringen aan de bakkerij ondermaats zijn. In dit geval analyseren we de verandering in de digital twin, en genereren we uitzonderingen zodra we een verandering als onwenselijk zien zodat we direct kunnen reageren als het nodig is.
Hoe bouw je de digital twin?
Nu we wat meer duidelijkheid hebben over waarom je een digital twin zou willen implementeren volgt de vraag hoe we dit vervolgens moeten doen. Allereest is het belangrijk om een doel te stellen voor de digital twin, en alle eisen van de betrokken gebruikers en applicaties te verzamelen met betrekking tot welke inzichten zij uit de digital twin willen halen. Door dit vast te stellen maken we de scope van de digital twin duidelijk, en weten we ook welke informatie we moeten verzamelen om de digital twin up to date te houden.
De volgende taak is daarom dan ook om alle data bronnen te identificeren die we nodig hebben om de digital twin up-to-date te houden. Dit vormt vaak een grote uitdaging, aangezien het verkrijgen van toegang en het bruikbaar maken van data uit allerlei verschillende bronnen een langdurig proces kan zijn. Nadat je toegang tot de data hebt gekregen moet je de data namelijk opschonen en verwerken tot de juiste structuur. Dit betekent het inrichten van een digitale wasstraat voor alle verschillende soorten data. Nadat de data is opgeschoond en genormaliseerd kunnen we deze aggregeren tot een model. Er zijn dus drie stappen: 1) Het ophalen van de data 2) Het opschonen en normaliseren van de data 3) Het aggregeren tot een model. Voor het uitvoeren van deze taken is Stream Processing technologie het meest geschikt. Stream processing heeft ingebouwde tools voor complexe operaties zoals het verrijkingen van data, of het uitvoeren van aggregaties over een bepaalde tijdsperiode. Voorbeelden van stream processing tools zijn bijvoorbeeld Kafka Streams en Flink.
Als we teruggaan naar de bakkerij. Stel dat we de uurlijkse inname van ingrediënten willen bijhouden zodat we ons productieproces kunnen monitoren. Er zijn sensoren geplaatst in de bakkerij die de inname van ingrediënten monitoren. Deze datastroom moeten we eerst binnenhalen, en vervolgens moeten we de ingevoerde datastroom opschonen zodat we alleen geldige, genormaliseerde data overhouden. In het geval van de bakkerij betekent dit dat we alle sensordata omzetten in innamen in grammen, en alle 0 metingen verwijderen. Ten slotte aggregeren we deze data per dag, zodat we altijd de actuele inname van elk van de ingrediënten weten.
De laatste stap in de ontwikkeling is het beschikbaar maken van de digital twin aan alle geïnteresseerden. Door herbruikbare API’s te bouwen boven op de digital twin kunnen alle geïnteresseerde partijen de digital twin raadplegen. Afhankelijk van de vereisten kan deze data bijvoorbeeld geïntegreerd worden in bestaande dashboarding en rapportering tools, in beslissingsondersteunende systemen, of in een specifieke UI. De laatste is het meeste van toepassing op complexe processen of activa die gespecialiseerde visualisaties vereisen.
Naast de eerdergenoemde on-demand applicaties kunnen event gedreven applicaties worden ingezet om onmiddellijk te reageren wanneer de digital twin verandert. Bijvoorbeeld, in onze bakkerij willen we misschien direct reageren als de uurlijkse inname van ingrediënten onder een bepaalde drempelwaarde komt. Door event-gedreven applicaties te bouwen op de digital twin, kunnen we direct reageren wanneer dit gebeurt, in plaats van achteraf.
Aangezien de digital twin voortdurend veranderd, is het belangrijk om de digital twin zodanig op te stellen dat hij makkelijk te veranderen is. Het gebruik van no-code of low-code tools, zoals Streaming SQL en model-gedreven ontwikkeltools kan hierbij helpen. Deze tools stellen business developers in staat om de digital twin zelf te veranderen, zonder dat het nodig is om traditionele software developers in te schakelen. eMagiz is een van de tools die organisaties kan helpen met de uitdagingen rondom het onderhouden van een digital twin. Zo biedt eMagiz bijvoorbeeld tools om data te verzamelen uit verschillende databronnen en applicaties. Daarnaast biedt eMagiz de mogelijkheid om data op te schonen, te normaliseren en te aggregeren tot een digital twin. Tot slot biedt het platform de mogelijkheid om het model te ontsluiten via een API, en real-time actie te ondernemen op veranderen in de digital twin. Neem contact met ons op om meer te weten te komen over hoe wij u kunnen helpen met de implementatie van de digital twin.
Door Mark de la Court, Product owner Event management @ eMagiz
