Commission Implementing Regulation (EU) 2023/1695 of 10 August 2023 on the technical specification for interoperability relating to the control-command and signalling subsystems of the rail system in the European Union and repealing Regulation (EU) 2016/919 (Text with EEA relevance)

• (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 [^E0021]. 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. (¹) In this case, the assessment of the management of transitions shall be according to national specifications.

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 [^E0022]. 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.

This includes the documents referred to in the Agency ESC/RSC Technical Document.

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 train detection systems types already in use); perform tests according to standards (for new train detection systems types on the line). 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 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 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 June 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 ([^E0023]) 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 sets out the principles to be applied by the entities managing the change and authorising entities in line with the EC verification procedure described in Article 15(9) and Article 21(12) of Directive (EU) 2016/797 and Annex IV to that Directive. 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) 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 7.2.2.1(5) 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 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 in accordance with Article 15(1), point (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 changes referred in Article 15(1), point (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 changes referred to in Article 15(1), point (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 Release 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.
4.2.4 Mobile communication functions for railways RMR 4.2.4.2.1 GSM-R Voice and operational communication applications	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)
4.2.4 Mobile communication functions for railways RMR 4.2.4.2.1 GSM-R Voice and operational communication applications	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 Release 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.
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 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
4.2.4 Mobile communication functions for railways RMR 4.2.4.1.1 GSM-R Basic communication function	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.
4.2.18 On-Board ATO functionality	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.
7.2.5  Legacy systems	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 ([^E0024]) 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 ([^E0025]);

• (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 ([^E0026]) 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 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 ([^E0027]);

• (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 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

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.

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 Article 15(9) and Article 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 require 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 ([^E0028]) 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 ([^E0029]);

• (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.3.1 (6).

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 ([^E0030]) 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 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 ([^E0031]);

• (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 ([^E0032]) 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.

For any application for authorisation in conformity to type, vehicles in production phase shall meet the CCS on-board subsystem requirements after the deadline stated in the column ‘production phase’ of Tables B1.1, B1.1b, B1.2 and B1.2b. This is independent of whether the associated vehicle type design phase is completed before or after the CCS TSI entered into force.

(5) Vehicle in operation

The vehicle is in operation when it is registered with ‘Valid’ registration code ‘00’ and ‘11’, in the European Vehicle Register in accordance with Commission Implementing Decision (EU) 2018/1614 ([^E0033]) and maintained in a safe state of running in accordance with Commission Implementing Regulation (EU) 2019/779 ([^E0034]).

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)For projects in design phase by 28 September 2023, the notified body shall issue the EC type or design examination certificate according to the following rules:

• For changes in the CCS TSI introduced by this Regulation that are not listed in Appendix B, conformity with the initial assessment framework established by one of the following: Regulation (EU) 2016/919, Regulation (EU) 2016/919 as amended by Regulation (EU) 2019/776, Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/387 or Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/420, shall be deemed as 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 CCS TSI introduced by this Regulation that are referenced in Appendix B, their application is mandatory according to the transition regime defined in 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 and Table B1.1b) assessed according to the initial assessment framework.

• (3)When several revisions of this TSI come into force during the design phase, the notified body shall consider changes in the CCS TSI introduced by those revisions in the manner described in sub-paragraph (2) when issuing the EC type or design examination certificate.

• (4)It is always permissible (but not mandatory) to use a most recent version of any TSI, either totally or for particular points, unless 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

From 28 September 2023, the EC type or design examination certificate for the subsystem issued in accordance with one of the following: Regulation (EU) 2016/919, Regulation (EU) 2016/919 as amended by Regulation (EU) 2019/776, Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/387 or Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/420, remains valid unless it is required to be revised according to the specific transition regime as set out in Appendix B to this Annex.

7.2.4.2.   CCS Trackside Subsystem

In accordance with 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.

From 28 September 2023, the EC type or design examination certificate for the subsystem issued in accordance with one of the following: Regulation (EU) 2016/919, Regulation (EU) 2016/919 as amended by Regulation (EU) 2019/776, Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/387 or Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/420, remains valid unless it is required to be revised according to the transition regime as set out in Appendix B, Table B2, to this Annex.

For EC type or design examination certificate for the subsystem issued against CCS TSI versions prior to Regulation EU 2016/919, a specific gap analysis shall be performed identifying any differences between the other version of the CCS TSI and the CCS TSI established by one of the following: Regulation (EU) 2016/919, Regulation (EU) 2016/919 as amended by Regulation (EU) 2019/776, Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/387 or Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/420, within the scope of the changes proposed to the subsystem. For the differences between CCS TSI established by one of the following: Regulation (EU) 2016/919, Regulation (EU) 2016/919 as amended by Regulation (EU) 2019/776, Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/387 or Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/420, and CCS TSI established by this Regulation, they shall be managed according to the transition regime for this CCS TSI as set out in Appendix B, Table B2, to this Annex.

7.2.4.3.   Interoperability constituents

EC design or type certificates of interoperability constituents already placed on the market based on CCS TSI established by one of the following: Regulation (EU) 2016/919, Regulation (EU) 2016/919 as amended by Regulation (EU) 2019/776, Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/387 or Regulation (EU) 2016/919 as amended by Regulation (EU) 2020/420, remain valid after 28 September 2023 even if a revision of this TSI comes into force after 28 September 2023, unless a requirement is applicable at CCS subsystem which impacts the interoperability constituent (as set out in Table B1.1 and Table B1.1b or Table B2 and Table B2b of Appendix B to this Annex) or unless explicitly otherwise specified in Table B3 and Table B3b of Appendix B to this Annex.

During this transition period, 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 ([^E0035]).

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. Member States concerned shall inform the Committee no later than 1 October 2026, and shall update this information on a yearly basis.

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 ([^E0036]). A notification period shorter than 5 years is only allowed if this is agreed between the IM and RUs who run services or intend 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 shall 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 ([^E0037]) 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 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 B3b). These updated Interoperability Constituents (including the associated EC Certificates) shall be made available for integration in the concerned subsystems according to Appendix B (Table B3b).

- 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