baklofen i abilify €56.72
27 wrz 2022

Zmiany: na rysunku chmurka, a co w modelu?

To, że w projekcie pojawiają się zmiany

27 wrz 2022

To, że w projekcie pojawiają się zmiany chyba nie dziwi nikogo. Wynikają one z różnych czynników: poprawy własnych błędów, nowych pomysłów inwestorów oraz optymalizacji wykonywanej przez wykonawców robót. Aby móc się w tym wszystkim orientować, wszelkie zmiany są oznaczane na dokumentacji rysunkowej, katalogowane i opisywane. Co jednak z modelem? Kwestia ta do dzisiaj jest dla mnie otwarta, bo i metod jest co najmniej kilka.

Oczywiście nie zaryzykuję stwierdzenia, że przedstawione poniżej sposoby oznaczania zmian w modelach stanowią zamkniętą i skończoną listę możliwości lub są najlepsze. Przytoczę takie, które analizowaliśmy w związku z uczestnictwem w inwestycji dot. budowy Ośrodka Narciarstwa Biegowego i Biathlonu, którego Inwestorem jest Dolnośląski Park Innowacji i Nauki i którego realizację nadzoruje konsorcjum firm Miastoprojekt Wrocław i ETC Architekci (projektant główny).

Oznaczmy zmiany jak na rysunku!

Na rysunkach wszelkie zmiany zwyczajowo są oznaczone chmurkami oraz listą zmian w obszarze przeznaczonym na tabelkę rysunkową. I to było inspiracją dla pierwszego z pomysłów, jaki analizowaliśmy wraz z projektantami. Koncepcja polegała na tym, aby skorzystać z uzgodnionego dla dokumentacji systemu oznaczania rewizji kolejnymi literami alfabetu (pierwsze wydanie – rewizja A, drugie – B itd.), ale w odniesieniu do konkretnego, zmienianego komponentu modelu – symulując oznaczenie chmurką poprzez dodanie parametru z numerem rewizji. Potencjalnie pozwoliłoby to także na powiązanie rewizji rysunkowych z tymi występującymi w modelach. Zmiany można wtedy pokazać np. tak, jak wskazano na rysunku 1 – przy pomocy funkcji “Smart views” w BIMcollab ZOOM.

Rysunek 1. Oznaczenia elementów według wartości parametru “Rewizja” w BIMcollab ZOOM (opracowanie modelu: M.A.D. Engineers)

Przy tym podejściu pojawiają się jednak dodatkowe pytania. Pierwsze z nich dotyczy tego, jak opisać parametry odnoszące się do rewizji (rysunek 2):

  • ująć w modelu tylko oznaczenie rewizji, co nie byłoby zbyt pracochłonne i prowadzić zewnętrzną listę zmian (wersja 1 na rysunku poniżej),
  • czy też zmiany opisywać w formie wartości parametru (jak w wersji 2), co pozwoliłoby na wygenerowanie listy zmian bezpośrednio z modelu?

Rysunek 2. Parametry dot. rewizji w modelach (źródło: M.A.D. Engineers)

Niezależnie od sposobu opisu parametrów metoda ta jest obarczona ryzykiem. Bo wyobraźmy sobie, co się stanie, jeśli zapomnimy uzupełnić te parametry (np. element został zmieniony w ramach danej rewizji, ale właściwości nie będą na to wskazywać) lub przez pomyłkę zmienimy właściwości elementu, który nie powinien być objęty daną rewizją. Taka sytuacja potencjalnie generuje dużą ilość zapytań o informację, a ich procedowanie trwa, co może odbić się na terminie realizacji oraz zaufaniu do danych zawartych w modelach.

Drugie pytanie dotyczy tego, jak poradzić sobie z numerowaniem rewizji bo prawdą jest, że w przypadku zmiany kolejny numer otrzymuje jeden rysunek, a nie cały ich pakiet (np. dotyczący danej branży). Dodatkowo nie każda zmiana musi mieć swoje odzwierciedlenie w modelu a rewizja modelu niekoniecznie musi pociągać za sobą korektę rysunku. Analizując możliwe sytuacje można je podsumować w następujący sposób:

  • zmiana w dokumentacji nie wpływa na model (m.in. uzupełnienie opisu, korekta dokumentacji opracowanej jedynie w postaci 2D, np. detalu);
  • zmiana w dokumentacji wpływa na model (m.in. korekta tras instalacji, zmiana wyposażenia lub materiałów);
  • zmiana w modelu nie wpływa na dokumentację (m.in. korektę w zakresie eksportowanych właściwości, usunięcie kolizji nie widocznych na rysunkach)

W takich sytuacjach bardzo łatwo dopuścić do sytuacji, gdy numeracja zacznie się “rozjeżdżać” – oznaczenia modeli “wyprzedzą” oznaczenia na rysunkach (rysunek 3), a powiązanie określonej korekty modelu z tą widoczną na rysunku staje się bardzo trudne, jeśli nie niemożliwe.

Rysunek 3. Zmiany oznaczeń rewizji na rysunkach i w modelu przy każdorazowym wpływie korekty na model – na szaro oznaczono elementy dokumentacji, które nie ulegają zmianie (źródło: opracowanie własne)

Można oczywiście potraktować zmiany w modelu jako te nadrzędne i utrzymać oznaczenia z modelu na rysunku, jak pokazano na rysunku 4 – rysunki otrzymują numer rewizji adekwatny do odpowiadającej mu wersji modelu – niezależnie od tego, jak oznaczona była poprzednia wersja. Taki system w dużej (jeśli nie przeważającej) części przypadków, powodowałby powstanie „luk” na liście rewizji poszczególnych rysunków. Nie dość, że byłoby to mało intuicyjne dla projektantów dodatkowo mogłoby generować dużą ilość zapytań z budowy, która próbowałaby dociec, czy na pewno otrzymali całość dokumentacji i czy nie nastąpiły jakieś omyłki. Działania te – choć w pełni zrozumiałe – stanowiłyby spore obciążenie, zarówno dla administracji budowy, jak i zespołu projektowego, wymuszając zwiększenie ich zaangażowania w proces zarządzania dokumentacją, co nie leży w interesie żadnej ze stron.

Rysunek 4. Zmiany oznaczeń rewizji na rysunkach i w modelu przy utrzymaniu oznaczeń zmian modelu jako nadrzędnych – na szaro oznaczono elementy dokumentacji, które nie ulegają zmianie (źródło: opracowanie własne)

Na uwagę zasługuje także przypadek zmiany rysunkowej, która nie generuje konieczności wprowadzenia korekty w modelu. Aby zachować spójność z przyjętym systemem należałoby mimo to wydać również rewizję modelu. To także powodowałoby konieczność wykonania dodatkowej pracy – tym razem po stronie Managera BIM – który musiałby dokonać analizy zawartości modelu oraz potwierdzenia, że nadal jest ona spójna z modelem realizacyjnym opracowywanym przez wykonawcę robót.

Rysunki swoje, a model swoje (niestety)

Jak widać – choć dokumentacja płaska w większości jest opracowaniem wtórnym względem modelu (powstaje na jego podstawie) – to uwspólnienie oznaczeń zmian dla modeli i rysunków w ramach wydanej dokumentacji projektowej nie jest zadaniem łatwym. Korekty w modelu trzeba  jednak jakoś opisywać, aby wykonawca wiedział, że ma do czynienia z kolejną jego wersją.

Po przemyśleniach doszliśmy do wniosku, że powinniśmy odejść od oznaczeń literowych – aby wyraźnie zaznaczyć, że rewizja E modelu niekoniecznie odpowiada rewizji E określonego rysunku. Wybór padł na oznaczenia cyfrowe (arabskie). Rozwinęliśmy więc zastosowany w ramach etapu projektowania system nazewnictwa modeli o pole dotyczące rewizji.

Założyliśmy najbardziej pesymistyczny scenariusz, w którym każda potencjalna zmiana mogła nieść za sobą korektę modelu, a że zmian było  dużo – stąd stosowanie aż 3 znaków. Dodatkowo, aby ułatwić powiązanie zmian w modelu ze zmianami w dokumentacji, do nazwy modelu dodaliśmy datę wydania – wystarczy jedynie odnaleźć w spisie dokumentacji rewizję z tożsamą do modelu datą (patrz: rysunek 5).

Rysunek 5. Powiązanie oznaczeń zmian w modelach oraz na rysunkach (źródło: opracowanie własne)

Czy to jest jednak potrzebne?

Mając model BIM oraz odpowiednie narzędzia można względnie bezproblemowo wykazać, co w projekcie się zmieniło. Można do tego wykorzystać narzędzia do projektowania (bodaj wszystkie wiodące oprogramowania posiadają funkcjonalność pozwalającą na porównanie zawartości ilościowej i jakościowej analizowanych plików) lub przeglądarki plików IFC, np. BIM Vision (i modułu “Zmiany”). W takiej sytuacji sprawdzenie, czy coś się zmieniło zajmuje tylko chwilę – wystarczy jedynie otworzyć oba pliki (“stary” i “nowy” – ze zmianami), a program po kilku kliknięciach wykona za nas całą analizę. Jej wyniki mogą wyglądać na przykład tak, jak na rysunku 6 poniżej.

Rysunek 6. Porównanie modelu zagospodarowania placu budowy – widok z przeglądarki BIM Vision (opracowanie modeli: konsorcjum firm: Porr – lider, Elektromontaż Rzeszów oraz Akme Zdzisław Wiśniewski – partnerzy)

Na podstawie danych w obu plikach BIM Vision porównuje ich zawartość i – jeśli znajdzie różnice – klasyfikuje je do odpowiedniej kategorii, co wizualnie jest sygnalizowane określonym kolorem. Nie jest to może rozwiązanie idealne, bo jednego elementu może dotyczyć wiele rodzajów zmian, ale na pewno daje szybki ogląd na to, czy i jak dużo się zmieniło. I tak na podstawie powyższego rysunku możemy stwierdzić m.in., że zmieniły się właściwości dwóch żurawi wieżowych, a ostatni został już zdemontowany.

Oczywiście taka informacja bywa niewystarczająca – wiemy jedynie, że coś w zakresie parametrów się zmieniło, ale nie wiemy, co konkretnie. W takiej sytuacji możemy ręcznie sprawdzić właściwości poszczególnych elementów, jednak istnieje możliwość, że nie dostaniemy odpowiedzi na postawione pytanie. Dwa wybrane elementy wydają się przecież identyczne (patrz: rysunek 7).

Rysunek 7. Porównanie danych dla elementu (opracowanie modeli: konsorcjum firm: Porr – lider, Elektromontaż Rzeszów oraz Akme Zdzisław Wiśniewski – partnerzy)

Zmian należy więc poszukać głębiej i warto do tego zaprząc bardziej zaawansowane funkcjonalności, np. wtyczkę Compare do BIM Vision. Dzięki automatyzacji możemy śledzić zmiany element po elemencie, a wszystkie zostaną nam wyraźnie wskazane i opisane, jak pokazano na rysunku 8.

Rysunek 8. Porównanie danych dla elementu przy zastosowaniu Compare – wtyczki do BIM Vision (opracowanie modeli: konsorcjum firm: Porr – lider, Elektromontaż Rzeszów oraz Akme Zdzisław Wiśniewski – partnerzy)

Jak możemy zauważyć: w samym analizowanym komponencie faktycznie nie było zmian, ale klasy nadrzędne (IfcProject i IfcStorey) mają inne wartości. W takim przypadku, w związku z relacjami między elementami modelu oraz dziedziczeniem właściwości to również stanowi zmianę analizowanego komponentu.

Po skorygowaniu modelu w tym zakresie (ujednoliceniu właściwości dla IfcProject i IfcStorey) zmian jest widocznie mniej (patrz rysunek 9).

Rysunek 9. Porównanie wersji modelu po skorygowaniu danych dla IfcProject i IfcStorey (opracowanie modeli: konsorcjum firm: Porr – lider, Elektromontaż Rzeszów oraz Akme Zdzisław Wiśniewski – partnerzy, M.A.D. Engineers (w zakresie opisanych korekt)

Tym razem zmiana – przynajmniej dla wskazanego na rysunku 10 elementu – jest widoczna na pierwszy rzut oka i dotyczy ilości danych przypisanych do elementu

Rysunek 10. Porównanie danych dla elementu po usunięciu zmian wynikających ze zmienionych wartości IfcProject i IfcStorey (źródło modeli: konsorcjum firm: Porr – lider, Elektromontaż Rzeszów oraz Akme Zdzisław Wiśniewski – partnerzy, M.A.D. Engineers (w zakresie opisanych korekt)

Jak widać na powyższym przykładzie, aby wyniki identyfikacji zmian realnie odzwierciedlały wprowadzone w projekcie korekty, musi zostać spełniony szereg warunków, z których najważniejsze to:

  • zachowanie odpowiedniej “higieny modelowania” – przede wszystkim modyfikowanie jedynie tego, co faktycznie chcemy zmienić,
  • wykonanie eksportu modelu (jeśli wykorzystujemy pliki IFC) przy zachowaniu tych samych globally unique identifier (guid) dla elementów oraz tych samych ustawień eksportu.

Niestety – jak pokazuje praktyka – zadanie to bywa trudniejsze, niż może się wydawać. Niemniej warto podjąć ten wysiłek w imię ułatwienia pracy nie tylko sobie, ale też pozostałym członkom zespołu i usprawnienia procesu zarządzania zmianami.

A może CDE?

Znaczna część rozwiązań wpisujących się w ideę CDE posiada funkcjonalność pozwalającą opisać przechowywane dane dodatkowymi informacjami – metadanymi. Wśród nich PN-EN ISO 19650-1 bezpośrednio wymienia właśnie rewizję. Mechanizm jej oznaczania może być różny w zależności od narzędzia, ale sporo z nich może dokonać automatycznej numeracji kolejnych wersji danego pliku – taką funkcjonalność posiada narzędzie stosowane w ramach budowy ONBiB (ePMflow). To, co w jakiś sposób wyróżnia to narzędzie to możliwość podjęcia decyzji o randze danej zmiany (np. czy jest ona istotna z punktu widzenia określonych kryteriów, czy też nie). Te mniej ważne można oznaczać tzw. „małą rewizją”, a te istotniejsze – „dużą”. Dodatkowo, aby ułatwić innym członkom zespołu pracę, warto rozważyć wkazanie także dodatkowych informacji, którymi możemy opisać poszczególne pliki przechowywane w CDE, np. takich, jak te wskazane na rysunku 11.

Rysunek 11. Porównanie danych dla elementu po usunięciu zmian wynikających ze zmienionych wartości IfcProject i IfcStorey (źródło modeli: konsorcjum firm: Porr – lider, Elektromontaż Rzeszów oraz Akme Zdzisław Wiśniewski – partnerzy, M.A.D. Engineers (w zakresie opisanych korekt)

Taki system nie dość, że jest odporny na błędy ludzkie (nikt nie pomyli numeru rewizji – może pomylić jedynie dostarczany plik) to wprowadzanie wspomnianych wyżej informacji, wraz z tymi, które typowo opisują dane przechowywane w CDE, może posłużyć do generowania odpowiednich spisów. Na tym polu istnieje więc potencjał na kolejną optymalizację procesu zarządzania dokumentacją

Podsumowanie

Nie pokuszę się o stwierdzenie, że powyższa lista metod jest pełna, ani że któryś z przedstawionych sposobów jest tym, który można nazwać mianem najlepszego, bowiem wszystkie mają swoje wady i zalety. To, który system stanie się obowiązującym dla projektu stanowi wypadkową co najmniej kilku czynników. Do najistotniejszych zaliczyłabym możliwości stosowanych narzędzi, preferencje członków zespołu oraz ich kompetencje i potrzeby. Najważniejsze jest to, aby na projekcie panował porządek a proces zarzadzania zmianami przebiegał – oczywiście w miarę możliwości – sprawnie. To jest cel, który powinien nam przyświecać, gdy przyjdzie nam dokonać wyboru. Bo to, że zmiany się pojawią należy uznać za pewnik. Tego chyba nie zmieni żadna nowość technologiczna.

 

Karolina Wróbel

M.A.D. Engineers

Leave a comment
More Posts
Comments
Comment