A. Introduction

It is difficult to provide a realistic exercise in a one-term course on safety-critical systems development. In particular, it is hard to avoid using COTS or a contrived example. Instead, I want to pose a design challenge that may have significant real-world benefits. The challenge is to support the on-line presentation of accident reports. You are free to choose an appropriate presentation format and to choose which accident you will look at.

The main point behind this exercise is to move beyond paper-based presentation techniques for accident and incident reports. The on-line documents produced by the FAA, NTSB and CAA tend to be direct translations of their paper based versions (for more examples of this see www.dcs.gla.ac.uk/research/gaag/links.html). This ignores the opportunities provided by electronic media. I have written a paper about improving the presentation of accident reports .

Warning: you are not accident investigators. Therefore, it is important that you minimise any unnsupported interpretation of the evidence presented in the reports. In particular, it is not the purpose of your analysis to assign blaim to any individual or organisation involved in the incident.

B. Your Task: Alternative Presentation Formats for Accident Reports

• Approach 1: single accident visualisation.
  You can approach this task in a number of ways. For instance, you could design a presentation that maps the events described in the site onto the various components of Reason's model (see lecture 1). Alternatively, you could use a set of FMECA tables to provide an overview of the consequences of the different failures that are described in the report. Criticality and discovery rankings could also be included to reflect the interpretation in the report. Elsewhere, I have used fault trees to provide an overview of an accident. If you decide to use any of these approaches then image map techniques might be used to link the elements of the graphical structures back to the text of the incident report itself. It is also possible to use VRML, QuicktimeVR or any other visualisation technique providing that they support the presentation of the accident report. The central point here is that your site must effectively present information about key failures in the development and operation of a safety critical system.

• Approach 2: special study visualisation.
  An alternative approach is to look at one of the overview reports presented by the various investigation agencies. For example, the US National Transportation Board have commissioned a number of studies that look at common factors across several different incidents and accidents. You might choose to support these documents by providing information about "prototypical" incidents based on these common features in an accident. This might be done using VRML simulations of an accident or through a succession of simpler graphical images. At the very least, it should be possible to navigate between multiple accounts of similar failures. Something which has not been tried before but which I would like to recommend is for you to produce a report that links accidents with similar features/common causes in more than one industry. An example would be a collection of pages describing mode confusion problems (roughly speaking - where operators fail to predict the effects of their input) or communications failure amongst teams of operators. The key point here is that your site must effectively present information about common failures in the development and operation of several safety critical systems.

• Approach 3: accident search engines.
  Finally, you might like to exploit information retrieval techniques to index and search for accident reports over a number of different sites. This would enable readers to look for several different accident reports all dealing with problems such as "high workload" or "situation awareness". The US Federal Aviation Authority already have a simple system in place - something like this might be extended over multiple sites. The key point here is that users can search for those aspects of an accident report that document key failures in the development and operation of safety critical systems.

C. The Design Brief

In the documentation (see below) that you submit with your solutions, it is very important that you explain who the users of your system will be. You must also specify the particular information needs that the site will support.

D. Assessment Criteria and Submission Details

This exercise is degree assessed. It contributes 30% to the total marks associated with this course. The body of the report should not exceed twenty A4 pages. The report must be printed out and must be submitted in a secure binder (i.e., one that will keep the pages together and in the correct order). It must include:

1. A title page containing the name of the student as well as their contact details (email address etc);
   
2. A table of contents and appropriate page numbers;
   
3. A section on the design of the system. This should include some consideration of alternative approaches and a considered justification of the reasons why you build the system in the way that you did.
   
4. An implementation section. This should describe the techniques that you used during the development of your system.
   
5. An evaluation section. This must consider both formative and summative testing. Formative evaluation might include user testing of pencil and paper prototypes and of partial implementations. Summative evaluation describes the testing of the final system.

1. the listing of any code used during the implementation together with suitable acknowledgements for the source of code that has been borrowed from other programmers;
   
2. internal documentation (maximum two sides). These are notes that are intended to provide guidance for anyone who must maintain or develop your system.

The following marking scheme will be applied:

• 15 for the design;
• 15 for the implementation;
• 10 for the evaluation;
• 10 for the technical documentation.

Back to the main index...