tiistai 6. joulukuuta 2011

CAD-softat ja 3D

Geometrialtaan onnistuneen tietomallinnuksen edellytyksenä on yhdistelmämallin luominen heti suunnittelun alkuvaiheissa.

CAD-softia käyttävät suunnittelijat tietävät, että markkinoilla ei löydy sovellusta, joka toimisi tietomallien rakentamistyökaluna ja samaan aikaan kokonaisuutta hallitsevana yhdistelmämallisovelluksena.

Jos joku teille väittää, että käyttää omaa cad-softaansa yhdistelmämallien tarkastelutyökaluna, hän on joko softamyyjä tai ammattitaidoton turisti.

Kun rakennuksen pinta-ala on luokkaa 4.000m2 tai suurempi, alkaa cad-softista potku lopppua, jos siihen tungetaan kaikki suunnittelualat - joko suoraan objekteina (miten päivitetään?) tai viitekuvatekniikoilla (näkyvät cad-softassa yhtenä isona mötikkänä). 

RYM Oy:n DRUM -hanke (http://www.rym.fi/tutkimusohjelmat/PRE/drum/) on mielenkiintoinen tekniikka, joka jollain tasolla toivottovasti lyö itsensä läpi. Valitettavasti osa meistä elää kuitenkin Autodesk -maailmassa joten olen erittäin skeptinen tekniikaltaan hyvien ajatusten löytämistä perille näihin softiin. Onhan yleisesti tiedossa, että paras tekniikka ei takaa markkinajohtajuutta tai läpimurtoa - sen takaa iso markkinointikoneisto.

Miten sitten tänä päivänä esimerkiksi TATE-suunnittelija voi toimia 3D:ssä, jos käytetty cad-softa ei sitä tue?

Pitää ottaa käyttöön joku apusofta, esim. Navisworks, Solibri, BIMsight, CadFaster tms. Sitten cad-softan tiedostot linkitetään kiinni valittuun apuohjelmistoon. Formaattina esim. dwg, ifc, nwc tai joku muu.

Ym. asia kuulostaa yksinkertaiselta, mutta matkassa on paljon mutkia edessä. Käytettäessä esim. MagiCADiä, ei ko. yhdistelmämallisoftiin voida suoraan linkittää dwg-tiedostoja. Tämä siksi, että magi käyttää proxyobjekteja. Jotta 3D-informaatio saataisiin siirtymään yhdistelmämallisoftaan, tulisi magicadissä ensiksi laittaa "3D-tila" päälle ja sitten tallettaan dwg + päivittää yhdistelmämallisofta lukemaan päivitetyt tiedostot.

Ja kun yhdistelmämallisoftassa on kiinni 20-50 dwg-tiedostoa, voi vain kuvitella kuinka kauan se kestää.
Ja kun viisi kollegaa mallintaa tietenkin samaan aikaan jotain toista osa-aluetta rakennuksessa, niin he eivät ole välttämättä tallettaneet omia osuuksiaan 3D-tilassa -> lopputuloksena yhdistelmämallisoftassa näkyy vain 2d-tietoa näiltä osin.

Entäpä IFC? Ihan toimiva, mutta esim. Navisworks ei osaa käyttää ainakaan magicadin värejä (kaikki menee valkoisena sisälle). Lisäksi IFC:n teko ja lukeminen kestää isommassa kohteessa liian kauan aikaa jolloin sen käyttö ei ole riittävän tehokasta, kun puhutaan lähes reaaliaikaisesta mallien päivitettävyydestä. 

IFC on hyvä formaatti, kun siirretään tietoa esim. projektipankin kautta muille suunnitteluosapuolille. Toimiston päivittäisenä, sisäisenä tiedonsiirtoratkaisuna se on liian massiivinen / hidas.

Toimivimmaksi ratkaisuksi Autodesk -maailmassa ehdottaisin kantapään kautta oppineena yhdistelmää magi + nwc + navisworks. Tällä tekniikalla yhdistelmämallin päivitys esim. minuutin välein on mahdollista ja takaa mallintajalle lähes reaaliaikaisen 3D-näkymän kokonaisuuteen. 

Isotkin kohteet pyörivät, päivitysten nopeus on riittävä, joskaan ei tehokas isoissa kohteissa. Aina menee jossain kohtaa raja sille, koska pitää suunniteltava kohde pilkkoa pienempiin osiin.

Toimivaa softaa ei ole olemassa, sellaisesta ei kannata edes uneksia. On selvitettävä tarjolla olevat vaihtoehdot ja valittava vähiten huono ratkaisu. Lisäksi on oltava rohkeutta luopua vääristä ratkaisuista, kun tekniikka kehittyy jollain muulla alustalla paremmaksi / pidemmälle. 


Viikon kuva:
Autodesk -tuotteet sulassa sovussa. Näköjään tehoa riittää vielä MP3-musiikin pyörittämiseenkin...



Huomioi, että kyseessä on todellinen suunnittelijan työpiste - kolmioviivotin on edelleenkin yksi tietomallinnuksen perustyökaluja.



maanantai 5. joulukuuta 2011

Miten rakentamisen maailma muutetaan?

Huomauttaisin heti alkuun, että otsikossa on kysymysmerkki.

Olin pari päivää läheisessä kosketuksessa saksalaiseen rakentamiskulttuuriin ja voin todeta, että meillä suomessa asiat ovat hyvin - vaikka haluankin olla mukana muuttamassa suomalaista rakentamiskulttuuria totaalisesti.

Saksalaisten "normaali" tapa antaa kohteesta tarjous on hintakilpailu. Ei laatua, ei energiavertailuja, ei innovaatioita. Yksi hinta, yksi voittaja.

Kun tämä "voittaja" on saatu valittua, alkaa selvittely, mitä tilaaja ihan oikesti haluaa. Siinä voi olla pieni mahdollisuus siihen, että tehtäisiin jotain järkevääkin bulkkirakennuksen sijasta. Yleensä kuulemma ei tapahdu mitään erikoista - sillä hinnalla, jolla ollaan materiaalitietojen perusteella rakennus tarjottu, se tullaan toteuttamaan.

Olen niin rikki ym. tapaan toimia, että en viitsi asiasta enempää kirjoittaa. Palataan otsikon aiheeseen.

Miten rakentamisen maailma muutetaan.

Se lähtee yksilöistä. Jonkun on oltava eri mieltä. Jonkun on saatava muutkin ammattilaiset vakuuttuneeksi siitä, että homma haisee. Sitten nämä muut omalla toiminnallaan ajavat tilanteen siihen pisteeseen, että systeemiä aletaan muuttaa. Meitä on paljon, meissä on voimaa - meidän pitää vain toimia.

Kun suunnittelemme ja rakennamme rakennuksia, meidän pitää oppia tekemään yhteistyötä kaikkien osapuolten kanssa. Työmaan siivooja on yhtä pätevä ammattilainen kuin insinöörikoulutuksen käynyt suunnittelija. Molempia tarvitaan, molemmat tekevät työtä yhteisen päämäärän eteen - tilaajan tulee saada se, mitä he ovat tilanneet.

Arkkitehdin ja tilaajan pitää ymmärtää, että talotekniikka tarvitsee rakennuksesta tiloja. Talotekniset laitteet tulee olla huollettavissa, niihin pitää päästä käsiksi vielä takuuajan jälkeenkin. Tämä on rakennuksen omistajan etu, jonka todellisena valvojana projektissa on pääsuunnittelija.

Kun suunnittelemme rakennuksia, on tietomallinnus erinomaisena apuna faktatiedon tai visuaalisen esittelyn työkaluna. Mutta mikään ei poista sitä velvollisuutta, että meidän rakennusalan ammattilaisten pitää tehdä omalta osa-alueeltamme se tehtävä, mihin meidät on koulutettu. Yhdessä teemme rakennuksia, yksilönä teemme vain projekteja.

Tietomallinnus on prosessimuutos rakennusteollisuudessa. Se ei ole cad-softa, se ei ole tietotekniikkaa. Tietomallinnus on mahdollistaja - muutos ajattelutavassa.

Onneksi pieni osa suomalaisia alan ammattilaisia on hahmottanut tämän asian. Infrapuolella on jo ollut esim. allianssihankkeita. Senaatti kiinteistöt ajaa sitä testimielessä myös rakennuspuolelle.

Allianssihankkeen tavoitteet ovat nopeasti katsottuna aivan kuten IPD / Lean -hankkeen oppikirjasta. Valitaan suunnittelu- ja rakentamisryhmä  laadullisin perustein, asetetaan tekemiselle selviä tavotteita. Tehdään työtä yhdessä, jaetaan riskit ja voitot yhdessä.

Miten tilaaja saa rakennuksensa mahdollisimman edullisella kustannuksella laadusta tinkimättä? Miten se pystytään osoittamaan virtuaalisesti, ennen kuin kaivuri on työmaalla? Miten rakennuksen tekijät saavat sen taloudellisen voiton, joka heille kuuluu kun tavoitteet on saavutettu?

Näihin kaikkiin kysymyksiin on jo vastaukset olemassa. Asia pitää vain konkretisoida todellisen projektin kautta.

Tässä maailmassa minä haluan olla mukana - aktiivisena osapuolena.

Viikon linkki:
http://www.rtk.fi/Download.aspx?id=8345&type=1
Lukekaa ajatuksella... Liikenneviraston uudet linjaukset, Allianssia, PPP-mallia ja vaikka mitä mukavaa.




perjantai 11. marraskuuta 2011

Lisätty todellisuus

Välillä pääsee / joutuu hankkeisiin, joissa tapahtuu jotain hienoa.

http://virtual.vtt.fi/virtual/proj2/multimedia/

Augmented Reality on  "lisätyn todellisuuden" tekniikka, jossa suomessa professori Charles Woodward luo uusia lumia siihen tahtiin, että kohta (no, muutamia vuosia) nähdään ihmeitä tapahtuvan myös kiinteistöjen ylläpidossa.

Ajattelepa, että otat käsiisi iPadin ja osoittelet sillä alakattoa. Omenahärveli kuvaa alakattoa ja siihen kuvaan lisätään kohteen tietomalli ohjelmallisesti. Näet alakaton sisään.

Voit kysyä iPadissa näkyvältä kanavalta, mihin järjestelmän se kuuluu. Voit nähdä, missä huollettava ilmavirtasäädin todella on.

Mitäpä jos kuvataankin tilaa, ja nähdään sen todellinen, mitattu lämpötila  ja verrataan sitä vaatimusmallin lämpötilaan, tämänhetkisellä ulkolämpötilalla... täyttyykö arvot?

Seuraava steppi on lisätä samaan systeemiin automaatiojärjestelmän tiedot. Millä ilmavirralla ilmavirtasäädin on tarkoitettu toimivan (tulee tietomallista)? Millä ilmavirralla se nyt toimii (tulee automaagiojärjestelmästä).

Kuulostaa Star Trekiltä, mutta tämä todellisuudessa ei olla kuitenkaan kaukana Hollywood -todellisuudesta. Puuttuu vain "hieman" tutkimusta sisätilojen paikannustekniikasta sekä jostain pitäisi saada tietomalli, joka vastaa todellisuutta.

Mitäpä jos kävelisi iv-konehuoneeseen, ja härvelin läpi näkyisi punaisella vilkuvalla värillä ne laitteet, jotka eivät toimi suunnitelluilla arvoilla? Tai ovat muuten epäkurantissa mielentilassa. Tämä selviää kyllä jo nykyisinkin helposti automaatiojärjestelmän kautta, mutta toisi ruohonleikkaaja-kiinteistönhuoltajille hieman enemmän konkretiaa taloteknisen järjestelmän toimivuuteen.

Lisätyn todellisuuden edut tietomallien hyötykäytössä ovat erinomaiset. Nyt pitää vain osata erottaa hype todellisesta tarpeesta. Voisi olla mahdollista nähdä esim. työmaaoloissa tyhjää, juuri valmistunutta käytävää kuvattaessa sinne tulevat talotekniset asennukset. Tai sama juttu IV-konehuoneessa.

Onko siitä kuitenkaan mitään muuta hyötyä, kuin ensivaikutelman WOW-efekti...? En tiedä, mutta hieno juttu tuo olisi...

Kun näin ensimmäisen kerran pörssifirman vuosikatsauksen alkusivuilla toimitusjohtajan nousevan juttelemaan menneesta ja tulevasta kuten Prinsessa Leia Star Warsissa, luulin näkeväni näkyjä.

Sitten heräsin, ja tajusin, että LVI-suunnittelu on parasta, mitä ihmisen uralle voi tapahtua.
.
Testatkaa itse:
Printaa tämä papreille:
http://virtual.vtt.fi/virtual/proj2/multimedia/TechOutlook2020.pdf
laita se pöydälle, ja kuvaa läppärin tms. kameralla sitä tämän sivun kautta:
http://www.dnv.com/moreondnv/research_innovation/foresight/outlook/video.asp







perjantai 4. marraskuuta 2011

Miten suunnitellaan alakatto?



Tässä blogissa piti kertoa, että mitä tarkoittaa IDM / MVD -lyhenteet, mutta ajattelinkin kertoa, miten suunnitellaan alakatto.
En tiedä, kumpi on tärkeämpi asia (siis prosessikaavio alakaton suunnittelusta) vai konkreettinen työjärjestys ja sisällöntuotto ongelman ratkaisemiseksi.

Olen aivan täynnä projekteja, joissa yhdistelmämallitarkastelussa talotekniset komponentit eivät osu oikeaan paikkaan alakatoissa. Joko ne ovat 5mm (luit oikein, viisi millimetriä) liian korkealla tai sitten puhallinkonvektorin reunalista tulee 600x600 ruudussa valaisimen päälle - ne eivät siis voi olla vierekkäin.

Puhumattakaan kaiuttimesta, jonka läpi on tulossa sprinklersuutin samassa kohdassa.

Ja miksi näin? No jospa arkkitehdille olisi annettu edes jonkinlainen mahdollisuus tehdä 
alakattosuunnittelu talotekniikkasuunnittelijan tietojen pohjalta?

Nyt hän saa jotain tietomalleja, joista ei selviä päätelaitteiden paikka tai ne ovat ainakin aivan kummallisissa paikoissa (siis arkkitehdin mielestä). Sen jälkeen nuori, juuri valmistunut arkkitehti joutuu laittamaan tate-komponentit paikoilleen. Koulussa tälle arkkitehdille on iskostettu päähän taiteellisuutta ja kokonaisuuden hallintaa - hän päättää, hän tietää.

Jälleen kerran on unohdettu suunnittelu ja vaiheistus. Projektin vetäjille alakattoasiat ovat yksi pieni vaihe projektissa, joka menee perinteisesti aina väärin. Se on kuin reikäkuvat, aina piikataan.

Eräs Skanskan (iso)johtaja on kuulemma sanonut jotain tähän tyyliin: "Rakentaminen on helppoa. Niin kauan kun valetaan enemmän kuin piikataan, niin se on taloudellisesti kannattavaa". Tämä siis täyttä kuulopuhetta eikä firmakaan välttämättä ole oikea.

Alakatoissa muutostyöt ovat onneksi helpompia, mutta muistan itsekin olleeni työmaalla pohtimassa miten kamat saadaan mahtumaan määrättyyn tilaan tai paikkaan. Näistäkin tupakinmittaisista tuumaustauoista voi päästä eroon noudattamalla näitä ohjeita:

Yleissuunnitteluvaihe
1. TATE tekee 2d-leikkaukset, joiden perusteella saadaan alakattokorko

2. ARK ja RAK tekee 3D-mallihuoneen tai -alueen jonne yhteistyössa arkkitehdin kanssa TATE mallintaa päätelaitteet alakattoon. Huomioi se, että ennen mallinnusta on tästäkin alueesta tehty 2d-leikkaus TATE:n toimesta.

3. Molemmat vaiheet tehdään keskustelevasti, suunnitelmallisesti. Ei mitään "tässä on 
tiedosto, piirtele siihen", vaan istutaan saman pöydän viereen ja jutellaan - suunnitellaan.

Toteutussuunnitteluvaihe
1. TATE istuu arkkitehdin kanssa alas palaveriin ja varmistetaan, että yleissuunnitteluvaiheen ratkaisut pätevät vielä. Alakattomaailma tarkennetaan, eli minkätyyppisiä alakattoja olisi tulossa. Avattavuus, huollettavuus, avoimeisuus, luukut jne. käydään läpi.

2. TATE skissaa, kertoo, perustelee ja pyörittelee arkkitehdille perusratkaisut erilaisiin 
tilatyyppeihin. Kertoo reunaehdoista. Vähintään kaikki toistuvat perusratkaistut tulee käydä läpi, mielellään koko rakennus.

3. Arkkitehti piirtää (huom - ei mallinna) alakattopiirustuksen. 2D-alakattopiirustuksessa on kaikki tate-komponentit sijoitettu kuten alakattopalaverissa oli sovittu.

4. Arkkitehti mallintaa alakaton oikeaan korkoon, alapinta on halutussa korossa, paksuudessa huomioitu tukirakenne.

5. TATE mallintaa omat komponentit 2d-alakattokuvan mukaisesti x-y suunnassa oikeaan paikkaan ja 3d-alakattomallinnuksen kanssa korkeusasemaltaan oikeaan paikkaan.

Ym. prosessi toimii teknisesti aina. Valitettavasti suomalainen rakennuttamisprosessi ei tätä metodia tue.

Ja toinen ongelma voinee olla se, että arkkitehtiä sekä tate-suunnittelijaa ei kiinnosta siirtää tätä suunitteluvaihetta toteutussuunnitteluvaiheen alkuun, vaan haluaisivat tehdä sen loppupuolella "kun kaikki asiat on löytäneet paikkaansa". Aivan hölmö peruste.

Tiedän, että ammattilaiset osaavat tehdä päätelaite -ja valaisinsijoitukset ennen kuin mitään on mallinnettu.

Joku voi ihmetellä, miten ym. liittyy tietomallinnukseen. Voin kertoa, että sen on juuri tätä. Tietomallinnus on prosessimuutos rakennus- ja infrateollisuudessa. Tietomallinnus ei ole cad-softan jatke, sillä ei ole juuri mitään tekemistä alakattojen mallintamiseen. Softat ovat vain työkaluja muiden työkalujen joukossa.

Ei saa hämääntyä tietomallinnus -sanasta. Kyse on kuitenkin vain suunnittelusta, rakentamisesta ja kiinteistöjen ylläpidosta.

Helppoa.

Palatakseni alkuperäiseen aiheeseen, IDM ja MVD:













keskiviikko 19. lokakuuta 2011

Open BIM Blues

Kitaramusiikki on aina ollut lähellä sydäntäni ja nyt OpenBIM -porukka on tehnyt hienon promootion tietomallinnuksen hienouksista.


Onneksi olkoon, Graphisoft, Tekla, DDS ja muut .

perjantai 14. lokakuuta 2011

Talotekninen suunnittelu erään firman silmin

En malta olla mainostamatta työpaikkani Olof Granlundin tekemää 50v juhlakirjaa firman taipaleesta talotekniikan piirissä 1900 -luvun puolivälistä tähän päivään asti.

Kirja on luettavissa nettisivujemme kautta PDF-versiona. Ihan kaikkea ei ole tämän blogin kirjoituspäivänä vielä julkaistu, mutta luettavaa on kuitenkin jo ihan riittävästi.

Opus taustoittaa mielestäni hienosti taloteknisen suunnittelun kehitystä sekä antaa kuvan insinööritoimiston työnkuvan muutoksesta nykysuomessa.

Perusasia ei ole kuitenkaan muuttunut. Suunnitteluinsinööri haluaa olla tilaajan paras asiantuntija ja ajaa toimeksiantajan etuja annetussa tehtävässä.

Iso kunnia kirjan tekemisestä menee Rakennusneuvos Reijo Hänniselle (periaatteessa eläkkeellä), Tuotekehitysosaston vetäjälle Markku Jokelalle (kenties eläkkeellä) ja jokaisen alan monitoimimiehelle Harri Aavaharjulle (suomen nuori toivo jazz-trumpetistien piirissä).

perjantai 30. syyskuuta 2011

TATE-suunnittelu ja luonnosvaihe

Huomasin vuoden 2010  lopulla, kuinka tyhmä olen.

Luulin, että kaikille suunnitteluosapuolille ja tilaajille on jo selvää se, että nykyisenkaltaista suunnitteluprosessia noudattamalla TATE-suunnittelija ei voi tehdä luonnosvaiheessa koko rakennuksen kattavaa tietomallia. Asiastahan on puhuttu vasta noin 10 vuotta.

Kunnes käsiin tippui muutamia tarjouspyyntöjä, joissa pyydettiin talotekniikan massaluetteloita sekä ehdotus-, että yleissuunniteluvaiheen lopussa. Vähän aikaa meni kelatessa, että mitäköhän niissä oikeasti tarkoitetaan?

Jos TATE-suunnittelija osaisi suunnitella kohteen luonnosvaiheessa, niin mihin tarvitaan toteutussuunnitteluvaihetta?

Vuoden 2011 missioni näyttää olevan tämän lauseen toistaminen: "Suunnitellaan ensin, mallinnetaan sitten". Tuo ei tarkoita sitä, ettäkö mallinnus olisi turhaa - ei tietenkään. Mutta ennen mallintamista pitää miettiä. Pitää arpoa eri vaihtoehtoja. Vaihtoehtoiset ratkaisut ovat niin yleismaailmallisia asioita, että ei niitä kannata mihinkään mallintaa.

Kollegani sanoi hyvin: "Ehdotussuunnittelu on sitä, että poltetaan tupakkaa ja juodaan konjakkia". Olen täsmälleen samaa mieltä. Siinä vaiheessa pallotellaan ideoita, keskustellaan ja ihmetellään. Joku ehdotus voi jalostua jopa skissiksi asti. Tai ainakin lauseeksi muistioon.

Kun voittanut ehdotus on muotoutunut, sitä aletaan tarkentaa. Simuloidaan olosuhteita, energiaa jne. Tutkitaan, toimiiko vaihtari. Jos ei toimi, niin muutetaan sitä hieman. Mallinnetaan vaikkapa mallihuone. Sen voisi vaikkapa visualisoida, jotta käyttäjäkin tajuaisi, mitä on saamassa. He voisivat vaikuttaa asioihin, kun juna ei ole mennyt vielä  ohi.

Kun ollaan päästy eteenpäin, niin aloitetaan yleissuunnittelu. Mennään vielä pidemmälle vaihtoehdon tutkimisessa. Mutta ei tehdä missään nimessä koko rakennuksen kattavaa TATE-verkostoa.

Yleisuunnitteluaika on TATE-puolelta avustavaa suunnittelua. Autamme rakennesuunnittelijaa ja arkkitehtiä, jotta he saavat omat mallinsa tehtyä. Kerromme tilavaraukset, kerromme reititykset jotta ei tule yllätyksiä palkistojen kanssa.

TATE-tekee 2D-leikkauksia. Kyllä, luit oikein. 2D-leikkaus. Siis ei mallista otettu, vaan sellainen perinteinen, piirretty leikkaus. Sen avulla  kerromme esim. alakattokorot. Hyvässä projektissa yleissuunnitteluvaiheen 2D-leikkaukset pätevät myös toteutussuunnitteluaikana. Niiden perusteella 5 TATE-mallintajaa voivat aloittaa omien järjestelmiensä mallintamisen siten, että verkostot eivät törmäile. Kaikilla on selvä reitti, missä korossa kulkea.

Kun TATE-suunnittelijalta vaaditaan "mittatarkkaa ja virheetöntä mallia" (ei muuten voitu jättää tarjousta tuosta kohteesta) niin toivoisin, että suunnitteluvaiheiden sisältöä kunnioitettaisiin. Eri suunnittelualojen vaiheistus ei ole olemassa ihan turhaan hyvässä suunnittelunohjauksessa.






perjantai 16. syyskuuta 2011

Revit IFC rajapinta Open Sourceksi

Nyt kuuluu kummia Autodeskin tehtaalta.

Revitin IFC rajapinta on aukaistu ja jokainen pääsee koodaamaan omia lisäyksiä siihen:
http://sourceforge.net/projects/ifcexporter/

Tämä ei ole mikään krakkeriversio, vaan Autodeskin virallinen aukaisu:
“For several years now, our customers have been asking for greater flexibility with the Revit IFC file format output,” said Jim Lynch, vice president, Building and Strategic Technology Group, Architecture, Engineering and Construction Solutions, Autodesk. “The decision to release the Revit IFC exporter code as open source furthers our ongoing commitment to support the IFC standard, and marks the latest demonstration of the Autodesk drive to encourage full data exchange within a Building Information Modelling workflow.”

Suomalaiset "Isot Pojat" latasivat kehitysympäristön - ensimmäinen kommentti oli, että "ei siellä DLL:ssä mitään ollut". No, voipi olla pojat ei vaan osanneet... seurataan mielenkiinnolla kehitystä.
Mielenkiintoiseksi asian tässä tekee myös se, että tunnetusti Revitissä on ollut ehdottomasti huonoin rajapinta IFC-exportissa verrattuna muihin isoihin bim-softiin.
Sanooko Autodesk vuoden päästä, että, "Sorry, ei mahda ongelmille mitään, koska se on open sourcea ja vaikea valvoa jne. käyttäjät ei tee tarpeeksi hyviä rajapintoja..." vai jatkavatko he itse ifc-rajapinnan kehittämistä?
Oletan, että tottakai adesk jatkaa kehittämistä itse, muuten menee pohja pois koko touhulta. Tällä tavalla he saavat hienosti selville, kuka koodari osaa IFC:tä (ja rekrytoida heidät), ja he saavat kenties toivottavasti vihdoinkin toimivaa koodia - ilmaiseksi.
Tunnettuahan on, että AutoCAD Architecturen IFC-kehitystiimi on erillään Revitin IFC-rajapinnan kehitystiimistä. Tai tiimistä on vaikea puhuia, jos yksi kaveri on tehnyt sitä... kohta niitä lienee siis 3-5 kaveria.
Väittäisin tätä systeemiä jopa nerokkaaksi.
Ja voipi olla mahdollisuus jopa siihen, että me loppukäyttäjät jopa hyödymme tästä.

Viikon koodi:
Tämä kuuluu kuulemma IFC-tiedostoja lukevan ohjelman ensimmäisille riville:
"If Revit then End"

lauantai 3. syyskuuta 2011

Betatestausta lisenssirahoilla

On se vaan hienoa olla cad-softafirmojen betatestaajina, maksaen täydet lisenssihinnat ja sen päälle vielä vähän extrajuttuja, joita softafirma on suuressa viisaudessaa halunut firmalta vaatia. (extrat eivät ole tämän blogin aihe, mutta voisi näistä ylimääräisistä maksuistakin jotain joskus kirjoittaa...)

Viimeisin ongelma tuli eteen Autodesk Navisworks 2012 päivitysten kanssa. Eipä se sitten ollutkaan yhteensopiva version 2011 kanssa.

Menin siihen lankaan, että kuvittelin jonkun Autodeskillä avanneen 2011 versiolla tehdyn yhdistelmämallin (nwf, jossa nwc -tiedostoja linkitttynä) 2012 versiolla, mutta taisin olla väärässä. Eivät varmaan olleet avanneet. Tai sitten heillä on laittomat versiot omissa koneissaan, jotka eivät tutki lisenssejä jne.

Tässä hätäisimmille ongelman ydin:
http://beyonddesign.typepad.com/posts/2011/06/nwc-files-cant-be-loaded-in-navisworks-2012-nwfs-.html

Lopputuloksena työpaikallani kaikki 2011 versiolla tehdyt nwffät pitää deletoida, tehdä uudet nwc:t kaikista malleista ja tehdä uudet nwffät, uusilla linkityksillä, uusillä näkymillä, uusilla värityksillä, uusilla animaatioilla jne.

Yhdistelmämallien lukumäärä lähenee sataa, ajallinen menetys arviolta 300 tuntia.

Jälleen sama kysymys: Kenelle saan lähettää laskun?

Navis 2012 julkaistiin muistaakeni huhtikuussa 2011. Miten on mahdollsita, että vieläkään ei ole service packia tähän ongelmaan olemassa...? (Syyskuun 3,  2011).  Mitä softafirmat ajattelevat heidän asiakkaidensa softilla tekevän...? Leikkivän jotain kivoja juttuja?

Voin paljastaa heille salaisuuden. Niillä softilla tehdään töitä. Laitetaan kone aamulla päälle, aukaistaan ohjelmat ja mallinnetaan päivä. Sitten se kone suljetaan ja sama juttu seuraavana aamuna.

Yleensä viikonloppuna kone olisi kiinni, mutta kun softan aiheuttamia ongelmia on pitänyt viikolla selvitellä, voi olla, että pitää vielä tulla viikonloppuna paikkaamaan aikataulua.

Tekla, Graphisoft: tehkää pliis HVAC/E -softa!
Ei se DDS tai Plancal niin hyvä kuitenkaan ole.




Päivitys 9.9.2011:
SP1 on julkaistu.
Asennus lähee "Multilingual" versiona win7 64bit english koneessa hienosti saksankielisenä...:


Saapa nähdä, korjaako se kuvaamaani ongelmaa. Adeskin mukaan korjaa, mutta arvaa uskonko - testataan kunhan pääsen sekoittamaan jonkun projektityöntekijän koneen. Ja sitten asennetaan softia mallinnusajalla taas uudelleen.





perjantai 19. elokuuta 2011

Kansalliset tietomalliohjeet (cobim)

Kesälomat on pidetty, akut ladattu ja tämäkin blogi lähtee jälleen liikkeelle.

Ajattelin informoida näin oman blogini kautta, että kansallisten tietomalliohjeiden päivitysprosessi etenee, eikä ole jäissä vaikka sellaistakin olen jostain kuullut.

Kyseessä on siis Senaatti kiinteistöjen ohjeistuksen päivitysprojekti vastaamaan viimeisinä vuosina saatuja käytännön oppeja ja kokemuksia.

Talotekniikanohjeistus (osa numero 4) kokee mielestäni kohtalaisen muutoksen - konkreettisempaan suuntaan.

Kantaa otetaan mm. siihen, että mikä olisi oltava tate-mallin tarkkuustaso ja tietosisältö  toteutusvaiheessa. Valitettavasti tuota en osaa ihan konkreettisesti määritellä koska kuten tiedämme, kohteet ovat eriarvoisia. Elementtikerrostaloa ei voida tehdä samoilla ohjeilla kuin museoviraston suojelemaa arvokohdetta.

Luonnosvaiheessa otetaan kantaa mallinnuslaajuuteen, jonka voisi kiteyttää siihen, että: "Suunnitellaan ensin, mallinnetaan vasta sitten".

Luonnosvaiheessa tehdään tilavaraukset (arkkitehti mallintaa tilat, TATE-suunnittelija vaakasuuntaiset verkostot). Luonnoksissa tehdään perinteiset 2D-leikkauskuvat. Luonnoksissa tehdään palvelualuekaaviot.

Ja kaikista tärkein juttu: Laaditaan tavoitteet suunnittelulle. Mihin mallia käytetään? Mihin lämpötiloihin kesäaikainen jäähdytys eri tiloissa suunnitellaan? jne.jne.

Uusina asioina työpiirustustasolla nostetaan seuraavia asioita:
- "punakynäpiirustusten" mallintaminen, tuotetietojen päivitys
- Säätöpiirustusten tekeminen
- Sprinkleriverkostot tulee tehdä mallintaen ja käyttäen mallipohjaista laskentaa

Ja kun kaikki on kunnolla mallinettu ja laskettu, voidaan työmaalle toimittaa urakoitsijaa helpottavia asiakirjoja ja malleja. Säätöpöytäkirjat saadaan mallista, yhdistelmämallilla voidaan tehdä työnsuunnittelu.

Ym. kappaleesta tulikin mieleen: Urakoitsijat, kouluttautukaa yhdistelmämallien käyttäjiksi. Niistä on teille todellista hyötyä, kun malli on kunnossa. Ymmärrän täysin, että susimalli lentää roskikseen jos siihen ei voi luottaa, mutta kun me suunnittelijat opimme tekemään toimivia malleja, niin hyödyn korjaatte Te.

Lausuntoversiot ovat jakelussa projektin johtoryhmän jäsenille, mutta näppärimmät voivat ne kooklellakin löytää... tai sitten laittamalla minulle viestiä.

PS. Osa 9, tate-laskelmat kannattaa myös lukaista, jos jostain löytyy. Mukana uusia esimerkkejä valottamaan eri tate-laskentojen eroja.



torstai 23. kesäkuuta 2011

MSc tutkinto tietomalleista

No niin, kaikki opiskelunhaluiset. Kipikipi tänne:
http://www.salford.ac.uk/news/details/1393

Arto ihan oikeasti tietää kaiken - loistava kaveri.

Olen nähnyt tulevaisuuden

Olin viime viikolla yhtenä osana suomalaista valtuuskuntaa tutustumassa USA:n ja varsinkin San Franciscon alueen tietomallipohjaiseen suunnitteluun ja rakentamiseen.

Viikon reissumme alkoi yritystapaamisilla, jatkui CIFE:n Summer Programilla ja päättyi kahteen sairaalakohteen työmaakäyntiin (UCSF Medical Center at Mission Bay, 23.000m2  ja  Sutter Medical Center Castro Valley, 22.000m2).

Kaksi kovaa, Rakennusneuvos Reijo Hänninen ja Professori Martin Fisher


Retken pelasti käyminen DPR:n työmailla - CIFE:n Summer Programin aihealueena oli Kiinteistöjen ylläpidon ja tietomallinnuksen yhdistäminen (FM+BIM), tai ainakin sillä mielellä menin luentoja kuuntelemaan.

Pitää sanoa, että jenkit osaavat kyllä esiintymisen, mutta tällä kertaa Summer Program oli pettymys. Kiinteistöjen omistajat kertoivat, että heillä on kiinteistöissä automaatiojärjestelmät, joita seuraamalla voidaan tietää mitä rakennukselle kuuluu. Ja että pitää analysoida mittarointien tuloksia, jos haluaa ylläpitää kiinteistöjä oikein.

Ei tuota varten olisi pitänyt jenkkeihin asti mennä.

Ei koko ohjelma kuitenkaan hukkaan mennyt, nyt vahvistui käsitys muutamasta ennaltakin tiedetystä asiasta: tuleviin rakennuksiin pitää tehdä kunnollinen mittarointi, kerroskohtainen, osastokohtainen jne. Käyttäjien on päästävä näkemään, mitä rakennus kuluttaa, jotta heidän käyttötottumuksiin voidaan vaikuttaa.

Erilaiset dashboardit, monitorit auloissa / käyttäjän omalla koneella kertovat reaaliaikaista tietoa siitä, kuinka paljon energiaa kuluu - tälläkin vaikutetaan käyttäjään, valot sammutetaan (käsin tai automaattisesti), kun tiedetään, että sillä voidaan aikaansaada säästöjä.

Pitää sanoa, että välillä ihmetyttää jenkkien teot. Toiset asiat ovat täyttä high-techiä, toiset taas aivan käsittämätöntä räpellystä. Ihmetyttää, onko tuo kansa todella käynyt kuussa...

Sairaalakohteiden työmaakäynneillä tutustuimme IPD projektien hienouksiin. Mission Bayn kohde oli julkinen rakennelma ja Sutter Healthin kohde yksityinen. Se toi sopimustekniikoihin muutaman lisäjuonteen. Mutta perusperiaate oli kuitenkin sama. Kaikki tekee yhdessä rakennusta, jokaisen panosta tarvitaan. Autetaan kaveria, kun sillä on ongelma ja suunnittelu, rakennuttaminen, käyttäjä ja urakoitsijat ovat samassa veneessä.

Oli todella hieno nähdä myös se, kuinka ylpeitä kohteiden esittelijät olivat toimintatavastaan. Perusjenkkityyliin kaikki oli hienoa ja mahtavaa. Jollain tapaa uskon sen näin olevankin. Ihan kaikkiin vaikeisiin kysymyksiin en saanut vastausta, mutta toimintatapa, jossa tehdään yhdessä töitä, on ilmiselvästi toimiva.



Tajusin IPD projekteista sen, että tietomallinnus on vain työväline. Koko homman juju on projektin vetäminen ja sen seuranta. Näissä projekteissa kaverit todella suunnittelevat ennen kuin aloittavat tekemään. Mallinnusta ei lähdetä suorittamaan, ennenkuin palaset on loksautettu paikalleen. Kaikenlaisia post-it -lippulappu juttuja näkyi seinillä, Big Roomissa oli käyty syvällisiä keskusteluja erilaisista toteutusvaihtoehdoista.

Oli aikamoinen shokki astua työmaatoimistoon sisälle. Luulin, että homma tehdään jossain isossa neukkarissa (big room). Oven takana oli arviolta 500m2 toimistoa, jossa 20-30 henkeä oli tietokoneiden takana töissä. Ei mikään ihan perustyömaakoppi. Samassa avokonttoritilassa olivat arkkitehdit, rakentajat aliurakoitsijoineen sekä erikoissuunnittelijat. Jos arkkitehdillä oli joku asia ratkaistavana, ei tarvinnut lähetellä sähköposteja, riitti että meni juttelemaan ko. alueen suunnittelijalle.

Melkein AC/DC, virtuaaliyrityksen pääkonttori.

Ilmankos DPR puhui, että haastavaa hommassa on virtuaaliyrityksen perustaminen. Sitä tuo homma todella oli, monta eri firmaa saman katon alla, yhteisissä tietojärjestelmissä, yhteisessä tietomallissa kiinni.

Talotekniikkaurakoitsijalla oli täysi sananvalta suunnitelmiin - jos (ja kun) he keksivät jonkun helpomman ja kustannustehokkaan asennustavan joka oli hyväksyttävissä myös suunnittelijan toimesta, niin se toteutettiin. Säästynyt rahasumma meni koko IPD ryhmän yhteiseen kassaan, josta eri prosenttiosuuksilla kerätään voitot pois.

Mukana suunnittelutiimissä oli myös kohteen kiinteistönhoitoyritys. Kun suunnittelija ja urakoitsija keksivät jonkun järjettömän ratkaisun, jossa piilotetaan huollettavat kohteet seinien sisään, niin huoltohenkilökunta pystyi puuttumaan siihen. Jälleen toimenpide, jolla rakenuttaja saa mitä tilaa - toimivan rakennuksen.

Jep, urakoitsijat uskaltavat koskea tietokoneisiin

IPD kohteissa ei muuten ollut kaivuria työmaalla ennen kuin kohde oli suunniteltu riittävän pitkälle (terveisiä vaan projektinjohtourakoitsijoille...). DPR on hahmottanut ja toteuttanut sen ihanteen, että panostamalla alkuvaiheessa todella kokonaisvaltaiseen ja tehokkaaseen suunnitteluun voitetaan työmaavaiheessa kustannukset moninkertaisesti takaisin. Eli ihan perusjuttuja, jotka kaikki rakentamisen ammattilaiset tietävät: suunnitellaan ensin, suunnitellaan vaiheistettuna. Sitten rakennetaan, kun tiedetään mitä tehdään.

Ei se voi olla vaikeata. Ekonomeilta pitäisi kieltää excelin käyttö, ei rakennusprojekti tuota enempää rahaa, jos aletaan tehdä liian aikaisessa vaiheessa sutta työmaalla. Kun tehdään kunnon kohde, jossa on elinkaarimalli mukana, niin rahaa virtaa vielä rakennuksen valmistuttuakin.

Nyt pitää lopettaa puhuminen ja aloittaa tekeminen. IPD on tulevaisuutta toivottavasti myös suomessa. Tarvitaan rohkeutta, intohimoa ja asiansa osaavia henkilöitä.

Tietomallinnustekniikka on meillä hallussa, pitää vain saada sopimustekniikka ja asenne kuntoon.

Viikon kuva

Kävin lähellä taivasta.
Haight Ashbury Music Center hippialueella... jos sieltä ei löydy kitaraa, niin ei sitten mistään...

perjantai 27. toukokuuta 2011

Salaa mallinnetut kohteet

Kuinkahan monta kohdetta on suomessa viimeisten vuosien aikana mallinnettu suunnitteluryhmän
toimesta "salaa", tilaajalta tietämättä?

Eli on sattunut kohtaamaan firmat, joilla sisäisenä, normaaliina tapana on mallintaa kohteet.
Mutta koska mallinnusta ei ole tilattu, ei sitä silloin täysimääräisenä hyödynnetäkään. Ainakaan
ulospäin.

Ei anneta kaverille mallia käyttöön, josta toinen voisi jopa hyötyä - työmaasta nyt puhumattakaan.
On tilattu vain piirustukset - mallin kauttahan joku voisi nähdä, että jollain väliseinällä on
väärä koodi...

Voin kertoa tilaajille yhden salaisuuden. Jos kohteenne on vähänkään liikerakennukseen viittaava,
niin se on mitä suuremmalla todennäköisyydellä tehty softilla, joilla syntyy myös tietomalli.
Ja riippuen firmasta, sisäiset laatukriteerit jo takaavat ihan hyvän lopputuloksen
tietomallinnuksen suhteen.

Jos suunnittelufirmalla on oma käytäntö tehdä joku asia, se on yleensä sille firmalle paras tapa.

Pienellä tönäisyllä esim. arkkitehtisuunnittelun puoleen saadaan täysverisen tietomalli kohteesta.
RAK ja LVIS/SPR yleensä seuraa mukana, jolloin käsissä onkin täysiverinen yhdistelmämalli
ylläpidon käyttöön (mitä se sitten tarkoittaakaan...)

Se voi maksaa jopa 3-5% lisää suunnittelukustannuksista. On aivan varma, että tuo voitetaan
takaisin moninkertaisena urakoitsijoiden valintatilanteessa / työmaavaiheessa.

Rakennuttaja - luota suunnittelijaan. Hän haluaa olla kaverisi.

perjantai 20. toukokuuta 2011

Origo

Kuinka vaikeata tämä voi olla?

Meni hermot tänään hommissa.

1990 luvulta lähtien on ollut selvää, että kaikkien suunnittelijoiden pitää tehdä mallit samaan origoon.

Rakennuksen mallintamisessa ei ole olemassa kuin yksi origo. Se on se, jonka arkkitehti on suuressa viisaudessaan sopinut. Kaikkien tulee noudattaa sitä origoa.

Korkomaailma tulee olla absoluuttinen. Ei ole olemassa muuta korkoa objektille IFC-mallissa, kuin absoluuttinen korko.

Uskokaa nyt jo kaikki tämä asia. Ollaan harjoiteltu 20 vuotta, eikö tämä asia nyt jo voitaisi tietää ihan kaikkien kesken...

Ja arkkitehdille vinkiksi:
- world -origo on lähellä rakennusta
- rakennuksen koordinaatisto ei ole sama kuin mittamiehillä / kaupungilla / suomella. ARK on velvollinen laittamaan rakennuksen suoraan world- origon suhteen, vasempaan alakulmaan, jonnekin lähelle rakennusta. Asemakuva on eri asia, se on valtakunnan koordinaatistossa. Tai kaupungin. Tai jossain, mihin GEO sen haluaa.
- z-korko on yhdistelmämalleissa absoluuttinen korko merenpinnasta, leikkauskuvien mukainen.
- JA SITÄ ORIGOA EI MUUTETA KESKEN PROJEKTIN

Niin monta turhaa työtuntia lähtisi pois, jos nämä asiat ymmärrettäisiin-

keskiviikko 18. toukokuuta 2011

Suomalaiset softafirmat tietomallinnuksen kärjessä

Suomi on kummallinen maa. Joku keksii jalostaa kumisaappaasta kännykän, toinen taas tekee oman käyttöjärjestelmän tietokoneeseen, kun ei tykkää tarjolla olevista.

Tietomallinnuksessakin ollaan menty maassamme kohtalaisesti vastavirtaan. Kun muut puhuvat 3D:stä, täällä jo tarkastetaan malleja sääntöpohjaisesti. Kun muualla ihmetellään, miten kanttikanavan kulmakappaleesta saadaan levityskuva metallipajalle, täällä ollaan laskettu sen osan painehäviö tietyllä virtaamalla.

Kun täällä on laskettu yli kymmenen vuotta mallipohjaisesti rakennusten energioita, esittelee suuri ja mahtava cad-ohjelmistotuottaja asian suurena uutuutena uudessa softassaan.

Kuulin, että Tanskassa Ramboll esittely ylpeänä uutta pääkonttoriaan ja sitä, kuinka se on suunniteltu hyödyntäen tietomallinnusta. Rakenteet on suunniteltu Teklalla, talotekniikka MagiCADillä ja yhdistelmämallit / tarkastus Solibrilla.

Tilaisuudessa oli kuulemma hienoa olla suomalainen.

Sanat Solibri, MagiCAD ja Tekla saivat minun silmiini uuden kumppanin eräiden tapahtumien kautta. Se on Vico Software. En oikeataan tiedä, kuinka suomalainen tuo firma on (ei juuri ollenkaan), mutta ainakin minä haluan pitää sen suomalaisena.

Mallien kautta paukutetaan kustannustietoa, 5D-tietoa ja muuta taaloihin / euroihin sidottua arvoa sellaista vauhtia ulos, että heikompaa alkaa hirvittää. Kaiken perustana on kuitenkin toimivat mallit - ja kas kummaa, Vicon yksi suuri osa-alue on konsultointitoiminta / mallinnus. Eli kun mallinnetaan tietäen mikä käyttötarkoitus mallilla tulee olemaan, alkaa hyötyjä näkyä. Kun koulutetaan mallintajat tekemään asioita oikein, alkaa neliöt ja kuutiot muuttua euroiksi (tai Vicon tapauksessa varmaankin taaloiksi).

Kannattaa lukea Seppäsen Ollin (ei se proffa, mutta tekniikan tohtori kuitenkin) blogia, viisaita sanoja fiksulta kaverilta. Ja asennekin on kohdallaan.

No entäpä Tekla. Perinteinen ja vanha suomalainen pioneerityön pikkujättiläinen. 1970 luvulta lähtenyt firma, joka on aina ollut vähän liikaa aikaansa edellä. Tehnyt softaa firmoille, jotka eivät ole tajunneet mitä he uusmmalla softaversiolla tekisivät. Tai ovat tajunneet sitten 8 vuoden päästä, mutta yleensä silloin on ollut jo liian myöhäistä - maailma ehti muuttua.

Kunnes rakennesuunnittelufirmat 2000 luvulla hahmottivat, miten hyötyä Teklan tuotteista - myynti lähti nousuun, ero kilpailijohin oli selkeä. Ja eipä mennyt aikaakaan, kun ison veden takaa tuli taalasäkki pääomistajien harteille ja kehitys alkaa uusilla näkökulmilla.

Voisinpa jopa sanoa, että onneksi olkoon Tekla!

Toivon todella, että ostajana ei ole bulvaani erään toisen firman toimeksiannosta.


Solibri.

Solibri, Solibri, Solibri.

Jos puhutaan softasta, joka on aikaansa edellä, niin tässä on voittaja. Kuulemani mukaan firman johdolle on on tullut jo 1990 luvun puolivälissä ajatus esille (tai silloin ei ollut vielä firmaa, mutta ajatus oli...). Jos "uudessa tuotemallimaailmassa" mallinnetaan ovia, ikkunoita, seiniä ja ne tietävät itse mitä ovat, niin voidaan ohjelmallisesti tehdä tarkistuksia niiden oikeellisuudesta. Tämä lause on oma tulkintani, en tiedä, kuinka paljon heittääkö todellisuudesta.

Mutta pointti on se, että miten jollekin voi tulla tuollainen ajatus mieleen aikana, jolloin puhuttiin tasojen nimistä, viivojen väreistä ja muusta täysin turhasta.

2000 luvun alussa alkoi tulla toimivia tarkastusohjelmia - vain kunnolliset mallit puuttuivat. Taas softafirma on aikaansa edellä, sisällöntuottajat eivät pysty toimittamaan sellaisia tuotoksia, että ohjelmaa voisi fiksusti käyttää. On turha tehdä tarkastusraporttia siitä, että seinät eivät ole mallinnettu seinäobjekteina. Sen piti olla itsestäänselvyys.

Nykyaikana suunnittelutoimistot alkavat olla jo sillä tasolla, että Solibrista alkaa olla oikeasti hyötyä. Se on todellakin jotain muuta kuin IFC-viewer. Se on Checker.

Ja nyt sinne saadaan sisälle malleja, jotka on tehty tietomallintaen - ohjelman 10 vuotta vanhat ideat alkavat vihdoin toteutua.

Kunnes joku ostaa senkin.

lauantai 30. huhtikuuta 2011

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ä

sunnuntai 10. huhtikuuta 2011

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.




keskiviikko 30. maaliskuuta 2011

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

tiistai 22. maaliskuuta 2011

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.

sunnuntai 13. maaliskuuta 2011

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ä:

tiistai 8. maaliskuuta 2011

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.

lauantai 26. helmikuuta 2011

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