Прошло целых два года, как команда NSR Specification твердо пообещала добиться автоматизации экспертизы цифровых информационных моделей (ЦИМ) за счет создания машинопонимаемых представлений требований стандартов проектирования. На тот момент мы очень хотели регулярно рассказывать о промежуточных результатах, но слишком увлеклись разработкой. Ежедневно возникали новые и новые проблемы, в муках рождались способы их решения, в спешке писались задачи на разработку, когда заканчивались слова мы рисовали картинки, потом, дрожащими руками тестировали новый функционал, с азартом отлавливали баги, умело замаскированные под фичи... Каждый раз нам казалось, что осталось только дождаться свежего релиза, и все, мы победили. Оглядываясь назад, мне все чаще кажется, что мы были немного сумасшедшими, раз взялись за эту задачу. Но это, наверное, к лучшему. Если бы тогда, в 2023 году мы знали обо всех сложностях, с которыми нам предстоит столкнуться, то сегодня не смогли бы похвастаться работающим решением. Теперь то уж точно нам есть о чем рассказать: решение работает и уже обкатано на нескольких пилотных проектах.

Краткое содержание предыдущей серии

Несколько лет назад государством была поставлена очень амбициозная задача перевода текста требований норм и стандартов с русского языка на язык программного сценария, который сможет прочитать, понять и исполнить внешнее программное обеспечение. Применительно к строительной отрасли такие требования должны были обеспечить, как минимум, автоматическую оценку соответствия проектных решений нормам и стандартам РФ. Сперва это называлось машиночитаемостью, затем машинопонимаемостью, потом появилась машиноинтерпритируемость, в конце концов все запутались, а самые настойчивые…

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

Не будем зацикливаться на терминологии, и без этого проблематика поражает воображение:

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

Во-вторых, проблемой является и обработка текста стандарта, в котором надо сперва выделить границы нормативных положений, а затем с удивлением обнаружить, что отнюдь не каждое из них является требованием (есть исключения, инструкции и справка), а те, которые содержат в себе критерии оценки объектов, очень часто включают в себя не моделируемые условия, вроде «предела видимости» или «исключения проникновения дождевых талых вод». Но, конечно же, есть и те требования, которые можно использовать в качестве исходных данных для создания правил проверки ЦИМ.

В-третьих, какое ПО будет выполнять проверку? Минимально необходимый функционал должен позволять выполнять отбор элементов ЦИМ по информационным характеристикам, оценку положения элементов относительно друг друга и анализ структурных связей. А максимально, необходимо использовать отбор элементов по расчетным, относительным значениям, выполнять группировку, считать количество, суммировать количественные характеристики и… выполнять шаги по принятию решений. Можно, конечно, взять и написать собственное приложение, но сколько времени это займет? Поэтому было решено экспериментировать с тем, что есть. А есть у нас функционал проверки на геометрические коллизии, который может отобрать пары элементов по информационным свойствам и оценить их положение относительно друг друга в CADLib Модель и Архив (плюс/минус похожий инструмент есть и в других BIM- агрегаторах).

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

Пионеры не ищут легких путей!

Следовательно, нам необходимо создать машинопонимаемое представление нормативного требования, учитывающее еще не стандартизированные особенности проектирования ЦИМ и функциональные ограничения ПО, исполняющего проверку. Схему данных универсального xml, утвержденного Минстроем РФ решено было не ждать, а делать сразу специализированный xml для конкретных BIM-агрегаторов.

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

Сегодня многие говорят о возможностях технологии ИИ при решении подобных нетривиальных задач. Но существующие на данный момент генеративные модели (LLM) плохо понимают нюансы проектирования и склонны давать неполные ответы. Нужно дообучение, которое, мягко говоря, очень затратно.

Обучать ИИ решению точных задач проще всего на размеченных данных. Два года назад мы провели эксперимент по конвертации сценария проверки ЦИМ на основе семантической разметки нормативного требования, который смог прочитать и исполнить CADLib Модель и Архив.

Было решено масштабировать этот опыт, создать инструмент обработки текста стандартов, с помощью которого можно и получить работающие программные сценарии оценки соответствия ЦИМ, и собрать данные для машинного обучения.

Между двух огней

Мы начинали с того, что применяли классические методы разметки текста разнообразных требований, а затем вручную создавали правила проверки тестовой ЦИМ в CADLib Модель и Архив, чтобы понять логику работы, а затем пытались натянуть одно на другое. И следует признать, что не всегда это было возможно. Пройдя все стадии принятия неизбежного, нам пришлось признать, что:

• с логикой работы программ для проверки ничего сделать нельзя (кроме как разработать свое решение);

• а вот логику семантического анализа мы можем разработать свою собственную, чтобы из нее можно было получить набор фильтров для отбора объектов и проверки по информационным свойствам, данные о структурных связях и сведения о положении элементов относительно друг друга.

Именно поэтому нам и пришлось разрабатывать собственный инструмент, реализующий разметку текста, а не использовать готовые программы (они есть, — на разный вкус, размер и кошелек).

Этапы семантического анализа по NSRовски

Раскрою все секреты. Итак, что происходит с текстом требования, если его загрузить в наш инструмент:

1. Лексический анализ или токенизация (выделение в тексте нормативного положения лексем, токенов).

2. Назначение на каждый токен (группу токенов) семантического компонента в соответствии со значением токена. Отобранный набор семантических компонентов является симбиозом морфологического и синтаксического анализов. Если описать это в общих чертах, то выделяются:

   · Subject — субъект требования, аналог подлежащего в синтаксисе. Сущность, которая в процессе выполнения условий, описанных в требовании, будет определена как спроектированная с нарушением;

   · Object — объект требования, аналог подлежащего в синтаксисе, но не являющийся субъектом требования;

   · Property — наименование атрибута (длина, ширина, высота, покрытие) субъекта или объекта;

   · Calculated property — показатель взаиморасположения объектов. Сейчас это используется только для расстояний;

   · Feature — характеристика или качественное значение атрибута субъекта или объекта;

   · Quantity — количественный показатель атрибута субъекта или объекта;

   · Units — единица измерения количественного показателя субъекта или объекта;

   · Deontic operator — деонтический оператор, выражающий степень необходимости выполнения условий;

   · Action — действие, которое, согласно условиям, (не) может выполняться над субъектом или объектом;

   · Mathematical operator — компонент, описывающий математические операции;

   · Operator modifier — модификатор оператора, уточняющий порядок (регулярность) выполнения условий;

   · Comparative relation — компонент, выполняющий сравнение;

   · Negation — отрицание, например «не более», «не распространяется»;

   · Logical operator — логический оператор;

   · Relation — оператор, указывающий на взаимосвязь между субъектом или объектами;

   · Subject reference — местоимения, являющиеся ссылками на субъект или объект или термины‑синонимы субъекта или объекта требования;

   · Quantity (property) reference — местоимения, ссылки на количественный показатель атрибута субъекта или объекта, аналогично subject reference;

   · Constraint operator — оператор, с помощью которого устанавливается связь между субъектом или объектом и значением его атрибутов или местоположением.

   На этом этапе у нас реализована подсказка семантического компонента с помощью нейросети. Точность подсказок уже очень высокая, более 80%, но решение все равно принимает человек, который может внести изменения вручную, и эти данные будут использованы для дообучения.

3. Назначение связи семантических компонентов

На этом этапе разметчик должен указать какой property (атрибут) какому объекту принадлежит, на какое числовое значение указывает оператор сравнения и тому подобное. Направление связей соответствует правилам построения синтаксических деревьев. Это принципиально для дальнейшей автоматизации.

Конечно, мы могли бы попробовать обойтись без этого этапа. Но текст требований чаще всего включает в себя множество однородных членов и для точности интерпретации при создании правил проверки нам надо знать наверняка, что 3-го типа – это свойство лестницы, а не лестничной клетки или стены.

Может быть, в будущем мы сможем опускать установку связей. Но пока нам нельзя рисковать.

4.  Формирование верхнеуровневых и групп семантических компонентов в виде простых суждений, которые в общем виде похожи на триплеты (субъект, предикат, объект). Эти простые суждения должны стать шагами выполнения проверки.

Сейчас мы выделяем два типа суждений:

• ограничение: критерии выбора субъекта в ИМ (ЦИМ);

• правило: критерии проверки выполнения требования.

  И дополнительно классифицируем их по содержанию:

• качественные (шаг анализа качественных свойств объекта);

• количественные (шаг анализа количественных свойств объекта);

• местоположение (шаг анализа расположения нескольких объектов в ЦИМ относительно друг друга);

• структурные (шаг анализа структурных связей элементов, например, в соответствии со структурой IFC).

На этом этапе у нас тоже работает подсказка от нейросетей, но здемь точность нас пока не удовлетворяет: где-то 50-60%. Но и примеров для обучения у нас было не так много, около 150 штук. Так что, нам есть на что надеяться.

  5.  Формирование шагов проверки из набора верхнеуровневых компонентов, содержащих все сведения для выбора субъекта (субъектов) проверки и оценки наличия нарушения, согласно нормативному требованию.

Эта система разметки позволяет автоматизировано создавать структуру сценария проверки ЦИМ. Она достаточно гибкая, чтобы предусмотреть различные варианты выполнения ЦИМ (та же лестница и ограждение могут быть представлены самостоятельными объектами или единым, неделимым элементом, где высота ограждения будет записью в атрибутах).

 КСИ – сомнительно или окей?

Одной разметки структуры мало для создания работающего правила. Необходимо еще к каждому понятию в тексте требования привязать пары атрибут+значение, которые используются для описания объектов в пользовательской ЦИМ.

Это могут быть коды классификатора строительной информации (вопреки распространенному мнению, что составной код не является обязательным условием применения КСИ, можно описывать кодами отдельные позиции характеристик). На всякий пожарный мы добавили в наш модуль все редакции классификатора.

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

Разметка – дело тонкое

Если бы все требования были такими: одно предложение и конкретные критерии оценки. Но на практике все сложнее.

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

   Видео 1. Расчетные значения:

2. Оценка минимально допустимого расстояния между трубопроводами. Если делать разметку со стандартной логикой, то в проверке произойдет оценка положения всех труб со всеми трубами и, в результате, мы получим ложные коллизии. Значит, нужно как-то сделать исключение для элементов, принадлежащих одной линии. Выкрутились с помощью формул.

3. Иногда в тексте прямо не указано расстояние между объектами, расположение которых друг к другу надо проверить. Например, «Площадка перед дверью» – сколько это в миллиметрах? Не придумали ничего лучше, как вручную указывать для таких случаев расстояние с учетом возможной погрешности.

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

Видео 2. Разбор табличного требования:

Продолжать можно бесконечно долго. Более того, мы до сих пор не придумали, как преодолеть некоторые сложности. Например, работу с исключениями, которые в структуре стандарта находятся отдельно от требований.

Иными словами, нам есть к чему стремиться!

Брюки превращаются... Превращаются брюки...

А потом началось самое увлекательное, ведь нам надо было втиснуть все многообразие связей, полученных в результате семантического разбора в ограниченное количество операций по проверке ЦИМ, реализованное в готовых программных решениях.

Это очень напоминает управление марионеткой на ниточках с помощью креста (ваги).

Чем мы могли оперировать, используя классический функционал проверки на коллизии CADLib Модель и Архив:

? фильтрами по свойствам объектов, причем структурные связи тоже становятся фильтрами отбора. В условиях проверки нельзя использовать характеристики структурных элементов (типа здания или этажа);

? оценкой минимального расстояния (если в случае наличия одного объекта относительно другого на определенном расстоянии- работает условие проверки);

? оценкой наличия объекта (трудно для понимания, но, против факта не попрешь: в этом случае условие проверки будет работать, если не получилось обнаружить один объект на определенном расстоянии относительно другого);

? оценкой пересечения объектов (условие проверки работает в том случае, если имеется физическое пересечение объектов).

Добавим к этому возможность взять в одну проверку только два объекта, чтобы проверить их взаиморасположение. Становится совсем весело.

Для тех, кто запутался, объясню на примерах:

• из требования к лестницам в лестничных клетках, у которых должна быть определенные ширина или уклон, надо получить проверку по условию минимального расстояния: искать помещение/зону лестничной клетки относительно объекта лестницы, и, если она обнаружилась, то проверять ширину;

• если же проверять надо лестницы не в зоне лестничной клетки, то, позарез придется учесть отрицание «не» и зацепившись за него, как за якорь, создать условие проверки наличия объектов, чтобы оценивать свойства только тех лестниц, у которых лестничных клеток не нашлось.

И это еще полбеды, а вот что делать с «открытыми лестницами»? Как из этого текста получить в явном виде указание на то, что речь о лестницах не в лестничной клетке? Назначить семантический компонент отрицания на открытость? В принципе можно…

Приведу еще примеры:

• Колясочная должна располагаться на расстоянии менее (не более) x метров от входа – должна работать проверка наличия соседних объектов.

• Котельная должна располагаться на расстоянии более (не менее) x метров от склада горючих материалов – условие минимального расстояния.

Получается, надо искать токен, на котором назначен оператор сравнения, посмотреть есть ли тут отрицание «не», и в зависимости от их значения создавать правильное условие.

А ведь может быть и «колясочная не должна располагаться на расстоянии более x метров от входа». Здесь тоже отрицание, но связанное с деонтическим оператором.

Сперва мы пытались словами описывать задание на разработку конвертера правил проверки из разметки. Когда приличных слов не осталось – начали рисовать схемы.

И, слава крепкой нервной системе наших разработчиков, конвертация заработала.

Видео 3. Схема интерпретации разметки:

Доверяй, но проверяй

Чтобы разработать инструмент, работающий не только в нашем воображении, но и на практике, мы за последние 2 года реализовали около 16 пилотных проектов на реальных пользовательских ЦИМ в разнообразных форматах:

• IFC;

• CDE.

А также на различных типах ОКС:

• магистральный трубопровод;

• промышленное здание;

• жилой многоквартирный дом;

• здание школы;

• автомобильная дорога.

И даже попробовали разные BIM-агрегаторы, помимо CADLib Модель и Архив, с которым у нас есть готовая интеграция. Мы изучали возможности настройки правил проверки в:

• Larix Manager;

• Tangle Control;

• BIMIT.

Да, речь пока о ручной настройке правил проверки в соотвествии со структурой семантической разметки требования. Но ведь и в CADLib Модель и Архив мы начинали именно с этого! В общем, мы открыты к дружбе, сотрудничеству и экспериментам (если вы понимаете, о чем я).

Защита от нарушений

В этом году в самой Платформе nanoCAD появилась панель проверки модели с функционалом, учитывающим нашу потребность отработать все многообразие логических операций, которые можно выделить в нормативном требовании средней «заковыристости». Расчетные значения здесь можно использовать не только в шагах проверки, но и в условиях отбора. Можно проверять объекты на касание, считать количество, суммировать их количественные характеристики. А главное, доступна возможность создания сценариев проверки с бесконечной вложенностью шагов.

Нам осталось настроить выгрузку правил для nanoCAD из нашей разметки и можно будет сказать, что прямо в среде проектирования можно помогать проектировщику выполнить работу с учетом норм технического регулирования. По крайней мере, мы уже точно движемся в этом направлении.

Видео 4. Панель проверки модели в nanoCAD:

Где хранить?

Нормативные требования регулярно изменяются: в одни вносятся изменения, другие отменяют. Наконец, появляются новые требования. Поэтому так важно организовать хранение правил проверки совместно с актуализируемыми фрагментами стандартов.

Но мы и тут справились, реализовав экспорт размеченных данных в подсистему требований NSR Specification.

Здесь можно будет найти пакеты проверок, созданные нами, разработчиками системы. И здесь же счастливые обладатели доступа к модулю семантического анализа смогут сохранить свои версии правил проверки, учитывающие особенности собственных ЦИМ.

Жаркая осень 2025-го

Этой осенью у нас должен состояться релиз модуля семантического анализа NSR Specification.

И тогда каждый заинтересованный сможет попробовать свои силы в разметке требований. Обещаем организовать онлайн-доступ к веб-интерфейсу и провести обучающие вебинары.

Предлагаем следить за новостями. @NanoCADNews @nanocad @nsrspec