Jakiś czas temu zwróciliśmy uwagę na fakt, że weryfikacja modeli jest sprawą niezwykle ważną, chociaż często bagatelizowaną (odsyłam do tego artykułu NIE TYLKO CLASH DETECTION). Dziś postaram się nieco rozwinąć ten temat, chociaż nie obejdzie się bez dotknięcia również o innych, równie trudnych i złożonych zagadnień.
Poruszając się w obrębie weryfikacji poprawności modeli oraz mając na uwadze, że pierwszym, który powstaje jest najczęściej ten związany z branżą architektoniczną omawianie weryfikacji poprawności modeli warto zacząć od przeanalizowania zdefiniowanego przez Solibri zestawu reguł „BIM Validation – Architectural”. Opis całości oczywiście zająłby mnóstwo miejsca (zestaw zawiera bowiem aż 42 (!) reguły – patrz: grafika 1) dlatego na początek zajmiemy się wybranymi przypadkami.
Grafika 1: lista reguł dla zestawu „BIM Validation – Architectural” w SMC
O ile tylko znamy zasady weryfikacji to niektóre z reguł są bardzo łatwe do sprawdzenia nawet bez użycia narzędzi pokroju SMC. Czasem wystarczy do tego jedynie przeglądarka plików IFC. Dla przykładu można podać chociażby hierarchię modelu, która znajduje się na szczycie powyższej listy. Zgodnie z założeniami twórców formatu IFC powinna być ona zgodna ze schematem, który przedstawia grafika 2. Wynika z niej, że projekt musi zawierać co najmniej jeden budynek oraz minimum jedną kondygnację. Dodatkowo każdy element modelu powinien przynależeć do jednej z nich (jedynie czasem bezpośrednio do IfcSite lub IfcBuilding) [1].
Grafika 2: obowiązkowe i fakultatywne elementy zawarte w modelu IFC [1]
- Czy IfcProject zawiera IfcBuilding?
- Czy IfcBuilding zawiera IfcBuildingStorey?
- Czy w modelu są elementy nie przypisane do IfcBuildingStorey?
Właśnie w taki sposób do tego zagadnienia podchodzi algorytm zaimplementowany w SMC. Użytkownik jednak od razu zauważy pewne niezgodności modelu z przedstawioną strukturą (patrz: grafika 3) – ilość kondygnacji powinna być zdecydowanie większa – samo nadziemie ma ich 18. Skąd więc pozytywny wynik testu (patrz: grafika 4)?
Grafika 3: model wraz ze strukturą IFC widoczny w przeglądarce BIM Vision
Grafika 4: wyniki weryfikacji zestawu „Model Structure Check” w SMC dla modelu
Należy zauważyć, że algorytmy zawsze tworzone są, (a przynajmniej powinny być) w taki sposób, aby dzięki temu narzędzie:
- Działało poprawnie (poddawało ocenie określone kryteria),
- Było uniwersalne (uwzględniało jak największą ilość przypadków),
- Oceniało kryteria w sposób zero-jedynkowy.
Na pewno nie można więc powiedzieć, że reguła ta została opisana w nieprawidłowy sposób, przejawia bowiem wszystkie powyższe cechy. Sytuacja ta zwraca jednak uwagę na bardzo ważny aspekt dotyczący dowolnej weryfikacji modeli – programy ZAWSZE oparte są na algorytmach. Do rzetelnej INTERPRETACJI wyników potrzebny jest człowiek. Do tego najlepiej taki, który zna i rozumie wykorzystywane narzędzia.
Aby nie opierać tego wniosku na jednym tylko przykładzie prześledźmy kolejne reguły z grupy „Model Structure Check”. W tym celu zobaczmy jak mogłaby wyglądać struktura tego samego modelu (patrz: grafika 5). Przy eksporcie (poza oczywistą zmianą ilości kondygnacji) przekazano do pliku IFC reprezentację osi konstrukcyjnych.
Grafika 5: zmieniona struktura modelu
Prześledźmy ponownie wyniki. Jak pokazuje grafika 6 hierarchia modelu już nie jest prawidłowa ponieważ instancja IfcBuilding o nazwie „Building.b.1” nie zawiera żadnych kondygnacji a jedynie reprezentacje osi. Warto zwrócić uwagę na fakt, że również wynik weryfikacji pn. „Building Floors” różni się w stosunku do tego, który przedstawia grafika 4. Przeanalizujmy więc i tą regułę.
Grafika 6: wyniki analizy „Model Structure Check” dla modelu przedstawionego na poprzedniej grafice
Ponownie należy zacząć od zasad, którym powinny podlegać kondygnacje. Zacznijmy więc od tego, czym właściwie są. Łącząc definicję American Institute of Architects (AIA) oraz bSI [2]: kondygnacje w większości przypadków (tj. widoków MVD) posiadają jednoznacznie identyfikujące je w pionie rzędne i reprezentują poziomy (lub prawie poziomy) zbiór przestrzeni. Dla człowieka jednak sama rzędna może nie wystarczyć – należy więc nadać jej własną, indywidualną nazwę. Aby wprowadzenie kondygnacji do modelu miało sens powinny również zawierać jakieś elementy – same w ogromnej większości przypadków nie posiadają bowiem, podobnie jak IfcBuilding, reprezentacji geometrycznej.
Zredagujmy ponownie pytania, które mógłby obejmować algorytm sprawdzający poprawność definicji kondygnacji [3]:
- Czy model zawiera „puste” kondygnacje?
- Czy każda ze zdefiniowanych kondygnacji posiada indywidualną rzędną?
- Czy każda ze zdefiniowanych kondygnacji posiada swoją własną nazwę?
W tym przypadku weryfikacja założeń staje się nieco trudniejsza. Należy wziąć pod uwagę nieco więcej czynników a przy projektach obiektów wysokich odpowiednio przekłada się to na czas przeprowadzenia takiej analizy. Wyobraźmy sobie, że każdą ze zdefiniowanych kondygnacji będziemy sprawdzać „ręcznie”, np. tak, jak to pokazuje grafika 7:
- Rozwijamy strukturę do kondygnacji i sprawdzamy ich nazwy,
- Wyświetlamy każdą kondygnację z osobna aby zweryfikować jej zawartość,
- Jednocześnie sprawdzamy, czy zdefiniowane poziomy są unikatowe.
Grafika 7: wyniki analizy „Model Structure Check” dla modelu przedstawionego na poprzedniej grafice
Narzędzie wykonujące tą pracę za nas wydaje się coraz bardziej potrzebne, prawda? Ale idźmy dalej i sprawdźmy zupełnie inną regułę, np. „Components Above Columns” z grupy reguł „Deficiency Detection”. Ideą tej weryfikacji jest sprawdzenie, czy istnienie słupów w modelu jest sensowne, tj. czy stanowią one podporę dla innych elementów. Ręczna weryfikacja najprawdopodobniej wyglądałaby tak, że sprawdzający w przypadku każdego słupa (w tym modelu jest ich ponad 600 – patrz: grafika 8) wykonuje takie przycięcie modelu, które pozwoliłoby jednoznacznie stwierdzić, że bezpośrednio nad nim znajduje się inny element oraz dokonuje pomiaru weryfikując czy odległość ta mieści się w zadanej w regule tolerancji.
Grafika 8: słupy w analizowanym modelu
Ile czasu może zająć analiza jednego przypadku? Sprawdziłam – od 3 sekund (w przypadku słupków na dachu – nad nimi nie powinno być innych elementów) do ok. 1,5 minuty (w przypadku słupów znajdujących się wewnątrz budynku). Dla uproszczenia niech średnio zajmuje to jedną minutę – łącznie będzie to ponad 10 godzin. Dla porównania algorytmowi SMC ta czynność zajęła 2 (słownie: dwie) sekundy, a analiza konieczna do prawidłowej interpretacji wyników oraz utworzenie najpierw notatek a następnie prezentacji (jak to zrobić opisywaliśmy w tym artykule SOLIBRI MODEL CHECKER – WYSZUKIWANIE KOLIZJI) – nieco ponad 10 minut.
Różnica jest sześćdziesięciokrotna.
Czy teraz wizja wykonywania raz po raz (cyklicznie, np. raz w tygodniu) czynności weryfikacyjnych bez zastosowania zaawansowanego oprogramowania, nawet tylko dla kilku reguł, nie wydaje się być wręcz przerażająca?
Mając to na uwadze spróbujmy odpowiedzieć na pytanie z tytułu: człowiek czy algorytm? Otóż w realizacji tak skomplikowanych zadań, jakie nakłada na nas stosowanie nowych metod pracy jedno nie może istnieć bez drugiego. Człowiek bez pomocy maszyny nie będzie w stanie sprostać ogromowi pracy, jaka wynika ze stosowania metodologii BIM. Maszyna z kolei nie będzie potrafiła podjąć świadomej decyzji warunkującej dalsze kroki w procesie. Dopiero działając wspólnie osiągnięcie żądanego efektu jest w zasięgu ręki a podział pracy, jaki wyłania się z przedstawionego schematu zdaje się doskonale sprawdzać. A to dlatego, że każdy zaangażowany w ten mechanizm, czy to człowiek, czy maszyna, daje od siebie to, co ma najlepszego.
Bibliografia:
[1] T. Liebich, IFC 2x Edition 3. Model Implementation Guide, Version 2.0 red., buildingSMART International Modeling Support Group, 2009.
[2] buildingSMART International, [Online]. Available: http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/index.htm.
[3] Solibri Inc., [Online]. Available: https://solution.solibri.com/help/smc/9.8/en/Help.htm?construction_rules.htm.
Karolina Wróbel
M.A.D. Engineers
