Mudeli ülesehituse kokkulepped

Kaheksa kokkulepet, mis teevad teemamudelid vahetatavaks ja mõistetavaks: faili nimi, asukoht, tasandid, üksused, nimetamine, klassifikaator, atribuutide komplektid ning kordused ja lõikumised.

Lühidalt

See leht kirjeldab, kuidas teemamudelite struktuur üles ehitada nii, et mudelid on vahetatavad ja mõistetavad. BIM-i struktuur on kindlaks määratud, kuid selle sisu on projektipõhine. Seega tuleb kokku leppida minimaalsetes tingimustes, millele iga teemamudel vastama peab.

Kuna üksik mudel ei pea sisaldama kogu eriala, vaid võib esitada sellest ühte „teemat“, kutsutakse neid teemamudeliteks. Seetõttu võib projektis olla igal erialal mitu teemamudelit.

Millal vaja

Need kokkulepped on vajalikud arusaadava ja optimaalse koostöö tagamiseks. Pärast põhjalikke konsultatsioone sektoris jõuti seisukohani, et kõik selle peatüki kokkulepped on kõigis teemamudelites kohustuslikud.

3.1 Faili nimi

Süsteemne nimetamine

Selle kokkuleppe eesmärk on lihtsustada teemamudelite kasutajate tööd nii projekti ajal kui ka pärast seda. Teemamudelite süsteemne nimetamine loob projektis ühtsuse – faili nimi viitab alati sisule. Peale selle saab ühtse struktuuri kasutamisel teha automaatkontrolle.

Nimede moodustamine

Leppige projektimeeskonnas kokku, kuidas nimesid moodustatakse. Allpool on mõni võimalus.

Lihtne nimekuju

<ehitis>_<eriala>_<osa>.ifc

• projekti nimi_EK_TP.ifc
• projekti nimi_ehitis_ehitiseosa.ifc
• projekti nimi_EL_valgustus.ifc
• projekti nimi_EN_1. korrus.ifc

Laiendatud nimekuju

<ehitis>_<kinnisvara objekt-teemamudeli tüüp-teemamudeli alatüüp>_<ettevõtte nimi>-<plokk4>-<plokk5>….ifc

Siin koosneb faili nimi kasutatavate plokkide minimaalsest hulgast; selles näites on need ülalolevast seeriast kolm esimest. Täpsemad nimed on projektimeeskonnaga kooskõlastades alati võimalikud. Seda ka siis, kui täidetakse eri plokke.

3.2 Lokaalne asukoht

Teemamudelite asukoht

Kuna töötatakse mitme teema-, mitte ühe tervikmudeliga, on vaja kooskõlastada teemamudelite asukohad baaspunkti suhtes.

• Protsessi alguses määrab algataja baaspunkti asukoha läbimõeldult, et seda saaks silmas pidada ehitise kogu olelusringi jooksul.
• Baaspunkt on koondmudeli alguspunkt.
• Kui töötate mitme teemamudeliga, veenduge, et need oleksid korrektselt joondatud.

Praktilised soovitused

• On soovitatav, et baaspunkt asuks ehitise x- ja y-suunalistest gabariitidest väljaspool.
• Vajaduse korral asetage vastastikuseks joondamiseks baaspunkti võrdlusobjekt. Sel juhul veenduge, et võrdlusobjekt asuks väljaspool ehitist, kaasa arvatud z-suund, ja et kõigi teemamudelite võrdlusobjektid kattuksid täielikult.
• Baaspunkti geoviite saab anda mudeli omadusena nii, et mudelit on võimalik GIS-vaaturites maailmaruumis õiges kohas kuvada.

3.3 Ehitise tasandite korraldus ja nimetamine

Ehitise korrektsed tasandid

Looge teemamudelites ühetaolised ja süsteemsed tasandid nii, et teemamudeleid ja neist moodustatud IFC-faile saaks projektis üheselt mõistetavalt kasutada. Veenduge, et ehitustasandite nimed ja kõrgusemärgid oleksid kõigis teemamudelites samad. Süsteemse nimetamise põhimõte on, et tasandeid saaks sorteerida numbriliselt, lisades tekstilise kirjelduse.

Mis on korrus?

Korrus on juurdepääsetav ruumikiht. Viimistletud põranda ülapind on BuildingStorey piir, mis tähendab, et BuildingStorey on ka ruumi piir. IFC-failis võib seega olla korruse kohta ainult üks BuildingStorey. Lisatasandid, näiteks põrandakonstruktsioonide ülapinnad, võivad olla ainult algfailides.

• Leppige kokku, millise tasandiga (Level) on BuildingStorey seotud, et kõik osalised kasutaksid tasandist 0 samu kõrguseid.
• Vundament ei ole eraldiseisev BuildingStorey. Vundamendi elemendid kuuluvad selle korruse juurde, mis sellele toetub (tavaliselt kõige alumine korrus ehk –1, kui see on keldrikorrus, või 00, kui esimene maapealne korrus).
• Põranda kandetalad kuuluvad selle BuildingStorey juurde, mille põrandat need kannavad.
• Eri hooneosadel võivad olla eri BuildingStorey’d, mis juhul võib korruse nimekujusse lisada ka hooneosa tähise.
• Poolkorrus, mis nimetatakse BuildingStorey’ks, saab lisatähise -a, -b, -c jne.
• Hoone ülemist pinda võib nimetada kui „katus“ või „korrus“. Mitme katusega hoone korral ei ole „katust“ sobiv kasutada.
• Mitut korrust läbivad elemendid kuuluvad selle põranda juurde, kuhu need paigaldatakse. Tavaliselt saab määravaks see, kuidas need tegelikult ehitatakse.

BuildingStorey’de nimetamine on projektipõhine. Näiteks võib ehitise tasandite nime koostada järgmiselt.

<number><poolkorruse tähis> <kirjeldus>

• 01 esimene korrus
• 01a poolkorrus
• 02 teine korrus
• 03 kolmas korrus

3.4 Üksuste (Entity) korrektne kasutamine

IFC rakendamine sisaldab ka IFC-skeemide kasutamist, kus üksused ehk Entity’d ja tüübiloendid ehk TypeEnumeration’id on kaks kõige tähtsamat elementi.

Üksus ehk Entity

Korrektseid üksusi kasutades teab tarkvara, mis liiki objektiga on tegu. Lisaks määrab üksus kindlaks standardse omaduste (property) komplekti IFC-s.

Lähterakendused ekspordivad ja impordivad üksusi enamjaolt õigesti, kuid nende seadeid on võimalik mitmel viisil kohandada ning üksust modelleerida eri viisidel. Ilma õigete ekspordiseadeteta muutub element tihti BuildingElementProxy tüüpi elemendiks. Seda saab vältida, kui eksportida õigel viisil.

Näiteid üksustest:

• trepikoda = IfcStair
• põrandakate = IfcCovering
• lagi = IfcCovering
• tuletõkkeklapp = IfcDamperType

Tüübiloend ehk TypeEnumeration

Tüübiloendit kasutatakse siis, kui tahetakse üksuse sees teha eristusi. IFC pakub üksustele tüübiloendite komplekte. Kui element ei sobi ühtegi eeldefineeritud tüübiloendisse, võib alati kasutada tüübiloendit USERDEFINED. Uute terminite vohamise vältimiseks kasutage seda ainult tungival vajadusel. Kui te ei saa või ei taha veel valikut teha, kasutage tüübiloendit NOTDEFINED. See näitab, et ekspordite ainult üksust (vaikimisi üksuse tüübiloend ei ole alati korrektne).

Näiteid tüübiloendiga üksustest:

• põrand = FLOOR
• põrandakate = FLOORING
• laekate = CEILING
• tuletõkkeklapp = FIREDAMPER

Üksuse ja tüübiloendi erinevus lae näitel: Entity on IfcCovering, TypeEnumeration on CEILING.

Kasulik: üksuse IfcCovering tüübiloendi väärtused.

3.5 Struktuur ja nimetamine

Mida näitab Name

Kui töötatakse süsteemselt, saab vastuvõtja vahetatavat infot lihtsalt ja korrektselt tõlgendada. Seetõttu on oluline, et nimetamine oleks arusaadav. Kui objekti olemus on nimetusest väljaloetav, loote projektis selguse ja mõistetavuse. Peale selle muudab see elementide struktuuri läbipaistvaks ja arusaadavaks kogu protsessis.

Name kui atribuut

Atribuut Name on üksiku elemendi nimi, mida võib kasutada mitu korda. Lähterakendustes määrab kogumi nimi elemendi kuju (nt „ümmargune tuletõkkeklapp“). Selle nime võib üle kirjutada, kui see parandab eksporditud IFC-faili kasutatavust (nt teatud lähterakendusele omaste nimede lahtimõtestamine).

Type kui atribuut

Tunnus Type on näiteks ümmarguste tuletõkkeklappide kogum, millel on sama kuju, aga eri omadused. Eelkõige on mõeldud eri mõõtmeid (nt toru läbimõõt ja sügavus ning seinapaksus).

3.6 Klassifitseerimissüsteem

Klassifikatsioon

Objektide klassifitseerimine pakub mitut hüve (nt filtreerimine, lihtne ja kiire suhtlemine ning tõlgendamine). Peale selle annab see võimaluse ühildumiseks teiste süsteemidega (nt eelarvestamine, tootekirjeldused).

Kodeerimine

Üksuste ja võimalike tüüpide korrektne kasutamine võimaldab IFC-failis jämedalt filtreerida. Näiteks atribuutidega IsExternal ja LoadBearing saab mudelist juba palju infot. Kodeerimine peaks põhinema sellel infol, kuid saab ka teistpidi – alustada kodeerimisest ja selle järgi muuta tunnuseid.

Klassifitseerimine tehakse tarkvara võimalustest olenevalt. Tulemuseks on klassifikatsioon, mis on lisatud IFC-faili ja mida saab kasutada otse IFC-vaaturis või -kontrolleris.

Kood

• Valige igale objektile sobivaim kood. Kasutage oma asukohariigis klassifikaatori viimati avaldatud versiooni või Hollandi klassifikaatori NL-SfB viimast väljaannet.
• Vaadake klassifikatsiooni koodi NL-SfB tabeli 1 veerust E. Kasutage ainult neljakohalist tähist ilma sulgudeta.

Klassifikaatori näited

Klassifikaatori nimi: NL-SfB, tabel 1. Kuna arvutid ei suuda sageli kaldkriipsu (/) lugeda, on selle asemel kasutatud sidekriipsu, s.t NL/SfB asemel on kasutatud tähist NL-SfB.

• 21.11 välisseinad; mittekandvad, massiivseinad
• 56.83 küte; soojavarustus, laeküte (kliimaseade)
• 68.72 varahaldussüsteem; mõõtmine ja juhtimine, välised seadmed, komponendid, signaalid

3.7 Atribuutide komplektide (PropertySets) kasutamine

Kindlaksmääratud asukoht

IFC kirjeldab atribuutide komplekte, mis on seotud omadustega. Kuna kasutatakse rahvusvahelist standardit, on kõigile kasutatud atribuutidele kindlaks määratud asukoht ja kõigis teemamudelites on need võimalik leida samast asukohast.

Eeldefineeritus

IFC pakub üksuse liigi järgi eeldefineeritud atribuutide komplekte CommonPropertySets. Kui üksusele on lisatud tüübiloend TypeEnumeration, on mõnikord saadaval atribuutide lisakomplektid.

Atribuudid atribuutide komplektis (Pset)

Üksusel (Entity) on mitu atribuuti (Properties), mis koondatakse üheks komplektiks. Igal üksusel on sellele iseloomulik atribuutide kogu. Üks kõige äratuntavam CommonPropertySet on näiteks Pset_WallCommon, mis sisaldab selliseid atribuute nagu FireRating, LoadBearing ja IsExternal.

• Kui buildingSMARTi juhendi järgi kuulub atribuut kindlasse Pset’i, siis seal peab see ka olema.
• Lisaatribuudid, mida buildingSMART ei paku, võib paigutada oma atribuutide komplekti. Nimetage need komplektid projektipõhistes kokkulepetes (punkt 4.8, leht „Vähim nõutav info mudelis“), et projektimeeskonna kõik liikmed teaksid, kust teie lisatud atribuute leida.
• Pange tähele: lisaatribuutide komplektide nimed ei tohi buildingSMARTi juhendi järgi alata tähekombinatsiooniga „Pset“.

Atribuutide komplektide näited

Pset_CoveringCommon (kehtib ka IfcCovering.FLOORING’u kohta) sisaldab atribuute FireRating, IsExternal, LoadBearing, FlammabilityRating, AcousticRating, FragilityRating, SurfaceSpreadOfFlame ja Combustible.

Pset_CoveringCeiling (kehtib ainult lagede kohta) sisaldab atribuute FragilityRating, Permeability, TileLength ja TileWidth.

IFC2x3 TC1 ja IFC4 erinevused

Pange tähele, et IFC eri versioonide atribuutide (Properties) ja atribuutide komplektide (Psets) vahel on erinevusi. Näiteks üksuse IfcPile puhul ei ole versioonis IFC2x3 TC1 komplektis Pset_PileCommon atribuuti LoadBearing. Kui soovite näidata, kas vai on kandev või mitte, peate IFC2x3 TC1-s tegema eraldiseisva atribuudi ja seda seal näitama. Alates versioonist IFC4.0.2 on atribuut LoadBearing komplekti Pset_PileCommon lisatud.

3.8 Kordused ja lõikumised

Mudelite usaldusväärsus

Infovahetuse usaldusväärsuse tagamiseks on oluline mudelite kvaliteet. Kordused ja lõikumised on olulised maksumuse hindamisel (nt koguste määramine).

Kordused

Korduseks loetakse seda, kui ühes teemamudelis asub üks ja sama objekt mitu korda samas kohas. Kordused ei ole kunagi lubatud, sest need muudavad analüüsid (nt koguste hindamine ja ehituskorralduse simulatsioonid) valeks.

Lõikumised

Lõikumised ei ole põhimõtteliselt lubatud, kui need mõjutavad koostööd teiste teemamudelitega või praktilist ehitatavust. Arutelud selle üle, mida lõikumistelt oodatakse, on osaliste vahel väga olulised. Lõikumiste lubatud hulk sõltub teemamudeli tüübist ja muidugi sellest, millist infot jagatakse.

Mis edasi

• Mida mudelis vähemalt peab olema: leht „Vähim nõutav info mudelis“.
• ÜBN 4.1 täpsustused tõlkele: leht „Modelleerimise juhised“.