This is a draft course description for a final year module to be taught in the Dept. of Computing Science, University of Glasgow in 1999-2000.
Comments and criticisms very welcome.
Safety-Critical Systems Development
Chris Johnson, University of Glasgow
**** IMPORTANT *****
The course notes and materials are now on-line at:
http://www.dcs.gla.ac.uk/~johnson/teaching/safety.
Thanks, Chris.
Rationale
Computers control many of the systems that protect us from death and injury.
Automatic braking systems are intended to reduce the risks of car accidents.
Medical imaging systems help in the diagnosis of diseases.
Even the programs that control our microwave cookers help to protect us from exposure to radiation.
This course will equip students with an initial understanding of the tools and techniques that are being used to aid the development of safety-critical systems.
An initial analysis of previous failures will work through current attempts
to standardise 'best practice'. We will then look at the problems that
complicate the design of safety-critical systems.
The course will end with a two week practical exercise.
Aims
This module encourages student's to apply software and hardware engineering techniques, learnt in other areas of the course, to support the development of safety-critical applications.
It also encourages students to consider the particular methodological and professional issues that surround the development of safety-critical systems.
Objectives
By the end of the course, students should:
- understand the professional and social issues involved in the design and testing of safety-critical systems;
- recognise the importance of standards and show a clear understanding of recent initiatives in this area;
- be able to apply a number of risk analysis techniques such as Faliure Modes, Effects and Criticality Analysis and Fault Tree Analysis;
- be able to apply a number of safety critical design techniques such as literate specification;
- be able to apply a number of safety critical evaluation techniques such as Black Box testing and the observational evaluation of operator performance;
- be able to identify the main characteristics of an appropriate safety culture within large organisations.
The presentation and treatment of this material is described below.
The course text book will be Nancy Leveson's Safeware: System safety and computers, Addison-Wesley, ISBN 0-201-11972-2.
Content
- Week 1:
Accident Analysis.
Lecture 1: Glasgow work on accident reporting.
Lecture 2: Ethics and pragmatics of systems development, including ACM guidelines.
- Week 2:
Standards and project management issues.
Lecture 1: UK DEF-STAN 00-55, US DoE, BCS/IEE work, DTI initiatives.
Lecture 2: ALARP, MORT and organisational failure.
- Week 3:
Requirements Analysis.
Lecture 1: The problems of requirements elicitation and management.
Lecture 2: Qualitative risk analysis, including FMECA and Fault trees.
- Week 4:
Mathematics of reliability.
Lecture 1: Probabilistic risk assessment, quantified fault trees and decision theory.
Lecture 2: Markov analysis, Monte Carlo simulation, Six deadly sins of statistical misinterpretation.
- Week 5:
Hardware Design
Lecture 1: redundancy, fault detection and fault tolerant architectures
Lecture 2: microprocessor design faults and electromagnetic compatability.
- Week 6:
Software Engineering
Lecture 1: Leveson's `designing for safety'; simplicity; decoupling; incremental control...
Lecture 2: The case for and against the use of formal methods.
- Week 7:
Human Factors.
Lecture 1: Rasmussen's knowledge, skills and rules. Norman's slips and lapses
Lecture 2: Reason and Hollnagel's error taxonomies.
- Week 8:
Testing and Maintenance
Lecture 1: evaluating functional requirements; dynamic and static testing.
Lecture 2: evaluating non-functional requirements; usability testing.
- Weeks 9 & 10:
Practical exercise
Pre-requisites
Level 3 Software Engineering and level 1 Human-Computer Interaction.
Credits
This course will be worth 10 credits.
Assessment
This course will be assessed through an examination (70%) and through a sustained practical exercise (30%).
The open assessment will be based upon a real-world case study.
This will focus upon one of three areas:
- requirements engineering;
- implementation;
- testing.
For example, a testing exercise might involve an analysis of the Ariane 5 failure and a report on the testing techniques that might be used to protect systems from the weaknesses of `legacy' software.
Similarly, an exercise on requirements engineering might begin by analysing the failure of the London ambulance system and might then proceed to plan requirements gathering for a call desk to support Strathclyde Regional Fire Brigade.
johnson@dcs.gla.ac.uk