De toekomst is open
Omdat er waarschijnlijk nooit een holistische oplossing zal zijn waarmee het hele proceslandschap in kaart kan worden gebracht op weg van een eerste basisbeoordeling tot het beheer van een gebouw, zijn open interfaces nodig. Het idee om de hele levenscyclus van een gebouw digitaal in kaart te brengen kan alleen werken als verschillende softwareomgevingen succesvol samenwerken. In het verleden heeft dit besef ertoe geleid dat de belangrijkste fabrikanten van softwareoplossingen die geschikt zijn voor BIM (bijvoorbeeld voor CAD, AVA en CAFM) zich openstelden voor niet aan eigendomsrechten gebonden technologieën zoals IFC en BCF. Dit is ongetwijfeld een belangrijke basis voor de fundamentele haalbaarheid van open processtructuren. De reality check laat echter zien dat de praktische implementatie van de benodigde use cases op veel plaatsen nog als toekomstvisie op de flip-over hangt.
Dit is precies wat er de komende jaren zal moeten veranderen. Waar vandaag de dag geïsoleerde oplossingen zoals "klein BIM" of "gesloten BIM" nog net door de beugel kunnen als state of the art, zullen in de toekomst de tekenen wijzen naar "groot open BIM", een interdisciplinaire samenwerking op basis van neutrale uitwisselingsformaten. Enerzijds kan dit worden afgeleid uit de concrete acties van prominente softwarefabrikanten, zoals de recente toetreding van Autodesk tot de Open Design Alliance. Anderzijds verwijzen richtlijnen voor de uitwisseling van informatie in BIM-projecten steeds vaker naar IFC volgens DIN EN ISO 16739 en BCF. De ontwerpen VDI 2552 Deel 9 (Classificatiesystemen) en VDI 2552 Deel 11.2 (Informatie-uitwisselingsvereisten: Sleuf- en doorbraakontwerp) zijn hier voorbeelden van. DIN EN ISO 19650 is weliswaar grotendeels formaatneutraal geschreven, maar laat de lezer tussen de regels door ook weinig twijfel bestaan over de basis waarop de implementatie van de concepten die het bevat, wordt aanbevolen.
BIM use cases en model view definition
Als je een IFC-bestand ontvangt van een andere projectdeelnemer of als je je eigen werkstatussen aanlevert, moet je eerst het doel van deze informatieoverdracht verduidelijken. Idealiter is in een BIM-ontwikkelingsplan een specifieke diepte van informatievereisten gedefinieerd, zodat de informatieverstrekker de informatieontvanger precies die informatie kan leveren die nodig is voor de beoogde use case. Als slechts een deelverzameling van een model aan de ontvanger wordt gegeven, wordt dit een model view definition (MVD) genoemd. In tegenstelling tot eenvoudige aanzichtfilters, zoals bekend van CAD-toepassingen, kan een MVD niet alleen worden gebruikt om een aanzicht van het model te genereren, maar ook om het type en de reikwijdte te definiëren van de geometrische en alfanumerieke informatie die moet worden geëxporteerd. De beschrijving van een componentgeometrie kan bijvoorbeeld worden omgezet in een expliciete vorm (vlakke grensvlakken) of het aantal te exporteren attributen kan worden beperkt tot de vereiste en reeds opgeslagen informatie. Dus als men zegt dat men een IFC verwacht voor een bepaalde toepassing, dan bedoelt men eigenlijk een MVD.
In de loop van de IFC-ontwikkeling zijn enkele gestandaardiseerde MVD's gepubliceerd, zoals de prominente IFC 2x3 Coordination View 2.0, die de subset van het IFC 2x3-schema definieert die nodig is voor coördinatiedoeleinden. De meeste omgevingen staan ook export met upstream modelfilters toe, evenals het gebruik van optionele exportinstellingen, waarmee gebruikers in beperkte vorm hun eigen MVD's kunnen definiëren. Bovendien kan de gebruiker de IFC-klassen en -typen verfijnen via een (handmatige) classificatie en een toewijzing van type-specifieke attribuutverzamelingen, als de gebruikte auteursomgeving niet zonder tegenstrijdigheden kan worden gekoppeld aan het gebruikte IFC-schema. Deze stap is echter een uitdaging voor de meeste gebruikers vanwege de complexiteit van de interfaces. Zelfs als een bepaalde kracht van de interfaces nodig is om een zo breed mogelijk scala aan gebruikssituaties te dekken, worden de invoer- en uitvoerstappen in de praktijk beperkt tot het gebruik van eerder gedefinieerde configuratieprofielen. Uiteindelijk is het hetzelfde als met de projecttemplate: één keer moet iemand in het bedrijf definiëren hoe het eruit moet zien. De andere medewerkers gebruiken dan gewoon deze sjabloon. Wat betreft de behandeling van architectuurmodellen zijn er al overeenkomsten tussen verschillende auteursplatforms (bijvoorbeeld de "IFC Model Exchange" add-in voor vereenvoudigde uitwisseling tussen Archicad en Revit). Aan de kant van TGA zijn er echter nog maar een paar gevorderde gebruikers die de IFC-interface van Revit voldoende begrijpen om er open planningsprocessen mee te realiseren.
Waarom is het gebruik van op IFC gebaseerde workflows in TGA dan zo moeilijk?
Nou, als je een semantisch of consistent geclassificeerd gebouwmodel wilt representeren, biedt IFC honderden gestandaardiseerde klassen, typen en eigenschappensets waarmee dit bijna zonder tegenspraak kan worden bereikt. Een auteursomgeving zoals Revit heeft deze eis niet diepgaand. Hier is het voldoende dat componenten zijn onderverdeeld in categorieën op basis van hun ruwe beoogde gebruik en hun bewerkingsgedrag (bijvoorbeeld als wanden, plafonds, leidingaccessoires, HVAC-componenten, enzovoort). Maar juist deze omstandigheid van niet-unieke machinevertaalbaarheid van IFC-typen en hun parametrische eigenschappen in auteursomgevingen vereist extra aandacht, zowel bij het gebruik van een IFC als constructiedocument als bij het exporteren van een IFC voor distributie.
Om informatie-uitwisseling via open standaarden te laten slagen, moeten de modellen dus voldoen aan een overeengekomen MVD, d.w.z. componenten moeten correct geclassificeerd zijn en voorzien van de vereiste attributen. En de software die gebruikt wordt aan zowel de verzender- als de ontvangerkant moet de beschikbare informatie kunnen verwerken.
TGA-modellen coördineren met IFC
Voordat we uitleggen hoe we onze eigen IFC-uitvoer kunnen genereren, gaan we eerst in op het onderwerp door twee veelvoorkomende use cases te bespreken waarbij de TGA-planner een IFC ontvangt als basis voor de planning.
Coördinatie van verschillende beroepen
Als een kantoor niet alle beroepen in hetzelfde auteurssysteem plant of als er verschillende planners van gebouwinstallaties bij een project betrokken zijn, kan het gebeuren dat IFC wordt overeengekomen als gemeenschappelijke noemer voor coördinatie. In dit geval bevinden Revit-gebruikers zich in de situatie dat ze in hun eigen planning moeten verwijzen naar de planningsstatus van een ander gebouwbeheersysteem. De beste manier om dit te doen is door een IFC-bestand te koppelen. Hierbij maakt de IFC-interface van Revit op de achtergrond een Revit-project aan met de extensie ".ifc.rvt". Daarnaast wordt er een logbestand aangemaakt voor het insluiten van fouten en een bestand met gedeelde parameters met de extensie ".ifc.sharedparameters.txt", dat in Revit kan worden ingesteld om gedeelde parameterdefinities bekend te maken in het project.
In ons voorbeeld nemen we een verwarmingssysteem dat is ontworpen met LINEAR Design 3D Pipe&Power in AutoCAD en geëxporteerd als IFC 2x3 Coordination View 2.0. Direct na het koppelen in Revit ziet het resultaat er in eerste instantie teleurstellend uit. Waar heldere kleuren in de IFC-viewer de leidingsystemen nog onderscheidbaar maakten (afbeelding 2), zien we na het koppelen een ogenschijnlijk volledig zwart gekleurd netwerk (afbeelding 3). Deze zwarte kleur is echter slechts een representatieprobleem. Als we individuele elementen van dichtbij bekijken, zien we dat deze kleuring het gevolg is van de randen van de expliciete geometriegeneratie. Nu is het in Revit niet mogelijk om de rasterlijnen van geïmporteerde objecten te verbergen via een centraal mechanisme. Er is echter wel de mogelijkheid om Revit met behulp van filters de systemen te laten kleuren op basis van hun systeemclassificatie.
Om dit te doen, stel je eerst het parameterdefinitiebestand vermeld aan het begin met de extensie ".ifc.sharedparameters.txt" in als een gedeeld parameterbestand. Maak vervolgens de daarin opgenomen parameter "IfcSystem" bekend als kopieerparameter voor de relevante categorieën. De classificatie in Revit categorieën en de concrete systeemidentificatie van een component kan worden uitgevoerd door de objecteigenschappen te inspecteren. In dit geval moeten systemen met de aanduidingen "flow" en "return" worden gefilterd. In de Revit view overrides worden regelgebaseerde filters gemaakt voor de leidingcategorieën. Voer als voorwaarde in dat het attribuut "IfcSystem" moet overeenkomen met de waarde "Flow" of "Return". Op dezelfde manier overschrijft men de lijnkleur voor deze filters naar wens.
Na het definiëren van de filters zijn niet alleen de kleuren van de randen aangenamer, het is ook mogelijk om individuele systemen specifiek te tonen en te verbergen door middel van de zichtbaarheidsregeling van het bijbehorende filter (zie afbeelding 4). Op een vergelijkbare manier kunnen ook componentenlijsten worden gemaakt, waarin elementen in koppelingen worden opgesomd samen met hun gedeelde parameters.
In een notendop
Gebruik het automatisch gegenereerde tekstbestand met de extensie ".ifc.sharedparameters.txt" als basis voor het maken van weergavefilters. 1. Maak een filterparameter bekend bij de relevante categorieën.
1. Maak een geschikte filterparameter bekend bij de relevante categorieën, bijv.
| Parameter | Betekenis |
| IfcSystem | Systeemaansluiting ("toevoerlucht", "afvoerlucht", enz.) |
| IfcExportAs | IFC-classificatie ("IfcPipeSegment", "IfcBoiler", "IfcTank" etc.) |
| IfcSpatialContainer | Structureel bovenliggend element (bijv. "begane grond") |
2. stel de weergave van je link in op de instelling "according to basic component view
3. maak regelgebaseerde filters om de zichtbaarheid en weergave van geclassificeerde modelinhoud te regelen.
IFC-architectuur als basis
Een andere use case waarbij een model via IFC als basis wordt gebruikt, is de ontwikkeling van een TGA-model op basis van een bestaande architectuur. In dit geval dient de architectuurtekening verschillende doelen: Enerzijds creëert het onderliggende model een referentiesysteem voor de TGA-modellering en daaropvolgende coördinatietaken zoals slot- en penetratieplanning. Anderzijds dient de architectuur als ruimtelijke begrenzing voor de MEP-ruimtes, die nodig zijn om randvoorwaarden voor het ontwerp te specificeren.
Bij het werken met IFC-architecturen moet rekening worden gehouden met twee essentiële punten: Ten eerste moeten alle relevante componenten en de ruimte-informatie daadwerkelijk worden geëxporteerd. Ten tweede moeten de geëxporteerde componenten ook correct ingestelde IFC-klassen en -typen hebben. Modellen met alleen correct ogende geometrieën, waarbij de aard en functie van de gerepresenteerde componenten niet kan worden afgeleid uit een classificatie, zijn geen goed uitgangspunt.
Informatie
Voor de meeste use cases gebaseerd op een IFC-architectuur is het voldoende als het model alle ruimtebepalende componenten bevat met de bijbehorende classificatie (bijvoorbeeld IfcWalls) en ook openingen voor ramen (IfcWindow) en deuren (IfcDoor) zijn geëxporteerd. Als het IFC-document ook ruimteobjecten (IfcSpace) bevat, is het ook eenvoudig om MEP-ruimten te genereren op basis van een IFC-architectuur met de LINEAR-oplossing en gegevens over te dragen vanuit het architectuurmodel. Op deze manier kunnen de vraagwaarden per ruimte (bijv. luchthoeveelheden, thermische belastingen, enz.) naar de overeenkomstige ruimteobjecten worden geschreven, ongeacht of deze afkomstig zijn van extern bepaalde ontwerpspecificaties of gedetailleerde belastingsberekeningen (zie LINEAR aktuell 1-2020, p. 22 e.v. voor details).
Als u een tijdrovende verbouwing van het gebouw wilt vermijden, is een belangrijke voorwaarde - naast de vereiste geometrieën - de beschikbaarheid van semantische informatie, bijv. IFC-klasse en -type. De minimale omvang moet voor aanvang van het project worden overeengekomen.
Om ervoor te zorgen dat de bovengenoemde semantische informatie niet ten prooi valt aan het importproces, is het belangrijk om de tabel met IFC-importtoewijzingen correct in te stellen. Deze tabel maakt IFC klassen en types bekend bij de corresponderende Revit categorieën en dient zo als referentie voor de importfunctie. De genoemde tabel is gevuld met nuttige suggesties tijdens een Revit-installatie, maar afhankelijk van het architectuurplatform en de gebruikte exportinstellingen kan het nodig zijn om vermeldingen toe te voegen of toewijzingen te wijzigen. Bovendien is het mogelijk om onnodige modelinhoud voor de import te negeren door "DontImport" op te geven in plaats van een Revit categorie.
Na het koppelen van het IFC-architectuurdocument is het eerste wat opvalt dat de raamopeningen, die eigenlijk bedoeld zijn als zuurkastlichamen, expliciet worden weergegeven in de koppeling als objecten van de categorie "General Model". Als u de weergave-eigenschappen van de koppeling opent, ziet u ook dat deze openingen door de importroutine worden opgeslagen in de subcategorie "IfcOpeningElement", die helaas niet wordt weergegeven in het bovenliggende project (afbeelding 6).
Er zijn twee manieren om de openingen te verbergen. De ene is om de weergave van de link te overschrijven met aangepaste instellingen. Anderzijds kan men de basisweergave van de componenten gebruiken en een zichtbaarheidsfilter maken zoals eerder getoond, dat objecten van de categorie "Algemeen model" filtert met de waarde "IfcOpeningElement" voor het classificatieattribuut "IfcExportAs".
Voor het maken van MEP-ruimten op basis van een IFC-koppeling is de functionaliteit MEP-ruimten van de liNear Desktop handig. Deze bepaalt de ruimtecontouren op basis van de IfcSpace-elementen en stuurt parameters zoals naam/nummer en eventuele IFC-attributen naar de bijbehorende MEP-ruimten. Verdere technische randvoorwaarden kunnen dan worden ingevoerd via de eigenschappendialogen of worden overgebracht van een extern ruimteboek naar het TGA-model met behulp van de LINEAR Excel-interface.
TGA-modellen exporteren naar IFC
De uitvoer van een IFC-bestand kan om verschillende redenen worden gedaan. Voorbeelden zijn documentatiedoeleinden, modelcoördinatie, visualisatietaken of gegevensoverdracht in verschillende processtappen (bijv. vroegtijdige communicatie van de ruimtevereisten op hoger niveau voor de gebouwinstallaties, planning van sleuven en doorbraken, overdracht aan hoofdaannemers, facturen van hoeveelheden of hoeveelheidsberekeningen). Daarom is het belangrijk dat de vereisten voor de inhoud en de kwaliteiten al van tevoren zijn overeengekomen. De IFC-exportinterface aan Revit-zijde biedt nu een aantal mogelijkheden die niet noodzakelijkerwijs onmiddellijk duidelijk zijn voor gebruikers. In het volgende willen we drie belangrijke punten bespreken: Classificaties, eigenschappensets en exportinstellingen.
TIP
Gebruik componentenlijsten om snel uw MEP-ruimtegeneratie te controleren.
- Gebruik liNear-Desktop om ruimtegegevens over te brengen van uw IFC-ruimten naar de overeenkomstige MEP-ruimten.
- Maak componentlijsten met de bijbehorende velden (bijv. naam, nummer, oppervlakte).
- Gebruik berekende kolommen en voorwaardelijke opmaak om afwijkingen zichtbaar te maken.
Voorbeeld: Procentuele afwijking van ruimteoppervlakken tussen MEP- en architectuurruimten
De classificatiecascade
Revit biedt standaard verschillende mechanismen om componenten te classificeren. De eenvoudigste vorm van classificatie zijn de categorieën waarin componenten worden ingedeeld. Deze vrij pragmatische manier van differentiëren is eigenlijk alleen bedoeld voor de auteursomgeving, aangezien een raam zich bijvoorbeeld anders gedraagt dan een pijpfitting. Deze zeer grove indeling bereikt zijn grenzen als het aankomt op het maken van een meer gedetailleerde toewijzing, in dit geval voor de juiste IFC export.
Je kunt de moeilijkheid zien als je kijkt naar de tabel met IFC-exportklassen in Revit, die een ruwe mapping maakt van Revit-categorieën naar IFC-klassen. Bijvoorbeeld, de Revit categorie "HLS components", die extreem belangrijk is voor planners van gebouwinstallaties, wordt hier standaard toegewezen aan "IfcBuildingElementProxy", het IFC equivalent van het "General Model". Dit betekent dat een belangrijke klasse van objecten een concrete semantische toewijzing mist. Correct zouden deze HLS-componenten gemapt moeten worden aan een grote subset van de overkoepelende klasse "IfcDistributionElement" (gebouwgebonden componenten), die onder andere verschillende typen generatoren, opslageenheden, verbruikers en regelaars omvat.
Om het exportmodel semantisch te verrijken, is het daarom raadzaam om een nauwkeurigere classificatie uit te voeren. De hiervoor gereserveerde parameternaam is "IfcExportAs". Nieuwere versies van de IFC-interfaces begrijpen nog steeds de definitie "IfcExportAs[Type]", waarmee de gebruiker zowel op kopie- als op typeniveau kan classificeren. In elk geval moet ervoor gezorgd worden dat elk van deze parameters slechts één keer voorkomt in het project. Als families uit verschillende bronnen worden gebruikt, kan het gebeuren dat deze parameters al vooraf zijn ingesteld, maar verschillen in hun unieke identifier (GUID). Mede gezien het feit dat IFC voortdurend in ontwikkeling is, dient een dergelijke voorinstelling door de gebruiker gecontroleerd te worden, aangezien aan het "IfcExportAs" attribuut niet te zien is wat de onderliggende IFC-versie is en er soms nieuwe klassen kunnen worden toegevoegd of verouderde klassen kunnen worden verwijderd.
Het is daarom raadzaam om overeenstemming te bereiken over de te gebruiken classificatieparameters en de in het project te gebruiken families volgens een uniform schema te classificeren. Optimaal is de definitie van de parameters gebaseerd op het bovenstaande schema, dat de introductie van zowel een typeparameter als een kopieparameter vereist. De cascade van de bepaling in de Revit-IFC Exporter wordt getoond in Fig. 8.
Hier wordt de eerste niet-lege parameter in de cascade gebruikt. Bovendien verwerkt de exporteur om historische redenen mogelijke varianten van hoofdletters en kleine letters in de parameternamen. Een specificatie van "IFCExportAs" of "IFCEXPORTAS" kan dus ook worden begrepen.
Voor de overgrote meerderheid van de componenten is een typeclassificatie voldoende. De nieuwe classificatietool van LINEAR, die is opgenomen in het nieuwste feature pack en kan worden uitgebreid met andere classificatieschema's naast IFC, helpt je hierbij.
Eigenschappenreeksen
Naast de classificatie zijn de eigenschappenreeksen van doorslaggevend belang voor een precies passende overdracht van informatie. Door attributen te structureren in eigenschappensets (vaak aangeduid als "Pset") kun je specifiek bepalen welke informatie moet worden gecommuniceerd in het resulterende IFC-bestand en welke niet. U kunt uw eigen attributen structureren of gestandaardiseerde eigenschappensets gebruiken, zoals die in ISO 16739. Bijvoorbeeld zoals gedefinieerd in ISO 16739-1:2018 of de buildingSMART Data Dictionary (bsDD). Een essentiële voorwaarde hiervoor is dat je componenten zijn geclassificeerd.
Revit biedt je verschillende instellingsopties waarmee je de export van eigenschappensets kunt regelen.
Revit eigenschappensets
Deze modus exporteert alle Revit-eigenschappen voor elk element. Deze instelling vereist geen voorbereiding in het project, maar volgt ook geen speciale conventie, aangezien het alleen generieke eigenschappensets ongefilterd exporteert. De resulterende IFC-bestanden bevatten meestal veel onnodige attributen, die ook de bestandsgrootte negatief beïnvloeden. Gebruik in een productieve omgeving wordt daarom afgeraden.
General IFC property sets
Bevat de standaard property sets van de IFC-specificatie, op voorwaarde dat de exporter ze kan identificeren. Als uw parameters niet voldoen aan het IFC-naamgevingsschema, kan de juiste referentie worden vastgesteld via een parameter mapping tabel.
Basishoeveelheden
Exporteert hoeveelheidsafname (Qto) records die eigenschappen bevatten zoals externe afmetingen. Op dit moment lijken deze niet geïmplementeerd te zijn voor TGA-relevante componenten (bijv. Qto_SpaceHeaterBaseQuantities).
Door gebruiker gedefinieerde eigenschappensets
Deze optie gebruikt een extern tekstbestand dat tegelijkertijd de te exporteren eigenschappensets definieert en de mogelijkheid biedt om parameters toe te wijzen aan de standaard attributen volgens je eigen naamgevingsschema. Deze manier is erg flexibel, maar vereist het onderhoud van een extern tekstbestand, dat losgekoppeld is van het eigenlijke model.
Mapping van verschillende informatievereisten
Tot slot kan een ongedocumenteerde functie van de exportinterface worden gebruikt om duidelijk te organiseren welke eigenschapsrecords wanneer moeten worden geëxporteerd.
Hiervoor definiëren we gewoon de kopieerparameter "IfcExportAs" voor de categorie componentlijsten. Deze heeft een speciale waarde "DontExport", die ervoor zorgt dat de hoofdcomponentenlijst niet wordt geëxporteerd, zelfs als we de optie om de PSet-componentenlijsten te exporteren hebben geactiveerd. Bovendien is deze waarde ook handig om de weergave in de projectbrowser te filteren. We kunnen dus het WYSIWYG-principe gebruiken om componentenlijsten te verbergen die niet relevant zijn voor de komende export.
Als we nog verder gaan, kunnen we ook ja/nee specificaties gebruiken in de globale parameters om de overeenkomstige parameter in te stellen op de waarde "DontExport" voor verschillende lijsten, zoals het voorbeeld in Figuur 13 illustreert.
Dit mechanisme kan bijvoorbeeld ook worden gebruikt om de eis voor een instelbaar informatieniveau (LoI) voor de export te implementeren. Dit betekent dat de planner alleen de gegevens kan leveren die in de huidige fase nodig zijn volgens het BIM-ontwikkelingsplan. Voor aanbestedingsdoeleinden kunnen bijvoorbeeld eigendomsgegevens die informatie over de fabrikant zouden onthullen, worden achtergehouden. In een later stadium kan deze informatie worden opgenomen in de IFC-export door de informatiediepte te vergroten.
In een notendop
Verbeter uw IFC-export door creatief gebruik van de ingebouwde Revit tools:
- Filter componenten op basis van IFC-exportclassificatie voor het gericht maken van eigenschappensets.
- Organiseer uw eigenschappenlijsten door filters en contourparameters op te geven in de projectbrowser.
- Bepaal welke informatie u wanneer uitvoert via de IFC-exportclassificatie van de componentenlijsten.
- Koppel de IFC-exportclassificatie aan globale parameters voor gemakkelijke activering/deactivering van meerdere eigenschappensets.
Exportinstellingen
Als alleen bepaalde delen van het model geëxporteerd moeten worden, is het aan te raden om een view aan te maken voor exportdoeleinden en de bijbehorende IFC-exportinstelling te activeren. Op deze manier worden alleen de elementen die zichtbaar zijn in deze view geëxporteerd. Hetzelfde aanzicht moet ook worden gebruikt om de geometrie te maken, wat via een andere optie wordt geregeld. Verder wordt aanbevolen om de IFC GUID's op te slaan in een elementparameter na de export, aangezien dit de bidirectionele verbinding tussen IFC entiteiten en de overeenkomstige Revit elementen documenteert.
Een andere cruciale vraag is de juiste basis MVD - waarnaar verwezen wordt als IFC versie in de Revit instellingen. Revit kan momenteel overweg met verschillende versies van het IFC-schema, waarvan IFC 2x3 en IFC 4 momenteel het meest relevant zijn.
De keuze tussen deze twee versies is niet eenvoudig, want er zijn goede argumenten voor beide. Terwijl IFC 2x3 momenteel een breed praktisch gebruik kent en volledig gecertificeerde interfaces, bevat IFC 4 een aantal nuttige innovaties. Onder andere worden de types Bepaling voor Ruimte en Bepaling voor Leegte geïntroduceerd, die uitstekend geschikt zijn voor coördinatiedoeleinden tussen vakgebieden.
Naast de introductie van nieuwe nuttige klassen en typen en andere verbeteringen, zijn met name de mogelijkheden voor de geometrische representatie van bouwcomponenten aanzienlijk verbeterd. In de bovenstaande grafiek tonen we de exportresultaten van twee geometrische ontwikkelingsfasen van een eenvoudige container met verschillende MVD's. Terwijl de resultaten van de "Coordination View 2.0" en de "Reference View" expliciete geometrieën genereren op basis van vlakke veelhoeken, maakt de "Design Transfer View" de grotendeels verliesvrije representatie van de in Revit gemodelleerde containerbodems mogelijk.
Driehoeksmeting van deze omwentelingslichamen en de cilindrische scheepshuid gebeurt alleen voor weergave in een IFC-viewer (hier: Open IFC Viewer 21.10). Dus terwijl de impliciete representatie een relatief kleine hoeveelheid gegevens oplevert met een hoge geometrische precisie, kost de interpretatie aan de ontvangende kant aanzienlijk meer moeite. Om deze reden en omdat de certificering van de Revit interfaces nog niet is afgerond, is het gebruik van de voordelige "Design Transfer View" in productieve omgevingen alleen geschikt als de compatibiliteit tussen de genererende en consumerende platforms grondig is gecontroleerd.
CONCLUSIE
Dit artikel toont de basisstappen voor de implementatie van open workflows met Revit en IFC. Door gebruik te maken van geavanceerde filtermechanismen op basis van gedeelde parameters en door de componenten in het project op de juiste manier te classificeren, worden zowel het gebruik van een IFC-document als de export van een IFC-bestand met een gedefinieerd informatieschema geïllustreerd.
Om een werkend proces te creëren op basis van de getoonde technieken, zijn gevorderde Revit gebruikers nodig die het technisch-administratieve gedeelte voldoende diepgaand begrijpen om een overeenkomstige basis te creëren. Indien mogelijk moet het volgende grootschalige project niet worden gebruikt als startpunt voor de sprong naar de praktijk. Het is veeleer zinvol dat alle deelnemers de technieken uitproberen in een klein "proefballonnetje".
Wij van LINEAR begeleiden u op dit pad door de weg te effenen voor een intelligente verdere ontwikkeling van onze desktops. Er is vandaag al veel mogelijk, het is relatief duur om te starten, maar het is niet nodig om direct 100% te bereiken. Het belangrijkste is om vandaag de juiste koers uit te zetten om de digitale verbinding niet te missen.
Christian Waluga
Literatuuraanbevelingen
We hebben geprobeerd een zo uitgebreid mogelijk overzicht te geven van IFC-workflows in TGA. Voor de duidelijkheid betekende dit dat er details in verkorte vorm moesten worden gepresenteerd die elders al in detail zijn gedocumenteerd. Meer informatie is te vinden in de volgende bronnen:
- Revit IFC Manual: Gedetailleerde handleiding voor het werken met IFC-bestanden, Autodesk, 2018. www. autodesk.de/campaigns/interoperability/ifc-handbuch
- IFC Specifications Database, buildingSMART, 2021. technical.buildingsmart.org/standards/ifc/ifc-scheme-specifications/
- liNear aktuell 2-2020: De essentie in het oog houden - integrale workflows vanaf het begin
- liNear aktuell 1-2020: workflow gebaseerd op IFC-architecturen