Weryfikacja modelu powykonawczego – Solibri

Jeszcze do niedawna modelowanie kojarzyło się głównie z etapem projektowania. Dziś świadomość tego, że model nie kończy swojego żywota wraz ze skierowaniem projektu do realizacji wydaje się już dość powszechna. Inwestor Ośrodka Narciarstwa Biegowego i Biathlonu (ONBiB) w Szklarskiej Porębie – Dolnośląski Park Innowacji i Nauki S.A. (DPIN) – już w 2018 roku wyraził ją następującym zapisem:

Rysunek 1. Załącznik nr 1 do Części II SIWZ w postępowaniu nr: ZP/NP/ 04/2018 – wymagane rodzaje modeli

Pierwszy z wymienionych modeli dotyczy oczywiście fazy realizacji robót budowlanych. Kolejne – zgodnie z treścią umowy – powinny zostać dostarczone po zakończeniu tego procesu.

Zanim jednak omówimy sobie zawartość powykonawczych i zarządczych modeli opracowanych dla ONBiB, warto przypomnieć, że nie była ona wyraźnie określona przez DPIN na etapie postępowania. Specyfikacja poszczególnych modeli była wynikiem ogólnych wymagań opisanych w SIWZ, zapisów przedłożonej przez GW (konsorcjum firm: PORR S.A. – lider, Akme Zdzisław Wiśniewski oraz Elektromontaż Rzeszów S.A. – partnerzy) Metodyki[1] i uzgodnień poczynionych na etapie realizacji, które znalazły swoje odzwierciedlenie w Planie Realizacji BIM

Specyfikacja modeli

Generalny Wykonawca w pierwszej kolejności – na podstawie zakresu wskazanego przez Zamawiającego w SIWZ – doprecyzował listę modeli, które będą opracowane w ramach projektu. W efekcie lista powykonawczych modeli prezentuje się następująco:

• W ramach obiektu wydzielono modele architektury, konstrukcji, instalacji wewnętrznych (wodną, kanalizacyjną, elektryczną, wentylacji i klimatyzacji oraz technologii uzdatniania wody basenowej) i wyposażenia. Dodatkowo ze względów technicznych wydzielono modele izolacji instalacji,
• W ramach zagospodarowania terenu osobno wydzielono modele: terenu, wyposażenia zewnętrznego oraz sieci (wod.-kan i hydrograficznej, elektrycznej i teletechnicznej oraz dolnego źródła ciepła).

Następnie zawartość każdego z modeli została doprecyzowana poprzez wskazanie rodzaju występujących w nich elementów oraz ich klasyfikacji. W dalszej kolejności określono zestaw parametrów opisujących występujące w projekcie elementy – jeśli parametr powinien zostać przypisany do danego rodzaju elementu oznaczono go znakiem [x] (patrz: rysunek 2).

Rysunek 2. Specyfikacja modelu instalacji uzdatniania wody basenowej (autor: konsorcjum firm: PORR S.A. – lider, Akme Zdzisław Wiśniewski oraz Elektromontaż Rzeszów S.A. – partnerzy)

Weryfikacja kompletności modeli

Tak przygotowana specyfikacja zawartości modeli stanowi bardzo wygodną podstawę do weryfikacji. Oczywiście można dokonać weryfikacji ręcznej jednak mając na uwadze, że na powykonawczy model inwestycji ONBiB składa się przeszło 180 tysięcy (!) elementów – byłaby to praca żmudna, nieefektywna i narażona na szereg błędów ludzkich. Na szczęście w dobie galopującej technologii dysponujemy narzędziami, które znacznie usprawniają realizację tego typu zadań, choć i one wymagają pewnego nakładu czasu i pracy. Przede wszystkim trzeba przełożyć istniejące wymagania względem modelu i jego elementów na język zrozumiały dla algorytmu wykorzystywany przez program. W analizowanym przykładzie będzie to Solibri Office.

Program ten oferuje szereg predefiniowanych reguł weryfikacji modeli (przykładowe reguły przedstawia rysunek 3 poniżej). Świadomy użytkownik wie jednak, że wiele z nich, aby zwrócić wiarygodne i użyteczne wyniki, wymaga dostosowania do analizowanego projektu

Rysunek 3. Przykładowe reguły dostępne w Solibri Office (panel Ruleset manager)

Użytkownik może nie tylko zmieniać parametry dokonywanych weryfikacji, ale tworzyć również własne zestawy reguł, dowolnie je grupować i nazywać, dzięki czemu otrzymujemy automat do weryfikacji dedykowany konkretnemu projektowi. Aby udowodnić, że faktycznie jest to możliwe, w dalszej części artykułu, posługując się jednym z modeli, pokażemy, jak można go zweryfikować pod kątem danych ujętych w tabeli widocznej na rysunku 2 powyżej.

Tworzenie własnego zestawu reguł

Aby stworzyć swój własny zestaw reguł należy w górnym panelu wybrać polecenie ≪FILE≫, a następnie ≪Ruleset Manager≫. W kolejnym kroku należy utworzyć nowy zestaw reguł przy pomocy polecenia ≪New Ruleset≫ znajdującego się w prawej części panelu ≪WORKSPACE≫. Gdy zestaw reguł zostanie utworzony można przystąpić do jego uzupełniania. W tym celu należy skopiować interesujące nas reguły z panelu ≪RULESET FOLDERS≫ lub ≪LIBRARIES≫.

Lista elementów modelu i ich klasyfikacja

Zacznijmy od zawartości modelu. Zakładając, że lista elementów ujęta w tabeli jest kompletna, można wykorzystać ją bezpośrednio do weryfikacji za pomocą reguły ≪09 Property Values Must Be from Agreed List≫[2]. Reguła ta pozwala sprawdzić, czy wybrane rodzaje komponentów posiadają określone wartości wskazanych parametrów (patrz: rysunek 4).

Rysunek 4. Panel definicji reguły “09 Property Values Must Be from Agreed List” (panel Ruleset manager)

Jak wspomnieliśmy wyżej – użytkownik może dostosować nazwę swojej reguły w taki sposób, aby była ona w pełni zrozumiała dla niego i jego współpracowników, w tym także odbiorców raportu. Służy do tego pole widoczne na samej górze okna, oznaczone na niebiesko na rysunku 4. Użytkownik może także dodać swój własny opis, w którym przykładowo zawrze dodatkowe informacje lub określi podstawę dla danej reguły – w tym celu należy wybrać polecenie ≪Edit≫, znajdujące się poniżej, w polu ≪Description≫.

Kolejnym istotnym krokiem jest wskazanie elementów, które mają być sprawdzone przez daną regułę. W tym celu można zdefiniować odpowiedni filtr wykorzystujący dowolny z istniejących w modelu parametrów lub skorzystać z mechanizmu ≪Reguł nadrzędnych≫ (z ang. ≪Gatekeeper rule≫[3]) – pozwala on zdefiniować regułę, która podzieli elementy na takie, które spełniają postawiony warunek oraz te, które go nie spełniają. Tylko grupa wskazana przez użytkownika będzie podlegać kolejnym (znajdującym się “głębiej” w strukturze) weryfikacjom (patrz opis na rysunku 5). W analizowanym przypadku reguły podrzędne będą sprawdzane jedynie dla elementów, dla których utworzona będzie uwaga. Dzięki temu kolejnym analizom będą podlegać jedynie elementy należące do wskazanego modelu i nie ma potrzeby definiowania zakresu elementów dla kolejnych reguł.

Rysunek 5. Zasada działania ≪Reguły nadrzędnej≫ (panel Ruleset manager)

Wracając do reguły sprawdzającej zgodność specyfikacji z nazewnictwem i klasyfikacją elementów: po wyborze elementów mających podlegać weryfikacji należy uzupełnić tabelę w polu ≪Allowed Property Values≫. W kolejnych kolumnach definiowane są (od lewej): klasy elementów – ≪Component≫, parametr – ≪Property≫ – oraz dopuszczalne jego wartości – ≪Allowed Value≫. Dla wszystkich komponentów, które spełnią dowolną ze zdefiniowanych kombinacji reguła nie zwróci błędu.

Sformułowanie “tabela” nie zostało użyte przypadkowo, bowiem możliwe jest zaimportowanie gotowych wartości z arkusza kalkulacyjnego. Warto skorzystać z tej możliwości nie tylko wtedy, gdy definiujemy wiele kombinacji element-parametr-wartość. Aby z niej skorzystać należy wybrać polecenie ≪Import Excel Worksheet≫. Proces wyboru danych do weryfikacji obejmuje 4 kroki:

1. Wybór skoroszytu programu Microsoft Excel,
2. Wybór arkusza ze skoroszytu,
3. Weryfikacja nagłówków importowanej tabeli,
4. Wybór wierszy, które powinny zostać zaimportowane.

Przewaga metody wykorzystującej arkusz kalkulacyjny leży nie tylko w szybkiej definicji danych do weryfikacji, ale także ich błyskawiczną aktualizację. Po wprowadzeniu korekt wystarczy jedynie wybrać polecenie ≪Update Imported Data≫, a wprowadzone dane zostaną zaktualizowane.

Efekt zastosowania reguły

Opracowaną regułę należy sprawdzić w praktyce, przechodząc do panelu ≪CHECKING≫ u góry okna programu. Jeśli reguła została już zapisana i była otworzona w projekcie, zmiany zostaną zaktualizowane automatycznie – nie ma potrzeby ponownego wyboru reguł (niezbędne jest jednak uruchomienie polecenia ≪Check Model≫.

Reguła ≪09 Property Values Must Be from Agreed List≫ zwróci uwagi w następujących przypadkach:

• gdy w modelu istnieje element o danej klasie, który nie posiada wskazanego parametru,
• gdy ww. element posiada parametr, ale jego wartość nie została wskazana jako dopuszczalna,
• gdy istnieje element o danych parametrach, ale nie jest on sklasyfikowany tak, jak wskazano w definicji reguły, np. gdy ≪Rura≫ nie została sklasyfikowana jako ≪Flow Segment≫.

Ta reguła pozwala nie tylko zweryfikować model, ale może być także pomocna przy aktualizacji specyfikacji modelu. Narzędzie to jest więc przydatne nie tylko dla weryfikatora modelu, ale także jego twórcy.

Parametry

Kolejna część specyfikacji obejmuje grupy parametrów, same parametry oraz ich wartości. Choć można skorzystać z poprzednio omawianej reguły, to w przypadku, gdy dla różnych elementów (nawet tak samo sklasyfikowanych) zestawy parametrów różnią się (jak ma to miejsce w przypadku ONBiB, co widać na rysunku 2), bardziej odpowiednia będzie reguła ≪203 Required Property Sets≫[4].

Podobnie jak w poprzednim przypadku pożądane wartości parametrów i ich zestawów mogą zostać wprowadzone “ręcznie” lub przy pomocy odpowiednio przygotowanego arkusza kalkulacyjnego. Tym razem jednak będzie on nieco bardziej złożony niż w przypadku poprzednio omawianej reguły. Zanim przejdziemy do arkusza warto zapoznać się z tym, jakie właściwości można zdefiniować “ręcznie”.

W pierwszej kolejności należy wybrać rodzaj elementu – w tym celu należy wykorzystać polecenie ≪Insert Row≫, znajdujące się w prawym górnym rogu panelu ≪Property Sets≫. Działanie skutkuje otwarciem okna, w którym wskazane są dyscypliny modelu oraz klasy elementów, jakie mogą mieć zastosowanie w danej dyscyplinie (patrz: rysunek 6).

Rysunek 6. Okno wyboru rodzaju elementu (klasy komponentu)

Po wykonaniu tej czynności w panelu ≪Property Sets≫ pojawi się pierwszy wiersz, który należy odpowiednio uzupełnić wskazując (patrz: rysunek 7):

• zestaw właściwości, czyli “Property set”, w którym powinien być zawarty wskazany w kolejnej kolumnie parametr,
• parametr, którego istnienie użytkownik chce zweryfikować,
• informacje, czy dany parametr:
  • musi być przypisany dla wskazanego elementu – wtedy wybieramy opcję: ≪Must exist≫,
  • nie może być przypisany do elementu – wtedy wybieramy opcję: ≪Must not exist≫,
  • może, ale nie musi, być przypisany do elementu – wtedy wybieramy opcję ≪Optional≫.
• warunek, który musi spełnić wybrany przez użytkownika parametr – ≪Value Conditions≫. W zależności od typu wartości parametru jest on definiowany jako:
  • wartość tekstowa – użytkownik wskazuje sposób zapisu parametru tekstowego, przy czym może wykorzystać znak ≪*≫, np. gdy wpiszemy ≪Winda*≫ wtedy wartości ≪Winda towarowa≫, ≪Winda osobowa≫ oraz ≪Winda≫ będą uznane za prawidłowe, a reguła nie zwróci błędu,
  • wartość logiczna: ≪prawda≫, ≪fałsz≫ lub ≪prawda lub fałsz≫ – może to dotyczyć np. parametru “Load bearing”,
  • wartość liczbowa, określana dla parametrów ilościowych: długości, powierzchni lub objętości, którą wykorzystamy, gdy chcemy sprawdzić np. czy szerokość drzwi mieści się w określonym zakresie,
  • data (użytkownik może wskazać dowolne zakresy dat wykorzystując typowe operatory: <, >, ≤, ≥, =),
  • wartość z określonego i skończonego katalogu wartości, np. gdy dopuszczamy w typie okna następujące wartości: ≪Rozwieralne≫, ≪Rozwieralno-uchylne≫, ≪Uchylne≫ lub ≪Nieotwierane≫,
  • ostatni warunek – ≪Visualize Only≫ – należy wybrać, gdy nie oczekujemy, że reguła zwróci błąd, ale chcemy, by spowodowała określony sposób wyświetlania elementów spełniających dany warunek.

Rysunek 7. Okno definicji warunku dla reguły ≪203 Required Property Sets≫

Wprowadzanie tego typu reguł jest oczywiście pracochłonne. Dużo korzystniejsze może okazać się skorzystanie z wartości ujętych w arkuszu kalkulacyjnym. Do jego opracowania można wykorzystać udostępniony przez Solibri szablon (link do szablonu znajduje się pod tym linkiem) – patrz też: rysunek 8.

Rysunek 8. Szablon do wprowadzenia danych dla reguły ≪203 Required Property Sets≫

Przy pomocy takich arkuszy można stosunkowo szybko opracować odpowiednie reguły dla danych zdefiniowanych jak pokazano na rysunku 2. Dla przykładu poniżej przedstawiono arkusz oparty o dane wskazane dla rur (patrz: Rysunek 9).

Rysunek 9. Przykład arkusza kalkulacyjnego definiującego warunki dla elementu wskazanego na rys. 2

Z powyższego arkusza możemy wywnioskować, że reguła może zwrócić błędy, gdy element sklasyfikowany jako ≪IfcFurnishingElement≫:

• w grupie parametrów ≪DCS_Ogolne≫:
  • nie będzie posiadał zdefiniowanego parametru ≪Nazwa≫ lub nazwa elementu będzie inna niż ≪Rura≫,
  • nie będzie posiadał zdefiniowanego parametru ≪Oznaczenie≫,
  • nie będzie posiadał zdefiniowanego parametru ≪Typ≫,
  • nie będzie posiadał zdefiniowanego parametru ≪Material≫,
  • nie będzie posiadał zdefiniowanego parametru ≪Pomieszczenie≫,
  • nie będzie posiadał zdefiniowanego parametru ≪Numer pomieszczenia≫,
  • nie będzie posiadał zdefiniowanego parametru ≪Szerokosc≫ lub jego wartość nie będzie liczbą podaną w metrach lub pochodnych (np. mm),
  • nie będzie posiadał zdefiniowanego parametru ≪Wysokosc≫lub jego wartość nie będzie liczbą podaną w metrach lub pochodnych (np. mm),
  • nie będzie posiadał zdefiniowanego parametru ≪Glebokosc≫lub jego wartość nie będzie liczbą podaną w metrach lub pochodnych (np. mm),
• w grupie parametrów ≪DCS_BMS≫ będzie posiadał dowolny z wymienionych parametrów: ≪Nazwa≫, ≪Protokol komunikacyjny≫, ≪Punkt integracji≫.

W przypadku, gdy dla danego rodzaju komponentu pożądane są różne zestawy właściwości (np. jak widać na rysunku 2: dla sklasyfikowanych jako ≪IfcFlowTreatmentDevice≫ układu oczyszczania i sterylizatora) zasadne jest odpowiednie odfiltrowanie elementów przez wypełnienie informacji w polu ≪Checked Components≫.

Wyniki

Gdy zakończymy definiowanie reguł weryfikacji nadchodzi moment ich przetestowania. W tym celu należy zapisać opracowany zestaw reguł (polecenie ≪Save Ruleset≫ w panelu ≪WORKSPACE≫), przejść do zakładki ≪CHECKING≫, wybrać polecenie ≪Add Ruleset≫, wybrać opracowany zestaw reguł i uruchomić proces weryfikacji poleceniem ≪Check model≫.

Ostatnim krokiem weryfikacji jest analiza uzyskanych wyników. Wbrew temu, co może się wydawać, każda ze zwróconych uwag powinna zostać przeanalizowana i odpowiednio sklasyfikowana poleceniem ≪Mark as Rejected≫ – gdy wymaga wprowadzenia korekty – lub ≪Mark as Accepted≫ – w przeciwnym wypadku. Dodatkowo osoba weryfikująca może utworzyć notatki do poszczególnych błędów i na tej podstawie wygenerować prezentację, którą można przekazać twórcy modelu w postaci pliku *.bcf, *.pdf lub w formacie programu Microsoft Excel. Bardziej efektywne wydaje się jednak przekazanie pliku programu Solibri Office, który odbiorca może otworzyć korzystając z bezpłatnej wersji tego narzędzia, czyli Solibri Anywhere.

Podsumowanie

Przedstawione powyżej reguły pokazują jedynie procent możliwości, jakie posiada Solibri Office. W zależności od tego, jak opiszemy wymagania względem modelu możemy skorzystać z innych reguł jego weryfikacji, predefiniowanych w programie. Musimy tylko pamiętać, że aby uzyskać rzetelne wyniki konieczne jest pochylenie się nad regułami i ich dostosowanie. Tak samo zresztą jest w programie do modelowania – zanim rozpoczniemy pracę przygotowujemy szablon projektu, ustalamy podstawowe parametry i dopiero przystępujemy do pracy. Pamiętajmy, że każdy algorytm jest tylko tak dobry, jak jego autor.

Karolina Wróbel

M.A.D. Engineers sp. z o.o.