Train Real Time Data Protocol
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. 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. 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.

Process Data (PD) 
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.

PD push 

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.

PD pull 

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.

PD Telegramm Format 

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

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.

Message Data (MD) 
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.

Patrón de comunicación MD 

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.

MD Telegramm Format 

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

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.

Información general 
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.

Referencias
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 . 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 . 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 . Process Data ( PD ) Los datos del proceso TRDP se envían cíclicamente a intervalos dems como paquetes UDP en el puerto Los remitentes reciben el nombre de " publicador " o " fuente " , los destinatarios como " suscriptor " o " receptor " . Varios patrones de comunicación son compatibles . PD push 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 . PD pull 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 . PD Telegramm Format Los telegramas de datos de proceso constan de un encabezado y datos de usuario ( incluido un remolque SDT opcional ( Transmisión segura de datos ) ) . 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: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:aBytes ReplyComID / ReplyIpAddress : Para telegramas de extracción , para determinar la respuesta de envío PD HeaderFCS : CRC32 según IEEE802.3 , comienza el valorFFFFFFFF , inverso y siempre en formato little endian Dataset : Max.Bytes de datos Todos los datos se transmiten en ' Orden de bytes de red ' ( Big Endian ) , a excepción del FCS . Message Data ( MD ) Los datos del mensaje TRDP son controlados por eventos a través de UDP o TCP en el puerto Los canales se denominan 'solicitante ' o ' llamante' , receptor ' oyente ' o ' receptor ' . Varios patrones de comunicación son compatibles . Patrón de comunicación MD 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 deshacer la . 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 ( 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 . MD Telegramm Format Los telegramas de datos de proceso constan de un encabezado y datos de usuario ( incluido un tráiler opcional SDT ( Safe Data Transmission ) ) . 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: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:aBytes ReplyStatus SessionId : UUID de acuerdo con RFC 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 inicioFFFFFFFF , inverso y siempre en formato little endian Dataset : Max.Bytes de datos Todos los datos se transmiten en ' Orden de bytes de red ' ( Big Endian ) , a excepción del FCS . Información general Los telegramas PD y MD pueden utilizar se 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 . Referencias