safety-critical systems 2 requirement engineering t- 79.5303 spring 2006 ilkka herttua
TRANSCRIPT
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
Overall safety lifecycle
Concept1
System Acceptance10
System Validation (including Safety Acceptance and
Commissioning)
9
Installation8
Design and Implementation
6
Apportionment of System Requirements
5
Performance Monitoring12
Modification and Retrofit13
System Definition and Application Conditions
2
Re-apply Lifecycle(See note)
Risk Analysis3
Operation and Maintenance11
System Requirements4
Manufacture7
Decommissioning and Disposal
14
Note: The phase at which a modification enters the life-cycle will be dependent upon both the systembeing 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,01Occasional 0,001Remote 0,0001Improbable 0,00001Incredible 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 notfully traced to its source
Basic event, input
Fault event resultingfrom 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 acceptabilityTolerable hazard rate (THR) – A hazard rate which guarantees that the
resulting risk does not exceed a target individual risk
SIL 4 = 10-9 < THR < 10-8 per hour and per function
SIL 3 = 10-8 < THR < 10-7
SIL 2 = 10-7 < THR < 10-6
SIL 1 = 10-6 < THR < 10-5
Potential Loss of Life (PLL) expected number of casualties per year
SIL = safety integrity level
Current situation / critical systems
• Based on the data on recent failures of critical systems, the following can be concluded:
a) Failures become more and more distributed and often nation-wide (e.g. air traffic control and commercial systems like credit card denial of authorisation)
b) The source of failure is more rarely in hardware (physical faults), and more frequently in system design or end-user operation / interaction (software).
c) The harm caused by failures is mostly economical, but sometimes health and safety concerns are also involved.
d) Failures can impact many different aspects of dependability (dependability = ability to deliver service that can justifiably be trusted).
V - Lifecycle model
SystemAcceptance
System Integration & Test
Module Integration & Test
Requirements Analysis
Requirements Model
Test Scenarios Test Scenarios
SoftwareImplementation
& Unit Test
SoftwareDesign
Requirements Document
Systems Analysis &
Design
Functional / Architechural - Model
Specification Document K
now
led
ge B
ase
** 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
Dynamic Object Oriented Requirements System
Effizienz
InterfacesRequirements
Links
ReportsAnalysis
Change Proposal SystemFilter, Views
Multiuser-DatabankUser Accounts
Configuration-management
Text ProcessingTemplates, Standards
DOORS
Capture, Link, Trace, Analyse, Administer
Terminology in DOORS
One Document, Group of related Information
Requirements, Tests, Specifications,Change Requests, etc
Consists of numerous ModulesProject
Module
Object
Object
Object
Object Attribute
Attribute
Attribute
Data of a Module
Characteristics of Objects or Links
Date of last Change, Priority, Status, Costs, ...
Relation betweentwo Objects
Links
Traceability in DOORSRequirement Specification Architectur
alDesign
TestPlan
Follow Customer Ammendments through all the Documentation
Traceability - Requirements from Scenarios
Goal hierarchy
user requirements
traceability
Two people shall be able to lift the boat onto the
roof of the average saloon car.
The sailor shall be able to contact the coastguard
when the boat is capsized.
The sailor shall be able to perform a tacking
manoeuvre.
To have sailedand
survived
Ready to sail
Sailed
Returnedhome
Boatloaded
Boat lifted
Boatunloaded
Boatrigged
Boat on car
Mast rigged
Center-plate rigged
Rudder rigged
Gibed
Boatmanoeuvred
Tacked
Cruised
Boatcapsized
Gone ashore
Boat righted
Coast guardcontacted
V - Lifecycle model
SystemAcceptance
System Integration & Test
Module Integration & Test
Requirements Analysis
Requirements Model
Test Scenarios Test Scenarios
SoftwareImplementation
& Unit Test
SoftwareDesign
Requirements Document
Systems Analysis &
Design
Functional / Architechural - Model
Specification Document K
now
led
ge B
ase
** 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 [email protected]