IFC modellcsere

Mi az IFC modellcsere?

Az IFC modellcsere azt a gyakorlatot jelenti, amikor egy modellt kiviszünk a létrehozó szoftverből, és egy semleges, strukturált fájlba helyezzük, amelyet bármely más program a saját feltételei szerint képes olvasni. Az Industry Foundation Classes (IFC) a mögöttes nyílt séma, amelyet a buildingSMART tart fenn és ISO 16739 szabványként publikált. Ez a séma a falakat, csatornákat, csöveket és tereket nevesített, tipizált objektumokként írja le, nem pedig vonalakként és buta geometriaként. A csere itt cselekvés, nem főnév: az exportálás, a leképezés ellenőrzése, az importálás és a körkörös teszt együtt igazolja, hogy a fogadó oldal azt kapta, amit a küldő fél szándékozott továbbítani.

Egy lakóépület-projekt esetében ez minden olyan szakaszváltáskor megtörténik, ahol a felek nem osztoznak egy szoftverlicencen: az építésztől a statikus felé, a statikustól a MEP-koordináció felé, majd a teljes összehangolt készlet a megrendelő saját archívumába kerül az átadáskor. Minden egyes átadás annyira jó, amennyire az azt keresztező IFC-fájl, mert a fogadó eszköz nem fér hozzá ahhoz, ami a natív formátumban maradt.

Mi marad meg ténylegesen egy IFC-export során, és mi nem?

Az export egy fordítás, és a fordítások során vesznek el dolgok. Egy parametrikus családból épített fal az export másik oldalán egy rögzített geometriai darabbá válik, amelyet falként címkéznek meg egy tulajdonságkészlettel: már nem emlékszik az azt létrehozó szabályra, csak az export pillanatában hozzárendelt alakra és adatokra.

Általában megmarad	Általában nem marad meg
Teljes geometria és térbeli hierarchia (telek, épület, szint, helyiség)	Natív parametrikus szabályok (a család vezérlő méretei és kényszerei)
A szerzőeszköz által leképezett szabványos tulajdonságkészletek (anyag, tűzállósági fokozat, hőtechnikai értékek)	Egyedi tulajdonságok, amelyeket az eszköz soha nem képezett le IFC tulajdonságkészletre
Az exportőr által az exportáláskor kiszámított mennyiségek (terület, térfogat, hossz)	Az e mennyiségeket meghatározó képletek és élő kapcsolatok
Objektumtípus és -besorolás (fal, csatornaszakasz, helyiség)	Nézetfüggő 2D feliratozás: méretvonalak, szöveges megjegyzések, részletfeliratok, amelyek egy adott rajznézethez kötődnek

Egy IFC-fájlt fogadó szakági tervező nem tudja úgy szerkeszteni a tervet, ahogy a szerző tette; lekérdezheti, megmérheti, ütközésvizsgálatot futtathat rajta, és mennyiségeket nyerhet ki belőle, de nem a lépcső vagy tetőforma mögötti parametrikus szabályokat. A csere a koordinációt és a nyilvántartást szolgálja, nem a közös szerzői munkát.

Melyik IFC sémaverziót használja egy lakóépület-projekt?

Magának a sémának is vannak verziói, és a választás nem pusztán esztétikai kérdés.

Verzió	Kiadás éve	Mit fed le jól	Gyakorlati megjegyzés
IFC2x3	2005	Épületek: építészet, statika, alapvető MEP	Még mindig a legszélesebb körben támogatott export- és importcél a régebbi szoftververziók között; a legbiztonságosabb alapértelmezés, ha a szakági tervező eszköze ismeretlen
IFC4	2013	Épületek, gazdagabb tulajdonságkészletek, jobb MEP-rendszerek és csatlakozások	Tisztább adatmodell, de nem minden megjelenítő vagy régebbi eszköz olvassa megbízhatóan
IFC4.3 (ISO 16739-1:2024)	2024	Épületek plusz infrastruktúra, például utak, vasutak és hidak	Túlzás egy családi házhoz; akkor releváns, ha a projekt érinti a telek infrastruktúráját

Egy családi ház vagy kis lakóépület esetében az IFC2x3 marad a pragmatikus alapértelmezés a külső cseréhez: ez az a verzió, amelyet minden megjelenítő, ellenőrző és régebbi szakági eszköz panasz nélkül megnyit. Az IFC4-et érdemes megkövetelni, ha a lánc minden résztvevője megerősítette a tiszta exportot és importot, mivel a strukturált MEP-adatokat hűségesebben szállítja.

Miben különbözik az IFC modellcsere egy natív projektfájl elküldésétől?

Egy natív fájl (.rvt, .pln, .skp) a szerző projektjének teljes, szerkeszthető másolata, de csak abban az eszközben nyílik meg helyesen, amelyik készítette, gyakran csak egy adott verzióban. Ha elküldjük egy olyan szakági tervezőnek, aki nem rendelkezik az adott szoftverrel, akkor semmit sem küldünk, amit meg tudna nyitni.

Az IFC-csere a szerkeszthetőséget függetlenségre cseréli: a fogadó fél egy olyan fájlt kap, amelyet bármely IFC-képes megjelenítő meg tud nyitni, a fent leírt parametrikus intelligencia elvesztésének árán. Emellett a licencfüggőséget formátumfüggőségre cseréli: egy natív fájl olvashatatlanná válik, ha a projektben senki sem rendelkezik érvényes licenccel az adott szoftverre, míg egy IFC-fájl, amely egy nyílt ISO-szabvány, olvasható marad, függetlenül attól, hogy ki melyik eszközért fizet még.

A kettő nem versenytárs: natív fájlok a szerzői munkához egy szakágon belül, IFC-csere minden olyan esetben, ami átlépi a szakágak vagy szoftverek határát.

Hogyan néz ki egy fegyelmezett csere-munkafolyamat a gyakorlatban?

Egy megbízható munkafolyamat négy lépésből áll, amelyeket minden modellkiadáskor meg kell ismételni, nem csak egyszer a végén:

• Exportálás meghatározott leképezéssel. A szerzőeszköz IFC-exportbeállításai döntik el, hogy mely tulajdonságkészletek, sémaverzió és geometriai részletességi szint kerüljön ki. Alapértelmezésben hagyva ezek eszközönként és verzióként változnak, ezért a projektben egyszer rögzíteni kell őket, és újra felhasználni.
• Az eredmény ellenőrzése elküldés előtt. Nyissa meg az exportált fájlt egy semleges megjelenítőben, ne a szerzőeszközben, és ellenőrizze, hogy a térbeli hierarchia, a mértékegységek és a koordináta-rendszer eredete megfelel-e annak, amit a fogadó vár. Egy 40 méterrel arrébb lévő modell láthatatlanul hibás marad, amíg valaki észre nem veszi.
• Körkörös teszt a projekt első cseréjénél. Exportálás, majd újraimportálás a forráseszköz egy második példányába vagy egy megjelenítőbe, hogy megerősítse, semmi sem veszett el csendben. Érdemes egyszer elvégezni projektenként, nem fájlonként.
• Újraexportálás minden modellkiadáskor. A koordináció csak akkor hasznos, ha a határt átlépő fájl naprakész; egy elavult export meghiúsítja a megosztott Közös Adatkörnyezet célját.

Miért kellene egy magánmegrendelőnek törődnie a csereformátummal?

Két következménye van annak, ha a natív fájlok helyett nyílt csereformátumot választunk. Először is, a megrendelőnek olvasható modellje marad, miután bármelyik szakági tervező licencének lejár, szoftvert vált, vagy a tervező már nem elérhető: egy IFC-fájl évekkel később is megnyílik ingyenes megjelenítőkben, míg egy elhagyott licencből származó natív fájl lehet, hogy egyáltalán nem nyílik meg. Másodszor, minden szakág továbbra is azt az eszközt használhatja, amelyhez ténylegesen ért, mert az IFC a közös nyelv közöttük, nem pedig egy megosztott program.

Ez teszi lehetővé a használható kivitelezési dokumentációt is: az összehangolt modell IFC-exportja a rajzok mellett olyasmi, amit egy jövőbeli karbantartó vállalkozó meg tud nyitni anélkül, hogy bármit is birtokolnia vagy licencelnie kellene.

Mi szokott rosszul menni egy csere során, és hogyan lehet ezt kiszűrni?

Az ismétlődő hiba nem egy sérült fájl, hanem egy csendes eltérés: milliméterben exportált mértékegységek, amelyeket méterben feltételezve importálnak, egy olyan tulajdonság, amelyet a küldő eszköz soha nem képezett le, így a fogadó oldal üres mezőt lát, vagy egy olyan geometriai részletességi szint, amely túl durva az ütközésvizsgálathoz. Ezek egyike sem dob hibát; később bukkannak fel, amikor egy csatorna "nincs ott" a koordinációs modellben, vagy egy tűzállósági fokozat beállítatlanként jelenik meg.

A kiszűrés módja eljárásrendi: valaki az exportált fájlt a létrehozó eszköztől függetlenül megnyitja, és ellenőrzi egy rövid lista alapján (eredet, mértékegységek, szintek száma, néhány ismert méret), ugyanaz a fegyelem, amely egy megfelelő Fejlettségi Szint nyilatkozat mögött áll.

Hogyan illeszkedik az IFC-csere a tágabb koordinációs folyamatba?

A csere a mechanizmus, nem a cél. Ez teszi lehetővé a BIM koordinációt a külön licencelt szakágak között: enélkül az ütközésvizsgálatnak nincs közös tesztelési alapja, és a megosztott adatkörnyezetnek nincs semleges fájlja, amit tárolhat. A beállítások, a verzióválasztás és az ellenőrzési rutin egyszeri, korai helyes rögzítése biztosítja, hogy minden későbbi lépés olyan adatokon fusson, amelyeket mindenki ténylegesen meg tud nyitni.