UIC CODE 556

4th edition, August 2005

Translation OR

Information transmission in the train (train bus) - General

dispositions
Transmission d’informations dans le train (bus de train)
Informationsübertragung im Zug (Zugbus) - Allgemeine Bedingungen
Leaflet to be classified in Volumes:
V - Rolling stock
VI - Traction

Application:
With effect from 1. August 2005
All members of the International Union of Railways

Record of updates
1st edition, June 1998 First issue, was not published in the UIC Code.

2nd edition, May 1999 Redactional corrections without modification of the contents,
addition of new telegrams in Appendices 1 and 2.1 to 2.3, first issue
of Appendices 5.3, 7, 8 and 9 and approval of new train bus nodes;
has not been published in the UIC Code.

3rd edition, October 2004 Adaptation to the editor’s guide M1 coordination and insertion of the
new content of the applications traction and doors; insertion of new
appendix G (prev. 7) "Homologation procedure of train bus nodes",
editorial changes; has not been published in the UIC Code.

4th edition, August 2005 Publication in electronic format with Appendices A, B, E, I and J
published on the Internet site

The person responsible for this leaflet is named in the UIC Code

556
OR
Contents

Summary ..............................................................................................................................1

1- General......................................................................................................................... 2

2- Scope ........................................................................................................................... 3

2.1 - Basis ..................................................................................................................... 3

2.2 - Special cases........................................................................................................ 3

3- Laying down the Standard ......................................................................................... 4

3.1 - Classification of UIC Leaflet 556........................................................................... 4

3.2 - Train Communication Network - TCN................................................................... 5
3.3 - UIC Leaflet 556..................................................................................................... 5
3.4 - Applications .......................................................................................................... 5

4- Specifications for the hardware................................................................................. 6

4.1 - Bus structure......................................................................................................... 6

4.2 - Cable for the transmission of information ............................................................. 7
4.3 - Train bus nodes .................................................................................................... 8

5- Specification of the software ................................................................................... 10

5.1 - Operating conditions........................................................................................... 10

5.2 - Inauguration........................................................................................................ 14
5.3 - Train structure..................................................................................................... 16
5.4 - Transmission cases ............................................................................................ 17
5.5 - Vehicle addressing ............................................................................................. 17
5.6 - Functional addressing......................................................................................... 19
5.7 - Telegram structures............................................................................................ 20

6- Reliability ................................................................................................................... 27

6.1 - Failure rate.......................................................................................................... 27

6.2 - Error tolerance .................................................................................................... 27
6.3 - Transmission reliability in undisturbed operation................................................ 27

556-0
OR
7- Modification procedure ............................................................................................ 29

7.1 - Modification competence .................................................................................... 29

7.2 - Modification procedure ....................................................................................... 30
7.3 - UIC-Steering Group "Train bus" ......................................................................... 31

8- Test procedure for train bus nodes (gateways) ..................................................... 32

8.1 - Homologation...................................................................................................... 32
8.2 - Homologation procedure .................................................................................... 32
8.3 - Approval of the test laboratory............................................................................ 32

9- Other matters............................................................................................................. 33

Appendix A - List of information to be transmitted (Version 002.02,

valid from 01.08.2005) ................................................................................ 35

Appendix B - Composition of the R telegrams ............................................................... 36

B.1 - Composition of the R1 telegram (Version 002.02, valid from 01.08.2005) ......... 36
B.2 - Composition of the R2 telegram (Version 002.02, valid from 01.08.2005) ......... 36
B.3 - Composition of the R3 telegram (Version 002.02, valid from 01.08.2005) ......... 36

Appendix C - Inauguration and Mapping Server............................................................. 37

C.1 - Concept of the train inauguration (Version 002.02, valid from 01.08.2005) ....... 37
C.2 - UIC Mapping Server - Specification (Version 002.02, valid
from 01.08.2005) ................................................................................................ 55
C.3 - Construction of the inauguration frame (Version 002.02, valid
from 01.08.2005) ................................................................................................ 84

Appendix D - Process Data Marshalling (PDM) - Specification

(Version 002.02, valid from 01.08.2005) .................................................... 91
D.1 - Introduction ......................................................................................................... 91
D.2 - Marshalling types................................................................................................ 91
D.3 - Marshalling Modes.............................................................................................. 92
D.4 - Data paths in PDM.............................................................................................. 92
D.5 - PDM Operation ................................................................................................... 94
D.6 - PDM Function ..................................................................................................... 96

556-0
OR
Appendix E - Vehicle properties and collective addresses ........................................... 99
E.1 - List of static vehicle properties (Version 001.02, valid from 01.08.2005) ........... 99
E.2 - List of dynamic vehicle properties (Version 001.02, valid from 01.08.2005) ...... 99
E.3 - List of collective addresses (Version 001.02, valid from 01.08.2005)................. 99

Appendix F - TCN Data Types (Version 001.02, valid from 01.08.2005) ..................... 100
F.1 - Presentation and encoding of transmitted data ................................................ 100
F.2 - Data ordering .................................................................................................... 100
F.3 - Notation for the primitive types ......................................................................... 101
F.4 - Structured types................................................................................................ 107
F.5 - Natural alignment.............................................................................................. 110
F.6 - Notation for the TIMEDATE48 type .................................................................. 110

Appendix G - Homologation Procedure for Train Bus Nodes

(Version 001.01, valid from 01.08.2005) .................................................. 112
G.1 - Foreword........................................................................................................... 112
G.2 - General prescriptions........................................................................................ 112
G.3 - Procedure ......................................................................................................... 112
G.4 - Contact details .................................................................................................. 114

Appendix H - Conformance testing (Version 001.02, valid from 01.08.2005) ............. 116
H.1 - Definitions ......................................................................................................... 116
H.2 - General ............................................................................................................. 117
H.3 - Train configurations .......................................................................................... 119
H.4 - Guidelines to conformance testing execution ................................................... 123
H.5 - Test bed............................................................................................................ 124
H.6 - Test suites ........................................................................................................ 125

Appendix I - Type approved train bus nodes in vehicles that run in

international services (Version 001.02, valid from 01.08.2005) ............ 214

Appendix J - Modification list (Version 002.02, valid from 01.08.2005)...................... 215

List of abbreviations ........................................................................................................216

Glossary ...........................................................................................................................218

Bibliography .....................................................................................................................220

556-0
OR
Summary

This leaflet defines the requirements for data transmission equipment on RIC coaches.

The requirements may also be applied to other coaches, driving trailers, traction vehicles and multiple
units.

The purpose of this leaflet is to:

- fully document the requirements of all users, align them and set them out in standard form,

- provide guidelines for the technical solution adopted for the train bus and the physical
characteristics of the transmission cable,

- Lay down and specify the details of the requirements of the various UIC Committes as listed in
Appendix A - page 35.

Concrete train bus applications for certain functionalities are not dealt with in UIC Leaflet 556. They
are contained in other leaflets administered by the UIC bodies responsible for the respective vehicle
components.

1 556
OR
1 - General

The object of the train bus is to transmit information of all types from any vehicle of a train or multiple
units in passenger service into one or more other vehicles of the same train.

With the help of the train bus

- the operating process should be made more flexible by increased and differentiated remote
control possibilities,

- the work of the Operating Department staff should be made easier,

- the safety of passenger traffic should be increased,

- additional functionalities should be opened up in passenger traffic as, for example,

• automatic brake testing,

• comprehensive information and service for the passengers,
• general use of diagnostic techniques in the vehicles,
• saving of energy.

2 556
OR
O 2 - Scope

2.1 - Basis

The present requirements apply to a homogenous train formation, in which in the undamaged
condition all vehicles are either completely bus compatible or only suitable for train inauguration and
participate in bus traffic.

2.2 - Special cases

The equipment should be partly usable if cable vehicles are fitted between bus capable vehicles,
which do not actively take part in the bus traffic, but allow the unhindered transmission of information
within the train composition.

If passenger trains are made up of individual coaches or vehicles with damaged bus connections, then
the conventional functions of the remote control and information as specified in UIC Leaflet 558 (see
Bibliography - page 220) are controlled by it and not by the train bus.

In detail these are:

- remote control of the doors as specified in UIC Leaflet 560;

- remote control of the lighting as specified in UIC Leaflet 555;

- passenger address throughout the train by means of loudspeaker equipment as specified in UIC
Leaflet 568 (see Bibliography - page 220).

Should, in this special case, further functions be necessitated over the train bus, then operating
regulations should be introduced and application side precautions taken.

On trains made up of vehicles that do not have transmission cables the operation should be done
conventionally without using the train bus.

3 556
OR
3 - Laying down the Standard

3.1 - Classification of UIC Leaflet 556

This Leaflet has the function shown in Fig. 1 of a connecting element between the functions of the
technical applications (application) in passenger coaches, traction units and multiple unit trains e.g.
for traction control, brake control, door control, passenger services, diagnostics etc. and the data
transmission specified in IEC Standard 61375 Train Communication Network TCN for the train bus -
Wire Train Bus (WTB) (see List of abbreviations - page 216 and Bibliography - page 220).

Operator (e.g. driver, train staff)

⇔

⇔
⇔
⇔
diagnosis traction brakes door control
UIC Leaflet 557 UIC Leaflet 647 UIC Leaflets 54X UIC Leaflets 560/660
⇔
⇔

⇔
⇔

⇔
UIC Application Leaflet 556 ⇔
⇔

Data R
⇔

Data E
(process data) (message data)

IEC 61375
(TCN - Standard for WTB)

Fig. 1 - UIC-Leaflet 556 as connecting element between

IEC Standard 61375 (TCN) and the functions of the UIC applications

The functionalities of the application of the UIC train bus are shown in Appendix A - page 35. It is not
possible in most cases to allow the signals or data transmitted over the train bus to directly affect the
individual control systems or vehicle components or to obtain signals from these. Signals which
contain the necessary information must, therefore, be defined with a view to the use of the train bus
for the individual functionalities. These signals must be translated by the application, in order to
achieve the necessary independence from concrete technical solutions. In addition it should be
specified what the time response for the individual pieces of data must be and how the application
should behave when faced with irregularities and defects in the data traffic.

4 556
OR
O 3.2 - Train Communication Network - TCN

The IEC-Standard 61375 Train Communication Network TCN specifies the data transmission in trains
through the train bus (Wire Train Bus). UIC Leaflet 556 is based on this standard. Consequently it is
mandatory to use the TCN standard in its Wire Train Bus (WTB) elements for the achievement of a
data transmission system. The use of the data formats, protocols etc. defined in it or the functions
offered through the user interface (application interface) is binding.

O 3.3 - UIC Leaflet 556

This Leaflet specifies the parameters with which the functions of IEC 61375 are used in a standard
way in the case of a "UIC" use. This ensures that all vehicles built to this specification speak the same
language over the train bus.

The Leaflet also specifies all the necessary details of all the information to be exchanged on the train
bus of trains and vehicles that run in international traffic (see Appendix A - page 35 and B - page 36
as weel as point C.3 - page 84. These definitions apply up to the interface, from and to the
applications, and are kept so general that they are not dependent on concrete technical solutions. In
addition it is specified how the time behaviour for the individual information must be and how the
application must react to irregularities and defects in the data flow.

The modification procedure for the leaflet is described in point 7 - page 29.

In addition, the UIC train bus offers the possibility of achieving national or bi- or multinational
applications through the use of the UIC parameters. This is explained in Appendix B - page 36 and
can be done independently or in addition to the UIC application.

O 3.4 - Applications

The functions of the applications of the UIC train bus, that is to say the regulations of how to achieve
a uniform process of generating and processing the information to be transmitted, are specified in
special UIC leaflets for such applications, some of which still have to be written (see UIC Leaflet 557
for diagnostics in passenger coaches, UIC Leaflet 647 for traction control, UIC Leaflet 541-5 for EP
brakes and emergency brake shorting out, UIC Leaflet 560 for doors in passenger coaches, UIC
Leaflet 568 for public address, UIC Leaflet 176 for passenger information systems etc. see
bibliography - page 220).

These UIC leaflets are prepared and updated by the UIC technical Committees responsible for these
applications. These leaflets also contain the conditions for the necessary tests of these applications
for conformity.

5 556
OR
4 - Specifications for the hardware

4.1 - Bus structure

4.1.1 - Principles

The train bus must be able to operate with between 2 and 22 vehicles with a maximum of 32 train bus
nodes and a transmission cable length (source ⇔ sink) of up to 850 m.

At least one train bus node is planned per vehicle. For redundancy purposes it is recommended that
two train bus subscribers are used on traction units (see Glossary - page 218) and for the bus
connection of the driving cab equipment of driving trailers (this also applies to multiple units). In this
case, one of the two redundant train bus subscribers is always active and the other is in cold standby
mode.

In the case of failure the activation of the train bus subscriber in cold standby is done automatically.
Faults and remedies should however be diagnosed, displayed and stored.

The following maximum damping values based on the bit rate should be met:

per train bus node 0,3 dB

per vehicule (with short-circuited train bus nodes) 0,5 dB
per train 20,0 dB

4.1.2 - Types of UIC train bus connection

For the type of bus connection (see Fig. 2) a distinction should be made between

- vehicles with individual train bus nodes,

- traction units, driving trailers and multiple units fitted with two redundant train bus nodes,

- trainsets, i.e. groups of vehicles with a common train bus node for several vehicles (these can also
be designed as redundant, if, for example, a driving trailer function is available).

Vehicle bus

Tractive units with Vehicle with Trainset with common node Driving trailer with
redundant nodes individual node for several vehicles redundant nodes

Fig. 2 - type of UIC train bus connection

A special form of the UIC train bus connection is given, if in one vehicle several different functions
(traction or vehicle functions) are allotted to the train bus nodes present. In such a case care should
be taken that on the train bus level no functional conflicts occur.

6 556
OR
 To meet the error tolerance requirement of point 6.2 - page 27 two synchronously working bus lines
with separate cables and plug devices between the vehicles shall be provided as shown in Fig. 3.

O 4.2 - Cable for the transmission of information

4.2.1 - Physical features

The cable for the transmission of information within the trains shall be designed as a shielded 2 core
cable to guarantee defect-free transmission. Two redundant cable ways (line A and line B) shall be
provided (see Fig. 3).

The physical features, the principle routing and the coupling in coaches of passenger trains are
described and specified in UIC Leaflets 558 and 541-5.

For multiple units these conditions apply also in respect of the coupling between vehicles.

Direction train bus nodes (vehicle or trainset):

B A A

1 2 2 1 2 1

Line Line Line

Unit B Unit A Unit A
Node Node Node
Line Line Line
Unit A Unit B Unit B

1 2 2 1 2 1

A B B

Fig. 3 - Principle coupling of the train bus nodes on the cable

4.2.2 - Additional features

- The train bus cable must be designed as electrically isolated. This means a separated-potential
subscriber interface. The cable used shall be kept exclusively for information transmission.

- The shield of the train bus cable at the train bus nodes in the vehicles shall be connected to earth
and may not be coupled through or connected between the vehicles.

- The shields must be earthed whenever possible.

The shield concept is specified in UIC Leaflet 558.

7 556
OR
 End node Intermediate node(s) End node
terminator jumper jumper
connector connector

Inter-vehicle Inter-vehicle
impedance impedance

Vehicule Vehicle Vehicle

ground ground ground

Fig. 4 - Shield concept for the trains bus nodes

O 4.3 - Train bus nodes

The electrical consumption of a train bus node from the battery supplied DC system of the vehicle shall
not exceed 10 W when it is in sleep mode (see point 5.1 - page 10).

The train bus nodes must be able to operate in the voltage tolerance range of 0,7 to 1,25 x Unominal.
Moreover, they must meet the other conditions specified in EN 50155 (see Bibliography - page 220).

The connection of the train bus nodes in the vehicles must result in the clear recognition of the forward,
backward, right and left directions of the train as specified in Fig. 5 - page 9.

8 556
OR
 Reference direction vehicle/trainset ì

Left

- -vehicle end 2 - vehicle end 1

- -rear - front
- train bus node connection 2 - train bus node connection 1
-
Rightight
ht 1

Vehicle
Line A

Coupling box 2 1
2 1
Train bus
2 1
Cable with plug Other functions
as specified in
Line B
UIC leaflet 541-5
or UIC leaflet 558

Trainset

Vehicle Vehicle Vehicle

2 2 2 1 1 1
vehicle bus
b

Fig. 5 - Installation of the train bus node in the vehicle/trainset (plan view)

9 556
OR
O 5 - Specification of the software

5.1 - Operating conditions

The train bus nodes in an individual vehicle should be able to take up the following conditions:

Operating
conditions Properties
N° Designation
0 Off A train bus node is not able to work when the voltage of the DC system of
the vehicle concerned falls below 70% of the nominal voltage.
1 Sleep mode The train bus node of a vehicle can receive signals on the train bus cable,
e.g. inauguration commands.
2 Inauguration The train bus nodes of the individual vehicles are polled from the TCN
master.
They export the specified vehicle properties (see point C.2 - page 55)
according to the inauguration concept (see Appendix E - page 99) as part
of the inauguration frame (see point C.3 - page 84).
The vehicles are numbered in the sequence defined in point C.1 - page 37.
The result of the inauguration is the listing of all vehicles with their data. It
is determined from the inauguration frames of all vehicles and filed in the
NADI (see point C.1).
3 Full Information exchange as specified in Appendix A - page 35.
operation

A new configuration of the telegram structures because of modifications of the status of individual
vehicles (leading, not leading, driven, not driven (see point 5.2 - page 14) must take place during full
operation and may only restrict the usability of the bus for a maximum of 1 second (this may be a
maximum of 1,4 seconds for errors and defects in the inauguration command - see point 6.2 -
page 27).

The following requirements determine the transitions of the operating and internal conditions of the
train bus node:

- With battery charge available, the train bus node goes into the inauguration and full service
operation.

- If the train bus node is in the sleep mode (operating condition 1), the operation of the push button
"coach lighting on" on the operating switch desk as specified in UIC Leaflet 550-1 (see
Bibliography - page 220) initiates the transition into the inauguration and full operation (operating
conditions 2 and 3).

- If bus activity is recognised during sleep mode, the train bus node goes into the inauguration and
full service operation (operating conditions 2 and 3).

10 556
OR
- 45 minutes after the termination of battery charging throughout the train (e.g. switching off of the
train line from the traction unit), the train bus goes into the sleep mode (operating condition 1)
corresponding to the sleep concept of IEC standard 61375. 45 minutes after the loss of battery
charge in the vehicle concerned, each train bus node thus sends to the train bus master the order
to go to sleep.

- If the protection of the battery against deep discharge is activated (see also UIC Leaflet 550 - see
Bibliography - page 220), the train bus node is switched off (operating condition 0), since all
remote-controlled loads are likewise switched off.

- For emergency operation the train bus node can also be switched on below the lowest switch off
stage of the minimal voltage with the push button "coach lighting on" on the operating desk,
provided that the minimum voltage of the DC system (70% of the nominal voltage, EN 50155) is
available.

- The UIC Mapping Server telegram "request to change to sleep mode" controls the transition
between node operation and waiting in sleep [Link] DC system of the vehicle is monitored
with a suitable device, in order to derive the conditions for the change of condition of the train bus
node.

The following conditions are required:

- battery charging in the vehicle (available or not available);

- monitoring of the protection of the battery for deep discharge (undershooting or overshooting);

- local inauguration request by the falling edge when operating the push button "coach lighting on";

- remote inauguration request by bus activity on the train bus (is recognised by the train bus node);

- it is possible to go from the operating condition "full operation" directly into the condition "wait in
sleep mode" by sending a suitable E telegram.

11 556
OR
 Local inauguration
normal node request or remote
operation inauguration request
Cancel TCN
Sleep

being recharged
battery is being

battery is not
Request Local inauguration

recharged
request
or local inauguration request

Switch off node after being

Battery is being recharged

Telegram 15.04(1)

triggered by the battery

or telegram 15.04(0)

protection against deep

45 min timer is discharge for more than
running 5 minutes Node off

Off
Telegram 15.04 (1)
Time > 45 min. or

TCN Sleep Switch off node after being

Request triggered by the battery
protection against deep
discharge for more than
5 minutes
TCN master has received
Waiting for all sleep requests
Sleep Mode
sleep mode TCN slave detects no
bus activity
Inauguration and normal operation Sleep mode

Legend:

State Internal state of a train bus node State Operational state of a train bus node

TCN command with Condition

state transition State transition with condition

Fig. 6 - Operating conditions and condition transitions of the train bus nodes

Terms:
Minimal voltage lowest stage: The lowest stage for loads on the battery achieved as
specified in UIC Leaflet 550 in the vehicle.
Local inauguration command: Local operation of the push button coach lighting or a
battery charge in the vehicle.
Remote inauguration command: Bus activity recognised on the train bus.
Telegram 15.04 (X): UIC Mapping Server Telegram "request to change to
sleep mode" (1) request (0) cancel, (see Appendix A -
page 35).

12 556
OR
The following table describes the operating modes shown in Fig. 6 - page 12 and changes of mode:

Mode Condition Resulting mode Explanation

Inauguration Operation of the protection Out Switching off after operation of the protection for
and full of the battery for deep dis- (mode off) deep discharge of the battery.
operation charge for more than
5 minutes
Node No battery charging in the Timer runs After the end of battery charging a timer starts
operation vehicle 45 mins with a duration of 45 min. before the sleep mode
is ordered.
Telegram 15.04(1) Wait for sleep With the UIC Mapping Server telegram
mode "Request to change to sleep mode change"
(request), the sleep mode can be entered
without timer waiting delay.
Timer runs Time > 45 min. or Wait for sleep After the timer has run out, the train bus node
45 min. telegram 15.04(1) mode sends the request "sleep request" over the train
bus, in order to request the sleep mode as
specified in IEC Standard 61375.
Battery charging in the Node operation If battery charge is restored the timer is reset.
vehicle
Waiting for All sleep requirements Sleep Mode) Corresponding to the sleep concept of the IEC
sleep mode receive (TCN-Master) or standard 61375, the train bus master ends its
no bus activity activity as soon as it has received the sleep
(TCN-Slave) request from all bus nodes. The train bus
slaves go into sleep mode, if there is no further
train bus activity.
Battery charging in the Node operation If battery charging returns, if the push button
vehicle or local "coach lighting on" is pressed or if the UIC
inauguration request or Mapping Server telegram "request to change in
telegram 15.04(0) sleep mode" (cancel) is received, the sleep
request is withdrawn, that is to say "sleep
request cancel" is sent out. Train bus activity
does not lead to the withdrawal of the sleep
request with the TCN request "sleep request
cancel".
Sleep mode Local inauguration request Node operation The train bus node is woken up by battery
or remote inauguration charging on the train line.
With the push button "coach lighting on", the
train bus node in a vehicle can be switched on,
which then wakes up the other train bus nodes
with an inauguration.
Operation of the protection Off Switching off after operation of the protection of
of the battery for deep (Node off) the battery for deep discharge.
discharge for more than
5 min.
Off Operation of the protection Node operation The train bus node in a vehicle can be switched
of the battery for deep on with the push button "coach lighting on",
discharge or local even when the protection of the battery against
inauguration request deep discharge has been activated. Thus the
train bus can be woken up from this vehicle.

13 556
OR
5.2 - Inauguration

5.2.1 - Concept

A precondition for the smooth operation of the data transmission system over the UIC train bus in
trains made up of individual coaches and in multiple units, which can also include trainsets, is the
carrying out of the inauguration.

The inauguration is divided into the two parts given below:

- TCN inauguration to guarantee the data transmission as specified in IEC Standard 61375;

- UIC inauguration for the formation of the actual vehicle configuration regarding the data traffic.

The concept of the train inauguration, especially the UIC inauguration is described in detail in point
C.1 - page 37.

5.2.2 - UIC Mapping Server

The purpose of the UIC Mapping Server is to guarantee the standard procedure of the inauguration
with distribution of the TCN and UIC inauguration numbers throughout the train, the static and dynamic
vehicle properties in the NADI (Node Address and Attribute Directory) etc. as well as to carry out the
special functions such as collective and group addressing. This is a software module in the UIC train
bus node, which ensures the function of the UIC train bus while considering the real vehicle
configuration.

The specification of the UIC Mapping Server is given in point C.2 - page 55.

The use of the UIC Mapping Server specified in point C.2 is a precondition for guaranteeing the
function of the UIC train bus according to this leaflet.

A further software model for carrying out special functions for certain information to be transmitted over
the UIC train bus is the Process Data Marshalling (PDM). This guarantees the possibility of combining
and assessing information and data according to the criteria specified by the application. The
specification of the Process Data Marshalling is given in Appendix D - page 91.

The conformity test to be carried out for vehicles in international traffic for train bus nodes with
implemented function of the UIC Mapping Server is described in detail in point 8 - page 32.

5.2.3 - Vehicle sequence

[Link] - Determining the forward, backward, left and right direction

A "reference direction train" is specified for the complete train. This is calculated from each train bus
node of the UIC sequence specified with the train inauguration and stored in the NADI.

The detailed description is contained in point C.1.

14 556
OR
[Link] - Specifying the vehicle sequence number

Independent of the technology of the "UIC train inauguration", the vehicles in the inauguration result
are numbered in sequence - starting from the leading vehicle at one end of the train composition:
- 01 - 02 - 03 - ... - MN.

If the inauguration is initiated from the leading vehicle, the inauguration result should be shown there.
The traction unit driver can correct the inauguration result in the leading vehicle if there are vehicles
which do not take part in the inauguration in between bus-fitted vehicles e.g. vehicles which cannot be
automatically inaugurated due to defects in the train bus node. Detailed specifications are given in UIC
Leaflet 647.

If a train inauguration is carried out without the presence of a leading vehicle by the application master
in any other vehicle of the train, then in conjunction with the application (e.g. initialising of functions of
the passenger information and seat reservation) a correction of the inauguration must be possible on
a suitable man-machine interface. Detailed specifications for this are contained in specific new UIC
leaflets (to be produced).

The coach order numbers for seat reservations are independent of this numbering as part of the UIC
train inauguration. The coach order numbers are static vehicle properties (see point E.2 - page 99) as
far as the data traffic over the train bus is concerned. They must be announced to the system for
passenger information systems.

For the specification of the vehicle with the serial number 01 the following cases which are described
in detail in point C.1 - page 37 apply:

1. Leading vehicle at one end:

This vehicle = vehicle 01

2. Leading vehicle within a train composition:

The vehicle 01 is the end vehicle, which is located nearer to the leading vehicle, when counting
the number of intermediate vehicles. If there is an identical number of vehicles, 4. applies.

3. No leading vehicle within the train composition but a traction unit at one end of the train
composition:
This vehicle = vehicle 01

4. All other cases:

Vehicle 01 is at one of the two ends of the train and so the TCN sequence tends to correspond to
the UIC sequence

Example: TCN : 61 62 63 01 02 ...

UIC : 01 02 03 04 05 ...

15 556
OR
5.2.4 - Multiple inaugurations

If the inauguration of two or more vehicles starts at the same time, then TCN resolves the conflict
automatically. As a result a completely inaugurated train is produced.

5.3 - Train structure

5.3.1 - Leading vehicle

The leading vehicle controls the movements of the train, especially the brake. It is generally occupied
(except, for example, when radio-controlled). The property "leading vehicle" is transmitted to the
vehicle concerned and consequently to the UIC train bus by a precise operation, in general by the
activation of the driver's brake valve (see UIC Leaflet 647).

There is always a maximum of one leading vehicle in the train. Details of how the leading vehicle in
the train is determined are given in point C.1.3.2 - page 39.

Traction units, railcars, multiple units, locomotives and driving trailers (see Glossary - page 218) can
take on the property "leading vehicle".

5.3.2 - Vehicle properties

Further features must be given for the accurate description of vehicle properties. For this a distinction
should be made between static and dynamic properties:

- Static properties are features built into the vehicle and thus only dependent on its class or design.

- Dynamic properties depend on the operating condition of the vehicle and/or on the way it is
operated.

The static vehicle properties are listed in point E.1 - page 99. The table gives,

- whether the property depends on the train bus nodes (gateway) (= trainset) or on the individual
vehicle;

- in which octet/bit of the inauguration frame this property is given to the other train bus nodes;

- which telegrams are supported by the train bus node concerned that is to say sent and/or
processed, if this property is available.

The dynamic properties of the vehicles are given in point E.2 - page 99.

16 556
OR
5.4 - Transmission cases

The individual applications of the UIC train bus, which require a general train data transmission, are
given in Appendix A - page 35. The list is divided into the following functional areas:

0 Test purposes
1 Door control and door monotoring
2 Lighting control
3 Public address
4 Traction control
5 Brake functions
6 Completeness of the train
7 Central control of the climatic equipment
8 General train diagnosis
9 Control of equipment for passenger information
10 Central control of the power supply equipment
11 Others
...
15 UIC Mapping Server

Even if not all applications are installed at the same time and from the beginning, the UIC train bus
system is basically designed so that it controls all the applications shown and still has reserves for
additional applications which may become necessary later.

This list is, therefore, continuously updated (see also point 7 - page 29).

In the functional range "public address" only the control of the participating equipment in the vehicles
of the train is operated with the help of the UIC train bus. The sound transmission itself is done as
specified in UIC Leaflet 568 using wires 1-4 of the remote control and information cable specified in
UIC Leaflet 558.

5.5 - Vehicle addressing

5.5.1 - Addresses

Each telegram carries the source address (UIC inauguration number of the sender of the information)
and the destination address (UIC inauguration number of the receiver of the information).

The source address always allows determining the UIC vehicle number corresponding to the
inauguration result.

17 556
OR
Each receiver can, therefore, always ascertain from which vehicle the incoming information comes.
The cases in which this knowledge is of significance for carrying out the operation are marked in
Appendix A - page 35 in columns 16 and 19 by brackets.

On the users level a collective or group address as specified in points 5.5.2 and 5.5.3, can be used as
the destination address besides the UIC inauguration number of a given vehicle. Thus information can
be transmitted at the same time to several vehicles involved.

5.5.2 - Collective addresses

Collective addresses are used for

- static vehicle properties as specified in point E.1 - page 99 or

- dynamic vehicle properties as specified in point E.2 - page 99 or

- certain states transmitted by R telegrams.

The collective addresses used are listed in point E.3 - page 99.

5.5.3 - Group addresses

Independent of vehicle properties or because of operating events, certain vehicles of different groups
can be freely selected and arranged to have defined group addresses (e.g. different journey routes of
vehicle groups, travel companies in certain vehicles). The system is set up to support a minimum of
15 of these freely selectable groups. The detailed arrangements for the selecting, advising, reading
and deleting of groups are contained in the relevant UIC leaflets which describe the application.

A group is characterised as follows:

- Group number (201 to 254)

Each group number may only be present once in the group database.

- Number of vehicles in the group.

- Group description
A data field with a length of 32 characters (UNICODE16) is specified for the verbal description of
a group and the proposed functionality including eventual user restrictions for certain functions.

- Vehicle identification numbers (ID) of the group members

Dynamic groups are independent of any train inaugurations that become necessary during the
period in service. Therefore the characterisation of the group members is done through the vehicle
identification numbers (ID).

In order to prevent the parallel input of modification of groups within a train, a token-bit set to "0" is
used in the R data (R3 telegram, octet 10, bit 3). This token-bit indicates that group data is sent over
the train bus from any subscriber. It can be placed by any subscriber. The detailed mechanism for the
use of this token-bit has to be defined in the leaflets for the use of group addresses.

18 556
OR
The reading, writing and deleting of individual groups, as well as of all groups over the UIC train bus,
is done through telegrams 11.01 / 11.01A to 11.06 / 11.06A and is specified as follows:

- The management of the groups is done with confirmed E data traffic (see List of abbreviations -
page 216).

- The reading of a group is done with telegrams 11.01 / 11.01A, the reading of all groups is done
with telegrams 11.02 / 11.02A.

- The writing (definition) of a group is done with telegrams 11.03 / 11.03A, the writing of all groups
is done with telegrams 11.04 / 11.04A.

- The cancelling of a special group is done with telegrams 11.05 / 11.05A, the cancelling of all
groups is done by sending telegram 11.06 / 11.06A

5.6 - Functional addressing

5.6.1 - Internal vehicle structures

CEI 61375 is a standard which also deals with the processing of the information to be carried by the
UIC train bus inside the vehicle, thus, before it is transmitted:

- production of the information in the sub-systems,

- collecting the information in the traffic memory of the train bus node after the transmission,

- distribution of the information to the sub-systems,

- processing of the information in the sub-systems.

CEI 61375 provides a vehicle bus MVB (Multifunction Vehicle Bus) corresponding to the UIC train bus
WTB.

Like UIC Leaflet 556, IEC 61375 also assumes that at the same time other vehicle structures can and
are allowed to occur. A clear interface between the train bus nodes and vehicle internal structure must,
therefore, be defined, which in all cases enables the above mentioned tasks to be achieved. This is
done by defining standard function addresses for the data transmission over the train bus.

5.6.2 - Function addresses

Information is exchanged between functions. Functions are carried out by the train bus nodes
themselves or by differently connected sub-systems. All occurring functions are, therefore, given
function addresses that is to say they are numbered in a standard way.

IEC 61375 specifies the following number frames:

- Universal functions (e.g. UIC, underground in general, ...) 0 - 127

- Private functions (e.g. special applications, 128 - 239
individual railways, underground, tramways, ...)

19 556
OR
This leaflet specifies the following function addresses for the UIC international mandatory applications:

01 Cab
02 Train control
03 Traction unit control
04 Traction unit auxiliary operation
05 Drive
06 Brakes
07 Power supply
08 Data radio/radio modem
09 Diagnostics
10 Doors
11 Lighting
12 Public address
13 Heating and air conditioning equipment
14 Passenger information, passenger service
15 Train bus nodes (UIC Mapping Server)
16 Distance/speed measurement
17 Train protection
18 Sanitary equipment
19 Cab display
20 Tilting equipment
21 Train bus nodes (general services)
22-99 Reserves

5.7 - Telegram structures

5.7.1 - General data structures

The information to be transmitted is packed in accordance with the following rules into regular (R) or
event based (E) telegrams and transported over the UIC train bus.

20 556
OR
5.7.2 - R telegrams (regular telegrams)

R telegrams are sent every 100 ms over the UIC train bus. One vehicle always sends to all vehicles.
Each vehicle takes and assesses the information addressed to it, the other information is ignored.

The basic structure as specified in the IEC standard for the UIC train bus WTB is as follows:

"Transport part" "Application part"

Source vehicle Head Individual information place orientated
1 octet 2 octets maximum 126 octets

The UIC train bus uses the following structures:

Type of telegram Application part

R1 Head Coach Information Traction information
(identical to R3) (orders of the leading vehicle)
2 octets 38 octets 88 octets

R2 Head Coach Information Traction Information

(identical to R3) (reports of the vehicles hauled)
2 octets 38 octets 88 octets

R3 Head Coach information

2 octets 38 octets

The types of telegram to be sent out from a vehicle are made up of combinations of the following static
and dynamic vehicle properties:

Property as Type of telegram 1 Type of telegram 2 Type of telegram 3

specified in points
E.1 or E.2 - page 99
38 any 1 1 1 0 1 any
39 any 1 0 1 1 1 any
49 any 1 1 1 0 0 0
50 any 1 0 0 1 1 0
512 1 0 0

21 556
OR
Key (see also points E.1 or E.2 - page 99) :

38 Traction unit with electric drive

39 Traction unit with diesel engine drive
49 Drive of the electric traction unit can be remote-controlled by means of the train bus with
control procedure 1e
50 Drive of the diesel traction unit can be remote-controlled by means of the train bus with
control procedure 1d
512 Vehicle is the leading vehicle (this dynamic property is given by the UIC Mapping Server)

The make up of the 3 types of telegrams as well as the source and destination functions of the position-
orientated information packed in them are given in Appendix B - page 36.

The following general structure applies to the R telegrams and provides for the applications stated in
UIC Leaflet 556, a reserve for the future definition of further international applications as well as for
applications to be used nationally only:

UIC Leaflet 556

Structure range
Octet range Number
Head information 1-2 2
R3-telegram Internationally defined 3 - 30 28
International reserve 31 - 38 8
National reserve 39 + 40 2
R1-telegram Internationally defined 41 - 69 29
International reserve 70 - 84 15
National reserve 85 - 128 44
R2-telegram Internationally defined 41 - 71 31
International reserve 72 - 84 13
National reserve 85 - 128 44

The readability for the individual subscriber vehicle results from the information received in the
telegram header:

- Train bus user (here "UIC");

- Type of telegram (here "R1", "R2" or "R3");

- Version number (= highest version number of the UIC Leaflet 556 which still supports the train bus
subscriber involved);

- Dynamic vehicle properties;

- Validity.

22 556
OR
The static vehicle properties are communicated over the "Inauguration Frame" (see point C.3 -
page 84) at the inauguration.

NB: The version number ensures only the readability of the R telegrams in the international area.
It does not say that the sending train bus subscriber has and supports all the functions
contained in the telegram. These depend much more on the static vehicle properties given
in the inauguration frame (see point C.3).

The use of the national reserves (octet 39 and 40 as well as 85 - 128) is otherwise completely free, if
necessary national regulations shall be observed. International and unused national reserves shall be
set bitwise to "1".

5.7.3 - E Telegrams (event based telegrams)

An E telegram has the structure shown in Table 1 - page 24 and is transmitted once as a result of an
event that triggered it.

There are two procedures for E telegram traffic:

- Bilateral traffic:
The E telegram is transmitted from the sending train bus subscriber to one specific vehicle and for
this purpose addressed with its UIC sequence number.

- Multicast or Broadcast traffic:

The E telegram is transmitted from the sending train bus subscriber at the same time to several
(multicast) or all (broadcast) vehicles. In this case collective addresses (e.g. 66 = all vehicles, 67 =
all coaches, ...) or group addresses are used.

Since E telegrams are only sent once, TCN provides a special procedure for safe transmission.

The computer in the train bus node is informed whether the transmission is successful through reports,
which run in the so-called transport layer (only in bilateral traffic). If this transport acknowledgement is
not received within a certain time, the transmission is repeated up to twice more. If the transmission
cannot be completed successfully even after the third attempt, the transmission is interrupted and the
sending application must be informed.

Each vehicle that receives an E telegram, regardless of whether it is bilateral, multicast or broadcast
traffic, must, after receipt and processing, send an answer telegram to the sending train bus
subscriber. This monitors the receipt at the right time of the answer telegram or telegrams and repeats
these to the sending user. The latter then knows not only that the telegram has been received, but also
how the telegram was processed by the receiver. The answer telegram should be transmitted by using
the reply mechanism of the TCN.

The answer telegram is for this reason produced by the destination function and not from the computer
in the train bus node of the destination vehicle. The answer telegrams are, therefore, without exception
defined in Appendix A - page 35. They can be recognised by the "A" after the running number (e.g.
1.7A is the answer to telegram 1.7). The answer telegrams are also E telegrams. They are
constructed with the same structure as the original telegrams. The processing status must be called
up from octet 9 (see Table 1 : page 24).

23 556
OR
 1. International binding E telegram

Structure part Key code Adress part Telegram code Status Variable content

Octet No 1 2 3 4 5 6 7 8 9 10 11ff

Target vehicle
RU code Target Source Source UIC telegram Status Structure according
Content Reserve (single or ollective Reserve
(UIC) function vehicle function code (or command) to Appendix A - page 35
address)

Data format ENUM8 ENUM8 ENUM8 ENUM8 ENUM8 ENUM8 ENUM8 ENUM8 ENUM8 ENUM8

Codes 00 NN HH NN HH HH HH

05 = veh. 05

24
Examples 00 64 = leading. veh. 10 = door 02 = veh. 02 10 = door 0x1004
67 = all pass. veh.

2. National or bilateral usable E telegram

Structure part Key code Address part Telegram code Status Variable content

Octet No 1 2 3 4 5 6 7 8 9 10 11ff
Table 1 : Structure of the E telegram

Target vehicle
RU code Target Source Source application UIC telegram Status Structure according
Content Reserve (single or collective Reserve
(UIC) function vehicle function code code (or command) to Appendix A - page 35
address)

Data format ENUM8 ENUM8 ENUM8 ENUM8 ENUM8 ENUM8 ENUM8 ENUM8 ENUM8 ENUM8

Codes NNN NN HH NN HH HH HH

80 = DB 05 = veh. 05
Examples 87 = SNCF 64 = leading. veh. 10=door 02=veh. 02 10=door 0X10 0X04
101ff = bilat. 67 = all pass. veh.

556
OR
The following code frames are specified for this:

255 Processing not possible, since the function is not available

254 Processing not possible, since the function is switched off
253 Processing not at present possible, since the function is defective
252 Processing possible later, computer at present overloaded
251 Processing possible later, function is in test mode
200-250 Reserved for information about further processing obstacles
100-199 Reserved for information about further regular types of processing
0-99 Confirmation of the proper receipt and the type of proper processing.
The coding for this is given in Appendix A - page 35.

If no code is shown in Appendix A - page 35 for the regular processing then it should be coded:

1 answer telegram received and duly processed.

Further contents can also be packed in the octets 11 ff of the answer telegram. This is shown in detail
in Appendix A - page 35 as well.

There is no further answer to an answer telegram.

Like R telegram information, E telegrams are also sent through function addresses directly to the
function concerned. However, an E telegram can only be addressed to one function.

The use of the TCN topocounters (see point C.1.3.8 - page 53) for E telegrams is specified as
mandatory, so that if there is a new inauguration in the meantime, long E telegrams, including the
appropriate answer telegrams, can be transmitted correctly.

The obligatory part of the E telegram consists of the octets 1 to 10.

The E telegram header consists of the octets 1 to 8.

The following general rules apply to the production and use of E telegrams:

- The E telegram format shall always be completed on the total number of octets.

- All reserve bits and octets shall be set to "0" if they are not used.

The individual elements of the header of the E telegrams have the following meaning:

- Key code: The key code consists of two octets.

The first contains the RU code concerned.
For the UIC application it should be coded "00".
The second is at present reserved.
- Address part: The address part consists of four octets. The information shown for the
address part is used in order to forward the information to the competent
sub-system and to enable the processing by the sub-system on the basis of
the knowledge of the origin.

25 556
OR
The terms below have the following meaning:

Destination vehicule: UIC address of the destination vehicle or collective or group address (see
Appendix A - page 35, Column 9a).
Destination function: Function by which the information is to be processed (see Appendix A,
Column 14).
Source vehicle: UIC address of the source vehicle (see Appendix A, Column 3).
Source function: Function from which the information was produced (see Appendix A,
Column 13).

The function addresses are the same as for the R telegrams (see point 5.6.2 - page 19):

RU/UIC: The first octet of the key code gives the UIC code of the owning RU of the
information source. It gives the RUs the opportunity of making a national
or bilateral use of the UIC train bus besides the international obligatory
specification.

The code "00" applies for international obligatory information. This and
only this is given in Appendix A.

It is recommended that RUs produce a similar list for national use and to
exchange this, if necessary, with individual (neighbouring) RUs for
possible bilateral use.
UIC telegram code: The 7th and 8th octet in the telegram header define the UIC telegram code,
which consists of 4 hexadecimal figures. For each E telegram given in
Appendix A, Column 13, a separate UIC telegram code should be given,
from which the receiving train bus subscriber, the type of the sub-system
and the type of the processing can be derived on the basis of tables
deposited there. With the telegram code the "most significant octet" is the
first to be transmitted (octet 7 before octet 8).
Application The first octet of the UIC telegram code (7th octet of the E telegram) is
identification: used as the application identification for national/private use of the UIC
train bus. National regulations can be made for this.
Status : In the 9th octet of the E telegrams "Status" different contents (e.g. 1 = ON!,
0 = OFF!) can be packaged corresponding to the definitions in Appendix
A. The coding is not subject to any regulation. If no different contents are
passed on, it should be coded "1".

Longer E telegrams are divided into pieces of suitable length (e.g. 128 bytes).

26 556
OR
6 - Reliability

6.1 - Failure rate

The consistency of the functional ability of the equipment participating in the bus operation over time
is of particular importance for defect-free operation.

6.2 - Error tolerance

If there are errors in traction units and driving trailers

the 1st error that occurs should not result in any lasting effect on the data exchange on the
train bus. Temporary impairment shall not last longer than 1,4 seconds and must
automatically be overcome.

If there are errors in the other vehicles

the maximum result of the first error shall be that a vehicle can no longer be reached over
the train bus. This fact must be known to the vehicle concerned, so that safe conditions
can be brought about in its sub-systems and the leading vehicle and all other vehicles
must be informed.

If the defective/separated vehicle is in the bus line, this should be classified as "defective" and
indicated to the traction unit driver in the leading vehicle.

If the defective/separated vehicle(s) are at the end of the train, this should be immediately and
neutrally indicated to the traction unit driver in the leading vehicle. The traction unit driver then decides
whether it is a planned train shortening or a failure and enters this in the system by corresponding
actions.

If the train has been shortened, the train bus system goes into the inauguration operation. If a defect
has occurred, the bus operation is continued with the remaining vehicles. Attempts are periodically
made to get the lost bus subscriber(s) back on the bus.

6.3 - Transmission reliability in undisturbed operation

6.3.1 - Transmission of regularly recurring information

Because of the regular repetition in the rhythm of the time based transmission priority no special safety
precautions are normally required (R telegrams).

No acknowledgement of the individual pieces of information is given.

For special safety critical information antivalent data capture + data transmission + data evaluation is
recommended on the user level.

27 556
OR
6.3.2 - Transmission of event-based information

The bus shall be designed in such a way that the sender is told in each case whether the information
that has been sent has arrived. It does not have to be told whether it was understood. The
transmission tests shall be continued until it is reported that the E telegram has been received or until
it appears to be successful, in general three times.

If communication is lost, the sending application is informed. The application decides whether there
should be a further repetition of the complete report, e.g. after a suitable stabilisation period.

The processing status is coded in the 9th octet of the answer telegram corresponding to the provisions
in point 5.7.3 - page 23.

28 556
OR
O 7 - Modification procedure

In order to enable the data traffic to be extended in accordance with technical progress and the
requirements of the RUs, the following procedure is laid down for modifications and extensions of the
leaflet that become necessary.

7.1 - Modification competence

The UIC Steering Group "Train bus" is responsible for preparing modifications and additions to the
leaflet.

It will always take care to guarantee the downwards compatibility of the individual leaflet versions and
check to what extent an update of the leaflet is necessitated by other standardising work, especially
in respect of the TCN standard. With the same objective the Control Group follows up the work of the
UIC Committees and supports it by applying the relevant decisions to the UIC train bus.

Modifications to the leaflet can be initiated by

- decisions of other UIC Committees,

- applications from interested RUs or firms and

- the initiative of the UIC Steering Group "train bus".

When it is absolutely necessary to make the UIC train bus conform to the application, it is very
important to make quick modifications. Therefore, authority to take decisions is delegated as follows
depending on the scope of the modifications:

Modified part of the leaflet Modified item Responsibility for

taking decisions
Appendix A - page 35 New or modified E telegrams UIC Steering Group "Train bus"
Appendix A and B - page 36 New or modified R telegrams UIC Working Group
commissioned by the UIC
Steering Group "train bus"
Point C.3 - page 84 and Modification in the UIC Working Group
Appendix E - page 99 inauguration frame commissioned by the UIC
Steering Group "train bus"
Appendix D - page 91 Modifications to PDM UIC Working Group
commissioned by the UIC
Steering Group "train bus"
Other parts or modification items Technical and Research Forum
(FTR)

29 556
OR
7.2 - Modification procedure

Any modification may have serious effects on the data traffic of already existing products and vehicles.
Therefore, in order to maintain an undisturbed operation and the ability to freely couple different
vehicles, it is necessary to insist on two principles:

7.2.1 - Absolute downwards compatibility

Each implementation based on a later version must be able to exchange undistorted data with all
earlier versions.

7.2.2 - Exact documentation of the modification version

The text and each Appendix of UIC Leaflet 556 can be modified separately and independently from
one another, therefore, each part is given a separate version number beginning with "1" and
increasing from modification to modification. All modifications are accurately documented with the
date of the modification advice and modified version number in the "modification certificate" see
Appendix J - page 215.

Advice of modifications is issued as required - up to twice a year - by the Steering Group "Train bus"
and contains the following elements:

1. New version of the appendix;

2. Modified parts of the leaflet in the new form;

3. Documentation of all changes (= comparison old-new) for the modified parts of the leaflet;

4. Date, on which the modifications come into force.

In each vehicle, it must be exactly documented by suitable lettering on the train bus node which
modification condition of the leaflet is fitted, that is to say which version of the leaflet or which version
of the individual leaflet parts is supported. Thus the version number of Appendix J applies as the
complete version of the leaflet. For an implementation, it is sufficient to give this number.

In exceptional cases e.g. with later design modifications, implementations with different modification
conditions of the individual leaflet parts are allowed. Then the supported version numbers of all parts
of the leaflet must be given in matrix form.

The version of points B.1, B.2, B.3 - page 36 and C.3 - page 84 fitted and used for the application are
carried in the telegram traffic.

30 556
OR
7.2.3 - Announcement of the modifications

The leaflet and all modifications can be obtained as hard copy and as electronic file from

Direction Générale de l’UIC

Département Système
16, rue Jean Rey - 75015 Paris

or on the UIC website: [Link]

All UIC member automatically receive all updates to the leaflet.

7.3 - UIC-Steering Group "Train bus"

Members of the UIC Steering Group "Train bus" are selected amongst applicants from interested RUs
and firms which develop or deliver train bus equipment.

The UIC Steering Group chooses amongst its members for two year cycles the people responsible for
the following departments:

Department Area
Chairman Management, basic questions
Points 1 - page 2 to 9 - page 33 and Appendices G -
page 112, H - page 116, and I - page 214
Telegram traffic Appendices A - page 35 and B - page 36
Inauguration procedure Appendices C - page 37 and E - page 99,
UIC-Mapping-Server
Standardisation principles TCN-questions, other committees, PDM,
Appendices D - page 91 and E

31 556
OR
O 8 - Test procedure for train bus nodes (gateways)

8.1 - Homologation

Only type approved train bus nodes may be used.

After having completed conformity testing type approved train bus nodes are listed in Appendix I -
page 214.

8.2 - Homologation procedure

The homologation of the train bus nodes for vehicles that run in international traffic is carried out by
the UIC Steering Group "Train bus" which is the body with experience of the use of the UIC train bus
for the transmission of information in trains. Representatives of all UIC Committees which use the UIC
train bus participate in this Control Group.

The type approval of new train bus nodes is done by conformity testing which checks the conformity
of the inauguration mechanism and the data traffic (R-data and E-data) of the new train bus node
including the use of the UIC Mapping Server with at least one already approved train bus node.

The conformity testing shall be carried out in suitably equipped laboratories e.g. by the RUs or by the
industry.

For each type approval of a new train bus node by the UIC Control Group "Train bus", an application
shall initially be made to the UIC Office in Paris.

The detailed content of the conformity testing is laid down in Appendix H - page 116.

8.3 - Approval of the test laboratory

The test laboratories will be approved by the UIC Steering Group "Train bus". The approval procedure
is yet to be laid down.

32 556
OR
O 9 - Other matters

Addresses

The features of the bus capability (see Glossary - page 218) of vehicles that run in passenger service
are characterised by addresses.

For passenger coaches that can be used on any international service in which the data transmission
for the UIC train bus is done over the remote control and information cable as specified in UIC
Leaflet 558, the marking is done while retaining the train remote control functions for remote control
of the door closing, as well as the central side selective door release as specified in UIC Leaflet 560
over wires 9, 14, 15, 16 and 12 of the cable specified in UIC Leaflet 558, and for remote control of the
lighting as specified in UIC Leaflet 555 over the wires 10, 11 and 12 of the cable specified in UIC
Leaflet 558 according to RIC sheet 10 as follows:

K Sign for coaches with:

- 18 wire remote control and information cable as specified in UIC Leaflet 558
(Cable vehicle as specified in UIC Leaflet 556)
- Remote control of door closing as specified in UIC Leaflet 560
- Remote control of the lighting as specified in UIC Leaflet 555.

L Sign for coaches with:

- 18 wire remote control and information cable as specified in UIC Leaflet 558
(Cable vehicle as specified in UIC Leaflet 556)
- Remote control of door closing and the side selective door release as specified in UIC
Leaflet 560 over the wires 9,14,15,16 and 12 of the cable specified in UIC Leaflet 558
- Remote control of the lighting as specified in UIC Leaflet 555.

M Sign for coaches with:

- 18 wire remote control and information cable as specified in UIC Leaflet 558
- Train bus nodes as specified in UIC Leaflet 556 only capable for train inauguration
- Remote control of door closing as specified in UIC Leaflet 560
- Remote control of lighting as specified in UIC Leaflet 555.

33 556
OR
N Sign for coaches with:

- 18 wire remote control and information cable as specified in UIC Leaflet 558
- Train bus node as specified in UIC Leaflet 556 only capable of train inauguration
- Remote control of door closing and the side selective door release as specified in UIC
Leaflet 560 over wires 9,14,15,16 and 12 of the cable specified in UIC Leaflet 558
- Remote control of the lighting as specified in UIC Leaflet 555.

O Sign for coaches with:

- 18 wire remote control and information cable as specified in UIC Leaflet 558
- Train bus node as specified in UIC Leaflet 556 fully bus compatible
- Remote control of door closing as specified in UIC Leaflet 560
- Remote control of the lighting as specified in UIC Leaflet 555.

P Sign for coaches with:

- 18 wire remote control and information cable as specified in UIC Leaflet 558
- Train bus node as specified in UIC Leaflet 556 fully bus compatible
- Remote control of door closing and the side selective door release as specified in UIC
Leaflet 560 over wires 9, 14, 15, 16 and 12 of the cable specified in UIC Leaflet 558
- Remote control of the lighting as specified in UIC Leaflet 555.

Q Sign for coaches with:

- 18 wire remote control and information cable as specified in UIC Leaflet 558
- Train bus node as specified in UIC Leaflet 556 fully bus compatible
- Remote control of door closing as specified in UIC Leaflet 560
- Remote control of the lighting as specified in UIC Leaflet 555.
- Side selective door release over the train bus as specified in UIC Leaflets 556-0 to
556-3.

If the data transmission on the UIC train bus is done over the cable defined in UIC Leaflet 541-5,
then the markings should be done according to the specifications of this leaflet.

34 556
OR
Appendices

Appendix A - List of information to be transmitted

(Version 002.02, valid from 01.08.2005)

The list of information to be transmitted is to be found on the UIC Website ([Link]

Technical and Research/Products/Catalogue of products technically approved by UIC/train bus.

35 556
OR
Appendices

Appendix B - Composition of the R telegrams

B.1 - Composition of the R1 telegram (Version 002.02, valid from

01.08.2005)

The composition of the R1 telegram is to be found on the UIC-Website ([Link]

Technical and Research/Products/Catalogue of products technically approved by UIC/train bus

B.2 - Composition of the R2 telegram (Version 002.02, valid from

01.08.2005)

The composition of the R2 telegram is to be found on the UIC-Website ([Link]

Technical and Research/Products/Catalogue of products technically approved by UIC/train bus

B.3 - Composition of the R3 telegram (Version 002.02, valid from

01.08.2005)

The composition of the R3 telegram is to be found on the UIC-Website ([Link]

Technical and Research/Products/Catalogue of products technically approved by UIC/train bus

36 556
OR
Appendices

Appendix C - Inauguration and Mapping Server

C.1 - Concept of the train inauguration (Version 002.02, valid from

01.08.2005)

C.1.1 - Foreword

The train inauguration is an important feature of the train bus as specified in the TCN standard. Beside
the train inauguration itself with a view to data transmission as specified by TCN, a UIC train
inauguration is necessary, which considers the actual train composition, this means the vehicles
present in the train with their special properties (see points E.1 and E.2 - page 99). A condition both
for the train inauguration for the purpose of data transmission (TCN inauguration) and for the UIC train
inauguration is that it should be carried out in an acceptable time for the applications, which are
operated over the train bus.

The concept described below considers these requirements, however, by using the application
defined inauguration data of the TCN standard. The algorithm for the UIC inauguration could
consequently be considerably simplified.

C.1.2 - States in the train bus operation

Fig. 1 shows the process and states in connection with the UIC inauguration.

TCN
inauguration

Redundancy switchover UIC inauguration

(cold standby) UIC request (e.g. following a
node late insertion inauguration correction information
composition change distribution)
loss of TCN master
master (mode) change

confirmed no
configuration? Operating
unit

yes
request
UIC operation configuration
in confirmed (NADI)
configuration UIC operation request
in actual configuration
configuration
(NADI)

Fig. 1 - Process and states for train bus traffic in connection with the UIC inauguration

37 556
OR
Appendices

Regarding the data traffic on the train bus the following applies from the point of view of the
Application for the individual states:

State Process data traffic E-telegram traffic

TCN inauguration not possible not possible
UIC inauguration not possible not possible
UIC operation with actual configuration a acc. to UIC acc. to UIC

UIC operation with confirmed configuration acc. to UIC acc. to UIC

a. Scope of the operation allowed with an actual configuration is laid down in the UIC leaflets based on the different applications or
functionalities.

A UIC inauguration is always triggered if a TCN inauguration occurs. Moreover the application has the
possibility of triggering a UIC inauguration. In this case no relays are switched in the train bus nodes
(gateways), and the phase of the naming/unnaming of the TCN nodes is not carried out. The TCN
Topography_Request/Response phase described below is begun directly. The UIC inauguration is
always successfully completed when the distribution of the inaugural information ensured by the TCN
is assessed decentrally on all nodes. If a node fails during the TCN inauguration, then it is not
contained in the configuration. A failure directly after the inauguration phase is the same as a failure
in normal operation.

The result is a NADI representing either an actual configuration on all nodes or a confirmed
configuration on all nodes. If the mapping service cannot calculate either of the two configurations,
e.g. because of the non-UIC conforming vehicles in the train, the NADI determined is not valid (see
also point C.[Link] - page 45, second paragraph).

If there is a valid NADI, the UIC operation is started. The confirmation/correction of the inauguration
result can be carried out by an operating device, which sends the correcting information by means of
message data and implicitly triggers a request for the UIC inauguration.

The model used includes a redundant train bus connection in cold-standby. With cold-standby should
be meant that respectively only one active gateway of a redundant gateway pair takes part in the train
bus traffic. The passive gateway does not take part in the train bus traffic. If there is a redundancy
switch over, the previously passive gateway becomes an active gateway and so triggers a TCN
inauguration. It is, therefore, required that a TCN inauguration should not be prevented during the
journey (inhibit bit is not set in normal operation). A train bus node designed to be redundant must
recognise whether it was started as a result of a redundancy switch over.

From the point of view of the UIC inauguration, a redundancy with hot standby is only allowed if it
satisfies the TCN standard and the inauguration algorithm described here. A model used for hot
standby with a redundant train bus connection is not explicitly described.

38 556
OR
Appendices

C.1.3 - UIC inauguration

C.1.3.1 - Requirements

The UIC inauguration is based on the fact that an inauguration frame to be specified by the application
is sent as TCN Topography_Response per broadcast and received at all other nodes. The TCN
Topography_Request/Response mechanism thereby guarantees the following:

1. All intact nodes have identical information regarding the content of the inauguration frame
exchanged at the end of this sequence.

2. A node which has not been properly through the exchange of topography does not participate in
the train bus traffic without renewed inauguration.

3. TCN-inauguration and associated UIC inauguration last for 32 nodes in the normal case 1 s. If
it is necessary to repeat the inauguration protocol because of errors, the duration of the complete
inauguration is limited to a maximum of 1,4s. The inauguration time is defined as follows: Time
from the first unnaming-request in the TCN inauguration until the completion of the calculation of
the NADI.

NB : In the implementation a suitable time protocol shall be considered e.g. by means of an event
recorder.
Next an assessment process runs at each node, which constructs the NADI on the basis of the
information in the inauguration frame.

It should be guaranteed that all nodes construct identical information in the NADI. This is achieved by
the identical algorithm running on all nodes and that for the construction of the NADI only the identical
results of the TCN Topography_Request/Response phase is processed at all nodes. No node may
use additionally stored data, for this can lead to inconsistent NADIs. In this connection the case that
a node has not run properly through the exchange of topography, is the same as a failure shortly after
the conclusion of the inauguration. If a node does not react any more immediately after the
inauguration, it can only be taken into the system again by a new inauguration or by node reinsertion.

C.1.3.2 - Determination of the leading vehicle in the train

In a train there can never be more than one leading vehicle. This is a global property in relation to the
train. In order to be able to deal sensibly with cases of conflict at the UIC inauguration the property
512 "vehicle is leading vehicle" is only assigned at the end of the UIC inauguration. The sending out
of the R1 telegrams is associated with property 512 "vehicle is leading vehicle".

A vehicle1 can declare the following properties at the beginning of the UIC inauguration:

- Property 510: "Vehicle was leading vehicle" (had in the last inauguration the Property 512 "Vehicle
is leading vehicle")

- Property 511: "Vehicle wants to become leading vehicle"

1. For a vehicle with several train bus nodes, only that train bus node which is assigned to the traction function,
can give these properties.

39 556
OR
Appendices

The following provisions apply:

1. In the determination of the leading vehicle, the only vehicles considered are those which were
detected on the train bus and to which a valid UIC address can be assigned.

2. If, because of an operation, a leading vehicle no longer has the property 511 "Vehicle wants to
become leading vehicle", it has at the same time lost the property 510 "Vehicle was leading
vehicle"1

3. If at the beginning of the UIC inauguration there is a vehicle with the properties 510 "Vehicle was
leading vehicle" and 511 "Vehicle wants to become leading vehicle", then this vehicle receives the
property 512 "Vehicle is leading vehicle" after the UIC inauguration. This property is not assigned
to any other vehicle.

4. If at the beginning of the UIC inauguration, there is no vehicle with the property 510 "Vehicle was
leading vehicle" then it depends on how many vehicles report the property 511:

a. exactly one vehicle: This and only this vehicle receives the property 512 "Vehicle is leading
vehicle" after the UIC inauguration.
b. more than one vehicle or no vehicle: no vehicle receives the property 512 "Vehicle is leading
vehicle" after the UIC inauguration.

5. If at the beginning of the UIC inauguration several vehicles have the property 510 "vehicle was
leading vehicle" (e.g. when trains are coupled), then no vehicle receives the property 512 "Vehicle
is leading vehicle" after the UIC inauguration.

Consequently it can be guaranteed that after a UIC inauguration at the most one vehicle can be the
leading vehicle in the train2. It is the task of the application to assess possible conflict cases regarding
the leading vehicle in the train and to display the corresponding error reports.

C.1.3.3 - Vehicle sequence and recognition of direction

C.[Link] - Algorithms of the UIC address allocation

The following events cause a UIC inauguration:

1. a TCN inauguration (the necessary exchange of inauguration telegrams for the UIC inauguration
takes place during the TCN inauguration);

2. an inauguration request received from a node by means of E telegrams;

3. a request to reset the configuration received from a node by means of E telegrams;

4. a request to distribute a confirmation, a correction or an assignment of vehicle numbers for seat

reservation received and converted from a node by means of multi-cast E telegram to all nodes in
the train;

5. a vehicle gets or loses the property 511 "Vehicle wants to become leading vehicle" or changes the
direction of the request (for trainsets).

1. Consequently, the inconsistent combination of the two properties 510 "Vehicle is the leading vehicle" but
not 511 "Vehicle wants to become leading vehicle" should be ignored by the inauguration.
2. On the basis of these arrangements it is ensured that only one train bus node sends a type 1 telegram. For
protection against extreme errors it should be ensured that should two type 1 telegrams be sent, these are
not assessed by any vehicle.

40 556
OR
Appendices

Independent of the event which triggers a UIC inauguration, the allocation of the UIC addresses
depends on the state in which the train configuration is transferred.

The vehicle with the UIC address 01 is determined for a UIC inauguration according to the following
criteria:

If the result is that no confirmed train configuration is determined, then the rules a) to d) apply,
otherwise the rules a) to c).

a) Leading vehicle at one end:

This vehicle = vehicle 01
b) Leading vehicle within the train:
Vehicle 01 is the end vehicle, which is nearer to the leading vehicle, when counting the number of
intermediate vehicles.
If there is an identical number of vehicles d) applies.
c) No leading vehicle within the train but a traction unit at one end of the train (at the other end,
therefore, none, however possibly one or more within the train):
This vehicle = vehicle 01
d) In all other cases:
Vehicle 01 is at one of the two train ends and thus the TCN sequence tends to correspond to the
UIC sequence a:
Example: 61 62 63 01 02 TCN
01 02 03 04 05 UIC
a. That is to say the "reference direction train" is identical with the "reference direction TCN"

Regarding the differentiation of the rules it should be noted that for rules a) to c) the operating staff
already have, when approaching the train, a certain expectation regarding the UIC address 01,
because of the position of the leading vehicle or because of the position of the traction unit. With rule
d) this is not the case. It should, therefore, be indifferent to the operating staff at which end of the train
address 01 is formed. For orientation in the train, however, the operating equipments should indicate
to the staff the direction in which the address 01 was given.

If the result of the UIC inauguration is a confirmed train configuration, then a check is made according
to rules a) to c) to see whether the sequence must be inverted. At the same time only the two vehicles
which are end vehicles according to the correction or confirmation action are considered as end
vehicles. Their UIC address is, therefore, either 01 or identical with the number of the confirmed
vehicles in the train. Furthermore vehicles with unknown UIC address 001 are not taken into
consideration for the decision whether the order should be inverted (see point C.[Link] - page 52).

1. That is to say an undefined position in the train

41 556
OR
Appendices

C.[Link] - Direction determination forwards, backwards, left and right

A "reference direction train" is laid down for the complete train. This is calculated for each train bus
node from the UIC order established with the UIC inauguration and stored in the NADI. No further data
traffic beyond the UIC inauguration frame is necessary for this.

1) TCN inauguration

At the end of the TCN inauguration each train bus node sends its inauguration frame (see point C.3 -
page 84) to all train bus nodes at the request of the train bus master. In this there is the orientation of
the train bus node relative to the orientation of the train bus master. The latter defines the "reference
direction TCN".

Information route Representation and processing

Serial Data
Type of
No. from Source Target Information type/
Purpose tele- Code/
point E.2 origin Meaning extent Octet Bit
gram value
- page 99 Fct. Veh. Veh. Fct. of the
values
1a 2 13 3 9a 14 10 15 16 16a 17 18 19
505 Report: all veh. all veh. Inaugu- Train bus node "Reference Bitset8 3 7
Orientation ration direction train
relative to frame bus node" is
"reference to "reference
direction direction
TCN" TCN"
the same 1
the inverse 0

As a result of the TCN inauguration each train bus node recognises the reference direction of all other
nodes relative to the "reference direction TCN".

2) UIC inauguration

Since the "reference direction train bus nodes" according to the installation specifications is identical
with the reference direction of the trainset/vehicle (see Fig. 5 - page 58) each train bus node can
calculate the UIC order and consequently the "reference direction train" according to the rules from
point C.[Link] - page 40 using the following algorithm:

Vehicle X = Vehicle 01 ⇒ "Reference direction train" = towards vehicle 01

Vehicle X = Vehicle 01 ⇒ "Reference direction train" = away from vehicle 02

"Reference direction train"

right

forwards backwards

left

42 556
OR
Appendices

3) Assignment of the particular reference direction

Each vehicle determines its orientation relative to the "reference direction train" by the following rules:

1. If the "reference direction TCN" is identical with the "reference direction train" then the orientation
to the "reference direction train" is the same as the orientation of the train bus node relative to the
"reference direction TCN" (= property 505).

2. If the "reference direction TCN" is opposite to the "reference direction train" then the orientation to
the "reference direction train" is inverse to the orientation of the train bus node relative to the
"reference direction TCN" (= property 505).

"Reference direction train" "Reference direction train bus node" "1" • "0"

The train bus nodes convert correspondingly all incoming and outgoing commands and reports, which
contain the terms in Appendix A - page 35 "forwards", "front", "backwards", "back", "left" or "right"
uniformly to the "reference direction train".

The further conversion of the "reference direction train bus nodes" into the "reference direction
vehicle" depends on whether the train bus node controls an individual vehicle or a trainset.

a) Train bus node controls an individual vehicle:

"Reference direction train bus node" = "Reference direction vehicle"
b) Train bus controls a trainset:
"Reference direction train bus node" = "Reference direction trainset"
"Reference direction train bus nodes", "reference direction trainset" and "reference direction
vehicle" are laid down as specified in the regulations for the installation of the train bus nodes
and, therefore, programmed in a fixed way. At the same time in a trainset the "reference direction
trainset" and the reference directions of the individual vehicles do not necessarily have to
correspond.
The further conversion of the "reference direction trainset" into the "reference direction vehicle"
is no longer an item of the train bus functions, it is carried out by other applications, e.g. by an
MVB according to TCN.

Example:

"reference direction train"

train bus

01 02 03 04 05 06 07 08

Trainset

If there are several train bus nodes in one vehicle, then each of these nodes carries out the above
mentioned calculations independently. In order to obtain the same results, it is important that the
"reference direction train bus node" is given in each node of the vehicle in the same way.

43 556
OR
Appendices

C.1.3.4 - Data structure

C.[Link] - Principle of the construction of the inauguration frame

The detailed construction of the inauguration telegram is described in point C.3 - page 84.

Size
Octet/bit No Name
(in bytes)
Information for train bus nodes (= trainsets):
1 UIC identification: 0x1 1
2 UIC inauguration version number 1
3 Orientation and TCN address 1
4 Length of following net data in octets 1
5 UIC code of the operating RU 1
6 UIC code of the owning RU 1
7 National application identification 1
8 National telegram version 1
9 NN > 0: Number of vehicles controlled from this node 1
(1…6)
NN ≤ -2: Number of nodes in this vehicle
10 Status/control bits 1
11 a
UIC address of the vehicle in which the train bus node is located 1
(property 141)
12 Confirmed number of vehicles 1
13...20 Confirmed position of the vehicles which are not reachable over 8
the train bus
21 R telegram version number 1
22...34 Gateway (= trainset) specific properties 20
35...41 Reserve for gateway specific properties 7
42...43 Reserve for national gateway specific properties 2
44 General reserve 1
Information for max. 6 controlled vehicles: (i = 0...5)
45+(i*14)... UIC identification number (ID) b 5
49+(i*14)
50+(i*14)... Vehicle specific properties 6
54+(i*14)
55+(i*14)... Reserve for national vehicle specific properties 1
56+(i*14)... General reserve 1
c
57+(i*14)... Coach number for seat reservation 2
58+(i*14)
a. The octets 11…20 in the inauguration frame of an unknown node are of no significance.
b. For the converting of the 11 significant digits of the UIC vehicle identification number (octet 45 + (i*14)…49 + (i*14)) into binary
format the UIC vehicle identification number should be interpreted as an 11 character decimal figure (example: 008071-40492
gives when converted 00 30 1b fc 8c). The transmission of the binary format takes place first with the "most significant octet" (in
the example "00").
c. The value 0 characterises that no coach number was assigned.

44 556
OR
Appendices

The first 4 bytes stand for particular net data in the ID traffic store; for a maximum of 6 controlled
vehicles per trainset there is consequently a total length of the inauguration frame of:
44 + 14*6 = 128 bytes.

C.[Link] - Use of application specific TCN information

The first two bytes of the inauguration frame contain from the TCN view the node type and the node
version. It is established that the node type is covered with the UIC identification and the node version
with the UIC inauguration frame.

An inauguration is only then successful, if all vehicles report the UIC identification as node type.
Otherwise no valid NADI can be computed (see point C.1.2 - page 37).

Regarding the TCN User Report it is determined, that from the point of view of the UIC application it
is undefined and must not be changed.

C.[Link] - Local structures

The inauguration algorithm requires, beside the data in the inauguration frame, the following local data
structures to control the various states during the inauguration:

- node status,

- confirmed UIC address,

- confirmed number of vehicles,

- confirmed position of the vehicles that cannot be reached over the train bus (gaps).

Moreover as a result of the TCN Topography_Request/Response phase, a table with the data of all
nodes is available. It is designated as a network configuration and contains for each node the TCN
address and a copy of the inauguration frames.

C.[Link] - Composition of the NADI

The NADI consists of a global part as well as a description for individual vehicles. In the global part
there are the following elements:

1. UIC inauguration frame version number,

2. R data version number,

3. NADI status,

4. Topo counter,

5. Number of entries,

6. Position of the vehicles that cannot be reached,

7. Add on information.

45 556
OR
Appendices

The add on information is of the type BITSET8 and has the following meaning:

Bit 0: orientation of the UIC reference direction (direction of view of the vehicle with UIC address 01)
relative to the TCN master, where: 0 = inverse, 1 = the same.
Bit 1: is set at 1, when at least one node was additionally active in a confirmed configuration.
Bit 2: is set at 1, when at least one node has failed in a confirmed configuration.
Bit 3-7: reserve.

The bits 1 and 2 are set to 0 at each changeover from a confirmed configuration to an actual
configuration and vice versa.

Each line in the NADI contains the following elements:

1. TCN address,

2. Number of vehicles controlled,

3. UIC address,

4. Operating RU,

5. Owning RU,

6. National version,

7. Application identification,

8. Trainset properties,

9. UIC-ID,

10. Vehicle number for seat reservation,

11. Vehicle specific properties,

12. Vehicle add on information.

The entry vehicle add on information is of type BITSET8 and has the following significance:

Bit 0: orientation of the vehicle relative to the TCN master, where:

0 = inverse, 1 = same.
Bit 1: orientation of the vehicle relative to the UIC reference direction, where:
0 = inverse, 1 = same
Bit 2: property 512 "Vehicle is leading vehicle" where:
1 = leading, 0 = not leading
Bit 3: property 511 "Vehicle wants to be leading vehicle" was set in theo inauguration frame
Bit 4-7: reserve.

46 556
OR
Appendices

In the NADI various vehicles are represented as follows:

A Vehicles with one gateway

One line.

B Trainsets
One line for each controlled vehicle (own UIC address and own UIC ID); the entries in the
following columns are identical for the controlled vehicles of a trainset:
- TCN address,
- owning RU,
- trainset specific properties,
- operating RU

C Vehicles with several gateways

A line for each gateway, the entries in the following columns are identical for vehicles with several
gateways:
- owning RU,
- UIC address,
- UIC ID
- operating RU

D Vehicles which do not take part in the train bus traffic

A line just for the UIC address (such vehicles were inserted because of a correction).

The number of lines in the table is not restricted by the maximum number of vehicles, since several
lines are necessary for vehicles with several gateways. The NADI contains an identification, which lays
down whether an actual configuration was determined or whether an already confirmed configuration
was found. The vehicles are shown in the NADI in rising order in the reference direction train.

C.1.3.5 - Description of the inauguration algorithm

C.[Link] - General

A train bus node recognises three states locally at the beginning of a UIC inauguration:

1. Configuration unknown;

2. UIC address set;

3. Configuration stored.

The state 2 is adopted only immediately after a correction/confirmation of the inauguration results. It
means that the train bus node has already received its correction information.

Because of its state a train bus node announces various informations during the inauguration. In the
state "configuration unknown" the values of the correction information are undefined. In the other
states these values are valid.

The inauguration frames of all vehicles are distributed and entered in the network configuration
according to the TCN address .

47 556
OR
Appendices

The inauguration algorithm is then carried out distributedly on each train bus node.

The UIC identification (Node_Type) is checked next, regardless of the state of a train bus node. If a
vehicle has no UIC identification the inauguration is not successful.

The R telegram version number is then checked. Regarding the version numbering, it is assumed that
only upward compatible extensions of a version of the leaflet are initially allowed. If different
R telegram versions are reported, the minimum of all reported version numbers is automatically
computed and used as the actual R telegram version number for the data interpretation (see octet 2
of the R telegram).

The further course of the algorithm depends on the state of all train bus nodes involved in the
inauguration. The following state diagram gives an overview of the state change within a train bus
node:

Receiving correction
information

Actual
(unknown) Redundancy switch over UIC address set
configuration or reset configuration
request or not all
nodes in state
"UIC address set"

Redundancy switch over

or reset configuration UIC inauguration and
request or definite all nodes in state "UIC address set"
train lengthening

receiving
correction
UIC inauguration information
after redundancy
switch over Stored
configuration

Fig. 2 - States of a train bus node and its state transitions

48 556
OR
Appendices

C.[Link] - Determining the type of train configuration

In general it must be possible to distinguish at the start of the UIC inauguration whether the result will
be a confirmed train configuration or not. This is decided on the basis of the reset configuration request
and the states of all the train bus nodes involved in the UIC inauguration.

The allocation of the UIC addresses is described in point C.[Link] - page 40. For details regarding
the construction of the NADI see Appendix A - page 35, check telegram, telegram 0.01A.

If the control bit "reset confirmed configuration" is set by a train bus node then the NADI is calculated
as the actual configuration. The train bus node changes to the state "configuration unknown".

If all train bus nodes report the control bit "configuration unknown", then the NADI is computed as the
actual configuration.

If some but not all train bus nodes report the control bit "UIC address set", then the NADI is computed
as the actual configuration. The train bus node changes into the state "configuration unknown".

If all train bus nodes report the control bit "UIC address set", a distinction must be made as to whether
it is a correction or a confirmation. In both cases the train bus node changes into the state
"configuration stored".

If all train bus nodes report the UIC address "00" in the inauguration frame, it is a confirmation. The
computed configuration is then marked as a confirmed configuration. The calculated number of the
vehicle and its own UIC address are stored in the inauguration frame.

Otherwise it is a correction, in which after the consistency check of each train bus node the correction
information is accepted locally.

If the train bus nodes is in the state "configuration stored" and possibly one or more is in "configuration
unknown", then after the consistency check the NADI is marked as "confirmed configuration".

If in the consistency check an error is found in the confirmed train configuration reported in the
inauguration frame, then the NADI is computed as the actual configuration. The train bus node goes
into the state "configuration unknown". This is the case if:

- a definite train lengthening (vehicles have been added) has taken place or

- the "reference direction train" can no longer be calculated or1

- the sequence of the UIC addresses reported in the inauguration frame is not monotonic.

A definite train lengthening is defined as follows:

In a UIC inauguration the number of the vehicles reported in the UIC inauguration is compared with
the number of the confirmed vehicles.

1. The "reference direction train" can accurately be calculated if

- at least two different stored UIC addresses are reported or
- at least one train bus node is in the condition "configuration stored" or "UIC address set" and this node is
a TCN end node, whose UIC address (octet 11 in the inauguration frame) is 01 or equal to the confirmed
number of vehicles.

49 556
OR
Appendices

- If at the front of the train before the first vehicle or/and at the end of the train behind the last vehicle
with "confirmed configuration" more new vehicles are reported, as the number of existing gaps,
then the vehicles added cannot be arranged within the configuration. Then a definite train
lengthening has taken place (coupling a confirmed train with individual vehicles or an unconfirmed
train).

- Vehicles, which between the first vehicle with "confirmed configuration" and the last vehicle with
"confirmed configuration" are recognised by a new UIC inauguration, do not lead to a "definite train
lengthening" that is to say the train sequence remains confirmed.

- If from the vehicles with "confirmed configuration" different numbers of vehicles and/or different
numbers or/and positions of confirmed gaps are reported, then a definite train lengthening has
taken place (coupling of two confirmed trains).

- If the number of the vehicles reported in the UIC inauguration with "confirmed configuration" is
greater than the reported number of vehicles, then a definite train lengthening has occurred
(coupling of two confirmed trains).

C.[Link] - Integration of nodes in the state "configuration unknown" in a confirmed train

configuration

If at least one unconfirmed node in the middle of the train (which was not an end node) was active
during a UIC inauguration and confirmed nodes existed in the train, then by means of the following
formula it is decided whether the unconfirmed vehicles can be included in the confirmed configuration:
N vehicle_gaps ( V 1 ,V 2 ) = N unconfirmed_vehicles ( V 1 ,V 2 ) + N confirmed_vehicle_gaps ( V 1 ,V 2 )

in which:

- V 1 ,V 2 are the active vehicles with confirmed UIC address in front of and behind the vehicles to
be classified,

- N vehicle_gaps ( V 1 ,V 2 ) are the number of vehicles between V 1 and V 2 ,

- N confirmed_vehicle_gaps ( V 1 ,V 2 ) are the number of confirmed gaps between V 1 and V 2 ,

- N unconfirmed_vehicles ( V 1 ,V 2 ) are the number of active vehicles without confirmed UIC address
between V 1 and V 2 .

Example:

1. In a train with four vehicles a gap is corrected between the third and fourth vehicle, so that the train
now has five confirmed addresses. If vehicle 03 now fails triggering an inauguration and becomes
active again, then the following configuration is produced:

UIC address 01 02 unknownt 04 05

TCN address 0x01 0x02 0x03 confirmed gap (0x7F) 0x04
with the above formula we get 2 (02, 05) = 1 (02, 05) + 1 (02, 05), that is to say after the UIC
inauguration the confirmation appears as follows:

UIC address 01 02 03 04 05
TCN address 0x01 0x02 0x03 confirmed gap (0x7F) 0x04

50 556
OR
Appendices

2. In a train with three vehicles, two gaps were corrected between the second and third vehicle so
that the train now has five confirmed addresses. If a node becomes active with two vehicles at this
location, then the following configuration is achieved:

UIC address 01 02 unknown unknown 03 04 05

TCN address 0x01 0x02 0x03 0x03 confirmed confirmed 0x04
gap (0x7F) gap (0x7F)

with the above formula 2 (02, 05) ≠ 2 (02, 05) + 2 (02, 05), that is to say after the UIC inauguration
the configuration will appear as follows:

UIC address 01 02 00 00 03 04 05
TCN address 0x01 0x02 0x03 0x03 confirmed gap confirmed gap 0x04
(0x7F) (0x7F)

3. A train with four vehicles is confirmed. If now vehicles 02 and 03 fail triggering an inauguration and
if one of them again becomes active, then the following configuration is obtained:

UIC- address 01 unknown 02 03 04

TCN address 0x01 0x02 unconfirmed unconfirmed 0x03
gap (0x7F) gap (0x7F)

with the above formula 2 (01, 04) ≠ 1 (01, 04) + 0 (01, 04), that is to say after the UIC inauguration
the configuration will appear as follows:

UIC address 01 00 02 03 04
TCN address 0x01 0x02 unconfirmed unconfirmed 0x03
gap (0x7F) gap (0x7F)

C.[Link] - Integration of nodes after redundancy switch over

A node can also be set into the state "configuration unknown" as a result of a redundancy switch over.
It reports this in its inauguration frame by setting the redundancy bit.

The procedure regarding the redundancy bits is as follows:

1. When initialising the node, the redundancy bit is preset to 0.

2. The redundancy bit is set to 1 if the "redundancy switch over recognition" recognises a
redundancy case.

3. The redundancy bit is then assessed by the inauguration algorithm.

4. The redundancy bit is reset to 0 after each UIC inauguration (for single nodes by a time out).

In addition to the integration conditions for nodes in the state "configuration unknown", a redundant
node, which does not lie in the middle of the train between two nodes in the "configuration stored"
state, is integrated then and only then in a confirmed train configuration, if

- the redundant bit is set to 1,

- the node is in the state "configuration unknown",

51 556
OR
Appendices

- the redundant node can be assigned in analogy to the above formula, that is to say a valid UIC
address can be assigned to it.

C.[Link] - Display of unknown vehicles

A vehicle to which a valid UIC address cannot be assigned is written into the NADI with the UIC
address 00 and its TCN address. They are arranged in the NADI bearing in mind the TCN order
according to "reference direction train" as far as possible to the front. In the global part of the NADI, a
bit is set which indicates that a vehicle was recognised, to which no UIC address could be assigned.
If it is desired that the node again subscribes to the train bus traffic, then a correction must be carried
out.

For a vehicle that was present in the confirmed configuration and is no longer active in the
inauguration, the TCN address is set in the NADI to 0x7F, that is to say the node is marked as no
longer accessible and its UIC address remains valid. Bit 2 is set in the add-on-information of the NADI.

In each case after the inauguration with the respective configuration, the UIC operation is started.

C.1.3.6 - Construction of the NADI from the network configuration

First the correct number of vehicles is determined (expanding of the trainsets, multi-mentions for
vehicles with several gateways). This is important so that with the allocation of UIC addresses the
rules regarding the position of the leading vehicle are correctly observed. Then the UIC addresses are
assigned or accepted.

In the treatment of trainsets the following should be noted:

A trainset always gives the information regarding the checked vehicles in coach direction 1 as
specified in the TCN standard (see Fig 5 - page 9). In the carrying out of the inauguration algorithm
the orientation regarding the TCN masters is then known.

Because of the information regarding UIC address 1, the TCN addresses of all train bus nodes and
the orientation relative to the bus master, the algorithm must now determine the correct arrangement
of UIC addresses and UIC IDs (and consequently vehicle numbers for seat reservation) within
trainsets and write them into the NADI. Moreover for vehicles with several gateways, all necessary
entries are set up in the NADI.

C.1.3.7 - Confirmation/correction of an inauguration result

It is assumed that the correction activity is not time critical.

A correction/confirmation can be carried out by different authorities, e.g.:

- dialogue with the traction unit driver over a control device,

- automatic correction by the vehicle control under inclusion of additional information.

If the inauguration result is marked as "not confirmed", then a confirmation/correction can be carried
out by the application. In this way new vehicles can be put into the train in any position. These can be
cable vehicles or vehicles with defect gateways. The corrected configuration (the confirmation or
correction telegram) for this is sent by multicast over the gateway of the TCN master1.

1. This protects the data consistency with parallel correction action.

52 556
OR
Appendices

On receipt of a confirmation telegram, each node in the inauguration frame sets the control bit "UIC
address set" and initialises in the inauguration frame its UIC address. After distribution of the telegram
to all train bus nodes, the gateway of the TCN master initiates a UIC inauguration. The actual train
configuration determined by the UIC inauguration is accepted by each gateway as the confirmed
configuration.

On receipt of a correction telegram, each gateway calculates its own UIC address taking into
consideration the vehicles inserted. Gaps at UIC address n are respectively coded by a 1 in bit position
n-1. If all train bus nodes have received this correction E-telegram, the gateway of the TCN master
initiates a UIC inauguration.

The confirming authority can check after the completion of this inauguration whether the confirmation
or correction was carried out successfully. If the inauguration result is marked as "confirmed
configuration", then the procedure was completed successfully. If the inauguration result is an actual
configuration, the confirmation/correction could not be carried out and the procedure can be repeated.

C.1.3.8 - Versioning

It is not proposed that there should be a versioning of the inauguration result. Since the TCN
topocounter is always changed when a UIC inauguration is triggered, the message data traffic to the
interfaces to the train bus is correspondingly monitored and rejected if there are discrepancies in the
topocounter.

C.1.3.9 - Interfaces to the application

Each application must be able to carry out the following actions:

- inform its own vehicle properties to the Mapping-Server,

- trigger a UIC inauguration,

- place a reset configuration request,

- send correction information to TCN master.

After the inauguration the application receives access to the following data within the node:

- NADI (e.g. property 512 "vehicle is leading vehicle" configuration result),

- Mapping Server status,

- train topography.

This interface is described in Appendix A - page 35 telegram groups 0 and 15.

After completion of the UIC inauguration the application gets access to the NADI. The access
functions are described in point C.2 - page 55.

53 556
OR
Appendices

C.1.3.10 - Restrictions

Regarding the number of train bus nodes there are no restrictions on the basis of the inauguration
algorithm, which are not stipulated by the TCN standard anyway.

On the basis of the design of the inauguration frame a gateway in a trainset can process information
for a maximum of 6 controlled vehicles. The maximum number of vehicles in the train is 22.

Record of updates

Version Date Change Reason for the change

002.01 01.11.2004 Change of the layout according to M1 New layout based on UIC guide
M1
Adoption of a history of updates Increasing the usability
Adoption of a revision number Enhancement and redesign of the
versioning
002.02 01.08.2005 Change in the layout
UIC requirement
Renumbering of the Appendices

54 556
OR
Appendices

C.2 - UIC Mapping Server - Specification (Version 002.02, valid from

01.08.2005)

C.2.1 - Summary

The TCN gateway as it has been defined in the TCN standard has mainly to perform two tasks: first,
to "marshall" process data from the MVB to the WTB and vice versa (Process Data Marshalling), and
second, to route message data from and towards the WTB. All this is performed by the TCN protocol
stack, extended by Process Data Marshalling module.

As these are basic network functions which allow full communication ability all over the network, the
addressing capabilities are rudimentary (just speaking about WTB nodes and MVB functions) and the
capabilities to have more information about the environment the TCN is embedded in are not
subjected. Furthermore, the pure TCN gateway just provides information about the TCN network, but
doesn´t consider parts of the environment that are not reachable via TCN. This gap is filled by UIC
Leaflet 556, which defines a user profile of the TCN especially suited for UIC applications. This user
profile defines all signals that are to be transmitted over the WTB (both process data signals and
messages) and it defines an enhanced addressing scheme comprising addressing of physical
vehicles and vehicle groups. It also provides additional information about the system environment,
thus describing the whole train composition rather than only the communication network.

To cope with these additional, UIC specific, requirements a specialized software component, the "UIC
Mapping Server" (see Bibliography - page 220), provides the user with all the information that is
needed to use the enhanced addressing schemes as defined in UIC Leaflet 556. For this purpose, all
necessary information like vehicle descriptions and train composition, is collected during the
inauguration phase and stored in a database ("node address and attribute directory", NADI). Each
WTB node holds an identical copy of that database. Information, which is not available at the time of
inauguration like for instance group memberships, can be added at any time to that database (this can
be done for instance by using a MMI display).

The UIC Mapping Server is a supplement of the TCN protocol stack for UIC applications. A TCN
gateway enhanced by the capabilities of a UIC Mapping Server will be called a UIC gateway.

The present point describes the basic functions of the UIC Mapping Server in a more general way (like
a tutorial) and describes the individual components the UIC Mapping Server consists of. In addition, it
defines basic design principles of the UIC Mapping Server.

55 556
OR
Appendices

C.2.2 - Introduction

The relationship between the TCN standard on the one hand and the application of the TCN by UIC
on the other hand is depicted in Fig. 3. UIC Leaflet 556 describes all communication related issues
based on the TCN services for process data and message data transfer. It is supplemented by a
number of additional leaflets that detail the user profile of specific functions.

User

Function Function Function Function

Diagnosis traction brakes door control
UIC leaflet 557 UIC leaflet 6XY UIC leaflet 54X UIC leaflets
560/660

UIC Application
UIC Leaflet 556

(Process data) (Message data)

TCN WTB Standard

Fig. 3 - Relation between the TCN standard and its application by the UIC

As this UIC mapping server software will be an integral part of a UIC comformable TCN gateway ("UIC
gateway") the development must take into consideration the whole gateway software structure and
its interrelationships when specifying the UIC Mapping Server software.

56 556
OR
Appendices

The UIC Gateway is generally used for the connection of vehicle control systems, either distributed or
not, to the WTB train bus. The gateway performs the task of data routing between the train bus and
the subordinated vehicle bus. The UIC gateway can be seen as an ordinary TCN gateway customized
for the special needs of UIC conformable applications. The compliancy with UIC requirements, that
are defined in UIC Leaflet 556, is one of the main prerequisites the UIC gateway is faced with.

The terms "message" or "message data" and "E telegram" are used as synonyms in all of point C.2.
"Message" is the standard expression used in the TCN Standard and is therefore used in texts relating
more to the TCN/UIC relationship. "E telegram" is the corresponding term used in UIC Leaflet 556.

C.2.3 - UIC Mapping - Introduction

Figures 4 and 5 - page 58 illustrate the diversity an application programmer of typical train subsystem
software components like door function, traction control etc. has to deal with.

Figure 4 shows the TCN view of a train, which shows only TCN network with its WTB nodes and MVB
stations. The relation to the real train consisting of vehicles of different kinds is not obvious, thus the
application programmer is "blind" when he is confronted with tasks that are vehicle related. Even more,
the WTB addressing scheme is dynamic, it may change from inauguration to inauguration. Hence,
addressing of vehicles may become a mess. If for instance a function in a remote vehicle shall be
activated by messages, one has to ensure that between the time when the message was sent and the
time when it was received no inauguration was made which altered the node addresses. Of course,
there are mechanisms in the TCN protocol stack that prohibit malfunctions, like for instance the
checking of the topography counter. But all this is not very practical.

TCN address

01 63

GW GW
MVB

door brake Air trac- door brake Air

cond. tion cond.

300797-4

Fig. 4 - TCN view of a train

Since a "TCN view" is not sufficient, UIC defined in its leaflet 556 a "user view" of a train
communication network. In this user view, only vehicles are considered and functions within that
vehicles. The internal structure of a vehicle is invisible and, even more, irrelevant. For vehicle
addressing four possibilities are defined:

1. range number ("UIC address"),

2. vehicle number for seat reservation,

57 556
OR
Appendices

3. vehicle identification number (unique number for UIC vehicles),

4. group (predefined and user defined).

Functions within the vehicles are simply identified through their function number.

UIC address

1 2 3
Train bus

GW 32 33 GW 35

door air Trac- air

Brake cond. tion door Brake cond.
101-001-6 508071-40635-1 508071-40492-4

300797-3
Functions
Vehicle number for UIC identification
seat reservation number

Fig. 5 - UIC view of a train

Concerning the ISO OSI 7-layer model, which defines the 7 layers of communication, the UIC Mapping
Server must be part of layer 7 (application layer), although it is somehow between the TCN application
interface (which is also defined in layer 7) and the application itself.

A TCN gateway enhanced by these capabilities of a UIC Mapping Server will be called a UIC gateway.

The services offered by the UIC gateway can be devided into two categories:

1. system services, which are autonomously performed and are mainly responsible for establishing
a running network;

2. user services, which allow a remote or local user to control the communication.

These services are described in more details in point C.2.4 - page 59. The related user interface is
defined in point C.2.5 - page 65.

The basic software structure of the UIC Mapping Server is described in point C.2.6 - page 67. Because
the UIC Mapping Server cannot be considered independently from other parts of the UIC gateway,
point C.2.7 - page 79 contains a brief description of those parts.

58 556
OR
Appendices

C.2.4 - UIC Mapping services

This point describes the services that are offered by a UIC gateway in general and the UIC Mapping
Server in particular.

C.2.4.1 - Definitions

Two kinds of services exist within the UIC gateway. Some of these services are performed
autonomously by the gateway once the gateway is started up. They have to be preconfigured on the
gateway and are called "gateway system services".

Example

Once on, the gateway automatically starts as a weak master, performs TCN and UIC inauguration and
marshals process data.

The gateway also acts as a service provider and offers "gateway user services" which can be used
by remote users. These services are typically used to retrieve state information, topography
information or to submit a multicast.

C.2.4.2 - Gateway system services

The following table lists all the services the UIC gateway has to perform autonomously. To do this, the
gateway needs no interaction with the user, it must only be preconfigured accordingly.

59 556
OR
Appendices

Table 1 : System services

Object Service Description

TCN tcn_inauguration TCN inauguration procedure as defined in
the TCN standard, part 4.
process_data Process data transmission over MVB and
WTB as defined in the TCN standard, parts 2
and 4.
message_data Message data transmission including routing
of message data between WTB, vehicle bus
(e.g. MVB) and gateway local as defined in
TCN standard, part 2.
network_management Agent for network management services as
defined in the TCN standard, part 5.
PDM process_data_marshalling Marshalling of process data between WTB
and vehicle bus (e.g. MVB) as defined in UIC
Leaflet 556.
UMS wtb_ configuration_and _control Preconfiguring and starting the WTB link
layer according to UIC Leaflet 556 (weak
master).
uic_inauguration Sending and receiving inauguration data,
calculating the valid NADI by applying the
algorithm defined in point C.1 - page 37 and
storing the NADI in the NADI database.
correction_train_inauguration Reception of correction info and distribution
to all other WTB nodes.
nadi_control Building up and maintaining the NADI.
group_definition Reception of new group list entries and
storing it in the NADI database. Handling of
groups.
redundancy_handling Handling of a redundant gateway.

60 556
OR
Appendices

C.2.4.3 - Gateway user services

In addition to the gateway system services the UIC gateway provides the following user services:

Table 2 : User services

Object Service Access Description
UMS change_omode local Change operational mode of the WTB node
either to PASSIVE, SLAVE, WEAK or
STRONG.
inauguration_control global Allow or inhibit inauguration.
sleep global Request or cancel the request to enter sleep
mode.
inauguration_enforce global Enforce a new UIC inauguration (WTB
topography exchange).
read_uwtm_state global Read status information from the WTB node.
read_uwtm_topo local Read topography information from the WTB
node.
write_res_nr global Set the vehicle numbers for seat reservation.
write_correction global Write correction information and update the
NADI accordingly.
leading local Request or reset the request of leadership.
read_nadi global Read the actual valid NADI version.
write_group global Store a group in the NADI.
write_group_all global Store a new group list.
read_group global Read the group members of a group.
read_group_list global Read a list of all defined groups.
delete_group global Delete a group.
delete_group_all global Delete all groups.
mutlicast_create global Request a multicast transmission.

global: access via WTB or MVB

local: access via MVB

61 556
OR
Appendices

C.2.4.4 - User service usage

User services are called up by message data, that means a service is requested by sending a
call_message to the UMS_Function and the service result is delivered in the corresponding
reply_message.

Hence the gateway operates as a server reacting only on requests from a remote user (Fig. 6)1.

Example:

A MVB device wants to know about the newest version of the NADI. It sends a "read_nadi" service
call message to the gateway and gets the new NADI in the reply.

It is invisible from the outside of the gateway which software instance of the gateway UMS finally does
the job. The remote user sees only the "UMS_Function" he has to address.

By convention, the UMS_Function has the function number 15.

event notification
(optional)

service request UIC

USER
PROCESS GATEWAY

service reply

040897-1

Fig. 6 - Gateway service access paradigm

C.2.4.5 - Process variables

This point describes an interface of the UIC Mapping Server to the vehicle bus. This is an example
how it may be realized. However, its description is not normative as the UIC Leaflet 556 makes no
normative prescriptions about the vehicle bus.

The choice to run the UMS as a pure server for user services has one major impact on the system
design: by default, there is no mechanism for event notification, that informs the user that something
happened.

1. The restriction to run the gateway as a server only is motivated by the avoidance of complex and
troublesome communication relations among the gateway itself and between gateway and user processes.
Imagine for instance, the gateway distributes the new NADI version after an inauguration autonomously to
its subordinated vehicle bus stations. Then it has to have the knowledge about all connected vehicle bus
stations, which means to have a station list preconfigured. Each time there is a change in vehicle bus
configuration this list has to be updated.

62 556
OR
Appendices

To avoid a burdensome polling of the UMS state to get informatons about new events, a few process
variables are defined (see Tables 3 and 4 - page 64) which can be used to signal a change of some
important status information on the vehicle bus. Each vehicle bus station interested in event
notification has to cyclically poll these process variables. Signalling status changes over the WTB is
not supported1.

C.[Link] - Exported PVs

These PVs should be exported to the local vehicle bus in order to signal important events.

Table 3 : Process variables exported by the USM

PV name Type Values Remarks
UIC_PV_CONFLICT BOOLEAN1 UWTM_NOCONFLICT = 0 Indicates a strong master
UWTM_CONFLICT = 1 conflict.
UIC_PV_OPMODE ENUM4 UWTM_SLAVE = 0 Indicates current
UWTM_WEAK_MASTER = 1 operational mode.
UWTM_STRONG = 2
UWTM_PASSIVE = 3
UIC_PV_STATE ENUM4 UWTM_IDLE = 1 Indicates the current
UWTM_PASSIVE = 4 UWTM state.
UWTM_REGULAR = 2
UWTM_RESTRICTED = 3
UWTM_SINGLE = 5
UIC_PV_LEADING BOOLEAN1 UWTM_NOT_LEADING = 0 Indicates whether vehicle
UWTM_LEADING = 1 is leading or not.
UIC_PV_TOPO_ UNSIGNED8 0..63 Actual topo count
COUNT (0 = invalid).
UIC_PV_NUMBER_ UNSIGNED8 1..63 Number of vehicles.
VEHICLES
UIC_PV_ ANTIVALENT2 UWTM_INVERSE = 0 Orientation with respect to
ORIENTATION UWTM_NOT_INVERSE = 1 the TCN.

1. But of course other mechanisms exist. If for instance a remote user is not informed about a NADI change
and wants to send a message based on the old NADI address information, it will get an error indication from
the local gateway which indicates a mismatch of the topo counter. Hence the user knows that something
must be changed and can ask for new NADI address information (see also the description of the UIC
Mapping Server Remote Interface).

63 556
OR
Appendices

C.[Link] - Imported PVs

The following PVs can be imported by the UMS allowing a rudimentary WTB control via process
variables (This for instance can be important for vehicle bus devices that are not capable to send
message data).

Table 4 : Process variables optionally imported by the UMS

PV name Type Values Remarks
UIC_PV_OPMODE_ ENUM4 UWTM_PASSIVE = 3 Select operational mode.
SELECT UWTM_SLAVE = 0
UWTM_WEAK = 1
UWTM_STRONG = 2
UIC_PV_LEADING_ BOOLEAN1 UWTM_NOT_LEADING = 0 Request train leadership.
REQUEST UWTM_LEADING = 1
UIC_PV_LEADING_ BOOLEAN1 UWTM_DIR1 = 0 Indicates direction of the
DIRECT UWTM_DIR2 = 1 leading vehicle in the case of
a trainset with two driver´s
cabs.
UIC_PV_SLEEP BOOLEAN1 UWTM_NOSLEEP = 0 UWTM_NOSLEEP means
UWTM_SLEEP = 1 no sleep request or, if alrea-
dy requested, cancelling the
request.
UIC_PV_INAUG BOOLEAN1 UWTM_ALLOWED = 0 Allow/inhibit TCN
UWTM_INHIBITED = 1 inauguration.

Restriction:

The UMS supports only the PV import from one vehicle bus source

64 556
OR
Appendices

C.2.5 - UIC Mapping Server - User interface

As already mentioned in the previous section all user services are callable by the means of TCN
messages. This chapter gives an overview of the messages that shall be used for this purpose.

C.2.5.1 - Message format

All user services are invoked by message data calls requesting a specific service, and the result is
returned with the reply. The format of the telegrams transfered over the WTB follows the format
specified in UIC Leaflet 556:

Octet

0 Owner UIC application code

1 Reserved always 0

2 Destination vehicle range of group number

3 Destination function Function number according to UIC Leaflet 556

4 Source vehicle range number

5 Source function function number according to UIC Leaflet 556

6 Code (MSO) message code (most significant octet)

7 Code (LSO) message code (least significant octet)

8 Status (command) Status or command (message type dependent)

9 Reserved always 0

10 dependent on the message type

Message body

Fig. 7 - E telegram header

65 556
OR
Appendices

C.2.5.2 - UMS Messages - Summary

The following table lists all the user service telegrams that can be sent to the UIC gateway. From the
gateway point of view it doesn´t matter whether these telegrams originate from the local vehicle (via
MVB or local) or another vehicle (via WTB). But not all of the telegrams are allowed to be sent between
vehicles (see below).

Table 5 : UIC Mapping Server Telegrams

Service message Code Direction Access rights Description
local test regular
UIC_FC_READ_NADI 0x0001 Aufruf X request to read the complete NADI
UIC_FR_READ_NADI 0x0A01 Antwort X copy of the currently valid NADI
UIC_FC_READ_UWTM_ 0x0022 Aufruf X request for reading the UWTM state
STATE
UIC_FR_READ_UWTM_ 0x0A22 Antwort X UWTM state
STATE
UIC_FC_CHANGE_OMODE 0x0003 Aufruf X command to change the operational mode
of the gateway
UIC_FR_CHANGE_OMODE 0x0A03 Antwort X status
UIC_FC_READ_UWTM_ 0x0004 Aufruf X request to read the TCN topography
TOPOGRAPHY
UIC_FR_READ_UWTM_ 0x0A04 Antwort X TCN topography
TOPOGRAPHY
UIC_FC_READ_GROUP 0xB001 Aufruf X request to read the members of a group
UIC_FR_READ_GROUP 0xBA01 Antwort X members of a group
UIC_FC_READ_GROUP_ 0xB002 Aufruf X request to read a list of all defined groups
LIST
UIC_FR_READ_GROUP_ 0xBA02 Antwort X status
LIST
UIC_FC_WRITE_GROUP 0xB003 Aufruf X request to write the members of a group
UIC_FR_WRITE_GROUP 0xBA03 Antwort X status
UIC_FC_WRITE_GROUP_ 0xB004 Aufruf X request to write a list of groups
ALL
UIC_FR_WRITE_GROUP_ 0xBA04 Antwort X status
ALL
UIC_FC_DELETE_GROUP 0xB005 Aufruf X request to delete a group
UIC_FR_DELETE_GROUP 0xBA05 Antwort X status
UIC_FC_DELETE_GROUP 0xB006 Aufruf X request to delete all groups
_ALL
UIC_FR_DELETE_GROUP 0xBA06 Antwort X status
_ALL
UIC_FC_DEL_CONFIG 0xF001 Aufruf X request to delete the confirmed
configuration
UIC_FR_DEL_CONFIG 0xFA01 Antwort X status
UIC_FC_WRITE_ 0xF002 Aufruf X request to write correction information
CORRECTION (remark: the telegram causes implicitely a
UIC inauguration)

66 556
OR
Appendices

Table 5 : UIC Mapping Server Telegrams

UIC_FR_WRITE_ 0xFA02 Antwort X status
CORRECTION
UIC_FC_WRITE_RES_NR 0xF003 Aufruf X request to write the vehicle numbers for
seat reservation (remark: the telegram
causes implicitely a UIC inauguration)
UIC_FR_WRITE_RES_NR 0xFA03 Antwort X status
UIC_FC_SLEEP 0xF004 Aufruf X command to set or cancel sleep request
UIC_FR_SLEEP 0xFA04 Antwort X status
UIC_FC_INAUGURATION_ 0xF005 Aufruf X command to inhibit or allow inauguration
CONTROL
UIC_FR_INAUGURATION_ 0xFA05 Antwort X status
CONTROL
UIC_FC_INAUGURATION_ 0xF006 Aufruf X command to enforce a new inauguration
ENFORCE
UIC_FR_INAUGURATION_ 0xFA06 Antwort X status
ENFORCE
UIC_FC_MULTICAST_ 0xF007 Aufruf X request the exchange of a multicast
CREATE message
UIC_FR_MULTICAST_ 0xFA07 Antwort X status
CREATE
UIC_FC_LEADING 0x00F0 Aufruf X command to set or reset the leading
request bit
UIC_FR_LEADING 0x0AF0 Antwort X status
UIC_FC_CONVERT_UIC_ 0x00F1 Aufruf X request to convert a UIC address to TCN
TCN address
UIC_FC_CONVERT_UIC_ 0x0AF1 Antwort X TCN address(es)
TCN

Access rights:
local: the telegram is not allowed to be sent on WTB.
test: the telegram can be sent on WTB only for test purpose
(e.g. conformance test)
regular: the telegram can be sent on WTB

The specification of the regular and test telegrams is given in Apendix A - page 35.

Local telegrams are defined in point C.2.8 - page 82.

C.2.6 - Software

NB : The implementation of the UIC Mapping Server may deviate from the description given
hereinafter in respect of the naming conventions of internal functions and the internal
processing, like for instance the interfaces between the MS components.

C.2.6.1 - General UIC Gateway software structure

The UIC Mapping Server software can not be considered isolated from any other software component
on the UIC gateway. Therefore it is necessary to mention all that components beside the UIC Mapping
Server that build up a UIC gateway.

67 556
OR
Appendices

The UIC Gateway consists of the following major components:

- TCN Protocol Stack consisting of WTB Link Layer, MVB Link Layer (optionally, or another vehicle
bus interface), Real Time Protocols (with modules "messenger" and "RTP PD interface" ) and
Network Management Agent (NMA).

- Process Data Marshalling for process data import and export.

- UIC Mapping Server with the subcomponents UIC Train Bus Configurator, UIC NADI & Group
Server, UIC Agent, UIC WTB Manager and UIC Intelligent Multicast Server.

- Node Supervisor with the Node Supervisor Data Base.

- Realtime Operating System with the PIL interface.

Besides the UIC Mapping Server which acts as the agent for incoming user service requests, there
might be a corresponding managing process situated on MVB stations which allows to submit user
service requests to the gateway. This managing process is called the UIC Mapping Server Remote
Interface (UMSI).

The following points describe the individual components of the UIC mapping server.

NS
Data-
Node base
Supervisor
(proprietary) TrafficStores
MVB
UIC Mapping Server
resume/ N
suspend UIC- NADI & A
Messages Agent Group
- Group classification Server D
Im-
configuration

configuration

Operating system
- NADI access functions I Process Data port
- Display Dialog for correction info
- WTB control Marshalling
ex- P
Intellig. NADI write (PDM) port
MC - distribution of I
Server correction info
- NADI access Train Bus MVB
NMA - WTB control L
Configurator
WTB control
Manager PDM control
(Start/Stop)
Func
Dir RTP PD interface
MESSENGER
ID interface PD
StaDi traffic
store
ID - TS
MVB

LMI BMI IDI LPI

WTB LINK LAYER

Fig. 8 - UIC gateway software structure (data flow)

68 556
OR
Appendices

C.2.6.2 - Basic Design Principles

C.[Link] - E-telegram handling

As already outlined, the UMS offers its user services by the means of E telegrams. A service is
requested by sending the corresponding E telegram to the UMS, and the UMS returns the result in the
related answer E telegram. For sending and receiving E telegrams the message call/reply mechanism
of the TCN RTPs shall be used.

To manage messages one has to consider two aspects: first, the buffer management and second, the
message conversion from a WTB byte (or bit-) stream to a high level language data structure suited
to the processing of the content of the message. The conversion must take into consideration the data
presentation of the processing unit (e.g. little endian or big endian format or alignment) compared to
the presentation of a message on the WTB (big endian, byte stream). For message conversion, each
function provider of the UMS incorporates a "Message Converter". Concerning call_messages, this
converter inputs the message byte stream and outputs a corresponding data structure. For
Reply_Messages, the procedure is reversed.

In detail, the handling of messages shall be performed as follows :

Upon reception of the first message data frame (which is the Call_Request frame that contains the
overall length of the message), the RTPs will allocate the buffer for that Call_Message1. A pointer to
the message buffer is passed to the UIC Agent ("am_receive_confirm"), which then calls the
corresponding service provider ("<mod>_request")2 for processing the Call_Message and generating
the Reply_Message. The message converter of the service provider first allocates a buffer for the data
structure, converts the message and passes a pointer to the data structure to the service provider
function. This function returns a pointer to the reply message data structure. The message converter
then allocates the buffer for the Reply_Message byte stream, converts the message and returns to the
RTPs which thereafter start sending the Reply_Message.

The correct handling of message processing especially with respect to the buffer management and
conversion are depicted in Fig. 9 - page 70.

1. The am_receive_request function of the RTPs message application interface has to be called with a
NULL-pointer for the Call_Message so that the RTPs are responsible for buffer allocation
2. <mod> to be replaced by UWTM, UTBC, UNGS and UIMCS.

69 556
OR
Appendices

Service provider
WTB RTP UAGT Message Converter Service Provider
am_receive_request()
frame
Allocate buffer for
frame a
bytestream call_message
frame
am_receive_confirm()
incoming xxx_request()
call_message allocate buffer for
b
structure call_message
convert bytestream
to structure
xxx_local_request() Allocate buffer for
structure
c reply_message
process
function
return (xxx_local_request)

b
free buffer of structure
call_message
d allocate buffer for byte-
stream reply_message

convert structure
to bytestream

c free buffer of
structure
return (REPLY_FREE)
reply_message
outgoing return (xxx_request)
reply_message am_reply_request()
frame am_buffer_free()
frame
a free buffer of bytestream
frame
call_message
frame
am_reply_confirm()
REPLY_FREE

d free buffer of Bytestream

reply_message

160 198-2
= free memory
= telegram convention
= allocate memory

Fig. 9 - Message handling

The procedure of message conversion highly depends on the used hardware platform and therefore
must be tailored while porting the software to a specific hardware.

In the minimal version (hardware supports big endian format and natural data aligment1 ) the message
converter just outputs the input pointer without any processing (just type casting). In this case, there
is no extra buffer allocation for the data structure necessary

1. Natural alignment of data types means, to align 16-bit data types to an address divisible by 2, 32-bit types
to an address divisible by 4 and so on.

70 556
OR
Appendices

C.[Link] - Correction and reservation handling

The procedure for correcting the inauguration result and submitting seat reservation shall be handled
as follows:

1. The display sends a multicast_create message enveloping the corresponding E-telegram (either
UIC_FC_WRITE_CORRECTION or UIC_FC_WRITE_RES_NR) to the gateway with TCN
address 01 (TCN master)1.

2. The UIMCS of the TCN master then first distributes the correction or reservation telegrams to all
other gateways. Thereafter, a new UIC inauguration will be triggered automatically, resulting in a
new NADI version.

C.[Link] - Single nodes

Some particularities have to be observed with single nodes. A single node is a WTB node that is not
connected to any other WTB node, thus there is no data transmission via WTB. But devices inside the
vehicle, or vehicles within a trainset, need to have a valid NADI that holds the vehicle or trainset related
information. Therefrom the following requirements result:

- even in the case of a single node there must be a valid NADI;

- from an application point of view, the single node gateway is in regular operation.

A gateway becomes a single node if it does not succeed in inaugurating other nodes or beeing
inaugurated by another node within a time of 5 seconds.

C.[Link] - Group information handling

The UIC Mapping Server incorporates a group data base that is used to store user defined groups.
The UIC Mapping Server provides services for reading, writing and deleting groups.

The handling of groups like the procedure of group definition or the adjustment in case of train coupling
is not part of the UIC Mapping Server. This shall be done by a seperated Group Server.

C.2.6.3 - UIC Mapping Server Interfaces

The UMS is embedded in the UIC gateway firmware and such interfaces with several other
components. There are mainly four external interfaces:

TCN Protocol stack This interface is defined in the TCN standard and comprises the RTP
interface (TCN part 2), the WTB interface (TCN part 4) and the MVB
interface (TCN part 3).
Process Data Marshalling This interface comprises functions for PDM control and PV read and
write access. Has to be defined with the PDM.

1. The reason for this is to put concurrent requests from different displays into sequence.

71 556
OR
Appendices

Node Supervisor The NSDB holds all the configuration data that are needed by the
UMS. Thus the UMS defines several functions to be called by the node
supervisor.
Operating System Towards the OS an abstract interface has been defined which is also
used by the TCN protocol stack. This interface is called the PIL
(Processor Interface Library).

Apart from the external interfaces there are also internal interfaces between the different
subcomponents of the UMS. These interfaces are defined with the subcomponent specifications. For
conveniance, Fig. 10 gives an overview of these internal function interfaces.

ungs_
request()
E- UAGT E-Telegr.
UNGS
Telegr.

ungs_write_
nadi()
uimcs_request()
PDM

UIMCS UMS
E-Telegr. E-Telegr.
PDM
pdm_control ()
Adapter
E-Telegr.
from extern

uwtm_request() utbc_request()
uwtm_
configure() utbc_build_nadi()

uwtm_sync() x y
utbc_set_leading_req()
UWTM UTBC
y provides a
utbc_red_indicate() function to be
called by x

am.. interface functions Is_t_..interface functions li_t_..interface functions

Application Supervisory
Message Inauguration Data
interface Interface
interface
RTP WTB Link Layer
160198-1

Fig. 10 - Functional interfaces

72 556
OR
Appendices

C.2.6.4 - Description of UIC Mapping Server components

This point gives a rough definition of the several components the UIC Mapping Server is composed of.

C.[Link] - UIC Agent

Function

The UIC Agent serves as the general UMS replier for all exchanged UIC_Messages which are directed
to or from the UIC gateway mapping server function in order to manipulate any UIC Mapping Server
object. For message exchange the Messages Services of the TCN will be used.

The UIC Agent can be seen as a message dispatcher in analogy to the NMA (NMA = Network
Management Agent. See [TCN] for further information). Incoming Call_Messages are decoded, the
corresponding object is accessed and a Reply_Message is sent back with the result of the service.
Object manipulation is done via functions offered by the different UMS sub-components (so-called
"function providers"). For our purpose the following instances act as corresponding function providers:

- the UIC NADI & Group Server

- the UIC Train Bus Configurator

- the WTB Manager

- the Intelligent MC Service.

Because many incoming calls can be in parallel, the UIC Agent has to synchronise such calls in a way
that function calls to the function providers are put in sequence. Thus the different function providers
need not to have to synchronize the function calls by themselves.

For details about the message handling see point C.[Link] - page 69.

Interface

The UIC Agent is directly connected to the TCN messenger as a replier function.

For generating the Reply_Messages it contacts the correspondent function providers by calling the
<mod>_request1 function. The function provider generates the reply and returns immediately, that
means it is not allowed to go to a "wait" position (non-blocking function).

1. <mod> to be replaced by UWTM, UNGT, UTBC or UIMCS.

73 556
OR
Appendices

C.[Link] - Function Providers

Each of the function providers shall obey the following principles:

Message conversion and buffer management

The function provider has to convert the messages from bytestream to data structure and vice versa.
The principle is described in Fig. 9 - page 70. Here, the procedure shall be described with the following
pseudo-code example:

<mod>_request (..)
{
allocate_buffer(B); /* /* allocate buffer for the Call_Message data structure */
NTOH_<telegram_type> (); /* /* convert from bytestream to data structure */
<telegram_type>_request(); /* /* call service provider function for processing the Call_Message and generating the
Reply_Message */
free_buffer(B); /* /* free the buffer of the Call_Message data structure */
allocate_buffer(D); /* /* allocate buffer for the Reply_Message bytestream */
NTOH_<telegram_type> (); /* /* convert from structure to bytestream */
(*free_replymsg)(); /* /* call call-back function to free the buffer of Reply_Message data structure*/
}

The reply message is generated by the telegram type related request function:

<telegram_type>_request (..)
{
allocate_buffer(C); /* /* allocate buffer for the Reply_Message data structure */
process_call_message();
generate_reply_message(); /* /* generate the Reply_Message data structure */
}

Function <mod>_request

The prototype of the <mod>_request function shall be as follows:

<mod>_RESULT <mod>_request (
void * p_uic_callmsg, /* ptr to call msg */
CARDINAL32 uic_callmsg_size, /* call message size*/
AM_ADDRESS * caller, /* caller address */
void ** pp_uic_replymsg, /* ptr to reply msg */
CARDINAL32 * p_uic_replymsg_size, /* size of reply msg*/
REPLY_FREE * p_reply_free_fct /* buffer free fct. */
);

Typ REPLY_FREE

This function shall be used to free previously allocated buffer.

typedef void (*REPLY_FREE) (void *);

74 556
OR
Appendices

Function <telegramm_type>_request

The prototype of the <mod>_local_request function shall be as follows:

<mod>_RESULT <telegram_type>_request (
UIC_T_<telegram_type> *p_uic_callmsg,
UIC_T_<telegram_type> **pp_uic_replymsg,
REPLY_FREE *p_reply_free_fct
);

Functions for conversion

For each telegram type, there must be two conversion functions:

Function

<mod>_RESULT NTOH_<telegram_type> (
UN-SIGNED8 *p_bytestream_in,
CARDINAL32 bytestream_length,
UIC_T_<telegram_type> *p_struct_out
);

for conversion from bytestream to structure

and

Function

<mod>_RESULT HTON_<telegram_type> (
UIC_T_<telegram_type> *p_struct_in,
UN-SIGNED8 *p_bytestream_out,
CARDINAL32 bytestream_length
);

for conversion from structure to bytestream.

Rules for message reply

With the exception of the UIMC and the UWTM, all other service providers must not wait for the result
for generating the reply, because their services are defined in a way that the result can be immediately
achieved. Normally its just a copying of a buffer region (e.g. a NADI copy).

For the UIMC and the UWTM, however, things are not so easy because most of the services these
two are confronted with are complex and require a multi-step handling. In these cases, only the
acceptance of the service will be replied. If a caller wants to know about the success of a call, it has
to issue a seperate status poll.

75 556
OR
Appendices

Table 6 : Error handling

Type of error Responsible Handling

call_message shorter than UAGT The UAGT shall free the buffer of the
10 octets call_message and cancel the connection
invalid call_message code UAGT return reply_message (header only) with
error indication in the status octet
invalid source/destination Function provider return reply_message (header only) with
address, invalid status error indication in the status octet
error during telegram Function provider return reply_message (header only) with
processing error indication in the status octet
error with buffer allocation Function provider error return in the <mod>_request
function.
The UAGT shall free the buffer of the
call_message and cancel the connection.
unability to reply even a Function provider error return in the <mod>_request
header indicating an error UAGT function.
(static memory error) The UAGT shall free the buffer of the
call_message and cancel the connection.

C.[Link] - UIC WTB Bus Manager (UWTM)

Function

The UIC WTB bus manager is responsible for the configuration, start-up (e.g.
STRONG/WEAK/SLAVE/PASSIVE mode) and control (e.g. inhibit/allow) of the WTB link layer. For
this reason it shall implement a state machine which follows the states of the WTB Link Layer BMI. To
properly start-up the WTB, it shall receive its configuration data from the Node Supervisor, and it shall
work in a way that it performs WTB control completely autonomously thereafter.

Interfaces

1. Exported functions

uwtm_configure () used for UWTM configuration. To be called by the Node Supervisor.

uwtm_sync () lifesign indication for redundancy control
uwtm_request() called by the UAGT for E-telegram processing (user services)

2. Supported user services

The UIC WTB Manager shall provide uwtm_request() functions to the UIC Agent. The UWTM shall
handle the following user services:

• change_omode
• inauguration_control
• sleep
• inauguration_enforce

76 556
OR
Appendices

• read_uwtm_state
• read_uwtm_topo
• leading

3. Controlling with process variables

In parallel to the user services the WTB manager provides process variables for easy remote
control and state reading (see Table 2 - page 61 and 3 - page 63).

C.[Link] - UIC Intelligent Multicast Server (UIMCS)

Function

The UIMCS serves as a central instance for multicasting messages using the TCN single-cast protocol.
Messages are multicasted to all gateways connected to the WTB.

For the UIC Mapping Server a multicast service is required for:

- distribution of correction info to all other vehicles;

- distribution of group information to all other vehicles.

Interfaces

1. Exported functions
uimcs_request () called by the UAGT for E-telegram processing (user services)
2. Supported user services
multicast_create
C.[Link] - UIC Train Bus Configurator

Function

The UIC Train Bus Configurator is responsible for the UIC train inauguration, that means to distribute
and collect vehicle descriptors and to assign the correct UIC address to nodes and vehicles. The basic
concept is given in point C.1 - page 37. The whole functionality of the UTBC is devided into two tasks:

- After TCN inauguration, the UTBC calculates the new NADI (algorithm see point C.1) and stores
it in the NADI database directly. This algorithm is implemented within one function that will be
called by the UWTM each time a new topography has been distributed.

- Correction information is passed to the UTBC by the UIC Agent, e.g. from any display. This
correction information is processed by a function that is called by the UIC Agent with the UTBC
as the corresponding function provider.

Processing of inauguration data and processing of correction information are completely different
tasks with disjunctive functions and operating on disjunctive data, therefore there is no special
synchronisation needed. None of the tasks needs to incorporate a state machine, that is why they can
be implemented as non-blocking functions.

77 556
OR
Appendices

Interfaces

1. Exported functions

utbc_request() called by the UAGT for E-telegram processing (user services)

utbc_set_leading_req() to be called by the UWTM in the case leading is requested or a
leading request shall be canceled
utbc_build_nadi() to be called by the UWTM each time a new topography has been
distributed
utbc_delete_config () to be called by the UWTM after reception of an order to delete
the confirmed configuration
utbc_red_indicate() to be called by the UWTM if a redundancy switch-over occurs

2. Supported user services

• write_res_nr
• write_correction

C.[Link] - NADI and NADI & Group Server

Function

The NADI is the database for all train-describing data. Thus it contains information about the train
topography, the individual vehicles within the train ("vehicle descriptors") and the group memberships
of vehicles. The NADI is accessable by functions that are supplied by the "UIC NADI & Group Server".
Thus the NADI is completely encapsulated in an "object oriented" way and the data structure itself is
hidden to the user.

Each time a new inauguration takes place the UTBC generates a new version of the NADI. This
version can either be confirmed by the application or not. This new version is stored in the NADI
database. It shall be possible to read from and write to the database in parallel in a consistent and
non-blocking way.

Concerning group handling the NADI server stores new groups in the NADI database. These groups
are delivered by the seperated Group Server1. After storage of the groups, the group membership
information can be read at any time from local instances.

Interface

1. Exported function

ungs_write_nadi() called by the UTBC each time a new NADI version has been calculated
ungs_request() called by the UAGT for E-telegram processing (user services)

1. It is assumed that group memberships are inserted either by the train attendants or by any other
mechanism. The handling of groups is on behalf of the Group Server, that is not a part of the UIC Mapping
Server.

78 556
OR
Appendices

2. Supported user services

• read_nadi
• write_group
• write_group_all
• read_group
• read_group_list
• delete_group
• delete_group_all

C.2.7 - Other components related to the UIC Mapping Server

This point presents a brief informal description of the UIC gateway software components which are
not part of the UIC mapping server.

C.2.7.1 - UIC Mapping Server Remote Interface (UMSI)

The UIC Mapping Server standardizes the remote user access with TCN messages. It is not specified
herein, nor it is requested, how a remote user (e.g. an MVB station) may initiate such message
exchange with the UIC Mapping Server. But it would be convenient to provide a unique and simple to
use functional interface to remote user processes that allows to access the UIC Mapping Server
services in a general way. This functional interface will be called the UIC Mapping Server remote
interface. This interface consists of a set of C-functions (assembled in a library) that can be called by
user processes and which handle all the message data exchange with the UIC Mapping Server, thus
discharging the user from assembling messages and managing message transfer by himself.

Besides the necessary message data exchange with the UIC Mapping Server for UMS service calls,
the UMSI shall also be reponsible for the mapping of UIC addresses to TCN addresses when user
processes apply message calls to other users somewhere in the TCN. Thus it should provide functions
for message data sending similar to that defined by the TCN RTPs, but with the distinction that UIC
addresses are used rather than TCN ones.

Example:
The user function "Door" in vehicle 8 wants to send a diagnostic message to the user function "dia-
gnosis" in the leading vehicle. For this, it calls a function:
umsi_call_request ( destination_vehicle = leading vehicle,
destination_function = Diagnosis
....

The UMSI converts the UIC addresses to the TCN addresses (e.g. leading vehicle = WTB node 62,
diagnosis = TCN function "34") and calls the corresponding TCN function for message transmission.
In the other direction, the same is done with the reply.

Hence the user only has to think in UIC addresses and needs not to care about TCN addressing,
making user programs more easy to understand.

The UMSI also takes care of holding the newest NADI version in order to prevent missadressing of
messages.

79 556
OR
Appendices

C.2.7.2 - Other Gateway software components

This point describes the software components which are needed besides the UIC Mapping Server to
build a UIC conformable gateway. They are included herein for information, but they do not belong to
the UIC Mapping Server software package.

C.[Link] - WTB Link Layer

The WTB Link Layer is responsible for the WTB inauguration and the sending and receiving of PD and
MD frames. The WTB Link Layer shall be in accordance to the IEC 61375, part 4. To adapt to a certain
hardware plattform all HW related functions are seperated and encapsulated into a driver software,
thus that the WTB link layer is completely HW independent.

The WTB link layer provides the following interfaces:

- Bus Management Interface BMI,

- PD Traffic Store,

- Inauguration Data Interface,

- Driver interface,

- PIL interface.

The inauguration data interface provides functions for reading and writing inauguration data datasets.
These datasets are used by the UTBC to calculate a valid NADI.

C.[Link] - Messenger and RTP

The Messenger software module takes care of routing and transporting TCN message data within the
TCN. It shall be in accordance to the IEC 61375, part 2.

C.[Link] - Process Data Marshalling

The process data marshalling is responsible for data marshalling between MVB (or any other vehicle
bus) and the WTB. Marshalling means one of the following:

- copy selected process variables from WTB to MVB and vice versa;

- apply functions to one or a set of process variables and sending the function result on either WTB
(exporting) or vehicle bus (inporting). Allowed functions are defined in UIC Leaflet 556.

The PDM shall support import and export of process data frame types 0 (invalid), 1 (leading vehicle),
2 (traction vehicle) and 3 (other).

Towards the UMS, the PDM shall provide a function pdm_control that will be used by the UWTM to
start and stop the PDM and to select the marshalling mode.

80 556
OR
Appendices

C.[Link] - Node Supervisor and NSDB

The node supervisor is a "virtual" instance because its implementation greatly depends on the used
hardware plattform and therefore can not be a common component of the gateway. It mainly has the
task to start the gateway in a proper way ("main task"), that means both initialization and configuration.
Configuration data are held in the node supervisor database (NSDB). The NSDB contains
configuration data for the following components:

- Messenger,

- PDM and its database,

- Mapping Server,

- WTB configuration,

- MVB device address list,

- WTB traffic store,

- MVB traffic store.

C.[Link] - Operating System and PIL

Because selecting an operating system is a choice of the hardware deliverer there shall be a
standardized processor interface library (PIL) available which provides a set of hardware-independent
operating system services like:

- task lock/unlock,

- copy functions,

- interrupt functions,

- semaphores,

- timers,

- queues.

The PIL shall be in accordance to the JDP specification. All generic software components of the UIC
Mapping Server will use the PIL.

81 556
OR
Appendices

C.2.8 - Specification of the local Mapping Server E Telegrams

The local E telegrams are restricted to the vehicle internal application and shall not be sent on the
WTB.

Information path Representation and processing

Telegram type
Destinat Sub-
Source Time sti
N° Purpose ion Origin of Data P

Octet
Code/
informa- Meaning type/ Bit
value
D out a tute
fct veh veh fct tion values M [sec.] va-
lue
1 2 13 3 9a 14 10 15 16 16a 17 18 19 20 21 22
UIC Mapping Server - Local telegrams
1.1 set/reset NN 1..63 1..63 15 E Code Unsigned 7+8 0x00F0
attribute 16
"leading State Unsigned 9 0: reset
vehicle"
8 1: set
Direction (for Unsigned 11 0:
trainsets with 8 direction 1
2 driver cabs) 1:
direction 2
1.1A acknowledge 15 1..63 1..63 NN E Code Unsigned 7+8 0x0AF0
16
State Unsigned 9 0: accepted
8 >200: error
1.2 request UIC NN 1..63 1..63 15 E Code Unsigned 7+8 0x00F1
to TCN 16
conversion
UIC Address Unsigned 11 0..63
8
1.2A acknowledge 15 1..63 1..63 NN E Code Unsigned 7+8 0x0AF1
16
State Unsigned 9 0: accepted
8 >200: error
topo_count Unsigned 11
8
UIC Address Unsigned 12 0..63
8
number n of Unsigned 13 0: no found
the returned 8 1..63
TCN
addresses
TCN Unsigned 14 1..63
Address 1 8 .
TCN 14+(
Address n n-1)

a. i = Ini-value

82 556
OR
Appendices

Record of updates:

Version Date Change Reason for the change

002.01 01.11.2004 Change of the layout according to M1 New layout based on UIC guide
M1
Adoption of a history of updates Increasing the usability
Adoption of a revision number Enhancement and redesign of the
versioning
002.02 01.08.2005 Change of the layout
UIC requirement
Renumbering of the Appendices

83 556
OR
Appendices

C.3 - Construction of the inauguration frame (Version 002.02, valid

from 01.08.2005)

Data type Source Serial No

Source
Octet

Scope of Code Meaning Gateway from

vehicle
Bit

values (=Trainset) Appendix E

1 0-3 ENUM4 1 Type of application UICa X

4-7 0 Reserve
2 ENUM8 NN UIC inauguration frame - version number X 133
3 0-6 "WORD7" NN TCN inauguration address X 514
7 BITSET1 Orientation relative to the TCN master X 505
0 = reference direction train bus node is opposite
to the reference direction TCN
1 = reference direction train bus node is the
same as the reference direction TCN
4 UNSIGNED8 124 Length of the application data in the X
inauguration frame
5 ENUM8 NN UIC Code of the operating RU X 135
6 ENUM8 NN UIC Code of the owning RU X 136
7 ENUM8 NN National application identification X 138
8 ENUM8 NN National telegram version X 137
9 INTEGER8 NN NN > 0: Number of vehicles monitored from X 139
this node (1…6)
NN ≤ -2: Number of nodes in this
vehicle is |NN|
10 0 BITSET8 1 Delete confirmed configuration X 501
1 1 Configuration unknown X 502
2 1 UIC address placed X 503
3 1 Configuration stored X 504
4 1 Vehicle was leading vehicle X 510
5 1 Vehicle wants to be leading vehicle X 511
6 if bit 10/5 = 0: meaningless X 515
if octet 9 < 2: meaningless
0 In the trainset, vehicle with cab 1 wants to be
leading.
Note: Cab 1 is the front cab in the reference
direction of the trainset
1 In the trainset, vehicle with cab 2 wants to be
leading
7 1 Inauguration triggered by redundancy change X 516
over

11 UNSIGNED8 NN Confirmed UIC address of the vehicle which is X 507

the location of the train bus node (property 141)
0 No confirmed UIC address known

12 UNSIGNED8 NN Confirmed number of vehicles = NN X 508

0 No confirmed number of vehicles known
a. A vehicle which does not contain the value 0x1 in the lower four bits is not a UIC vehicle. That means that for this train no valid
NADI can be produced. The upper four bits are reserve.

84 556
OR
Appendices

Data type Source Serial No

Source
Octet
Scope of Code Meaning Gateway from
vehicle

Bit
values (=Trainset) Appendix E

13 Array Confirmed position of the vehicles which X 509

BITSET8 cannot be reached over the train bus:
14
15 0. Bit = Vehicle position 1

16 1. Bit = Vehicle position 2

17
18 n. Bit = Vehicle position n+1

19
20 63. Bit = Vehicle position 64

21 ENUM8 NN R telegram version number X 134

22 0 BITSET8 1 Vehicle has sealed toilets X 17

1 1 Vehicle is pressure tight X 19
1 Vehicle has side sensitive door locking over the X 21
2
train bus
1 Vehicle has side sensitive door not locking over X 22
3
the train bus
4 1 Vehicle supports "door close" X 23
5 1 Vehicle supports door close monitoring X 24
6 1 Vehicle supports prevent/allow WC use X 29
7 1 Vehicle supports lighting control over train bus X 30
23 0 BITSET8 1 Vehicle supports internal loudspeaker (choice X 31
receipt)
1 1 Vehicle supports internal loudspeaker X 32
(obligation receipt)
2 1 Vehicle supports speech connection with X 33
leading vehicle
3 1 Vehicle supports speech connection between X 34
leading vehicle and trailing tractive unit
4 1 Vehicle has external loudspeaker X 35
5 1 Vehicle supports external loudspeaker control X 36
6 1 Vehicle supports public address in individual X 37
vehicles/vehicle groups
7 1 Vehicle supports warm chain X 142
24 0 BITSET8 1 Tractive unit with electric drive X 38
1 1 Tractive unit with diesel engine drive X 39
2 1 Vehicle has ≤ 2 pantographs X 40
3 1 Vehicle has > 2 pantographs independent of X 41
each other
4 1 Vehicle can remotely control the drive of other X 44
(electric) tractive units with control system 1e
over the train bus
5 1 Vehicle can remotely control the drive of other X 45
(diesel) tractive units with control system 1d
over the train bus
6 1 Vehicle can remotely control the drive of other X 46
(electric) tractive units with control system 2e
over the train bus
7 1 Vehicle can remotely control the drive of other X 47
(diesel) tractive units with control system 2d
over the train bus

85 556
OR
Appendices

Data type Source Serial No

Source
Octet
Scope of Code Meaning Gateway from
vehicle

Bit
values (=Trainset) Appendix E
25 0 BITSET8 1 Vehicle can remotely control the drive of other X 48
tractive units with control system 3 over the
train bus
1 1 Drive of the electric tractive unit with control X 49
system 1e can be remote-controlled over the
train bus
2 1 Drive of the diesel tractive unit can be remote- X 50
controlled with control system 1d over the train
bus
3 1 Drive of the electric tractive unit can be X 51
remote-controlled with control system 2e over
the train bus
4 1 Drive of the diesel tractive unit can be X 52
remote-controlled with control system 2d over
the train bus
5 1 Drive of the tractive unit can be X 53
remote-controlled with control system 3 over
the train bus
6 1 Vehicle can remotely control the drive of other X 54
(tractive) vehicles but not over the train bus
7 1 Drive of the (tractive) vehicle can be X 55
remote-controlled but not over the train bus
26 0 BITSET8 1 Vehicle has a speed controller for traction X 56
1 1 Vehicle has a train line X 57
2 1 Vehicle can globally remotely control the train X 58
line over the train bus
3 1 Vehicle can remotely control the train line over X 59
the train bus, selectively
4 1 Vehicle can be remote-controlled by the train X 60
line over the train bus, selectively
5 1 Vehicle supports report "train line in" X 61
6 1 Vehicle supports report "train line earthed" X 62
7 1 Vehicle supports report "train line externally X 63
supplied"
27 0 BITSET8 1 Vehicle supports remote control of fan over the X 64
train bus
1 1 Vehicle supports compressor remote control X 65
over the train bus
2 1 Vehicle supports input of target speed X 66
3 1 Vehicle supports fault reset X 67
4 1 Vehicle supports "establish traction readiness" X 68
5 1 Vehicle supports "sand"! X 69
6 1 Vehicle supports "drive or prepare to drive...!" X 70
7 1 Vehicle supports "drive through tunnel" X 71
28 0 BITSET8 1 Vehicle supports over high current limitation X 72
1 1 Vehicle supports "drive through a neutral X 73
section"
2 1 Vehicle supports start train power supply or X 74
switch on/switch off or cut out
3 1 Vehicle supports preheat coolant X 75
4 1 Vehicle supports transmission gear change X 76
5 1 Vehicle supports fast brake command X 77
6 1 Vehicle supports control of the Mg-brake X 78
7 1 Vehicle supports release of the WB-brake X 79

86 556
OR
Appendices

Data type Source Serial No

Source
Octet
Scope of Code Meaning Gateway from
vehicle

Bit
values (=Trainset) Appendix E
29 0 BITSET8 1 Vehicle supports control of the WB-brake X 80
1 1 Vehicle supports tilting technology X 81
2 1 Vehicle supports report of high current X 82
3 1 Vehicle supports report of the overhead line X 83
voltage
4 1 Vehicle supports report of the train power X 84
supply
5 1 Vehicle supports report of preheating operating X 85
6 1 Vehicle supports report of transmission gear X 86
change
7 1 Vehicle supports report of diesel engine speed X 87
30 0 BITSET8 1 Vehicle supports auxilliary control of X 88
compressor
1 1 Vehicle supports report of max. possible X 89
tractive effort value
2 1 Vehicle supports report of max. possible brake X 90
force value
3 1 Vehicle supports report of actual traction value X 91
4 1 Vehicle supports ep-brake over the train bus X 92
with control system1
5 1 Vehicle supports ep-brake over the train bus X 93
with control system 2
6 1 Vehicle has ep-brakes but they are not X 94
controlled over the train bus
7 1 Vehicle supports emergency brake shorting X 95
over the train bus
31 0 BITSET8 1 Vehicle has emergency brake shorting but not X 96
over the train bus
1 1 Vehicle has magnetic rail brakes X 97
2 1 Vehicle supports magnetic rail brakes over the X 98
train bus
3 1 Vehicle has motor brakes X 99
4 1 Vehicle supports motor brakes over the train X 100
bus
5 1 Vehicle has eddy current brakes X 101
6 1 Vehicle supports eddy current brakes over the X 102
train bus
7 1 Vehicle supports automatic brake test X 103
32 0 BITSET8 1 Tractive unit reports: motor brake is in service X 104
1 1 Vehicle supports tail light operation X 106
2 1 Vehicle supports tail light monitoring X 107
3 1 Vehicle supports check of automatic coupling X 110
engagement
4 1 Vehicle supports control of air conditioning X 111
system(s)
5 1 Vehicle supports diagnostics: flashing defect X 112
indicator light and acknowledgement
6 1 Vehicle supports diagnostics: transmission of X 113
diagnostic results
7 1 Vehicle supports diagnostics: all fault reports to X 114
the leading vehicle

87 556
OR
Appendices

Data type Source Serial No

Source
Octet
Scope of Code Meaning Gateway from
vehicle

Bit
values (=Trainset) Appendix E
33 0 BITSET8 1 Vehicle supports diagnostics: individual fault X 115
reports to the leading vehicle
1 1 Vehicle supports diagnostics: sum of fault X 116
reports
2 1 Vehicle supports electronic train running X 117
indicator
3 1 Vehicle supports "next station" X 119
4 1 Vehicle supports "train connection at next X 120
station"
5 1 Vehicle supports transmission of advertising X 121
6 1 Vehicle supports "stop requested" X 123
7 1 Vehicle supports data refreshing in ticket X 124
canceller
34 0 BITSET8 1 Vehicle supports "energy saving" (generic X 126
order)
1 1 Vehicle supports "data channel" X 128
2 1 Vehicle supports report date and time X 131
3 1 Vehicle has radio clock X 132
4 1 Vehicle supports "run through washer" X 143
5 1 Vehicle can remotely control the drive of other X 144
tractive units with control system 4 over the
train bus.
6 1 Drive of the tractive vehicle with control system X 145
type 4 can be remotely controlled over the train
bus
7 1 Vehicle supports report of traction resources X 146
35 0 BITSET8 1 Vehicle supports report of additional X 147
informations
1 1 Vehicle supports parking mode X 148
2 1 Vehicle supports diagnostics: report of detailed X 149
faults to the leading vehicle
3 1 Vehicle supports diagnostics: fault correction X 150
procedure
4 1 Vehicle supports diagnostics: tests X 151
5-7 0 Reserve for gateway specific properties X
36 BITSET8 0 Reserve for gateway specific properties X
bis
41
42 BITSET8 0 Reserve for national gateway specific X
bis properties
43
44 0 General reserve X
Vehicle based properties – 1st octet series = 1st vehicle in trainset (in reference direction front of trainset)
45 Array of binary UIC Identification number of the vehicle X
UNSIGNED8
46
47
48
49

88 556
OR
Appendices

Data type Source Serial No

Source
Octet
Scope of Code Meaning Gateway from
vehicle

Bit
values (=Trainset) Appendix E
50 0 BITSET8 1 Vehicle has 1st class seats X 1
1 1 Vehicle has 2nd class seats X 2
2 1 Vehicle has seats for smokers X 3
3 1 Vehicle has seats for non-smokers X 4
4 1 Vehicle has equipment for disabled people X 5
5 1 Vehicle has a compartment for mother and X 6
child
6 1 Vehicle has a conference compartment X 7
7 1 Vehicle has a guard’s compartment X 8
51 0 BITSET8 1 Vehicle is restaurant car or has seats for meals X 9
1 1 Vehicle has a support point for a minibar X 10
2 1 Vehicle has a support point for catering X 11
3 1 Vehicle is a couchette coach or has couchette X 12
places
4 1 Vehicle is a sleeping car X 13
5 1 Vehicle is a special coach (e.g. company X 14
coach)
6 1 Vehicle is a baggage van or has space for X 15
carrying baggage
7 1 Vehicle is a postal vehicle or has space for X 16
carrying mail
52 0 BITSET8 1 Vehicle has a telephone for passenger use X 18
1 1 Vehicle is a freight wagon X 20
2 1 Vehicle has moveable footsteps X 25
3 1 Vehicle supports release of the footsteps X 26
4 1 Vehicle supports locking of the doors of X 27
sleeping cars
5 1 Vehicle supports common operation of the X 28
corridor connection doors to the neighbouring
vehicle
6 1 Vehicle has a cab for one direction of travel X 42
7 1 Vehicle has two cabs for both directions of X 43
travel
53 0 BITSET8 1 Vehicle supports completeness of the train X 105
1 1 Vehicle has an automatic coupling on vehicle X 108
No. 1 end
2 1 Vehicle has an automatic coupling on vehicle X 109
No. 2 end
3 1 Vehicle supports electronic seat reservation X 118
4 1 Vehicle supports train crew call X 122
5 1 Vehicle supports FIS-exchange X 125
6 1 Vehicle supports "energy saving" (vehicle X 127
selective)
7 1 Vehicle supports group addressing X 129
54 0 BITSET8 1 Vehicle supports report of actual speed value X 130
1 1 Vehicle has a train bus node X 141
2-7 0 Reserve for special vehicle properties X
55 BITSET8 0 Reserve for national vehicle specific properties X

56 0 General vehicle specific reserve X

57 UNSIGNED16 NNN Seat reservation number of the vehicle X 513

- 0 No seat reservation number given
58

89 556
OR
Appendices

Data type Source Serial No

Source
Octet
Scope of Code Meaning Gateway from
vehicle

Bit
values (=Trainset) Appendix E
Vehicle based properties – 2nd octet series = 2nd vehicle in trainset (in reference direction front of trainset)
59 As octet 45 - 58 x
bis
72
Vehicle based properties – 3rd octet series = 3rd vehicle in trainset (in reference direction front of trainset))
73 As octet 45 - 58 x
bis
86
Vehicle based properties – 4th octet series = 4th vehicle in trainset (in reference direction front of trainset))
87 As octet 45 - 58 x
bis
100
Vehicle based properties – 5th octet series = 5th vehicle in trainset (in reference direction front of trainset))
101 As octet 45 - 58 x
bis
114
Vehicle based properties – 6th octet series = 6th vehicle in trainset (in reference direction front of trainset))
115 As octet 45 - 58 x
bis
128

Record of updates:

Version Date Change Reason for the change

002.01 01.11.2004 Admission of 9 new gateway specific Inclusion of the new functions
static vehicle properties in the concerning UIC Leaflet 647
inauguration frame (properties 143-151)
Change of the layout according to M1 New layout based on the UIC
guide M1
Adoption of a history of updates Increasing the usability
Adoption of a revision number Enhancement and redesign of the
versioning
002.02 01.08.2005 Change of the layout
Modification of the numbering of the UIC requirement
Appendices

90 556
OR
Appendices

Appendix D - Process Data Marshalling (PDM) -

Specification (Version 002.02, valid from
01.08.2005)

D.1 - Introduction

The International Electrotechnical Commission, Technical Committee 9, Working Group 22 (IEC TC9
WG22), in collaboration with the International Union of Railways, Pilot Group 5R (UIC 5R), has
developed a set of standards defining a Train Communication Network (TCN).

This network consists of a train bus which interconnects the different vehicles of a train and of a vehicle
bus which interconnects the equipment within a vehicle.

This document describes the functionality of Process Data Marshalling PDM. In principle, PDM
transports process variables from TCN Wire Train Bus WTB to a vehicle bus (e.g. TCN Multifunction
Vehicle Bus MVB) and vice versa. PDM handles periodic data only, message data are not handled.

The Process Data Marshalling PDM is the application task to transfer process variables over bus
boundaries. The PDM can be customized to a specific application by lists. These lists define where
process variables come from and where they go to. PDM Function can do some processing on the
process variables.

D.2 - Marshalling types

PDM copies process variables from one Traffic Store to another Traffic Store:

WTB

Train bus traffic store

Export

Import

PDM

Vehicle bus traffic store

Vehicle bus

Two types of marshalling are defined:

- Export Marshalling

- Import Marshalling

91 556
OR
Appendices

D.2.1 - Export Marshalling

Export Marshalling means, to copy variables from one or more Vehicle Bus Traffic Stores to the WTB
Traffic Store source port. The entire WTB port is written, so unused space in the port has to be filled
with default values.

The Export Marshalling can do some processing on the process variables. The Export Marshalling
determines the length of the exported frame depending on the frame type.

D.2.2 - Import Marshalling

Import Marshalling means, to copy variables from the WTB Traffic Store to the statically configured
Vehicle Bus Traffic Store(s). The Import Marshalling can do some processing on the process
variables.

D.3 - Marshalling Modes

A vehicle may have different dynamic operation modes. According to these vehicle operation modes,
PDM offers marshalling modes. Each marshalling mode may have a different configuration.

Example:
A traction vehicle like a locomotive may be the traction leader of a train set, traction follower or support
no traction at all. In each case different data will be imported and exported.

A default mode should always be present, if no specific mode is used for PDM.

If the vehicle operation mode changes, PDM can be reconfigured to accept the new marshalling mode.

D.4 - Data paths in PDM

This point is for informational purposes only and not normative as each gateway supplier may
implement their gateways differently.

PDM marshalls the process data from a source to a destination. The destination is always a Traffic
Store. The source is a Traffic Store, a Default Value Buffer or an Undefined Value Buffer.

92 556
OR
Appendices

Traffic Store

Default Value Undefined Value

Buffer Buffer

Replacement dependent on Database

vehicle characteristics vehicle
characteristics
PDM

PDM Function

Traffic Store

The following data paths can be configured:

- from Traffic Store to Traffic Store, direct or via a PDM Function.

This is the basic task of PDM. The process variable can be processed by a function before it is
written to the destination Traffic Store.

- from Default Value Buffer to Traffic Store.

Default values are used when a value should be written to a port, but no process variable can
deliver this value. Default values are not intended to substitute invalid or too old (not fresh)
process variables.

- Vehicle feature dependent process variable from Traffic Store to Traffic Store, direct or via a PDM
Function.
Process variables may be combined with static and dynamic vehicle features. Marshalling will only
be done, when the vehicle feature is present. Otherwise PDM substitutes the process variable by
an undefined or application defined default value of the apropriate data type. An undefined value
is represented by a check variable set to 11b or the variable value set to all "1". This conforms to
the TCN-Norm IEC 61375.

93 556
OR
Appendices

Three cases should be considered for vehicle dependent process variables:

- One variable with one check variable: PDM can substitute an undefined value by setting the check
variable to 11b.

- Several variables with one check variable: If all variables are not supported, PDM can substitute
undefined values by setting the check variable to 11b.

- Several variables with one check variable: If only some variables are not supported, PDM should
substitute application defined default values.

The process variable can be processed by a function before it is written to the destination Traffic Store.
If the process variable is substituted by an undefined value, it can be ignored as function argument.

D.5 - PDM Operation

PDM is activated by a configurable timer or an event (e.g. WTB data receive). After activation, PDM
copies all variables configured for the activated marshalling type.

The copy process has four steps:

1. All variables are read, one set of data after the other.

2. For each variable with configured freshness supervision the freshness is checked. Too old
variables are invalidated (see below).

3. Then all configured functions (see point D.6 - page 96) are applied to the variables.

4. At last PDM copies the variables, function results and default values to the destination ports and
Traffic Stores.

94 556
OR
Appendices

for all datasets from which Variables come

read all variables of dataset
if (Import Marshalling and Frame Type OK) or no Import Marshalling
then else
for all variables of dataset set all variables of dataset
invalid
if check freshness, data too old
then else
set variable invalid
if Import Marshalling and any frame type field not OK
then else
set all variables of WTB Traffic Store invalid
for all PDM Functions
execute PDM Function
for all datasets to which variables go to
write all variables of dataset
(PD Variables, Function results, Default Values)

A variable or a function is invalidated by the following algorithm:

if Variable or function result has check

then else
set check to 00b set variable value to all "0"

If the variable or function result has a check variable, only the check variable is set to 00b . The variable
value is not set to all "0" since the variable can not be very invalid.

If the variable or function result has no check variable the value will be set to all "0". This conforms to
the TCN Standard IEC 61375.

NB : Since overwriting the value of a Process_Variable with all "0" or "1" may yield a legal value, a
Check_Variable of the same dataset is used as a validity indicator where this could be a
problem (IEC 61375, ch. [Link].4 Error handling).

95 556
OR
Appendices

D.6 - PDM Function

D.6.1 - General

Additionally to the pure copying of variables, PDM supports the processing of process variables by
functions. The function processing is supported for all Marshalling types.

Example:
Suppose, an application needs to know whether all doors of a train are closed. Since a train may
consist of 1 to 20 vehicles with doors, the application must be able to process a wide range of input
data. Using a function of the PDM which reads all door states and delivers one variable saying "all
doors closed" makes application programming much easier.

The functions offered by PDM have generally the form:

y = f ( x 1 , x 2 , ... x n ) ; x i ,i = 1 .. n , input argument, y function result

There may be any number (greater than zero) of arguments and one result. Arguments of a function
may come from different ports and Traffic Stores. Arguments and the result are described by
PV_Names.

The PDM offers the following standard processing functions:

- logical functions: AND, AND_IGNORE_INVALID

OR, OR_IGNORE_INVALID
XOR, XOR_IGNORE_INVALID
- numeric functions: MIN, MIN_IGNORE_INVALID
MAX, MAX_IGNORE_INVALID
SUM, SUM_IGNORE_INVALID

D.6.2 - Function processing

All arguments of a function are checked for validity. Too old variables are already invalidated by the
second step of the copy process. Arguments can have a check variable or not. Both variants can be
mixed if the function has more than one argument.

If an argument is invalid or undefined, it can be ignored (functions XXX_IGNORE_INVALID). If an

invalid or undefined argument is not ignored, it sets the function result to invalid.

Only valid arguments are processed. If all arguments are invalid or undefined, the result is set to
invalid.

If necessary, the type of the arguments is converted to a type suitable for processing. The processing
type is configurable.

If an error occurs during the evaluation of the function the result is set to invalid.

After all arguments are processed, the computed result is converted to the desired function result
described by a PV_Name.

The function result can have a check variable or not, independent of the arguments.

96 556
OR
Appendices

for all arguments of function

if variable is valid
then else
cast arguments type to if IGNORE_INVALID
computing type
apply function to then else
argument and
ignore argument set function result invalid
compute function
result return
function result
if all variables are invalid
then else
set function result invalid
return function result
cast computing type to result type
if function result has check
then else
set check to 01b
return function result

The validity of a variable is checked by the following algorithm:

if Variable has check

then else
if check = 10b if Variable value has all "0" or "1"
or check = 01b
then else then else
Variable is valid Variable is invalid Variable is invalid Variable is valid

97 556
OR
Appendices

D.6.3 - Logical functions: AND, OR and XOR

For these functions the arguments are of BOOLEAN type, ANTIVALENT type or of BITSET type. If the
argument is of BITSET type, it is necessary to specify also the bit position of the bit within the bit-set.
The types of arguments may be mixed within one function call.

The result value of this functions is of BOOLEAN or ANTIVALENT type.

Additionally, it is possible to specify whether the variable is used directly or whether the variable is
negated before use.

D.6.4 - Numeric functions: MIN, MAX, SUM

For these functions the arguments are of INTEGER, UNSIGNED, REAL and FRACTIONAL type with
a maximal size of 32 bits. INTEGER and UNSIGNED with different sizes may be mixed within one
function call. After processing the type of the result is converted (by a cast) to the type of the
destination variable. There is no range checking, be careful with overflows.

Record of updates:

Version Date Change Reason for the change

002.01 01.11.2004 Change in the layout according to M1 New layout in accordance with
UIC guide M1
Adoption of a record of updates Increasing the usability
Adoption of a revision number Enhancement and redesign of the
versioning
002.02 01.08.2005 Change in the layout
UIC requirement
Renumbering of the Appendices

98 556
OR
Appendices

Appendix E - Vehicle properties and collective addresses

E.1 - List of static vehicle properties (Version 001.02, valid from

01.08.2005)

The list of static vehicle properties is to be found on the UIC-Website ([Link] Technical
and Research/Products/Catalogue of products technically approved by UIC/train bus.

E.2 - List of dynamic vehicle properties (Version 001.02, valid from

01.08.2005)

The list of dynamic vehicle properties is to be found on the UIC-Website ([Link]

Technical and Research/Products/Catalogue of products technically approved by UIC/train bus.

E.3 - List of collective addresses (Version 001.02, valid from 01.08.2005)

The list of collective addresses is to be found on the UIC-Website ([Link] Technical

and Research/Products/Catalogue of products technically approved by UIC/train bus.

99 556
OR
Appendices

Appendix F - TCN Data Types (Version 001.02, valid

from 01.08.2005)

F.1 - Presentation and encoding of transmitted data

The Appendix F specifies data types and encoding rules to specify how these types are encoded for
transmission. It serves as an informal, first reference; more detailed information can be found in the
TCN standard.

F.2 - Data ordering

F.2.1 - Transmission format

The TCN standard prescribes the order in which bits and words are transmitted over the Train
Communication Network. To this effect, it defines a number of primitive types and structured types.

F.2.2 - General rules

- Information about the data type shall not be sent with the data. Types are expected to be defined
and agreed beforehand between the users of the TCN in a specific application.
- All data shall be transmitted most significant octet first (Big-Endian). On the WTB, each octet is
transmitted with the least significant bit first.
- The elements of a structured type (e.g. Record) shall be transmitted in the order in which they are
declared.
- Arrays shall be transmitted in order of increasing index. Multi-dimensional arrays are transmitted
in the order their indices are listed (e.g. ARRAY OF [row, column] is transmitted row by row).
- To ease implementation, a variable shall be transmitted at an offset address which is a multiple of
its size (natural alignment).
- Variable length data (open arrays, records, sets...) shall not be used as Process_Variables.
- When the network is unable to supply data, for instance when a transmission error occurs or when
the Traffic_Store is not initialised, any instance which detects it shall overwrite the unsafe data
with "0".

This notation uses compact encoding rules:

- It assumes that all user-defined types are recognised by the destination.
- It uses primitive types of fixed size.
- It includes the size of the elements explicitly in a dedicated field where needed.
- It is not aligned, although natural alignment should be used.

100 556
OR
Appendices

F.3 - Notation for the primitive types

F.3.1 - Notation for the Boolean type

Definition

A primitive type with two distinguished values, TRUE and FALSE.

NB : This type is used to represent binary inputs and outputs (relay, led, micro switch, etc.).

Encoding

A variable of Boolean type shall be encoded as one bit:

1. Bit Interpretation

2∧0
0 FALSE
1 TRUE

F.3.2 - Notation for the Antivalent type

Definition

A primitive type with four distinguished values.

NB : Variables of this type are used as check variable for other variables or for critical Booleans.

Encoding

A variable of Antivalent type shall be transmitted as 2 bits, the first one corresponds to the Boolean
meaning of the variable and the second to its inverse. It may take one of four states, as follows:

1. Bit 2. Bit Interpretation

2∧1 2∧0
0 0 ERROR
0 1 FALSE
1 0 TRUE
1 1 UNDEFINED

NB : the ERROR and UNDEFINED states may be interpreted as legal states by an application.

101 556
OR
Appendices

F.3.3 - Notation for the unsigned integer types (UNSIGNED#)

Definition

A primitive type with distinguished values which are positive whole numbers, including zero (as a
single value), having a fixed size in bits defined by the suffix #.

Encoding

UNSIGNED8 Type

Offset 0 1 2 3 4 5 6 7
2∧7 2∧6 2∧5 2∧4 2∧3 2∧2 2∧1 2∧0

Range: 0..2∧8-1

UNSIGNED16 Type

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
2∧15 2∧14 2∧13 2∧12 2∧11 2∧10 2∧9 2∧8 2∧7 2∧6 2∧5 2∧4 2∧3 2∧2 2∧1 2∧0

Range: 0..2∧16-1

UNSIGNED32 Type

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
2∧31 2∧30 2∧29 2∧28 2∧27 2∧26 2∧25 2∧24 2∧23 2∧22 2∧21 2∧20 2∧19 2∧18 2∧17 2∧16
2∧15 2∧14 2∧13 2∧12 2∧11 2∧10 2∧9 2∧8 2∧7 2∧6 2∧5 2∧4 2∧3 2∧2 2∧1 2∧0
Offset 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Range: 0..2∧32-1

F.3.4 - Notation for the integer type (INTEGER#)

Definition

A primitive type with distinguished values which are positive and negative whole numbers, including
zero (as a single value), having a fixed size in bits defined by the suffix #.

Encoding

The value shall be represented in binary 2’s complement.

When the carried value has a smaller size than the INTEGER# type, it shall be right-justified and
sign-extended to the left (if it is negative, with "1", otherwise, with "0").

102 556
OR
Appendices

INTEGER8 encoding

Offset 0 1 2 3 4 5 6 7
sign 2∧6 2∧5 2∧4 2∧3 2∧2 2∧1 2∧0

Range: -2∧7..2∧7-1

Example:

’1111 1110’B = -2

INTEGER16 encoding

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
sign 2∧14 2∧13 2∧12 2∧11 2∧10 2∧9 2∧8 2∧7 2∧6 2∧5 2∧4 2∧3 2∧2 2∧1 2∧0

Range: -2∧15..2∧15-1

INTEGER32 encoding

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
sign 2∧30 2∧29 2∧28 2∧27 2∧26 2∧25 2∧24 2∧23 2∧22 2∧21 2∧20 2∧19 2∧18 2∧17 2∧16
2∧15 2∧14 2∧13 2∧12 2∧11 2∧10 2∧9 2∧8 2∧7 2∧6 2∧5 2∧4 2∧3 2∧2 2∧1 2∧0
Offset 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Range: -2∧31..+2∧31-1

F.3.5 - Notation for the enumerated type (ENUM#)

Definition

A primitive type whose values are given distinct identifiers as part of the type notation. It has a fixed
size in bits defined by the suffix #.

Example:

Day_Of_WeeK_Typ::= ENUM4
{
MONDAY (1),
TUESDAY (2),
WEDNESDAY (3),
THURSDAY (4),
FRIDAY (5),
SATURDAY (6),
SUNDAY (7),
UNDEFINED (0)
}

Value "2" means "TUESDAY".

103 556
OR
Appendices

Encoding

Values of ENUM# shall be represented by an unsigned integer occupying the same place.

ENUM4 encoding

Offset 0 1 2 3
2∧3 2∧2 2∧1 2∧0

Range: 0..15

Example:

'0001'B means "MONDAY" in the above example.

ENUM8 encoding

Offset 0 1 2 3 4 5 6 7
2∧7 2∧6 2∧5 2∧4 2∧3 2∧2 2∧1 2∧0

Range: 0..255

Example:

'0000 0001'B means "MONDAY" in the above example (considering it is ENUM8 rather than ENUM4 .

F.3.6 - Notation for the unipolar types

Definition

Primitive types with distinguished values which are non-negative, whole numbers divided by a fixed
power of two, expressing a value in percent of a span.

NB: 1- The number before the comma gives the number of power of 2 forming the integer
part.
2- The epsilon factor is equal to the value of the smallest power of two in the word.

UNIPOLAR2.16 encoding

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
2∧1 2∧0 2∧-1 2∧-2 2∧-3 2∧-4 2∧-5 2∧-6 2∧-7 2∧-8 2∧-9 2∧-10 2∧-11 2∧-12 2∧-13 2∧-14
integrer fractional part
part

Span: 0..400% - Epsilon

104 556
OR
Appendices

F.3.7 - Notation for the bipolar types

Definition

Primitive types with distinguished values which are positive or negative, whole numbers (including
zero) divided by a fixed power of two, expressing a value in percent of a span.

NB: 1- The number before the comma gives the span in multiple of 100%.
2- The epsilon factor is equal to the value of the smallest power of two in the word.

Encoding

BIPOLAR2.16 Encoding

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
sign 2∧0 2∧-1 2∧-2 2∧-3 2∧-4 2∧-5 2∧-6 2∧-7 2∧-8 2∧-9 2∧-10 2∧-11 2∧-12 2∧-13 2∧-14
integrer fractional part
part

Span: -200%..+200% - Epsilon

BIPOLAR4.16 Encoding

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
sign 2∧2 2∧1 2∧0 2∧-1 2∧-2 2∧-3 2∧-4 2∧-5 2∧-6 2∧-7 2∧-8 2∧-9 2∧-10 2∧-11 2∧-12
integrer part fractional part

Span: -800%..+800% - Epsilon

F.3.8 - Notation for the character type

Definition

A primitive type whose distinguished values are members of the set of characters defined in ISO/IEC
8859-1 (see Bibliography - page 220).

Encoding

Visible characters shall be transmitted in one octet, without parity bit.

Offset 0 1 2 3 4 5 6 7
2∧7 2∧6 2∧5 2∧4 2∧3 2∧2 2∧1 2∧0

Example:

'01100001'B = character "a" according to ISO/IEC 8859-1.

105 556
OR
Appendices

F.3.9 - Notation for the Unicode character type

Definition

A primitive type whose distinguished values are members of the set of characters defined in IEC
10646 (see Bibliography - page 220).

Encoding

Visible characters shall be transmitted in two octets.

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
2∧15 2∧14 2∧13 2∧12 2∧11 2∧10 2∧9 2∧8 2∧7 2∧6 2∧5 2∧4 2∧3 2∧2 2∧1 2∧0

F.3.10 - Notation for the uncommitted types

Definition

An uncommitted type of undefined contents, but of fixed size.

Encoding

A variable of uncommitted type has no prescribed encoding.

Bits shall be named according to the power of two of a variable of UNSIGNED# type which would
occupy that place.

NB : this naming is not identical to the offset.

WORD8 encoding

Offset 0 1 2 3 4 5 6 7
2∧7 2∧6 2∧5 2∧4 2∧3 2∧2 2∧1 2∧0

WORD16 encoding

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

2∧15 2∧14 2∧13 2∧12 2∧11 2∧10 2∧9 2∧8 2∧7 2∧6 2∧5 2∧4 2∧3 2∧2 2∧1 2∧0

106 556
OR
Appendices

F.4 - Structured types

Five different structured types are defined:

RECORD (variable length),

ARRAY (fixed length or variable length),
BITSET# (fixed length),

F.4.1 - Notation for the record types

Definition

A structured type defined by referencing a fixed, ordered list of types; each value of the new type is
an ordered list of values, one from each of the component types.

NB : It is recommended to observe natural alignment when defining a RECORD, i.e. all elements
should be located at an offset with respect to the beginning of the record which is a multiple of
their size.

Encoding

Elements of a RECORD shall be transmitted in the order of their declaration.

Example:

A value of type TimeOfDay32 is represented as follows:

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Year
Dummy Month Day

TimeOfDay32::= RECORD
{
year INTEGER16,
dummy WORD4,
month UNSIGNED4,
day UNSIGNED8
}

"Dummy" was introduced to align the variable "day" on a 8-Bit word boundary.

107 556
OR
Appendices

F.4.2 - Notation for the bitset types

Definition

an ARRAY [#] of BOOLEAN1, occupying a fixed size of #.

Encoding

BITSET8 encoding

Offset 0 1 2 3 4 5 6 7
1st Bit 8th Bit

Range: 8-Bit set of Boolean

Example:

AccessType8::= BITSET8
{
system (0), -- this is the first bit of the set (MSB)
owner, (1),
group, (2),
world, (3),
reserved4 (4),
reserved5 (5),
reserved6 (6),
reserved7 (7) -- 8th or last bit of the set (LSB)
}

An UNSIGNED8 occupying that space with a value of '80'H means that "system" is the only member
of the set.

BITSET16 encoding

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1st Bit last Bit

Example:

AccessType ::= BITSET16 { system (0), owner (1), group (2), world (3)}.

Value '0110 0000 0000 0000'B means that "owner" and "group" are members of the set.

BITSET32 encoding

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Byte 1 1st Bit
Byte 2 last Bit
Offset 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

108 556
OR
Appendices

BITSET64 encoding

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Byte 0 1st Bit
Byte 2
Byte 4
Byte 6 last Bit

F.4.3 - Notation for the array type

Definition

A structured type, defined by referencing a single existing type; each value of the new type is an
ordered list of zero, one or more values of the existing type. The position of each value is identified by
an index. The number of values is indicated by either a constant or a field of the embedding structure.

The number or identifier specifies the size of the array in number of elements. Its type shall be
UNSIGNED Type. If an UNSIGNED type without a defined identifier is indicated, the array count is
located before the array elements begin.

Encoding

Arrays shall be transmitted in order of increasing index.

Multi-dimensional arrays shall be transmitted in the order their indices are listed.

NB : ARRAY OF [row, column] is transmitted row by row.

Arrays of octets (uncommitted contents, e.g. memory dump) shall be transmitted in increasing memory
address (or index) of the Application Memory.

All elements of the array shall be transmitted, even those which are not significant.

Example:

transmission of an octet memory dump.

DumpOctetType ::= ARRAY [array_count UNSIGNED16] OF WORD8.

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1st array_count (before the array structure)
... Octet at address M Octet at address M+1
.. Octet
Last Octet at address (M + array_count-2) Octet at address (M + array_count-1)

109 556
OR
Appendices

If the type were:

DumpOctetType ::= ARRAY [count] OF WORD8

the number of elements would be given by the field "count" located in the nesting data structure.

Example:

Same as above, but as a WORD16 memory dump. The array_elements are now half the value than
in the preceding case.

DumpWordType ::= ARRAY [array_count UNSIGNED16] OF WORD16.

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
first array_count (before the array structure)
... Word at address M
..
Last Word at address (M + array_count x 2 - 1)

F.5 - Natural alignment

Natural alignment is an attribute of a data item that refers to its placement:

- a primitive type is "naturally aligned at any position" that is a multiple of its length in octets
- a structure is "naturally aligned" when all members of the structure are naturally aligned.
To achieve this, reserved fields may have to be defined. Such fields have to be initialized with "0".

F.6 - Notation for the TIMEDATE48 type

Definition

A structured type expressing the absolute time in number of seconds since Universal Co-ordinated
Time (UTC), [Link], 1st January 1970 (Unix and ANSI-C format).

NB : This type is used for distribution of the actual time, event tagging and synchronisation.
Encoding

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
First seconds (most significant)
seconds (least significant)
Last ticks = 1/65536 second

Time can be represented to a granularity of 15,3 µs (=1/65536 s)

The precision of the fractional part shall be at least 10 bits.

110 556
OR
Appendices

Unused low order bits shall be set to zero.

Record of updates:

Version Date Change Reason for the change

001.01 01.11.2004 Change in the layout according to M1 New layout in accordance with
UIC guide M1
Adoption of a record of updates Increasing the usability
Adoption of a revision number Enhancement and redesign of the
versioning
001.02 01.08.2005 Change in the layout
UIC requirement
Renumbering of the Appendices

111 556
OR
Appendices

Appendix G - Homologation Procedure for Train Bus

Nodes (Version 001.01, valid from
01.08.2005)

G.1 - Foreword

This Appendix describes the formal homologation procedure that shall be applied to homologate train
bus nodes whose conformity to this Leaflet has been assessed according to the conformity test
described in Appendix H - page 116 .

Practical aspects and responsibilities are taken into account to clarify, simplify and accelerate the
homologation process.

G.2 - General prescriptions

The entities involved in the homologation procedure are:

1. UIC System Department;

2. UIC Steering Group Train Bus;

3. Homologated Test Laboratory;

4. Node Manufacturer.

All documents and letters exchanged among the previous entities shall be written in the English
language: the electronic transmission is allowed but the documents and letters must also be sent by
post.

At the end of this procedure, the complete set of issued documents and the exchanged
correspondence shall be provided, in electronic form, on a CD-rom to the UIC System Department and
to the UIC Steering Group Train Bus. The files shall be in Acrobat PDF format or others of similar
popularity.

G.3 - Procedure

The procedure for the homologation of a train bus node consists of the phases listed hereafter.

G.3.1 - Homologation request application to the homologated laboratory

The node manufacturer sends to the chosen homologated test laboratory all the preparatory docu-
ments which are:
1. A detailed description of the train bus node to homologate.

2. The test reports of the Manufacturer Configuration Conformance Testing according to point H.4.1
- page 123.
3. Test reports of all other tests carried out on the train bus node by the manufacturer.

112 556
OR
Appendices

4. Documentation regarding the testing of similar products already homologated, if applicable.

G.3.2 - Homologation request application to the UIC

Formal homologation procedure starts with a request submitted to the UIC System Department and to
the Secretary of the UIC Steering Group Train Bus. The contact details are specified in point G.4 -
page 114.

The application request shall contain at least the following information:

1. Details about the company, including a brief presentation of its activities in the railway communi-
cation market.
2. Responsible person for the homologation procedure at the manufacturer's complete with address.

3. The homologated laboratory chosen for the execution of the tests.

4. Preliminary time scheduling, already agreed with the test laboratory, for the set up phase and for
the test execution.

G.3.3 - Acknowledgement of the homologation request

Once the homologation request application has been received, the UIC Steering Group Train Bus
forwards it to the train bus experts according to the Steering Group Internal Regulation.

After examination of the completeness of the homologation request, the UIC Steering Group Train
Bus Secretary sends an acknowledgement of receipt of the homologation request to the manufacturer
and to the UIC System Department. This document contains the UIC contact person's address details
in accordance with the Steering Group Internal Regulation.

G.3.4 - Conformity test for the reference configuration TTC3

The manufacturer shall send the invitation for the execution of the above mentioned TTC3 test at least
3 weeks in advance to,
1. the chosen test laboratory, and
2. the contact person stated in point G.3.3.

In accordance to point H.4.2 - page 123, personnel of the Test Laboratory shall be present during the
tests.

G.3.5 - Conformity test for the reference configurations TTC1 and TTC2

The Manufacturer shall send the invitation for the execution of the above mentioned TTC1 and TTC2
tests at least 3 weeks in advance, to
1. the chosen test laboratory, and
2. the contact person stated in point G - page 112.

In general, the presence of at least 50% of the members of the Sub-Group of the UIC Steering Group
Train Bus responsible for the conformity tests is also necessary. Exceptions to this rule must be
accepted by the UIC Steering Group Train Bus President.

In case of failure of the tests, the whole phase described in this paragraph shall be repeated.

113 556
OR
Appendices

G.3.6 - Test report and homologation recommendation

In case of a positive test result, the Test Laboratory forwards a comprehensive test report to the UIC
System Department and to the UIC Steering Group Train Bus.

This report shall include detailed information on:

1. the setting up of the laboratory,

2. the results of the tests, including all the detailed outputs of the test bed according to point H.6 -
page 125,

3. the minutes of the test session, signed by the participants.

The UIC contact person provisionally certifies that the node is homologated.

All the documentation produced and the correspondence exchanged must be archived by the Test
Laboratory, by the UIC System Department and by the UIC Steering Group Train Bus.

G.3.7 - Homologation

Once the conformity test is passed, the procedure is concluded and the UIC Steering Group Train Bus
ratifies the certification of homologation of the node given in point G.3.6 and a new edition of
Appendix I - page 214 including that node is issued.

G.4 - Contact details

Addresses of the UIC entities involved in the homologation procedure:

G.4.1 - UIC System Department, UIC Steering Group Train Bus

UIC - International Union of Railways

System Department
16, rue Jean Rey
F-75015 Paris
Tel. +33 1 44 49 20 20
Fax +33 1 44 49 20 29
Internet: [Link]

UIC - International Union of Railways

Secretary of Steering Group Train Bus
16, rue Jean Rey
F-75015 Paris
Tel. +33 1 44 49 20 20
Fax +33 1 44 49 20 29
Internet: [Link]

114 556
OR
Appendices

G.4.2 - Homologated Laboratories

The list of the homologated laboratory is to be found on the UIC-Website ([Link]

Technical and Research/Products/Catalogue of products technically approved by UIC/train bus.

Record of updates

Version Date Change Reason for the

change
001.01 01.08.2005 Change in the layout
UIC requirement
Renumbering of the Appendices

115 556
OR
Appendices

Appendix H - Conformance testing (Version 001.02, valid

from 01.08.2005)

H.1 - Definitions

The following terms are used in this Appendix with a special meaning which is given hereinafter.

UIC 556 Node

This is, at least one WTB device compliant to IEC Standard 61375-1. The vehicle bus interface and
the gateway functionality are not mandatory, nevertheless, when existing, they may be helpful to
attach the tester device. Note that this definition is quite different from the definition given by IEC
61375-1 that defines a node as a gateway between WTB and MVB.

Key position

This is a position of the node within the test train composition that is believed to be highly significant
for the test coverage.

Reference Node

The Reference Node (ref) is a node that is already homologated according to this Appendix.

Device under Test (DuT)

This is a node that is under test with the aim to be homologated according to this Appendix. The Device
under Test (DuT) shall have already passed the Manufacturer Configuration Conformance Testing as
stated by the Certification Statement given by the manufacturer.

Ref Position

This is a position of the node within the test train composition that has to be hold by a reference node
during the execution of the Reference Configuration Conformance Testing.

DuT Position

This is a position of the node within the test train composition that has to be hold by a node under test
during the execution of the Reference Configuration Conformance Testing.

Qualitative Result

The qualitative result of a test case is PASSED or NOT PASSED respectively if the checks do or do
not match the contents of such checks reported in the table Test Sequence of the test case.

Quantitative Result

The quantitative result of a test case are values measured according to the request of the test
sequence of that test case.

116 556
OR
Appendices

TTC (Testing Train Configuration)

The Testing Train Configuration is an important issue in order to reach the required coverage of the
test nad to run the test in a condition that is believed to be close to the condition of the actual
exploitation. Three different Testing Train Configuration are used called TTC1, TTC2 TTC3.

Standard Addresses

The result of the computation of an actual full configuration with unknown master node occurs
frequently and is therefore called "standard addresses", this sentence may appear in the column
called "expected configuration" in the table reporting the test sequence.

H.2 - General

H.2.1 - Scope

A UIC 556 node is an equipment designed according to IEC Standard 61375-1 providing at least the
WTB interface and the ability to run the relevant protocols and the application profile specified by UIC
Leaflet 556; the MVB interface is not strictly required, nevertheless the term UIC 556 node may
indicate also a TCN gateway or any other gateway between WTB and the relevant vehicle bus.

The scope of this document is to provide a UIC Conformance Testing procedure that defines the test
conditions and the test steps and gives the requirements of the test bed.

UIC 556 conformance testing provides the means of:

- assuring at a convenient coverage that a UIC node complies with the UIC 556 specification;

- facilitating interoperability between different UIC 556 nodes and between vehicles in which such
equipment is installed.

The interoperability issues which are covered include interfaces between vehicles relevant to the train
bus and do not include the interfaces between equipment relevant to the vehicle bus.

H.2.2 - Levels of Conformity

Two different levels of conformance testing are distinguished:

- Manufacturer Configuration Conformance Testing: it is requested when vehicles in the train

are equipped with UIC 556 nodes of the same manufacturer. This level of conformance is a
prerequisite to the Reference Configuration Conformance. For this first level, it is the responsibility
of UIC 556 node manufacturers or system integrators to actually implement the conformance tests
and to develop suitable testers where necessary.

- Reference Configuration Conformance Testing: it is requested when trains are equipped with
UIC 556 nodes from different manufacturers and must be interoperable in their normal operation.
For this level of conformance, it is necessary to qualify a UIC 556 node as a UIC approved node
and it is the responsibility of UIC to actually implement the conformance tests and to develop
suitable testers.

117 556
OR
Appendices

Complete interoperability requires not only that vehicles or equipment can correctly communicate
between each other, but also that they are able to sustain the UIC Leaflet 556 defined traffic with
adequate performance; for this reason both levels of Conformance Testing include some test cases
that have the aim to check and validate:

- some UIC 556 special functionalities (like sleep mode)

- some UIC 556 performance characteristics (like inauguration time and node redundancy
switch-over).

H.2.3 - Entities

The entities involved in order to run the UIC Conformance Testing are the following:

- UIC Node: it may be a node under test or a reference node, both are equipped with the software
that implements the TCN Stack and the UIC Stack.

- TCN Stack Software: this is the software that implements the protocols according to
IEC Standard 61375-1.

- UIC Stack Software: this is the software that implements the protocols according to UIC
Leaflet 556.

- UIC tester: this is an equipment to be attached to the UIC node in order to stimulate the execution
of the test cases and/or to record the test cases results. To perform such a task the UIC tester is
equipped with a UIC simple testing application.

- Simple testing application: this is the software that implements the protocols according to
IEC Standard 61375-1.

H.2.4 - Coverage Boundaries and Limitations

The boundaries of the UIC Conformance Testing are the following:

- Lower Boundary: the coverage of the UIC Conformance Testing is limited by the coverage of the
TCN Conformance Testing; consequently the TCN conformance is not a UIC Conformance
Testing issue but it is a pre-requisite which has to be already achieved before the UIC
conformance is issued.

- Upper Boundary: the coverage of the UIC Conformance Testing is limited to a simple testing
application that is provided by the UIC 556 node manufacturer for the purpose of running the UIC
Conformance Testing. Such a simple testing application shall be compliant to the test cases as
they are defined and described in this document. The conformity of any UIC 556 application is
beyond the scope of the UIC 556 Conformance Testing.

118 556
OR
Appendices

H.3 - Train configurations

Different Train Configurations are used to run the UIC Conformance Testing as reported by Table 7;
each configuration is dedicated to a set of test cases. The column NRN reports the number of non
redundant nodes.

The most used configuration is the TTC1 which, for this reason, is called Reference Configuration.

Table 7 : Testing Train Configurations

Short Form Test Cases number of number number of
ID vehicles of non redundant
redundant nodes
nodes
TTC1 ♦ Confirmed compositions test suite 7 6 3
• Confirmation, correction and reset of train
compositions
• Loss and integration of intermediate nodes
• Loss and integration of end nodes for
confirmed compositions
• Lengthening of confirmed compositions
• Coupling of two confirmed compositions

• Setting the vehicle number for seat

reservation

♦ UIC redundancy test suite

• Redundancy switch-over for unconfirmed
compositions
• Redundancy switch-over for confirmed
compositions
♦ Unconfirmed compositions test suite;
♦ Leading vehicle test suite;
♦ Inhibit functionality test suite;
♦ Group telegrams test suite;
♦ E telegram error handling test suite;
♦ Sleep mode test suite
TTC2 ♦ Unconfirmed compositions test suite (applied to 22 7
trainsets of all possible lengths)
TTC3 ♦ UIC redundancy test suite 22 22 1a
• Duration of redundancy switch-over
♦ Performance test suite
• Duration of UIC Inauguration
Single DuT ♦ Performance test suite not 1
applicable
• Power consumption
a. one node shall be redundant in order to measure the redundancy switch-over time.

119 556
OR
Appendices

H.3.1 - Testing Train Configurations

Fig. 11 shows the Testing Train Configuration TTC1 where the following vehicles are represented:

- vehicle A is a locomotive equipped with a redundant node;

- vehicle B is a coach equipped with a single node;

- vehicle C is a steering coach;

- vehicle D is part of a trainset and it is equipped with a redundant node;

- vehicle E is part of a trainset, no node;

- vehicle F is part of a trainset, no node;

- vehicle G is a steering coach equipped with two nodes, one single node and one redundant node.

A B C D E F G

Fig. 11 - Testing Train Configuration TTC1

Table 8 : TTC1 - Identification of key positions, ref positions,

DuT positions and properties
Vehicle position A B C D E F G1 G2

Key positions K K K K K

Regular test cases

1st test run Ref DuT Ref Ref DuT DuT

2nd test run DuT Ref DuT DuT Ref Ref

All redundancy tests K K K K

1st test run Ref DuT Ref Ref DuT DuT

2nd test run DuT Ref DuT DuT Ref Ref

Orientation ← → → ← → →
Trainset properties 38, 44, --- 44, 45 39, 44 % % --- 44, 45
45, 45, 50
49

Vehicle properties 42, 141 1, 141 2, 42, 141 1, 42, 141 2 2, 42 2, 141 42, 141

120 556
OR
Appendices

H.3.2 - Testing Train Configuration 2

Fig. 12 shows the Testing Train Configuration TTC2 where the following vehicles are represented:

- vehicle A to E is a trainset equipped with a single node (group of vehicles);

- vehicle F to H is a trainset equipped with a single node;

- vehicle I is a locomotive equipped with a single node;

- vehicle J to K is a trainset equipped with a single node;

- vehicle L to M is a trainset equipped with a single node;

- vehicle P to U is a trainset equipped with a single node;

- vehicle V is a locomotive equipped with a single node;

A B C D E F G H I J K L M N O P Q R S T U V

Fig. 12 - Testing Train Configuration TTC2

Table 9 : TTC2 - Identification of key positions, ref positions,

DuT positions and properties
Vehicle position Trainset Trainset Vehicle I Trainset Trainset Trainset Vehicle V
A/E F/H J/K L/O P/U

All test cases

1st test run DuT Ref DuT Ref DuT Ref DuT

2nd test run Ref DuT Ref DuT Ref DuT Ref

Vehicle properties C: 141 F: 141 141 J: 141 L: 42, U: 42, 141 141
M: 141,
O: 42

Orientation ← → →

Trainset properties 38, 44, 39, 44, 45,

45, 49, 50,

121 556
OR
Appendices

H.3.3 - Testing Train Configuration 3

This Testing Train Configuration is dedicated to the performance measurement.

Although the performance, like inauguration time, is a characteristic that shall be assured in the
maximum configuration (it means 22 vehicles with 32 nodes), practical reasons lead to use a reduced
configuration that seems, nevertheless, to be significant.

Such configuration contains 22 vehicles and 22 single node.

The configuration shall be implemented in such a way that it is possible to measure the relevant
characteristics with shortened configuration of 10 and 16 nodes in order to list a table of the
characteristics themselves.

As an example if the inauguration time is measured, the result will be three inauguration times relevant
to 10, 16 and 22 nodes.

The value relevant to 22 nodes shall be less than 1.4 second while the values relevant to 10 and 16
nodes are to be considered indicative of the inauguration time versus the number of the nodes in the
composition.

Figure 13 shows the Testing Train Configuration TTC3 where the following vehicles are represented:

- vehicle A is a locomotive equipped with a redundant node;

- vehicles B to U are coaches equipped with a single node;

Fig. 13 - Testing Train Configuration TTC3

Table 10 : TTC3 - Identification of key positions, ref positions,

DuT Positions and properties
Vehicle position A B C-U

Key positions K K K

Regular test cases DuT Ref DuT

All redundancy tests DuT Ref DuT

Orientation ← ← ←

Trainset properties 38, 44, 45,49

Vehicle properties 43, 141 141 141

122 556
OR
Appendices

H.4 - Guidelines to conformance testing execution

H.4.1 - Manufacturer Configuration Conformance Testing

The Manufacturer Configuration Conformance Testing is executed by the manufacturer in his own
laboratory.

The testing train compositions to be used are TTC1, TTC2 and TTC3.

All test cases shall be executed using DuT produced by the manufacturer. The key positions are
intrinsically covered.

The manufacturer shall compile a test report that identifies:

- the nodes that were submitted to the testing;

- the qualitative results and the quantitative results, if any, of each test step.

The manufacturer shall keep the DuT nodes and eventually use them for the Reference Configuration
Conformance Testing.

H.4.2 - Reference Configuration Conformance Testing

The Reference Configuration Conformance Testing is executed in a laboratory that is homologated

according to the rules specified in point 8.3 - page 32 .

There are two types of nodes which may be homologated

- non-redundant UIC 556 nodes,

- redundant UIC 556 nodes.

In order to run the test, the manufacturer shall provide:

TTC1 TTC2 TTC3

non-redundant UIC 556 nodes 3 4 21
redundant UIC 556 nodes 1+2 - 20 + 1

The nodes shall have been submitted by the manufacturer himself to the homogeneous configuration
conformance test and a certification statement, declaring that the test was passed, shall be provided.

The Reference Configuration Conformance Testing is performed using the TTC1, TTC2, and TTC3
test composition, as well as the devices under Test (DUT) and Reference nodes that shall be already
homologated according to point 8 - page 32.

The relevant test cases with TTC1 and TTC2 shall be executed twice, each time is called a run.

The first run is executed with the Ref nodes and the DuT nodes in the positions specified by the
Tables 8 - page 120 and 9 - page 121 then, during the second run, the positions hold by the Ref nodes
are hold by the DuT nodes and vice versa.

123 556
OR
Appendices

For practical reasons, the relevant test cases with TTC3 are executed at the Manufacturer's location
with in presence of the personnel of the homologated laboratory.

H.5 - Test bed

The test bed is implemented by the relevant Testing Train Configuration that shall support the
following manipulations in the Testing Train Configuration itself:

- coupling and uncoupling of nodes;

- turning on and off of nodes;

- redundancy switching over.

Furthermore it is necessary to attach the UIC Tester to the relevant node that has to perform the action
as it is specified in the test sequence described in point H.6.1 - page 125.

The UIC Tester and a Line Monitor, when necessary, are needed in order to log the results of the action
and check them for the qualitative and quantitative aspects.

It is not required that the DuT and the Ref node have exposed interfaces dedicated to the purpose of
the test, the existing WTB and MVB interfaces are sufficient and the UIC Tester is believed to be
normally attached to the MVB interface of the relevant node that causes the action or, when the MVB
bus is not used by the node, to the application interface of the node itself.

The monitoring and logging of the results is performed by instrumentation devices attached to the
WTB and/or MVB interface (this may be the UIC Tester itself if it provides this possibility).

Nevertheless, if the node provides a service interface, this interface may be used to provide the
logging data to a PC unit.

In order to reduce the testing cost and the total duration of the testing, a full automation of the testing
sequences is suggested but not required.

Full automation also has the advantage of reducing the number of human errors and obtaining an
automatic print-out of the results and checks.

The main areas to be automated are:

- the coupling and uncoupling of the WTB connection between the nodes of the Testing Train
Configuration in order to control by means of the UIC Tester the shortening and the lengthening
of the configuration;

- the switching on and off of the nodes in order to control by means of the UIC Tester the simulation
of the node failure and node re-insertion;

- the switching-over of the redundant node in order to control in a precise and simultaneous way
the taking over of the redundant node.

124 556
OR
Appendices

H.6 - Test suites

H.6.1 - Guidelines to test case interpretation and execution

The test cases are grouped and each group is reported in one paragraph of this document; the
grouping criteria are to test homogeneous features specified by the UIC Leaflet 556 such
homogeneous features are listed in the paragraph title of the test group itself.

Each paragraph is structured in the following topics:

Purpose:

This is a synopsis highlighting the main aims of the test cases group.

Reference to UIC 556:

The references to the relevant points of UIC Leaflet 556 are listed, where the characteristics that are
tested by the test cases reported in the test sequence are specified.

Train composition:

Here is specified which testing train compositions are used to run the test cases.

NB : This topic reports, if any, all the specific notes that may be useful to better understand the test
cases.
Test sequence:

The test sequence is given in a table where the test cases are listed in the order in which they shall
be executed.

The table has five columns: step, action, expected results, checks, expected configuration.

The meaning of each column is listed hereinafter:

- the first column is the test step number;

- the second column describes which action shall be done on the testing configuration in order to
generate stimuli;
- the third column describes the qualitative and quantitative results which are the consequences of
the action and shall be observed and logged;

- the forth column describes which parameters, data on the bus and/or events shall be checked;
- the fifth column describes, possibly graphically, the train configuration that is expected to be
verified in the NADI with particular reference to the TCN and UIC numbering.

125 556
OR
Appendices

Graphic Symbols:

Hereinafter graphic symbols and their meanings are shown as they appear in the fifth column of the
test sequence table.

B
00

Fig. 14 - Vehicles with unknown UIC adress 00

(a vehicle which cannot be integrated into a confirmed composition)

gap
02

Fig. 15 - confirmed missing vehicle with UIC adress 02

(a vehicle which has not been present during correction/confirmation)

missing
04

Fig. 16 - unconfirmed missing vehicle with UIC adress 04

(a vehicle which was present during correction/confirmation)

The following explanations are relevant to the operation mode of nodes:

- TCN adresses are preceded by T, UIC adresses are preceded by U.

H.6.2 - List of Test Cases

The following is a list of test cases which should be covered by both the Manufacturer Conformance
Test and the Reference Conformance Test.

1. Confirmed compositions test suites

• Confirmation, correction and reset of train compositions

• Loss and integration of intermediate nodes
• Loss and integration of end nodes for confirmed compositions
• Lengthening of confirmed compositions
• Coupling of two confirmed compositions
• Setting the vehicle number for seat reservation

126 556
OR
Appendices

2. UIC redundancy test suites

• Redundancy switch-over for unconfirmed compositions

• Redundancy switch-over for confirmed compositions
• Duration of redundancy switch-over

3. Performance test suite

• Duration of UIC inauguration

• Power consumption

4. Unconfirmed compositions test suites

• applied to TTC1
• applied to trainsets of all possible lengths
5. Leading vehicle test suites
6. Inhibit functionality test suites
7. Group handling test suites (B001…B006)
8. E telegram error handling test suites
9. Sleep mode test suites

H.6.3 - Description of test suites

H.6.3.1 - Confirmed compositions test suites

Purpose:

Test the features for confirmed compositions, especially

- confirmation, correction and reset of train compositions;
- loss and integration of intermediate nodes;
- loss and integration of end nodes;
- lengthening of confirmed compositions;
- coupling of two confirmed compositions;
- setting the vehicle number for seat reservation.

Additionally, test the following additional features of leading requests for a confirmed composition

- ignore a leading request from a vehicle with unknown UIC address.

127 556
OR
Appendices

NB : For computing the composition, the following rules are applied to the first 4 test cases:

Test case 0 0 0 0
rule "a" 3, 6 8, 9, 10, 11, 19 2, 3, 6, 11
rule "b" 12, 26
rule "c" 2, 4, 5, 7, 8, 9 2, 4, 6, 7, 15, 4, 5, 7, 12, 13,
17, 18, 22, 24, 14, 5
25
no inversion 8, 9, 10 3, 4

H.[Link] - Confirmation, correction and reset of train compositions.

Purpose:

Test the correct handling of correction and confirmation E telegrams:

test steps
• NADI confirmation 2
• NADI correction 5
• NADI invalidation 8
• incomplete distribution of correction information 9
• change of the leading vehicle 3, 4, 6, 7

Reference to UIC 556:

Point 5.1 - page 10 operational mode: INAUGURATION/REGULAR

Point C - page 37 description of algorithm
Point C.2.5 - page 65 UMS user services / E telegrams:
Appendix A - page 35, No 15.02 write_correction: UIC_FC_CORRECTION
Appendix A - page 35, No 15.01 UIC_FC_DELETE_CONFIG
Appendix A - page 35, No 15.07 multicast_create: UIC_FC_MULTICAST_CREATE
Point C.2.8 - page 82 Leading: (local)
Point C.[Link] - page 71 correction handling

Train composition:

TTC1 defined in Point H.3.1 - page 120. The key positions are the train bus nodes of vehicles A, C,
D/E/F and G.

NB : Nothing to note.

128 556
OR
 Test sequence:
Step Action Expected result Checks Expected configuration

1 turn A - G on TCN/UIC inauguration with A - G: • unconf. NADI (8 entries)

ordering according to rule "c"
Appendices

• no leading vehicle A B C D E F G
01 02 03 04 05 06 07

2 confirm ordering UIC inauguration with A - G: • inauguration data (A - G: "UIC adress set") see above
ordering according to rule "c"
• conf. NADI (8 entries)
• no leading vehicle
3 set leading request UIC inauguration with A - G: • inauguration data (A - G: "conf. configuration",
on G2 in direction 1 ordering according to rule "a" info on conf. configuration;
G2: requests leading in direction 1) A B C D E F G
07 06 05 04 03 02 01
• conf. NADI (8 entries)

• leading vehicle = 01

129
4 reset leading request UIC inauguration with A - G: • inauguration data (A - G: "conf. configuration",
on G2 ordering according to rule "c" info on conf. configuration)
A B C D E F G
01 02 03 04 05 06 07
• conf. NADI (8 entries)
• no leading vehicle
5 correct ordering UIC inauguration with A - G: • inauguration data (A - G: "UIC address set",
with A, B, ordering according to rule "c" info on conf. configuration)
gap, C, D, E, F, G A B gap C D E F G
• conf. NADI (9 entries) 01 02 03 04 05 06 07 08

• no leading vehicle
6 set leading request UIC inauguration with A - G: • inauguration data (A - G: "conf. configuration",
on G2 in direction 1 ordering according to rule "a" info on conf. configuration;
G2: requests leading in direction 1) A B gap C D E F G
08 07 06 05 04 03 02 01
• conf. NADI (9 entries)
• leading vehicle G2 = 01

556
OR
 Step Action Expected result checks Expected configuration

7 reset leading UIC inauguration with A - G: • inauguration data (A - G: "conf. configuration",

request on G2 ordering according to rule "c" info on conf. configuration);
A B gap C D E F G
• conf. NADI (9 entries) 01 02 03 04 05 06 07 08
Appendices

• no leading vehicle

8 invalidate ordering UIC inauguration with A - G: • inauguration data (A - G1: "conf. configuration",
on vehicle G2 ordering according to rule "c" info on conf. configuration;
G2: "delete conf. configuration") A B C D E F G
01 02 03 04 05 06 07
• unconf. NADI (8 entries)
• no leading vehicle

9 confirm ordering on UIC inauguration with A - G: • inauguration data (A: "UIC address set") see above
A only and enforce ordering according to rule "c"
a UIC inauguration • unconf. NADI (8 entries)

130
• no leading vehicle

556
OR
Appendices

H.[Link] - Loss and integration of intermediate nodes

Purpose:

Test the correct handling of correction and confirmation for intermediate nodes with:

Test steps

• node failure 3, 5, 16, 23

• successful node reinsertion 4, 8, 17, 18, 24, 25, 26
• failed node reinsertion 6, 11
• change of the leading vehicle 8, 19, 26

and the correct handling of leading requests for confirmed compositions with

• setting the leading property for an intermediate vehicle with 7, 8

unknown UIC address
• leading vehicle conflict resolution 9, 10, 11
(case one vehicle was and requests leading and another one
requests leading)

Reference to UIC 556:

Point 5.1 - page 10 operational mode: INAUGURATION/REGULAR

Point 6.2 - page 27 Failure tolerance
Point C.1.3.5 - page 47 Description of algorithm: node, failure, node insertion, unknown
nodes
Point C.2.5 - page 65 UMS user services / E-telegrams:
Appendix A - page 35, No 15.02 write_correction: UIC_FC_CORRECTION
Appendix A - page 35, No 15.07 multicast_create: UIC_FC_MULTICAST_CREATE
Point C.2.8 - page 82 leading: (local)
Point C.[Link] - page 71 correction handling

Train composition:

TTC1 defined in point H.3.1 - page 120. The key positions are the train bus nodes of vehicles C, D/E/F
and G (1st node).

NB : Nothing to note.

131 556
OR
 Test sequence

Step Action expected result Checks Expected configuration

1 turn A, C - G on TCN/UIC inauguration with A, C - G: • unconf. NADI (7 entries)

Appendices

with master A ordering according to rule "c"

• no leading vehicle A C D E F G
01 02 03 04 05 06

2 correct ordering UIC inauguration with A, C - G: • inauguration data (A, C - G: "UIC address set";
with A, ordering according to rule "c" info on conf. configuration)
gap, C, D, E, F, G A gap C D E F G
• conf. NADI (8 entries) 01 02 03 04 05 06 07

• no leading vehicle
3 turn C off no UIC inauguration • Topography (counter not changed) see above
(TCN master at A)
• NADI unchanged
4 turn C on UIC inauguration with A, C - G: • inauguration data (A, D - G: "conf. configuration", see above
ordering according to rule "c" info on conf. configuration;

132
(Position of C can be C: no info on conf. configuration)
determined)
• conf. NADI (8 entries)
• no leading vehicle
5 turn C and no UIC inauguration • Topography (counter not changed) see above
D/E/F off (TCN master at A)
• NADI unchanged
6 turn C on TCN/UIC inauguration with A, C, G: • inauguration data (A, G: "conf. configuration",
ordering according to rule "c" info on conf. configuration;
(position of C cannot be determined) C: no info on conf. configuration) A C gap missing missing missing missing G
01 00 02 03 04 05 06 07
• conf. NADI (9 entries; missing +
unknown vehicle)
• no leading vehicle

556
OR
 Step Action Expected result checks Expected configuration

7 set leading request UIC inauguration with A, C - G: • inauguration data (A, G: "conf. configuration", see above
on C in direction 1 ordering according to rule "c" info on conf. configuration;
(position of C cannot be C: no info on conf. configuration,
determined) requests leading in direction 1)
Appendices

(C has unknown UIC address)

• conf. NADI (9 entries;
missing + unknown veh.)
• no leading vehicle
8 set leading request UIC inauguration with A, C - G: • inauguration data (A, G: "conf. configuration",
on G2 in direction 1 ordering according to rule "a" info on conf. configuration;
(position of C cannot be C: no info on conf. configuration,
A gap missing missing missing missing C G
determined) requests leading in direction 1; 07 06 05 04 03 02 00 01
(C has unknown UIC address) G2: requests leading in direction 1)
• conf. NADI (9 entries;
missing + unknown veh.)
• leading vehicle G2 = 01
9 turn D/E/F on TCN/UIC inauguration with A, C - G: • inauguration data (A, G: "conf. configuration",

133
ordering according to rule "a" info on conf. configuration;
(position of C, D/E/F can be C - F: no info on conf. configuration;
determined) C: requests leading in direction 1; A gap C D E F G
07 06 05 04 03 02 01
G2: was and requests leading in direction 1)

• conf. NADI (8 entries)

• leading vehicle G2 = 01
10 correct ordering with UIC inauguration with A , C - G: • inauguration data (A, C - G: "UIC adress set", see above
A, gap, C, D, E, F, G ordering according to rule "a" info on conf. configuration;
C: requests leading;
G2: was and requests leading in direction 1)
• conf. NADI (8 entries)
• leading vehicle G2 = 01

556
OR
 Step Action Expected result Checks Expected configuration

11 turn B on TCN/UIC inauguration • inauguration data (A, C - G:

with A - G ordering "conf. configuration",
according to rule "a" info on conf. configuration;
A gap B C D E F G
(position of B cannot be B: no info on conf. configuration; 07 06 00 05 04 03 02 01
Appendices

determined) C: requests leading in direction 1;

G2: was and requests leading in direction 1)
• conf. NADI (9 entries)

• leading vehicle G2 = 01
12 reset leading request on G2 TCN/UIC inauguration • inauguration data (A, C - G: "
with A - G ordering conf. configuration",
according to rule "b" info on conf. configuration;
A B gap C D E F G
(position of B cannot be B: no info on conf. configuration; 01 00 02 03 04 05 06 07
determined) C: requests leading in direction 1)

• conf. NADI (9 entries)

• leading vehicle C = 03

134
13 turn off

14 switch A - G on TCN/UIC inauguration • unconf. NADI (8 entries)

with master at A with A - G:
A B C D E F G
ordering according to rule "c" • no leading vehicle 01 02 03 04 05 06 07

15 Confirm ordering UIC inauguration with A - G: • inauguration data (A - G: "UIC adress set") see above
ordering according to rule "c"
• conf. NADI (8 entries)

• no leading vehicle
16 turn D/E/F no UIC inauguration • Topography (counter not changed) see above
and G1 off (TCN master at A)
• NADI unchanged
17 turn D/E/F on TCN/UIC inauguration • inauguration data (A - C, G2:
A - F, G2: ordering "conf. configuration",
according to rule "c" info on conf. configuration;
A B C D E F G
(position of D/E/Fcan be D/E/F: no info on conf. configuration) 01 02 03 04 05 06 07
determined) • conf. NADI (7 entries)

• no leading vehicle

556
OR
 Step Action Expected result Checks Expected configuration

18 turn G1 on TCN/UIC inauguration A - G: • inauguration data (A - F, G2: "conf. configuration",

oredering according to rule "c" info on conf. configuration;
(position of G1 can be G1: no info on conf. configuration) A B C D E F G
determined) 01 02 03 04 05 06 07
Appendices

• conf. NADI (8 entries)

• no leading vehicle
19 set leading request UIC inauguration with A - G: • inauguration data (A - G: "conf. configuration",
on G2 in direction 1 ordering according to rule "a" info on conf. configuration;
G2 requests leading in direction 1)
A B C D E F G
07 06 05 04 03 02 01
• conf. NADI (8 entries)
• leading vehicle G2 = 01
20 turn off

21 turn A - G on TCN/UIC inauguration with A - G: • unconf. NADI (8 entries)

with master at A ordering according to rule "c"
• no leading vehicle A B C D E F G

135
01 02 03 04 05 06 07

22 Confirm ordering UIC inauguration with A - G: • inauguration data (A - G: see above

ordering according to rule "c" "UIC adress set")

• conf. NADI (8 entries)

• no leading vehicle
23 turn D/E/F no UIC inauguration • Topography (counter not changed) see above
and G1off (TCN master at A)
• NADI unchanged
24 turn G1 on TCN/UIC inauguration A - C, G: • inauguration data (A - C, G2: "conf. configuration",
ordering according to rule "c" info on conf. configuration;
(position of G1 can be G1: no info on conf. configuration)
A B C missing missing missing G
determined) 01 02 03 04 05 06 07
• conf. NADI
(8 entries; missing veh.)
• no leading vehicle

556
OR
 Step Action Expected result Checks Expected configuration

25 turn D/E/F on TCN/UIC inauguration A - G: • inauguration data (A - C, G: "conf. configuration",

ordering according to rule "c" info on conf. configuration;
(position of D/E/F can be D/E/F: no info on conf. configuration) A B C D E F G
determined) 01 02 03 04 05 06 07
Appendices

• conf. NADI (8 entries)

• no leading vehicle
26 set leading request UIC inauguration A - G: • inauguration data (A - G: "conf. configuration",
on F (direction 2) ordering according to rule "b" info on conf. configuration;
D/E/F: requests leading in direction 1) A B C D E F G
07 06 05 04 03 02 01
• conf. NADI (8 entries)

• leading vehicle F = 02

136
556
OR
Appendices

H.[Link] - Loss and integration of end nodes for confirmed compositions

Purpose:

Test the correct handling of confirmed compositions for end nodes with:
Test steps

• node failure 4, 8
• successful node reinsertion 5
• failed node reinsertion 9
• change of the leading vehicle 6, 7, 11

and the correct handling of leading requests for confirmed compositions with:

• setting the leading property for an end vehicle with unknown 10, 15
UIC address

Reference to UIC 556:

Point 5.1 - page 10 operational modes: INAUGURATION/REGULAR

Point 6.2 - page 27 failure tolerance
Point C.1.3.5 - page 47 description of algorithm
Point C.2.5 - page 65 UMS user services / E-Telegrams:
Appendix A - page 35, No 15.02 write_correction: UIC_FC_CORRECTION
Appendix A - page 35, No 15.07 multicast_create: UIC_FC_MULTICAST_CREATE
Point C.2.8 - page 82 leading: (local)
Point C.[Link] - page 71 correction handling

Train composition:

TTC1 as defined in point H.3.1 - page 120. The key positions are the train bus nodes of vehicles A
and G2.

NB : Nothing to note.

137 556
OR
 Test sequence

Step Action Expected result Checks Expected configuration

1 turn A - G on TCN/UIC inauguration with A - G: • unconf. NADI (8 entries)

Appendices

with master at A ordering according to rule "c"

A B C D E F G
• no leading vehicle 01 02 03 04 05 06 07

2 set leading request UIC inauguration with A - G: • inauguration data (G2: requests leading
on G2 in direction 1 ordering according to rule "a" in direction 1))
A B C D E F G
• unconf. NADI (8 entries) 07 06 05 04 03 02 01

• leading vehicle G2 = 01
3 Confirm ordering UIC inauguration with A - G: • inauguration data (A - G: "UIC address set"; see above
ordering according to rule "a" G2: was and requests leading in direction 1)

• conf. NADI (8 entries)

• leading vehicle G2 = 01

138
4 turn G2 off TCN/UIC inauguration with A - G1: • inauguration data (A - G1: "conf. configuration",
ordering according to rule "c" info on conf. configuration)
A B C D E F G
• [Link] (7 entries) 01 02 03 04 05 06 07

• no leading vehicle
5 turn vehicle G2 on TCN/UIC inauguration with A - G: • inauguration data (A - G1: "conf. configuration",
ordering according to rule "c" info on conf. configuration;
G2: no info on conf. configuration)
A B C D E F G
01 02 03 04 05 06 07
• conf. NADI (8 entries)
• no leading vehicle
6 set leading request UIC inauguration with A - G: • inauguration data (A - G: "conf. configuration",
on G2 in direction 1 ordering according to rule "a" Info on conf. configuration;
G2: requests leading in direction 1)
A B C D E F G
07 06 05 04 03 02 01
• conf. NADI (8 entries)
• leading vehicle G2 = 01

556
OR
 Step Action Eexpected result Checks Expected configuration

7 reset leading UIC inauguration with A - G: • inauguration data (A - G: "conf. configuration",

request on G2 ordering according to rule "c" info on conf. configuration)
A B C D E F G
• conf. NADI (8 entries) 01 02 03 04 05 06 07
Appendices

• no leading vehicle
8 turn A off TCN/UIC inauguration with B - G: • inauguration data (B - G: "conf. configuration",
no inversion of ordering info on conf. configuration)
(rules a - c cannot be applied
missing B C D E F G
• conf. NADI (8 entries; missing veh.) 07 06 05 04 03 02 01

• no leading vehicle

9 turn A on TCN/UIC inauguration with A - G: • inauguration data (B - G: "conf. configuration",

no inversion of ordering info on conf. configuration;
(rules a - c cannot be applied) A: no info on conf. configuration)
missing A B C D E F G
07 00 06 05 04 03 02 01
• conf. NADI (9 entries;

139
missing + unknown veh.)

• no leading vehicle
10 set leading request UIC inauguration with A - G: • inaugration data (B - G: "conf. configuration", see above
on A in direction 1 no inversion of ordering info on conf. configuration;
(A has unknown UIC address; A: no info on conf. configuration,
rules a - c cannot be applied) requests leading in direction 1)
• conf. NADI (9 entries;
missing + unknown veh.)

• no leading vehicle
11 confirm ordering UIC inauguration with A - G: • inauguration data (A - G: "UIC address set";
ordering according to rule "a" A: requests leading in direction 1)
A B C D E F G
• conf. NADI (8 entries) 01 02 03 04 05 06 07

• leading vehicle A = 01

556
OR
 Step Action Expected result Checks Expected configuration

12 reset leading UIC inauguration with A - G: • inauguration data (A - G2: "conf. configuration", see above
request on A ordering according to rule "c" info on conf. configuration)
• conf. NADI (8 entries)
Appendices

• no leading vehicle
13 turn G1, G2 off TCN/UIC inauguration with A - G: • inauguration data (A - G2: "conf. configuration",
ordering according to rule "c" info on conf. configuration)
A B C D E F missing
• conf. NADI 01 02 03 04 05 06 07
(7 entries; missing nodes)

• no leading vehicle

14 turn G1, G2 on TCN/UIC inauguration with A - G: • inauguration data (A - F: "conf. configuration",

ordering according to rule "c" info on conf. configuration;
G: no info on conf. configuration)
A B C D E F G missing
01 02 03 04 05 06 00 07
• conf. NADI (9 entries;

140
missing + unknown nodes)
• no leading vehicle
15 Set leading request UIC inauguration with A - G: • inauguration data (A - F: "conf. configuration", see above
on G2 ordering according to rule "c" info on conf. configuration;
(G2 has unknown UIC address) no info on conf. configuration;
G2: requests leading in direction 1)
• conf. NADI (8 entries)
• no leading vehicle

556
OR
Appendices

H.[Link] - Lengthening of confirmed compositions

Purpose:

Test the correct handling of confirmed compositions:

Test steps

• lengthening of confirmed compositions 3, 5

and the correct handling of leading requests for confirmed compositions with:

• setting the leading property for an end vehicle with unknown UIC 4
address

Reference to UIC 556:

Point 5.1 - page 10 operational modes: INAUGURATION/REGULAR

Point C.1.3.5 - page 47 description of algorithm
Point C.2.5 - page 65 UMS user services / E-Telegrams:
Appendix A - page 35, No 15.02 write_correction: UIC_FC_CORRECTION
Appendix A - page 35, No 15.07 multicast_create: UIC_FC_MULTICAST_CREATE
Point C.2.8 - page 82 leading: (local)
Point C.[Link] - page 71 correction handling

Train composition:

TTC1 as defined in point H.3.1 - page 120. The key positions are the train bus nodes of vehicles A, C,
D/E/F and G.

NB : Nothing to note.

141 556
OR
 Test sequence:

Step Action Expected result Checks Expected configuration

1 turn C - G on TCN/UIC inauguration with C - G: • unconf. NADI (6 entries)

Appendices

with master at D ordering according to rule "d"

C D E F G
• no leading vehicle 01 02 03 04 05

2 correct ordering UIC inauguration with C - G: • inauguration data (C - G: "UIC address set",
with gap C, D, E, F, G ordering according to rule "d" info on conf. configuration)
gap C D E F G
• conf. NADI (7 entries) 01 02 03 04 05 06

• no leading vehicle
3 turn A on TCN/UIC inauguration with A, C - G: • inauguration data (C - G: "conf. configuration",
no inversion of ordering info on conf. configuration;
(no lengthening) A: no info on conf. configuration)
A gap C D E F G
00 01 02 03 04 05 06
• conf. NADI
(8 entries; unknown veh.)

142
• no leading vehicle
4 Set leading request UIC inauguration with A, C - G: • inauguration data (C - G: "conf. configuration", see above
on A no inversion of ordering info on conf. configuration;
(UIC address of A is unknown) A: no info on conf. configuration,
requests leading in direction 1)
• conf. NADI (8 entries;
unknown veh.)
• no leading vehicle
5 turn B on TCN/UIC inauguration with A - G: • inauguration data (C - G: "conf. configuration",
ordering according to rule "a" Info on conf. configuration;
(lengthening) A, B: no info on conf. configuration;
A B C D E F G
A: requests leading in direction 1) 01 02 03 04 05 06 07

• unconf. NADI (8 entries)

• leading vehicle A = 01

556
OR
Appendices

H.[Link] - Coupling of two confirmed compositions.

Purpose:

Test the correct handling of confirmed compositions:

coupling of a confirmed composition with another confirmed composition Test steps

• with a different number of confirmed vehicles 6

• with a different list of confirmed missing vehicles 12
• resulting in a number of confirmed vehicles larger than the confirmed number of 18
vehicles

Reference to UIC 556:

Point 5.1 - page 10 operational modes: INAUGURATION/REGULAR

Point 6.2 - page 27 failure tolerance
Point C.1.3.5 - page 47 description of algorithm
Point C.2.5 - page 65 UMS user services / E-Telegrams:
Appendix A - page 35, No 15.02 write_correction: UIC_FC_CORRECTION
Appendix A - page 35, No 15.07 multicast_create: UIC_FC_MULTICAST_CREATE
Appendix A - page 35, No 15.06 inauguration_control: UIC_FC_INAUGURATION_CONTROL
Point C.[Link] - page 71 correction handling

Train composition:

TTC1 as defined in point H.3.1 - page 120. The key positions are the train bus nodes of vehicles A, C,
D/E/F and G.

NB : Nothing to note.

143 556
OR
 Test sequence:
Step Action Eexpected result Checks Expected configuration

1 turn A - C on TCN/UIC inauguration with A - C: • unconf. NADI (3 entries)

ordering according to rule "c"
Appendices

• no leading vehicle A B C
01 02 03

2 confirm ordering UIC inauguration with A - C: • inauguration data (A - C: "UIC address set") see above
with A - C ordering according to rule "c"
• conf. NADI (3 entries)
• no leading vehicle
3 set inhibit for A INHIBIT is set • UWTM Status (Inhibit) see above

4 turn D - G on TCN/UIC inauguration with D - G: composition 1 (A - C):

ordering according to rule "c"
• conf. NADI (3 entries) A B C
01 02 03
• no leading vehicle
composition 2 (D - G):

144
• unconf. NADI (5 entries)
D E F G
01 02 03 04
• no leading vehicle
5 confirm ordering UIC inauguration with D - G: composition 1 (A - C): see above
with D - G ordering according to rule "c"
• conf. NADI (3 entries)
• no leading vehicle
composition 2 (D - G):

• inauguration data (D - G: "UIC address set")

• conf. NADI (5 entries)
• no leading vehicle
6 reset inhibit for A TCN/UIC inauguration with A - G: • inauguration data (A - G: "conf. composition",
ordering according to rule "c" different confirmed number of vehicles)
(the conf. numbers of veh. differ)
A B C D E F G
• unconf. NADI (8 entries) 01 02 03 04 05 06 07

• no leading vehicle

556
OR
 Step Action Eexpected result Checks Expected configuration

7 turn D - G off TCN/UIC inauguration with A - C: • unconf. NADI (3 entries)

ordering according to rule "c"
A B C
• no leading vehicle 01 02 03
Appendices

8 correct ordering UIC inauguration with A - C: • inauguration data (A - C: "UIC address set",
with A, B, C, gap ordering according to rule "c" info on conf. configuration)
A B C gap
• conf. NADI (4 entries) 01 02 03 04

• no leading vehicle
9 set Inhibit for A INHIBIT is set • UWTM status (Inhibit) see above

10 turn D - G on TCN/UIC inauguration with D - G: composition 1 (A - C):

ordering according to rule "c"
• conf. NADI (4 entries)
A B C gap
• conf. missing vehicle 04 01 02 03 04

• no leading vehicle

145
composition 2 (D - G):
D E F G
• unconf. NADI (5 entries) 01 02 03 04

• no leading vehicle
11 confirm ordering UIC inauguration with D - G: composition 1 (A - C): see above
with D - G ordering according to rule "c"
• conf. NADI (4 entries)
• no leading vehicle
composition 2 (D - G):

• inauguration data (D - G: "UIC address set")

• conf. NADI (5 entries)
• no leading vehicle

556
OR
 Step Action Eexpected result Checks Expected configuration

12 reset Inhibit for A TCN/UIC inauguration with A - G: • inauguration data (A - G: "conf. configuration";
ordering according to rule "c" different confirmed missing vehicles lists
(the lists of conf. missing A B C D E F G
01 02 03 04 05 06 07
Appendices

veh. differ)
• unconf. NADI (8 entries)
• no leading vehicle
13 turn D - G off TCN/UIC inauguration with A - C: • unconf. NADI (3 entries)
ordering according to rule "c"
• no leading vehicle A B C
01 02 03

14 correct ordering UIC inauguration with A - C: • inauguration data (A - C: "UIC address set";
with A, B, C, D ordering according to rule "c" info on conf. configuration)
A B C missing
01 02 03 04
• conf. NADI (4 entries; missing veh.)

• no leading vehicle

146
15 set Inhibit for A INHIBIT is SET • UWTM status (Inhibit) see above

16 turn D - G on TCN/UIC inauguration with D - G: composition 1 (A - C):

ordering according to rule "c"
• conf. NADI (4 entries; missing veh.)
A B C missing
01 02 03 04

• no leading vehicle
composition2 (D - G):

• unconf. NADI (5 entries) E

D F G
01 02 03 04
• no leading vehicle

556
OR
 Step Action Eexpected result Checks Expected configuration

17 confirm ordering UIC inauguration with D - G: composition 1 (A - C): see above

with D - G ordering according to rule "c" • conf. NADI (4 entries; missing veh.)
Appendices

• no leading vehicle
composition 2 (D - G):

• inauguration data (D - G: "UIC address set")

• conf. NADI (5 entries)
• no leading vehicle
18 reset Inhibit TCN/UIC inauguration with A - G: • inauguration data (A - G: "conf. configuration";
for A ordering according to rule "c" info on conf. configuration)
(the number of conf. veh. is A B C D E F G
larger than the conf. number
• unconf. NADI (8 entries) 01 02 03 04 05 06 07

of veh.) • no leading vehicle

147
556
OR
Appendices

H.[Link] - Setting the vehicle number for seat reservation

Purpose:

Test the correct handling of setting the vehicle reservation number.

Reference to UIC 556:

Point 5.1 - page 10 operational mode: INAUGURATION/REGULAR

Point C.2.5 - page 65 UMS user services / E-Telegrams:
Appendix A - page 35, No 15.03 write_res_nr: UIC_FC_WRITE_RES_NR
Appendix A - page 35, No 15.07 multicast_create: UIC_FC_MULTICAST_CREATE
Point C.[Link] - page 71 vehicle reservation handling

Train composition:

TTC1 as defined in point H.3.1 - page 120. The key positions are the train bus nodes of vehicles A, C,
D/E/F and G.

NB : Nothing to note.

148 556
OR
 Test sequence:
Step Action Eexpected result Checks Expected configuration

1 turn A - G on TCN/UIC inauguration with A - G: • unconf. NADI (8 entries)

ordering according to rule "c"
Appendices

A B C D E F G
• no leading vehicle 01 02 03 04 05 06 07

2 set veh. no. for seat UIC inauguration with A - G: • inauguration data (A - G: new vehicle reservation
reservation to ordering according to rule "c" number)
(000, 101, 102, 111, A B C D E F G
112, 113, 121) • unconf. NADI (8 entries) 01 02 03 04 05 06 07
000 101 102 111 112 113 121 res. num.
• no leading vehicle

149
556
OR
Appendices

H.6.3.2 - UIC redundancy test suite

Purpose:

Test the features for redundancy switch-over, especially

- for unconfirmed compositions

- for confirmed compositions

- duration.

This includes redundancy switch-over for end nodes, intermediate nodes, and vehicles with multiple
gateways.

NB : Nothing to note.

H.[Link] - Redundancy switch-over for unconfirmed compositions.

Purpose:

Test the correct handling of redundancy for unconfirmed compositions:

test case/test step 2 3 4

• intermediate node X
• end node X X
• vehicle with one gateway X
• trainset X
• vehicle with multiple gateways X

Reference to UIC 556:

Point 4.1.1 und 4.1.2 - page 6 Bus structure

Point 5.1 - page 10 operational mode: INAUGURATION
Point 6.2 - page 27 failure tolerance
Point C.2.6 - page 67 UMS user services / messages:
Point C.2.8 - page 82 leading: (local)

Train compositions:

TTC1 as defined in point H.3.1 - page 120. The key positions are the train bus nodes of vehicles A, C,
D/E/F and G2.

NB : Nothing to note.

150 556
OR
 Test sequence:

Step Action Expected result Checks Expected configuration

1 turn A - G on TCN/UIC inauguration with A - G: • unconf. NADI (8 entries)

Appendices

ordering according to rule "c"

• no leading vehicle A B C D E F G
01 02 03 04 05 06 07

2 trigger failure of active node TCN/UIC inauguration with A - G: • inauguration data (A: "Redundancy switch-over") see above
for A ordering according to rule "c"
(successful redundancy switch-over • unconf. NADI (8 entries)
of A)
• no leading vehicle
3 trigger failure of active node TCN/UIC inauguration with A - G: • inauguration data (D-F: "Redundancy switch-over") see above
for D - F ordering according to rule "c"
(successful redundancy • unconf. NADI (8 entries)
switch-over of D/E/F)
• no leading vehicle
4 trigger failure of active node TCN/UIC inauguration with A - G: • inauguration data (G2: "Redundancy switch-over") see above

151
for G2 ordering according to rule "c"
(redundancy switch-over of G2) • unconf. NADI (8 entries)
• no leading vehicle

556
OR
Appendices

H.[Link] - Redundancy switch-over for confirmed compositions

Purpose:

Test the correct handling of redundancy for confirmed compositions:

Test case/test step 3 6 9 13 17 20 23 27 30

• Intermediates nodes X X X X
• end nodes X X X X X X
• vehicles with one node X X X X
• trainsets X X X X
• vehicles with multiple nodes X X
• simple gaps X X X
• multiple gaps u (X) c u c u+c
(u: unconfirmed; c: confirmed gap)

Reference to UIC 556:

Point 4.1.1 and 4.1.2 - page 6 Bus structure

Point 5.1 - page 10 operational mode: INAUGURATION/REGULAR
Point 6.2 - page 27 failure tolerance
Point C.1.3.5 - page 47 description of algorithm: redundant train bus nodes
Point C.2.5 - page 65 UMS user services / messages:
Appendix A - page 35, No 15.02 write_correction: UIC_FC_CORRECTION
Appendix A - page 35, No 15.07 multicast_create: UIC_FC_MULTICAST_CREATE
Point C.[Link] - page 71 correction handling

Train composition:

TTC1 as defined in point H.3.1 - page 120. The key positions are the train bus nodes of vehicles A,
D/E/F and G.

NB : Nothing to note.

152 556
OR
 Test sequence:

Step Action Expected result Checks Expected configuration

1 turn A - G on TCN/UIC inauguration with A - G: • unconf. NADI (8 entries)

Appendices

ordering according to rule "c"

• no leading vehicle A B C D E F G
01 02 03 04 05 06 07

2 confirm ordering UIC inauguration with A - G: • inauguration data (A - G: see above

ordering according to rule "c" "UIC address set")
• conf. NADI (8 entries)
• no leading vehicle
3 trigger failure of active TCN/UIC inauguration with A - G: • inauguration data (A - C, G: "conf. see above
node of D/E/F ordering according to rule "c" configuration",
(successful redundancy info on conf. configuration;
switch-over of D/E/F) D/E/F: "Redundancy switch-over")
• conf. NADI (8 entries)

• no leading vehicle

153
4 prepare deactivated standby no UIC inauguration • UWTM topography (not changed) see above
node for D/E/F a

5 turn C off depends on position of none ---

TCN master
6 trigger failure of active node TCN/UIC inauguration with • inauguration data (A - B, G: "conf.
for D/E/F A - B, D - G: configuration",
ordering according to rule "c" info on conf. configuration; A B D E F missing missing missing missing G
01 02 00 00 00 03 04 05 06 07
(unsuccessful redundancy D/E/F: "Redundancy switch-over")
switch-over of D/E/F:
position of D/E/F cannot
• conf. NADI (11 entries;
missing + unknown veh)
be determined)
• no leading vehicle
7 turn C on TCN/UIC inauguration with A - G: • inauguration data (A - B, G: "conf.
ordering according to rule "c" configuration",
(Position of C, D/E/F info on conf. configuration;
A B C D E F G
C - F: no info on conf. configuration) 01 02 03 04 05 06 07
can be determined)
• conf. NADI (8 entries)

• no leading vehicle
a. What actually needs to be done may depend on the hardware redundancy concept

556
OR
 Step Action Expected result Checks Expected configuration

8 prepare deactivated no UIC inauguration • UWTM Topography (not changed) see above
standby node for D/E/F
9 trigger failure of active TCN/UIC inauguration with A - G: • inauguration data (A - G1: conf. configuration see above
Appendices

node of G2 ordering according to rule "c" info on conf. configuration;

(successful redundancy G2: "redundancy switch-over")
switch-over of G2)
• conf. NADI (8 entries)
• no leading vehicle
10 prepare deactivated no UIC inauguration • UWTM Topography (not changed) see above
standby node for G2

11 confirm ordering UIC inauguration with A - G: • inauguration data (A - G: "UIC address set") see above
ordering according to rule "c"
• conf. NADI (8 entries)
• no leading vehicle
12 turn G1 off depends on position of TCN master none ---

154
13 trigger failure of active TCN/UIC inauguration with A - F, G2: • inauguration data (A - F: "conf. configuration",
node of G2 ordering according to rule "c" info on conf. configuration;
(successful redundancy G2 "redundancy switch-over" A B C D E F G
switch-over of G2) 01 02 03 04 05 06 07
• conf. NADI (7 entries)
• no leading vehicle
14 turn G1 on TCN/UIC inauguration with A - G: • inauguration data (A - F; G2: "conf. configuration",
ordering according to rule "c" info on conf. configuration;
G1: no info on conf. configuration) A B C D E F G
01 02 03 04 05 06 07
• conf. NADI (8 entries)
• no leading vehicle
15 prepare deactivated no UIC inauguration • UWTM Topography (not changed) see above
standby node for G2

556
OR
 Step Action Expected result Checks Expected configuration

16 correct ordering with UIC inauguration with A - G: • inauguration data (A - G: "UIC address set",
A, B, C, ordering according to rule "c" info on conf. configuration)
gap, D, E, F, G
• conf. NADI (9 entries) A B C gap D E F G
01 02 03 04 05 06 07 08
Appendices

• no leading vehicle
17 trigger failure of active TCN/UIC inauguration with A - G: • inauguration data (A - C, G: "conf. configuration", see above
node for D/E/F ordering according to rule "c" info on conf. configuration;
(successful redundancy D/E/F: "Redundancy switch-over")
switch-over of D/E/F) D/E/F: "Redundancy switch-over")
• conf. NADI (8 entries)

• no leading vehicle
18 prepare deactivated no UIC inauguration • UWTM Topography (not changed) see above
standby node for D/E/F

19 confirm ordering UIC inauguration with A - G: • inauguration data (A - G: "UIC address set")
ordering according to rule "c"

155
• conf. NADI (8 entries)
A B C D E F G
01 02 03 04 05 06 07
• no leading vehicle
20 trigger failure of TCN/UIC inauguration with A - G: • inauguration data (B - G: "conf. configuration", see above
active node of A ordering according to rule "c" info on conf. configuration;
(successful redundancy A: "redundancy switch-over")
switch-over of A)
• conf. NADI (8 entries)
• no leading vehicle
21 prepare deactivated no UIC inauguration • UWTM Topography (not changed) see above
standby node for A
22 turn B off depends on position of none ---
TCN master
23 trigger failure of TCN/UIC inauguration • inauguration data (C - G: "conf. configuration",
active node of A with A, C - G: no inversion info on conf. configuration;
of ordering A: "redundancy switch-over")
A missing missing C D E F G
(A has unknown UIC address) 00 01 02 03 04 05 06 07
• conf. NADI (9 entries; missing +
(unsuccessful redundancy unknown vehicles)
switch-over of A: position of
A cannot be determined) • no leading vehicle

556
OR
 Step Action Expected result Checks Expected configuration

24 turn B on TCN/UIC inauguration with A - G: • inauguration data (C - G: "conf. configuration",

no inversion of ordering info on conf. configuration;
(A and B have unknown A, B: no info on conf. configuration) A B missing missing C D E F G
00 00 01 02 03 04 05 06 07
UIC address)
Appendices

• conf. NADI (10 entries; missing +

unknown vehicles)

• no leading vehicle
25 prepare deactivated no UIC inauguration • UWTM Topography (not changed) see above
standby node for A
26 correct ordering with A, UIC inauguration with A - G: • inauguration data (A - G: "UIC address set",
gap, B, C, D, E, F, G ordering according to rule "c" info on conf. configuration)
A gap B C D E F G
• conf. NADI (9 entries) 01 02 03 04 05 06 07 08

• no leading vehicle
27 trigger failure of active TCN/UIC inauguration with A - G: • inauguration data (B - G: "conf. configuration", see above
node of A ordering according to rule "c" info on conf. configuration;

156
(successful redundancy A: "Redundancy switch-over")
switch-over of A) • conf. NADI (9 entries)
• no leading vehicle
28 prepare deactivated no UIC inauguration • UWTM Topography (not changed) see above
standby node for A
29 turn B off depends on position of none ---
TCN master
30 trigger failure of active TCN/UIC inauguration with • inauguration data (C - G: "conf. configuration",
node for A A, C - G: Info on conf. configuration;
no inversion of ordering A: "redundancy switch-over")
A missing gap missing C D E F G
(A has unknown UIC address 00 01 02 03 04 05 06 07 08
• conf. NADI (10 entries; unknown +
(unsuccessful redundancy missing vehicles)
switch-over of A:
position of A cannot be • no leading vehicle
determined

556
OR
 Step Action Expected result Checks Expected configuration

31 turn B on TCN/UIC inauguration with A - G: • inauguration data (C - G: "conf. configuration",

no inversion of ordering info on conf. configuration;
(A has unknown UIC address) A, B: no info on conf. configuration) A B missing gap missing C D E F G
(B cannot be integrated) 00 00 01 02 03 04 05 06 07 08
Appendices

• conf. NADI (11 entries; missing +

unknown vehicles)
• no leading vehicle

157
556
OR
Appendices

H.[Link] - Duration of redundancy switch-over

Purpose:

Measure the duration of a UIC redundancy switch-over.

This shall typically take no longer than 1 s. At worst, it may take up to 1,4 s.

The duration of a UIC redundancy switch-over shall be measured with reference to:

Test step Reason for inauguration Definition of switch-over time

2 a simple failure of the redundant gateway time between the last PD frame before the
(e.g. switch off active gateway) node failure and the first valid PD frame
(of vehicle A)

Reference to UIC 556:

Point 4.1.1 and 4.1.2 - page 6 bus structure

Point 6.2 - page 27 failure tolerance
Point C.1.3 - page 39 UIC inauguration

Train composition:

TTC1 as defined in point H.3.1 - page 120. All nodes are key positions.

NB : The duration of the redundancy switch-over is measured in a composition of 8, 16, and

22 nodes.

To achieve statistically significant values, the measurement shall be repeated at least 10 times for
each configuration.

Table 11 : Duration of redundancy switch-over a

(N/min./max./mean/std. deviation)
Results Number of nodes
a) 8 nodes b) 16 nodes c) 22 nodes
(A-H) (A-P) (A-V)
N
min.
max.
mean
standard deviation
a. UIC 556 is only normative with respect to the maximum inauguration duration. The values of the minimum,
average values and the standard deviation are only documented to assess the failure coincidence of the
measurements.

158 556
OR
 Test sequence:
Step Action Expected result Checks Expected configuration

1 turn on: TCN/UIC inauguration: • unconf. NADI (a) 8, b) 16 or c) 22 entries) a)

a) A - H ordering according to rule "c"
Appendices

b) A - P A B C D E F G H
ou 01 02 03 04 05 06 07 08

c) A - V
b)
...
A B C D E F G H P
01 02 03 04 05 06 07 08 16

c)
.......
A B C D E F G H V
01 02 03 04 05 06 07 08 22

2 trigger failure of the active TCN/UIC inauguration: • unconf. NADI (a) 8, b) 16 or c) see above
node of A ordering according to rule "c" 22 entries) statistics
(redundancy switch-over of A) • duration of redundancy switch-over

159
556
OR
Appendices

H.6.3.3 - Performance test suite

Purpose:
Measure the performance characteristics for a UIC node, especially:
- duration of UIC/TCN and UIC inauguration;
- power consumption in sleep mode.

NB : Nothing to note.

H.[Link] - Duration of UIC inauguration

Purpose:
Measure the duration of a UIC inauguration.

This shall typically take no longer than 1 s. At worst, it may take up to 1,4 s.

The duration of a UIC inauguration shall be measured with reference to:

Test step Reason for inauguration Definition of inauguration time

2, 4 a new TCN inauguration (e.g. time between sending the first UNNAME telegram
after lengthening or shortening of and the first valid PD frame (of vehicle A)
the train bus)
3 change of the UIC configuration time between sending the first Topography
(e.g. change of the leading Request frame and the first valid PD frame (of
vehicle) vehicle A)

Reference to UIC 556:

Point 4.1.1 and 4.1.2 - page 6 Bus structure

Point 5.1 - page 10 Operational mode: INAUGURATION
(duration for change of leading vehicle)
Point 5.6.2 - page 19 Function address 15
Point 6.2 - page 27 Failure tolerance
Point C.2.5 - page 65 UMS user services / messages:
Point C.2.7.2 - page 80 leading_request: (local)
Point C.1.3.1 - page 39 UIC inauguration

160 556
OR
Appendices

Train composition:
TTC3 as defined in point H.3.3 - page 122. All nodes are key positions.

NB : The duration of the inauguration is measured in a composition of 8, 16, and 22 nodes.

To achieve statistically significant values, the measurement shall be repeated at least 10 times for
each configuration.

Table 12 : Duration of UIC inauguration a

(N/min/max/mean/std. deviation)

Number of nodes (nn)

TCN
Results a) 8 nodes b) 16 nodes c) 22 nodes
inauguration
(A-H) (A-P) (A-V)
yes/ N
lengthening
(step 2) min.
max.
mean
standard
deviation
no N
(step 3)
min.
max.
mean
standard
deviation
yes/ N
shortening
(step 4) min.
max.
mean
standard
deviation
a. UIC 556 is only normative with respect to the maximum inauguration duration. The values of the minimum, average
values and the standard deviation are only documented to assess the failure coincidence of the measurements.

161 556
OR
 Test sequence:
Step Action Expected result Checks Expected configuration

1 turn on: TCN/UIC inauguration: none ---

a) B - H ordering according to rule "c"
Appendices

b) B - P
or
c) B - V
2 turn A on TCN/UIC inauguration: • unconf. NADI (a) 8, b) 16 or c) 22 entries) a)
ordering according to rule "c"
A B C D E F G H
01 02 03 04 05 06 07 08

• no leading vehicle statistics b)

...
A B C D E F G H P
01 02 03 04 05 06 07 08 16

• duration of TCN/UIC inauguration c)

.......
A B C D E F G H V
01 02 03 04 05 06 07 08 22

162
3 set leading request TCN/UIC inauguration: • unconf. NADI (a) 8, b) 16 or c) 22 entries) see above
A in direction 1 ordering according to rule "a
• leading vehicle A = 01 statistics

• duration of UIC inauguration

4 turn off: TCN/UIC inauguration: • unconf. NADI (a) 7, b) 15 or c) 21 entries) a)

a) H ordering according to rule "a"
b) P A B C D E F G
01 02 03 04 05 06 07
or
• leading vehicle A = 01 statistics b)
c) V
...
A B C D E F G H Q
01 02 03 04 05 06 07 08 15

• duration of TCN/UIC inauguration c)

.......
A B C D E F G H U
01 02 03 04 05 06 07 08 21

556
OR
Appendices

H.[Link] - Power consumption

Purpose:

Verify that the power consumption of a single node in SLEEP mode is less than 10 W.

Reference to UIC 556:

Point 4.3 - page 8 power consumption in sleep mode < 10 W

Point 5.1 - page 10 operational mode: SLEEP

Train composition:

The tests concerning the SLEEP mode power consumption may be done with one single gateway.

NB : The power consumption of the train bus node shall be measured at the node's power supply
input.

163 556
OR
 Test sequence:
Step Action Expected result Checks Expected configuration

1 turn on train bus node is in operation • node status: ON ---

Appendices

2 set SLEEP request to vehicle A vehicle A enters SLEEP mode • node status : SLEEP ---

3 measure power consumption power consumption below 10 W • power consumption ---

164
556
OR
Appendices

H.6.3.4 - Unconfirmed compositions test suite

H.[Link] - Unconfirmed composition on TTC1

Purpose:

Test the correct computation of unconfirmed train compositions depending on

- the number of vehicles/nodes in the train;

- the number of vehicles in each trainset within the train;

- the number of double node vehicles (0/1);

- the position of the TCN master within the train;

- the existence and position of a leading vehicle.

Reference to UIC 556:

Point C.1.3.2 - page 39

Composition:

See reference composition.

NB : Following cases shall be covered:

1. failure of single (a) intermediate / (b) end node(s) (master (') / slave nodes)
2. occurrence of single (a) intermediate / (b) end node(s)
3. no leading vehicle
4. leading vehicle (a) in an end node, (b) in the middle vehicle, (c) in another intermediate
node/vehicle
5. (a) no / (b) one / (c) two traction unit(s) in end/intermediate node(s)/vehicle(s).

165 556
OR
 Test sequence:
Step Action Expected result Check Expected configuration
The results shall be checked by TCN addresses are apecified as far as predictable
analyzing the NADI: UIC and TCN
Appendices

addresses shall be checked as (far as)

specified, as well as leading requests
and leading vehicles, other NADI
contents shall be compared with the
corresponding content of other nodes'
NADIs. The reply telegram source function
shall be always 15, the reply telegram status
shall be always 0, and the reply telegram
code shall be checked (0A01 for getNADI,
0A22 for getStatus, 0A03 for setOpMode,
0AF0 for setLeading / resetLeading). Empty
entries mean: no check necessary.
The entries "… relative to …" refer to
NADI entries (counted from 1): 24,0
(global part); 71,0; 71,1 for the

166
first vehicle and those for further
vehicles. The entries 0-0 or 1-1 refer to
a double node vehicle. The order is
always starting at UIC address 1.

1 turn all vehicles on TCN & UIC inauguration UIC addresses, 8 NADI entries Standard addresses
3,5b with all nodes
2 set B strong TCN & UIC inauguration UIC and TCN addresses,
3,5b with all nodes 8 NADI entries
TCN, relative to UIC: 0 A B C D E F G1 G2

U01 U02 U03 U04 U05 U06 U07

vehicles, relative to TCN: T02 T01 T63 T62 T62 T62 T61 T60

0, 1, 1, 0, 0, 0, 1-1 (UIC 1…7)

vehicles, relative to UIC:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)

556
OR
 Step Action Expected result Check Expected configuration

3 turn A off TCN & UIC inauguration UIC and TCN addresses,
1b, with nodes BCDG1G2 7 NADI entries TCN,
B C D E F G1 G2
3,5a relative to UIC: 1
U06 U05 U04 U03 U02 U01
Appendices

vehicles, relative to TCN: T01 T63 T62 T62 T62 T61 T60

1-1, 0, 0, 0, 1, 1 (UIC 1…6)

vehicles, relative to UIC:
1-1, 0, 0, 0, 1, 1 (UIC 1…6)
4 turn A on TCN & UIC inauguration UIC and TCN addresses,
2b, with all nodes 8 NADI entries
A B C D E F G1 G2
3,5b TCN, relative to UIC: 0
U01 U02 U03 U04 U05 U06 U07
T02 T01 T63 T62 T62 T62 T61 T60
vehicles, relative to TCN:
0, 1, 1, 0, 0, 0, 1-1 (UIC 1…7)
vehicles, relative to UIC:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)
5 turn B off TCN & UIC inauguration UIC addresses,

167
1a’, with nodes ACDG1G2 7 NADI entries
A C D E F G1 G2
3,5b U01 U02 U03 U04 U05 U06

6 turn B on TCN & UIC inauguration UIC addresses, Standard addresses

2a, with all nodes 8 NADI entries
3,5b
7 set B strong and then
set B weak A B C D E F G1 G2

U01 U02 U03 U04 U05 U06 U07

T02 T01 T63 T62 T62 T62 T61 T60

8 turn D off no inauguration UIC and TCN addreses, see above

1a, 8 NADI entries
TCN, relative to UIC: 0
3,5b
vehicles, relative to TCN:
0, 1, 1, 0, 0, 0, 1-1 (UIC 1…7)
vehicles, relative to UIC:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)

556
OR
 Step Action Expected result Check Expected configuration

9 turn D on UIC inauguration see above see above

2a, with all nodes
3,5b
Appendices

10 turn CD off no inauguration see above see above

1a,
3,5b
11 turn D on TCN & UIC inauguration with UIC addresses,
2a, nodes ABDG1G2 7 NADI entries A B D E F G1 G2

3,5b U01 U02 U03 U04 U05 U06

12 set B strong and then

set B weak

13 turn C on TCN & UIC inauguration UIC addresses, Standard addresses

2a, with all nodes 8 NADI entries
3,5b

168
14 set B strong and then
set B weak
15 turn G2 off TCN & UIC inauguration UIC addresses,
1b, with nodes ABCDG1 7 NADI entries
A B C D E F G1
3,5b U01 U02 U03 U04 U05 U06 U07

16 turn G2 on TCN & UIC inauguration UIC addresses, Standard addresses

2b, with all nodes 8 NADI entries
3,5b

17 set A strong [TCN] & UIC inauguration UIC and TCN addresses,
3,5b with all nodes 8 NADI entries
A B C D E F G1 G2
TCN, relative to UIC: 1
U01 U02 U03 U04 U05 U06 U07
T01 T02 T03 T04 T04 T04 T05 T06
vehicles, relative to TCN:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)
vehicles, relative to UIC:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)

556
OR
 Step Action Expected result Check Expected configuration

18 turn A off TCN & UIC inauguration UIC address tendency corresponds for TCN master on D:
1b’, with nodes BCDG1G2 with that of TCN,
7 NADI entries B C D E F G1 G2
3,5a
Appendices

U01 U02 U03 U04 U05 U06

for TCN master on B, C, G1 or G2:

B C D E F G1 G2

U06 U05 U04 U03 U02 U01

19 turn A on TCN & UIC inauguration UIC addresses, Standard addresses

2b, with all nodes 8 NADI entries
3,5b
20 set A strong and then
set A weak A B C D E F G1 G2

U01 U02 U03 U04 U05 U06 U07

T01 T02 T03 T04 T04 T04 T05 T06

169
21 turn C off no inauguration UIC and TCN addresses, see above
1a, 8 NADI entries
3,5b TCN, relative to UIC: 1

vehicles, relative to TCN:

1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)
vehicles, relative to UIC:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)
22 turn C on UIC inauguration see above see above
2a, with all nodes
3,5b
23 set G2 strong

556
OR
 Step Action Expected result Check Expected configuration

24 turn A off TCN & UIC inauguration UIC and TCN addresses,
1b, with nodes BCDG1G2 7 NADI entries
B C D E F G1 G2
3,5a TCN, relative to UIC: 1
U06 U05 U04 U03 U02 U01
Appendices

T05 T04 T03 T03 T03 T02 T01

vehicles, relative to TCN:
1-1, 0, 0, 0, 1, 1 (UIC 1…6)
vehicles, relative to UIC:
1-1, 0, 0, 0, 1, 1 (UIC 1…6)
25 turn A on TCN & UIC inauguration UIC and TCN addresses,
2b, with all nodes 8 NADI entries
A B C D E F G1 G2
3,5b TCN, relative to UIC: 0
U01 U02 U03 U04 U05 U06 U07
T06 T05 T04 T03 T03 T03 T02 T01
vehicles, relative to TCN:
0, 1, 1, 0, 0, 0, 1-1 (UIC 1…7)
vehicles, relative to UIC:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)
26 turn G1 off no inauguration see above see above

170
1a,
3,5b

27 turn G1 on UIC inauguration see above see above

2a, with all nodes
3,5b

28 turn G2 off TCN & UIC inauguration UIC addresses,

1b’, with nodes ABCDG1 7 NADI entries
A B C D E F G1
3,5b U01 U02 U03 U04 U05 U06 U07

29 turn G2 on TCN & UIC inauguration UIC addresses Standard addresses

2b, with all nodes 8 NADI entries
3,5b

556
OR
 Step Action Expected result Check Expected configuration

30 set A strong and [TCN &] UIC inauguration UIC and TCN addresses,
then set A weak with all nodes 8 NADI entries
A B C D E F G1 G2
TCN, relative to UIC: 1
U01 U02 U03 U04 U05 U06 U07
Appendices

T01 T02 T03 T04 T04 T04 T05 T06

vehicles, relative to TCN:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)
vehicles, relative to UIC:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)
31 leading request on A UIC inauguration UIC and TCN addresses, see above
4a, for direction 1 with all nodes 8 NADI entries
5b A requ. leadership
and is leading
32 reset leading UIC inauguration UIC and TCN addresses, see above
3, request on A with all nodes 8 NADI entries
5b
33 leading request on C UIC inauguration UIC and TCN addresses, see above

171
4c, for direction 2 with all nodes 8 NADI entries
5b C requ. leadership
and is leading
34 reset leading UIC inauguration UIC and TCN addresses, see above
3, request on C with all nodes 8 NADI entries
5b
35 leading request UIC inauguration UIC and TCN addresses,
4c, on F (direction 2) with all nodes 8 NADI entries
A B C D E F G1 G2
5b F requ. leadership
U07 U06 U05 U04 U03 U02 U01
and is leading T01 T02 T03 T04 T04 T04 T05 T06

TCN, relative to UIC: 0

vehicles, relative to TCN:
0-0, 1, 1, 1, 0, 0, 1 (UIC 1…7)
vehicles, relative to UIC:
1-1, 0, 0, 0, 1, 1, 0 (UIC 1…7)

556
OR
 Step Action Expected result Check Expected configuration

36 leading request UIC inauguration UIC and TCN addresses,

4b, on D (direction 1) with all nodes 8 NADI entries
A B C D E F G1 G2
5b D requ. leadership and
U01 U02 U03 U04 U05 U06 U07
Appendices

is leading T01 T02 T03 T04 T04 T04 T05 T06

TCN, relative to UIC: 1

vehicles, relative to TCN:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)
vehicles, relative to UIC:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)
37 reset leading UIC inauguration UIC and TCN addresses, see above
3, request on D with all nodes 8 NADI entries
5b
38 leading request UIC inauguration UIC and TCN addresses,
4a, on G2 for direction 2 with all nodes 8 NADI entries
A B C D E F G1 G2
5b G2 requ. leadership
U07 U06 U05 U04 U03 U02 U01

172
and is leading T01 T02 T03 T04 T04 T04 T05 T06

TCN, relative to UIC: 0

vehicles, relative to TCN:
0-0, 1, 1, 1, 0, 0, 1 (UIC 1…7)
vehicles, relative to UIC:
1-1, 0, 0, 0, 1, 1, 0 (UIC 1…7)
39 turn offA TCN & UIC inauguration UIC addresses,
1b’ with nodes BCDG1G2 7 NADI entries
B C D E F G1 G2
4a, G2 requ. leadership
U06 U05 U04 U03 U02 U01
5a and is leading
40 set B strong [TCN &] UIC inauguration UIC and TCN addresses,
4a, with nodes BCDG1G2 7 NADI entries
B C D E F G1 G2
5a G2 requ. leadership
U06 U05 U04 U03 U02 U01
and is leading T01 T63 T62 T62 T62 T61 T60

TCN, relative to UIC: 1

vehicles, relative to TCN:
1-1, 0, 0, 0, 1, 1 (UIC 1…6)
vehicles, relative to UIC:
1-1, 0, 0, 0, 1, 1 (UIC 1…6)

556
OR
 Step Action Expected result Check Expected configuration

41 reset leading UIC inauguration UIC and TCN addresses, see above
3,5a request on G2 with nodes BCDG1G2 7 NADI entries
TCN, relative to UIC: 1
Appendices

vehicles, relative to TCN:

1-1, 0, 0, 0, 1, 1 (UIC 1…6)
vehicles, relative to UIC:
1-1, 0, 0, 0, 1, 1 (UIC 1…6)
42 leading request UIC inauguration UIC and TCN addresses,
4c, on D (direction 1) with nodes BCDG1G2 7 NADI entries
B C D E F G1 G2
5a D requ. leadership
U01 U02 U03 U04 U05 U06
and is leading T01 T63 T62 T62 T62 T61 T60

TCN, relative to UIC: 0

vehicles, relative to TCN:
1, 1, 0, 0, 0, 1-1 (UIC 1…6)
vehicles, relative to UIC:

173
0, 0, 1, 1, 1, 0-0 (UIC 1…6)
43 turn G1G2 off TCN & UIC inaguration UIC and TCN addresses,
1ab with nodes BCD 5 NADI entries
B C D E F
4b, D requ. leadership
U05 U04 U03 U02 U01

5b and is leading T01 T63 T62 T62 T62

TCN, relative to UIC: 1

vehicles, relative to TCN:
0, 0, 0, 1, 1 (UIC 1…5)
vehicles, relative to UIC:
0, 0, 0, 1, 1 (UIC 1…5)
44 set B weak

45 turn A on TCN & UIC inauguration UIC addresses,

2b, with nodes ABCD 6 NADI entries
A B C D E F
4c, D requ. leadership
U06 U05 U04 U03 U02 U01

5c and is leading

556
OR
 Step Action Expected result Check Expected configuration

46 set C strong and then [TCN &] 2 UIC inaugurations UIC and TCN addresses,
4c, set C weak with nodes ABCD 6 NADI entries
A B C D E F
5c D requ. leadership
U06 U05 U04 U03 U02 U01
Appendices

and is leading T03 T02 T01 T63 T63 T63

TCN, relative to UIC: 1

vehicles, relative to TCN:
0, 0, 0, 1, 1, 0 (UIC 1…6)
vehicles, relative to UIC:
0, 0, 0, 1, 1, 0 (UIC 1…6)
47 turn G1 on TCN & UIC inauguration TUIC address tendency corresponds for TCN master on A or D:
2b, with nodes ABCDG1
with that of TCN,
4b, 7 NADI entries A B C D E F G1
5b U01 U02 U03 U04 U05 U06 U07

for TCN master on B, C or G1:

174
D requ. leadership
and is leading A B C D E F G1

U07 U06 U05 U04 U03 U02 U01

48 turn G2 on TCN & UIC inauguration UIC address tendency corresponds for TCN master on A or D:
2b, with all nodes
with that of TCN, standard addresses
4b,
8 NADI entries for TCN master on B, C, G1 or G2:
5b
D requ. leadership
and is leading A B C D E F G1 G2

U07 U06 U05 U04 U03 U02 U01

49 set C strong [TCN &] UIC inauguration UIC and TCN addresses,
4b, with all nodes 8 NADI entries
A B C D E F G1 G2
5b D requ. leadership
U07 U06 U05 U04 U03 U02 U01
and is leading T03 T02 T01 T63 T63 T63 T62 T61

TCN, relative to UIC: 1

vehicles, relative to TCN:
1-1, 0, 0, 0, 1, 1, 0 (UIC 1…7)
vehicles, relative to UIC:
1-1, 0, 0, 0, 1, 1, 0 (UIC 1…7)

556
OR
 Step Action Expected result Check Expected configuration

50 reset leading UIC inauguration UIC and TCN addresses, 8 NADI entries
3, 5b request on D with all nodes
A B C D E F G1 G2
TCN, relative to UIC: 0
U01 U02 U03 U04 U05 U06 U07
Appendices

T03 T02 T01 T63 T63 T63 T62 T61

vehicles, relative to TCN:
0, 1, 1, 0, 0, 0, 1-1 (UIC 1…7)
vehicles, relative to UIC:
1, 0, 0, 1, 1, 1, 0-0 (UIC 1…7)
51 turn G2 off TCN & UIC inauguration UIC and TCN addresses,
1b, with nodes ABCDG1 7 NADI entries
A B C D E F G1
3,5b TCN, relative to UIC: 0
U01 U02 U03 U04 U05 U06 U07
T03 T02 T01 T63 T63 T63 T62
vehicles, relative to TCN:
0, 1, 1, 0, 0, 0, 1 (UIC 1…7)
vehicles, relative to UIC:
1, 0, 0, 1, 1, 1, 0 (UIC 1…7)
52 turn G1 off TCN & UIC inauguration UIC and TCN addresses,

175
1b, with nodes ABCD 6 NADI entries
A B C D E F
3,5c TCN, relative to UIC: 1
U06 U05 U04 U03 U02 U01
T03 T02 T01 T63 T63 T63
vehicles, relative to TCN:
0, 0, 0, 1, 1, 0 (UIC 1…6)
vehicles, relative to UIC:
0, 0, 0, 1, 1, 0 (UIC 1…6)
53 turn A off TCN & UIC inauguration UIC and TCN addresses,
1b, with nodes BCD 5 NADI entries
B C D E F
3,5b TCN, relative to UIC: 1
U05 U04 U03 U02 U01
T02 T01 T63 T63 T63
vehicles, relative to TCN:
0, 0, 0, 1, 1 (UIC 1…5)
vehicles, relative to UIC:
0, 0, 0, 1, 1 (UIC 1…5)

556
OR
 Step Action Expected result Check Expected configuration

54 set C weak; TCN & 3 UIC inauguration UIC and TCN addresses,
3, set D strong; with nodes BCD 5 NADI entries
set D weak B C D E F
5b TCN, relative to UIC: 0
U05 U04 U03 U02 U01
Appendices

T62 T63 T01 T01 T01

vehicles, relative to TCN:
1, 1, 1, 0, 0 (UIC 1…5)
vehicles, relative to UIC:
0, 0, 0, 1, 1 (UIC 1…5)
55 turn G1 on TCN & UIC inauguration UIC address tendency corresponds for TCN master on D:
2b, with nodes BCDG1 with that of TCN,
6 NADI entries
3,5a B C D E F G1

U01 U02 U03 U04 U05 U06

for TCN master on B, C or G1:

B C D E F G1

U06 U05 U04 U03 U02 U01

176
56 turn A on TCN & UIC inauguration UIC addresses,
2b, with nodes ABCDG1 7 NADI entries A B C D E F G1

U01 U02 U03 U04 U05 U06 U07

3,5b
57 turn G2 on TCN & UIC inauguration UIC addresses, standard adresses
2b, with all nodes 8 NADI entries
3,5b
58 leading request on C UIC inauguration UIC addresses, 8 NADI-entries standard addresses
4c, for direction 1 with all nodes
C requ. leadership
5b and is leading

556
OR
Appendices

H.[Link] - Unconfirmed compositions with trainsets of all possible lengths

Purpose:

Test the correct computation of unconfirmed train compositions depending on:

- the number of vehicles/nodes in the train;

- the number of vehicles in each trainset within the train;

- the position of the TCN master within the train;

- the existence and position of a leading vehicle.

Reference to UIC 556:

Point C.1.3.2 - page 39

Composition:

See Fig. 17 - page 178.

NB : Following cases shall be covered:

1. failure of single (a) intermediate / (b) end node(s) (master/slave nodes);
2. occurrence of single (a) intermediate / (b) end node(s)
3. no leading vehicle;
4. leading vehicle (a) in an end node, (b) in an intermediate node/vehicle;
5. (a) no / (b) one / (c) two traction unit(s) in end/intermediate node(s)/vehicle(s)

177 556
OR
 A B C D E F G H I J K L M N O P Q R S T U VV
Appendices

← → → → ← ← ←

C: 141 F: 141 38, 44, J: 141 L: 42, M: 141, O: 42 U: 42, 141 39, 44,
45, 49, 45, 50,
141 141

Fig. 17 - Long train with 16 and more vehicles

178
556
OR
 Test sequence:
Step Action Expected result Check Expected configuration
The calculation shall be checked by Due to its length, the train is symbolized by a string,
analyzing the NADI. containing (subsets of) the vehicle letters (A to V) and
Appendices

UIC addresses shall be checked as after each vehicle letter the UIC address as far as
(far as) specified, other NADI predictable.
contents shall be compared with the
corresponding content of other
nodes' NADIs.

1 turn IJ on TCN & UIC inauguration UIC addresses I01 J02 K03
3,5b with nodes IJ 2 nodes, 3 vehicles, 3 NADI entries

2 turn F on TCN & UIC inauguration UIC address tendency corresponds F06 G05 H04 I03 J02 K01
2b, with nodes FIJ wuth that of TCN
3,5a 3 nodes, 6 vehicles,
6 NADI entries
3 turn M on TCN & UIC inauguration UIC address tendency corresponds for TCN master on M:

179
2b, with nodes FIJM with that of TCN F01 G02 H03 I04 J05 K06 L07 M08 N09 O10
4 nodes, 10 vehicles, for TCN master on F, I or J:
3,5a
10 NADI entries F10 G09 H08 I07 J06 K05 L04 M03 N02 O01

4 turn F off TCN & UIC inauguration UIC addresses I01 J02 K03 L04 M05 N06 O07
1b, with nodes IJM
3 nodes, 7 vehicles,
3,5b 7 NADI entries
5 leading request on O UIC inauguration UIC addresses I07 J06 K05 L04 M03 N02 O01
4a, (direction 2) with nodes IJM
3 nodes, 7 vehicles,
5b 7 NADI entries
leading vehicle: O

6 turn UV on TCN & UIC inauguration UIC addresses I01 J02 K03 L04 M05 N06 O07 P08 Q09 R10
2b, with nodes IJMUV 5 nodes, 14 vehicles, S11 T12 U13 V14
4b 14 NADI entries
5c leading vehicle: O

7 leading request UIC inauguration UIC addresses I01 J02 K03 L04 M05 N06 O07 P08 Q09 R10
4b, on L (direction1) with nodes IJMUV S11 T12 U13 V14
5 nodes, 14 vehicles,
5c 14 NADI entries
leading vehicle: L

556
OR
 Step Action Expected result Check Expected configuration

8 turn F on TCN & UIC inauguration UIC addresses F01 G02 H03 I04 J05 K06 L07 M08 N09 O10
2b, with nodes FIJMUV P11 Q12 R13 S14 T15 U16 V17
6 nodes, 17 vehicles,
4b, 17 NADI entries
Appendices

5b leading vehicle: L

9 turn C on TCN & UIC inauguration UIC addresses A22 B21 C20 D19 E18 F17 G16 H15 I14 J13 K12
2b, with all nodes L11 M10 N09 O08 P07 Q06 R05 S04 T03 U02 V01
7 nodes, 22 vehicles,
4b, 22 NADI entries
5b
leading vehicle: L

10 reset leading UIC inauguration with UIC addresses see above

3,5b request on L all nodes
7 nodes, 22 vehicles,
22 NADI entries
11 turn V off TCN & UIC inauguration TUIC address tendency corresponds for TCN master on C, M, U or V:

180
1b, with nodes CFIJMU with that of TCN A01 B02 C03 D04 E05 F06 G07 H08 I09 J10 K11
L12 M13 N14 O15 P16 Q17 R18 S19 T20 U21
3,5a
6 nodes, 21 vehicles, for TCN master on F, I or J:
21 NADI entries A21 B20 C19 D18 E17 F16 G15 H14 I13 J12 K11
L10 M09 N08 O07 P06 Q05 R04 S03 T02 U01
12 leading request UIC inauguration UIC addresses A21 B20 C19 D18 E17 F16 G15 H14 I13 J12 K11
4a, on U (direction 2) with all nodes L10 M09 N08 O07 P06 Q05 R04 S03 T02 U01
5a 6 nodes, 21 vehicles,
21 NADI entries
leading vehicle: U

556
OR
 Step Action Expected result Check Expected configuration

13 uncouple between TCN & UIC inauguration UIC addresses vehicle A … H:

1b, F and I with nodes CF and
vehicle A … H: Tendency corresponding for TCN master on C:
TCN & UIC inauguration
3,5a/1b,
with nodes IJMU
Appendices

with that of TCN A01 B02 C03 D04 E05 F06 G07 H08
4a, 2 nodes,
5b 8 vehicles,
8 NADI entries for TCN-Master on F:
vehicles I … U: 4 nodes, A08 B07 C06 D05 E04 F03 G02 H01
13 vehicles, vehicle I … U:
13 NADI entries I13 J12 K11 L10 M09 N08 O07 P06 Q05 R04
leading vehicle: U S03 T02 U01

14 reset leading UIC inauguration UIC addresses vehicle. I … U:

3,5a/3,5b request on U with nodes IJMU I01 J02 K03 L04 M05 N06 O07 P08 Q09 R10
vehicle I … U: 4 nodes,
S11 T12 U13
13 vehicles,
13 NADI entries

181
15 set I strong TCN & UIC inauguration UIC addresses see above
3,5a/3,5b with nodes IJMU
vehicle I … U: 4 nodes,
13 vehicles,
13 NADI entries
16 turn V on TCN & UIC inauguration UIC addresses vehicle I … V:
3,5a/2b, with nodes IJMUV
vehicle I … V: 5 nodes, for TCN master on M, U or V:
3,5c 14 vehicles,
I01 J02 K03 L04 M05 N06 O07 P08 Q09 R10
14 NADI entries
S11 T12 U13 V14
for TCN master on I or J:
I14 J13 K12 L11 M10 N09 O08 P07 Q06 R05
S04 T03 U02 V01
17 set I weak UIC inauguration UIC addresses see above
3,5a/3,5c with nodes IJMUV vehicle. I … V: 5 nodes,
14 vehicles, 14 NADI entries

18 couple between F and I TCN & UIC inauguration UIC addresses A22 B21 C20 D19 E18 F17 G16 H15 I14 J13 K12
2b/3,5b with all nodes L11 M10 N09 O08 P07 Q06 R05 S04 T03 U02 V01

556
OR
 Step Action Expected result Check Expected configuration

19 turn M off TCN & UIC inauguration UIC addresses A18 B17 C16 D15 E14 F13 G12 H11 I10 J09 K08 P07 Q06 R05 S04 T03 U02 V01
1a, with nodes CFIJUV
3,5b,
Appendices

20 turn M on TCN & UIC inauguration UIC addresses A22 B21 C20 D19 E18 F17 G16 H15 I14 J13 K12
2a, with all nodes L11 M10 N09 O08 P07 Q06 R05 S04 T03 U02 V01
3,5b

182
556
OR
Appendices

H.6.3.5 - Leading vehicle test suite

Purpose:

Test the correct handling of a leadership request on a node and of its withdrawal, including the
detection and the correct handling of a request conflict.

The following table shows the necessary test cases to be covered by the test steps as well as the
expected results.

Reference:

Point C.1.3.2 - page 39

Composition:

See reference composition.

NB : Following basic cases shall be covered (each case is carried out by a line or a group of lines
within the table below):

1. no node is leading, and no node requests leadership;

2. no node is leading, and a single node requests leadership;
3. one node is leading and another node requests leadership (end node & end node,
intermediate node & intermediate node, end node & intermediate node);
4. no node is leading and two nodes request leadership (end node & end node,
intermediate node & intermediate node, end node & intermediate node);
5. no node is leading and nodes ACDG2 request leadership;

6. two nodes were leading (end node & end node, intermediate node & intermediate node,
end node & intermediate node).
The transitions between these cases shall cover the following situations:
no node is leading, at least two nodes request leadership and one of them resets its
A)
leadership request;
one node is leading, at least one other node requests leadership, and the leading
B)
node resets its leadership request;
one node is leading, at least one other node requests leadership, and a non-leading
C)
node resets its leadership request;
one node is leading, at least one other node requests leadership, and the leading
D)
node receives a leadership request for the opposite direction.

183 556
OR
 Line No Vehicle A Vehicle B Vehicle C Vehicle D Vehicle F Node G1 Node G2 leadership Summary description

1 -a - - - - - - none no request
2a requested - - - - - - Vehicle A no conflict
Appendices

2b - - requested - - - - Vehicle C no conflict

2c - - - requested - - - Vehicle D no conflict
2d - - - - requested - - Vehicle F no conflict
2e - - - - - - requested Vehicle G2 no conflict
requested &
3a - requested - - - - Vehicle A with one leadership b
leading
requested &
3b - - - - - requested Vehicle A with one leadership
leading
requested &
3c requested - - - - - Vehicle C with one leadership
leading
requested &
3d - - - requested - - Vehicle C with one leadership

184
leading
requested &
3e - - - - - requested Vehicle C with one leadership
leading
requested &
3f requested - - - - - Vehicle D with one leadership
leading
requested &
3g - - requested - - - Vehicle D with one leadership
leading
requested &
3h - - - - - requested Vehicle D with one leadership
leading
requested &
3i requested - - - - - Vehicle F with one leadership
leading
requested &
3j - - requested - - - Vehicle F with one leadership
leading
requested &
3k - - - - - requested Vehicle F with one leadership
leading
requested &
3l requested - - - - - Vehicle G2 with one leadership
leading
requested&
3m - - requested - - - Vehicle G2 with one leadership
leading
a. no request.
b. shaded field indicate conflict cases.

556
OR
 Line No Vehicle A Vehicle B Vehicle C Vehicle D Vehicle F Node G1 Node G2 leadership Summary description

4a requested - - - - - requested none without leadership

4b - - requested requested - - - none without leadership

Appendices

4c requested - requested - - - - none without leadership

4d - - requested - requested - - none without leadership
4e - - requested - - - requested none without leadership
4f requested - - requested - - - none without leadership

4g - - - requested - - requested none without leadership

4h requested - - - requested - - none without leadership

4i - - - - requested - requested none without leadership

5a requested - requested requested - - requested none without leadership

185
5b requested - requested - requested - requested none without leadership
requested & requested &
6a - - - - - Vehicle A with multiple leadership
leading leading
requested & requested &
6b - - - - - Vehicle B with multiple leadership
leading leading
requested & requested &
6c - - - - - VehicleC with multiple leadership
leading leading
requested & requested &
6d - - - - - Vehicle C with multiple leadership
leading leading
requested & requested &
6e - - - - - Vehicle C with multiple leadership
leading leading
requested & requested &
6f - - - - - Vehicle D with multiple leadership
leading leading
requested & requested &
6g - - - - - Vehicle F with multiple leadership
leading leading
requested & requested &
6h - - - - - Vehicle F with multiple leadership
leading leading

556
OR
Appendices

General remark:

After each step the leading vehicle(s) shall be determined or it shall be detected that there is none. This
shall be done by the corresponding NADI entries (dynamic property 511: "requests leading", dynamic
property 512: "is leading"), through the distributed inauguration frames (dynamic property 510: "was
leading", dynamic property 511: "requests leading"), and through the type of R telegrams distributed by
the different nodes ("is leading"). After each step the number of nodes shall also be checked in the
content of the topography response telegram (0A04, and this code itself too) and the number of vehicles
through the NADI content (0A01, ditto). The reply telegram code shall also be checked for setOpMode
(0A03) and multicastRequest (FA07). The reply telegram source function shall always be 15, the reply
telegram status shall always be 0.

186 556
OR
 Test sequence:
Step Action Expected result Check Expected configuration
& ref.
All NADIs are unconfirmed and TCN addresses as specified as far as predictable
Appendices

shall contain 8 entries.

Empty entries mean: no check necesary

1 turn on all vehicles TCN & UIC inauguration 510: - 511: - 512: - Standard addresses
1 with all nodes
2 set B strong and then [TCN &] 2 UIC inaugurations 510: - 511: - 512: -
1 set B weak with all nodes A B C D E F G1 G2

U01 U02 U03 U04 U05 U06 U07

T02 T01 T63 T62 T62 T62 T61 T60

3 leading request UIC inauguration 510: - 511: A 512:A see above

2a on A for direction 1 with all nodes
4 leading request UIC inauguration 510: A 511: A, G2 512: A see above
3b on G2 for direction 1 with all nodes
5 reset leading request UIC inauguration with all nodes 510: - 511:G2 512: G2
on A A B C D E F

187
2e, B G1 G2

U07 U06 U05 U04 U03 U02 U01

T02 T01 T63 T62 T62 T62 T61 T60

6 leading request UIC inauguration with all nodes 510: G2 511: A, G2 512:G2 see above
3I on A for direction 1
7 leading request UIC inauguration with all nodes 510: G2 511: A, C, 512: G2 see above
on C for direction 1 G2
8 reset leading request UIC inauguration with all nodes 510: G2 511: C, G2 512:G2 see above
3m, C on A

9 reset leading UIC inauguration with all nodes 510: - 511: C 512: C
2b, B request on G2 A B C D E F G1 G2

U01 U02 U03 U04 U05 U06 U07

T02 T01 T63 T62 T62 T62 T61 T60

10 leading request UIC inauguration with all nodes 510: C 511: A, C 512: C see above
3c on A for direction 1
11 leading request UIC inauguration with all nodes 510: C 511: A, C, F 512: C see above
on F for direction 2
12 reset leading UIC inauguration with all nodes 510: C 510: C, F 512: C see above
3d, C request on A

556
OR
 Step Action Expected result Check Expected configuration
&ref.
13 reset leading UIC inauguration with all nodes 510: - 511:F 512: F
2d, B request on C A B C D E F G1 G2

U07 U06 U05 U04 U03 U02 U01

Appendices

T02 T01 T63 T62 T62 T62 T61 T60

14 leading request UIC inauguration with all nodes 510:F 511: A, F 512: F see above
3i on A for direction 1
15 leading request UIC inauguration with all nodes 510: D 511: A, D 512: D see above
3f, D on D (direction 1)

16 reset leading UIC inauguration with all nodes 510: D 511: D 512:D see above
2c, C request on A

17 leading request UIC inauguration with all nodes 510: D 511: C, D 512: D see above
3g on G2 for direction 1
18 leading request UIC inauguration with all nodes 510: D 511:C, D, 512: D see above
on G2 for direction 1 G2

188
19 reset leading UIC inauguration with all nodes 510: D 511: D, G2 512:D see above
3h, C request on C

20 leading request UIC inauguration with all nodes 510: F 511: F, G2 512: F see above
3k, on F (direction 2)
D
21 leading request UIC inauguration with all nodes 510: F 511: C, F, 512:F see above
on C for direction 1 G2

22 reset leading UIC inauguration with all nodes 510: F 511: C, F 512: F see above
3j, request on G2
C
23 reset leading UIC inauguration with all nodes 510: - 511: C 512: C
2b, request on F A B C D E F G1 G2

B U01 U02 U03 U04 U05 U06 U07

T02 T01 T63 T62 T62 T62 T61 T60

24 leading request UIC inauguration with all nodes 510: C 511: C, G2 512: C see above
3e on G2 for direction 1

25 leading request UIC inauguration with all nodes 510: C 511: A, C, 512: C see above
on A for direction 1 G2

556
OR
 Step Action Expected result Check Expected configuration
&ref.
26 reset leading UIC inauguration with all nodes 510: - 511: A, G2 512: - see above
4a, B request on C
Appendices

27 leading request on C UIC inauguration with all nodes 510: - 511: A, C, 512: - se above
for direction 1 G2
28 leading request UIC inauguration with all nodes 510: - 511: A, C, 512: - see above
5a on D (direction 1) D, G2

29 leading request UIC inauguration with all nodes 510: - 511: A, C, 512:- see above
5b on F (direction 2) F, G2
30 reset leading UIC inauguration with all nodes 510: - 511: A, C, 512: - see above
A request on G2 F

31 reset leading UIC inauguration with all nodes 510: - 511: A, C 512: - see above
4c, request on F
A

189
32 leading request UIC inauguration with all nodes 510: - 511: A, C, 512:- see above
on F (direction 2) F
33 reset leading UIC inauguration with all nodes 510: - 511: C, F 512: - see above
4d, request on A
A
34 leading request UIC inauguration with all nodes 510: - 511: C, D 512:- see above
4b on D (direction 1)

35 leading request UIC inauguration with all nodes 510: - 511: C, D, 512: - see above
on G2 for direction 1 G2

36 reset leading UIC inauguration with all nodes 510: - 511: C, G2 512: - see above
4e, request on D
A
37 leading request UIC inauguration with all nodes 510: - 511: C, F, 512: - see above
on F (direction 2) G2
38 reset leading UIC inauguration with all nodes 510: - 510: F, G2 512: - see above
4j, request on C
A

556
OR
 Step Action Expected result Check Expected configuration
& ref
39 leading request UIC inauguration with all nodes 510: - 511: D, G2 512: - see above
4g on D (direction 1)
Appendices

40 reset leading UIC inauguration with all nodes 510: - 511: D 512: D
2c, request on G2 A B C D E F G1 G2

U07 U06 U05 U04 U03 U02 U01

A T02 T01 T63 T62 T62 T62 T61 T60

41 leading request
on F (direction 2)

42 leading request
on G2 for direction 1

Continuation for confirmed confguration:

Step Action Expected result Check Expected configuration

190
The specified results are valid for confirmed If a cell contains two train segments, the upper one represents
configurations and the NADI of the left train segment, and the lower one
- if specified - for unknown (actual) represents the NADI of the right train segment. If one segment
configurations only. If not explicitly specified has not been changed, only the other one is shown.
differently, the NADI(s) is/are confirmed.

43c confirm configuration UIC inauguration with all nodes 510: F 511: F, G2 512: F
A B C D E F G1 G2

U07 U06 U05 U04 U03 U02 U01

T02 T01 T63 T62 T62 T62 T61 T60

44c uncouple between TCN & UIC inauguration with left: 510: F 511: F 512: F
B, C F and G nodes ABCD and TCN & UIC A B C D E F
inauguration with nodes G1G2 right: 510: - 511: G2 512: G2
U07 U06 U05 U04 U03 U02 U01

number of NADI entries: 7 (leflt)

and 8 (right) G1 G2

U07 U06 U05 U04 U03 U02 U01

556
OR
 Step Action Expected result Check Expected configuration

45c Couple whole train TCN & UIC inaguration 510: F, G2 511:F, G2 512: - Standard addresses
6h with all nodes
number of NADI entries: 8
Appendices

46c reset leading UIC inauguration 510: - 511: F 512: F

2d, A request on G2 with all nodes A B C D E F G1 G2
number of NADI entries: 8 U07 U06 U05 U04 U03 U02 U01

47c uncouple between TCN & UIC inauguration left: 510: - 511: - 512: -
C and D with nodes ABC A B C
and TCN & UIC right: 510: F 511: F 512: F
U01 U02 U03 U04 U05 U06 U07
inauguration number of NADI entries: 7 (left)
with nodes DG1G2 and 8 (right) D E F G1 G2

U07 U06 U05 U04 U03 U02 U01

48c leading request UIC inauguration left: 510: - 511: C, 512: C left train segment:
on C for direction 1 with nodes ABC number of NADI entries: 7 (left)
A B C
U01 U02 U03 U04 U05 U06 U07

191
49c couple whole train TCN & UIC inauguration 510: C, F 511: C, F 512:- Standard addresses
6d with all nodes
number of actual NADI entries: 8

50c confirm configuration UIC inauguration 510:- 511: C, F 512:- Standard addresses
4d with all nodes
number of NADI entries: 8

51c reset leading request UIC inauguration 510:- 511: C 512: C Standard addresses
2b, on F with all nodes
number of NADI entries: 8
A
52c leading request UIC inauguration 510: C 511:C, G2 512: C Standard addresses
3e on G2 for direction 1 with all nodes
number of NADI entries: 8

53c uncouple between TCN & UIC inauguration left: 510: C 511: C 512: C
B, C and D with nodes ABC and A B C
TCN & UIC inauguration right: 510:- 511: G2 512: G2 U01 U02 U03 U04 U05 U06 U07
C
with nodes DG1G2
number of NADI entries:
7 (leflt) and 8 (right) D E F G1 G2

U07 U06 U05 U04 U03 U02 U01

556
OR
 Step Action Expected result Check Expected configuration

54c couple whole train TCN & UIC inauguration 510: C, G2 511: C, G2 512:- Standard addresses
6e with all nodes
number of actual NADI entries: 8
Appendices

55c confirm configuration UIC inauguraiton 510:- 511: C, G2 512:- Standard addresses
4e with all nodes
number of NADI entries: 8

56c leading request UIC inauguration 510:- 511: A, C, 512:- Standard addresses
on A for direction 1 with all nodes G2
number of NADI entries: 8

57c uncouple between TCN & UIC inauguration left: 510:- 511: A, C 512:-
A C and D with nodes ABC and A B C
TCN & UIC inauguration right: 510:- 511: G2 512: G2 U01 U02 U03 U04 U05 U06 U07
with nodes DG1 G2
number of NADI entries:
D E F

192
7 (left) and 8 (right) G1 G2

U07 U06 U05 U04 U03 U02 U01

58c reset leading UIC inauguration left: 510: - 511: A 512: A see above
A request on C with nodes ABC
number of NADI entries: 7 (left)

59c couple whole train TCN & UIC inauguration 510: A, G2 511: A, G2 512: - Standard addresses
6a with all nodes
number of actual NADI entries: 8

60c confirm configuration UIC inauguration with all nodes 510: - 511: A, G2 512: - Standard addresses
3b
number of NADI entries: 8

61c reset leading UIC inauguration 510:- 511: A 512: A Standard addresses
2a, request on G2 with all nodes
number of NADI entries: 8
A

62c leading request UIC inauguration 510: A 511: A, C 512: A Standard addresses
3a on C for direction 1 with all nodes
number of NADI entries: 8

556
OR
 Step Action Expected result Check Expected configuration

63c uncouple between TCN & UIC inauguration left: 510: A 511: A 512: A
B, C B and C with nodes AB and TCN & UIC A B
inauguration with right: 510: - 511: C 512: C
U01 U02 U03 U04 U05 U06 U07
Appendices

nodes CDG1G2
number of NADI entries:
7 (left) and 8 (right)
C D E F G1 G2

U01 U02 U03 U04 U05 U06 U07

64c couple whole train TCN & UIC inauguration 510: A, C 511: A, C 512:- Standard addresses
6c with all nodes
number of NADI entries: 8

65c leading request UIC inauguration 510:- 511: A, C, 512:- Standard addresses
on D (direction 1) with all nodes D
number of NADI entries: 8

66c reset leading UIC inauguration 510:- 511: A, D 512:- Standard addresses
4f, A request on C with all nodes
number of NADI entries: 8

193
67c uncouple between TCN & UIC inauguration left: 510:- 511: A 512: A
A C and D with nodes ABC and A B C
right: 510:- 511: D 512: D
TCN & UIC inauguration U01 U02 U03 U04 U05 U06 U07
with nodes DG1 G2
number of NADI entries:
7 (left) and 8 (right) D E F G1 G2

U01 U02 U03 U04 U05 U06 U07

68c couple whole train TCN & UIC inauguration 510: A, D 511: A, D 512:- Standard addresses
6f with all nodes
number of NADI entries: 8

69c leading request UIC inauguration 510:- 511: A, F 512:- Standard addresses
4h on F (direction 2) with all nodes
number of NADI entries: 8

70c uncouple between TCN & UIC inauguration left: 510:- 511: A 512: A left train segment
A C and D with nodes ABC and TCN & UIC
right: 510:- 511: F 512: F
inauguration with
nodes DG1 G2 A B C

U01 U02 U03 U04 U05 U06 U07

number of NADI entries:

7 (left) and 8 (right) D E F G1 G2

U07 U06 U05 U04 U03 U02 U01

556
OR
 Step Action Expected result Check Expected configuration

71c couple whole train TCN & UIC inauguration 510: A, F 511: A, F 512:- Standard addresses
6g with all nodes
number of actual NADI entries: 8
Appendices

72c confirm configuration UIC inauguration 510:- 511: A, F 512:- Standard addresses
4h with all nodes
number of NADI entries: 8

73c leading request UIC inauguration 510:- 511: A, D 512:- Standard addresses
4f on D (direction1) with all nodes
number of NADI entries: 8

74c leading request UIC inauguration 510:- 511: A, C, 512:- Standard addresses
on C for direction 1 with all nodes D
number of NADI entries: 8

75c uncouple between TCN & UIC inauguration with left: 510:- 511: A, C 512:-
C and D nodes ABC and TCN & A B C

194
A
UIC inauguraiton right: 510:- 511: D 512: D U01 U02 U03 U04 U05 U06 U07
with nodes DG1G2
number of NADI entries:
7 (left) and 8 (right) D E F G1 G2

U01 U02 U03 U04 U05 U06 U07

76c reset leading UIC inauguration left: 510: - 511: C 512: C see above
A request on A with nodes ABC
number of NADI entries: 7 (left)

77c couple whole train TCN & UIC inauguration 510: C, D 511: C, D 512:- Standard addrsses
6b with all nodes
number of NADI entries: 8

556
OR
Appendices

H.6.3.6 - Inhibit functionality test suite

Purpose:

Test the correct handling of an inhibit request on a node and its withdrawal.

Reference:

Appendix A - page 35

Composition:

See reference composition.

NB : Following basic cases shall be covered:

Test case Reference to test steps

1. non-master end node failure 4, 8 a
2. non-master intermediate node failure 3, 17
3. master end node failure 8 a, 15
4. master intermediate node failure 10
5. occurrence of end node(s) 11, 20
6. occurrence of intermediate node(s) 7, 18
a. In case 8 it is not predictable if node G2 is master or not. So, this step may be test case 1 or 3.

195 556
OR
 Test sequence:
Step Action Expected result Check Expected configuration
No vehicle is leading, the configuration
is unconfirmed. Checks will be done
Appendices

on the NADI. The inhibit bit shall be

checked within the mapping server
status reply telegram from the TCN
master. The reply telegram source
function shall always be 15, the reply
telegram status shall always be 0,
and the reply telegram code shall be
checked (0A01 for getNADI, 0A22
for getStatus, 0A03 for setOpMode, FA05
for set inhibit / cancel inhibit).
Empty entries mean: no check necessary.

1 turn on all nodes TCN & UIC inauguration NADI contains 8 entries Standard addresses
with all nodes no inhibit bit set
2 set D strong;

196
set D weak;
send inhibit request to G1

3 turn B, C off no inauguration NADI contains 8 entries Standard addresses

inhibit bit set
4 turn A off TCN & UIC inauguration NADI contains 5 entries
with nodes DG1G2 no inhibit bit set
D E F G1 G2

U01 U02 U03 U04

5 turn A on TCN & UIC inauguration NADI contains 6 entries

with nodes ADG1 G2 no inhibit bit set A D E F G1 G2

U01 U02 U03 U04 U05

6 send inhibit no inauguration NADI contains 6 entries see above

request to D no inhibit bit set
7 turn B on no inauguration NADI contains 6 entries see above
no inhibit bit set
8 turn G2 off TCN & UIC inauguration NADI contains 6 entries
with nodes ABDG1 no inhibit bit set A B D E F G1

U01 U02 U03 U04 U05 U06

556
OR
 Step Action Expected result Check Expected configuration

9 set B strong and then set B weak [TCN &] 2 UIC inaugurations NADI contains 6 entries
with nodes ABDG1 no inhibit bit set A B D E F G1

U01 U02 U04 U05 U06 U07

T02 T01 T63 T63 T63 T62
Appendices

10 send inhibit request to A; TCN & UIC inauguration NADI contains 5 entries
turn B off with nodes ADG1 no inhibit bit set A D E F G1

U01 U02 U03 U04 U05

11 send inhibit request to A; no inauguration NADI contains 5 entries see above

turn G2 on no inhibit bit set

12 reset inhibit request on A TCN & UIC inauguration NADI contains 6 entries
with nodes ADG1 G2 no inhibit bit set A D E F G1 G2

U01 U02 U03 U04 U05

13 turn all nodes on

197
14 set G2 strong ; [TCN &] 2 UIC inaugurations NADI contains 8 entries
set G2 weak ; with all nodes inhibit bit set A B C D E F G1 G2
send inhibit request to B U01 U02 U03 U04 U05 U06 U07
T06 T05 T04 T03 T03 T03 T02 T01

15 turn G2 off TCN & UIC inauguration NADI contains 7 entries

with nodes ABCDG1 no inhibit bit set A B C D E F G1

U01 U02 U03 U04 U05 U06 U07

16 set D strong; [TCN &] 2 UIC inaugurations NADI contains 7 entries

set D weak with nodes ABCDG1 no inhibit bit set A B C D E F G1

U01 U02 U03 U04 U05 U06 U07

T61 T62 T63 T01 T01 T01 T02

17 send inhibit request to A no inauguration NADI contains 7 entries see above

turn B, C off no inhibit bit set

18 turn C on TCN & UIC inauguration NADI contains 6 entries

with nodes ACDG1 no inhibit bit set A C D E F G1

U01 U02 U03 U04 U05 U06

19 turn on all nodes and

uncouple between
C and D

556
OR
 Step Action Expected result Check Expected configuration

20 send inhibit request to no inauguration NADI contains 3 entries (left) left train segment:
B and couple whole train and 5 entries (right)
inhibit bit set (left)
A B C
Appendices

U01 U02 U03

right train segment:

D E F G1 G2

U01 U02 U03 U04

21 reset inhibit rquest on B TCN & UIC inauguration NADI contains 8 entries Standard addresses
with all nodes no inhibit bit set

198
556
OR
Appendices

H.6.3.7 - Group handling test suite

Purpose:

Test the correct administration of read, write and delete group telegrams for single groups and for lists
of groups.

Reference:

Appendix A - page 35.

Composition:

See reference composition.

NB : Following basic cases shall be covered:

Test case Reference to test steps
1. write single group to one node 1
2. write single group to all nodes (multicast) 15
3. write list of groups to one node 2, 4
4. write list of groups to all nodes (multicast) 3
5. read single group (from one node) 5
6. read group list (from one node) 8
7. delete single group in one node 11
8. delete all groups in one node 10
9. delete all groups in all nodes (multicast) 16
10. write single existing group to one node 9
11. write list of groups with existing groups to one node 12
12. write single illegal group number 13, 14
13. read non-existing group 6
14. delete non-existing group 7

199 556
OR
 Test sequence:
Step Action Expected result
The syntax of a group in this column is: The only relevant result is the group directory of the specified nodes. The result shall be checked by means
of the readAllGroups telegram. The group identifiers shall always be set as defined on the left. The reply
Appendices

<group number> '('<list of UIC ids>')' telegram source function shall always be 15, the reply telegram status shall always be 0, and the reply
telegram code shall be checked (BA01 for readGroup, BA02 for readAllGroups, BA03 for writeGroup, BA04
The group identifier (32 unicode characters) for writeGroupList, BA05 for deleteGroup, BA06 for deleteAllGroups, and FA07 for multiCastRequest).
shall be initialized with blanks and shall start with
the decimal representation of the group number

1 write group 201 (24001, 24002, 24003, …, node A:

24022) to vehicle A 201 (24001, 24002, 24003, …, 24022)

200
2 write group list: node A:
240 (24001, 24002, 24003, …, 24022), 201 (24001, 24002, 24003, …, 24022)
241 (24101, 24102, 24103, …, 24122), node B:
242 (24201, 24202, 24203, …, 24222), 240 (24001, 24002, 24003, …, 24022), 241 (24101, 24102, 24103, …, 24122),
243 (24301, 24302, 24303, …, 24322), 242 (24201, 24202, 24203, …, 24222), 243 (24301, 24302, 24303, …, 24322),
244 (24401, 24402, 24403, …, 24422), 244 (24401, 24402, 24403, …, 24422), 245 (24501, 24502, 24503, …, 24522),
245 (24501, 24502, 24503, …, 24522), 246 (24601, 24602, 24603, …, 24622), 247 (24701, 24702, 24703, …, 24722),
246 (24601, 24602, 24603, …, 24622), 248 (24801, 24802, 24803, …, 24822), 249 (24901, 24902, 24903, …, 24922),
247 (24701, 24702, 24703, …, 24722), 250 (25001, 25002, 25003, …, 25022), 251 (25101, 25102, 25103, …, 25122),
248 (24801, 24802, 24803, …, 24822), 252 (25201, 25202, 25203, …, 25222), 253 (25301, 25302, 25303, …, 25322),
249 (24901, 24902, 24903, …, 24922), 254 (25401, 25402, 25403, …, 25422)
250 (25001, 25002, 25003, …, 25022),
251 (25101, 25102, 25103, …, 25122),
252 (25201, 25202, 25203, …, 25222),
253 (25301, 25302, 25303, …, 25322),
254 (25401, 25402, 25403, …, 25422)
to vehicle B

556
OR
 Step Action Expected result

3 write group list: node A:

220 (22001, 22002, 22003, …, 22022), 201 (24001, 24002, 24003, …, 24022), 220 (22001, 22002, 22003, …, 22022),
221 (22101, 22102, 22103, …, 22122), 221 (22101, 22102, 22103, …, 22122), 222 (22201, 22202, 22203, …, 22222),
222 (22201, 22202, 22203, …, 22222), 223 (22301, 22302, 22303, …, 22322), 224 (22401, 22402, 22403, …, 22422),
Appendices

223 (22301, 22302, 22303, …, 22322), 225 (22501, 22502, 22503, …, 22522), 226 (22601, 22602, 22603, …, 22622),
224 (22401, 22402, 22403, …, 22422), 227 (22701, 22702, 22703, …, 22722), 228 (22801, 22802, 22803, …, 22822),
225 (22501, 22502, 22503, …, 22522), 229 (22901, 22902, 22903, …, 22922), 230 (23001, 23002, 23003, …, 23022),
226 (22601, 22602, 22603, …, 22622), 231 (23101, 23102, 23103, …, 23122), 232 (23201, 23202, 23203, …, 23222),
227 (22701, 22702, 22703, …, 22722), 233 (23301, 23302, 23303, …, 23322), 234 (23401, 23402, 23403, …, 23422)
228 (22801, 22802, 22803, …, 22822), node B:
229 (22901, 22902, 22903, …, 22922), 220 (22001, 22002, 22003, …, 22022), 221 (22101, 22102, 22103, …, 22122),
230 (23001, 23002, 23003, …, 23022), 222 (22201, 22202, 22203, …, 22222), 223 (22301, 22302, 22303, …, 22322),
231 (23101, 23102, 23103, …, 23122), 224 (22401, 22402, 22403, …, 22422), 225 (22501, 22502, 22503, …, 22522),
232 (23201, 23202, 23203, …, 23222), 226 (22601, 22602, 22603, …, 22622), 227 (22701, 22702, 22703, …, 22722),
233 (23301, 23302, 23303, …, 23322), 228 (22801, 22802, 22803, …, 22822), 229 (22901, 22902, 22903, …, 22922),
234 (23401, 23402, 23403, …, 23422) 230 (23001, 23002, 23003, …, 23022), 231 (23101, 23102, 23103, …, 23122),
to vehicle A as multicast telegram 232 (23201, 23202, 23203, …, 23222), 233 (23301, 23302, 23303, …, 23322),
234 (23401, 23402, 23403, …, 23422), 240 (24001, 24002, 24003, …, 24022),

201
241 (24101, 24102, 24103, …, 24122), 242 (24201, 24202, 24203, …, 24222),
243 (24301, 24302, 24303, …, 24322), 244 (24401, 24402, 24403, …, 24422),
245 (24501, 24502, 24503, …, 24522), 246 (24601, 24602, 24603, …, 24622),
247 (24701, 24702, 24703, …, 24722), 248 (24801, 24802, 24803, …, 24822),
249 (24901, 24902, 24903, …, 24922), 250 (25001, 25002, 25003, …, 25022),
251 (25101, 25102, 25103, …, 25122), 252 (25201, 25202, 25203, …, 25222),
253 (25301, 25302, 25303, …, 25322), 254 (25401, 25402, 25403, …, 25422)
nodes C, D, G1, G2:
220 (22001, 22002, 22003, …, 22022), 221 (22101, 22102, 22103, …, 22122),
222 (22201, 22202, 22203, …, 22222), 223 (22301, 22302, 22303, …, 22322),
224 (22401, 22402, 22403, …, 22422), 225 (22501, 22502, 22503, …, 22522),
226 (22601, 22602, 22603, …, 22622), 227 (22701, 22702, 22703, …, 22722),
228 (22801, 22802, 22803, …, 22822), 229 (22901, 22902, 22903, …, 22922),
230 (23001, 23002, 23003, …, 23022), 231 (23101, 23102, 23103, …, 23122),
232 (23201, 23202, 23203, …, 23222), 233 (23301, 23302, 23303, …, 23322),
234 (23401, 23402, 23403, …, 23422)

556
OR
 Step Action Expected result

4 write group list:: node A:

201 (20101, 20102, 20103, …, 20122), 201 (24001, 24002, 24003, …, 24022), 220 (22001, 22002, 22003, …, 22022),
202 (20201, 20202, 20203, …, 20222), 221 (22101, 22102, 22103, …, 22122), 222 (22201, 22202, 22203, …, 22222),
223 (22301, 22302, 22303, …, 22322), 224 (22401, 22402, 22403, …, 22422),
Appendices

203 (20301, 20302, 20303, …, 20322),

202 (20401, 20402, 20403, …, 20422), 225 (22501, 22502, 22503, …, 22522), 226 (22601, 22602, 22603, …, 22622),
205 (20501, 20502, 20503, …, 20522), 227 (22701, 22702, 22703, …, 22722), 228 (22801, 22802, 22803, …, 22822),
206 (20601, 20602, 20603, …, 20622), 229 (22901, 22902, 22903, …, 22922), 230 (23001, 23002, 23003, …, 23022),
207 (20701, 20702, 20703, …, 20722), 231 (23101, 23102, 23103, …, 23122), 232 (23201, 23202, 23203, …, 23222),
208 (20801, 20802, 20803, …, 20822), 233 (23301, 23302, 23303, …, 23322), 234 (23401, 23402, 23403, …, 23422)
209 (20901, 20902, 20903, …, 20922), node B:
210 (21001, 21002, 21003, …, 21022), 201 (20101, 20102, 20103, …, 20122), 202 (20201, 20202, 20203, …, 20222),
211 (21101, 21102, 21103, …, 21122), 203 (20301, 20302, 20303, …, 20322), 202 (20401, 20402, 20403, …, 20422),
212 (21201, 21202, 21203, …, 21222), 205 (20501, 20502, 20503, …, 20522), 206 (20601, 20602, 20603, …, 20622),
213 (21301, 21302, 21303, …, 21322), 207 (20701, 20702, 20703, …, 20722), 208 (20801, 20802, 20803, …, 20822),
214 (21401, 21402, 21403, …, 21422) 209 (20901, 20902, 20903, …, 20922), 210 (21001, 21002, 21003, …, 21022),
to vehicle B 211 (21101, 21102, 21103, …, 21122), 212 (21201, 21202, 21203, …, 21222),
213 (21301, 21302, 21303, …, 21322), 214 (21401, 21402, 21403, …, 21422),
write group list:: 215 (21501, 21502, 21503, …, 21522), 216 (21601, 21602, 21603, …, 21622),

202
215 (21501, 21502, 21503, …, 21522), 217 (21701, 21702, 21703, …, 21722), 218 (21801, 21802, 21803, …, 21822),
216 (21601, 21602, 21603, …, 21622), 219 (21901, 21902, 21903, …, 21922), 220 (22001, 22002, 22003, …, 22022),
217 (21701, 21702, 21703, …, 21722), 221 (22101, 22102, 22103, …, 22122), 222 (22201, 22202, 22203, …, 22222),
218 (21801, 21802, 21803, …, 21822), 223 (22301, 22302, 22303, …, 22322), 224 (22401, 22402, 22403, …, 22422),
219 (21901, 21902, 21903, …, 21922), 225 (22501, 22502, 22503, …, 22522), 226 (22601, 22602, 22603, …, 22622),
235 (23501, 23502, 23503, …, 23522), 227 (22701, 22702, 22703, …, 22722), 228 (22801, 22802, 22803, …, 22822),
236 (23601, 23602, 23603, …, 23622), 229 (22901, 22902, 22903, …, 22922), 230 (23001, 23002, 23003, …, 23022),
237 (23701, 23702, 23703, …, 23722), 231 (23101, 23102, 23103, …, 23122), 232 (23201, 23202, 23203, …, 23222),
238 (23801, 23802, 23803, …, 23822), 233 (23301, 23302, 23303, …, 23322), 234 (23401, 23402, 23403, …, 23422),
239 (23901, 23902, 23903, …, 23922) 235 (23501, 23502, 23503, …, 23522), 236 (23601, 23602, 23603, …, 23622),
to vehicle B 237 (23701, 23702, 23703, …, 23722), 238 (23801, 23802, 23803, …, 23822),
239 (23901, 23902, 23903, …, 23922), 240 (24001, 24002, 24003, …, 24022),
241 (24101, 24102, 24103, …, 24122), 242 (24201, 24202, 24203, …, 24222),
243 (24301, 24302, 24303, …, 24322), 244 (24401, 24402, 24403, …, 24422),
245 (24501, 24502, 24503, …, 24522), 246 (24601, 24602, 24603, …, 24622),
247 (24701, 24702, 24703, …, 24722), 248 (24801, 24802, 24803, …, 24822),
249 (24901, 24902, 24903, …, 24922), 250 (25001, 25002, 25003, …, 25022),
251 (25101, 25102, 25103, …, 25122), 252 (25201, 25202, 25203, …, 25222),
253 (25301, 25302, 25303, …, 25322), 254 (25401, 25402, 25403, …, 25422)

556
OR
 Step Action Expected result
nodes C, D, G1, G2:
220 (22001, 22002, 22003, …, 22022), 221 (22101, 22102, 22103, …, 22122),
222 (22201, 22202, 22203, …, 22222), 223 (22301, 22302, 22303, …, 22322),
Appendices

224 (22401, 22402, 22403, …, 22422), 225 (22501, 22502, 22503, …, 22522),
226 (22601, 22602, 22603, …, 22622), 227 (22701, 22702, 22703, …, 22722),
228 (22801, 22802, 22803, …, 22822), 229 (22901, 22902, 22903, …, 22922),
230 (23001, 23002, 23003, …, 23022), 231 (23101, 23102, 23103, …, 23122),
232 (23201, 23202, 23203, …, 23222), 233 (23301, 23302, 23303, …, 23322),
234 (23401, 23402, 23403, …, 23422)

5 read group 202 from vehicle B Returns

202 (20201, 20202, 20203, …, 20222),
no change within the nodes’ group directories

6 read group 202 from vehicle A returns status > 200 (within UIC header of reply telegram): group does not exist
no change within the nodes’ group directories

203
7 delete group 202 in vehicle A returns status > 200 (within UIC header of reply telegram): group does not exist
no change within the nodes’ group directories

8 read all groups from vehicle B returns

201 (20101, 20102, 20103, …, 20122), 202 (20201, 20202, 20203, …, 20222),
203 (20301, 20302, 20303, …, 20322), 202 (20401, 20402, 20403, …, 20422),
205 (20501, 20502, 20503, …, 20522), 206 (20601, 20602, 20603, …, 20622),
207 (20701, 20702, 20703, …, 20722), 208 (20801, 20802, 20803, …, 20822),
209 (20901, 20902, 20903, …, 20922), 210 (21001, 21002, 21003, …, 21022),
211 (21101, 21102, 21103, …, 21122), 212 (21201, 21202, 21203, …, 21222),
213 (21301, 21302, 21303, …, 21322), 214 (21401, 21402, 21403, …, 21422),
215 (21501, 21502, 21503, …, 21522), 216 (21601, 21602, 21603, …, 21622),
217 (21701, 21702, 21703, …, 21722), 218 (21801, 21802, 21803, …, 21822),
219 (21901, 21902, 21903, …, 21922), 220 (22001, 22002, 22003, …, 22022),
221 (22101, 22102, 22103, …, 22122), 222 (22201, 22202, 22203, …, 22222),
223 (22301, 22302, 22303, …, 22322), 224 (22401, 22402, 22403, …, 22422),
225 (22501, 22502, 22503, …, 22522), 226 (22601, 22602, 22603, …, 22622),
227 (22701, 22702, 22703, …, 22722), 228 (22801, 22802, 22803, …, 22822),
229 (22901, 22902, 22903, …, 22922), 230 (23001, 23002, 23003, …, 23022),
231 (23101, 23102, 23103, …, 23122), 232 (23201, 23202, 23203, …, 23222),
233 (23301, 23302, 23303, …, 23322), 234 (23401, 23402, 23403, …, 23422),
235 (23501, 23502, 23503, …, 23522), 236 (23601, 23602, 23603, …, 23622),
237 (23701, 23702, 23703, …, 23722), 238 (23801, 23802, 23803, …, 23822),

556
OR
 Step Action Expected result
239 (23901, 23902, 23903, …, 23922), 240 (24001, 24002, 24003, …, 24022),
241 (24101, 24102, 24103, …, 24122), 242 (24201, 24202, 24203, …, 24222),
243 (24301, 24302, 24303, …, 24322), 244 (24401, 24402, 24403, …, 24422),
245 (24501, 24502, 24503, …, 24522), 246 (24601, 24602, 24603, …, 24622),
Appendices

247 (24701, 24702, 24703, …, 24722), 248 (24801, 24802, 24803, …, 24822),
249 (24901, 24902, 24903, …, 24922), 250 (25001, 25002, 25003, …, 25022),
251 (25101, 25102, 25103, …, 25122), 252 (25201, 25202, 25203, …, 25222),
253 (25301, 25302, 25303, …, 25322), 254 (25401, 25402, 25403, …, 25422)
no change within the nodes’ group directories

9 write group 201 (1, 2, 3, …, 22) to vehicle A returns status > 200 (within UIC header of reply telegram): group already exists
no change within the nodes’ group directories

10 delete all groups in vehicle A node B:

delete all groups in vehicle C 201 (20101, 20102, 20103, …, 20122), 202 (20201, 20202, 20203, …, 20222),
delete all groups in vehicle D 203 (20301, 20302, 20303, …, 20322), 202 (20401, 20402, 20403, …, 20422),
delete all groups in vehicle G1 205 (20501, 20502, 20503, …, 20522), 206 (20601, 20602, 20603, …, 20622),
delete all groups in vehicle G2 207 (20701, 20702, 20703, …, 20722), 208 (20801, 20802, 20803, …, 20822),
209 (20901, 20902, 20903, …, 20922), 210 (21001, 21002, 21003, …, 21022),

204
211 (21101, 21102, 21103, …, 21122), 212 (21201, 21202, 21203, …, 21222),
213 (21301, 21302, 21303, …, 21322), 214 (21401, 21402, 21403, …, 21422),
215 (21501, 21502, 21503, …, 21522), 216 (21601, 21602, 21603, …, 21622),
217 (21701, 21702, 21703, …, 21722), 218 (21801, 21802, 21803, …, 21822),
219 (21901, 21902, 21903, …, 21922), 220 (22001, 22002, 22003, …, 22022),
221 (22101, 22102, 22103, …, 22122), 222 (22201, 22202, 22203, …, 22222),
223 (22301, 22302, 22303, …, 22322), 224 (22401, 22402, 22403, …, 22422),
225 (22501, 22502, 22503, …, 22522), 226 (22601, 22602, 22603, …, 22622),
227 (22701, 22702, 22703, …, 22722), 228 (22801, 22802, 22803, …, 22822),
229 (22901, 22902, 22903, …, 22922), 230 (23001, 23002, 23003, …, 23022),
231 (23101, 23102, 23103, …, 23122), 232 (23201, 23202, 23203, …, 23222),
233 (23301, 23302, 23303, …, 23322), 234 (23401, 23402, 23403, …, 23422),
235 (23501, 23502, 23503, …, 23522), 236 (23601, 23602, 23603, …, 23622),
237 (23701, 23702, 23703, …, 23722), 238 (23801, 23802, 23803, …, 23822),
239 (23901, 23902, 23903, …, 23922), 240 (24001, 24002, 24003, …, 24022),
241 (24101, 24102, 24103, …, 24122), 242 (24201, 24202, 24203, …, 24222),
243 (24301, 24302, 24303, …, 24322), 244 (24401, 24402, 24403, …, 24422),
245 (24501, 24502, 24503, …, 24522), 246 (24601, 24602, 24603, …, 24622),
247 (24701, 24702, 24703, …, 24722), 248 (24801, 24802, 24803, …, 24822),
249 (24901, 24902, 24903, …, 24922), 250 (25001, 25002, 25003, …, 25022),
251 (25101, 25102, 25103, …, 25122), 252 (25201, 25202, 25203, …, 25222),
253 (25301, 25302, 25303, …, 25322), 254 (25401, 25402, 25403, …, 25422)

556
OR
 Step Action Expected result

11 delete group 201 in vehicle B node B:

201 (20101, 20102, 20103, …, 20122), 202 (20201, 20202, 20203, …, 20222),
203 (20301, 20302, 20303, …, 20322), 202 (20401, 20402, 20403, …, 20422),
205 (20501, 20502, 20503, …, 20522), 206 (20601, 20602, 20603, …, 20622),
Appendices

207 (20701, 20702, 20703, …, 20722), 208 (20801, 20802, 20803, …, 20822),
209 (20901, 20902, 20903, …, 20922), 210 (21001, 21002, 21003, …, 21022),
211 (21101, 21102, 21103, …, 21122), 212 (21201, 21202, 21203, …, 21222),
213 (21301, 21302, 21303, …, 21322), 214 (21401, 21402, 21403, …, 21422),
215 (21501, 21502, 21503, …, 21522), 216 (21601, 21602, 21603, …, 21622),
217 (21701, 21702, 21703, …, 21722), 218 (21801, 21802, 21803, …, 21822),
219 (21901, 21902, 21903, …, 21922), 220 (22001, 22002, 22003, …, 22022),
221 (22101, 22102, 22103, …, 22122), 222 (22201, 22202, 22203, …, 22222),
223 (22301, 22302, 22303, …, 22322), 224 (22401, 22402, 22403, …, 22422),
225 (22501, 22502, 22503, …, 22522), 226 (22601, 22602, 22603, …, 22622),
227 (22701, 22702, 22703, …, 22722), 228 (22801, 22802, 22803, …, 22822),
229 (22901, 22902, 22903, …, 22922), 230 (23001, 23002, 23003, …, 23022),
231 (23101, 23102, 23103, …, 23122), 232 (23201, 23202, 23203, …, 23222),
233 (23301, 23302, 23303, …, 23322), 234 (23401, 23402, 23403, …, 23422),

205
235 (23501, 23502, 23503, …, 23522), 236 (23601, 23602, 23603, …, 23622),
237 (23701, 23702, 23703, …, 23722), 238 (23801, 23802, 23803, …, 23822),
239 (23901, 23902, 23903, …, 23922), 240 (24001, 24002, 24003, …, 24022),
241 (24101, 24102, 24103, …, 24122), 242 (24201, 24202, 24203, …, 24222),
243 (24301, 24302, 24303, …, 24322), 244 (24401, 24402, 24403, …, 24422),
245 (24501, 24502, 24503, …, 24522), 246 (24601, 24602, 24603, …, 24622),
247 (24701, 24702, 24703, …, 24722), 248 (24801, 24802, 24803, …, 24822),
249 (24901, 24902, 24903, …, 24922), 250 (25001, 25002, 25003, …, 25022),
251 (25101, 25102, 25103, …, 25122), 252 (25201, 25202, 25203, …, 25222),
253 (25301, 25302, 25303, …, 25322), 254 (25401, 25402, 25403, …, 25422)

12 write group list: returns status > 200 (within UIC header of reply telegram): group already exists
201 (20101, 20102, 20103, …, 20122), 202 (1, 2, 3) to vehicle B node B:
201 (20101, 20102, 20103, …, 20122), 202 (20201, 20202, 20203, …, 20222),
203 (20301, 20302, 20303, …, 20322), 202 (20401, 20402, 20403, …, 20422),
205 (20501, 20502, 20503, …, 20522), 206 (20601, 20602, 20603, …, 20622),
207 (20701, 20702, 20703, …, 20722), 208 (20801, 20802, 20803, …, 20822),
209 (20901, 20902, 20903, …, 20922), 210 (21001, 21002, 21003, …, 21022),
211 (21101, 21102, 21103, …, 21122), 212 (21201, 21202, 21203, …, 21222),
213 (21301, 21302, 21303, …, 21322), 214 (21401, 21402, 21403, …, 21422),
215 (21501, 21502, 21503, …, 21522), 216 (21601, 21602, 21603, …, 21622),
217 (21701, 21702, 21703, …, 21722), 218 (21801, 21802, 21803, …, 21822),
219 (21901, 21902, 21903, …, 21922), 220 (22001, 22002, 22003, …, 22022),
221 (22101, 22102, 22103, …, 22122), 222 (22201, 22202, 22203, …, 22222),

556
OR
 Step Action Expected result
223 (22301, 22302, 22303, …, 22322), 224 (22401, 22402, 22403, …, 22422),
225 (22501, 22502, 22503, …, 22522), 226 (22601, 22602, 22603, …, 22622),
227 (22701, 22702, 22703, …, 22722), 228 (22801, 22802, 22803, …, 22822),
229 (22901, 22902, 22903, …, 22922), 230 (23001, 23002, 23003, …, 23022),
Appendices

231 (23101, 23102, 23103, …, 23122), 232 (23201, 23202, 23203, …, 23222),
233 (23301, 23302, 23303, …, 23322), 234 (23401, 23402, 23403, …, 23422),
235 (23501, 23502, 23503, …, 23522), 236 (23601, 23602, 23603, …, 23622),
237 (23701, 23702, 23703, …, 23722), 238 (23801, 23802, 23803, …, 23822),
239 (23901, 23902, 23903, …, 23922), 240 (24001, 24002, 24003, …, 24022),
241 (24101, 24102, 24103, …, 24122), 242 (24201, 24202, 24203, …, 24222),
243 (24301, 24302, 24303, …, 24322), 244 (24401, 24402, 24403, …, 24422),
245 (24501, 24502, 24503, …, 24522), 246 (24601, 24602, 24603, …, 24622),
247 (24701, 24702, 24703, …, 24722), 248 (24801, 24802, 24803, …, 24822),
249 (24901, 24902, 24903, …, 24922), 250 (25001, 25002, 25003, …, 25022),
251 (25101, 25102, 25103, …, 25122), 252 (25201, 25202, 25203, …, 25222),
253 (25301, 25302, 25303, …, 25322), 254 (25401, 25402, 25403, …, 25422)

13 write group 200 (111) to vehicle A returns status > 200 (within UIC header of reply telegram): group number is invalid

206
no change within the nodes’ group directories

14 write group 255 (111) to vehicle B returns status > 200 (within UIC header of reply telegram): group number is invalid
no change within the nodes’ group directories

15 write group 202 (…) node A:

with all UIC IDs that exist in the actual current 202 (…)
train composition to vehicle B as multicast telegram node B:
201 (20101, 20102, 20103, …, 20122), 202 (20201, 20202, 20203, …, 20222),
203 (20301, 20302, 20303, …, 20322), 202 (20401, 20402, 20403, …, 20422),
205 (20501, 20502, 20503, …, 20522), 206 (20601, 20602, 20603, …, 20622),
207 (20701, 20702, 20703, …, 20722), 208 (20801, 20802, 20803, …, 20822),
209 (20901, 20902, 20903, …, 20922), 210 (21001, 21002, 21003, …, 21022),
211 (21101, 21102, 21103, …, 21122), 212 (21201, 21202, 21203, …, 21222),
213 (21301, 21302, 21303, …, 21322), 214 (21401, 21402, 21403, …, 21422),
215 (21501, 21502, 21503, …, 21522), 216 (21601, 21602, 21603, …, 21622),
217 (21701, 21702, 21703, …, 21722), 218 (21801, 21802, 21803, …, 21822),
219 (21901, 21902, 21903, …, 21922), 220 (22001, 22002, 22003, …, 22022),
221 (22101, 22102, 22103, …, 22122), 222 (22201, 22202, 22203, …, 22222),
223 (22301, 22302, 22303, …, 22322), 224 (22401, 22402, 22403, …, 22422),
225 (22501, 22502, 22503, …, 22522), 226 (22601, 22602, 22603, …, 22622),
227 (22701, 22702, 22703, …, 22722), 228 (22801, 22802, 22803, …, 22822),
229 (22901, 22902, 22903, …, 22922), 230 (23001, 23002, 23003, …, 23022),
231 (23101, 23102, 23103, …, 23122), 232 (23201, 23202, 23203, …, 23222),
233 (23301, 23302, 23303, …, 23322), 234 (23401, 23402, 23403, …, 23422),

556
OR
 Step Action Expected result
235 (23501, 23502, 23503, …, 23522), 236 (23601, 23602, 23603, …, 23622),
237 (23701, 23702, 23703, …, 23722), 238 (23801, 23802, 23803, …, 23822),
239 (23901, 23902, 23903, …, 23922), 240 (24001, 24002, 24003, …, 24022),
241 (24101, 24102, 24103, …, 24122), 242 (24201, 24202, 24203, …, 24222),
Appendices

243 (24301, 24302, 24303, …, 24322), 244 (24401, 24402, 24403, …, 24422),
245 (24501, 24502, 24503, …, 24522), 246 (24601, 24602, 24603, …, 24622),
247 (24701, 24702, 24703, …, 24722), 248 (24801, 24802, 24803, …, 24822),
249 (24901, 24902, 24903, …, 24922), 250 (25001, 25002, 25003, …, 25022),
251 (25101, 25102, 25103, …, 25122), 252 (25201, 25202, 25203, …, 25222),
253 (25301, 25302, 25303, …, 25322), 254 (25401, 25402, 25403, …, 25422)
nodes C, D, G1, G2:
202 (…)
Group 202 (except in vehicle B) shall contain valid UIC and TCN addresses according to the
actual current train composition

16 delete all groups in all nodes -

207
556
OR
Appendices

H.6.3.8 - E telegram error handling test suite

Check of the E telegram error handling

Purpose:
Test the handling of erroneous E telegrams that are addressed to the UMS (function 15).

Reference:
Point 5.7.3 - page 23,
Appendix A - page 35.

Composition:
See reference composition.

NB : It shall be ensured that invalid function codes will be rejected with status > 200.

Test sequence:

Step action Expected result

all telegrams shall be sent to function 15 checks will be done on the UIC header
(UIC mapping server)
1 send getNADI reply telegram (1 entry) to Reply telegram:
vehicle A UIC-Code: 0,
1. reserved Byte: 0,
source function: 15,
status > 200
(no reply telegram expected)
2 send getTopography reply telegram see above
(2 nodes) to vehicle G1
3 send getStatus reply telegram to vehicle B see above
4 send UIC header with code 0 to vehicle C see above
5 send UIC header with code 0x1007 to see above
vehicle D

208 556
OR
Appendices

H.6.3.9 - Sleep mode test suite

Purpose:
Test the correct handling of a sleep mode request on a node and its withdrawal.

Reference:
Appendix A - page 35

Composition:
See reference composition.

NB : Following basic cases shall be covered:

Test cases References to test steps
1. intermediate node is last active node before sleeping mode 4-6
2. end node is last active node before sleeping mode 1-3
3. turn off the master when not all other nodes have set sleep 7-12
requests
4. all nodes except one intermediate non-master node request 23-26
sleeping mode and that intermediate node fails
4. coupling and uncoupling of trains in sleeping mode 21-22
6. resetting of sleep requests 13-20

209 556
OR
 Test sequence:
Step action Expected result Check Expected configuration
No vehicle is leading, the configuration is unconfirmed. TCN addresses are specified as
Checks will be done on the NADI. The sleep bit shall be far as predictable.
Appendices

checked within the mapping server status reply

telegrams of all nodes. The reply telegram source
function shall always be 15, the reply telegram status
shall always be 0, and the reply telegram code shall be
checked (0A01 for getNADI, 0A22 for getStatus, 0A03
for setOpMode, FA04 for setSleepRequest /cancelSleepRequest).
Empty entries mean: no check necessary.

1 turn all nodes on TCN & UIC inauguration NADI contains 8 entries Standard addresses
with all nodes no sleep bit set
2 send sleep requests no inauguration NADI contains 8 entries Standard addresses
to ABCDG1 a sleep bit set in ABCDG1

3 send sleep request train in sleep modus All nodes are in sleep mode -

210
to G2

4 turn A off and then TCN & UIC inauguration NADI contains 8 entries Standard addresses
turn A on with all nodes no sleep bit set
5 send sleep requests no inauguration NADI contains 8 entries Standard addresses
to ABCG1 G2 sleep bit set in ABC G1 G2

6 send sleep train in sleep modus All nodes are in sleep mode -
request to D

a. The order of sleep request E telegrams to each node should be meaningless (as long as one remaining node does not request sleeping mode),
e.g. DCG1BA should have the same effect

556
OR
 Step Action Expected result Check Expected configuration

7 turn D off and TCN & UIC inauguration NADI contains 8 entries Standard addresses
then turn D on with all nodes no sleep bit set
8 set D strong and [TCN &] 2 UIC inaugurations NADI contains 8 entries
Appendices

then set D weak with all nodes no sleep bit set A B C D E F G1 G2

U01 U02 U03 U04 U05 U06 U07

T61 T62 T63 T01 T01 T01 T02 T03

9 send sleep no inauguration NADI contains 8 entries see above

requests to B sleep bit set in B

10 uncouple between left train segment: no sleep bit set

B and C right train segment: not checked

11 send sleep left train segment: sleep bit set in A

request to A right train segment: not checked

12 couple between TCN & UIC inauguration NADI contains 8 entries Standard addresses
B and C with all nodes no sleep bit set
13 send sleep request no inauguration NADI contains 8 entries sleep Standard addresses

211
to ABCDG1 bit set in : ABCDG1

14 reset sleep no inauguration NADI contains 8 entries Standard addresses

request on G1 sleep bit set in ABCD

15 send sleep no inauguration NADI contains 8 entries Standard addresses

request to G2 sleep bit set in : ABCDG2

16 reset sleep no inauguration NADI contains 8 entries Standard addresses

request on D sleep bit set in : ABCG2

17 send sleep no inauguration NADI contains 8 entries Standard addresses

request to G1 sleep bit set in: ABCG1G2

18 reset sleep no inauguration NADI contains 8 entries Standard addresses

request on A sleep bit set in : BCG1G2

19 send sleep no inauguration NADI contains 8 entries Standard addresses

request to D sleep bit set in : BCDG1G2

556
OR
 Step Action Expected result check Expected configuration

20 send sleep train in sleeping mode All nodes are in sleep mode -
request to A
Appendices

21 uncouple between train in sleeping mode All nodes are in sleep mode -
B and C

22 couple whole train train in sleeping mode All nodes are in sleep mode -

23 turn G2 off and then TCN & UIC inauguration NADI contains 8 entries Standard addresses
turn G2 on with all nodes no sleep bit set
24 set A strong and [TCN &] 2 UIC inaugurations NADI contains 8 entries
then set A weak with all nodes no sleep bit set A B C D E F G1 G2

U01 U02 U03 U04 U05 U06 U07

T01 T02 T03 T04 T04 T04 T05 T06

25 send sleep request no inauguration NADI contains 8 entries see above

to ACDG1G2 sleep bit set in : ACDG1G2
26 turn B off no inauguration NADI contains 8 entries see above

212
sleep bit set in : ACDG1G2

556
OR
Appendices

Record of updates

Version Date Change Reason for the change

001.01 01.11.2004 Change of the layout according to M1 New layout based on the UIC
guide M1
Adoption of a history of updates Increasing the usability
Adoption of a revision number Enhancement and redesign of the
versioning
001.02 01.08.2005 Change of the layout
Modification of the numbering of the UIC requirement
Appendices

213 556
OR
Appendices

Appendix I - Type approved train bus nodes in vehicles

that run in international services (Version
001.02, valid from 01.08.2005)

The list of type approved train bus nodes in vehicles that run in international services is to be found
on the UIC Website ([Link] Technical and Research/Products/Catalogue of products
technically approved by UIC/train bus.

214 556
OR
Appendices

Appendix J - Modification list (Version 002.02, valid from

01.08.2005)

The modification list is to be found on the UIC Website ([Link] Technical and
Research/Products/Catalogue of products technically approved by UIC/train bus.

215 556
OR
List of abbreviations

BMI Bus Management Interface

E-Data Event-oriented data

FTF Frame Type Field

GW Gateway-train bus node

IDI Inauguration Data Interface

IEC International Electrotechnical Commission

IGZ Train bus industry group

(Industriegruppe Zugbus)

ISBN International Standard Book Number

ISO International Standardization Organization

JDP Joint Development Project TCN

LL Link Layer

LME Layer Management Entity

LMI Link Layer to Messenger Interface

LPI Link Layer Process Data Interface

LSO Least Significant Octet

MC Multicast (Sending of messages to several train bus nodes)

MD Message Data

MDB Marshalling Data Base

MSO Most Significant Octet

MVB Multifunction Vehicle Bus

NADI Node Address & Attribute Directory

NMA Network Management Agent

NS Node Supervisor

NSDB Node Supervisor Database (Database of the GW - control module)

216 556
OR
PD Process Data

PDM Process Data Marshalling (bus spreading transfer (shunting) of process

variables)

PIL Processor Interface Library

PV Process Variable

R-Daten Regular data

RIC (Regolamento Internazionale Carrozze) "Agreement on the reciprocal

use of passenger and baggage vehicles in international traffic"

RTP Real Time Protocols

SC Single cast (Sending of messages only to one other train bus node)

Single Node Single node

SMAP Station Management Application Process

Strong Master Strong master

TC9 Technical Committee 9 (of IEC)

TCN Train Communication Network

TCN Adress Number between 1 and 63 which is given during the TCN inauguration

UAGT UIC Agent

UIC International Union of Railways

UIC Adress Also called the UIC sequence number, a number which is given on the
basis of the UIC address allocation algorithm

UIC ID Clear identification number for coaches, 11 significant places

UIMCS UIC Mapping Server Intelligent Multicast Server

UMS UIC Mapping Server

UMSI UIC Mapping Server Remote Interface

UNGS UIC NADI & Group Server

UTBC UIC Train Bus Configurator

UWTM UIC WTB Manager

Weak Master Weak master

WG22 Working Group 22 (of TC9 of IEC)

WTB Wired Train Bus

WTB-LL Wired Train Bus Link Layer

217 556
OR
Glossary

Bus capability In order to guarantee the transmission of information within passenger

trains over the train bus, the vehicles need to be suitably equipped.
Vehicles, which have none of the following features, must not be allowed
to run in these trains.
Regarding the capability of the vehicles to participate in the bus traffic,
the following features should be differentiated and marked as shown in
point:
- fully bus suitable vehicles
- only vehicles capable of train inauguration
- vehicles that are not capable of train inauguration, which, however, are
fitted with a cable for data transmission (cable vehicles).

Driving trailer A vehicle with a driving cab at least at one end of the vehicle from which
the traction and braking functions of a train can be controlled.

Leaflet Edition This is not a version number, but an indication that the leaflet has been
modified and reissued.

Locomotive A traction unit with no passenger or freight capacity. The traction and
braking functions of a train can be controlled from the cabs of the
locomotives.

Multiple Unit A number of vehicles put together to form a unit for the conveyance of
passengers and/or freight. The driving cabs of the multiple unit can be
located in spe-cial power cars (e.g. locomotives with only one cab) or in
end vehicles fitted with driving cabs. Groups of vehicles of the multiple
unit can be assembled into trainsets.

UIC Inauguration frame number

This corresponds to the edition number of the UIC Leaflet and the overall
version number indicated in the Modification List in Appendix J.

UIC R telegram version number

This corresponds to the edition number of the UIC Leaflet and the overall
version number indicated in the Modification List in Appendix J.

Passenger coach A passenger carrying vehicle without its own propulsion system.

Railcar A traction unit for the carriage of passengers and/or freight. The traction
and braking functions of a train can be controlled from the cabs of the
railcar.

Traction Unit Vehicle with its own power equipment.

Trainset Groups of coaches and/or railcars, which only have one common
connection to the train bus.

218 556
OR
UIC Leaflet UIC Leaflets are documents in which the results of work conducted in the
UIC study bodies and at UIC Headquarters, in some cases with the
support of industry, are officially set out. They are the product of joint
work and are approved by the Association's active members in the
relevant bodies (see Internal Regulation A17). The aim of UIC Leaflets
is to set down guidelines, standards and processes in the form of clear
provisions, in order to ensure interoperability and compatibility and to
foster technical progress and communication between members of the
Association in all areas of railway activity.

219 556
OR
Bibliography

1. UIC leaflets

International union of railways

UIC Leaflet 176: Specifications for passenger information displayed electronically in trains, 1st edition,
july 2001

UIC Leaflet 541-5: Brakes - Electropneumatic brake (ep brake) - Electropneumatic emergency brake
override (EBO), 3rd edition, may 2003

UIC Leaflet 550: Power supply installations for passenger stock, 11th edition, April 2005

UIC Leaflet 550-1: Electrical switch cabinets on passenger stock, 1st edition of 1.1.90

UIC Leaflet 553: Heating, ventilation and air-conditioning in coaches, 6th edition, February 2004

UIC Leaflet 555: Electric lighting in passenger rolling stock, 1st edition of 1.1.78 and 7 Amendments

UIC Leaflet 557: Diagnostics on passenger rolling stock, 2nd edition of 1.1.98

UIC Leaflet 558 : Remote control and data cable - Standard technical features for the equipping of RIC
coaches, 1st edition of 1.1.96

UIC Leaflet 560: Doors, footboards, windows, steps, handles and handrails of coaches and luggage
vans, 12th edition, March 2002

UIC Leaflet 568: Loudspeaker and telephone systems in RIC coaches - Standard technical
characteristics, 3rd edition of 1.1.96

UIC Leaflet 647: Functional model for the remote control of power cars (EU-Remote-Control),
(1st edition under preparation)

UIC Leaflet 660: Measures to ensure the technical compatibility of high-speed trains, 2nd edition,
August 2002

220 556-0
OR
2. European standards

European Committee for normalisation (CEN)

EN 5[Link] Railway appliances - Electronic equipment used on rolling stock, May 1996 (current
edition May 2003)

3. International standards

International Organization for Standardization (ISO) /

International Electrotechnical Commission (IEC)
ISO/IEC 8859-1: Information technology - 8-bit single-byte coded graphic character sets - Part 1: Latin
alphabet No. 1, April 1998

ISO/IEC 10646: Information technology - Universal multiple-octet coded character set (UCS),
December 2003

International Electrotechnical Commission (IEC)

CEI 61375 : Electric railway equipment - Train Bus - Part 1: Train Communication Network - TCN,
June 1998

4. ERRI reports

International Union of Railways (UIC)

ERRI B 108.3/DT 273: Transmission of information in the train by a central data line - Transmission of
information through the UIC 12-core train line: test with a token transmission system (SNCF/Alsthom),
August 1992

5. Miscellaneous

IGZ Doc. No. 16

UIC-Mapping-Server Specification V 1.0,

JDP / Adtranz
WTB link Layer 1.9 User’s Manual,

JDP / Siemens Transportation Systems

NS Data Base Handling, Rev. A

PDM User’s Manual, Rev. B.01

221 556-0
OR
 Warning

No part of this publication may be copied, reproduced or distributed by any means whatsoever, including
electronic, except for private and individual use, without the express permission of the International Union of
Railways (UIC). The same applies for translation, adaptation or transformation, arrangement or reproduction by
any method or procedure whatsoever. The sole exceptions - noting the author's name and the source - are
"analyses and brief quotations justified by the critical, argumentative, educational, scientific or informative nature
of the publication into which they are incorporated".
(Articles L 122-4 and L122-5 of the French Intellectual Property Code).
 International Union of Railways (UIC) - Paris, 2005

Printed by the International Union of Railways (UIC)

16, rue Jean Rey 75015 Paris - France, August 2005
Dépôt Légal August 2005

ISBN 2-7461-0964-6 (French version)

ISBN 2-7461-0965-4 (German version)
ISBN 2-7461-0966-2 (English version)

556
OR