Wat zijn de ‘emerging technologies’ in de bouwsector? Wat betekenen ze en waarvoor dienen ze? Dat legt expert Martijn de Riet van Smart WorkPlace partner Bimforce uit. In deel 3 aandacht voor Digital Twins.

Dit artikel is het derde in een reeks over ‘emerging technologies’ in de bouw. Waar we bij de vorige artikelen, over Graph databases en Cloud en Azure omgevingen, nog voornamelijk de focus hebben gelegd op de techniek onder de motorkap, gaan we vandaag kijken naar wat dit in de praktijk betekent voor de gebruiker.

De grenzen van BIM

Al sinds de introductie van BIM in de bouwsector is het doel geweest om tot één geïntegreerde informatiestroom te komen die de levensloop van een echt gebouw digitaal zou weerspiegelen. 

In het begin zijn de ontwikkelingen in BIM vooral gestuurd door ontwerpers, engineers en aannemers. Daarna zijn fabrikanten de nieuwe procesgang gaan ondersteunen door het leveren van informatie aan het BIM-proces. 

In de laatste jaren zijn ook de belangrijkste stakeholders in de bouwsector, de eigenaars en gebruikers van de gebouwen, steeds vaker kansen gaan zien in de toepassing van BIM in hun beheers- en managementprocessen.

Hierbij loopt de sector echter wel tegen een fundamentele beperking aan van de manier waarop de huidige BIM-processen zijn ingericht. Momenteel zijn deze processen namelijk ingericht op de overdracht van informatie via bestanden. Of het nu gaat om 3D modellen als Revit of een IFC-bestand, of om andere informatie in de vorm van exceldata of PDF’s: de informatieoverdracht vindt plaats door op vooraf afgesproken tijden bestanden uit te wisselen, met een vooraf afgesproken inhoud. 

De afspraken over het proces worden vastgelegd in een BIM Protocol. De ILS regelt de inhoud van het Digitaal Gebouw Model en de manier waarop informatie wordt overgedragen. Het Uitvoeringsplan koppelt dit aan de werkprocessen van degene die de informatie aanlevert.

Het ontwerpproces werkt toe naar verschillende stadia van het ontwerp: voorlopig, definitief, technisch en ten slotte het uitvoeringsontwerp. De uitvoering werkt toe naar de overdracht van het model naar de opdrachtgever ‘as built’. In alle gevallen is er sprake van een statische momentopname als eindpunt in het (deel)proces.

Figuur 1. Lineaire procesgang BIM.

Maar als we gaan kijken naar de eindgebruiker, gebouweigenaar of -beheerder, dan bestaat dat statische eindpunt helemaal niet. Aan ieder gebouw worden continu dingen gewijzigd. Denk maar aan uw eigen huis: volgens Vereniging Eigen Huis geeft u gemiddeld tussen de 3.300,- (nieuwbouw tussenwoning) en 31.000 (vrijstaande woning < 1919) uit aan regulier onderhoud aan uw woning. Nog los van verbouwingen (aan-, uitbouw, dakkapel, nieuwe keuken of badkamer) of interne verhuizingen (nieuwe slaapkamer voor de kinderen of de aanschaf van een andere bank)

Als dit wordt vertaald naar de bezittingen van een woningbouwcorporatie, de beheerder van een groot ziekenhuis of de functioneel beheerder van een kantorenpark, is het niet lastig om te bedenken dat in de gebruiksfase een ‘oplevermoment’ nooit kan worden bereikt. Er is een continue stroom van wijzigingen en aanpassingen aan het gebouw die moeten worden verwerkt. En de wijzigingen zijn dus ook nooit ‘af’.

Daar komt nog bij dat gebruikers vooral geïnteresseerd zijn in de realtime prestaties van het gebouw: Wat is de onderhoudsstatus? Waar bevindt de luchtbehandelingskast voor dit systeem zich? Welke gebruiksfuncties en personen worden beïnvloed door een voorgenomen verbouwing? Enzovoorts.

Om dit soort inzichten te verkrijgen wordt gekeken naar het toepassen van sensoren in allerlei gebouwsystemen, en het koppelen van deze sensoren aan het Digitale Gebouw Model. Vanuit het gebruikersperspectief is dit natuurlijk een logische stap, maar als al deze sensoren ook daadwerkelijk continu gaan communiceren met het Digitaal Gebouw Model is het continu ook in gebruik.

Figuur 2. Impact beheersprocessen op Digitale Gebouw Informatie.

De enige logische conclusie is dat gedurende de gebruiksfase een file-based systeem om deze redenen dus niet kan werken.

Digital Twins

Het concept van een Digital Twin is ontstaan in de industrie. Een Digital Twin wordt daar gebruikt om vanaf het eerste ontwerp tot en met het gebruik van het product te monitoren hoe het zich ontwikkelt in theorie en vervolgens hoe het presteert in de praktijk. 

De (Engelstalige) Wikipediapagina over Digital Twin geeft een mooi overzicht van de gebruikte definities. Hierbij vallen een aantal zaken op:

Geen bestand

Een Digital Twin is in de meeste definities niet een bestand (of een hele grote hoop bestanden), maar wordt omschreven als een simulatie of een digitale ‘kloon’ van het fysieke object. Logisch natuurlijk, want als je ‘realtime data gebruikt om (zelf)lerend te analyseren en simuleren’ kan dat alleen maar als de data altijd beschikbaar zijn, en niet even wordt ‘uitgecheckt’ om de wijzigingen door te voeren in de modellen.

Levensloopbestendig

Een Digital Twin moet levensloopbestendig zijn. Alle definities gaan uit van een enkelvoudige bron van informatie die door de levenscyclus heen communiceert met verschillende gebruikersprocessen. Dat betekent in de ontwerpfase met gebouwmodellen, tijdens de realisatie een uitwisseling van data met systemen van fabrikanten en tot slot tijdens gebruik communicatie met het Facility Management platform en Onderhoudssoftware. Waarna er een verbouwing volgt die weer een uitwisseling met een architect noodzakelijk maakt. Enzovoorts.

Er is één klein probleem: de levensloop van een gebouw bedraagt gemakkelijk 50 jaar. Nu was ik er 50 jaar geleden nog niet, maar ik ben er vrij zeker van dat de opdrachtgevers, architecten en aannemers die toen werkten de huidige realiteit niet echt konden voorzien. En hetzelfde geldt natuurlijk voor de gebouwen die nu worden opgeleverd: het is met geen mogelijkheid te voorzien hoe de onderhoudsmonteur over 25 jaar zijn werk doet. 

Op zich niet erg, maar het levert wel een paar randvoorwaardes op voor een Digital Twin: 

• De Digital Twin moet zodanig zijn opgezet en ingericht dat de eigenaar van het gebouw de data kan overzetten naar nieuwe, en hopelijk betere, systemen. Feitelijk zou het het beste zijn als uw Digital Twin ook onder de privacywetgeving zou vallen, dan zou dit ‘recht op portabiliteit’ geregeld zijn.
• De Digital Twin moet in staat zijn om nieuwe softwaresystemen, toepassingen en data te integreren in het Digitaal Gebouw Model. Met andere woorden: in de 50 jaar dat het gebouw bestaat zullen zowel de hard- als software tools die gebruikt worden veranderen. De Digital Twin moet zich hierop aan kunnen passen, en bij voorkeur zonder dat het hele systeem opnieuw ingericht moet worden. 

En wat heeft dit te maken met Graphs en Azure?

Dan nu de hamvraag: wat hebben deze onderwerpen met elkaar te maken? Eigenlijk is dat vrij eenvoudig: als de randvoorwaarden bekijken die aan een Digital Twin worden gesteld dan kan dit in één woord worden samengevat: Flexibiliteit.

Niemand weet hoe we over 50 jaar met onze gebouwdata omgaan. Het enige wat we met zekerheid kunnen zeggen is dat de systemen en software die we vandaag gebruiken er dan niet meer zullen zijn. En de systemen waarmee de gebouwdata worden beheerd moeten flexibel genoeg zijn om zich aan te passen.

Werkprocessen worden ondersteund door software. Deze software moet kunnen praten met de Digital Twin, of dit nu tekensoftware als Revit is, een Excel rekenblad, het cloudplatform wat gebruikt wordt voor planmatig onderhoud of de IFC Viewer waarmee het gebouw wordt gevisualiseerd. Echter, al deze systemen hebben een andere manier om hun data aan te leveren en op te vragen. De informatie in een Revitmodel moet worden geëxporteerd vanuit Revit zelf. Een excelfile kan middels een filetransfer worden geüpload en verwerkt. Voor de cloudoplossing kan rechtstreeks via een webservice een koppeling gemaakt worden, terwijl de IFC Viewer Open Source is en op Linux draait.

Een Cloud Service Provider als Azure biedt een uitgelezen mogelijkheid om uit een bijna oneindig scala aan verbindingen de juiste oplossing te kiezen, op maat voor iedere tool die moet worden aangesloten.

Bij het opslaan van de database gaat het erom een systeem te kiezen waarbij nieuwe werkprocessen eenvoudig kunnen worden aangekoppeld, en oude processen kunnen worden afgekoppeld, door simpelweg de bestaande informatiestructuren uit te breiden. Hiervoor zijn Graph Databases uitermate geschikt. Door de manier waarop deze worden ingericht en bevraagd kan een nieuwe databron naar wens worden toegevoegd zonder dat dit invloed heeft op bestaande informatie. Vervolgens hoeven enkel de zoekalgoritmes te worden aangepast en is de nieuwe databron binnen het systeem beschikbaar.

Natuurlijk is dit in de praktijk ingewikkelder dan het zo klinkt, maar zeker in vergelijking met het volledig opnieuw uitdenken van uw databasestructuur, is het een relatief eenvoudige taak.

Conclusie

De emerging technologies van de jaren ‘20 zullen zich vooral richten op het (beter) beheersbaar maken van informatiestromen. Dit zal voornamelijk gebeuren door in te zetten op een platform wat geen enkel ander doel heeft dan het verzamelen, structureren, analyseren en weer beschikbaar maken van Digitale Gebouw Informatie aan andere processen. Dit platform, een Digital Twin dus, zal op lange termijn te kunnen functioneren als hierbij gebruik gemaakt wordt van flexibele platforms als Azure en Graph databases om de steeds wijzigende gebouwinformatie en digitale werkprocessen te kunnen blijven ondersteunen.

vrijdag 13 september 2019permalink