SafetyCritical Systems 2 Requirement Engineering

1
Safety-Critical Systems 2Requirement Engineering

• T- 79.5303 Spring 2008
• Ilkka Herttua

2
Critical Applications

• Computer based systems used in transportation,
  chemical process and nuclear power plants.
• A failure in the system endangers human lives
  directly or through environment pollution. Also
  preferable approach for systems, which have large
  scale economic influence. (telecom, space)

3
Examples of computer failures in critical systems
4
Safety Context Diagram
HUMAN
PROCESS

• Operating Rules
• Physical Facts

SYSTEM

• Designing
• Operating

• - Hardware
• Software
• Technology

5
Current situation / critical systems

• Based on the data on recent failures of critical
  systems, the following can be concluded
• Failures become more and more distributed and
  often nation-wide (e.g. air traffic control and
  commercial systems like credit card denial of
  authorisation)
• The source of failure is more rarely in hardware
  (physical faults), and more frequently in system
  design or end-user operation / interaction
  (software).
• The harm caused by failures is mostly economical,
  but sometimes health and safety concerns are also
  involved.
• Failures can impact many different aspects of
  dependability (dependability ability to deliver
  service that can justifiably be trusted).

6
Safety Definition

• Safety
• Safety is a property of a system that it will
  not endanger human life or the environment.
• Safety-Critical System
• A system that is intended to achieve, on its
  own, the necessary level of safety integrity for
  the implementation of the required safety
  functions.

7
V - Lifecycle model
8
Overall safety lifecycle

•  

9
Developing safety-related systems

• To achieve safety
• 1. safety requirements (avoid possible
  hazards, risks)
• 2. quality management (follow up process)
• 3. design / system architecture
  (reliability)
• 4. defined design/manufacture processes
• 5. certification and approval processes
  (testing, proving)
• 6. known behaviour of the system in all
  conditions (modelling, formal verification)
•  

10
1. Define the Problem Context

• Understanding the whole context
• The problem context, and
• The problem
• Setting the boundary
• The application domain
• The system
• Their boundary
• Describing the context
• Traditional context diagrams
• The importance of showing the whole domain

11
Data. Prep. system
Installation rules and track layout
Maintenance
Environment
Human
National rules
Power source
Traffic control system
Diagnostics system
Boundary 2
RBC
Route Setting
Control
EURO-INTERLOCKING Context diagram working draft,
28.03.00.
Object Controller
Power Supply
Train
12
Safety Requirements

• Requirements are stakeholders (customer) demands
  what they want the system to do. Not defining
  how !!! gt specification
• Safety requirements are defining what the system
  must do and must not do in order to ensure
  safety. Both positive and negative functionality.
•  

13
Specification

• Supplier instructions how to build the system.
  Derived from the required functionality
  Requirements.
• Requirements R Domain Knowledge D gt
  Specification S

14
Where do we go wrong?

• Many system failures are not failures to
  understand R requirements they are mistakes in
  D domain knowledge
• A NYC subway train crashed into the rear end of
  another train on 5th June 1995. The motorman ran
  through a red light. The safety system did apply
  the emergency brakes. However the ...signal
  spacing was set in 1918, when trains were
  shorter, lighter and slower, and the emergency
  brake system could not stop the train in time.
• Are you sure?

15
Requirement Engineering Right Requirements

• Ways to refine Requirements
• - complete linking to hazards (possible
  dangerous events)
• - correct testing modelling
• - consistent semi/formal language
• - unambiguous text in real English
•  

16
Requirement Engineering

• Tools Doors (Telelogic)
• Data base and configuration management
• History, traceability and linking
•  
•  

17
Project Development Process
Requirements Simulation
RequirementsValidation via Simulation
Requirements Modelling
Capture requirements
Furnish Railway requirements
18
Traceability in DOORS
Architectural Design
Requirement
Specification
Test Plan
Follow Customer Ammendments through all the
Documentation
19
Traceability - Requirements from Scenarios
Boat lifted
Boat loaded
Two people shall be able to lift the boat onto
the roof of the average saloon car.
Boat on car
Ready to sail
Boat unloaded
Mast rigged
Center-plate rigged
traceability
Boat rigged
To have sailed and survived
Rudder rigged
The sailor shall be able to perform a tacking
manoeuvre.
Goal hierarchy
Gibed
user requirements
Tacked
Boat manoeuvred
Sailed
Cruised
The sailor shall be able to contact the
coastguard when the boat is capsized.
Boat righted
Boat capsized
Returned home
Coast guard contacted
Gone ashore
20
(No Transcript)
21
Risk Analysis

• Risk is a combination of the severity (class) and
  frequency (probability) of the hazardous event.
• Risk Analysis is a process of evaluating the
  probability of hazardous events.
• The Value of life??
• Value of life is estimated between 0.75M 2,5M
  Euro.
• USA numbers higher.

22
Risk Analysis

• Classes - Catastrophic multiple deaths
  gt10
• - Critical a death or severe injuries
• - Marginal a severe injury
• - Insignificant a minor
  injury
• Frequency Categories
• Frequent 0,1 events/year
• Probable 0,01
• Occasional 0,001
• Remote 0,0001
• Improbable 0,00001
• Incredible 0,000001

23
Hazard Analysis

• A Hazard is situation in which there is actual or
  potential danger to people or to environment.
• Analytical techniques
• - Failure modes and effects analysis (FMEA)
• - Failure modes, effects and criticality
  analysis (FMECA)
• - Hazard and operability studies (HAZOP)
• - Event tree analysis (ETA)
• - Fault tree analysis (FTA)

24
Fault Tree Analysis 1
The diagram shows a heater controller for a tank
of toxic liquid. The computer controls the heater
using a power switch on the basis of information
obtained from a temperature sensor. The sensor is
connected to the computer via an electronic
interface that supplies a binary signal
indicating when the liquid is up to its required
temperature. The top event of the fault tree is
the liquid being heated above its required
temperature.
 
25
Fault event not fully traced to its source
Basic event, input
Fault event resulting from other events
OR connection
26
Risk acceptability

• National/international decision level of an
  acceptable loss (ethical, political and
  economical)
• Risk Analysis Evaluation
• ALARP as low as reasonable practical (UK, USA)
• Societal risk has to be examined when there is
  a possibility of a catastrophe involving a large
  number of casualties
• GAMAB Globalement Au Moins Aussi Bon not
  greater than before (France)
• All new systems must offer a level of risk
  globally at least as good as the one offered by
  any equivalent existing system
• MEM minimum endogenous mortality
• Hazard due to a new system would not
  significantly augment the figure of the minimum
  endogenous mortality for an individual
•  

27
Risk acceptability

• Tolerable hazard rate (THR) A hazard rate which
  guarantees that the resulting risk does not
  exceed a target individual risk
• SIL 4 10-9 lt THR lt 10-8 per hour
  and per function
• SIL 3 10-8 lt THR lt 10-7
• SIL 2 10-7 lt THR lt 10-6
• SIL 1 10-6 lt THR lt 10-5
• Potential Loss of Life (PLL) expected number of
  casualties per year
• SIL safety integrity level
•  

28
V - Lifecycle model
29
Additional home assignments

• From Neil Storeys book Safety Critical Computer
  Systems
• 1.12 (Please define primary, functional and
  indirect safety)
• 2.4 (Please define unavailability)
• Email by 14 February to herttua_at_uic.asso.fr