Het lijkt wel alsof iedereen tegenwoordig op de Digital Twin-trein springt. Maar hoe zorgen we ervoor dat iedereen het wiel niet opnieuw hoeft uit te vinden? Geonovum pakt deze uitdaging aan door een architectuur voor Digital Twins te ontwikkelen die het makkelijker maakt om herbruikbare componenten te creëren. Deze architectuur is gebaseerd op het zogenaamde ‘driehoeksmodel‘.
Driehoeksmodel
Het driehoeksmodel bestaat uit drie componenten: de data, de rekenmodellen en de visualisatie.
Bijvoorbeeld, het Urbo3D Klimaatspel (een digital twin van een wijk) bestaat uit drie onderdelen:
- Data: de 3D-data uit de ‘3D Basisvoorziening‘ van het Kadaster, gecombineerd met BAG, BGT en klimaatdata uit de Klimaateffectatlas.
- Rekenmodellen: modellen die het Stedelijke Hitteeiland– en de overstromingseffecten berekenen na wijzigingen in het spel.
- Visualisatie: de Godot-game-engine die de 3D-data en de resultaten van de rekenmodellen visualiseert.
Het driehoeksmodel maakt onafhankelijke ontwikkeling en hergebruik van componenten tussen verschillende digital twins mogelijk. Bijvoorbeeld, als er meer detail nodig is voor het plaatsen van zonnepanelen, kan de ‘3D Basisvoorziening’ worden vervangen door ‘3D BAG‘-data. Op dezelfde manier kunnen nauwkeurigere overstromingsmodellen de bestaande modellen vervangen.
Componenten kunnen zich op verschillende servers bevinden en toegankelijk zijn via API’s. Hoewel data wel beschikbaar is via endpoints op PDOK, zijn rekenmodellen nog niet API-toegankelijk. Geonovum onderzoekt manieren om deze modellen toegankelijke en interoperabel te maken.
De praktijk is echter wat rommeliger.
Uitdaging: De Wet van Lekkende Abstracties
De wet van lekkende abstracties is een term bedacht door Joel Spolsky in zijn blogpost The Law of Leaky Abstractions. Deze wet stelt dat elke abstractie een lek heeft, dat wil zeggen: enkele details die niet geabstraheerd kunnen worden en problemen veroorzaken.
Het lastige, lekkende detail in dit geval is de trage prestaties van het systeem. De rekenmodellen hebben data nodig om te functioneren, dus de modellen en de data moeten bij elkaar worden gebracht: ofwel de (vaak grote en complexe) data moeten naar het model worden gestuurd, of het model moet naar de data worden gestuurd. Beide opties hebben hun eigen problemen.
- Data verzenden: Grote, complexe 3D-data kunnen prestatieproblemen en synchronisatie-uitdagingen in dynamische omgevingen veroorzaken.
- Berekening verzenden: Complexe modellen zijn lastig om elders uit te voeren en gegevenswijzigingen blijven problematisch.
In de praktijk worden de 3D-data vaak naar het model verzonden, wat prestatieproblemen kan veroorzaken. Deze problemen kunnen worden verminderd door technieken zoals datacompressie, sampling en caching, maar deze technieken zijn niet eenvoudig te implementeren en maken de rekenmodel-API’s complexer.
Prestaties en bruikbaarheid
Prestaties zijn cruciaal voor de bruikbaarheid, vooral in educatieve spellen zoals Urbo3D, waar een responsieve interface essentieel is om de aandacht van tieners vast te houden. Maar ook in een professionele omgeving kan een traag systeem een groot probleem zijn. Trage systemen frustreren gebruikers, waardoor verkenning en experimenteren worden bemoeilijkt.
In het ergste geval zullen gebruikers hun digital twins volledig de rug toekeren door trage prestaties.
Prestaties verbeteren in Urbo3D
Om prestaties te bereiken die acceptabel zijn voor onze kritische tienerdoelgroep, hebben we een aantal strategieën toegepast:
- We hebben de abstracties doorbroken.
- Wij hebben het aantal berekeningen verminderd.
- We hebben de berekeningen naar de GPU verplaatst.
Abstracties doorbreken
De rekenmodellen zijn direct geïntegreerd in de Godot-visualisatie-engine. Deze aanpak elimineert de latentie van de communicatie tussen client en server en biedt spelers de directe feedback die ze nodig hebben. Dit vereist echter dat de modellen in-house worden ontwikkeld in plaats van gebruik te maken van oplossingen van derden. Daardoor moeten eventuele modelvervangingen ook op maat worden geïmplementeerd.
Aantal berekeningen verminderen
Om de rekencapaciteit te minimaliseren, passen we een strategie toe die bekend staat als incrementeel rekenen. Deze aanpak stelt ons in staat om de toestand van het systeem efficiënter bij te werken door volledige herberekeningen te vermijden.
- Aanvankelijk wordt de toestand van het systeem berekend met behulp van het oorspronkelijke model.
- Bij een wijziging binnen de digital twin werken we selectief alleen de toestand bij in het geografische gebied dat door de wijziging wordt beïnvloed.
Bijvoorbeeld, bij het evalueren van hittestress in een wijk met behulp van het hittestressmodel van het RIVM, richten we ons, wanneer een speler een boom toevoegt, op het herberekenen van de hittestressveranderingen specifiek rond de locatie van de boom, in plaats van de hele wijk opnieuw te beoordelen.
Deze methode versnelt het updateproces aanzienlijk en optimaliseert de prestaties door onnodige volledige herberekeningen te vermijden.
Berekeningen naar de GPU verplaatsen
Om de prestaties nog verder te verbeteren, maken we gebruik van de GPU voor berekeningen door gebruik te maken van Shaders in Godot.
Shaders zijn gespecialiseerde programma’s die draaien op Graphics Processing Units (GPU’s). Hoewel ze oorspronkelijk zijn ontworpen voor het schaduwen van 3D-scènes, zijn hun mogelijkheden aanzienlijk uitgebreid. In onze toepassing worden shaders gebruikt om de modelberekeningen uit te voeren. Deze shaders zijn geschreven in een taal afgeleid van GLSL (OpenGL Shading Language) binnen de Godot-engine.
Conclusie
Door een reeks innovatieve technieken te integreren, hebben we met succes de prestatie-uitdagingen in het Urbo3D Klimaatspel aangepakt, wat de algehele spelervaring voor onze kritische tienerdoelgroep heeft verbeterd. De strategieën—het doorbreken van abstracties, het verminderen van het aantal berekeningen en het benutten van GPU-berekeningen—droegen gezamenlijk bij aan een responsievere en boeiendere interface, cruciaal voor zowel educatieve als professionele toepassingen.
Ondanks deze vooruitgangen vereiste het behalen van optimale prestaties dat we aanzienlijk afweken van het oorspronkelijke driehoeksmodel. Deze afwijking hield in dat data, rekenmodellen en visualisatie strak met elkaar werden verbonden tot een meer samenhangend systeem. Hoewel deze aanpak de benodigde prestatiewinst opleverde, bracht het ook de beperkingen van het driehoeksmodel aan het licht in scenario’s die real-time interactie en feedback vereisen.
Deze ervaring benadrukt het belang van flexibiliteit in digital twin-architecturen. Hoewel het driehoeksmodel een robuust kader biedt voor hergebruik van componenten en modulariteit, kunnen bepaalde toepassingen een meer geïntegreerde aanpak vereisen om specifieke prestatie- en gebruikseisen te vervullen. Vooruitkijkend zou een hybride model dat de sterke punten van zowel abstractie als integratie combineert, een evenwichtige oplossing kunnen bieden die tegemoetkomt aan de diverse behoeften van digital twin-toepassingen.