IEC 61375-2-3 (Communication Profile)

Introduction

The communication profile (IEC 61375-2-3), which is part of IEC 61375, ensures interoperability between consists of trains with respect to the exchange of information.

For this it defines all items which are needed, the so-called communication profile, of the Train Communication Network, as defined in TTDP (IEC 61375-2-5).

Overview

This part of the IEC 61375 revolves around three major parts:

1. Communication profile configuration
2. TCN-DNS
3. ECSP / ECSC

Communication profile configuration

The communication profile configuration file specifies functions and vehicles, and all their properties (such as id, name, etc.), in the local consist. This is also known as the “CSTINFO data”. This configuration file need to be consistent across all ETBNs that are part of the same consist (redundant nodes).

The data is structured hierarchically. The top scope of CSTINFO represents the local consist. As such, the root object contains information about the consist, as a list of consist-level functions, as well as the vehicles that the consist contains. These vehicles then also contain functions.

A ‘function’ in this context means an individual device, an interface on a device, or a multicast group - anything that can be resolved to one IP address using TCN-DNS. Functions can belong directly to a consist (which is often the case for multicast groups) or to a vehicle, which in turn belongs to a consist.

A ‘vehicle’ refers to an actual train car, a physical entity, which constitutes part of a consist. A consist can include one or more vehicles.

See the sections on CSTINFO and the TTDB data model in IEC 61375-2-3 for a more detailed discussion of these terms.

As mentioned above, the CSTINFO data for the local consist is provided to the system by means of a file on the ETBN device. This file is in JSON format, must be placed in a specific location, described below, and conform to the supplied JSON schema.

Consist and vehicle properties

The TTDB data model allows for opaque consist and vehicle “properties” data that is not parsed or interpreted by the implementation. This data is provided in the JSON file as Base64-encoded strings, using the alphabet in RFC 4648. To make the file more user-friendly, the encoded data is formatted as an array of strings (so that line breaks may be inserted between the array elements). The implementation will concatenate the string array, in order, and decode the Base64 data when the file is processed. The decoded data will not be parsed or interpreted in any way except for being included in the CSTINFO telegrams that the device transmits as per IEC 61375-2-3.

Since several vehicles in the file may use identical properties data, the file is structured in a way where vehicle properties are referenced indirectly - each vehicle object has an optional propSlot attribute, which maps to a slot attribute of a properties object in the vehPropList array. Consist properties are defined directly in the consist object. See the comm profile configuration schema for additional details.

TCN-DNS (Train Communication Network Domain Name System)

TCN-DNS specifies one of two interfaces (where the other interface is DNS according to RFC1035) that an application can use to lookup names, much like a DNS lookup, but with a few differences:

1. Queries whose URIs resolve to any local device will resolve relative to the querier, not the resolver.
2. Some queries will resolve to two IP addresses which represents an IP range, which can include more than two functions.

ECSP / ECSC (ETB Control Service Provider / ETB Control Service Client)

The ECSP, running on each ETBN, handles all communication and keeps a database of all vehicles, functions and operational states and statuses.

The ECSC, running on a selected device on the train, communicates with the ECSP in order to set and get various data sets.

TCN ECHO Server Interface

The TCN ECHO Server function can be used by end devices, running a compatible TCN ECHO Client function, to perform reachability and latency measurements to the Server (running on a WeOS device configured as an ETBN). When performing latency measurements, no guarantees are given regarding response time, other than that the TCN ECHO Server will attempt to respond as fast as possible.

A TCN ECHO Client needs to send an TCN ECHO request telegram via TRDP. When the TCN ECHO Server receives such a telegram, it will, as quickly as possible, send an TCN ECHO response telegram back to the TCN ECHO Client.

See Annex A - TCN ECHO request/response telegram below for a description of the fields and content of the TCN ECHO request and response telegrams.

Configuration

To setup the communication profile, perform the following steps:

1. Create a communication profile configuration file (see configuration options below).
2. Ensure that the file conforms to the provided JSON schema.
3. (Optional) Generate a SHA256 hash of the contents of the file using any suitable external tool.
4. Copy that configuration file to /cfg/cstinfo.json on the device. Do this for every ETBN in the consist, including redundant ETBNs.
5. (Optional) use the cstinfo-validate command in the config/ttdp context of the WeOS CLI to validate the file, verify its integrity by comparing the checksum from step 3. to a hash computed by WeOS, and store the hash for later verification.

For an example configuration of a communication profile, see Single consist net with two redundant ETB nodes HowTo

Configuration Options

The structure of the configuration file must conform to comm profile configuration schema.

Additionally, the CSTINFO data contained in the file must follow the data model described in IEC 61375-2-3. This implies the following (though this list is non-exhaustive). If these rules are not followed, the file will be rejected as “semantically incorrect”, even though it may still be syntactically valid (i.e. conform to the JSON schema).

• Functions must be related to (by means of the etbId attribute) either an ETB that has been defined in the etbInfoList, or use the special value “255”.
• Functions must have a cnId attribute that corresponds to a CN that has been defined (by means of cnCnt, since CN numbers start at 1 and are consecutive) for the ETB that it is related to, or use the special value “0”.
• Vehicles that use properties (via the propSlot attribute) must reference a properties object that is defined in the vehPropList array. The propSlot value must match a slot value.
• The cstVehNo numbers of defined vehicles must start at 1 and be consecutive without gaps.
• There must at most be 3072 functions defined in the consist, in total (at consist level as well as in all the vehicles).
• When the consist and vehicle properties have been decoded from the Base64 format, the total size of the resulting CSTINFO structure must be at most 65536 bytes on the wire.

See the sections on CSTINFO and the TTDB data model in IEC 61375-2-3 for a more detailed discussion of these rules and their meaning.

Annex A

TCN ECHO request response telegram

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              cmd              |            reserved           |0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           challenge                           |1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |2
|                                                               |3
|                                                               |4
|                            payload                            |5
|                                                               |6
|                                                               |7
|                                                               |8
|                                                               |9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: TCN ECHO request/response telegram layout

The TCN ECHO request and response telegrams have ComID 170 and must be handled according to the TRDP specification (see ).

The TCN ECHO request and response exchange is done by means of TRDP PD (process data) telegrams, as defined in Annex A in the IEC 61375-2-3 standard, using ComID 170 and the dataset shown in Figure 1 above. A description of each field in the dataset follows:

cmd

Type: Unsigned Int 16
Byte offset: 0

TCN ECHO command:
1 = request (sent by TCN ECHO Client)
2 = reply (sent by TCN ECHO Server)

reserved

Type: Unsigned Int 16
Byte offset: 2

Reserved. Recommended value 0.
TCN ECHO Server will copy this as-is into the reply telegrams’ reserved field.

challenge

Type: Unsigned Int 32
Byte offset: 4

The TCN ECHO Server will perform an XOR operation with 0x11257731 over the received challenge and copy the calculated result into the reply telegrams’ challenge field.

payload

Type: Array of Unsigned Int 8, length 32
Byte offset: 8

The TCN ECHO Server will copy the received payload as-is into the reply telegrams’ payload field.