Safety-Critical Systems T- 79.232 Ilkka Herttua. Safety Context Diagram HUMANPROCESS SYSTEM -...
-
Upload
harry-smith -
Category
Documents
-
view
223 -
download
1
Transcript of Safety-Critical Systems T- 79.232 Ilkka Herttua. Safety Context Diagram HUMANPROCESS SYSTEM -...
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 10E-5 – 10E-4SIL 3 10E-4 – 10E-3SIL 2 10E-3 – 10E-2SIL 1 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
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.
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 Managementwith DOORS
Slides provided by Telelogic/ Quality Systems & Software
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 DOORSUser Demands System Requirements 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
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]