Autoryzowany dystrybutor Graphisoft Archicad w Polsce. Sprawdź korzyści

wsc
logo2 wsc
WSCBaza wiedzy

Zarządzanie zmianami na bazie modeli BIM na przykładzie Solibri Office

Zarządzanie zmianami na bazie modeli BIM na przykładzie Solibri Office

25/03/2024

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.

Tabela 1. Analiza zmian w modelach w podziale na etapy realizacji inwestycji

ZagadnienieZmiany w toku projektowaniaZmiany w toku realizacji robót
Zakres zmianMiędzy kolejnymi wydaniami jest ich stosunkowo dużo, są wynikiem - często wielowątkowej - analizy projektowejZakres zmian jest stosunkowo niewielki w odniesieniu do całości projektu i wynika z konkretnej potrzeby inwestora lub wykonawcy robót
Wpływ zmianyStosunkowo niski - zmiany są typowym elementem procesu projektowania i nie mają istotnego wpływu na przebieg prac budowlanych, terminowość realizacji lub końcowy koszt inwestycjiW 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 modeluInny członek zespołu projektowego, inwestor, w sytuacji kontraktów zaprojektuj i buduj - członek zespołu wykonawcy robótWykonawca robót, najczęściej nie będący członkiem zespołu projektowego
Świadomość zmiany odbiorcy modeluWysoka - odbiorcy zaangażowani są bezpośrednio w proces projektowania i posiadają wiedzę o zakresie zmian wprowadzanych między kolejnymi wydaniami projektuMoż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.

Budowa reguły do weryfikacji zmian

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:

  • Jest ona zaznaczona - program wykorzystuje do analizy pary komponentów o tym samym numerze identyfikacyjnym - po jednym ze starszego i nowego modelu (jeśli podczas doboru w starszym modelu zostaną GUID bez pary - Solibri określi komponenty jako usunięte, a numery występujące jedynie w nowszym modelu - jako dodane w ramach aktualizacji modelu);
  • Nie jest ona zaznaczona - Solibri dobierze komponenty w pary stary-nowy na podstawie zawartej w modelu geometrii oraz parametrów opisujących poszczególne elementy.

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.

Tabela 2. Gotowe zestawy reguł identyfikacji zmian w Solibri Office

Rule setsZestaw regułRegułaFiltr komponentów
Architectural RulesModel Revisions Comparison - ArchitectureComponent Comparisonwszystkie komponenty dyscypliny Architectural z wyłączeniem IfcSpace oraz IfcOpening
Space Comparisonkomponenty IfcSpace
Building Comparisonkomponenty IfcBuilding
Example Rules#206 Model ComparisonComponent Comparison - Architecturalwszystkie komponenty dyscypliny Architectural z wyłączeniem IfcSpace oraz IfcOpening
Space Comparisonkomponenty IfcSpace
Floor Comparisonkomponenty IfcBuildingStorey
Component Comparison - Structuralwszystkie komponenty dyscyplin konstrukcyjnych (Prefab Concrete, Steel Structure, Structural)
Component Comparison - Architectural - Components identified by GUID onlywszystkie komponenty dyscypliny Architectural z wyłączeniem IfcSpace oraz IfcOpening identyfikowanych jedynie na podstawie GUID (zaznaczony check-box Identify components only with GUID)
MEP RulesModel Revisions Comparison - Building ServiceComponent  Comparisonwszystkie komponenty dyscyplin instalacyjnych (Air Conditioning, Building Services, Cooling, Electrical, HVAC, Heat, Plumbing, Process, Special Piping, Sprinkler, Ventilation)
Building Comparisonkomponenty IfcBuilding dla wymienionych wyżej dyscyplin instalacyjnych
Structural RulesModel Revisions Comparison - StructureComponent  Comparisonwszystkie komponenty dyscyplin konstrukcyjnych (Prefab Concrete, Steel Structure, Structural)
Building Comparisonkomponenty IfcBuilding dla wymienionych wyżej dyscyplin konstrukcyjnych
Solibri Common Rules (Libraries)Model Comparisonporó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.:

  • dot. położenia komponentu, np. Top/Bottom Elevation, Global X/Y/Z, Distance to Next Floor, Latitude i Longitude (dot. IfcBuilding),
  • dot. jego wymiarów i danych ilościowych, np. Area, Height, Perimeter of Openings, Profile Height, Volume.

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.

Rodzaje zmian w modelu

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.

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?

Krok 1: komponenty usunięte i dodane

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:

  • “Komponenty niezmienione” mogą zostać zestawione przy pomocy okna Checked Components i funkcji Show Passed, jak pokazano na rysunku 6.,
  • “Komponenty usunięte” i “Komponenty dodane” będą widoczne w oknie Results (dostępnego w zakładce CHECKING z menu VIEWS jak pokazano na rysunku 6).

Krok 2: reguła nadrzędna

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:

  • Check all model component, if passed - reguły podrzędne będą analizowały wszystkie komponenty modelu jeśli reguła nadrzędna nie zwróciła żadnego błędu,
  • Check all model components, if issues - reguły podrzędne będą analizowały wszystkie komponenty modelu jeśli reguła nadrzędna zwróciła jakikolwiek błąd,
  • Check only failed components - reguły podrzędne będą analizowały te komponenty, dla których reguła nadrzędna zwróciła błąd,
  • Check only passed components - reguły podrzędne będą analizowały te komponenty, dla których reguła nadrzędna nie zwróciła błędu.

W prezentowanej analizie właściwe będzie wykorzystanie ostatniej z wymienionych opcji.

Krok 3: analiza ogólna zmienionych komponentów

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.

Krok 4: szczegółowa analiza 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

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ę.

Podsumowanie

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.