“DV 29”
COMMISSION RECOMMENDATION
on the authorisation for the placing in service of
structural subsystems and vehicles under
Directive 2008/57/EC
Why DV29?
Agency Study on Authorisation + Sector
Complaints
•
•
•
•
•
Costs, delays, uncertainty (increasing especially for CCS)
Different authorisation process in every country
Different interpretations of the directives in each country
Confusion over roles and responsibilities
Old processes continue
 Duplicate checks, “surprises”, overlaps between checks.
• Conflicts between directive and historical roles and
responsibilities eg
 IM acting as regulator (setting rules, authorising)
 ISAs carrying out “approvals”
• Technical incompatibility between projects (eg ETCS & GSMR)
How DV29 is to be used
It does not have the same legal status as the Directive
BUT
• If an entity complains that a MS or NSA is not acting
according to the Directive then the adjudicating
authority will refer to DV29
• The Commission will use DV29 to check conformity of
MS implementation of 2008/57
• All Member States agreed to it
3
Managing shared systems
2 Stages
• Stage 1 – National systems as open, shared
systems - NOW
• Separation of infrastructure and train
operations
• Transparent rules, roles, and responsibilities
• Stage 2 – Migration to a single European (target)
shared system-IN FUTURE
• One set of system specifications
• Conformity to these specifications
All Change-NOW!
•Before
•25 National Railways
•Each a single legal entity
responsible for all parts of the
system and its “V” cycle
•Railway Companies part of
government -”light touch” or no
regulatory supervision.
•“closed” systems
•“closed” markets
•Discrimination mandatory
•Now
•Each national system now a
“shared” system
•Many legal entities responsible
each for their own part
•RUs train operations
•IMs infrastructure operation
•Ministries – rules
•Regulation of railway
organisational and technical
interfaces essential
•“open” system
•“open” market
•Discrimination prohibited
Some Consequences
Managing national railway systems as open systems
Opening of markets means making requirements
for authorisation
 transparent
 repeatable (same result for the same input every time)
 certain (not changing over time or according to different
individual’s judgement)
 Verifiable by an independent 3rd party (NoBo, DeBo,CSMAB)
decision making must ensure
 “same as the other guy”
 “same as before”
Old Tools->New Tools
Interop and Safety Directives overtake EN50126/8/9
(“V”) as a tool for authorisation



CSM covers risk assessment
TSIs and national rules cover availability, reliability and safety
Technical compatibility must also be assured (not part of EN50126)
Dangers of using the “old tools”




Many ETCS systems / projects are all safe but incompatible with each
other (sometimes even in the same country!) - A step in the wrong
direction -towards diversity, away from interoperability
Confusion over roles and responsibilities
Multiple rechecks by different checkers
Assessing the same risk many, many times (i.e. assessing the same
risks again and again for each and every project)
NB - Confusion leads to high cost + safety risk
Scope of Authorisation
Authorisation v Operation
• Authorisation of Vehicle (= an Initial “Snapshot”)
• Vehicle design operating state “meets the essential requirements when
integrated into the system”
• Conforms to rules defining how to meet the ERs (TSI/NNTR). In particular:• Subsystems safely integrated
• Technically Compatible with the network (TSI+NNTR)
•
Authorisation is not related to any particular RU or IM
• Operation of trains (= an ongoing process using
vehs)
• RU’s Safety Management System
• Maintenance assures ongoing conformity with essential requirements
• Relies upon ability of each route to support the train (route compatibility)
and maintenance by IM of that ability.
Separation of Authorisation from Operation
Autorisation to place in service
by Member State (NSA)
Design, construction and installallation
Ability to operate and maintain
Exported Technical Characteristics
and operational/maintenance rules linked to the
design
Safe integration including technical compatibility
Risks covered by
relevant TSI
Checked by
NoBo
Open points,
specific cases in
TSI and
derogations
Checked by
Designated body
Risks covered
By NNTR
Checked by
Designated
body
Risks covered
neither by TSI
nor
NNTR
Checked by
CSM assessment
body
Provision and process of the safety
certificate/authorisation and/or ECM
certificate
the red line
Geographical Scope of Authorisation
“Each Member State shall authorise placing in service of those structural
subsystems constituting the rail system which are located or operated in its
territory (Art 15) “
Conclusion: Authorisation is required for all parts of the rail system
“Before being used on a network, a vehicle shall be authorised to be placed
in service by the national safety authority which is competent for this
network, unless otherwise provided for in this Chapter (Art 21.1)”
Observations:
• Authorisation may be obtained by a manufacturer. (independant of RU)
• No new authorisation if vehicle used on different routes
Conclusion: Vehicle Authorisation is for a network according to the rules
for that network
What is a Network?
A Network – some factors to consider
•
•
•
•
A geographically connected set of routes
Supervised by one Safety Authority
Managed by a single Infrastructure Manager
With one set of Technical Specifications / Rules
How many networks in a country?
“Steps should be taken to avoid a situation where Member
States adopt new national rules or undertake projects that
increase the diversity of the present system”
Maintaining the Essential Requirements (incl
Technical Compatibility)
The conformity with the TSIs and NNTR (demonstrated at
authorisation) must be maintained
• for a network by the IMs (variable track guage or loading gauge
infrastructure is not allowed)
• for a vehicle by the RU (variable track or kinematic gauge vehicles not
allowed)
An RU/IM must, via its SMS, ensure that it does not operate any
vehicle/network whose conformity with the essential
requirements (as described in the TSI and NNTR) has not been
maintained
• operation of vehicles/networks with unknown maintenance
limits is not allowed because it compromises compatibility
Operations TSI
Comes into play when it is necessary to have
common procedures of operation and traffic
management
• Not relevant (no checks) for authorisation (right
rand side of the dotted red line)
• Functionalities for operation (eg visibility, horns
braking requirements) are covered by structural
TSIs
Some Comparisons - Aviation
Aircraft certification
• Independent of which airline will use the plane
 Not related to the ability of any airline to maintain the plane
 Not related to the ability of any airline’s pilots to fly the
plane
Independent from particular routes or airports
 Airport operators make public the nature of their
infrastructure (runway length etc)
 Airlines make sure they fly to airports that are compatible
with their planes
Some Comparisons- Road System
Vehicles
• are certified independantly from drivers or haulage companies
• are certified independent of which routes they use
Common Technical Rules, Roles and Responsibilities apply
• New highways are built and maintained to “standard dimensions” (eg
bridge height)
• Road signs are standardised nationally /at EU level (not project by
project)
• Highway authorities make public the nature of their non standard
infrastructure (eg low bridges) and maintain them to published limits
• Management systems of bus companies and freight hauliers ensure
that their drivers only drive vehicles on routes that are compatible
with their busses/lorries
Technical Compatibility, Safe
Integration
Technical Compatibility (1)
One of the essential requirements (Annex III)
“The technical characteristics of the infrastructure
and fixed installations must be compatible with
each other and with those of the trains to be used
on the rail system”
“Steps should be taken to avoid a situation where
Member States adopt new national rules or
undertake projects that increase the diversity of the
present system”.
Technical Compatibility (2)
• Technical Compatibility is an essential element in
market opening and interoperability
• The Member State must ensure technical
compatibility at the vehicle-network interface is
maintained.
Technical Compatibility (3)
TSIs (and national rules where not covered by TSIs)
specify how the essential requirement of Technical
Compatibility is to be implemented
Conclusions:
–
To preserve technical compatibility and prevent diversity
national rules need to cover the vehicle-network interface to
the same scope and level of detail as TSIs
–
The MS must make transparent the rules that specify any
requirements that exist (in addition to those in TSIs) that are
necessary (“exported” to vehicles) to implement technical
compatibility between TSI conform vehicles and non-TSI
conform parts of their network.
Managing Shared Systems
Vehicles
Veh authorisation
Integration
Into veh typa A
Integration into
Veh Type C
Network
Technical
Compatibility
Supplier A
OBU
Subsystem authorisation
Project A
Integration into
Local inf
Project B
Integration into
Local inf
Integration
Into veh typa A
Integration into
Veh Type B
Integration into
Veh Type C
Supplier B
OBU
Integration
Into veh typa A
Integration into
Veh Type B
Integration into
Veh Type C
Integration into
Veh Type C
Conformity
to Reference
TSI + national
rule
TSI + national
rule
Project C
Project D
Supplier C
OBU
Supplier D
OBU
Integration into
Local inf
Integration into
Local inf
Project E
Integration
Into veh typa A
Integration into
Veh Type B
Conformity
to Reference
Integration into
Local inf
Project F
Integration into
Local inf
Integration into
Local inf
Project G
Integration into
Local inf
Project H
Integration into
Local inf
For each infrastructure project 1 compatibility check (TSI )plus local integration
For each OBU design one IC check to TSI and MS national rules
For each loco type / OBU combination check integration veh to OBU
Old Tools->New Tools
Interop and Safety Directives overtake EN50126/8/9
(“V”) as a tool for authorisation



CSM covers risk assessment
TSIs and national rules cover availability, reliability and safety
Technical compatibility must also be assured (not part of EN50126)
Dangers of using the “old tools”




Many ETCS systems / projects are all safe but incompatible with each
other (sometimes even in the same country!) - A step in the wrong
direction -towards diversity, away from interoperability
Confusion over roles and responsibilities
Multiple rechecks by different checkers
Assessing the same risk many, many times (i.e. assessing the same
risks again and again for each and every project)
NB Confusion leads to high cost + safety risk
Technical Compatibility (1)
A–
A’
B–
B’
Interoperable
interface
Technical Compatibility (2)
A–
A’
B–
B’
Interoperable
interface
Technical Compatibilty (TC) : one of the essential requirements
(Annex III)
TSIs specify how the essential requirements are to be
implemented – Verification of TC by reference to TSIs
Technical Compatibility (3)
B
A–
A’
Interoperable
interface
B’
Safe Integration (1)
Need to demonstrate the safe integration before authorisation
A
B
Interoperable
interface
Hazard identification
Technical solution
Risk analysis
Measures
Design constraints
Maintainabily
constraints
Safe Integration (2)
Has also demonstrated the safe integration before authorisation
A’
B’
Interoperable
interface
BUT
Hazard identification
Technical solution
Risk analysis
Measures
Design constraints
Maintainabily
constraints
Safe Integration (3)
B’
A
Interoperable
interface
Safe integration could jeopardise interoperability
 Interface need to be covered by rules
When no TSI, national rules apply and need to be notified
Part of the next revision of the TSI
Safe Integration (5)
How to perform the safe integration  CSM on Risk Assessment
RISK ANALYSIS
HAZARD IDENTIFICATION
AND CLASSIFICATION
Codes of
Practice
Similar
Reference
Systems
Explicit Risk
Estimation
Not lead to requirements contradictory to TSIs or NTRs ones
When TSIs or NTRs exist, they are mandatory
Safe Integration (6)
Important remark
Both directive 2008/57/EC and 2004/49/EC must be complied with
 Safe Integration must be delivered in a way that is Technically
Compatible
 If additional requirements (from the one of the TSIs) are
necessary to maintain the existing safety level then: Requirements on network or operation (as long as they do
not contradict the TSI)
 If not possible, should be included in the vehicle related TSI
as duly justified specific case
Safe Integration (6)
Already some experiences
RISK ANALYSIS
HAZARD IDENTIFICATION
AND CLASSIFICATION
Codes of
Practice
Similar
Reference
Systems
Explicit Risk
Estimation
The interface will then be covered by rules
Evolution of Rules for
Technically Compatible Safe
Integration
Network-Vehicle
Rules for Vehicle-Network
Compatibility
Old National Laws
Usually “High Level”
“Be safe”
Rules of the National
Railway Company
including RU-IM
operational rules and
specifications for
Vehicle – Network
Compatibility
Implementing legislation
plus
National Rules including
RU-IM Operational Rules
and Rules specifying the
network – vehicle
compatibility
IM Company rules
RU Company rules
34
Mutual Recognition
(incl “grandfather’s rights”)
Mutual Recognition
• Member States may choose to require Additional
authorisation for vehicles already authorised in another
MS
• On additional authorisation Member States may only
check against
 Specific cases
 Rules relating to compatibility with the network
 (but only if they are B and C rules in the Ref Doc)
• For non TSI conform vehicles the NSA must not call into
question the checks of first authorisation unless they
can demonstrate a substantial safety risk to the
applicant
• (And even then not if related to an A rule in the Ref Doc)
Grandfather’s Rights (1)
• Art 23 and 25 (Additional authorisation) require
that
• For TSI conform vehs only technical
compatibility with the network and specific
cases may be checked
• For Non TSI-Conform the NSA may not call into
question checks carried out as part of the first
authorisation save (i.e. except) where the NSA
is able to demonstrate a significant safety risk
Grandfather’s Rights (2)
• This means that
• Grandfathers rights apply to additional authorisations in
respect of parameters not relating to network-vehicle
compatibility or specific cases
 Because it would be discriminatory to allow a 20 years old
national vehicle to run on grandfathers rights but to insist that an
identical vehicle applying for additional authorisation must
conform to today’s rules for new vehicles.
• Except where to do so would create a significant safety risk
(e.g. if the safety level of the old foreign vehicle is much
lower than would be allowed for same age national
vehicles)

Because to do so would discriminate in the opposite direction and
would lower the overall level of safety
Registers
Register of infrastructure (RINF)/ Network
Statement
Application of 2001/14/EC and 2008/57/EC
Purpose – The tool for the RU to establish route
compatiblity
Scope: whole network (incl. existing lines)
 Description of the “nature of infrastructure” as far as
compatibility with the train is concerned
 Should allow IMs to inform RUs in a harmonised way about the
nature of the infrastructure
 Contains route specific non-conformities with TSI/national
rules.
To Conclude
Key principles of DV 29
• Separation of authorisation from operation (use)
• Vehicle Authorisation is for a Network
•
and is given by the NSA (and only the NSA)
• Technical Compatibility Network-Vehicles is assured by
conformity with TSIs and national rules.
 Route exceptions described in the network
statement/infrastructure register
 Maintenance must maintain this compatibility
 Don’t let projects create new system diversity!
• At additional authorisation, checks may concern only
conformity to notified national rules related to technical
compatibility with the Network unless a significant safety
risk can be demonstrated.
Thank you for your attention
Questions?
43