Reasoning With Diagrams : Symptom Abstraction

R.P.Clark

November 29, 2009

Abstract

In modular systems design, it is often very useful to know the failure modes of the sub-systems used. This paper outlines a technique for determining the failure modes of a sub-system given its component parts, and the failure modes of those parts.

The technique uses a graphical notation, based on Euler and Constraint diagrams to model failure modes and failure mode common symptom collection. The technique is designed for making the building blocks for a hierarchical fault model.

Once the failure modes have been determined for a sub-system, that sub-system may be treated as a ‘component’ or ‘black box’ and used in conjunction with other such analysed sub-systems, to model higher level sub-systems. In this way a hierarchy to represent the fault behaviour of a system can be built.

The hierarchy is built from the bottom up. Starting with component failure modes at the bottom. Because the process is bottom-up no component failure mode can be overlooked. Once a hierarchy is in place it can be converted into a fault data model.

From the fault data model, automatic generation of FTA[3] (Fault Tree Analysis) and mimimal cuts sets[4] are possible. Also statistical reliability[5] and MTTF (Mean Time to Failure) calculations can be produced automatically, where component failure mode statistics are available[1].

This paper focuses on the process of building the blocks that are used in the hierarchy.

1 Introduction

1.1 Static Analysis

In the field of safety critical engineering; to comply with European Law a product must be certified under the approriate ‘EN’ standard. Typically environmental stress, EMC, electrical stressing, endurance tests, software inspections and project management quality reviews are applied[6].

Static testing is also applied. This is theoretical analysis of the design of the product from the safety perspective. Three main techniques are currenly used, Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis). The technique outlined here aims to provide a mathematical frame work to assist in the production of these three results of static analysis.

It aims to

• To automate the process where possible

• To apply a documented trail for each analysis phase (determination of functional groups, and analysis of component failure modes on those groups)

• To use a modular approach so that analysed sub-systems can be re-used

• Automatically ensure no failure mode is unhandled

• To produce a data model from which FTA, FMEA and statistical failure models may be obtained automatically

1.2 Systems, functional groups, sub-systems and failure modes

It is helpful here to define some terms, system, functional group, component, base component

A System, is really any coherent entity that would be sold as a safety critical product. A sub-system is a system that is part of some larger system. For instance a stereo amplifier separate is a sub-system. The whole Sound System, consists perhaps of the following ‘sub-systems’: CD-player, tuner, amplifier separate, loudspeakers and ipod interface.

Thinking like this is a top down analysis approach and is the way in which FTA[4] analyses a System and breaks it down.

A sub-system will be composed of component parts, which may themselves be sub-systems. However each ‘component part’ will have a fault/failure behaviour and it should always be possible to obtain a set of failure modes for each ‘component’.

If we look at the sound system again as an example; the CD player could fail in serveral distinct ways, no matter what has happened to it or has gone wrong inside it.

Using the reasoning that working from the bottom up forces the consideration of all possible component failures (which can be missed in a top down approach) we are presented with a problem. Which collections of base components should we choose ?

For instance in the CD player example; to start at the bottom; we are presented with a massive list of base components, resistors, motors, user switches, laser diodes all sorts ! Clearly, working from the bottom up we need to pick small collections of components that work together in some way. These are termed ‘functional groups’. For instance the circuitry that powers the laser diode to read the CD might contain a handful of components, and as such would make a good candidate to be one of the base level functional groups.

In choosing the lowest level (base component) sub-systems we would look for the smallest ‘functional groups’ of components within a system. A functional group is a set of components that interact to perform a specific function.

When we have analysed the fault behaviour of a functional group, we can treat it as a ‘black box’. This type of thinking is starting to become more commonplace in product literature, with the emergence of reliability safety standards such as IOC1508[6],EN61508[5]. FIT (Failure in Time - expected number of failures per billion hours of operation) values are published for some microcontrollers. A micro controller is a complex sub-system in its self and could be considered a ‘black box’ with a given reliability. ^{1}

As electrical components have detailed datasheets a useful extension of this would be failure modes of the component, with environmental factors and MTTF statistics.

Currently this sort of information is generally only available for generic component types[1]. We can now call our functional group a sub-system. We know how will behave under fault conditions !

At higher levels of analysis, functional groups are pre-analysed sub-systems that interact to perform a given function.

Definition  Description
System  A product designed to

work as a coherent entity

Sub-system  A part of a system,

sub-systems may contain sub-systems

Functional Group A collection of sub-systems and/or

components that interact to perform a specific function

Base Component Any bought in component, which

hopefully has a known set of failure modes

Failure mode  A way in which a System,

Sub-system or component can fail

2 The Symptom abstraction Process

symptom abstraction described The objective here is to analyse the functional group and find out what will happen to it when it components fail. Once we know how it fails as a functional group, we can treat it as a component or sub-system with a known set of failure modes.

Each failure mode (or combination of) investigated is termed a ‘test case’. Each ‘test case’ is analysed. The component failure modes are taken into consideration and their effect on the functional group. When all ‘test cases’ have been analysed a second phase is applied. This looks at the results of the ‘test cases’ as symptoms of the sub-systems failed components. In this way ‘test cases’ are collected as common symptoms from the perspective of the sub-system. To go back to the CD player example, a failed output stage, and a failed internal audio amplifier, will both cause the same failure; no sound !

symptom abstraction represented on the diagram From the collection of parts for the sub-system under analysis, a set of failure modes for each component is obtained. A diagram is then drawn with each component failure mode represented by a contour. An analysis phase is now applied, where component failure modes are chosen for ‘test cases’.^{2}

1Microchip sources give an FIT of 4 for their PIC18 series micro controllers[2], The DOD 1991 reliability manual[1] applies a FIT of 100 for this generic type of component

2Combinations of component failure modes can be represented by overlapping contours

A ‘test case’ is represented on the diagram as a point or asterisk, in a region enclosed by the contours representing the failure modes it investigates.

The effect on the sub-system of the test cases is analysed. It is appropriately labeled, and then the next test case is analysed. When all test cases have been analysed, we switch our attention to a higher abstraction level.

We can now try to simplfy this diagram by determining common symptoms. A common symptom, in this context, is defined as faults caused by different component failure modes that have the same effect from the perspective4 of a ‘user’ of the sub-system.

Test case results can now viewed as failure modes of the sub-sytem or ‘black box’, and grouped together where there are common symptoms. They are grouped together by joining them with lines. These lines form them into collected groups (or ‘spiders’). It can be seen now that each lone test case and spider on the diagram is a distinct failure mode of the sub-system. This means that these failure modes represent the fault behaviour of the sub-system. We can now treat this sub-system as a component in its own right, or in other words, we have derived a failure mode model at a higher level of abstraction.

We can now draw a new diagram to represent the failure modes of the subsystem. Each spider or lone test case, becomes a contour representing a failure mode of the sub-system in this new diagram.

3 The Process : To analyse a base level subsystem

To sumarise:

• Determine a minimal functional group

• Obtain list of components in the functional group

• Collect the failure modes for each component

• Draw these as contours on a diagram

• Where multiple failures are examined use overlapping contours

• For each region on the diagram, make a test case

• Examine each test case and determine the effect of the component failure modes on the behaviour of the functional group

• Collect common symptoms. Imagine you are handed this functional group as a ‘black box’, a sub-system to use. Determine which test cases produce the same fault symptoms. Join common symptoms with lines connecting them (sometimes termed a ‘spider’).

• The lone test cases and the spiders are now the fault mode behaviour of the sub-system.

• A new diagram can now be drawn where each spider, or lone test case from the original diagram is represented as a contour. These contours represent the failure modes of the sub-system.

Figure 1: SS_{cfm} Component Failure modes represented as contours

4 A general Sub-System example

Consider a sub-system SS with component parts A,B and C. Each part has a set of related fault modes (i.e. ways in which it can fail to operate correctly). Let us define the following failure modes for each component part, defining a function F M() where K is a component part and F is its set of failure modes^{3}.

F M : K ↦ F

For our example above

F M(A) = {a_{1}, a_{2}, a_{3}}
F M(B) = {b_{1}, b_{2}}
F M(C) = {c_{1}, c_{2}}

We can now represent the sub-system as a set of component faulure modes SS_{cfm}, thus

SS_{cfm} = {a_{1}, a_{2}, a_{3}, b_{1}, b_{2}, c_{1}, c_{2}}  (1)

The failure modes of the components can be represented as contours on on the diagram in ??.

We can now look at the effects that component failure modes have on the sub-system. This process involves examining ‘test cases’. Each ‘test case’ represents the fault behaviour of the sub-system due to particular combinations of component fault modes.

3Base component failure modes are defined, often with statistics and evironmental factors in a variety of sources. [1]

Figure 2: Component Failure modes with analysed test cases

Each test case can be represented on the diagram as a labeled point. The labeled point will reside in a region on the diagram enclosed by the contours representing particular component fault modes. The label will indicate the fault symptom from the perspective of the sub-system. For the sake of example, only single component failure modes are considered. We can now assign a test case to each contour, and mark it on the diagram.

Component Failure Mode test case
a 1  fs 1
a 2  fs 2
a 3  fs 3
b 1  fs 4
b 2  fs 5
c 1  fs 6
c 2  fs 7

The sub-system fault symptoms are now represented on the diagram as in figure 4.

A second stage of analysis is now applied. Empirically, it is often noticed that a sub-system will fail in the same way due to a variety of reasons. To the ‘user’ of the sub-system, it does not matter which component or combination of components has failed. The sub-system can thus be considered to have its own set of failure modes. This stage of the analysis is to determine these, to collect like symptoms. This is performed on the diagram by linking the test cases with lines to form ‘spiders’

For the sake of example let us consider the fault symptoms SP 1 = {fs_{2}, fs_{4}, fs_{5}} to be an identical failure mode at the sub-system level. These can then be joined to form a spider. Likewise let SP 2 = {fs_{1}, fs_{3}, fs_{7}} be an identical failure mode at the sub-system level. Let {fs_{6}} be a distinct failure mode at sub-system level.

The diagram can now be drawn as in figure 4.

Figure 3: Common failure modes collected as ‘Spiders’

The third stage of the process can be applied automatically. Each ‘spider’ or ‘lone test case’ becomes a contour in the new diagram.

The result of this will be, a set of failure modes for the sub-system, as though it were a black box or a component to be used in higher level designs.

We have now in SP 1, SP 2 and fs_{6} the three ways in which this sub-system can fail. In other words we have derived failure modes for this subsystem.

This sub-system may now therfore, be represented by three separate failure modes. We may now treat this sub-system as we would a component with a known set of failure modes. The failure modes of the Sub-system SS are now the set SS_{fm} = {SP 1, Sp2, fs_{6}}.

Defining the function ‘▷◁’ to represent this analysis process, we may now write

▷◁: SubSystemComponentF aultModes ⟶ SubSystemF aultModes

▷◁ SS_{cfm} :⟶ SS_{fm}  (2)

The SS_{fm} set of fault modes can be represented as an Euler diagram, and the derivation of SS_{fm} can be represented graphically as in figure ??

The derived diagram in figure 4 shows the functional group of components A, B, C analysed as a sub-system. The result is a set of fault modes that define the fault mode behaviour of that sub-system. .

This sub-system, with its three error modes, can now form a new higher level functional group for analysis.

Figure 4: Deriving a new diagram 8

5 A Complete System, analysed into sub-systems with known fault modes

The algorithm 5 describes using set theory, taking a complete system S and breaking it down into base level sub-systems with known failure modes, suitable for use in building a fault hierarchy.

6 To conclude

The technique provides a methodology for bottom-up analysis of the fault behaviour of complex safety critical systems.

6.1 Hierarchical Simplification

Because symptom abstraction collects fault modes, the number of faults to handle decreases as the hierarchy progresses upwards. This is seen in real life Systems. At the highest levels the number of faults reduces. A Sound system might have, for instance only four faults at its highest or System level,

SoundSystemF aults = {T UNER F AULT, CD F AULT, SOUND OUT F AULT, IP OD F AULT }

The number of causes for any of these faults is very large ! It does not matter which combination of causes caused the fault to the user. But as the hierarchy goes up in abstraction level the number of faults goes down.

References

[1] U. S. DOD. Reliability Prediction of Electronic Equipment. DOD, 1991.

[2] Microchip. Microchip technology inc. home page. Available from http://www.microchip.com/, 2009.

[3] NASA. Fault tree handbook with aerospace applications. NASA Handbook, 2002.

[4] U. N. reg commission. Fault tree handbook. Nuclear Safety Analysis Handbook, 1981.

[5] E. N. Standard. Functional safety of electrical/electronic/programmable electronic safety related systems. EN61508, 2002.

[6] N. Storey. Safety-Critical Computer Systems ISBN 0-201-42787-7. Prentice Hall, 1996.

 Stored on Ultra 10 CVS repository
 $Id: symptom_abstraction.tex,v 1.10 2009/11/28 20:05:33 robin Exp $

Algorithm 1 Symptom abstraction : Base component level analysis

Require: Obtain a list of components for the System S under investigation. Ensure: Decomposition of S into atomic components where each component c

has a know set of fm failure modes. 1: Determine functional groups fg_{n} ⊂ S of components, where n is an in-

dex number and the number of functional groups found. { The functional groups should be chosen to be minimally sized collections of components that perform a specific function.}

Require: Ensure that all components belong to at least one functional group

⋃_{i=1...n} fg_{i} = S okular 2: let the function F M take a component and return a set of all its failure

modes. 3: let fm_{i} be a set of failure modes 4: for all fg_{i} ∈ S iterate using i do 5: for all c ∈ fg_{i} do 6: fm_{i}+ = F M(c) 7: end for 8: Define a sub-system SS_{i} as a set of test cases tc_{j} where j is an index and

the number of test cases. 9: Choose the combinations of failure modes to be analysed tc_{j} =⊂ ⋂ fm_{i} {

the combinations of failure modes to test will be a subset of the powerset of the failure modes, j represents an index of the test cases}

Ensure: All failure modes are represented in a test case ∀a|a ∈ fm_{i}(a ∈

tc_{i}|tc_{j} ∈ SS_{i}) 10: for all tc_{j} ∈ SS_{i} do 11: Analyse the sub-system’s fault behaviour under the failure modes in tc_{i} 12: Label tc_{j} according to failure effects 13: end for

{Now all test cases have been analysed, collect common symptoms} 14: Let ts be a common symptom indexed by k. 15: Let ▷◁ be the symbol for symptom collection 16: Let SSF M_{i} be a set of failure modes respresenting the behaviour of F M_{i}

as a sub-system 17: for all tc_{j}inSS_{i} do 18: Collect all common symptoms (with spiders) into spiders (ts_{j}). Add

these to set SSF M_{i} 19: Collect all lone test cases add to set SSF M_{i} Ensure: That all lone test cases + the contents of the spiders are all the

test cases Ensure: that no lone test case belongs to a spider and vice versa 20: end for 21: Now all functional groups identified have been converted into ▷◁ (SS_{i}) =

SSF M_{i} sets 22: We now have a collection of sub-systems with known fault behaviour. 23: end for