23 Cze 2016

BIM/IPD wymiana informacji – formaty natywne (własność producentów) i otwarte (publiczne)

W ostatnich latach tematyka BIM coraz częściej

23 Cze 2016

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 umie­jętnościach kooperacji i na techno­logicznym know-how w zakresie obsługi formatów danych, dostar­czonych przez wszystkich projektan­tów w procesie. Są dwa rodzaje ta­kich danych: natywne i otwarte. Jak dotąd dokumentacja żadnego z for­matów natywnych nie ujrzała świa­tła dziennego dla zwykłego użyt­kownika. Format natywny jest for­matem 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. czarny­mi skrzynkami. Nawet powszechny format wymiany informacji w CAD, o nazwie DWG, nie posiada żad­nej publicznej dokumentacji. Z te­go też powodu – i również dlatego, że istnieją nań nakładki, niebędące własnością Autodesku – próba opa­tentowania formatu DWG w 2006 r. przez koncern została ostatecz­nie odrzucona przez Sąd Patentowy USA w czerwcu 2011 r., z argumen­tacją: „DWG is merely descriptive of applicant’s goods under Section 2(e) (1) of the Trademark Act for two re­asons: (1) DWG is a recognized ab­breviation for „drawing”, and (2) .dwg is a file format used for com­puter-aided design (CAD) drawings made both with applicant’s CAD so­ftware 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 kilkuna­stoma firmami zgrupowanymi w konsor­cjum 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 (In­dustry Foundation Classes) i opar­to go na standardzie STEP (Standard for the Exchange of Product model data, ISO 10303), uznanym za nie­wystarczający dla przekazania cało­ści oczekiwanej informacji. W 1997 r. nastąpiła zmiana nazwy konsorcjum na International Alliance for Intero­perability, a w 2005 r. ukształtowała się obecna nazwa – buildingSMART. (rys. 1 – zasada IFC).

20160518_dod it ifc 06_po_II_page002_001

Rys.1

W 2002 r., po nabyciu Revita, Au­todesk odwrócił się od poparcia dla formatu IFC. Żaden z dokumen­tów reklamowych Autodesku z okre­su między 2003 a 2011 r. nie zawiera wzmianki o IFC jako możliwym for­macie wymiany danych dla BIM, któ­ry to termin właśnie się wtedy wy­kluł. 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 for­matem wymiany informacji geome­trycznej i niegeometrycznej w stan­dardzie BIM dla zleceń publicznych od 4 kwietnia 2016 r. (a więc od kilku tygodni już oficjalnie w mocy) skło­niły Autodesk do ponownego zajęcia się tym formatem dla importów i eks­portów modeli wielowymiarowych (3D / 4D / 5D itp.) (rys. 2 – atlas BIM).

20160518_dod it ifc 06_po_II_page002_002

Rys.2

Kod źródłowy translatora IFC zo­stał w międzyczasie przekazany przez Autodesk użytkownikom ja­ko 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ę inte­roperacyjności (wymiany z dowol­nym programem, nie wyłączając in­nych produktów samego Autodesku) w tym software. W międzyczasie po­wstały także translatory samego pro­ducenta – ocenę ich jakości i porów­nanie z w/w translatorami otwartymi pozostawiam samym użytkownikom.

Zaprogramowanie translatora IFC przez kogokolwiek było możliwe dla­tego, że istnieje pełna dokumenta­cja formatu, oparta na normie ISO 16739, aktualna wersja z 2013 r. Tyl­ko taka forma standardu jest gwa­rantem bezpieczeństwa danych na dziesięciolecia i niezależnie od so­ftware, które służy do otwarcia mo­deli IFC. Pełną listę uczestników pro­cesu certyfikacji formatu IFC można znaleźć na stronie: http://www.buil­dingsmart-tech.org/certification/ifc­-certification-2.0/ifc2x3-cv-v2.0-certi­fication/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 przete­stowana przed uzyskaniem pozy­tywnych efektów. Podstawową trud­nością w stosowaniu IFC jest przede wszystkim import, a w nim najwięk­sze kłopoty sprawia import opera­cji bryłowych dla geometrii standar­dowych, 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ów­no narzędziem modelującym wyłącz­nie informację inżynieryjną, teksto­wą (nie jest to tematem niniejszego artykułu), jak i dodatkowo modele­rem informacji, także geometrycznej. A taki z kolei może mieć charak­ter aplikacji modelującej powierzch­niowo (jak np. SketchUp, stąd zresz­tą taka łatwość tworzenia prezentacji w tym programie, ale jednocześnie uboga treść informacyjna modeli) lub bryłowo (pozostała większość aplika­cji 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 implementa­cji silnika 3D, ale nie będziemy tutaj wchodzić w aż takie szczegóły tech­nologiczne.

Natomiast, bardzo istotnym kło­potem z plikiem w formacie natyw­nym jest fakt, że nawet najbardziej kompleksowe „suites” (a więc ze­stawy programów jednego konkret­nego producenta) do projektowania w budownictwie nie zapewniają peł­nej funkcjonalności dla całego pro­cesu inwestycyjnego. Przede wszyst­kim pakiety dla projektantów nie obsługują ciągłości model-fabry­kacja i wymagają innych, specjalistycznych software CAM (Compu­ter Aided Manufacturing) dla samej produkcji, a więc co i raz potrzebna jest wymiana danych między różny­mi programami, niekoniecznie o tym samym formacie. Różnorodność for­matów jest zresztą regułą, a nie wy­jątkiem, jako że aby zapisać dane w formacie innego producenta, wy­magana jest licencja na jego użytko­wanie, co generuje kolejne kłopoty organizacyjne i finansowe. Oczywi­ście znaczący producenci softwa­re próbują skupować pomniejszych wytwórców potencjalnie cieka­wych aplikacji, ale integracja tychże do jednego formatu wymiany da­nych jest nie tylko trudna, lecz także wątpliwa z punktu widzenia ochro­ny przed monopolizacją.

Pod kontrolą

Istnieją zresztą instytucje, które zaj­mują 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 za­kup konkurencyjnej dla AutoCADa technologii firmy Softdesk (ówcze­snego właściciela IntelliCAD) dopie­ro pod warunkiem dotrzymania kil­ku 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 (Euro­pean Antitrust Commission).

Z drugiej strony rynek software dla przemysłu budowlanego (bo nim się tu głównie zajmujemy) wydaje się kontrolować sam siebie w wystarcza­jący sposób, zwłaszcza, że operuje na nim kilku gigantów: Autodesk (obrót w 2013 r. – $2.2 mld), Trimble (ob­rót w 2013 r. – $2.0 mld) oraz Nemet­schek (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 pro­duktów i usług, a dochód firmy Ne­metschek (Allplan, ArchiCAD, Vec­torworks, 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 organiza­cji, zgrupowanych w wielu krajach i grupach krajów pod nazwą „chap­ters”. Mamy np. norweski chap­ter, ale i Nordic Chapter (Finlandia, Szwecja i Dania), przy którym zresz­tą Polska uzyskała w październiku 2015 r. status obserwatora. Aktual­ne działania polskich firm i podmio­tó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ównoznacz­ne z aktywnym współtworzeniem standardów nomenklatury techno­logicznej w komputeryzacji proce­sów budowlanych na bazie otwarte­go formatu IFC. I tak np. norweska firma Catenda opracowała matrycę odwzorowań nazewnictwa budowla­nego w kolejnych krajach, będących członkami buildingSMART, w formie bazy danych, interfejsu programo­wego oraz przeglądarki internetowej o wspólnej nazwie bSDD (building­SMART Data Dictionary) (rys. 3 – za­sada bSDD).

20160518_dod it ifc 06_po_II_page004_001

Rys.3

Polska nie posiada jeszcze takiej fizycznej nomenklatury budowla­nej, 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 pra­ce nad powstaniem takiej klasyfika­cji, 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 bu­dowlanych wychodzących z kompu­terów projektantów, umożliwiającą jednoznaczną identyfikację z fizycz­nymi elementami do wbudowania w obiekty budowlane, czyli zrozu­mienie modeli projektantów przez wszystkich członków ekipy wyko­nawczej na placu budowy, producen­tów, dostawców i potem końcowych użytkowników. Istniejące na pol­skim rynku standardy są chaotycz­ne, z powtarzającymi się w różnych miejscach tymi samymi elementami, i nie nadają się do digitalizacji w ce­lu odwzorowania do abstrakcyjnych standardów komputerowych, jak np. spójnego i logicznego IFC.

Żyjemy jednak w społeczeństwie nominalnie kapitalistycznym (cho­ciaż regulacje rynkowe i forma za­rządzania korporacjami temu prze­czą), i mimo że buildingSMART jest organizacją non-for-profit, to jednak roczne koszty aktywnego uczestnic­twa w pracach organizacji (Product Room) wynoszą dla oficjalnych pod­miotó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ży­wiło wejście na polski rynek w paź­dzierniku 2015 r. portalu BIMobject. Przedstawiciele tej platformy po­dróżują aktualnie po Polsce i zbie­rają akces od producentów elemen­tów i wyrobów budowlanych dla umieszczenia tychże obiektów w bi­bliotece portalu w najbardziej istot­nych formatach dla software do two­rzenia w BIM. Odbywa się to na zasadzie stworzenia modeli produk­tów w software Rhino i przy pomo­cy skryptu Lena, po czym ten na­tywny obiekt jest eksportowany do takich formatów jak RVT (Re­vit), GSM (ArchiCAD), VWX (Vec­torworks), SKP (SketchUp) oraz IFC. Producenci nawet nie potrze­bują dostarczać własnych mode­li, wystarczą rysunki i opisy. BIMo­bject wykona za nich tę pracę we własnym zakresie. Dostęp do porta­lu 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 informa­cji formatów natywnych jest zda­niem autora stanem przejściowym. Na dłuższą metę jednorodna struk­tura, pełna dokumentacja i obecna nieedytowalność, będące gwaran­tem zachowania praw autorskich i ochrony efektów pracy projektan­tów, jakie zapewnia IFC, zyskają co­raz bardziej na znaczeniu. Wystarczy wspomnieć, że zestawy parame­trów w obiektach IFC, tzw. Property Sets, lub w skrócie PSets, raz zapisa­ne w jednym programie do tworze­nia BIM, odczytywane są w ten sam sposób w każdym innym programie, który jest w stanie zaimportować IFC (rys. 4 – struktura IFC).

20160518_dod it ifc 06_po_II_page004_002

Rys.4

Dla wykonawców prac budowla­nych i fachowców od zarządzania obiektami będzie to jednak oznaczać konieczność przyswojenia sobie me­tod 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 de­precjonują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 otwar­tego) formatu BCF (BIM Collabora­tion Format), który umożliwia ra­portowanie analiz modeli w czasie rzeczywistym, dodatkowo ujednoli­ci obsługę procesów budowlanych w technologii cyfrowej. Dodatko­wo 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 inwesto­rom (prywatnym, bo dla publiczne­go wymagany byłby przetarg na so­ftware do odczytania modeli) także plików natywnych oznacza udostęp­nienie im możliwości dowolnej edy­cji modeli projektowych, oczywiście pod warunkiem, że dysponują od­powiednim software. Właścicielem praw autorskich modeli są konkret­ni projektanci (autorskie prawa oso­biste), inwestor oficjalnie może zaś jedynie nabyć prawa użytkowania modelu (autorskie prawa majątko­we), i to na określony okres. Regulu­ją to obowiązująca w Polsce ustawa o ochronie praw autorskich (Dz.U. 1994 Nr 24 poz. 83, z późn. zmiana­mi) i zasady cywilnej odpowiedzial­noś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 plat­formie rozwoju inwestycji, to w po­łączeniu ze zintegrowaną kontrolą dostępu i zachowaniem chronologii wersji będzie to kontrolowany proces dla dowolnego jego uczestnika, nie­zależnie od software, jakiego używa.

02

Rys.5

Dla specjalistów od zarządzania obiektami w zupełności wystarczą dane zapisane w modelu w forma­cie IFC, a zwłaszcza jego podzbio­rze o ogólnej nazwie XXXie (infor­mation exchange, np. COBie – są to pliki Excel) (rys. 5 – COBie). Ewen­tualna oczekiwana edytowalność ele­mentów geometrycznych modelu nie ma żadnych podstaw prawnych, a wręcz przeciwnie – wiele restryk­cji. Każda próba ustalenia tu forma­tów natywnych będzie próbą mono­polizacji 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&case­Type = SERIAL_NO&searchType = statusSearch
http://worldcadaccess.typepad.com/blog/2011/07/no-j­oy-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/we­ek45/TOC.html

Leave a comment
More Posts
Comments
  1. Grzegorz Lipiec 2nd, 2016 5:48AM

    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.

  2. gester Lipiec 3rd, 2016 1:44AM

    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.

  3. Tomasz Wiatr Październik 7th, 2016 3:09PM

    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…

  4. admin Październik 8th, 2016 6:14PM

    Tomek,

    potraktuj to co napisał Grzegorz, jako prowokację i słowa bez pokrycia. To nie pierwszy jego raz u nas na blogu 🙂

    • Tomasz Wiatr Październik 8th, 2016 6:49PM

      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!!!

  5. ravscin Październik 18th, 2016 1:43PM

    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ć.

  6. gester Październik 24th, 2016 10:32PM

    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.

Comment