IFC als een universele indeling voor gegevensuitwisseling

IFC als een universele indeling voor gegevensuitwisseling
IMS team-Marcel-Kunzmann-
Bijgedragen door: Marcel Kunzmann

Marcel is een technologieconsultant en leverancier van ideeën voor onze software. Hij bepaalt wat technisch haalbaar is en test opkomende technologieën, zoals AR en IoT. Na het werk stapt hij op zijn fiets - zijn analoge compensatie voor digitale topprestaties.

De Industry Foundation Classes IFC worden standaard sneller. Enerzijds wordt IFC5 gepland en zal dit binnenkort de eerste pre-release zijn. Tegelijkertijd zijn recent nieuwe werkgroepen gevonden die met behulp van de IFC-standaard het openBIM-concept proberen te vestigen op nieuwe gebieden.

De vereniging buildingSMART heeft onlangs opgeroepen tot een werkgroep om de IFC voor "Locatie, landschap en stadsplanning" uit te breiden. Je doel is om alle buitenkant te dekken overkoepelende IFC-standaard invoegen.

Maar hoe verstandig is zo'n project eigenlijk? Hebben we echt zo'n uitgebreide standaard nodig?

En hoe past het in BIM en CAFM verstandige?

Mogelijk is er al in de onderbouw

Wat met de nieuwe werkgroepen moet worden beschreven, kan technisch al in IFC worden weergegeven. In IFC kunnen gebruikers objecten die niet in de catalogus zijn opgenomen, definiëren als zogenaamde IFC-proxy's. Deze krijgen individuele kenmerken, de zogenaamde IFC-eigenschappenverzamelingen, Het probleem: vanwege de eigenschappen die naar smaak zijn toegewezen, is semantisch transparante en dus betrouwbare gegevensuitwisseling tussen verschillende partners niet langer mogelijk.

Het feit dat de nieuwe IFC-werkgroepen vorm heeft te maken met een tekortkoming van de norm: IFC is momenteel nog steeds erg gebouwgericht, schrijft buildingSMART zelfkritisch in de aankondiging van de landschapswerkgroep. Er is geen expliciete semantiek voor de beschrijving van buitenfaciliteiten. Noch bomen, noch tuinmeubilair, paden en hun bedekkingen, waterleidingen en riolen konden worden voorgesteld met de beschikbare elementen. En ook niet de structuur van het landschap of objecten erin, zoals water en meren.

IFC-werkgroepen overal

Deze kritiek kan ook analoog worden toegepast op de andere gebieden waarop werkgroepen de afgelopen maanden zijn samengekomen. Deze omvatten die voor verkeersroutes, bruggen, tunnels, spoorlijnen of voor luchthavens. Als deze groepen bindende resultaten overeenkomen, zou de IFC-standaard de beschrijving van een aanzienlijk meer gebouwde en ontworpen omgeving en infrastructuur mogelijk maken.

Sectoren beginnen ook betrokken te raken. Een voorbeeld is de prefab industrie. Ze vormde de IFC Precast-werkgroep en werkte aan de modellering van ingebouwde onderdelen. Als een langetermijndoelstelling zou het mogelijk zijn om elk afgewerkt onderdeel duidelijk te identificeren. Van planning tot productie door machines die IFC-gegevens gebruiken voor controle, tot assemblage. Dit zou traceerbaarheid bieden - niet alleen gedurende de levenscyclus van gebouwen, maar gedurende de uitgebreide levenscyclus van componenten.

Met de uitbreiding naar IFC5 heeft buildingSMART een ander belangrijk doel: meer gestandaardiseerde workflows creëren. De reden is dat door de toenemende verspreiding van BIM, een toenemend aantal gebruikers uit steeds meer transacties en gebieden de BIM-methode gebruikt. De vereniging stelt dat het eisenprofiel voor de beschrijvingsstandaard moet worden uitgebreid, zodat de gegevensuitwisseling in de toekomst blijft werken.

Alleen: hoe relevant is zo'n uitbreiding echt, vooral met het oog op BIM en CAFM? En er is ook de vraag: wie profiteerde van de uitbreidingen als de huidige IFC4-norm - bijvoorbeeld in Duitsland - alleen rudimentair wordt gebruikt?

De kern: wat maakt het uit?

Ik geef toe dat de vraag fout is. Een norm is onmiskenbaar altijd welkom en fundamenteel relevant. Het helpt om inhoud bindend te houden voor verschillende gebruikers. Daarom moet worden gevraagd hoe de implementatie in dit land kan worden verbeterd. Basics zijn te vinden:

Gegevens voor infrastructurele CAFM zijn bijvoorbeeld te vinden in de meeste BIM-modellen. De mogelijkheden van IFC blijven echter vrijwel altijd onbenut in technische systemen. Dit ondanks het feit dat er binnen de IFC "Domain Layer" voldoende mogelijkheden zijn om ook hier te modelleren.

BIM-modellen die ik vandaag heb, laten de gapende hiaten zien: planners gebruiken vaak de IFC-entiteiten van een hoger niveau in plaats van de specifieke subtypen. In de elektrische / airconditioningtechnologie wordt alles als een vast tarief beschouwd IFCFlowTerminal aangewezen, zelfs als het een eenvoudige lamp of een radiator is. Of zinvolle entiteiten worden niet gekozen. Het gebeurt dus dat op het gebied van brandbeveiliging de SHEV-flappen vaak worden gebruikt als IFCWindow en dus worden weergegeven als een venster.

Of het zal de generieke manier zijn IfcBuildingElementProxy zo gekozen dat bijvoorbeeld liften niet meer dan IfcTransportElement van het type LIFT zijn herkenbaar.

Voor CAFM en BIM zijn de toevoegingen aan IFC en de wijziging van IFC5 een goede en wenselijke vooruitgang. Maar om de uitbreidingen vruchten af te werpen, moeten hun mogelijkheden consequent worden gebruikt. Specialistische planners klikken zelden hun weg door de diepten van de nomenclatuur. Tijdens het wandelen moet er een complete vertaalmatrix in het bedrijf zijn die elk componenttype toewijst aan de overeenkomstige IFC-entiteit.

Vereis actief fijne differentiatie

De noodzakelijke fijne differentiatie moet actief worden geëist - zij het door de eigenaar van het gebouw, door de latere gebruiker en exploitant, of door partners die afhankelijk zijn van duidelijke informatie in de loop van het BIM-proces.

Je moet ook voorzichtig zijn met planningssoftware. Standaard worden alleen algemene entiteiten begunstigd. Gevoelige IFC-exporten worden alleen gemaakt door de bijbehorende BIM-ontwerptools zoals Revit of Allplan te parametreren.

BIM-manager als poortwachter

Het is de verantwoordelijkheid van de BIM-manager om ervoor te zorgen dat de informatie van IFC correct wordt opgeslagen in het BIM-model. Hij moet erop toezien dat de geplande nomenclatuur van het project wordt nageleefd en moet er actief om vragen als deze wordt genegeerd.

De aankomende uitbreidingen zullen de IFC immers helpen zijn weg te vinden naar nog meer industrieën als een universeel dataformaat. Dit maakt het doel van openBIM om als een centrale database en uitwisselingsformaat te fungeren waarschijnlijker. En dit moet hand in hand gaan met een toenemende discipline bij alle betrokkenen. Iedereen zou er baat bij hebben, zowel met het oog op transacties als op samenwerking of met het oog op de internationalisering van projecten.

Dus ik kan alleen maar adviseren dat we allemaal meespelen. Dan is de standaard zoals vandaag met IFC4 en in de toekomst ook als IFC5 voor BIM CAFM erg handig.

Met vriendelijke groeten

handtekening KUN IFC als een universele indeling voor gegevensuitwisseling »IMSWARE.de

Uw beoordeling

gemiddelde 4.5 / 5. Aantal stemmen: 8

Beoordeelt u als eerste :-)

Geweldig, heel erg bedankt!

Misschien wil je ons volgen op ...

Het spijt ons dat je dit bericht niet leuk vond.

Hoe kunnen we dit verbeteren?

blog
Vorige lezing
Allemaal met slechts één software CAFM bij ALNO AG in Pfullendorf
Volgende lezing
Kerstmis: elektrisch, maar onderhoudsvrij!