Привет, Хабр!
Меня зовут Александр Гокканен, я координатор по технологиям информационного моделирования в команде ПИК Digital.
В этой статье я расскажу, как мы, используя BIM-технологии, изменили процесс проектирования и оформления комплектов КЖС (конструкций железобетонных сборных) в ПИК.
Предпосылки
До внедрения BIM-технологий все процессы подготовки комплектов чертежей выполнялись вручную в системе AutoCAD. На плечи проектировщиков ложились абсолютно все задачи: размещение конструкций на плане, отрисовка необходимых торцов у конструкций, отрисовка проёмов и узлов, внесение изменений, а также проверка перед выпуском габаритов.
Например, в процессе маркировки панелей проектировщик своими руками прописывал длинную марку, включающую префикс, габариты панели, сведения о здании, корпусе и другое. Также подсчитывались и настраивались вручную спецификации. Кроме того, получая сведения от смежных разделов, проектировщики собственноручно переносили информацию из одного файла в другой.
Время показало, что такой способ разработки комплекта ведёт к увеличению рутинной работы, а также может приводить к ошибкам из-за человеческого фактора. Всё это подтолкнуло нас к введению автоматизации в проектах.
Первые шаги в автоматизации процессов. Стык CAD и BIM
Первым шагом в автоматизации процесса моделирования в AutoCAD стало создание динамических блоков панелей с разными типами торцов, проёмов, закладных деталей и других элементов. Это упростило работу, но полностью проблемы не решило. Какие вопросы оставались нерешенными:
Габариты панелей всё равно приходилось настраивать вручную, растягивая блоки так, чтобы не испортить значения других параметров.
В блоках панелей были заложены только определённые типы торцов, и при появлении новых сочетаний проектировщикам приходилось дорабатывать их самостоятельно.
Закладные детали накладывались друг на друга, а отметки проставлялись вручную.
Появлялись новые панели, процесс моделирования которых был значительно сложнее старых (и как покажет время, моделировать их оказалось проще в Revit, нежели в AutoCAD).
Чтобы снизить нагрузку на проектировщиков, мы разработали две базы: базу панелей и базу монтажных планов.
База панелей использовалась для выгрузки сведений о панели и присвоения ей марки. После запуска плагина AutoCAD формировался JSON-файл со всеми сведениями о панели и сохранялся в отдельную папку на сетевом диске. Но со временем база сильно выросла, и обработка одной панели стала занимать уже не 2 минуты, а полчаса, что сильно увеличило трудозатраты.
База монтажных планов применялась для передачи заданий в отдел разработки архитектурных решений (АР). Плагин формировал JSON-файл со всеми панелями на плане, далее отправлял его по электронной почте архитекторам, которые через BIM-координаторов загружали его в общую базу данных.
Постепенно мы автоматизировали и другие процессы. Например, получение колористических индексов (плагин обращался к заданию на колористику от АР и автоматически заполнял колористические индексы) и создание спецификаций (спецификаций панелей, групповых спецификаций, выборки узлов, спецификаций стальных марок и материалов).
Тем не менее, ведомости расхода стали и материалов по-прежнему приходилось рассчитывались вручную в Excel.
Переход на BIM. Технология Precast
Следующим шагом в автоматизации стал переход на Revit и разработка плагинов уже для него. Новая технология получила название Precast (от англ. precast concrete — сборный железобетон). Она включает в себя:
шаблоны для создания файлов;
группу плагинов на базе Revit, которую мы называем PikPrecast (ниже скриншот с панели инструментов);
базу панелей и базу монтажных планов;
разработанные семейства, которые хранятся в отдельном сервисе управления BIM-компонентами Family Manager (подробнее про этот сервис можете прочесть в статье «Экосистема ПИК. Развитие Family Manager»);
инструкции для работы с технологией.
Надо сказать, что работа технологии Precast строится, в том числе, на слаженном взаимодействии между смежными командами. Каждый новый проект начинается с создания новых скоординированных между собой файлов. Их по заявке проектировщиков готовят координаторы адресных объектов. На этом этапе команда координации:
создаёт новые папки и файлы на Revit-сервере;
передаёт координаты файлам.
Если в процессе разработки комплектов возникают проблемы с ПО, плагинами или техническими ресурсами, их решают BIM-поддержка и техническая поддержка.
Новые конструктивные решения могут требовать разработки новых или доработки существующих семейств. В таком случае заявка подаётся через Family Manager в команду по разработке семейств (подробнее про этот сервис можете прочесть в статье «“Фабрика семейств”: как мы создали эффективный конвейер предоставления BIM-семейств и упростили жизнь проектировщикам»).
Что касается развития технологии и инструментов автоматизации, то за это отвечают как команда технологий информационного моделирования (ТИМ), так и руководитель отдела проектирования, который выполняет роль функционального заказчика.
После формирования запроса на доработку или разработку инструмента, а также в случае его внутреннего инициирования командой, в ТИМ заводится задача: описываются необходимые вводные, совместно с заказчиком определяется приоритет, и задача включается в план.
Следующим этапом после разработки идёт тестирование, затем написание документации. Наконец, после ревью кода происходит релиз новой версии.
Помимо этого, команда дорабатывает шаблон и отвечает за BIM-требования к моделям КЖС (крупноразмерные железобетонные сводчатые конструкции).
Команда проектировщиков КЖС тесно взаимодействует и со смежными отделами. Например, задание от проектировщиков АР является основным для комплекта КЖС и направляется ещё до задания на монолитные конструкции (монолит). В ответ проектировщики КЖС передают в АР задание на колористику — монтажные планы с указанием расположения осей и конструкций и отметкой уровней. Затем АР выдаёт КЖС колористические индексы для панелей, которые согласовываются перед подписанием комплекта. Далее КЖС выдаёт проектировщикам КР (конструктивных решений) задание на монолит. Они отрабатывают его и присылают модель на согласование. Если появляются какие-то расхождения, они исправляются по месту.
Планы в формате IFC направляются в систему Aspa, оттуда данные забирает команда «Префаб Технологий». Затем отдел автоматизации проектирования обрабатывает задание и отдаёт проектировщикам для разработки панелей. В конечном счёте задание на панели отправляется на завод для их производства.
Теперь давайте подробнее остановимся на команде проектирования КЖС и разберёмся, чем именно она занимается, а главное, как она это делает в Revit.
Моделирование
Помните, в разделе про первые шаги автоматизации я рассказывал про динамические блоки с панелями и их компонентами, и про проблемы, которые возникают при таком подходе?
Так вот, в рамках технологии КЖС мы разработали в Revit семейства панелей КЖС. Особое внимание было отведено торцам – предусмотрено 9 различных вариантов, которые, при необходимости, можно переключать внутри семейства. Это значительно оптимизирует процесс моделирования, так как пользователям больше не надо создавать вручную нужную панель из нескольких динамических блоков.
Для удобства моделирования панели теперь строятся по линии, то есть проектировщик чертит линии, размещает семейство, выбирая нужные отрезки, по которым оно должно быть расставлено, и панели автоматически появляются. Проблем с изменением габаритов, как это было раньше, больше нет.
Затем, используя разработанные семейства узлов, термовкладышей (элементов для теплоизоляции), оконных проёмов, проектировщик моделирует соответствующие элементы в Revit.
Кстати, благодаря семействам узлов в Revit удалось уйти от размещения деталей друг на друге и ручного ввода отметок. Теперь отметки задаются автоматически, а результат всегда можно проверить на 3D виде.
По оценкам наших проектировщиков, это упростило процесс и сильно добавило моделированию гибкости. Но есть и обратная сторона — необходимо внимательно следить за всеми параметрами семейств в проекте, чтобы избежать ошибок.
А во что все эти панели собираются? Изначально все решения КЖС делятся на три комплекта:
типовые этажи (КЖС1);
технический этаж (КЖС2);
кровля (КЖС3).
В зависимости от различий на типовых и техническом этажах комплекты могут делиться внутри себя (например, КЖС1.1, КЖС1.2, КЖС1.3 или КЖС2.1, КЖС2.2.). Дополнительно происходит деление по секциям. Таким образом, в файле содержатся конструкции только одной секции, размещенные только на одном уровне. При этом в файле этажа подготавливаются все поэтажные планы, где эти конструкции используются. Комплекты разрабатываются последовательно от типовых этажей к кровле. Таким делением мы уходим от медленной работы в файле при его открытии и при внесении в него изменений.
Для оформления всего комплекта создаётся файл-сборка. В него подгружаются в виде связанных файлов все комплекты каждой секции и копируются на те уровни, где конструкции повторяются (перекрытия моделируются номинально). Внутри файлов все элементы для удобства распределены по рабочим наборам. Так, мы сначала моделируем комплекты по отдельности, а затем уже готовые конструкции загружаем в файл сборки, где и производим оформление.
Дополнительно мы подготовили два универсальных шаблона на все случаи жизни (для файла сборки и для файла этажа). В них уже есть преднастроенные листы для каждого комплекта.
Работа с базой панелей
Для начала давайте разберёмся, какие есть базы и для чего мы их используем:
1. Для хранения семейств Revit — база данных FamilyManager.
2. Для маркировки и выгрузки панелей — база данных панелей.
3. Для выдачи задания на колористику — база данных монтажных планов.
При переходе на Revit мы доработали технологию взаимодействия с базой панелей. Теперь она работает следующим образом:
Проектировщик запускает плагин «Выгрузка».
«Выгрузка» сравнивает панели в файле с теми, что уже есть в базе.
В соответствие с их характеристиками назначается марка.
Если подходящая марка не находится, то с одобрения проектировщика (галочка «Создавать панели») плагин записывает панель в базу данных и присваивает ей марку.
Мы не только адаптировали под Revit уже существующий функционал, но и отказались от хранения папок на сетевых дисках, что ускорило обработку панелей в файле.
Также мы разработали новые плагины: «Подобные панели» и «Сравнить с эталоном»:
Плагин «Подобные панели» ищет панели, подобные той, что выбрал проектировщик, и размещает в проекте. Для этого мы доработали задание точности совпадения закладных деталей и проёмов. Теперь можно находить не идеальный мэтч, а именно подобную панель.
Плагин «Сравнить с эталоном» аналогично ищет панель, подобную той, что выбрал проектировщик, только вместо размещения выводит уведомление о соответствии/несоответствии панели базе данных.
Работа с базой монтажных планов и обмен заданиями с АР
Для обмена заданиями с АР используются плагины «JSON панели», «JSON оси» и «Монтажный план». Соответственно они выгружают панели, оси, уровни, марки и расположение панелей в отдельный сервис, к которому обращаются архитекторы.
Также у проектировщиков КЖС есть плагин «Получить колористику», с помощью которого они получают колористические индексы для каждой панели. Эти индексы прописываются у каждой панели. Так как файлы этажа копируются в файле сборки, то для одной панели заполняются сразу индексы для всех этажей, где данный файл этажа используется.
Пример колористических индексов в панели
При маркировке панелей мы используем соответствующий этажу типоразмер семейства марки, который считывает значение колористического индекса нужного этажа.
Обмен заданиями с отделом разработки монолита
Отдел разработки монолитных конструкций в качестве исходных данных получает расположение монолитных пилонов, контуры плит перекрытий и расположение закладных деталей в монолитных конструкциях, к которым крепятся навесные фасадные панели.
Эта информация передаётся в формате .rvt и дополняется актуальным альбомом узлов. Для получения задания на монолит в файл КЖС в виде связи подгружается файл с монолитными конструкциями. Для копирования элементов модели из файла применяется функция «Копирование/мониторинг».
Такой способ позволяет автоматически отслеживать изменения в монолитных конструкциях и оперативно вносить их в файлы КЖС.
Спецификации
С переходом в Revit открылась новая сущность — «Ведомости/Спецификации». Туда переехали групповые спецификации, выборки узлов, спецификации стальных марок и материалов.
А для формирования «Ведомости расхода стали» (ВРС), «Спецификации панелей» и «Ведомости объёмов работ» (ВОР) мы стали использовать плагин «Спецификации». Он собирает информацию из параметров в семействах и представляет её в нужном нам виде.
Также этот плагин позволяет быстро создавать и обновлять ВРС, ВОР и Спецификации панелей с разбивкой на комплекты типовых этажей, технического этажа, кровли и с опцией выбора связанных файлов, которые нужно обработать. Также есть возможность экспорта файлов в Excel.
Как думаете, сколько бы времени заняло формирование всех этих спецификаций у проектировщика вручную?
Для ВОР также предусмотрена настройка разделения по строениям и секциям, а ещё создание дополнительной таблицы с выборкой площади.
Полученные ВРС, ВОР и «Спецификации панелей», по сути, являются графическими элементами, так как находятся в заголовках спецификаций, а не собираются из файла. Однако, это даёт дополнительную гибкость в плане оформления, обработки и представления данных.
Оформление
Одним из направлений развития линейки плагинов PikPrecast в 2025 году стала разработка нового инструмента — «Автооформление КЖС». В рамках него мы реализовали модуль «Компоненты чертежа», позволяющий выравнивать на листах расположение планов и их заголовков по образцу, указанному проектировщиком. Это значительно упростило процесс проверки чертежей.
При проверке комплекта в PDF проектировщику важно, чтобы при переходе с одного листа на другой расположение плана и его заголовка сохранялось. Это позволяет сразу заметить отличия и не тратить время на выравнивание. Ранее проектировщик вручную смещал планы и заголовки и при проверке постоянно отвлекался на изменение их положения. Теперь первый процесс автоматизирован, а второй полностью исключён.
В скором времени мы добавим ещё два модуля:
«Нумерация листов» — для автоматического пакетного расставления номеров листа, в том числе, с возможностью группировки листов.
«Контур перекрытия» — для рисования границы перекрытия. Его необходимость обусловлена тем, что само перекрытие должно быть скрыто на плане, при этом граница нужна для оформления планов.
Итоги и планы
Нашим главным достижением стала автоматизация ключевых процессов при выполнении комплекта — заполнение марок у каждой панели, расположение компонентов чертежей, выгрузка заданий, создание и обновление спецификаций и проверка панелей на соответствие базе. Представьте, сколько времени это занимало бы, если бы эти процессы всё ещё оставались ручными?
Главное — мы научились преодолевать трудности, отладили процессы и фактически создали свой рецепт автоматизированного BIM-счастья.
Сейчас перед нами стоят следующие вызовы:
обмен заданиями между КР (монолит) и КЖС для контроля соответствия геометрий в моделях;
обмен заданиями между АР и КЖС для контроля соответствия геометрий в моделях;
автоматическая расстановка закладных деталей по заданию от КР (монолит) и проверка расположения;
оптимизация структуры хранения данных о панелях и монтажных планах;
доработка шаблонов для большей автоматизации оформления;
автоматическая проверка модели КЖС перед выдачей комплекта.
Параллельно мы исправляем возникающие баги и проблемы, совершенствуем инструменты и добавляем новые функции.