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

morning edit

Browse Source
This commit is contained in:
Robin Clark 2011-02-01 08:04:55 +00:00
parent c315a69229
commit aa2eb54ce0
2 changed files with 68 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

92
fmmdset/fmmdset.tex
View File

@ -32,10 +32,10 @@ EN298, EN61508, EN12067, EN230, UL1998.
{
This chapter describes the Failure Mode Modular De-Composition (FMMD)
methodology to analyse
safety critcal designs from a failure mode perspective, with emphasis on building the hierarchical model..
safety critcal designs from a failure mode perspective, with emphasis on building a hierarchical models, in an incremental and modular fashiion.
%Failure Mode Modular De-Composition (FMMD)
FMMD provides
a rigorous method for creating a fault effects model of a system from the bottom up using {\bc} level fault modes.
a rigorous method for creating a fault effects model of a system from the bottom up starting with {\bc} level fault modes.
Using symptom extraction, and taking {\fgs} of components, a fault behaviour
hierarchy is built, forming a fault model tree.
From the fault model trees,
@ -45,7 +45,7 @@ It provides the means to trace the causes of dangerous detected and dangerous un
It provides the means to produce Minimal cut-sets, FTA diagrams and FMEDA models, from
a data model built by the FMMD methodology.
It has a common notation spanning mechanical, electrical and software failures,
and incorporating them into system models. It has been designed for small safety critical embedded
and can integrate all three into the same system models. It has been designed for small safety critical embedded
systems, but because of its modular and hierarchical nature, can be used to model larger systems.
It is intended to be used to formally prove systems to meet EN and UL standards, including and not limited to
EN298, EN61508, EN12067, EN230, UL1998.
@ -62,7 +62,7 @@ the assessment of safety critical designs, aiding in identifying detected and un
\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 beginning to be specified in some safety standards.\footnote{Formal methods
such as the Z notation appear as `highly recommended' techniques in the EN61508 standard\cite{en61508}, but
apply only to software currently.} However, some standards are now implying the handling of
apply only to software currently. Semi formal methods such as FMEDA are recomended for electronics.} However, some standards are now implying the handling of
simultaneous faults which complicates the scenario based approvals that are
currently used\footnote{Standard EN298:2003 demands that double simultaneous failures must be handled, in the case of
a single dangerous fault being detected.}.
@ -82,6 +82,8 @@ The second is to specify
that any single or double part faults cannot lead to a dangerous fault in the system under consideration.
This entails tracing the effects of all part failure modes
and working out if they can lead to any dangerous faults in the system under consideration.
This is the deterministic approach, and looks for casual links from the {\bc} failure modes
to SYSTEM failures.
%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} .
@ -115,19 +117,20 @@ FMMD has a common notation for modelling mechanical, electronic and software des
\paragraph{ Creating a fault hierarchy}
The main idea of the methodology is to build a hierarchy of fault modes from the part
level up to highest system levels.
The main idea of the methodology is to build a hierarchy of fault modes from the {\bc}
level up to the top, or SYSTEM.
The first stage is to choose
components that interact and naturally form {\fgs}. The initial {\fgs} are thus collections of base parts.
{\bcs} that interact and naturally form {\fgs}. The initial {\fgs} 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 components themselves, but in the ways in which they can fail.
For this study a {\fg} will mean a collection of components.
In order to determine the symptoms or failure modes of a {\fg},
we need to consider all failure modes of its components.
By analysing the fault behaviour of a `{\fg}' with respect these failure modes
we can derive a new set of possible failure modes.
By analysing the fault behaviour of a `{\fg}' with respect these component failure modes
we can derive a new set of possible failure modes. In fact we can caal these
the symptoms of failure for the {\fg}.
%
This new set of faults is the set of derived faults from the perspective of the {\fg}, and is thus at a higher level of
fault~mode abstraction. Thus we can say that the {\fg} as an entity, can fail in a number of well defined ways.
@ -138,8 +141,7 @@ These new failure~modes are derived failure modes.
%being derived from the {\fg}.
We can now create a new `{\dc}' which has
the failure symptoms of the {\fg} as its set of failure modes.
This new {\dc} is at a higher failure mode abstraction
level than the {\bcs}.
This new {\dc} is at a higher `failure~mode~abstraction~level' than {\bcs}.
%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.
@ -156,21 +158,21 @@ at a higher abstraction level.
Reference the symptom abstraction paper here
}
{
This analysis and symptom collection process is described in detail in the Symptom extraction (see chapter \ref{symptomex}).
This analysis and symptom collection process is described in detail in the Symptom extraction chapter (see section \ref{symptomex}).
}
\subsubsection { Definitions }
\begin{itemize}
\item {\bc} - a component with a known set of unitary state failure modes
\item {\bc} - a component with a known set of unitary state failure modes. Base here mean a starting or `bought~in' component.
\item {\fg} - a collection of components chosen to perform a particular task
\item {\em derived failure mode} - a failure symptom of a functional group
\item {\dc} - a new component derived from an analysed {\fg}
\end{itemize}
\subsubsection{An algebraic notation for identifying FMMD enitities}
Each component $C$ holds a set of failure modes for the component.
Each component $C$ has an associated set of failure modes for the component.
We can define a function $fm$ that returns the
set of failure modes $F$ for the component $C$.
@ -193,7 +195,17 @@ of a {\fg}.
We can overload the $fm$ function for a functional group $FG$
where it will return all the failure modes of the components in $FG$
$$ fm (FG) = F $$
given by
$$ fm (FG) = F. $$
And formally, where $\mathcal{FG}$ is the set of all functional groups,
\begin{equation}
fm : \mathcal{FG} \rightarrow \mathcal{P}\mathcal{F}.
\end{equation}
%$$ \mathcal{fm}(C) \rightarrow S $$
%$$ {fm}(C) \rightarrow S $$
@ -215,12 +227,16 @@ We can apply symptom abstraction to a {\fg} to find
a set of derived failure modes. We are interested in the failure modes
of all the components in the {\fg}. An analysis process
defined by the symbol `$\bowtie$' is applied to the {\fg}.
The $\bowtie$ analysis, or symptom extraction process, is described in chapter \ref{chap:sympex}.
Using $\alpha$ to symbolise the fault abstraction level, we can state:
$$ \bowtie(FG^{\alpha}) \rightarrow C^{{\alpha}+1} $$
iThe $\bowtie$ function takes a {\fg}
as an argument and returns a newly cretaed {\dc}.
The $\bowtie$ function processes each member (component) of the set $FG$ and
The $\bowtie$ analysis, a symptom extraction process, is described in chapter \ref{chap:sympex}.
Using $\alpha$ to symbolise the fault abstraction level, we can now state:
$$ \bowtie(FG^{\alpha}) \rightarrow C^{{\alpha}+1}. $$
\paragraph{The symptom abstraction process in outline.} 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 {\dc} is created
where its failure modes are the symptoms from $FG$.
@ -234,7 +250,7 @@ levels, we can converge to a complete failure mode model of the system under ana
An example of a simple system will illustrate this.
\subsection {Example FMEA process using an FMEA diagram}
\subsection {Theoretical Example Symptom Abstraction Process }
Consider a simple {\fg} $ FG^0_1 $ comprising of two base components $C^0_1,C^0_2$.
@ -308,26 +324,26 @@ as the failure modes raise in abstraction level.
\end{figure}
\section {Building the Hierarchy - Higher levels \\ of Fault Mode Analysis}
\section {Building the Hierarchy - Higher levels of Fault Mode Analysis}
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 $C^{1}_{{N}}$ {\dcs} to form {\fgs}. These
$FG^2_{N}$ {\fgs} can be used to create $C^3_{{N}}$ {\dcs} and so on.
We can take this hierarchy one stage further by combining the abstraction level 1 components (i.e. like $C^{1}_{{N}}$) to form {\fgs}. These
$FG^1_{N}$ {\fgs} can be used to create $C^2_{{N}}$ {\dcs} and so on.
At the top of the hierarchy, there will be one final (where $t$ is the
top level) component $C^{t}_{{N}}$ and {\em its fault modes, are the failure modes of the SYSTEM}. The causes for these
system level fault~modes will be traceable down to part fault modes, traversing the tree
through the lower level {\fgs} and components.
Each SYSTEM level fault may have a number of paths through the
tree to different low level of base component failure modes.
In FTA\cite{nucfta}\cite{nasafta} terminology, these paths through the tree are called `minimal cut sets'.
In FTA~\cite{nucfta}~\cite{nasafta} terminology, these paths through the tree are called `cut sets'.
%A hierarchy of levels of faults becoming more abstract (at each level) should
%converge to a small sub-set of system level errors.
In any System there are number of general failure mode conditions.
This number will always be far smaller than the number of component
This number will always be far smaller than the sum of component
failure modes of all its components.
This is because many component level failure modes
result in the same SYSTEM level failure modes.
@ -345,10 +361,11 @@ real time control systems often have a small number of major reportable faults (
even though they may have accompanying diagnostic data.
The FMMD hierarchy is of the form of a directed acyclic graph\cite{alg}. % XXX better citation really required
The FMMD hierarchy can be drawn in the form of a directed acyclic graph~\cite{alg}, this is
explored in chapter \ref{chap:dag}.. % XXX better citation really required
Each stage of analysis builds the acyclic graph by adding to the top of the tree, leaving the previous work
unchanged, very much in the way that the source code control system git\cite{git}
manages source code trees.
unchanged, very much in the way that the source code control system git~\cite{git}
appends changes to source code trees.
Because of this, it is permissible, for instance, to
create a functional group from components at different levels of failure mode abstraction.
@ -418,7 +435,7 @@ a few resistors to determine offset and gain,
a safety resistor, and perhaps some smoothing capacitors.
These components form a {\fg}. 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 two amplifiers are now connected to an ADC which converts the voltages to binary words for the micro-processor.
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.
@ -449,22 +466,23 @@ via the RS232 serial line.
% \label{fig:mvs}
% \end{figure}
This has a number of obvious {\fgs}, the PCB power supply, the milli-volt amplifiers,
This has a number of obvious modules (or {\fgs}), the PCB power supply, the milli-volt amplifiers,
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 {\fgs} in turn and examine them closely.
It would be sensible if the system could detect the most obvious fault~modes by self testing.
It would be sensible if the system could detect the most likely 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,
and then considering possible faulures 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
fault~modes of the milli-volt monitor as a whole.
However this type of analysis is not guaranteed
to rigorously take into account all fault~modes.
It is useful to follow an example fault through levels of abstraction hierarchy however.
It is useful to follow an example fault through levels of abstraction hierarchy to make this point clear.
%The FMMD technique,
%goes further than this by considering all part fault~modes and
@ -579,9 +597,9 @@ to correct the product.
\subsection {{\dcs} - Modules - re-usability}
In the example system in the introduction, the milli-volt amplifiers
use the same electronic circuit. The set of derived failure mode model for them is therefore
use the same electronic circuit. The derived failure mode model for them is therefore
the same.
Thus, the derived component, for the amplifiers may be re-used, with a different index number in the model..
Thus, the derived component, for the amplifiers may be re-used, with a different index number in the model.
\subsection{ Multi Channel Safety Critical Systems }
@ -599,7 +617,7 @@ The Ericsson AXE telephone exchange hardware is a 1oo2 system, and the arbiter (
can detect and switch control within on processor instruction. Should a hardware error
be detected,\footnote{Or in a test plant environment, more likely someone coming along and `borrowing' a cpu board from
your working exchange} the processor will switch to the redundant side without breaking any telephone calls
or any being set up. An alarm will be raised to inform that this has happened, but the impact to
or any being set up. An alarm will be raised to inform that this has happened, but the performance impact to
the 1oo2 system, is a one micro-processor instruction delay to the entire process.
The premise here is that the arbiter should be able to determine which

23
symptom_ex_process/symptom_ex_process.tex
View File

@ -327,8 +327,11 @@ are examined with respect to their effect on the functional~group.
%
The aim of this analysis is to find out how the functional~group fails given
the test case conditions, for each test case.
The goal of the process is to produce a set of failure modes from the perspective of the functional~group.
The goal of the process is to produce a set of failure modes from the perspective of the user of the functional~group.
%
In other words, if a designer is handed an piece of circuitry to use, he need not be concerned with
the failure modes of its components. He is handed it as a derived component, which has
a set of failure mode symptoms. The designer can now treat this piece of circuioty as a black box, or {\dc}.
\paragraph{Environmental Conditions or Applied States.}
@ -408,7 +411,7 @@ form `test cases'.
% \item For each region on the diagram, make a test case
\item Using the `test cases' as scenarios to examine the effects of component failures
we determine the failure~mode behaviour of the functional group.
This is a human process involving detailed analysis of the failure modes in the test case on the operation of the {\fg}.
This is a human process, involving detailed analysis of the component failure modes in the test case on the {\fg}.
Where spcific environment conditions, or applied states are germane to the {\fg}, these must be examined
for each test case.
\item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.
@ -675,7 +678,7 @@ the SYSTEM level.
%% IF this is a paper it needs work on the description here.
}
{
To re-cap from the definitions chapter \ref{chap:definitions}.
To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}.
Let the set of all possible components be $\mathcal{C}$
and let the set of all possible failure modes be $\mathcal{F}$.
@ -720,14 +723,14 @@ this section
using set theory and procedural descriptions.
%
The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$
and converts it to a derived~component/sub-system $DC$.
and a new 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 from which it was derived.
%Thus,
$DC$ can be treated
$DC$ can now be treated
as a component with a known set of failure modes.
@ -892,15 +895,15 @@ given by
$$ dtc(F) = TC $$
In algorithm \ref{alg2}, the function \textbf{chosen} means that the failure modes for a particular test case have been chosen by
In algorithm \ref{alg22}, the function \textbf{chosen} means that the failure modes for a particular test case have been chosen by
a human operator and are additional to those chosen by the automated process (i.e they are special case test cases involving multiple failure modes)
The function \textbf{unitarystate} means that all test cases can have no pairs of failure modes sourced from the component.
The function \textbf{unitarystate} means that all test cases can have no pairs of failure modes sourced from the same component.
\ifthenelse {\boolean{paper}}
{
%% perhaps ref a paper here XXXXX
}
{
This is discussed in section \ref{sec:unitarystate}.
This is discussed in chapter \ref{sec:unitarystate}.
}
%%
%% Algorithm 2
@ -1027,7 +1030,7 @@ $$ atc(TC) = R $$
\caption{Analyse Test Cases: atc(TC) } \label{alg33}
\begin{algorithmic}[1]
\STATE { let r be a `test case result'}
\STATE { Let the function $Analyse : tc \rightarrow 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 { Let the function $Analyse : tc \rightarrow r $ } \COMMENT { This analysis is a human activity, examining the component 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$ }
\FORALL { Environmental and Specific Applied States }
@ -1058,7 +1061,7 @@ where possible.
%
When the all the test cases have been analysed
we will have a `result' for each `test case'.
Each result will be described w.r.t. to the {\fg}, not the components failure modes
Each result will be described {\wrt} to the {\fg}, not the components failure modes
in its test case.
%
%In the case of a simple