W ostatnich latach tematyka BIM coraz częściej pojawia się na łamach prasy fachowej, w mediach cyfrowych i podczas wielu konferencji na terenie całego kraju. Zwykle jednak nie wspomina się przy tym o „drugiej połówce” procesu zintegrowanego w zadaniach budowlanych – IPD (Integrated Project Delivery – Zintegrowany Proces Inwestycyjny) – odpowiadającej za dystrybucję i ewaluację wymodelowanej w procesie BIM wielowymiarowej informacji pomiędzy wszystkimi uczestnikami inwestycji.
IPD opiera się na socjalnych umiejętnościach kooperacji i na technologicznym know-how w zakresie obsługi formatów danych, dostarczonych przez wszystkich projektantów w procesie. Są dwa rodzaje takich danych: natywne i otwarte. Jak dotąd dokumentacja żadnego z formatów natywnych nie ujrzała światła dziennego dla zwykłego użytkownika. Format natywny jest formatem zamkniętym, producent jest go w stanie zmienić, zastąpić innym lub nawet zarzucić, bez podawania przyczyn. Jest to więc taki „black box” – a pamiętamy, jakie kłopoty mogą być związane z tzw. czarnymi skrzynkami. Nawet powszechny format wymiany informacji w CAD, o nazwie DWG, nie posiada żadnej publicznej dokumentacji. Z tego też powodu – i również dlatego, że istnieją nań nakładki, niebędące własnością Autodesku – próba opatentowania formatu DWG w 2006 r. przez koncern została ostatecznie odrzucona przez Sąd Patentowy USA w czerwcu 2011 r., z argumentacją: „DWG is merely descriptive of applicant’s goods under Section 2(e) (1) of the Trademark Act for two reasons: (1) DWG is a recognized abbreviation for „drawing”, and (2) .dwg is a file format used for computer-aided design (CAD) drawings made both with applicant’s CAD software and others’ CAD software”. Mimo że Autodesk odwołał się od tej decyzji, Sąd Patentowy (USPTO) podtrzymał w 2013 r. swój werdykt.
Publiczny format jest standardem otwartym, dobrze udokumentowanym i z przeprowadzoną tzw. inżynierią wsteczną, w celu kontroli procesu powstawania danych i dla zapewnienia jego bezpieczeństwa.
Formatem natywnym jest zapis informacji z konkretnego software danego producenta, oparty na rezultatach rozwoju własnej technologii, chronionej tajemnicą firmową i prawami autorskimi tegoż producenta.
Industry Foundation Classes
W 1994 Autodesk, wraz z kilkunastoma firmami zgrupowanymi w konsorcjum pod nazwą Industry Alliance for Interoperability, rozpoczął pracę nad wspólnym formatem wymiany plików dla geometrii 3D i związanych z nią danych alfanumerycznych. Format ten, zapisany w języku modelowania danych EXPRESS, nazwano IFC (Industry Foundation Classes) i oparto go na standardzie STEP (Standard for the Exchange of Product model data, ISO 10303), uznanym za niewystarczający dla przekazania całości oczekiwanej informacji. W 1997 r. nastąpiła zmiana nazwy konsorcjum na International Alliance for Interoperability, a w 2005 r. ukształtowała się obecna nazwa – buildingSMART. (rys. 1 – zasada IFC).
W 2002 r., po nabyciu Revita, Autodesk odwrócił się od poparcia dla formatu IFC. Żaden z dokumentów reklamowych Autodesku z okresu między 2003 a 2011 r. nie zawiera wzmianki o IFC jako możliwym formacie wymiany danych dla BIM, który to termin właśnie się wtedy wykluł. Dopiero stopniowe przyjęcie w niemal całej Skandynawii IFC jako obowiązującego formatu wymiany danych, a zwłaszcza zapowiedziane od 2012 r. decyzje rządu brytyjskiego ustanawiające IFC podstawowym formatem wymiany informacji geometrycznej i niegeometrycznej w standardzie BIM dla zleceń publicznych od 4 kwietnia 2016 r. (a więc od kilku tygodni już oficjalnie w mocy) skłoniły Autodesk do ponownego zajęcia się tym formatem dla importów i eksportów modeli wielowymiarowych (3D / 4D / 5D itp.) (rys. 2 – atlas BIM).
Kod źródłowy translatora IFC został w międzyczasie przekazany przez Autodesk użytkownikom jako dobro publiczne (GPL – General Public License) i sami użytkownicy zaprogramowali jego funkcjonującą wersję, m.in. do Revita LT (Limited Technology), jako jedyną opcję interoperacyjności (wymiany z dowolnym programem, nie wyłączając innych produktów samego Autodesku) w tym software. W międzyczasie powstały także translatory samego producenta – ocenę ich jakości i porównanie z w/w translatorami otwartymi pozostawiam samym użytkownikom.
Zaprogramowanie translatora IFC przez kogokolwiek było możliwe dlatego, że istnieje pełna dokumentacja formatu, oparta na normie ISO 16739, aktualna wersja z 2013 r. Tylko taka forma standardu jest gwarantem bezpieczeństwa danych na dziesięciolecia i niezależnie od software, które służy do otwarcia modeli IFC. Pełną listę uczestników procesu certyfikacji formatu IFC można znaleźć na stronie: http://www.buildingsmart-tech.org/certification/ifc-certification-2.0/ifc2x3-cv-v2.0-certification/participants.
W drodze do doskonałości
Inni znaczący producenci software dla tworzenia w BIM (BIM authoring) rozpoczęli procesy certyfikacyjne wcześniej, dlatego ich funkcjonalność wymiany plików w formacie IFC mogła zostać wystarczająco przetestowana przed uzyskaniem pozytywnych efektów. Podstawową trudnością w stosowaniu IFC jest przede wszystkim import, a w nim największe kłopoty sprawia import operacji bryłowych dla geometrii standardowych, a zwłaszcza dla geometrii o tzw. „wolnej formie”.
Wiąże się to z charakterem samego software do tworzenia w procesach projektowych, które może być zarówno narzędziem modelującym wyłącznie informację inżynieryjną, tekstową (nie jest to tematem niniejszego artykułu), jak i dodatkowo modelerem informacji, także geometrycznej. A taki z kolei może mieć charakter aplikacji modelującej powierzchniowo (jak np. SketchUp, stąd zresztą taka łatwość tworzenia prezentacji w tym programie, ale jednocześnie uboga treść informacyjna modeli) lub bryłowo (pozostała większość aplikacji do tworzenia w BIM).
Co do modelerów bryłowych różnica w jakości eksportu do formatów otwartych może mieć także związek z różnicami w stopniu implementacji silnika 3D, ale nie będziemy tutaj wchodzić w aż takie szczegóły technologiczne.
Natomiast, bardzo istotnym kłopotem z plikiem w formacie natywnym jest fakt, że nawet najbardziej kompleksowe „suites” (a więc zestawy programów jednego konkretnego producenta) do projektowania w budownictwie nie zapewniają pełnej funkcjonalności dla całego procesu inwestycyjnego. Przede wszystkim pakiety dla projektantów nie obsługują ciągłości model-fabrykacja i wymagają innych, specjalistycznych software CAM (Computer Aided Manufacturing) dla samej produkcji, a więc co i raz potrzebna jest wymiana danych między różnymi programami, niekoniecznie o tym samym formacie. Różnorodność formatów jest zresztą regułą, a nie wyjątkiem, jako że aby zapisać dane w formacie innego producenta, wymagana jest licencja na jego użytkowanie, co generuje kolejne kłopoty organizacyjne i finansowe. Oczywiście znaczący producenci software próbują skupować pomniejszych wytwórców potencjalnie ciekawych aplikacji, ale integracja tychże do jednego formatu wymiany danych jest nie tylko trudna, lecz także wątpliwa z punktu widzenia ochrony przed monopolizacją.
Pod kontrolą
Istnieją zresztą instytucje, które zajmują się kontrolą wielkości zakresów rynkowych poszczególnych towarów i usług. I tak np. amerykański FTC (Federal Trade Commission) w 1997 roku umożliwił firmie Autodesk zakup konkurencyjnej dla AutoCADa technologii firmy Softdesk (ówczesnego właściciela IntelliCAD) dopiero pod warunkiem dotrzymania kilku warunków chroniących kupowaną technologię, a odpowiednia umowa została zawarta na okres 10 lat. FTC uznał, że limit 70% zasięgu rynku CAD na PC, powyżej którego można mówić o monopolu, zostałby zagrożony. Podobne instytucje kontrolują zresztą rynek Unii Europejskiej (European Antitrust Commission).
Z drugiej strony rynek software dla przemysłu budowlanego (bo nim się tu głównie zajmujemy) wydaje się kontrolować sam siebie w wystarczający sposób, zwłaszcza, że operuje na nim kilku gigantów: Autodesk (obrót w 2013 r. – $2.2 mld), Trimble (obrót w 2013 r. – $2.0 mld) oraz Nemetschek (obrót w 2013 r. – €370 mln).
Co ciekawe, zarówno Autodesk (AutoCAD, Revit Suite, Inventor, Maya itd.), jak i Trimble (ViCo, Tekla, SketchUp itd.) większość dochodów mają nie z software, ale z innych produktów i usług, a dochód firmy Nemetschek (Allplan, ArchiCAD, Vectorworks, Scia, DDS-CAD, Bluebeam, Solibri itd.) to praktycznie wyłącznie software, co, być może dla niektórych niespodziewanie, czyni tę firmę największym producentem software budowlanego na świecie.
Potrzebny wspólny język
Otwarty format IFC, zarządzany przez organizację buildingSMART, rozwija się dynamicznie poprzez pracę wielu podmiotów tej organizacji, zgrupowanych w wielu krajach i grupach krajów pod nazwą „chapters”. Mamy np. norweski chapter, ale i Nordic Chapter (Finlandia, Szwecja i Dania), przy którym zresztą Polska uzyskała w październiku 2015 r. status obserwatora. Aktualne działania polskich firm i podmiotów indywidualnych (także z udziałem autora) mają na celu uzyskanie aktywnego statusu Polish Chapter, z możliwością współpracy w tzw. Product Room. Jest to równoznaczne z aktywnym współtworzeniem standardów nomenklatury technologicznej w komputeryzacji procesów budowlanych na bazie otwartego formatu IFC. I tak np. norweska firma Catenda opracowała matrycę odwzorowań nazewnictwa budowlanego w kolejnych krajach, będących członkami buildingSMART, w formie bazy danych, interfejsu programowego oraz przeglądarki internetowej o wspólnej nazwie bSDD (buildingSMART Data Dictionary) (rys. 3 – zasada bSDD).
Polska nie posiada jeszcze takiej fizycznej nomenklatury budowlanej, którą można by odwzorować do ostatecznego abstrakcyjnego języka komputerowego IFC (istniejące niestety się do tego nie nadają). Aktywny status przyspieszyłby prace nad powstaniem takiej klasyfikacji, bez której BIM (a właściwie IPD) nie jest możliwy. Nie jest możliwy dlatego, że nie ma obecnie takiego odwzorowania, które zapewniłoby ciągłość nazewnictwa obiektów budowlanych wychodzących z komputerów projektantów, umożliwiającą jednoznaczną identyfikację z fizycznymi elementami do wbudowania w obiekty budowlane, czyli zrozumienie modeli projektantów przez wszystkich członków ekipy wykonawczej na placu budowy, producentów, dostawców i potem końcowych użytkowników. Istniejące na polskim rynku standardy są chaotyczne, z powtarzającymi się w różnych miejscach tymi samymi elementami, i nie nadają się do digitalizacji w celu odwzorowania do abstrakcyjnych standardów komputerowych, jak np. spójnego i logicznego IFC.
Żyjemy jednak w społeczeństwie nominalnie kapitalistycznym (chociaż regulacje rynkowe i forma zarządzania korporacjami temu przeczą), i mimo że buildingSMART jest organizacją non-for-profit, to jednak roczne koszty aktywnego uczestnictwa w pracach organizacji (Product Room) wynoszą dla oficjalnych podmiotów od €25 tys wzwyż.
BIMobject
Niezależnie od tego nadzieję na stworzenie platformy integrującej inteligentne obiekty przynajmniej dla projektantów i producentów ożywiło wejście na polski rynek w październiku 2015 r. portalu BIMobject. Przedstawiciele tej platformy podróżują aktualnie po Polsce i zbierają akces od producentów elementów i wyrobów budowlanych dla umieszczenia tychże obiektów w bibliotece portalu w najbardziej istotnych formatach dla software do tworzenia w BIM. Odbywa się to na zasadzie stworzenia modeli produktów w software Rhino i przy pomocy skryptu Lena, po czym ten natywny obiekt jest eksportowany do takich formatów jak RVT (Revit), GSM (ArchiCAD), VWX (Vectorworks), SKP (SketchUp) oraz IFC. Producenci nawet nie potrzebują dostarczać własnych modeli, wystarczą rysunki i opisy. BIMobject wykona za nich tę pracę we własnym zakresie. Dostęp do portalu jest darmowy dla użytkowników (głównie projektanci), producenci są zobowiązani do uiszczenia opłaty zależnie od liczby wprowadzonych produktów.
IFC w przyszłości
Różnorodność obowiązujących w oficjalnej wymianie informacji formatów natywnych jest zdaniem autora stanem przejściowym. Na dłuższą metę jednorodna struktura, pełna dokumentacja i obecna nieedytowalność, będące gwarantem zachowania praw autorskich i ochrony efektów pracy projektantów, jakie zapewnia IFC, zyskają coraz bardziej na znaczeniu. Wystarczy wspomnieć, że zestawy parametrów w obiektach IFC, tzw. Property Sets, lub w skrócie PSets, raz zapisane w jednym programie do tworzenia BIM, odczytywane są w ten sam sposób w każdym innym programie, który jest w stanie zaimportować IFC (rys. 4 – struktura IFC).
Dla wykonawców prac budowlanych i fachowców od zarządzania obiektami będzie to jednak oznaczać konieczność przyswojenia sobie metod ewaluacji plików IFC pod kątem użytkowania ich w procesach, którymi kierują lub które nadzorują czy aktywnie wykonują.
Nadal istnieją co prawda głosy deprecjonujące format IFC (chociaż głównie z tych samych źródeł), ale nie ma dla niego aktualnie żadnej znaczącej alternatywy, a powstanie w międzyczasie (następnego otwartego) formatu BCF (BIM Collaboration Format), który umożliwia raportowanie analiz modeli w czasie rzeczywistym, dodatkowo ujednolici obsługę procesów budowlanych w technologii cyfrowej. Dodatkowo otwarta forma i transparentność prac buildingSMART są kolejnymi gwarantami zachowania jakości oraz bezpieczeństwa dostępu i wymiany informacji w tym formacie na lata i dziesięciolecia. Ostatnim pozytywnym aspektem IFC jest nieedytowalność jego modeli i obiektów. Przekazywanie inwestorom (prywatnym, bo dla publicznego wymagany byłby przetarg na software do odczytania modeli) także plików natywnych oznacza udostępnienie im możliwości dowolnej edycji modeli projektowych, oczywiście pod warunkiem, że dysponują odpowiednim software. Właścicielem praw autorskich modeli są konkretni projektanci (autorskie prawa osobiste), inwestor oficjalnie może zaś jedynie nabyć prawa użytkowania modelu (autorskie prawa majątkowe), i to na określony okres. Regulują to obowiązująca w Polsce ustawa o ochronie praw autorskich (Dz.U. 1994 Nr 24 poz. 83, z późn. zmianami) i zasady cywilnej odpowiedzialności inżynierów za efekty własnej pracy (ubezpieczenia izbowe), od których nie ma wyjątków..
I choć być może przyszłe prace nad IFC wprowadzą, zapewne dla wygody projektantów, edytowalność dla umożliwienia opracowywania wspólnego modelu na wspólnej platformie rozwoju inwestycji, to w połączeniu ze zintegrowaną kontrolą dostępu i zachowaniem chronologii wersji będzie to kontrolowany proces dla dowolnego jego uczestnika, niezależnie od software, jakiego używa.
Dla specjalistów od zarządzania obiektami w zupełności wystarczą dane zapisane w modelu w formacie IFC, a zwłaszcza jego podzbiorze o ogólnej nazwie XXXie (information exchange, np. COBie – są to pliki Excel) (rys. 5 – COBie). Ewentualna oczekiwana edytowalność elementów geometrycznych modelu nie ma żadnych podstaw prawnych, a wręcz przeciwnie – wiele restrykcji. Każda próba ustalenia tu formatów natywnych będzie próbą monopolizacji rynku, i przez to obiektem badania komisji kontrolujących.
Robert Szczepaniak
Architekt (IARP/Kammer Wien)
Stowarzyszenie BIM dla polskiego budownictwa
Nemetschek Vectorworks
W artykule wykorzystano źródła:
Wyrok USPTO w/s DWG:
http://tsdr.uspto.gov/#caseNumber = 78852798&caseType = SERIAL_NO&searchType = statusSearch
http://worldcadaccess.typepad.com/blog/2011/07/no-joy-for-autodesk-as-uspto-continues-to-agree-that-dwg-is-not-registerable.html
Lista spraw patentowych USPTO (stan – listopad 2013): http://www.uspto.gov/web/offices/com/sol/og/2013/week45/TOC.html
Robercie, calkiem niezly artykul – chyba pierwszy dobry material na bimblogu! Gdybys tylko przeredegowal go, odpuszczajac opluwanie swojej konkurencji to bylby naprawde wzorcowy.
Co do IFC, to sprawa nie jest oczywista. Zrzeszenie niemieckich producentow oprogramowania inzynierskiego postanowilo nie adoptowac ich produktow do IFC, bo poczytuja to jako zagrozenie ich firm przez firmy globalne. Jak na razie przekonali rzad federalny by srandard IFC nie byl legalizowany w BRD. We Francji jest bardzo podobne postrzeganie IFC, a jak wiadomo protekcjonizm krajowych firm w tych krajach nie raz zmienial historie swiata.
grzegorz, przedstawione zostały fakty. nic nie poradzę, że producenci nie grają fair.
co do niemieckich postanowień, to ich nie znam, mogłbyś podać źródło? może być po niemiecku.
Szanowny Grzegorzu, oczywiście obiektywizm zawsze w cenie, ale człowiek pisze uczciwie, że zajmuje się VW a o ADSK nie pisze nic zdrożnego. Firma ma oczywiście w swej stajni sporo programów i między nimi dane można wymieniać przez jakiś własny format wewnętrzny, który sobie zrobili, no i faktycznie oni woleliby pewnie aby nic poza tym nie istniało, w tym także IFC, no i gdyby opanowali rynek pewnie niczego innego by nie było. Ten tekst pokazuje w fabularny sposób.
Co o dFrancji zawsze żyła we własnym świecie budowlanym, mają też problem z informatykami, bo wyjeżdżają im do USA za chlebem i np. ich edytor IFC nie jest rozwinięty. Co do francuskiej firmy Graitec czy Robobat to im je wykupili, ale ich używają oczywiście. Poza tym we Francji mocną pozycję ma Allplan, mają własne moduły krajowe, jest też grecki 4M IDEA sprzedawany tam pod jakąś inną nazwą, są też inne wątki, ale to Allplan ma spore uznanie, byłem pod wrażeniem.
Co do Niemiec, nie można stwierdzić, że coś nie gra, poza tym rozwój jest tam przemyślany (!), znam kilka narzędzi mniej znanych, które mają wsparcie IFC (ale weszli to zbyt wcześniej, jeszcze nie był czas) no a sam fakt, że Nemetchek jest tak potężną firmą w skali świata, no i właśnie niemiecką, nie pozwala stwierdzić, że czegoś tam nie ma, ale rozwój ten jest spokojny, naturalny, i nie polega na tym, że ktoś „chodzi za tym” aby ktoś wpisał do prawa jakiś obowiązek…
Tomek,
potraktuj to co napisał Grzegorz, jako prowokację i słowa bez pokrycia. To nie pierwszy jego raz u nas na blogu 🙂
Tych faktów nie znałem :), ale zawsze punkt widzenia ma znaczenie.
Napisałem bo był inny głos, na temat programu, który też warto pokazać, bo różnorodność w świecie Open BIM ma swój urok. VW co prawda próbowałem, ale jakoś do mnie nie trafia, choć cenowo jest dość atrakcyjny, ale nazywanie modelowania ogólnobudowlanego architekturą zawsze mnie odstręcza i to tylko dlatego, że w Polsce ktoś chce na to, co tak nazwie, mieć wyłączność. Sam program VW nie jest nawet winien :-), ale jest wersja VW Designer, niestety droższa, mająca jednak kilka funkcjonalności na raz. Potrzeba różnorodności, swobody, wolności, aby inżynier budownictwa na głos słowa architektura nie dostawał mdłości, wszak architektura po łacinie to budownictwo, a budynek to konstrukcja + instalacje. Ludzie pamiętajcie!!!
Dziękuję za świetny artykuł. Szczególnie za jasny i logicznie zbudowany przekaz wszystkich informacji i poprawną polszczyznę. Zresztą jak widzę kto pisał to mnie to nie powinno dziwić.
dzięki za miłe słowa.
a co do samego meritum, to spełniają się moje przypuszczenia – w ifc4 mamy dwa różne eksporty modeli do tego formatu:
– nieedytowalny ‚reference view’ jako referencję własnej pracy (czyli swego rodzaju ‚podkład’ dla pracy branżowej) oraz
– edytowalny ‚design transfer view’ jako piaskownicę testową dla dłubania w innych, otrzymanych modelach.