18 September Licensing for Next Generation Signalling Buddhadev Dutta Chowdhury 27 th April 2012

Competence and Competency Competency needs to respond to: - Organisational Changes - Emerging Technologies - Change in Project Lifecycle - Change in Operation and Maintenance Regime Competency Models 18 September 20152

IRSE Licence 18 September IRSE Licensing - Competency benchmarking across the supply chain - Based on International Standard for Personal Certification ISO Covers a wide range: Design, Installation, Testing, Project Engineering and Technical - Is this adequate for future trends on signalling? - We may have to adapt some competency frameworks.

Signalling Evolution Mechanical Interlocking Electro-Mechanical Systems Relay Interlocking Solid State Interlocking Computer Based Interlocking Communication Based Train Control 18 September 20154

Change in contractual Arrangements Previous signalling contracts specified products - Client owned the system New contracts do not specify technical requirements. Instead they require performance-related criteria, such as: - Journey Time Capability - Reliability - Whole lifecycle cost - Clients endorse the system - Supplier owns the design of the system 18 September 20155

Complexity of Systems Combined effort to achieve performance Performance requirements apportionment Knowledge and understanding of all the key disciplines: - Signalling - Telecommunications - Rolling Stock - Control System - Traction - Traffic Control Simulation techniques 18 September 20156

Train Control System Architecture Interface 18 September 20157

Train-borne signalling Design competency Testing Competency Maintenance Competency - First Line Maintenance - Second Line Maintenance - Third Line Maintenance Rolling stock and Signalling systems integration are increasing in complexity. 18 September 20158

Signalling systems (hardware & Software) Moving towards common hardware platform. Software modifications to fulfil contract requirements are the main areas of change for new projects. Data modifications and preparation are required depending on the geographical layouts and constraints of the railway. 18 September 20159

Software Development Lifecycle 18 September

Software Reliability Assess qualitative failures Dependent on robustness Failure Rates: - Capability Maturity Model - Number of Lines of Code - Environmental Parameters - Decrease through Testing Process DRACAS Data Management 18 September

Data Preparation Systems configured by data Significant testing in factory prior to being released on site This is either software or data or a combination of both Common hardware platform with digital/serial/radio I/O Geographical data/map on trains or wayside No traditional relay interlocking 18 September

Embedded Software & SIL Levels Embedded software - Extra complexity - Extra functionality Safety Integrity level - Rolling Stock - Signalling 18 September

Communication Knowledge and Understanding Transmission theory Security + robustness + coding + signal processing Network architecture Interfaces, EMC 18 September

Voice Operation Comms Distributed mobile / fixed comms Routing Talk groups Network architecture Coding – real time Signal processing 18 September

Tools Computer for software interfaces Radio testing platforms Antenna Bespoke preparation tools based on the suppliers products. V&V tools System integration platforms (simulators/ emulators) Compliers (with high integrity levels) 18 September

Systems approach Total railway approach is required. Data and software from non-signalling systems may be critical. Interfaces are no longer only voltage free contacts but complex data channels. Examples include: Information to/from other train systems (TMS, ATO, Brake controllers / traction controllers) Interfaces to/from other wayside systems (Comms, ATS systems, passenger information etc) 18 September

Reliability Availability Maintainability Fundamental Principle of RAM analysis Domain experience of signalling Adopt Systems Engineering approach Failure data apportioned to signalling 18 September

Engineering Safety Hazard identification, log and management Interface hazard analysis SIL assessment / Tolerable hazard rates 18 September

Safety Case Evidence of quality management Evidence of safety management Evidence of functional and technical safety 18 September

Issues of Overview Specification Communication with other discipline / stake holders Visualisation of complete system Partitioning of the systems and apportionment 18 September

Complexity of Software adaptation 18 September

Regulatory & Guidance Documents Railway and Other guided Transport Systems (Safety) Regulations (ROGS) Company standards - Network Rail standards - London Underground Standards ORR Guidance Regulations Yellow Book 18 September

Competency Framework 18 September

Subject Areas 18 September

Further Break down 18 September

What we need Structured approach to competence management process Knowledge and understanding of functionality, architecture and interfaces including impacts on the other systems. 18 September

Conclusion Through knowledge of total operation and engineering systems Proven ability to the company business An understanding of rail industries Practical, commercial, financial management awareness and ability A defined roots for professional development 18 September

Thank You 18 September