An Integrated Toolset For Software Safety Analysis Peter Fenelon John A. McDermid Department of Computer Science University of York Heslington York Y01 5DD United Kingdom Email : pete@minster.york.ac.uk, jam@minster.york.ac.uk Phone : +44 904 433388 FAX : +44 904 432708 ABSTRACT Traditional methods for the assessment of software safety suffer from poor integration -LRB- from methodological , operational and semantic points of view -RRB- both with each other and with the rest of the development lifecycle of safety-critical systems . Our goal is to develop a set of methods and tools which address these weaknesses , and this paper describes our current research into these areas . We describe an integrated approach to software safety analysis based around the techniques of Fault Tree Analysis and Failure Modes , Effects and Criticality Analysis , together with a prototype toolset which will implement these techniques . Issues pertaining to the integration of safety analysis into a broader development lifecycle are also discussed . Our approach emphasises pragmatism and simplicity ? we aim to create a set of tools and methods which are robust and straightforward , and are directly usable by industrial practitioners in the field of software safety . hhhhhhhhhhhhhhh The research described in this paper is funded by British Aerospace Defence -LRB- Military Aircraft Division -RRB- , Warton , Lancs . 1 . Introduction As the use of computer systems in safety-related applications becomes ever more widespread we are increasingly faced with the task of deciding whether the software used in the systems is sufficiently `` safe '' . To avoid confusion we introduce the term safety integrity to identify the properties of the design and implementation of software such that it shall not behave in a way which shall not endanger the safety of the system nin its intended use . The concept of software safety integrity is a relatively subtle one ? software failures alone can not cause harm ; only the interactions between `` faulty '' software and the rest of the system can do so . Correctness and safety integrity are not necessarily the same thing ? it is possible for a system to be in a state which is incorrect with respect to a functional specification , but which will still meet defined safety criteria . The task of the engineer involved in the development of the software components of safety-critical systems should therefore include the systematic assessment of the potential failure modes of the software , and the analysis of the consequences of these failure modes . The results of these analyses must then be integrated into an overall safety case for the system . A safety case is a complete set of evidence produced with the intention of demonstrating that an operational system is safe to deploy for its intended use . There are already a number of methods and tools in existence which claim to assist in this process , several of which will be discussed in more detail later in this paper . It is , however , our belief that , in their traditional forms , these methods suffer from poor integration into the system development lifecycle at several levels ? g Semantic level : Links between different methods used in safety assessment , and links between assessment , design and implementation , are generally inadequate in the sense that there are no common semantic frameworks -LRB- system or computational models -RRB- to link the techniques together ; hence -LRB- for example -RRB- the meaning of data derived from safety analysis of a piece of software may be open to misinterpretation in the context of the system design without a sound underlying model for integrating information from different views and levels of abstraction of a system . . g Procedural level : There is often no sound methodological framework in which to use the safety assessment methods , so that , for instance , the effect of a design decision upon the safety case ? is not properly considered at the time the decision is made ; this can be addressed by integrating safety analysis procedures and their results hhhhhhhhhhhhhhh ? A safety case is the complete body of evidence and argumentation that a system is safe for its intended purpose into the review and change-management procedures . g Operational level : Integration between tools used for system development and safety assessment is traditionally poor . This paper describes our attempts within the SSAP project to design methods and tools which bridge these semantic and operational gaps and thus facilitate procedural integration , yet also retain a high degree of compatibility with traditional methods . Although our emphasis in this paper is on semantic integration , we shall also briefly discuss our current implementation of a prototype toolset , built largely from standard software components , which aims to provide operational support for our methods . 2 . Background To The SSAP Project The Software Safety Assessment Procedures project , funded by British Aerospace Defence -LRB- Military Aircraft Division -RRB- , commenced in September 1990 . Its objectives are to construct a flexible and powerful environment in which tools concerned with software safety can operate , and to use this framework to assess the usefulness of these methods . We have worked with particular reference to existing standards used in large-scale industrial safety-critical software development . Wherever possible , we have chosen to use existing methods as a base for our analyses and simple software components as a basis for implementation . A pragmatic approach to design and implementation based around object oriented principles has enabled us to propose and develop a loosely-coupled set of tools sharing a common database and offering the user a broad range of software safety analysis methods . The two basic techniques at the heart of SSAP are Fault Tree Analysis -LRB- FTA -RRB- and Failure Modes , Effects and Criticality Analysis -LRB- FMECA -RRB- . Both methods which are well-understood in the systems engineering processes in the aerospace industry -LRB- and elsewhere -RRB- and much of our effort has been concentrated upon developing idioms and extensions which enable us to describe the failure properties of software systems more precisely . We have also proposed a new notation which links FTA and FMECA in a simple and easily comprehensible fashion . This was required because we believe that Software FTA and FMECA , although both powerful and useful methods , do not integrate well at present . We required a notation which offered the precise semantics of fault trees and the intuitive readability of FMECA , and which could be used effectively as a bridge between the two . Our new Failure Propagation and Transformation Notation , is somewhat analogous to traditional dataflow-based design notations , although instead of showing normal dataflow between elements in a system it describes the propagation and transformation of failures . We shall describe the relationship between this notation , FTA and FMECA in a later section , and explain what we mean by transformation of failures . It should be noted that SSAP is only one of a number of projects at York concerned with safety-critical systems ; we are already considering integration of SSAP with various other tools ; we return to a discussion of operational integration in the concluding section of the paper . We believe that the use of well-founded methods at all levels of the systems engineering process is important , but also that these should be presented to the engineer in as straightforward a fashion as possible . Our aim in SSAP is to provide a simple set of graphical or textual notations with an underlying set of formalisms and semantic bases to link these methods into the formal methods used in safety critical software development . The basic methods used in SSAP have been selected since it is simple to link FMECA to FTA -LRB- via our new notation -RRB- , and since it has been demonstrated that it is also conceptually easy to link FTA to Dijkstra 's wp-calculus -LRB- Cla91 -RRB- we can provide a link from software FTA into formal methods . We therefore hope to be able to provide a set of methods which have a real semantic basis and reflect the structure and meaning of software components at all levels . We are particularly interested in automatic derivation of fault trees from program code and from structured design notations , notably CORE -LRB- COntrolled Requirements Expression -RRB- . This paper describes the principles underlying our work and the status of our toolset . We discuss FTA , FMECA and our new FPTN notation before considering broader integration issues . 3 . Fault Tree Analysis In SSAP Fault Tree Analysis has been in use since at least the 1960s as a tool for the assessment of system reliability -LRB- Che71 -RRB- and has developed into a well-understood , standardised method with broad applications throughout the discipline of safety and reliability engineering . The best introduction to `` classical '' fault tree analysis is the extensive and authoritative Fault Tree Handbook -LRB- Ves81 -RRB- . Traditional fault tree analysis is a probabilistic method in which potential causes of some failure -LRB- `` top event '' -RRB- are recursively organised in a tree structure reflecting causality ? causality is a crucial notion underlying all safety analysis techniques . Higher-level events can be caused by various combinations of lower-level events , with the principal connectives used in the tree being the AND and OR gates , which have meanings analogous to those traditionally used in electronic circuit design . Majority gates -LRB- where N out of M inputs must be true before the output is true -RRB- , exclusive-OR gates and INHIBIT gates -LRB- which generate a true output if some input representing an event in the system is true , and some external `` conditioning event '' has occurred -RRB- are also available , although these tend not to be used when FTA is applied to software systems . Much of the basic work on the application of fault trees to software systems has been carried out by Leveson and her colleagues . In particular -LRB- Lev83 -RRB- , demonstrates a template-based approach to software fault tree analysis in which programming language constructs are mapped onto instances of a set of templates describing the failure properties of the statement in question -LRB- for example , there are templates for IF , WHILE , assignment and so on -RRB- . These are composed in well-defined ways in order to derive a fault tree describing the failure properties of a software component . In Leveson 's work the control flow structure of the system is assumed to reflect the causality of faults , provided the faults are such that control flow is not violated by the occurrence of a fault . It should be noted that software fault tree analysis is not probabilistic since the failure modes of software are -LRB- in theory -RRB- deterministic . Software FTA can , however , be interfaced to system-level FTA in order to provide a more complete view of system safety . It is also possible to consider a software fault tree in which the leaf nodes are representations of hardware events which can meaningfully be assigned failure probabilities ; from such a tree we can estimate the probability of a particular software failure mode arising by examining its external causes . Leveson 's extensions to traditional methods of FTA are tied closely to traditional imperative languages with simple constructs . Later attempts to add support for the Ada concurrency model -LRB- Cha89 -RRB- are somewhat less convincing , since the templates are more complex and it is debatable whether they capture the full failure semantics of Ada 's complex tasking statements . Leveson-style fault trees are also structured in terms of the system in normal mode of operation rather than reflecting its failure properties , and emphasise a depth first and bottom-up approach to analysis . This is counter to the traditional top-down application of fault trees and we have found the that the bottomup approach to software fault tree analysis is difficult to explain to traditional safety engineers . Software fault trees can also become unwieldly and difficult to manipulate , but our toolset handles decomposition and `` folding '' of fault trees and alleviates this problem to some degree . While this approach is acceptable when dealing with code which is already written , we believe that the bottom-up method of fault tree analysis has prevented pro-active use of FTA in the design and implementation phases of the software lifecycle . This is particularly important as we believe that successful integration of safety assessment techniques such as FTA into the development lifecycle is only possible if we have a strong link between safety assessment methods and the design process , for example allowing us to determine where safety features -LRB- defences which prevent potentially harmful internal failures from propagating -RRB- need to be included in a system -LRB- this implies that there is a need for rapid iteration between design and safety analysis , and strong semantic links between the methods used -RRB- . We have therefore proposed a form of Hierarchical FTA -LRB- HFTA -RRB- which , although compatible with Leveson 's methods , takes an almost diametrically opposed approach and is inherently top-down and breadth-first . 3.1 . Hierarchical FTA Here we attempt to demonstrate some of the principles of our HFTA method . We show the broad techniques applicable in HFTA by illustrating the initial steps of a small case study of a piece of non-critical software ; the same methods are currently being employed on a more substantial case study with a critical component and initial results indicate that there is a substantial saving in effort and increase in comprehensibility over the traditional approach The case study we use here for illustrative purposes centres around a simple desk accessory program for a microcomputer which allows the user to format floppy disks with various non-standard parameters . Obviously this example is not safety critical , but it demonstrates the principles of HFTA without requiring us to consider the more complex hazards inherent in `` real world '' applications . The software under analysis was written in Modula-2 , as two MODULES . One of these -LRB- named DskForm -RRB- contains the Format procedure used to format the disks , the other -LRB- FormAcc -RRB- contains the procedure which dispatches work to the formatter -LRB- Do_Work -RRB- and the entry and main event loop of the accessory -LRB- as module-level initialisation code -RRB- . A note on terminology : AES -LRB- Application Environment Services -RRB- is a part of the Atari ST 's GEM windowing system which deals with multi-tasking applications . It is impossible for a program which has not successfully negotiated with AES to make use of any high-level graphics functions such as menus , dialogue boxes etc. . TOS is the lowest level of the Atari OS , approximately equivalent to the BIOS on an IBM - compatible personal computer . In order for a floppy disk to be successfully formatted the program must gather the appropriate parameters -LRB- number of sides , tracks and sectors per track -RRB- from the user , create the individual tracks by means of repeated calls to an operating system routine and then write a `` boot sector '' to the disk containing information about the type of disk we have just formatted . 3.2 . Top Level view -LRB- Systems Perspective -RRB- We are concerned with a particular failure mode of the formatter ? what can cause it to fail to format disks correctly ? From a systems point of view we might see a top-level fault tree as below , considering the following as potential root causes of the failure of the formatter to work correctly : g AES communication failure ? the application has not successfully registered itself with the AES . g Error caused inside formatter software -LRB- internal error -RRB- g Fault on media ? there is a genuine defect in either the floppy disk or the drive . Disk fails to format AES failure Internal Error Media Fault Figure 1 : System View of fault tree 3.3 . Top Level view -LRB- Software Perspective -RRB- Without access to the underlying operating system source code , we can only investigate the failure of the software down to the level of failure of individual system calls involved in the successful formatting of a disk . We consider the top-level of the system from a software point of view , looking at the modules which can fail : DoWork sets incorrect disk parameters Disk does not format Format procedure fails DskForm fails Figure 2 : Software View of fault tree The software view is related to the systems view ? the failure of the formatting software is equivalent to the `` internal failure inside formatter '' case in the above tree . The obvious action here is to investigate the three potential causes of failure and discover what failure modes they can bring about . 3.4 . Second-Level Decomposition ? DSKFORM initialisation code The only failure in the initialisation/main loop which can cause the formatter not to succeed is one which leads to the accessory not responding to requests to format disks . There are three potential causes of this , each of which can be uniquely associated with and a particular block of code : g Failure to initialise as an AES application -LRB- Call to the OS routine appl_init -RRB- g Failure to register on the Desk menu -LRB- Call to the OS routine menu_register -RRB- g Failure to respond to AES messages from the Desktop -LRB- desk accessory fails to return from a call to the OS routine evnt_mesag -RRB- This leads to the following fault tree for this subsystem : DskForm does not call DoWork Appl_Init fails to register the program Menu_Register fails to put the program onto menu bar No messages are received by calls to evnt_mesag Figure 3 : Failure Inside the DSKFORM Module 3.5 . Second-Level Decomposition ? DO_WORK code The possibility exists that the user could select invalid parameters inside the DO_WORK procedure , which pops up dialogue boxes with buttons inviting the user to select of which drive , how many sides , tracks and sectors per track should be used . -LRB- Although Atari and compatible floppy drives are nominally rated at 80 tracks , 9 sectors per track many drives allow more ; this program gives the user the choice of selecting up to 84 tracks by 10 sectors . Both single - and double-sided drives are available , and selectable -RRB- . There is no guarantee that the parameters the user selects will work on the selected drive : this leads to the following fault tree : Format parameters set incorrectly Drive ID number set incorrectly No of sectors per track set incorrectly No . of tracks per side set incorrectly No of sides to format set incorrectly Figure 4 : Failure Inside the DO_WORK procedure 3.6 . Second-Level Decomposition ? FORMAT code We now consider the consequences of failures inside the actual FORMAT procedure . There are only two basic causes of failure to format a floppy disk correctly in this procedure ? failure to format one of the tracks correctly , or failure to generate a correct boot sector -LRB- written on the first sector of the disk , containing information on the capacity of the disk , number of sides , sectors and tracks and a unique volume identifier -RRB- . However , we might find that bad parameters passed in by the DO_WORK routine give rise to an anomalous situation -LRB- e.g. trying to format a disk to 84 sectors in a drive only capable of 82 -RRB- This gives rise to the following fault tree : Disk does not format Bad drive parameters Bad physical media Boot sector generation incorrect Figure 5 : Failure inside the FORMAT procedure The `` Bad Media '' failure corresponds to a failure in physical formatting of the disk tracks . This is handled by a pair of nested FOR loops in the FORMAT procedure , one loop iterating over the sides of the disk and the other over the tracks on each side . We can apply Leveson-style templates to this section of code if necessary ; the format procedure will return an error code if the call to the operating-system flopfmt -LRB- format track -RRB- routine fails on a `` bad sector '' or track . We can also do some Third-Level Decomposition ? we can examine potential causes of the generation of an invalid boot sector . 3.7 . Third Level Decomposition ? Boot Sector Generation Two potential failures can prejudice the creation of a usable boot sector : g Failure of the call to the OS protobt -LRB- create prototype boot sector -RRB- routine -LRB- invalid parameters passed to it -RRB- . g Failure to write a successfully-created prototype boot sector to the disk ? the call to the OS flopwr routine -LRB- floppy disk write -RRB- might fail . The corresponding fault tree appears as follows : Bad or missing boot sector Call to flopwr fails to write the generated sector Call to protobt to generate the sector fails Figure 6 : Failure in Boot Sector generation 3.8 . Further Decomposition We have yet to decompose the system right down to code level , yet we still have a good understanding of what potential failures there are and how they contribute to the overall failure to format disks . Where necessary , we can apply Leveson-style template FTA to the blocks of code represented by the leaves of our second and third-level fault trees . It is important to note that throughout our analysis we have been identified faults which are meaningful in terms of the application , not merely artefacts of the program structure . Were we to descend into the implementational aspects of such an analysis we could then use Leveson-style templates to model the code fragments we discover . For example , the actual formatting of the tracks on the disk is carried out by repeated calls -LRB- nested FOR loops , one iterating over sides and the other over tracks -RRB- to the operating system flopfmt routine ; we could construct a Leveson-style model by nesting the faulttree representation of the inner for loop inside that of the outer loop , and appending a template representing procedure call with an exceptional return value -LRB- flopfmt returns a negative number to the caller if an error has occurred -RRB- . 3.9 . Conclusions On Software FTA The high-level failure modes relate to the semantics of the application and we can think of them in ways in which the system might violate its specification . In effect they are an application-oriented causal abstraction from the details of the program . They are hypothetical -LRB- judgmental -RRB- until they are confirmed by detailed analysis in terms of the control flow structure of the program . In this example , as is normally the case , fault tree analysis leads us to focus on small parts of the actual code . This is at considerable variance with normal approaches to program verification , but it can lead to more focussed and efficient analysis . 4 . Failure Modes , Effects and Criticality Analysis In SSAP FMECA is a quantitative and qualitative method which is used as to analyse the effects of a single failure on a system . It is particularly useful as a tool for summarising the failure behaviour of a system and can be used `` pro-actively '' as a tool for reliability growth -LRB- Rah90 -RRB- if well integrated into the development lifecycle . FMECA is also often used as the basis for analysing maintainability and related requirements , although this is in the broader systems context and we do not discuss this further in this paper . FMECA and related techniques are of great pragmatic importance as one of the most common requirements in many safety-critical systems is that there should be no single point of failure which can lead to a hazard ; FMECA can be used to analyse a design in order to verify that no single point failure can propagate through the system to cause a hazard . FMECA is well-understood at the systems level ; sound procedures and standards have existed for many years -LRB- see for example -LRB- ARP67 -RRB- for more information -RRB- and equipment suppliers and users -LRB- at least in the aerospace industry -RRB- have developed much experience of using the method . Suppliers of all manner of equipment provide lists of potential failure modes for components and equipments , which can be used as data for FMECA at higher levels ; standardised worksheets for constructing FMECAs of subsystems and systems exist and computer support -LRB- basically interfaces to traditional databases -RRB- is often available . The principle behind FMECA is simple ? it attempts to evaluate the effects of a single failure of a component on the system as a whole . The mapping from failure modes to effects may be a direct one , or hierarchies of failure modes and effects may be necessary , with combinations of failures required to bring about particular output states . FMECA is traditionally a laborious process with no real effective procedure beyond the mechanical filling-in of worksheets . In essence these are an abstraction of a judgemental causal analysis of the design , concerned with the propagation of a single failure mode through the system -LRB- compare this to fault tree analysis , which is concerned with the conjunction of failure modes -RRB- . There is little methodological support ? the abstraction of failure modes from the design is largely a judgemental process ? the method 's applicability to software systems has in the past often been doubted . FMECA is also largely an experience-based procedure ? prior knowledge of similar systems often serves to structure the analysis and , at the systems level , FMECA is often closely related to similar experiential methods such as Zonal Hazard Analysis which is concerned with the interaction between systems within particular physical regions . FMECA has yet to be applied to software in a truly comprehensive and successful fashion . In part this is due to the lack of readily-identifiable software components with well-defined failure properties , and in part , we believe , because existing methods of software FTA are not structured in terms of the failure behaviour of the software but in terms of its logical structure . We believe that our hierarchical FTA method , with its emphasis upon a failure-based approach to structuring the tree , is inherently more suited to integration with FMECA ? every intermediate node , right down to the code level , is a reflection of a real failure mode of some identifiable element within the system , rather than corresponding to some artificial notion of failure of a tiny fragment of code . The failure modes at the `` bottom '' of FMECA worksheets should be the same as those which represent leaf nodes in corresponding fault trees . The FTAs then show how combinations of these events can lead to hazards . FMECAs show the effects of single failure modes , thus the approaches show complementary aspects of the consequences of failure modes . If a single failure mode could lead to a hazard then the fault tree and FMECA chart would be equivalent for that failure mode . Thus , there are links between FTAs and FMECA , but there is a more fundamental relationship ; we believe that both FTA and FMECA are both abstractions of the same underlying causal model of the propagation of failures -LRB- cause and effect -RRB- through a system . These causal possibilities are properties of the design , but they do not necessarily correspond to the logical , physical or functional form of the system . Traditionally , FTAs and FMECAs are developed in an intuitive fashion by experienced safety engineers . We propose a systematic model of failure propagation which can be used to reinforce or replace this intuitionistic reasoning . This is the domain of the FPTN notation discussed below . 5 . Failure Propagation & Transformation Notation The Failure Propagation and Transformation notation is a simple graphical method for expressing the failure behaviour of systems with complex internal structures . It allows us to address many of the limitations inherent in both FTA and FMECA . In particular , our aims in creating FPTN were to provide a simple , clean notation which reflected both system architecture and the way in which failures within the system interact . Since failure propagation is arguably a form of -LRB- abnormal -RRB- data flow , FPTN was initially intended to resemble data-flow based methods such as CORE and Mascot . It is a modular and hierarchical notation which allows decomposition based upon system architecture , but replaces the conventional concept of data flow by failure propagation between modules . Since we are concerned with all possible interactions between failure modes , FPTN diagrams are potentially infinite ! In practice , though , we limit the modelling to failure modes and combinations thereof which are credible , i.e. which can plausibly occur during the system lifetime . We return to such methodological issues at the end of the section . We use the term transformation of failures because a design can change the nature of a failure . Recovery mechanisms or other defensive programming strategies may prevent a failure from propagating at all . More subtly , a protection mechanism may , for example , detect a timeout and cause a function to return an approximate value instead of an exact one . Thus a value domain failure may result from an earlier time domain failure . The notation gives the need to illustrate such transformations . A software module in FTPN is represented by a simple box with a set of input and output failure modes . Inside the box we list a set of predicates describing the relationship between the input and output failure modes of the module ; in fact , these predicates correspond to the sum-of-products form of the minimal cutsets of the fault trees -LRB- a minimal cutset being any set of conditions necessary and sufficient to cause the loss event described at the top of the tree -RRB- for each output failure mode . In effect the FPTN box contains a forest of fault trees laid on their sides . We also provide simple representations for failure modes which can arise inside a module and for exceptions handled by modules . There is also a facility for attaching a criticality to a module which is not yet used in the current FPTN implementation . Some elements of the notation are depicted in Figure 7 : PREDICATES e.g. . A : = B | C D : = EF & GH Exc ? is a flag to indicate whether exception handlers or other recovery mechanisms are present . Crit is an indicator of the relative criticality of the module Input Failure Modes Output Failure Modes Exc ? CritModule Name Shadowing to indicate decomposability for compouind modules Figure 7 : Elements of FPTN notation It is our intention that failure modes in FPTN are typed ; failures may be classified into various broad categories , for example : g Timing failures g Value failures g Failures of commission g Failures of omission This classification follows that of Ezhilchelvan and Shrivavasta -LRB- Ezh85 -RRB- . We further subdivide failures into g Internal failures ? those due to the module being considered g External failures ? those due to other application modules g Infrastructural failures ? those due to the underlying hardware , operating system or external environment . Thus , for example , deadlock of processes would lead to an external omission failure ; loss of a physical link would be an infrastructural failure . This categorisation gives us a basis for analysing failure modes and for determining what detection and recovery mechanisms are needed -LRB- an important part of the iterative design process with safety requirements seen as a driving force -RRB- . FPTN enables us to observe the consequences of , for example , a value error in the inputs to a particular module causing a timing error in one of its outputs -LRB- perhaps through excessive iteration when using an input which had not been range-checked as a loop counter -RRB- , and so on . It also allows us to consider common-mode failures in a more tractable fashion than FMECA . 5.1 . FPTN in use Here we introduce some of the notational ideas in FPTN by reference to a small example . Suppose we have some hypothetical system S which consists of three communicating software modules Subsystem 1 , Subsystem 2 and Subsystem 3 , and we have initial sets of failure hypotheses for all of these modules . How can we relate the failure modes of the three modules to those of the system as a whole , and what would the resulting FPTN diagram look like ? We start by considering the modules in isolation . To reduce our initial hypothetical failure modes to a realistic set , techniques such as fault tree analysis or FMECA can be used . We consider the subsystems in turn and integrate the FPTN views of them into a coherent view of the system at a whole . Since FPTN is inherently hierarchical results from FPTN analysis of one level of a system can be `` folded away '' into black boxes for use at higher levels . 5.2 . Subsystem1 Software fault tree analysis of Subsystem 1 reveals that it is susceptible to input failure modes A -LRB- timing -RRB- and B -LRB- a value error -RRB- . Failure mode A alone causes output failure mode Y , a communications error . A and B must both occur to cause failure mode X , a timing error . The subsystem generates no new failure modes unrelated to input failures -LRB- this is a rather unrealistic example ? most real subsystems would generate some failure modes which would be propagated into the environment -RRB- , but has an exception handler or recovery block which prevents failure mode C alone from being propagated any further . Its FPTN representation appears below : X : t == A : t AND B : v Y : c == A : t AND NOT B : v C : t HANDLED BY ErrorProc II * S.Subsystem1EH C : t Y : c X : t A : t B : v Figure 8 : Subsystem 1 Note the typing of the failure modes ? in general X : y refers to a failure mode X of type y ; single-character abbreviations are used for t iming , v alue , etc. . 5.3 . Subsystem2 Fault tree analysis reveals that Subsystem 2 is susceptible to failure modes A -LRB- timing -RRB- and Y -LRB- communications -RRB- . Failure mode W occurs if A or Y occurs , and in addition to this a new failure mode Z -LRB- a timing error -RRB- is generated by an internal value error inside the subsystem . The FPTN representation appears below : II * GENERATED z : t FROM INTERNAL : v W : c == A : t OR Y : c A : t Y : c S.Subsystem2 Z : t W : c Figure 9 : Subsystem 2 5.4 . Subsystem3 After analysis of Subsystem 3 we discover that it is vulnerable to failure modes B , X and Z , all of which we have met before . It generates the failure modes V -LRB- a value error -RRB- and A -LRB- a timing error which we have previously encountered -RRB- . This gives rise to the FPTN diagram depicted below : II * S.Subsystem3 V : v == B : v AND X : t A : t == Z : t AND -LRB- B : v OR X : t -RRB- B : v X : t Z : t V : v A : t Figure 10 : Subsystem 3 5.5 . Combining The Subsystems We now take the three modules and combine them into a single diagram by connecting up corresponding failure modes -LRB- Fig. 11 -RRB- . Those failure modes propagating out of the system , or those generated externally and affecting it , can be thought of as respectively the output and input failure modes of the system as a whole . II * S.Subsystem3 B : v X : t Z : t V : v A : t S.Subsystem2 II * A : t Y : c Z : t W : c II * S.Subsystem1EH C : t Y : c X : t A : t B : v B : v V : v W : c C : t Figure 11 : FPTN diagram of System S We can simplify this view of the system and replace it with the following FPTN diagram which could be used as a component in a higher level analysis -LRB- Figure 12 -RRB- : II * B : v C : t V : v W : c System S Figure 12 : Abstract FPTN view of system S 5.6 . Commentary on FPTN We commented above upon the inadequate links between FMECA and FTA . Our FPTN is a generalisation of both techniques ; FMECA and FTA can both be regarded as special cases -LRB- abstractions from -RRB- FPTN . However , in some senses we have merely moved the problems we alluded to above , not solved them ? we still have to construct the FPTN diagrams -LRB- although we have reduced the number of judgemental decisions -RRB- . There is some hope that we can do better . The fault classification gives us a basis for a systematic analysis of the failure behaviour of the system . As a minimal improvement , it seems feasible that this will yield a rigorous manual procedure . We are aware of a project -LRB- IFME -RRB- carried out at the Turing Institute in collaboration with British Aerospace -LRB- Mur92 -RRB- which has partially automated the generation of FMECAs from design descriptions , and we believe it may be possible to link these ideas to generate FPTN diagrams from design data . We have yet to evaluate this possibility . 6 . Methodological Integration How can we use FPTN to structure a safety analysis of a software system ? We envisage the use of FPTN in the early stages of a safety analysis as a simple architectural modelling tool ? the system is decomposed into a series of FPTN modules reflecting the operational structure of the software . We then use hypothetical failure modes which we believe exist in the system , and tentatively connect the modules which we believe cause and are affected by those failures . We will usually have some idea of the basic failure properties of a module if we know its function ? for example , a procedure carrying out some calculation in a hard real-time system might return an imprecise result if forced to relinquish a timeslice , or -LRB- in a badly designed system -RRB- might cause a timing error by overrunning its timeslice . Similarly we might expect data acquisition routines , communications software and so on to display characteristic patterns of failure modes which we can use as initial failure hypotheses . We then consider each module in turn , starting from the lowest-level and progressing up the hierarchy . Note that this does not mean abandoning the top-down fault tree analysis method ? inside the modules the trees will be developed according to the hierarchical approach sketched above . For each module we construct a software fault tree , plugging in each `` output '' failure mode we believe affects the module as a potential top event . Note that these are not necessarily hazardous failure modes ? they may be handled at other levels of the system . Standard minimal cut-set analysis is then carried out . We may also carry out more `` semantic '' analysis of a software fault tree : for example , a particular branch of a tree might represent a code fragment such as the following : type A_TYPE is new integer range 1 . .100 ; X : A_TYPE ; ... if X > 200 then <statements> else <other statements> end if ; Assume that a hazardous condition arises when the value of X is greater than 200 at the end of the block under consideration . A fault tree would be constructed with an AND gate with two main branches , one corresponding to the THEN part and the other to the ELSE branch ? . It is clear that the THEN branch of the statement can never be executed ; a fault tree system with sufficient links to the original semantics of the program -LRB- in this case , a system able to recognise the constraints on the types -RRB- could recognise this and prune the then branch from the Leveson-style representation of the code fragment . From such an analysis we can determine g whether the top event -LRB- and therefore the hypothetical failure mode -RRB- occurs given the set of input failure modes and g which of the input failure modes are responsible for the generation of the output failure . We can therefore modify the set of inputs and outputs connected to the module after this analysis , removing those inputs and outputs which after analysis clearly do not form part of the failure behaviour of the module and rewriting the sum of products form of the minimal cutsets giving rise to each output failure mode as the FPTN equational descriptions of the module . The eliminated failure modes would be retained in FMECA tables ? they are failure modes with no effect . FPTN therefore acts as both a causal model and a representation of the system architecture . The failure modes identified as outputs of a software system can be easily integrated into systems-level FMECA ? they can be viewed as corresponding to failure modes of the processing node on which they are running . hhhhhhhhhhhhhhh ? We ignore the potential for failure modes caused by the evaluation of the expression in the IF statement in this example . 7 . Implementation Issues The original design for the SSAP software was a purely object-oriented system employing a persistent store and an object-oriented user interface management system . Data within the system was to be represented in a flexible and extensible class hierarchy with the various analyses embedded in the classes as methods . We originally intended to build a `` monolithic '' integrated application which would be extended by adding new classes and methods into the system . This approach has had to be modified slightly ? we were obliged to split the functionality of the system into distinct front and back-ends which at present run on different machines connected via our local area network . Our current architecture retains the persistent store ? implemented on top of the ONTOS object oriented database ? which contains instances of the classes defined in the hierarchy . All analyses are implemented in this back-end , which runs on an IBM RS/6000 under AIX . The original display and editing tool was custom-built with the InterViews 3.0 b toolkit -LRB- Lin87 -RRB- and ran on a Sun-3 workstation . This application , although user-friendly and quite simple to use , was slow and inefficient . We abandoned it in favour of a set of simple interfaces built upon a locally enhanced version of the Xsim tool from the University of Washington ; Xsim is a generic application running under the X window system which can be tailored to provide a user interface for any software tool which requires input of graphs . We have constructed editors for fault-trees and for the FPTN using Xsim ; these generate output in Xsim 's internal format . A translation program converts this into a simple language we term Common Safety Interchange Format -LRB- CSIF -RRB- ; CSIF output from the tool is then sent over TCP/IP to the database/back end running on the IBM machine . Results of the analyses are transmitted in CSIF from the IBM to the Sun ; a CSIF to Xsim translator then generates a new Xsim file and invokes the display tool . There is therefore little distinction between the user 's input and the system 's output generated from it ? indeed , the user is free to modify system output and store it in the database , enabling `` what-if '' exercises to be carried out . The combination of Xsim , CSIF and the class hierarchy we have implemented with ONTOS enables us to create tools for new notations very quickly ? for example , our initial prototype editor for the FPTN notation took only a couple of days to build and integrate into the system , inclusive of the addition of some necessary basic database support . Thus we are free to concentrate upon the development of the analysis methods rather than the implementation details ; the lower -LRB- infrastructural -RRB- levels of the class hierarchy provide most of the basic functionality . We have also constructed a system which transforms annotated programs in an Ada subset -LRB- we are aiming at full compatibility with Spark - an Ada subset for safety critical applications -RRB- into CSIF descriptions of their corresponding fault trees ; an approach combining HFTA as a higher-level structuring technique and Leveson-style templates at the lowest level has been adopted . The Leif syntax-directed editing and parsing toolkit -LRB- Smi88 -RRB- has been used in conjunction with Gnu Emacs to provide a user interface to the Ada-specific and parsing functions of the system ; the textual representation of the Leif parse tree is then processed to form a CSIF representation of a fault tree which can be stored in the database . 8 . Integration Of SSAP With Other Tools SSAP does not exist in isolation . Many research projects at York are considering other interesting areas in the development of high-integrity software and are producing their own tools to assist in this work . These projects are complementary and there are significant synergistic benefits to be offered if we can achieve a level of integration between these tools . Perhaps the project most closely related to SSAP is ASAM , which is concerned with the production of a series of prototype Safety Argument Managers and a methodology for using them . A safety argument manager provides a framework for the generation of safety cases -LRB- as mentioned in our introduction -RRB- and we believe that there is obvious scope for communication between SSAP and the SAMs produced by ASAM . ASAM is based upon methods of argument representation developed in the 1950s by the English philosopher Stephen Toulmin -LRB- Tou58 -RRB- and it is a long-term aim that we should be able to use data derived from SSAP analyses as data , backing or warrant -LRB- supporting material -RRB- in Toulmin-style arguments . It may also prove interesting to link SSAP into the CADi ? toolset ; this is a typechecker , browser and -LRB- emerging -RRB- theorem prover for the Z notation . Predicates derived from FPTN diagrams or fault trees could be mechanically translated into Z and manipulated inside CADi ? and perhaps its theorem proving capabilities could be used to simplify expressions and therefore the fault-trees from which they are derived . Links to other verification systems such as HOL have also been considered ? as we have mentioned , SFTA displays many of the same semantic properties as wp calculus and the use of SFTA as a user-friendly front end to traditionally difficult tasks would appear to be beneficial . We have in addition briefly considered the potential for linking SSAP to the toolset under construction by the Real Time Systems research group , enabling us to integrate failure analysis into the complex tasking problems in the latest generation of hard real time systems . 9 . Conclusions We believe that the SSAP tools and methods are evolving to a stage where successful integration at all three levels previously identified can be achieved . At the semantic level , we believe that the common causal model shared by FTA , FMECA and FPTN allows data to be shared between these notations . At the procedural level , we have suggested how FPTN can be used to mirror the design process , and how it links to fault-tree analysis on software components . Finally , at the operational level we have demonstrated that it is possible to construct a toolset which allows data to be shared between a range of notations and which has a sufficiently open architecture to facilitate extensibility and interoperability with other systems . The SSAP project has identified several interesting areas of research into the development of safety-critical systems and has in particular looked closely at the analysis of software failures . We have developed several new techniques and extensions to fault tree analysis , and in particular have developed a notation -LRB- FPTN -RRB- which enables us to bridge the semantic gap between FTA and FMECA . We have designed an open architecture which facilitates easy integration of new tools and methods into the SSAP system and perhaps more significantly , should allow us to integrate SSAP with other tools being built at York , for example the ASAM safety argument manager , the CADi ? specification tool and the STRESS real-time simulator . The SSAP approach , which emphasises pragmatism and simplicity in both methods and tools , seems to provide a sound framework for further research and a useful platform for software safety analysis in its own right . 10 . Acknowledgements The authors wish to thank the Software Technology department at Warton for its support and technical input . In particular , discussions with Julian Johnson , Brian Jepson and Lynn Spencer have influenced our thinking . In the Airworthiness group , Sandy Drysdale 's comments from the perspective of an engineer involved in the safety assessment of real systems have been invaluable . At York , Chris Higgins -LRB- ASAM -RRB- , Ian Toyn -LRB- CADi ? -RRB- and Ken Tindell and Mike Richardson of the Real Time Systems group have also provided many interesting insights into the potential for linking SSAP with other tools . Andy Vickers ' work on enhancing Xsim has also contributed much to our work . 11 . References ARP67 . ARP926 , `` Design Analysis Procedure For Failure Modes , Effects and Criticality Analysis -LRB- FMECA -RRB- '' , Aerospace Recommended Practice -LRB- ARP -RRB- 926 , Detroit , USA , Society of Automotive Engineers -LRB- SAE -RRB- -LRB- 15th September 1967 -RRB- . Cha89 . Cha , S S , Leveson , N G and Shimeall , T J , `` Safety Verification In Murphy Using Fault Tree Analysis '' , in Software Risk Management , ed . Boehm , Barry W. , IEEE -LRB- 1989 -RRB- . Che71 . Chelson , P O , `` Reliability Computation Using Fault Trees '' , Technical Report -LRB- NASA-CR-124740 -RRB- , NASA Jet Propulsion Laboratory -LRB- 1971 -RRB- . Cla91 . Clarke , Stephen J and McDermid , John A , `` Software Fault Trees And Weakest Preconditions ? A Comparison And Analysis '' , To Appear , University of York , Department of Computer Science -LRB- 1991 -RRB- . Ezh85 . Ezhilchelvan , P. D. and Shrivastava , S. K. , `` A Characterisation of Faults in Systems '' , Technical Report -LRB- Sept 85 -RRB- . Lev83 . Leveson N.G. and Harvey P.R. , `` Software fault tree analysis '' , Journal of Systems and Software 3 -LRB- 2 -RRB- , pp. 173-81 , J. Syst . Softw . -LRB- USA -RRB- -LRB- June 1983 -RRB- . Lin87 . Linton , Mark A , Calder , Paul R and Vlissides , John M , `` The Design And Implementation Of InterViews '' , Proceedings of the USENIX C++ Conference -LRB- November 1987 -RRB- . Mur92 . Murdoch , John , Pearce , D and Ward , G , `` Logic Modelling Of Dependable Systems '' , Proceedings of the IFAC Symposium On Safety Of Computer Control Systems , Zurich -LRB- 28-30 October 1992 -RRB- . Rah90 . Raheja , Dev , `` Software System Failure Mode And Effects Analysis -LRB- SSFMEA -RRB- ? A Tool For Reliability Growth '' , Proceedings of the International Symposium on Reliability and Maintainability , Tokyo , pp . IX-1 - IX-7 -LRB- 1990 -RRB- . Smi88 . Smith , William W. , Campbell , Roy and LaLiberte , Dan , User Manual For Leif With GNU Emacs , University of Illinois -LRB- 1988 -RRB- . Tou58 . Toulmin , Stephen , The Uses Of Argument , Cambridge University Press -LRB- 1958 -RRB- . Ves81 . Veseley , W E , Fault Tree Handbook , Division of the System Safety Office of Nuclear Reactor Regulation , US Nuclear Regulatory Commission , Washington DC -LRB- 1981 -RRB- .

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O B I O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

failure modes
failure propagation
fault trees
safety assessment

failure transformation
integration of methods


A Convergence Theorem for Chaotic Asynchronous Relaxation John C. Strikwerday Computer Sciences Department University of Wisconsin-Madison Abstract We present a convergence result for chaotic asynchronous relaxation that is a modification of the result of Chazan and Miranker . The modification is a restriction to the case of global memory or fast communication . The extra restriction is that each update is based on a prior state of the system , rather than based on prior sub-states of the system . AMS -LRB- MOS -RRB- classifications : 65F10 1 . Introduction . In their seminal paper -LSB- 5 -RSB- Chazan and Miranker studied chaotic relaxation , now usually called asynchronous relaxation , for the solution of linear systems . In chaotic relaxation the order in which components of the solution are updated is arbitrary and the past values of components that are used in the updates are also selected arbitrarily . This is meant to be a model for parallel computation in which different processors work independently and have access to data values in local memory . The chaotic model of Chazan and Miranker is interesting because of the great generality allowed and because there is a simple necessary and sufficient condition for the system to converge for chaotic updates . The model of Chazan and Miranker is an extreme model in that many real systems place more restrictions on the process than Chazan and Miranker do . Much of the paper -LSB- 5 -RSB- deals with the special case of periodic relaxation , in which there is a well-define order to the process of updating . Much of the work that has followed that of Chazan and Miranker extends the analysis of periodic relaxation , see , for example , -LSB- 4 -RSB- and -LSB- 6 -RSB- . At the end of -LSB- 5 -RSB- Chazan and Miranker prove an interesting very general theorem on convergence for chaotic iteration . In this paper we present , we believe , the first theorem y This work was supported in part by the National Science Foundation under grant DMS-9208049 that modifies their general theorem for chaotic relaxation . Our version of chaotic relaxation is more restrictive than is that of Chazan and Miranker . The structure of this paper is as follows . Section 2 presents the chaotic relaxation of Chazan and Miranker with a discussion of our modification . Both the general theorem of Chazan and Miranker and our new result are stated . Section 3 presents the proof of our theorem and Section 4 presents some conclusions . 2 . Chaotic Asynchronous Relaxation . We consider the solution of linear systems of the form -LRB- I ? B -RRB- ~ x = ~ d -LRB- 2:1 -RRB- where I is the N by N identity matrix , B is an N by N matrix , ~ d is the data vector , and ~ x is the vector of unknowns . Both ~ x and ~ d have N components . The iteration begins with an initial vector ~ x0 and proceeds by computing successive iterates ~ x ? : We first establish some notation . The spectral radius of a matrix A will be denoted by ae -LRB- A -RRB- : We define the absolute value of a vector ~ x to be the vector whose components are the absolute values of ~ x ; and we denote the absolute value of ~ x as j ~ xj : The absolute value of a matrix A is defined similarly and will be written jAj : The Euclidean norm of a vector ~ x will be written as k ~ xk : Chaotic relaxation as defined by Chazan and Miranker can be specified in terms of two functions , an update function u -LRB- ? -RRB- and a shift function s -LRB- ? ; ? -RRB- : For each nonnegative integer ? the component to be updated at step ? is given by u -LRB- ? -RRB- : For the update at step ? the value of the mth component used in the update is the value at s -LRB- ? ; m -RRB- steps back . This can be expressed as x ? +1 ` = PNm = 1 b ` ; mx ?? s -LRB- ? ; m -RRB- m + d ` for ` = u -LRB- ? -RRB- ; x ? +1 ` = x ? ` for ` < > u -LRB- ? -RRB- : The standard Jacobi and Gauss-Seidel methods of solution are particular cases in which there is a repeating pattern to the updating of components . For example , the Jacobi method can be described by u -LRB- ? -RRB- =-LRB- ? mod N -RRB- + 1 s -LRB- ? ; m -RRB- = ? mod N ; and similarly , the Gauss-Seidel method can be described by u -LRB- ? -RRB- =-LRB- ? mod N -RRB- + 1 s -LRB- ? ; m -RRB- = 0 : As is well known , a necessary and sufficient condition for the convergence of the Jacobi method is that ae -LRB- B -RRB- be less than 1 . Of interest here are cases where there is no particular pattern to the order of the updates . Bertsekas and Tsitsiklis -LSB- 2 , page 435 -RSB- consider a seemly more general form of asynchronous relaxation in which the function u -LRB- ? -RRB- takes sets as values . All the components in the set u -LRB- ? -RRB- are updated at step ? : However , it is easily seen that this is equivalent to the chaotic relaxation of Chazan and Miranker under a renumbering of the steps . The update and shift functions are required to satisfy the following conditions . Condition 1 . The update function u -LRB- ? -RRB- takes on each value ` for 1 < = ` < = N infinitely often . Condition 2 . The shift function is bounded , that is , there is an integer ? s such that < = s -LRB- ? ; m -RRB- < ? s : For the initial steps to be well defined , we require s -LRB- ? ; m -RRB- < = ? ; as well . Condition 1 is obviously necessary for the process to converge , and Bertsekas -LSB- 3 -RSB- has an example of a non-converging process in the case that Condition 2 fails to hold . For the general chaotic relaxation as defined here , Chazan and Miranker have proved the following stability theorem . -LRB- See also Bertsekas and Tsitsiklis -LSB- 2 -RSB- for a proof . -RRB- Theorem 2.1 . A necessary and sufficient condition for the chaotic iteration to converge for all update functions and shift functions satisfying Conditions 1 and 2 is the condition ae -LRB- jBj -RRB- < 1 : An interesting feature of the definition of Chazan and Miranker is the extreme generality allowed . We emphasize two features especially . First , if a component is updated twice , say u -LRB- ? 1 -RRB- = u -LRB- ? 2 -RRB- = ` with ? 1 < ? 2 there is no constraint on s -LRB- ? 1 ; m -RRB- compared with s -LRB- ? 2 ; m -RRB- : A reasonable restriction would be to require more recent data in the update at ? 2 than was used at ? 1 : In particular , one might require ? 1 ? s -LRB- ? 1 ; m -RRB- < = ? 2 ? s -LRB- ? 2 ; m -RRB- when u -LRB- ? 1 -RRB- = u -LRB- ? 2 -RRB- for ? 1 < ? 2 : -LRB- 2:2 -RRB- Secondly , for processes in which there is a global common memory or in which there is some control of the consistency of the data , the update of any particular component would be required to use the data at a given state . That is , the function s -LRB- ? ; ? -RRB- would be independent of m : In this case the update of component u -LRB- ? -RRB- depends only on the vector ~ x ?? s -LRB- ? -RRB- : This condition can be stated as : Condition 3 . The shift function is independent of m : Here we are interested in considering a modification of the processes allowed by Chazan and Miranker by considering the Condition 3 along with Conditions 1 and 2 . In the notation of Bertsekas and Tsitsiklis -LSB- 2 -RSB- this condition is that o ij -LRB- t -RRB- is independent of j : Our main result is the following theorem . Theorem 2.2 . A necessary and sufficient condition for the chaotic iteration to converge for all update functions and shift functions satisfying Conditions 1 , 2 , and 3 is the condition ae -LRB- jBj -RRB- < 1 : The proof of this result does not follow from the proof of Chazan and Miranker because the construction of the non-converging sequence in -LSB- 5 -RSB- depends heavily on the function s -LRB- ? ; ? -RRB- depending on the component of the vector . In fact , the construction of the non-converging sequence for the restricted case of Theorem 2.2 is more involved than in the general case of Theorem 2.1 . 3 . Proof of Theorem 2.2 . The proof that the condition ae -LRB- jBj -RRB- < 1 implies that the restricted processes will converge follows from the theorem of Chazan and Miranker . However , we include it here for completeness . The proof of the following lemma is due to Baudet -LSB- 1 -RSB- . Lemma 3.1 . The condition ae -LRB- jBj -RRB- < 1 implies that there is a value with < < 1 and a vector ~ p with positive components such that jBj ~ p < = ~ p : Proof . Suppose first that jb ` ; mj > for all components of jBj : Then by Perron 's Theorem -LSB- 7 , vol . 2 , page 53 -RSB- on positive matrices , the largest eigenvalue of jBj is simple and the eigenvector has positive values . If ~ p is this eigenvector and is the eigenvalue then jBj ~ p = ~ p ; and the theorem is proved in this special case . If b ` ; m = for some entries of B ; consider the matrix B '' in which all zero entries in B are replaced by a small positive value '' : Since the spectral radius of a matrix is a continuous function of the matrix entries , we can choose '' small enough so that ae -LRB- jB `` j -RRB- is less than 1 . As in the special case above there is an and ~ p satisfying jB `` j ~ p = ~ p : However , we also have jBj ~ p < = jB `` j ~ p = ~ p : This proves the lemma . Proof of Theorem 2.2 . We first prove that if ae -LRB- jBj -RRB- < 1 ; then the process is convergent . We consider the difference between x ? ; the solution of the system -LRB- 2.1 -RRB- , and the iterates . Let ~ y ? = ~ x ? ? ~ x ? : Using the vector ~ p and value discussed in Lemma 3.1 , we consider the first ? s vectors in the process . Since all components of ~ p are positive , there is a positive value M such that j ~ y ? j < = M ~ p for < = ? < ? s : Consider any component updated using any of these ? s vectors , the update satisfies the estimate jy ? +1 ` j < = N X m = 1 jb ` ; mjjy ?? s -LRB- ? -RRB- m j < = ffMv ` If ? 1 is the first instance after ? s for which all the components have been updated , then j ~ y ? 1 j < = ffM ~ p : Moreover , j ~ y?j < = ffM ~ p for all ? greater than ? 1 : Similarly , if ? 2 is the next instance after ? 1 for which all components have again been updated , then j ~ y ? j < = 2M ~ p for all ? greater than ? 2 : In this way we see that ~ y ? converges to 0 . We now consider the proof that if ae -LRB- jBj -RRB- > = 1 ; then there is an update function u -LRB- ? -RRB- and a shift function s -LRB- ? -RRB- such that the process does not converge . We may assume that ae -LRB- B -RRB- < 1 ; since if this is not the case , the Jacobi method does not converge . Our construction relies on the following simple lemma . Lemma 3.2 . Let B be a matrix with ae -LRB- B -RRB- > = 1 and let Z be a non-zero vector such that BTZ = > = Z with j > = j > = 1 : If X is a vector such that XTZ < > ; then kBnXk is bounded away from 0 . The proof follows immediately from the relations . < j > = n ZTXj = j -LRB- -LRB- BT -RRB- nZ -RRB- TXj = jZT -LRB- BnX -RRB- j < = kZkkBnXk : The construction of a process that does not converge involves the construction of an auxiliary process that starts from a large set of initial vectors and can be shown to be nonconvergent . Then we show that there exist nonconvergent processes that start with a single vector . The auxiliary process starts with a set of P + 1 vectors w ? for < = ? < = P : We construct a process that diverges , starting with these vectors . Let ~ v be an eigenvector of jBj with eigenvalue > = , i.e. , jBj ~ v = > = ~ v and let ~ v > = and > = > = 1 : We begin with a sequence of vectors ~ w ? for < = ? < = P for some integer P satisfying the following three criteria . 1 . j ~ w ? j = ~ v : 2 . Between successive vectors ~ wi and ~ wi +1 there is precisely one component that changes sign . 3 . For each row of B ; there is a ~ w ? with the same pattern of signs and a ~ w ? with the opposite pattern of signs . That is , for each ` there is some ? and some ? such that N X m = 1 b ` ; mw?m = N X m = 1 jb ` ; mjvm = > = v ` and N X m = 1 b ` ; mw?m = ? N X m = 1 jb ` ; mjvm = ? > = v ` : Notice that P must be at least 2N and can be taken to be less than N2 : We conjecture that P can always be chosen proportional to N : For each m with < = m < = N ; let oem be the sign of ~ w0m : We first construct vectors ~ w ? +1 for P < = ? < P + N : For now we define the update function u -LRB- ? -RRB- and the shift function s -LRB- ? -RRB- only for ? greater than and equal to P : Let ` = 1 + -LRB- ? ? P -RRB- mod N and then determine ? with < = ? < = P such that ~ w ? has the sign sequence of the ` - th row of B if oe ` = 1 or where ~ w ? has the opposite sign sequence of the ` - th row of B if oe ` = ? 1 : Then for P < = ? < P + N set u -LRB- ? -RRB- = ` and s -LRB- ? -RRB- = ? ? ? : With this choice of u -LRB- ? -RRB- and s -LRB- ? -RRB- we have for ` = u -LRB- ? -RRB- N X m = 1 b ` ; mw ?? s -LRB- ? -RRB- m = N X m = 1 b ` ; mw?m = oe ` N X m = 1 jb ` ; mjvm = oe ` > = v ` = > = w0 ` : In this way , the vector ~ wP + N is > = ~ w0 : For ? from P + N up to 2P + N ; the update and shift functions are defined as follows . For ? in this range , define ? as ? ? P ? N : The vectors ~ w ? and ~ w ? +1 differ only in the sign of one component . Let this component be ` ; we define u -LRB- ? -RRB- = ` : We define s -LRB- ? -RRB- in this way . If the sign of ~ w ? +1 ` is positive , let o with < = o < = P be the index of the vector ~ wo that has the same sign sequence as the ` - th row of B : If the sign of ~ w ? +1 ` is negative , let o with < = o < = P be the index of the vector ~ wo that has the opposite sign sequence as the ` - th row of B : Then s -LRB- ? -RRB- = ? ? o : With this choice of u -LRB- ? -RRB- and s -LRB- ? -RRB- ; the vector ~ w ? +1 has the same sign sequence as ~ w ? +1 ? P?N and is , in fact , > = ~ w ? +1 ? P?N : In this way the vectors ~ w ? for P + N < = ? < = 2P + N are equal to > = times the sequence ~ w ? for < = ? < = P : For ? greater than or equal to 2P + N ; the functions u -LRB- ? -RRB- and s -LRB- ? -RRB- are defined by periodicity with period P + N We now construct the matrix B and vector Y : The vector Y is formed by using the direct sum of the vectors ~ w ? for ? = ; : : : ; P : -LRB- The dimension of Y is N -LRB- P + 1 -RRB- :-RRB- The rows and columns of B are indexed by the ordered pairs -LRB- ? ; m -RRB- where < = ? < = P and 1 < = m < = N : The first N rows of B are defined using the steps to construct w ? for P < = ? < P + N B -LRB- 0 ; ` -RRB- -LRB- ; m -RRB- = ae b ` ; m if = P + ` ? 1 ? s -LRB- P + ` ? 1 -RRB- ; otherwise . The elements B -LRB- ff ; ` -RRB- -LRB- ; m -RRB- for > are constructed using the update and shift functions for P + N < = ? < 2P + N : B -LRB- ff ; ` -RRB- -LRB- ; m -RRB- = 8 < : b ` ; m if = + P + N ? 1 ? s -LRB- + P + N ? 1 -RRB- ; and ` = u -LRB- + P + N ? 1 -RRB- ; B -LRB- ? 1 ; ` -RRB- -LRB- ; m -RRB- otherwise . The vector BY is the vector formed from the ~ w ? for P + N < = ? < = 2P + N : In general , the vector BmY is the vector formed from the ~ w ? for m -LRB- P + N -RRB- < = ? < = -LRB- m + 1 -RRB- P + mN : By the construction of B ; we have that BY = > = Y : We now construct the sequence starting from an initial vector ~ x0 : Let Z be a vector such that ZTY = 1 and BTZ = > = Z : From ~ x0 we will construct a vector X such that ZTX < > ; and by Lemma 3.2 , this will imply that the process starting with ~ x0 is nonconvergent . Partition the components of Z in the same way as those of Y : We index the components as z?i : Some of the components of Z must be nonzero , choose a component i ? such that for some ? the product vi?z?i ? is nonzero . Define ?? = max < = ? < = Pf ? : vi?z?i ? < > g : Let j ? be any index other than i ? : By the construction of B and because Z is a left eigenvector , ?? is not zero . Since we assume that ae -LRB- B -RRB- < 1 ; the matrix I ? B is nonsingular and we define ~ x0 by -LRB- I ? B -RRB- ~ x0 = ? ~ v : Note that B ~ x0 = ~ x0 + ~ v : Define u -LRB- ? -RRB- = j ? for < = ? < P and define s -LRB- ? -RRB- = ? for these same values . Thus the vectors ~ x ? are equal to ~ x0 except in the j ? - th component , where the value is x0j ? + vj ? : The vector X of dimension N -LRB- P + 1 -RRB- is formed from the components of the ~ x ? in order . To use Lemma 3.2 we need to consider the dot product of X and Z : This is the sum of the dot products of ~ x ? with ~ z ? : That is , XTZ = ~ x0 ? PX ? = 0 ~ z ? + vj ? PX ? = 1 z?j ? : If XTZ is nonzero , then by Lemma 3.2 , the sequence kBnXk is nonconvergent . This implies that the chaotic process is nonconvergent . If XTZ is zero , we modify the above process to have u -LRB- ?? ? 1 -RRB- = i ? instead of u -LRB- ?? ? 1 -RRB- = j ? : In this case the dot product is XTZ = ~ x0 ? PX ? = 0 ~ z ? + vj ? PX ? = 1 z?j ? + vi?z ?? i ? = vi?z ?? i ? < > ; and therefore , as above , this process is nonconvergent . This proves Theorem 2.2 . 4 . Conclusions and Discussion . We have given a necessary and sufficient condition for the convergence of chaotic relaxation under the additional constraint that there be a definite state to the data at each step of the chaotic iteration . A interesting topic for further study would be the analysis of systems that are less chaotic than the general system of Chazan and Miranker -LSB- 5 -RSB- , but allow for behavior that is not deterministic . The situation in which there is some constraint on older data not being available once newer data is available , see -LRB- 2.2 -RRB- , appears to be much more difficult than the case studied here . We have not been able to use the methods of this paper to approach this question . From the proof of Theorem 2.2 , it appears that the addition of Condition 3 requires that the nonconvergent sequence has a greater value of ? s than did the construction of Chazan and Miranker . It would be of interest to see how the results of Theorem 2.2 would be modified under restrictions on ? s : References -LSB- 1 -RSB- G. Baudet , Asynchronous iterative methods for multiprocessors , J. ACM , 25 -LRB- 1978 -RRB- , pp. 225-244 . -LSB- 2 -RSB- D.P. Bertsekas and J.N. Tsitsiklis , Parallel and Distributed Computing , Numerical Methods , Prentice-Hall , Inc. , Englewood Cliffs , N.J. , 1989 . -LSB- 3 -RSB- D.P. Bertsekas and J.N. Tsitsiklis , Some aspects of parallel and distributed algorithms - a survey , Automatica , 27 -LRB- 1991 -RRB- , pp. 3-21 . -LSB- 4 -RSB- R. Bru , L. Elsner , and M. Neumann , Models of parallel chaotic iteration methods , Lin . Alg . Appl. , 103 -LRB- 1988 -RRB- , pp. 175-192 . -LSB- 5 -RSB- D. Chazan and W. Miranker , Chaotic relaxation , Lin . Alg . Appl. , 2 -LRB- 1969 -RRB- , pp. 199-222 . -LSB- 6 -RSB- J.D.P. Donnelly , Periodic chaotic relaxation , Lin . Alg . Appl. , 4 -LRB- 1971 -RRB- , pp. 117-128 . -LSB- 7 -RSB- F.R. Gantmacher , The Theory of Matrices , Chelsea Publishing Co. , New York , 1959 .

O O O O O B I O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O B I O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

asynchronous relaxation
chaotic relaxation