Оба числа - про одно и то же испытание двигателя ПД-8. Разница в том, где оно проходило.
Испытания двигателя ПД-8 в АО «ОДК-Сатурн». Натурный эксперимент: оценочно 1,1 млрд рублей и около года с учётом изготовления опытных образцов, монтажа и подготовки к испытаниям. То же самое на комплексных инженерных моделях: 8 миллионов рублей и два месяца. Плюс к этому в цифре удалось оптимизировать конструкцию двигателя и поднять его характеристики.
Разница в 137 раз по деньгам и в шесть раз по срокам - это не эффект удачно купленного софта. Это эффект того, что гипотезу проверили до того, как она превратилась в металл. И дальше я хочу объяснить, почему такая разница возникает закономерно, а не как счастливое исключение.
Вопрос не в цене расчёта, а в этапе, на котором вы платите
Инженерные расчёты всегда решали одну задачу - проверить гипотезу до того, как изделие или процесс будут воплощены «в металле». Всё остальное - экономия времени на проектировании и доводке, сокращение числа испытаний, снижение затрат на пусконаладку и ТОиР, рост характеристик, снижение веса без потери надёжности - следствия этой единственной цели.
Поэтому меня всегда немного смешит вопрос о доступности комплексных инженерных расчётов. Вопрос не в том, дорого ли это. Вопрос в том, на каком этапе заказчик готов заплатить.
Возьмём одну и ту же конструкторскую ошибку. На этапе проектирования её исправление стоит условные 10 000 рублей - всё происходит в компьютере. Та же ошибка, найденная на опытном образце, - уже несколько миллионов рублей. А если она дошла до серийного производства, счёт может идти на миллионы долларов: именно так выглядят массовые отзывы автомобилей для устранения дефекта конструкции.
Расчёты не бывают дорогими. Дорогим бывает их отсутствие.
Рынок сместился с CAD на CAE. Ещё недавно основной интерес предприятий был во внедрении CAD-систем. Сейчас акцент явно ушёл в сторону CAE и автоматизации расчётов: рынок CAE, в отличие от рынка PLM в целом, растёт двузначными темпами в год.
К нам, как к экспертам, по-прежнему приходят с действительно сложными задачами. Но надо честно признать: за последние годы предприятия обросли «мышцами» и с большей частью расчётов справляются сами. Их сегодняшние вопросы звучат иначе:
- как считать быстрее
- как перейти от разрозненных расчётов отдельных деталей и узлов к комплексным мультифизичным расчётам изделия целиком
- как применять архитектурное проектирование и имитационное моделирование (1D-расчёты), чтобы находить ошибки конструкции ещё на концептуальной стадии
- как наладить взаимодействие конструкторских и расчётных подразделений
- как формализовать наработанные расчётные методики и автоматизировать расчётные цепочки
- как управлять расчётными данными
- как проводить компьютерную оптимизацию изделий и создавать цифровые двойники
- какие практики системной инженерии (MBSE) реально работают на их изделиях.
Это вопросы зрелого рынка. И это хороший знак.
42 миллиона в год без единого рубля капитальных затрат
Второй пример - из области эффективности производства, и он мне нравится даже больше, чем история с двигателем. Самое интересное с практической точки зрения сегодня - это сочетание одномерных имитационных моделей с конвейерами обработки статистики и телеметрии. Такой гибрид даёт бизнесу постоянно обновляемую модель, точно описывающую текущее состояние процесса, а значит - прогноз эффективности производства и основу для мер по её повышению.
Один наш заказчик, применив этот подход, нашёл возможность сократить издержки производственной линии на 42 миллиона рублей в год. Линию не дорабатывали, оборудование не модернизировали. Изменился только алгоритм регулирования загрузки оборудования - гибкий, рассчитанный гибридной системой на базе точной имитационной модели.
Где ломается доверие к модели
Меня часто спрашивают, на каких этапах возможны ошибки. Отвечу коротко: на всех. Подготовка данных - сложность сбора, интерпретации и очистки статистики и проектных данных. Расчёт - неочевидные полуэмпирические коэффициенты и зависимости, зашитые в код разработчиками ПО и не подходящие под ваш конкретный случай. Постобработка - неверная интерпретация результатов. Редуцирование и интеграция с телеметрией - ошибки конвейера данных и некорректно применённые методы статистики.
Вариантов ошибиться множество, а результат один: модель, которой нельзя доверять. Её прогнозы ошибочны, а предсказанные ею решения ведут к потерям, убыткам, а иногда и к аварийным ситуациям.
Что с этим делать:
1. Считать одну задачу в нескольких CAE-системах и сверять результаты. Совпали - вероятность ошибки моделирования минимальна.
2. Формализовать методики, проверенные практикой. Автоматизированные расчётные цепочки позволяют инженеру работать без риска «отсебятины».
3. Не отменять эксперимент. Только дорогостоящее испытание натурного образца надёжно подтверждает соответствие изделия заданным ТТХ. Но моделирование резко сокращает число образцов - часто до одного, который подтверждает точность модели.
Про импортозамещение - как есть
Отечественное ПО для инженерного анализа на годы отстаёт от ведущих зарубежных систем вроде ANSYS. Какие-то задачи мы уже решаем успешно, какие-то - пока нет. Это не приговор, это констатация.
Поэтому мы предлагаем предприятиям гибридную тактику в части CAE. Там, где отечественный софт уже даёт нужную точность и производительность, надо вести импортозамещение - мы помогаем выявить такие области и подобрать подходящие российские инструменты. В остальных областях, чтобы не разрушить и не ухудшить процессы проектирования, разумнее продолжать работать на имеющемся зарубежном ПО. Техническую поддержку этих решений мы обеспечиваем в полном объёме, несмотря на уход западных вендоров из РФ.
С инженерной точки зрения других разумных вариантов в текущей ситуации я не вижу. Административные решения, принятые без понимания сути инженерного дела, здесь обходятся дороже, чем кажется.
Расчёты как способ проектировать, а не проверять
Раньше расчёт был финальной операцией: конструкция готова -проверим. Сегодня всё большую роль играют расчёты, встроенные в процесс проектирования с самых ранних стадий - с концептуальной модели, с определения архитектуры изделия. В своё время ANSYS сформулировал это как «проектирование, движимое расчётами»: расчёт перестаёт быть вспомогательным проверочным инструментом и становится одним из основных средств проектирования. А это требует тесной интеграции расчётов в конструкторские процессы.
Цифровые двойники: тест на здравый смысл
О цифровых двойниках не говорит только ленивый, поэтому сформулирую свою позицию жёстко. Цифровой двойник - это компьютерная модель с двусторонней связью с физическим объектом. Объектом может быть и отдельная единица оборудования, и производство целиком. Но модель - это инструмент. Если у инструмента есть цель по SMART, вытекающая из базовых целей бизнеса, есть конкретные задачи, а ROI проекта не уходит за горизонт 3–5 лет, - такой двойник имеет право на существование.
Сказать, что одна отрасль остро нуждается в ЦД, а другая нет, не получится. Просто кто-то считает деньги, а кто-то пока находится в зоне, где их можно не считать.
Выгоды при этом хорошо известны. Разработчику и производителю ЦД даёт снижение себестоимости и веса, рост эффективности и надёжности. Эксплуатанту - гарантию работоспособности, улучшенные технические показатели, онлайн-мониторинг и оптимизацию параметров в реальном времени.
Что будет дальше? Самое интересное - симбиоз ИИ и традиционных средств автоматизации компьютерного моделирования. Автоматически построенная схема автоматизации, автоматически сгенерированные конвейеры очистки данных, автоматически сформированная интеграционная связь с расчётными моделями.
Это превратит инженера из «калькулятора» в творца, который одним промптом проверяет множество сценариев и находит неочевидные пути повышения эффективности процессов и оборудования. Если сегодня расчётчик одновременно проверяет 4–5 гипотез, то с таким инструментарием он будет проверять сотни вариантов за раз. Именно здесь, по моему мнению, и произойдёт следующий качественный скачок.
