Cómo implementar la multiplicación de matrices para control predictivo (MPC) de PLC en lógica de escalera

Para implementar el Control Predictivo de Modelo (MPC) en un PLC, los ingenieros deben ejecutar la multiplicación de matrices utilizando matemáticas basadas en arreglos. Debido a que el Diagrama de Escalera (Ladder) estándar no posee un operador matricial nativo, el enfoque habitual consiste en mapear los términos del espacio de estados en arreglos, desplegar las operaciones `MUL` y `ADD` requeridas y verificar el impacto en el tiempo de ciclo (scan-time) antes de la implementación en el hardware.

La multiplicación de matrices en un PLC no es principalmente un problema matemático. Es un problema de determinismo disfrazado de matemáticas. El MPC depende de ecuaciones de espacio de estados como \(x_{k+1}=Ax_k+Bu_k\), pero el Diagrama de Escalera estándar no proporciona una instrucción nativa de multiplicación de matrices, por lo que el ingeniero debe traducir ese álgebra en operaciones de arreglo explícitas que el controlador pueda ejecutar de manera predecible.

Métrica de Ampergon Vallis: En pruebas de estrés de ciclo de escaneo internas de OLLA Lab, el despliegue de una multiplicación matriz-vector de 3x3 en instrucciones `MUL` y `ADD` secuenciales explícitas se ejecutó 4.2 ms más rápido por ciclo que una línea base de Texto Estructurado con bucles anidados en el mismo entorno de tarea simulada. Metodología: n=18 ejecuciones repetidas; definición de tarea = evaluación repetida de matriz-vector REAL de 3x3 con actualizaciones de estado analógico; comparador de línea base = implementación en Texto Estructurado con bucles `FOR` anidados; ventana de tiempo = pruebas de banco de marzo de 2026. Esto respalda una afirmación limitada sobre la sobrecarga de implementación en esta configuración de prueba. No demuestra que la escalera desplegada sea siempre más rápida en todas las familias de PLC, revisiones de firmware o compiladores.

Esa distinción es importante porque los temporizadores de vigilancia (watchdog) no son filosóficos. Bloquean CPUs reales.

Las matemáticas matriciales son el núcleo computacional del MPC. El controlador predice el comportamiento futuro del proceso a partir de un modelo, evalúa los movimientos de control y actualiza las salidas basándose en la respuesta esperada de múltiples variables interactivas.

La forma estándar de espacio de estados en tiempo discreto es:

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

Donde:

• \(x(k)\) = vector de estado actual
• \(x(k+1)\) = siguiente vector de estado predicho
• \(A\) = matriz del sistema que describe la dinámica interna del proceso
• \(B\) = matriz de entrada que describe cómo las variables manipuladas afectan a los estados
• \(u(k)\) = vector de entrada de control

En términos de PLC, esos objetos se convierten en etiquetas (tags) y arreglos:

• `Matrix_A` almacena los coeficientes de dinámica del proceso
• `Matrix_B` almacena los coeficientes de influencia de entrada
• `Vector_x` almacena los estados actuales medidos o estimados
• `Vector_u` almacena las entradas manipuladas actuales
• `Vector_x_Next` almacena el siguiente estado predicho

La distinción importante es SISO frente a MIMO. Un lazo PID generalmente maneja una variable medida frente a una variable manipulada. El MPC está diseñado para un comportamiento de múltiples entradas y múltiples salidas, donde cambiar un actuador puede influir en varias variables de proceso a la vez. Los sistemas de vapor, redes de tanques, patines térmicos e interacciones de presión-flujo rara vez son lo suficientemente amables como para permanecer desacoplados.

Las ecuaciones de espacio de estados se mapean a la lógica de escalera convirtiendo matrices y vectores en arreglos de PLC, y luego ejecutando cada producto punto explícitamente. La escalera puede representar las matemáticas, pero no las abstrae por usted.

Para un ejemplo compacto de 2x2, la estructura de etiquetas se puede definir de la siguiente manera:

Estructura del diccionario de etiquetas para un sistema 2x2

- `Matrix_A`: Arreglo `REAL` 2D `[0..1, 0..1]` - `Vector_x`: Arreglo `REAL` 1D `[0..1]` - `Vector_x_Next`: Arreglo `REAL` 1D `[0..1]` - `Temp_Mul_00`: `REAL` - `Temp_Mul_01`: `REAL` - `Temp_Mul_10`: `REAL` - `Temp_Mul_11`: `REAL`

• Almacena los coeficientes de dinámica del sistema
• Almacena los estados actuales, como nivel del tanque y temperatura
• Almacena los siguientes valores de estado predichos
• Almacenamiento temporal para `Matrix_A[0,0] * Vector_x[0]`
• Almacenamiento temporal para `Matrix_A[0,1] * Vector_x[1]`
• Almacenamiento temporal para `Matrix_A[1,0] * Vector_x[0]`
• Almacenamiento temporal para `Matrix_A[1,1] * Vector_x[1]`

La regla operativa es simple: cada fila de la matriz se convierte en un cálculo de producto punto, y cada producto punto se convierte en una secuencia de multiplicaciones y sumas explícitas. Elegante en papel; repetitivo en escalera. Al CPU, sin embargo, le importa más la previsibilidad que la elegancia.

En OLLA Lab, esto se vuelve inspeccionable en lugar de teórico. El editor de escalera puede emparejarse con el panel de variables para que un ingeniero pueda observar cada índice de arreglo, registro temporal y valor de estado resultante en tiempo real durante la simulación. Esto es operativamente útil porque le permite verificar no solo que el peldaño (rung) sea sintácticamente válido, sino que las vinculaciones de los arreglos y los valores intermedios sean numéricamente sensatos antes de involucrar cualquier tarjeta de salida real.

La lógica de escalera tiene dificultades con la multiplicación de matrices porque el LD estándar está orientado a instrucciones, no a álgebra. Está diseñado en torno a contactos, bobinas, bloques de funciones y ejecución determinista de peldaños, no álgebra lineal de alta densidad.

Las limitaciones principales suelen ser:

• Sin operador matricial nativo
• Los entornos de escalera estándar generalmente no proporcionan una instrucción única para la multiplicación matriz-vector o matriz-matriz.
• Ergonomía de bucles limitada
• La iteración suele ser más fácil en Texto Estructurado que en Diagrama de Escalera.
• Gran dependencia de etiquetas temporales
• Incluso las operaciones matriciales pequeñas requieren almacenamiento intermedio para cada producto parcial.
• Sensibilidad al ciclo de escaneo
• La aritmética de punto flotante, la indexación de arreglos y los cálculos repetidos consumen un tiempo de ejecución medible.

Eso no significa que la escalera no pueda hacer el trabajo. Significa que el ingeniero debe elegir entre dos estilos de implementación:

### Opción 1: Usar Texto Estructurado para bucles

Esta suele ser la expresión más compacta de las matemáticas. Un bucle `FOR` anidado puede calcular un producto matriz-vector de forma limpia, especialmente cuando las dimensiones pueden cambiar.

Ventajas

• Código más corto
• Más fácil de escalar para matrices más grandes
• Más natural para matemáticas iterativas

Compensaciones

• La sobrecarga de ejecución puede aumentar dependiendo de la plataforma y el comportamiento del compilador
• La visibilidad de depuración puede ser menos obvia para los equipos que viven principalmente en escalera
• Algunos equipos de mantenimiento prefieren una lógica explícita peldaño a peldaño para la resolución de problemas

### Opción 2: Desplegar las matemáticas matriciales en el Diagrama de Escalera

Esto significa escribir cada multiplicación y suma explícitamente.

Ventajas

• Ejecución determinista y visualmente rastreable
• Resolución de problemas a nivel de peldaño más sencilla
• A menudo mejor alineado con las expectativas de mantenimiento en sistemas centrados en escalera

Compensaciones

• Implementación verbosa
• Poca escalabilidad a medida que crece el tamaño de la matriz
• Alto riesgo de errores de copiar y pegar si la disciplina de nombres es débil

Este es el contraste clásico: código compacto frente a ejecución transparente. En un proceso en vivo, la transparencia suele envejecer mejor.

Las matemáticas de punto flotante basadas en arreglos pueden aumentar materialmente el tiempo de ciclo del PLC. Si el tiempo total de ejecución excede el umbral de vigilancia configurado para ese controlador, la CPU puede fallar y detener la ejecución.

Ese es el riesgo real del hardware. No es que "el código se sienta pesado". Es un fallo.

La carga del tiempo de ciclo suele provenir de una combinación de factores:

• Aritmética REAL
• Las operaciones de punto flotante son más costosas que las operaciones de enteros en muchas plataformas PLC.
• Indexación de arreglos
• El acceso indexado añade una sobrecarga de direccionamiento en comparación con las etiquetas escalares fijas.
• Bucles anidados
• La iteración repetida multiplica rápidamente el costo de ejecución.
• Lógica analógica adicional
• El escalado, filtrado, sujeción (clamping) y comprobaciones de alarma a menudo se sitúan alrededor de las matemáticas matriciales en lugar de reemplazarlas.
• Ejecución de ciclo único
• Ejecutar el cálculo completo en cada ciclo puede ser innecesario y costoso.

La configuración del temporizador de vigilancia varía según la familia de controladores y el diseño de la aplicación. Un rango amplio de "típicamente 10–50 ms" es común en la práctica, pero el número relevante es siempre el umbral configurado en el sistema objetivo real. Los estándares no rescatan a un controlador de una aritmética que no puede terminar a tiempo.

Estrategias para la mitigación del tiempo de ciclo

Las principales estrategias de mitigación son arquitectónicas, no cosméticas.

#### 1. Desplegar cálculos críticos

Escriba instrucciones `MUL` y `ADD` explícitas para cada término en matrices pequeñas.

• Mejor para sistemas de dimensiones fijas pequeñas
• Mejora la trazabilidad
• Evita la sobrecarga de bucles en algunos entornos

#### 2. Dividir el cálculo en intervalos de tiempo (Time-slice)

Distribuya el cálculo matricial a través de múltiples ciclos utilizando un índice de paso o una máquina de estados.

• Reduce la carga máxima del ciclo
• Útil para cálculos más grandes
• Introduce latencia que debe tenerse en cuenta en el rendimiento del control

#### 3. Optimizar tipos de datos

Utilice matemáticas de enteros escalados como `DINT` donde la resolución y el rango del proceso lo permitan.

• Puede reducir el costo de ejecución
• Requiere un escalado disciplinado y gestión de desbordamiento
• No siempre aceptable para modelos de proceso de mayor resolución

#### 4. Reducir la frecuencia de ejecución

Ejecute el cálculo predictivo en una tarea periódica más lenta si la dinámica del proceso lo permite.

• Apropiado para sistemas térmicos o de nivel más lentos
• Menos apropiado para movimiento rápido o control de presión estricto
• Debe permanecer consistente con el objetivo de control

#### 5. Precalcular constantes donde sea posible

Almacene coeficientes fijos y evite cálculos repetidos para valores que no cambian de un ciclo a otro.

• Reduce la aritmética innecesaria
• Simplifica la ruta de ejecución en tiempo de ejecución

Vale la pena establecer una corrección práctica claramente: un tiempo de ciclo más rápido no es automáticamente un mejor control. Para el MPC, la pregunta es si la tasa de actualización del control es apropiada para el proceso y sostenible para el controlador. Rápido e inestable sigue siendo inestable.

Un multiplicador matriz-vector 2x2 en escalera se construye calculando un producto punto por índice de salida. Cada elemento de salida es la suma de productos de una fila de la matriz y el vector de entrada.

Suponga:

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

Entonces:

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

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

### Paso 1: Calcular el primer producto parcial para el índice 0

Multiplique `Matrix_A[0,0]` por `Vector_x[0]` y almacene el resultado en `Temp_Mul_00`.

- Fuente A: `Matrix_A[0,0]` - Fuente B: `Vector_x[0]` - Destino: `Temp_Mul_00`

### Paso 2: Calcular el segundo producto parcial para el índice 0

Multiplique `Matrix_A[0,1]` por `Vector_x[1]` y almacene el resultado en `Temp_Mul_01`.

- Fuente A: `Matrix_A[0,1]` - Fuente B: `Vector_x[1]` - Destino: `Temp_Mul_01`

### Paso 3: Sumar los productos para el índice de salida 0

Sume `Temp_Mul_00` y `Temp_Mul_01`, luego almacene el resultado en `Vector_x_Next[0]`.

- Fuente A: `Temp_Mul_00` - Fuente B: `Temp_Mul_01` - Destino: `Vector_x_Next[0]`

### Paso 4: Repetir el patrón para el índice de salida 1

Multiplique y sume la segunda fila:

• `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]`

Concepto de Diagrama de Escalera para la primera fila

|----[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])--|

Concepto multimedia: Instrucciones `MUL` y `ADD` desplegadas para la fila 0 de una matriz de estado 2x2.

Texto alternativo de la imagen: Captura de pantalla del Editor de Lógica de Escalera de OLLA Lab que muestra una multiplicación de matriz 2x2 desplegada en bloques explícitos de MUL y ADD, con el Panel de Variables mostrando los valores de arreglo REAL resultantes para un escenario de control predictivo multivariable.

En OLLA Lab, el flujo de trabajo práctico consiste en construir esta secuencia de peldaños en el editor de escalera basado en navegador, ejecutar el modo de simulación e inspeccionar `Matrix_A`, `Vector_x`, las etiquetas temporales y `Vector_x_Next` en el panel de variables. Eso permite al ingeniero confirmar tres cosas por separado:

• que la aritmética es correcta,
• que las etiquetas están mapeadas correctamente,
• y que el costo del tiempo de ciclo sigue siendo aceptable bajo carga de simulación.

Esa es una distinción útil porque las matemáticas incorrectas y el cableado incorrecto a menudo producen el mismo primer síntoma: una variable de proceso dirigiéndose a algún lugar poco útil.

La corrección matemática es necesaria pero no suficiente. Un cálculo matricial puede ser numéricamente correcto y aun así producir un comportamiento de control deficiente cuando se conecta a una planta simulada con acoplamiento, retardo, saturación y perturbaciones.

Para este artículo, la validación con gemelo digital significa algo operativamente específico: ejecutar la implementación en escalera frente a un modelo de equipo simulado realista, inyectar cambios o fallos controlados y comparar el estado del controlador, el comportamiento de E/S y la respuesta del proceso antes de cualquier despliegue en campo.

En OLLA Lab, ese flujo de trabajo de validación puede incluir:

• vincular la lógica basada en arreglos a un escenario analógico multivariable,
• ajustar las entradas y perturbaciones del proceso en modo de simulación,
• observar el comportamiento de las variables y E/S en tiempo real,
• comparar el estado de la escalera frente al estado del equipo simulado,
• y revisar la implementación después de que aparezca un comportamiento anormal.

Un caso de prueba útil es un proceso acoplado como flujo y presión del tanque o nivel y temperatura. Inyecte un cambio de paso en una variable manipulada, luego verifique si la actualización del estado predicho sigue la respuesta del proceso simulado sin oscilación desbocada, saturación o acoplamiento cruzado inverosímil.

Aquí es donde se debe definir correctamente Listo para Simulación (Simulation-Ready). Un ingeniero listo para la simulación no es simplemente alguien que puede escribir sintaxis de PLC válida. Es un ingeniero que puede probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento realista del proceso antes de que llegue a un proceso en vivo. La sintaxis es fácil de admirar. La capacidad de despliegue es menos indulgente.

¿Qué debe documentar como evidencia de ingeniería?

Si desea demostrar competencia en lógica de PLC avanzada, construya un cuerpo compacto de evidencia de ingeniería en lugar de una galería de capturas de pantalla.

Utilice esta estructura:

• Defina el proceso, los estados, las variables manipuladas y el objetivo de control.

- Establezca qué significa un comportamiento aceptable en términos medibles: tiempo de establecimiento, sobreimpulso acotado, sin fallo de vigilancia, actualización de estado estable, comportamiento correcto de enclavamiento.

• Muestre los peldaños implementados, las etiquetas relevantes y la respuesta de la planta simulada correspondiente.

• Registre la perturbación, el coeficiente incorrecto, el fallo del sensor, el evento de saturación o el estrés de tiempo introducido.

• Explique qué lógica, programación, escalado o cambio de tipo de datos se aplicó.

• Indique qué reveló el fallo sobre el modelo, la implementación o los límites del controlador.

1. Descripción del sistema
2. Definición operativa de "correcto"
3. Lógica de escalera y estado del equipo simulado
4. El caso de fallo inyectado
5. La revisión realizada
6. Lecciones aprendidas

Esa estructura es más valiosa que una captura de pantalla pulida porque demuestra el juicio de ingeniería bajo restricción. A los empleadores y revisores generalmente les importa menos si el peldaño se veía ordenado que si usted sabía qué hacer cuando el modelo se comportaba mal.

Las matemáticas MPC pertenecen al PLC solo cuando el controlador, la estructura de la tarea y la dinámica del proceso lo respaldan. La migración del control avanzado hacia la ejecución local y en el borde (edge) es real, pero eso no significa que cada PLC deba convertirse en un DCS pequeño y sobrecargado.

Mantenga el cálculo en el PLC cuando estas condiciones sean ciertas:

• las dimensiones de la matriz son modestas,
• el tiempo de ejecución está acotado y probado,
• el proceso se beneficia de una respuesta determinista local,
• los equipos de mantenimiento pueden respaldar la implementación,
• y la validación ha mostrado un comportamiento estable bajo perturbaciones realistas.

Mueva el cálculo a un DCS, PC industrial o capa de computación en el borde cuando estas condiciones dominen:

• horizontes de optimización más grandes,
• operaciones matriciales más pesadas,
• actualizaciones frecuentes del modelo,
• recursos de PLC restringidos,
• o un impacto inaceptable en el tiempo de ciclo.

La pregunta de ingeniería no es si el MPC basado en PLC está de moda. Es si la implementación es auditable, determinista y soportable en el hardware objetivo. Esas son palabras menos glamorosas que "IA" u "optimización". También mantienen las plantas funcionando.

Esta implementación abarca la teoría de control, las restricciones de ejecución de PLC, la práctica de simulación y la disciplina de ingeniería adyacente a la seguridad. Ningún estándar único le dice cómo escribir la multiplicación de matrices en escalera, pero varios cuerpos de literatura y estándares dan forma a los límites correctos.

Las referencias relevantes incluyen:

• IEC 61131-3
• Rige los lenguajes de programación de PLC como el Diagrama de Escalera y el Texto Estructurado.
• IEC 61508
• Proporciona el marco más amplio para la seguridad funcional de sistemas eléctricos/electrónicos/electrónicos programables.
• Guía de exida y literatura sobre el ciclo de vida de seguridad
• Útil para comprender la prueba, la disciplina de validación y la separación entre el comportamiento funcional y las declaraciones de seguridad.
• Literatura de IFAC y control de procesos
• Relevante para la arquitectura MPC, el modelado de espacio de estados y la optimización restringida.
• Literatura sobre gemelos digitales y formación en simulación
• Relevante para validar la lógica frente al comportamiento realista de la planta y mejorar la preparación para la puesta en marcha.

Un límite necesario: validar la lógica de control en simulación no establece por sí mismo la idoneidad SIL, el cumplimiento normativo o la competencia del sitio. Mejora la evidencia previa al despliegue. No elimina el resto de la ingeniería.

- IEC 61131-3: Controladores programables — Parte 3 - Familia de estándares de seguridad funcional IEC 61508 - Recursos de validación y seguridad funcional de exida - Recomendación de señalización de estado NAMUR NE 107 - Gemelo digital en la industria: estado del arte (DOI)