warsztat architekta
BIM oraz IPD
10
praktyka projektowa
Podobnie ma się sprawa z softwarem BIM dla managementu
i kooperacji – moim zdaniem głównego typu oprogramowania
w procesach BIM/IPD – który jest w stanie zebrać owoce
pracy wszystkich projektantów i zarówno rozesłać pliki do
software'ów analitycznych, jak i ewaluować poskładane mode-
le (ang.
federated models
) we własnym zakresie, na końcu
integrując wyniki na etapie wykonawstwa.
Dostępne na krajowym rynku zachodnie produkty nie
uwzględniają w pełni polskich realiów i wymagają adaptacji
w – i tak już wystarczająco skomplikowanych – procesach.
8.
Integracja wszystkich aspektów w procesie LCA (ang.
life
cycle assessment
, czyli czas życia obiektu)
Jak zwykle wzorce pochodzą z Wielkiej Brytanii. W ostatnich
latach dokonano tam w ramach prac nad ośmioma kolumnami
oficjalnej implementacji BIM dla osiągnięcia poziomu 2. („The
8 Pillars of BIM Level 2”), dodatkowego podziału częci tech-
nologicznej procesu IPD na podkategorie:
• PIM (ang.
project information model
) – po stronie projek-
towo-wykonawczej: wielowymiarowa platforma dla danych
projektowych i dla wykonawstwa,
• IE (
Information Exchange
) – formaty wymiany danych
i kooperacji,
• AIM (
Asset Information Model
) – rodzaj docelowego ocze-
kiwania inwestora co do otrzymanych modeli dla okresu
użytkowania obiektu.
Jako ze Anglicy niemal wszystko maja już pod oficjalna
kontrola, PIM opiera się na publicznie dostepnym dokumencie
tworzenia BIM (
BIM authoring
– patrz aspekt 7). W chwili
obecnej jest to w naszym kraju sytuacja teoretyczna (patrz
aspekt 1 i konkluzje poniżej), piszemy zatem o rozwiązaniach
docelowych.
Drugi raz dochodzi do wspomnianego styku przepływu infor-
macji, gdy nasycony danymi wirtualny model zostaje przeka-
zany managerowi wykonawstwa w BIM jako osobne modele
albo model wspólny (tzw.
federated model
, czyli modele bran-
żowe złożone razem w oprogramowaniu dla managementu
BIM). Przekaz taki występuje wielokrotnie.
Obecnie nie istnieje w Polsce żaden system klasyfikacji budow-
lanej, który byłby kompatybilny z dokładnym, abstrakcyjnym
układem standardów komputerowych dla procesów BIM.
Mało tego, funkcjonujące systemy nazewnictwa budowlanego
są albo chaotyczne (zarówno KNR, jak i CPV mają powtarza-
jące się w różnych miejscach te same elementy i mało logiczną
strukturę), albo w części stanowią własność prywatną (KNR).
Alternatywy dla nich nie stanowią ani PKOB (Polska Klasyfikacja
Obiektów Budowlanych), ani PKWiU (Polska Klasyfikacja
Wyrobów i Usług), ani PKD (Polska Klasyfikacja Działalności).
Możliwe opcje pochodzą z zagranicy, np. brytyjski Uniclass
(Uniclass 2015) lub amerykański OmniClass. Inne systemy
(SfB, STABU, CEEC, OENORM A-6241 części 1 i 2 itp.) są
zbyt mało znane na krajowym rynku bądź niezbyt adekwatne.
7.
Technologia BIM.
Istnieją trzy rodzaje software'u dla technologii BIM:
• dla wielowymiarowego projektowania BIM (
BIM autho-
ring
) – architekci i projektanci branżowi,
• dla analiz/ewaluacji modeli (
BIM evaluation
) – projektanci
i inżynierowie BIM,
• dla managementu i kooperacji (
BIM management
) dla modeli
złożonych – managerowie BIM ze strony inwestora i wykonawcy.
Kłopotem jest wejście na krajowy rynek różnego rodzaju
software’u zachodnich producentów, który nie ma z rodzimy-
mi realiami praktycznie nic wspólnego, poza wprowadzonym
polskim interfejsem (choć też nie zawsze). Trudno w takich
programach wygenerować analizy przydatne dla wykonawców
i dostawców w procesach budowlanych, a z kolei wymagać
od nich dostosowania się do zachodnich wzorców też nie jest
właściwą drogą. Stąd zrozumiałe frustracje dostawców, od któ-
rych oczekuje się opracowania modelowych dla różnego typu
software’u BIM, nie tylko narzucającego im konkretne, głównie
natywne, formaty danych geometrycznych, ale i całkowicie
ignorującego wymianę danych alfanumerycznych.
7.
Przepływ danych z abstraktu
do rzeczywistości
(rys. Robert Szczepaniak,
na podstawie Bew-Richards
2005-2010)
7
