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 %The sub-system $SS$ is a collection
%of failure~modes of the sub-system. %of failure~modes of the sub-system.
Note that 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. than the functional~group it was derived from.
However, it can still be treated However, it can still be treated
as a component with a known set of failure modes. as a component with a known set of failure modes.
\paragraph{Enumerating abstraction levels} \paragraph{Enumerating abstraction levels}
We can assign an attribute of abstraction level to 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. For a base component let the abstraction level be zero.
If we apply the symptom abstraction process $\bowtie$ 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 one higher that the highest $\alpha$ value of any of the components
in the functional group used to derive it. in the functional group used to derive it.
Thus a derived component sourced from base components 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 %the functional~group must take the abstraction level
%of the highest assigned to any of its components. %of the highest assigned to any of its components.
% %
With a derived component $DC$ having an abstraction level %With a derived component $DC$ having an abstraction level
attribute $\alpha$ we can use this to track the The attribute $\alpha$ we can be used to track the
level of fault abstraction through a hierarchy. Because base and derived components level of fault abstraction of components in an FMMD hierarchy. Because base and derived components
are collected to form functional groups, a hierarchy is 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} %\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. 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}. 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 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 \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 The first stage is to find the failure modes to consider for
analysis. analysis.
@ -110,7 +110,7 @@ in the analysis stages.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage \clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases} \subsection{ Determine Test Cases}
From the failure modes associated with the functional~group From the failure modes associated with the functional~group
we now need to determine test cases. 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. 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$. 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 given by
@ -167,7 +167,7 @@ $$ DTC(F) = TC $$
\IF{Double fault checking} \IF{Double fault checking}
\STATE { let $f1,f2$ represet a component failure modes, and $c$ a component in the functional group } \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 { 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 \COMMENT { This corresponds to checking that each possible double failure mode is considered
as a test case; more rigorous cardinality constraint as a test case; more rigorous cardinality constraint
checks may be required for some safety standards. Note if both failure modes 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 \clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Analyse Test Cases} \subsection{ Analyse Test Cases}
%% %%
%% Algorithm 3 %% Algorithm 3
%% %%
The test cases are now analysed for their impact on the behaviour of the functional~group. 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}$). 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+] \begin{algorithm}[h+]
~\label{alg:sympabs3} ~\label{alg:sympabs3}
@ -229,7 +231,7 @@ Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional g
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage \clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms} \subsection{ Find Common Symptoms}
%% %%
%% Algorithm 4 %% 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. 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$. 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+] \begin{algorithm}[h+]
~\label{alg:sympabs4} ~\label{alg:sympabs4}
@ -281,14 +284,25 @@ The failures have now been considered not from the component level, but from the
functional~group level. functional~group level.
We now have a set $SP$ of the symptoms of failure. 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 \clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component} \subsection{ Create Derived Component}
%% %%
%% Algorithm 5 %% Algorithm 5
%% %%
@ -297,7 +311,12 @@ This derived component may now be used to build
new functional groups at higher levels of fault abstraction. new functional groups at higher levels of fault abstraction.
Let $DC$ be a derived component with its own set of failure~modes. 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+] \begin{algorithm}[h+]
~\label{alg:sympabs5} ~\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. 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 The checks and constraints applied in the algorithm ensure that all component failure
modes are covered. 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. from the bottom-up.
\subsection{Hierarchical Simplification} \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\}$$ $$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT\}$$
\normalsize \normalsize
The number of causes for any of these faults is very large. 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. But as the hierarchy goes up in abstraction level, the number of faults goes down.
\subsection{Tracable Fault Modes} \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 To start with collections of base components are chosen to form functional~groups, which are analysed
w.r.t. its failure mode behaviour. w.r.t. its failure mode behaviour.
These functional groups 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, These higher level, or derived compoenents,
can be used to build derived components at higher levels of abstraction, and ultimately 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. 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 The objective of `symptom abstraction' is to analyse the functional~group and find
how it can fail how it can fail
when specified components within it 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. with its own set of failure modes.
\paragraph{FMEA applied to the Functional Group} \paragraph{FMEA applied to the Functional Group}
@ -45,7 +45,7 @@ will both cause the same failure; $no\_sound$ !
\paragraph{Collection of Symptoms} \paragraph{Collection of Symptoms}
The common symptoms of failure and lone~component failure~modes are identified and collected. 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. 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. associated with a functional~group have been handled.
Were failure~modes missed, any failure mode model could be dangerously incomplete. 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. 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 Likewise
let $SP2 = \{g_1, g_3, g_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. 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}, 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. In other words we have derived failure modes for this functional~group.
We can place these in a set of symptoms, $SP$. 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 \} $$ $$ FM(DC) = \{ SP1, SP2, SP3 \} $$
Note that $g_6$ %, %while %being a failure mode has Note that $g_6$ has \textbf{not dissappeared from the analysis process}.
% 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. 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 \}$. 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!}! 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 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}$ 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) 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. with known failure modes.
This process can be repeated using derived~components to build a This process can be repeated using derived~components to build a
hierarchical hierarchical fault~mode model.
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} \subsection{Top Down or \\ natural trouble shooting}
It is interesting here to look at the `natural' trouble shooting process. 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 A faulty piece of equipment is examined and will have a
symptom or specific fault. The suspected area or sub-system within the symptom or specific fault.
equipment will next be looked into. %
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 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 to determine the next area or sub~system to look into, each time
moving to a more detailed lower level. 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, 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. 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 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 By working from the bottom up, we can trace all possible sources
that could cause a particular mode of equipment failure. that could cause a particular mode of equipment failure.
This means that at the design stage of a product all component failure This means that at the design stage of a product all component failure