\chapter{Algorithmic Description of FMMD} %\label{sec:symptom_abstraction} \label{sec:algorithmfmmd} This appendix formalises the process for performing one stage of the FMMD process %i.e. from a given {\fg} to creating a {\dc}. % The FMMD process is then examined in greater %levels of detail and described with set theory in an algorithmic context. % The intention for defining FMMD in algorithmic and set theoretic terms is to provide a solid specification for the process that could guide a software implementation.% for it. %\glossary{name={entry name}, description={entry description}} \nocite{safeware} \section{Overview of the FMMD analysis process} The FMMD process is described in chapter~\ref{sec:chap4}. To re-cap, FMMD has four main stages: \begin{itemize} \item collection of components to form {\fgs}, \item applying FMEA to the {\fgs}, \item collecting common symptoms from the FMEA results, \item creating a {\dc} modelling the failure mode behaviour of the {\fg}. \end{itemize} % \fmmdgloss %This is termed `symptom~abstraction'. % TO DO: separate these two: % % \paragraph{FMMD analysis Objective.} % The objective of `symptom abstraction' is to analyse the functional~group and find % how it can fail % when specified components within it fail. % Once we know how a functional~group can fail, we can treat it as a component or sub-system % with its own set of failure modes. % Once the failure symptoms for a {\fg} are known, the {\fg} can be treated as a component or sub-system % with its own set of failure modes. This process allows us to modularise and thus simplify FMEA analysis of systems. % %We later add another step to this process, that of defining the combinations of {\fms} considered for each FMEA %scenario. %The FMMD process stages are expanded upon %below. \paragraph{FMEA applied to the {\fg}: choosing test~cases.} As a {\fg} is a collection of components, the failure~modes to consider are the failure modes of its components. %, as %developed in the function definition $fm : \;\mathcal{G} \rightarrow \mathcal{F}$. %The aim here is to build `test cases', Single {\fms} or combinations are used to create failure~mode analysis scenarios, or test cases. %Each failure mode (or combination of) investigated is termed a `test case'. %Each `test case' is analysed. % The component failure modes in each test case are examined with respect to their effect on the {\fg} (in contrast, traditional FMEA examines each component failure modes effect on a whole system). % The aim of FMMD analysis is to find out how the {\fg} fails given each test case. % %The goal of the process is to produce a set of failure modes from the perspective of the user of the {\fg}. % %In other words, if a designer has a previously analysed module to use, he/she need not be concerned with %the failure modes of its components: it is handled it as a derived component, %which has its own FMMD defined set of failure modes. % symptoms. % %The designer can now treat this module as a black box (i.e. as a {\dc}). \fmmdgloss \paragraph{Environmental Conditions or Operational States.} % Each test case must also be considered for all %applied/ operational states and %in the for the case of each applied states or environmental conditions to which it may be exposed. In this way, all possible failure mode behaviour, due to all the conditions that can be applied for all the test~cases will be examined. % \paragraph{Symptom Identification.} When all test~cases have been analysed, a set of FMEA results exists for the given {\fg}. % applied. These results can be viewed as symptoms of failure of the {\fg}. % %This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but of the {\fg}/sub-system. %Single component failures (or combinations) within the functional~group may cause unique symptoms. %However, m %Many failures, when looked at from the perspective of the {\fg}, will have the same symptoms. %These can be collected as `common symptoms'. % %To go back to the CD~player example from section~\ref{sec:cdplayer}, a failed %output stage, and a failed internal audio amplifier, %will both cause the same failure symptom; $no\_sound$ ! \paragraph{Collection of Symptoms.} \fmmdgloss %Looking at the % examining failure from the % functional group perspective failure modes, we collect % some of these into common `symptoms' where possible. % % % Some test cases may cause % unique failure modes at the functional group level. These can be termed % lone symptoms. % % % The common symptoms of failure and lone~symptoms are identified and collected. % % % We can now create a new component and consider the symptoms as its failure modes. Common symptoms of failure of the {\fg} are collected. % A new component is created to represent the {\fg} and the aggregated symptoms considered as its failure modes. % This new component is called a `{\dc}'. % %Note that here, b Because the FMMD process is bottom up, it can be ensured that all failure modes from the components in a {\fg} have been considered. %\footnote{Software can check that all failure modes have been included in at least one test case, and modelled individually. For Double %Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well.}. % Were failure~modes to be missed, the resulting failure mode model would be %dangerously incomplete. % It is possible here for an automated system to flag un-handled failure modes. %which solves the main failing of top~down methodologies %\cite{topdownmiss}, %that of not %guaranteeing to model all component failure modes. %\ref{requirement at the start} \section{Expanding on a single stage of the FMMD process} %\paragraph{To analyse a base level Derived~Component/sub-system} The expanded FMMD process can now be described in five steps: \fmmdgloss \begin{enumerate} \item Choose a set of components to form a {\fg}, and collect the failure modes of each component in the {\fg} into a flat set. %% COLLECT FAILURE MODES \item Choose all single instances (and optional selected combinations\footnote{ %% DETERMINE TEST CASES Some specific combinations of failure modes might be included. For instance where a very reliable part is duplicated but very critical, like the 4 engines on a 747 aircraft.}) of the failure modes to form `test~cases'. % \item If required, create test cases from all valid double failure mode combinations within the {\fg}. % \item Draw these as contours on a diagram % \item Where simultaneous failures are examined use overlapping contours % \item For each region on the diagram, make a test case \item Using the `test cases' as scenarios to examine the effects of component failures, %% APPLY FMEA the failure~mode behaviour of the {\fg} is determined. % This is a human process, applying FMEA for each test case. % Where specific environmental conditions, or operational states are germane to the {\fg}, these must also be examined for each test case. % \item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the {\fg}}. %% COLLECT COMMON SYMPTOMS % \item The common~symptoms are now the fault mode behaviour of the {\fg}. %% CREATE DC i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail. % A new `{\dc}' can now be created where each common~symptom, or lone symptom, is a failure~mode of this new component. \end{enumerate} \subsection{Single stage of FMMD described as a `symptom~abstraction~process'} \fmmdglossSA A single stage of FMMD analysis can be described as symptom abstraction. % This is because the failure modes of a {\dc} are at a higher---or meta/more~abstract level---than the component failure modes it was derived from. %we take a {\fg} and from its component failure modes and FMEA analysis, derive symptom of failure. %symptoms of failure derived. % %These derived failure mode, failure modes of the {\fg} considered as an entity or component, are abstract %or at a higher level in the systems modular hierarchy. %To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}. The FMMD process is now described introducing set theoretical definitions % formal definitions that will be used in the algorithmic description of FMMD. %below. % Let the set of all possible components be $\mathcal{C}$ and let the set of all possible failure modes be $\mathcal{F}$ and $\mathcal{P}$ the powerset. \fmmdgloss The function $fm$ is defined which returns the failure modes for a given component (see section~\ref{sec:formal7}): \begin{equation} {fm} : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F} . \end{equation} %defined by (where $C$ is a component and $F$ is a set of failure modes): %$$ fm ( C ) = F $$ The notation for the function $fm$ is overloaded and defined for the set of components within a {\fg} $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: \begin{equation} fm : FG \rightarrow \mathcal{F} . \end{equation} Where $\mathcal{FG}$ is the set of all sets of {\fgs}, and $\mathcal{DC}$ is the set of all derived components, the symptom abstraction process is defined thus: $$ %\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent \derivec : \mathcal{FG} \rightarrow \mathcal{DC} . $$ \fmmdglossSA %The next section describes the details of the symptom abstraction process. } %\section{A Formal Algorithmic Description of `Symptom Abstraction'} \section{Algorithmic Description of Symptom Abstraction} %\section{Algorithmic Description} \label{sec:symptomabs} The algorithm for {\em symptom abstraction} is described in this section %describes the symptom abstraction process using set theory and procedural descriptions. % %The {\em symptom abstraction process} (given the symbol `$\derivec$', D for derive) takes a {\fg} $FG$ %and a new 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 from which it was derived. % %Thus, ke % $DC$ can now be treated % as a component with a known set of failure modes. %\ForAll { $c \in FG $ } \Comment{Find the highest abstraction level of any component in the functional group} % \IF{$c.\abslev > \abslev_{max}$} % $\abslev_{max} = c.\abslev$ % \ENDIF %\State { $ FM(c) \in FG_{cfm} $ } \Comment {Collect all failure modes from each component into the set $FM_{cfm}$} %\EndFor % By defining the process and describing it using set theory, constraints and verification checks %in the process can be stated formally. % The algorithm, represented by the symbol `$\derivec$', is described using five algorithmic steps below. %These are described using the Algorithm environment in the next section \ref{algorithms}. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % As a function $\derivec$ has the following signature: % % % %\clearpage % $$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} .$$ \fmmdglossSA \begin{algorithm} \caption{Derive new `Component' $DC$ from a given {\fg} $FG$: $\derivec(FG)$} \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 giving a set of test cases $TC$ } %to apply to the functional group } \State {R = atc (TC)} \Comment{ analyse the test cases giving a set of FMEA results $R$}%, for failure mode behaviour of the functional~group } \State {SP = fcs (R)} \Comment{ find common symptoms, aggregate results from R giving a set of symptoms $SP$}%of failure for the functional group } \State {DC = cdc (SP)} \Comment{ create a derived component } \State \textbf{return} $DC$ \end{algorithmic} \label{alg66} \end{algorithm} \fmmdglossSA The symptom abstraction process allows us to take a {\fg} of components, analyse the failure mode behaviour and create a new entity, a {\dc} 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. % \fmmdgloss %\clearpage \subsection{Determine Failure Modes to Examine} \fmodegloss The first stage is to find the failure modes to consider for analysis, using the earlier definition of the function $fm$ applied to all components within the given {\fg}. % % 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 $G$ such that $\mathcal{G} \in \mathcal{P}\,\mathcal{C}$. % % % The function $fm$ can be overloaded with a {\fg} $\mathcal{G}$ as its domain % and the power-set of all failure modes as its range. % % % % % $$ fm: \mathcal{G} \rightarrow \mathcal{P}\,\mathcal{F} $$ % % % % % % %The next task is to formulate `test~cases'. These are a collection of combinations of these {\fms} and will be used %in the analysis stages. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %\clearpage \subsection{ Determine Test Cases} From the failure modes associated with the functional~group, test cases must next be determined. %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$). The function $dtc$ is defined thus: % $$ dtc: \mathcal{F} \rightarrow \mathcal{TC}, $$ % given by % $$ dtc(F) = TC. $$ % In algorithm \ref{alg22}, 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 test~cases involving multiple failure modes). % \fmmdglossMUTEX % The function \textbf{isunitarystate} takes as its argument a test~case and returns true if no pairs of that test~case's failure modes are sourced from the same component (see section~\ref{sec:unitarystate}). % In other words, this function tests that {\fms} in test~cases only use {\fms} that are mutually exclusive within components. % \label{sec:completetest} % The $dtc$ function enforces completeness in the model by ensuring that %for all failure modes in components in the {\fg} are included in at least one test~case. % % %% % %{ \footnotesize \begin{algorithm}[h+] \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 a set of test cases } \Comment {this set is used to collect the test cases} \State { Let $tc_j$ be a set of component failure modes where $j$ is an index of $J$} \Comment { Each set $tc_j$ is a `test~case' and $TC = \bigcup_{j \in J} \{tc_j\}$ where $J \subset \mathbb{N}_{+}$ } \State { $ TC := \emptyset $ } \Comment{Initialise set of test cases} \State { $ j := 1 $ } \Comment{Initialise index of test cases} \ForAll { $ f \in F $ } \Comment{ Assign one test case per single fault mode } \State{$ tc_j := f $} \State { $ TC := TC \cup tc_j $ } \Comment{ place this test case into the set TC } \State{ $ j := j + 1 $} \EndFor %\State { Let $ptc$ be a provisional test case } \Comment{ Determine Test cases with simultaneous failure modes } \If{DoubleFaultChecking = TRUE} \Comment{ Assign one test case per valid double fault mode } %\State { Let $ptc$ be a provisional test case } \ForAll { $ f_1,f_2 \in F $ } \State { $ ptc := \{ f_1,f_2 \} $ } \Comment{Make $ptc$ a provisional test case} %\State { FINDING ERRORS IN LATEX SOURCE IS challenging} % ESCPECIALLY IN THIS 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 $ } \Comment{ place this test case into the set TC } \EndIf \EndFor \EndIf % \ForAll { $ ptc \in \mathcal{P}(F) $ } \Comment{for all subsets of F} %%\mathcal{P} F $ } % \State { $ ptc \in \mathcal{P} F $ } \Comment{Make $ptc$ a provisional test case} \If { ${chosen}(ptc) \wedge ptc \not\in TC \wedge {isunitarystate}(ptc)$ } \State{ $ j := j + 1 $} % latex bug hunt game #1 \State { $ tc_j := ptc $} \State { $ TC := TC \cup tc_j $ } \EndIf \EndFor % %\algstore %\algrestore % \algstore{myalg} \end{algorithmic} \end{algorithm} \clearpage % %Algorithm~\ref{alg22} continued below. % \begin{algorithm} \begin{algorithmic} [1] \algrestore{myalg} \Ensure { $ \forall j_1,j_2 \in J \; such\; that\; j_1 \neq j_2 \big( tc_{j_1} \neq tc_{j_2} \big) $} \Comment{Ensure test cases are distinct} \Ensure { $ \forall tc \in TC \big( tc \in \mathcal{P}(F) \big) $ } \Comment{Ensure each test case is a subset of F} % \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 { Check that at each single failure mode in the {\fg} is included as a test case.} %\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 \wedge f2) \not\in (\forall c) \;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) \wedge ({DoubleFaultChecking} = TRUE)$ } \Comment { If ${DoubleFaultChecking}$ is required, check that all possible double failure modes in the {\fg} (see section~\ref{sec:unitarystate}) are included as a test cases.} \State \textbf{return} $TC$ \end{algorithmic} \end{algorithm} %} % end footnotesize % 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 {\fg}. % Double failure mode checking has been included in this algorithm specifically because of the double failure mode implications of European standard EN298~\cite{en298}. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %\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}$). The function $atc$ is defined thus: $$ 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 { define the function $Analyse : tc \rightarrow r $ } \Comment { This analysis is a human activity, FMEA, i.e. examining the component 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$ } \ForAll { Environmental and Specific Applied States } \State { $ rc_j = Analyse(tc_j) $} \Comment {this is FMEA applied in the localised context of the {\fg}} %\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 \State \textbf{return} $R$ %\hline \end{algorithmic} \end{algorithm} Algorithm \ref{alg33} has built the set $R$, the sub-system/{\fg} results for each test case. The analysis is primarily a human activity. % %Each test case is examined in detail. % % Calculations or simulations are performed to determine how the failure modes in each test case will affect the functional~group. % Ideally field data and/or formal physical testing should be used in addition to static failure mode reasoning where possible. % When all the test cases have been analysed, a `result' will exist for each `test case'. % Each result will be described from the perspective of %{\wrt} to the {\fg}, not the members of it i.e. 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. %% % A set of results corresponding to our test cases is now available. % These share a common index value ($j$ in the algorithm description). % These results are the failure modes of the {\fg}. % \fmmdgloss %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, results which have a common failure symptom from the perspective of the operation of the {\fg}. % Let set $\mathcal{SP}$ be the set of all symptoms, and $\mathcal{R}$ be the set of all test case results. % The function $fcs$ is defined thus: % $$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, $\abslev$ (see section~\ref{sec:alpha}). The failures have now been considered not from the component level, but from the sub-system or functional~group level. A set $SP$, the symptoms of failure is obtained. % \ifthenelse {\boolean{paper}} { Component failure modes must be mutually exclusive. \fmmdglossMUTEX 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. } { Ensuring that no result belongs to more than one symptom set enforces the `unitary state failure mode constraint' for derived components (see section~\ref{sec:unitarystate}). } \fmmdgloss %% 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 {\fgs} at higher levels of fault abstraction. Let $DC$ be a derived component with its own set of failure~modes. The function $cdc$ is defined thus: $$ 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. A derived~component $DC$, which has its own set of failure~modes has been created. % 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. \paragraph{Enumerating abstraction levels.} \label{sec:abstractionlevel} % As described in section~\ref{sec:alpha} the attribute of abstraction level $\abslev$ can be assigned to components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$). % For a base component, let the abstraction level be zero. % The symptom abstraction process is applied giving a $\dc$, this derived~component will have an $\abslev$ value one higher than the highest $\abslev$ value of any of the components in the {\fg} used to derive it. % Thus a derived component sourced from base components will have an $\abslev$ value of 1. % The attribute $\abslev$ 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 {\fgs}, a hierarchy is naturally formed with the abstraction levels increasing with each tier. % \fmmdgloss \subsection{Hierarchical Simplification} Since symptom abstraction aggregates fault modes, the number of faults to handle should decrease 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. To go back to the sound system analogy (see section~\ref{sec:cdplayer}), it may have 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: as is found in practise in real world systems. \subsection{Traceable Fault Modes} Since the fault modes are determined from the bottom-up, the causes for all high level faults naturally form trees. % That is to say from the bottom-up causes become symptoms, which in the next level become causes as the tree is traversed upwards. % This is demonstrated in the examples chapter~\ref{sec:chap5} where DAGS are drawn linking failure mode causes and symptoms in FMMD analysis hierarchies. % These trees can be also 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 Mean Time to Failure (MTTF) and Failure in Time(FIT)\cite{en61508} levels can be automatically calculated. \fmmdgloss %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %