Safety-Critical Systems 2 Requirement Engineering T- 79.5303 Spring 2006 Ilkka Herttua

Safety-Critical Systems 2
Requirement Engineering
T- 79.5303 Spring 2006
Ilkka Herttua
Safety Context Diagram
HUMAN
PROCESS
SYSTEM
- Hardware
- Software
- Operating Rules
Critical Applications
• Computer based systems used in
avionics, chemical process and nuclear
power plants.
• A failure in the system endangers human
lives directly or through environment
pollution. Large scale economic influence.
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.
Developing safety-related
systems
• To achieve safety:
- safety requirements (avoiding hazards, risks)
- quality management (follow up process)
- design / system architecture (reliability)
- defined design/manufacture processes
- certification and approval processes
- known behaviour of the system in all conditions
1
Concept
2
System Definition and
Application Conditions
3
Risk Analysis
Overall safety lifecycle
4
System Requirements
5
Apportionment of
System Requirements
6
Design and Implementation
7
Manufacture
8
Installation
9
System Validation (including
Safety Acceptance and
Commissioning)
10
System Acceptance
12
Performance Monitoring
11
Operation and Maintenance
14
Decommissioning and Disposal
13
Modification and Retrofit
Re-apply Lifecycle
(See note)
Note: The phase at which a modification enters the life-cycle will be dependent upon both the system
being modified and the specific modification under consideration.
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 –2M GBP.
USA numbers higher.
Risk Analysis
• Classes:
- Catastrophic – multiple deaths >10
- 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
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)
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.
Fault event not
fully traced to its source
Basic event, input
Fault event resulting
from other events
OR connection
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”
Risk acceptability
Tolerable hazard rate (THR) – A hazard rate which guarantees that the
resulting risk does not exceed a target individual risk
SIL 4 =
SIL 3 =
SIL 2 =
SIL 1 =
10-9
10-8
10-7
10-6
< THR < 10-8
< THR < 10-7
< THR < 10-6
< THR < 10-5
per hour and per function
Potential Loss of Life (PLL) expected number of casualties per year
SIL = safety integrity level
Current situation / critical systems
•
a)
b)
c)
d)
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).
Examples of computer failures in
critical systems
V - Lifecycle model
Requirements Model
Requirements
Document
Test Scenarios
Knowledge Base *
Test Scenarios
Requirements
Analysis
Functional /
Architechural - Model
Systems
Analysis &
Design
Specification
Document
Software
Design
System
Acceptance
System
Integration & Test
Module
Integration & Test
Software
Implementation
& Unit Test
* Configuration controlled Knowledge
that is increasing in Understanding
until Completion of the System:
• Requirements Documentation
• Requirements Traceability
• Model Data/Parameters
• Test Definition/Vectors
Safety Requirements
• Requirements are stakeholders (customer)
demands – what they want the system to do.
Not defining how !!! => specification
• Safety requirements are defining what the
system must do and must not do in order to
ensure safety. Both positive and negative
functionality.
Specification
• Supplier instructions how to build the
system. Derived from the required
functionality = Requirements.
Requirements R + Domain Knowledge D
=> Specification S
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?
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
Requirement Engineering
Tools – Doors (Telelogic)
- Data base and configuration management
- History, traceability and linking
Requirements Management
with DOORS
Slides provided by
Telelogic/ Quality Systems & Software
Dynamic Object Oriented Requirements
System
Configurationmanagement
Reports
Analysis
Interfaces
Effizienz
DOORS
Text Processing
Templates, Standards
Requirements
Links
Multiuser-Databank
User Accounts
Change Proposal System
Filter, Views
Capture, Link, Trace, Analyse, Administer
Terminology in DOORS
Project
Consists of numerous Modules
Module
One Document,
Group of related Information
Requirements, Tests, Specifications,
Change Requests, etc
Object
Links
Object
Object
Object
Data of a Module
Attribute
Attribute
Relation between
two Objects
Attribute
Characteristics of Objects or Links
Date of last Change, Priority,
Status, Costs, ...
Traceability in DOORS
Requirement
Specification
Architectural
Design
Test
Plan
Follow Customer Ammendments through all the Documentation
Traceability - Requirements from
Scenarios
Boat
loaded
Boat lifted
Boat on car
Ready to sail
Boat
unloaded
Boat
rigged
To have
sailed
and
survived
Two people shall be able
to lift the boat onto the
roof of the average
saloon car.
Mast rigged
Center-plate
rigged
traceability
Rudder
rigged
The sailor shall be able to
perform a tacking
manoeuvre.
Goal hierarchy
Gibed
Tacked
Sailed
Boat
manoeuvred
user requirements
Cruised
Boat
capsized
Returned
home
Boat righted
Coast guard
contacted
Gone ashore
The sailor shall be able to
contact the coastguard
when the boat is
capsized.
V - Lifecycle model
Requirements Model
Requirements
Document
Test Scenarios
Knowledge Base *
Test Scenarios
Requirements
Analysis
Functional /
Architechural - Model
Systems
Analysis &
Design
Specification
Document
Software
Design
System
Acceptance
System
Integration & Test
Module
Integration & Test
Software
Implementation
& Unit Test
* Configuration controlled Knowledge
that is increasing in Understanding
until Completion of the System:
• Requirements Documentation
• Requirements Traceability
• Model Data/Parameters
• Test Definition/Vectors
Additional home assignments
• From Neil Storey’s book Safety Critical
Computer Systems
• 1.12 (Please define primary, functional and
indirect safety)
• 2.4 (Please define unavailability)
Email by 1 March to herttua@eurolock.org