SEN/1269/2016/351054 JULKINEN Tietomallit ylläpidossa Raportti 2016-09-21
2 Tiivistelmä Tässä selvityksessä perehdytään rakennusten tieto- ja yhdistelmämallien (BIM, Building Information Model) rakentamisen jälkeisen ajan hyödyntämismahdollisuuksiin. Selvityksen lähestymistapa on prosessilähtöinen, eli tiedon tarvetta on tarkasteltu muutaman keskeisen prosessin näkökulmasta. Keskeinen havainto on, etteivät nykyiset tietomallien laadintakäytännöt juurikaan tue ylläpidon tarpeita. Ylläpidon tarvitsemaa tietoa, kuten esimerkiksi materiaalien käyttöikiä tai hoitojaksoja, ei normaalisti tallenneta malliin. Rakennussuunnittelijat eivät myöskään välttämättä ole oikea taho laatimaan ylläpidon tehtäviä. Tietomallien tietotekninen rakenne ei ole paras mahdollinen ylläpidon tiedon tallennuspaikaksi. Varsinkin yhdistelmämalli on jo itsessään massiivinen tiedosto ja lisäinformaatio kasvattaa sen kokoa entisestään. Ylläpidon tarvitsema tieto tulisikin tallentaa erilliseen tietokantaan ja linkittää mallin rakennusosiin. Tämä edellyttää yhteisen identifiointikäytännön sopimista. Selvityksestä käy ilmi, että tietomallien käytönaikainen hyödyntäminen edellyttää sekä usean osapuolen yhteistyötä että tietoteknisten ratkaisujen kehittämistä ja toteuttamista. Kuitenkin jo pelkkä tietomalli antaa ylläpidon osapuolille lisäinformaatiota 2D-piirustuksiin verrattuna. Ensimmäinen askel mallien käytönaikaisessa hyödyntämisessä onkin siirtää olemassa olevat tietomallit prosessien ja osapuolten saataville. Kun eri osapuolet pääsevät tarkastelemaan malleja oman toimintansa näkökulmasta, esille voi nousta uusia käyttömahdollisuuksia, joita ei aiemmin ole tunnistettu. Tietomalli voisi muun muassa toimia eräänlaisena Lean-alustana ja auttaa osapuolia kehittämään omaa toimintaansa. Käytönaikaisen suorituskyvyn mittaamiseen tarvittavalle tekniikalle (anturit ja mittarit) kaivataan myös käyttöliittymiä tietomalleihin. Nämä käyttöliittymät tulisi integroida konsernitason energian- ja olosuhteiden seurantajärjestelmiin. Selvityksen johtopäätökset-osassa on kuvattu kehitysaskeleet, joita tietomallien käyttöönotto ylläpidossa vähintään edellyttää. Selvitystyössä ovat auttaneet ja sisältöä kommentoineet seuraavien yritysten edustajat: Granlund Oy Gravicon Oy ISS Palvelut Oy Ramboll Finland Oy VTT Oy Dokumentin laatimistyötä ovat tukeneet myös kollegat Senaatti-kiinteistöjen rakennuttamissekä toimitila- ja ylläpitoyksiköistä.
3 Sisällysluettelo Tiivistelmä... 2 Sisällysluettelo... 3 Lyhenteet... 4 1 Johdanto... 6 1.1 Selvityksen tausta... 6 1.2 Tavoitteet ja rajaus... 7 2 Tietomallinnus Senaatti-kiinteistöissä... 8 2.1 Taustaa... 8 2.2 Mallintamisen tavoitteet... 8 3 Tietomallien käyttäminen... 10 3.1 Yleistä... 10 3.2 Tietomallinnusta koskevat määräykset ja ohjeet... 14 3.3 Tietomallinnuksen haasteita ylläpidon näkökulmasta... 14 3.4 Riskit... 15 3.5 Yhdistelmämalli... 16 4 Ylläpidon tiedontarve... 18 5 Ylläpitomalli... 19 5.1 Yleistä... 19 5.2 Ylläpitomallin tietosisältö... 19 5.3 Ylläpitomallin käyttö... 20 6 Olosuhdemalli... 22 6.1 Yleistä... 22 6.2 Olosuhdemallin tietosisältö... 22 6.3 Olosuhdemallin käyttö... 24 6 Tietomallien mahdollisuudet... 25 6.1 Kiinteistöliiketoiminta... 26 6.2 Energiatehokkuuden ja sisäolosuhteiden hallinta... 27 6.3 Kunnossapito... 28 6.4 Kiinteistönhoidon tarjouslaskenta... 30 6.5 Huoltokirjan käyttö... 31 6.6 Toimitilapalveluiden tuottaminen... 32 6.7 Kiinteistön käyttö... 33 7 Johtopäätökset... 34 7.1 Yhteenveto... 34 7.2 Kehitysaskeleet... 38 KIRJALLISUUTTA... 39
4 Lyhenteet AR IFC IFC-malli Keskusosa Komponentti Määräluettelo Natiivimalli, alkuperäismalli Olio Pääteosa Siirto-osa Statustieto Talotekninen järjestelmä Lisätty todellisuus eli Augmented reality (AR) yhdistää digitaalisen tiedon käyttäjän todelliseen ympäristöön. Toisin kuin virtuaalitodellisuus, lisätty todellisuus kerrostaa uutta tietoa olemassa olevan ympäristön päälle (esim. älylasit). IFC-tiedosto on kansainvälisen International Alliance for Interoperabilityn kehittämä avoin ISO-standardisoitu XMLpohjainen tiedonsiirtomuoto. IFC on standardi oliopohjaisen tiedon siirtoon tietokonejärjestelmästä toiseen. Uusin IFCstandardi versio 4 (aikaisemmin nimeltään 2x4) julkaistiin 2013, mutta useimmat mallinnusohjelmat tukevat vielä IFC 2x3 -versiota. 3-ulotteinen malli, joka sisältää suunnitteluorganisaation kanssa yhteisesti sovitun geometrian ja tietosisällön käyttötarkoitukseen ja suunnitteluvaiheeseen sopivana. Esim. LVI2010-nimikkeistön mukaisesti LVI-toiminnon tuottava LVI-järjestelmän osa, esimerkiksi jakokeskukset jne. Laite, esim. palopelti, päätelaite, suodatin, puhallin, sähkö-tai telepiste jne. Luettelo, jossa on esitetty samantyyppisten taloteknisten järjestelmien osat niin, että niiden määrät on laskettu yhteen. Sovellusohjelmiston sisäinen tiedostojen tallennusmuoto, joka on avattavissa luotettavasti vain alkuperäisellä sovellusohjelmistolla. Tietotekniikassa jonkin asian yleinen käsite. Oliolla voi olla erilaisia ilmentymiä, joilla on samat ominaisuudet, mutta eri arvot. Olio sisältää erilaisia ominaisuuksia (attribuutteja), jotka ohjelmoinnissa tallennetaan muuttujiin, sekä metodeita, joilla käsitellään olion sisältämiä tietoja, eli muuttujien arvoja. Esim. LVI2010-nimikkeistön mukaiset järjestelmäosat, valaisimet jne. Esim. LVI2010-nimikkeistön mukaiset järjestelmäosat, kaapelireitit jne. Komponenteille annettu lisämääre, huomautus tms. joka siirtyy myös IFC-malleihin Kokonaisuus, joka kuvaa yhden toiminnallisen tai staattisen järjestelmän keskusosan, siirto-osan ja pääteosat. Esimerkiksi
5 yksi ilmanvaihtokone kanavistoineen, komponentteineen ja päätelaitteineen on talotekninen järjestelmä. Tietomalli Tilaaja Rakennuksen ominaisuuksien aineellinen ja toiminnallinen kuvaus digitaalisessa muodossa, mikä mahdollistaa tiedon jakamisen yhteisesti sovitulla tavalla. Osapuoli, jonka vastuulla on tarjouspyyntöaineiston tilaaminen suunnittelijalta ja sen lähettäminen urakoitsijalle urakkalaskentaan Yhdistelmämalli Malli, jossa on yhdistettynä useiden suunnittelualojen 3Dtietomalleja samassa koordinaatistossa YTV 2012 Yleiset Tietomallivaatimukset 2012 GUID 2D-piirustus Globally Unique Identifier, objektin yksilöllinen tunnus tietomallissa Perinteisin menetelmin piirretty kuvaus rakennettavasta kohteesta. Työkaluna cad-järjestelmä, paperi, transparentti tms.
6 1 Johdanto 1.1 Selvityksen tausta Rakennuksen tietomalli (engl. Building Information Model, BIM) on rakennuksen ja rakennusprosessin koko elinkaaren aikaisten tietojen kokonaisuus digitaalisessa muodossa. Tietomalliin liittyy myös rakennuksen geometrian määrittäminen ja esittäminen kolmiulotteisesti havainnollisuuden ja erilaisten simulointitarpeiden vuoksi. Tietomalliajattelu on peräisin valmistavasta teollisuudesta, jossa se on tuotetiedon nimellä yleisesti käytössä oleva metodi tuotteiden suunnittelussa ja valmistuksessa. Tietomallien laatiminen on jo arkipäiväistä isommissa hankkeissa. Pieniä hankkeita kuten tilojen saneerauksia tai muutoksia tehdään edelleen 2D-suunnitteluna silloin, kun kohteesta ei ennestään ole olemassa 3D-mallia. Malleja käytetään jo yleisesti hyväksi myös rakentamisen aikana mm. talotekniikan asennusreittien ja risteilyjen tarkastamisessa ja yhteensovittamisessa. Tietomallien hyödyntäminen rakennuksen ylläpidossa ottaa käytännössä vasta ensimmäisiä askeleitaan. Hyödyntämismahdollisuuksia on etsitty pääasiassa kehityshankkeiden ja pilottien kautta. Yleisissä tietomallivaatimuksissa YTV 2012 on esitetty ohjeita ja sisältövaatimuksia ylläpidon malleille, mutta käytännössä malleja ei ole ainakaan kaupallisessa mielessä hyödynnetty. Tällä hetkellä alalla ei ole yhteistä näkemystä siitä, mikä on oikea tapa hyödyntää tietomalleja rakennusten ylläpidon aikana. Mallista voidaan esimerkiksi tehdä kolmiulotteisia näkymiä kiinteistönhoidon ja kiinteistön vuokralaisten käyttöön. Näkymässä voidaan esittää muun muassa olosuhteiden ja palvelupyyntöjen hetkellistä tilannetta. Tätä ratkaisua kutsutaan olosuhdemalliksi. Toinen vaihtoehto on tehdä mallista ylläpitomalli, jossa huoltoluukut, venttiilit ym. toimilaitteet, huoltoa vaativat kohteet ja mittausdataa tuottavat sensorit sijaitsevat kolmiulotteisessa tila-avaruudessa. Mallien sisältöä ja hyödyntämismahdollisuuksia on käsitelty tarkemmin luvuissa 5. ja 6. Tietomalliperustaisesta suunnittelusta puhuttaessa on oleellista ymmärtää, että suunnittelu tuottaa paljon muutakin kuin pelkkiä piirustuksia. Tietomallikehityksen keskeinen tavoite on, että samassa paikassa olevaa digitaalista tietoa tulee hyödyntää paljon muuhunkin kuin pelkkien piirustusten tuottamiseen.
7 1.2 Tavoitteet ja rajaus Tämän raportin tarkoitus on toimia käytännön päänavaajana tietomallien hyödyntämiselle rakennusten ylläpidossa. Tavoitteena on kuvata käytännöt, joilla mahdollistetaan ylläpidon tarvitseman tiedon tallentaminen tietomalliin, sekä tunnistaa uusia tietomallien hyödyntämistapoja. Seuraavassa on kuvattu kolme näkökulmaa, joista tietomallien hyödyntämistapoja voidaan tarkastella, sekä niihin liittyvät keskeiset kysymykset. 1. Asiakasnäkökulma - Saavutetaanko tietomallien käytöllä ja kehittämisellä kilpailuetuja? - Voidaanko tietomallien käytöllä profiloitua ja erottua kilpailijoista? - Saavuttavatko asiakas ja loppukäyttäjä konkreettisia etuja tietomallien käytöllä? 2. Talousnäkökulma - Saavuttavatko eri osapuolet parempaa tuottavuutta ja tehokkuutta tietomallien käytön kautta? 3. Henkilöstönäkökulma - Tuottaako tietomallin käyttö lisäarvoa eri osapuolten henkilöstölle?
8 2 Tietomallinnus Senaatti-kiinteistöissä 2.1 Taustaa Senaatti-kiinteistöt on rakennusten tietomallinnuksen uranuurtaja Suomessa. Malleja on laadittu vuodesta 2000 alkaen. Tavoitteena on ollut kiinteistö- ja rakennusalan tuottavuuden, tehokkuuden sekä lopputuotteen ja toiminnan laadun parantaminen. Senaatti-kiinteistöt on myös tehnyt tiivistä yhteistyötä pohjoismaisten sisarorganisaatioiden sekä suunnittelijoiden ja rakennusteollisuuden edustajien kanssa. Vuonna 2007 Senaatti-kiinteistöt julkaisi omat tietomallivaatimuksensa ja alkoi edellyttää tietomallintamista kaikissa yli miljoonan euron rakennushankkeissa. Vaatimus pohjautui rakennusteollisuuden toivomukseen. Useat alan toimijat olivat pyytäneet tilaajia aktivoitumaan tietomallintamisessa, koska he - samoin kuin osa suunnittelijoista - olivat todenneet voivansa tehostaa omaa toimintaansa tietomallintamisen avulla. Aluksi mallinnusvaatimus koski ainoastaan arkkitehtisuunnitelmia. Mallinnusvelvoite ulotettiin kaikille suunnittelualoille vuodesta 2009 alkaen. Kun tietomallivaatimusten päivittäminen vuonna 2010 tuli ajankohtaiseksi, ei Senaattikiinteistöt enää halunnut yksin toimia hankkeen veturina. Tietomallivaatimusten kehittämisen ympärille käynnistettiin kehityshanke, johon liittyi laaja joukko kiinteistö- ja rakennusalan toimijoita. BuildingSMART Finland (bsf) sai tehtäväkseen koordinoida yhteisten BIMvaatimusten laadintaa. Työn tuloksena julkaistiin vuonna 2012 päivitetyt tietomallivaatimukset YTV 2012. 2.2 Mallintamisen tavoitteet Tietomallinnus tarkoittaa tietokonepohjaista rakennuksen suunnittelua, jossa rakennuksesta luonaan n-ulotteinen (n x D) malli simulointia, suunnittelua, rakentamista ja käyttöä varten. Se auttaa suunnittelijoita ja rakentajia visualisoimaan rakentamisen kohdetta simuloidussa ympäristössä, sekä tunnistamaan mahdolliset suunnitteluun, rakentamiseen tai toimintaan liittyvät ongelmat. Tietomalli mahdollistaa koko elinkaaren aikaisen tiedonhallinnan, tukee kestävää kehitystä sekä elinkaari- ja ympäristörakentamista. Mallintamisella tuetaan sekä kiinteistöliiketoimintaa että investointiprosessin tehokkaampaa ohjausta. Yleisellä tasolla mallinnus tuottaa mm. tarkempaa tietoa investointipäätöksen tueksi, joustavaa ja avointa tiedonjakoa kaikkien osapuolten kesken, parempaa laatua virtuaalisten analysointityökalujen avulla, taloudellisuutta ja tehokkuutta rakennuksen käyttöön ja ylläpitoon sekä kiinteistön koko elinkaaren kestävää tiedonhallintaa.
9 Rakennushankkeen kriittisin hetki on päätöksenteko hankkeeseen ryhtymisestä. Tietomallintamisen mahdollistama tarkka ja luotettava tieto jo hankesuunnitteluvaiheessa vähentää epäonnistumisen riskiä huomattavasti esimerkiksi vaihtoehtojen helpon vertailtavuuden avulla. Tavoitteet voidaan asettaa ja niitä voidaan seurata tarkemmin, mikä helpottaa ja parantaa hankkeen ohjattavuutta. Mallintamisen mahdollistama visualisointi lisää asiakkaan ja myös tilaajan ymmärrystä siitä, millaista ratkaisua hänelle ollaan tarjoamassa. Tietomalli tuottaa tarkkaa määrätietoa, joka mahdollistaa tarkan tarjouslaskennan ja budjetoinnin. Myös elinkaarianalyysit voidaan tehdä varhaisessa vaiheessa. Integroitu tietomalliteknologia tekee mahdolliseksi joustavan ja avoimen tiedon jakamisen kaikkien osapuolten kesken. Yhteisen standardin (esimerkiksi IFC) käyttö mahdollistaa suunnitelmien yhdistämisen ja vertailun, joka vähentää suunnitteluvirheitä ja sitä kautta helpottaa työmaan toimintaa. Jatkuvan tiedonsiirron avulla muutosten hallinta on helpompaa ja turhan työn tekeminen vähenee. Virtuaaliset analysointityökalut tuottavat parempaa laatua, sillä ne paljastavat mahdolliset ongelmat jo varhaisessa vaiheessa. Korjaukset voidaan tehdä suunnittelupöydällä, eikä niitä tarvitse selvittää työmaalla. Mallipohjaiset analysointityökalut (energia-, olosuhde-, valaistus-, virtaus-, elinkaari- ja ympäristövaikutussimuloinnit) mahdollistavat erilaisten vaihtoehtojen nopean vertailemisen. Yksi mallintamisen päätavoitteista on tuottaa käyttöä ja ylläpitoa varten taloudellinen ja tehokas rakennus. Tätä varten rakennukseen tulee suunnitella kattava anturointi, jonka avulla kerätään tarkat olosuhdetiedot simulointia ja suunnittelun ja toteutuksen keskinäistä vertailua varten. Malli parantaa tilakustannusten hallintaa ja raportointia ja lisää omistajan ja vuokralaisen saaman tiedon avoimuutta ja käytettävyyttä.
10 3 Tietomallien käyttäminen 3.1 Yleistä Tavallisesti BIM-mallilla tarkoitetaan rakennuksen kolmiulotteista mallia (3D). Käytössä on myös 4D-malleja, joilla tarkoitetaan rakentamisajan simulointia 3D-mallissa, sekä myös rahoituksen sisältäviä 5D-malleja. Rakennuksen tietomallin sisältämästä datasta voidaan tuottaa lukemattomia erilaisia näkymiä ilman erillistä suunnittelua. Käytännössä BIM on joukko ohjelmistoja, jotka yhdessä kykenevät muodostamaan ihmisen kulloinkin tarvitseman kolmiulotteisen näkymän. Tietomallinnus auttaa suunnittelijoita saavuttamaan asetetut tavoitteet. Tietomalli ei ole kuitenkaan ole itse päämäärä, vaan ainoastaan työkalu, joka helpottaa tavoiteltuun suunnitteluratkaisuun pääsemistä. Mallintamisprosessi myös tekee suunnitteluprosessista läpinäkyvän. Mallipohjaisen suunnittelun alkuvaiheessa voidaan yhdellä silmäyksellä todeta, mitä on tehty ja mitä on vielä tekemättä. Tarkempaa suunnittelua jatketaan yleensä samassa mallissa, jolloin eri rakenteiden valmiusasteen toteaminen vaikeutuu. Tilannetta voisi parantaa määrittelemällä yhteisesti, kuinka yksittäisen objektin (olion) tai niiden muodostaman loogisen kokonaisuuden (esim. betonielementti) valmius ja versio esitetään. Tietomallia käyttävät ohjelmat ovat oliopohjaisia. Oliot ovat valmiiksi määriteltyjä tietopaketteja, joita käsitellään kokonaisuuksina. Oliot sisältävät käytetyn rakennusosan, kuten pilarin, oven, ikkunan tai seinän, tiedot määrätyssä formaatissa. Olioon voidaan myös määrittää käyttäytymistä. Olion sisältämä tieto käsittää useita eri näkökulmia, kuten visuaalisuus, mitat, materiaaliominaisuudet, lämpötekniset ominaisuudet ja niin edelleen. Kun olio liitetään malliin, sen sisältämä tuotetieto integroituu mallitiedostoon. Käytännön suunnittelutyössä yksittäisten materiaalien ominaisuusvaatimukset (esim. RYL tms.) kirjataan ensisijaisesti eri selostuksiin. Mallin tietosisältö voi siltä osin olla puutteellinen tai sekalainen. Ensisijaisesti malliin syötetään tai haetaan tuotekirjastoista ominaisuustietoja, joita hyödynnetään esim. visualisoinnissa tai muissa erityistarkoituksessa. Tietomallin sisältämää tietoa voidaan hyödyntää esimerkiksi lujuuslaskennassa ja tehdasvalmisteisten osien tuotannossa. Laskentaohjelma saa tuotemallista rakennusosan mitat, materiaalin ja muut tarvittavat ominaisuudet, joiden avulla se voi laskea voimasuureet rakennusrunkoon. Samaten esimerkiksi teräsrungon palkin suunnittelutiedot voidaan syöttää suoraan mallista tuotteen valmistuksesta huolehtivalle koneelle. Valmistajien BIM-objektikirjastojen käyttö on osin ongelmallista, sillä ne periaatteessa sitovat urakoitsijan käyttämään suunnittelijan valitsemaa toimittajaa. Jos tuote kuitenkin vaihdetaan, saattaa uuden objektin päivittäminen malliin olla työlästä. Toinen vaihtoehto on yrittää
11 päivittää uudet tiedot aiemmalle objektille. Kummassakin tapauksessa suunnittelussa syntyy vain as-designed, ei as-built -malli. Erityisesti taloteknisessä suunnittelussa käytetään usein valmiiden olioiden lisäksi ohjelmistojen normaaleilla piirto-ominaisuuksilla piirrettyjä objekteja. Niihin on tyypillisesti vaikeaa lisätä pitkälle menevää älykkyyttä. Lisäksi tiedostojen suuri koko vaikeuttaa niiden hallintaa. Piirretyillä objekteilla on käytännössä mahdotonta suunnitella suuria tietomallikokonaisuuksia. Kehittyneempiä piirrosobjekteja on mahdollista luoda ohjelmoimalla. Ohjelmoidut objektit ovat tiedostokooltaan pienempiä ja niiden hallitseminen suurissa malleissa on helpompaa. Ohjelmointi mahdollistaa myös huomattavasti monimutkaisempien ja suunnittelun kannalta älykkäämpien ominaisuuksien lisäämisen. Ohjelmoinnilla tapahtuva objektien laatiminen vaatii kuitenkin osaamista, jota talotekniikkasuunnittelijoilla ei tavallisesti ole. Kuva 1. Mallintamisen vaiheet Kuva 1. esittää rakennuksen tietomallinnuksen perinteistä vaiheistusta. Vaiheiden sisällöt lyhyesti: Tilamalli: Ehdotussuunnittelua varten luotu malli, johon on määritelty yksittäiset rakennuksen tilat. Tilamallin avulla voidaan mm. analysoida rakennuksen elinkaarikustannuksia ja ympäristövaikutuksia. Alustava rakennusosamalli: Luonnossuunnitteluvaiheen malli, jossa on alustavasti määritelty tiloja rajaavat rakennusosat ilman niiden tarkempaa tuoterakennetta. Rakennusosamalli: Toteutussuunnitteluvaiheen malli, jossa on määritelty rakennusosat yleisesti, ilman lopullisia tuotemäärityksiä.
12 Tuoteosamalli: Toteutussuunnitteluvaiheen täydennetty rakennusosamalli, jossa rakennusosia vastaavat valitut rakennustuotteet. Toteumamalli: Rakennuksen lopullinen, toteutunut malli, jonka tarkoitus on saada ajantasainen tieto rakennuksen ylläpitoon. Ylläpitomalli: Malli joka sisältää käytön ja ylläpidon aikaiset tehtävät, muutokset, peruskorjauksen tiedot jne. Käytännössä tietomallinnus on toistaiseksi liittynyt varsin tiiviisti suunnitteluvaiheessa syntyvään tietoon ja sen käyttöön. Tietomallin hyödyntämiseen ja päivitykseen rakennuksen käytön aikana ei ole olemassa yhteisesti sovittua toimintamallia. Vaikka yleisiä tehtävä- ja prosessikuvauksia on tehty, ovat rakennushankkeen eri toimijoiden rajapinnat ja toimintatavat vakiintumattomia. Mallinnettaessa työpanos jakaantuu toisin kuin perinteisessä suunnitteluprosessissa. Pääpaino siirtyy piirto-, tulostus- ja tiedonsiirtorutiineista merkittävimpiin suunnittelutehtäviin ja sisällön tuottamiseen. Rakennus mallinnetaankin yleensä ensin kokonaisvaltaisesti ja 2D-piirustukset tuotetaan malleista. Käytännössä 2D-muotoisia toteutuspiirustuksia joudutaan kuitenkin tuottamaan vaiheittain hankkeen aikataulun mukaan, jolloin tarkentava mallipohjainen suunnittelu etenee myös vaiheittain. Tämän onnistuminen edellyttää, että olio- ja objektitason valmiusaste- ja versiohallinnasta on sovittu, jotta osapuolet tietävät mikä versio on missäkin vaiheessa kurantti. Kuva 2. Tiedon kumuloituminen rakennuksen elinkaaren läpi
13 Kuva 2. esittää tietomäärän kertymistä rakennuksen elinkaaren aikana. Ylläpito, joka on ajallisesti pisin jakso, kerryttää tietomäärää eniten. Toisaalta ylläpito myös tarvitsee kaikissa edellisissä vaiheissa tuotettua tietoa. Kuva 3. Tiedon muodostuminen rakennushankkeen aikana (RT 10-10992, 2) Rakennushankkeen tulee tuottaa suunnittelualakohtaiset tietomallit, jotka voidaan siirtää sellaisenaan ylläpito-organisaation käyttöön. Luovutusvaiheessa ei pitäisi olla tarvetta lisätä rakentamiseen liittyvää informaatiota, vaan rakentamisen aikaiset muutossuunnitelmat tulisi tuottaa mallintamalla ennen kyseisen muutoksen tekemistä. Tällä varmistetaan, että mallit ovat aina ajan tasalla. Menettely vaatii suunnitteluorganisaatiolta mallinnusprosessin hyvää hallinta
14 ja sen integroimista rakentamiseen, jottei muutostöiden suunnittelu vaikuttaisi hankkeen läpivientiin. 3.2 Tietomallinnusta koskevat määräykset ja ohjeet Tärkeimmät tietomallintamisen laadintaa ohjaavat asiakirjat ovat hankkeen ohjelma-asiakirjat liitteineen, Senaatti-kiinteistöjen CAD-ohje, suunnittelun tehtäväluettelot (TELU) ja YTV 2012. Luovutettavien mallien sisältöä ja luovutusjärjestelyjä on kuvattu CAD-ohjeessa ja Asiakirjojen luovutusohjeessa. Senaatti-kiinteistöjen hankekohtaiset tietomallivaatimukset on kuvattu taulukoina, joita suositellaan käytettäväksi kaikissa mallinnettavissa hankkeissa. Ensisijaisesti YTV2012 vaatimuksissa määritellään, mitä rakenteita mallinnetaan, sekä edelliseen liittyviä tarkentavia asioita. Niissä ei juurikaan määritellä rakenteille annettavaa tietosisältöä. Tarkentavissa taulukoissa esitetyt vaatimukset koskevat lähinnä tyyppinimikkeitä, Talo 2000 -tunnusta sekä mitta- ja määrätietoja. Vain joidenkin määrättyjen rakenteiden kohdalla (esim. oven tai ikkunan), on esitetty vaatimuksia ominaisuuksien määrittelystä. Jos ominaisuustietoja kuitenkin vaaditaan, tulee samalla sopia, mihin tietokenttiin ne eri ohjelmissa ja IFC-export tiedostoissa kirjoitetaan, jotta tietotyypit olisivat koneluettavissa. BuildingSMART Finland (bsf) on julkaissut sarjan tietomallien tietosisältövaatimuksia syksyllä 2015. Senaatti-kiinteistöt ei ole toistaiseksi tehnyt päätöstä niiden käyttöönotosta. 3.3 Tietomallinnuksen haasteita ylläpidon näkökulmasta Vaikka tietomallien käyttö rakentamisen aikana on lisääntynyt, ovat ne muutamia harvoja poikkeuksia lukuun ottamatta melko vieraita kiinteistöjen ylläpito-organisaatioille. Tietomallien tuomia hyötyjä ei tunneta, eikä tilaaja edellytä palveluntuottajalta tietomallin käyttämistä. Sähköisten järjestelmien käyttäminen on arkipäivää kiinteistönhoito-organisaatioille. Uusien tietoteknisten järjestelmien tuominen kiinteistönhoidon arkeen saattaa kuitenkin aiheuttaa muutosvastarintaa, ellei niistä saatavia hyötyjä pystytä konkreettisesti osoittamaan. Uuden tietojärjestelmän tulisi helpottaa henkilön työtä esimerkiksi nopeuttamalla tiedon löytymistä ja vähentämällä vianhakuun käytettävää aikaa. Tietomallien hyöty ilman ylläpidon tietomallikäyttöliittymää jää kuitenkin vähäiseksi, koska kiinteistönhuolto ei päivittäin tarvitse detaljitason rakennusosatietoja. Tavallisimpia esteitä mallien käytölle ylläpidossa ovat: - Tietokoneiden kapasiteetti rajoittaa BIM-ohjelmistojen käyttöä (erityisesti yhteiskäyttöä) - Jotkut ohjelmistojen toiminnoista ovat kömpelöitä ja niiden käyttö vie runsaasti aikaa - Tietomalli on laadittu puutteellisesti - Mallin oikeellisuuteen ei luoteta - Katseluohjelmat eivät ole yhteensopivia
15 - Rakentamisen aikaisia muutoksia ei ole päivitetty - Mallissa ei ole ylläpidon tarvitsemia tietoja - Mallia ei ylläpidetä käytön aikana - Malliin ei tallenneta käytön aikana kertyvää kokemusta (nk. hiljaista tietoa) - Rajapintoja visualisointiohjelmiin tai huollon sovelluksiin ei ole - Rajapintoja mittaus- tai rakennusautomaatiojärjestelmiin ei ole - Muutosvastarinta - Ylläpidosta ei tietoisesti haluta tehdä täysin läpinäkyvää - Tietojen siirto muihin järjestelmiin vaatii runsaasti manuaalista työtä 3.4 Riskit Tärkein tietomallien sisältämän tiedon hyödyntämiseen liittyvä riski liittyy tekijänoikeuksiin. Aina ei ole selvää, kenellä on omistusoikeus tietomallin tietoihin. Esimerkiksi rakennuksen omistaja voi olettaa omistavansa mallin, koska hän maksaa suunnittelun. Suunnittelutiimin jäsenet ovat kuitenkin voineet käyttää mallin luomisessa omaa tuotekehitystään ja suojattuja lisenssejä. Ongelmien välttämiseksi tulisi aina laatia erillinen tietomallin käyttösopimus. Sopimuksen tavoitteena on välttää rajoitteita tai ongelmia, jotka voivat estää mallin täysimääräisen hyödyntämisen esimerkiksi ylläpidon eri osapuolten toimesta. Edellä kuvattu ongelma voi syntyä esimerkiksi käytettäessä laitteiden tai materiaalien myyjien omia tuoteosamalleja. Valmiit tuoteosamallit helpottavat suunnittelijoiden työtä merkittävästi, sillä ne ovat tarkkoja mitoiltaan ja toiminta-arvoiltaan ja sisältävät runsaasti tuotetietoa. Käytännössä ongelmia voi syntyä, jos laitetoimittajan tuoteosamalli on lisensoitu kyseiselle yritykselle, eikä sen sisältämän tiedon hyödyntämisestä ylläpidossa ole erikseen sovittu. Rakennusalalta puuttuu asiaa koskeva lainsäädäntö. Vaatimus tietojen avoimuudesta koskee myös rakennusautomaatiojärjestelmän tuottamien tietojen saatavuutta. Esimerkiksi autoissa on säädöspohjaisesti määritelty, mitä tietoa pitää olla luettavissa katsastusta varten. Toisaalta valmistajan pitää tarjota vastaavat huollon ohjelmat korvausta vastaan muillekin kuin merkkihuolloille. Toinen merkittävä riski liittyy vastuuseen BIM-datan päivityksestä sekä sen täsmällisyydestä ja oikeellisuudesta. Huomaamatta jääneet suunnitteluvirheet saattavat aiheuttaa merkittäviä kustannuksia erityisesti rakentamisen aikana. Tästä syystä, ennen kuin tietomallia aletaan hyödyntää, on sovittava osapuolten kesken virhevastuista ja vastuunrajoituksista. Selvitysvaiheen laiminlyönti voi johtaa monimutkaisiin korvausvaatimuksiin ja hankaliin työmaa-aikaisiin selvityksiin. Tietomallin tarkastukselle on varattava riittävästi sekä aikaa että rahaa.
16 Kolmannen riskin muodostavat ohjelmistojen väliset teknologiset rajapinnat ja niiden mahdolliset virhetoiminnot. Esimerkiksi kehittyneissä rakennusyrityksissä hankkeen kustannukset ja aikataulu kerrostetaan 3D-malliin. Pääurakoitsijan ja aliurakoitsijoiden käyttämät ohjelmistot saattavat kuitenkin olla keskenään erilaisia, jolloin pääurakoitsija joutuu joko ylläpitämään kokonaisaikataulua manuaalisesti tai hankkimaan yhteensopivan ohjelmiston. Tämä voi olla BIM-moduuli tai muu sovellus, joka integroidaan 3D-malliin. Tällä hetkellä suurin osa projektinhallintatyökaluista on kuitenkin kehitetty erillään BIM-malleista. Sama koskee myös ylläpidon ohjelmistoja. Tietotekninen virhe voi aiheuttaa esimerkiksi jonkin valmiselementin tilauksen myöhästymisen, jos sen tiedot eivät siirry oikein mallin ja aikatauluohjelmiston välillä. 3.5 Yhdistelmämalli Yhdistelmämalli muodostetaan yhdistämällä eri suunnittelualojen tietomallit. Yhdistelmämalli on tekninen malli, jonka tarkoituksena on varmistaa eri tekniikkalajien ja eri hankeosien suunnitelmien yhteensopivuus. Yhdistelmämallista voidaan myös tuottaa muun muassa esittelymalli tilojen tulevia käyttäjiä varten. Yhdistelmämalli luodaan jonkin yhteisesti sovitun avoimen tiedonsiirtoformaatin avulla. Yleisesti käytössä olevia avoimen tiedonsiirron standardeja ovat mm. tietomallinnuksen perusvaatimuksena oleva IFC (Industry Foundation Classes) sekä uudempi, USA:ssa ja eräissä muissa maissa käytetty COBie. COBie (Construction Operations Building Information Exchange) ei sellaisenaan sovellu kokonaisen mallin tietolähteeksi. Kyseessä on tietomuoto, joka on alun perin kehitetty muiden kuin geometristen mallinnustietojen keräämiseen ja julkaisemiseen tietomallista. COBie helpottaa lähtötietojen, kuten laiteluetteloiden, tuoteselosteiden, takuuasioiden, varaosaluetteloiden sekä ennakoivan huollon aikataulujen keräämisessä ja tallentamisessa. Harvemmin käytetty BCF (Building Collaboration Format) on suomalaisten buildingsmart jäsenten, Teklan ja Solibrin, yhteistyönä kehittämä tiedonsiirtomuoto. BCF-viesti sisältää mallikomponenttien sijainti- ja objektitiedot, joiden perusteella vastaanottava ohjelma löytää lähettäjän valitseman näkymän ja korostaa halutut komponentit. Menetelmässä siirretään ainoastaan pienikokoinen XML-pohjainen tiedosto, eikä havaintojen tai malliin liittyvien kysymysten esittäminen edellytä koko IFC -mallin lähettämistä. BCF-valmius on rakennettu jo useisiin ohjelmistoihin kuten Tekla Structures, Solibri Model Checker, CADS Planner ja DDS Architecture. BCF:n ensimmäinen käyttöalue on ollut suunnittelijoiden tai muiden hankeosapuolten välisten viestien välittäminen, jotka sisältävät tarkan referenssiviittauksen mallin tiettyyn kohtaan. BCF:n avulla voisi toteuttaa esimerkiksi yksikertaisen konekortin ja mallin linkityksen BCF-
17 yhteensopivan katseluohjelman avulla. Tulevaisuudessa BFC:stä muodostunee ainakin pilvipalvelupohjaisia asianhallintaratkaisuja projektiyhteisön käyttöön. Missään nykyisin käytössä olevassa IFC export -formaatissa kaikki suunnittelualojen malleissa oleva älykkyys (tieto) ei siirry IFC-malliin, joten ne eivät täysin korvaa alkuperäismalleja. IFCtiedonsiirrossa malleista muun muassa katoaa usein parametrisyys, jota tarvitaan rakennusosien muokkaamisessa ja mm. esitystapojen hallinnassa. Kuva 4. Yhdistelmämalli suunnittelun ja tuotannon apuvälineenä Tietomallia voidaan periaatteessa käyttää sellaisenaan sähköisten kiinteistönhallintajärjestelmien rinnalla kiinteistön ylläpidossa. Mallin hyödyntämistä vaikeuttavat hankalien käyttöliittymien lisäksi tiedon sijainnin määrittäminen ja paikkansapitävyyden varmistaminen. Optimaalisessa tilanteessa malli olisi integroitu muihin järjestelmiin siten, että ne käyttäisivät suoraan mallissa olevaa tietoa ilman erillistä käyttöliittymää. Jotta mallissa olevaa tietoa olisi mahdollista hyödyntää, tulisi jokaiselle malliin lisättävälle objektille antaa yksilöivä tunnus. Tunnus voidaan muodostaa esimerkiksi GUIDmenetelmän mukaisesti.
18 4 Ylläpidon tiedontarve Kiinteistöjohtamisen tiedontarve vaihtelee rooleittain. Strateginen johtaminen tarvitsee erityypistä tietoa kuin taktinen johtaminen tai operatiivinen toiminta. Tässä selvityksessä keskitytään pääasiassa operatiivisen toiminnan eli ylläpidon tarvitseman tiedon hankkimiseen ja tuottamiseen rakennuksen tietomallin avulla. Ylläpidon keskeiset prosessit ovat: a) kiinteistön ylläpito, b) kiinteistönhoito, c) teknisten järjestelmien hoito, d) kiinteistönhuolto, e) energiankäytön hallinta sekä f) kiinteistönhoidon valvonta. Mainitut prosessit muodostuvat eritasoisista toiminnoista. Esimerkiksi kiinteistön ylläpito sisältää kiinteistönhoidon, joka puolestaan useimmiten sisältää sekä kiinteistön huollon että teknisten järjestelmien hoidon. Ylläpidon tiedontarve perustuu sen omaan tavoiteasetteluun. Ylläpidon keskeisenä tavoitteena on aikaansaada asetettujen tavoitteiden mukaiset työolosuhteet (erityisesti sisäolosuhteet), kehittää energiankulutusta vähentäviä toimintamalleja sekä huolehtia, että kiinteistöt ovat elinkaarensa mukaisessa teknisessä kunnossa. Ylläpito pyritään toteuttamaan optimaalisin kustannuksin volyymietu huomioiden ja saavuttamaan asetetut kulutustavoitteet. Ylläpidon käyttämä tieto voidaan jakaa aktiiviseen ja passiiviseen tietoon. Aktiivista tietoa ovat esimerkiksi palvelupyynnöt, vikailmoitukset ja hälytykset sekä antureiden ja mittareiden tuottama tieto. Passiivista tietoa ovat muun muassa tilojen pintamateriaalien ja rakenteiden tiedot, kiinteistönhoidon tarjouspyyntömateriaali, huoneiston käyttöohjeet ja huolto-ohjelma. Tietomalli sisältää pääasiassa raakadataa, jota ihminen ei voi sellaisenaan hyödyntää. Tieto on käyttökelpoista vasta, kun datasta muodostetaan ihmisen ymmärtämää informaatiota. Tästä syystä prosessi, jolla data muutetaan informaatioksi, on vähintään yhtä tärkeä kuin itse data.
19 5 Ylläpitomalli 5.1 Yleistä Ylläpitomalli tarkoittaa rakennuksen yhdistelmämallia, jossa on esitetty käytön ja ylläpidon aikaista huoltoa, käyttöä ja kunnossapitoa vaativat rakenteet ja laitteet. Ylläpitomallin avulla voidaan paikantaa tiloja, laitteita ja muita ylläpitokohteita, sekä tuottaa näkymiä esimerkiksi piilossa olevista huolto- ja korjausrakennuskohteista. Kuva 5. Ylläpitomalli on as built -mallien yhdistelmä 5.2 Ylläpitomallin tietosisältö Ylläpitomalli sisältää pääasiassa passiivista tietosisältöä. Oleellisimpia passiivisia tietoja kiinteistönhoidon kannalta ovat muun muassa seuraavat: - Tilatiedot - Laitetiedot karkealla tasolla - Teknisten järjestelmien vaikutusaluekartat - Paikannuspiirustukset / järjestelmien paikannuskaaviot - Konekortit / toimintakaaviot järjestelmittäin - Järjestelmäkuvaukset
20 Tarpeellisen tiedon tarve vaihtelee käyttäjäryhmittäin, joten ylläpitomalliin tulisi voida luoda erilaisia, käyttäjäroolista riippuvia tasoja tai käyttöliittymiä. Tällä hetkellä ylläpitomalli toimii passiivisen tiedon varastona, mikä rajoittaa sen käyttämisen lähinnä tiedon hakemiseen ja visualisointiin. Jotta ylläpitomalli vastaisi kiinteistönhuollon tarpeita, sen tulisi sisältää vähintään paikannuspiirustuksissa vaadittavat tiedot sekä yksilölliset tunnisteet, joiden avulla laitetiedot voitaisiin yhdistää huoltokirjaan. Tällöin huoltokirjaan ei tarvitsisi laatia erillisiä 2D-paikannuspiirustuksia, vaan paikantaminen tapahtuisi suoraan tietomallista. Kaiken mahdollisen tiedon tallentaminen tietomalliin kasvattaa mallin kokoa ja vaikeuttaa sen käsittelyä. Eniten käytettävän tiedon tulisikin sijaita erillisessä tietokannassa, jossa sitä ylläpidetään ja josta sitä voidaan tarvittaessa hakea. Myös tietojen päivitettävyyden kannalta on järkevää, ettei kiinteistön ylläpitoon liittyvää tietoa varastoida yhdistelmämalliin. Mallin tulee sisältää vain tarpeelliset tiedot rakennuksen geometriasta, rakenteista ja osista, joiden avulla ne voidaan yhdistää sähköiseen huoltokirjaan tai muuhun digitaaliseen järjestelmään. 5.3 Ylläpitomallin käyttö Ylläpitomallia voidaan käyttää työkaluna esimerkiksi seuraaviin toimintoihin: 1. Visualisointi - Seinien ja alakattojen sisällä olevien kohteiden tarkastelu - Teknisten laitteiden paikantaminen - Laitteistojen sijoituksen hahmottaminen - Ongelmakohteiden löytäminen - Teknisten järjestelmien vaikutusalueiden kartoittaminen - Käyttäjien muutosten havainnollistamiseen 2. Käyttömuutoksien ja korjaustyön suunnittelu - Putkistojen ja johtoteiden suunnittelu - Olosuhdesimuloinnit - Tilamuutoksien suunnittelu 3. Työn suunnittelu ennen kohteeseen menoa - Kulkureitti työkohteeseen - Huolto-ohjeet 3D-näkymässä - Oikeiden työkalujen ja varaosien ennakointi - Taloteknisten komponenttien saavutettavuuden arviointi - Vikojen syy seuraussuhteiden selvittäminen - Lisätyn todellisuuden (AR) käyttäminen huolto-ohjeissa
21 4. Energiasimulointi käytön aikana - Lämmön, kaukokylmän, veden ja sähkön kulutukseen vaikuttavien tekijöiden tunnistaminen - Laskennallisen ja todellisen kulutuksen vertailu 5. Muut simulaatiot - Palosimulaatiot - Rakenne- ja kuormitussimulaatiot - Pinta-alatietojen ja palo-osastojen todentaminen 6. Turvallisuus - Turvallisuushenkilöstön perehdytys - Turvakävelyjen visualisointi - Pelastustoimen hyökkäysreittien suunnittelu hätätilannetta varten - Hätäpoistuminen - Sammutussuunnitelmat - Paloilmoittimen paikantamiskaaviot - Savutuuletus - Palo-osastot - ATEX-alueet - Ovikartat ja avainsarjat - Sprinkleri- ja kaasusammutusalueet 7. Käyttäjän avustaminen - Muutoskustannusten ja huoltohintojen perustelu Ylläpitomallin suurimpia vahvuuksia 2D-piirustuksiin verrattuna on sen visuaalisuus. Mallin tulkinta ei edellytä rakennuspiirustusten lukutaitoa, mutta se edellyttää kykyä hahmottaa tiloja kolmiulotteisesti. Rakenteiden sisällä olevaa rakennus- ja talotekniikkaa voidaan tarkastella ilman, että rakenteita tai luukkuja tarvitsee avata. Malli helpottaa myös vikatilanteen syiden ja seurausten arviointia. Mallin avulla on mahdollista tarkastella samanaikaisesti laajempia kokonaisuuksia ja tehdä johtopäätöksiä asioiden keskinäisistä vaikutuksista. Teknisessä mielessä yhdistelmämallissa ei normaalisti ole linkkiä esimerkiksi taloteknisen järjestelmän keskuslaitteen ja tilan välillä. Toisin sanoen esimerkiksi järjestelmän vaikutusalue pitää tunnistaa manuaalisesti seuraamalla siirto-osia, ellei näitä linkkejä erikseen ole rakennettu malliin. Tietomallin käyttö paikantamispiirustuksena edellyttää yhtenäistä komponenttien nimeämiskäytäntöä esimerkiksi huoltokirjan ja vikailmoitusten kanssa. Suunnittelun ja toteutuksen tavoitteena tulee olla ratkaisu, joka mahdollistaa kiinteistön toteutuneen energiankulutuksen ja todellisten olosuhteiden vertaamisen suunnitteluvaiheessa tehtyihin laskelmiin. Tällöin rakennuksen energiankulutus ja olosuhteet on simuloitava suunnitteluvaiheessa. Käytönaikaisen vertailun tekeminen edellyttää, että tiedot ovat ylläpidon
22 käytettävissä, sekä että olosuhteet mitataan riittävässä laajuudessa vertailun tekemisen näkökulmasta. Tietomalleja ei tällä hetkellä tiettävästi käytetä turvallisuustoiminnan suunnittelussa tai pelastustoiminnassa. Malli kuitenkin mahdollistaa sekä käyttäjien että pelastusviranomaisen perehdyttämisen kiinteistön poistumisturvallisuuteen. Malli voi myös toimia pelastushenkilöstön apuna suunniteltaessa rakennukseen loukkuun jääneiden ihmisten pelastamista esimerkiksi tulipalotilanteessa. Mallien uskottavuuden ja sen kautta käytön avaintekijä on niiden ajantasaisuus. Kiinteistölle tulisi laatia ylläpidon tietomallien mallien päivitysohje, jossa kuvataan päivityksiin liittyvät tehtävät, vastuut ja ajankohdat. Päivityksiin voidaan liittää sovittaessa myös energiatodistuksen päivitys ja ylläpidon ohjelmistojen auditointi. Ylläpidon mallien päivitykset on luontevinta ajoittaa korjausrakennushankkeiden yhteyteen. Näiden lisäksi kiinteistössä voi olla tarvetta määräaikaisille päivityksille. 6 Olosuhdemalli 6.1 Yleistä Olosuhdemalli on rakennuksen 2,5- tai 3D-malli, johon on yhdistetty rakennukseen asennettujen sensoreiden tuottama tieto vallitsevista olosuhteista. Olosuhdemallin tietosisältöä, visualisoinnin toteutustapaa ja mittaustiedon ajantasaisuuden vaatimuksia ei toistaiseksi ole määritelty. Markkinoilla ei myöskään ole valmista, tietomalliin pohjautuvaa visualisointiratkaisua. Tällä hetkellä olosuhdemallia sanan varsinaisessa merkityksessä ei vielä ole olemassa. Erilaisia käyttöliittymiä olosuhde- ja kulutustietoon on tuotantokäytössä, mutta ne eivät perustu kohderakennuksen tietomalliin. Joissakin ratkaisuissa on mallin sijaan hyödynnetty 2Dpohjapiirroksia tai 2,5D -piirroksia. 2,5D tarkoittaa kallistettua tasokuvaa, jossa on esitetty myös seiniä. Lähimpänä tuotteistusta on Senaatti-kiinteistöjen 3D-tietomalliin perustuva Virtuaalinen kiinteistö, jossa sisäolosuhteita ja energiankulutuksia esitetään Internetin kautta kiinteistöjen käyttäjille ja kiinteistönhuollolle. Virtuaalisen kiinteistön kautta voi myös jättää kiinteistöä koskevia palvelupyyntöjä, seurata korjausten toteutumista ja viestiä kiinteistönhoidon etävalvomon kanssa. 6.2 Olosuhdemallin tietosisältö Olosuhdemallin tarkoitus on esittää tietomallin avulla visuaalista informaatiota rakennuksen muuttuvista suureista, kuten esimerkiksi sisäilman lämpötilasta, hiilidioksidipitoisuudesta tai
23 rakennuksen energiankulutuksesta, tietyllä ajanhetkellä määrätyssä tilassa tai tilaryhmässä. Olosuhdemalli sisältää sekä passiivista että aktiivista tietosisältöä. Oleellisimpia aktiivisia tietoja ovat muun muassa: - Lämpötila ja sisäilman laatu - Rakennuksen painesuhteet - Rakennekosteudet - Valaistuksen käyttötiedot - Energiankulutus - Erilaiset hälytykset - Teknisten järjestelmien käyntitilatiedot - Tilojen käyttöaste - Kokoustilojen varaustilanne Tarpeellisen tiedon tarve vaihtelee käyttäjäryhmittäin, sillä esimerkiksi tilojen käyttäjä tarvitsee erilaista tietoa kuin kiinteistönhoito. Olosuhdemalliin tulisi voida luoda erilaisia, käyttäjäroolista riippuvia tasoja tai käyttöliittymiä. Olosuhdemallin tarvitsemaa visualisointia ei ole perusteltua rakentaa suoraan tietomalliin kahdesta syystä. Ensinnäkin lisätiedon luominen malliin kasvattaisi sen kokoa ja vaikeuttaisi sen käsittelyä. Toiseksi aktiivisen tiedon näyttäminen edellyttäisi rajapintojen rakentamista yhdistelmämallin ja hetkellistä dataa tuottavien järjestelmien esimerkiksi rakennusautomaation välille. Tätä ei nykyisen tiedon valossa pystytä toteuttamaan kustannustehokkaasti ja yleispätevästi siten, että sama rajapinta kykenisi palvelemaan erityyppisiä järjestelmiä. Aktiiviset tiedot tulisi tallentaa erilliseen tietokantaan, jossa niiden operointi ja varmuuskopiointi voidaan suorittaa häiritsemättä tietomallia itseään. Tietokannan käyttäminen mahdollistaa myös taloteknisten järjestelmien välisen tiedonsiirron ilman erillistä rajapintaa. Tämä tarkoittaa sitä, että esimerkiksi rakennusautomaatio voi suoraan hyödyntää olosuhdemittauksen tuottamaa dataa ja huoltotehtävät palvelupyyntödataa sen jälkeen, kun niiden tiedot on tallennettu tietokantaan. Tämä vaatimus aiheuttaa sen, että tietokantaan tallennettavalla tiedolla on oltava ennalta sovittu keräystaajuus ja aikaleima, mikä puolestaan vaikuttaa tallennuskapasiteetin tarpeeseen. Pilotoiduissa ratkaisuissa olosuhdemalli on luotu yhdistelmämallista luomalla tarvittavat rakennus- ja talotekniset osat sisältävä yksinkertaistettu malli, joka vastaa rakennuksen kolmiulotteista kuvaa. Kukin tila on esitetty tilaelementtinä, jonka ominaisuuksia (esimerkiksi väriä) voidaan dynaamisesti muuttaa ja johon voidaan lisätä animaatioita. Olosuhdemalli edellyttää, että jo suunnitteluvaiheessa aktiivisille komponenteille luodaan paikkatieto ja identiteetti, jotka pystytään lukemaan ulkopuoliseen tietokantaan. Tällöin esimerkiksi rakennusautomaatiojärjestelmä pystyy tunnistamaan mallissa olevat komponentit ja tuottamaan kullekin komponentille dedikoitua mittausdataa. Kun mittausdata ja paikkatieto
24 yhdistetään ja sijoitetaan rakennuksen tietomallista luotuun tilamalliin, saadaan yksinkertainen olosuhdemalli. Samaan tietokantaan voidaan tuoda myös muita aktiivisia tietoja, kuten esimerkiksi asioiden, laitteiden tai komponenttien käyntitilatietoja sekä käyttöastedataa. Näiden liittäminen olosuhdetiedon kanssa samaan, kolmiulotteiseen näkymään tekee olosuhdemallista monipuolisemman ja käyttökelpoisemman. Taloteknisessä suunnittelussa luodaan myös suuri määrä 2D-piirustuksia, joiden sisältämää tietoa ei siirretä tietomalliin. Tällaisia piirustuksia ovat esimerkiksi sähkökeskusten pääkaaviot ja piirikaaviot sekä LVI- ja automaatiojärjestelmien toimintakaaviot. Periaatteessa esimerkiksi 2D-toimintakaavio voisi hyvin sisältää aktiivisia komponentteja, jotka olisi liitetty joko tietomalliin tai edellä kuvattuun erilliseen tietokantaan. 6.3 Olosuhdemallin käyttö Olosuhdemallia voidaan käyttää esimerkiksi seuraaviin toimintoihin: 1. Visualisointi - Tilojen sisäolosuhteiden havainnointi sekä kokonaisuutena että tilakohtaisesti - Rakennuksen energiankulutuksen toteaminen - Teknisten laitteiden päällä/pois tilojen toteaminen - Tilojen varaustilanteen toteaminen - Tilojen käyttöasteen ja -tilanteen toteaminen - Tilojen tunnistaminen ja löytäminen - Palvelupyynnön tilan toteaminen - Käyttäjäpalautteen esittäminen 2. Analysointi - Talotekniikan säätöjen oikeellisuuden arviointi - Palvelupyyntöjen syy/seuraussuhteiden selvittäminen - Energiankulutukseen vaikuttavien tekijöiden tunnistaminen - Käyttäjäpalautteen analysointi - Käyttäjätyytyväisyyteen vaikuttavien tekijöiden tunnistaminen 3. Turvallisuus - Poistumisopastus - Palo- tai pelastustoiminta-alueen toteaminen - Henkilöiden paikantaminen hätätilanteessa - Ovien auki/kiinni tilat 4. Toimitilapalvelut - Tilavaraukset - Vapaat ja varatut tilat - Työpisteiden varustelu - Tarjoilut
25 - IT-laitteet ja käyttötuki - Läsnäolotieto (tavoitettavuus) Olosuhdemallin visuaalinen tulkinta edellyttää kykyä hahmottaa tiloja kolmiulotteisesti. Esimerkiksi tietyn tilan löytäminen monimutkaisesta mallista edellyttää kolmiulotteista hahmottamista. Toisaalta mallia voi myös tarkastella kerroksittain kohtisuorasti lattiatasoon nähden, jolloin näkymä ei poikkea 2D-näkymästä. Kolmiulotteisuuden ansiosta on mahdollista tarkastella samanaikaisesti useita kerrostasoja ja tehdä johtopäätöksiä laajoista kokonaisuuksista. Olosuhdemallissa tulee itsessään olla tai sen kautta tulee olla saatavissa pysyvyystietojen, käyttäjäpalautteen ja käyttöasteiden aikasarjoja, joita pystytään tarkastelemaan visuaalisesti. Olosuhdemallin toteuttaminen edellyttää, että suunnittelijat tietävät, mitä tietoa mallissa halutaan näyttää. Suunnittelijan tulee paikantaa komponentit malliin ja nimetä ne siten, että ne voidaan vaivatta löytää ja liittää ne tietokantaan. Nimeämisessä komponenteille on annettava vähintään paikkatieto, mitattava tai laskettava suure tai suureet, tila jota kyseinen komponentti palvelee sekä järjestelmä, johon se kuuluu. Tapauskohtaisesti voidaan tarvita muitakin tietoja. Yhtenäinen komponenttien nimeämiskäytäntö on tarpeellinen myös esimerkiksi huoltokirjan ja vikailmoitusten kannalta. Olosuhdemallin kannalta on keskeistä, että anturointi riittävän tiheä sekä tiedonkeruutaajuus riittävän korkea, jotta tavoiteltu informaatiotaso voidaan saavuttaa. 6 Tietomallien mahdollisuudet Tietomallien käyttöä rakennuksen käytön aikana voidaan tarkastella joko osapuolten (käyttäjäroolien) näkökulmasta tai prosessien näkökulmasta. Tämän raportin lähtökohta on prosessilähtöinen. Useilla osapuolilla on joko samoja tai hyvin lähellä toisiaan olevia tarpeita, joiden listaaminen useaan kertaan ei ole tarkoituksenmukaista. Prosessilähtöisyys tukee myös tietomallin sisällön ja rakenteen kehittämistä paremmin kuin osapuolilähtöisyys. Tässä työssä tarkastellut prosessit ovat: - Kiinteistöliiketoiminta - Energiatehokkuuden ja sisäolosuhteiden hallinta - Kunnossapito - Kiinteistönhoidon tarjouslaskenta - Huoltokirjan käyttö - Toimitilapalveluiden tuottaminen - Kiinteistön käyttö Prosesseja tuottavat ja hallinnoivat osapuolet ovat: - Kiinteistön omistaja - Paikallinen kiinteistönhoito
26 - Kiinteistönhoidon etävalvomo - Kiinteistön kohdekäyttäjä - Käyttäjän kiinteistömanageri - Lisäarvopalveluiden tuottajat 6.1 Kiinteistöliiketoiminta Kiinteistöliiketoiminnan näkökulmasta tietomalli on taloudellinen ja immateriaalinen sijoitus, jonka tavoite on muun muassa tuottaa kustannussäästöjä hankkeissa, lyhentää rakentamisaikaa ja parantaa rakentamisen laatua. Rakennusvaiheen jälkeen tietomallia hyödynnetään lähinnä tilamuutosten, saneerausten ja peruskorjausten lähtötietojen tuottamisessa. Jatkohankkeiden suunnittelutyö ei kuitenkaan käytännön syistä käynnisty yhdistelmämallista, vaan suunnittelualakohtaisista natiivimalleista. Ennen muutostyön varsinaisen suunnittelun aloittamista yhdistelmämallia voidaan käyttää lähinnä toteutuksen kokonaisuuden tarkasteluun, tilatarpeiden sijoitteluun kerros- tai rakennusosatasolla sekä arkkitehdin luonnosvaiheen ratkaisujen esittelyyn rakennuksen omistajalle ja käyttäjille. Tietomallin käyttötapoja kiinteistöliiketoiminnassa ovat esimerkiksi seuraavat: - Kohteen muodon ja koon sekä sen erityispiirteiden hahmottaminen - Rakenteellisten mahdollisuuksien tunnistaminen tila- ja käyttötapamuutosten kannalta - Talotekniikan mahdollisuuksien tunnistaminen tilamuutosten näkökulmasta - Kiinteistönhoidon tarjouslaskennan tukeminen - Poistumisturvallisuuden tarkastelu ja suunnittelu - Kulunhallinnan suunnittelu ja valvonta - Tilaratkaisujen esittely käyttäjille - Eri käyttäjien tilojen rajapintojen ja laajuuksien havainnointi
27 Kuva 6. Tietomallin käyttömahdollisuuksia kiinteistöliiketoiminnassa Tietomallinnuksen ylläpidon aikaisia etuja kiinteistöliiketoiminnan näkökulmasta ovat esimerkiksi rakennuksen arvon parempi säilyminen ja pienemmät ylläpitokustannukset kehittyneen ylläpitotoiminnan avulla, parempi myyntiarvo kiinteistötiedon läpinäkyvyyden ja laadukkuuden avulla, parempi tuotos-panos-suhde tarkempaan tietoon perustuvan tilankäytön ja -tarjonnan avulla sekä korkeampi tuottotaso mallin mahdollistamien laadukkaiden lisäarvopalveluiden avulla. 6.2 Energiatehokkuuden ja sisäolosuhteiden hallinta Tietomallia voidaan käyttää esimerkiksi energiankulutukseen vaikuttavien tekijöiden tunnistamiseen sekä laskennallisen ja todellisen kulutuksen vertailuun. Tämä edellyttää sitä, että kulutukset on simuloitu suunnitteluaikana ja tarkastettu as built-mallista todellisten laiteja komponenttihankintojen perusteella. Lisäksi tulosten täytyy olla ylläpito-osapuolten hyödynnettävissä, mikä asettaa tulosten tallennusformaatille erityisvaatimuksia. Kun rakennuksesta on luotu olosuhdemalli, voidaan energiankulutusta visualisoida esimerkiksi väreillä tai animaatiolla. Kulutuspoikkeamat on helppoa todeta havainnollisen visualisoinnin avulla. Samalla pystytään seuraamaan olosuhteissa, käytössä ja talotekniikan toiminnassa tapahtuvia muutoksia, sekä tunnistamaan ja hallitsemaan niiden avulla energiankulutukseen ja olosuhteisiin vaikuttavia tekijöitä. Tietomallin käyttö parantaa myös etäkäytön ja -hallinnan mahdollisuuksia. Etäkäytöllä ja - hallinnalla tarkoitetaan toimintaa, jossa kiinteistönhoidon palveluntuottaja valvoo ja operoi kiinteistön rakennusautomaatiojärjestelmää etäyhteyden kautta etävalvontakeskuksesta. Etävalvontakeskuksen tärkein tehtävä on ajaa rakennusta ennakoivasti optimaalisilla
28 asetusarvoilla. Toinen tärkeä rooli on etsiä järjestelmätason vastauksia ja ratkaisuja energiankulutus- ja sisäolosuhdepoikkeamiin, tukea paikallista kiinteistönhoitajaa pulmatilanteissa sekä parantaa kiinteistönhoidon mahdollisuuksia havaita ja korjata nopeammin energiankulutukseen ja sisäolosuhteisiin vaikuttavat viat. Lisäksi etävalvomolla on paikallista kiinteistönhoitajaa paremmat mahdollisuudet tarkkailla pitkäaikaisia trendejä ja havaita hitaasti tapahtuvaa asetusarvojen ryömintää, sekä laitteiden suorituskyvyn heikkenemistä. 6.3 Kunnossapito Kunnossapidon tarkoitus on huolehtia rakennuksen koneiden, laitteiden ja rakennusosien kunnosta siten, että - toiminta voi tapahtua olosuhteissa, jotka ovat edullisimmat nettotuottojen, turvallisuuden, ympäristön ja laadun kannalta ja - palvelu voidaan tuottaa siten, että asiakas on tyytyväinen ja kustannus/laatusuhde mahdollisimman edullinen. Kunnossapito jaetaan tavallisesti ennakoivaan (ehkäisevään) ja korjaavaan kunnossapitoon. Ennakoivan kunnossapidon tarkoitus on pienentää vikaantumisen todennäköisyyttä ja laitteistojen toimintakyvyn alenemista. Ennakoiva kunnossapito on joko säännöllistä tai sitä tehdään tarpeen vaatiessa. Ennakoivaa kunnossapitoa ovat mm: - tarkastaminen, - kuntoon perustuva kunnossapito - määräystenmukaisuuden toteaminen sekä - testaaminen ja toimintakunnon toteaminen. Senaatti-kiinteistöissä käytetään ennakoivan kunnossapidon johtamisjärjestelmänä digitaalista huoltokirjaa, jossa on määritelty muun muassa laite- ja rakennusosakohtaiset huolto- ja tarkastusjaksot. Huoltokirjaan on kuvattu myös ennakoivaan kunnossapitoon liittyvät toimenpiteet. Huoltokirjan kautta välitetään myös kiinteistön käyttäjiltä tulevat palvelupyynnöt, jotka voivat nimensä mukaisesti sisältää vikailmoitusten lisäksi kiinteistöä koskeviin palveluihin liittyviä pyyntöjä. Ennakoivan kunnossapidon kannalta keskeistä on, että toimenpiteitä vaativat laitteet ja rakennusosat on paikannettu ja nimetty tietomalliin. Esimerkkinä mainittakoon vesikaton pintamateriaali, jolle voidaan määritellä huoltojaksot ja arvioitu käyttöikä. Myös huoltotehtävät olisi periaatteessa mahdollista kirjoittaa suoraan tietomalliin. Suunnittelijat eivät kuitenkaan välttämättä ole oikea taho määrittelemään kunnossapitotoimenpiteitä, joten se siirretään yleensä erillisen osapuolen (yleensä nk. huoltokirjan laatija) tehtäväksi. Kunnossapitotoimenpiteet määritellään tavallisesti rakennusaikana, sillä tavoitteena on että valmis huoltokirja olisi käytettävissä rakennuksen valmistuessa.