Tiedonsiirron käyttötapaus: Määrätiedon siirto

Transkriptio

1 Tiedonsiirron käyttötapaus: Tiedonsiirron käyttötapaus: Tiedonsiirron käyttötapaus Tunnistettu käytännön tiedonsiirron tarve Tiedonsiirron yksityiskohtainen dokumentointi Tiedonsiirron standardin (IFC) soveltaminen Ohjeistuksena toteutuksille ja ja käytäntöön Osapuoli Määrälaskenta (Lähettäjä) Määrät Osapuoli Kustannuslaskenta (Vastaanottaja) Määrittelee tiedonsiirron tietosisällön ja toteutuksen Sovellus X Sovellus X Sovellus Y Sovellus Y KKa Projekti Pro IT Rakennusteollisuus RT Dokumentin nimi Tiedonsiirron käyttötapaus: Dokumentin versio.0 Kirjoittaja Kari Karstila & Kalle Serén / Eurostepsys Oy Julkisuus Julkinen ProIT_DEXUC_Maaratieto_Versio_0_ doc

2 Tiedonsiirron käyttötapaus: 2 OSA KÄYTTÖTAPAUKSEN KUVAUS: PERUSTEET JA TIETOSISÄLTÖ... 3 JOHDANTO YLEISTÄ DOKUMENTIN SISÄLTÖ PERUSTEET KÄYTTÖTAPAUKSEN NIMI JA KOHDEALUE RAJAUS Tiedonsiirron tarkoitus ja karkea tietosisältö Osapuolet ja sovellukset Käyttötapauksen alatapaukset LIITTYMINEN RAKENNUSPROSESSIIN LÄHTÖOLETUKSET TIETOSISÄLTÖ MÄÄRÄTIEDON KOHTEIDEN RYHMITTELY MÄÄRÄTIEDON KOHTEET MÄÄRÄ JA MÄÄRÄN MITTAYKSIKKÖ MÄÄRIEN SIJAINTI MÄÄRÄTIEDON KOHTEEN LISÄTIEDOT KÄYTÄNNÖN TIEDONSIIRTOJEN TIETOSISÄLLÖN RAJAUKSEN KUVAUS... 0 OSA 2 KÄYTTÖTAPAUKSEN TOTEUTUS: IFC-TOTEUTUS... JOHDANTO TIEDONSIIRRON IFC-TOTEUTUS IFC-TUOTEMALLIN MINIMISISÄLTÖ IFC-tuotemallin minimisisältö summaamattoman määrätiedon tapauksessa IFC-tuotemallin minimisisältö summatun määrätiedon tapauksessa MÄÄRÄTIEDON TOTEUTUS IFC-LUOKILLA KÄYTTÖTAPAUKSEN IFC-ASPEKTIT IFC-TIEDONSIIRRON FORMAATIT... 6 VIITTEET... 7 LIITE. LYHYT SANASTO... 8 LIITE 2. TIEDONSIIRRON TIETOSISÄLLÖN KUVAUKSEN LYHYT TARKISTUSLISTA... 2 LIITE 3. TIEDONSIIRRON TOTEUTUKSEN LYHYT TARKISTUSLISTA LIITE 4. TIEDONSIIRRON KÄYTTÖTAPAUKSEN IFC-TOTEUTUKSEN IFC- ASPEKTIKORTIT ProIT_DEXUC_Maaratieto_Versio_0_ doc

3 Tiedonsiirron käyttötapaus: 3 Osa Käyttötapauksen kuvaus: Perusteet ja tietosisältö ProIT_DEXUC_Maaratieto_Versio_0_ doc

4 Tiedonsiirron käyttötapaus: 4 Johdanto Tämä dokumentti on tiedonsiirron käyttötapauksen määrittely (spesifikaatio) määrätiedon siirrolle yleisellä tasolla. Tämä tiedonsiirron käyttötapaus koskee erityisesti digitaalisen tuotetiedon siirtoa tietokonesovellusten kesken.. Yleistä Tiedonsiirron käyttötapaus (lyh. käyttötapaus) on tunnistettu käytännön tiedonsiirron tarve, esimerkiksi rakennushankkeissa, jonka tiedonsiirron vaatimukset ja toteutus on yksityiskohtaisesti dokumentoitu (kuva ). Käyttötapauksen käytännön tiedonsiirrot tapahtuvat rakennushankkeissa, niiden osapuolien ja heidän tietokonesovellustensa välillä. Tiedonsiirron käyttötapaus Tunnistettu käytännön tiedonsiirron tarve Tiedonsiirron yksityiskohtainen dokumentointi Tiedonsiirron standardin (IFC) soveltaminen Ohjeistuksena toteutuksille ja ja käytäntöön Osapuoli Määrälaskenta (Lähettäjä) Määrät Osapuoli Kustannuslaskenta (Vastaanottaja) Määrittelee tiedonsiirron tietosisällön ja toteutuksen Sovellus X Sovellus X Sovellus Y Sovellus Y KKa Kuva. Tiedonsiirron käyttötapaus. Käyttötapauksen spesifikaation tarkoituksena on toisaalta toimia ohjeena tiedonsiirron käyttötapauksen toteutuksille sovelluksissa, sekä toisaalta rakennushankkeiden käyttötapauksen käytännön tiedonsiirtoja varten määritellä käyttötapauksen rajaus ja vaatimukset sekä siirrettävät tiedot..3 Dokumentin sisältö Dokumentti kuvaa käyttötapauksen tarkoituksen, rajauksen ja lähtöoletukset, sekä määrittelee käyttötapauksessa siirrettävät tiedot tiedonsiirron toteutuksesta riippumattomassa muodossa. Lisäksi dokumentti kuvaa käyttötapauksen mukaisen tiedonsiirron toteutuksen IFC-tiedonsiirron standardia käyttäen. Dokumentti on jaettu kahteen osaan. Osa koskee käyttötapauksen perusteita, määrittelyä ja tietosisältöä yleisesti, ilman tiedonsiirron toteutustapaa. Osan tarkoituksena on antaa ProIT_DEXUC_Maaratieto_Versio_0_ doc

5 Tiedonsiirron käyttötapaus: 5 yleiskuva käyttötapauksesta ja Osa on siten suunnattu sekä ohjelmistokehittäjille että käyttäjille. Osa 2 kuvaa käyttötapauksen toteutuksen IFC-spesifikaatiota käyttäen. Tämä toteutus perustuu kesällä 2004 julkaistuun versioon IFC 2x2 Addendum []. Osa 2 on tarkoitettu lähinnä ohjelmistototeuttajia varten. Tähän dokumenttiin suoraan liittyvää viitemateriaalia, tai muuten aihetta sivuavaa dokumentaatiota ovat: ProIT Arkkitehdin tuotemallisuunnittelu Yleiset perusteet ja ohjeita, joka antaa kuvaa rakennussuunnittelun tuotemallinnuksen yleisiä periaatteita ja antaa mallinnusohjeita sekä määrittelee tiloille käytettävät nimikkeet, tyyppitunnukset [2]. ProIT Rakennetyyppikirjasto, joka määrittelee eri rakennusosille joukon yleisesti käytettyjä rakennetyyppejä ja niiden nimikkeet [3]. ProIT Rakennetyyppikirjasto, joka määrittelee eri rakennusosille joukon yleisesti käytettyjä rakennetyyppejä ja niiden nimikkeet [4]. IFC Aspect card library, joka kuvaa IFC-tuotetietomallin osittelun aspekteihin, joita hyödynnetään tiedonsiirron käyttötapausten IFC-toteutuksessa [7]. Talo 2000-nimikkeistö, joka määrittelee Talo 2000-luokitusjärjestelmän, sisältyy viitteeseen [8]. CAD-toimittajien ohjelmistokohtainen IFC-ohjeistus tuotemallintamisesta ja IFCtiedonsiirrosta. Ainakin seuraaviin sovelluksiin löytyy IFC-ohjeistusta: ArchiCAD [9] ja AutoCAD ADT [0]. Suunnittelijan määrälaskentaa palvelevien tyyppirakenteiden määrittely [], jossa on kuvattu eri rakennusosien määrälaskennan lähtötietoina käytettyjä mittatietoja sekä määrälaskennan sääntöjä ProIT_DEXUC_Maaratieto_Versio_0_ doc

6 Tiedonsiirron käyttötapaus: 6 2 Perusteet 2. Käyttötapauksen nimi ja kohdealue Tämän tiedonsiirron käyttötapauksen nimi on. Käyttötapauksen tarkoituksena on määritellä yleisellä tasolla määrätiedon siirtoa, jota voidaan soveltaa tiloja, rakennusosia tai laiteosia koskevan määrätiedon siirtoon. Käyttötapauksen mukaiset tiedonsiirrot voi toistua käytännön hankkeissa eri karkeustason tiedoilla, hankkeen eri vaiheissa. 2.2 Rajaus 2.2. Tiedonsiirron tarkoitus ja karkea tietosisältö Käyttötapauksen tarkoituksena on siirtää määrätietoa määrätiedon tuottavasta toiminnosta, esim. suunnittelusta tai määrälaskennasta, määrätietoa hyödyntävään toimintoon, kuten kustannusarviointiin tai tarjouslaskentaan. Tässä yhteydessä on tarpeen määritellä määrätieto: Tilojen, rakennus- ja laiteosien määrätieto tarkoittaa yksittäisistä olioista ja niiden ominaisuuksista (esim. muodosta) johdettuja määrää kuvaavia tietoja, joita myös usein summataan yli saman tyypin (esim. rakennetyypin) omaavien olioiden. Esimerkkejä määrätiedosta oavt tietyn rakennetyypin omaavien seinien yhteenlaskettu pinta-ala, tietyn tyyppisen ilmastointikanavan yhteenlaskettu pituus, tietyn tyyppisen sähköpäätelaitteen kappalemäärä, jne. Rakennushankkeissa määrätietoa siirretään eri osapuolien kesken, eri tarkoituksiin, hankkeen eri vaiheissa. Eri määrätiedon siirroilla on kuitenkin siinä määrin yhtenevät tietotarpeet tai määrätiedon elementit, että määrätiedon siirron käyttötapaus määritellään tässä yleisellä tasolla. Myös määrätiedon siirtojen erityistarpeiden huomioonottamisen periaate määritellään käyttötapauksessa. Määrätiedon siirron tietosisällön keskeiset elementit ovat: määrätiedon kohteen (tila-, rakennusosa-, laite- tms. tyyppi) tunnistaminen ja luokittelu (nimike), kohdetta koskeva määrä ja sen yksikkö, määrätietojen ryhmittely sekä valinnaisesti määrän sijainti. Lisäksi määrätietoon voi liittyä tapauskohtaista ominaisuustietoa, joka riippuu määrätiedon kohteen tyypistä. Esimerkki tällaisesta ominaisuustiedosta on LVI-määrätiedon tapauksessa kanavien eristeen paksuus, laiteosien (asennus)korkeusasema. Käyttötapaus ei määrittele tiedonsiirtoa koskevia sopimusoikeudellisia, vastuu- yms. asioita. Niistä on sovittava erikseen. Aihetta koskevia yleisiä ohjeita ollaan kehittämässä toisaalla. Rakennushankkeiden tiedonhallinnasta ja tiedonsiirrosta voidaan ja tulisi sopia ja antaa tarkennettua ohjeistusta myös hankekohtaisissa ICT-ohjeissa ProIT_DEXUC_Maaratieto_Versio_0_ doc

7 Tiedonsiirron käyttötapaus: Osapuolet ja sovellukset Tiedonsiirron käyttötapauksen osapuolina ja sovelluksina ovat tyypillisesti (kuva 2): Tiedon lähettäjä: Suunnittelu tai toteutuksen suunnittelu, joka automaattisesti tuotemallista tai määrälaskennan kautta tuottaa tiloja, rakennus- tai laiteosia koskevaa määrätietoa. Tiedon vastaanottaja: Määrätietoa hyödyntävä toiminto, kuten kustannusarviointi, tarjouslaskenta, tms. Selitykset: Rooli (Osapuoli) Suunnittelija / Toteuttaja Määrälaskenta Toiminto Sovellustyyppi Tietosisältö CAD / Määrälaskentasovellus Rakennusosien määrät Laiteosien määrät Toteuttaja Määrätiedon käyttö Kustannusarviointi / Tarjouslaskenta /... KKa Kuva 2. Tiedonsiirron käyttötapauksen osapuolet, toiminnot ja sovellustyypit Käyttötapauksen alatapaukset Tiedonsiirron käyttötapaus jakaantuu kahteen alatapaukseen, jotka ovat: Summaamattoman määrätiedon siirto, jossa johdettua määrätietoa siirretään liitettynä rakennuksen tuotemallin yksittäisiin tila-, rakennus- tai laiteosa tms. olioihin. Tässä tapauksessa voi olla kysymys esimerkiksi rakennusosan 3D-muodosta johdetun pinta-ala tai tilavuustiedon liittäminen määrätietona olioon, jota vastaanottava sovellus voi hyödyntää ilman, että sen tarvitsee tulkita 3D-geometriatietoa. Tapauksessa voi siirtyä rakennuksen tuotemalli olioineen, ja niihin liitettyine määrätietoineen. Summatun määrätiedon siirto, jossa siirrettävä määrätieto on summattu per tila-, rakennus- tai laiteosatyyppi, eikä yksikkäisiä olioita siirretä. Huomautus: Tässä tapauksessa siirretään vain tyyppikohtaista määrätietoa, ei niinkään rakennuksen tuotemallin kaikkia yksittäisiä tila-, rakennus- ja laiteosa-olioita ProIT_DEXUC_Maaratieto_Versio_0_ doc

8 Tiedonsiirron käyttötapaus: Liittyminen rakennusprosessiin Tiedonsiirron käyttötapauksen identifiointiin rakennusprosessissa käytetään tässä Pro ITprosessimallia [5], joka yleisellä, toteutusmuodosta riippumattomalla tavalla mallintaa rakennushankkeen prosessin aina hankesuunnittelusta rakennuksen käyttöön ja ylläpitoon. Päänäkökulma ProIT-prosessimallissa on rakennusprosessin toimintojen ja niiden välisten tietovirtojen kuvaaminen. Koska tämä tiedonsiirron käyttötapaus on määritelty yleisellä tasolla, käyttötapausta vaikea yksityiskohtaisesti asemoida Pro IT:n prosessimallissa. Kuitenkin, eniten määrätiedon siirtoa prosessissa tapahtuu rakennuksen suunnittelun ja työmaatoteutuksen valmistelun toiminnoissa, mikä on ilmaistu kuvassa 3. A0 Suunnittele, toteuta, käytä ja ylläpidä rakennus A Johda hanke A2 Tee asiakas- päätökset, ja hallitse asiakas- ja viranomaisvaatimukset A3 Suunnittele rakennus, ja valmistele työmaatoteutus A3 Koordinoi rakennuksen suunnittelu sekä tuoteosien ja järjestelmien suunnittelu A32 Kehitä ja analysoi vaihtoehtoratkaisut A33 Tee tarkentuva suunnittelu A34 Valmistele työmaatoteutus A35 Valvo toteutuksen suunnitelmien- mukaisuus A4 Suunnittele ja valmista tuoteosat ja järjestelmät A5 Tee työmaatoteutus ja luovuta rakennus A6 Käyttöönota ja käytä rakennusta, ja harjoita kiinteistönpitoa A7 Hallitse rakennuksen elinkaaritiedot, ja yleiset tietokannat KKa Kuva 3. ProIT-prosessimallin toimintojen hierarkian eräitä toimintoja (vahvennettu), joihin käyttötapauksen mukaista määrätiedon siirtoa voi liittyä. Huom. Tässä on esitetty vain hierarkian kolme ylimmäistä tasoa. 2.4 Lähtöoletukset Käyttötapauksen lähtöoletuksena on, että rakennuksen suunnittelun tai määrälaskennan toiminto on tavalla tai toisella (esim. rakennuksen tuoteamallista) tuottanut tiloja, rakennustai laiteosia koskevaa määrätietoa. Lisäksi käytettävän sovelluksen tulee pystyä kirjoittamaan määrätieto Osan 2 määrittelemään tiedonsiirron toteutuksen esitysmuotoon ja tiedonsiirron formaattiin. Tiedonsiirron jälkeen määrätiedot pitää pystyä jälkikäsittelemään (lukemaan) Osan 2 määrittelemästä tiedonsiirron toteutuksen esitysmuodosta ja tiedonsiirron formaatista määrätietoa hyödyntävän sovelluksen tiedoiksi. Tiedonsiirron oletuksena on myös se, että tietoa lähettävällä ja vastaanottavalla osapuolella on yhteinen käsitys tilojen, rakennus- ja laiteosien tyyppien nimikkeistä, eli käyttävät samaa nimikkeistöä määrätiedon kohteille. Esimerkkinä tällaisista nimikkeistöistä voivat olla ProIT rakennetyyppikirjaston nimikkeistö [4], tai yhteisesti sovitut LVI-laiteosien nimikkeet. Tietoa vastaanottavalla puolella määrätiedon kohteet tunnistetaan niiden nimikkeiden avulla ProIT_DEXUC_Maaratieto_Versio_0_ doc

9 Tiedonsiirron käyttötapaus: 9 3 Tietosisältö Tiedonsiirron käyttötapauksen keskeisenä määrätiedon tietosisältönä yleisellä tasolla on: Määrätiedon kohteiden ryhmittely Määrätiedon kohde, esim. tila(tyyppi), rakennus- tai laiteosa(tyyppi) Määrä ja sen mittayksikkö Määrätiedon sijainti Tapauskohtaiset kohteisiin liittyvät lisätiedot, ominaisuudet. Kaikille em. olioille yhteisenä tietotarpeena on tuotemallintamisen periaatteiden mukainen olioiden yksikäsitteinen tunnistaminen (käytännössä yksikäsitteinen Id). Tätä edellyttää mm. muutosten hallinta. Määrätiedon elementteihin liittyviä tietotarpeita on kuvattu seuraavassa tarkemmin. 3. Määrätiedon kohteiden ryhmittely Määrätiedon kohteita on usein tarpeen ryhmitellä eri tavoin. Ryhmittelyn perusteita voi olla useita tapauksesta ja näkökulmasta riippuen; perusteena voi olla esimerkiksi järjestelmä, johon kohde kuuluu, määrän sijainti, tuotteen valmistaja, jne. 3.2 Määrätiedon kohteet Määrätiedon kohteena ovat käyttötapauksen alatapauksesta riippuen: Summaamattoman määrätiedon käyttötapauksessa yksittäiset tila-, rakennus- ja laiteosaoliot. Summatun määrätiedon käyttötapauksessa tila-, rakennus- ja laiteosien tyypit, kuten tilatyypit käyttötarkoituksen mukaan, rakennusosatyypit rakennetyyppien mukaan tai eri laitetyypit. 3.3 Määrä ja määrän mittayksikkö Määräkohteen määrä ilmaistaan tyypillisesti kappalemäärän tai pituus, pinta-ala tai tilavuusmitan avulla. Määrätiedolle pitää myös ilmaista määrän mittayksikkö määrätiedon yksikäsitteisyyden varmistamiseksi. 3.4 Määrien sijainti Valinnaisesti määrille voi olla tarpeen myös kuvata niiden sijainti jollakin tavalla. Sijainti voidaan ilmaista esim. rakennuksen lohkona, kerroksena, tilana jne. Summaamattoman määrätiedon tapauksessa, kun määrät on liitetty yksittäisiin olioihin, olioiden sijainti ilmaisee samalla määrän sijainnin. Summatun määrätiedon tapauksessa, eräs tapa ilmaista määrien sijaintia on käyttää ryhmittelyä, ja ryhmitellä määrät sijainneittain ProIT_DEXUC_Maaratieto_Versio_0_ doc

10 Tiedonsiirron käyttötapaus: Määrätiedon kohteen lisätiedot Siirrettävän määrätiedon tyypistä ja näkökulmasta riippuen yksittäisiin määrätietoihin saattaa olla tarpeen liittää muuta määrittelevää ominaisuustietoa, jotka vaihtelevat tapauksittain. Tässä yleistetyssä tiedonsiirron käyttötapauksessa ei näitä kaikkia tapauskohtaisia ominaisuustietoja ole pyritty määrittelemään, vaan kuvataan (Osassa 2) yleinen mekanismi tällaisten ominaisuustietojen liittämiseksi määrätietoihin. 3.6 Käytännön tiedonsiirtojen tietosisällön rajauksen kuvaus Käytännön tiedonsiirron toteutuksissa rakennushankkeissa voi siirrettävän tiedon tietosisältö vaihdella yhdenkin tietonsiirron käyttötapauksen sisällä, riippuen hankkeen vaiheesta, määrätiedon tarkkuudesta, jne. Tähän liittyen on rakennushankkeissa tiedonsiirtoa varten syytä määritellä yksittäisen tiedonsiirron kattama tietosisältö, ja se mitä tietoa ei siirretä. Tällöin tiedon vastaanottaja / hyödyntäjä on tietoinen tietosisällön mahdollisista rajoituksista. Liitteessä 2 on esitetty lyhyt tarkistuslista käytännön tiedonsiirtojen tietosisällön rajauksen kuvaamiseksi ProIT_DEXUC_Maaratieto_Versio_0_ doc

11 Tiedonsiirron käyttötapaus: Osa 2 Käyttötapauksen toteutus: IFC-toteutus ProIT_DEXUC_Maaratieto_Versio_0_ doc

12 Tiedonsiirron käyttötapaus: 2 Johdanto Tiedonsiirron käyttötapauksen tietosisältömäärittely kohdassa 3 on riippumaton siitä millä tavalla ja missä formaatissa tiedot siirretään sovellusten kesken. Tiedonsiirron toteutuksissa määritellään toteutustapa (tiedonsiirron esitysmuoto ja formaatti) tietosisällön siirtämiseksi. Samalle tietosisällölle voi olla vaihtoehtoisia tiedonsiirron toteutustapoja (kuten tietyn sovellusohjelman oma formaatti, de facto standardi, standardi). Rakennushankkeissa on aina erikseen sovittava käytettävä tiedonsiirron toteutustapa. Tässä dokumentissa kuvataan tiedonsiirron toteutus IFC-spesifikaatiota käyttäen. Tämä kuvaus on tarkoitettu toisaalta ohjelmistotoimittajille tiedonsiirron rajapinnan toteutusta (implementointia) varten, toisaalta tietosiirron ratkaisuja valitseville kuvauksena vaatimuksista silloin, jos tiedosniiro toteutetaan IFC:tä käyttäen. Tiedonsiirron toteutukselle käyttötapaus määrittelee ainoastaan toteutuksen esitysmuodon ja formaatin, eli sen missä muodossa tietojen tulee olla tiedonsiirrossa. Käyttötapaus ei kuitenkaan määrittele mitä mediaa tms. käyttäen tiedonsiirto tapahtuu. 2 Tiedonsiirron IFC-toteutus Tiedonsiirron IFC-toteutus perustuu versioon IFC 2x2 Addendum (IFC 2x 2nd edition Addendum ), joka on julkaistu kesällä IFC-tuotemallin minimisisältö IFC-tuotetietomalli ja spesifikaatio asettaa tietyt minimivaatimukset sille mitä rakennuksen tuotemallin tiedostopohjaisen IFC-tiedonsiirron tietosisältönä täytyy olla. Tiedonsiirron käyttötapauksen alatapauksesta riippuen tiedonsiirron minimisisällöllä on erilaiset vaatimukset, jotka kuvataan seuraavassa 2.. IFC-tuotemallin minimisisältö summaamattoman määrätiedon tapauksessa Summaamattoman määrätiedon tapauksessa tuotemallin tietosisältönä on yksittäiset tila-, rakennus- ja laiteosien oliot. Siten tämän käyttötapauksen IFC-tuotemallin minimisisältönä on projektin koostumusrakenne, johon yksittäiset oliot on liitetty: Projekti o Identifiointi ja omistushistoria o Projektin konteksti ja yleiset mittayksiköt Rakennus ja Kerrokset o Identifiointi ja omistushistoria o Määrätiedot (valinnainen) Tilat (valinnainen) o Identifiointi ja omistushistoria o Tilatyyppi o Määrätiedot ProIT_DEXUC_Maaratieto_Versio_0_ doc

13 Tiedonsiirron käyttötapaus: 3 o Ominaisuustiedot (valinnainen) Rakennusosat (valinnainen) o Identifiointi ja omistushistoria o Rakennetyyppi o Määrätiedot o Ominaisuustiedot (valinnainen) Laiteosat (valinnainen) o Identifiointi ja omistushistoria o Laitetyyppi o Määrätiedot o Ominaisuustiedot (valinnainen) Projektin koostumusrakenne (Projekti / Rakennuskompleksi, Rakennus, Lohko / Kerros / Tila) Rakennus- ja laiteosien looginen sijainti koostumusrakenteessa. Määrätiedon ryhmittelyt (valinnainen) Se onko tiedonsiirron tietosisällössä tilat, rakennus- tai laiteosat vai mahdollisesti kaikki edellä mainitut riippuu tiedonsiirron tapauksesta IFC-tuotemallin minimisisältö summatun määrätiedon tapauksessa Summatun määrätiedon tapauksessa tuotemallin tietosisältönä on määrätiedot tila-, rakennusja laiteosien tyypeittäin, tai tyypeittäin jollakin perusteella ryhmiteltynä. Siten tässä käyttötapauksessa projektin koostumusrakenne ei ole relevantti, vaan summatun määrätiedon siirron minimisisältönä on: Projekti o Identifiointi ja omistushistoria o Projektin konteksti ja yleiset mittayksiköt Tilatyypit (valinnainen) o Identifiointi ja omistushistoria o Tilatyyppi o Tyypin määrätiedot o Ominaisuustiedot (valinnainen) ProIT_DEXUC_Maaratieto_Versio_0_ doc

14 Tiedonsiirron käyttötapaus: 4 Rakennusosatyypit (valinnainen) o Identifiointi ja omistushistoria o Rakennetyyppi o Tyypin määrätiedot o Ominaisuustiedot (valinnainen) Laiteosatyypit (valinnainen) o Identifiointi ja omistushistoria o Laitetyyppi o Tyypin määrätiedot o Ominaisuustiedot (valinnainen) Määrätiedon ryhmittelyt (valinnainen) Se onko tiedonsiirron tietosisällössä tila-, rakennus- tai laiteosatyypit vai mahdollisesti kaikki edellä mainitut riippuu tiedonsiirron tapauksesta. 2.2 Määrätiedon toteutus IFC-luokilla Osan kohdassa 3 keskeisiksi todettujen määrätiedon elementtien toteutus IFC-luokilla on esitetty taulukossa. Taulukko. Tietosisällön keskeisten elementtien peilaus ("mappaus") IFC-luokiksi. Määrätiedon elementti IFC-luokka Kommentti Summaamattoman määrätiedon alatapaus Projekti IfcProject Määrätiedon kohteet: Tilat Rakennusosat Laiteosat IfcSpace IfcBuildingElement /... IfcDistributionElement /... Alaluokat Alaluokat Määrät IfcElementQuantity ja IfcPhysicalSimpleQuantity /... Alaluokat Mittayksikkö IfcPhysicalSimpleQuantity.Unit Mittayksikköjen oletukset määritelty projektin tasolla Sijainti Projektin koostumusrakenne Ryhmittelyt IfcGroup ja IfcRelAssignsToGroup Ominaisuustiedot IfcPropertySet ja IfcProperty /... Relevanteista ominaisuuksista sovittava erikseen ProIT_DEXUC_Maaratieto_Versio_0_ doc

15 Tiedonsiirron käyttötapaus: 5 Taulukko. Tietosisällön keskeisten elementtien peilaus ("mappaus") IFC-luokiksi, jatkuu... Määrätiedon elementti IFC-luokka Kommentti Summatun määrätiedon alatapaus Projekti Määrätiedon kohteet: Tilatyypit Rakennusosatyypit Laiteosatyypit Määrät IfcProject IfcTypeProduct IfcBuildingElementType /... IfcDIstributionElementType /... IfcElementQuantity ja IfcPhysicalSimpleQuantity /... Alaluokat Alaluokat Mittayksikkö IfcPhysicalSimpleQuantity.Unit Mittayksikköjen oletukset määritelty projektin tasolla Sijainti / Ryhmittelyt IfcGroup ja IfcRelAssignsToGroup Sijainti ryhmittelyiden avulla Ominaisuustiedot IfcPropertySet ja IfcProperty /... Relevanteista ominaisuuksista sovittava erikseen 2.3 Käyttötapauksen IFC-Aspektit Seuraavassa kuvataan IFC-tuotetietomallin eri osia, IFC Aspekteja [7], jotka ovat tarpeen käyttötapauksen tiedonsiirron toteuttamiseksi. IFC Aspekti on IFC-tuotetietomallin ryhmittely osajoukkoihin siten, että yksi IFC Aspekti kuvaa objektien, kuten rakennusosa-olioiden, tietyn piirteen tai yhteenkuuluvat ominaisuudet. IFC Aspektien kuvaus antaa myös esimerkin IFC Aspektin instanssioinnista. Tämän tiedonsiirron käyttötapauksen IFC-toteutuksen edellyttämät IFC Aspektit on listattu taulukossa 2. Näiden IFC Aspektien määrittelykortit on esitetty liitteessä ProIT_DEXUC_Maaratieto_Versio_0_ doc

16 Tiedonsiirron käyttötapaus: 6 Identifiointi Projekti Rakennus Kerros Tila Taulukko 2. Käyttötapauksen tiedonsiirron IFC-toteutuksen IFC Aspektit. Tietoelementti IFC Aspekti Kommentit Rakennusosat Laiteosat Tilatyypit, rakennus- ja laiteosatyypit Tilojen, rakennus- ja laiteosien luokittelu (nimikkeet) Tila, rakennus- ja laiteosatyyppien luokittelu (nimikkeet) Rakennusosan rakennetyyppi ProIT-00 Identification, naming and owner ProIT-20 Spatial element ProIT-20 Spatial element ProIT-20 Spatial element ProIT-20 Spatial element ProIT-2 Building element ProIT-22 Building service elements ProIT-072 TypeObject ProIT-050 Classification ProIT-050 Classification ProIT-05 Classification and construction type Viittaa IFC Aspektiin ProIT-050 Classification Projektin koostumusrakenne ProIT-02 Project containment Summaamaton tapaus Rakennus- ja laiteosien looginen sijanti Tilojen, rakennus- ja laiteosien erityiset ominaisuudet Ryhmittelyt ProIT-02 Project containment ProIT-07 Property set and Properties ProIT-030 Grouping Summaamaton tapaus Tarjoaa yleisen mekanismin sovittujen ominaisuuksien liittämiseen tila-, rakennus- ja laiteosa-olioihin. 2.4 IFC-tiedonsiirron formaatit IFC-tiedonsiirrossa on kaksi vaihtoehtoista formaattia saman tietosisällön siirtämiseen. Nämä IFC-tiedonsiirron formaatit ovat: IFC-formaatti tai IFC Part 2-formaatti, joka perustuu standardiin ISO [2]. ifcxml-formaatti, joka perustuu IFC-tuotetietomallin määrittelyyn XML Schema-kielellä [3]. Pohjautuu IFC 2x-versioon, mutta ifcxml määrittely IFC 2x2 Addendum - versiolle on tekeillä. Tällä hetkellä IFC-toteutukset kaupallisissa sovelluksissa käyttävät IFC-tiedonsiirtoon IFC Part 2-formaattia ProIT_DEXUC_Maaratieto_Versio_0_ doc

17 Tiedonsiirron käyttötapaus: 7 Viitteet [] International Alliance for Interoperability. Industry Foundation Classes IFC 2x2 Addendum. On-line Reference. [2] Pro IT / Seppo Niemioja. Arkkitehdin tuotemallisuunnittelu Yleiset perusteet ja ohjeita. Pro IT, Tuotemallitieto rakennusprosessissa. Rakennusteollisuus RT. Tammikuu [3] Pro IT / Finnmap Consulting Oy. Tuotemallinnus rakennesuunnittelussa Perusteet ja ohjeita. Pro IT, Tuotemallitieto rakennusprosessissa. Rakennusteollisuus RT [4] Pro IT / Lauri Melvasalo. Pro IT Rakennetyyppikirjasto. Pro IT, Tuotemallitieto rakennusprosessissa. Rakennusteollisuus RT [5] Pro IT / Karstila, Kari & Serén, Kalle. Tuotemallipohjaisen suunnittelun, toteutuksen ja ylläpidon prosessimalli. Pro IT, Tuotemallitieto rakennusprosessissa. Rakennusteollisuus RT [6] Pro IT / Karstila, Kari (ed.). Rakennusten tuotemallintamisen sanasto. Pro IT, Tuotemallitieto rakennusprosessissa. Rakennusteollisuus RT s. [7] Pro IT / Karstila, Kari & Serén, Kalle. IFC Aspect card library. Pro IT, Tuotemallitieto rakennusprosessissa. Rakennusteollisuus RT [8] Haahtela, Yrjänä & Kiiras, Juhani. Talonrakennuksen kustannustieto. Haahtela-Kehitys Oy s. [9] Graphisoft. IFC Reference Guide. 75 s. [0] Tomi Henttinen. Autodesk Architectural Desktop 3.3 IFC 2x tuotemallinnusohje. 6 s. [] Esko Enkovaara & Heikki Haveri. Suunnittelijan määrälaskentaa palvelevien tyyppirakenteiden määrittely. Rakennusteollisuuden keskusliitto [2] ISO :994. Industrial automation systems and integration Product data representation and exchange Part : Implementation methods: Clear text encoding of the exchange structure. International Organization for Standardization ISO, Geneva. [3] Liebich, Thomas. ifcxml. International Alliance for Interoperability ProIT_DEXUC_Maaratieto_Versio_0_ doc

18 Tiedonsiirron käyttötapaus: 8 Liite. Lyhyt sanasto. Sanastossa on kuvattu käyttötapauksen spesifikaation kannalta keskeisimmät termit. Tätä laajemmin on rakennusten tuotemallintamisen terminologiaa määritelty ProIT-sanastossa [6]. Termi 3D-muoto Alustava rakennusosamalli Esitysmuoto Formaatti ICT IFC Aspekti IFC Objektimalli IFC spesifikaatio IFC tuotetietomalli Instanssiointi Käyttötapaus Luokka Mittatieto Määritelmä Kolmiulotteinen muoto. Muodon kuvaus kolmiulotteisen geometrian avulla. Esimerkiksi rakennusosan, seinän, muoto tilavuuskappaleena, suorakulmaisena särmiönä. Rakennuksen tuotemallin tietosisällön osajoukko (vaiheistus), joka kattaa tiloja rajaavat rakennusosat, alustavasti ilman rakennusosien tarkempaa tuoterakennetta. Ks. rakennuksen tuotemallin vaiheistus, vaatimus-, rakennusosa-, tuoteosa-, toteutus-, toteuma- ja ylläpitomalli. Esitysmuoto määrittelee sen miten olion ominaisuudet kuvataan, esim. olion attribuutteina ja relaatioina. Datan esitysmuoto jonkin määritellyn enkoodaustavan (syntaksin) mukaisesti. Information and Communication Technology. Tieto- ja viestintäteknologia. IFC tuotetietomallin ryhmittely osajoukkoihin yhdessä instanssiointiesimerkkien kanssa siten, että yksi IFC Aspekti kuvaa objektien tietyn piirteen tai yhteenkuuluvien ominaisuuksien kuvaamisen kokonaisuuden. Esimerkkejä IFC-Aspekteista: Identifiointi ja omistus, luokittelu, rakennetyyppi, 3D-muodon kuvaus pursotusgeometrialla. IFC Aspektit tukevat tiedonsiirron käyttötapausten määrittelyä ja niiden toteuttamista tietokonesovelluksista. Huom. IFC Aspektit voivat olla osittain päällekkäisiä. Synonyymi sanalle IFC-tuotetietomalli. IFC-objektimalli on kuvattu EXPRESS-tiedonmäärittelykielellä IFC skeemana. Huomautus: Koska IFC kattaa muutakin kuin itse tuotteen (rakennuksen), voidaan puhua tuotetietomallin sijasta myös projektitietomallista. IFC-tuotetietomallin ja sitä täydentävien tietomäärittelyiden (ominaisuusjoukkomäärittelyt), sekä näitä selittävän dokumentaation muodostama kokonaisuus. IFC spesifikaatio määrittelee IFC-tiedonsiirron standardin. IFC-spesifikaation määrittelemä tuotetietomalli. Synonyymi sanalle IFC-objektimalli. Instanssien luonti eli luodaan olioita, ja annetaan niille ominaisuuksien arvot. Lyhennys termille tiedonsiirron käyttötapaus Luokka määrittelee samankaltaisten olioiden ominaisuudet. Olion 3D-muotoa kuvaavat tiedot. Esim. Seinän pituus, leveys ja korkeus. Vrt. Määrätieto ProIT_DEXUC_Maaratieto_Versio_0_ doc

19 Tiedonsiirron käyttötapaus: 9 Termi Määrätieto Näkymä Olio / Objekti Rakennetyyppi Rakennuksen tuotemallin vaiheistus Rakennusosamalli Tiedonsiirron käyttötapaus Tuotemalli Tuotetieto Määritelmä Yksittäisten olioiden 3D-muodon perustiedoista, so. mittatiedoista, johdettu määrää (pinta-alaa, tilavuutta, tms.) kuvaava, tai kappaletavaroiden yhteenlaskettua määrää kuvaava tieto. Määrätietoa usein summataan per rakennetyyppi. Esim. Seinän pinta-ala ja tilavuus, tai tietyn rakennetyypin omaavien seinien yhteinen pinta-ala; tai tietyn tyyppisten ovien yhteenlaskettu lukumäärä. Yleisesti, kokonaisuuden osajoukko tai näkökulma kokonaisuuteen tiettyä tarkoitusta varten. IFC:ssä, toteutuksia varten määritelty IFC:n osajoukko, jota joukko ohjelmistototeuttajia on yhteisesti sopinut tukevansa. Engl. View. Tiettyä asiaa kuvaavien tietojen kooste, jota sovelluksissa käsitellään yhtenä kokonaisuutena. Oliopohjaisessa mallintamisessa tai tuotemallintamisessa asioita kuvataan oliolla, joilla on ominaisuuksia, sekä relaatioita (yhteyksiä) toisiin olioihin. Esim. rakennuksen rakennusosat mallinnetaan tietokonesovelluksilla rakennusosa-olioilla, joilla on ominaisuutensa sekä relaatioita rakennuksen tuotemallin muihin olioihin. Huomautus: Joskus yleisessä kielenkäytössä oliolla saatetaan tarkoittaa joko luokkaa tai luokan instanssia. Jos on tarpeen erityisesti tehdä ero näiden kahden välillä on syytä käyttää jälkimmäisiä termejä. Määrittelee rakennusosan koostumuksen osistaan. Esim. Seinän rakennetyyppi määrittelee seinän poikkileikkauksen rakennekerrokset. Rakennuksen tuotemallin tietosisällön kehittymisen ja tuotetiedon kumuloitumisen karkeaksi kuvaamiseksi määritelty vaiheistus. Ks. alustava rakennusosamalli, rakennusosamalli Rakennuksen tuotemallin tietosisällön osajoukko (vaiheistus), joka kattaa rakennusosat ja niiden tuoterakenteen; kuitenkin niin, että lopullisia rakennustuotteita ei ole vielä valittu. Ks. rakennuksen tuotemallin vaiheistus, alustava rakennusosamalli. Käytännön tiedonsiirron tarve, joka on tunnistettu ja sen tietotarpeet ja tiedonsiirron toteutus on määritelty ja dokumentoitu toteutusta ja käyttöä varten. IFC:n yhteydessä tiedonsiirron käyttötapaus on suunnilleen sama kuin Näkymäkäsite (engl. View). Tuotetietomallin instanssiointi. Tiettyä tuotetta kuvaavat tiedot tuotetietomallin mukaisesti jäsennettynä, ja tallennettuna tuotetietona, tietokonesovelluksilla tulkittavissa olevassa muodossa. Esim. Tietyn rakennuksen tiedot tallennettuna IFC-formaatin mukaiseen siirtotiedostoon. Tuotetta koskevien tietojen esitysmuoto, joka soveltuu ihmisten ja tietokonesovellusten toimesta tapahtuvaan kommunikointiin, tulkintaan ja prosessiontiin. (ISO 0303-) Tuotetta ja siihen liittyviä asioita kuvaava tieto, joka on digitaalisessa, tietokonesovelluksilla tulkittavassa muodossa. Esim. Rakennusta ja rakennusprojektia kuvaavat tiedot IFC-formaatin mukaisessa muodossa ProIT_DEXUC_Maaratieto_Versio_0_ doc

20 Tiedonsiirron käyttötapaus: 20 Termi Tuotetietomalli Määritelmä Tuotetietoja määrittelevä käsitemalli. Tuotetietojen formaali määrittely, joka määrittelee tuotetietojen tietosisällön. Esim. IFC Objektimalli on rakentamisen ja kiinteistönpidon tiedonsiirtoa varten määritelty tuotetietomalli ProIT_DEXUC_Maaratieto_Versio_0_ doc

21 Tiedonsiirron käyttötapaus: 2 Liite 2. Tiedonsiirron tietosisällön kuvauksen lyhyt tarkistuslista. Käytännön tiedonsiirroissa on oleellista, että tiedonsiirron osapuolilla on yhteinen käsitys tiedonsiirron tietosisällöstä ja sen rajauksesta. Tiedonsiirron tietosisällöstä ja sen rajauksessa määriteltäviä asioita: Tuotemallin vaihe, josta määrätiedot on mahdollisesti tuotettu: Alustava rakennusosamalli / Rakennusosamalli / Tuoteosamalli Rakenne- ja laitetyyppien määrittelyn taso: Ei määritelty / Yleiset (taso 000) / Yksityiskohtaiset (taso 23) Tyyppien (tila-, rakenne- ja laitetyyppien) nimikkeiden nimikkeistö (esim. ProITrakennetyypit) Laitetyyppien nimikkeiden nimikkeistö Sisältyvät / ei-sisältyvät tilat, rakennus- ja laiteosat: Listat esimerkiksi Talo nimikkeistön mukaan Muuta: Erityiset kommentit sisällön rajoituksista / puutteista. Mallinnuksessa käytetyt säännöt, jotka vaikuttavat tuotettuihin määrätietoihin ProIT_DEXUC_Maaratieto_Versio_0_ doc

22 Tiedonsiirron käyttötapaus: 22 Liite 3. Tiedonsiirron toteutuksen lyhyt tarkistuslista. Tiedonsiirrosta sovittaessa ainakin seuraavia näkökohtia tulisi pohtia, ja ottaa tarpeen mukaan osaksi sopimista. Tiedonsiirron sopimukset; vastuut, velvoitteet ja oikeudet. Tiedonsiirron tietosisältö (ks. liite 2) Mallinnuksen säännöt (esim ProIT Rakennussuunnittelun tuotemallinnusohje [2]) Nimikkeistöt (rakennusosille, rakennetyypeille) Kuvatasojen käyttö Tiedonsiirron standardi / formaatti, ja sen versio Sovellusten yhteensopivuus: o Tiedonsiirron rajapinta (Add-on) o Tuki tiedonsiirron formaatille (mukaan lukien sen versio) Nimeämiskäytännöt Tiedonsiirron media / palvelimet Tiedonsiirron proseduurit Tarvittavat kuittaukset Tiedonsiirtoon liittyvä arkistointi ProIT_DEXUC_Maaratieto_Versio_0_ doc

23 Tiedonsiirron käyttötapaus: 23 Liite 4. Tiedonsiirron käyttötapauksen IFC-toteutuksen IFC- Aspektikortit. IFC Aspektikortit ProIT-000 Aspect card guidelines ProIT-00 Identification, naming and owner ProIT-02 Project containment ProIT-030 Grouping ProIT-050 Classification ProIT-05 Classification and construction type ProIT-07 Property set and properties ProIT-072 TypeObject ProIT-20 Spatial element ProIT-2 Building element ProIT-22 Building service elements ProIT_DEXUC_Maaratieto_Versio_0_ doc

24 IFC Aspect Name: Aspect Card Guidelines Code: ProIT-000 Created: Revision Date: Version:. Editor: KSn Page (3) General Description: These are general guidelines for using/making the IFC Aspects as used within the context of Pro IT Data Exchange Use Cases. This field is for a brief, general description of the Aspect. General Entity Type Description: This field is for a condensed description of entity types. Entity Type Detail Considerations: This field is for special notes on usage of attributes and other specific details. NOTE: The Aspect Card Code in the header section is for referencing purposes only the numbering does not carry any semantic meaning. Notes: This field is for special notes, considerations, etc. This Guideline Card includes all the fields that may occur on an Aspect Card. Fields that not necessarily occur on every type of Aspect Card are also shown in this card for reference. All optional fields are indicated where applicable. Usage Note: all table fields are implemented as AutoText (see Menu: Insert -> AutoText -> TableCaption). Partial Schema in EXPRESS-G: You should put your aspect schema in EXPRESS-G here. Note that several sub-schemas may be included if needed. (here is a summary of EXPRESS-G symbols): (simple data type) (defined type) (select type) (enumeration type) (entity type) (Super/Subtype relationships) (Attribute / Relationship) (Optional Attribute / Relationship) page #, ref # (#, #,...) page #, ref # name (Reference to this page) (Reference to another page) KKa ProIT_IFC_Aspect_000_AspectCardGuidelines_-.doc

25 IFC Aspect Name: Aspect Card Guidelines Code: ProIT-000 Created: Revision Date: Version:. Editor: KSn Page 2(3) Property Sets: Pset Name Property Name Property Data Type <Pset_> Name of st Pset <Prop_.> Name of st property <IfcDataType.> st prop Data type <Prop_.2> etc. <IfcDataType.2> etc. <Pset_2> etc. <Prop_2.> etc. <IfcDataType2.> etc. <Prop_2.2> etc. <IfcDataType2.2> etc. Note: This field is OPTIONAL. In some cases you may want to present the used Psets with appropriate property definitions. This is done through a sub-table within a table field, just add rows to the sub-table as needed. Geometry Use: Local Placement Geometric Representations Describe the local placement if needed (usually only reference to specification is required) Bounding box Swept Solid Etc. Short notes on usage, reference to applicable Aspect Card and IFC specification Repeated for each applicable geometric representation Note: This field is OPTIONAL. In some cases you may want to present the Geometry use with appropriate representations. This is done through a sub-table within a table field, just add rows to the sub-table as needed. ProIT_IFC_Aspect_000_AspectCardGuidelines_-.doc

26 IFC Aspect Name: Aspect Card Guidelines Code: ProIT-000 Created: Revision Date: Version:. Editor: KSn Page 3(3) General Instantiation Description: Short characterization of the Aspect instantiation. Instantiation Notes: Special considerations, issues, notes on intantiations, references, etc. Instantiation details: Condensed description about instantiation details. Note that several examples with accompanying descriptions can be included. In some generic Aspect Cards the instantiation sections are not included, just the schema sections. The instantiations of these generic aspects are illustrated in more specific Aspect Cards. Instrance Diagram: Insert Instance Diagram here. Note that several instance diagram examples may be included if needed (here is now a brief summary of the instance diagram notation): Instance diagram notation: EntityType #23 AttributeName = Value2 AttributeName = Value2 An instance of Entity Type and its simple Attribute Values. RelshipName RelshipName EntityType A Relationship between Instances. An aggregate Relationship between Instances. A reference to an Instance with details omitted. EntityType Page#, RefId# Page#, RefId# (frompage#) A reference to an Instance on another page. A reference to an Instance on this page. Pset Usage Instructions: Note: This field is OPTIONAL. In some cases you may want to present the Pset usage with appropriate property value instantiations. This field is for a free text description of this. ProIT_IFC_Aspect_000_AspectCardGuidelines_-.doc

27 IFC Aspect Name: Identification, Naming and Owner Code: ProIT-00 Created: Revision Date: Version:.0 Editor: KSn Page (2) General Description: This aspect describes how objects are named and identified as well as how ownership of objects is assigned according to the IFC specification. See also IFC 2x2 add. on-line specification. Entity Type Detail Considerations: The IfcRoot.GlobalId attribute is globally unique and is governed by special constraints and generation principles described in the IFC specification. The IfcRoot.Name attribute is generally optional, but subtypes may impose mandatory use through local where rules, see the IFC specification for details. The Ifc.CreationDate and Ifc. LastModificationDate attributes are of type IfcTimeStamp, which is an indication of date and time expressed as the number of seconds which have elapsed since the beginning of the year 970. General Entity Type Description: In order to maintain and manage the instantiated IFC model objects over their lifetime they are uniquely identified by the GlobalId attribute which is possessed by every instance of subtypes of IfcRoot. In addition, IfcRoot has the optional Name and Description attributes for additional naming and descriptive purposes. The IFC model has a lightweight construct for capturing the most recent changes for a specific instance through the attribute possessed by all subtypes of IfcRoot. This attribute refers to an Ifc instance holding the information about the state of the instance, the name and organization of the user that created and last modified the instance, the software application that created and last modified the instance, and the date and time that the instance was created and last modified. Notes: The identification, naming and ownership assignment applies to all subtypes of the IfcRoot entity, i.e. all objects of entity types belonging to the project model part of the IFC object model, either subtypes of IfcObject, IfcRelationship or IfcPropertyDefinition. Partial Schema in EXPRESS-G: *STRING IfcGloballyUniqueId *GlobalId IfcRoot Name IfcPersonAndOrganization OwningUser LastModifyingUser Ifc Description 2,2 IfcText OwningApplication IfcApplication LastModifyingApplication IfcChangeActionEnum ChangeAction State IfcPropertyDefinition IfcRelationship IfcObject IfcStateEnum CreationDate IfcTimeStamp LastModifiedDate ProIT_IFC_Aspect_00_IdentificationNamingOwner_-0.doc

28 IFC Aspect Name: Identification, Naming and Owner Code: ProIT-00 Created: Revision Date: Version:.0 Editor: KSn Page 2(2) General Instantiation Description: This instance diagram gives an example of how an object, an instance of IfcColumn, a subtype of IfcRoot, is given identification, naming and owner history information. Instantiation Notes: Some of the optional attributes are left unasserted in the example. IfcLocalPlacement and IfcProductDefintionShape instance details are omitted for sake of clarity (see aspect cards ProIT-080 and ProIT-08 for further details). Instantiation details: The instance of the class IfcColumn (#) has a globally unique ID, which is generated according to the IFC specifications. The column object is named 'Column---'. The optional Description attribute is here left without a value. All objects in a building project have a relationship to an owner history, which gives a snapshot of the last changes made to a specific object. The column has an owner history (#2) with the last change action Added, pointing to the application (#3) as well as person and organization (#4, #5 and #6) that have the ownership of the column information. The owning user has a specific role Consultant stored in an instance of the IfcActorRole class (#7). The owning application (#3) has an organization (#8) as its developer. Instance Diagram: IfcColumn # GlobalId: 'F327BF38ED484EB858DC9' Name: 'C---' Description: 'A concrete column' ObjectType: $ Tag: $ ObjectPlacement Representation IfcLocalPlacement IfcProductDefinitionShape Ifc #2 State: $ ChangeAction:.ADDED. LastModifiedDate: $ CreationDate: OwningApplication IfcApplication #3 Version: '.0' ApplicationFullName: 'TheApplication' ApplicationIdentifier: 'TheApp' ApplicationDeveloper OwningUser IfcPersonAndOrganization #5 TheOrganization IfcOrganization #4 Id: $ Name: 'DesignCompany Ltd' IfcOrganization #8 Id: $ Name: 'SoftCompany Ltd' Roles ThePerson IfcPerson #6 Id: $ FamilyName: 'Doe' GivenName: 'John' MiddleNames: $ PrefixTitles: $ SuffixTitles: $ IfcActorRole #7 Role:.CONSULTANT. UserDefinedRole: $ ProIT_IFC_Aspect_00_IdentificationNamingOwner_-0.doc

29 IFC Aspect Name: Project Containment Code: ProIT-02 Created: Revision Date: Version:.0 Editor: KSn Page (2) General Description: This aspect describes which classes are involved in the formation of a typical project containment hierarchy and how these should be instantiated according to the IFC specification. See also IFC 2x2 add. on-line specification. Entity Type Detail Considerations: The elements contained in a spatial structure may be further decomposed using instances of IfcRelAggregates as links between the whole and parts. Note the naming conventions of the objectified relationships' attributes: RelatingObject and RelatingStructure always point to the whole, whereas the RelatedObject and RelatedElements always refer to the aggregate of parts. General Entity Type Description: The decomposition/containment is generally built around a hierarchy of different levels of spatial elements where the decomposition is realized through objectified relationships, i.e. IfcRelAggregates instances. The chain of decomposition has an instance of IfcProject as a navigational starting point. The spatial decomposition chain is in its complete form: project (an instance of IfcProject) site(s) (instance(s) of IfcSite) building(s) (instance(s) of IfcBuilding) storeys (instances of IfcBuildingStorey) spaces (instances of IfcSpace). The physical building elements, walls, columns and beams, etc. (subtypes of IfcProduct), are connected to the respective spatial elements they are contained in, usually to a building storey, through specific objectified relationships, i.e. instances of IfcRelContainedInSpatialStructure. Notes: There is a minor inconsistency in the lastest IFC specification where the IfcRelContainedInSpatialStructure.Related- Elements attribute points to IfcProduct whereas the corresponding inverse attribute ContainedInStructure points from its subtype IfcElement. Both classes are abstract so there are no practical implications due to this. Partial Schema in EXPRESS-G: 2,5 GloballyUniqueId *GlobalId IfcRoot Name 2,7 Ifc Description 2,6 IfcText IfcRelationship RelatingObject (INV) IsDecomposedBy S[0:] RelatedObjects S[:?] (INV) Decomposes S[0:?] IfcObject ObjectType LongName Phase IfcRelConnects IfcRelDecomposes IfcProduct IfcProject UnitsInContext 2,3 IfcUnitAssignment IfcRelAggregates RepresentationContexts S[:?] 2,2 IfcRepresentationContext (INV) ContainedInStructure FOR RelatedElements IfcElement Tag 2,4 IfcIdentifier IfcRelContainedInSpatialStructure RelatedElements S[:?] RelatingStructure IfcSpatialStructureElement LongName CompositionType IfcBuildingElement IfcDistributionElement IfcFurnishingElement (INV) ContainsElements S[0:?] IfcElementCompositionEnum IfcEquipmentElement IfcElementAssembly IfcSite IfcBuilding IfcElectricalElement IfcElementComponent IfcSpace IfcBuildingStorey IfcTransportElement IfcFeatureElement ProIT_IFC_Aspect_02_ProjectContainment_-0.doc

30 IFC Aspect Name: Project Containment Code: ProIT-02 Created: Revision Date: Version:.0 Editor: KSn Page 2(2) General Instantiation Description: This instance diagram gives an example of how a project containment/decomposition hierarchy is formed. Instantiation Notes: All instance attribute details are omitted for the sake of clarity only the principles of project containment instantiation are shown on object level. Ifc instantiations are also completely omitted (see aspect card ProIT-00 for further details) as well as all possible representation instantiations. Instantiation details: The basic building decomposition structure mechanism is presented in the instance diagram below. The spatial decomposition is formed using aggregate relationships (#, #2 and #3), which gives a decomposition chain: project (#6) site (#7) building (#8) two building storeys (#9, #0). The physical building elements, a column (#6), a wall (#7), a beam (#9), and a slab (#8) in this example, are connected to their respective building storey with containment relationships (#4, #5). Instance Diagram: IfcProject #6 RelatingObject IfcRelAggregates # IfcSite #7 RelatedObjects RelatingObject IfcRelAggregates #2 IfcBuilding #8 RelatedObjects RelatingObject IfcRelAggregates #3 RelatedObjects IfcBuildingStorey #9 RelatingStructure IfcRelContainedInSpatialStructure #4 IfcColumn #6 RelatedObjects IfcWall #7 IfcBuildingStorey #0 RelatingStructure IfcRelContainedInSpatialStructure #5 IfcBeam #9 RelatedObjects IfcSlab #8 ProIT_IFC_Aspect_02_ProjectContainment_-0.doc

31 IFC Aspect Name: Grouping Code: ProIT-030 Created: Revision Date: Version:.0 Editor: KSn Page (2) General Description: This aspect describes how objects are grouped together using the grouping mechanism according to the IFC specification. See also IFC 2x2 add. on-line specification. Entity Type Detail Considerations: There are several possible uses for grouping: collecting members of a system together, grouping objects according to different disciplines, grouping together objects for procurement purposes, providing alternative hierarchical structures, etc. Groups may be defined using instances of specific subtypes of the IfcGroup class found in the IFC object model or using the generic IfcGroup class and by qualifying the group, for instance, using the inherited ObjectType attribute or the Name or Description attributes. General Entity Type Description: Grouping is a general purpose logical collection of objects. The grouping is independent of any fixed decomposition or location groups may be established for various reasons. Groups are implemented using instances of the IfcGroup class (or more specific subtypes) to which the group members are assigned using IfcRelAssignsToGroup instances. It should be noted that a single object may be included in several different groups. Another noticeable aspect is that a group itself may a part of another group, and that groups can be nested to form hierarchies. Notes: There are a number of subtypes of IfcGroup in the IFC model. Of these only the two most widely used, IfcSystem and IfcZone, are shown in the partial schema below. Partial Schema in EXPRESS-G: 2,2 IfcGloballyUniqueId *GlobalId IfcRoot Name 2,3 Ifc Description 2,4 IfcText IfcRelationship IfcObject ObjectType IfcRelAssigns RelatedObjects S[:?] (INV) HasAssignments S[0:?] IfcObjectTypeEnum RelatedObjectsType IfcRelAssignsToGroup RelatingGroup (INV) IsGroupedBy IfcGroup IfcSystem IfcZone ProIT_IFC_Aspect_030_Grouping_-0.doc

32 IFC Aspect Name: Grouping Code: ProIT-030 Created: Revision Date: Version:.0 Editor: KSn Page 2(2) General Instantiation Description: The instantiation example diagram illustates how two objects, two door instances, are assigned the group for fire protecting doors. Instantiation Notes: Some of the optional attributes are left unasserted in the examples. Ifc instantiation details are omitted for sake of clarity (see aspect card ProIT-00 for further details). Instantiation details: Two doors (instances of IfcDoor, #3 ja #4) are assigned through an objectified relationship, an instance of IfcRelAssignsToGroup ( #2), to a group (#). This group (an IfcGroup instance) is a logical collection of the doors and the purpose of the group is given by the IfcGroup.Description attribute to which in this case the value 'Fire protecting doors' is asserted, i.e. the two doors belong to the group of fire protecting doors. Instance Diagram: IfcGroup # GlobalId: 'GH3E57998AA433E928FB' Name: '' Description: 'Fire protecting doors' RelatingGroup Ifc IfcRelAssignsToGroup #2 GlobalId: 'GH3E57998AA433E928JK6' Name:$ RelatedObjectsType: $ RelatedObjects IfcDoor #3 GlobalId: 'DB3E57998AA433E928FB' Name: 'Metal door 00' OverallHeight: OverallWidht: Ifc IfcDoor #4 GlobalId: 'DB3E57998AA433E928FH' Name: 'Metal door 002' OverallHeight: OverallWidht: Ifc ProIT_IFC_Aspect_030_Grouping_-0.doc