Realizacja techniczna, skoordynowana w jednym modelu BIM

BIM jako rama koordynacji

BIM/Revit traktujemy jako ramę koordynacji łączącą decyzje kreatywne między dyscyplinami — nie jako warstwę prezentacji. Dane oświetlenia, oznakowania, mebli miejskich oraz sztuki i warstwy cyfrowej żyją w jednym środowisku modelu, dzięki czemu intencja projektowa jest zachowana przez dokumentację i budowę.

Proces gotowy do Revita

Pracujemy z natywnymi rodzinami Revit tam, gdzie to możliwe, i ze strukturalnymi bibliotekami RFA dla oznakowania i obiektów custom. Gdy partnerzy używają innych środowisk modelowania, wymiana danych przez STEP, IFC i DWG jest koordynowana w ramach jasnego planu wymiany danych.

Redukcja kolizji i koordynacja

Koordynacja skupia się na warstwach przestrzennych, które wnosimy — stożki światła, strefy widoczności oznakowania, obrysy konstrukcyjne instalacji artystycznych, obrysy mebli miejskich — oraz na ich interakcji z architekturą, MEP, konstrukcją i krajobrazem.

Modele techniczne i dokumentacja

Dokumentacja jest przygotowana pod przetarg, produkcję i montaż: rysunki techniczne, zestawienia, specyfikacje, założenia sterowania i logika materiału — wszystko wyprowadzone z tego samego skoordynowanego środowiska modelu.

Rodziny STEP i RFA dla oznakowania

Typologie oznakowania dostarczamy jako rodziny RFA gotowe do Revita z dokumentacją STEP, wspierając dystrybucję znaków opartą na BIM i koordynację produkcji.

Pakiety gotowe do wdrożenia

Finalne pakiety są zorganizowane tak, by wykonawcy, producenci i monterzy otrzymywali spójne informacje, które wspierają decyzje z jednego skoordynowanego źródła.

Zastosowania BIM, kamienie milowe wymiany informacji, formaty modeli, odpowiedzialności i wymagany poziom informacji ustala się, zanim cokolwiek powstanie — w BEP i w planach dostarczania informacji. Tu rozstrzyga się, co model oznakowania ma nieść, na którym etapie i kto za co odpowiada. Ramy wyznacza ISO 19650.

Modele architektury, konstrukcji, sufitów, MEP i zagospodarowania terenu zostają przejęte i sprawdzone: poziomy, osie, współrzędne wspólne, jednostki, podział na strefy i fazy. Oznakowanie powstaje na zweryfikowanych podkładach, nie na założeniach o nich.

Zanim powstanie pierwsza rodzina, ustalamy schemat danych znaku: Sign ID, typ, poziom i strefa, treść i cel, sposób montażu, wymiary, wykończenie, podświetlenie, zasilanie i dane, status i rewizja. W Revicie są to Shared Parameters, dzięki czemu te same pola działają w rodzinach, tagach i zestawieniach.

Parametryczne rodziny Revit powstają osobno dla każdej typologii nośnika — parametry typu i instancji, warianty mocowania, skalowalna geometria, reprezentacje 2D i 3D, katalogi typów tam, gdzie wariantów jest wiele. Rodziny pozostają lekkie, żeby model federacyjny dało się otworzyć. W openBIM znak odwzorowuje się jako IfcSign.

Znaki trafiają do modelu i dostają tożsamość: Sign ID, typ, treść, kierunek strzałki, cel, host, poziom i pomieszczenie. Od tego momentu plany lokalizacji i zestawienia znaków powstają z modelu, a nie obok niego.

Modele branżowe zostają połączone w model federacyjny, a następnie wydane przez CDE z kontrolowanym statusem, rewizją, metadanymi i klasyfikacją. Publikacja to przejście między WIP, Shared i Published — nie wysłanie pliku mailem.

Oznakowanie sprawdzamy względem skrzydeł drzwi i ich stref otwierania, sufitów, belek i instalacji, tryskaczy, kamer i czujek, wysokości przejścia pod znakami podwieszanymi, podłoża pod mocowanie, dostępu montażowego i serwisowego oraz zasilania i danych dla znaków podświetlanych i cyfrowych. Każdy problem ma przypisaną osobę odpowiedzialną i jest prowadzony jako BCF, nie jako zrzut ekranu w mailu.

Z modelu powstają plany lokalizacji, zestawienia, tagi, elewacje, widoki linii wzroku i koordynacyjne 3D, detale montażu, przedmiary oraz zestawienia zasilania i danych. W trakcie budowy dochodzą: opiniowanie rysunków warsztatowych, makiety, aktualizacja lokalizacji i rejestr usterek. Całość zamyka model as-built, końcowe zestawienie znaków i dane na potrzeby utrzymania obiektu.

Schemat danych, nazewnictwo, klasyfikacja i wymagany poziom informacji zostają zatwierdzone przed pierwszą rodziną — w momencie, w którym zmiana jest jeszcze tania. Dopóki którekolwiek z tych ustaleń pozostaje otwarte, modelowanie się nie zaczyna.

Przy każdym przejściu WIP → Shared model jest sprawdzany, nie oglądany: zduplikowane Sign ID, brakujące parametry, błędne przypisanie do hosta i poziomu, wartości spoza uzgodnionych list oraz każda rozbieżność między modelem a zestawieniem. Gdy wymagania zapisane są jako specyfikacja IDS, sprawdzenie wykonuje się automatycznie na pliku IFC, nie okiem. Wykrywanie kolizji tego nie zastępuje — model wolny od kolizji nadal może być bezużyteczny.

To, co faktycznie zamontowano, zostaje uzgodnione z modelem i końcowym zestawieniem, zanim dane trafią do utrzymania: skorygowane lokalizacje, zamienniki przyjęte na budowie i rejestr znaków, z którego realnie będzie korzystał zarządca.