perjantai 23. lokakuuta 2015

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:




lauantai 10. lokakuuta 2015

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: