From 6bbdfda43e9d8448fc7d9e41854aab1c1374ed1f Mon Sep 17 00:00:00 2001 From: Robin Date: Sat, 24 Jul 2010 11:51:29 +0100 Subject: [PATCH] restructured to make chapter and paper easier to produce, and tidied algorithm section --- symptom_ex_process/abstract.tex | 38 ++++ symptom_ex_process/algorithm.tex | 321 ++++++++++++++++++++++++++++ symptom_ex_process/fmmd.tex | 3 + symptom_ex_process/introduction.tex | 42 ++++ symptom_ex_process/process.tex | 258 ++++++++++++++++++++++ symptom_ex_process/sx.tex | 21 ++ symptom_ex_process/sys_abs.tex | 261 ++++++++++++++++++++++ symptom_ex_process/topbot.tex | 167 +++++++++++++++ 8 files changed, 1111 insertions(+) create mode 100644 symptom_ex_process/abstract.tex create mode 100644 symptom_ex_process/algorithm.tex create mode 100644 symptom_ex_process/fmmd.tex create mode 100644 symptom_ex_process/introduction.tex create mode 100644 symptom_ex_process/process.tex create mode 100644 symptom_ex_process/sx.tex create mode 100644 symptom_ex_process/sys_abs.tex create mode 100644 symptom_ex_process/topbot.tex diff --git a/symptom_ex_process/abstract.tex b/symptom_ex_process/abstract.tex new file mode 100644 index 0000000..e54f9cc --- /dev/null +++ b/symptom_ex_process/abstract.tex @@ -0,0 +1,38 @@ +\begin{abstract} +In failure mode analysis, it is essential to +know the failure modes of the sub-systems and components used. +This paper outlines a technique for determining the failure modes of a sub-system given +its components. +% +This paper describes a process for taking a functional~group of components, +applying FMEA analysis on all the component failure modes possible in that functional~group, +and then determining how that functional group can fail. +% +With this information, we can treat the functional group +as a component in its own right. +This new component is a derived from the functional~group. +In the field of safety engineering this derived component correspond 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. + +Once the failure modes have been determined for a sub-system/derived~component, +this derived component can be combined with others to form functional groups +to model +higher level sub-systems/derived~components. +In this way a hierarchy to represent the fault behaviour +of a system can be built from the bottom~up. This process can continue +until there is a complete hierarchy representing the failure mode +behaviour of the entire system under analysis. +%FMMD hierarchy +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. +% +From the fault data model, automatic generation +of FTA\cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets\cite{nucfta} are possible. +Also statistical reliability/probability of failure~on~demand\cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced +automatically, where component failure mode statistics are available\cite{mil1991}. +% +% +This paper focuses on the process of building the blocks, the symptom extraction or abstraction process, that is key to creating an FMMD hierarchy. +\end{abstract} diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex new file mode 100644 index 0000000..45b3515 --- /dev/null +++ b/symptom_ex_process/algorithm.tex @@ -0,0 +1,321 @@ + + +%\section{A Formal Algorithmic Description of `Symptom Abstraction'} +\section{Algorithmic Description} + +The algorithm for {\em symptom extraction} is described in +this section +%describes the symptom abstraction process +using set theory. + +The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$ +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, +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} +If $DC$ were to be included in a functional~group, +that functional~group must be considered to be at a higher level of +abstraction than a base level functional~group. +% +In fact, if the abstraction level is enumerated, +the functional~group must take the abstraction level +of the highest assigned to any of its components. +% +$DC$ can be used as a system building block at a higher +level of fault abstraction. Because the derived components +merge to form functional groups, a converging hierarchy is +naturally formed with the abstraction level increasing with each tier. + + +The algorithm, representing the function $\bowtie$, has been broken down into five stages, each following on from the other. +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. + +\clearpage +\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine} + +The first stage is to find the failure modes to consider for +analysis. +Let $FG$ be the set of components in the functional group under analysis, and $c$ +be components that are members of it. This function returns a flat set of failure modes $F$. + +$$ FG \mapsto F$$ +%% +%% Algorithm 1 +%% + +\begin{algorithm}[h+] + ~\label{alg:sympabs1} +\caption{FM( $FG$ )} \label{alg:sympabs11} +\begin{algorithmic}[1] +\REQUIRE {FG is a set of components} + +\STATE { Let $FG$ be a set of components } \COMMENT{ The functional group should be chosen to be minimally sized collections of components that perform a specific function} +\STATE { Let $c$ represent a component} + +\ENSURE{ Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG | FM(c) \neq \emptyset$ } + +\STATE {let $F=FM(FG)$ be a set of all failure modes to consider for the functional~group $FG$} + +%\STATE {Collect all failure modes from all the components in FG into the set $FG_{cfm}$} +%\FORALL { $c \in FG $ } +%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$} +%\ENDFOR + +\RETURN { $F$ } + +%\hline + +\end{algorithmic} +\end{algorithm} + +Algorthim \ref{alg:sympabs11} has taken a functional~group $FG$ and returned a set of failure~modes $F=FM(FG)$ where each component has a known set of failure~modes. +The next task is to formulate `test cases'. These are the combinations of failure~modes that will be used +in the analysis stages. + +\clearpage +\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases} + +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 could be formed from single failure modes or failure modes in combination. +Let $TC$ be the set of test cases associated withthe functional group $FG$. + +$$ DTC: F \mapsto TC$$ + +%% +%% Algorithm 2 +%% + + +\begin{algorithm}[h+] + ~\label{alg:sympabs2} +\caption{DTC: (F) } \label{alg:sympabs22} +\begin{algorithmic}[1] + + \REQUIRE {F is a flat set of failure modes } + + \STATE { All test cases are now chosen by the investigating engineer(s). Typically all single + component failures are investigated + with some specially selected combination faults} + + \STATE { Let $TC$ be a set of test cases } + \STATE { Let $tc_j$ be set of component failure modes where $j$ is an index of $J$} + \COMMENT { Each set $tc_j$ is a `test case' } + \STATE { $ \forall j \in J | tc_j \in TC $ } \COMMENT {Ensure the test cases are complete and unique} + + \FORALL { $tc_j \in TC$ } + %\ENSURE {$ tc_j \in \bigcap FG_{cfm} $} + \ENSURE {$ tc_j \in \mathcal{P}(F))$} + \COMMENT { require that the test case is a member of the powerset of $F$ } + \ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $} + \COMMENT { Test cases must be unique } + \ENDFOR + + + + \STATE { let $f$ represet a component failure mode } + \ENSURE { That all failure modes are represented in at least one test case } + \ENSURE { $ \forall f | (f \in F)) \wedge (f \in \bigcup TC) $ } + \COMMENT { This corresponds to checking that at least each failure mode is considered at + least once in the analysis; more rigorous cardinality constraint + checks may be required for some safety standards} + + + \RETURN $TC$ +% some european standards +% imply checking all double fault combinations\cite{en298} } + +%\hline + +\end{algorithmic} +\end{algorithm} + +Algorithm \ref{alg:sympabs22} has taken the set of failure modes $ F=FM(FG) $ and returned a set of test cases $TC$. +The next stage is to analyse the effect of each test case on the functional group. + + + + +\clearpage +\subsection{Algorithmic Description of Symptom Abstraction \\ 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 results indexed by $j$ (the same index used to identify the test cases $tc_{j}$). + +$$ATC: TC \mapsto R $$ + +\begin{algorithm}[h+] + ~\label{alg:sympabs3} +\caption{ATC(TC) } \label{alg:sympabs33} +\begin{algorithmic}[1] + \STATE { let r be a `test case result'} + \STATE { Let the function $Analyse : tc \mapsto r $ } \COMMENT { This analysis is a human activity, examining the failure~modes in the test case and determining how the functional~group will fail under those conditions} + \STATE { $ R $ is a set of test case results $r_j \in R$ where the index $j$ corresponds to $tc_j \in TC$} + \FORALL { $tc_j \in TC$ } + \STATE { $ rc_j = Analyse(tc_j) $} \COMMENT {this is Fault Mode Effects Analysis (FMEA) applied in the context of the functional group} + \STATE { $ rc_j \in R $ } \COMMENT{Add $rc_j$ to the set R} + \ENDFOR + + \RETURN $R$ + +%\hline +\end{algorithmic} +\end{algorithm} + +Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case. + +\clearpage +\subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms} +%% +%% Algorithm 4 +%% +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: R \mapsto SP $$ + + +\begin{algorithm}[h+] + ~\label{alg:sympabs4} + +\caption{FCS($R$)} \label{alg:sympabs44} + +\begin{algorithmic}[1] + + + %\REQUIRE {All failure modes for the components in $fm_i = FM(fg_i)$} + \STATE {Let $sp_l$ be a set of `test cases results' where $l$ is an index set $L$} + \STATE {Let $SP$ be a set whose members are sets $sp_l$} + \COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system} +% + %\COMMENT{This corresponds to a fault symptom of the functional group $FG$} + %\COMMENT{where double failure modes are required the cardinality constrained powerset of two must be applied to each failure mode} + + \FORALL { $ r_j \in R$ } + \STATE { $sp_l \in \mathcal{P} R \wedge sp_l \in SP$ } + %\STATE { $sp_l \in \bigcap R \wedge sp_l \in SP$ } + \COMMENT{ Collect common symptoms. + Analyse the sub-system's fault behaviour under the failure modes in $tc_j$ and determine the symptoms $sp_l$ that it +causes in the functional group $FG$} + %\ENSURE { $ \forall l2 \in L ( \forall l1 \in L | \exists a \in sp_{l1} \neq \exists b \in sp_{l2} \wedge l1 \neq l2 ) $} + + \REQUIRE {$ \forall a \in sp_l | \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$} + + \COMMENT { Ensure that the elements in each $sp_l$ are not present in any other $sp_l$ set } + + \ENDFOR + \STATE { The Set $SP$ can now be considered to be the set of fault modes for the sub-system that $FG$ represents} + + \RETURN $SP$ +%\hline + +\end{algorithmic} +\end{algorithm} + +Algorithm \ref{alg:sympabs44} raises the failure~mode abstraction level. +The failures have now been considered not from the component level, but from the sub-system or +functional~group level. +We now have a set $SP$ of the symptoms of failure. + + + + +\clearpage +\subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component} +%% +%% Algorithm 5 +%% +This final stage, is the creation of the derived component. +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: SP \mapsto DC $$ +\begin{algorithm}[h+] + ~\label{alg:sympabs5} + +\caption{CDC(SP) } \label{alg:sympabs55} + +\begin{algorithmic}[1] + + \STATE { Let $DC$ be a derived component with failure modes $f$ indexed by $l$ } + \FORALL { $sp_l \in SP$ } + \STATE { $ f_l = ConvertToFaultMode(sp_l) $} + \STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes} + \ENDFOR +%\hline + +\end{algorithmic} +\end{algorithm} + +Algorithm \ref{alg:sympabs55} is the final stage in the process. We now have a +derived~component $DC$, which has its own set of failure~modes. This can now be +used in conjection with other components (or derived~components) +to form functional~groups at a higher level of failure~mode~abstraction. +Hierarchies of fault abstraction can be built that can model an entire SYSTEM. + +\section{Linking all five stages} + +$$ \bowtie: FG \mapsto DC $$ + +\begin{algorithm}[h+] + +\caption{$\bowtie(FG)$} \label{alg:sympabs66} + +\begin{algorithmic}[1] + + \STATE {F = FM (FG)} + \STATE {TC = DTC (F)} + \STATE {R = ATC (TC)} + \STATE {SP = FCS (R)} + \STATE {DC = CDC (SP)} + + \RETURN $DC$ + +\end{algorithmic} +\end{algorithm} + +The symptom abstraction technique allows us to take a functional group of components, 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 +from the bottom-up. + +\subsection{Hierarchical Simplification} + +Because symptom abstraction collects fault modes, the number of faults to handle decreases +as the hierarchy progresses upwards. +This is seen by casual observation of real life Systems. At the highest levels the number of faults +is significantly less than the sum of its component failure modes. +A Sound system might have, for instance only four faults at its highest or System level, +\small +$$ 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. +But as the hierarchy goes up in abstraction level, the number of faults goes down. + +\subsection{Tracable Fault Modes} + +Because the fault modes are determined from the bottom-up, the causes +for all high level faults naturally form trees. +Minimal cut sets \cite{nasafta} can be determined from these, and by +analysing the statistical likelyhood of the component failures, +the MTTF and SIL\cite{en61508} levels can be automatically calculated. + + +\vspace{40pt} +\today + diff --git a/symptom_ex_process/fmmd.tex b/symptom_ex_process/fmmd.tex new file mode 100644 index 0000000..b2d1b17 --- /dev/null +++ b/symptom_ex_process/fmmd.tex @@ -0,0 +1,3 @@ + + +Describe FMMD diff --git a/symptom_ex_process/introduction.tex b/symptom_ex_process/introduction.tex new file mode 100644 index 0000000..108434e --- /dev/null +++ b/symptom_ex_process/introduction.tex @@ -0,0 +1,42 @@ +{ +In failure mode analysis, it is essential to +know the failure modes of the sub-systems and components used. +This paper outlines a technique for determining the failure modes of a sub-system given +its components. +% +This chapter describes a process for taking a functional group of components, +applying FMEA analysis on all the component failure modes possible in that functional~group, +and then determining how that functional group can fail. +% +% +With this information, we can treat the functional group +as a component in its own right. +This new component is a derived from the functional~group. +In the field of safety engineering this derived component correspond 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. +% +Once the failure modes have been determined for a sub-system/derived~component, +this derived component can be combined with others to form functional groups +to model +higher level sub-systems/derived~components. +% +In this way a hierarchy to represent the fault behaviour +of a system can be built from the bottom~up. This process can continue +until there is a complete hierarchy representing the failure mode +behaviour of the entire system under analysis. +%FMMD hierarchy +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. +% +From the fault data model, automatic generation +of FTA\cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets\cite{nucfta} are possible. +Also statistical reliability/probability of failure~on~demand\cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced +automatically, where component failure mode statistics are available\cite{mil1991}. +% +This chapter focuses on the process of building the blocks, the symptom extraction or abstraction process, that is key to creating an FMMD hierarchy. + + +} + diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex new file mode 100644 index 0000000..40c113b --- /dev/null +++ b/symptom_ex_process/process.tex @@ -0,0 +1,258 @@ + +\section{The Symptom abstraction Process} + +% TO DO: separate these two: + +\paragraph{Symptom Extraction Described} + +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 +with its own set of failure modes. + +\paragraph{FMEA applied to the Functional Group} +As the functional~group is a set of components, the failure~modes +that we have to consider are all the failure modes of its components. +Each failure mode (or combination of) investigated is termed a `test case'. +Each `test case' is analysed. +% +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 reacts +to each of the test case conditions. +The goal of the process is to produce a set of failure modes from the perspective of the functional~group. + + + + +\paragraph{Symptom Identification} +When all `test~cases' have been analysed, a second phase is applied. +% +This looks at the results of the `test~cases' as symptoms +of the 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. +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$ ! + + + + +\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 +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. +\ref{requirement at the start} + + +\section{The Process : To analyse a base level Derived~Component/sub-system} + +To sumarise: + +\begin{itemize} + \item Determine a minimal functional group + \item Obtain the list of components in the functional group + \item Collect the failure modes for each component +% \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 Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group + \item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use. +Determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider'). + \item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component. + \item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component. +\end{itemize} + + + + +\section{A general derived Component/Sub-System example} + +Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. + +$$ FG = \{ C_1 , C_2 , C_3 \} $$ + +Each component has a set of related fault modes (i.e. ways in which it can fail to operate correctly). +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} +}. + +To re-cap from the definitions chapter \ref{chap:definitions}. + +Let the set of all possible components be $\mathcal{C}$ +and let the set of all possible failure modes be $\mathcal{F}$. + +We can define a function $FM$ + +\begin{equation} +FM : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} +\end{equation} + +defined by (where $C$ is a component and $F$ is a set of failure modes): + +$$ FM ( C ) = F $$ + +%\\ + +And for this example: + +$$ FM(C_1) = \{ a_1, a_2, a_3 \} $$ +$$ FM(C_2) = \{ b_1, b_2 \} $$ +$$ FM(C_3) = \{ c_1, c_2 \} $$ + + +\paragraph{Finding all failure modes within the functional group} + +For FMMD failure mode analysis, we need to consider the failure modes +from all the components in the functional group as a flat set. +This can be found by applying function $FM$ to all the components +in the functional~group and taking the union of them thus: + +$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} FM(C_j) $$ + +We can actually overload the notation for the function FM +and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: + +\begin{equation} +FM : FG \mapsto \mathcal{F} +\end{equation} + +Applied to the functional~group $FG$ in the example above: +\begin{equation} + FM(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \} +\end{equation} + +This can be seen as all the failure modes that can affect the failure mode group $FG$. + +\subsection{Analysis of the functional group failure modes} + +For this example we shall consider single failure modes. +%For each of the failure modes from $FM(FG)$ we shall +%create a test case ($fgfm_i$). Next each test case is examined/analysed +%and its effect on the functional group determined. + +\par +%\vspace{0.3cm} +\begin{table}[h] +\begin{tabular}{||c|c|c|c||} \hline \hline + {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\ + {\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline +% +$a\_1$ & $fs\_1$ & $fgfm_{1}$ & SP2 \\ \hline +$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline +$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline +$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline +$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline +$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\ \hline +$c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline +% + \hline +\end{tabular} +\caption{Component to functional group to failure symptoms example} +\label{tab:fexsymptoms} +\end{table} +%\vspace{0.3cm} + +Table~\ref{tab:fexsymptoms} shows the analysis process. +As we are only looking at single fault possibilities for this example each failure mode +is represented by a test~case. +The Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}. +The test cases are analysed w.r.t. the functional~group. +These become functional~group~failure~modes ($fgfm$'s). +The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. + +For the sake of example, let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ to be +identical from the perspective of the functional~group. +That is to say, the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes +occur, is going to be the same. +For example, in our CD player example, this could mean the common symptom `no\_sound'. +No matter which component failure modes, or combinations thereof cause the problem, +the failure symptom is the same. +It may be of interest to the manufacturers and designers of the CD player why it failed, but +as far as we the users are concerned, it has only one symptom, +`no\_sound'! +We can thus group these component failure modes into a common symptom, $SP1$, thus +$ SP1 = \{fgfm_2, fgfm_4, fgfm_5\}$. +% These can then be joined to form a spider. +Likewise +let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. +Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}. + + +We have now in $SP1$, $SP2$ and $fgfm_6$ as 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$. +% +$$ SP = \{ SP1, SP2, fgfm_6 \} $$ +% +% +These three symptoms can be considered the set of failure modes for the functional~group, and +we can treat it as though it were a {\em black box} +or a {\em component} to be used in higher level designs. +% +The next stage of the process could be applied automatically. +Each common symptom becomes a failure mode of +a newly created derived component. Let $DC$ be the newly derived component. +This is assigned the failure modes that were derived from the functional~group. +We can thus apply the function $FM$ on this newly derived component thus: + +$$ FM(DC) = \{ SP1, SP2, fgfm_6 \} $$ + +Note that $fgfm_6$, while %being a failure mode has +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 in the derived component. +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!}! +The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). + + +\subsection{Defining the analysis process as a function} + +It is useful to define this analysis process as a function. +Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now +write + +$$ +\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent +$$ +% +%\begin{equation} +% \bowtie(FG_{cfm}) = DC +%\end{equation} +% +%or applying the function $FM$ to obtain the $FG_{cfm}$ set +% +Where DC is a derived component, and FG is a functional group: + +\begin{equation} + \bowtie(FM(FG)) = DC +\end{equation} + + +%The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour. +%The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' symbol, as in figure \ref{fig:gensubsys4} + +% \begin{figure}[h+] +% \centering +% \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg} +% % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 +% \label{fig:gensubsys3} +% \caption{Deriving a new diagram} + + +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. + diff --git a/symptom_ex_process/sx.tex b/symptom_ex_process/sx.tex new file mode 100644 index 0000000..df06ffc --- /dev/null +++ b/symptom_ex_process/sx.tex @@ -0,0 +1,21 @@ + +\ifthenelse {\boolean{paper}} +{ +\input{abstract} +\input{fmmd} +} +{ +\input{introducion} +} + +\input{topbot} + +\input{sys_abs} + +\input{process} + +\input{algorithm} + +\vspace{40pt} +\today + diff --git a/symptom_ex_process/sys_abs.tex b/symptom_ex_process/sys_abs.tex new file mode 100644 index 0000000..6e2cfc2 --- /dev/null +++ b/symptom_ex_process/sys_abs.tex @@ -0,0 +1,261 @@ +ection{The Symptom abstraction Process} + +% TO DO: separate these two: + +\paragraph{Symptom Extraction Described} + +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 +with its own set of failure modes. + +\paragraph{FMEA applied to the Functional Group} +As the functional~group is a set of components, the failure~modes +that we have to consider are all the failure modes of its components. +Each failure mode (or combination of) investigated is termed a `test case'. +Each `test case' is analysed. +% +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 reacts +to each of the test case conditions. +The goal of the process is to produce a set of failure modes from the perspective of the functional~group. + + + + +\paragraph{Symptom Identification} +When all `test~cases' have been analysed, a second phase is applied. +% +This looks at the results of the `test~cases' as symptoms +of the 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. +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$ ! + + + + +\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 +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. +\ref{requirement at the start} + + +\section{The Process : To analyse a base level Derived~Component/sub-system} + +To sumarise: + +\begin{itemize} + \item Determine a minimal functional group + \item Obtain the list of components in the functional group + \item Collect the failure modes for each component +% \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 Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group + \item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use. +Determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider'). + \item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component. + \item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component. +\end{itemize} + + + + +\section{A general derived Component/Sub-System example} + +Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. + +$$ FG = \{ C_1 , C_2 , C_3 \} $$ + +Each component has a set of related fault modes (i.e. ways in which it can fail to operate correctly). +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} +}. + +To re-cap from the definitions chapter \ref{chap:definitions}. + +Let the set of all possible components be $\mathcal{C}$ +and let the set of all possible failure modes be $\mathcal{F}$. + +We can define a function $FM$ + +\begin{equation} +FM : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} +\end{equation} + +defined by (where $C$ is a component and $F$ is a set of failure modes): + +$$ FM ( C ) = F $$ + +%\\ + +And for this example: + +$$ FM(C_1) = \{ a_1, a_2, a_3 \} $$ +$$ FM(C_2) = \{ b_1, b_2 \} $$ +$$ FM(C_3) = \{ c_1, c_2 \} $$ + + +\paragraph{Finding all failure modes within the functional group} + +For FMMD failure mode analysis, we need to consider the failure modes +from all the components in the functional group as a flat set. +This can be found by applying function $FM$ to all the components +in the functional~group and taking the union of them thus: + +$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} FM(C_j) $$ + +We can actually overload the notation for the function FM +and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: + +\begin{equation} +FM : FG \mapsto \mathcal{F} +\end{equation} + +Applied to the functional~group $FG$ in the example above: +\begin{equation} + FM(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \} +\end{equation} + +This can be seen as all the failure modes that can affect the failure mode group $FG$. + +\subsection{Analysis of the functional group failure modes} + +For this example we shall consider single failure modes. +%For each of the failure modes from $FM(FG)$ we shall +%create a test case ($fgfm_i$). Next each test case is examined/analysed +%and its effect on the functional group determined. + +\par +%\vspace{0.3cm} +\begin{table}[h] +\begin{tabular}{||c|c|c|c||} \hline \hline + {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\ + {\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline +% +$a\_1$ & $fs\_1$ & $fgfm_{1}$ & SP2 \\ \hline +$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline +$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline +$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline +$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline +$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\ \hline +$c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline +% + \hline +\end{tabular} +\caption{Component to functional group to failure symptoms example} +\label{tab:fexsymptoms} +\end{table} +%\vspace{0.3cm} + +Table~\ref{tab:fexsymptoms} shows the analysis process. +As we are only looking at single fault possibilities for this example each failure mode +is represented by a test~case. +The Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}. +The test cases are analysed w.r.t. the functional~group. +These become functional~group~failure~modes ($fgfm$'s). +The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. + +For the sake of example, let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ to be +identical from the perspective of the functional~group. +That is to say, the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes +occur, is going to be the same. +For example, in our CD player example, this could mean the common symptom `no\_sound'. +No matter which component failure modes, or combinations thereof cause the problem, +the failure symptom is the same. +It may be of interest to the manufacturers and designers of the CD player why it failed, but +as far as we the users are concerned, it has only one symptom, +`no\_sound'! +We can thus group these component failure modes into a common symptom, $SP1$, thus +$ SP1 = \{fgfm_2, fgfm_4, fgfm_5\}$. +% These can then be joined to form a spider. +Likewise +let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. +Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}. + + +We have now in $SP1$, $SP2$ and $fgfm_6$ as 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$. +% +$$ SP = \{ SP1, SP2, fgfm_6 \} $$ +% +% +These three symptoms can be considered the set of failure modes for the functional~group, and +we can treat it as though it were a {\em black box} +or a {\em component} to be used in higher level designs. +% +The next stage of the process could be applied automatically. +Each common symptom becomes a failure mode of +a newly created derived component. Let $DC$ be the newly derived component. +This is assigned the failure modes that were derived from the functional~group. +We can thus apply the function $FM$ on this newly derived component thus: + +$$ FM(DC) = \{ SP1, SP2, fgfm_6 \} $$ + +Note that $fgfm_6$, while %being a failure mode has +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 in the derived component. +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!}! +The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). + + +\subsection{Defining the analysis process as a function} + +It is useful to define this analysis process as a function. +Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now +write + +$$ +\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent +$$ +% +%\begin{equation} +% \bowtie(FG_{cfm}) = DC +%\end{equation} +% +%or applying the function $FM$ to obtain the $FG_{cfm}$ set +% +Where DC is a derived component, and FG is a functional group: + +\begin{equation} + \bowtie(FM(FG)) = DC +\end{equation} + + +%The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour. +%The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' symbol, as in figure \ref{fig:gensubsys4} + +% \begin{figure}[h+] +% \centering +% \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg} +% % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 +% \label{fig:gensubsys3} +% \caption{Deriving a new diagram} + + +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. + + + + + diff --git a/symptom_ex_process/topbot.tex b/symptom_ex_process/topbot.tex new file mode 100644 index 0000000..076d86e --- /dev/null +++ b/symptom_ex_process/topbot.tex @@ -0,0 +1,167 @@ + +\section{Fault Finding and Failure Mode Analysis} + +\subsection{Static Analysis} + +In the field of safety critical engineering; to comply with +European Law a product must be certified under the approriate `EN' standard. +Typically environmental stress, EMC, electrical stressing, endurance tests, +software~inspections and project~management quality reviews are applied\cite{sccs}. + +Static testing is also applied. This is theoretical analysis of the design of the product from the safety +perspective. +Three main techniques are currently used, +Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis). +The FMMD technique is aimed primarily as design verification for +safety critical systems. +However, FMMD also provides the mathematical frame work +to assist in the production of these three results of static analysis. +From the model created by the FMMD technique, the three above failure mode +descriptions can be derived. + +\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. +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. +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. +Specific measurements +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 fault isolation/finding techniques are described in \ref{NETWORKDECOMPOSITION}. +\subsection{FMMD - Bottom~up Analysis} +The FMMD technique does not follow the `natural fault finding' or top down approach, +it instead works from the bottom up. +Starting with a collection of base~components that form +a simple functional group, the effect of all component error modes are +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. +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 +of the components. +%It also means that every component failure mode must at the very least be considered. + + +%{ +%The aims are +%\begin{itemize} +% \item To automate the process where possible +% \item To apply a documented trail for each analysis phase (determination of functional groups, and analysis of component failure modes on those groups) +% \item To use a modular approach so that analysed sub-systems can be re-used +% \item Automatically ensure no failure mode is unhandled +% \item To produce a data model from which FTA, FMEA and statistical failure models may be obtained automatically +%\end{itemize} +%} +% + +\subsection{Systems, functional groups, sub-systems and failure modes} + +It is helpful here to define some terms, `system', `functional~group', `component', `base~component' and `derived~component/sub-system'. +These are listed in table~\ref{tab:symexdef}. + +A System, is really any coherent entity that would be sold as a product. % safety critical product. +A sub-system is a system that is part of some larger system. +For instance a stereo amplifier separate is a sub-system. The +whole Sound System, consists perhaps of the following `sub-systems': +CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface. + +%Thinking like this is a top~down analysis approach +%and is the way in which FTA\cite{nucfta} analyses a System +%and breaks it down. + +A sub-system will be composed of components, which +may themselves be sub-systems. However each `component' +will have a fault/failure behaviour and it should +always be possible to obtain a set of failure modes +for each `component'. +%In FMMD terms a sub-system is a derived component. + +If we look at the sound system example, +the CD~player could fail in several distinct ways, +and this couldbe due to a large number of +component failure modes. +%no matter what has happened to it or has gone wrong inside it. + + +Using the reasoning that working from the bottom up forces the consideration of all possible +component failures (which can be missed in a top~down approach) +we are presented with a problem. Which initial collections of base components should we choose ? + +For instance in the CD~player example; to start at the bottom; we are presented with +a massive list of base~components, resistors, motors, user~switches, laser~diodes, all sorts ! +Clearly, working from the bottom~up, we need to pick small +collections of components that work together in some way. +These are termed `functional~groups'. For instance the circuitry that powers the laser diode +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. + + +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 +to perform a specific function. + +When we have analysed the fault behaviour of a functional group, we can treat it as a `black box'. +The fault behaviour will consist of a set of `symptoms' caused by combinations +of the component failure modes. +We can make a new `component' derived from the functional~group. +The symptoms are the failure modes of this new `derived component'. + +%We can now call our functional~group a sub-system or a derived~component. +%The goal here is to know how it will behave under fault conditions ! +%Imagine buying one such `sub~system' from a very honest vendor. +%One of those sir, yes but be warned it may fail in these distinct ways, here +%in the honest data sheet the set of failure modes is listed! + + +%This type of thinking is starting to become more commonplace in product literature, with the emergence +%of reliability safety standards such as IOC1508\cite{sccs},EN61508\cite{en61508}. +%FIT (Failure in Time - expected number of failures per billion hours of operation) values +%are published for some micro-controllers. A micro~controller +%is a complex sub-system in its self and could be considered a `black~box' with a given reliability. +%\footnote{Microchip sources give an FIT of 4 for their PIC18 series micro~controllers\cite{microchip}, The DOD +%1991 reliability manual\cite{mil1991} applies a FIT of 100 for this generic type of component} + +Electrical components have detailed datasheets associated with them. A useful extension of this could +be failure modes of the component, with environmental factors and MTTF statistics. +Currently this sort of failure mode information is generally only available for generic component types\cite{mil1991}. + + +%At higher levels of analysis, functional~groups are pre-analysed sub-systems that interact to +%erform a given function. + +%\vspace{0.3cm} +\begin{table}[h] +\center +\begin{tabular}{||l|l||} \hline \hline + {\em Definition } & {\em Description} \\ \hline +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 \\ + & from derived components \\ \hline +Failure mode & A way in which a System, \\ + & Sub-system or component can fail \\ \hline +Functional Group & A collection of sub-systems and/or \\ + & components that interact to \\ + & perform a specific function \\ \hline +Base Component & Any bought in component, which \\ + & hopefully has a known set of failure modes \\ \hline + \hline +\end{tabular} +\caption{Symptom Extraction Definitions} +\label{tab:symexdef} +\end{table} +%\vspace{0.3cm} +