Table of Contents
Krótka historia IFC2x3 oraz IFC4
IFC2x3
IFC nie jest nowym konceptem. Na blogu jest artykuł opisujący ogólną historię formatu IFC. Jeżeli jeszcze nie przeczytaliście, to gorąco polcam przeczytać tutaj. Najpopularniejszy format wciąż używany przez branże to IFC2x3, który pojawił się w 2006 roku. Gotowy do użytku był w 2007 po wprowadzeniu jednej łatki (Technical Corrigendum 1). O dziwo, IFC2x3 był głównie zmianą jakościową do swojego poprzednika IFC2x2 z 2003 roku. Stąd też x3 w nazwie – zgodnie z nazewnictwem buildingSMART oznacza jedynie “mniejszą wersję”. Podstawowy koncept IFC2.0 został stworzony w 1999!
IFC2x3 był pierwszą wersją, którą możemy nazwać oficjalnym standardem – została ujęta w PAS 16739 (Publicly Available Specification – Specyfikacja Dostępna Publicznie, rodzaj tymczasowego standardu. Więcej na ten temat.
Główne problemy formatu IFC2x3
Format ten stał się powszechnie stosowany w branży budowlanej, większość programów uzyskała certyfikat w 2013 i 2014 roku (więc 6-7 lat po wypuszczeniu na rynek!).Obejmuje również czas kiedy BIM rozwinął się komercyjnie w obrębie przemysłu AEC.
W tym czasie, wiele projektów napotkało na problemy związane z interoperacyjnością IFC2x3. Często nie wiadomo kto jest winny: eksport z narzędzia do modelowania BIM, import do przeglądarki IFC czy może sam IFC za błędy w schemacie? Pomimo iż większość oprogramowania jest certyfikowana w IFC2x3, błędy się zdarzają. Mają miejsce gdzieś pomiędzy tym jak jeden program definiuje element przy jego eksporcie do IFC a tym jak inny program rozumie ten sam element IFC i tłumaczy go w imporcie. A czasami też jest to mankament IFC 2×3.
Te błędy w tłumaczeniu są wybitnie frustrujące przy zagadnieniach geometrycznych. Oto niektóre typowe błędy:
- Cienkie płyty/osłony mają problemy z otworowaniem (np. podłoga która jest modelowana jako oddzielny obiekt)
- Wycięcia na drzwi muszą posiadać ścianę po obu stronach, pomimo że jest inny obiekt pomiędzy dwoma oddzielnymi drzwiami a w ścianie powinno być wycięcie
Jest też wiele problemów związanych ściśle ze schematem IFC:
- Nie uwzględnia danych parametrycznych
- Zakrzywienia oraz obiekty okrągłe są modelowane jako wieloboki, które zwalniają model (brak obsługi krzywych b-spline)
- Brak domeny infrastrukturalnej (choć ta nieźle daje sobie z tym radę)
- Zbyt mało schematów i właściwości dla instalacji. Pomimo że wszystkie posiadają swoje encje oraz klasy, domena instalacji budowlanych ma wiele niedociągnięć.
IFC4
Po wprowadzeniu IFC2x3, buildingSMART zaczęło prace nad nową wersją formatu – IFC2x4, czyli dzisiejsze IFC4. Jak pierwotna nazwa sugeruje IFC4 nie jest kompletnie nowym schematem – jest to raczej udoskonalenie jakościowe oraz rozszerzenie istniejącego formatu IFC2x3. W pewnym momencie, zakres usprawnień schematu był na tyle szeroki że groziło to zerwaniem wstecznej kompatybilności. Dlatego też został nazwany IFC4 zamiast IFC2x4. Schemat został wypuszczony na rynek w 2013 roku i natychmiast znalazł się w standardzie ISO 16739:2013.
Więc, jak widać, IFC4 jest udoskonaleniem IFC2x3. Pomimo iż BuildingSMART nie gwarantuje kompatybilności wstecznej, wątpię byśmy mieli wielkie problemy, np. z niemożnością otwarcia pliku IFC2x3 w certyfikowanym programie dla IFC4. Powody są następujące:
Struktury schematów są podobne (IFC4 jest rozszerzeniem pewnych domen dla IFC2x3)
Do tej pory nie wprowadzono oprogramowania jedynie dla IFC4 (i wątpię by takowe było w przeciągu najbliższych 5 lub więcej lat)
Nie kupuje sie rocznej licencji na używanie schematu IFC
Tego samego nie można powiedzieć o natywnych formatach, pomimo iż nowe wydania są jedynie poprawkami i udoskonaleniami kodu sprzed 3 czy więcej dekad 🙂
Oficjalną wersją jest IFC4.0 (z jeszcze dziwniejszą nazwą, którą chyba tylko programiści potrafią rozszyfrować: IFC4 ADD2 TC1). Do tej pory wyszły 2 małe poprawki zajmujące się domeną infrastrukturalną. Wersja 4.3 jest wciąż udoskonalana, więc, kto wie, może wkrótce przeskoczymy z formatu IFC2x3 od razu do IFC4x3 (lub IFC4.3, co oznacza to samo)?
Tutaj można sprawdzić wszystkie wersje oraz ich statusy.
Jakie usprawnienia przynosi IFC4?
Celem IFC4 było usprawnienie jednorodności w schemacie, redukcja oraz optymalizacja pliku po zapełnieniu modelu danymi. Jednym z celów było dążenie do bardziej poprawnych rezultatów eksportów IFC oraz umożliwienie przerzucania modeli IFC pomiędzy różnymi programami (eksport z jednego programu oraz import do innego do dalszej pracy nad modelem).
Niektóre udoskonalenia w schemacie struktury:
- Poprawa technicznych problemów znanych z w IFC2x3,
- Podtypy elementów budowlanych dopuszczają parametryzowanie ich kształtu, materiału czy typu ,
- Ustandaryzowane właściwości ilościowe dodane do specyfikacji IFC. Nie będzie więcej wielu właściwości z ilościami zależnymi od rodzaju użytego programu?
- Obsługa obliczeń energetycznych oraz zaawansowanych symulacji,
- Określona w standardzie ISO 16739-1:2018,
- Połączenie definicji właściwości IFC ze słownikiem danych buildingSMART,
umożliwiający używanie ojczystych języków i klasyfikacji, - Umożliwienie obsługi powierzchni i krzywizn. Powinno to wielce usprawnić działanie modeli zawierających znaczną ilość krzywizn (np. instalacje sanitarne, zbrojenie, fasady),
- Ulepszona praca z 4D poprzez uproszczenie definicji czasu zadania, kalendarzy pracy oraz harmonogramów,
- Kosz jest przypisany do danego obiektu a nie jego relacji.
- Przyspiesza to działanie modeli które używają zbiory danych 5D,
- Poprawienie interoperacyjności BIM do GIS,
- Wprowadzenie jednostki systemu dystrybucji, poprawienie semantyki oraz obsługa nowych elementów w celu lepszego uchwycenia domeny instalacji budowlanych,
- Poprawa czytelności dokumentacji technicznej w celu ułatwienia procesu wdrożenia,
- Umożliwienie rozszerzenia IFC do infrastruktury: mosty, tory kolejowe, drogi oraz inne domeny (deweloperzy pracują nad rozszerzeniami dla najnowszej wersji 4.3),
- Wersja 4.3 wyłączyła jednostkę IfcBuildingElementProxy. Tłumaczę to tym iż buildingSMART jest pewien, że wszystkie elementy są ujęte w dostępnych klasach IFC. Co stanowi dobrą wiadomość.
Jak widać, zmiany są znaczne i obejmuje całe spektrum przepływu danych oraz przypadków użytkowych BIM. Ekscytujące!
Certyfikacja oprogramowania w IFC2x3 oraz IFC4
Oprogramowanie uzyskuje certyfikacje buildingSMART w oparciu o to jak dobrze radzą sobie w obsłudze eksportu oraz importu natywnego modelu do formatu IFC zdefiniowanego przez Model View Definition. Istota MVD została omówiona tutaj. W skrócie, certyfikowane oprogramowanie oznacza, że poprawnie przeszło większość testów. Niekoniecznie to oznacza to bezstratny transfer modeli do IFC i vice versa.
IFC2x3 powstał z jednym oficjalnym MVD używanym do koordynacji wielobranżowej (z czterech w całości) zwanym “Coordination View”. Od tamtej pory, powstało wiele nieoficjalnych dodatkowych, nieoficjalnych MVD. Oto pełna lista.
Pierwotnym celem Coordination View MVD była obsługa (tak jak nazwa sugeruje) współpracy pomiędzy różnymi branżami. Przez lata, definicja modelu została poszerzona, aby poprawić transfer plików IFC pomiędzy różnymi oprogramowaniami. MVD zostało poszerzone na tyle, że w końcu zdecydowano się wydać Coordination View 2.0, który dzisiaj jest uznawany za standardową definicję eksportu.
Z jednej strony to dobrze – szacuję, że około 90% eksportu używa tylko tego MVD, więc projektanci nie mają problemu z wyborem. Z drugiej strony, jeżeli coś służy wszystkiemu, to nie służy niczemu. Żadne oprogramowanie nie spełniało w 100% wymagań certyfikacji buildingSMART, więc bSI zaczęło przydzielać zielone, żółte lub czerwone oznaczenia wymaganym zadaniom. Aby zdobyć certyfikację, oprogramowanie nie musiało zdobyć wszystkich zielonych oznaczeń. A to spowodowało jeszcze większy chaos.
Z tego względu, oficjalne MVD dla IFC4 miało za zadanie zupełnie oddzielić od siebie te dwie funkcje: koordynację oraz transfer projektu. Dla pierwszej funkcji buildingSMART stworzyło Reference View MVD, dla drugiej – Design Transfer. Certyfikacja jest też surowsza – oprogramowanie otrzymuje certyfikat jeżeli jest w pełni zgodne z MVD. Żadnych wyjątków. Ponadto, dopiero po pozytywnej certyfikacji na Reference View, dostawca może ubiegać się certyfikat na Design Transfer.
Prowadzi to do bardziej jednorodnych wyników eksportu IFC przy użyciu różnego oprogramowania, co prowadzi do jednoznacznego importu pliku IFC do oprogramowania przeglądającego / sprawdzającego, a ostatecznie do modeli IFC o lepszej jakości. Jednakże, znacznie trudniej jest zdobyć certyfikat przez dostawców oprogramowania.
