Tietomallistrategia

Rakennustietosäätiön palkitseman bim-gurun Tomi Henttisen (kultainen pränikkä, buildingSMART Finlandin pj)  innoittamana otan työn alle yhdyssanan: Tietomallistrategia.

Mitä tuo on?

Törmäystarkasteluja? Jotain tietomallikoordinaattorin hommia? Suunnittelunohjausta?

Jokaisessa rakennusprojektissa pitää olla taustalla tietomallistrategia. Miksi mallinnusta tehdään? Mitä laskujen maksaja siitä hyötyy? Miksi kohdetta ei kannata tehdä mallintaen, mitä jos tehtäisiin perinteisesti?

Fiksuja kysymyksiä, joihin pitää tulla vastaus ennen kuin aletaan tilata tietomallinnettua kohdetta. Jos tilaaja / rakennuttajakonsultti ei löydä vastausta mallinnuksen hyötyihin, ainoa vinkkini on:

Älkää tilatko mallinnusta!

Tehkää rakennus kuten on totuttu ennnekin tehtävän. Älkää kiusatko niitä suunnittelijoita, jotka yrittävät tehdä jotain uutta. (siis 20v sitten mahdollistettua periaatetta). Teettäkää normaali homekoulu. Älkää ottako huomioon elinkaarikustannuksia, unohtakaa tavotteiden mukaiset ilmavirrat ja olosuhteet sisäilmastossa. Älkää seuratko kiinteistön toimivuutta käytön aikana. Uskokaa, että se on ihan OK ilman huoltoakin. Muistakaa ottaa halvin tarjous joka vaiheessa ja mahdollistakaa urakoiden pilkkominen pieniksi palasiksi. Aliurakoisijan aliurakoisijanaliurakoisija on ihan OK.

Rakennuksia suunnitellaan nykyään onneksi vain harvoin rakennusmääräysten minimivaatimusten mukaisesti (mutu), koska ne asettavat minimitavoitteet ja joiden seuraukset ovat nyt havaittavissa (1970-luvulta eteenpäin tehdyt rakennukset) epäonnistuneina ratkaisuina.

On täysin selvää, että suunnittelija haluaa tehdä parhaan mahdollisen suunnitelman. Sen toteuttamiseksi Me tarvitsemme tilaajan tekemän tietomallistrategian. Jos sitä ei ole, toimimme kuten ennenkin.

Tietomallistrategia kertoo kertoo meille poloisille talotekniikkasuunnittelijoille mitä tilaaja ajattelee omasta kiinteistömassasta. Se ei kerro, miten tehdään suunnittelu, mutta se antaa suuntaviivat siihen, painotetaanko sijaintia, tehokkuutta, elinkaarea, neliöiden käyttöä, yhteensovitysta, työmaakäyttöä, energiaa vai mitä? Tämän tiedon perusteella voidaan kohde mallintaa siihen käyttötarkoitukseen, johon käyttäjä / tilaaja tähtää.

Joku voisi kuvitella, että ym. asia on suunnittelunohjausta.

Se ei ole sitä. Se on tietomallistrategiaa.

Suunnittelunohjaus on kakkosena.

Sen edellä on Tietomallistrategia

Tietomallinnus = Suunnittelua = erilainen prosessi tehdä tilaajan vaatimukset täyttävä rakennus.

Tilaaja: tehkää Tietomallistrategia, kertokaa, mitä haluatte. (max. 1kpl A4, ranskalaiset viivat OK)

Suomen valtio: tehkää rakennetun ympäristön hallintastrategia ja nitokaa tietomallit siihen kiinni jotta strategian toteuttaminen olisi mahdollsita. Näin tilaaja saa jotain kättä pidempää tehdäkseen omat ratkaisut.

Rakennuttaminen on erittäin vaativa tehtävä ja sen toteuttaminen tarpeenmukaisesti tarvitsee laajan näkemyksen ja kokemuksen.


Viikon kuva:
DPR Construction inc. : Best practices.
Kun teemme asiat fiksusti, kehitämme uudet parhaat toimintatavat joita ei ole vielä olemassa perinteisessä rakennushankkeessa.

Rakennusteollisuus: ottakaa haaste vastaan!
Yksilöt tekevät muutoksen.

Origo versio 2

Kesälomat ohi, joulua odotellessa.

Tämä on viimeinen kirjoitukseni origoista mihinkään julkaisuun. Nyt minä lopetan, nyt en enää jaksa.

Hermot riekaleina. Ei VOI olla näin vaikeaa.

http://tietomalli.blogspot.fi/2011/05/origo.html

Jälleen yksi projekti, jossa origo hakusessa eri osapuolilla noin kerran kuukaudessa vaikka ohjeistus on annettu ja jopa rakennuttajakonsultin kautta palavereissa läpikäyty useampaan otteeseen. Ja eri osapuolten välillä hyväksyttynä.

Uskokaa nyt hyvät ihmiset, että tämän sivuston ilmoittamaan origoon:
http://fi.wikipedia.org/wiki/ETRS-TM35FIN
ei voi mallintaa rakennuksia. Origo ei voi olla tyynellämerellä 25.000km päässä kun tehdään rakennusten tietomallinnusta.

Infratekniikka on eri asia, koska he eivät mallinna vielä mutteritasolle. Mutta kun Infrasektori pääsee tästä heidän tietomallinnuksen alkuhuumasta realistiselle tasolle, niin tämä kirjoitukseni alkaa koskettaa myös heitä.

Jos ette ole huomanneet, niin maaPALLO on pyöreähkö ja siinä aiheutuu mittakaavavirhe kun mallinnamme tasolla olevia kerroksia rakennukseen.

Lisäksi prosessorien liukulukuvirheet kertaantuvat, ja saamme koordinaateiksi epämääräisiä desimaalilukuja -> pitäisi olla "100,100,100", mutta se on cad softan aivoissa: "100,0000001, 100,0000001, 100,0000002". Ja kun näitä vektoreita jaetaan, derivoidaan, interpoloidaan, integroidaan, hyperventiloidaan keskenänsä niin tapahtuu laskuvirheitä. Tietokoneiden matematiikkaprosessoriosuudet eivät siis osaa matematiikkaa.
Valittakaa Intelille tai AMD:lle.

Mulle on oikeastaan ihan sama, missä se origo on (kunhan kaikilla rakennussuunnittelun osapuolilla on sama origo), jos BIM softat toimisivat tuon origon kanssa mutta kun ne ei toimi.

Sitten kun tehdään IFC-malleja, niin ainakin minä suosittelen tekemään ne siihen origoon, joka on valittuna BIM softassanne "WCS"-origoksi, eli siihen origoon, jossa tehdään todellinen mallinnus. Jos lähdetään kikkailemaan sillä, että mallinnetaan omassa origossa "WCS" ja sitten laitetaan ifc-exportissa siirtokoordinaateiksi "WCS * xyz25000" eli tehdään joku siirto jonnekin ja parhaimmassa tapauksessa myös pieni kiepsautus 28.679835 astetta (minkä origon suhteen?) niin eihän tuo voi oikeasti olla toimiva ratkaisu, kun ajatellaan kaikkia eri suunnitteluosapuolia ja heidän omia (erilaisia) BIM softia.

Jos joku sattuu suunnittelemaan / mallintamaan johonkin kylään esim. Otto -automaatteja, niin valitkaa sieltä kylästä YKSI origo, jonka suhteen nuo kaikki Otto -automaatit mallinnetaan BIM-softilla. About max. 10km päässä olevat Otot tähän samaan origoon.

Jos tuohon samaan infrakuvaan halutaan mukaan myös Nosto -automaatteja jotka ovat toisessa kylässä  200km päässä (ja niillä on oma yhteinen origo omasta kylästä), niin hakekaa näiden kahden eri maailman välille yhdistävä koordinaatisto, jotta MOLEMPIA pystytään siirtämään siihen haluttuun uuteen koordinaatistoon (vaikkapa ETRS-GK25).

Jos Frank Otto haluaa nähdä nuo automaatit yhdessä kokonaisuudessa karttapohjan päällä, niin:
a) ne näkyy kaikki, kun tehdään yhdistelmämallisoftassa tarvittava siirto Frank Otton ilmoittamaan koordinaatistoon
b) ne näkyy siinä suoraan, jos Frank Otto on rakentanut oman maailmansa tuon fiksusti valitun kyläorigon mukaiseksi
c) niitä ei näy oikeassa suhteessa toisiinsa mitenkään, koska kukaan suunnitteluosapuolista ei ole noudattanut / ymmärtänyt ohjeita ja ovat kiinnostuneita vain omasta suorituksestaan.


Lisätietoa BIM origon sijainneista:
http://files.kotisivukone.com/buildingsmart.kotisivukone.com/YTV2012/ytv2012_osa_3_ark.pdf

http://www.skolry.fi/sites/default/files/SKOL_TATE_prosessikuvauksia_201406.pdf

BIM-origosanastoa:

WCS:
World Coordinate System on Autodeskin (AutoCAD) keksintö. Se ei ole Global -origo, joka on maamittareiden maailmanorigo tyynellä merellä (ETRS-GK25 yleensä Helsingissä))

Local -origo: jotain jonka joku on keksinyt jossain. Voi olla mitä vaan, esim. WCS tai jos lokaali paikka on maapallo, niin vaikkapa tyynellämerellä.

UCS:
User Coordinate System, mallintajan oma paikallisorigo joka luodaan jos haluaa tehdä jotain mikä tuntuu itsestä kivalta. Ei vaikuta mihinkään, ei sekoita mitään, saa vapaasti käyttää.

ACS:
Auxiliary Coordinate system. Kuten UCS, esim. Bentleyn tuotteissa (Microstation).

Global:
En tiedä alkuperää, mutta jossain "hyvin" alkaneissa projekteissa sitä on pidetty sekä tyynenmerenorigona että WCS origona. Ja jos joku on halunnut, niin on myös sana "Local" on lisätty tähän yhteyteen. Ja UCS / ACS on tilanteesta riippuen sopinut tähän kategoriaan. Älä käytä tyynenmerenorigoa WCS origona.

Viikon kuva: