Dynamo / Vasari

Nyt alkaa pelottaa...

Ei KHL -seuran eteneminen liigassa, vaan Autodeskin uudet tuulet.
http://dynamobim.org/

Dynamo yhdistettynä Vasarin ajatuksiin tulee aiheuttamaan uusia tuulia alkuvaiheen simuloinneissa:
http://autodeskvasari.com/

Mitä Autodeskillä on tapahtunut viimeisen parin vuoden aikana? Ihan kuin he alkaisivat ymmärtää asiakastansa...? Tai sitten Open Sourcella saa lisää todellisia innovaatioita (vertaa Revit IFC rajapinta: http://tietomalli.blogspot.fi/2011/09/revit-ifc-rajapinta-open-sourceksi.html )

Hienoa toimintaa.


Viikon kuva:
City District Analysis

Vanha Maailma

Piti kirjoittaa, että "Uusi maailma". Siten tajusin, että se oli olemassa jo 20v sitten.

Työpaikalleni on tippunut erinomaiseen tahtiin Allianssikyselyjä - loistavaa.

Herätystä on tapahtunut.

Mielenkiintoista on, että niiden sisältö on tämän mukainen:
http://portal.liikennevirasto.fi/portal/page/portal/f/uutiset/2011/9_10_2011/06102011_lj-paivat/13Vaihtoehtoiset_hankintamuodot.pdf

Kaikki kunnia Liikennevirastolle, He ovat tehneet kenties suurimman rahallisen säästön rakentamisen sektorilla kuin jos olisi toimittu "kuten ennenkin".

Tsekatkaapa sivu 12 ja 25.

Kummallista, että osassa allianssikyselyistä on sivu 25 mukana... (kohdassa "Sopimustekstiä").

Kopionti kunniaan jos se on sisällöltään OK. Tuo sivu on nähty aika usein.

Toisaalta, en näe tuossa ongelmaa, kun sisältö ja asiantuntemus tukee tekstiä.


Viikon Kuva:

Tärkein vaihe suunnittelijan näkökulmasta: Kehitysvaihe.

Lean Construction seminaaria tarjolla

Älkää missatko tätä:
http://vison.fi/uutiset.html?35

Lean Construction seminaaria tarjolla, pääesiintyjänä Michael Bade, kaveri joka väänsi julkisen hankintalain alaisen UCSF:n  (University of California, San Francisco) tilausmetodit sellaisiksi, että IPD projektit ovat mahdollisia.

Esityksen jälkeen on toivottavasti selvää, että julkisissa hankinnoissa voi aivan hyvin käyttää IPD / Allianssimenetelyä.

Tai kuten Herra Bade sanoo, se on "IPD'ish" sopimus.

Eräästä Badeen projektistä on kirjoitettu täällä:
http://tietomalli.blogspot.fi/2011/06/olen-nahnyt-tulevaisuuden.html
ja
http://tietomalli.blogspot.fi/2014/05/california-uber-alles.html


Viikon kuva:
Mr Bade UCSF:n kampuksella

Kun homma lähtee lapasesta

Muutaman kerran on tullut eteen tilanne, että ei pysty ymmärtämään toisen osapuolen ajatuksia.

Tai sitten kyseessä on normaali tilanne, jossa etsitään syyllistä ja oma vastuu pyritään siirtämään ravintoketjun seuraavalle osapuolelle.

Tässä sähköpostikeskustelua oikeasta kohteesta, jonka LVI-suunnittelutoimiston tiedän olevan TOP15 joukossa Suomen TATE-mallinnuksen piirissä. (LVI-suunnittelijan lupa julkaisulle saatu)

LVI-suunnittelija:
(edit)
"Tarkasta tietomallista on tullut työmaan jarru. Urakoitsijan alustava arvio seinärei’itysten korjaamisesta on xxxxx €.

Arviosta puuttuu vielä mahdolliset tekniikka-asennusten tietomallista aiheutuneet kustannukset.

Voisitko kertoa, mitä suuruusluokkaa yo. kohteen tietomallin päivitys YTV-mallista malliksi, jossa sallitaan 25 mm:n törmäilyt.

"

(edit)

Minä:

"

Terve xxccyy,

Minun mielestä tämä ei ole ollenkaan tietomalliasia.

Urakoitsija ei voi tehdä reikiä mitoittamattomien pohjapiirustusten / tietomallin perusteella.

Jos oikein yritetään tarkkuustasoa hakea, niin olisikohan toleranssi se, minkä 1:50 mittatikulla pohjakuvista saa mitattua?

SKOL ohjeistus reikävarausten teosta löytyy täältä:

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

Olen tuon hankkeen vetänyt, rakennesuunnittelijat ovat sen hyväksyneet skollissa

Jos teille ei ole etukäteen kerrottu, että rei'ät tullaan tekemään mallin perusteella (muihinkin seiniin kuin kantaviin) niin vähimmäisvaatimus mielestäni on, että siitä teille etukäteen kerrotaan jotta voitte kertoa, onko se edes mahdollista.

En valitettavasti pysty antamaan arviota ajankäytöstä, en tiedä toimintatapojanne. Mutta sen tiedän, että päivittämisessä ei ole mitään järkeä. Tietomallin tarkoitus ei ole olla 1:1 graafinen näkymä rakennettavasta kohteesta, vaan se on suunnitelma. Jos sitä aiotaan käyttää esim. esivalmistusten, reikien tms. tekoon kokonaisvaltaisesti, niin sitten se pitää tehdä tätä käyttötarkoitusta silmälläpitäen. Käytännössä mallinnuksen silloin tekee siis urakoitsija (kuten keskieuroopassa/jenkeissä)

Jos reikiä halutaan tehdä mallien perusteella, niin ne tulee tehdä reikävarausobjektien kautta, jotka on suunnittelija tehnyt, konnari hyväksynyt. Ei siis tasokuvin kanavien / putkien perusteella.

Kummallisesti tämä tietomallinnus tuntuu välillä hämärtävän ihan normaaleja suunnittelu- ja työmaatoimintakäytäntöjä. Ei vanhat säännöt ole minnekään kadonneet, työkalut ja prosessit ovat vain uusia (niin, jos olette tehneet suunnittelun kuten ennenkin muuttamatta toimintatapoja suunnittelutiimin yhteistyössä / työmaan keskuudessa, niin ongelmia alkaa tulla… tietoa on liikaa, sen oikeellisuutta pitää pystyä tarkastelemaan).

Tuo 25mm "toleranssi" hämää minua. TATE-kamat ovat eriarvoisia sijaintejansa suhteen eri osissa rakennusta. Näkyvillä olevat kamat varmaankin tulisi olla kohtalaisen tarkasti, mutta esim. iv-konehuoneessa tuo tarkkuus on sulaa hulluutta. Eli mielestäni ei voi katsoa suoraan mihinkään numeroarvoon, pitää osata / pystyä käyttämään järkeä.

Jotenkin minusta tuntuu, että suunnittelun ohjaus tai luulot tietomallintamisen tarkkuudesta ovat lähteneet käsistä. Jälkikäteen näiden asioiden perkaaminen on harmittavaa. Pitäisi olla ennen mallinnusta selvillä, mihin käyttötarkoitukseen sitä tullaan käyttämään. Kaikki ei ole mahdollista – joillakin voi olla luulo, että kun tehdään YTV:n mukaisesti, niin sitten on vaikka mitä mahdollisuuksia. Ei ole, ne pitää osata kertoa ennen mallinnusta.

teroj

"

Kommenttina tuohon viimeiseen kappaleeseen: Ei sellaista henkilöä ole olemassa, joka pystyy kertomaan hankkeen alkuvaiheessa, mitä tullaan tekemään ja miten. Tuo on utopiaa. Mutta se ei ole, että hommataan hankkeeseen kehitysvaihe, jossa kerätään ammattitaito samaan avokonttoriin ja mietitään, mitä tulisi tehdä - sen perusteella sitten aletaan tehdä vaatimuksia.

Jumalauta- yhteistyötä, toisen työn merkityksen ymmärtämistä ja kunnioitusta.

Circle - DNA

Viikon kuva:

Tästä palkista tehdään pienoiselokuva erään  ex-suomalaisen firman markkinointitarkoituksiin.

WWW-kysely talotekniikan tietomallintamisesta

BuildingSMART Finland Talotekniikan toimialaryhmä järjestää kyselyn koskien Talotekniikan tietomallinnusta.

Kysely on tarkoitettu talotekniikan urakoitsijoille, suunnittelijoille ja tilaajille. Kyselyn tulokset julkistetaan 3.10 Finnbuild 2014 messuilla ja vastausaikaa on 25.9.2014 asti.

Kyselyn tarkoitus on kartoittaa Suomen talotekniikkasektorin valmiutta, halua ja haasteita tietomallinnuksen parissa. Vastausten perusteella bSF Talotekniikan toimialaryhmä kehittää omaa toimintaansa vastaten kentän vaatimuksiin.

Kyselyyn pääset täältä:

http://buildingsmart.fi/uutiset.html?22

Talotekniikkatoimialaryhmän sivuille pääset täältä:

http://buildingsmart.fi/talotekniikan-toimialaryhma

No niin, kaikki hopi hopi vastaamaan kysymyksiin. Niiden perusteella saadaan kartoitettua tilannetta Suomessa ja pystytään ohjaamaan bSF TATE-toimialaryhmän toimintaa tulevaisuudessa.

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: