safety critical systems 2 requirement engineering n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Safety-Critical Systems 2 Requirement Engineering PowerPoint Presentation
Download Presentation
Safety-Critical Systems 2 Requirement Engineering

Loading in 2 Seconds...

play fullscreen
1 / 28

Safety-Critical Systems 2 Requirement Engineering - PowerPoint PPT Presentation


  • 174 Views
  • Uploaded on

Safety-Critical Systems 2 Requirement Engineering. T- 79.5303 Spring 2008 Ilkka Herttua. Critical Applications. Computer based systems used in transportation, chemical process and nuclear power plants.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Safety-Critical Systems 2 Requirement Engineering' - rea


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
safety critical systems 2 requirement engineering

Safety-Critical Systems 2Requirement Engineering

T- 79.5303 Spring 2008

Ilkka Herttua

critical applications
Critical Applications
  • Computer based systems used in transportation, chemical process and nuclear power plants.
  • A failure in the system endangers human lives directly or through environment pollution. Also preferable approach for systems, which have large scale economic influence. (telecom, space)
safety context diagram
Safety Context Diagram

HUMAN

PROCESS

  • Operating Rules
  • Physical Facts

SYSTEM

  • Designing
  • Operating
  • - Hardware
  • Software
  • Technology
current situation critical systems
Current situation / critical systems
  • 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).
safety definition
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.

v lifecycle model

Requirements Model

Requirements

Analysis

Test Scenarios

Test Scenarios

System

Acceptance

Requirements

Document

Functional /

Architechural - Model

System

Integration & Test

Systems

Analysis & Design

Specification

Document

Knowledge Base *

Software

Design

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
V - Lifecycle model
developing safety related systems
Developing safety-related systems
  • To achieve safety:

1. safety requirements (avoid possible hazards, risks)

2. quality management (follow up process)

3. design / system architecture (reliability)

4. defined design/manufacture processes

5. certification and approval processes (testing, proving)

6. known behaviour of the system in all conditions (modelling, formal verification)

1 define the problem context
1. Define the Problem Context
  • Understanding the whole context
    • The problem context, and
    • The problem
  • Setting the boundary
    • The application domain
    • The system
    • Their boundary
  • Describing the context
    • Traditional context diagrams
    • The importance of showing the whole domain
safety requirements
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
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
Where do we go wrong?
  • Many system failures are not failures to understand R requirements ; they are mistakes inD 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
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
Requirement Engineering

Tools – Doors (Telelogic)

  • Data base and configuration management
  • History, traceability and linking
slide16

Consultants

KnowGravity

DOORS

Requirements

Database

Euro-Interlocking Core Team

Railway Domain Experts

Project Development Process

Requirements Simulation

RequirementsValidation via Simulation

Requirements

Modelling

Capture

requirements

Furnish Railway

requirements

traceability in doors
Traceability in DOORS

Architectural

Design

Requirement

Specification

Test

Plan

Follow Customer Ammendments through all the Documentation

traceability requirements from scenarios
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

risk analysis
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 –2,5M Euro.

USA numbers higher.

risk analysis1
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
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
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.

slide24

Fault event not

fully traced to its source

Basic event, input

Fault event resulting

from other events

OR connection

risk acceptability
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 acceptability1
Risk acceptability

Tolerable 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

v lifecycle model1

Requirements Model

Requirements

Analysis

Test Scenarios

Test Scenarios

System

Acceptance

Requirements

Document

Functional /

Architechural - Model

System

Integration & Test

Systems

Analysis & Design

Specification

Document

Knowledge Base *

Software

Design

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
V - Lifecycle model
additional home assignments
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 14 February to herttua@uic.asso.fr