ANNEX I

Table of contents

1.

INTRODUCTION

391

1.1.

Technical scope

391

1.2.

Geographical Scope

391

1.3.

Content of this TSI

391

2.

SUBSYSTEM DEFINITION AND SCOPE

392

2.1.

Introduction

392

2.2.

Scope

392

2.3.

Trackside Application Levels (ETCS)

393

3.

THE ESSENTIAL REQUIREMENTS FOR THE CONTROL-COMMAND AND SIGNALLING SUBSYSTEMS

393

3.1.

General

393

3.2.

Specific Aspects of the Control-Command and Signalling Subsystems

395

3.2.1.

Safety

395

3.2.2.

Reliability and Availability

395

3.2.3.

Technical Compatibility

395

3.3.

Essential requirements not directly covered by this TSI

396

3.3.1.

Safety

396

3.3.2.

Health

396

3.3.3.

Environmental Protection

396

3.3.4.

Technical Compatibility

396

3.3.5.

Accessibility

396

4.

CHARACTERISATION OF THE SUBSYSTEMS

397

4.1.

Introduction

397

4.1.1.

Basic parameters

397

4.1.2.

Overview of the requirements

397

4.1.3.

Parts of Control-command and Signalling Subsystems

398

4.2.

Functional and technical specifications of the Subsystems

398

4.2.1.

Control-Command and Signalling reliability, availability and safety characteristics relevant to interoperability

398

4.2.2.

On-Board ETCS functionality

400

4.2.3.

Trackside ETCS functionality

401

4.2.4.

Mobile communication functions for railways RMR

402

4.2.5.

RMR, ETCS and ATO air gap interfaces

403

4.2.6.

On-Board Interfaces Internal to Control-Command and Signalling

404

4.2.7.

Trackside Interfaces Internal to Control-Command and Signalling

406

4.2.8.

Key Management

407

4.2.9.

ETCS-ID Management

407

4.2.10.

Trackside Train Detection Systems

407

4.2.11.

Electromagnetic Compatibility between Rolling Stock and Control-Command and Signalling trackside equipment

407

4.2.12.

ETCS DMI (Driver-Machine Interface)

407

4.2.13.

RMR DMI (Driver-Machine Interface)

407

4.2.14.

Interface to Data Recording for Regulatory Purposes

408

4.2.15.

Trackside Control-Command and Signalling objects

408

4.2.16.

Construction of equipment used in CCS subsystems

408

4.2.17.

ETCS and Radio System Compatibility

408

4.2.18.

On-Board ATO functionality

412

4.2.19.

Trackside ATO functionality

413

4.2.20.

Technical documentation for Maintenance

413

4.3.

Functional and technical specifications of the interfaces to other Subsystems

414

4.3.1.

Interface to the Operation and Traffic Management Subsystem

414

4.3.2.

Interface to the Rolling Stock Subsystem

415

4.3.3.

Interfaces to Infrastructure Subsystem

418

4.3.4.

Interfaces to Energy Subsystem

418

4.4.

Operating rules

418

4.5.

Maintenance rules

418

4.6.

Professional competences

418

4.7.

Health and safety conditions

419

4.8.

Registers

419

4.9.

Route compatibility checks before the use of authorised vehicles

419

5.

INTEROPERABILITY CONSTITUENTS

419

5.1.

Definition

419

5.2.

List of interoperability constituents

419

5.2.1.

Basic interoperability constituents

419

5.2.2.

Grouping of interoperability constituents

419

5.3.

Constituents’ performance and specifications

420

6.

ASSESSING THE CONFORMITY AND/OR SUITABILITY FOR USE OF THE CONSTITUENTS AND VERIFYING THE SUBSYSTEMS

426

6.1.

Introduction

426

6.1.1.

General principles

426

6.1.2.

Principles for testing ETCS, ATO and RMR

427

6.2.

Interoperability constituents

427

6.2.1.

Assessment procedures for Control-Command and Signalling Interoperability Constituents

427

6.2.2.

Modules for Control-Command and Signalling Interoperability Constituents

428

6.2.3.

Assessment requirements

428

6.2.4.

Special issues

431

6.3.

Control-Command and Signalling Subsystems

432

6.3.1.

Assessment procedures for Control-Command and Signalling Subsystems

432

6.3.2.

Modules for Control-Command and Signalling Subsystems

433

6.3.3.

Assessment requirements for an On-board Subsystem

433

6.3.4.

Assessment requirements for a Trackside Subsystem

438

6.4.

Provisions in case of the partial assessment of TSI requirements

443

6.4.1.

Assessment of parts of control-command and signalling subsystems

443

6.4.2.

Intermediate Statement of Verification

444

6.5.

Management of errors

444

6.5.1.

Content of EC certificates

444

6.5.2.

Content of EC declarations

445

7.

IMPLEMENTING THE TSI CONTROL-COMMAND AND SIGNALLING

445

7.1.

Introduction

445

7.2.

Generally applicable rules

445

7.2.1.

Upgrading or renewing the Control-Command Subsystems or parts of them

445

7.2.2.

Changes to an existing On-Board subsystem

445

7.2.3.

Upgrade or renewal of existing trackside subsystem

451

7.2.4.

EC type or design examination certificates

454

7.2.5.

Legacy systems

455

7.2.6.

Availability of Specific Transmission Modules and interfaces to Class B on-board

455

7.2.7.

Additional Class B equipment on a line equipped with Class A

456

7.2.8.

Vehicle with Class A and Class B equipment

456

7.2.9.

Conditions for mandatory and optional functions

456

7.2.10.

Specifications maintenance (error corrections)

458

7.3.

RMR specific implementation rules

459

7.3.1.

Trackside installations

459

7.3.2.

On-board installations

460

7.4.

ETCS specific implementation rules

461

7.4.1.

Trackside installations

461

7.4.2.

On-board installations

462

7.4.3.

National requirements

464

7.4.4.

National Implementation Plans

464

7.5.

ETCS and radio system compatibility checks implementation rules

466

7.6.

Train detection systems specific implementation rules

466

7.7.

Specific cases

466

7.7.1.

Introduction

466

7.7.2.

List of specific cases

467

Appendix A

478

Table A 1 –

References between basic parameters and mandatory specifications

478

Table A 2 –

List of mandatory specifications

481

Table A 3 –

List of standards

486

Table A 4 –

List of mandatory standards for accredited laboratories

486

Appendix B

487

B1.

Changes of requirements and transition regimes for On-Board Subsystems

487

B2.

Changes of requirements and transition regimes for CCS Trackside Subsystem

499

B3.

Changes of Interoperability Constituent requirements and transition regimes for CCS Subsystem

501

Appendix C

503

Appendix C.1:

ESC Statement template

504

Appendix C.2:

ESC Interoperability Constituent Statement template

505

Appendix C.3:

RSC Statement template

506

Appendix C.4:

RSC Interoperability Constituent Statement template

507

Appendix C.5:

Combined ESC/RSC Statement template

508

Appendix C.6:

Combined ESC/RSC Interoperability Constituent Statement template

509

Appendix D

510

Appendix E

511

Appendix F

515

Appendix G

516

Appendix H

518

1.   INTRODUCTION

1.1.   Technical scope

This TSI concerns the Control Command and Signalling On-Board Subsystem and the Control-Command and Signalling Trackside Subsystem.

This TSI is applicable to control-command and signalling trackside Subsystems of the rail network defined in the point 1.2 (Geographical Scope) of this TSI and to the control-command and signalling on-board subsystems of vehicles which are (or are intended to be) operated on it. These vehicles are of one of the following types (as defined in point 2 of Annex I to Directive (EU) 2016/797):

(1)	locomotives and passenger rolling stock, including thermal or electric traction units, self-propelling thermal or electric passenger trains, and passenger coach, if equipped with a driving cab;

(2)	special vehicles, such as on-track machines, if equipped with a driving cab and intended to be used in running mode on its own wheels.

This list of vehicles shall include those which are specially designed to operate on the different types of high-speed lines described in point 1.2 (Geographical Scope).

1.2.   Geographical Scope

The geographical scope of this TSI is the network of the whole rail system, as described in point 1 of Annex I to Directive (EU) 2016/797 and excludes the infrastructure cases referred to in Article 1(3) and (4) of Directive (EU) 2016/797.

The TSI shall apply to networks with 1 435 mm, 1 520 mm, 1 524 mm, 1 600 mm and 1 668 mm track gauges. However, it shall not apply to short border crossing lines with 1 520 mm track gauges that are connected to the network of third countries.

1.3.   Content of this TSI

In accordance with Article 4(3) of Directive (EU) 2016/797, this TSI:

(1)	indicates its intended scope – Chapter 2 (Subsystem definition and scope);

(2)	lays down essential requirements for the Control-Command and Signalling Subsystems and their interfaces vis-à-vis other subsystems – Chapter 3 (The Essential Requirements for the Control-command and signalling Subsystems);

(3)	lays down the functional and technical specifications to be met by the Subsystems and their interfaces vis-à-vis other subsystems – Chapter 4 (Characterisation of the Subsystems);

(4)	determines the interoperability constituents and interfaces which must be covered by European specifications, including European standards, and which are necessary to achieve interoperability within the Union rail system – Chapter 5 (Interoperability Constituents);

(5)

states, in each case under consideration, which procedures are to be used to assess the conformity or the suitability for use of the interoperability constituents and for the ‘EC’ verification of the subsystems – Chapter 6 (Assessing the conformity and/or suitability for use of the constituents and verifying the subsystems);

(6)	indicates the strategy for implementing this TSI – Chapter 7 (Implementing the TSI Control-Command and Signalling);

(7)	indicates the professional competences and health and safety conditions at work required for the staff operating and maintaining these subsystems and implementing the TSI – Chapter 4 (Characterisation of the Subsystems);

(8)

indicates the provisions applicable to the existing subsystems, in particular in the event of upgrading and renewal and, in such cases, the modification work which requires an application for a new authorisation for the vehicle or trackside subsystem – Chapter 7 (Implementing the TSI Control-Command and Signalling);

(9)

indicates the parameters of the subsystems to be checked by the railway undertaking and the procedures to be applied to check those parameters after the delivery of the vehicle authorisation for placing on the market and before the first use of the vehicle to ensure compatibility between vehicles and the routes on which they are to be operated – Chapter 4 (Characterisation of the Subsystems).

In accordance with Article 4(5) of Directive (EU) 2016/797, provisions for specific cases are indicated in Chapter 7 (Implementing the TSI Control-Command and Signalling).

This TSI also sets out, in Chapter 4 (Characterisation of the Subsystems), the operating and maintenance rules which specifically apply to the scope indicated in paragraphs 1.1 and 1.2 above.

2.   SUBSYSTEM DEFINITION AND SCOPE

2.1.   Introduction

The Control-Command and Signalling Subsystems are defined in Annex II to Directive (EU) 2016/797 as:

(1)	Trackside control-command and signalling as: ‘all the trackside equipment required to ensure safety and to command and control movements of trains authorised to travel on the network.’;

(2)	On-board control-command and signalling as ‘all the on-board equipment required to ensure safety and to command and control movements of trains authorised to travel on the network’.

The features of the Control-Command and Signalling Subsystems are:

(1)	the functions that are essential for the safe control of railway traffic, and that are essential for its operation, including those required for degraded modes (1);

(2)	the interfaces;

(3)	the level of performance required to meet the essential requirements.

2.2.   Scope

The Control-Command and Signalling Subsystem TSI specifies only those requirements which are necessary to assure the interoperability of the Union rail system and the compliance with the essential requirements (2).

The Control-Command and Signalling Subsystems include the following parts:

(1)	train protection;

(2)	voice radio communication;

(3)	data radio communication;

(4)	train detection;

(5)	automated train operation (3).

ERTMS (European Rail Traffic Management System) is composed of train protection (ETCS), radio communication (RMR) and automated train operation (ATO).

The Class A train protection system is ETCS (European Train Control System) (4) whilst the Class A radio system is RMR (Railway Mobile Radio system). In this TSI, RMR comprises two radio class A systems: GSM-R and FRMCS (Future Railway Mobile Communication System) that may be implemented both at the same time or each of them independently (5).

For train detection, this TSI specifies only the requirements for the interface with other subsystems.

The list of Class B systems is established in the Annex II to this Regulation.

The requirements for the Control-Command and Signalling On-board Subsystem are specified in relation to Class A radio mobiles, train protection and automated train operation.

The requirements for the Control-Command and Signalling Trackside Subsystem are specified in relation to:

(1)	the Class A radio network;

(2)	the Class A train protection;

(3)	the Class A automated train operation;

(4)	the interface requirements for train detection systems, to ensure their compatibility with rolling stock.

All Control-Command and Signalling Subsystems, even where not specified in this TSI, shall be assessed according with Commission Implementing Regulation (EU) No 402/2013 (6).

2.3.   Trackside Application Levels (ETCS)

The interfaces specified by this TSI define the means of data transmission to, and (where appropriate) from trains. The ETCS specifications referenced by this TSI provide application levels from which a trackside implementation may choose the means of transmission that meet its requirements.

This TSI defines the requirements for all application levels. For the technical definition of the ETCS application levels see Appendix A, Table A.1, 4.1 c.

3.   THE ESSENTIAL REQUIREMENTS FOR THE CONTROL-COMMAND AND SIGNALLING SUBSYSTEMS

3.1.   General

Directive (EU) 2016/797 requires that the subsystems and the interoperability constituents including interfaces meet the essential requirements set out in general terms in Annex III to that Directive.

The essential requirements are:

(1)

Safety;

(2)	Reliability and Availability;

(3)

Health;

(4)	Environmental Protection;

(5)	Technical compatibility;

(6)	Accessibility.

The essential requirements for Class A systems are described in Table 3.1.

The requirements for Class B systems are the responsibility of the relevant Member State.

The following table indicates the essential requirements, as set out and numbered in Annex III to Directive (EU) 2016/797, taken into account by the basic parameters defined in Chapter 4 of this TSI.

Table 3.1.

Relation between Essential Requirements and Basic Parameters

Basic Parameter Point	Basic Parameter Title	Safety	Reliability-Availability	Health	Environmental protection	Technical compatibility
4.2.1	Control-Command and Signalling reliability, availability and safety characteristics relevant to interoperability	1.1.1 1.1.3 2.3.1	1.2
4.2.2	On-Board ETCS functionality	1.1.1				1.5 2.3.2
4.2.3	Trackside ETCS functionality	1.1.1				1.5 2.3.2
4.2.4	Mobile communication functions for railways RMR				1.4.3	1.5 2.3.2
4.2.5	RMR, ETCS and ATO air gap interfaces					1.5 2.3.2
4.2.6	On-Board Interfaces Internal to Control-Command and Signalling					1.5 2.3.2
4.2.7	Trackside Interfaces Internal to Control-Command and Signalling					1.5 2.3.2
4.2.8	Key Management					1.5 2.3.2
4.2.9	ETCS-ID Management					1.5 2.3.2
4.2.10	Trackside Train Detection Systems					1.5 2.3.2
4.2.11	Electromagnetic Compatibility between Rolling Stock and Control-Command and Signalling trackside equipment				1.4.3	1.5 2.3.2
4.2.12	ETCS DMI (Driver-Machine Interface)					1.5 2.3.2
4.2.13	RMR DMI (Driver-Machine Interface)					1.5 2.3.2
4.2.14	Interface to Data Recording for Regulatory Purposes	1.1.1				1.5 2.3.2
4.2.15	Trackside Control-Command and Signalling objects					1.5 2.3.2
4.2.16	Construction of equipment used in CCS subsystems	1.1.3 1.1.4		1.3.2	1.4.2
4.2.17	ETCS and Radio System Compatibility					1.5 2.3.2
4.2.18	On-Board ATO functionality					1.5 2.3.2
4.2.19	Trackside ATO functionality					1.5 2.3.2
4.2.20	Technical documentation for Maintenance	1.1.5 1.1.1

3.2.   Specific Aspects of the Control-Command and Signalling Subsystems

3.2.1.   Safety

Every Control-Command and Signalling Subsystems project shall take the measures necessary to ensure that the level of risk of an error occurring within the scope of the Control-Command and Signalling Subsystems, is not higher than the objective for the service.

To ensure that the measures taken to achieve safety do not jeopardise interoperability, the requirements of the basic parameter defined in point 4.2.1 (Control-Command and Signalling reliability, availability and safety characteristics relevant to interoperability) shall be respected.

For the ETCS Class A system the safety objective is apportioned between the Control-Command and Signalling On-board and Trackside Subsystems. The detailed requirements are specified in the basic parameter defined in point 4.2.1 (Control-Command and Signalling reliability, availability and safety characteristics relevant to interoperability). This safety requirement shall be met together with the availability requirements as defined in point 3.2.2 (Reliability and Availability).

3.2.2.   Reliability and Availability

For the Class A system, the reliability and availability objectives are apportioned between the Control-Command and Signalling On-board and Trackside Subsystems. The detailed requirements are specified in the basic parameter defined in point 4.2.1 (Control-Command and Signalling reliability, availability and safety characteristics relevant to interoperability).

The level of risk caused by age and wear of constituents used within the subsystem shall be monitored. The requirements for maintenance stated in point 4.5 shall be respected.

3.2.3.   Technical Compatibility

Technical compatibility includes the functions, interfaces and performances required to achieve interoperability.

The requirements of technical compatibility are subdivided in the following three categories:

(1)	The first category sets out the general engineering requirements for interoperability namely environmental conditions, internal electromagnetic compatibility (EMC) within the railway boundaries, and installation. These compatibility requirements are defined in this chapter.

(2)	The second category describes how the Control Command and Signalling Subsystems have to be applied technically and what functions they have to perform to ensure interoperability. This category is defined in Chapter 4.

(3)	The third category describes how the Control Command and Signalling Subsystems are interfaced with the Operation and Traffic Management Subsystem in order that operational interoperability is achieved. This category is described in Chapter 4.

3.2.3.1.   Engineering Compatibility

3.2.3.1.1.    Physical environmental conditions

Control Command and Signalling equipment shall be capable of operating under the climatic and physical conditions which characterise the area in which the relevant part of the Union rail system is located.

The requirements of basic parameter 4.2.16 (Construction of equipment used in CCS subsystems) shall be respected.

3.2.3.1.2.    Railway Internal Electromagnetic Compatibility

The basic parameter related to electromagnetic compatibility between Rolling Stock and Control-Command and Signalling trackside equipment is described in point 4.2.11 (Electromagnetic Compatibility between Rolling Stock and Control-Command and Signalling trackside equipment).

3.3.   Essential requirements not directly covered by this TSI

3.3.1.   Safety

The essential requirement 1.1.2 in Annex III to Directive (EU) 2016/797 is not within the scope of this TSI.

The essential requirement 1.1.4 in Annex III to Directive (EU) 2016/797 for the Control-Command Signalling trackside subsystems is covered by the applicable European and national provisions in force.

3.3.2.   Health

In accordance with Union legislation and with national legislation that is compatible with the Union legislation, care shall be taken to ensure that the materials used and the design of the Control-Command and Signalling Subsystems do not constitute a health hazard to persons having access to them. This is in relation with the essential requirement 1.3.1 in Annex III to Directive (EU) 2016/797. The essential requirement 1.3.2 in Annex III to Directive (EU) 2016/797 for the Control-Command Signalling trackside subsystems is covered by the applicable European and national provisions in force.

3.3.3.   Environmental Protection

In accordance with Union legislation and with national legislation that is compatible with Union legislation:

(1)	the Control-Command and Signalling equipment, if subjected to excessive heat or fire, shall not exceed limits for the emission of fumes or gases which are harmful to the environment. This is in relation with the essential requirement 1.4.2 in Annex III to Directive (EU) 2016/797;

(2)	the Control-Command and Signalling equipment shall not contain substances which may abnormally contaminate the environment during their normal use. This is in relation with the essential requirement 1.4.1 in Annex III to Directive (EU) 2016/797;

(3)

the Control-Command and Signalling equipment shall be subject to the Union legislation in force controlling the limits to the emission of and the susceptibility to electromagnetic interference along the boundaries of railway property. This is in relation with the essential requirement 1.4.3 in Annex III to Directive (EU) 2016/797;

(4)	the Control-Command and Signalling equipment shall comply with existing regulations on noise pollution. This is in relation with the essential requirement 1.4.4 in Annex III to Directive (EU) 2016/797;

(5)

the Control-Command and Signalling equipment shall not give rise to any inadmissible level of vibration which could jeopardise the integrity of the infrastructure (when the infrastructure is in the correct state of maintenance). This is in relation with the essential requirement 1.4.5 in Annex III to Directive (EU) 2016/797.

3.3.4.   Technical Compatibility

3.3.4.1.   Railway Internal Electromagnetic Compatibility

In accordance with Union legislation and with national legislation that is compatible with the Union legislation, the Control Command and Signalling equipment shall neither interfere with nor be interfered with by other control-command and signalling equipment or other subsystems.

3.3.5.   Accessibility

The essential requirement 1.6 in Annex III to Directive (EU) 2016/797 is not within the scope of this TSI.

4.   CHARACTERISATION OF THE SUBSYSTEMS

4.1.   Introduction

4.1.1.   Basic parameters

In accordance with the relevant essential requirements, the Control-Command and Signalling Subsystems are characterised by the following basic parameters:

(1)	Control-Command and Signalling reliability, availability and safety characteristics relevant to interoperability (point 4.2.1);

(2)	On-Board ETCS functionality (point 4.2.2);

(3)	Trackside ETCS functionality (point 4.2.3);

(4)	Mobile communication functions for railways RMR (point 4.2.4);

(5)	RMR, ETCS and ATO air gap interfaces (point 4.2.5);

(6)	On-Board Interfaces Internal to Control-Command and Signalling (point 4.2.6);

(7)	Trackside Interfaces Internal to Control-Command and Signalling (point 4.2.7);

(8)	Key Management (point 4.2.8);

(9)	ETCS-ID Management (point 4.2.9);

(10)	Trackside Train Detection Systems (point 4.2.10);

(11)	Electromagnetic Compatibility between Rolling Stock and Control-Command and Signalling trackside equipment (point 4.2.11);

(12)	ETCS DMI (Driver-Machine Interface) (point 4.2.12);

(13)	RMR DMI (Driver-Machine Interface) (point 4.2.13);

(14)	Interface to Data Recording for Regulatory Purposes (point 4.2.14);

(15)	Trackside Control-Command and Signalling objects (point 4.2.15);

(16)	Construction of equipment used in CCS subsystems (point 4.2.16);

(17)	ETCS and Radio System Compatibility (point 4.2.17);

(18)	On-Board ATO functionality (point 4.2.18);

(19)	Trackside ATO functionality (point 4.2.19);

(20)	Technical documentation for Maintenance (point 4.2.20).

4.1.2.   Overview of the requirements

All requirements in point 4.2 (Functional and technical specifications of the Subsystems) related to these basic parameters shall be applied to the Class A system.

Requirements for Class B systems and for STMs (which enable the Class A On-board system to operate on Class B infrastructure) are the responsibility of the relevant Member State.

This TSI is based on the principles of enabling the Control-Command and Signalling Trackside Subsystem to be compatible with TSI-compliant Control-Command and Signalling On-board Subsystems. To achieve this goal:

(1)	functions, interfaces and performance of the Control-Command and Signalling On-board Subsystem are standardised, ensuring that every train will react in a predictable way to data received from trackside;

(2)

for the Control-Command and Signalling Trackside Subsystem, track-to-train and train-to-track communication are fully standardised in this TSI. The specifications referenced in the points below allow Control-Command and Signalling trackside functionality to be applied in a flexible way, so that it can be optimally integrated into the railway system. This flexibility shall be exploited without limiting the movement of vehicles with TSI-compliant on-board subsystems.

The Control-Command and Signalling functions are classified in categories indicating whether they are optional or mandatory. The categories are defined in point 7.2.9 of this TSI and in specifications referred to in Appendix A and these texts also state how the functions are classified.

Appendix A, Table A.1, 4.1 c provides the Glossary of ETCS and ATO terms and definitions, which are used in the specifications referred to in Appendix A.

4.1.3.   Parts of Control-command and Signalling Subsystems

According to point 2.2 (Scope) the Control-Command and Signalling Subsystems can be subdivided in parts.

The following table indicates which basic parameters are relevant for each subsystem and for each part.

Table 4.1.

Parts of Control Command and Signalling Subsystems

Subsystem	Part	Basic parameters
Control-Command and Signalling On-board	Train protection	4.2.1, 4.2.2, 4.2.5, 4.2.6, 4.2.8, 4.2.9, 4.2.12, 4.2.14, 4.2.16, 4.2.17, 4.2.20
	Voice radio communication	4.2.1.2, 4.2.4.1, 4.2.4.2, 4.2.5.1, 4.2.13, 4.2.16, 4.2.17, 4.2.20
	Data radio communication	4.2.1.2, 4.2.4.1, 4.2.4.3, 4.2.5.1, 4.2.6.2, 4.2.16, 4.2.17, 4.2.20
	Automated Train Operation	4.2.1.2, 4.2.5.1, 4.2.6, 4.2.12, 4.2.16, 4.2.18, 4.2.20
Control-Command and Signalling Trackside	Train protection	4.2.1, 4.2.3, 4.2.5, 4.2.7, 4.2.8, 4.2.9, 4.2.15, 4.2.16, 4.2.17, 4.2.20
	Voice radio communication	4.2.1.2, 4.2.4, 4.2.5.1, 4.2.7, 4.2.16, 4.2.17, 4.2.20
	Data radio communication	4.2.1.2, 4.2.4, 4.2.5.1, 4.2.7, 4.2.16, 4.2.17, 4.2.20
	Train detection	4.2.10, 4.2.11
	Automated Train Operation	4.2.1.2, 4.2.5.1, 4.2.7, 4.2.16, 4.2.19, 4.2.20

4.2.   Functional and technical specifications of the Subsystems

4.2.1.   Control-Command and Signalling reliability, availability and safety characteristics relevant to interoperability

This basic parameter describes the requirements for the Control-Command and Signalling On-board Subsystem and Trackside subsystem with reference to point 3.2.1 (Safety) and point 3.2.2 (Reliability and Availability).

In order to achieve interoperability, when implementing Control-Command and Signalling On-board and Trackside subsystems the following provisions shall be respected:

(1)

The design, implementation and use of a Control-Command and Signalling On-board or Trackside subsystem shall not export any requirements: (a) across the interface between Control-Command and Signalling On-board and Trackside subsystems in addition to the requirements specified in this TSI; (b) to any other subsystem in addition to the requirements specified in the corresponding TSIs.

(2)	The requirements set out in points 4.2.1.1 and 4.2.1.2 below shall be respected.

4.2.1.1.   Safety

The Control-Command and Signalling On-board and Trackside subsystems shall respect the requirements for ETCS equipment and installations stated in this TSI.

For the hazard ‘exceeding speed and/or distance limits advised to ETCS’ the tolerable hazard rate (THR) shall be 10-9 h-1 for random failures of the on-board ETCS and 10-9 h-1 for random failures of the trackside ETCS. See Appendix A, Table A 1, 4.2.1 a.

To achieve interoperability, the on-board ETCS shall fully respect all requirements specified in Appendix A, Table A 1, 4.2.1. Nevertheless, less stringent safety requirements are acceptable for trackside ETCS provided that, in combination with TSI-compliant Control-Command and Signalling On-board subsystems, the safety level for the service is met.

For the ETCS Class A system:

(1)

the changes made by railway undertakings and infrastructure managers to implement preventive or corrective maintenance actions shall be managed in compliance with the processes and procedures of their safety management system according to Article 9 of Directive (EU) 2016/798 of the European Parliament and of the Council (Safety Directive) (7);

(2)

other types of changes made by railway undertaking and infrastructure managers (e.g. changes of the design or implementation of ETCS), as well as the changes made by other actors (e.g. manufacturers or other suppliers) shall be managed according to the risk management process set out in Annex I to the Implementing Regulation (EU) No 402/2013, as referred to in Article 6(1)(a) of Directive (EU) 2016/798.

Additionally, the correct application of the risk management process as set out in Annex I to Implementing Regulation (EU) No 402/2013, as well as the appropriateness of the results from this application, shall be independently assessed by a CSM assessment body according to Article 6 of that Regulation. There shall not be restrictions with respect to the type A, B or C of independence of the CSM assessment body permitted by Implementing Regulation (EU) No 402/2013. The appointed CSM assessment body shall be accredited or recognised according to the requirements in Annex II to Implementing Regulation (EU) No 402/2013 in the field of ‘Control-Command and Signalling’ sub-system, as listed in item 5 ‘classification’ of ERADIS database entry for Assessment Bodies.

The accreditation, or recognition, in the field of ‘Control-Command and Signalling’ sub-system, covers the CSM assessment body competence to independently assess the ‘safe integration’ at the level of an ETCS subsystem, or an ETCS Interoperability Constituent. This includes the competence for:

(1)	the assessment of safe integration of all internal components and interfaces that form the architecture of the ETCS subsystem or ETCS Interoperability Constituent;

(2)	the assessment of safe integration of all external interfaces of the ETCS subsystem, or ETCS Interoperability Constituent, within its direct physical, functional, environmental, operational and maintenance context.

The application of the standards as referred to in Appendix A, Table A 3 is an appropriate means to fully comply to the risk management process as set out in Annex I to the Implementing Regulation (EU) No 402/2013 for design, implementation, production, installation and validation (incl. Safety acceptance) of interoperability constituents and subsystems. When different standards from the ones referred to in Appendix A, Table A 3 are applied, at least equivalence shall be proven.

Whenever for an ETCS subsystem or an ETCS Interoperability Constituent the specifications as referred to in Appendix A, Table A 3 are used as an appropriate means to fully comply to the risk management process as set out in Annex I to the Implementing Regulation (EU) No 402/2013, in order to avoid unnecessary duplication of independent assessment work, the independent safety assessment activities that are required by the specifications referred to in Appendix A, Table A 3 shall be carried out by a CSM assessment body accredited or recognized as specified in the point above instead of a CENELEC independent safety assessor.

4.2.1.2.   Availability/Reliability

This point refers to the occurrence of failure modes not causing safety hazards but creating degraded situations, the management of which could decrease the overall safety of the system.

In the context of this parameter, ‘failure’ means the termination of the ability of an item to perform a required function with the required performance and ‘failure mode’ means the effect by which the failure is observed.

To ensure that the relevant infrastructure managers and railway undertaking are given all the information they need to define appropriate procedures for managing degraded situations, the technical file accompanying the EC declaration of verification for an on-board or trackside CCS subsystem shall contain the calculated availability/reliability values related to failure modes having an impact on the capability of the CCS subsystem to supervise the safe movement of one or more vehicles or to establish radio voice communication between traffic control and the train drivers.

Compliance with the following calculated values shall be ensured:

(1)	Mean time of hours of operation between failures of a CCS on-board subsystem requiring the isolation of the train protection functions: (open point);

(2)	Mean time of hours of operation between failures of a CCS on-board subsystem preventing radio voice communication between traffic control and the train driver: (open point).

To allow the infrastructure managers and railway undertakings to monitor, during the life of the subsystems, the level of risk and the respect of the reliability/availability values used for the definition of procedures to manage degraded situations, the requirements for maintenance stated in point 4.2.20 (Technical documentation for Maintenance) shall be respected.

4.2.2.   On-Board ETCS functionality

The basic parameter for ETCS on-board functionality describes all the functions needed to run a train in a safe way. The primary function is to provide automatic train protection and cab signalling:

(1)	setting the train characteristics (e.g. maximum train speed, braking performance);

(2)	selecting the supervision mode on the basis of information from trackside;

(3)	performing odometry functions;

(4)	locating the train in a coordinate system based on Eurobalise locations;

(5)	calculating the dynamic speed profile for its mission on the basis of train characteristics and of information from trackside;

(6)	supervising the dynamic speed profile during the mission;

(7)	providing the intervention function.

These functions shall be implemented in accordance with Appendix A, Table A 1, 4.2.2 b and their performance shall conform to Appendix A, Table A 1, 4.2.2 a.

The requirements for tests are specified in Appendix A, Table A 1, 4.2.2 c.

The main functionality is supported by other functions, to which Appendix A, Table A 1, 4.2.2 a and 4.2.2 b also apply, together with the additional specifications indicated below:

(1)

Communication with the Control-Command and Signalling Trackside Subsystem. (a) Eurobalise data transmission. See point 4.2.5.2 (Eurobalise communication with the train for ERTMS applications). (b) Euroloop data transmission. See point 4.2.5.3 (Euroloop communication with the train for ERTMS applications). This functionality is optional on-board unless required by specific cases in point 7.7, which shall only refer to the Appendix A specifications. (c) Radio data transmission for radio infill. See Appendix A, Table A 1, 4.2.2 d, point 4.2.5.1 (RMR air gap interface), point 4.2.6.2 (Interface between RMR Data Communication and ETCS/ATO-applications) and point 4.2.8 (Key Management). This functionality is optional on-board unless required by specific cases in point 7.7. The implementation of this functionality, including for specific cases, shall be compliant to Appendix A specifications. (d) Radio data transmission. See point 4.2.5.1 (RMR air gap interface), point 4.2.6.2 (Interface between RMR Data Communication and ETCS/ATO-applications) and point 4.2.8 (Key Management). This radio data transmission is optional unless operating on an ETCS level 2 (formerly ETCS level 2 or level 3) line.

(2)	Communicating with the driver. See Appendix A, Table A 1, 4.2.2 e, point 4.2.12 (ETCS DMI (Driver-Machine Interface)).

(3)	Communicating with the STM. See point 4.2.6.1 (ETCS and Class B train protection). This function includes: (a) managing the STM output; (b) providing data to be used by the STM; (c) managing STM transitions.

(4)

Managing information about: (a) completeness of the train – Supplying the train integrity and safe consist length information to the on-board subsystem, is optional unless it is required by trackside. (b) cold movement detection – The ETCS on-board equipment shall be fitted with a Cold Movement Detection.

(5)	Equipment health monitoring and degraded mode support. This function includes: (a) initialising the on-board ETCS functionality; (b) providing degraded mode support; (c) isolating the on-board ETCS functionality.

(6)	Support data recording for regulatory purposes. See point 4.2.14 (Interface to Data Recording for Regulatory Purposes).

(7)

Forwarding information/orders and receiving state information from rolling stock:   to/from the train interface unit. See Appendix A, Table A 1, 4.2.2 f. Note: The ETCS on-board shall be compliant with the train FFFIS only on newly developed vehicle designs requiring a first authorisation as defined in Article 14 (1), point (a) of Commission Implementing Regulation (EU) 2018/545 (8).

(8)	Forwarding information/orders and receiving state information from ATO on-board. See Appendix A, Table A 1, 4.2.2 h.

4.2.3.   Trackside ETCS functionality

This Basic parameter describes the ETCS trackside functionality. It contains all ETCS functionality to provide a safe path to a specific train.

The main functionalities are:

(1)	locating a specific train in a coordinate system based on Eurobalise locations (ETCS level 2);

(2)	translating the information from trackside signalling equipment into a standard format for the Control-Command and Signalling On-board Subsystem;

(3)	sending movement authorities including track description and orders assigned to a specific train.

These functions shall be implemented in accordance with Appendix A, Table A 1, 4.2.3 band their performance shall conform to Appendix A, Table A 1, 4.2.3 a.

The main functionality is supported by other functions, to which Appendix A, Table A 1, 4.2.3 a and 4.2.3 b also apply, together with the additional specifications indicated below:

(1)

communicating with the Control-Command and Signalling On-board Subsystem. This includes: (a) Eurobalise data transmission. See point 4.2.5.2 (Eurobalise communication with the train for ERTMS applications) and point 4.2.7.4 (Eurobalise/LEU; (b) Euroloop data transmission. See point 4.2.5.3 (Euroloop communication with the train for ERTMS applicationsand point 4.2.7.5 (Euroloop/LEU). Euroloop is only relevant in level 1, in which it is optional; (c) Radio data transmission for radio infill. See point 4.2.5.1.2.1 (GSM-R air gap interface for the ETCS application), point 4.2.7.3.1.1 (GSM-R/trackside ETCS) and point 4.2.8 (Key Management). Radio infill is only relevant in level 1, in which it is optional; (d) Radio data transmission. See point 4.2.5.1 (RMR air gap interface), point 4.2.7.3 (RMR/trackside ETCS and RMR/trackside ATO) and point 4.2.8 (Key Management). Radio data transmission is only relevant to ETCS level 2;

(2)

generating information/orders to the on-board ETCS, e.g. information related to closing/opening the air flaps, lowering/raising the pantograph, opening/closing the main power switch, changing from traction system A to traction system B. Implementation of this functionality is optional for trackside; it can however be required by other applicable TSIs or national rules or the application of risk evaluation and assessment to ensure safe integration of subsystems;

(3)	managing the transitions between areas supervised by different Radio Block Centres (RBCs) (only relevant for ETCS level 2). See point 4.2.7.1 (Functional interface between RBCs) and point 4.2.7.2 (RBC/RBC).

4.2.4.   Mobile communication functions for railways RMR

This basic parameter describes the radio communication functions. Such functions shall be implemented in the Control-Command and Signalling On-board and Trackside subsystems, according to the specifications indicated below.

4.2.4.1.   Basic communication function

4.2.4.1.1.    GSM-R Basic communication function

The general requirements are specified in Appendix A, Table A 1, 4.2.4 a.

In addition, the following specifications shall be respected:

(1)	ASCI features; Appendix A, Table A 1, 4.2.4 b;

(2)	SIM card; Appendix A, Table A 1, 4.2.4 c;

(3)	location-dependent addressing; Appendix A, Table A 1, 4.2.4 e.

4.2.4.1.2.    FRMCS Basic communication function

The general requirements are specified in Appendix A, Table A 1, 4.2.4 l

In addition, the following specifications shall be respected:

(1)	FRMCS Profile; Appendix A, Table A 1, 4.2.4 n;

4.2.4.2.   Voice and operational communication applications

4.2.4.2.1.    GSM-R Voice and operational communication applications

The general requirements are defined in Appendix A, Table A 1, 4.2.4 f.

The requirements for tests are specified in Appendix A, Table A 1, 4.2.4 g.

In addition, the following specifications shall be respected:

(1)	confirmation of high priority calls; Appendix A, Table A 1, 4.2.4 h;

(2)	functional addressing; Appendix A, Table A 1, 4.2.4 j;

(3)	presentation of functional numbers; Appendix A, Table A 1, 4.2.4 k;

(4)	User-to-User Signalling; Appendix A, Table A 1, 4.2.4 d.

4.2.4.2.2.    FRMCS Voice and operational communication applications

The general requirements are defined in Appendix A, Table A 1, 4.2.4 m.

The requirements for tests are specified in Appendix A, Table A 1, 4.2.4 o.

4.2.4.3.   Data communication applications for ETCS and ATO

4.2.4.3.1.    Data communication for ETCS

The ‘data radio communication’ part of the On-board Control-command and Signalling Subsystem shall be able to support the establishment of at least two simultaneous communication sessions with ETCS.

4.2.4.3.1.1.   GSM-R data communication for ETCS

The general requirements are defined in Appendix A, Table A 1, 4.2.4 f.

The requirements for tests are specified in Appendix A, Table A 1, 4.2.4 g.

This functionality is mandatory only in the case of ETCS level 2 and radio infill applications.

4.2.4.3.1.2.   FRMCS data communication for ETCS

The general requirements are defined in Appendix A, Table A 1, 4.2.4 m.

The requirements for tests are specified in Appendix A, Table A 1, 4.2.4 o.

This functionality is mandatory in the case of ETCS level 2 applications.

4.2.4.3.2.    Data communication for ATO

4.2.4.3.2.1.   GSM-R data communication for ATO

The general requirements are defined in Appendix A, Table A 1, 4.2.4 f.

The requirements for tests are specified in Appendix A, Table A 1, 4.2.4 g.

4.2.4.3.2.2.   FRMCS data communication for ATO

The general requirements are defined in Appendix A, Table A 1, 4.2.4 m.

The requirements for tests are specified in Appendix A, Table A 1, 4.2.4 o.

4.2.5.   RMR, ETCS and ATO air gap interfaces

This basic parameter specifies the requirements for the air gap between Control-Command and Signalling Trackside and On-board subsystems and has to be taken into account in conjunction with the requirements for the interfaces between ETCS, ATO and RMR equipment, as specified in point 4.2.6 (On-Board Interfaces Internal to Control-Command and Signalling) and point 4.2.7 (Trackside Interfaces Internal to Control-Command and Signalling).

This basic parameter includes:

(1)	the physical, electrical and electromagnetic values to be respected to allow safe functioning;

(2)	the communication protocol to be used;

(3)	the availability of the communication channel.

The applicable specifications are listed below.

4.2.5.1.   RMR air gap interface

4.2.5.1.1.    RMR general air gap interface

4.2.5.1.1.1.   GSM-R air gap interface

The air gap interface shall comply with the requirements specified in Appendix A, Table A 1, 4.2.5 a and 4.2.4 f.

Note 1:

GSM-R radio communication interfaces shall operate in the frequency band specified in Appendix A, Table A 1, 4.2.5 a and 4.2.4 f.

Note 2:

On-Board Control-command and Signalling Subsystems shall be protected against interference, fulfilling the requirements specified in Appendix A, Table A 1, 4.2.4 f.

4.2.5.1.1.2.   FRMCS air gap interface

The air gap interface shall comply with the requirements specified in Appendix A, Table A 1, 4.2.5 f.

4.2.5.1.2.    RMR air gap interface for ETCS application

4.2.5.1.2.1.   GSM-R air gap interface for the ETCS application

The data communication protocols shall comply with Appendix A, Table A 1, 4.2.5 b.

Where radio infill is implemented, the requirements stated in Appendix A, Table A 1, 4.2.5 c shall be respected in addition.

4.2.5.1.2.2.   FRMCS air gap interface for the ETCS application

The data communication protocols shall comply with Appendix A, Table A 1, 4.2.5 j.

4.2.5.1.3.    RMR air gap interface for ATO application

4.2.5.1.3.1.   GSM-R air gap interface for ATO application

Packet switch communication shall be used and the data communication protocols shall comply with the relevant requirements in Appendix A, Table A 1, 4.2.5 h.

The use of other wireless communication networks, e.g. operated by a public or private Mobile Network Operator, is allowed for the ATO application, however it is considered out of scope of this TSI.

The use of these networks shall not interfere with GSM-R voice and data communications.

4.2.5.1.3.2.   FRMCS air gap interface for ATO application

The data communication protocols shall comply with Appendix A, Table A 1, 4.2.5 i.

4.2.5.2.   Eurobalise communication with the train for ERTMS applications

Eurobalise communication interfaces shall comply with Appendix A, Table A 1, 4.2.5 d.

4.2.5.3.   Euroloop communication with the train for ERTMS applications

Euroloop communication interfaces shall comply with Appendix A, Table A 1, 4.2.5 e.

4.2.6.   On-Board Interfaces Internal to Control-Command and Signalling

This Basic Parameter consists of the following parts:

4.2.6.1.   ETCS and Class B train protection

Where ETCS and Class B train protection functions are installed on-board, the integration and transitions between them shall be managed with one of the following:

(1)	a standardised interface (STM); or

(2)	a non-standardised interface; or

(3)	Class B and Class A integrated within the same equipment (e.g. ‘bi-standards’); or

(4)	no direct interface between both equipment.

Where the integration of, and transitions between, ETCS and Class B systems are managed with the standardised interface (STM), it shall comply with requirements as specified in Appendix A, Table A 1, 4.2.6 a.

Appendix A, Table A 1, 4.2.6 b specifies the K interface (to allow certain STMs to read information from Class B balises through the ETCS on-board antenna) and Appendix A, Table A 1, 4.2.6 c the G interface (air gap between ETCS on-board antenna and Class B balises).

Implementation of Interface ‘K’ is optional, but if done it must be in accordance with Appendix A, Table A 1, 4.2.6 b.

Furthermore, if Interface ‘K’ is implemented, the on-board transmission channel functionality must be able to handle the properties of Appendix A, Table A 1, 4.2.6 c.

If the integration and transitions between ETCS and Class B train protection on-board are not managed using the standardised interface specified in Appendix A, Table A 1, 4.2.6 a, the method shall not impose any additional requirements on the Control-Command and Signalling Trackside Subsystem.

4.2.6.2.   Interface between RMR Data Communication and ETCS/ATO-applications

4.2.6.2.1.    Interface between RMR Data Communication and ETCS

4.2.6.2.1.1.   Interface between GSM-R Data Communication and ETCS

The requirements for the interface between the on-board GSM-R and the on-board ETCS functionality are specified in Appendix A, Table A 1, 4.2.6 d.

Where radio infill is implemented, the requirements stated in Appendix A, Table A 1, 4.2.6 e shall be respected.

4.2.6.2.1.2.   Interface between FRMCS Data Communication and ETCS

The requirements for the interface between on-board FRMCS and the on-board ETCS functionality are specified in Appendix A, Table A 1, 4.2.6 g.

4.2.6.2.2.    Interface between RMR Data Communication and ATO

4.2.6.2.2.1.   Interface between GSM-R Data Communication and ATO

The requirements for the interface between the on-board GSM-R and the on-board ATO functionality are specified in Appendix A, Table A 1, 4.2.6 j.

4.2.6.2.2.2.   Interface between FRMCS Data Communication and ATO

The requirements for the interface between on-board FRMCS and the on-board ATO functionality are specified in Appendix A, Table A 1, 4.2.6 k.

4.2.6.2.3.    Interface between FRMCS on-board voice application and on-board FRMCS

The requirements for the interface between FRMCS on-board voice application and on-board FRMCS are specified in Appendix A, Table A 1, 4.2.6 l.

4.2.6.3.   Odometry

There are no specific requirements for the odometry interface.

4.2.6.4.   Interface between ATO and ETCS

The requirements for the interface between the on-board ATO functionality and the on-board ETCS functionality are specified in Appendix A, Table A 1, 4.2.6 h.

4.2.6.5.   Additional CCS On-Board Internal Interfaces

4.2.6.5.1.    CCS Consist network communication layers

The interface between the end devices (e.g. ETCS on-board, ATO on-board and FRMCS on-board) and the Ethernet Consist Network shall comply with Appendix A, Table A 1, 4.2.6 i unless otherwise specified. This interface is only applicable on newly developed vehicle designs requiring a first authorisation as defined in Article 14 (1), point (a), of Implementing Regulation (EU) 2018/545.

4.2.7.   Trackside Interfaces Internal to Control-Command and Signalling

This Basic Parameter consists of five parts.

4.2.7.1.   Functional interface between RBCs

This interface defines the data to be exchanged between neighbouring RBCs to allow the safe movement of a train from one RBC area to the next:

(1)	Information from the ‘Handing Over’ RBC to the ‘Accepting’ RBC.

(2)	Information from the ‘Accepting’ RBC to the ‘Handing Over’ RBC.

(3)	The requirements are specified in Appendix A, Table A 1, 4.2.7 a.

4.2.7.2.   RBC/RBC

This is the technical interface between two RBCs. The requirements are specified in Appendix A, Table A 1, 4.2.7 b.

4.2.7.3.   RMR/trackside ETCS and RMR/trackside ATO

4.2.7.3.1.    RMR/trackside ETCS

4.2.7.3.1.1.   GSM-R/trackside ETCS

The requirements for the interface between GSM-R and the trackside ETCS functionality are specified in Appendix A, Table A 1, 4.2.7 c.

4.2.7.3.1.2.   FRMCS/trackside ETCS

The requirements for the interface between FRMCS and the trackside ETCS functionality are specified in Appendix A, Table A 1, 4.2.7 f.

4.2.7.3.2.    RMR/trackside ATO

4.2.7.3.2.1.   GSM-R/trackside ATO

The requirements for the interface between GSM-R and the trackside ATO functionality are specified in Appendix A, Table A 1, 4.2.7 g.

4.2.7.3.2.2.   FRMCS/trackside ATO

The requirements for the interface between FRMCS and the trackside ATO functionality are specified in Appendix A, Table A 1, 4.2.7 h

4.2.7.4.   Eurobalise/LEU

This is the interface between Eurobalise and the LEU. The requirements are specified in Appendix A, Table A 1, 4.2.7 d.

This interface contributes to this basic parameter only when Eurobalise and LEU are supplied as separate interoperability constituents (see point 5.2.2, Grouping of interoperability constituents).

4.2.7.5.   Euroloop/LEU

This is the interface between Euroloop and the LEU. The requirements are specified in Appendix A, Table A 1, 4.2.7 e.

This interface contributes to this Basic Parameter only when Euroloop and LEU are supplied as separate interoperability constituents (see point 5.2.2, Grouping of interoperability constituents).

4.2.8.   Key Management

This basic parameter specifies requirements for the management of cryptographic keys used for the protection of data transmitted via radio.

The requirements are specified in Appendix A, Table A 1, 4.2.8 a. Only requirements related to the interfaces of Control-Command and Signalling equipment fall within the scope of this TSI.

4.2.9.   ETCS-ID Management

This basic parameter concerns the ETCS-identities (ETCS-IDs) for equipment in Control-Command and Signalling Trackside and On-board Subsystems.

The requirements are specified in Appendix A 4.2.9 a.

4.2.10.   Trackside Train Detection Systems

This basic parameter specifies the interface requirements between the trackside train detection systems and rolling stock, related to vehicle design and operation.

The interface requirements to be respected by the train detection systems are specified in Appendix A, Table A 1, 4.2.10 a.

4.2.11.   Electromagnetic Compatibility between Rolling Stock and Control-Command and Signalling trackside equipment

This basic parameter specifies the interface requirements for electromagnetic compatibility between rolling stock and trackside Control-Command and Signalling train detection equipment.

The interface requirements to be respected by the train detection system are specified in Appendix A, Table A 1, 4.2.11 a.

4.2.12.   ETCS DMI (Driver-Machine Interface)

This basic parameter describes the information provided from ETCS and ATO to the driver and entered into the on-board by the driver. See Appendix A, Table A 1, 4.2.12 a.

It includes:

(1)	ergonomics (including visibility);

(2)	ETCS and ATO functions to be displayed;

(3)	ETCS and ATO functions triggered by driver input.

4.2.13.   RMR DMI (Driver-Machine Interface)

This basic parameter describes the information provided from RMR to the driver and entered into the RMR on-board by the driver.

It includes:

(1)	ergonomics (including visibility);

(2)	RMR functions to be displayed;

(3)	call-related information outgoing;

(4)	call-related information incoming.

4.2.13.1.   GSM-R DMI (Driver Machine Interface)

See Appendix A, Table A 1, 4.2.13 a for GSM-R.

4.2.13.2.   FRMCS DMI (Driver Machine Interface)

See Appendix A, Table A 1, 4.2.13 b for FRMCS.

4.2.14.   Interface to Data Recording for Regulatory Purposes

This basic parameter describes the data exchange between the on-board ETCS and the rolling stock recording device.

See Appendix A, Table A 1, 4.2.14 a.

4.2.15.   Trackside Control-Command and Signalling objects

This basic parameter describes:

(1)	the characteristics of retro-reflecting signs to ensure correct visibility;

(2)	the characteristics of interoperable marker boards;

(3)	the positioning of interoperable marker boards to meet their intended operational purpose.

For (1) and (2) see Appendix A, Table A 1, 4.2.15 a.

For (3) see Appendix A, Table A 1, 4.2.15 b.

In addition, the installation of trackside Control-Command and Signalling objects shall be compatible with the driver’s field of view and the infrastructure requirements.

4.2.16.   Construction of equipment used in CCS subsystems

The environmental conditions specified in the documents listed in Appendix A, Table A 2 of this TSI shall be respected.

Requirements for materials referred to in Commission Regulation (EU) No 1302/2014 (9) (LOC&PAS TSI) (e.g. related to fire protection) shall be respected by Control-command and signalling On-board Interoperability Constituents and Subsystems.

4.2.17.   ETCS and Radio System Compatibility

Due to the different possible implementations and the status of the migration to fully compliant CCS Subsystems, checks shall be performed in order to demonstrate the technical compatibility between the on-board and trackside CCS Subsystems. The necessity of these checks shall be considered as a measure to increase the confidence on the technical compatibility between the CCS subsystems. It is expected that these checks will be reduced until the principle stated in 6.1.2.1 is achieved.

4.2.17.1.   ETCS System Compatibility

ETCS System Compatibility (ESC) is the recording of technical compatibility between ETCS on-board and the trackside parts ETCS of the CCS subsystems within an area of use.

Each ESC Type identifies the set of ESC checks (e.g. document check, lab or track test, …) applicable for a section or group of sections within an area of use. It is possible to use the same ESC type for cross border infrastructure and for different national infrastructures.

The results of the ESC checks for an on-board unit on the Interoperability Constituent level or subsystem level, including findings and conditions arising, are recorded in the ESC Check Report.

‘Representative configuration’ means a configuration on the basis of which test results can be achieved, which are valid for various configurations of the same certified ETCS on-board interoperability constituent or of a certified on-board subsystem. These results shall also be equivalent for various configurations of a certified ETCS trackside subsystem.

For ESC checks at ETCS on-board Interoperability Constituent level the following is to be observed:

(1)

The ESC Interoperability Constituent Statement records the ESC results of the ETCS On-board Interoperability Constituent to the ESC Type(s) that is valid regardless of the specific configuration of the ETCS on-board Interoperability Constituent. This document shall be produced by the on-board supplier. The template provided in Appendix C.2 or C.6 shall be used.

(2)

The ESC Interoperability Constituent Statement shall include the summary of the findings and conditions of the ESC Check Report(s) on the results of the ESC checks passed (defined in one or more ESC Type), which are valid independently from the specific configuration parameters of the on-board Interoperability Constituent and can therefore be used in every applicable specific on-board CCS subsystem level.

(3)	The ESC Interoperability Constituent Statement shall include the list of ESC checks performed for the ESC Type(s).

(4)	The ESC Interoperability Constituent Statement shall include the reference to the NoBo assessment Report according to 6.2.4.3 (ETCS and radio system compatibility checks for Interoperability Constituent).

The ESC of the specific on-board CCS subsystem with respect to one or more ESC Type(s) is laid down in the ESC Statement. The template provided in Appendix C.1 or C.5 shall be used.

At subsystem level, the ESC Statement shall also include the summary of the ESC Check Report and shall demonstrate the fulfilment of the required ESC checks (for each ESC Type included in the Statement) published in the Agency ESC/RSC technical document in addition to already provided ESC interoperability constituent statements.

The ESC Statement shall also include the full list of ESC Interoperability Constituent statements taken into account in the assessment (if any), the conditions (if any) with respect to the different ESC Types and the NoBo Assessment Report according to 6.3.3.1 (ETCS and radio system compatibility checks).

4.2.17.2.   Requirements for ETCS System Compatibility

The Infrastructure Manager is responsible for defining the ESC type(s). All sections of the Union network which require the same set of checks for the demonstration of ESC shall have the same ESC type.

The list of ESC Types is published and maintained by the European Union Agency for Railways in the technical document ‘ESC/RSC technical document, TD/011REC1028’. See Appendix A, Table A 1, 4.2.17 a. The Agency shall assess the checks unless they have been assessed by a NoBo as required in Table 6.3 row 10. The assessment by the Agency shall be done within 2 months of receipt thereof, unless a longer period is agreed between the Agency and the Infrastructure Manager but not exceeding 4 months in total. The technical document will be updated within 10 working days after positive assessment.

The ESC Types shall only be used when published with status ‘Valid’ in the Agency Technical document referred above.

Infrastructure Managers, with the support of the ETCS suppliers for their network, shall submit to the Agency the definition of the necessary checks for each ESC type on their network. The minimum information that shall be included:

(1)	Definition of each check to be performed.

(2)	Criteria to pass each check.

(3)	If a check is only required for trains compatible with a specific M_VERSION functionality and a given TSI release.

(4)	If checks are to be performed in laboratories or on the track. In case of track, it shall be indicated if a specific location is required.

(5)	Contact details in order to request the performance of each check.

(6)	Description of the representative configuration of a check whenever defined by the relevant IM to be performed in a laboratory.

(7)

Proposal of the transition period between the new version of ESC Types definition and prior version, or the national procedure. It shall also be indicated the validity of the previous ESC Types. The final transition period shall be agreed with the Agency. In the absence of agreement it will be 6 months.

Infrastructure Managers shall classify the ETCS lines according to ESC Types and register the ESC Types in RINF. If no ESC definition is published in the ESC/RSC Technical Document or received by the Agency for existing lines equipped with ETCS, it shall be considered that no ESC checks are required for the concerned lines.

Infrastructure Manager shall provide the necessary means, laboratory or access to the infrastructure, to perform the checks, as required by Article 6 of Implementing Regulation (EU) 2018/545.

Infrastructure Managers shall submit to the Agency any changes on the referred checks for their network.

The ESC types are valid indefinitely unless modified or withdrawn by the Infrastructure Manager. In case of changes, the provisions on 7.2.3.4 (Impact on the technical compatibility between on-board and trackside parts of the CCS subsystems) shall be respected. If an on-board needs to be rechecked, only the new/updated ESC checks need to be done, applying the principle that already passed checks remain valid, if the vehicle is not modified.

When ESC checks are published or updated by the Agency in the technical document ‘ESC/RSC technical document, TD/011REC1028’, the corresponding existing National Rules for ETCS compatibility testing shall be withdrawn and only ESC checks shall be performed to demonstrate technical compatibility between subsystems. The IM shall indicate the equivalence (none, partial or complete) of the ESC with the previous national procedure, if existing. In such a case, Interoperability Constituent or subsystems which have demonstrated technical compatibility with the previous national procedure, may reuse that as evidence for the demonstration of compliance with the equivalent part of the new ESC without the need to execute the checks again. If not fully equivalent, the IM shall indicate a transition period as mentioned in point (7) above.

The Entity in charge of ESC demonstration shall define a representative configuration of the ETCS on-board subsystem.

The ESC Statement shall be produced by the Entity applying for ESC Demonstration.

The Entity applying for ESC Demonstration shall have the ESC check report for the Interoperability Constituent or Subsystem assessed by a Notified Body according with points 6.2.4.3 (ETCS and radio system compatibility checks for Interoperability Constituent) or 6.3.3.1 (ETCS and radio system compatibility checks).

If a Check Report or an ESC Interoperability Constituent Statement referred to in the ESC Statement contains Conditions, all Conditions shall be recorded, reflecting the status and if agreed how they are managed by the affected party (e.g. RU willing to demonstrate the compatibility with a route), and this responsibility shall be recorded in the ESC Statement.

4.2.17.3.   Radio System Compatibility

Radio System Compatibility (RSC) is the recording of technical compatibility between voice or data radio on-board and the trackside parts of RMR of the CCS subsystems within an area of use.

Each RSC Type identifies the set of RSC checks (e.g. document check, lab or track test) applicable for a section or group of sections within an area of use. It is possible to use the same RSC type for cross border infrastructure and for different national infrastructures.

The results of the RSC checks for an on-board voice or data radio part on the Interoperability Constituent level or subsystem level, including findings and conditions arising, are recorded in the RSC Check Report.

Representative Configuration means a configuration on the basis of which test results can be achieved, which are valid for various configurations of the same certified Interoperability Constituent or of a certified on-board subsystem. These results shall also be equivalent for various configurations of a certified RMR trackside subsystem.

For RSC checks at Interoperability Constituent level the following is to be observed:

(1)

The RSC Interoperability Constituent Statement records the RSC results of the Interoperability Constituent (e.g. Cab Radio or EDOR) to the RSC Type(s) that is valid regardless of the specific configuration of the Interoperability Constituents. This document shall be produced by the supplier. The template provided in Appendix C.4 or C.6 shall be used.

(2)

The RSC Interoperability Constituent Statement shall include the summary of the findings and conditions of RSC Check Report(s) on the results of the RSC checks passed (defined in one or more RSC Type), which are valid independently from the specific configuration parameters of the on-board Interoperability Constituent and can therefore be used in every applicable on-board CCS subsystem level.

(3)	The RSC Interoperability Constituent Statement shall include the list of RSC checks performed for the RSC Type(s).

(4)	The RSC Interoperability Constituent Statement shall include the reference to the NoBo assessment Report according to 6.2.4.3 (ETCS and radio system compatibility checks for Interoperability Constituent).

The RSC of the specific on-board CCS subsystem with respect to one or more RSC Type(s) is laid down in the RSC Statement. The template provided in Appendix C.3 or C.5 shall be used.

At subsystem level, the RSC Statement shall also include the summary of the Check Report and shall demonstrate the fulfilment of the required RSC checks (for each RSC Type included in the Statement) published in the Agency ESC/RSC technical document in addition to already provided RSC interoperability constituent statements.

The RSC Statement shall also include the full list of RSC Interoperability Constituent statements taken into account in the assessment (if any), the conditions (if any) with respect to the different RSC Types and the NoBo Assessment Report according to 6.3.3.1 (ETCS and radio system compatibility checks).

4.2.17.4.   Requirements for Radio System Compatibility

The Infrastructure Manager is responsible for defining the RSC type(s). All sections of the Union network which require the same set of checks for the demonstration of RSC shall have the same RSC type.

The list of RSC Types is published and maintained by the European Union Agency for Railways in the technical document ‘ESC/RSC technical document, TD/011REC1028’. See Appendix A, Table A 1, 4.2.17 a. The Agency shall assess the checks unless they have been assessed by a NoBo as required in Table 6.3 row 10. The assessment by the Agency shall be done within 2 months of receipt thereof, unless a longer period is agreed between the Agency and the Infrastructure Manager but not exceeding 4 months in total. The technical document will be updated within 10 working days after positive assessment.

The RSC Types shall only be used when published with status ‘Valid’ in the Agency Technical document referred above.

Infrastructure Managers, with the support of the RMR suppliers for their network, shall submit to the Agency the definition of the necessary checks for each RSC type on their network. The minimum information that shall be included:

(1)	Definition of each check to be performed

(2)	Criteria to pass each check

(3)	If a check is only required for trains equipped with a specific RMR GSM-R/FRMCS baseline and a given TSI release.

(4)	If checks are to be performed in laboratories or on the track. In case of track, it shall be indicated if a specific location is required.

(5)	Contact details in order to request the performance of each check

(6)	Description of the representative configuration of a check whenever defined by the relevant IM to be performed in a laboratory

(7)

Proposal of the transition period between the new version of RSC Types definition and prior version, or the national procedure. It shall also be indicated the validity of the previous RSC Types. The final transition period shall be agreed with the Agency. In the absence of agreement it will be 6 months.

Infrastructure Managers shall classify their lines according to RSC Types for voice and, if applicable, ETCS data. This RSC type classification shall be registered in RINF. If no RSC definition is published in the ESC/RSC Technical Document or received by the Agency for existing lines equipped with RMR GSM-R, it shall be considered that no RSC checks are required for the concerned lines.

Infrastructure Manager shall provide the necessary means, laboratory or access to the infrastructure, to perform the checks, as required by Article 6 of the Implementing Regulation (EU) 2018/545.

Infrastructure Managers shall submit to the Agency any changes on the referred checks for their network.

The RSC types are valid indefinitely unless modified or withdrawn by the Infrastructure Manager. In case of changes, the provisions on 7.2.3.4 (Impact on the technical compatibility between on-board and trackside parts of the CCS subsystems)shall be respected. If an on-board needs to be rechecked, only the new/updated RSC checks need to be done, applying the principle that already passed checks remain valid, if the vehicle is not modified.

When RSC checks are published or updated by the Agency in the technical document ‘ESC/RSC technical document, TD/011REC1028’, the corresponding existing National Rules for Radio compatibility testing shall be withdrawn and only RSC checks shall be performed to demonstrate technical compatibility between subsystems. The IM shall indicate the equivalence (none, partial or complete) of the RSC with the previous national procedure, if existing. In such a case, Interoperability Constituent or subsystems which have demonstrated technical compatibility with the previous national procedure, may reuse that as evidence for the RSC without the need to execute the checks again.

Entity in charge of RSC demonstration shall define a representative configuration of the Radio on-board subsystem.

The RSC Statement shall be produced by the Entity applying for RSC Demonstration.

The Entity applying for RSC Demonstration shall have the check report for the Interoperability Constituent or Subsystem assessed by a Notified Body according with points 6.2.4.3 (ETCS and radio system compatibility checks for Interoperability Constituent) or 6.3.3.1 (ETCS and radio system compatibility checks).

If a Check Report or an RSC Interoperability Constituent Statement referred to in the RSC Statement contains Conditions, all Conditions shall be recorded, reflecting the status and if agreed how they are managed by the affected party (e.g. RU willing to demonstrate the compatibility with a route), and this responsibility shall be recorded in the RSC Statement.

4.2.18.   On-Board ATO functionality

This basic parameter describes the ATO on-board functionality needed to operate a train up to Grade of Automation 2 with ETCS providing the automatic train protection functionality to enable it. The functions shall be implemented according to Appendix A, Table A 1, 4.2.18 a in addition to those required in point 4.2.2 (On-Board ETCS functionality).

The ATO functionality is supported by the additional specifications indicated below:

(1)	Communication with the Control-Command and Signalling Trackside Subsystem for radio data transmission. See point 4.2.5.1 (RMR air gap interface), point 4.2.6.2 (Interface between RMR Data Communication and ETCS/ATO-applications).

(2)	Communicating with the driver. See Appendix A, Table A 1, 4.2.2 e and 4.2.12 a (ETCS DMI).

(3)	Forwarding information/orders and receiving state information from rolling stock. See Appendix A, Table A 1, 4.2.18 c.

(4)	Forwarding information/orders and receiving state information from on-board ETCS. See Appendix A, Table A 1, 4.2.18 d.

The requirements for tests are specified in Appendix A, Table A 1, 4.2.18 b.

4.2.19.   Trackside ATO functionality

This basic parameter describes the ATO trackside functionality needed to operate a train up to Grade of Automation 2 with ETCS providing the automatic train protection functionality to enable it.

In addition to those required in point 4.2.3 (Trackside ETCS functionality), the functions shall be implemented according to Appendix A, Table A 1, 4.2.19 a.

The ATO functionality is supported with the additional specifications for communicating with the Control-Command and Signalling On-board Subsystem based on radio data transmission. See Appendix A, point 4.2.5.1 (RMR air gap interface) and point 4.2.7.3 (RMR/trackside ETCS and RMR/trackside ATO).

The requirements for tests are specified in Appendix A, Table A 1, 4.2.19 b.

4.2.20.   Technical documentation for Maintenance

This basic parameter describes the necessary requirements in relation to the technical documentation for maintenance to be fulfilled by the manufacturers of equipment and the applicant for subsystem verification.

4.2.20.1.   Responsibility of the manufacturer of equipment

The manufacturer of equipment incorporated in the subsystem shall specify:

(1)

all maintenance requirements and procedures (including health monitoring, diagnosis of events, test methods and tools and also the required professional competence) necessary for achieving essential requirements and values quoted in the mandatory requirements of this TSI throughout the equipment life-cycle (transport and storage before installation, normal operation, failures and effects of failures, repair work, checking and maintenance, decommissioning, etc.). For further details on error corrections see points 6.5 (Management of errors) and 7.2.10 (Specifications maintenance (error corrections));

(2)

all requirements and procedures (test methods and tools, the required professional competence and the evaluation of the impact of the updated Interoperability Constituent on the subsystem) necessary to implement updated Interoperability Constituents due to specification error corrections throughout the equipment life-cycle (specifications maintenance). This includes the definition of the necessary procedures for updates of approved system modules and processes, during all life cycle phases, when there are error corrections according to Article 9 of this Regulation applicable to the subsystems;

(3)	the health and safety risks that may affect the public and the maintenance staff;

(4)	the conditions for first line maintenance, i.e. the definition of Line Replaceable Units (LRUs), the definition of approved compatible versions of hardware and software, the procedures for replacing failed LRUs, the conditions for storing LRUs and for repairing failed LRUs;

(5)	the checks to be carried out if equipment is subject to exceptional stress (e.g. adverse environmental conditions or abnormal shocks);

(6)	the checks to be carried out when maintaining equipment other than Control-Command and Signalling equipment and which influences the Control-Command and Signalling Subsystems (e.g. changing the wheel diameter).

4.2.20.2.   Responsibility of the applicant for subsystem verification

The applicant shall:

(1)	ensure that the maintenance requirements as described in point 4.2.20.1 (Responsibility of the manufacturer of equipment) are defined for all components within the scope of this TSI regardless of whether or not they are interoperability constituents;

(2)	complete the above requirements in point 4.2.20.1 taking into account the risks arising from interactions between different components of the subsystem and interfaces to other subsystems.

(3)

define procedures for the roll-out of updated interoperability constituents due to specification error corrections (specifications maintenance) according to the relevant documentation of the interoperability constituent, where applicable. The applicant shall provide a configuration management system to identify the impact on the subsystem. The applicant shall ensure the availability of the documentation regarding the version of the interoperability constituents included in its subsystems.

4.2.20.3.   System identifier

The ERTMS (ETCS, RMR, ATO) functionality of an Interoperability Constituent or a subsystem shall be described with a ‘system identifier’, which is a numbering scheme to identify the system version and distinguish between a functional and a realisation identifier. The ‘functional identifier’ is part of the system identifier and means a figure or a number of figures defined by the individual configuration management, which represents a reference of the functionality for CCS implemented in a CCS subsystem or Interoperability Constituent. The ‘Realisation identifier’ is part of the system identifier and means a figure or a number of figures defined by the individual configuration management of a supplier, which represents a specific configuration (e.g. HW and SW) of a CCS subsystem or Interoperability Constituent. The ‘system identifier’, ‘functional identifier’ and ‘realisation identifier’ shall be defined by each supplier.

4.3.   Functional and technical specifications of the interfaces to other Subsystems

4.3.1.   Interface to the Operation and Traffic Management Subsystem

Interface with Operation and Traffic Management TSI
Reference CCS TSI		Reference Operation and Traffic Management TSI (10)
Parameter	Point	Parameter	Point
Operating rules List of harmonised text indications and messages displayed on the ETCS Driver Machine Interface	4.4 Appendix E	Driver’s Rule book Operating rules ERTMS trackside engineering information relevant to operation	4.2.1.2.1 4.4 Appendix D3
Trackside Control-Command and Signalling objects	4.2.15	Requirements for signal and line-side marker sighting	4.2.2.8
Train braking performance and characteristics	4.2.2	Train braking	4.2.2.6
Use of sanding equipment On-board flange lubrication Use of composite brake blocks	4.2.10	Driver’s Rule book	4.2.1.2.1
Interface to Data Recording for Regulatory Purposes	4.2.14	Data recording	4.2.3.5
ETCS DMI (Driver-Machine Interface)	4.2.12	Format of train running number	4.2.3.2.1
RMR DMI (Driver-Machine Interface)	4.2.13	Format of train running number	4.2.3.2.1
Key Management	4.2.8	Ensuring that the train is in running order	4.2.2.7
Route compatibility checks before the use of authorised vehicles	4.9	Parameters for the vehicle and train compatibility over the route intended for operation	Appendix D1

4.3.2.   Interface to the Rolling Stock Subsystem

Interface with Rolling Stock TSIs
Reference CCS TSI		Reference Rolling Stock TSIs
Parameter	Point	Parameter		Point
Compatibility with trackside train detection systems: vehicle design	4.2.10	Rolling stock characteristics to be compatible with train detection systems based on track circuits	LOC & PAS TSI	4.2.3.3.1.1
			Wagon TSI (11)	4.2.3.2
		Rolling stock characteristics to be compatible with train detection systems based on axle counters	LOC & PAS TSI	4.2.3.3.1.2
			Wagon TSI	4.2.3.3
		Rolling stock characteristics to be compatible with loop equipment	LOC & PAS TSI	4.2.3.3.1.3
			Wagon TSI	4.2.3.3
Electromagnetic Compatibility between Rolling Stock and Control-Command and Signalling trackside equipment	4.2.11	Rolling stock characteristics to be compatible with train detection systems based on track circuits	LOC & PAS TSI	4.2.3.3.1.1
			Wagon TSI	4.2.3.3
		Rolling stock characteristics to be compatible with train detection systems based on axle counters	LOC & PAS TSI	4.2.3.3.1.2
			Wagon TSI	4.2.3.3
Train braking performance and characteristics	4.2.2 4.2.18	Braking performance	LOC & PAS TSI Emergency braking	4.2.4.5.2
			LOC & PAS TSI Service braking	4.2.4.5.3
			Wagon TSI	4.2.4.1.2
Position of Control-Command and Signalling on-board antennas	4.2.2	Kinematic gauge	LOC & PAS TSI	4.2.3.1
			Wagon TSI	None
Isolation of on-board ETCS functionality	4.2.2	Operating rules	LOC & PAS TSI	4.2.12.3
			Wagon TSI	None
Trackside Control-Command and Signalling objects	4.2.15	External visibility Head lights	LOC & PAS TSI	4.2.7.1.1
			Wagon TSI	None
		Driver’s external field of view	LOC & PAS TSI Line of sight	4.2.9.1.3.1
			LOC & PAS TSI Windscreen	4.2.9.2
			Wagon TSI	None
Interface to Data Recording for Regulatory Purposes	4.2.14	Recording device	LOC & PAS TSI	4.2.9.6
			Wagon TSI	None
ETCS on-board: Forwarding information/orders and receiving state information from rolling stock	4.2.2	Separation sections	LOC & PAS TSI	4.2.8.2.9.8
			Wagon TSI	None
		Dynamic braking command	LOC&PAS TSI	4.2.4.4.4
			Wagon TSI	None
		Magnetic track brake	LOC&PAS TSI	4.2.4.8.2
			Wagon TSI	None
		Eddy current track brake	LOC&PAS TSI	4.2.4.8.3
			Wagon TSI	None
		Maximum power and current from the overhead contact line	LOC&PAS TSI	4.2.8.2.4
			Wagon TSI	None
		Door opening	LOC&PAS TSI	4.2.5.5.6
			Wagon TSI	None
		Requirements on performance	LOC&PAS TSI	4.2.8.1.2
			Wagon TSI	None
		Smoke control	LOC&PAS TSI	4.2.10.4.2
			Wagon TSI	None
		Radio Remote control function by staff for shunting operation	LOC&PAS TSI	4.2.9.3.6
			Wagon TSI	None
		Driver's desk – Ergonomics	LOC&PAS TSI	4.2.9.1.6
			Wagon TSI	None
		Requirements for management of ETCS modes: sleeping mode	LOC&PAS TSI	4.2.9.3.7.1
			Wagon TSI	None
		Requirements for management of ETCS modes: passive shunting	LOC&PAS TSI	4.2.9.3.7.2
			Wagon TSI	None
		Requirements for management of ETCS modes: non leading	LOC&PAS TSI	4.2.9.3.7.3
			Wagon TSI	None
		Type of brake system	LOC&PAS TSI	4.2.4.3
			Wagon TSI	None
		Traction Status	LOC&PAS TSI	4.2.9.3.8
			Wagon TSI	None
		Running dynamic behaviour	LOC&PAS TSI	4.2.3.4.2
			Wagon TSI	None
ATO on-board: Forwarding information/orders and receiving state information from rolling stock	4.2.18	Interface requirements with Automated Train Operation onboard	LOC & PAS TSI	4.2.13
			Wagon TSI	None
Emergency braking command	4.2.2	Emergency braking command	LOC & PAS TSI	4.2.4.4.1
			Wagon TSI	None
Construction of equipment used in CCS subsystems	4.2.16	Material requirements	LOC&PAS TSI	4.2.10.2.1
			Wagon TSI	None
Service braking command	4.2.2	Service braking command	LOC & PAS TSI	4.2.4.4.2
			Wagon TSI	None

4.3.3.   Interfaces to Infrastructure Subsystem

Interface with Infrastructure TSI
Reference CCS TSI		Reference Infrastructure TSI
Parameter	Point	Parameter		Point
Eurobalise communication (space for installation)	4.2.5.2	Structure gauge	INF TSI (12)	4.2.3.1
Euroloop communication (space for installation)	4.2.5.3	Structure gauge	INF TSI	4.2.3.1
Trackside Control-Command and Signalling objects	4.2.15	Structure gauge	INF TSI	4.2.3.1

4.3.4.   Interfaces to Energy Subsystem

Interface with Energy TSI
Reference CCS TSI		Reference Energy TSI
Parameter	Point	Parameter		Point
Commands to rolling stock equipment	4.2.2 4.2.3	Phase separation sections System separation sections	ENE TSI (13)	4.2.15 4.2.16

4.4.   Operating rules

The rules for operating a railway service with ETCS, ATO and RMR are specified in the Operation and Traffic Management TSI.

The harmonised text indications and messages displayed on the ETCS Driver Machine Interface are listed under Appendix E.

4.5.   Maintenance rules

The maintenance rules of the subsystems covered by this TSI shall ensure that the values quoted in the basic parameters indicated in Chapter 4 are maintained within the required limits throughout the lifetime of the subsystems. However, during preventative or corrective maintenance, the subsystem may not be able to respect the values quoted in the basic parameters; the maintenance rules shall ensure that safety is not prejudiced during these activities.

The entity in charge of the Control-Command and Signalling Subsystems shall set up maintenance rules to achieve the above objectives. The preparation of these rules shall be done with the assistance of the requirements in 4.2.20 (Technical documentation for Maintenance).

4.6.   Professional competences

The manufacturers of the equipment and of the subsystem shall provide information sufficient to define the professional competences required for the installation, final inspection and maintenance of the Control-Command and Signalling Subsystems. See point 4.5 (Maintenance rules).

4.7.   Health and safety conditions

Care shall be taken to ensure health and safety for maintenance and operations staff, in accordance with Union legislation and the national legislation that is compatible with the Union legislation.

Manufacturers shall indicate the risks for health and safety that arise from using and maintaining their equipment and subsystems. See point 4.4 (Operating rules) and point 4.5 (Maintenance rules).

4.8.   Registers

The data to be provided for the registers provided for in Articles 48 and 49 of Directive (EU) 2016/797 are those indicated in Commission Implementing Decision 2011/665/EU (14) and Commission Implementing Regulation (EU) 2019/777 (15).

4.9.   Route compatibility checks before the use of authorised vehicles

The parameters of the on-board CCS subsystem to be used by the railway undertaking, for the purpose of route compatibility check, are described in Appendix D1 of Implementing Regulation (EU) 2019/773.

5.   INTEROPERABILITY CONSTITUENTS

5.1.   Definition

In accordance with Article 2(7) of Directive (EU) 2016/797, interoperability constituents 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 rail system depends directly or indirectly, including both tangible objects and intangible objects.

5.2.   List of interoperability constituents

5.2.1.   Basic interoperability constituents

The basic interoperability constituents in the Control-Command and Signalling Subsystems are defined in:

(1)	Table 5.1. for the Control-Command and Signalling On-board Subsystem;

(2)	Table 5.2. for the Control-Command and Signalling Trackside Subsystem.

5.2.2.   Grouping of interoperability constituents

5.2.2.1.

The functions of basic interoperability constituents may be combined to form a group. This group is then defined by those functions and by its remaining external interfaces. If a group is formed in this way, it shall be considered as an interoperability constituent. Compliance of interfaces internal to the group of Interoperability Constituents to basic parameters of Chapter 4 does not have to be verified. Compliance of interfaces external to the group of Interoperability Constituents has to be verified to demonstrate conformity with the basic parameters related to the requirements of these external interfaces.

5.2.2.2.

When interoperability constituents are grouped, the grouped functions and their addressing must be configurable in such a way that the grouped functions of the ATO, ETCS and the radio ICs can be replaced during the life cycle of the CCS subsystem by an external ATO, ETCS or Radio ICs. Therefore, the following interfaces in a grouped Interoperability Constituent shall be made externally accessible on the CCS Consist network communication layers as specified in Appendix A, Table A 1, 4.2.6 i: (1) Interface between ATO On-Board and ETCS On-Board as specified in Appendix A, Table A 1, 4.2.6 h; (2) Interface between ATO On-Board and GSM-R data radio On-Board as specified in Appendix A, Table A 1, 4.2.6 j; (3) Interface between On-board FRMCS and the CCS applications (ETCS in Appendix A, Table A 1, 4.2.6 g and ATO in Appendix A, Table A 1, 4.2.6 k);

5.3.   Constituents’ performance and specifications

For each basic interoperability constituent or group of interoperability constituents, the tables in Chapter 5 describe:

(1)	in column 3, the functions and interfaces. Note that some interoperability constituents have functions and/or interfaces that are optional;

(2)

in column 4, the mandatory specifications for the conformity assessment of each function or interface (where applicable) by reference to the relevant section of Chapter 4. Table 5.1. Basic interoperability constituents in the Control-Command and Signalling On-board Subsystem No Interoperability constituent (IC) Characteristics Specific requirements to be assessed by reference to Chapter 4 1 ETCS on-board Reliability, Availability, Maintainability, Safety (RAMS):   Safety   Availability/Reliability   Maintainability 4.2.1.1 4.2.1.2 4.2.20.1 On-board ETCS functionality (excluding odometry) System identifier 4.2.2 4.2.20.3 ETCS air gap interfaces   RBC (Radio data transmission optional)   Radio infill unit (functionality optional)   Eurobalise air gap   Euroloop air gap (functionality optional) 4.2.5 4.2.5.1.2 4.2.5.1.2.1 4.2.5.2 4.2.5.3 Interfaces   STM (implementation of interface K optional)   GSM-R data radio   On-Board FRMCS   Key management   ETCS-ID Management   ETCS Driver-Machine Interface   Train interface (see note below)   On-board recording device   ATO interface   CCS Consist network communication layers. Note for train interface: The implementation of all functions described in Appendix A Index 7 document is mandatory at Interoperability Constituent level. 4.2.6.1 4.2.6.2.1.1 4.2.6.2.1.2 4.2.8 4.2.9 4.2.12 4.2.2 4.2.14 4.2.6.4 4.2.6.5.1 Construction of equipment 4.2.16 ETCS System Compatibility (ESC) (optional) 4.2.17.1 4.2.17.2 2 Odometry equipment Reliability, Availability, Maintainability, Safety (RAMS):   Safety   Availability/Reliability   Maintainability 4.2.1.1 4.2.1.2 4.2.20.1 On-board ETCS functionality: only Odometry 4.2.2 Construction of equipment 4.2.16 3 Standardised interface STM Interfaces   On-board ETCS 4.2.6.1 4 GSM-R voice cab radio Note: SIM card, antenna, connecting cables and filters are not part of this interoperability constituent Reliability, Availability, Maintainability (RAM):   Availability/Reliability   Maintainability 4.2.1.2 4.2.20.1 Basic communication functions 4.2.4.1.1 Voice and operational communication applications System identifier 4.2.4.2.1 4.2.20.3 Interfaces   GSM-R air gap   GSM-R Driver-Machine Interface 4.2.5.1.1.1 4.2.13.1 Construction of equipment 4.2.16 Radio System Compatibility (RSC) (optional) 4.2.17.3 4.2.17.4 5 GSM-R data radio Note: SIM card, antenna, connecting cables and filters are not part of this interoperability constituent Reliability, Availability, Maintainability (RAM):   Availability/Reliability   Maintainability 4.2.1.2 4.2.20.1 Basic communication functions 4.2.4.1.1 ETCS data communication applications System identifier 4.2.4.3.1.1 4.2.20.3 Interfaces   On-board ETCS   On-board ATO   GSM-R air gap   GSM-R air gap for ETCS   GSM-R air gap for ATO 4.2.6.2.1.1 4.2.6.2.2.1 4.2.5.1.1.1 4.2.5.1.2.1 4.2.5.1.3.1 Construction of equipment 4.2.16 Radio System Compatibility (RSC) (optional) 4.2.17.3 4.2.17.4 6 GSM-R SIM card Note: It is the responsibility of the GSM-R network operator to deliver to railway undertakings the SIM cards to be inserted in GSM-R terminal equipment. Basic communication functions System identifier 4.2.4.1.1 4.2.20.3 Construction of equipment 4.2.16 Radio System Compatibility (RSC) (optional) 4.2.17.3 4.2.17.4 7 ATO On-Board Reliability, Availability, Maintainability (RAM):   Availability/Reliability   Maintainability 4.2.1.2 4.2.20.1 On-board ATO functionality (excluding communication) System identifier 4.2.18 4.2.20.3 ATO air gap interfaces 4.2.5.1.3 Interfaces   GSM-R data radio   On-Board FRMCS   Train interface   ETCS interface   CCS Consist network communication layers 4.2.6.2.2.1 4.2.6.2.2.2 4.2.18 4.2.6.4 4.2.6.5.1 Construction of equipment 4.2.16 8 FRMCS On-Board voice application Reliability, Availability, Maintainability (RAM):   Availability/Reliability   Maintainability 4.2.1.2 4.2.20.1 Basic communication functions 4.2.4.1.2 Voice and operational communication applications System identifier 4.2.4.2.2 4.2.20.3 Interfaces   On-board FRMCS   FRMCS Driver-Machine Interface 4.2.6.2.3 4.2.13.2 Construction of equipment 4.2.16 Radio System Compatibility (RSC) (optional) 4.2.17.3 4.2.17.4 9 On-board FRMCS Reliability, Availability, Maintainability (RAM):   Availability/Reliability   Maintainability 4.2.1.2 4.2.20.1 Basic communication functions System identifier 4.2.4.1.2 4.2.20.3 Interfaces   FRMCS on-board voice application   FRMCS air gap   FRMCS air gap for ETCS application   FRMCS air gap for ATO application   On-board ETCS   On-board ATO   CCS Consist network communication layers 4.2.6.2.3 4.2.5.1.1.2 4.2.5.1.2.2 4.2.5.1.3.2 4.2.6.2.1.2 4.2.6.2.2.2 4.2.6.5.1 Construction of equipment 4.2.16 Radio System Compatibility (RSC) (optional) 4.2.17.3 4.2.17.4 10 FRMCS Profile Note: It is the responsibility of the FRMCS network operator to ensure that the FRMCS profile is made available to the subscribers. Basic communication functions System identifier 4.2.4.1.2 4.2.20.3 Construction of equipment 4.2.16 Radio System Compatibility (RSC) (optional) 4.2.17.3 4.2.17.4 Table 5.2. Basic interoperability constituents in the Control-Command and Signalling Trackside Subsystem 1 2 3 4 No Interoperability Constituent (IC) Characteristics Specific requirements to be assessed by reference to Chapter 4 1 RBC Reliability, Availability, Maintainability, Safety (RAMS):   Safety   Availability/Reliability   Maintainability 4.2.1.1 4.2.1.2 4.2.20.1 Trackside ETCS functionality (excluding communication via Eurobalises, radio infill and Euroloop) System identifier 4.2.3 4.2.20.3 RMR, ETCS and ATO air gap interfaces: only radio communication with train   GSM-R air gap interface for ETCS   FRMCS air gap interface for ETCS 4.2.5.1.2.1 4.2.5.1.2.2 Interfaces   Neighbouring RBC   GSM-R Data radio communication   FRMCS Trackside   Key management   ETCS-ID Management 4.2.7.1, 4.2.7.2 4.2.7.3.1.1 4.2.7.3.1.2 4.2.8 4.2.9 Construction of equipment 4.2.16 2 Radio infill unit Reliability, Availability, Maintainability, Safety (RAMS):   Safety   Availability/Reliability   Maintainability 4.2.1.1 4.2.1.2 4.2.20.1 Trackside ETCS functionality (excluding communication via Eurobalises, Euroloop and level 2 functionality) System identifier 4.2.3 4.2.20.3 RMR, ETCS and ATO air gap interfaces: only radio communication with train   GSM-R air gap interface for ETCS 4.2.5.1.2.1 Interfaces   GSM-R Data radio communication   Key management   ETCS-ID Management   Interlocking and LEU 4.2.7.3 4.2.8 4.2.9 4.2.3 Construction of equipment 4.2.16 3 Eurobalise Reliability, Availability, Maintainability, Safety (RAMS):   Safety   Availability/Reliability   Maintainability 4.2.1.1 4.2.1.2 4.2.20.1 ETCS and RMR air gap interfaces: only Eurobalise communication with train System identifier 4.2.5.2 4.2.20.3 Interfaces   LEU – Eurobalise 4.2.7.4 Construction of equipment 4.2.16 4 Euroloop Reliability, Availability, Maintainability, Safety (RAMS):   Safety   Availability/Reliability   Maintainability 4.2.1.1 4.2.1.2 4.2.20.1 ETCS and RMR air gap interfaces: only Euroloop communication with train System identifier 4.2.5.3 4.2.20.3 Interfaces   LEU – Euroloop 4.2.7.5 Construction of equipment 4.2.16 5 LEU Eurobalise Reliability, Availability, Maintainability, Safety (RAMS):   Safety   Availability/Reliability   Maintainability 4.2.1.1 4.2.1.2 4.2.20.1 Trackside ETCS functionality (excluding communication via radio infill, Euroloop and level 2 functionality) System identifier 4.2.3 4.2.20.3 Interfaces   LEU – Eurobalise 4.2.7.4 Construction of equipment 4.2.16 6 LEU Euroloop Reliability, Availability, Maintainability, Safety (RAMS):   Safety   Availability/Reliability   Maintainability 4.2.1.1 4.2.1.2 4.2.20.1 Trackside ETCS functionality (excluding communication via radio infill, Eurobalise and level 2 functionality) System identifier 4.2.3 4.2.20.3 Interfaces   LEU – Euroloop 4.2.7.5 Construction of equipment 4.2.16 7 Axle Counter Trackside train detection systems (only parameters relevant for axle counters) 4.2.10 Electromagnetic compatibility (only parameters relevant for axle counters) 4.2.11 8 Marker Board Trackside Control-Command and Signalling objects (only points 1 and 2) 4.2.15 Construction of equipment 4.2.16 9 ATO Trackside Reliability, Availability, Maintainability (RAM):   Availability/Reliability   Maintainability 4.2.1.2 4.2.20.1 Trackside ATO functionality System identifier 4.2.19 4.2.20.3 RMR, ETCS and ATO air gap interfaces: only radio communication with train   GSM-R air gap interface for ATO   FRMCS air gap interface for ATO 4.2.5.1.3.1 4.2.5.1.3.2 Interfaces:   GSM-R Data radio communication   FRMCS Trackside 4.2.7.3.2.1 4.2.7.3.2.2 Construction of equipment 4.2.16

6.   ASSESSING THE CONFORMITY AND/OR SUITABILITY FOR USE OF THE CONSTITUENTS AND VERIFYING THE SUBSYSTEMS

6.1.   Introduction

6.1.1.   General principles

6.1.1.1.   Compliance with basic parameters

Fulfilment of the essential requirements set out in Chapter 3 of this TSI shall be ensured through compliance with the basic parameters specified in Chapter 4.

This compliance shall be demonstrated by:

(1)	assessing the conformity of the interoperability constituents specified in Chapter 5 (see points 6.2.1, 6.2.2, 6.2.3, 6.2.4);

(2)	verifying the subsystems (see point 6.3 and point 6.4).

In case of changes to existing subsystems, the requirements in 7.2.2 for on-board subsystems and 7.2.3 for trackside subsystems shall be considered in the assessment.

6.1.1.2.   Partial fulfilment of TSI requirements

An on-board subsystem may, if fulfilling both conditions below, not implement all mandatory functionalities specified in this TSI:

(1)	the functionalities are listed in Appendix G;

(2)	the Infrastructure Manager (with the support of the Member State) has indicated in RINF that the partial fulfilment of the listed requirement does not prevent an optimal and safe operation on its network.

Where a control-command and signalling interoperability constituent or subsystem does not implement all functionalities specified in this TSI, the relevant conditions for use shall reflect it in accordance with provisions of points 6.5.1 and 6.5.2.

6.1.2.   Principles for testing ETCS, ATO and RMR

6.1.2.1.   Principle

The principle is that a Control-Command and Signalling On-board Subsystem covered by an ‘EC’ declaration of verification is able to run on every Control-Command and Signalling Trackside Subsystem covered by an ‘EC’ Declaration of verification, under the conditions specified in this TSI, with no additional verifications.

Achievement of this principle is facilitated by:

(1)	rules for the design and installation of the Control-Command and Signalling On-board and the Trackside subsystems;

(2)	test specifications to prove that the Control-Command and Signalling On-board and Trackside Subsystems comply with the requirements of this TSI and are mutually compatible.

6.1.2.2.   Operational test scenarios

For the purpose of this TSI, an ‘operational test scenario’ means a sequence of trackside and on-board events related to or influencing the Control-command and Signalling subsystems (e.g. sending/receiving messages, exceeding a speed limit, actions of operators ) and the specified timing between them in order to test the intended railway system operation in situations relevant for ETCS, ATO and RMR (e.g. entry of a train into an equipped area, awakening of a train, overriding a signal at stop).

The operational tests scenarios are based on the engineering rules adopted for the project.

Check of compliance of a real implementation with an operational test scenario shall be possible gathering information through easily accessible interfaces (preferably the standard interfaces specified in this TSI).

6.1.2.3.   Requirements for Operational test scenarios

The set of engineering rules for the trackside parts of ETCS, ATO and RMR and related operational test scenarios for the Trackside Control-command and Signalling Subsystem shall be sufficient to describe all intended system operations relevant for the Trackside Control-command and Signalling Subsystem in normal and identified degraded situations, and:

(1)	shall be consistent with the specifications referenced in this TSI;

(2)	shall assume that functions, interfaces and performance of the Control-command and Signalling On-board Subsystems interacting with the Trackside Subsystem are compliant with the requirements of this TSI;

(3)

shall be the ones used in the EC Verification of the Trackside Control-command and Signalling Subsystem, to check that the implemented functions, interfaces and performance are able to ensure that the intended system operation in combination with the relevant modes and transitions between levels and modes of the Control-command and Signalling On-board Subsystems are respected.

6.2.   Interoperability constituents

6.2.1.   Assessment procedures for Control-Command and Signalling Interoperability Constituents

Before placing on the market an interoperability constituent and/or groups of interoperability constituents the manufacturer or his authorised representative established within the European Union shall draw up an ‘EC’ declaration of conformity in accordance with Article 9(2) and Article 10(1) of Directive (EU) 2016/797.

The assessment procedure shall be carried out using one of the modules specified in point 6.2.2 (Modules for Control-Command and Signalling Interoperability Constituents).

An ‘EC’ declaration of suitability for use is not required for Control-Command and Signalling interoperability constituents. Compliance with relevant basic parameters, as demonstrated by the ‘EC’ Declaration of conformity, is sufficient for placing the interoperability constituents on the market (16).

6.2.2.   Modules for Control-Command and Signalling Interoperability Constituents

For assessing interoperability constituents within the Control-Command and Signalling Subsystems, the manufacturer or his authorised representative established within the European Union, may choose:

(1)	either the type-examination procedure (Module CB) for the design and development phase in combination with the production quality management system procedure (Module CD) for the production phase; or

(2)	the type-examination procedure (Module CB) for the design and development phase in combination with the product verification procedure (Module CF); or

(3)	the full quality management system with design examination procedure (Module CH1).

In addition, for checking the SIM card and Marker Board Interoperability Constituent, the manufacturer or his representative may choose Module CA.

The modules are described in detail in the Commission Decision 2010/713/EU (17).

The following clarifications apply to the use of some of the modules:

(1)	with reference to Chapter 2 of the ‘Module CB’, ‘EC’-type examination shall be carried out through a combination of production type and design type;

(2)	with reference to Chapter 3 of the ‘Module CF’ (product verification) statistical verification is not allowed, i.e. all interoperability constituents shall be individually examined.

6.2.3.   Assessment requirements

Independently of the selected module:

(1)	the requirements stated in point 6.2.4.1 of this TSI shall be respected for the ‘On-board ETCS’ interoperability constituent;

(2)

the activities shown in Table 6.1.1 shall be carried out when assessing the conformity of an interoperability constituent or a group of interoperability constituents as defined in Chapter 5 of this TSI. All verifications shall be carried out by reference to the applicable table in Chapter 5 and the basic parameters indicated there.

(3)

The manufacturer of the equipment shall inform a Notified Body about all changes affecting the conformity of the Interoperability Constituent due to the requirements of the applicable TSI release. The manufacturer shall also demonstrate if these specifications of error corrections require new checks, in accordance with Table 6.1.1 and by application of modules for the EC Conformity according to 6.2.2. This information shall be provided by the manufacturer with corresponding references to the technical documentation relating to the existing EC certificate. The manufacturer shall justify and document that applicable requirements are met at interoperability constituent level, which shall be assessed by a Notified Body.

The manufacturer shall inform the impacted entities about changes, e.g. regarding operation and maintenance, if they affect existing and already implemented products/components.

Table 6.1.1.

Conformity assessment requirements of an interoperability constituent or a group of interoperability constituents

No	Aspect	What to assess	Supporting evidence
1a	Functions, interfaces and performances	Check that all mandatory functions, interfaces and performances as described in the basic parameters referenced in the relevant table of Chapter 5 are implemented and that they comply with the requirements of this TSI.	Design documentation and running of test cases and test sequences, as described in the basic parameters referenced in the relevant table of Chapter 5.
1b		Check which optional functions and interfaces as described in the basic parameters referenced in the relevant table of Chapter 5 are implemented and that they comply with the requirements of this TSI.	Design documentation and running of test cases and test sequences, as described in the basic parameters referenced in the relevant table of Chapter 5.
1c		Check which additional functions and interfaces (not specified in this TSI) are implemented and that they do not lead to conflicts with implemented functions specified in this TSI.	Impact analysis.
2a	Construction of equipment	Check compliance with mandatory conditions, where specified in the basic parameters referenced in the relevant table of Chapter 5.	Documentation on material used and, where necessary, tests to ensure that the requirements of the basic parameters referenced in the relevant table of Chapter 5 are satisfied.
2b		In addition, check that the interoperability constituent functions correctly in the environmental conditions for which it is designed.	Tests according to the applicant’s specifications.
3	Reliability, Availability, Maintainability, Safety (RAMS)	Check compliance with the safety requirements where specified in the basic parameters referenced in the relevant table of Chapter 5, i.e. 1. respect for quantitative Tolerable Hazard Rates (THRs) caused by random failures; 2. the development process is able to detect and eliminate systematic failures.	1. Calculations for the THRs caused by random failures, supported by reliability data. 2.1. The manufacturer’s quality and safety management throughout design, manufacturing and testing conforms to a recognised standard (see Note). 2.2. The software development life-cycle, the hardware development life-cycle and the integration of hardware and software have each been undertaken in accordance with a recognised standard (see Note). 2.3. The safety verification and validation process has been undertaken in accordance with a recognised standard (see Note) and respects the safety requirements described in the basic parameters referenced in the relevant table of Chapter 5. 2.4. The functional and technical safety requirements (correct operation under fault-free conditions, effects of faults and of external influences) are verified in accordance with a recognised standard (see Note). Note: The standard shall satisfy at least the following requirements: (1) be compliant with the requirements for code of practice, as stated in Annex I, point 2.3.2, of Regulation (EU) No 402/2013; (2) be widely acknowledged in the railway domain. If this is not the case, the standard will have to be justified and be acceptable to the Notified Body; (3) be relevant for the control of the considered hazards in the system under assessment; (4) be publicly available for all actors who want to use it.
4		Check that the quantitative reliability target (related to random failures) indicated by the applicant is met.	Calculations
5		Elimination of systematic failures.	Tests of equipment (full Interoperability Constituent or separately for subassemblies) in operational conditions, with repair when defects are detected. Documentation accompanying the certificate which indicates which kind of verifications have been performed, which standards have been applied and criteria adopted to consider these tests completed (according to decisions of the applicant).
6	Technical documentation for maintenance	Check compliance with maintenance requirements – point 4.2.20.1.	Document check

6.2.4.   Special issues

6.2.4.1.   Mandatory tests for the on-board ETCS

Particular attention shall be given to assessing the conformity of the on-board ETCS interoperability constituent, since it is complex and plays a key role in achieving interoperability.

Regardless of whether module CB or CH1 is chosen, the Notified Body shall check that:

(1)

a representative specimen of the interoperability constituent has been submitted to a full set of test sequences including all test cases necessary to check the functions referenced in point 4.2.2 (On-Board ETCS functionality). The applicant is responsible to define the test cases and their organisation in sequences, if this is not included in specifications referenced in this TSI;

(2)

these tests were carried out in a laboratory accredited in accordance with Regulation (EC) No 765/2008 of the European Parliament and of the Council (18) and the standards referred to in Appendix A, Table A 4 to carry out tests with the use of the test architecture and the procedures specified in Appendix A, Table A 1: (a) For on-board ETCS supporting up to system version 2.1: 4.2.2 c. (b) For on-board ETCS supporting up to system version 2.2 and 3.0: not included, see previous point (1).

The laboratory shall provide a full report clearly indicating the results of the tests cases and sequences used. The Notified Body is responsible to assess the suitability of test cases and sequences to check compliance with all relevant requirements and to evaluate the results of tests in view of the certification of the Interoperability Constituent.

6.2.4.2.   Class B interfaces

Each Member State shall be responsible for verifying that Class B systems and their interfaces to the ETCS on-board Interoperability Constituent conform to its national requirements.

The verification of the standardised STM interface to the on-board ETCS requires a conformity assessment carried out by a Notified Body.

6.2.4.3.   ETCS and radio system compatibility checks for Interoperability Constituent

Since the ESC/RSC checks are not required in Table 6.1.1, they are not required for issuing an interoperability constituent certificate.

If ESC/RSC checks are executed at Interoperability Constituent level, the task of the NoBo with regards to the ESC/RSC Interoperability Constituent statement(s) and associated report is to verify the correctness and completeness of the ESC/RSC check report for the Interoperability Constituent, according to the requirements in this point.

In line with the Directive (EU) 2016/797 the Notified Body performing this assessment may be a different one from the Notified Body performing the EC conformity or suitability procedure for the interoperability constituent.

Table 6.1.2.

NoBo assessment of the ETCS or Radio System Compatibility Check for Interoperability Constituents

No	Aspect	What to assess	Supporting evidence
1	Availability of the results	Assess that the check report gives reference to the checks according to the definition of the ESC/RSC types in the technical document published by ERA (19). Assess that the Interoperability Constituent check report clearly indicates which checks have been verified for the ESC/RSC Type.	Evaluation of the ESC/RSC Check Report.
2	Availability of the results	Assess that ESC/RSC results indicate for every ESC/RSC Check whether the ESC/RSC Check was passed as specified or not.	Evaluation of the ESC/RSC Check Report.
3	Incompatibilities and errors reported	Assess that for every ESC/RSC Check which was not passed as specified, the incompatibilities and errors reported during ESC/RSC Checks are stated.	Evaluation of the ESC/RSC Check Report.
4	Impact analysis	Assess that for every ESC/RSC Check which was not passed as specified, an impact analysis of the effects on ESC/RSC has been performed and recorded using the template provided in the Appendix D.	Evaluation of the ESC/RSC Check Report.

6.3.   Control-Command and Signalling Subsystems

6.3.1.   Assessment procedures for Control-Command and Signalling Subsystems

This Chapter deals with the ‘EC’ declaration of verification for the Control-Command and Signalling On-board Subsystem and the ‘EC’ declaration of verification for the Control-Command and Signalling Trackside Subsystem.

At the request of the applicant the Notified Body shall carry out an ‘EC’ verification of a Control-Command and Signalling On-board or Trackside Subsystem in accordance with Annex IV to Directive (EU) 2016/797.

The applicant shall draw up the ‘EC’ declaration of verification for the Control-Command and Signalling On-board or Trackside Subsystem in accordance with Article 15(1) and (9) of Directive (EU) 2016/797.

The content of the ‘EC’ declaration of verification shall conform to Article 15(9) of Directive (EU) 2016/797.

The assessment procedure shall be carried out using the modules specified in point 6.3.2 (Modules for Control-Command and Signalling Subsystems).

The ‘EC’ declarations of verification for a Control-Command and Signalling On-board Subsystem and of a Control-Command and Signalling Trackside Subsystem, together with the certificates of conformity, shall be deemed sufficient to ensure that the subsystems are compatible under the conditions specified in this TSI.

6.3.2.   Modules for Control-Command and Signalling Subsystems

All modules indicated below are specified in the Decision 2010/713/EU.

6.3.2.1.   On-board Subsystem

For verifying the Control-Command and Signalling On-board Subsystem, the applicant may choose either:

(1)	the type-examination procedure (Module SB) for the design and development phase in combination with the production quality management system procedure (Module SD) for the production phase; or

(2)	the type-examination procedure (Module SB) for the design and development phase in combination with the product verification procedure (Module SF); or

(3)	the full quality management system with design examination procedure (Module SH1).

6.3.2.2.   Trackside Subsystem

For verifying the Control-Command and Signalling Trackside Subsystem, the applicant may choose either:

(1)	the unit verification procedure (Module SG); or

(2)	the type-examination procedure (Module SB) for the design and development phase in combination with the production quality management system procedure (Module SD) for the production phase; or

(3)	the type-examination procedure (Module SB) for the design and development phase in combination with the product verification procedure (Module SF); or

(4)	the full quality management system with design examination procedure (Module SH1).

6.3.2.3.   Conditions for using modules for On-board and Trackside Subsystems

With reference to point 4.2 of Module SB (type-examination), design review is requested.

With reference to point 4.2 of Module SH1 (full quality management system with design examination), an additional type test is required.

6.3.3.   Assessment requirements for an On-board Subsystem

Table 6.2.1 shows the checks that must be carried out when verifying a Control-Command and Signalling On-board Subsystem and the basic parameters that must be respected.

Independently of the module chosen:

(1)	verification shall demonstrate that the Control-Command and Signalling On-board Subsystem complies with basic parameters when it is integrated into the vehicle;

(2)	the functionality and performances of interoperability constituents already covered by their EC Declaration of conformity do not require additional verifications;

(3)

the update due to specifications maintenance of an already integrated Interoperability Constituent will not require additional verification by a subsystem Notified Body if the Interoperability Constituent Notified Body confirms that the impact of the update to be assessed is limited to the Interoperability Constituent and if no impact at subsystem level is identified by the CSM assessment body assessing the subsystem integration of the update. Table 6.2.1. Conformity assessment requirements for an On-board Subsystem or for groups of Parts No Aspect What to assess Supporting evidence 1a Use of interoperability constituents Check whether the interoperability constituents to be integrated into the subsystem are all covered by an ‘EC’ Declaration of conformity and a corresponding certificate. The Subsystem needs to be checked with a SIM card compliant with the requirements of this TSI. Changing the SIM card with another one compliant with the TSI is not a modification of the Subsystem. Existence and content of documents. 1b Check conditions and limits of use on the use of Interoperability Constituents against the characteristics of the subsystem and of the environment Analysis by document check. 1c For interoperability constituents that have been certified against a version of the CCS TSI, which is different from the version applied for the ‘EC’ Verification of the subsystem and/or against a set of specifications which is different from the set of specifications applied for the ‘EC’ Verification of the subsystem, check that the certificate still ensures subsystem compliance with the requirements of the TSI currently in force. Impact analysis by document checks. 2a Integration of interoperability constituents in the subsystem Check the correct installation and functioning of the internal interfaces of the subsystem – Basic parameter 4.2.6. Checks according to specifications. 2b Check that additional functions (not specified in this TSI) do not impact the mandatory ones. Impact analysis. 2c Check that the values of ETCS IDs are within the allowed range and, if required by this TSI, have unique values – Basic parameter 4.2.9. Check of design specifications. 2d Check that there is a system identifier for ETCS part of the subsystem. In case of modification of the functional or realisation part of the system identifier, that the modification corresponds to the definition – Basic Parameter 4.2.20.3. Document check. 3 Integration of parts in the subsystem Check the interfaces and integration between the different parts of the subsystem – Table 4.1 and Basic parameter 4.2.6. Impact analysis by document checks. 4a Integration with rolling stock Check the correct installation of equipment – Basic Parameters 4.2.2, 4.2.4, 4.2.14, 4.2.18 and conditions for installation of equipment, as specified by the manufacturer. Results of checks (according to specifications referenced in the Basic Parameters and the manufacturer's installation rules). 4b Check that the Control-Command and Signalling On-board Subsystem is compatible with the rolling stock environment – Basic parameter 4.2.16. Document check (certificates of interoperability constituents and possible integration methods checked against characteristics of rolling stock). 4c Check that parameters (e.g. braking parameters) are correctly configured and that they are within the allowed range. Document check (values of parameters checked against characteristics of rolling stock). 5a Integration with Class B, depending on ETCS on-board and Class B interface Check that the standardised interface STM is connected to on-board ETCS with TSI-compliant interfaces. Nothing to test: there is a standard interface already tested at interoperability constituent level. Its functioning has already been tested when checking the integration of interoperability constituents in the subsystem. 5b Check that Class B functions implemented in the on-board ETCS– Basic parameter 4.2.6.1 – create no additional requirements for the Control-Command and Signalling Trackside Subsystem due to transitions. Nothing to test: everything has already been tested at interoperability constituent level. 5c Check that separate Class B equipment which is not connected to the on-board ETCS– Basic Parameter 4.2.6.1 – creates no additional requirements for Control-Command and Signalling Trackside Subsystem due to transitions. Nothing to test: no interface (20). 5d Check that separate Class B equipment connected on-board ETCS using (partly) non TSI compliant interfaces – basic parameter 4.2.6.1 – creates no additional requirements for the Control-Command and Signalling Trackside Subsystem due to transitions. Also check that ETCS functions are not affected. Impact analysis by document check and integration tests report. 6a Integration with Control-Command and Signalling Trackside Subsystems Check that Eurobalise telegrams can be read (scope of this test is limited to checking that the antenna has been appropriately installed. The tests already carried out at Interoperability Constituent level shall not be repeated) – Basic Parameter 4.2.5. Test using a certified Eurobalise: the ability to read correctly the telegram is the supporting evidence. 6b Check that Euroloop telegrams (if applicable) can be read – Basic Parameter 4.2.5. Test using a certified Euroloop: the ability to read correctly the telegram is the supporting evidence. 6c Check that the equipment can handle a RMR call for voice and data (if applicable) – Basic Parameter 4.2.5. Test with a certified RMR network. The ability to set up, maintain and disconnect a connection is the supporting evidence. 7a Reliability, Availability, Maintainability, Safety (RAMS) Check that the equipment complies with safety requirements – Basic Parameter 4.2.1. Application of procedures specified in the Common Safety Method for Risk Evaluation and Assessment. 7b Check that the quantitative reliability target is met – Basic Parameter 4.2.1. Calculations. 7c Check the compliance with requirements about maintenance – point 4.2.20.2. Documents check. 8 Integration with Control-Command and Signalling Trackside Subsystems and other subsystems: tests under conditions representing the intended operation. Test the behaviour of the subsystem under as many different conditions as reasonably possible representing the intended operation (e.g. line gradient, train speed, vibrations, traction power, weather conditions, design of Control-Command and Signalling trackside functionality). The test must be able to verify: (1) that odometry functions are correctly performed – basic parameter 4.2.2; (2) that the on-board Control-Command and Signalling Subsystem is compatible with the rolling stock environment – basic parameter 4.2.16. These tests must also be such as to increase confidence that there will be no systematic failures. The scope of these tests excludes tests already carried out at different stages: tests performed on the interoperability constituents and tests performed on the subsystem in a simulated environment shall be taken into account. Tests under environmental conditions are not necessary for on-board RMR voice equipment. Note: Indicate in the certificate which conditions have been tested and which standards have been applied. Reports of test runs.

6.3.3.1.   ETCS and radio system compatibility checks

The task of the NoBo with regards to the ESC/RSC check report is to verify the correctness and completeness of the ESC/RSC check report for the subsystem, according to the requirements in this point.

Since the ESC/RSC checks are not required in Table 6.2.1, they are not needed for issuing an on-board subsystem certificate. Such an on-board subsystem therefore will only be considered compatible with Class A infrastructures where no specific ESC/RSC check is required to demonstrate technical compatibility (i.e. identified by the IM as ESC-EU-0 or RSC-EU-0 in RINF).

Table 6.2.2.

NoBo assessment of the ETCS or Radio System Compatibility Check for On-Board Subsystems

No	Aspect	What to assess	Supporting evidence
1	Availability of the results	Assess that the check report gives reference to the checks according to the definition of the ESC/RSC types in the technical document published by ERA (21). Assess that all required ESC/RSC checks of that ESC/RSC type have been evaluated.	Evaluation of the ESC/RSC Check Report.
2	Availability of the results	Assess that ESC/RSC results indicate for every ESC/RSC Check whether the ESC/RSC Check was passed as specified or not.	Evaluation of the ESC/RSC Check Report.
3	Incompatibilities and errors reported	Assess that for every ESC/RSC Check which was not passed as specified, the incompatibilities and errors reported during ESC/RSC Checks are stated.	Evaluation of the ESC/RSC Check Report.
4	Impact analysis	Assess that for every ESC/RSC Check which was not passed as specified, an impact analysis of the effects on ESC/RSC has been performed and recorded using the template provided in the Appendix D.	Evaluation of the ESC/RSC Check Report.
5	Conditions	Assess that all conditions are referred to in the check report.	Evaluation of the ESC/RSC Check Report.
6	Integration of ESC/RSC Interoperability Constituent Statements	Assess that if the ESC/RSC statement is based on ESC/RSC Interoperability Constituent statements, the results from ESC/RSC Interoperability Constituent Statement are applicable to the concerned subsystem.	Evaluation of the ESC/RSC Check Report.

The Notified Body shall not check again any aspect covered during the already performed EC Verification procedure for the on-board subsystem or already covered in the ESC/RSC Interoperability Constituent Statement.

In line with the Directive (EU) 2016/797, the Notified Body performing this assessment may be a different one from the Notified Body performing the EC Verification procedure for the on-board subsystem or from the Notified Body performing the assessment on the ESC/RSC Interoperability Constituents check report.

6.3.4.   Assessment requirements for a Trackside Subsystem

The purpose of assessments carried out within the scope of this TSI is to verify that the equipment complies with the requirements stated in Chapter 4.

However, for the design of the ETCS part of the Control-Command and Signalling Trackside Subsystem, application-specific information is needed. This shall include:

(1)	line characteristics such as gradients, distances, positions of route elements and Eurobalises/Euroloops, locations to be protected, etc.;

(2)	the signalling data and rules to be handled by the ETCS system.

This TSI does not cover checks to assess whether the application-specific information is correct.

Regardless of the module chosen:

(1)	Table 6.3 shows the checks that shall be carried out to verify a Control-Command and Signalling Trackside Subsystem and the basic parameters that shall be respected;

(2)	functionality and performance that have already been checked at the level of the interoperability constituents do not require additional verification;

(3)

the update due to specifications maintenance of an already integrated Interoperability Constituent will not require additional verification by a subsystem Notified Body if the Interoperability Constituent Notified Body confirms that the impact of the update to be assessed is limited to the Interoperability Constituent and if no impact at subsystem level is identified by the CSM assessment body assessing the subsystem integration of the update. Table 6.3. Conformity assessment requirements for a Trackside Subsystem No Aspect What to assess Supporting evidence 1a Use of interoperability constituents Check that all interoperability constituents to be integrated into the subsystem are covered by an EC declaration of conformity and the corresponding certificate. Existence and content of documents. 1b Check conditions and limits of use on the use of interoperability constituents against the characteristics of the subsystem and of the environment. Impact analysis by documents check. 1c For interoperability constituents that have been certified against a version of the Control-Command and Signalling TSI, which is different from the version applied for the ‘EC’ Verification of the subsystem and/or against a set of specifications which is different from the set of specifications applied for the ‘EC’ Verification of the subsystem, check that the certificate still ensures compliance with the requirements of the TSI currently in force. Impact analysis by comparison of specifications referenced in the TSI and certificates of the interoperability constituents. 2a Integration of interoperability constituents in the subsystem Note: Only those with a specific assessment at subsystem level. Check that the internal interfaces of the subsystem have been installed properly and function properly – Basic parameters 4.2.5, 4.2.7 and conditions specified by the manufacturer. (N/A for Interoperability Constituent axle counter and Marker Boards) Checks according to specifications. 2b Check that additional functions (not specified in this TSI) do not impact the mandatory ones. (N/A for Interoperability Constituent axle counter and Marker Boards) Impact analysis. 2c Check that the values of ETCS IDs are within the allowed range and, if required by this TSI, have unique values – Basic Parameter 4.2.9. (N/A for Interoperability Constituent axle counter and Marker Boards) Check of design specifications. 2d For Interoperability Constituent axle counters (only): The integration of the Interoperability Constituent in the subsystem has to be verified: Check index 77 document Chapter 4, table 16 ‘conformity assessment’. Check the correct installation of equipment and conditions specified by the manufacturer and/or the infrastructure manager. Document check. 2e Check that there is a system identifier for the ETCS part of the subsystem. In case of modification of the functional or realisation part of the system identifier, that the modification corresponds to the definition – Basic Parameter 4.2.20.3. Document check. 3 Trackside Control-Command objects Check that requirements for marker boards specified in this TSI are fulfilled (characteristics, compatibility with the infrastructure requirements (gauge, …), compatibility with the driver’s field of view, the positioning of interoperable marker boards to meet their intended operational purpose) – Basic parameter 4.2.15. Design documentation, results of tests or test runs with TSI compliant rolling stock. 4a Integration with infrastructure Check that the ETCS, RMR and ATO equipment has been properly installed – Basic parameters 4.2.3, 4.2.4, 4.2.19 and conditions for installation specified by the manufacturer. Results of checks (according to specifications referenced in the basic parameters and manufacturer's installation rules). 4b Check that the Control-Command and Signalling Trackside subsystem equipment is compatible with the trackside environment – Basic parameter 4.2.16. Document check (certificates of interoperability constituents and possible methods of integration checked against trackside characteristics). 5a Integration with trackside signalling (not applicable for train detection part) Check that all functions required by the application are implemented in accordance with specifications referenced in this TSI – Basic parameter 4.2.3. Document check (applicant's design specification and certificates of interoperability constituents). 5b Check the correct configuration of parameters (Eurobalise telegrams, RBC messages, marker boards positions, etc.). Document check (values of parameters checked against characteristics of trackside and of signalling). 5c Check that the interfaces are correctly installed and function properly. Design verification and tests according to information supplied by the applicant. 5d Check that the Control-Command and Signalling Trackside subsystem operates correctly according to information at the interfaces with trackside signalling (e.g. appropriate generation of Eurobalise telegrams by a LEU or of message by RBC). Design verification and tests according to the information supplied by the applicant. 6a Integration with Control-Command and Signalling On-board Subsystems Check the RMR coverage – Basic Parameter 4.2.4. On site measurements. 6b Check that all functions required by the application are implemented in accordance with specifications referenced in this TSI – basic parameters 4.2.3, 4.2.4 and 4.2.5. Reports of the operational test scenarios specified in point 6.1.2 with at least two certified Control-Command and Signalling On-board Subsystems from different suppliers. The report shall indicate which operational test scenarios have been tested, which on-board equipment has been used and whether tests have been performed in laboratories, test lines or real implementation. 7 Compatibility of train detection systems (Excluding axle counters) Check that the train detection systems comply with the requirements of this TSI – Basic parameters 4.2.10 and 4.2.11. Check index 77 document Chapter 4. Check the correct installation of equipment and conditions specified by the manufacturer and/or the infrastructure manager. Evidence of compatibility of equipment from existing installations (for systems already in use); perform tests according to standards for new types. On-site measurements to prove correctness of installation. Document check of correct installation of equipment. 8a Reliability, Availability, Maintainability, Safety (RAMS) (excluding train detection) Check compliance with safety requirements – Basic Parameter 4.2.1.1. Application of procedures specified in the Common Safety Method for Risk Evaluation and Assessment. 8b Check that quantitative reliability targets are respected – Basic Parameter 4.2.1.2. Calculations. 8c Check the compliance with requirements about maintenance – point 4.2.20.2. Document check. 9 Integration with Control-Command and Signalling On-board Subsystems and rolling stock: tests under conditions representing the intended operation. Test the behaviour of the subsystem under many different conditions as reasonably feasible representing the intended operation (e.g. train speed, number of trains on the line, weather conditions). The test must be able to verify: (1) the performance of train detection systems – Basic parameters 4.2.10, 4.2.11; (2) that the Control-Command and Signalling Trackside subsystem is compatible with trackside environment – Basic parameter 4.2.16. These tests will also increase confidence in the absence of systematic failures. The scope of these tests excludes tests already done in different steps: tests performed at the level of interoperability constituents and tests performed on the subsystem in a simulated environment shall be taken into account. Note: Indicate in the certificate which conditions have been tested and which standards have been applied. Reports of test runs. 10 ETCS and radio System Compatibility The proposed ESC and RSC checks are only covering TSI requirements and are in line with the specifications – Basic Parameter 4.2.17. Document check of the envisaged ESC/RSC types in case they are new or modified. OR The technical compatibility checks for ESC and RSC Type(s) are published as ‘Valid’ in the Agency ESC/RSC technical document, if they remain unchanged.

6.4.   Provisions in case of the partial assessment of TSI requirements

6.4.1.   Assessment of parts of control-command and signalling subsystems

Pursuant to Article 15(7) of Directive (EU) 2016/797, the Notified Body may issue EC certificates of verification for certain parts of a subsystem, if allowed to do so under the relevant TSI.

As pointed out in point 2.2 (Scope) of this TSI, the trackside and on-board control-command and signalling subsystems contain parts, as specified in point 4.1 (Introduction), and this section only relates to those defined parts.

An EC certificate of verification may be issued for each part or for a combination of parts specified in this TSI.

Regardless of which module is chosen, the Notified Body shall check that the requirements (all relevant requirements as specified in Table 6.2.1) are fulfilled for:

(1)	the part in question; and

(2)	its interfaces to the unchanged parts of the subsystem; and

(3)	the integration with the unchanged parts of the subsystem.

For the CCS on-board subsystem: In any case of assessment of parts the EC certificate(s) of verification issued by the Notified Body(ies) shall consider one of the following options:

(1)	An EC certificate of verification of the CCS on-board subsystem covering all parts; or

(2)	An EC certificate of verification for each of the following groups of parts: (a) Train protection, data radio communication and automated train operation parts; and (b) Voice radio communication part.

The EC certificate of verification shall state and provide evidence on the fulfilment of all requirements in Table 6.2.1, and on possible interfaces between parts or absence thereof, in one of the following ways:

(1)	the absence of interfaces with the other part/group of parts; or

(2)

in case of interfaces with the other part/group of parts, the absence of the conditions and limits of use of the other part/group of parts. In case of interfaces that require conditions and limits of use in line with the requirements specified in the Table 6.2.1 of this TSI and that export constraints to the other part/group of parts, there shall be an EC subsystem certificate; or

(3)

in case the subsystem consists of only one part/group of parts, no additional assessment on subsystem level is necessary if the assessment of the part/group of parts covers all TSI requirements for that part/group of parts. In this case the EC certificate of verification for the part replaces the subsystem EC certificate of verification.

6.4.2.   Intermediate Statement of Verification

If conformity is assessed for subsystems specified by the applicant and different from the parts allowed in Table 4.1, and the assessment process is different from the process described in point 6.4.1 (Assessment of parts of control-command and signalling subsystems) of this TSI, or if only certain stages of the verification procedure have been performed, only an intermediate statement of verification may be issued.

6.5.   Management of errors

Where deviations from intended functions and/or performance are detected during the tests or during the operational life of a subsystem, the applicants and/or operators shall inform without delay the Agency and the authorising entity that issued the authorisations for the concerned trackside subsystems or vehicles, to initiate the procedures set out in Article 16 of Directive (EU) 2016/797. As a result of the application of Article 16(3) of that Directive:

(1)

if the deviation is due to incorrect application of this TSI or to errors in design or installation of equipment, the applicant for the relevant certificates shall take the necessary corrective actions and the certificates affected and/or the corresponding technical files (for interoperability constituents and/or subsystems), together with the corresponding EC Declarations, shall be updated;

(2)	if the deviation is due to errors in this TSI or in specifications referenced therein, the procedure set out in Article 6 of the Directive (EU) 2016/797 shall be initiated.

The applicants and/or suppliers may be applying their own solution to the identified error once the error related change request has been validated by the Change Control Management (CCM) procedure according to Article 28(2) of Regulation (EU) 2016/796. This validation shall be done within 3 months after the complete information has been submitted.

Any such temporary solution to the identified error, that does not export constraints to the other subsystem, may be applied until the agreed error correction is adopted in a new version of CCS TSI. Once a solution to the identified error is adopted in a new TSI version the applicants and/or suppliers shall apply the adopted solution to the existing vehicles according to the earlier of the following conditions:

(a)	if implementation of error correction does not require authorization: at the next occasion when error correction is mandatory by virtue of table B1.1 row 1 and in any case not before 1.1.2026;

(b)	if implementation of error correction requires authorization: at the next reauthorisation resulting from another change to the vehicle train protection (ETCS) system;

(c)	at the next upgrade to a higher system version of the vehicle train protection part.

Note:

For Interoperability constituents for which the result of the information to be provided as described in point 7.2.10.1 indicates that there is no impact regarding safety, operation and interoperability, an update is not required.

Error corrections might impact the CCS trackside and CCS on-board subsystems. The Agency shall organise an efficient processing of all the information received in order to facilitate the Change Control Management process for improvement and further development of the specifications, including the test specifications.

6.5.1.   Content of EC certificates

As per Commission Implementing Regulation (EU) 2019/250 (22) the notified bodies shall describe the restrictions and conditions for use of interoperability constituents and subsystems in the relevant EC certificates.

Notified bodies shall coordinate with the Agency the way in which errors, restrictions and conditions for use of interoperability constituents and subsystems are managed in the relevant EC certificates for verification and their accompanying technical files in the working group set up under Article 29 of Regulation (EU) 2016/796.

In the accompanying technical file issued by the NoBo the template of Appendix D shall be used.

6.5.2.   Content of EC declarations

As per Implementing Regulation (EU) 2019/250 the interoperability constituent’s manufacturer or the subsystem applicant shall describe in the EC declaration of conformity or verification the restrictions and conditions for use.

In the accompanying technical files the template of Appendix D shall be used.

7.   IMPLEMENTING THE TSI CONTROL-COMMAND AND SIGNALLING

7.1.   Introduction

This Chapter outlines the technical measures for implementing the TSI, and in particular the conditions for migrating to Class A systems.

Account must be taken of the fact that the implementation of a TSI occasionally has to be coordinated with the implementation of other TSIs.

7.2.   Generally applicable rules

7.2.1.   Upgrading or renewing the Control-Command Subsystems or parts of them

Upgrading or renewing the Control-Command and Signalling Subsystems may concern any or all of the parts constituting them, as specified in point 2.2 (Scope).

The different parts of the Control-Command and Signalling Subsystems may therefore be upgraded or renewed separately, if interoperability is not jeopardised.

See point 4.1 (Introduction) for the definition of the basic parameters for each part.

7.2.2.   Changes to an existing On-Board subsystem

This point defines the principles to be applied by the entities managing the change and authorising entities in line with the EC verification procedure described in Articles 15(9) and 21(12) and Annex IV of Directive (EU) 2016/797. This procedure is further developed in Articles 13, 15 and 16 of Implementing Regulation (EU) 2018/545 and in Decision 2010/713/EU.

This point applies in case of any change(s) to an existing on-board subsystem or on-board subsystem type, including renewal or upgrade. It does not apply in case of changes covered by Article 15(1), point (a) of Implementing Regulation (EU) 2018/545.

7.2.2.1.   Rules to manage changes in on-board CCS subsystems

(1)

Parts, as defined in Table 4.1 of this TSI, and basic parameters of the on-board subsystem that are not affected by the change(s) are exempt from conformity assessment against the provisions in this TSI. The list of parts and basic parameters affected by the change is to be provided by the entity managing the change.

(2)

The entity managing the change shall inform a Notified Body of all changes affecting the conformity of the subsystem with the requirements of the relevant TSI(s) requiring new checks, in accordance with Articles 15 and 16 of Implementing Regulation (EU) 2018/545 and Decision 2010/713/EU and by application of modules SB, SD/SF or SH1 for the EC verification, and if relevant Article 15(5) of Directive (EU) 2016/797. This information shall be provided by the entity managing the change with corresponding references to the technical documentation relating to the existing EC certificate.

(3)

The entity managing the change has to justify and document that applicable requirements remain consistent at subsystem level, and this has to be assessed by a Notified Body.

(4)

The changes impacting the Basic Design Characteristics of the on-board subsystem are defined in Table 7.1 (Basic Design Characteristics) and shall be classified as Article 15(1), points (c) or (d) of Implementing Regulation (EU) 2018/545, and in accordance with Table 7.1 (Basic Design Characteristics) changes not impacting but related to the Basic Design Characteristics shall be classified by the entity managing the change as Article 15(1), point (b) of Implementing Regulation (EU) 2018/545.

(5)

Changes not covered by point 7.2.2.1(4) above are deemed not to have any impact on the basic design characteristics. They will be classified by the entity managing the change as Article 15(1), points (a) or (b) of Implementing Regulation (EU) 2018/545. Note: The classification of the changes set out in points 7.2.2.1(4) and this point above is performed by the entity managing the change without prejudice of the safety judgement mandated in Article 21(12), point (b) of Directive (EU) 2016/797.

(6)

All changes shall remain compliant with the applicable TSIs (23) regardless its classification. Table 7.1. Basic Design Characteristics 1. TSI Point 2. Related basic design characteristic(s) 3. Changes not impacting the basic design characteristics according to 15(1)(b) of Implementing Regulation (EU) 2018/545 4. Changes impacting the basic design characteristic but inside the acceptable range of parameters therefore to be classified as Art 15.1(c) of Implementing Regulation (EU) 2018/545 5. Changes impacting the basic design characteristic and outside the acceptable range of parameters therefore to be classified as Art 15.1(d) of Implementing Regulation (EU) 2018/545 4.2.2 On-Board ETCS functionality ETCS equipment on-board and the set of specification of CCS TSI Appendix A Not applicable Not applicable Use another Appendix A set of specifications.   Envelope of legally operated ETCS system versions Not applicable Not applicable Installation or start the operational use of ETCS; Modification of the envelope of legally operated ETCS system versions from set of specifications in Appendix A.   ETCS On-board implementation Fulfilling all the conditions in point 7.2.2.2 (change of realisation identifier) Not applicable Not fulfilling all the conditions in point 7.2.2.2 (change of functional identifier)   Managing information about the completeness of the train (not from driver) Not applicable Adding or removing train integrity supervision Not applicable   Safe consist length information from on-board necessary to access the line and SIL Not applicable Adding or removing safe consist length information Not applicable 4.2.17.1 ETCS System Compatibility ETCS System Compatibility Not applicable Adding or removing an ESC statement fulfilling all the conditions in point 7.2.2.4. Adding or removing an ESC statement not fulfilling all the conditions in point 7.2.2.4. 4.2.4 Mobile communication functions for railways RMR 4.2.4.2.1 GSM-R Voice and operational communication applications GSM-R Radio voice on board and its Baseline Usage of another Baseline fulfilling all the conditions in point 7.2.2.3 Not applicable Installation or start the operational use of GSM-R cab radio; Usage of another Baseline not fulfilling all the conditions in point 7.2.2.3. GSM-R Voice and operational communication implementation Fulfilling all the conditions in point 7.2.2.3 (change of realisation identifier) Not applicable Not fulfilling all the conditions in point 7.2.2.3 (change of functional identifier) GSM-R Voice SIM Card support of Group ID 555 Not applicable Change the SIM Card support of Group ID 555 Not applicable 4.2.17.3 ETCS and Radio System Compatibility Radio Voice System Compatibility Not applicable Adding or removing an RSC statement fulfilling all the conditions in point 7.2.2.4. Adding or removing an RSC statement not fulfilling all the conditions in point 7.2.2.4. 4.2.4 Mobile communication functions for railways RMR 4.2.4.3.1.1 GSM-R data communication for ETCS 4.2.4.3.2.1 GSM-R data communication for ATO GSM-R Radio Data communication on board and its Baseline Usage of another Baseline fulfilling all the conditions in point 7.2.2.3. Not applicable Installation or start the operational use of GSM-R EDOR; Usage another Baseline not fulfilling all the conditions in point 7.2.2.3. GSM-R Data communication for ETCS and ATO implementation Fulfilling all the conditions in point 7.2.2.3 (change of realisation identifier) Not applicable Not fulfilling all the conditions in point 7.2.2.3 (change of functional identifier) 4.2.17.3 ETCS and Radio System Compatibility Radio Data System Compatibility Not applicable Adding or removing an RSC statement fulfilling all the conditions in point 7.2.2.4. Adding or removing an RSC statement not fulfilling all the conditions in point 7.2.2.4. 4.2.4 Mobile communication functions for railways RMR 4.2.4.1.1 GSM-R Basic communication function Voice SIM Card GSM-R Home Network Not applicable Replacement of a TSI compliant GSM-R SIM Card by another TSI compliant GSM-R SIM Card with a different GSM-R Home Network Not applicable Data SIM Card GSM-R Home Network Not applicable Replacement of a TSI compliant GSM-R SIM Card by another TSI compliant GSM-R SIM Card with a different GSM-R Home Network Not applicable 4.2.18 On-Board ATO functionality On-board ATO system version Not applicable Change of the ATO system version fulfilling all the conditions in point 7.2.2.3. Add or remove the ATO part of the CCS on-board subsystem; Start the operational use of ATO. Or change of the ATO system version not fulfilling all the conditions in point 7.2.2.3. On-board ATO implementation Fulfilling all the conditions in point 7.2.2.3 (change of realisation identifier) Not applicable Not fulfilling all the conditions in point 7.2.2.3 (change of functional identifier) 7.2.5 Legacy systems Class B or other train protection, control and warning legacy systems installed (system and, if applicable, version) The requirements for Class B system are the responsibility of the relevant Member State. The requirements for Class B system are the responsibility of the relevant Member State. Add or remove Class B train protection systems. The requirements for Class B system are the responsibility of the relevant Member State. Class B or other radio legacy systems installed (system and, if applicable, version) The requirements for Class B system are the responsibility of the relevant Member State. The requirements for Class B system are the responsibility of the relevant Member State. Add or remove Class B radio legacy systems. The requirements for Class B system are the responsibility of the relevant Member State.

(7)

In order to establish the EC certificate of verification, the Notified Body may refer to: (a) the original EC certificate of verification for parts of the design that are unchanged or those that are changed but do not affect the conformity of the subsystem, as far as it is still valid; (b) amendments to the original EC certificate of verification for modified parts of the design that affect the conformity of the subsystem with the applicable TSI version used for the EC verification.

(8)

In any case, the entity managing the change shall ensure that the technical documentation which is relating to the EC certificate is updated accordingly.

(9)

The updated technical documentation, related to the EC certificate is referred to in the technical file accompanying the EC declaration of verification issued by the entity managing the change for on-board subsystem declared as conformant to the modified type.

7.2.2.2.   Conditions for a change in the On-board ETCS functionality that does not impact the basic design characteristics

(1)

The target functionality (24) remains unchanged or is set to the state already expected during the original certification or authorisation. Target functionality is considered unchanged when applying the specification maintenance (error correction) process described in point 7.2.10 which includes the implementation of error corrections or the implementation of mitigation measures.

(2)

The interfaces relevant for safety & technical compatibility remain unchanged or are set to the state already expected during the original certification or authorisation.

(3)

The result of the safety judgement (e.g. safety case according to EN 50126) remains unchanged.

(4)

No new safety related application conditions (SRAC) or interoperability constraints have been added due to the change.

(5)

A CSM assessment body (CSM RA) as specified in point 4.2.1 has independently assessed the applicant’s risk assessment and within it the demonstration that the change does not adversely affect safety. The applicant’s demonstration shall include the evidence that the change actually corrects the causes of the initial deviation of the functionality.

(6)

Depending on the type of change: (a) in the case where the change is made due to a product error: The change is performed under a quality management system approved by a notified body. For other modules it shall be justified that the verification performed remains valid (25); (b) in the case where the change is made due to the specification maintenance process (there are updated specifications in Appendix A Table A 2 with the descriptions of the error correction): an updated EC design examination or EC type examination certificate for the Interoperability Constituents or Subsystem with the implementation of error corrections is needed. In this case the provisions of point 6.3.3 (3) apply.

(7)

The individual configuration management defines a ‘system identifier’ (as defined in 4.2.20.3) and the ‘functional identifier’ of the ‘system identifier’ has not been changed after the change.

(8)

The change shall be part of the configuration management required by Article 5 of Implementing Regulation (EU) 2018/545.

7.2.2.3.   Conditions for a change in the on-board mobile communication functions for railways or in the ATO on-board functionality that does not impact the basic design characteristics

(1)

The target functionality (26) remains unchanged or is set to the state already expected during the original certification or authorisation. Target functionality is considered unchanged when applying the specification maintenance (error correction) process described in point 7.2.10, which includes either the implementation of error corrections or the implementation of mitigation measures.

(2)

The interfaces relevant for technical compatibility remain unchanged or are set to the state already expected during the original certification or authorisation.

(3)

Depending on the type of change: (a) in the case where the change is made due to a product error: The change is performed under a quality management system approved by a notified body. For other modules it shall be justified that the verification performed remains valid (27); (b) in the case where the change is made due to the specification maintenance process (there are updated specifications in Appendix A Table A 2 with the descriptions of the error correction): an updated EC design examination or EC type examination certificate for the Interoperability Constituents or Subsystem with the implementation of error corrections is needed. In this case the provisions of point 6.3.3(3) apply.

(4)

The change shall be part of the configuration management required by Article 5 of Implementing Regulation (EU) 2018/545.

7.2.2.4.   Conditions for a change in the on-board subsystem regarding ETCS or Radio system compatibility that does not impact the basic design characteristics

(1)

No safety related application conditions (SRAC) or interoperability constraints related to the technical compatibility with the network have been added or removed due to the addition or removal of an ESC or RSC statement.

(2)

No interoperability constraints (restrictions or conditions for use) related to the technical compatibility with the network have been added or removed due to the ESC or RSC statement.

7.2.3.   Upgrade or renewal of existing trackside subsystem

This point defines the principles to be applied by the entities managing the change and authorising entities in line with the EC verification procedure described in Articles 15(9) and 18(6) of Directive (EU) 2016/797 and in Decision 2010/713/EU.

7.2.3.1.   Rules to manage upgrade or renewal of existing trackside CCS subsystems

In the event of upgrading or renewing the Control-Command and Signalling Subsystems bearing EC certificate of verification the following rules apply:

(1)

The changes require new authorisation if they impact basic parameters as defined in Table 7.2. Table 7.2. Trackside basic parameters modifications which requires a new authorisation Basic Parameter Modification which requires a new authorisation 4.2.3 Trackside ETCS functionality Not fulfilling all the conditions in point 7.2.3.2 4.2.4 4.2.4.2 Mobile communication functions for railways RMR Voice and operational communication applications Not fulfilling all the conditions in point 7.2.3.3 4.2.4 4.2.4.3 Mobile communication functions for railways RMR Data communication applications for ETCS and ATO Not fulfilling all the conditions in point 7.2.3.3 4.2.19 Trackside ATO functionality Not fulfilling all the conditions in point 7.2.3.3

(2)

The changes are permitted to be dealt with by only re-assessing those modifications that affect the conformity of the subsystem with the applicable TSIs version used for the EC verification. The entity managing the change has to justify and document that applicable requirements remain consistent at subsystem level, and this has to be assessed by a Notified Body.

(3)

The entity managing the change shall inform the Notified Body of all changes that may affect the conformity of the subsystem with the requirements of the relevant TSI(s) or the conditions for validity of the certificate. This information shall be provided by the entity managing the change with corresponding references to the technical documentation relating to the existing EC certificate.

(4)

An EC-Certificate reflecting the changes that affect the conformity to the TSI shall be established by a NoBo. In order to establish the EC certificate, the Notified Body may to refer to: (a) the original EC certificate for parts of the design that are unchanged or those that are changed but do not affect the conformity of the subsystem, as far as it is still valid; (b) additional EC certificate (amending the original certificate) for modified parts of the design that affect the conformity of the subsystem with the applicable TSI version used for the EC verification.

(5)	In any case, the entity managing the change shall ensure that the technical documentation which is relating to the EC certificate is updated accordingly.

(6)

‘Configuration management’ means a systematic organisational, technical and administrative process put in place throughout the lifecycle of a CCS subsystem to ensure that the consistency of the documentation and the traceability of the changes are established and maintained so that: (a) requirements from relevant Union law and national rules are met; (b) changes are controlled and documented either in the technical files or in the file accompanying the issued authorisation; (c) information and data is kept current and accurate; (d) relevant parties are informed of changes, as required.

7.2.3.2.   Conditions for an upgrade or renewal in the trackside ETCS functionality that, if not fulfilled, requires new authorisation for placing in service

(1)

The target functionality (28) of the basic parameter 4.2.3 remains unchanged or is set to the state already expected during the original certification or authorisation. Target functionality is considered unchanged when applying the specification maintenance (error correction) process described in point 7.2.10, which includes the implementation of error corrections or the implementation of mitigation measures.

(2)

The interfaces of the basic parameter 4.2.3 relevant for safety & technical compatibility remain unchanged or are set to the state already expected during the original certification or authorisation.

(3)

The result of the safety judgement (e.g. safety case according to EN 50126) remains unchanged.

(4)

No new safety related application conditions (SRAC) or interoperability constraints have been added due to the change.

(5)

When required in point 4.2.1, a CSM assessment body (CSM RA) has independently assessed the applicant’s risk assessment and within it the demonstration that the change does not adversely affect safety. In the case where the change is due to product error, the applicant’s demonstration shall include the evidence that the change actually corrects the causes of the product error.

(6)

Depending on the type of change: (a) in the case where the change is made due to a product error: The change is performed under a quality management system approved by a notified body. For other modules it shall be justified that the verification performed remains valid (29); (b) in the case where the change is made due to the specification maintenance process (there are updated specifications in Appendix A Table A 2 with the descriptions of the error correction solution): an updated EC certificate for the Interoperability Constituents or Subsystem with the implementation of error corrections is needed. In this case the provisions of point 6.3.4 (3) apply.

(7)

The individual configuration management defines a ‘system identifier’ (as defined in 4.2.20.3) and the ‘functional identifier’ of the ‘system identifier’ has not been changed after the change.

(8)

The change shall be part of the configuration management as defined in 7.2.1b.1.7.

7.2.3.3.   Conditions for an upgrade or renewal in the trackside mobile communication for railways or trackside ATO functionality that, if not fulfilled, requires a new authorisation for placing in service

(1)

The target functionality (30) of basic parameters 4.2.4.2, 4.2.4.3 and 4.2.19 remain unchanged or is set to the state already expected during the original certification or authorisation. Target functionality is considered unchanged when applying the specification maintenance (error correction) process described in point 7.2.10, which includes either the implementation of error corrections or the implementation of mitigation measures.

(2)

The interfaces of basic parameters 4.2.4.2, 4.2.4.3 and 4.2.19 relevant for technical compatibility remain unchanged or are set to the state already expected during the original certification or authorisation.

(3)

Depending on the type of change: (a) in the case where the change is made due to a product error: The change is performed under a quality management system approved by a notified body (e.g. according to modules CH1, SH1, CD, SD). For other modules (e.g. CF, SF, SG) it shall be justified that the verification performed remains valid (31); (b) in the case where the change is made due to the specification maintenance process (there are updated specifications in Appendix A Table A 2 with the descriptions of the error correction solution): an updated EC certificate for the Interoperability Constituents or Subsystem with the implementation of error corrections is needed. In this case the provisions of point 6.3.4 (3) apply.

(4)

The change shall be part of the configuration management as defined in 7.2.3.1 (6)

7.2.3.4.   Impact on the technical compatibility between on-board and trackside parts of the CCS subsystems

Infrastructure managers shall ensure that changes to an existing trackside subsystem allow the continuation of the operation of TSI compliant (32) on-board subsystems in operation on the lines concerned by the changes.

This requirement is not applicable when the changes are due to the implementation of a new level application trackside, by requirements defined in 7.2.9.1 (1) and (4), or by requirements of an incompatible application (e.g. change to a new X of M_VERSION as defined in 7.4.2.4).

7.2.4.   EC type or design examination certificates

7.2.4.1.   CCS On-Board Subsystem

7.2.4.1.1.    Definitions

(1)

Initial assessment framework for CCS On-Board Subsystem The initial assessment framework is the CCS TSI applicable at the beginning of the design phase when the notified body for the CCS on-board Subsystem is contracted by the applicant.

(2)

Certification framework for CCS On-Board Subsystem The certification framework is the CCS TSI applicable at the time of issuing the EC type or design examination certificate. It is the initial assessment framework amended with the revisions of TSIs that came into force during the design phase, and applicable as per the transition regime described in Appendix B.

(3)

Design phase for CCS On-Board Subsystem The design phase for the CCS subsystem is the period starting once a notified body, which is responsible for EC verification, is contracted by the applicant and ending when the EC type or design examination certificate is issued. A design phase covers the CCS subsystem integrated in a vehicle type and one or several type variant(s) and type version(s). For all type variant(s) and type version(s), the design phase is considered as starting at the same time as for the main type.

(4)

Production phase for CCS On-Board Subsystem The production phase is the period during which the CCS on-board subsystem may be placed on the market on the basis of an EC declaration of verification referring to a valid EC type or design examination certificate.

(5)

Vehicle in operation The vehicle is in operation when it is registered with ‘Valid’ registration code ‘00’, in the National Vehicle Register in accordance with Commission Decision 2007/756/EC (33) or in the European Vehicle Register in accordance with Commission Implementing Decision (EU) 2018/1614 (34) and maintained in a safe state of running in accordance with Commission Implementing Regulation (EU) 2019/779 (35).

7.2.4.1.2.    Rules related to the EC type or design examination certificate

(1)

The notified body shall issue the EC type or design examination certificate referring to the certification framework.

(2)

When a revision of this TSI comes into force during the design phase, the notified body shall issue the EC type or design examination certificate according to the following rules: For changes in the TSIs that are not referenced in Appendix B, conformity with the initial assessment framework leads to conformity to the certification framework. The Notified Body shall issue the EC type or design examination certificate referring to the certification framework without additional assessment. For changes in the TSIs that are referenced in Appendix B, their application is mandatory according to the transition regime defined in this Appendix B. During the defined transition period, the Notified Body may issue the EC type or design examination certificate referring to the certification framework without additional assessment. The Notified Body shall list in the EC type or design examination certificate all the points (from Table B1.1) assessed according to the initial assessment framework.

(3)

When several revisions of this TSI come into force during the design phase, the paragraph (2) above shall apply to all revisions successively.

(4)

It is always permissible (but not mandatory) to use a most recent version of any TSI, either totally or for particular points, unless explicitly otherwise specified in the revision of these TSIs; in case of application limited to particular points, the applicant has to justify and document that applicable requirements remain consistent, and this has to be approved by the notified body.

7.2.4.1.3.    Validity of the EC type or design examination certificate

When a revision of this TSI comes into force, the EC type or design examination certificate for the subsystem remains valid unless it is required to be revised according to the specific transition regime of a TSI change as defined in Appendix B of this TSI.

7.2.4.2.   CCS Trackside Subsystem

According to Article 4, point (2) of Directive (EU) 2016/797, the CCS Trackside Subsystem shall comply with the TSI in force at the time of the request for authorisation of placing in service.

When a revision of this TSI comes into force, the EC type or design examination certificate for the subsystem remains valid unless it is required to be revised according to the transition regime of a TSI change as defined in Appendix B (Table B2) of this TSI.

7.2.4.3.   Interoperability constituents

EC design or type certificates of interoperability constituents already placed on the market based on a previous version of this TSI remain valid even if a revision of this TSI comes into force, unless a requirement is applicable at CCS subsystem level which impacts the interoperability constituent (as specified in Table B1.1 or Table B2 of Appendix B) or unless explicitly otherwise specified in the revision of this TSI within Table B3 of Appendix B.

During this time, these interoperability constituents are permitted to be placed on the market without a new design or type examination.

7.2.5.   Legacy systems

Member States shall ensure that the functionality of the legacy systems and their interfaces remains unchanged, except where modifications are needed to mitigate safety-related flaws in these systems (36).

7.2.6.   Availability of Specific Transmission Modules and interfaces to Class B on-board

If trackside that fall within the scope of this TSI are not equipped with the Class A train protection system, the Member State shall ensure the availability of a Specific Transmission Module (STM) or products and/or specifications that would allow the integration of its legacy Class B train protection system with the Class A on-board system. For lines equipped with more than one Class B system, the requirement applies to at least one of these Class B systems.

The Member State shall notify within one year of the entry into force of the TSI, the Class B system (s) for which the requirement is met.

The Class B on-board and its interface, for existing products that have already demonstrated integration with Class A TSI compliant products, shall correspond to any of the technical possibilities defined in point 4.2.6.1. In the case where there is no system available that has already demonstrated integration with Class A TSI compliant on-board system, the solution made available shall be with standardised interface (STM).

The Member State shall notify the specifications of the interfaces between class A and class B on-board train protection systems within 1 year after entry into force of the TSI.

If for a particular class B system, the only solution available in the market is Class B and Class A integrated within the same equipment, the holders of the Class B specifications (e.g. supplier, railway undertaking, infrastructure manager) shall provide the specifications, for the parts they hold, necessary for integration of this Class B system with a compliant ETCS on-board. Any relevant intellectual property they hold shall be made available on a FRAND (fair, reasonable and non-discriminatory) terms basis. The holders of the specifications shall ensure the information provided is sufficient to allow other manufacturers to integrate class B with any ETCS on-board in existing rolling stock.

In this context, due regard is to be given to ensuring an open market for Class B and STM under fair commercial conditions. If, for technical or economic reasons, including applicable intellectual property rights, the availability of an STM or a Class B with its complete interface specifications to a class A system cannot be ensured, the Member States concerned shall inform the Committee referred to in Article 51(1) of Directive (EU) 2016/797 of the underlying reasons for the problem and of the mitigation measures that it intends to put into place in order to allow operators – and in particular foreign operators – access to its infrastructure.

7.2.7.   Additional Class B equipment on a line equipped with Class A

On a line equipped with ETCS and/or RMR, additional Class B trackside equipment may be installed in order to allow the operation of rolling stock not compatible yet with Class A during the on-board Class A deployment phase.

Each Infrastructure Manager shall be responsible for verifying that the trackside design supports transitions between Class A and Class B and does not impose any additional requirements to the CCS Class A on-board, thus the Control-Command and Signalling Trackside Subsystem shall be designed as if Control-Command and Signalling Class A on-board is using standardised interface (STM) between Class A and Class B systems.

7.2.8.   Vehicle with Class A and Class B equipment

Vehicle may be equipped with both Class A and Class B systems to enable operation on several lines.

The Member State concerned may restrict the use of an on-board Class B system on lines where the Class B system is not installed trackside.

A vehicle equipped with both class A and class B shall demonstrate technical compatibility with trackside Class A on lines double equipped with Class A in parallel with Class B. Being equipped with a Class B system in addition to Class A shall not be a requirement for the compatibility of a vehicle with lines where Class B is installed in parallel with Class A.

For vehicle equipped with class A, class B train protection systems may be implemented according to requirements defined in point 4.2.6.1 and following the requirements in point 7.2.6.

7.2.9.   Conditions for mandatory and optional functions

The applicant for EC verification of a Control-command and Signalling Trackside subsystem shall check whether Control-command and Signalling Trackside functions, which are defined ‘optional’ in this TSI, are required by other TSIs, national rules or by the application of risk evaluation and assessment to ensure safe integration of subsystems.

The trackside implementation of national or optional functions shall be technically compatible and not prevent the use of that infrastructure by a train that complies only with the mandatory requirements of the On-board Class A system except as required for the following on-board optional functions in point 7.2.9.1 and 7.2.9.3. The trackside implementation of one of these optional functions which leads to a new mandatory on-board requirement on specific lines shall be notified minimum 5 years before the function can become a mandatory on-board requirement. The notification of a new mandatory on-board requirement shall be done within the RINF and these changes in RINF shall be listed in the Network Statement according to Article 27 of the Directive 2012/34/EU of the European Parliament and of the Council (37). A notification period shorter than 5 years is only allowed if this is agreed between the IM and RU’s who run services or intent to run services (at the time of establishing the agreement) on these lines. This agreement on shortening the notification period shall be notified to the European Commission.

An on-board subsystem which incorporates a KER STM, may make it necessary to implement the K-interface.

7.2.9.1.   ETCS

(1)

An ETCS Level 2 Trackside application with no or reduced train detection (formerly ETCS level 3) relies on on-board information to determine track occupation and requires that the on-board is able to fulfil the requirements for confirmed train length information as specified in Appendix A, Table A 2, index 27.

(2)

An ETCS Level 1 Trackside application with infill requires that the on-board is equipped with the corresponding in-fill data transmission (Euroloop or radio) if the release speed is set to zero for safety reasons (e.g. protection of danger points).

(3)

When ETCS needs data transmission by radio, the data radio communication part as specified in this TSI is required.

(4)

When ETCS trackside needs a specific ETCS system version, the on-board shall be equipped according to the implementation requirements listed in 7.4.2.4.2.

7.2.9.2.   ATO

(1)

ATO Trackside: the trackside implementation of ATO is an optional function for interoperability which does technically not prevent the use of that infrastructure by a train that is not equipped with ATO on-board. Where ATO GoA1/2 functionality is implemented over ETCS trackside, the specifications of ATO in Appendix A of this TSI shall be applied. Note: Where ATO GoA1/2 functionality is implemented over Class B trackside, the specifications of ATO trackside in Appendix A of this TSI should be applied in order to facilitate the future migration to ATO on lines to be equipped with ETCS.

(2)

ATO on-board: the fitting of ATO in a CCS on-board Subsystem is mandatory (38) when implementing ETCS for the first time into the vehicle and the vehicle is also intended for use on a line including at least one section equipped with ATO where the IM has notified in RINF the services requiring mandatory ATO on-board implementation. Note: Where ATO GoA1/2 functionality is implemented over Class B trackside, the ATO on-board implementation is based on contractual agreements between the IM and RUs and as such there are no mandatory ATO GoA1/2 implementation requirements until ATO trackside and Class B trackside lines are migrated to a fully compliant ETCS including ATO trackside specifications in Appendix A of this TSI.

7.2.9.3.   RMR

GSM-R and/or FRMCS shall be implemented according to the implementation requirements listed in point 7.3.2.

7.2.10.   Specifications maintenance (error corrections)

7.2.10.1.   Responsibilities during the Change Control Management process

During the Change Control Management (CCM) process of the ERTMS specifications and before the entry into force of the next legal release of this TSI, errors are classified as preventing normal service or as not preventing normal service.

For the errors preventing normal service, on-board manufacturers, operators, e.g. providing input on the occurrence of the error during normal service, and infrastructure managers with the necessary input from the trackside manufacturers shall describe their products and system implementations with respect to the situation identified by answering to the ERA questionnaires (which include the resolutions of the errors and the mitigation measures).

The answers on these ERA questionnaires shall be provided within 3 months after publication of the questionnaires, in particular the Infrastructure Manager shall evaluate within the ERA questionnaire if:

(1)	the impact of the error is acceptable, as regards safety and network operation;

(2)

the impact of the error is acceptable for interoperability, this either means that: (a) the non-implementation of the trackside error correction would allow any ERTMS vehicle complying with the latest TSI release to provide normal service in the network; or (b) the non-implementation of the on-board error correction would allow that ERTMS vehicle to provide normal service in the TSI compliant network.

The Agency shall publish the results of the ERA questionnaires in a transparent manner.

7.2.10.2.   On-board and Trackside Manufacturer responsibilities

After the publication of the error corrections in a legal release, manufacturers shall update their Interoperability Constituents accordingly and are responsible for maintaining the Interoperability Constituents as requested in point 4.2.20.1 (including maintaining the associated EC Certificates) and according to the transition requirements in Appendix B (Table B3). These updated Interoperability Constituents (including the associated EC Certificates) shall be made available for integration in the concerned subsystems according to Appendix B (Table B3).

Note:

For Interoperability constituents for which the information previously provided as described in point 7.2.10.1 indicates that there is no impact regarding safety, operation and interoperability, an update is not required.

7.2.10.3.   Infrastructure Manager and Railway Undertaking responsibilities

7.2.10.3.1.    Infrastructure Manager responsibilities

In case the impact of one of the errors as described in point 7.2.10.1 is identified as unacceptable on the Infrastructure Manager’s network, the Infrastructure Manager, based on the information previously provided by on-board manufacturers within the ERA questionnaires, shall identify the ERTMS vehicles authorised to run on its network or being authorised to run on its network that have not implemented a solution which mitigates the interoperability or safety problem caused by the specification error. In case of significant impact on existing vehicles running on its network reported by on-board manufacturers (with the support of operators), the Infrastructure Manager can voluntarily decide to evaluate the implementation of temporary trackside mitigation measures in order to facilitate existing vehicles to continue their services until on-board error corrections are implemented.

The Infrastructure Manager shall register in the related RINF (39) parameter which error corrections are applicable (i.e. the errors preventing normal service in the network) for the on-board. This shall be registered at the latest 12 months after the entry into force of the TSI or shall be registered in case of new or upgrade trackside implementation within its network.

For impacted ERTMS trackside subsystems, Infrastructure Managers shall implement the relevant trackside error corrections enabling a TSI compliant CCS on-board (including on-board error correction implementation) to provide a normal service, in accordance with appendix B (Table B2) of this CCS TSI.

This Infrastructure Manager shall update -if applicable- the existing ETCS and radio system compatibility checks type (ESC/RSC) (i.e. this shall not lead to the creation of a new ESC/RSC type).

7.2.10.3.2.    Railway Undertakings responsibilities

The Railway Undertakings shall compare the error corrections registered in RINF for the area of use of the vehicle with the information previously provided as described in point 7.2.10.1 to identify the necessary error corrections to be implemented in the vehicles.

For impacted ERTMS on-board subsystems, Railway Undertakings with support of the on-board manufacturers shall implement the necessary error corrections in the CCS on-board subsystems in accordance with appendix B (Table B1.1) of this CCS TSI.

7.3.   RMR specific implementation rules

7.3.1.   Trackside installations

7.3.1.1.   The fitting of GSM-R or FRMCS is mandatory when:

(1)

installing for the first time the radio communication part of a Control-Command and Signalling Trackside Subsystem; When FRMCS is the first class A radio system on a line, conditions in 7.3.1.3 shall be respected.

(2)

upgrading the radio communication part of a Control-Command and Signalling Trackside Subsystem already in service in such a way that it changes the functions or the performance of the subsystem. This does not include the modifications deemed necessary to mitigate safety-related defects in the legacy installation;

(3)

Implementation of ETCS level 2 needs data radio communication.

(4)

Implementation of ETCS level 1 with radio infill needs GSM-R data radio communication.

7.3.1.2.   GSM-R may only be taken out of operation when the following conditions are fulfilled:

—

Condition 1: minimum notification period of 5 years where GSM-R services shall be stopped. This notification shall only be done when FRMCS on-board Interoperability Constituents’ specifications, as listed in Table 5.1 and Appendix A, are completed and published with an amendment of this CCS TSI which allows the tendering of the complete FRMCS on-board equipment. This notification shall be done within the RINF and these changes in RINF shall be listed in the Network Statement as part of Article 27 of Directive 2012/34/EU; and

—

Condition 2: FRMCS is in service; A shorter period is allowed if this is agreed between the IM and the RU’s who run services or intent to run services (at the time of establishing the agreement) on these lines. This agreement on shorter notification period shall be notified to the European Commission.

7.3.1.3.   The trackside implementation of FRMCS only, without pre-existing GSM-R, is allowed if the following condition is fulfilled:

Minimum notification period of 5 years where FRMCS services shall be in operation. This notification can only be done when FRMCS on-board Interoperability Constituents’ specifications, as listed in Table 5.1 and Appendix A, are completed and published with an amendment of this CCS TSI which allows the tendering of the complete FRMCS on-board equipment. This notification shall be done within the RINF and these changes in RINF shall be listed in the Network Statement as part of Article 27 of Directive 2012/34/EU.

A shorter period is allowed if this is agreed between the IM and the RU’s who run services or intent to run services (at the time of establishing the agreement) on these lines. This agreement shall be notified to the Commission.

7.3.2.   On-board installations

7.3.2.1.

The fitting of GSM-R in rolling stock intended for use on a line including at least one section equipped with GSM-R and not equipped with FRMCS or on a line including at least one RBC not supporting FRMCS (even if superimposed to a legacy radio communication system), is mandatory when: (1) installing for the first time the voice radio communication part of a Control-Command and Signalling On-board Subsystem; (2) upgrading the voice radio communication part of a Control-Command and Signalling On-board Subsystem already on the market (Class B) in such a way that it changes the functions or the performance of the subsystem. This does not apply to modifications deemed necessary to mitigate safety-related defects in the legacy installation;