Malli on todellisuuden yksinkertaistus. Todellisuus on äärettömän monimutkainen ja jokaisella sen osalla on loputtomasti ominaisuuksia ja suhteita. Kun todellisuudesta tehdään malli, on sen väistämättä oltava radikaali yksinkertaistus. Klassinen matematiikka ei pysty hallitsemaan edes mallia, jossa on vaivaiset 3 toisiinsa painovoiman kautta vaikuttavaa taivaankappaletta. Myöskään, jos rakennuksen seinät ovat vaaterissa, ne eivät ole yhdensuuntaisia, koska ’vaateri’ syntyy maapallon keskipisteen kautta kulkevan säteen avulla.
Malli on todellisuuden yksinkertaistus käyttötarkoitukseen. Jotta todellisuutta voidaan yksinkertaistaa, pitää valita näkökulma, eli käyttötarkoitus. Perinteinen pahvista tehty arkkitehtimalli soveltuu massoittelun tutkimiseen, mutta ei sen selvittämiseen, miten tulipalo etenee rakennuksessa. Tietomallit ovat tietysti monipuolisempia ja yksi tietomalli voi soveltua useampaan käyttötarkoitukseen. Ne eivät kuitenkaan automaattisesti tai sattumalta sovellu mihinkään, vaan kaikki käyttötarkoitukset pitää mahdollistaa tarkoituksella. Esimerkiksi aito ’digitaalinen kaksonen’ on mahdoton, koska se ei olisi todellisuuden yksinkertaistus, eikä sillä olisi erikseen määriteltyjä käyttötarkoituksia.
Tietomallissa tieto on tallennettu tietorakenteisiin. Tietorakenteiden rakennuspalikat ovat objektit ja niiden ominaisuudet. Rakennusten tietomallien yhteydessä puhutaan usein objekteista, ominaisuuksista, relaatioista ja geometriasta. Tässä jaottelussa ominaisuudet ovat tekstiä, numeroita, mittoja jne., relaatiot suhteita objektien välillä ja geometria objektin 3D tai 2D esitys. Oikeasti malleissa on kuitenkin aina vain objekteja ja ominaisuuksia, jolloin relaatiot ovat yhdenlasia ominaisuuksia ja geometria koostuu objekteista, jotka on liitetty ’varsinaisiin’ objekteihin relaatioilla. Tuo tyypillinen jako, vaikka se onkin teknisesti keinotekoinen, on kuitenkin hyödyllinen, koska se auttaa puhumaan tietomalleista.
Eri malleissa sama tieto voidaan tallentaa eri tietorakenteisiin. Voidaan esimerkiksi sanoa, että seinä tehdään betonista, mutta aivan yhtä hyvin, että betonista tehdään seinä. Kun seinä tehdään betonista, on rakennusosa objekti ja materiaali sen ominaisuus. Kun taas betonista tehdään seinä, on materiaali objekti ja rakennusosa ominaisuus. Tämä on olennaista kun tietomalleja käytetään tiedonsiirrossa. Lähettävän osapuolen omassa, ns. natiivimallissa, tieto on tallennettu tuon mallin tietorakenteisiin, tiedonsiirtoa varten sama tieto tallennetaan toisiin tietorakenteisiin (esimerkiksi IFC) ja vastaanottavassa ohjelmistossa vielä kerran vastaanottavan ohjelmiston tietorakenteisiin.
Kun tieto muunnetaan toisiin tietorakenteisiin (transformoidaan), voi tietoa kadota. Tämä voi johtua virheistä, ja olla siten tahatonta. Tietoa voidaan kuitenkin myös kadottaa tahallisesti, esimerkiksi seinäelementtien aikataulutukseen tarvitaan paljon vähemmän tietoa kuin niiden suunnitteluun ja valmistukseen. Tässä palataan eri mallien käyttötarkoitukseen, sillä seinäelementtien aikataulutusta varten todellisuutta voidaan yksinkertaistaa enemmän kuin niiden valmistusta varten.
Toisaalta tietoa voi olla liian vähän, jolloin mallia pitää rikastaa, jotta se soveltuu ajateltuun käyttötarkoitukseen. Esimerkiksi rakennesuunnittelijan mallin seinäelementissä ei ole aikataulutietoa, joten mallia pitää rikastaa aikataulutusta varten. Onnistuneessa tiedonsiirrossa tapahtuu siis tahallista tiedon kadottamista ja siinä pitää hyväksyä, että siirretty malli ei sisällä kaikkea tarvittavaa tietoa.
Rakennusalalla käytetyt ohjelmistot ja tiedonsiirtoformaatit voivat antaa sellaisen kuvan, että tietomallien rakenne ja käyttötarkoitukset on jo ’keksitty’ ja lyöty lukkoon. Näin ei suinkaan ole, vaan tietomallintamisessa on vasta raapaistu pintaa ja parhaat ideat ovat vielä keksimättä. Toimintaan on kuitenkin jo pesiytynyt haitallisia ajatuksia ja ratkaisuja, joita voidaan haastaa tässä esitettyjen periaatteiden pohjalta.
Tiedon menettäminen tiedonsiirrossa nähdään usein periaatteelliseksi ongelmaksi, vaikka se johtuu eri tarkoitukseen tehtyjen tietomallien erilaisista rakenteista ja on siten luonteva osa tietomallipohjaista tiedonsiirtoa. Tästä on myös hyötyä toisella tasolla. Alkuperäisissä malleissa on usein parametrisiä objekteja, joiden kehittämiseen on nähty paljon vaivaa, eikä niitä siksi haluta luovuttaa muille osapuolille. Kun tiedonsiirrossa käytetään staattisia objekteja, jotka ovat kopio alkuperäisen parametrisen objektin tietystä konfiguraatiosta, voidaan tarvittava suunnittelutieto siirtää ilman pelkoa immateriaalioikeuksien vuotamisesta.
Toisaalta jos ei ymmärretä mallien rikastamisen mahdollisuutta, päädytään usein vaatimaan toisilta osapuolilta sellaista tietoa, jota he eivät luontevasti tuota osana omaa tehtäväänsä. Tästä on hyvänä esimerkkinä lohkojako, joka rakennusliikkeen on luontevinta lisätä malliin itse, sen sijaan että se vaadittaisiin suunnittelijoilta.
Jos taas ei ymmärretä tietorakenteiden muokkaamisen mahdollisuutta, päädytään helposti vaatimaan vastaanottajan tarvitsemia tietorakenteita, kuten luokitteluja. Parempi ratkaisu on siirtää luokitteluun tarvittavia tietoja ja antaa vastaanottajan luokitella malli näiden tietojen perusteella haluamallaan tavalla.
Siirrettävän mallin, eli IFC mallin, muokkaamista vastustetaan myös usein periaatteellisista syistä. Mallin muokkaaminen on muka vaarallista. Kun kuitenkin ymmärtää, että tieto ja tietorakenteet ovat eri asia, voi huoletta muokata tietoa toisenlaisiin tietorakenteisiin. Tämä tapahtuu tiedonsiirron yhteydessä joka tapauksessa kaksi kertaa; kun natiivimallista luodaan IFC malli ja kun IFC malli luetaan vastaanottavaan ohjelmistoon. Ei siis pitäisi olla mitään ongelmaa siinä, että tietorakenteita muokataan tarvittaessa vielä kolmannen kerran tiedonsiirron yhteydessä. Päinvastoin, tästä on käytännössä monia hyötyjä, koska se mahdollistaa onnistuneen tiedonsiirron vähemmillä vaatimuksilla. Parhaimmillaan vaatimukset nimittäin kohdistuvat vain tietoon, eivät lainkaan tietorakenteisiin. Kaikki lienevät sitä mieltä, että vaatimusten vähentäminen on hyvä asia.
Tietomallien teorian ymmärtämisestä on siis selkeitä hyötyjä, koska se auttaa kyseenalaistamaan vallitsevia käytäntöjä ja kehittämään parempia niiden tilalle.
7.5.2022
Jiri Hietanen