Wymiana danych w formatach OpenBIM w projektach infrastrukturalnych

W artykule poruszony jest temat niezwykle ważny w obszarze projektowania infrastrukturalnego w metodyce OpenBIM, jakim jest problem poprawnego zapisu semantyki – a raczej jej możliwych substytutów – komponentów infrastrukturalnych, dla których nie opracowano jeszcze odpowiednich specyfikacji formatu IFC lub nie ma oprogramowania, które by taką semantykę implementowało. Mowa tu przede wszystkim o projektach liniowych: drogowych, kolejowych, tunelach, gazociągach, a w dalszej perspektywie infrastruktury lotniskowej czy budownictwa wodnego, np. w związku z planowaną inwestycją Centralnego Portu Komunikacyjnego lub biorąc pod uwagę szerokie plany inwestycyjne Wód Polskich.

Skuteczna wymiana informacji w formatach otwartych BIM w przypadku projektów infrastrukturalnych stanowi wyzwanie. Dzieje się tak, bowiem najczęściej modele powstają w oprogramowaniu, które w najlepszym razie mają certyfikację dla formatu kubaturowego IFC 2x3, rzadziej IFC 4.0, a z braku standardów dla wymienionych wyżej obszarów projektowania, oprogramowanie najczęściej „nie zna” semantyki tych typów obiektów. Stąd projektanci tworzą modele np. mostów w posiadanym oprogramowaniu kubaturowym, modelują bryły mostów z komponentów typu belki, słupy, ściany, stropy – co może jeszcze nie budzi aż takiego oporu, choć pylon mostu a słup w budynku to jednak dwa zupełnie różne „słupy”. Różni je nie tylko sposób pracy, możliwe oddziaływania (siły) fizyczne i związany z tym model mechaniczny, ale także sposób wykonania, interakcje z innymi komponentami obiektu, czy sposób wymiarowania. Nawet skala obiektu, zazwyczaj zupełnie inna dla konstrukcji mostowych niż słupy w budynkach, niesie ze sobą zupełnie inne podejście do obliczeń wytrzymałościowych, teorii mechanicznej (lub jej rzędu), harmonogramowania, technologii wykonania czy nawet sprzętu niezbędnego do montażu. Jeśli jednak jezdnia na moście jest modelowana jako dach (bo łatwo zamodelować spadki), a cięgna mostów wiszących jako poręcze schodów, to zaczynamy mieć wątpliwości, czy to jeszcze jest modelowanie BIM i co jest warty taki model. Poza wizualizacją, prostymi przedmiarami i ewentualnie koordynacją 3D, przydatność takich modeli może być wątpliwa.
Artykuł poświęcony jest omówieniu technik i sposobów pracy pozwalających osłabić nieco tak poważne zarzuty o bezużyteczności BIM na obecnym etapie rozwoju standardów infrastrukturalnych, pokazując sposoby odbudowania nieobecnej de facto semantyki poprzez wykorzystanie mechanizmów IfcProxy, zbiorów właściwości Parameter Sets (Psets) i systemów klasyfikacji. Conditio sine qua non tej strategii jest standaryzacja protokołów wymiany informacji w projekcie, czyli dobry BIM management.

Stan rozwoju standardów infrastrukturalnych OpenBIM w roku 2021
Analiza stanu rozwoju standardów OpenBIM – szczególnie oczywiście chodzi tu o fundamentalne standardy: IFC (Industry Foundation CLasses), MVD (Model View Definition) oraz bSDD (buildingSMART Data Dictionary) dla projektów infrastrukturalnych prowadzi do wniosków, że organizacja buildingSMART – mimo świadomości wagi zagadnienia i szerokich planów działania w tym obszarze [1–4], szczególnie w zakresie opracowania semantyki komponentów infrastrukturalnych (IFC), nie była w stanie, jak na razie, wypracować ani spójnej koncepcji, ani praktycznie działających specyfikacji, pozwalających projektantom i wykonawcom przekazywać cyfrowo modele informacyjne obiektów budowlanych z obszaru budownictwa infrastrukturalnego i liniowego. Wyjątkiem jest tutaj jedynie specyfikacja mostowa IFC 4.2, która została przyjęta oficjalnie jeszcze w 2019 roku, choć jej obecny oficjalny status na stronie organizacji buildingSMART International jest oznaczony jako wycofany („withdrawn” – stan na czerwiec 2021), podobnie jak standard IfcAlignment (IFC 4.1) [5]. Jest to związane prawdopodobnie nie tyle z całkowitym wycofaniem tych standardów, ale z publikacją szerszego standardu IFC 4.3, będącego na razie w wersji rozwojowej Release Candidate 4 (RC4), obejmującego pokaźne spektrum obiektów infrastrukturalnych, w tym drogi, mosty, drogi kolejowe, porty i drogi wodne.

Jako uaktualnienie wcześniejszych publikacji [1–4] warto odnotować propozycje nowych klas i zmian w standardzie IFC 4.2, które wnosi standard IFC 4.3 RC4. Razem jest to nietrywialna liczba 62 nowych obiektów zebranych w tabeli nr 1.

Tabela 1. Nowe encje/klasy standardu IFC 4.3 TC4 [5]

Jak widać, buildingSMART International pracuje nad rozwojem standardów OpenBIM, a 62 nowe encje semantyczne i odpowiadające im klasy IFC z pewnością przybliżają perspektywę pełnego standardu infrastrukturalnego IFC5, jednak droga do tego celu jest jeszcze daleka, a plany wydania go w roku 2021 – jak się wydaje – nierealne. Także i drugi nurt standaryzacji bSI, standard bSDD, czyli definicje ontologii (słownik danych) dla encji infrastrukturalnych OpenBIM nie nadąża za wymaganiami rynku, ani nawet za postępem prac nad standardem IFC4.3RC4. W związku z tym w praktycznych zastosowaniach projektanci są zmuszeni odwoływać się do systemów klasyfikacji ogólnobudowlanej typu CoClass, Uniclas-2015 czy Omni-class, pozwalających na wymianę informacji bez utraty jej całej semantyki – przynajmniej w niektórych przypadkach.

Projekt infrastrukturalny bim realizowany narzędziami niewspierającymi semantyki komponentów infrastrukturalnych
Realizacja inwestycji infrastrukturalnych z żądaniem metodyki BIM staje się w naszym kraju coraz powszechniejsza. Po pierwszych „eksperymentach” prowadzonych głównie przez duże firmy w zakresie „samotnego BIM-u” stosowanego w niektórych inwestycjach infrastrukturalnych celem osiągnięcia większych zysków i redukcji ryzyka, pojawiają się projekty, takie jak obwodnica Zatora w ciągu drogi krajowej nr 28 [6], które zwiastują nowe „rozdanie” na rynku inwestycji infrastrukturalnych: zintegrowanego projektowania i realizacji BIM/3D/4D/5D, a w dalszej perspektywie BIM 6D/7D inicjowanego przez stronę zamawiającego. Jeśli dodamy plany budowy Centralnego Portu Komunikacyjnego (komponent lotniskowy) i związanego z tym projektem planu budowy „szprych” kolei dużych prędkości (komponent kolejowy) całkowicie w oparciu o metodykę BIM [7], a także kolejne plany GDDKiA
czy jednostek samorządowych budowy dróg, linii tramwajowych czy metra (Warszawa [8], Kraków [9]), zapotrzebowanie na projekty infrastrukturalne w metodyce BIM będzie prawdopodobnie lawinowo rosło. Z punktu widzenia strony wykonawczej, projektantów i generalnych wykonawców, trend ten będzie z pewnością wyzwaniem. Dlatego tak ważny jest rozwój kompetencji i umiejętności dostarczenia zintegrowanych projektów BIM.

Obserwacja krajowego rynku projektów infrastrukturalnych i analiza dostępnych projektów/danych o narzędziach infrastrukturalnych [10] pozwala konkludować, że na obecnym etapie do projektowania infrastrukturalnego na krajowym rynku stosowane są dwa typy programów:
■ do projektów typu liniowego (drogi, drogi kolejowe, tunele itp.) – oprogramowanie typu CAD 3D/BIM 3D lub innych pakietów/nakładek tego typu
■ do projektów obiektów inżynieryjnych (mosty, przepusty, wiadukty, stacje itp.) – oprogramowanie klasy kubaturowej.
O ile produkty z pierwszej grupy najczęściej natywnie wspierają – przynajmniej do pewnego stopnia – semantykę komponentów BIM z domeny infrastrukturalnej, o tyle najpopularniejsze na rynku produkty z drugiej grupy semantyki tej natywnie nie wspierają. Czy w takim razie można projektować elementy infrastruktury drogowej, kolejowej czy mostowej, bez konieczności inwestycji w nowe oprogramowanie, szkolenia, a może i sprzęt IT – a przy tym nie udawać przed inwestorem, że dostarcza się realny infra-BIM, a nie pseudo-infra-BIM [1]? Można, okazuje się całkiem sprawnie i z pożytkiem dla projektu użyć narzędzi kubaturowych do projektowania infrastrukturalnego i to nie na poziomie pseudo-infra-BIM-u. Prześledźmy możliwości na przykładowym zadaniu prostego modelowania obiektu typu inżynieryjnego w oprogramowaniu klasy kubaturowej [11].

 

 

Rys. 1. Przykładowy obiekt inżynieryjny [11]

Projekt obiektu inżynieryjnego
Modelowanie obiektu mostowego (przykładowy obiekt na rys. 1) w oprogramowaniu klasy kubaturowej [11] jest możliwe z wykorzystaniem albo wbudowanych komponentów BIM o ustalonej semantyce (przykładowo ściany, belki, zbrojenia, ławy/stopy fundamentowe, słupy itp.), których semantyka jest bliska lub taka sama jak komponentów infrastrukturalnych, albo z wykorzystaniem możliwości modelowania obiektów geometrycznych 3D klasy ogólnej (typu CAD 3D – ang. generic 3D models) z pomocą środowiska modelowania bryłowego (ang. massing environemt).

W drugim przypadku semantyki praktycznie nie ma, a przykładowe narzędzie do modelowania kubaturowego wykorzystane w tym artykule [11] wspiera jedynie konwersję 4 typów obiektów geometrycznych 3D do swoich kategorii semantycznych: dach wg powierzchni, ściana osłonowa/ściana wg powierzchni oraz strop wg powierzchni. Z tego skromnego arsenału narzędzi jako tako nadawałoby się do naszych celów jedynie konwertowanie powierzchni brył 3D do ścian. Można by w ten sposób wymodelować np. przyczółek mostu, w miarę dokładnie oddając geometrię. Jednak już semantyka tego obiektu z punktu widzenia modelu analitycznego, która w narzędziu do modelowania kubaturowego [11] jest reprezentowana albo jako ściana nośna, albo jako ściana pracująca na ścinanie/tarcza, jest dla obiektu typu przyczółek mostu daleka od jego sposobu pracy – w analizie wytrzymałościowej powinien być modelowany raczej jako bryła 3D analizowana elementami skończonymi 3D w ogólnym, trójwymiarowym stanie naprężenia.
Drugą ścieżką wymodelowania komponentów BIM typu mostowego o w miarę poprawnej semantyce infrastrukturalnej jest edytor rodzin w narzędziu do modelowania kubaturowego [11]. Udostępnia on wiele szablonów rodzin typu kubaturowego, w tym dla słupów, belek, ram konstrukcyjnych i wielu innych komponentów niosących bazową semantykę tych komponentów, a także możliwości w miarę elastycznego kształtowania geometrii 3D, w tym narzędzia do wyciągnięć, obrotów, przeciągnięć po ścieżce itp. Jeśli dodamy do tego zestawy właściwości na poziomie kategorii, rodziny i elementu, możemy w miarę poprawnie przekazać semantykę tego komponentu (rys. 2).
W wielu przypadkach narzędzia te będą adekwatne do zbudowania poprawnej semantyki także obiektów infrastrukturalnych, jeśli ich zachowanie, powiązania parametryczne i sposób pracy nie będą w istotny sposób odmienne od ich kubaturowych odpowiedników.

 

Rys. 2. Element przyczółku mostu – widok w Edytorze rodzin [11] (materiały dydaktyczne WIL PK)

Jednak co można zrobić, gdy ten w miarę skromny zestaw narzędzi [11] nie umożliwia realizacji wymogów zlecenia w projekcie infrastrukturalnym z narzuconym wymaganiem dostarczenia modelu BIM o poprawnej semantyce infrastrukturalnej? Pozostaje wtedy modelowanie komponentami o nieodpowiedniej semantyce z punktu widzenia projektu infrastrukturalnego lub modelowanie bryłowe (bryły generic 3D) i posiłkowanie się standardami OpenBIM, czyli eksportem do formatu IFC.

Narzędzia eksportu IFC i systemy klasyfikacji
Sztuczką, żeby ocalić więcej informacji semantycznej o komponentach BIM zawartych w modelu [11] są narzędzia: eksportu do IFC, do definiowania parametrów projektu i parametrów współdzielonych oraz wsparcie, jakie niesie pełniejsze i świadome wykorzystanie systemów klasyfikacji.
Narzędzie do eksportu IFC pozwala m.in. na przypisanie innej klasy semantycznej, niż własna kategoria programu kubaturowego [11], np. mapowanie komponentu typu strop, użytego jako warstwa jezdna mostu do komponentu typu IfcBridgePart oraz określenie jego typu jako DECK (uwaga: pisownia nazw klas i typów jest czuła na wielkość liter, w artykule używana jest pisownia wg specyfikacji
IFC 4.2). W tym przypadku możemy na wyjściu dostać model, który w dowolnej przeglądarce IFC będzie poprawnie podawał klasę IFC komponentu oraz stowarzyszone z nią zestawy typowych właściwości Psets. W razie potrzeby, możemy też tworzyć własne grupy parametrów Psets wg wymagań wymiany informacji projektu (EIR).

Rys. 3. Mapowanie kategorii do klasy IFC przez opcje eksportu IFC [11]

Mapowania klas dokonujemy na dwa sposoby: albo ogólnie, na poziomie kategorii (czyli wszystkie komponenty danej kategorii są mapowane jednorodnie na jakąś klasę IFC), albo indywidualnie, na poziomie rodziny, poprzez specjalnie zdefiniowane parametry projektu IfcExportAs, IfcExportType. Na rysunkach 3 i 4 pokazane są odpowiednie procedury robocze.
1. Mapowanie całej kategorii jako klasy IFC – należy zdefiniować odpowiednie mapowanie w opcjach eksportu dla IFC. W tym celu należy wejść do menu eksportu (rys. 3b), a następnie zdefiniować mapowanie klasy IFC i ewentualnie numeracji Typu dla danej klasy. Przykładowo, dla kategorii stropy konstrukcyjne – jeśli były użyte do zamodelowania wierzchniej warstwy mostu (rys. 3a) możemy mapować tę kategorię do klasy IfcBridgePart, ze zdefiniowanym typem tego komponentu jako DECK. Tego typu proces można powtórzyć dla każdej kategorii i każdej klasy IFC. Warto jednak pamiętać, że mapowanie to działa globalnie, dla wszystkich elementów danej kategorii, stąd jeśli jeden strop byłby użyty jako jezdnia (jak w omawianym przypadku), a inny jako płyta fundamentowa element przyczółku, to nie ma ich jak rozróżnić tą metodą jako odmienne typy klasy IfcBridgePart.

2. Mapowanie indywidualnych komponentów do klas IFC – mechanizm pozwalający przypisać komponentowi modelu indywidualnie dowolną klasę IFC i predefiniowany dla niej typ niezależnie od jego macierzystej kategorii w narzędziu do modelowania kubaturowego [11] (lub jej braku w przypadku obiektów bryłowych/modeli ogólnych). Zastosowanie tej możliwości wymaga jednak wykorzystania innego mechanizmu, tzn. utworzenia specjalnych parametrów projektu o nazwie IfcExportAs oraz IfcExportType, albo takich samych parametrów rodziny (w Edytorze rodzin), i przypisanie ich bądź danej rodzinie, bądź wszystkim kategoriom natywnym komponentów programu kubaturowego [11], dla których planowany jest eksport do semantycznych klas IFC. Po zdefiniowaniu parametrów tego typu możliwe jest mapowanie rodzin lub kategorii do dowolnych klas IFC przez wpisanie we właściwościach obiektu (dla typu lub elementu) jego mapowania. Rysunek 4 przedstawia sekwencję czynności w przypadku parametrów rodziny, możliwe jest także osiągnięcie podobnych efektów (zwłaszcza dla rodzin systemowych, których nie można edytować w edytorze rodzin) przez zdefiniowanie parametrów projektu (najlepiej przez wcześniejszą definicję parametrów współdzielonych – omawiane poniżej dla zagadnienia definicji własnych zestawów właściwości). Na rysunku 4b pokazano przypisanie przykładowej rodzinie ram konstrukcyjnych z rys. 2 klasy IfcBridgePart, z predefiniowanym typem ABUTMENT (przyczółek).

Rys. 4. a) tworzenie parametrów IfcExportAs na poziomie rodziny, b) zmiana kategorii ram konstrukcyjnych (rodzina Headstock Beam) na IfcBridgePart, typ ABUTMENT [11]

Co zrobić jednak w przypadku, gdy w standardzie IFC brak odpowiedniej klasy semantycznej, gdyż nie została zdefiniowana, albo zamawiający – czasami nie mając odpowiedniej wiedzy i świadomości – wymaga kubaturowej wersji standardu IFC, czyli najczęściej IFC 2x3 lub IFC 4.0? W takim przypadku używamy „wytrychowej” klasy IFC, tzw. IfcBuildingElementProxy, czyli komponentu typu ogólnego (podobnego nieco do omawianego wcześniej modelu bryłowego generic 3D), dla którego semantyka nie jest zdefiniowana w standardzie IFC, natomiast częściową informację o semantyce takiego komponentu możemy przekazać przez system klasyfikacji, np. Uniclass-2015.
Przykładowo, jeśli w oprogramowaniu kubaturowym [11] wymodelujemy narzędziami modelowania bryłowego tunel, a standard IFC dla tuneli jeszcze nie powstał i nie ma odpowiednich klas dla jego mapowania, możemy znaleźć odpowiedni kod klasyfikacji dla tunelu i we właściwościach tunelu, który został przez nas wymodelowany jako model ogólny, wpisać go w pole kodu klasyfikacji (pole kodu klasyfikacji znajdziemy we właściwościach praktycznie wszystkich kategorii). Na rysunku 5a) pokazano wynik poszukiwania kodów klasyfikacji Uniclass-2015 uzyskany z wyszukiwarki [12] dla tuneli i ich komponentów, a na rysunku 5b) pokazano wpisanie w komponent Model ogólny [11] wybranego kodu klasyfikacji.

Jak widać, przeszukiwanie wszystkich tabel Uniclass-2015 prowadzi do znalezienia ponad 60 kodów Uniclass możliwych do przypisania tunelom lub ich częściom, włącznie z definiowaniem technologii robót czy kodyfikacją komponentów składowych. Umożliwia to bardzo precyzyjne przeniesienie informacji o semantyce danego komponentu, zwłaszcza, że możemy dla poszczególnych komponentów przypisywać kilka kodów klasyfikacji, pozwalających pełniej wymienić istotne dla projektu informacje (rys. 5b). Dodajmy, że kody klasyfikacji warto podawać nie tylko dla komponentów typu Proxy, ponieważ można z ich pomocą przekazać wiele cennych informacji np. o technologii wykonania pewnych elementów, bezcennych dla modelowania BIM 4D i 5D (kosztorysy, przedmiary, harmonogramy). Dla tych zastosowań warto zwrócić uwagę, aby system klasyfikacji projektu był zgodny z normą ISO 12006-2, czyli był w klasie tzw. hierarchicznych systemów klasyfikacji obiektowej. Pozwala to oprogramowaniu dedukować częściowe zachowanie komponentów od szczegółu do ogółu i vice versa oraz budować z nich systemy.

 

Rys. 5. a) wyszukiwarka Unicalss-2015 [12], b) semi-semantyka komponentów modeli BIM definiowana z wykorzystaniem klasyfikacji Uniclass-2015 – kody dla tunelu ogólnego typu (En_80_96_90) z tabeli Entities oraz kod uściślający typ dla komponentów żelbetowych (Pr_20_76_92_65) z tabeli Products Unicalss-2015

PSETS – zestawy właściwości/parametrów IFC
Inną ciekawą opcją eksportu do standardów OpenBIM z formatów natywnych jest grupowanie parametrów w tzw. Parameter Sets (zbiory parametrów), popularnie zwanymi Psets. Można je eksportować pod własnymi nazwami, najczęściej wg wymogów zamawiającego określonych w EIR projektu. Dzięki temu mechanizmowi nawet obiekty klasy modele ogólne/bryłowe modelowania kubaturowego [11] (czyli te bez żadnej semantyki), mogą zostać wyposażone w wiele takich zestawów właściwości – jedne grupujące np. parametry materiałowe, inne geometryczne czy dla przedmiarów, a jeszcze inne ważne z punktu widzenia eksploatacji, będących także namiastką semantyki tych komponentów. Wtedy model wyeksportowany do IFC ma w przeglądarce IFC szereg zakładek z właściwościami, o logicznych nazwach i logicznej strukturze (mogą one być także przekazane przez zestawienia). Dla wielu procesów roboczych nie ma znaczenia,
że dany komponent nie ma poprawnej semantyki na poziomie programu do modelowania. Liczy się struktura danych wyeksportowanych do dalszych procesów,
np. agregacji z innymi bazami danych (np. cenniki czy KNR-y). Wtedy takie grupowanie parametrów pod potrzeby projektu, używanie ustalonego standardu nazewnictwa komponentów i struktury parametrów jest dużo ważniejsze, niż to, że np. w programie do modelowania dany komponent automatycznie generuje odpowiednie powiązania parametryczne z innymi komponentami (przykładowo, tnie jakieś otwory, czy zawija materiał na końcach). Podkreślmy tu jasno, że definiowanie własnych zestawów właściwości w projekcie nie jest obowiązkowe i jeśli się nie korzysta z tych mechanizmów, parametry komponentów też są eksportowane. Tyle że najczęściej są pogrupowane w chaotyczne często grupy, o przypadkowych nazwach wynikających z nazw grupowania parametrów w programie natywnym. Utrudnia to zrozumienie i poprawną interpretację informacji projektu innym osobom, zwłaszcza jeśli dokonujemy mapowania natywnych klas semantycznych oprogramowania używanego do modelownia na inne klasy, stosowniejsze dla projektów infrastrukturalnych.

Przykładowo, jeśli w narzędziu do modelowania kubaturowego [11] przyczółek mostu kształtujemy komponentem typu ściana pochyła, to wyeksportuje on parametry wg sposobu i zakresu zdefiniowanego dla ścian (w przypadku ściany będzie to zestaw parametrów o nazwie Pset_WallCommon i zakresie parametrów podanych dla tego zestawu pod adresem [13], gdzie wśród predefiniowanych parametrów nie ma parametrów charakterystycznych dla przyczółków mostów, a są np. typu odporność ogniowa, właściwości akustyczne czy termiczne, niezupełnie adekwatne dla mostów. Część z nich będzie oczywiście przydatna dla charakterystyki przyczółku mostu, ale nie będzie to pełny zbiór wymaganych danych – część istotnej informacji będzie nieobecna albo będzie musiała być przekazana niezależnie, np. w opisie tekstowym czy pliku Excela. Jeśli natomiast przygotujemy szablony zestawów parametrów (nazwy zestawów, nazwy parametrów/atrybutów, typy danych dla każdego parametru – np. tekstowe, numeryczne, data i czas, logiczne Tak/Nie itp.), to nawet dla komponentów typu IfcProxy uzyskamy efekt pełnej cyfrowej wymiany adekwatnych dla modelu informacyjnego danego obiektu informacji projektowych. Czy to otwarcie takiego modelu w przeglądarce IFC, czy wygenerowanie zestawień, będzie procesem prostym, zrozumiałym i informacyjnie bogatym. Krytycznym i najtrudniejszym elementem tego sposobu postępowania jest przygotowanie wymagań dla wspomnianych szablonów zestawów właściwości, czyli własnych Psetów i konsekwentne wypełnianie danymi kolejnych komponentów modelu. Czyli, mówiąc krótko, krytyczny jest dobry BIM management w projekcie. Dla maksymalizacji jego efektów najlepiej jest, kiedy te wymagania i specyfikację tych szablonów tworzy zamawiający/inwestor. W zaawansowanym wydaniu specyfikacja ta będzie wynikała z przygotowania strategii informacyjnej organizacji OIR, a potem tzw. słownika danych (ang. data dictionary), będącego podstawą do określenia wymagań informacyjnych projektowych PIR oraz wymagań informacyjnych eksploatacyjnych AIR [N1, 14]. Dyskusja tych zagadnień wykracza jednak poza ramy niniejszego artykułu.

Podsumowanie
W niniejszym artykule przedyskutowano kwestię możliwości podniesienia jakości modeli informacyjnych infra-BIM, realizowanych bardzo często narzędziami do modelowania kubaturowego lub nawet CAD 3D, z wykorzystaniem mapowania klas w trakcie eksportu, dedykowanych zestawów właściwości, obiektów typu IfcProxy i systemów klasyfikacji. Przedstawiony w tym artykule materiał nie ma charakteru szkoleniowego, jest raczej szkicem. Czytelnicy zainteresowani nabyciem praktycznych umiejętności powinni zgłębić temat z dostępnego systemu pomocy w używanym oprogramowaniu, detalicznych materiałów szkoleniowych, w tym także dostępnych w Internecie.

Sensem prowadzonych rozważań jest zainspirowanie czytelników do poszukiwań, jak w projektach infra-BIM prostymi relatywnie narzędziami pokonać różne ograniczenia oprogramowania BIM, podnieść jakość informacji poprzez pełniejszą cyfrową wymianę strukturalnej informacji projektowej lepiej dopasowanej do potrzeb projektów infrastrukturalnych i liniowych oraz uzyskać nowy poziom dojrzałości. Oczywiście najlepiej by było, gdyby tego typu sztuczki i obejścia nie były potrzebne, zwłaszcza że mają swoje ograniczenia, o których w ogóle nie było tu miejsca dyskutować. Najlepiej, aby dostępne oprogramowanie i specyfikacje formatów OpenBIM w pełni pokrywały semantykę komponentów infrastrukturalnych BIM. Jednak na ten moment przyjdzie nam jeszcze poczekać.

Inne ważne zagadnienie dyskutowane (choć nie wprost) w artykule, to rola i waga zarządzania procesem informacyjnym w projekcie BIM, dojrzała specyfikacja wymagań informacyjnych po stronie inwestorów, ich świadomość zapotrzebowania na konkretne informacje, o konkretnej i ustalonej strukturze, grupowaniu, zakresie i nazewnictwie parametrów oraz innych danych przekazywanych w różnych fazach rozwoju projektu.

Jak pokazują doświadczenia z rynku brytyjskiego (np. British Highways Data Dictionary), ogromnym ułatwieniem dla wszystkich stron i interesariuszy projektu jest posiadanie dojrzałych celów BIM, zdefiniowanych potrzeb informacyjnych na poziomie projektu PIR oraz eksploatacji AIR i wynikających z tej świadomości zasad definiowania zakresu oraz sposobu wymiany informacji w EIR (wg ISO 19650 są to metody i procedury wytwarzania informacji oraz standard informacyjny projektu [15]). Jak się wydaje, mimo braku standardów i niedojrzałości oprogramowania, przy dobrym BIM managemencie także i w Polsce możemy podnieść już obecnie poziom projektów infrastrukturalnych do pełnego stadium 2 [N1] (w brytyjskiej taksonomii jest to poziom dojrzałości 2), wymiany danych strukturalnych o gwarantowanym poziomie jakości i w pełni cyfrowym przebiegu wymiany informacji.

dr inż. Jacek Magiera
Politechnika Krakowska, Wydział Inżynierii Lądowej, Katedra Technologii Informatycznych w Inżynierii; Fundacja eccBIM

Artykuł zamieszczony w „Przewodniku Projektanta” nr 3/2021

Członkowie Polskiej Izby Inżynierów Budownictwa mogą składać zamówienie na drukowane wydanie „Przewodnika Projektanta” nr 4/2021.

Zachęcamy członków PIIB do wypełnienia formularza zgłoszeniowego zamieszczonego na stronie www.izbudujemy.pl/formularze/przewodnikprojektanta

W kolejnym wydaniu „Przewodnika Projektanta” będziemy poruszać tematy związane z m.in. konstrukcjami murowymi, sufitami podwieszanymi, czy wentylacją pływalni. Kontynuujemy cykl artykułów dotycząćych BIM, a także będą zamieszczone artykuły prawne, m.in. związane ze wstrzymaniem robót budowlanych.

 

Normy
N1. PN-EN ISO 19650-1 Organizacja i digitalizacja informacji o budynkach i budowlach, w tym modelowanie informacji o budynku (BIM) – Zarządzanie informacjami za pomocą modelowania informacji o budynku – Część 1: Koncepcje i zasady, PKN, luty 2019.

Literatura
1. Magiera J., OpenBIM, a krajowe projekty infrastrukturalne i liniowe – cz. I, Wiadomości Projektanta Budownictwa, ISSN 1899-6094, 2019, nr 3 (338), str. 12–15.
2. Magiera J., OpenBIM, a krajowe projekty infrastrukturalne i liniowe – cz. II, Wiadomości Projektanta Budownictwa, ISSN 1899-6094, 2019, nr 4 (339), str. 14–18.
3. Magiera J., BIM dla projektów infrastrukturalnych i liniowych – stan rozwoju technologii, [w:] Zeszyty Naukowo-Techniczne Stowarzyszenia Inżynierów i Techników Komunikacji Rzeczpospolitej Polskiej, Oddział w Krakowie, Seria: Materiały Konferencyjne, ISSN 1231-9155, 2019, nr 1 (118), str. 45–63, Tytuł numeru: Nowoczesne technologie w projektowaniu, budowie i eksploatacji infrastruktury drogowej miast, metropolii i regionów – NOVDROG’19.
4. Magiera J., Szarata A., Technologia BIM – cz. I. Obecny stan rozwoju i najbliższa przyszłość, Inżynier Budownictwa, 2020, nr 6 (184), str. 52–54.
5. https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ifc-release-notes/ (dostęp: czerwiec 2021 r.).
6. https://gddkia.eb2b.com.pl/open-preview-auction.html/132185/opracowanie-kompleksowej-dokumentacji-projektowej-i-opracowan-towarzyszacych-dla-zadania-pn-budowa-obwodnicy-zatora-w-ciagu-drogi-krajowej-nr-28-wraz-z-uzyskaniem-decyzji-administracyjnych-i-sprawowaniem-nadzoru-autorskiego (dostęp: czerwiec 2021 r.).
7. CPK czyli, co robimy, https://raportkolejowy.pl/cpk-czyli-co-robimy/ (dostęp: czerwiec 2021 r.).
8. Trzaskowski podjął decyzję o budowie III linii metra, https://www.transport-publiczny.pl/mobile/trzaskowski-podjal-decyzje-o-budowie-iii-linii-metra-67987.html (dostęp: czerwiec 2021 r.).
9. W Krakowie ma powstać premetro. Znamy dokładne plany, https://portalkomunalny.pl/w-krakowie-ma-powstac-premetro-znamy-dokladne-plany-419886/ (dostęp: czerwiec 2021 r.).
10. Jaki program BIM wybrać? TOP LISTA, https://bimcorner.com/pl/program-bim/ (dostęp: czerwiec 2021 r.).
11. Oprogramowanie klasy kubaturowej, https://www.autodesk.com/products/revit/overview (dostęp: czerwiec 2021 r.).
12. https://www.thenbs.com/our-tools/uniclass-2015 (dostęp: czerwiec 2021 r.).
13. https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/link/pset_bridgecommon.htm (dostęp: czerwiec 2021 r.).
14. Magiera J., Anatomia wymagań informacyjnych normy ISO 19650 – jak się odnaleźć w labiryncie OIR-AIR-PIR-EIR?, Przewodnik Projektanta, 1/2021, https://inzynierbudownictwa.pl/anatomia-wymagan-informacyjnych-bim-normy-iso-19650-jak-sie-odnalezc-w-labiryncie-oir-air-pir-eir/ (dostęp: czerwiec 2021 r.).
15. Magiera J., Czaplejewicz A., Wala K., Słownik podstawowych pojęć i terminów norm ISO 19650-1 i 19650-2 – propozycja polskiej terminologii BIM, BuilderScience, maj 2021, str. 68–77.