exponenta event banner

Оценка эффективности управления с помощью корректировки горизонта времени выполнения

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

Обзор выбора горизонта прогнозирования и управления

Горизонты прогнозирования и управления вместе с временем выборки контроллера обычно определяются до того, как будут разработаны другие настройки MPC, такие как ограничения и веса.

Существуют определенные рекомендации по выбору времени выборки. Ts, горизонт прогнозирования pи горизонт управления m. Например, предположим, что требуется определить, как далеко контроллер должен смотреть в будущее. Теоретически, время прогнозирования должно быть достаточно большим, чтобы фиксировать доминирующее динамическое поведение установки, но не более, чтобы избежать растраты ресурсов, используемых при вычислениях. На практике вы часто начинаете с небольшого значения и постепенно увеличиваете его, чтобы увидеть, как улучшается эффективность управления. Когда это плато, остановитесь.

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

В этом примере мы демонстрируем, как настроить горизонты прогнозирования и управления блока контроллера MPC, используя его входные данные, и сравниваем эффективность управления после нескольких запусков моделирования без воссоздания объекта контроллера MPC, используемого блоком. Если блок выполняется во встроенной системе, можно также настроить горизонты в реальном времени без регенерации и повторного развертывания кода.

Для выполнения этого примера необходимы Design™ Simulink ® и Simulink Control.

if ~mpcchecktoolboxinstalled('simulink')
    disp('Simulink is required to run this example.')
    return
end
if ~mpcchecktoolboxinstalled('slcontrol')
    disp('Simulink Control Design is required to run this example.')
    return
end

Линеаризация нелинейной установки в номинальной рабочей точке

Нелинейная установка с одним входом-одним выходом реализована в модели Simulink mpc_nloffsets. В номинальной рабочей точке установка находится в установившемся состоянии с выходом -0,5.

plant_mdl = 'mpc_nloffsets';

Используйте operspec команда Simulink Control Design для создания объекта спецификации операционной точки с требуемым выходным значением, фиксированным в установившемся состоянии.

op = operspec(plant_mdl);
op.Outputs.Known = true;
op.Outputs.y = -0.5;

Используйте findop команда модуля Simulink Control Design для получения номинальной рабочей точки.

[op_point, op_report] = findop(plant_mdl,op);
 Operating point search report:
---------------------------------

 Operating point search report for the Model mpc_nloffsets.
 (Time-Varying Components Evaluated at time t=0)

Operating point specifications were successfully met.
States: 
----------
(1.) mpc_nloffsets/Integrator
      x:         0.595      dx:      1.03e-13 (0)
(2.) mpc_nloffsets/Integrator2
      x:          2.19      dx:      -1.1e-09 (0)

Inputs: 
----------
(1.) mpc_nloffsets/In1
      u:         -1.18    [-Inf Inf]

Outputs: 
----------
(1.) mpc_nloffsets/Out1
      y:          -0.5    (-0.5)

Используйте linearize команда Simulink Control Design для линеаризации установки при номинальном рабочем состоянии.

plant = linearize(plant_mdl, op_point);

Получение номинальных состояний установки, выхода и ввода.

x0 = [op_report.States(1).x;op_report.States(2).x];
y0 = op_report.Outputs.y;
u0 = op_report.Inputs.u;

Линеаризованная установка является недостаточно демпфируемой системой второго порядка. Использование damp команда, мы можем выяснить доминирующую постоянную времени растения, которая составляет около 1,7 секунды.

damp(plant)
                                                                       
         Pole              Damping       Frequency      Time Constant  
                                       (rad/seconds)      (seconds)    
                                                                       
 -5.95e-01 + 1.84e+00i     3.07e-01       1.94e+00         1.68e+00    
 -5.95e-01 - 1.84e+00i     3.07e-01       1.94e+00         1.68e+00    

Проектирование контроллера MPC по умолчанию

Простое руководство рекомендует, чтобы время прогнозирования, по крайней мере, охватывало доминирующую постоянную времени (1,7 секунд), а горизонт управления составлял 10% ~ 20% горизонта прогнозирования. Поэтому, если мы выберем время выборки 0,1, горизонт прогнозирования должен быть около 17. Это дает нам начальную точку для выбора горизонтов по умолчанию

Ts = 0.1;
p = 20;
m = 4;
mpcobj = mpc(plant,Ts,p,m);
-->The "Weights.ManipulatedVariables" property of "mpc" object is empty. Assuming default 0.00000.
-->The "Weights.ManipulatedVariablesRate" property of "mpc" object is empty. Assuming default 0.10000.
-->The "Weights.OutputVariables" property of "mpc" object is empty. Assuming default 1.00000.

Установите номинальные значения в контроллере.

mpcobj.Model.Nominal = struct('X', x0, 'U', u0, 'Y', y0);

Задать ограничение СН.

mpcobj.MV.Max = 2;
mpcobj.MV.Min = -2;

Поскольку в установке мало шума, мы уменьшаем усиление шумовой модели, чтобы сделать фильтр Калмана по умолчанию более агрессивным.

mpcobj.Model.Noise = 0.1;

Сравнение производительности между различными вариантами горизонта прогнозирования

mpc_onlineHorizons в модели реализована система управления замкнутым контуром. Наша цель - отслеживать изменение -0.2 шага в опорном сигнале с минимальным превышением. Мы также хотим, чтобы время установки было меньше 5 секунд.

r0 = -0.7;
mdl = 'mpc_onlineHorizons';
open_system(mdl)

В модели блок MPC имеет два входа, где мы можем соединить сигнал горизонта прогнозирования и сигнал горизонта управления. В каждом моделировании мы изменяем значение горизонта прогнозирования (от 5 до 50), сохраняя при этом горизонт управления на уровне 4. Мы измеряем как превышение (%), так и время установки (сек) из сохраненных результатов моделирования. Обратите внимание, что объект контроллера MPC не изменяется. Вместо этого новые значения горизонта подаются в качестве входных сигналов во время выполнения.

p_choices = 5:5:50;
set_param([mdl '/Control Horizon'],'Value','4')
for p = p_choices
    set_param([mdl '/Prediction Horizon'],'Value',num2str(p))
    sim(mdl,20)
    settling_timeP(p/5) = ...
        find((abs(y.signals.values-r0)<0.01)&(abs([0;diff(y.signals.values)])<0.001),1,'first')*Ts;
    if r0>y0
        overshootP(p/5) = abs((max(y.signals.values)-r0)/r0)*100;
    else
        overshootP(p/5) = abs((min(y.signals.values)-r0)/r0)*100;
    end
end
figure
subplot(2,1,1)
plot(p_choices,overshootP,'*')
xlabel('prediction horizon')
ylabel('overshoot (%)')
title('control horizon = 4')
subplot(2,1,2)
plot(p_choices,settling_timeP,'*')
ylabel('settling time (sec)')
xlabel('prediction horizon')
-->Converting model to discrete time.
-->Assuming output disturbance added to measured output channel #1 is integrated white noise.

Как показывают два графика выше, когда горизонт прогнозирования увеличивается с 5 до 15, превышение снижается с 6% до 3%, а время отстаивания увеличивается с 3 секунд до 4 секунд. Однако после этого и перерасход, и время оседания остаются более или менее одинаковыми. Кроме того, все значения времени отстаивания удовлетворяют верхней границе 5 секунд. Поэтому мы выбираем горизонт прогнозирования 15, потому что это наименьшее значение для достижения удовлетворительной производительности путем формирования наименьшей задачи оптимизации.

Сравнение производительности между различными вариантами горизонта управления

После выбора горизонта прогнозирования используется одна и та же настройка для оценки различных вариантов горизонта управления. В каждом моделировании мы изменяем горизонт управления (от 1 до 10), сохраняя горизонт прогнозирования на уровне 15.

c_choices = 1:10;
set_param([mdl '/Prediction Horizon'],'Value','15')
for c = c_choices
    set_param([mdl '/Control Horizon'],'Value',num2str(c))
    sim(mdl,20)
    settling_timeC(c) = ...
        find((abs(y.signals.values-r0)<0.01)&(abs([0;diff(y.signals.values)])<0.001),1,'first')*Ts;
    if r0>y0
        overshootC(c) = abs((max(y.signals.values)-r0)/r0)*100;
    else
        overshootC(c) = abs((min(y.signals.values)-r0)/r0)*100;
    end
end
figure
subplot(2,1,1)
plot(c_choices,overshootC,'*')
xlabel('control horizon')
ylabel('overshoot (%)')
title('prediction horizon = 15')
subplot(2,1,2)
plot(c_choices,settling_timeC,'*')
xlabel('control horizon')
ylabel('settling time (sec)')

Как показывают два графика выше, когда горизонт управления увеличивается с 1 до 3, перерасход падает с 10% до 2%. После этого он увеличивается обратно до 5% по мере роста контрольного горизонта с 4 до 10. Объяснение состоит в том, что когда горизонт управления равен 1, контроллер не имеет достаточной степени свободы для достижения разумного отклика. Когда горизонт управления равен 4 или выше, контроллер имеет больше переменных принятия решения, так что первое оптимальное движение часто становится более агрессивным и, таким образом, приводит к большему превышению, но более короткому времени оседания. В этом примере, поскольку основной целью управления является достижение минимального превышения, мы выбираем 3 в качестве горизонта управления.

Моделируют модель с горизонтом прогнозирования = 15 и горизонтом управления = 3. Напомним, что нашим первоначальным выбором конструкции является горизонт прогнозирования = 20 и горизонт управления = 4, основанный на простом руководстве, которое близко к нашему окончательному выбору.

set_param([mdl '/Prediction Horizon'],'Value','15')
set_param([mdl '/Control Horizon'],'Value','3')
open_system([mdl '/Input'])
open_system([mdl '/Output'])
sim(mdl)

Настройка горизонтов в реальном времени на встраиваемых системах

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

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

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

bdclose(mdl)

См. также

Связанные темы