Report on the Certification of ERTMS equipment

EUROPEAN RAILWAY AGENCY


Report on the certification of ERTMS equipment

Reference: ERA/REP/2011-08/ERTMS Document type: Report

Version : 1.0

Date : 14th April 2011


File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0-

public release version

of 51

Table of Contents

1. ABBREVIATIONS AND REFERENCES .................................................................. 4

1.1 Abbreviations .................................................................................. 4

1.2 Reference Documents ....................................................................... 5

1.3 Supporting documents ....................................................................... 6

2. INTRODUCTION........................................................................................ 7

2.1 Legal basis for the report .................................................................... 7

2.2 Working methodology ....................................................................... 7

2.2.1 Data collection .............................................................................. 7

2.2.2 ERA analysis and recommendations for improvements ............................. 8

3. THE CERTIFICATION AND PLACING IN SERVICE PROCESSES ...................................... 9

3.1 Evolution of the EU legal framework ...................................................... 9

3.2 The actors ................................................................................... 10

3.2.1 Ministry ..................................................................................... 10

3.2.2 NSA ......................................................................................... 10

3.2.3 NoBo and DeBo .......................................................................... 10

3.2.4 Assessor of the common safety methods ............................................ 11

3.3 The 3 main steps of the certification and placing in service process and its actors11

3.3.1 Step 1: Certification of an CCS IC ..................................................... 11

3.3.2 Step 2: EC declaration of verification of a CCS subsystem ....................... 12

3.3.3 Step 3: Authorisation for the placing in service of a CCS subsystem............ 13

3.4 The dependencies of the three steps on each other ................................. 13

3.5 Certificates and ISV ........................................................................ 13

4. EVOLUTION FROM THE CURRENT SITUATION TO THE TARGET SITUATION ..................... 15

4.1 The current situation ....................................................................... 15

4.1.1 The current situation in regard to step 1, certification of an IC ................... 15

4.1.2 The current situation in regard to step 2: EC declaration of verification of a

subsystem ........................................................................................... 17

4.1.3 The current situation in regard to step 3: Placing in service of a subsystem ... 18

4.1.4 Measures (regardless of the steps mentioned above) already taken by the

involved actors/organisations ..................................................................... 18

4.1.5 Actual situation in regard to certifications issued .................................... 19

4.1.6 RFU (Recommendation For Use) ...................................................... 22

4.2 The next steps to reach the target situation ............................................ 24




of 51

4.2.1 Fundamental principles .................................................................. 24

4.2.2 Actions to be performed during the migration part .................................. 24

ANNEX A (ERA QUESTIONNAIRE) ................................................................... 31

1. Documents available .................................................................... 31

2. The certification process ............................................................... 32

3. ERA actions to be taken ............................................................... 33

ANNEX B (QUESTIONNAIRE FEEDBACK) ............................................................. 34

ANNEX C (CCS CERTIFICATES ASSIGNED) ......................................................... 50




of 51

1. ABBREVIATIONS AND REFERENCES

1.1 Abbreviations

Table 1: Abbreviations

Abbreviation Definition

CCS Control-Command and Signalling

CENELEC European Committee for Electrotechnical Standardisation

(Comité Européen de Normalisation Electrotechnique)

DeBo Designated Body

DG MOVE Directorate-General for Mobility and Transport

EC European Commission

EN European Standards

ERA European Railway Agency (also referred to as Agency)

ERTMS European Rail Traffic Management System

EVC European Vital Computer

HW Hardware

IC Interoperability Constituent

ISA Independent Safety Assessors

ISV Intermediate Statement of Verifications

IM Infrastructure Manager

LEU Lineside Electronic Unit

MoU Memorandum of Understanding

MS Member State

NoBo Notified Body

NB-Rail Coordination Group of Notified Bodies

NSA National Safety Authority

NR National Rules

OTS Operational Test Scenarios

RFU Recommendation for use

RISC Railway Interoperability and Safety Committee

RS Rolling Stock

RU Railway Undertaking




of 51

Table 1: Abbreviations

Abbreviation Definition

SAC Safety relevant Application Condition

SS Subset

SW Software

TEN Trans-European Network

TSI Technical Specification for Interoperability

VK Vehicle Keeper

1.2 Reference Documents

Table 2 : Reference documents

Ref. N° Document Reference Title Last

Issue

[1] Directive 2008/57/EC Directive 2008/57/EC of the European Parliament and

of the Council of 17 June 2008 on the interoperability of

the rail system within the Community (Recast)

17 June 2008

[2] Regulation 1335/2008 REGULATION (EC) No 1335/2008 OF THE

EUROPEAN PARLIAMENT AND OF THE COUNCIL of

16 December 2008 amending Regulation (EC) No

881/2004 establishing a European Railway Agency

(Agency Regulation)

16 December

2008

[3] DV029/EN06 Commission implementing recommendation of directive

2008/57/EC of the European Parliament and of the

council of 17 June 2008 on the interoperability of the rail

system within the community “The authorisation process

of structural subsystems and vehicles under directive

2008/57/EC ”

07.01.2011

[4] 08/57 – DV34/EN03 Draft Commission Directive amending Annexes II, V

and VI of Directive 2008/57/EC of the European

Parliament and of the Council of 17 June 2008 on the

interoperability of the rail system within the Community

20.10.2010

[5] Directive 2004/49/EC DIRECTIVE 2004/49/EC OF THE EUROPEAN

PARLIAMENT AND OF THE COUNCIL of 29 April 2004

on safety on the Community’s railways

29.042004

[6] Directive 2008/110/EC DIRECTIVE 2008/110/EC OF THE EUROPEAN

PARLIAMENT AND OF THE COUNCIL of 16

December 2008 amending Directive 2004/49/EC on

safety on the Community’s railways (Railway Safety

Directive)

16.12.2008




of 51

Table 2 : Reference documents

Ref. N° Document Reference Title Last

Issue

[7] 2006/679/EC CR TSI CCS

Commission Decision concerning the technical

specification for interoperability relating to the control-

command and signalling subsystem of the trans-

European conventional rail system

28 March

2006

[8] 2006/860/EC CR TSI CCS – First modification and HS TSI CCS

Revision

Commission Decision concerning a technical



European high speed rail system and modifying Annex

A to Decision 2006/679/EC concerning the technical



European conventional rail system

7 November

2006

1.3 Supporting documents

ERA report on railway vehicle authorisation

ERA “Biennial Report on the Progress with Railway Interoperability in the European Union” 2009”

ERA_ERTMS_028528 Terms of references of the “Notified bodies ad hoc group for ERTMS

Tender ERA/2006/ERTMS/OP/01; WP4 Final Report on Analysis of interoperability problems – 14

September 2007

NB Rail presentation “Development of the ERTMS/ETCS system from NoBo perspective” (Maribor

2010)

EC presentation “Testing – corridor A – NSA meeting 02.12.2010”

EC presentation in the MoU Steering November 2010

Sintef ICT “ERTMS sub group User Guide V2011-01”

Corridor A presentation “2010-12-02 Presentation Testing of ETCS-0112” (Meeting with DG

Move/ERA on 2nd December 2011)

ERA report on railway vehicle authorisation v0.9

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:284:0001:0176:EN:PDF

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:342:0001:0165:EN:PDF




of 51

2. INTRODUCTION

2.1 Legal basis for the report

Art. 21a of EC Regulation 1335/2008 [2] states that:

7. The Agency shall evaluate the certification process of the ERTMS equipment by submitting to the Commission by 1 January 2011 a report containing, where appropriate, improvements to be made.

8. On the basis of the report referred to in paragraph 7, the Commission shall assess the costs and benefits of using a single type of laboratory equipment, a single reference track and/or a single certification body at Community level. Such certification body needs to comply with the criteria of Annex VIII of the Railway Interoperability Directive. The Commission may present a report and, if appropriate, bring forward a legislative proposal to improve the ERTMS certification system.

Though Art. 21a of EC Regulation 1335/2008 [2] requires ERA to produce a report on the

certification process of the ERTMS equipment it proved necessary to analyse the whole process

from IC certification until the authorisation for placing in service. The justification therefore can be

found in chapter 3.4 of this report.

2.2 Working methodology

2.2.1 Data collection

In a first step, a questionnaire was elaborated by ERA ERTMS Unit (see Annex A). The questionnaire

was addressed, via the representing bodies, to the actors involved in the certification and placing in

service process, namely UNISIG, CER, EIM, ERTMS test laboratories, NB Rail and NSA Focus group.

Bilateral discussions, based on the questionnaire took place with:

UNISIG, CER and EIM

NB-Rail and the NSA focus group

Beacon Rail Leasing and MRCE (Mitsui Rail Capital Europe).

NSAs Austria, Switzerland, Netherland and Germany,

NoBos EBC and Railcert,

SBB, RFI

Bombardier

A written feedback was received from the organisations listed in Annex B (Remark: Name of the

organisations not for public distribution).




of 51

The outcome of the bilateral discussions as well as the feedback from the questionnaire was taken

into account in the conclusions of the report.

The RFUs from NB Rail and the list of ERTMS related certificates from the NoBos were analysed.

2.2.2 ERA analysis and recommendations for improvements

In a second step the feedback from the questionnaire, the meetings and the analysis of the NoBo activities was put together in order to form a picture of the current situation and to evaluate the discrepancies with the target situation laid out in Directive 2008/57/EC [1] and DV 29 [3].

Finally, the Agency identified actions that can help the migration from the current situation to the intended target regime.




of 51

3. THE CERTIFICATION AND PLACING IN SERVICE PROCESSES

3.1 Evolution of the EU legal framework

With the opening of the market for rail operations and supply of goods and services it has

been necessary to put in place new rules and procedures for authorisation to reflect the fact

that the management of the railway system is now “shared” between many independent

actors, principally Infrastructure Managers (IMs) and Railway Undertakings (RUs), each

responsible for their part of the railway system under a framework of rules and procedures

put in place by MSs and EC.

Since 1996 the procedure for placing in service of the subsystems has been covered by

European Directives on interoperability. The scope of granting authorisation has

progressively been extended from the high speed Trans European Network (TEN) culminating

in the recast Interoperability Directive [1] which extends the scope of the authorisation

processes to the entire railway system. In addition Directive 2008/57/EC [1] introduces the

concept of “vehicle” authorisation and the classification of notified national rules to facilitate

wherever possible the mutual recognition of the requirements for vehicle authorisation

carried out against national rules. This concept of “Cross Acceptance” as a stepping stone to

full interoperability was initially proposed by the Sector and supported by the EC.

The Directive 2008/57/EC [1] covers the authorisation of the CCS subsystem and vehicles in

the following Articles:

10. Placing on the market of interoperability constituents;

15.Procedure for placing in service;

16.Free movement of subsystems;

17. Conformity with TSIs and national rules;

18.Procedure for establishing the ‘EC’ declaration of verification;

20.Placing in service of existing subsystems after renewal or upgrading;

The recast Interoperability Directive [1] is now supplemented by the EC Recommendation -

DV29 [3] - describing the common understanding of the procedure for authorising the

placing in service of vehicles.




of 51

3.2 The actors

The following actors are/may be involved in the certification and placing in service processes:

Ministry (MS), NSA, NoBo, DeBo, RU, IM, Vehicle Keeper (VK), Assessor of the common safety

methods, Independent Expert (IE), Competent Person (CP), Manufacturer, Contracting Entity

(CE), Specific Technical Committee, Registering Entity (RE), Temporary Technical Committee

or Technical Supervision Board, Competent Authority (CA).

This report focus on the following actors: Manufacturer, MS, NSA, NoBo, DeBo, RU and IM. A

summary of the actual situation could be found hereafter and in the Agency report on

railway vehicle authorisation.

3.2.1 Ministry

The Ministry of Transports is often the State authority for railways. In some countries, the

Ministry is also acting as NSA (e.g. EL, CH).

The Ministry acting as MSs Railway authority is responsible for:

transposing Directives into national law

enforcing National and European legislation (this is sometimes delegated to the NSA)

putting in place and notifying the NRs

designating the bodies responsible for the verification of conformity with NNRs

(DeBos)

notifying the NoBos for their MS.

3.2.2 NSA

In most, but not all, countries, the NSA is separate but under supervision of its relevant Ministry.

According to the Directive 2004/49/EC [5] art. 16.2 the NSA acts on behalf of the MS to grant the authorisation for the placing in service.

Some NSAs also grant a temporary authorisation (not foreseen in 2008/57/EC [1]) or authorisation for operation on specific lines, with restrictions.

NSAs grant the authorisation for vehicles which are already authorised in other EU/EEA

countries (“additional authorisations”) with or without testing.

Most of the NSAs accept only documentation in their national language. However, some may accept partial or complete documentation in other languages (e.g. English or any other language that the experts can understand).

3.2.3 NoBo and DeBo

Accreditation of checking bodies and verification arrangements are considerably different in

the MSs:




of 51

In six countries there are several NoBos (AT, IT, PL, LV, SL, UK)

In seven countries (ES, DE, BE, HU, PT, RO, SK) there is only one NoBo

Eight countries and Northern Ireland have not notified any NoBo (FI, BG, NI, CH, DK,

LT, IE, LU, EE)

In nine countries (UK, NL, BE, PT, FR, CZ, ES, EL, SE) the NoBos are also DeBos

In two countries (FI, NO), the DeBo is the NSA

In one country (DE) in addition to the assessment by NoBos and DeBos an additional

third party assessment must be carried out by Independent Experts (IE) who are

accredited by the NSA but are contracted by the applicant

3.2.4 Assessor of the common safety methods

The basis for the verification of fulfilment of the safety essential requirement is a safety assessment performed by an assessor of the common safety methods. The assessor of the common safety methods may or may not be a notified body himself and the same notified body may perform conformity verification with respect to safety as well as to the other essential requirements.

3.3 The 3 main steps of the certification and placing in service process

and its actors

The certification and authorisation for placing in service of a subsystem could be divided in 3

main steps:

1. EC declaration of conformity (applicant) > Certification of IC’s conformity assessed by a

NoBo

2. EC declaration of verification of a subsystem (applicant) > Certificate of verification

assessed by a NoBo

3. Authorisation for the placing in service of a subsystems (MS/NSA)

It has to be stated that the EC declarations and the authorisations for the placing in service of a CCS subsystem are separate for trackside and on-board (see 08/57 – DV34/EN03 [4]).

3.3.1 Step 1: Certification of an CCS IC

The CCS TSIs actually in force [7], [8] list in table 5.1 a the following ICs for ERTMS on-board:

ERTMS/ETCS on-board

Safety platform on-board

Safety information recorder

Odometry




of 51

External STM

ERTMS/GSM-R on-board

and in table 5.2.a for ERTMS trackside:

RBC

Radio infill unit

Eurobalise

Euroloop

LEU Eurobalise

LEU Euroloop

Safety platform trackside

According to the TSI CCS [7],[8] it is possible to combine IC’s which will then form a new IC. It has to be noted that some of the IC’s (e.g. safety platform trackside or Safety information recorder) will be removed from the TSI CCS [7],[8] and the GSM-R part will be split in voice, ETCS data and SIM card in the revised version of the TSI CCS. The certification of an IC is based on 2008/57/EC [1] and requested by the applicant who will provide an EC declaration of conformity for the IC as stated in Article 10 [1] and detailed in Annex IV [1]. The assessment of the conformity of an IC is performed by a NoBo. From ERA point of view, the purpose of the conformity assessment of a CCS IC is to verify:

that all mandatory functions applicable to the interoperability of the constituent have

been implemented,

which optional functions applicable to the interoperability of the constituent have

been implemented,

that any additional functions implemented are not in conflict with the implemented

relevant TSI CCS functions

3.3.2 Step 2: EC declaration of verification of a CCS subsystem

(2008/57/EC *1+ Article 18) In order to establish the ‘EC’ declaration of verification, the applicant shall invite the notified body that it has selected for that purpose to apply the ‘EC’ verification procedure referred to in Annex VI. The task of the NoBo selected begins at the design stage and covers the entire manufacturing period through to the acceptance stage before the subsystem is placed in service. It also covers the verification of the interfaces with the system into which it is integrated. It is the responsibility of the NoBo to compile the technical file however, the verification task of the NoBo under Directive 2008/57/EC [1] is limited to the requirements mentioned in the applicable TSIs. The certification is valid in all member states. On Subsystem level the NoBo is allowed to issue ISV.

The declaration of verification consists of two parts:




of 51

1. Integration of the CCS subsystem either into a vehicle or into a line. The NoBo has to

check that the interfaces and the assigned functionalities are working properly.

Remark: Functionalities to be certified on IC level are outside the scope of this activity.

2. Check of the compatibility between track and train

3.3.3 Step 3: Authorisation for the placing in service of a CCS subsystem

This is based on 2008/57/EC [1] Chapter IV and V under the responsibility of the MS.

As part of the authorisation for placing in service of subsystems the MS must have evidence that the technical compatibility of these subsystems with the system into which they are being integrated and in particular the safe integration of these subsystems when integrated into the systems in which they are placed. (Remark: open points should be covered by NNTR)

An authorisation granted for vehicles completely conform to all TSI by one MS is valid in all MSs without prejudice to the decisions of any other MS requiring an additional authorisation (Article 23 [1]). In the case of vehicles which do not conform to the TSI, the authorisation is limited to the network of the MS that grants it (Article 24 and 25 [1]). More details can be found in DV 29 [3].

Remark: The verification against a certified on-board is the key aspect to place a line in service and that a certified on-board will be accepted without additional tests for the entire network of a MS; this has to be ensured when the target situation is reached.

3.4 The dependencies of the three steps on each other

As the three steps must be passed in sequential order there are some dependencies. In case step 1 is not or not completely passed step 2 theoretically cannot be performed, the same is valid for the transition from step 2 to step 3. In an ideal world there would be no problem to pass all the steps, however in the field of ERTMS/ETCS the situation today is not yet optimal. Moreover, an IC certificate (step 1) does not ensure that the tested functionalities will work in step 2 or 3 because the level of the tests is different. The specifications currently referenced in the TSI CCS [7],[8] are not yet sufficient to take into account all the conditions (operational and engineering conditions of the infrastructure and on-board) occurring in steps 2 and 3. Therefore this report shall cover the whole process.

3.5 Certificates and ISV

According to 2008/57/EC [1] Annex IV chapter 3 the EC declaration of conformity of an IC shall contain among other “all the relevant descriptions met by the interoperability constituent and,

in particular, its conditions of use“. This clause could be interpreted in such a way that it is possible to issue certificates for ICs which are not fully compliant with the TSI CCS.

Remark: It is common practise to issue in this case certificates with restrictions.

In regard to the subsystem there is the possibility for a NoBo to issue ISVs in order to cover

certain stages of the verification procedure or certain parts of the subsystem (2008/57/EC [1]




of 51

Article 18 chapter 4) “The notified body may issue intermediate statement verifications to cover certain stages of the

verification procedure or certain parts of the subsystem. In such a case, the procedure set out in Annex VI shall apply.” It

has to be noted that 2008/57/EC [1] Annex VI only describes the assignment of ISV for the

completion of the 3 identified stages (design, production, testing) and does not mention at

all the issue of ISV for certain parts of the subsystem. 08/57 – DV34/EN03 [4] fills this gap

and includes now the term “certain parts” in chapter 2.2 of the updated Annex VI, moreover

the subsystem could be divided into certain parts also at the applicant’s request. As the term

“certain parts of the subsystem” is nowhere defined the applicant may have the possibility to

cut the subsystem into pieces fitting best to him. This may help for other subsystems, as e.g.

an ISV could be assigned by NoBo to the platform of a freight wagon and afterward an ISV for

adding the buffers or the constructions and so on; the use of this approach for the CCS

subsystem needs to be demonstrated.

Remark: The TSI CCS [7], [8] specifies the following parts and allows a separate migration and

certification:

1. train protection, 2. radio communication, 3. train detection. As each part could be placed in service independently, the use of ISVs for these parts seems

not to be appropriate as ISVs are seen as steps towards a placing in service of a subsystem

but not as the final certificate for this.




of 51

4. EVOLUTION FROM THE CURRENT SITUATION TO THE

TARGET SITUATION

In order to achieve compliance with the requirements of the Directive 2008/57/EC [1] there is the need to move from the current situation to the so called target situation as laid down in 2008/57/EC [1]. This migration to the target situation shall be the main focus of the future activities of the stakeholder involved.

4.1 The current situation

4.1.1 The current situation in regard to step 1, certification of an IC

The certification of an IC is based on the requirements and test specifications listed in the TSI CCS. For some IC the interface and test specifications are stable enough to ensure conformity and full functionality of the track-side and train-borne products e.g. for the Eurobalise the specification has reached nearly the level of a product standard. The situation in regard to some other ICs is different e.g. for the ERTMS/ETCS on-board and the RBC.

The tests are performed either in a manufacturer test lab or in an external independent test lab which shall be compliant with the architecture defined in SUBSET094.

1. Challenges encountered in regard to ERTMS/ETCS on-board IC certification are:

Gaps and errors in SUBSET 076

After several test campaigns with industrial products five type of errors have been detected:

editorial errors (e.g. packet 255 not included because of error in the test drafting tools used)

sequence errors (e.g. wrong assembly between test cases),

variability errors (e.g. options or set of options not taken into account),

errors related to SS-026 interpretation (e.g. wrong allocation of requirements between on board and trackside)

detected impact of other subsets (e.g. DMI specifications).

To test against SUBSET 076 a set of generic train data have been developed (SUBSET 076-6-8 - informative document). The independent test labs use 2 fixed sets to perform the test sequences, the manufacturer are using for their tests in each case project dependent parameters which can affect the test performance (Remark: It has to be checked if this lead to different test results)

Up to now several laboratories (from manufacturer or independent) are not accredited. As this accreditation is progressively being achieved more and more control about the testing procedures can be gained.

The SRS gives some room for interpretation for some of the functions specified (e.g. the interpretation if a function is assigned to trackside or to on-board sometimes




of 51

differs between test labs and manufacturer). (Remark: ERA has launched an activity to generate a common list of requirements including their assignment to trackside or on-board as part of the SUBSET 076 debugging activity).

SUBSET 076 only intends to demonstrate conformity of the on-board with the SRS, it does not cover the operational use of the ERTMS/ETCS On board subsystem. Because it does not check the trackside engineering of the line where the train will run.

SUBSET 076 is not intended to check the performance and the RAMS requirements.

Performance requirements for the test bench and the unit under test are not fixed or the selection inside a range is possible as for instance, response timers. SUBSET 076 does not check the performance (response time) of the unit under test.

SUBSET 076 does not check proprietary interfaces or protocols.

Not all mandatory functions specified in the SRS are implemented on-board either because they are judged by the implementer as not relevant (e.g. in case the on-board is only intended for L1 operation) or not relevant/required for a specific project.

2. For RBC IC certification the situation is:

The set of functions implemented are project specific

No harmonised test specification exists (SUBSET 076 targets on-board only)

Common interface specification to the interlocking does not exist

Remark: This interface is specific for every implementation. A CSM assessor verifies the design of the “national signalling”, defines the requirements for the design of the RBC (for the on-board, the standard functionality has to be assumed without exported requirements), while a NoBo ensures that the design of the RBC is not against the TSI. A specification is not needed for the IC certification but the interface has a big impact on the behaviour of the RBC which leads to the fact that a huge amount of tests can be only performed in step 2.

3. For the balise IC certification the specifications are reported as robust enough to test and provide a certificate.

4. For GSM-R the following status can be reported:

In the existing EIRENE specification one IC is clearly defined, the cab radio including the data transmission part for ETCS. The TSI CCS reflects this accordingly. As a consequence certification of cab radios not comprising all parts (voice + ETCS) is not fully defined. In practice most certified radios were voice radios without ETCS (needing a restriction for that). On the other hand NoBos have no clear rule how to perform certification for cab radios for ETCS only. Furthermore the specification in EIRENE is not fully distinctive between voice and ETCS part.

The SIM card (belonging to the network and) located in the radio module is an item hindering cross acceptance after certification of a cab radio (Certificate is restricted to




of 51

one SIM-Cab Radio combination in theory although this does not reflect reality in most cases). Additionally the specification does not clearly distinguish between SIM and cab radio functionality (e.g. requirement for certain calls)

The test criteria for the certification are not yet available for the network and must be urgently updated for the radio equipment (missing for the ETCS part)

The existing specification is not sufficiently divided in

o On-board part and trackside part

o makes no difference between constituent and authorisation

and has a definition of options, mandatory not in line with directive and TSI, especially does not distinguish between requirements for interoperability and for standardisation.

The used parameter sets in the systems are unknown (not distributed by the operator) therefore different behaviour in the networks makes certification based on tests against one network questionable. This can force the repetition of the certification in the various countries in contradiction to the idea of certificates, not mentioning cross acceptance.

Some requirements are not yet tested due to unavailability of procedure and equipment (e.g. 500 Km/h).

In the specification operational aspects and technical requirements are mixed and partly hamper an unambiguous certification. FRS and SRS are not fully matching in various requirements.

The success of the implementation of 70 000 km is based on common interpretation from early trials, very good cooperation and on the EIRENE requirements.

4.1.2 The current situation in regard to step 2: EC declaration of verification of a

subsystem

The main problems encountered in regard to the integration of an ERTMS/ETCS on-board are:

No “fully” certified on-board available (see 4.1.1)

As often not all the SRS functions are implemented and the impact on the integration into a subsystem and also train to track integration is not specified, the NoBos can evaluate the situation in a different way.

A manufacturer only implement and test functions (except for the basic functionality) which could be cross tested (train – track or track –train integration) which lead to the fact that a function which is not implemented trackside in a certain project is not implemented on-board or at least not tested in the Train –track integration)

The NoBos use different ways/depth/quality to certify the integration

As a consequence of the fact that not all the relevant functions are implemented and tested, train to track integration is only made (and valid) between a specific on-board and a specific line.




of 51

Several functions are only specified for end to end, a clear split in regard to the air gaps and IC’s involved is not made. This may differ from line to line, on-board to on-board.

4.1.3 The current situation in regard to step 3: Placing in service of a subsystem

As none of the existing on-board has a declaration to be fully compliant with the TSI CCS [7], [8] and the tests in step 2 only cover the vehicle to track tests for a specific line (or some lines already implemented) the placing in service is only valid for the lines against which the on-board is tested and for which the NSA is responsible. This leads to the situation that with each new ERTMS line in service the certified on-board has to be (till a certain extend) retested in order to achieve the permission to run on this line.

When the lines and the on-boards have not yet proven 2.3.0d compatibility, the following situation may occur therefore:

An RU has equipped its loco with ETCS and some class B systems in order to be able to run in country A, B, C and D. Country A is upgrading a line to 2.3.0d, as a result new tests for placing in service for the on-board are needed. Based on this tests it turns out that the on-board software needs to be updated. With the new software a new certificate is issued, but additional test may be necessary to check compatibility of this new software with the trackside in other countries. This situation might be repeated when another line will be upgraded to 2.3.0d.

It was reported from a manufacturer that their on-board, based on national requirements, contains 350 parameter to be individually adjusted and tested for each project; this was seen as costly and very time consuming. The analysis of ERA shows that many of the parameters were related to:

STM (which is outside the scope of the TSI CCS)

Braking aspects and SBI and EBI supervision (to be covered with the braking model)

Train interface (might be covered with the UNISIG proposal on the TIU FFFIS)

Several parameters are used to allow the maximum flexibility or to cope with the specific hard and software configuration of the manufacturer.

Nevertheless some of the parameters (probably required by the customer) are considered by ERA as not in line with the TSI CCS like level/mode inhibition, odometry accuracy margins and some other national or customised functions.

The NSAs have difficulties in monitoring the modifications made based on software changes (patches, releases, new upgrades), therefore such modifications may lead to additional tests in case of renewal or update for the placing in service.

4.1.4 Measures (regardless of the steps mentioned above) already taken by the

involved actors/organisations

NB-Rail




of 51

In order to improve the situation, the NoBos try to coordinate between each other. RFU are created and agreed by NB-Rail in order avoid possible different interpretations of the specifications and in order to harmonise the way of working.

Remark: Not all of the NoBos participate to the meetings of the ERTMS subgroup of NB-Rail and the application of the RFU is voluntary, therefore it cannot be ensured that the RFUs are understood and are applied by all the NoBos.

Corridors

The actors involved in a given corridor try to coordinate between each other. Remark: there is the risk that coordination groups between actors (especially between NSAs) without a strong supervision by EC / ERA can lead to “multilaterally” agreed solutions.

Corridor A is working on their guideline for the authorisation of the ERTMS/ETCS on-board subsystem.

ERA

ERA has generated a working group in order to correct the errors in SUBSET 076

ERA is getting feedback from the first experiences of accreditation of laboratories according to ISO 17025 (Accreditation strategy was endorsed by ERTMS MoU Steering Committee on the 19/10/2009).

ERA had contracted an activity in order to clearly allocate the functionalities to on-board and trackside

ERA has started a WG (Engineering Guidelines WG) which aimed at agreeing common engineering guidelines without modifying ERTMS/ETCS functionalities

In order to get more clarity in regard to the content of the certificates ERA is promoting Peer reviews between NoBos, in the context of the ad hoc group established according to the ERA document ERA_ERTMS_028528 (Terms of references of the “Notified bodies ad hoc group for ERTMS”).

4.1.5 Actual situation in regard to certifications issued

Certificates can be issued for IC and for subsystems. The way a product is assessed is based on the modules used; this leads to the fact that usually 2 certificates are needed. In regard to TSI CCS the following combination of certificates/modules are feasible:

For IC

Module B and module D

Module B and module F

Module H2 (design examination and quality system certificate)

For Subsystems

Module SB and module SD

Module SB and module SF




of 51

Module SH2 (design examination and quality system certificate)

Module SG only

The report (Tender ERA/2006/ERTMS/OP/01; WP4 Final Report on Analysis of interoperability problems – 14 September 2007) provides an overview of the situation in 2007. The ERA Biennial report 2009 gives the situation in 2008.

CCS interoperability constituents certificates

196 certificates for interoperability constituents and 25 requests for certification were registered on the Circa NB RAIL web site (on August 27 2007).

End of 2008 the number of certificates for TSI CCS ICs had increased to 356.




of 51

CCS subsystem certificates

In total 2 issued certificates for subsystems were registered on the Circa NB RAIL website and 45 requests for certification (on August 27 2007).

End of 2008 the number of certificates for TSI CCS subsystems has increased to 29.

This clearly shows an increase of certificates on IC and on subsystem level. The actual status (published by the NoBos) of Certificates issued can be found on the CIRCA website under:

http://circa.europa.eu/Members/irc/nbg/nbrail/library?l=/certification/notified_folders&vm=detailed&sb=Title






of 51

Here each NoBo can list its certificates assigned. Some information/examples can be found in Annex C.

There is a common NB-Rail template for listing the certificates but only a certain number of the NoBo are using it. From the information listed there it is not always possible to trace which IC or subsystem (on-board or trackside) is concerned by the certificate e.g. this could be found in the description box of the IC or subsystem (free text):

• ISoV produced to record the extent of the CCS TSI assessments made by RAL against the SD

module and to record the reservations identified as part of that scope of work. (remark: this certificate is linked to a loco)

• CTRL 1 (remark: certificate of EC verification for a line in UK (no version, no level, …)

• CFL 1.0, CH 1.1, CFL 2.0, PV 2.0, PV 3.0, PV 3.1, PV 3.3, PV 3.4, PV 3.5, PV 3.6 mit BL3.4.1 (remark: Quality system approval for an LEU)

4.1.6 RFU (Recommendation For Use)

The NoBos try to harmonise their activity among each other for CCS. This is done within the ERTMS subgroup of NB-Rail (where ERA is involved) where RFUs are discussed and agreed. The aim of the RFU is to agree on common guidelines or interpretations of the relevant specifications and processes to be applied. The list of the RFUs adopted by the NB-Rail Plenary Meeting (PM) can be found under the following link:

http://circa.europa.eu/irc/nbg/nbrail/info/data/en/information/nbrail/RFU.htm

In addition there are also draft RFUs not yet adopted by the PM.

NB-Rail Questions & Clarifications also related to RFU topics can be found under the following link:

http://circa.europa.eu/irc/nbg/nbrail/info/data/en/information/nbrail/QC.htm

In total 42 RFU were published. These adopted RFUs issued by NB-Rail before 31 January 2011 have been analysed with the following result:

22 concern other TSIs

15 concern certification issues in general

5 concern the TSI CCS

In addition, 8 draft RFUs are under discussion:

1 concerns another TSI

1 concerns certification issues in general

6 concern the TSI CCS

Adopted RFUs concerning the TSI CCS:

RFU 2-000-16 (Criteria for the NoBos to accept an ISA and its work performed)

RFU 2-400-23 (Use of SH module in the frame of the different TSI versions)

Remark: As this is linked to the TSI CCS from 2002 the RFU might become obsolete.

http://circa.europa.eu/irc/nbg/nbrail/info/data/en/information/nbrail/RFU.htm

http://circa.europa.eu/irc/nbg/nbrail/info/data/en/information/nbrail/QC.htm




of 51

RFU-CCS-030 (Use of computer tools by testing bodies which are not independent test labs)

RFU-CCS-040 (RFU lists (high level) what has to be assessed for an RBC as IC and as trackside

assembly)

Remark: In regard to IC certification the RFU is less detailed than what is specified in chapter

5.2a of the TSI CCS [7], [8]. The second part of the RFU is mainly covered by the updated

chapter 6 of the TSI CCS (to be voted June 2011).

RFU-STR-046 (How to deal with SW/HW modifications for already certified IC)

Remark: The flowchart for the certification process to be agreed by the concerned sector

organisations should replace amongst others this RFU.

(General) RFU-STR-045 (Clarification of terms in regard to standards, which might be used

differently in the directive and the TSI for the same document (no date of approval))

Remark: To be checked, result to be added in the TSI CCS application guide.

(General) WKD-STR-004 (RFU lists the directives which are relevant for the rail system)

Draft RFUs concerning the TSI CCS are:

(General) RFU-STR-xxx (HW/SW modifications in already certified subsystems)

RFU-CCS-033 (testing under full operational conditions)

Remark: RFU from 2009 and put on hold, NB-Rail is waiting the feedback from ERA. This topic

is in fact strongly related to the clarifications on the authorisation process (DV 29) that could

also make this RFU obsolete. To be noted that the term “full operational conditions” is no

more used in the revised TSI proposed by ERA (it was a wording from the old version of the

modules, now changed); in any case tests in “operational conditions” are still required before

issuing a certificate and the TSI defines their scope in chapter 6.

RFU-CCS-xxx (Access to certification test reports and other supporting documents)

Remark: RFU from 2008, trying to solve the problem of the traceability and accessibility of

documentations related to the certification.

RFU-CCS-xxx (GSM-R network certification)

Remark: RFU from 2008, there is an on-going discussion between ERA and NB-Rail to agree

on common test cases.

RFU-CCS-xxx (Recall of Subset-040 to version 2.0.0)

Remark: RFU from 2008, no NB-Rail activity on this topic, seems obsolete.

RFU-??? (Incompatibility between LEUs and balises from different manufacturers)

Remark: RFU from 2007, no NB-Rail activity on this topic, seems obsolete

RFU-??? (Reserved Items in Annex A of TSIs for CCS)




of 51

Remark: RFU from 2007, seems obsolete.

It has to be stated; that these RFUs are coping with general issues related to certification of IC’s and assemblies and are not only relevant for the TSI CCS. None of the RFUs really questions the TSI CCS and its mandatory documents.

4.2 The next steps to reach the target situation

4.2.1 Fundamental principles

The goal of ERTMS is to ensure interoperable traffic, including border crossing, allowing vehicles equipped with ERTMS/ETCS on-board to run on all lines conform to the TSI CCS. This implies technical compatibility between networks and vehicles.

The TSI CCS allows ERTMS/ETCS trackside to choose the level of application, the functions and modes implemented and the extent of their implementation. ERTMS/ETCS trackside is integrated within the existing national systems (traffic control, interlocking, train detection, line design), often overlaid to existing legacy systems and embedded in the national rules and regulations. This leads to a wide range of variations for trackside implementations.

On the contrary, the on-board ERTMS/ETCS implements all the standard functions and is able to process all the standard information packets. As an acceptable restriction of this requirement could be seen, that for certain applications (e.g. L1 only) a certified ERTMS/ETCS on-board may only have the relevant L1 functionality. In order to ensure that a certified ERTMS/ETCS on-board can run on all lines compliant with the TSI CCS the following philosophy should be applied:

In order to preserve the status quo for already existing applications; in case an existing 2.3.0d conform on-board when running on an existing 2.3.0d conform trackside encounters a problem both have to be equally treated and to demonstrate that they are compliant with the TSI CCS. This philosophy should be slightly changed for future applications. To place a new line in service a certified on-board should be used, it is assumed that in case of problems detected this shall be due to a not compliant trackside implementation. Also when to date, because of the reasons laid down in chapter 4 of this report, this is not completely feasible this philosophy should be applied from now on.

4.2.2 Actions to be performed during the migration part

In Europe when moving towards the target situation; three main areas of actions remain to be fully completed before reaching it:

• Completing the existing set of specifications and debugging the test requirements.

• Ensuring transparent certification and conformity verification especially for the on-board.

• Verifying the trackside with certified on-board against a sufficiently complete set of implemented scenarios.

4.2.2.1 Completing the existing set of specifications and debugging the test requirements.

Completing the existing set of specifications




of 51

The basis for the certification needs to be consolidated, therefore the technical specifications and the test specifications need to be completed and where applicable debugged.

For the SRS we have reached a stable status with the version 2.3.0d, the synchronisation and the update to Baseline 3 is planned and will be finalised in 2012.

For the test specification (Subset 076) the debugging for 2.3.0d and the update to Baseline 3 is contracted and the work has started. This is the most urgent activity which includes the clear assignment of the functionality either to the on-board or the trackside.

The update of the remaining TSI CCS Annex A specifications is part of the ERA Baseline 3 master plan and scheduled to be finalised at the end of 2012.

For trackside especially for the RBC, test specifications could be beneficial too. Based on the outcome of the assignment of the SRS requirements to trackside and on-board, the feedback from the Corridor A activities and the relevant issues from the implemented scenarios test requirements / scenarios for trackside need to be elaborated.

The translation need of the SRS and the other relevant documents into a formal language was analysed by ERA. Also when a big benefit was seen it would be only useful in case all the relevant specifications are translated. Having in mind the resources available it would lead to the fact that the date 2012 to finalise baseline 3 would not be met.

There is in general the situation that we have to deal with an imperfect set of documents. In order to support the work of the NoBos the relevant documents or parts of them should be identified and guidance should be given how to deal with them during the certification process.

Debugging the test requirements

The IC certificate demonstrates that a product is compliant with the ERTMS/ETCS requirements and functions. In order to improve the testing and the quality of its output the following means have to be taken:

The way how to deal with the different parameters used by the test labs and the manufacturer for the ERTMS/on-board needs to be discussed and agreed by the involved actors.

It has to be ensured that the test labs are also comparable in terms of quality and performance, therefore only accredited test labs should be used for the certification.

In order to make the tests better comparable, a common test environment in terms of interfaces should be used by the labs and any deviations from this must be listed and made public.

When working on the test specification in addition it has to be checked:

if the requirements from Subset 041 (14 parameter) could be incorporated.

for which of the variables where actually fixed values are used for the tests it is possible to ensure that the full range is tested.

which requirements on the interfaces (odometry, Euroradio, TIU, JRU) could be incorporated




of 51

In addition it has to be checked which additional tests (derived from the already implemented scenarios) could be already performed on IC level (including the trackside part). This would increase the issues to be tested on IC level.

4.2.2.2 Ensuring transparent certification and conformity verification for the on-board.

In order to ensure this (having already in mind the debugged specifications) the relevant functions have to be known and agreed by all the stakeholders and have to be specified in an unambiguous way. The process to test and check these functions needs to be described till the relevant level of detail; it has to be transparent and comparable. Traceability is the key issue, it is important to know how it was checked that a specific function is implemented. In addition the manufacturer must implement all the functions also if in absence of a real implementation some of them can only be tested on IC level, therefore:

a. Common, agreed and comparable checklists of the relevant functions and traceability to its verification are needed

b. The precise details of the roles and work performed by the different actors has to be specified

c. The manufacturer must have the means to provide products containing all the required functions

a: Common, agreed and comparable checklists.

Based on the feedback received from the questionnaire and the discussions it clearly shows that there is the need to provide and agree on the content of such checklists. They should contain where appropriate a clear assignment of the SUBSET 076 functionalities to trackside, to on-board and to the air gap which needs to be agreed by the involved actors (NoBos, test labs and manufacturer) (Remark: ERA has already contracted an activity in order to clearly allocate the functionalities). These lists would also help in short term to clearly and comparably identify all the functions which are not implemented in the current products and would lead to a better overall quality of the work performed by the NoBo.

Common and comparable checklists would ensure as a side effect that missing functions and functional additional requirements (requested by the customer) would be easily detectable and traceable.

There is the need to identify the documents which are relevant for the certification process in general and the ones which give no additional requirement for it (e.g. the ERTMS/ETCS FRS as these requirements already covered in the SRS).

As the TSI CCS today allows for the on-board different levels of implementation (e.g. L1 only) or additional optional functions (e.g. loop infill or interface K) and in addition RUs may order, driven by business cases, ETCS on-board e.g. without the STM interface, there is a need to identify, define and agree on a set of different but well defined on-board ETCS subsystems.

b: Precise details of the roles and work performed by the different actors

From a legal point of view it is not forbidden to provide certificates for ICs and subsystems not completely compliant with the TSI CCS and/or to distinguish between the 3 different




of 51

target systems (parts) described in the TSI CCS. The process, the types of certificates, the level of detail of their content and the templates to be used in order to get the outcome comparable is not clearly defined. Based on the feedback received from the questionnaire and the discussions it clearly shows that there is the need to support the work of the NoBos in this field by a “flow chart” describing all possible cases with a clear indication who is responsible and which kind of certificates (Remark: Including the use of ISV) can be given at a certain stage of the process needs to be elaborated. ERA having the mandate to provide guidance to the NoBos should chair, in close cooperation with NB-Rail and the other actors involved, this activity.

The NoBos, as described in 4.1.6, are creating RFU to harmonise their activity among each other. The analysis of the RFU shows that some of them lack completeness and parts of them seem to be obsolete. Nevertheless, concerning the certification activity and having in mind that the RFUs are only voluntary commitments, it shows that there is the need to provide more guidance in regard to:

How to make the NoBo output comparable (part of the guideline to be elaborated)

What has to be assessed and under which conditions (covered in the revised TSI CCS)

Which documents/clauses are relevant for a certain IC/assembly (covered to a certain

extent in the TSI CCS)

How to deal with HW/SW modifications for IC or assemblies including “software

management” (part of the guideline to be elaborated)

The guideline which has to be elaborated should take into account the relevant parts of the RFU adopted. Future NB-Rail TSI CCS relevant topics should be directly incorporated in the Guideline document; therefore a process should be put in place.

The list of certificates published by the NoBos should use a common template. The boxes in the template need to clearly identify the objects assessed; the type of certificate and the reservations made. This should be done where appropriate in coded text taking into account the wording in the directives and the TSI CCS.

Any deviation or lack of functionality from the specification should be clearly stated and the behaviour of the system should be very well detailed, explaining the different scenarios and the final status of the system.

c: Ensuring that the products contain all the relevant functions

It would support the activities and give more traceability when an analysis would be made in order to identify the means to be taken to ensure that the IC contains all the relevant functions.

4.2.2.3 Verifying the trackside with certified on-board against a sufficiently complete set

of implemented scenarios.




of 51

Creating a database to collect the scenarios implemented to test the on-board products against was the basic idea from the sector organisations to get confidence that the on-board can run without any problem on all existing lines. Also when this approach at a first glance looks useful and feasible it has some issues to be handled with:

Having a possibility while testing against the implemented scenarios which ensures compatibility with the existing lines may limit the effort of a manufacturer to develop a product which is fully compliant (required functions and performance) with the TSI CCS.

ERTMS/ETCS lines in service today have not yet proven that they are 2.3.0d compatible but the scenarios to be delivered should be 2.3.0d. This may lead to a significant delay.

ERTMS/ETCS on-boards have not yet proven that they are 2.3.0d compatible and that all functions are implemented.

It is not sure that the scenarios from all existing lines can be provided.

Several MSs have no or only a few ERTMS lines in operation, which means that not all scenarios needed to operate on their whole network are known to date or in the near future.

The specifications as they are today already provide all information in regard to the functionalities and the performance needed in order to develop an interoperable on-board. Also when the specifications need some fine-tuning, synchronisation and e.g. for SUBSET 076 some debugging this will not change the set of requirements known to date. Nevertheless the data base is seen as a good tool to:

Prove that the specifications are unambiguous

Identify implementations which contain national add on

Allow to prove that the trackside implementation is TSI CCS conform

Provide guidance for future implementers

Gain confidence during the migration period that the on-board can run on the lines which have provided these scenarios and when a so called “critical mass” of scenarios is reached to have confidence that the whole network is compatible with an certified on-board.

The certification of ERTMS/ETCS on-board should be based on the specifications referred in the TSI CCS; the collection of the implemented scenarios has to be seen as a supporting tool for the migration period. In order to collect a representative number of scenarios it has to be ensured that the existing ERTMS lines, when 2.3.0d compatible, provide their scenarios. The same should be the case for the ERTMS lines contracted. There is a need that the stakeholders involved agree on a process which ensures this requirement. In addition the MS or the IM must provide the “missing” (not yet implemented scenarios due to the lack of projects) scenarios in order to “complete” the set of network specific scenarios. As this part is not covered by real projects it has to be analysed how this can be ensured. This approach would guarantee that the scenarios implemented today and most of the future ones are known and could be, in order to gain confidence during the migration period, cross tested with the existing ERTMS/ETCS on-boards.




of 51

As a side effect the scenarios could help to improve, where appropriate, the engineering guidelines and could support the harmonisation of operational rules. It would limit the “legal” (national) deviations for trackside implementation or at least make them traceable and force the actors involved to create common (from functionality point of view) products.

4.2.2.4 Additional actions to be taken

Short term solutions helping the NoBo certification process

Today, because of the non-debugged Subset 076, the different interpretations of some SRS functionalities in assigning them to trackside or on-board and the implementation philosophy of the manufacturer each IC tested in a test lab has a different set of failed tests. Normally the NoBo has to check together with the lab and the manufacturer the reason for each function why the lab test has failed and/or why the on-board is still compliant with the TSI as stated by the manufacturer. In order to avoid this situation it is proposed to agree on the test cases not questioned to date which should be passed by each product in the test lab (which will be increase stepwise with the debugging of Subset 076). For the remaining not tested functions it is up to the applicant to provide the evidence that the function is implemented as specified in the TSI CCS.

GSM-R activities

In a first step the specification will be analysed and the mandatory part for interoperability separated, reviewed and updated. In addition the following activities have to be started:

Defining the requirements for

o SIM

o EDOR (ETCS DATA Only Radio)

o Roaming

Some parts are still under discussion and have to be solved:

Shunting procedure

Upgrade and classification of environmental conditions

The test cases for the new defined constituents (cab radio for voice, EDOR and SIM card) described in the new TSI and the network assessment, will be created and linked to relevant interoperability requirements.

Migration strategy to reach 2.3.0d compatibility

Comment: As mentioned in chapter 4.1.3 there is a need, also in order to avoid additional and unnecessary financial burden for the RU, to have a clear status of a coordinated European migration for trackside and on-board towards 2.3.0d compatibility

Activities to be performed under ERA lead (including the GSM-R part)

Priority Duration Activity Status

High Short term

Debugging the Subset 076 Started




of 51

High Short term

Update the Annex A documents to B3 In progress

High Short term

Introduce the need for an European test data base

Finalised, incorporated in the TSI CCS update, to be voted mid-2011.

High Short term

Provide analysis how to get more transparency

Starting in April 2011

High Short term

Provide a guideline for the certification process including detailed process description

High Short term

Create common and agreed checklists

High Short term

Consultation of interoperability requirements for GSM-R

In progress

High Short term

Preparation of test cases (GSM-R network and mobile equipment) and allocation to the relevant interoperability requirements

In progress

Medium Medium term

Elaborate additional test specifications (e. g. for RBC)

Medium Medium term

Run cyclically workshops with the actors involved to discuss and monitor the process.

Medium Short term

Provide processes to improve the exchange of information

Additional activities needed

Priority Duration Lead Activity Status

High Short term

Manufacturer Analysis regarding the means to be taken to ensure products containing all relevant functions

High Medium term

MS Upgrade the ERTMS/ETCS trackside to 2.3.0d compatibility

High Medium term

RU Upgrade the ERTMS/ETCS on-board to 2.3.0d compatibility

High Medium term

ERTMS Users Group

Create the operational test data base

Started

High Medium term

TBD Maintain the operational test data base




of 51

Annex A (ERA questionnaire)

ERA questionnaire

1. Documents available

a. Directive 2008/57/EC and 2009/131/EC and DV34 (23.9.2010)

What do you expect from the ERA report in regard to the certification process?

What is your point of view in regard to: “single type of laboratory equipment, a single reference track and/or a single certification body at Community level”

Did the directives improve the certification and placing in service process?

o If yes, why?

o If no, why?

What still need to be improved or is missing?

b. Revised TSI CCS HS&CR (to be voted in 2011)

Did the revised TSI improve the certification and placing in service process?

o If yes, why?

o If no, why?


c. DV29 version 4

Did DV29 support the IO directive in regard to placing in service the trackside subsystem and the vehicles in regard to TSI CCS?

o If yes, why?

o If no, why?


d. Module specification

Did the new Module specification cover your needs?

o If yes, why?

o If no, why?


e. Subset 076 and ERTMS/ETCS SRS

Is the document complete for 2.3.0d?

Are you aware of an active process to collect and incorporate the errors detected?

What is missing in the documents (e.g. degraded situations)?




of 51

f. ERA document “Criteria for the ERTMS Laboratories” v5

Is the document complete and useful?

Did the document needs improvement and if yes what has to be modified?

2. The certification process

What are your lessons learned in regard to certification?

Would you provide a “show case” to be incorporated in the ERA report?

Is there a need to define rules (ERA) how to deal with deviations and which deviations are acceptable with a clear definition of the impact?

Would you support that ERA is involved (informed) as soon as an applicant asks for a certificate?

How do you handle the situation that the specifications (e.g. SRS, SUBSET 076, SUBSET 040) are not jet fully synchronized?

How to deal with the situation that the interpretation e.g. of the SRS (assignment of functions to trackside, on-board and air gap) differs from manufacturer to manufacturer and to the test lab specifications?

For which subsets or interface specifications test specifications are missing?

Which documents (e.g. the ERTMS/ETCS FRS) are not useful for the certification process as the requirements could not be checked?

How to deal with the situation that there are (known) errors in the actually legalized specifications?

How do you certify that the add-on (IC and/or subsystem) are compatibility with the TSI conform part?

How do you certify that the not implemented functions will not lead to problems on-board and trackside (e. g. no SH trackside in L2 and the train send a SH request)?

What is your experience with the independent laboratories?

Is there something missing in regard to QoS for data transmission and if yes, what?

Would you support the general use of the H2/SH2 Modules (tests under control of the Manufacturers) and/or what has to be changed/added that this is acceptable for you?

How do you manage the issue of delta certification and assessment and what is missing on regulatory level?

How the test labs were used in the certification process?

Is it possible for you to certify the IC RBC or EVC?

Which split of on-board functionality you may accept in order provide a certificate (e.g. L1 only, L2/L1, no loop function, no SH mode,...)?

Are there parameter which are not clearly assignable to on-board or trackside as they cover the whole transmission chain and how do you cope with them)?




of 51

Based on what you certify a JRU?

Who is responsible for the interfaces to other TSI (chapter 4.3) and how to avoid that some work is doubled?

Which RFU you like that ERA should them incorporate in their recommendation?

Placing in service

What are your lessons learned in regard to placing in service

Would you provide a “show case” to be incorporated in the ERA report

How it can be ensured that deviations are accepted by all the NSA

What has to be improved in the NoBo certification process (e.g. harmonised template (ERA) to be applied by each NoBo, ...)

Would you support the general use of the H2/SH2 Modules (tests under control of the Manufacturers) and/or what has to be changed/added that this is acceptable for you?

Is there a need to improve/harmonise the issue of delta certification and assessment and is there something missing on regulatory level?

Would you support (actively) the harmonisation of operational rules?

Would you actively support that the “national” test cases would be published and incorporated in the test data base?

How to deal with software upgrades (patch, minor release, major release)

What is your experience with TIU information provided by ETCS and the safety level required?

3. ERA actions to be taken

Is there a need for (and what could be your support/contribution to this)?:

Splitting the ERTMS/ETCS functions in M (e.g. M for L1) and “optional” (e.g. saltwater resistant only where applicable)?

Allocating the requirements/functionalities of the ERTMS/ETCS SRS to trackside, on board or both?

Providing guidelines for the NoBo?

Steering the NoBo activities by ERA?

Harmonising of the requirements of the testing laboratories?

A flow chart describing the whole process (from manufacturing the IC till placing in service) including the tasks from the parties involved?

Closure of remaining open points (mainly former AAA1)?

Harmonising/standardising implementation rules?

Harmonising operational rules?




of 51

Annex B (Questionnaire feedback)

The migration part; Feedback from the ERA questionnaire

List and code of the contributors to the ERA questionnaire

This is the non-public part of the report

Railways:

[R1] >

[R2] >

[R3] >

Industry:

[I1] >

Sector organisations

[S1] >

Member state/NSA

[M1] >

[M2] >

[M3] >

Test Labs

[T1] >

1. Comments on available documents

a. General comments:

The process to place in service is started but it is missing in the TSI. It should be extremely convenient to guarantee the interoperability of the European Corridors. [T1]

The process as described can be used in about 10 to 20 years. How to deal during the phase of migration is missing [R1]

The process as described is a global description only without any pre-conception of the practical way forward. The conditions of applicability need to be completely defined. [S1]

The documents available are quite high level documents and need to be read in conjunction with domestic legislation and with a scope statement for a project. Worked examples of how




of 51

to apply the documentation in reality would help this in future as at present each project has to work through the detail on their own. [R3]

Instead of aiming for a “single type of laboratory equipment, a single reference track and/or a single certification body at Community level” it would be better to harmonise the requirements to those. This could also be on the level of recommendations (like DV29) or publication of best practise [R1]

A single laboratory and reference track type may assist in getting consistent authorisation of all suppliers systems. However this would need to be considered carefully in terms of country specific requirements and so may not be sufficient if it was standalone without country specific backup. This would not cope with validation of country specific NNTRs on open points or specific country requirements on non-mandated parts of the TSI. It would make these more of a challenge to be incorporated and managed appropriately in terms of the certification process through a single Certification body at Community level. A single Certification body would need to be able to have the capacity to deal with multiple projects and make sure it did not delay country specific programmes. [R3]

A single reference track is considered as not achievable due to not harmonised/ not restricted engineering rules and variety of existing operating rules in the MS. [I1]

The idea of a “golden on-board” or “golden reference track” seems to be a very ambitious idea and from our perspective it would be almost impossible to make a "golden reference track" including all possible infrastructure situations. Even if a "golden reference track" should be made, it would still be necessary to make tests in the "real world". Reference test laboratories is very useful and will be more so when a common set of test scenarios have been collected, consolidated and agreed. [M3]

Single type of laboratory is necessary if results from different tests have to be compared (i.e. to facilitate the approval of other test campaigns when placing in service a specific vehicle) [M1]; [M3]; It would seem more feasible to define an accreditation scheme for test laboratories. [M3]

We do not support the idea of a single certification body. We fear the scope for such a body will be too big, the differentially and versatility required will be too great. [M2]

According to the definition and regulation of NoBos, we understand that certification carried out by them offers the guarantee of reliability required by EU Directives, both Interoperability Directive (2008/57/EC), as well as Safety directive (2004/49/EC) and the Regulation for Accreditation and market Surveillance (2008/765/EC). Because that we consider that it is not necessary that the certification will be carried out by a single body at EU level. Although a single body is not necessary it would be desirable that an independent organisation monitors that all NoBos are working with the same policies, procedures and requirements. This organisation could be the ERA. [M2]

b. Revised TSI CCS HS&CR (to be voted in June 2011)

As the TSI is developed according to Directive 2008/57/EC the only improvement seen is the introduction of the European OTS database in chapter 6 [R1].




of 51

The addition of a requirement for a certification by an “accredited laboratory” alongside that of a NoBo does not deal with the problem of inconsistent NoBo certification and adds extra cost and complexity. Also whilst the Subset -076 for Baseline 230d is in a poor state the process of accreditation for laboratories cannot be progressed. [S1]

The deletion of CENELEC standards 50126, 8 and 9 as mandatory standards from Annex A of the TSI is not acceptable as their status solely as harmonised standards could give rise to their mandatory status being diluted, to the detriment of the production of safety software for railway (ERTMS SIL 4) applications. [S1]

We believe that a great deal of clarification has been made which will improve the process. [M2] it has now a better structure, it clarifies the interfaces between subsystems, the maintainability requirement and the list of components [M1] (Remark: detailed comments for improvement of the TSI can be found in the feedback from [M1])

c. DV29 EN05

There is still the problem that the DV29 describes the target situation only. [R1]

The document just seemed to provide another level of detail to understand and apply rather than simplify the way to introduce the system. Some worked examples may help in this area. [R3]

The document DV29 is a good guideline, which simplifies and explains the authorization process for the placing in service of structural subsystems and vehicles. It also explains the division of placing a subsystem in service (part of the authorization), and maintaining a subsystem already placed in service (part of the SMS). Missing is the use of ISC (Interim Statement of Conformity), and an explanation of how the KMS (Key Management System) is intended to work. [M2]

The DV29 document is seen as a very useful guide to interoperability. The effect on projects still remains to be seen. [M3]

Remark: Sweden has used ISC (Interim Statement of Conformity, RFU 0-000-17, issue 01) for issuing conformity assessment statements for e.g. safety issues. An ISV is not suitable for that type of conformity assessment because it can only be issued for certain defined “stages” (even though DV34 states that it also can be used for “parts” of the subsystem).

DV 29 is an improvement to specify more clearly the process of authorisation to put into service and the roles and responsibilities of each entity involved, but [M1]:

It should be more detailed the process for authorizing to place in service: how to check the safe integration of train-track [M1]

In the new model the IM should only maintain the infrastructure and the RU is responsible for ensuring the compatibility of its trains with the infrastructure. This will be based on the information contained in the RINF which is not yet operative. This new model is nowadays a theoretical model and we think that will not be applicable in a near future. A trial period where we could check the efficiency of using the RINF for the verification of the technical compatibility should be established [M1]

DV 29 is a declaration in the good direction. It addresses the need for a better policy for certification and placing in service that guarantees interoperability. It needs to be




of 51

accompanied by additional directives to place projects in service and by the review of the existing ones (on the way) [T1]

d. Module specifications

The module specification did not cover the needs as there are global requirements which do not lead to traceable and comparable documentation. In order to identify what is missing EN 50126 to 50159 should be examined. There is the need of harmonised procedures and agreed templates: [R1]

Make a safety plan including all the responsibilities [R1]

Take over the requirements for a safety case [R1]

Check all the documents where the requirements are fulfilled [R1]

The new module specification covers our needs in the same way as the previous one. [M2]

The new module specification is an improvement but: [M1]

The tools for the NoBo to verify that the laboratories where the tests are performed are equipped with reference tools (e.g. labs in the suppliers companies) should be included [M1].

It should also be clarified the process to deal with the interfaces between subsystems when there are different NoBos involved in the certification.[M1]

In regard to the modules to be followed in the certification process our advice should be to restrict the use of the module H, eventually to suppress it. [T1]

e. Subset 076

The document needs urgently to get debugged. [R1], [S1], [M2]

A train could be placed in safe operation without SUBSET 076 compliance but not without full without full track specific OTSs compliance because [R1]:

It’s only a test for the specification but these specifications are not consolidated and not consistent [R1]

It’s only a one path test to check all the functions not all functionalities.*R1+

The tests by subset 076 does not matches the real operations [R1]

As long as the operational rules are different or a set of agreed common scenarios are not available subset 076 is a nice to have [R1]

Analysis of the OTS from the Database would help to close gaps not a short term issue! [R1]

SUBSET 076, known errors are yet not incorporated [R3]

The Version 2.3.1 of SUBSET 076 is not ready to be a full test specification, because there are still too many errors included. [I1]

There is a process for correcting the errors, but it is not really public. Instead of updating the SUBSET 076 Test Specifications only in determined time periods, there shall be a continuous updating process of the SUBSET 076; otherwise there will never be stable test specification. For getting this into reality there shall be an additional change control management board




of 51

for the SUBSET 076 under the leadership of the independent test laboratories, instead of working with excel tables sent around by mail. [I1]

In addition the following important issues have to be implemented:

There is the need for a functional separation of the sequences, providing the chance of delta testing for small software changes. To avoid a full test of about 3 Months for every small software update [I1]

There is the need for a separation of the optional functions (according to the FRS) [I1]

There is the need to shorten the test sequences to a maximum of 15-20 minutes running time [I1]

In case the document is debugged it will be sufficient for on board IC test [M1]

f. ERA document “Criteria for the ERTMS Laboratories” v5

The requirements in the document seem just formal and not related to specific technical or process requirements/arrangements – it is therefore not clear if the document is already useful (to be checked) [R1]

The document is incomplete and not really useful and there are real issues about the practicality of becoming accredited. [S1]

The document needs some work and revisions before it can be issued, and formally agreed upon. Consolidate some parts in the document to clearly lead the users (MS/IM) in the planning and decisions for selecting test activities, scope and precondition for this. [R2] Remark: Detailed comments could be found in the feedback from [M2]

The use of the SRS 2.3.0 d is difficult due that it is a Subet-026 v 2.3.0 + Subset-108 v 1.2.0, i.e. the final written sentence of a requirement is not readable at once. [T1]

2. Certification process

a. What are your lessons learned in regard to certification?

At each Certificate it is unclear what is checked and where the open requirements are or which one has do check again. If there are SAC then it is unclear what´s the reasons are. [R1]

The certification process:

takes a considerable amount of time and needs to be de-linked from a commissioning date. [R3]

it has highlighted inaccuracies and inconsistencies in the current versions of the TSI [R3]

it has shown that our supplier does not have versions of software that are currently 100% compliant to the TSI [R3]

it has shown that an ERTMS system can have a safety case to show that it is safe and operable despite it not being 100% compliant to the TSI [R3]

it has shown that the authorisation into service process is not well understood and where as it is acceptable to enter into service in some countries with deviations, this is not possible in all countries [R3]




of 51

it has added cost and delay to the project but at this point in time not seemed to have added value [R3]

It would be useful to give specific examples of how real life differs from theory. [S1]

In the moment it is not possible to get a full certificate of conformity, not even in theory. However, all certification procedures and regulations are based on exactly this. This is a situation that is from our point of view not acceptable. [I1]

Some specific items have been collected in order to improve Ss076 (e.g. the consistency and coherency, applicability to real on-board units, like temporal behaviour or braking behaviour as well as the process, tools and formats for the evaluation). The major part of the future test specification is that it has to become more flexible and modular. [T1]

b. Return of experience from [M1]

Open points sometimes are difficult to assess because of a lack of national rules [M1]

The final report that accompanies the certificate does not follow a standard format. It should be harmonized to easily understand the non compliances / restrictions and their impact. [M1]

Through the verification process it has been clearly shown the need for improvement of the technical specifications [M1]

Some specifications are missing, e.g.- RBC tests [M1]

The versions of the documents in Annex A of TSI have not been consistent in some of its releases (included specifications from different baselines). [M1]

The certification is a long process and sometimes an update of Annex A has happened in between. It is not clear what to do in this case. [M1]

There is not a univocal relationship between CCS TSI Annex A releases and ERTMS baselines. [M1]

There is not easy access to the change requests that are not classified in subset 108 so it is not possible to check that they are being implemented in the way they should be. Specially with CR ‘dc’ *M1+

The certification process should start at the beginning of the project. Often NoBos are not contacted until the subsystem is already installed and it is too late. [M1]

The certificate should be available prior to the start of the placing into service process. [M1]

We found that because the requirements to asses are not closed (functionality has been changing in the last years, Safety is an open point, there are not stable "validated" systems for reference, etc) it is required some evidence of train - track integration, additional to the certification. For that, some field tests have been designed. The field trials could be reduced promoting laboratory tools for independent verification and validation of the field trials providing physical and human resources and defining the reference and test procedures. [M1]

At the moment the Spanish experience in lab is mainly with L1 and it has proven very useful. Tests have been performed for the Commuter lines in Madrid. The trackside involves two




of 51

different suppliers. Tests have been performed with the TSD and real cabs. For Madrid-Valencia line tests were performed with two different Eurocabs.

c. Is there a need to define rules (ERA) how to deal with deviations and which

deviations are acceptable with a clear definition of the impact?

Yes this would be extremely helpful [R3], [I1]

Yes, in principle; it has to be dealt with in a harmonised manner (e.g. Level 1 EVC is not permitted by the TSI but it is envisaged in the SRS). [S1]

Yes, until there will be a specification without mistakes, it would be good to define acceptable levels of deviation from the TSI. This will have to be done with the NoBos collaboration. [M1]

d. Would you support that ERA is involved (informed) as soon as an applicant

asks for a certificate?

This might help if it was clear that how this would add value to the process. It would be helpful if it could speed up the authorisation by the National Safety Authorities (NSA) and simplify NoBo activities. [R3]

No, why should ERA be involved. What would ERA do with such information [S1], [I1]

With the knowledge and experience we have today we think the use of the Notified Body in the Certification process should be enough. [M2]

Yes, ERA should monitor the NoBos. In that way the certification process will be harmonized. [M1]

e. How do you handle the situation that the specifications (e.g. SRS, SUBSET 076,

Subset 40) are not jet fully synchronized?

Through lots of discussions between supplier, NoBo, NSA, member state. Deviations are generated by the NoBo which then have to be managed through a deviations process with the NSA and member state. [R3]

Bilateral discussion with NoBo who in turn will clear with NSA. [S1]

Sweden: So far this is handled by the Infrastructure Manager, Trafikverket. Trafikverket follows the current specifications and if there are deficiencies, Trafikverket in co-operation with their suppliers, examines them and selects “best practice”. The NoBo is asked to confirm that Trafikverkets understanding is valid. This is done in order to render progress in the projects possible, but the consequence is that selected ”solutions” in many cases makes interoperability impossible, and prevents all possibilities of ”plug and play”. The consequence of the deficiencies in specifications will result in major costs in the future due to changes and adaptations of the products

When having the situation that two specifications are not fully synchronized, with each other then the most priority has the SUBSET108 and the SUBSET026. Such differences are clearly




of 51

stated in the subset conformity verification reports. For example the SUBSET033/034 are also not harmonised with the SRS(SUBSET026), therefore these specifications are only partly compliant and wrong references are clearly shown in verification reports. [I1]

The manufacturer justifies the compliance, not compliance or failure to comply with certain requirements, motivated by the errors founded in these documents. [M1]

This was one of the issues for defining the complementary tests. The situation is handled through the analysis of the deviations. Deviations are accepted if it does not affect interoperability, safety and operation. The assessment report should explain the restrictions, the functionality implemented (including lists of CR’s) and should contain the list of specifications that apply to the subsystem /component. Then, the restrictions can be checked in the integration phase of the authorisation to place into service. [M1]

If there is a more restrictive and concerning Ss076 deviating behaviour, it is stated and can be declared as more restrictive behaviour referring to Ss040. This is an extremely dangerous situation to guarantee interoperability. Synchronization of SS076 and SS40 is desirable. Currently, we restrict our results to SS076, but once a synchronization is available it should be imposed. [T1]

f. How to deal with the situation that the interpretation e.g. of the SRS

(assignment of functions to trackside, on-board and air gap) differs from

manufacturer to manufacturer and to the test lab specifications?

We recommend the use of a neutral ref. lab to make tests of a set of different IC’s for issued areas and use the ref. lab as the “master” if differences are escalating. The outcome should be judged by ERA if non-compliance with the TSI exists. [M2]

That’s a problem and causes a lot of effort (each manufacturer or test lab has to scan the specifications and has to apply a requirement and subsystem status). It is not only having a clear indication of trackside, on-board and air gap functions; it’s also for having a clear indication of the requirements or informative status of a paragraph. The SRS shall provide such information’s. *I1+

Complementary tests have been designed for the early ERTMS implementations when this kind of problem appeared. These tests were carried out by an independent company from the manufacturer T/OB. Because Subset 076 was not synchronized with the rest of the specs it has been difficult to impose it as a mandatory specification [M1]

Test campaigns using the first commercial products help to avoid this situation. [T!]

This should not happen, because in Ss076 in the traceability it has been analysed which requirement is related to trainside and/or trackside among other aspects. This was reviewed also in former times by UNISIG members. There should be one agreed official requirement analyses and traceability table. [T1]

g. For which subsets or interface specifications test specifications are missing?

TIU FFFIS would improve the situation; certainly a test specification is envisaged. [S1]; [I1]

In general, verification of Track side engineering and implementation of the ERTMS functions are verified against national project documents. This is done because we need test




of 51

specifications that support the trackside engineering. Specifications supporting harmonized implementation of trackside functions are missing, along with its test specifications. [M2]

The certification of an RBC is very difficult due to the lack of IC RBC tests specifications. [M1]

Some new European interfaces should help a lot in the certification of trackside products. (RBC, IXL, CTC); (EVC, DMI, JRU) [T1]

The current specifications for Odometry and DMI can be tested, but they seem to be not optimal. [T1]

h. Which documents (e.g. the ERTMS/ETCS FRS) are not useful for the

certification process as the requirements could not be checked?

SUBSET033/SUBSET034 are not useful in the current state [I1]

Subset-023v.2.0.0, Subset-054 v.2.0.0, FRS [M1]

Informative documents in Subset-076. The review of the test specification also covers the simplification of documents. A proposal is already on the table. [T1]

i. How to deal with the situation that there are (known) errors in the actually

legalized specifications (e.g. SUBSET 076)?

Through lots of discussions between supplier, NoBo, NSA, member state. Deviations are generated by the NoBo which then have to be managed through a deviations process with the NSA and member state. [R3]

If there are technical deviations, we support the procedure in” Guide for the application of Article 7 of Directive 2008/57/EC on the management of deficiencies in TSIs (DV22EN03)”. The main problem occurs when different interpretations of a requirement are possible [M2].

Such an error is a planned deviation within the certification process, which then leads to a denial of a certification. [I1]

Deviations should be allowed for these situations and clearly written in the final report. A deviation is accepted if it does not affect interoperability, safety and operation. [M1]

They should be managed by ERA and the corresponding working group in a first step and secondly by the CCM process. We are proposing changes as informative steps, so that a notify body can better evaluate the constituent. [T1]

j. How do you certify that the not implemented functions will not lead to

problems on-board and trackside (e. g. no SH trackside in L2 and the train send

a SH request)?

These have been treated as deviations and then added as functional restrictions or Route specific restrictions on the certification. Analysis by the supplier has been used to show they will not have an operational impact on the route in the short term. [R3]

These issues will be dealt with by mitigation measures against all such eventualities which are checked by the appointed ISA. [S1]

The Notified Body shall make sure that added functionality does not disturb interoperability. (According to TSI CCS HS&CR chapter 6 the NoBo shall assess “which additional functions and




of 51

interfaces (not specified in this TSI) are implemented and that they do not lead to conflicts with implemented functions specified in this TSI”) *M2+

Not possible to test this in theory, only possible when making field tests. [I1]

The only task of the NoBo is to identify the not implemented functions and to include them in the infrastructure register or in on board register. Manufacturers procedures and tests should verify this. Functions not implemented need to be clearly stated in the certificates so that the impact could be checked when placing into service. Normally the on-board should be “complete” and it is the trackside that can have some optional functions. This is because the on-board spec (SRS) is more complete and has the reactions specified while the trackside specifications are not specified with such detail. Integration tests have been designed for this as part of the placing into service process. [M1]

k. What is your experience with the independent laboratories?

Labs have been used for operational tests to test both on-board and trackside with great success. Accredited laboratories give an additional guarantee in any certification process [M1]

l. Is there something missing in regard to QoS for data transmission and if yes,

what?

There are problems in the GSM-R QoS Test Specification (although it is an informative specification) which result in failed tests for lines where the QoS is sufficient to run trains. [R3]

We are not aware of any current issues [S1]

According to our experience the following is missing:

1. Subset 93 which specifies QoS for data is according to us to stringent in some aspects. An ERTMS implementation can work perfect on a line which not fulfils (all) the requirements in Subset 93. [R2]

2. On the other hand Subset 93 is informative and hence not part of the certification process.[R2]

3. Subset 93 is mainly a requirement for the GSM-R network and there is no a corresponding specification for on-board than generic requirements on the radio module. Perhaps this situation should be analysed. [R2]

Currently only testable on a specific line taking the individual characteristics of that line into account. [I1]

m. Would you support the general use of the H2/SH2 Modules (tests under

control of the Manufacturers)

Yes [R3], [I1]




of 51

Yes, but when the specifications and ERTMS implementations in general are more mature. The use of the H2/SH2 modules has many advantages, in time and price, and they should be used whenever possible. [M1]

The projects within Sweden and Trafikverket are all using modules H2/SH2 both for trackside and on-board ERTMS. Both the Swedish Transport Agency and Trafikverket supports the general use of them.

Restrict the use of Module H, eventually suppress it. [T1]

n. How do you manage the issue of delta certification and assessment and what is

missing on regulatory level?

Through discussions with the member state and the NSA [R3]

We support the use of ISV (Intermediate Statement of Verification) and ISC (Interim Statement of Conformity) [M2]

The problem of doing delta certification is currently the test specification. Without the separation of functionality it is not possible to do a delta certification. [I1]

Depends on the delta. It could require considerable specification work when preparing the test sequences. Laboratories should be able to provide certification times short enough to avoid this issue. [T1]

o. Are there parameters which are not clearly assignable to on-board or trackside

as they cover the whole transmission chain and how do you cope with them)?

Well the evidence of the non functionality e. g. cross talk with THR 10-10 1/h is not really testable. To guarantee this THR constructive and planning arrangements are necessary. (These may differ between infrastructures!) Make aware requirements shall be testable. That means each requirement shall be tested and measured to be evidenced. [R1]

KMS (Key Management System) cover both on-board and trackside. We have had some trouble in interpreting how the KMS is intended to work. We believe a common interface between the on-board ERTMS/ETCS equipment and the Home-KMC need to be specified to facilitate the open market. To sum up, we believe this area needs to be improved [M2]

We are just analysing this for Baseline 3. In general there are three categories a requirement is related to the on-board, secondly to the trackside and thirdly to both (e.g. communication issues among others). [T1]

p. Which RFU you like that ERA should them incorporate in their

recommendation?

A future RFU defining the “certificate with conditions” *I2+.

3. Placing into service

The report of EPSF in the ERA XA workshop (17 Nov) was very useful because it describes a pragmatic and stepwise approach, taking into account national legislation constraints e.g.




of 51

regarding language for legal documents, references to existing or previous standards (for vehicles already in service), … but still targeting to make the Reference List work [R1]

a. What are your lessons learned in regard to placing into service

Lessons learned [M1]:

The process is usually very complex and takes a long time

o The subsystems get to the last part of the process sometimes without finishing previous steps (i.e. EVC not having the complete sub 76 performed in a reference laboratory)

o It should be clearly specified the entities involved in the integration phase of the placing into service. The number of entities involved should be kept to a minimum.

There is not a clear scope of the test campaigns

o Not always a clear objective of the tests

Each train track integration is different, different additional issues may appear (errors on the track, errors on the train, inconsistencies in the specification)

Regarding the specifications, there are mainly two issues that have a big impact on the placing into service:

o The unmanaged update of the specifications (i.e. is not functional to place into service subsystems when the version of the specifications is continuously changing in an incompatible way)

o Open technical issues derived from the lack of mature specifications

Lessons learned [R3]:

De-link interoperability authorisation from entry into service [R3]

Run ERTMS trains in level 0 operation before level 2 operation to allow reliability problems to be fixed with minimal operational impact [R3]

Commission trains separately from the infrastructure [R3]

Implement a robust DRACAS (Data Recording And Corrective Action System) system and in service monitoring plan to understand and manage any issues arising from entry into service [R3]

Use a simulation laboratory and test track to carry out as much testing and validation as possible before construction commences on the route of the project so design can be understood and validated before it gets very expensive and time consuming to change [R3]

Quite some effort have been spent in order to harmonise and integrate the TSI CCS certification process with the well established process of commissioning and taking ATC systems into operation. This is pertinent with respect to the interface between design evidence and commissioning procedures. [M2]




of 51

The member states requests a full certificate of verification and conformity for placing into service. Without having such a certificate the ever ongoing effort is very high for explaining the reasons for it. [I2]

The reference laboratory of CEDEX has been used with success to put in service the High Speed line Madrid-Valencia and the Commuter lines of Madrid. With the confidence and support of the companies project data from Alstom, Invensys and Thales has been translated to the format of the Scenarios Controller. Operational scenarios have been built for the specific lines according to the cases selected by ADIF to put in service ERTMS infrastructure. [T1]

Commercial EVCs from Alstom, Bombardier, Invensys and Siemens have been connected to the test bench. This allowed the Laboratory to support RENFE to put in service trains to operate on the previous lines using the operational scenarios as requested by ADIF. [T1]

4.1.1.3 Previous projects are for level 1. At this moment the laboratories are working on the integration of commercial RBCs to support the entry in service process for Level 2. UNISIG companies have already shown interest and are cooperating [T1]

b. How it can be ensured that deviations are accepted by all the NSA

See EPSF report: acceptance given from NSA1 to NSA2 cannot simply be transferred to NSA3 – there is no “easy standard way” before checking conditions are fully harmonised [R1]

An NSA deviations process could be run by a central body which could give generic approval to some deviations and allow country specific approval to be given on others. [R3]

We must strive to have certification without deviations. A condition for that are mandatory requirements on requirements that effect interoperability. Requirements that cannot be assessed needs to be changed or clarified. [M2]

Until we have that situation NoBos must write certificates which clearly states deviations and any operative restrictions as result. [M2]

To have restrictions accepted by all NSA seems difficult. [M2]

Without harmonised acceptance criteria not possible to ensure. [I1}

Minimising these deviations [M1]

Defining a clear list of deviations so they can be accepted or exported; explaining the deviations and in particular the impact on the system where it is being placed into service [M1]

Including the final test phase for train track integration in the process, harmonising this test campaign and making the NSA define the necessary test cases for each network [M1]

Under the authority of the ERA acting as European Authority [T1]

Collecting line specific operational scenarios in an agreed harmonized format. The format has to be compatible to the technical test specification (Subset-076) in order to enable a consistency check. [T1]

c. What has to be improved in the NoBo certification process (e.g. harmonised template

(ERA) to be applied by each NoBo, ...)?

We need a common checklist containing all the requirements [R1]




of 51

Clear guidance and agreement needs to be given to the NoBos on how to handle deviations in the certification process and how these can be incorporated into successful submissions for authorisation. [R3]

There are already some templates from NB-Rail’s work. These could be used as a basis. [I1]

We support the work of NB-Rail, and think the best and quickest way to get harmonized templates which are up to date, are by the use of the Notified Bodies. [M2]

We also believe that there exists a need for control and supervision of NB-Rail. ERA should be responsible for that task. [M2]

d. Is there a need to improve/harmonise the issue of delta certification and assessment

and is there something missing on regulatory level?

Yes – partial certification would be useful if NSAs would accept it and would mean experience could be gained in terms of ERTMS deployment on a Route in the short term, with a path to full authorisation in the timescales that interoperability on the route (or for the fleet) would practically be required. [R3]

The use of ISV and ISC could facilitate the issue of delta certification. [M2]

The certification process will soon be a matter of days, therefore reducing the need of delta certifications [T1]

e. Would you support (actively) the harmonisation of operational rules?

Make it step by step and not the second step for the first one. That means each MS shall specify the tests in accordance of its operation. Next step compare the test cases and select the harmonised one. Then analyse the other one and try to harmonise it completely or partly. At the end of the day 90% are harmonised [R1]

We support the current work for harmonisation of both the ETCS and non-ETCS operational rules. The current work to merge the TSIs OPE HS and CR will provide a common Annex A covering the former and there is another work stream aimed at further harmonisation where this is feasible. Work for each of the ‘Corridors’ is also dealing with this. *R3+

Harmonisation of operational rules, particularly the non-ERTMS rules, is difficult because operational practices differ between member states, and because different meanings are given to common terms. For example “permissive working” has a number of different meanings. It is difficult to achieve true harmonisation, and often a fairly non-prescriptive form of words result. [R3]

Yes [M2]; [M1], [T1]

There should be a closer collaboration between the operational and the technical works, in order to assure that the objective is shared and that the works of the different groups are aligned [M1]

The interface between the CCS TSI and the OPE TSI should be more clearly defined. No mandatory requirements additional to the technical specifications, should be imposed due to operational rules. [M1]

The non harmonisation of the operational rules may cause difficulties when integrating the on-board and trackside assemblies. For example, due to the different operational procedures to set TSR, a train already certified and in service in a different country, is not able to manage




of 51

the TSR as engineered in the Spanish network, even though the technical specifications are followed. This problem has been identified when performing the operational tests for the integration of the train in the section. [M1]

f. Would you actively support that the “national” test cases would be published and

incorporated in the test data base?

Yes! [R1]; [R3]; [I1]; [M2]; [M1]

Remark [M1]: It is essential for this test campaign that the responsibilities are strictly defined and that the reporting is also harmonised so the test cases will not be repeated and the cost and time of the integration is minimised.

Yes, the national Test cases should extend the technical test cases from methodological point of view but should be managed separately and collected by the EEIG and/or ERA for certain ETCS lines. [T1]

g. What is your experience with TIU information provided by ETCS and the safety level

required?

The border of the system at Subset 091 is not in line with the border of real systems. Subset 091 belongs to technical safety targets only, NSA work is based on EN 50126 ff dealing with an overall safety level (technical – random failure + operational - systematic failure). [R1]

4. Expectations from ERA

To recommend a new base line if and only if [T1]:

• the test specification is produced,

• the test architecture is reviewed and debugged and

• test campaigns have been performed with equipment from different suppliers using the specification generated for the new baseline.

To trace the inconsistencies detected in the test specification and propose periodical reviews [T1]

To arbitrate the conflicts between companies and laboratories in case of different interpretation of the applicable specification. [T1]

To promote all activity addressed to assure clear interpretation of test results and to speed-up the testing process. [T1]

Dealing with the problems and proposed improvements from all MS and a proposal for harmonisation of the certification process in Europe [M1]

A flowchart covering the activities, responsibilities, deliverables and time constraints for the certification process should be elaborated. The whole process (from manufacturing the IC, placing into service till operation and maintenance phase) should be described. [R1]; [M2]; [M1], [T1]




of 51

Such a flowchart would be exceedingly helpful and we would be pleased to help generate such a flow chart. It may be something which could be developed through the ERTMS user group. [R3]

Complete, detailed and comparable checklists for the NoBos need to be elaborated for all the actors involved including a methodology to transport the elements not testable at a certain step to the next step. [R1]

Closure of remaining open points (mainly former AAA1) [R1]; [M2] but only if agreement can be reached with all stakeholders on how to close them [R3]

Incorporate the sector expectations of XA workshop [R1]

More guidance to the NoBos on the authorisation process and how to manage deviations would be useful. [R3]; [M2], [M1], [T1]

Steering the NoBo activity is massively needed to come to a harmonised European approach [L1]

Guidance on how to interface product NoBos with application NoBo with respect to certificate restrictions would also be useful. [R3]

OTS data base to be elaborated and maintained. [R1]

Harmonising/standardising of implementation rules [M2]; [M1], [T1]

Harmonising of operational rules [M2]; [M1], [T1]

A so called safety plan needs to be elaborated. The document should describe all the process steps (as in CENELEC 50126 picture 9 (tasks and Project steps) and chapter 6 (RAMS lifecycle)) and a structure of the European safety case (as in CENELEC 50129 chapter 5) [R1]

It would be very useful to have a minimum set of mandatory functions agreed for interoperability which would make the certification process easier and avoid the need to provide more functions than is actually required. [R3]

We support ERA in controlling NoBo (and NB-Rail) so that their work doesn’t diverse between different bodies and that their work is consistent with the intentions of the role NoBo. [M2]




of 51

Annex C (CCS Certificates assigned)

In order to give a quick overview a rough and incomplete extract for the CCS part could be found hereafter.

NoBo Subject Applicant On-board

Trackside

Altran Switchable Eurobalise x

Arsenal LEU Alcatel/Thales x

Belgorail Several versions of Safety platform on-board, odometry and JRU Alstom x

Belgorail Several versions of Safety platform trackside (RBC) Alstom x

Certifer Eurobalise encoder Alstom x

Certifer Safety platform on-board, EVC, odometry CSEE Transport x

Certifer Several RBC Ansaldo x

Certifer RBC Alstom x

Certifer On-board bi-standard (TVM) Ansaldo x

Cetren Line equipment (Perpignan-Figueras HS Line) TEP x

Cetren Several lines Adif x

Cetren LEU Nucleo x

Cetren On-board Alstom x

EBC JRU Hasler Rail x

EBC ETCS on-board Siemens x

EBC Balise Siemens x

EBC STM (LZB) Thales x

EBC Line L1 CFL x

Interfleet On-board HSBC Rail Ltd x

Interfleet On-board Siemens AG x

Kema RBC Alstom x

Kema EVC Alstom x

Kema STM ATB Alstom x

Kema STM TBL Alstom x

Kema STM USSB Alstom x

Tuev Rheinland Eurobalise

Ansaldo x

Tuev Rheinland LEU

Ansaldo x

Tuev Rheinland Several on-board

Alstom, Siemens x

Railcert LEU Dimetronic x

Railcert Eurobalise Bombardier x

Rina Eurobalise Sigma x

Rina On-board Alstom x

Rina On-board and safety platform Alstom x




of 51

Rina JRU Alstom x

Rina Odometry Alstom x

Certifer GSM-R cab radio Alstom x

EBC GSM-R parts Hoermann x EBC GSM-R parts EADS x

EBC GSM-R parts Nortel x

Interfleet GSM-R on-board First GBRF x

Lloyd's GSM-R voice on-board

Rail for London, First Scotrail, First great Western x

Lloyd's GSM-R infrastructure Network Rail x

Railcert Several GSM-R on-board Siemens UK x

Rina Several GSM-R cab radio OTE, Selex, Alstom, NEC x

Tuev Rheinland Several GSM-R mobile equipment Hoermann, Nortel x

Tuev Rheinland GSM-R network Kapsch x

Report on the Certification of ERTMS equipment

Documents

Transcript of Report on the Certification of ERTMS equipment