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

after hazel proof read and some more given by stuff, and found nice cardinality constraint check

Browse Source
This commit is contained in:
Robin 2010-08-03 22:41:29 +01:00
parent b5f8a03743
commit 64cfeffeca
4 changed files with 68 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

65
symptom_ex_process/algorithm.tex
View File

@ -13,16 +13,16 @@ and converts it to a 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,
$DC$ is a derived component at a higher level of fault analysis abstraction
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}
We can assign an attribute of abstraction level to
components $\alpha$, where $\alpha$ is a natural number, ($\alpha \in \mathcal{N}$).
components $\alpha$, where $\alpha$ is a natural number, ($\alpha \in \mathbb{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
the resulting 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
@ -36,11 +36,11 @@ will have an $\alpha$ value of 1.
%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
%With a derived component $DC$ having an abstraction level
The attribute $\alpha$ we can be used to track the
level of fault abstraction of components in an FMMD 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.
naturally formed with the abstraction levels increasing with each tier.
%\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group}
@ -54,10 +54,10 @@ naturally formed with the abstraction level increasing with each tier.
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.
verification checks in the process are stated formally.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine}
\subsection{ Determine Failure Modes to examine}
The first stage is to find the failure modes to consider for
analysis.
@ -110,7 +110,7 @@ in the analysis stages.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases}
\subsection{ Determine Test Cases}
From the failure modes associated with the functional~group
we now need to determine test cases.
@ -118,7 +118,7 @@ The test cases are collections of failure modes.
These could be formed from single failure modes or failure modes in combination.
Let $TC$ be the set of test cases associated with the functional group $FG$.
$$ DTC: \mathcal{F} \mapsto \mathcal{TC} $$
$$ DTC: \mathcal{F} \rightarrow \mathcal{TC} $$
given by
@ -167,7 +167,7 @@ $$ DTC(F) = TC $$
\IF{Double fault checking}
\STATE { let $f1,f2$ represet a component failure modes, and $c$ a component in the functional group }
%\ENSURE { That all failure modes are represented in at least one test case }
\ENSURE { $ \forall f1,f2 \;where\; (f1,f2) \not\in c\;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ }
\ENSURE { $ \forall f1,f2 \;where\; (f1,f2) \not\in c\;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) $ }
\COMMENT { This corresponds to checking that each possible double failure mode is considered
as a test case; more rigorous cardinality constraint
checks may be required for some safety standards. Note if both failure modes
@ -195,14 +195,16 @@ 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}
\subsection{ 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 test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$).
$$ATC: \mathcal{TC} \mapsto \mathcal{R} $$
$$ATC: \mathcal{TC} \rightarrow \mathcal{R} $$A
given by
$$ ATC(TC) = R $$
\begin{algorithm}[h+]
~\label{alg:sympabs3}
@ -229,7 +231,7 @@ Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional g
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms}
\subsection{ Find Common Symptoms}
%%
%% Algorithm 4
%%
@ -237,8 +239,9 @@ This stage analyses the results from bottom-up FMEA analysis ($R$), and collects
results that, from the perspective of the functional~group, have the same failure symptom.
Let set $SP$ be the set of symptoms for the functional group $FG$.
$$FCS: \mathcal{R} \mapsto \mathcal{SP} $$
$$FCS: \mathcal{R} \rightarrow \mathcal{SP} $$
given by
$$ FCS(R) = SP $$
\begin{algorithm}[h+]
~\label{alg:sympabs4}
@ -281,14 +284,25 @@ The failures have now been considered not from the component level, but from the
functional~group level.
We now have a set $SP$ of the symptoms of failure.
\ifthenelse {\boolean{paper}}
{
%CUNT VIM just went and wrote random shit did you not
Component failure modes must be mutually exclusive.
That is to say only one specific failure mode may be active at any time.
This condition/property has been termed unitary state failure mode.
Ensuring that no result belongs to more than
one Symptom set, enforces this.
}
{
Note ensuring that no result belongs to more than one symptom
enforces unitary state failure mode constraint for derived components.
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component}
\subsection{ Create Derived Component}
%%
%% Algorithm 5
%%
@ -297,7 +311,12 @@ This derived component may now be used to build
new functional groups at higher levels of fault abstraction.
Let $DC$ be a derived component with its own set of failure~modes.
$$ CDC: \mathcal{SP} \mapsto \mathcal{DC} $$
$$ CDC: \mathcal{SP} \rightarrow \mathcal{DC} $$
given by
$$ CDC(SP) = DC $$
\begin{algorithm}[h+]
~\label{alg:sympabs5}
@ -351,7 +370,7 @@ analyse the failure
mode behaviour and create a new entity, a derived~component, that has its own set of failure modes.
The checks and constraints applied in the algorithm ensure that all component failure
modes are covered.
This process naturally takes one step to building a hierarchical failure mode model
This process provides the analysis `step' to building a hierarchical failure mode model
from the bottom-up.
\subsection{Hierarchical Simplification}
@ -366,7 +385,7 @@ A Sound system might have, for instance only four faults at its highest or Syste
$$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT\}$$
\normalsize
The number of causes for any of these faults is very large.
It does not matter to the user, which combination of causes caused the fault.
It does not matter to the user, which combination of component failure~modes caused the fault.
But as the hierarchy goes up in abstraction level, the number of faults goes down.
\subsection{Tracable Fault Modes}

2
symptom_ex_process/fmmd.tex
View File

@ -9,7 +9,7 @@ FMMD modelling technique. FMMD builds a hierarchy of failure mode behaviours fro
To start with collections of base components are chosen to form functional~groups, which are analysed
w.r.t. its failure mode behaviour.
These functional groups
can then be treated as a components in their own right.
can then be treated as components in their own right.
These higher level, or derived compoenents,
can be used to build derived components at higher levels of abstraction, and ultimately
are used to build an FMMD fault model hierarchy of the system modelled.

29
symptom_ex_process/process.tex
View File

@ -8,7 +8,7 @@
The objective of `symptom abstraction' is to analyse the functional~group and find
how it can fail
when specified components within it fail.
Once we know how functional~group can fail, we can treat it as a component or sub-system
Once we know how a functional~group can fail, we can treat it as a component or sub-system
with its own set of failure modes.
\paragraph{FMEA applied to the Functional Group}
@ -45,7 +45,7 @@ will both cause the same failure; $no\_sound$ !
\paragraph{Collection of Symptoms}
The common symptoms of failure and lone~component failure~modes are identified and collected.
We can now consider the functional~group as a component and the common symptoms as its failure modes.
Note that here because the process is bottom up, we can ensure that all failure modes
Note that here, because the process is bottom up, we can ensure that all failure modes
associated with a functional~group have been handled.
Were failure~modes missed, any failure mode model could be dangerously incomplete.
It is possible here for an automated system to flag unhandled failure modes.
@ -187,9 +187,9 @@ $ SP1 = \{g_2, g_4, g_5\}$.
Likewise
let $SP2 = \{g_1, g_3, g_7\}$ be an identical failure mode {\em from the perspective of the functional~group}.
Let $\{g_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom},
s lone symptom can be assigned its own symptom set $SP3 = \{g_6\}$.
but as a `lone' symptom it can be assigned its own symptom set $SP3 = \{g_6\}$.
We have now in $SP1$, $SP2$ and $SP3$ as the three ways in which this functional~group can fail.
We now have in $SP1$, $SP2$ and $SP3$ the three ways in which this functional~group can fail.
In other words we have derived failure modes for this functional~group.
We can place these in a set of symptoms, $SP$.
%
@ -208,14 +208,23 @@ 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
% not being grouped as a common symptom
has \textbf{not dissappeared from the analysis process}.
Note that $g_6$ 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.
i.e. were it not to have been grouped in $SP3$, $ FM(DC)$ would have been $ \{ SP1, SP2, g_6 \}$.
This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}!
%
\ifthenelse {\boolean{paper}}
{
An advantage of a bottom-up process is that failure modes
from base level components cannot be overlooked.
}
{
An advantage of a bottom-up process is that failure modes
from base level components cannot be overlooked.
The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}).
The newly derived compoennt $DC$ is availble for use to form higher level functional groups, and we can thus
}
%
The newly derived component $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}$
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@ -257,9 +266,7 @@ Where DC is a derived component, and FG is a functional group:
This sub-system or derived~component $DC$ , with its three error modes, can now be treated as a component (although at a higher level of abstraction)
with known failure modes.
This process can be repeated using derived~components to build a
hierarchical
fault~mode
model.
hierarchical fault~mode model.

11
symptom_ex_process/topbot.tex
View File

@ -23,10 +23,13 @@ and can thus model an entire electro mechanical software controlled system.
\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.
Fault finding is instinctively performed from the top-down.
A faulty piece of equipment is examined and will have a
symptom or specific fault. The suspected area or sub-system within the
equipment will next be looked into.
symptom or specific fault.
%
The suspected area or sub-system within the
equipment will be looked into next.
%
The trouble shooter will look for behaviour that is unusual or incorrect
to determine the next area or sub~system to look into, each time
moving to a more detailed lower level.
@ -69,7 +72,7 @@ examined, as to their effect on the functional group.
The effects on the functional group can then be collected as common symptoms,
and now we may treat the functional group as a component as it has a known set of failure modes.
By reusing the `components' derived from functional~groups an entire
hierarichal failure mode mode of the system can be built.
hierarichal failure mode of the system can be built.
By working from the bottom up, we can trace all possible sources
that could cause a particular mode of equipment failure.
This means that at the design stage of a product all component failure