worked on fmmdset

component_failure_modes_definition/component_failure_modes_definition.tex

@@ -300,6 +300,80 @@ we have banned larger combinations as well.
 
 
 
+\section{Handling Simultaneous Component Faults}
+
+\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]  $$
+
+
 \section{Component Failure Modes and Statistical Sample Space}
 %\paragraph{NOT WRITTEN YET PLEASE IGNORE}
 A sample space is defined as the set of all possible outcomes.

fmmdset/fmmdset.tex

@@ -1,12 +1,5 @@
-
-
-
 % $Id: fmmdset.tex,v 1.7 2009/06/06 11:52:09 robin Exp $
 
-
-
-
-
 %\newtheorem{theorem}{Thoeorem}
 % 
 % \def\lastname{Clark}
@@ -50,7 +43,8 @@ are faults which may occur but are not self~detected, or are impossible to detec
 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
-simultaneous faults which complicates the scenario based approvals that are currently used.
+simultaneous faults which complicates the scenario based approvals that are 
+currently used\footnote{Standard EN298 stronlgy 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}.
@@ -97,20 +91,14 @@ and dangerous~faults can be determined from traversing the fault tree down to th
 
 \subsection{Basic Concepts Of FMMD}
 
-\subsubsection { What is a part ? }
+\subsubsection { Definitions }
 
-A Part here means a lowest level component, an entity which can be bought and 
+\begin{list}
-hopefully has some statisics for MTTF and known failure modes.
+\item base component - a component with a known set of unitary state failure modes 
-Where manufacturers MTTF data is non-existant (or unverified) a guide such as MIL1992\cite{MIL1992} may be used.
+\item functional group -  a collection of components chosen to perform a particular task
-Parts for approved safety critical systems under formal observance~\cite{FMproduction} 
+\item derived failure mode - a failure symptom of a functional group
-will be documented in a parts list. The `parts list' is a formal document for 
+\item derived component - a functional group after analysis
-both design and quality assured production.
+\end{list}
-A parts list will typically include
-the manufacturers part number, guidance for placement in the system, 
-a functional description, vendor parts numbers
-and a description. A resistor, capacitor or a microcontroller would be typical of a `part'.
-A part will normally have a set of failure~modes, or ways in which it can fail. Thus a set of failure~modes
-is associated with each part. 
 
 \subsubsection{ Creating a fault hierarchy}
 
@@ -118,28 +106,45 @@ The main idea of the methodology is to build a hierarchy of fault modes from the
 level up to highest system levels. 
 
 The first stage is to choose
-parts that interact and naturally form {\em functional groups}. {Functional groups} are thus collections of parts.
+parts that interact and naturally form {\em functional groups}. {Functional groups} are thus collections of base parts.
 %These parts all have associated fault modes. A module is a set fault~modes. 
 
 From the point of view of fault analysis, we are not interested in the parts themselves, but in the ways in which they can fail.
 
-For this study a Module will mean a collection of fault modes.
+For this study a functional group will mean a collection of components.
-For a module formed from a {\em functional group} this will be the collection of all fault modes of its parts.
+In order to determine the symptoms or failure modes of a {\em functional group}
-By analysing the fault behaviour of a `module' with respect to all the fault~modes, 
+we need to consider all failure modes of its parts.
-we can derive a new set of possible fault~modes at the module level. 
+By analysing the fault behaviour of a `functional group' with respect these failure modes
+we can derive a new set of possible failure modes.
+%
 This new set of faults is the set of derived faults from the module level and is thus at a higher level of 
 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 module. What this means is the `fault~symptoms' of the module have been derived.
+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.
+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.
+%
 %When we have determined the fault~modes at the module level these can become a set of derived faults.
-By taking sets of derived faults (module level faults) we can combine these to form modules
+%By taking sets of derived faults (module level faults) we can combine these to form modules
-at a higher level of fault abstraction. An entire hierarchy of fault modes can now be built in this way,
+%at a higher level of fault abstraction. An entire hierarchy of fault modes can now be built in this way,
-to represent the fault behaviour of the entire system. This can be seen as using the modules we have analysed
+%to represent the fault behaviour of the entire system. This can be seen as using the modules we have analysed
-as parts, parts which may now be combined to create new functional groups, 
+%as parts, parts which may now be combined to create new functional groups, 
-but as parts at a higher level of fault abstraction. 
+%but as parts at a higher level of fault abstraction. 
+Applying the same process with derived components we can bring derived components
+together to form functional groups and create new derived components
+at a higher abstraction level.
+
+
+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
+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$.
 
 
 
@@ -149,156 +154,34 @@ but as parts at a higher level of fault abstraction.
 %This leads to a set of fault modes for each module, the derived fault~modes $D$.
 %These derived fault modes may now be used at a higher abstraction level.
 %A hierarchy can be built, with each level representing a higher level of fault abstraction.
-
+%
-%Each part may fail in a number of ways.  
+%%Each part may fail in a number of ways.  
-We can take the levels of abstraction and view them as a hierarchy, with part level faults at the bottom.
+%We can take the levels of abstraction and view them as a hierarchy, with part level faults at the bottom.
-Each time we analyse a set of fault modes, with respect to how they interact,
+%Each time we analyse a set of fault modes, with respect to how they interact,
-we get a new set of faults a higher level of fault abstraction.
+%we get a new set of faults a higher level of fault abstraction.
-At the lowest level of fault~mode abstraction is the
+%At the lowest level of fault~mode abstraction is the
-part failure modes. This is the hierarchy abstraction level zero. Functional~groups, collections of parts are also at
+%part failure modes. This is the hierarchy abstraction level zero. Functional~groups, collections of parts are also at
-abstraction level 0. Combining derived fault modes from functional groups to form {\em modules}, will
+%abstraction level 0. Combining derived fault modes from functional groups to form {\em modules}, will
-also be at level 0. 
+%also be at level 0. 
-%By deriving the fault modes for a particular module.
+%%By deriving the fault modes for a particular module.
-A set of faults derived from a `module' will be at abstraction level 1.
+%A set of faults derived from a `module' will be at abstraction level 1.
-Thus the module, a collection of parts is analysed, and the fault symtopms of that module derived.
+%Thus the module, a collection of parts is analysed, and the fault symtopms of that module derived.
-The act of analysing and deriving new faults raises the abstraction level.
+%The act of analysing and deriving new faults raises the abstraction level.
-
+%
-
+%
-Simple parts may have
+%Simple parts may have
-a single failure mode, and more  complex ones may have hundreds.
+%a single failure mode, and more  complex ones may have hundreds.
-% Hazel 11FEB2008 said this was difficult to read
+%% Hazel 11FEB2008 said this was difficult to read
-%It can be easily seen that trying to judge the effect of a single part mode failure against
+%%It can be easily seen that trying to judge the effect of a single part mode failure against
-%all other parts failure modes in the system would be a thankless and practically impossible task.
+%%all other parts failure modes in the system would be a thankless and practically impossible task.
-Were we to analyse the effect of each part failure mode against all other parts in the circuit,
+%Were we to analyse the effect of each part failure mode against all other parts in the circuit,
-we could be facing a very large task.
+%we could be facing a very large task.
-Modularisation allows detailed (part fault mode level) analysis of well defined functional groups within a system.
+%Modularisation allows detailed (part fault mode level) analysis of well defined functional groups within a system.
-The hierarchy allows the combining of these modules to form meaningful fault represention of the system.
+%The hierarchy allows the combining of these modules to form meaningful fault represention of the system.
-
+%
 
 An example of a simple system will illustrate this.
 
-\subsection{Example FMMD Hierarchy}
-
-
-%%% This is the tikz picture ??/
-%
-%\begin{figure}[h+]
-%\centering
-%\input{fmmdset/mvsblock.tex}
-%\caption{Block Diagram : Example  Milli-Volt Sensor : Block Diagram}
-%%\includegraphics[scale=0.20]{ptop.eps}
-%\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
-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.
-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
-via the RS232 serial line.
-
-% 
-% \begin{figure}[h+]
-% %\centering
-% %\input{millivolt_sensor.tex}
-% \includegraphics[scale=0.4]{fmmdset/millivolt_sensor.eps}
-% \caption{Hierarchical Module Diagram : Milli-Volt Sensor Example}
-% \label{fig:mvs}
-% \end{figure}
-
-\begin{figure}[h]
- \centering
- \includegraphics[width=400pt,bb=0 0 749 507,keepaspectratio=true]{fmmdset/millivolt_sensor.png}
- % millivolt_sensor.png: 749x507 pixel, 72dpi, 26.42x17.89 cm, bb=0 0 749 507
- \caption{Hierarchial Module Diagram : Millivolt Sensor Example}
- \label{fig:mvs}
-\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).
-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.
-When these have been examined and diagnostic safeguard strategies have been thought up,
-we might look at reporting any fault via the RS232 link.
-% (if it still works !).
-
-By doing this we have already used a modular approach. 
-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.
-   
-%The FMMD technique, 
-%goes further than this by considering all part fault~modes and 
-%places the analysis phases into a rigid structure. 
-%Each analysis phase is
-%described using set theory in later sections. 
-%By creating a rigid hierarchy, not only can we traverse back
-%down it to find possible causes for system errors, we can also determine 
-%combinations of fault modes that cause certain high level fault modes.
-%For instance, it may be a criteria that no single part failure may cause a fatal error.
-%If a fault tree can trace down to a single part fault for a potentially fatal 
-%fault mode, then a re-design must be undertaken.
-%Some standards for automated burner controllers demand that two part failure modes cannot cause 
-%a dangerous/potentially fatal error. Again having a complete fault analysis tree will reveal these conditions.
-
-
-\subsection{An example part Fault and its subsequent \\ abstraction to system or top level}
-
-An example of a part fault effect on the example system is given below, showing how this fault 
-manifests itself at each abstraction level.
-
-%\begin{example}
-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. 
-%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.
-Any voltage outside this range will be considered erroneous.
-As the resistor short causes the amplifier to output 5V we can detect the error condition.
-This resistor is a part in the `millivolt amplifier 1' module.
-% (see figure \ref{fig:mvs}).
-The fault mode at the derived fault  level (abstraction level 1) is OUTPUT\_HIGH.
-Looking higher in the hierarchy, the next abstraction level higher, level 2, will see this as
-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}
-
-\subsubsection{Abstraction Layer Summary \\ for example fault.}
-\begin{description}
-%\begin{list}
-\item[Abstraction Level 0 :] Resistor has fault mode `R48\_SHORT' in amplifier 1.
-\item[Abstraction Level 1 :] Amplifier 1 has fault mode `OUTPUT\_HIGH'.
-\item[Abstraction Level 2 :] Milli-volt sensor has `CHANNEL\_1' fault.
-%\item[Abstraction Level 3 :] System has `MILLI\_VOLT\_SENSOR' fault.
-%\end{itemize}
-%\end{list}
-\end{description}
-
-
-
-
-
-Thus we have looked at a single part fault and analysed its effect from the
-bottom up on the system as a whole, going up through the abstraction layers.
-
 \subsubsection{Fault Abstraction Level}
 \label{fal}
 Let the fault abstraction level mean the number of times an element of a system
@@ -918,6 +801,137 @@ $$ \#\mathcal{P}_{cc} S = {\sum^{k}_{1..cc}  \frac{\#S!}{k!(\#S-k)!}}  - {\sum^{
 %$$ \#\mathcal{P}_{cc} S = \sum^{k}_{1..cc}  \big[ \frac{\#S!}{k!(\#S-k)!}  - \sum_{j} (\#C_{j} \choose cc \big]  $$
 
 
+
+
+%% CASE STUDY BEGIN
+
+\subsection{Case Study FMMD Hierarchy:\\ Simple RS-232 voltage reader}
+
+
+%%% This is the tikz picture ??/
+%
+%\begin{figure}[h+]
+%\centering
+%\input{fmmdset/mvsblock.tex}
+%\caption{Block Diagram : Example  Milli-Volt Sensor : Block Diagram}
+%%\includegraphics[scale=0.20]{ptop.eps}
+%\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
+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.
+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
+via the RS232 serial line.
+
+% 
+% \begin{figure}[h+]
+% %\centering
+% %\input{millivolt_sensor.tex}
+% \includegraphics[scale=0.4]{fmmdset/millivolt_sensor.eps}
+% \caption{Hierarchical Module Diagram : Milli-Volt Sensor Example}
+% \label{fig:mvs}
+% \end{figure}
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=400pt,bb=0 0 749 507,keepaspectratio=true]{fmmdset/millivolt_sensor.png}
+ % millivolt_sensor.png: 749x507 pixel, 72dpi, 26.42x17.89 cm, bb=0 0 749 507
+ \caption{Hierarchial Module Diagram : Millivolt Sensor Example}
+ \label{fig:mvs}
+\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).
+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.
+When these have been examined and diagnostic safeguard strategies have been thought up,
+we might look at reporting any fault via the RS232 link.
+% (if it still works !).
+
+By doing this we have already used a modular approach. 
+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.
+   
+%The FMMD technique, 
+%goes further than this by considering all part fault~modes and 
+%places the analysis phases into a rigid structure. 
+%Each analysis phase is
+%described using set theory in later sections. 
+%By creating a rigid hierarchy, not only can we traverse back
+%down it to find possible causes for system errors, we can also determine 
+%combinations of fault modes that cause certain high level fault modes.
+%For instance, it may be a criteria that no single part failure may cause a fatal error.
+%If a fault tree can trace down to a single part fault for a potentially fatal 
+%fault mode, then a re-design must be undertaken.
+%Some standards for automated burner controllers demand that two part failure modes cannot cause 
+%a dangerous/potentially fatal error. Again having a complete fault analysis tree will reveal these conditions.
+
+
+\subsection{An example part Fault and its subsequent \\ abstraction to system or top level}
+
+An example of a part fault effect on the example system is given below, showing how this fault 
+manifests itself at each abstraction level.
+
+%\begin{example}
+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. 
+%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.
+Any voltage outside this range will be considered erroneous.
+As the resistor short causes the amplifier to output 5V we can detect the error condition.
+This resistor is a part in the `millivolt amplifier 1' module.
+% (see figure \ref{fig:mvs}).
+The fault mode at the derived fault  level (abstraction level 1) is OUTPUT\_HIGH.
+Looking higher in the hierarchy, the next abstraction level higher, level 2, will see this as
+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}
+
+\subsubsection{Abstraction Layer Summary \\ for example fault.}
+\begin{description}
+%\begin{list}
+\item[Abstraction Level 0 :] Resistor has fault mode `R48\_SHORT' in amplifier 1.
+\item[Abstraction Level 1 :] Amplifier 1 has fault mode `OUTPUT\_HIGH'.
+\item[Abstraction Level 2 :] Milli-volt sensor has `CHANNEL\_1' fault.
+%\item[Abstraction Level 3 :] System has `MILLI\_VOLT\_SENSOR' fault.
+%\end{itemize}
+%\end{list}
+\end{description}
+
+
+
+
+
+Thus we have looked at a single part fault and analysed its effect from the
+bottom up on the system as a whole, going up through the abstraction layers.
+
+%%
+%% END CASE STUDY
+%%
+
+
 \section{Future Ideas}
 
 \subsection{ Production Quality Control }