Enne tarkvaraliste näidete juurde asumist (kuidas nendega tagada CCI, CCI-EE põhimõtteid), vaatame üldistavalt mõne näite varal, kuidas ühtse klassifitseerimissüsteemi kasutuselevõtmine aitab kujundada varakeskset unikaalset ID-d, mis on elukaareülene ning nii inim- kui masinloetav. Juhul kui varasemalt on kasutusel mõni muu unikaalse ID kasutamine, tuleb see siduda CCI-EE koodidega, mida siinkohal ei käsitleta. Üldistavalt saab märkida, et mistahes IT süsteem võib kasutada oma enda unikaalset ID väärtust ja me ei pruugigi saada seda selles tarkvaras ümber defineerida (võtame näiteks BMS ehk Building Management System, mõne turvasüsteemide lahenduse, ruumiregistri, vararegistri jne – kõigis neis võib olla defineeritud oma enda unikaalse ID loogika, mõnes näiteks vaid numbrite kujul). Seega peame ehitusinfomudelite kontekstis või siis ka sellest tuleneva varade korrashoiu kontekstis teostama informatsiooni omavahelise integreerimise, kus ehitusinfomudelist tulenev ja näiteks CCI-EE klassifitseerimissüsteemil baseeruv unikaalne ID seotakse teiste, tellijale oluliste, infosüsteemidega. Kui seda unikaalset ID-d aga ehitusinfomudelite kontekstis pole, on ka integreerimisi ülikeeruline teostada. Tarkvarade vaikimisi unikaalsed ID-d (GUID, Element ID, Handle jne) ei ole inim- ega masinloetavad, lisaks kasutavad erinevad tarkvarad erinevat unikaalset ID-d ja samalaadse info ülekandmisel peame tegema kordades rohkem erinevaid integreerimisi.

Infosüsteemide ülese unikaalse ID kasutuselevõtmine muutub kriitiliseks kui meil on soov liikuda mudelpõhisesse korrashoidu, kus muuhulgas tuleb defineerida ka optimaalsed infoedastuse ülekanded (EIR ehk Exchange Information Requirements nii nagu seda sätestab EN ISO 19650 seeria). Samas on oluline rääkida ühtsest unikaalsest ID mõistest (inim- kui masinloetav) mistahes ehitise elukaare etapi juures, kus on vaja teha kokkuvõtteid või väljavõtteid mahtudest (kas siis ehitusinfomudelist või sellega seotud dokumentatsioonist), millel seejärel baseeruvad näiteks nii eelarved kui muu info automaatne kaasamine. CCI / CCI-EE võimaldab tekitada automaatseid seoseid teiste CCI-EE alamtabelitega, nt teatud ehituskomponentidega seotakse kindlad abivahendid/ressursid või tegevused. CCI-EE annab võimaluse rääkida mahtudest nii üldisemal tasandil (nt CCI tuumiktabelite kontekstis, rahvusvaheline mõõde) kui siis ka detailsemas esituses, milles kaasatakse juba CCI-EE rakendustabeleid (CCI-EE/R), kus lisaks üldtaseme koodile tuuakse sisse ka tüübi/alatüübi kontekst. Pane tähele, et CCI-EE rakendustabelid (tüübid/alatüübid) on CCI-EE baastabelite lisa, mis on omaette arendus ja mida siinkohal näitena ka põgusalt kaasatakse.

Klassifitseerimine tähendab üldjuhul mingite kindlate atribuutide defineerimist, nende kasutusele võtmist digitaalse / füüsilise vara kontekstis. Need atribuudid peaksid olema selgelt defineeritud ja ka nimetatud, alles siis saame nende kaudu edastatavast omadusest üheselt aru (atribuudi mõiste = omaduse nimetus, mis kannab endas omaduse väärtust). Algselt CCI-EE koosseisu kuulunud omaduste tabel on nüüd leitav CIA-DD tabeli nime all, mis siis defineerib atribuudid, mida mistahes projektis soovitakse kasutusele võtta, et tagada ühtne struktuur/nimetamine. Muuhulgas leiab sealt ka atribuute, mis võimaldab meil kasutusele võtta klassifitseerimissüsteem või sellest lähtuv loogika, viitetunnussüsteem.

CIA-DD tabelis on ühtne struktuur tagatud läbi atribuudi koodi (2 tähte + 3 numbrit), mis peab jääma paika mistahes rakenduses kui soovitakse CIA-DD tabelist lähtuvat ja ühetaolist infovahetust. Üldjuhul koosneb meie atribuudi nimetus aga lisaks ka tekstilisest kirjest, mida CIA-DD tabel üheselt ette ei kirjuta ja mida võib seega ka projekti- või tellija põhiselt määratleda. Seetõttu ongi siinne näide üks võimalikest nimetamise skeemidest. Ehkki tekstiline kirje on justkui vaba, peab see jääma atribuudi koodi/ definitsiooni/ standardi poolt määratud piiridesse ja ei tohiks olla segadust tekitav. Atribuudi koodile (kui seda kasutatakse mõnes rakenduses) võib lisada viite CIA-DD tabelile, kust saab lugeda täpsustavat infot antud atribuudi kohta. Selliselt hallatakse atribuutide definitsioone ühest kindlast kohast, kust võib omakorda leida seoseid teiste infosüsteemidega (nt IFC property, ETIM kood jne).

Antud näites piirdume CCI põhitabeleid määratlevate atribuutidega + tüübi ja ID-ga seotud lisaatribuutidega. Samas on võimalik tekitada ka laiendatud vaade, kus kaasatakse nn kollaste/punaste tabelite atribuutinfot. Tasub aga rõhutada, et baastabelite atribuudid on kõige määravamad ning kogu atribuutinfot ei peagi mudelisse kaasama, vaid tänu baastabelite atribuutidele saab linkida lisaatribuute ka mudelitest väljapool.

Allpool on esitatud CIA-DD atribuutide nimekiri, mida kasutatakse järgnevates näidetes. Oluline on järgida, et mistahes tarkvaras oleksid kasutusel sama struktuuriga atribuudid, seeläbi saame mistahes lähtetarkvarast eksporditavast infost ka ühtmoodi aru. Ehkki atribuutide nimekiri võib tunduda pikana, on osad neist filtreeritud vaid kindlatele elementide tüübile, mille kohta leiad juba lisainfot tarkvarade näidetest.

Atribuudi nimetus	Atribuudi üldine kirjeldus (lisainfot + seoseid IFC / ETIM / standarditega vaata ka CIA-DD tabelist)
AC125_EhRuumKlassKood	CCI klassifikaator, mis määratleb ehitatud ruumi koodi (nt AAB)
AC126_EhRuumTyypKood	tüübi kood, mis jagab CCI ehitatud ruumi klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt AAB10)
AC127_EhRuumID	loendatav kood, mis viitab kindlale ehitatud ruumile (vastavalt selle tüübile või ilma, nt AAB1001 või AAB1 või AAB01 jne)
AC130_EhRuumKlassNimi	CCI klassifikaator, mis määratleb ehitatud ruumi mõiste (nt Eluruum)
AC131_EhRuumTyypNimi	tüübi mõiste, mis jagab CCI ehitatud ruumi klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt Elutuba)
AC135_EhKompleksKlassKood	CCI klassifikaator, mis määratleb ehituskompleksi koodi (nt A)
AC136_EhKompleksTyypKood	tüübi kood, mis jagab CCI ehituskompleksi klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt A10)
AC137_EhKompleksID	loendatav kood, mis viitab kindlale ehituskompleksile (vastavalt selle tüübile või ilma, nt A1001 või A1 või A01 jne)
AC140_EhKompleksKlassNimi	CCI klassifikaator, mis määratleb ehituskompleksi mõiste (nt Elamukompleks)
AC141_EhKompleksTyypNimi	tüübi mõiste, mis jagab CCI ehituskompleksi klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt Karavanipark)
AC145_EhitisKlassKood	CCI klassifikaator, mis määratleb ehitise koodi (nt AA)
AC146_EhitisTyypKood	tüübi kood, mis jagab CCI ehitise klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt AA10)
AC147_EhitisID	loendatav kood, mis viitab kindlale ehitisele (vastavalt selle tüübile või ilma, nt AA1001 või AA1 või AA01 jne)
AC150_EhitisKlassNimi	CCI klassifikaator, mis määratleb ehitise mõiste (nt Eramu)
AC151_EhitisTyypNimi	tüübi mõiste, mis jagab CCI ehitise klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt Suvemaja)
AC155_SysteemKlassKood	CCI klassifikaator, mis määratleb funktsionaalse süsteemi koodi (nt A), tähistab süsteemi, mis jaguneb või mille alla võivad kuuluda üks või rohkem osasüsteemi
AC156_SysteemTyypKood	tüübi kood, mis jagab CCI funktsionaalse süsteemi klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt A10)
AC157_SysteemID	loendatav kood, mis viitab kindlale funktsionaalsele süsteemile (vastavalt selle tüübile või ilma, nt A1001 või A1 või A01 jne)
AC160_SysteemKlassNimi	CCI klassifikaator, mis määratleb funktsionaalse süsteemi mõiste (nt Maapealsed ja pinnasesüsteemid)
AC161_SysteemTyypNimi	tüübi mõiste, mis jagab CCI funktsionaalse süsteemi klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt Muldkeha)
AC165_OsasysteemKlassKood	CCI klassifikaator, mis määratleb tehnilise süsteemi koodi (nt AB), tähistab osasüsteemi, mis lähtub või on allsüsteemiks funktsionaalsele süsteemile (süsteemile kui peasüsteemile)
AC166_OsasysteemTyypKood	tüübi kood, mis jagab CCI tehnilise süsteemi klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt AB10)
AC167_OsasysteemID	loendatav kood, mis viitab kindlale tehnilisele süsteemile (vastavalt selle tüübile või ilma, nt AB1001 või AB1 või AB01 jne)
AC170_OsasysteemKlassNimi	CCI klassifikaator, mis määratleb tehnilise süsteemi mõiste (nt Vundamendisüsteem)
AC171_OsaSysteemTyypNimi	tüübi mõiste, mis jagab CCI tehnilise süsteemi klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt Plaatvundamendi ehitus)
AC175_KomponentKlassKood	CCI klassifikaator, mis määratleb ehituskomponendi koodi (nt ULD)
AC176_KomponentTyypKood	tüübi kood, mis jagab CCI ehituskomponendi klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt ULD10)
AC177_KomponentID	loendatav kood, mis viitab kindlale ehituskomponendile (vastavalt selle tüübile või ilma, nt ULD01%ULD10 või ULD1001 või ULD1 või ULD01 jne), unikaalsus võib tuleneda tehnilise süsteemi ja/või funktsionaalse süsteemi ID-st
AC180_KomponentKlassNimi	CCI klassifikaator, mis määratleb ehituskomponendi mõiste (nt Post)
AC181_KomponentTyypNimi	tüübi mõiste, mis jagab CCI ehituskomponendid klassi tüüpideks ning alatüüpideks vastavalt konkreetse(te)le standardi(te)le ja/või vararegistri vajadustele (nt Monteeritav tervikpost)
AN143_RuumNimetus	üld- või määratletud nimi, mis tähistab ruumi kavandatud kasutust või funktsiooni, siinses näidetes kasutusel vaid hoone ruumide korral, et viidata olemasolevale nimetusele
AN144_RuumiNR	ruumile määratud number, siinses näidetes kasutusel vaid hoone ruumide korral, et viidata olemasolevale numbrile

Mõned atribuudid on kombinatsioon eelnevatest atribuutide väärtustest, mistõttu need on esitatud eraldiseisva tabelina. Pane tähele, et nende atribuutide juures kasutatakse nii eelnevalt kirjeldatud atribuutide väärtuseid + lisasümboleid. Seega ongi oluline, et alusomaduse väärtus oleks n-ö puhtana saadaval, mis võimaldab sellega toimetada mistahes viisil (vastavalt tellijapõhisele infosisunõudele näiteks).

Atribuudi nimetus	Atribuudi üldine kirjeldus (lisainfot + seoseid IFC / ETIM / standarditega vaata ka CIA-DD tabelist)
AN116_IfcClassReference	klassifikaatori esitus läbi selle koodi ja mõiste kombo (kood:mõiste), siinses näidetes kasutusel vaid Autodesk Revit juures, seda saab seejärel eksportida kui IfcClassificationReference struktuuri
AR320_Mitmikviitetunnus	viitetunnus, mis koosneb ühendatud ühetasandilistest viitetunnustest (nt ukselukk kuulub uksele, mõlemad on ehituskomponendid ja ukseluku viitamiseks kasutatakse kahte samatasandilist koodi, mis on üksteisest eraldatud punktiga: QQC01.RLA01); mitmikviitetunnuse kasutamiseks peaks see komponent oleme eraldi valitav, lisaks sõltume, kas see on eraldiseisvalt modelleeritud või mitte
AR340_Viitetunnus	konkreetse objekti identifikaator (tuvasti), mis on moodustatud selle süsteemi suhtes, mille koostisosaks see objekt on selle süsteemi ühe või mitme aspekti järgi (nt komponendile saab määrata kui QQA01%QQA10, kus QQA01 esitab KomponentID väärtust ja QQA10 komponendi tüübi väärtust ja % märk markeerib tüübi tunnuse algust)
AR360_UnikaalneID	viitetunnusülem, kahe või enama objektiga seotud viitetunnuste kogum, millest vähemalt üks identifitseerib üheselt selle objekti (nt soovides markeerida ukse (ehituskomponent) paigutust kindlas seinas (tehniline süsteem), mis kuulub välisseinte süsteemi (funktsionaalne süsteem), saame selle kirjutada: B1001.AD5001.QQC01%QQC10 )

Omaduste kombineerimisele kasutatakse EN IEC/ISO 81346 standardiseerias määratletud eraldusmärke, mis on konkreetse tähendusega ja aitavad seeläbi lihtsamini orienteeruda kui tegemist on kombineeritud väärtusega.

Tähemärk/sümbol	Kirjeldus
.	(punkt) üldjuhul kasutatakse kahe erineva koodi eraldusmärgina, mis üksikuna viitavad erinevatele tabelitele, kas siis lihtsalt tähekoodina, koos tüübi numbriga või ID tunnusena (nt B.AD – siin eristatakse funktsionaalse süsteemi koodi (B) tehnilise süsteemi koodist (AD) )
=	(võrdusmärk) kui seotud objekti funktsiooniaspektiga (nt seinasüsteemi saab viidata kui =B )
–	(miinus) kui seotud objekti tooteaspektiga (ehituselement)
+	(pluss) kui seotud objekti peremeespaigaldisaspektiga (nt koosolekuruum +BAB)
++	(2x pluss) kui seotud objekti paigalduskohapõhise aspektiga (nt kui diivan asub koosolekuruumis BAB, siis lisame ruumiviite kui: ++BAB)
%	(protsent) kui seotud objekti tüübiaspektiga (nt kindlale akna tüübile viitame kui %QQA10)
#	(trellid) kui seotud objekti muude aspektidega

Kui eelnevalt käsitletud tähemärgid/sümbolid on mõeldud ennekõike eristamaks teatud klassifikaatoreid üksteisest või rõhutada selle aspektile, siis lisaks neile võivad mängu tulla ka lisaviitetunnused/tähised, mida kaasatakse ennekõike sildistamisel (nt vaadetel, et rõhutada, mida miski kood esitab, sest siis ei ole meil enam atribuudi konteksti, on vaid selle väärtus). Väga oluline on vahet teha atribuudi poolt esitaval väärtusel ja seda väärtust kasutaval tähisel. Need on erinevad asjad! Ja kuniks väärtus on omaette omadus, siis saab sellega teha “mida iganes”, teisisõnu, vastavalt infosisunõuetele markeerida seda ühe või teise viitetunnusega.

CCI-EE tabelid on hetkel markeeritud kahetähelise koodiga (nt CO – tähistab komponenti). CCI-EE juhendites on seega toodud näited just nimelt läbi nende koodide. Kui soovitakse viidata komponendile, siis kasutatakse lisamärgitust: <CO>

Seega, kui lisan plaanile sildi koodiga QQA, siis ei pruugi see kasutajale öelda mitte-kui-midagi, samas kui ma lisan selle ette lisamärgituse (viite): <CO>QQA, siis määran üheselt, et tegemist on aknaga, sest sellist koodi kasutab just nimelt aken kui seda vaadata komponentide <CO> tabelist.

Tähemärk/sümbol	Kirjeldus
/	(kaldkriips) kasutatakse juhul kui soovitakse ühel andmeväljal markeerida/viidata kahele erinevale kuuluvusele (viitetunnusele). Näiteks <CO>QQA/+<CS>BAA1001 tähendab, et me räägime aknast (QQA), mis on ruumis BAA1001 (ruumi viide kui <CS>), kaldkriips eristab kahte erinevat viitetunnust ning + tähistab, et me räägime kuuluvusest teisele elemendile (vt eelmine tabel)
< >	kasutatakse kui soovitakse viidata kindlale tabelile/klassifikaatorile, kust sellele järgnev kood pärineb. Näiteks <CO> tähistab komponentide tabelit. <CS> tähistab ehitatud ruumide tabelit. Lühikoodid pärinevad CCI-EE tabelite töölehtedelt.

CCI-EE kasutab kahetähelist koodi kui viitab kindlale tabelile. Samas võib seda teha ka ISO 81346-12 markeeritud viisil, kuid teatud põhimõtteliste erinevustega. Nimelt sätestatakse seal koodid järgmistele tabelitele (EN ISO 12006-2 laiendatud vaade).

Tähekood	CCI / CCI-EE tabel (järgib osalt EN ISO 12006-2 struktuuri)
A	Tegevusruum
B	Ehitatud ruum
C	Ehituskompleks
D	Ehituse abivahend
E	Ehitis
G	Ehituse osaline
L	Ehituselement
P	Ehitustoode
R	Ehitusprotsess
S	Korrus
Z	Tsoon

Edasistes näidetes kasutatakse hetkel CCI-EE ehk kahetähelisi koode. Samas ei omagi see suures plaanis tähtsust, kuniks üks või teine on infosisunõuetes määratletud ja atribuudi väärtust hoitakse puhtana (ehk siis mitte koos viitega). Näiteks ruumi klassifikaatorit esitav väärtus kui BAA ja mitte <CS>BAA või <B>BAA, sest need on juba täiendavad osad ja neid me kasutame näiteks sildistamisel. Muus osas kirjeldab seda väärtust väga kindel atribuut.

Lisaks eeltoodule võivad olla kaasatud ka muud infosisu esitavad omadused aga jällegi CIA-DD koodi kasutades. Mõned näited leitavad ka tarkvarade mallides. Infosisu kaasamisel tasub arvesse võtta, kas selle olemasolu on ehitusinfo mudelis vajalik/oluline või on mõistlik see informatsioon kaasata mõnes teises infosüsteemis (spetsifikatsioonidest tulenev, konkreetse CCI / CCI-EE komponendi tüübiga/alatüübiga kaasnev infosisu jne). Sellest lähtuvalt on kaasatud mallides jäetud infosisu ulatus minimaalseks. Muidugi tuleb siin alati mängu tellija/projektis osalise kontekst, millist infosisu vajatakse!

Järgides CCI-EE loogikat, saab lisaks ehituselementide klassifitseerimisele määratleda ka nendega seotud ehitusressursid või siis projekti staadiumi jne. Selle kirjeldamiseks on omaette atribuudid, mis leitavad CIA-DD tabelist, kuid mida siinkohal ei käsitleta.

Järgnevates alalõikudes käsitleme juba konkreetsemaid näiteid, milles on eelnevaid põhimõtteid rakendatud. Ehkki tarkvarade näited on piiratud, saab nendes kasutatud põhimõtteid rakendadada mistahes tarkvarale, mida konkreetne kasutaja eelistab. Tehnilisemas osas (mis järgneb üldisematele näidetele) vaatame aga lähemalt, kuidas siinses postituses toodud tarkvarade mallid on üles ehitatud ja kuidas konkreetsetes tarkvarades klassifitseerimissüsteemi kasutusele võtta.