Lisää kivoja kolmikirjaimisia lyhenteitä, kuten IPD ja VDC

On mielenkiintoista, että jotkut järkevät asiat lyhennetään yleensä kolmikirjaimisina. Esim. IFC, BIM ja kaikenlaiset muut pikkujutut.

Muutaman vuoden ajan yllämainittuihin lyhenteisiin on liitetty myös toisenlaisia asioita - IPD ja VDC. Toivon todella, että näiden lyhenteiden takana oleva ajatus löisi itsensä läpi suomalaisessa rakentamisessa ja muuttaisivat rakennusten hankinta-, tilaus-, suunnittelu- ja rakentamiskulttuuria.

Integrated Project Delivery tarkoittaa raa'asti sitä, että aloitetaanpa rakennuksen suunnittelu siten että suljetaan kaikki päätekijät lukittuun isoon huoneeseen ja avataan ovi kolmen päivän välein. Tai neljän - tai viiden.

No, oikeasti siis suunnitellaan siten, että paikalla on tilaaja, käyttäjä, suunnittelijat, rakentajat jne. eli kaikki osapuolet, jotka ovat tekemisissä kokonaisuuden kanssa. Näissä tilaisuuksissa siirretään suunnittelua ja ratkaisuntekopäätöksiä voimakkaasti alkusuunnitteluun. Voidaan jopa sanoa, että hankevaiheen aikana tapahtuu huomattavasti enemmän pienemmässä ajassa. Ehdotussuunnitteluvaihe käydään "lukitun" tilan sisällä keskenäiseesti läpi. Laskelmia tehdään, BIMiä käytetään hyödyksi sen äärirajoilla. Valitaan ratkaisuja kokonaistaloudellisin perustein, ei pelkästään siksi, että joku osapuoli saisi siitä 0.2% taloudellisen voiton.

Tehdään siis yhdessä töitä parhaan lopputuloksen saamiseksi annetuilla reunaehdoilla.

Kuulostanee utopistiseltä, idealistiseltä ja vaikealta.

Paitsi jos sattuu olemaan edistyksellistä porukkaa ajattelemassa, kuten Silicon Valleyssä.

Olen päässyt seuraamaan muutaman tovin rakennusfirman nimeltä DPR touhuja tuolla alueella. Heidän "neljän tason BIM" on suoraa myyntipuhetta siitä, miten asioita pitäisi tehdä.

Ja epäamerikalliseen tapaan he ovat myös tehneet, eivätkä vain puhuneet. Yhtenä esimerkkinä toteutuneesta IPD projektista Sutter Healthille tehty Sutter Medical Center, jossa on käytetty IPD:n periaatteita. Rakennusta tehdään tällä hetkellä (2011) ja sen valmistuu joulukuussa 2013. On hienoa nähdä tämän rakennuksen ympärillä oleva innostuneisuus. Sutter Health (siis tilaaja) pitää kohteesta omaa blogia, jossa sisältöäkin tuotetaan hyvää tahtia.

IPD:n edut on siis tässä esimerkissä hahmottanut rakennusyhtiö. He ovat tajunneet, että he saavat tällä menetelmällä parhaan taloudellisen hyödyn kokonaisuudesta. Siinä samalla tilaaja ja käyttäjäkin saavat toimivan rakennuksen - sellaisen jonka ovat halunneet.

Mitä tämä vaatii? se vaatii työtä, tilaajan ja käyttäjän paneutumista rakentamiseen, vahvaa projektinvetäjää ja koko IPD ryhmän kykyä tehdä päätöksiä kun on niiden aika.

Ennenkaikkea se vaatii uusia sopimusmalleja ja riskinottokykyä koko IPD-ryhmälle. Olin tilaisuudessa, jossa DPR:n Dean Reed esitteli heidän IPD konseptiaan. Yhtenä tärkeimpänä asiana esityksessä oli sopiminen taloudellisesta hyödystä. Itse suunnittelu- / rakentamistekniikka on ammattilaisten kanssa yksinkertaista. Ongelma on sopia juridisesti, ketä saa taloudellisen hyödyn. Kun nämä asiat on sovittu, aukeaa uusi maailma avoimille ajatuksille siitä, miten saadaa paras lopputulos tilaajalle ja käyttäjälle. Voin kertoa, että malli tähän on olemassa ja se kuulosti erinomaisen fiksulta.

DPR on kummallinen firma. Jotkut jenkeissä vaikuttavat tahot sanovat, että eivät ole kuulleetkaan koko fimasta tai sitten sanovat, että he eivät ole "isoissa" piireissä. Minun korviin jäi kuva, että he ovat erilaisia. Kuulostaa siis hyvältä.

Dean Reedin ajama Lean Project Deliveryn olen ymmärtänyt lähes synonyyiksi IPD:n kanssa, mutta IPD:ssä kenties mennään enemmän tekniikka edellä. Jotta kokonaisuus toimisi, pitää mukana ehdottomasti olla sopimustekniikka ja juridiikka. Ja Deanin ajatuksissa myös ihmiset. Ihmiset tekevät rakennuksia, eivät koneet.

No mitä se VDC (Virtual Design and Construction) sitten on? Minun mielestä ei juuri mitään. Se on sitä, että tehdään hienoja rakennuksia käyttäen BIMin mahdollisuuksia hyödyksi. Kuten nytkin, mutta vajavaisesti.

Mutta miten ne hienot, toimivat rakennukset sitten tehdään - siihen tarvitaan IPD:tä ja jokaisen osapuolen omistautumista rakennukselle.

Joskus 1990 luvulla kirjoitin Cadlink -verkkosivustolle otsikolla "Rakennuttajat, Herätkää!". Tuolloin tarkoitin sitä, että pitäisi osata vaatia suunnittelijoilta kunnollisia cad-suunnitelmia. Nyt tuo sama lause voisi tarkoittaa sitä, että: "Rakennuttajat; tulkaa auttamaan suunnittelijoita rakennuksenne tekemisessä - tuokaa prosessiin mukaan myös oikealla asenteella varustettu rakennusurakoitsija."

Viikon kuva:
Ote DPR:n Sutter Medical Centeristä

Erään rakennuksen tietomallitarina talotekniikan näkökulmasta

Olipa kerran valtio, joka ei ollut osannut rakennuttaa yrityksistä huolimatta klassisen tanssitaiteen Mekkaa. Yritelmiä oli ympäri valtiota ja yhteinen näkemys oli se, että kaikkialla muualla paitsi pääkaupunkiseudulla oli parhaimmat fasiliteetit kansantanhujen järjestämiselle.

Aihe oli yleinen pääkaupunkiseudun kulttuurieliitin puheissa yli kymmenen vuoden ajan, kunnes päätettiin järjestää arkkitehtikilpailu asian korjaamiseksi. Kilpailun voittajaehdotus oli lähes kaikkien mieleen ja päätettiin ryhtyä toimeen – enää puuttuisi rahoitus. Sekin saatiin järjestymään yhteisellä koalitiolla ja viiden vuoden taistelulla.

Noin 11 vuotta arkkitehtikilpailun voiton jälkeen tanssitaiteen mekka on lähestulkoon valmis, ensimmäiset tanhut on jo salaa tanssittu ja vaikuttaa siltä, että tärkein kaikesta, tanssilattian vahaus on onnistunut hienosti. Enää ei tarvita perunajauhoja lattialle – se on valmis ottamaan vastaan tanssijat ”luomuna”.

Talotekniikkasuunnittelun aloitus

LVI toimisto ”L” pääsi mukaan suunnitteluprojektiin laatupisteillä. Tietomalli on ollut suuri haaste ja projektin tässä vaiheessa voidaan todeta, että ilman sitä toteutus ei olisi onnistunut. Kaikki projektiin osallistuneet ovat asiasta samaa mieltä.

Tanssisalien ja harjoitushuoneiden lämpötilan sekä kosteuden hallinta vaatii suuria ilmamääriä ja niinpä ilmankäsittelykoneiden kokonaisilmamäärä on 120 m3/s ja niitä on yhteensä 22 kappaletta. Puhaltimien valinnassa suunnittelu- ja toteutusvaiheessa on kiinnitetty erityistä huomiota ääniteknisiin suoritusarvoihin – tanssijoiden kenkien suhina on kuuluttava ylimmälle parvelle asti virheettömänä.

Tietomallipohjainen suunnittelu mahdollisti esimerkiksi lämpiöiden osalta ilmamäärän pienentämisen henkilö-/ neliöpohjaiseen mitoitukseen verrattuna. CFD (computational fluid dynamics ) -simulointi osoitti, että iv-koneiden ilmamääriä voidaan pienentää 20% sisäilmaolosuhteiden tavoitteiden huonontumatta.

"Tekniset tilat ovat tämän tyyppisissä kohteissa säännöllisesti liian pieniä. Suuret ilmamäärät ja matalat äänitasot vaativat väljästi mitoitettuja ilmankäsittelykojeita ja kanavistoja. Konehuoneet olivat 50% liian pieniä ja 30% liian matalia. Meiltä meni koko kesä niiden suunnitteluun, laskentavaiheessa tuli sitten vain yksi kysely", kertoo projektissa vahvasti mukana ollut DI Ilma Virta. "Meillä on käytössä nyt mallinnuksen Rolls Royce ja ilman sitä tämä ei olisi onnistunut", hän kiittelee Magicad-ohjelmistoa ja kaikkia suunnitteluprosessiin osallistuneita.

Johtuen projektin monimuotoisuudesta on suunnitteluprosessi ollut erittäin raskas. Talotekninen L2 tason luonnossuunnitelma julkaistiin vuonna 2005. Julkaisu oli 207 sivuinen, sisältäen hankeyhteenvedon, elinkaaritarkastelut, energia- ja olosuhdesimuloinnit, CFD-simuloinnit, järjestelmäkaaviot ja muut tarvittavat dokumentit.

Arkkitehdin tietomallia voitiin käyttää vain 80 prosenttisesti tässä vaiheessa, johtuen lähinnä ohjelmistojen kehittymättömyydestä tuottaa spesifikaation mukaista IFC tiedostoa sekä kohteen monimuotoisuudesta, jolloin mallinnusvirheillekin oli jäänyt tilaa. Puuttuvat osat mallinnettiin itse jolloin kokonaisuus saatiin hallintaan ja koko rakennusta koskevat laskelmat tehtyä.

Luonnosvaiheen jälkeen alkoi projektin työmallin teko Magicadillä. Käytettävissä oli arkkitehdin 1:100 leikkaukset sekä tarkkaan talotekniseen mallinnukseen puutteellinen ARK-3D malli.



Verkostojen tietomallinnus

LVI-suunnittelutoimistossa päätettiin testata uutta toimintatapaa dwg –kuvien käsittelyssä. Saimme arkkitehdiltä heidän AutoCAD Architecturella (vuonna 2005 ADT, Architectural Desktop) tehdyn mallin projektitiedostot ja kirjaston. Integroimme siihen omat talotekniset dwg –tiedostomme ja näin ajattelimme hyödyntävämme Architecturen ominaisuuksia 3D tiedossa ja dwg –mallien projektinhallinnassa.

Noin puolen vuoden päästä totesimme, että integraatioajatuksemme oli teknisesti väärä – mallien koko paisui niin suureksi, että meillä ei ollut mitään mahdollisuutta pyörittää arkkitehdin 3D-informaatiota oman 3D-mallimme taustalla. Myös ohjelmistojen puutteelliset integraatiokyvyt talotekniikkamallin ja arkkitehtimallin käsittelyssä tulivat vastaan. Totesimme, että Autodesk Architecture ei ole riittävä alusta talotekniikan 3D-mallintamiselle.

Siirryimme takaisin siihen, minkä tiedämme toimivan. ACA mallin alle perinteinen 2D arkkitehtikuva ja siihen Magicadillä 3D-tietomallinnus taloteknisistä verkostoista. Kohteen ensimmäinen LVI-tekniikan tietomalli luotiin siis ”tyhjään” cad-avaruuteen, 1:100 ark-leikkausten tietosisällön kanssa - kuten tuona aikana lähes jokainen muukin kohde tehtiin.

Yhdistelmämallit nostivat päätänsä myös todellisissa rakennuskohteissa vuosina 2004-2006. Ohjelmistot alkoivat olla siinä tasossa, että voitiin siirtyä demo –portaalta oikeisiin kohteisiin. Solibri Model Checkeriä käytettiin taloteknisen mallin tarkastelussa alkuvaiheessa, kunnes siirryttiin pääsääntöisesti käyttämään Navisworksia normaalin tietomallintamisen tukiohjelmistona.

Kuten todettua, olimme todenneet että yhdistelmällä Magicad + ACA ei voida tehdä taloteknisiä tietomalleja siinä tarkkuudessa, joka tulisi olemaan kohteen omana vaatimuksenamme / tavoitteena. Toisaalta, mitään virallista vaatimusta ei ollut edes olemassa, sillä Ison Rakennuttajan tietomalliohjeistus julkaistiin vasta vuonna 2007 – teimme mallia siis ohjeella ”suunnitellaan 3D:nä”.

Navisworksin käyttöönotto avasi pelimme uudelleen. Sen kautta voimme lähes reaaliaikaisesti nähdä, mitä kokonaisuudelle tapahtuu, kun viisi – seitsemän henkilöä mallintaa samanaikaisesti samaa kohdetta. Navisworksin käyttö tässä kohteessa loi LVI-suunnittelutoimistoon uuden käytännön koko cad-suunnittelujärjestelmäksi. Se koostuu nykyisin kahdesta näytöstä, jossa toisessa on ACA+Magicad ja toisessa Navisworks –yhdistelmämalli kohteesta. Tämä järjestelmä takaa tekniset mahdollisuudet mallin 3D-tarkkuustason kasvattamiselle sille tasolle, mitä Tanssitaiteen rakennuksen mallille alkoi tapahtua, kun rakennusurakoitsija ”R” tuli mukaan hankkeeseen.



Pääurakoitsijaksi rakennusliike ”R”

Kun kohteen pääurakoitsijaksi monien eri vaiheiden jälkeen tuli ”R”, alkoi tietomallissammekin tapahtua. Olimme tehneet kohteen ”normaalilla” mallinnustarkkuudella, joka oli noin 5-20cm. Eli pääsääntöisesti mallimme kanavistot olivat tuon lukeman päässä oikeasta sijainnistaan. Se taas tarkoittaa sitä, että joissakin kohdissa eri verkostot viistivät toisiaan tai pahimmassa tapauksissa menivät toistensa läpi.

Tämä tarkkuustaso ei riittänyt R:lle. Heidän käytössä näimme ensimmäisen kerran työmaalle asti siirtyneen tietomallipohjaisen materiaalin hyödyntämisen. Monilla rakennusfirmoilla puheet tietomallien käytöstä jäävät firman johdon / keskijohdon seminaaripuheiksi työmaiden ollessa autuaan tietämätön uusien teknologioiden mahdollisuuksista – ainakin vuonna 2008.

”R” otti talotekniikkamallin IFC tiedostot heti käsittelyynsä, yhdisti ne Tekla –ohjelmistoon ja alkoi ihmetellä sitä, että ovatko rakennemalli ja talotekniikkamalli edes samasta rakennuksesta…

Yhteistyö alkoi kuitenkin rakentavasti. Molemmin puolin tiedostettiin uusi tilanne. Nyt oltiin lähellä sitä tasoa, että talotekniikkamalli olisi ”as buildt” jo ennen rakentamista ja koska kaikki suunnitteluosapuolet tekevät työnsä mallin kautta, tulee R:lle siitä kiistatonta hyötyä rakentamisvaiheessa.

On ymmärrettävää, että ketään muuta osapuolta kuin LVI-suunnittelijaa ei kiinnostanut se tosiseikka, että olimme tehneet hienon tietomallin. Kaikki verkostot oli tasapainotettu, iv-puolella oli tehty äänilaskelmat – saimme kaistoittain äänitiedot siitä kohtaa kanavistoa kuin halusimme. Opimme myös sen, että jos akustikoilla on jokin kikka vaimentaa ääntä, joka on toiminut jossain muussa kohteessa, niin se otetaan helposti käyttöön (esim. tietty määrä vaimennettuja kulmakappaleita kanavistossa, vaikka olisi ollut tarjolla äänen tehotasot kaistoittain)

Verkostojen 3D-geometriamallinnus nousi siis Tanssitaiteen rakennuksen kohdalla sellaiseen arvoon, jota ei oltu muissa vastaavan kokoluokan kohteissa vielä nähty. Syynä tähän olivat ahtaat tilat - mallin tarkkuustason nosto oli elintärkeä sille, että kaikki järjestelmät saatiin yleensä mahdutettua kohteeseen. Vieläpä siten, että järkevät huoltoreitit säilyivät.

Kohteessa päätettiin siis rakennusurakoitsijavalinnan jälkeen nostaa kohteen 3D-mallin tarkkuustasoa. Kohde aikataulutettiin pääurakoitsijan toimesta ja sen perusteella MagiCAD -mallinnusta lähdettiin tarkentamaan. Ison Rakennuttajan kanssa tehtiin alustava sopimus siitä, että tarkkuustason kasvattamiselle on selvät perusteet ja lisälaskutus mahdollista.



Rakennemallin muutokset

Tässä kohtaa tapahtui yksi suuri asia, joka lähes sekoitti koko taloteknisen mallinnuksen. Kohteeseen suunnitellut matalat M-palkit muutettiin delta –palkeiksi, laattoja alettiin tukea konsolein. Voisi sanoa, että lähes kaikki verkostomme osuivat tämän jälkeen palkistoihin / kattolaattoihin. Solibrin tekemä automaattinen tarkastusraportti oli karua luettavaa. Jos iv-kanava törmää palkkiin (jota ei ole ollut, kun suunnitelmaa oli tehty), niin korjaava osapuoli on iv-suunnittelu. Välillä tietomallipalavereissa jouduttiin vääntämään rautalankaa siitä, että emme ole tarkoituksella vetäneet verkostoja palkkien läpi.

Käytännössä mallin tarkkuustason nosto ei ollut siis ainoa työ, joka jouduttiin tekemään uusiksi mallin tarkkuustason kasvattamisen yhteydessä. Jouduimme hakemaan myös uusia reittejä rakennemallin muututtua kohteessa erilaiseksi kuin mitä se oli ollut suunnitteluaikana.

Työmäärän arviointi on ollut erittäin vaikeaa mallin tarkkuusnostolle. Esimerkkinä siitä voitaisiin pitää tekniikkakellarin erään osan mallinnustyötä. Ajattelimme, että työ kestää kuukauden, todellisuudessa meni 5 kuukautta. Aikaa ”as buildt” mallin tekemiseen ennen kuin asennustöitä on suoritettu kuluu todella runsaasti. Mutta näin jälkikäteen katsoen, työmäärä on todella ollut sen arvoista.



Mallin käyttö työmaalla

Työmaa pystyy tekemään ennen asennustöiden aloitusta asennuskatselmuksen kohteesta virtuaalisesti. Jokainen osapuoli näkee kokonaisuuden ja mikä on hänen oma osuus siinä. Rakennusliike ”R” on koordinoinut kohdetta esimerkillisesti tietomalleja hyväksikäyttäen. Alkuvaiheessa on mm. puratettu jo tehtyjä viemäriasennuksia, koska niitä ei oltu tehty mallin mukaisesti. Nyt kun työmaa on ”hyvässä vauhdissa” ja luottamus mallien tarkkuudelle on saavutettu, työt etenevät sujuvasti eteenpäin - vieläpä aikataulussa.

On hienoa nähdä työmaalla käydessä, että pöydiltä / seiniltä löytyy normaalien 2D suunnitelmien lisäksi todella paljon 3D-tulosteita eri kohdista verkostoja. Ja näitä tulosteita ei ole tilattu LVI-suunnittelijalta, vaan työmaa on ne itse tulostanut suoraan mallista. Ajat ovat siis muuttuneet – enää ei suunnittelijalta tilata leikkausta jostain kohdasta, vaan työmaa käy kaivamassa tarvittavan tiedon itse mallista.



Kohteen opetukset

Kohteena Tanssitaiteen rakennuksen projektia voisi pitää tietomallinnuksen ammattikouluna. Sitä ennen on korkeakouluissa mietitty tutkijoiden taholta työmenetelmiä, joita tietomallipohjainen suunnittelu tulisi tarvitsemaan. Ohjelmistokehittäjät ovat tehneet jo vuosia ohjelmistoja tietomallipohjaiseen suunnitteluun.

Tämän kohteen tapauksessa nämä opit siirrettiin jossain muodossa käytäntöön vuonna 2004 ja ennakkoluulottomasti hypättiin tyhjyyteen. Tietomallinnus siirrettiin oppikirjoista käytännön tasolle, yhteistyö eri suunnittelijoiden kesken aloitettiin uudella tavalla. Opittiin paljon uusia työmenetelmiä, jotka pitäisi ottaa käyttöön jokaisessa vastaavassa kohteessa. Huomionarvoista tässä kohteessa on siis se, että se on virallisesti / sopimusteknisesti suunniteltu perinteisen suunnittelumenetelmän prosessein, joskin tekijät ja tilaaja ovat olleet avoimin mielin käyttöönottamassa uusia metodeja.

On täysin selvää, että suunnittelun prosessit pitää muuttaa kun tehdään tietomallipohjaista suunnittelua. Tulevaisuudessa tähän tulee toivottavasti apuja, kun käytäntö ja tutkimus kohtaavat toisensa. Sekä myös urakoitsija ja suunnittelija. Jokaisella suunnittelualalla on historiallisia painolasteja mukanaan, joiden järkiperäisyys tulee uudelleen tarkistaa. Esimerkkinä tästä voisi olla reikäkuvien käsittelyprosessit, joiden uudelleenmietintä olisi todella hyödyllistä kaikille osapuolille.

Tanssitaiteen rakennus on tehty siis käyttäen perinteisiä suunnittelun prosessimenetelmiä. Mitään muuta vaihtoehtoa ei valitettavasti ole voinut ollakaan, sillä suunnittelun aloituksesta on kulunut sen verran paljon aikaa, eikä kesken projektivaiheen voi käytäntöäkään muuttaa.

Kohteen opetus tietomallimielessä on ollut se, että projektiryhmän yhteistyön merkitys tulee kasvamaan erittäin paljon. Jokaisen eri suunnittelijan on tunnettava toistensa suunnittelumetodit, jotta päästään hedelmälliseen lopputulokseen. Työmaan tulee olla läheisemmässä suhteessa suunnitteluun – heidän ammattitaitoaan tarvitaan kun lähdetään tekemään toteutusmallia. Kaikki suunnitelmat tulee perustua tietomalliin, samasta asiasta ei voi olla kahta eri näkemystä – toinen mallissa ja toinen 2D-piirustuksessa.

Ohjelmistoilla ei suunnitella tai rakenneta kohteita. Sen tekevät ihmiset.

Viikon kuva:

Imperiumin puolella.

Myykää minulle toimiva mallinnussofta

Haluan saada talotekniikkapuolelle suunnittelujärjestelmän, joka käsittelee rakennusta kokonaisuutena eikä pelkkänä kerroksittain mallintavana piirustuslautana. Kerrosjako pitää ehdottomasti olla olemassa sisäänrakennettuna ohjelmistoon, mutta esimerkiksi pystynousut pitää päästä mallintamaan kokonaisuutena alusta loppuun, eli esim. ylimmästä IV-konehuoneesta alimpaan kerrokseen - läpi talon, kertavetona.

Koko rakennus on saatava leikkautumaan, kuten yhdistelmämallien käsittelyyn tarkoitetuissa ohjelmistoissa tai oikeissa CAD-järjestelmissä. Miksi yleensä tarvitsemme suunnittelussa yhdistelmämallien käsittelyyn erillisiä ohjelmistoja? Mehän olemme maksaneet suuren rahan CAD-järjestelmästä, jolla pitäisi pystyä näkemään kokonaisuuksia, eikä pelkästään jotain pientä putkenpätkää kolmannesta kerroksesta.

Suunnittelujärjestelmässä pitää olla ns. ”tiimityöskentelyominaisuus”. Kateellisena katselen ArchiCAD -arkkitehtien ja Tekla -rakennesuunnittelijoiden työtapaa, kun kaikki suunnittelijat tekevät samaa rakennusta, yhtäaikaa. Me kärvistelemme talotekniikkapuolella kerroskohtaisessa suunnittelussa, tiedostokohtaisessa systeemissä. Jokainen erillinen suunnittelija näkee omalta cad-ruudultaan vain vajavaisen kokonaisuuden todellisuudesta.

Nykyisin, jos haluaa nähdä minne on verkostot rakennuksessa mallintanut, pitää ottaa käyttöön toinen ohjelmisto joka on erikoistunut yhdistelmämallien käsittelyyn.

Täysin järjetöntä touhua. Haluan saada kaikki objektit näkyville cad-järjestelmässäni, jotta osaisin suunnitella risteilyvapaita verkostoja.

Haluan tietenkin pitää nykyisinkin käytössäolevat loistavat verkostojen tasapainotus- ja äänilaskennat ohjelmistossa. Sekä laite- ja komponenttivalmistajien tuoteluettelot, matemaattisine tietoineen. Haluan kuitenkin tehdä työmaalle eri rakennusvaiheisiin soveltuvia piirustuksia. IV-asentajaa tuskin kiinnostaa säätöpellin ilmavirta ja painehäviö, mutta säätömies voisi tällä tiedolla jo jotain tehdäkin. Haluan siis tulostaa paperille eri käyttötilanteisiin kustomoituja näkymiä mallista.

Haluan saada verkostojen muuttamiseen parempia työkaluja. Jos haluan laskea käytävän IV-runkoa 100mm alaspäin, niin haluan klikata runkoa ja sanoa, että mene 100mm alaspäin. Ei niin hirveän monimutkainen halu. Ei vaan toimi, jos rungossa on pari t-haaraa johonkin huoneeseen.

Jos haluan muuttaa viemärin kallistusta kymmenestä promillesta viiteentoista, niin senkin pitäisi olla mahdollista ylläkuvatulla tavalla.

Haluan muuttaa sadan samantyyppisen komponentin ominaisuuksia tai korkoasemaa yhdellä kerralla. Haluan klikata alakattoa ja kertoa sadalle päätelaitteelle, valaisimelle jne. että "asettukaa tämän alakaton alapintaan".

Haluan kertoa lattiakaivolle, viemärille jne. että "asetu ontelolaatan ontelon kohdalle, eikä kannaksen".

Haluan kertoa putkelle, että asetu 150mm päähän tuosta viereisestä putkesta.

Suunnittelu on muuttamista. Suunnittelu ja mallintaminen eivät ole synonyymejä ainakaan minun sanakirjassani. Ne eivät ole toisiansa poissulkevia tapahtumia, mutta koska jo tehdyn mallinnuksen muuttaminen on nykytyökaluilla niin hankalaa, alkaa liian helposti siirtää koko mallinnuksen aloittamista eteenpäin ja eteenpäin. Tällä metodilla ei projektinjohtourakka toimi, joka lienee valitettavasti tulevaisuuden (ja nykyisyyden) tapa toimia. Tarvitaan siis työkaluja jo mallinnettujen verkostojen helppoon muuttamiseen ja ominaisuuksien lisäämiseen suunnitteluprosessin edetessä kohti tarkempaa ja tarkempaa lopputulosta.

Haluan, että ohjelmistofirmat tekevät keskenään yhteistyötä. En välttämättä halua saada omaan cad-järjestelmään aina koko rakennuksen ARK-mallia, vaan haluan saada esim. kaikki sen alueen pilarit ja seinät ruudulleni jossa työskentelen. Täydellisinä objekteina, ei minään viitekuvina. Kun en niitä enää tarvitse, heitän ne deletellä pois ja kutsun työskentelyalueelleni seuraavat objektit joita työssäni tarvitsen.

(pikkulinnut ovat laulaneet, että tämänsuuntainen kehitys olisi jo tiettyjen ohjelmistotalojen osalta käynnistynyt - tai sitten olen tahallaan ymmärtänyt asian väärin...).

Haluan, että ohjelmistotalot kuuntelevat heidän softiensa käyttäjiä.

ISH2011 ja BIM

Tuli käväistyä Frankfurthin "LVI-messuilla", kohtalaisen suurissa talotekniikkapuolen kokoontumisajoissa.

Tottakai kiertelin osastoja enemmän tietomallilasit päässä kuin puhaltimien hyötysuhdevaatimuksia muistellen - joskin ainahan tulee tutustuttua jokaisen messuhallin WC-tilojen tekniikkaan...

Oli mielenkiintoista todeta, että tarjonta saksan BIM markkinoilla oli kohtalaisen laajaa, mutta todella spesifioitunutta juuri keskieuroopan suunnittelu- ja urakointikulttuuriin. Tai mikäs ihme se on, markkinahan on laaja.

Ei voi suoraan väittää, että he olisivat täysin kuutamolla, mutta kyllä siellä suomalaisen kelpaa kävellä eri osastoillaja todeta, että ollaan vielä muutaman vuoden pidemmällä täällä pohjolan perukoilla, joiden markkinoista ketään ei ole kiinnostunut.

Lähes joka ständillä kun kyselin, että kuinka moni prosentti suunnittelijoista käyttää esim. tasapainotuksia hyödyksi, tuli vastaukseksi käsienlevitystä.

Paljon tärkeämpää oli, että oliko putkilaipat minkäkin DIN normin mukaiset ja millä normilla oli lämpöhäviöt laskettu.

Autocadin päälle oli rakenneltu aika paljon softia, selvässä vähemmistössä oli omalla alustalla pyörähtelevät talotekniikan BIM mallintimet. On todettava, että autocadin päälle kun tekee, niin saa nopeasti näyttävää jälkeä aikaiseksi, mutta loppupeleissä puhti sitten loppuukin kesken.

Muutama omalla alustalla oleva softa näytti erittäin lupaavalta kehitysalkiolta, paperilla ja demotilanteessa kaikki oli kunnossa. Vaikutelmaksi jäi, että enää kun he saisivat käyttäjäkunnan tajuamaan BIMin hyödyt, olisi markkinat auki.

Yllättävää oli huomata myös se, että Autodesk Revit oli lähestulkoon tuntematon käsite. Edes Autodeskin omalla osastolla ei löytynyt kaveria, joka olisi osannut Revit MEPpiä hieman pyöritellä. Tai sitten demohaluihin vaikutti se, että minulla ei ollut pukua päällä...

Vain muutamalla osastolla oli hahmotettu, että tietomallin elinkaari ei lopu suunnitteluun, vaan jatkuu jossakin muodossa kiinteistöjen ylläpitoon. FM -lyhennettä oli monessa mainoksessa, mutta en ihan päässyt kartalle siitä, miten he mallia sinne jatkavat. Demot liittyivät pelkkään suunnitteluun.

Kokonaisuudessaan keikka avasi sen verran silmiä, että tasapainottavia ja äänilaskelmilla varustettuja softia löytyy, mutta käytettävyys vaikutti hieman kotimaisia vastineita kömpelömmältä. Yleensä valikoissa vilkkui liikaa DIN standardeja ja muita koodeja, ennen kuin pääsi niin pitkälle että pystyi vääntämään putkea ruudulle.

Ja huomasi hyvin, että myyntitykit demosivat tajuamatta mitä he ovat tekemässä. Näin taas sen legendaarisen demon, jossa laitetaan ~8 päätelaitetta huoneisiin ja sitten vedetään yksi runko käytävälle ja yhdellä käskyllä liitetään nämä kaikki päätelaitteet runkoon... jepjep, näinhän se iv-suunnittelu hoituu.

simplebim - syvempää tuttavuutta IFC:n saloihin

Suomalainen Datacubist Oy tarjoaa IFC osaamistaan ohjelmansa simplebimin kautta.

Simplebimillä voidaan luoda käyttötarkoitukseen sopivia IFC-tiedostoja. Ohjelmassa on myös erinomaiset keinot "kaivaa" tietoa ifc:n sisältä ja siirtää niitä esim. exceliin.

Otetaan esimerkiksi arkkitehtimalli, jossa on myös irtokalusteet mukana. Simplebimin avulla voit poistaa kaikki kalusteet ja tehdä jäljelle jääneestä mallista uuden IFC-tiedoston. Näin voidaan eri käyttötarkoituksiin luoda niille soveltuvat mallit.

Valitettavasti ohjelmaan voidaan tässä vaiheessa pääsääntöisesti vain poistaa objekteja, ei esim. luoda tai muuttaa olemassaolevia toisenlaisiksi. Esimerkkinä tästä voisi olla tapaus, jossa arkkitehtimallissa on tilat olemassa, mutta kirjoittanut cad-ohjelmisto ei ole osannut tehdä relaatioita kuntoon. Eli mallia ei voida käyttää energialaskennoissa hyödyksi. Olisi pieni päiväuni saada sellainen softa, joka "ravistelisi" rakennusta ja liittäisi seinät ja ikkunat IFC-speksien mukaisesti tilaan, loisi space boundaryt jne. Ja sitten korjatu IFC-ulos ja laskemaan energioita.

Ei liene ihan helppo tehtävä, mutta kenties joskus tulevaisuudessa joku sellaisenkin tekee.

Ohjelman käyttöliittymän logiikkaan menee muutama tovi, ennenkuin käyttö alkaa luonnistaa. Sanonkin nyt heti vinkin - muistakaa pitää CTRL-SHIFT näppäimiä painettuna, joko molemmat yhtä aikaa tai erikseen yhdessä hiiren oikean napin kanssa. Näin alkaa orbit ja zoomaus onnistua. Pitää sanoa, että useia cad-ohjelmistoja käyttäneenä tässä softassa on keksitty pyörä uudelleen, ja renkaat ovat mielestäni vähintään kuusikulmioiset - ei siis ihan pyöreät...

Ohjelma on selvästi tehty tietomallispesialisteille ja he siitä eniten irti saavatkin. Jotta pääsee syvemmälle softan toimintoihin, pitää ymmärtää vähintään perusteet IFC:n rakenteesta. Kun perusteet on hallussa, tarjoaa softa hienon ympäristön tietomallien tarkastelulle ja käyttötarkoitukseensa sovittamiselle.

Ohjelmaan voidaan myös itse koodata lisämoduleja, eli jos olet etsinut työkalua IFC-tiedostojen hakkeroimiseen, niin tässä voisi olla hyvä alusta.

Katso esittelyvideot osoitteesta http://www.datacubist.com/ ja tee valinta, onko softa tehty sinulle. Pelkkään IFC-tiedostojen visuaaliseen tarkasteluun sitä ei kannata hankkia. Toisaalta, hinta ei ole paha, 200e.

Näkymä simplebimistä:

Suunnittelun vaiheistus takaisin

"Vanhoina hyvinä aikoina" suunnittelu oli vaiheistettu siten, että ensiksi teki arkkitehti
pohjakuvat, sen jälkeen rakennesuunnittelija rungon, sitten LVI-suunnittelija verkostot ja
tämän jälkeen sähkösuunnittelija kaapelihyllyt ja sähköistyksen. Rakennusautomaatiosuunnittelijakin mahtui vielä LVI:n ja sähkön välimaastoon.

Oli itsestään selvää, että arkkitehtipohjat oli lukittu jonakin päivämääränä ja siitä kuukausi tms. niin LVI-suunnittelijalla on urakkalaskentakuvat kopiossa. Siitä viikko ja RAU kuvat on kopiossa. Ja tästä viikko, niin sähkösuunitelmat ovat lähteneet.

Minne hemmettiin tämä hyvä ja looginen toimintatapa on hävinnyt?

Ei suunnitelmat voi valmistua samaan aikaan. Suunnitteluprosessi koostuu osasuorituksista, joissa seuraavan vaiheen tekijä vaatii jonkun muun vaiheen tekemää pohjatyötä.

Ja sama asia tietomallien näkökulmasta: "kun mallinsin sen iv-kanavan, niin ei siinä kohtaa
käytävää ollut rakennepalkkia, se (ne) tulivat viime metreillä rak-suunnitelmiin." Ja sitten IV-suunnittelija muuttaa (ilman lisätyökorvausta) iv-kanavat alemmaksi, kun palkista ei pääse läpi - ja alkaa itku sähkärillä: "Ei mulle kerrottu, että iv-kanavat tippuu 20cm, nyt ei pysty asentamaan kaapeleitä hyllylle, hylly tippuu ainakin 15cm". Ja sitä kautta käytävän alakattokorko on 15cm alempana ja kun työmaa ei kuitenkaan saa kamoja mahtumaan se tippuu vielä 5cm.

Taas talotekniikka on syyllinen, tuhosi arkkitehdin vision käytävästä.

Ei ym. skenaario ole pelkästään vaiheistuksen puuttesta johtuva, mutta aivan liian yleinen.
Mitä jos suunniteltaisiin ensin ja sitten rakennettaisiin? Huima idea!

Ei auta, että annetaan pelkästään enemmän suunnitteluaikaa, pitää olla vaiheistus olemassa. Kaikkein
tärkeintä on hyvä arkkitehti, pääsuunnittelija. Jos tilat liikuvat koko suunnitteluprosessin ajan, niin se sekoittaa koko talotekniikan suunnittelun.

Arkkitehdillä pitää olla riittävä aika tilaohjelman kuntoon laittamisessa ja jonkun rakennuttamisorganisaatiossa on pystyttävä sanomaan käyttäjälle, että tietyn päivämäärän jälkeen ei oteta enää muutoksia vastaan.

Jos kuiluille ja teknisille tiloille ei synny arkkitehdin suunnitelmiin ehdotettuja reittejä, ollaan tuhon tiellä. Nykyiset rakennukset vaativat paljon tekniikkaa, niitä pitää huoltaa ja niihin on päästävä käsiksi koko rakennuksen elinkaaren ajan. Ammattitaitoinen arkkitehti pitää tätä onneksi itsestäänselvyytenä.

Talotekniikan mallin muuttaminen ja korjaaminen ei ole mitään helppoa työtä. On usein järkevämäpää aloittaa jonkun alueen mallintaminen uudelleen tyhjästä, kuin lähteä korjaamaan / muuttamaan olemassaolevaa.

Takaisin suunnitteluprosessiin; nyt kun suomessa on liikkeellä projekteja joiden tarkoitus on kehittää (tai luoda) tietomallisuunnittelun prosessia niin onneksi mukana on myös rakennuttamisen rahakirstun päällä olevia rakentamisen ammattilaisia.

Toivon, että heillä on kokonaisnäkemystä siitä, mitkä asiat aiheuttavat sekasortoisia rakennuskohteita. Ne eivät ole varmaankaan tietoteknisiä asioita, vaan puhtaasti ammattitaitoisen rakennuttamisen ja suunnittelun asioita.

Toteutussuunnitteluvaiheessa tehtävä tietomallisuunnittelu ei ole sitä, että voidaan veivata asioita "helposti" edestakaisin - mitä enemmän veivataan, sitä sekaisemmaksi homma menee. Jos rakennuttaminen on epäonnistunut (ehdotus- ja yleissuunnitteluvaiheessa), on ihan sama, mallinnetaanko vai piirretäänkö viivoja - näitä projekteja on vaikea suunnittelijoiden tasolla laittaa raiteilleen.

Suunnittelun vaiheistus on yksi askel monien joukossa, joka on palautettava rakennuttamisprosessiin. Tai ainakin silloin, jos halutaan saada hyötyjä tietomallisuunnittelusta.

Jos rakentamisen idea on pilkkoa urakat mahdollisimman pieniin osa-alueisiin ja kilpailuttaa ne kaikki sekä valita aina kustannuksiltaan halvin vaihtoehto, niin tulemme tekemään tulevaisuudessa samaa sutta kuin mitä ollaan tehty 70 -luvulta lähtien - tietomalleista riippumatta.

Niin, ym. tapa on siis nykyisinkin normaali, yleisesti hyväksytty urakoitsijoiden toimintatapa.

Mikä on ylläpidon tietomalli?

Tämän hetken yksi suurista asioista, mitä maailmalla puhutaan ja kehitetään, on ylläpidon tietomalli.

Tämä asia ymmärretään yhtä monella tavalla kuin on keskustelijoitakin. Alla oleva näkökulma on minun näkemys siitä, mitä sillä tarkoitetaan.

Lähden liikkeelle siitä, että ylläpidon tietomallista pitäisi varmaan olla jotain hyötyäkin kiinteistön omistajalle. Tai ainakin kiinteistöä ylläpitävälle taholle.

Tämä tarkoittaa sitä, että ylläpidon tietomalli on jotain paljon enemmän, kuin graafinen näkymä tietomalliin. Se on paljon enemmän, kuin tietoja seinistä ja ikkunoista.

Ylläpidon tietomalli on helposti ylläpidettävä tietokanta, josta voidaan saada pitkän tähtäimen suunnitelmia, yhteenvetoraportteja, laitetietoja, huoltolistauksia, ennakoivaa huoltoa jne. On pelkkä nyanssi, että pääseekö tietoihin käsiksi klikkaamalla 3D-mallissa olevaa lattiaa (mikä materiaali, mikä siivousväli jne.) tai muuta objektia.

Tämä ominaisuus on kyllä ihan kiva ja varmaan demoaisin sitä erittäin mielelläni seminaareissa / esityksissä, mutta mitä todellista, konkreettista hyötyä sillä saavutetaan verrattuna esimerkiksi siihen, että klikkaan talon 2D-pohjakuvaa, jossa sama huone sisältää samat tietomallitiedot?

Pääsen 2D-kuvan kautta huomattavasti nopeammin tarkastelemaan asioita huone- tai aluetasolla.

Ylläpito tarvitsee pääsääntöisesti avukseen isojen alueiden kokonaistietoja, jotta voidaan tarkastella kiinteistöä kokonaisuutena. Kokonaisuuksien käsittely onnistuu parhaiten 2D-pohjakuvien kautta, taikka sorttaamalla listasta esim. kaikki kiinteistön käytävät, jolloin tiedän niiden kokonaisneliömäärän -> pystyn kilpailuttamaan siivouksen. (ja saan tietenkin pohjakuvat käytävistä värillisenä jne)

On kuitenkin selvää, että ym. asiat tullaan tulevaisuudessa tekemään mahdolliseksi myös 3D-mallin kautta. Aika näyttää, mitä uutta hienoa sen kautta keksitään, mutta liikkeelle päästään yksinkertaisemminkin. Olisihan se ihan hienoa ajella iv-konehuoneeseen ja klikata puhallinta, jolloin saisin sen tiedot esille. Sekä käyntiajat, energiankulutuksen jne.

Mutta kiinteistön omistajana minua ei niin hirveästi kiinnostaisi se yksittäinen puhallin, vaan kaikkien iv-koneiden kokonaisenergiankulutus ja miten sitä pystyisi pienentämään.

Ym. esimerkissä on jo rutkasti vaikeusastetta. Tuossa tapauksessa ollaan puhaltimeen linkitetty sekä valvontajärjestelmän tietoja että ylläpidon huoltokirjatietoja. On selvää, että ensimmäisinä askeleina tulemme näkemään huoltokirjan linkitykset ja sen jälkeen pitkän ajan kuluttua valvontajärjestelmän tietoja ylläpidon tietomallissa, objektikohtaisesti.

Edellisessä kappaleessa on yksi tärkeä sana. Se sana on "linkitetty". Eli kun mennään 3D tietomallitasolle, niin mikään tärkeä tieto ei ole graafisissa objekteissa itsessään sisällä. Objektit ovat mallissa, jotta niiden avulla voidaan luoda linkki tietokantaan oikeaan komponenttiin tai laitteeseen. Kun jotain muutetaan tai päivitetään, tieto päivitetään tai päivittyy tietokantaan. Ei välttämättä 3D-malliin.

3D-mallia ei kannata aina pienten muutosten takia päivittää. Jos tehdään tilamuutoksia, niin niitä kannattaa kerätä muutamia ja tehdä sitten kerralla graafinen päivitys. Tietokantaa sitä vastoin päivitetään jatkuvasti. Laitteita poistuu, ne muuttuvat, niitä huolletaan jne. Tietokanta päivittyy ja muuttuu, kun normaali nykyaikainen ylläpidon huoltokirjaohjelmisto sitä päivittää.

Miten sitten saadaan ensimmäinen versio ylläpidon tietomallista? Tippuuko se automaattisesti loppudokumenttien muodossa projektipankkiin?

Voin kertoa, että ei tipu.

Prosessimielessä se tarkoittaa sitä, että suunnittelijoiden mallit päivitetään vastaamaan rakennettua todellisuutta (as buildt -mallit). Tässä kohtaa joku sanoo, että ei onnistu. Minä sanon, että onnistuu.

Kikka on siinä, että mitä jos meillä onkin tarjota urakoitsijoille sellaiset suunnittelumallit, että niiden mukaan pystytään kiinteistö rakentamaan? Huima ajatus... että suunnittelija tekisi sellaiset suunnitelmat, että niiden kanssa voitaisiin tehdä työt loppuun. Meillä on siis as buildt -kuvat olemassa jo ennen, kuin yhtään putkea / kanavaa on kattoon laitettu. Tämä on täysin mahdollista, jos suunnittelijoille annetaan mahdollisuus suunnitella kohde kunnolla. Miten se tehdään - on oman blogikirjoituksen aihe.

Kun ollaan tehty tietomalli oikein suunnitteluvaiheessa, jää jäljelle tiedon päivittäminen. Koska urakoitsija on saanut esim. jotkut muut kuin suunnitelmien mukaiset säätöpellit 100e halvemmalla, niin suunnittelija vaihtaa ne omaan malliinsa. Sama juttu muiden tuotteiden kanssa. Päivitetään malli vastaamaan tietosisällöltään todellisuutta. (fiksut tekevät tämän ennen säätötöiden aloittamista, eli tilaavat suunnittelijalta säätökuvat).

Näin ollaan saatu suunnittelijoilta alkutilanteen malli. Sen jälkeen homman ottaa haltuun ylläpidon koordinaattori. Hän tekee normaalit huoltokirjaan liittyvät työt ja hoitaa mallin linkitykset kuntoon. Hänen vastuulla on se kertaluontoinen työ, että ylläpidon tietomalli rakentuu linkittyen tietokantoihin.

Esimerkiksi talotekniikkapuolella on paljon komponentteja ja laitteita, joita ei edes ole mallissa. Laiteluettelot tulee siirtää ylläpidon tietokantaan ja komponentit linkittää vähintään sijaintitiedollaan 3d-malliin.

Harvemmin arkkitehdin mallissa on lattiapintojen materiaalia tai seinäpintojen käsittelyä. Mutta ne löytyvät kyllä erillisestä maalaustyöselostuksesta tai muusta asiakirjasta. Jonkun pitää tehdä se työ, että kaikki tärkeä mitä on haluttu laitettavan ylläpidon tietokantaan, päivittyy sinne.

Näin ollaan päästy tilanteeseen, jossa suunnittelijoiden tietomalli on päivittynyt ylläpidon tietomalliksi ja voidaan alkaa keksiä kaikkia uusia kivoja juttuja, mihin sitä voisi käyttää oikeasti hyödyksi.

Toivottavasti tätä ei lue ketään prosessiteollisuuden / teollisuuslaitosten suunnittelijat... he varmaan nauraisivat, koska heillä ylläpito-organisaatio on heti hankkeen alussa vahvasti mukana suunnittelua ohjaamassa. Eli ensiksi tulee se, miten laite huolletaan / korjataan, sen jälkeen mietitään muut asiat.

Meillä talotekniikkapuolella (ja rakennuttajapuolella) olisi paljon oppimista heiltä.

Viikon vinkki:

- Ensimmäinen askel hyvän tietomallin tekemiselle on asennemuutos.

Viikon kuva:

- esimerkki tietomallipohjaisesta 2D-näkymästä kiinteistöön. Kuvassa näkyy kerroskohtainen tuloilmakoneiden palvelualuekartta