TAUSTA
Suomessa ja maailmalla on jo reilun vuosikymmenen ajan kehitetty tietomallipohjaista tiedonsiirtoa tukevia tietomallivaatimuksia. Itse osallistuin jo 2007 Senaatti Kiinteistöjen vaatimusten, jotka olivat yhdet maailman ensimmäisistä, kirjoittamiseen. Työtä tehdään siis paljon, mutta silti tarjolla on hämmästyttävän vähän selkeää analyysiä siitä, millainen on hyvä tietomallivaatimus.
Tämän dokumentin tarkoituksena on määritellä kriteerejä hyville tietomallivaatimuksille. Kun kirjoitat, kommentoit tai noudatat tietomallivaatimuksia, voit peilata niitä näitä kriteerejä vasten. Voit esittää yksinkertaisia kysymyksiä ja koittaa löytää niihin yksinkertaisia vastauksia. Valitettavan usein jo muutaman kysymyksen esittäminen osoittaa nykyisten tietomallivaatimusten heikkouden.
KRITEERIT
1. Tuottaa arvoa
Vaatimusten tulee mahdollistaa jotain hyödyllistä.
Jos huonetiloilla on huonetilaohjelmaa vastaava nimi, voidaan suunnitelmaa verrata huonetilaohjelmaan.
Usein vaatimuksissa ei kerrota, miksi vaatimus on asetettu. Tämä voi johtua esim. siitä, että samaan vaatimukseen on vedetty yhteen usean eri käyttötapauksen mahdollistaminen, eikä lukijaa haluta rasittaa kaikilla yksityiskohdilla. Hyödyn osoittaminen on kuitenkin tärkeää, koska se auttaa motivoimaan vaatimusten noudattajia ja myöskin kehittämään vaatimuksia tulevaisuudessa. Voi nimittäin hyvinkin olla, että mallin vastaanottaja ei tunnista hyötyä.
Asetetaan vaatimus, että kaikilla rakennusosilla pitää olla Talo90 luokittelu ,koska se mahdollistaa mallin jäsentämisen määrälaskentaa varten. Määrälaskija ei kuitenkaan hyödynnä arkkitehdin malliin syöttämää Talo90 luokittelua, koska ei luota siihen, että se on tehty oikein.
2. Ei sekoita vaatimuksia ja ohjeita
Vaatimus asetetaan aina siirrettävälle mallille, joka on useimmiten IFC formaatissa. Ohjeet taas liittyvät siihen, miten vaatimukset täyttävä malli saadaan aikaiseksi.
Kaikki seinät tulee mallintaa seinätyökalulla.
Yllä oleva vaatimus sekoittaa vaatimusta ja ohjetta. Puhdas vaatimus olisi, että kaikki seinät tulee siirtää seinäobjekteina. Ohje taas on, että yksi tapa toteuttaa tämä vaatimus on mallintaa seinä seinätyökalulla. Vaatimuksen ja ohjeen erottaminen avaa mahdollisuuden toteuttaa sama vaatimus myös eri tavalla, esimerkiksi pilarityökalulla mallinnettu seinä voidaan tiedonsiirtoa varten osoittaa seinäksi tai seinätyökalulla mallinnettu liitutaulu voidaan osoittaa varusteeksi. Tämä on hyvin tärkeää alan kehittymisen kannalta, koska se tukee ajatusta siitä, että olemme vasta raapaisseet hieman pintaa ja tulevaisuudessa asiat voidaan aina tehdä tehokkaammin ja luotettavammin.
Tähän liittyy olennaisesti se, että vaatimukset koskevat vain ja ainoastaan siirrettävää mallia, eivät koskaan ns. natiivimallia tai muuta tapaa, jolla siirtomalli on tuotettu.
3. Vaatimuksen toteuttamiselle on olemassa ohje
Toteuttamiskelpoisen ohjeen olemassaolo todistaa, että vaatimus on mahdollista toteuttaa.
Seinät saadaan siirtymään seinäobjekteina, kun ne mallinnetaan seinätyökalulla.
Ohje myös paljastaa, jos vaatimuksen täyttäminen on epärealistisen työlästä
Rakennusosille asetetaan kerrostieto yksi kerrallaan avaamalla ko. rakennusosan ominaisuusdialogi.
4. On käytännössä toteutuskelpoinen
Ohjelmistot mahdollistavat teknisesti monenlaisen tiedon syöttämisen malliin, mutta oikeasti voimme luottaa vain sellaiseen tietoon, jonka mallin laatija myös suunnittelee tai määrittelee.
Mallin objektit tulee katkaista lohkorajoilla.
Koska rakennusliike määrittelee lohkorajat, pakottaa yllä oleva vaatimus suunnittelijan jäsentämään mallit tavalla, joka ei kuulu hänen suunnittelutyöhönsä ja vaikeuttaa lisäksi tarpeettomasti mallintamista. Rakennusliikkeen on parempi lisätä lohkotieto malliin itse, jolloin se tulee tehtyä oikein ja prosessi on tehokkaampi.
5. On mahdollisimman yksinkertainen ja selkeä
Vaatimuksissa on useimmiten yksi komponentti, joka käsittelee tietosisältöä ja toinen, joka käsittelee teknistä toteutusta.
Huonetiloilla tulee olla nimi.
Huonetilat tulee siirtää IfcSpace objekteina ja nimen siirtämiseen tulee käyttää LongName ominaisuutta.
Vaatimusten toteuttajat ymmärtävät usein tietosisällön vaatimuksen hyvin, mutta tekninen vaatimus on vieraampi ja vaikeampi toteuttaa. Hyvässä vaatimuksessa nämä kaksi komponenttia on erotettu toisistaan ja tekninen vaatimus on minimoitu.
Kuvitellaan tulevaisuuden järjestelmä, joka löytää tilan nimen mistä tahansa tilaobjektin ominaisuudesta. Kun tällainen ratkaisu on käytössä, voidaan tekninen vaatimus yksinkertaistaa muotoon: tilan nimi voidaan siirtää tilaobjektin minkä tahansa ominaisuuden avulla.
6. Toteutuminen on ohjelmallisesti tarkastettavissa
Vaatimusten toteutumisen tarkastaminen tiedonsiirron yhteydessä on olennainen osa toimivaa prosessia. Siinä tarkastetaan, että tiedon tuottanut osapuoli on tehnyt sen, mitä on luvannut. Tällä ratkaistaan myös vastuukysymykset, koska tiedon tuottajan vastuulla on toimittaa sovitunlaisia malleja ja tämän jälkeen vastuu näiden mallien hyödyntämisestä siirtyy niiden käyttäjille. Käytännössä ainoa ratkaisu on tarkastaa mallit ohjelmallisesti, koska muuten luottamus malleihin ja sen mukana niiden käyttökelpoisuus rapautuu.
Vaatimus on, että kaikilla seinillä on projektissa sovittu rakennetyyppi. Määrälaskija saa kolmannen kerran mallin, jossa puolet rakennetyypeistä puuttuu tai arvot ovat ilmiselvästi virheellisiä. Määrälaskija päättää olla hyödyntämättä tätä tietoa mallin jäsentämiseen.
Kaikkea ei kuitenkaan voi tarkastaa ja johonkin pitää luottaa. Jos esimerkiksi olisi olemassa ratkaisu, joka osaa tarkastaa rakennetyyppien oikeellisuuden, niin sama järjestelmä osaisi myös asettaa rakennetyyppitiedon oikein. Tämä taas johtaisi siihen, että rakennetyyppitietoa olisi enää turha vaatia.
7. Pystyy kehittymään
Kun vaatimusten taustat on avattu, voidaan niihin suhtautua kriittisesti ja niitä voidaan jatkuvasti kehittää. Nykyisissä ohjelmistoissa on esimerkiksi aina puutteita, jotka pitää realismin nimissä ottaa huomioon. Ei voida vaatia asioita, jotka on tällä hetkellä mahdotonta tai liian vaikeaa toteuttaa.
Viemäriputkiston kaatoja ei tarvitse mallintaa, koska kaatojen mallintaminen ei tätä vaatimusta kirjoitettaessa ole ohjelmistoteknisesti mahdollista.
Vuonna 2007 yllä oleva vaatimus oli vielä aiheellinen, mutta nykyisillä ohjelmistoilla kaadot pystytään jo mallintamaan. Kun ohjelmistot kehittyvät voidaan vaatimusta siis muuttaa, koska viemäriputkien oikea sijainti on hyödyllinen tieto esim. törmäystarkasteluissa. Jos taas alkuperäinen syy ei ole enää tiedossa, on vaikeampaa reagoida reunaehtojen muuttumiseen.
8. Ei vaadi johdetun tiedon siirtämistä
Malleissa on sekä alkuperäistä tietoa, että johdettua tietoa, ja vaatimukset pitäisi asettaa alkuperäiselle tiedolle.
Objektilla on kaksi ominaisuutta: se on seinä ja sijaitsee rakennuksen ulkovaipassa. Nämä ovat alkuperäistä tietoa. Tämän objektin Talo90 luokitus on ”1.2.4.1 Ulkoseinät”, mikä on alkuperäisestä tiedosta johdettua tietoa.
Johdettu tieto ei tuo tiedonsiirtoon mitään uutta informaatioita, joten sen siirtämistä ei tule vaatia. Periaatteessa myös määrät ja mitat ovat geometriasta johdettua tietoa, jolloin pelkän geometrian vaatiminen riittää. Jos vastaanottajan käyttämien ohjelmistojen tai osaamisen puutteiden takia kuitenkin päädytään vaatimaan johdettua tietoa, pitää tämä tehdä tietoisesti. Tarvitaan siis aina analyysi siitä, mikä tieto on alkuperäistä ja mikä johdettua.
4.4.2022
Jiri Hietanen