From 0aa4c9e92472193c9a4a62c9ba2b7f6898c2b133 Mon Sep 17 00:00:00 2001 From: Robin Date: Fri, 25 Jun 2010 19:49:44 +0100 Subject: [PATCH] Friday edits --- components_as_plds/components_as_plds.tex | 6 +- fmmdset/Makefile | 3 +- fmmdset/fmmdset.tex | 153 +--- logic_diagram/logic_diagram.tex | 44 +- statistics/statistics.tex | 45 ++ style.tex | 128 ++-- sw_as_plds/sw_as_plds.tex | 106 ++- .../symptom_ex_process_paper.tex | 719 ------------------ thesis.tex | 5 +- 9 files changed, 243 insertions(+), 966 deletions(-) delete mode 100644 symptom_ex_process/symptom_ex_process_paper.tex diff --git a/components_as_plds/components_as_plds.tex b/components_as_plds/components_as_plds.tex index e13d243..0c29891 100644 --- a/components_as_plds/components_as_plds.tex +++ b/components_as_plds/components_as_plds.tex @@ -37,7 +37,7 @@ Every component in a electrical circuit may fail in several ways. The most obvious ways for them to fail are that legs of the circuit become disconnected or are shorted. -Components may fail internally. Some may have failure modes due to environmentalfactors. +Components may fail internally. Some may have failure modes due to environmental factors. % SPACE SOLDER EVAPORATING % TEMPERATURE EFFECTS SUCH AS INACCURACY, LEAKAGE OF CURRENT ETC @@ -45,7 +45,7 @@ Each component thus has a set of possible failure modes. Looking at this independently of cause, we can in the worst case consider that any of these errors could occur at any time. -In analysing a circuit we should look take into consideration +In analysing a circuit we should take into consideration all possible failure modes, and where appropriate, how these failure modes will affect other components in the circuit. @@ -74,7 +74,7 @@ be OPEN circuit.This again would create an OPEN circuit. It could become shorted by some foreign material, or in the production soldering process. This again would have the same effect. It would appear to be a SHORT circuit. It could be overstressed and burnt out, (by the application of an out of spec current for instance). -Resistors typically can drift in value with temperature. For someapplications this may not be important. +Resistors typically drift slightly in value with temperature. For some applications this may not be important. The manufacturers data-sheet will describe the temperature drift co-effecients and operating ranges. We can represent our resistor then to be in four operational states, $R_s = \{ OK, OPEN, SHORT, T\_DRIFT \}$. diff --git a/fmmdset/Makefile b/fmmdset/Makefile index 3a1aa33..a577cc2 100644 --- a/fmmdset/Makefile +++ b/fmmdset/Makefile @@ -7,7 +7,8 @@ paper: paper.tex fmmdset_p.tex pdflatex paper.tex #dvipdf paper - okular paper.pdf + mv paper.pdf fmmdset_paper.pdf + okular fmmdset_paper.pdf # Remove the need for referncing graphics in subdirectories diff --git a/fmmdset/fmmdset.tex b/fmmdset/fmmdset.tex index 1120614..b17ca4d 100644 --- a/fmmdset/fmmdset.tex +++ b/fmmdset/fmmdset.tex @@ -26,13 +26,13 @@ EN298, EN61508, EN12067, EN230, UL1998. The purpose of the FMMD methodology is to apply formal techniques to the assessment of safety critical designs, aiding in identifying detected and undetected faults -\footnote{Undetectabed faults +\footnote{Undetectable faults are faults which may occur but are not self~detected, or are impossible to detect by the system}. Formal methods are just begining to be specified in some safety standards.\footnote{Formal methods -such as the Z notation appear as `highly recomended' techniques in the EN61508 standard, but -apply only to software currently}.However, some standards are now implying the handling of +such as the Z notation appear as `highly recommended' techniques in the EN61508 standard, but +apply only to software currently.} However, some standards are now implying the handling of simultaneous faults which complicates the scenario based approvals that are -currently used\footnote{Standard EN298 stronlgy implies that double simultaneeous failures must be handled.}. +currently used\footnote{Standard EN298:2003 strongly implies that double simultaneeous failures must be handled.}. % Some safety critical system assemesment criteria %are statistical, and require a target failure rate per hour of operation be met \cite{EN61508}. @@ -52,7 +52,7 @@ This entails tracing the effects of all part failure modes %For instance, during WWII after operational research teams had analysed data it was determined that % an aircraft engine that can, through one part failure cause a catastrophic failure is an unacceptable design.\cite{boffin} . -Both of these methods require a complete fault analysis tree.%\cite{FMEA}. +Both of these methods require a complete fault analysis tree. The statistical method requires additional Mean Time To Failure (MTTF) data for all part failure modes. @@ -101,9 +101,9 @@ This new set of faults is the set of derived faults from the module level and is fault~mode abstraction. Thus we can say that the module as a whole entity can fail in a number of well defined ways. In other words we have taken a functional group, and analysed how it can fail according to the failure modes of its parts. -The ways in which the module can fail now become a new set of fault modes, the fault~modes -derived from the functional~group. we can now create a new `derived~component' which has -the failure symtoms of the functional~group as its set of failure modes. +The ways in which the module can fail now becomes a new set of fault modes, the fault~modes +being derived from the functional~group. We can now create a new `derived~component' which has +the failure symptoms of the functional~group as its set of failure modes. This new derived~component is at a higher failure mode abstraction level than the base components. %What this means is the `fault~symptoms' of the module have been derived. @@ -135,31 +135,32 @@ set of failure modes $S$ for the component. $$ \mathcal{FM}(C) \rightarrow S $$ We can indicate the abstraction level of a component by using a superscript. -Thus for the component $C$, where it is base component we can asign it +Thus for the component $C$, where it is a `base component' we can asign it the abstraction level zero thus $C^0$. Should we wish to index the components (for example as in a product parts~list) we can use a sub-script. Our base component (if first in the parts~list) could now be uniquely identified as $C^0_1$. -A functional group can use the letter $F$. A function group is a collection -of components. We thus define $F$ as a set of components. +A functional group can use the variable name $FG$. A functional group is a collection +of components. We thus define $FG$ as a set of components that have been chosen as members +of a functional~group. We can further define the abstraction level of a functional group. We can say that it is the maximum abstraction level of any of its components. Thus a functional group containing only base components would have an abstraction level zero and could be represented with a superscript of zero thus -$F^0$. The functional group set may also be indexed. +$FG^0$. The functional group set may also be indexed. We can apply symptom abstraction to a functional group to find a set of derived failure modes. We are interested in the failure modes of all the components in the functional group. An analysis process -defined as $\bowtie$ is applied to the functional group. +defined by the symbol `$\bowtie$' is applied to the functional~group. -$$ \bowtie(F^N) \rightarrow C^{N+1} $$ +$$ \bowtie(FG^N) \rightarrow C^{N+1} $$ -The $\bowtie$ function processes each member (component) of the set $F$ and +The $\bowtie$ function processes each member (component) of the set $FG$ and extracts all the component failure modes, which are used by the analyst to determine the derived failure modes. A new derived component is created -where its failure modes are the symptoms from $F$. +where its failure modes are the symptoms from $FG$. Note that the component will have a higher abstraction level than the functional group it analysed. @@ -172,12 +173,12 @@ An example of a simple system will illustrate this. \subsection {Example FMEA process using an FMEA diagram} -Consider a simple functional~group $ F^0_1 $ derived from two base components $C^0_1,C^0_2$. +Consider a simple functional~group $ FG^0_1 $ derived from two base components $C^0_1,C^0_2$. -We can apply $\bowtie$ to the functional~group $F$ +We can apply $\bowtie$ to the functional~group $FG$ and it will return a derived component at abstraction level 1 (with an index of 1 for completeness) -$$ \bowtie( F^0_1 ) = C^1_1 $$ +$$ \bowtie( FG^0_1 ) = C^1_1 $$ to look at this analysis process in more detail. @@ -230,7 +231,7 @@ We can represent this analysis process in a diagram see figure \ref{fig:onestage \section {Building the Hierarchy - Higher levels \\ of Fault Mode Analysis} -Figure \ref{fig:fmmdh} shows a hierarchy of failure mode descopmosition. +Figure \ref{fig:fmmdh} shows a hierarchy of failure mode de-composition. It can be seen that the derived fault~mode sets are higher level abstractions of the fault behaviour of the modules. We can take this one stage further by combining the $D^{1}_{N}$ sets to form modules. These @@ -242,7 +243,7 @@ system level fault~modes will be traceable down to part fault modes. A hierarchy of levels of faults becoming more abstract at each level should converge to a small sub-set of system level errors. -This thinning out of the number of system level errors is borne out in practise ; +This thinning out of the number of system level errors is borne out in practise; real time control systems often have a small number of major reportable faults (typically $ < 50$), even though they may have accompanying diagnostic data. @@ -270,9 +271,9 @@ even though they may have accompanying diagnostic data. \subsection{ Proof of number of part~failure \\ modes preserved in hierarchy build} -Here need to prove that if we have an abstract fault, then as it goes higher in the tree, it can only collect MORE not less +Here we need to prove that if there is an abstract fault, then as it goes higher in the tree, it can only collect MORE not less actual part~failure modes. This is obvious but needs a proof. -Also this means may need dummy modules to not violate jumping up the tree structure +Also this means that we may need dummy modules so as not to violate jumping up the tree structure %Complete coverage for all derived hierarch levels can be generalised thus: @@ -280,78 +281,6 @@ Also this means may need dummy modules to not violate jumping up the tree struct % \; \Rightarrow \; x \; \in \; \cup \; M^{h}_{y} ) $$ -\subsection{Cardinality Constrained Powerset } -\label{ccp} - -A Cardinality Constrained powerset is one where sub-sets of a cardinality greater than a threshold -are not included. This theshold is called the cardinality constraint. -To indicate this the cardinality constraint $cc$, is subscripted to the powerset symbol thus $\mathcal{P}_{cc}$. -Consider the set $S = \{a,b,c\}$. $\mathcal{P}_{2} S $ means all subsets of S where the cardinality of the subsets is -less than or equal to 2. - -$$ \mathcal{P} S = \{ 0, \{a,b,c\}, \{a,b\},\{b,c\},\{c,a\},\{a\},\{b\},\{c\} \} $$ - -$$ \mathcal{P}_{2} S = \{ \{a,b\},\{b,c\},\{c,a\},\{a\},\{b\},\{c\} \} $$ - -$$ \mathcal{P}_{1} S = \{ \{a\},\{b\},\{c\} \} $$ - -A $k$ combination is a subset with $k$ elements. -The number of $k$ combinations (each of size $k$) from a set $S$ -with $n$ elements (size $n$) is the binomial coefficient - -$$ C^n_k = {n \choose k} = \frac{n!}{k!(n-k)!}$$ - -To find the number of elements in a cardinality constrained subset S with up to $cc$ elements -in each comination sub-set, -we need to sum the combinations, -%subtracting $cc$ from the final result -%(repeated empty set counts) -from $1$ to $cc$ thus - -% -% $$ {\sum}_{k = 1..cc} {\#S \choose k} = \frac{\#S!}{k!(\#S-k)!} $$ -% - -$$ \#\mathcal{P}_{cc} S = \sum^{k}_{1..cc} \frac{\#S!}{k!(\#S-k)!} $$ - - - -\subsection{Actual Number of combinations to check with Unitary State Fault mode sets} - -Where all components analysed only have one fault mode, the cardinality constrained powerset -calculation give the correct number of test case combinations to check. -Because set of failure modes is constrained to be unitary state, the acual number will -be less. - - -What must actually be done is to subtract the number of component `internal combinations' -from the cardinality constrain powerset number. - -Thus were we to have a simple circuit with two components R and T, of which -$FM(R) = {R_o, R_s}$ and $FM(T) = {T_o, T_s, T_h}$. -For a cardinality constrained powerset of 2, because there are 5 error modes -gives $\frac{5!}/{1!(5-1)!} + \frac{5!}{2!(5-2)!} = 15$. OK -5 single fault modes, and ${2 \choose 5}$ ten double fault modes. -However we know that the faults are mutually exclusive for a component. -We must then subtract the number of `internal' component fault combinations. -For component R there is only one internal component fault that cannot exist -$R_o \wedge R_s$. As a combination ${2 \choose 2} = 1$ . For $T$ the component with - three fault modes ${2 \choose 3} = 3$. -Thus for $cc == 2$ we must subtract $(3+1)$. - -Written as a general formula, where C is a set of the components (indexed by j where J -is the set of componets under analyis) and $\#C$ -indicates the number of mutually exclusive fault modes the compoent has:- - -%$$ \#\mathcal{P}_{cc} S = \sum^{k}_{1..cc} \frac{\#S!}{k!(\#S-k)!} $$ - -$$ \#\mathcal{P}_{cc} S = {\sum^{k}_{1..cc} \frac{\#S!}{k!(\#S-k)!}} - {\sum^{j}_{j \in J} {\#C_{j} \choose cc}} $$ - - - -%$$ \#\mathcal{P}_{cc} S = \sum^{k}_{1..cc} \big[ \frac{\#S!}{k!(\#S-k)!} - \sum_{j} (\#C_{j} \choose cc \big] $$ - - %% CASE STUDY BEGIN @@ -369,21 +298,21 @@ $$ \#\mathcal{P}_{cc} S = {\sum^{k}_{1..cc} \frac{\#S!}{k!(\#S-k)!}} - {\sum^{ %\label{fig:mvsblock} %\end{figure} % -Consider a simple electronic system, that provides say two milli amplifiers -which supplies these onward via serial link - RS232. This is simple in concept, plug in a -computer, run a terminal prgram, and the instrument will report the milli volt readings in ASCII +Consider a simple electronic system, that provides say two milli-volt amplifiers +which passes the values onward via serial link - RS232. This is simple in concept, plug in a +computer, run a terminal program, and the instrument will report the milli volt readings in ASCII with any error messages. % in CRC checksum protected packets. -It is interesting to look at one of `functional groups'. The millivolt amplifiers are a good example. +It is interesting to look at one of `functional groups'. The milli-volt amplifiers are a good example. These can be analysed by taking a functional~group, the components surrounding the op-amp, a few resistors to determine offset and gain, -a safety resistor, and perhaps some smoothing capacitiors. -These components form the functional group. The circuit is then analysed for all the fault combinations -of these parts. This produces a large collection of possible fault~modes for the milli-volt amplifier. -The two amplifiers are now connected to the ADC which converts the voltages to binary words for the microprocessor. -The microporessor then uses the values to determine if the readings are valid and then formats text to send +a safety resistor, and perhaps some smoothing capacitors. +These components form a functional group. This circuit is then analysed for all the fault combinations +of its parts. This produces a collection of possible symptoms/fault~modes for the milli-volt amplifier. +The two amplifiers are now connected to an ADC which converts the voltages to binary words for the microprocessor. +The micro-processor then uses the values to determine if the readings are valid and then formats text to send via the RS232 serial line. % @@ -404,7 +333,7 @@ via the RS232 serial line. \end{figure} This has a number of obvious functional~groups, the PCB power supply, the milli-volt amplifiers, -the analog to digital conversion circuity, the micro processor and the UART (serial link - RS232 transceiver). +the analog to digital conversion circuitry, the micro processor and the UART (serial link - RS232 transceiver). It would make sense when analysing this system to take each one of these functional~groups in turn and examine them closely. It would be sensible if the system could detect the most obvious fault~modes by self testing. @@ -417,8 +346,8 @@ We have analysed each section of the circuitry, and then using the abstract errors derived from each module, can fit these into a picture of the fault~modes of the milli-volt monitor as a whole. However this type of analysis is not guaranteed -to rigourously take into account all fault~modes. -It is useful to follow an example fault though levels of abstraction hierarchy however, see below. +to rigorously take into account all fault~modes. +It is useful to follow an example fault through levels of abstraction hierarchy however. %The FMMD technique, %goes further than this by considering all part fault~modes and @@ -445,7 +374,7 @@ As an example let us consider a resistor failure in the first milli-volt sensor. Let us say that this resistor, R48 say, with the particular fault mode `shorted' causes the amplifier to output 5V. -At the part level we have one fault mode in one part. +At the part level, we have one fault mode in one part. %This is the lowest or zero level of fault abstraction. Let us say that this amplifier has been designed to amplify the milli-volt input to between 1 and 4 volts, a convenient voltage for the ADC/microcontroller to read. @@ -458,7 +387,7 @@ Looking higher in the hierarchy, the next abstraction level higher, level 2, wil a `CHANNEL\_1' input fault. %The system as a whole (abstraction level 3) will see this as %a `MILLI\_VOLT\_SENSOR' fault~mode. -%\end{example} +%\end{example}/ \subsubsection{Abstraction Layer Summary \\ for example fault.} \begin{description} @@ -496,13 +425,13 @@ This quickly becomes a priority to-do list with the most costly faults at the to \subsection { Test Rigs } -Test rigs apply a rigourous checking process to safety critical equipment before +Test rigs apply a rigorous checking process to safety critical equipment before they can be sold, and this usually is a legal or contractural requirement, backed up by inspections and and an approval process. They are usually a clamp arrangement where the PCB under test is placed. Precesion and calibrated test signals are then applied to the board under test. For PCBs containing -microprocessor, custom test~rig software may be run on them to excersize +microprocessor, custom test~rig software may be run on them to exersize active sections of the PCB (for instance to drive outputs, relays etc). The main purpose of a test rig is to prevent fault equipment from being shipped. @@ -523,7 +452,7 @@ simply be given a different index number and re-used. \subsection{ Multi Channel Safety Critical Systems } -Where a system has several independent parrallel tasks, each one can be a separate hierarchy. +Where a system has several independent parallel tasks, each one can be a separate hierarchy. % \small % \bibliography{vmgbibliography,mybib} diff --git a/logic_diagram/logic_diagram.tex b/logic_diagram/logic_diagram.tex index 86739da..4b36bed 100644 --- a/logic_diagram/logic_diagram.tex +++ b/logic_diagram/logic_diagram.tex @@ -86,7 +86,7 @@ All features may be labelled, and the labels must be unique within a diagram, ho Test cases are marked by asterisks. These are used as a visual `anchor' to mark a logical condition, the logical condition being defined by the contours that enclose the region on which the test~case has been placed. -The contours that enclose represent conjuction. +The contours that enclose represent conjunction. Test~cases may be connected by joining lines. These lines represent disjunction (Boolean `XOR') of test~cases. @@ -112,7 +112,7 @@ With these three visual syntax elements, we have the basic building blocks for a \section{Formal Description of PLD} -Definitions of conrete and abstract PLD's follow. +Definitions of concrete and abstract PLD's follow. Well-formedness conditions for PLD's are separated from this definition, because of practical differences between the way they are used to represent software as opposed to representing electronics and mechanical systems. @@ -120,7 +120,7 @@ representing electronics and mechanical systems. \subsection{Concrete PLD Definition} \paragraph{MUST REFERENCE CONSTRAINT DIAGRAMS HERE} -A concrete {\em Propositional logic diagram} is a set of labeled {\em contours} +A concrete {\em Propositional logic diagram} is a set of labelled {\em contours} (closed curves) in the plane. The minimal regions formed by the closed curves can by occupied by `test points'. The `test points' may be joined by joining lines. @@ -132,7 +132,7 @@ To differentiate these from common Euler diagram notation (normally used to repr the curves are drawn using dotted and dashed lines. \subsection{ PLD Definition} -In English: +%In English: Possible elements in a PLD diagram are contours, test points and joining lines that connect test points. { \definition{A concrete PLD $d$ is a set comprising of a set of @@ -142,7 +142,7 @@ a set of test point joining lines $J=J(d)$. } } -In English: +%In English: Each element of the diagram has a unique label within the diagram. %Thus the set of labels found in a diagram is %a subset of the powerset of characters that can be present in a label. @@ -231,7 +231,7 @@ associating a joining line with a pair of test points. The Join t1,t2 is defined } } -In English: +%In English: Test points on the concrete diagram pair-wise connected by a `joining line' @@ -290,8 +290,8 @@ A singleton test point can be considered a sequence of one test point and is the To obtain the set of propositions from a PLD, each $SMG$ must be traversed along each joining line. For each test case -in the $SMG$ a new section of the equation is disjuctively appended to it. - +in the $SMG$ a new section of the equation is disjunctively appended to it. +% Let conjunctive logic equation associated with a test point be determined from the contours that enclose it. i.e. the contours $\mathcal{X}$ from the zone it inhabits. @@ -403,7 +403,7 @@ There are no disjunctive joining lines and so this diagram represents one equati Note that $P$ is considered to be an $SMG$ with one element, $ (a \wedge b) $ \paragraph{How this would be interpreted in failure analysis} -In failure analysis, this could be considered to be a faunctional~group with two failure states $a$ and $b$. +In failure analysis, this could be considered to be a functional~group with two failure states $a$ and $b$. The proposition $P$ considers the scenario where both failure~modes are active. \clearpage @@ -443,7 +443,7 @@ substituting the test cases for their Boolean logic equations gives \end{equation} \paragraph{Failure Analysis Interpretation} -Equation \ref{eqn:l_or} would be interpretted to mean that +Equation \ref{eqn:l_or} would be interpreted to mean that either failure mode a or b occurring, would have the same failure symptom for the circuit/functional~group under analysis. @@ -452,7 +452,7 @@ under analysis. \clearpage \subsection {Labels and useage} -%In diagram \ref{fig:ld_meq} Z and W were labeled but were not necessary for the final expression +%In diagram \ref{fig:ld_meq} Z and W were labelled but were not necessary for the final expression %of $ R = b \vee c $. The intended use of these diagrams, is that resultant logical conditions be used in a later stage of reasoning. %Test cases joined by disjunction, all become represented in one, resultant equation. %Therefore only test cases not linked by any disjunctive joining lines need be named. @@ -463,7 +463,7 @@ under analysis. Diagram \ref{fig:ld_meq} shows three Functionally Merged groups, Q, R and P. -Z and W were labeled but this was not necessary for determination of the final expression +Z and W were labelled but this was not necessary for determination of the final expression of $ R = b \oplus c $. %The intended use of these diagrams, is that resultant logical conditions be used in a later stage of reasoning. %Test cases joined by disjunction, all become represented in one, resultant equation. @@ -558,7 +558,7 @@ $$ R1 = b \oplus ( a \wedge c ) $$. $R2$ joins two other test cases $$R2 = a \oplus c $$ -The test~case residing in the intersection of countours $B$ and $A$ +The test~case residing in the intersection of contours $B$ and $A$ represents the logic equation $R3 = a \wedge b$. \paragraph{How this would be interpreted in failure analysis} @@ -577,8 +577,8 @@ by the FMMD software tool. \subsection { Inhibit Failure } -Very often a failure mode can only occurr -given a searate environmental condition. +Very often a failure mode can only occur +given a separate environmental condition. In Fault Tree Analysis (FTA) this is represented by an inhibit gate.\cite{NASA},\cite{NUK} \begin{figure}[h] @@ -600,16 +600,16 @@ Contour $C$ is enclosed by contour $A$. This says that for failure~mode $C$ to occur failure mode $A$ must have occurred. A well known example of this is the space shuttle `O' ring failure that -caused the 1986 challenger disaster \cite{wdycwopt}. -For the failure mode to occur the ambient temperature had to +caused the 1986 Challenger disaster \cite{wdycwopt}. +For the failure mode to occur, the ambient temperature had to be below a critical value. If we take the failure mode of the `O' ring to be $C$ and the temperature below critical to be $A$, we can see that -the low temperature failure~mode $C$ can only occurr if $A$ is true. +the low temperature failure~mode $C$ can only occur if $A$ is true. The `O' ring could fail in a different way independant of the critical temperature and this is represented, for the sake of this example, by contour $D$. -In terms of propositional logic, the inhibit gate of FTA, and the countour enclosure +In terms of propositional logic, the inhibit gate of FTA, and the contour enclosure of PLD represent {\em implication}. \\ % \tiny @@ -802,9 +802,9 @@ analysis, but that the possibility of two component failing simultaneously must be considered. EN298 states that if a burner controller is in `lock out' (i.e. has detected a fault and has ordered a shutdown) a secondary fault cannot be allowed to put the equipement under control (the burner) into a dangerous state. -To cover this rigourously we are bound to consider more than one fault being active at a time. +To cover this rigorously, we are bound to consider more than one fault being active at a time. \paragraph{Covering Double faults in a PLD Diagram} -Because we are allowed to repeat contours in a PLD diagram +Because we are allowed to repeat contours in a PLD diagram, we can arrange them in a matrix like configuration as in figure \ref{fig:doublesim}. Note that we have here all the single and double failure test cases in one diagram. @@ -823,7 +823,7 @@ double simultaneous failure instance. \section{N Simultaneous Errors} There are systems where it may be necessary to model for N simultaneous failures. -This can be achived in a PLD diagram by enclosing a test case with +This can be achieved in a PLD diagram by enclosing a test case with all the failure modes to be modelled simultaneously, see figure \ref{fig:allfour}. For instance, a 747 Aircraft with four engines, could suffer from diff --git a/statistics/statistics.tex b/statistics/statistics.tex index 1d4b7ad..392256f 100644 --- a/statistics/statistics.tex +++ b/statistics/statistics.tex @@ -13,9 +13,54 @@ and looks at the statistical justifications for their application.} \section{Introduction} +\section{Safety and Reliability} + +- How these are different. + +- Safety is environmentally sensitive + + +In order to quantify a difference between safety and reliability we +need to determine which system failure modes are dangerous or safe. +Were a burner controller to detect a problem with an air pressure switch +and refuse to start up (and raise an alarm) we can see this is a safe failure mode. +Were a burner controller to pump fuel into the combustion chamber +and then ignite it after long duration\footnote{Most GAS safety timeouts for seeing a flame under ignition conditions specify < 3 seconds} +we would have a clear risk of a dangerous explosion. +Here, the picture is further complicated by the environment. +If the burner was placed in a remote building and operated +remotely, there would be minimal risk to life. +Were the burner to be located in a busy factory, surrounded by people +the safety risk is higher. + + + +- How safety and reliability get confused. +A tale of two customers (for integrated boiler controls). + +Customer 1. Brewery. +Impact of boiler going down, delayed production - some cost. + +Customer 2. Nuclear Powerstation. +Impact of boiler going down, no CO2 primary coolant available, possible reactor shutdown, possible emergency shutdown methods. Cost very high. + +For the Brewery, safety is of the highest importance. +For the Nuclear power station + +\section{Interfacing} + +Mech - elec - sw + +Most problems occur here need citations +look at some of Nancys accident papaers. + \section{Current Methods for Safety Critical Analysis} +\section{STAMP} + +High level technique, look at processes with feed back loops and rules, and then interfaces wbetween them. + \subsection{Deterministic Approach} \paragraph{NOT WRITTEN YET PLEASE IGNORE} diff --git a/style.tex b/style.tex index 79082ab..c2b58b5 100644 --- a/style.tex +++ b/style.tex @@ -3,32 +3,32 @@ % % Jonathan Burch This is the terse form - expanded, formatted, % 20-Jan-1989 commented version in TEX$LATEX:ASYOULIKEIT.FULL -% -\catcode`\@=11\def\ps@asyoulikeit{\def\@oddhead{\hbox{}\lp@innerhead -\lp@headfill\lp@middlehead\lp@headfill\lp@outerhead}\def\@evenhead -{\hbox{}\lp@outerhead\lp@headfill\lp@middlehead\lp@headfill\lp@innerhead} -\def\@oddfoot{\hbox{}\lp@innerfoot\lp@footfill\lp@middlefoot\lp@footfill -\lp@outerfoot}\def\@evenfoot{\hbox{}\lp@outerfoot\lp@footfill\lp@middlefoot -\lp@footfill\lp@innerfoot}\def\sectionmark##1{}\def\subsectionmark##1{}} -\def\lp@innerhead{}\def\lp@middlehead{}\def\lp@outerhead{}\def\lp@innerfoot{} -\def\lp@middlefoot{ {\thepage} }\def\lp@outerfoot{}\def\lp@headfill{\hfil} -\def\lp@footfill{\hfil}\newcommand{\lp@linefill}{\leaders\hrule height 0.55ex -depth -0.5ex\hfill}\newcommand{\innerhead}[1]{\def\lp@innerhead{#1}} -\newcommand{\middlehead}[1]{\def\lp@middlehead{#1}}\newcommand{\outerhead}[1] -{\def\lp@outerhead{#1}}\newcommand{\innerfoot}[1]{\def\lp@innerfoot{#1}} -\newcommand{\middlefoot}[1]{\def\lp@middlefoot{#1}}\newcommand{\outerfoot}[1] -{\def\lp@outerfoot{#1}}\newcommand{\lineheadfill}{\def\lp@headfill -{\lp@linefill}}\newcommand{\linefootfill}{\def\lp@footfill{\lp@linefill}} -\newcommand{\blankheadfill}{\def\lp@headfill{\hfill}}\newcommand -{\blankfootfill}{\def\lp@footfill{\hfill}}\newcommand{\documentnumber}[1] -{\def\lp@docno{#1}\outerhead{\lp@docno}}\def\lp@docno{}\def\@maketitlet -{\newpage\null\vskip -14ex\hbox{}\hfill\lp@docno\vskip 13ex\begin{center} -{\LARGE\@title\par}\vskip 1.5em{\large\lineskip .5em\begin{tabular}[t]{c} -\@author\end{tabular}\par}\vskip 1em{\large\@date}\end{center}\par\vskip 3em} -\def\abstract{\if@twocolumn\section*{Abstract}\else\small\begin{center} -{\bf Abstract\vspace{-.5em}\vspace{0pt}}\end{center}\quotation\fi}\def -\endabstract{\if@twocolumn\else\endquotation\fi}\ps@asyoulikeit\catcode`\@=12 -% +%% +%\catcode`\@=11\def\ps@asyoulikeit{\def\@oddhead{\hbox{}\lp@innerhead +%\lp@headfill\lp@middlehead\lp@headfill\lp@outerhead}\def\@evenhead +%{\hbox{}\lp@outerhead\lp@headfill\lp@middlehead\lp@headfill\lp@innerhead} +%\def\@oddfoot{\hbox{}\lp@innerfoot\lp@footfill\lp@middlefoot\lp@footfill +%\lp@outerfoot}\def\@evenfoot{\hbox{}\lp@outerfoot\lp@footfill\lp@middlefoot +%\lp@footfill\lp@innerfoot}\def\sectionmark##1{}\def\subsectionmark##1{}} +%\def\lp@innerhead{}\def\lp@middlehead{}\def\lp@outerhead{}\def\lp@innerfoot{} +%\def\lp@middlefoot{ {\thepage} }\def\lp@outerfoot{}\def\lp@headfill{\hfil} +%\def\lp@footfill{\hfil}\newcommand{\lp@linefill}{\leaders\hrule height 0.55ex +%depth -0.5ex\hfill}\newcommand{\innerhead}[1]{\def\lp@innerhead{#1}} +%\newcommand{\middlehead}[1]{\def\lp@middlehead{#1}}\newcommand{\outerhead}[1] +%{\def\lp@outerhead{#1}}\newcommand{\innerfoot}[1]{\def\lp@innerfoot{#1}} +%\newcommand{\middlefoot}[1]{\def\lp@middlefoot{#1}}\newcommand{\outerfoot}[1] +%{\def\lp@outerfoot{#1}}\newcommand{\lineheadfill}{\def\lp@headfill +%{\lp@linefill}}\newcommand{\linefootfill}{\def\lp@footfill{\lp@linefill}} +%\newcommand{\blankheadfill}{\def\lp@headfill{\hfill}}\newcommand +%{\blankfootfill}{\def\lp@footfill{\hfill}}\newcommand{\documentnumber}[1] +%{\def\lp@docno{#1}\outerhead{\lp@docno}}\def\lp@docno{}\def\@maketitlet +%{\newpage\null\vskip -14ex\hbox{}\hfill\lp@docno\vskip 13ex\begin{center} +%{\LARGE\@title\par}\vskip 1.5em{\large\lineskip .5em\begin{tabular}[t]{c} +%\@author\end{tabular}\par}\vskip 1em{\large\@date}\end{center}\par\vskip 3em} +%\def\abstract{\if@twocolumn\section*{Abstract}\else\small\begin{center} +%{\bf Abstract\vspace{-.5em}\vspace{0pt}}\end{center}\quotation\fi}\def +%\endabstract{\if@twocolumn\else\endquotation\fi}\ps@asyoulikeit\catcode`\@=12 +%% %=========== End of {asyoulikeit} page style definition ====================* \DeclareSymbolFont{AMSb}{U}{msb}{m}{n} @@ -48,22 +48,22 @@ depth -0.5ex\hfill}\newcommand{\innerhead}[1]{\def\lp@innerhead{#1}} % % Local definitions % ----------------- -\newcommand{\eg}{{\it e.g.}} -\newcommand{\etc}{{\it etc.}} -\newcommand{\ie}{{\it i.e.}} -\newcommand{\qv}{{\it q.v.}} -\newcommand{\viz}{{\it viz.}} -\newcommand{\degs}[1]{$#1^\circ$} % Degrees symbol -\newcommand{\mins}[1]{$#1^{\scriptsize\prime}$} % Minutes symbol -\newcommand{\secs}[1]{$#1^{\scriptsize\prime\prime}$} % Seconds symbol -\newcommand{\key}[1]{\fbox{\sc#1}} % Box for keys -\newcommand{\?}{\_\hspace{0.115em}} % Proper spacing for - % underscore -\newcommand{\rev}{PA5} -\newcommand{\etcdoc}{ HR222975 } -\newcommand{\wlc}{{Water~Level~Controller~Unit}} -\newcommand{\ft}{{\em 4 $\rightarrow$ 20mA } } -\newcommand{\tds}{TDS Daughterboard} +%\newcommand{\eg}{{\it e.g.}} +%\newcommand{\etc}{{\it etc.}} +%\newcommand{\ie}{{\it i.e.}} +%\newcommand{\qv}{{\it q.v.}} +%\newcommand{\viz}{{\it viz.}} +%\newcommand{\degs}[1]{$#1^\circ$} % Degrees symbol +%\newcommand{\mins}[1]{$#1^{\scriptsize\prime}$} % Minutes symbol +%\newcommand{\secs}[1]{$#1^{\scriptsize\prime\prime}$} % Seconds symbol +%\newcommand{\key}[1]{\fbox{\sc#1}} % Box for keys +%\newcommand{\?}{\_\hspace{0.115em}} % Proper spacing for +% % underscore +%\newcommand{\rev}{PA5} +%\newcommand{\etcdoc}{ HR222975 } +%\newcommand{\wlc}{{Water~Level~Controller~Unit}} +%\newcommand{\ft}{{\em 4 $\rightarrow$ 20mA } } +%\newcommand{\tds}{TDS Daughterboard} \newcommand{\oc}{$^{o}{C}$} \newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}} \newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}} @@ -75,40 +75,40 @@ depth -0.5ex\hfill}\newcommand{\innerhead}[1]{\def\lp@innerhead{#1}} % %----- Enclose text (#2) in ruled box of given thickness (#1) -\def\boxit#1#2{\vbox{\hrule height #1pt\hbox{\vrule width #1pt\hskip 5pt - \vbox{\vskip 5pt #2 \vskip 5pt}\hskip 5pt - \vrule width #1pt}\hrule height #1pt}} - +%\def\boxit#1#2{\vbox{\hrule height #1pt\hbox{\vrule width #1pt\hskip 5pt +% \vbox{\vskip 5pt #2 \vskip 5pt}\hskip 5pt +% \vrule width #1pt}\hrule height #1pt}} +% %----- Display boxed warning text (#1) -\def\warning#1{\bigskip - \setbox1=\vbox{\tolerance=5000\parfillskip=0pt - \hsize=3in\noindent#1} - \centerline{\boxit{1.0}{\box1}} - \bigskip} +%\def\warning#1{\bigskip +% \setbox1=\vbox{\tolerance=5000\parfillskip=0pt +% \hsize=3in\noindent#1} +% \centerline{\boxit{1.0}{\box1}} +% \bigskip} %----- Definitions to aid display of help text % (modelled on \item and \itemitem) -\def\helpindent#1{\setbox2=\hbox to\parindent{{\it #1}\hfil} - \indent\llap{\box2}\ignorespaces} -\def\helpitem{\parindent=70pt\par\hang\helpindent} -\def\helpitemitem{\parindent=70pt\par\indent \parindent=80pt -\hangindent2\parindent \helpindent} - +%\def\helpindent#1{\setbox2=\hbox to\parindent{{\it #1}\hfil} +% \indent\llap{\box2}\ignorespaces} +%\def\helpitem{\parindent=70pt\par\hang\helpindent} +%\def\helpitemitem{\parindent=70pt\par\indent \parindent=80pt +%\hangindent2\parindent \helpindent} +% %----- Tables and footnotes to tables % -\newcommand{\spacerA}{\rule{0mm}{4mm}} -\newcommand{\spacerB}{\rule[-2mm]{0mm}{5mm}} -\footnotesep=5mm -\renewcommand{\footnoterule}{{\small Notes:}} +%\newcommand{\spacerA}{\rule{0mm}{4mm}} +%\newcommand{\spacerB}{\rule[-2mm]{0mm}{5mm}} +%\footnotesep=5mm +%\renewcommand{\footnoterule}{{\small Notes:}} %% Robin 01AUG2008 %% -\newcounter{examplec} -\newcounter{definitionc} -\newcounter{summaryc} +%\newcounter{examplec} +%\newcounter{definitionc} +%\newcounter{summaryc} %\@addtoreset{examplec}{chapter}\renewcommand\theexamplec{\thechapter.arabic{examplec}} %\@addtoreset{definitionc}{chapter} diff --git a/sw_as_plds/sw_as_plds.tex b/sw_as_plds/sw_as_plds.tex index a1231b3..c2a6dfe 100644 --- a/sw_as_plds/sw_as_plds.tex +++ b/sw_as_plds/sw_as_plds.tex @@ -31,11 +31,19 @@ \ifthenelse {\boolean{paper}} { \begin{abstract} -This chapter describes how software can be represented by first order logic, and how +This chapter describes +the flow of data through a software system, +and how software elements be represented in a propositional logic diagram. +When we have the software in a common notation with electrical +and mechanical systems, we can apply analysis to complete +embedded systems. +in the same diagram When represented in this way they can be combined with other PLD's representing hardware and mechanical elements. Thus, Fault Mode Effects Analysis (FMEA) can be applied to electro/software/mechanical systems using a common mathematically based formal graphical notation. +Thus critical interfaces \cite{sec:interfaces} between sub-systems in different diciplines +can be modelled from a fault perspective. \end{abstract} } {} @@ -48,22 +56,36 @@ using a common mathematically based formal graphical notation. \section{Introduction} -The code in software defines logical euations and these determine the flow, or path software takes though the code. +The code in software defines logical equations and these determine the flow, or path software takes through the code. Because computer languages are very well defined, they can be viewed as formal languages. Becuase of this, they can be mapped onto propositional logic. Software can be viewed in terms of program flow stages. Transitioning between one stage and another depends on decisions made from variable states. This corresponds to the standard software structures, if-then-else - do-while etc. + do-while etc. At a program flow stage, the software may initiate actions. Typically, in an embedded system, a micro controller will read from external sensors, and then apply outputs to control the equipment under supervision. +More generally the flow of data follows a pattern of afferent, transform and efferent. + +\subsection{Afferent, Transform and Afferent Data Flow} + +Need a diagram showing data flow context. + +Then need a diagram showing the example. +Identified functions. +Inheriting the failure modes from the hardware they read. +And then the transform function above them perhaps resolving things. +Think this should be a pt100 and temp controller example. + +\subsection{Mapping the Data Flow into a PLD diagram} + Each test case in a PLD software diagram, corresponds to an action taken by the software. This action could be to modify an internal flag or variable, -or it could be modify an output that can actuate an action outside the micro-controller. +or it could be to modify an output that can actuate an action outside the micro-controller. A simple example illustrates this, a simple micro-controller program, that reads an IR detector and then displays status on a bank of LEDs. @@ -139,48 +161,48 @@ the main diagram. Note it should be possible to automatically generate diagrams from code. Analyse C code for instance and make these types of diagrams. - -\subsection{Afferent, processing and Efferent flow} - -A concept from Yourdon dataflow analysis, is that there -is Afferent, processing and Efferent flow. -That is to say information comes in (afferent flow) -is processed and the actions or data out, are the efferent flow. - -In a real time system, this corresponds to a hierarchy where -electrical and mechanical systems sit at either end with the -computer providing the processing. re-phrase. - -Need tree diagram here with MECH as lowest, electronics and then SW -as typical program structure. -{\huge DIAGRAM REQUIRED} - - - - -\section{General Placement of Software in an Embedded System} - -Sw acts as transfrom flow . Sensors (electronics ) are afferent flow. -Actuators are efferent flow. - -The s/w sits in the midlle. -The s/w can apply checking to and therefore naturally sits at the top of the hierarchy. - -Similarities with yourdon dataflow mwethod here -\clearpage - -%%\bibliography{vmgbibliography,mybib} % +%\subsection{Afferent, processing and Efferent flow} % -%Typeset in \ \ {\huge \LaTeX} \ \ on \ \ \today +%A concept from Yourdon dataflow analysis, is that there +%is Afferent, processing and Efferent flow. +%That is to say information comes in (afferent flow) +%is processed and the actions or data out, are the efferent flow. % -%\begin{verbatim} -%CVS Revision Identity $Id: sw_as_plds.tex,v 1.2 2008/11/04 07:40:50 robin Exp $ -%\end{verbatim} -%Compiled last \today -%\end{document} +%In a real time system, this corresponds to a hierarchy where +%electrical and mechanical systems sit at either end with the +%computer providing the processing. re-phrase. % -%\theend +%Need tree diagram here with MECH as lowest, electronics and then SW +%as typical program structure. +%{\huge DIAGRAM REQUIRED} % % % +% +%\section{General Placement of Software in an Embedded System} +% +%Sw acts as transfrom flow . Sensors (electronics ) are afferent flow. +%Actuators are efferent flow. +% +%The s/w sits in the midlle. +%The s/w can apply checking to and therefore naturally sits at the top of the hierarchy. +% +%Similarities with Yourdon dataflow method here +%\clearpage +% +%%%\bibliography{vmgbibliography,mybib} +%% +%% +%%Typeset in \ \ {\huge \LaTeX} \ \ on \ \ \today +%% +%%\begin{verbatim} +%%CVS Revision Identity $Id: sw_as_plds.tex,v 1.2 2008/11/04 07:40:50 robin Exp $ +%%\end{verbatim} +%%Compiled last \today +%%\end{document} +%% +%%\theend +%% +%% +%% diff --git a/symptom_ex_process/symptom_ex_process_paper.tex b/symptom_ex_process/symptom_ex_process_paper.tex deleted file mode 100644 index 8c6c68a..0000000 --- a/symptom_ex_process/symptom_ex_process_paper.tex +++ /dev/null @@ -1,719 +0,0 @@ - - -\ifthenelse {\boolean{paper}} -{ -\begin{abstract} -In failure mode analysis, it is essential to -know the failure modes of the sub-systems and components used. -This paper outlines a technique for determining the failure modes of a sub-system given -its components. - -This chapter describes a process for taking a functional group of components, applying FMEA analysis and then determining how that functional group can fail. -With this information, we can treat the functional group -as a component in its own right. -This new component is a derived component. -For a top down technique this would correspond to a low~level sub-system. -%The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint diagrams\cite{constraint} to model failure modes and failure mode common symptom collection. The technique is designed for making building blocks for a hierarchical fault model. - -Once the failure modes have been determined for a sub-system/derived~component, -this derived component can be combined with others to form functional groups -to model -higher level sub-systems/derived~components. -In this way a hierarchy to represent the fault behaviour -of a system can be built from the bottom~up. This process can continue -until there is a complete hierarchy representing the failure mode -behaviour of the entire system under analysis. -%FMMD hierarchy -Using the FMMD technique the hierarchy is built from the bottom up to ensure complete failure mode coverage. -Because the process is bottom-up, syntax checking and tracking can ensure that -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\cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets\cite{nucfta} are possible. -Also statistical reliability/probability of failure~on~demand\cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced -automatically, where component failure mode statistics are available\cite{mil1991}. -% -This paper focuses on the process of building the blocks, that are key to creating an FMMD hierarchy. - -\end{abstract} -} -{} - - -%\clearpage - -\section{Introduction} - -\subsection{Top Down or natural trouble shooting} -It is interesting here to look at the `natural' trouble shooting process. -Fault finding is intinctively performed from the top-down. -A faulty piece of equipment is examined and will have a -symptom or specific fault. The suspected area or sub-system within the -equipment will next be looked into. -The trouble shooter will look for behaviour that is unusual or incorrect -to determine the next area or sub~system to look into, each time -moving to a more detailed lower level. -Specific measurements -and checks will be made, and finally a component or a low level sub-system -will be found to be faulty. -A natural fault finding process is thus top~down. -\subsection{FMMD - Bottom~up Analysis} -The FMMD technique does not follow the `natural fault finding' or top down approach, -it instead works from the bottom up. -Starting with a collection of base~components that form -a simple functional group, the effect of all component error modes are -examined, as to their effect on the functional group. -The effects on the functional group can then be collected as common symptoms, -and now we may treat the functional group as a component as it has a known set of failure modes. -By reusing the `components' derived from functional~groups an entire -hierarichal failure mode mode of the system can be built. -By working from the bottom up, we can trace all possible sources -that could cause a particular mode of equipment failure. -This means that at the design stage of a product all component failure -modes must be considered. The aim here is for complete failure mode coverage. -This also means that we can obtain statistical estimates based on the known reliabilities -of the components. -%It also means that every component failure mode must at the very least be considered. - -\subsection{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\cite{sccs}. - -Static testing is also applied. This is theoretical analysis of the design of the product from the safety -perspective. -Three main techniques are currently 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. -From the model created by the FMMD technique, the three above failure mode -descriptions can be derived. - -{ -The aims are -\begin{itemize} - \item To automate the process where possible - \item To apply a documented trail for each analysis phase (determination of functional groups, and analysis of component failure modes on those groups) - \item To use a modular approach so that analysed sub-systems can be re-used - \item Automatically ensure no failure mode is unhandled - \item To produce a data model from which FTA, FMEA and statistical failure models may be obtained automatically -\end{itemize} -} - - -\subsection{Systems, functional groups, sub-systems and failure modes} - -It is helpful here to define some terms, `system', `functional~group', `component', `base~component' and `derived~component/sub-system'. -These are listed in table~\ref{tab:symexdef}. - -A System, is really any coherent entity that would be sold as a product. % 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\cite{nucfta} analyses a System -%and breaks it down. - -A sub-system will be composed of components, which -may themselves be sub-systems. However each `component' -will have a fault/failure behaviour and it should -always be possible to obtain a set of failure modes -for each `component'. In FMMD terms a sub-system is a derived component. - -If we look at the sound system example, -the CD~player could fail in several distinct ways, -and this couldbe due to a large number of -component failure modes. -%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 initial 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 illuminate 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. -We can define a functional~group as 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'. -We can now call our functional~group a sub-system or a derived~component. -The goal here is to know how it will behave under fault conditions ! -%Imagine buying one such `sub~system' from a very honest vendor. -%One of those sir, yes but be warned it may fail in these distinct ways, here -%in the honest data sheet the set of failure modes is listed! - - -%This type of thinking is starting to become more commonplace in product literature, with the emergence -%of reliability safety standards such as IOC1508\cite{sccs},EN61508\cite{en61508}. -%FIT (Failure in Time - expected number of failures per billion hours of operation) values -%are published for some micro-controllers. A micro~controller -%is a complex sub-system in its self and could be considered a `black~box' with a given reliability. -%\footnote{Microchip sources give an FIT of 4 for their PIC18 series micro~controllers\cite{microchip}, The DOD -%1991 reliability manual\cite{mil1991} applies a FIT of 100 for this generic type of component} - -Electrical components have detailed datasheets associated with them. A useful extension of this could -be failure modes of the component, with environmental factors and MTTF statistics. -Currently this sort of failure mode information is generally only available for generic component types\cite{mil1991}. - - -%At higher levels of analysis, functional~groups are pre-analysed sub-systems that interact to -%erform a given function. - -%\vspace{0.3cm} -\begin{table}[h] -\center -\begin{tabular}{||l|l||} \hline \hline - {\em Definition } & {\em Description} \\ \hline -System & A product designed to \\ - & work as a coherent entity \\ \hline -Sub-system & A part of a system, \\ --or- derived component & sub-systems may contain sub-systems. \\ - & derived~components may by derived \\ - & from derived components \\ \hline -Failure mode & A way in which a System, \\ - & Sub-system or component can fail \\ \hline -Functional Group & A collection of sub-systems and/or \\ - & components that interact to \\ - & perform a specific function \\ \hline -Base Component & Any bought in component, which \\ - & hopefully has a known set of failure modes \\ \hline - \hline -\end{tabular} -\caption{Symptom Extraction Definitions} -\label{tab:symexdef} -\end{table} -%\vspace{0.3cm} - - -\section{The Symptom abstraction Process} - -% TO DO: separate these two: - -\paragraph{Symptom Extraction Described} - -The objective of `symptom abstraction' is to analyse the functional~group and find -how it can fail -when specified components within it fail. -Once we know how functional~group can fail, we can treat it as a component or sub-system -with its own set of failure modes. - -\paragraph{FMEA applied to the Functional Group} -As the functional~group is a set of components, the failure~modes -that we have to consider are all the failure modes of its components. -Each failure mode (or combination of) investigated is termed a `test case'. -Each `test case' is analysed. -% -The component failure modes in each test case -are examined with respect to their effect on the functional~group. -% -The aim of this analysis is to find out how the functional~group reacts -to each of the test case conditions. -The goal of the process is to produce a set of failure modes from the perspective of the functional~group. - - - - -\paragraph{Symptom Identification} -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-system. -Single component failures (or combinations) within the functional~group may cause unique symptoms. -However, many failures, when looked at from the perspective of the functional group, will have the same symptoms. -These can be collected as `common symptoms'. -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$ ! - - - - -\paragraph{Collection of Symptoms} -The common symptoms of failure and lone~component failure~modes are identified and collected. -We can now consider the functional~group as a component and the common symptoms as its failure modes. -Note that here because the process is bottom up, we can ensure that all failure modes -associated with a functional~group have been handled. -Were failure~modes missed, any failure mode model could be dangerously incomplete. -It is possible here for an automated system to flag unhandled failure modes. -\ref{requirement at the start} - - -\section{The Process : To analyse a base level Derived~Component/sub-system} - -To sumarise: - -\begin{itemize} - \item Determine a minimal functional group - \item Obtain the list of components in the functional group - \item Collect the failure modes for each component -% \item Draw these as contours on a diagram -% \item Where si,ultaneous failures are examined use overlapping contours -% \item For each region on the diagram, make a test case - \item Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group - \item 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 {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider'). - \item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component. - \item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component. -\end{itemize} - - - - -\section{A general derived Component/Sub-System example} - -Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. - -$$ FG = \{ C_1 , C_2 , C_3 \} $$ - -Each component 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, defining a function $FM()$ -that is passed a component and returns the set of failure modes associated with it -\footnote{Base component failure modes are defined, often with -statistics and evironmental factors in a variety of sources. \cite{mil1991} -}. - -To re-cap from the definitions chapter \ref{chap:definitions}. - -Let the set of all possible components be $\mathcal{C}$ -and let the set of all possible failure modes be $\mathcal{F}$. - -We can define a function $FM$ - -\begin{equation} -FM : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} -\end{equation} - -defined by (where $C$ is a component and $F$ is a set of failure modes): - -$$ FM ( C ) = F $$ - -%\\ - -And for this example: - -$$ FM(C_1) = \{ a_1, a_2, a_3 \} $$ -$$ FM(C_2) = \{ b_1, b_2 \} $$ -$$ FM(C_3) = \{ c_1, c_2 \} $$ - - -\paragraph{Finding all failure modes within the functional group} - -For FMMD failure mode analysis, we need to consider the failure modes -from all the components in the functional group as a flat set. -This can be found by applying function $FM$ to all the components -in the functional~group and taking the union of them thus: - -$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} FM(C_j) $$ - -We can actually overload the notation for the function FM -and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: - -\begin{equation} -FM : FG \mapsto \mathcal{F} -\end{equation} - -Applied to the functional~group $FG$ in the example above: -\begin{equation} - FM(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \} -\end{equation} - -This can be seen as all the failure modes that can affect the failure mode group $FG$. - -\subsection{Analysis of the functional group failure modes} - -For this example we shall consider single failure modes. -%For each of the failure modes from $FM(FG)$ we shall -%create a test case ($fgfm_i$). Next each test case is examined/analysed -%and its effect on the functional group determined. - -\par -%\vspace{0.3cm} -\begin{table}[h] -\begin{tabular}{||c|c|c|c||} \hline \hline - {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\ - {\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline -% -$a\_1$ & $fs\_1$ & $fgfm_{1}$ & SP2 \\ \hline -$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline -$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline -$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline -$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline -$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\ \hline -$c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline -% - \hline -\end{tabular} -\caption{Component to functional group to failure symptoms example} -\label{tab:fexsymptoms} -\end{table} -%\vspace{0.3cm} - -Table~\ref{tab:fexsymptoms} shows the analysis process. -As we are only looking at single fault possibilities for this example each failure mode -is represented by a test~case. -The Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}. -The test cases are analysed w.r.t. the functional~group. -These become functional~group~failure~modes ($fgfm$'s). -The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. - -For the sake of example, let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ to be -identical from the perspective of the functional~group. -That is to say, the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes -occur, is going to be the same. -For example, in our CD player example, this could mean the common symptom `no\_sound'. -No matter which component failure modes, or combinations thereof cause the problem, -the failure symptom is the same. -It may be of interest to the manufacturers and designers of the CD player why it failed, but -as far as we the users are concerned, it has only one symptom, -`no\_sound'! -We can thus group these component failure modes into a common symptom, $SP1$, thus -$ SP1 = \{fgfm_2, fgfm_4, fgfm_5\}$. -% These can then be joined to form a spider. -Likewise -let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. -Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}. - - -We have now in $SP1$, $SP2$ and $fgfm_6$ as the three ways in which this functional~group can fail. -In other words we have derived failure modes for this functional~group. -We can place these in a set of symptoms, $SP$. -% -$$ SP = \{ SP1, SP2, fgfm_6 \} $$ -% -% -These three symptoms can be considered the set of failure modes for the functional~group, and -we can treat it as though it were a {\em black box} -or a {\em component} to be used in higher level designs. -% -The next stage of the process could be applied automatically. -Each common symptom becomes a failure mode of -a newly created derived component. Let $DC$ be the newly derived component. -This is assigned the failure modes that were derived from the functional~group. -We can thus apply the function $FM$ on this newly derived component thus: - -$$ FM(DC) = \{ SP1, SP2, fgfm_6 \} $$ - -Note that $fgfm_6$, while %being a failure mode has -not being grouped as a common symptom -has \textbf{not dissappeared from the analysis process}. -Were the designer to have overlooked this test case, it would appear in the derived component. -This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! -The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). - - -\subsection{Defining the analysis process as a function} - -It is useful to define this analysis process as a function. -Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now -write - -$$ -\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent -$$ -% -%\begin{equation} -% \bowtie(FG_{cfm}) = DC -%\end{equation} -% -%or applying the function $FM$ to obtain the $FG_{cfm}$ set -% -Where DC is a derived component, and FG is a functional group: - -\begin{equation} - \bowtie(FM(FG)) = DC -\end{equation} - - -%The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour. -%The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' symbol, as in figure \ref{fig:gensubsys4} - -% \begin{figure}[h+] -% \centering -% \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg} -% % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 -% \label{fig:gensubsys3} -% \caption{Deriving a new diagram} - - -This sub-system or derived~component $DC$ , with its three error modes, can now be treated as a component (although at a higher level of abstraction) -with known failure modes. -This process can be repeated using derived~components to build a -hierarchical -fault~mode -model. - - - - - -%\section{A Formal Algorithmic Description of `Symptom Abstraction'} -\section{Algorithmic Description} - -The algorithm for {\em symptom extraction} is described in -this section -%describes the symptom abstraction process -using set theory. - -The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$ -and converts it to a derived~component/sub-system $DC$. -%The sub-system $SS$ is a collection -%of failure~modes of the sub-system. -Note that -$DC$ is a derived component at a higher level of fault analysis abstraction, -than the functional~group it was derived from. -However, it can still be treated -as a component with a known set of failure modes. -\paragraph{Enumerating abstraction levels} -If $DC$ were to be included in a functional~group, -that functional~group must be considered to be at a higher level of -abstraction than a base level functional~group. -% -In fact, if the abstraction level is enumerated, -the functional~group must take the abstraction level -of the highest assigned to any of its components. -% -$DC$ can be used as a system building block at a higher -level of fault abstraction. Because the derived components -merge to form functional groups, a converging hierarchy is -naturally formed with the abstraction level increasing with each tier. - - -The algorithm, representing the function $\bowtie$, has been broken down into five stages, each following on from the other. -These are described using the Algorithm environment in the next section \ref{algorithms}. -By defining the process and describing it using set theory, constraints and -verification checks in the process can be stated formally. - -\clearpage -\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine} -%% -%% Algorithm 1 -%% - -\begin{algorithm}[h+] - ~\label{alg:sympabs1} -\caption{Determine failure modes: $FG \mapsto F$} \label{alg:sympabs11} -\begin{algorithmic}[1] -%\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. - - -%\STATE Determine functional groups $fg_n \subset S$ of components, where n is an index number and the number of functional groups found. - -\STATE { Let $FG$ be a set of components } \COMMENT{ The functional group should be chosen to be minimally sized collections of components that perform a specific function} -\STATE { Let $C$ represent a component} - -\ENSURE{ Each component $C \in FG $ has a known set of failure modes i.e. $FM(C) \neq \emptyset$ } - -\STATE {let $F=FM(FG)$ be a set of all failure modes to consider for the functional~group $FG$} - -%\STATE {Collect all failure modes from all the components in FG into the set $FG_{cfm}$} -%\FORALL { $c \in FG $ } -%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$} -%\ENDFOR - -%\hline -Algorthim \ref{alg:sympabs11} has taken a functional~group $FG$ and returned a set of failure~modes $F=FM(FG)$ where each component has a known set of failure~modes. -The next task is to formulate `test cases'. These are the combinations of failure~modes that will be used -in the analysis stages. - - -\end{algorithmic} -\end{algorithm} - -\clearpage -\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases} -%% -%% Algorithm 2 -%% - - -\begin{algorithm}[h+] - ~\label{alg:sympabs2} -\caption{Determine Test Cases: $F \mapsto TC $} \label{alg:sympabs22} -\begin{algorithmic}[1] - - \REQUIRE {Determine the test cases to be applied} - - \STATE { All test cases are now chosen by the investigating engineer(s). Typically all single - component failures are investigated - with some specially selected combination faults} - - \STATE { Let $TC$ be a set of test cases } - \STATE { Let $tc_j$ be set of component failure modes where $j$ is an index of $J$} - \COMMENT { Each set $tc_j$ is a `test case' } - \STATE { $ \forall j \in J | tc_j \in TC $ } - - %\STATE { $ \bigcup_{j=1...N} tc_j = \bigcup TC $ } - %\COMMENT { All $tc_j$ test cases sets belong to $TC$ } - - %\REQUIRE { $ TC \subset \bigcup (FM_{cfm}) $ } - %\COMMENT { $TC$ is the set of all test_cases -% Let TC be a subset of the powerset of the failure modes $ FG_{cfm} $, -%i.e. only failure modes present in $ FG_{cfm} $ are present in sets belonging to $ TC $} - - - \COMMENT { Ensure the test cases are complete and unique } - - \FORALL { $tc_j \in TC$ } - %\ENSURE {$ tc_j \in \bigcap FG_{cfm} $} - \ENSURE {$ tc_j \in \mathcal{P}(F))$} - \COMMENT { require that the test case is a member of the powerset of $F$ } - \ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $} - \COMMENT { Test cases must be unique } - \ENDFOR - - - - \STATE { let $f$ represet a component failure mode } - \REQUIRE { That all failure modes are represented in at least one test case } - \ENSURE { $ \forall f | (f \in F)) \wedge (f \in \bigcup TC) $ } - \COMMENT { This corresponds to checking that at least each failure mode is considered at least once in the analysis; some european standards -imply checking all double fault combinations\cite{en298} } - -%\hline -Algorithm \ref{alg:sympabs22} has taken the set of failure modes $ F=FM(FG) $ and returned a set of test cases $TC$. -The next stages is to analyse the effect of each test case on the functional group. - -\end{algorithmic} -\end{algorithm} - -\clearpage -\subsection{Algorithmic Description of Symptom Abstraction \\ Analyse Test Cases} -%% -%% Algorithm 3 -%% - -\begin{algorithm}[h+] - ~\label{alg:sympabs3} -\caption{Analyse Test Cases: $ TC \mapsto R $} \label{alg:sympabs33} -\begin{algorithmic}[1] - \STATE { let r be a `test case result'} - \STATE { Let the function $Analyse : tc \mapsto r $ } \COMMENT { This analysis is a human activity, examining the failure~modes in the test case and determining how the functional~group will fail under those conditions} - \STATE { $ R $ is a set of test case results $r_j \in R$ where the index $j$ corresponds to $tc_j \in TC$} - \FORALL { $tc_j \in TC$ } - \STATE { $ rc_j = Analyse(tc_j) $} \COMMENT {this is Fault Mode Effects Analysis (FMEA) applied in the context of the functional group} - \STATE { $ rc_j \in R $ } - \ENDFOR - -%\hline -Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case. -\end{algorithmic} -\end{algorithm} - - -\clearpage -\subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms} -%% -%% Algorithm 4 -%% - -\begin{algorithm}[h+] - ~\label{alg:sympabs4} - -\caption{Find Common Symptoms: $ R \mapsto SP $} \label{alg:sympabs44} - -\begin{algorithmic}[1] - - - %\REQUIRE {All failure modes for the components in $fm_i = FM(fg_i)$} - \STATE {Let $sp_l$ be a set of `test cases results' where $l$ is an index set $L$} - \STATE {Let $SP$ be a set whose members are sets $sp_l$} - \COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system} -% - %\COMMENT{This corresponds to a fault symptom of the functional group $FG$} - %\COMMENT{where double failure modes are required the cardinality constrained powerset of two must be applied to each failure mode} - - \FORALL { $ r_j \in R$ } - \STATE { $sp_l \in \mathcal{P} R \wedge sp_l \in SP$ } - %\STATE { $sp_l \in \bigcap R \wedge sp_l \in SP$ } - \COMMENT{ Collect common symptoms. - Analyse the sub-system's fault behaviour under the failure modes in $tc_j$ and determine the symptoms $sp_l$ that it -causes in the functional group $FG$} - %\ENSURE { $ \forall l2 \in L ( \forall l1 \in L | \exists a \in sp_{l1} \neq \exists b \in sp_{l2} \wedge l1 \neq l2 ) $} - - \ENSURE {$ \forall a \in sp_l | \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$} - - \COMMENT { Ensure that the elements in each $sp_l$ are not present in any other $sp_l$ set } - - \ENDFOR - \STATE { The Set $SP$ can now be considered to be the set of fault modes for the sub-system that $FG$ represents} - -%\hline -Algorithm \ref{alg:sympabs44} raises the failure~mode abstraction level. -The failures have now been considered not from the component level, but from the sub-system or -functional~group level. -We now have a set $SP$ of the symptoms of failure. - -\end{algorithmic} -\end{algorithm} - -\clearpage -\subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component} -%% -%% Algorithm 5 -%% - -\begin{algorithm}[h+] - ~\label{alg:sympabs5} - -\caption{Treat the symptoms as failure modes of the Derived~Component/Sub-System: $ SP \mapsto DC $} \label{alg:sympabs55} - -\begin{algorithmic}[1] - - \STATE { Let $DC$ be a derived component with failure modes $f$ indexed by $l$ } - \FORALL { $sp_l \in SP$ } - \STATE { $ f_l = ConvertToFaultMode(sp_l) $} - \STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes} - \ENDFOR -%\hline - -Algorithm \ref{alg:sympabs55} is the final stage in the process. We now have a -derived~component $DC$, which has its own set of failure~modes. This can now be -used in conjection with other components (or derived~components) -to form functional~groups at a higher level of failure~mode~abstraction. -Hierarchies of fault abstraction can be built that can model an entire SYSTEM. -\end{algorithmic} -\end{algorithm} - - -\section{To conclude} - -The technique provides a methodology for bottom-up analysis of the fault behaviour of complex safety critical systems. - -\subsection{Hierarchical Simplification} - -Because symptom abstraction collects fault modes, the number of faults to handle decreases -as the hierarchy progresses upwards. -This is seen by casual observation of real life Systems. At the highest levels the number of faults -is significantly less than the sum of its component failure modes. -A Sound system might have, for instance only four faults at its highest or System level, -\small -$$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT\}$$ -\normalsize -The number of causes for any of these faults is very large. -It does not matter to the user, which combination of causes caused the fault. -But as the hierarchy goes up in abstraction level, the number of faults goes down. - -\subsection{Tracable Fault Modes} - -Because the fault modes are determined from the bottom-up, the causes -for all high level faults naturally form trees. -Minimal cut sets \cite{nasafta} can be determined from these, and by -analysing the statistical likelyhood of the component failures, -the MTTF and SIL\cite{en61508} levels can be automatically calculated. - diff --git a/thesis.tex b/thesis.tex index 4147015..d76c557 100644 --- a/thesis.tex +++ b/thesis.tex @@ -53,9 +53,6 @@ \chapter{Thesis Scope} \input{introduction/introduction} -\chapter{An overview of European and North Americans Standards} -\input{standards/standards} - \chapter{Statistical Methods and Models} \input{statistics/statistics} @@ -63,6 +60,8 @@ \input{survey/survey} +\chapter{An overview of European and North Americans Standards} +\input{standards/standards} \typeout{ ---------------- Component Failure Modes Definition } \chapter { Component Failure Modes Definition}