1. Recommendation 2014/897/EC (DV29bis) Key Principles

2. ›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

3. Responsibilities 3

4. ›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

5. ›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

6. ›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

7. ›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

8. Authorisation 8

9. ›“ 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

10. Authorisation CaseVehicle Type Individual Vehicle When First AuthorisationXXFor a new basic design New Authorisation (Upgrade/Renewal) XXFor a changed basic design Additional AuthorisationXXWhen already authorised in another EU MS Renewed AuthorisationXFor a type authorisation that is not valid anymore Subsequent Authorisation XFor individual vehicles conforming to an authorised vehicle type The Authorisation Cases

11. 11 Authorisation compared to Use System specifications = TSIs and National Rules

12. ›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

13. ›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. 14 Vehicle composed of two subsystems – “cumulative” diagram Vehicle RSTCCS

15. 15 Vehicle composed of two subsystems - Options Vehicle RSTCCS Option 1Option 2Option 3 Subsystem 1EC declaration of verification YES incl in veh declaration AuthorisationYESno Subsystem 2EC declaration of verification YES incl in veh declaration AuthorisationYESno VehicleEC declaration of verification No (Art 22.2 a) YES (Art. 22.2.b) YES (Art. 22.2.b) AuthorisationYES

16. Rules and the essential requirements 16

17. ›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

18. 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 Level of DETAIL Voluntary Applicant chooses own specification Mandatory Specified in TSIs / NTRs

19. ›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

20. Technical Compatibility and Safe Integration 20

21. ›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

22. ›(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

23. ›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

24. Technical Files 24

25. ›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

26. Mutual Recognition 26

27. ›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

28. Return of experience 28

29. ›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

30. Modifications 30

31. ›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. 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. 33