Tämä artikkeli on tiivistelmä ja yhteenveto uuden standardiversion teknisestä Roadmapista, tiekartasta, joka julkaistiin alun perin vuonna 2020. Sen tarkoitus oli avata konkreettiset syyt uuden version kehittämiseen ja tärkeimmät muutokset.
Syyskuussa 2023 päivitetty ladattavissa oleva Roadmap-esitys löytyy tältä sivulta.
Perustelut IFC5:n kehitykselle tutkittiin ja avattiin julkisuuteen noin viisi vuotta sitten, laaja-alaisena komiteatyönä. Syvällä standardin aiempien versioiden kehityksessä olevat eri osapuolia edustavat jäsenet koostivat pohjaksi olemassa olevia haasteita:
IFC-standardien kehitystä ohjasi pitkään Model View Definition (MVD) -konsepti. Sen määrittely toteutettiin vastaamaan johonkin tiedonsiirron käyttötapaukseen. Esimerkiksi mitä siirretään arkkitehdilta rakennesuunnittelijalle. Määrittelyn tekeminen ja se että MVD-sertifioitiin ohjelmistovalmistajien toimesta kesti esimerkiksi noin viisi vuotta. Buildingsmartin ansaintamalli oli se, että ohjelmistot kehittyvät, kun joku tapaus on määritelty ja ne haluavat sertifioitua.
Käytännössä läheskään kaikki eivät sertifioituneet, vaan ottivat konseptin käyttöön itse, osittain ja vaihtelevasti. IFC 4.x määrittely kasvoi merkittävästi aiempiin verrattuna ja siinä oli 300 dokumentoitua poikkeusta. MVD-versioita kehitettiin erillisissä työryhmissä rinnakkain, joka johti päällekkäisyyksiin ja ristiriitoihin.
IFC 4.3 -ominaisuudet on vakioitu, niin että ne ovat linjassa bsDD:n ja IFC:n välillä, lisäksi uusi Information Delivery Specification (IDS) -tiedonsiirtomäärittely ja uusi ohjelmistojen sertifiointitapa on käyttöönotettu. Uusi ”tulostaulupohjainen” sertifiointi on tuotu vanhan rinnalle skaalautuvaksi tavaksi. Se vertaa ohjelmistoa koko standardia vastaan, ja näyttää ohjelmiston sisällön tuen osa-alueittain. Sen avulla loppukäyttäjät näkevät paremmin ohjelmistojen väliset IFC-ominaisuuksien tuen erot.
Buildingsmart toivoo teollisuuden eri toimijoiden osallistuvan kehitykseen enemmän, esimerkiksi tilaajia määrittelemään tiedonsiirron kuvauksia (IDS) ja valmistajien tietosisältökirjastoja bsDD-muodoissa. Näin standardin pohja pysyy vakiona ja tapauskohtaisiin tarpeisiin räätälöinti on ketterämmin mahdollista. Luonnollisesti ohjelmistovalmistajat vastaavat IFC-, IDS- ja bsDD tuen toteuttamisesta tuotteisiinsa. Kaikki ne voivat toimia dynaamisesti. Esimerkiksi IFC-standardin kieliversiot ja valmistajien tuotetietojen sisällöt voivat toimia dynaamisesti eli ”kirjastomaisesti”. Myös ”vakioidun” standardin ulkopuolisten tuotteiden ja ratkaisujen IFC-tuen kehittäminen ketterämmin on mahdollista, vaikka alan valmistajien intressiryhmien toimesta, toki Buildingsmartia konsultoiden. Esimerkiksi Suomalainen RAVA-sisältö ei ole mukana missään virallisessa MVD-määrittelyssä. Siksi se kannattaa toteuttaa IDS-määrittelynä.
Uuden rakennuslain tietomallivaatimukseksi tulee aluksi IFC-versio 4.3.2, joka tulee olemaan ”viimeinen” tiedostopohjaiseen määrittelyyn pohjautuva IFC. Suurin käytännön ero verrattuna edeltävään 4.0-versioon on infrastruktuurin tietomallien osien (linjaukset, sillat, laiturit ja niin edelleen) ja laajemman ”digikaksos”-sisällön tuki. Käytännössä 4.3.2-version vaatimuksella siirrytään samalla parempaan rakennusaineiden ominaisuuksien siirtoon, jonka tuki eteni versiossa 4. Vaikka 4.3.2 tulee olemaan ”lajinsa viimeinen”, houkuttelevat uuden sukupolven hyödyt kehittyneemmän yhteistyön pariin.
Vaatimus Suomessa on rakentamislain tietomalliasetukseen kirjattu ”tai uudempi”, joka sallii ja kannustaa uudempien aktiiviseen käyttöönottoon. Tämä periaate on mukana myös aiemmin tehdyssä arkistolaitoksen päätöksessä.
Graphisoft on toteuttamassa 4.3.2-tuen Archicad 29 -versioon. Toisin sanoen se on ensimmäinen Archicad-versio, joka vastaa 1.1.2026 voimaan tulevan rakentamislain tietomalliasetuksen vaatimuksiin. Myös Archicad 28 -versiossa mukaan tullut IDS-standardin tuki on merkki kehitysaskeleesta, jonka sisältö ja mahdollisuudet vielä varmaan etenevät. IFC 5 -tyyppinen (Common data enviroment) CDE-yhteistyö on Archicad-käyttäjille jo arkea, tiimityön muodossa. Sen avulla voi jo tehdä monialaista yhteistyötä esimerkiksi LVIS-suunnittelijoiden kanssa. Lisäksi esimerkiksi Archicadin SAF-linkitys rakennesuunnittelijoiden lujuuslaskentaohjelmiin käyttää samoja periaatteita – toistaiseksi tiedostopohjaisesti.
Jäämme kuitenkin vielä odottamaan Graphisoftin bsDD-tukea. Käythän äänestämässä sen puolesta Graphisoftin Wishlistiin tekemääni aloitetta (vaatii kirjautumisen GSID-tunnuksella).
Lue myös nämä aiheeseen liittyvät artikkelit: