Как реализовать матричное умножение для MPC на базе ПЛК в Ladder Logic

Для реализации прогнозного управления (MPC) в ПЛК инженеры должны выполнять матричное умножение, используя математику на основе массивов. Поскольку стандартный язык релейно-контактных схем (Ladder Diagram) не имеет встроенного матричного оператора, обычный подход заключается в отображении членов пространства состояний в массивы, развертывании необходимых инструкций `MUL` и `ADD` и проверке влияния на время цикла сканирования перед развертыванием на оборудовании.

Матричное умножение в ПЛК — это не столько математическая задача, сколько проблема детерминизма, скрытая под маской математики. MPC опирается на уравнения пространства состояний, такие как \(x_{k+1}=Ax_k+Bu_k\), но стандартный Ladder Diagram не предоставляет встроенной инструкции для матричного умножения, поэтому инженер должен перевести эту алгебру в явные операции с массивами, которые контроллер сможет выполнять предсказуемо.

Метрика Ampergon Vallis: В ходе внутренних стресс-тестов цикла сканирования в OLLA Lab развертывание умножения матрицы 3x3 на вектор в явные последовательные инструкции `MUL` и `ADD` выполнялось на 4,2 мс быстрее за цикл, чем базовый вариант на Structured Text с вложенными циклами в тех же условиях моделируемой задачи. Методология: n=18 повторных запусков; определение задачи = повторное вычисление матрицы 3x3 типа REAL на вектор с обновлением аналоговых состояний; базовый компаратор = реализация на Structured Text с вложенными циклами `FOR`; временное окно = стендовые испытания в марте 2026 года. Это подтверждает обоснованность утверждения об издержках реализации в данной тестовой конфигурации. Это не доказывает, что развернутый Ladder всегда быстрее на любом семействе ПЛК, версии прошивки или компиляторе.

Это различие важно, потому что сторожевые таймеры (watchdog timers) — это не философская категория. Они вызывают сбои реальных процессоров.

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

Стандартная форма дискретного пространства состояний выглядит так:

\[ x(k+1)=Ax(k)+Bu(k) \]

Где:

• \(x(k)\) = вектор текущего состояния
• \(x(k+1)\) = вектор следующего прогнозируемого состояния
• \(A\) = системная матрица, описывающая внутреннюю динамику процесса
• \(B\) = входная матрица, описывающая влияние управляемых переменных на состояния
• \(u(k)\) = вектор управляющих воздействий

В терминах ПЛК эти объекты становятся тегами и массивами:

• `Matrix_A` хранит коэффициенты динамики процесса
• `Matrix_B` хранит коэффициенты влияния входов
• `Vector_x` хранит текущие измеренные или оцененные состояния
• `Vector_u` хранит текущие управляемые входы
• `Vector_x_Next` хранит прогнозируемое следующее состояние

Важное различие заключается в SISO против MIMO. ПИД-контур обычно обрабатывает одну измеренную переменную относительно одной управляемой переменной. MPC создан для поведения с несколькими входами и несколькими выходами (MIMO), где изменение одного исполнительного механизма может влиять на несколько переменных процесса одновременно. Паровые системы, сети резервуаров, тепловые установки и взаимодействия давления и потока редко бывают достаточно «вежливыми», чтобы оставаться несвязанными.

Уравнения пространства состояний отображаются в логику Ladder путем преобразования матриц и векторов в массивы ПЛК с последующим явным выполнением каждого скалярного произведения. Ladder может представить математику, но не абстрагирует её для вас.

Для компактного примера 2x2 структура тегов может быть определена следующим образом:

Структура словаря тегов для системы 2x2

- `Matrix_A`: двумерный массив `REAL` `[0..1, 0..1]` - `Vector_x`: одномерный массив `REAL` `[0..1]` - `Vector_x_Next`: одномерный массив `REAL` `[0..1]` - `Temp_Mul_00`: `REAL` - `Temp_Mul_01`: `REAL` - `Temp_Mul_10`: `REAL` - `Temp_Mul_11`: `REAL`

• Хранит коэффициенты динамики системы
• Хранит текущие состояния, такие как уровень в резервуаре и температура
• Хранит следующие прогнозируемые значения состояния
• Временное хранилище для `Matrix_A[0,0] * Vector_x[0]`
• Временное хранилище для `Matrix_A[0,1] * Vector_x[1]`
• Временное хранилище для `Matrix_A[1,0] * Vector_x[0]`
• Временное хранилище для `Matrix_A[1,1] * Vector_x[1]`

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

В OLLA Lab это становится проверяемым, а не теоретическим. Редактор Ladder можно связать с панелью переменных, чтобы инженер мог наблюдать за каждым индексом массива, временным регистром и результирующим значением состояния в режиме реального времени во время симуляции. Это полезно, так как позволяет убедиться не только в синтаксической правильности цепи, но и в том, что привязки массивов и промежуточные значения численно корректны до того, как будет задействована реальная выходная карта.

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

Основные ограничения обычно таковы:

• Отсутствие встроенного матричного оператора
• Стандартные среды Ladder обычно не предоставляют единую инструкцию для умножения матриц на вектор или матриц на матрицу.
• Ограниченная эргономика циклов
• Итерации обычно проще реализовать на Structured Text, чем на Ladder Diagram.
• Сильная зависимость от временных тегов
• Даже небольшие матричные операции требуют промежуточного хранения для каждого частичного произведения.
• Чувствительность к циклу сканирования
• Арифметика с плавающей запятой, индексация массивов и повторяющиеся вычисления потребляют измеримое время выполнения.

Это не означает, что Ladder не может справиться с задачей. Это означает, что инженер должен выбрать один из двух стилей реализации:

### Вариант 1: Использование Structured Text для циклов

Это часто более компактное выражение математики. Вложенный цикл `FOR` может чисто рассчитать произведение матрицы на вектор, особенно когда размеры могут меняться.

Преимущества

• Более короткий код
• Легче масштабировать для больших матриц
• Более естественно для итеративной математики

Компромиссы

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

### Вариант 2: Развертывание матричной математики в Ladder Diagram

Это означает написание каждого умножения и сложения явно.

Преимущества

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

Компромиссы

• Громоздкая реализация
• Плохая масштабируемость при увеличении размера матрицы
• Высокий риск ошибок при копировании, если дисциплина именования слабая

Это классический контраст: компактный код против прозрачного выполнения. В реальном процессе прозрачность обычно лучше выдерживает испытание временем.

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

Это реальный аппаратный риск. Не «код кажется тяжелым». А сбой.

Нагрузка на время цикла сканирования обычно возникает из-за сочетания факторов:

• Арифметика REAL
• Операции с плавающей запятой на многих платформах ПЛК дороже, чем целочисленные операции.
• Индексация массивов
• Индексированный доступ добавляет накладные расходы на адресацию по сравнению с фиксированными скалярными тегами.
• Вложенные циклы
• Повторяющиеся итерации быстро умножают стоимость выполнения.
• Дополнительная аналоговая логика
• Масштабирование, фильтрация, ограничение и проверка аварийных сигналов часто окружают матричную математику, а не заменяют её.
• Выполнение за один цикл
• Выполнение полного расчета в каждом цикле может быть излишним и дорогостоящим.

Настройки сторожевого таймера варьируются в зависимости от семейства контроллеров и проектирования приложения. Широкий диапазон «обычно 10–50 мс» является обычным на практике, но релевантным числом всегда является настроенный порог на конкретной целевой системе. Стандарты не спасают контроллер от арифметики, которую он не может завершить вовремя.

Стратегии снижения времени цикла сканирования

Основные стратегии снижения нагрузки являются архитектурными, а не косметическими.

#### 1. Развертывание критических вычислений

Напишите явные инструкции `MUL` и `ADD` для каждого члена в небольших матрицах.

• Лучше всего подходит для небольших систем с фиксированной размерностью
• Улучшает прослеживаемость
• Избегает накладных расходов на циклы в некоторых средах

#### 2. Временное разделение вычислений (Time-slicing)

Распределите матричный расчет на несколько циклов сканирования, используя индекс шага или конечный автомат.

• Снижает пиковую нагрузку на сканирование
• Полезно для более крупных расчетов
• Вносит задержку, которую необходимо учитывать в производительности управления

#### 3. Оптимизация типов данных

Используйте масштабированную целочисленную математику, такую как `DINT`, где разрешение и диапазон процесса это позволяют.

• Может снизить стоимость выполнения
• Требует дисциплинированного масштабирования и управления переполнением
• Не всегда приемлемо для моделей процессов с более высоким разрешением

#### 4. Снижение частоты выполнения

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

• Подходит для более медленных тепловых или уровневых систем
• Менее подходит для быстрого движения или жесткого контроля давления
• Должно оставаться согласованным с целью управления

#### 5. Предварительное вычисление констант, где это возможно

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

• Снижает ненужную арифметику
• Упрощает путь выполнения во время работы

Практическую поправку стоит заявить прямо: более быстрое время сканирования не автоматически означает лучшее управление. Для MPC вопрос в том, является ли частота обновления управления подходящей для процесса и устойчивой для контроллера. Быстрое и нестабильное — это все еще нестабильное.

Матричный умножитель 2x2 на вектор в Ladder строится путем вычисления одного скалярного произведения на каждый выходной индекс. Каждый выходной элемент — это сумма произведений одной строки матрицы и вектора входа.

Предположим:

\[ A = \begin{bmatrix} a_{00} & a_{01}\\ a_{10} & a_{11} \end{bmatrix} ,\quad x = \begin{bmatrix} x_0\\ x_1 \end{bmatrix} \]

Тогда:

\[ x_{next,0} = a_{00}x_0 + a_{01}x_1 \]

\[ x_{next,1} = a_{10}x_0 + a_{11}x_1 \]

### Шаг 1: Вычислите первое частичное произведение для индекса 0

Умножьте `Matrix_A[0,0]` на `Vector_x[0]` и сохраните результат в `Temp_Mul_00`.

- Источник A: `Matrix_A[0,0]` - Источник B: `Vector_x[0]` - Назначение: `Temp_Mul_00`

### Шаг 2: Вычислите второе частичное произведение для индекса 0

Умножьте `Matrix_A[0,1]` на `Vector_x[1]` и сохраните результат в `Temp_Mul_01`.

- Источник A: `Matrix_A[0,1]` - Источник B: `Vector_x[1]` - Назначение: `Temp_Mul_01`

### Шаг 3: Суммируйте произведения для выходного индекса 0

Сложите `Temp_Mul_00` и `Temp_Mul_01`, затем сохраните результат в `Vector_x_Next[0]`.

- Источник A: `Temp_Mul_00` - Источник B: `Temp_Mul_01` - Назначение: `Vector_x_Next[0]`

### Шаг 4: Повторите шаблон для выходного индекса 1

Умножьте и сложите вторую строку:

• `Matrix_A[1,0] * Vector_x[0] -> Temp_Mul_10`
• `Matrix_A[1,1] * Vector_x[1] -> Temp_Mul_11`
• `Temp_Mul_10 + Temp_Mul_11 -> Vector_x_Next[1]`

Концепция Ladder Diagram для первой строки

|----[MUL Matrix_A[0,0] Vector_x[0] ]----------------(Temp_Mul_00)----| |----[MUL Matrix_A[0,1] Vector_x[1] ]----------------(Temp_Mul_01)----| |----[ADD Temp_Mul_00 Temp_Mul_01 ]--------------(Vector_x_Next[0])--|

Медиа-концепция: Развернутые инструкции `MUL` и `ADD` для строки 0 матрицы состояний 2x2.

Альтернативный текст изображения: Скриншот редактора Ladder Logic в OLLA Lab, показывающий матричное умножение 2x2, развернутое в явные блоки MUL и ADD, с панелью переменных, отображающей результирующие значения массива REAL для сценария многомерного прогнозного управления.

В OLLA Lab практический рабочий процесс заключается в создании этой последовательности цепей в браузере, запуске режима симуляции и проверке `Matrix_A`, `Vector_x`, временных тегов и `Vector_x_Next` на панели переменных. Это позволяет инженеру подтвердить три вещи отдельно:

• арифметика верна,
• теги сопоставлены правильно,
• и стоимость времени сканирования остается приемлемой при нагрузке симуляции.

Это полезное различие, потому что неправильная математика и неправильная проводка часто дают один и тот же первый симптом: переменная процесса направляется куда-то не туда.

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

Для этой статьи проверка цифрового двойника означает нечто операционно специфическое: запуск реализации Ladder против реалистичной модели моделируемого оборудования, внесение контролируемых изменений или неисправностей и сравнение состояния контроллера, поведения I/O и отклика процесса перед любым развертыванием на объекте.

В OLLA Lab этот рабочий процесс проверки может включать:

• привязку логики на основе массивов к многомерному аналоговому сценарию,
• настройку входов процесса и возмущений в режиме симуляции,
• наблюдение за поведением переменных и I/O в реальном времени,
• сравнение состояния Ladder с состоянием моделируемого оборудования,
• и пересмотр реализации после появления ненормального поведения.

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

Именно здесь следует правильно определить понятие Simulation-Ready (готовность к симуляции). Инженер, готовый к симуляции, — это не просто тот, кто может написать правильный синтаксис ПЛК. Это инженер, который может доказать, наблюдать, диагностировать и защитить логику управления от реалистичного поведения процесса до того, как она достигнет реального процесса. Синтаксисом легко восхищаться. Развертываемость менее снисходительна.

Что следует документировать в качестве инженерного доказательства?

Если вы хотите продемонстрировать компетентность в продвинутой логике ПЛК, создайте компактный корпус инженерных доказательств, а не галерею скриншотов.

Используйте эту структуру:

• Определите процесс, состояния, управляемые переменные и цель управления.

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

• Покажите реализованные цепи, соответствующие теги и соответствующий отклик моделируемой установки.

• Запишите возмущение, неверный коэффициент, отказ датчика, событие насыщения или временной стресс.

• Объясните, какая логика, планирование, масштабирование или изменение типа данных были применены.

• Укажите, что выявил сбой в модели, реализации или ограничениях контроллера.

1. Описание системы
2. Операционное определение «правильности»
3. Логика Ladder и состояние моделируемого оборудования
4. Случай внесенной неисправности
5. Внесенные изменения
6. Извлеченные уроки

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

Математика MPC принадлежит ПЛК только тогда, когда контроллер, структура задачи и динамика процесса поддерживают её. Миграция продвинутого управления в сторону периферийных и локальных вычислений реальна, но это не означает, что каждый ПЛК должен стать маленькой, перегруженной DCS.

Оставляйте расчет в ПЛК, когда верны следующие условия:

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

Переносите расчет на DCS, промышленный ПК или уровень периферийных вычислений, когда доминируют следующие условия:

• большие горизонты оптимизации,
• более тяжелые матричные операции,
• частые обновления модели,
• ограниченные ресурсы ПЛК,
• или неприемлемое влияние на время цикла сканирования.

Инженерный вопрос не в том, модно ли MPC на базе ПЛК. А в том, является ли реализация аудируемой, детерминированной и поддерживаемой на целевом оборудовании. Это менее гламурные слова, чем «ИИ» или «оптимизация». Но именно они обеспечивают работу заводов.

Эта реализация охватывает теорию управления, ограничения выполнения ПЛК, практику симуляции и дисциплину инженерного проектирования, смежную с безопасностью. Ни один стандарт не говорит вам, как писать матричное умножение в Ladder, но несколько сводов литературы и стандартов формируют правильные границы.

Релевантные ссылки включают:

• IEC 61131-3
• Регулирует языки программирования ПЛК, такие как Ladder Diagram и Structured Text.
• IEC 61508
• Предоставляет более широкую основу для функциональной безопасности электрических/электронных/программируемых электронных систем.
• Руководство exida и литература по жизненному циклу безопасности
• Полезно для понимания доказательств, дисциплины проверки и разделения между функциональным поведением и требованиями безопасности.
• Литература IFAC и управления процессами
• Релевантна для архитектуры MPC, моделирования пространства состояний и оптимизации с ограничениями.
• Литература по цифровым двойникам и обучению симуляции
• Релевантна для проверки логики против реалистичного поведения установки и улучшения готовности к вводу в эксплуатацию.

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

Вверх: Чтобы поместить логику управления на основе массивов в более широкий контекст автоматизации, вернитесь в Ladder Logic Mastery Hub.

В сторону: Для оценки состояния при зашумленных измерениях процесса прочитайте Implementing a 1D Kalman Filter in Structured Text: A Masterclass.

В сторону: Для переноса моделей из систем более высокого уровня в логику, исполняемую ПЛК, см. Converting Neural Network Weights to PLC Logic.

Вниз: Чтобы безопасно попрактиковаться в матричной математике, лимитах времени сканирования и многомерной проверке, откройте Multi-Variable Optimization Preset в OLLA Lab.

- IEC 61131-3: Программируемые контроллеры — Часть 3 - Семейство стандартов функциональной безопасности IEC 61508 - Ресурсы по функциональной безопасности и валидации exida - Рекомендация NAMUR NE 107 по сигнализации состояния - Цифровой двойник в промышленности: современное состояние (DOI)