CCI-EE kui unikaalne ID
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. Samas neid, keda huvitab, kuidas CCI-EE haakub olemasolevate BIM nõuetega (nt “Üldised BIM nõuded) võivad tutvuda lisamaterjaliga BIM infosisu nõuded CCI-EE kontekstis (hooned, infra, TRAM). Ü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 CCI-EE 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-EE võimaldab oma unikaalsest koodist lähtuvalt 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 rakendustabelid, 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, mida siinkohal ka põgusalt käsitleme.
Klassifitseerimine tähendab üldjuhul mingite kindlate omaduste defineerimist, nende kasutusele võtmist digitaalse / füüsilise vara kontekstis. Seega tasub enne konkreetse näite juurde liikumist tähele panna omaduste nimekirja, mis tulevad mängu CCI-EE rakendamisel. Need on need omadused, mille kaudu me klassifitseerime kui ka identifitseerime ehituselemendi, ruumi, ehitise või ehituskompleksi. Nende omaduste nimetused tulenevad CCI-EE <RI> tabelist ja on väga oluline, et omaduste nimetamisel jääks alati paika <RI> tabelis toodud tähe-numbriline osa (2 tähte + 3 numbrit). Siinses näites piirdume nn roheliste tabelite klassifikaatoritega ja neid täiendavate tüübi / unikaalse ID / viitetunnusega seotud omadustega. Lisaks võib mudelis kaasata CCI-EE kollaste/punaste tabelite klassifikaatoreid ning nendega seotud tüüpe/unikaalset ID-d. Samas võib kollaste/punaste tabelitega seotud info tulla mängu ka mudelite väliselt, mingis teises infosüsteemis, kus mudelist eksporditud ja CCI-EE tunnustega informatsioon seotakse teises infosüsteemis oleva informatsiooniga, kus samuti CCI-EE kasutusel (nt eelarve koostamist lihtsustav ühikmaksumuste tabel, ehituskomponendist lähtuv lisaressursside kaasamise vajadus jne). Allpool on esitatud CCI-EE omaduste/parameetrite nimekiri, mis tuleb ehitusinfomudelites kasutusele võtta CCI-EE edukaks rakendamiseks (roheliste tabelite ulatuses). Need samad omadused just selliste nimetustega peavad olema kasutusel ka tarkvarade mallides (osaliselt on tekstilise osa juures kasutatud ingliskeelset kirjeldust/esitust, soovi korral võib kasutada eestikeelset nimetust aga ilma tühikuteta, täpitähtedeta).
| Parameetri nimetus | Parameetri üldine kirjeldus (lisainfot + seoseid IFC / ETIM / standarditega vaata ka CCI-EE RI tabelist) |
| AC125_cciCScode | ehitatud ruumi tähistav klassifikaator CCI-EE tabelist CS (kolmetäheline kood) |
| AC130_cciCSterm | ehitatud ruumi tähistav mõiste CCI-EE tabelist CS (tekst nii nagu märgitud) |
| AC135_cciCCcode | ehituskompleksi tähistav klassifikaator CCI-EE tabelist CC (ühetäheline kood) |
| AC140_cciCCterm | ehituskompleksi tähistav mõiste CCI-EE tabelist CC (tekst nii nagu märgitud) |
| AC145_cciCEcode | ehitist tähistav klassifikaator CCI-EE tabelist CE (kahetäheline kood) |
| AC150_cciCEterm | ehitist tähistav mõiste CCI-EE tabelist CE (tekst nii nagu märgitud) |
| AC155_cciCFcode | funktsionaalsest süsteemi tähistav klassifikaator CCI-EE tabelist CF (ühetäheline kood) |
| AC160_cciCFterm | funktsionaalsest süsteemi tähistav mõiste CCI-EE tabelist CF (tekst nii nagu märgitud) |
| AC165_cciCTcode | tehnilist süsteemi tähistav klassifikaator CCI-EE tabelist CT (kahetäheline kood) |
| AC170_cciCTterm | tehnilist süsteemi tähistav mõiste CCI-EE tabelist CT (tekst nii nagu märgitud) |
| AC175_cciCOcode | komponenti tähistav klassifikaator CCI-EE tabelist CO (kolmetäheline kood) |
| AC180_cciCOterm | komponenti tähistav mõiste CCI-EE tabelist CO (tekst nii nagu märgitud) |
| AT800_TypeNumber | klassifitseeritava elemendi, ehitise, ehituskompleksi, ehitatud ruumi jne tähistav tüübi number (kahekohaline number, üldjuhul baseerub etteantud CCI-EE rakendustabelil) |
| AT825_TypeTerm | klassifitseeritava elemendi, ehitise, ehituskompleksi, ehitatud ruumi jne tähistav tüübi mõiste (tekst nii nagu märgitud, üldjuhul baseerub etteantud CCI-EE rakendustabelil) |
| AT850_TypeDesignation | elemendi / ehitatud ruumi / ehitise / ehituskompleksi klassifikaatori ja tüübi numbri kokku kleebitud väärtus (vastavalt CCI-EE juhendile) |
| AJ125_IDNumber | elemendi / ehitatud ruumi / ehitise / ehituskompleksi unikaalne ID, mis lähtub viitetunnuse põhisest loogikast (nt ühes seinas olevate akende unikaalne ID, ja mitte üle hoone kui terviku olevate akende unikaalne ID – unikaalne ID võib baseeruda ka ruumil ning see on alati seotud tüübiga ehk kindlat tüüpi omava elemendi unikaalne ID) |
| AR200_Viitetunnus | elemendi / ehitatud ruumi / ehitise / ehituskompleksi klassifikaatori, tüübi numbri (AT800_TypeNumber) ning ID numbri (AJ125_IDNumber) kombo |
| AM945_Mitmikviitetunnus | elemendi / ehitatud ruumi / ehitise / ehituskompleksi alamelement ja/või kaasnev element (alati ei pruugi olla täidetud) |
| AR225_Viitetunnusrühm | elemendi / ehitatud ruumi / ehitise seos temast kõrgema asetusega viitetunnuste kombinatsioon (võib muuhulgas kaasata ka kollaste ja punaste tabelite viitetunnuseid, vt CCI-EE juhendit) |
Lisaks eeltoodule võivad olla kaasatud ka muud infosisu esitavad omadused aga jällegi CCI-EE koodi kasutades. Mõned näited leitavad ka tarkvarade mallides, kuid põhjalikum tabel leitav juba varasemalt viidatud artiklist BIM infosisu nõuded CCI-EE kontekstis (hooned, infra, TRAM). Infosisu kaasamisel tasub arvesse võtta, kas selle olemasolu on ehitusinfomudelis vajalik/oluline või on mõistlik see informatsioon kaasata mõnes teises infosüsteemis (spetsifikatsioonidest tulenev, konkreetse CCI-EE komponendi tüübiga/alatüübiga kaasnev infosisu jne). Sellest lähtuvalt on kaasatud mallides ka infosisu ulatus jäätud minimaalseks. Muidugi tuleb siin alati mängu ka tellija/projektis osalise kontekst, millist infosisu vajatakse.
Näiteks, Autodesk Revit malli on lisatud omadus nimetusega AJ300_IfcClassificationReference, mille täitmisega tagame üldise klassifikaatori (rohelised tabelid) korrektset ülekandumist IFC faili struktuuri (vt näidet edasises peatükis). Samas sellist omadust ei ole vaja Autodesk Civil 3D näitel, sest seal kantakse üldine klassifikaator üle teisest andmestruktuurist (mitte meie poolt antud parameetriga).
Järgides CCI-EE loogikat, saab lisaks komponentide klassifitseerimisele määratleda ka nendega seotud ehitusressursid või siis projekti staadiumi jne. Selle kirjeldamiseks on omaette omadused, mis leitavad CCI-EE RI tabelist. Vaikimisi ei ole neid kõikidesse siin esitatud mallidesse lisatud, kuna neid omadusi võidakse täita ka modelleerimispaketi väliselt lähtuvalt geomeetrilise osa unikaalsetest CCI-EE koodidest (viitetunnusrühma väärtustest). Allpool näide omadustest, mis seda osa kirjeldavad.
- AC245_cciPAcode: <PA>EAG (projekteerimisele eelnev protsess, projekti administreerimine, eskiisi koostamine)
- AC205_cciRAcode: <RA>ABA (arendajad, kavandajad, planeerija)
- AC265_cciPPcode: <PP>### (pole veel määratud, seega jäävad kohatäitjana trellid, ###)
Märkus. Viitetunnuste ja viitetunnusrühmade loomine võib baseeruda erinevatel mallidel. Näiteks, lisaks fikseeritud väärtusele võid soovida lisada ka viite tabelile, kust see pärineb (samas määratleb seda valitud omaduse nimetus nagunii). Teisisõnu, lisaks väärtusele EAG (pane tähele omaduse nimetust eelnevast näitest), mis pärineb tabelist PA, võid soovida kaasata ka tabeli nimetuse koodi: <PA>EAG. Samas tuleb tähele panna, et sellega muutub automaatne viitetunnuse loomine, mistõttu tuleb leida viis, kuidas seda korrigeerida. Seega tasub läbi mõelda, kuidas valitud info esitusviisi kasutatakse sellele järgnevas infoedastuses / platvormil, kuhu seda üle kantakse. Jällegi on siin abiks infoedastuse eeskiri, millega see konkreetselt paika pannakse, et ei juhtuks olukorda, kus ühes failis/allikas ühtmoodi ja teises teistmoodi.
Nüüd, kus oleme avanud unikaalse ID üldisema olemuse ning toonud välja CCI-EE omadused, mis võimaldavad unikaalse ID kasutuselevõtmist, vaatame tarkvaralisi näiteid, kuidas see teatud ehitusinfo juures kasutust leiab. Esmalt üldisemas vaates, kus me kasutame küll konkreetseid tarkvarasid, kuid mille juures on oluline järgida, kuidas eelnimetatud omadusi täidetakse. Seega me ei lähe esimeses osas tarkvara spetsiifikasse ja toodud põhimõtteid tuleb iseseisvalt üle kanda mistahes muule 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.