Специфікація інформаційної доставки

Що таке специфікація інформаційної поставки?

Специфікація інформаційної поставки (IDS) — це відкритий, машиночитаний стандарт, опублікований buildingSMART, який виражає вимоги до BIM-інформації у вигляді правил, що підлягають перевірці. Якщо План виконання BIM викладає вимоги у вигляді тексту («стіни повинні містити значення U та категорію вогнестійкості»), то IDS перетворює цю вимогу на правило, яке перевіряльник може виконати автоматично: відкрити модель IFC, перевірити кожну стіну та повідомити про результат — пройдено чи не пройдено. Саме цей перехід від тексту до машиновиконуваного коду є визначальною перевагою IDS.

Стандарт підтримується buildingSMART і публікується як публічна специфікація. Він працює в екосистемі openBIM, оперуючи файлами IFC, які є незалежними від постачальника програмного забезпечення та вільно поширюються. IDS усуває людський фактор із перевірки відповідності: або модель відповідає специфікації, або ні, і це перевіряється програмним забезпеченням без необхідності тлумачення.

Чим IDS відрізняється від Плану виконання BIM?

Обидва документи фіксують інформаційні вимоги, але на різних рівнях. BEP — це письмова угода, зазвичай обсягом 5–50 сторінок, де команда та замовник узгоджують, яка інформація потрібна, хто її створює та до якого терміну. Відповідність є предметом обговорення: член команди каже «ми надали теплотехнічні властивості», отримувач перевіряє та або погоджується, або заперечує. Спір вирішується електронним листом або на зустрічі.

IDS бере ту саму вимогу («потрібні теплотехнічні властивості») і кодує її як правило: «для кожного об'єкта стіни має існувати властивість з назвою U-value, а її значення має бути числом від 0,1 до 2,0». Машина застосовує це правило до моделі та звітує: п'ять стін пройшли, дві стіни не пройшли (відсутнє значення U), три стіни не пройшли (значення поза діапазоном). Немає місця для суперечок; дані або є, або їх немає.

На практиці IDS доповнює BEP, а не замінює його. BEP залишається контрактом і звідом правил проекту. IDS — це інструмент, який автоматизує одну частину контролю виконання BEP: частини, що стосуються повноти інформації та угод про найменування.

Яку структуру визначає специфікація IDS?

Кожне правило IDS має дві частини: застосовність та вимоги. Застосовність відповідає на питання «до яких об'єктів застосовується це правило?». Вимоги відповідають на питання «що має бути правдою для цих об'єктів?».

Застосовність фільтрує за типом об'єкта IFC, класифікацією або властивістю. Наприклад: «застосувати до всіх елементів, класифікованих як теплова ізоляція» або «застосувати до всіх стін на поверсі номер 2». Вимоги потім визначають, яка інформація має супроводжувати ці об'єкти: мінімальні та максімальні значення, обов'язкові властивості, дозволені матеріали або зв'язки з іншими елементами. Правило може говорити: «будь-який елемент ізоляції повинен мати властивість Товщина (числове, міліметри, мінімум 50)», що перевіряється за визначеннями властивостей зі Словника даних buildingSMART, щоб найменування співпадало в моделях з різних інструментів.

Чому IDS працює лише тоді, коли найменування дійсно збігаються?

Ось жорстке обмеження: правила IDS посилаються на назви властивостей та класифікації. Якщо ваша архітектурна модель називає теплову властивість «U_Val», а правило шукає «U-value», перевіряльник нічого не бачить, позначає це як невдачу, і жодне людське судження не може це скасувати. Властивість існує, але під іншою назвою, тому правило технічно правильне: необхідна властивість відсутня.

Ось чому IDS та Словник даних buildingSMART (bsdd) повинні працювати разом. bsdd — це реєстр визначень властивостей, згрупованих за доменами, кожне зі стандартизованою назвою. Коли правило IDS говорить «властивість U-value (з коду bsdd PSet_WallCommon.U-value)», це означає: вона повинна існувати, під цією точною назвою, з цим точним визначенням. Програмне забезпечення кожного консультанта потім має експортувати в IFC, використовуючи назви властивостей bsdd, інакше перевірка не вдасться.

Для індивідуальної практики, яка координує зовнішніх консультантів, забезпечення цього вимагає включення посилання на bsdd у BEP та прохання до консультантів підтвердити, що їхнє програмне забезпечення може експортувати з його використанням. Багато інструментів зараз це підтримують; деякі все ще ні. Ось чому впровадження IDS у словацькій практиці все ще на ранній стадії: екосистема повинна узгодити найменування, перш ніж перевірки IDS стануть надійними.

Де IDS знаходиться в робочому процесі?

Набір правил IDS зазвичай узгоджується із замовником на початку, разом із BEP. Він знаходиться в Спільному середовищі даних як контрольна точка якості проекту. Кожного разу, коли консультант випускає оновлення моделі (щотижня, раз на два тижні або на контрольних етапах), модель надсилається до CDE, і перевіряльник (програмне забезпечення або людина, яка використовує програмне забезпечення) запускає правила IDS. Результати надсилаються команді: «модель MEP проходить усі правила» або «архітектурна модель не проходить: 12 стін без значення U».

Потім результати надходять у процес координації: виявляються колізії, збої IDS реєструються як проблеми в інструменті координації, призначаються відповідальній стороні та вирішуються до наступного випуску. BIM-координація стає більш структурованою, оскільки якість інформації перевіряється, а не передбачається. Команди виявляють неповні або неправильно названі дані на ранніх етапах, а не під час передачі.

Які практичні обмеження впровадження IDS сьогодні?

IDS — чудова ідея, але в словацькій практиці житлового будівництва впровадження все ще на ранній стадії. Кілька причин:

• Підтримка інструментів різна. Не кожна BIM-платформа експортує IDS, і не кожен перевіряльник надійно його читає. Підтримка покращується, але багато невеликих практик все ще використовують старіші версії програмного забезпечення без можливості IDS.
• Узгодження bsdd неповне. Багато європейських бібліотек властивостей все ще мігрують до визначень buildingSMART. Поки це не буде узгоджено, забезпечення дотримання найменувань через IDS є складним.
• Потрібна згода консультантів. Інженер-конструктор, який працює над кількома проектами, не може прийняти IDS для одного клієнта та ігнорувати його для іншого. Спочатку має відбутися широке впровадження стандарту в галузі.
• IDS не може оцінювати дизайн. Стіна може пройти всі правила IDS і все одно не досягти цільового показника теплопередачі, або повітропровід може бути правильно названий, але недостатнього розміру. IDS перевіряє наявність та формат даних, а не їхню правильність чи продуктивність.

Для індивідуальних практик прагматичний підхід полягає в тому, щоб почати з невеликих, високоцінних правил (наприклад, «кожна стіна повинна мати тип і товщину») і розширювати їх лише тоді, коли ваші консультанти продемонструють підтримку як стандарту, так і найменувань bsdd. BEP залишається основним інструментом; IDS — це зростаючий супутник, який автоматизує частину контролю якості в міру дозрівання екосистеми.