Современное проектирование уже невозможно представить без технологий информационного моделирования. BIM-модель здания собирается из тысяч компонентов — семейств, которые содержат не только геометрию, но и параметры для расчётов, спецификаций и автоматизации. Однако по мере роста инжиниринговой компании и увеличения числа заказчиков возникает фундаментальная проблема: как управлять библиотекой, когда у разных клиентов — разные требования к одним и тем же элементам?

Эта ситуация знакома любой крупной проектной организации. Для одного заказчика дверь должна иметь определённый набор параметров и уровень детализации, для другого — совершенно иной. Раньше приходилось создавать копии каталогов под каждого клиента. Это быстро превращалось в беспорядок: одни и те же BIM-компоненты дублировались по разным папкам, терялась актуальность, а на оптимизацию уходило большое количество времени. Специально для решения этой задачи в Family Manager, системе для управления библиотеками BIM-компонентов, появился функционал «Стандарты».

Привет, Хабр! Меня зовут Роман Заикин, я руководитель проекта градостроительного модуля платформы R2 в компании ПИК. Хочу рассказать, как и зачем мы создали собственный инструмент для архитектурно-градостроительного анализа, какие вызовы решали и каких результатов добились (и причём тут Unreal Engine).

Привет, Хабр!

Это — третья часть «Внедрения VMware Horizon глазами инженера». В этот раз разберёмся с сетевой связностью, из чего вообще состоит Horizon и как именовать весь этот «зоопарк».

В предыдущих частях:

Часть 1.

Часть 2.

Сетевое оборудование

В прошлой статье я обещал слегка окунуться в мир сетевого оборудования.

Закрыть тему vSAN, не разобравшись со схемой сети, невозможно. Предполагается, что читатель уже знаком с базовыми принципами сетевой модели ESXi/vSphere — иначе только этой теме пришлось бы посвящать отдельный цикл статей.

Существует множество подходов к построению сети для кластеров VDI. Мы рассмотрим один из практических вариантов — тот, который используем сами в ПИК, — и на его основе набросаем типовую схему подключения ESXi к коммутаторам. Нам потребуется как минимум три отдельных сети. Две из них (для ВМ и vSAN) должны быть высокоскоростными — 10, а лучше 25 гигабит.

Проблема: 2 000+ проектировщиков тратят 15–30 минут на поиск ответа в 120+ инструкциях Confluence.

Решение: ИИ-помощник на основе архитектуры RAG, который отвечает за несколько минут.

Результат: время поиска сократилось до 5 минут, адаптация персонала — с 2–4 недель до 3–5 дней.

Привет, Хабр! Меня зовут Максим Курбатов, я — руководитель продукта BIM Inspector в ПИК Digital. Сегодня расскажу, как мы решили одну из непростых задач в BIM-автоматизации — помогли новому пользователю начать работать с системой за дни, а не за недели.

Привет, Хабр! Меня зовут Дарья Попова, я работаю в отделе внедрения технологий информационного моделирования в компании ПИК. 

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

На данный момент у нас есть линейка продуктов, которая состоит из Family Manager, BIM Inspector, PikTools, Робот R2, BIM Data Service и PikCheckUp. Все инструменты связаны между собой и дополняют друг друга, но в то же время могут работать автономно. Прежде чем перейти к части про междисциплинарный продукт, а именно о том, что он включает в себя, стоит кратко упомянуть о PikTools и BIM Inspector, так как продукт МД непосредственно с ними связан. 

PikTools — набор инструментов для автоматизации проектирования в Revit, Civil 3D и AutoCAD, которые ускоряют и упрощают размещение элементов, заполнение параметров, выпуск документации. 

BIM Inspector — сервис для проверки данных в модели на соответствие стандартам проектирования и BIM-требованиям. Проверки выполняются фоном на сервере, ошибки отображаются в интерфейсе ПО с инструкциями для исправления.

Полное описание экосистемы можно найти в статье «Экосистема ПИК. История формирования».

Привет, Хабр! Меня зовут Андрей Лаврентьев, я — аналитик в группе развития технологий информационного моделирования инженерного направления в ПИК.

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

Когда в компаниях внедряют BIM-процессы (в частности, проектирование в Revit), нередко можно услышать расхожую фразу о том, что информационная модель позволяет легко, «одной кнопкой», выдавать из себя точные объёмы изделий, материалов и оборудования.

На деле это оказывается правдой только наполовину. Лёгкой выдаче точных объёмов предшествует кропотливая работа проектировщика и BIM-специалиста. Важную роль играет их внимание к качеству семейств и моделирования с самых ранних этапов, к параметризации элементов в модели и к соблюдению технологии.

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

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

Привет, Хабр! Меня зовут Дмитрий Гайдамак, я руковожу отделом ИТ в дирекции автоматизации проектного блока ПИК. Это — вторая статья из цикла о внедрении VDI на крупном предприятии (первую статью, с предысторией, уже публиковали в блоге).

Пришло время разобраться с самой сложной частью запоминающих устройств — с дисками. Здесь на сцену выходит vSAN со своими особенностями.

Тонкости сайзинга хранилища: почему vSAN

Первый кластер в нашей пилотной конфигурации VDI состоял всего из двух серверов и был рассчитан примерно на 80 рабочих мест. При скромных начальных требованиях к виртуальным машинам мы могли бы спокойно разместить их данные на какой-нибудь простой СХД (вариант с локальными датасторами даже не стоит рассматривать как недостаточно гибкий). Но мы понимали, что рано или поздно придётся масштабироваться — и вот тут начали появляться нюансы.

На тот момент мы не знали, какое количество операций ввода-вывода будет генерировать рабочая станция VDI в течение дня, и просто поверили на слово интегратору, посчитавшему для нас нужные цифры. Сейчас могу с уверенностью сказать: ферма из ста рабочих станций, где работают проектировщики, способна сгенерировать 15–25 тысяч IOPS на чтение и примерно столько же на запись (на бэкэнде vSAN с Parity FT=2, что близко к RAID 6 на СХД). Особенно утром, когда все одновременно открывают проекты.

Если экстраполировать, становится ясно, какую нагрузку приходится выдерживать датастору каждый день. В случае с СХД сотня пользователей не вызовет проблем, но тысяча уже окажется не по зубам железу начального уровня, и придётся обзавестись новой, более серьёзной СХД.

Привет, Хабр!

Меня зовут Альбина Алдабергенова, я – руководитель продукта BIM Data Service в ПИК.

Продолжаем серию статей об экосистеме ПИК. В предыдущих материалах мы уже рассказали историю ее формирования и разобрали несколько инструментов: Family Manager, PikTools и BIM Inspector.

Сегодня расскажу о продукте BIM Data Service, который превращает «цифровой двойник» здания в единый источник общих данных. А также о том, как мы автоматизировали один из самых непростых процессов в строительстве — расчёт сметы.

Привет, Хабр! Познакомимся? Меня зовут Адель Матвеева, я – координатор по технологиям информационного моделирования в команде информационного моделирования архитектурного направления в ПИК. Сегодня хочу рассказать о нашем подходе к работе с перемычками.

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

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

— дверь сдвинули — перемычка осталась на месте;
— проём удалили — перемычка осталась в проекте и в ведомостях;
— изменилось примыкание — стратегия опирания должна быть другой, но в модели осталась старая.

Как правило, ошибки всплывают поздно — после выпуска документации или уже на стройке. Настоящая ценность перемычек в Revit — не в быстрой расстановке семейства, а в том, чтобы принять верное решение и сохранить его актуальным до выпуска рабочей документации. Ручной выбор по каждому проёму не масштабируется: после изменения в модели его приходится заново проверять и пересобирать. В итоге время уходит не на проектирование, а на переделки.

Мы в команде прошли путь от классического подхода «двери/окна с вложенными перемычками» к инструменту «Перемычки», который автоматизирует именно выбор по стандарту и контроль актуальности, а не только расстановку.

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

Привет, Хабр! На связи команда разработки продукта PIKTools Генплан.

Хотите узнать, как генпланисту оперативно создавать, редактировать, оформлять и проверять генеральные планы? Как получать рабочую документацию строительства, сократить трудозатраты на ее разработку? Как наш продукт PIKTools Генплан помогает в этом?

Если да, тогда приготовьте себе кофе и погнали — мы продолжаем наш рассказ. Если вы пропустили вводную статью про продукт, советуем начать с нее. Сегодня речь пойдет о модуле «Озеленение». Расскажем о том, из чего он состоит, а также какие прикладные задачи и проблемы он решает.

Привет, Хабр! Меня зовут Артур Ишмаев, я руководитель отдела внедрения и развития нейросетей в дирекции цифровых инноваций и ИИ в ПИК. 

В первой части статьи я подробно разбирал работу Data-driven Interior Plan Generation for Residential Buildings (2019) — одного из первых проектов, пытающихся воспроизвести процесс проектирования дома с помощью нейронных сетей, а именно с помощью набора свёрточных моделей.

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

Начну я с инструмента WallPlan, который стал важным промежуточным этапом в эволюции генеративных планировочных систем.

Привет, Хабр!

Меня зовут Дмитрий Гайдамак. В ПИК я отвечаю за серверную инфраструктуру для проектировщиков и их техническую поддержку. В этом цикле статей я расскажу, как мы внедряли и развивали Omnissa (ранее — VMware) Horizon. И сделаю это глазами инженера, а не менеджера.

Цикл будет полезен ИТ-специалистам — как тем, кто ещё сомневается, с чего вообще начать внедрение, так и тем, кто уже рисует первые наброски архитектуры под себя.

Постепенно мы разберём:

• соображения на тему подбора железа для VDI;

• базовые понятия vSAN и его сайзинг под свои нужды;

• компоненты всей будущей системы VDI;

• балансировку нагрузки и организацию отказоустойчивости решений Omnissa;

• администрирование системы: золотой образ, клоны, пулы;

• доставку приложений AppVolumes;

• возможности кастомизации рабочих мест VDI;

• мониторинг Horizon;

• соображения на тему безопасности stateless рабочих мест;

• брендирование и настройку веб-портала Horizon.

Всё это я постараюсь дополнить реальными случаями из опыта эксплуатации VDI у нас в ПИК. Но всему своё время. Начнём с краткой предыстории.

Привет, Хабр, и с наступающим Новым годом! Меня зовут Станислав Пуртов, я – заместитель директора по автоматизации проектного блока в ПИК. 

В этой статье хочу рассказать, как мы стали компанией удаленного проектирования.

Для начала давайте разберемся, что это такое, ведь под «удалёнщиком» до сих пор понимают разное. 

Для кого-то это подрядчик, который не состоит в штате и работает в своем режиме, а ещё для него редко появляется какое-то дело, или мы вовсе можем забыть про этого человека на полгода.

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

Но, важный момент – «офиса» как физического пространства  у нас нет. Вся наша команда – удалёнщики – или также это называют «распределённая команда», и в этой статье я как раз и расскажу, как мы ею стали.

Привет, Хабр!

Меня зовут Александра Касаткина. Я ведущий координатор по технологиям информационного моделирования в группе BIM-поддержки в команде ПИК Digital.

Ранее руководитель группы Александра Васильева рассказывала, как устроен сервис BIM-поддержки и как мы решаем проблемы до их появления в статье «BIM-поддержка в ПИК: как сервис решает проблемы до их возникновения». Но что делать, если проблема есть, а решения в базе знаний у нас нет? Разберем в этой статье. В конце статьи приложим чек-лист с алгоритмом действий при решении нетиповых кейсов.

Почему важно не просто «починить», а понять корень проблемы

В работе с Revit даже самая продуманная методология не застрахована от неожиданных сбоев — особенно когда речь идет о нетиповых задачах, которых нет во внутренних инструкциях. В BIM-поддержке ПИК мы сталкиваемся с такими кейсами регулярно. И наш подход — не просто быстро «залатать дыру», а разобраться, почему она появилась. Глубокое понимание причины позволяет не только решить текущую проблему, но и предотвратить десятки подобных в будущем. В этой статье мы поделимся практическими примерами таких ситуаций и тем, как мы их превращаем в устойчивые решения.

Реальные кейсы: что пошло не так, и как мы это решили

Мы разобрали четыре нетиповых случая из практики с описанием проблемы, хода расследования и главного вывода.

Максим Курбатов, руководитель продукта BIM Inspector (ПИК Digital)

В современном проектировании BIM-модели становятся всё более сложными, а требования к их качеству — строже. Проверка соответствия модели внутренним стандартам, ГОСТам и регламентам — неотъемлемая часть рабочего процесса. Однако ручная или полуавтоматическая проверка быстро превращается в узкое место: десятки правил, сотни элементов, часы ожидания результата.

В ПИК мы столкнулись с этой проблемой на практике. Когда проверка одной модели стала занимать до часа, стало ясно: подход «нажми и жди» больше не масштабируется. Мы задались целью не просто ускорить проверку, а полностью исключить её из активного участия проектировщика. Так родилось решение, которое мы называем «умные фермы» — распределённая система фоновой автоматической проверки BIM-моделей.

Привет, Хабр! Меня зовут Артур Ишмаев, я — руководитель отдела внедрения и развития нейросетей в девелопере ПИК. 

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

Вводная часть

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

Задача генерации плана дома

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

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

Привет, Хабр!

На связи команда BIM-координации в ПИК, ранее мы уже рассказывали о себе в статье «Мы создали сервис для координации BIM-моделей. Как он работает?».

Сегодня мы расскажем о одном из важных инструментов в нашей работе, без которого не обходится ни один рабочий день — CheckUP.

CheckUP — это система автоматизированной проверки BIM-моделей на наличие коллизий, основанная на фоновой проверке средствами Navisworks и обработке результатов в среде Revit.

Привет, Хабр!

Меня зовут Александр Гокканен, я координатор по технологиям информационного моделирования в команде ПИК Digital.

В этой статье я расскажу, как мы, используя BIM-технологии, изменили процесс проектирования и оформления комплектов КЖС (конструкций железобетонных сборных) в ПИК.

Предпосылки

До внедрения BIM-технологий все процессы подготовки комплектов чертежей выполнялись вручную в системе AutoCAD. На плечи проектировщиков ложились абсолютно все задачи: размещение конструкций на плане, отрисовка необходимых торцов у конструкций, отрисовка проёмов и узлов, внесение изменений, а также проверка перед выпуском габаритов. 

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

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

Привет, Хабр! На связи команда разработчиков R2 из ПИК Digital. Сегодня мы расскажем о нашей платформе на базе движка UE, на которой мы занимаемся разработкой модулей, автоматизирующих  различные процессы девелопмента.

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

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

Платформа R2 — это попытка системно решить эту проблему, охватив часть процессов девелоперского цикла модульными инструментами, которые работают с моделью данных и интегрируются с привычными САПР-системами.

Ранее мы уже рассказывали о том, как с помощью сервиса R2 можно использовать метод инсоляционного массинга — то есть, проверять размещение многоэтажной жилой настройки на участке с учётом требований инсоляции.

Почему Unreal Engine?

В основе платформы R2 лежит движок Unreal Engine — решение, которое может показаться неожиданным для сферы проектирования недвижимости. Однако именно производительность этого движка и его способность работать с большими объемами данных стали ключевыми факторами выбора.

Привет, Хабр!

Меня зовут Рудольф Караджаян, я руковожу направлением информационного моделирования наружных сетей в ПИК.

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

Принципы автоматизации для других разделов (связь, теплоснабжение, освещение) мы разберём в следующих публикациях.