OpenBIM

OpenBIM

A különböző tervezőeszközökkel készített állományok esetén az egyik kulcskérdés az adatcsere. Milyen módon adják át az egyes szakágak az elkészített terveiket adatszolgáltatásként, hogyan állnak össze az egyes részek egy teljes egésszé? “Hagyományos” kétdimenziós rajzok esetén ez viszonylag egyszerű feladat, hiszen szinte minden ma használatos tervezőeszköz képes például DXF, néhány még DWG exportra is. Természetesen azért ezen a területen sem fenékig tejfel az élet. Az Autodesk alkalmazásokat használók gyakran szembetalálkoznak azzal a jelenséggel, hogy a más gyártók által 100%-os DWG kompatibilitásnak mondott végtermék ellenére, ha megnyitunk egy ilyen exportált rajzot, akkor a méretek nagyon kuszák lesznek, az egyes vonalak nem feltétlenül csatlakoznak. Vannak akik milliméterben, mások méterben rajzolnak, így az egymásra vetített rajzokat léptékezni szükséges. Az egységes koordinátarendszer használata pedig csak hab a tortán.

Háromdimenziós modellek esetén sokkal több adatot kell(ene) átadni, minél kevesebb adatvesztéssel és minél kevesebb előkészítő munkával. Ez utóbbi azt jelenti, hogy egyáltalán nem nevezem hatékonynak, amikor egy adatszolgáltatással napokat kell eltölteni azért, hogy a saját rendszeremben használható legyen.

Building Smart / OpenBIM / IFC
1995-ben 12 szoftvergyártó megalapította a Private Alliance-t azzal a céllal, hogy elősegítsék a termékeik közötti adatmegosztást.
Az alapítótagok:

“1995. szeptemberétől minden érdeklődő csatlakozhatott a szervezethez.
1996-ban a korábbi szervezetből létrejött az International Alliance for Interoperability. Megfogalmazták az Industry Foundation Class (IFC) fő célját: egy olyan független leíró adatbázis, amivel az építmény teljes életciklusa során támogatható.
2008. névváltás, létrejött a buildingSMART / OpenBIM.
building: a teljes épített környezetet magába foglalja (épületek és infrastruktúra egyaránt)
SMART: intelligens elemekkel történő kommunikáció, csapatmunka, az épített környezet felépítése és üzemeltetése”
forrás: wikipedia, buildingsmart.org

Az IFC jelenleg a 4-es verziónál tart (2013-ban adták ki). A leírások alapján a főbb építészeti, épületgépész és szerkezeti geometriákat és ezek egyes tulajdonságait tárolja, támogatja a 4D és 5D modell adatszolgáltatást. A leendő IFC 5-ös verzió már képes lesz infrastruktúra elemeket is kezelni.
Az egyes verziók pontos leírásai itt találhatók.

Hogyan néz ki az IFC használata a gyakorlatban? Erre a kérdésre Szilágyi Balázs építészmérnök, BIM tanácsadó 2015. január 8-án, a tervlap.hu-n megjelent írásának egy részletét idézem:

“Van egy IFC (Industry Foundation Classes) névre keresztelt állítólagos szent grál, világmegváltó csodafegyver, ami bár szimpatikus – jelenlegi legfrissebb verziójában is – az alábbi problémákat veti fel:
● objektum modellje ugyan lefedi majd az összes eddigi tudásunk szerint, magasáépítési létesítményben megjelenhető objektumot, de a belső struktúrája csak bizonyos szűk körben szabványos
○ ennek következménye, hogy legtöbbször a modell importálása csak ugyanabban a szoftverben hozza a várt eredményeket, ahonnan származik;
○ többek között hiányosak a földrajzi hely, anyag, költség, tevékenység osztályok;
○ ez egyre hangsúlyosabb épület-automatika egyáltalán nem vihető át tervező-rendszerek között, a logikai kapcsolatok hiánya miatt az energetikai és üzemeltetési adatokra gyakorolt hatásuk is elvész.

● Nem kezeli a geometriák közötti logikai kapcsolatokat
○ ezzel a szakágak közötti logikák is borulnak, a 3D alapú tervező-rendszerek legtöbb esetben pont ezeken az összefüggéseken alapulnak (pl: fal-födém csatlakozások, épületgépészeti és elektromos rendszerelemek, fizikai és analitikai tartószerkezeti modellek, szerkezetek és vasalásuk…);
○ a geometriák lehetőségei meglehetősen korlátozottak, ennek mélyreható tanulmányozását itt érdemes kezdeni: ISO10303-21 .

● Képességeit kényszerűségből a tervezőszoftver-piac leggyengébb szereplőihez kell igazítani a kompatibilitás fenntarthatóságához a fejlődés lassúvá és vontatottá vált.”

A teljes cikk itt található.

Az OpenBIM-et és ezzel az IFC-t előtérbe helyezők azt mondják, hogy minden felhasználó dolgozzon nyugodtan a saját alkalmazásában és majd IFC-vel megoldják az adatcserét. Kicsit sarkos megközelítés ugyan, de néhány oldalon ezt a megoldást úgy szemléltetik, hogy egy nemzetközi társaságban mindenki nyugodtan beszélje a saját nyelvét, a központban tolmácsként az IFC áll, és az majd fordít a beszélgetőpartnerek között. Az előzőek alapján érdemes feltenni a kérdést, hogy szeretnénk-e egy üzleti tárgyalás során konyhanyelvet beszélő tolmácsot alkalmazni? Persze vannak olyan helyzetek, amikor ez is elegendő lehet.

Érdemes végiggondolni az alábbi kérdéseket is:
– Milyen módon továbbítjuk az egyes IFC fájlokat (FTP, e-mail, cloud, egyéb), ezek hogyan illeszthetők a tervezési és a vállalati folyamatokba?
– Mi a helyzet a verziókövetéssel (amennyiben módosul az adott szakági terv), hogyan tároljuk az egyes verziókat?
– Ki koordinálja és validálja az egyes szakágak által készített IFC-ket?
– Hogyan lehet ellenőrizni az IFC adatszolgáltatás aktualitását, honnan értesülünk a módosításokról?
– Ha az importálás után helyretettük az IFC tartalmát, akkor egy újabb verzió esetén ezeket ismét meg kell tenni (esélyes hogy nem egyetlen adatszolgáltatás lesz!)?
– Mi a helyzet eltérő IFC verziót használó alkalmazások esetén?
– Kinek a felelőssége, ha importáláskor az IFC nem hozza, vagy látszólag nem hozza be az összes olyan adatot, amit az IFC készítője szeretett volna megosztani velem?
– Mi lesz a végeredmény (az összes IFC-t megkapja a megrendelő és összerakja magának, egy általa kiválasztott alkalmazásban, az összes IFC-t betöltjük egy kiválasztott alkalmazásba, mindenki leadja a saját részét a saját alkalmazásának natív formátumában), amit megkap a megrendelő?
– Hogyan kezeljük a projekthez kapcsolódó egyéb fájlokat (műszaki leírások, Excel táblák, levelezés stb)?

Szerző:
Kiss Károly