Mikä on ylläpidon tietomalli?

Tämän hetken yksi suurista asioista, mitä maailmalla puhutaan ja kehitetään, on ylläpidon tietomalli.

Tämä asia ymmärretään yhtä monella tavalla kuin on keskustelijoitakin. Alla oleva näkökulma on minun näkemys siitä, mitä sillä tarkoitetaan.

Lähden liikkeelle siitä, että ylläpidon tietomallista pitäisi varmaan olla jotain hyötyäkin kiinteistön omistajalle. Tai ainakin kiinteistöä ylläpitävälle taholle.

Tämä tarkoittaa sitä, että ylläpidon tietomalli on jotain paljon enemmän, kuin graafinen näkymä tietomalliin. Se on paljon enemmän, kuin tietoja seinistä ja ikkunoista.

Ylläpidon tietomalli on helposti ylläpidettävä tietokanta, josta voidaan saada pitkän tähtäimen suunnitelmia, yhteenvetoraportteja, laitetietoja, huoltolistauksia, ennakoivaa huoltoa jne. On pelkkä nyanssi, että pääseekö tietoihin käsiksi klikkaamalla 3D-mallissa olevaa lattiaa (mikä materiaali, mikä siivousväli jne.) tai muuta objektia.

Tämä ominaisuus on kyllä ihan kiva ja varmaan demoaisin sitä erittäin mielelläni seminaareissa / esityksissä, mutta mitä todellista, konkreettista hyötyä sillä saavutetaan verrattuna esimerkiksi siihen, että klikkaan talon 2D-pohjakuvaa, jossa sama huone sisältää samat tietomallitiedot?

Pääsen 2D-kuvan kautta huomattavasti nopeammin tarkastelemaan asioita huone- tai aluetasolla.

Ylläpito tarvitsee pääsääntöisesti avukseen isojen alueiden kokonaistietoja, jotta voidaan tarkastella kiinteistöä kokonaisuutena. Kokonaisuuksien käsittely onnistuu parhaiten 2D-pohjakuvien kautta, taikka sorttaamalla listasta esim. kaikki kiinteistön käytävät, jolloin tiedän niiden kokonaisneliömäärän -> pystyn kilpailuttamaan siivouksen. (ja saan tietenkin pohjakuvat käytävistä värillisenä jne)

On kuitenkin selvää, että ym. asiat tullaan tulevaisuudessa tekemään mahdolliseksi myös 3D-mallin kautta. Aika näyttää, mitä uutta hienoa sen kautta keksitään, mutta liikkeelle päästään yksinkertaisemminkin. Olisihan se ihan hienoa ajella iv-konehuoneeseen ja klikata puhallinta, jolloin saisin sen tiedot esille. Sekä käyntiajat, energiankulutuksen jne.

Mutta kiinteistön omistajana minua ei niin hirveästi kiinnostaisi se yksittäinen puhallin, vaan kaikkien iv-koneiden kokonaisenergiankulutus ja miten sitä pystyisi pienentämään.

Ym. esimerkissä on jo rutkasti vaikeusastetta. Tuossa tapauksessa ollaan puhaltimeen linkitetty sekä valvontajärjestelmän tietoja että ylläpidon huoltokirjatietoja. On selvää, että ensimmäisinä askeleina tulemme näkemään huoltokirjan linkitykset ja sen jälkeen pitkän ajan kuluttua valvontajärjestelmän tietoja ylläpidon tietomallissa, objektikohtaisesti.

Edellisessä kappaleessa on yksi tärkeä sana. Se sana on "linkitetty". Eli kun mennään 3D tietomallitasolle, niin mikään tärkeä tieto ei ole graafisissa objekteissa itsessään sisällä. Objektit ovat mallissa, jotta niiden avulla voidaan luoda linkki tietokantaan oikeaan komponenttiin tai laitteeseen. Kun jotain muutetaan tai päivitetään, tieto päivitetään tai päivittyy tietokantaan. Ei välttämättä 3D-malliin.

3D-mallia ei kannata aina pienten muutosten takia päivittää. Jos tehdään tilamuutoksia, niin niitä kannattaa kerätä muutamia ja tehdä sitten kerralla graafinen päivitys. Tietokantaa sitä vastoin päivitetään jatkuvasti. Laitteita poistuu, ne muuttuvat, niitä huolletaan jne. Tietokanta päivittyy ja muuttuu, kun normaali nykyaikainen ylläpidon huoltokirjaohjelmisto sitä päivittää.

Miten sitten saadaan ensimmäinen versio ylläpidon tietomallista? Tippuuko se automaattisesti loppudokumenttien muodossa projektipankkiin?

Voin kertoa, että ei tipu.

Prosessimielessä se tarkoittaa sitä, että suunnittelijoiden mallit päivitetään vastaamaan rakennettua todellisuutta (as buildt -mallit). Tässä kohtaa joku sanoo, että ei onnistu. Minä sanon, että onnistuu.

Kikka on siinä, että mitä jos meillä onkin tarjota urakoitsijoille sellaiset suunnittelumallit, että niiden mukaan pystytään kiinteistö rakentamaan? Huima ajatus... että suunnittelija tekisi sellaiset suunnitelmat, että niiden kanssa voitaisiin tehdä työt loppuun. Meillä on siis as buildt -kuvat olemassa jo ennen, kuin yhtään putkea / kanavaa on kattoon laitettu. Tämä on täysin mahdollista, jos suunnittelijoille annetaan mahdollisuus suunnitella kohde kunnolla. Miten se tehdään - on oman blogikirjoituksen aihe.

Kun ollaan tehty tietomalli oikein suunnitteluvaiheessa, jää jäljelle tiedon päivittäminen. Koska urakoitsija on saanut esim. jotkut muut kuin suunnitelmien mukaiset säätöpellit 100e halvemmalla, niin suunnittelija vaihtaa ne omaan malliinsa. Sama juttu muiden tuotteiden kanssa. Päivitetään malli vastaamaan tietosisällöltään todellisuutta. (fiksut tekevät tämän ennen säätötöiden aloittamista, eli tilaavat suunnittelijalta säätökuvat).

Näin ollaan saatu suunnittelijoilta alkutilanteen malli. Sen jälkeen homman ottaa haltuun ylläpidon koordinaattori. Hän tekee normaalit huoltokirjaan liittyvät työt ja hoitaa mallin linkitykset kuntoon. Hänen vastuulla on se kertaluontoinen työ, että ylläpidon tietomalli rakentuu linkittyen tietokantoihin.

Esimerkiksi talotekniikkapuolella on paljon komponentteja ja laitteita, joita ei edes ole mallissa. Laiteluettelot tulee siirtää ylläpidon tietokantaan ja komponentit linkittää vähintään sijaintitiedollaan 3d-malliin.

Harvemmin arkkitehdin mallissa on lattiapintojen materiaalia tai seinäpintojen käsittelyä. Mutta ne löytyvät kyllä erillisestä maalaustyöselostuksesta tai muusta asiakirjasta. Jonkun pitää tehdä se työ, että kaikki tärkeä mitä on haluttu laitettavan ylläpidon tietokantaan, päivittyy sinne.

Näin ollaan päästy tilanteeseen, jossa suunnittelijoiden tietomalli on päivittynyt ylläpidon tietomalliksi ja voidaan alkaa keksiä kaikkia uusia kivoja juttuja, mihin sitä voisi käyttää oikeasti hyödyksi.

Toivottavasti tätä ei lue ketään prosessiteollisuuden / teollisuuslaitosten suunnittelijat... he varmaan nauraisivat, koska heillä ylläpito-organisaatio on heti hankkeen alussa vahvasti mukana suunnittelua ohjaamassa. Eli ensiksi tulee se, miten laite huolletaan / korjataan, sen jälkeen mietitään muut asiat.

Meillä talotekniikkapuolella (ja rakennuttajapuolella) olisi paljon oppimista heiltä.

Viikon vinkki:

- Ensimmäinen askel hyvän tietomallin tekemiselle on asennemuutos.

Viikon kuva:

- esimerkki tietomallipohjaisesta 2D-näkymästä kiinteistöön. Kuvassa näkyy kerroskohtainen tuloilmakoneiden palvelualuekartta