Введение
Цифровизация инвестиционно-строительной деятельности в Российской Федерации сопровождается планомерным нормативным закреплением требований к формированию, ведению и экспертизе информационной модели объекта капитального строительства (ОКС). Постановление Правительства РФ от 05.03.2021 № 331 установило случаи, при которых застройщик и технический заказчик обязаны обеспечивать формирование информационной модели, а Постановление № 614 от 17.05.2024 утвердило правила ее ведения и строгие требования к форматам электронных документов [1, 2]. В этих условиях особую роль приобретают информационные требования заказчика (Exchange Information Requirements, EIR), поскольку именно они определяют состав, структуру, сроки и, что наиболее важно, уровень качества предоставляемых данных.
Однако на практике в строительных проектах, особенно в сегменте массового жилищного строительства, сохраняется системный разрыв между EIR как текстовым документом приложения к договору и EIR как проверяемым критерием приемки. Этот разрыв проявляется в не структурированности требований, неоднозначных трактовках атрибутов, использовании различных классификаторов участниками процесса и отсутствии формализованного сценария проверки в контуре среды общих данных (СОД) [3, 4]. Перевод требований EIR из текстового вида в формализованные, проверяемые правила и включение этой проверки в процессные шлюзы СОД позволяет повысить воспроизводимость приемки, снизить число возвратов комплектов материалов на доработку и улучшить управляемость качеством данных на стадии проектирования и строительства [5].
Целью данного исследования является разработка методики формализации и валидации требований к информации (EIR) в СОД для жилищных проектов РФ, включающей классификацию проверяемых требований, спецификацию правил валидации с применением формально-логического аппарата, процессный сценарий их применения в СОД и критерии оценки эффективности.
Переход строительной отрасли к технологиям информационного моделирования (ТИМ/BIM) обусловил смену парадигмы: от управления статичными документами отрасль перешла к управлению структурированными данными на протяжении всего жизненного цикла ОКС [6]. В центре этого процесса находится информация, качество и полнота которой определяют эффективность принимаемых решений. Ключевым инструментом решения проблемы хаотичного обмена данными стала международная серия стандартов ISO 19650. В частности, ISO 19650-1:2018 определяет понятия и принципы информационного менеджмента, а ISO 19650-2:2018 устанавливает требования к управлению информацией на стадии создания актива [7, 8].
В логике международной серии стандартов ISO 19650 процесс управления информацией базируется на строгой иерархии требований. Фундаментом выступают организационные информационные требования (OIR), определяющие стратегические цели заказчика. На их основе формируются требования к информации об активе (AIR) для стадии эксплуатации и требования к информации проекта (PIR) для стадии реализации. Завершающим звеном, транслирующим эти стратегии в конкретные контрактные обязательства, являются информационные требования заказчика (EIR). Таким образом, валидируемые параметры не являются произвольными, а представляют собой результат декомпозиции AIR и PIR, что обеспечивает сквозную трассируемость от бизнес-цели до конкретного атрибута в модели. При этом важным методическим уточнением требует понятие «уровня детализации» в составе EIR. В рамках данной методики под ним понимается не только геометрическая сложность (LOD), но и Уровень информационной потребности (Level of Information Need, LOIN) в терминологии ISO 19650-1. LOIN определяет минимально достаточный объем информации (геометрия, данные, документы), необходимый для конкретного шлюза СОД. Это позволяет избежать ситуации, когда от исполнителя требуют заполнения всех атрибутов на стадии, когда часть данных еще не может быть определена по технологическим причинам.. В российской практике подходы к управлению информацией развиваются в рамках национальной системы стандартов, в том числе ГОСТ Р 10.00.00.00-2023, который гармонизирован с международными подходами, но адаптирован к российской системе технического регулирования [9].
Проблема валидации BIM-моделей активно исследуется в зарубежной литературе. Исследователи проводят параллели между валидацией BIM и практиками тестирования в программной инженерии, выделяя модульное, интеграционное и системное тестирование [10]. Ключевым событием в области стандартизации стала разработка формата Information Delivery Specification (IDS) под эгидой buildingSMART International [11]. IDS представляет собой открытый формат для описания требований к информационному наполнению моделей в машиночитаемом виде, позволяя формализовать EIR для автоматической проверки различными программными средствами [12].
В то же время, как отмечается в работах Pauwels et al. (2024), современные инструменты имеют ограничения и не покрывают весь спектр требований EIR, особенно в части логических зависимостей и процессных проверок [13]. В российском контексте ситуация осложняется активным процессом импортозамещения программного обеспечения, необходимостью учета национальных классификаторов (КСИ, ОКС) и отсутствием единой методологии формализации EIR, встроенной непосредственно в процессные шлюзы СОД [14, 15]. Данная работа направлена на заполнение этого пробела путем разработки процессно-ориентированной методики, не привязанной жестко к конкретному программному обеспечению.
Материалы и методы
Методологическую основу исследования составили принципы управления информацией по ISO 19650, концепция машиночитаемых спецификаций IDS и нормативная база РФ (ПП РФ № 331, ПП РФ № 614, ГОСТ Р 10.00.00.00-2023, СП 333.1325800.2020). СОД рассматривается не просто как хранилище файлов, а как управляемый процесс, в котором информационные контейнеры последовательно проходят зоны: рабочих данных (Work in Progress, WIP), общих данных (Shared), опубликованных данных (Published) и архива (Archive).
Требование EIR считается пригодным для формальной проверки, если оно удовлетворяет следующим критериям: однозначность (допускает единое толкование), наблюдаемость (существует объект проверки), измеримость (можно задать критерий «выполнено/не выполнено»), ссылочность (опирается на контролируемый набор значений) и трассируемость (можно связать требование с пунктом EIR и артефактом приемки).
На основе анализа практики была разработана классификация требований EIR, наиболее естественно переводимых в проверяемые правила (таблица 1).
Таблица 1
Классификация требований EIR, пригодных для формальной проверки
|
Класс требования |
Что проверяется |
Тип критерия |
Основа для проверки |
|
Полнота данных |
Наличие обязательных атрибутов |
Принято / |
Матрица обязательных атрибутов EIR |
|
Соответствие справочнику |
Принадлежность значения перечню |
Принято / |
Справочники значений / коды КСИ |
|
Диапазоны и единицы |
Числовые параметры и единицы |
Порог / интервал |
Пороговые значения, единицы измерения |
|
Логические зависимости |
Условная обязательность параметров |
Логическое «Если – То» |
Формализованные правила условий |
|
Уникальность |
Дублирование, уникальность ID |
Принято / |
Модель, правила генерации ID |
|
Комплектность выдачи |
Наличие документов и структуры |
Принято / |
Перечень документов + форматы данных |
|
Соблюдение процесса СОД |
Статусы, версии, контрольные точки |
Принято / |
Регламент СОД + точки контроля |
Для формального описания правил валидации в методике предлагается использовать аппарат математической логики. Правило валидации RR для множества объектов проверки Eobj может быть выражено следующей формулой:
∀e∈Eobj:(Pattr(e)∈Vdict) ∧ (Prange(e)∈[min,max])→Status(e)="Valid" (1)
где:
e – отдельный элемент информационной модели или информационный контейнер;
Pattr(e) – значение проверяемого атрибута элемента e;
Vdict – множество допустимых значений, определенное в справочнике заказчика;
Prange(e) – числовое значение параметра элемента e;
[min,max] – допустимый интервал значений параметра;
Status(e) – результирующий статус валидации элемента.
Ключевым методическим инструментом разработана «карточка правила валидации». Она содержит: код правила, связанный код требования EIR, объект проверки, формализованный критерий «выполнено/не выполнено», критичность несоответствия (критическое, существенное, несущественное), ответственную роль и способ проверки.
Основным результатом работы стала разработка референс-архитектуры функции валидации EIR в СОД, не привязанной к конкретному программному обеспечению. Архитектура базируется на цепочке артефактов: «требование → правило → прогон проверки → отчет → задача → приемка».
Для подтверждения применимости методики была проведена апробация на примере типового многоквартирного жилого дома (секционный, с повторяющимися этажами). Областью апробации выбраны ограждающие конструкции (наружные стены, окна, фасадные элементы), характеризующиеся высокой повторяемостью элементов и регулярными обновлениями проектной документации.
В таблице 2 представлен фрагмент матрицы трассируемости, демонстрирующей связь между исходным требованием, формализованным правилом и управленческим действием в СОД.
Таблица 2
Фрагмент матрицы трассируемости «требование → правило → действие»
|
Код требования (EIR) |
Код правила валидации |
Объект проверки |
Критерий проверки |
Управленческое действие при нарушении |
|
ТР-ОГК-003. Указание основного материала наружной стены |
ПР-ОГК-003 |
Элементы модели «Наружная стена» |
Атрибут «Основной материал» заполнен значением из утвержденного справочника |
Задача архитектору (АР): заполнить атрибут по справочнику. Блокировка приемки до устранения. |
|
ТР-ОГК-005. Толщина конструктивного слоя наружной стены |
ПР-ОГК-005 |
Элементы модели «Наружная стена» |
Значение толщины задано в мм и находится в диапазоне 80–400 мм (для ЖБ: 120–600 мм) |
Задача конструктору (КР): скорректировать геометрические параметры или тип конструкции. |
|
ТР-ОБЩ-004. Наличие отчета о валидации в комплекте |
ПР-ОБЩ-001 |
Информационный контейнер «Комплект материалов» |
В составе комплекта присутствует файл отчета о валидации актуальной версии |
Задача координатору по ТИМ: приложить отчет. Комплект не допускается к проверке. |
Ключевым вектором развития автоматизированной валидации является использование машиночитаемых форматов, таких как Information Delivery Specification (IDS). Предлагаемая методика выступает концептуальным мостом между текстовым EIR и форматами машинной проверки. Рассмотрим преобразование требования ТР-ОГК-005 (из Таблицы 2) в логику IDS на основе разработанной карточки правила ПР-ОГК-005:
- Applicability (Применимость): Определяется объект проверки. В терминах IDS это класс IFC: IfcWall (Наружная стена).
- Requirements (Требования): Формализуется критерий из карточки правила. Facet (Атрибут/Свойство): Pset_WallCommon.Thickness; Data Type: Decimal; Bounds (Диапазон): MinValue = 80, MaxValue = 400 (для ЖБ: 120-600); Unit: mm. Такое структурирование позволяет в будущем экспортировать реестр карточек правил из СОД напрямую в XML-схему IDS для автоматического прогона в специализированных валидаторах без участия человека.
Процессный сценарий применения методики включает две критические контрольные точки (шлюза): допуск комплекта материалов к проверке (контроль статусов и комплектности) и допуск к приемке (отсутствие критических несоответствий). При выявлении нарушений формируется реестр несоответствий, на основании которого в СОД создаются задачи для исполнителей. Цикл замыкается повторной проверкой обновленной версии контейнера (таблица 3).
Таблица 3
Логика процессного сценария применения валидации в СОД
|
Группа шагов |
Событие перехода |
Артефакт-основание |
|
Подготовка |
Комплект сформирован и допущен к проверке |
Отметка допуска к проверке в СОД |
|
Проверка |
Запущен прогон по версии набора правил |
Запись о прогоне валидации |
|
Результат |
Сформирован отчет и реестр несоответствий |
Отчет о валидации + реестр |
|
Исправление |
Назначены задачи, загружена новая версия |
Задачи + новые версии контейнеров |
|
Повторная проверка |
Проверяющий подтвердил устранение замечаний |
Обновленный отчет/реестр |
|
Приемка |
Комплект допущен к приемке, критических нарушений нет |
Запись о приемке в СОД |
Внедрение предложенной методики позволяет перейти от субъективной визуальной проверки к объективному контролю. Для демонстрации эффективности рассмотрим контрольный пример на базе апробации типового жилого дома (проверка 186 элементов ограждающих конструкций по 12 правилам валидации). Базовый сценарий (традиционный подход): Визуальный контроль и ручная выгрузка параметров. Время на подготовку и проверку одного комплекта составляет в среднем 6–8 часов. Из-за субъективности замечаний количество итераций (возвратов) на доработку до стадии приемки достигает 3–4 раз. Суммарные трудозатраты на цикл приемки: ~25 часов. Предложенный сценарий (с применением методики):
- Подготовка: настройка справочников и карточек правил (выполняется один раз на проект) – 2 часа.
- Прогон: автоматизированная/полуавтоматизированная проверка в шлюзе СОД – 15 минут.
- Устранение: благодаря матрице трассируемости и четкому указанию критичности, исполнители получают адресные задачи. Количество итераций сокращается до 1–2 раз. Результат: Суммарные трудозатраты на цикл приемки снижаются до ~5 часов (сокращение на 80%). Количество возвратов комплектов материалов снижается в 2-3 раза за счет раннего шлюза контроля комплектности и статусов (ПР-ОБЩ-001, ПР-ОБЩ-002).
Ограничением текущей апробации является то, что методика реализована на уровне организационно-процессного моделирования без разработки программного модуля. Для полноценной автоматизации необходимы предварительные условия: согласованный между участниками словарь атрибутов, версионируемые справочники допустимых значений и единые правила генерации идентификаторов объектов.
Методика допускает поэтапное внедрение в зависимости от зрелости организации:
Сценарий 1: Регламент и документы. Проверка выполняется по чек-листу, отчет и реестр формируются как документы, задачи ведутся в реестре.
Сценарий 2: Частичная автоматизация. Автоматизируются проверки комплектности, полноты, диапазонов и запрета значений-заглушек; сложные логические зависимости проверяются вручную.
Сценарий 3: Расширенная автоматизация. Автоматизируется большинство правил, задачи и статусы связаны с реестром, ведется аудит и метрики качества данных.
Заключение
В ходе исследования достигнута поставленная цель: разработана методика формализации и валидации требований к информации (EIR) в среде общих данных для жилищных проектов РФ. Научная новизна заключается в предложенной классификации проверяемых требований, структуре карточки правила как минимально достаточной спецификации проверяемого требования, механизме трассируемости от требования к результатам проверки и процессном сценарии с контрольными точками допуска.
Практическая значимость работы состоит в возможности применения методики участниками проекта: заказчиками для повышения доказательности требований и воспроизводимости приемки, проектировщиками для снижения неопределенности требований и уменьшения возвратов выпусков, операторами СОД для внедрения типового процесса контроля качества данных. Разработанный комплект шаблонов и регламентов формирует надежную основу для последующей программной автоматизации проверок в отечественных и импортонезависимых платформах СОД.
Разработанная методика обладает высоким потенциалом масштабирования за пределы стадии проектирования на весь жизненный цикл объекта капитального строительства (ОКС). На стадии строительства фокус валидации смещается на проверку исполнительных моделей (As-built): карточки правил адаптируются для контроля фактических геометрических отклонений и подтверждения заменяемых материалов. На стадии эксплуатации информационные требования заказчика (EIR) трансформируются в требования к модели актива (AIM) на основе AIR. Предложенный механизм трассируемости и версионирования наборов правил позволяет адаптировать функцию валидации для проверки готовности цифровой модели к передаче в эксплуатацию (например, автоматический контроль наличия паспортов оборудования, кодов для CAFM-систем). Таким образом, СОД с встроенным контуром валидации EIR становится единым инструментом управления качеством данных от концепции до сноса объекта.
