diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex index 4846e9c..60a4f3e 100644 --- a/symptom_ex_process/algorithm.tex +++ b/symptom_ex_process/algorithm.tex @@ -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} diff --git a/symptom_ex_process/fmmd.tex b/symptom_ex_process/fmmd.tex index 5f63710..d443403 100644 --- a/symptom_ex_process/fmmd.tex +++ b/symptom_ex_process/fmmd.tex @@ -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. diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index 3a46670..8a762ab 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -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. diff --git a/symptom_ex_process/topbot.tex b/symptom_ex_process/topbot.tex index 8d78816..15f73ba 100644 --- a/symptom_ex_process/topbot.tex +++ b/symptom_ex_process/topbot.tex @@ -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