Cómo programar lógica de máquina de estados en un PLC para un motor trifásico

Para programar la lógica de una máquina de estados en un PLC, los ingenieros dividen la secuencia de la máquina en estados mutuamente excluyentes y realizan transiciones entre ellos de forma explícita. Para un motor trifásico, esto generalmente significa estados basados en enteros como Apagado (Off), Arranque (Starting), Marcha (Running), Parada (Stopping) y Fallo (Fault), los cuales son más fáciles de validar, solucionar y robustecer que la lógica de auto-retención (seal-in) anidada.

La lógica de auto-retención anidada no es "suficientemente buena" solo porque funcione en la primera prueba. En el control secuencial, la lógica booleana que parece ordenada en una pantalla estática aún puede producir condiciones de carrera, rutas de recuperación ambiguas y comportamientos dependientes del ciclo de escaneo cuando las entradas fluctúan o los fallos ocurren a mitad de la secuencia.

Durante las pruebas internas del preset de motor trifásico de Ampergon Vallis en OLLA Lab, reemplazar los contactos de auto-retención anidados por una máquina de estados finitos explícita basada en enteros redujo los eventos de fallo por condición de carrera observados en un 87% durante ensayos de parada anormal simulada [Metodología: n=30 ejecuciones de simulación de la misma tarea de motor trifásico, comparador de referencia de auto-retención anidada, ventana de prueba febrero-marzo de 2026]. Esto respalda una afirmación acotada sobre un preset de entrenamiento interno bajo inyección de fallos simulada. No establece una tasa de reducción de defectos universal en todas las arquitecturas de PLC, plantas o aplicaciones de motores.

Esa distinción es importante. Los fallos en la puesta en marcha suelen originarse en condiciones límite, no en el camino feliz (happy path).

La lógica de máquina de estados finitos es superior para el control secuencial porque hace que el comportamiento de la máquina sea explícito, mutuamente excluyente y determinista. Una FSM construida correctamente permite que el PLC evalúe las reglas para el estado actual y luego realice la transición solo cuando se cumplan las condiciones definidas.

Los peldaños de auto-retención anidados hacen lo contrario. A menudo dispersan la memoria de la secuencia a través de múltiples bits, permisivos, enclavamientos y bloqueos que interactúan indirectamente. El resultado es una lógica que puede funcionar, pero solo hasta que la temporización, la pérdida de retroalimentación o un apagado anormal exponen el acoplamiento oculto. La sintaxis no es lo mismo que la capacidad de despliegue.

La norma IEC 61131-3 no exige un patrón secuencial universal, pero su modelo de organización de programas respalda firmemente una lógica de control estructurada, legible y mantenible para la secuenciación basada en estados en aplicaciones de PLC (IEC, 2013). En la práctica, las FSM se han convertido en una arquitectura común para secuencias de máquinas porque son más fáciles de razonar, probar y recuperar tras fallos.

Una definición operativa útil es la siguiente:

- Máquina de estados finitos en lógica de escalera: una arquitectura de control en la que una variable de estado representa el modo actual de la máquina, solo un estado válido está activo a la vez y las transiciones ocurren a través de condiciones explícitas que asignan el siguiente estado.

Esa última cláusula es la clave de todo. Si la transición no es explícita, la máquina depende de efectos secundarios.

Lógica "Cebolla" vs. Arquitectura de Máquina de Estados

| Factor de ingeniería | Auto-retención anidada / "Lógica Cebolla" | Máquina de estados finitos | |---|---|---| | Memoria de secuencia activa | Distribuida en bits y enclavamientos | Centralizada en una variable de estado | | Comportamiento del ciclo de escaneo | Puede volverse sensible al orden y ambigua | Determinista cuando las transiciones son explícitas | | Recuperación de fallos | A menudo inferida de varias condiciones | Estado de fallo explícito, p. ej., `99` | | Solución de problemas | Rastrear muchos bits interactuando | Leer primero el entero del estado actual | | Expansión de secuencia | Frágil a medida que crecen las ramas | Más fácil insertar estados intermedios | | Validación en simulación | Más difícil aislar la ruta de fallo | Pruebas claras transición por transición |

Los ingenieros de control senior rechazan la lógica cebolla por la misma razón que rechazan el cableado de campo sin etiquetar: el sistema puede seguir funcionando, pero nadie debería tener que adivinar por qué.

Una secuencia de motor trifásico requiere más que un bit de encendido y apagado porque el equipo real tiene comportamiento de transición, temporización de retroalimentación y manejo de fallos. Incluso un arrancador de motor simple generalmente necesita un tratamiento explícito de permisivos, confirmación de arranque, comportamiento de parada y recuperación de disparo.

Una FSM práctica para un motor trifásico utiliza comúnmente estos estados:

1. Estado 0 — Apagado / Listo (Off / Ready) El motor está desenergizado. Los permisivos requeridos son correctos. La secuencia espera un comando de arranque válido.
2. Estado 10 — Arranque (Starting) Se ha emitido la salida de arranque. La lógica espera la retroalimentación esperada, como contacto auxiliar, estado de marcha, confirmación de velocidad o una ventana de tiempo de arranque.
3. Estado 20 — Marcha (Running) El motor está en operación de estado estable. La lógica continúa monitoreando comandos de parada, sobrecargas, pérdida de permisivos y retroalimentación anormal.
4. Estado 30 — Parada (Stopping) Se ha iniciado un comando de parada o un apagado controlado. La lógica espera la confirmación de desenergización, retroalimentación de velocidad cero o finalización del tiempo de espera.
5. Estado 99 — Fallo (Fault) Ha ocurrido un disparo, prueba fallida, sobrecarga o condición de secuencia inválida. Las salidas se llevan a la respuesta segura definida y la lógica de reinicio se maneja explícitamente.

Usar incrementos de 10 es un hábito de ingeniería práctico porque deja espacio para la inserción posterior de estados como `15 = Verificación de arranque` o `25 = Confirmación de inercia` sin tener que renumerar toda la secuencia.

Por qué los estados de transición importan en el control de motores real

Los estados de transición existen porque los motores interactúan con la realidad eléctrica y mecánica, no solo con símbolos de escalera. Dependiendo de la aplicación, la secuencia de control puede necesitar considerar:

• tiempo de cierre del contactor
• temporización de transferencia estrella-triángulo
• aceleración y desaceleración del VFD
• retroalimentación de prueba de contactos auxiliares
• pérdida de permisivos durante la operación
• disparos de relés de sobrecarga
• enclavamientos de procesos aguas abajo
• confirmación de velocidad cero o parada

Aquí es también donde "Listo para simulación" (Simulation-Ready) necesita una definición precisa.

- Listo para simulación: capaz de probar, observar, diagnosticar y robustecer la lógica de control frente al comportamiento real del proceso antes de que llegue a un proceso en vivo.

Eso significa más que escribir un peldaño que compile. Significa validar si el estado de la escalera, el estado de E/S y el estado del equipo simulado permanecen coherentes bajo condiciones normales y anormales.

Una FSM basada en escalera se construye leyendo el estado actual con un comparador y escribiendo el siguiente estado con un movimiento (MOV) explícito. En OLLA Lab, ese trabajo ocurre en el editor de escalera, el panel de variables y el modo de simulación.

OLLA Lab debe entenderse aquí como un entorno de validación y ensayo acotado. Es útil porque permite a los ingenieros practicar comportamientos de puesta en marcha de alto riesgo, como la validación de lógica, observación de E/S, inyección de fallos y revisión, sin usar equipos reales como ayuda didáctica.

### Paso 1: Definir el entero de estado

Cree una etiqueta (tag) como:

- `Motor_State` : `INT`

Este entero es la única fuente de verdad para el estado de secuencia actual de la máquina.

Las etiquetas complementarias recomendadas incluyen:

• `Start_PB`
• `Stop_PB`
• `OL_Trip`
• `Aux_Run_Proof`
• `Reset_PB`
• `Motor_Output`
• `Start_Timer.DN`
• `Stop_Timer.DN`

### Paso 2: Construir la transición de Apagado a Arranque

La primera transición generalmente mueve el motor del estado listo al estado de arranque cuando los permisivos y una solicitud de arranque están presentes.

Concepto de lógica de ejemplo:

• Si `Motor_State = 0`
• y `Start_PB = TRUE`
• y no hay disparo activo
• y los permisivos requeridos son correctos
• entonces `MOV 10` a `Motor_State`

Este es el patrón básico:

• `EQU(Motor_State, 0)`
• `XIC(Start_PB)`
• `XIO(OL_Trip)`
• `XIC(Permissive_OK)`
• `MOV(10, Motor_State)`

### Paso 3: Construir la transición de Arranque a Marcha

El estado de arranque debe confirmar que el motor realmente alcanzó la condición esperada. Esa confirmación puede ser un contacto auxiliar, retroalimentación de marcha, prueba de flujo, prueba de rotación o una condición de tiempo, dependiendo de la aplicación.

Concepto de lógica de ejemplo:

• Si `Motor_State = 10`
• y `Aux_Run_Proof = TRUE`
• entonces `MOV 20` a `Motor_State`

Si la prueba no se recibe dentro del tiempo permitido, realice la transición a fallo en su lugar.

• Si `Motor_State = 10`
• y `Start_Timer.DN = TRUE`
• y `Aux_Run_Proof = FALSE`
• entonces `MOV 99` a `Motor_State`

### Paso 4: Construir la transición de Marcha a Parada

El estado de marcha debe monitorear tanto las paradas comandadas como las condiciones anormales.

Concepto de lógica de ejemplo:

• Si `Motor_State = 20`
• y `Stop_PB = TRUE`
• entonces `MOV 30` a `Motor_State`

Incluya también el manejo de disparos:

• Si `Motor_State = 20`
• y `OL_Trip = TRUE`
• entonces `MOV 99` a `Motor_State`

### Paso 5: Construir la transición de Parada a Apagado

El estado de parada debe esperar a que el motor alcance la condición de parada esperada.

Concepto de lógica de ejemplo:

• Si `Motor_State = 30`
• y la confirmación de parada es verdadera
• entonces `MOV 0` a `Motor_State`

Cuando no existe una prueba física de parada, se puede usar un temporizador acotado, pero esa debería ser una elección de diseño consciente en lugar de una suposición disfrazada de certeza.

### Paso 6: Construir el estado de fallo explícito

El estado de fallo debe desenergizar las salidas y requerir una ruta de reinicio definida. En muchas aplicaciones, eso significa que no hay reinicio automático después de una sobrecarga o prueba fallida a menos que la filosofía de control lo permita explícitamente.

Concepto de lógica de ejemplo:

• Si `Motor_State = 99`
• forzar `Motor_Output = FALSE`
• requerir `Reset_PB = TRUE`
• requerir disparo despejado
• entonces `MOV 0` a `Motor_State`

Resumen del patrón de escalera

Un patrón de peldaño FSM limpio en OLLA Lab generalmente sigue esta secuencia:

• `EQU` para identificar el estado actual
• una o más condiciones `XIC` / `XIO` para validar la transición
• `MOV` para escribir el siguiente estado

Ejemplo de patrón de escalera:

• `EQU Motor_State 10` y `XIC Aux_Run_Proof` entonces `MOV 20 -> Motor_State`
• `EQU Motor_State 10` y `XIO Aux_Run_Proof` y `XIC Start_Timer.DN` entonces `MOV 99 -> Motor_State`

Texto alternativo de la imagen: Captura de pantalla del editor de lógica de escalera de OLLA Lab que muestra un peldaño de máquina de estados finitos donde un bloque EQU verifica si Motor_State es igual a 10, una condición de entrada verifica Aux_Run_Proof y un bloque MOV hace la transición de Motor_State a 20.

Las salidas deben derivarse del estado activo, no usarse como memoria oculta para la secuencia. Esta distinción es fácil de pasar por alto y costosa de ignorar.

Un patrón común es:

• energizar `Motor_Output` cuando `Motor_State = 10` o `Motor_State = 20`
• desenergizarla en `0`, `30` y `99` a menos que la filosofía de parada requiera una retención controlada

Eso le da una relación directa entre la intención de la secuencia y la salida comandada. También hace que la simulación y la solución de problemas sean más limpias porque la salida se convierte en una consecuencia del estado, no en una segunda máquina de estados no documentada.

Ejemplo de lógica de salida

• Si `Motor_State = 10` O `Motor_State = 20`
• entonces `Motor_Output = TRUE`

• Si `Motor_State = 0`, `30` o `99`
• entonces `Motor_Output = FALSE`

Para sistemas de motores más complejos, como arrancadores reversibles, transiciones estrella-triángulo o arreglos de bypass de VFD, cada comando de actuador debe seguir siendo derivado del estado y enclavado explícitamente.

El fallo de FSM más común es un estado colgado. Un estado colgado ocurre cuando la máquina entra en un estado válido pero nunca satisface las condiciones requeridas para salir de él.

Por eso la simulación es importante. Le permite observar la causalidad antes de que el hardware, la mecánica y la presión del cronograma compliquen el diagnóstico.

En OLLA Lab, la solución de problemas de una FSM debe seguir una secuencia simple:

1. Leer primero el entero del estado actual Verifique `Motor_State` en el panel de variables. No comience adivinando qué peldaño parece incorrecto.
2. Verificar la condición de transición esperada Si el motor está en `Estado 10`, confirme si `Aux_Run_Proof` realmente cambia, si el temporizador está funcionando y si los permisivos siguen siendo verdaderos.
3. Verificar el estado de la escalera frente al estado del equipo simulado La escalera puede comandar una salida de motor, pero el equipo simulado puede seguir mostrando prueba fallida, respuesta retrasada o comportamiento de fallo.
4. Inyectar un fallo deliberadamente Cambie `OL_Trip` durante el `Estado 20` y confirme que la secuencia hace la transición inmediatamente al `Estado 99`.
5. Verificar la respuesta segura Confirme que las salidas del motor se desenergizan según sea necesario y que la máquina no puede reanudar la operación hasta que se cumplan las condiciones de reinicio.

Aquí es donde OLLA Lab se vuelve operativamente útil. Permite al alumno comparar el entero de estado de control, las condiciones de E/S y el comportamiento del equipo en un solo lugar, lo que refleja el trabajo que hacen los ingenieros de puesta en marcha bajo presión.

Una prueba práctica de inyección de fallos

Utilice este caso de prueba acotado:

• Comience desde `Estado 0`
• Emita un comando de arranque válido
• Confirme la transición al `Estado 10`
• Confirme la retroalimentación de prueba y la transición al `Estado 20`
• Fuerce `OL_Trip = TRUE`
• Verifique la transición inmediata al `Estado 99`
• Verifique `Motor_Output = FALSE`
• Despeje el disparo y emita el reinicio
• Verifique la transición de vuelta al `Estado 0`

Si alguno de esos pasos falla, el problema ya no es abstracto. Ahora tiene un caso de defecto reproducible.

La validación de gemelo digital, en este artículo, significa probar la lógica de escalera contra un modelo de máquina simulado realista para que el comportamiento de la secuencia pueda observarse tanto en condiciones normales como anormales antes del despliegue. No significa que la simulación sea un sustituto legal para la aceptación en sitio, la verificación de seguridad funcional o la firma de puesta en marcha.

Ese límite es importante. Un gemelo digital puede mejorar la validación de secuencias, el realismo del entrenamiento y el ensayo de fallos, pero no elimina la necesidad de revisión específica de la planta, verificación de dispositivos y actividades formales del ciclo de vida de seguridad bajo normas como IEC 61508 cuando corresponda (IEC, 2010; exida, 2024).

En OLLA Lab, la validación de gemelo digital es operativamente útil cuando el ingeniero puede hacer todo lo siguiente:

• comparar el estado de la escalera con el comportamiento del equipo simulado
• observar si las transiciones de E/S ocurren según lo previsto
• inyectar fallos y verificar la respuesta de estado seguro
• revisar la lógica después de un fallo
• volver a ejecutar el mismo escenario para confirmar la corrección

Esa es la diferencia entre la práctica de sintaxis y el ensayo de puesta en marcha.

Una galería de capturas de pantalla no es evidencia de ingeniería. Es solo un registro parcial.

Si desea demostrar una competencia de control real, construya un cuerpo compacto de evidencia utilizando esta estructura:

1. Descripción del sistema Defina la máquina o unidad de proceso, su objetivo y las E/S relevantes.
2. Definición operativa del comportamiento correcto Indique qué debe hacer la secuencia, qué retroalimentación debe recibir y qué constituye una respuesta segura válida.
3. Lógica de escalera y estado del equipo simulado Muestre la lógica de estado, la lógica de salida y el comportamiento simulado correspondiente.
4. El caso de fallo inyectado Documente la condición anormal que introdujo, como disparo por sobrecarga, prueba de arranque fallida o pérdida de permisivos.
5. La revisión realizada Explique qué lógica cambió y por qué.
6. Lecciones aprendidas Registre qué reveló el fallo sobre el diseño de la secuencia, las suposiciones o los enclavamientos faltantes.

Esta estructura es más creíble porque muestra razonamiento, manejo de fallos y disciplina de revisión. Un peldaño limpio por sí solo no muestra si la lógica sobrevive a condiciones realistas.

El control secuencial estructurado, la validación basada en simulación y las pruebas conscientes de fallos están bien alineados con la práctica de ingeniería establecida, aunque la implementación exacta varía según el sector y la clase de riesgo.

La base relevante incluye:

• IEC 61131-3 para lenguajes de programación de PLC y principios de implementación de control estructurado (IEC, 2013)
• IEC 61508 para el pensamiento del ciclo de vida de seguridad funcional, especialmente donde importan las condiciones anormales y el comportamiento de estado seguro (IEC, 2010)
• Guía de exida sobre disciplina del ciclo de vida de seguridad, rigor de verificación y la diferencia entre la intención de la lógica y el comportamiento validado en sistemas industriales (exida, 2024)
• literatura de investigación sobre simulación industrial, gemelos digitales y entornos de entrenamiento inmersivo que muestra que los entornos simulados pueden mejorar la comprensión procedimental, el ensayo de fallos y el aprendizaje a nivel de sistema cuando están vinculados al desempeño de tareas observables en lugar de solo a la novedad (Tao et al., 2019; Jones et al., 2023; Villalonga et al., 2021)

La conclusión cuidadosa no es que la simulación reemplace el trabajo en sitio. Es que la simulación puede desplazar el aprendizaje costoso hacia la izquierda (shift left), donde los errores son más baratos y visibles.

- IEC 61131-3: Controladores programables — Parte 3 - Descripción general de la norma de seguridad funcional IEC 61508 - Perfil de fabricación inteligente del NIST - IEEE Access: Tecnologías habilitadoras de gemelos digitales (DOI)

El equipo de ingeniería de Ampergon Vallis Lab desarrolla metodologías de control industrial y entornos de validación para sistemas de automatización.

Este artículo ha sido revisado por ingenieros de control de Ampergon Vallis para asegurar la precisión técnica en la implementación de máquinas de estados en lógica de escalera y la validez de las prácticas de simulación descritas.