From b1b776265c104ffe2f5446773d8e8f745780d8cc Mon Sep 17 00:00:00 2001 From: Robin Date: Thu, 10 Jun 2010 22:06:22 +0100 Subject: [PATCH] too tired to do this really --- standards/standards.tex | 24 +- symptom_ex_process/Makefile | 3 +- .../symptom_ex_process_paper.tex | 698 ++++++++++++++++++ 3 files changed, 718 insertions(+), 7 deletions(-) create mode 100644 symptom_ex_process/symptom_ex_process_paper.tex diff --git a/standards/standards.tex b/standards/standards.tex index e4fa253..1461208 100644 --- a/standards/standards.tex +++ b/standards/standards.tex @@ -11,8 +11,20 @@ are reviewed. \section{Introduction} -\section{European Safety Standards Legal Framework} -\section{North American Legal Framework} +\section{European or `EN' Standards} + +\subsection{Scope} +\subsection{Approval Process} +\subsection{Legal Framework} +\subsection{References} + +\section{North American Standards} + +\subsection{Scope} +\subsection{Approval Process} +\subsection{Legal Framework} +\subsection{References} + Protection against being sued mainly ! UL - underwriters laboratories.... etc @@ -21,10 +33,10 @@ Protection against being sued mainly ! UL - underwriters laboratories.... etc Stabndards of ten reference other - i.e. EMC testing in EN298 refers toEN blah blah to level blah blah -\section{EN298} +\section{Standard in detail: EN298} -\section{UL1998} +\section{Standard in detail: UL1998} -\section{EN230} +\section{Standard in detail: EN230} -\section{EN61508} +\section{Standard in detail: EN61508} diff --git a/symptom_ex_process/Makefile b/symptom_ex_process/Makefile index 730ed75..611bbdd 100644 --- a/symptom_ex_process/Makefile +++ b/symptom_ex_process/Makefile @@ -8,7 +8,8 @@ paper: paper.tex symptom_ex_process_paper.tex #latex paper.tex #dvipdf paper pdflatex cannot use eps ffs pdflatex paper.tex - okular paper.pdf + mv paper.pdf symptom_ex_process_paper.pdf + okular symptom_ex_process_paper.pdf # Remove the need for referncing graphics in subdirectories diff --git a/symptom_ex_process/symptom_ex_process_paper.tex b/symptom_ex_process/symptom_ex_process_paper.tex new file mode 100644 index 0000000..8885c40 --- /dev/null +++ b/symptom_ex_process/symptom_ex_process_paper.tex @@ -0,0 +1,698 @@ + +\begin{abstract} +In failure mode analysis, it is essential to +know the failure modes of the sub-systems and components used. +This paper outlines a technique for determining the failure modes of a sub-system given +its component parts. +%, and the failure modes of those parts. + +This chapter describes a process for taking a functional group of components, applying FMEA analysis and then determining how that functional group can fail. +With this information, we can treat the functional group +as a component in its own right. + +This new component is a derived component. +For a top down technique this would correspond 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/derived~component, +This derived component can be combined with others to form functional groups +to model +higher level sub-systems/derived~components. +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. +% +From the fault data model, automatic generation +of FTA\cite{nasafta} (Fault Tree Analysis) and mimimal 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, where component failure mode statistics are available\cite{mil1991}. +% +This paper focuses on the process of building the blocks, that are key to creating an FMMD hierarchy. + +\end{abstract} + +%\clearpage + +\section{Introduction} + +\subsection{Top Down or natural trouble shooting} +It is interesting here to look at the `natural' trouble shooting process. +Fault finding is intinctively 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 next be looked into. +The trouble shooter will look for behaviour that is unusual or incorrect +to determine the next area or sub~system to look at, 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. +\subsection{FMMD - Bottom~up Analysis} +The FMMD technique does not follow the `natural fault finding' or top down approach, +it instead works from the bottom up. +Starting with a collection of 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. It has a known set of failure modes. +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 the components. +It also means that every component failure mode must at the very least be considered. + +\subsection{Static Analysis} + +In the field of safety critical engineering; to comply with +European Law a product must be certified under the approriate `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 techniques are currenly used, +Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis). +The technique outlined here aims to provide a mathematical frame work +to assist in the production of these three results of static analysis. +From the model created by the FMMD technique, the three above failure mode +descriptions can be derived. + +{ +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} +} + + +\subsection{Systems, functional groups, sub-systems and failure modes} + +It is helpful here to define some terms, `system', `functional~group', `component', `base~component' and `derived~component/sub-system'. +These are listed in table~\ref{tab:symexdef}. + +A System, is really any coherent entity that would be sold as a product. % safety critical product. +A sub-system is a system that is part of some larger system. +For instance a stereo amplifier separate is a sub-system. The +whole Sound System, consists perhaps of the following `sub-systems': +CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface. + +%Thinking like this is a top~down analysis approach +%and is the way in which FTA\cite{nucfta} analyses a System +%and breaks it down. + +A sub-system will be composed of component parts, which +may themselves be sub-systems. However each `component part' +will have a fault/failure behaviour and it should +always be possible to obtain a set of failure modes +for each `component'. In FMMD terms a sub-system is a derived component. + +If we look at the sound system again as an +example; the CD~player could fail in serveral distinct ways, no matter +what has happened to it or has gone wrong inside it. + + +Using the reasoning that working from the bottom up forces the consideration of all possible +component failures (which can be missed in a top~down approach) +we are presented with a problem. Which initial collections of base components should we choose ? + +For instance in the CD~player example; to start at the bottom; we are presented with +a massive list of base~components, resistors, motors, user~switches, laser~diodes all sorts ! +Clearly, working from the bottom~up we need to pick small +collections of components that work together in some way. +These are termed `functional~groups'. For instance the circuitry that powers the laser diode +to illuminate the CD might contain a handful of components, and as such would make a good candidate +to be one of the base level functional~groups. + + +In choosing the lowest level (base component) sub-systems we would look +for the smallest `functional~groups' of components within a system. A functional~group is a set of components that interact +to perform a specific function. + +When we have analysed the fault behaviour of a functional group, we can treat it as a `black box'. +We can now call our functional~group a sub-system. The goal here is to know how will behave under fault conditions ! +%Imagine buying one such `sub~system' from a very honest vendor. +%One of those sir, yes but be warned it may fail in these distinct ways, here +%in the honest data sheet the set of failure modes is listed! + + +%This type of thinking is starting to become more commonplace in product literature, with the emergence +%of reliability safety standards such as IOC1508\cite{sccs},EN61508\cite{en61508}. +%FIT (Failure in Time - expected number of failures per billion hours of operation) values +%are published for some micro-controllers. A micro~controller +%is a complex sub-system in its self and could be considered a `black~box' with a given reliability. +%\footnote{Microchip sources give an FIT of 4 for their PIC18 series micro~controllers\cite{microchip}, The DOD +%1991 reliability manual\cite{mil1991} applies a FIT of 100 for this generic type of component} + +Electrical components have detailed datasheets associated with them. A useful extension of this would +be failure modes of the component, with environmental factors and MTTF statistics. + +Currently this sort of information is generally only available for generic component types\cite{mil1991}. + + +%At higher levels of analysis, functional~groups are pre-analysed sub-systems that interact to +%erform a given function. + +%\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 \\ \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 +Base Component & Any bought in component, which \\ + & hopefully has a known set of failure modes \\ \hline + \hline +\end{tabular} +\caption{Symptom Extraction Definitions} +\label{tab:symexdef} +\end{table} +%\vspace{0.3cm} + + +\section{The Symptom abstraction Process} + +% TO DO: separate these two: + +\paragraph{Symptom Extraction Described} + +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 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 is a set of components, the failure~modes +that we have to consider are all the failure modes of its components. +Each failure mode (or combination of) investigated is termed a `test case'. +Each `test case' is analysed. +The component failure modes are examined with respect to their effect on the functional~group. +The aim of this analysis is to find out how the functional~group react +to each of the test case conditions. +The goal of the process is to produce a set of failure modes from the perspective of the functional~group. +\paragraph{Symptom Identification} +When all `test~cases' have been analysed a second phase is applied. +% +This looks at the results of the `test~cases' as symptoms +of the sub-system. +Single component failures 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} +The common symptoms of failure and lone~component failure~modes are identified and collected. +We can now consider the functional~group as a component and the common symptoms as its failure modes. +Note that here because the process is bottom up, we can ensure that all failure modes +associated with a functional~group have been handled. +Were failure~modes missed any failure mode model could be dangerously incomplete. +It is possible here for an automated system to flag unhandled failure modes. +\ref{requirement at the start} + +% \paragraph{symptom abstraction represented on the diagram} This process can be applied using a diagram. From the collection of parts for the sub-system under analysis, a set of failure modes for each component is obtained. A diagram is then drawn with each component failure mode represented by a contour. Component failure mode combinations are chosen for `test cases'.\footnote{Combinations of component failure modes can be represented by overlapping contours} A `test case' is represented on the diagram as a point or asterisk, in a region enclosed by the contours representing the failure modes it investigates. The effect on the sub-system of each test case is analysed. %It is then represented on the diagram by an asterisk on the contour representing the failure mode. The `test~case~results' are archived. When all test cases have been analysed, we switch our attention to a higher abstraction level. % We treat the sub-system as a black box, or as a component part itsself. % We can now look at the test case results from the perspective of a `user' % of this sub-system. % % +% We treat the sub-system as a `black box' and view the effects of the component failure +% at the sub-system level. This mean we are not interested so much in what the compoent does, +% but how the sub-system reacts when it fails in a certain way. +% +% Each `test case' is labelled from the perspective of the failure as seen at sub-system level. + +% We can now try to simplfy by determining common symptoms. A common symptom, in this context, is defined as faults caused by different component failure modes that have the same effect from the perspective of a `user' of the sub-system. Test case results can now viewed as failure modes of the sub-sytem or `black box', and grouped together where there are common symptoms. These are grouped together by joining them with lines. These lines form collected groups (or `spiders'). See figure \ref{fig:gensubsys3}. +% It can be seen now that each {\em lone test case} and {\em spider} on the diagram is a distinct failure mode of the sub-system. This means that these failure modes represent the fault behaviour of the sub-system. We can now treat this sub-system as a component in its own right, or in other words, we have derived a failure mode model at a higher level of abstraction. We can now draw a new diagram to represent the failure modes of the sub-system. Each spider or lone test case, becomes a contour representing a failure mode of the sub-system in this new diagram (see figure \ref{fig:gensubsys4}. + +\section{The Process : To analyse a base level Derived~Component/sub-system} + +To sumarise: + +\begin{itemize} + \item Determine a minimal functional group + \item Obtain the list of components in the functional group + \item Collect the failure modes for each component +% \item Draw these as contours on a diagram +% \item Where si,ultaneous failures are examined use overlapping contours +% \item For each region on the diagram, make a test case + \item Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group + \item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use. +Determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider'). + \item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component. + \item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component +\end{itemize} + + + + +\section{A general derived Component/Sub-System example} + +Consider a functional group $FG$ with component parts $A$,$B$ and $C$. + +$$ FG = \{ A, B , C \} $$ + +Each part 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 part, defining a function $FM()$ where $K$ +is a component part and $F$ is its set of failure modes\footnote{Base component failure modes are defined, often with +statistics and evironmental factors in a variety of sources. \cite{mil1991} +}. + +$$ +FM : K \mapsto F +$$ +\\ +For our example abovei, let the components have the fiollowing failure~modes +\\ +$$ FM(A) = \{ a_1, a_2, a_3 \} $$ +$$ FM(B) = \{ b_1, b_2 \} $$ +$$ FM(C) = \{ c_1, c_2 \} $$ + +%\paragraph{NOTE TO ANDREW : SHOULD I DEFINE A FUNCTION HERE THAT CONVERTS A FUNCTIONAL GROUP +%TO the set of failure modes in all its component parts ??? Am I being lazy here ???} + +%In order to convert the three components with thier failure +%modes into one large set containing all the failure modes, +%we could index all Components in $FG$ with $ j \in J $ and use + +\paragraph{Finding all failure modes within the functional group} + +Consider the index set $j \in J$ +Consider the set C to represent components and let this be indexd by $j$. +For this example consider all instances of $C_j$ to be members of $FG$, + $$ \forall j \in J | C_j \in FG $$ + +Now take the union over the application of all components in the set $FG$ + +$$ FG_{cfm} = \bigcup ( \forall j \in J FM(C_j) ) $$ + +We can now represent the functional~group $FG$ as a set of component faulure modes $FG_{cfm}$, +thus + +\begin{equation} + FG_{cfm} = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \} +\end{equation} + +This could be seen as all the failure modes that can affect the failure mode group $FG$. + + +% The failure modes of the components can be represented as contours on on the diagram in \ref{fig:gensubsys1}. \begin{figure} \centering \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/synmptom_abstraction.jpg} % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 \label{fig:gensubsys1} \caption{$FG_{cfm}$ Component Failure modes represented as contours} \end{figure} % % DIAGRAM WITH SPIDER % \begin{figure} % \centering % \includegraphics[scale=20]{./synmptom_abstraction.jpg} % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 % \label{fig:gensubsys2} % \caption{$SS_{cfm}$ Component Failure modes represented as contours} % \end{figure} We can now look at the effects that component failure modes have on the sub-system. This process involves examining `test cases'. Each `test case' represents the fault behaviour of the sub-system due to particular combinations of component fault modes. Each test case can be represented on the diagram as a labeled point. The labeled point will reside in a region on the diagram enclosed by the contours representing particular component fault modes. The label will indicate the fault symptom from the perspective of the sub-system. For the sake of example, only single component failure modes are considered. We can now assign a test~case to each contour, and mark it on the diagram. % \begin{figure}[h+] % \centering % \includegraphics[scale=20]{./symptom_abstraction2.jpg} % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 % \label{fig:gensubsys2} % \caption{Component Failure modes with analysed test cases} % \end{figure} \begin{figure} \centering \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/symptom_abstraction2.jpg} % symptom_abstraction2.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 \label{fig:gensubsys2} \caption{Component Failure modes with analysed test cases} \end{figure} + +\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$ & $fgfm_{1}$ & SP2 \\ \hline +$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline +$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline +$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline +$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline +$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\ \hline +$c\_2$ & $fs\_7$ & $fgfm_{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. +In this example we are only looking at single fault possibilities. +The 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 ($fgfm$'s). +The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. + +% The sub-system fault symptoms are now represented on the diagram as in figure \ref{fig:gensubsys2}. A second stage of analysis is now applied. Empirically, it is often noticed that a sub-system will fail in the same way due to a variety of reasons. To the `user' of the sub-system, it does not matter which component or combination of components has failed. The sub-system can thus be considered to have its own set of failure modes. This stage of the analysis is to determine these, to collect `like symptoms'. This is performed on the diagram by linking the test cases with lines to form `spiders' +For the sake of example let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ be +identical from the perspective of the functional~group. +That is to say, that the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_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 = \{fgfm_2, fgfm_4, fgfm_5\}$. +% These can then be joined to form a spider. +Likewise +let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. +Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}. + +% The diagram can now be drawn as in figure \ref{fig:gensubsys3}. % \begin{figure}[h+] % \centering % \includegraphics[scale=20]{./symptom_abstraction3.jpg} % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 % \label{fig:gensubsys3} % \caption{Common failure modes collected as `Spiders'} % \end{figure} \begin{figure}[h+] \centering \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/symptom_abstraction3.jpg} % symptom_abstraction3.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 \label{fig:gensubsys3} \caption{Common failure modes collected as `Spiders'} \end{figure} + +We have now in $SP1$, $SP2$ and $fgfm_6$ as 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$. +% +$$ SP = \{ SP1, SP2, fgfm_6 \} $$ +% +% +These three symptoms can be considered the set of failure modes for the functional~group, and +we can 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, fgfm_6 \} $$ + +Note that $fgfm_6$, while %being a failure mode has +not being grouped as a common symptom +has \textbf{not dissappeared from the analysis process}. +Were the designer to have overlooked this test case, it would appear in the derived component. +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, my advice to all nine year olds faced with this dilema, is its best, to throw the brussell sprouts out of the dining~room window while the adults are not watching!}! +The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). + + +\subsection{Defining the analysis process as a function} + +It is useful to define this analysis process as a function. +Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now +write + +$$ +\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent +$$ + +\begin{equation} + \bowtie(FG_{cfm}) = DC +\end{equation} + +or applying the function $FM$ to obtain the $FG_{cfm}$ set + +\begin{equation} + \bowtie(FM(FG)) = DC +\end{equation} + + +%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 `$\bowtie$' 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} + + +This sub-system or derived~component $DC$ , with its three error modes, can now be treated as a component (although at a higher level of abstraction) +with known failure modes. +This process can be repeated using derived~components to build a +hierarchical +fault~mode +model. + + + + + +%\section{A Formal Algorithmic Description of `Symptom Abstraction'} +\section{Algorithmic Description} + +The algorithm for {\em symptom extraction} is described in +this section +%describes the symptom abstraction process +using set theory. + +The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$ +and converts it to a derived~component/sub-system $DC$. +%The sub-system $SS$ is a collection +%of failure~modes of the sub-system. +Note that +$DC$ is a derived component at a higher level of fault analysis abstraction, +than the functional~group it was derived from. +However, it can still be treated +as a component with a known set of failure modes. +\paragraph{enumerating abstraction levels} +If $DC$ is included in a functional~group +that functional~group must be considered to be a 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. +% +$DC$ can be used as a system building block at a higher +level of fault abstraction. Because the derived components +merge to form functional groups, a converging hierarchy is +naturally formed with the abstraction level increasing with each tier. + + +The algorithm, representing the function $\bowtie$, has been broken down into five stages, each following on from the other. +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 can be stated formally. + +\clearpage +\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine} +%% +%% Algorithm 1 +%% + +\begin{algorithm}[h+] + ~\label{alg:sympabs1} +\caption{Determine failure modes: $FG \mapsto FG_{cfm}$} \label{alg:sympabs11} +\begin{algorithmic}[1] +%\REQUIRE Obtain a list of components for the System $S$ under investigation. +%ENSURE Decomposition of $S$ into atomic components where each component $c$ has a know set of $fm$ failure modes. + + +%\STATE Determine functional groups $fg_n \subset S$ of components, where n is an index number and the number of functional groups found. + +\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 { Let $c$ represent a component} +\STATE { Let $C_{fm}$ represent a set of failure modes } +\STATE { $FM(c) \mapsto C_{fm} $} \COMMENT {Let the function $FM$ take a component and return a set of all its failure modes} + +%\ENSURE { $ \forall c | c \in FG \wedge FM(c) \neq \emptyset $} +%\ENSURE { $ c | c \in FG \wedge FM(c) \neq \emptyset $} +\ENSURE{ Each component $c \in FG $ has a known set of failure modes i.e. $FM(c) \neq \emptyset$ } +%\REQUIRE{ Ensure that all components belong to at least one functional group $\bigcup_{i=1...n} fg_i = S $ } +%symptom_abstraction +% okular + +\STATE {let $FG_{cfm}$ be a set of all failure modes to consider for the functional~group $FG$} + +\STATE {Collect all failure modes from all the components in FG into the set $FG_{cfm}$} +\FORALL { $c \in FG $ } +\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$} +\ENDFOR + +%\hline +Algorthim \ref{alg:sympabs11} has taken a functional group $FG$ and returned a set of failure~modes $FG_{cfm}$. +The next task is to formulate `test cases'. These are the combinations of failure~modes that will be used +in the analysis stages. + + +\end{algorithmic} +\end{algorithm} + +\clearpage +\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases} +%% +%% Algorithm 2 +%% + + +\begin{algorithm}[h+] + ~\label{alg:sympabs2} +\caption{Determine Test Cases: $FM_{cfm} \mapsto TC $} \label{alg:sympabs22} +\begin{algorithmic}[1] + + \REQUIRE {Determine the test cases to be applied} + + \STATE { All test cases are now chosen by the investigating engineer(s). Typically all single + component failures are investigated + with some specially selected combination faults} + + \STATE { Let $TC$ be a set of test cases } + \STATE { Let $tc_j$ be set of component failure modes where $j$ is an index of $J$} + \COMMENT { Each set $tc_j$ is a `test case' } + \STATE { $ \forall j \in J | tc_j \in TC $ } + + %\STATE { $ \bigcup_{j=1...N} tc_j = \bigcup TC $ } + %\COMMENT { All $tc_j$ test cases sets belong to $TC$ } + + %\REQUIRE { $ TC \subset \bigcup (FM_{cfm}) $ } + %\COMMENT { $TC$ is the set of all test_cases +% Let TC be a subset of the powerset of the failure modes $ FG_{cfm} $, +%i.e. only failure modes present in $ FG_{cfm} $ are present in sets belonging to $ TC $} + + + \COMMENT { Ensure the test cases are complete and unique } + + \FORALL { $tc_j \in TC$ } + %\ENSURE {$ tc_j \in \bigcap FG_{cfm} $} + \ENSURE {$ tc_j \in \mathcal{P} FG_{cfm} $} + \COMMENT { require that the test case is a member of the powerset of $FM_{cfm}$ } + \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 + + + + \STATE { let $f$ represet a component failure mode } + \REQUIRE { That all failure modes are represented in at least one test case } + \ENSURE { $ \forall f | (f \in FM_{cfm}) \wedge (f \in \bigcup TC) $ } + \COMMENT { This corresponds to checking that at least each failure mode is considered at least once in the analysis; some european standards +imply checking all double fault combinations\cite{en298} } + +%\hline +Algorithm \ref{alg:sympabs22} has taken the set of failure modes $FM_{cfm}$ and returned a set of test cases $TC$. +The next stages is to analyse the effect of each test case on the functional group. + +\end{algorithmic} +\end{algorithm} + +\clearpage +\subsection{Algorithmic Description of Symptom Abstraction \\ Analyse Test Cases} +%% +%% Algorithm 3 +%% + +\begin{algorithm}[h+] + ~\label{alg:sympabs3} +\caption{Analyse Test Cases: $ TC \mapsto R $} \label{alg:sympabs33} +\begin{algorithmic}[1] + \STATE { let r be a `test case result'} + \STATE { Let the function $Analyse : tc \mapsto r $ } \COMMENT { This analysis is a human activity, examining the failure~modes in the test case and determining how the functional~group will fail under those conditions} + \STATE { $ R $ is a set of test case results $r_j \in R$ where the index $j$ corresponds to $tc_j \in TC$} + \FORALL { $tc_j \in TC$ } + \STATE { $ rc_j = Analyse(tc_j) $} \COMMENT {this is Fault Mode Effects Analysis (FMEA) applied in the context of the functional group} + \STATE { $ rc_j \in R $ } + \ENDFOR + +%\hline +Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case. +\end{algorithmic} +\end{algorithm} + + +\clearpage +\subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms} +%% +%% Algorithm 4 +%% + +\begin{algorithm}[h+] + ~\label{alg:sympabs4} + +\caption{Find Common Symptoms: $ R \mapsto SP $} \label{alg:sympabs44} + +\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 sets $sp_l$} + \COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system} +% + %\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} + + \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 | \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} + +%\hline +Algorithm \ref{alg:sympabs44} raises the failure~mode abstraction level. +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. + +\end{algorithmic} +\end{algorithm} + +\clearpage +\subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component} +%% +%% Algorithm 5 +%% + +\begin{algorithm}[h+] + ~\label{alg:sympabs5} + +\caption{Treat the symptoms as failure modes of the Derived~Component/Sub-System: $ SP \mapsto DC $} \label{alg:sympabs55} + +\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} + \ENDFOR +%\hline + +Algorithm \ref{alg:sympabs55} 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 +% treated as a component, and +used in conjection with other components (or derived~components) to form functional~groups at a higher level of failure~mode~abstraction. +\end{algorithmic} +\end{algorithm} + + +\section{To conclude} + +The technique provides a methodology for bottom-up analysis of the fault behaviour of complex safety critical systems. + +\subsection{Hierarchical Simplification} + +Because symptom abstraction collects fault modes, the number of faults to handle decreases +as the hierarchy progresses upwards. +This is seen in real life Systems. At the highest levels the number of faults +reduces. 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 which combination of causes caused the fault to the user. +But as the hierarchy goes up in abstraction level the number of faults goes down. + +\subsection{Tracable Fault Modes} + +Because the fault modes are determined from the bottom-up, the causes +for all high level faults naturally form trees. +Minimal cut sets \cite{nasafta} can be determined from these, and by +analysing the statistical likely hood of the component failures +the MTTF and SIL\cite{en61508} levels can be automatically calculated. +