¿Cuál es la diferencia entre PROFINET RT e IRT?

Volver al glosario

RT: tramas priorizadas sobre Ethernet ordinario

PROFINET RT logra el comportamiento en tiempo real sin abandonar el Ethernet estándar. Marca sus tramas de datos de proceso cíclicos con alta prioridad para que los switches las reenvíen antes que el tráfico de mejor esfuerzo, como páginas web o transferencias de archivos. Esas tramas también se saltan parte de la sobrecarga de la pila TCP/IP de propósito general, al manejarse de forma más directa, lo que reduce la latencia. El resultado es una comunicación suficientemente determinista para la inmensa mayoría de las tareas de automatización: leer sensores, escribir a actuadores, intercambiar estado con E/S remota, todo en un ciclo regular.

Como RT se apoya en la priorización más que en una planificación estricta, su temporización es buena pero no perfectamente rígida. Las tramas todavía comparten la red entre sí y con tráfico de menor prioridad, así que hay algo de variabilidad, o jitter, en el momento exacto en que llega una trama dada. Para el control de proceso y la mayoría de la E/S de fábrica esa variabilidad es cómodamente pequeña frente a los tiempos de respuesta que el equipo necesita, por lo que RT es totalmente adecuado y es la clase que la mayoría de los dispositivos PROFINET usa a diario.

La gran ventaja práctica de RT es que funciona sobre switches administrados ordinarios que soporten el manejo de prioridad correspondiente, sin hardware exótico. Un ingeniero puede construir una red RT con switches industriales de amplia disponibilidad, lo que mantiene bajos el costo y la complejidad. Esa cotidianidad también es lo que hace a RT relativamente fácil de observar desde afuera, porque las tramas viajan sobre infraestructura Ethernet normal que puede espejearse o intervenirse.

IRT: ranuras planificadas por hardware para control de movimiento

El Tiempo Real Isócrono existe porque algunas aplicaciones no toleran ni siquiera el pequeño jitter que RT permite. Coordinar varios ejes de movimiento para que se muevan en sincronía precisa, por ejemplo en una línea de impresión o en una máquina de manipulación sincronizada, exige que cada dispositivo envíe y reciba casi en el mismo instante en cada ciclo. IRT lo logra dividiendo cada ciclo de comunicación en ranuras de tiempo reservadas y planificando el tráfico isócrono en esas ranuras por adelantado, de modo que las tramas críticas en el tiempo tienen prácticamente garantizado un camino libre en un momento conocido.

Esta planificación se aplica en hardware y no se deja a la prioridad por software. IRT depende de switches con silicio especial capaz de IRT que entiende las ranuras reservadas y reenvía las tramas planificadas de forma determinista, manteniendo el jitter en el rango por debajo del microsegundo. Todo el segmento comparte una base de tiempo sincronizada y un plan de comunicación, así que la red se comporta casi como un mecanismo de relojería distribuido. Ese es el nivel de precisión que el control de movimiento necesita, y está muy por encima de lo que la priorización por sí sola puede dar.

El costo de esa precisión es hardware dedicado y más ingeniería. Un segmento IRT necesita los switches y dispositivos especiales que lo soportan, y el plan de comunicación debe diseñarse como parte de la ingeniería de red en lugar de dejarse al azar. Como las ranuras de tiempo están reservadas, una red IRT también asigna parte de cada ciclo al tráfico isócrono y parte al tráfico ordinario, así que ambos coexisten de forma cuidadosamente particionada. Por eso IRT se reserva para las partes de una máquina que genuinamente lo necesitan, con RT encargándose de todo lo demás.

Intervenir RT frente a IRT para monitoreo

Para un integrador de monitoreo, la distinción RT frente a IRT tiene una consecuencia muy práctica: qué tan fácil es observar el tráfico. Las tramas RT viajan sobre Ethernet ordinario en switches administrados estándar, así que a menudo pueden espejearse a un puerto de monitoreo o leerse a través de un gateway sin perturbar la red de control. Eso hace comparativamente sencillo subir los valores de proceso cíclicos de un segmento RT hacia un SCADA de nube, donde pueden historizarse, mostrarse en tableros y alarmarse junto con datos de otras fuentes.

Los segmentos IRT son otra cosa. Su tráfico depende del plan de ranuras de tiempo reservadas y del hardware especial que lo impone, así que espejear o insertar un dispositivo con descuido en un camino IRT arriesga perturbar el mismo determinismo por el que el segmento existe. A los datos de control de movimiento en una red IRT suele accederse mejor de forma indirecta, leyendo los valores de interés desde el controlador que ya participa en el plan IRT, en lugar de intervenir directamente el hilo isócrono. El controlador expone entonces los valores relevantes a través de una interfaz normal que un gateway puede leer.

En la práctica esto significa que una arquitectura de monitoreo bien planeada trata a las dos clases de forma distinta. Merobix y plataformas de nube similares suelen ingerir los datos de proceso y estado de nivel RT a través de un gateway o del controlador, que es donde de todos modos viven los valores operativos útiles, mientras dejan el tráfico de movimiento IRT estrechamente planificado al propio hardware de la máquina. Saber que un segmento es IRT le dice al integrador que no espere olfatearlo como Ethernet ordinario, y que alcance sus datos a través del controlador, manteniendo tanto el monitoreo confiable como el control de movimiento sin perturbar.

Preguntas frecuentes