Näide: Autodesk Revit
Märkus. Autodesk Revit näited esitatakse viisil, kus kõik atribuudid on defineeritud esmalt Instance viisil. Teatud olukordades on mõningaid atribuute vaja ka Type esituses ja sellele pööratakse tähelepanu edasistes sektsioonides (nt tüübiga seotud atribuutide ülekandmine COBie infovahetusvormingusse). Pane tähele, et teatud kategooriad eeldavad alati Instance atribuuti (nt Room, Project Information), mistõttu on Instance ka siinsetes näidetes esmavalik. Samas on võimalik etteantud Shared Parameters faili kasutades kaasata atribuute nii Instance kui Type sektsiooni, tuleb aga tähele panna, et osad atribuudid on rangelt Instance iseloomuga, ehk siis need on mingit ID väärtust esitavad ja seega ei saa kuuluda Type sektsiooni. Instance/Type põhine määratlus võib olla väga tarkvara-spetsiifiline, ja see ei pruugi üldse teemaks olla mõnes teises tarkvaras (nt Autodesk Civil 3D tarkvaras sedalaadi erisust ei tehta).
Sisujuht
Hoone näide
Allolevalt teeme läbi põhimõttelise klassifitseerimise praktika hoone näitel, kus valime ühe komponendi, ühe tehnilise süsteemi (koos funktsionaalse süsteemi viitetunnusega) ning ka ehitatud ruumi.
Allalaaditavast Autodesk Revit failist leiad aga terviklikuma pildi, kus klassifitseeritud on kõik sarnased komponendid, lisatabelid, väljavõtted jne. Atribuutide taaskasutamiseks on võimalik kasutada näidis-Revit faili kui ka Shared Parameters faili. Lisaks on kasutusel RDS/R rakendustabel, kus on toodud tüübid/alatüübid, mida klassifitseerimisel kasutatakse.
Märkus. RDS/R rakendustabeli tüübid/alatüübid peavad lähtuma ühetaolisest reeglistikust, nt eristuvast funktsioonist, mida element täidab või muust, eristuvast, aspektist. Tüüpe/alatüüpe saab alati täpsustada toote spetsiifiliste atribuutidega (lisaatribuudid), mistõttu rakendustabeli tüüpe/alatüüpe ei tohi vaadata toote/tootja või liiga spetsiifilise atribuudi kontekstis. Samas mõnel juhul võib eristuvaks tüübiks/alatüübiks olla materjali kontekst kui selline eristamine on väga põhimõtteline (nt keskkonna aspekt). Siin toodud rakendustabel on tellijate ülene ehk siis kui rakendustabeleid vaadata ühe konkreetse tellija näitel, siis ilmselgelt ei vaja ta kõikide RDS/CCI põhiklassifikaatorite laiendamist tüüpideks/alatüüpideks, vaid piirduda vaid talle oluliste osadega.
Laadi alla siin näites kasutatud Autodesk Revit näidismudel (2026 versioon, uuendamisel):
Laadi alla IFC 4.3 ekspordituna Autodesk Revit 2026 näidismudelist:
Märkus. Näidisfaili saab laiendada kui on kaasatud lisakomponentide tüüpe/elemente. Hetkel on fookuses arhitektuurse osa põhikomponendid.
Hoone: Komponendi klassifitseerimine
Peale RDS/CCI klassifitseerimisega seotud atribuutide kaasamisest aktiivsesse projekti, kuvatakse need Properties > Identity Data sektsioonis. Autodesk Revit on selles osas piiratud, et me saame kasutada sisseehitatud sektsioone nagu Identity Data, IFC Parameters, Data jne. Atribuutide kuva saab objekti kategooria põhiselt seadistada (nt ruumide juures pole mõtet näidata tehnilise süsteemiga seotud atribuuti).
Antud näidetes lähtutakse, et atribuutide täitmise koosseis täpsustatakse infosisunõuetes. Ühelt poolt täidetakse atribuudid üksiti, kuid viitetunnuste ja unikaalse ID juures kombineeritakse erinevad väärtused üheks tervikuks (seda saab automatiseerida, mida vaadatakse edasistes näidetes).

Akna kui komponendi näitel käime seega läbi eelneval pildil toodud atribuudid, mis ühtlasi sätestab ka nende atribuutide täitmise eeskirja.
- AN010_Nimetus – akna (tüübi) nimetus, mis võib baseeruda rakendustabelitel (nt RDS/R). Antud näites kui: Pöördaken
- AN112_TüüpKood – akna (tüübi) nimetusele vastav tüübi kood, mis võib baseeruda olemasoleval rakendustabelil (nt RDS/R). Siin märgitud kui: QQA40
- AN114_ID – konkreetse akna (selle tüübi) unikaalne kordus. Unikaalsus võib tulla nii üle terve ehitise, lähtuvalt tüübist ja selle kordusest või ka konkreetse tüübiga akna paigutusest mõnes süsteemis/osasüsteemis. Lõpuosa (eristatud alakriipsuga) võib laiendada ka kolmekohaliseks kui selleks peaks olema vajadus. Siin märgitud kui: QQA40_02
Sisuliselt sellega piirdub konkreetsre akna klassifitseerimine. Sellele järgneb akna seos süsteemi ja/või osasüsteemiga (kuuluvus). Seos/kuuluvus võimaldab komponente süsteemi järgi filtreerida. Süsteem esitab nii-öelda laiema vaate (üldisema, nt horisontaalne-vertikaalne paigutus), samas kui osasüsteem jällegi kitsama vaate (üldjuhul kirjeldav läbi tehnilise lahenduse). Esmalt süsteemi näide.
- AN130_SüsteemNimetus – süsteemi (tüübi) inimloetav nimetus, mis võib baseeruda rakendustabelitel (nt RDS/R) või ka tellija vara nimekirjadel
- AN132_SüsteemKood – süsteemi (tüübi) masinloetav kood, mis vastab inimloetavale nimetusele ja baseerub samal allikal, mis ka nimetus ise. Siin näites kui: B12
- AN134_SüsteemID – konkreetset süsteemi tüüpi eristav ID, mis võimaldab vahet teha samaväärsetel süsteemi tüüpidel (üle ehitise), siin näites kasutatakse kahekohalist numbrit, mis kirjutatakse süsteemi koodiga kokku. Siin näites kui: B1201
Süsteemide sees “paiknevad” osasüsteemid, nende täitmine järgib sarnaseid põhimõtteid, mis ka süsteemi juures. Peamiseks erinevuseks on see, et ID osa eristab nüüd ühes konkreetses süsteemis olevaid unikaalseid osasüsteeme. Seega kui süsteem muutub, saab osasüsteem alustada taas n-ö “01” väärtusest. Sestap liigituvadki komponendid osasüsteemidesse ning osasüsteemid omakorda süsteemidesse.
- AN160_OsasüsteemNimetus – osasüsteemi (tüübi) inimloetav nimetus, mis võib baseeruda rakendustabelitel (nt RDS/R) või ka tellija vara nimekirjadel
- AN162_OsasüsteemKood – osasüsteemi (tüübi) masinloetav kood, mis vastab inimloetavale nimetusele ja baseerub samal allikal, mis ka nimetus ise. Siin näites kui: AD12
- AN164_OsasüsteemID – konkreetset osasüsteemi tüüpi eristav ID, mis võimaldab vahet teha samaväärsetel osasüsteemi tüüpidel (ühe konkreetse süsteemi piires), siin näites kasutatakse kahekohalist numbrit, mis kirjutatakse osasüsteemi koodiga kokku. Siin näites kui: AD1215
Kui komponent ja selle kuuluvus on määratletud, saab üksikute väärtuste baasil koostada konkreetse elemendi unikaalse ID väärtuse, mis baseerub RDS loogikal.
- AR360_UnikaalneID – siin väljal saavad kokku üksikud ID väärtused, mis RDS loogika järgi on eraldatud üksteisest punktiga. Antud näites kui:
B1201.AD1215.QQA40_01
Märkus. Vajadusel võib unikaalse ID väärtuse moodustamise põhimõtteid muuta aga see peab olema täpsustatud infosisu nõuetes. Näiteks kasutada kõikide ID väärtuste juures alakriipsu: B12_01.AD12_15.QQA40_01
Märkus. Unikaalset ID väärtust saab täiendada ka asukohapõhise või paigutusega seotud infoga. Näiteks akna juures räägime üldjuhul paigutuse kontekstist (kasutatakse + märki). Samas kui ruumis olev komponent võib olla viidatud kui asukoha kontekstist (sellisel juhul kasutatakse “++” ehk kahekordset plussmärki). Ühe omaduse alla võib lisada ka mitu viitetunnusrühma aga sellisel juhul tuleks need eristada “/” märgiga: –B1201.AD1215.QQA40_01 /+<CS>BAA1001
Märkus. Vaata ka varasemat peatükki. <CS> on kokkulepitav väärtus. Seda võib asendada näiteks ISO 81346-12 poolt kirjeldatud tähtedega aga teatud erisustega/mõõndustega ning ühe või teise skeemi valik peab olema selgelt määratletud infosisu nõuetes.
Lisaks RDS/CCI klassifitseerivatele omadustele on kaasatud mõned lisaomadused, millega määratleme näiteks materjali kategooria, mahtude arvestamise ühiku ning mahulise väärtuse (numbrina, sh soovitud arv komakohti).
Hoone: Süsteemi klassifitseerimine (seina kui osasüsteemi näide)
Allpool on valitud sein, milles olevat akent oleme eelnevas sektsioonis klassifitseerinud. Sisuliselt peavad siin esitatud väärtused vastama sellele, mis ka eelneval pildil (sektsioois), mistõttu neid kordama ei hakka. Samas pane tähele, et kui sein muutub, siis ka väärtused muutuvad. Kui sein (osasüsteem) kuulub samasse süsteemi, siis süsteemi omadused jäävad samaks. Kui sein (osasüsteem) kuulub teise süsteemi, siis süsteemi omadused samuti muutuvad. Osasüsteemid on üldjuhul välja modelleeritud, samas kui süsteemi osa on üldisem ja seda kasutatakse osasüsteeme koondava grupina, mistõttu üldjuhul meil sellist komponenti ei eksisteeri, kus me täidame ainult süsteemi kirjeldava osa!

Hoone: Ehitatud ruumi klassifitseerimine
Allpool on valitud hoones olev ruum, mida oleme vastavalt RDS/CCI skeemile klassifitseerinud.

Vaatamegi üle, mis atribuudid tuleb ruumi kui ehitatud ruumi juures täita (minimaalselt). Kuna ruum on Autodesk Revit mõistes Instance tüüpi element, siis siin kahtepidi täitmist olla ei saa (tüüp vs komponent).
- AN010_Nimetus – ehitatud ruumi tüübi nimetus, mis baseerub rakendustabelil (RDS/R) või tellija põhisel nimistul/registril, siin märgitud kui: Elutuba
- AN112_TüüpKood – ehitatud ruumi tüübi kood, mis vastab nimetusele ja baseerub samal allikal, mis ka nimetus ise, siin märgitud kui: AAB10
- AN114_ID – ehitatud ruumi tüübiga seotud ID, milles sama tüüpi esitava ruumi n-ö kordus lisatakse täiendava kahekohalise numbriga, siin märgitud kui: AAB1001
- AR360_UnikaalneID – ehitatud ruumi ID, millele on täiendavalt lisatud tabeli kood, mis võimaldab neid eristada näiteks teistest elementidest, mis 3 tähte + 4 numbrit esitavad, et seda kaasata täpsustavasse ID koodi loomisesse (vt akna näidet)
Ruumiga seonduvalt on täidetud ka ühikuga seotud omadus, samas kui mahuline omadus täidetakse vaid IFC eksportimisel ning originaalmudelis on see väärtus leitav vaikimisi omaduse küljest. Kasutusel on ka vaikimisi omadus “Number”, millega tähistatakse ruumi numbrit (lisavajadus). Teatud juhtudel (nt avalikud hooned) võidakse AN114_ID omadust täitagi ruumi numbriga seonduvalt, milles kasutusel tellija/hoone spetsiifika.
Sellega oleme esitanud hoone klassifitseerimisloogika näite Autodesk Revit baasil. On selge, et komponente on erinevaid ja seega tuleb eelnevalt käsitletud põhimõtteid kasutada ka teiste objektide klassifitseerimisel. Tarkvaralist spetsiifikat ja mallide ülesehitust on kirjeldatud hilisemas sektsioonis.
Viadukti näide
Allolevalt teeme läbi põhimõttelise klassifitseerimise praktika lihtsa viadukti näitel, kus valime ühe komponendi. Allalaaditavast Autodesk Revit failist leiad aga terviklikuma pildi, kus klassifitseeritud on kõik sarnased komponendid, lisatabelid, väljavõtted jne. Atribuutide taaskasutamiseks on võimalik kasutada näidis-Revit faili kui ka Shared Parameters faili. Lisaks on kasutusel RDS/R rakendustabel, kus on toodud tüübid/alatüübid, mida klassifitseerimisel kasutatakse.
Märkus. RDS/R rakendustabeli tüübid/alatüübid peavad lähtuma ühetaolisest reeglistikust, nt eristuvast funktsioonist, mida element täidab või muust, eristuvast, aspektist. Tüüpe/alatüüpe saab alati täpsustada toote spetsiifiliste atribuutidega (lisaatribuudid), mistõttu rakendustabeli tüüpe/alatüüpe ei tohi vaadata toote/tootja või liiga spetsiifilise atribuudi kontekstis. Samas mõnel juhul võib eristuvaks tüübiks/alatüübiks olla materjali kontekst kui selline eristamine on väga põhimõtteline (nt keskkonna aspekt). Siin toodud rakendustabel on tellijate ülene ehk siis kui rakendustabeleid vaadata ühe konkreetse tellija näitel, siis ilmselgelt ei vaja ta kõikide RDS/CCI põhiklassifikaatorite laiendamist tüüpideks/alatüüpideks, vaid piirduda vaid talle oluliste osadega.
Laadi alla siin näites kasutatud Autodesk Revit näidismudel (2026 versioon):
Laadi alla IFC 4.3 ekspordituna Autodesk Revit 2026 näidismudelist:
Märkus. Näidisfaili saab laiendada kui on kaasatud lisakomponentide tüüpe/elemente. Hetkel on fookuses konstruktsiooni osa põhikomponendid.
Viadukt: Komponendi klassifitseerimine
Peale RDS/CCI klassifitseerimisega seotud atribuutide kaasamisest aktiivsesse projekti, kuvatakse need Properties > Identity Data sektsioonis. Autodesk Revit on selles osas piiratud, et me saame kasutada sisseehitatud sektsioone nagu Identity Data, IFC Parameters, Data jne. Atribuutide kuva saab objekti kategooria põhiselt seadistada.
Antud näidetes lähtutakse, et atribuutide täitmise koosseis täpsustatakse infosisunõuetes. Siinsetes näidetes on lähtutud, et täitmisele kuuluvad ka süsteemi/osasüsteemi kuuluvust näitavad atribuudid, sõltuma sellest, kas valitud on komponent või tehniline süsteem. Ühelt poolt täidetakse atribuudid üksiti, kuid viitetunnuste ja unikaalse ID juures kombineeritakse erinevad väärtused üheks tervikuks (seda saab automatiseerida, mida vaadatakse edasistes näidetes).

Tala kui komponendi näitel käime seega läbi eelneval pildil toodud atribuudid, mis ühtlasi sätestab ka nende atribuutide täitmise eeskirja.
- AN010_Nimetus – tala (tüübi) nimetus, mis võib baseeruda rakendustabelitel (nt RDS/R). Antud näites kui: Metallmaterjalist tala
- AN112_TüüpKood – tala (tüübi) nimetusele vastav tüübi kood, mis võib baseeruda olemasoleval rakendustabelil (nt RDS/R). Siin märgitud kui: ULE30
- AN114_ID – konkreetse tala (selle tüübi) unikaalne kordus. Unikaalsus võib tulla nii üle terve ehitise, lähtuvalt tüübist ja selle kordusest või ka konkreetse tüübiga tala paigutusest mõnes süsteemis/osasüsteemis. Lõpuosa (eristatud alakriipsuga) võib laiendada ka kolmekohaliseks kui selleks peaks olema vajadus. Siin märgitud kui: ULE30_01
Sisuliselt sellega piirdub konkreetsre tala klassifitseerimine. Sellele järgneb tala seos süsteemi ja/või osasüsteemiga (kuuluvus). Seos/kuuluvus võimaldab komponente süsteemi järgi filtreerida. Süsteem esitab nii-öelda laiema vaate (üldisema, nt horisontaalne-vertikaalne paigutus), samas kui osasüsteem jällegi kitsama vaate (üldjuhul kirjeldav läbi tehnilise lahenduse). Esmalt süsteemi näide.
- AN130_SüsteemNimetus – süsteemi (tüübi) inimloetav nimetus, mis võib baseeruda rakendustabelitel (nt RDS/R) või ka tellija vara nimekirjadel. Siin näites kui: Vahelaesüsteemi pealisehituse osa
- AN132_SüsteemKood – süsteemi (tüübi) masinloetav kood, mis vastab inimloetavale nimetusele ja baseerub samal allikal, mis ka nimetus ise. Siin näites kui: C13
- AN134_SüsteemID – konkreetset süsteemi tüüpi eristav ID, mis võimaldab vahet teha samaväärsetel süsteemi tüüpidel (üle ehitise), siin näites kasutatakse kahekohalist numbrit, mis kirjutatakse süsteemi koodiga kokku. Siin näites kui: C1301
Süsteemide sees “paiknevad” osasüsteemid, nende täitmine järgib sarnaseid põhimõtteid, mis ka süsteemi juures. Peamiseks erinevuseks on see, et ID osa eristab nüüd ühes konkreetses süsteemis olevaid unikaalseid osasüsteeme. Seega kui süsteem muutub, saab osasüsteem alustada taas n-ö “01” väärtusest. Sestap liigituvadki komponendid osasüsteemidesse ning osasüsteemid omakorda süsteemidesse.
- AN160_OsasüsteemNimetus – osasüsteemi (tüübi) inimloetav nimetus, mis võib baseeruda rakendustabelitel (nt RDS/R) või ka tellija vara nimekirjadel. Siin näites kui: Üldine talakonstruktsioon
- AN162_OsasüsteemKood – osasüsteemi (tüübi) masinloetav kood, mis vastab inimloetavale nimetusele ja baseerub samal allikal, mis ka nimetus ise. Siin näites kui: BC01
- AN164_OsasüsteemID – konkreetset osasüsteemi tüüpi eristav ID, mis võimaldab vahet teha samaväärsetel osasüsteemi tüüpidel (ühe konkreetse süsteemi piires), siin näites kasutatakse kahekohalist numbrit, mis kirjutatakse osasüsteemi koodiga kokku. Siin näites kui: BC0101
Kui komponent ja selle kuuluvus on määratletud, saab üksikute väärtuste baasil koostada konkreetse elemendi unikaalse ID väärtuse, mis baseerub RDS loogikal.
- AR360_UnikaalneID – siin väljal saavad kokku üksikud ID väärtused, mis RDS loogika järgi on eraldatud üksteisest punktiga. Antud näites kui:
C1301.BC0101.ULE30_01
Märkus. Vajadusel võib unikaalse ID väärtuse moodustamise põhimõtteid muuta aga see peab olema täpsustatud infosisu nõuetes. Näiteks kasutada kõikide ID väärtuste juures alakriipsu: C13_01.BC01_01.ULE30_01
Märkus. Unikaalset ID väärtust saab täiendada ka asukohapõhise või paigutusega seotud infoga (nt ruumi kontekst).
Lisaks RDS/CCI klassifitseerivatele omadustele on kaasatud mõned lisaomadused, millega määratleme näiteks materjali kategooria, mahtude arvestamise ühiku ning mahulise väärtuse (numbrina, sh soovitud arv komakohti).
Sellega oleme esitanud viadukti klassifitseerimisloogika näite Autodesk Revit baasil. On selge, et komponente on erinevaid ja seega tuleb eelnevalt käsitletud põhimõtteid kasutada ka teiste objektide klassifitseerimisel. Tarkvaralist spetsiifikat ja mallide ülesehitust on kirjeldatud hilisemas sektsioonis.