Cómo reemplazar la frágil lógica de cebolla con máquinas de estado de PLC

Para reemplazar la frágil lógica de cebolla en los programas de PLC, los ingenieros deben utilizar máquinas de estados finitos explícitas. Una arquitectura de máquina de estados puede reducir la ambigüedad en el orden de escaneo, aislar el manejo de fallos y hacer que las pruebas de condiciones anormales sean observables en simulación antes de que la lógica llegue a un proceso real.

Un error común es pensar que la lógica de escalera se vuelve "avanzada" cuando se vuelve densa. En la práctica, la densidad suele ser solo ambigüedad con casco de seguridad. Las máquinas no fallan porque un peldaño parezca sofisticado; fallan porque la secuencia no era determinista cuando una entrada real cambió en el momento equivocado.

Durante una evaluación comparativa interna reciente de 200 ejercicios de secuencias de mezcla enviados por usuarios en OLLA Lab, el 82% de los programas de "lógica de cebolla" profundamente anidados entraron en un bloqueo de secuencia irrecuperable al ser sometidos a un evento de pérdida intermitente de sensor de 100 ms, mientras que las versiones refactorizadas de estado explícito se recuperaron de forma determinista en el 100% de esas mismas pruebas de escenario [Metodología: n=200 tareas de secuencia de mezcla enviadas, comparador = implementación original de enclavamiento anidado frente a implementación refactorizada de estado explícito, ventana de tiempo = ciclo de revisión interna de Ampergon Vallis Lab completado en el Q1 de 2026]. Esta evaluación comparativa interna respalda un punto arquitectónico limitado: los modelos de estado explícito fueron más recuperables ante fallos bajo las condiciones probadas. No respalda afirmaciones generales sobre todo el código de PLC, todas las industrias o la competencia de los operadores.

La distinción práctica es simple: la sintaxis no es capacidad de despliegue. Un programa que funciona en el camino ideal pero se congela ante una permisiva parpadeante no está listo para la puesta en marcha, por muy ordenados que se vean los peldaños.

La lógica de cebolla es un antipatrón de lógica de escalera en el que el comportamiento de la máquina se controla a través de capas de booleanos interdependientes, enclavamientos dispersos y permisivas anidadas cuya ruta de ejecución combinada es difícil de razonar en condiciones anormales.

El nombre es informal, pero el modo de fallo es real. Cada nueva condición envuelve a la anterior hasta que la secuencia se vuelve dependiente de interacciones ocultas entre el orden de los peldaños, el historial de enclavamiento y las entradas transitorias. Suele funcionar durante las demostraciones. La puesta en marcha es menos cortés.

Los 3 síntomas de la lógica de cebolla

El progreso de la secuencia depende de múltiples instrucciones `(S)/(R)` o `(OTL)/(OTU)` distribuidas en muchos peldaños, a menudo sin una única fuente autorizada del estado de la máquina.

• Enclavamientos interdependientes

El comportamiento del programa cambia dependiendo del orden de los peldaños, la sincronización de un escaneo o si una permisiva cae antes o después de que se evalúe una condición de desenclavamiento.

• Vulnerabilidad del ciclo de escaneo

La secuencia se ejecuta correctamente cuando cada sensor se comporta limpiamente, pero se atasca, se enclava a medias o requiere un reinicio manual después de una interrupción a mitad del ciclo.

• Sesgo del camino ideal (Happy-path bias)

Por qué la lógica de cebolla se vuelve frágil

La lógica de cebolla aumenta la complejidad ciclomática efectiva. En términos simples, el número de posibles rutas de ejecución crece más rápido de lo que un ingeniero junior puede rastrear de manera confiable bajo condiciones de fallo, especialmente cuando varios booleanos pueden permanecer verdaderos desde escaneos anteriores.

Eso importa porque la resolución de problemas en PLC no se hace en el vacío. Se hace mientras una cinta transportadora está detenida, una bomba no está disponible o un paso de lote está esperando una permisiva que "debería ser verdadera". "Debería" no es un método de diagnóstico.

Las máquinas de estado explícitas proporcionan una mejor recuperación ante fallos porque hacen que la intención de la máquina sea singular, observable y determinista. En cualquier momento dado, la máquina ocupa un estado definido y las transiciones ocurren solo cuando se cumplen condiciones explícitas.

Esta es la diferencia arquitectónica que importa. La lógica de cebolla pregunta: "¿Qué colección de bits implica actualmente dónde estoy?". Una máquina de estados pregunta: "¿En qué estado estoy y qué condición permite el siguiente?". La segunda pregunta es mucho más fácil de responder a las 3 de la mañana.

### Definición operativa: ¿qué es una máquina de estados explícita en lógica de escalera?

Una máquina de estados explícita es una arquitectura de control en la que:

• el estado de la secuencia de una máquina está representado por una única variable de estado autorizada, a menudo un número entero;
• cada estado es mutuamente excluyente de los demás;
• las transiciones están definidas explícitamente por condiciones observables;
• las condiciones anormales dirigen la máquina a un estado definido de fallo o espera;
• las salidas físicas se derivan del estado activo en lugar de estar dispersas en peldaños de secuencia no relacionados.

Un ejemplo simple podría usar:

• `0 = Reposo`
• `10 = Iniciando`
• `20 = En funcionamiento`
• `30 = Deteniendo`
• `99 = Fallo`

Este enfoque se alinea con los principios establecidos de estructuración de software bajo IEC 61131-3, que admite la organización estructurada de programas, un comportamiento de ejecución claro y una lógica de control mantenible. El estándar no prescribe un patrón de secuencia universal para cada máquina, pero la preferencia por una arquitectura explícita y legible no es controvertida.

Estado explícito vs. lógica de cebolla

| Aspecto de ingeniería | Máquina de estados explícita | Lógica de cebolla | |---|---|---| | Representación de estado | Una variable de estado autorizada, típicamente basada en enteros | Muchos booleanos y enclavamientos superpuestos | | Visibilidad de la secuencia | La fase actual de la máquina es directamente observable | La posición de la secuencia debe inferirse | | Manejo de fallos | Salto explícito a un estado definido de fallo o espera | La recuperación depende de desenclavar las condiciones correctas | | Mapeo de salidas | Salidas derivadas en una rutina dedicada desde el estado activo | Salidas a menudo dispersas en los peldaños de la secuencia | | Resolución de problemas | Preguntar: "¿Por qué el estado X no pasó a Y?" | Preguntar: "¿Qué bit falló al activarse o desactivarse?" | | Sensibilidad al orden de escaneo | Reducida cuando las transiciones están claramente particionadas | A menudo altamente sensible al orden de los peldaños | | Mantenibilidad | Más fácil de revisar, probar y revisar | Se degrada rápidamente a medida que se acumulan condiciones |

La lógica de cebolla falla bajo el comportamiento real del ciclo de escaneo porque los PLC no evalúan la intención; evalúan las instrucciones en orden, un escaneo a la vez, utilizando el estado actual de la memoria y las entradas.

Eso suena obvio, pero muchos errores de secuencia son solo una apreciación tardía de ese hecho. Un sensor puede caer durante 50 ms. Una retroalimentación puede llegar un escaneo más tarde de lo esperado. Un enclavamiento puede permanecer activado porque el peldaño de desenclavamiento nunca se hizo verdadero bajo la secuencia exacta de eventos que ocurrieron.

Mecanismos de fallo típicos

Un bit de transición se activa y desactiva en la lógica adyacente, dejando la lógica de secuencia aguas abajo en una condición indeterminada.

• Carreras de un solo escaneo

Un paso de la secuencia permanece verdadero porque la ruta de reinicio depende de una permisiva que desapareció durante el fallo.

• Persistencia de memoria enclavada

Mover un peldaño para mejorar la legibilidad cambia el comportamiento porque la lógica dependía del orden de ejecución implícito en lugar de transiciones de estado explícitas.

• Dependencia del orden de los peldaños

Una señal de campo ruidosa o perdida brevemente hace que la máquina avance parcialmente y luego pierda las condiciones necesarias para continuar o recuperarse.

• Rebote de sensor o pérdida intermitente

Estos no son casos extremos exóticos. Son eventos ordinarios en la planta. El hardware no tiene ninguna obligación de halagar su diseño de secuencia.

Se construye una máquina de estados finitos en lógica de escalera separando la lógica de transición de estado de la lógica de acción de salida. La rutina de transición decide cuándo la máquina cambia de estado. La rutina de salida decide qué hace la máquina mientras está en ese estado.

Esa separación es la disciplina central. Si las transiciones y las salidas se mezclan en todas partes, la arquitectura deriva de nuevo hacia la lógica de cebolla.

### Paso 1: Definir los estados de la máquina

Comience asignando valores de estado mutuamente excluyentes.

• `0 = Reposo`
• `10 = Solicitud_Inicio`
• `20 = Iniciando`
• `30 = En funcionamiento`
• `40 = Deteniendo`
• `99 = Fallo`

Use una numeración que deje espacio para inserciones posteriores. Los ingenieros que numeran cada estado 1, 2, 3 suelen encontrarse con el estado 2.5 eventualmente.

### Paso 2: Definir las condiciones de transición

Cada transición debe responder a una pregunta estrecha:

• ¿Qué condición permite la entrada al siguiente estado?
• ¿Qué condición bloquea el progreso?
• ¿Qué condición fuerza un estado de fallo o espera?
• ¿Qué condición permite el reinicio o la recuperación?

Las transiciones deben ser explícitas y comprobables. Evite la dependencia oculta de efectos secundarios de peldaños no relacionados.

### Paso 3: Escribir primero la lógica de transición

A continuación se muestra un ejemplo compacto de estilo escalera para transiciones de estado:

Lenguaje: Diagrama de escalera - Lógica de transición de estado

Peldaño 1: Reposo (0) -> Iniciando (10) EQU(Estado_Maquina, 0) --- XIC(PB_Inicio) --- XIC(Sistema_Listo) --- MOV(10, Estado_Maquina)

Peldaño 2: Iniciando (10) -> En funcionamiento (20) EQU(Estado_Maquina, 10) --- XIC(Fdbk_Motor_Marcha) --- MOV(20, Estado_Maquina)

Peldaño 3: Cualquier estado activo -> Fallo (99) ante disparo NEQ(Estado_Maquina, 0) --- XIC(Disparo_Activo) --- MOV(99, Estado_Maquina)

Peldaño 4: Fallo (99) -> Reposo (0) tras reinicio y condiciones seguras EQU(Estado_Maquina, 99) --- XIC(PB_Reinicio) --- XIO(Disparo_Activo) --- XIC(Sistema_Listo) --- MOV(0, Estado_Maquina)

El punto importante no es la sintaxis exacta. El punto importante es que el estado actual y la condición de transición sean visibles, singulares y revisables.

### Paso 4: Mapear salidas desde el estado, no desde fragmentos de secuencia

Una rutina separada debe derivar las salidas del estado activo.

Por ejemplo:

• Si `Estado_Maquina = 20`, comandar `Motor_Marcha = 1`
• Si `Estado_Maquina = 40`, comandar `Motor_Marcha = 0`
• Si `Estado_Maquina = 99`, desenergizar salidas no seguras y activar indicación de fallo

Esto reduce las bobinas de salida dispersas y hace que el comportamiento de la máquina sea más fácil de auditar.

### Paso 5: Definir el comportamiento ante fallos deliberadamente

Un estado de fallo no debe ser un contenedor vago de "algo salió mal". Debe definir:

• qué salidas se desenergizan,
• qué alarmas se activan,
• si el reinicio es automático o manual,
• qué condiciones de reinicio se requieren,
• y qué evidencia puede observar el operador o el ingeniero.

El determinismo importa más cuando las cosas salen mal. El funcionamiento normal halaga a las arquitecturas débiles.

"Listo para simulación" significa que el ingeniero puede probar, observar, diagnosticar y endurecer la lógica de control contra el comportamiento realista del proceso en un entorno de riesgo contenido antes de que esa lógica llegue a un proceso real.

Esta es una definición operativa, no un cumplido. No significa "familiarizado con la sintaxis de escalera", "listo para la puesta en marcha sin supervisión" o "empleable automáticamente". Significa que el ingeniero puede someter una secuencia a condiciones anormales, inspeccionar el comportamiento resultante y revisar la lógica basándose en evidencia.

Comportamientos observables de un ingeniero "Listo para simulación"

Un ingeniero "Listo para simulación" puede:

• forzar y monitorear E/S discretas y analógicas;
• comparar el comportamiento esperado de la secuencia con la respuesta observada de la máquina;
• inyectar un fallo, como la pérdida intermitente de un sensor o la falta de retroalimentación;
• verificar que la lógica transita a un estado seguro y definido;
• revisar las permisivas de transición o el manejo de fallos;
• volver a ejecutar el escenario y demostrar un comportamiento determinista mejorado.

Esa es la diferencia entre escribir código y validar el comportamiento de control. La brecha es costosa.

OLLA Lab simula fallos de transición de estado proporcionando a los ingenieros un entorno de escalera basado en navegador, controles de simulación, variables y E/S visibles, y gemelos digitales basados en escenarios que permiten la inyección de fallos sin riesgo para el equipo real.

Aquí es donde el producto se vuelve operativamente útil. El valor no es que dibuje lógica de escalera en un navegador. Muchas herramientas pueden dibujar. El valor es que la lógica puede ejercitarse contra el comportamiento simulado del equipo y condiciones anormales en un entorno contenido.

Capacidades relevantes de OLLA Lab para la validación de máquinas de estado

Los ingenieros pueden construir transiciones de estado utilizando contactos, bobinas, temporizadores, contadores, comparadores, matemáticas, lógica e instrucciones relacionadas con PID.

• Editor de lógica de escalera basado en web

La lógica se puede ejecutar, detener y observar sin hardware físico.

• Modo de simulación

Las etiquetas (tags), entradas, salidas, valores analógicos y variables de estado se pueden monitorear y ajustar directamente.

• Panel de variables y visibilidad de E/S

La lógica de escalera se puede comparar con el comportamiento simulado del equipo en contextos realistas de máquina o proceso.

• Simulaciones 3D / WebXR / VR

El ingeniero puede probar si la lógica de secuencia produce el comportamiento esperado del equipo antes de cualquier discusión de despliegue en vivo.

• Flujo de trabajo de validación de gemelos digitales

Más de 50 preajustes nombrados en manufactura, agua y aguas residuales, HVAC, química, farmacéutica, almacenamiento, alimentos y bebidas, y servicios públicos proporcionan secuencias, peligros e interbloqueos específicos del contexto.

• Preajustes industriales basados en escenarios

Un caso de prueba práctico en OLLA Lab

En un escenario de atasco de cinta transportadora, un ingeniero puede:

Esa es una tarea de ensayo creíble porque refleja una pregunta real de puesta en marcha: ¿qué sucede cuando la máquina no recibe la secuencia de señales limpias que el autor original asumió?

1. establecer `Estado_Maquina = 20` para representar "En funcionamiento";
2. observar el gemelo digital de la cinta transportadora operando;
3. eliminar una entrada de permisiva o retroalimentación a mitad de la secuencia usando el panel de variables;
4. verificar si el estado transita a `99 = Fallo` o se cuelga en una condición inconsistente;
5. revisar la lógica de transición;
6. volver a ejecutar el escenario para confirmar la recuperación determinista.

Los ingenieros deben documentar la habilidad en máquinas de estado como un cuerpo compacto de evidencia de ingeniería, no como una galería de capturas de pantalla.

Una captura de pantalla prueba que una pantalla existió. No prueba que la lógica fuera correcta, probada o revisada después del fallo.

Estructura de evidencia requerida

Utilice esta estructura de seis partes:

Declare qué significa el comportamiento exitoso en términos observables: condiciones de inicio, salidas, transiciones, alarmas, comportamiento de parada segura y requisitos de reinicio.

Identifique la condición anormal introducida: caída de sensor, retroalimentación fallida, excursión analógica, tiempo de espera (timeout), atasco, interrupción de cadena de parada de emergencia o similar.

Documente el cambio exacto en la lógica: tiempo de espera añadido, permisiva revisada, transición de fallo explícita, manejo de rebote, remapeo de salidas o condición de reinicio.

1. Descripción del sistema Defina la máquina o proceso, su propósito y sus límites de secuencia.
2. Definición operativa de "correcto"
3. Lógica de escalera y estado del equipo simulado Muestre la arquitectura de estado, las etiquetas clave y la respuesta correspondiente del equipo simulado.
4. El caso de fallo inyectado
5. La revisión realizada
6. Lecciones aprendidas Explique qué reveló el fallo sobre la arquitectura original y por qué la revisión mejoró el determinismo o la recuperabilidad.

Esta estructura es útil porque hace que el razonamiento de ingeniería sea inspeccionable. Los empleadores y revisores senior no necesitan un portafolio de interfaces bonitas. Necesitan evidencia de que usted puede pensar a través del fallo.

La arquitectura de estado explícita está respaldada indirectamente por principios establecidos de software de control e ingeniería de seguridad, incluso donde los estándares no prescriben un patrón de escalera exacto.

Estándares relevantes y fundamentos técnicos

Admite enfoques de programación estructurada para software de control industrial y una organización clara de la lógica, funciones y comportamiento de ejecución.

• IEC 61131-3

Enfatiza la integridad sistemática, la respuesta ante fallos y la importancia de reducir la ambigüedad de diseño peligrosa en sistemas relacionados con la seguridad.

• IEC 61508

Refuerzan la necesidad de un comportamiento determinista, trazabilidad y manejo de fallos comprobable en el diseño de sistemas de control.

• Guía de exida y práctica de seguridad funcional

La literatura industrial reciente respalda constantemente la simulación como un medio para validar el comportamiento, reducir el riesgo de puesta en marcha y exponer fallos de secuencia antes del despliegue, al tiempo que advierte que la calidad de la simulación depende de la fidelidad del modelo y el diseño de la prueba.

• Literatura sobre gemelos digitales y simulación

La investigación en entornos de formación en ingeniería sugiere que la simulación interactiva puede mejorar la comprensión procedimental y el reconocimiento de fallos, particularmente cuando los estudiantes pueden probar la causa y el efecto en lugar de solo leer ejemplos estáticos.

• Literatura sobre formación inmersiva e interactiva

La conclusión limitada es directa: la simulación no reemplaza la experiencia de campo, pero es un lugar defendible para ensayar la lógica de fallos que sería insegura, costosa o poco práctica de probar en un proceso real.

Las máquinas de estado no son magia. Aún pueden estar mal diseñadas, ser demasiado complicadas o implementarse sin suficiente atención al comportamiento en estado seguro, manejo de modos o recuperación del operador.

Errores comunes en máquinas de estado

• demasiados estados sin una jerarquía clara;
• distinción poco clara entre modo, estado y fallo;
• transiciones activadas por señales ruidosas sin rebote o validación;
• estados de fallo que no definen el comportamiento de las salidas;
• rutas de recuperación que permiten un reinicio inseguro o no intencionado;
• lógica de salida que reintroduce silenciosamente dependencias dispersas.

Una mala máquina de estados sigue siendo más fácil de diagnosticar que una mala lógica de cebolla, pero eso no es lo mismo que decir que es buena. La arquitectura mejora sus probabilidades; no suspende la disciplina de ingeniería.

La conclusión práctica es que las máquinas de estado explícitas suelen ser la mejor arquitectura cuando la claridad de la secuencia, la recuperación ante fallos y la visibilidad de la puesta en marcha son importantes.

Si la máquina tiene múltiples fases, interbloqueos, condiciones anormales o requisitos de recuperación, un modelo de estado autorizada único generalmente superará a la lógica de enclavamiento en capas en mantenibilidad y capacidad de diagnóstico. Eso es especialmente cierto para los ingenieros junior e intermedios que necesitan una arquitectura sobre la que puedan razonar bajo presión.

OLLA Lab encaja en este flujo de trabajo como un entorno de validación limitado. Permite a los ingenieros construir lógica de escalera, observar E/S, comparar el estado con el comportamiento simulado del equipo, inyectar fallos y revisar la secuencia antes de que exista cualquier contexto de despliegue en vivo. Ese es un caso de uso serio. No se requieren fuegos artificiales.

- Para un desglose más profundo del comportamiento de enclavamiento, revise “Seal-In” vs. “Latch”: Por qué los ingenieros profesionales eligen cuidadosamente. - Para ver esta arquitectura aplicada a un proceso continuo, siga Step-by-Step Build: The Automated Mixer State Machine.

• Dominar la arquitectura de estados es una competencia central en nuestro Ladder Logic Mastery Hub.
• Deje de adivinar cómo su lógica manejará un fallo de sensor. Abra el Conveyor Jam Scenario en OLLA Lab.

- Arriba (Pillar Hub): Explore la guía de pilares - A través: Artículo relacionado 1 - A través: Artículo relacionado 2 - Abajo (Comercial/CTA): Construya su próximo proyecto en OLLA Lab

- IEC 61131-3 Programming Languages - Kritzinger et al. (2018) Digital twin in manufacturing - Tao et al. (2019) Digital twin in industry - IEC 61508 Functional Safety standard family