RTDS - Simulación en tiempo real y Hardware in the Loop (HIL): ventajas frente a los entornos offline
En INDIELEC solemos contar una escena que se repite más de lo que parece. Un equipo de ingeniería llega con un proyecto “bien armado” en papel: modelos offline, resultados bonitos, conclusiones razonables… pero con una inquietud que no se quita de encima: “¿Y si el día que conectemos el equipo a red, la realidad no se comporta como la simulación?”
Esa duda es el punto de inflexión. Porque en sistemas eléctricos modernos —con renovables, convertidores, automatización, comunicaciones y exigencias de calidad cada vez más altas— la diferencia entre “funciona en el ordenador” y “funciona en campo” puede estar en detalles muy concretos: un retardo, un disparo, una saturación, una interacción de control, una secuencia de protecciones o una señal IEC que llega un poco tarde. Y ahí es donde la simulación en tiempo real y el hardware in the loop dejan de ser conceptos “de laboratorio” y se convierten en una ventaja competitiva real.
En este artículo vamos a explicarlo con calma y con narrativa: qué significa simular en tiempo real con RTDS, qué es exactamente el enfoque hardware in the loop, por qué marca diferencias frente a los entornos offline y cómo lo aplicamos nosotros para que los estudios no se queden en teoría, sino que se traduzcan en decisiones seguras.
Por qué el entorno offline se queda corto justo cuando más lo necesitas
Los entornos offline son imprescindibles. Con ellos diseñamos, dimensionamos, exploramos escenarios, iteramos rápido y construimos hipótesis. Pero también tienen una limitación de base: no “viven” en el mismo reloj que el equipo real.
En un entorno offline, el tiempo es flexible. La simulación puede ir más rápido o más lento que la realidad. Puedes pausar, repetir, cambiar parámetros y volver a lanzar. Eso está genial para aprender y para diseñar. Pero cuando el objetivo es validar el comportamiento de un dispositivo real (o de un conjunto de dispositivos), aparece un problema: ese dispositivo está programado para operar con un tiempo exacto y con entradas/salidas que llegan cuando tienen que llegar.
La literatura técnica lo resume de forma bastante directa: las simulaciones de sistemas de potencia suelen clasificarse en offline y en tiempo real, y el enfoque offline tiene desventajas para reproducir fielmente el comportamiento del equipo real en condiciones prácticas; precisamente por eso se impulsa la simulación en tiempo real y el salto hacia HIL.
Y esto no es un matiz. Es el tipo de cosa que explica por qué, a veces, un control funciona perfecto en un modelo… y luego en pruebas aparece una oscilación, una respuesta inesperada o un disparo que nadie había visto venir.
Qué aporta la simulación en tiempo real cuando el sistema “se pone serio”
Cuando hablamos de simulación en tiempo real en el mundo eléctrico, hablamos de algo muy concreto: la simulación tiene que ejecutarse a la misma velocidad que el mundo físico, de forma determinista.
En RTDS, esto se traduce en poder ejecutar simulaciones EMT (transitorios electromagnéticos) en tiempo real, con el nivel de detalle que hace falta para reproducir faltas, maniobras, transitorios y dinámicas rápidas, pero sin “romper” el reloj.
En la práctica, esto cambia el tipo de preguntas que puedes responder. Ya no solo preguntas “qué pasaría si…”, sino “cómo se comporta realmente el sistema cuando…”, con un punto clave: puedes conectar equipos reales a esa simulación y cerrar el círculo.
Ahí es donde aparece la pieza que lo cambia todo: hardware in the loop.
Qué es Hardware in the Loop y por qué no es solo un “test con cacharros”
A veces se explica el hardware in the loop como “meter un equipo real dentro de una simulación”. Es cierto, pero se queda corto.
Nosotros lo contamos así: hardware in the loop es convertir la simulación en un entorno de pruebas donde el equipo cree que está en la red real.
Eso significa que el dispositivo bajo prueba (un relé, un controlador, un PLC, un regulador, un inversor…) recibe señales como si vinieran del sistema eléctrico real, toma decisiones con sus tiempos reales, envía salidas reales, y esas salidas vuelven a influir en la simulación. Es un bucle cerrado.
Es exactamente la idea que muchas organizaciones describen como un “simulador de vuelo” para electrónica de potencia y equipos de red: un entorno seguro donde exponer el equipo a fenómenos dinámicos y transitorios, ver su respuesta y afinar antes de ir a campo.
Y aquí hay una distinción importante, porque “hardware in the loop” no es una sola cosa.

CHIL vs PHIL: dos formas de HIL para dos tipos de riesgo
En proyectos de RTDS, suele hablarse de dos variantes principales:
CHIL: Controller Hardware in the Loop
En CHIL conectamos controladores y equipos de protección/automatización (relés, controladores de planta, reguladores, PLCs) a la simulación en tiempo real. Las señales suelen ser de bajo nivel (analógicas/digitales y comunicaciones), y el interés está en validar:
tiempos de respuesta
lógica de control
secuencias
coordinación entre dispositivos
comportamiento ante eventos
Los casos de uso en redes activas y microredes (control primario/secundario, coordinaciones, etc.) se trabajan muchísimo con CHIL porque permite probar la estrategia de control sin energizar nada.
PHIL: Power Hardware in the Loop
En PHIL damos un paso más: conectamos equipos de potencia (por ejemplo, un inversor real) a través de una interfaz de potencia (amplificadores, sensado, algoritmos de interfaz). Esto permite que el hardware intercambie potencia “de verdad” con el entorno simulado.
PHIL es potentísimo, pero también exige mucho más cuidado: la interfaz y su estabilidad, el dimensionamiento del amplificador, la seguridad, la disipación… Por eso, en muchos proyectos se combina: primero CHIL para afinar control y lógicas; luego PHIL para campañas de validación enfocadas.
Entonces… ¿qué tiene RTDS que lo hace tan relevante frente a offline?
Aquí viene el corazón del artículo. La comparación “offline vs tiempo real” no va de cuál es más “moderno”, sino de qué riesgos puedes cerrar.
1) El tiempo deja de ser “un parámetro” y se vuelve “la realidad”
En offline puedes tener un modelo excelente, pero el dispositivo real vive con un reloj determinista. En RTDS, la simulación también. Eso te permite detectar problemas que solo aparecen cuando hay:
retardos reales
secuencias rápidas
eventos encadenados
saturaciones y límites de control en milisegundos
En otras palabras: no solo validas el resultado final, validas el camino.
2) Pruebas cerradas en bucle: el equipo reacciona, y su reacción importa
En offline, muchas veces “asumimos” cómo actuaría un relé o un controlador, o lo representamos con un bloque simplificado. En hardware in the loop, el relé o el controlador real decide. Y esa decisión vuelve a impactar en la red simulada.
RTDS describe precisamente esa capacidad: ejecutar EMT en tiempo real y permitir que equipos físicos —protección, control o electrónica de potencia— se prueben en lazo cerrado con la red simulada.
3) Puedes probar la coordinación de un esquema completo, no solo un dispositivo aislado
Este punto es crítico y, honestamente, es donde vemos más valor en industria: la mayoría de incidentes no nacen de “un equipo malo”, sino de interacciones.
HIL permite probar múltiples dispositivos a la vez y validar el rendimiento del conjunto antes del despliegue.
Esto es especialmente útil cuando hay lógicas de automatización, cambios de grupo de ajuste, protecciones adaptativas o esquemas con PLCs.
4) Seguridad: fallar en el laboratorio, no en campo
Hay pruebas que nadie quiere hacer “de verdad” en una red energizada: faltas repetidas, maniobras exigentes, condiciones extremas, escenarios improbables pero críticos. En RTDS puedes empujar el sistema a límites en un entorno controlado.
Por eso se habla de RTDS y HIL como herramientas para reducir riesgos: reduces incertidumbre antes de conectar.
5) Validación y eficiencia cuando hay DER, inversores y redes activas
Cuando entran recursos distribuidos y convertidores, el comportamiento dinámico se vuelve más sensible. IEEE lo plantea claramente: la simulación HIL en tiempo real se ha consolidado como una herramienta eficiente para análisis y validación de sistemas eléctricos y componentes DER.
En el mundo real, esto se traduce en algo muy tangible: probar controles y protecciones antes de que el primer día de operación te regale una sorpresa.
Una historia típica: cómo se “nota” la diferencia entre offline y HIL
Imagina un proyecto con una planta renovable y un esquema de protección y control moderno. En offline, el modelo te dice que la falta se despeja, que la tensión recupera, que el control cumple… todo correcto.
El día que pasas a RTDS con hardware in the loop, aparecen preguntas que el offline no te obligaba a mirar:
-
¿el relé detecta exactamente cuando esperamos, con sus filtros reales y sus temporizaciones reales?
-
¿los contactos, señales digitales y comunicaciones llegan con el orden correcto?
-
¿hay condiciones en las que el control entra en un modo límite y provoca una reacción diferente?
-
¿una apertura/cierre en un instante “malo” genera un comportamiento que no estaba en el guión?
No es que el offline estuviera “mal”. Es que el offline estaba respondiendo a otra capa del problema. Cuando pasas a HIL, entras en la capa donde las cosas ocurren con reloj real.
Ventajas concretas frente a offline cuando hablamos de entregables de ingeniería
Aquí es donde lo conectamos con proyectos reales (lo que a nuestros clientes les importa):
Menos iteraciones en puesta en marcha
Cuando validas lógicas y ajustes en HIL, reduces la cantidad de pruebas “a ciegas” en site. Eso ahorra tiempo, viajes, discusiones y, sobre todo, riesgo operativo.
Ajustes de protecciones con mucha más confianza
Hay entidades que subrayan que verificar ajustes complejos “en la pantalla” es insuficiente y que las pruebas HIL del esquema completo pueden marcar la diferencia en estudios de protección.
Nosotros lo vemos clarísimo: con HIL no solo revisas curvas; verificas comportamiento del esquema.
Mejor calidad en el control y automatización
Con CHIL puedes probar cambios de setpoints, secuencias, lógicas anti-isla, modos de operación… antes de energizar.
Pruebas de eventos raros, sin miedo
Faltas repetidas, reconexiones, contingencias combinadas… en HIL puedes forzar escenarios que en campo serían delicados o directamente inviables.
Lo que solemos recomendar en INDIELEC para que RTDS y HIL no se queden en “un demo”
Aquí va nuestra parte favorita: la diferencia entre “tener RTDS” y “sacar valor de RTDS”.
-
Empezar por el riesgo real
No arrancamos con “hagamos un modelo gigante”. Arrancamos con el fenómeno crítico: protección, control, un evento, una coordinación. Construimos alrededor de eso. -
Diseñar un plan de pruebas como si fuera una puesta en marcha
HIL brilla cuando hay guión: casos, criterios de aceptación, secuencias, límites. Sin eso, se convierte en un laboratorio sin dirección. -
Construir el modelo para iterar
Versionado, trazabilidad, parámetros claros, señales bien nombradas. Esto parece gestión, pero en realidad es lo que hace que el proyecto avance. -
Elegir CHIL o PHIL con realismo
Si el objetivo es validar control y protecciones, CHIL suele dar muchísimo valor con menor complejidad. Si el objetivo es validar comportamiento de potencia de un dispositivo real, PHIL tiene sentido, pero lo planteamos como campaña enfocada (por requisitos de interfaz y seguridad).
Cómo ayudamos desde INDIELEC con RTDS y Hardware in the Loop
Lo decimos tal cual: la mayoría de equipos no necesitan “más tecnología”; necesitan un camino para aplicarla.
En INDIELEC solemos aportar en tres frentes:
-
Puesta en marcha y arquitectura de laboratorio (I/O, señales, comunicaciones, seguridad, estructura de modelos).
-
Formación práctica orientada a casos reales: que el equipo sepa montar, probar, interpretar y documentar.
-
Soporte y consultoría cuando hay plazos o fenómenos complejos: diseño de campañas HIL, creación de modelos EMT en tiempo real, integración con dispositivos, definición de criterios de aceptación.
La idea es que RTDS no sea “una máquina en una sala”, sino un entorno de validación que reduce riesgo y acelera decisiones.
Offline diseña, tiempo real valida, HIL te deja dormir
Si tuviéramos que resumirlo con una frase que usamos mucho: el offline te ayuda a diseñar; RTDS en tiempo real te ayuda a validar; hardware in the loop te ayuda a confiar.
La simulación offline seguirá siendo una herramienta base, y la usamos cada día. Pero cuando el proyecto entra en el terreno donde importan los milisegundos, las señales reales, la coordinación entre dispositivos y el comportamiento auténtico de protecciones y controles, la simulación en tiempo real con RTDS y el enfoque hardware in the loop marcan una diferencia enorme.
No porque sea “más moderno”, sino porque reduce el hueco entre el modelo y el mundo real. Y en sistemas eléctricos, cerrar ese hueco suele ser la diferencia entre una puesta en marcha tranquila… o una cadena de sorpresas que nadie quiere vivir.
English
