EUROPEAN RAILWAY AGENCY
EUROPEAN RAILWAY AGENCY
Report on the certification of ERTMS equipment
Reference:
ERA/REP/2011-08/ERTMS
Version :
1.0
Date :
14th April 2011
Document type:
Report
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 2 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 3 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 4 of 51
EUROPEAN RAILWAY AGENCY
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 07.01.2011
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 ”
[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
[5]
Directive 2004/49/EC
DIRECTIVE 2004/49/EC OF THE EUROPEAN
29.042004
PARLIAMENT AND OF THE COUNCIL of 29 April 2004
on safety on the Community’s railways
[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)
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 5 of 51
20.10.2010
16.12.2008
EUROPEAN RAILWAY AGENCY
Table 2 : Reference documents
Ref. N°
Document Reference
[7]
2006/679/EC
[8]
2006/860/EC
Title
Last
Issue
CR TSI CCS
Commission Decision concerning the technical
specification for interoperability relating to the controlcommand and signalling subsystem of the transEuropean conventional rail system
CR TSI CCS – First modification and HS TSI CCS
Revision
28 March
2006
7 November
2006
Commission Decision concerning a technical
specification for interoperability relating to the controlcommand and signalling subsystem of the transEuropean high speed rail system and modifying Annex
A to Decision 2006/679/EC concerning the technical
specification for interoperability relating to the controlcommand and signalling subsystem of the transEuropean conventional rail system
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 6 of 51
EUROPEAN RAILWAY AGENCY
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).
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 7 of 51
EUROPEAN RAILWAY AGENCY
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.
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 8 of 51
EUROPEAN RAILWAY AGENCY
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.
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 9 of 51
EUROPEAN RAILWAY AGENCY
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:
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 10 of 51
EUROPEAN RAILWAY AGENCY






3.2.4
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
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 11 of 51
EUROPEAN RAILWAY AGENCY


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:
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 12 of 51
EUROPEAN RAILWAY AGENCY
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]
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 13 of 51
EUROPEAN RAILWAY AGENCY
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.
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 14 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 15 of 51
EUROPEAN RAILWAY AGENCY
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).
2.

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 onboard is only intended for L1 operation) or not relevant/required for a specific
project.
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 16 of 51
EUROPEAN RAILWAY AGENCY
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.
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 17 of 51
EUROPEAN RAILWAY AGENCY

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 onboard.
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 18 of 51
EUROPEAN RAILWAY AGENCY
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 onboard 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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 19 of 51
EUROPEAN RAILWAY AGENCY
 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.
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 20 of 51
EUROPEAN RAILWAY AGENCY
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=detail
ed&sb=Title
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 21 of 51
EUROPEAN RAILWAY AGENCY
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.
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 22 of 51
EUROPEAN RAILWAY AGENCY
 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)
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 23 of 51
EUROPEAN RAILWAY AGENCY
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 onboard.
• 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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 24 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 25 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 26 of 51
EUROPEAN RAILWAY AGENCY
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.
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 27 of 51
EUROPEAN RAILWAY AGENCY
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.
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 28 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 29 of 51
EUROPEAN RAILWAY AGENCY
High
Short
term
Update the Annex A documents to B3
In progress
High
Short
term
Introduce the need for an European Finalised, incorporated in
test data base
the TSI CCS update, to be
voted mid-2011.
High
Short
term
Provide analysis how to get more Starting in April 2011
transparency
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 In progress
requirements for GSM-R
High
Short
term
Preparation of test cases (GSM-R In progress
network and mobile equipment) and
allocation
to
the
relevant
interoperability requirements
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
Group
High
Medium
term
TBD
Users Create the operational test data Started
base
Maintain the operational test data
base
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 30 of 51
EUROPEAN RAILWAY AGENCY
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?

What still need to be improved or is missing?
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?

What still need to be improved or is missing?
d. Module specification

Did the new Module specification cover your needs?
o If yes, why?
o If no, why?

What still need to be improved or is missing?
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)?
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 31 of 51
EUROPEAN RAILWAY AGENCY
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 onboard 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)?
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 32 of 51
EUROPEAN RAILWAY AGENCY

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?
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 33 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 34 of 51
EUROPEAN RAILWAY AGENCY
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].
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 35 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 36 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 37 of 51
EUROPEAN RAILWAY AGENCY
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]
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 38 of 51
EUROPEAN RAILWAY AGENCY

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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 39 of 51
EUROPEAN RAILWAY AGENCY
different suppliers. Tests have been performed with the TSD and real cabs. For MadridValencia 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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 40 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 41 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 42 of 51
EUROPEAN RAILWAY AGENCY
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]
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 43 of 51
EUROPEAN RAILWAY AGENCY
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.
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 44 of 51
EUROPEAN RAILWAY AGENCY
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]
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 45 of 51
EUROPEAN RAILWAY AGENCY
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]
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 46 of 51
EUROPEAN RAILWAY AGENCY
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
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 47 of 51
EUROPEAN RAILWAY AGENCY
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 speedup 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]
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 48 of 51
EUROPEAN RAILWAY AGENCY
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]
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
Page 49 of 51
EUROPEAN RAILWAY AGENCY
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
Altran
Arsenal
Belgorail
Belgorail
Certifer
Certifer
Certifer
Certifer
Certifer
Cetren
Cetren
Cetren
Cetren
EBC
EBC
EBC
EBC
EBC
Interfleet
Interfleet
Kema
Kema
Kema
Kema
Kema
Tuev
Rheinland
Tuev
Rheinland
Tuev
Rheinland
Railcert
Railcert
Rina
Rina
Rina
Subject
Switchable Eurobalise
LEU
Several versions of Safety platform on-board,
odometry and JRU
Several versions of Safety platform trackside (RBC)
Eurobalise encoder
Safety platform on-board, EVC, odometry
Several RBC
RBC
On-board bi-standard (TVM)
Line equipment (Perpignan-Figueras HS Line)
Several lines
LEU
On-board
JRU
ETCS on-board
Balise
STM (LZB)
Line L1
On-board
On-board
RBC
EVC
STM ATB
STM TBL
STM USSB
Applicant
Onboard
Alcatel/Thales
Alstom
Alstom
Alstom
CSEE Transport
Ansaldo
Alstom
Ansaldo
TEP
Adif
Nucleo
Alstom
Hasler Rail
Siemens
Siemens
Thales
CFL
HSBC Rail Ltd
Siemens AG
Alstom
Alstom
Alstom
Alstom
Alstom
Ansaldo
Tracksid
e
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Eurobalise
x
Ansaldo
LEU
x
Alstom, Siemens
Several on-board
LEU
Eurobalise
Eurobalise
On-board
On-board and safety platform
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
x
Dimetronic
Bombardier
Sigma
Alstom
Alstom
Page 50 of 51
x
x
x
x
x
EUROPEAN RAILWAY AGENCY
Rina
Rina
JRU
Odometry
Alstom
Alstom
x
x
Certifer
EBC
EBC
EBC
Interfleet
GSM-R cab radio
GSM-R parts
GSM-R parts
GSM-R parts
GSM-R on-board
x
x
x
x
x
Lloyd's
Lloyd's
Railcert
GSM-R voice on-board
GSM-R infrastructure
Several GSM-R on-board
Rina
Tuev
Rheinland
Tuev
Rheinland
Several GSM-R cab radio
Alstom
Hoermann
EADS
Nortel
First GBRF
Rail for London,
First Scotrail, First
great Western
Network Rail
Siemens UK
OTE, Selex, Alstom,
NEC
Several GSM-R mobile equipment
Hoermann, Nortel
x
GSM-R network
Kapsch
File: ERA-REP-2011-08-ERTMS ERTMS-Certification-V1.0public release version
x
x
x
x
x
Page 51 of 51