From 50d8a0dc75d5869509d126193f60f07e2f2f5393 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 27 Jul 2013 14:58:03 +0100 Subject: [PATCH] JMC PR --- submission_thesis/appendixes/algorithmic.tex | 37 ++++++++++++-------- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/submission_thesis/appendixes/algorithmic.tex b/submission_thesis/appendixes/algorithmic.tex index e3e9c0e..b6e65b0 100644 --- a/submission_thesis/appendixes/algorithmic.tex +++ b/submission_thesis/appendixes/algorithmic.tex @@ -268,7 +268,7 @@ The FMMD process is described in chapter~\ref{sec:chap4}, to re-cap, FMMD has fo % with its own set of failure modes. % Once the failure symptoms for a {\fg} are known, the {\fg} can be treated as a component or sub-system % with its own set of failure modes. -This process allows us to modularise and simply FMEA analysis of systems. +This process allows us to modularise and simplify FMEA analysis of systems. % The FMMD process stages are expanded upon below. @@ -291,8 +291,8 @@ each test case. % %The goal of the process is to produce a set of failure modes from the perspective of the user of the {\fg}. % -In other words, if a designer has a previously analysed module to use, he need not be concerned with -the failure modes of its components: it is handed it as a derived component, +In other words, if a designer has a previously analysed module to use, he/she need not be concerned with +the failure modes of its components: it is handled it as a derived component, which has its own FMMD defined set of failure modes. % symptoms. % The designer can now treat this module as a black box (i.e. as a {\dc}). @@ -402,7 +402,7 @@ we determine the failure~mode behaviour of the {\fg}. % This is a human process, applying FMEA for each test case. % -Where specific environment conditions, or operational states are germane to the {\fg}, these must also be examined +Where specific environmental conditions, or operational states are germane to the {\fg}, these must also 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 {\fg}}. @@ -675,11 +675,13 @@ for each test case. % } % { -\subsection{Single FMMD stage described as a `symptom~abstraction~process'} +\subsection{Single stage of FMMD described as a `symptom~abstraction~process'} We can view one stage of FMMD analysis as the act of symptom abstraction. -This is because we take a {\fg} and from its component failure modes and FMEA analysis, symptoms of failure derived. +% +This is because we take a {\fg} and from its component failure modes and FMEA analysis, derive symptom of failure. %symptoms of failure derived. +% These derived failure mode, failure modes of the {\fg} considered as an entity or component, are abstract or at a higher level in the systems modular hierarchy. %To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}. @@ -750,7 +752,7 @@ components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$). For a base component, let the abstraction level be zero. If we apply the symptom abstraction process $\derivec$, the resulting derived~component will have an $\abslev$ value -one higher that the highest $\abslev$ value of any of the components +one higher than the highest $\abslev$ value of any of the components in the {\fg} used to derive it. Thus a derived component sourced from base components will have an $\abslev$ value of 1. @@ -779,10 +781,10 @@ naturally formed with the abstraction levels increasing with each tier. %\ENDFOR -The algorithm, represented by the symbol `$\derivec$', has been broken down into five consecutive stages. +The algorithm, represented by the symbol `$\derivec$', is now broken down into five consecutive steps. %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 are stated formally. +By defining the process and describing it using set theory constraints and +verification checks in the process can be stated formally. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -1077,10 +1079,10 @@ The analysis is primarily a human activity. Calculations or simulations are performed to determine how the failure modes in each test case will affect the functional~group. -Ideally field data and/or formal physical testing should be used in addition static failure mode reasoning +Ideally field data and/or formal physical testing should be used in addition to static failure mode reasoning where possible. % -When the all the test cases have been analysed +When all the test cases have been analysed, we will have a `result' for each `test case'. % Each result will be described from the perspective of %{\wrt} to @@ -1205,7 +1207,7 @@ set enforces the `unitary state failure mode constraint' for derived components. %% %% Algorithm 5 %% -This final stage, is the creation of the derived component. +This final stage is the creation of the derived component. This derived component may now be used to build new {\fgs} at higher levels of fault abstraction. Let $DC$ be a derived component with its own set of failure~modes. @@ -1247,7 +1249,7 @@ to form functional~groups at higher levels of failure~mode~abstraction. %Hierarchies of fault abstraction can be built that can model an entire SYSTEM. \subsection{Hierarchical Simplification} -Because symptom abstraction collects aggregates fault modes, the number of faults to handle should decrease +Because symptom abstraction aggregates fault modes, the number of faults to handle should decrease as the hierarchy progresses upwards. %This is seen by casual observation of real life Systems. NEED A GOOD REF HERE At the highest levels the number of faults @@ -1257,7 +1259,9 @@ 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 component failure~modes caused the fault. +% But as the hierarchy goes up in abstraction level, the number of failure modes goes down for each level: as is found in practise in real world systems. @@ -1265,9 +1269,12 @@ as is found in practise in real world systems. Because the fault modes are determined from the bottom-up, the causes for all high level faults naturally form trees. -That is to say from the bottom-up causes become symptoms which in the next level become causes as we traverse up the tree. +% +That is to say from the bottom-up causes become symptoms, which in the next level become causes as we traverse up the tree. +% This is demonstrated in the examples chapter~\ref{sec:chap5} where DAGS are drawn linking failure mode causes and symptoms in FMMD analysis hierarchies. +% These trees can be also traversed to produce minimal cut sets\cite{nasafta} or entire FTA trees\cite{nucfta}, and by analysing the statistical likelihood of the component failures,