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

after talk with Andrew Fish 30JUL2010

Browse Source
This commit is contained in:
Robin 2010-08-01 16:41:15 +01:00
parent 24f0ce0b65
commit 35a08f62e8
4 changed files with 128 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

139
symptom_ex_process/algorithm.tex
View File

@ -18,34 +18,62 @@ than the functional~group it was derived from.
However, it can still be treated
as a component with a known set of failure modes.
\paragraph{Enumerating abstraction levels}
If $DC$ were to be included in a functional~group,
that functional~group must be considered to be at a higher level of
abstraction than a base level functional~group.
We can assign an attribute of abstraction level to
components $\alpha$, where $\alpha$ is a natural number, ($\alpha \in \mathcal{N}$).
For a base component let the abstraction level be zero.
If we apply the symptom abstraction process $\bowtie$
the reulting derived~component will have an $\alpha$ value
one higher that the highest $\alpha$ value of any of the components
in the functional group used to derive it.
Thus a derived component sourced from base components
will have an $\alpha$ value of 1.
%
In fact, if the abstraction level is enumerated,
the functional~group must take the abstraction level
of the highest assigned to any of its components.
%If $DC$ were to be included in a functional~group,
%that functional~group must be considered to be at a higher level of
%abstraction than a base level functional~group.
%
$DC$ can be used as a system building block at a higher
level of fault abstraction. Because derived components
are collected to form functional groups, a converging hierarchy is
%In fact, if the abstraction level is enumerated,
%the functional~group must take the abstraction level
%of the highest assigned to any of its components.
%
With a derived component $DC$ having an abstraction level
attribute $\alpha$ we can use this to track the
level of fault abstraction through a hierarchy. Because base and derived components
are collected to form functional groups, a hierarchy is
naturally formed with the abstraction level increasing with each tier.
The algorithm, representing the function $\bowtie$, has been broken down into five stages, each following on from the other.
%\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group}
% \IF{$c.\alpha > \alpha_{max}$}
% $\alpha_{max} = c.\alpha$
% \ENDIF
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$}
%\ENDFOR
The algorithm, representing the function $\bowtie$, has been broken down into five consecutive stages.
These are described using the Algorithm environment in the next section \ref{algorithms}.
By defining the process and describing it using set theory, constraints and
verification checks in the process can be stated formally.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine}
The first stage is to find the failure modes to consider for
analysis.
Let $FG$ be the set of components in the functional group under analysis, and $c$
be components that are members of it. This function returns a flat set of failure modes $F$.
From the earlier definition of the function `FM':
$$ FM: \mathcal{FG} \mapsto \mathcal{F}$$
The function $FM$ applied to a component returns the failure modes for that component.
The function $FM$ takes a flat set components $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$.
$$ FM: \mathcal{FG} \rightarrow \mathcal{F}$$
%Let $FG$ be the set of components in the functional group under analysis, and $c$
%be components that are members of it. This function returns a flat set of failure modes $F$.
given by
$$FM(FG) = F$$
%%
%% Algorithm 1
%%
@ -54,31 +82,33 @@ $$ FM: \mathcal{FG} \mapsto \mathcal{F}$$
~\label{alg:sympabs1}
\caption{FM( $FG$ )} \label{alg:sympabs11}
\begin{algorithmic}[1]
\REQUIRE {FG is a set of components}
\REQUIRE {FG is a set of components (a functional~group)}
\STATE { Let $FG$ be a set of components } \COMMENT{ The functional group should be chosen to be minimally sized collections of components that perform a specific function}
\STATE { Let $c$ represent a component}
\ENSURE{ Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG | FM(c) \neq \emptyset$ }
\FORALL { $c \in FG $ }
\REQUIRE{ Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; such \; that\; FM(c) \neq \emptyset$ }
\ENDFOR
\STATE {let $F=FM(FG)$ be a set of all failure modes to consider for the functional~group $FG$}
%\STATE {Collect all failure modes from all the components in FG into the set $FG_{cfm}$}
%\FORALL { $c \in FG $ }
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$}
%\ENDFOR
\RETURN { $F$ }
%\hline
%
\end{algorithmic}
\end{algorithm}
Algorthim \ref{alg:sympabs11} has taken a functional~group $FG$ and returned a set of failure~modes $F=FM(FG)$ where each component has a known set of failure~modes.
The next task is to formulate `test cases'. These are the combinations of failure~modes that will be used
Algorthim \ref{alg:sympabs11} has taken a functional~group $FG$ and returned a set of failure~modes $F=FM(FG)$
(given that each component has a known set of failure~modes).
The next task is to formulate `test cases'. These are a collection of combinations of these failure~modes and will be used
in the analysis stages.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases}
@ -90,6 +120,10 @@ Let $TC$ be the set of test cases associated withthe functional group $FG$.
$$ DTC: \mathcal{F} \mapsto \mathcal{TC} $$
given by
$$ DTC(F) = TC $$
%%
%% Algorithm 2
%%
@ -109,25 +143,37 @@ $$ DTC: \mathcal{F} \mapsto \mathcal{TC} $$
\STATE { Let $TC$ be a set of test cases }
\STATE { Let $tc_j$ be set of component failure modes where $j$ is an index of $J$}
\COMMENT { Each set $tc_j$ is a `test case' }
\STATE { $ \forall j \in J | tc_j \in TC $ } \COMMENT {Ensure the test cases are complete and unique}
%\STATE { $ \forall j \in J | tc_j \in TC $ } \COMMENT {Ensure the test cases are complete and unique}
\FORALL { $tc_j \in TC$ }
%\ENSURE {$ tc_j \in \bigcap FG_{cfm} $}
\ENSURE {$ tc_j \in \mathcal{P}(F))$}
\COMMENT { require that the test case is a member of the powerset of $F$ }
\ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $}
%\ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $}
\ENSURE { $\forall j1,j2 \in J \; such\; that\; tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 $}
\COMMENT { Test cases must be unique }
\ENDFOR
\IF{Single fault checking}
\STATE { let $f$ represet a component failure mode }
\ENSURE { That all failure modes are represented in at least one test case }
\ENSURE { $ \forall f | (f \in F)) \wedge (f \in \bigcup TC) $ }
%\ENSURE { That all failure modes are represented in at least one test case }
\ENSURE { $ \forall f \;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ }
\COMMENT { This corresponds to checking that at least each failure mode is considered at
least once in the analysis; more rigorous cardinality constraint
checks may be required for some safety standards}
\ENDIF
\IF{Double fault checking}
\STATE { let $f1,f2$ represet a component failure modes }
%\ENSURE { That all failure modes are represented in at least one test case }
\ENSURE { $ \forall f1,f2 \;where\; \not(f1,f2) \in c\;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ }
\COMMENT { This corresponds to checking that at least each possible double failure mode is considered at
least once in the analysis; more rigorous cardinality constraint
checks may be required for some safety standards. Not if both failure modes
in the check are sourced from the same component $c$ the test case is impossible
under unitary state failure mode conditions}
\ENDIF
\RETURN $TC$
% some european standards
@ -144,13 +190,17 @@ The next stage is to analyse the effect of each test case on the functional grou
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Analyse Test Cases}
%%
%% Algorithm 3
%%
The test cases are now analysed for their impact on the behaviour of the functional~group.
Let $R$ be a set of results indexed by $j$ (the same index used to identify the test cases $tc_{j}$).
Let $R$ be a set of test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$).
$$ATC: \mathcal{TC} \mapsto \mathcal{R} $$
@ -163,7 +213,8 @@ $$ATC: \mathcal{TC} \mapsto \mathcal{R} $$
\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$ }
\STATE { $ rc_j = Analyse(tc_j) $} \COMMENT {this is Fault Mode Effects Analysis (FMEA) applied in the context of the functional group}
\STATE { $ rc_j \in R $ } \COMMENT{Add $rc_j$ to the set R}
%\STATE { $ rc_j \in R $ } \COMMENT{Add $rc_j$ to the set R}
\STATE{ $ R := R \cap rc_j $ } \COMMENT{Add $rc_j$ to the set R}
\ENDFOR
\RETURN $R$
@ -174,6 +225,9 @@ $$ATC: \mathcal{TC} \mapsto \mathcal{R} $$
Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms}
%%
@ -210,8 +264,7 @@ $$FCS: \mathcal{R} \mapsto \mathcal{SP} $$
causes in the functional group $FG$}
%\ENSURE { $ \forall l2 \in L ( \forall l1 \in L | \exists a \in sp_{l1} \neq \exists b \in sp_{l2} \wedge l1 \neq l2 ) $}
\REQUIRE {$ \forall a \in sp_l | \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$}
\ENSURE {$ \forall a \in sp_l \;such\;that\; \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$}
\COMMENT { Ensure that the elements in each $sp_l$ are not present in any other $sp_l$ set }
\ENDFOR
@ -231,6 +284,9 @@ We now have a set $SP$ of the symptoms of failure.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component}
%%
@ -252,7 +308,9 @@ $$ CDC: \mathcal{SP} \mapsto \mathcal{DC} $$
\STATE { Let $DC$ be a derived component with failure modes $f$ indexed by $l$ }
\FORALL { $sp_l \in SP$ }
\STATE { $ f_l = ConvertToFaultMode(sp_l) $}
\STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
%\STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
\STATE { $DC := DC \cap f_l$ } \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
\ENDFOR
\RETURN DC
%\hline
@ -276,11 +334,11 @@ $$ \bowtie: \mathcal{FG} \mapsto \mathcal{DC} $$
\begin{algorithmic}[1]
\STATE {F = FM (FG)}
\STATE {TC = DTC (F)}
\STATE {R = ATC (TC)}
\STATE {SP = FCS (R)}
\STATE {DC = CDC (SP)}
\STATE {F = FM (FG)} \COMMENT{ collect all the failure modes from the from the components in the functional~group }
\STATE {TC = DTC (F)} \COMMENT{ determine all test cases to apply to the functional group }
\STATE {R = ATC (TC)} \COMMENT{ analyse the test cases, for failure mode behaviour of the functional~group }
\STATE {SP = FCS (R)} \COMMENT{ find common symptoms of failure for the functional group }
\STATE {DC = CDC (SP)} \COMMENT{ create a derived component }
\RETURN $DC$
@ -299,7 +357,8 @@ from the bottom-up.
Because symptom abstraction collects fault modes, the number of faults to handle decreases
as the hierarchy progresses upwards.
This is seen by casual observation of real life Systems. At the highest levels the number of faults
%This is seen by casual observation of real life Systems. NEED A GOOD REF HERE
At the highest levels the number of faults
is significantly less than the sum of its component failure modes.
A Sound system might have, for instance only four faults at its highest or System level,
\small

2
symptom_ex_process/fmmd.tex
View File

@ -2,7 +2,7 @@
% Describe FMMD
\section{Background: FMMD outline}
\section{Background:\\ FMMD outline}
The symptom abstraction process described here, is a core process in the
%Failure Mode Modular De-Composition
FMMD modelling technique. FMMD builds a hierarchy of failure mode behaviours from the bottom up.

26
symptom_ex_process/process.tex
View File

@ -57,16 +57,17 @@ It is possible here for an automated system to flag unhandled failure modes.
To sumarise:
\begin{itemize}
\item Determine a minimal functional group
\item Obtain the list of components in the functional group
\item Collect the failure modes for each component
\item Choose a set of components to form a functional group.
% \item Obtain the list of components in the functional group
\item Collect the failure modes of each component into a flat set.
\item Choose all single instances and selected combinations of the failure modes to
form `test cases'.
% \item Draw these as contours on a diagram
% \item Where si,ultaneous failures are examined use overlapping contours
% \item For each region on the diagram, make a test case
\item Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group
\item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use.
Determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider').
\item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component.
\item Using the `test cases' determine their effects on the failure~mode behaviour of the functional group.
\item Collect common~symptoms. i.e. determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.
\item The common~symptoms are now the fault mode behaviour of the functional~group.
\item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component.
\end{itemize}
@ -94,7 +95,7 @@ and let the set of all possible failure modes be $\mathcal{F}$.
We can define a function $FM$
\begin{equation}
\mathcal{FM} : \mathcal{C} \mapsto \mathcal{P}\mathcal{F}
{FM} : \mathcal{C} \mapsto \mathcal{P}\mathcal{F}
\end{equation}
defined by (where $C$ is a component and $F$ is a set of failure modes):
@ -207,7 +208,7 @@ We can thus apply the function $FM$ on this newly derived component thus:
$$ FM(DC) = \{ SP1, SP2, SP3 \} $$
Note that $g_6$, while %being a failure mode has
Note that $g_6$ %, %while %being a failure mode has
% not being grouped as a common symptom
has \textbf{not dissappeared from the analysis process}.
Were the designer to have overlooked this test case, it would appear as a failure mode of the derived component.
@ -217,6 +218,7 @@ The process must not allow failure modes to be ignored or forgotten (see project
The newly derived compoennt $DC$ is availble for use to form higher level functional groups, and we can thus
consider DC as being in the set of components i.e. $DC \in \mathcal{C}$
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Defining the analysis process as a function}
@ -259,3 +261,9 @@ hierarchical
fault~mode
model.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %

12
symptom_ex_process/topbot.tex
View File

@ -1,5 +1,5 @@
\section{Fault Finding and Failure Mode Analysis}
\section{Fault Finding \\ and Failure Mode Analysis}
\subsection{Static Analysis}
@ -21,7 +21,7 @@ can be derived.
FMMD can model electrical, mechanical and software using a common notation,
and can thus model an entire electro mechanical software controlled system.
\subsection{Top Down or natural trouble shooting}
\subsection{Top Down or \\ natural trouble shooting}
It is interesting here to look at the `natural' trouble shooting process.
Fault finding is intinctively performed from the top-down.
A faulty piece of equipment is examined and will have a
@ -173,7 +173,8 @@ System & A product designed to \\
Sub-system & A part of a system, \\
-or- derived component & sub-systems may contain sub-systems. \\
& derived~components may by derived \\
& from derived components \\ \hline
& from derived components \\
& Constraint: This object must have a defined set of failure~modes \\ \hline
Failure mode & A way in which a System, \\
& Sub-system or component can fail \\ \hline
Functional Group & A collection of sub-systems and/or \\
@ -181,8 +182,9 @@ Functional Group & A collection of sub-systems and/or \\
& perform a specific function \\ \hline
Symptom & A failure mode of a functional group, caused by \\
& a combination of its component failure modes \\ \hline
Base Component & Any bought in component, which \\
& hopefully has a known set of failure modes \\ \hline
Base Component & Any bought in component, or \\
& lowest level module/or part \\
& Constraint: This object must have a defined set of failure~modes \\ \hline
\hline
\end{tabular}
\caption{Symptom Extraction Definitions}