Автоматизация проверки информационных моделей на соответствие нормативам с использованием дескрипционной логики

Денис Олегович Турыгин, программист-разработчик отдела разработки инновационных систем ООО «Нанософт разработка» denis.turygin@nanocad.ru.
Ильдар Раисович Баймуратов, к.т.н., научный сотрудник Ганноверский университет (Германия) baimuratov.i@gmail.com.
Аннотация: В статье представлен метод автоматической проверки информационных моделей (ИМ) на соответствие строительным нормам. Нормативные требования переводятся в формальный вид с помощью трехуровневой схемы разметки текста, после чего автоматически преобразуются в код на языке OWL DL и сопоставляются с данными ИМ, что позволяет системе выявлять нарушения с помощью логического вывода. Приведены результаты экспериментов, оценена эффективность подхода и проанализированы перспективы его расширения и интеграции в nanoCAD, что открывает возможности автоматизации проверки соответствия нормам в инженерной практике.
Ключевые слова: технологии информационного моделирования (ТИМ), информационная модель (ИМ), разметка текста, дескрипционная логика, Natural Language Processing (NLP), OWL.
Технологии информационного моделирования играют особую роль в контексте соблюдения строительных норм. Любое здание должно соответствовать десяткам, а иногда и сотням требований, описанным в различных регламентах. Сегодня эта проверка часто выполняется вручную: эксперты перечитывают нормативы и сопоставляют их с проектом. Этот процесс не только медленный, но и не исключает ошибок. При этом современные строительные проекты становятся все сложнее, а нормативная база все объемнее. Поэтому потребность в автоматизированной проверке соответствия проектов требованиям растет с каждым годом. По оценкам специалистов, примерно треть времени при проектировании уходит на проверку нормативов. Однако человеческий фактор все равно приводит к пропуску важных нарушений — до 15−20% случаев. Очевидно, что автоматизация способна резко сократить трудозатраты и повысить качество работы. Дополнительным стимулом становится цифровизация строительной отрасли. Во многих странах применение BIM уже обязательно для государственных проектов. В России также поддерживается курс на полный переход к цифровым технологиям в строительстве, включая активное внедрение информационных моделей. Все это создает спрос на инструменты, которые позволят автоматически и надежно проверять ИМ на соответствие нормативам.
Постановка проблемы
Для реализации автоматической проверки информационных моделей на соответствие строительным нормам нормативные требования необходимо представить в формализованном виде, однозначно читаемом машиной. При этом возникают серьезные сложности. Строительные нормы ориентированы на людей, а не на алгоритмы: тексты часто содержат сложные синтаксические конструкции, условия, исключения и ссылки на другие документы. Одни и те же объекты в разных документах могут называться по-разному, а некоторые термины остаются неявными, требуя понимания смысла из контекста (задача, с которой стандартные алгоритмы справляются плохо). Существующие методы формализации нормативных требований пока не получили широкого распространения. Дополнительно наблюдается отсутствие стандартизированного подхода к разметке нормативных документов для последующей автоматизации. Такая разметка требует не только глубокого знания строительных норм, но и понимания формальной логики и принципов онтологического моделирования.
Пути решения проблемы
Чтобы решить эту проблему, предлагается метод перевода нормативных требований в машиночитаемый формат. Для этого используется дескрипционная логика (DL) — подход, который позволяет описывать объекты и их свойства в строгой, математически однозначной форме. На ее основе создается модель в формате OWL DL 1, который широко применяется для онтологий и хорошо подходит для автоматических проверок. Разработанный подход включает:
схему разметки нормативных требований;
инструменты преобразования разметки в OWL-код;
механизм сопоставления этого кода с реальной ИМ.
Проверка выполняется логическим выводом, то есть специализированная система автоматически определяет, нарушено ли какое-либо правило. Такой подход делает процесс проверки прозрачным, воспроизводимым и независимым от человеческого фактора. В итоге предлагаемый метод открывает путь к созданию интеллектуальных систем, которые могут автоматически выявлять нарушения, объяснять их и значительно ускорять работу специалистов.
В чем состоит суть метода?
В основе такого исследования лежит подход, который позволяет «переводить» строительные нормы с человекочитаемого формата в машиночитаемый. Благодаря этому ИМ можно автоматически проверить на соответствие требованиям, используя интеллектуальную систему (логический вывод, reasoner 2), способную самостоятельно искать противоречия (рисунок 1).
Главная идея метода — трехуровневая система аннотации. Она представляет обычный текст нормативов в структурированное описание, постепенно уточняя его и делая все более формальным. На первом уровне фиксируется общий смысл требования, на втором — его ключевые элементы, а на третьем — конкретные логические структуры, которые затем становятся основой для машинной проверки. В аннотацию входят не только сами элементы разметки, но и связи между ними: лингвистические и семантические. Их можно представить как стрелки, которые указывают, какие части текста относятся друг к другу и как они взаимодействуют. Это позволяет системе понимать не просто отдельные слова, а весь смысловой контекст.
После того как нормативные требования размечены, начинается этап автоматической конвертации. Специальная программа преобразует разметку в формат OWL — один из стандартных языков для представления знаний и онтологий. В это OWL-представление дополнительно импортируются данные из ИМ: все объекты, элементы здания и их характеристики. Далее в дело вступает reasoner, который сравнивает формализованные правила с реальными данными ИМ. Если где-то есть несоответствие, система его обнаружит и объяснит, какое условие было нарушено и каким объектом. Таким образом, предлагаемый метод позволяет автоматизировать проверку информационных моделей, сделать ее точной, прозрачной и с понятными результатами.
Схема разметки
Разработанная трехуровневая схема разметки позволяет «разобрать» текст технического требования на понятные системе элементы. Она устроена как иерархия тегов и связей, где каждый уровень выполняет свою роль в превращении обычного текста в формальное описание, пригодное для автоматической проверки.
Первый уровень — доменные термины. Здесь фиксируются основные понятия из строительной области. Для этого используются официальные классификаторы, например, российский «Классификатор строительной информации» (КСИ). Благодаря этому система точно понимает, о каких объектах идет речь, и может корректно сопоставлять их с элементами ИМ. Уровень доменных терминов служит мостом между формализованными требованиями и объектами ИМ.
Второй уровень — семантические типы. Этот слой отвечает за преобразование естественного языка в формальные логические конструкции, которые затем можно представить в формате OWL DL. По сути, здесь текст начинает превращаться в строгие онтологические описания, которые машина может прочитать однозначно.
Третий уровень — семантические роли. На этом этапе уточняются связи между частями требований: что с чем связано, какие объекты участвуют в отношении и какие логические зависимости между ними существуют. Эти связи нужны для построения корректных логических аксиом, на основе которых reasoner сможет выполнять проверку.
Таким образом, каждый уровень разметки вносит свой вклад: от определения терминов до построения логических правил, что в итоге обеспечивает переход от нормативного текста к его формальному исполняемому представлению.
Семантические типы
Слой семантических типов представляет собой адаптацию синтаксиса языка OWL DL для нужд разметки нормативных текстов. Основой служит Manchester-синтаксис OWL с модификациями для улучшения понимания экспертами предметной области. Полное сопоставление тегов с конструкциями OWL представлено в таблице 1.

Дополнительно слой семантических типов включает специальные семантические стрелки Domain, Range и Of, которые помогают однозначно установить связи между семантическими типами. Стрелка Domain указывает на субъект отношения или свойства, а стрелка Range — на объект или значение. В свою очередь, Of определяет, к чему относятся сравнение или связка.
Семантические роли
Большинство строительных требований имеют структуру условных утверждений вида «если объект имеет определенные характеристики, то он должен удовлетворять определенным ограничениям». Эта структура формализуется через две семантические роли:
Subject (Субъект) — описывает класс объектов, к которому применяется требование;
Restriction (Ограничение) — определяет условия, которым должны удовлетворять объекты.
Лингвистические стрелки
Лингвистические стрелки соединяют отдельные фрагменты текста, относящиеся к одному и тому же элементу требования. В зависимости от того, как соединяются фрагменты текста, используются три вида стрелок:
Concatenation: a → b → ab;
Distribution: a → b, a → c → ab, ac;
Self-distribution: a → b → a, ab,
где a, b и c — фрагменты текста. Связь между тегами слоя семантических ролей устанавливается стрелкой To — эта стрелка помогает однозначно установить отношения между субъектами и ограничениями, когда в требовании больше одной пары семантических ролей.
Демонстрация разметки
Процесс разметки выполняется с использованием платформы INCEpTION [1] - инструмента для создания лингвистических корпусов и семантической разметки текстов. Теги для уровней семантических типов и ролей создавались вручную в соответствии с разработанной схемой. Связи между тегами реализованы как слои отношений с направленными стрелками. Рассмотрим требование (рисунок 2) «Перекрытие под зальным помещением, лекционной аудиторией должно быть с пределом огнестойкости не ниже REI 60».

Уровень доменных терминов (темно-зеленые блоки):
«Перекрытие» → TeS-AC (конструкции перекрытий);
«зальным помещением» → RZo-BEB030 (зрительный зал);
«пределом огнестойкости» → Prp-XPF_0007 (предел огнестойкости).
Уровень семантических типов (желтые блоки):
«Перекрытие» → Class;
«зальным помещением» → Class;
«лекционной аудиторией» → Class;
«не ниже» → Comparison;
«REI 60» → Literal;
«пределом огнестойкости» → Property (Domain → «Перекрытие», Range → «REI 60″);
„под“ → Relation (Domain → „Перекрытие“, Range → {"зальным помещением», «лекционной аудиторией"});
«должно быть» → Universal restriction.
Уровень семантических ролей (светло-зеленые блоки):
«Перекрытие под зальным помещением, лекционной аудиторией» → Subject;
«должно быть с пределом огнестойкости не ниже REI 60» → Restriction;
Subject → To → Restriction.
Полученная разметка служит основой для автоматизированного формирования OWL-представлений, используемых на следующих этапах проверки информационных моделей на соответствие.
Конвертация разметки в OWL
Для автоматизированной проверки информационных моделей на соответствие нормативным требованиям текстовые требования сначала переводятся в машиночитаемый формат. Этот процесс проходит несколько этапов.
Этап 1. Подготовка данных
Загружается файл с разметкой требования, полученный из инструмента INCEpTION. В результате программной обработки получается упорядоченная таблица данных, которая готова для следующего этапа.
Этап 2. Преобразование в формальные элементы
На этом этапе текстовые элементы превращаются в онтологические сущности: классы, свойства и связи между ними. Система также сопоставляет термины требований с уже существующими понятиями предметной области, обеспечивая единообразие в интерпретации. Особое внимание уделяется сложным конструкциям, условиям и исключениям из норм, которые преобразуются в логические правила, понятные системе. В результате формируются формальные утверждения, которые отражают смысл исходного текста и могут использоваться для автоматической проверки соответствия информационной модели нормам (рисунок 3).

На заключительном этапе формируется исполняемая модель требования, которую можно загрузить в любой OWL-совместимый reasoner для автоматизированной проверки соответствия. Таким образом, этот подход позволяет преобразовывать сложные строительные нормы в машиночитаемое представление, значительно ускоряя и упрощая процесс проверки информационных моделей на соответствие техническим требованиям.
Проверка информационной модели на соответствие требованиям
Предлагаемый подход автоматизированной проверки основан на применении механизмов логического вывода к графу, который получен объединением формализованных требований и данных, импортированных из ИМ. В процессе работы объекты ИМ преобразуются в экземпляры (индивиды) OWL-классов, соответствующих доменным терминам. Далее выполняется запуск механизма логического вывода, который классифицирует индивиды по субъектам требований и определяет, удовлетворяют ли эти объекты заданным ограничениям. В случае обнаружения несоответствия система формирует сообщение об ошибке с объяснением причины расхождения.
При выполнении проверки на соответствие запускается инструмент логического вывода (reasoner) Pellet [2], интегрированного в библиотеку Owlready2. Если проверка завершается успешно, в консоль выводится время работы reasoner’а, например:
* Owlready2 * Pellet took 1.5050263404846191 secondsВ процессе проверки reasoner может добавлять в онтологию новые аксиомы, уточняющие логические зависимости между элементами модели. Если обнаруживается противоречие, система сообщает об ошибке и выводит объяснение, сгенерированное Pellet:
ERROR: Ontology is inconsistent, run «pellet explain» to get the reason
This is the output of `pellet explain`:
Axiom: Thing subClassOf Nothing
Explanation(s):
1) RoomHeightRequirement equivalentTo height only decimal[>= 2.3]
Room_101_Instance height 1.5305109
Room_101_Instance type Room_101
Room_101 subClassOf RoomHeightRequirementВ приведенном примере reasoner указывает, что экземпляр Room_101_Instance имеет значение свойства height, равное 1,53 м, тогда как, согласно требованию для соответствующего класса Room HeightRequirement, высота должна быть не ниже 2,3 м. В итоге выявляется нарушение условия требования.
Таким образом, предложенный подход обеспечивает прозрачную, воспроизводимую и интерпретируемую проверку информационных моделей на соответствие нормативным требованиям, что существенно повышает точность анализа и снижает зависимость от человеческого фактора.
Вывод
В ходе исследования разработан и апробирован подход к автоматизированной проверке информационных моделей на соответствие нормативным требованиям, обеспечивающий их преобразование из текстового представления в исполняемый формат на языке OWL DL. Основой системы является трехуровневая схема семантической разметки, которая позволяет поэтапно формализовать нормативные требования и конвертировать их в исполняемый OWL-код. Разработанный подход интегрирует методы обработки естественного языка, онтологического моделирования и логического вывода, что обеспечивает воспроизводимый и интерпретируемый процесс проверки соответствия.
Ограничения предлагаемого подхода
Несмотря на достигнутые результаты, предлагаемый метод имеет ряд существенных ограничений, которые необходимо учитывать при его практическом применении. Главное ограничение связано со сложностью формализации нормативных требований: не все типы требований могут быть легко представлены в рамках используемой схемы аннотации и дескрипционной логики. Многие нормативные требования содержат неявные или нечетко определенные ограничения, интерпретация которых традиционно возлагается на экспертов. Например, требования, использующие такие формулировки, как «при необходимости», «в зависимости от условий эксплуатации», «с учетом местных особенностей», не поддаются прямой формализации без дополнительного контекста. Система способна обрабатывать только те фрагменты текста, в которых ограничения выражены явно и однозначно.
Возможности стандартных механизмов логического вывода для дескрипционных логик также не охватывают некоторые типы требований, особенно те, которые включают арифметические вычисления, сложные алгоритмы или процедурные спецификации. Например, требования к расчету нагрузок, определению коэффициентов безопасности или выбору материалов на основе многофакторного анализа выходят за рамки OWL-ризонеров.
Система не учитывает широкий контекст документа, такой как область применения нормы, ссылки на другие документы или изменения в нормативной базе. Это может приводить к неправильной интерпретации требований, которые имеют ограниченную область действия или содержат условия применимости.
Тем не менее частичная формализация, которую обеспечивает предлагаемый метод, имеет значительную практическую ценность. Она позволяет автоматизировать рутинные процедуры проверки соответствия для четко определенных требований и высвобождает экспертные ресурсы для анализа сложных и неоднозначных случаев. Явная идентификация формализуемых и неформализуемых частей требований также повышает прозрачность процесса проверки соответствия и помогает четко разграничить области автоматической и экспертной валидаций.
Планируемая доработка системы
Дальнейшее развитие исследования предполагает несколько направлений работы, направленных на расширение возможностей системы и повышение ее практической применимости в реальных проектах строительной отрасли. Приоритетным направлением является значительное расширение объема размеченных нормативных требований — это позволит выполнить более качественную проверку информационных моделей. Планируется создание специализированных наборов данных для различных типов требований (пожарная безопасность, энергоэффективность, доступность). Ключевым направлением практического внедрения является разработка плагинов и API для интеграции с nanoCAD — это обеспечит бесшовную интеграцию автоматизированной проверки соответствия в существующие рабочие процессы проектирования.
OWL DL — это диалект языка веб-онтологий OWL (Web Ontology Language), основанный на дескрипционной логике, который обеспечивает вычислимую полноту и разрешимость логических выводов.
Reasoner — это программное обеспечение, предназначенное для работы с базами знаний, которое анализирует их структуру, проверяет логическую согласованность и выводит новые знания на основе заданных правил и описаний.
Источник — журнал «Информационное моделирование».
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.