%\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