Cómo convertir pesos de redes neuronales a texto estructurado de PLC para detección de anomalías

Convertir los pesos de una red neuronal a texto estructurado (Structured Text) de PLC implica exportar los pesos y sesgos de un modelo entrenado, reescribirlos como matrices IEC 61131-3 y ejecutar las operaciones matemáticas feedforward de forma determinista dentro del ciclo de escaneo del PLC. El objetivo de ingeniería no es el eslogan de "IA en el control", sino una inferencia acotada y comprobable sin dependencia de redes edge.

Las redes neuronales no se vuelven industrialmente útiles simplemente porque clasifiquen bien los datos en Python. Se vuelven útiles cuando su ruta de ejecución es lo suficientemente predecible para un sistema de control que depende críticamente del tiempo de ciclo (scan time), los límites del watchdog y el comportamiento ante fallos.

Para la detección de anomalías de alta velocidad, enviar datos de proceso a un PC edge externo puede introducir latencia, jitter y un punto de fallo adicional entre la señal y la acción. Esa arquitectura puede ser aceptable para analítica consultiva, pero es menos adecuada cuando la salida del modelo está vinculada a un permiso, disparo o interbloqueo. La tecnología operativa (OT) tiene poca paciencia con arquitecturas elegantes que fallan de forma ineficiente.

Una alternativa acotada es exportar un modelo ligero entrenado —típicamente un perceptrón multicapa superficial— a texto estructurado IEC 61131-3 y ejecutar la inferencia directamente en el controlador.

Métrica de Ampergon Vallis: En una simulación interna de OLLA Lab, un MLP de 3 capas utilizando una matriz de capa oculta de 16x16 en coma flotante añadió 1.2 ms a la ejecución del ciclo simulado durante pruebas de inferencia repetidas. *Metodología: n=25 ejecuciones de simulación de la misma tarea feedforward, comparador de referencia = lógica idéntica sin ejecución de matriz, ventana de tiempo = una sesión de validación de marzo de 2026. Esto respalda la afirmación de que los bloques de inferencia neuronal pequeños pueden probarse para determinar su viabilidad determinista en un entorno tipo PLC. No* demuestra su idoneidad para todos los controladores, todos los presupuestos de tiempo de ciclo ni ninguna función de seguridad.

Ejecutar la inferencia dentro del PLC elimina el transporte de red de la ruta de ejecución crítica. Esa es la razón de ingeniería central.

Un PC edge puede ser adecuado para monitoreo no crítico, analítica de historiadores o paneles de mantenimiento. Es una propuesta diferente cuando la salida del modelo debe participar en una decisión de control determinista. Si el enlace de red cae, la ruta de inferencia cae con él. El problema no es que la computación edge sea incorrecta; el problema es que la lógica de control es menos permisiva que la arquitectura de analítica.

La distinción es simple:

• La inferencia edge suele ser asíncrona, dependiente de la red y programada fuera del ciclo del PLC.
• La inferencia residente en PLC es determinista solo si el tiempo de ejecución, el uso de memoria y el comportamiento ante fallos están acotados dentro de la tarea del controlador.

Para la detección de anomalías vinculada a un permiso de motor, inhibición de válvula o retención de secuencia, la localidad determinista es fundamental. Un resultado que llega tarde suele ser funcionalmente equivalente a no obtener ningún resultado.

¿Qué contexto normativo es relevante aquí?

Las normas de seguridad funcional no respaldan suposiciones de temporización casuales. La norma IEC 61508 se preocupa por el comportamiento predecible, la ejecución validada y la respuesta conocida ante fallos, no por si un modelo parece impresionante en un cuaderno de notas.

Esto requiere un límite cuidadoso:

• Incrustar una red neuronal en texto estructurado no la convierte automáticamente en una función de seguridad.
• Puede respaldar una lógica de monitoreo de procesos determinista si su ejecución está validada, acotada y segregada adecuadamente.
• Si la salida influye en una acción relacionada con la seguridad, la carga de la verificación aumenta drásticamente. "Funcionó en la simulación" no es un caso de seguridad.

Una idea errónea común es que poner IA dentro del PLC la hace automáticamente más industrial. Solo la acerca al ciclo de escaneo. La parte difícil sigue siendo la prueba.

Solo los modelos feedforward pequeños son prácticos en la mayoría de los contextos de PLC. Ese es el límite útil.

El candidato más común es un perceptrón multicapa (MLP) superficial entrenado fuera de línea en MATLAB, Python o un entorno similar, y luego exportado como pesos y sesgos estáticos. Esto funciona porque la inferencia para un MLP fijo es solo aritmética:

• multiplicación de matrices
• suma de sesgos
• evaluación de funciones de activación
• lógica de umbral o clasificación

Esa aritmética es tediosa pero determinista.

Los modelos con más probabilidades de encajar son:

• MLP de una sola capa oculta o superficiales
• Vectores de entrada pequeños
• Recuentos limitados de nodos ocultos
• Funciones de activación simples, como ReLU o aproximaciones lineales acotadas

Los modelos con menos probabilidades de encajar limpiamente son:

• redes recurrentes
• modelos convolucionales grandes
• arquitecturas transformer
• cualquier cosa que requiera comportamiento de memoria dinámica, bibliotecas no compatibles o un rendimiento sustancial en coma flotante

Esto no es una declaración sobre la capacidad de la IA en general. Es una declaración sobre la economía del controlador y la disciplina del ciclo de escaneo.

El proceso de conversión es sencillo en concepto e implacable en los detalles. La mayoría de los fallos no son matemáticos. Son fallos de indexación, escalado, tipo de datos o tiempo de tarea.

### Paso 1: Entrenar un modelo ligero fuera de línea

Entrene el modelo en MATLAB, Python u otro entorno de ML utilizando datos históricos de proceso o datos de eventos etiquetados.

Los buenos candidatos para el despliegue en PLC suelen tener:

• entradas numéricas normalizadas
• recuento de características limitado
• envolventes de operación estables
• etiquetas de anomalía claras o lógica de umbral
• una ruta de inferencia que pueda explicarse y acotarse

Si el modelo necesita una GPU de escritorio para ejecutarse cómodamente, generalmente no pertenece a una tarea de controlador estándar.

### Paso 2: Exportar pesos y sesgos

Extraiga los parámetros entrenados del modelo:

• matriz de pesos de entrada a capa oculta
• vector de sesgos de la capa oculta
• matriz de pesos de capa oculta a salida
• vector de sesgos de la capa de salida

Los formatos de exportación típicos incluyen:

• CSV
• JSON
• Matrices de MATLAB
• Matrices NumPy de Python escritas en texto

En esta etapa, conserve:

• dimensiones de las matrices
• orden de filas/columnas
• precisión numérica
• constantes de normalización de entrada
• valores de umbral de salida

Un número sorprendente de problemas de despliegue son, en realidad, solo matrices transpuestas.

### Paso 3: Convertir los parámetros en matrices compatibles con IEC 61131-3

Reescriba los parámetros del modelo como matrices de texto estructurado utilizando tipos de datos compatibles con el controlador, típicamente `REAL` o `LREAL` según la capacidad de la plataforma y el presupuesto del ciclo de escaneo.

Ejemplo de mapeo de formas:

• `W1[NodosOcultos, NodosEntrada]`
• `B1[NodosOcultos]`
• `W2[NodosSalida, NodosOcultos]`
• `B2[NodosSalida]`

Defina también:

• matrices de vectores de entrada
• matrices de suma de nodos intermedios
• matrices de salida de activación
• matrices de salida de inferencia final

La elección del tipo de datos importa. `LREAL` puede mejorar la fidelidad numérica, pero también puede aumentar el costo de ejecución dependiendo de la arquitectura del controlador.

### Paso 4: Recrear el paso feedforward en texto estructurado

Implemente el modelo como aritmética explícita:

1. inicialice cada suma de nodo con su sesgo
2. acumule los productos de entrada ponderados
3. aplique la función de activación
4. pase las salidas activadas a la siguiente capa
5. compare la salida final con un umbral o regla de clasificación

Aquí es donde el modelo se convierte en un bloque aritmético determinista.

### Paso 5: Recrear la lógica de preprocesamiento y salida

Un modelo entrenado con entradas normalizadas debe recibir entradas normalizadas en el PLC. De lo contrario, la inferencia es matemáticamente correcta y operacionalmente incorrecta.

Debe implementar:

• escalado
• corrección de offset
• limitación (clamping) si es necesario
• manejo de señales faltantes
• umbral de salida
• comportamiento en estado de fallo si el bloque de inferencia recibe datos no válidos

Un modelo sin su ruta de preprocesamiento no está desplegado. Solo está copiado.

La multiplicación de matrices en texto estructurado se implementa generalmente con bucles `FOR` anidados y acumulación explícita en matrices de suma de nodos. El objetivo es la corrección, el determinismo y la visibilidad del tiempo de ciclo.

Ejemplo: suma ponderada de capa oculta

Lenguaje: Texto estructurado

// Suma ponderada de capa oculta FOR i := 0 TO HiddenNodes - 1 DO NodeSum[i] := Bias1[i]; FOR j := 0 TO InputNodes - 1 DO NodeSum[i] := NodeSum[i] + (InputArray[j] * Weight1[i, j]); END_FOR; END_FOR;

Este código realiza el producto escalar entre el vector de entrada y la fila de pesos de cada neurona de la capa oculta, y luego añade el sesgo correspondiente.

Comprobaciones de implementación importantes:

• confirme si su PLC utiliza convenciones de matriz basadas en cero o en uno
• mantenga las dimensiones de las matrices explícitas
• inicialice las sumas antes de la acumulación
• evite la conversión de tipos oculta
• pruebe el tiempo de ejecución en el peor de los casos, no solo el tiempo de ejecución nominal

Un bucle que funciona una vez es una demostración. Un bucle que funciona a la velocidad de la tarea bajo entradas con ruido es ingeniería.

¿Cómo se calcula la capa de salida?

La capa de salida sigue el mismo patrón aplicado a las activaciones de la capa oculta.

Lenguaje: Texto estructurado

// Suma ponderada de capa de salida FOR i := 0 TO OutputNodes - 1 DO OutputSum[i] := Bias2[i]; FOR j := 0 TO HiddenNodes - 1 DO OutputSum[i] := OutputSum[i] + (HiddenOutput[j] * Weight2[i, j]); END_FOR; END_FOR;

Para una puntuación de anomalía única, `OutputNodes` puede ser `1`, comparando la puntuación final contra un umbral.

ReLU es una de las funciones de activación más fáciles de traducir porque es lineal a trozos. En texto estructurado, se convierte en un condicional simple.

Lenguaje: Texto estructurado

// Activación ReLU FOR i := 0 TO HiddenNodes - 1 DO IF NodeSum[i] < 0.0 THEN HiddenOutput[i] := 0.0; ELSE HiddenOutput[i] := NodeSum[i]; END_IF; END_FOR;

Esto preserva la regla básica de ReLU:

• si la entrada < 0, la salida = 0
• de lo contrario, la salida = entrada

Esa simplicidad es útil en los PLC porque evita funciones no lineales más costosas.

¿Qué otros enfoques de activación son prácticos?

Las opciones prácticas dependen de la capacidad del controlador, pero los enfoques comunes incluyen:

- ReLU: el más simple para implementación directa - Activación lineal: útil para salidas de tipo regresión - Aproximación a trozos: utilizada a veces cuando se necesita una función no lineal suave pero el soporte matemático nativo es limitado

Las opciones menos prácticas en muchos PLC incluyen:

• cálculos exactos de sigmoide o tanh utilizando exponenciales costosas
• esquemas de activación dinámicos que requieren bibliotecas no compatibles
• arquitecturas que dependen del comportamiento del grafo en tiempo de ejecución

En el trabajo de control, el comportamiento acotado suele superar al comportamiento elegante pero no comprobable.

La detección de anomalías se vuelve operacionalmente significativa solo cuando la salida está vinculada a una acción de control definida. "El modelo produjo 0.83" aún no es un resultado de ingeniería.

Una implementación utilizable necesita:

• una puntuación de anomalía definida
• un umbral o regla de clasificación
• una regla de debounce o persistencia si se espera ruido
• una respuesta de control clara

Por ejemplo:

- establecer `AnomalyDetected := TRUE` - desactivar `MotorRunPermissive := FALSE`

• si la puntuación de anomalía > umbral durante 500 ms
• enclavar una alarma
• requerir un reinicio del operador o supervisor según la filosofía

Esa lógica debe documentarse en términos de control, no en términos de ML.

Definición operativa de detección de anomalías

En este artículo, detección de anomalías significa:

> leer un conjunto acotado de entradas de proceso, ejecutar un bloque de inferencia feedforward determinista dentro de la tarea del PLC, comparar la puntuación resultante con un umbral definido y cambiar una variable de estado de control, como un permiso, alarma o retención de secuencia, cuando se cumple la condición de umbral.

Esa definición es intencionalmente estrecha. Es observable, comprobable y adecuada para la validación.

Los riesgos principales son el desbordamiento del ciclo de escaneo (scan overrun), el desajuste numérico y la falsa confianza.

1. Riesgo de tiempo de ciclo y watchdog

La aritmética de matrices consume tiempo de tarea. Si el bloque de inferencia es demasiado grande o está mal estructurado, puede activar fallos de watchdog o degradar la capacidad de respuesta del control.

Los factores de riesgo incluyen:

• matrices grandes
• ejecución frecuente en tareas rápidas
• uso intensivo de coma flotante
• normalización y escalado repetidos dentro del mismo ciclo
• recomputación innecesaria

Las mitigaciones incluyen:

• reducir el tamaño del modelo
• mover la inferencia a una tarea periódica más lenta cuando sea apropiado
• precomputar constantes
• utilizar pruebas de ejecución acotadas
• validar el impacto en el ciclo de escaneo en el peor de los casos antes del despliegue

2. Desajuste de tipo de datos y precisión

Un modelo entrenado en `float64` y desplegado en `REAL` puede comportarse de manera diferente en los umbrales. Esa diferencia puede ser pequeña numéricamente y grande operacionalmente.

Compruebe:

• rango numérico
• consistencia del escalado
• sensibilidad del umbral
• comportamiento de coma flotante específico del controlador

3. Errores de indexación y orientación de matrices

Una matriz transpuesta, un índice desplazado o un mapeo de sesgos incorrecto pueden producir salidas que parecen plausibles siendo completamente erróneas.

Por eso la validación determinista es importante. Los errores aritméticos suelen ser lo suficientemente educados como para compilar.

4. Comportamiento ante entradas no válidas

Un sensor faltante, un valor obsoleto, un transmisor saturado o un escalado analógico incorrecto pueden corromper la inferencia.

Defina:

• qué sucede ante una mala calidad de señal
• si el bloque se inhibe a sí mismo
• si la salida falla de forma segura, falla de forma neutral o solo genera alarmas
• si el resultado se ignora durante estados de mantenimiento o arranque

5. Uso indebido en contextos de seguridad

Un bloque de inferencia neuronal no debe describirse como clasificado para seguridad simplemente porque está dentro de un PLC. Si influye en una función relacionada con la seguridad, las obligaciones de diseño, verificación y ciclo de vida se vuelven sustancialmente más exigentes.

OLLA Lab es útil aquí como un entorno de validación acotado para tareas de puesta en marcha de alto riesgo. No es un atajo para las pruebas del controlador y no sustituye la aceptación en sitio. Es donde usted ensaya los modos de fallo antes de que el hardware y el tiempo de proceso se vuelvan costosos.

En este caso de uso, OLLA Lab puede apoyar a los ingenieros proporcionando:

• un entorno de lógica basado en navegador para construir y revisar la lógica de control
• modo de simulación para ejecutar, detener y observar el comportamiento sin hardware físico
• visibilidad de variables y E/S para rastrear valores intermedios
• pruebas basadas en escenarios realistas contra el comportamiento del equipo simulado
• flujos de trabajo de validación tipo gemelo digital donde la lógica puede compararse con la respuesta esperada de la máquina

Para el flujo de trabajo de este artículo, el valor práctico es claro:

• escribir la lógica de inferencia
• vincular entradas a variables de proceso simuladas
• inyectar perturbaciones o condiciones anormales
• observar cambios en el estado de salida
• comprobar si la respuesta de control coincide con la filosofía prevista

Eso es lo que debería significar Simulation-Ready en términos operativos: un ingeniero que puede probar, observar, diagnosticar y endurecer la lógica de control contra el comportamiento real del proceso antes de que llegue a un proceso en vivo.

¿Qué significa aquí la validación de gemelo digital?

En este contexto acotado, validación de gemelo digital significa probar la lógica de control contra un modelo de equipo simulado realista para que el ingeniero pueda comparar:

• estado de lógica ladder o texto estructurado
• estado de E/S
• respuesta del proceso
• manejo de condiciones anormales
• acción de control resultante

No significa que el modelo simulado sea automáticamente una réplica perfecta del comportamiento en sitio. Significa que la lógica puede ensayarse contra la dinámica de la máquina o proceso representativo antes del despliegue en campo.

Un flujo de trabajo práctico es tratar la red neuronal como un bloque dentro de una narrativa de control más amplia en lugar de como un objeto novedoso.

Una secuencia de validación representativa sería:

1. Construir el bloque de inferencia Implemente los pesos exportados, sesgos, normalización y lógica de umbral en texto estructurado o un flujo de trabajo de lógica de control compatible equivalente.
2. Vincular las entradas a señales de proceso simuladas Mapee las entradas del modelo a variables como vibración, corriente del motor, aumento de temperatura, fluctuación de presión o inestabilidad de flujo.
3. Definir el estado normal esperado Confirme que la salida del modelo permanece por debajo del umbral durante la operación saludable.
4. Inyectar una condición anormal Introduzca una perturbación como vibración oscilatoria, pico de sensor, deriva, o comportamiento de carga inestable.
5. Observar la salida de inferencia y la respuesta de control Verifique que la puntuación de anomalía cruce el umbral solo cuando se pretende, y que el permiso, alarma o estado de secuencia cambien correctamente.
6. Medir la carga de la lógica Revise si la aritmética añadida crea un costo de ejecución inaceptable o un comportamiento inestable.

Esa secuencia importa porque la detección de anomalías solo es útil cuando está vinculada a una consecuencia del proceso. Una puntuación sin una ruta de acción es solo un número.

Una galería de capturas de pantalla es una evidencia débil. Un registro de validación compacto es más útil para revisores, instructores y empleadores porque muestra razonamiento, no solo familiaridad con la interfaz.

Utilice esta estructura:

Registre qué cambió después de la primera prueba: ajuste de umbral, lógica de debounce, corrección de escalado, ubicación de la tarea u optimización de matriz.

1. Descripción del sistema Describa el equipo, el objetivo del proceso, las entradas relevantes y dónde se sitúa el bloque de detección de anomalías en la filosofía de control.
2. Definición operativa del comportamiento correcto Establezca exactamente qué debe hacer la lógica bajo condiciones normales y anormales, incluyendo umbrales, temporización y estados de salida esperados.
3. Estado de la lógica y del equipo simulado Muestre la lógica implementada y el comportamiento correspondiente de la máquina o proceso simulado durante la prueba.
4. El caso de fallo inyectado Documente la perturbación introducida, como ruido de sensor, deriva, oscilación o carga anormal.
5. La revisión realizada
6. Lecciones aprendidas Resuma lo que la prueba reveló sobre la capacidad de despliegue, falsos positivos, carga de escaneo o filosofía de control.

Ese cuerpo de evidencia está mucho más cerca del juicio de puesta en marcha que una captura de pantalla pulida.

El despliegue debe estar limitado por una verificación acotada, no por entusiasmo.

Utilice una lista de verificación previa al despliegue:

• El tamaño del modelo es apropiado para el controlador y la velocidad de la tarea
• El escalado de entrada coincide con las condiciones de entrenamiento
• Los pesos y sesgos están mapeados correctamente
• La lógica de activación está implementada exactamente como se pretende
• El comportamiento del umbral está documentado
• El manejo de entradas incorrectas está definido
• Se ha probado el tiempo de ejecución en el peor de los casos
• Se ha verificado la respuesta de control ante la anomalía
• Se ha definido el comportamiento de respaldo si el bloque de inferencia no es válido
• Se han planificado las pruebas de puesta en marcha específicas del sitio

Si el modelo no puede superar esta lista de verificación, no está listo para el PLC. Puede seguir siendo útil en otros lugares.

Este enfoque resuelve un problema específico de OT: cómo ejecutar un modelo pequeño entrenado de forma determinista dentro de un entorno de control tipo PLC sin depender de una infraestructura de inferencia externa.

Puede ayudar con:

• puntuación de anomalías de baja latencia
• inferencia local acotada
• reducción de la dependencia de la red en las decisiones de control
• validación de la aritmética del modelo contra el comportamiento realista del proceso

No resuelve:

• certificación de seguridad por implicación
• gobernanza del modelo por sí misma
• puesta en marcha específica de la planta solo mediante simulación
• idoneidad de arquitecturas neuronales grandes o complejas para hardware de PLC estándar

Ese límite vale la pena mantenerlo limpio.

Convertir los pesos de una red neuronal a texto estructurado de PLC es técnicamente viable cuando el modelo es pequeño, la ruta aritmética es explícita y la carga de ejecución se valida contra las restricciones del controlador. El punto no es hacer que los PLC imiten entornos de Python. El punto es colocar una función de inferencia acotada donde la respuesta determinista importa más.

La secuencia de ingeniería es clara:

• entrenar fuera de línea
• exportar pesos y sesgos
• reescribirlos como matrices IEC 61131-3
• implementar la matemática feedforward y la lógica de activación
• validar el impacto en el escaneo y el comportamiento ante fallos
• probar la consecuencia del control contra condiciones de proceso simuladas realistas

Aquí es donde OLLA Lab se vuelve operacionalmente útil. Proporciona un lugar para ensayar lógica pesada en matrices, observar el comportamiento de E/S y variables, inyectar condiciones anormales y endurecer el diseño antes de la puesta en marcha en vivo. Ese es un uso creíble de la simulación: no reemplazar la prueba en campo, sino hacer que la prueba en campo sea menos imprudente.

- IEC 61131-3: Controladores programables — Parte 3: Lenguajes de programación - IEC 61508 Visión general de la seguridad funcional - Marco de gestión de riesgos de IA del NIST (AI RMF 1.0) - Revisión de gemelos digitales (IFAC-PapersOnLine) - IA industrial en la Industria 4.0 (Manufacturing Letters)