Как все работает сейчас

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

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

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

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

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

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

Итак, мы разобрались, что именно может делать инженер в проекте. Однако это не все. Не менее важно ответить на следующий вопрос: зачем это нужно?

Зачем инженер это делает

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

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

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

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

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

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

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

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

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

Инженер или ИИ?

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

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

1. Генерация концепции. Представляется, что алгоритм должен проанализировать требования, представленные в машиночитаемом формате, и задать рамки, внутри которых нейросеть, обученная на концепциях аналогичных объектов, предложит некоторое количество вариантов на выбор. Иллюстрация похожей технологии – Nvidia Canvas: https://youtu.be/CyClQaJqY00. Возможно, задание рамок фактически будет выглядеть как выбор конкретной нейросети алгоритмом, исходя из набора требований.

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

2. Выбор оптимального варианта – задача чисто алгоритмическая. Каждый вариант проверяется на соответствие каждому из параметров, и выбирается оптимальный. Краткая иллюстрация как это может быть – например тут https://youtu.be/3ptdmJonZAY

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

3. Детализация моделей происходит, например, так.

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

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

5. Так как алгоритмические проверки всего со всем можно было выполнять прямо в процессе итераций из п. 3, в этом шаге не должно быть необходимости – после п. 4 модель уже должна быть внутренне непротиворечивой и соответствующей исходным и внутренним требованиям. Если это почему-то не так, то здесь можно провести алгоритмическую проверку на соответствие всего со всем.

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

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

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

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

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

Проблемы, которые предстоит решить

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

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

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