Common data environment

Introduction

EN ISO 19650-1 põhikontseptsioonidele keskenduv standardiseeria esimene osa selgitab, kuidas CDE on tehniliste lahenduste ja protsesside töövoogude kombinatsioon.

Tavalisem on aga see, et digitaalsed lahendused nagu elektroonilised dokumendihaldussüsteemid (ingl electronic document management systems, EDMS) mängivad suurt rolli CDE lahenduste ja töövoogude juurutamisel. Kuid tuleb tunnistada, et ühe töövoo raames saab kasutada paljusid erinevaid tehnoloogiaid.

EN ISO 19650-2 näeb ette, et määrav osaline (või tema nimel tegutsev kolmas isik) pakub ja haldab CDE-d kõigi infokonteinerite haldamiseks, mida määrava osalisega kogu projekti eluea jooksul arendatakse ja vahetatakse iga elluviimise meeskonnaga. Seda nimetatakse standardis EN ISO 19650-2 osas kui projekti CDE.

Kuid EN ISO 19650-2 näeb ette ka seda, et elluviimise meeskonnad võivad rakendada ka oma (jagatud) CDE-sid (kuid mitte projekti CDE asemel). Selles juhendis toome ka näiteid just sedalaadi stsenaariumite kohta, mis võib informatsiooni haldamist keeruliseks muuta.

When is the CDE required?

EN ISO 19650-2 soovitab tungivalt, et projekti CDE oleks enne hankekonkursiga alustamist paigas, et informatsiooni saaks võimalike pakkujatega turvalisel viisil jagada.

Responsibility

Määrav osaline vastutab ühtse andmekeskkonna (CDE) loomise eest. Eeldusel, et kaasatud on teenuste ulatus, võib määrav osaline valikuliselt:

1. Tellida antud tegevus/teenus kolmandalt osaliselt.
2. Anda vastutus CDE majutuse, haldamise ja/või toeteenuse pakkumise eest määratud osalisele eeldusel, et tagatakse teenuste ulatus.

Guidance

Ühtse andmekeskkonna (CDE) lihtsustatud vaade seisneb selles, et see salvestab projektiandmed struktureeritud viisil, millele projektimeeskond omab turvalist ligipääsu. Sama oluline on see, et CDE toetab erinevaid informatsiooniga seotud töövooge. Töövoog võib olla dokumentide kinnitamise või vastuvõtmise protsess. Töövoog võib samamoodi olla ka andmete teatud liiki eraldamine ja valideerimine mudelist ning kirjetest varaga seotud andmestiku kontrolliks. Digitaalses keskkonnas peab CDE toetama töövooge, mis vastavad ärivajadustele. Mõnel juhul on vaja mitut CDE-d, kuna võib olla raske leida ühte süsteemi, mis vastaks kõigile vajadustele.

Types of common data environment

Kuigi CDE-s võib sõna "ühtne" kaasamine soovitada üht süsteemi kogu jagatud informatsiooni salvestamiseks, ei ole see alati võimalik, kuna kõigil tarkvarasüsteemidel on omad piirangud. Andmete jagamiseks peaks siiski olema ühtne strateegia ja kõikide andmete salvestamise asukoht peaks olema hästi mõistetav.

• Dokumendihaldus – see on ilmselt kõigist tarkvarasüsteemidest kõige tuntum, kuid tuleb tagada, et mõistetakse erinevusi: (a) organisatsiooni dokumentide haldamiseks kasutatava dokumendihaldussüsteemi ja (b) jagatud projektidokumentide jaoks kasutatava süsteemi vahel. Mõlemad pakuvad sarnast funktsionaalsust ja mõnda süsteemi saab kohandada nii, et see vastaks mõlema nõuetele. Süsteeme, mis võimaldavad projektimeeskonna liikmete vahel pilvepõhist jagamist, ei eksisteerinud veel mõned kümnendid tagasi ja sestap on need just viimase kümne aasta jooksul oluliselt arenenud.
• Korrashoiuplatvorm (FM) – FM-tarkvarasüsteemid (ingl facility management) on eksisteerinud peaaegu sama kaua kui dokumendihalduse süsteemid. Paljud olid algselt töölauarakendused, kuid on nüüdseks muudetud pilvepõhisteks rakendusteks. Nagu dokumendihalduse süsteemidki, sobivad mõned süsteemid paremini just käitamisinfo haldamiseks, samas kui teised süsteemid on suunatud varade kohta käiva informatsiooni kogumisele projekteerimise ja ehitamise etapi jooksul.
• Kvaliteedijuhtimine – CDE-d ja rajatiste haldamiseks kasutatavad süsteemid sisaldavad sageli kvaliteedijuhtimise funktsioone, mis võivad oluliselt suurendada kontrollide läbiviimiseks kuluvat aega ja vaeva. Need võivad hõlmata kohandatud kontrollnimekirju ja võimalust luua ja hallata ülevaatustest tulenevaid defekte. Paljud süsteemid sisaldavad nüüd tahvelarvutipõhiseid rakendusi, mis saavad ülevaatuse ajal probleemiga seotud asukohti täpselt määrata, fotosid seostada ja lisada üksikasjalikke märkmeid.
• Lepinguhaldus – süsteemid, mida kasutatakse lepingute edastamise haldamiseks, sealhulgas varajased hoiatused, projektijuhi juhised, hüvitise aktid jne. Keerukamad süsteemid võivad pakkuda iga suhtluse täielikku kontrolljälge, mis võib viia eelarve või programmi ulatuse muutumiseni.
• Kulude juhtimine – kulujuhtimise süsteemid võivad hõlmata mitmesuguseid süsteeme, mis hõlmavad näiteks:
  • Ärijuhtimise tarkvara, mis haldab ettevõtte kapitali- ja tööjõukulusid. Need võivad hõlmata mõningaid tarneahela halduse funktsioone. Neid süsteeme üldiselt ei jagata ja seega ei kujuta see endast CDE-d.
  • Suuremad kliendid ja töövõtjad kasutavad tavaliselt tarneahela haldustarkvara, et hallata süstemaatiliselt lepingutega seotud kulusid. Neid süsteeme saab jagada kontrollitult.
  • Eelarvestamise ning mahtude väljavõtteid kasutatakse kulude hindamiseks projekteerimise etapis. Mitmed süsteemid kombineerivad nüüd võimalusi koguste genereerimiseks nii 2D kui 3D tulemitest.
• Planeerimisega, ajakavaga ning programmiga seotud tarkvara – võimaldab planeerida ja kategoriseerida projekteerimis- ja/või ehitustegevusi ning sisaldab Gantti diagrammi vormingut, mis võimaldab luua sõltuvusi tegevuste vahel ühes nende algus- ja edasilükkumise aegadega. Mitmed neist süsteemidest ei ole veel täielikult pilvepõhised ja raskendavad seetõttu hõlpsamat koostööd ning informatsiooni jagamist.
• Varahaldus – ehitistes, kus on palju standardseid varasid (nt tervishoiuhooned), on olemas väljakujunenud tarkvarasüsteemid, mis liidestavad varanõuded varade elluviimisega (tarnega).

Minimum requirements

EN ISO 19650-2 sätestab CDE miinimumnõuded:

1. Igal infokonteineril peab olema kordumatu ID, mis põhineb kokkulepitud ja dokumenteeritud nimetamiskokkuleppel, mis koosneb eraldajaga eraldatud väljadest.
2. Igale väljale määratakse väärtus vastavalt kokkulepitud ja dokumenteeritud koode esitatavast standardist.
3. Igale infokonteinerile määratakse järgmised atribuudid:
   • Staatus (sobivus)
   • Läbivaatus
4. Infokonteinereid saab üle viia erinevate seisude vahel.
5. Infokonteineri seisu muutumise korral salvestatakse kasutaja nimi ning kuupäev.
6. Kontrollitud juurdepääs infokonteineri tasemel.

Recommended requirements

CDE funktsionaalsed ja mittefunktsionaalsed nõuded peaksid vastama määrava osalise ning projekti nõuetele. Ühel juhul on vaja lihtsat dokumendihaldussüsteemi, kuid mõnel juhul võib vaja minna keerukamat protsesside haldust, mis toetavad välitöid, varahaldust, kuluhaldust ja projektijuhtimist. Saadaval on mitmeid lahendusi ja mõnel juhul võib määrav osaline välja töötada spetsiaalse, enda ärivajadustele vastava, süsteemi.

Paljud organisatsioonid on täna eelistamas kindlat CDE-d, mida kasutatakse projektides, kus nad täidavad projektijuhi rolli, mida saab omakorda kasutada ka dokumendihaldussüsteemina, kus salvestatakse töös olevat informatsiooni. Määrava osalise poolt kasutatav süsteem võib olla aga erinev ning tihtipeale on tegemist süsteemiga, mis ei ühildu projekti elluviimise meeskonna poolt kasutatavaga. Seetõttu tuleb arvestada teatud ebaefektiivsustega failide alla-üles laadimisega ühest-teise süsteemi üleminekul tagades muuhulgas ka metaandmete ülekandmise. Näiteks, kuidas te teate, et määravale osalisele kontrollimiseks ning kinnitamiseks edastatud fail on täpselt see sama, mis teie süsteemis? On teatud protsessid, mida saab kasutada sedalaadi kontrolli tagamiseks, et vigu ei juhtuks või neid vähemalt minimeerida.

Alternatiiviks on märksa keerukamad süsteemid, kus mõlemad süsteemid suhtlevad omavahel, kuid see on ehitussektoris veel suhteliselt uus temaatika. Sarnaselt muudele, arenenumatele tööstusharudele, nagu jaekaubandus ja autotööstus, töötatakse selliste protsesside automatiseerimiseks välja rakendusprogrammide liidesed (API-d), mis vähendab nii tööjõukulu kui vigade tekkimise riski.

Security

CDE-s peaks olema vähemalt kaks administraatori õigustega isikut, kellel on CDE-s olevale projektile täielik juurdepääs. Administraatoriks peaks olema ühelt poolt infohaldur ning lisaks ka tema poolt määratud dokumendihaldur (kontrollija isikus). Mõned CDE-d võivad pakkuda ka piiratud administreerimise liidest, et anda teatud õigused ka veel lisakasutajatele. 

CDE administraatoril peaksid olema järgmised õigused:

• CDE kasutajakontode ligipääsude andmine ning tühistamine
• Kasutajagruppide loomine ning kasutajate sidumine/eemaldamine igast grupist
• Rollide loomine ning kasutajate sidumine/eemaldamine rolliga
• Rollide loomine ning rolliga seotud infokonteinerite ligipääsude sidumine
• Dokumentide staatuste loomine vastavalt EN ISO 19650-2 nõuetele

Audit trail

Kontrolljälg on standardne nõue kogu dokumentatsioonile sõltumata sellest, kas välised kvaliteedi tagamise süsteemid seda nõuavad või mitte. Lihtsamalt öeldes peaks kõigil kolmandate osalistega jagatud failidel olema kirje selle kohta, millal, kes ja mis põhjusel neid jagati. Kõiki järgnevaid muudatusi tuleks samuti jälgida, tagamaks, et kõik eelmise versiooni saajad mõistaksid, et eelmine versioon on asendatud.

Auditi või jälgitavuse huvides tuleks ideaaljuhul jälgida ka järgmist lisateavet iga dokumendi kohta, mida siis teatud viisil saaks raporteerida:

1. Milline isik dokumendi esitas
2. Esitamise kuupäev
3. Milline isik dokumendi kinnitas (mõned kinnitused võivad olla astmelised – näiteks konsultandi kinnitus, millele järgneb kliendi kinnitus jne)
4. Kinnitamise kuupäev
5. Millised isikud dokumenti vaatasid või alla laadisid
6. Vaatamise/allalaadimise kuupäev

Folders

Enamikel CDE-del on kasutusel ühiste atribuutidega failide salvestamiseks mõeldud kaustade või konteinerite kontseptsioon. Enamik teavad, mis asi on kaust ja seega loome neid tihtipeale rohkem kui pikas perspektiivis vajame. Kaustade lisamine CDE-sse pole aga nõutav ja kaustade arvu minimaalsena hoidmisel on teatud põhjendatud eelised, kuna kaustad muudavad turvalisusega seotud kaalutlused keerukamaks. Mõnel CDE-l on eelnevalt määratletud konteinerid, mida tuleb kasutada. Paljud pilvepõhised andmebaasisüsteemid sisaldavad filtreerimismehhanisme, mis võivad olla võimekamad kui kaustad, mis lubavad faile rühmitada, filtreerida ja sorteerida failinime, versiooni, oleku, töövõtu või muude faili metaandmete alusel. CDE-s on turvalisus ilmselt ainus põhjus, miks kasutada kaustasid, kuna turvalisusega seotud aspekte on kõige lihtsam rakendada kaustadele, mitte aga failidele, et minimeerida üldist keerukust. Samas, ainsad nõutavad kaustad võivad olla määratud kui tööandja, projektmeeskonna ning ehitaja vaatest. Kõik need kaustad võivad sisaldada iga töörühma jaoks alamkaustu. Turvalisust saab seejärel juhtida põhikaustade ja seejärel töörühma kausta põhiselt. Tavaliselt on igal töörühmal juurdepääs oma kaustast nii üleslaadimiseks, vaatamiseks kui allalaadimiseks, kuid ainult vaatamise ning alla laadimise õigus teistes kaustades.

Kui CDE võimaldab, tuleks failide versioonid linkida Tellija > Infovahetus alamkausta. Vastasel juhul võidakse luua “edastatud“ nimeline kaust, kuhu failid kopeeritakse. Võimaluse korral peaksid failid asuma samas kaustas, et saaks säilitada versiooni ja oleku kontrolli (vt joonist).

Joonis. CDE näidisstruktuur.

CDE kaustastruktuuri näide:

1. Jagatud ressursid
   • Tellija nõuded
   • BIM rakenduskava
   • Mõõdistused
2. Projekteerimine:
   • 2D mudelid (M2)
   • 3D mudelid (M3)
   • Animatsioonid (AF)
   • Vastuolude edastused (CR)
   • Koondmudelid (CM)
   • Joonised (DR)
   • Mudelite edastused (MR)
   • Visualiseeringud (VS)
   • Ruumikaardid (RD)
   • Ruumiplaanid (SA)
   • Tabelid (SH)
   • Spetsifikatsioonid (SP)
   • Arvutused (CA)
3. Projektijuhtimine:
   • Programmid (PR)
4. Kulujuhtimine:
   • Kuluarvestus (CP)
   • Kululoend (BQ)
5. Juhtimine:
   • Raport (RP)
6. Tervis ja ohutus:
   • Metoodika avaldused (MS)

Containers / files

Kõik meeskonnaliikmed peaksid CDE konteinerid nimetama vastavalt standardile, kasutades selleks ettenähtud välju. Infohaldusfunktsiooni täitvad isikud peaksid kehtestama projektipõhised väljakoodid, tagades ühtse failinimesüsteemi olemasolu.

Roles

Kui CDE süsteem seda võimaldab, tuleks kaustadele või konteineritele juurdepääsu andmiseks kasutada rolle. Lisaks administraatori rollile peaks infohaldur lisama igale töörühmale oma rolli, näiteks “Arhitekt“, “Ehitusinsener“ jne. Konkreetsete funktsioonide jaoks võib luua täiendavaid rolle, näiteks “BREEAM“ (ingl Building Research Establishment Environmental Assessment Methodology).

Distribution groups

Jaotusgrupid võimaldavad CDE-ga seotud toiminguid suunata vastavatele inimestele. Näiteks võib luua projekteerimismeeskonna jaotusgrupi, et tagada kõigi projektmeeskonna liikmete teavitamine.

Iga jaotusgrupi kohta tuleks salvestada järgmine teave:

• Jaotusgrupid
• Tegevus
• Toimingule reageerimise aeg

CDE haldamise eest vastutav isik peaks pidama igas jaotusgrupis kasutajate loendit.

CDE forms

Võimaluse korral tuleks kirjavahetuse automatiseerimiseks kasutada vorme, eriti kui on nõue, milles kaasatud mitu osalist ja sellest lähtuvalt tagatakse otsuste õigeaegne vastuvõtmine. Vorme saab kasutada infopäringute (RFI), tehniliste esildiste, projektlahendusega seotud probleemide ja paljude muude vastust nõudvate edasiminekute registreerimiseks ja jälgimiseks. Mõnel CDE süsteemil on vormide loomise süsteemid ning tüüpiliste töövoogude jaoks võivad olla eelmääratletud vormid. Lepingulised nõuded tuleks üle vaadata, et tagada CDE vormide vastavus nõuetele.

Components of the CDE

Tihtipeale arvatakse, et CDE puudutab rohkem tehnoloogiat ja vähem töövooge. Tegelikult on oluline, et kõigepealt töötataks välja töövood ja seejärel valitakse töövoogu hõlbustavad lahendused.

Samuti võib mõista, et vara- või projektiinfo haldamisel domineerivad üksikud tehnoloogilised lahendused. See pole nii ja erinevat tüüpi varade või projektiinfo käsitlemiseks on palju lahendusi. Näiteks võivad olla dokumendihaldustööriistad projektfailide jaoks, lepinguhaldustööriistad äriinfo haldamiseks, e-posti haldustööriistad kirjavahetuse jaoks ja mobiilsed tööriistad platsi kvaliteediandmete kogumise/märkimise jaoks. Igal lahendusel võib olla mitu erinevat töövoogu, mis tagab informatsiooni hoolikalt kavandamise, jagamise, salvestamise, haldamise ja hankimise ning selle õigeaegsuse, korrektsuse, täielikkuse ja järjepidevuse.

Information container states

Infokonteineri arenedes on sellel erinevad olekud. Allolev joonis (EN ISO 19650-1, joonis 10 baasil) illustreerib neid olekuid infokonteineri töövoo osana. See joonis on tegeliku protsessi lihtsustus ja infokonteinerid võivad läbida erinevaid töövooge, kasutades potentsiaalselt mitut lahendust, nagu märgitakse ka edaspidi.

Joonis. Ühtse andmekeskkonna (CDE) kontseptsioon (EN ISO 19650-1, joonis 10 baasil).

Kas aga oled mõelnud, et nende infokonteinerite olekute ekvivalendid esinevad enamikus informatsiooni tootmisprotsessides, sealhulgas e-kirjades, kuigi need on kasutajale sageli nähtamatud. Näiteks kui hakkate e-kirja kirjutama, on see justkui "Töösolev protsess“. Teie e-posti tööriist võib ka teie e-kirjad automaatselt arhiveerida. Võib-olla peab keegi teie e-kirja tundlikkuse tõttu enne selle lõpliku versiooni saatmist kinnitama – see on nagu "Jagatud“ olek. Kui saadate e-kirja õigele adressaadile, on see nagu selle "Avaldatud“ olek. Kõik teie ja adressaadi e-posti tööriistad pakuvad ka e-kirjade arhiveerimise võimalust.

Metadata

Oluline on välja selgitada, mida metaandmete all mõeldakse, kuna EN ISO 19650 seeria ei paku ametlikku määratlust. Metaandmed on määratletud kui "mingeid andmeid kirjeldavad andmed ehk nii-öelda andmed andmete kohta" (Wikipedia). Leiab ka lihtsamaid sõnastusi, näiteks „andmed andmete kohta“ (ingl data about data, ISO/IEC 9075).

EN ISO 19650 seeria teeb selgeks, et autorid hoiavad oma informatsiooni üle ranget kontrolli kogu selle väljatöötamise ajal. Autoril on soovitatav seda saavutada metaandmete määramise abil. See teavitab, millises versioonis infokonteiner parasjagu on ja milleks seda saab kasutada.

Metaandmete määramise ulatus võib ulatuda kaugemale EN ISO 19650 seeria soovitustest ja nõuetest, näiteks hõlmates varakeskset informatsiooni.

Information container management through metadata assignment

Metaandmete nõue tekitab väljakutse, kuidas saab metaandmeid CDE lahenduste vahel üle kanda. Määraval osalisel, määratud juhtivatel osalistel ja määratud osalistel võivad olla oma CDE lahendused, mis on osa üldisest projekti CDE töövoost ja lahendustest. On oluline, et need CDE lahendused töötaksid tõhusalt koos CDE töövoo osana informatsiooni arendamise ja vahetamise ajal. Need lahendused ei pruugi aga üksteisega ideaalselt liidestuda, mistõttu on metaandmete automaatne edastamine võimatu.

Varasemalt kasutatud e-posti analoogia kohaselt on peaaegu kõik e-posti tööriistade pakkujad kasutusele võtnud standardse vahetusprotokolli (näiteks POP), mis võimaldab e-kirjade sujuvat liikumist olenemata nende saatmiseks või vastuvõtmiseks kasutatavast tööriistast/lahendusest.

Samas kui infovahetuse tähenduses selline standard hetkel puudub. See tähendab aga, et tuleb mõelda, kuidas saab üht infokonteinerit ja selle metaandmeid ühest süsteemist teise üle kanda. Tegelikkuses on see sageli käsitsi tehtav protsess, mis nõuab iga vastuvõtva süsteemi infokonteineri metaandmete ümberregistreerimist.

Allolev joonis illustreerib, kuidas projekti CDE töövoo osana on vaja kahte erinevat CDE lahendust, et koos töötada. Iga lahendus haldab infokonteinereid erinevalt.

CDE lahendust 1 (jagatud CDE) haldab elluviimise meeskonna määratud juhtiv osaline. CDE lahendus 1 haldab infokonteinereid ühe rühmana olenemata tüübist. See kasutab metaandmete määranguid, et võimaldada kasutajal infokonteinereid vastavalt filtreerida. Näiteks saab kasutaja just olekukoodi abil filtreerida endale sobivaim infokonteinerite täpsem vaade.

Joonis. Illustratsioon kahest erinevast CDE lahendusest, kus metaandmete määramine tuleb üle kanda.

CDE lahendus 2 on projekti CDE, mida haldab määrav osaline ja mis haldab teavet kaustastruktuuride ja metaandmete määrangutega. Enne infokonteineri teisaldamist CDE lahendusest 1 > CDE lahendusesse 2 on oluline kokku leppida, kuidas metaandmeid saab edastusprotsessi ajal säilitada või üle kanda.

Näiteks CDE lahendus 2 ei võimalda spetsiaalset klassifitseerimise metaandmete välja. Sellest tulenevalt on määrav osaline esitanud klassifikatsiooni metaandmete välja kaustanime kaudu (antud juhul eraldades joonised vastavalt iga joonise olemusele). CDE lahenduse 2 paigutus peaks kajastama klassifikatsiooni metaandmete kasutamist CDE lahenduses 1. Sellise lähenemisviisi tulemuseks võib olla aga suurema osa metaandmete käsitsi ülekandmine (kuna need tuleb sel ajal trükkida või eelnevalt valida vahetuse käigus). Tuleks jälgida, et kaustapuud metaandmeid täiendaksid, mitte neid dubleeriksid.

Classification through metadata assignment

Infokonteineri klassifikaator
EN ISO 19650-2 punkt 5.1.7 ja ISO 19650-3 punkt 5.1.9 nõuavad, et infokonteineritele määratakse klassifikatsiooni metaandmed vastavalt standardile EN ISO 12006-2. Mitmed klassifitseerimissüsteemid vastavad EN ISO 12006-2 nõuetele ja seeläbi on soovitatav neid ka antud kontekstis eelistada.

Assigning metadata within CDE solutions

Klassifikatsiooni metaandmete määramine CDE lahenduse infokonteineritele nõuab:

• Kuidas tuvastada infokonteinerit ja/või selle sisu
• Kuidas edastada infokonteinereid kasutatavate CDE lahenduste vahel.

Varasemalt esitatud joonis näitas, kuidas saab klassifitseerimisega seotud infot üle kanda kahe CDE lahenduse vahel, mis lähenevad metaandmete kasutamisele erinevalt.

CDE lahenduse 2 puuduseks on (potentsiaalselt) paljude kaustade käsitsi loomine. Kuid kui see on õigesti rakendatud, annab see eelise ühetaolisest struktuurist (klassifikatsioonist), mis võimaldab igal kasutajal infokonteinereid ühetaoliselt filtreerida. Näiteks “PM_40_40 : Projektjoonised” järgi.

EN ISO 19650-2 ega EN ISO 19650-3 ei anna klassifitseerimise kohta täpsemaid üksikasju, kuid on oluline, et klassifikaatorit kasutatakse ennekõike infokonteineri sisu, mitte infokonteineri vormi tähistamiseks (vormi käsitletakse infokonteineri nime struktuuri väljana).

Revision control through metadata assignment

Infokonteinerite väljatöötamisel on oluline jälgida muudatusi eelmiste ja praeguste läbivaatamiste ja versioonide vahel. Sama oluline on jälgida, millist läbivaatust ja versiooni kellegagi jagatakse.

EN ISO 19650-1 soovitab, et infokonteinerite läbivaatamissüsteem järgiks kokkulepitud standardit. Allpool on toodud UK näide. 

Joonis. Läbivaatamise metaandmestik, mis koosneb kolmest alamkomponendist.

Revision control during Work in Progress (WIP)

Töös oleva (ingl work in progress, WIP) infokonteinerite versioonihaldus võimaldab autoril hallata oma tööd ja vältida informatsiooni kadumist selle arendamise käigus. Allolev joonis illustreerib versioonihalduse eeliseid. Joonisel näidatud stsenaariumid esitavad, et kui töös oleku ajal kaasatakse läbivaatamise juhtimist, on autoril selge ülevaade nende informatsiooni arengutest ja ta saab vajadusel naasta varasemale versioonile.

Joonis. Illustratsioon töösoleku versioonikontrolli eelistest.

Revision control of Shared information

Alloleval joonisel on jagatud oleku versioonid identifitseeritud kahekohalise täisarvuna (näidatud tumesinises kastis koos ingliskeelse lühendiga WIP ehk work in progress). See jälgib läbivaatamist, mida jagatakse väljaspool teostaja töörühma.

On oluline, et läbivaatamise süsteem kohandaks järjekindlalt seda iteratiivset lähenemist, mis hõlmab mitut töösolekut (WIP) ja jagatud versiooni ühe infokonteineri ulatuses. Joonis esitab protsessi pärast WIP ja jagatud informatsiooni esimest läbimist, illustreerides informatsiooni arendamise kahte täiendavat iteratsiooni.

Joonis. Töösoleva ja jagatud versioonide läbivaatuste näidisprotsess.

Revision control of Published information containers

Avaldatud (lepinguline) informatsioon on teave, mille määratud juhtiv osaline on autoriseerinud ja seejärel määrav osaline vastu võtnud. Infokonteiner on äratuntav kui avaldatud selle läbivaatamise koodis oleva prefiksi C kaudu (tegemist on UK näitega). See aitab infokonteineri saajatel selgelt eristada esialgset (P) ja avaldatud (C) sisu.

Pange tähele, et mõned infokonteinerite tüübid ei pruugi kunagi jõuda avaldatud olekusse. Näiteks võivad sageli ainult koordineerimise eesmärgil kasutatavad konstruktsioonide geomeetrilised mudelid jääda esialgseteks. Samas kui teisi infokonteineri tüüpe, sealhulgas neid, mis on genereeritud konstruktsioonide geomeetrilistest mudelitest, näiteks 2D-jooniseid ja spetsid, võib tõepoolest vaja minna määramise ning lepingutest tulenevate kohutuste täitmisel.

Joonis. Illustratsioon, kuidas läbivaatamise metaandmed eri olekuid eristavad.

Status allocation through metadata assignment

Olekukoodid
EN ISO 19650 seeria määratleb, et infokonteineritele tuleks metaandmetena määrata olekukood, mis näitab infokonteineri lubatud kasutamist (vt EN ISO 19650-1 punkt 12.1).

Olekukoodi määramise põhjus on:

(1) Teha saajale selgeks, milleks infokonteinerit kasutada, ja täpsemalt, milleks seda ei tohi kasutada.

UK defined standard status codes

Allolevalt toome UK näite nende EN ISO 19650-2 rahvuslikust lisast. Selles on toodud metaandmete määramiseks standardiseeritud olekukoodid (vt allolevat tabelit). Igal tabelis toodud koodile on lisatud ka kirjeldus, mida see endas teavitusena markeerib. Olekukoodide määramisel on autoritele saadaval ka läbivaatamise juhend. Näiteks praegu ülevaatamisel olevat infokonteinerit (olekukood S3) ei tohiks kasutada lepingulistel eesmärkidel, nagu materjalide hankimine, kulude kokkulepe või ehitustööde läbiviimine.

Jagatud informatsiooni olekukoodides kasutatakse informatsiooni iteratiivsel arendusel tavaliselt koode S1, S2 ja S3. Need on tüüpilised koodid, mida tööetapis tõenäoliselt kasutatakse. Koode S4 ja S5 kasutatakse tavaliselt tööetapis või selle lõpus või siis, kui esitatakse ametlik infovahetus määrava osalisega (kliendiga).

Tabel. UK näide olekukoodide valikust infokonteinerile.

Tabel. Näidisnimekiri olekukoodi An numbrilistest väärtustest.

Status codes driving CDE workflow

Allolev joonis ja tabel illustreerivad, kuidas olekukoodid juhivad infokonteinerite arendamist ja vahetamist ühe osana CDE töövoost, mis on kooskõlas standardi EN ISO 19650-2 punktidega 5.6 ja 5.7.

Siin toodud konkreetne näide on seotud eelprojektile analoogse vaatega ja näitab:

• Kuidas EN ISO 19650-2 alalõigud tegelikkuses iga infokonteineri puhul iteratiivselt kehtivad?
• Kuidas infokonteinerid saavad töösolekute ja jagatud olekute vahel mitu korda ringi käia, enne kui need avaldatakse?
• Kuidas olekukood teatab informatsiooni saajale, milliseid toiminguid on vaja teha
• Kuidas see eelprojektina määratletud ülesanne loob oma informatsiooni geomeetrilise mudelina, mis on kooskõlastatud teiste geomeetriliste mudelitega ja/või nende esitustega (esitus annab lähteinfo teatud kindlal kujul, antud juhul geomeetrilise mudeli sisu läbi lõigete, vaadete või plaanide)?
• Kuidas koordineeritud informatsioon seejärel selle algvormingust eksporditakse kommenteerimiseks valmis joonistena?
• Kuidas tuleb pärast kommentaaride saamist algset informatsiooni töösolevas versioonis värskendada enne joonise uuesti väljastamist?
• Kuidas peab uuesti välja antud joonise autoriseerima ja kinnitama enne kui see muutub avaldatud informatsiooniks?
• Lihtsuse huvides on alloleval pildil näidatud joonise edenemine selle algsest geomeetrilisest mudelist autoriseerimise ja kinnitamiseni. Tegelikkuses liiguksid kõik infovahetuse nõuetes määratletud infokonteinerid läbi sarnase protsessi (üks selline infokonteiner oleks viidatud joonise genereerinud geomeetriline mudel).

Joonis. Illustratsioon infokonteinerist, mis liigub olekute vahel.

Tuleb märkida, et eelneval joonisel kujutatud protsess ei ole tegelikkuses tõenäoliselt nii lineaarne. Näiteks võivad taustal jätkuda pooleliolevad tegevused (etapid 1, 2, 5, 6 jne), samal ajal kui informatsioon edeneb läbivaatamisprotsessis (sammud 3, 4, 7 ja 8). Selle põhjuseks on asjaolu, et disain on sujuv ja progressiivne ja ei pea ülevaatamise ajal tingimata kommentaare ootama.

Tabel. Näide infokonteineri iteratiivsest arendusest.

Kuigi see protsess näib olevat pikk, illustreerib see EN ISO 19650 laiendatud vaadet riiklikute lisade kaasamisel läbi iteratiivsete infokonteinerite arenduse. Tegelikkuses saab ja tuleks leida efektiivsemaid töövooge lähtuvalt valitud ja võimekamat CDE-d silmas pidades.

Examples of status codes

Allolev tabel annab ülevaate sellest, millal võib teatud olukordades mõnda olekukoodi kasutada. Antud näide baseerub UK rahvuslikul lisal. Muuhulgas on selles märgitud, et koode saab laiendada (või samal põhimõttel välistada), et need vastaksid konkreetsetele projektinõuetele, eeldusel, et nõutavad koodid on dokumenteeritud projektiinfo standardis ja infoprotokollina kokku lepitud.

Tabel. Olekukoodide rakendus.

Checklist of actions/key points to consider

EN ISO 19650-2 alalõikude viited on näidatud sulgudes.

• Kas määrav osaline (5.1.4) on projektiinfo standardis määratlenud mis tahes projektipõhise standardse olekukoodide ja läbivaatamissüsteemi laienduse ja kas need on üle vaadatud või muudetud (ja määrava osalisega kokku lepitud), et see vastaks iga määratud juhtiva osalise (5.3.2, 5.4.1) elluviimise nõuetele?
• Kas määrav osaline (5.1.4) on vara või projektiinfo standardis määratlenud klassifitseerimissüsteemi ja kas määratud juhtiv osaline on selle üle vaadanud või muutnud (ja määrava osalisega kokku lepitud), et see vastaks määratud juhtiva osalise (5.3.2, 5.4.1)  elluviimise nõuetele?
• Kas määrav osaline (5.1.4) on vara või projektiinfo standardis määratlenud infokonteineri ID nimetamise standardi ja kas määratud juhtiv osaline (5.3.2, 5.4.1) on selle üle vaadanud või muutnud (ja määrava osalisega kokku lepitud), et see vastaks elluviimise nõuetele?
• Kas nimetamise standard määratleb, kuidas mudelite edastamistele/ekspordile antakse erinevad konteinerite nimed? Näiteks, tuleks IFC faile (STEP vormingus) nimetada erinevalt nende algallika geomeetrilistest mudelitest ja PDF-faile erinevalt nende loomulikest 2D-jooniste ekvivalentidest (et ühelgi konteineril ei oleks sama ID-d). Pange tähele, et iga kord, kui algset infokonteinerit värskendatakse, tuleks värskendada ka seotud eksporte (niivõrd kui algse infokonteineri värskendamine neid mõjutab). See nõuab infokonteineri autorilt väga suurt tähelepanu:
  • seotud värskenduste eksportimine;
  • algse infokonteineri ja sellest eksporditud infokonteinerite värskenduste kontrolljälje tagamine.
• Kas kõik potentsiaalsed CDE lahendused on üle vaadatud, et tagada nende kokkulepitud metaandmete määramise toetamine (5.1.5, 5.5.2)?
• Kas potentsiaalse(te) CDE lahendus(te) valimisel on kaalutud turvakaalutlusi tagamaks, et juurdepääsuõigusi saab määrata individuaalsel ja organisatsiooni tasandil (5.1.5, 5.3.2, 5.5.2)?
• Kui CDE töövoo rakendamiseks kasutatakse mitut CDE lahendust, millest osa võib kuuluda või olla hallatud erinevate organisatsioonide poolt, kas CDE töövoog on üle vaadatud, et tagada infokonteinerite sujuv liikumine iga CDE lahenduse kaudu (5.5.2)?
• Kas CDE lahendusi on testitud, et tagada metaandmete määramiste ülekandmine nende vahel?
• Kas on kokku lepitud, kuidas toimub infokonteinerite käsitsi või automaatne ülekandmine erinevate lahenduste vahel?
• Kas on rakendatud ja dokumenteeritud üheselt mõistetav CDE töövoog selle kohta, kuidas igat tüüpi infokonteinereid arendatakse > kontrollitakse > jagatakse > autoriseeritakse > kinnitatakse > avaldatakse > arhiveeritakse? (seotud punktiga 5.5.2)
• Kas varaga seotud tegevusel või projektil on selge dokumenteeritud standardmeetodite ja protsesside kogum, kuidas infostandardis määratletud metaandmete määramised infokonteineritele määratakse (punkt 5.5.3)?
• Kas on määratletud, milliseid klassifikatsioonisüsteemi tabeleid/komplekte rakendatakse teatud tüüpi informatsioonile/infokonteineritele?
• Kas iga olekukoodi tähendus ja selle kasutamise piirangud on kinnitatud?
• Kas on kinnitatud, kuidas uued vara- või projektipõhised koodid genereeritakse, kokku lepitakse ja dokumenteeritakse?
• Kas on selgitatud, kuidas iga metaandmete määramine CDE lahenduses (igaühes) on tehtud?
  

Summary

Antud õppematerjal esitas täiendatud vaate ühtse andmekeskkonna olemusele. Siintoodut saab kasutada viitena kui soovitakse rakendada EN ISO 19650 põhimõtteid vara, projekti, määramise või ettevõtte kontekstis.