buildingSMART Finland, tietosisällön vakiointi

buildingSMART Finland Talotekniikan toimialaryhmä on julkaisut tietomallien vakioidun tietosisällön vaatimukset, ladattavissa täältä:
https://buildingsmart.fi/talotekniikan-tietomallien-tietosisallon-vakiointitaulukko-julkaistu/

Tämä taulukko on alkulaukaus sille, että alkaisimme käyttää myös TIETOA suunnittelun aineistoissa.

Teemme edelleen suunnitelmia pelkästään visuaaliseen tarkasteluun.

Meiltä puuttuu ymmärrys siitä, että tietomalli täydentää paperituotetta, emmekä osaa / uskalla käyttää tietomalleja rakentamisen ykköstiedonlähteenä.

Piirustukset eivät tule häviämään mihinkään, ne ovat yksi osa tietomallia. Yksi näkymä moniulotteiseen tietosisältöön.

Räikeimpänä esimerkkinä talotekniikan puolelta voidaan ehkä pitää sähköteknisten kaavioiden ylivaltaa. Asiat esitetään piirustuksen muodossa, jotka ihminen tulkitsee tuotteeksi. Lisäksi muut dokumentit "täydentävät" kaavioiden tietoja.  Näitä kaavioita ei voi poistaa kokonaan, niille on ehdottomasi oma paikkansa. Mutta mutu -arvioni on, että 80% tietosisällöstä voidaan tuottaa koneluettavaksi jotta esim. jakokeskusvalmistaja voi tuottaa hinta-arvion tehokkaammin (muutettuaan tietenkin ensiksi oman tarjoussysteeminsä...).

Ym. ei tarkoita sitä, että tiedot pitäisi olla IFC-malleissa. Ne voivat olla yhtä hyvin tietokannoissa, johon päästään kiinni API rajapinnoin.

Kuten tiedetään, taustani on LVI -suunnittelu, siksi on helppo ottaa silmätikuksi alue, josta en tiedä juuri mitään. Mutta kyllä minuta ihmetyttää, että projektissa voi olla yli 800 (kahdeksansataa) kaaviota eikä yhtään sähköteknistä laiteluetteloa - pois lukien valaisimet.

Vakiointitaulukon tarkoitus

bSF TATE-vakiointitaulukko on tehty, jotta eri suunnittelufirmat voisivat tuottaa tilaajalle tietomalleja samanlaisella tietosisällöllä. Näin suunnittelutoimistojen tuotos näkyy tilaajalle päin samanlaisena tietosisällön suhteen.

Ainakaan minulta, tilaajat eivät ole tällaista koskaan vaatineet. Se johtuu siitä, että tilaajat eivät vielä arvosta tietosisältöä. Kun vakioitu tietosisältö alkaa olla "uusi normaali", tulee ohjelmistoja jotka hyödyntävät tietoa skaalautuvasti. Tämän jälkeen myös tilaajat hahmottavat uuden tilanteen - portfoliotason tiedolla johtaminen on mahdollista, koska tiedot ovat semanttisia - tietosisältö on tiedossa, tiedetään mistä kentästä luetaan mitäkin tietoa ja mitä se tarkoittaa.

Näin siis voidaan tehdä koneluettavia, kolmannen osapuolen ohjelmistoja jotka ymmärtävät heti, mitä suunnittelija on tuottanut.

Kiinteistöjen omistajaorganisaatiot hyötyvät tästä eniten. Rakennusten tekniset tiedot ovat vertailukelpoisia keskenään.

Miten otetaan käytäntöön?

Suomessa, MagiCAD  Group ja Kymdata ovat luvanneet tehdä omiin ohjelmistoihinsa valmiit asetukset, jotka valitsemalla voidaan tuottaa IFC-tiedostot, jotka tukevat bSF speksiä.

Arvio asetusten julkaisemisesta: vuoden 2019 aikana

Tilaajat: kun käyttötapaustaulukot on tehty, voitte viitata niihin tarjouspyynnöissä. Kun nyt vuonna 2019 tilaatte suunnittelun YTV2012 speksin mukaisesti, niin saatte oletettavasti juuri sen, mitä haluatte.

Tämän vakiointitaulukon tietosisällön tuottaminen onnistuu helposti, kun sovellusohjelmistojen IFC-export määrityksiin / asetuksiin pystytään luomaan omia sisältöasetuksia.

Suunnittelu tehdään normaalisti, ja kun tehdään IFC-export, niin valitaan bSF-speksin mukaiset asetukset - ei lisätyötä suunnittelijalle, kun mennään YTV2012 mukaisilla asetuksilla.

Yhteistoiminnallisuus

Taulukossa on paljon tietokenttiä.  Kaikkia ei ole tarkoitettu täytettävän BIM-softan / suunnittelijan toimesta, vaan taulukko varautuu tulevaan, yhteistoiminnalliseen toimintatapaan, jossa rakennusorganisaatiot yhdessä tuottavat tietoa tilaajan tarpeisiin.

Suunnittelija tuottaa tilaajan vaatimaa tietoa, rakennusurakoitsija täydentää sitä esim. hankintojen ja aikataulutuksen näkökulmasta sekä ylläpito-organisaatio hyödyntää sekä rikastuttaa tätä tietoa omiin tarpeisiinsa.

Ym. skenaario ei ole mahdollista tiedostopohjaisessa, IFC-malleihin perustuvassa toimintakulttuurissa. Siksi tarvitaan avointa tietosisällön vakiointimäärittelyä, joka kokoaa usean eri järjestelmän tietosisältömääritykset yhden speksin alaisuuteen.

Tulevaisuus

Taulukko on tehty, jotta softavalmistajat näkevät, minne ala haluaa tietomallinnusta viedä. Taulukossa on asioita, jotka eivät ole vielä mahdollista toteuttaa. Taulukossa otetaan kantaa mm. LoI (Level of Information) ja LoG (Level of Geometry) määrityksiin. Näille ei ole selkeää speksiä vielä olemassa, mutta bimforum.org järjestelmän LOD -systeemi kertoo periaatteet.

Tulevaisuudessa tietomallit tulevat olemaan pilvessä. Myös natiivimallit. Tämä helpottaa tiedon jakamista ja tuottamista usean eri toimittajan kesken. Suunnitelu, urakointi ja ylläpito lähenevät toisiansa.

Salatut erikoiskohteet tulevat kärsimään tästä suuntauksesta, mutta oman pilven rakentaminen on tietyin reunaehdoin mahdollista.

Onko ristissä muiden vastaavien hankkeiden kanssa?

Ei ole, sillä nyt puhutaan ruohonjuuritason vakioinnista. Tämä ei ole nimikkeistö, kuten esim. CoClass tai Cuneco.

Lisäksi tämä on paljon suppeampi näkökulma, kuin esim. CoBIE määrittelee. Olemme pyrkineet ottamaan käyttöön minimimäärän tietoa - jolla kuitenkin pärjätään 80% tapauksista.

Eveliina Vesalainen teki aiheesta myös diplomi-insinöörityön, jossa verrattiin eri nimikkeistöjä:
https://buildingsmart.fi/talotekniikan-bim-nimikkeistojen-parhaat-kaytannot-eveliina-vesalainen-granlund/

Even dippa oli yksi perusta tämän bSF vakiointityön tekemiselle.

Vakiointitaulukon rakenne

Taulukko on nyt julkaistu Excel -formaatissa, mutta laajamittainen käyttö vaatii omaa sivustoa tai ohjelmistoa. Asia on työn alla... ehdotuksia otetaan vastaan.

Taulukko koostuu kahdesta osiosta:

1. Propertylistauksesta, jossa on listattuna propertyt ja propertysetit.
2.  Käyttötapaustaulukoista, jossa kerrotaan mitä propertyjä milläkin talotekniselle komponentille tulee olla ko. käyttötapaukseen liitettynä.

Nyt on siis julkaistu osa 1, eli propertylista. Siihen tulee vielä täydennyksiä, eli tarkoitus on vielä vakioida eri propertyjen arvot, jos property sen mahdollistaa (ei numeerinen).

Esimerkkinä tästä esim. property "Discipline" (tekniikanala). Sen arvot voidaan vakioida, eli vastaukset voisivat olla: "Ilmanvaihto", Sähkötekniikka", Rakennusautomaatio"...

Property? Propertyset?

Mitä nuo ovat?
Property on IFC-tiedostossa oleva Attribuutti. Propertyset on IFC-tiedostossa oleva Ominaisuusjoukko.

Propertysetit sisältävät propertyjä.
Propertyllä on joku arvo/vastaus (Property Value)

Esimerkki:
Propertysettiin "bSF_Technical" on määrätty liitettäväksi property "Material". Property Value tähän voi olla esim. "Cu" tai "Copper". Tästä pääsemme edellisen kappaleen kysymykseen - mikä halutaan vakioiduksi vastaukseksi?

Selection List voi kertoa propertylle "Material" vastaukseksi "Cu" tai "Copper". Tai "Kupari" Millä  mennään eteenpäin? Tähän buildingSMART Finland haluaa vastauksia kentältä. 

Kielivalinta

Meidän oli tehtävä päätös, että mennäänkö suomenkielellä vai kansainvälisellä, ifc-speksin mukaisella vaihtoehdolla. Valinta päätyi kansainvälisyyteen.

Kansainvälisesti tietosisällön vakiointihankkeita on menossa useita, mutta emme löytäneet sieltä suoraan, suomalaiseen suunnittelu- / rakentamiskulttuuriin soveltuvia vaihtoehtoja. Lopputulos oli tehdä speksi englanniksi. Ajatuksena myös se, että ehkä joku toinen maa ottaisi meidän tekemän speksin käyttöön - näin saisimme synergiaa aikaiseksi. Näitä vakiointeja ei ole kuitenkaan julkaistu vielä kovinkaan montaa.

Huomioitavaa siis on, että virallinen bSF vakiointi tarkoittaa vakiointia englanninkielisillä propertyillä ja propertyseteillä. Property value (eli arvot propertyille) voivat olla joko englantia, numeroita, swahilia tai valintoja "Selection List" -listasta. Siis sitä, mitä tilaaja vaatii omalle kohteelle tuotettavaksi.

Käyttötapaustaulukko (=ruksihelvetti)

Ehdottomasti vaikein osuus tämän vakiointitaulukon jalkauttamisesta kentälle tulee olemaan käyttötapaustaulukoiden käyttö.

Käyttötapaustaulukot kertovat, mitä tietosisältöä tilaaja haluaa saada suunnitelmiinsa, rakennusvaiheeseen ja ylläpidon käyttöön.

Käyttötapaustaulukot eivät ole vielä tehtynä tässä ensimmäisessä julkaisussa. Vuoden 2019 aikana tehdään taulukko, joka vastaa Yleisten Tietomallivaatimusten YTV2012 tietosisältövaadetta.

Julkaistussa excelissä on mukana myös tyhjä taulukko käyttötapausmäärittelyjen tekemiseksi. Isoin haaste sen tekemiselle oli erilaisten LVISA laitteiden kategoriointi. Onko meillä käytössä omat sisältövaatimukset komponenteille "Venttiili" ja "Linjasäätöventtiili". Vai menevätkö ne samalla tietosisällöllä?

Käyttötapaustaulukoita tehdään tarpeen mukaisesti lisää. Niitä voi tehdä tilaajat haluamallansa tietosisällössä, mutta ainakin taulukot ylläpidon-, määrälaskennan- , yleissuunnittelun ja toteutussuunnittelun vaatimuksista  tullaan tekemään bSF TATE-ryhmän toimesta.

TATE-komponenttien kategoriat

Henkilökohtaisesti erittäin korkealle arvostamani henkilöt olivat sitä mieltä, että kategorisointi on täysin turhaa. Komponenteille kerrotaan yhdellä propertyllä, mikä se on. Eli esim. "Ultraviolettisterilisaattori" olisi oman kategorian arvoinen. Ajatus oli, että jokaisella komponentilla on "Minä olen" -tyyppinen propertytieto.

Tähän ei menty, vaan tehtiin kaksiportainen komponenttien tunnistusjärjestelmä.
Property "Object Type" kertoo pääkategorian, joka on siis käyttötapaustaulukoiden otsikkona.
Property "Object Subtype" kertoo tarkenteen pääkategorian laitteelle.

Esimerkki:
"Object Type" = "Venttiili"
"Object Subtype" = "Linjasäätöventtiili"

Näin siis saadaan 95% TATE -komponenteista päägategorioiden alle ja kun halutaan kertoa todella tarkka speksi komponentin tyypistä, voidaan kirjoittaa kenttään "Object Subtype" arvo "Ultraviolettisterilisaattori". Tämä kenttä toimii kuten vaatimus "Minä olen" -tiedolle.

Yksiköt (Units)

Taulukon julkaisun jälkeen tuli heti pari kyselyä siitä, että millä yksiköillä arvot kirjoitetaan.

Pääsääntö on se, että käytetään IFC-speksin mukaisia logiikoita - mitä se sitten tarkoittaakaan.

Excelissä sarakkeessa " i " näkyy "plus" merkintä, jonka avaamalla saa näkyville ne yksiköt, joita halutaan ohjelmistoissa näkyvänä.  (excelissä on  siis piilotettuna sarakkeita)

Eli jos on Discipline "Piping" niin olisi kiva, jos olisi kPa arvoja paineen yksikkönä. Jos on "Ventilation", niin "Pa" on paljon parempi arvo näytöllä kun klikkaa komponenttia.

Yksiköiden käyttö IFC speksin sisällä ei vaikuta olevan mitenkään yksinkertaista eri softatoimittajien välillä. Tästä otetaan mielellään kommentteja vastaan - miten tämä tulisi speksata, jotta softat pystyvät yksiselitteisesti toimimaan siten, että käyttäjä näkee yksiköitä, joita haluaa nähdä.

Tilaajat, rakennuttajakonsultit, tarjousten laatijat

Toivon, että ette käytä tätä tietosisällön vakiointitaulukkoa lyömäaseena esim. luovutusmallien tekemisen yhteydessä.

Jos ruksaatte käyttötapaustaulukkoon "Kaikki" tiedot, niin miettikää, mille osapuolelle niiden täyttö tulee osoittaa. Miettikää, mikä tieto on tärkeää ja mikä ei.

Ennen kaikkea miettikää, kuka tulee tietoa käyttämään? Ei ole mitään järkeä pyytää as-built tietoa, jos sitä ei tulla käyttämään missään hyödyksi. Tuleva saneeraus ei riitä vastaukseksi - se tulee vasta 5-10 vuoden päästä. Rakennus (ja softat) on muuttunet jo tuohon mennessä. 

Henkilökohtaisesti en tiedä yhtään kohdetta, joissa olisi ylläpidon aikana ollut CoBIE käytössä, (tai sillä siirretty tietoja) ylläpitojärjestelmään. Se että BIM mallit on kunnossa, ei tarkoita sitä, että ne olisivat käytössä. Ja päivittyisivät rakennuksen elinkaaren aikana.

Suunnittelijalle ja urakoitsijalle jokainen ruksi maksaa rahaa. Se näkyy myös tarjoushinnoissa.

Kun vaaditte tietosisältöä, muistakaa myös varmistaa, että saatte sitä.

On epäreilua, jos joku lipeää siitä, mitä on pyydetty. Kun EIR (https://www.designingbuildings.co.uk/wiki/Employer%27s_information_requirements_EIR ) on tehty, niin BEP (https://www.designingbuildings.co.uk/wiki/BIM_execution_plan_BEP ) vastaa siihen, mitä on vaadittu ja miten se aiotaan toteuttaa.

Varmistakaa, että saatte sitä mitä on tilattu.

On muistettava, että tietosisällön tuottamisesta maksettu raha on pieni asia siitä hyödystä, jotka saavutetaan, kun tietomalleja käytetään rakennuksen elinkaaren aikana.

Tietomallin sisältämä Tieto on tärkeämpää kuin seinän sijainti graafisessa ympäristössä.

Puolen vuoden kuva:

Tästä se lähtee:

Kommnetit bSF taulukkoon, jätä  mieluiten tähän blogiin. Tai Twitteriin / LinkedIniin.

TATE-määrälistoja ei urakoitsija tule näkemään

Viime vuoden lopulla saatiin päätökseen KIRA-digihanke "Talotekniset määräluettelot urakkalaskentaan".

Toimin buildingSMART Finlandin TATE-työryhmän vetäjänä, joka oli tätä KIRA-digihanketta hakenut.

Loppuraportti on ladattavissa täältä:
http://www.kiradigi.fi/3-kokeiluhankkeet/kokeiluhankkeet/talotekniset-maaraluettelot-avuksi-urakkalaskentaan.html

Hanke oli kohtalainen tuskien taival. Onneksi se oli "kokeiluhanke", jossa yhtenä aspektina on aina epäonnistumisen mahdollisuus.

Epäonnistuimmeko tässä hankkeessa?

Jos katsoo projektisuunnitelmaa, niin vastaus on selkeästi "Kyllä".

Emme löytäneet todellisia urakkalaskentaprojekteja tähän hankkeeseen, jotta olisimme voineet testauttaa bSF:n laatimaa ohjeistusta määräluetteloiden käyttämiseksi:
https://buildingsmart.fi/wp-content/uploads/2016/11/YTV2012_Taydentava_liite_TATE_Prosessiohje.pdf
ja
http://tietomalli.blogspot.fi/2015/12/51-miljoonan-euron-saasto-vuodessa-sis.html

Jos asiaa katsoo jatkuvan parantamisen periaatteilla, niin vastaus on "Ei".

Voidaan todeta, että meillä on vielä paljon parannettavaa - koko rakennusalan laajuudessa. On mielestäni piristävää nostaa esiin fiksuja kehitysehdotuksia, jotka eivät kuitenkaan syystä tai toisesta tule käytäntöön.

Välillä tuntuu, että ratkaisut rakennusalan tai sen tuottavuuden kehittämiseen ovat liian yksinkertaisia. Ongelma on siinä, että usean ihmisen tai organisaation tulee tehdä samanaikaisesti tätä kehitystä. Tästä syystä allianssihankkeissa kehittäminen on mahdollista. Kaikilla osapuolilla on lupa toimia toisin / innovatiivisesti.

Toisin sanoen, "bottom-up" malli ei toimi rakennusalan kehittämisessä.

Tarvitsemme Kekkosen, joka sanoo miten toimitaan - ja sen jälkeen alkaa suorittavassa portaassa tapahtua.


Tässä copy/paste loppuraportista, eli analysointia siitä, miksei pilottikohteita löytynyt:
---
Miksi projekteja ei löytynyt? 
Suureksi pettymykseksi emme pystyneet vakuuttamaan todellisten hankkeiden vetäjiä siitä, että määrätietojen antaminen TATE-urakoitsijoiden käyttöön olisi kokonaisuuden kannalta hyvä ratkaisu.

Syitä projektien löytymättömyyteen ovat ainakin seuraavat aiheet:

BuildingSMART Finlandin sisäiset asiat:
- Ryhmässä olevat jäsenet kuuluvat pääsääntöisesti yritysten kehitysorganisaatioihin. Heillä ei ole henkilöinä suuriakaan mahdollisuuksia vaikuttaa yritysten liiketoiminnallisten projektien vetämiseen.
- BuildingSMART toimii ”harrastajapohjalta” ja jokaisella jäsenellä on selkeästi päätyö ensimmäisenä prioriteettina. Projekteja olisi voinut hankkia tarmokkaamminkin, mutta ajankäytöllisistä syistä siihen ei ollut mahdollisuuksia. Ydinjoukko hankkeen organisoinnissa oli kohtalaisen pieni, noin viisi henkeä.
- Jotta projekteja olisi löytynyt, olisi tullut panostaa enemmän yritysten johdon vakuuttamiseen asian kokonaistaloudellisesta tärkeydestä. Nyt keskustelimme projektinvetäjätasolla, jolloin helposti taloudellisessa vastuussa oleva projektipäällikkö ei halua ”ylimääräisiä” tehtäviä mukaan projektiinsa – varsinkin kun rakennusprojekti on alkuvaiheessa ja muita järjestettäviä asioita on paljon avoimena.

Ulkopuoliset asiat: 
- Projekteja ei löytynyt oletettavasti siitäkään syystä, että kenenkään hankkeiden käynnistämisessä mukana olevien henkilöiden intressissä ei ole luovuttaa määrätietoja urakoitsijoille. Ajatellaan ehkä vain käynnistettävää, yhtä hanketta, näkemättä kokonaiskuvaa Suomen mittakaavassa.
- Projektien löytymiseen vaikutti myös aikataulu, sillä tieto määräluetteloiden käyttämisestä hankkeessa olisi pitänyt saada mukaan jo suunnittelijoiden tarjouspyyntöihin. Tämä tarkoittaa sitä, että olisi tarvittu hankesuunnitteluvaiheessa oleva projekti, jossa tilaajan edustus olisi ollut avarakatseinen hankkeen päämääriä kohtaan.
- Koska rakennusalan kehitystä ei pystytä toteuttamaan ruohonjuuritasolta, tulisi yritysten johdon sekä rakennushankkeita tilaavien osapuolten nousta vaatimaan uusien, toimivaksi osoitettujen toimintatapojen käyttöönottoa

Eräänä syynä projektien löytymättömyyteen pidän henkilökohtaisesti sitä, että rakennusalalla puuttuu halu kehittää omaa osaamistaan. On helpompi tehdä kuten ennenkin, vaikka pystytään osoittamaan uusien prosessien hyödyllisyys hankkeelle.
Yleisesti rakennushankkeen eri osapuolten keskuudessa on todettu, että määrälistojen käyttö hankkeissa olisi ehdottomasti järkevää. Siitä hyötyisivät kaikki osapuolet, se toisi urakoitsijoiden tarjoushintoja lähemmäksi toisiaan jolloin voitaisiin tehdä vertailukelpoisia urakoitsijavalintoja.
Lisäksi suunnitelmien laatu nousisi pienen pykälän, sillä kun suunnittelijalla on tiedossa, että kohteesta otetaan määrälistat, aletaan kiinnittää enemmän huomiota tietomallien tietosisällön oikeellisuuteen.

---

Henkilökohtaisesti tämä oli minulle viimeinen taisto määrälistojen puolesta puhumisessa. Nyt pitää vaihtaa henkilöitä, sillä 20v olen tästä puhunut / yrittänyt ja tuloksia ei ole tullut. Vedän siis "omat johtopäätökset".


Viikon kuva:

API nana ko?

Nyt alkaa rakennusalallakin näkyä sana "API" siellä sun täällä.

Huom! tämän blogin alaosassa on kaksi haastetta rakennusalalle (tiedän, että suurin osa ei jaksa lukea tätä loppuun asti...)

---

Open API ja REST API. Documented API. JSON.... jne. Näitä viljelevät ne kaverit, jotka eivät tajua mitä tuo tarkoittaa - kuten minäkin.

Olen yrittänyt opiskella APIen mahdollisuukisa tämän vuosikymmenen alusta lähtien, kun meidän firman softa-arkkitehti sellaiset minulle esitteli. Käsittääkseni / toivottavasti tämä on nyt meidän firman viimeisintä hottia:
https://designer-demo.granlunddesigner.fi/api/index

Ihan turha kysyä minulta mitä nuo tarkoittavat, mutta tiedän sen, että kun niitä lukee joku toisen firman devaaja ja hän haluaisi saada meiltä jonkun kiinteistön pumpun tiedot, niin me saadaan se hänelle toimitettua ilman yhtään ylimääräsitä työtä. Kunhan me luotetaan hänen softaan, kunhan meillä on kiinteistöomistajan oikeus jakaa se tieto.

Nyt päästään moneen herkulliseen asiaan kiinni. Saako tietoa jakaa ilman, että olemme sopineet tiedon antajan kanssa asiasta?

Mitä kun (ei jos) haemme tietoa monesta eri lähteestä ja muodostamme näistä tiedoista sellaista tietoa, jota ei ole olemassa? Onko tuo tieto meidän tietoa vai pitääkö meidän kysyä joltakin, että "Teidän tietoa on käytetty tämän tiedon tuottamiseen arviolta 12% verran. Saatte meiltä 1% alennuksen Saas -palvelustanne" ?

Esimerkki:
Haen lämpötiloja kiinteistöstä A1 olevilta toimistohuoneilta. Samalla haen ilmatieteenlaitokselta avoimen datan kautta ulkoilman lämpötiloja. Teen näiden kahden eri arvon kanssa trendikäyrän vuoden ajalta.
Sitten teen saman kiinteistölle A2 ja sen toimistohuoneille.
ja A3:selle. Ja neloselle jne.

Tiedän kaikien kohteiden pinta-alan avoimen kaupunkimallin kautta. Tiedän näiden kiinteistöjen nykyarvon. Tiedän näiden kiinteistöjen aurinkoenergiapotentiaalin avoimen datan kautta. Tiedän energiankulutuksen koska mittaamme sitä. Ja sen saan myös energialaitokselta. Tiedän sairaspoissaolot. Tiedän henkilöstön vaihtuvuuden.

Ym. tiedoista pystymme muodostamaan todella paljon uutta tietoja, joka palvelee kiinteistömassojen omistajaa. Mutta voisiko sitä tietoa jakaa myös muille? Edes anonyyminä, neliöpohjaisena tunnuslukutietona?

Jotta ym. skenaario on mahdollinen, niin tiedon pitää olla käytettävissä valituille softatoimittajille / yhteistyökumppaneille. Kukaan ei tee softaa, jos lopputuloksista pitää maksaa ensimmäisen tiedon tuottajalle. Vai maksaako?

Ensimmäisen tiedon tuottaja on triggeri, joka laukaisee koko analyysin eteenpäin. Tuosta triggeristä pitäisi olla hyötyä kaikille, jotka samaan kelkkaan lähtevät.

Ja sitten asian pihvi businessporukoille; miten tästä tehdään rahaa?
Vastaus: Lohkoketjuilla.

lämpötila / aikayksikkö = rahan arvoinen tieto.

Kun lähetän (siis joku kysyy sitä) APIn kautta lämpötilatiedon softa b:eelle, tienaan lohkoketjun kautta siitä 0,01 senttiä. Jos tämän minulta tulleen alkuperäisen lämpötilan lähettää softa  b eteenpäin soft c:lle, niin saan siitä 0,01+0,01 senttiä. jne. jne.... jne^2.
Rahantuloa ei voi estää...

Blockchainin kautta originaalin tiedon tuottaja tienaa, transaktio on jäljitettävissä ja todistettavissa automaattisesti, ilman ihmisen työtä.

Kun softa b rikastaa omalla softalla minulta saatua tietoa, ja tämä rikastettu tieto on sellaista, jota itsekin tarvitsen niin me olemme lukittauduttu toisiimme. Saan siis ilmaiseksi tietoa, jota tarvitsen jonkun toiminnallisuuden toteuttamiseksi.

Tämä tarkoittaa sitä, että kannattaa tehdä itsensä niin tarpeelliseksi, että sinun tietoja hyödyntävä softa ei pysty toimimaan jollet pysty tarjoamaan tietoa heille.

Pitää olla kaikkien kilpailijoiden paras kaveri.

Tiedon jakaminen on uusi Musta.

Tiedon jakaminen laajentaa muut softat myyntiyksiköiksi.


Haaste 1
Haastan kiinteistöomistajat jakamaan omien kiinteistöjen tietoja avoimeen rajapintaan.

Esim. €/m2 , kWh/m2 tai muilla "anonyymisillä" arvoilla. Tai jos olette todella edistyneitä, juuri niillä mittaustuloksilla, jotka olette tehneet kiinteisössä. Eli yksittäisen tilan lämpötila, kosteus, äänitaso, viihtyvyys, ilman laatu rakennuksen sisällä ja ulkopuolella...

Näin voisimme rakentaa Suomessa tietokannan, josta oikeasti tiedämme  miten eri tyyppisillä kiinteistöilä menee. Ja en tarkoita pelkkää energiaa, koska se on jo arkipäivää. Tarkoitan esim. todellisia siivouskustannuksia, käyttäjätyytyväisyyttä, vuokralaisten vaihtuvuutta, kahvinkeittimen täyttöastetta...

Ongelma 1: minne sitä tietoa talletetaan? Mikä avoin rajapinta? Missä?

Haaste 2:
Kaikki puhuu "Väylästä" jonne tieto laitetaan ja sitten se on jotenkin simbsalabBIM kaikkien käytettävissä.

Haastan rakennusalan tekemään "Väylän" vaatiman API speksit.

---
Meidän pitää sopia yhteisesti API VÄYLÄ. Ei muuta. Ei tarvitse sopia, kuka ylläpitää sitä. Ei tarvitse hypätä ylimmälle portaalle yhdellä hypyllä.

Kun API väylä on speksattu, voi softafirmat alkaa tehdä omia APEja siihen yhteensopiviksi. Vasta sen jälkeen, kun rakennusala pystyy osoittamaan yhteisen suunnana tiedon jakamisesta, voivat useat eri softatoimittajat alkaa tehdä siihen rajapintaan soveltuvia ohjelmistoja.

Tarkoitus ei ole tallettaa mitään API väylään (poislukien käyttäjien / firmojen tunnistautuminen). Tiedon tallennuksen hoitaa softat, jotka tukevat speksattua API väylää.

Kiinteistön omistaja voi valita itsellensä sopivat palveluntuottajan. Ja vaihtaa sitä toiseen, jos homma ei toimi. Uusi palveluntuottaja saadaan leivottua helposti olemassa olevaan systeemiin, sillä rajapinnat ovat tehty yhteisellä speksillä.

Rakennusalan pitää ensiksi sopia, minkälaisia API rakenteita tehdään. Siis näin yksinkertaisia speksejä koodareiden mietittäksi:
- Anna minulle kiinteistön nimi
- Anna minulle kiinteistön osoite
- Anaa minulle kiinteistön ikkunat
- Anna minulle kiinteistön ikkunat ja sen propertyt
- Anna minulle kiinteistön ikkunoiden propertyistä U-arvo
- Jaa kiinteistön ikkunat
- Jaa kiinteistöin ikkunann U-arvo
- Jaa ihan mitä vaan mitä ollaan löydetty

Ym. tarkoittaa sitä, että ei pidä määritellä, missä tieto on, vaan pitää määritellä rajapinnat.
Sen jälkeen kun olemme tehneet rajapinnat, softavalmistajat pystyvät tekemään softaa sen päälle.

Use-caset tulevat sen jälkeen, kun tiedetään, mitä tietoa on tarjolla.

Näin pääsemme avoimeen rajapintamäärittelyyn Suomen kiinteistöjen osalta. Näin saadaan softaa joka pystyy luottamaan avoimiin rajapintoihin.

Kun määrittelemme esim. buildingSMARTin kautta APIen tietosisältövaatimukset, pääsemme tasolle, jota ei muualla ole.

Ym. tekstistä päästään hienosti semanttiseen webiin, jota on tutkittu Drumbeat hankkeessa:
http://www.drumbeat.fi/
http://www.drumbeat.fi/pdf/RESTinterface.pdf


BIM Level 3 UK:ssa ei ole mitään meille Suomalaisille, me ollaan sentään jo 100 vuotiaita! Siis teinejä verrattuna britteihin, virtaa riittää.


Viikon kuva:
Suomi 100
Tosi mukavaa olla Suomalainen

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

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.