Tervetuloa Nordic BIM Group Finlandin blogiin

Yhteenveto IFC 5 -version kehityksen sisällöstä ja tilanteesta

Kirjoittanut Ville Pietilä | 04 syyskuuta 2025

Tässä on tekoälyn luoma suomenkielinen yhteenveto artikkelista “Future of the Industry Foundation Classes: towards IFC 5” (CIB W78 2021 -konferenssi):

YLEISKUVA

Raportti esittelee buildingSMARTin IFC 5 (Industry Foundation Classes -versio 5) -kehityksen tilannetta vuoden 2021 lopulla. IFC 5:n perustana on buildingSMARTin huhtikuussa 2020 julkaistu Technical Roadmap, jonka tavoitteena on modernisoida, modulisoida ja normalisoida IFC-kehikko vastaamaan uusia käyttötarpeita. IFC 5 -projektia on toteuttamassa monialainen tehtäväryhmä, joka tapaa säännöllisesti ja työskentelee intensiivisesti eri osa-alueiden parissa.

1. TAUSTA JA MOTIVAATIO

  • Nykytilanne: IFC perustuu EXPRESS-kieliseen skeemaan ja STEP/SPF-tiedostomuotoon. Tämä perinteinen "tiedosto"-rakenne ei vastaa modernien digital twin -sovellusten, reaaliaikaisten päivitysten tai AI/ML-pohjaisten työkalujen tarpeisiin. 

  • Johtopäätös: IFC-rakenne eli Skeema on vanhentunut, ja nykyaikaiset teknologiat (JSON, UML, XML, OWL) ovat paljon kehittäjäystävällisempiä. IFC 5:llä pyritään siis tekniseen modernisointiin ilman että laajennetaan semanttista sisältöä – esimerkiksi IFC 4.3:ssa ja IFC 5:ssä on sama semanttinen laajuus. 

2. MODULARISOINTI

  • Miksi modularisointi?: IFC-arkkitehtuuri sekä ylläpitokäytänteet ovat monimutkaisia, ja MVD (Model View Definition) -rakenteet ovat jäykkiä. Modulaarinen rakenne helpottaa hallintaa ja mahdollistaa päivitykset riippumatta semanttisista muutoksista.

  • Late binding: Uusi rakenne pohjautuu "late binding" -periaatteeseen, jossa perusydin (shared base) on vakaa ja moduuleina tulevat laajennukset liitettäviä. Tämä auttaa yhdenmukaistamaan tietomallin eri sovellusten välillä ja tukee API-pohjaista käyttöä. 

3. HIERARKIAN (PRODUCT TREE) NORMALISOINTI

  • Hierarkia uudistuu: IFC-taksonomia normalisoidaan niin, että tuotteet (IfcProduct) jaetaan selkeämmin esimerkiksi IfcElement, IfcSpatialElement ja IfcFeatureElement -luokkiin. Tämä helpottaa vanhempien ja uusien versioiden yhteiskäyttöä.

  • Tyyppien pakollisuus: Jatkossa elementillä on aina oma tyyppi (IfcElementType), mikä vähentää päällekkäisyyksiä ja poistaa tarpeen PredefinedType-attribuutille. Tämä yksinkertaistaa skeemaa merkittävästi ja poistaa redundanssia.

4. RELAATIOIDEN (RELATIONS) YKSINKERTAISTAMINEN

  • Relaatiomallin analysointi IFC 4.3:n relaatioluokkien osalta osoitti, että monet niistä ovat redundansseja tai eroavat vain suhteiden tyypin perusteella. Tarkoituksena on yhdistää tai yksinkertaistaa näitä luokkia niiltä osin kuin semanttisia eroja ei ole.

  • Missä mahdollista, objektirakenteisia (objectified) relaatioluokkia muutetaan tavallisiksi attribuuteiksi. Tämä koskee kuitenkin vain binäärisiä suhteita, joissa ei ole lisäattribuutteja. 

  • Relaatioiden navigoitavuus ja rakenne (esimerkiksi hierarkia vs. verkko) selkeytetään: halutaan, että tietyt suhteet muodostavat puumaisen rakenteen, navigoitavuus on selkeä ja risteäviä silmukoita (circuits) ei synny.

5. YLLÄPITO JA LAADUN VARMISTUS

  • GitHub-pohjainen hallinta: UML-luokkadiagrammit, markdown-dokumentaatio ja mvdXML-tiedostot hallinnoidaan GitHubissa. Muutokset tehdään pull requestien kautta, ja automaattiset laaduntarkistukset (GitHub Actions + Python-skriptit) generoivat EXPRESS-scheman, HTML-diagrammit ja niin edelleen.

  • Prosessi takaa avoimuuden ja jäljitettävyyden: kuka ehdotti muutoksen, syy hyväksymiselle/hylkäykselle ja automatisoidut testiraportit ovat nähtävissä.

6. MUIHIN KEHITYSKOHTEISIIN LIITTYVIÄ ALOITTEITA

  • Kyselykieli (query language) ja API-kehitys ovat tavoitteena, mutta käytännön toteutus siirtynee 2–3 vuoden aikajaksolle. Tässä IFC 5:n rakenteellinen modernisointi on edellytys.

  • bSDD-Dictionary ja IDS: buildingSMART Data Dictionary (bSDD) uudistettiin 2020 ja lanseerattiin kesällä 2021. Se toimii luokkien ja attribuuttien URI-tietolähteenä REST GraphQL-rajapintojen kautta. IDS-standardilla (Information Delivery Specification) määritellään, mitä tietoa tietyssä kontekstissa tulee vaihtaa IFC:n avulla.

  • Kontainerimuodot: Tutkitaan JSON-, JSON-LD, binäärisiä (HDF5) ja muita uusia tapoja serialisoida IFC. Nämä kokeilut tukevat digital twin -konseptia ja tehokasta datansiirtoa.

7. PÄÄTELMÄ JA KESKUSTELU

  • IFC 5 -kehitys osoittaa, että modernisointi on teknisesti mahdollista ja tarpeellinen avoimen BIM-ekosysteemin kehittämiseksi.

  • Avoimia kysymyksiä on vielä paljon: miten late-bound-lohko toimii oikeassa käytössä, miten varmistetaan yhteensopivuus eri moduulien välillä ja miten säilytetään interoperabiliteetti. Artikkeli onkin avoin kutsu akateemiselle ja teolliselle yhteistyölle eri osa-alueiden jatkokehittämiseksi.

YHTEENVETO AVAINKOHDISTA

  • IFC 5 on tekninen modernisointi ilman semanttista laajuuden laajentamista.

  • Modularisointi ja late-binding-arkkitehtuuri mahdollistaavat joustavan kehityksen ja paremman yhteensopivuuden.

  • Tyypit (IfcElementType) tehdään pakollisiksi, mikä yksinkertaistaa skeemaa.

  • Relaatioita yhdistellään ja yksinkertaistetaan tarpeettoman monimutkaisuuden vähentämiseksi.

  • Ylläpito GitHub-pohjaisesti avoimin ja automaattisesti validoiden takaa laadun ja mahdollistaa laajemman osallistumisen.

  • Tulevaisuuden työkalut (API, kyselykieli, uudet serialisointimuodot) perustuvat näihin IFC 5:n teknisiin muutoksiin.

Lue koko artikkeli (englanniksi) täältä: Future of the Industry Foundation Classes: towards IFC 5