Strokovni- razpravi: Produktivni model v življenjskem ciklu gradbenega objekta Danijel Rebolj Univerza v Mariboru, Fakulteta za gradbeništvo Smetanova 17, 2000 Maribor Rebolj@uni-mb.si Izvleček Namen prispevka je pnkazati probleme in rešitve pri integraciji informacijskih tokov v življenjskem ciklu gradbenega objekta. Čeprav so mnoge posamezne faze življenjskega cikla podprte z bolj ali manj ustrezno informacijsko tehnologijo, pa ti »otoki avtomatizacije« večinoma niso ustrezno povezani, V prispevku je predstavljen že uveljavljeni koncept rešitve, ki temelji na integriranem produktnem modelu, prikazan pa je tudi primer enostavnega produktnega modela ceste in pozitivni učinki njegove uporabe, Opisane so tudi pomanjkljivosti produktnih modelov ter novi koncept »virtual-nega produktnega modela«, ki nekatere opisane pomanjkljivosti odpravlja. Abstract The intention of the paper is to present problems and solutions in integrating information flows in the life cycle of a building object. Although many life cycle phases have already been supported by more or less suitable information technology, these »islands of automation« are not suitably integrated. The paper describes an already recognized solution concept, based on the integrated product model, and explains it on a simple product model of a road. Positive effects as well as some deficiencies of product models are shown. The article ends with a description of a new concept of »virtual product model«, overcoming some of the stated deficiencies. UVOD Gradbeništvo je v kratki zgodovini računalništva v določenih trenutkih izjemno hitro vključevalo nove informacijske tehnologije v rešitve problemov. Gradbeni inženir Konrad Zuse je leta 1938 celo zgradil prvi binarni elektronsko-mehanskl računalnik Z1 (Ceruzzi 1981) tudi zato, da bi lahko z njim reševal statične probleme vse kompleksnejših konstrukcij. Programski jezik FORTRAN je sredi 30-ih let odprl možnost praktične uporabe računalnikov mnogim inženirjem in v gradbeništvu je nemogoče postalo mogoče, predvsem na področju numeričnih analiz, postopoma pa tudi na drugih področjih (Fenves 1996). Tako so posamezni procesi v gradbeništvu postopoma dobivali računalniško podporo, ti t.i, otoki avtomatizacije pa so se vse bolj širili (Hannus 1998). Zal v realnem okolju veliko počasneje, kot v raziskovalno razvojnih centrih, kjer se je za področje uporabe informacijskih tehnologij v gradbeništvu postopoma oblikovalo ime gradbena informatika (Bauinformatik v nemščini in Construction Information Technology v angleščini, kjer sov uporabi še nekateri drugi izrazi), Razlogov, da se je gradbena informatika v industriji uveljavlja počasneje kot na nekaterih drugih področjih je več: enkratnost izdelkov, razpršenost proizvodnje, raznolikost in množičnost vključenih podjetij itd. Mnogi avtorji so te posebnosti analizirati in skušali zastaviti smernice za učinkovitejši razvoj gradbene informatike {Bjork, 1999). V realnem okolju so posamezni procesi v gradbeništvu med seboj povezani, saj se vsi nanašajo na skupen izdelek, gradbeni objekt. Vsak proces ima svojo vlogo in položaj v življenjskem ciklu izdelka, procese pa povezujejo informacijski tokovi, ki temeljijo na bolj ali manj Strukturiranih podatkih. Še najpogosteje se podatki prenašajo v klasični obliki načrtov na papirju, kar onemogoča avtomatizacijo prenosa informacij iz ene faze življenjskega cikla V drugo. V široki uporabi je tudi prenos podatkov v digitalnih oblikah, ki temeljijo predvsem na standardih za vektorski opis grafičnih podatkov (npr, PXF), vendar se pri teh prav tako pojavljajo velike težave. Gradbene konstrukcije so namreč zelo kompleksne, prav tako pa tudi podatkovne strukture, s katerimi jih predstavljamo. Standardi, ki se uporabljajo za prenos podatkov, večinoma niso sposobni predstavljanja kompleksnih podatkovnih struktur v celoti, tako da se tudi digitalni zapisi omejujejo na enostavne risbe in sezname, velik del informacij pa se pri tem izgubi. Sistematično povezovanje računalniških programov, ki podpirajo posamezne procese v življenjskem ciklu 1999 - številka 4 ■ letnik VII i ijainifcr wil nformat ika Strokovni- razpravi: izdelka in so jedro otokov avtomatizacije, je predmet mnogih raziskovalnih in razvojnih projektov v zadnjih dvajsetih letih. Dober pregled nekaterih projektov podajata Brandon in Betts (Brandon 1995). Glede na način povezovanja programov lahko metode razdelimo v naslednje skupine; ■ Povezovanje različnih programskih paketov s pomočjo bolj ali manj inteligentnih podatkovnih vmesnikov. Primer je metoda »software fixing« (Syal 1991), pri kateri se uporabljajo informacijski inter-preterji, ki razpoznavajo določene podatkovne strukture in jih prilagajajo ustreznim programom. Te metode ne omogočajo tekočega pretoka informacij, vključevanje novih programov pa je oteženo, ker je potrebno za vsakega izdelati nov podatkovni vmesnik. ■ Uporaba posebnega medija za prenos informacij med programi. Znana je metoda »blackboard« {Yau 1991), ki za komunikacijo uporablja skupno »tablo« in preko nje tekoč pretok informacij. Tega omogoča tudi metoda objektnih lupin »Object Shell« (Rebolj 1993), vendar pri obeh metodah ostaja težava z vključevanjem novih programov, ■ Koncept integrirane baze podatkov temelji na skupnem viru podatkov, ki ga uporabljajo vsi vključeni programi. Znanih je več projektov, v katerih je bil uporabljen koncept integrirane podatkovne baze: RATAS (Bjiirk 1998), ATLAS (ATLAS 1992), COMBINE (Augenbroe 1993), COMBI (Ammerman 1994), v zadnjem času pa npr. SPACE in OSCON, ki sta služila kot izhodišče za trenutno verjetno najbolj tehnološko razvito integrirano okolje v gradbeni industriji (Faraj 1999), Med zgodnejše, vendar manj znane sisteme sodi tudi Gradbeniški informacijski sistem z enotno geometrijsko-konstrukcijsko bazo podatkov (Rebolj 1990). Mnogi avtorji so podali pregledne opise naštetih in tudi drugih projektov in sistemov {A mor 1998, Eastman 1998). Integrirana baza podatkov velja danes kot najučinkovitejša povezava računalniških programov v življenjskem ciklu gradbenega objekta. Vsebina podatkovne baze zajema celovit opis produkta, zato takšnemu podatkovnemu modelu pravimo tudi produktni model. PRODUKTNI IN PROCESNI MODELI V GRADBENIŠTVU Osnovni namen produktnega modela gradbenega objekta je izboljšati in avtomatizirati prenos podatkov med različnimi aplikacijami, ki so v uporabi v različnih procesih življenjskega cikla objekta (Slika J). Koncept integrirane podatkovne baze produkta temelji predvsem na dveh bistvenih predpostavkah: 1. vsi vključeni programi za izmenjavo informacij uporabljajo sintaktično in semantično enak način opisovanja podatkovnih struktur, 2, skupen upravljalski sistem podatkovne baze skrbi za integriteto podatkov in s tem zagotavlja usklajenost informacijskih tokov. Za zagotavljanje prvega pogoja so informatiki, ki so se ukvarjali z modeliranjem objektov na različnih inženirskih področjih, razvili metode za modeliranje in opisovanje kompleksnih podatkovnih struktur in jih tudi standardizirali. Tako je leta 1994 nastal mednarodni standard za izmenjavo podatkov STEP, STandard for the Exchange of Product model dala (ISO 1994), ki omogoča opis poljubnih gradnikov in struktur, kijih ti i i □ □ □ urejanje prostora i_ □ konstruiranje inštalacije arhitektura Povezava je lahko: - neposredna ali ------- posredna vmesnik za izmenjavo produktnih podatkov in nadzor dostopa produktni model | gradbenega objekta P—~ vodenje proiekta spremljanje gradnje 48 Slika 1. Vloga produktnega modela gradbenega objekta (Center ?a gradbeno informatiko). opombi iitINFORMATIKA 1999- Številka A - letnik VII Strokovni- razpravi: sestavljajo. Standard je bil uspešno uporabljen predvsem pri zelo velikih projektih {Hardwick 1997), vendar še ni doživel široke uporabe, saj ga večina ustreznih programov ne podpira. Odprto pa je ostalo tudi vprašanje definicije osnovnih gradnikov kompleksnih struktur, ki so ga na posameznih področjih reševali ločeno. Tudi v gradbeništvu, kjer obstajajo posebni aplikacijski protokoli STEP-a za opisovanje elementov gradbenih konstrukcij (npr. AP 225, ki z eksplicitno oblikovno predstavitvijo opisuje gradnike konstrukcij). Ti aplikacijski protokoli se razvijajo počasi in zato ne doživljajo pravega zanimanja. Pa bi pospešila standardizacijo osnovnih gradnikov, se je mednarodna skupnost za skladnost delovanja 1AI (International Alliance for Interoperability) lotila izdelave svojega standarda IPC, Industry Fundation Classes (Liebich 1999). IPC je zbirka gradnikov /.a področje gradbeništva, ki upošteva standard STEP. Po drugi strani je IPC tudi določeno razhajanje od sicer povsem odprtega standarda STEP, saj zapira zbirko gradnikov v meje partnerjev I Al, med katere sodijo predvsem veliki proizvajalci programske opreme. Seveda je jasno, da morajo biti gradniki do neke ravni enolično definirani, saj sicer ne bi obstajal skupen jezik za izmenjavo informacij. Vprašanje pa je, do katere ravni abstrakcije je poenotenje smiselno. Vprašanje je tudi, ali je takšno mejo sploh mogoče postaviti. Na področju pisav npr. še vedno ni jasno, ali je za zapis informacij primernejša pisava, ki temelji na simbolih (kitajske in japonske pismenkc), ali tista, ki temelji na glasovih (črkovne pisave). Katera je manj omejujoča in katera bolj izrazna? V zadnjem času se je na področju internetne tehnologije pojavil še je/.ik XML, s katerim je mogoče opisati tudi produktne modele Ker XML obeta zelo široko uporabo, se postavlja vprašanje, ali ne bi bilo smiselno tudi produktne modele opisovati z njim. Drugi problem integrirane podatkovne baze je usklajenost podatkov. To je mogoče zagotoviti le, če je znana projektna shema. Projektna shema namreč določa zaporedje izvajanja procesov v življenjskem ciklu objekta, povezave med njimi, odgovornost in pristojnost za določen del podatkov ipd. Takšni shemi pravimo tudi procesni model in ga tudi lahko opišemo z nekaterimi standardnimi tehnikami {npr. EXPRESS, 1DEE0 ali UML). Tako je tudi v gradbeni informatiki nesporno dejstvo, da je za uspešno uporabo produktne-ga modela nujna povezava s procesnim modelom, ki vključuje četrto razsežnost - čas. Integrirane produktno-procesne modele imenujemo tudi 4D modeli (Aalami in Fischer 199«). Razvoj produktnih in procesnih modelov je v veliki meri usmerjal tudi hkraten razvoj informacijskih tehnologij, predvsem tistih vezanih na internet. To dejstvo ne preseneča, saj velik del težav pri integraciji infor- 1999 številka4-letnikVII madjskih tokov v gradbeništvu izhaja prav i/ prostorske razpršenosti procesov. Tehnologija odjemalec-strežnik, ki se je kasneje razvila v 3 plastni model porazdeljene obdelave podatkov, je danes dovolj zrela za praktično uporabo» čeprav je razvoj Še vedno v intenzivnem teku. Večina projektov, ki poskuša implementirati koncept porazdeljene uporabe produktnih modelov (npr. Faraj et al. 1999), uporablja tehnologijo ČORBA (Common Object Request Broker Architecture), saj je neodvisna od operacijskega okolja računalnikov. PRODUKTNI MODEL CESTNEGA TELESA Za veliko večino znanih programov, ki so v uporabi pri gradnji cest, so značilne slabo povezane ali sploh nepo vezane podatkovne strukture, ki so povsem podrejene konvencional nemu postopku načrtovanja cest. Še posebej to velja za nadgradnje različnih univerzalnih CAD-programov, ki vključujejo dodatne specializirane funkcije za načrtovanje cest in so usmerjene predvsem v izdelavo risb - načrtov. Obstajajo pa tudi programi, ki imajo za osnovo ustrezen celovit model ceste - podatkovne strukture torej, v katerih so med seboj povezani osnovni gradniki kot so os ceste, elementi prečnih profilov in teren. Programov, ki bi vsebovali celovit model ceste, je precej manj in so praviloma zaprti. To pomeni, da svojega modela ne znajo posredovati drugim programom brez znatne izgube informacij, ki je značilna za pretvorbo v široko podprte standardne opise podatkovnih struktur - predvsem geometrijskih {npr, DXF). Novi standardi na področju izmenjave informacij (STEP, IFC) ponujajo veliko več možnosti za celovitejše opisovanje modelov gradbenih objektov - tudi cest. Vendar jedo njihove učinkovite uporabe dolga pot, na katero je raziskovalna skupina avtorja prispevka stopila v začetku 90-ih let. Velik del tega časa je bil posvečen integraciji računalniško podprtih procesov življenjskih ciklov gradbenih objektov, še posebej cest. Izdelali smo enostaven, odprt produktu i model ceste, ki ga je zelo lahko uporabiti. Model cestnega telesa ali MCT, kot smo ga poimenovali, nam služi kot izhodišče za izboljšanje izmenjave podatkov med obstoječimi programi, ki podpirajo različne faze v življenjskem ciklu ceste (Rebolj 1999). Tudi za tlorisni prikaz osi ceste lahko rečemo, tla je model ceste. Vendar tak prikaz predstavlja le izsek iz celotne strukture. O integriranem modelu objekta pa lahko govorimo šele tedaj, ko vključuje vse bistvene komponente objekta in povezave med njimi. Marsikateri CAD-program za ceste vključuje vse potrebne komponente, vendar so povezave med njimi skrite v programu samem in ne v modelu - ali pa jih v računalniku sploh ni in jih ustvari človek v svojem umu. Seveda lahko model ceste definiramo širše ali ožje - odvisno od faze življenjskega cikla alt vidika, s katerega cesto opazujemo. V Npom&ndNFORMATHiA Strokovni- razpravi: Slika 2. Sinteza projekcij osi in prečnih profilov-osnovnih gradnikov modela ceste (Center za gradbeno informatiko). fazi priprave zemljišča je lahko bistvena komponenta modela poligon, ki predstavlja obod cestnega telesa, v fazi izgradnje je to tehnologija, vezana na določeno aktivnost v terminskem planu gradnje, za vrednotenje investicije so pomembni ekonomski vplivi, za ugotavljanje vplivov na okolje pa prometni tok. MCT izhaja iz faze geometrijskega načrtovanja, saj je oblika osnovna lastnost in funkcija ceste. Model je objektno zasnovan in odprt, kar nam omogoča postopno dopolnjevanje z elementi, ki so potrebni v drugih fazah življenjskega cikla. Da bi omogočili največjo možno kompatibilnost z razširjenimi računalniškimi programi, smo ohranili temeljno strukturo modela, ki izhaja iz konvencionalnega postopka načrtovanja cest. Slika 2 še najbolj nazorno prikazuje jedro MCT, v katerega sta med drugim vključeni horizontalna in vertikalna projekcija osi ter opis prečnih profilov. Zunanja predstavitev MCT, ali kratko mCT (me ta da g to teka cestnega telesa), je namenjena predvsem izmenjavi podatkov med obstoječimi programi, ki so vključeni v življenjski cikel ceste. Prvi korak v našem pristopu je bila preprosta metadatoteka, za katero je mogoče hitro in enostavno izdelati vmesnike za branje in pisanje ustreznih podatkov v programske pakete vseli vrst in iz njih, ki jih uporabljajo v mnogih različnih birojih in podjetjih, vključenih v cestne projekte. Z vmesnikom mCT so že opremljeni nekateri komercialni programi (npr. program za načrtovanje geometrije ceste Plateia), Za demonstracijo uporabe MCT in zapolnitev nekaterih avtomatizadjskih lukenj smo izdelali Okolje za podporo življenjskega cikla ceste (ali kratko RO), ki vključuje več funkcionalnih modulov v obliki strežnikov (Slika 3). Slika 3, Osnovna arhitektura okolja RO (Center za gradbeno informatiko). iipombndNfORMATIKA 1999-številka 4-letnik VII Strokovni- razpravi: Produktni podatki MCT so odjemalcem na voljo v relacijski podatkovni bazi (RDD), okolje pa zajema tudi prostorske podatke, ki so na voljo preko strežnika prostorske podatkovne baze {SDB), Mnogi funkcionalni strežniki namreč vsebujejo funkcije geografskih informacijskih sistemov {GTS). V okolju RO so trenutno na voljo naslednji funkcionalni strežniki, ki vsi uporabljajo de! podatkovne strukture, definirane v MCT: ■ definicija koridorja {upoštevaje ustrezne geografske podatke poiščemo optimalni geografski koridor za novo cesto), ■ spremljanje odkupa zemljišč (generiramo obod cestnega telesa s skrajnimi zunanjimi točkami prečnih profilov ter z njim prekrijemo parcele v ustrezni geografski temi - Slika 4), m izračun emisij škodljivih snovi {uporabimo prostorsko predstavitev osi, ki jo generiramo iz projekcij v modelu, dodatno pa moramo navezati ustrezne prometne podatke) in ■ hitra 3D vizualizacija (generiramo 3D geometrijski model ter s tem omogočimo hitro vizualno presojo trase; 3D vizualizacijo smo implementirali tudi v obliki samostojnega programa, ki iz mCT izdela VRML datoteko (virtual reality markup language, I lartman in Wernecke 1996), primerno za objavo na svetovnem spletu - Slika 5). Pri uvajanju okolja RO smo lahko ugotovili, da je problem pri povezavi različnih programov, ki podpirajo različne faze v življenjskem ciklu ceste, predvsem konceptualen in organizacijski in ne toliko tehnološki. Prikaz prihrankov zaradi zmanjševanja zastojev in težav, ki so sicer značilni za konvencionalno pripravo vhodnih podatkov za posamezen računalniški program, je bil povsod dobro sprejet. Zataknilo pa se je pri uvajanju produktnega modela v vsakdanjo prakso, saj je v življenjski cikel ceste vključenih več med seboj slabo povezanih samostojnih podjetij. Nekaj očitkov smo doživeli zaradi enostavnosti modela. Pri tem pa je zanimivo, da že iz tako enostavnega modela z lahkoto izpeljemo podatke za celo vrsto aplikacij, za katere je sicer potrebno dolgotrajna priprava (npr. 3D predstavitev, obodni poligon ceste, itd.). Menimo, da visoka učinkovitost enostavnega modela dokazuje pravilno usmeritev, model pa tudi že izboljšujemo, širimo in pri tem preizkušamo različne standarde (STEP, XML), Po drugi strani je implementacija enostavnega modela veliko lažja - upoštevati je namreč potrebno obstoječe računalniške programe. Že pn uvajanju enostavnega modela smo naleteli med uporabniki v praksi na velike težave in sprašujemo se ali ne bi bile te težave v primeru »vsevključujočega«, visoko kompleksnega modela, nepremostljive. •m RO ■ ipiemlranje odkupa zemljišč Cesta Parcele Vtnilev i* Slika 4. Spremljanje odkupa zemljišč na osnovi prekrivanja parcel z ohodoni ceste (Center za gradbeno informatiko), 1999 ■ Številka 4 • letnik VII iqxtmbnd NFORM ATIKA Strokovni- razpravi: O C:\Fiojokti\VFIML\PnmBi.wil (local) - Micioiofl Intelnet Exploier FJe £dil View Favorite* Help o o s a Back Slop Rcl/itih Home liri nfo rm at ika 1999-Številka 4-letnik VII