Введение
Ценность цифровой информационной модели не сводится к геометрии. Для расчётов, передачи данных между программами, формирования ведомостей и последующего машинного анализа не менее важны сведения, записанные в свойствах элементов. Оценивать качество ЦИМ приходится как минимум в двух плоскостях: корректно ли сформирована геометрия и достаточно ли полно описаны объекты информационно. В обзоре исследований по автоматизированной проверке ТИМ-моделей подчёркивается, что ошибки и неполнота данных модели прямо ограничивают надёжность дальнейших цифровых процедур [1].
Вне поля зрения атрибутивные ошибки на практике часто остаются до тех пор, пока модель служит только чертежом. Стоит обратиться к ней как к источнику данных, и обнаруживается, что у части объектов отсутствует обязательный параметр, одинаковые сведения заполнены по-разному или требуемое значение нельзя извлечь без разночтений. С.С. Федоров и С.Д. Казаков выделяют проверку наличия и заполненности атрибутов как отдельные операции анализа ЦИМ с последующим формированием отчёта [2]. Для Renga к этому добавляется задача корректного соответствия внутренних типов и параметров представлению IFC. Практический вариант такого сопоставления для архитектурной модели Renga рассмотрен Р.В. Осташевым и С.И. Евтушенко [3].
Переход к автоматической проверке меняет сам характер контроля. Специалист при ручном просмотре способен интерпретировать контекст. Программному модулю всё нужно объяснить заранее: какой объект проверять, какое свойство искать и какое значение считать допустимым. В классической работе C. Eastman и соавторов автоматизированный контроль рассматривается как последовательный процесс интерпретации правил и данных модели [4]. R. Amor и J. Dimyadi указывают, что качество исходной ЦИМ-информации остаётся одной из главных проблем автоматизированной проверки [5]. В более поздней работе Z. Ma и соавторов правила качества применяются прямо к IFC-модели на основе формализованного представления требований [6]. Отсюда практический вывод: до сложного нормоконтроля имеет смысл проверить информационную готовность модели, то есть наличие требуемых свойств, их заполненность, формат и допустимость значений.
В российской практике требования к атрибутам распределены между разными документами и не представлены в виде единой машинно-читаемой базы. ПНСТ 909-20241 задаёт требования к цифровым информационным моделям жилых зданий и связывает элементы модели с сущностями IFC. Кроме того, в нём показан принцип формирования информационного наполнения для различных сценариев применения ТИМ. Для настоящего исследования этот документ важен как пример структуры требований, а не как готовый перечень для любого типа объекта.
Для общественных зданий состав контролируемых сведений приходится формировать заново, с учётом назначения объекта. Помимо общих требований к общественным зданиям могут потребоваться нормы доступности, эвакуации, пожарной безопасности и специализированные требования для конкретной функции здания. Механическим переносом таблиц из ПНСТ 909-2024 задача не решается. Она состоит в преобразовании текстовых положений нормативных и проектных документов в проверяемые условия, привязанные к определённым объектам и свойствам модели. Подобная логика лежит в основе спецификации информационных требований (IDS), где информационные требования задаются в форме, пригодной для автоматической проверки IFC-модели [7–9].
Целью работы является разработка методики контроля заполнения атрибутивных данных ЦИМ и определение структуры программного инструмента автоматизации такого контроля в Renga. Речь идёт об инструменте, способном находить отсутствующие и некорректные параметры, объяснять причину несоответствия в отчёте и, когда это возможно без смыслового предположения, дозаполнять значение автоматически. Для этого требуется решить пять связанных задач: определить источники требований; задать единый формат описания правила; разделить типы атрибутивных ошибок; установить границы допустимого автозаполнения; описать последовательность работы модуля с объектами и свойствами Renga.
Материалы и методы
Исследование выполнено как методическая разработка. В основу положены работы по контролю качества цифровых информационных моделей и сопоставлению параметров при экспорте в IFC [1–3], исследования по автоматизированной проверке ТИМ-моделей на основе формализованных правил [4–6, 10, 11], публикации по спецификации информационных требований (IDS) и семантическому обогащению моделей [7–9, 12], а также материалы по КСИ, МССК. Возможность практической реализации оценивалась по официальной документации Renga API. Готовой базой полей нормативные документы при этом не считались: они рассматривались как первичный текст, из которого требуется выделить проверяемое требование.
Работа с каждым требованием выполняется последовательно. Сначала определяется содержательный смысл нормы или проектного требования и объект, к которому оно относится. Затем объект сопоставляется с классом информационной модели, выбирается свойство, задаются тип данных и допустимое значение, после чего формулируются условия применимости и способ контроля. На последнем этапе принимается решение о том, может ли программа только зафиксировать ошибку или имеет право получить недостающее значение из других данных модели. Для апробации методики выбраны четыре архитектурных класса: IfcSpace, IfcDoor, IfcStair и IfcRamp. Этот набор даёт возможность проверить подход на строковых, логических и числовых атрибутах, а также на требованиях, которые действуют не для всех объектов одного класса.
Чтобы свести результаты множества проверок к одному показателю, введён коэффициент соответствия атрибутивных данных Kattr. Он показывает, какая доля правил, действительно применимых к выбранному объекту или набору объектов, выполнена без ошибок. Показатель можно рассчитывать на уровне отдельного элемента, группы элементов, IFC-класса или модели в целом. Детальный отчёт коэффициент не заменяет; его назначение состоит в краткой оценке информационной готовности модели.
Kattr = Npass / Napp × 100 %
Npass — количество применимых требований, по которым проверка завершена со статусом «соответствует»;
Napp — общее количество требований, применимых к проверяемому объекту или набору объектов.
Сам по себе коэффициент не показывает характер найденных проблем. Например, одинаковое значение Kattr может быть получено как при нескольких пустых полях, так и при одном критическом несоответствии значения. Сводная оценка поэтому применима только вместе с перечнем конкретных ошибок. Здесь соблюдается общий принцип автоматизированной проверки, где отдельно выполняются подготовка данных, формализация правила, вычисление результата и его представление пользователю [4, 5, 10].
Результаты
В ходе работы была сформирована схема перевода требований к информационному наполнению в набор правил, которые можно выполнять программно. Анализ показал, что делить эту задачу удобнее по трём уровням принятия решения, чем по программным функциям.
На первом уровне определяются источник и назначение требования: откуда оно берётся и зачем конкретное свойство нужно в модели. На втором уровне выполняется формализация: задаются объект, атрибут, тип данных, допустимое значение и условия применимости. Третий уровень отвечает за программное выполнение: правило проверяется, после чего определяется статус ошибки и допустимое действие с моделью.
Это разделение существенно. Нормативный или проектный документ описывает требуемое состояние объекта, но не обязан указывать, как именно это состояние хранится в Renga или IFC. Программное правило, напротив, допускает только одно представление. Итогом поэтому становится библиотека требований, в которой для каждого контролируемого свойства можно проследить происхождение, область действия и алгоритм проверки. Простой перечень параметров этого не даёт.
I. Источники требований к атрибутивным данным цифровой информационной модели
Отправной точкой при выборе атрибута служит задача использования информации. Набор полей, доступных в конкретной программе, на эту роль не подходит. ПНСТ 909-20241 связывает информационное наполнение со сценариями применения ТИМ и требует заполнения включённых в соответствующий состав атрибутов. СП 333.1325800.20202 также устанавливает общие требования к атрибутивному составу элементов ЦИМ: состав атрибутов должен обеспечивать полноту сведений, предусмотренных действующими нормами, и при необходимости может расширяться требованиями заказчика. На общественные здания этот принцип переносится как способ организации требований; готовым перечнем параметров он не является. Для общественного объекта дополнительно учитываются СП 118.13330.20223, профильные своды правил, требования доступности, эвакуации и противопожарной защиты.
Дополнительным подтверждением такого направления является ПНСТ 1080-20264, посвящённый цифровым информационным моделям поликлиник. Документ уже утверждён, но вводится в действие с 1 января 2027 г.; поэтому на дату подготовки статьи он используется только как ориентир развития требований к ЦИМ специализированных общественных объектов.
Для автоматизированного контроля важно сохранить связь каждого свойства с причиной его появления. Источником может быть нормативный документ, требование заказчика, проектное решение или технологическая потребность. Если эта связь потеряна, программа ещё способна обнаружить пустое поле, но уже не сможет объяснить, почему отсутствие значения считается ошибкой. В работе предлагается разделять три среды, между которыми проходит требование: нормативную, информационную и программную (Таблица 1).
Таблица 1
Структура источников требований к атрибутивным данным ЦИМ
|
Нормативная среда |
Информационная среда |
Программная среда |
|
• ПНСТ и своды правил |
• класс элемента IFC |
• тип объекта Renga |
Норма, связанная с доступностью пути для маломобильных групп населения, сначала относится к нормативной среде. На следующем шаге она связывается с конкретными типами объектов (помещением, дверью, пандусом) и описывается через свойства или вычисляемые признаки. И только после этого для Renga определяется, где взять значение и как проверить результат. Так схема отделяет содержание требования от способа его хранения. Есть и ещё одно практическое преимущество. При переходе от одного типа общественного здания к другому основная архитектура модуля может оставаться прежней; меняется в основном библиотека требований и условия их действия. Аналогичное отделение правил от данных модели используется в исследованиях автоматизированного ТИМ-контроля, где правила дополнительно различаются по структуре и вычислительной сложности [4, 6, 10, 11]. При рассмотрении классификации строительной информации в работе учитываются КСИ и МССК.
II. Формализация требований и виды автоматизированного контроля атрибутов
Чтобы текстовое требование можно было выполнить программно, в работе введено понятие «паспорт требования». Под паспортом требования понимается структурированный документ, который детально фиксирует условия и правила применения конкретного требования к информационной модели объекта. В нём содержатся идентификатор правила, ссылка на источник, область применения, тип объекта, контролируемое свойство, тип данных, допустимый диапазон или перечень значений, способ получения фактического значения, метод проверки, критичность и режим обработки ошибки. Паспорт служит промежуточным слоем между нормативным текстом и программным кодом.
Близкий по смыслу подход уже закреплён в спецификации информационных требований (IDS). Формат IDS разработан buildingSMART6 для задания информационных требований, которые могут интерпретироваться программными средствами и применяться к IFC-моделям. В нём можно ограничивать область применения и задавать требования к сущностям, классификациям, материалам, свойствам и их значениям. В работах G. de Marco и соавторов, S. Fischer и соавторов, а также D.C. Dias и соавторов показано использование IDS для структурирования требований, проверки их выполнения и подготовки ТИМ-данных к последующим задачам [7–9]. Для модуля Renga полное воспроизведение формата IDS необязательно, однако принцип «область применимости + набор требований» хорошо подходит для построения внутренней библиотеки правил.
После формализации должно быть ясно, какое именно состояние считать несоответствием, и контроль здесь не сводится к поиску незаполненных ячеек. В библиотеке правил различаются как минимум восемь ситуаций. Две из них связаны с отсутствием данных: свойства нет у объекта либо свойство есть, но значение отсутствует. Три относятся к самому значению: его тип не соответствует ожидаемому, числовое значение выходит за установленный диапазон или предельную границу, категориальное либо текстовое значение не входит в заранее заданный разрешённый перечень или классификатор. Ещё три касаются условий применимости, связей между параметрами и достаточности исходных данных: правило применимо только при определённом условии, но это условие не выполнено; взаимосвязанные параметры противоречат друг другу; требуемую характеристику невозможно получить из доступных данных, то есть в модели отсутствуют исходные сведения, нужные для её вычисления или определения. Выход числа за допустимую границу при этом относится к количественным ограничениям, а отсутствие значения в разрешённом перечне относится к контролю дискретных или категориальных значений.
Для проверки работоспособности такой структуры подготовлен пилотный набор правил для четырёх базовых архитектурных классов общественного здания (Таблица 2). Примеры показывают метод; полного нормативного перечня они не дают.
Таблица 2
Пример формализации правил контроля атрибутивных данных
|
Класс IFC |
Проверяемый атрибут |
Условие контроля |
Результат / политика дозаполнения |
|
IfcSpace |
Назначение помещения |
Свойство существует и имеет непустое значение из принятого классификатора |
Ошибка: отсутствует/не заполнено; автоматическое заполнение не выполняется |
|
IfcSpace |
Площадь помещения |
Числовое значение существует; единица измерения определена; при необходимости сравнивается с расчётной площадью |
При отсутствии допустимо получить из количественной характеристики или геометрии |
|
IfcSpace |
Признак доступности МГН |
Логическое значение задано для помещений, включённых в доступный маршрут |
При отсутствии требуется проверка контекста; автоматическое заполнение только при однозначном правиле |
|
IfcDoor |
Предел огнестойкости |
Для противопожарной двери свойство обязательно и соответствует допустимому формату |
Ошибка критического типа; значение не должно назначаться программой без исходного основания |
|
IfcDoor |
Признак эвакуационного выхода |
Для двери, участвующей в эвакуационном маршруте, должен быть задан соответствующий признак |
Условная проверка; при конфликте формируется предупреждение |
|
IfcStair |
Высота ступени |
Числовое значение существует и находится в заданном диапазоне |
Возможно вычисление по геометрическим параметрам лестницы при достаточности данных |
|
IfcStair |
Ширина проступи |
Числовое значение существует и соответствует условию применимого правила |
Возможно вычисление по геометрии; при расхождении фиксируется ошибка |
|
IfcRamp |
Уклон |
Числовое значение существует, имеет корректную единицу и проверяется по допустимой границе |
При наличии геометрии уклон может быть вычислен автоматически |
Исправление найденных ошибок составляет отдельную задачу. Возможность записать значение через API сама по себе не обязывает программу делать это автоматически. Автозаполнение оправдано только тогда, когда новое значение однозначно следует из уже имеющихся данных: геометрии, количественной характеристики, идентификатора или заранее установленного соответствия классификации. Если свойство отражает проектное решение, нормативно назначаемую характеристику или зависит от контекста, программа не должна подменять специалиста. В частности, нельзя автоматически «угадывать» назначение помещения, требуемый предел огнестойкости или другие семантические признаки, для которых в модели нет достаточного основания. Каждому правилу с учётом этого назначается один из четырёх режимов. В режиме AUTO значение вычисляется и записывается без участия пользователя, в режиме SUGGEST программа формирует вариант, но запись выполняется только после подтверждения. MANUAL означает, что значение вносит сам специалист. CHECK_ONLY оставляет правило исключительно для контроля. При таком разделении поведение модуля становится предсказуемым, а риском автоматических изменений можно управлять отдельно.
В публикациях по информационному обогащению ЦИМ используется сходная логика. G. de Marco и соавторы рассматривают IDS как средство работы с неполным информационным наполнением [7]. D.C. Dias и соавторы показывают процесс открытого обмена ТИМ-данными, ориентированный на спецификацию информационных требований (IDS), в котором проверка требований связана с подготовкой данных модели к стоимостной оценке [9]. A. Karmakar и V.S.K. Delhi исследуют сочетание машинного обучения и детерминированных правил для семантического обогащения ЦИМ [12]. Из этих работ для настоящей разработки важен один общий принцип: у значения, которое добавляет программа, должно быть проверяемое происхождение. Результат необъяснимого предположения под это определение не подходит.
III. Программная реализация контроля и дозаполнения атрибутов в Renga
Renga API5 предоставляет базовые операции для реализации такого контроля: доступ к объектам модели, параметрам, количественным характеристикам и пользовательским свойствам. Через контейнер свойств можно проверить наличие свойства у объекта, получить его идентификатор и значение, а для пользовательских свойств выполнять создание и изменение через предусмотренные API операции. Контроль в этом случае запускается непосредственно в исходной модели, и экспорт не превращается в обязательный этап каждой проверки.
IFC при этом остаётся полезным уровнем унификации. В Renga предусмотрена настройка экспорта IFC4 через файлы сопоставления типов и параметров. Р.В. Осташев и С.И. Евтушенко показывают пример разработки такого IFC-маппинга для архитектурных моделей Renga [3]. Поэтому в библиотеке требований целесообразно хранить две ссылки на одно и то же свойство: внутренний идентификатор Renga, необходимый для работы модуля, и соответствующее IFC-представление, необходимое для открытого обмена данными.
Работу модуля можно свести к семи операциям. После запуска загружается библиотека требований и считывается коллекция объектов модели. Дальше для каждого объекта определяется тип и отбираются только применимые к нему правила, модуль получает нужные свойства, выполняет проверки, при разрешённом режиме обрабатывает недостающее значение и добавляет результат в отчёт. Общая последовательность показана на Рис. 1.
Рис. 1. Логика автоматизированного контроля
атрибутивных данных ЦИМ в Renga
Самым важным этапом является правильный выбор применимых правил. Одно и то же свойство не обязательно для всех объектов одного класса: правило может относиться ко всем помещениям, только к санитарным помещениям, к дверям на эвакуационном пути или к пандусам доступного маршрута. Без учёта области применения модуль будет генерировать ложные ошибки. То, что применимость правила нужно определять заранее и отдельно от самой проверки, прослеживается в работах C. Eastman и соавторов и W. Solihin, C. Eastman [4, 10].
После выбора правила сначала проверяется само наличие свойства. Если оно найдено, последовательно анализируются заполненность, тип и фактическое значение. При выявлении несоответствия дальнейшее действие выполняется в соответствии с назначенным этому правилу режимом обработки, описанным выше. Все записи в модель выполняются в отдельной операции редактирования, чтобы пользователь видел результат вмешательства и мог его отменить.
Отчёт нужен для устранения ошибок, одного их подсчёта недостаточно. Для каждой записи предлагается указывать объект Renga, его тип и IFC-класс, идентификатор правила, контролируемый атрибут, источник требования, фактическое значение, ожидаемое условие, тип несоответствия и выполненное действие. В сводной части можно показывать число применённых правил, успешных проверок, автоматически исправленных ошибок, замечаний для ручной работы и коэффициент Kattr.
Разрабатываемый модуль не подменяет систему автоматизированного нормоконтроля. Его задача находится на более раннем этапе: определить, достаточно ли хорошо подготовлены атрибутивные данные для дальнейшего машинного использования. Это важно для сценариев, где ЦИМ служит источником ведомостей, расчётов или последующих проверок. Исследования по спецификации информационных требований (IDS) показывают, что заранее сформулированные и машинно проверяемые информационные требования полезны на практике [7–9], а современные обзоры автоматизированной проверки ЦИМ подтверждают, что качество исходных данных остаётся самостоятельным направлением исследований [1].
Развивать модуль имеет смысл поэтапно: сначала проверки, не требующие сложного контекста (наличие свойства, заполненность, тип данных и допустимый диапазон), затем условные правила, согласованность нескольких свойств и вычисление значений по геометрии. Рабочий прототип при этом появляется раньше, а первая версия модуля не оказывается связанной с задачей полного автоматизированного нормоконтроля.
Выводы
По результатам исследования атрибутивный контроль выделяется в отдельный этап обеспечения качества ЦИМ. Даже правильно построенная геометрическая модель не становится автоматически пригодной для расчётов и обмена данными: для машинной обработки нужно, чтобы требуемые свойства существовали и были заполнены значениями в ожидаемом формате.
Число собранных параметров само по себе мало что даёт; для автоматизации важнее, чтобы у каждого параметра было ясное происхождение. Для каждого атрибута задаются источник, область применения, тип объекта, способ представления, допустимое состояние и метод проверки. Переход к другому типу общественного здания при таком подходе требует прежде всего расширения библиотеки правил, переделывать весь модуль не нужно.
Переход от текстовой нормы к машинно выполняемому условию обеспечивает предложенный «паспорт требования». Для первой версии инструмента наиболее рациональны четыре группы проверок: наличие свойства, заполненность, тип данных и допустимость значения. Более сложные условные и межобъектные правила подключаются после того, как устойчиво работает выбор объектов и чтение их свойств.
Автоматическое исправление требует осторожности. Программа может самостоятельно записывать геометрические или расчётные характеристики, если исходных данных достаточно для однозначного вычисления. Семантические и проектные решения должны оставаться под контролем специалиста. Разделение правил на AUTO, SUGGEST, MANUAL и CHECK_ONLY закрепляет это ограничение в самой структуре библиотеки требований.
Следующим практическим этапом работы является создание модуля Renga, реализующего цепочку «модель-объект-применимое требование-проверка-допустимое исправление-отчёт». Он может использоваться как предварительный контроль перед IFC-экспортом, передачей модели заказчику, формированием ведомостей и запуском более сложных процедур автоматизированной проверки.
____________________
1ПНСТ 909-2024. Требования к цифровым информационным моделям объектов непроизводственного назначения. Часть 1. Жилые здания. Официальная карточка Росстандарта. URL: https://protect.gost.ru/gost/details/e9a5b8e2-3d74-460b-b4ab-0a091317beef (дата обращения: 11.09.2026).
2СП 333.1325800.2020. Информационное моделирование в строительстве. Правила формирования информационной модели объектов на различных стадиях жизненного цикла. Росстандарт. URL: https://protect.gost.ru/sp/details/a1f757dc-ba6b-4572-a267-cc8016b950f0 (дата обращения: 12.09.2026).
3СП 118.13330.2022. Общественные здания и сооружения. Росстандарт. URL: https://protect.gost.ru/sp/details/ced01945-2f53-47c9-bdb8-4875c2b9800e (дата обращения: 12.09.2026).
4ПНСТ 1080-2026. Цифровые информационные модели объектов непроизводственного назначения. Поликлиники. Общие требования. Дата введения в действие — 01.01.2027. Приказ Росстандарта от 23.07.2026 № 34-пнст. URL: https://www.consultant.ru/document/cons_doc_LAW_540818/ (дата обращения: 11.09.2026).
5Renga API. How to work with properties; IPropertyContainer Interface Reference; Экспорт в IFC. Официальная документация Renga. URL: https://help.rengabim.com/api/how-to-properties.html; https://help.rengabim.com/api/interface_i_property_container.html; https://help.rengabim.com/ru/Content/ifc.htm (дата обращения: 11.09.2026).
6buildingSMART International. Information Delivery Specification (IDS). URL: https://www.buildingsmart.org/standards/bsi-standards/information-delivery-specification-ids/ (дата обращения: 11.09.2026).
