Меня зовут Дарья Беляева, я — Tech Lead и архитектор решений на стыке BIM, CDE и Revit API. Мы с коллегой, Андреем Прохоровым, за два месяца с нуля сделали AGR.Checker — плагин для Revit, который проверяет ЦИМ на соответствие требованиям IDS перед сдачей в составе АГР. В этой статье — конкретные инженерные решения, которые легли в основу плагина, и то, с чем мы разобрались при регистрации прав на программу в Роспатенте.

Какую проблему мы решаем этим плагином и зачем он нужен

Подготовка ЦИМ к сдаче в составе АГР требует, чтобы у элементов модели были проставлены конкретные параметры, конкретные значения и правильные IFC‑классы — это описывается требованиями IDS от Департамента градостроительной политики. Идеальный процесс: изучаем требования → создаём параметры → настраиваем маппинг → заполняем параметры → проверяем модель → отправляем заказчику → profit.

Но на практике модель собирают несколько человек (с разным уровнем подготовки) в разное время, и к моменту сдачи в ней неизбежно накапливаются несоответствия: где‑то не проставлен IFC‑класс, где‑то параметр пустой или дублируется, где‑то технически существует, но не активирован. Стандартный способ найти всё это — вручную пройтись по спецификации и свериться с требованиями, что на модели среднего объёма занимает часы, и так перед каждой сдачей заново, потом выгрузить в IFC, загрузить на СтроимПросто, там проверить, сверять всё это с моделью в Revit... Понимаете, к чему я клоню? Мы тратим много времени на рутину, хотя процесс довольно понятен.

AGR.Checker берёт эту рутину на себя: сканирует модель, сверяет её с правилами IDS и выдаёт конкретный список того, что нужно поправить — с возможностью сразу перейти к нужному элементу в модели и исправить проблему групповым способом, а не по одному элементу.

Идея и то, как мы подошли к архитектуре

Идею и саму логику проверки — какие параметры и в каком виде обязательны для каких категорий — сформулировал Андрей, BIM‑инженер с опытом на объектах метрополитена, ТЭС, АЭС, жилых домов и дорожного строительства. Архитектуру и весь код плагина писала я: моей задачей было превратить эту логику в боевой универсальный инструмент для любых объектов.

Плагин написан на C# под Revit API. Структурно я разделила его на несколько независимых модулей с чёткой зоной ответственности у каждого:

• точка входа и регистрация в интерфейсе Revit;

• слой работы с самой моделью (чтение и запись параметров элементов);

• модель данных для таблицы результатов;

• ядро проверки;

• генератор спецификаций;

• парсер конфигураций с правилами IDS;

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

Первое архитектурное решение, которое определило всё остальное, и которое я приняла на старте: проверка должна идти не по отдельным элементам, а по группам. На реальной модели с объекта однотипных элементов — сотни и тысячи, и если проверять каждый элемент по отдельности, пользователь на выходе получит сотни одинаковых строк ошибок вместо одной понятной. Поэтому ядро проверки сначала группирует элементы по категории, семейству, типу и IFC‑классу, и уже группы сверяются с правилами IDS — это одновременно и производительнее, и на порядок читаемее для человека, который потом с этим результатом работает.

Отдельно я продумала кейс с зонами: у зон с одинаковым семейством и типом, но разной схемой зонирования (например, «Общая площадь здания» и «СПП в ГНС»), стандартной группировки недостаточно — по факту это разные объекты с разными требованиями, и в таблице результатов они не должны схлопываться в одну строку. Схему зонирования я включила в ключ группировки отдельным полем — без неё пользователь просто не понимает, почему в одной строке результата смешались зоны с разными требованиями к ним.

Сложности с производительностью на больших моделях

Повторюсь, что модели с реальных объектов могут быть очень объёмными — вплоть до десятков тысяч элементов. Чтение параметров через Revit API — недешёвая операция для ПК, и если делать это поэлементно, то на большой модели проверка растягивается на долгое время. Группировка элементов до проверки здесь сработала на производительность: правила сверяются один раз на группу, а не по кругу на каждый элемент группы отдельно.

Совместимость версий Revit

Плагин поддерживает Revit с 2020 по 2026 версию. Revit API между версиями отличается не сильно, но всё же не гарантирует полную обратную совместимость — часть вызовов и поведение отдельных функций меняется от релиза к релизу. Чтобы не переписывать логику проверки при каждом новом релизе Revit, я вынесла все версионно‑зависимые места в отдельный слой совместимости, через который основной код работает с Revit. При выходе новой версии достаточно точечно обновить этот слой, не трогая остальную логику.

Правила IDS — входные данные, а не код

Требования IDS могут меняться, и зашивать их в код в виде условных конструкций означало бы пересобирать и заново распространять плагин при каждом изменении требований Департамента градостроительной политики. Поэтому я сделала так, чтобы правила хранились как структурированные данные по типам (набор свойств → параметр → тип данных → допустимые значения), которые можно обновлять отдельно от самого плагина, без релиза новой версии.

Лицензирование без внешней инфраструктуры

Раз мы делали продукт, то встал вопрос защиты от бесконтрольного копирования. Разворачивать сервер активации ради одного продукта избыточно, поэтому я сделала полностью офлайн‑схему: лицензия привязывается к цифровому «отпечатку» устройства (хеш от нескольких аппаратных идентификаторов) и подписывается криптографически, а плагин при старте сам проверяет подпись — без обращения к серверу при каждом запуске Revit. Подделать лицензию без закрытого ключа нельзя.

Регистрация в Роспатенте

Разумеется, мы решили закрепить права на программу. Нас двое, и оба хотели официально зафиксировать своё отношение к продукту — мы сразу пошли разбираться в теме. Плюс‑минус разобрались и вам рассказываем: нужен не патент, а государственная регистрация программы для ЭВМ. Отличия от патента: нет экспертизы по существу (никто не проверяет «новизну» алгоритма) и процедура быстрее. Процедура платная — 5000 рублей. Данная регистрация фиксирует авторство и дату создания программы: в Роспатент депонируются реферат и фрагмент исходного кода.

Для регистрации необходимы следующие документы:

• заявление о государственной регистрации программы для ЭВМ (форма из Приказа Минэкономразвития № 211) с данными обоих правообладателей. Заполнить можно прямо на сайте ФИПС, это удобнее. Нужна ЭЦП! Есть ещё вариант через Госуслуги, там подойдёт и простая электронная подпись (ПЭП);

• реферат объёмом не более 900 знаков;

• депонируемые материалы (фрагмент исходного кода в объёме, достаточном для идентификации программы);

• согласие каждого автора на указание сведений о нём в заявлении;

• согласие на обработку персональных данных;

• документ об успешно оплаченной пошлине.

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

Что дальше

Плагин уже прошёл тестирование и продолжает использоваться на наших реальных объектах. Регистрация прав закрывает юридическую часть истории. Планируем внедрять новые фичи по типу выгрузки IFC для последующей загрузки на сайт СтроимПросто.

А как вы проверяете модели на требования для АГР?