Utbyte av en IFC-modell

Utbyte av IFC-modeller sker kontinuerligt under ett projekt och har olika syften, exempelvis för:

• modellsamordning,
• utbyte mellan projektörer,
• mängdberäkningar,
• energianalyser,
• produktion, och
• drift- och underhållsplanering.

Oavsett syfte måste beställaren av information definiera aktuella krav i en leveransspecifikation för avsett syfte. Denna metod går inte igenom hur detaljerade krav på objekt i en leveransspecifikation ska uppfyllas vid utbyte av IFC-modeller, utan i denna metod ingår krav på informationsmängden i sin helhet. Följande moment ingår i denna metod:

1. IFC-entiteter
2. Filformat
3. Versioner av IFC och Model View Definitions
4. Metadata
5. Attribut, Parameter- och Mängdgrupper
6. Utrymmesgränser
7. Insättningspunkt

IFC-entiteter

IFC-modeller är uppbyggda med en fördefinierad struktur av IFC-entiteter enligt den förenklade figuren nedan.

(Figur: IFC entitets i trädstruktur)

De fyra översta IFC-entiteterna i strukturen är så kallade diskreta objekt, det vill säga objekt som inte har någon geometrisk representation. Nedan följer en kort beskrivning av dessa:

• IfcProject – Den översta noden i modellen som representerar aktuellt projekt och därmed även IFC-filen i sin helhet.
• IfcSite – Denna nod representerar ofta aktuell fastighet och benämns vanligen med fastighetsbeteckning. Ett IfcProject bör enbart innehålla en underliggande IfcSite.
• IfcBuilding – Denna nod representerar aktuellt byggnadsverk, ofta en byggnad, och benämns vanligen med byggnadsverksbeteckning, exempelvis HUS 02, eller enbart 02. En IfcSite kan innehålla flera underliggande IfcBuildings men rekommendationen är att enbart levererar en IfcBuiding per IfcSite, det vill säga en byggnad per IFC-fil.
• IfcBuildingStorey – Denna nod representerar aktuella våningsplan inom ett byggnadsverk. En IfcBuilding kan innehålla en eller flera IfcBuildingStoreys.

Det är viktigt att samordna namngivning av dessa noder för att underlätta utbyte av information. Det krävs vanligen att specifika parametrar nyttjas för denna information i originalprogramvarorna för att informationen exporteras till IFC-formatet, det vill säga på attributet Name för varje entitet ovan.

Övriga IFC-entiteter i strukturen ovan representeras av geometriska objekt. I figuren presenteras de fem vanligaste IFC-entiteterna, men det finns fler inom IFC-formatet. Nedan följer en kort beskrivning av dessa:

• IfcBuildingElement – Denna IFC-entitet och dess underliggande IFC-entiteter representerar objekt inom arkitektur och byggkonstruktion, exempelvis fönster (IfcWindow), väggar (IfcWall), och pelare (IfcColumn).
• IfcCivilElement – Denna IFC-entitet representerar infrastrukturella objekt.
• IfcDistributionElement – Denna IFC-entitet och dess underliggande IFC-entiteter representerar objekt inom installationssystem, exempelvis kabelstegar (IfcCableCarrierSegment), pumpar (IfcPumt), och handfat (IfcSanitaryTerminal).
• IfcFurnishingElement – Denna IFC-entitet och dess underliggande IFC-entiteter representerar fast och lös inredning.
• IfcSpace – Denna IFC-entitet representerar utrymmen.

Det är viktigt att dessa objekt modelleras på det våningsplan de är belägna. Om objekt får genom flera våningsplan (exempelvis en prefabricerad stålpelare) modelleras det på det lägst belägna våningsplanet. Vid export till IFC förekommer det ofta ett val att dela dessa objekt per våningsplan. Rekommendationen är att inte göra den uppdelningen vid export, utan istället modellera objekt som de är tänkta att byggas. Detta har en stor betydelse vid syfte att nyttja IFC-modeller för mängberäkning.

De geometriska objekten som beskrivs ovan kan även grupperas i olika typer av system. Det vanligaste är att objekt inom klassen IfcDistributionElement grupperas i så kallade IfcDistributionSystems där varje grupp representerar ett installationssystem, exempelvis luftbehandlingssystem, kallelsesignalsystem, och tappvattensystem.

Filformat

IFC-formatet kan levereras i två olika format, .ifc och .ifcXML, där båda formaten även kan packas ihop till så kallade zip-filer, .ifcZIP. Tabellen nedan ger en kort beskrivning av dessa format.

Det pågår även arbeten med att skapa ytterligare format av IFC-data, bland annat ifcJSON för att utbyta IFC-data via webgränssnitt.

Versioner av IFC och Model View Definitions

Vid utbyte av IFC-modeller ska både version av IFC-formatet och tillhörande Model View Definition (MVD) vara överenskommet. Programvaruleverantörer kan i dagsläget certifiera sina verktyg för följande versioner:

• IFC4 ADD TC1 [ 4.0.2.1] med tillhörande MVD Reference View [RV1.2], och
• IFC2x3 TC1 [2.3.0.1] med tillhörande MVD Coordination View [CV2.0].

För aktuella IFC-versioner och dess status, se buildingSMART International IFC Specifications Database

För aktuella Model View Definitions och dess status, se buildingSMART International MVD Database

För certifierade programvaror, se buildingSMART International IFC Certification Participants

För programvaror som har stöd för IFC men inte är certifierade, se buildingSMART International Standards Implementation Database

Metadata

Vid utbyte av IFC-formatet är det viktigt att kunna se nödvändiga metadata om filen, exempelvis när den skapades och vem som exporterat filen. Denna information finns samlad under följande tre parametergrupper på filninvå:

• File Name,
• File Schema, och
• File Description.

Se metoden Information i IFC-modeller för vidare information och anvisning från respektive programvarutillverkare för tillämpning.

Attribut, Parameter- och Mängdgrupper

I certifierade programvaror mappas programvarutillverkarens objektstyper till IFC-entiteter inom IFC-formatet, exempelvis exporteras en balk som modellerats med orignalprogramvarans balk-verktyg till motsvarande balk inom IFC-formatet, det vill säga IfcBeam. Vidare kan även dessa objektstyper ytterligare definieras genom att mappas till IFC-entiteternas typer (PredefinedType), men detta är i dagsläget ovanligt förekommande. En balk kan exempelvis ytterligare definieras med sex typer av balken, men den kan även vara användardefinierad, eller odefinierad.

Information om IFC-entiteter beskrivs med hjälp av attribut och parametrar där parametrarna antingen ingår i en parameter- eller mängdgrupp vilka beskrivs kortfattat nedan:

• Attribut (Attributes) – Grundläggande information om varje entitet, exempelvis global identifikation (GlobalId), ägare (OwnerHistory), benämning (Name), och beskrivning (Description).
• Parametergrupp (IfcPropertySets) – En grupp av parametrar som ytterligare beskriver IFC-entiteter, exempelvis om byggdelen är bärande eller ej (LoadBearing) och brandteknisk klass (FireRating).
• Mängdgrupp (IfcQuantitySets) – En grupp av parametrar som beskriver IFC-entiteters olika mängder, exempelvis längd (Length) och tvärsnittsarea (CrossSectionArea).

Baserat på beskrivningen ovan är det viktigt att varje objekt modelleras med rätt verktyg i originalprogramvaran, speciellt om syftet är att använda IFC-modellen för mängdberäkningar. Om exempelvis en balk skulle modelleras med originalprogramvarans väggverktyg och därmed exporteras som en IfcWall istället som en IfcBeam kommer det exempelvis inte vara möjligt att få ut information om balkens tvärsnittsarea (CrossSectionArea).

För aktuell mappning av attribut, parametrar, parameter- och mängdgrupper, se respektive programvarutillverkares dokumentation.

Det är ibland möjligt att frångå programvarutillverkarens mappning av objektstyper till IFC-entiteter genom att exempelvis ändra en inställningsfil som styr mappningen eller att per objektstyp eller förekomst överskrida inställningsfilen med så kallade exportparametrar, men detta bör i så stor utsträckning som möjligt undvikas på grund av att de mängdgrupper som kan beskrivas av den ursprungliga objektsklassen möjligen inte kan hanteras av den objektsklass som överskrids.

Följande exportparametrar finns tillgängliga för att överskrida inställningsfilens mappning mot IFC-entiteter:

• IfcExportAs – Överskrider den IFC-entitet som är angiven i aktuell inställningsfil. Ange exakt stavning, enligt buildingSMART International, för den IFC-entitet som ska överskrida den som är definierad i aktuell inställningsfil. Exempelvis kan ett bjälklag (IfcSlab) exporteras som grundkonstruktion (IfcFooting).
• IfcExportType – Överskrider den typ av IFC-entitet som eventuellt är angiven in aktuell inställningsfil. Ange exakt stavning, enligt buildingSMART International, för den typ som ska överskrida den som definierad i aktuell inställningsfil. Exempelvis kan grundkonstruktionen (IfcFooting) detaljeras som en typ av grundbalk (FOOTING_BEAM).

Exportparametern IfcExportType kan även ersättas genom att både ange IFC-entitet och typ (separerade med en punkt) inom exportparametern IfcExportAs, exempelvis IfcFooting.FOOTING_BEAM.

Ett alternativ till att nyttja IFC-formatets inbyggda attribut och egenskapsuppsättningar är att skapa egna egenskapsuppsättningar och tilldela dem till olika klasser inom IFC-formatet, se metoden Information i IFC-modeller. Mängduppsättningar kan däremot inte hanteras av användaren.

Utrymmesgränser

Utrymmesgränser (IfcRelSpaceBoundary) definierar gränser mellan utrymmen och dess omgivande byggdelar. Det finns två typer av utrymmesgränser:

• Nivå 1 – Ingen hänsyn tas till om det finns ett utrymme eller byggdel på andra sidan utrymmesgränsen.
• Nivå 2 – Hänsyn tas till om det finns ett utrymme eller byggdel på andra sidan utrymmesgränsen.
  • Nivå 2, Typ A – Det är ett utrymme på andra sidan.
  • Nivå 2, Typ B – Det är en byggdel på andra sidan.

Vid export av modeller som innehåller utrymmen är det viktigt att definiera vilken nivå av utrymmesgränser som ska exporteras, vilket beror av det aktuella syftet. Dessa utrymmesgränser är exempelvis viktiga vid energianalyser och mängdberäkningar.

Förutom ovan två beskrivna nivåer brukar det även vara möjligt att helt exkludera utrymmesgränser från vid export.

Insättningspunkt

När modeller delas är det viktigt att alla ingående modeller ligger rätt placerade i aktuellt koordinat- och höjdsystem. Detta säkerställs främst genom samordning mellan respektive originalprogramvara. Programvaror hanterar koordinater på olika sätt på grund av olika tekniska begränsningar. I vissa programvaror sker modellering enligt aktuellt primärnät, medan i andra sker modellering enligt en lokal insättningspunkt som direkt relaterar till aktuellt primärnät. Oavsett metod är rekommendationen att IFC-modeller alltid ska exporteras enligt aktuellt primärnät. Se även metoden Lokalt och Globalt Koordinat- och Höjdsystem för en 3D-CAD-modell.