Safety-Critical Systems 2

T 79.232

Ilkka Herttua

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)

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

Hazard probability

• Probability classes: Frequent

ProbableOccasionalRemoteImprobableIncredible

 

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)

 

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

 

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

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.

Development Methods

• Right Requirements phase 1-5

- complete – linking to hazards

- correct – testing & modelling

- consistent – semiformal language

- unambiguous - better 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

MaintenanceVerification and

ValidationAnalysing and

Writing

IdentifyingStakeholders and

ElicitingRequirements

Defining theProblem Context

Use

Managing Requirements

Resolving Conflicts

The REVEAL Process

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

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

“How do I manage change?”

Stay on track and meet schedule

Changes from allusers including

DOORSNetTM

Read-only user submits

“Change Proposal”

Changes reviewed on-line

Changes automatically

update module

Accepted

Rejected

Link

On Hold

In Review

Team Work: DOORS in Intranet/Internet

DOORSNetUser

Read, Comment, Review, Change Request submission

View by Browser Over the Web in your Project Data

DOORSUser

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

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)

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

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

Home assignments

• 4.18 (tolerable risk)

• 5.10 (incompleteness within specification)

Email before 25. February to herttua@eurolock.org