DR MARC ANTONI - UIC

Transcription

1 DR MARC ANTONI - UIC

2 1. Why this question? 2. Current evidences 3. How to move forward? 4. First step 5. Summary

3 Why should a railway need open and formal FRS to define ETCS in Europe? 1. ETCS is a sub-system (ATC with block & cab signalling) to be duly integrated in each national railway system, with regards to geography and demography : uniformity & integration 2. ETCS doesn t change the responsibility of the IM s regarding Safety and Security : how to be able to 3. ETCS, as other IT technologies, doesn t change the responsibility of IM s regarding the systems investments, the maintenance & renewal costs : how to be able to

4 The railway system is in stable unbalance An evolution of one dimension has an impact on the others Human capital (organisation, skills, education, culture, including ETCS ) Environment by sub network (economical and safety targets, traffic, track ownership policy ) Infrastructure (track, signalling including ETCS, traffic management, overhead lines, monitoring ) Balance x Operation principles - Rules (operation rules including ETCS, laws, technical directives, track ownership management ) Rolling stock (signaling systems including ETCS, speed, load, aerodynamics, acceleration, monitoring )

5 ETCS doesn t change the responsibility of the IM s and RUs regarding Safety and Security : 1. IMs and RUs will always be responsible of the safety and security of the signalling assets, and when they have outsourced the design, build and maintenance 2. The question is to know how it will be possible regarding: - the reduced visibility on the ETCS functionalities in the systems - the difficulty to manage the interfaces with the other all railway system - the difficulty to follow the real status of the systems...

6 ETCS, as other IT technologies, doesn t change the responsibility of IM s and RUs regarding the systems investments, the maintenance & renewal costs: 1. Same as previously, regarding performance and costs 2. How to deal with: - Reduced visibility on the systems design, their strengths and weaknesses in terms of asset management - difficulty to control maintenance and renewal plans - necessity to manage unforeseen needed renewal work, with related risks and costs

7 ETCS has to be interfaced with the whole railway system, especially the legacy signalling system that must remain: Functional Software (formal provable) + Critical computerized system Operators Exploitation rules sensors Maintenance ERTMS system Over system Hard and Ground Software Rolling stocks Field Elements Block system

8 The railway expectations about ETCS deployment are now in favour of: Eradicating by formal proof the functional mistakes leading to systematic common mode failures : determinism Considering the national operation principles, the degraded modes, the maintenance and operation constraints Unambiguous requirements for different ETCS subsystems => giving real evidence of functional safety => safety & security need transparency (white box vs. black box) : determinism Independency of RBC from the existing interlocking type and existing radio carrier

9 Defining an unambiguous set of ETCS requirements: FFRS, Formal Functional Requirements Specs These will : 1. Lead to a common understanding for railway people (responsible for the integration and the global safety & security of the railway system) and suppliers (responsible for the design choices ) 2. Use generic and formal description of the ETCS functionalities and of the national signalling functions (Operation principles) 3. Give the possibility for simulations, testing and/or mathematical proofs by the safety responsible entiity

10 Formalization of the requirements simulation Formalization of the Postulates for each sub system interfaced with the RBC Formalisation of the Functionalities of the RBC Link with interlocking (where the information is coming from) RBC Link to moving EVC s through the radio Links FFRS describing the RBC s postulates FFRS describing the RBC specifications / clear interfaces to the environment

11 Formal description of the requirements proof Formalization of the Postulates for each sub system interfaced Formalisation of the Functionalities of the RBC Link with interlocking (where the information is coming from) Link to moving EVC s through the radio Links RBC Safety Properties FFRS describing the RBC specifications the Safety Properties & the Postulates Realisation of the proof that not a single safety property isn t verified (without any scenario!)

12 UIC projects are working to make it possible to define FFRS for ERTMS in the future: 1. SMILE (Smooth Moving Interlocking Link with ETCS) Formal definition of a generic SIL4 interface unit between existing interlocking (especially based on class-1 relay) and existing or future RBC Choice of the formal language + open proof tools Unique architecture + formal Requirements 2. SATLOC (~ETCS L3 with localisation by satellite) Formal writing of the specifications, module by module, to be able to simulate all the system and to prove it formally (in addition of the classical testing made before)

13 13 A formal description of the ETCS specifications for: A quick reduction of the life cycle costs (operation, maintenance, renewal...) A faster and more efficient deployment of ETCS in Europe (for all legacy systems) A Facilitated safety and security demonstration (assessment) Fulfilling all special clients requirements without any need for change request of the official Specifications

14 ETCS (block system) Interlocking system Field elements Instead of changing all the blocks, change one by one each construction block when needed and this way reduce the safety costs building The Formal Functional System Requirements have now to be written in / Take action

15 Thank you for your kind attention What is important is not only the goal, but the common work to reach it To do it well the first time or Slow and steady, wins the race Dr. Marc ANTONI, UIC - Director Rail System antoni@uic.org