История одной автоматизации в BIM-проекте: от скриптов в Dynamo до собственного плагина и SQL Server

Всем привет! Меня зовут Кирилл Якименко, я – BIM-эксперт компании КРОК, работаю с BIM-технологиями уже около 6 лет, входил даже в клуб Autodesk Expert Elite. В КРОК я занимаюсь тем, что внедряю BIM-технологии, развиваю и поддерживаю их применение.

Сегодня я вам расскажу о том, какой путь прошел КРОК в эволюции автоматизации процессов в Revit, как большой и тяжелый проект нам помогал в этом, а не мешал.

Автоматизацию рутинных процессов мы начали с Dynamo, потом стали писать скрипты на Python, познакомились с Revit API, завели внешнюю базу данных для масштабных проектов и научились красиво визуализировать данные из нее и составлять отчеты. Затем поняли, что нам нужен свой плагин, который мог бы управлять информацией в больших проектах и фильтровать данные по тем же коллизиям между элементами в моделях для разных пользователей и разных типов инженерных систем. С плагином мы очень быстро исчерпали резервы локальной базы данных (БД) и нам понадобился выделенный сервер.

Начнем с Dynamo

Как и большинство автоматизаторов, использующих Revit, мы начали с Dynamo, поскольку это простейший способ автоматизации, доступный прямо «из коробки».

У Dynamo много плюсов:

• он уже встроен в Revit;

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

• взаимодействие с Dynamo дает понимание того, как устроены наши модели Revit: что такое элемент, типы элементов, что из себя представляют параметры внутри модели, параметры внутри семейств, типы, размеры и так далее. Это пригодится при сложной автоматизации. Поэтому Dynamo – это очень круто;

• Dynamo работает последовательно – скрипт выстраивается слева направо: входные данные, обработка, затем вывод результата. Для людей, незнакомых с программированием, это хороший и простой старт в данном направлении. Они начинают мыслить логически, выстраивают полный алгоритм;

• еще один плюс Dynamo в том, что он помогает там, где Revit не вывозит, так как не все умеет из коробки. Dynamo = костыль помощи для Revit.

Зачем нам Dynamo?

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

• создании модели. При разворачивании проекта на сервере скрипты создают модели по разделам, добавляют необходимые рабочие наборы и связанные файлы;

• пакетной обработке большого числа моделей АР и КР, которые нужно залить на Revit-сервер и почистить;

• обработке семейств. Если у нас есть какие-то специфические требования заказчика по параметрам, например, он приносит свой ФОП, мы обязаны следовать этому требованию и переработать нашу библиотеку;

• подготовке шаблонов. Когда мы разрабатывали свои шаблоны, то пошли по пути наименьшего сопротивления: взяли шаблон ADSK (так как они были максимально адаптированы под российские стандарты) и доработали их определенным образом – добавили наши параметры, создали подготовленные листы. Весь процесс подготовки шаблонов ADSK к шаблонам КРОК у нас полностью автоматизирован.

Почему Dynamo не идеален

Тем не менее, Dynamo имеет ряд недостатков:

• из-за его линейности неудобно делать циклы и разветвления. Я сейчас говорю про Dynamo, который «из коробки»;

• также есть ограничение по памяти. Случается, что при обработке большого количества элементов память не освобождается, Dynamo зависает, и скрипт не отрабатывает (привет Google Chrome с кучей вкладок).

Также у Dynamo ограниченный встроенный набор функций. На скриншоте ниже видно, что у нас есть группа стандартных нодов, закрывающих порядка 70% наших потребностей, но постоянно возникают задачи, которых нет в стандартных пакетах. Приходится скачивать дополнительные пакеты.

Из этого вытекает следующая проблема – версионность. На следующем скриншоте видно, что пакет archi-lab имеет кучу версий, и нужно следить, чтобы у разработчика скрипта и у пользователя были одинаковые версии. Мы это решаем с помощью bat-файлов единой библиотеки пакетов, но все равно это неудобно.

Лечим проблемы с Dynamo с помощью Python

У Dynamo есть возможность создать Python-нод, в котором можно разместить полноценный код на языке Python.

 Python достаточно дружелюбный язык программирования в плане легкости изучения и применения. Перечислю основные плюсы для нас:

• для него не нужно устанавливать никакие дополнительные пакеты: если мы что-то напишем на Python в Dynamo, то с большой долей вероятности при переносе скрипта на любой компьютер он там тоже заработает;

• в Python-ноде можно делать циклы и разветвления, чего нет в стандартных нодах. Буквально две-три строчки кода, и мы уже можем обрабатывать несколько моделей, множество элементов и так далее;

• в Python можно чистить память. То есть можно оптимизировать работу скрипта, улучшить этот процесс.

А самый главный плюс использования кода Python в Dynamo в том, что мы начинаем погружаться в Revit API.

Revit API

«Страшно, очень страшно! Мы не знаем, что это такое, если бы знали, что это такое, мы не знаем, что это такое».

Шутки шутками, но когда кто-то погружается первый раз в Python внутри Dynamo и начинает изучать Revit API, кажется, что это что-то страшное, что-то непонятное. Мы же не программисты. Но на самом деле тут все просто и удобно.

Если мы посмотрим на Revit как на ПО, то его можно (примитивно) разделить на две части: GUI и API.

GUI (Graphical User Interface) – это графический интерфейс приложения, который мы видим, когда его запускаем: лента, кнопочки, свойства, диспетчер проекта и так далее.

API (Application Programming Interface) – программный интерфейс, то есть описание способов взаимодействия с программой.

Зачем это нам нужно? В API описаны:

• все элементы (классы), с которыми мы взаимодействуем;

• процессы (методы) и то, как мы можем с ними взаимодействовать.

То есть в Dynamo мы можем взаимодействовать с элементами посредством Python и с помощью методов из API. Также, стоит понимать, что в API достаточно много функций, которые не вынесены на кнопочку в ленте в Revit.

Дальнейшая автоматизация на больших проектах

Мы разобрались с Dynamo, с Python, залезли в API, где начали изучать методы и наполнять библиотеку скриптов. Но настала пора двигаться дальше. Катализатором процесса стал большой проект, в котором имелось порядка 150-200 моделей: несколько технологических корпусов и множество вспомогательных зданий на площадке, для каждого из которых проектируется большое количество инженерных систем и выпускается большое количество проектной документации.

Таким образом, возник вопрос: а как все это контролировать? Как подготовить всю нашу библиотеку семейств ко всем требованиям? Ответ – максимально автоматизируя процессы.

Excel – всему голова!

Раз у нас модель Revit – это некая база данных, то для хранения сводной информации нужно использовать таблицу. Начали с самого простого – с Excel. Упорядочили в нем список всех ~200 моделей. Затем начали выгружать туда количество элементов в моделях, поскольку было важно видеть динамику наполнения модели и появление в ней новых элементов от недели к неделе. И самое болезненное у всех – это количество коллизий. Соответственно, их тоже нужно было видеть в динамике.

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

База данных как самое логичное и взрослое решение

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

Первое – простота установки. Не нужно заморачиваться с серверами и так далее. Второе – она бесплатна. Третье – это хранение данных в файле, лежащем на сетевом диске, к которому у всех есть доступ. Четвертое, и главное – с помощью Dynamo можно обращаться к этой базе данных, – записывать и читать.

Начали экспериментировать. Создали таблицы, определили список элементов, которые попадают в них, какие параметры у элементов записывать в таблицы. Затем продумали связь таблиц в БД.

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

«А красота-то где?»

Вот мы считали огромное количество информации из модели, записали все в базу. А что дальше? У нас там большое количество строк, большое количество информации, как это посмотреть и как анализировать?

Для этого стали использовать программу Power Bi. В ней очень удобно выводить отчеты, удобно фильтровать по определенным зданиям, фильтровать по датам. И все это можно смотреть еще и в динамике.

Сказать, что наши ГИПы (главный инженер проекта), менеджеры проекта были довольны – ничего не сказать.

Пример визуализации данных по коллизиям в Power BI:

Cоздание своего плагина и переход на C#

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

И тут случился «переломный» момент в эволюции автоматизации в КРОК — мы поняли, что нам нужен свой плагин для Revit. Многие компании к этому приходят. Собственно, к этому пришли и мы вместе с нашим программистом. Он начинал с того, что писал небольшие макросы для Word и для AutoCAD на языке VBA. Сейчас он занимается полноценной разработкой на языке C#. Так у нас появился свой плагин.

Все началось примерно с такого диалога: «А давайте у нас будет своя вкладка на ленте, давайте мы сделаем там свою кнопку». «А что будет делать эта кнопка?». «У нас был скрипт, который обновлял пространство по помещениям, давайте его реализуем?». «Давайте!».

На самом деле это была своеобразная тренировка перед полноценным боем – разработкой плагина по работе с коллизиями.

Что было бы в принципе самым удобным для проектировщика при устранении коллизий? Не отчеты просматривать в виде табличек, а видеть эти коллизии непосредственно в Revit.

Мы пошли по пути наименьшего сопротивления. Взяли отчет, сделанный в Navisworks, и записали в базу данных. Затем сделали плагин, который считывает эту информацию из БД, понимает, в какой модели находится сейчас проектировщик, и фильтрует коллизии: оставляет только те, которые относятся к открытой модели. Например, инженер систем вентиляции будет видеть только коллизии вентиляции.

Плагин обрезает 3D вид и показывает непосредственно элемент, который пересекается. Таким образом проектировщики начали максимально результативно устранять коллизии, и их количество начало быстро сокращаться в проекте. Также мы сразу задумались о простановке статусов, чтобы проектировщик, когда устранит коллизию, отметил это, и ГИП видел их статус (отработанные, критические и т.д.).

 Пример работы нашего плагина по работе с коллизиями:

Аппетит приходит во время еды

Таким образом, мы коснулись ряда важных процессов при разработке плагина: начали взаимодействовать с БД с помощью языка C# и с помощью плагина обращаться к БД, записывать в нее различную информацию из моделей, читать; а также начали взаимодействовать непосредственно с элементами Revit.

Дальше у нас появились новые идеи: если делаем свой плагин, то можем делать что угодно, какие угодно инструменты… Но тут мы остановились и поняли, что всю эту работу нужно вести систематически, структурировано, правильно.

Первое – нужно отслеживать, кто вообще пользуется нашим плагином. Второе — какая у пользователя версия плагина установлена.

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

Также мы подумали, а зачем ГИПу видеть в Revit все инструменты в нашем плагине, которые нужны проектировщику? Возможно, ему нужна своя лента? Тут появилась идея, что у нас будут именно разные роли пользователей, и у них будут свои, персональные ленты в плагине. То есть наш плагин имеет разный вид под конкретную роль: у BIMщика – все инструменты, у проектировщика только для него, а у ГИПа только для контроля моделей.

Переезд на новую БД

И тут мы поняли, что нас начинает ограничивать выбранная компактная база данных SQLite. В том числе из-за того, что это локальный файл, и одновременный доступ к нему (если, допустим, весь департамент сядет устранять коллизии) будет затруднительным. Вдобавок размер этого файла тоже начал увеличиваться после того, как мы начали записывать туда отчеты (как было когда-то с Excel).

Ну и следующее взрослое решение – это переезд на отдельный мощный сервер, на котором развернута база данных SQL Server с полноценной структурой, очисткой, синхронизацией. 

Критическое обновление

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

Мы придумали способ, как поставить ‭«заплатку» на ленту нашего плагина, соответственно, у всех проектировщиков на панели плагина появилось предупреждение: «ребята, нужно обновиться». Таким образом, переезд с компактной базы данных на полноценный SQL сервер нам дался очень-очень легко.

Не делать автоматизацию ради автоматизации

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

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

Важно думать о масштабировании – мы начали вести всю нашу систему буквально с одного проекта, но теперь раскатали наши решения на все проекты, которые ведутся в департаменте. Практически все BIM-проектирование в КРОК ведется с использованием нашего плагина и базы данных.

Самый яркий момент в этой истории в том, что мы начали использовать БД для хранения больших объемов данных и взаимодействовать с ним через наш плагин в Revit. В BIM-проектировании работы с БД я мало где встречал, и считаю это большим упущением.