Download Safety-Critical Systems

Safety-Critical Systems
T- 79.232
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.
Safety Definition
• Safety integrity:
The likelihood of a safety-related system
achieving its required safety features under
all the stated conditions within a stated
operational environment and within a stated
period of time.
• SIL levels 0 to 4.
• SIL 4 is the highest safety integrity level.
Integrity levels
Safety Integrity is a measure of the likelihood
of the safety system correctly performing its
task.
Safety Integrity levels: (failures/year)
SIL 4
SIL 3
SIL 2
SIL 1
10E-5 – 10E-4
10E-4 – 10E-3
10E-3 – 10E-2
10E-2 – 10E-1
Verification and validation
• Verification is the process of determining
that a system or module meets its
specification.
• Validation is the process of determining
that a system is appropriate for its purpose.
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.
Requirement 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
• Methods – Reveal (UK)
- All necessary included, right structure and
understandable wording.
• Tools – Doors (Telelogic)
- Data base and configuration management
- History, traceability and linking
REVEAL
• REVEAL is a requirements engineering method
(Praxis UK)
– independent of particular notations
– compatible with different tools
• The application of scientific principles
– the role of domain knowledge in relating requirements
to specifications
• Through a systematic process
– what has to be done
– what order it should be done in
– how it can be done
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
User Demands
System Requirements
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
Developing safety-related
systems
• To achieve safety:
- safety requirements
- quality management
- design / system architecture (RAM)
- defined design/manufacture processes
- certification and approval processes
- known behaviour of the system in all conditions
RAM
• Reliability is the probability of a component or system
functioning correctly over a given period of time under a
given set of operating conditions. (MTBF mean time
between failure.)
• The availability of a system is the probability that the
system will be functioning correctly at any given time.
• Maintainability: Maintenance is the action taken to retain
a system in or return a system to its designed operating
condition. (MTTR mean time to repair.)
Fault, error and failure
• A fault is defect within the system.
Random faults – hardware components, systematic faults
– software/hardware design and manufacture processes.
• An error is a deviation from the required operation of the
system or subsystem.
• A system failure occurs when the system fails to perform
its required function. (Significant, major and minor)
Fault management
Fault management techniques:
• Fault avoidance – in entire system design phase
• Fault removal - before system enters service
• Fault detection – during service to minimising
effects
• Fault tolerance – operate correctly in the presence
of faults
Home assignments
• 1.12 (primary, functional and indirect safety)
• 2.4 (unavailability)
Email by 14 February to [email protected]