Presenting a Safety Case A case study

1

• Presenting a Safety Case- A case study -
• Odd NordlandSINTEF Telecom and
  Informaticshttp//www.informatics.sintef.no/nor
  dlandmailtoOdd.Nordland_at_informatics.sintef.no

2
Introduction

• Automatic Train Protection systems and
  interlocking systems have become more complex
• they rely heavily on microprocessors and
  software
• CENELEC Railway Application Standards
• Describe WHAT to dobut say less about HOW
• Applying the standards is a currently learning
  exercise

3
Computer Based Interlocking

• Interlocking Processing Unit (IPU)
• processes data according to interlocking rules
• controls OCS
• Object Controller System (OCS)
• receives orders from the IPU
• sends messages to wayside objects (signals,
  transponders etc.)
• receives status information back
• sends status to IPU
• Software
• generic information about interlocking rules
• generic data about types of objects to control
• specific information about actually connected
  objects
• SW generation process
• highly automated
• performed for each specific application

4
Computer Based Interlocking (cont'd)

• purpose
• receives data from trains (position, speed etc.)
• contains data about route, station ("geography,
  topology")
• contains data about interlocking rules
• sends messages to trains and drivers
• controls signals, point switches etc.
• based on an older system
• adapted to the Norwegian market
• Safety Case according to the CENELEC standards

5
Safety Case

• What kind of CASE?
• special case?
• briefcase?
• suitcase?
• bookcase?
• legal case?
• safety case!
• The Safety Case is a line of argumentation, not
  just a collection of facts!
• The Safety Case contents
• Definition of System
• Quality Management Report
• Safety Management Report
• Technical Safety Report
• Related Safety Cases
• The Conclusion

6
The Safety Case contents

• Definition of System
• a description of the system
• the product structure
• interfaces (internal, external)
• issue/revision resp. version data!
• Quality Management Report
• the quality requirements
• the quality management system
• the quality management activities

7
The Safety Case contents (cont'd)

• Safety Management Report
• the safety requirements
• the safety management system
• the safety management activities
• Technical Safety Report
• Introduction
• Assurance of correct functional operation
• Effects of faults
• Operation with external influences
• Safety related application conditions
• Safety qualification tests

8
The Safety Case contents (cont'd)

• Related Safety Cases
• Safety cases of parts, components etc.
• certificates, licenses, ...
• Safety related application conditions
• what the components require
• The Conclusion
• This shall summarise the evidence presented in
  the previous parts of the Safety Case, and argue
  that the relevant system/subsystem/equipment is
  adequately safe, subject to compliance with the
  specified application conditions.

9
The Safety Case family

• Generic product Safety Case(independent of
  application)A generic product can be re-used for
  different independent applications.
• Generic application Safety Case(for a class of
  application)A generic application can be re-used
  for a class/type of application with common
  functions.
• Specific application Safety Case(for a specific
  application)A specific application is used for
  only one particular installation.

10
Problems encountered

• the scope of necessary documentation was
  underestimated
• adapting existing company procedures to new
  standards is slow
• legacy products
• products were developed before the standards came
• their documentation was not conformant with the
  standard
• retrospective documentation of personnel
  qualification
• dynamic development
• the system was upgraded on the way
• existing documentation suddenly became out of
  date
• embedded processes
• CBI includes a generation process for software
• the standards do not deal with proving that a
  process is safe

11
Lessons learnt

• The CENELEC standards don't cover all aspects of
  a real development
• suppliers, operators and assessors should agree
  on how to proceed at the start of the project
• Modifications during the process are expensive
• get your system safe first, then upgrade it
• delta safety case for the upgrade
• Start adapting procedures to the standards NOW
• the standards are here to stay
• the sooner you're compliant, the easier life will
  become
• Document history
• keep CVs of key personnel
• keep development records
• keep descriptions of old procedures
• Understand the standards
• learning by doing is expensive
• know what to do at the start, then you'll avoid
  expensive blunders