diff --git a/submission_thesis/appendixes/algorithmic.tex b/submission_thesis/appendixes/algorithmic.tex index a5d93fa..875d0c1 100644 --- a/submission_thesis/appendixes/algorithmic.tex +++ b/submission_thesis/appendixes/algorithmic.tex @@ -1,11 +1,22 @@ -\chapter{Algorithmic Description of Symptom Abstraction} +\chapter{Algorithmic Description of FMMD} %\label{sec:symptom_abstraction} \label{sec:algorithmfmmd} This section uses algorithms and set theory to describe the process for analysing a {\fg} and determining from it a {\dc}. +It begins with an overview of the FMMD process, and then contrasts and compares it +to diagnostic analysis (fault finding). + % -\paragraph{Symptom Abstraction in brief} +\section{FMMD as a process.} + +In FMMD we take a group of components with a functional purpose, apply +FMEA, and then determine how the {\fg} can fail. +We determine the common symptoms of failure of the {\fg}, and then +create a new {\dc} which has, as its failure modes, the symptoms we determined. + +\paragraph{FMMD and failure mode models.} + In essence, we take a {\fg} (a collection of components), and apply FMEA analysis locally on this {\fg}. % @@ -18,7 +29,7 @@ we are able to collect common symptoms of failure for the {\fg}. % With the collected common symptoms, we can treat the {\fg} as a component in its own right. -This new component, is derived from the {\fg}. +This new component being derived from the {\fg}. In the field of safety engineering this derived component corresponds to a low~level sub-system. %The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint diagrams\cite{constraint} to model failure modes and failure mode common symptom collection. The technique is designed for making building blocks for a hierarchical fault model. % @@ -34,7 +45,7 @@ Using the FMMD technique, the hierarchy is built from the bottom up to ensure complete failure mode coverage. Because the process is bottom-up, syntax checking and tracking can ensure that no component failure mode can be overlooked. -Once a hierarchy is in place, it can be converted into a fault data model. +Once a hierarchy is in place, it can be converted into a generic failure mode model. \fmmdgloss % From the fault data model, automatic generation @@ -51,7 +62,13 @@ The symptom extraction or abstraction process, is the key process in creating an -\subsection{Fault Finding and Failure Mode Analysis} +\subsection{Diagnostic analysis and Failure Mode Analysis} +Fault finding is a closely related discipline to failure mode analysis. +In diagnostic analysis, we generally start with a high level --- or system ---failure type. +We trace this from the top, de-composing the systems until we come to +a component or sub-system that has caused the failure. +While there are similarities between diagnostic failure mode tracing and static failure mode analysis +it is important to discuss the differences between them. % %\subsection{Static Analysis} % @@ -76,7 +93,7 @@ The symptom extraction or abstraction process, is the key process in creating an %and can thus model an integrated electro-mechanical software controlled system. % \subsection{Top Down or Natural Trouble Shooting} -It is interesting here to look at the `natural' trouble shooting process. +We firstly 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 symptom or specific fault. @@ -92,7 +109,7 @@ and checks will be made, and finally a component or a low level sub-system will be found to be faulty. A natural fault finding process is thus top~down. Top down formal fault isolation/finding techniques for electronics are described in \cite{maikowski}. - +Fault tree analysis is a top down static failure mode analysis technique~\cite{nucfta,nasafta}. %% %% to fool the graphics insertion to make it compatible %% with thesis and papaer level directories. @@ -145,8 +162,8 @@ a hierarchy is naturally formed. 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 -modes must be considered. The aim here is for complete failure mode coverage. -This also means that we can obtain statistical estimates based on the known reliabilities +modes must be considered. A benefit of FMMD is complete failure mode coverage. +This also means that it is possible to obtain statistical estimates based on the known reliabilities of components~\cite{mil1991}. %It also means that every component failure mode must at the very least be considered. @@ -206,11 +223,11 @@ of components~\cite{mil1991}. \nocite{safeware} -\section{Overview of Symptom Extraction Process} +\section{Overview of the FMMD analysis Process} % TO DO: separate these two: -\paragraph{Symptom Extraction Objective.} +\paragraph{FMMD analysis Objective.} The objective of `symptom abstraction' is to analyse the functional~group and find how it can fail when specified components within it fail. @@ -242,13 +259,13 @@ a set of failure mode symptoms. The designer can now treat this piece of circuit Each test case must be considered for all applied/operational states and %in the for the case of each applied states or environmental conditions to which it may be exposed. In this way, all possible -failure mode behaviour due to the test case conditions will be examined. +failure mode behaviour due to all the conditions that can be applied to a test case will be examined. As part of this analysis process, records must be kept detailing each test case result along with its resultant {\fg} failure mode. -This data will be kept in the model and can be used to -examine environmentally sourced common mode failure scenarios. +If this data is kept in the model and could be used to +automatically examine the effects of environmentally sourced common mode failure scenarios. %%- A {\fg} may, in the case of an electronic circuit have @@ -267,30 +284,44 @@ When all `test~cases' have been analysed, a second phase can be actioned. % appl % This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but of the {\fg}/sub-system. %Single component failures (or combinations) within the functional~group may cause unique symptoms. -However, many failures, when looked at from the perspective of the functional group, will have the same symptoms. +%However, m +Many failures, when looked at from the perspective of the functional group, will have the same symptoms. These can be collected as `common symptoms'. +% To go back to the CD~player example, a failed output stage, and a failed internal audio amplifier, -will both cause the same failure; $no\_sound$ ! +will both cause the same failure symptom; $no\_sound$ ! \paragraph{Collection of Symptoms.} -Looking at the functional group perspective failure modes, we can collect -some of these into common `symptoms'. Some test cases may cause +%Looking at the +examining failure from the +functional group perspective failure modes, we collect +some of these into common `symptoms' where possible. +% +Some test cases may cause unique failure modes at the functional group level. These can be termed lone symptoms. +% The common symptoms of failure and lone~symptoms are identified and collected. -We can now consider the functional~group as a component and the symptoms as its failure modes. -Note that here, because the process is bottom up, we can ensure that all failure modes +% +We can now create a new component and consider the symptoms as its failure modes. +% +We call this new component a `{\dc}'. +% +%Note that here, b +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.}. % -Were any failure~modes missed, the failure mode model could be dangerously incomplete. +Were any failure~modes missed, the failure mode model could be %dangerously +incomplete. +% It is possible here for an automated system to flag un-handled failure modes, which solves the main failing of top~down methodologies %\cite{topdownmiss}, @@ -815,15 +846,16 @@ cases can have no pairs of failure modes sourced from the same component. \label{sec:completetest} -This function also ensure completeness in the model. -It ensures that for all failure modes in the {\fg} are considered in a test~case. - +This function also ensures completeness in the model. +It ensures that %for +all failure modes in the {\fg} are considered in a test~case. +% \ifthenelse {\boolean{paper}} { %% perhaps ref a paper here XXXXX } { -This is discussed in chapter \ref{sec:unitarystate}. +Components with a unitary state property are discussed in chapter \ref{sec:unitarystate}. } %% %% Algorithm 2 @@ -970,19 +1002,21 @@ Algorithm \ref{alg33} has built the set $R$, the sub-system/functional group res The analysis is primarily a human activity. % -Each test case is examined in detail. +%Each test case is examined in detail. % % Calculations or simulations are performed to determine how the failure modes in each test case will affect the functional~group. -Ideally field and formal physical testing data should be used in addition +Ideally field data and/or formal physical testing should be used in addition static failure mode reasoning where possible. % When the all the test cases have been analysed we will have a `result' for each `test case'. -Each result will be described {\wrt} to the {\fg}, not the components failure modes -in its test case. +% +Each result will be described from the perspective of %{\wrt} to +the {\fg}, not the components failure modes. +%in its test case. % %In the case of a simple %electronic circuit, we could calculate the effect on voltages @@ -1144,7 +1178,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 fault modes, the number of faults to handle decreases +Because symptom abstraction collects 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 @@ -1155,13 +1189,17 @@ $$ 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. +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. \subsection{Traceable Fault Modes} Because the fault modes are determined from the bottom-up, the causes for all high level faults naturally form trees. -These trees can be traversed to produce +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, the Mean Time to Failure (MTTF) and SIL\cite{en61508} levels can be automatically calculated.