%\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}_0$). 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$ 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, represented by the symbol `$\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{alg1} \caption{Determine Failure Modes: FM( $FG$ )} \label{alg11} \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{alg11} 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{alg2} \caption{Determine Test Cases: DTC: (F) } \label{alg22} \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$ represent 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$ represent 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{alg22} 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{alg3} \caption{Analyse Test Cases: ATC(TC) } \label{alg33} \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 \cup rc_j $ } \COMMENT{Add $rc_j$ to the set R} \ENDFOR \RETURN $R$ %\hline \end{algorithmic} \end{algorithm} Algorithm \ref{alg33} has built the set $R$, the sub-system/functional group results for each test case. The analysis is primarily a human activity. % Each test case is examined in detail. % % Ideally calculations or simulations are performed to determine the functional~group failure mode the test case failure modes will cause. % % In the case of a simple electronic circuit, we could calculate the effect on voltages within the circuit given certain component failure modes, for instance. The affect of these unusual volatges would then be a failure mode of the functional group and become the result of the test case. When each test case has been analysed, we have a set of results. These are the failure modes of the functional group. Once a functional group has been analysed, it can be re-used in any other design that uses it. Often safety critical designs have repeated sections (such as safety critical digital inputs or $4\rightarrow20mA$ inputs), and in this case the analysis would only need to be performed once. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \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. This stage collects results into `Symptom' sets. Each result from the preceding stage is examined and collected into common symptom sets. That is to say, each result in a symptom set, from the perspective of the functional group has the same failure symptom. Let set $SP$ be the family of symptom sets for the functional group $FG$. $$FCS: \mathcal{R} \rightarrow \mathcal{SP} $$ given by $$ FCS(R) = SP $$ \begin{algorithm}[h+] ~\label{alg4} \caption{Find Common Symptoms: FCS($R$)} \label{alg44} \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 the indexed `symptoms' $sp_l$} \COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system} \STATE{$SP := 0$} \COMMENT{ initialise the `symptom family set'} % %\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} \REPEAT \STATE{$sp_l := 0$} \COMMENT{ initialise the `symptom'} \STATE{$sp_l \in \mathcal{P} R$} \COMMENT{Select common symptoms from the results set} \STATE{$ R := R \backslash sp_l $} \COMMENT{remove the results used from the results set} \STATE{$ SP := SP \cup sp_l$} \COMMENT{collect the symptom into the symtom family set SP} \STATE{$ l := l + 1 $} \COMMENT{move the index up for the next symptom to collect} \UNTIL{ $ R = \emptyset $ } \COMMENT{continue until all results belong to a symptom} %% \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{alg44} raises the failure~mode abstraction level, $\alpha$. 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}} { 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, for the derived component created in the next stage. } { Note ensuring that no result belongs to more than one symptom set enforces the `unitary state failure mode constraint' for derived components. } %% Interesting to draw a graph here. %% starting with components, branching out to failure modes, then those being combined to %% test cases, the test cases producing results, and then the results collected into %% symptoms. %% the new component then gets the symptoms as failure modes. %% must be drawn !!!!! %% 04AUG2010 ~~~~ A27 refugee !!! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \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{alg5} \caption{Create Derived Component: CDC(SP) } \label{alg55} \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 \cup 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{alg55} 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{Extract Symptoms from Functional Group: $\bowtie(FG)$} \label{alg66} \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 likelihood of the component failures, the MTTF and SIL\cite{en61508} levels can be automatically calculated. \vspace{40pt} %\today