The Why-Because Analysis Homepage

Contents


What is WBA?
Why-Because Analysis (WBA) is a rigorous technique for causally analysing the behaviour of complex technical and socio-technical systems. Its primary application is in the analysis of accidents, mainly to transportation systems (air, rail and sea). It is also used in the Ontological Analysis method for safety requirements analysis during system development.

WBA is based on a rigorous notion of causal factor. Whether one event or state is a causal factor in the occurrence of another is determined by applying the Counterfactual Test. The Counterfactual Test was proposed by the philosophical logician David Lewis in 1975, who credited David Hume (1770's) and has withstood detailed philosophical criticism since. During analysis, a Why-Because Graph (WB-Graph or WBG) is built showing the causal connections between all events and states of the behaviour being analysed. The completed WB-Graph is the main output of WBA.

The WB-Graph provides a rigorous causal explanation of the behaviour being analysed. However, mistakes may be made in constructing the WB-Graph, as with any human activity. To detect such mistakes, WBA provides a formal proof method which allows one to check whether the WB-Graph is correct and relatively complete. The formal proof method is based on the logic EL, a multi-modal logic based inter alia on Lamport's TLA and Lewis's Causal Logic. Most users of WBA do not feel the need to check their WB-Graphs using the formal proof procedures, but for those who do, it is there. WBA is the only accident analysis method with such a formal consistency/completeness check.

There is one-page description of WBA and a short history (PDF) of WBA.

A detailed description of the WBA process has been prepared by Thilo Paul-Stüve, based on his hierarchical task analysis (HTA) of WBA. It includes

back to contents...


WBA Training Course and Tutorial

A two-day WBA training course is available. It consists of a WBA Tutorial, and participant hands-on exercises using the WB-Toolset. The WBA Tutorial is one day, without participant exercises. The Tutorial has been given inter alia at the Safety@Siemens 2000 conference in Munich, and at Siemens Transportation Systems in Braunschweig. The WBA training course in its present form has been given three times in Australia in 2004 under the auspices of the Australian Safety-Critical Systems Club and twice in 2005 under the auspices of the Australian Aviation Psychology Association and the Civil Aviation Safety Authority, as well as to industrial clients in the transportation industry in Europe. Contact Peter Ladkin.

back to contents...


WB-Toolset

We have a suite of software tools, based extensively on open source software, which aid in the construction and display of WB-Graphs. The suite is known as the WB-Toolset. The WB-Toolset currently comprises

YBEdit is a layout and display software written in Tcl/Tk which uses the Graphviz layout engine and graph manipulation software from AT&T Labs. It incorporates a point-and-click-based GUI which displays the WB-Graph being built in real-time.

VDAS is a lightweight archiving software written in Java. It is used to archive and store the WB-Graphs built with YB-Edit, and supplies version control and common-access control for cooperative work on a WB-Graph.

YBFactor is an input GUI for entering the key events and states, and information about them, which are anticipated to play a causal role in the WB-Graph. It is written in Java.

YBTimeliner converts a WB-Graph whose labels are annotated with the keywords TStmp and Actrs into a timeline showing the sequence of (punctual) events in an incident, along with the participants in each event, in an HTML format. YBTimeliner is written in PERL.

The WB-Toolset is currently implemented on a "black box", YB-CSS, a small bare-bones PC running the operating system NetBSD. YB-CSS is a server which provides the WB-Toolset to up to five individual PCs running the freely available VNC client terminal emulation software. Because the only interface to a local area network or client computers is via VNC, there are virtually no important security issues with use of YB-CSS in this architectural configuration.

back to contents...


WBA book

The current version of the WBA book is Chapters 11-25 of the book Causal System Analysis, by Peter B. Ladkin, a version of which is to be published by Springer-Verlag, Heidelberg and London.

back to contents...


Comparison of WB-Graphs

The output of a Why-Because Analysis is a Why-Because Graph. If the method is objective, it should be the case that different WB-Graphs prepared by different groups for the same incident should be very similar. The question arises how one can formally assess similarity of WB-Graphs.

back to contents...


Timelines

Events in WB-Graphs built using the WB-Toolset may be annotated with both time of occurrence and participants, in the node label, via the keywords TStmp and Actrs, to produce a timeline of the salient events. At present, only punctual times may be included. States, which generally occur over periods and not punctually, are not yet represented. As an example, we show an annotated version of the Glenbrook Specific-Causes Why-Because Graph and Timeline produced directly from it by the YBTimeliner software.

back to contents...


WBA examples

Examples of Why-Because Analyses are available from RVS and other sources. We list some publically available examples:

back to contents...


WBA literature and software

The following literature and software appeared previously on the WBA home page in 2000. Some of it may be outdated; some of it represents research directions not taken. We can't take them all - please feel free to take this stuff and do interesting new things. And please also tell us about it!

cid2ft

Bernd Sieker, RVS-Soft-06, 28 June 2001 [ Service ]

This tool analyses CIDs, presented as CI-Script input files, and generates a fault tree in Postscript from the CID. Its function is described in the document RVS-Occ-01-04, How to Generate Fault Trees from Causal Influence Diagrams, by Peter B. Ladkin, Bernd Sieker and Joachim Weidner [Abstract | PDF Version (333K) | Postscript Version (705K)].

We offer this tool as a WWW service. The WW user must write the CI-Script input file. The service will prompt the user for the file name, and return the completed fault tree as a postscript file to the user.

cid2dot

Michael Höhl, Bernd Sieker, RVS-Soft-05, 21 June 2000, modified 1 July 2001
[ Service ]

This tool produces Postscript Causal Influence Diagrams, from input presented as CI-Script. Its function is described in the document RVS-Bk-00-01 Notes on the Foundations of System Safety and Risk, by Peter B. Ladkin [Abstract | PDF Version (1.65Mb) | PS Version (7.83MB)]

We offer this tool as a WWW service. The WW user must write the CI-Script input file. The service will prompt the user for the file name, and return the completed fault tree as a postscript file to the user.

wb2dot

Michael Höhl, RVS-Soft-04, 2 April 1998 [ Manual | Service ]

wb2dot is a tool for converting WB-Graphs written in textual ASCII form (in EBNF) automatically into (pictorial) graphs. There is a parser for the textual WB-Graph which feeds into the graph layout mechanism, which is the dot tool, part of the graphviz suite from Bell Labs. The Manual describes the tool.

Also available is the wb2dot Service which allows people to use wb2dot remotely. The service offers a CGI interface, which asks for the filename (pathname) of a textual-WB-graph source file on the user's machine, reads it (make sure the permissions are set!), then processes it on our WWW server here, and returns to the user's browser an HTML page containing details of the run (including any error messages) along with a link to download the postscript file containing the pictorial form of the graph which was generated.

A Quick Introduction to Why-Because Analysis

Peter B. Ladkin, 1 March 1999
[ 11pp, Postscript, 159K | DVI without chart, 43K]
[ Chart of WB-Analyses performed by ourselves and others, Postscript, 19K ]

Just what it says - this paper explains the steps in a Why-Because Analysis of a complex behavior, and illustrates the core idea, the WB-Graph Method, as well as explaining why formal verification of the WB-Graph is often important as well.

Examples of Why-Because Graphs

Heiko Holtkamp, 4 March 1999

Postscript versions of Why-Because Graphs for various incidents we have analysed, generated using the tool wb2dot from analyses written in WB-Script. A postscript viewer with zoom capability is required, since the graphs are compact.

Towards "Why...Because"-Analysis of Failures

Karsten Loer, Diplom Thesis, 20 February 1998

Abstract: This thesis introduces the Why...Because Analysis (WBA) method of explaining failures causally. From a brief history of an incident, WBA first aims at inquiring after and identifying the significant acts/states/events/non-events that partake in a causal explanation, and then proving rigorously in the formal logic Explanatory Logic (EL) that the explanation found is correct and relatively sufficient. WBA along with formal proof in Lamport's hierarchical style is presented by means of a small running example. (G-ZIPped PS, 501K

Papers from the Origins of WBA

The main idea of WB-analysis comes from a formal semantics for causation, explained by the philosophical logician David Lewis in 1973. Ladkin used the Lewis semantics first to clarify the causal factors involved in two aircraft accidents in

He showed that application of the Lewis criterion led to a structure that could be represented as a graph, called in that essay the causal hypergraph, now know as the WB-Graph. It was observed that logical connections fulfil the Lewis causality criterion also, although a logical implication between statements is not normally regarded as having anything to do with causality. Also, some instances of causality in the behavior machines is `traditionally' analysed by using logical inference from a specification of the machine and of the various states of the machine at the time events happen, using the assumption that the machine fulfils its specification. For these reasons, the Lewis relation could be seen as involving explanatory features which did not seem to be purely causal. The name WB-Graph (Why...Because...Graph) was thus suggested by Everett Palmer of NASA Ames to be more appropriate.

Two survey papers reviewed the analysis method and results as of 1998.

is informal, and was written for the biannual Research Magazine of the University of Bielefeld in early 1998. A more technical survey article is

Papers describing some analyses from 1997-8 are:

The Lewis criterion was also used to analyse the report of the 1979 Chicago O'Hare DC-10 engine-loss accident. The paper appeared in the 18th Digital Avionics System Conference in 1999. An early version is In the Cali, Warsaw and O'Hare cases, the conclusions of the rigorous WB-analysis based on the events, states and processes mentioned in the accident reports do not completely agree with the `probable causes' and `contributing factors' in those reports. Since the WB-analysis is based on a rigorous application of a precise criterion, and the causal conclusions in the accident reports are not justified by any explicit reasoning or reasoning criteria, one would be justified in holding the report conclusions to contain reasoning mistakes. In any case, an explanation of the divergence is to be wished for and is mostly lacking.

The WB-analysis is primarily concerned with analysing causality. The input to the causal analysis is therefore taken to be the list of events, states and processes (short coherent sequences of actions and states that do not need to be analysed into components) stated in the accident reports. The Lewis criterion is applied to these pairwise to obtain the WB-graph in, first, a textual form and then (automatically or by hand) in graphical form. The textual and graphical form can be generated automatically from the individual judgements of causal factors, as shown in

It is important to distinguish the purely temporal factors of an accident sequence from the causal factors that are part of its explanation. Some attempts to formalise causality have conflated them, and try to formalise the causal reasoning in a pure temporal logic. We do not believe this can work. A critique of one attempt to do this may be found in an early paper

and a general critique of other attempts, and some principles on which they appear to be based, may be found in Our view of how temporal logic enters into accident histories and analysis, and how the `standard' temporal logic for reactive systems should be thereby modified, may be found in

More than just observable causal factors come into play when analysing an accident. One must be able to identify causally significant non-events, and to incorporate information about the procedural and regulatory context in which process leading to the accident developed. Palmer and Ladkin have developed a method of inferring the causal significance of non-events, based on comparing the observed events and states with standard operating procedures and observing where those procedures were not adhered to (in An Analysis of `Oops', to appear). Non-events are added to the state/event/process list to represent events that should have happened but didn't. We expect a similar technique to work for more general deontic contexts, such as regulatory matters and managerial oversight, Reason's latent error types.

Furthermore, there are occasions when deontic considerations conflict with the purely causal analysis. An example was noted in

In this example, explanation requires the deontic considerations to take precedence over the purely causal factors. WB-analysis will thus have to incorporate this deontic reasoning.

We have observed that all accident reporting depends upon a closed-world assumption (CWA), namely that all the relevant facts are those we know plus those we know are missing. An investigation is considered to have gathered all the facts when we know what we know and we know what we don't know. An explanation based on this collection of facts and missing-facts may be incomplete (as when certain facts obviously lack a causal explanation - the causes are thus missing-facts), but it is not non-monotonic. If one is lacking part of an explanation, the explanation itself does not have to be revised when missing facts are discovered later. However, for many if not all accidents, it is in principle possible that certain events that are not considered plausible and are not easily traceable could in fact have happened, and have led to the accident. The supposition that there are no such abnormal events is equivalent to the CWA. It is a supposition, and the possibility is always there that it may be shown to be incorrect by further evidence. This plausibility criterion, the CWA, thus leads to non-monotonicity. While incompleteness is accomodated within the WB-method as it now is, non-monotonic features of the reasoning are not yet explicitly accounted for.

The paper

is a short abstract with examples illustrating the deontic/causal conflict, and non-monotonic reasoning in aviation accident reports.

back to contents...