Information Delivery Specifications en Common Data Environment API´s
In september organiseerde Stumico een tweetal webinars. De eerste ging over de ontwikkeling en toegevoegde waarde van Information Delivery Specifications (IDS) voor de communicatie in bouwprojecten en bij het tweede webinar werd ingegaan op openCDE API’s. Twee onderwerpen die de nodige aandacht verdienen in de huidige markt.
Door de redactie
De IFC (Industry Foundation Classes) is een open neutraal formaat dat ontwikkeld is voor het delen van een 3D Bouw Informatie Model (BIM), Daardoor is dit initiatief al intelligenter dan het digitaal uitwisselen van 2D-tekeningen en hoeveelheden. IFC is sinds enkele jaren als internationale standaard vastgelegd in de ISO 16739-1:2018. Om IFC beter in de praktijk te kunnen toepassen, zijn er zaken aan toegevoegd, zoals in Nederland de ILS (Informatie Levering Specificatie) en NL-SfB-afspraken. IDS is tenslotte weer een toevoeging om de im- en export van ILS te verbeteren.
Wat zijn MVD’s?
Voordat Van Berlo dieper inging op de toegevoegde waarde van IDS, lichtte hij de rol van Model View Definition ofwel MVD’s toe. De totale IFC-standaard bestaat uit een hiërarchische boomstructuur om alle bouwonderdelen en hun onderlinge relaties (semantisch) te beschrijven. Bij de vertaalslag van alle theoretische afspraken naar de praktijk implementeren leveranciers maar een deel van de totale IFC, afhankelijk van de eigen specialiteit (bouw, installatie of infra) en softwarefuncties.
Op basis van de hele IFC definieert elke softwareleverancier een MVD, die als daadwerkelijk uitwisselingsbestand wordt gebruikt. Met als praktisch nadeel mogelijke interoperabiliteitsfouten tussen verschillende MVD’s. Omdat alle MVD’s eindigen op .ifc, verwacht je als gebruiker echter geen problemen. Om het plaatje compleet te maken is de Nederlandse Basis ILS ook een soort MVD, terwijl er in onze bouwpraktijk weer verschillende ILS’en worden gebruikt.
Use-cases nodig
MVD’s en ILS’en zijn beide op ‘use-cases’ gebaseerde uitwisselingsafspraken, die in de praktijk echter nog onvoldoende worden nageleefd. Als gevolg daarvan ontstaan er bij het exporteren en importeren van een BIM mogelijke communicatiefouten, die veelal niet worden ontdekt door de gebruikte softwaretool. Om dit soort fouten te voorkomen, wordt de IFC vanaf versie 5 uitgebreid met IDS om use-case specifiek een ILS vast te leggen en de softwaretools met IDS-mapping tables om hun import/export te verbeteren.
Voor de verdere ontwikkeling van IFC5 met IDS als nieuwe communicatietaal, is het echter belangrijk dat verschillende marktpartijen regelmatig voorkomende use-cases kenbaar maken bij de IFC-ontwikkelaars. In Nederland is Cyrille Pennavaire als projectleider daarvoor het aanspreekpunt (tevens BIM-manager bij Heijmans). Het doel van de verdere IDS-ontwikkeling is zowel de communicatie voor slimmer bouwen te verbeteren als de certificering van softwaretools die IFC ondersteunen te verduidelijken.
Nederland loopt voorop
Dat IDS leeft onder de Stumico-leden en dus in de Nederlandse bouwpraktijk, bleek uit de vele praktische vragen na afloop van de technische uiteenzetting. Onder andere over aan welke bijdragen de grootste behoefte is. Een voorbeeld daarvan is welke eisen er bovenop een ILS nog extra worden gesteld, om het Basis ILS praktischer toepasbaar te maken. Voor geïnteresseerden is de eerste IDS-specificatie nu al te raadplegen op de github-server van buildingSMART.
Er was ook een vraag over de relatie tussen OTL (Object Type Library) en IDS. OTL is een gedetailleerde specificatielaag om bijvoorbeeld een typische Nederlandse wegverbinding als extensie van IFC-roads te beschrijven. Het is daarmee ook een bron voor de samenstelling van een IDS. Volgens Van Berlo loopt Nederland voorop bij het vastleggen van IDS’en voor dit internationale project. Hij verwacht de eerste publieke versie van IFC5 eind dit jaar met daarbij dan een 1.0-versie van de nieuwe IDS.
Common Data Environment
Dat IDS van belang is voor de uitwisseling van bouwinformatie, is duidelijk, maar er zijn meer zaken die een rol spelen bij BIM in de praktijk. Naarmate het gebruik van een BIM in projecten toeneemt, wordt het bijvoorbeeld ook belangrijker dat alle informatie op een eenduidige wijze tussen de bouwpartners en gebruikte softwaretools is uit te wisselen. Een op open standaarden gebaseerde Common Data Environment (CDE) met bijbehorende API’s gaat helpen de communicatie te verbeteren. Dat is nodig, want voorlopig communiceert nog geen enkel mens of IT-systeem foutloos en volledig. In bouw- en infraprojecten, die door technische ontwikkelingen en toenemende regelgeving complexer worden, leiden communicatiefouten ook anno 2020 nog tot onnodige faalkosten en inefficiencies. Op het gebied van datacommunicatie worstelen bouwteams al decennia met de incompatibiliteit tussen gebruikte bestandsformaten en zowel de correctheid als compleetheid van alle digitale informatie.
In vergelijking met de vroegere verschillen tussen bestandsformaten als dwg, dxf, dgn et cetera en het gebruik van lagen, voegt het BIMmen een derde dimensie en meer data toe aan de communicatie-uitdagingen. Gelukkig conformeren steeds meer softwareleveranciers en bouwpartijen zich aan open standaarden, zoals de NEN-EN-ISO 19650. In 2014 is een buildingSMART-werkgroep begonnen aan de missie om met behulp van openCDE API’s dataverlies in projecten te voorkomen en tijdbesparingen te realiseren bij het multidisciplinair integreren, delen en gebruiken van BIM-informatie.
Nieuwe generatie centrale bron
Common Data Environment (CDE) is de Engelse term voor één enkele bron van de waarheid. Het belang en de voordelen daarvan worden de laatste jaren meer benadrukt. Tijdens het mainframe-tijdperk was er maar één digitale informatiebron, de centrale database. In het huidige IT-landschap met bedrijfssystemen, hybride cloudservices en mobiele apps worden er op zoveel plaatsen data gecreëerd, gedeeld, opgeslagen en geraadpleegd dat mensen het inzicht en overzicht verliezen. Een CDE is de nieuwe generatie centrale bron waar iedereen de correcte en laatste versie van informatie kan vinden en gebruiken.
De ontwikkeling en het gebruik van een CDE is dus helemaal niet nieuw, maar het feit dat deze op open standaarden wordt gebaseerd, biedt een aantal voordelen. Bij het gebruik van een openCDE in de bouw en infra worden alle betrokken partijen minder afhankelijk van de softwareleveranciers, terwijl de spelregels voor informatiecommunicatie eenduidig zijn. In de ISO 19650-standaard bestaat zo’n CDE uit vier onderdelen, genaamd werkgebied, gezamenlijk gebied, publicatiegebied en archiefgebied, afhankelijk van de toepassingsfase in de levenscyclus van een gebouw of infrastructuur.
Net als voor Information Delivery Specifications (IDS) zijn voor de ontwikkeling van openCDE API’s use-cases nodig. Alle bouwpartners hebben te maken met integratie-uitdagingen bij het delen van informatie, maar de impact ervan op projecten en dus de prioriteit verschilt. Om de betrokkenheid bij en het draagvlak voor gebruik van de openCDE API te vergroten, is het belangrijk als eerste een oplossing te bieden voor vaak voorkomende use-cases. Tijdens het openCDE API’s-webinar zijn onder andere het uploaden van files en het creëren van automated dataflows als voorbeelden belicht.
De openCDE API’s van buildingSMART worden ontwikkeld op basis van zes principes. De eerste is dat elke API een specifieke toepassing of workflow (use-cases) adresseert. Daarnaast dienen API’s samen te werken en er hetzelfde uit te zien. Het derde principe is dat eerst de software wordt gemaakt en daarna pas de specificaties. De vierde regel is dat gebruikers de API´s zullen testen en dat de ontwikkelaars vervolgens hun feedback verwerken. Het vijfde en zesde principe is ten slotte dat eventuele beperkingen voor het gebruik worden opgelost en dat de ontwikkelaars openstaan voor deelname en inbreng.
Organisatie en roadmap
De openCDE API’s-werkgroep stemt tweewekelijks alle actiepunten en de planning met elkaar af. Verder wordt er twee keer per jaar een hackaton georganiseerd en indien nodig een focusgroep aan het werk gezet. In lijn met het open karakter van deze ontwikkeling kan iedere geïnteresseerde de projectvoortgang volgen via de website en een Github-server van buildingSMART. Tijdens het webinar is tevens de relatie met het BIM Collaboration Format (BCF) belicht, gerelateerd aan de adoptiecurve. Daarvoor is al een open API beschikbaar.
Volgens de gepresenteerde roadmap komt er begin 2021 een eerste versie van de openCDE documents API beschikbaar, voor interactieve dataflow tussen een gebruiker en server. Daarna volgen varianten voor de niet-interactieve dataflow tussen servers, een property exchange API en BCF 3.0. Omdat het succes van openCDE API’s afhankelijk is van organisaties die ermee gaan werken, heeft de werkgroep behoefte aan meer feedback uit de praktijk. Ook voor softwareleveranciers zijn de openCDE API’s interessant, omdat het door de markt gevraagde functionaliteit is die ze zelf niet meer hoeven te ontwikkelen.
