¶ Väylämäisen kohteen tiedonsiirron määritys
Julkaistu 14.2.2025
Lopputuotteina projektista valmistuivat IFC tiedonsiirtomenetelmän dokumentaatio, käyttötapauskuvaukset valituista käyttötapauksista sekä Saate, missä kuvattiin mm. projektin päätelmät ja suositukset jatkokehitykselle sekä IFC:n lokalisoinnin toteutustavat.
Projektin lopputuotteina syntyivät seuraavat aineistot:
¶ IFC tiedonvaihdon vaatimusten dokumentaatio
IFC tiedonvaihdon vaatimusten dokumentaatio - IFC-Route (Englanniksi)
¶ Käyttötapauskuvaukset
- Tiedonsiirto suunnittelusta rakentamiseen
- Määrälaskenta
- Tiedonsiirto tilaajan järjestelmiin (rajaus rakentamisen aikaiseen/jälkeiseen aikaan)
¶ Wiki-artikkeli projektista
kts. seuraava kappale, Saate.
¶ Saate
¶ Väylämäisen kohteen IFC-tiedonsiirron taustat
Suomessa laajalti käytössä oleva LandXML-pohjainen (Inframodel) tiedonsiirtomenetelmä on kuvauskyvyltään rajoittunut, eikä mahdollista väylämäisten kohteiden edistyneiden ominaisuuksien tiedonsiirtoa. Tästä syystä suuri määrä tietoa siirtyy edelleen erilaisten piirustusten, taulukoiden ja muiden dokumenttien välityksellä.
IFC 4.3 tarjoaa toisaalta liian monipuolisen kuvauskyvyn (mallin rakenne, geometria, ominaisuustiedot), jotta sitä voitaisiin suoraan hyödyntää vakioidusti. Projektissa tehty dokumentaatio määrittää sen vähimmäistason IFC 4.3 -toiminnallisuuksille, jotka kattavat valitut tiedonsiirtotapaukset. Siirtyminen IFC-pohjaiseen tiedonsiirtoon mahdollistaisi koneluettavan, ominaisuuksiltaan rikkaan tiedonvaihdon.
Projektin tavoitteena oli määrittää väylämäisten kohteiden tiedonsiirron tarpeet, rajaten määrittelytyö kuitenkin tie- ja katumalleihin. Työn aikana rajauksia tarkennettiin ja esimerkiksi pohjanvahvistukset, varusteet, ajoratamaalaukset ja rakenteet kuten hidastustöyssyt rajattiin työn ulkopuolelle.
Tiedonsiirron käyttötapauksia projektiin valittiin kolme:
- Tiedonsiirto suunnittelusta rakentamiseen
- Määrälaskenta
- Tiedonsiirto tilaajan järjestelmiin (rajaus rakentamisen aikaiseen/jälkeiseen aikaan)
Linkki projektin GitHub repositoryyn: https://github.com/buildingSMART-Finland/RYTV-IFCRoute
¶ Projektin sisältö
Projektissa määritettiin IFC 4.3 muotoinen tiedonsiirto, joka dokumentoitiin rajatuissa käyttötapauksissa. Dokumentaatio määrittää valittujen käyttötapausten tiedonvaihdon IFC 4.3 -muodossa. Työn aikana määriteltiin tarvittavat perustiedot, geometria, rakenteet ja ominaisuustiedot käyttötapauksista, jotka verrattiin IFC4.3 standardiin. Työn perustana toimi Inframodel määritykset, yleiset inframallivaatimukset ja valittujen tilaajaorganisaatioiden tiedonsiirron vaatimukset, joille haettiin vastineet IFC standardista suomalaisten infra-alan vaatimusten mukaisesti.
Projektissa ei tavoiteltu varsinaista julkaistavaa standardia vaan pohjatyötä tulevaa standardointityötä ajatellen keskittyen rajattuihin käyttötapauksiin ja Inframodel (LandXML) – IFC vertailuun.
Tässä projektissa tehtiin useita keskeisiä määrittelyjä ja selvennyksiä. Projektin aikana kuvattiin Infratoimialan ensimmäiset käyttötapaukset, joten aluksi oli kuvattava perusasiat ja tekniset määritykset kuntoon, että varsinaisten käyttötapausten määrittäminen onnistuisi. Perusasioilla tarkoitetaan vakioitua IFC rakennetta sekä yleisiä projektia käsittäviä tietoja, kuten IFC File structure, File Headers ja ifcProject sekä Classification. Lisäksi suunniteltiin dokumentaation rakenne ja määritysten kuvaustapa, tämä dokumentaatio toimii jatkossa perustana työn jatkamiselle ja IFC4.3 lokalisoinnille Suomeen.
Työssä selvennettiin käyttötapausten tiedonvaihdon geometrista ja tietosisällöllistä esitystapaa, hierarkiaa ja relaatioita joiden perusteella määritettiin vakioitu IFC-rakenne (kts. kuva alla).
Tiedonvaihtomääritysten kuvaamiseksi määriteltiin Englanninkielinen tekstimuotoinen dokumentaatio, joka sisältää UML ER-kaavioita, taulukoita sekä esimerkkikuvia, jotka koostetaan pdf dokumentiksi dokumenttiautomaatiolla Githubista. Tämä dokumentaatio kuvastaa valittujen käyttötapausten tiedonvaihdon sisältöä ja vaatimuksia.
Dokumentaatiota tarkentaa Suomenkieliset käyttötapauskuvaukset jokaisesta kolmesta käyttötapauksesta.
¶ Projektin aikaiset huomiot ja kehitystarpeet
Projektissa havaittiin useita kehityskohteita. Laajempi IFC määritys ja dokumentaatio vaatii pitkäjänteistä ja keskeytyksetöntä kehittämistä ja työskentelyä sekä rakennusalan laajaa osallistamista. Haasteena on nykyiset toimintatavat ja määritykset, IFC nykyistä tiedonsiirtoa rikkaampi tiedonsiirto sekä ovat nykyiset standardointi- ja dokumentointiprosessit, jotka eivät ole jatkuvia ja vakioituja vaan projektikohtaisia ja projektiluonteisia. Lisäksi havaittiin, että laajojen käyttötapausten pilkkominen pienemmiksi olisi suositeltavaa. Tämä vaatii riittävän laajan pohjatyön ja määrittelyn sekä valmiin perusmäärityksen, mitä käyttötapauksilla lähdetään tarkentamaan. Toisaalta taas liian pieniksi pilkotut käyttötapaukset eivät ole aina optimaalinen lähestymistapa, mikäli määritettävä asia liittyy isompaan kokonaisuuteen, jonka osia puuttuu, on määrittämättä tai ei ole rajattu selkeästi. Tämä johtaa helposti projektin laajenemiseen, koska määrittelyä ja selvitystä voidaan joutua tekemään huomattavasti enemmän, kun käyttötapaukseen kuvitellaan kuuluvan.
Tässä projektissa luotiin perusta kuntoon mm. perusasioiden tekniset määritykset, IFC rakenne ja määrittelyn logiikka, sekä valittujen tiedonvaihdon “perus” käyttötapausten vaatimukset. Tämä mahdollistaa tulevaisuudessa IFC muotoisen tiedonsiirron määrittelyn ja ketterämmin ja vakioidusti.
Tärkeimmät nostot ja huomiot:
- Lähtökohtaisesti kaikki määritys tulisi saada koneluettavaan ja ymmärrettävään muotoon, pois lukien ihmiselle ja kehittäjälle tarkoitettu tekstimäinen kuvaava sisältö. Tarvitaan jokin tietokantamuotoinen teknologia eri käyttötapausten vaatimien tietosisältöjen ja geometristen esitysmuotojen hallitsemiseen, kuvaamiseen ja jakamiseen.
- Tämä mahdollistaa tiedonsiirron määritysten ja dokumentaation tuottamisen koneluettavasti ja esimerkiksi tietosisältövaatimusten “tulostamisen” järjestelmästä esimerkiksi excel taulukkoon, bSDD tietokantaan tai IDS tiedostoon.
- Lisäksi eri asioiden relaatiot ja vaikkapa UML tai BPMN tyyppiset kuvaajat on helpommin toteutettavissa kantamuotoisesta aineistosta.
- Määritysten visualisointia tulee parantaa esimerkiksi käyttötapauskohtaisten UML-kaavioiden ja selkeiden hierarkioiden sekä havainnollistavien kuvien avulla.
- Varsinkin kuvat koettiin haastaviksi ja ehdotuksena seuraaviin projekteihin on graafikon ottaminen mukaan laadukkaiden kuvien tuottamisen tueksi.
- Ohjelmistotoimittajien kanssa tulee tehdä tiivistä yhteistyötä parhaan käytännön löytämiseksi.
- Julkaisujärjestelmän kehittäminen tukemaan standardointityötä, tiedonvaihdon käyttötapausten määritystä sekä julkaisuja.
- Käyttötapausten tuottaminen dokumenttiautomaation avulla. Tässä projektissa käyttötapaukset olivat irrallinen oma osa kokonaisuutta, eikä esimerkiksi käyttötapauskohtaisten propertysettien tulostaminen taulukkomaisesti käyttötapausdokumenttiin onnistunut. Kokemukset, opit ja tiedot tämän projektin teknisistä tarpeista on viety tiedoksi Julkaisualustan kehittäminen osa A projektille.
- Luokittelu ja nimikkeistöjärjestelmien puutteet ja yhteentoimivuus määrittelyiden kanssa
- IFC dokumentaatio on osittain sekava, hankalasti tulkittava ja laaja. Haasteeksi tunnistettiin mm. käyttöohjeen puuttuminen, lokalisoinnin toteuttaminen ja määrittäminen.
- Näin IFC toimii tyyppisen ohjeen puuttuminen koettiin haasteeksi ja tämän tekeminen olisi erittäin suositeltavaa bSI toimesta.
- Lisäksi tarvittaisiin Suomenkielinen kansantajuinen ja ymmärrettävä käyttöohje ja johdanto IFC käyttämiseen.
- UML kaaviot ja kuvat avaa todella paljon ja selkeyttää IFC kehittämistä ja käyttöönottoa sekä lokalisointia.
- Näin IFC toimii tyyppisen ohjeen puuttuminen koettiin haasteeksi ja tämän tekeminen olisi erittäin suositeltavaa bSI toimesta.
- Erillisen dokumentaation kehittämistä ja ylläpitämistä IFC tiedonsiirtomenetelmän lokalisoinnista ei olisi optimaalista, mutta toisaalta nykyinen IFC dokumentaatio ja teknologiat ei mahdollista tämän toteuttamista, vaan käytännössä lokalisointia varten tarvitaan erinäisiä teknisiä määrityksiä ohjelmistokehittäjille sekä käyttäjille. Tämän ratkaisua ja toteuttamista tulee miettiä bSI ja bSF tasolla.
- Miten lokalisointi ja tämän dokumentointi olisi järkevintä toteuttaa? esim. bSDD tai IDS ei ratkaise kokonaisuutta, mutta toimivat työkaluina täydentämään vaatimusmäärittelyitä ja näiden jakamista.
- Pelkkä tietosisältöjen määrittäminen lokaalisti ei riitä, tarvitaan myös esitystavan ja rakenteen lokalistointia, enumeraatioita jne.
- Lokalisoinnin määritys tulee saada koneluettavaan muotoon ja lokaalin toimijan hallinnoitavaksi (esim buildingSMART Chapter, tilaajaorganisaatio tms.). Tämän hallintaan ja vaatimusten tuottamiseen tarvitaan työkalu ja tietokanta. Toki master kannasta voidaan jakaa määrityksiä bSDD tai IDS menetelmillä, joka on suotavaa, mutta nämä eivät sovellu suoraan vaatimusmäärittelyiden ylläpitämiseen.
- UCM mahdollistaa käyttötapausten kuvaamisen, mutta tämä on irrallinen käyttötapauskuvaus, ei järkevä tapa kuvata esim. Inframodel määrittelyiden laajuista lokalisointia.
- Miten lokalisointi ja tämän dokumentointi olisi järkevintä toteuttaa? esim. bSDD tai IDS ei ratkaise kokonaisuutta, mutta toimivat työkaluina täydentämään vaatimusmäärittelyitä ja näiden jakamista.
- Joitain havaintoja ja nostoja IFC 4.3 tiedonsiirtomenetelmän dokumentaatiosta
- Onko linkit ja viittaukset pysyviä, voidaanko viitata luotettavasti?
- Onko IFC4.3 määrityksissä huomioitu Infratoimialan erityistarpeet ja yhteentoimivuus tai päällekkäisyys?
- IFCMaterial käyttö ei luontevaa ja selkeää, enumeraatiot vajaita ja toimivuus ei käyttökelpoinen. → tämä melkein kannustaa määrittämään eri tyyppisiä materiaalitietoa Propertyseteillä.
¶ Jatkotoimenpiteet
Laajempi IFC määritystyö Suomessa ja sen dokumentaatio vaatii pitkäjänteistä ja keskeytyksetöntä kehittämistä ja työskentelyä sekä rakennusalan laajaa osallistamista. Haasteena on nykyiset toimintatavat ja määritykset. IFC on nykyistä tiedonsiirtoa rikkaampi formaatti ja mahdollistaa todella paljon uusia käyttötapauksia. Lisäksi nykyiset standardointi- ja dokumentointiprosessit , jotka eivät ole jatkuvia ja vakioituja vaan projektikohtaisia ja projektiluonteisia, rajoittavat ja hidastavat kehitystä. Tiedonsiirron kehittämiseen liittyen puuttuu selkeä visio ja tahtotila, mitä kehittämisellä tavoitellaan. Myös tarkemmin määritelty kehityspolku vaiheistuksineen, ns. tiekartta tukisi suunnitelmallista kehittämistä ja uusien toiminnallisuuksien käyttöönottoa. Tämä kehittäminen luonnolisesti vaatii kestävän ja kestävän rahoituksen sekä tekijöitä ja alan sitoutumisen kehittämiseen. IFC laajan käyttöönoton ajankohtaa on hankala arvioida, työ vaatii käytännössä tuhansia tunteja asiantuntijatyötä, vakiointia tukevan politiikan, työkalut sekä tavoitteen.
Tulevaisuudessa kaikki tiedonvaihtomääritykset, vaatimukset, ohjeet ja muu dokumentaatio tulisi olla ylläpidettävissä ja jaettavissa yhdessä paikassa yhtenä kokonaisuutena, josta voidaan tarkastella haluttuja tai valittuja näkymiä. Tietosisällön ja geometrisen esitystavan määritykset ja vaatimukset on oltava saavutettavissa avoimesti koneluettavassa ja -ymmärrettävässä muodossa, että näitä vasten voidaan validoida tietoa tiedontuottamisen ja -siirtämisen prosessin aikana sekä muissa tiedonvaihtopisteissä. Tässä tiedon jakamisessa menetelmät, kuten bSDD ja IDS toiminevat hyvin. Kokonaisuuden hallintaan tarvitaan työkalut sekä menetelmät, eli vakioitu prosessi sekä teknologia, minkä avulla kokonaisuutta kehitetään, sisältöä tuotetaan, hallinnoidaan ja jaetaan käyttäjille. Tähän tarvitaan julkaisukokonaisuuden hallinnan teknologia ja prosessi, mistä tietoa voidaan jakaa ihmisluettavasti käyttäjille ja koneluettavasti teknologialle. Käytännössä tarvitaan tietokanta, mitä ylläpidetään, ja mistä esimerkiksi dokumenttiautomaatiolle saadaan syötteeksi geometrian tai ominaisuustietojen vaatimuksia taulukkomuotoisessa ihmisluettavassa esitystavassa.
Selvitettäviä ja määritettäviä asioita, sekä näihin liittyvää prosessia, soveltamislogiikkaa, omistajuutta, käyttötapauksia ja pelisääntöjä tulee miettiä seuraavista asioista vähintään buildingSMART Finland tasolla:
- Tavoitteet ja suunnitelmallinen kehittäminen
- Mitä tavoitellaan, millä aikataululla, mistä eri tehtäväpaketeista ja kokonaisuuksista työ koostuu, rahoituksen varmistaminen jne.
- buildingSMART International teknologiat ja määritykset
- bSDD - buildingSMART Data Dictionary, IDS - Information Delivery Specification, UCM - Use Case Management, IFC tiedonvaihdon dokumentaatio
- Miten näihin liittyvä lokalisointi, soveltaminen, pelisäännöt, omistajuus ja käyttö toteutetaan suomessa?
- Mihin näitä käytetään ja näiden käytön rajaukset, miten lokalisointi toteutetaan?
- “Näin IFC toimii” ohjeistus
- Tarvitaan Suomenkielinen kansantajuinen ja ymmärrettävä käyttöohje ja johdanto IFC käyttämiseen.
- Nimikkeistö- ja luokittelujärjestelmien kehittäminen sekä kansalliset linjaukset käyttöön liittyen (Esim. Terrain coding, Surface Coding, Infra Coding jne.)
- IFC lokalisoinnin, nimikkeistöjen, tietosisältövaatimusten hallintaan, kehittämiseen ja jakamiseen vakioitu ja yhteisessä käytössä oleva työkalu ja järjestelmä.
Käyttötapauskuvaukset ovat oma kokonaisuus, minkä rajaamista, määrittelyä, tekemistä ja jakamista tulee miettiä tarkemmin. Käyttötapauskuvaus dokumenttimuotoisena on irrallinen käsin työstettävä aineisto, joka olisi toteutettavissa dokumenttiautomaation avulla muun määrityksen ja vakioinnin yhteydessä. Projektissa tunnistettiin käyttötapauskuvausten irrallisuus, jota tulee jatkossa miettiä.
¶ Projektiryhmä
Juuso Virrankuja, Sitowise (pp.)
Jari Kainuvaara, Sitowise
Juha Hyvärinen, JHy Consulting
Mikko Vesanen, Novatron
Niki Tapper, Ramboll
Timo Pitkänen, Arkance
Juha Liukas, Sitowise (laadunvarmistus)