%\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. Thus, it can be treated as a component with a known set of failure modes. \paragraph{Enumerating abstraction levels} We can assign an attribute of abstraction level $\alpha$ to components, 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. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Algorithmic Description of Symptom Abstraction} %\clearpage $$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$ \begin{algorithm}[h+] \caption{Derive new `Component' 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 methodology 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. %\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. Thus its domain is the set of all components $\mathcal{C}$ and its range is the powerset of all failure modes $\mathcal{P}\,\mathcal{F}$. $$ fm : \mathcal{C} \rightarrow \mathcal{P}\,\mathcal{F} $$ A {\fg} is a collection of components such that $\mathcal{FG} \in \mathcal{P}\,\mathcal{C}$. The function $fm$ can be overloaded with a functional group $\mathcal{FG}$ as its domain and the powerset of all failure modes as its range. $$ fm: \mathcal{FG} \rightarrow \mathcal{P}\,\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 %%% % %%%- %%%- A such that B is C %%%- % % %\begin{algorithm}[h+] % ~\label{alg1} %\caption{Determine Failure Modes: fm( $FG$ )} \label{alg11} %\begin{algorithmic}[1] %\REQUIRE {FG is a non empty set of components i.e. $ FG \in \mathcal{P}\,\mathcal{C} \wedge FG \neq \emptyset $. } %\REQUIRE {Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; \big( fm(c) \neq \emptyset \big)$.} % %%\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 { $ F := \emptyset $ } \COMMENT{Clear the set of failure modes} %\FORALL { $c \in FG $ } %\STATE { $F:= F \cup fm(c)$ } \COMMENT{Collect the failure modes from the component `c' and append them to $F$ } %\ENDFOR % %\COMMENT {$F=fm(FG)$ is the 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 can be formed from single failure modes or failure modes in combination. Let $\mathcal{TC}$ be the set of all test cases, $\mathcal{F}$ be the set of all failure modes. %(associated with the functional group $FG$). $$ dtc: \mathcal{F} \rightarrow \mathcal{TC} $$ given by $$ dtc(F) = TC $$ The function \textbf{chosen} means that the failure modes for a particular test case have been chosen by a human operator and are additional to those chosen by the automated process (i.e they are special case test cases involving multiple failure modes) The function \textbf{unitarystate} means that all test cases can have no pairs of failure modes sourced from the component. This is discussed in section \ref{unitarystate}. %% %% Algorithm 2 %% %% %% Maybe need to iterate through each failure mode, adding a new test case %% this would build up all single fault test cases. %% \begin{algorithm}[h+] ~\label{alg2} \caption{Determine Test Cases: dtc: (F) } \label{alg22} \begin{algorithmic}[1] \REQUIRE {F is a non empty flat set of failure modes } \STATE { All test cases are chosen by the investigating engineer(s). Typically all single component failures are investigated with some specially selected combination faults} \STATE { Let $TC$ be the 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} \STATE { $ TC := \emptyset $ } \COMMENT{Initialise set of test cases} \STATE { $ j := 1 $ } \COMMENT{Initialise index of test cases} \FORALL { $ f \in F $ } \STATE{$ tc_j := f $} \COMMENT{ Assign one test case per single fault mode } \STATE{ $ j := j + 1 $} \ENDFOR %\STATE { Let $ptc$ be a provisional test case } \COMMENT{ Determine Test cases with simultaneous failure modes } \IF{DoubleFaultChecking} %\STATE { Let $ptc$ be a provisional test case } \FORALL { $ f1,f2 \in F $ } \STATE { $ ptc := \{ f1,f2 \} $ } \COMMENT{Make $ptc$ a provisional test case} %\STATE { FINDING ERRORS IN LATEX SOURCE IS FUCKING ANNOYING} % ESCPECIALLY IN THIS FUCKING ENVIRONMENT 22OCT2010 %% OK maybe you can't have comments after IF: half an hour wasted... \IF { $ {isunitarystate}(ptc) $ } % \COMMENT{Ensure the chosen failure mode set is unitary state compliant} \STATE{ $ j := j + 1 $} % latex bug hunt game what fun ! #2 \STATE { $ tc_j := ptc $} \STATE { $ TC := TC \cup tc_j $ } \ENDIF \ENDFOR \ENDIF \FORALL { $ ptc \in \mathcal{P}(F) $ } %%\mathcal{P} F $ } %%\STATE { $ ptc \in \mathcal{P} F $ } \COMMENT{Make a provisional test case} \IF { ${chosen}(ptc) \wedge ptc \not\in TC \wedge {isunitarystate}(ptc)$ } %%% \COMMENT{IF this combination of faults is chosen as an additional Test case include it in TC} \STATE{ $ j := j + 1 $} % latex bug hunt game #1 \STATE { $ tc_j := ptc $} \STATE { $ TC := TC \cup tc_j $ } \ENDIF \ENDFOR %\FORALL { $tc_j \in TC$ } %\ENSURE {$ tc_j \in \bigcap FG_{cfm} $} % % Lone commoents like the one below causing incredibly annoying very difficult to trace errors: cunt %\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 % % \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 % \ENSURE { $ \forall j1,j2 \in J \; such\; that\; j1 \neq j2 \big( tc_{j1} \neq tc_{j2} \big) $} \ENSURE { $ \forall tc \in TC \big( tc \in \mathcal{P}(F) \big) $ } \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 $\mathcal{R}$ be the set of all test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$). $$ atc: \mathcal{TC} \rightarrow \mathcal{R} $$ 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 \rightarrow 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} \FORALL { Environmental and Specific 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 \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 how the failure modes in each test case will affect the functional~group. % When the all the test cases have been anaslysed we will have a `result' for each `test case'. Each result will be described w.r.t. to the {\fg}, not the components failure modes in its test case. % %In the case of a simple %electronic circuit, we could calculate the effect on voltages %within the circuit given a certain component failure mode, for instance. %% % Thus we will have a set of results corresponding to our test cases. These share a common index value ($j$ in the algorithm description). These results 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 $\mathcal{SP}$ be the set of all symptoms, and $\mathcal{R}$ be the set of all test case results. $$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{$Let \; sp_l \in \mathcal{P} R$ such that R is in a common symptom group } \COMMENT{determine 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} This 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 $$ The new component will have a set of failure modes that correspond to the common symptoms collected from the $FG$. %\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} The function $cdc$ 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. \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 failure modes goes down for each level. \subsection{Traceable Fault Modes} Because the fault modes are determined from the bottom-up, the causes for all high level faults naturally form trees. These trees can be traversed to produce 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. %%%\section{Example Symptom Extraction} %% There already is an example of the process before the algorithmic description %%%This is a simplified version of the pt100 example in chapter \ref{pt100}. \vspace{40pt} %\today