Licensing for Next Generation Signalling
Buddhadev Dutta Chowdhury
27th April 2012
9 April 2015
1
Competence and Competency
Competency needs to respond to:
- Organisational Changes
- Emerging Technologies
- Change in Project Lifecycle
- Change in Operation and
Maintenance Regime
 Competency Models

9 April 2015
2
IRSE Licence

IRSE Licensing
- Competency benchmarking across the supply
chain
- Based on International Standard for Personal
Certification ISO 17024
- 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.
9 April 2015
3
Signalling Evolution






Mechanical Interlocking
Electro-Mechanical Systems
Relay Interlocking
Solid State Interlocking
Computer Based Interlocking
Communication Based Train Control
9 April 2015
4
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
9 April 2015
5
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
9 April 2015
6
Train Control System
Architecture Interface
9 April 2015
7
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.

9 April 2015
8
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.
9 April 2015
9
Software Development
Lifecycle
9 April 2015
10
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
9 April 2015
11
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
9 April 2015
12
Embedded Software & SIL
Levels


-
Embedded software
Extra complexity
Extra functionality
Safety Integrity level
Rolling Stock
Signalling
9 April 2015
13
Communication Knowledge and
Understanding




Transmission theory
Security +
robustness + coding
+ signal processing
Network architecture
Interfaces, EMC
9 April 2015
14
Voice Operation Comms






Distributed mobile / fixed comms
Routing
Talk groups
Network architecture
Coding – real time
Signal processing
9 April 2015
15
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)
9 April 2015
16
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)
9 April 2015
17
Reliability Availability
Maintainability




Fundamental Principle of RAM analysis
Domain experience of signalling
Adopt Systems Engineering approach
Failure data apportioned to signalling
9 April 2015
18
Engineering Safety



Hazard identification, log and management
Interface hazard analysis
SIL assessment / Tolerable hazard rates
9 April 2015
19
Safety Case



Evidence of quality management
Evidence of safety management
Evidence of functional and technical safety
9 April 2015
20
Issues of Overview
Specification



Communication with other discipline / stake
holders
Visualisation of complete system
Partitioning of the systems and
apportionment
9 April 2015
21
Complexity of Software
adaptation
9 April 2015
22
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
9 April 2015
23
Competency Framework
9 April 2015
24
Subject Areas
9 April 2015
25
Further Break down
9 April 2015
26
What we need


Structured approach to competence
management process
Knowledge and understanding of
functionality, architecture and interfaces
including impacts on the other systems.
9 April 2015
27
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
9 April 2015
28
Thank You
9 April 2015
29