Commission Regulation (EC) No 62/2006 of  23 December 2005  concerning the technical specification for interoperability relating to the telematic applications for freight subsystem of the trans-European conventional rail system   (Text with EEA relevance)
Date: 2005-12-23
Institutions: European Commission
Subjects: carriage of goods, freight rate, harmonisation of standards, rail transport, technical standard, telematics, trans-European network

18.1.2006

EN

Official Journal of the European Union

L 13/1

I

(Acts whose publication is obligatory)

COMMISSION REGULATION (EC) No 62/2006

of 23 December 2005

concerning the technical specification for interoperability relating to the telematic applications for
freight subsystem of the trans-European conventional rail system

(Text with EEA relevance)

THE COMMISSION OF THE EUROPEAN COMMUNITIES,

Having regard to the Treaty establishing the European Com-
munity,

Having regard to Directive 2001/16/EC of the European Parlia-
ment and of the Council of 19 March 2001 on the interoper-
ability of the trans-European conventional rail system (1), and in
particular Article 6(1) thereof,

Whereas:

(1)

(2)

(3)

In accordance with Article 2(c) of Directive 2001/16/EC,
the trans-European conventional rail system is subdi-
vided into structural and functional subsystems. Each of
the subsystems should be covered by a technical specifi-
cation for interoperability (TSI).

The first step in establishing a TSI is to have a draft TSI
drawn up by the European Association for Railway
Interoperability (AEIF) which was appointed as joint
representative body.

The AEIF has been given a mandate to draw up a draft
TSI for the telematics applications for freight subsystem
in accordance with Article 6(1) of Directive 2001/16/EC.
The basic parameters for this draft TSI were adopted by
Commission Decision 2004/446/EC of 29 April 2004
specifying the basic parameters of the Noise, Freight
Wagons and Telematics applications for freight Tech-
nical Specifications for Interoperability referred to in
Directive 2001/16/EC (2).

(1) OJ L 110, 20.4.2001, p. 1. Directive as amended by Directive
2004/50/EC (OJ L 164, 30.4.2004, p. 114, as corrected by OJ
L 220, 21.6.2004, p. 40).

(2) OJ L 155, 30.4.2004, p. 1, as corrected by OJ L 193, 1.6.2004, p. 1.

(4)

(5)

(6)

(7)

The draft TSI set up on the basis of the basic parameters
was accompanied by an introductory report containing a
cost-benefit analysis as provided for in Article 6(5) of
the Directive.

The draft TSI has been examined by the Committee set
up by Article 21 of Council Directive 96/48/EC of
23 July 1996 on the interoperability of the trans-Euro-
pean high-speed rail system (3) and in the light of the
introductory report.

According to Article 1 of Directive 2001/16/EC, the
conditions for achieving interoperability of the trans-Eur-
opean conventional
rail system concern the design,
construction, upgrading, renewal and operation of the
infrastructures and rolling stock contributing to the
functioning of the system to be put into service after the
date of entry into force of the Directive. In addition to
this, the efficient interconnection of the information and
communication systems of the different infrastructure
managers and operators is considered to be important.

Most of the existing telematics applications for freight
were developed and implemented according to national
market requirements. This hampers the continuity of
information services across borders, a key factor in
ensuring the quality of international rail services, notably
freight
in the fast-growing segment of
services.

international

(8)

A TSI on telematics should not demand the use of
specific technologies or technical solutions except where
this is strictly necessary for the interoperability of the
trans-European conventional rail system.

(3) OJ L 235, 17.9.1996, p. 6. Directive as last amended by Directive

2004/50/EC.

L 13/2

EN

Official Journal of the European Union

18.1.2006

(9)

(10)

The telematics TSI
is based on best available expert
knowledge at the time of preparation of the relevant
draft. Developments in technology, operational, safety or
social requirements may make it necessary to amend or
supplement this TSI. For this purpose, a Change Control
Management process will be devised to consolidate and
update the requirements of
the TSI. This updating
process will be placed under the auspices of the Euro-
pean Railway Agency established under Regulation (EC)
No 881/2004 of the European Parliament and of the
Council (1) once the Agency is operational, namely by
April 2006 at the latest. Where appropriate, a deeper
and more comprehensive review or updating procedure
which entails modifications to the due process identified
in this TSI will be
initiated in accordance with
Article 6(3) of Directive 2001/16/EC.

The application of a telematics TSI should take into
account specific criteria relating to technical and opera-
tional compatibility between the infrastructures and the
rolling stock to be brought into service and the systems
into which they are to be integrated. These compatibility
requirements entail a complex technical and economical
analysis that is to be done on a case-by-case basis. Such
analysis should take into account the interfaces between
the different subsystems referred to in Directive 2001/
16/EC, the different categories of lines and rolling stock
referred to in that Directive and the technical and opera-
tional environments of the existing network.

(11) However,

it is essential that such an analysis should
proceed within a framework of coherent implementation
rules and guidelines. That will necessitate the establish-
ment, by the representative bodies from the railway
sector acting on a European level, of a European strategy
for the implementation of a telematics TSI. Such a
strategy should indicate the stages required to move
from the present
fragmented national approaches in
to a situation of
regard to information management
seamless information exchange across the whole rail
network of the European Union.

(12)

To ensure an efficient implementation of the TSI, a Stra-
tegic European Deployment Plan must be developed.
Phasing plans to be set up by the actors must be co-ordi-
nated at European level and take into account existing
processes and IT systems of the railway undertakings
and the infrastructure managers. For
this purpose,
Railway Undertakings
and Infrastructure Managers
should contribute by providing functional and technical
telematics
information about
applications for freight.

the existing individual

system from becoming obsolete before its interconnec-
tions have been fully established. In addition, fragmented
deployment throughout the European rail system would
give rise to major costs and operational overheads due
to uncertainty as to continuity of service. The develop-
ment of a coherent framework plan at European level
would contribute to a harmonious development of seam-
less information services across the whole trans-Euro-
pean rail system, in compliance with the EU strategy for
the TEN-transport network. Such a plan should build
upon the corresponding national implementation plans
and should provide an appropriate knowledge base for
decision support by the different stakeholders — in par-
ticular, by the Commission in the allocation of financial
support to railway projects. The Commission should be
permitted to facilitate the appropriate means to ensure
coordination between the parties in the development of
such a European plan.

(14)

(15)

In order to avoid any confusion, it is necessary to state
the provisions of Decision 2004/446/EC which
that
the trans-European
concern the basic parameters of
conventional rail system shall not apply anymore.

The TSI on telematics applications for freight has a func-
tional nature. As a consequence, the main addressees of
the provisions contained in the TSI will be the market
actors. A Regulation addressed to a suitable range of
actors is more appropriate than a Decision addressed to
the Member States, in view of the implementation of the
provisions of the TSI.

(16)

The provisions of this Regulation are in conformity with
the opinion of the Committee set up by Directive 96/48/
EC,

HAS ADOPTED THIS REGULATION:

Article 1

The technical specification for interoperability (TSI) relating to
the ‘telematics applications
the
for
conventional rail system referred to in Article 6(1) of Direc-
tive 2001/16/EC shall be as set out in the Annex to this Regu-
lation.

subsystem of

freight’

The TSI shall be fully applicable to the infrastructure and
rolling stock of the trans-European conventional rail system as
defined in Annex I to Directive 2001/16/EC.

(13)

The target system required in the TSI should build upon
computer-based technology having a prospective opera-
tive life-span which is significantly less than that of
current traditional railway signalling and telecommunica-
tion facilities. That being so,
it calls for a proactive
rather than reactive deployment strategy to prevent the

(1) OJ L 164, 30.4.2004, p. 1, as corrected by OJ L 220, 21.6.2004,

p. 3.

Article 2

Railway Undertakings and Infrastructure Managers shall contri-
bute by providing functional and technical information about
the existing individual
telematics applications for freight as
defined in Chapter 2 of the Annex, not later than six months
after the entry into force of this Regulation.

18.1.2006

EN

Official Journal of the European Union

L 13/3

Article 3

Article 4

The representative bodies from the railway sector acting on a
European level as defined in Article 3(2) of Regulation (EC)
No 881/2004 shall establish a Strategic European Deployment
Plan for the attached TSI according with the criteria specified in
Chapter 7 of the Annex to this Regulation.

They shall forward this strategic plan to the Member States and
the Commission not later than one year after the entry into
force of this Regulation.

Those provisions of Decision 2004/446/EC which concern the
rail
basic parameters of
system shall no longer apply as from the date of the entry into
force of this Regulation.

the trans-European conventional

Article 5

This Regulation shall enter into force on the day following its
publication in the Official Journal of the European Union.

This Regulation shall be binding in its entirety and directly applicable in all Member States.

Done at Brussels, 23 December 2005.

For the Commission

Jacques BARROT

Vice-President

L 13/4

EN

Official Journal of the European Union

18.1.2006

Technical specification for interoperability relating to the telematic applications for freight subsystem of the
trans-European conventional rail system

ANNEX

CONTENTS:

1.

INTRODUCTION . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. .

1.1. Technical scope . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . .

1.2. Geographical scope . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . .

1.3. Content of this TSI . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . .

2. DEFINITION OF SUBSYSTEM/SCOPE . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. .

2.1. Functions within the scope of the TSI . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . .

2.2. Functions outside the scope of the TSI . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . .

2.3. Overview of the subsystem description . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . .

2.3.1.

Involved entities . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . .

2.3.2

Considered processes . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . .

2.3.3 General remarks . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

3. ESSENTIAL REQUIREMENTS .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

3.1. Compliance with the essential requirements . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

3.2. Essential requirements aspects . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

3.3. Aspects relating to general requirements . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

3.3.1.

Safety . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

3.3.2. Reliability and availability . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

3.3.3. Health . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

3.3.4.

Environmental protection . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

3.3.5. Technical compatibility . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

3.4. Aspects relating specifically to the telematic applications subsystem for freight . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

3.4.1. Technical compatibility . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

3.4.2. Reliability and availability . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

3.4.3. Health . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

3.4.4.

Safety . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4. CHARACTERISATION OF THE SUBSYSTEM . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

4.1.

Introduction . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

4.2. Functional and technical specifications of the subsystem . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

4.2.1. Consignment note data . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.2.

Path request . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.3. Train preparation .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.4. Train running forecast . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.5.

Service disruption information . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.6. Train location . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.7.

Shipment ETI/ETA . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.8. Wagon movement . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.9.

Interchange reporting . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.10. Data exchange for quality improvement . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.11. The main reference data .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.12. Various reference files and databases . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.13. Electronic transmission of documents . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.2.14. Networking and communication . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

6

6

6

7

7

7

7

8

8

9

11

12

12

12

12

12

13

13

13

14

14

14

14

14

15

15

15

15

16

17

22

25

27

28

30

32

35

36

38

40

44

44

18.1.2006

EN

Official Journal of the European Union

L 13/5

4.3. Functional and technical specifications of the interfaces . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

4.3.1.

Interfaces with the tsi infrastructure . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.3.2.

Interfaces with the TSI control/command and signalling . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.3.3.

Interfaces with the rolling stock subsystem . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.3.4.

Interfaces with the TSI operation and traffic management . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.4. Operating rules . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

4.4.1. Data quality . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.4.2. Operating the central repository . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

4.5. Maintenance rules . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

4.6. Professional qualifications . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

4.7. Health and safety conditions . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

4.8.

Infrastructure and rolling stock registers . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

5.

INTEROPERABILITY CONSTITUENTS . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

5.1. Definition . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

5.2. List of constituents . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

5.3.

‘Constituents’ performances and specifications . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

6. ASSESSMENT OF CONFORMITY AND/OR SUITABILITY FOR USE OF THE CONSTITUENTS AND
VERIFICATION OF THE SUBSYSTEM . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

6.1.

Interoperability constituents .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

6.1.1. Assessment procedures . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

6.1.2. Module . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

6.2. Subsystem telematic applications for freight . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

7.

IMPLEMENTATION . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

7.1. Modalities of application of this TSI . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

7.1.1.

Introduction . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

7.1.2.

Strategic european deployment plan (SEDP) . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

7.1.3. Modalities for implementation . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

7.2. Migration strategy . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

7.3. Management of change . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

7.3.1.

Introduction . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

7.3.2. Baselining .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

7.3.3. Baseline release . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

7.3.4. Deployment of new baselines . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

7.3.5. Change management process — the requirements . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

7.3.6. Configuration management plan — the requirements .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

7.4. Specific cases .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . .

7.4.1.

Introduction . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

7.4.2.

List of specific cases . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . .

ANNEX A LIST OF ACCOMPANYING DOCUMENTS . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

ANNEX B GLOSSARY . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

TABLES:

Table 1:

Path request . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

Table 2:

Path cancellation by RU . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

Table 3:

Path cancellation by IM . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

Table 4:

Receipt confirmation . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

Table 5:

Train preparation . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .

46

46

46

46

47

47

47

48

48

49

49

49

49

49

50

50

50

50

50

50

50

51

51

51

51

52

53

56

56

57

58

58

58

59

59

59

60

61

62

18

18

19

19

23

L 13/6

EN

Official Journal of the European Union

18.1.2006

Trans-European conventional rail system

Technical specification for interoperability subsystem Telematic Applications for Freight

1. INTRODUCTION

1.1. Technical scope

This TSI concerns the telematic applications subsystem for freight services shown in the list in point 1(b) of
Annex II to Directive 2001/16/EC.

The commercial operation of trains, wagons and intermodal units throughout the trans-European rail network
requires efficient interchange of information between the different Infrastructure Managers, Railway Undertak-
ings and other service providers. Performance levels, safety, quality of service and cost depend upon such
compatibility and interchange as does, in particular, the interoperability of the trans-European conventional rail
system.

The technical specification for interoperability also has an impact on the conditions of use of rail transport by
users. In this respect the term users is understood to mean not only infrastructure managers or railway undertak-
ings but also all other service providers such as wagon companies, intermodal operators and even customers.

Last but not least, the benefit of interoperability of the conventional rail system was taken into account to bring
about the conditions for greater interoperability between modes of transport, in particular between conventional
rail transport and combined rail transport.

The purpose of this TSI is to ensure also that efficient interchange of information is at all times best adapted,
with regard to quality and quantity, to changing requirements so that the transport process may remain as
economically viable as possible and that freight transport on rail maintains its hold on the market against the
intense competition it has to face.

All this means the building or upgrading of the trans-European conventional rail system for conventional rail
transport and intermodal transport. The need for such an upgrade of the rail part of the transport system can
also be seen by considering the critical points (interfaces between the various partners involved) in freight trans-
port on road compared with the critical points of freight transport on rail for one simplified scenario as shown
in Annex A, Index 5, Chapter 1.1.

To manage shipments under the conditions of so many interfaces by means of information exchange on the
basis of the Directives 2001/14/EC (1) and 2001/16/EC of the European Parliament and of the Council is the
final goal of this TSI.

This short explanation of the scope of the conventional rail TSI telematic applications for freight also shows the
difference to the Conventional Rail TSI Operation and Traffic Management. The Operation and Traffic Manage-
ment TSI covers — especially under safety aspects — the procedures and related equipment enabling a coherent
operation of the different structural subsystems including,
in particular, train driving, traffic planning and
management, which is the principal business of an RU according the definition (see Chapter 2.3: Overview of
the subsystem description).

The TSI telematic applications covers the applications for freight services and the management of connections
with other modes of transport which means that it concentrates on the transport services of an RU in addition
to the pure operation of trains. Safety aspects are only considered as far as the existence of data elements, e.g.
wrong or not actual values, may have an impact on the safety operation of a train.

1.2. Geographical scope

The geographical scope of this TSI is the trans-European conventional rail system as described in Annex I to the
Directive 2001/16/EC. But this TSI may also be applied to the complete freight transport rail network of the
Member States of the EU, with the restriction that the requirements of this TSI are not mandatory for freight
transport arriving from or going to a non-EU country.

(1) OJ L 75, 15.3.2001, p. 29. Directive as last amended by Directive 2004/49/EC (OJ L 164, 30.4.2004, p. 44, as corrected by OJ L

220, 21.6.2004, p. 16)

18.1.2006

EN

Official Journal of the European Union

L 13/7

1.3. Content of this TSI

In accordance with Article 5(3) of Directive 2001/16/EC, this TSI:

(a) indicates its intended scope of the telematic applications subsystem for freight — Chapter 2: Definition of

subsystem/scope ;

(b) lays down the essential requirements for this subsystem and its interface vis-à-vis other subsystems —

Chapter 3: Essential requirements ;

(c) establishes the functional and technical specifications to be met by the subsystem and its interfaces vis-à-vis

other subsystems — Chapter 4: Characterisation of the subsystem ;

(d) determines the interoperability constituents and interfaces covered by European specifications,

including
European standards, which are necessary to achieve interoperability within the trans-European conventional
rail system — Chapter 5: Essential requirements ;

(e) states, in each case under consideration, the procedures for the assessment of conformity or suitability for
use. This includes, in particular, the modules defined in Council Decision 93/465/EEC (1) or, where appro-
priate, the specific procedures to be used to assess either the conformity to or the suitability for use of inter-
operability constituents and ‘EC’ verification of subsystems — Chapter 6: Assessment of conformity and/or
suitability for use of the constituents and verification of the subsystem ;

(f) indicates the strategy for implementing the TSI. In particular it is necessary to specify the stages to be
completed in order to make a gradual transition from the existing situation to the final situation in which
compliance with the TSI shall be the norm — Chapter 7: Implementation ;

(g) indicates, for the staff concerned, the professional qualifications and health and safety conditions at work
required for the operation and maintenance of this subsystem, as well as for the implementation of the TSI
— Chapter 4: Characterisation of the subsystem .

Moreover, in accordance with Article 5(5), provision is made for specific cases for this TSI; these are indicated
in Chapter 7.4: Specific cases .

Lastly, this TSI also comprises, in Chapter 4 (Characterisation of the subsystem), the operating and maintenance
requirements specific to the scope indicated in paragraphs 1.1 (Technical scope) and 1.2 (Geographical scope)
above.

2. DEFINITION OF SUBSYSTEM/SCOPE

2.1. Functions within the scope of the TSI

The subsystem Telematic Applications for Freight is defined by Annex II of the Directive 2001/16/EC, Section
2.5(b).

It includes in particular:

— applications for freight services, including information systems (real-time monitoring of freight and trains),

— marshalling and allocation systems, whereby under allocation systems is understood train composition,

— reservation systems, whereby here is understood the train path reservation,

— management of connections with other modes of transport and production of electronic accompanying

documents.

2.2. Functions outside the scope of the TSI

Payment and invoicing systems for customers are not within the scope of this TSI, nor are such systems for
payment and invoicing between various service providers such as railway undertakings or infrastructure
managers. The system design behind the data exchange in accordance with Chapter 4.2 (Functional and tech-
nical specifications of the subsystem), however, provides the information needed as a basis for payment resulting
from the transport services.

Also the long-term planning of the timetables is out with the scope of this telematic applications TSI. Neverthe-
less at some points there will be reference to the outcome of the long-term planning in so far as there is a rela-
tionship to the efficient interchange of information required for the operation of trains.

(1) OJ L 220, 30.8.1993, p. 23.

L 13/8

EN

Official Journal of the European Union

18.1.2006

2.3. Overview of the subsystem description

2.3.1. Involved entities

This TSI takes into account the present service providers and the various possible service providers of the future
involved in freight transport as they are for (this list is not exhaustive):

— wagons

— locomotives

— drivers

— switching and hump shunting

— slot selling

— shipment management

— train composition

— train Operation

— train monitoring

— train controlling

— shipment monitoring

— inspections and repair of wagon and/or locomotive

— customs clearance

— operating intermodal terminals

— haulage management.

Some specific service providers are defined explicitly in the Directives 2001/14/EC and 2001/16/EC. Since both
directives have to be taken into account, this TSI considers in particular the definition of (see also Annex A,
Index 6):

‘“Infrastructure Manager (IM)” means any body or undertaking that is responsible, in particular, for estab-
lishing and maintaining railway infrastructure. This may also include the management of infrastructure
control and safety systems. The functions of the infrastructure manager on a network or part of a network
may be allocated to different bodies or undertakings.’

Based on this definition, this TSI regards an IM as the service provider for the allocation of paths, for control-
ling/monitoring the trains and for train/path related reporting.

According to Directive 2001/14/EC the body or undertaking to which an IM allocates a path is defined as an
applicant.

‘“Applicant” means a licensed railway undertaking and/or an international grouping of railway undertakings,
and, in Member States which provide for such a possibility, other persons and/or legal entities with public
service or commercial interest in procuring infrastructure capacity, such as public authorities under Regu-
lation (EEC) No 1191/69 and shippers, freight forwarders and combined transport operators, for the opera-
tion of railway services on their respective territories.

Whereas a “Railway Undertaking” is defined as any public or private undertaking, licensed according to
applicable Community legislation, the principal business of which is to provide services for the transport of
goods and/or passengers by rail with a requirement that the undertaking must ensure traction; this also
includes undertakings which provide traction only.’

Based on this definition, this TSI regards the RU as the service provider for operating trains.

Regarding the allocation of a train path for running a train, Article 13 of the Directive 2001/14/EC also has to
be taken into account:

‘Infrastructure capacity shall be allocated by an infrastructure manager, and once allocated to an applicant
may not be transferred by the recipient to another undertaking or service. Any trading in infrastructure
capacity shall be prohibited and shall lead to exclusion from the further allocation of capacity. The use of
capacity by a railway undertaking when carrying out the business of an applicant who is not a railway
undertaking shall not be considered as transfer.’

18.1.2006

EN

Official Journal of the European Union

L 13/9

In relation to the communication scenarios between infrastructure managers and applicants in the execution
mode of a transport, only the IM and the RU have to be considered and not all types of applicants, which may
be relevant for the planning mode. In the execution mode a defined IM–RU relationship is always given, for
which the message exchange and the information storage is specified in this TSI. The definition of an applicant
and the resulting path allocation possibilities remain uninfluenced.

As already mentioned various services have to be provided for a freight transport. One for example is the provi-
sion of wagons. This service can be related to a fleet manager. If this service for a transport is one of the services
offered by the RU, the RU acts also as fleet manager. A fleet manager again can manage his own wagons and/or
wagons from another keeper (another service provider for freight wagons). The needs for this kind of service
provider are taken into account independent of whether the legal entity of the fleet manager is an RU or not.

This TSI does not create new legal entities and does not force an RU to involve external service providers for
services which the RU itself offers but it does name, where necessary, a service by the name of a related service
provider. If the service is offered by an RU, the RU acts as the service provider for that service.

When taking into account the needs of a customer, one of the services is to organise and manage the transport
line according to the commitment to the customer. This service is provided by the Lead Railway Undertaking
(Lead RU or LRU). The LRU is the single point of contact for the customer. If more than one railway under-
taking is involved in the transport chain, the LRU is also responsible for the co-ordination with the other
railway undertakings.

This service can also be undertaken by a forwarder or by any other entity.

The involvement of an RU as LRU can differ from one type of transport flow to another. In the intermodal busi-
ness the managing of capacity in block trains and the preparing of waybills is done by an intermodal service
integrator, who could then be customer for the LRU.

The main point, however, is that the RUs and the IMs and all other service providers (in the sense as defined
above) must work together, either through cooperation and/or open access, as well as through efficient inter-
change of information, to deliver seamless services to the customer.

2.3.2. Considered processes

This TSI for the railway freight transport industry is limited according to Directive 2001/16/EC to IMs and RUs/
LRUs with reference to their direct customers.

In the operation of freight services, the activity of an LRU, regarding a consignment, starts with the receipt of
the consignment note from its customer and, for example, for wagon loads with the release time of the wagons.
The LRU creates a preliminary trip plan (based on experience and/or contract) for the transport journey. If the
LRU intends to have the wagon load in a train under Open Access mode (the LRU operates the train for the
complete journey), the preliminary trip plan is per se the final one. If the LRU intends to put the wagon load in
a train which involves the cooperation of other RUs, he first has to find out which RUs he should address and
at what time an interchange between two successive RUs can occur. The LRU then prepares the preliminary
wagon orders individually for each RU as subsets of the full consignment note. The wagon orders are specified
in Chapter 4.2.1 (Consignment note data).

The addressed RUs check the availability of the resources for the operation of the wagons and the availability of
the train path. The responses from the various RUs enable the LRU to refine the trip plan or to start the interro-
gation anew — perhaps even with other RUs — until the trip plan finally fits customer requirements.

The RUs/LRUs must in general have, at minimum, the capability of:

— DEFINING services in terms of price and transit times, wagon supply (where applicable), wagon/intermodal
unit information (location, status and the wagon/intermodal unit related estimated time of arrival ‘ETA’),
where shipments can be loaded on empty wagons, containers, etc.,

— DELIVERING the service that has been defined in a reliable, seamless manner through the use of common
business processes and linked systems. There must be a capability for RUs, IMs and other service providers
and stakeholders such as customs to exchange information electronically,

L 13/10

EN

Official Journal of the European Union

18.1.2006

— MEASURING the quality of the service delivered compared to what was defined. i.e. billing accuracy against
price quoted, actual transit times against commitments, wagon ordered against supplied, ETAs against actual
arrival times,

— OPERATING in a productive manner in terms of utilisation: train, infrastructure and fleet capacity through
the use of business processes, systems and data exchange required to support wagon/intermodal unit and
train scheduling.

The RUs/LRUs as an applicant must also provide (through contracts with IMs) the required train path and must
operate the train within their journey section. For the train path they may use already booked paths (in planning
mode) or they have to request an ad hoc train path from the infrastructure manager(s) (IMs) relevant for the
journey section(s) over which the RU operates the train. In Annex A, Index 5, Chapter 1.2 an example is given
for the path request scenario.

The path ownership is also import for the communication during the train running between IM and RU. The
communication must always be based on train and path number, whereby the IM communicates with the RU,
who has booked the train path on his infrastructure (see also Annex A, Index 5, Chapter 1.2).

If an RU provides the complete journey A–F (Open Access by RU, no other RUs are involved), then each IM
involved communicates directly with this RU only. This ‘open access’ by the RU can be realised by booking the
train path via ‘One Stop Shop’ or in sections with each IM directly. The TSI takes account both cases as it is
shown in Chapter 4.2.2.1: Path request , Preliminary remarks .

The dialogue process between RUs and IMs for establishing a train path for a freight train is defined in Chapter
4.2.2 (Path request). This function refers to Article 23(1) of the Directive 2001/14/EC. The dialogue process
excludes obtaining the licence for an RU providing services in accordance with Directive 2001/13/EC of the
European Parliament and of the Council (1), the certification according to Directive 2001/14/EC and access
rights according to Council Directive 91/440/EEC (2).

In Chapter 4.2.3 (Train preparation) is defined the information exchange relating to the train composition and
the train departure procedure. The data exchange during the running of a train in the case of normal operation
is given in Chapter 4.2.4 (Train running forecast) and for exceptions the messages are defined in Chapter 4.2.5
(Service disruption information). Tracing information about train location is defined in Chapter 4.2.6 (Train
location). All these messages are exchanged between RU and IM and based on trains.

For a customer the most important information is always the estimated time of arrival (ETA) for his shipment.
From the information exchange between LRU and IM (in case of Open Access) an ETA can be calculated. In the
case of cooperation mode with various RUs, the ETA and also the estimated times of interchange (ETIs) can be
determined from the message exchange between RUs and IMs and provided to the LRU by the RUs, (Chapter
4.2.7 Shipment ETI/ETA).

Also determined from the information exchange between IM and RU, the LRU knows, for example:

— when the wagons departed from or arrived at a yard or at defined locations (Chapter 4.2.8 Wagon move-

ment), or

— when the responsibility for the wagons was transferred from one RU to the next RU in the transport chain

(Chapter 4.2.9 Interchange reporting).

Determined not only from the data exchange between IM and RU, but also from the data exchange between
RUs and LRU, various statistics may be evaluated:

— for — in the medium term — planning the production process in greater detail, and

— for — in the long term — carrying out strategic planning exercises and capacity studies (e.g. network

analyses, definition of siding and marshalling yards, rolling stock planning), but above all

— for improving the quality of the transport service and productivity (Chapter 4.2.10 Data exchange for

quality improvement).

The handling of empty wagons takes on particular relevance when considering interoperable wagons. In prin-
ciple there is no difference in the handling of loaded or empty wagons. The transport of empty wagons is also
based on wagon orders, whereby the fleet manager for these empty wagons must be considered as a customer.

(1) OJ L 75, 15.3.2001, p. 26.
(2) OJ L 237, 24.8.1991, p. 25. Directive as last amended by Directive 2004/51/EC of the European Parliament and of the Council (OJ L

164, 30.4.2004, p. 164, as corrected by OJ L 220, 21.6.2004, p. 58).

18.1.2006

EN

Official Journal of the European Union

L 13/11

2.3.3. General remarks

An information system is only as good as the reliability of the data within it. Therefore the data that plays a
decisive role in the forwarding of a consignment, a wagon or a container must be accurate and captured
economically — which means that the data should be entered into the system only once.

Based on this, the applications and messages of this TSI avoid the multiple manual data input by access to
already stored data, e.g. the rolling stock reference data. The requirements regarding the rolling stock reference
data are defined in Chapter 4.2.11 (The main reference data). The specified Rolling Stock Reference Databases
must allow easy access to the technical data. The contents of the databases must be accessible, based on struc-
tured access rights depending on privilege, to all IMs, RUs and fleet managers, in particular for purposes of fleet
management and rolling stock maintenance. They must contain all transport critical technical data such as:

— identification of rolling stock,

— technical/design data,

— assessment of compatibility with the infrastructure,

— assessment of relevant loading characteristics,

— brake relevant characteristics,

— maintenance data,

— environmental characteristics.

In the intermodal transport business at various points (called gateways) a wagon is not only connected to
another train, but also the intermodal unit may be moved from one wagon to another. As a consequence it is
not sufficient to work with only a trip plan for wagons and therefore a trip plan for the intermodal units must
also be drawn up.

In Chapter 4.2.12 (Various reference files) some reference files and various databases are listed, among them, the
Wagon and Intermodal Unit Operational Database. This database contains the operational status data of the
rolling stock, the weight and dangerous goods information, information related to intermodal units and the loca-
tion information. In Chapter 4.2.13 (Electronic transmission of documents) the requirements for the electronic
transmission of documents are given.

The TSI for telematic applications subsystem for freight services defines the required information, which has to
be exchanged between the different partners involved in a transport chain, and permits a standard mandatory
data exchange process to be installed. It shows also the architecture strategy for such a communication platform.
This is outlined in Chapter 4.2.14 (Electronic transmission of documents) taken into account:

— the interface to the subsystem Operation and Traffic Management of the trans-European conventional rail

system referred to in Article 5(3) of Directive 2001/16/EC,

— the requirements for the content of the Network Statement, which are set out in Directive 2001/14/EC,

Article 3 and Annex I,

— the information available on the freight wagon rolling stock and the requirements regarding maintenance

from the rolling stock TSI.

There is no direct data transmission from the subsystem Telematic Applications for Freight Services into the
train, to the driver or to parts of the Control Command and Signalling subsystem and the physical transmission
network is a completely different one from the network used by the Command Control and Signalling
subsystem. The ERTMS/ETSC system is using GSM-R. In this open network the ETCS specifications clarify that
safety is achieved with the appropriate management of open networks hazards in the EURORADIO protocol.

The interfaces to the structural subsystems Rolling Stock and Control Command are only given via the Rolling
Stock Reference Databases (Chapter 4.2.11.3: The Rolling Stock Reference Databases), which are under the
control of the keepers. The interfaces to the subsystems Infrastructure, Control Command and Energy are given
with the path definition (Chapter 4.2.2.3: Path Details message) from the IM, where infrastructure related values
for the train are specified, and with the information provided by the IMs regarding restrictions in the infrastruc-
ture (Chapter 4.2.11.2: The Infrastructure Restriction Notice Databases).

L 13/12

EN

Official Journal of the European Union

18.1.2006

3. ESSENTIAL REQUIREMENTS

3.1. Compliance with the essential requirements

According to Article 4(1) of Directive 2001/16/EC, the trans-European conventional rail system, subsystems and
their interoperability constituents must meet the essential requirements set out in general terms in Annex III to
the Directive.

In the scope of the present TSI, fulfilment of relevant essential requirements quoted in Chapter 3 of this TSI will
be ensured for the subsystem by the compliance with the specifications described in Chapter 4: Characterisation
of the subsystem.

3.2. Essential requirements aspects

The essential requirements concern:

— safety,

— reliability and availability,

— health,

— environmental protection,

— technical compatibility.

According to Directive 2001/16/EC, the essential requirements may be generally applicable to the whole trans-
European conventional rail system or be specific to each subsystem and its constituents.

3.3. Aspects relating to general requirements

The relevance of the general requirements to the telematic applications subsystem for freight is determined as
follows:

3.3.1. Safety

In accordance with Annex III to Directive 2001/16/EC, the safety-related essential requirements that apply to
the telematic applications subsystem for freight are the following:

— Essential requirement 1.1.1 of Annex III to Directive 2001/16/EC:

‘The design, construction or assembly, maintenance and monitoring of safety-critical components and, more
particularly, of the components involved in train movements must be such as to guarantee safety at the level
corresponding to the aims laid down for the network, including those for specific degraded situations.’

This essential requirement is not relevant to the telematic applications subsystem.

— Essential requirement 1.1.2 of Annex III to Directive 2001/16/EC:

‘The parameters involved in the wheel/rail contact must meet the stability requirements needed in order to
guarantee safe movement at the maximum authorised speed.’

This essential requirement is not relevant to the telematic applications subsystem.

— Essential requirement 1.1.3 of Annex III to Directive 2001/16/EC:

‘The components used must withstand any normal or exceptional stresses that have been specified during
their period in service. The safety repercussions of any accidental failures must be limited by appropriate
means.’

This essential requirement is not relevant to the telematic applications subsystem.

— Essential requirement 1.1.4 of Annex III to Directive 2001/16/EC:

‘The design of fixed installations and rolling stock and the choice of the materials used must be aimed at
limiting the generation, propagation and effects of fire and smoke in the event of a fire.’

This essential requirement is not relevant to the telematic applications subsystem.

18.1.2006

EN

Official Journal of the European Union

L 13/13

— Essential requirement 1.1.5 of Annex III to Directive 2001/16/EC:

‘Any devices intended to be handled by users must be so designed as not to impair the safe operation of the
devices or the health and safety of users if used foreseeable in a manner not in accordance with the posted
instructions.’

This essential requirement is not relevant to the telematic applications subsystem.

3.3.2. Reliability and availability

‘The monitoring and maintenance of fixed or movable components that are involved in train movements must
be organised, carried out and quantified in such a manner as to maintain their operation under the intended
conditions.’

This essential requirement is met by the following chapters:

Chapter 4.2.11: The main reference data,

Chapter 4.2.12: Various reference files and databases,

Chapter 4.2.14: Networking and communication.

3.3.3. Health

— Essential requirement 1.3.1 of Annex III to Directive 2001/16/EC:

‘Materials likely, by virtue of the way they are used, to constitute a health hazard to those having access to
them must not be used in trains and railway infrastructure.’

This essential requirement is not relevant to the telematic applications subsystem.

— Essential requirement 1.3.2 of Annex III to Directive 2001/16/EC:

‘Those materials must be selected, deployed and used in such a way as to restrict the emission of harmful
and dangerous fumes or gases, particularly in the event of fire.’

This essential requirement is not relevant to the telematic applications subsystem.

3.3.4. Environmental protection

— Essential requirement 1.4.1 of Annex III to Directive 2001/16/EC:

‘The environmental impact of establishment and operation of the trans-European conventional rail system
must be assessed and taken into account at the design stage of the system in accordance with the Com-
munity provisions in force.’

This essential requirement is not relevant to the telematic applications subsystem.

— Essential requirement 1.4.2 of Annex III to Directive 2001/16/EC:

‘The materials used in the trains and infrastructure must prevent the emission of fumes or gases which are
harmful and dangerous to the environment, particularly in the event of fire.’

This essential requirement is not relevant to the telematic applications subsystem.

— Essential requirement 1.4.3 of Annex III to Directive 2001/16/EC:

‘The rolling stock and energy-supply systems must be designed and manufactured in such a way as to be
electro-magnetically compatible with the installations, equipment and public or private networks with which
they might interfere.’

This essential requirement is not relevant to the telematic applications subsystem.

— Essential requirement 1.4.4 of Annex III to Directive 2001/16/EC:

‘Operation of the trans-European conventional rail system must respect existing regulations on noise pollu-
tion.’

This essential requirement is not relevant to the telematic applications subsystem.

L 13/14

EN

Official Journal of the European Union

18.1.2006

— Essential requirement 1.4.5 of Annex III to Directive 2001/16/EC:

‘Operation of the trans-European conventional rail system must not give rise to an inadmissible level of
ground vibrations for the activities and areas close to the infrastructure and in a normal state of mainte-
nance.’

This essential requirement is not relevant to the telematic applications subsystem.

3.3.5. Technical compatibility

— Essential requirement 1.5 of Annex III to Directive 2001/16/EC:

‘The technical characteristics of the infrastructure and fixed installations must be compatible with each other
and with those of the trains to be used on the trans-European conventional rail system. If compliance with
these characteristics proves difficult on certain sections of the network, temporary solutions, which ensure
compatibility in the future, may be implemented.’

This essential requirement is not relevant to the telematic applications subsystem.

3.4. Aspects relating specifically to the telematic applications subsystem for freight

3.4.1. Technical compatibility

— Essential requirement 2.7.1 of Annex III to Directive 2001/16/EC:

‘The essential requirements for telematic applications guarantee a minimum quality of service for passengers
and carriers of goods, particularly in terms of technical compatibility.’

Steps must be taken to ensure:

— that the databases, software and data communication protocols are developed in a manner allowing
maximum data interchange between different applications and operators, excluding confidential commer-
cial data;

— ‘easy access to the information for users.’

This essential requirement is specially met by the following chapters:

Chapter 4.2.11: The main reference data,

Chapter 4.2.12: Various reference files and databases,

Chapter 4.2.14: Networking and communication.

3.4.2. Reliability and availability

— Essential requirement 2.7.2 of Annex III to Directive 2001/16/EC:

‘The methods of use, management, updating and maintenance of these databases, software and data commu-
nication protocols must guarantee the efficiency of these systems and the quality of the service.’

This requirement is specially met by the following chapters:

Chapter 4.2.11: The main reference data,

Chapter 4.2.12: Various reference files and databases,

Chapter 4.2.14: Networking and communication.

But this essential requirement, especially the method of use to guarantee the efficiency of these telematic
applications and the quality of the service, is the foundations for the complete TSI and not only restricted to
the chapters mentioned above.

3.4.3. Health

— Essential requirement 2.7.3 of Annex III to Directive 2001/16/EC:

‘The interfaces between these systems and users must comply with the minimum rules on ergonomics and
health protection.’

This TSI does not specify any additional requirements to existing national and European rules related to
minimum rules on ergonomics and health protection of an interface between these telematic applications
and users.

18.1.2006

EN

Official Journal of the European Union

L 13/15

3.4.4. Safety

— Essential requirement 2.7.4 of Annex III to Directive 2001/16/EC:

‘Suitable levels of integrity and dependability must be provided for the storage or transmission of safety-
related information.’

This requirement is met by the following chapters:

Chapter 4.2.11: The main reference data,

Chapter 4.2.12: Various reference files and databases,

Chapter 4.2.14: Networking and communication.

4. CHARACTERISATION OF THE SUBSYSTEM

4.1. Introduction

The trans-European conventional rail system, to which Directive 2001/16/EC applies and of which the telematic
applications subsystem is a part, is an integrated system whose consistency must be verified. This consistency
must be checked in particular with regard to the specifications of the subsystem, its interfaces vis-à-vis the
system in which it is integrated, as well as the operating and maintenance rules.

Taking into account all the applicable essential requirements, the telematic application subsystem for freight is
characterised by:

4.2. Functional and technical specifications of the subsystem

In light of the essential requirements in Chapter 3 (Essential requirements), the functional and technical specifi-
cations of the subsystem are as follows:

— consignment note data,

— path request,

— train preparation,

— train running forecast,

— service disruption information,

— train location,

— wagon/intermodal unit ETI/ETA,

— wagon movement,

— interchange reporting,

— data exchange for quality improvement,

— the main reference data,

— various reference files and databases,

— electronic transmission of documents,

— networking and communication.

The detailed specifications are outlined below. Further details and the formats of the messages are defined in
Annex A, Index 1.

G en er a l re ma r ks on the me ssa g e str u c tu r e

The messages are structured into two data sets:

— control data: explanation see below,

— information data: the application information.

The control data show the following elements:

— status: the status of a message can be:

‘New message’, if this is a new message,

‘Alteration’, if this is a modification of a previous send message,

‘Deletion’, if the previous sent message should be deleted,

L 13/16

EN

Official Journal of the European Union

18.1.2006

— message reference with:

Message type: e.g. ‘path request’ or ‘enquiry about train running’,

Data and time: actual date and time when the message was sent,

Message number: number generated by the sender of the message,

— related reference, only if the message is the answer to a previous received message (identical to the ‘message

reference’ of the received message) with:

Related type: type of the received message,

Related date and time: date and time of the received message,

Related number: number of the received message,

— sender of the message,

— recipient of the message.

In the following chapters mainly the status ‘New message’ is considered. In Chapter 4.2.2 Path request is also
referred to the status ‘deletion’ regarding the Path Request message.

4.2.1. Consignment note data

4.2.1.1. Cu stome r c on si g n men t note

The consignment note has to be sent by the customer to the Lead RU. It must show all the information needed
to carry a consignment from the consignor to the consignee. The LRU must supplement this data with addi-
tional information. These data, including the additional ones, are (for the description of the data see Annex A,
Index 3) listed in the table in Annex A, Index 3 with the indication in row ‘Data in consignment note’, whether
they are mandatory or optional and whether they must be delivered by the consignor or supplemented by the
LRU.

In the case of Open Access the Lead RU contracting with the customer has all the information after the supple-
ment of the data available. No message exchange is needed with other RUs. These data are also the basis for a
path request on short notice, if this is required for the execution of the consignment note.

The following messages are for the case of non Open Access. The content of these messages may also be the
basis for the path requests on short notice, if required for the execution of the consignment note.

4.2.1.2. Wa g on or de rs

The wagon order is primarily a subset of the consignment note information. It must be forwarded to the RUs
involved in the transport chain, since it could become an input for an ad hoc path request (Chapter 4.2.2: Path
request). The content of the wagon order must show the relevant information which is needed for an RU to
effect transportation during its responsibility until handover to next RU. Therefore the content is dependent on
the role to be performed by the railway undertaking: Origin-, Transit- or Delivery RU (ORU, TRU, DRU):

— wagon order for the Origin Railway Undertaking (ORU),

— wagon order for the Transit Railway Undertaking (TRU),

— wagon order for the Delivery Railway Undertaking (DRU).

The data of the wagon orders according the various roles of an RU are listed in detail in Annex A, Index 3,
marked as to whether they are mandatory or optional. The detailed formats of these messages are defined in
Annex A, Index 1.

The main contents of these wagon orders are:

— consignor and consignee information,

— routing information,

— consignment identification,

— wagon information,

— place and time information.

18.1.2006

EN

Official Journal of the European Union

L 13/17

Selected data of the consignment note data must also be accessible for all partners (e.g. IM, keeper, etc.) in the
transport chain including customers. These are especially per wagon:

— load weight (gross weight of the load),

— CN/HS number,

— dangerous goods information,

— transportation unit.

4.2.2. Path request

4.2.2.1. Pr e li mi na ry re ma r ks

L o n g - t e r m p l a n n i n g

The train path defines the requested, accepted and actual data to be stored concerning the path of a train and
the characteristics of the train for each segment of that path. The following description presents the information
which must be available to the infrastructure manager. For a more detailed description: see Annex A, Index 4.

This information must be updated whenever a change occurs.

The main path data must be:

— identification of the train path (path number). A path could be either planned usage of capacity along a
route section, or the actual routing of a train along a specified line within a route. The exact nature depends
upon the processes in use within an IM,

— path departure point, which means the place from where the path will start together with the date and time

of the departure of a train on that path,

— destination of the train path, which means the place where the path will end together with date and time at

which a train is due to arrive at that destination,

— description of the journey section, which defines the data provided by the IM for each accepted journey
section — from the start to the first intermediate stop, further intermediate stops and from the final inter-
mediate stop to the end of the accepted journey. This description may comprise:

— intermediate stops or other designated points along the proposed path with date and time for the arrival,
departure or passage at these intermediate points as well with an Activity Code, which defines an activity
to be undertaken at that intermediate point en route,

— identification of the IM responsible for the traffic management for the current journey section and identi-

fication of the IM responsible for the traffic management for the next journey section,

— description of the equipment (command and control system, radio system, etc.) to be carried by the
train; this must be compatible with the infrastructure to enable traction, control and communications
from the train to IM control,

— train related data for the journey section: max. weight, max. length, max. speed, max. axle weight, min.
identifiers of not

information concerning exceptional gauging,

brake force, max. weight per metre,
allowed dangerous goods,

— path number,

— additional route section running time to allow for recovery, path problems, etc.

Execution path contract: before the running of a train, the journey section must be updated and completed with
actual values. The execution mode is independent from the planning mode.

P a t h r e q u e s t o n s h o r t n o t i c e

Due to exceptions during the train running or due to transport demands on a short-time basis, a railway under-
taking must have the possibility to get an ad hoc path on the network.

In the first case, immediate actions have to be started, whereby the actual train composition based on the train
composition list is known.

In the second case, the railway undertaking must provide the infrastructure manager with all necessary data
concerning when and where the train is required to run together with the physical characteristics in so far as
they interact with the infrastructure. These data are mainly given in the supplemented consignment note respec-
tively in the wagon orders.

L 13/18

EN

Official Journal of the European Union

18.1.2006

The path agreement for a train movement at short notice is based on a dialogue between RUs and IMs. The
dialogue will involve all RUs and IMs involved in moving the train along the desired path but maybe with
different contribution to the path finding process. According to Directive 2001/14/EC, Article 13, mainly two
general valid different scenarios can be distinguished for freight transport operating on the infrastructures of
several IMs (see also Annex A, Index 5, Chapter 1.3).

— scenario A: The RU contacts all involved IMs directly (case A) or via the OSS (case B) to organise the paths
for the complete journey. In this case the RU has also to operate the train on the complete journey
according to Article 13 of the Directive 2001/14/EC.

— scenario B: Each RU involved in the transport journey contacts the local IMs directly or via OSS to request a

path for the journey section on which it operates the train.

remark: As already mentioned in Chapter 2 (Definition of subsystem/scope), in the execution mode, the IM will
always communicate with the RU which has booked the path. Therefore the ‘path ownership’ is important for
the message exchange during operation of the train.

In both scenarios the booking procedure of a path on short notice follows the dialogue between RU and IM
involved as described on the next page.

The following table shows the messages used in the dialogue for the path request:

Table 1

Path request

Message

Explanation

Messages used in the dialogue for the path request

Path Request

Path Details

Path Confirmed

Path Details Refused

RU to IM(s) involved, this message must be sent for a path request at
short notice.

This message must be sent from IM(s) to RU confirming details of path
in response to RU's ‘Path Request’, perhaps with changed values or if the
IM cannot serve the path request, with the indication ‘No alternatives
available’.

This message must be sent from the RU to the IM for the acceptance of
the ‘Path Details’ from the IM in response to the RU's original request.

This message must be sent from the RU to the IM when not accepting
the ‘Path Details’ from the IM in response to RU's original request,
if
there are changed values, which the RU cannot accept.

This dialogue ends with the RU by the Path Confirmed message or with the deletion of the path request (Path
Request message with status ‘Deletion’, see Chapter 4.2: Functional and technical specifications of the subsystem,
General remarks on the message structure). A Path Details Refused message from the RU must always be served
with a new Path Details message. If the IM cannot serve the path request with a new proposal within the Path
Details message, he must send the Path Details message with the indication ‘No alternatives available’, which
ends the dialogue with the IM.

Whether the path was booked in the long-term planning or on a short notice, the RU must have always the
possibility to cancel a booked path. For the cancellation of a booked path the following message must be used.

Table 2

Path cancellation by RU

Message

Explanation

Message to cancel a booked path by RU

Path Cancelled

Advice from the RU to the IM to cancel a previously booked path or a
part of it.

18.1.2006

EN

Official Journal of the European Union

L 13/19

Based on the path agreement, the RU can expect that a booked path is also available. Therefore if something
occurs and the booked path is no longer available, the IM must inform the RU as soon as it has the knowledge
about this fact. A cause of this may be for example an interruption on the path. This can happen at any time
between the moment the train path is contracted and the departure of the train. The IM is obliged to send an
alternative proposal together with the indication ‘Path not available’. If this is not possible the IM must send the
proposal as soon as possible. With the Path Not Available message a dialogue starts for a new path agreement
initiated by the IM.

Messages used in the dialogue for the cancellation of a booked path by IM.

Table 3

Path cancellation by IM

Message

Explanation

Messages used in the path cancellation process initiated by IM

Path Not Available

Advice from the IM to the RU that the booked path is not available.

Path Details

This message must be sent from IM(s) to RU proposing an alternative
path after the advice from the IM to the RU that the booked path is not
available.

Path Confirmed

This message must be sent from the RU to the IM for the acceptance of
the path proposed in the Path Not Available message.

Path Details Refused

This message must be sent from the RU to the IM when not accepting
the proposal from the IM in the Path Not Available message.

In this case the IM must send a new proposal.

This dialogue ends by the RU with the Path Cancelled message related to
IM's Path Not Available message.

In general, if the receiver of a request or enquiry can not answer in real time he must inform the originator of
the message (for example the Path Details message as response to the Path Request can not be sent immediately).
This must be done by using the following message:

Table 4

Receipt confirmation

Message

Explanation

This message is valid in general

Receipt Confirmation

This message must be sent from the recipient of a message to the origi-
nator of the message when the required response cannot be made avail-
able within the time interval as defined in Chapter 4.4 (Operating rules),
section ‘Timeliness’.

These messages are described by mentioning the main points in the following chapters. The detailed formats are
defined in Annex A, Index 1. The logical sequence of these messages is shown in the diagrams in Annex A,
Index 5, Chapter 2.1 to 2.3.

4.2.2.2. Pa th R e q ue st me ssa g e

This is the request from the RU to the IM for a train path. Such a request must contain:

— path departure point: place from where the proposed path will start,

— path departure date/time: date/time for which the path is requested,

L 13/20

EN

Official Journal of the European Union

18.1.2006

— path destination point: destination of train for the requested path,

— path destination arrival date/time: date/time at which the proposed train is due to arrive at its destination,

— requested journey section:

— intermediate stops or other designated points along the proposed path with date/time at which the
proposed train is due to arrive at an intermediate point and the date/time that the train is due to depart
from an intermediate point. A blank entry indicates that it will not stop at that point,

— available equipment on the train: traction type, command and control system including on-board radio

equipment,

— train weight,

— train length,

— braking system to be used and braking performance,

— maximum speed of the train,

— maximum axle weight of the train,

— maximum weight per metre,

— information concerning exceptional gauging,

— UN/RID numbers relating to any dangerous goods,

— definitions of activity to be undertaken at any intermediate point en route,

— responsible RU: identification of the RU responsible for the train for the current journey section,

— responsible IM: identification of the IM responsible for the train for the current journey section,

— next responsible IM: identification of the IM responsible for the train for the next journey section (if

any).

As an information support for the formulation of the path request, the RU can consult the relevant Network
Statement to check whether the data of the train in mind comply with the infrastructure. Data such as
dangerous goods information also has to be taken into account.

The keepers of the wagons must give the RUs access to the technical wagon data.

The RUs must themselves ensure access to the reference files, e.g. to the dangerous goods reference file if
required.

4.2.2.3. Pa th Deta i ls me ssa g e

This message is the answer from an IM to the Path Request message from an RU. In the case that the IM cannot
serve the path request, he must send this message with the indication ‘No alternatives available’. In the other
case he must answer the RU request by sending back a path number together with the same data as in the train
path request but perhaps with changed values.

For the alternative proposed by IM the following data must be sent:

— new path number,

— path departure point: place from where the proposed path will start,

— path departure date/time: date/time for which the path is proposed,

— path destination point: destination of train for the proposed path,

— path destination arrival date/time: date/time at which the train is due to arrive at its destination,

— modified journey section:

— intermediate stops or other designated points along the proposed path with date/time at which the
proposed train is due to arrive at an intermediate point and the date/time that the train is due to depart
from an intermediate point. A blank entry indicates that it will not stop at that point,

18.1.2006

EN

Official Journal of the European Union

L 13/21

— required equipment on the train: traction type, command and control system including on-board radio

equipment,

— train weight,

— train length,

— braking system to be used and braking performance,

— maximum speed of the train,

— maximum axle weight of the train,

— maximum weight per metre,

— information concerning exceptional gauging,

— UN/RID numbers relating to any dangerous goods,

— definitions of activity to be undertaken at any intermediate point en route,

— responsible RU: identification of the RU responsible for the train for the current journey section,

— responsible IM: identification of the IM responsible for the train for the current journey section,

— next responsible IM: identification of the IM responsible for the train for the next journey section (if

any).

4.2.2.4. Pa th Con fi r med me ssa g e

This message must be sent from an RU to an IM accepting a proposed path in response to the RU's original
request. With this message the path is booked. The main message content is:

— path number: to identify the path,

— path departure point: place from where the train will depart,

— path departure date/time: date/time for which the path is requested,

— path destination point: train destination for the requested path,

— path destination arrival date/time: date/time at which proposed train is due to arrive at its destination,

— indicates that the RU has accepted the proposed path.

4.2.2.5. Pa th Deta i ls R e fu se d messa g e

In the case of a refusal of the proposed path as given in the Path Details message by the IM, the RU must send
this message to the IM to advise him, that it does not accept the proposed path as given in the Path Details
message. The main data are:

— path number: to identify the path,

— indicates the refusal of the path details.

As additional information the following data may be sent:

— path departure point: place from where the train will depart,

— path departure date/time: date/time for which the path is requested,

— path destination point: destination of train for the requested path,

— path destination arrival date/time: date/time at which the proposed train is due to arrive at its destination.

4.2.2.6. Pa th Ca nc e lle d me ssa g e

This is the RU advice to cancel a previously booked path. Together with the cancellation indicator (corresponds
to the message type), the path number must be sent for the unique identification of the path. This applies to
path booking in planning mode and on short notice:

— path number: to identify the path,

— train number (if already known to the IM),

— indicates the cancellation of the booked train path.

L 13/22

EN

Official Journal of the European Union

18.1.2006

As additional information the following data may be sent:

— path departure point: place from where the train will depart,

— path departure date/time: date/time for which the path is requested,

— path destination point: destination of train for the requested path,

— path destination arrival date/time: date/time at which the proposed train is due to arrive at its destination.

4.2.2.7. Pa th Not A v a i la ble messa g e

The IM must inform the RU as soon as it has the knowledge, that a train path is not available. The message
Train Path Not Available can be send at any time between the moment the train path is contracted and the
departure of the train. A cause of this message may be e.g. an interruption on the path. The main contents of
this message are:

— path number of the path which is not available,

— train number of the train foreseen for the cancelled path (if already known to the IM),

— path departure point with date and time for which path was booked,

— path destination point with date and time at which the train is due to arrive at its destination,

— Train Path Not Available indication,

— indication of the cause.

Together with this message or as soon as possible the IM must send without any further request from the RU
an alternative proposal. This is done with the message Path Details related to this Path Not Available message.

4.2.2.8. R e ce i pt Confi r ma ti on me ssa g e

This information must be sent from the recipient of a message to the originator of the message, when the
required response cannot be made available within the time-frame as specified in Chapter 4.4 (Operating rules).
This message must have an identifier to which it refers (entries in Related message, see Chapter 4.2: Functional
and technical specifications of the subsystem, General remarks on the message structure) and the indication:
(Application level)

— Message Confirmation: indicates that the recipient has received the message and will act upon it as neces-

sary.

4.2.3. Train preparation

4.2.3.1. Ge ne ra l r ema rk s

This section specifies the messages which must be exchanged during the train preparation phase until the start
of the train. The messages are shown below in Table 5.

For the preparation of the train, the RU must have access to the infrastructure restriction notices, to the tech-
nical wagon data (Rolling Stock Reference Databases, Chapter 4.2.11.3: The Rolling Stock Reference Databases),
to the dangerous goods reference file and to the current, updated information status on the wagons (Chapter
4.2.12.2: Other databases : The Wagon and Intermodal Unit Operational Database). This applies to all wagons
on the train. At the end the RU must send the train composition to the next RUs. This message must also be
sent from the RU to the IM(s) with whom it has booked a path section, when requested by the Conventional
Rail TSI Operation and Traffic Management or by the contract(s) between RU and IM(s).

If the train composition is changed at a location, this message must be exchanged once more with information
updated by the RU responsible.

At each point, e.g. origin and interchange point, where the responsibility changes on the RU side, the start
procedure dialogue between IM and RU ‘Train Ready — Train Running Information’ is obligatory.

18.1.2006

EN

Official Journal of the European Union

L 13/23

The messages used within this start procedure dialogue are:

TABLE 5

Train preparation

Message

Explanation

Train Composition

RU to IM, this message must be sent according the description
above.

In the case that the IM has received a train composition message send mandatory by the RU, the IM
may send:

Train Accepted

Train Not Suitable

Train Ready

Train Position

Train at Start

IM to RU:
optional,
agreed between IM and RU.

this message is
if nothing else is

Train
completed.

preparation

can

be

IM to RU: this message may
be sent by the IM,
if this is
detected by him.

RU possibilities:

modify the train composition,

or

train path and request

cancel
new path .

RU to IM: this message must be sent.

IM to RU: defines exactly where and when the train must present
itself on the network. This message may be sent depending on
national rules.

RU to IM: this message may be sent to indicate that the train has
started its journey as response on the message: Train Position.

This message may be sent depending on national rules.

Train Running Information

IM to RU: this message must be sent to indicate that the train has
arrived on the infrastructure.

These messages are described by mentioning the main points in the following chapters. The detailed formats are
defined in Annex A, Index 1. The logical sequence is shown in Annex A, Index 5, Chapter 3.

Remark: During the train preparation also a Train Path Not Available message can occur, since this message can
be send at any time between the moment the train path is contracted and the departure of the train. The proce-
dure for this is described in Chapter 4.2.2 (Path request).

4.2.3.2. Tr a i n Composi ti on me ssa g e

This message must be sent from the RU to the next RU, defining the composition of the train. This message
must also be sent from the RU to the IM(s) when requested by the Conventional Rail TSI Operation and Traffic
Management or by the contract between IM and RU. Whenever there is a change in the composition during the
journey of a train, the RU responsible has to update this message to all parties involved.

The information, which must be transmitted and be accessible, is:

— train number and path number to identify the path,

— path departure point and date and time for which the path was requested,

— path destination point and date and time at which the proposed train is due to arrive at its destination,

— loco(s) identification and position of loco(s) in the train,

— train length, train weight, maximum speed of the train,

— train composition with the sequence of vehicle IDs,

— command and control system including type of radio equipment,

L 13/24

EN

Official Journal of the European Union

18.1.2006

— information concerning exceptional gauging,

— UN/RID numbers of dangerous goods,

— indication if livestock and people (other than the train crew) will be carried,

— braking system to be used,

— wagon data.

After the receipt of the train composition the IM may verify the entries against the contracted path, if the
contract between IM and RU explicitly allows this. In that case the IM must have easy access to the information
about possible restrictions in the relevant infrastructure, to the technical wagon data (Chapter 4.2.11.3: The
Rolling Stock Reference Databases), to the dangerous goods reference file and to the current, updated informa-
tion status on the wagons (Chapter 4.2.12.2: Other databases , Wagon and Intermodal Unit Operational Data-
base). This refers to all wagons on the train. In that case also, the IM, who manages his train paths and keeps up
the actual status of the path information, must add the train details of the train composition to the path and
train data as mentioned in Chapter 4.2.2.1 (Path request, Preliminary remarks).

4.2.3.3. Tr a i n A cc e pte d m essa g e

Depending on the contractual agreement between the IM and the RU and on regulatory requirements, the IM
may also advise the RU if the train composition is acceptable for the booked path. This is effected with this
message.

The main contents of this message are:

— train and path number,

— path departure point with date and time for which the path was requested,

— path destination point with date and time at which the proposed train is due to arrive at its destination,

— indication that the IM has accepted the train composition as being suitable for the agreed path.

4.2.3.4. Tr a i n N ot S u i ta ble messa g e

If the train is not suitable for the previously agreed path, the IM may inform the RU, with this message. In this
case the RU must recheck the train composition. The main contents of this message are:

— train and path number,

— path departure point with date and time for which the path was requested,

— path destination point with date and time at which the proposed train is due to arrive at its destination,

— Not Suitable indication, which indicates that the train does not match the allocated path and therefore may

not run,

— indication of the cause.

4.2.3.5. Tr a i n R ea dy me ssa g e

This message must be sent from RU to IM indicating that the train is ready for access to the network. The main
contents of this message are:

— train and path number,

— path departure point with date and time for which the path was requested,

— path destination point with date and time at which the proposed train is due to arrive at its destination,

— Train Ready indication, which indicates that the train has been prepared and is ready to run,

— control contact ID for all ship-to-shore communications,

— if the contractual arrangement between RU and IM does not require the Train Position/Train at Start
message exchange, the train journey start date/time, which informs the IM of the forecasted date/time at
which the train will present itself to the network, must be defined in this message. In the case of the required
message exchange Train Position/Train at Start, this data element must not be transmitted.

18.1.2006

EN

Official Journal of the European Union

L 13/25

4.2.3.6. Tr a i n Posi ti on m essa g e

This message may be sent from the IM to the RU defining exactly when and where the train should present
itself to the network as an answer to the Train Ready message. The transmission of this message depends on the
contractual arrangement between the RU and the IM. In case where the transmission is needed, the main
contents of this message are:

— train and path number,

— path departure point with date and time for which the path is requested,

— path destination point with date and time at which the proposed train is due to arrive at its destination,

— track identification, which informs the RU of the track ID on which the train should present itself to the

network,

— train journey start date/time, which informs the RU of the precise date/time at which the train should

present itself to the network,

— control contact ID.

4.2.3.7. Tr a i n a t Sta r t me ssa g e

This message may be sent from the RU to the IM when having received a Train Position message from the IM,
to indicate that the train has started its journey. This message must have an identifier to which it refers and the
indication:

— Train at Start: date/time train actually started journey.

4.2.3.8. Tr a i n R un ni ng Infor ma ti on

As soon as the train is present on the IM infrastructure, which means that the train has left the departure
station, the IM sends this message to the RU who has booked the path. This message is described in Chapter
4.2.4 (Train running forecast).

4.2.4. Train running forecast

4.2.4.1. Ge ne ra l r ema rk s

This section specifies the messages which must be exchanged during the normal running of a train without any
interruption.

The relevant messages are:

Train Running Forecast,

Train Running Information.

This information exchange between RUs and IMs always takes place between the IM in charge and the RU, who
has booked the path on which the train is actually running. In the case of Open Access, which means that the
paths for the complete journey are booked by one RU (this RU also operates the train during the complete
journey), all messages are sent to this RU. The same is true, if the paths for the journey are booked by one RU
via OSS.

For further consideration the following scenarios will be differentiated, taking into account the various commu-
nication relations between RUs and IMs according to the path booking scenarios of Chapter 4.2.2.1 (Path
request, Preliminary remarks, Scenario A and B):

— Train approaching a handover point between IM n1 and his neighbour IM n2

It is supposed that the handover point is not also an interchange (only Scenario B) nor a handling point. Thus,
the handover point is a point on the booked paths of one RU and the RU has already sent the train composition
to IM n2, whilst simultaneously sending this message to IM n1.

IM n1, after departure from the departure point (1), must send a Train Running Forecast message to IM n2 with
the estimated handover time (ETH). This message is simultaneously sent to the RU.

(1) Under departure point the start point of the path is understood, which can be the train departure point for the journey or an inter-

change point. The handover point is the end point of the path.

L 13/26

EN

Official Journal of the European Union

18.1.2006

When the train leaves the infrastructure of IM n1 at the handover point this IM sends a Train Running Informa-
tion with the actual handover time at this point to its path contracted RU.

When the train arrives on the infrastructure of IM n2 at the handover point this IM sends a Train Running
Information with the actual handover time from this point to its path contracted RU.

— Train approaching an interchange point between RU 1 and the next RU 2 (only Scenario B)

In the path contract an interchange point must always be defined as a reporting point. (TETAs at reporting points
will be generated by the IMs as specified in their contracts with the RUs.)

For this point the IM in charge sends, once the train left the previous reporting point, a Train Running Forecast
message with the TETA for this interchange point to the RU which has contracted the path with him (e.g. RU
1). RU 1 transfers this message to the next RU (e.g. RU 2) supposed to take over the train. Additionally, this
message is also sent to the Lead RU (LRU) for the transport if there is one and if this is defined in the coopera-
tion contract between both RUs.

If the interchange point is also a handover point between e.g. IM n1 and IM n2, IM n1 sends the Train Running
Forecast message already after departure from the departure point or from the previous interchange point to IM
n2 with the estimated handover time (ETH). This message is also sent to the RU having contracted the path e.g.
RU 1. For the RU the ETH is equal to the TETA at the interchange point. RU 1 transfers this message to its
neighbour RU 2 and to the Lead RU for the transport if there is one and if this is defined in the cooperation
contract between both RUs.

When the train arrives at an interchange point, the IM must send a Train Running Information to his path
contracted RU, for example RU 1, with the actual time of the arrival at that point.

Before the train leaves the interchange point, RU 2 must send a new Train Composition message to the IM
having allocated the path and follow the departure procedure as defined in Chapter 4.2.3 (Train preparation).

— Train approaching a handling point of an RU (Scenario A)

A handling point must always be defined in the path contract as a reporting point.

For this point the IM in charge must send a Train Running Forecast message with a TETA only if this is specified
in contract between IM and RU.

But if the handling point is also a handover point between, for example, IM n1 and IM n2, IM n1 must send the
Train Running Forecast message after departure from the departure point or from the previous interchange to
IM n2 with the estimated handover time (ETH). This message is also sent to the RU. For the RU the ETH is
equal to the TETA at the handling point.

When the train arrives at the handling point, the IM must send a Train Running Information with the actual
time of arrival at this point to the RU.

Before the train leaves the handling point the RU and IM must follow the departure procedure as defined in
Chapter 4.2.3 (Train preparation).

— Train arrival at destination

When the train arrives at its destination the IM responsible sends a Train Running Information message with
the actual arrival time to the RU which contracted the path.

Remark: In the path contract other locations may also be defined for which a Train Running Forecast with TETA
and Train Running Information messages with the actual time are requested. For these points the IM in charge
sends these messages as specified in the contract. The further evaluation and processing of the delivered ETHs
and TETAs is described in the Chapters 4.2.7 (Shipment ETI/ETA) to 4.2.9 (Interchange reporting).

In the following chapters the message Train Running Forecast and Train Running Information are described by
mentioning only the main contents. The detailed formats are defined in Annex A, Index 1. The logical sequence
of this message exchange relating to the different communication scenarios is shown in Annex A, Index 5,
Chapter 4 with the remark, that regarding the communication relation between RU and IMs for train running,
the two path request scenarios A(case A) and A(case B) (Chapter 4.2.2.1: Path request , Preliminary remarks) are
identical, because in both cases the IMs know only one RU e.g. RU1 which operates the complete path and is
also responsible for new train composition at the handling points.

18.1.2006

EN

Official Journal of the European Union

L 13/27

4.2.4.2. Tr a i n R un ni ng F or e c a st me ssa g e

This message must be issued by the IM for handover points, interchange points and for the train destination as
described in Chapter 4.2.4.1 (Train running forecast, General remarks).

In addition, the message must be issued by the IM to the RU for other reporting points according the RU/IM
contracts (e.g. for handling points).

The main data elements are:

— path number and train number,

— scheduled departure date and time at IM location (or scheduled handover time to next IM),

— reporting point identification,

— forecasted date/time at reporting point.

4.2.4.3. Tr a i n R un ni ng Infor ma ti on me ssa g e

This message must be issued upon:

— departure from departure point, arrival at destination,

— arrival and departure at handover points,

interchange points and at agreed reporting points based on

contract (e.g. handling points).

The main data elements are:

— path number and train number,

— scheduled departure date and time at IM location,

— most recent reporting point identification,

— actual time at reporting point,

— train reporting point status (Arrival, Departure, Passage, Not Specified, Departure from Origin, Arrival at

Destination),

— arrival track at location,

— departure track from location,

— booked scheduled time delta deviation minutes,

— current schedule if multiple re-schedules,

— For each deviation from ‘Booked Scheduled Time’ at that reporting location:

— reason code (perhaps multiple),

— deviation time for this reason code (multiple reasons may be posted per reporting point),

— may add free text about deviation.

4.2.5. Service disruption information

4.2.5.1. Ge ne ra l r ema rk s

When the RU learns about a service disruption during the train running operation for which it is responsible, it
must immediately inform the IM concerned (no IT-message, e.g. orally by the driver). If necessary the RU
updates the Wagon and Intermodal Unit Operational Database. If necessary the IM updates the infrastructure
data in the Infrastructure Restriction Notice Database and/or the path, respectively the train database.

If the delay exceeds x minutes (this value must be defined in the contract between RU and IM) the IM concerned
must send to the RU a Train Running Forecast message relating to the next reporting point.

If the train is cancelled, the IM sends a Train Running Interrupted message as specified below.

In the cases of exceptions where the RU or the IM is not able to run the train at the forecasted time, a new path
according Chapter 4.2.2 (Path request) must be negotiated.

L 13/28

EN

Official Journal of the European Union

18.1.2006

4.2.5.2. Tr a i n R un ni ng Inte rr u pte d messa g e

If the train is cancelled this message is issued by the IM to the neighbouring IM and to the path contracted RU.

The main data elements in this message are:

— path and train number,

— location identification,

— scheduled departure date and time at this location,

— interruption reason,

— interruption description.

4.2.6. Train location

4.2.6.1. Pr e fa c e

This section specifies the tracing possibility to get information about train location. The RU may send an
enquiry to the IM about its trains at any time. The RU may enquire about:

— the running of the train (last recorded location, delays, delay reasons),

— a train's performance (delays, delay reasons, delay locations),

— all identifiers of a specified train,

— train forecast at a specified location,

— all train running forecasts for a specified location.

The access to this information must be independent from the communication relation RU/IM during the train
running, which means that the RU must have a single (1) access address to this information. The information is
based mainly on the stored message exchange as mentioned above.

4.2.6.2. En qu i r y a bou t the Tr a i n R u nni ng me ssa g e s

Purpose:

RU to enquire on the last recorded status (location, delays and delay reasons) of one specific train on
the infrastructure of a specified IM.

Enquiry: main data elements:

— train running number,

— IM identifier,

— scheduled departure date and time at IM location.

Response:

information data:

— most recent reporting location,

— actual time at reporting point,

— train reporting point status (Arrival, Departure, Passage, Not Specified, Departure from Origin,

Arrival at Destination),

— arrival track at location,

— departure track from location,

— booked scheduled time,

— booked scheduled time delta delay,

— re-scheduled time (against current schedule if multiple re-schedules),

— for each delay at that reporting location:

— reason code and delay time for this reason code.

(1) This means, that the access to this information must be independent from which IM has stored the information or part of it.

18.1.2006

EN

Official Journal of the European Union

L 13/29

4.2.6.3. En qu i r y a bou t the Tr a i n De la y / Per f or ma n ce me ssa g e s

Purpose:

RU to enquire on all of the delays to a specific train with a particular IM.

Enquiry: main data elements:

— train running number,

— IM identifier,

— scheduled departure date and time at IM location.

Response:

information data (same information as with ‘Enquiry about train running’, not only for the most
recent point but for each reporting point of the train on the infrastructure of the specified IM):

— for each reporting point:

— most recent reporting location,

— actual time at reporting point,

— train reporting point status (Arrival, Departure, Passage, Not Specified, Departure from

Origin, Arrival at Destination),

— arrival track at location,

— departure track from location,

— booked scheduled time,

— booked scheduled time delta delay,

— re-scheduled time (against current schedule if multiple re-schedules),

— for each delay at that reporting location:

— reason code and delay time for this reason code.

4.2.6.4. En qu i r y a bou t Tr a i n Ide nti f i e r me ssa g e s

Purpose:

RU to enquire about the current train identifier and its previous train identifiers. Any of the train
identifiers for a specific train can be used for the enquiry.

Enquiry: main data elements:

— known train running number,

— IM identifier,

— scheduled departure date and time at the IM location.

Response:

information data:

— current train identifier:

— train running number,

— scheduled departure date and time at the IM location,

— for each other train identifier:

— train running number,

— scheduled departure date and time at the IM location.

4.2.6.5. En qu i r y to IM a bou t the T ra i n F or e ca st me ssa g e s

Purpose:

RU to enquire about the forecast time for a specified train at a particular reporting location or by
missing out the reporting location, to enquire on the forecast time at the handover point from the
IM.

L 13/30

EN

Official Journal of the European Union

18.1.2006

Enquiry: main data elements:

— train running number,

— scheduled departure date and time at IM location,

— reporting location identifier (The reporting location for which the forecast is required. This is
optional and, if not stated, the response refers to the final reporting point for that IM for this
train.).

Response:

information data:

— IM code,

— reporting point identification,

— forecasted date/time at reporting point.

4.2.6.6. En qu i r y to IM a bou t T ra i n s a t R ep or ti ng L oca ti on me ssa g es

Purpose:

RU to enquire about all his trains at a particular reporting location on the infrastructure of a specific
IM.

Enquiry: main data elements:

— IM code,

— reporting location identification (The reporting location for which the forecast is required. This is
optional and, if not stated, the response should be the final reporting point for that IM for this
train.).

Response:

information data:

— for each of this enquirer's trains:

— train running number,

— scheduled departure date and time at IM location or scheduled handover time,

— IM code,

— reporting point identification,

— forecasted date/time at reporting point.

4.2.7. Shipment ETI/ETA

4.2.7.1. Pr e li mi na ry re ma r k

The Chapters 4.2.2 (Path request) through to 4.2.6 (Train location) have mainly described the communication
between the RU and the IM. Since the task of the infrastructure manager is the monitoring and control of the
trains the key element for this communication is the train number. The wagon information part of the train
composition message is relevant for checking the train composition against the IM/RU path-contract and in
cases of exceptions.

The individual monitoring of wagons or intermodal units is not covered by this information exchange. This is
done on the RU/LRU level based on the train related messages and is described in the following Chapters 4.2.7
(Shipment ETI/ETA) to 4.2.9 (Interchange reporting).

The wagon or intermodal unit related information exchange and updating are essentially supported by storage
of ‘trip plans’ and ‘wagon movements’ (Chapter 4.2.12.2: Other databases).

As already mentioned in Chapter 2.3.2 (Considered processes), for a customer the most important information
is always the estimated time of arrival (ETA) for his shipment. The wagon related ETA as well as the ETI is also
the basic information in the communication between LRU and RU. This information is the main instrument for
the LRU to monitor the physical transport of a shipment and to check it against the commitment to the
customer.

18.1.2006

EN

Official Journal of the European Union

L 13/31

The forecasted times in the train related messages are all related to an arrival of a train at a certain point, which
may be a handover point, interchange point, the train destination or another reporting point. These are all Train
Estimated Times of Arrivals (TETA). For the various wagons or intermodal units in the train, such a TETA may
have different meanings. A TETA for an interchange point, for example, may be an estimated time of inter-
change (ETI) for some wagons or intermodal units. For other wagons remaining in the train for further transpor-
tation by the same RU, the TETA might have no relevance. It is the task of the RU receiving the TETA informa-
tion to identify and process that information, store it as a wagon movement in the Wagon and Intermodal Unit
Operational Database and communicate it to the LRU, if the train is not running in Open Access mode. This is
now considered in the following chapters.

4.2.7.2. ET I/ ET A c a lc u la ti on

The ETI/ETA calculation is based on the information from the infrastructure manager in charge, which sends,
within the Train Running Forecast message, the Train Estimated Time of Arrival (TETA) for defined reporting
points (in any case for handover, interchange, or arrival points including intermodal terminals) on the agreed
train path e.g. for the handover point from one IM to the next IM (in this case TETA is equal to ETH).

For the interchange points or for other defined reporting points on the agreed train path, the RU must calculate
for the next RU in the transport shipment chain, the estimated time of interchange (ETI) for the wagons and/or
intermodal units.

As an RU may have wagons with different journeys and from various LRUs within the train, the interchange
point for the ETI calculation for the wagons may be different. This is explained in the following two simplified
examples (The pictorial representation of these scenarios is given in Annex A, Index 5, Chapter 1.4 and the
sequence diagram based on example 1 for the interchange point C is shown in Annex A, Index 5, Chapter 5).

Example 1: RU 1 has wagons No 1 and 2 from LRU 1 and wagons No 3 to 5 from LRU 2 within the same
train. At the interchange point C the further transport of the wagons 1 and 2 will be done by RU 2
and for the wagons 3 to 5 by RU 3. In this case RU 1 must calculate related to the interchange
point C the ETI for the wagons 1 and 2 and must send these values to LRU 1. RU 1 must also
calculate related to the same interchange point C the ETI for the wagons 3 to 5 and send these
values to LRU 2.

Example 2: RU 1 has wagons No 1 and 2 from LRU 1 and wagons No 3 to 5 from LRU 2 within the same
train. At the interchange point C the further transport of the wagons 3 to 5 will be done by RU 3
whereas the wagons 1 and 2 remain in the train of RU 1 until the interchange point E, where the
responsibility for these wagons will be changed to RU 2. In this case RU 1 must calculate related to
the interchange point C only the ETI for the wagons 3 to 5 and must send these values to LRU 2.
For the wagons 1 and 2 the interchange point C is not relevant. The next relevant interchange
point for these wagons is E and related to this point the RU 1 must calculate the ETI and send
these values to LRU 1.

The next RU, based upon the ETI input of the preceding RU, calculates for its part the wagon related ETI for the
next interchange point. These steps are effected by each succeeding RU. When the last RU (e.g. RU n) in the
transport chain of a wagon receives the ETI from his preceding RU (e.g. RU n-1) for the interchange of the
wagon between RU n-1 and RU n, the last RU (RU n) must calculate the estimated time of arrival of the wagons
at the final destination. This is to cater for the placement of the wagons according to the wagon order and in
line with the commitment of the LRU to his customer. This is the ETA for the wagon and must be sent to the
LRU. It must be electronically stored along with wagon movement. The LRU must grant access to the customer
for his relevant data, according to contractual conditions.

Remark on intermodal units: for the intermodal units on a wagon, the wagon ETIs are also ETIs for the inter-
modal units. Regarding the ETAs for intermodal units it should be noticed, that the RU is not in the position to
calculate such an ETA beyond the rail transportation part. Therefore the RU can only deliver ETIs related to the
intermodal terminal.

The Lead RU is responsible for the comparison of the ETA with the commitment to the customer.

Deviations of the ETA against the commitment to the customer must be handled in accordance with the
contract and may lead to an alert management process by the LRU. For the transmission of information on the
result of this process is foreseen the Alert message.

As a basis for the Alert management process the LRU must have the possibility for a wagon related enquiry on
deviations. This enquiry of an LRU and the response from an RU is also specified below.

L 13/32

EN

Official Journal of the European Union

18.1.2006

4.2.7.3. Wa g on ET I/E T A me ssa g e

Purpose:

sending ETI or updated ETI from one RU to the next in the transport chain. The last RU
in the transport chain of the wagons sends the ETA or updated ETA to the LRU.

Main data elements: — RU identification which has produced the ETI or ETA,

— departure or previous interchange station (ETI or departure time at origin station),

— train number starting from departure or previous interchange station (from ETI or

departure time at origin station),

— actual departure date and time of the train,

— arrival or next interchange station (ETI/ETA end),

— train number arriving at the ETI/ETA end station (arrival or next interchange station),

— arrival date and time of the wagon (ETI or ETA).

4.2.7.4. A le rt messa g e

Purpose:

following the comparison between ETA and commitment to the customer, the LRU may
send an Alert message to the RUs involved.

Main data elements: — wagon number,

— commitment to the customer: arrival date and hour,

— actual ETA: date and time.

Remark: In case of Open Access the calculation of ETI and ETA is an RU internal process. In this case the RU is
the lead RU itself.

4.2.7.5. En qu i r y a bou t Wa g on de v i a ti on me ssa g e s

Purpose:

LRU to enquire on the deviations to a specific wagon.

Enquiry: main data elements:

— wagon number,

— LRU identifier.

Response:

Information data:

— for each reporting point:

— reporting location,

— wagon reporting point status (departure, yard arrival, yard departure,

interchange arrival,

arrival at destination yard),

— responsible RU at reporting location and according wagon reporting point status,

— re-scheduled time (against current schedule if multiple reschedules),

— ETI, if reporting point is an interchange point,

— actual time at reporting point,

— for each deviation at that reporting point:

— reason code and delay time for this reason.

4.2.8. Wagon movement

4.2.8.1. Pr e li mi na ry re ma r ks

For the reporting of the movement of a wagon, the following data must be stored and electronically accessible.
They must be also exchanged within message on contractual base to authorised parties. The detailed formats are
defined in Annex A, Index 1.

— Wagon Release Notice

— Wagon Departure Notice

18.1.2006

EN

Official Journal of the European Union

L 13/33

— Wagon Yard Arrival

— Wagon Yard Departure

— Wagon Exceptions message

— Wagon Arrival Notice

— Wagon Delivery Notice

— Wagon Delivery Confirmation

— Wagon Interchange Reporting, will be described separately in Chapter 4.2.9: Interchange reporting

4.2.8.2. Wa g on R e lea se Noti c e me ssa g e

Purpose:

LRU to RU: The Lead RU is not necessarily the first RU in the transport chain. In this
case the LRU must tell the RU in charge that the wagon is ready for pull at the customer
sidings (place of departure according to the LRU commitment) at the given release time
(date and time of departure).

This event must be stored in the Wagon and Intermodal Unit Operational Database.

Main data elements: — wagon number,

— place, date and time of departure (place from which a transport is scheduled to

depart).

The following data must be easy accessible to RU and LRU as stored data in databases:

— transportation unit, identification, size and type,

— unit capacity used,

— total weight

(booked/actual total weight

(mass) of goods,

including packing and

carrier's equipment),

— dangerous goods indication.

4.2.8.3. Wa g on Dep a r tu r e Noti c e me ssa g e

Purpose:

RU to LRU: The RU must inform the LRU of the actual date and time that the wagon has
been pulled from the place of departure.

This event must be stored in the Wagon and Intermodal Unit Operational Database. With
this message exchange the responsibility for the wagon changes from customer to the
RU.

Main data elements: — wagon number,

— place, date and time of departure (place from which a transport is scheduled to

depart).

The following data must be easy accessible to RU and LRU as stored data in databases:

— transportation unit, identification, size and type,

— unit capacity used,

— total weight

(booked/actual total weight

(mass) of goods,

including packing and

carrier's equipment),

— dangerous goods indication.

4.2.8.4. Wa g on Ya rd A r r i v a l me ssa g e

Purpose:

The RU must inform the LRU, that the wagon has arrived at its yard. This message can be
based on a Train Running Information message from Chapter 4.2.4 (Train running fore-
cast). This event must be stored in the Wagon and Intermodal Unit Operational Database.

Main data elements: — wagon number,

— yard of arrival identification,

— date and time of arrival at the yard.

L 13/34

EN

Official Journal of the European Union

18.1.2006

4.2.8.5. Wa g on Ya rd De pa r tu re me ssa g e

Purpose:

The RU must inform the LRU, that the wagon has left its yard. This message can be based
on a Train Running Information message from Chapter 4.2.4 (Train running forecast).
This event must be stored in the Wagon and Intermodal Unit Operational Database.

Main data elements: — wagon number,

— yard of departure identification,

— date and time of departure from the yard.

4.2.8.6. Wa g on Ex c ep ti on m essa g e

Purpose:

The RU must inform the LRU if something unexpected occurs to the wagon, which might
have an impact for the ETI/ETA, or requires any additional action. This message requires
in most of the cases also a new ETI/ETA calculation. If the LRU decided to have a new
ETI/ETA, it sends a message back to the RU, which has sent this message together with
the indication ‘ETI/ETA requested’ (message: Wagon Exception message New ETI/ETA
Request). The new ETI/ETA calculation must follow the procedure of Chapter 4.2.7
(Shipment ETI/ETA).

This information must be stored in the Wagon and Intermodal Unit Operational Data-
base.

Main data elements: — wagon number,

— place, date and time of disruption (place where something unexpected happens during

the transport),

— reason/disruption code.

In addition the following data must be easily accessible as stored data in databases:

— transportation unit identification,

— dangerous goods indication.

4.2.8.7. Wa g on Ex c ep ti on m essa g e N ew ET I/ E T A R e q ue st

Purpose:

The LRU may send this message to the actual RU, which has sent the Exception message,
to request for new ETI/ETA calculation. The LRU sends this message also to all following
RUs to inform them about the deviations. The need for a new ETI/ETA calculation is up
to the LRU and is not necessary in any cases.

Main data elements: — wagon number,

— place, date and time of disruption (place where something unexpected happens during

the transport),

— reason/disruption code,

— new ETI/ETA request.

In addition the following data must be easy accessible as stored data in databases:

— transportation unit identification,

— dangerous good indication.

4.2.8.8. Wa g on A r ri v a l N oti c e messa g e

Purpose:

The last RU in a wagon or intermodal unit transport chain must inform the LRU that the
wagon has arrived at its yard (RU location).

Main data elements: — wagon number,

— identification of yard of the RU,

— date and time of arrival.

18.1.2006

EN

Official Journal of the European Union

L 13/35

4.2.8.9. Wa g on Deli v e ry N oti c e messa g e

Purpose:

The last RU in a wagon transport chain must inform the LRU that the wagon has been
placed at the consignee's sidings.

Main data elements: — wagon number,

— identification of placement on consignee sidings (location, zone, track, slot),

— date and time of placement.

The Wagon Delivery Notice may be sent a second time as a Wagon Delivery Confirmation with the additional
data:

— customer identifier.

Remark: In the case of Open Access the described wagon movement is an RU (LRU) internal process. Neverthe-
less all calculations and data storage must be effected by it as the LRU having a contract with and a commitment
to the customer.

The sequence diagram for these messages based on example 1 for the ETI calculation for the wagons 1 and 2
(see Chapter 4.2.7.2 ETI/ETA calculation) is integrated in the diagram for interchange reporting in Annex A,
Index 5, Chapter 6.

4.2.9. Interchange reporting

4.2.9.1. Pr e li mi na ry re ma r k

The interchange reporting describes the messages attached to the transfer of responsibility for a wagon between
two railway undertakings, which occurs at interchange points. It also commands the new RU to make an ETI
calculation and to follow the process as described in Chapter 4.2.7 (Shipment ETI/ETA).

The following messages must be exchanged:

— Wagon Interchange Notice,

— Wagon Interchange Notice/Sub,

— Wagon Received At Interchange,

— Wagon Refused At Interchange.

The information data of these messages must be stored in the Wagon and Intermodal Unit Operational Data-
base. In case of any deviation a new ETI/ETA must be generated and communicated according to the process
described in Chapter 4.2.7: Shipment ETI/ETA . The sequence diagram for these messages is shown in connec-
tion with the wagon movement messages in Annex A, Index 5, Chapter 6.

The Wagon Interchange Notices and the Wagon Interchange Notices/Sub as well as the wagon received
messages may be transferred as a list for various wagons, especially if these wagons are all within one train. In
this case all the wagons may be listed within one message transfer.

In the case of Open Access there are no interchange points. At a handling point the responsibility for the
wagons does not change. Therefore there is no special message exchange needed. But derived from the running
information of the train at this reporting point, the wagon or intermodal unit related information — regarding
location and date/time of arrival and departure — must be processed and stored in the Wagon and Intermodal
Unit Operational Database.

The contents of these messages are given as follows:

4.2.9.2. Wa g on In ter c ha n g e Noti ce me ssa g e

Purpose:

With the Wagon Interchange Notice a railway undertaking (RU 1) asks the next railway
undertaking (RU 2) in the transport chain whether it accepts the responsibility for a
wagon. With the Wagon Interchange Notice/Sub the RU 2 informs its IM, that it has
accepted the responsibility.

L 13/36

EN

Official Journal of the European Union

18.1.2006

Main data elements: — wagon number,

— train number (only if the wagon is in a train),

— location; date and time of interchange.

In addition the following data must be easily accessible as stored data in databases:

— transportation unit identification (number, size, type),

— total weight

(booked/actual total weight

(mass) of goods,

including packing and

carrier's equipment),

— unit capacity used,

— dangerous good details, ID.

4.2.9.3. Wa g on In ter c ha n g e Noti ce / S ub me ssa g e

Purpose:

With the Wagon Interchange Notice/Sub the RU 2 informs the IM, that it has taken over
the responsibility of a particular wagon.

Main data elements: — wagon number,

— train number (only if the wagon is in a train),

— location, date and time of interchange.

In addition the following data must be easily accessible as stored data in databases:

— dangerous goods details, identification.

4.2.9.4. Wa g on R e ce i v ed A t In ter c ha n g e me ssa g e

Purpose:

With the Wagon Received At Interchange message the RU 2 informs RU 1 that it accepts
the responsibility for the wagon.

Main data elements: — wagon number,

— location, date and time of interchange.

4.2.9.5. Wa g on R e fu se d A t Inte rc ha ng e m essa g e

Purpose:

With the Wagon Refused At Interchange message the RU 2 informs RU 1 that it is not
willing to take over the responsibility for the wagon.

Main data elements: — wagon number,

— location, date and time of interchange,

— reason code for the refuse,

— further description (optional).

4.2.10. Data exchange for quality improvement

To be competitive the European Railway Industry must deliver higher service quality to its customers (see also
Annex III, Article 2.7.1 to the Directive 2001/16/EC).

A measurement process is an essential post trip process to support quality improvements.

In addition to measuring the service quality delivered to the customer, LRUs, RUs and IMs must measure the
quality of the service components that in total make up the product delivered to the customer.

The process involves the IMs and the RUs (especially if they are Lead RUs) selecting an individual quality para-
meter, a route or location and a measurement period in which actual results are to be measured against prede-
termined criteria and which normally have been set out in a contract.

The results of the measurement process must clearly show the achievement level against the target which has
been agreed upon between the contracting parties.

The measurement reports must be able to access sufficient detail to allow an analysis to indicate the location
and apparent cause of reductions in quality, e.g. delays. Root cause analysis must then be carried out on repeti-
tive, quality failures, so that corrective action can be determined by the contracting parties.

18.1.2006

EN

Official Journal of the European Union

L 13/37

It is the obligation of an IM and an RU to provide data, participate in root cause analysis, also with third parties,
and to implement any corrective action which has been agreed to.

The measurement process is a repetitive one.

To measure quality the already defined messages may be used as shown under the six headings, listed below:

1. LRU/customer: Transit Time, ETA, Alert Resolution

In contracts between RUs acting as service integrators (LRU) and customers, commitments can be made
(depending on the individual agreement) regarding transit time, ETA and alert resolution. The most relevant
messages for this measurement of quality are:

— Release Notice,

— Departure Notice,

— Delivery notice.

2. LRU/service providers: Transit and Handling Times, ETAs, ETIs, Reason Codes

In contracts between a Lead RU and other transport service providers commitments can be made concerning
transit times (hours) with individual service providers as follows:

— release cut off/pull time to interchange delivery,

— pick up to in gate,

— in gate to loading,

— interchange receipt to interchange delivery,

— interchange receipt to placement/constructive placement,

— grounding to delivery.

The most relevant messages for this measurement of quality are:

— Release Notice,

— Departure Notice,

— Yard Arrival,

— Yard Departure,

— Arrival Notice,

— Wagon Interchange Delivery,

— Wagon Interchange Receipt,

— Wagon Interchange Refused.

3. RU/IM: Train Performance, Train ETA (TETA), ETH

In contracts between RUs and IMs, a punctuality level for train schedules at specified reporting points can be
specified as can the accuracy of train ETAs and ETHs. The most relevant messages for this measurement of
quality are:

— Train Running Forecast,

— Train Running Information,

— Enquiry/Response about train delay/performance.

4. RU/IM: Path Availability/Planned

In contracts between RUs and IMs path availability to run trains will be clearly described in terms of a range of
times at specified points. Train specifications in terms of maximum length and gross weight, loading gauge etc.,
will also be covered in these contracts. This aspect will be addressed under item number 6 (IM/RU: Train
composition quality).

L 13/38

EN

Official Journal of the European Union

18.1.2006

The procedures and time frames for confirming the utilisation of a path, cancelling the use of a planned path
and the extent to which a path can be used outside (early or late) the specified range of times will also be
covered in these contracts. The most relevant messages for this measurement of quality are:

— Path Cancelled,

— Path Not Available.

5. RU/IM: Path Availability on short notice

When an RU wants to run a train outside the time limits established for a planned path, a path request on short
notice must be sent to the IM(s) involved (as provided in the Directive 2001/14/EC).

Periodically the RU will compare the path request and the response data for producing reports as follows:

— path request response time against framework agreement,

— number of paths supplied within certain time periods, within the requested time,

— number of rejected path requests.

The most relevant messages for this measurement of quality are:

— Path Request,

— Path Details,

— Path Details Refused,

— Path Cancelled,

— Path Not Available.

6. IM/RU: Train composition quality

When the train ready messages and/or train composition lists are sent by an RU to the IM(s) or to other RUs,
they must comply with the train specifications contained within the applicable contract. For the checking of this
compliance and therefore for the measurement of the train composition quality the most relevant messages are:

— Train Composition,

— Train Not Suitable.

4.2.11. The main reference data

4.2.11.1. Pr e fa c e

The Infrastructure Data (the Network Statements and the stored data in the Infrastructure Restriction Notice
Database) and Rolling Stock Data (in the Rolling Stock Reference Databases and in the Wagon and Intermodal
Unit Operational Database) are the most important data for the operation of freight trains on the European
network. Both types of data together allow an assessment of the compatibility of the rolling stock with the infra-
structure, help to avoid multiple data input, which increase especially the data quality, and they give a clear
picture on all available installations and equipment at any time for fast decisions during the operation.

4.2.11.2. The Inf ra str uc tu r e R estri c ti on Noti c e Da ta ba ses

Each IM is responsible for the suitability of a path on his infrastructure and the RU is obliged to check the train
characteristics against the values given in the path details of its contracted path.

Without prejudice to the conditions for the usage of a path in the Network Statements or to the responsibilities
in case of any restrictions in the infrastructure explained in the TSI Operation and Traffic Management, the RU
must know before preparing the train, whether there are any restrictions on the line segments or stations
(nodes) affecting its train composition described in the path contract.

18.1.2006

EN

Official Journal of the European Union

L 13/39

For this the IMs must install and fill-in Infrastructure Restriction Notice Databases. The structure of such a data-
base is outlined in Annex A, Index 2. The entries of these databases are based on segments in line with the rele-
vant Network Statements with the addition of restriction information. These databases must be accessible via
the common interface (4.2.14.1: General architecture and 4.2.14.7: Common interface).

The RU is obliged to take into account all restrictions in the Infrastructure Restriction Notice Database affecting
its train running until the pre-departure period. If nothing else is defined in a contract between the IM and RU,
the pre-departure period starts one hour before the scheduled time of departure.

In the pre-departure period the IM must notify directly the RU of any relevant changes arising in the Infrastruc-
ture Restriction Notice Database.

4.2.11.3. The R oll i n g S toc k R ef er e nc e Da ta ba ses

The keeper of a rolling stock is responsible for the storage of the rolling stock data within a Rolling Stock Refer-
ence Database.

The Information that must be included in the individual Rolling Stock Reference Databases is described in detail
in Annex A, Index 2. They must contain all items for:

— identification of rolling stock,

— assessment of the compatibility with the infrastructure,

— assessment of relevant loading characteristics,

— brake relevant characteristics,

— maintenance data,

— environmental characteristics.

The Rolling Stock Reference Databases must allow easy access (a single common access provided via the
common interface) to the technical data to minimise the volume of data transmitted for each operation.
Contents of the databases must be accessible, based on structured access rights depending on privilege to all
service providers (IMs, RUs, logistic providers and fleet managers) in particular for purposes of fleet management
and rolling stock maintenance.

The entries in the Rolling Stock Reference Database can be grouped as follows:

— Administrative data,

related to certification and registration items such as reference to the EC registration file, ID of the notified
body, etc.; this may include historical data related to ownership, rental, etc. The following steps have to be
taken into account:

— EC certification,

— registration in the ‘home’ State,

— date put into service in the State of registration,

— registration in other countries for the use on their national network,

— safety certification for all rolling stock which does not comply with the Rolling Stock TSI.

The keeper is obliged to ensure that these data are available and the processes behind have been conducted.

— Design data,

which shall include all constitutive (physical) elements of the rolling stock, including characteristics related
to the environment, and all information that is expected to remain valid throughout the life of the rolling
stock — this part may contain a history of major modifications, major maintenance, overhaul, etc.

L 13/40

EN

Official Journal of the European Union

18.1.2006

4.2.11.4. The R oll i n g S toc k O pe r a ti on a l Da ta

Beside the reference data for rolling stock, the data representing the actual status of the rolling stock is the most
important data for operational purposes.

This data shall include temporary data, such as restrictions, current and projected maintenance actions, kilo-
meters and fault counters, etc.; and all data that could be considered as ‘status’ (temporary speed restrictions,
brake isolated, needs for repair and fault description, etc.,).

For use of the operational rolling stock data, three different entities must be considered taking into account the
different parties responsible for rolling stock during transport operation:

— Railway Undertaking as Duty holder during its transport control,

— Keeper of rolling stock, and

— User (Hirer) of rolling stock.

For all three different parties the operational rolling stock data must be accessible by the authorised user, down
to his predefined authorised level, using the single key given by the wagon ID (wagon number).

The operational rolling stock data is a part of the European-wide Wagon and Intermodal Unit Operational Data-
base as described in Chapter 4.2.12.2 Other databases .

4.2.12. Various reference files and databases

4.2.12.1. R e fe re nc e fi le s

For the operation of freight trains on the European network the following reference files must be available and
accessible to all service providers (IMs, RUs, logistic providers and fleet managers). The data must represent the
actual status at all times.

L o c a l l y s t o r e d a n d a d m i n i s t r a t e d :

— reference file of the emergency services, correlated to type of hazardous goods.

C e n t r a l l y s t o r e d a n d a d m i n i s t r a t e d :

— reference file of the coding for all IMs, RUs, service provider companies,

— reference file of the coding for transport customers,

— reference file of the coding of locations (primary, subsidiary and zone-track-spot),

— reference file of the coding for customer locations,

— reference file of all existing train control systems,

— reference file of hazardous goods, UN and RID numbers,

— reference file of all different locomotive types,

— reference file of all CN and HS codes for goods,

— reference file of all European maintenance workshops,

— reference file of all European audit bodies,

— reference file of all European licensed operators including respective list of national safety certificates

granted.

The coding of IMs, RUs, transport organisations and companies and transport customers as well as of locations
(primary, subsidiary, etc.) including customer locations are pending.

18.1.2006

EN

Official Journal of the European Union

L 13/41

4.2.12.2. Oth er da ta ba se s

To allow for the tracking of train and wagon movements, the following databases, updated at each relevant
event in real time, must be installed. Authorised entities such as keepers and fleet managers must have access to
the data relevant to fulfil their functions, according to contractual conditions.

— Wagon and Intermodal Unit Operational Database,

— Trip plan for wagon/intermodal unit.

These databases must be accessible via the common interface (4.2.14.1: General architecture and 4.2.14.7:
Common interface).

W a g o n a n d I n t e r m o d a l U n i t O p e r a t i o n a l D a t a b a s e

The communication between the Lead RU and RUs in the cooperation mode is based on wagon and/or inter-
modal unit numbers. Therefore an RU, which communicates with the IMs at train level, must break down this
information into wagon and intermodal unit related one. This wagon and intermodal unit related information
must be stored in the Wagon and Intermodal Unit Operational Database. The information on train movement
leads to new entries/updates in the Wagon and Intermodal Unit Operational Database for customer information.
The movement part for a wagon or intermodal unit in the database is set up at the latest when receiving the
release time for the wagons or intermodal unit from the customer. This release time is the first movement entry
for a wagon into the Wagon and Intermodal Unit Operational Database related to an actual transport journey.
The messages for the wagon movement are defined in the Chapters 4.2.8 (Wagon movement) and 4.2.9 (Inter-
change reporting). This database must be accessible via the common interface (4.2.14.1: General architecture
and 4.2.14.7: Common interface).

The Wagon and Intermodal Unit Operational Database is the most important one for the tracking of wagons
and therefore for the communication between the RUs involved and the Lead RU. This database shows the
movement of a wagon and of an intermodal unit from departure through to final delivery at customer sidings
with ETIs and actual times at different locations until the final delivery time ETA. The database also shows the
different status of the rolling stock such as:

— Status: loading of the rolling stock

This status is required for the information exchange between the RU and the IMs and to other railway undertak-
ings involved in the transport journey.

— Status: loaded wagon on journey

This status is required for the information exchange between the IM and the RU, with other infrastructure
managers and with other railway undertakings involved in the transport journey.

— Status: empty wagon on journey

This status is required for the information exchange between the IM and the RU, with other infrastructure
managers and railway undertakings involved in the transport journey.

— Status: unloading of rolling stock

This status is required for the information exchange between the RU at destination and the Lead RU for the
transport.

— Status: empty wagon under fleet management control

This status is required to get the information about availability of a vehicle of defined characteristics.

W a g o n T r i p P l a n D a t a b a s e s

Trains normally carry wagons from various customers. For each wagon the Lead RU (RU acting as service inte-
grator) must establish and update a trip plan which corresponds to the train path at train level. New train paths
for a train — e.g. in case of service interruptions — lead to revised trip plans for the wagons concerned. The
creation time for the trip plan is the receipt of the consignment note from the customer.

L 13/42

EN

Official Journal of the European Union

18.1.2006

The Wagon Trip Plans must be stored by each LRU in a database. These databases must be accessible via the
common interface (4.2.14.1: General architecture and 4.2.14.7: Common interface).

Remark:

In addition to the mandatory databases mentioned above, at each IM side a train database may be installed.

This infrastructure manager train database corresponds to the movement part of the Wagon and Intermodal
Unit Operational Database. The main data entries are the train related data of the train composition message
from the RU. All train events result in an update of this train related database. An alternative storage possibility
for these data is the path database (Chapter 4.2.2: Path request). These databases must be accessible via the
common interface (4.2.14.1: General architecture and 4.2.14.7: Common interface).

4.2.12.3. A ddi ti on a l r eq u i re me nts on the da ta ba ses

Under the following points are listed additional requirements which must be supported by the various data-
bases.

These are:

1. Authentication

A database must support the authentication of users of the systems before they can gain access to the data-
base.

2. Security

A database must support the security aspects in the meaning of controlling access to the database. The
possible encryption of the database contents itself is not required.

3. Consistency

A database selected shall support the ACID principle (Atomicity, Consistency, Isolation, Durability).

4. Access control

A database must allow access to the data to users or systems that have been granted permission. The access
control shall be supported down to a single attribute of a data record. The database shall support configur-
able, role based access control for insertion, update or deletion of data records.

5. Tracing

A database must support logging all actions applied to the database to allow for tracing the detail of the
data entry (Who, What, When did the contents change).

6. Lock strategy

A database must implement a locking strategy which allows access to the data even when other users are
currently editing records.

7. Multiple access

A database must support that data can be accessed simultaneously by several users and systems.

8. Reliability

The reliability of a database must support the required availability.

9. Availability

A database must have an availability on demand of at least 99,9 %.

10. Maintainability

A maintainability of the database must support the required availability.

18.1.2006

EN

Official Journal of the European Union

L 13/43

11. Safety

Databases themselves are not safety related. Hence safety aspects are not relevant. This is not to be confused
with the fact that the data — e.g. wrong or not actual data — may have impact on the safety operation of
a train.

12. Compatibility

A database must support a data manipulation language that is widely accepted, such as SQL or XQL.

13. Import facility

A database shall provide a facility that allows the import of formatted data that can be used to fill the data-
base instead of manual input.

14. Export facility

A database shall provide a facility that allows to export the contents of the complete database or its part as
formatted data.

15. Mandatory fields

A database must support mandatory fields that are required to be filled before the relevant record is
accepted as input to the database.

16. Plausibility checks

A database must support configurable plausibility checks before accepting the insertion, update or deletion
of data records.

17. Response times

A database must have response times that allow users to insert, update or delete data records in a timely
manner.

18. Performance aspects

A database shall support the queries necessary to allow the effective run of about 60 000 train runs per 24
hours. About 50 % of these train runs are deemed to take place within two hours.

The number and kind of queries or updates per train are dependent on the overall process for planning and
running a train.

19. Capacity aspects

A database shall support the storage of the relevant data for all freight wagons respectively the network. It
shall be possible to extend the capacity by simple means (i.e. by adding more storage capacity and compu-
ters). The extension of the capacity shall not require replacement of the subsystem.

20. Historical data

A database shall support the management of historical data in the meaning of making of data available that
has been already transferred into an archive.

21. Back-up strategy

A back-up strategy shall be in place to ensure that the complete database contents for up to a 24-hour
period can be recovered.

22. Commercial aspects

A database system used shall be available commercially-off-the-shelf (COTS-product) or be available in the
public domain (Open Source).

Remarks:

The above requirements must be handled by a standard Database Management System (DBMS).

L 13/44

EN

Official Journal of the European Union

18.1.2006

The usage of the various databases is embedded into various work flows described here before. The general
workflow is a request/response mechanism, where an interested party requests information from the database
through the common interface (4.2.14.1: General architecture and 4.2.14.7: Common interface). The DBMS
responds to this request either by providing the requested data or by responding that no data can be made avail-
able (no such data exists or access is refused due to access control).

4.2.13. Electronic transmission of documents

The description in Chapter 4.2.14 (Networking and communication) presents the communication network to be
used for data exchange. This network and the described security handling allow any type of network transmis-
sion, such as e-mail, file transfer (ftp, http), etc. The type to choose can then be decided upon by the parties
for
involved in the information exchange, which means, that
example, via ftp is given.

the electronic transmission of documents,

4.2.14. Networking and communication

4.2.14.1. Ge ne ra l a r c hi te c tu re

This subsystem will see, over time, the growth and interaction of a large and complex telematic rail interoper-
ability community with hundreds of participating actors (RUs, IMs, etc.), which will compete and/or cooperate
in serving the market's needs.

The network and communication infrastructure supporting such rail interoperability community will be based
on a common ‘Information Exchange Architecture’, known and adopted by all participating actors.

The proposed ‘Information Exchange Architecture’:

— is designed to reconcile heterogeneous information models by semantically transforming the data that is
exchanged between the systems and by reconciling the business process and application-level protocol differ-
ences,

— has minimum impact on the existing IT architectures implemented by every actor,

— safeguards IT investments made already.

The Information Exchange Architecture favours a mostly peer-to-peer type of interaction between all actors,
while it guarantees the overall integrity and consistency of the rail interoperability community by providing a
set of centralised services.

A peer-to-peer interaction model allows the best cost distribution between the different actors, based on actual
usage and it will present, in general, lesser scalability problems. A pictorial representation on the general archi-
tecture is given in Annex A, Index 5, Chapter 1.5.

4.2.14.2. Ne tw or k

Networking in this case means the method and philosophy of communication and does not mean the physical
network.

Rail interoperability is based on a common ‘Information Exchange Architecture’, known and adopted by all
participants, thus encouraging and lowering barriers for new entrants, especially customers.

The security issue will therefore be addressed not by the network (VPN, tunnelling, etc.), but by exchanging and
managing inherently secure messages. A VPN network is therefore not required (the administration of a large
VPN network will be complex and costly to manage), thus avoiding problems with responsibilities and owner-
ship allocation. Tunnelling is not considered as a necessary means for achieving the appropriate security level.

In any case if some actors already have or want to implement various degrees of security on selected partitions
of the network, they can do so.

Over the public Internet network it is possible to implement a hybrid peer-to-peer model with a ‘central reposi-
tory’ and a ‘common interface’ at each actors' node.

18.1.2006

EN

Official Journal of the European Union

L 13/45

The central repository is approached first to obtain meta-information, such as the identity of the peer (actor) on
which some information is stored, or to verify security credentials. Afterwards, a peer-to-peer communication is
performed between involved actors.

4.2.14.3. Pr otoc ols

Only protocols belonging to the full Internet Protocol suite must be used.

4.2.14.4. Se c ur i ty

To achieve a high level of security, all messages must be self-contained, which means that the information in
the message is secured and the receiver can verify the authenticity of the message. This may be solved by using
an encryption and signing scheme similar to email encryption. This makes it possible to use any type of
network transmission, like e-mail, file transfer (ftp, http), etc. The actual type to choose can then be decided
upon by the parties involved in the information exchange.

4.2.14.5. En cr y pti on

Either asymmetric encryption or a hybrid solution based on symmetric encryption with public key protection
must be used, due to the fact that sharing a common secret key among many actors will fail at some point. A
higher level of security is easier to achieve if every actor takes responsibility for its own pair of keys, even
though a high level of integrity of the central repository (the key server) is required.

4.2.14.6. Ce ntr a l re posi tory

The central repository must be able to handle:

— metadata — structured data describing the content of messages,

— Public Key Infrastructure (PKI),

— Certification Authority (CA),

— directory (phonebook) — it contains all needed information about the participating actors for exchanging

messages.

The management of the central repository should be under the responsibility of a non-commercial co-European
organisation.

L 13/46

EN

Official Journal of the European Union

18.1.2006

4.2.14.7. Common i n te r fa ce

The common interface is mandatory for each actor in order to join the rail interoperability community.

The common interface has to be able to handle:

— message formatting of outgoing messages according to the metadata,

— signing and encryption of outgoing messages,

— addressing of the outgoing messages,

— authenticity verification of the incoming messages,

— decryption of incoming messages,

— conformity checks of incoming messages according to metadata,

— handling the single common access to various databases.

Each instance of the common interface will have access to all the data required according the TSI within each
RU, IM, etc, whether the relevant databases are central or individual (see also Annex A, Index 5, Chapter 1.6).

Based on the results of authenticity verification of incoming messages, a minimum level of message acknowl-
edgement can be implemented:

(i) positive send ACK;

(ii) negative send NACK.

The common interface uses the information in the central repository in order to manage the above tasks.

An actor may implement a local ‘mirror’ of the central repository to shorten response times.

4.3. Functional and technical specifications of the interfaces

In light of the essential requirements in Chapter 3, the functional and technical specifications of the interfaces
are as follows:

4.3.1. Interfaces with the TSI infrastructure

The infrastructure subsystem includes traffic management, tracking, and navigation systems: technical installa-
tions for data processing and telecommunications intended for long-distance passenger services and freight
services on the network in order to guarantee the safe and harmonious operation of the network and efficient
traffic management.

The subsystem Telematic Applications for Freight uses the data required for operational purposes as given by
the path contract, eventually updated in the restriction notice database, as provided by the IM. Thus no direct
interface exists between this TSI and the TSI for infrastructure.

4.3.2. Interfaces with the TSI control/command and signalling

The only connection to control command and signalling is via the

— path contract, where within the line segment description the relevant information about usable command

control and signalling equipment is given, and

— various Rolling Stock Reference Databases, where the command control and signalling equipment of the

rolling stock must be stored.

4.3.3. Interfaces with the rolling stock subsystem

The subsystem Telematic Applications for Freight identifies the technical and operational data, which must be
available for the rolling stock.

18.1.2006

EN

Official Journal of the European Union

L 13/47

The rolling stock TSI specifies the characteristics of a wagon. If the characteristics changes for a wagon, this
must be updated in the Rolling Stock Reference Databases within the normal maintenance process for the data-
base. Thus no direct interface exists between this TSI and the TSI for rolling stock.

4.3.4. Interfaces with the TSI operation and traffic management

The subsystem Operation and Traffic Management specifies the procedures and related equipment enabling a
coherent operation of the different structural subsystems, both during normal and degraded operation, including
in particular train driving, traffic planning and management.

The subsystem Telematic Applications for Freight mainly specifies applications for freight services including
real-time monitoring of freight and trains and the management of connections with other modes of transport.

In order to ensure consistency between both TSIs, the following procedure applies.

When the specifications of the TSI Operation and Traffic Management related to the requirements of this TSI
will be written and/or will become subject to amendments, then the body in charge of this TSI must be
consulted.

In the case that the specifications of this TSI related to operational requirements specified in the TSI Operation
and Traffic Management should be subject to any amendment, the body in charge of the TSI Operation and
Traffic Management must be consulted.

4.4. Operating rules

In light of the essential requirements in Chapter 3, the operating rules specific to the subsystem concerned by
this TSI are as follows:

4.4.1. Data quality

For data quality assurance purposes, the originator of any TSI message will be responsible for the correctness of
the data content of the message at the time when the message is sent. Where the source data for data quality
assurance purposes is available from the databases provided as part of the TSI, the data contained within those
databases must be used for data quality assurance.

Where the source data for data quality assurance purposes is not provided from the databases provided as part
of this TSI, the originator of the message must make the data quality assurance check from their own resources.

Data quality assurance will
described above plus, where applicable,
messages.

include comparison with data from databases provided as part of this TSI as
logic checks to assure the timeliness and continuity of data and

Data are of high quality if they are fit for their intended uses, which means they:

— are error-free: accessible, accurate, timely, complete, consistent with other sources, etc., and

— possess desired features: relevant, comprehensive, proper level of detail, easy-to-read, easy-to-interpret, etc.

The data quality is mainly characterised by:

— accuracy,

— completeness,

— consistency,

— timeliness.

A cc u r a c y :

The information (data) required needs to be captured as economically as possible. This is only feasible if the
primary data, which plays a decisive role in the forwarding of a consignment, a wagon or a container, is only
recorded, if possible, on one single occasion for the whole transport. Therefore the primary data should be intro-
duced into the system as close as possible to its source, e.g. on the basis of the consignment note drawn up
when a wagon or a consignment is tendered for carriage, so that it can be fully integrated into any later proces-
sing operation.

L 13/48

EN

Official Journal of the European Union

18.1.2006

Comple te ne ss:

Before sending out messages the completeness and syntax must be checked using the metadata. This also avoids
unnecessary information traffic on the network.

All incoming messages must also be checked for completeness using the metadata.

Consiste ncy:

Business rules must be implemented in order to guarantee consistency. Double entry should be avoided and the
owner of the data should be clearly identified.

The type of implementation of these business rules depends on the complexity of the rule. For simple rules,
database constraints and triggers are sufficient. In case of more complex rules which require data from various
tables, validation procedures must be implemented which check the consistency of the data version before inter-
face data are generated and the new data version becomes operational. It must be guaranteed that transferred
data are validated against the defined business rules.

T i meli ne ss:

The provision of information right in time is an important point. As far as the triggering for data storage or for
message sending is event driven directly from the IT system the timeliness is not a problem if the system is
designed in well manner according the needs of the business processes. But in most of the cases the initiation of
sending a message is done by an operator or at least is based on additional input from an operator (for example
the sending of the train composition or the actualising of train or wagon related data). To fulfil the timeliness
requirements the updating of the data must be done as soon as possible also to guarantee, that the messages
will have the actual data content when sending out automatically by the system.

In general the following requirements must be fulfilled:

The response time for enquiries must be less then 5 minutes. All data updates and exchanges must be done as soon as
possible. The system reaction and transmission time for the update should be below 1 minute.

Da ta qu a lity me tr i c s

For the completeness (percent of data fields having values entered into them) of mandatory data and for the
consistency of data (percent of matching values across tables/files/records) a percentage of 100 % must be
reached.

For the timeliness of data (percent of data available within a specified threshold time frame) a percentage of
98 % must be reached. As far as threshold values are not defined in this TSI, these values must be specified in
the contracts between the involved parties.

The required accuracy (percent of stored values that are correct when compared to the actual value) must be
above 90 %. The exact value and the criteria must been set out in the contracts between the involved parties.

4.4.2. Operating the central repository

The functions of the central repository are defined in Chapter 4.2.14.6 (Central repository). For data quality
assurance purposes, the entity operating the central repository should be responsible for the updating and the
quality of the metadata and the directory, and also for the administration of the access control (Public keys).
Regarding the quality of the metadata a percentage of 100 % must be reached for completeness, consistency,
timeliness and accuracy.

4.5. Maintenance rules

In light of the essential requirements in Chapter 3, the maintenance rules specific to the subsystem concerned
by this TSI are as follows:

18.1.2006

EN

Official Journal of the European Union

L 13/49

The quality of the transport service must be guaranteed even if the data processing equipment were to break
down in full or in part. It is therefore, advisable to install duplex systems or computers with a particularly high
degree of reliability, and for which the uninterrupted operation during maintenance is ensured.

The maintenance aspects regarding the various databases are mentioned in Chapter 4.2.12.3 (Additional require-
ments on the databases), points 10 and 21.

4.6. Professional qualifications

The professional qualifications of staff required for the operation and maintenance of the subsystem and for
implementing the TSI are as follows:

The implementation of this TSI does not require a complete new system in hardware and software with new
staff. The realisation of the requirements of the TSI leads only to changes, upgrades or functional enlargements
of the operation as it is already done by the existing staff. Therefore, there are no additional requirements to the
existing national and European rules on professional qualifications.

If necessary, an add-on training of staff should not just consist of showing them how to operate equipment. The
member of staff must know and understand his specific role to be played in the overall transportation process.
Staff must in particular be aware of the requirement to maintain a high working performance level, since this is
a decisive factor for the reliability of the information to be processed at a subsequent stage.

The professional qualifications needed for the composition and operation of trains are defined in the TSI Opera-
tion and Traffic Management.

4.7. Health and safety conditions

The health and safety conditions of staff required for the operation and maintenance of the subsystem concerned
(or the technical scope as defined in paragraph 1.1) and for the implementation of the TSI are as follows:

There are no additional requirements to existing national and European rules on health and safety.

4.8. Infrastructure and rolling stock registers

In accordance with Article 24(1) of Directive 2001/16/EC, ‘the Member States shall ensure that registers of infra-
structure and of rolling stock are published and updated annually. Those registers shall indicate the main feature
of each subsystem or part subsystem involved and their correlation with the features laid down by the applicable
TSIs. To that end, each TSI shall indicate precisely which information must be included in the registers of infra-
structure and of rolling stock.’

Due to the annual update and publication of these registers they are not utilisable for the subsystem Telematic
Applications for Freight. Therefore this TSI has nothing to indicate in these registers.

5. INTEROPERABILITY CONSTITUENTS

5.1. Definition

According to Article 2(d) of Directive 2001/16/EC, interoperability constituents are ‘any elementary component,
group of components, subassembly or complete assembly of equipment incorporated or intended to be incorpo-
rated into a subsystem upon which the interoperability of the trans-European conventional rail system depends
directly or indirectly. The concept of a constituent covers both tangible objects and intangible objects such as
software’.

L 13/50

EN

Official Journal of the European Union

18.1.2006

5.2. List of constituents

The interoperability constituents are covered by the relevant provisions of Directive 2001/16/EC.

There are no interoperability constituents determined as far as the subsystem Telematic Applications for Freight
is concerned.

For the fulfilment of the requirements of this TSI only standard IT equipment is needed, without any specific
aspects for interoperability in the railway environment. This is valid for hardware components and for the stand-
ard software used like operating system and databases. The application software is individual on each user's side
and can be adapted and improved according the individual actual functionality and needs. The proposed ‘appli-
cation integration architecture’ assumes that applications might not have the same internal information model.
Application integration is defined as the process of making independently designed application systems work
together.

5.3.

‘Constituents’ performances and specifications

See Chapter 5.2, not relevant for the TSI telematic applications for freight.

6. ASSESSMENT OF CONFORMITY AND/OR SUITABILITY FOR USE OF THE CONSTITUENTS AND VERIFICATION

OF THE SUBSYSTEM

6.1. Interoperability constituents

6.1.1. Assessment procedures

The assessment procedure for conformity or suitability for use of interoperability constituents must be based on
European specifications or specifications approved in accordance with Directive 2001/16/EC.

In the case of suitability for use, these specifications will indicate all the parameters to be measured, monitored
or observed, and will describe the related testing methods and measuring procedures, whether in a test-bench
simulation or tests in a real railway environment.

Procedures for assessing conformity and/or suitability for use:

List of specifications, description of the testing methods:

Not relevant for the TSI telematic applications for freight

6.1.2. Module

At the request of the manufacturer or his representative established in the Community, the procedure is carried
out by a notified body in accordance with the provisions of the pertinent modules of Council Decision
93/465/EEC as set out, amended and supplemented in the Annex to this TSI.

The modules should be combined and used selectively according to the particular constituent.

Not relevant for the TSI telematic applications for freight.

6.2. Subsystem Telematic Applications for Freight

At the request of the awarding authority or its representative established in the Community, the notified body
carries out EC verification in accordance with Annex VI to Directive 2001/16/EC.

According to Annex II to Directive 2001/16/EC, the subsystems are broken down into structural and opera-
tional areas.

The conformity assessment is obligatory for TSIs in the structural area. The subsystem Telematic Applications
for Freight belongs to the operational area and this TSI does not determine any modules for conformity assess-
ment.

However the central repository and a common interface at each actor's node are the backbone of the application
integration. The exchange information model is held in the centralised application integration repository, which
holds the interface metadata in one physical location. The metadata contains information about the communica-
tion content (what is in the data being sent), the touch point identities of the senders and receivers, and the
interaction process mechanics application-level business protocols.

18.1.2006

EN

Official Journal of the European Union

L 13/51

The following points are highlighted:

— The central repository contains the directory (phonebook) of all participating actors for the exchange of
messages. This directory must represent the actual status at all times. Wrong entries become obvious imme-
diately. No assessment procedure needed.

— The central repository also contains the certification authority (Open CA PKI). This is mainly an administra-
tion act, which is physically implemented. Wrong entries become obvious immediately. No assessment
procedure needed.

— The central repository contains the message metadata (according to Annex A, Index 1) as the basis for
message exchange in a heterogeneous information environment. The metadata must be administrated and
updated in the central repository. Any incompatibility in the message structure or content of the messages
for sending or receiving data will be recognised immediately and the transfer will be refused. No assessment
procedure needed.

— The common interface at each actor's node contains mainly the local ‘mirror’ of the central repository for
shortening the response time and reducing the load on the repository. It must be ensured, that the data
versions in the central repository and in the common interface are always the same. Therefore the data
update must be done on the central level and new versions must be downloaded from there. No assessment
procedure needed.

7. IMPLEMENTATION

7.1. Modalities of application of this TSI

7.1.1. Introduction

This TSI is oriented to provide information support to the rail freight business process that can lead to a major
enhancement of the quality of transportation services. As such its application is independent from the notions
of new/upgrade or legacy infrastructure or rolling stock assets as it is usual in other TSI called for by Directive
2001/16/EC.

Due to its pervasive nature the impact of this TSI will be profound on the business and operational processes of
the whole of the European rail industry. Moreover, the continuous growth of international freight transport
demands a European-wide information management perspective. These facts compound to call for the set-up of
a coherent trans-European implementation plan for this TSI. This plan should provide both a vision of what is
to be achieved when implementing the TSI and the way and timing to migrate from the present framework of
fragmented information systems towards a comprehensive European-wide information highway that can
provide value-added to all rail transport stakeholders — infrastructure managers, railway undertakings, freight
forwarders and ultimately the client alike.

Set against this background the concept of a Strategic European Deployment Plan (SEDP) is mandated. The
SEDP defines the target system that is to be achieved in order to implement this TSI together with its underpin-
ning roll-out plan as outlined in the following paragraph.

7.1.2. Strategic European Deployment Plan (SEDP)

7.1.2.1. Ob j ec ti v es of the S EDP

The purpose of the Strategic European Deployment Plan (SEDP) is threefold:

1. to provide a vision for the implementation of the TAF TSI within the European rail industry;

2. to qualify such a vision from a technical and economic feasibility perspective;

3. to establish a roadmap of the activities deemed necessary in order to realise such a vision.

In addition to provide a roadmap for the implementation of the TAF TSI ensuring visibility of the whole imple-
mentation process, the SEDP should bestow appropriate yardsticks for the monitoring of its progress by the
different stakeholders — namely infrastructure managers, railway undertakings, freight forwarders and ultimately
the client — in a way that can guarantee the defence of their best interests. This regards notably the required
investments to be mobilised by the infrastructure managers and railway undertakings in the potential upgrading
and integration of their legacy IT systems and the capability of the TAF TSI-based systems in effectively
responding to the ever evolving needs of information from freight forwarders and clients alike.

L 13/52

EN

Official Journal of the European Union

18.1.2006

Set against this background, the SEDP should ultimately constitute an instrument enabling to focus the whole of
the European railway industry on a pan-European information system development target, whilst allowing for
the promotion of synergies, avoidance of fragmentation and the concentration of limited resources on those
priority issues better responding to the overriding transportation service quality goals.

7.1.2.2. Th e S E DP r e qu i re me nts

The elaboration of such a plan will require a systematic analysis of the relevant technical, operational, economic
and institutional issues that underpin the implementation process of the TAF TSI. This includes in particular:

1. the inventory of the relevant legacy IT applications that could constitute the foundation on which to build a

pan-European system capable of delivering the TAF TSI requirements (hereafter called the TAF system);

2. the definition of the functional and associated data and performance requirements necessary to deliver the

TAF TSI;

3. the outline of the TAF system architecture. This shall be based on the analysis of the system configurations
capable of potentially integrating the legacy IT facilities while delivering the required functionality and perfor-
mance — e.g. centralised or distributed client-server architectures, agent-based architectures;

4. the establishment of the technical and interface requirements for the TAF system and its potential sub/client

systems;

5. the elaboration of an overall TAF system development plan from concept-to-delivery. This should provide
guidelines on the process and the planning for the potential integration of legacy facilities as well as a risk
assessment of the crucial phases of such a plan. Moreover, it should account for the ongoing and planned
evolution of legacy facilities;

6. the identification of the appropriate governance structures underpinning the development of the TAF system

as well as its operation throughout its lifetime;

7. an assessment of the total life cycle costs (LCC) associated with the roll-out and operation of the TAF system

together with a subsequent investment plan.

Rather than following a sequential path this analysis should evolve through an iterative basis aimed at identi-
fying the optimum system deployment strategy. Such study cycle should conduce ultimately to the following
specific outcome:

— a full set of functional, performance, system and technical specifications for the procurement of the TAF

system,

— a rollout programme from concept-to-delivery. This shall include the detailed planning of all those project

phases and major individual activities that concur to the achievement of the end goals,

— a definition of the governance structure, methods and procedures ( (1)) underpinning system development,

validation and operation,

— an investment plan and a subsequent financial engineering approach enabling its realisation.

7.1.3. Modalities for implementation

The modalities for application of this TSI are subject to the requirements of the Strategic European Deployment
Plan (SEDP) as outlined previously.

For the purpose of the elaboration of the SEDP the following requirements do apply:

— Railway Undertakings and Infrastructure Managers shall contribute by providing functional and technical

information about the existing individual telematics applications for freight (2);

(1) E.g. quality assurance standards, system development methodology, testing methodology, documentation planning.
(2) Existing telematic applications for freight are telematic applications for freight that are already in service before this TSI enters into

force.

18.1.2006

EN

Official Journal of the European Union

L 13/53

— The representative bodies from the railway sector acting on a European level as defined in Article 3(2) of
Regulation (EC) No 881/2004 shall establish a Strategic European Deployment Plan as outlined in the
previous paragraph. They shall forward this strategic plan to the Member States and the Commission not
later than one year after the date of publication of this Regulation. If after this period of time no significant
progress is observed the task will be embraced by the European Commission to subsequently propose draft
legislation for the implementation of this TSI.

— Once the strategic plan is completed, all activities related to the implementation of the subsystem Telematic
Applications for Freight have to be justified against this deployment plan. Any proposed non-adherence by a
RU or IM should be justified in the implementation dossier submitted to the Member State, to the European
Railway Agency and to the EC.

7.2. Migration strategy

Migration strategies have to be devised in order to cater for the transition period between the current framework
of differentiated information systems and the fulfilment of this TSI as commanded by the SEDP.

For this purpose the information handling concepts embodied in this TSI where developed in order to facilitate
such a migration. They do allow for an incremental build-up of the target TAF TSI pan-European system,
notably through facilities such as peer-to-peer communication based e.g. on the concept of aggregate data repo-
sitories (namely including message metadata, data directory and certification authority).

An illustrative example how such information exchange between a RU and IM could work in practice is given
below. The example shows only the logical inter-system communication dependencies structured in stepwise
manner without accounting for any individual migration needs that might be required by the individual
systems. These latter needs should be duly considered when drawing up the SEDP.

Step 1: The general architecture, as described in Chapter 4.2.14.1 (General architecture), embodies the concept
of a ‘central repository’ operated by a neutral and independent entity. At the site of each participant in the
communication network, an interface layer, which may include a message broker, is specified for interoper-
ability, which can be built centrally or individually. These parts are in respect of ‘networking and communica-
tion’, the only operational aspects required for interoperability. They are also the basic preconditions for the
European-wide data exchange. Therefore they must be realised and installed before any other function can come
into operation.

After this step already the electronic transmission of documents (Chapter 4.2.13:) may be realised independent
from the logical sequence of the other steps.

Available features after this step for

IM

RU

The basis for the information exchange is given.

Advantage:

Electronic transmission of documents in the final environment is possible.

Tests of the various further steps can be made in real environment.

Step 2: At the same time or shortly after step 1, the Rolling Stock Reference Databases and the Wagon and
Intermodal Unit Operational Database (Chapter 4.2.11.3: The Rolling Stock Reference Databases and Chapter
4.2.12.2: Other databases) must be available. If not all data are already in the databases, it must be at least
possible to put manually into the Wagon and Intermodal Unit Operational Database — for each wagon in a
running train — the data needed for rail transport as listed in Annex A, Index 2).

Available features after this step for

IM

RU

The basic information in the Wagon and Intermodal Unit Operational Database and the Rolling Stock Reference
Databases are accessible. A manual update of the relevant data is possible.

Advantage:

The IT support for a path request and for the train composition is given.

An easy access to the rolling stock data for third parties e.g. fleet managers can be realised.

L 13/54

EN

Official Journal of the European Union

18.1.2006

Step 3: For outside access to the various databases the common interface must be realised and implemented in
parallel or shortly after step 2.

Available features after this step for

IM

RU

A database for the storage of path/train information is
prepared.

The data input can start manually. The on-line connec-
tion to the existing IM systems for the automatic input
and update is available.

Advantage:

Data of incoming messages can be stored as for the
final version.

The database(s) for the movement data of wagons/
intermodal units and for the load (weight, dangerous
goods) is prepared, together with the reference files
needed.

(wagon order) and/or of

From now on the relevant data from the delivered
the
consignment notes
existing train composition can be filled in manually or
already automatically via RU internal connection to
the existing systems for recording the consignment
notes and for recording the train composition.

The check of the wagon data with the Rolling Stock
Reference Databases is possible as well as the assess-
ment of the train data with the infrastructure data.

Advantage:

Support for creating the train composition.

Data of incoming messages can be stored as for the
final version.

For the next steps it is important to mention, that the proposed architecture allows for a smooth coming into
operation of the various functions to fulfil the requirement of the subsystem Telematic Applications for Freight.
Based on the central repository (message metadata, directory and certification authority), it is possible to enable
the data exchange between two partners individually depending on message type.

Step 4: The Path Request messages can be implemented independent from the next steps, but for step 6 it is
necessary that the path is already named by a path number.

Available features after this step for

IM

RU

Automatic data input into the database for the storage
of path/train information. Telematic supported path
definition in combination with the Infrastructure
Restriction Notice Databases.

Advantage:

Faster
reactions on path requests, better demand
oriented path usage, higher reliability of the path char-
acteristic data (current status in the Infrastructure
Restriction Notice Databases), improvement in the use
of the infrastructure.

Path request on short notice is possible.

Advantage:

Better demand oriented path request is possible. Faster
reaction by IM on path requests. A higher reliability of
the path characteristic data. Speeds up wagon turn
around times.

Step 5: The wagon orders data deliver basic information for the composition of a train, therefore these messages
should go into operation before step 6.

Available features after this step for

IM

RU

No additional features.

Automatic take over of the consignment note data
into the data storage of step 3. Automatic generation
and sending of wagon orders to cooperating RUs.

Advantage:

Faster distribution of
handling time at interchange points.

the wagon orders, shortened

Support
contracts.

for

applying international purchase/sales

18.1.2006

EN

Official Journal of the European Union

L 13/55

Step 6: The coming into operation of train preparation messages is the next step, whereby the sending of the
train composition message is the most important one and should be realised first.

Available features after this step for

IM

RU

Receiving train composition in advance. Higher relia-
bility of the data. Clear time stamp of the start time
for the use of the path. Automatic update of the data-
base for the storage of path/train information.

Advantage:

Optimising of the path usage. Clear responsibility at
start time.

Sending train composition mostly automatically gener-
ated, high reliability of the data, automatic update into
the data storage of step 3.

Advantage:

Clear responsibility at start time for the IM service,
reliable start time for the wagons/shipments.

Support for minimising expenses and costs by reduced
data capture at borders.

Support for speeding up shipment times by guaranteed
take-over of trains by RU and IM.

Support
wagons.

for minimising risks during takeover of

Step 7: At latest before step 8, the wagon movement functions ‘Wagon Release and Departure Notice, Wagon
Yard Arrival, Wagon Yard Departure, Wagon Arrival Notice and Wagon Delivery Notice/Confirmation’ together
with the trip planning functionality should be realised at the RU level.

Available features after this step for

IM

RU

No additional features.

IT supported trip planning at wagon and intermodal
unit level is possible.

The system is prepared to calculate send and receive
wagon and
related movement
messages.

intermodal

unit

Advantage:

First step for the tracking and tracing of wagons and
shipments at an international level.

Step 8: For the next step the Train Running and Train Running Forecast messages should be realised. With the
Train Running Forecast message, the Train Estimated Time of Arrival (TETA respectively ETH) can be sent,
which is the basis for the calculation of the wagon/shipment related ETIs and the ETA. This step also contains
the realisation of the enquiry/response for train running and train forecast.

Available features after this step for

IM

RU

Train running and train running forecast in real time
sent to neighbour IMs and to the RUs.

Location and train estimated time as a basis for
wagon/shipment related ETI/ETA calculation available.

Advantage:

Advantage:

Enhanced and more reliable planning opportunities
supporting efficient path usage.

Tool to meet customer's wish to be informed if trans-
port problems occur.

Reduces border stops, supports demand oriented path
usage.

Together with the finalising of step 4 support for
minimising expenses and costs by demand oriented
path usage.

Enhanced and more reliable planning opportunities.

Support for speeding up shipment times by reducing
border stops.

Support
trains.

for minimising risks during take over of

L 13/56

EN

Official Journal of the European Union

18.1.2006

Step 9: The interchange reporting (Chapter 4.2.9:Interchange reporting) and the functionality of Chapter 4.2.7
(Shipment ETI/ETA) should be implemented at the same time or shortly after step 8. This is in particular rele-
vant for RUs.

Available features after this step for

IM

RU

Knowing the location of a wagon within the IM's
infrastructure, and which RU is responsible, even if
the wagon is not in a train.

ETI and ETA calculation based on TETA values, auto-
matic update of the movement data in the Wagon and
Intermodal Unit Operational Database.

Advantage:

International empty wagon management fully realised.

Knowing wagon location and responsible entity in a
yard.

International trip planning completed.

Advantage:

Shipment
level.

tracking and tracing on an international

Speeding up wagon turn around times.

Support for international empty wagon management.

Support
services offered.

for consignments abroad and booking of

Support
transports.

for quality improvement of

international

Support for international trip planning.

Step 10: The realisation of the ‘service disruption information’ functionality is part of step 10, together with the
realisation of the enquiry/response about train delay, train identifier and train at reporting location. Based on
the disruption information, the Wagon Exception message at RU level (Chapter 4.2.8.6: Wagon Exception
message and Chapter 4.2.8.7: Wagon Exception message New ETI/ETA Request) could come into operation.

Available features after this step for

IM

RU

Disruption handling and delivery outstanding reports
for RUs.

Advantage:

Quality improvement of the service.

Exception handling and outstanding enquiries.

Advantage:

International shipment tracking and tracing.

Speeding up wagon turn around times.

Step 11: After a consolidation phase, the evaluation of the transmitted and stored data for quality improvement
could come into operation.

Available features after this step for

IM

RU

Availability of exhaustive statistical database.

Advantage:

Provision of input data for improvement of the transport service quality.

7.3. Management of change

7.3.1. Introduction

Change is a facet inherent to any kind of computer-based systems used in real-world environments. It is
prompted by the emergence of new requirements or by changes to existing requirements either due to errors
reported in operation or the need of improvements in performance or other non-functional characteristics.

18.1.2006

EN

Official Journal of the European Union

L 13/57

But change has to be managed as it is underpinned by continuity of service considerations and by backward
compatibility objectives so as to provoke minimal time and cost overheads to the operation of already deployed
IT equipment providing TAF functionality (i.e. legacy IT facilities). It is therefore crucial to define a clear strategy
of how to implement and manage change to legacy IT equipment to avoid disruption to railway operations
without undermining the underlying objectives of guaranteeing continuity of service and interoperability. Two
main issues underpin the definition of such a strategy:

— the establishment of a configuration management framework defining the standards and procedures for
managing system evolution. This should include how to record and process proposed system changes, how
to relate these changes to system components and how to track system releases,

— a policy for release of system baselines.

7.3.2. Baselining

System stability is essential so that actual implementation and deployment can be realistic. This need for stability
is akin to all parties:

— the infrastructure managers and the railway operators that will have to handle various versions of systems

providing TAF functionality,

— the industry that needs time to specify, develop and prove continued interoperability.

A baseline in essence embodies the concept of a stable kernel in terms of system functionality, performance and
other non-functional characteristics (e.g. RAM) (1). However, past experience with this type of systems has
shown that a number of version releases (2) are needed to achieve a stable and implementation-suitable baseline.
This can be illustrated as a cascade process as follows:

Through its feedback loops, such a process is highly intertwined. This precludes putting several of those
processes in parallel, an approach that would lead to unstable, confusing and operationally hampering situations.
Baselines have then to be processed in a series rather than in a parallel manner as illustrated below:

(1) A baseline acts as a reference starting point for a controlled management of the system evolution.
(2) A version release is a version of the system that is distributed to railway customers. Versions of the system may have different func-

tionality, performance or may repair system faults or safety or security shortcomings.

L 13/58

EN

Official Journal of the European Union

18.1.2006

7.3.3. Baseline release

Based on current experience the timing between different baselines can be estimated to be circa four to five
years.

A new baseline should in principle be linked with significant modifications of the system functionality or system
performance. This could include aspects such as:

— the incorporation of set of today's national functions, where these can be generalized, within the interoper-

able kernel,

— other future value-added services.

Each baseline should also embrace the functionality of the previous baseline. Debugging versions to repair
system faults or security shortcomings should be handled as a version release of a particular baseline. Unless
prevented by security implications such version releases within the same baseline are to be backward compa-
tible.

The added functionality that might be embodied in different baselines necessarily implies that different baselines
are not backward compatible. However, in order to facilitate migration and in the extent possible from a tech-
nical view point, different baselines should encompass a common core of functionality for which backward
compatibility should be ensured. Such a common core should provide a minimum kernel to enable interoper-
able data services under acceptable performance.

7.3.4. Deployment of new baselines

Infrastructure managers and railway operators will never be in a position to switch from one baseline to the
next over night. Henceforth, each baseline has to developed hand-in-hand with an appropriate migration
strategy. This is to address problems such as co-existence of TAF facilities compliant with different versions of
the TAF specifications, preferred paths of migration (namely trackside priority, rolling-stock priority or simulta-
neous) as well as the indicative timeframes and the priorities for the migration.

7.3.5. Change management process — the requirements

As mentioned earlier, change is a fact of life for large software based systems. Henceforth, change management
procedures should be designed to ensure that the costs and benefits of change are properly analysed and that
changes are implemented in a controlled way. This requires the defined change management process and asso-
ciated tools to ensure that changes are recorded and applied to the specifications in a cost-effective manner.
Whatever the specific details of such a process might eventually be, the latter should be broadly mapped on a
structured approach as follows:

18.1.2006

EN

Official Journal of the European Union

L 13/59

A configuration management plan embodying the set of standards and procedures for change management
should underpin the whole of the change management process as described above. The generic requirements for
such a plan are described in paragraph 7.3.6. The implementation strategy for the approved changes should be
formalised (on the basis of due process and due documentation) into a change management plan that includes
notably:

— the identification of the technical constraints underpinning the change,

— a statement of who takes responsibility for the change implementation procedures,

— the validation procedure for the changes to be implemented,

— the policy for change management, release, migration and roll-out.

An important part of the change management process is the definition of the responsibilities for the delivery of
the specifications and for both its quality assurance and configuration management. It is planned that most of
these tasks will revert to or will be supervised by the European Railway Agency (established by Regulation (EC)
No 881/2004) when this will begin operation. The change management process should be formalised within
the set of documentation referred to in Annex A.

Finally, it is essential that the Change Control Board (CCB), which eventually will act as overall system authority,
is composed of a representative cross-section of the all interested parties — namely infrastructure managers,
railway undertakings, supply industry, notified bodies and regulatory authorities alike. Such affiliation of the
parties should ensure a system perspective on the changes that are to be made and a global assessment of their
implications. The CCB ultimately will be put under the aegis of the European Railway Agency.

7.3.6. Configuration management plan — the requirements

The configuration management plan should describe the set of standards and procedures for change manage-
ment encompassing notably:

— the definition of what entities are to be managed and a formal scheme for identifying these entities,

— a statement of who takes responsibility for the configuration management procedures and for submitting

controlled entities to the configuration management decision structure,

— the configuration management policies that are to be used for change control and version management,

— a description of the records of the configuration management process which should be maintained,

— a description of the tools to be used for configuration management and the process to be applied when

using these tools,

— a definition of the configuration database which will be used to record configuration information.

The specific details of the configuration management processes are to be formalised through specifications to be
incorporated in the list of specifications included under Annex A to this TSI.

7.4. Specific cases

7.4.1. Introduction

The following special provisions are permitted in the specific cases below.

These specific cases belong to two categories: the provisions apply either permanently (case P), or temporarily
(case T). In temporary cases it is recommended that the Member States concerned should conform with the rele-
vant subsystem either by 2010 (case T1), an objective set out in Decision No 1692/96/EC of the European
Parliament and of the Council of 23 July 1996 on Community guidelines for the development of the trans-Euro-
pean transport network (1), or by 2020 (case T2). ‘T open’ is defined as an undetermined period, which will be
fixed in a future revision of this TSI.

(1) OJ L 228, 9.9.1996, p. 1. Decision as last amended by Decision No 884/2004/EC (OJ L 167, 30.4.2004, p. 1, as corrected by OJ L

201, 7.6.2004, p. 1).

L 13/60

EN

Official Journal of the European Union

18.1.2006

7.4.2. List of specific cases

7.4.2.1. Sp ec i fi c c a se for EU me mbe r sta te s w i th bor der to thi r d c ou ntr i e s

On the territories of EU Member States having a border with third countries, the requirements of this TSI are
not obligatory to transports directly arriving from or going to these third countries (case T open).

However if the transport journey will be extended to another EU Member State, then the requirements of this
TSI must be applied in full, provided that there is not a bilateral or multilateral agreement between the States
concerned or between RUs or IMs acting in the territory of those Member States

7.4.2.2. Sp ec i fi c c a se for Gr ee c e

For a transport journey operated on lines with 1 000 mm track gauge, national rules shall apply.

18.1.2006

EN

Official Journal of the European Union

L 13/61

ANNEX A

LIST OF ACCOMPANYING DOCUMENTS

List of mandatory specifications

Index N

Reference

Document name

Version

1

2

3

4

5

6

AEIF_TAF_MesDa-
ta_V11_041021.doc

AEIF_TAF_DbsDa-
ta_V10_040322.doc

AEIF_TAF_ConDa-
ta_V10_040622.doc

AEIF_TAF_Patda-
ta_V10_040622.doc

AEIF_TAF_Fig-
Seq_V10_040622.doc

AEIF_TAF_-
CofMgt_V10_041012.doc
Pending

CR telematic applications for freight: data definitions
and messages

CR telematic applications for freight: the infrastructure
data and the rolling stock data

CR telematic applications for freight: the consignment
note data and description

CR telematic applications for freight: the train path
data and description

CR telematic applications
sequence diagrams of the TAF TSI messages

freight:

for

figures and

TAF configuration management, concept and generic
requirements

1.1

1.0

1.0

1.0

1.0

1.0

L 13/62

EN

Official Journal of the European Union

18.1.2006

ANNEX B

GLOSSARY

Term

Description

ACID

AEIF

Applicant

Block train

Booking

CA

CN-code

Atomicity, Consistence, Isolation, Durability
These are the four primary attributes ensured to any transaction:
Atomicity. In a transaction involving two or more discrete pieces of informa-
tion, either all of the pieces are committed or none are.

Consistency. A transaction either creates a new and valid state of data, or, if
any failure occurs, returns all data to its state before the transaction was
started.

Isolation. A transaction in process and not yet committed must remain
isolated from any other transaction.

Durability. Committed data is saved by the system such that, even in the
event of a failure and system restart, the data is available in its correct state.

The ACID concept is described in ISO/IEC 10026-1:1992 Section 4. Each of
these attributes can be measured against a benchmark. In general, however, a
transaction manager or monitor is designed to realise the ACID concept. In a
distributed system, one way to achieve ACID is to use a two-phase commit
(2PC), which ensures that all
involved sites must commit to transaction
completion or none do, and the transaction is rolled back.

Association Européenne pour l'Interopérabilité Ferroviaire. AEIF is according
Directive 2001/16/EC the ‘joint representative body, the common association
of UIC, UNIFE and UITP’.

Means a licensed railway undertaking and/or an international grouping of
railway undertakings, and, in Member States which provide for such a possi-
bility, other persons and/or legal entities with public service or commercial
interest in procuring infrastructure capacity, such as public authorities under
Council Regulation (EEC) No 1191/69 (1) and shippers, freight forwarders and
combined transport operators, for the operation of railway service on their
respective territories.

A specific form of a direct train with only as much wagons as needed,
running between two transhipment points without intermediate marshalling.

The process of making a reservation for space on a means of transport for
the movement of goods.

Certification Authority

8-digit code list for products used by customs.

Combined rail transport

Intermodal transport where the major part of the European journey is by rail
by any initial and/or final leg carried out by road are short as possible.

Consignee

Consignment

Party by whom the goods are to be received.
Synonym: Goods receiver.

A separately identifiable amount of goods to be transported from one
consignor to one consignee via one or more than one modes of transport as
specified in one single transport document.
Synonym: Shipment.

Consignment note

A document which evidence a contract for the transportation by a carrier of
one consignment from a named place of acceptance to a named place of
delivery. It contains details of the consignment to be carried.

18.1.2006

EN

Official Journal of the European Union

L 13/63

Term

Description

Consignor

Cooperation mode

Party which, by contract with a service integrator, consigns or sends goods
with the carrier, or has them conveyed by him.
Synonyms: Shipper, Goods sender.

Mode of train operation where various RU cooperate under the leadership of
one RU (LRU). Each involved RU contracts the needed path for the transport
journey on its own.

COTS-product

Commercially-off-the-shelf products.

Departure date/time, actual

Date (and time) of departure of means of transport.

Direct train

Duty holder

Encryption

A train with related wagons which runs between two transhipment points
(initial source — final destination) without intermediate marshalling.

Any individual or legal entity responsible for the risk which he imports onto
the network, i.e. the RU.

Encoding of messages.
Decryption: converting encrypted data back into original form.

Essential requirements

Essential requirements means all the conditions set out in Annex III to Direc-
tive 2001/16/EC which must be met by the trans-European conventional rail
system, the subsystems, and the interoperability constituents including inter-
faces.

ETA

ETH

ETI

Estimated Time of Arrival of wagons at the customer side.

Estimated Time of Handover of a train from one IM to another.

Estimated Time of Interchange of wagons from one RU to another.

Forecast time

Best estimate of arrival, departure or passing time of a train.

FTP

Gateway

GGP

File Transfer Protocol.
A protocol to transfer files between computer systems in the network TCP/IP.

Station within the journey of a train with intermodal units, where the load
changes the wagons.

Gateway to Gateway Protocol.
See also IP.

Gross weight of load

Booked/actual total weight (mass) of goods, including packing but excluding
the carrier's equipment.

Handling point

Station where the RU may change the train composition, but where it
remains responsible for the wagons, no change of responsibility.

Handover point

Point where the responsibility changes from one IM to another.

Haulage

Hirer

Transport by road.

Any individual or other legal entity designated as such by the keeper/owner
of a wagon.

L 13/64

EN

Official Journal of the European Union

18.1.2006

HS code

HTTP

ICMP

IM

Term

Description

6-digit code list for products used by customs, identically to the first 6 digits
of the CN code.

Hypertext Transfer Protocol.
The client/sever protocol used on connect to servers on the Web.

Internet Control Message Protocol (ICMP).
Occasionally a gateway (see GGP) or destination host (see IP) will communi-
cate with a source host, for example, to report an error in datagram proces-
sing. For such purposes this protocol, the Internet Control Message Protocol
(ICMP), is used. ICMP, uses the basic support of IP as if it were a higher level
protocol, however, ICMP is actually an integral part of IP, and must be imple-
mented by every IP module. ICMP messages are sent in several situations: for
example, when a datagram cannot reach its destination, when the gateway
does not have the buffering capacity to forward a datagram, and when the
gateway can direct the host to send traffic on a shorter route. The Internet
Protocol
is not designed to be absolutely reliable. The purpose of these
control messages is to provide feedback about problems in the communica-
tion environment, not to make IP reliable. There are still no guarantees that a
datagram will be delivered or a control message will be returned. Some data-
grams may still be undelivered without any report of their loss. The higher
level protocols that use IP must implement their own reliability procedures if
reliable communication is required. The ICMP messages typically report
errors in the processing of datagrams. To avoid the infinite regress of
ICMP
messages about messages etc., no ICMP messages are sent about
messages. Also ICMP messages are only sent about errors in handling frag-
ment zero of fragmented datagrams. (Fragment zero has the fragment offset
equal zero.)

Infrastructure Manager. Any body or undertaking that is responsible in par-
ticular for establishing and maintaining railway infrastructure. This may also
include the management of infrastructure control and safety systems. The
functions of the infrastructure manager on a corridor or part of a corridor
may be allocated to different bodies or undertakings (Directive 2001/14/EC).

Infrastructure manager (IM)

See IM.

Interchange

The transfer of control from one railway company to another for practical
operational and safety reasons. Examples are:

— mixed services,
— services with shared haulage responsibility,
— the transfer of information between different railway administrations,
— the transfer of information between wagon owners/keepers and train

operators.

Interchange point

Location where the transfer of responsibility for the wagons of a train goes
from one RU to another RU.
Regarding a train running, the train is taken over from one RU by the other
RU, which owns now the path for the next journey section.

Intermediate point

Location which defines the start or end point of a journey section. This may
be e. g. an interchange, handover or handling point.

Intermodal operator

Operator of an intermodal terminal, e.g. a Gateway.

Intermodal service integrator

Any body or undertaking, which has the contract with customers for the
transport of intermodal units. He is preparing waybills, managing capacity on
block trains, etc.

18.1.2006

EN

Official Journal of the European Union

L 13/65

Term

Description

Intermodal terminal

Intermodal transport

Intermodal unit

Internet

Interoperability constituent

IP

Journey

Journey section

Keeper

Lead Railway Undertaking

Loco ID

LRU

MAY

Location which provides the space, equipment and operational environment
under which the loading units (freight containers, swap bodies, semi-trailers
or trailers) transfer takes place.

The movement of goods in one and the same loading unit or vehicle which
uses successively several modes of transport without handling of the goods
themselves in changing modes.

A Load Unit which can be transported by different modes, e.g. container,
swap body, semi-trailer, trailer.

— Any large network made up of several smaller networks.
— A group of networks that are interconnected so that they appear to be
one continuous large network, and can be addressed seamlessly at the OSI
model network layer through routers.

— The industry name for the network, used as reference resource for e-mail

and an on-line chat room for users around the world.

Means any elementary component, group of components, subassembly or
complete assembly of equipment incorporated or intended to be incorporated
into a subsystem upon which the interoperability of the trans-European
conventional rail system depends directly or indirectly. The concept of a
constituent covers both tangible objects and intangible objects such as soft-
ware.

(IP)

The Internet Protocol.
The Internet Protocol
system of interconnected networks.
The network connecting devices are called Gateways. These gateways commu-
nicate between themselves for control purposes via a Gateway to Gateway
Protocol (GGP).

is used for host-to-host datagram service in a

A ‘journey’ denotes the spatial forwarding of a loaded or empty wagon from
the forwarding station to the destination station.

Is the part of the journey which takes place on one infrastructure sector of an
infrastructure manager, or
part of the journey from the entry handover point to the exit handover point
of the infrastructure of one infrastructure manager.

The person, who being the owner or having the right to dispose of it, exploits
a vehicle economically in a permanent manner as a means of transport and is
registered as such in the Rolling Stock Register.

Responsible RU, which organises and manages the transport line according to
the customer's commitment. It is the single point of contact for the customer.
If more than one Railway Undertaking is involved in the transport chain, the
LRU is responsible for the coordination of the various Railway Undertakings.
A customer may be especially for intermodal transport an intermodal service
integrator.

Unique identification number of a traction unit.

See Lead Railway Undertaking.

This word, or the adjective ‘OPTIONAL’, means that an item is truly optional.
One vendor may choose to include the item because a particular marketplace
requires it or because the vendor feels that it enhances the product while
another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does include the
option, though perhaps with reduced functionality.
In the same vein an
implementation which does include a particular option.
MUST be prepared to interoperate with another implementation which does
not include the option (except, of course, for the feature the option provides).

L 13/66

EN

Official Journal of the European Union

18.1.2006

Term

Description

Metadata

MUST

MUST NOT

NFS

Simply put, is data about data. It describes data, software services, and other
components contained in the enterprise information systems. Examples of the
types of metadata include standard data definitions,
location and routing
information, and synchronisation management for distributing shared data.

This word, or the terms ‘REQUIRED’ or ‘SHALL’, mean that the definition is
an absolute requirement of the specification.

This phrase, or the phrase ‘SHALL NOT’, means that the definition is an abso-
lute prohibition of the specification.

The Network File System (NFS) is a distributed file system protocol.
The Network File System (NFS) protocol provides transparent remote access
to shared file systems across networks. The NFS protocol is designed to be
machine, operating system, network architecture, and security mechanism,
and transport protocol independent. This independence is achieved through
the use of Remote Procedure Call (RPC) primitives built on top of an eXternal
Data Representation (XDR).

Notified bodies

The bodies which are responsible for assessing the conformity or suitability
for use of the interoperability constituents or for appraising the EC procedure
for verification of the subsystems (Directive 91/440/EC).

One Stop Shop (OSS)

An international partnership between rail Infrastructure Managers providing a
single point of contact for rail customers for the purposes of:

Open Access mode

OSI

OSI reference model

OSS

Path

Path assembly

Path number

Peer-to-peer

— ordering specified train paths in international freight traffic,
— monitoring the entire train movement,
— generally also invoicing track access charges on behalf of IM's.

Mode of train operation where only one RU is involved, which runs the train
on various infrastructures. This RU contracts the needed paths with all
involved IMs.

Open Systems Interconnection.
Describes a communication protocol of open systems based on the OSI refer-
ence model. Open systems are capable of communicating independent of
proprietary solutions.

Standard description of how messages should be transmitted between any
two points in a network. The OSI model defines seven layers of functions
that take place at each end of a communication. These layers are the only
internationally accepted framework of standards for communication.

One Stop Shop.

Path means the infrastructure capacity needed to run a train between two
places over a given time-period (route defined in time and space).

Joining up of individual train paths to extend path in terms of time and
space.

Number of the defined train path.

The term ‘peer-to-peer’ refers to a class of systems and applications that
employ distributed resources to perform a critical function in a decentralised
manner. The resources encompass computing power, data (storage and
content), network bandwidth, and presence (computers, human, and other
resources). The critical function can be distributed computing, data/content
sharing, communication and collaboration, or platform services. Decentralisa-
tion may apply to algorithms, data, and metadata, or to all of them. This does
not preclude retaining centralisation in some parts of the systems and applica-
tions if it meets their requirements.

18.1.2006

EN

Official Journal of the European Union

L 13/67

Term

Description

PKI

Public key infrastructure.

Place of delivery

Place of departure

Place of destination

Pre-departure period

Primary data

Put into Service

Place where the delivery happens (departure rail station to be given). A place
where responsibility for the wagon is changed.

Place from which a means of
departed.

transport

is scheduled to depart or has

Place at which the means of transport is due to arrive or has arrived.
Synonym: Place of arrival.

Is the delta time before the scheduled time of departure. The pre-departure
period starts at scheduled time of departure minus delta time and ends at the
scheduled time of departure.

Basic data as reference data input for messages or as the basis for function-
ality and calculation of derived data.

A procedure dependent on the technical approval of a wagon and a contract
for use with a RU which allows commercial operation of the wagon.

Railway Undertaking (RU)

Railway undertaking shall mean any public or private undertaking the prin-
cipal business of which is to provide services for the transport of goods and/
or passengers by rail with a requirement that the undertaking must ensure
traction; this also includes undertakings which provide traction only.

RAMS

RARP

See Reliability, Availability, Maintainability, Safety.

Reverse Address Resolution Protocol (RARP).

Release date/time

Date/time when the goods are expected to be released or were released by the
customer.

Release time for wagons

Date and time when the wagons are ready to be pulled from the named place
on the customer siding.

Reliability, Availability, Maintain-
ability, Safety (RAMS)

Reporting point

Repository

Reliability — The ability to start and continue to operate under designated
operating conditions for a designated period expressed mathematically.
Availability — The time in operation compared to the time out of service
expressed mathematically.
Maintainability — The ability of a system to be put back into service after a
failure expressed mathematically.
Safety — The probability of a hazardous event being initiated by the system
expressed mathematically.

Location on the train journey, where the responsible IM has to issue a Train
Running Forecast message with TETA to the path contracted RU.

A repository is similar to a database and data dictionary, however it usually
encompasses a comprehensive information management system environment.
It must include not only descriptions of data structures (i.e. entities and
elements), but also metadata of
to the enterprise, data screens,
interest
reports, programs, and systems. Typically it includes and internal set of soft-
ware tools, a DBMS, a metamodel, populated metadata, and loading and
retrieval software for accessing repository data.

RID

Regulations concerning the international carriage of dangerous goods by rail.

RID number

OTIF number for dangerous goods.

L 13/68

EN

Official Journal of the European Union

18.1.2006

RIV

Route

Term

Description

Regulations governing the reciprocal use of wagons in international traffic.
Regulations governing the reciprocal use of loading tackle, container and
pallets in international traffic.

The geographical way to be taken from a starting point to a point of destina-
tion.

Route section

A part of a route.

RPC

RU

Remote Procedure Call.
The RPC protocol is specified in the Remote Procedure Call Protocol Specifi-
cation Version 2 [RFC1831].

See Railway Undertaking.

Scheduled time of departure

Date and time of departure for which the path is requested.

Scheduled timetable

Chronologically defined occupation of rail infrastructure for a train move-
ment on open line or in stations. Changes to the timetables will be supplied
by the IMs at least two days before the commencement of the day when the
train departs from its origin. This timetable applies to a specific day. Known
in some countries as the Operational Timetable.

Service provider

Responsible carrier for this specific transport stage. Party who receives and
handles the booking.

Shipment

A package of goods from one consignor to one consignee, which is loaded in
one or more complete IM units or which is loaded on one or more complete
wagons.

E.g.:

Short notice path request

Individual request for a path according Directive 2001/14/EC, Article 23 due
to additional transport demands or operational needs.

18.1.2006

EN

Official Journal of the European Union

L 13/69

Term

Description

SHOULD

SHOULD NOT

SMTP

SNMP

SQL

Stakeholders

This word, or the adjective ‘RECOMMENDED’, mean that there may exist
valid reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing a
different course.

This phrase, or the phrase ‘NOT RECOMMENDED’ mean that there may exist
valid reasons in particular circumstances when the particular behaviour is
acceptable or even useful, but the full implications should be understood and
the case carefully weighed before implementing any behaviour described with
this label.

Simple Mail Transfer Protocol.

Simple Network Management Protocol.

Structured Query Language.
A language devised by IBM, then standardised by ANSI and ISO, which is
used for creating, managing and retrieving data in relational databases.

Any person or organisation with a reasonable interest in train service delivery,
e.g.:
Railway Undertaking (RU),

Shipment monitoring provider,

Locomotive provider,

Wagon provider,

Driver/Train crew provider,

Hump yard provider,

Switch move provider,

Service integrator,

Slot provider (IM),

Train controller (IM),

Traffic manager,

Fleet manager

Ferry boat provider,

Wagon, locomotive inspector,

Wagon, locomotive repair provider,

Shipment manager,

Switching and humping provider,

Logistic provider,

Consignee,

Consignor.

For intermodal in addition:

Container provider,

Intermodal terminal operator,

Drayage provider/Haulage company,

Steam ship,

Barge lines.

TCP

Transmission Control Protocol (TCP).

Technical Specification for Intero-
perability

Means the specifications by which a subsystem or part subsystem is covered
in order to meet the essential requirements and ensure the interoperability of
the trans-European conventional rail system.

L 13/70

EN

Official Journal of the European Union

18.1.2006

TETA

Tracing

Tracking

Term

Description

See Train Estimated Time of Arrival

Activity at request of finding and reconstructing the transport history of a
given consignment, vehicle, equipment, package or cargo.

Activity of systematically monitoring and recording the present location and
status of a given consignment, vehicle, equipment, package or cargo.

Train Estimated Time of Arrival

Estimated Time of Arrival of a train at a specific point, e.g. handover point,
interchange point, destination of the train.

Train path

Train route defined in time and space.

Train Path/Slot

A definition of a train's route in terms of time and the locations (marker
points) at which it will originate and terminate along with details of those
locations en route at which it will either pass or call. The detail might also
include any activities that the train will perform en route for example train
crew, locomotive or other consist changes.

Trans-European rail network

Rail network as described in Annex 1 to Directive 2001/16/EC.

Transhipment

The operation of moving goods cargo items or unit loads from one vehicle to
another or to and from storage.

Trip plan

TSI

Tunnelling

UDP

UIC

UITP

For wagon or intermodal unit shows the planned reference trip of the wagon/
intermodal unity.

See Technical Specification for Interoperability

A process whereby private IP packets are encapsulated within a public IP
packet.

User Datagram Protocol.
Simple Traversal of User Datagram Protocol (UDP) through Network Address
Translators (NATs) (STUN) is a lightweight protocol that allows applications
to discover the presence and types of NATs and firewalls between them and
the public Internet. It also provides the ability for applications to determine
the public Internet Protocol (IP) addresses allocated to them by the NAT.
STUN works with many existing NATs, and does not require any special
behavior from them. As a result, it allows a wide variety of applications to
work through existing NAT infrastructure.

UIC is the international railway union.

UITP is the traffic operator's international cooperative organ.

UN number

United Nation number for dangerous goods.

UNIFE

UNIFE is an organisation that takes care of the interests of the suppliers to
the railway sector. Currently approximately 100 suppliers and subcontractors
are directly represented and about 1 000 indirectly through national organisa-
tions.

18.1.2006

EN

Official Journal of the European Union

L 13/71

Term

Description

Unit capacity used

Code to indicate to which extent the equipment is loaded or empty (e.g. full,
empty, LCL).

Unit load

Unit train

VPN

A number of individual packages bonded, palletised or strapped together to
form a single unit for more efficient handling by mechanical equipment.

A freight train dispatched with only one consignment note and only one type
of goods and composed of uniform wagons running from a consignor to a
consignee without intermediate marshalling.

Virtual Private Network.
The term Virtual Private Network has been used to describe almost any type
of remote connectivity system, such as the public telephone network and
Frame Relay PVCs.
With the introduction of the Internet, VPN has become synonymous with
remote IP-based data networking. Simply put, a VPN consists of two or more
private networks that communicate securely over a public network.
VPN can exist between an individual machine and a private network (client-
to-server) or a remote LAN and a private network (server-to-server). The
private networks are able to connect by tunnelling, A VPN commonly uses
the Internet as an underlying transport network, but encrypts the data being
sent between a VPN client and VPN gateway to ensure that it cannot be read
even if intercepted in transit.

Wagon load

A unit load whereas the unit is a wagon.

Wagon order

Waybill

Web

XDR

A subset of the consignment note which shows the relevant information for a
RU, needed to carry on the transportation during its responsibility until hand-
over to a next RU.
Instruction for the transportation of a wagon consignment.

The document made out by the carrier or on behalf of the carrier evidencing
the contract for the transport of cargo.

World Wide Web.
An internet service that links documents by providing hypertext links from
server to server so a user can jump from document to related document no
matter where it is stored on the Internet.

is specified in External Data Representation Standard

External Data Representation.
The XDR protocol
[RFC1832].
XDR is a standard for the description and encoding of data. It is useful for
transferring data between different computer architectures. XDR fits into the
ISO presentation layer, and is roughly analogous in purpose to X.409, ISO
Abstract Syntax Notation. The major difference between these two is that
XDR uses implicit typing, while X.409 uses explicit typing. XDR uses a
language to describe data formats. The language can be used only to describe
data; it is not a programming language. This language allows one to describe
intricate data formats in a concise manner. The alternative of using graphical
representations (itself an informal language) quickly becomes incomprehen-
sible when faced with complexity. The XDR language itself is similar to the C
language. Protocols such as ONC RPC (Remote Procedure Call) and the NFS
(Network File System) use XDR to describe the format of their data. The XDR
standard makes the following assumption: that bytes (or octets) are portable,
where a byte is defined to be 8 bits of data. A given hardware device should
encode the bytes onto the various media in such a way that other hardware
devices may decode the bytes without loss of meaning.

L 13/72

EN

Official Journal of the European Union

18.1.2006

Term

Description

XML-RPC

XML-RPC is an Extensible Mark-up Language — Remote Procedure Calling
protocol that works over the Internet. It defines an XML format for messages
that are transferred between clients and servers using HTTP. An XML-RPC
message encodes either a procedure to be invoked by the server, along with
the parameters to use in the invocation, or the result of an invocation. Proce-
dure parameters and results can be scalars, numbers, strings, dates, etc.; they
can also be complex record and list structures. This document specifies a how
to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages
encoded in the XML-RPC format between clients and servers.

XQL

Extended Structured Query Language.

(1) OJ L 156, 28.6.1969, p. 1. Regulation as last amended by Regulation (EEC) No 1893/91 (OJ L 169, 29.6.1991, p. 1).