diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex index 5ab8635..eabea67 100644 --- a/symptom_ex_process/algorithm.tex +++ b/symptom_ex_process/algorithm.tex @@ -61,7 +61,43 @@ The algorithm, represented by the symbol `$\bowtie$', has been broken down into By defining the process and describing it using set theory, constraints and verification checks in the process are stated formally. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\clearpage + + + +\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 @@ -69,46 +105,59 @@ 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}$. -The function $fm$ takes a functional group $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$. +$$ fm : \mathcal{C} \rightarrow \mathcal{P}\,\mathcal{F} $$ -$$ fm: \mathcal{FG} \rightarrow \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. -%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 -%% +$$ fm: \mathcal{FG} \rightarrow \mathcal{P}\,\mathcal{F} $$ -\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} - -\STATE { $ F := \emptyset $} \COMMENT{Clear the set of failure modes} -\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$ } -\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). +%%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. @@ -116,14 +165,16 @@ in the analysis stages. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\clearpage +%\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, which hold combinations of failure modes $F$ (associated with the functional group $FG$). +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} $$ @@ -131,6 +182,10 @@ 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 %% @@ -165,16 +220,17 @@ $$ dtc(F) = TC $$ \STATE{ $ j := j + 1 $} \ENDFOR - \STATE { Let $ptc$ be a provisional test case } \COMMENT{ Determine Test cases with simultaneous failure modes } + %\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 } + %\STATE { Let $ptc$ be a provisional test case } \FORALL { $ f1,f2 \in F $ } - \STATE { $ ptc := \{ f1,f2 \} $ } \COMMENT{Make a provisional test case} + \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 { $ \mathcal{ISUNITARYSTATE}(ptc) $ } % \COMMENT{Ensure the chosen failure mode set is unitary state compliant} + \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 $ } @@ -182,27 +238,23 @@ $$ dtc(F) = TC $$ \ENDFOR \ENDIF - - - - \FORALL { $ ptc \in \mathcal{P}(F) $ } %%\mathcal{P} F $ } %%\STATE { $ ptc \in \mathcal{P} F $ } \COMMENT{Make a provisional test case} - \IF { $\mathcal{CHOSEN}(ptc) \wedge ptc \not\in TC \wedge \mathcal{ISUNITARYSTATE}(ptc)$ } %%% \COMMENT{IF this combination of faults is chosen as an additional Test case include it in TC} + \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$ } + %\FORALL { $tc_j \in TC$ } %\ENSURE {$ tc_j \in \bigcap FG_{cfm} $} - \ENSURE {$ tc_j \in \mathcal{P}(F) $ } % \mathcal{P}(F)$} - \COMMENT { require that the test case is a member of the powerset of $F$ } + % + % 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 ) $} - \ENSURE { $\forall j1,j2 \in J \; such\; that\; tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 $} - \COMMENT { Test cases must be unique } - \ENDFOR + %\COMMENT { Test cases must be unique } + %\ENDFOR % % \IF{Single fault checking} % \STATE { let $f$ represent a component failure mode } @@ -224,6 +276,8 @@ $$ dtc(F) = TC $$ % 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} } @@ -239,9 +293,6 @@ The next stage is to analyse the effect of each test case on the functional grou - - - %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \clearpage \subsection{ Analyse Test Cases} @@ -249,9 +300,9 @@ The next stage is to analyse the effect of each test case on the functional grou %% 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}$). +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} $$A +$$ atc: \mathcal{TC} \rightarrow \mathcal{R} $$ given by $$ atc(TC) = R $$ @@ -283,27 +334,33 @@ 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. +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 certain component failure modes, for instance. -The affect of these unusual voltages 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. +%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. +%% -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. +% +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 +%\clearpage \subsection{ Find Common Symptoms} %% %% Algorithm 4 @@ -315,59 +372,61 @@ 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$. +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} +%\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} -\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$. +%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. @@ -412,62 +471,35 @@ given by $$ cdc(SP) = DC $$ -\begin{algorithm}[h+] - ~\label{alg5} +The new component will have a set of failure modes that correspond to the common symptoms collected from the $FG$. -\caption{Create Derived Component: cdc(SP) } \label{alg55} +%\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} -\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 +%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. - -\section{Linking all five stages} - -$$ \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. - \subsection{Hierarchical Simplification} Because symptom abstraction collects fault modes, the number of faults to handle decreases @@ -481,7 +513,7 @@ $$ 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. +But as the hierarchy goes up in abstraction level, the number of failure modes goes down for each level. \subsection{Traceable Fault Modes} @@ -492,6 +524,9 @@ 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 diff --git a/symptom_ex_process/algorithm.tex.old b/symptom_ex_process/algorithm.tex.old new file mode 100644 index 0000000..7c8fddd --- /dev/null +++ b/symptom_ex_process/algorithm.tex.old @@ -0,0 +1,532 @@ +%% +% +% +% OBSOLETE DO NOT EDIT. +% This is the one with the simple functions described as algorithms +% +%% 23OCT2010 +%% + +%\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. +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\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.e they are special case test cases involving multiple failure modes) +The function \textbf{unitarystate} means that the test case has 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} + \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 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} 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} \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. + +\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} + +This is a simplified version of the pt100 example in chapter \ref{pt100}. + + + +\vspace{40pt} +%\today +