Virtual Commissioning: cómo funciona y cuándo compensa

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

Por Mirko Peters · 2026-11-11

La puesta en marcha virtual prueba el software de control en un modelo virtual antes del arranque. Descubre cómo funciona, qué dice la evidencia y cuándo compensa para una planta.

Traducido automáticamente con IA a partir de la publicación original. Lee el original en inglés

La puesta en marcha virtual consiste en probar el software de control real de una máquina o planta contra un modelo virtual antes de que el equipo esté construido o en funcionamiento. Compensa cuando un día de retraso en el arranque es caro o la lógica de control es compleja, y no compensa en todos los proyectos. Esta guía está pensada para responsables de planta que deben decidir si la solicitan. Aprenderás cómo funciona, los tres niveles de prueba, qué dice la evidencia sobre el ahorro de tiempo, un ejemplo de punto de equilibrio con cifras y los errores que conviene evitar.

Puntos clave

• La puesta en marcha virtual conecta el software de control real, como un programa de PLC, con un modelo simulado de la máquina, de forma que la lógica, las señales y las secuencias se prueban antes de que el equipo funcione.
• El modelo necesita tanto geometría y cinemática como la interfaz eléctrica con el controlador, y su valor depende de lo fiel que sea al comportamiento real.
• Los ahorros de tiempo publicados son grandes, pero proceden de experimentos pequeños y de páginas de fabricantes, así que planifica con una cifra conservadora y no la des por garantizada.
• Compensa cuando un día de retraso en el arranque es caro, la lógica de control es compleja o el modelo puede reutilizarse para formación y cambios posteriores.
• Responde a una pregunta distinta de la de una simulación de producción: si el control funciona, no cuánto puede entregar el sistema.

Puesta en marcha virtual: qué es y cómo funciona

En la puesta en marcha tradicional, el software de control se encuentra por primera vez con la máquina en la planta. Los errores de lógica, señales y secuencias cuestan entonces tiempo en el suelo de producción, donde cada hora de retraso es cara. La puesta en marcha virtual traslada ese primer encuentro a la mesa de trabajo, a un entorno virtual donde el modelo puede simular sensores, accionamientos y piezas. En un proyecto de automatización, eso significa resolver problemas en una fase temprana, cuando la corrección es barata. Un artículo de Matthias Schamp y colaboradores de la Universidad de Gante y Flanders Make, publicado en Procedia Manufacturing en 2019, la describe como la réplica del comportamiento del hardware en un entorno de software, con el fin de validar la lógica de control antes de la implementación real. Los componentes virtuales necesitan un modelo mecánico, con geometría y cinemática, y un modelo eléctrico que cubra la interacción con el PLC.

En la práctica, los pasos son los siguientes:

1. Construye el modelo de la máquina o la planta: las partes que se mueven, los sensores y los actuadores.
2. Nombra las señales en el modelo igual que en el programa de control, para que el controlador vea el modelo como vería el equipo real.
3. Conecta el software de control al modelo. El programa de PLC real se ejecuta y el modelo reacciona.
4. Prueba secuencias y fallos. Ejecuta ciclos normales y, después, provoca fallos como una pieza ausente, un fallo de sensor o un atasco, que son arriesgados o lentos de probar en el equipo real.
5. Corrige los errores en la mesa de trabajo y lleva el programa corregido a la planta.

La calidad del resultado depende de lo fiel que sea el modelo al comportamiento real. El artículo de Schamp afirma que el modelo digital debe comportarse como el sistema de producción real, y señala como retos abiertos el esfuerzo de modelado y la dependencia de la experiencia especializada.

Tres niveles de prueba: model-in-the-loop, software-in-the-loop y hardware-in-the-loop

La prueba puede realizarse en distintos niveles, según la fase del proyecto. La página del proveedor de realvirtual, que vende software de puesta en marcha virtual, describe tres bucles:

• Model-in-the-loop acopla modelos de comportamiento, por ejemplo de una herramienta de simulación, al modelo de la máquina. Es adecuado para accionamientos y procesos antes de que exista código de PLC.
• Software-in-the-loop ejecuta el controlador como software en un PC, de modo que la prueba completa no requiere cableado ni hardware. Es adecuado para pruebas tempranas y escala con facilidad.
• Hardware-in-the-loop conecta un PLC real con el modelo a través de una red. Está más cerca del sistema final y comprueba el comportamiento y los tiempos del hardware real.

Una entrada de blog de Siemens, que es un proveedor, describe los mismos dos modos de software-in-the-loop y hardware-in-the-loop para su herramienta de simulación de planta. La diferencia entre simulación y emulación, que aquí importa, merece un tratamiento aparte. Para un responsable de planta, la conclusión práctica es esta: empieza con software y añade hardware real cuando el proyecto llegue a la fase en la que los tiempos y las interfaces son determinantes.

Lo que dice la evidencia sobre el ahorro de tiempo

Los ahorros reportados son importantes, pero la calidad de la evidencia varía, así que lee las cifras con cuidado.

• El artículo de Schamp cita un experimento anterior a pequeña escala que reportó una reducción del 73% en el tiempo real de puesta en marcha y una mejora del 31% en los requisitos cumplidos antes de la puesta en marcha real con un enfoque de modelo digital. Los autores señalan que comparar enfoques es difícil, porque una puesta en marcha solo puede hacerse una vez.
• La página de realvirtual indica que el tiempo de puesta en marcha en obra puede ser hasta un 75% menor y que la proporción de funciones de control que funcionaron al primer intento pasó del 37% al 84%, citando un estudio de campo de la Universidad Técnica de Múnich. También dice que ese 75% no es un resultado garantizado en todos los proyectos. Es una fuente del proveedor que cita a un tercero.
• La entrada de blog de Siemens también afirma ahorros importantes, pero ofrece pocas cifras que se puedan comprobar.

Por tanto, la dirección es coherente, pero la magnitud es incierta. Para planificar, usa una hipótesis conservadora, como un cuarto del tiempo en obra, y compárala con tu primer proyecto.

Un término relacionado es el gemelo digital: una representación digital mantenida de un recurso físico, actualizada a partir de observaciones. En los proyectos de Industria 4.0, el gemelo y el modelo de puesta en marcha suelen tratarse juntos, pero no son lo mismo. Un modelo creado para la puesta en marcha virtual suele ser un modelo de prueba único, por ejemplo para una línea de montaje. Si lo mantienes actualizado, puede convertirse en un gemelo y utilizarse después para formación y para probar cambios posteriores. Esa reutilización es una de las principales formas en que la inversión se recupera.

Ejemplo: ¿cuándo compensa?

Este es un cálculo ilustrativo, no un caso medido. Una nueva línea necesita 30 días de puesta en marcha en obra. Crear el modelo virtual cuesta 25 días de ingeniería a 800, es decir, 20,000, más 15,000 en software y licencias, lo que suma 35,000 en total. Un día de retraso en el arranque cuesta 8,000, por el equipo en obra y el margen perdido.

Supón que el equipo planifica de forma conservadora y espera ahorrar el 25% del tiempo en obra, es decir, 7.5 días.

• Ahorro: 7.5 × 8,000 = 60,000.
• Coste: 35,000.
• Beneficio neto: unos 25,000.

El punto de equilibrio está en 35,000 ÷ 8,000 = 4.4 días, que equivale a alrededor del 15% de los 30 días. Si el tiempo ahorrado es inferior a esa cifra, el modelo no se amortiza por sí solo en esta línea.

Ahora cambia un supuesto. Si un día de retraso cuesta solo 3.000, los mismos 7,5 días valen 22.500, lo que es menos que los 35.000. El proyecto no se amortiza en la primera línea, salvo que el modelo se reutilice. Si el mismo modelo también sirve para formar a los operarios y para dos cambios posteriores que, cada uno, habrían costado dos días de pruebas a 3.000, la reutilización añade 12.000. El beneficio total es entonces de unos 34.500, lo que está cerca del punto de equilibrio.

La idea clave es que la decisión depende de tres números: el coste de un día de retraso, la proporción de días que esperas ahorrar y la reutilización del modelo. Compáralos antes de que empiece el proyecto.

Pruebas de control y pruebas de resultados: dos tipos de simulación

La puesta en marcha virtual a veces se confunde con la simulación de producción, porque ambas usan un modelo. Responden a preguntas distintas. La distinción habitual es esta: la simulación estudia cómo se comporta un sistema y qué puede entregar, mientras que aquí el objetivo es comprobar que el control funciona.

Una simulación del sistema de producción pregunta si la planta entregará el resultado previsto. iFAKT's Polaris Simulator, por ejemplo, es un módulo de iFAKT Polaris que prueba virtualmente el sistema de producción, por ejemplo escenarios de capacidad, dotación de personal y búferes, y revela cuellos de botella antes de hacer cambios. Es una pregunta sobre flujo y capacidad. No es una prueba del código del PLC, y ambas no se sustituyen. Una línea puede tener un programa de control bien probado y, aun así, ser un mal diseño, o al revés. Las dos pruebas responden a preguntas distintas, así que deben situarse en momentos distintos del proyecto.

Cómo iniciar un proyecto de automatización en cinco pasos

Esta secuencia es una ayuda de planificación propia, no un estándar.

1. Elige un proyecto con un coste de retraso elevado o con una lógica de control compleja y nueva. Una máquina sencilla que ya has construido muchas veces es un mal primer caso.
2. Define las preguntas. ¿Qué secuencias, enclavamientos y casos de fallo deben probarse? El alcance determina el esfuerzo de modelado.
3. Acuerda el nivel de detalle. El modelo debe ser tan sencillo como permitan las preguntas. Un modelo demasiado detallado consume tiempo. Uno demasiado simple pasa por alto los errores.
4. Elige el nivel de prueba. Empieza con software in the loop. Añade hardware cuando el tiempo de respuesta o las interfaces sean importantes.
5. Prueba, documenta y conserva el modelo. Registra los errores encontrados, lleva el programa corregido a la planta y asigna después un responsable del modelo.

Errores comunes

• Empezar demasiado tarde. Si el código de control ya está terminado y entregado, queda poco que probar.
• Nivel de detalle inadecuado. Un modelo demasiado simple pasa por alto los errores, y uno demasiado detallado retrasa el proyecto.
• Señales que no coinciden. Si los nombres de las señales del modelo no coinciden con los reales, estarás probando un programa distinto.
• Tomar una prueba superada como prueba definitiva. El modelo no es la máquina. Reserva tiempo para la comprobación en planta.
• Confiar en el porcentaje destacado. Incluso el proveedor reconoce que su cifra no está garantizada para todos los proyectos.
• Sin responsable tras el proyecto. Un modelo que nadie mantiene queda desactualizado tras el primer cambio.

Cómo puede ayudar el software

El software de simulación para este trabajo va desde suites de simulación de planta hasta plugins de motores de juego, y muchos se conectan con las plataformas de PLC habituales. Fíjate en las interfaces con tu controlador, en el esfuerzo necesario para construir y nombrar las señales y en si el modelo puede reutilizarse más adelante. Una herramienta solo es tan útil como el modelo que construyes con ella, y construir ese modelo es la parte más costosa.

Siguiente paso

Enumera tus próximos tres proyectos de inversión, estima el coste de un día de retraso en la puesta en marcha de cada uno y compáralo con el coste de un modelo. Elige como piloto el proyecto en el que la puesta en marcha virtual tenga más probabilidades de amortizarse.