%\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} We can assign an attribute of abstraction level to components $\alpha$, where $\alpha$ is a natural number, ($\alpha \in \mathbb{N}$). 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. Thus a derived component sourced from base components will have an $\alpha$ value of 1. % %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. % %With a derived component $DC$ having an abstraction level The attribute $\alpha$ we can be used to track the level of fault abstraction of components in an FMMD hierarchy. Because base and derived components are collected to form functional groups, a hierarchy is naturally formed with the abstraction levels increasing with each tier. %\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group} % \IF{$c.\alpha > \alpha_{max}$} % $\alpha_{max} = c.\alpha$ % \ENDIF %\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$} %\ENDFOR The algorithm, representing the function $\bowtie$, has been broken down into five consecutive stages. 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. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %\clearpage \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': The function $FM$ applied to a component returns the failure modes for that component. The function $FM$ takes a flat set components $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$. $$ FM: \mathcal{FG} \rightarrow \mathcal{F}$$ %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$. given by $$FM(FG) = 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 (a functional~group)} \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} \FORALL { $c \in FG $ } \REQUIRE{ Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; such \; that\; FM(c) \neq \emptyset$ } \ENDFOR \STATE {let $F=FM(FG)$ be a set of all failure modes to consider for the functional~group $FG$} \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)$ (given that each component has a known set of failure~modes). The next task is to formulate `test cases'. These are a collection of combinations of these failure~modes and will be used in the analysis stages. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \clearpage \subsection{ 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 with the functional group $FG$. $$ DTC: \mathcal{F} \rightarrow \mathcal{TC} $$ given by $$ DTC(F) = 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 ) $} \ENSURE { $\forall j1,j2 \in J \; such\; that\; tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 $} \COMMENT { Test cases must be unique } \ENDFOR \IF{Single fault checking} \STATE { let $f$ represet a component failure mode } %\ENSURE { That all failure modes are represented in at least one test case } \ENSURE { $ \forall f \;such\;that\; (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} \ENDIF \IF{Double fault checking} \STATE { let $f1,f2$ represet a component failure modes, and $c$ any component in the functional group } %\ENSURE { That all failure modes are represented in at least one test case } \ENSURE { $ \forall f1,f2 \;where\; (f1,f2) \not\in c\;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) $ } \COMMENT { This corresponds to checking that each possible double failure mode is considered as a test case; more rigorous cardinality constraint checks may be required for some safety standards. Note if both failure modes in the check are sourced from the same component $c$ the test case is impossible under unitary state failure mode conditions} \ENDIF \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{ 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 test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$). $$ATC: \mathcal{TC} \rightarrow \mathcal{R} $$A given by $$ ATC(TC) = 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} \STATE{ $ R := R \cap rc_j $ } \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{ 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: \mathcal{R} \rightarrow \mathcal{SP} $$ given by $$ FCS(R) = 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 ) $} \ENSURE {$ \forall a \in sp_l \;such\;that\; \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. \ifthenelse {\boolean{paper}} { %CUNT VIM just went and wrote random shit did you not Component failure modes must be mutually exclusive. That is to say only one specific failure mode may be active at any time. This condition/property has been termed unitary state failure mode. Ensuring that no result belongs to more than one Symptom set, enforces this. } { Note ensuring that no result belongs to more than one symptom enforces unitary state failure mode constraint for derived components. } %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \clearpage \subsection{ 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: \mathcal{SP} \rightarrow \mathcal{DC} $$ given by $$ CDC(SP) = 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} \STATE { $DC := DC \cap f_l$ } \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes} \ENDFOR \ENSURE { $FM(DC) \neq \emptyset$ } \COMMENT{Ensure that DC has a known set of failure modes} \RETURN DC %\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 with other components (or derived~components) to form functional~groups at higher levels of failure~mode~abstraction. %Hierarchies of fault abstraction can be built that can model an entire SYSTEM. \section{Linking all five stages} $$ \bowtie: \mathcal{FG} \mapsto \mathcal{DC} $$ \begin{algorithm}[h+] \caption{$\bowtie(FG)$} \label{alg:sympabs66} \begin{algorithmic}[1] \STATE {F = FM (FG)} \COMMENT{ collect all component failure modes }%from the from the components in the functional~group } \STATE {TC = DTC (F)} \COMMENT{ determine all test cases } %to apply to the functional group } \STATE {R = ATC (TC)} \COMMENT{ analyse the test cases }%, for failure mode behaviour of the functional~group } \STATE {SP = FCS (R)} \COMMENT{ find common symptoms }%of failure for the functional group } \STATE {DC = CDC (SP)} \COMMENT{ create a derived component } \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 provides the analysis `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. NEED A GOOD REF HERE 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 component failure~modes 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. These trees can be traversed to produce minimal cut sets\cite{nasafta} or entire FTA trees\cite{nucfta}, and by analysing the statistical likelyhood of the component failures, the MTTF and SIL\cite{en61508} levels can be automatically calculated. \vspace{40pt} %\today