Recommendation 2014/897/EC (DV29bis)

Key Principles

› Make rail more competitive by:

› Market opening › International operation › Interoperability

› Gradual migration to the optimal level of harmonisation

› The framework combines › New approach to products and services › Rules and tools for management of shared systems

2

Policy Objectives

Responsibilities

3

› The applicant is responsible for ensuring that the requirements of the relevant Union legislation including any relevant national rules have been met by the subsystem (or a vehicle as a combination of subsystems) in its design operating state. This includes (but is not limited to):-

› The essential requirements for the railway system set out in Annex III of the

Interoperability Directive › The essential requirements of other directives › The specific requirements contained within TSIs › The specific requirements contained in national rules (where TSIs do not yet apply)

› Where not specified in legislation (e.g. TSIs) the applicant may choose his own solutions to meet the essential requirements.

› The applicant signs an EC Declaration of verification to declare that he has discharged this responsibility.

4

The applicant

› The role of the NSA “should be to carry out a check of the documents accompanying the application for placing in service and providing evidence of the adequacy of the verification procedure. This check should consist of checking the completeness, relevance and consistency of the documentation submitted for authorisation. It is limited to matters within the competence of the National (railway) safety authorities as defined in Directive 2004/49/EC”

› If the compliance at authorisation with the essential requirements is later called into question the authorising NSA should only be held accountable for the specific tasks allocated by Article 16 of the Safety Directive

5

The NSA

› Notified Bodies › Verify conformity with TSIs and draw up the certificate(s) of verification intended

for the applicant. › The notified body’s verification “shall also cover verification of the interfaces of the

subsystem in question with the system into which it is incorporated”.

› Designated Bodies › Carry out exactly the same tasks in respect of national rules

› Risk Assessment Bodies › Review risk assessments procedures and issue safety assessment reports when the

use of the CSM is required by the Interoperability Directive, the TSIs or the national rules.

› The independence of the staff responsible for assessment must be guaranteed. › e.g. “functionally independent of the authorities issuing authorisation”

6

The Assessment Bodies

› The infrastructure managers have one direct role in the context of facilitating the authorisation process. › In the case of additional tests required by a national safety authority, for an

additional authorisation ‘the infrastructure manager, in consultation with the applicant, shall make every effort to ensure that any tests take place within 3 months of the applicant’s request’.

› The infrastructure manager has no power to impose a sort of second authorisation to the vehicles or trains of the railway undertakings.

7

The Infrastructure Manager

Authorisation

8

› “ The authorisation for placing in service of a subsystem is the recognition by the Member State that the applicant for this subsystem has demonstrated that it meets, in its design operating state, all the essential requirements of Directive 2008/57/EC when integrated into the rail system”

› Authorisation should not be related to any particular › Route, Railway Undertaking, Keeper or ECM

› The design operating state is “the normal operating mode and the foreseeable degraded conditions (including wear) within the range and conditions of use specified in the technical and maintenance files. It covers all conditions under which the subsystem is intended to operate and its technical boundaries”

› Limits ands conditions of use related to vehicle authorisations should be specified in terms of the parameters of the characteristics of infrastructure and not in terms of geography

9

Authorisation

Authorisation Case Vehicle Type

Individual Vehicle

When

First Authorisation X X For a new basic design

New Authorisation (Upgrade/Renewal)

X X For a changed basic design

Additional Authorisation X X When already authorised in another EU MS

Renewed Authorisation X For a type authorisation that is not valid anymore

Subsequent Authorisation

X For individual vehicles conforming to an authorised vehicle type

The Authorisation Cases

11

Authorisation compared to Use

Authorisation

for placing in

service

Design, production

and testingOperation and

maintenance

Conformity to System Specifications

Meeting the Essential RequirementsSafety

Technical Compatibility

Reliability and Availability

Health

Environmental Protection

Accessibility

Checks by assessment bodies

Provisions and processes of

Railway Undertaking’s or

Infrastructire Manager’s

Safety Management System

- Technical characteristics

- Conditions and limits of use

- Operational and maintenance

requirements related to the design

Return of experience

System specifications = TSIs and National Rules

› Type authorisation allows manufacturers to offer their customers vehicle types already authorised › By analogy a vehicle type authorisation is the recognition by the Member State that the

applicant for this subsystem has demonstrated that it meets, in its design operating state, all the essential requirements of Directive 2008/57/EC when integrated into the rail system

› A vehicle type is a design described by a set of basic design characteristics. The basic design characteristics of a vehicle type are listed in ERATV. The values of the basic design characteristics of a vehicle type shall be registered in ERATV.

› This › Removes much of the authorisation risk from their customers › Allows small orders to be placed with reduced cost of authorisation › Allows long production runs and economies of scale by supplying the same type of

vehicle to many customers › Allows an open market in leasing and sale of authorised vehicles › Avoids each RU having its own special vehicle designs

› Is a concept applied in other transport modes

12

Type Authorisation

› Subsystems may be authorised individually but cannot be authorised in isolation from other subsystems

› Because a subsystem authorisation must always be based on a “verification of its

interfaces” (Art 18.2), check “the technical compatibility with the system in which they are being integrated” (Art 15.1) and ensure safe integration with the rest of the vehicle/network project.

› As allowed by the Interoperability Directive, DV29bis foresees that:

› A single EC declaration of verification may cover more than one subsystem › A vehicle authorisation is a combination of the authorisations of the subsystem

that comprise the vehicle

13

Subsystems and Vehicles

14

Vehicle composed of two subsystems – “cumulative” diagram

Vehicle

RST CCS

15

Vehicle composed of two subsystems - Options

Vehicle

RST CCS

Option 1 Option 2 Option 3

Subsystem 1 EC declaration of verification

YES YES incl in veh declaration

Authorisation YES no no

Subsystem 2 EC declaration of verification

YES YES incl in veh declaration

Authorisation YES no no

Vehicle EC declaration of verification

No (Art 22.2 a)

YES (Art. 22.2.b)

YES (Art. 22.2.b)

Authorisation YES YES YES

Rules and the essential requirements

16

› The essential requirements are all the conditions “which must be met by the rail system, subsystems, interoperability constituents including interfaces”

Whereas:

› TSIs set out specifications “to the extent necessary to meet the objectives [of the Interoperability Directive].” (Art 5.3 ID)

› It follows that TSIs only need to be as exhaustive in respect of the essential requirements as is necessary to meet the objectives of the Directive – i.e. they specify the optimal level of harmonisation

17

TSIs and the essential requirements

TSIs and the essential requirements

18

Interoperability Directive 6 Essential Requirements

Mandatory Rules

TSIs + NTRs

Standards directly quoted in TSIs

Harmonised EN Standards

Other public standards and documents

Company standards

1.Safety 2.Reliability and availability 3.Health 4.Environmental protection 5.Technical compatibility 6.Accessibility

Leve

l of

DET

AIL

Voluntary • Applicant chooses

own specification

Mandatory • Specified in

TSIs / NTRs

› When a rule is changed, the rule must be clear about its scope of application, e.g. if and when it applies to:

› only new vehicles and subsystems at first authorisation, › existing authorised vehicle types, › existing vehicles to be given a new authorisation after renewal or upgrade, or › all subsystems and vehicles already in service.

19

Changes to rules

Technical Compatibility and Safe Integration

20

› Vehicles and networks are managed by different actors each responsible for their part of the system

› Therefore, an (exhaustive) rule-based approach is necessary for the network-vehicle interface. › Every basic parameter and interface of the target system to be explicitly

checked for authorisation must be fully specified in the TSIs and national rules where not yet covered by TSIs

› The relevant conformity assessment requirements must also be included.

21

Technical Compatibility

› (a) safe integration between the elements composing a subsystem

› (b) safe integration between subsystems that compose a vehicle

› (c) safe integration of a vehicle with the network characteristics

Part of the applicant’s EC verification for authorisation

› ------------------------------------------------------------------------------------

Not part of EC verification for authorisation

› (d) safe integration into an RUs SMS

› (e) safe integration of a train with the routes over which it operates

22

Safe Integration for Vehicles

› The TSIs and national rules may require the use of the CSM for specific parameters

› The applicant must ensure that all requirements (including non-safety essential requirements) have been captured. For parameters where CSM use is not required by the TSI or national rules, the CSM approach may still be used at the choice of the applicant but is not mandatory.

› It is not part of authorisation to use the CSM or RA check to validate the correctness of TSI requirements but, if a discrepancy or error is perceived in TSIs or national rules, then the issue must be raised as a matter of urgency, with justification, using the procedures (ID Article 17, DV29bis Rec. 43).

› An applicant is not required to assess if the authorisation itself represents a significant change to the railway system. This task is to be carried out by the RU/IM who intends to bring it into use on their part of the system.

23

Risk Assessment in authorisation

Technical Files

24

› Each NoBo and each DeBo compiles a Technical File covering the verifications that they have carried out.

› The applicant compiles a “technical file accompanying the EC declaration of verification”. This contains: › All the NoBo and DeBo files (including all certification) › All other files required by all applicable EU legislation including drawings etc. .as

required by para 2.4 of Annex V I › Everything else necessary for the authorisation, and ongoing use of the

subsystem/vehicle, e.g. the limits and conditions of use.

› The MS may specify in their National Legal Framework which parts of the technical file accompanying the EC declaration of verification they wish to see in the documentation to be submitted for authorisation.

25

Different Technical Files

Mutual Recognition

26

› Verifications carried out according to national rules of other Member States must be mutually recognised unless:

› These are strictly necessary to check the technical compatibility of the vehicle with

the relevant network and are not equivalent to the rules of the Member State of the first authorisation. (ie there is no evidence of Technical Compatibility with the network)

or › A Member State can demonstrate to the applicant for additional authorisation a

substantial safety risk (non-TSI conform vehicles)

› CSM assessments carried out as part of authorisation must be mutually recognised

27

Mutual Recognition

Return of experience

28

› The SMS of RUs and IMs should cover the processes and actions necessary to maintain vehicles and subsystems in use in conformity with the essential requirements. This must take account of return of experience.

› NSAs should monitor conformity with and effectiveness of the SMS in dealing with return of experience. They should not prescribe corrective action.

29

Return of experience

Modifications

30

› Substitution = no change to Technical File

› Changes that change the Technical File and require new checks but leave the « basic design characteristics » unchanged (e.g. same vehicle type)

› (Change to basic design characteristics->new vehicle type)

Decision involving RU/IM + NoBo/DeBo (EC Verification)

› -----------------------------------------------------------------------------------------------------------------

Decision involving applicant and NSA/Ministry (authorisation)

› Renewal/upgrading not requiring authorisation

› Renewal /upgrading requiring authorisation

31

4 levels of Change

Small change

Big change

32

New Type, New Authorisation ?

Basic Parameters for Vehicle Authorisation

Basic Design Characteristics

A change above a certain threshold will trigger a new type and a new vehicle authorisation

A change above a certain threshold will trigger a new vehicle authorisation

If possible, the threshold should be defined in TSIs

33