Autoryzowany dystrybutor Graphisoft Archicad w Polsce. Sprawdź korzyści
Jedyne, czego można być w życiu pewnym, to zmiana. Dotyczy to także (a może nawet w szczególności) procesu projektowania. Zmiany nie są jednak czymś, czego powinniśmy się obawiać. Świadczą bowiem o tym, że szukamy lepszych rozwiązań i rozwijamy się. Taki pogląd ujawnia się także w przytaczanych coraz częściej normach i standardach, mających w nazwie “BIM”, np. w serii norm PN-EN ISO 19650. Iteracyjne podejście do projektowania to nic innego jak ciągłe zmiany w ustalonym kierunku wg określonego harmonogramu. Niestety obserwowana w rzeczywistości trajektoria zmian zamiast prostej drogi do celu częściej przypomina trasę pokonywaną w poszukiwaniu ulubionego produktu w supermarkecie, który znowu “zmienił się dla swoich klientów”.
Przez lata przywykliśmy do tego, że na dokumentacji wszystkie zmiany opisane są przez odpowiednie rejestry oraz chmurki. Nierzadko zdarza się, że nie odzwierciedlają one w pełni wprowadzonych korekt. Na szczęście nowe technologie przynoszą nam mniej zawodne narzędzia niż ludzka skrupulatność, która (nie oszukujmy się!) bywa tym mniejsza, im bliżej ustalonego dla wydania dokumentacji terminu. Do takich narzędzi zdecydowanie należy Solibri Office.
Narzędzie to posiada szereg bardzo przydatnych funkcjonalności, a do najbardziej rozwiniętych należą te dotyczące analizy jakościowej modeli. Nawet mało wprawny użytkownik może je wykorzystać dzięki szerokiej bazie gotowych reguł.
Zanim jednak przyjdzie czas na szczegółowe omówienie możliwości programu warto pochylić się nieco nad problematyką zmian projektowych, bo różni się ona nieco w zależności od etapu realizacji inwestycji, co przedstawia Tabela 1.
Zagadnienie | Zmiany w toku projektowania | Zmiany w toku realizacji robót |
Zakres zmian | Między kolejnymi wydaniami jest ich stosunkowo dużo, są wynikiem - często wielowątkowej - analizy projektowej | Zakres zmian jest stosunkowo niewielki w odniesieniu do całości projektu i wynika z konkretnej potrzeby inwestora lub wykonawcy robót |
Wpływ zmiany | Stosunkowo niski - zmiany są typowym elementem procesu projektowania i nie mają istotnego wpływu na przebieg prac budowlanych, terminowość realizacji lub końcowy koszt inwestycji | W zależności od zakresu zmiany może mieć ona istotny wpływ na przebieg prac budowlanych, terminowość realizacji lub końcowy koszt inwestycji |
Główny odbiorca zmienionego modelu | Inny członek zespołu projektowego, inwestor, w sytuacji kontraktów zaprojektuj i buduj - członek zespołu wykonawcy robót | Wykonawca robót, najczęściej nie będący członkiem zespołu projektowego |
Świadomość zmiany odbiorcy modelu | Wysoka - odbiorcy zaangażowani są bezpośrednio w proces projektowania i posiadają wiedzę o zakresie zmian wprowadzanych między kolejnymi wydaniami projektu | Może być znikoma, personel budowy często opiera swoją wiedzę o zakresie zmiany na podsumowaniu przygotowanym przez projektanta i zamieszczonym na rysunkach lub informacjom przekazywanym w toku narad budowy |
Z powyższego zestawienia można wnioskować, że analiza zmian w toku projektowania nie musi być kwestią kluczową. Sytuacja ta jednak zmienia się diametralnie w momencie, w którym mija czas przygotowań do budowy i staje się tym istotniejsza, im roboty są bardziej zaawansowane a zmiany są trudniejsze do wprowadzenia - dlatego też zamieszczony w dalszej części przykład bazować będzie właśnie na sytuacji, która mogłaby mieć miejsce w toku realizacji robót.
Aby móc analizować zmiany w Solibri Office należy najpierw zrozumieć sposób definiowania i działania dedykowanych do tego celu reguł. Choć dla każdej z dyscyplin projektowych w Solibri zdefiniowano domyślne zestawy reguł weryfikacji, każde zawarte w nich sprawdzenie bazuje na jednej regule bazowej - #206 Model Comparison, której budowa została przedstawiona na rysunku 1.
W sekcji [1] użytkownik powinien zdefiniować modele, które będą podlegały analizie. Może zrobić to bezpośrednio - przez wskazanie konkretnych plików z utworzonego uprzednio w Solibri Office modelu złożeniowego (federowanego) - lub skorzystać z informacji zawartych w plikach IFC. Program może automatycznie określić, który model jest starszy, a który nowszy, wykorzystując do tego “Time stamp”, czyli informację zapisywaną w header pliku wskazującą na datę i godzinę wykonania eksportu do IFC z programu natywnego.
W ramach check-box [2] - Identify components only with GUID - użytkownik może określić, w jaki sposób Solibri Office ma identyfikować komponenty w modelu. Jeśli:
Użytkownik powinien podjąć tą decyzję uwzględniając sposób wykonywania modelu przez jego autora. Jeśli spełnione są łącznie następujące warunki: autor modelu co do zasady edytuje istniejące elementy (nie usuwa ich i nie wprowadza nowych) a podczas kolejnych wydań GUID istniejących komponentów się nie zmienia - użytkownik może bez obaw zaznaczyć omawianą opcję.
W sekcji [3] - Checked Components - użytkownik powinien określić, które komponenty chce poddać analizie. Reguła #206 Model Comparison domyślnie sprawdza wszystkie komponenty oraz dodatkowo kondygnacje.
W Solibri Office użytkownik znajdzie jednak szereg gotowych zestawów reguł, nakierowanych na potrzeby konkretnych dyscyplin projektowych. Ich zestawienie przedstawia tabela 2.
Rule sets | Zestaw reguł | Reguła | Filtr komponentów |
Architectural Rules | Model Revisions Comparison - Architecture | Component Comparison | wszystkie komponenty dyscypliny Architectural z wyłączeniem IfcSpace oraz IfcOpening |
Space Comparison | komponenty IfcSpace | ||
Building Comparison | komponenty IfcBuilding | ||
Example Rules | #206 Model Comparison | Component Comparison - Architectural | wszystkie komponenty dyscypliny Architectural z wyłączeniem IfcSpace oraz IfcOpening |
Space Comparison | komponenty IfcSpace | ||
Floor Comparison | komponenty IfcBuildingStorey | ||
Component Comparison - Structural | wszystkie komponenty dyscyplin konstrukcyjnych (Prefab Concrete, Steel Structure, Structural) | ||
Component Comparison - Architectural - Components identified by GUID only | wszystkie komponenty dyscypliny Architectural z wyłączeniem IfcSpace oraz IfcOpening identyfikowanych jedynie na podstawie GUID (zaznaczony check-box Identify components only with GUID) | ||
MEP Rules | Model Revisions Comparison - Building Service | Component Comparison | wszystkie komponenty dyscyplin instalacyjnych (Air Conditioning, Building Services, Cooling, Electrical, HVAC, Heat, Plumbing, Process, Special Piping, Sprinkler, Ventilation) |
Building Comparison | komponenty IfcBuilding dla wymienionych wyżej dyscyplin instalacyjnych | ||
Structural Rules | Model Revisions Comparison - Structure | Component Comparison | wszystkie komponenty dyscyplin konstrukcyjnych (Prefab Concrete, Steel Structure, Structural) |
Building Comparison | komponenty IfcBuilding dla wymienionych wyżej dyscyplin konstrukcyjnych | ||
Solibri Common Rules (Libraries) | Model Comparison | porównanie wszystkich IfcEntity oraz IfcBuildingStorey |
Aby dodatkowo określić zakres weryfikacji zmian użytkownik powinien określić, jakie dane mają być analizowane. Predefiniowane w Solibri zestawy reguł wskazują na zakresy typowo przenoszonych danych w ramach określonej dyscypliny projektowej. Każdy projekt może mieć jednak inne wymagania - a zatem także inny standard zapisu danych istotnych dla odbiorcy modelu (np. dedykowany property set lub nazewnictwo parametrów).
Wskazanie w sekcji [5] - Compared Properties - konkretnych parametrów spowoduje, że w przypadku, gdy dla któregokolwiek komponentu wskazanego w sekcji [2] zmieni się jego wartość Solibri zwróci wynik (issue) wskazując wartość pierwotną oraz po zmianie. Dotyczy to także sytuacji, gdy parametr zostanie usunięty lub dodany w jednej z analizowanych wersji modeli.
Predefiniowane zestawy właściwości obejmują nie tylko parametry techniczne zawarte w zestawach Pset_ComponentCommon, ale także m.in.:
Zasadniczo wszystkie tego typu zmiany można zidentyfikować zaznaczając check-box [4] - Geometries. Należy jednak mieć na uwadze, że Solibri wykaże wszelkiego typu zmiany geometrii - nawet te, które w przeważającej części przypadków są dla użytkownika nieistotne, np. typ definicji geometrii (Boundary Representation, Solid lub Extrusion) lub liczba poligonów opisujących komponent (Triangle Count) - wskazując jedynie, że Geometry is changed. Aby dokonać rzetelnej analizy i uzyskać satysfakcjonujące (tj. istotne dla użytkownika) wyniki i móc wyciągnąć właściwe wnioski, użytkownik powinien szczególną uwagę poświęcić sekcjom [4] i [5] reguły.
Aby prawidłowo wykonać opisane wyżej zadanie należy zadać sobie pytanie: jakiego rodzaju zmiany mogą wystąpić w modelu? Zasadniczo można wydzielić dwie główne grupy: zmiany właściwości i zmiany geometrii (przy czym zmiany obrysu komponentu i jego lokalizacji mogą występować niezależnie od siebie). Graficzny podział komponentów, które mogą występować w analizowanym - zmienianym - modelu przedstawia rysunek 2. Zastosowane oznaczenia literowe należy rozumieć jak wskazano poniżej:
A Komponenty zmieniły swoją lokalizację w przestrzeni trójwymiarowej, w szczególności zostały przesunięte, ale ich kształt ani parametry nie uległy zmianie.
B Geometria komponentów uległa zmianie, np. zmiana długości, zmiana lokalizacji lub ilości otworów, inny sposób docięcia do sąsiedniego komponentu. Zmiana tego typu prawie zawsze wiąże się ze zmianą w zakresie danych dot. lokalizacji. Uwaga: z uwagi na zakres dostępnych parametrów możliwe, że nie wszystkie będą możliwe do wykrycia (np. gdy symetrycznie względem środka ciężkości komponentu przesunięto istniejące otwory bez zmiany ich wielkości i ilości)
C Zmieniły się informacje niegeometryczne o komponencie, np. nazwa, oznaczenie, materiał, dane techniczne.
AB Większość zmian geometrii niesie ze sobą zmianę lokalizacji komponentu w przestrzeni, np. zmiana długości powoduje modyfikację długości bounding box komponentu, zmiana środka ciężkości komponentu, zmiana granicznych rzędnych bounding box.
AC Zmianie parametrów niegeometrycznych towarzyszy przesunięcie w przestrzeni bez zmiany geometrii komponentu.
BC Zmianie geometrii komponentu nie skutkującej zmianie lokalizacji towarzyszy zmiana danych niegeometrycznych, np. komponent opisany w B zmienił materiał.
ABC Zmianie uległy jednocześnie wszystkiego typu informacje o komponencie.
Użytkownik może analizować wszystkie zmiany łącznie, ale powinna to być jednak świadoma decyzja. Do zobrazowania możliwego sposobu postępowania posłuży poniższy przykład.
Odbiorcą modelu jest osoba nadzorująca montaż konstrukcji stalowej. Analizując model dysponuje ona parametrami widocznymi na rysunku 3. Analizując zmiany w otrzymanym modelu jednym z pierwszych pytań, które powinien zadać sobie hipotetyczny kierownik montażu brzmi: czy zakres elementów składowych konstrukcji nie został zmieniony, tj. czy nie zostały do niej dodane elementy lub nie zrezygnowano z montażu jakiegoś fragmentu?
W pierwszym kroku kierownik montażu może przygotować regułę, która pozwoli mu odpowiedzieć na pytanie, czy w modelu znajdują się nowe komponenty lub wcześniej istniejące zostały usunięte. Ta reguła oraz wszystkie kolejne uwzględniają założenie, że projektant zachowuje reżim w zakresie GUID komponentów modelu, a użytkownik nie analizuje śrub oraz otworów w modelu - założenia te przedstawia rysunek 4. Uzyskane z pomocą reguły wyniki przedstawia rysunek 5.
Tak wykonana analiza pozwoli użytkownikowi ujawnić pierwsze trzy grupy komponentów w porównywanych modelach widoczne na rysunku 2:
Dużo trudniejsza jest analiza komponentów, które uległy jakiejś zmianie. Ważne jest przy tym, aby kolejne definiowane sprawdzenia nie powielały uzyskanych już wyników - może to powodować trudności w ich interpretacji.
Mając tego świadomość hipotetyczny użytkownik wykluczy uzyskane w pierwszym kroku wyniki dot. elementów usuniętych i dodanych. W tym celu może wykorzystać mechanizm reguł nadrzędnych i podrzędnych (Gatekeeper Rules oraz Sub-Rules). Aby z niego skorzystać należy przejść do zakładki File a następnie wybrać polecenie Ruleset Manager. Po otwarciu modyfikowanego zestawu reguł należy skopiować regułę zwracającą elementy usunięte i zmienione - stanie się ona regułą nadrzędną dla kolejnych, dotyczących szczegółowej analizy zmienionych komponentów.
Po dodaniu reguł podrzędnych użytkownik może zdecydować, w jaki sposób Solibri ma potraktować wyniki z reguły nadrzędnej:
W prezentowanej analizie właściwe będzie wykorzystanie ostatniej z wymienionych opcji.
Kolejnym krokiem, który wykona przykładowy kierownik montażu jest zdefiniowanie reguł, które zwrócą pozostałe wyniki będące w kręgu jego zainteresowania. W tym celu określi istotne dla niego parametry, które podda analizie. Na cel niniejszego przykładu będą to właściwości oznaczone kolorem różowym na rysunku 7.
Jak widać część informacji można pozyskać z modelu z pomocą więcej niż jednego parametru (np. profil komponentu, rzędne), co oznaczono osobnymi kolorami. Dokonując selekcji parametrów odbiorca modelu powinien mieć na uwadze, że autor mógł przypadkowo lub umyślnie ukryć wprowadzone zmiany. W związku z tym powinien podjąć decyzję, czy skorzysta z parametrów zawartych w Pset określonych w standardzie projektu, z danych pochodzących bezpośrednio z modelu natywnego (te dane zawarte są w zakładce BIM Data) czy też z obu wskazanych grup danych.
Na rysunku 8 przedstawiono zakres analizowanych parametrów zdefiniowany przez hipotetycznego kierownika montażu. Kolorami oznaczono komponenty odpowiadające głównym typom zmian widocznych na rysunku 2. Po dokonaniu selekcji komponentów użytkownik może już zdefiniować je w sekcji [5] Compared Properties reguły podrzędnej (rysunek 8).
Zasadę tworzenia reguły nadrzędnej oraz zwracającej wszystkie zmienione komponenty przedstawia rysunek 9 (uwaga - modyfikacja relacji między regułami możliwa jest jedynie z poziomu okna Ruleset Manager). Jak widać sposób prezentacji wyników (domyślnie Solibri grupuje wyniki na podstawie typu komponentu i zmodyfikowanych właściwości) i opis zidentyfikowanych podczas analizy zmian w dalszym ciągu może być czasochłonny dla użytkownika.
Ułatwieniem dla hipotetycznego kierownika montażu może być utworzenie dedykowanych reguł lub ich zestawów, w których odpowiednie zastosowanie mechanizmu reguł podrzędnych i nadrzędnych pozwoli zwrócić odpowiedzi na konkretne pytania nurtujące użytkownika. Wbrew pozorom zadanie to nie musi być pracochłonne choć z pewnością wymaga zaangażowania.
Punktem wyjścia będą konkretne pytania, na które będzie chciał odpowiedzieć kierownik montażu. W kolejnym kroku określi on oczekiwane rezultaty analizy i powiąże je z działaniami, które będzie musiał podjąć w toku realizacji swoich obowiązków. Ostatnim krokiem będzie określenie zakresów zmian, których będzie poszukiwał w modelu - będą one stanowiły podstawę do zdefiniowania odpowiednich reguł w Solibri. Przykładowy proces analizy przedstawia rysunek 10.
Do opracowania reguł niezbędnych do uzyskania pożądanych odpowiedzi użytkownik może wykorzystać dane zdefiniowane w regule widocznej na rysunku 8 - wystarczy, że wykona jej kopię i usunie parametry, które nie będą istotne z punktu widzenia szczegółowej analizy, której powinien odpowiednio je ułożyć korzystając z mechanizmu reguł nadrzędnych i podrzędnych, jak pokazano na rysunku 11.
Wyniki wszystkich sprawdzeń wyświetlane są w oknie RESULTS dostępnego jak pokazano na rysunku 6. Solibri domyślnie grupuje je według rodzaju błędu, klasy komponentu oraz jego typu. Jest to układ oparty o kategorię (rysunek 12 - Category hierarchy). Jeśli jednak nie jest on dla użytkownika wygodny lub użyteczny Solibri oferuje możliwość przełączenia widoku na standardową listę, gdzie każda uwaga będzie stanowiła osobną pozycję (patrz: rysunek 12).
Przykładowy kierownik montażu może jednak nie być zadowolony z takiej prezentacji wyników, bo w kontaktach ze swoim zespołem nie posługuje się ani typami, ani numerami komponentów nadawanymi przez Solibri, a numerami elementów widocznymi w dokumentacji projektowej. Aby zmienić sposób prezentacji wyników powinien on wybrać trzecią z dostępnych opcji - Custom Hierarchy. a następnie wykonać czynności pokazane na rysunku 13.
Użytkownik ma możliwość utworzenia hierarchii wielopoziomowej, na wzór Category Hierarchy wykorzystującej dowolne parametry. Przykładowy kierownik montażu może np. skategoryzować zmiany według profilu oraz numeru elementu (Part mark). Hierarchię oraz usystematyzowane wg niej wyniki przedstawia rysunek 14.
Definiując własną hierarchię wyników należy mieć jednak na uwadze, że część zidentyfikowanych błędów może być przypisana do kilku grup. Jeśli taka sytuacja wystąpi wybór podwójnie ujętej w hierarchii uwagi spowoduje podświetlenie tej samej uwagi (patrz: rysunek 15). Nieodpowiednie usystematyzowanie wyników - jeśli nie jest podyktowane szczególnymi potrzebami użytkownika - zamiast ułatwić, może utrudnić ich analizę.
Analiza zmian nie jest zadaniem łatwym. Dysponowanie prawidłowo wykonanym modelem może ją znacznie usprawnić, a Solibri Office jest idealnym narzędziem do wsparcia w tym zakresie. Choć budowa reguły służącej do analizy zmian wydaje się bardzo prosta, posiada szeroki wachlarz zastosowania i pozwala na uzyskanie wiarygodnych i przede wszystkim użytecznych wyników. Czas poświęcony na zbudowanie własnego zestawu reguł weryfikacji z pewnością zwróci się z nawiązką podczas kolejnych sprawdzeń. A to, że konieczne będzie ich wykonanie - biorąc pod uwagę nieustające ryzyko zmian - jest wysoce prawdopodobne.
Karolina Wróbel
M.A.D. Engineers sp. z o.o.