“ози сайт използва бисквитки (cookies). јко желаете можете да научите повече тук. –азбрах

Ќовини »“ мениджмънт
бр. 8, 2017

13 термина при —»ћ

—вързани със —»ћ термини и пон€ти€, които е добре да познавате с оглед на участие в проекти в строителни€ сектор

от , 20 септември 2017 0 620 прочитани€,


»зползването на —троително информационното моделиране – —»ћ (Building information modeling-BIM) набира скорост в строителни€ сектор. ѕравителства от различни държави – ќбединеното кралство, ’оланди€, ’онгконг, вече дори в „или, а в скоро време и в √ермани€ и ‘ранци€ започват да изискват прилагането на —»ћ за финансирани с публични средства проекти. ¬ следващи€ текст са изведени информации за 13 термина и пон€ти€ свързани със —»ћ, с които рано или късно ще се сблъскате, ако искате да участвате в такива проекти. — оглед на стремежа за чистота на пон€ти€та на български е направен опит за смислови€ им превод. ѕри н€кои от т€х може би ще се наложат и български наименовени€ и съкращени€, но при други (например IFC) преводът би бил неудачен и със сигурност ще се ползват директно английските пон€ти€ и абревиатури.

1. BIM Maturity Level / Ќива на развитие (зр€лост) на —»ћ

„рез т€х може да се определи нивото на приложение на —»ћ в жизнени€ цикъл на сградата или съоръжението. ƒефинирани са четири нива, които се означават с числа от 0 до 3, като във вс€ко следващо се увеличават изисквани€та към прилаганите елементи на —»ћ. »зползваните съкращени€ на английски са част от пон€ти€та из€снени по-долу.

  • Ќиво 0 (Level 0) определ€ процесите на използване на 2D CAD, при които обаче липсва обмен на информаци€.

ѕо-гол€мата част от бранша и у нас е надхвърлил това ниво. Ќай простата форма на BIM включва 2D чертежи и текстове в електронен формат, с обмен на информаци€та на харти€ или по електронен път, но без общи стандарти или процеси. ѕо същество това е използване на електронна чертожна дъска без опит за взаимодействие с останалите потребители на информаци€ за обекта.

  • Ќиво 1 (Level 1) се достига при използването на 2D и 3D CAD с обмен на информаци€ чрез файлове между н€кой от участници в процесите.

“ипичното —»ћ Ќиво 1 представл€ва смес от 3D CAD модели за концептуална работа и 2D документаци€ за процедурите по утвърждаване на процесите и за изпълнение на строителството. “€ може да включва двумерни и тримерни компютърни модели за визуализаци€ или за създаване на концептуалните проекти. ѕри Ќиво 1 обаче моделите не се ползват съвместно от участниците в процеса.

  • Ќиво 2 (Level 2) включва взаимодействие и обмен на информаци€ базирана на файлове между различните участници, както и други аспекти на —»ћ като – ќбща информационна среда (CDE) и изготв€не на Ѕаза-данни от —троителство към ѕолзване ( COBie). Ќа този етап проектната информаци€ може все още да се съхран€ва на различни места и връзките между участниците в процесите да се настройват и управл€ват ръчно.

“о се отличава по съвместната работа – всички участници ползват собствени 3D CAD модели, и не работ€т непременно върху общ, съвместен модел. —ъвместната работа се осъществ€ва според начина по който участниците в процеса обмен€т информаци€ помежду си. ѕроектната информаци€ се обмен€ на базата на общ файлов формат, което дава възможност на всеки участник да комбинира сво€та информаци€ с общата и така да създава и изследва общ модел чрез сво€та собствена технологи€. Ќиво 2 —»ћ е управл€ема тримерна 3D работна среда с данни за обекта създадена на базата на отделните модели генерирани и използвани от отделните участници. ƒори когато отделните модели са обединени в общ модел те не губ€т сво€та индентичност и ц€лост.

  • Ќиво 3 (Level 3) все още не е специфицирано подробно, но следва да съдържа напълно интегриран —»ћ процес. “ова включва аспекти като – получаване и зареждане на данни от един и същ общодостъпен централен модел в реално време.

“ова предсто€що ниво, н€къде наричано още „—вещени€ √раал“ на —»ћ, представл€ва пълно сътрудничество между всички участници в жизнени€ цикъл на сградата или съоръжението чрез използването на негов общ модел. “ози модел се съхран€ва на едно м€сто и следва да е напълно съвместим с всички развиващи се в областта старндарти. ќбщи€т модел е достъпен за всички и съдържа освен тримерна геометрична информаци€ и данни за последователността на изпълнение (4D), стойността (5D) и информаци€ необходима за управлението на собствеността (6D).

Ќивата на зр€лост при използването на —»ћ са дефинирани чрез ћоделът за зр€лост на —»ћ, разработен от ћарк Ѕю и ћервин –ичардс за да ги из€сн€т в стандарта на ќбединеното  ралство PAS 1192.

2. Dimensions / –азмерност на модела

ѕоради факта, че —»ћ навлиза в много аспекти на жизнени€ цикъл на инвестиционен обект, могат да се дефинират н€колко допълнителни размерности на модела. ќсвен характерните и досега в строителството 2D (чертежи) и 3D (макети) модели при —»ћ се въвеждат и следните нови размерности:

  • 4D се отнас€ към времето – или по-точно за планирането на изпълнението на оебкта, което е включено в —»ћ процесите. „рез графиците на изпълнение и времевите анализи участниците в проекта и разбира се бъдещи€ собственик могат да оцен€т как проекта ще се развива и ще функционира във времето.  ъм тази размерност могат да се отнесат и всички симулации на които би могло да бъде подложен модела с оглед на оценка на дълготрайността на бъдещата сграда или съоръжение.

  • 5D добав€ финансирането - „рез този аспект на използването на —»ћ се подчертава възможността да се анализира много точно стойността на отделните части и дейности по време на изпълнението и управлението на обекта.

  • 6D и следващите нива на размерност се отнас€т директно към фазата на управление и поддръжка.  огато става дума за проект за сграда могат да бъдат покрити широк кръг изисквани€ и стратегии за развитие и управление, както и за бъдещи реконструкции.

3. BIM Protocol / —»ћ ѕротокол

—»ћ ѕротокол е официалното споразумение, което дава възможност за плавното протичане на процесите в един —»ћ проект. „рез него се определ€ рол€та на »нформационни€ мениджър и всички стандарти, които следва да бъдат спазвани от членовете на проектни€ екип. ѕротоколът описва и нивото на подробности на информаци€та, които следва да съдържат различните части на проекта както и форматът на представ€нето им. “ози формат може да е обвързан и със специфични лицензи на производители на —»ћ програмни продукти. ќбобщено може да се определи, че чрез —»ћ ѕротокол се създава работната среда за обмен на информаци€ между различните участници в един проект управл€ван от конкретен възложител. ѕротоколът осигур€ва и прослед€емост на информаци€та. ѕри допусната грешка в данните свързани с конкретни€ модел чрез —»ћ ѕ–ќ“ќ ќЋј може да се установи кой и кога е допуснал грешката. ѕротоколът може да бъде не само технически инструмент, но да бъде част от договорните отношени€ между участниците в процеса. “ой се €в€ва изключително важен инструмент за управление и координаци€ на един проект в който се прилага —»ћ.

4. Employers Information Requirements (EIR) / »нформационни изисквани€ на възложител€ (»»¬)

“ози документ следва да предхожда сключването на договор между възложител€ и изпълнител€. „рез него възложител€т следва да определи точно каква информаци€ следва да му бъде предоставена от изпълнителите на проекта. ¬ това пон€тие се включват и форматите на информационните масиви, кога следва те да бъдат предоставени и за какво ще бъдат използвани. “ова постав€ високи изисквани€ пред възложител€. “ой тр€бва да е на€сно във всеки един момент каква информаци€ ще му е нужна за протичането на управл€ваните от него работни процеси. “ози документ следва да описва необходимата информаци€ за всички етапи на проекта и стандартите, които тр€бва да се прилагат при подготв€нето и предостав€нето и на възложител€. ќбикновено изисквани€та са разделени на три основни области:

  • “ехнически изисквани€
    тук се включват изисквани€та към софтуерната платформа, форматите за обмен на информаци€, ниво на подробности на информаци€та и необходимост от обучение на участниците.

  • ”правленски изисквани€
    тук се включват ролите на отделните участници в процеса и техните отговорности в него, процесите на сътрудничество между т€х, изисквани€та за сигурност на информаци€та и др.

  • “ърговски изисквани€
    в тази част могат да се включат неща като – валидност на информаци€та във времето, оценка на стойността на доставките и оценка на компетентността на участниците.

5. Master Information Delivery Plan (MIDP) / ќсновен план за предостав€не на информаци€ (ќѕѕ»)

“ова е график за изпълнението на проекта с прилагане на —»ћ. “ук се описват всички етапи и фази на изпълнението на проекта - кой, кога и на кого следва да предостави съответната информаци€. “ози план всъщност се €в€ва като част от »нформационни изисквани€ на възложител€ (EIR)

¬ графика следва да се включи всеки документ, които се €в€ва като част от проекта. Ѕило то –тримерен модел, доклад за анализ на модела, списъци на доставки или просто доклад за изпълнението на отделна фаза на проекта. ¬ него следва да се включи всеки елемент от проекта, който тр€бва да бъде предаден на възложител€ за да се счита проекта за приключен. ¬ него се описват – модели, чертежи и фотореалистични изображени€; спецификации; списъци на оборудване; графици; количествени сметки; об€снителни записки и др.

6. BIM Execution Plan (BEP) / ѕлан за изпълнение на —»ћ (ѕ»—)

“ози документ се прави в два варианта – преди и след сключването на договор за изпълнение. » двата типа ѕ»— из€сн€ват детайли за използването на различни часто от информаци€та за проекта и обикновено са неразделно приложение от »нформационни изисквани€ на възложител€ (EIR).

ѕ»— всъщност е част от процеса за избор на изпълнители. „рез него може да се оцени ефективността на за прилагане на —»ћ от отделните изпълнители и дали те ще могат да изпълн€т задачата. ќт т€х се очаква към офертата си за изпълнение на проекта да покажат и детайлно как ще приложат изисквани€та за управление на информаци€та и детайлността за изпълнение и управление на —»ћ.

ѕредварителни€т ѕ»— обикновенно съдържа схемата на предварителен план за развитие на проекта които включват и възможностите, компетентностите и опита на потенциалните изпълнители и целите при съвместната им работа. Ќай общо казано –  акво и как следва да се направи.

ƒоговорни€т ѕ»— е много по-детайлиран и в него зал€гат специфичните стратегии за етапите на проекта, включително ролите и отговорностите на участниците, документаци€ от рода на - ќсновен план за предостав€не на информаци€ ќѕѕ» , методи и процедури на работа и др. ¬същност чрез него се описва какво и как точно тр€бва да направи колектива като се постав€т срокове и критерии, чрез които следва да се контролира изпълнението.

7. Common Data Environment (CDE) / ќбща —реда за —ъхранение на ƒанни (ќ——ƒ)

“ова е м€стото където се случва маги€та на —»ћ.

 акто е видно от названието и това е цифровата работна среда за съхран€ване на всички информации за проекта. “ова може да е наето облачно пространство или сървър при н€кои от участниците в проекта. ¬сички членове на колектива следва да имат съответни€ достъп и права за промени – където е необходимо. “ози метод на работа намал€ва риска от дублиране на информаци€та и грешки в комуникаци€та между членовата на работни€ екип. ќ——ƒ следва да е единствени€ източник на информаци€ за проекта.

ќ——ƒ се съхран€ва и контролира от »нформационни€ ћениджър – определен в —»ћ ѕротокола. “ой следва да е назначен от възложител€. »нформационни€т мениджър носи отговорността за спазването на протоколите и за сигурността на данните на проекта.

8. Data Classification /  ласификаци€ на данните

 ласифицирането на данните е познато пон€тие, но —»ћ го издига на по-високо ниво. ¬ много случай отделни компании и организации имат свои начини за класифициране на данните. “ози подход обаче постав€ под заплаха едни от най-важните предимства и цели на —»ћ.

—ъществуват различни системи за класифициране като MasterFormat, OmniClass Construction Classification System и UNICLASS.

Ќезависимо дали всички участници в проекта ще се обедин€т към н€ко€ от тези системи или нещо друго, то от изключителна важност е да има еднакъв подход към класифицирането на данните и той да е единен за всички. “ова не се ограничава само до проектни€ колектив, а до всички – производство, строителство, поддръжка.  ласифицирането на данните дава възможност за структурирането им, които улесн€ва подреждането, търсенето и систематизирането им.

9. Project Information Model (PIM) / ѕроектен информационен модел (ѕ»ћ)

“ози модел наричан още и инженерен цифров модел, представ€ проекта като единно ц€ло. “ой може да се използва за предварителна визуализаци€ на бъдещи€ строителен обект, с него се извършват инженерни анализи и чрез него се детайлират и оптимизират строителните системи и подходи за изпълнението на обекта. ¬сички отделни части на проекта допринас€т за изграждането на ѕ»ћ, който се използва от концептуалното решение до подписването на договора за строителство.

≈дна от основните задачи на ѕ»ћ е да даде обща представа на участниците в проекта за съвместните им действи€ и намерени€ при изготв€нето на проекта. “ой обикновенно съдържа, както графична, така и не-графична информаци€. ¬секи участник в проектирането – архитект, конструктор, инсталационен инженер, геодезист – създава един или н€колко модела. ћодели се създават още в концептуалната фаза – обемно-пространствени решени€, идейни модели – чрез които се формира иде€та за бъдещи€ строеж. ¬ъв следващите фази се оформ€ виртуални€ строителен модел, който следва да съдържа всичко което тр€бва да бъде изработено, инсталирано или конструирано на м€сто.

ѕ»ћ обикновено се ползва по време на етапа на проектиране и строителство след което той се доразвива във »мотен »нформационен ћодел »»ћ. (¬иж по-долу) »зисквани€та към последни€ се задават в »нформационни изисквани€ на възложител€ »»¬

10. Asset Information Model (AIM) / »мотен »нформационен ћодел (»»ћ)

“ози информационен модел се създава на базата на ѕ»ћ и се използва за управлението, поддръжката и използването на инвестиционни€ проект, такъв какъвто е изпълнен. –азбира се той може да бъде изпълнен и без наличието на ѕ»ћ, ако в обекта се поддържа специализирана система за управление на собствеността.

—тандартното съдържание на »»ћ включва:

  • ƒанните определ€щи оригиналното проектно намерение от ѕ»ћ или друга предварително известна информаци€.

  • 3D модели, заедно с документаци€ и метаданни.

  • ƒетайли свързани със собствеността, правата, ограничени€та, проучвани€ и измервани€ и др. информации.

11. LoD (Level of Development/Definition) / Ќиво на развитие (Ќ–)

LoD е пон€тие свързано със —»ћ в което може да има регионални различи€, но принципните дефиниции са подобни.

—пецификаци€та на LoD следва да бъде приложена към всички фази на проекта, както относно графичното представ€не, така и спр€мо данните които следва да съдържа модела при завършването на даден етап.

¬ приети€ в ќбединеното  ралство AEC (UK) BIM Technology Protocol Ќ– се раздел€ на две части:

  • Ќиво на ƒетайл (Ќƒ)– за графичното съдържание.

  • Ќиво на »нформаци€ (Ќ») – за не – графичното съдържание.

ѕри всички варианти на това пон€тие, се цели да се контролира количеството информаци€, ко€то се въвежда в модела на всеки етап от развитието и използването му. “ова тр€бва да предотврати препълването на модела с информаци€ в началните фази на развитието му.  оличеството на информаци€ следва да е съобразено с моментите на взимане на ключови решени€ в процеса на използване на —»ћ. ѕри началните фази на обсъждане на концепци€та сигурно не е нужна информаци€ за инсталациите и поддръжката, ко€то ще е задължителна във фазите на проектиране и управление.

12. Industry Foundation Class (IFC) / Ѕазови индустриални класове

IFC е международен формат на данни развиван и поддържан от организаци€та buildingSMART. “ой е проектиран за да може пълно да се опишат данните за продукци€та на строителната индустри€ – сгради и съоръжени€ – с оглед на улесн€ването на обмена на информаци€ между различните участници в процесите и различните типове програмни продукти.

IFC е вече стандартизиран чрез ISO 16739, който е въведен и в Ѕългари€ през 2017 г чрез Ѕƒ— EN ISO 16739:2017 . “ози стандарт е в непрекъснато развитие. ѕоследни€т му вариант покрива :

  • ‘ормати за обмен изисквани през фазите на жизнени€ цикъл на една сграда.

  • ‘ормати за обмен изисквани от всички дисциплини и участници в тези фази на жизнени€ цикъл.

¬ъпреки това не се покриват формати за обмен извън проектиране, строителство, производство на строителни елементи, управление и поддръжка на сградата и аспекти на поведението и.

ћного програмни продукти (като Revit, ALLPLAN, ARCHICAD и др.) поддържат импортиране и експортиране на модела от и към IFC.

13. COBie (Construction into Operation of Building information exchange) / (ќбмен на информаци€ за —града от —троителството към ѕолзването ѝ)

COBie е структуриран, независим формат на данни, който се фокусира по-скоро на описателната информаци€, отколкото на геометричната. ќфициално той е част от структурираната чрез IFC информаци€, ко€то тр€бва да се предаде от строител€ на собственика с оглед на улесн€ването на взимането на решени€ при управлението на собствеността и на изградените активи.

“ова е база-данни във таблична форма ко€то обикновено съдържа:

  • —писъци на оборудването и обзавеждането

  • “ехнически паспорти на всички използвани продукти и материали

  • √аранционни услови€ и срокове

  • —писъци на резервни части

  • √рафици за профилактична поддръжка

COBie е развит за да опрости управлението на данните получени чрез —»ћ и това да се осъществи независимо от умени€та свързани с »“. “ака или иначе не всеки инструмент за създаване на —»ћ поддържа COBie , така че този формат не може да бъде универсално приложен.

 акто е видно при въвеждането на —»ћ в строителството се изисква не само ползването на един или друг програмен продукт, който да облекчи съответните работни процеси. Ќеобходимо е всички основни участници в инвестиционни€ процес – възложител, изпълнители проектанти и строители, управители на собствеността - да са на€сно с новите процеси и възможности на технологиите и да са добре подготвени за възлагането, изпълнението, контролирането и поддръжката на инвестиционни€ обект. ѕодготовката за използването на —»ћ у нас следва да започне при активната ангажираност на държавните и общинските органи и всички браншови организации –  јЅ,  »»ѕ,  —Ѕ, Ѕј»»  и др. Ќеобходими са промени в нормативните документи свързани с инвестиционни€ процес, превод и адаптаци€ на стандарти, разработване на примерни документи и ръководства за прилагането им. —ъздадената с помощта на ≈вропейската комиси€ работна група EU BIM Task Group вече публикува - Ќаръчник за въвеждането на —»ћ в ≈вропейски€ ќбществен —ектор. “ой дава добра основа да се започне подготовката на услови€та за използване на —»ћ в Ѕългари€.

 ќћ≈Ќ“ј–» ќ“  

ѕолезни страници
    «а нас | јудитори€ | –еклама |  онтакти | ќбщи услови€ |
    ƒействителни собственици на насто€щото издание са »во √еоргиев ѕрокопиев и “еодор »ванов «ахов