Будущее строительного проектирования и инженер по требованиям

Автор – генеральный директор ООО «РОСЭКО-СТРОЙПРОЕКТ» Александр Лапыгин

BIM, алгоритмы, нейросети, и инженер по требованиям.

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

На днях в самом активном чате о BIM в Telegram (ссылку думаю все знают) состоялся очередной холивар на тему будущего строительного проектирования. Началось всё с опроса Артёма Бойко на тему «какая специальность будет «главной» в проектировании будущего» (и там вопрос начался с обсуждения смет, и того, будет ли определять содержимое модели и его структуру сметчик, BIM-менеджер или инженер-проектировщик, если кратко). А дальше я немного подлил масла в огонь, упомянув ИИ и нейросети. И понеслось…

Вопросы, как и всегда: будет ли создана условная Красная кнопка «Создать проект», и соответственно будет ли нужен человек в роли проектировщика, и если да – то с какими функциями.

Чтобы зафиксировать свою позицию, напишу и здесь тоже – тут можно чуть длиннее чем в Telegram, то есть как раз так как я люблю..)) Прошу воспринимать написанное ниже как идеалистическую фантазию, которая, однако, мной воспринимается как вполне возможный путь развития технологии строительного проектирования – если не целиком (я вряд ли предскажу на 100% правильно, как мы будем проектировать в будущем), то по крайней мере в определённых фрагментах.

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

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

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

Решать более сложные задачи численными методами вручную практически невозможно (нужно перемножать очень большие матрицы), и здесь студенту уже помогают компьютеры (FEM и CFD, например). Однако в них многое зависит от корректности ввода данных, и в случае ошибочного ввода (забыли прикрепить колонну к перекрытию, создали элемент с нулевой жёсткостью, задали шарнир вместо жёсткой заделки, продублировали один элемент дважды в одном месте) программа всё посчитает и покажет неверный результат. Чтобы контролировать корректность полученного результата, студент (и уже инженер) как раз применяет свой опыт качественного решения задач, который научил его понимать примерно, от каких загружений должны быть какие эпюры. И этот опыт ему подскажет, что нелогичное распределение напряжений – следствие ошибки, и расчётную схему нужно поправить для повторного расчёта. (Это, кстати, часто бывает поводом для отдельного холивара – что важнее, уметь пользоваться инструментом, к примеру конкретной расчётной программой, или иметь опыт решения задач вручную, и понимать, где программа посчитала «не то». Я считаю, что сейчас проектировщику необходимо в равной степени знать и теорию своей специальности, и практику с применением различных программ).

Дальше студент (а чаще уже инженер, начинающий карьеру) изучает различные программные комплексы – как для расчётов (FEM, CFD, или ещё каких-то в зависимости от специальности), так и для отображения результатов этих расчётов – конкретных проектных решений. Раньше это были CAD продукты, теперь – BIM (что бы мы в это понятие ни вкладывали: здесь есть место ещё для одного холивара, начинать который мы, конечно, не будем).

Фактически ему нужно научиться корректно использовать функционал ПО для создания моделей, которые нужны для различных целей: расчётная модель (FEM), визуальная модель (3D), информационная модель (BIM), организационная модель (4D), стоимостная модель (5D), эксплуатационная (6D), предиктивная (7D) и другие частные случаи. В идеальном случае это совокупность объектов и процессов, которые имеют взаимосвязи и общие параметры. Пока нет единой платформы, которая могла бы вмещать все эти модели, ссылающиеся на единую базу данных. Поэтому для каждой модели используется своё ПО, и некоторые модели через API могут синхронизироваться друг с другом. Но в общем процесс эволюции программ ведёт ко всё большей интеграции моделей друг с другом, асимптотически приближаясь к идеальной картине единого пространства моделирования.

Итак, мы разобрались, что именно может делать инженер в проекте. Теперь кратко о том, ЗАЧЕМ он это делает.

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

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

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

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

И, для любого проекта, кроме требований, исходящих от будущего пользователя, есть требования регуляторов – государственных или даже надгосударственных (как МАГАТЭ в примере с АЭС). Это СП, СанПиНы, ФЗ, ПП РФ, ГОСТы, стандарты ISO, Еврокоды, Правила землепользования и застройки, Условия присоединения к инженерным сетям и прочие подобные документы. Для простоты будем считать, что вся физика объекта (чтобы здание стояло и не упало, микроклимат внутри был приемлемый, вода дошла до верхнего этажа с нужным напором и т.п.) учтены именно этими требованиями (как это сделано в СП «Нагрузки и воздействия» с учётом ГОСТ «Надёжность строительных конструкций» и СП «Стальные конструкции», в которых непосредственно и приведены формулы расчётов), и отдельно их учитывать не нужно. Для единичных уникальных проектов делаются научные исследования, по результатам которых формируется СТУ – просто ещё один документ со сводкой дополнительных требований.

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

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

Теперь кратко опишем, какие действия предпринимает инженер (инженеры), чтобы в соответствии со всеми этими требованиями запроектировать будущий объект.

  1. Генерация концепции-модели. Как правило в конце этапа есть несколько вариантов концепции.
  2. При наличии нескольких вариантов каждый проверяется на соответствие применимым требованиям, и находится оптимальный. Оптимальность здесь может определяться по различным факторам, смотря какие параметры для заказчика проекта являются наиболее приоритетными (минимальная площадь застройки, максимальное эстетическое совершенство, или минимальный строительный объём, или минимальная высота - любой из параметров, который может быть определён на этом этапе). В конце этапа мы имеем один выбранный вариант концепции-модели.
  3. Детализация выбранной концептуальной модели методом итераций:

    A. Формирование внутреннего требования одной дисциплиной

    B. Получение этого внутреннего требования другой дисциплиной

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

    D. Моделирование принятого решения

    E. Расчёт по созданной модели (или качественная оценка эстетической составляющей, если мы, например, говорим про визуализационную архитектурную модель) – то есть проверка на соответствие внешним требованиям

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

    G. Корректировка модели по результатам расчёта и повторный расчёт – пока он не покажет соответствие модели требованию

    H. Выдача внутреннего требования на создание модели в смежную дисциплину

    Этот процесс во всём проекте занимает бОльшую часть времени, так как много и смежных дисциплин, и видов моделей, и пока они все между собой взаимосвязываются в основном вручную. Результатом этого этапа является совокупность всех необходимых для реализации видов моделей по всем дисциплинам, входящим в проект.
  4. При желании заказчика на этом этапе тоже может быть выполнено по несколько вариантов некоторых моделей, чтобы можно было выбрать оптимальный вариант, исходя из приоритетных параметров. Например, по стоимостной и эксплуатационной моделям можно настроить баланс между CAPEX и OPEX объекта, а по модели фасада здания – баланс между долговечностью и стоимостью (не забывая также и об эстетике). По конструктивным моделям можно выбрать более экономичный вариант – монолит или металлокаркас с огнезащитой, или, например перекрытие - балочное, безбалочное, или с капителями. Однако на этом этапе вариантное проектирование уже гораздо дороже, так как для качественного сравнения моделей каждый вариант нужно проработать достаточно детально, поэтому на практике вариативность здесь встречается нечасто. Как правило, её заменяют отсылкой к опыту – либо самого проектировщика, либо техзаказчика, либо будущего подрядчика. Насколько этот опыт релевантен и вообще имеется – в большом числе случаев вопрос открытый 😊. В общем, если этот этап есть, его результат – выбранный вариант комбинации моделей, оптимально соответствующий приоритетным параметрам.
  5. Выбранный вариант проверяется на соответствие требованиям. Исходным, внешним и внутренним. Это тоже итеративный процесс, так как дисциплины связаны не попарно, а практически каждая с каждой, и на предыдущем этапе эти взаимосвязи не всегда могли быть сразу учтены. Простыми словами – это процесс проверки на коллизии, а также контроль соответствия проектных решений ТЗ и нормативам. В основном этим занимаются Главспецы по разделам, ГИП и BIM-координатор. Результат этапа – внутренне непротиворечивая совокупность всех видов моделей по всем дисциплинам проекта, соответствующая внешним и исходным требованиям.
  6. Оформление результата и передача заказчику в той форме, в которой от него ожидает проект будущий подрядчик строительства. В случае с BIM пока это оформление на листы, выпуск в pdf (где-то тут упомянем ЭЦП как механизм придания юридической значимости этим документам). В случае если подрядчик ожидает получить в работу некоторые модели – их тоже нужно подготовить к выдаче, так что, если когда-то pdf окажется не нужен, на этом этапе останется такая вот чистка моделей и подписание их ЭЦП.

Вроде ничего не забыл?

А теперь к тому, ради чего вообще весь этот текст.

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

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

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

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

Ещё один вид деятельности – это творчество, для тех объектов, где важна красота. Можно отдать дизайн на откуп нейросетям, и мы такие примеры уже знаем (https://www.artlebedev.ru/ironov/), но всегда найдутся желающие получить дизайн авторский, «с душой». И спрос таких клиентов будут удовлетворять вполне живые архитекторы и дизайнеры интерьеров, с использованием для остальных дисциплин инструментов автоматического проектирования.

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

Проблем на пути создания этой «большой красной кнопки» несколько.

  • Все нейросети нужно обучать на достаточно больших сетах хорошо размеченных данных. Сеты кто-то должен собрать, а данные – разметить. Если сбор данных ещё можно выполнить руками пользователей, дав им возможность грузить свои проекты в облачные сервисы (как это делает сейчас, например, тот же Autodesk со своим Construction Cloud), то разметить их подходящим образом – не факт что получится так же легко. Данных много, и классифицируют их все по-разному. А разметка вручную требует огромного времени, причём если с разметкой изображений котиков могли справиться любые добровольцы или студенты-практиканты, то размечать проектные данные должны специалисты, инженеры, которым нужно довольно много платить. Пока ещё никто не поверил в нейросети настолько, чтобы начать вкладывать в создание таких сетов большие деньги.
  • Алгоритмы, которые генерируют большое число вариантов проектных решений, требуют на входе набор конкретных параметров, а для выбора оптимального решения – расстановку этих параметров по приоритетам. Также, для учёта внешних требований, необходимо наличие нормативных документов в машиночитаемом формате. Работа по созданию машиночитаемых нормативов начата, но для её выполнения тоже нужны довольно большие ресурсы, а также поддержка и понимание цели этого мероприятия на всех уровнях власти. Пока этот путь ещё только начинается.
  • Чтобы система работала, все типы моделей должны иметь точки взаимодействия, ссылаться на общую базу данных, и обновление ПО не должно мешать работе с более старыми версиями моделей. Пока, как мы знаем, универсальное ПО для работы со всеми типами моделей никем не создано, и в ближайшее время вряд ли появится – слишком большой бюджет нужен на написание такого программного продукта. Гораздо более реальным видится создание открытого стандарта, по которому модели смогут обмениваться информацией друг с другом. Но даже и здесь работы ещё много: такие стандарты как ifc не подходят для совместной работы, а те, что больше подходят – зачастую являются закрытыми и приносят прибыль конкретным вендорам, а потому вряд ли в перспективе станут общедоступными.

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

Если у вас есть чем этот текст дополнить, либо по каким-то позициям есть контраргументы – я буду рад прочесть и обсудить ваши комментарии.


vk icon