Cómo solicitar a la IA la programación de PLC con filosofías de control para Yaga

La solicitud (prompting) efectiva de IA para la programación de PLC requiere filosofías de control estructuradas, no solicitudes abiertas. Cuando los ingenieros proporcionan mapeos de E/S explícitos, permisivos, enclavamientos, estados de secuencia y condiciones de falla, Yaga puede generar un andamiaje de lógica de escalera que es materialmente más fácil de validar dentro del entorno de simulación de OLLA Lab.

La IA no falla en el trabajo de PLC porque sea "mala programando". Falla porque la lógica de escalera no es solo generación de código; es un comportamiento de control determinista bajo restricciones, orden de escaneo y estados anormales. Esa distinción a menudo se pasa por alto.

Durante un reciente ejercicio beta interno del asistente Yaga de OLLA Lab, los prompts que incluían un diccionario de etiquetas, un estado seguro definido y al menos un enclavamiento explícito produjeron un andamiaje de primera pasada utilizable para simulación en 22 de 24 tareas (91.7%), mientras que los prompts genéricos como "escribe una secuencia de bomba" requirieron correcciones importantes en 17 de 24 tareas (70.8%) antes de que la simulación pudiera proceder. Metodología: n=48 ejecuciones de tareas de prompt en ejercicios de bomba, mezclador, transportador y nivel de tanque; comparador de referencia = prompt de lenguaje natural genérico frente a prompt de filosofía de control estructurado; ventana de tiempo = ventana beta interna, febrero-marzo de 2026. Esto respalda una afirmación limitada: la estructura del prompt afecta fuertemente la usabilidad de primera pasada en la simulación. No prueba la capacidad de despliegue en campo, la suficiencia de seguridad o la preparación para la producción.

En automatización, la ingeniería de prompts debe definirse de forma estricta: la traducción sistemática de restricciones mecánicas, mapeo de E/S y enclavamientos de seguridad en parámetros legibles por máquina para que un agente de IA pueda generar un andamiaje sintácticamente correcto y comprobable. Esa es una herramienta útil, no un sustituto del juicio de ingeniería. OLLA Lab es importante aquí como el bucle de validación, no como un permiso.

Los LLM generales fallan en la lógica de escalera porque predicen secuencias de tokens plausibles, mientras que los PLC ejecutan una lógica de escaneo determinista frente a entradas y salidas con estado. Un modelo de lenguaje ve continuidad de texto; un controlador ve orden de evaluación, bits de memoria, condiciones de flanco y estado del dispositivo.

La lógica de escalera también es espacial. Las ramas paralelas, las rutas de auto-retención (seal-in), las cadenas de permisivos y los estados mutuamente excluyentes transmiten significado a través de la estructura, no solo a través de las palabras. Un LLM de propósito general tiende a linealizar esa estructura en texto y puede perder la intención de ejecución en el proceso. Esta es una razón por la cual la escalera generada por IA puede parecer competente mientras se comporta de manera incorrecta.

Un segundo modo de falla es la escasa conciencia del ciclo de escaneo. La lógica del PLC se evalúa repetidamente, y las salidas pueden escribirse, restablecerse o anularse dentro del mismo escaneo dependiendo de la estructura del programa. Sin restricciones explícitas, un LLM puede generar:

• escrituras duplicadas en la misma bobina de salida,
• comportamiento de un solo disparo (one-shot) faltante,
• condiciones de carrera entre modos automático y manual,
• temporizadores con condiciones de reinicio poco claras,
• umbrales analógicos sin banda muerta o manejo de fallas,
• enclavamientos que aparecen en los comentarios pero no en la lógica ejecutable.

El resultado común es familiar para los profesionales: lógica que se lee bien pero se comporta mal tan pronto como cambian las entradas. La sintaxis es barata; el determinismo es más difícil.

Esta limitación es ampliamente consistente con la literatura sobre el razonamiento de los LLM y la fiabilidad del código. El trabajo publicado en software y sistemas incorporados sugiere que la calidad de la salida se degrada cuando las tareas requieren un seguimiento de estado persistente, razonamiento espacial o satisfacción exacta de restricciones en lugar de una finalización de patrones fluida (Bubeck et al., 2023; Huang & Chang, 2023). La programación de PLC es especialmente implacable en los tres aspectos.

Un prompt de IA de grado industrial es una especificación funcional compacta. Debe decirle al modelo qué es la máquina, qué significa "seguro", qué dispositivos existen, qué condiciones deben ser verdaderas antes de que se permita una acción y cómo se debe manejar la falla. Si el prompt no puede respaldar una revisión básica de la Especificación de Diseño Funcional (FDS), probablemente sea demasiado vago para una generación de escalera confiable.

En la práctica, un buen prompt de PLC se comporta menos como una consulta de búsqueda y más como instrucciones para un ingeniero de control junior. Los ingenieros senior no dicen: "hazme un programa de bomba". Especifican el proceso, las etiquetas, la secuencia, los disparos (trips) y el estado de respaldo esperado.

Los 3 pilares de un prompt de automatización

#### 1. Contexto y objetivo

Indique la máquina o unidad de proceso, el objetivo operativo y el estado seguro.

Incluya:

• tipo de equipo,
• modo de operación,
• objetivo de inicio/parada,
• condición de parada segura,
• expectativa de estado anormal.

Ejemplo:

• "Bomba de transferencia única llena un tanque diario."
• "El estado seguro es bomba apagada y válvula de salida cerrada."
• "Si el transmisor de nivel no es válido, inhibir el arranque automático."

#### 2. Diccionario de E/S y etiquetas

Defina las etiquetas explícitamente. La IA funciona mejor cuando el nombrado es inequívoco y tipado.

Incluya:

• entradas digitales,
• salidas digitales,
• entradas analógicas,
• salidas analógicas si es relevante,
• bits de memoria interna,
• temporizadores y contadores,
• bits de alarma o falla.

Ejemplo:

• `DI_PB_Start`
• `DI_PB_Stop`
• `DI_EStop_OK`
• `AI_Tank_Level_Pct`
• `DO_Pump_Run`
• `M_Auto_Mode`
• `T_FillTimeout`

La disciplina de nombrado no es cosmética. Es la diferencia entre una lógica rastreable y un impuesto de depuración.

#### 3. Permisivos y enclavamientos

Defina qué debe ser cierto antes de que pueda ocurrir una acción y qué obliga a la acción a detenerse.

Incluya:

• permisivos,
• disparos (trips),
• restricciones de modo,
• requisitos de retroalimentación,
• comportamiento de tiempo de espera,
• condiciones de alarma.

Ejemplo:

• La bomba solo puede arrancar si `DI_EStop_OK = TRUE`
• La bomba solo puede arrancar si `AI_Tank_Level_Pct < 80`
• La bomba debe detenerse si `AI_Tank_Level_Pct >= 95`
• Generar alarma si el comando de ejecución es verdadero y no hay retroalimentación de ejecución en 3 segundos

Aquí es donde muchos prompts colapsan. Los ingenieros a menudo especifican el camino feliz y omiten las razones por las que la máquina debe negarse a moverse. Las plantas reales pasan mucho tiempo en condiciones fuera de lo normal.

Para el prompting de IA, una filosofía de control debe definirse como la especificación funcional mínima necesaria para generar un andamiaje de control comprobable. No es una frase de marketing ni una narrativa de diseño vaga. Operativamente, debe contener los mismos comportamientos centrales que un ingeniero de control espera en un documento de estilo FDS:

• estado inicial,
• modos de operación,
• secuencia de operaciones,
• permisivos,
• enclavamientos,
• alarmas y disparos,
• respuestas a fallas,
• comportamiento de reinicio,
• acciones del operador,
• criterios de éxito.

Esa definición está limitada por observables de ingeniería. Si el prompt no le dice al modelo qué debe hacer el proceso cuando falla un sensor, se abre una tapa, un nivel excede el umbral o nunca llega una retroalimentación, entonces el prompt no es una filosofía de control.

Este encuadre se alinea con la práctica establecida de documentación industrial. IEC 61131-3 rige los lenguajes de programación de PLC, pero una buena lógica de escalera aún depende de la claridad funcional ascendente. Los estándares no rescatan la intención vaga.

Un concepto erróneo útil para retirar

La ingeniería de prompts en automatización no se trata de hacer que la IA sea más creativa. Se trata de hacer que la especificación sea menos ambigua.

La forma más efectiva de solicitar a Yaga es proporcionar una plantilla restringida y reutilizable. Se debe indicar al modelo el rol, el objetivo del proceso, las etiquetas, la secuencia, los permisivos, los enclavamientos y el formato de salida esperado. Si alguno de ellos se deja implícito, el modelo puede improvisar.

Plantilla de prompt recomendada para Yaga

Actúa como un asistente de lógica de escalera IEC 61131-3.

Objetivo: Crea un andamiaje de lógica de escalera para la siguiente tarea de control.

Descripción del sistema: - Equipo: [máquina/unidad de proceso] - Objetivo operativo: [qué debe hacer el sistema] - Estado seguro: [qué salidas/estados deben ser verdaderos cuando está detenido o en falla]

Diccionario de E/S y etiquetas: Entradas digitales: - [etiqueta]: [descripción] - [etiqueta]: [descripción]

Salidas digitales: - [etiqueta]: [descripción]

Entradas analógicas: - [etiqueta]: [descripción y unidades de ingeniería]

Bits internos / Temporizadores / Contadores: - [etiqueta]: [propósito]

Modos de operación:

• [Auto / Manual / Mantenimiento]
• [reglas de modo]

Secuencia de operaciones:

Permisivos:

• [condición requerida antes del inicio]
• [condición requerida antes de la transición]

Enclavamientos / Disparos:

• [condición que debe detener o inhibir la operación]
• [condición de falla y respuesta]

Alarmas:

• [condición de alarma]
• [condición de tiempo de espera]

Reglas de reinicio / recuperación:

• [requisito de reinicio manual]
• [regla de reinicio automático si está permitido]

Requisitos de salida:

• Usa una estructura de escalera clara peldaño a peldaño
• No escribas en la misma bobina de salida en múltiples ubicaciones conflictivas
• Usa bits internos nombrados para estados de secuencia donde sea necesario
• Incluye comentarios para cada peldaño
• Identifica las suposiciones explícitamente

Esta plantilla no garantiza una lógica correcta. Hace algo más útil: hace que los errores sean visibles antes.

1. [paso 1]
2. [paso 2]
3. [paso 3]

Prompt junior vs. prompt senior

| Estilo de prompt | Ejemplo | Resultado probable | |---|---|---| | Prompt junior | "Haz un diagrama de escalera que encienda un mezclador durante 10 segundos cuando presione inicio." | Comportamiento de parada ambiguo, falta de enclavamiento de tapa, lógica de reinicio poco clara, estructura de etiquetas débil | | Prompt senior | "Actúa como un programador IEC 61131-3. Crea un andamiaje de escalera para un mezclador. Entradas: `PB_Start` (NO), `PB_Stop` (NC), `LS_LidClosed`, `EStop_OK`. Salida: `MTR_Mixer`. Enclavamiento: el mezclador no puede funcionar a menos que la tapa esté cerrada y la parada de emergencia esté sana. Usa TON para un ciclo de ejecución de 10 s. Detente inmediatamente al abrir la tapa o comando de parada. Estado seguro = motor apagado. Proporciona comentarios de peldaño e identifica suposiciones." | Línea base comprobable con permisivos explícitos, comportamiento de parada más seguro, ruta de simulación más clara |

La diferencia no es la elocuencia. Es la densidad de restricciones.

Un buen prompt de PLC debe definir la máquina como un sistema con estado, no como una tarea verbal. Antes de que Yaga escriba cualquier peldaño, el prompt ya debería responder seis preguntas de ingeniería.

1. ¿Qué es el sistema?

Defina el equipo, el límite del proceso y la operación prevista.

Ejemplo:

• "Estación de bombeo dúplex principal/reserva con alarma de nivel alto y alternancia."

2. ¿Qué es el comportamiento "correcto"?

Defina la condición de éxito operativo en términos observables.

Ejemplo:

• "En modo automático, la bomba principal arranca al 70% del nivel del pozo húmedo y se detiene al 30%; la bomba de reserva arranca al 90%; ambas se detienen por parada de emergencia o sobrecarga del motor."

Esto importa porque "listo para simulación" debe definirse operativamente: un ingeniero está listo para la simulación cuando puede probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento real del proceso antes de que llegue a un proceso en vivo. Ese es un estándar más fuerte que conocer la sintaxis de escalera.

3. ¿Cuáles son las etiquetas y los tipos de señal?

Enumere las etiquetas, la dirección de la señal y las unidades.

Ejemplo:

• `AI_WetWell_Level_Pct` = entrada analógica, porcentaje
• `DI_P1_OL_Trip` = entrada digital, disparo por sobrecarga
• `DO_P1_RunCmd` = salida digital

4. ¿Qué condiciones anormales existen?

Defina fallas, estados no válidos y respuestas a fallas.

Ejemplo:

• mala calidad del transmisor de nivel,
• ausencia de retroalimentación de ejecución después del comando,
• ambas sobrecargas activas,
• parada de emergencia no sana,
• conflicto de interruptor HOA.

5. ¿Qué nunca debe suceder?

Indique el comportamiento prohibido explícitamente.

Ejemplo:

• "Nunca comande ambas bombas en lógica de alternancia manual."
• "No reiniciar automáticamente después del reinicio de sobrecarga sin la acción del operador."
• "No arrancar el mezclador con la tapa abierta."

6. ¿Qué suposiciones están permitidas?

Exija a la IA que declare las suposiciones en lugar de ocultarlas.

Ejemplo:

• "Asuma que el pulsador de parada es NC sano a menos que se indique lo contrario."
• "Asuma que el escalado analógico ya se realizó aguas arriba."

Las suposiciones ocultas son una fuente común de lógica de escalera débil generada por IA.

OLLA Lab valida la lógica generada por IA colocándola dentro de un entorno de simulación donde las entradas, salidas, variables y el comportamiento del equipo pueden observarse y manipularse antes de considerar cualquier despliegue en vivo. Eso lo convierte en un bucle de validación de riesgo contenido, no en un oráculo.

El editor de escalera proporciona la superficie lógica. El Modo de Simulación proporciona la ejecución. El Panel de Variables proporciona observabilidad en etiquetas, estados de E/S, valores analógicos y variables de control. Juntos, permiten a un ingeniero probar si la lógica generada se comporta como se especificó cuando cambian las condiciones.

En términos prácticos, esto significa que puede:

• alternar entradas digitales,
• forzar condiciones de falla,
• inspeccionar la respuesta de salida,
• observar cómo los temporizadores y bits internos cambian de estado,
• comparar el estado de la escalera con el comportamiento del equipo simulado,
• revisar la lógica después de una prueba fallida.

La validación no es una captura de pantalla de un peldaño que parece correcto. La validación es una secuencia de suposiciones refutadas seguidas de una lógica más estricta.

Cómo se ve el bucle de generación-validación

1. Generar andamiaje con Yaga Utilice un prompt de filosofía de control estructurado.
2. Inspeccionar la escalera generada Verifique los nombres de las etiquetas, la propiedad de la salida, la estructura de la secuencia y la ubicación de los enclavamientos.
3. Ejecutar la lógica en simulación Comience con condiciones nominales.
4. Inyectar condiciones anormales Fuerce la pérdida de sensores, permisivos no válidos, estados de tapa abierta, disparos por sobrecarga, casos de tiempo de espera.
5. Observar si la lógica falla de forma segura Confirme la parada segura, el enclavamiento de alarma, la inhibición del reinicio o el mantenimiento del estado según sea necesario.
6. Revisar y volver a probar Ajuste el prompt o edite la escalera directamente.

Aquí es donde OLLA Lab se vuelve operativamente útil. Brinda a los ingenieros un lugar para ensayar tareas de alto riesgo para las cuales los sistemas en vivo son malos maestros.

La prueba definiendo casos de falla antes de confiar en la secuencia nominal. Una rutina de escalera que funciona solo cuando cada señal se comporta correctamente no está validada; simplemente no ha sido desafiada.

Como mínimo, pruebe estas categorías en la simulación.

Fallas de integridad de entrada

• sensor atascado en alto,
• sensor atascado en bajo,
• transmisor fuera de rango,
• valor analógico incorrecto,
• ausencia de retroalimentación después del comando.

Fallas de enclavamiento

• parada de emergencia no sana,
• protección o tapa abierta,
• permisivo perdido durante la ejecución,
• disparo por sobrecarga activo,
• prueba de válvula no realizada.

Fallas de secuencia

• el temporizador nunca se reinicia,
• el bit de estado permanece enclavado,
• superposición de comandos manual y automático,
• el reinicio ocurre después del disparo sin reinicio,
• la salida permanece energizada después de la ruta de parada.

Fallas relacionadas con analógicos y PID

• la variable de proceso excede el umbral de disparo,
• falta banda muerta analógica,
• vibración de alarma cerca del umbral,
• la salida del controlador se satura,
• la transferencia de modo causa un salto.

La presencia de herramientas analógicas y paneles de control PID en OLLA Lab es importante aquí porque muchos ejemplos de IA permanecen atrapados en la lógica discreta. El control de procesos real generalmente no lo hace. Una estación de bombeo, AHU, bucle térmico o patín de dosificación a menudo incluye umbrales, retrasos, bandas muertas y comportamiento dependiente del modo.

Un ejemplo práctico debe mostrar la traducción de la intención del proceso a restricciones legibles por máquina. A continuación se muestra un ejemplo de mezclador compacto adecuado para Yaga.

Ejemplo de prompt estructurado

Actúa como un asistente de lógica de escalera IEC 61131-3.

Descripción del sistema: - Equipo: Mezclador por lotes - Objetivo operativo: Ejecutar el mezclador durante 10 segundos después del comando de inicio del operador - Estado seguro: Motor del mezclador apagado inmediatamente al detenerse, pérdida de parada de emergencia o tapa abierta

Diccionario de E/S y etiquetas: Entradas digitales: - DI_PB_Start: Pulsador de inicio, normalmente abierto - DI_PB_Stop: Pulsador de parada, normalmente cerrado - DI_Lid_Closed: Prueba de tapa cerrada - DI_EStop_OK: Parada de emergencia sana

Salidas digitales: - DO_Mixer_Run: Comando de ejecución del motor del mezclador

Bits internos / Temporizadores: - M_Mix_Cycle_Active: Enclavamiento de ciclo de mezcla activo - T_Mix_Run: Temporizador TON de 10 segundos

Secuencia de operaciones:

Permisivos:

• DI_Lid_Closed = TRUE
• DI_EStop_OK = TRUE
• DI_PB_Stop sano

Enclavamientos / Disparos:

• Si la tapa se abre durante la ejecución, desenergice DO_Mixer_Run inmediatamente
• Si la parada de emergencia no está sana, desenergice DO_Mixer_Run inmediatamente

Requisitos de salida:

• Proporcione andamiaje de escalera peldaño a peldaño
• Use una ruta de propiedad de salida para DO_Mixer_Run
• Agregue comentarios de peldaño
• Indique cualquier suposición

1. Con el comando de inicio, comience el ciclo de mezcla solo si la tapa está cerrada y la parada de emergencia está sana
2. Ejecute el motor del mezclador durante 10 segundos
3. Detenga el motor cuando el temporizador termine
4. Aborte inmediatamente si hay comando de parada, tapa abierta o parada de emergencia no sana

Qué verificar después de la generación

Después de que Yaga genere la escalera, inspeccione:

• una ruta de propiedad clara para `DO_Mixer_Run`,
• temporizador de habilitación vinculado al estado del ciclo activo,
• caída inmediata al abrir la tapa o pérdida de parada de emergencia,
• sin reinicio automático oculto,
• comentarios que coincidan con el comportamiento real del peldaño,
• suposiciones explícitas.

Luego ejecútelo en la simulación y fuerce `DI_Lid_Closed` a falso durante la ejecución temporizada. Si el comando del motor persiste, el prompt o la lógica son incorrectos.

Los ingenieros deben documentar el trabajo de PLC asistido por IA como evidencia de ingeniería, no como una galería de capturas de pantalla de interfaz. Un registro creíble muestra qué se suponía que debía hacer el sistema, cómo se probó, cómo falló y cómo se corrigió.

Utilice esta estructura:

Registre la falla exacta introducida: pérdida de sensor, sobrecarga, caída de permisivo, tiempo de espera, valor analógico no válido, etc.

1. Descripción del sistema Defina el equipo, el objetivo del proceso, el modo de operación y el estado seguro.
2. Definición operativa de "correcto" Indique los criterios de éxito observables, incluidas las condiciones de parada y el comportamiento en estado anormal.
3. Lógica de escalera y estado del equipo simulado Muestre la escalera generada o editada junto con el estado relevante de la máquina simulada o el comportamiento de la variable.
4. El caso de falla inyectado
5. La revisión realizada Documente el cambio de lógica o el refinamiento del prompt utilizado para corregir el comportamiento.
6. Lecciones aprendidas Indique qué reveló la falla sobre la filosofía de control original, las suposiciones o el diseño de la secuencia.

Esto produce un cuerpo de evidencia compacto que es útil para revisores, instructores o gerentes de contratación.

El prompting de PLC asistido por IA es útil para andamiaje, redacción y aceleración de la estructura lógica de primera pasada. No es suficiente para la validación de seguridad, la firma de puesta en marcha o las decisiones de despliegue específicas del sitio.

Ese límite es importante tanto para la ética como para la ingeniería. OLLA Lab se describe aquí como un simulador de lógica de escalera y gemelo digital interactivo basado en web con soporte guiado a través de Yaga, simulaciones 3D/WebXR/VR, ejercicios basados en escenarios, herramientas analógicas y PID, y flujos de trabajo de instructores. Esas características lo hacen útil como entorno de ensayo y validación. No convierten la lógica generada en lógica de planta aprobada por asociación.

Algunos límites deben permanecer explícitos:

• La escalera generada por IA puede ser sintácticamente plausible y funcionalmente insegura.
• La simulación puede exponer muchos defectos lógicos, pero no es idéntica a la puesta en marcha en el sitio.
• La validación del gemelo digital depende de la fidelidad del modelo y el alcance del escenario.
• Las obligaciones de seguridad funcional aún requieren métodos formales, revisión competente y disciplina de ciclo de vida basada en estándares.

Esto es consistente con la literatura de seguridad más amplia. IEC 61508 y la guía relacionada tratan las fallas sistemáticas, los errores de especificación y la disciplina de verificación como preocupaciones centrales. Un modelo que produce código rápidamente no elimina esos deberes.

Este enfoque es más útil porque cambia la tarea de la generación sin restricciones a la ingeniería limitada. Cuando escribe primero una filosofía de control, obliga a que las decisiones importantes salgan a la luz: estado seguro, permisivos, disparos, propiedad de la secuencia y respuesta a fallas.

Eso tiene tres beneficios prácticos:

• mejor andamiaje de primera pasada,
• depuración más rápida en simulación,
• revisión más clara por parte de humanos.

También enseña el hábito correcto. La transición profesional no es solo de no conocer la escalera a conocerla. Es de escribir peldaños a defender el comportamiento.

- Descripción general del estándar IEC 61131-3 (PLCopen) - Marco de gestión de riesgos de IA del NIST (AI RMF 1.0) - Descripción general de las Pautas de accesibilidad al contenido web (WCAG) 2 del W3C - Portal de taxonomía y publicaciones de IEEE - Página del estándar de gestión de riesgos de IA ISO/IEC 23894