05 Gru 2018

Nie tylko clash detection

Pierwsze co przychodzi na myśl przy okazji

05 Gru 2018

Pierwsze co przychodzi na myśl przy okazji modeli BIM i tego, co można dzięki nim uzyskać to weryfikacja kolizji międzybranżowych czyli wyszukanie w modelach różnego rodzaju błędów wynikających z przyjętych rozwiązań. W zależności od ich rodzaju kolizje można podzielić na kilka grup:

  • Hard clash („twarde” kolizje)
  • Soft clash (kolizje „miękkie”)
  • Workflow / 4D clash (kolizje montażowe /harmonogramowe /4D)

Pierwsza z nich jest najprostsza do zdefiniowania i najłatwiejsza do wykrycia przez programy mające w swojej funkcjonalności clash detection. Obejmuje bowiem wszelkiego rodzaju przecięcia lub nachodzenie na siebie elementów (patrz: grafika 1). W programach do weryfikacji kolizji najczęściej wystarczy jedynie wskazać modele mające uczestniczyć w sprawdzeniu.

grafika 1: przecięcie rury ze ścianą

Drugi rodzaj, tzw. kolizje miękkie, jest nieco trudniejszy do zlokalizowania, ponieważ wymaga wprowadzenia parametrów uwzględniających dodatkowe odchyłki. Mogą one obejmować tolerancje geometryczne elementów, np. ugięcie stalowej belki, lub użytkowe, np. dotyczące stref dostępu do urządzeń czy minimalnych koniecznych do zachowania odległości między elementami, które zapewnią możliwość montażu (patrz: grafika 2).

grafika 2: odległość między kanałem wentylacyjnym a stropem wynosi 55 mm przy minimalnej wynikającej z możliwości zamontowania zawiesi – 100 mm

Zlokalizowanie kolizji 4D, zwanych również montażowymi, jest jeszcze bardziej skomplikowane. Należy bowiem uwzględnić harmonogram dostaw materiałów lub kolejność wykonywania prac w trakcie wznoszenia obiektu (patrz: grafika 3). Problem ten jest więc bardzo złożony i wymaga zaangażowania do pracy programu, który oprócz możliwości przeprowadzenia „klasycznego” (na zasadach jak wyżej) procesu clash detection uwzględnia wymienione informacje związane z planowaniem robót. Jak można wywnioskować z tego tekstu potrafi to jedynie „prawdziwy” program do analizy 4D. Niestety póki co liczba takich narzędzi jest znikoma. Osobiście wiadomo mi o dwóch: Synchro oraz Vico Office.

grafika 3: przykład możliwej kolizji 4D (jeśli najpierw zostaną zamontowane elementy instalacji w kolorze cyan montaż czerwonych przewodów może być niemożliwy lub mocno utrudniony)

Podczas analizy wyników czasem zdarza się jednak, że trafiamy na sytuacje, które nie dają się zakwalifikować do żadnej z powyższych grup. Program do weryfikacji może wskazać na miejsca, gdzie konflikt albo nie występuje w ogóle (np. elementy jedynie się stykają; patrz: grafika 4), albo jego eliminacja w modelu jest na tyle pracochłonna, że okazuje się nieefektywna biorąc pod uwagę możliwość jej usunięcia na budowie. Tu dla przykładu można podać elastyczne przewody, które w modelu zawsze będą miały określony przez komponent kształt, ale na budowie zmiana ich położenia jest banalnie prosta i szybka w realizacji. Takie przykłady nazywam „nie-kolizjami”.

grafika 4: program wskazuje na istnienie kolizji na styku elementów

Interpretacja wyników nie jest więc aż tak łatwa, jak mogłoby się wydawać na pierwszy rzut oka. Nie wystarczy jedynie „wrzucić” modele do programu i kliknąć „weryfikuj” – to dopiero początek. Każda z kolizji powinna być dokładnie przeanalizowana przez kompetentną osobę(y). Tylko wtedy będzie można mieć pewność, że prawidłowo przeprowadziliśmy clash detection.

Jednak mimo, że zagadnienie to jest bardzo istotne z punktu widzenia zarówno projektantów, jak i wykonawców oraz wydaje się nieodłącznym elementem BIM bardzo często umyka nam fakt, że Building Information Modeling to nie tylko clash detection – o jego sile decyduje przede wszystkim to, że (przynajmniej w założeniu) powinien zapewnić rzetelne źródło informacji o obiekcie. A będą one rzetelne jedynie wtedy, gdy będziemy mieli pewność co do poprawności modelu, który je niesie. Stwierdzenie to zapewne sprowokuje wielu czytelników do zadania pytania: jak więc sprawdzić model BIM?

Przy codziennej pracy możemy się jednak przekonać, że sformułowanie na nie odpowiedzi zdecydowanie nie jest zadaniem trywialnym. Wręcz przeciwnie – jest to problem bardzo złożony. Należy bowiem odpowiedzieć na szereg kolejnych pytań. Jak powinny wyglądać modele? Jak zoptymalizować procesy weryfikacji? Skąd mieć pewność, że nic nie przeoczyliśmy? Można tak wymieniać dosyć długo. Na szczęście (co napawa lekkim optymizmem), odpowiedzi na przynajmniej część z nich można uzyskać stosunkowo łatwo.

Sporo wiedzy można pozyskać z publikacji uniwersytetów, stowarzyszeń i izb budowlanych z różnych krajów, które na przestrzeni ostatnich lat wydają coraz większą ilość materiałów na temat BIM. Te dokumenty postawiłabym jednak na drugim miejscu w hierarchii bo fundamentalnych zasad weryfikacji modeli BIM w formacie IFC należałoby szukać u źródła, tj. w materiałach publikowanych przez buildingSMART. Wytyczne bSI stanowią bowiem kompendium wiedzy na temat tego, jak w założeniu twórców formatu powinny wyglądać modele IFC, począwszy od klasyfikacji elementów i struktury bazy danych, przez definicję widoków, po zawartość modeli i wiele, wiele innych.

Jak widać ilość aspektów, które powinniśmy brać pod uwagę przy ocenie modeli może być naprawdę duża. Bez narzędzi, które to usprawniają byłaby też bardzo czasochłonna. Mimo, że twórcy oprogramowań do modelowania robią, co mogą, aby jak najbardziej ułatwić życie swoim klientom (np. tworzą dodatkowe narzędzia, usprawniają proces modelowania wykorzystując algorytmy, które część operacji wykonują za nich, powiększają ilość opcji eksportu do formatu IFC itd.) nadal bardzo dużo zależy od umiejętności i wiedzy użytkowników. A im „lepszy” będzie produkt, który wyjdzie spod ich rąk, tym łatwiej będzie z niego korzystać pozostałym osobom zaangażowanym w projekt. Właśnie dlatego tak ważna jest (pomijana dosyć często) weryfikacja samych modeli a nie tylko kolizji między nimi.

W tym miejscu warto się zastanowić nad odpowiedzią na kolejne pytanie: jaki program będzie do najlepszy, aby sprostać wszystkim powyższym zadaniom? Programów, które wykonują clash detection jest dosyć sporo (a ich liczba stale rośnie): wygaszana już Tekla BIMsight, Trimble Connect (o jego funkcjonalnościach możecie poczytać tu), Autodesk Navisworks, SimpleBIM, prawie wszystkie programy natywne do modelowania i wiele, wiele innych. Celowo pominęłam jedno oprogramowanie, bo wrzucenie go do jednego worka z wyżej wymienionymi uważam za ogromne faux pas, gdyż oferuje znacznie więcej niż tylko clash detection (wnioski tego typu można znaleźć wśród wielu użytkowników, np. tu lub tu). Ten program to Solibri Model Checker (SMC).

Biorąc pod uwagę, że jest to program jedyny w swoim rodzaju należałoby poświęcić mu nieco więcej uwagi. Dlatego też niniejszy post można uznać za pierwszy w cyklu traktującym o SMC.

Karolina Wróbel
M.A.D. Engineers

Leave a comment
More Posts
Comments
  1. Tomasz Wiatr Grudzień 9th, 2018 6:43PM

    Ciekawy tekst, problemowy, gratulacje.

    Na początek rzecz oczywista dla nas – celem powinno być unikalnie kolizji, a nie ich wykrywanie, co nie znaczy, że wykrywanie nie służy unikaniu, zwłaszcza jeśli zostanie przeprowadzone w porę, ale jeśli odbywa się dopiero w rękach wykonawcy jest sprawą cokolwiek kontrowersyjną, ale w Polsce nikogo ona nie bulwersuje. Na pytanie ‚jaki program będzie do tego najlepszy, aby sprostać wszystkim powyższym zadaniom?’ odpowiedż nie jest łatwa, ale pewne jest jedno. Piersza linia walki z kolizjami odbywać się musi w fazie projektowania. Wykrywanie kolizji ma nawet nasza polska Arcadia BIM, a nie miał do nie dawna jedynie słuszny system zdaniem niektórych.

    Dodam jeszcze jeden rodzaj kolizji, który powinien być wymieniony na początku. Chodzi o kolizje pozorne. Chodzi o taką sytuacją, gdy np. cienka rura czy przewód przechodzi np. przez ściankę działową, bo jedynym sposobem na jej wykonanie jest proste wykucie, które z góry zakładamy, ale czy chcemy o nim wiedzieć? Moim zdaniem tylko o tyle, o ile program pozwoli nam je wyeliminować przez półautomatyczne stworzenie otworu. Inna sprawa otwory w elementach konstrukcji nośnej rzecz jasna…

    Poza tym jeszcze jedna kolizja, która na określenie kolizji nawet nie zasługuje ale formalnie nią jest, jako żywo. Np. rura CO ułożona w izolacji termicznej podłogi jest kolizją na ‚całej linii’, bo nikt w modelu nie żłobi w styropianie rowków, ale takie to kolizje wykrywają te programy. Oczywiście dobrze, że są, ale chyba 99 procent ich ostrzeżeń jest fałszywym alarmem.

    Co do przyszłości TeklaBIMsight to ciekawa wiadomość, ale faktycznie ociężała to maszyna, poza tym nie działa wiecznie, no i trzeba rejestrować się celem podbicia statystyki. Ostatnio powstałe wtyczki do BIMvsion mogłyby zyskać większe uznanie gdyby ich nadmiar konieczny do zainstalowania nie przytłaczał, bo w pewnym momencie będzie trzeba narzędzia do zarządzania wtyczkami… albo dodatkowy monitor ;] ale to oczywiście żart, w każdym razie są ich 3 pakiety.

Comment