Safety-Critical Systems 2

1
Safety-Critical Systems 2

• T 79.232
• Ilkka Herttua

2
Main topics for spring 2003

• Fault tolerance/reliability (III)
• Hardware/Programmable Logic Controllers (III)
• Safety-Critical Software (IV)
• Formal Methods modelling (IV/V)
• Verification/Validation and Testing (V)
• Seminars (VI)

3
Risk Analysis

• Risk is a combination of the severity (class) and
  frequency (probability) of the hazardous event.
• Classes - Catastrophic multiple deaths
• - Critical a death or severe injuries
• - Marginal a severe injury
• - Negligible a minor injury

4
Hazard probability

• Probability classes
• Frequent
• Probable
• Occasional
• Remote
• Improbable
• Incredible
•  

5
Risk acceptability

• National/international decision level of an
  acceptable loss (ethical, political and
  economical)
• Risk Analysis Methods
• ALARP as low as reasonable practical (UK, USA)
• GAMAB not greater than before (France)
•  

6
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-4
• SIL 3 10E-4 10E-3
• SIL 2 10E-3 10E-2
• SIL 1 10E-2 10E-1
•  

7
V - Lifecycle model
8
Overall safety lifecycle

•  

9
Development Methods

• Right Requirements phase 1-5
• - complete linking to hazards
• - correct testing modelling
• - consistent semiformal language
• - unambiguous - better English
•  

10
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
•  
•  

11
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

12
The REVEAL Process
13
On-going Processes

• Management
• Baselining
• Tracing
• Change management
• Fault management
• Use of tools
• Conflict Management
• Identification of conflicts
• Negotiation
• Recording conflict and outcome for future change
  management

14
Requirements Management with DOORS
Slides provided by Telelogic/ Quality Systems
Software
15
Dynamic Object Oriented Requirements System
Interfaces
Configuration- management
Requirements Links
Effizienz
DOORS
Reports Analysis
Multiuser-Databank User Accounts
Change Proposal System Filter, Views
Text Processing Templates, Standards
Capture, Link, Trace, Analyse, Administer
16
Terminology in DOORS
Project
Module
17
How do I manage change?
Read-only user submits Change Proposal
Changes automatically update module
Accepted
Changes reviewed on-line
On Hold
In Review
Rejected
Stay on track and meet schedule
18
Team Work DOORS in Intranet/Internet
View by Browser Over the Web in your Project
Data
DOORS User
DOORSNet User
Read, Comment, Review, Change Request submission
19
Traceability in DOORS
Architectural Design
User Demands
System Requirements
Test Plan
Follow Customer Ammendments through all the
Documentation
20
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
21
References

• Telecommunications ATT, Alcatel, British
  Telecom, General Dynamics, ITT, L3 Comm, MCI
  Worldcom, Motorola, Nokia, Nortel, Tellabs
• Defense/Aerospace Boeing, Jet Propulsion Labs,
  Lockheed Martin, Raytheon
• Equipment Manufacturers Cadence, Carrier, Cisco
  Systems, Hewlett Packard, Kodak, Otis Elevator,
  Pitney Bowes, Xerox
• Automotive BMW, Chrysler Daimler-Benz , Ford,
  General Motors, Rolls-Royce
• Financial/Insurance Citicorp, Experian, Freddie
  Mac, Mastercard, NASD/NASDAQ/ASE, Nations Bank,
  Norwest Financial Services, Prudential, State
  Farm, UNUM, USAA, VISA
• Government CND, FDA, FAA, MoD, NIMA, NASA, NSA,
  DISA, IRS, DOD
• Healthcare/Medical Abbott Labs, Beckman
  Instruments, GE Medical, HP Medical,
  Kaiser Permanente, Siemans Medical
• Systems Integrators Booz Allen, CSC, EDS, IBM,
  Litton/PRC, Mitre, SAIC, Unisys

22
Designing for Safety

• Faults groups
• - requirement/specification errors
• - random component failures
• - systematic faults in design (software)
• Approaches to tackle problems
• - right system architecture (fault-tolerant)
• - reliability engineering (component, system)
• - quality management (designing and producing
  processes)

23
Designing for Safety

• Hierarchical design
• - simple modules, encapsulated functionality
• - separated safety kernel safety critical
  functions
• Maintainability
• - preventative versa corrective maintenance
• - scheduled maintenance routines for whole
  lifecycle
• - easy to find faults and repair short MTTR
  mean time to repair
• Human error
• - Proper HMI

24
Safety management

• Safety culture/policy of the organisation
• - Task for management ( Tarkets )
• Safety planning
• - Task for safety manager ( How to )
• Safety reporting
• - All personal
• - Safety log / validation reports

25
Home assignments

• 4.18 (tolerable risk)
• 5.10 (incompleteness within specification)
• Email before 25. February to herttua_at_eurolock.org