ISO 19650? Eurokody? Normy? Normy są długie. Są niezrozumiałe i nudne. Pamiętam jak na studiach alergicznie reagowałem na każde wspomnienie o normach i Eurokodach (dalej się wzdrygam na nazwę Eurokod 2). A teraz… W sumie niewiele się zmieniło. Ale! W ankiecie często prosiliście o podzielenie się wiedzą o CDE oraz o ISO 19650. Przebrnąłem więc dla Was od deski do deski przez tę normę. Uwierzcie mi, nie jest to emocjonująca lektura. Efektem jest ten oraz kolejne wpisy, będące podsumowaniem, wnioskami oraz praktycznymi spostrzeżeniami.
Spis treści
1. Definicja Common Data Environment
Zacznijmy od definicji. Cytując za standardem ISO 19650-1, p. 3.3.15, Common Data Environment to (tłumaczenie własne):
Agreed source of information for any given project or asset, for collecting, managing and disseminating each information container through a managed process.
Komentarze do definicji (za ISO):
- Komentarz 1: Proces CDE opisuje zestaw kroków, które należy zastosować. Rozwiązanie CDE przedstawia konkretną technologię.
- Informacja: Reprezentacja danych możliwa do re-interpretowania oraz przedstawiona w sposób umożliwiający komunikację (np. Belka stalowa HEB).
- Zbiór informacji: trwały zestaw informacji, który można odzyskać z pamięci pliku, systemu lub aplikacji (np. Model strukturalny w IFC).
Agreed source of information for any given project or asset,
- CDE zostaje uzgodnione dla całego zespołu projektowego,
- Jest źródłem informacji,
- Może występować na każdym projekcie lub też już istniejącej budowli (aktywo).
for collecting, managing and disseminating each information container
- W CDE gromadzi się każdy zbiór informacji powstający na projekcie.
- Zbiory informacji to zwykle pliki lub podzbiory danych. Mogą być one ustrukturyzowane (informacje posiadające metadane, np. modele geometryczne, zestawienia, bazy danych) lub nieustrukturyzowane (informacje nieposiadające metadanych, np. dokumenty pdf, skany, zdjęcia, nagrania, e-maile, nagrania wideo),
- CDE służy nie tylko do statycznego przechowywania informacji, ale także do zarządzania nimi oraz rozpowszechniania do pozostałych członków procesu projektowego (innymi słowy – informacje są dostępne dla wszystkich członków zespołu).
through a managed process.
- CDE to przede wszystkim proces (spójrz na komentarz 1 do definicji),
- Proces ten jest zarządzany, to znaczy, że istnieje osoba odpowiedzialna za CDE.
Po rozbiciu tej definicji na czynniki pierwsze pojawia się już nieco bardziej zrozumiały obraz czym jest i czemu służy Common Data Environment.
2. Jedno czy wiele CDE?
ISO zostało stworzone z myślą o projektach BIM na poziomie drugim. Jest to poziom ambicji większości firm, które implementują BIM. Jednocześnie spotkałem się już z niejednym projektem, który ma ambicje sprostać oczekiwaniom BIM poziomu 3.
Jaki to ma wpływ na temat CDE? BIM Stage 2 dopuszcza stosowanie kilku rozwiązań CDE dla jednego projektu. Często kończy się na tym, że projektant, wykonawca oraz inwestor ma swoje rozwiązanie. Ten proces CDE opisywał Konrad Naborczyk w swoim artykule o technologii BIM w firmie wykonawczej. BIM poziomu trzeciego to już baza danych CDE, która jest jedna i wspólna dla całego projektu.
3. Kto jest odpowiedzialny za stworzenie i utrzymanie CDE?
W normie jasno sprecyzowane jest, że to na inwestorze (appointing party) spoczywa odpowiedzialność za stworzenie i utrzymanie Common Data Environment dla całego projektu.
Jeśli planowane jest używane rozwiązanie zewnętrzne, to CDE powinno być pierwszym podpisanym kontraktem na projekcie. Najlepiej, aby stworzyć CDE jeszcze zanim ogłosi się przetarg.
Osobą odpowiedzialną za utrzymanie CDE jest “Manager Informacji”, którego zadaniem jest nadzór nad procesem, aktualizacja oraz synchronizacja wszystkich zbiorów informacji na projekcie. Nie można mylić tego stanowiska z BIM Koordynatorem. Manager Informacji nie ma odpowiedzialności za prace projektowe lub koordynację międzybranżową.
4. Założenia Common Data Environment
Aby dobrze zarządzać zbiorami informacji, proces Common Data Environment powinien spełniać następujące założenia:
- Każdy projekt powinien uzgodnić i zapisać konwencję nazewnictwa oraz klasyfikacji metadanych.
- Każdy zbiór informacji powinien posiadać swoje Unikalne ID (unikalną nazwę) według konwencji nazewnictwa ustalonej na projekcie.
- Każde pole metadanych powinno mieć przypisaną wartość zgodnie z tą konwencją.
- Każdy zbiór informacji ma mieć możliwość przypisania mu wartości:
- Status,
- Rewizja,
- Klasyfikacja.
- Istnieje możliwość modyfikacji stanu zaawansowania dla każdego zbioru informacji.
- Zachowana jest historia zmian stanu zaawansowania dla każdego zbioru informacji zawierająca:
- Nazwę użytkownika,
- Daty,
- Rewizje.
- Możliwość stworzenia kontroli dostępu na poziomie pojedynczego zbioru informacji.
Zadania te opiszę poniżej przedstawiając elementy składowe procesu Common Data Environment.
5. Proces CDE
Do każdego zbioru informacji przypisujemy metadane, aby ułatwić zarządzanie procesem, śledzenie zmian oraz filtrowanie danych. W ten sposób jesteśmy w stanie zapewnić porządek oraz kontrolę nad informacjami, które pojawiają się w trakcie procesu inwestycyjnego. Poniżej opiszę szczegółowo każdą z tych metadanych.
Stan zaawansowania informacji (progres)
Każdy zbiór informacji (information container) może znajdować się w różnym stanie zaawansowania. Grafika pochodząca z ISO 19650 pokazana poniżej przedstawia ten proces w uproszczonej formie.
W praktyce widzę tu trzy możliwe rozwiązania zagadnienia:
- Statusy w formie metadanych przypisanych do każdego dokumentu. Struktura CDE jest w takim wypadku tabelaryczna (więcej o statusach poniżej)
- Podział na foldery z nazwami statusów (Work In Progres, Shared, Published, Archive)
- Sterowanie uprawnieniami użytkowników we wspólnej bazie danych
Work In Progress
Check / Review / Approve
Stan przejściowy, w trakcie którego sprawdzana jest zgodność stworzonych informacji względem wymagań projektowych oraz standardów. Odpowiedzialna za to jest firma wytwarzająca te informacje.
W praktyce: Projektanci wentylacji zakończyli pracę nad rewizją. Zgłaszają to do osoby odpowiedzialnej za daną dyscyplinę na projekcie. Osoba ta sprawdza zgodność z wymaganiami projektowymi oraz akceptuje model.
Shared
W tym stanie znajduje się cała dokumentacja, która służy do koordynacji oraz jako podkład do dalszej wspólnej pracy między zespołami projektowymi. Zbiory informacji w stanie “Współdzielonym” są widoczne i dostępne dla każdego uczestnika projektu, ale są nieedytowalne. W tym stanie znajdują się również inne informacje dla klienta (appointing party), które oczekują jego autoryzacji.
W praktyce: w stanie shared znajdują się m.in. wszystkie modele branżowe w formacie IFC, które oczekują na koordynacje. Mogą się tu także znajdować np. Wnioski materiałowe, lub wnioski o roboty dodatkowe, które czekają na akceptację inwestora.
Review / Authorize
Stan przejściowy, w którym odbywa się proces porównywania otrzymanych informacji z wymaganiami projektowymi. Ocenia się skoordynowanie, dokładność oraz kompletność dostarczanych informacji.
Jeśli zbiór informacji spełnia wymagania, przenosi się go do stanu “Published”. Jeśli natomiast posiada on braki odsyłany jest do stanu “Work In Progress” w celu poprawy przed wysłaniem do kolejnej koordynacji.
Autoryzacja oddziela informacje, które mogą ulec zmianie, od informacji poprawnych. Po autoryzacji informacje mogą być przeznaczone do:
- szczegółowego projektowania,
- użytku przez wykonawcę,
- zarządzania obiektem.
W praktyce: Po koordynacji wielobranżowej fragment projektu (nazwijmy go: Obszar Kontrolny 1) zostaje zaakceptowany. Natomiast Obszar Kontrolny 2 wymaga poprawy i informacje w tym obszarze modelu wracają do stanu “Work In Progress”.
Published
W tym stanie znajdują się wyłącznie informacje poprawne i przeznaczone do użytku przez kolejnych uczestników procesu inwestycyjnego.
W praktyce: Model z Obszarem Kontrolnym 1 po koordynacji zostaje przeniesiony do stanu “Published”. W tym momencie wykonawca może używać go jako podstawy do składania zamówień na materiały budowlane. Jeśli Wykonawca użyłby modelu ze stanu shared, odpowiedzialność za ewentualne błędy spoczywałaby wyłącznie na nim.
Archive
Stan ten służy jako zapis wszystkich zmian dokonywanych na zbiorach informacji podczas procesu inwestycyjnego. Może posłużyć jako pomoc w rozwiązywaniu ewentualnych sporów pomiędzy uczestnikami procesu.
Unikalne ID
Nazwa zbioru informacji (dokument, rysunek, model, etc.) powinna być unikalna oraz wspólna dla całego projektu (opisaną np. w BEP). National Annex podaje sugestie dla Wielkiej Brytanii. Ja opiszę tutaj format, który znam z kilku inwestycji z Norwegii.
Zbiory informacji podpisuje się następująco:
Numer budynku-kondygnacja-strefa kontrolna-dyscyplina-kod klasyfikacji systemu-typ rysunku-numer porządkowy
6025-XX-S-A-200-00-001
Kontrola wersji (rewizje)
Chyba każdy z nas pamięta pracę nad dokumentem w wordzie zanim Microsoft wprowadził automatyczną kontrolę wersji. Jeśli zapisywałeś swoją pracę używając tylko ctrl+s to nie używałeś kontroli wersji. Bez kontroli wersji nie możesz wrócić do wyglądu dokumentu z poprzedniej sesji. Jeśli natomiast używałeś opcji “zapisz jako” a następnie codziennie nadawałeś inną nazwę temu plikowi – wtedy stosowałeś rewizje. Po dwóch dniach mogłeś odpalić poprzedni dokument i sprawdzić zmiany.
Wersja kontroli w Google Docs pomaga mi zawsze przy tworzeniu nowych wpisów na blog 🙂 W bardzo trafny sposób zagadnienie obrazuje ta infografika:
W CDE funkcjonuje to w podobny sposób. ISO 19650 w aneksie do brytyjskiej wersji proponuje rozwiązanie:
W Norwegii natomiast używa się jedynie indeksu 1-literowego A-Z, następnie 2-literowego AA, AB, itd.
Oczywiście nie są to jedyne słuszne rozwiązania. Dużo zależy także od używanego programu – jedne używają tylko daty jako metadanej rewizji, a inne numerację liczbową. Tutaj znowu najważniejszy jest proces i uzgodnienie wspólnej formy na początku projektu.
Statusy
Status w postaci metadanych ma wskazywać na stan zaawansowania informacji w CDE, aby każdy z uczestników projektu miał świadomość w jakim celu może wykorzystać dany zbiór informacji (a także w jakim celu nie może go wykorzystywać). Ponadto ustawienie takich metadanych dostępnych dla każdego odwiedzającego CDE obrazuje progres prac oraz gdzie w procesie znajduje się interesujący nas zbiór informacji.
Brytyjski załącznik krajowy przychodzi z sugestią używania poszczególnych statusów:
Jeśli kogoś interesuje zgłębienie tego tematu to polecam dalszą lekturę w dokumencie stworzonym przez UK BIM Framework – Information Management according to BS EN ISO 19650 Guidance.
Statsbygg (norweska dyrekcja budownictwa publicznego) zaleca w przewodniku PA 0603 stosowanie statusów:
D – do komentowania, koordynacja wewnątrz dyscyplinarna
I – do komentowania, koordynacja branżowa
C – do akceptacji
G – zaakceptowany
U – nieważny/archiwum
Klasyfikacje
ISO zaleca, aby każdy zbiór informacji został przypisany do klasyfikacji wspólnej dla całego projektu. Klasyfikacja wskazuje jaki typ informacji znajduje się w danym zbiorze informacji. Może ona definiować m.in dyscyplinę (architektura, konstrukcje, wentylacja), typ rysunku (model, plan, detal). Ważne jest aby pozostałe metadane przypisane do zbioru informacji (np unikalne ID, albo statusy) nie były duplikowane przez klasyfikację.
6. Podsumowanie
Powyżej przedstawiłem wszystko, co znalazłem na temat procesu Common Data Environment w normie ISO 19650. Moim celem było przedstawienie tego w sposób zwięzły i zrozumiały. Tego pierwszego nie jestem pewien (artykuł ma dobrze ponad 2000 słów), ale mam nadzieję, że to drugie zostało spełnione.🙂 Dajcie znać, czy podobał Wam się ten artykuł! Jeśli tak, to na warsztat wezmę pozostałe procesy opisywane w ISO.
W następnym wpisie przedstawię jedno z możliwych rozwiązań software’owych, które służy za rozwiązanie CDE, ale także spełnia dodatkowe funkcjonalności.
Proces Common Data Environment - Infografika
Informacje zawarte w tym artykule są oparte na moim własnym doświadczeniu, treścią normy ISO 19650-1 oraz ISO 19650-2 oraz przewodnikiem po normie stworzonym przez UK BIM Framework: https://ukbimframework.org/standards-guidance
