edits from Andrew fish comments 01OCT2010
This commit is contained in:
parent
0167f23b01
commit
95328ba5da
Binary file not shown.
Binary file not shown.
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
@ -5,32 +5,50 @@
|
|||||||
\ifthenelse {\boolean{paper}}
|
\ifthenelse {\boolean{paper}}
|
||||||
{
|
{
|
||||||
\begin{abstract}
|
\begin{abstract}
|
||||||
This paper describes a process for analysing safety critical systems, to formally prove how safe the
|
This paper describes
|
||||||
designs and built -in safety measures are. It provides
|
a methodology to analyse
|
||||||
the rigorous method for creating a fault effects model of a system from the bottom up using {\bc} level fault modes.
|
safety critcal designs from a failure mode perspective.
|
||||||
|
This paper concentrates on the hierarchical model: the analysis
|
||||||
|
phases (symtom abstraction) and {\fgs} are dealt with
|
||||||
|
in \cite{symptom_ex}.
|
||||||
|
|
||||||
|
The (Failure Mode Modular De-Composition) FMMD methodology provides
|
||||||
|
a rigorous method for creating a fault effects model of a system from the bottom up using {\bc} level fault modes.
|
||||||
Using symptom extraction, and taking {\fgs} of components, a fault behaviour
|
Using symptom extraction, and taking {\fgs} of components, a fault behaviour
|
||||||
hierarchy is built, forming a fault model tree.
|
hierarchy is built, forming a fault model tree.
|
||||||
From the fault model trees,
|
From the fault model trees,
|
||||||
modular re-usable sections of safety critical systems,
|
modular re-usable sections of safety critical systems,
|
||||||
and accurate, statistical estimation for fault frequency can be derived automatically.
|
and accurate, statistical estimation for fault frequency can be derived automatically.
|
||||||
It provides the means to trace the causes of dangerous detected and dangerous undetected faults.
|
It provides the means to trace the causes of dangerous detected and dangerous undetected faults.
|
||||||
|
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
|
||||||
|
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
|
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.
|
EN298, EN61508, EN12067, EN230, UL1998.
|
||||||
\end{abstract}
|
\end{abstract}
|
||||||
}
|
}
|
||||||
{
|
{
|
||||||
This chapter describes a process for analysing safety critical systems, to formally prove how safe the
|
This chapter describes the Failure Mode Modular De-Composition (FMMD)
|
||||||
designs and built -in safety measures are. It provides
|
methodology to analyse
|
||||||
the rigorous method for creating a fault effects model of a system from the bottom up using {\bc} level fault modes.
|
safety critcal designs from a failure mode perspective, with emphasis on building the hierarchical model..
|
||||||
|
%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.
|
||||||
Using symptom extraction, and taking {\fgs} of components, a fault behaviour
|
Using symptom extraction, and taking {\fgs} of components, a fault behaviour
|
||||||
hierarchy is built, forming a fault model tree.
|
hierarchy is built, forming a fault model tree.
|
||||||
From the fault model trees,
|
From the fault model trees,
|
||||||
modular re-usable sections of safety critical systems,
|
modular re-usable sections of safety critical systems,
|
||||||
and accurate, statistical estimation for fault frequency can be derived automatically.
|
and accurate, statistical estimation for fault frequency can be derived automatically.
|
||||||
It provides the means to trace the causes of dangerous detected and dangerous undetected faults.
|
It provides the means to trace the causes of dangerous detected and dangerous undetected faults.
|
||||||
|
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
|
||||||
|
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
|
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.
|
EN298, EN61508, EN12067, EN230, UL1998.
|
||||||
|
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
@ -40,7 +58,7 @@ EN298, EN61508, EN12067, EN230, UL1998.
|
|||||||
% described here, models a safety critical system from the bottom up.
|
% described here, models a safety critical system from the bottom up.
|
||||||
|
|
||||||
The purpose of the FMMD methodology is to apply formal techniques to
|
The purpose of the FMMD methodology is to apply formal techniques to
|
||||||
the assessment of safety critical designs, aiding in identifying detected and undetected faults
|
the assessment of safety critical designs, aiding in identifying detected and undetectable faults
|
||||||
\footnote{Undetectable faults are faults which may occur but are not self~detected, or are impossible to detect by the system.}.
|
\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
|
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
|
such as the Z notation appear as `highly recommended' techniques in the EN61508 standard\cite{en61508}, but
|
||||||
@ -152,7 +170,7 @@ This analysis and symptom collection process is described in detail in the Sympt
|
|||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
\subsubsection{An algebraic notation for identifying FMMD enitities}
|
\subsubsection{An algebraic notation for identifying FMMD enitities}
|
||||||
Each component $C$ is a set of failure modes for the component.
|
Each component $C$ holds a set of failure modes for the component.
|
||||||
We can define a function $fm$ that returns the
|
We can define a function $fm$ that returns the
|
||||||
set of failure modes $F$ for the component $C$.
|
set of failure modes $F$ for the component $C$.
|
||||||
|
|
||||||
@ -169,6 +187,13 @@ defined by, where C is a component and F is a set of failure modes.
|
|||||||
|
|
||||||
$$ fm ( C ) = F $$
|
$$ fm ( C ) = F $$
|
||||||
|
|
||||||
|
We can use the variable name $FG$ to represent a {\fg}. A {\fg} is a collection
|
||||||
|
of components. We thus define $FG$ as a set of components that have been chosen as members
|
||||||
|
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 $$
|
||||||
|
|
||||||
%$$ \mathcal{fm}(C) \rightarrow S $$
|
%$$ \mathcal{fm}(C) \rightarrow S $$
|
||||||
%$$ {fm}(C) \rightarrow S $$
|
%$$ {fm}(C) \rightarrow S $$
|
||||||
@ -180,14 +205,11 @@ the abstraction level zero thus $C^0$. Should we wish to index the components
|
|||||||
Our base component (if first in the parts~list) could now be uniquely identified as
|
Our base component (if first in the parts~list) could now be uniquely identified as
|
||||||
$C^0_1$.
|
$C^0_1$.
|
||||||
|
|
||||||
A {\fg} can use the variable name $FG$. A {\fg} is a collection
|
|
||||||
of components. We thus define $FG$ as a set of components that have been chosen as members
|
|
||||||
of a {\fg}.
|
|
||||||
We can further define the abstraction level of a {\fg}.
|
We can further define the abstraction level of a {\fg}.
|
||||||
We can say that it is the maximum abstraction level of any of its
|
We can say that it is the maximum abstraction level of any of its
|
||||||
components. Thus a functional group containing only base components
|
components. Thus a functional group containing only base components
|
||||||
would have an abstraction level zero and could be represented with a superscript of zero thus
|
would have an abstraction level zero and could be represented with a superscript of zero thus
|
||||||
$FG^0$. The functional group set may also be indexed.
|
`$FG^0$'. The functional group set may also be indexed.
|
||||||
|
|
||||||
We can apply symptom abstraction to a {\fg} to find
|
We can apply symptom abstraction to a {\fg} to find
|
||||||
a set of derived failure modes. We are interested in the failure modes
|
a set of derived failure modes. We are interested in the failure modes
|
||||||
@ -213,12 +235,12 @@ An example of a simple system will illustrate this.
|
|||||||
|
|
||||||
\subsection {Example FMEA process using an FMEA diagram}
|
\subsection {Example FMEA process using an FMEA diagram}
|
||||||
|
|
||||||
Consider a simple {\fg} $ FG^0_1 $ derived from two base components $C^0_1,C^0_2$.
|
Consider a simple {\fg} $ FG^0_1 $ comprising of two base components $C^0_1,C^0_2$.
|
||||||
|
|
||||||
We can apply $\bowtie$ to the {\fg} $FG$
|
We can apply $\bowtie$ to the {\fg} $FG$
|
||||||
and it will return a {\dc} at abstraction level 1 (with an index of 1 for completeness)
|
and it will return a {\dc} at abstraction level 1 (with an index of 1 represented a as sub-script)
|
||||||
|
|
||||||
$$ \bowtie fm(( FG^0_1 )) = C^1_1 $$
|
$$ \bowtie \big( fm(( FG^0_1 )) \big)= C^1_1 $$
|
||||||
|
|
||||||
to look at this analysis process in more detail.
|
to look at this analysis process in more detail.
|
||||||
|
|
||||||
@ -228,28 +250,39 @@ By way of example applying ${fm}$ to obtain the failure modes $f_N$
|
|||||||
$$ {fm}(C^0_1) = \{ f_1, f_2 \} $$
|
$$ {fm}(C^0_1) = \{ f_1, f_2 \} $$
|
||||||
$$ {fm}(C^0_2) = \{ f_3, f_4, f_5 \} $$
|
$$ {fm}(C^0_2) = \{ f_3, f_4, f_5 \} $$
|
||||||
|
|
||||||
And overloading $fm$ to find the flat set of failure modes from a {\fg}
|
And overloading $fm$ to find the flat set of failure modes from the {\fg} $FG^0_1$
|
||||||
|
|
||||||
$$ {fm}{FG^0_1} = \{ s_6, s_7, s_8 \} $$
|
$$ {fm}({FG^0_1}) = \{ f_1, f_2, f_3, f_4, f_5 \} $$
|
||||||
|
|
||||||
The symptom extraction process is now applied
|
The symptom extraction process is now applied
|
||||||
i.e. the analyst now considers failure modes $f_{1..5}$ in the context of the {\fg}
|
i.e. the analyst now considers failure modes $f_{1..5}$ in the context of the {\fg}
|
||||||
and determines the failure modes of the {\fg}..
|
and determines the `failure symptoms' of the {\fg}.
|
||||||
The result of this process will be a set of derived failure modes.
|
The result of this process will be a set of derived failure modes.
|
||||||
For this example, let these be $ \{ s_6, s_7, s_8 \} $.
|
For this example, let these be $ \{ s_6, s_7, s_8 \} $.
|
||||||
We can now create a {\dc} $C^1_1$ with this set of failure modes.
|
We can now create a {\dc} $C^1_1$ with this set of failure modes.
|
||||||
|
|
||||||
Thus:
|
Thus:
|
||||||
|
|
||||||
$$ {fm}(C^1_1) = \{ s_6, s_7, s_8 \} $$
|
$$ \bowtie \big( {fm}(FG^0_1) \big) = C^1_1 $$
|
||||||
|
|
||||||
|
|
||||||
We can represent this analysis process in a diagram see figure \ref{fig:onestage}
|
and applying $fm$ to the newly derived component
|
||||||
|
|
||||||
|
$$ fm(C^1_1) = \{ s_6, s_7, s_8 \} $$
|
||||||
|
|
||||||
|
By representing this analysis process in a diagram, the hierarchical nature
|
||||||
|
of the process is apparent, see figure \ref{fig:onestage}.
|
||||||
|
Each $\bowtie$ analysis phase, raises the level of failure mode abstraction.
|
||||||
|
By this we can see the failure effects becoming less specific (for instance a resistor going open)
|
||||||
|
and more about the effect that will have on a functional system (for instance `amplifier one' failing)
|
||||||
|
as the failure modes raise in abstraction level.
|
||||||
|
|
||||||
\begin{figure}[h]
|
\begin{figure}[h]
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=200pt,bb=0 0 268 270]{fmmdset/onestage.jpg}
|
\includegraphics[width=200pt,bb=0 0 268 270]{fmmdset/onestage.jpg}
|
||||||
% onestage.jpg: 268x270 pixel, 72dpi, 9.45x9.52 cm, bb=0 0 268 270
|
% onestage.jpg: 268x270 pixel, 72dpi, 9.45x9.52 cm, bb=0 0 268 270
|
||||||
\caption{FMMD analysis of functional group}
|
%\caption{FMMD analysis of functional group}
|
||||||
|
\caption{FMMD Analysis of one functional Group: Two components form a functional group, which forms a derived component}
|
||||||
\label{fig:onestage}
|
\label{fig:onestage}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
@ -279,19 +312,32 @@ We can represent this analysis process in a diagram see figure \ref{fig:onestage
|
|||||||
Figure \ref{fig:fmmdh} shows a hierarchy of failure mode de-composition.
|
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.
|
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 {\dc} $C^{1}_{{N}}$ sets to form {\fgs}. These
|
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.
|
$FG^2_{N}$ {\fgs} can be used to create $C^3_{{N}}$ {\dcs} and so on.
|
||||||
At the top of the hierarchy, there will be one final (where $t$ is the
|
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
|
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
|
system level fault~modes will be traceable down to part fault modes, traversing the tree
|
||||||
through the lower level {\fgs} and components.
|
through the lower level {\fgs} and components.
|
||||||
each SYSTEM level fault may have a number of paths through the
|
Each SYSTEM level fault may have a number of paths through the
|
||||||
tree to different low level of base component failure modes.
|
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 `minimal cut sets'.
|
||||||
|
|
||||||
|
|
||||||
A hierarchy of levels of faults becoming more abstract at each level should
|
%A hierarchy of levels of faults becoming more abstract (at each level) should
|
||||||
converge to a small sub-set of system level errors.
|
%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
|
||||||
|
failure modes of all its components.
|
||||||
|
This is because many component level failure modes
|
||||||
|
result in the same SYSTEM level failure modes.
|
||||||
|
|
||||||
|
%%-\subsection{ Proof of number of component~failure \\ modes preserved in hierarchy build}
|
||||||
|
%%-
|
||||||
|
%%-Here we need to prove that if there is an abstract fault, then as it goes higher in the tree, it can only collect MORE not less
|
||||||
|
%%-actual {\bc} failure modes.
|
||||||
|
As we go up through a fault hierarchy, the
|
||||||
|
number of failure modes to handle, should decrease
|
||||||
|
with each level of abstraction.
|
||||||
|
|
||||||
This thinning out of the number of system level errors is borne out in practice;
|
This thinning out of the number of system level errors is borne out in practice;
|
||||||
real time control systems often have a small number of major reportable faults (typically $ < 50$),
|
real time control systems often have a small number of major reportable faults (typically $ < 50$),
|
||||||
@ -305,7 +351,7 @@ manages source code trees.
|
|||||||
Because of this, it is permissible, for instance, to
|
Because of this, it is permissible, for instance, to
|
||||||
create a functional group from components at different levels of failure mode abstraction.
|
create a functional group from components at different levels of failure mode abstraction.
|
||||||
|
|
||||||
\cite{sem}
|
%\cite{sem}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -319,16 +365,12 @@ create a functional group from components at different levels of failure mode ab
|
|||||||
%\caption{Simple Euler Diagram}
|
%\caption{Simple Euler Diagram}
|
||||||
%\end{figure}
|
%\end{figure}
|
||||||
|
|
||||||
\cite{sem}
|
%\cite{sem}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
\section {Modelling considerations}
|
\section {Modelling considerations}
|
||||||
|
|
||||||
\subsection{ Proof of number of component~failure \\ modes preserved in hierarchy build}
|
|
||||||
|
|
||||||
Here we need to prove that if there is an abstract fault, then as it goes higher in the tree, it can only collect MORE not less
|
|
||||||
actual {\bc} failure modes.
|
|
||||||
%% This is obvious but needs a proof.
|
%% This is obvious but needs a proof.
|
||||||
%% Also this means that we may need dummy modules so as not to violate jumping up the tree structure
|
%% Also this means that we may need dummy modules so as not to violate jumping up the tree structure
|
||||||
|
|
||||||
@ -438,7 +480,7 @@ It is useful to follow an example fault through levels of abstraction hierarchy
|
|||||||
%a dangerous/potentially fatal error. Again having a complete fault analysis tree will reveal these conditions.
|
%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}
|
\subsection{An example part Fault and \\ its representation at different abstraction levels}
|
||||||
|
|
||||||
An example of a part fault effect on the example system is given below, showing how this fault
|
An example of a part fault effect on the example system is given below, showing how this fault
|
||||||
manifests itself at each abstraction level.
|
manifests itself at each abstraction level.
|
||||||
@ -491,8 +533,9 @@ the circuitry between the input milli-volt signal and the ADC/Microcontroller.
|
|||||||
On examining this we would probably measure the in circuit resistances
|
On examining this we would probably measure the in circuit resistances
|
||||||
and discover the faulty resistor.
|
and discover the faulty resistor.
|
||||||
With the natural fault finding process, we have narrowed down until we came to
|
With the natural fault finding process, we have narrowed down until we came to
|
||||||
the faulty component. FMMD analysis works from the bottom~up, and this is
|
the faulty component.
|
||||||
because it must cover all component failure modes.
|
Because FMMD analysis works from the bottom~up,
|
||||||
|
it is possible to check that all component failure modes have been considered in the model.
|
||||||
%%
|
%%
|
||||||
%% END CASE STUDY
|
%% END CASE STUDY
|
||||||
%%
|
%%
|
||||||
@ -515,9 +558,11 @@ Test rigs apply a rigorous checking process to safety critical equipment before
|
|||||||
they can be sold, and this usually is a legal or contractural requirement, backed up by inspections
|
they can be sold, and this usually is a legal or contractural requirement, backed up by inspections
|
||||||
and and an approval process.
|
and and an approval process.
|
||||||
|
|
||||||
They are usually a clamp arrangement where the PCB under test is placed.
|
They are usually a clamp arrangement where the PCB under test is placed over
|
||||||
|
connection points applied by gold plated sprung pins: these rigs are commonly known
|
||||||
|
as `beds of nails' \cite{garret} \cite{maikowski}.
|
||||||
Precision and calibrated test signals are then applied to the board under test. For PCBs containing
|
Precision and calibrated test signals are then applied to the board under test. For PCBs containing
|
||||||
microprocessor, custom test~rig software may be run on them to exercise
|
microprocessors, custom test~rig software may be run on them to exercise
|
||||||
active sections of the PCB (for instance to drive outputs, relays etc).
|
active sections of the PCB (for instance to drive outputs, relays etc).
|
||||||
|
|
||||||
The main purpose of a test rig is to prevent fault equipment from being shipped.
|
The main purpose of a test rig is to prevent fault equipment from being shipped.
|
||||||
@ -530,11 +575,12 @@ Having a fault causation tree would be useful for identifying which parts may be
|
|||||||
or simply incorrect. The test rig armed with the fault analysis tree could point to parts or combinations of parts that could be checked
|
or simply incorrect. The test rig armed with the fault analysis tree could point to parts or combinations of parts that could be checked
|
||||||
to correct the product.
|
to correct the product.
|
||||||
|
|
||||||
\subsection {Modules - re-usability}
|
\subsection {{\dcs} - Modules - re-usability}
|
||||||
|
|
||||||
In the example system in the introduction, the milli-volt amplifiers
|
In the example system in the introduction, the milli-volt amplifiers
|
||||||
are the same circuit. The set of derived faults for the module may therefore
|
use the same electronic circuit. The set of derived failure mode model for them is therefore
|
||||||
simply be given a different index number and re-used.
|
the same.
|
||||||
|
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 }
|
\subsection{ Multi Channel Safety Critical Systems }
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user