Естественно, в таких условиях уже невозможно производить конкурентную, современную продукцию, используя кульман и логарифмическую линейку. В современных конструкторских бюро (КБ) в ход идут самые разные средства автоматизации проектирования: это и дополненная/виртуальная реальность для проработки эргономики кабины, и различные виды математических моделей (от 1D-моделей агрегатов для разработки алгоритмов управления до 3D-моделей для расчёта аэродинамических характеристик летательного аппарата и прочностных расчётов), и цифровые макеты изделий для подготовки производства. А учитывая современные тренды, кажется, что и AI-ассистенты кружат где-то рядом.

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

В этой статье мы, ЦИТМ «Экспонента», покажем, что для инженеров есть хорошее средство для импортозамещения инженерного ПО по крайней мере на малом фронте математического моделирования — это среда Engee. И покажем это мы не на сферических инженерах в тропосфере, перечислив возможности Engee в вакууме. Покажем мы это на реальном примере из инженерной практики специалистов настоящего авиационного КБ.

Итак, в качестве инженеров, решивших действовать на упреждение в части импортозамещения инженерного ПО, пока не стало слишком поздно… барабанная дробь… выступает одно из подразделений УЗГА (Уральский завод гражданской авиации, разработчик воздушных судов «Байкал», «Освей», «Ладога» и др.). В должностные обязанности коллег входит в том числе и разработка авиационных силовых установок (ДВС, ГТД) и систем управления ими. До сего дня в инженерной практике подразделения широко использовался MATLAB/Simulink для 1D-моделирования поведения агрегатов и разработки алгоритмов систем управления этими агрегатами. В подобных задачах MATLAB/Simulink является одним из популярнейших решений и широко распространён среди предприятий-разработчиков авиационной техники в России и за рубежом. Причин этому существует великое множество, но основные, на наш взгляд, кроются в самом модельно-ориентированном подходе: математические модели позволяют с невероятной наглядностью (и без ущерба для окружающих) анализировать поведение системы во всех возможных режимах работы, а также разрабатывать алгоритмы систем управления, не превращая профильных инженеров в программистов. Такую концепцию MATLAB/Simulink продвигает в массы, поддерживая широкими возможностями решения частных задач независимо от сферы применения.

Применительно к Engee вопросы у УЗГА стояли примерно те же: будут ли задачи решаться привычным образом, совпадают ли результаты расчётов, насколько сложно инженерам переходить на новую среду разработки? Ответы на эти вопросы были найдены в рамках проекта с применением среды Engee в рабочих процессах подразделения.

В этом проекте специалисты УЗГА решили не мелочиться и замоделировать работу целого газотурбинного двигателя, но чтобы не раскрывать коммерческой тайны, взяли в публичном доступе описание математической модели абстрактного ГТД (тоже реализованную в среде Simulink, что оказалось очень кстати для сравнения) и воспроизвести аналогичную модель в среде Engee.

Основные структурные части ГТД изображены на рисунке ниже:

• Входное устройство предназначено для подвода к компрессору двигателя потребного количества воздуха.
• Компрессор ГТД служит для повышения давления воздуха перед подачей его в камеру сгорания.
• Камера сгорания предназначена для подвода теплоты к рабочему телу в двигателе за счёт сгорания топлива.
• Турбина ГТД предназначена для преобразования энергии газа в работу на валу, затрачиваемую на привод компрессора.
• Реактивное сопло предназначено для ускорения потока воздуха или газа и создания реактивной тяги.

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

Перейдём к исходной математической модели нашего ГТД, реализованной в среде MATLAB/Simulink. Дабы не перегружать текст огромным количеством скриншотов исходной модели, посмотрим на общую структуру модели:

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

Например, уравнение динамики ротора выглядит вот так:

где Nт — мощность турбины, Вт

Nст — мощность стартера, Вт

Nк — мощность компрессора, Вт

Nтр (n) =kтр (n)⋅n - потери мощности на трение в зависимости от частоты вращения n, Вт.

При этом коэффициент расчёта потерь мощности на трение kтр (Вт/(об/мин)) задан следующей табличной зависимостью:

А вот как это же уравнение выглядит в соответствующем блоке модели:

При этом значение каждого сигнала (читай, составляющей уравнения) может быть проанализировано для отладки во время или после симуляции. Подобным образом работают все составные части моделируемого ГТД.

Глобально модель описывает поведение ГТД во времени в зависимости от количества подаваемого топлива и параметров окружающей среды (температура воздуха, давление и число Маха).

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

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

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

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

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

При разработке Engee главным продуктовым требованием было обеспечение гладкого, безболезненного переезда на новое ПО пользователей самых популярных зарубежных инструментов разработки — MATLAB/Simulink и Amesim. Соответственно, внешний вид и содержание всех составных частей Engee максимально приближено к тому, что пользователь видел в привычных ему инструментах.

С точки зрения использования блоков в модели, пользователю доступны почти 80% того, что есть в Simulink: это и блоки базовой библиотеки, и блоки физического моделирования и конечные автоматы для проектирования управляющей логики.

То есть в рамках проекта инженеры фактически занимались сборкой модели из тех же блоков, что и в Simulink. Автоматический конвертер моделей из Simulink на тот момент находился в разработке (но теперь он уже готов).

Спустя некоторое время монотонной работы мы получили вот такую модель:

Выглядит похоже, а теперь посмотрим на уже знакомые уравнения вращения ротора:

Тоже как будто бы визуально совпадает.

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

Так как мы имеем Simulink-модель в качестве эталона, запишем на ней данные для двух сценариев:

1) Изменение подачи топлива в камеру сгорания ГТД при неизменных параметрах атмосферы – фактически, виртуальные наземные испытания на газодинамическую устойчивость.

2) Изменение параметров окружающей атмосферы, например, при снижении с постоянным числом Маха и фиксированной подачей топлива.

Данные входных/выходных параметров запишем в пару mat-файлов (собственный формат среды MATLAB/Simulink), а обработаем и сравним уже в Engee.

Импорт эталонных данных, запуск модели в Engee и вывод графиков организуем в виде интерактивного скрипта (TLDR: мы просто запускаем Engee-модель с теми же параметрами, что и в симулинк-файле):

Подготовка к импорту данных

In [ ]:
# Подключим необходимые пакеты для работы с mat-файлами
Pkg.add("MAT")
using MAT

Загрузка модели в Engee и её параметров

In [ ]:
model = engee.open("Turbine_model_Compare.engee");
engee.script.run("Model_params.ngscript");

Импорт данных из Simulink

In [ ]:
# Определяем имена файлов с эталонными данными
fnames = [
"slx/SL_data_Const_atmosphere.mat"
"slx/SL_data_Const_Gtop.mat"
];

Запуск и получение данных в Engee

In [ ]:
# Зарезервируем переменные под вычисление погрешностей
n_rotor_SL = Vector{Vector}();
P_SL = Vector{Vector}();
n_rotor_result = Vector{Vector}();
P_result = Vector{Vector}();


# Организуем основной рабочий цикл для сравнения данных
for i = 1:length(fnames)


# Читаем данные
file = matopen(fnames[i])
global SL_Data = read(file, "Simulink_Data")
close(file)


# Раскладываем данные по переменным
global time_values = SL_Data[:,1];
global Gtop = SL_Data[:,2];
global M = SL_Data[:,3];
global T_h = SL_Data[:,4];
global p_h = SL_Data[:,5];
global N_start = SL_Data[:,6];
global n_rotor = SL_Data[:,11];
push!(n_rotor_SL,n_rotor);
global P = SL_Data[:,12];
push!(P_SL,P);


# Запускаем расчёт
engee.run(model)


# Записываем результаты моделирования
tmp_n_vec = Vector(collect(simout["Turbine_model_Compare/Turbine Engine.n, RPS"]).value);
push!(n_rotor_result, tmp_n_vec);
tmp_P_vec = Vector(collect(simout["Turbine_model_Compare/Turbine Engine.P, N"]).value);
push!(P_result, tmp_P_vec);
end

В графическом виде результаты сравнения для двух экспериментов будут выглядеть следующим образом:

Итак, мы видим, что для симуляции в Simulink и Engee обороты ротора не отличаются более чем на 20 об/сек, а для тяги — не более 3 Н. В относительных погрешностях речь идет о величине порядка 1,5%, что в свою очередь говорит о близости решателей Simulink и Engee. И еще раз — это погрешность относительно Simulink, где решатель на переходном процессе делает чуть другие шаги. На устоявшемся процессе погрешности квази-нулевая, разумеется — ведь уравнения те же самые.

Кажется, что результатам расчёта можно доверять, и ментальное здоровье инженера не пострадает при таком импортозамещении ПО?.. Как бы не так! Мы хотим, чтобы импортозамещение вызывало восторг!

Для полноты картины вспомним ещё один удобный функционал Simulink — маски блоков, и посмотрим, как аналогичным образом пользователи могут сами организовать удобную работу с передачей параметров в Engee.

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

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

Для модели ГТД в Engee маска блока будет выглядеть так (и не спрашивайте, почему вместо привычного КПД везде указаны «Потери», так автор увидел):

Итак, мы посмотрели на реальный опыт рядовых инженеров УЗГА в деле нелёгкого перехода на российское инженерное ПО на примере малой задачи по переносу модели ГТД. По отзывам сотрудников российских компаний, перейти с MATLAB/Simulink в среду математических расчётов и моделирования Engee можно безболезненно благодаря низкому порогу входа, привычным методам работы и уверенности в результатах вычислений в среде Engee.

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

Как мы участников ЦИПР обучали пилотированию МС-21

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

P. S. Если заинтересовались моделью ГТД — она здесь.