Cómo separar la percepción de la IA de la seguridad del PLC: La arquitectura "Médula Oblongata"

La arquitectura "Médula Oblongata" separa la percepción no determinista de la IA del control determinista del PLC. En este modelo, la IA puede proponer puntos de consigna (setpoints) o clasificaciones, pero el PLC sigue siendo la capa de validación y ejecución en tiempo real estricto que impone límites, permisivos, watchdogs y comportamientos de estado seguro antes de que cualquier comando llegue al equipo.

La IA no es un controlador de seguridad, y tratarla como tal es un error de arquitectura antes de que se convierta en un error de puesta en marcha. La distinción útil es simple: la IA es buena en percepción, estimación y optimización; los PLC son buenos en ejecución determinista, enclavamientos y control acotado.

Esa distinción es importante porque los sistemas de control industrial no fallan en abstracto. Fallan como latidos perdidos, valores obsoletos, condiciones de carrera y salidas que se mueven cuando no deberían. La máquina rara vez se impresiona con un modelo ingenioso.

Una prueba de banco interna reciente de Ampergon Vallis respalda el valor práctico de esta separación. Durante un ejercicio de simulación de 100 horas en OLLA Lab, las actualizaciones de puntos de consigna externos asíncronos inyectadas en un escenario de control de bucle cerrado produjeron un aumento del 14% en los eventos de falla por saturación integral (integral windup) en comparación con una ruta de validación de PLC con límites y restricciones de tasa, mientras que la ruta gobernada por PLC mantuvo la varianza de respuesta en un envolvente de ejecución determinista de 3 ms para la secuencia de peldaños de validación. [Metodología: ejecución de prueba simulada de 100 horas; tarea = transferencia de punto de consigna externo a un escenario de control acotado; comparador base = inyección directa de punto de consigna asíncrono sin validación de límite y watchdog; ventana de tiempo = una única ejecución continua de 100 horas.] Esta métrica respalda el valor de la validación defensiva del PLC en simulación. No respalda ninguna afirmación general sobre todos los sistemas de IA, todas las plantas o la certificación de seguridad formal.

La ejecución determinista es necesaria porque las decisiones de seguridad y de control primario deben ocurrir dentro de límites de tiempo conocidos. Los motores de inferencia de IA, ya sean locales o remotos, no garantizan esa propiedad.

Un PLC ejecuta su programa en un ciclo de escaneo acotado. Las entradas se leen, la lógica se resuelve, las salidas se escriben y el ciclo se repite en un intervalo definido. Ese intervalo puede variar ligeramente según la plataforma y la carga del programa, pero está diseñado para seguir siendo predecible y observable. La previsibilidad es el objetivo.

Los sistemas de IA funcionan de manera diferente. Su tiempo de respuesta puede variar con la carga del procesador, la presión de la memoria, el comportamiento del programador, el tamaño del modelo, la limitación térmica, los retrasos del middleware o la latencia de la red. Incluso cuando la inferencia promedio es rápida, el tiempo en el peor de los casos es lo que importa cuando el equipo puede moverse, chocar, llenarse en exceso, sobrecalentarse o no dispararse.

La matemática del ciclo de escaneo frente a la inferencia asíncrona

La distinción de ingeniería no es filosófica. Es temporal.

• Ruta de control del PLC
• Se ejecuta en un ciclo de escaneo repetido
• Admite la evaluación de lógica acotada
• Está diseñada para el manejo determinista de E/S
• Puede ser auditada contra el comportamiento de tiempo y fallas

• Ruta de cómputo de IA
• Se ejecuta de forma asíncrona
• Puede devolver resultados en intervalos irregulares
• Puede estancarse, agotarse el tiempo de espera (timeout), presentar jitter o producir salidas obsoletas
• A menudo depende de pilas de software no diseñadas como lógica de seguridad primaria

En términos prácticos, se puede confiar en que un PLC evalúe un permisivo en cada escaneo. Un servicio de IA puede ser útil, pero no se puede confiar en él de la misma manera. Útil y confiable no son sinónimos. Las plantas aprenden esa distinción de forma costosa cuando la olvidan.

Lo que dicen las normas sobre el control determinista

La norma IEC 61508 establece el marco de seguridad funcional para sistemas eléctricos, electrónicos y electrónicos programables relacionados con la seguridad. Una implicación central para esta discusión es directa: el comportamiento relacionado con la seguridad requiere características de ejecución demostrables, acotadas y validadas.

Eso no significa que cada programa de PLC sea automáticamente seguro. Significa que las funciones de seguridad requieren un diseño determinista, verificación y disciplina de ciclo de vida que los sistemas de IA asíncronos no proporcionan inherentemente. exida y la guía de seguridad funcional relacionada señalan el mismo punto práctico en términos industriales: si una función es crítica para la seguridad, la incertidumbre temporal y el comportamiento inverificable no son inconvenientes menores.

Una corrección concisa es útil aquí: la IA puede ayudar a un sistema relacionado con la seguridad, pero no debe tratarse como la capa de seguridad determinista primaria. No se puede conectar una cortina de luz a un LLM y llamarlo arquitectura.

La arquitectura "Médula Oblongata" es un modelo de control en capas en el que la IA propone y el PLC dispone. La IA realiza la percepción u optimización de alto nivel; el PLC sigue siendo la autoridad en tiempo real estricto que valida, limita, secuencia o rechaza esas solicitudes antes de que el hardware actúe.

La analogía biológica es memorable porque es lo suficientemente precisa estructuralmente como para ser útil. La corteza interpreta y planifica. La médula maneja las funciones de supervivencia autonómicas. En términos de automatización, la IA puede estimar la calidad del producto, detectar objetos o sugerir un ajuste en la tasa de alimentación; el PLC sigue siendo el dueño de los enclavamientos, las cadenas de parada, los permisivos y el accionamiento acotado.

La jerarquía de control

• Interpreta imágenes, tendencias o el contexto de procesos multivariables
• Genera una clasificación, asesoramiento o punto de consigna solicitado
• Opera de forma asíncrona y puede ser incorrecta, retrasada u obsoleta

• Comprueba la solicitud contra límites estrictos
• Verifica el estado de la máquina, los permisivos y los enclavamientos
• Confirma la frescura mediante lógica de latido (heartbeat) o watchdog
• Aplica límites de tasa de cambio, abrazaderas (clamps) y comportamiento de respaldo

• Recibe solo comandos aprobados por el PLC
• Incluye variadores, válvulas, contactores, actuadores y alarmas
• Se mueve a un estado seguro o acotado si la validación falla

1. Capa de percepción (IA)
2. Capa de validación (PLC)
3. Capa de ejecución (Hardware)

Esta no es una posición anti-IA. Es una posición pro-límites. Una buena arquitectura es, en su mayor parte, una negativa disciplinada.

Lo que el PLC siempre debe retener

El PLC debe retener la autoridad absoluta sobre las funciones que requieren una respuesta determinista y un comportamiento de falla acotado.

Esto generalmente incluye:

• Procesamiento de parada de emergencia
• Evaluación de enclavamientos de seguridad
• Permisivos de movimiento
• Lógica de evitación de colisiones
• Límites estrictos de recorrido o velocidad
• Respaldo a estado seguro ante pérdida de comunicación
• Control de secuencia para transiciones peligrosas
• Arbitraje final de comandos a los actuadores

Si una IA solicita un aumento de velocidad, el PLC puede permitirlo, reducirlo, retrasarlo o rechazarlo. La respuesta final pertenece a la capa determinista.

Se programan límites de seguridad de tiempo real estricto tratando las salidas de la IA como entradas externas no confiables. Esto significa que cada valor originado por la IA debe pasar por una lógica defensiva explícita antes de que pueda influir en una máquina o proceso.

Aquí es donde la lógica ladder deja de ser práctica de sintaxis y se convierte en juicio de puesta en marcha. Un peldaño que simplemente "funciona" no es suficiente. El peldaño también debe fallar de manera controlada.

Peldaños defensivos esenciales para el intercambio IA-PLC

#### 1. Temporizador watchdog para supervisión de latido

Un temporizador watchdog verifica que la IA o el sistema de cómputo aguas arriba todavía se esté comunicando dentro de un intervalo aceptable.

- Si el temporizador expira, el PLC:

• La IA envía un bit de latido o un valor incremental
• El PLC reinicia un temporizador TON o equivalente cuando el latido cambia
• invalida la solicitud de la IA,
• fuerza un valor predeterminado seguro,
• eleva una falla o alarma,
• y evita una ejecución adicional hasta que se cumplan las condiciones de recuperación

Un servicio aguas arriba muerto no debería dejar una ruta de salida activa detrás de él. Eso no es inteligencia; eso es residuo.

#### 2. Bloque de límite para sujeción estricta (clamping)

Una instrucción de límite restringe los valores solicitados a una banda operativa físicamente segura.

Casos de uso de ejemplo:

• Limitar la velocidad del motor solicitada entre la velocidad mínima de enfriamiento y la RPM máxima segura
• Limitar la demanda de una válvula a un rango que evite el choque hidráulico
• Limitar un punto de consigna de temperatura a los límites de diseño del equipo

Ejemplo de estructura de lógica ladder:

- Instrucción: LIM (Prueba de límite) - Límite inferior: 15.0 Hz - Prueba: `AI_Requested_Speed` - Límite superior: 45.0 Hz - Salida: `Safe_Speed_Permissive`

El punto no es la elegancia. El punto es que ningún optimismo aguas arriba puede ordenar un exceso de velocidad.

#### 3. Limitación de la tasa de cambio

Un limitador de tasa de cambio evita cambios bruscos de comando que son técnicamente válidos en magnitud pero inseguros en la transición.

Ejemplos:

• Evitar que una válvula se mueva del 10% al 100% en una sola actualización
• Restringir los aumentos de velocidad del VFD a una rampa definida
• Limitar el movimiento del punto de consigna por escaneo o por segundo

Esto importa porque muchas fallas ocurren en la transición, no en el punto final. El número final puede ser legal mientras que el camino hacia él es imprudente.

#### 4. Detección de obsolescencia y validez de secuencia

Un valor puede ser numéricamente plausible y aun así ser operacionalmente inválido.

El PLC debe verificar:

• frescura de la marca de tiempo o conteo de secuencia
• compatibilidad del modo de máquina
• fase actual de operación
• estado del permisivo antes de aplicar la solicitud
• si la solicitud pertenece a la receta activa, paso de lote o estado de secuencia

Un punto de consigna obsoleto durante la fase de secuencia incorrecta es solo una forma educada de datos incorrectos.

Lo que significa "correcto" en esta arquitectura

La corrección debe definirse operacionalmente, no cosméticamente. En este contexto, una integración IA-PLC correcta significa:

• el PLC acepta solo solicitudes frescas y acotadas,
• la máquina se mueve solo cuando los permisivos son verdaderos,
• las transiciones inseguras están bloqueadas,
• la pérdida de comunicación produce un estado de respaldo definido,
• y cada ruta de rechazo es observable en etiquetas, alarmas o lógica de eventos.

Esa definición es más útil que "el peldaño compiló". La compilación es un estándar bajo. El daño al equipo lo supera regularmente.

Se valida el intercambio IA-PLC simulando un comportamiento anormal deliberadamente, y luego probando que la lógica del PLC lo rechaza o lo contiene. La validación no es mostrar que el camino feliz funciona. La validación es mostrar que las entradas incorrectas fallan de manera segura y observable.

Aquí es donde "Listo para simulación" (Simulation-Ready) necesita una definición estricta. Un ingeniero "Listo para simulación" es aquel que puede probar, observar, diagnosticar y endurecer la lógica de control contra el comportamiento realista del proceso antes de que llegue a un proceso real. Ese es un estándar más alto que conocer la sintaxis ladder. Es la diferencia entre dibujar lógica y ponerla en marcha.

Lo que debe probarse antes de la exposición al hardware

Como mínimo, los ingenieros deben probar:

• latido perdido del servicio de IA
• actualizaciones retrasadas y valores obsoletos
• puntos de consigna fuera de rango
• valores inverosímiles pero dentro del rango
• solicitudes oscilantes rápidas
• desajuste de modo entre la solicitud de la IA y el estado de la máquina
• temporización de secuencia de inicio incorrecta
• comportamiento de respaldo tras la restauración de la comunicación

Si esos casos no se han ejercitado, la arquitectura no está validada. Es simplemente esperanzadora.

OLLA Lab es útil aquí como un entorno de validación acotado para ensayar el lado del PLC del riesgo de integración de la IA. No es un certificador de seguridad de IA, y no es un sustituto para la aceptación formal del sitio, la revisión de peligros o la evaluación de seguridad funcional. Es un lugar para practicar las tareas exactas de endurecimiento del control que son demasiado arriesgadas o demasiado costosas para improvisar en equipos reales.

La ventaja práctica es simple: los ingenieros pueden inyectar un comportamiento incorrecto de forma segura y repetida.

Lo que OLLA Lab permite ensayar a los ingenieros

Usando el editor de lógica ladder basado en web, el modo de simulación y el panel de variables, los ingenieros pueden:

• construir lógica ladder que supervise un valor solicitado externo,
• alternar entradas y etiquetas internas en tiempo real,
• observar salidas y permisivos intermedios,
• probar temporizadores, contadores, comparadores, matemáticas y comportamiento relacionado con PID,
• comparar el estado ladder contra la respuesta del equipo simulado,
• y revisar la lógica después de observar una ruta de falla.

Ese flujo de trabajo importa porque las fallas de integración de la IA a menudo aparecen como problemas de temporización y estado, no solo como números incorrectos. OLLA Lab le da a esos problemas un lugar donde hacerse visibles.

Un flujo de trabajo de validación práctico en OLLA Lab

Una secuencia de ensayo creíble se ve así:

• Construir una secuencia de peldaños que reciba un valor de velocidad, flujo o posición solicitado externamente
• Agregar permisivos, comprobaciones de modo y una condición de ejecución final

• Insertar un temporizador watchdog
• Agregar una abrazadera (clamp) usando lógica de límite
• Agregar un limitador de tasa o rampa escalonada
• Definir el comportamiento de respaldo ante tiempo de espera o datos inválidos

• Usar el panel de variables para forzar valores fuera de rango
• Pausar o detener la señal de latido
• Introducir cambios bruscos de comando
• Cambiar el estado del proceso a mitad del comando

• Confirmar que las salidas permanecen acotadas
• Verificar que la lógica de tiempo de espera se dispare correctamente
• Comprobar que las alarmas o bits de falla se vuelvan visibles
• Comparar el comportamiento de la máquina simulada con la filosofía de control esperada

• Ajustar valores de temporizador, límites y condiciones de secuencia
• Volver a probar las mismas fallas hasta que la ruta de rechazo sea determinista y legible

1. Crear la ruta de control
2. Agregar lógica defensiva
3. Inyectar casos anormales
4. Observar causa y efecto
5. Revisar y volver a ejecutar

Aquí es donde OLLA Lab se vuelve operacionalmente útil. Permite a los ingenieros ensayar la lógica de veto, no solo admirarla.

Debe producir un cuerpo compacto de evidencia de ingeniería que demuestre el razonamiento de control bajo falla, no una galería de capturas de pantalla del editor. Las capturas de pantalla prueban que existía una pantalla. No prueban que la lógica se mantuvo bajo estrés.

Use esta estructura:

Establezca los criterios de aceptación exactos: rango operativo permitido, intervalo de tiempo de espera, condiciones permisivas, estado de respaldo y comportamiento de alarma esperado.

Documente la condición anormal introducida: latido obsoleto, solicitud de exceso de velocidad, desajuste de modo, comando oscilante o temporización de secuencia inválida.

Explique qué cambió en la lógica: abrazadera agregada, intervalo de watchdog cambiado, enclavamiento insertado, límite de tasa de cambio agregado o control de secuencia revisado.

1. Descripción del sistema Describa la máquina o celda de proceso, el objetivo de control, la entrada proporcionada por la IA y el rol de seguridad o validación propiedad del PLC.
2. Definición operativa de "correcto"
3. Lógica ladder y estado del equipo simulado Muestre los peldaños, etiquetas y el estado de la máquina o proceso simulado que gobiernan esos peldaños.
4. El caso de falla inyectado
5. La revisión realizada
6. Lecciones aprendidas Indique qué reveló la falla sobre la filosofía de control, las suposiciones de la máquina o la ruta de validez de los datos.

Esa estructura de evidencia es mucho más persuasiva que un clip de demostración pulido. El riesgo de puesta en marcha responde a la prueba, no a la estética.

La IA pertenece aguas arriba del control determinista, no en su lugar. Su rol útil es generar valores de asesoramiento o candidatos a partir de datos complejos que la lógica convencional maneja mal.

Los ejemplos incluyen:

• clasificación basada en visión
• detección de anomalías
• estimación de calidad
• puntuación de mantenimiento predictivo
• recomendaciones de optimización multivariable
• sugerencias de puntos de consigna adaptativos

El PLC luego decide si esas salidas son admisibles en el contexto actual de la máquina.

Una regla arquitectónica limpia

Una regla práctica es esta: la IA puede recomendar; el PLC debe autorizar.

Esa regla preserva las fortalezas de ambas capas:

• La IA maneja la ambigüedad, el reconocimiento de patrones y la optimización
• La lógica del PLC maneja la temporización, los permisivos, los límites y la ejecución determinista

El resultado no es glamoroso, lo cual suele ser una buena señal en los controles. Una buena arquitectura de planta suele parecer un poco aburrida hasta justo antes de que evite un error costoso.

El error más común es permitir que las salidas de la IA omitan la lógica de validación explícita. Una vez que eso sucede, la arquitectura ya ha perdido su disciplina de límites.

Otros errores recurrentes incluyen:

• tratar una marca de tiempo de red como equivalente a la frescura determinista
• asumir que los valores dentro del rango son automáticamente seguros
• olvidar la validación del estado de la secuencia
• omitir el comportamiento de respaldo ante la pérdida de latido
• permitir que las salidas de asesoramiento se conviertan en comandos directos con el tiempo
• probar solo el comportamiento nominal y no las transiciones anormales
• confundir el éxito del simulador con la preparación del sitio

Ese último merece énfasis. La simulación es un entorno de validación, no una declaración de competencia en campo. Es donde los ingenieros aprenden a observar, diagnosticar y endurecer la lógica antes de la exposición real. Útil, necesario y, aun así, no es lo mismo que estar al lado de una línea en funcionamiento a las 2:00 a.m. con mantenimiento esperando.

La forma segura de integrar la IA en la automatización industrial es separar la percepción de la autoridad. La IA puede clasificar, estimar y recomendar. El PLC debe seguir siendo el núcleo de tiempo real estricto que valida, limita, secuencia y veta.

Esa es la arquitectura "Médula Oblongata" en una línea: la IA piensa, el PLC mantiene vivo al organismo.

Para los ingenieros, la tarea práctica no es celebrar las salidas de la IA, sino endurecer la ruta de control a su alrededor. Los watchdogs, límites, permisivos, comprobaciones de tasa de cambio, detección de datos obsoletos y respaldos a estado seguro no son detalles opcionales. Son la arquitectura.

Y si eso suena menos futurista que las presentaciones de marketing, bien. Las máquinas generalmente prefieren a los adultos.

- IEC 61131-3: Controladores programables — Parte 3 - Familia de normas 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)