Tirgum arvien vairāk uzsākot darboties BIM projektu apritē, par vienu no svarīgākajiem aspektiem kļūst izraudzīt atbilstošu projekta apjomu, t.i., detalizācijas līmeni. Tas nepieciešams, lai projekts tiktu kvalitatīvi sagatavots, tajā būtu nepieciešamais informācijas apjoms, kā arī tas tiktu savlaicīgi realizēts. Taču, cenšoties radīt informatīvāku modeļa paketi, parādās cita galējība – informācijas pārpilnība, kas var novest pie laika un resursu izšķiešanas. Kas veido modeļa detalizāciju, un kādas ir galvenās problēmas, to plānojot?
BIM modeļa detalizācijas jēdzieni un galvenās problēmas
Tādiem BIM projektos ļoti bieži dzirdamiem jēdzieniem kā Level of Development, Level of Detail un Level of Information nav definēts viens konkrēts standarts vai reglaments. Saprotams, ka tādēļ rodas interpretācijas, un jēdzieni bieži tiek saprasti un pielietoti atšķirīgi.
Level of (Model) Development – tas ir projekta grafiskās un ne-grafiskās informācijas kopums. Ar šo jēdzienu vispārēji definējam BIM projekta mērķus BIM izpildes plānā.
Level of Detail – elementu grafiskās informācijas precizitāte/detalizācija, t.i., atbilstība faktiskajam plānotajam elementam.
Level of Information – šis jēdziens norāda, kāda ne-grafiskā informācija jāsniedz par katru elementu. Iespējams, ka projekta detalizācija paredzēta ar LOD 400 (t.i., modeļa izmantojums ēkas uzraudzībai), taču konkrētajam elementam šādā gadījumā ir svarīgāks lielāks ne-grafiskās informācijas līmenis (piemēram garantija u.tml.) nekā grafiskais. Varbūt nav tik svarīga detalizēta klimata sistēmas modeļa pakete ar visām tās “iekšām”, bet svarīgāk ir zināt tās jaudu, garantijas laiku vai norādes instrukcijā. Tas nozīmē, ka elementam var paredzēt mazāku grafisko detalizāciju, taču vairāk pārdomāt ne-grafiskās informācijas apjomu.
Plānojot modeļa detalizāciju, nereti rodas vairākas problēmas:
• Nekonkrētība, nosakot projekta mērķus un modeļa izmantošanu.
• Mēģinājums modeļa detalizāciju “iebāzt” vienā skaitlī.
• Neatbilstoši izvēlēts elementu skaits.
• Neatbilstoši izvēlēta ģeometrijas detalizācija.
• Nav definēta modeļa precizitāte/kļūda.
• Nav norādīts ne-grafiskās informācijas apjoms.
• Komandai nav iesniegtas vizuālas un skaidras prasības attiecībā uz modelējamiem elementiem
Tas nozīmē, ka grūtākais un varbūt pat atbildīgākais darbs ir noformulēt un definēt komandai modeļa detalizāciju tā, lai prasības būtu skaidras gan vizuāli, gan informatīvā nozīmē un lai nerastos interpretācijas un pārpratumi, pārspīlēta modelēšana vai tieši otrādi – elementu trūkums.
Nekonkrētība, nosakot projekta mērķus un modeļa izmantošanu
Publiskās iestādes “Skaitmeninė Statyba”(Digitālā būvniecība) publicētais modeļa izmantošanas veidu saraksts parāda dažus piemērus, pēc kuriem iespējams detalizētāk saplānot, kam tieši modelis būs paredzēts, un atkarībā no tā projekta komandai sadalīt darbus un pienākumus:
• Esošo apstākļu modelēšana;
• Ekonomiskie/kvantitatīvie un izmaksu aprēķini (tāmes sastādīšana);
• Projekta posmu plānošana (4D);
• Gruntsgabala analīze;
• Funkcionālais, apjoma un plāna izvērtējums;
• Projekta vizualizācija un uzraudzība;
• Projektēšana/ modelēšana;
• Inženieraprēķini un analīze;
• Enerģētiskā analīze;
• Stabilitātes novērtēšana;
• Konstrukciju analīze un projektēšana;
• Apgaismojuma analīze;
• Inženiersistēmu analīze;
• Citi analīzes gadījumi;
• Atbilstības novērtējums/ projekta ekspertīze;
• 3D koordinēšana/ krustošanās vietu pārbaude;
• Būvniecības vietas plānošana;
• Veselības un drošība līdzekļu plānošana;
• Konstrukciju – tehnoloģiskā analīze;
• Būvniecības tehnoloģiju (tehnoloģisko shēmu) un montēšanas gaitas piedāvājums;
• Būvniecības loģistikas plānošana;
• Būvniecības procesu modelēšana un vadība (4D);
• Digitālā ražošana;
• Būvniecības darbu tehniskā uzraudzība (laukumā);
• Izpildes modelēšana;
• Datu modelēšana;
• Būves uzraudzības plānošana;
• Būves (inženier-) sistēmu analīze;
• Enerģijas patēriņa analīze;
• Īpašuma pārvaldīšana;
• Telpas pārvaldīšana un uzraudzība;
• Stabilitātes uzraudzība un analīze;
• Avāriju prevencija;
• Citi
BIM projekta sagatavošanas vadlīnijas nosaka, ka modeļa detalizācijas līmenis tiek noteikts un aprakstīts, novērtējot Pasūtītāja prasības un mērķus. Tomēr arī programmatūras izvēli un komandas IT stratēģiju jāizvēlas atbilstoši galvenajam mērķim un nolūkam, kam tiks izmantots konkrētais BIM modelis.
Gatavojoties projektam, vajadzētu precīzi formulēt, vai no modeļa tiks izgūti apjomi vai tiks tikai vizualizēti projekta risinājumi. Iespējams, tiks veidots VR, varbūt ar modeļa palīdzību tiks gatavota visa dokumentācija. Vai varbūt modelis domāts tikai vizuālai krustojumu koordinācijai? Varbūt – ēkas uzraudzībai? Skaidrāk nosakot mērķus, ir daudz vieglāk sadalīt, cik un kādi elementi un kāda grafiskā vai ne-grafiskā informācija tiks prasīta no projekta komandas.
Mēģinājums modeļa detalizāciju “iebāzt” vienā skaitlī
Pieturēties pie esošiem standartiem un piemērot vienu šablonu visiem projektiem izrādās nepraktiski, jo katram no tiem ir atšķirīgi mērķi un nolūki. Mēģinot projektu “pievilkt” standartam un ar vienu detalizācijas skaitlisko rādītāju noteikt projekta posmus, riskējam neizpildīt noteiktos mērķus (piemēram, tiek gatavots LOD 400 modelis, lai to izmantotu ēkas uzraudzībai, taču rezultātā uzraudzītāji izmanto tikai dažas informācijas ailes (garantija, atsauce uz instrukciju, jaunākās izmaiņas), un lielākā daļa šīs informācijas nav grafiska).
Tāpat zināms, ka bieži projekta vadītāja atbildību uzņemas arhitekti. Un klāt šīm divām funkcijām viņi nereti cer uzņemties arī BIM vadītāja lomu, taču šādā gadījumā var skaidri nosaukt divus galvenos riska faktorus:
1. Pasūtītājs nezina, kas tieši viņam nepieciešams no BIM, tāpēc izmanto vispārējas frāzes un jēdzienus BIM stratēģija veidošanai, savukārt arhitektam to interpretējot, tiek sniegta tikai viena – arhitektūras – modeļa grafiskā un informatīvā detalizācija;
2. Pasūtītājs ne pārāk labi izprot BIM prasības/ mērķu būtību un to saistību ar projekta izmaksām un laika grafiku, tāpēc “mētājas” ar frāzi “man vajag visu”. Projektu vadītāja centieni iesniegt modeli, kurā būtu “viss”, ne vienmēr uzlabo gala produktu. Tas palielina projekta cenu, jo tiek lieki tērēts laiks un resursi.
Neatbilstoši izvēlēts elementu skaits
Vēl viena svarīga lieta – projektā jāizvērtē, vai elementam pietiks ar simbola atveidojumu, izmantojot bibliotēku standarta elementus, norādot elementam rezervējamo vietu, mērķi un galvenos parametrus, vai varbūt detalizētie elementi tiks izmantoti ražošanā un CNC darbgaldos un informācijas nepieciešams vairāk.
Elementa grafiskā detalizācija jāizvēlas tā, lai darba patēriņš tās veidošanā būtu optimāls, lai nevajadzētu tērēt laiku, modelējot elementus tādā līmenī, kādā pēc tam tos nenāksies izmantot.
Nav definēta modeļa precizitāte/kļūda
Neliela, bet pietiekami svarīga lieta ir noteikt elementu krustojuma vietu toleranci (100 mm; 50 mm; 1 mm). Lielisks piemērs varētu būt cauruļvadu izolācijas savstarpējās krustojuma vietas 1cm – varbūt tas ir pavisam vienkārši, bez papildu izmaksām un to var koriģēt un izmainīt būvē uz vietas, bet varbūt tā patiešām ir būtiska krustojumu vieta un nepieciešams šī mezgla modeli detalizēt.
Nav norādīts ne-grafiskās informācijas apjoms
Eksportējot modeli IFC formātā, noteikta informācijas daļa tiek piegādāta automātiski, atbilstoši izvēlētajam produktam no bibliotēkas (teiksim, materiāls, nosaukums u.tml.), taču katrai programmatūrai ir citāda informācijas piegādes veidne (kāda informācija tiek eksportēta automātiski, kāda jāizvēlas no datubāzes vai pat jāveido papildu ailes). Tāpat viena un tā pati informācija, piemēram, tā paša materiāla nosaukums, dažādās programmatūru sistēmās ir nosaukts atšķirīgi, tāpēc ir jādefinē vispārēji noteikumi visai projekta komandai par katra elementa pārsūtamo informāciju un kāda ir materiālu un citas informācijas nosaukumu indeksācija.
BIM projekta komandai nav iesniegtas vizuālas un skaidras prasības attiecībā uz modelējamiem elementiem
Visbiežāk modeļa elementu detalizācijas informācija projekta komandai tiek iesniegta tabulas veidā, norādot elementa nosaukumu, nepieciešamo grafisko un ne-grafisko informāciju. Taču šādas tabulas ir diezgan grūti saprast, jo tās nav vizuāli viegli uztveramas. Bieži vien noteikts informācijas daudzums tiek norādīts ar kodiem (saīsinājumiem), kas prasa ne tikai “studēt” iesniegto tabulu, bet arī noskaidrot, kas ar norādīto kodu pateikts. Nesen organizētā vebinārā tika apspriesta modeļa detalizācija, un tā laikā veiktajā aptaujā dalībnieki uzsvēra galvenās ar projekta detalizāciju saistītās neskaidrības:
• Trūkst atsevišķu elementu detalizēta apraksta (10%);
• Trūkst vizuāla noformējuma, kas precizētu elementu ģeometrisko attēlojumu (25%);
• Elementiem pietrūkst ne-grafiskās informācijas (30%);
• Elementu precizitāte/kļūda modelī (10%);
• Precīzs elementu definējums atbilstoši izmantošanas mērķim (25%).
Skaidrs, ka tirgū pārsvarā sastopamas līdzīgas problēmas, aprakstot modeļa elementu grafisko detalizāciju, tāpēc ir nepieciešams risinājums, kas atvieglotu darbu un ļautu iespējami samazināt problēmu rašanās risku.
[su_youtube url=”https://www.youtube.com/watch?v=78SU7KAheXw&feature=youtu.be” width=”300″ height=”300″]Video[/su_youtube]
Kā no šādām situācijām izvairīties?
Minētās problēmas var atrisināt interaktīvas BIM projekta modeļa plānošanas un vadības sistēmas, kā, piemēram, LODplanner. Tā palīdzēs ne tikai vizuāli prezentēt modeļa apjomu un detalizāciju atbilstoši pienākumiem, bet ļaus arī izsekot, vai projekts virzās pietiekamā tempā un pareizā virzienā. Turklāt, strādājot ar LODplanner, tiek ietaupīts laiks gan BIM izpildes plāna, gan elementu prezentāciju un pienākumu tabulu sagatavošanai, jo tiek nodrošināta iespēja piekļūt atvērtai datubāzei, ko veidojuši lietotāji visā pasaulē.
Ne mazāk svarīgi ir izglītot Pasūtītāju: apspriest ar viņu modeļa izmantošanas iespējas konkrētā projektā un formulēt Pasūtītāja prasības. To izpildes stratēģija skaidri jāiestrādā BIM izpildes plānā, kā arī modeļa prezentāciju grafikā.