Nemetschek tykkää Solibrista

Sinnehän sekin sitten meni:
http://www.nemetschek.com/presse/pressemitteilungen/detail/nemetschek-uebernimmt-fuehrenden-bim-spezialisten-solibri/

Onnea Heikki, hieno homma! Hintakin vaikuttaa olevan paikallaan, jos käytäväpuheet pitävät paikkaansa.

Suomiperusteiset BIM-firmat alkavat loppua, ne ostetaan pois muiden ulkomaisten organisaatioiden sateenvarjon alle. Tekesin kansainvälistämispolitiikka toimii.

Koko maailma tietää, että Solibri on ollut edelläkävijä tietomallien hyödyntämisessä. Sen guru-arvostus on korkeinta AAA-luokkaa. Kiinnostavaa on, miten Nemetschek aikoo hyödyntää Solibrin maineen.
Ensiarvio saataneen täältä:
http://www.scia.net/nl/software/product-selection/solibri

Perusepäilevänä alkaa ajatella kysymyksiä:
- Miksi nykypäivänä ostetaan firma, joka ei tee pilviohjelmistoja?
- Miten Solibri ujutetaan Nemetschekin sateenvarjon alle?
- Tuleekohan BIMx :ään laajennus?
- Onko haluttu ostaa ylivertainen ammattitaito IFC-teknologian hallinnassa?
- Jatkaakohan Solibri duunia "kuten ennenkin"?

Lohduttavaa on se, että muutkin Nemetschekin ostamat firmat ovat jatkaneet toimintaa oman brandinsa alla, kuten Grapfisoft, DDS, Bluebeam, Vectorworks... Toivon, että tuon listan jatkona on myös Solibri. Enkä oikeastaan epäile, etteikö olisi. Varmastikin on.

Jumankauta, että on vaikea kirjoittaa sana Nemetschek oikein..

Viikon Kuva:

Dear. Prof. Nemetschek.

Let Solibri fly wherever they want to.

51 miljoonan euron säästö vuodessa (sis. BIM100%)

Liittyen tähän viestiin:
http://tietomalli.blogspot.fi/2015/02/materiaalilistat-urakkalaskentaan.html

Sekä tähän julkilausumaan:
http://buildingsmart.fi/uutiset.html?32122

voidaan todeta, että meistä insinööreistä ei ole markkinointiammattilaisiksi.

Perusteet materiaalilistojen tuottamisesta urakkalaskentaan sisältyy tähän esitykseen:
https://asiakas.kotisivukone.com/files/buildingsmart.kotisivukone.com/uutiset/bSF_TATE/bSF_tate_Tero_Jarvinen_27.11.2015.pdf

Ja sieltä pitää hakea slide 21.

Melkein hävettää, että olen osannut piilottaa asian ytimen näin syvälle.

Eli:
Säästämme Suomessa yli 50 miljoonaa euroa vuodessa tate-urakkalaskennassa, kun tuotamme TATE suunnittelumateriaalin tietomallipohjaisesti / bSF speksin mukaisesti.

Speksi julkaistaan ensivuoden alussa, RT-kortti tulossa, tilaajat ovat avainasemassa.

Vastuu materiaalimäärien sisällöstä on tilaajalla, urakoitsijat ovat samalla viivalla, suunnittelijat tekevät "perussuorituksen".

Ei voi olla vaikeaa - hoidetaanpa tietoteknisesti jo 25v sitten ollut pikkujuttu todellisuudeksi sekä mahdolliseksi Suomalaisessa urakkalaskennassa.

Mikä hienointa, ei tarvita yhtään prosessimuutosta. Ei yhtään lisätyötä. Ainoastaan se, että suunnittelija saa luvan lähettää materiaalin urakoitsijalle.

Ja sitten se vaikein kohta: Suunnitelmat on tehtävä noudattaen YTV2012 määrityksiä sekä tilaajan on varmistettava, että projekitin vaiheistus on kunnossa (TATE ei tee toteutussuunnittelua siinä vaiheessa kun ARK tekee luonnoksia...)

Yksittäiset ihmiset tekevät muutokset - eivät organisaatiot.


Viikon kuva:

Urakoitsija on (vieläkin?) ystävä

Uusin blogini täällä:

http://energistarakentamista.com/2015/11/23/urakoitsija-on-ystava/

Käytännössä ei ole mitään uutta kirjoitettuna, lähinnä kooste tämän blogin jutuista.

On muuten tällähetkellä vaikeaa toteuttaa otsikon aihetta työelämässä.

Nimimerkillä "hyvä tietomalli vaikeaan kohteeseen -> suunnittelija on syyllinen työmaan ongelmiin"

LVI-alan historiikki 2015

Börje Hagner on tehnyt pienimuotoisen uroteon ja koonnut Suomen LVI-alan historiikin yksien kansien väliin.

Historiikki on ladattavissa mm. täältä:
http://www.ax.fi/?x18668=108099

(päivitys, uusi 2017 versio:
https://www.ril.fi/media/2017/2017-jasenyys/seniorit/2017/lvi-historiikki-2017-borje-hagner.pdf

)

Sisältö teoksessa on aivan uskomaton... hienoa kuvamateriaalia ja oivaltavaa tekstiä. En kyllä ihan vielä ehtinyt kannesta kanteen lukea - veikkaan siinä menevän muutama ilta.

Börje, seuraava sukupolvi kiittää ja kumartaa.

Viikon kuva:

Tiedon epävarmuus

Lähitulevaisuudessa kaikki tieto on pilvessä, ehkä myös 3d-mallit.

Tieto on hajautettu objektitasolle, kuten nyt toimitaan IFC-malleissa. Venttiili tietää olevansa venttiili ja sille on liitetty lisäinformaatiota attribuuteilla. Venttiili tulee tietämään itsestään paljon muutakin, jota ei ole sille erikseen koodattu.

Kun sanon ym. lauseen ylläpidon ammattilaisille, saan sääliviä katseita. Isoa tietomäärää ei pysty kuulemma hallitsemaan ja pikkuosilla ei ole merkitystä kokonaisuuden kannalta. Tietoa pitää pystyä päivittämään, isoa massaa on vaikea (mahdoton) hallita. Minun vastaus siihen on, että pitäisi päästä pois excelistä / perinteisistä hierarkisista tietokantanäkymistä kohti tiedonhallintaa ja sitä kautta koota iso kuva perustuen pienempiin palasiin. Tällä matkalla olen alkukuopassa, työ jatkuu.

Pitää pystyä elämään epävarmuuden kanssa.

Lisäinformaation oikeellisuudesta ei ole mitään määritelmää. Kun luovutan mallini toiselle osapuolelle, toinen osapuoli ei pysty tietämään, mikä tieto on totta, arvausta tai pahimmassa (sekä normaalimmassa) tapauksessa: "Se ohjelma vaan laittoi sen tiedon sinne".

Tässä piilee tietomallien tulevaisuuden suurin ratkaistavissa oleva ongelma.
Olemme ohittaneet sen pisteen, että suunnittelijat eivät osaa käyttää softaa.
Olemme ohittaneet sen pisteen, että mallinnettaisiin vanhalla piirustusprosessilla.
Olemme ohittaneet sen pisteen, että tilaaja ei tietäisi, miten malleja haluaa käyttää rakentamisessa.

Tietomalliselostukset, dokumentit yms. yleismaailmalliset julkilausumat eivät kerro mitään. Tiedon on oltava sisällä objektissa. Jokaisen mutterin pitää tietää minimissään oma syntymäajankohta, kuka minut suunnitelmaan sijoitti, kuka minut muutti, kuka minut deletoi. Kaikille asioille tultava ajankohta objektille. Näitä asioita ei suunnittelija objektille anna, softa hoitaa sen.

Tulemme kohtaamaan ongelmia, kun tietosisältöön ei voi luottaa. En usko, että paperilla olevat taulukkomuotoiset LoDit asiaa selvittävät. Onko se muuten Level of Details vai Development... sen kanssa saa aina hyvin kulumaan puolisen tuntia bim-palavereissa. Eräs proffa esitti, että pitäisi olla LoE, Level of Estimation -> olen valitettavasti samaa mieltä. Nämä asiat pitää olla rakennettuna softaan sisälle, pilveen koko suunnitteluryhmän käytettäväksi. Softan tulee tukea prosessia / suunnitelman kehittämistä, tiedon luonti ja oikeellisuuden arvaus ei voi olla ihmisen viitseliäisyyden varassa.

Vanha viisaus on ollut, että: "Epävarmuuden kanssa on kyettävä elämään". Miksi pitäisi arvata jotain asiaa, jos joku kuitenkin tietää oikean vastauksen? Miksei se tieto voisi olla googlemaisesti semanttisessa webissä josta löydän tiedon muutaman hakusanan avulla?

Kun tähän päästään, minulla tulee olla kyky analysoida, onko saamani tieto totta vai ei. Samalla logiikalla kuin nykyisinkin - etsin googlella tietoa, saan paljon vastauksia joista 98% on turhaa, mutta yleensä ensimmäisten kymmenen vastauksen joukossa on ratkaisu. Tai ainakin kun klikkaan ensimmäistä ratkaisua, pääsen syvemmälle uusiin mahdollisuuksiin ja sitten löydän haluamani informaation.

Iso muutos on se, että virallista, oikeaa tietoa ei ole olemassa. On vain se tieto, joka on tarjolla siinä hetkessä, kun sitä kysytään. Sillä tarkkuudella, kun se on pystytty toimittamaan ko. projektin vaiheessa.

Tähän ollaan jo otettu ensiaskeleet nykyisessä rakentamisprosessissa. On hyväksytty, että IFC-mallit talletetaan esim. viikoittain työmaan käyttöön. Muutospiirustukset laitetaan kuitenkin harvemmin, kun on tehty "isoja" muutoksia. Työmaalla on siis mahdollisimman ajankohtainen tieto IFC-malleissa, mutta piirustukset laahaavat perässä. En ole kuullut yhdeltäkään työmaalta, että tämä olisi ongelma. Muutospiirustuksia käytetään vain lisälaskujen viitteinä.

Toinen esimerkki on energiasimuloinnit. Ne kuuluu tehdä siinä vaiheessa projektia, jossa on mahdollisuus vaikuttaa rakennuksen energiakäyttäytymiseen (hankevaihe/ehdotussuunnittelu). Kukaan ei kuvittele silloin tulevan lopullisia energiankulutustietoja. Mutta saamme eri vaihtoehtojen vaikutukset selville, jonka perusteella voidaan tehdä päätöksiä etenemisestä. Siis paras käytettävissä oleva tieto siinä ajankohdassa kuin simulointi on tehty.

Tarvitsen ohjelmistoja, jotka kommunikoivat toistensa välillä pilven sisällä. Tähän tarvitsen pilviservereitä, jotka hoitavat kommunikoinnin ilman, että minä teen mitään. Minun tehtävä on syöttää parasta mahdollista tietoa pilveen Toisen projektissa mukana olevan velvollisuus on käyttää sitä tietoa, jos sattuu / haluaa sen jostain löytää.

"Jos sattuu / haluaa sen jostain löytää". Mahdoton ajatus perinteisillä sopimusmalleilla.

Viikon kuva:

Yksi näistä palloista (simuloinneista) on oikea vaihtoehto:

Matkaraportti: Norja

Kävin kääntymässä muutaman päivän Norjassa tutustumassa TATE-suunnittelun saloihin IFC:n luvatussa maassa.

Ensialkuun on todettava, että ei huhut Norjan edistyksellisyydestä ole turhia. He ovat noin valovuoden meitä edellä. Tai ehkä kaksi.

Ensimmäinen kohde oli Norconsult, http://www.norconsult.com/ jossa esiteltiin 80.000m2 toimistokohde http://fornebuporten.no/ . Jos suoraan sanotaan, niin oli ihan niin kuin meillä Suomessa oleva iso kohde. Tai ainakaan en päässyt jyvälle erinomaisuudesta.

Toisaalta, mallit, aikataulu ja budjetti oli kunnossa. Suunnittelijalla  oli hyvä yhteisymmärrys urakoitsijan kanssa. Tiedot olivat malleissa standardin mukaisissa paikoissa. Kohdetta oli kuulemma kiva suunnitella. Kaikki hilanvitkuttimet vaatimustenhallinnasta BCF-kommunikointiin oli käytössä.

Toinen kohde oli COWI, http://www.cowi.com/ jossa esiteltiin Oslon lentokentän 120.000m2 laajennusta http://www.airport-technology.com/projects/oslo-airport-terminal-2/ . Kohteen suunnittelijat ja urakoitsijat olivat lentokentän vieressä olevassa toimistorakennuksessa. Oven yläpuolella luki ”T2_Team”.

Astuin sisään toimistoon, infoscreeni löytyi aulasta ja portaiden yläpäästä avokonttori. Mentiin isoon neukkariin, jossa viriteltiin tietokoneet kuntoon ja vaihdeltiin kuulumisia. Kaikki oli kuten IPD –hankkeessa, bigroom kunnossa ja eri osapuolet saman katon alla tekemässä töitä.

Aloitimme palaverin, kaveri esitteli toimintaa hankkeessa. On se vain kummallista, että sellaiset asiat kuin yhteistyö, mallien oikeellisuus, tietosisällön standardisointi ja tiedonhallinta ovat itsestäänselvyyksiä kun kaveri esittelee kohdetta. Monta sellaista asiaa tuli eteen, jossa joku suomalainen olisi pysähtynyt ja esittänyt kuinka hienosti esim. ”ulkoseinien U-arvojen päivittäminen onnistui Revitin ja Excelin linkkauksella”. Nuo jutut oli itsestäänselvyyksiä, eivät erityisen esityksen  arvoisia.

Viikoittain käydään kuulemma läpi, mitä tehdään ensiviikolla ja miten viime viikko meni. Tarkistetaan tietotarpeet ja kerrotaan, mitä ollaan tehty.

Aloin kysellä, että miten te kutsutte tätä avokonttoria - kenties Bigroomiksi? Kaveri ei ollut koskaan kuullut termiä. Vastasi, että tämä on tiimityöskentelytila, ollaan tultu tänne viimeiset 5 vuotta duuniin.

Kysyin, onko tämä IPD tai Allianssi –projekti, jossa ydinryhmä on yhteisvastuullinen tappioista ja voitoista. Kaveri kertoi, että ei tiedä sopimustekniikasta paljoakaan, mutta sellainen käytäntö on, että jos kaikki pärjäävät, niin se näkyy hänen tilipussissa. Eli motivaatio hankkeen onnistumiselle on olemassa. Ei siis pelkästään palkkio firmalle, vaan myös hankkeeseen osallistuville työntekijöille.

Sivuhuomiona se, että hankkeeseen osallistuvien käyntikortitkin olivat hankkeeseen liittyviä – eivät siis oman firman logolla varustettuja pahvinpaloja.

Pitää myöntää, että kuka hanketta on vetänytkään, niin hienosti on onnistuttu hukuttamaan tekniset termit kuten Lean ja IPD pois henkilökunnalta. On osattu tuoda esiin ne elementit, jotka ovat yhteistoiminnalle tärkeitä ilman että ollaan kyllästetytty porukka erilaisilla lyhenteillä, kuten IPD, Lean, BIM, Last Planner jne.

Muita huomioita Norjasta:

- Vaatimustenhallinta. Molemmissa projekteissa käytössä yhteisillä ohjelmistoilla eri suunnitteluosapuolten ja käyttäjien välillä

- Energiasimuloinnit. Lämpöhäviöt, laiteluettelot jne. alkuvaiheen mitoitukset jäivät minulle mysteereiksi. Veikkaan syynä olevan se, että esittelijät olivat toteutusvaiheen kavereita. Kumpikin sanoi käyttävänsä ”rule of thumb” metodia mitoituksissa. Tuo ei voi mielestäni pitää paikkaansa, sen verran oli bimiä esityksissä. Tai sitten ymmärsin jotain väärin.

- Standardisointi. http://www.statsbygg.no/Om-Statsbygg/About-Statsbygg/ ,eli Statsbygg (paikallinen Senaatti kiinteistöt) on julkaissut vuosia sitten omat vaatimuksensa ja niitä noudatetaan yleisesti. Molemmilla firmoilla oli Revit Templatet viritetty omaan prosessin + Statsbyggin vaatimusten mukaisesti. Molemmat firmat (ja NTI CADcentral, www.nticad.no) sanoivat, että templaten tekeminen kunnolla on avain onneen. Jos oikein ymmärsin, niin mallit ovat koneluettavia.

-  Raha. Kyllähän se näkyi, mutta en millään haluaisi sanoa että: ”Onhan se helppoa kun on rahaa”. Ihmiset sitä työtä tekevät. Toisaalta, on se helpompaa kun saa ostettua mitä haluaa esim. ohjelmistolisenssien / tekniikan suhteen…

- 3D. Grafiikan erottaminen tietosisällöstä oli selviö. Eli klikkaamalla objektia tieto pitää tulla jostain pilvipalvelusta. Hienoa saada vahvistus omille luuloille – harmi vain että nämä kaverit tekevät sitä jo käytännössä.

- Yhteistyö. Vaikutti siltä, että urakoitsijan ja suunnittelijan välillä ei ollut isoa rotkoa. Molemmat ymmärsivät toisiansa, tai niin ainakin suunnittelijat minulle kertoivat.

Yritin keksiä jotain negatiivistakin tästä reissusta. Ei meinaa löytyä.

Kenties lopputulema on se, että tulen olemaan työpaikkani kallein henkilö seuraavien 1-5 vuoden aikana - liittyen prosessi-, koulutus- ja ohjelmistomuutoksiin.

 Päivän kuva:

Ilman piristeitä?

TATE määrätiedot kommenttikierrokselle

Pyydän kaikkia kommentoimaan buildingSMART Finland Talotekniikan toimialaryhmän tekemiä ohjeita kosken talotekniikan määrätietojen toimittamista urakkalaskentaan:

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

Nyt on mahdollsita vaikuttaa, muutetaan yhdessä prosessia ja tehdään tulevaisuudestamme fiksumpaa - kaikille osapuolille.

Vuoden kuva:

Espoossa Texasin säätiedot

Bigroom vs. Knotworking

Hävettää myöntää, mutta luin vasta nyt tämän Cradlen paperin:

https://helda.helsinki.fi/bitstream/handle/10138/42897/ICCEPM_2013_KNOTWORKING_re_submitted.pdf?sequence=2

Olin mukana ko. kohteen tiimissä nro 1, ja Helsingin Yliopiston tutkijoiden havainnot ovat kyllä ihan paikkaansapitäviä.

Vahvistan sen havainnon, että pikkuprojekteihin sopii paremmin Solmu ja Bigroom on isoihin kohteisiin, luokkaa 300M€ tai suuremmat.

Jos tehdään Bigroom, siellä on oltava todellakin paikalla. Ei riitä, että ollaan pari päivää viikossa hengessä mukana. Silloin pitää miettiä hankkeen henkilörakenne / vaiheistus huomattavasti tarkemmin. Solmussa pystyy yleensä löytämään oikeat henkilöt paremmin paikalle.

Solmutyöskentely tyhjentää takin totaalisesti parin päivän jälkeen, sinusta on täysin imetty mehut. Pitää skarpata koko ajan ja olla aktiivinen. Ei sovi kaikille persoonallisuuksille.

Mutta, kun on oikea porukka, tehdään parissa päivässä kuukauden duuni.

Vielä kun saisi tilaajan ja rakennuttajan mukaan solmuun. Lopputulos olisi paljon parempi.


Viikon kuva:

Mitä meiltä pimitetään?

Uusin blogi löytyy tällä kertaa täältä:

http://energistarakentamista.com/

Historiaa: MagiCADin painetasolaskelmat

Tasaisin väliajoin minulta kysellään, miten painehäviölaskelmat tehdään MagiCADissä. Jotenkin on aistittavissa, että paineen käyttäytyminen suljetussa verkostossa on mysteeri heille.

Rippasin tähän blogiin viestin vuodelta ~2001 tjsp. Hauska lukea sen aikaisen MUGF -sivuston kirjoituksia (MagiCAD User Group Finland).

Tietosisältö on suurinpiirtein OK vielä  ~14 vuoden tietomallinnuksen jälkeenkin.

Samaa juttua on myös täällä:
http://tietomalli.blogspot.fi/2011/02/nuoruuden-uhoa.html

Alkuperäinen viesti:
http://web.archive.org/web/20040610095309/http://www.mugf.net/

---
/MUGF Start

12. Miten löydän painetasollisesti virheellisen komponentin verkostosta?

Tehtäessä tasapainotus verkostoon, voi painetaso joskus olla järjettömän korkea. Vielä en ole törmännyt yhteenkään projektiin, jossa magi olisi laskenut painetason liian suureksi ohjelmavirheen vuoksi. Aina on verkostosta löytynyt jokin mallinnusvirhe, joka aiheuttaa painetason nousun liian suureksi.

Kaikki me ammattilaisethan tiedämme, että jos lämmitysverkostossa vaikeimman linjan linjasäätöventtiilille tulee ~60kPa painehäviö, niin se ei ole sen venttiilin vika, vaan jossakin muualla verkostossa on jokin komponentti, joka aiheuttaa suuren painehäviön. Linjasäätöventtiili vain tasapainottaa verkoston tähän olosuhteeseen. Magi ei siis osaa ajatella, se tekee työtä tyhmänä laskukoneena.

"Flow Route Examination" on loistava käsky verkostojen tarkistuksessa. Sarakkeesta "dpconn" nähdään liitoksen painehäviö. Lisäksi systeemivalikossa voidaan asettaa hälytysrajat liian suurille komponenttien painehäviöille.

Tasapainottamalla verkosto ja laittamalla ruksi kohtaan "Show the most significant route" saadaan magi piirtämään ruudulle reitti vaikeimmalle haaralle. Tätä kannattaa käyttää kun tarkistetaan verkosto. Jos verkostossa on joku liian ahdas paikka, niin se saadaan selville tämän reitin varrelta "Flow Route Examination" käskyllä. Huomaa, että käyttövesipuolella magi piirtää omat reitit kylmälle ja lämpimälle vedelle.

Tässä eräitä tarkastuskohteita, jonka avulla voi löytyä verkoston mallinnusvirhe:

1.  Patteriventtiilien käyrästöt
Jos nestevirta on liian suuri patteriventtiilille, niin käyrästö menee "tappiin" ja aiheuttaa venttiilillä liian suuren painehäviön. Esim. porrashuoneiden patterit mitoitetaan välillä erittäin suurelle teholle, jolloin yksi DN20 venttiili ei aina riitä.
Suosittelen kaikille vertailemaan eri valmistajien patteriventtiilien käyrästöjä - niissä on todellakin eroja. Varsinkin erittäin pienten nestevirtojen käyrät voivat tuottaa yllätyksiä. Jos pikkupatterit eivät mene tasapainoon, kannattaa kokeilla Danfossin RA-N tai T&A:n TRV-1S venttiilejä.

2.  Vääränkokoiset linja- ja sulkuventtiilit
Varsinkin IV-verkoissa kun piirtelee putkistoa esim DN40 putkella (siis ennen mitoitusta) ja tekee IV-koneiden kytkennät valmiiksi - eli laittaa venttiilit putkistoon kiinni - voi tapahtua virheitä.

Kun tekee putkistomitoituksen niin vaikka putki suurenee, venttiili ei välttämättä suurenekaan. Tämä johtuu siitä, että jos on käyttänyt esim. T&A:n STAD -linjasäätöventtiiliä; venttiilin suurin koko on DN50, jonka jälkeen pitää käyttää STAFfia. Magi ei tätä tietenkään tajua, vaan jos putki suurenee DN40 -> DN100, niin tässä DN100 putkessa on DN50 kokoinen venttiili kiinni. Se on siis suurin koko, jonka ohjelma löytää tietokannastaan.

Sama juttu pätee sulkuventtiilille, eli jos on käyttänyt alussa väärän mallista venttiiliä, niin se tasapainotettaessa aiheuttaa verkostoon suuren painehäviön

3.  Kanttikanavien äänenvaimentimet
Kanttikanavien äänenvaimentimissa pitää olla tarkkana, sillä jos äänenvaimennin on liian pieni, niin se aiheuttaa suuren painehäviön verkostoon. Magi tekee aina kanavan kokoisen vaimentimen. Varsinkin Swegonin PLG -vaimentimen kanssa pitää olla tarkkana. Vaikka vaimennin onkin ominaisuuksiltaan hyvä, pitää LVI-suunnittelijan tietää, minkä kokoinen vaimennin verkostoon pitää laittaa - ohjelma ei sitä osaa valita. Eli kanttikanava pitää suurentaa ennen vaimentimen laittoa, jotta kanavanopeus saadaan "oikealle" tasolle.

4. Komponentit, joille on mallinnettu käyrästö 
Magin putkistokomponenttien takana on tuskastuttavan usein esimallinenttu käyrästö, joka siis seuraa nestevirtaa ja laskee itse painehäviön. LVI-suunnittelijalle tämä aiheuttaa harmaita hiuksia, sillä suunnitteluvaiheessa emme tiedä, minkä valmistajan tuotteen urakoitsija kiinteistöön valitsee. Siksi pitäisi olla mahdollisuus antaa aina itse komponentin painehäviö virtaamasta riippumatta (Lock dp, kuten linjasäätöventtiileissä)

Nyt se ei siis ole vielä mahdollista (magiversio 2001.6). Erikoiskomponentit, kuten mutataskut, 1-, 2- ja 3-tieventtiilit pitää käydä katsomassa mitoituksen jälkeen, että mille arvolle magi ne mitoitti. Jos lopputulos ei miellytä, pitää komponentin kokoa muuttaa ja toivoa, että päästään sellaiselle tasolle, kun halutaan. Tietenkin voi mallintaa itse juuri sopivan komponentin, mutta se vie yleensä liikaa aikaa eikä siihen "viitsi" ryhtyä.

5. Open ends
Avoimet päät löytää helposti ottamalla "Part Property Line" ja aktivoimalla kohta "Open ends". Tekstikoko kannattaa laittaa kohtalaisen suureksi, esim 400. Lisäksi kikka nro 13 auttaa huomattavasti.

6. Huono LVI-suunnittelu
Ammattilaista tarvitaan edelleen. Huonosti suunniteltua verkostoa ei pystytä pelastamaan edes magilla...

---

/MUGF end

Nuoriso, nouskaa omalle tasollenne. Tehkää maailma, jossa haluatte olla 20v päästä.

Viikon kuva.

Muistaakseni Swegon Gold v.2000 jotain + ahdas paikka

Big Room

Sana Big Room on löytynyt kiitettävällä frekvenssillä niissä tarjouspyynnöissä, joissa on panostettu yhteistyön mahdollistamiseen suunnittelu- / rakentamisprosessin aikana.

Mielestäni on havaittavissa, että tuo sana tarkoittaa eri asiaa eri henkilöillä. Sama juttu, kun puhutaan tietomallintamisesta ja "tietomallintamisesta". Kaksi henkilöä voi puhua tunnin keskenänsä huomatakseen, että tarkoittavat aivan eri asiaa, puhe etenee kuitenkin samoilla termeillä.

Tässä oma mielipiteeni siitä, mitä Big Room tarkoittaa.

Big Room on avokonttori, jossa työskentelee virtuaalinen yritys.

Big Roomiin tullaan aamulla töihin ja sieltä lähdetään kotiin työpäivän loputtua.

Big Roomissa on useiden eri firmojen henkilöitä työssä.

Big Roomin vieressä on rakennettava kohde.

Big Room ei ole työpaja. Big Room ei ole Solmutyöskentelyä ( [c] HY Cradle)

Big Roomissa voi olla työpajoja. Big Roomissa voi olla Solmutyöskentelyä

Big Room ei ole iso neukkari.

Tuon tämän asian esille, sillä vaikuttaa siltä, että normaaleja työpajoja aletaan sekoittaa Big Room työskentelyyn. Pidetään työpajat työpajoina ja yhteisissä tiloissa tehtävä työnteko erillään toisistaan.

Ym. asian sekavuuteen vaikuttanee myös se, että rakennusalalla on kokemusta vielä vähän todellisesta Big Roomista, siis siitä, missä mukana on myös urakoitsija eikä pelkästään tilaaja ja suunnittelijat. Infralla tämäkin asian on jo koeponnistettu sekä hyväksi havaittu.

Allianssin kehitysvaihe vaikuttaa olevan selvästikin työpajatoimintaa - ja hyvä niin. Parin päivän pyrähdyksiä jossa on firmojen ykkösketju tekemässä suuret linjat kuntoon. Sitten mennään omalle toimistolle ja tehdään sovitut asiat + valmistellaan seuraavan työpajan agenda.

Kun projektissa päästään eteenpäin ja aletaan tehdä toteutussuunnittelua, vaihtuu porukka ja yhteistyö muuttuu aktiivisemmaksi - läsnäoloa tarvitaan enemmän.

Talotekniikalle on erittäin tärkeää, että Big Roomissa on mahdollista tehdä myös muiden kohteiden suunnittelua. Vaatii erittäin ison kohteen, että projektinvetäjä olisi 100% siinä kiinni. Mallintavalle suunnittelijalle se ei kuitenkaan ole ongelma, ajankäyttö kohdistuu aktiivisesti kohteeseen.

Big Roomin kokoukset / työt tulee aikatauluttaa. Pitää sopia vakiokokousajat ja kuka on paikalla minäkin päivänä. Mitä ylemmälle hierarkiassa mennään, sitä vähemmän he ovat läsnä. Kun ylätason kaverien kokoustarve kartoitetaan, niin heidän työpanos saadaan osumaan täsmäiskuna aktiiviselle kohteelle.

Big Roomin tekninen varustus ja laajuus tulee aiheuttamaan alussa varmasti keskustelua. Jotta työskentely on mahdollista erikseen rakennetussa uudisrakennuksessa (malli: työmaatoimisto + vähän enemmän) tai lähistöltä löydettävissä olevassa tyhjässä kiinteistössä, sinne pitää rakentaa tietotekninen ympäristö.

On huomioitavaa, että projektipankkia ei Big Roomissa tarvita. Työskentely-ympäristö on yhteinen, tiedostot ovat hallinnassa kuten firmojen omilla servereillä on totuttu työskentelemään. Tarvitaan oikea dokumenttienhallintajärjestelmä tai ainakin yhteisesti sovittu logiikka tiedostojen tallentamiselle.

Tietotekniset asiat ovat kuitenkin helpoin asia, sillä vaikein on sosiaalisen aspektin huomioiminen. Miten yhdistää toisilleen tuntemattomat henkilöt toisiinsa - firmarajojen yli? Tiimihengen luominen vaatii monta illallista,  jääkiekko-ottelua ja museossa käyntiä.

Tietoteknisen ympäristöön liittyviä asioita ovat ainakin:
- Sisäverkko Wifillä on välttämättömyys
- Verkkotulostimet, NFC:llä, pilvitulostuksella
- Sisäinen tiedostopalvelin. Onko NAS purkki vai jotain ammattimaisempaa
- Pilvipolitiikka. Onko Google Drive/Dropbox/OneDrive/Box mahdollista käyttää? Tietoturva? Vai luodaanko esim. OwnCloud?
- Mallien jakaminen, tiimityöskentely (Tekla, Revit, ArchiCAD) (onneksi tämä ei ole edes mahdollista MagiCADillä tai CADSsillä...)
- Missä mallit fyysisesti ovat? Missä ovat natiivit "äitimallit"?
- Virallisen yhdistelmämallin sijainti Big Roomin serverillä?
- Dokumenttienhallinta? Projektipankit?
- Etätyöskentelyn mahdollistaminen. VPN vai Citrix?
- VPN: helppo
- Citrix: tietoturvallinen, personoitu, skaalautuva, paras ja kallein
- Videoneuvottelujärjestelmä, Lync vai jotain muuta?
- Smartboardeista plussaa. Ja varsinkin, jos niitä osaa käyttää muunakin kuin videotykkinä.
- Screenejä seinillä, jossa pyörii kohteen mittarointitietoja; ollaanko taloudellisessa tavoitteessa, mitä kokouksia on tulossa, mihin asiaan tulee keskittyä erityisesti, koska on seuraava sauna-ilta...
- Screeni, jossa kerrotaan kohteessa työskentelevistä ihmisistä, nimi, kuva, toimenkuva jne.
- Screeni, jossa pyörii kohteen virallinen yhdistelmämalli
- Palautescreeni, jonne voi nimettömänä tai nimellä antaa kommentteja kohteen etenemisestä, parannusehdotuksia jne.
- Kohteen www-sivut, infokanava, intra, blogi, wiki tms.


Lisäksi tulee huomioida:
- Vartiointi, hälytykset
- Tietoturvallisuus
- Tilantarve, osa porukasta on paikalla 1 pvä / vko, osa 3 ja joku aina.
- Kaikki neukkarivarustus pyörillä (isoilla). Pöydät / tuolit liikuteltavia.
- Big Roomin layout tulee muuttumaan pari kertaa työn edetessä. Alussa on hyvä sekoittaa eri suunnittelualoja, lopussa on hyvä ryhmittää samanhenkinen porukka yhteen kasaan.
- Neukkareita, hiljaisia huoneita jne. tarvitaan aina
- Min. yksi oikeasti iso neukkari.
- WC + keittiö olisi kiva
- Last Plannerille iso seinä
- Käyttäjien osallistuttaminen
- Käyttäjille tila, jossa he voivat käydä tutustumassa kohteeseen. "Showroom".


Kun kaikki ym. jutut laskee euroiksi, ollaan helposti kuusinumeroisessa luvussa, eikä ensimmäinen numero ole välillä 1-3.

Se ei tunnu missään, jos kohteen hintalappu on miljardi.

Viikon kuva:

Mittarointia ameriikan malliin

BuildingSMART Spain julkaisi BIM vaatimukset

Täytyy sanoa, että pari kertaa hieraisin silmiä, kun sain vinkin näistä sivuista:
http://www.buildingsmart.es/index.php/ubim/documentos-ubim
(edit 27.3.2015: taitaa löytyä nyt täältä: http://www.buildingsmart.es/bim/gu%C3%ADas-ubim/ )

Kohtalaisen tutun näköistä tekstiä, sana COBIM löytyy myös sisällössä mainittuna.

Sekin on hienoa soveltamista, että Espanjalaiset levittävät vaatimuksia GNU-lisenssin alaisuudessa... ja ovat samalla copyrightanneet bim-vaatimuksensa:
"Derecho de Autor © 2014 BuildingSMART Spanish Chapter"

En olisi koskaan uskonut, että suomalaisten tapa toimia rakennushankkeissa kelpaa myös Espanjan rakennusmarkkinoille... pitänee käydä tutustumassa uuteen markkina-alueeseen.

Kohtalaisen iso projekti tämä on pitänyt olla, sillä co-authoreita löytyy yli 80 henkeä

Materiaalilistat urakkalaskentaan

Olen vetänyt vuoden verran buildingSMART Finlandin alaista TATE-toimialaryhmää. Aloitimme viime vuonna ja katsoimme, alkaako toiminta lentää.

Vielä ollaan remmissä, porukkaakin alkaa ilmaantua ympärille lisää ja lisää.

Viime vuonna teimme mm. www-kyselyn TATE-toimialan tietomallintamisesta. Kyselyyn osallistui 193 henkilöä, kiitos siitä. Tämä kysely tullaan tekemään uudelleen toivottavasti  syksyllä 2015. Toivon vahvempaa osallistumista urakoitsijoilta ja tilaajilta.

Tämän vuoden tehtävälistalla ykkösenä on ikuisuusaihe:
Materiaalilistat urakkalaskennan käyttöön.

Yli 20 vuotta on ollut mahdollista tuottaa TATE-suunnitelmista massalistat, mutta niiden käyttö todellisuudessa on lapsen kengissä.

BuildingSMARTin piirissä on hieno tilanne; mukana on myös tilaajien toimialaryhmä. Uskon tämän ryhmän ratkaisevan sopimustekniset ja juridiset asiat. Ne eivät ole ongelmia, ne eivät ole haasteita. Ne ovat asioita, jotka on ratkaistava ja selvitettävä pelisäännöt eri osapuolille. Ei rakettitiedettä, pelkkää asioiden sopimista.

Materiaalilistojen käyttöä urakkalaskennassa on yritetty monesti, ja tämä on yksi yritys muiden joukossa. Toivon todella, että eri intressiryhmät löytävät yhteisen sävelen ja me suunnittelijat saamme toimittaa urakointiin tietoa, jota he tarvitsevat ja joka syntyy meillä suunnitelmien sivutuotteena - ilman mitään sen ihmeellisempää lisätyötä. Vaade on vain se, että YTV2012 Osa 4:sta noudatetaan. Peruskauraa.

En missään nimessä halua uskoa kuulemaani kommenttia, että: "Paras tilanne on, kun joku on laskenut väärin". Ei voi olla nykymaailmassa näin (tuostakin on kyllä jo 10v aikaa). Kukaan täysijärkinen ei voi luulla, että vinguttamalla urakoitsijoita saa sen lopputuloksen, jota on halunnut / omat esimiehet ovat vaatineet käyttäjien toiveiden perusteella.

En minä, eikä mielestäni kukaan, joiden kanssa olen asiaa ihmetellyt pysty ymmärtämään sitä, että urakoitsija mittaa rullalla / mittatikulla metrejä piirustuksista kun antaa tarjousta. Toivon todella, että tuo ei ole totta vuonna 2015, mutta taidan tietää, että se on totta... rakennuttaja maksaa tämänkin työn. Jos yksi kymmenestä lasketusta kohteesta jää urakoitsijan haaviin, niin ne 9 muuta laskentaa näkyy voittaneen kohteen hinnassa.

Kuten todettua, massalistojen tuottaminen ei ole ollenkaan tekninen haaste. Kunhan sovitaan, mitä tietoa tuotetaan, mikä on sen tarkkuustaso eri suunnitteluvaiheissa ja millä alkutiedolla se on tuotettu.

Ratkaistavat asiat liittyvät juridiikkaan. Mitä YSE sanoo vastuista, miten toimitaan, kun materiaalilistat eivät pidäkään 100% paikkaansa (eivät pidä muuten koskaan). Kuka vastaa mistäkin? Missä menee vastuurajat? Minkälainen sopimustekniikka tarvitaan? Miten tehdään plus/miinuslistat, miten kompensoidaan muutokset?

Pääkysymys on, miten vastuut jaetaan? (Arvatkaa, antaako Allianssi / IPD tähän vastauksen...)

Tiedän, että näistäkin asioista on jo olemassa ratkaisuja.

Nyt ne pitää vain kirjoittaa auki.

Viikon vinkki:
Osallistu buildingSMART Finlandin toimintaan:
http://buildingsmart.fi/jaseneksi-hakeminen


Viikon kuva:
Rullaa'ti rullaa rallallallallei

Talotekninen suunnittelija + Arkkitehti

Välillä tuntuu, että me talotekniset suunnittelijat olemme arkkitehdin pahimpia vihollisia.

Oikeasti me haluaisimme olla heidän parhaita kavereita ja auttaa heitä tekemään parasta mahdollista arkkitehtuuria parhaimmalla mahdollisella elinkaarikustannuksella, käyttäjien viihtyvyydellä sekä sisäympäristöolosuhteilla.

Ehdotussuunnitteluvaiheessa kerromme TATE-tilavarausten vaatimat tilantarpeet perustuen käyttäjän/tilaajan/arkkitehdin hyväksymään tilaohjelmaan.

Ja sitten ne tilatarpeet muodostuvat arkkitehtisuunnitelmiin iv-konehuoneina, iv-kuiluina, hormistoina jne.

Nämä tarpeet me tarkastamme ark-mallipäivityksen yhteydessä ja kuinka ollakkaan - yleensä sovitut konehuoneet ja kuilut ovat pienentyneet siitä, mitä ollaan sovittu keskinäisessä palaverissa.

Nyt tuli esille hieno kohde. Tämä asia kerrottiin meille selvästi etukäteen.

Lainaus pitkähköstä sähköpostiviestistä:

"HUOM!
- Olemme hieman pienenetäneet pääsuunnittelijan pyynnöstä IV-kuiluja, jotta ne mahtuvat paremmin 3.kerrokseen."

Toivottavasti eteen tulee lisää vastaavaa toimintaa.

Nyt pystymme reagoimaan asiaan ennen kuin mitään on rakennettu - tätäkään asiaa ei tarvitse ihmetellä työmaalla kun kamat ei mahdu liian pieneen kuiluun. Voimme reagoida asiaan jo suunnitteluvaiheessa (toistamiseen/kolmanteen/neljänteen kertaa.).

Rakennusala: Yhteistyötä!