Asset Information Requirements

Introduction

Selles moodulis keskendume varaomanikele, kes soovivad määratleda informatsiooni, mis on vajalik ehitatud vara käitamiseks ja hooldamiseks, mis on kooskõlas organisatsiooni varahalduse strateegiaga.

When are AIRs Established?

Vara infonõuded (AIR) tuleb kehtestada enne mis tahes seotud määramist. Vara infonõuded kehtivad isikute või funktsioonide kasutamiseks, kes vastutavad varade kasutamise ja hooldamise eest. Need ei ole ette nähtud hankedokumentatsiooni lisamiseks; siiski on mõistlik tagada, et hankedokumentidesse lisatakse asjakohased väljavõtted, et pakkujad hindaksid varade informatsiooni esitamiseks vajalikke jõupingutusi. Üksikisikud ja funktsioonid, kes koostavad infovahetuse nõuded (EIR), peavad viitama AIR-idele.

Responsibility

Määrav osaline vastutab varade infonõuete kehtestamise eest. Vara infonõuete koostamist võib juhtida ettevõttesisene meeskond, kes vastutab varade ja ehitiste korrashoiu eest. Vara infonõuded ei ole ette nähtud hankedokumentidesse lisamiseks.

Hankedokumentatsiooni koostamisel vastutab määrav osaline selle eest, et üksikasjalikud varanõuded sisalduksid infovahetuse nõuetes (EIR). Projektiinfo standardisse tuleks lisada standardsed nõuded, nagu hooldatavate varade ajakava või asjakohased atribuudid. Kõik varade loomise, heakskiitmise, jagamise, kontrollimise, kasutuselevõtu ja üleandmise metoodikad tuleks dokumenteerida projektiinfo tootmismeetodites ja -protsessides.

Määratud juhtiv osaline vastutab selle eest, et iga infovahetuse ajal määravale osalisele esitatavad andmed oleksid kooskõlas projektiinfo standardiga. Määratud juhtiv osaline peaks läbi vaatama projektiinfo tootmismeetodid ja -protsessid seoses varade info loomise, heakskiitmise, esitamise ja vastuvõtmise nõuetega. Määratud juhtiv osaline vastutab lõpliku läbivaatamise eest, enne kui varade info esitatakse määravale osalisele heakskiitmiseks.

Varade projekteerimise eest vastutav elluviimise meeskond peaks andma informatsiooni nende varade kohta, mille eest nad vastutavad. Pärast määramist ja ettevalmistusperioodi jooksul peaks määratud juhtiv osaline tagama, et vastutus varade eest jaotatakse iga töörühma vahel. Määratud juhtiv osaline peaks koostama üksikasjaliku vastutusmaatriksi, mis määrab, kes mida modelleerib ja millal. Hoolikalt tuleks planeerida varasid, mis on integreeritud läbi mitme erivaldkonna, nt vihmavee väljalaskeavad katuses ja sisemine vihmaveetoru, mis võivad olla erinevate valdkondade poolt projekteeritud. Määratud juhtiv osaline peaks kontrollima, kas varade klassifitseerimise süsteem on ette nähtud, ja kui on, siis lisama selle vastutusmaatriksisse.

Määratud juhtiv osaline vastutab projekteerimis- ja/või ehitusinfo nõuete dokumenteerimise eest BIM rakenduskavas. Näiteks võib määratud juhtival osalisele olla lisanõudeid varade haldamise kohta ehitamise ajal. Kvaliteedi tagamise ja eeskirjadele vastavuse tagamiseks saab varade olekut jälgida alates nende täpsustamisest kuni tarnimiseni, paigaldamiseni, kontrollimiseni ja seejärel tahvelarvutite või telefonide abil süsteemi kaudu kasutusele võtmiseni. Kui sellist protsessi ei ole projektiinfo tootmismeetodites ja -protsessides täpsustatud, peaks määratud juhtiv osaline selle BIM rakenduskavas kajastama.

Standards and Guides

Organisatsioonid, kes soovivad kehtestada vara infonõudeid, peaksid üle vaatama järgmised standardid:

• EN ISO 19650-3 – Hoonete ja rajatistega seotud info, sealhulgas ehitusinformatsiooni modelleerimise (BIM) korraldamine ja digitaliseerimine. Infohaldus ehitusinformatsiooni modelleerimise abil. Osa 3: Varade käitamisetapp.
• ISO 55000 – Varahaldus. Ülevaade, põhimõtted, terminoloogia.
• ISO 55001 – Varahaldus. Juhtimissüsteemid. Nõuded.

Guidance and examples

Järgnevalt vaatame alateema kaupa varade infonõuetega seotud põhikomponente.

Asset information requirements

Vara infonõuete ettevalmistamisel peaks määrav osaline tegema koostööd kõigi asjaomaste sidusrühmadega, kes vastutavad varade eest. See võib hõlmata ehitiste haldajaid, operaatoreid, hooldustöötajaid, organisatsioone, kellel on varade hooldamise teenusetaseme lepingud, kindlustusettevõtteid ja finantsosakonda.

Vara infonõuetes tuleks arvesse võtta:

• Varade omandiõigus ja nendega seotud informatsioon
• Nõutav informatsioon nii vara gruppide kui ka üksikute varade lõikes
• Päästiksündmused:
  • Projekti algatamine uue vara loomiseks
  • Varade väljavahetamine
  • Suuremahulised tööd vara kallal
  • Väikesemahulised tööd vara kallal
  • Vara ülevaatus
  • Vara hooldustööd, olenemata sellest, kas see on planeeritud või ennetav
  • Kasutusea lõputööd, nagu käitusest kõrvaldamine, lammutamine, deaktiveerimine ja konserveerimine
  • Vara riskianalüüs
  • Vara väärtuse muutus
  • Muudatus vara suhtes kehtivates regulatsioonides
  • Reguleeriva asutuse nõutud informatsiooni muutmine
  • Muutus organisatsioonilistes nõuetes
  • Omaniku muutus
  • Operaatori vahetus
  • Korrashoidja vahetus

Tegevuse toetamiseks vajalik informatsioon:

• Kavandatud parenduste rahaline kasu
• Vahend vara tootluse ennustamiseks
• Vara mittekättesaadavuse või ebaõnnestumise tegevus- ja finantsmõju
• Alternatiivsete kapitaliinvesteeringute elukaarekulude võrdlused
• Garantiide aegumiskuupäevad
• Hinnang vara majandusliku eluea lõppemisele
• Varade toimimise kvaliteedieesmärgid
• Varahalduse ja kinnisvarahalduse teenusetasemed
• Vara ülalpidamiskulud
• Varade asendusväärtused
• Planeeritud tulude ja kulude finantsanalüüs
• Plaanidest kõrvalekaldumise finantsmõju nt hoolduse edasilükkamine 6 kuu võrra
• Üldine finantstulemus
• Varadega seotud riskide tuvastamine, hindamine ja kontroll

Enne projektlahenduse hankimist peaks määrav osaline:

• Pidama nõu sidusrühmadega ja tegema kindlaks äritegevuseks vajaliku graafika või ruumiandmed. Näiteks võib kinnisvaraosakond nõuda kaarte või plaane, mis näitavad iga kinnistu üleandmise aega ja selle kasutamist planeerimise eesmärgil.
• Pidama nõu sidusrühmadega ja tegema kindlaks äritegevuse andmenõuded. Näiteks võib finants- või projekti kontrollmehhanismidel juba olla kasutusel klassifitseerimissüsteem, mida kasutatakse kulujuhtimiseks ja ajakavaks.
• Pidama nõu vara haldavate sidusrühmadega. Need võivad olla ettevõttesisesed, kasutades FM-süsteemi, või korrashoiuteenuse võib tellida väljast, kasutades valdkonna standardseid või eritellimusel valmistatud süsteeme. See võib olla ka mõlema kombinatsioon. Näiteks saab enamikku varadest, välja arvatud sprinklersüsteemid, hallata ettevõttesiseselt.
• Valmistama ette vara infonõuded (AIR)
• Koostama tegevuskuludesse kuuluvate varade registri
• Tegema kindlaks kasutuses olevate varade atribuudinõuded. See võib hõlmata iga vara jaoks ühist põhiatribuutide komplekti, nt vara ID; atribuute, mis on ühised teatud tüüpi varadele, nt mehaanilised seadmed ja atribuudid, mis on spetsiifilised teatud varatüübile, nt soojuspump.
• Valmistama ette varainfo infovahetuse nõuded, võttes arvesse iga määramise vastutust ning tööplaani
• Dokumenteerima, kuidas varainfot luuakse, kogutakse, üle vaadatakse ja aktsepteeritakse

Asset information and BIM models

BIM mudelid on sisuliselt 3D esitusega andmebaas. Osa andmetest on parameetrilised projektandmed, mis näiteks võimaldavad esitada kahte identset tüüpi objekte, mis erinevad ainult mõõtmete poolest, nt laius, pikkus või kõrgus. Lisada saab ka muud andmesisu, näiteks tuleohutus- või akustilise nõuete tagamisega seotud andmeid. Lisada saab ka andmeid, mida kasutatakse käitamise ja korrashoiu kontekstis. Informatsiooni saab esitada tabelitena või esitada siltidena 2D või 3D vaadetel/plaanidel. Mõned tarkvaralahendused on võimelised andmeid mudelitega kahesuunaliselt sünkroniseerida.

Kui BIM mudeleid sihipäraselt kasutada, on need oluliselt võimekamad kui 2D CAD süsteemide poolt pakutav, kuna nii 2D kui 3D geomeetria ja sellega seotud andmed on sünkroonis. Samuti on oluline märkida, et kogu varainfo ei pea olema mudelites. Vaatame siinkohal mõningaid BIM mudelite eeliseid aga ka puuduseid.

• Eelised
  • Informatsioon on üheselt seotud vara olemasolu või selle puudumisega. Näiteks kui uks lisatakse või eemaldatakse, kajastub see ukse spetsis, kus kõiki andmeid saab hallata ühest kohast. Seda ei saa öelda CAD-jooniste kohta, kus uks on paigutatud plaanidele, vaadetele, lõigetele, tabelitesse ja spetsifikatsioonidesse, mida tuleb iga ukse või uksetüübi lisamisel või eemaldamisel käsitsi koordineerida.
• Puudused
  • Andmete hulk võib oluliselt mõjutada mudelite andmemahtu
  • Mitte igaüks pole võimeline mudeleid looma ja vaatama. Peavad olema vahendid, mis võimaldavad neil, kes ei tunne mudeleid, informatsiooni vaadata/kontrollida. Pilvepõhised lahendused lihtsustavad antud puudusest üle saama.
  • Suuremate projektide puhul jagatakse andmed paljude erinevate mudelite vahel, seega peab olema tagatud, et igal (osa)mudelil on kõigi asjakohaste varade jaoks täpselt samad atribuudid
  • Kuigi BIM-süsteemid on tegelikult andmebaasid, ei saa neid pidada andmehaldussüsteemideks. Keerulisi päringuid ja aruandlust saab kõige paremini teha siis, kui mudelid on lingitud või imporditud mõnda andmehaldussüsteemi.

Tänasel päeval on suundumus selle poole, kus mudelid ja nendega seotud andmed on pilveteenuses lingitud nii nagu paljud muud tüüpi andmed. See pakub arvukalt võimalusi projekteerimis- ja ehitusandmete kontrollimiseks, analüüsimiseks ja jagamiseks. Samuti avab see ka võimalused tehisintellektile (ingl artificial intelligence, AI) ja masinõppele (ingl machine learning, ML), mida saab kasutada esitatud andmetest õppimiseks. Näiteks kui ruumide külgnevuse jaoks on kehtestatud reeglid, saab AI abil analüüsida, kas projektlahend rikub neid reegleid või see pole optimaalne.

Kui just ei kasutata keerukamat pilvepõhist süsteemi, koosneb üleandmisinfo mudelitest ja vararegistritest. On oluline, et see informatsioon sünkroniseeritakse mudelite ja vararegistrite ning määratud juhtiva osalise vahel ning elluviimise meeskond peaks kaaluma andmete säilitamiseks sobivaid protsesse. Kui kogu informatsioon lisatakse ja hallatakse mudelitena, peaksid mudelite autorid eraldama andmed vararegistritesse, mis tagab informatsiooni ühetaolisuse. Kui need lisaandmed asuvad teistes andmebaasides, tuleks andmete väljavõtmiseks ja vararegistrisse liitmiseks kasutada sobivaid tööriistu. Informatsiooni dubleerimise või kadumise vältimiseks on oluline varainfot hoolikalt planeerida.

Asset information and model complexity

Mudelid on enamike failidega võrreldes üsna mahukad. Need võivad olla ka väga keerulised ja sisaldada palju detaile. Alltöövõtja mudelid, näiteks konstruktsiooniterase mudelid, võivad sisaldada detaile, nagu mutrid ja poldid. Kuigi need mudelid näevad visuaalselt suurepärased välja ja võivad koos valideerimisega esitada teostustinfot, võivad need liialt koormata varahaldussüsteemi, kuna selline detailide hulk pole sageli vajalik. Kuigi valminud mudelid annavad väga hea ülevaate sellest, mis on ehitatud, võib ehitiste haldamiseks kasutatavaid mudeleid olla vaja redigeerida, samas tagades, et see ei mõjutaks nende toimivust.

Assets information and the plan of work

Füüsilist vara esindavate digitaalsete mudelite koostamisel tuleb programmiliselt arvestada kolme olulise aspektiga:

1. Millal vara modelleeritakse? Sarnaselt reaalsele maailmale peab mõni modelleerimine olema teistest modelleerimisest ülimuslik ja sageli tuleb seda projekteerijate vahel kooskõlastada. Näiteks ei saa laele lisada laes olevaid tehnosüsteeme nagu plafoonid või suitsuandurid, kui see (lagi) pole arhitekti poolt modelleeritud.
2. Millist detailsust modelleerimisel kasutatakse? See võib projekti igas etapis muutuda, kuid põhimõtteliselt on tõenäoliselt kolm erinevat etappi, milleks on eel-/põhiprojekt, tööprojekt ja ehitamine. Projekteerimisetapis kõike ei modelleerita ja seal, kus see on modelleeritud, on see madalama detailsusega, kuid mitte nii madal, et koguste hinnang oleks ebamäärane. Tööprojekti eesmärgiks on koostada terviklik projektlahendus vastavalt eelarvele. Ehitamisel peaks detailsuse aste olema piisav täpseks ruumipõhiseks koordineerimiseks, tootmiseks, ehitamiseks ja kokkupanekuks.
3. Millal andmed lisatakse? Kõik algab väga piiratud hulga andmetega ja nende hulk suureneb iga projekti etapiga. Varasemates etappides tuleks keskenduda andmete kaasamisele, mis tagavad projektlahendi optimeerimise. Need on sageli parameetrilised andmed või andmed, mida saab analüüsiks kasutada. Hanke teostamiseks peab täpsete koguste saamiseks olema piisavalt andmeid. Näiteks on oluline eristada väga kallist uksetüüpi tavauksest või eristada soojusallikaid kasutatava tehnoloogia järgi, nt gaasiboiler, õhk-vesi soojuspump. Ehituse ajal tuleb keskenduda üleantavatele andmetele.

Joonis. Lisatav andmehulk vastavalt projekti staadiumile.

Varadele lisatakse informatsiooni, kuna neid varasid modelleeritakse vastavalt projekti staadiumile, et teha kuluprognooside kohta olulisi otsuseid. Näiteks, põhiprojektis võidakse lisada uks ühes vara ID-ga (ukse number), mis määratleb selle ukse unikaalselt. Hankekonkurssi tulemusena on uksele lisatud spetsifikatsiooni viide, mis annab informatsiooni selle ukse eeldatava toimivuse ja konstruktsiooni kohta. Ehituse ajal värskendatakse andmeid tootja nimetusega ning võidakse lisada märge “määratletud“. Kui uks on paigaldatud, värskendatakse olekuks "paigaldatud" ja lisatakse paigalduskuupäev.

Classification systems

Sarnastel varadel võivad olla sarnased atribuudid. Näiteks on kõigil ustel uksenumber ja tulekindlus. Soojuspumbad ja boilerid on soojusallikad ja neil on sarnased omadused. Sarnaste varade rühmitamist nimetatakse klassifikatsiooniks. On mitmeid klassifitseerimissüsteeme, mis põhinevad üldiselt maksumuse-, spetsifitseerimise- või andmevahetuse (tarkvara) nõuetel. 

Tänasel päeval võib tarkvaralisi klassifikatsioone pidada kõige populaarsemateks klassifitseerimismeetoditeks ainult seetõttu, et mudelite elementide klassifitseerimise väärtust pole hästi mõistetud ja hallatud.

Enamik klassifikatsioonisüsteeme on hierarhilised. Tipptasemel on väga üldine klassifikatsioon nt mistahes arhitektuursed, konstruktsioonilised, mehaanilised või elektrilised komponendid. Järgmine tase allapoole annab laiema rühmituse nt kõik soojusallikad või sekundaarsed elemendid, mis seotud siseseintega. Madalaimal klassifikatsioonitasemel võib tuvastada väga konkreetseid elemente, nagu mutrid ja poldid, ning seega hakkab klassifikaatorite arv kasvama. Uniclass klassifitseerimissüsteemil on tuhandeid klassifitseeritud tooteid, mis on kasulikud just varahalduse jaoks, kuid sellisel määratluse tasemel muutuks kulude haldamine üle jõu käivaks.

Järgnevalt on toodud mõned näited sarnastest varadest, mis on klassifitseeritud NRM-i, ARM-i ja Uniclass järgi.

Tabel. NRM (maksumuspõhine süsteem).

NRM-i hierarhia näide:

• 2 – Pealisehitus 
• 2.6 – Aknad ja välisuksed
• 2.6.1 – Välisuksed

Tabel. Uniclass (spetsifitseerimisel põhinev süsteem).

Uniclass hierarhia näide:

• PR – toode
• PR_30 – Avad
• PR_30_59 - Avad ja avamiskomponendi tooted
• Pr_30_59_24 - Uksekomplekt

Tabel. IFC (tarkvaral põhinev).

IFC hierarhia näide:

• IfcElement
  • IfcBuilding element
    • IfcDoor

Kuigi klassifikatsioonisüsteeme saab potentsiaalselt rakendada, ei ole paljude elementide puhul üks-ühele kaardistamist. Näiteks ARM 4 rühmitab uksed konstruktsiooni järgi, nt puit või teras, samas kui NRM klassifitseerib uksed välis- või siseuksed. Uniclass võib klassifitseerida uksi üheks süsteemiks ja sisaldab üle 100 klassifikaatori, mis arvestavad kõike alates üldisest uksekomplektist kuni hingedeni. Ameerika süsteemid kasutavad mõnel juhul erinevat terminoloogiat kui jällegi Euroopas.

Kui mudelis olevaid andmeid tahetakse kasutada koguste või muude tulemusnäitajate jaoks, tuleb kasutada klassifikaatoreid. Vastasel juhul on andmeanalüüs üle jõu käiv ja nende töötlemiseks kulub iga kord, kui informatsiooni jagatakse, palju aega. On väga häid põhjendusi,  miks valida klassifikaator projekti spetsifikatsiooni baasil aga ka põhjuseid, miks valida just maksumuspõhine süsteem. Samas saab läbi integreeritud seoste kasutada ka mõlemat varianti eeldusel, et mudeli iga elemendi klassifikatsiooni valimisel on olemas selge juhis.

Klassifitseerimissüsteemi paika panemiseks on kaasatud järgmised sidusrühmad:

• Finants- või eelarvestajad, kes soovivad mõista koguste mõju kuludele, mida tavaliselt juhitakse kulujaotusstruktuuri (ingl cost breakdown structure, CBS) abil.
• Eelarvestajad, kes soovivad mudelitest tõhusalt mahtusid eraldada, et informatsiooni saaks kasutada sarnaste elementide koguste spetside koostamiseks.
• Toimingud, kus soovitakse rühmitada hooldatavate varade elemente vararegistris või FM-süsteemis.

Space planning

Peaaegu kõigil ehitistel on ruumiplaneerimise nõue. See aitab ehitisi projekteerida, ehitada, käitada ja kasutada, et navigeerida ning leida ruume ja varasid. Viitetunnus ehitatud ruumide unikaalseks klassifitseerimiseks oleks nt ruumi number ja osakond/funktsioon. Muuhulgas tuleks määratleda ruumi mõõtmise standardid ja metoodikad, mis peaksid põhinema asjakohastel riiklikel või rahvusvahelistel standarditel. Vajaduse korral tuleks määratleda ruumide klassifitseerimise graafiline esitus, mis tagaks järjepidevuse, kui plaane ja mudeleid vaatavad läbi projektimeeskonna liikmed, kes igapäevaselt ei osale projektdokumentatsiooni loomes.

Maintainable Assets

Hooldatavad varad on varad, mis on kaetud tegevuskuludega (ingl operating expenses, OPEX). Tavaliselt on need varad, mis vajavad hooldust, varuosi või väljavahetamist. Paljud on mehaanilised või elektrilised varad, nagu pumbad, konveierid ja kätekuivatid. Standardmääratlust ei ole ja iga varahaldur peab ise otsustama, millised varad on hooldatavad.

Mõnda hooldatavat vara ei pruugi olla vaja eraldi vararegistris või FM-süsteemis registreerida. Näiteks valgusite kohta võib olla lihtsalt valgustite tüüpide nimekiri, mida siis vastavalt strateegiale jooksvalt vahetatakse või vahetatakse vastavalt nende läbipõlemisele.

Tabel. Hooldatavate varade näidisnimekiri. Ukse juures on rõhuasetus selle lukukomplektil, ventilatsioonirestidel.

Hooldatavad varad võivad olla dokumenteeritud või viidatud projektiinfo standardis (PIR).

Määratud juhtiv osaline peaks määrama igale projekteerijale vastutuse varaga seotud informatsiooni esitamise eest. Teatud juhtudel võib ülesanne jaguneda mitme töörühma vahel. Näiteks võib mehaanikainsener kehtestada ukserestile nõude, kuid arhitekt vastutab selle eest, et oleks valitud visuaalselt sobiv rest. Vastutuse eristamiseks saab kasutada modelleerimise vastutusmaatriksi malli (nt RIAI Appendix 2 – Model Responsibility Template). Allolevalt on toodud näide.

Tabel. Modelleerimise vastutusmaatriks. Vastutused markeeritud RACI mudeli järgi (R – vastutav, soovitaja; A – kinnitaja; C – konsultant; I – informeeritud, teadlik).

Attributes

Varadele lisatud informatsioon on määratletud atribuutinfona, mida tavaliselt ja sõltuvalt kasutatavast tehnoloogiast nimetatakse ka parameetriteks, omadusteks ja omaduse gruppideks. Informatsiooni tase viitab üldiselt informatsiooni hulgale ja struktuurile. Informatsiooni esitamiseks võib kasutada COBie nõuet. COBie on populaarne varainfo vorming, mida kasutatakse USA-s, Ühendkuningriigis ja teistes riikides, kuid seda ei peeta otseselt rahvusvaheliseks standardiks. See ei tohiks aga takistada klienti valimast COBie'd, kui see vastab tema infovajadustele, mis sellisel juhul tuleks markeerida infovahetuse nõuetesse (EIR). Samas ei tohiks COBie nõuet lihtsalt sisse kirjutada, analüüsimata, kuidas seda plaanitakse kasutada. Vastasel juhul kogume liiga palju informatsiooni, mis ei pruugi täita eesmärki. Seega, informatsiooni olulisust, mida kaasata, tuleks kaalukalt planeerida.

Iga hooldatav vara sisaldab mitmeid atribuute. Mõned neist on põhiatribuudid või atribuudid, mida jagatakse kõigi varade või vara gruppidega. Näiteks vara ID-d võivad kasutada kõik varad, summaarset jahutusvõimsust aga mehaanilised varad, mida kasutatakse ruumide jahutamisel. Tuleks aga olla ettevaatlik, et ei määratletaks atribuute, mis ei ole opereerimise ja korrashoiu tähenduses vajalikud. Sellise info lisamine ei oma mitte mingit väärtust ja võib omakorda vähendada muu informatsiooni väärtust, kuna see lisatud teave aegub, kui seda ei värskendata.

Kui nõutavad atribuudid on kokku lepitud, tuleks iga atribuudi omadused määratleda. Arvesse tuleks võtta alljärgnevat:

• Atribuutide nimetused peaksid olema lihtsad ja kõigile arusaadavad. Vältige lühendite kasutamist, välja arvatud juhul, kui need on väga hästi arusaadavad.
• Kasutage võimaluse korral COBie atribuutide nimesid, kuna paljud süsteemid kasutavad COBie atribuute.
• Atribuudid võivad olla tüübi või eksemplari atribuudid. Kõiki sama tootja ja mudelitunnusega pumpasid võib pidada sama tüüpi. Näiteks võib olla küll kahte tüüpi pumpasid, kuid neid kahte tüüpi pumpasid on 200 eksemplari. Tüübi atribuutidega seotud väärtusi on palju vähem kui eksemplariga seotud atribuute.
• Oluline on määrata atribuudi vorming. Tekstiväärtustega on lihtne, kuid nagu arvutustabelite puhul, tuleb need arvutuste tegemiseks (nt kõikide 200 kW summaarse jahutusvõimsusega AHU-de filtreerimiseks) teisendada sobivasse andmetüüpi.
• Määrata tuleb ühikud. Paljud modelleerimissüsteemid kasutavad ühikuid.
• Näidisandmed pakuvad projektimeeskonna liikmetele näiteid selle kohta, kuidas soovite informatsiooni saada.

Responsibility matrix

Standardi EN ISO 19650-2:2018 tegevus 5.4.2 nõuab, et määratud juhtiv osaline kehtestaks üksikasjaliku vastutusmaatriksi, mis võtab arvesse edastatavaid andmeid, nagu vararegistrid, joonised, mudelid, aruanded jne. See on väga oluline, kuid tehnilise informatsiooni (nt mudelid, joonised ja spetsifikatsioonid) üksikasjalikuks koostamiseks on vaja ka elemendipõhist vastutusmaatriksit.

Alljärgnevalt näide elemendipõhisest vastutusmaatriksist, mis põhineb standardil RICS New Rules of Measurement (NRM).

Tabel. Elemendipõhine vastutusmaatriks.

Transferring assets and attribute data to the asset information model (AIM)

Enne varade ja atribuutinfo ülekandmist ärisüsteemidesse (nt FM-süsteemid ja finantssüsteemid) tuleb luua metoodika nende ülevaatamiseks, kinnitamiseks, esitamiseks ning vastuvõtmiseks. Varainfo kontrollimise, ülevaatamise, jagamise, autoriseerimise, esitamise ja vastuvõtmise protsess on sama, mis kogu muu, töörühmade loodud, informatsiooni juures ning see on määratletud standardi EN ISO 19650-2 tegevustena 5.6.3–5.7.4.

Joonis. Kinnitusprotsessi maatriks. 

Täiendavate juhiste saamiseks vaata ka lisamoodulit ühtne andmekeskkond.