Przygotowanie zamówienia na wykonanie modelu – wybrane aspekty techniczne: integracja z systemami do zarządzania

W poprzednim artykule z tej serii  wskazaliśmy, że podczas prac nad określeniem specyfikacji realizacji zamówienia konieczne jest uwzględnienie aspektów organizacyjnych, technicznych i formalnych oraz przedstawiliśmy wybrane aspekty należące do pierwszej z wymienionych grup zagadnień. Dzisiejszy tekst dedykowany jest kwestiom technicznym, w szczególności jednej, kluczowej dla powodzenia całego projektu, czyli integracji opracowanych przez wykonawcę modeli w systemach do zarządzania.

W tym miejscu warto przypomnieć, że do tego celu Muzeum będzie wykorzystywać dwa oddzielne systemy:

• do zarządzania w skali mikro (czyli w ujęciu pojedynczego obiektu – baraku znajdującego się na obszarze odcinka BI byłego KL Auschwitz II-Birkenau) – System Zarządzania Danymi BIM (SZD-BIM), który miał być dopiero wyspecyfikowany i uruchomiony w Muzeum,
• do zarządzania w skali makro (w kontekście całego obszaru Muzeum wraz ze znajdującymi się na nim obiektami) – System Zarządzania Danymi GIS (SZD-GIS).

Integracja z systemem GIS

Gdy M.A.D. Engineers rozpoczęło współpracę z Muzeum decyzja o wykorzystaniu w procesie zarządzania danymi GIS oprogramowania ArcGIS Pro była już podjęta. Naszym zadaniem pozostało określenie, w jaki sposób przeprowadzić proces integracji danych BIM do tego systemu. Podejmując decyzję kluczowe było osiągnięcie trzech celów:

• poprawny import geometrii elementów modeli do ArcGIS Pro,
• prawidłowy odczyt wprowadzonych do modeli danych oraz
• możliwość nałożenia tekstur na elementy wirtualnej makiety, czyli powstałego w ramach integracji produktu końcowego.

Na początek skupiliśmy się na przeanalizowaniu możliwości, którymi dysponuje ArcGIS Pro w kontekście odczytu danych BIM. W okresie prowadzenia omawianych analiz użytkownik tego narzędzia miał dwie opcje:

1. Skorzystać z plików w formacie IFC,
2. Użyć plików RVT, czyli jedynego formatu natywnego narzędzia BIM możliwego do odczytania przez ArcGIS Pro.

Druga z opcji od razu wydała się bardziej ryzykowna z dwóch powodów:

1. Z uwagi na brzmienie art. 99 ust. 4 Pzp:

“Przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję, w szczególności przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli mogłoby to doprowadzić do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów.”

Jeśli konieczne okazałoby się opracowanie plików modeli w formacie RVT, zapisy OPZ mogłyby zostać zaskarżone przez potencjalnych wykonawców, którzy zarzuciliby Muzeum ograniczenie konkurencji. Pracownicy działu prawnego Muzeum zwrócili jednak uwagę, że nie zawsze jest to zero-jedynkowe. Takie stanowisko można spotkać także w orzecznictwie, np. w wyroku KIO 2184/13:

“(…) uzasadnione potrzeby podmiotu zamawiającego mogą ograniczać krąg potencjalnych wykonawców oraz wpływać na zakres oferowanych przez nich usług, dostaw i robót budowlanych o ile wynikają one z celu, dla którego podmiot zamawiający wszczyna określone postępowanie, cel ten jest nakierowany na realizację tychże potrzeb i w żaden inny sposób nie może zostać osiągnięty (zasada proporcjonalności), zaś wymagania zamawiającego związane są z istotą przedmiotu zamówienia i jego indywidualnymi właściwościami pozwalającymi na osiągnięcie wskazanego wyżej celu.”

Należy jednak zwrócić uwagę na podkreślone elementy, z których wynika, że aby takie zapisy (w analizowanym przypadku: o wykorzystaniu konkretnego oprogramowania do wykonania modeli) mogły zostać ujęte w opisie przedmiotu zamówienia należałoby BEZSPRZECZNIE wykazać, że wynika to bezpośrednio z uzasadnionych potrzeb Muzeum oraz że w inny sposób NIE DA SIĘ osiągnąć zamierzonego celu. Technicznie istniała jednak inna możliwość – użycie formatu IFC.

2. Ze względów technicznych

Dodatkowo należy zwrócić uwagę na to, że integracja natywnych formatów w programach różnych producentów generuje powstanie także ryzyka w ujęciu technicznym. Nawet drobna zmiana w funkcjonowaniu programu A może przełożyć się na brak możliwości odczytu danych w narzędziu B. Błędy te można oczywiście naprawić w kolejnych wersjach programów, ale ich opracowanie zależne jest od wydawców. Może to zająć znaczną ilość czasu, w którym użytkownik może utracić możliwość wykorzystania pełnego potencjału narzędzi, którymi dysponuje.

Łatwo sobie także wyobrazić, że firma Autodesk zechce wejść na rynek GIS i opracuje własne oprogramowanie do obsługi tych zagadnień. W takiej sytuacji, z punktu widzenia biznesowego, utrzymanie przez Autodesk porozumienia o integracji z Esri mogłoby okazać się zbędne. Jego rozwiązanie mogłoby znacznie utrudnić dotychczasowym użytkownikom pracę przy przyjętych założeniach. Z tego punktu widzenia wykorzystanie formatów otwartych jest decyzją bezpieczniejszą w dłuższej perspektywie czasu (a przypomnijmy, że wykorzystanie modeli w ich cyklu życia – liczonym w kolejnych dziesiątkach lat – jest jednym z głównych celów Muzeum).

Trzeba jednak także uczciwie przyznać, że w odniesieniu do importu geometrii format natywny sprawdzał się nieco lepiej niż IFC. W przypadku plików RVT nie stwierdziliśmy, aby nawet oddająca wszelkie deformacje geometria stanowiła problem dla ArcGIS. W przypadku IFC tego typu błędy się pojawiały. Pogłębiona analiza w tym zakresie realizowana we współpracy z pracownikami Esri Polska skłoniła nas do wniosku, że przyczyną jest skomplikowany opis geometrii. Problem udało się zmarginalizować stosując dwa rozwiązania:

• wykorzystanie geometrii brep (boundary representation), która była dla ArcGIS Pro łatwiejsza w interpretacji oraz
• uproszczeniu geometrii modeli opracowanych w celu stworzenia wirtualnej makiety.

Należy podkreślić, że import danych niegeometrycznych do geobazy zarówno w przypadku formatu RVT, jak i IFC wymagał dodatkowej pracy polegającej na opracowaniu odpowiednich reguł transformacji. W tym miejscu ponownie należy zastanowić się nad tym, czy w przypadku wydania kolejnych wersji Autodesk Revit nie będzie konieczności ich modyfikacji. Wpływ takiego problemu w odniesieniu do formatu IFC był w zasadzie pomijalny.

W kontekście wirtualnej makiety dla Muzeum istotne było także oteksturowanie jej elementów. Niestety niezależnie od wybranego formatu (RVT, IFC2x3 czy IFC4, który teoretycznie może przenosić informacje o teksturze) i metody importu danych do geobazy – podjęte próby przyniosły jeden wniosek: konieczne jest nałożenie tekstur bezpośrednio w ArcGIS Pro. Nie jest to jednak program graficzny i brak mu narzędzi usprawniających realizację tego typu zadań. W związku z tym każdą teksturę należało nałożyć ręcznie. Naturalną konsekwencją powyższego wniosku było ograniczenie zakresu modelu, który miał zostać pokryty grafiką.

To nie był jednak koniec wyzwań związanych z teksturowaniem. Grafika nałożona na skomplikowaną, opisaną przez wiele trójkątów geometrię wyglądała jak odbicie w stłuczonym lustrze. Wyglądało na to, że prawidłowe oteksturowanie elementów wymagałoby przekształcenia grafiki z obrazu dwuwymiarowego na mapę trójwymiarową (tzw. UV mappingu). W związku z tym wraz z pracownikami Muzeum ponownie pochyliliśmy się nad Standardem BIM GPK oraz celami projektu. Wspólnie doszliśmy do wniosku, że do zarządzania w skali makro odzwierciedlenie deformacji pojedynczych elementów nie było kwestią kluczową. Rezygnacja z wymogu zapewnienia wysokiej dokładności geometrycznej była:

• uzasadniona z punktu widzenia celów powstania wirtualnej makiety,
• korzystna ze względu na ograniczenie czasochłonności opracowania wirtualnej makiety – umożliwiła jej sprawniejsze wykonanie i w efekcie – szybsze uruchomienie w pełni nasyconego pożądanymi danymi systemu do zarządzania w skali makro,
• pożądana ze względu na uproszczenie realizacji zadania polegającego na oteksturowaniu elementów wirtualnej makiety.

Pozostając w temacie dokładności modeli, lecz w szerszym zakresie, należy zaznaczyć, że Muzeum w chwili ogłaszania postępowania nie dysponowało szczegółowymi inwentaryzacjami wszystkich baraków znajdujących się na obszarze byłego KL Auschwitz II – Birkenau. Te wykonywane są systematycznie w miarę postępów prac konserwatorskich podejmowanych w ramach Globalnego Programu Konserwacji. Pod znakiem zapytania stało więc, czy możliwe będzie wykonanie wirtualnej makiety w całości w okresie objętym umową z przyszłym wykonawcą?

Można było oczywiście powierzyć wykonanie inwentaryzacji przyszłemu wykonawcy, ale – z uwagi na liczbę obiektów (45) – wiązałoby się to ze znacznym podniesieniem kosztów i wydłużeniem czasu potrzebnego na realizację zamówienia. Patrząc jednak na kompleks baraków murowanych mających być przedmiotem umowy z szerszej perspektywy okazało się, że większość baraków wzniesiono na podstawie tego samego projektu. To pozwoliło, pomijając szczegóły nieistotne z punktu widzenia skali makro, sprowadzić listę obiektów, za pomocą których można odzwierciedlić obszar odcinka BI Muzeum, do 6 unikatowych typów. W ten sposób zostały wskazane modele, które można było uznać za wzorcowe dla pozostałych.

Można by pomyśleć, że w takiej sytuacji, aby sporządzić wirtualną makietę wystarczy jedynie powielić modele wzorcowe odpowiednią liczbę razy i prawidłowo umiejscowić w geobazie. O ile jednak część różnic można było pominąć (np. przesunięcie ściany wewnętrznej o kilka centymetrów) to niektóre miały istotne znaczenie dla Zamawiającego (np. brak określonych elementów więźby dachowej czy różnice w rozkładzie wnętrz). To powodowało, że elementem OPZ musiało stać się opracowanie wskazujące przyszłemu wykonawcy granicę, gdzie kończą się różnice nieistotne, a gdzie zaczynają te, które powinny być widoczne w modelach poszczególnych baraków. Dysponując takimi wytycznymi wykonując kolejne modele (w OPZ funkcjonujące pod nazwą modeli baraków analogicznych) na podstawie modelu baraku wzorcowego wykonawca musiał:

• Zidentyfikować wszystkie różnice między barakiem wzorcowym a analogicznym,
• Ocenić, po której stronie wyznaczonej granicy znajduje się zidentyfikowana różnica,
• Jeśli różnica powinna być ujęta w modelu – odpowiednio skorygować model baraku analogicznego.

Stosując powyższą procedurę czas potrzebny na opracowanie modeli wszystkich baraków znacznie się skrócił.

W tym miejscu warto na chwilę przenieść się do teraźniejszości. Choć M.A.D. Engineers nie brał czynnego udziału w procesie opracowania wirtualnej makiety, ona sama stanowiła jedynie jeden z elementów szeroko zakrojonego wdrożenia GIS w Muzeum a sam proces nadal trwa – jako współautor wymagań w tym zakresie – byliśmy ciekawi, jaki efekt udało się uzyskać. Dzięki uprzejmości Muzeum, możemy pokazać efekty podjętych już działań i skonfrontować je z założeniami przedstawionymi w wynikach projektu pilotażowego, które przytaczaliśmy na początku tego tekstu.

Patrząc na kryteria jesteśmy skłonni stwierdzić, że udało się osiągnąć oczekiwany efekt, ale ocenę pozostawiamy Wam – czytelnikom – oraz przede wszystkim pracownikom Muzeum. Tymczasem wracając do głównego wątku…

Modele uproszczone opracowane w celu stworzenia wirtualnej makiety mogły zostać wykorzystane także w systemie do zarządzania w skali mikro. Bo choć założyliśmy, że geometria tych modeli będzie dokładna, to mając wybór między włączeniem do systemu jedynie opracowań o wysokiej szczegółowości (co obrazuje zawartość niebieskiej ramki na schemacie poniżej), a możliwością zobrazowania całego kompleksu (żółta ramka) mogła być tylko jedna odpowiedź: należy skorzystać z tej możliwości.

Integracja z systemem BIM

Aby uwypuklić to wyzwanie należy przypomnieć, że system do zarządzania w skali mikro ma być nasycany dodatkowymi informacjami o poszczególnych komponentach i modelach, a dane, których nie sposób przełożyć na atrybuty (np. dokumentacja fotograficzna czy konserwatorska) powinny być z nimi bezpośrednio powiązane. W taki sposób powstanie sieć powiązań komponent↔plik/informacja. Patrząc na konieczność aktualizacji modelu, wynikającą z przejścia systemu ze stanu tymczasowego do docelowego (patrz: różowa ramka) musieliśmy odpowiedzieć sobie na następujące pytanie: skąd system ma “wiedzieć”, że jakiś komponent, który system już “zna”, obrazuje ten sam element choć jego geometria może być zupełnie inna niż w istniejącym modelu?

Na szczęście problem ten już dawno został rozwiązany w bardzo prosty sposób. Wystarczy zapewnić niezmienność w czasie jednej informacji o elemencie, która będzie wykorzystywana do jego identyfikacji. W przypadku modeli zapisanych w schemacie IFC jest to Globall Unique Identifier (GUID) – oznaczenie, które programy do modelowania przypisują elementom w momencie eksportu i utrzymują, aby umożliwić użytkownikom analizę zmian wprowadzonych między kolejnymi wydaniami modelu.

Wynikiem tej analizy w przypadku modelu zaimplementowanego do systemu do zarządzania w skali mikro będzie działanie jak opisano w poniższej tabeli.

W związku z tym, że kwestia GUID tak istotnie wpływa na funkcjonowanie planowanych do uruchomienia systemów, musiała ona znaleźć swoje odzwierciedlenie w dokumentacji postępowania przetargowego. Przyszły wykonawca miał zobowiązać się do zapewnienia niezmienności numerów identyfikacyjnych od pierwszego wydania danego modelu, niezależnie od stanu baraku, który odzwierciedlają (przed czy po przeprowadzeniu prac konserwatorskich).

Podsumowanie

Opisane wyżej zagadnienia techniczne były tylko jednymi z wielu, nad którymi musieliśmy się pochylić wraz z pracownikami Muzeum. Dużo niewiadomych, jeszcze więcej możliwych ścieżek do zbadania i ciężar odpowiedzialności za podjęte decyzje i wydane rekomendacje (które – na szczęście – z perspektywy czasu, okazały się słuszne) sprawiają, że “Projekt wykorzystania technologii BIM w cyklu funkcjonowania obiektów zlokalizowanych na obszarze byłego KL Auschwitz II-Birkenau na terenie Państwowego Muzeum Auschwitz-Birkenau w Oświęcimiu” w oczach zespołu M.A.D. Engineers z każdym tygodniem zyskiwał kolejne gwiazdki na skali wyzwań. O innych opowiemy w kolejnym artykule z tej serii.

Karolina Wróbel
M.A.D. Engineers