diff --git a/component_failure_modes_definition/component_failure_modes_definition.tex b/component_failure_modes_definition/component_failure_modes_definition.tex index d7f9592..189b9e4 100644 --- a/component_failure_modes_definition/component_failure_modes_definition.tex +++ b/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. diff --git a/fmmdset/fmmdset.tex b/fmmdset/fmmdset.tex index 5455299..567b865 100644 --- a/fmmdset/fmmdset.tex +++ b/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 -hopefully has some statisics for MTTF and known failure modes. -Where manufacturers MTTF data is non-existant (or unverified) a guide such as MIL1992\cite{MIL1992} may be used. -Parts for approved safety critical systems under formal observance~\cite{FMproduction} -will be documented in a parts list. The `parts list' is a formal document for -both design and quality assured production. -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. +\begin{list} +\item base component - a component with a known set of unitary state failure modes +\item functional group - a collection of components chosen to perform a particular task +\item derived failure mode - a failure symptom of a functional group +\item derived component - a functional group after analysis +\end{list} \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 a module formed from a {\em functional group} this will be the collection of all fault modes of its parts. -By analysing the fault behaviour of a `module' with respect to all the fault~modes, -we can derive a new set of possible fault~modes at the module level. +For this study a functional group will mean a collection of components. +In order to determine the symptoms or failure modes of a {\em functional group} +we need to consider all failure modes of its parts. +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 -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 -as parts, parts which may now be combined to create new functional groups, -but as parts at a higher level of fault abstraction. +%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, +%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, +%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. -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, -we get a new set of faults a higher level of fault abstraction. -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 -abstraction level 0. Combining derived fault modes from functional groups to form {\em modules}, will -also be at level 0. -%By deriving the fault modes for a particular module. -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. -The act of analysing and deriving new faults raises the abstraction level. - - -Simple parts may have -a single failure mode, and more complex ones may have hundreds. -% 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 -%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, -we could be facing a very large task. -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. - +% +%%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. +%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. +%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 +%abstraction level 0. Combining derived fault modes from functional groups to form {\em modules}, will +%also be at level 0. +%%By deriving the fault modes for a particular module. +%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. +%The act of analysing and deriving new faults raises the abstraction level. +% +% +%Simple parts may have +%a single failure mode, and more complex ones may have hundreds. +%% 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 +%%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, +%we could be facing a very large task. +%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. +% 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 } diff --git a/fmmdset/onestage.dia b/fmmdset/onestage.dia new file mode 100644 index 0000000..a4ac1bc Binary files /dev/null and b/fmmdset/onestage.dia differ diff --git a/fmmdset/onestage.jpg b/fmmdset/onestage.jpg new file mode 100644 index 0000000..75ca005 Binary files /dev/null and b/fmmdset/onestage.jpg differ