------------------------------------------------------------- Документ безкоштовно доступний для ознайомлення в форматі TXT без графіки і без таблиць. Повний текст документу див. в нормативній базі "Зодчий" https://cct.com.ua/zodch.htm ------------------------------------------------------------- ДСТУ EN ISO 29481-1:2022 II Право власності на цей національний стандарт належить державі. Заборонено повністю чи частково видавати, відтворювати задля розповсюдження і розповсюджувати як офіційне видання цей національний стандарт або його частини на будь-яких носіях інформації без дозволу ДП «УкрНДНЦ» чи уповноваженої ним особи ДП «УкрНДНЦ», 2022 ПЕРЕДМОВА 1 РОЗРОБЛЕНО: Технічний комітет стандартизації «Металобудівництво» (ТК 301), Товариство з обмеженою відповідальністю «Український інститут сталевих конструкцій імені В. М. Шимановського» 2 ПРИЙНЯТО ТА НАДАНО ЧИННОСТІ: наказ Державного підприємства «Український науково- дослідний і навчальний центр проблем стандартизації, сертифікації та якості» (ДП «УкрНДНЦ») від 26 січня 2022 р. № 20 з 2022−10−01 3 Національний стандарт відповідає EN ISO 29481-1:2017 Building information models — Information delivery manual — Part 1: Methodology and format (ISO 29481-1:2016) (Інформаційні моделі будівель. Настанова з доставляння інформації. Частина 1. Методологія та формат) і внесений з дозволу CEN-CENELEC, Rue de la Science 23, B-1040 Brussels, Belgium. Усі права щодо використання європейських стандартів у будь-якій формі й будь-яким способом залишаються за CEN Ступінь відповідності — ідентичний (IDT) Переклад з англійської (еn) 4 Цей стандарт розроблено згідно з правилами, установленими в національній стандартизації України 5 УВЕДЕНО ВПЕРШЕ ДСТУ EN ISO 29481-1:2022 III ЗМІСТ С. Національний вступ .................................................................................................................................... V Передмова до ISO 29481-1:2016 ............................................................................................................... V Вступ........................................................................................................................................................... VI 1 Сфера застосування.................................................................................................................................1 2 Нормативні посилання .............................................................................................................................1 3 Терміни та визначення понять .................................................................................................................1 4 Настанова з доставляння інформації ......................................................................................................3 4.1 Загальні положення ............................................................................................................................3 4.2 Користувачі цього стандарту .............................................................................................................3 4.3 Бізнес-контекст процесу .....................................................................................................................3 4.4 Повна схема ........................................................................................................................................4 4.5 Розбиття повної схеми на складові для забезпечення виконання вимог .......................................4 4.6 Підтримання процесу будівельного інформаційного моделювання................................................5 4.7 Підтримання бізнес-процесу ..............................................................................................................5 4.8 Підтримання програмного рішення ...................................................................................................5 4.9 Специфічний інформаційний вміст IDM ............................................................................................5 5 Структура IDM ...........................................................................................................................................6 5.1 Загальні положення ............................................................................................................................6 5.2 Базова структура ................................................................................................................................7 5.2.1 Загальні вимоги ..........................................................................................................................7 5.2.2 Інформаційний вміст заголовка компонента IDM ....................................................................7 5.2.3 Опис компонента IDM ................................................................................................................8 5.3 Карта взаємодії/карта транзакції .......................................................................................................8 5.4 Карти процесів ....................................................................................................................................9 5.5 Вимоги щодо обміну ...........................................................................................................................9 5.5.1 Загальні вимоги ..........................................................................................................................9 5.5.2 Блоки інформації .......................................................................................................................9 5.5.3 Інформаційні обмеження ...........................................................................................................9 5.6 Технічне виконання ...........................................................................................................................10 5.6.1 Загальні положення .................................................................................................................10 5.6.2 Створення метаданих ..............................................................................................................10 5.6.3 Структура взаємодії .................................................................................................................10 5.6.4 Визначення проєкції моделі (MVD) .........................................................................................10 Додаток А (довідковий) Процес розроблення IDM ..................................................................................12 Додаток B (довідковий) Приклади спрощених компонентів IDM ............................................................15 ДСТУ EN ISO 29481-1:2022 IV Додаток C (довідковий) Базові етапи життєвого циклу ..........................................................................19 Додаток D (довідковий) Використання в IDM методів BPMN .................................................................22 Бібліографія ................................................................................................................................................26 ДСТУ EN ISO 29481-1:2022 V НАЦІОНАЛЬНИЙ ВСТУП Цей національний стандарт ДСТУ EN ISO 29481-1:2022 (EN ISO 29481-1:2017, IDT; ISO 29481-1:2016, IDT) «Інформаційні моделі будівель. Настанова з доставляння інформації. Частина 1. Методологія та формат», прийнятий методом перекладу, — ідентичний щодо EN ISO 29481-1:2017 (версія en) «Building information models — Information delivery manual — Part 1: Methodology and format» (ISO 29481-1:2016). Технічний комітет стандартизації, відповідальний за цей стандарт в Україні, — ТК 301 «Метало- будівництво». У цьому національному стандарті зазначено вимоги, які відповідають законодавству України. До стандарту внесено такі редакційні зміни: — слова «цей міжнародний стандарт», «ця частина стандарту» та «цей документ» замінено на «цей стандарт»; — структурні елементи стандарту: «Титульний аркуш», «Передмову», «Зміст», «Національний вступ», першу сторінку, розділи «Терміни та визначення понять» та «Бібліографічні дані» — оформлено згідно з вимогами національної стандартизації України; — у розділі 2, підрозділі 5.3, додатку D та «Бібліографії» наведено «Національне пояснення», виділене рамкою; — зі «Вступу» до EN ISO 29481-1:2017 у цей «Національний вступ» внесено все, що безпосередньо стосується цього стандарту; — рисунки наведено прямо після тексту, де вперше виконано посилання на них, або на черговій сторінці; — виправлено друкарські помилки в Передмові до ISO 29481-1:2016 і таблиці D.1. Копії нормативних документів, посилання на які є в цьому стандарті, можна отримати в Національному фонді нормативних документів. ПЕРЕДМОВА до ISO 29481-1:2016 ISO (Міжнародна організація зі стандартизації) є всесвітнім об’єднанням національних органів стандартизації (органів-членів ISO). Роботу з підготування міжнародних стандартів зазвичай виконують, залучаючи технічні комітети ISO. Кожен орган-член ISO, зацікавлений у темі, за якою створено технічний комітет, має право бути представлений у цьому комітеті. У роботі беруть участь також урядові та неурядові міжнародні організації, які взаємодіють з ISO. ISO тісно співпрацює з Міжнародною електротехнічною комісією (IEC) з усіх питань електротехнічної стандартизації. Процедури, використовувані для розроблення цього стандарту та призначені для його подальшого підтримання в актуальному стані, викладено в директивах ISO/IEC, частина 1. Зокрема, треба зазначити різні критерії схвалення, застосовні до різних типів документів ISO. Цей стандарт було розроблено відповідно до редакційних правил, викладених у директивах ISO/IEC, частина 2 (див. www.iso.org/ directives). Потрібно звернути увагу на те, що деякі елементи цього стандарту можуть бути предметом патентних прав. ISO не несе відповідальності за виявлення будь-якого чи всіх таких патентних прав. Подробиці щодо будь-яких патентних прав, виявлених під час розроблення стандарту, наведено у вступі та/або в списку отриманих патентних декларацій ISO (див. www.iso.org/patents). Будь-яка торговельна назва, використана в цьому стандарті, є інформацією, наданою користувачам для зручності, і не означає схвалення. Роз’яснення щодо добровільного застосування стандартів, значень специфічних термінів та формулювань ISO, пов’язаних з оцінюванням відповідності, а також інформація про приєднання ISO до принципів Світової організації торгівлі (СОТ) щодо технічних бар’єрів у торгівлі (TВT) доступні за адресою: https://www.iso.org/foreword-supplementary-information.html. Комітет, відповідальний за цей документ, — ISO/TC 59, «Будівлі та інженерні споруди», ПК 13 «Організація інформації щодо будівель та споруд». Другу редакцію цього стандарту введено на заміну скасованої попередньої редакції ISO 29481-1:2010, яку було переглянуто з технічними поправками. Стандарт ISO 29481 під загальною назвою «Інформаційні моделі будівель. Настанова з доставляння інформації» містить такі частини: — частина 1 «Методологія та формат»; — частина 2 «Принципи взаємодії». ДСТУ EN ISO 29481-1:2022 VI ВСТУП до ISO 29481-1:2016 Цей стандарт зазнав ґрунтовного перегляду з огляду на вдосконалені підходи до розроблення настанов із доставляння інформації та їх технічної реалізації в формах, придатних до читання програмними засобами. Важливо зауважити, що ці зміни не призведуть до того, що існуючі настанови з доставляння інформації (information delivery manuals, IDM) стануть незастосовними. Будівельне інформаційне моделювання є цифровою технологією для описування й представлення інформації, застосовної до планування, проєктування, зведення та експлуатації будівельних об’єктів. Цей підхід до моделювання набуває щодалі більшого поширення, охоплюючи всі аспекти середовища забудови, зокрема об’єкти інфраструктури, інженерні мережі та місця громадського користування. Сукупно все це називають будівельними процесами. Такий підхід до управління інформацією об’єднує різні набори даних, використовувані протягом життєвого циклу будівельного об’єкта, в об’єднане інформаційне середовище, зменшуючи, а часом і зовсім усуваючи потребу в багатьох типах традиційно використовуваної документації на паперових носіях. Цей підхід зазвичай називають будівельним інформаційним моделюванням (building information modelling; BIM); застосування поняття було започатковано в сфері архітектури, причому ту саму абревіатуру використовують також для позначення результату процесу — інформаційної моделі як такої або інформаційної моделі будівлі (building information model; BIM). Хоча основну увагу в зазначених вище процесах будівництва приділено фізичній структурі середовища забудови, технологія BIM також може сприяти процесам, пов’язаним з управлінням використовуваним простором будівель та у ширшому масштабі – міських кварталів і міст, а також із об’єктами інфраструктури та інженерними мережами будівель. У цьому стандарті їх розглянуто як «варіанти використання». IDM забезпечує найбільш ефективне застосування BIM. Якщо інформація, потрібна для підтримання процесу будівництва або варіанту використання, доступна в форматах BIM, і якість цієї інформації є задовільною, то це сприятиме значному поліпшенню процесу. Для цього потрібне спільне розуміння процесів протягом усього життєвого циклу спроєктованого будівельного об’єкта у середовищі забудови, зокрема інформації, потрібної для реалізації процесу та отримання його результатів. Це стосується будь-якої діяльності, яка призводить до обміну інфор- мацією, і може не стосуватися безпосередньо BIM, як наприклад, процес складання плану робіт чи укладання договору. У цьому стандарті викладено методологію розроблення комплексного нормативного документа, в якому описано процеси і дані, потрібні для розроблення або управління побудованим об’єктом. У стандарті викладено способи визначення та описування виконуваних у зазначеному контексті процесів, потрібної для їх виконання інформації та результатів процесу. У цьому стандарті також в загальних рисах описано, як цю інформацію може бути додатково деталізовано для підтримання програмних рішень, які надають розробники програмного забезпечення, для уможливлення її повторного використання та налаштування відповідно до потреб національного, регіонального рівня та конкретного проєкту. Отже, у цьому стандарті встановлено основні принципи, які забезпечують надійність обміну/ спільного використання інформації користувачами, щоб вони були впевнені, що отримана ними інформація є точною і достатньою для виконання їхньої діяльності. Розроблення цього стандарту було обумовлено потребою користувачів досягти надійності обміну інформацією. 1 ДСТУ EN ISO 29481-1:2022 НАЦІОНАЛЬНИЙ СТАНДАРТ УКРАЇНИ ІНФОРМАЦІЙНІ МОДЕЛІ БУДІВЕЛЬ НАСТАНОВА З ДОСТАВЛЯННЯ ІНФОРМАЦІЇ Частина 1. Методологія та формат BUILDING INFORMATION MODELS INFORMATION DELIVERY MANUAL Part 1: Methodology and format Чинний від 2022-10-01 1 СФЕРА ЗАСТОСУВАННЯ У цьому стандарті визначено: — методологію встановлення взаємозв’язків між бізнес-процесами, здійснюваними на етапі будівництва об’єктів, технічних вимог щодо інформації, потрібної для функціонування цих процесів, та — способи розроблення карт і описування процесів управління інформацією протягом життєвого циклу будівельних об’єктів. Цей стандарт призначений для забезпечення функціональної сумісності програмного забезпечення, використовуваного на всіх етапах життєвого циклу будівельних об’єктів, зокрема під час складання завдань на проєктування/описів, проєктування як такого, розроблення документації, виконання будівельних робіт, експлуатації, технічного обслуговування та знесення. Стандарт також сприяє співпраці між дійовими особами — учасниками процесу будівництва у сфері цифрових технологій та утворенню основи для обміну точною, достовірною, відтворюваною і високоякісною інформацією. 2 НОРМАТИВНІ ПОСИЛАННЯ Наведені нижче нормативні документи, у повному складі чи їхні частини, необхідні для застосування цього стандарту. У разі датованих посилань застосовують тільки наведені видання. У разі недатованих посилань потрібно користуватись останнім виданням наведених нормативних документів (разом зі змінами). ISO 6707-1 Building and civil engineering — Vocabulary — Part 1: General terms. НАЦІОНАЛЬНЕ ПОЯСНЕННЯ ISO 6707-1 Будівлі та інженерні споруди. Словник. Частина 1. Загальні терміни. 3 ТЕРМІНИ ТА ВИЗНАЧЕННЯ ПОНЯТЬ У цьому стандарті вжито терміни та визначення понять, наведені в ISO 6707-1, а також зазначені нижче. 3.1 дійова особа (actor) Особа, організація чи її підрозділ (наприклад, відділ, група тощо), залучені до процесу будівництва 3.2 будівельне інформаційне моделювання; ВІМ (building information modelling; BIM) Використання загального цифрового представлення будівельного об’єкта (зокрема, будівель, мостів, доріг, технологічного устатковання тощо) для сприяння процесам проєктування, спорудження та експлуатації, а також створення надійної основи для прийняття рішень. Примітка. Абревіатура BIM також означає цифрове представлення для спільного використання фізичних і функціональних характеристик будь-яких будівельних об’єктів ДСТУ EN ISO 29481-1:2022 2 3.3 програмне забезпечення ВІМ (BIM software application) Програмне забезпечення для створення, змінення, аналізування, управління, публікування, спільного використання, скасування або інших дій з елементами BIM 3.4 бізнес-вимога (business requirement) Вимога, в якій описано комерційною термінологією те, що потрібно доставити або виконати 3.5 інформаційне обмеження (information constraint) Ствердження, в якому формально визначено або обмежено сферу застосування певного обсягу інформації, пов’язаної з певним аспектом бізнесу, правило, згідно з яким функціонує організація, або стратегія чи рішення, які впливають на процес 3.6 клас (class) Тип або сукупність предметів, які мають спільні ознаки 3.7 будівлі та споруди (construction works) Все, що побудовано або є результатом будівельних робіт. [ДЖЕРЕЛО: ISO 6707-1:2014, 3.1.1] Примітка. Термін може означати будівлю, об’єкт інфраструктури (дорога, міст, трубопровід тощо) або елемент благоустрою території, а також бути застосованим у більш широкому розумінні, охоплюючи сукупність цих елементів, з яких сформовано міський район, університетське містечко або інституційний заклад 3.8 процес будівництва (construction process) Процес, у якому використовують будівельні ресурси для досягнення результатів будівництва. Примітка. Будь-який процес будівництва можна розділити на складові процеси 3.9 вимога щодо обміну; ER (exchange requirement; ER) Визначений набір блоків інформації, потрібних для обміну з метою виконання певної бізнес-вимоги на певній фазі (або фазах) / стадії (або стадіях) процесу 3.10 настанова з доставляння інформації; IDM (information delivery manual; IDM) Документація, в якій охоплено бізнес-процес та наведено детальні технічні вимоги щодо інформації, доставляння якої користувач, який виконує певну роль, має забезпечити у певний термін під час реалізації проєкту. Примітка. Цей термін може означати технічні вимоги щодо доставляння інформації (information delivery specification; IDS) 3.11 компоненти IDM (IDM components) Базові елементи, з яких формують IDM: карти взаємодії/карти транзакцій, карти процесів і вимоги щодо обміну 3.12 блок інформації (information unit) Окремий елемент інформації, наприклад, ідентифікатор вікна або висота приміщення 3.13 карта взаємодії (interaction map) Представлення ролей і транзакцій, пов’язаних із досягненням певної цілі 3.14 структура взаємодії (interaction framework) Формалізований опис елементів взаємодії, зокрема, визначення ролей, транзакцій, повідомлень у транзакції та елементів даних у повідомленнях 3.15 модель (model) Представлення системи, яке уможливлює дослідження її властивостей 3.16 визначення проєкції моделі; MVD (model view definition; MVD) Інтерпретоване комп’ютером визначення вимоги щодо обміну, пов’язане конкретно з однією або декількома певними стандартними інформаційними схемами. Примітка. Визначення проєкції моделі (MVD) також називають визначенням модельного виду, підмножиною (схеми) та класом відповідності (conformance class; CC), зокрема, в ISO 10303 3.17 об’єкт (object) Будь-яка частина навколишнього світу, осяжна у відчуттях або мислима. Примітка. Об’єкт – це дещо абстрактне або фізичне, на що спрямована думка, почуття чи дія 3.18 карта процесу; РМ (process map; PM) Представлення характеристик процесу, відповідних до визначеної бізнес-цілі ДСТУ EN ISO 29481-1:2022 3 3.19 роль (role) Функції, виконувані дійовою особою у певний момент часу. Примітка. Роль дійової особи визначають не за професією чи видом виконуваної діяльності, а за дією та її результатом 3.20 транзакція (transaction) Подія комунікації, під час якої реалізують взаємодію виконавці двох ролей 3.21 карта транзакції (transaction map) Представлення набору повідомлень, призначених для обміну між виконавцями ролей для досягнення певної цілі. 4 НАСТАНОВА З ДОСТАВЛЯННЯ ІНФОРМАЦІЇ 4.1 Загальні положення У цьому розділі викладено концепції та принципи, призначені для розроблення IDM. 4.2 Користувачі цього стандарту Цей стандарт призначений здебільшого для користувачів, залучених до розроблення IDM, карт взаємодії, карт процесів, встановлення вимог щодо обміну та інформаційних обмежень із урахуванням відомостей, отриманих від кінцевих користувачів та постачальників програмного забезпечення. Крім того, деякі користувачі конкретних IDM можуть потребувати розроблення нових і, в такий спосіб, долучатися до цільової аудиторії цього стандарту. Такими користувачами є: — професійні розробники IDM та постачальники програмного забезпечення; — користувачі інформації, тобто виконавці робіт та кінцеві користувачі, які розробляють інформаційний вміст IDM та отримують комерційний прибуток від результату робіт. Іншою групою користувачів можуть бути ті, які застосовують документацію, розроблену завдяки використанню цього стандарту з урахуванням певного бізнес-процесу та на підставі докладних технічних вимог щодо інформації, яку користувач, виконуючи певну роль, має надавати в певний термін під час реалізації проєкту. До таких користувачів належать: — менеджер проєкту, відповідальний за організацію бізнес-процесу й забезпечення належного керування обміном інформацією; — менеджер BIM, який забезпечує дотримання встановлених вимог щодо обміну; — замовник, який ініціює (розробляє) та долучає IDM до договірної документації; — підрядник/консультант, який використовує IDM для визначення заходів, потрібних для дотримання відповідності до встановленого бізнес-процесу та вимог щодо інформації; — бізнес-менеджер, який використовує IDM як шаблон або стандарт для багатьох проєктів у своїй організації; — будівельна організація, що використовує IDM як шаблон або стандарт для проєктів у сфері своєї спеціалізації. 4.3 Бізнес-контекст процесу На рисунку 1 наведено приклад бізнес-контексту процесу, для якого потрібна IDM: замовник (роль 1) залучає консультанта (роль 2) для надання певної послуги. За такого сценарію їм потрібно усвідомити й офіційно оформити спільні та договірні аспекти взаємодії, а також умови доставляння інформації в цьому контексті. В IDM описують вимоги щодо інформації, пов’язані з усіма транзакціями (в обох напрямках), що стосуються цих відносин. Якусь частину цієї інформації буде збережено у складі BIM, а решту може бути отримано від будь-якої іншої сторони або із зовнішнього джерела. ДСТУ EN ISO 29481-1:2022 4 Рисунок 1 — Приклад простого бізнес-контексту, що потребує застосування IDM Першим кроком у розробленні IDM є розгляд сутності або контексту обмінювання інформацією. Існують два підходи щодо цього розгляду, для кожного з яких передбачено відповідну методологію. — Карти процесів є найбільш ефективними, якщо основну увагу зосереджено саме на бізнес- процесах (визначених за видами діяльності учасників-виконавців ролей), які має бути виконано для надання послуги або виготовлення кінцевої продукції (наприклад, проєкту). У цьому разі інформація, що є предметом розгляду в IDM, пов’язана з бізнес-вимогами. — Карти взаємодії/карти транзакцій є найбільш ефективними в межах бізнес-процесу, якщо основну увагу зосереджено на взаємодії між учасниками-виконавцями ролей, які мають надавати послугу або результати виробничого процесу, і завдання полягає в тому, щоб забезпечити наявність узгоджених протоколів комунікації для гарантованого досягнення цілей проєкту. У цьому разі предметом розгляду в IDM є інформація, пов’язана із транзакціями. Зазначені вище підходи є взаємно доповнюваними, і детальніші пояснення щодо них викладено в розділах цього стандарту нижче. У бізнес-контексті, який наведено в цьому розділі, може бути доцільним використання обох методологій: карта процесу може бути використана для уточнення деталей транзакції, встановленої під час практичного вирішення завдань за умов взаємодії, тоді як карту взаємодії можна використовувати для чіткого розуміння сутності інформаційної транзакції, визначеної в карті процесу. 4.4 Повна схема Коли інформаційні вимоги виконують за допомогою BIM, повна схема, що містить всю інформацію, потрібну всім учасникам упродовж процесу будівництва, буде величезною та складною. Така схема є виправданою для позначення всієї потрібної інформації для всіх бізнес-процесів на всіх етапах життєвого циклу, але не є способом, за яким зазвичай надають інформацію. 4.5 Розбиття повної схеми на складові для забезпечення виконання вимог Зазвичай обмін інформацією відбувається за певною темою та з рівнем деталізації, визначеним відповідно до етапу життєвого циклу. Він може бути пов’язаний з окремими бізнес-процесами на певному етапі життєвого циклу проєкту, але зазвичай охоплює блоки інформації, які можуть стосуватися більше ніж одного етапу життєвого циклу або бізнес-процесу. Це зазвичай називають представленням моделі, у зв’язку з чим мова піде про те, які компоненти інформаційної схеми потрібно застосовувати для задоволення вимог. Настанова з доставляння інформації Застосовна R1 Замовник R2 Консультант Т1 ДСТУ EN ISO 29481-1:2022 5 4.6 Підтримання процесу будівельного інформаційного моделювання Елементи загальної інформаційної схеми використовують в інформаційній моделі будівлі (див. рисунок 2). Для окремого бізнес-процесу потрібні тільки певні класи інформації. Кожен клас охоплює велику кількість об’єктів, кожен об’єкт має ідентичність (унікальний ідентифікатор) та статус (встановлюваний значеннями, присвоєними кожному атрибуту об’єкта). У сукупності класи, які підтримують бізнес-процес, утворюють унікальну й ідентифіковану стандартну схему, або модельний вид. Рисунок 2 — Підтримання процесу ВІМ 4.7 Підтримання бізнес-процесу Має бути встановлено набір інформації, обмін якою потрібний для сприяння функціонуванню конкретного бізнес-процесу або взаємодії на відповідних етапах життєвого циклу (в межах бізнес-процесу). Такий набір інформації називають вимогою щодо обміну. Вимога щодо обміну передбачає опис потрібної для обміну інформації, викладений нетехнічною мовою. Вимога щодо обміну може підтримувати передавання інформації про об’єкт, що забезпечуватиме зведення та експлуатацію будівельного об’єкта, або передавання інформації, пов’язаної з управлінням та контролюванням виконуваного проєкту. 4.8 Підтримання програмного рішення Перехід від визначеної вимоги щодо обміну інформацією до реалізації програмного рішення постачальником програмного забезпечення передбачає визначення модельного виду (MVD). Цей підхід уведено на заміну вимог, впровадження яких було передбачено у попередній редакції цього стандарту. 4.9 Специфічний інформаційний вміст IDM Нижче наведено специфічний інформаційний вміст IDM, який має охоплювати: — опис потреби щодо обміну в бізнес-контексті; — визначення дійових осіб, які надсилають та отримують інформацію; — встановлення, визначення та опис призначеної для обміну інформації для задоволення кожної вимоги у певний термін у бізнес-контексті; — умови, за яких надання визначень, технічних вимог та описів буде забезпечено у формі, яка є практично застосовною та зрозумілою; — умови розроблення детальних технічних вимог щодо інформації, охоплених вимогами щодо обміну, для сприяння розробленню програмного забезпечення BIM, та — умови, за яких буде гарантовано, що технічні вимоги щодо інформації відповідатимуть загально- прийнятій практиці за місцем застосування. Рекомендації щодо розроблення інформаційного вмісту та застосування відповідних методів наведено в додатку А. Інформаційна модель будівлі Інформаційна схема За схемою визначають сукупність моделей За класом визначають шаблон для сукупності об’єктів Схема визначена сукупністю класів Стандартна схема Клас Модель Модель уміщує сукупність об’єктів Об’єкт ДСТУ EN ISO 29481-1:2022 6 5 СТРУКТУРА IDM 5.1 Загальні положення Настанова з доставляння інформації (рисунок 3) містить: — карту взаємодії/карту транзакцій та/або карту процесу; — одну або кілька вимог щодо обміну інформацією. У карті взаємодії визначено залучені ролі та транзакції між ними. У кожній конкретній транзакції одна з ролей належить ініціатору, інша — виконавцю. У відповідній карті транзакції визначені повідомлення транзакції та застосовні правила щодо послідовності виконання. У карті процесу кожну роль зображують як смугу або «доріжку», всередині якої визначають відповідну послідовність дій для виконавця ролі. Дії виконавців різних ролей можуть потребувати обміну інформацією у формі повідомлень. Приклади таких повідомлень зображені на карті транзакції. Рисунок 3 — Базова структура IDM Деякі повідомлення можуть містити пакет інформації BIM, що обумовлює потребу визначити вимоги щодо обміну. Вимога щодо обміну містить вичерпний опис інформації, яку потрібно долучити до BIM та яка Структура взаємодії Визначення проєкції моделі Блоки інформації Вимога щодо обміну Вимоги щодо бібліотеки Взаємозв’язки між діями Об’єкт даних Доріжка Вимога щодо обміну Дії Інформаційні обмеження Рекомендації Опис потреби Технічне виконання Транзакція Ініціює Виконує Ініціатор Виконавець Роль Карта взаємодії/карта транзакції Карта процесу Повідомлення в транзакції Настанова з доставляння інформації ДСТУ EN ISO 29481-1:2022 7 пов’язана із повідомленням, яке потрібно передати під час міжрольової взаємодії. Вона містить встановлені вимоги щодо інформації, зокрема посилання на об’єкти бібліотеки, якщо це передбачено, а також опис потреби, рекомендації щодо використання та будь-які інформаційні обмеження, які можуть бути застосовані. Технічне виконання вимоги щодо обміну здійснюють на підставі визначення модельного виду. Технічне виконання карти взаємодії/ карти транзакцій здійснюють у межах взаємодії. 5.2 Базова структура 5.2.1 Загальні вимоги Кожний компонент IDM (карта процесу, карта взаємодії/карта транзакції або вимога щодо обміну) має містити заголовок та загальну інформацію про компонент з урахуванням викладених нижче вимог. 5.2.2 Інформаційний вміст заголовка компонента IDM Кожний компонент IDM має містити щонайменше таку виконавчу інформацію: — найменування або назва, що відповідає правилам іменування, наведеним у таблиці 1; — унікальний ідентифікатор; — етап проєкту, підтримуваний компонентом; — журнал змін, в якому зафіксовано дані щодо створення та всіх внесених змін із позначенням автора та дати. ДСТУ EN ISO 29481-1:2022 8 Таблиця 1 — Правила іменування Ч. ч. Правило іменування 1 Потрібно, щоб кожний компонент IDM мав ім’я 2 Першою частиною імені є префікс: — er_ для вимоги щодо обміну; — im_ для карти взаємодії; — pm_ для карти процесу; — tm_ для карти транзакції 3 Ім’я, присвоєне кожному компоненту IDM, є імперативом, складеним із двох частин: — перша частина імені — це потрібна для виконання дія (або діяльність), виражена дієсловом; — друга частина імені — це об’єкт, на який спрямовано дію, виражений іменником або іменниковим словосполученням. Це може бути прямий об’єкт (наприклад, «моделювати стіну») або непрямий об’єкт, який мають на увазі (наприклад, «пов’язати матеріал», що означає пов’язати {зі стіною} {матеріал}) 4 Усі ідентифіковані слова в імені мають бути відокремлені за допомогою символу підкреслення «_» 5 Компоненти IDM можуть мати додаткові кваліфікаційні параметри. Ці параметри виражають у вигляді списку в круглих дужках, наприклад, (a,b,c,d) Етап проєкту визначають відповідно до етапу життєвого циклу. Довідкову інформацію стосовно етапів життєвого циклу наведено в додатку С. Буває доцільно, передаючи кожен блок інформації, зробити посилання на вимогу щодо обміну, зазначену стосовно інформаційного вмісту. 5.2.3 Опис компонента IDM Опис кожного компонента IDM потрібно починати з короткого простого опису інформаційного вмісту, варіантів використання, цілей та сфери застосування, з якими має бути пов’язано компонент, або з опису про те, яку інформацію за конкретною темою чи бізнес-вимогою потрібно отримати. Приклади спрощених компонентів IDM наведені в додатку B. 5.3 Карта взаємодії/карта транзакції Призначеність карти взаємодії полягає у визначенні відповідних ролей та транзакцій для досягнення певної цілі, зазвичай колективного виконання проєктного завдання виконавчою групою. У контенті IDM розрізняють роль, виконуючи яку дійова особа ініціює запит (ініціатор), та іншу роль, дійова особа якої опрацьовує цей запит (виконавець). Комунікацію, потрібну для такої взаємодії, називають транзакцією. Рекомендовано, щоб метод розроблення карти взаємодії відповідав моделі CRISP (Dietz, J.L.G. : Enterprise Ontology, Springer, 2006). НАЦІОНАЛЬНЕ ПОЯСНЕННЯ Дітц Я. Л. Г. Онтологія підприємства. — Шпрінгер, 2006. Вміст карти взаємодії має охоплювати всі транзакції, потрібні для оброблення доставленої для BIM інформації дійовими особами, що виконують відповідні ролі. Усім транзакціям у карті взаємодії присвоюють унікальний ідентифікатор та ім’я. Карта транзакцій — це представлення повідомлень, якими можуть обмінюватися між собою дійові особи, задіяні у певних ролях, що беруть участь у конкретній транзакції, з урахуванням обмежень щодо послідовності виконання дій. Для розроблення карти транзакцій рекомендовано метод UML (Unified Modeling Language) — діаграма послідовностей). Обмін повідомленнями виконують з певною метою (наприклад, у разі запиту щодо внесення зміни або доставляння пакету інформації). Повідомлення являє собою заповнену інформаційну модель, що містить дані, які стосуються процесу. Повідомлення може мати одне або кілька вкладених файлів. За допомогою транзакцій визначають вимоги щодо ділової співпраці та комунікації, що надає можливість контролювати дії виконавців відповідних ролей та внесену ними у BIM інформацію. Для цього в конкретних транзакціях як додатки до певних повідомлень можуть бути долучені такі компоненти: — вимога щодо обміну; — пакет інформації (сукупність даних об’єкта, що є фактично доставлянням інформації, яка задовольняє потребу щодо обміну); ДСТУ EN ISO 29481-1:2022 9 — вікно авторизації: в контексті транзакції виконавець ролі може отримати доступ до програмних засобів BIM. У вікні авторизації зазначають, яку інформацію в цій транзакції можна читати або змінювати виконавцю ролі. 5.4 Карти процесів Призначеність карти процесів полягає в зображенні послідовності дій у межах конкретного бізнес- процесу, описуванні виконуваних учасниками ролей, залучених до процесу, та інформації, якої потребують, яку використовують та створюють. Для представлення карт процесів рекомендовано метод BPMN (Business Process Modelling Notation) — Нотація для моделювання бізнес-процесів. Додаткову інформацію щодо BPMN наведено в додатку D. В охопленій IDM карті процесу: — встановлюють межі для обсягу інформації, яку містить процес; — встановлюють дії, виконувані в межах процесу; та — зображують логічну послідовність дій. Інформацію, якої фактично потребують у межах процесу, визначають на підставі зазначених для процесу вимог щодо обміну. Карта процесу містить таку виконавчу інформацію: — вимоги щодо обміну в межах процесу; — вичерпний опис усього процесу; для ілюстрування окремих положень опису можна використовувати діаграми. 5.5 Вимоги щодо обміну 5.5.1 Загальні вимоги На підставі вимоги щодо обміну визначають інформацію, якою потрібно обмінюватися для підтримання зазначеного бізнес-процесу на певному етапі проєкту. Опис інформації передбачено надавати нетехнічною мовою. Вимога щодо обміну має бути зрозумілою для кінцевих користувачів (архітектора, інженера, конструктора тощо). Вимоги щодо обміну використовують для розроблення MVD, що є технічною специфікацією, яку використовують для розроблення програмного забезпечення відповідно до 5.6.3. Потреба щодо обміну інформацією відображає зв’язок між процесом і даними. Вона містить опис набору пов’язаної з процесом інформації, яку має доставити дійова особа в ролі ініціатора, щоб уможливити подальший процес виконання дій іншою дійовою особою у ролі виконавця. Цю потребу має бути визначено за умов чіткого розумінням інформаційних потреб дійових осіб наступного суміжного логічного потоку. 5.5.2 Блоки інформації Потрібну інформацію надають як набор блоків інформації. Блок інформації, зазвичай пов’язаний з одним із типів інформації або поняттям. Блок інформації може містити лише сутність, наприклад, «проєкт», «стіна», або сутність (наприклад, проєкт) та її атрибут (наприклад, ім’я), тобто «ім’я проєкту», «довжина стіни». Для вимоги щодо обміну спочатку визначають передумови. Такою передумовою є вимога щодо обміну, якої має бути дотримано до початку виконання поточної вимоги щодо обміну інформацією. Опісля мають бути зазначені інформаційні блоки з урахуванням таких вимог: — опис блоку інформації має бути якомога більш докладним і достатньо однозначним, щоб запобігти помилковому розумінню понять розробниками MVD; — має бути надано інформацію, потрібну для визначення інформаційного блоку; ці вимоги має бути викладено у спеціально розроблених положеннях, рекомендаціях або правилах, пов’язаних із цією інформацією. 5.5.3 Інформаційні обмеження В інформаційних обмеженнях зазначають тип даних інформаційного блоку, а також контекст, правила та обмеження щодо використання зазначеного інформаційного блоку. Нижче наведено кілька прикладів стосовно типів даних та правил. — Типи даних: — текст, ціле число, номер, 2D-графіка, 3D-модель тощо. ДСТУ EN ISO 29481-1:2022 10 — Контекст, правила та обмеження щодо використання: — потрібно, щоб стіл мав щонайменше три ніжки; — потрібно, щоб збірний залізобетонний елемент мав щонайменше три ідентифікатори: маркувальний номер виробу (заводський серійний номер), познаку марки (згідно з проєктом) та ідентифікатор місця встановлення; — площа кімнати не може бути менше ніж 0 м2, та — потрібно, щоб у разі доставки звичайним вантажним автомобілем найбільший розмір панелі не перевищував 14 м. 5.6 Технічне виконання 5.6.1 Загальні положення У цьому стандарті основним предметом розгляду є підготовка спільно застосовуваного мовного опису вимог щодо інформації, пов’язаних із бізнес-процесами, зокрема тими, що охоплюють обмін даними BIM. Ці технічні вимоги щодо інформації можуть бути покладені в основу автоматизованих процесів, пов’язаних із використанням програмного забезпечення, які в цьому стандарті названо технічним виконанням. У цьому розділі описано принципи та сферу застосування доступних варіантів технічного виконання, які є предметами розгляду в інших частинах цього стандарту. 5.6.2 Створення метаданих Головна призначеність усіх варіантів технічного виконання полягає у перетворенні специфікацій у машиночитану форму, що містить визначальні метадані (заголовок, загальний опис, класифікацію), потрібні для автоматизованого процесу. 5.6.3 Структура взаємодії Структура взаємодії — це формальний опис елементів взаємодії, зокрема визначення ролей, транзакцій, повідомлень у транзакції, послідовності повідомлень і елементів даних у повідомленнях. Методологію розроблення структури взаємодії та вимоги щодо її формату викладено в ISO 29481-2. 5.6.4 Визначення проєкції моделі (MVD) У визначенні проєкції моделі (Model view definition; MVD) встановлюють модель даних або підмножину моделі даних, яка вже існує та потрібна для виконання однієї або кількох конкретних вимог щодо обміну (рисунок 4). MVD, що використовують під час розроблення програмного забезпечення, має бути представлено в машиночитаній формі. MVD, призначене для окремої IDM, може бути використано в програмних засобах для вибирання інформації відповідно до конкретної вимоги щодо обміну. Якщо до MVD долучено інформаційні обмеження, то таке поєднання може бути використано для перевіряння даних. У програмних продуктах, які підтримують кілька вимог щодо обміну, може бути впроваджено консолідоване MVD, застосовне до кількох IDM. Ці MVD часто використовують для цілей сертифікації програмних продуктів, але перевірку даних завжди має бути виконано за кожним MVD окремо. ДСТУ EN ISO 29481-1:2022 11 Рисунок 4 — Взаємозв’язок між IDM та MVD Вимога щодо обміну MVD MVD + інформаційні обмеження MVD + інформаційні обмеження MVD Вимога щодо обміну Вимога щодо обміну Вимога щодо обміну MVD MVD + інформаційні обмеження Об’єднане MVD IDM IDM IDM Вимоги Впровадження програмного забезпечення/сертифікація Перевіряння даних ДСТУ EN ISO 29481-1:2022 12 ДОДАТОК А (довідковий) ПРОЦЕС РОЗРОБЛЕННЯ IDM А.1 Внесення пропозиції щодо розроблення IDM А.1.1 Загальна інформація Внесення пропозиції щодо розроблення IDM є попереднім етапом, на якому встановлюють умови для роботи, яку потрібно виконати. Ці умови стосуються: — визначення обсягу роботи, — встановлення методів розроблення, — визначення ресурсів, та — складання плану проєкту. А.1.2 Визначення сфери застосування Сфера застосування встановлює межі контексту для виконуваної роботи, забезпечивши постійне посилання на них для досягнення впевненості в тому, що обсяг роботи не перевищує межі, досягнення якої призведе до нестачі запланованих або наявних ресурсів. Під час підготування потрібно відповісти на такі питання: — Якими потребами бізнесу обумовлено обмін інформацією? — Хто може описати ці потреби? — Хто буде дійовими особами, які їхні ролі та інтереси? — Як можна підготувати й організувати обмін інформацією? — Чи сприятимуть укладені угоди, умови договорів, стандартів тощо обмінюванню інформацією? Підготування завершують оцінюванням можливості досягнення заявлених обсягів робіт і критеріїв успішності. Якщо оцінка є позитивною, можна розпочинати фактичне розроблення IDM. У разі негативної оцінки можна переглянути варіант використання або зупинити розроблення. Потрібно надати опис наявних ресурсів, а також усіх потрібних ресурсів ІТ. На підставі опису може бути доведена можливість досягнення цілей та розроблення на цій підставі IDM. Опис може свідчити й про неможливість досягнення бізнес-цілей. У цьому разі цілі потрібно переглянути відповідно до наявних та, можливо, визначених нових ресурсів ІТ. В іншому разі дійові особи можуть прийняти рішення про відмову від розроблення IDM. В описі мають бути зазначені практичні та юридичні питання, пов’язані з обміном інформацією, для уточнення обов’язків та відповідальності залучених керівників і виконавців. Буває так, що умови нових договорів та угод унеможливлюють досягнення раніше визначених цілей та критеріїв результативності. У цьому разі такі цілі, за можливості, переглядають, щоб досягти відповідності до умов, встановлених у договорах та стандартах. А.1.3 Встановлення методів розроблення Методи розроблення обирають із урахуванням обсягів інформації, наявного програмного забезпечення та інших умов, потрібних для обміну інформацією. Такі методи описані в A.2.1. А.1.4 Визначення ресурсів Ресурси — це особи, яких потрібно залучити до розроблення IDM. Ці ресурси мають бути пропорційно розподілені між процесами управління проєктом, розробленням компонентів IDM відповідно до профільної освіти так, щоб уможливити керування розробленням компонентів і передаванням програмних рішень. На збалансованість потрібних ресурсів впливатимуть обрані способи взаємодії, обрані під час розроблення. А.1.5 План проєкту У плані проєкту встановлюють терміни розроблення, визначають завдання, які потрібно виконати, зазначають виділені ресурси та результати роботи, яких потрібно досягти. А.2 Розроблення IDM А.2.1 Загальна інформація Існують три методи розроблення IDM: — дослідження процесу; — налаштування за допомогою інформаційних обмежень; — зворотне проєктування. ДСТУ EN ISO 29481-1:2022 13 А.2.2 Дослідження процесу А.2.2.1 Загальна інформація Дослідження процесу є традиційним методом, який використовують для розроблення IDM. Він заснований на припущенні відсутності програмного забезпечення, з якого може бути визначено вимоги, або інших вимог щодо обміну, які може бути налаштовано. Цей метод розроблення описано нижче як лінійну послідовність. На практиці може відбуватися зворотній зв’язок між етапами розроблення та циклічність у процесі розроблення. А.2.2.2 Процес дослідження Запропоновано два альтернативних методи: складання карти процесу та карти взаємодії. Має бути прийнято рішення щодо використання методу, найбільш застосовного до бізнес-процесу. До процесу дослідження залучають, насамперед, галузевих експертів та спеціалізованих постачальників інформаційних систем для будівництва, щоб встановити межі сфери застосування, карти процесу або структуру взаємодії. Для досягнення задовільного результату цей процес зазвичай потребує кількох циклів розроблення та перевіряння. Після завершення у карті процесу або діаграмі взаємодії може бути представлено поточну практику або пропозиції щодо вдосконалення бізнес-процесів. На етапі розроблення потрібно прийняти рішення щодо того, чи створювати процес таким «як є», чи таким «як має бути». Згідно з картами процесів або картами взаємодії мають бути визначені «пакети» даних, обмінювання якими потрібно в певні моменти бізнес-процесу. Вони являють собою вимоги щодо обміну. А.2.2.3 Формулювання вимог щодо обміну Опісля потрібно сформулювати вимоги щодо обміну. За можливості, вони мають бути засновані на вимогах щодо обміну, які вже існують. А.2.3 Налаштування за допомогою інформаційних обмежень А.2.3.1 Визначення інформаційних обмежень Принцип обмеження інформації полягає у визначенні лише тієї, що потрібна у подальшому для прийняття рішень щодо існуючого (чи щойно визначеного) обміну інформацією. Їх може бути використано для управління властивостями, які треба задати, або значеннями, які може бути присвоєно. А.2.3.2 Локалізація інформаційних обмежень Локалізація інформаційних обмежень заснована на припущенні, що вимога щодо обміну пов’язана з потребою досягнення певної цілі, але не відповідає потребам використання в конкретному місці. Таким місцем може бути географічне розташування (країна, регіон тощо), сфера діяльності, пов’язана з проєктом або взаємодією, узгодженою між членами виконавчої групи. Інформаційні обмеження застосовують до окремих блоків інформації, щоб забезпечити їх використання у певному місці. Потрібно враховувати, що для того самого інформаційного блока можуть існувати різні інформаційні обмеження, застосовувані в контексті іншої вимоги щодо обміну або за іншим місцем розташування. А.2.4 Зворотне проєктування А.2.4.1 Загальна інформація Зворотне проєктування засноване на припущенні, що вже існує програмне забезпечення, використовуючи яке можна імпортувати потрібну інформацію, щоб виконати поставлене завдання, але конкретні елементи інформації задокументовано не достатньо. У разі експорту даних цей процес не придатний для визначення вимог щодо інформації, оскільки за умов експортування можуть існувати різні варіанти використання цих даних. Отже, для експорту даних вимога щодо інформації має бути визначена з урахуванням потреб програми, яка отримує такі дані. Типовим способом зворотного проєктування є покрокове досягнення цільового результату із застосованням інструментальних засобів програмування, а потім — дослідження роботи за сценарієм для виявлення та позначення окремих елементів даних, які потрібно отримати від вихідних програмних засобів. А.2.4.2 Встановлення сценарію У програмному забезпеченні потрібно визначити всі кроки, потрібні для досягнення заданого результату, у вигляді сценарію. Цей сценарій може бути встановлено як карту процесу або як докладний текстовий опис, що можна застосувати як вимогу щодо обміну. А.2.4.3 Визначення потрібних даних Потрібно відпрацювати за встановленим сценарієм у програмному застосунку та зазначити всі ДСТУ EN ISO 29481-1:2022 14 дані, потрібні для досягнення заданого результату. Стосовно кожного зазначеного елемента даних має бути перевірено, чи потрібно його отримувати з інших програмних засобів. Якщо так, то його потрібно долучити до вимоги щодо обміну, щоб імпортувати дані. А.2.4.4 Формулювання вимоги щодо обміну Потрібно сформулювати вимогу щодо обміну, використавши встановлений сценарій як один із розділів опису й долучивши визначені дані до технічного розділу. Сценарій можна викласти також у вигляді карти процесу. А.2.4.5 Визначення інформаційних обмежень Має бути визначено набір інформаційних обмежень, які можуть бути потрібними в подальшому для визначення вимог щодо обміну інформацією. Їх можна застосовувати для управління властивостями, які має бути задано, або значеннями, які може бути присвоєно. А.2.4.6 Відтворення процесу Одну чи кілька вимог щодо обміну, отриманих методом зворотного проєктування з програмних засобів, можна відобразити в карті процесу або карті взаємодії. А.2.5 Впровадження та використання IDM Щойно IDM було розроблено та впроваджено, може бути розпочато обмінювання інформацією. Призначену для обміну інформацію має бути перевірено перед відправленням та у разі отримання. За умов, коли дійові особи отримають відповідний досвід з обмінювання інформацією, можна проводити оцінювання процесу. Оцінювання має охоплювати етапи підготування, розроблення та практичного впровадження IDM. За бажанням залучених дійових осіб програмне забезпечення, відповідне до розробленої IDM, може бути надано для сертифікації згідно з установленими правилами. У процесі сертифікації потрібно продемонструвати, що програмні продукти придатні до експортування/імпортування даних відповідно до вимог щодо обміну. Достовірність результатів сертифікації має засвідчити незалежна організація. Для подання заявки на сертифікацію у постачальників програмного забезпечення має бути економічне обґрунтування, оскільки вартість підготовки та самої сертифікації може бути висока. ДСТУ EN ISO 29481-1:2022 15 ДОДАТОК В (довідковий) ПРИКЛАДИ СПРОЩЕНИХ КОМПОНЕНТІВ IDM В.1 Бізнес-контекст прикладів Нижче наведено приклади компонентів IDM у простому бізнес-контексті процесу, в якому замовник залучає групу консультантів, щоб виконати проєктне завдання. Завдання полягає у встановленні схеми планування приміщень будівлі. Результати роботи надають у вигляді 3D-контурів. Фактично доставлена інформація являє собою групу 3D-контурів та оцінку витрат. Цей приклад суттєво спрощено і не призначено для застосування в реальній ситуації. В.2 Карта процесу Назва: pm_29481_sample Ідентифікаційна познака: pm_29481_sample_1 Стадія проєктування: Обґрунтування доцільності проєктного рішення. Рисунок B.1 — Карта процесу В.3 Карта взаємодії Назва: im_29481_sample Ідентифікаційна познака: im_29481_sample_1 Стадія проєктування: Обґрунтування доцільності проєктного рішення. ДСТУ EN ISO 29481-1:2022 16 Рисунок B.2 — Карта взаємодії В.4 Карта транзакції Назва: tm_29481_sample Ідентифікаційна познака: tm_29481_sample_1 Стадія проєктування: Обґрунтування доцільності проєктного рішення. Рисунок B.3 — Карта транзакції Проєктне бюро Керування проєктом R2 Комплексне проєктування R3 Проєктування R4 Кошторисне нормування СR1 Замовник Т1 R1 Т4 Т3 Т2 R1: Управління проєктом СR1: Замовник М1 Запит щодо надання проєктного рішення М2 Виконана робота і затвердження проєктного рішення М3 Коригування проєктного завдання М4 Виконану роботу прийнято М5 Виконану роботу не прийнято Транзакція: Т1 — запит щодо надання проєктного рішення ДСТУ EN ISO 29481-1:2022 17 В.5 Вимога щодо обміну Назва: er_29481_sample Ідентифікаційна познака: er_29481_sample_1 Стадія проєктування: Обґрунтування доцільності проєктного рішення. Настанова Цю вимогу щодо обміну застосовують до надання 3D-контурів, що являють собою мінімальний або найменший контур будівельного об’єкта. Кожний екземпляр будівельного об’єкта потрібно надати в обмежувальній рамці. Кожна обмежувальна рамка має бути прив’язана до заданого центру системи координат проєкту. Опис інформаційної потреби Інформація призначена для оцінювання доцільності проєктного рішення з урахуванням фізичного планування будівлі. ДСТУ EN ISO 29481-1:2022 18 Блоки інформації Таблиця В.1 — Блоки інформації Тип об’єкта Визначення Приклад і додаткові пояснення Обов’язкові Додаткові Концептуальне представлення властивостей Властивість Побудований об’єкт Спроєктований, побудований чи встановлений об’єкт, функціонування якого забезпечує надання послуг або досягнення певної цілі: Об’єкти дорожньо- транспортної інфраструктури; навчальні заклади; нова науково-дослідна установа 3D-модель Тривимірний контур Мінімальна (найменша) рамка чи обмежувальний контур — термін, використовуваний у геометрії, із гранями, паралельними осям координатної сітки Ідентифікація Коротка назва, застосовна для посилань Х Опис Додатковий опис, призначений для інформування під час обмінювання коментарями Х Довжина Довжина обмежувального прямокутника Довжина обмежувального прямокутника Вимір довжини, наприклад, у міліметрах Х Ширина Ширина обмежувального прямокутника Вимір ширини, наприклад, у міліметрах Х Висота Висота обмежувального прямокутника Вимір висоти, наприклад, у міліметрах Х Розташування Розташування обмежувального прямокутника в системі координат Вектор і напрямок обертання від початку системи координат до точки вставки обмежувального прямокутника Х Вимоги щодо бібліотеки Всі типи об’єктів, концептуальні представлення властивостей та властивості потрібно структурувати відповідно до вмісту бібліотеки типів об’єктів, доступної для замовника. Інформаційні обмеження Всі інформаційні обмеження, згідно з їхнім визначенням у бібліотеці типу об’єкту, має бути дотримано. Метадані потрібно доставляти відповідно до вимог стандарту метаданих «Дублінське ядро» (Dublin Core Metadata Initiative). Вимоги щодо формату Інформаційні блоки потрібно доставляти у форматі XML; всі блоки інформації може бути упаковано в один файл. Інформаційні блоки потрібно доставляти як вкладені файли до повідомлення під час транзакції. Метадані доставляють через повідомлення під час транзакції. ДСТУ EN ISO 29481-1:2022 19 ДОДАТОК С (довідковий) БАЗОВІ ЕТАПИ ЖИТТЄВОГО ЦИКЛУ С.1 Стандартні етапи життєвого циклу Вимоги щодо обміну визначають як такі, що стосуються певних етапів проєкту. Щоб досягти узгодженості етапів життєвого циклу, їхнє визначення завжди має ґрунтуватися на загальних принципах. Стадії життєвого циклу визначають, застосовуючи здебільшого посилання на стандарт ISO 22263, в якому запропоновано такі основні стадії: — передпроєктне підготування; — розроблення завдання на проєктування/опису основних проєктних рішень; — проєктування; — виконання будівельних робіт; — технічне обслуговування; — знесення. Призначеність цього стандарту полягає в тому, щоб, розділяючи зазначені в ISO 22263 основні етапи на складові частини, забезпечити встановлення групи підетапів, призначених для розроблення карт процесів та вимог щодо обміну. Нижче наведено розкладені в такий спосіб етапи, назви яких зазначені згідно з ISO 22263. ДСТУ EN ISO 29481-1:2022 20 Таблиця С.1 — Етапи життєвого циклу згідно з ISO 22263 Назва згідно з ISO 22263 Стан- дартний етап Стандартна назва Стандартне визначення Етапи до початку життєвого циклу будівельного об’єкта Передпроєктне підготування 0 Вимоги щодо портфоліо Встановлення потреби розроблення проєкту для задоволення бізнес-вимог замовника Завдання на проєктування/опис 1 Концептуальний виклад потреби Визначення можливих проєктних рішень та плану для обґрунтування їхньої доцільності 2 Обґрунтування доцільності Оцінювання представлених на етапі 1 варіантів з огляду на їхню практичну доцільність та прийняття рішення щодо обґрунтування доцільності їх фінансування 3 Обґрунтування доцільності фінансування Затвердження фінансування Етапи до початку зведення будівельного об’єкта Проєктування 4 Концептуальне ескізне проєктування Визначення основних конструкційних елементів на основі запропонованих варіантів проєкту 5 Концептуальний проєкт у повному обсязі Концептуальний проєкт та результати всіх робіт, підготовлені для схвалення та переходу до детального планування 6 Скоординований проєкт (та закупівлі) Доопрацювання всіх основних елементів проєкту для отримання дозволу на будівельні роботи. Схвалення фінансування проєкту в повному обсязі Етапи зведення будівельного об’єкта Виробництво/ виконання робіт 7 Інформація виробничого призначення Оформлення всіх результатів роботи, потрібних, щоб розпочати зведення будівельного об’єкта 8 Зведення будівельного об’єкта Виконання робіт із виготовлення виробів та будівництва відповідно до вимог замовника. Передача будівлі в експлуатацію в запланований термін Етапи після приймання в експлуатацію зведеного будівельного об’єкта Технічне обслуговування 9 Експлуатація і технічне обслуговування Ефективна експлуатація та результативне технічне обслуговування побудованого об’єкта Знесення 10 Утилізація Виведення з експлуатації, демонтаж та утилізація конструкційних компонентів та будівлі в цілому відповідно до норм і правил з охорони довкілля та безпеки для життя і здоров’я С.2 Етапи життєвого циклу згідно з місцевими правилами Етапи життєвого циклу зазвичай визначають відповідно до місцевих правил організування процесів. Тобто визначення етапів життєвого циклу в різних країнах відрізнятимуться. Наприклад, розроблення проєкту у Великій Британії часто буває організовано відповідно до Плану роботи Королівського інституту британських архітекторів (Royal Institute of British Architects; RIBA), а в Німеччині — відповідно до правил Протоколу про порядок розрахунку і виплати винагород архітекторам і інженерам (Honorarordnung für Architekten und Ingeneuere; HOAI). Етапи життєвого циклу, обумовлені стандартними вимогами щодо обміну, можуть бути адаптовані відповідно до особливостей місцевої практики впровадженням місцевих вимог. Тобто, ДСТУ EN ISO 29481-1:2022 21 замість наведеної в стандарті таблиці можна застосувати встановлену за місцевими правилами. Вимоги щодо обміну можуть бути визначені відповідно до цих місцевих правил. У разі застосування місцевих правил до визначення етапів потрібно забезпечити, щоб вони відповідали етапам, встановленим у цьому стандарті. Або як альтернативні варіанти: — один стандартний етап розділяють на кілька підетапів, що відповідають місцевим правилам; чи — кілька стандартних етапів об’єднують в один етап, що відповідає місцевим правилам. Потрібно забезпечити, щоб співвідношення між стандартними етапами та етапами, встановленими за місцевими правилами, було дотримано як «один до одного», «один до множини» чи «множина до одного». Потрібно, щоб межі етапів життєвого циклу не перетиналися: щоб початок чи закінчення встановленого за місцевими правилами етапу не перекривали собою частину іншого, стандартного, етапу. ДСТУ EN ISO 29481-1:2022 22 ДОДАТОК D (довідковий) ВИКОРИСТАННЯ В IDM МЕТОДІВ BPMN D.1 Загальна інформація Для розроблення карт процесів в IDM рекомендовано використовувати (але не обов’язково) наведені нижче 22 символьні познаки нотації моделювання бізнес-процесів (business process modelling notation; BPMN) (рисунок D.1). У таблиці D.1 наведено перелік визначень символів BPMN, рекомендованих згідно зі специфікацією BPMN Робочої групи з управління об’єктами (object management group; OMG). Початок Поміжна подія Кінець (Передавання) (Отримання) Міжсторінкові з’єднувачі (Передавання) (Отримання) За замовчуванням/ виключний Включний Паралельний Події повідомлення Шлюзи Дія (Згорнутий) (Розгорнутий) Група Робоча група та її доріжка Підпроцеси Рисунок D.1 — Символьні познаки BPMN, рекомендовані для моделювання карт процесів Потік послідовних операцій Потік повідомлень Асоціативний зв’язок Направлений асоціативний зв’язок Об’єкт даних Текстова примітка Примітка. Джерело: Lee, G., et al. (2013). «Extended Process to Product Modeling (xPPM) for integrated seamless IDM and MVD development». Advanced Engineering Informatics 27(4): 636-651. Рисунок D.1 — аркуш 2 НАЦІОНАЛЬНЕ ПОЯСНЕННЯ Лі Г. та ін. (2013) Розширений процес моделювання продукту (xPPM) для інтегрованого безперервного розроблення IDM та MVD. Передова інженерна інформатика 27(4): 636-651. ДСТУ EN ISO 29481-1:2022 23 Таблиця D.1 — Визначення рекомендованих символьних познак BPMN Елемент Визначення Дія (Завдання) Завдання — це охоплена процесом неподільна дія. Завданням називають виконувану під час процесу роботу, яку не може бути розкладено до дрібнішого рівня деталізації процесу Підпроцес Підпроцес — це складна діяльність, охоплена процесом чи програмою. Його структуру створено так, що за допомогою допоміжних заходів його може бути піддано дрібнішій деталізації (як процесу чи програми) Підпроцес (Розгорнутий) Підпроцес розгорнуто так, що видно охоплені його межами деталі (процесу). Потрібно уважно стежити за тим, щоб потоки послідовностей не перетинали межі підпроцесу Підпроцес (Згорнутий) Деталей підпроцесу на діаграмі не видно. Знак «плюс» в центрі нижньої частини контуру означає, що діяльність є підпроцесом і для неї визначено нижчий рівень деталізації Початок Початкова подія, яка означає початок процесу. Запуск початкових подій можливий тільки внаслідок спрацювання на тригер Проміжна подія Проміжна подія відбувається у певному місці між початком і кінцем процесу. Проміжні події можуть спрацьовувати на тригер або самі утворювати тригери Кінець Кінцева подія означає завершення процесу. Кінцеві події можуть бути пов’язані лише з передаванням результатів виконаної роботи Початкова подія (Повідомлення) Повідомлення, яке надходить від учасника і означає початок процесу. Фактичного учасника, від якого отримано повідомлення, можна ідентифікувати, пов’язавши подію з учасником за допомогою потоку повідомлень під час співпраці з визначення меж процесу Проміжна подія (Отримання повідомлення) Проміжна подія, пов’язана з повідомленням, може бути застосована для відправлення або отримання повідомлення. У разі використання познаки для «отримання повідомлення» маркер події має бути незаповненим. Це призводить до продовження процесу, якщо повідомлення є очікуваним, або змінення напрямку потоку для оброблення виключних умов Проміжна подія (Передавання повідомлення) Проміжна подія, що може бути застосована для відправлення або отримання повідомлення. У разі використання познаки для «передавання повідомлення» маркер події має бути заповненим (див. на наведеному вище рисунку ліворуч). Це призводить до продовження процесу, якщо повідомлення є очікуваним, або змінення напрямку потоку для оброблення виключних умов Кінцева подія (Повідомлення) Цей тип кінцевої події означає, що повідомлення надсилають учаснику наприкінці процесу. Докладніше про повідомлення див. на с. 91 (джерела, зазначеного в примітці до рисунка D.1) Проміжна подія (Зв’язок/отримання) Парні події зв’язку також можна використовувати як «міжсторінкові з’єднувачі» для представлення процесу на кількох сторінках. Їх також можна використовувати як загальні об’єкти «переходу» (go to) на рівні процесу. За цільовим посиланням може бути тільки одна подія. У разі використання познаки для «отримання» за вихідним посиланням маркер події має бути незаповненим. У разі використання для «передавання» за цільовим посиланням, маркер події має бути заповнений Проміжна подія (Зв’язок/передавання) Шлюз Шлюз використовують для керування розбіжністю та збіжністю потоків послідовностей в процесі та в програмі. Відтак він буде визначати розгалуження, роздвоєння, злиття та об’єднання маршрутів передачі даних. Внутрішні маркери означатимуть тип керування режимом роботи Шлюз (Виключний) [XOR], у разі розділення перенаправляє потік послідовностей виключно до одної з вихідних гілок. У разі об’єднання він перебуває в режимі очікування на завершення потоку по одній вхідній гілці перед запуском вихідного потоку ДСТУ EN ISO 29481-1:2022 24 Елемент Визначення Шлюз (Паралельний) [And], у разі використання для розділення потоку послідовностей всі вихідні гілки активуються одночасно. У разі об’єднання паралельних гілок він перебуває в режимі очікування на завершення потоків по всіх вхідних гілках перед запуском вихідного потоку Шлюз (Включний) [Or], у разі розділення активує одну або кілька гілок. Усі потоки, що надходять по активних гілках, мають бути завершені до об’єднання Потік послідовностей (Звичайний або неконтрольований) Потік послідовностей використовують, щоб показати порядок виконання дій у процесі та програмі Потік повідомлень Познаку використовують, щоб показати потік повідомлень між двома учасниками, готовими їх відправляти та отримувати. Потік повідомлень має з’єднувати дві окремі динамічні області. Їх поєднують або з межею динамічної області, або з об’єктами потоку в межах динамічної області. Вони не повинні з’єднувати два об’єкти в межах тої самої динамічної області Асоціювання Асоціювання застосовують, щоб встановити відношення зв’язку між інформацією й артефактами з об’єктами потоку. Текстові та графічні непотокові об’єкти можуть бути пов’язані з потоковими об’єктами та потоками Асоціювання даних Асоціювання даних застосовують для переміщення даних між об’єктами даних та їхніми властивостями, а також між вхідними та вихідними даними дій та процесів. Асоціювання даних може бути візуально представлено на діаграмі за допомогою з’єднувальної лінії, що означає відношення зв’язку Динамічна область Динамічна область — це графічне представлення спільної діяльності учасників. Динамічна область призначена для вміщення потоків послідовних дій, що формують окремий процес. Потоки послідовностей можуть перетинати межі, якими розділено доріжки динамічної області, але не можуть виходити за межі самої динамічної області. Тобто процес має бути повністю уміщено в динамічній області. Взаємодія між динамічними областями відображається через потоки повідомлень Доріжка Доріжка — це підрозділ процесу (часто в межах динамічної області), який простягається (по вертикалі або горизонталі) по всій довжині процесу. Доріжки часто використовують для представлення ролей в організації (наприклад, менеджер, співробітник), систем (наприклад, корпоративне програмне забезпечення), відділів організації (наприклад, відділ доставки, фінансовий відділ) тощо Об’єкт даних Об’єкти даних призначені для надання інформації про те, яку діяльність потрібно виконати та/або що має бути вироблено. Елементи об’єкта даних мають бути вміщені в елементах процесу або підпроцесу. Об’єкти даних не призначені для визначення станів Група Група — це не діяльність або будь-який об’єкт потоку, і тому її не може бути з’єднано із потоками послідовностей або потоками повідомлень. Крім того, групи не обумовлені межами динамічних областей і доріжок Текстова примітка Текстові анотації — це інструмент, за допомогою якого розробник моделі може надати додаткову інформацію читачеві діаграми BPMN. Об’єкт текстової анотації може бути пов’язано із конкретним об’єктом на діаграмі за допомогою асоціювання, але він не впливає на потік процесу У наступних розділах цього стандарту викладено комплекси загальних принципів та правил згідно із зазначеною нижче специфікацією BPMN OMG. Приклади та детальні пояснення можна отримати з таких джерел: — Business Process Modelling Notation (BPMN), OMG, 2013, доступно за адресою: — Silver, B., BPMN Method and Style: A levels-based methodology for BPM process modelling and improvement using BPMN 2.0, 2011, Cody-Cassidy Press. Кінець таблиці D.1 ДСТУ EN ISO 29481-1:2022 25 НАЦІОНАЛЬНЕ ПОЯСНЕННЯ — Нотація моделювання бізнес-процесів (BPMN), OMG, 2013 — Сільвер Б. Метод та стиль BPMN: Методологія моделювання процесів BPM на основі рівнів та вдосконалення за допомогою BPMN 2.0, 2011, Cody-Cassidy Press. D.2 Специфікація процесів і потоків У карти процесів має бути вміщено всі створені для опису процесів діаграми та схеми підпроцесів. Потрібно, щоб усі процеси мали унікальний ідентифікатор та назву (ім’я). Кожний процес на карті описують якомога детальніше. Мета полягає в тому, щоб читачеві з опису була зрозуміла призначеність процесу. Нижче наведено зазначені в специфікації BPMN правила, пов’язані з потоками та подіями процесів. Потік процесу — Рекомендовано для представлення потоків послідовностей обирати напрямок зліва направо або зверху вниз, а потоки повідомлень спрямовувати під кутом 90° до потоків послідовностей. — Потік процесу вміщують у динамічній області так, щоб він не виходив за її межі. — Взаємодію між динамічними областями відображають через потоки повідомлень. — Якщо в межах діаграми розгорнуто підпорядкований процес, то об’єкти всередині підпроцесу не можна пов’язувати з об’єктами за його межами. З’єднання потоків послідовностей — З’єднувальний об’єкт, який показує порядок виконуваних дій у процесі, представляють суцільною графічною лінією. — Кожний потік має лише одне джерело й одну ціль. — Потік послідовностей може перетинати межі між доріжками динамічної області, але не може виходити за її межі. — Джерелом і ціллю можуть бути лише дії, шлюзи та події. Але не можна, щоб ціллю чи джерелом потоку послідовностей був артефакт. З’єднання потоку повідомлень — За допомогою потоку повідомлень поєднують дві окремі динамічні області. Повідомлення приєднують або до межі динамічної області, або до потокових об’єктів у її межах. — За допомогою повідомлення не можна з’єднувати два об’єкти в тій самій динамічній області. — Потоки повідомлень не можна приєднувати до об’єктів, що знаходяться в одній і тій самій динамічній області. — Взаємодію між динамічними областями відображають через потоки повідомлень. — Джерелом або ціллю потоку повідомлень можуть бути лише динамічні області/учасники, дії та події. Але не можна, щоб ціллю або джерелом потоку повідомлень був артефакт. Асоціювання та асоціювання даних — Текстові та графічні непотокові об’єкти можуть бути асоційовані з потоковими об’єктами та потоками. — Асоціювання застосовують для встановлення визначених користувачем відношень зв’язку між текстом (анотацією) та потоковим об’єктом. — Для асоціювання даних використовують таку саму нотацію, як і для прямого асоціювання. — Асоціювання даних застосовують для переміщення даних між об’єктами даних, їхніми власти- востями, а також вхідними й вихідними даними дій та процесів. — Об’єкти даних можуть бути пов’язані безпосередньо зі з’єднувачем потоку послідовностей. — За допомогою дій визначають дві групи асоціацій даних, тоді як за допомогою подій — лише одну. D.3 Специфікація подій Подія вказує на стан діяльності. Вирізняють три основні види подій: початкові, проміжні та кінцеві події. Початкові та кінцеві події — Створення процесу розпочинається за умов, коли відбувається одна з його тригерних подій. — Для того щоб створений процес було завершено, всі маркери в цьому екземплярі процесу мають досягти кінцевого вузла, тобто вузлового сегмента, що не має вихідних потоків послідовностей. Якщо маркер досягає обмежувальної події завершення, весь процес завершується аномально. — Застосовувані початкові та кінцеві подій є незалежними для кожного рівня діаграми. — Якщо є початкова подія, то має бути щонайменше одна кінцева подія. А якщо є кінцева подія, то має бути щонайменше одна початкова подія. — Якщо початкову подію не застосовують, то потрібно, щоб неявна початкова подія не утворювала ДСТУ EN ISO 29481-1:2022 26 тригер для цього процесу. — Якщо процес складний та/або початкові умови не є очевидними, рекомендовано застосовувати початкову подію. — Якщо кінцеву подію не застосовують, то потрібно, щоб неявна кінцева подія не утворювала результат для цього процесу. — Потрібно, щоб процес не було завершено, доки не завершаться потоки по всіх паралельних маршрутах. D.4 Специфікація об’єктів даних Об’єкт даних — це іменована сукупність даних. Це може бути набір даних, доступний із зовнішнього джерела (наприклад, бібліотечні дані), або дані, експортовані з певної операції, щоб забезпечити виконання інших операцій (наприклад, вимога щодо обміну). Потрібно, щоб об’єкти даних, до яких не застосовують вимоги щодо обміну, мали ім’я, в якому вказано на їхню призначеність, та опис, у якому викладено їхню призначеність та вміст. Нижче наведено пов’язані з об’єктами даних правила, які зазначено в специфікації BPMN. Об’єкти даних — Елементи об’єкта даних вміщують в елементах процесу або підпроцесу. — Асоціації даних завжди вміщують в іншому елементі, за яким визначають, коли має бути виконано асоціювання цих даних. — Потрібно, щоб об’єкт даних не був ні джерелом, ні ціллю потоків послідовностей та потоків повідомлень. — Об’єкти даних можуть бути безпосередньо асоційовані зі з’єднувачем потоку послідовностей. D.5 Специфікація вимог щодо обміну в карті процесу У моделях BPMN вимогу щодо обміну представляють у карті процесу за допомогою об’єкта даних. Потрібно, щоб вимоги щодо обміну мали: — ім’я, в якому вказано їхню призначеність відповідно до правил іменування IDM, та — опис як окремий документ, в якому зазначено ціль та зміст вимоги щодо обміну. БІБЛІОГРАФІЯ 1 ISO 29481-2 Building information models — Information delivery manual — Part 2: Interaction framework. НАЦІОНАЛЬНЕ ПОЯСНЕННЯ 1 ISO 29481-2 Інформаційні моделі будівель. Настанова з доставляння інформації. Частина 2. Структура взаємодії. Код згідно з НК 004: 91.010.01 Ключові слова: будівельне інформаційне моделювання, будівельний об’єкт, будівлі та споруди, доставляння інформації, життєвий цикл, настанова, обмін інформацією, управління інформацією, формат. ------------------------------------------------------------- Документ безкоштовно доступний для ознайомлення в форматі TXT без графіки і без таблиць. Повний текст документу див. в нормативній базі "Зодчий" https://cct.com.ua/zodch.htm -------------------------------------------------------------