TenneT pilot met verschillende invalshoeken

Een ObjectTypenBibliotheek (OTL) begint steeds meer voeten in de aarde te krijgen binnen de Nederlandse bouw-, infra- en energiesector. Waar deze ontwikkelingen zijn begonnen bij publieke organsaties in de infrasector, zie je dat het ontwikkelen en gebruik van een OTL zich uitbreid naar de aannemers en adviesbureaus. Van origine heeft een OTL als doel om de integrale informatiebehoefte van een organisatie vast te leggen.

Op het moment is te zien dat veel van deze OTL’s, worden toegepast door asset eigenaren om de informatiebehoefte voor het beheer- en onderhoudsproces te omschrijven. De OTL wordt vervolgens onderdeel van het contract, vaak in combinatie met een informatieleveringsspecificatie (hierna: ILS). Wanneer een opdrachtgever asset informatie uitvraagt op basis van een OTL, wordt in veelal vereist om de data terug te leveren middels linked data formaten, of daarop gebaseerde standaarden zoals bijvoorbeeld COINS of de opvolger ICDD.

Kijkend naar de organisaties die werken uitvoeren voor deze asset eigenaren, zoals aannemers, is Building Information Modelling (hierna: BIM) de laatste jaren steeds volwassener geworden, al dan niet de standaard voor de grotere aannemers. BIM wordt veel toegepast voor het ontwerpen, plannen en uitvoeren van assets door de partijen gerelateerd aan het (nieuw) bouwproces. Voor deze partijen is het werken met een OTL, de bijbehorende standaarden en bestandsformaten, nieuw. Veel horend iets is dat aannemers zich afvragen of zij niet ‘gewoon’ de BIM-modellen kunnen opleveren.

Hoe kunnen deze twee stromen, toepassen BIM en OTL gebruik, elkaar vinden? Hoe verhoudt het vergezicht van deze technische en datagedreven ontwikkelingen zich ten opzichte van wat vandaag de dag praktisch toepasbaar is? In dit artikel bespreken we het spectrum van de meest praktische mogelijkheden tot het vergezicht met de ontwikkelingen. Hierbij staat een pilot centraal, waarbij verschillende mogelijkheden zijn uitgewerkt en toegepast en de voor- en nadelen opgesomd worden.

De pilot

Tennet heeft als asset eigenaar een OTL ontwikkeld voor het definiëren van de asset informatie behoefte. Naast de OTL heeft Tennet de afgelopen jaren een 6 tal BIM pilot project uitgevoerd waarin kennis en ervaring is opgedaan. Samen met de ketenpartners is het 3D BIM model hier centraal gezet voor het uitwisselen van geometrie en data in projecten. Beide stromen, OTL en BIM, bieden Tennet meerwaarde voor het uitwisselen van de juiste data rondom de assets, maar hoe kun je BIM en OTL gezamenlijk toepassen? TenneT had behoefte aan een zorgvuldige afweging rondom het werken met BIM-modellen in combinatie met de OTL.

Met deze vraag is er een pilot project gestart waarin verschillende varianten zijn verkend en waarmee verschillende dataleveringen zijn uitgevoerd. Het uitgangspunt is dat Tennet een OTL ter beschikking stelt en dat de datalevering, BIM-modellen (zowel native als IFC), 2D tekeningen en documenten dienen te bevatten. Zie Figuur 1 voor een schematisch overzicht van het startpunt.

Met dit uitgangspunt zijn twee stromen van data-terug-levering te scheiden. In de eerste variant wordt de data en de geometrie gescheiden. In dit geval wordt het BIM-model gedegradeerd tot 3D model en wordt alle informatie vastgelegd in een separaat (linked data)bestand, een dataset op basis van de OTL. Als tweede variant wordt het BIM-model gebruikt als de informatiedrager, hierbij wordt alle data vastgelegd in het BIM-model. Per variant is uitgewerkt hoe deze data tot stand is gekomen, hoe deze uitgewisseld wordt en worden de voor- en nadelen inzichtelijk gemaakt. Het vastleggen van data en de uitwisselen hoeven niet één op één gelijk te zijn. Het vastleggen van data kan op verschillenden wijzen worden gerealiseerd, ook wanneer het uitwisselen op een gestandaardiseerde wijze gebeurd.

Variant 1: Data en geometrie scheiden

In deze variant wordt de geometrie gescheiden van de data. Het BIM-model wordt hierbij gedegradeerd tot de drager van de geometrie, een 3D-model. De data wordt separaat geleverd, in het geval van de pilot, door middel van een instantie dataset van de OTL. Naast de 3D geometrie en de data worden er nog documenten en 2D tekeningen geleverd. Figuur 2 geeft een schematisch overzicht van de variant. Het aanbrengen van een scheiding tussen de data en de geometrie voor de oplevering van de informatie, brengt met zich mee dat er verwijzingen aangebracht dienen te worden ter plaatse van de scheiding. Door deze verwijzing aan te brengen wordt de relatie tussen de geometrie van een object en de daarbij horende data en/of documenten geborgd.

Vastleggen van de data in variant 1

We schetsen een aantal opties voor het vastleggen van data rondom objecten. Onder data verstaan we alle alfanumerieke waarden die iets zeggen over een object, de geometrie valt daar niet onder. Vanuit de verschillende wijzen van vastlegging komt men tot een oplevering van de informatie.

1. Vastleggen van alle object data in een separate (configuratie management) database (hierna: CMDB), zie Figuur 3.

Het vastleggen van alle data rondom de objecten kan worden gedaan middels een daarvoor ingerichte database. Hierbij is het van belang dat de database wordt ingericht zodat deze overweg kan met de OTL van de opdrachtgever. De data zal namelijk moeten voldoen aan de eisen zoals vastgelegd in de OTL. Oplevering; voor de uiteindelijke oplevering dient de database een bestand te genereren volgens de uitvraag van opdrachtgever. In het geval van deze pilot gaat het om een instantie dataset van de OTL te genereren. Een meer geavanceerde mogelijkheid is om de data via het web (beveiligd) te publiceren, hiermee wordt het exporteren van de data overbodig.

Aandachtspunten:

Door de data te scheiden van de geometrie dient er een referentie tussen de 2 databronnen (geometrie en data) te worden gelegd. Om discrepanties te voorkomen is het aan te raden om de relatie eenzijdig vast te leggen (van A naar B of van B naar A). Wanneer de inverse relatie gewenst is, genereer deze dan op basis van de directe relatie.

2. Vastleggen van alle object data in het BIM-model, zie Figuur 3. Naast 3D geometrie is BIM bij uitstek ook geschikt voor het vastleggen van de data gerelateerd aan de objecten. Bij het gebruik van een OTL is het daarbij van belang dat de eisen uit de OTL worden gevolgd. Naast dat objecten geclassificeerd dienen te worden volgens de OTL, dienen ook de regels omtrent de decompositie, eigenschappen en documenten(relaties) te worden vastgelegd in het BIM-model. Oplevering; voor de oplevering van de informatie volgens deze variant (data en geometrie gescheiden) dient de data uit het BIM onttrokken te worden en te worden opgeslagen als (linked) data bestand volgens de geleverde OTL. Dit kan op verschillende manieren gerealiseerd worden:

a. Een plugin in de native BIM software onttrekt de data waarna deze geconverteerd dient te worden naar een instantie dataset van de OTL (dezelfde actie als de generatie uit de cmdb uit punt 1).

b. Het BIM-model (of meerdere modellen) wordt geëxporteerd naar de open BIM standaard IFC.

Een applicatie onttrekt vervolgens de data uit het IFC en geconverteerd dit naar een instantie dataset geclassificeerd aan de OTL. Hiermee ontstaat er een modelleer applicatie onafhankelijke oplossing.

Aandachtspunten:

• De objecten in het BIM-model dienen getypeerd te worden conform de OTL. Hierbij is het aan te raden om deze typering als selectielijst in te laden in de modelleer applicatie.
• De eisen in de OTL, zoals eigenschappen, decompositie, documenten, en mogelijk meer dienen vastgelegd te worden in het BIM-model. Het is hierbij, net als het typeren van objecten, aan te raden om deze eigenschappen en relaties geautomatiseerd toe te voegen aan de objecten aan de hand van de typering.
• Om de hoeveelheid werk significant te verminderen is het aan te raden om object type (families) te modelleren, veel van de bovenstaande gegevens kunnen op dit niveau vastgelegd worden. De individuele objecten kunnen dan getypeerd worden volgens het object type.
• Besteed aandacht aan het configureren van de export naar IFC, zodat de data in het BIM-model naar de juiste IFC classes geëxporteerd wordt.

3. Vastleggen van de object data gespreid over het BIM-model en de database, zie Figuur 4.

Bij het vastleggen van de data verdeeld over twee verschillende bronnen is het van belang dat de data eenmalig wordt vastgelegd. Zo dient duidelijk te zijn welke data vastgelegd wordt in het BIM-model en welke data wordt vastgelegd in de CMDB.

a. De objecten uit het BIM-model worden gekoppeld aan de instanties in de CMDB. Hiermee kan de CMDB data overnemen uit het BIM-model. Vervolgens kan de CMDB een instantie dataset genereren op basis van de OTL, dit is hetzelfde proces als bij vastlegging variant 1.

b. Naast het koppelen van een BIM-model aan een CMDB, is het ook mogelijk om de twee gescheiden te laten werken. Beide genereren daarbij eigen instantie data welke een gedeelte van de informatie uit de OTL afdekken, het is daarbij de som van vastlegging variant 1 en 2. Voor de daadwerkelijke som dienen de twee gegenereerde instantie datasets te worden samengevoegd welke gezamenlijk de informatie dekken zoals aangegeven in de OTL

Oplevering; voor de oplevering van de informatie kan de data gecombineerd worden en als (linked) data bestand, volgens de geleverde OTL, worden samengevoegd.

Dit kan op verschillende manieren:

Aandachtspunten:

• De aandachtspunten zoals benoemd in 1 en 2 zijn hier van toepassing.
• Wanneer er een scheiding wordt gemaakt tussen het vastleggen van data in het BIM-model en een CMDB dient het duidelijk te zijn welke data, welke voorgeschreven staat in de OTL, in welke bron wordt vastgelegd.

Variant 2, data en geometrie gecombineerd

Naast het scheiden van data en geometrie is de open BIM standaard IFC bij geschikt voor het combineren van de geometrie met de data. Het IFC schema ondersteunt daarnaast ook het vastleggen van metadata rondom documenten en de relatie naar objecten. Hiermee is het mogelijk om alle data, en de relaties naar documenten en externe bronnen, middels één bestandsformaat te leveren. Figuur 5 geeft een schematisch overzicht van de variant.

Vastleggen van data in variant 2

De vastlegging van de data kan op dezelfde wijze als aangegeven in variant 1.

1. Vastleggen van alle object data in een separate (configuratie management) database (CMDB), zie Figuur 6.

Het vastleggen van alle data rondom de objecten kan worden gedaan middels een daarvoor ingerichte database. Hierbij is het van belang dat de database wordt ingericht zodat deze overweg kan met de OTL van de opdrachtgever. De data zal namelijk moeten voldoen aan de eisen zoals vastgelegd in de OTL.

Oplevering; voor de uiteindelijke oplevering dient de CMDB een export te maken naar de open BIM standaard IFC.

Aandachtspunten:

• Door de data te scheiden van de geometrie dient er een referentie tussen de 2 databronnen (geometrie en data) te worden gelegd. Om discrepanties te voorkomen is het aan te raden om de relatie eenzijdig vast te leggen (van A naar B of van B naar A). Wanneer de inverse relatie gewenst is, genereer deze dan op basis van de directe relatie.
• Hergebruik de global unique identifiers (GUID’s) van de objecten uit het BIM-model in het CMDB, zo kan de export naar IFC dezelfde GUID’s gebruiken.

2. Vastleggen van alle object data in het BIM-model, zie Figuur 6.

Naast 3D geometrie is BIM bij uitstek ook geschikt voor het vastleggen van de data gerelateerd aan de objecten. Bij het gebruik van een OTL is het daarbij van belang dat de eisen uit de OTL worden gevolgd. Naast dat objecten geclassificeerd dienen te worden volgens de OTL, dienen ook de regels omtrent de decompositie, eigenschappen en documenten(relaties) te worden vastgelegd in het BIM.

Oplevering; voor de oplevering dient er het BIM (of de verzameling van modellen) geëxporteerd te worden naar IFC middels de IFC exporter in de modelleer applicatie.

Aandachtspunten:

• De objecten in het BIM-model dienen getypeerd te worden conform de OTL. Hierbij is het aan te raden om deze typering als selectielijst in te laden in de modelleer applicatie.
• De eisen in de OTL, zoals eigenschappen, decompositie, documenten, en mogelijk meer dienen vastgelegd te worden in het BIM-model. Het is hierbij, net als het typeren van objecten, aan te raden om deze eigenschappen en relaties geautomatiseerd toe te voegen aan de objecten aan de hand van de typering.
• Om de hoeveelheid werk significant te verminderen is het aan te raden om object type (families) te modelleren, veel van de bovenstaande gegevens kunnen op dit niveau vastgelegd worden. De individuele objecten kunnen dan getypeerd worden volgens het object type.
• Besteed aandacht aan het configureren van de export naar IFC, zodat de data in het BIM-model naar de juiste IFC classes geëxporteerd wordt.

3. Vastleggen van de object data gespreid over het BIM-model en de database, zie Figuur 7.

Bij het vastleggen van de data verdeeld over twee verschillende bronnen is het van belang dat de data eenmalig wordt vastgelegd. Zo dient duidelijk te zijn welke data vastgelegd wordt in het BIM-model en welke data wordt vastgelegd in de CMDB.

Oplevering; voor de oplevering van de informatie kan de data gecombineerd worden tot één IFC bestand.

a. De objecten uit het BIM-model worden gekoppeld aan de instanties in de CMDB. Hiermee kan de CMDB data overnemen uit het BIM-model. Vervolgens kan de CMDB een instantie dataset genereren op basis van de OTL, dit is hetzelfde proces als bij vastlegging variant 1.

b. Naast het koppelen van een BIM-model aan een CMDB, is het ook mogelijk om de twee gescheiden te laten werken. Beide genereren daarbij een eigen instantie dataset welke een gedeelte van de informatie uit de OTL afdekken, het is daarbij de som van vastlegging variant 1 en 2. Voor de daadwerkelijke som dienen de twee gegenereerde instance datasets te worden samengevoegd welke gezamenlijk de informatie dekken zoals aangegeven in de OTL.

Aandachtspunten:

• De aandachtspunten zoals benoemd in 1 en 2 zijn hier van toepassing.
• Wanneer er een scheiding wordt gemaakt van de vastleggen van data over het BIM-model en een CMDB dient het duidelijk te zijn welke data (welke voorgeschreven staat in de OTL) in iedere bron wordt vastgelegd.

Welke variant heeft de voorkeur?

Ongeacht de varianten is een belangrijke vraag ‘Waar leggen we de knip van data transformatie? Bij de opdrachtnemer of bij de opdrachtgever? Een opdrachtgever kan een conversie applicatie opzetten om relevante data uit het BIM-model te onttrekken en deze in ieder gewenst formaat opslaan (bijvoorbeeld een dataset op basis van een OTL (variant 2). Deze vraag kan ook bij de opdrachtnemer neergelegd worden (variant 1).

Om een keuze te maken dient goed gekeken te worden naar het niveau in de markt op beide ontwikkelingen. Ons inziens is het te adviseren om beide varianten te ondersteunen. Zo worden partijen niet gedwongen om met technieken en werkprocessen te werken die hen nog niet eigen zijn. Dit zal uiteindelijk ten goede komen in de kwaliteit van de dataleveringen richting opdrachtgever. De digitale transitie heeft tijd nodig om de landen in alle lagen van organisaties, het is daarbij zaak om niet te snel geavanceerde technieken te verplichten, maar deze mogelijkheid al wel te bieden.

Wat kunnen leren van deze pilot?

• Specificeren van de eisen aan het BIM-model is nodig. Denk daarbij aan het specificeren van het gebruik van fysieke objecten en ruimtelijke objecten en het opdelen van het BIM-model in verschillende submodellen. Er is namelijk geen één BIM-model, maar een aggregatie van verschillende BIM-modellen. Of hoe leg je de relatie tussen de objecten in het BIM-model en de OTL en wanneer er gebruik wordt gemaakt van een aparte dataset op basis van een OTL, hoe leg je de relatie tussen de OTL dataset en het BIM-model vast? En zo zijn er nog vele aspecten.
• Houdt rekening met standaarden en zorg dat deze elkaar aanvullen en versterken. Zo beschrijft IFC voor objecttype een aantal basis eigenschappen. De BIM Basis ILS versie 2.0 en de BIM basis infra geven een aantal minimale uitgangspunten. Houdt rekening met het toepassen of uitvragen van een OTL met de standaarden van de keten. Hoe ga je om als brandwerendheid een basiseigenschap is in IFC, maar ook een vereiste in je OTL?
• Veel OTL’s, welke linked data technieken gebruiken, worden als bestand uitgewisseld. Dit is controversieel aan het linked data gedachtegoed. Is dit logisch of kan dit anders?
• Dit artikel is ingegaan op uitwisseling van de data middels BIM en/ of een (linked) data bestand. Dit (linked) data bestand wordt in de praktijk ook vaak vervangen door andere bestandsformaten, zoals bijvoorbeeld XML of Excel.
• Wanneer er gerefereerd wordt tussen verschillende databronnen (bijvoorbeeld tussen een 3D object en de daarbij behorende data), leg de relatie van het object naar de data, of visa versa, eenmaal vast. Wanneer er behoefte is aan de inverse relatie, genereer deze op basis van de relatie of laat een applicatie deze realtime leggen. Dit geldt ook voor documenten en tekeningen.
• Leg een referentie/classificatie aan van ieder object in het 3D-model naar een objecttype in de OTL.
• Leg een verwijzing aan van ieder object in het 3D-model naar het databestand, of visa versa.
• Instantieer naast de objecten ook document en tekening in het databestand. Dit kan zijn in de instantie dataset van de OTL, of in het IFC model en leg een verwijzing van de data naar het document. De inverse relatie kan ook interessant zijn, zo kan je op een 2D tekening de referentie op nemen in de stempel om vanuit daar direct naar de metadata van de tekening te gaan en de gerelateerde bronnen zoals het BIM-model.

Conclusie en vervolg

De variant om data te scheiden, of deels te scheiden, heeft als voordeel dat je data kunt vastleggen in legio verschillende applicaties. Zo kun je de data buiten modelleer applicaties bewerken en zijn er minder personen met kennis van de betreffende modelleer applicatie nodig. Het hoge niveau van detail- en informatiebehoefte van de assets, de vervangbaarheid van onderdelen en de organisaties in de keten (gespecialiseerd en grotere organisaties) heeft geleidt tot het advies om te kiezen voor variant 1, data en geometrie scheiden. Het gebruik van open standaarden voor zowel de OTL als BIM is geadviseerd, en wordt verder uitgewerkt.

Met dit advies ligt er een basis van een corporate policy waardoor TenneT op een eenduidige en duurzame wijze verder gestalte kan geven aan het BIM programma. Vervolgstappen worden nu gezet in het verfijnen van de eisen voor de data-uitwisseling met het gebruik van OTL en BIM. Deze verfijnde eisen worden in een volgende pilot getest, om te borgen dat de gestelde eisen haalbaar zijn én om verbeteringen in het opstellen en de uitwisseling van de data aan het licht te brengen. Een zeer praktische aanpak dus, wat direct resultaat op levert. De uitvoering en leerpunten van eisen aan OTL en BIM in de pilot zullen worden toegelicht in een volgend artikel!