diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex index 0a09a1f..4fccb48 100644 --- a/symptom_ex_process/algorithm.tex +++ b/symptom_ex_process/algorithm.tex @@ -14,19 +14,16 @@ and converts it to a derived~component/sub-system $DC$. %of failure~modes of the sub-system. Note that $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 from which it was derived. Thus, it can be treated as a component with a known set of failure modes. - - - \paragraph{Enumerating abstraction levels} We can assign an attribute of abstraction level $\alpha$ to components, where $\alpha$ is a natural number, ($\alpha \in \mathbb{N}_0$). -For a base component let the abstraction level be zero. -If we apply the symptom abstraction process $\bowtie$ +For a base component, let the abstraction level be zero. +If we apply the symptom abstraction process $\bowtie$, 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. @@ -98,11 +95,11 @@ from the bottom-up. %\clearpage -\subsection{ Determine Failure \\ Modes to examine} +\subsection{ Determine Failure Modes to Examine} The first stage is to find the failure modes to consider for -analysis. -From the earlier definition of the function `fm': +analysis, +using the earlier definition of the function `fm'. The function $fm$ applied to a component returns the failure modes for that component. Thus its domain is the set of all components $\mathcal{C}$ and its range @@ -168,7 +165,7 @@ in the analysis stages. %\clearpage \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. The test cases are collections of failure modes. These can be formed from single failure modes or failure modes in combination. @@ -344,7 +341,7 @@ Ideally calculations or simulations are performed to determine how the failure modes in each test case will affect the functional~group. % -When the all the test cases have been anaslysed +When the all the test cases have been analysed we will have a `result' for each `test case'. Each result will be described w.r.t. to the {\fg}, not the components failure modes in its test case. @@ -377,7 +374,7 @@ These results are the failure modes of the functional group. This stage collects results into `symptom' sets. Each result from the preceding stage is examined and collected into common symptom sets. -That is to say, each result in a symptom set, from the perspective of the functional group +That is to say, each result in a symptom set, from the perspective of the functional group, has the same failure symptom. Let set $\mathcal{SP}$ be the set of all symptoms, and $\mathcal{R}$ be the set of all test case results. diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index a1c3f7a..cbd0982 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -23,14 +23,15 @@ The component failure modes in each test case are examined with respect to their effect on the functional~group. % The aim of this analysis is to find out how the functional~group fails given -the test case conditions, defined in each test case. +the test case conditions, for each test case. The goal of the process is to produce a set of failure modes from the perspective of the functional~group. % \paragraph{Environmental Conditions or Applied States} -Each test case must be considered in the for the case of each applied states or -environmental conditions that it may be exposed to. In this way all +Each test case must be considered for all applied/operational states and +%in the for the case of each applied states or +environmental conditions that it may be exposed to. In this way all possible failure mode behaviour due to the test case conditions will be examined. As part of this analysis process, records must be kept @@ -75,7 +76,7 @@ We can now consider the functional~group as a component and the symptoms as its Note that here, because the process is bottom up, we can ensure that all failure modes from the components in a functional~group have been handled\footnote{Software can check that all failure modes have been included in at least one test case, and modelled individually. For Double -Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well}. +Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well.}. 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, which solves the main failing of top~down methodologies \cite{topdownmiss}, that of not @@ -87,7 +88,7 @@ guaranteeing to model all component failure modes. \paragraph{To analyse a base level Derived~Component/sub-system} -To sumarise: +To summarise: \begin{itemize} \item Choose a set of components to form a functional group. @@ -98,14 +99,14 @@ Some specific combinations of failure modes might be included. For instance wher a very reliable part is duplicated but very critical, like the 4 engines on a 747 aircraft.}) of the failure modes to form `test cases'. - \item If required create test cases from all valid double failure mode combinations within the {\fg}. + \item If required, create test cases from all valid double failure mode combinations within the {\fg}. % \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 Using the `test cases' as scenarios to examine the effects of component failures we determine failure~mode behaviour of the functional group. This is a human process involving detailed analysis of the failure modes in the test case on the operation of the {\fg}. -Where spcific environment conditions, or applied states are germane to the {\fg} these must be examined +Where spcific environment conditions, or applied states are germane to the {\fg}, these must be examined for each test case. \item Collect common~symptoms by determining 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 {\fg}. i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail. @@ -124,7 +125,7 @@ Each component has a set of related fault modes (i.e. ways in which it can fail Let us define the following failure modes for each component, defining a function $fm()$ that is passed a component and returns the set of failure modes associated with it \footnote{Base component failure modes are defined, often with -statistics and evironmental factors in a variety of sources. \cite{mil1991} +statistics and environmental factors in a variety of sources. \cite{mil1991} }. @@ -298,7 +299,7 @@ $$ Given by $ \bowtie ( FG ) = DC $ -as per the example in preceeding section \ref{theoreticalsx}. +as per the example in precedeing section \ref{theoreticalsx}. \paragraph{Extending $\bowtie$ to {\dcs}} @@ -320,7 +321,7 @@ to the {\fg} comprised of derived components because we can obtain a failure mode set, (the failure mode set we have named $DCFM$). -Thus we can now move up another abstaction level by applying +Thus we can now move up another abstraction level by applying symptom abstraction/extraction to the functional group $FG_{derived}$ shown in equation \ref{eqn:fgderived}. @@ -356,10 +357,10 @@ to keep track of the abstraction level of a {\dc}. %%\end{equation} -In other words by analysing a functional group containing derived components +In other words by analysing a functional group containing derived components, we have a new derived component as our result. This naturally -builds a bottom-up failure mode model, +builds a bottom-up failure mode model and with each iteration the model becomes more abstract will eventually reach the SYSTEM level. diff --git a/symptom_ex_process/sys_abs.tex b/symptom_ex_process/sys_abs.tex index 2d6ca8c..80290aa 100644 --- a/symptom_ex_process/sys_abs.tex +++ b/symptom_ex_process/sys_abs.tex @@ -4,6 +4,41 @@ %% %% %% + +% +% ________________,------. +% /_|_____||____|__| | | ___________ +% `,---,-' __,---' `---.__ +% / / __,--'---._______________.---' +% ____/ /--'___________.-' +% `-./___/______________/ +% `---------' +% +% .-. .-. +% ( ) ___________ ( ) +% `-' __,----' \v/ `----.__ `-' +% \\'----._______________.----'// +% \\________.-'/|\`-.________// +% `=====<___ @ __>======' +% `-----' +% +% ________________,------. +% (_)_____||____|__| | | +% `,---,-' _.-----._ +% /___/ ,-' | `-. +% / `-._ ,' | `. +% | `-._ / `. | ,' \ +% / `/ `. | ,'_ \ +% |__ | `. .-. ,' /__ | +% |__|--O------<|-------- ( ) --|__>--| +% | | ,' `-' `. \_ | +% \ _,\ ,' | `. / +% | _,-' \ ,' | `. / +% \___\,-' `. | ,' +% \ \ `-._ | _.-' +% ________________,`---`-. `-----' +% (_)_____||____|__| | | +% \section{The Symptom Extraction Process} % TO DO: separate these two: @@ -31,7 +66,7 @@ The goal of the process is to produce a set of failure modes from the perspectiv \paragraph{Environmental Conditions or Applied States} -Each test case must be considered in the light of any applied states or +Each test case must be considered in the light of any operational states or environmental conditions that it may be exposed to. \paragraph{Electronics} diff --git a/symptom_ex_process/topbot.tex b/symptom_ex_process/topbot.tex index f5426ea..01f45b4 100644 --- a/symptom_ex_process/topbot.tex +++ b/symptom_ex_process/topbot.tex @@ -23,7 +23,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 instinctively performed from the top-down. A faulty piece of equipment is examined and will have a @@ -87,7 +87,7 @@ and now we may treat the functional group as a component, as it has a known set % By reusing the `components' derived from functional~groups an entire hierarichal failure mode model of the system can be built. -That is to say, using derived components in higher level functional groups +That is to say, using derived components in higher level functional groups, a hierarchy is naturally formed. % By working from the bottom up, we can trace all possible sources @@ -152,7 +152,7 @@ These are termed `functional~groups'. For instance the circuitry that powers th to illuminate the CD might contain a handful of components, and as such would make a good candidate to be one of the base level functional~groups. -\paragraph{{\fg} to {\dc} process outline} +\paragraph{Functional group to {\dc} process outline} In choosing the lowest level (base component) sub-systems we would look for the smallest `functional~groups' of components within a system. We can define a functional~group as a set of components that interact @@ -192,7 +192,7 @@ System & A product designed to \\ & work as a coherent entity \\ \hline Sub-system & A part of a system, \\ -or- derived component & sub-systems may contain sub-systems. \\ - & derived~components may by derived \\ + & derived~components may be derived \\ & from derived components \\ & Constraint: This object must have a defined set of failure~modes \\ \hline Failure mode & A way in which a system, \\