Train Real Time Data Protocol

Train Real Time Data Protocol
Familia	Protocolo de internet
Función	Transferencia de datos en TCN
Puertos	17224/UDP Process Data (PD) 17225/UDP TCP Message Data (MD) (Transport)
Estándares
IEC61375-2-3 (2015)
[editar datos en Wikidata]

Train Real Time Data Protocol (TRDP) es un protocolo de red para la comunicación a través de redes basadas en IP en trenes y es parte de Train Communication Network (TCN). Se basa en UDP y opcionalmente en TCP, y permite el intercambio de datos de proceso (PD) y datos de mensaje (MD) entre dispositivos como controles de puertas, pantallas, aires acondicionados, etc. TRDP es un protocolo sin conexión, orientado a cuadros y forma la base para la comunicación en futuros trenes. El precursor es el protocolo patentado IPTCom de Bombardier Transportation, del cual TRDP maneja muchas características.

El protocolo fue desarrollado por el Grupo de Trabajo TC9 / WG43 de la IEC como parte de la TCN y estandarizado en IEC61375-2-3.^[1]​ Participan en el desarrollo y la estandarización son conocidos fabricantes y proveedores de material rodante para el tráfico ferroviario. Las actividades son coordinadas por el 'Grupo de Interés Especial de Código Abierto de la Red de Comunicación de Tren' bajo la abreviatura TCNOpen. TCNOpen es una iniciativa de código abierto fundada por los socios de la industria ferroviaria, con el objetivo de desarrollar conjuntamente componentes clave para los próximos estándares de comunicación ferroviaria.^[2]​ Una implementación de referencia en 'C' está disponible bajo la licencia de código abierto Mozilla MPL2 como "TRDP Light" en la plataforma SourceForge.^[3]​^[4]​

Los datos del proceso TRDP se envían cíclicamente a intervalos de 10 ms como paquetes UDP en el puerto 17224. Los remitentes reciben el nombre de "publicador" o "fuente", los destinatarios como "suscriptor" o "receptor". Varios patrones de comunicación son compatibles.

El emisor envía regularmente a un suscriptor. Si no se reciben datos dentro de un período de tiempo definido, por ejemplo B. en caso de una interrupción de la red, se activa un 'tiempo de espera' y los datos recibidos se marcan como obsoletos o se restablecen a cero. Además, el suscriptor puede usar un número de secuencia en el mensaje para ver si el paquete es nuevo o un duplicado de un remitente redundante, que luego se ignora.

Usando IP Multicast, los emisores pueden llegar a muchos suscriptores que se han suscrito a un grupo de multidifusión. Esto permite controlar grupos completos de dispositivos de forma sincronizada desde un transmisor.

Se puede usar un telegrama de solicitud para forzar la transmisión de datos de proceso. El emisor también debe enviar los datos fuera de los tiempos de ciclo establecidos. Los telegramas solicitados por el mecanismo pull llevan un identificador diferente ('Pp' en lugar de 'Pd', ver).

El direccionamiento de multidifusión permite que varios editores se dirijan simultáneamente; la dirección de respuesta también puede ser un grupo de multidifusión.

Los telegramas de datos de proceso constan de un encabezado y datos de usuario (incluido un remolque SDT opcional (Transmisión segura de datos)).^[5]​

• SequenceCounter: Se incrementa con cada telegrama transmitido

• MsgType:

• PR = PD Request
• PP = PD Reply
• PD = PD Data

• ComId: Específico de la aplicación, define el contenido de los datos, el intervalo y el tiempo de espera del telegrama etbTopoCnt: 0 para comunicación interna constante. En el caso de la comunicación remota, este es el CRC a través del 'Directorio de la red de trenes' y se verifica su validez tanto en el remitente como en el destinatario.

• opTrnTopoCnt: Necesario para telegramas con información direccional. Este es el CRC sobre 'Operational Train Directory'.

• DatasetLength: 0 a 1432 Bytes

• ReplyComID / ReplyIpAddress: Para telegramas de extracción, para determinar la respuesta de envío PD

• HeaderFCS: CRC32 según IEEE802.3, comienza el valor 0xFFFFFFFF, inverso y siempre en formato little endian

• Dataset: Max. 1432 Bytes de datos

Todos los datos se transmiten en 'Orden de bytes de red' (Big Endian), a excepción del FCS.

Los datos del mensaje TRDP son controlados por eventos a través de UDP o TCP en el puerto 17225. Los canales se denominan 'solicitante' o 'llamante', receptor 'oyente' o 'receptor'. Varios patrones de comunicación son compatibles.

Cuando se envía una 'notificación', el remitente no espera una respuesta. El emisor no puede determinar si el mensaje ha llegado al destinatario (en el caso de UDP). Cuando se realiza una solicitud, el llamante aprende con la respuesta, si el mensaje llegó (o al caducar un temporizador la ausencia de la respuesta). La respuesta puede solicitar que la persona que llama confirme la recepción del mensaje. Esto es importante si la respuesta ha causado un cambio en el estado de la respuesta y puede ser necesario deshacerla.

Si intercambia mensajes con frecuencia con los mismos dispositivos, tiene sentido usar una conexión TCP en lugar de UDP para la comunicación de datos de mensaje.

El tamaño máximo de datos a transferir está limitado a 64k (incluso para conexiones TCP).

Para el tráfico de datos de mensajes en UDP, también son posibles las direcciones de multidifusión:

La persona que llama puede especificar cuántas respuestas espera.

Los telegramas de datos de proceso constan de un encabezado y datos de usuario (incluido un tráiler opcional SDT (Safe Data Transmission)).^[5]​

• SequenceCounter: Se incrementa con cada telegrama transmitido

• MsgType::

• Mn = MD Notification
• Mr = MD Request mit Reply
• Mp = MD Reply ohne Confirmation
• Mq = MD Reply mit Confirmation
• Mc = MD Confirmation
• Me = MD Error

• ComId: Específico de la aplicación, define el contenido de los datos, el intervalo y el tiempo de espera del telegrama

• etbTopoCnt: 0 para la comunicación interna Consist. En el caso de la comunicación remota, este es el CRC a través del 'Directorio de la red de trenes' y se verifica su validez tanto en el remitente como en el destinatario

• opTrnTopoCnt: Necesario para telegramas con información direccional. Este es el CRC sobre 'Operational Train Directory'.

• DatasetLength: 0 a 65388 Bytes

• ReplyStatus

• SessionId: UUID de acuerdo con RFC 4122, identifica de forma única una sesión MD

• ReplyTimeOut: en µs

• SourceURI: Parte del usuario del URI de origen (parte antes del @)

• DestinationURI: Parte del usuario del URI objetivo (parte antes del @)

• HeaderFCS: CRC32 según IEEE802.3, valor de inicio 0xFFFFFFFF, inverso y siempre en formato little endian

• Dataset: Max. 65388 Bytes de datos

Todos los datos se transmiten en 'Orden de bytes de red' (Big Endian), a excepción del FCS.

Los telegramas PD y MD pueden utilizarse opcionalmente para la comunicación "segura" de acuerdo con SIL2 con una capa de enlace de datos. En IEC61375-2-3, el Anexo B define el Protocolo de Transmisión de Datos Seguros SDTv2.

El uso de TRDP es obligatorio (normativo) para la comunicación entre consiste a través de Ethernet según IEC61375-2-3, opcional para uso dentro de Consists.