Idea budowania bezpośrednio przy użyciu modeli stale rośnie, a coraz więcej projektów przyjmuje takie podejście. Jakiś czas temu pisałem o tym, czego wymaga się od takiego procesu oraz o jego korzyściach i wyzwaniach. Jednym z najważniejszych tematów, które się pojawiają, jest konfiguracja stabilnych i płynnych procesów oraz obiegu oprogramowania.
W tym wpisie chciałbym skupić się na ogólnej konfiguracji oprogramowania, na przykładzie projektu, w który jestem zaangażowany, Nowego Szpitala Uniwerysteckiego w Stavanger. Jakiego oprogramowania używamy w każdej fazie projektu? Jaki jest przepływ danych? Odpowiedz na te i inne pytania poniżej.
Spis treści
Cele cyfryzacji
Aby omówić konfigurację, musimy najpierw powrócić do celów cyfryzacji projektu. Rolą zespołu zarządzającego budową było udoskonalenie technologii projektu, aby spełnić wymagania klienta i umożliwić budowanie w oparciu o modele. Moglibyśmy podzielić je na trzy kategorie:
- Wyeliminowanie tworzenia tradycyjnych rysunków i opracowanie modeli, które można wykorzystać jako dokumentację budowlaną.
Mówiąc najprościej, jest to rezygnacja z rysunków i zastosowanie jedynie modeli. Chociaż rzeczywistość nie jest taka prosta. Musieliśmy skonfigurować cały plac budowy oraz zamówić i zdefiniować obieg oprogramowania, który mógłby być używany bezpośrednio na miejscu przez pracowników.
Projekt musiał zdefiniować wymagania informacyjne dla modeli i odpowiednio zasilić je danymi potrzebnymi pracownikom i geodetom do wykonywania czynności i pomiarów na miejscu. - Współpraca między zainteresowanymi stronami powinna zostać cyfrowa niezależnie od fazy projektu i lokalizacji personelu.
Wymagało to utworzenia opartego na chmurze centrum zarządzania projektami i współpracy dla wszystkich interesariuszy projektu (zamawiającego, projektantów, wykonawców, dostawców i użytkowników końcowych). Niemniej jednak, nie chodzi tylko o narzędzie – zupełnie inną historią jest ustanowienie i śledzenie procesów zarządzania zadaniami i komunikacji w organizacji dla ponad 300 pracowników biurowych. - Każda informacja musi być przechowywana tylko w jednym miejscu i skutecznie zarządzana poprzez cyfrową współpracę.
Nietrywialne. W branży AEC jesteśmy przyzwyczajeni do tworzenia arkuszy kalkulacyjnych, rejestrów i matryc. Eksportujemy dane z jednego źródła, rozwijamy je i używamy tak długo, jak są odpowiednie, a następnie odchodzimy. Albo zarządzamy wieloma równoległymi rejestrami. Wiesz, o czym mówię? Projektanci pomieszczeń mają swoje rejestry pomieszczeń, architekci swoje, a inżynierowie MEP swoje. Dane są powielane i zmieniane, a początkowo te same rejestry coraz bardziej oddalają się od siebie.
Ten wymóg kładzie temu kres. Każda informacja ma mieć tylko jedno miejsce, które jest nadrzędne dla danych i może zasilać inne źródła, które są nadrzędne dla innych danych. Innymi słowy, tworzymy ogromną relacyjną bazę danych z połączonymi tabelami. A ponieważ żadne oprogramowanie nie może zrobić wszystkiego, musimy wcześniej zdecydować o przepływie pracy i o tym, który program zarządza danym typem danych.
Podsumowując, wymóg ten stwarza możliwości – oszczędzamy czas, nie przechowując tych samych informacji w wielu miejscach. Z drugiej strony projekt musi ustanowić nowe przepływy pracy i procesy wymiany danych oraz ponownie ocenić ugruntowane procedury projektowania i komunikacji.
Oprogramowanie na różnych etapach projektu
Konfigurując przepływ pracy, musieliśmy wziąć pod uwagę, że wykorzystanie konkretnego oprogramowania zmienia się w trakcie cyklu życia projektu. Ostatecznie wybraliśmy zestaw narzędzi, które dobrze ze sobą współpracowały jako technologiczny trzon.
Od tego momentu dodaliśmy kilka programów, które wspierały określone zadania (np. zarządzanie drzwiami, obliczenia akustyczne), a głównym wymaganiem było, aby mogły one współpracować z pakietem, którego już używamy.
Setting up workflow, we had to take into consideration that the particular software use is changing through the project lifecycle. In the end, we have chosen a set of tools that worked OK with each other as a backbone.
From that point, we added some programs that supported given tasks (e.g. door management, acoustic calculations) and the prime requirement was that they could cooperate with the bundle we already use.
Cele właściwości
Zanim przejdziemy do opisu, które oprogramowanie robiło co i jak są one połączone, wróćmy jeszcze raz do właściwości obiektów.
W każdym projekcie tworzymy, modelujemy i zarządzamy właściwościami dla różnych celów projektu. Następnie definiuje to, które dane gdzie przepływają i jak oprogramowanie współpracuje. Podzieliłbym je w następujący sposób:
- Dane wejściowe projektu – dane określające wymagania dla projektu. Projektanci potrzebują ich do rozpoczęcia i kontynuowania procesu modelowania. Przepływa jako dane wejściowe do oprogramowania do modelowania. Przykładowe właściwości:
- Działy
- Zaprogramowany obszar
- Ilość świeżego powietrza
- Wymagania dotyczące systemów bezpieczeństwa
- Projekt – właściwości muszą być wymieniane między zespołami projektowymi. Inżynierowie MEP potrzebują informacji od inżynierów budowlanych, a ci potrzebują ich od architektów. I na odwrót. Przykłady:
- Siatka słupów
- Zaprojektowane granice pomieszczeń
- Rodzaje ścian
- Wysokość sufitu
- Współpraca i zarządzanie projektem – informacje umożliwiające zarządzanie projektem i współpracę między interesariuszami odpowiedzialnymi za różne dostawy – planowanie, zadania, kontrola, testowanie itp.
- Obszar kontrolny – aby wiedzieć, do jakiego miejsca się odnosimy
- Odpowiedzialność – aby wiedzieć, do kogo się odnosimy.
- Model Maturity Index / LOD
- Budowa – właściwości potrzebne wykonawcom do wykonywania pracy na miejscu przy użyciu modeli. Przykłady:
- Harmonogramy drzwi
- Wymiary rur
- Typ zasilania, napięcie
- Przekazanie – informacje dla użytkownika końcowego, aby mógł zarządzać obiektem. Menedżerowie muszą wiedzieć, co zostało ostatecznie zainstalowane na placu budowy, jak go obsługiwać i jakie są procedury konserwacji. Dane te są często zarówno plikami PDF, jak i właściwościami produktu wprowadzanymi do bazy danych obiektów. Przykłady:
- Instrukcje obsługi produktów
- Protokoły testów działania
- Warunki gwarancji
Dzięki zrozumieniu tych celów możemy zarządzać obiegiem informacji pomiędzy różnymi programami. Inny zestaw danych powinien być wymieniany, gdy wysyłamy projekt między stronami, inny w przypadku budowy, a jeszcze inny, gdy przygotowujemy się do przekazania do zarządzania obiektem. Idzie to w parze z celami eksportu IFC, ale wykracza poza to – wiele danych jest wymienianych z wykorzystaniem baz danych lub wewnątrz jednego oprogramowania, ale w różnych zespołach.
Przepływ pracy między oprogramowaniem
Dane wejściowe do projektu
Projektowanie
Następnie pojawili się projektanci i rozpoczęli pracę w programach Revit i Tekla. Zbierają odpowiednie dane z bazy danych dRofus, aby odpowiedzieć na wymagania.
W każdy piątek odbywa się automatyczny eksport IFC dla wszystkich modeli, a w weekend każda platforma jest zasilana świeżymi modelami.
Modele są scalane w Solibri. W procesie projektowania zespół używa go do zapewnienia jakości i wykrywania kolizji, kontroli danych i odbioru informacji. Zarówno wewnątrz zespołu projektowego, jak i do komunikacji z właścicielem budynku.
Zespół projektowy wykorzystuje serwer BCF o nazwie BIM Track (obecnie Newforma Connect) do wewnętrznego zarządzania zagadnieniami.
Współpraca
Do zarządzania kwestiami poza zespołem projektowym używamy platformy Pims, która jest głównym centrum projektu, a każdy interesariusz projektu jest umownie zobowiązany do korzystania z tego oprogramowania jako platformy do komunikacji i zarządzania zadaniami.
Pims jest naszym głównym narzędziem do współpracy i przechowywania danych. Jest to w zasadzie ogromna baza danych z różnymi modułami, które można ze sobą łączyć. Pochodzi z przemysłu naftowego i został dostosowany do potrzeb rynku budowlanego. Projekt wykorzystuje go jako:
- CDE
- Zarządzanie zagadnieniami i współpraca
- Repozytorium dokumentów M&O (konserwacja i eksploatacja)
- Listy kontrolne kontroli jakości dla wykonawców
- Repozytorium danych modelu (importujemy wszystkie IFC do ich bazy danych, a oni mogą wyodrębnić czyste dane z właściwości)
- Plan działań i rejestr dla pracowników na miejscu (przy użyciu „wagonów” z zasad Lean)
- Spotkanie z harmonogramem – cyfrowa tablica z codziennymi zadaniami dla każdego zespołu budowlanego
- I więcej
Korzystanie z jednego oprogramowania do tak wielu zadań ma zarówno zalety, jak i wady. Z jednej strony trzeba nauczyć się tylko jednego programu, a wszystkie moduły działają podobnie. Z drugiej strony – wiele modułów jest lepiej rozwiązanych przez oddzielne platformy. Plus jeśli wszystko ma iść na Pims, to każde oprogramowanie powinno z nimi współpracować. I tutaj pojawia się duży problem po obu stronach – producenci oprogramowania niekoniecznie chcą ze sobą współpracować, co wpływa na przepływ pracy w projekcie.
Budowa
Jako oprogramowanie na plac budowy zdecydowaliśmy się na StreamBIM, ponieważ było to wówczas najlepsze rozwiązanie na rynku. Co skłoniło nas do podjęcia takiej decyzji?
- Dedykowana aplikacja na ekrany dotykowe – obecnie ma je każdy pracownik
- Sprawne wymiarowanie i możliwość dodawania adnotacji do elementów
- Prostota nawigacji i łatwy podgląd rzutu kondygnacji
- Łatwość tworzenia przekrojów.
Przepływ pracy na placu budowy i łączenie harmonogramów z modelami wygląda następująco:
- Z Pims pliki IFC są wysyłane do StreamBIM w każdy poniedziałek
- Harmonogramy są tworzone w Safran Project, które są również łączone z danymi z Pims w jeden rejestr działań dostępny dla kierowników budowy i brygadzistów.
- Łączymy modele IFC z harmonogramami w Synchro do wizualizacji harmonogramów, tzw. 4D. Szczerze mówiąc, nie korzystaliśmy z tej funkcji zbyt często.
W projekcie używamy BIM kiosków, które umożliwiają pracownikom przeglądanie modeli niezależnie od pogody, dostępności Wi-Fi lub problemów z baterią. Jako rozwiązanie zapasowe dla StreamBIM – w przypadku awarii sieci, na każdej stacji BIM zainstalowany jest darmowy Solibri Anywhere. Jest beznadziejny do wymiarowania i orientacji wewnątrz budynku, ale ma niezaprzeczalną zaletę – działa offline na plikach pobranych na dysk twardy. To uratowało nas wiele razy.
Przekazanie projektu
Kiedy dochodzimy do przekazania obiektu, obieg oprogramowania zostaje zastąpiony przez gromadzenie danych i dokumentacji. Musimy połączyć podstawowe pliki PDF, rysunki i harmonogramy z modelami IFC i danymi projektu.
W tym celu ponownie używamy Pims – ponieważ mamy już każdy obiekt IFC przetłumaczony jako rekord w bazie danych, możemy połączyć je w zestawy danych i połączyć odpowiednie dokumenty.
Przepływ pracy dla gromadzenia dokumentacji MOM:
- Zaimportowane pliki IFC są przetwarzane i tłumaczone na rekordy bazy danych przez Pims.
- Obiekty są łączone w większe zestawy danych w zależności od ich wspólnych cech i wymagań dotyczących dokumentacji.
- Oddzielny moduł w Pims służy do dystrybucji tych wymagań do wykonawców w celu przesłania określonych typów dokumentacji na obiektach.
- Gotowa baza danych jest przekazywana zarządcom obiektów wraz z sesjami szkoleniowymi.
Podsumowanie
W tym wpisie zaledwie dotknąłem tematu integracji różnych programów w jeden dobrze naoliwiony trybik, który wykonuje przeznaczone dla nich zadania.
Jedną rzeczą jest wybór odpowiedniego pakietu oprogramowania, ale zupełnie innym i znacznie ważniejszym tematem jest skonfigurowanie obiegu oprogramowania między nimi, tak aby informacje były naprawdę zarządzane w jednym miejscu, a każdy program wykonywał tylko zadanie, do którego został przeznaczony.
Jest to temat, który chcę omówić następnym razem na blogu BIM Corner. Bądź na bieżąco!
