O jakich korzyściach słyszysz najczęściej, kiedy poruszany jest temat technologii BIM?
Ja zwykle słyszę, że projektowanie BIM przynosi oszczędności, eliminuje kolizje i usprawnia proces projektowy.
Jednocześnie jakie wyzwania mają przed sobą projektanci pracujący z technologią BIM?
Ja słyszę od nich, że projekty są coraz większe, coraz bardziej skomplikowane, a przy tym czasu na projektowanie jest coraz mniej.
Oba powyższe stwierdzenia są poprawne. BIM usprawnia proces projektowania. Jednak wysokie wymagania i skomplikowanie sprawiają, że proces projektowania często dławi się w natłoku informacji oraz ich nieuporządkowaniu.
W tej serii skupię się na literze “I” w skrócie BIM. To logiczne, że skoro projekty są coraz większe, to jest też coraz więcej informacji. Skoro czasu na projektowanie jest coraz mniej to znaczy, że czasu na dokonywanie zmian i poprawek także jest coraz mniej. W najbliższych wpisach chcę przedstawić podejście, które może zaoszczędzić czas i nerwy, w szczególności jeśli zostanie zaaplikowane już we wczesnej fazie projektu.
Jest to podejście do projektowania, w którym to dane odgrywają główną rolę w procesie rozwoju projektu. Metoda ta z sukcesem stosowana jest na dużych i skomplikowanych projektach kubaturowych, obiektach przemysłowych, lotniskach, hubach transportowych, etc. Ja sam nie znam projektów infrastrukturalnych stosujących to podejście, ale wierzę, że jest to możliwe po dostosowaniu pewnych elementów do specyfiki infrastruktury.
Dla kogo jest ta seria i czego się nauczysz?
- Dla inwestorów - dzięki niej dowiesz się jak przedstawiać swoje wymagania tak, aby ułatwić projektantowi pracę i zminimalizować możliwe pomyłki. Zobaczysz jak można szacować koszty nie posiadając jeszcze modelu BIM. Zdobędziesz wiedzę, jak w trakcie rozwoju projektu kontrolować zgodność danych z wymaganiami.
- Dla planistów - dowiesz się jak zaplanować pracę bez postawienia nawet jednej kreski w modelu oraz jak stworzyć wartościową bazę danych informacji o projekcie.
- Dla architektów i projektantów branżowych - dzięki zmianie podejścia do projektowania zaoszczędzisz czas na “przeklejaniu” informacji z pdfa do modelu. Dowiesz się także jak wygląda proces projektowy z bazą danych jako centrum informacji.
- Dla BIM koordynatora - nauczysz się sporo o konfiguracji atrybutów w programach graficznych oraz jak sprawić, aby bazy danych “rozmawiały” z modelami projektantów.
Jak cały nasz blog, tak i ta seria skoncentrowana będzie wokół praktycznych zagadnień – dlatego zaraz po wstępie i podstawach z niniejszego wpisu przejdziemy do konkretów. Zaczniemy od przedstawienia baz danych oraz procesów (workflows) na projektach, które odnoszą się do wyżej wymienionych zagadnień .
Na rynku istnieje wiele różnych programów do obsługi baz danych. W przykładach będę posługiwał się oprogramowaniem firmy dRofus, jako że znam je od podszewki. Projekty graficzne będą wykonane w ArchiCADzie, Revicie, albo będą to same pliki IFC.
Chciałbym podkreślić, że serię tę piszę przede wszystkim dla Was, dlatego jeśli tylko jakiś temat jest szczególnie interesujący to proszę o komentarze/e-maile. Dzięki informacji zwrotnej poświęcę więcej czasu na omówienie danego zagadnienia aby jeszcze dokładniej go przedstawić.
Spis artykułów
- Czym jest Model Driven Design oraz Data Driven Design (ten wpis).
- Jak przedstawić informacje o budynku w bazie danych? Omówienie struktury bazy danych na przykładzie projektu.
- Jak przedstawić projekt tak, żeby wszyscy wiedzieli co chcę wybudować? Data Driven Design dla Inwestora.
- Jak zaplanować projekt bez rysowania ani jednej kreski? Data Driven Design dla Planisty.
- Jak zarządzać informacjami na projektach? Porządkowanie i wykorzystanie informacji zawartych w modelu.
- Jak sprawić, aby zmiany projektowe nie zabiły mojego zespołu? Data Driven Design dla Architekta i Projektanta branżowego.
- Jak połączyć to, co graficzne z tym, co niegraficzne? Data Driven Design dla BIM Koordynatora.
- Jak oszacować koszta bez użycia modelu?
- Co zrobić dalej z tymi wszystkimi informacjami, które mam w bazie danych? Data Driven Design dla Administracji Obiektami.
- Inne elementy tworzące proces Data Driven Design
Artykuł 1: Czym jest Model Driven Design i Data Driven Design
W poniższym wpisie skupię się na podstawach, które pozwolą Ci zrozumieć szerszy kontekst tej serii. Opiszę i porównam dwa procesy projektowania – “tradycyjne” podejście do modelowania BIM oraz projektowanie w oparciu o dane.
Spis treści
Obecny proces projektowania (Model Driven Design)
BIM w branży zagościł się już na dobre i nikt, kto spróbował projektowania opartego na modelu nie myśli wracać do 2D. Jednocześnie w samym procesie zarządzania informacjami tak naprawdę niewiele się zmieniło w porównaniu do AutoCADa. Poniżej omówię obecny proces z naciskiem na zbieranie informacji projektowych oraz przedstawię miejsca, w których brak odpowiednich procesów sprawia najwięcej wyzwań.
W obecnej formie proces projektowania BIM zaczyna się od bliskiej współpracy z inwestorem, a także zespołem projektowym w celu uzyskania i zebrania informacji i wymagań o projekcie, które przechowujemy w Common Data Environment (Wszystko, co powinieneś wiedzieć o podstawach technologii BIM rozdział o informacji). Dane te dostępne są zwykle w wielu różnych formach, m.in.:
- Szkice modelu.
- Excel z wykazem pomieszczeń i powierzchni.
- PDFy z wymaganiami i opisami technicznymi dla każdej z branż.
W następnej fazie projektowany jest model 3D (zwykle zawierający kilka modeli 3D) zgodnie z wymaganiami określonymi w poprzedniej fazie projektu, przy użyciu narzędzi do modelowania graficznego (Revit, Archicad, Tekla, etc.). Zaczyna się od wprowadzania podstawowych i generycznych informacji o elementach, a wraz z postępem projektu, oraz w zależności, czy wymagania dotyczące projektowania są na wysokim poziomie, mogą być one dalej wzbogacane.
W dalszym ciągu następuje kontrola tego, co zostało zaprojektowane względem:
- Wymagań prawnych.
- Wymagań od inwestora.
- Innych branż (jest to rola BIM Koordynatora)
To właśnie w tej fazie najbardziej objawia się niepewność, które źródło informacji o obiekcie jest tym właściwym. To, które jest w modelu czy też to w dokumentach leżących na CDE? I najczęściej właśnie podczas kontroli wielu inwestorów rozkłada ręce i przyznaje, że nie ma na to dobrego procesu.
W przypadku rozbieżności pomiędzy wymaganiami i tym, co zostało zaprojektowane, należy wprowadzić zmiany projektowe w poszczególnych elementach i atrybutach należących do nich.
Taki sposób projektowania to Model Driven Design – centralne miejsce informacji o projekcie stanowi model (modele) oraz CDE, w którym znajdują się dokumenty.
Oczywiście jest to założenie teoretyczne. Powyższe kroki są powielane w iteracjach – w czasie cyklu rozwoju projektu następuje wiele kontroli i rewizji projektów.
Proces ten można przedstawić schematycznie w następujący sposób:
Zalety i wady Model Driven Design
Metoda projektowania Model Driven Design ma wiele oczywistych zalet:
- Projektanci pracują na jednym narzędziu, które dobrze znają, dzięki czemu proces projektowania przebiega w sprawny sposób.
- Powstaje wysokiej jakości wielobranżowy model 3D.
- Informacje są przypisane do elementów w modelu, co powoduje możliwość odczytu danych w każdym momencie procesu (również przy użyciu darmowych narzędzi do odczytu plików IFC).
- Wszyscy uprawnieni członkowie procesu projektowego mają dostęp do informacji i wymagań projektowych na CDE.
- O pozostałych zaletach możesz przeczytać w naszym artykule: Dlaczego powinienem wykorzystywać technologię BIM.
Niestety, nie jest ona idealny i ma kilka znaczących wad, jak na przykład:
- Waga plików – jeśli wprowadzamy do modelu wszystkie informacje powstające na projekcie, to rośnie wielkość pliku, a spada płynność i przejrzystość modelu.
- Zarządzanie zbiorem informacji – znalezienie i wygenerowanie żądanych zestawień, tabeli lub wysortowania danych zajmuje dużo czasu. Zarządzanie danymi z poziomu programów do modelowania jest przez to toporne.
- Podwójne źródło prawdy – w przypadku wymagań projektowych znajdujących się w plikach niepowiązanych z modelem pojawia się niebezpieczeństwo utraty kontroli prawdziwego i poprawnego źródła informacji.
Prosty i praktyczny przykład – z pomieszczeniami w budynku, w których ma być określona liczba gniazdek elektrycznych:- Podczas spotkania koordynacyjnego ustalono, że we wszystkich salach spotkań ma być po 10 gniazdek elektrycznych.
- W pierwotnych wymaganiach było ich 5.
- Do modelu wprowadzono 10 gniazdek według notatki ze spotkania koordynacyjnego.
- Inwestor nie aktualizuje jednak swojego dokumentu wymagań (zdarza się, np. z braku czasu bądź przez niedopatrzenie).
- Po pewnym czasie, sprawa powraca i zadane zostaje pytanie – dlaczego mamy 10 gniazdek, skoro w wymaganiach jasno stoi 5?
- Kontrola wymagań – porównanie modelu z wymaganiami, które powstały w oddzielnych dokumentach jest manualne i czasochłonne – na jednym monitorze Excel, na drugim model. Pochłania to lwią część nakładu pracy, a często z powodu braku czasu lub zasobów, wykonywane jest pobieżnie i niedokładnie.
- Zmiany projektowe – gdy się pojawiają, może wyniknąć konieczność przeprojektowania modelu, np. ściany, lub kanału wentylacyjnego. To z kolei wiąże się ze zmianą geometrii pomieszczenia lub innych elementów przylegających. Przez taką sytuację jedna zmiana może pociągnąć za sobą konieczność przeprojektowania dużej części budynku.
- Sprawdzenie progresu/stopnia zaawansowania projektu – graficznie projekty BIMowskie już po etapie szkicu niewiele się zmieniają, więc ciężko jest rozpoznać na pierwszy rzut oka zaawansowanie projektu.
W celu wyeliminowania tych wad, wielu projektantów i inwestorów zaczęło rozważać zmianę procesu projektowania na taki, w którym informacje zebrane w jednym miejscu będą stanowiły całe składnicę wiedzy oraz będą w stanie na bieżąco aktualizować model.
Projektowanie w oparciu o dane (Data Driven Design)
Punktem wyjściowym dla opracowania tego procesu była chęć eliminacji wad z poprzedniego punktu, równocześnie przy zachowaniu zalet procesu projektowania BIM. Stworzono więc możliwość połączenia informacji z wczesnego stadium projektowania z modelem, który powstaje w następnej kolejności.
Założeniem całego procesu projektowania w oparciu o dane jest centralna baza danych, która będzie w stanie zebrać w sobie możliwie najwięcej wymagań i danych i następnie synchronizować i mapować wybrane z nich z modelem.
Jest kilka możliwych sposobów rozwiązania tego zagadnienia:
- Dedykowany software: dRofus, BIMEye, Code Book, Building One i jeszcze kilka innych narzędzi
- Excel połączony z modelem. Nie jest to ładne ani proste rozwiązanie, ale na pewno najtańsze – dobrze ustrukturyzowany Excel, który potem automatycznie przenosi nam dane do odpowiednich atrybutów za pomocą zewnętrznego plug-ina lub skryptu w Dynamo lub Grasshopperze. Artykuł, który przedstawia podstawy połączenia Dynamo-Excel:
- Istnieje jeszcze teoretyczna opcja połączenia bazy danych SQL z programami graficznymi. Wymaga to jednak znajomości SQLa oraz API programów do modelowania
We wczesnej fazie projektowania współpraca pomiędzy inwestorem, planistą i architektem odbywa się z zastosowaniem wspólnej bazy danych. Informacje i wymagania zamiast do dokumentów i Exceli zapisuje się do bazy danych dzieląc tablice na planowane funkcje, działy i pomieszczenia.
Aby proces był możliwy do zastosowania, wymagana jest odpowiednia forma zapisu danych – muszą to być metadane, czyli zestaw ustrukturyzowanych informacji, które ułatwiają ich znalezienie, identyfikację, oraz zarządzanie. Przykład:
- Zamiast opisać w dokumencie: “Pomieszczenie biurowe projektowane dla 6 osób, użytkowane w dni robocze w godzinach 8 do 16.”
- Tworzymy tablice z powyższymi danymi w formie metadanych:
W następnej fazie wzbogacamy projekt o konkretne dane, zgodnie z wymaganiami inwestora. Mogą to być np. znaczące przedmioty (wyposażenie szpitalne), drogie elementy budowlane albo instalacje w budynku. Wprowadzenie tych informacji umożliwia proste i szybkie przeprowadzenie szacunku całkowitego budżetu oraz całkowitej planowanej powierzchni podzielonej na działy.
Informacje te służą następnie jako podstawa do przeprowadzenia pierwszej kontroli. Dzięki temu, że struktura bazy danych odzwierciedla strukturę projektu budowlanego (więcej we wpisie o strukturze bazy danych) można zacząć koordynować projekt już we wstępnej fazie. Projektanci mogą wprowadzać zmiany i dopasować projekt bez konieczności przeprojektowywania graficznego. Oszczędzamy jeden krok – wprowadzanie zmian projektowych na późniejszym etapie bazujących na obiektach 3D.
Po pierwszych korektach oraz mając całkiem zaawansowaną bazę danych zaczynamy projektować obiekty. Projektanci mogą ustalić odpowiednie mapowania danych (przyporządkowanie wartości między programami – jak na grafice poniżej) i sposób synchronizacji pomiędzy zewnętrzną bazą danych a modelem. Pozwala to na sprawniejsze modelowanie geometrii posiłkując się informacjami umieszczonymi w tablicach – a to dlatego, że atrybuty są już zdefiniowane i poprzez uruchomienie skryptu lub synchronizacji z programem zapełniają się one informacjami z bazy danych.
Co to daje? Nie trzeba wpisywać wszystkich atrybutów ręcznie do modelu, co przyspiesza modelowanie, ale także zapewnia poprawność danych na projekcie – w końcu odzwierciedlają one to, co zostało uzgodnione z inwestorem.
Nie jesteśmy niestety w stanie zupełnie wyeliminować przeprojektowywania obiektu w programie graficznym – w końcu zmiany przychodzą na różnych etapach, czasem bardzo późno. Jednocześnie dzięki posiadaniu pojedynczego źródła informacji, które współpracuje z modelami, jesteśmy w stanie łatwo je wprowadzić.
Poniżej przedstawiony jest szkic procesu w którym dane są motorem napędowym projektowania i to one determinują model:
Zalety i wady Data Driven Design
Zalety procesu projektowania opartego o dane są w zasadzie odpowiedzią na wady projektowania opartego na modelu:
- Waga plików – dzięki temu, że nie potrzebujemy trzymać wszystkich atrybutów w obiektach, pliki są znacznie lżejsze.
- Zarządzanie zbiorem informacji – możliwości pracy na bazie danych są takie, jak w pracy w Excelu. Filtrowanie, wyszukiwanie, sortowanie wierszy i kolumn jest proste i szybkie.
- Pojedyncze źródło prawdy – wszystkie informacje zaczyna się od wprowadzania do tabeli i to ona determinuje jakie są obowiązujące wymagania. A dzięki synchronizacji w tle z programami do modelowania jesteśmy w łatwy sposób te dane do nich przenieść.
- Kontrola wymagań – mając w jednym miejscu zarówno wymagania inwestora jak i zaprojektowane dane oraz podłączony model jesteśmy w stanie sprawnie wykonać kontrolę wymagania vs projekt.
- Zmiany projektowe – dzięki możliwości kontroli na wczesnym etapie projektowania w samej tylko bazie danych, lub tylko na poziomie atrybutów elementów, wprowadzanie zmian zajmuje mniej czasu. Oczywiście zależność kosztu zmian od zaawansowania projektu nie ulega modyfikacji – im później wprowadzamy zmianę, tym jest ona droższa i trudniejsza do wykonania.
- Mamy możliwość sprawdzenia stopnia zaawansowania progresu w całym projekcie poprzez łatwy wgląd w zaawansowanie danych.
Data Driven Design nie rozwiązuje niestety wszystkich wyzwań, które stoją przed uczestnikami dużych projektów:
- Różny proces projektowy od dotychczas znanego przez projektantów i inwestora – wymagana jest otwartość na zmiany i chęć dostosowania swoich nawyków do nowej rzeczywistości. Bez woli nauki nowego sposobu pracy i myślenia, projektowanie na podstawie danych będzie tylko kolejnym narzędziem i obciążeniem dla wszystkich stron.
- Konieczność przepisania wymagań inwestora z dokumentów wordowskich na metadane – obecnie wśród inwestorów dalej królują dokumenty pisane w programie Word i tabelki Excelowskie. Wprowadzenie i ustrukturyzowanie tych informacji wymaga czasu i jest obarczone ryzykiem błędu.
- Zaczynając pierwszy raz z tym procesem projektowania, musimy być przygotowani na dostosowanie standardowych bazy danych do naszych potrzeb oraz stworzenie strategii i w razie potrzeby modyfikacji procesu przepływu informacji.
- Dodatkowe koszty dla projektu – nie jest to rozwiązanie dostępne z poziomu Revita czy innego narzędzia. Jeśli chcemy dedykowane rozwiązanie, dochodzi koszt licencji lub zakupu odpowiedniego plug-ina. Aby obniżyć barierę wejścia można pozostać przy Excelu oraz zlecić (lub samodzielne stworzyć) skrypt do Dynamo lub Grasshoppera.
Podsumowanie
W tym pierwszym wpisie, rozpoczynającym serię o Data Driven Design, przedstawione zostały dwie różne metody podejścia do projektowania. Poznałeś ich mocne i słabe strony. Jeśli zainteresował Cię koncept Data Driven Design to zapraszam do kolejnych wpisów, w których omówię w szczegółach m.in. jak powinna wyglądać baza danych, przedstawię strategię zarządzania informacjami na projekcie oraz konkretne case’y projektowe dla różnych uczestników przedsięwzięcia inwestycyjnego.
Daj znać co myślisz o tym podejściu do projektowania w komentarzu poniżej lub wyślij wiadomość na [email protected]. Zawsze odpowiadamy i jesteśmy otwarci na dyskusję!
Sprawdź pozostałe artykuły dotyczące procesu Data-Driven Design:
CZĘŚĆ 1 – Data-Driven Design wyjaśniony w jednym poradniku
CZĘŚĆ 2 – Jak przedstawić informacje o budynku w bazie danych?
CZĘŚĆ 3 – Planowanie inwestycji – jak przedstawić wymagania?
