Учредитель журнала

РАБОТА С АТРИБУТИВНЫМИ ДАННЫМИ ЭЛЕМЕНТОВ ИНФОРМАЦИОННОЙ МОДЕЛИ

УДК 69:006.1

DOI 10.52815/0204-3653_2023_5194_
EDN: JWTBVX

Пестрикова Анастасия
Ведущий специалист по информационному моделированию зданий, BIM-менеджер, ООО «Проект СПиЧ»
e-mail: A.Pestrikova@speech.su

Адамцевич Любовь
Доцент, к. т. н., кафедра информационных систем технологий и автоматизации в строительстве, НИИ строительных материалов и технологий, Национальный исследовательский Московский государственный строительный университет
e-mail: AdamtsevichLA@mgsu.ru

Введение

Активное развитие технологий Индустрии 4.0 привело к цифровой трансформации строительной отрасли, где ключевыми становятся такие технологии, как информационное моделирование зданий и сооружений, аддитивное строительное производство, методы машинного обучения и др. [1].
Данная статья посвящена вопросам внедрения технологий информационного моделирования в России и решению проблем, возникающих при работе с атрибутивными данными элементов информационной модели на примере объекта жилищно-­гражданского назначения.

Основные требования к атрибутивному составу и содержанию элементов информационной модели

Информационная модель объекта капитального строительства формируется, как правило, на основе требований, изложенных в соответствующих нормативных документах, которые рассмотрены авторами ранее в работе [2]. Обобщенная структура классификации требований к информационной модели (ИМ) представлена на рис. 1.

Рис. 1. Классификация требований к информационной модели
объекта капитального строительства

Если рассматривать укрупненную классификацию, то можно выделить общие требования к файлу, к составу и наполнению информационной модели, а также к координации – размещению информационной модели – ее ориентации и позиционированию.
При этом под атрибутивной информативностью принимают характеристики моделируемого объекта, сформированные по требованиям к атрибутивному составу элементов информационной модели и отвечающие ограничениям действующей нормативно-­технической документации. При этом должно быть осуществлено однозначное определение элементов ИМ и их связей для выбранного уровня проработки на каждом этапе жизненного цикла (ЖЦ) объекта капитального строительства (ОКС).
Вместе с тем, обязательные атрибуты можно укрупненно разделить на группы, описывающие характеристики типов элементов, состоящих в классах, и выделить такие группы, как архитектурно-­конструктивные решения (которые и будут далее рассмотрены), электроснабжение, водоснабжение и пр.
Каждый класс элементов также может быть представлен в виде множества его составляющих – типов элементов, отражающих функциональное назначение (рис. 2).

Рис. 2. Типы элементов класса архитектурно-­конструктивныхA решений

Анализ процесса проверки атрибутивных данных

Для разработки системы автоматизированных проверок атрибутивных данных элементов информационной модели объекта капитального строительства необходимо провести анализ процесса проверки атрибутивных данных элементов в ИМ ОКС, который включает в себя комплексную оценку и валидацию атрибутивных данных, связанных с каждым элементом модели.
Начальным этапом процесса является идентификация элементов в информационной модели, которые содержат атрибутивные данные. Данные элементы представляют собой различные компоненты, такие как строительные элементы, конструктивные элементы, системы и другие объекты.
На следующем этапе проводятся анализ и проверка атрибутов на соответствие установленным стандартам, нормативным актам и требованиям проекта. На данном шаге цель аудита сводится к определению полноты, точности и согласованности атрибутивных данных элементов информационной модели. Именно на этом этапе возможно применение автоматизированных систем, например, для выполнения систематических проверок и выявления потенциальных проблем или несоответствий используются автоматизированные алгоритмы проверки и специализированное ПО.
Процесс проверки информационной модели позволяет установить соответствие содержания включенных в информационную модель атрибутивных и геометрических данных, в том числе, набору требований нормативных документов, требованиям заказчика и пр.
Проверка ИМ на всех этапах жизненного цикла ОКС является важным аспектом, с позиций обеспечения сохранения корректности данных при передаче модели в работу другим участвующим в проекте специалистам и заинтересованным лицам.
Учитывая вышеизложенное процесс аудита качества информационных моделей можно представить в схеме, представленной на рис. 3.

Рис. 3. Процесс аудита качества информационных моделей

В общем случае принципы контроля качества ИМ и ее элементов основаны на стандартизации и регламентации процессов информационного моделирования и должны учитывать требования и правила государственных и отраслевых документов по стандартизации. Работа организаций, обеспечивающих реализацию ИМ ОКС, должна базироваться на стандартах в области информационного моделирования, внедренных в ней, обеспечивающих стандартизацию процессов информационного обмена как внутри организации, так и с внешними участниками проекта. Реализация проекта должна быть обеспечена на основе утвержденных планов, а также с использованием открытых форматов и схем данных, регламентов коллективной работы в общей среде данных, с четким распределением ролей и функций участников проекта.
Вместе с тем состав обязательных проверок моделей может быть расширен в зависимости от уровня внедрения информационного моделирования в организации заказчика, навыков и опыта управляющих процессом моделирования, опыта руководителей проектов и исполнителей, наличия стандартов, практик и регламентов в области информационного моделирования, доступности программного обеспечения, наличия нормативных требований к проектным решениям и моделям в машиночитаемом формате, а также других факторов.
В соответствии с нормативными документами и регламентами организаций выделяют следующий набор обязательных проверок:
проверки пространственного положения и геометрических параметров;
проверки данных модели;
проверки на коллизии.
Процесс проведения проверок можно представить в виде обобщенной схемы, представленной на рис. 4.

Рис. 4. Обобщенная схема процесса проверки информационной модели

Как отмечено ранее, на этапах жизненного цикла ОКС проводить аудит информационных моделей необходимо регулярно, как для проверки корректности работы проектировщика, так и для сохранения преемственности данных при передаче модели в работу другим участвующим в проекте лицам. Однако в настоящее время проверка уровня проработки ИМ в соответствии с информационными требованиями заказчика вызывает ряд определенных затруднений, связанных с проработкой функционала программных инструментов, используемых в процессе формирования проверок.

Обзор функционала существующих систем анализа атрибутивных данных

В настоящее время существует значительное количество ПО для валидации информационных моделей. Проведем обзор существующих систем анализа атрибутивных данных для определения их достоинств и недостатков.
Проведенный анализ выявил, что большинство программных решений предназначено для работы с моделями, выполненными либо в ПО Autodesk Revit, либо с моделями, выгруженными в открытый формат IFC без возможности редактирования элементов модели.
Обзор существующих программ, поддерживающих проверку атрибутивных данных, представлен в таблице 1.

Таблица 1. Обзор существующих программ, поддерживающих проверку атрибутивных данных


При этом стоит отметить, что Revit Model Checker является плагином, осуществляющим комплексный сбор и анализ атрибутивных данных элементов информационной модели с минимальными потерями и искажениями данных в программном комплексе Autodesk Revit с возможностью создавать свои алгоритмы.
Autodesk Navisworks – отдельная программа, позволяющая визуально отобразить элементы по определенным условиям. Используется для проверок на коллизии, а также для формирования паспорта объекта.
Solibri Model Checker – специализированное программное обеспечение, предназначенное для обеспечения качества информационных моделей, выполняет анализ информационных моделей зданий и архитектурных и инженерных проектов с целью обеспечения их целостности, качества и физической безопасности.
Signal Tools – инструмент для проверки информационных моделей, выгрузки из них объемов работ для календарного графика и бюджета, а также создания строительной BIM-модели для сопровождения строительного процесса.
Таким образом, на рынке существуют продукты с разным функционалом, но при этом более распространена возможность проверки пространственных коллизий, чем проверка атрибутивных данных.
Среди российских продуктов заметна следующая тенденция: разработчики чаще ориентируются на создание плагинов для уже укрепившихся на рынке программ, таких как Autodesk Navisworks и Autodesk Revit, чем на создание полностью самостоятельных программ для валидации информационных моделей, что в настоящее время становится весьма актуальной проблемой.

Разработка системы автоматизированных проверок в ПО Renga

В настоящее время на российском рынке проходит активный процесс импортозамещения зарубежной продукции. При этом одной из российских компаний, занимающихся разработкой программных продуктов для проектирования зданий и сооружений, поддерживающей технологию информационного моделирования, является компания Software Renga [3–6 и др.].
Компания предлагает продукты для трехмерного проектирования. Документация, создаваемая в рамках этого ПО, соответствует российской нормативной базе [3].

Описание работы системы автоматизированных проверок

Разрабатываемая система является плагином – программным дополнением, реализующим внутренние события в ПО Renga. Процесс создания плагина подробно рассмотрен в [2].
Для расширения функциональности Renga и интеграции программного обеспечения применяется Renga API, который использует технологию COM для обеспечения доступа к функциям программы, поэтому возможно создание расширения и обращение к программе из сторонних приложений, в том числе написанных на языках программирования с динамической типизацией.
Для разработки приложений для Renga необходимо предустановить Software Development Toolkit (SDK), который предоставляет примеры кода и документацию по Renga API. Для инициализации плагина в среде Renga создается файл-описание библиотеки – файл XML-типа фиксированной разметки с расширением *.rndesk, который помещается в системной папке Renga.
Работа системы основывается на предоставлении доступа к свой­ствам объектов информационной модели через COM и получении значений присвоенным элементам модели свой­ств.
Свой­ства объектов модели Renga подразделяются на 3 типа [2]:
произвольные свой­ства различных фиксированных типов «Properties»;
расчетные характеристики свой­ственные типу объектов «Quantities»;
параметрические значения «Parameters» в зависимости от типа объекта.
Перечисленные выше свой­ства доступны через соответствующие интерфейсы «Container», которые доступны из объекта модели Renga:: ImodelObject. Представление объектов в Renga можно изобразить в виде схемы, представленной на рис. 5.

Рис. 5. Схема представления объектов в ПО Renga

Для корректной работы плагина и использования классов в коде программы, подключаются пространства имен, которые дают возможность ссылаться на классы.
На первом этапе разработки решения инициализируется разработка стартовой страницы открытия плагина, затем реализуется метод выбора объектов, который содержит в себе три условия.
Первое условие заключается в том, что на вход программе поступают типы объектов, которые присутствуют в модели. Если тип объекта не является Underfined, то в список проверяемых объектов записываются id – идентификаторы элементов. Для каждого идентификатора определяются ObjectType (тип объекта) и свой­ства, назначенные данному типу объекта. После определения свой­ств происходит реализация процесса получения значения данных свой­ств.
Второе условие содержит в себе ограничение по пользовательскому выбору ObjectType. Инициализируется процесс получения объектов данного типа из модели, а также получение значений уникального идентификатора и свой­ств, назначенных данному типу.
Третье условие заключается в проверке пользовательского выбора типов объекта. Если был определен способ пользовательского выбора типов объектов, но выбор не был сделан, выводится сообщение о пустом значении.
Для выбора всех элементов модели в проект плагина был добавлен пользовательский элемент управления Res.cs, который содержит в себе определение класса типов объектов.

Апробация системы автоматизированных проверок атрибутивных данных в ПО Renga

Апробация программы произведена при реализации проекта многоэтажного жилого дома. Информация по данному зданию была получена с реестра типовой рабочей документации официального сайта Минстроя России.
Информационная модель была создана на основе шаблона архитектурно-­конструктивных решений. Свой­ства объектов в архитектурно-­конструктивном шаблоне представлены на рис. 6.

Рис. 6. Свой­ства объектов в шаблоне

Данные свой­ства были выгружены в текстовый файл формата csv. В свой­ства элементов модели была внесена информация в соответствии с проектной документацией. Далее произведен аудит информационной модели при помощи предлагаемой автоматизированной системы. В результате работы системы получена таблица с перечнем элементов, которые не прошли проверку (рис. 7).

Рис. 7. Результат проверки

Полученные результаты можно использовать для отработки ошибок и приведения информационной модели в вид, соответствующий требованиям.

Выводы

Аудит информационной модели ОКС трудоемкий процесс, обойтись без которого невозможно. Вместе с тем ПО Renga имеет значительный потенциал для эффективного внедрения в инвестиционно-­строительный процесс за счет возможности разработки для интеграции дополнительных инструментов работы с информационной моделью.
Эффективный аудит требует непрерывного контроля и поддержки качества атрибутивных данных на протяжении всего жизненного цикла проекта. Регулярные проверки, периодические обзоры и непрерывный сбор обратной связи способствуют устойчивости и долгосрочной надежности информационной модели.
Использование автоматизированной системы при проверке атрибутивных данных информационной модели в значительной степени упрощает рабочий процесс, а также уменьшает трудовые и временные ресурсы.