Cómo se compara la automatización definida por software con los PLC de hardware: Guía de arquitectura 2026

La automatización definida por software (SDA, por sus siglas en inglés) desacopla la lógica de control IEC 61131-3 del hardware de controlador propietario mediante la ejecución de tiempos de ejecución de PLC virtuales en PC industriales o plataformas de computación de borde (edge). Los PLC de hardware siguen siendo esenciales para tareas de seguridad y movimiento de alta determinación, mientras que la SDA está ganando terreno en el control de procesos estándar y de supervisión, donde la implementación flexible y la validación agnóstica al hardware son importantes.

La automatización definida por software no es el fin del PLC. Es la separación del software de control del hardware de controlador propietario, y esa distinción es más importante que el eslogan. En la práctica, la mayoría de las plantas no están reemplazando cada controlador con un modelo centrado en la nube; están trasladando selectivamente las funciones de control estándar a PC industriales, tiempos de ejecución de borde y entornos virtualizados, manteniendo al mismo tiempo el hardware dedicado donde la seguridad determinista y el movimiento siguen siendo la norma.

En una prueba de estrés interna de 72 horas de un secuenciador HVAC virtualizado ejecutado en el entorno de simulación en la nube de OLLA Lab, la varianza máxima observada en el ciclo de escaneo se mantuvo dentro de 0.02 ms de una referencia de hardware definida durante tareas de control de procesos estándar. Metodología: n=1 modelo de secuenciador con transiciones de estado y condiciones de alarma repetidas; comparador de referencia = perfil de ejecución de hardware físico de la misma secuencia de control; ventana de tiempo = ejecución continua de 72 horas. Esto respalda la afirmación más limitada de que los entornos de validación basados en navegador pueden ser lo suficientemente estables para ensayar el comportamiento de control estándar. No respalda el reemplazo de sistemas de seguridad certificados ni la realización de afirmaciones generales de determinismo en todas las cargas de trabajo.

La verdadera pregunta no es si los PLC de hardware están muriendo. Es qué capas de control pueden ahora abstraerse de forma segura, económica y verificable, y cuáles siguen perteneciendo al hardware dedicado porque los requisitos de temporización, respuesta ante fallos y certificación siguen siendo decisivos.

La automatización definida por software es la abstracción de la lógica de control industrial del hardware de controlador propietario, de modo que las aplicaciones IEC 61131-3 puedan ejecutarse en plataformas de computación industrial de propósito general bajo un tiempo de ejecución en tiempo real adecuado. La lógica es familiar. El modelo de ejecución cambia.

En una arquitectura de PLC tradicional, el software de ingeniería, el tiempo de ejecución, la CPU y el ecosistema de E/S suelen estar vinculados a la pila de un proveedor. En la SDA, la aplicación de control se despliega en un tiempo de ejecución de PLC virtual en un PC industrial, dispositivo de borde o plataforma similar, a menudo con E/S remotas a través de redes industriales. Ese es el principio fundamental de desacoplamiento.

Esto no significa "control en la nube" en un sentido de marketing vago. En términos operativos, la SDA generalmente significa:

• La lógica IEC 61131-3 se crea independientemente de una CPU propietaria fija.
• El tiempo de ejecución se ejecuta en un IPC o plataforma de borde en lugar de en un chasis de PLC dedicado.
• Las E/S se distribuyen a través de dispositivos de campo conectados en red o islas de E/S remotas.
• La validación, las pruebas y la revisión ocurren cada vez más en entornos agnósticos al hardware antes de la implementación.

Ese último punto es donde el flujo de trabajo cambia más. La sintaxis sobrevive bastante bien a la abstracción. Los errores de puesta en marcha no.

Las tres capas de la arquitectura SDA

La SDA es más fácil de evaluar cuando se separa en capas.

• Capa de hardware
• PC industrial, dispositivo de borde o computación industrial COTS.
• E/S remotas conectadas en red, acopladores de bus de campo, instrumentos inteligentes, variadores.
• Infraestructura de red redundante o segmentada cuando sea necesario.

• Capa de virtualización o tiempo real
• Sistema operativo en tiempo real, variante de Linux en tiempo real o configuración de hipervisor.
• Asignación de núcleos de CPU, disciplina de programación y aislamiento de recursos.
• Controles de determinismo adecuados para la clase de tarea prevista.

• Capa de aplicación
• Tiempo de ejecución IEC 61131-3 o motor vPLC.
• Lógica de escalera (Ladder), texto estructurado, bloques de funciones, manejo de alarmas, secuenciación.
• Entornos de ingeniería, simulación y validación como OLLA Lab.

La distinción útil es simple: la SDA cambia dónde se ejecuta la lógica y cómo se gestiona, no lo que requiere una buena ingeniería de control. Una mala secuencia sigue siendo mala incluso cuando se virtualiza.

Los PC industriales están reemplazando a los PLC de hardware propietarios en aplicaciones seleccionadas porque pueden reducir la dependencia de un proveedor, aumentar la flexibilidad de la computación y alinearse de forma más natural con los patrones modernos de integración IT/OT. El motor no es la novedad. Es la presión arquitectónica.

Las recientes interrupciones en la cadena de suministro hicieron difícil ignorar un problema práctico: si una estrategia de control depende de la disponibilidad, el ciclo de vida y el modelo de licencias del controlador de un proveedor, el diseño técnico conlleva un riesgo de adquisición, lo admita o no el plano. El control basado en IPC no elimina el riesgo, pero lo redistribuye a un dominio que muchas organizaciones ya saben cómo gestionar.

El cambio es más fuerte en:

• control de supervisión
• secuenciación de procesos estándar
• skids y equipos modulares
• aplicaciones de borde intensivas en datos
• entornos que necesitan una integración más estrecha con análisis, API, historiadores o servicios en contenedores

El cambio es más débil en:

• movimiento de alta velocidad
• bucles deterministas estrictamente delimitados
• funciones de seguridad certificadas
• plantas heredadas donde el cambio de arquitectura introduce más riesgo que valor

Comparación entre IPC y PLC de hardware

| Factor de arquitectura | PLC de hardware propietario | SDA en PC industrial / Tiempo de ejecución vPLC | |---|---|---| | Dependencia del proveedor | Generalmente alta; el software, la CPU y el ecosistema están estrechamente acoplados | Menor en principio; el tiempo de ejecución y el hardware pueden desacoplarse, aunque no siempre por completo | | Escalabilidad de computación | Fija según la familia y el modelo del controlador | Más escalable; las opciones de CPU, memoria, almacenamiento y virtualización son más amplias | | Integración IT | A menudo posible pero incómoda; la integración puede depender de las herramientas del proveedor | Ajuste más nativo para API, contenedores, virtualización y servicios de borde | | Flexibilidad del ciclo de vida | Vinculado a los ciclos de lanzamiento del proveedor y las familias de hardware | Potencialmente más flexible, pero solo si la disciplina de control de versiones y soporte es sólida | | Modelos de E/S remota/distribuida | Maduros y bien comprendidos | Maduros en muchos casos, pero el diseño de red se vuelve más central | | Carga de parches y actualizaciones | Menor superficie, comportamiento de dispositivo más cerrado | Se requiere una mayor disciplina operativa; las actualizaciones pueden convertirse en su propio modo de fallo | | Casos de uso ideales | Control determinista, funciones adyacentes a la seguridad, estándares de planta establecidos | Control de supervisión, sistemas modulares, arquitecturas híbridas IT/OT |

La trampa no es sutil. Los IPC compran flexibilidad heredando más carga operativa de la computación de propósito general. Las plantas que tratan esa carga con ligereza tienden a redescubrir por qué los dispositivos cerrados eran populares en primer lugar.

No. Los PLC virtuales no reemplazarán a los Sistemas Instrumentados de Seguridad (SIS) donde se requiere seguridad funcional certificada y un comportamiento determinista estricto. Este es el límite que el marketing suele difuminar y las normas no.

La norma IEC 61508 y las prácticas de seguridad funcional relacionadas se preocupan por la integridad sistemática, el comportamiento determinista, la respuesta ante fallos y las restricciones de diseño certificadas. Una plataforma de computación de propósito general que ejecuta una carga de trabajo de control virtualizada puede ser totalmente adecuada para el control de procesos estándar y, aun así, ser la respuesta incorrecta para una función de seguridad con clasificación SIL. Esas son preguntas de ingeniería diferentes.

Los PLC de seguridad dedicados y los circuitos de seguridad cableados siguen siendo necesarios porque proporcionan:

• arquitectura de seguridad certificada
• comportamiento ante fallos delimitado y validado
• respuesta determinista bajo condiciones definidas
• separación de cargas de trabajo que no son de seguridad
• patrones de diseño establecidos para paradas de emergencia, disparos, permisivos y pruebas de validación

No se puede asumir que un hipervisor proporcione el mismo caso de garantía que una plataforma de seguridad certificada. Ni debería hacerlo.

Donde los PLC de hardware siguen dominando

Los PLC de hardware siguen siendo la opción predeterminada en aplicaciones donde la temporización de fallos y la respuesta ante fallos deben estar estrictamente delimitadas, incluyendo:

• Sistemas Instrumentados de Seguridad (SIS)
• Sistemas de parada de emergencia
• Movimiento de alta velocidad y control de servomotores coordinado
• Cadenas de seguridad de máquinas con solucionadores de lógica certificados
• Procesos donde las excursiones de latencia determinista crean un peligro inaceptable

Un encuadre más preciso es este: los PLC de hardware no están muriendo; se están concentrando en las partes de la pila de control donde el determinismo, la certificación y la contención de fallos no son negociables.

Se valida la lógica SDA mediante pruebas de software-in-the-loop (SIL) agnósticas al hardware que demuestran el comportamiento de la secuencia, la causalidad de las E/S, el manejo de estados anormales y la calidad de la revisión antes de la implementación en un tiempo de ejecución real. Si el objetivo de ejecución está abstraído, el flujo de trabajo de validación debe ser más explícito, no menos.

Aquí es donde muchos equipos hacen la comparación incorrecta. Comparan la sintaxis de escalera entre plataformas y concluyen que la portabilidad es la parte difícil. No lo es. La parte difícil es demostrar que el comportamiento previsto de la máquina o el proceso se mantiene cuando se introducen la temporización, las comunicaciones, las E/S remotas y las condiciones de fallo.

Operativamente, un ingeniero preparado para la simulación no es alguien que simplemente puede escribir lógica de escalera en un navegador. Un ingeniero preparado para la simulación puede:

• demostrar qué significa el comportamiento correcto para una secuencia o bucle de control
• observar transiciones de etiquetas, alarmas y estados en tiempo real frente al comportamiento del proceso previsto
• diagnosticar errores causales entre el estado lógico y el estado del equipo simulado
• inyectar condiciones anormales de forma segura
• revisar la lógica y verificar que la revisión cierre el modo de fallo sin crear uno nuevo

Esa es la diferencia entre la sintaxis y la capacidad de implementación.

Qué debe incluir la validación de software-in-the-loop

Un flujo de trabajo de validación de SDA creíble debería incluir al menos lo siguiente:

• Pruebas de causalidad de E/S
• ¿Cada transición de entrada produce la respuesta lógica y física prevista?
• Validación de secuencias
• ¿Los estados de arranque, parada, espera, fallo y recuperación se comportan en el orden correcto?
• Pruebas de alarmas e interbloqueos
• ¿Los permisivos, disparos, inhibiciones y la lógica de reinicio se comportan según lo definido?
• Pruebas de condiciones anormales
• ¿Qué sucede durante un fallo del sensor, pérdida de comunicación, retroalimentación obsoleta o actuación retrasada?
• Revisión de temporización
• ¿Los temporizadores, la lógica de eliminación de rebotes, las suposiciones del perro guardián (watchdog) y los comportamientos sensibles al escaneo siguen siendo aceptables?
• Después de un cambio de lógica impulsado por un fallo, ¿se puede demostrar el comportamiento corregido de forma repetible?

Una planta en funcionamiento es un mal lugar para descubrir que una caída de E/S remota convierte una parada suave en un bloqueo bloqueado.

Ensayando el control en la nube en OLLA Lab

OLLA Lab es útil aquí porque proporciona un entorno delimitado para escribir lógica de escalera, simular E/S, observar el estado de las variables y validar el comportamiento del control frente a escenarios realistas antes de la implementación del hardware. Debe entenderse como un entorno de ensayo y validación, no como un sustituto de la aceptación en el sitio, la certificación de seguridad o la puesta en marcha en campo.

En términos prácticos, OLLA Lab respalda este flujo de trabajo al permitir a los usuarios:

• construir lógica de escalera agnóstica al hardware en un editor basado en web
• ejecutar lógica en modo de simulación sin hardware de PLC físico
• inspeccionar entradas, salidas, etiquetas, valores analógicos y variables relacionadas con PID
• comparar el estado de la escalera con el comportamiento del equipo simulado
• trabajar a través de secuencias basadas en escenarios, interbloqueos, alarmas y notas de puesta en marcha
• utilizar modelos de equipos 3D o WebXR cuando estén disponibles para validar el comportamiento a nivel de máquina
• obtener asistencia guiada de Yaga, el guía de laboratorio de IA, durante los pasos de construcción y resolución de problemas

Aquí es donde OLLA Lab se vuelve operativamente útil. Ofrece a los ingenieros un lugar para ensayar tareas que son costosas, arriesgadas o poco prácticas de practicar en equipos reales: rastrear causa y efecto, probar estados anormales, revisar la lógica después de un fallo y verificar si el comportamiento de la máquina simulada coincide con la intención de la escalera.

La validación de gemelos digitales, en este contexto, significa probar la lógica de control contra un modelo de equipo o proceso simulado para que el ingeniero pueda comparar el comportamiento de control previsto con el comportamiento observado del sistema antes de la implementación. No es una frase de prestigio. Es un flujo de trabajo de evidencia.

Para la SDA, la validación de gemelos digitales es importante porque el controlador ya no es toda la historia. Las E/S conectadas en red, la computación de borde, las suposiciones de secuenciación, el comportamiento analógico y la recuperación de fallos interactúan. Un gemelo digital no elimina el riesgo de puesta en marcha, pero puede exponer defectos lógicos antes y de forma más económica que las pruebas en vivo.

En OLLA Lab, esa validación puede incluir:

• vincular etiquetas de escalera a estados de máquina simulados
• observar si una secuencia impulsa la respuesta física esperada
• probar interbloqueos, retroalimentaciones de prueba y comparadores de alarma
• evaluar el comportamiento analógico y las respuestas relacionadas con PID en el contexto del escenario
• revisar peligros y notas de puesta en marcha adjuntas a preajustes industriales realistas

El valor educativo no es que el gemelo se vea impresionante. El valor es que obliga al ingeniero a responder una pregunta más difícil: no "¿compila el peldaño?", sino "¿se comporta el sistema correctamente bajo condiciones realistas?"

Debería construir un cuerpo compacto de evidencia de ingeniería que muestre juicio de validación, no una galería de capturas de pantalla de escalera. Las capturas de pantalla prueban que un editor estaba abierto. No prueban que la lógica sobrevivió al contacto con un modelo de proceso.

Utilice esta estructura:

Indique qué significa el comportamiento correcto en términos observables: orden de secuencia, permisivos, umbrales de alarma, comportamiento de recuperación y expectativas de estado seguro.

1. Descripción del sistema Defina el equipo, el objetivo del proceso, el alcance de las E/S y los estados operativos.
2. Definición operativa del comportamiento correcto
3. Lógica de escalera y estado del equipo simulado Muestre la lógica de control junto con la respuesta de la máquina o proceso simulado, incluyendo etiquetas relevantes y transiciones de estado.
4. El caso de fallo inyectado Introduzca una condición anormal como retroalimentación fallida, respuesta retrasada de la válvula, deriva del sensor, pérdida de E/S remota o entrada analógica obsoleta.
5. La revisión realizada Documente el cambio de lógica, por qué se realizó y qué modo de fallo aborda.
6. Lecciones aprendidas Explique qué pasó por alto el primer diseño, qué mejoró el diseño revisado y qué requiere aún verificación en campo.

Esa estructura es útil tanto si el objetivo es un PLC de hardware como un tiempo de ejecución vPLC. La buena evidencia viaja mejor que la lealtad a la plataforma.

Los ingenieros deben utilizar las normas para definir límites, no para decorar afirmaciones de arquitectura. En las discusiones sobre SDA, tres preguntas adyacentes a las normas son las más importantes:

- IEC 61131-3: ¿Qué modelo de programación, comportamiento del lenguaje y estructura de control se están implementando?

- IEC 61508: ¿Es la arquitectura propuesta adecuada para las obligaciones de integridad de seguridad y respuesta ante fallos requeridas?

- IEC 62443 y prácticas de seguridad OT relacionadas: ¿Cómo cambia el movimiento hacia IPC, computación de borde y servicios en red la superficie de ciberseguridad y la carga de mantenimiento?

La lectura práctica es sencilla. IEC 61131-3 ayuda a explicar la portabilidad del software y la estructura de la lógica de control. IEC 61508 ayuda a explicar por qué no todas las cargas de trabajo de control deben virtualizarse. IEC 62443 se vuelve más relevante a medida que los sistemas de control heredan más preocupaciones de parcheo, segmentación, autenticación y acceso remoto de los entornos de TI.

La SDA no es solo una historia de controles. También es una historia de gobernanza IT/OT con consecuencias reales en el proceso cuando se maneja mal.

No. El PLC de hardware se está reduciendo a los roles donde el determinismo dedicado, la garantía de seguridad y la confiabilidad similar a la de un dispositivo siguen siendo superiores. La SDA se está expandiendo a las capas donde la portabilidad del software, la flexibilidad de la computación y la validación agnóstica al hardware pueden crear una ventaja operativa.

Ese es el punto de transición práctico en 2026.

Una visión de arquitectura razonable se ve así:

• Mantenga PLC de hardware dedicados o controladores de seguridad para seguridad con clasificación SIL, movimiento en tiempo real estricto y tareas deterministas estrictamente delimitadas.
• Utilice modelos SDA y vPLC para control de supervisión, skids modulares, control de procesos estándar distribuido y aplicaciones de borde integradas con TI.
• Valide agresivamente en flujos de trabajo de simulación primero antes de la implementación, especialmente cuando se trata de E/S remotas, virtualización o infraestructura mixta IT/OT.

El punto no es elegir un bando en una discusión tribal entre racks y tiempos de ejecución. El punto es colocar cada función de control en la arquitectura que pueda demostrar que merece el trabajo.

- UP (pillar): Explore todas las rutas del Pilar 5 - ACROSS (related): Cómo validar la lógica de PLC con gemelos digitales - ACROSS (related): Cómo programar interbloqueos a prueba de fallos con contactos normalmente cerrados - DOWN (commercial CTA): Genere impulso profesional con Cómo hacer la transición a la automatización de centros de datos: Programación de redundancia HVAC en OLLA Lab

- Norma IEC 61131-3 de lenguajes de programación PLC - Serie de ciberseguridad en automatización industrial IEC 62443 - NIST SP 800-82 Rev. 3 (Seguridad OT) - Arquitectura CPS de Industria 4.0 (Manufacturing Letters) - Gemelos digitales en la industria (IEEE TII, DOI)

El equipo de investigación de OLLA Lab se especializa en la intersección de la automatización industrial, la validación de software y la arquitectura de sistemas de control.

Este artículo ha sido revisado por expertos en sistemas de control industrial para garantizar la precisión técnica en las distinciones entre SDA, PLC de hardware y requisitos de seguridad funcional.