Amendment of the CCS TSI 2019: Opportunities for higher efficiency and better quality from the on-board perspective

The introduction of the Fourth Railway Package made it necessary to align the Technical Specifications for Interoperability (TSIs) as the most important technical basis for certification and authorisation of constituents and subsystems of the railway system in the European Union with the new requirements. Amongst them, the TSI for the trackside and on-board subsystems of control, command and signalling (CCS) needed to be amended.

With the UNISIG consortium, the ETCS supply industry could participate intensively in the revision of this CCS TSI. The working groups ‘Certification and Authorisation’ (UNISIG C&A) and ‘ERTMS Stakeholder Platform subgroup Test & Certification’ (T&C) with supply industry attendance developed proposals for some specific subjects.

These suggestions are considered in the CCS TSI 2019. They are dovetailed with the new processes of the Fourth Railway Packages, especially with the requirements of Regulation (EU) 2018/545 for the authorisation of vehicles and vehicle types.

The concept of the basic design characteristics (BDC) of a subsystem plays an important role here. The extent to which the BDCs are affected decides on the impact concerning the obligation to obtain a new authorisation to create a new vehicle type version or only to consider changes in the configuration management.

UNISIG C&A proposal: Minor changes without triggering a new authorisation

UNISIG is the consortium of the leading European manufacturers of control, command and signaling equipment, which contributes significantly to the maintenance of the ETCS specification. Several UNISIG-internal working groups perform this activity under the lead of the UNISIG Super Group. The working group C&A was founded to develop harmonized supply industry positions on certification and authorisation of ETCS products for discussion with the European representative bodies of railway undertakings and infrastructure managers, the European Commission (EC) or the European Union Agency for Railways (ERA). Moreover, the discussions involved ideas on how to simplify certification and authorisation processes. The objective of the discussions was to enable fast quality improvements for systems in service and to avoid or limit restrictions for use for vehicles in operation, by eliminating unnecessary certification and authorisation processes after minor modifications on ETCS products.

The considerations were influenced by real project examples where error corrections entailed a tedious and expensive authorization process. Frequently, these cases required the fulfillment of new requirements, because after the original authorization new requirements were defined, e.g. the release of a new CCS TSI or new national requirements.

There are multiple reasons for the error correction of on-board ETCS, e.g. the complexity of ETCS.

The complexity of ETCS results from the interaction of the following requirements, which must be considered in the development of the products:

• Further development of the ETCS system specification (mainly Subset-026)
• The partly contradictory national authorization requirements (national rules (NTRs))
• Additional customer requirements (e.g. for diagnosis)
• Additional interface requirements for integration with modern vehicles
• Unexpected ways of ETCS trackside engineering.

After the implementation of standard functionality errors may result from the need to adapt the on-board ETCS to a changing environment, e.g. by reacting to the interaction with a new version of the ETCS specification or to specific demands of vehicle operators or manufacturers.

Figure 1: Overview of Control, Command and Signalling Technical Specifications for Interoperability (CCS TSI) changes

The impact of the environment on the on-board ETCS differs fundamentally from the impact on legacy national on-board ATP (national train control = NTC). Here the environment normally adapts (e.g. the train interface unit (TIU) to the train protection) to the on-board NTC rather than the other way around, among other things in order not to jeopardize existing authorization of the on-board NTC.

In addition, the ETCS system specification describes the functional requirements of ETCS but does not impose many requirements on how ETCS shall be planned and engineered. Therefore, the trackside solution of an ETCS function is possible in many different ways. To limit the solutions, the planning and engineering of ETCS is typically defined by the engineering rules of the infrastructure managers (IM) for the ETCS trackside supplier, which are inter alia oriented towards trackside topography and operational needs. But these engineering rules are IM specific, thus not harmonised on a pan-European basis and can lead to different implementations for similar operational functions.

Anticipating all possible trackside solutions is not possible in the development of an on-board ETCS, which means that unexpected behaviour of the on-board ETCS can happen on ETCS tracks where the on-board has not operated before, if these are based on different engineering rules or use other ETCS functions. A theoretical solution would be the harmonisation of engineering rules. Until now, all endeavours to achieve this have not led to a positive result. Today, this fact is taken into account by various test processes, which have to be successfully performed, before a vehicle with ETCS supervision can operate on ETCS tracks. These aspects are tackled in more depth further in this article when addressing ETCS system compatibility.

Hence not all misbehaviour of on-board ETCS is caused by bad quality management of the manufacturers as often presumed. For acceptance and the future success of ETCS, especially with reference to possible imminent big vehicle retrofit programs in Europe the railway sector shall be able to fix this misbehaviour without cumbersome certification and authorisation processes. This is especially important to quickly react to increasing cyber-security threats.

In order to resolve these challenges the working group C&A drew up a position paper over the course of several months. Based on a comprehensive analysis of the legal situation, guidelines and standards it contains a proposed solution for the introduction of changes without the need for certification and authorisation.

To facilitate this, conditions to distinguish between minor and major changes were defined. Minor modifications are those, which do not trigger a new certification and authorization. These ideas are by no means new (e.g. assessment of significance according to the criteria of Article 4 of (EU) regulation 402/2013 (CSM-RA) or according to Annex 4, EIGV (Eisenbahn-Inbetriebnahmegenehmigungsverordnung (Railway’s Authorization for Placing into Service Regulation (in Germany))) or particularly innovative, but have not been defined or incorporated into the law before in this way, especially for products and systems according to the CCS TSI.

Beside maintaining the safety level, the main condition is the evaluation of the functional impact: In case of a minor change, the target functionality remains unchanged or is set to the state already expected during the original certification or authorisation.

The evaluation of the functional impact of a change has been connected with the definition of a harmonised scheme for system identifiers (version number or label). This scheme recognises two classification criteria: Functional identifier (X). Realisation identifier (Y).

A change performed under the above-mentioned conditions does only involve a change of the realisation identifier (Y), but not the functional identifier (X). Thus, it will be possible in a uniform manner to reference the realisation identifier on certificates and authorisations only as a wildcard in such a way that, after the consideration of other conditions error corrections are possible under responsibility of the manufacturer.

Each manufacturer has to define in detail the system identifier on the basis of the scheme presented above. For example, functional and realisation identifier can be subdivided in other classification criteria, if it is necessary for the products and systems.

Figure 2: Minor modifications not triggering a new authorisation process

ERTMS stakeholder platform ‘Test & Certification’ – ETCS system compatibility (ESC)

The ERTMS stakeholder platform was founded by ERA to assure the implementation of the ERTMS European Deployment plan. Its working groups should discuss topics, which today still are an obstacle for the success of ERTMS and make proposals for solutions. The working group T&C was charged with the task of making a proposal for the above-mentioned challenge: how to deal with the different ETCS trackside implementations.

The working group was staffed by technical experts of various representative bodies (CER (European Railways), EIM (European Infrastructure Managers), UNISIG, ERTMS Users Group (EUG), vehicle owners (e.g. EPPTOLA)) and European Commission and ERA.

As mentioned above, the harmonised engineering and operational rules do not exist and they are not expected in the near future. Therefore, the working group chose as a short-term solution to accept the current diversity and to define harmonised test processes to cope with the situation of having different ETCS trackside implementations.

Especially during the implementation of the first commercial ETCS lines the compatibility between trackside and on-board ETCS was a problem. Even though the situation has improved by continuously correcting the ETCS specification, all countries have defined test processes to reveal compatibility issues between trackside and vehicles before their commercial placing into service. This shows that an action was needed.

In the first meetings the working group T&C performed an analysis of the status quo. For this purpose case studies were discussed, e.g. the experience of a vehicle project for cross-border operation between Germany and the Netherlands, including the mentioned test process to detect compatibility of ETCS. A detailed presentation of the Swiss IOP process by the Federal Office for Transport in Switzerland (FOT) was also part of the analysis.

It was found that all the processes follow the same goal, namely the identification of compatibility/interoperability issues, but are considerably differently organized. These differences in organisation and technical implementation represent a huge problem for vehicle and ETCS manufacturers especially for market entry. While in the Netherlands the IM is owner of the required test facilities and is the creator of the test specification, in Switzerland both roles are held by the ETCS trackside suppliers. Both approaches have pros and cons.

The Dutch model allows access to test facilities in a non-discriminatory manner. In addition, the test specification is freely available. A manufacturer of an on-board ETCS directly requests the IM ProRail to conduct the tests. Details on the implementation are discussed and at the end of the process a test report assessed by an independent assessor is created. Finally, ProRail draws up a final recommendation to the safety authority concerning the fitness of the on-board ETCS for authorisation.

In Switzerland a manufacturer of on-board ETCS has to request the compatibility tests from the ETCS trackside supplier, who finally submits a so-called IOP statement, with which they state that the on-board ETCS is compatible with the trackside equipped by them. The tests are performed in the test facility of the ETCS trackside supplier without the ability of the on-board ETCS supplier to get insight into the specific test cases, that will be performed. The final IOP statement can describe anything noteworthy, which has to be assessed in later stages of the authorisation process. It is attached to the technical file of a vehicle authorisation or type approval case.

The advantage of the Dutch concept is the transparency on the test specification and the non-discrimination for access to the test facility. The disadvantage could be the alleged missing testing depth: The IM specifies the test cases himself. Problematic implementation details, which perhaps are only known by the ETCS trackside supplier, might not be captured in the test cases.

The disadvantage of the Swiss approach is the missing transparency of the conducted test cases, which are property of the ETCS trackside supplier and therefore not freely available. Typically, two competitors come face to face and the on-board ETCS supplier is in the weaker position, as he cannot readily require the ETCS trackside supplier to prioritise the conduction of the tests. The key advantage of the Swiss approach is however the test depth and the efficiency. The trackside supplier knows all implementation details and can reach a better accuracy of the test results. In addition, it does not involve external verification bodies. The test result in form of the IOP statement is directly attached to the authorisation documents.

In other countries which operate ETCS varied approaches exist, which are more or less different from the aforementioned concepts.

The working group T&C also considered the European Lab Framework Agreement from 2013, which was negotiated among the UNISIG companies. It regulates the access to test facilities of competitors and describes a process, how compatibility tests can be conducted via a harmonised interface based on the UNISIG specifications Subset-110/111/112, which also allow remote connections between on-board and trackside test facilities.

In addition, the working group of the rail freight corridor 1 national safety authorities (NSA RFC1 WG) collected valuable information on compatibility tests and distributed it in their guideline.

Based on the analysis of the aforementioned information and descriptions of existing solutions, the working group T&C developed a process, which is as compatible as possible to all implemented solutions. Consistent with the aim of demonstrating the compatibility between the two subsystems on-board and trackside CCS the term ETCS system compatibility (ESC) was defined, which shall replace all existing terminology (e.g. IOP, TTSV (Track-Train-System-Validation)). A document (‘Principles for the demonstration of ESC’) containing the working group results was finished in February 2019 and handed over to ERA for further use. Previous versions already served as a basis for the CCS TSI text amendment discussion. In principle, the document includes most of the necessary terminology and stakeholder definitions required for the process.

The new process is structured as follows: The IM serves as the focal point for the performance of verifications to demonstrate ESC. The IM shall assure the availability of test facilities for the demonstration of ESC. In addition, the IM is responsible to define the set of checks, that have to be applied for an ETCS type of line (ESC type). An ESC type may be defined by 1.) the operational concept specified for the ETCS lines, 2.) the applied engineering rules and 3.) the ETCS trackside supplier. Have all the three aspects been met for different ETCS tracks, it may be concluded by the IM that they are of the same ESC type. The mentioned set of checks have to be defined for each ESC type. The objective of this approach is to minimize the number of tests by using the test result of one ETCS line for all other lines of the same ESC type. This should motivate all stakeholders to limit the diversity of ETCS in the future.

Laboratories (recommended) or actual trackside facilities can serve as test facilities for the demonstration of ESC. The test facility manager is responsible to keep a central test database, which contains all possible test cases and is implemented in the test facility.

The process starts with a request to the IM from an entity interested in an ESC statement (entity applying for ESC demonstration). This entity will be typically but not necessarily the manufacturer of an on-board ETCS. In a next step the IM reviews the substance of the available evidence (e.g. certificates of conformity) on base of which the IM draws conclusions on the basic fitness for purpose and the required scope of testing.

According to the evidences provided, the test manager defines the scope of the required checks at the on-board subsystem level, and creates a preliminary test report, which is discussed among test manager, on-board and trackside ETCS manufacturer and the IM upon completion of the test campaign. If conspicuous behaviour occurred, a distinction must be made, whether it is a failure of the trackside or on-board ETCS implementation, an error of the ETCS system specification or only a problem of the test environment. In case of an error of the ETCS system specification ERA needs to be involved to take appropriate measures, e.g. the creation of a change request (CR). ERA is also called upon if the involved parties cannot agree upon the correct result of a test case.

If the discussion will lead to a positive test report, the entity applying for ESC demonstration can draw up an ESC statement related to the checked ESC types. In addition, and if test results are representative for all possible configurations of the on-board ETCS and can therefore be re-used for other specific applications, the manufacturer of the on-board ETCS can draw up an ESC IC (interoperability constituent) statement and publish it as a complementary annex to the EC declaration of conformity of his product. This emphasises the definition of ESC as a product characteristic.

Adoption of the concepts proposed by the working groups in the CCS TSI 2019

The aforementioned suggestions of the working groups C&A and T&C are considered in the CCS TSI 2019. They are dovetailed with the new processes of the Fourth Railway Packages, especially with the requirements of Regulation (EU) 2018/545 for the authorisation of vehicles and vehicle types.

The concept of the basic design characteristics (BDC) of a subsystem plays an important role here. The extent to which the BDCs are affected, decides on the impact concerning the obligation to obtain a new authorisation to create a new vehicle type version or only to consider changes in the configuration management. The BDCs for the on-board CCS subsystem are enclosed in table 7.1 of the new CCS TSI.

Minor changes

For the minor changes process, the CCS TSI 2019 defines the BDC ‘On-board ETCS implementation’. If the extent of the modification is only regarded as minor, the BDC is not affected. This means that it can be considered as covered by Article 15 (1)b of Regulation (EU) 2018/545, without triggering a new authorisation.

If the modification is regarded as substantial, the BDC ‘On-board ETCS implementation’ is affected. In this case it triggers a new authorisation according to Article 15 (1)d of Regulation (EU) 2018/545. The differentiation of these two cases can be derived from columns 3 and 5 of table 7.1 of the CCS TSI 2019.

Which of the two cases (minor or major change) applies for the performed change, must be defined by conditions (based on C&A’s proposal) as defined for the on-board subsystem in Section 7.2.1a.2 of the CCS TSI. These conditions concerning the functionality and the basic definition for the system identifier are evaluated at this stage. Additional conditions concern the compatibility of the interfaces after the change as well as the maintenance and demonstration of the safety level, including an independent safety assessment. New safety related application conditions must not be introduced due to the change which shall be performed under a quality management system approved by a Notified Body. Finally, it must be assured that the changed configuration is managed according to Article 5 of Regulation (EU) 2018/545. The entity managing the change (also according to Regulation (EU) 2018/545) shall demonstrate and document that the applicable requirements are still fulfilled.

According to Section 7.2.1a, point 7 (and footnote 15) of the CCS TSI 2019 in case of minor modifications the CCS TSI on which the original EC verification was based can be applied. As mentioned initially, this is a very important clause, which will spare many debates in the future.

Figure 3: ESC- pre-conditions and performance

ETCS system compatibility

For ETCS system compatibility (ESC), the CCS TSI 2019 defines a BDC for the on-board CCS subsystem of the same name. In addition, the CCS TSI 2019 defines the term Radio System Compatibility for the on-board subsystem, the equivalent of system compatibility to ETCS for radio communication.

The basic principles worked out by the working group T&C were transferred into the CCS TSI 2019, however not the detailed descriptions of the process. The details will be defined later by ERA, most probably by attaching the document prepared by the T&C working group to the CCS TSI guideline as an annex. The text of the regulation is limited to pointing out the IM’s responsibility for the ESC process and to defining a little number of minimum requirements. The IMs are responsible to define the necessary set of checks for their ESC types. They must define the latter in the infrastructure register RINF. Every single ETCS line could have its own ESC type. This may be quite often the case in the introductory phase of the overall concept, but the intention is to converge towards a reduction of the number of ESC types.

The required set of checks define the ESC types according to the CCS TSI. All ETCS lines for which the same set of checks are defined comply to one ESC type.

The IMs have to provide the checks for each ESC type by 16 January 2020 to ERA. ERA has to publish these in a technical document and make it publicly available.

The CCS TSI 2019 does not define in which kind of test facility the test cases have to be performed or how the process looks in detail. Its section 6.3.3.1, point a) indicates that a notified body shall check the availability of the ESC test result for the selected are of use of the vehicle. This will be a check of completeness of all available ESC statements and a check on the fulfilment or closure of possible conditions related to the check results. This will be done on the subsystem level. According to Section 6.3.3.1, point b) the test report must refer to the checks, which are included in the aforementioned technical document of ERA. For that point, the notified body will examine whether the report indicates a result for every necessary check. In addition, the notified body must check according to Section 6.3.3.1 point c), that the result of the test report states all incompatibilities and errors occurred during the test process.

The working group T&C was of the opinion that Notified Bodies are not required in the ESC assessment process. Assessment of the test results by the IM, test manager and participating (and probably competing) manufacturers was regarded to be sufficient. The Swiss IOP process is the best evidence that the demonstration of ESC can function very well without independent assessment bodies.

The CCS TSI 2019 does not require the incorporation of Notified Bodies into the actual test process. The assessment is limited to the inspection of the test report and the examination of completeness on the subsystem level of all available ESC (IC) statements for the area of use of the vehicle. Participation of the Notified Body in ESC tests is not necessary. In addition, the assessment of ESC is not part of the EC verification. An EC certificate of verification can also be granted without the assessment of ESC, since ESC is not an inspection point of table 6.2 of the CCS TSI 2019. The mentioned ESC assessment of a Notified Body happens therefore independently from the EC conformity assessment and does not need to be performed by the same Notified Body.

The CCS TSI 2019 also emphasises that some ESC checks can be demonstrated on the level of the interoperability constituent (e.g. as stated in an ESC IC statement on the product level) to reduce the scope of the verification in vehicle projects. Therefore, points b) and c) of Section 6.3.3.1 can be performed also on the interoperability constituent level.

ESC checks are introduced to the authorization process for a vehicle via the BDC ETCS system compatibility in the CCS TSI 2019. It is specified as a value within the area of use of the vehicle defined for the vehicle authorisation. This value complies to Article 21(10)b of Directive (EU) 2016/797 and may vary according to Article 21 (12)a of the same directive. Hence, a new authorization is not required, if the change of this value is inside an acceptable range defined by the CCS TSI.

Again, the CCS TSI supports the concept of an acceptable range in table 7.1. Adding or removing of an ESC statement can be defined as a change of the value when no other modifications are introduced in the vehicle. According to table 7.1, column 4, a change on this value leads only to a change according to Article 15 (1)c of Regulation (EU) 2018/545. In this case, the addition of an ESC statement for compatibility with an ESC type leads to a new vehicle type version, but does not trigger a new authorisation. Hence, the new ESC type is to be entered as a value into the vehicle register (ERATV). According to the current interpretation of the law, this value can be left empty for the authorization process, e.g. if the area of use of the vehicle does not include an ETCS line, for which ESC could be demonstrated. A vehicle (type) authorisation is anyway possible.

Availability of the BDC ETCS system compatibility is required as part of the check of the overall route compatibility of a vehicle according to Article 23 of (EU) 2016/767 (route compatibility check (RCC)). The inspection points are included in Annex D of the TSI Operation. If a line, over which the vehicle is to pass, is classified with an ESC type, a conclusion must be drawn within the RCC, whether the entry in ERATV for the given vehicle complies with the ESC value as defined in RINF. If this is the case, the vehicle can operate on the line. If the ESC value is missing, an ESC statement according to the aforementioned process must be achieved along with the creation of a new vehicle type version with a corresponding entry in ERATV. A new authorisation is not required, as long as the vehicle and the integrated on-board ETCS correctly master the new ESC type without modifications. But even the correction of an incorrect behaviour during ESC checks may not trigger a new authorisation, if the change due to the erroneous behaviour can be classified as minor (according to the conditions set in the CCS TSI 2019). Only a major change triggers a new authorization, e.g. if a certain function must be integrated subsequently due to an unsuccessful check (e.g. missing Euroloop function).

Conclusion

Considerations of a simplified process for minor changes and the demonstration of ETCS system compatibility in the CCS TSI 2019 represent a true paradigm shift and offer opportunities to reduce cost for the introduction of ETCS, for its maintenance and for the improvement of its quality. Both contributions were developed through intense collaboration in the sector and coordinated over a period of many months. The discussions were fruitful and were characterised by the pragmatism of all the involved stakeholders.

As the article shows, the practical consequences of the modifications in the CCS TSI 2019 are not easily understandable due to the complex wording of the law. Therefore, ERA needs to bring more clarity by publishing a CCS TSI Application Guide. In the medium term, priorities should seek to improve comprehensibility of the regulations. In addition, the good cooperation among the sector organizations concerning these topics must be continued to efficiently put the new framework into practice.