Cómo empaquetar el contexto de un manual de PLC de 1000 páginas para un copiloto de IA

El empaquetado de contexto en la automatización industrial es la transferencia estructurada de restricciones de control, definiciones de E/S, dialecto del fabricante y lógica operativa hacia un flujo de trabajo de IA. Es importante porque los modelos de lenguaje extenso pueden pasar por alto detalles críticos dentro de manuales extensos de fabricantes (OEM), mientras que los sistemas específicos de dominio como Yaga reducen esa carga de recuperación mediante el uso de contexto industrial preindexado y estados de simulación en tiempo real.

La IA genérica no falla en el trabajo con PLC simplemente porque los manuales sean extensos. Falla porque los documentos de control son densos, de propósito mixto y operativamente desiguales: una página contiene una dimensión de montaje, la siguiente contiene un umbral de disparo que puede detener un proceso. La capacidad de tokens no es lo mismo que el criterio de ingeniería.

En un benchmark interno de 2026 de Ampergon Vallis, la salida de un LLM genérico produjo errores de sintaxis o de referencia de etiquetas en el 41% de las tareas de generación de lógica de escalera (ladder logic) cuando se le solicitó a partir de un manual de variador OEM de 1200 páginas, mientras que los flujos de trabajo asistidos por Yaga en OLLA Lab redujeron esa tasa al 2,4% para la misma clase de tarea acotada. Metodología: n=84 tareas de prompt-respuesta; definición de tarea = generar o revisar lógica de escalera para permisivos de variador, fallos y manejo de estado de ejecución; comparador de referencia = LLM de frontera genérico con prompts derivados de PDF manuales; ventana de tiempo = enero-febrero de 2026. Esto respalda una afirmación limitada sobre la reducción de errores en un flujo de trabajo definido. No prueba una superioridad universal en todas las tareas de PLC, fabricantes o modelos.

El problema práctico es familiar: los ingenieros no necesitan más palabras de un copiloto; necesitan la restricción correcta para sobrevivir al ciclo de escaneo. Ese es un problema más pequeño y menos glamuroso. También es el que importa.

El empaquetado de contexto es la estructuración deliberada de las restricciones de la máquina, el proceso y la programación para que un sistema de IA pueda generar o evaluar la lógica de control frente a la realidad operativa real del sistema. En control, esto significa proporcionar al modelo los hechos que determinan si la lógica es simplemente plausible o realmente desplegable.

Una definición operativa útil es esta: el empaquetado de contexto es la conversión de conocimiento de ingeniería disperso en una especificación acotada y procesable mediante prompts. Esa especificación debe decirle a la IA qué es el sistema, cómo se le permite comportarse, qué etiquetas existen, qué estados son legales y qué modos de fallo deben prevalecer.

Esto no es lo mismo que adjuntar un PDF. Subir un manual le da al modelo acceso al texto. No garantiza una ponderación de prioridad, comprensión de secuencias o razonamiento de estados seguros. La recuperación semántica no es filosofía de control. La distinción es árida, pero costosa cuando se ignora.

¿Cuáles son los tres pilares de un prompt de automatización?

Un prompt de automatización utilizable generalmente necesita tres pilares:

• Restricciones de hardware
• Familia de controlador y entorno de programación
• Comportamiento de escaneo y supuestos de ejecución
• Memoria disponible o modelo de etiquetas
• Características de E/S físicas
• Registros específicos del dispositivo, palabras de estado y bits de fallo

• Filosofía de control
• Secuencia de operaciones
• Permisivos e interbloqueos
• Estados a prueba de fallos (fail-safe)
• Comportamiento de alarmas y disparos
• Comportamiento en modo manual frente a automático
• Condiciones de reinicio tras fallo o pérdida de potencia

- Lenguaje IEC 61131-3 utilizado: LD, ST, FBD, SFC, etc.

• Dialecto del fabricante
• Sintaxis y direccionamiento específicos de la plataforma
• Preferencias o prohibiciones de instrucciones
• Convenciones de nomenclatura y estructuras de etiquetas

En otras palabras, el modelo necesita conocer tanto la gramática como la planta. Una sin la otra es cómo se obtiene un sinsentido elegante.

Los copilotos de IA genéricos fallan porque el acceso a contextos largos no garantiza una recuperación estable del detalle correcto en el momento adecuado. Trabajos recientes de PNL sobre el efecto "perdido en el medio" muestran que los modelos pueden degradar su precisión de recuperación cuando la información crítica está enterrada dentro de contextos largos en lugar de colocarse cerca del principio o del final del prompt (Liu et al., 2024). Eso importa directamente en la documentación OEM, donde el registro que importa puede estar entre notas de instalación y tablas de mantenimiento.

Los manuales OEM también son estructuralmente hostiles a los prompts ingenuos. Típicamente combinan:

• detalles de instalación mecánica,
• diagramas de cableado,
• mapas de parámetros,
• tablas de protocolos,
• procedimientos de puesta en marcha,
• definiciones de alarmas,
• notas de seguridad,
• y ejemplos de software dispersos.

Un LLM no sabe intrínsecamente que una categoría de parada, una retroalimentación de prueba o una condición de reinicio de fallo deben tener prioridad sobre una dimensión de armario. A menos que el prompt imponga esa jerarquía, el modelo trata todo el texto como candidato a recuperación. Ese es un problema de lenguaje primero y un problema de control segundo.

¿Por qué los dialectos de los fabricantes empeoran el problema?

La variación entre fabricantes rompe la ilusión de que la norma IEC 61131-3 por sí sola es suficiente. El estándar define familias de lenguajes y conceptos, pero la implementación práctica está fuertemente moldeada por el fabricante.

Ejemplos:

- Los entornos de Rockwell a menudo dependen de estructuras basadas en etiquetas como `Local:1:I.Data`.

• El direccionamiento de memoria de Siemens puede usar formas como `%M`, `%I` y `%Q`.
• Los flujos de trabajo de Beckhoff TwinCAT pueden esperar diferentes nombres, supuestos de tareas y convenciones de ST.
• El comportamiento de los bloques de función, la semántica de los temporizadores y las expectativas de las bibliotecas pueden variar materialmente según la plataforma.

Un modelo genérico puede producir una lógica de escalera o ST sintácticamente plausible que es incorrecta para el entorno de destino. Esta es la versión de control de hablar la gramática correcta en el dialecto equivocado. Suena bien hasta que alguien intenta compilarlo.

¿Por qué RAG por sí solo no resuelve el razonamiento de control?

La generación aumentada por recuperación (RAG) mejora el acceso a los documentos, pero no produce automáticamente un razonamiento consciente de la secuencia o de la seguridad. RAG puede recuperar un párrafo sobre un permisivo. No garantiza que el modelo coloque ese permisivo en el peldaño (rung) correcto, asigne la dominancia adecuada sobre los comandos manuales o preserve la secuencia de puesta en marcha prevista.

Para el trabajo de control, la parte difícil a menudo no es encontrar la oración. Es preservar la jerarquía lógica:

• qué debe suceder primero,
• qué nunca debe suceder al mismo tiempo,
• qué se desactiva ante un fallo,
• y qué debe ser reconocido manualmente antes del reinicio.

Esa jerarquía a menudo está implícita en múltiples documentos. RAG genérico es un mecanismo de recuperación, no una mentalidad de puesta en marcha.

Un prompt basado en especificaciones debe restringir al modelo antes de que escriba un solo peldaño. El objetivo es reducir las alucinaciones reemplazando la generación abierta por una interpretación de ingeniería acotada.

La estructura mínima del prompt se muestra a continuación.

| Sección del Prompt | Entrada de Ingeniería | Expectativa de Salida de la IA | |---|---|---| | Asignación de Rol | "Actúa como un ingeniero de control generando lógica de escalera IEC 61131-3 para una plataforma definida." | Reduce el estilo y la familia de lenguaje. | | Definición de Plataforma | "Objetivo: Rockwell Studio 5000" o equivalente | Evita la deriva de sintaxis entre fabricantes. | | Descripción del Sistema | Describir la máquina o proceso y el objetivo operativo | Ancla la lógica al comportamiento físico. | | Definición de Estado | Definir estados legales y estado de fallo | Evita modelos de estado arbitrarios. | | Mapeo de E/S | Diccionario de etiquetas exacto con tipos de entrada/salida | Reduce la alucinación de etiquetas. | | Permisivos e Interbloqueos | Condiciones de inicio, parada, disparos, pruebas | Preserva la jerarquía de control. | | Restricciones de Instrucción | Instrucciones permitidas y no permitidas | Evita patrones no estándar. | | Comportamiento ante Fallos | Reglas de reinicio, reglas de enclavamiento, manejo de alarmas | Fuerza el manejo de estados anormales. | | Formato de Salida | "Devolver explicación peldaño a peldaño más supuestos" | Mejora la capacidad de revisión. |

¿Qué debería contener realmente un buen prompt de PLC?

Un buen prompt de PLC debería contener lo siguiente, en este orden:

1. Plataforma y lenguaje de destino
2. Descripción del sistema
3. Definición operativa del comportamiento correcto
4. Diccionario exacto de E/S y etiquetas
5. Secuencia de operaciones
6. Interbloqueos, disparos y comportamiento a prueba de fallos
7. Restricciones de instrucciones
8. Formato de salida esperado
9. Solicitud de supuestos explícitos y ambigüedades no resueltas

Ese cuarto punto importa más de lo que muchos usuarios esperan. Si el diccionario de etiquetas es vago, la salida será vaga. Los modelos son generosos con etiquetas inventadas. Las plantas no.

Ejemplo de un prompt compacto basado en especificaciones

Lenguaje: Estructura de Prompt de IA

SISTEMA: Estás generando lógica de escalera IEC 61131-3 para una rutina de control de motor.

PLATAFORMA: Solo lógica de escalera Rockwell Studio 5000.

DESCRIPCIÓN DEL SISTEMA: Controlar un motor trifásico con pulsadores de marcha/paro, fallo de sobrecarga, retroalimentación de marcha y selector HOA. El motor solo puede funcionar en AUTO o MAN (HAND) cuando no hay ningún fallo activo. En AUTO, el comando de marcha proviene de Process_Run_Request. En MAN, el Start_PB local controla la marcha, pero la sobrecarga y la parada de emergencia (E-stop) siguen dominando.

DEFINICIÓN OPERATIVA DE LO CORRECTO:

• El motor arranca solo cuando los permisivos son verdaderos.
• Cualquier E-stop o sobrecarga desactiva la salida inmediatamente.
• La pérdida de retroalimentación de marcha tras el retardo de arranque genera un fallo y desactiva el comando.
• El reinicio de fallo requiere Reset_PB y que todas las condiciones inseguras se hayan despejado.

MAPEADO DE E/S: Start_PB, Stop_PB, Reset_PB, HOA_Auto, HOA_Hand, EStop_OK, OL_OK, Run_Fbk, Process_Run_Request, Motor_Cmd, Motor_Fault

RESTRICCIONES:

• Usar lógica de sellado (seal-in), no latch/unlatch.
• Separar el peldaño de permisivos del peldaño de comando.
• Mostrar el peldaño de detección de fallos.
• No inventar etiquetas.

SALIDA: Devolver la intención de la lógica de escalera peldaño a peldaño, uso de etiquetas y supuestos que necesiten revisión de ingeniería.

Esto no hará que un modelo genérico sea determinista, pero hará que sea menos libre para improvisar. En control, eso es progreso.

Lista para la simulación (Simulation-Ready) debe definirse operacionalmente, no retóricamente. Una rutina de control está lista para la simulación cuando un ingeniero puede probar, observar, diagnosticar y endurecer su comportamiento frente a condiciones de proceso realistas antes de que llegue a un sistema real.

Eso significa que la lógica ha superado la sintaxis y ha entrado en la validación. La distinción clave es sintaxis frente a desplegabilidad.

Una revisión de "Lista para la simulación" debería responder a estas preguntas:

• ¿Puede la lógica ejecutarse frente a un modelo de equipo realista?
• ¿Se pueden alternar las entradas y observar las salidas en secuencia temporal?
• ¿Se pueden inspeccionar valores analógicos, temporizadores, contadores y comportamiento relacionado con PID?
• ¿Se pueden inyectar estados anormales deliberadamente?
• ¿Puede el ingeniero rastrear por qué cambió una salida, no solo que cambió?
• ¿Se puede revisar la lógica después de un fallo y volver a probarla bajo las mismas condiciones?

Aquí es donde muchos flujos de trabajo de IA siguen siendo débiles. Producen lógica candidata, pero no producen naturalmente evidencia de ingeniería.

¿Qué evidencia de ingeniería debería conservar?

Si desea demostrar competencia real, construya un cuerpo compacto de evidencia de ingeniería en lugar de una galería de capturas de pantalla. Utilice esta estructura:

1. Descripción del Sistema Defina la máquina o proceso, el objetivo operativo y el alcance.
2. Definición operativa de "correcto" Declare qué debe suceder en condiciones normales, de arranque, parada y fallo.
3. Lógica de escalera y estado del equipo simulado Muestre la lógica junto con las E/S simuladas o el comportamiento del equipo.
4. El caso de fallo inyectado Documente la condición anormal introducida deliberadamente.
5. La revisión realizada Registre el cambio de lógica y por qué fue necesario.
6. Lecciones aprendidas Capture lo que la prueba expuso sobre secuenciación, interbloqueos o diagnósticos.

Esa estructura es útil porque muestra razonamiento, no solo salida. Cualquiera puede publicar un peldaño. La tarea más difícil y valiosa es demostrar por qué sobrevive a un mal día.

Yaga reduce el empaquetado de contexto manual al operar dentro de un entorno industrial acotado en lugar de como un modelo de texto de propósito general separado del sistema bajo prueba. El punto importante no es que "sepa todo". Es que trabaja con contexto industrial preindexado y el estado activo de la simulación.

Operacionalmente, Yaga debe entenderse como un flujo de trabajo RAG específico de dominio, preindexado y conectado al entorno de escalera y simulación interno de OLLA Lab. Eso significa que el usuario no comienza desde un prompt en blanco y una pila de PDFs. El asistente puede hacer referencia a:

• la lógica de escalera activa,
• los estados actuales de variables y etiquetas,
• patrones de control específicos del escenario,
• contexto de aprendizaje guiado,
• y el comportamiento del equipo simulado vinculado a ese escenario.

Este es un problema más estrecho que la "IA industrial" en abstracto, que es precisamente por lo que es más útil.

¿Qué cambia realmente Yaga en el flujo de trabajo?

Yaga cambia el flujo de trabajo de la recopilación manual de contexto a la revisión consciente del contexto dentro del laboratorio.

En lugar de pedirle a un modelo genérico que infiera lo que probablemente significa una secuencia de bomba principal/reserva, el ingeniero o estudiante puede trabajar dentro de un escenario donde el contexto del sistema ya existe. Eso puede incluir objetivos, mapeo de E/S, peligros, necesidades de secuenciación, enlaces analógicos/PID y notas de puesta en marcha definidas en el entorno del laboratorio.

En la práctica, eso ayuda con tareas como:

• revisar un peldaño frente al escenario activo,
• rastrear por qué una salida no se energizó,
• verificar si una cadena de permisivos está incompleta,
• comparar el estado de la escalera con la respuesta del equipo simulado,
• y revisar la lógica después de una inyección de fallo.

Aquí es donde OLLA Lab se vuelve operacionalmente útil. No es un atajo para la competencia en el sitio, la calificación SIL o la certificación formal. Es un entorno de ensayo acotado para las partes de la puesta en marcha que son demasiado arriesgadas, demasiado costosas o demasiado disruptivas para practicar casualmente en equipos reales.

¿Por qué el estado de simulación en vivo es mejor que un prompt gigante?

El estado de simulación en vivo es mejor porque proporciona contexto estructurado y relevante en el momento del análisis. Un prompt gigante es estático y curado por el usuario. El estado de simulación es dinámico y está vinculado al comportamiento observable.

Esa distinción importa en escenarios que involucran:

• permisivos que son verdaderos en un escaneo y falsos en el siguiente,
• retroalimentaciones de prueba que fallan después de que se emite un comando,
• valores analógicos que cruzan umbrales de alarma,
• comportamiento relacionado con PID bajo condiciones de proceso cambiantes,
• y pasos de secuencia que dependen del historial de estados previos.

Un prompt manual puede describir estas cosas. Una simulación puede exponerlas. Esto último suele enseñar más y engañar menos.

Si debe usar un copiloto genérico, reduzca el tamaño del problema agresivamente. No le pida al modelo que "lea el manual y escriba el programa". Pídale que trabaje en un problema de control acotado con restricciones explícitas.

Un flujo de trabajo práctico es:

• Extraer solo las secciones relevantes del manual.
• Resumir el comportamiento del dispositivo en su propio lenguaje de ingeniería.
• Construir una lista de etiquetas exacta.
• Definir estados legales y estado de fallo.
• Declarar la secuencia requerida y la lógica de disparo.
• Requerir que el modelo enumere los supuestos.
• Revisar cada peldaño frente a la filosofía de control.
• Probar el resultado en simulación antes de cualquier uso orientado al hardware.

Además, separe la generación de la revisión. Use el modelo primero para redactar una estructura candidata, luego en una segunda pasada pídale que identifique supuestos inseguros, interbloqueos faltantes o riesgos de sintaxis específicos del fabricante. Los prompts de una sola pasada tienden a producir confianza más rápido que calidad. A la máquina no le avergüenza eso.

Varios estándares y áreas de investigación son relevantes, pero se aplican de manera diferente.

• IEC 61131-3 importa para las familias de lenguajes de programación de PLC y la estructura de implementación.
• IEC 61508 importa para el pensamiento del ciclo de vida de seguridad funcional, especialmente en torno al rigor sistemático, la verificación y la validación. No significa que una rutina generada por IA sea compatible con la seguridad por asociación.
• La literatura sobre gemelos digitales y simulación importa porque la validación virtual puede mejorar la comprensión del comportamiento del sistema, la respuesta ante fallos y la eficacia de la formación cuando se vincula a modelos realistas.
• La investigación sobre contextos largos de LLM importa porque la degradación de la recuperación afecta si las restricciones técnicas enterradas se utilizan realmente.

La advertencia clave es simple: los estándares pueden guiar la disciplina del proceso, pero no bendicen la lógica generada. La validación todavía tiene que ser ganada.

OLLA Lab encaja como un entorno de ensayo y validación basado en web para lógica de escalera, comportamiento de equipos simulados y resolución de problemas guiada. Su valor es más fuerte donde el usuario necesita conectar el código a la respuesta de la máquina en lugar de simplemente producir sintaxis.

Acotado correctamente, OLLA Lab apoya a ingenieros y estudiantes que necesitan practicar:

• construir lógica de escalera en un editor basado en navegador,
• ejecutar simulaciones de forma segura sin hardware físico,
• monitorear variables, E/S, valores analógicos y comportamiento relacionado con PID,
• trabajar a través de escenarios industriales realistas,
• y usar Yaga como un entrenador contextual en lugar de un oráculo.

Ese es un papel creíble. También es el correcto. En control, las herramientas deben ganarse la confianza reduciendo los modos de fallo, no pretendiendo que los han abolido.

- IEC 61131-3: Controladores programables — Parte 3: Lenguajes de programación - Descripción general de IEC 61508 (seguridad funcional) - Marco de gestión de riesgos de IA del NIST (AI RMF 1.0) - Gemelo digital en la fabricación: una revisión y clasificación categórica de la literatura (IFAC, DOI) - Gemelo digital en la industria: estado del arte (IEEE, DOI)

Este artículo fue preparado por el equipo de ingeniería de OLLA Lab, especialistas en flujos de trabajo de automatización industrial y validación de sistemas de control.

El contenido técnico ha sido verificado contra los estándares IEC 61131-3 y las mejores prácticas de validación de sistemas de control industrial. Los datos de rendimiento citados provienen de benchmarks internos de Ampergon Vallis (2026).