diff --git a/submission_thesis/CH4_FMMD/Makefile b/submission_thesis/CH4_FMMD/Makefile index b05b767..180249d 100644 --- a/submission_thesis/CH4_FMMD/Makefile +++ b/submission_thesis/CH4_FMMD/Makefile @@ -1,15 +1,15 @@ -PNG_DIA = cfg2.png cfg.png compco2.png compco3.png compco.png component.png componentpl.png fmmd_uml2.png fmmd_uml.png partitioncfm.png master_uml.png +PNG_DIA = cfg2.png cfg.png compco2.png compco3.png compco.png component.png componentpl.png fmmd_uml2.png fmmd_uml.png partitioncfm.png master_uml.png top_down_de_comp.png %.png:%.dia dia -t png $< echo " Chapter 4 DIA images generated" -pdf: $(PNG_DIA) - pdflatex discussion_doc - acroread discussion_doc.pdf & +#pdf: $(PNG_DIA) +# pdflatex discussion_doc +# acroread discussion_doc.pdf & # this is the target used diff --git a/submission_thesis/CH4_FMMD/copy.tex b/submission_thesis/CH4_FMMD/copy.tex index 56a1598..a0c91e0 100644 --- a/submission_thesis/CH4_FMMD/copy.tex +++ b/submission_thesis/CH4_FMMD/copy.tex @@ -1574,5 +1574,1274 @@ For Functional Group 2 (FG2), let us map: Thus a derived component, DC2, has the failure modes defined by $fm(DC2) = \{ S4, S5, S6 \}$. An example using the $Pt100$ circuit for double simultaneous failure analysis is given in section~\ref{sec:pt100}. -%This AUTOMATIC check can reveal WHEN double checking no longer necessary -%in the hierarchy to cover dub sum !!!!! YESSSS + +XXXXXXXXXXXXXXXXXXXXXXXXXX +This AUTOMATIC check can reveal WHEN double checking no longer necessary +in the hierarchy to cover dub sum !!!!! YESSSS + + + + + +%\ifthenelse {\boolean{paper}} +%{ +%\input{abstract} +%%%- \input{fmmd} +%%%- %\input{introduction} +%%%- \input{topbot} +%%%- %\input{sys_abs} +%%%- \input{process} +%%%- \input{algorithm} +% +%} +%{ +%\label{symptomex} +%%%- \input{./introduction} +%%%- \input{./topbot} +%%%- %\input{./sys_abs} +%%%- \input{./process} +%%%- \input{./algorithm} +%} +% +% +%{ +%\section{Introduction} +%\label{chap:sympex} +%This chapter describes the process for taking a {\fg}, +%analysing its failure mode behaviour from the failure modes +%and interactions of its components, +%and creating a {\dc} that represent the failure mode behaviour of that {\fg}. +% + +\section{Algorithmic Description of Symptom Abstraction} + +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 failures in the components of the {\fg}. +We can 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 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\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 + + + +\section{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 +hierihical 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{mil1992}. +%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} +%} +% + +\subsection{Systems, functional groups, sub-systems and failure modes} + +It is helpful here to define the terms, `system', `functional~group', `component', `base~component', `symptom' and `derived~component/sub-system'. +These are listed in table~\ref{tab:symexdef}. + +A system, is 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/slave 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. +\paragraph{Sub-systems, {\fgs} and components.} +A sub-system will be composed of components, which +may themselves be sub-systems. However each `component' +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 example, +the CD~player could fail in several distinct ways, +and this could have been caused by a number of component failure modes. +%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 \cite{faa}[Ch.9]) +we are presented with a problem. Which initial collections of base components should we choose? + +For instance in the CD~player example; if we 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. + +\paragraph{Functional group to {\dc} process outline.} +In choosing the lowest level (base component) sub-systems we would look +for the smallest `functional~groups' of components within a system. +We can define a functional~group as 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'. +The fault behaviour will consist of a set of `symptoms' caused by combinations +of its component failure modes. +We can thus make a new `component' derived from the functional~group. +The symptoms of the {\fg} are the failure modes of this new `derived component'. + +%We can now call our functional~group a sub-system or a derived~component. +%The goal here is to know how it 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 could +be failure modes of the component, with environmental factors and MTTF statistics. +Currently this sort of failure mode information is generally only available for generic component types \cite{mil1991}. + +%\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 an 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 failure~modes missed, any failure mode model could be dangerously incomplete. +It is possible here for an automated system to flag unhandled 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 si,ultaneous 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: +$$ +%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent +\bowtie : \mathcal{FG} \rightarrow \mathcal{DC} . +$$ + +Given by +$ \bowtie ( FG ) = DC $ +as per the example in precedeing section \ref{theoreticalsx}. + +\paragraph{Extending $\bowtie$ to {\dcs}} + +It is useful to further define the $\bowtie$ function, to +take the failure modes from derived components (as well as base components) +and return a new derived component. +This generalises the function $\bowtie$ 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 $\bowtie$ +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} + \bowtie ( FG_{derived} ) = DC_{derived} +\end{equation} + + +The case +where a {\fg} has been created from {\dcs} +using function `$\bowtie$' 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}. + +%%$$ +%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent +%%\bowtie : FG_{derived} \rightarrow DC +%%$$ +% +%\begin{equation} +% \bowtie(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} +%% \bowtie((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 `$\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} + +%% 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: +$$ +%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent +\bowtie : \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} + +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 `$\bowtie$') 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} +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 $\bowtie$, +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 `$\bowtie$', has been broken down into five consecutive stages. +%These are described using the Algorithm environment in the next section \ref{algorithms}. +By defining the process and describing it using set theory. Constraints and +verification checks in the process are stated formally. +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + + + +\section{Algorithmic Description of Symptom Abstraction} +%\clearpage +$$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$ + +\begin{algorithm}[h+] + +\caption{Derive new `Component' from Functional Group: $\bowtie(FG)$} \label{alg66} + +\begin{algorithmic}[1] + + \STATE {F = fm (FG)} \COMMENT{ collect all component failure modes }%from the from the components in the functional~group } + \STATE {TC = dtc (F)} \COMMENT{ determine all test cases } %to apply to the functional group } + \STATE {R = atc (TC)} \COMMENT{ analyse the test cases }%, for failure mode behaviour of the functional~group } + \STATE {SP = fcs (R)} \COMMENT{ find common symptoms }%of failure for the functional group } + \STATE {DC = cdc (SP)} \COMMENT{ create a derived component } + + \RETURN $DC$ + +\end{algorithmic} +\end{algorithm} + +The symptom abstraction 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{F} $$ + +A {\fg} is a collection of components such that $\mathcal{FG} \in \mathcal{P}\,\mathcal{C}$. + +The function $fm$ can be overloaded with a functional group $\mathcal{FG}$ as its domain +and the powerset of all failure modes as its range. + + +$$ fm: \mathcal{FG} \rightarrow \mathcal{P}\,\mathcal{F} $$ + +% +%%Let $FG$ be the set of components in the functional group under analysis, and $c$ +%%be components that are members of it. This function returns a flat set of failure modes $F$. +%given by +%$$fm(FG) = F$$ +%%% +%%% Algorithm 1 +%%% +% +%%%- +%%%- A such that B is C +%%%- +% +% +%\begin{algorithm}[h+] +% ~\label{alg1} +%\caption{Determine Failure Modes: fm( $FG$ )} \label{alg11} +%\begin{algorithmic}[1] +%\REQUIRE {FG is a non empty set of components i.e. $ FG \in \mathcal{P}\,\mathcal{C} \wedge FG \neq \emptyset $. } +%\REQUIRE {Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; \big( fm(c) \neq \emptyset \big)$.} +% +%%\STATE { Let $FG$ be a set of components } \COMMENT{The functional group should be chosen to be minimally sized collections of components that perform a specific function} +% +%\STATE { $ F := \emptyset $ } \COMMENT{Clear the set of failure modes} +%\FORALL { $c \in FG $ } +%\STATE { $F:= F \cup fm(c)$ } \COMMENT{Collect the failure modes from the component `c' and append them to $F$ } +%\ENDFOR +% +%\COMMENT {$F=fm(FG)$ is the set of all failure modes to consider for the functional~group $FG$} +% +% +%\RETURN { $F$ } +% +%%\hline +%% +%\end{algorithmic} +%\end{algorithm} +% +%Algorthim \ref{alg11} has taken a functional~group $FG$ and returned a set of failure~modes $F=fm(FG)$ +%(given that each component has a known set of failure~modes). +The next task is to formulate `test cases'. These are a collection of combinations of these failure~modes and will be used +in the analysis stages. + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%\clearpage +\subsection{ Determine Test Cases} + +From the failure modes associated with the functional~group, +we now need to determine test cases. +The test cases are collections of failure modes. +These can be formed from single failure modes or failure modes in combination. +Let $\mathcal{TC}$ be the set of all test cases, $\mathcal{F}$ +be the set of all failure modes. +%(associated with the functional group $FG$). + +$$ dtc: \mathcal{F} \rightarrow \mathcal{TC} $$ + +given by + +$$ dtc(F) = TC $$ + +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{unitarystate} means that all test cases can have no pairs of failure modes sourced from the same component. +\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 MTTF and SIL\cite{en61508} levels can be automatically calculated. + +%%%\section{Example Symptom Extraction} +%% There already is an example of the process before the algorithmic description +%%%This is a simplified version of the pt100 example in chapter \ref{pt100}. + +%\vspace{40pt} +%\today + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % diff --git a/submission_thesis/CH4_FMMD/top_down_de_comp.dia b/submission_thesis/CH4_FMMD/top_down_de_comp.dia new file mode 100644 index 0000000..4e875ae Binary files /dev/null and b/submission_thesis/CH4_FMMD/top_down_de_comp.dia differ