Wymiana modelu IFC

Czym jest wymiana modeli IFC?

Wymiana modeli IFC to praktyka polegająca na wyeksportowaniu modelu z programu, w którym został stworzony, i zapisaniu go w neutralnym, ustrukturyzowanym pliku, który każdy inny program może odczytać na własnych zasadach. Industry Foundation Classes (IFC) to otwarty schemat stojący za tym procesem, utrzymywany przez buildingSMART i opublikowany jako norma ISO 16739. Opisuje on ściany, przewody, rury i pomieszczenia jako nazwane, typowane obiekty, a nie linie i niemą geometrię. Kluczowe jest tutaj działanie – wymiana: eksport, sprawdzenie mapowania, import i test dwukierunkowy (round-trip) potwierdzają, że strona odbierająca otrzymała to, co strona wysyłająca chciała przekazać.

W projekcie mieszkaniowym ma to miejsce przy każdym przekazaniu między branżami, które nie dzielą się licencją: od architekta do konstruktora, od konstruktora do koordynacji MEP, a cały skoordynowany zestaw trafia do archiwum klienta przy odbiorze. Każde przekazanie jest tak dobre, jak plik IFC, który je umożliwia, ponieważ narzędzie odbierające nie ma dostępu do tego, co pozostało w natywnym formacie.

Co tak naprawdę przetrwa eksport IFC, a co nie?

Eksport to tłumaczenie, a tłumaczenia zawsze coś tracą. Ściana zbudowana z rodziny parametrycznej staje się, po drugiej stronie eksportu, stałym elementem geometrii oznaczonym jako ściana z zestawem właściwości: nie pamięta już reguły, która ją wygenerowała, a jedynie kształt i dane dołączone w momencie eksportu.

Zazwyczaj przetrwa	Zazwyczaj nie przetrwa
Ogólna geometria i hierarchia przestrzenna (działka, budynek, kondygnacja, pomieszczenie)	Natywne reguły parametryczne (wymiary sterujące i ograniczenia rodziny)
Standardowe zestawy właściwości mapowane przez narzędzie autorskie (materiał, klasa odporności ogniowej, wartości cieplne)	Niestandardowe właściwości, które narzędzie nigdy nie zamapowało do zestawu właściwości IFC
Ilości obliczane przez eksporter w momencie eksportu (powierzchnia, objętość, długość)	Formuły i aktywne powiązania sterujące tymi ilościami
Typ obiektu i klasyfikacja (ściana, odcinek kanału, pomieszczenie)	Zależna od widoku adnotacja 2D: wymiary, notatki tekstowe, odwołania do szczegółów powiązane z konkretnym widokiem rysunku

Konsultant otrzymujący plik IFC nie może edytować projektu tak, jak mógłby to zrobić jego autor; może go przeglądać, mierzyć, przeprowadzać na nim wykrywanie kolizji i wyodrębniać ilości, ale nie reguły parametryczne stojące za kształtem schodów czy dachu. Wymiana służy koordynacji i dokumentacji, a nie współtworzeniu.

Którą wersję schematu IFC powinien stosować projekt mieszkaniowy?

Sam schemat ma wersje, a wybór nie jest tylko kosmetyczny.

Wersja	Opublikowana	Co dobrze opisuje	Uwaga praktyczna
IFC2x3	2005	Budynki: architektura, konstrukcja, podstawowe MEP	Wciąż najszerzej wspierany cel eksportu i importu w starszych wersjach oprogramowania; najbezpieczniejsza domyślna opcja, gdy narzędzie konsultanta jest nieznane
IFC4	2013	Budynki, bogatsze zestawy właściwości, lepsze systemy i połączenia MEP	Czystszy model danych, ale nie każdy przeglądarka lub starsze narzędzie odczytuje go niezawodnie
IFC4.3 (ISO 16739-1:2024)	2024	Budynki plus infrastruktura, taka jak drogi, linie kolejowe i mosty	Przesada w przypadku pojedynczego domu; istotne, gdy projekt obejmuje infrastrukturę terenu

W przypadku projektu jednorodzinnego lub małego budynku mieszkalnego, IFC2x3 pozostaje pragmatycznym domyślnym wyborem do wymiany zewnętrznej: to wersja, którą każda przeglądarka, program do sprawdzania i starsze narzędzie konsultanta wciąż otwiera bez problemów. Warto nalegać na IFC4, gdy każda strona w łańcuchu potwierdzi czysty eksport i import, ponieważ przenosi on ustrukturyzowane dane MEP w bardziej wierny sposób.

Czym wymiana modeli IFC różni się od wysłania natywnego pliku projektu?

Plik natywny (.rvt, .pln, .skp) to kompletna, edytowalna kopia projektu autora, ale otwiera się poprawnie tylko w narzędziu, które go stworzyło, często tylko w odpowiedniej wersji. Wysłanie go konsultantowi, który nie posiada tego oprogramowania, oznacza wysłanie mu czegoś, czego nie jest w stanie otworzyć.

Wymiana IFC zamienia edytowalność na niezależność: strona odbierająca otrzymuje plik, który może otworzyć każda przeglądarka obsługująca IFC, kosztem utraty inteligencji parametrycznej opisanej powyżej. Zamienia również zależność od licencji na zależność od formatu: plik natywny staje się nieczytelny, gdy nikt w projekcie nie ma już aktualnej licencji na to oprogramowanie, podczas gdy plik IFC, będący otwartą normą ISO, pozostaje czytelny niezależnie od tego, za jakie narzędzia ktoś jeszcze płaci.

Te dwa podejścia nie konkurują ze sobą: pliki natywne do tworzenia treści w obrębie jednej branży, wymiana IFC do wszystkiego, co przekracza granice branżowe lub programowe.

Jak wygląda zdyscyplinowany przepływ pracy przy wymianie w praktyce?

Niezawodny przepływ pracy składa się z czterech kroków, powtarzanych przy każdym wydaniu modelu, a nie wykonanych raz na końcu:

• Eksport ze zdefiniowanym mapowaniem. Ustawienia eksportu IFC w narzędziu autorskim decydują o tym, które zestawy właściwości, wersja schematu i poziom szczegółowości geometrycznej zostaną wyeksportowane. Pozostawione domyślnie różnią się w zależności od narzędzia i wersji, dlatego projekt powinien je ustalić raz i używać ich wielokrotnie.
• Sprawdzenie wyniku przed wysłaniem. Otwórz wyeksportowany plik w neutralnej przeglądarce, a nie w narzędziu autorskim, i potwierdź, że hierarchia przestrzenna, jednostki i początek układu współrzędnych są zgodne z oczekiwaniami odbiorcy. Model oddalony o 40 metrów od miejsca, w którym powinien być, jest niewidocznie błędny, dopóki ktoś tego nie zauważy.
• Test dwukierunkowy (round-trip) przy pierwszej wymianie w projekcie. Eksport, a następnie ponowny import do drugiej instancji narzędzia źródłowego lub przeglądarki, aby potwierdzić, że nic nie zostało po cichu utracone. Warto zrobić to raz na projekt, a nie raz na plik.
• Ponowny eksport przy każdym wydaniu modelu. Koordynacja jest użyteczna tylko wtedy, gdy plik przekraczający granicę jest aktualny; nieaktualny eksport niweczy cel wspólnego środowiska danych.

Dlaczego prywatny klient powinien dbać o format wymiany?

Z wyboru otwartego formatu wymiany zamiast plików natywnych wynikają dwie konsekwencje. Po pierwsze, klient zachowuje czytelny model po tym, jak licencja któregokolwiek konsultanta wygaśnie, zmieni on dostawcę lub konsultant nie będzie już dostępny: plik IFC otwiera się w darmowych przeglądarkach lata później, podczas gdy plik natywny z porzuconej licencji może w ogóle się nie otworzyć. Po drugie, każda branża nadal używa narzędzia, w którym jest naprawdę dobra, ponieważ IFC jest wspólnym językiem między nimi, a nie wspólnym programem.

To właśnie umożliwia stworzenie użytecznej dokumentacji powykonawczej: eksport IFC skoordynowanego modelu, wraz z rysunkami, jest czymś, co przyszły wykonawca prac konserwacyjnych może otworzyć bez posiadania lub licencjonowania czegokolwiek.

Co najczęściej idzie źle podczas wymiany i jak to wykryć?

Powtarzającą się awarią nie jest uszkodzony plik, ale cicha niezgodność: jednostki wyeksportowane w milimetrach i zaimportowane przy założeniu metrów, właściwość, której narzędzie wysyłające nigdy nie zamapowało, więc strona odbierająca widzi puste pole, lub poziom szczegółowości geometrycznej zbyt niski, aby w ogóle wspierać wykrywanie kolizji. Żaden z tych błędów nie generuje komunikatu o błędzie; ujawniają się później, jako kanał, którego „nie ma” w modelu koordynacyjnym, lub klasa odporności ogniowej, która jest odczytana jako nieustawiona.

Sposobem na wykrycie jest procedura: ktoś otwiera wyeksportowany plik niezależnie od narzędzia, które go stworzyło, i sprawdza go pod kątem krótkiej listy (początek układu, jednostki, liczba kondygnacji, kilka znanych wymiarów), ta sama dyscyplina, która stoi za właściwą deklaracją Poziomu Opracowania.

Gdzie wymiana IFC znajduje się w szerszym procesie koordynacji?

Wymiana jest mechanizmem, a nie celem. To ona w ogóle umożliwia koordynację BIM między oddzielnie licencjonowanymi branżami: bez niej wykrywanie kolizji nie ma wspólnego elementu do testowania, a wspólne środowisko danych nie ma neutralnego pliku do przechowywania. Prawidłowe ustawienie opcji, wybór wersji i procedury sprawdzania raz, na wczesnym etapie, pozwala każdemu późniejszemu krokowi działać na danych, które każdy może faktycznie otworzyć.