Nowy oficjalny standard IFC4

Hasło IFC4 pojawia się w BIMowej przestrzeni już od wielu lat. Od momentu gdy w październiku 2017 roku IFC 4.0.2.1 (znane też jako IFC4 ADD2 TC1) stał się oficjalnym standardem, (który kilka miesięcy później znalazł swoje odzwierciedlenie w serii norm ISO) kolejne wersje były publikowane i wycofywane. We wrześniu tego roku osiągnęliśmy kolejny kamień milowy na drodze rozwoju IFC bo wersja 4.3.2.0 (IFC 4.3 ADD2) stała się oficjalnym standardem buildingSMART, a na początku przyszłego roku planowana jest publikacja kolejnego standardu ISO.

Może więc dziwić, że IFC4 nadal bywa używany dosć rzadko. Przyczyny można upatrywać między innymi w braku certyfikacji. Choć dziś (listopad 2023) certyfikatem na eksport lub import IFC4 może pochwalić się jedynie 10 narzędzi[1] (Allplan, ARCHICAD, Autodesk Revit, cadwork 3D, FORNAX, FulcrumHQ, MagiCAD, STRAKON, Tekla Structures oraz Vectorworks) to mając na uwadze mnogość programów “klasy BIM” jest to nadal niewielka liczba. Do tego jeśli chcielibyśmy oprzeć pracę na IFC4 i certyfikowanych narzędziach – póki co nie mamy w zanadrzu ŻADNEGO oprogramowania do weryfikacji modeli, nie mówiąc już o innych zastosowaniach. Jak na 10 lat od pojawienia się pierwszej wersji IFC4[2] tempo certyfikacji, mówiąc oględnie, nie zachwyca.

Certyfikacja IFC2x3 vs IFC4

Jednej z przyczyn takiego stanu rzeczy można upatrywać w zmianie sposobu certyfikacji, w szczególności w zaostrzeniu kryteriów. Kiedy buildingSMART certyfikował import i eksport do IFC2x3 podchodził do tego dość liberalnie. Programy mogły nie przejść wielu pojedynczych testów (nie otrzymać zielonego znacznika) a i tak otrzymać certyfikat. Przykładowa strona z raportu certyfikacji wyglądała tak:

Źródło: https://ifc2x3.b-cert.org/ords/ifc/certification/getCertificationReport/101

Widoczny powyżej mix mógł powodować szereg nieoczekiwanych błędów podczas wymiany modeli między dwoma narzędziami nawet jeśli oba posiadały odpowiednie certyfikaty – wyobraźmy sobie nawarstwienie problemów, gdy jeden z programów wadliwie eksportuje określone dane a drugi nie potrafi ich odczytać lub też robi to nieprawidłowo. Taka wymiana zawsze wiązała się z dużym ryzykiem, co w uproszczeniu przedstawia poniższy rysunek.

Źródło: opracowanie własne na podstawie grafiki https://cdn.mos.cms.futurecdn.net/8f70c5d2a5222d6bff2c4a95a3ff7637-1200-80.jpg.webp

Takie sytuacje oczywiście są frustrujące dla użytkowników i trudno się dziwić, że pojawiały (i nadal pojawiają) się głosy mówiące “IFC nie działa”. Z wierzchu faktycznie tak to wygląda, ale żeby zrozumieć przyczyny należy zajrzeć pod powierzchnię. Choć temat jest obszerny przyczyny przyklejenia tej niechlubnej łatki można w skrócie podzielić na dwie kategorie:

• użytkowników, w tym:
  • niewystarczającą znajomość używanego narzędzia (nieprawidłowe modelowanie, mapowanie danych, ustawienia eksportu itd.),
  • brak wiedzy o IFC i o tym, jak działa,
  • wynikające z powyższego używanie plików w celach, do których nie zostały stworzone (tu czynnik ludzki mocno “współpracuje” na niepowodzenie wymiany danych z drugą kategorią przyczyn),
• narzędzie i jego niedoskonałości, głównie:
  • brak funkcji umożliwiających uzyskanie poprawnych plików,
  • nieprawidłowe funkcjonowanie eksportu lub importu pliku IFC.

Druga kategoria przyczyn ma zostać usunięta właśnie dzięki zmianie stanowiska w kwestii certyfikacji w odniesieniu do IFC4. Zero-jedynkowe podejście ma zapewne sprawić między innymi, że użytkownicy zyskają większą pewność, że mogą polegać na swoim narzędziu. Z drugiej strony, co niekorzystne z punktu widzenia użytkowników, tłumaczenie-wytrych (swoją drogą absurdalne), że “to wina oprogramowania i nic na to nie poradzimy” stanie się całkowicie niezasadne bo czynniki technologiczne znikną lub zostaną w znacznym stopniu wyeliminowane i ten argument straci swoją zaskakująco dużą moc.

Co producenci na to?

Ostrzejsze zasady certyfikacji w oczywisty sposób będą musiały także wpłynąć na producentów. Można odnieść wrażenie, że w przypadku niektórych programów uzyskanie aprobaty buildingSMART zakończyło (lub co najmniej wyraźnie spowolniło) prace nad eksporterami do IFC2x3 CV2.0 mimo, że wydane certyfikaty jasno wskazywały, że programy nie spełniały wszystkich stawianych im wymagań. To ma się zmienić i niejako zmusić producentów do dążenia do wyznaczonego celu, jakim jest umożliwienie użytkownikom uzyskiwania modeli o wyższej jakości. Niestety ma to też negatywne konsekwencje.

Po pierwsze: czas. Przegląd danych udostępnionych przez buildingSMART wykazuje, że dotychczas proces uzyskania certyfikatu na eksport do IFC4 RV1.2 wynosił średnio nieco ponad 2 lata. Co prawda w przypadku IFC2x3 CV2.0 rekordziście proces certyfikacji zajął 6 lat, ale tym razem nie chodzi o wprowadzenie czegoś w zasadzie nowego, lecz o dokonanie odpowiednich modyfikacji i nadrobienie zaległości sprzed lat. Niestety producenci sporo przespali – pierwsza wersja formatu IFC4.0.0.0 pojawiła się w lutym 2013[3] roku a IFC2.3.0.1 w 2007 roku. Mówimy więc o zapóźnieniach rzędu nawet 16 lat.

Po drugie: koszty. Nie ulega wątpliwości, że proces ulepszenia oprogramowania wymaga niemałych nakładów. Prace programistyczne wymagają też testów, które muszą trwać. A nie ukrywajmy, że poza IFC producenci starają się (jak im idzie to inna bajka) sprostać rosnącym oczekiwaniom użytkowników dotyczących usprawnień w zakresie modelowania, generowania dokumentacji, współpracy międzybranżowej, obsługi nowych formatów danych wejściowych itd. IFC jest więc tylko jednym z elementów, nad którymi muszą się pochylić i ich strategia rozwoju musi być wielokierunkowa (dla przykładu można przytoczyć choćby mapę drogową, którą dla swoich użytkowników przygotował Autodesk).

Przy tych kosztach sama certyfikacja wydaje się wydatkiem wręcz pomijalnym biorąc pod uwagę zapewne ogromne budżety producentów przeznaczone na rozwój i utrzymanie swoich produktów. Producent oczekujący certyfikacji jedynie na import IFC4 poniesie podstawowy koszt w wysokości 25.000,00 €. Gdyby jednak chciał certyfikować zarówno import, jak i eksport do RV1.2 w zakresie wszystkich trzech domen (architektonicznej, konstrukcyjnej oraz instalacyjnej) to tylko nieco ponad dwukrotność tej kwoty (54.000,00 €). Dokładne kwoty dostępne są pod tym linkiem. Można więc sądzić, że koszt certyfikacji jest w tym procesie najmniejszym problemem.

Podsumowując już powoli kwestię certyfikacji IFC4 należy zastanowić się nad jednym pytaniem: jak obecnie wygląda sytuacja dla nas – użytkowników?

Czy coś nam grozi?

W obliczu istotnych braków w zakresie możliwości narzędzi “klasy BIM” zjawisko, które można coraz częściej obserwować, polegające na pojawianiu się wymogów stosowania IFC4 na projektach, wydaje się dość niepokojące. Jeśli dotychczasowe tempo certyfikacji się utrzyma a presja ze strony branży na używanie IFC4 będzie się nasilać to obawy o powtórkę z “rozrywki”, która miała miejsce z IFC2x3 wydają się w pełni uzasadnione. O czym mowa?

Na początek przypomnijmy, że w odniesieniu do IFC2x3 to do dziś jedynym oficjalnym widokiem modelu jest Coordination View 2.0 (dalej: CV 2.0). Istnieje oczywiście masa niecertyfikowanych MVD (np. IFC 2×3 Basic FM Handover View, IFC 2×3 Cobie 2.4 Design Deliverable, IFC 2×3 GSA Concept Design BIM 2010) ale – przynajmniej z mojego doświadczenia – ich wykorzystanie z reguły nie przynosi w pełni satysfakcjonujących efektów. Stąd najpowszechniej stosowanym jest CV2.0. Niestety użytkownicy nie do końca zdają się mieć świadomość, że choć podejmowano próby wykorzystania tego MVD na wielu polach to faktycznie jego przeznaczenie ograniczało się do użycia uzyskanego z jego pomocą IFC jako modelu odniesienia i do wymiany danych na cele koordynacji między domenami architektoniczną, konstrukcyjną i instalacyjną[4]. Takie samo przeznaczenie ma obecnie certyfikowany MVD dla IFC4 – Reference View 1.2 (dalej: RV 1.2)[5]:

• łączenie różnych modeli IFC jednej dyscypliny w celu kontroli wizualnej,
• wykrywanie kolizji między dyscyplinami,
• referencja (jako podkład z innej dyscypliny),
• wykonanie przedmiaru,
• sekwencjonowanie budowy,
• prezentacja wizualna projektu.

Jak widać powyżej chodzi o te zastosowania, które nie wymagają dalszych modyfikacji dostarczonych danych i wymagają jedynie przekazania określonych informacji. Nazwa “Reference View” ma najpewniej podkreślić te cele.

Wracając jednak do potencjalnego problemu z zapóźnieniami narzędzi: jeśli sytuacja się nie zmieni (tzn. nie przyspieszy wyraźnie, dając użytkownikom to, czego oczekują w niedalekiej perspektywie) to można obawiać się, że z braku alternatywy użytkownicy znowu będa podejmowali (w większości niestety daremne) próby wykorzystania modelu IFC pochodzącego z RV 1.2 do wszystkiego, co fabryka dała “bo przecież w BIM chodzi o współpracę”. Mało kto jednak zdaje sobie sprawę, że po to zaleca nam się rozpisywać, analizować i poprawiać procesy, żebyśmy – nawet jeśli nie mamy świadomości istniejących w wymianie danych ograniczeń – mogli je samodzielnie wykryć i odpowiednio wcześnie reagować, bez posiłkowania się wspomnianym hasłem-wytrychem “IFC nie działa”. Nie działa bo nie miał działać W TAKI SPOSÓB i oczekiwania użytkowników tego nie zmienią. To trochę tak, jakbyśmy liczyli, że biorąc z półki losowe produkty spożywcze uda nam się przyrządzić wykwintny obiad na miarę dania z restauracji z trzema gwiazdkami Michelin. Choć czasem może się udać to niestety w większości przypadków ta misja jest skazana na porażkę. Użytkownicy świadomi takich problemów mogą jedynie apelować o zwiększanie świadomości nie tylko z korzyści płynących z nowości, ale przede wszystkim ze związanych z nimi zagrożeń.

Co nam da IFC4?

Na szczęście kolejne wersje IFC to nie tylko zagrożenia, ale też szanse. Już na pierwszy rzut oka widać, że użytkownik opisując model może wybrać z większej liczby jednostek. IFC2x3 obejmował ich 653, IFC4.0.2.1 – 776, a nowy oficjalny standard – IFC4.3.2.0 (IFC 4.3 ADD2) aż 876. Część “starych” klas została dość mocno rozbudowana, aby precyzyjniej opisywać elementy, a jednostki typu przeobraziły się w te “główne”. Dotyczy to w szczególności elementów instalacyjnych. Dla przykładu już w IFC4.0.2.1 jednostka IfcFlowTerminal została wycofana a w jej miejsce wprowadzono szereg ją zastępujących – dedykowanych dla poszczególnych rodzajów elementów.

Źródło: opracowanie własne na podstawie: https://standards.buildingsmart.org/IFC/RELEASE/…

Jak duża, w porównaniu do możliwości IFC2x3, jest to różnorodność niech chociaż po części zobrazuje poniższy przykład.

Źródło: opracowanie własne, projekt: DCS; model: PORR S.A./Graphit sp. z o.o.

W standardzie IFC4 pojawiły się także uogólnienia dla przyszłych jednostek IFC dedykowanych dla projektów infrastrukturalnych:

• IfcCivilElement, stanowiącej uogólnienie wszystkich elementów związanych z obiektami inżynierii lądowej i wodnej, których nie można przedstawić jako IfcBuildingElement (części obiektu budowlanego), IfcDistributionElement (elementu systemu instalacyjnego) lub IfcGeographicElement. Klasa ta w wersji IFC 4.3.1.0 została zastąpiona klasami[6]:
  • IfcBuiltElement (obecnie klasa IfcBuildingElement),
  • IfcEarthworksElement (element budowlany utworzony w wyniku robót ziemnych związanych z budową podłoża, ustabilizowania, wzmocnienia lub podwyższenia poziomu gruntu),
  • IfcFacility (klasa wirtualna odnosząca w uproszczeniu wskazująca na rodzaj obiektu stanowiącego przedmiot modelu: IfcBuilding, IfcBridge, IfcRailway, IfcRoad, IfcMarineFacility, IfcTunnel),
  • IfcGeotechnicalElement (jednostka mająca w kolejnych rozszerzeniach przedstawiać elementy geotechniczne),
  • IfcGeographicElement, która stanowi uogólnienie dla jednostek reprezentujących elementy krajobrazu (drzew, latarni, znaków drogowych itp.)

Dodatkowo w IFC4.3.1.0 branża drogowa i kolejowa otrzymały dedykowane jednostki, odpowiednio:

• IfcKerb i IfcKerbType (krawężniki i obrzeża), IfcRoad i IfcRoadPart (nawierzchnie drogowe, piesze i rowerowe oraz ich części),
• IfcRail i IfcRailType (szyny), IfcRailway i IfcRailwayPart (trasa kolejowa i jej części), IfcTrackElement i IfcTrackElementType (tory).

Obecnie także prowadzone są prace mające na celu dokonanie dalszych uszczegółowień dla poszczególnych obszarów branży budowlanej, np. w ramach IFC4.4 zapowiadane jest ujęcie elementów dot. tuneli[7]

Coraz większa liczba jednostek, rozumiana jako coraz bardziej dokładniejszy opis elementów w ramach schematu IFC, oznaczać będzie na pewno zmniejszenie liczby IfcBuildingElementProxy w modelach. Widać to po opisie tej jednostki w IFC 4.

Źródło: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcBuildingElementProxy.htm

Oczywiście dobrze by było, gdyby faktycznie domeny i jednostki IFC w pełni pokrywały zapotrzebowanie branży jednak szczerze wątpię, aby było to możliwe. Nawet jeśli dziś wydaje nam się, że tak jest to jutro mogą pojawić się nowe potrzeby czy technologie, których opracowany standard nie uwzględnia. Sądzę, że buildingSMART doskonale zdaje sobie z tego sprawę i dlatego IfcBuildingElementProxy – jako taki joker – musi istnieć, choć należy się spodziewać dalszego ograniczania jego użycia.

Druga kwestia, którą warto poruszyć w kontekście IfcBuildingElementProxy, dotyczy narzędzi. Wiele programów używanych przez projektantów ma ograniczone możliwości w kwestiach związanych z IFC (i chyba należy się spodziewać, że jeszcze długo tak będzie). Oczywiście możemy powiedzieć, że należałoby wykorzystywać jedynie certyfikowane oprogramowanie jednak wiele branż nie dysponuje narzędziami, które jednocześnie spełniają techniczno-inżynierskie wymagania projektantów i potrafią poprawnie eksportować dane do IFC. W takich sytuacjach często, aby w ogóle móc brać udział w procesie opartym o wykorzystanie modeli, niezbędne wydaje się właśnie użycie jednostki IfcBuildingElementProxy. Nie dlatego, że jest ona najwłaściwszym wyborem, ale koniecznością bo lepiej mieć w modelu element niedookreślony niż nie mieć go wcale.

Podsumowując można powiedzieć, że rozwój IFC przypomina nieco wędrówkę, której trasa cały czas się zmienia, wydłużając się, a czasem zahaczając też o okoliczne wzgórza. Branża ewoluuje przynosząc nowe technologie i wyższe oczekiwania użytkowników przez co odległość do mety cały czas się zwiększa. Podczas tej wędrówki na szczęście co jakiś czas buildingSMART dorzuca nam niezbędny na danym odcinku ekwipunek, byśmy mogli iść dalej. W tym porównaniu (może nie do końca zgrabnym) kolejne jednostki IFC i certyfikowane programy mogą stanowić odpowiednik prowiantu, a zmiany które organizacja wdraża w zakresie certyfikacji to wręcz nowe buty, które zmienią jakość naszej wędrówki. I choć momentami mamy ochotę ponarzekać na IFC i trudy wędrówki to warto czasem po prostu podziwiać widoki i cieszyć się, że z każdym krokiem meta jest coraz bliżej.

Karolina Wróbel

M.A.D. Engineers