— Процессы проектирования связаны с накоплением огромного количества информации, — объясняет Павел Храмченков, старший инженер Dassault Systemes. — Сначала, на основе исследований рынка, формулируется идея, потом делается её предварительная, черновая проработка, предварительный расчёт и анализ, потом начинается переход к проектированию. Предприятию важно не только создать цифровой макет изделия и провести его виртуальное тестирование, но и подготовиться к производству: от создания технологической карты изделия до логистики. Мы избежим многих проблем, если ещё на этапе разработки поймём, как должны ехать по конвейеру коробки, как расставить людей, чтобы на конвейере не было заторов, как грузовики будут вывозить готовую продукцию со склада, одним словом, если обеспечим людей, работающих над изделием, всей полнотой информации от и до. После того как изделие произведено, необходимы инструкции по его эксплуатации и обслуживанию и, наконец, схема его утилизации.
В словах «гонка технологий» ключевое — это гонка. В конкурентной среде (там, где она есть) улучшенные версии чего бы то ни было надо выпускать быстрее других — и не разориться на этих скоростях. Появление PLM-платформ ставит крупные отечественные компании перед стратегической дилеммой: окупятся ли выигрышем во времени и себестоимости средства, инвестированные в мучительный, затратный по времени, деньгам и усилиям процесс внедрения совершенно новых для организации управленческих и информационных систем. Особенно остро эта дилемма стоит перед производителями товаров для рынков, чувствительных к дизайну и беспощадных к «нафталину»: например, для рынка гаджетов, цифровой техники или автомобилей.
— Раньше на создание нового автомобиля, даже при наличии программ компьютерного проектирования, уходило до пяти-шести лет, — говорит Храмченков. — Платформы полного жизненного цикла сокращают этот срок до трёх-четырёх лет. Выигрыш очень серьезный, потому что только от момента, когда «замораживается» дизайн кузова, до попадания машины на рынок проходит два-три года. В новейшем выпущенном автомобиле мы видим не сегодняшнюю дизайнерскую идею, а как минимум двухлетней давности. Задача всех инженерных продуктов и решений — сокращать этот разрыв. Ошибки неизбежны, но мы стремимся снизить риск необходимости возвращаться на несколько шагов назад ради их исправления. Система, которая позволяет увидеть любой инженерный процесс и любую деталь в самом широком производственном, коммерческом и пользовательском контексте, и есть управление жизненным циклом изделия.
Разумеется, управление жизненным циклом изделия выходит за рамки задачи сделать его модным и красивым. Существуют штучные высокотехнологичные продукты — ледоколы, самолёты и атомные электростанции, где PLM-технологии на этапе использования, обслуживания и утилизации играют едва ли не более важную роль, чем на этапе разработки, позволяя вести своего рода «амбулаторную карту» изделия, адекватно отслеживать его ресурс и точнее диагностировать неполадки. CAD’ы, системы проектирования, интегрируются в платформы PLM как составная часть. Возможно, это и есть будущее инженерного инструментария?
— Далеко не во всех отраслях и не всеми компаниями востребованы средства PLM, — возражает Собачкин. — Эти сложные и дорогие системы адресованы, в первую очередь, крупным корпорациям. А на сегодняшнем инженерном рынке есть и огромное количество мелких и средних организаций. Скорее, сегодняшняя «точка роста» инженерного софта связана со стремлением разработчиков CAD’ов преодолеть зависимость от внешних, по отношению к проектированию, средств анализа. Развитие собственных инструментов анализа и математического моделирования, пожалуй, пока остается самым перспективным направлением во всей цепочке программных инженерных продуктов.
Расчёт как стратегический ресурс
В докомпьютерную эпоху проектировщики отправляли свои чертежи на окончательную проверку в расчётные отделы, чтобы удостовериться, что изделие обладает приемлемыми физическими параметрами — прочностью, гидродинамикой и подобным, то есть не сгорит или не сломается при использовании. Расчётчики утверждали чертежи либо возвращали их на доработку. Времени такой процесс занимал достаточно много, погрешность вычислений была высока (отсюда правило классической советской инженерии — проектировать с огромным запасом прочности и порождённые им «неубиваемые» аппараты). Затем строили экспериментальные образцы, тестировали их вживую, по результатам снова дорабатывали проект и так доводили продукт до необходимых показателей качества. Сегодня программы компьютерного математического моделирования позволяют значительную часть экспериментов провести виртуально: созданную в CAD’е трёхмерную модель можно «жечь», «ломать», «разбивать об стенку», «довинчивать» по результатам и допускать её к реальным испытаниям только после того, как она удовлетворительно покажет себя на виртуальных. Это не только удешевляет и ускоряет процесс, но и расширяет человеческие возможности: сжечь на тестах десять ракетных двигателей вместо трёх — просто дорого, но испытывать на прочность, скажем, действующий атомный реактор — вообще плохая идея.
Математическое моделирование изделия и эксперимента решает много экономических проблем, но ставит одну — и очень серьёзную — стратегическую. Оно требует программного обеспечения, в которое «зашит» мощнейший математический аппарат, а такие коды не пишутся в одночасье.
— Компьютерный инженерный анализ развивался собственным путём, независимо от проектирования, — рассказывает Александр Собачкин. — Исторически пакеты для проектирования и для анализа разрабатывались разными организациями и сначала предназначались для разных групп пользователей: CAD’ы — для инженеров-конструкторов, а расчётные программы — для подразделений инженерного анализа. Разумеется, тут же был налажен обмен данными между этими программами, но в целом дорожки разошлись крепко. А сегодняшний рынок требует создания систем анализа, полностью интегрированных в среду CAD. Это бы позволило проводить расчёт изделия не только квалифицированному специалисту, пользователю соответствующих программ, но и обычному инженеру-конструктору, который смог бы анализировать процессы в своей трёхмерной модели по ходу проектирования, никуда ее не выгружая.
Есть и ещё одно важное отличие программ анализа от проектировочных. Программы для проектирования, CAD’ы, — это просто более удобный инструмент. Не думаю, что кому-то придёт в голову ограничивать к ним доступ из соображений национальной безопасности. Но программы математического моделирования и расчёта — это важный стратегический ресурс, в том числе оборонный. Возможно, не случайно развитие этого рынка шло таким образом, что в итоге на нём возник гигант, опережающий остальных: американская компания и одноимённый расчётный продукт Ansys. Сегодня он далеко оторвался от своих глобальных конкурентов по спектру решаемых задач, что касается российского рынка; среди отечественных разработчиков у него нет ни аналогов, ни конкурентов. Это означает, прежде всего, зависимость российских предприятий от заокеанского продукта, поставка которого в ряд отраслей в любой момент может быть ограничена или вообще прекращена. Если такие ограничения будут введены сейчас, они не приведут к тяжёлым последствиям, поскольку ещё живо поколение специалистов, умеющих решать задачи без помощи расчётных программ. Но новое поколение инженеров и расчётчиков скорее всего будет полагаться только на компьютерный анализ, да и эксперимент нынче не всем по карману. Актуальность работы над отечественными системами инженерного анализа, по-видимому, будет только возрастать. На создание таких систем уходят долгие годы, но есть способы ускорить процесс и выиграть драгоценное время. Опыт практически всех успешных разработчиков показывает, что один из способов выйти на новую ступень развития — стратегические покупки чужих интересных разработок, хорошо дополняющих сильные места самого покупателя. Этот путь может оказаться перспективным и для отечественного инженерного анализа.
Сильный расчётный код «с биографией» догнать и перегнать трудно, потому что, развиваясь, он постепенно аккумулирует всё больше знаний, математических моделей и подходов. Нужен инструмент, позволяющий очень многофакторные процессы обсчитывать в пределах доступных компьютерных мощностей. Если линейное разрешение расчётной сетки увеличить в десять раз, то при трёхмерном моделировании сложность расчёта вырастет в 103, то есть в тысячу раз. Иначе говоря, если разницу между величиной деталей изделия увеличить в десять раз, то его расчёт потребует в тысячу раз больший компьютерный ресурс. Такое резкое увеличение ресурсного «аппетита» расчётчиков вызвало к жизни целую индустрию параллельных вычислений, позволяющую использовать компьютерные мощности максимально эффективно; постоянно создаются огромные кластерные компьютеры и суперкомпьютеры. Но чем тоньше метод расчёта, тем он хуже параллелится, и к тому же зависимость эффективности от ресурса нелинейна: если считать задачу на тысяче процессоров одновременно, эффективность вырастет не в тысячу раз, а меньше. Математическое моделирование и расчёты — отдельный, весьма сложный мир, программы анализа похожи в этом отношении на английский газон: чтобы добиться по-настоящему впечатляющего результата, достаточно просто каждый день его подстригать... сто лет подряд.
***
Время великих инженеров ушло?
Андрей Аксёнов.
Инженерное программирование близко к науке в том смысле, что в нём всё ещё велика роль личности, индивидуального таланта, в отличие от промышленности, где от таланта инженера, по существу, уже ничего не зависит. Начиная с Генри Форда производство взяло курс на независимость от мастерства отдельного человека. Смысл фордовского конвейера заключался в возможности использовать неквалифицированных рабочих: взять человека с улицы, научить крутить одну гайку — и получать на выходе неплохие автомобили. В такой же конвейер постепенно превращается проектирование, и наш софт, нравится нам это или нет, часть этого процесса. Время великих инженеров ушло. Сегодня не надо быть Глушко, Королёвым или Алексеевым, чтобы спроектировать отличный самолёт или судно на подводных крыльях. Эстафетная палочка прорывного мышления перешла к разработчикам программ. Здесь конкретный человек, его мозг и талант ещё многое значат.
Конечно, у этой медали есть и светлая сторона. Например, программы оптимизации, которые берут на себя нетворческую часть работы. Кроме того, инженерный софт позволяет пользователю сразу охватить взглядом гораздо больше, чем при проектировании по старинке: мы видим, как течёт газ, как распределяются минимумы и максимумы тепла. Производственный опыт благодаря таким «картинкам» набирается гораздо быстрее.
Есть много историй, реальных и мифических, о великих инженерах, которые не нуждались в расчётах, больше того — проверяли правильность расчёта по тому, совпал или не совпал его результат с их интуитивным знанием. Интуиция высококлассного профессионала-технаря никогда не останется невостребованной, потому что она всё равно работает быстрее и точнее, чем численное моделирование. И, на мой взгляд, в области принятия стратегических рыночных решений — тоже.
***
Как оптимизировать лопату?
Полина Субботина.
Сначала надо решить, что такое для нас — идеальная лопата. Допустим, это лопата, которой удобно копать, и при этом приемлемая по весу, габаритам, прочности и цене. Если бы не программы оптимизации, нам бы пришлось в одной программе рассчитывать нашу лопату на прочность, в другой — конструировать её форму, а если мы захотим узнать, хорошо ли она будет рыхлить землю, придётся подключить ещё и гидродинамический анализ (рыхлую почву в некотором приближении можно считать как жидкость). Программа оптимизации позволяет связать все частные программы между собой. Она «подцепляет» разные CAD’ы и расчётные программы и перебирает варианты, причём не тупо, всё подряд, а практически как человек: отбросит заведомо неприемлемые решения и, сужаясь, пойдёт к нужному. Результатом будет модель лопаты с оптимальным набором характеристик по тем параметрам, которые мы задали. Это не самая дешёвая и не самая прочная лопата, но, если нам важны оба показателя, мы получим их оптимальное соотношение. Для инженера поиск оптимизма — своего рода искусство, требующее опыта и мастерства. А программа рассчитывает оптимум автоматически, быстро и точно. Тема оптимизации очень актуальна для разработчиков. Все мечтают и многие пытаются ею заниматься, но не всем такое под силу; оптимизация требует серьёзнейшего математического аппарата.
***
Задачи простые и сложные
Андрей Аксёнов.
Для разработчика сложность задачи связана не со значимостью или величиной объекта, а с разнообразием процессов и разбросом масштабов деталей. Например, обтекание автомобиля или самолёта посчитать легко, а процесс остывания чая в чашке — очень красивую, хотя не имеющую прикладного смысла задачу — рассчитать невероятно сложно: надо учитывать испарения, контакты между разными средами, пограничные слои. Ещё очень сложно смоделировать нагрев чайника — из-за его криволинейных поверхностей. А самая сложная задача, с которой мы когда-либо сталкивались на практике, вообще носит, извините, туалетный характер: надо было рассчитать систему слива из бачка в унитаз. Мало того что при распределении воды по объёму унитаза возникают плёнки, гидродинамика которых отличается от гидродинамики потока, но и в самом унитазе — не только вода, а ещё и некая «субстанция», про которую никто не знает, как она себя поведёт. Эту «субстанцию» приходилось предварительно моделировать CAD’ом, причём учитывая возможность её разрыва. Словом, слив из туалетного бачка потребовал огромного количества расчётных ячеек.
