robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

worked on fmmdset

Browse Source
This commit is contained in:
Robin 2010-05-30 14:35:09 +01:00
parent 8bb26ba758
commit 23092c9e75
4 changed files with 268 additions and 180 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
component_failure_modes_definition/component_failure_modes_definition.tex
View File

@ -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.

374
fmmdset/fmmdset.tex
View File

@ -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 }

BIN
fmmdset/onestage.dia Normal file
View File

Binary file not shown.

BIN
fmmdset/onestage.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.6 KiB