\chapter{Algorithmic Description of Symptom Abstraction} %\label{sec:symptom_abstraction} \label{sec:algorithmfmmd} This section uses algorithms and set theory to describe the process for analysing a {\fg} and determining from it a {\dc}. % \paragraph{Symptom Abstraction in brief} In essence, we take a {\fg} (a collection of components), and apply FMEA analysis locally on this {\fg}. % In this way, we determine how that {\fg} can fail. We can then go further and consider these to be symptoms of failure of the {\fg}. Because component failures will often manifest themselves as the same symptoms of failure, we are able to collect common symptoms of failure for the {\fg}. % % With the collected common symptoms, we can treat the {\fg} as a component in its own right. This new component, is derived from the {\fg}. In the field of safety engineering this derived component corresponds to a low~level sub-system. %The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint diagrams\cite{constraint} to model failure modes and failure mode common symptom collection. The technique is designed for making building blocks for a hierarchical fault model. % Once the failure modes have been determined for a sub-system/{\dc}, this {\dc} can be combined with others to form {\fgs} to model higher level sub-systems/{\dcs}. % In this way a hierarchy to represent the fault behaviour of a system can be built from the bottom~up. This process can continue until there is a complete hierarchy representing the failure mode behaviour of the entire system under analysis. %FMMD hierarchy Using the FMMD technique, the hierarchy is built from the bottom up to ensure complete failure mode coverage. Because the process is bottom-up, syntax checking and tracking can ensure that no component failure mode can be overlooked. Once a hierarchy is in place, it can be converted into a fault data model. \fmmdgloss % From the fault data model, automatic generation of FTA \cite{nasafta} (Fault Tree Analysis) and minimal cuts sets \cite{nucfta} are possible. Also statistical reliability/probability of failure~on~demand \cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced automatically\footnote{Where component failure mode statistics are available \cite{mil1991}}. % This chapter focuses on the process of converting {\fgs} to {\dcs}, or building the `blocks' of the FMMD hierarchy. We can term this stage in FMMD analysis as the `symptom extraction' process. The symptom extraction or abstraction process, is the key process in creating an FMMD hierarchy. } \vspace{40pt} %\today \subsection{Fault Finding and Failure Mode Analysis} % %\subsection{Static Analysis} % %In the field of safety critical engineering, to comply with %European Law, a product must be certified under the appropriate `EN' standard. %Typically environmental stress, EMC, electrical stressing, endurance tests, %software~inspections and project~management quality reviews are applied \cite{sccs}. % %Static testing is also applied. This is theoretical analysis of the design of the product from the safety %perspective. %% %Three main methodologies are currently used, %Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis). %The FMMD process is a static modelling methodology, aimed primarily for design verification of %safety critical systems. %% %However, FMMD also provides the mathematical framework %to assist in the production of the three traditional methods of static analysis. %From the model created by the FMMD methodology, statistical, FTA and FMEA models %can be derived. %FMMD can model electrical, mechanical and software failures using a common notation, %and can thus model an integrated electro-mechanical software controlled system. % \subsection{Top Down or Natural Trouble Shooting} It is interesting here to look at the `natural' trouble shooting process. Fault finding is instinctively performed from the top-down. A faulty piece of equipment is examined and will have a symptom or specific fault. % The suspected area or sub-system within the equipment will be looked into next. % The trouble shooter will look for behaviour that is unusual or incorrect to determine the next area or sub~system to look into, each time moving to a more detailed lower level. Specific measurements and checks will be made, and finally a component or a low level sub-system will be found to be faulty. A natural fault finding process is thus top~down. Top down formal fault isolation/finding techniques for electronics are described in \cite{maikowski}. %% %% to fool the graphics insertion to make it compatible %% with thesis and papaer level directories. %% %% ln -s . symptom_ex_process %% %% insert diagram here \begin{figure}[h] \centering \includegraphics[width=300pt,bb=0 0 587 445,keepaspectratio=true]{./CH4_FMMD/top_down_de_comp.png} % top_down_de_comp.jpg: 587x445 pixel, 72dpi, 20.71x15.70 cm, bb=0 0 587 445 \caption{Top Down Failure De-Composition Diagram} \label{fig:tdh} \end{figure} %% %% FMEA and FTA and safety engineering people used the term SUB_SYSTEM ALOT %% this study needs to use this term to keep the interested/in context. The term `sub-system' is typically used in top down methodologies. It has two equivalents in FMMD. Both {\fg} and {\dc} correspond to the top down concept of a `sub-system'. In FMMD a {\fg} becomes a {\dc} after analysis. The term sub-system will be used alongside both {\fg} and {\dc} where necessary. \subsection{Top-Down System De-Composition} A top down fault analysis system will take a system and divide it into several sub-systems, and determine the safety dependencies of the System on those sub-systems. In the case of large complicated systems, the sub-systems themselves may be broken down into simpler sub-systems. A top down hierarchy is shown in figure \ref{fig:tdh}. \subsection{FMMD - Bottom~up Analysis} The FMMD methodology does not follow the `natural fault finding' or top down approach, it instead works from the bottom up. Starting with a collection of base~components that form a simple functional group, the effect of all component error modes are examined, as to their effect on the functional group. % The effects on the functional group can then be collected as common symptoms, and now we may treat the functional group as a component, as it has a known set of failure modes. % By reusing the `components' derived from functional~groups, an entire hierarchical failure mode model of the system can be built. That is to say, using derived components in higher level functional groups, a hierarchy is naturally formed. % By working from the bottom up, we can trace all possible sources that could cause a particular mode of equipment failure. This means that at the design stage of a product all component failure modes must be considered. The aim here is for complete failure mode coverage. This also means that we can obtain statistical estimates based on the known reliabilities of components~\cite{mil1991}. %It also means that every component failure mode must at the very least be considered. %{ %The aims are %\begin{itemize} % \item To automate the process where possible % \item To apply a documented trail for each analysis phase (determination of functional groups, and analysis of component failure modes on those groups) % \item To use a modular approach so that analysed sub-systems can be re-used % \item Automatically ensure no failure mode is unhandled % \item To produce a data model from which FTA, FMEA and statistical failure models may be obtained automatically %\end{itemize} %} % %\vspace{0.3cm} % \begin{table}[h] % \center % \begin{tabular}{||l|l||} \hline \hline % {\em Definition } & {\em Description} \\ \hline % System & A product designed to \\ % & work as a coherent entity \\ \hline % Sub-system & A part of a system, \\ % -or- derived component & sub-systems may contain sub-systems. \\ % & derived~components may be derived \\ % & from derived components \\ % & Constraint: This object must have a defined set of failure~modes \\ \hline % Failure mode & A way in which a system, \\ % & sub-system or component can fail \\ \hline % Functional Group & A collection of sub-systems and/or \\ % & components that interact to \\ % & perform a specific function \\ \hline % Symptom & A failure mode of a functional group, caused by \\ % & a combination of its component failure modes \\ \hline % Base Component & Any bought in component, or \\ % & lowest level module/or part \\ % & Constraint: This object must have a defined set of failure~modes \\ \hline % \hline % \end{tabular} % \caption{Symptom Extraction Definitions} % \label{tab:symexdef} % \end{table} \fmodegloss \glossary{name={system}, description={A product designed to work as a coherent entity}} \glossary{name={sub-system}, description={A part of a system, sub-systems may contain sub-systems and so-on}} \glossary{name={derived component}, description={A theoretical component, derived from a collection of components (which may be derived components themselves)}} \glossary{name={functional group}, description={A collection of sub-systems and/or components that interact to perform a specific function}} \glossary{name={symptom}, description={A failure mode of a functional group (of components), caused by a combination of its component failure modes}} \glossary{name={base component}, description={Any bought in component, or lowest level module/or part}} %\glossary{name={entry name}, description={entry description}} \nocite{safeware} \section{Overview of Symptom Extraction Process} % TO DO: separate these two: \paragraph{Symptom Extraction 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. \paragraph{FMEA applied to the Functional Group.} As the functional~group contains a set of components, the failure~modes that we have to consider are all the failure modes of its components, as developed in the function definition $fm : \;\mathcal{FG} \rightarrow \mathcal{F}$. The aim here is to build `test cases', combinations of failure~modes to use as failure~mode analysis scenarios. %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 functional~group. % The aim of this analysis is to find out how the functional~group fails given the test case conditions, for each test case. The goal of the process is to produce a set of failure modes from the perspective of the user of the functional~group. % In other words, if a designer is handed a piece of circuitry to use, he need not be concerned with the failure modes of its components. He is handed it as a derived component, which has a set of failure mode symptoms. The designer can now treat this piece of circuitry as a black box, or {\dc}. \paragraph{Environmental Conditions or Applied States.} Each test case must 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 the test case conditions will be examined. As part of this analysis process, records must be kept detailing each test case result along with its resultant {\fg} failure mode. This data will be kept in the model and can be used to examine environmentally sourced common mode failure scenarios. %%- A {\fg} may, in the case of an electronic circuit have %%- applied states. For instance test modes, shutdown or lockout modes etc. %%- which are inputs to the circuit. %%- In this case each test case from the {\fg} must be analysed with %%- respect to all these states. %%- %%- A mechanical device may be required to work in different %%- temperature or pressure ranges for instance and its failure mode behaviour may %%- change due to enviromental factors. %%- \paragraph{Symptom Identification.} When all `test~cases' have been analysed, a second phase can be actioned. % applied. % 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, many failures, when looked at from the perspective of the functional group, will have the same symptoms. These can be collected as `common symptoms'. To go back to the CD~player example, a failed output stage, and a failed internal audio amplifier, will both cause the same failure; $no\_sound$ ! \paragraph{Collection of Symptoms.} Looking at the functional group perspective failure modes, we can collect some of these into common `symptoms'. 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 consider the functional~group as a component and the symptoms as its failure modes. Note that here, because the process is bottom up, we can ensure that all failure modes from the components in a functional~group have been handled\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 any failure~modes missed, the failure mode model could 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{The Process} \paragraph{To analyse a base level Derived~Component/sub-system} To summarise: \begin{itemize} \item Choose a set of components to form a functional group. % \item Obtain the list of components in the functional group \item Collect the failure modes of each component into a flat set. \item Choose all single instances (and optional selected combinations\footnote{ 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, we determine the failure~mode behaviour of the functional group. % This is a human process, involving detailed analysis of the component failure modes in the test case on the {\fg}. Where specific environment conditions, or applied states are germane to the {\fg}, these must 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 functional~group}. \item The common~symptoms are now the fault mode behaviour of the {\fg}. i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail. \item A new `derived component' can now be created where each common~symptom, or lone symptom, is a failure~mode of this new component. \end{itemize} \ifthenelse {\boolean{paper}} { \section{A theoretical `Derived Component' example} Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. $$ FG = \{ C_1 , C_2 , C_3 \} $$ Each component has a set of related fault modes (i.e. ways in which it can fail to operate correctly). Let us define the following failure modes for each component, defining a function $fm()$ that is passed a component and returns the set of failure modes associated with it \footnote{Base component failure modes are defined, often with statistics and environmental factors in a variety of sources. \cite{mil1991} }. \subsection{Define Failure mode function $fm$} Let the set of all possible components be $\mathcal{C}$ and let the set of all possible failure modes be $\mathcal{F}$. We can define a function $fm$ \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 $$ %\\ e.g. %And for this example: $$ fm(C_1) = \{ a_1, a_2, a_3 \} $$ $$ fm(C_2) = \{ b_1, b_2 \} $$ $$ fm(C_3) = \{ c_1, c_2 \} $$ where $a_n,b_n,c_n$ are component failure modes. \paragraph{Finding all failure modes within the functional group} For FMMD failure mode analysis, we need to consider the failure modes from all the components in the functional group as a flat set. This can be found by applying function $fm$ to all the components in the functional~group and taking the union of them (where F is the set of all failure modes for all components in the functional group) thus: $$ F = \bigcup_{j \in \{1...n\}} fm(C_j) $$ We overload the notation for the function $fm$ and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: \begin{equation} fm : FG \rightarrow \mathcal{F} \end{equation} Applied to the functional~group $FG$ in the example above: \begin{equation} fm(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \}. \end{equation} This can be seen as all the failure modes that can affect the failure mode group $FG$. \subsection{Analysis of the functional group failure modes} \label{theoreticalsx} For this example we shall consider single failure modes. %For each of the failure modes from $fm(FG)$ we shall %create a test case ($g_i$). Next each test case is examined/analysed %and its effect on the functional group determined. \par %\vspace{0.3cm} \begin{table}[h] \begin{tabular}{||c|c|c|c||} \hline \hline {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\ {\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline % $a\_1$ & $fs\_1$ & $g_{1}$ & SP2 \\ \hline $a\_2$ & $fs\_2$ & $g_{2}$ & SP1 \\ \hline $a\_3$ & $fs\_3$ & $g_{3}$ & SP2\\ \hline $b\_1$ & $fs\_4$ & $g_{4}$ & SP1 \\ \hline $b\_2$ & $fs\_5$ & $g_{5}$ & SP1 \\ \hline $c\_1$ & $fs\_6$ & $g_{6}$ & SP3 \\ \hline $c\_2$ & $fs\_7$ & $g_{7}$ & SP2\\ \hline % \hline \end{tabular} \caption{Component to functional group to failure symptoms example} \label{tab:fexsymptoms} \end{table} %\vspace{0.3cm} Table~\ref{tab:fexsymptoms} shows the analysis process. As we are only looking at single fault possibilities for this example each test case is represented by one failure mode. Chosen combinations of component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes.}. The test cases are analysed w.r.t. the functional~group. These become functional~group~failure~modes ($g$'s). The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. For the sake of example, let us consider the fault symptoms of the {\fg} $FG$ to be $\{g_2, g_4, g_5\}$ As failure modes, these are identical from the perspective of the functional~group. That is to say, the way in which functional~group fails if $g_2$, $g_4$ or $g_5$ % failure modes occur, is going to be the same. For example, in our CD player example, this could mean the common symptom `no\_sound'. No matter which component failure modes, or combinations thereof cause the problem, the failure symptom is the same. It may be of interest to the manufacturers and designers of the CD player why it failed, but as far as we, the users, are concerned it has only one symptom, `no\_sound'! We can thus group these component failure modes into a common symptom, $SP1$, thus $ SP1 = \{g_2, g_4, g_5\}$. % These can then be joined to form a spider. Likewise let $SP2 = \{g_1, g_3, g_7\}$ be an identical failure~mode {\em from the perspective of the functional~group}. Let $\{g_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}, but as a `lone' symptom it can be assigned its own symptom set $SP3 = \{g_6\}$. We now have in $SP1$, $SP2$ and $SP3$ the three ways in which this functional~group can fail. In other words we have derived failure modes for this functional~group. We can place these in a set of symptoms. % $$ SP = \{ SP1, SP2, SP3 \}. $$ % % These three symptoms can be considered the set of failure modes for the functional~group, if we treat it as though it were a {\em black box} or a {\em component} to be used in higher level designs. % The next stage of the process could be applied automatically. Each common symptom becomes a failure mode of a newly created derived component. Let $DC$ be the newly derived component. This is assigned the failure modes that were derived from the functional~group. We can thus apply the function $fm$ on this newly derived component thus: $$ fm(DC) = \{ SP1, SP2, SP3 \} $$ Note that $g_6$ has \textbf{not disappeared from the analysis process}. Were the designer to have overlooked this test case, it could appear as a failure mode of the derived component. i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ could have been $ \{ SP1, SP2, g_6 \}$. Because the process can be computerised, we can easily flag symptoms that have not been included as failure modes in a {\dc}. % Aw boring ! no jokes ? % This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! % %\ifthenelse {\boolean{paper}} %{ An advantage of a bottom-up process is that failure modes from base level components cannot be overlooked. %} %{ An advantage of a bottom-up process is that failure modes from base level components cannot be overlooked. The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{sec:aims}). %} % This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component with known failure modes (although at a higher level of abstraction). This process can be repeated using {\dcs} to build a hierarchical fault~mode model. The newly derived component $DC$ is available for use to form higher level functional groups, and we can thus consider DC as being in the set of components i.e. $DC \in \mathcal{C}$ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \subsection{Defining the analysis process \\ as a function} Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$ is the set of all derived components, we can define the symptom abstraction process thus: $$ %\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent \derivec : \mathcal{FG} \rightarrow \mathcal{DC} . $$ Given by $ \derivec ( FG ) = DC $ as per the example in precedeing section \ref{theoreticalsx}. \paragraph{Extending $\derivec$ to {\dcs}} It is useful to further define the $\derivec$ function, to take the failure modes from derived components (as well as base components) and return a new derived component. This generalises the function $\derivec$ and allows us to build hierarchical failure mode models. Where a {\fg} is composed of derived components, for sake of example where $DC_1, DC_2, DC_3 $ are {\dc}s we could collect these into a {\fg} thus $FG_{derived} = \{ DC_1, DC_2, DC_3 \}$. $DCFM$ is a set of failure modes from the new {\fg} $FG_{derived},$ $DCFM = fm(FG_{derived})$. We can apply the symptom abstraction process $\derivec$ to the {\fg} comprised of derived components because we can obtain a failure mode set, (the failure mode set we have named $DCFM$). Thus we can now move up another abstraction level by applying symptom abstraction/extraction to the functional group $FG_{derived}$ shown in equation \ref{eqn:fgderived}. \begin{equation} \label{eqn:fgderived} \derivec ( FG_{derived} ) = DC_{derived} \end{equation} The case where a {\fg} has been created from {\dcs} using function `$\derivec$' leads us to {\dc}s at a higher level of failure mode abstraction. A notation will be described in the next section to keep track of the abstraction level of a {\dc}. %%$$ %\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent %%\derivec : FG_{derived} \rightarrow DC %%$$ % %\begin{equation} % \derivec(FG_{cfm}) = DC %\end{equation} % %or applying the function $fm$ to obtain the $FG_{cfm}$ set % %%To put this in context, where FG is a functional group, sourced from base or derived components, %%we may state the process of %%analysing the failure modes in the {\fg} and returning a {\dc} thus: %%\begin{equation} %% \derivec((FG)) = DC %%\end{equation} In other words by analysing a functional group containing derived components, we have a new derived component as our result. This naturally builds a bottom-up failure mode model and with each iteration the model becomes more abstract will eventually reach the SYSTEM level. %The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour. %The derivation of $SS_{fm}$ is represented graphically using the `$\derivec$' symbol, as in figure \ref{fig:gensubsys4} % \begin{figure}[h+] % \centering % \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg} % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 % \label{fig:gensubsys3} % \caption{Deriving a new diagram} %% IF this is a paper it needs work on the description here. } { %To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}. Let the set of all possible components be $\mathcal{C}$ and let the set of all possible failure modes be $\mathcal{F}$. We can define a function $fm$ \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 $$ We overload the notation for the function $fm$ and define it for the set components within a functional group $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 functional groups, and $\mathcal{DC}$ is the set of all derived components, we can define the symptom abstraction process thus: $$ %\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent \derivec : \mathcal{FG} \rightarrow \mathcal{DC} . $$ The next section describes the details of the symptom extraction process. } %\section{A Formal Algorithmic Description of `Symptom Abstraction'} \section{Algorithmic Description} \label{sec:symptomabs} The algorithm for {\em symptom extraction} 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$') takes a functional group $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, $DC$ can now be treated as a component with a known set of failure modes. \paragraph{Enumerating abstraction levels} \label{sec:abstractionlevel} We can assign an attribute of abstraction level $\abslev$ to components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$). For a base component, let the abstraction level be zero. If we apply the symptom abstraction process $\derivec$, the resulting derived~component will have an $\abslev$ value one higher that the highest $\abslev$ 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 $\abslev$ 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 $\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 functional groups, a hierarchy is naturally formed with the abstraction levels increasing with each tier. \fmmdgloss %\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 The algorithm, represented by the symbol `$\derivec$', 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 $$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} $$ \begin{algorithm}[h+] \caption{Derive new `Component' from Functional Group: $\derivec(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 process 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, using 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{\FG} $$ 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 power-set 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 $$ 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 case test cases involving multiple failure modes) The function \textbf{unitary state} means that all test cases can have no pairs of failure modes sourced from the same component. \label{sec:completetest} This function also ensure completeness in the model. It ensures that for all failure modes in the {\fg} are considered in a test~case. \ifthenelse {\boolean{paper}} { %% perhaps ref a paper here XXXXX } { This is discussed in chapter \ref{sec: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 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 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. % % Calculations or simulations are performed to determine how the failure modes in each test case will affect the functional~group. Ideally field and formal physical testing data should be used in addition where possible. % When the all the test cases have been analysed we will have a `result' for each `test case'. Each result will be described {\wrt} 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, $\abslev$. 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 Mean Time to Failure (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 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % ..