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

Allianssien kilpailuasetelmat tarjousvaiheessa

Lensin tänään pihalle erään allianssihankkeen valmennustilaisuudesta, jossa tähdätään hyvään lopputulokseen kehitystyöpaissa ja tietenkin hankkeen voittamiseen.

Alkutilanne:
Olen mukana ryhmittymässä A, joka tarjoaa kohdetta B.
Muutaman kuukauden päästä minut kutsuttiin ryhmään C joka tarjoaa kohdetta D.

Olin ryhmän C valmennustilaisuudessa, jossa tajusin että tämän hankkeen pääurakoitsija on tarjoamassa myös hankkeen B kohdetta eri suunnittelijatiimillä.

Minulla on tässä ilmeisestikin selvä eturistiriitaongelma.

Ensimmäisen tauon jälkeen ilmoitin kaikille tästä tilanteesta. Pienen sekavuuden ja yleisen kommentoinnin jälkeen minulle tultiin kertomaan, että eturistiriita on selvä, kohteen B asioita aiotaan hyödyntää kohteen C pääurakoitsijan toimesta. Näitä suuria salaisuuksia ei voi minulle paljastaa.

Voin sanoa, että ryhmän C pääurakoitsijan ideat eivät ole välttämättä minulle ihan suuria yllätyksiä, koska olen ollut heidän kehittäjien kanssa tekemisissä viimeiset 10 vuotta, samoissa kehityshankkeissa, samoilla ajatuksilla. Olen myös ollut heitä kouluttamassa tietomallipohjaisen suunnittelun prosesseista.

Ihan looginen valinta on, että minulle ilmoitettiin olevani vapaa poistumaan valmennustilaisuudesta / ryhmän C allianssiprojektista (siis pääurakoitsijan päätöksellä, ei allianssin).

Siitä ei ollut mitään juttua, että edustamassani toimistossa on ~850 henkeä töissä. Olen lähes varma, että joku meistä on aina jossain allianssissa mukana ilman että muu firma / toisen osapulen yritys siitä tietää. Sen kyllä tiedän, että osassa projekteja allekirjoitetaan NDA -julistuksia, joita ei oltu tässä tehty - joskin se olisi ollut loppupeleissä kuitenkin aikamoista hurskastelua.

Ym. tilanne kuvaa asiaa, joka minulle ei ole tullut aikaisemmin mieleen. Kun allianssihankkeet leviävät Suomessa, niin miten niiden tekijät lukumäärällisesti riittävät? Nyt kysytään projekteihin henkilöitä nimillä, tarjouksissa. Joissakin hankkeista on aivan käsittämätön suuri rahallinen sakko sille, jos projektihenkilökuntaa vaihdetaan kesken hankkeen. Suurin piirtein pitää kuolla tai vaihtaa alaa, jos haluaa päästä eroon projektista.

Tällä hetkellä allianssit muodostetaan yleensä isoihin projekteihin. Nämä hankeet kestävät 1-5 vuotta (tai 20v, sekin on jo koettu...).

Kysymykseni on:
Miten yritykset voivat sitoa firman SKOL01-02 kaverit hankkeisiin niissä vaadituilla spekseillä viiden vuoden projektiin ilman eturistiriitoja?

Oma vastaukseni on: Ei mitenkään.

Nykyiset vaatimukset tarkoittavat sitä, että Suomessa voi olla käynnissä vain 4-8 talonrakennuksen allianssihanketta projekteissa, joiden suuruus on yli ~50M€ (täysin hatusta heitetyt numerot). Pätevyydet täyttäviä ammattilaisia ei löydy ja yritykset alkavat fiksata henkilöitä useisiin projekteihin. Tämä ei voi olla Allianssin tarkoitus. Pitää hyväksyä, että on olemassa ykkös- ja kakkosketjuja. Kukaan ei halua kolmosketjua, vaikka se voi olla "nälkäinen" ja ylittää ykkösketjun tuotokset.

Itse valitsisin kolmosketjun. Siellä on henkilöt, jotka haluavat muutosta - jota uudet toimintamallit edellyttävät. Heillä on halu näyttää, että "täältä tullaan". He ovat irti vanhoillisista metodeista, osaavat oikeasti ryhmätyön filosofian ja pitävät sitä normaalina tapana toimia hankkeissa. Kun nämä henkilöt hommataan eri firmoista niin löydetään yhteiseen hiileen puhaltava, nälkäinen nuorisojoukko - jotka ovat täysin oman alansa ammattilaisia.

Kenellekään ei pitäisi opettaa yhteistyötä, se pitää tulla sydämestä.

Sanon tämän lauseen siksi, että ryhmässä C (josta lensin pihalle) ei oltu (vielä) pääurakoitsijan toimesta ymmäretty Allianssin syvintä merkitystä - me teemme tämän yhdessä!

Pääurakoitsija tietää, mitä pitää tehdä kehitystyöpajassa mutta väitän, että he eivät ymmärrä, mitä pitää tehdä kehitystyöpajassa.

Me olemme Allianssi. Siihen kuuluu myös käyttäjä ja tilaaja.

Viitaten edellisiin kirjoittamaani blogeihin:
Rakennusala, Yhteistyötä!

Ymmärtäkää kokonaisuus.


Viikon mietelause:
Mukavinta oli, että ym. kakkoshankkeen (C) uloskävelyn jälkeen minulle tuli kahdesta eri firmasta viesti, jonkan sisältö oli yhteenvedettynä: "Olisi tuon teron tietoja / ymmärrystä voinut tässä kyllä käyttää hyväksikin..."

Autodesk on Ystävä

Toukokuussa 2016 kirjoittelin Autodeskin lisensseistä:
http://tietomalli.blogspot.fi/2016/05/autodeskin-lisenssikaytanto-muuttuu.html

Autodesk muutti lisenssikäytäntöä radikaalisti viime vuonna. Tämän perusteella firmat tekivät Autodeskin edustajien ehdottamia ratkaisuja, ja päivittivät softiansa Autodeskin ilmoituksen perusteella -> ostivat lisenssejä "tulevaisuutta varten". Muuttivat olemassa olevia lisenssejä säästääkseen "tulevaisuudessa". Pääsääntöisesti siksi, että pääsevät subscripton asiakkaaksi (joka käsittääkseni on ao. viestissä sama kuin "ylläpitosuunnitelma".)

Tulevaisuus näyttää loppuneen maaliskuussa 2017 kun Autodeskiltä tuli uudet lisenssimääritykset.

Viesti (en ota kantaa Suomen kielioppiin):











Tärkeä ilmoitus

Hei,

Haluamme kertoa lyhyesti Autodeskin nykyisestä suunnasta sekä tietyistä tulevista muutoksista, jotka vaikuttavat ylläpitosuunnitelmaasi. Lisäksi esittelemme tilaukseen siirtymistä koskevan erikoistarjouksen, johon sinun kannattaa tutustua.

Uskomme, että tilaus on paras tapa nauttia työkaluistamme ja teknologioistamme. Tilaus muuttaa merkittävällä tavalla sitä, kuinka toimitamme laajennettuja ominaisuuksia ja uusia toimintoja yhdistettyjen palveluiden kautta. Siksi olemme yrityksenä siirtymässä pelkästään tilauspohjaisiin malleihin. Investoimme jatkossakin erittäin voimakkaasti tilaustarjontaamme, jotta pystymme tarjoamaan sinulle enemmän lisäarvoa seuraavien etujen kautta:



•
Uusimmat tuoteominaisuudet – hyödynnä Autodeskin uusia innovaatioita, päivityksiä keskeisiin tuotteisiin, työpöytätuotteiden pilvipalveluita ja lisätoimintoja heti, kun ne ovat saatavilla, ja ilman lisämaksuja.

•
Uusien toimialakokoelmien käyttö – saatavilla vain tilauksena. Säästät huomattavan summan, jos tarvitset kahta tai useampaa Autodeskin ohjelmistoa.

•
Uusi parannettu tuki – nopeampi vasteaika ja mahdollisuus puhelinajan varaukseen Autodeskin teknisten tukiasiantuntijoiden kanssa.

•
Yksinkertaistettu hallinta – käytä työkaluja, jotka virtaviivaistavat kehitystä ja ohjelmistohallintaa, kun standardoit kaikki Autodesk-tuotteesi tilauksen alle.



Tilauspohjaisiin malleihin siirryttyämme olemme selvästi havainneet erään asian: kahden liiketoimintamallin ylläpitäminen (tilaukset ja ylläpitosuunnitelmat) on hyvin kallista. Jotta voimme jatkaa ylläpitosuunnitelmien tarjoamista, 7. toukokuuta 2017 alkaen tilausten uusintahinnat nousevat 5 % (2017), 10 % (2018) ja 20 % (2019). Huomaa myös, että ylläpitosuunnitelman voi tästä lähtien uusia vain vuodeksi kerrallaan.

Nyt kun olemme kertoneet Autodeskin suunnasta yrityksenä, haluamme kertoa erikoistarjouksesta, joka voi auttaa sinua harkitsemaan tilausvaihtoehtoa. Sen myötä haluamme antaa tunnustusta asiakasuskollisuudellesi sekä aiemmille investoinneillesi. Kesäkuusta 2017 alkaen voit siirtää ylläpitosuunnitelmaan kuuluvat tuotteesi tilauspohjaisiksi alennettuun hintaan. Tämä alennusprosentti laskee 5 % vuonna 2018 ja toiset 5 % vuonna 2019, eli mitä nopeammin vaihdat tilauspohjaiseen malliin, sitä vähemmän maksat – ja sitä enemmän säästät verrattuna niihin asiakkaisiin, jotka siirtyvät tilaukseen myöhemmin tai jatkavat ylläpitosuunnitelmassa. Kun teet tämän vaihdon, voit myös lukita alennetun hinnan jopa kolmeksi vuodeksi. Olet oikeutettu alennushintaan niin kauan kuin uusit tilauksesi.

Tiedämme, että sinulla on luultavasti kysymyksiä. Nämä ovat suuria muutoksia, ja olemme valmistautuneet auttamaan sinua niissä. Lisätietoja saat usein kysytyistä kysymyksistä. Voit myös ottaa yhteyttä Autodesk-myyntiedustajaan tai jälleenmyyjään, mikäli haluat keskustella vaihtoehdoista, jotka sopivat parhaiten omiin teknisiin vaatimuksiisi ja omaan liiketoimintaasi.

Valitsitpa tilaukseen siirtymisen tai ylläpitosuunnitelmasi uusimisen, lupaamme jatkossakin toimittaa sinulle alan parhaat ohjelmistot, palvelut ja tukipalvelut.

Ystävällisin terveisin,

(tämän editoin, tuskin "Teresa" tästä viestistä on vastuussa...)




---
Hienoa! Hyvä Autodesk! Kiitos yli 30v kumppanuudesta. Näin sitä asiakassuhdetta ylläpidetään!

Mielenkiintoista on kappale:
"Tilauspohjaisiin malleihin siirryttyämme olemme selvästi havainneet erään asian: kahden liiketoimintamallin ylläpitäminen (tilaukset ja ylläpitosuunnitelmat) on hyvin kallista. Jotta voimme jatkaa ylläpitosuunnitelmien tarjoamista, 7. toukokuuta 2017 alkaen tilausten uusintahinnat nousevat 5 % (2017), 10 % (2018) ja 20 % (2019). Huomaa myös, että ylläpitosuunnitelman voi tästä lähtien uusia vain vuodeksi kerrallaan."

Hienoa, että Autodesk on todennut meille "edullisen" (heidän määritelmä edustamalleni firmalle vuonna 2015) ja viime vuonna erittäin kalliilla hinnalla päivitetyn sopimusmallin meille sopimattomaksi. Viime vuonna Autodeskin edustajien mukaan se oli kyllä "ehdottomasti järkevä tehdä".

Kun teimme viimevuoden päivitystä, meille vakuutettiin "lisenssikäytäntö ei muutu lähiaikoina"

Lisäksi kappale:
"Uskomme, että tilaus on paras tapa nauttia työkaluistamme ja teknologioistamme. Tilaus muuttaa merkittävällä tavalla sitä, kuinka toimitamme laajennettuja ominaisuuksia ja uusia toimintoja yhdistettyjen palveluiden kautta"

on mielestäni sopimusehtojemme vastainen, sillä olemassa oleva suppari tarjoaa meille uusimmat tuotteet ja teknologiat. Tällainen paketti me ollaan ostettu kun suppari on tehty. Miten sen voi muuttaa erilaiseksi toisen osapuolen ilmoituksella?

Ja tämä:
"Uusien toimialakokoelmien käyttö – saatavilla vain tilauksena. Säästät huomattavan summan, jos tarvitset kahta tai useampaa Autodeskin ohjelmistoa."
Mitä mitä mitä? Me päivitettiin AutoCAD Architecturet -> Suite paketeiksi -> ihan varmaan meillä pitää olla supparillakin käytössä jatkossa kaikki Suitessa määritellyt tuotteet.

jatkuu:
"



Uusi parannettu tuki – nopeampi vasteaika ja mahdollisuus puhelinajan varaukseen Autodeskin teknisten tukiasiantuntijoiden kanssa."


Onko joku oikeasti saanut Autodeskiltä teknistä tukea? Siis suomeksi, yrityksen henkilökunnalle? Tuki tulee jälleenmyyjältä, jotka Suomessa ovat loistavia ammattilaisia. Autodeskin tuki on vitsi, google on parempi.

Lisenssioinnin lopputulos: muutamme omaa lisenssikäytäntöämme. Olemme Autodeskin narun perässä. Aloitan uudestaan korvaavien ohjelmistojen kartoituksen.

teroj

PS. tämä on minun omissa nimissä kirjoitettu teksti, ei edustamani yrityksen.


Viikon kuva:





Autodeskin viestissä on myös disclaimer, joka kertoo että:



Autodesk, Inc. • 111 McInnis Parkway • San Rafael, CA 94903

© 2017 Autodesk, Inc. All rights reserved. Oikeudelliset huomautukset ja tavaramerkit. Yksityisyyden suoja

Tämä on operatiiviseen toimintaamme liittyvä sähköpostiviesti.

Älä vastaa tähän sähköpostiviestiin. Vastauksia tähän sähköpostiin ei lueta eikä niihin vastata.

Autodesk, the Autodesk logo are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates in the USA and/or other countries. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product and services offerings, and specifications and pricing at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document.

Itse tulkitsen ym. tekstin, että viestiä saa jakaa sellaisenaan eteenpäin.

Digitaalinen kaksonen

Termi ”Digital Twin” on näkynyt viime aikoina silloin tällöin ulkomaisissa kirjoituksissa, joissa teemana on ollut tietomallien käyttö ylläpidossa.

Termi on mielestäni hyvä, koska se luo ajatustasolla ympäristön rakennusten analysoinnille ja havainnollistamiselle. Termi sinänsä ei ole uusi, se on ollut jo vuosia käytössä mm. mekaniikkateollisuudessa; https://en.wikipedia.org/wiki/Digital_Twins

Tarvitsemme rakennuksen digitalisen kaksosen, jos aiomme hallita sensoreiden synnyttämää valtavaa tietomäärää ihmiselle ymmärrettävässä muodossa.

Kun keräämme informaatiota rakennuksesta ja sitä analysoimalla luomme uutta tietoa, tarvitsemme tavan visualisoida sitä käyttäjälle. Yksinkertaisin visualisointitapa on esim. värjätä tiloja riippuen mitatusta lämpötilasta. Ihminen ymmärtää, että mitä punaisempi tila, sitä kuumempi se on.

Digitaalinen kaksonen synnytetään API –rajapinnoilla sekä alusta –ajattelulla

Jotta pystymme luomaan digitaalisen kaksosen, tarvitsemme reseptiksi vähintään:
1. Rakennuksen graafisen tietomallin, standardisoidulla tai tiedossa olevalla tietosisällöllä
2. Alustan, joka yhdistää graafisen näkymän pilvipalveluiden tietosisältöihin.
3. Dokumentoidut (tai avoimet) rajapinnat, joilla eri järjestelmät kommunikoivat keskenänsä

Kuva 1: Periaatekaavio dokumentoitujen API:en (esim. https://designer-demo.granlunddesigner.fi/api/index) avulla rakennettuun kehitysympäristöön.

Yksi tärkeä asia on ymmärtää staattinen ja dynaamisen tiedon ero. Staattisesta tiedon esimerkkinä toimii mm. Ilmanvaihdon palvelualue. Se ei muutu, jollei rakennukseen tehdä konkreettisia muutostöitä. Dynaamisen tiedon esimerkkinä toimikoon tilan lämpötila. Sitä mitataan jatkuvasti ja mittaustuloksen perusteella voidaan analysoida, onko tilassa kaikki OK. Jos ei ole, niin staattisen IV-palvelualuetiedon perusteella voidaan päästä käsiksi lisätietoon, esim. IV-koneen ulospuhalluslämpötilaan ja analysoida, onko se kunnossa.

Yksittäisen tilan tai tiloista koostuvan palvelualueen välille muodostetaan siis yhteys, jonka kautta voidaan lähteä automaattisesti selvittämään mahdollisia ongelmakohtia kysymykseen: ”Miksi tilassa on kuuma?”

Analysoinnin perusteella järjestelmän tulee pystyä esittämään käyttäjälle mahdollisia vaihtoehtoja ongelman syyksi. Tietoa kerätään myös ohi rakennusautomaatiojärjestelmän, mm. API rajapinnoilla varustetuista IoT antureista, joista saatujen lisätietojen perusteella digitaalinen kaksonen muodostaa kokonaiskuvan.

Kuva 2: Esimerkki Granlund Manager Metrix –prototyypistä, jossa kiinteistöautomaatiojärjestelmä 

syöttää lämpötiloja pilvipohjaiseen tietomalliin.

Visiona ”Virtuaalinen kiinteistö, jossa käyttäjä ja rakennus kommunikoivat keskenään”

Granlund on julkaissut Innovaatiostrategian vuosille 2017-2021.

Innovaatiostrategian visiona on saavuttaa ”Virtuaalinen kiinteistö, jossa käyttäjä ja rakennus kommunikoivat keskenään”

Kun pystymme yhdistämään virtuaalisen rakennuksen käytettävissä olevaan staattiseen ja dynaamiseen tietoon, pystymme niiden avulla luomaan uutta informaatiota. Kuljemme analysointien avulla kohti raportoivaa kiinteistöä.

Seuraava askel analysoinnista on kiinteistön käyttäytymisen ennustaminen. Tässä vaiheessa pystymme simuloimaan automaattisesti esim. kiinteistön energiankulutuksen ja sisäympäristön olosuhteet seuraavalle päivälle sääennustuksen sekä tulevan ihmiskuorman ja sen aikataulujen perusteella. Tällä tiedolla pystymme ohjaamaan järjestelmää ennakoivasti, ilman manuaalisäätöjä.

Näin olemme matkalla kohta oppivaa kiinteistöä. Kiinteistö kehittää itsellensä vuosien saatossa omaa tekoälyä oppien tekemistään virheistä mm. silloin, kun tehty ennustus ei vastannutkaan kiinteistön todellista, mitattua tilannetta.

Oppiva kiinteistö tarvitsee käyttäjäpalautetta, jonka avulla tuotetaan tilojen käyttäjille optimaalisinta olosuhdetta. Vain käyttäjä voi tietää, mitä hän haluaa – siihen ei edes tekoäly auta. Tämän lisäksi kiinteistön käyttöä anonyymisti seuraamalla ja analysoimalla pystymme muodostamaan kuvan miten käyttäjäjoukko vaikuttaa kiinteistön toimintaan. Jo pelkkä oppiminen siitä, mikä on kiinteistön käyttöaste eri ajankohtina kertoo paljon talotekniselle ohjausjärjestelmälle – puhumattakaan, mitä se kertoo yrityksen johdolle kiinteistön soveltuvuudesta oman liiketoiminnan harjoittamiseksi.

Emme voi kuitenkaan unohtaa kiinteistön fysikaalisia ominaisuuksia, kiinteistön on toimittava kuten se on suunniteltu toimivan. Granlund –konsernin 2020 Strategian missiona on ”Hyvinvointia rakennetussa ympäristössä”.

Tätä tavoitetta toteutamme Innovaatiostrategiassa, kun muistamme että: ”Käyttö ohjaa kaikkea tekemistämme”

Viikon kuva:

Mun duuni seuraavien vuosien aikana:

Vieraskynä: TATE-tietomallien käyttö työmaalla

Johanna teki alkuvuodesta osana YAMK opinnäytetyötä kyselyn Talotekniikan tietomallien käytöstä työmaalla, http://tietomalli.blogspot.fi/2016/12/osallistu-tate-tietomallikyselyyn.html

Tässä tuloksia:

---

Kyselytutkimustulokset ”TATE –tietomallien suunnittelumenetelmien kehittäminen ja mallien käyttö työmaalla”.

Kyselytutkimukseni sulkeutui virallisesti 31.1.2017 vastaajamäärän ollessa 42 vastausta. Vastauksista eroteltuna tästä porukasta 11 vastaajaa on yksiselitteisesti työmaaorganisaatioista ja 31 vastaajaa edusti erilaisia suunnittelu –tai ylläpitotehtäviä. Mielenkiintoista kyselyn tuloksista oli havaita, että niin suunnittelijoidenkin kuin työmaaväen näkemykset eivät poikenneet merkittävästi toisistaan. Tässä kirjoituksessa on lyhyt katsaus kyselyn tuloksiin. Tarkempi analysointi jää luettavaksi opinnäytteestä, joka valmistunee kesän aikana. Kiitos vielä kaikille vastaajille.

Kyselututkimuksen vastausten perusteella Talotekniikan tietomalleja käytetään niin suunnittelijoiden kuin työmaaväen osalta suunnittelun ja havainnollistamisen apuna, tormäsystarkasteluiden tuottamiseen, sekä kustannuslaskentaan. Näiden lisäksi suunnittelijat käyttävät malleja Energiasimulointien tuottamiseen, yhteensovittamiseen, markkinointiaineistojen tuottamiseen, auditointiin sekä tekniseen verkostolaskentaan. Työmaalla malleja käytetään puolestaan asennustöiden suunnitteluun ja etenemisen seurantaan, töiden ennakointiin, laadunvarmistukseen, suunnittelunohjaukseen ja valvontaan.

Kun kysyin vastaajilta mitä malleista heidän mielestään mahdollisesti tällä hetkellä uupuu, moni vastaaja korosti suojaetäisyyksien, tilavarausten, haalaus-ja huoltoreittien ja kannakkeiden puutteellista huomioimista tai malleista puuttumista. Vastauksista korostui myös eristysten puutteellinen mallinnus, joka ymmärrettävästi aiheuttaa ongelmia mm. kustannus –ja massalaskennassa. Laskentaan kuin tuotteiden (jopa väärien) käyttöön liittyen toivottiin LVI-numeroita liitettäväksi talotekniikkakomponentteihin. Vaatimusmallin käyttöä toivottiin, uskoakseni monestakin syystä koska tämän mukana siirtyy tilatiedon lisäksi mm. talotekniset mitoitusperusteet. Edellä mainittuihin löytyi komppaajia niin suunnittelijoiden kuin työmaan puolelta. Suunnittelijoiden joukosta nousi esiin em. lisäksi kappaleiden massatietojen puuttuminen. Tässä vaiheessa myönnän, että kaiken kiteyttävä vastaus oli kuitenkin ”asentajan käsi”.

Kyselyni yksi keskeisimmistä kysymyksistä oli kartoittaa vastaajien näkemyksiä siitä, pitäisikö malleista tarkastaa muutakin kuin pelkkää komponenttitörmäilyä? Mallien muu varsinainen tarkastaminen on tällä hetkellä lapsen kengissä ja käytännössä manuaalista työtä joka tehdään surffaamalla mallissa. Eikö olisi hienoa, kun voisit nappia painamalla saada ilmoituksen esimerkiksi kaikista komponenteista jotka osuvat komponentille määrätyn huoltotilan alueelle? Tai vaikkapa tarkastaa, että palohyllyjen yläpuolella k.o kerroksessa ei ole muuta tekniikkaa? Tai tarkastella, että vaatimusmalli vastaisi suunniteltua – ilman manuaalista työtä? Samaa periaatetta voi toteuttaa myös siihen, että tarkastetaan esim. että tietynlaisilla komponenteilla on määrätty tietosisältö – tätä voisikin sitten soveltaa aika laajalla spektrillä.

Ilokseni pystyin toteamaan, että lähes kaikki vastaajat toivat oman näkemyksensä esiin korostaen nimenomaan asennettavuuden ja huolto –ja haalausreittien, suojaetäisyyksien ja mitoitusarvojen tarkastamista.

Seuraavaa diagrammia tutkiessa täytyy korostaa, että ”Ei” vastaajat olivat kaikki suunnittelijapuolen edustajia, jotka korostivat pääasiassa kustannuspuolta. Urakoitsijoiden edustajista kaikki vastaajat olivat sitä mieltä, että yhteisesti sovitun aikataulun puitteissa suunnittelijan läsnäolosta olisi suuri hyöty ja se parantaisi mm. aliurakoitsijoiden kynnystä lähestyä suunnittelijaa pienemmissäkin asioissa. Hyvänä puolena pidettiin myös sitä, että asioiden selvittäminen nopeutuu ja että suunnittelija voisi samalla ylläpitää ns. ”as built” mallia, jolloin suunnitelmat vastaisivat lähes reaaliaikaisesti asennettua.  

Massalistojen käyttö urakkalaskennan apuna jakaa mielipiteitä. MagiCAD:sta tai mallista tuotetun massalistan juridista pätevyyttä ja sitovuutta kyseenalaistetaan, jonka vuoksi osa vastaajista näkee massalistan käytön enemmänkin suuntaa-antavana ja harkinnanvaraisena. Eräs LVI –ryhmänjohtaja osaa sanoa, että kertyneellä näppituntumalla putkipuolen listat ovat 60% ja IV 90% oikeassa. Putkipuolella ongelmia teettää suunnitteluohjelmiston kyky luokitella komponentteja jolloin listojen ulkopuolelle jää komponenttityypit kuten kaulus. Ohjelma ei myöskään tee eroja T-kappaleiden ja istutusten välillä, eikä erottele laippatyyppejä.

Massalistojen käyttöä pystyy kuitenkin näkemykseni mukaan laajentamaan pelkän komponenttilaskennan ulkopuolelle, vaikka sekin olisi syytä saada kuntoon. MagiCAD Bill of Materials ja Magi Export mahdollistavat hyvin yksilöllisen komponenttijaon luomisen mm. arvokkaammille verkostolaitteille. Saman pystyy tekemään IFC:stä esim. Solibri Model Checkerissä, jossa toiminto on sikäli parempi, että komponentilta löytyessä tarvittavat tiedot Solibri osaa ryhmitellä samat komponentit samalle riville. MagiCAD ei osaa.

Kyselytutkimuksesta heränneitä kommentteja voi laittaa sähköpostitse.

Johanna Lankinen

LVI-Projektipäällikkö

Granlund Oy

johanna.lankinen (at) granlund.fi

--EOF--

Bloginpitäjän huomio kohdistuu teemaan "Suunnittelija työmaalle". Suunnittelijan kohdalla asia tyrmätään ymmärrettävästi siksi, että sitä ei ole tilattu suunnittelusopimuksessa. Urakoitsija kuitenkin haluaisi saada tukea tietomallin tulkinnassa.

Mitä jos tilaaja tilaisi työmaavaiheessa nuoren, SKOL 04-05 luokan suunnittelijan työmaalle vaikkapa yhden päivän ajaksi / viikko?

Kokemuksesta tiedän, että tästä hyötyvät kaikki:

- Urakoitsija saa henkilön, joka osaa kaivaa mallista tietoja

- Urakoitsija saa heti vastauksen muutosehdotuksiin. Järjestelmien toimivuuden ja yhteensovittamisen kokonaiskuva on paremmin hallussa suunnittelijalla kuin urakoitsijalla.

- Tilaaja saa suunnitelman mukaisen asennuksen + as-built tason mallin koska sitä päivitetään yhdessä urakoitsijan kanssa. Ei enää "punakyniä".

- Nuori suunnittelija saa mielettömän mahdollisuuden olla työmaalla ja oppia miten sitä johdetaan. Mitä asentaja ajattelee, mitkä asiat ovat tärkeitä asennuksen kannalta. Seuraava kohde, jonka suunnittelija tekee, on varmasti asennettavuudeltaan parempi.

Tilaajat; miljoonahankkeessa 10.000e ei voi olla paljon.

teroj

Onko rakennuksella Sielu?

Perinteisen vertauksen mukaisesti rakennuksen LVIS-tekniikka vastaa ihmiskehon verisuonia, keuhkoja, hermoja. Rakennusautomaation vastine on löytynyt aivoista, joskin nykytietämyksellä pari valvonta-alakeskusta taitaa löytyä viemäröintijärjestelmästäkin.

Missä on rakennuksen Sielu?

Onko se henkistä höpinää vai muodostuuko se pienten teknisten järjestelmien yhteistoiminnallisuudesta? Uskommeko, että rakennuksella on Sielu – kuolleella, elottomalla betoni- ja rautakasalla?

Onko rakennuksen Sielu sen käyttäjät ja heidän tuottama toiminta? Miten keho (rakennus) suhtautuu käyttäjien tekemiin valintoihin – tatuointeihin iholla, peseytymättömyyteen (grafitteihin, siivoukseen)?

Ilmanvaihtosuodattimien vaihtamattomuus, koneiden väärät käyntiajat, rasvasäiliön tyhjentämättömyys, taajuusmuuttajien manuaalisäädöt?

Jotkut meistä ovat narkkareita, alkoholisteja, tupakoitsijoita. Jotkut hyppivät silloilta (laskuvarjon kanssa ja ilman). Onko heidän VAK sekaisin? Onko heitä huollettu?

Alkaako rakennus reagoida - homehtua, rapistua, vuotaa jos sitä ei hoideta? Jokainen meistä käynee silloin tällöin kävelylenkillä tai hoitaa muuten oman kehon hyvinvointia. Näin saamme raikkaan olotilan ja pystymme jopa psyykkisesti olemaan tyytyväisiä itseemme – onnistuinpa juoksemaan 5km!

Voiko rakennus tehdä itse jotain oman hyvinvointinsa eteen? Tuskin, se on kuin ikuinen lapsi, joka vaatii ulkopuolista hoitoa. Rakennukset eivät pysty itseään korjaamaan, siihen vaaditaan ulkopuolista apua ja reagointia, joko ennakkoon tai jälkikäteen.

Ihmisen ajatukset päättävät, että nyt on tehtävä keholle jotain. Samalla logiikalla kiinteistöjen käyttäjien tulisi reagoida ympärillä rapistuvan rakennuksen ongelmiin. Kertoa siitä eteenpäin, vaatia toimintaa päättävän tahon puolelta.

Jos kiinteistön käyttäjät eivät reagoi, rakennuksen aivojen – rakennusautomaatio yhdistettynä ylläpito-ohjelmistoon – tulee puuttua asiaan. Limbinen järjestelmä ottaa ohjat. Tajuttomuus muuttuu ylläpitomoodiin, pitäen potilaan hengissä kunnes tulee lisäapua.

Asioihin tulee puuttua ennakoivasti, ei jälkikäteen. Rakennuksen olotila tulee pystyä ennustamaan vähintään viikon päähän käyttäen apuna esim. säätilaa sekä tulevaa käyttökuormaa. Rakennuksen pitää tietää, mikä olotila sillä oli vuosi sitten vastaavissa olosuhteissa. Rakennuksen tulee käydä silloin tällöin lääkärissä, jotta pystytään selvittämään missä mennään elinolosuhteiden kanssa. Mitä vanhempi rakennus, sitä tiheämpi lääkärivierailu.

Ihmiset ovat valloittaneet maapallon, koska olemme sopeutuvia. Emme valita ihan joka asiasta. Tai sitten 3% meistä valittaa kaikesta. Tämä on ongelma rakennuksia ylläpitäville organisaatioille. Koska palautetta rakennuksen toimivuudesta tulee kohtalaisen vähän ja se on epätasapainossa laadun suhteen, meillä pitää olla kyky analysoida rakennuksen teknistä toimivuutta sekä käyttäjien fiilistä teknisillä ratkaisuilla. Tässä auttaa sisätilapaikannus, erilaiset automaattiset mittaroinnit (ääni, hiilidioksidi, palkkapäivä, lämpötila, vuodenaika, mieliala, kasvojen ilmeet, liike, valoisuus, sijainti, työntekijöiden kalenterit…), tiedon keräys ja sen perusteella tehtävät analysoinnit. Analysointien lopputulokset ohjaavat kiinteistöä – ei huoltohenkilökunta.

Tästä kerätystä tiedosta rakennuksen tulee oppia käyttäytymään tarpeen mukaisesti. Onko perjantaisin vähemmän henkilöitä rakennuksessa kuin tiistaisin? Missä osassa rakennusta he ovat torstaina? Miten optimoin käyttäytymiseni parhaalla mahdollisella tavalla?

Huoltohenkilökunnan tehtävä on varmistaa, että tekoäly ei tee idioottimaisuuksia, joita se voi hyvinkin tehdä. Emme pysty ylittämään ihmisaivojen kapasiteettiä ymmärtämisessä ja asioiden riippuvuuksien analysoinnissa. Asiansa osaavia huoltomiehiä tarvitaan aina, jotta pystymme muodostamaan inhimillisen kontaktin rakennuksiin ja sen käyttäjiin. Paras huoltomies on rakennuksessa, halvempi löytyy valvontakeskuksesta.

Pääsemme Toimivan Kiinteistön käyttöön, kun osaamme tehdä toimivan kiinteistön. Näitä kiinteistöjä on jo tehty useita. Ne eivät näy lehdissä, ne eivät kohoa tilastoissa. Ne toimivat, kuten ne on suunniteltukin toimivan. Tilaaja on panostanut siihen, että kokonaisuus on kunnossa.

Miten tähän päästään? Ei todellakaan antropologian kautta, vaan tekemällä normaali suunnittelutilaus, asettamalla selvät tavoitteet, valitsemalla suunnittelutiimi, joka ymmärtää tavoitteet ja osaa tehdä yhdessä töitä. Tilauksen tekijän tulee tietää, mitä hän haluaa. Sitä ei voi ammattitaitoinenkaan rakennuttajakonsultti kertoa – pitää olla tunne tekemisestä, jonka tietää oikeaksi.

Tiimi luo yhdessä tilaajan kanssa rakennuksen, joka täyttää tilaajan tavoitteet. Tiimi ymmärtää, että elämän tarkoitus ei ole valaa betoniseiniä, vaan saada niiden sisälle asiakas jota seinä palvelee. Asiakas tarvitsee elinkaariystävällisiä, omiin tarkoituksiinsa toimivia tiloja toiminnoillensa.

Tarvitsemme virtuaalisen kiinteistön, jonka avulla ohjataan todellista kiinteistöä. Haluamme tuottaa toimivia rakennuksia, jossa käyttäjä ja kiinteistö kommunikoivat keskenään.

Tarvitsemme rakennukseen sielun, joka ylläpitää fyysistä - todellista kokonaisuutta.

Kohti ajattelevaa, oppivaa rakennusta.

Viikon kuva:

Innovaatiostrategia 2021

Tiedon keruu - Visualisointi - Analysointi - Raportointi - Ennustaminen - Oppiminen - Ajatteleva kiinteistö -  Fyysisen kiinteistön ohjaaminen. Tekoäly.

Virtuaalinen kiinteistö, missä käyttäjä ja rakennus kommunikoivat keskenään