De anatomie van Digital Twins

De kracht van een digital twin zit in de abstractie die het biedt boven op de fysieke aansturing van een apparaat. Vanuit de historie zien we dat bij bedrijven vaak een scherpe splitsing is tussen IT (informatietechnologie) en OT (operationele technologie). In dit artikel belicht Niels Naglé een aantal belangrijke onderdelen van de Digital Twin.

Onder OT verstaan we alle fysieke apparatuur, zoals machines (motoren, robotarmen, sensoren) en de technische aansturing daarvan. Onder IT verstaan we alle softwaresystemen die informatie verwerken en de bedrijfsprocessen ondersteunen of aansturen. De OT is er hierbij gericht om de apparatuur te laten werken. Er is ook de mogelijkheid tot het uitvoeren van logica, maar de rekencapaciteit en de bijbehorende mogelijke complexiteit van logica is beperkt.

Automatisering
Door de trend van digitale transformatie, waarbij we steeds verder de bedrijfsprocessen digitaliseren, is er ook steeds meer behoefte om operationele processen te automatiseren waar fysieke apparatuur een rol in heeft. Denk hierbij aan een grotendeels geautomatiseerd distributiecentrum voor e-commerce of retail, geautomatiseerde kwaliteitscontrole in een productieproces of aan onderhoudsprocessen op apparatuur zoals motoren en robotarmen.

Ook zien we de opkomst van Industry 4.0 en de trend om alles in de omgeving “smart” te maken, zoals Smart Buildings en Smart Cities. Om deze processen efficiënt te kunnen automatiseren, is het van belang dat de bedrijfsregels en procesflow separaat ontwikkeld kunnen worden van de details rondom de fysieke aansturing en het uitlezen van de apparatuur. Dit is waar de digital twin een belangrijke rol heeft. Info Support heeft een IoT referentiearchitectuur opgesteld. (Zie de IoT-referentiearchitectuur voor meer details.) Hierbinnen is de digital twin gepositioneerd en uitgewerkt.

Anatomie van de Digital Twin
Een digital twin heeft de positie tussen de hardware, en de IT-processen. Aan de kant van de hardware gaat het om aansturing van actuatoren en het uitlezen van sensoren. Hierbij is OT-software benodigd voor de technische interactie. Onderstaand is de Digital Twin schematisch weergegeven.

De digital twin slaat de brug tussen de fysieke en de digitale wereld. Via de device gateway wordt de connectie met het device mogelijk gemaakt. Device management zorgt ervoor dat het device op de juiste manier geconfigureerd en geinstalleerd wordt. Deze acties vinden primair bij de initiële uitrol plaats.
Wanneer alles goed geconfigureerd is wordt vervolgende de core logic uitgevoerd. Dit zijn de processen die het bestaansrecht zijn van de digital twin, waarbij Sensoren worden uitgelezen (sensor readings) en op basis daarvan, via de core logic en externe commando’s (process control API) acties uitgestuurd kunnen worden naar het device (actuator commands).

Voor de besturingslogica is het vaak van belang dat de actuele toestand van het device bekend is. Omdat devices niet altijd connected hoeven te zijn, is het van belang om ook binnen de digital twin dataopslag te faciliteren. Zodat ook wanneer er tijdelijk geen connectie is, het toch mogelijk is om de laatst bekende status uit te lezen en commando’s richting het device klaar te zetten. Op deze manier wordt het integreren met IT processen een stuk eenvoudiger.

Een digital twin lost typisch de volgende uitdagingen op:
Robuuste interface met het Device
- Occasionally connected apparatuur
- Schaalbaarheid van de interface
- Robuustheid van de interface
- Koppelbaarheid van de interface met open protocollen
Semantische vertaling
- Vertalen van “Business Acties” (process control API) naar Technische Device commando’s (actuator commands)
- Vertalen van technische meetwaarden en gebeurtenissen (sensor readings) naar Business Events
Simulatie
- Het bieden van een gelijke interface en gedrag naar de buitenwereld, maar zonder de noodzaak voor fysieke hardware doordat het device of de device gateway vervangen kan worden door een gesimuleerde versie.
Consistent domeinmodel
- Een eenduidige set van regels waarin Acties, Events en Configuratie samenkomen (core logic), en die geautomatiseerd continue doorgetest kunnen worden met ondersteuning van de simulatie component.

Praktijkcase: Slimme Thermostaat
Om deze concepten wat concreter te maken passen we dit toe op een Slimme Thermostaat. Deze thermostaat kan het volgende:
• Detecteren aanwezigheid in de ruimte die op temperatuur gehouden moet worden
• Mogelijkheid om een doel temperatuur en tolerantie in te stellen (set-point temp)
• Het instellen van diverse stookschema’s (bijv. Vakantie, Weekend/Week, Zomer/Winter)
• Via Deep-Learning op basis van Aanwezigheid, Buitentemperatuur en handmatige aanpassingen op de thermostaat automatisch een stookschema leren (deep learning stookschema).

Om een veilige verbinding mogelijk te maken zal eenmalig ook een set aan credentials ingesteld moeten worden.

Het proces waar het om gaat, is klimaatbeheersing. Dankzij het digital twin concept is dit heel eenvoudig te realiseren. Er is een digital twin voor de thermostaat en er is een digital twin voor de CV-Ketel. De thermostaat geeft aan dat de temperatuur niet meer binnen de tolerantie valt, en de CV-Ketel zal verwarmen tot dit wel zo is.
Door het modulariseren van de oplossing naar digital twins, is het ook veel eenvoudiger geworden om dezelfde thermostaat binnen andere besturingprocessen te integreren. En het is bijvoorbeeld mogelijk om de CV-Ketel te testen met een gesimuleerde thermostaat en andersom.

De Rol van Domain-Driven Design
Wij passen Domain-Driven Design toe om de logica, processen en verantwoordelijkheden binnen een software architectuur (in dit geval die van de digital twin) goed te beleggen. DDD sluit hierbij heel goed aan omdat de “intelligentie” van de digital twin gevat moet worden in een autonoom component, het domein model.

Ook is er binnen DDD het software architectuur principe om infrastructurele zaken, zoals communicatie en opslag van gegevens, volledig te scheiden van de functionele logica. Dit betekent dat het ook goed mogelijk is om alle logica van de digital twin geïsoleerd en geautomatiseerd te testen. Wat ons betreft een randvoorwaarde voor een korte time-to-market in combinatie met lange termijn onderhoudbaarheid.

De Rol van Microservices
Zoals eerder aangegeven, spiegelt een digital twin een hardwarecomponent. Hardwarecomponenten zijn over het algemeen modulair opgebouwd. Op het kleinste niveau zijn de hardwarecomponenten ook relatief simpel.
Ook de digital twin moet zo’n zelfde modulaire opbouw hebben. Net als dat hardwarecomponenten tot een groter geheel gecombineerd worden, geldt dit ook voor de digital twin. Vanwege deze modulariteit, en de bovengenoemde uitdagingen die de digital twin oplost (schaalbaarheid, robuustheid, flexibiliteit en een domein model), zien we hier een hele goede fit met het toepassen van een microservices architectuur. Waarbij elke hardwarecomponent een digital twin microservice heeft, die met elkaar communicerend, een gehele hardware module representeren.

Denk hierbij in de context van het voorgaande voorbeeld aan de CV-Ketel, die naast de verwarming van het CV-water ook de functie van een boiler heeft voor warm water in de keuken of douche. Door deze twee componenten als onafhankelijke digital twin modules te realiseren, wordt het ook eenvoudiger om de boiler in andere totaalproducten te integreren.