From c050936f28cd31280bb706d88150bc46a0fa3068 Mon Sep 17 00:00:00 2001 From: Your Name Date: Thu, 12 Apr 2012 20:05:07 +0100 Subject: [PATCH 1/4] OK went through my own proff reading process and its now 20:05 and I am getting a bit tired. Better put it in git or perhaps loose it due to a typo in a Makefile.... --- papers/software_fmea/Makefile | 1 + submission_thesis/CH4_FMMD/copy.tex | 311 +++++++++++++--------- submission_thesis/CH5_Examples/copy.tex | 146 +++++----- submission_thesis/mybib.bib | 11 +- submission_thesis/style.tex | 5 +- submission_thesis/titlepage/titlepage.tex | 17 +- 6 files changed, 287 insertions(+), 204 deletions(-) diff --git a/papers/software_fmea/Makefile b/papers/software_fmea/Makefile index 93f6944..1268f95 100644 --- a/papers/software_fmea/Makefile +++ b/papers/software_fmea/Makefile @@ -6,6 +6,7 @@ PNG = fmmdh.png ct1.png hd.png ftcontext.png all: ${PNG} + pdflatex software_fmea pdflatex software_fmea acroread software_fmea.pdf diff --git a/submission_thesis/CH4_FMMD/copy.tex b/submission_thesis/CH4_FMMD/copy.tex index be1f7d1..56a1598 100644 --- a/submission_thesis/CH4_FMMD/copy.tex +++ b/submission_thesis/CH4_FMMD/copy.tex @@ -1,7 +1,6 @@ -\section{Copy dot tex} - - - +%% +%% CHAPTER 4 : Failure Mode Modular Discrimination +%% \ifthenelse {\boolean{paper}} { @@ -24,9 +23,11 @@ This chapter defines the FMMD process and related concepts and calculations. Firstly, %what is meant by the terms components, failure~modes, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes are defined. +% The general concept of the cardinality constrained powerset is introduced and calculations for it described, and then performance -calculations under `unitary state' fault mode conditions. +calculations (comparing traditional FMEA and FMMD). % under `unitary state' fault mode conditions. +% Data types and their relationships are described using UML. Mathematical constraints and definitions are made using set theory. } @@ -45,8 +46,10 @@ describes the data types and concepts for the Failure Mode Modular De-compositio When analysing a safety critical system using this methodology, we need clearly defined failure modes for all the components that are used to model the system. +% In our model, we have a constraint that -the component failure modes must be mutually exclusive. +the component failure modes must be mutually exclusive within individual components. +This concept is later developed as the condition of `unitary state' fault modes. When this constraint is complied with, we can use the FMMD method to build hierarchical bottom-up models of failure mode behaviour. %This and the definition of a component are @@ -94,7 +97,7 @@ to mean a part or a sub-assembly. What components all have in common is that they can fail, and fail in a number of well defined ways. For common base-components there is established literature for the failure modes for the system designer to consider (often with accompanying statistical -failure rates)~\cite{mil1991}. For instance, a simple resistor is generally considered +failure rates)~\cite{mil1991}~\cite{en298}~\cite{fmd91}. For instance, a simple resistor is generally considered to fail in two ways, it can go open circuit or it can short. Thus we can associate a set of faults to this component $ResistorFaultModes=\{OPEN, SHORT\}$. The UML diagram in figure @@ -114,13 +117,11 @@ each failure mode is referenced back to only one component. %%-%% The lower resistance part will draw more current and therefore have a statistically higher chance of failure.}. -A products are built using of many base-components and these are traditionally -kept in a `parts~list'. For a safety critical product this is usually a formal document -and is used by quality inspectors to ensure the correct parts are being fitted. -The parts list is shown for -completeness here, as people involved with Printed Circuit Board (PCB) and electronics production, verification -and testing would want to know where it lies in the model. -The parts list is not actively used in the FMMD method. +Controlled products are typically built using a large number of base-components and these are traditionally +kept in a `parts~list'. +For a safety critical product this is usually a formal document and is used by quality inspectors to ensure the correct parts are being fitted. +%The parts list is shown for completeness here, as people involved with Printed Circuit Board (PCB) and electronics production, verification and testing would want to know where it lies in the model. +The parts list is not actively used in the FMMD method, but is shown in the UML model for completeness. For the UML diagram in figure \ref{fig:componentpl} the parts list is simply a collection of components. \begin{figure}[h] \centering @@ -132,10 +133,10 @@ For the UML diagram in figure \ref{fig:componentpl} the parts list is simply a c Components in the parts list % (bought in parts) will be termed `base~components'. -Components derived from base~components will not always require -parts~numbers\footnote{It is common practise for sub assemblies, PCB's, mechanical parts, +Components derived from base~components (i.e. sub-assemblies) will not always require +parts~numbers\footnote{It is common practise for sub-assemblies, PCB's, mechanical parts, software modules and some collections of components to have part numbers. -This is a production/configuration~control issue and linked to Bill of Material (BOM) +This is a production/configuration~control issue and linked to Bill of Material (BOM)~\cite{opmanage} database structures etc. Parts numbers for derived components are not directly related to the analysis process we are concerned with here.}, and will not require a vendor reference, but must be named locally in the FMMD model. @@ -158,7 +159,9 @@ internally. What we need to know are the symptoms of failure. With these symptoms, we can trace their effects through the system under investigation and determine outcomes. -Different approval agenices may list different failure mode sets for the same generic components. +Different approval agencies may list different failure mode sets for the same generic components. +This apparent anomaly is discussed in section~\ref{sec:determine_fms} using two common electronic components +as examples. @@ -177,8 +180,9 @@ Traditional static fault analysis methods work from the top down. They identify faults that can occur in a system, and then work down to see how they could be caused. Some apply statistical techniques to determine the likelihood of component failures -causing specific system level errors. For example, Bayes theorem \ref{bayes}, the relation between a conditional probability and its reverse, -can be applied to specific failure modes in components and the probability of them causing given system level errors. +causing specific system level errors. For example the FMEA variant FMECA, uses +Bayes theorem~\ref{probstat}[p.170]~\cite{nucfta}[p.74] (the relation between a conditional probability and its reverse) +and is applied to specific failure modes in components and their probability of causing given system level errors. Another top down methodology is to apply cost benefit analysis to determine which faults are the highest priority to fix~\cite{bfmea}. The aim of FMMD analysis is to produce complete failure @@ -188,7 +192,7 @@ starting, where possible with known base~component failure~modes. An advantage of working from the bottom up is that we can ensure that all component failure modes must be considered. A top down approach can miss individual failure modes of components~\cite{faa}[Ch.~9], -especially where they are non obvious top-level faults. +especially where there are non obvious top-level faults. In order to analyse from the bottom-up, we need to take small groups of components from the parts~list that naturally @@ -203,13 +207,15 @@ and from this determine the failure modes of all the components that belong to i % % expand 21sep2010 %The `{\fg}' as used by the analyst is a collection of component failures modes. -The analysts interest is the ways in which the components within the {\fg} -can fail. All the failure modes of all the components within an {\fg} are collected. -As each component mode holds a set of failure modes, these set of sets of failure modes -is converted into +The analysts interest is in the ways in which the components within the {\fg} +can fail. +% +All the failure modes of all the components within an {\fg} are collected. +As each component mode holds a set of failure modes, the {\fg} represents a set of sets of failure modes. +We convert this into a flat set -of failure modes -(i.e. a set containing just failure modes not sets of failure modes). +of failure modes for use in analysis. +A flat set is a set containing just failure modes and not sets of failure modes~\cite{joyofsets}. % Each of these failure modes, and optionally combinations of them, are formed into `test cases' which are @@ -225,24 +231,26 @@ with its own set of failure modes. \subsection{From functional group to newly derived component} \label{fg} -The process for taking a {\fg}, considering +The process for taking a {\fg}, analysing its failure mode behaviour considering all the failure modes of all the components in the group, -and analysing it is called `symptom abstraction'. +and collecting symptoms of failure, is termed `symptom abstraction'. \ifthenelse {\boolean{paper}} { } { This -is dealt with in detail in chapter \ref{symptom_abstraction}. +is dealt with in detail using an algorithmic description, in section \ref{sec:symptom_abstraction}. } % define difference between a \fg and a \dc A {\fg} is a collection of components, a {\dc} is a new `theorectical' component which has a set of failure modes, which -correspond to the failure modes of the {\fg} it was derived from. -We could consider a {\fg} as a black box, or component -to use, and in this case it would have a set of failure modes. -Looking at the {\fg} in this way is seeing it as a {\dc}. +corresponds to the failure symptoms from the {\fg} from which it was derived. +% +We consider a {\dc} as a black box, or component +for use. +%, and in this case it would have a set of failure modes. +%Looking at the {\fg} in this way is seeing it as a {\dc}. In terms of our UML model, the symptom abstraction process takes a {\fg} and creates a new {\dc} from it. @@ -264,10 +272,10 @@ The UML representation (in figure \ref{fig:cfg}) shows a `functional group' hav The symbol $\bowtie$ is used to indicate the analysis process that takes a functional group and converts it into a new component. - -with $\mathcal{FG}$ represeting the set of all functional groups, and $\mathcal{DC}$ the set of all derived components, -this can be expresed as $ \bowtie : \mathcal{FG} \rightarrow \mathcal{DC} $ . - +\begin{definition} +With $\mathcal{FG}$ represeting the set of all functional groups, and $\mathcal{DC}$ the set of all derived components, +this can be expressed as $$ \bowtie : \mathcal{FG} \rightarrow \mathcal{DC} $$ . +\end{definition} \begin{figure}[h] \centering @@ -279,29 +287,30 @@ this can be expresed as $ \bowtie : \mathcal{FG} \rightarrow \mathcal{DC} $ . \subsection{Keeping track of the derived components position in the hierarchy} -\label{alpha} +\label{sec:alpha} The UML meta model in figure \ref{fig:cfg}, shows the relationships -between the classes and sub-classes. +between the entities used in FMMD. Note that because we can use derived components to build functional groups, -this model intrinsically supports building a hierarchy. +this model intrinsically supports % building a +hierarchy. % In use we will build a hierarchy of -objects, with derived~components forming functional~groups, and creating -derived components higher up in the structure. +objects, functional~groups formed with derived~components, and after symptom~abstraction creating +derived components yet higher up in the structure. % To keep track of the level in the hierarchy (i.e. how many stages of component derivation `$\bowtie$' have lead to the current derived component) we can add an attribute to the component data type. -This can be a natural number called the level variable $\alpha \in \mathbb{N}$. +This can be a natural number called the level variable $\abslev \in \mathbb{N}$. % J. Howse says zero is a given in comp sci. This can be a natural number called the level variable $\alpha \in \mathbb{N}_0$. -The $\alpha$ level variable in each component, +The $\abslev$ level variable in each component, indicates the position in the hierarchy. Base or parts~list components -have a `level' of $\alpha=0$. +have a `level' of $\abslev=0$. % I do not know how to make this simpler Derived~components take a level based on the highest level component used to build the functional group it was derived from plus 1. So a derived component built from base level or parts list components -would have an $\alpha$ value of 1. +would have an $\abslev$ value of 1. %\clearpage @@ -346,14 +355,15 @@ fm : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F} % \label{eqn:fminstance} %\end{equation} -\paragraph{Finding all failure modes within the functional group} +\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 a functional~group. -In a functional group we have a collection of Components -that hold failure mode sets. -We need to collect these failure mode sets and place all the failure -modes into a single set; this can be termed flattening the set of sets. +For FMMD failure % mode analysis %we need to consider the failure modes +%from all the components in a functional~group. +%In a functional group we have a collection of Components +%that hold failure mode sets. +we need to collect failure mode sets from the components and place them all +%modes +into a single set; this can be termed flattening the set of sets. %%Consider the components in a functional group to be $C_1...C_N$. The flat set of failure modes $FSF$ we are after can be found by applying function $fm$ to all the components in the functional~group and taking the union of them thus: @@ -423,13 +433,14 @@ Electrical resistors can fail by going OPEN or SHORTED. For a given resistor R we can apply the function $fm$ to find its set of failure modes thus $ fm(R) = \{R_{SHORTED}, R_{OPEN}\} $. -A resistor cannot fail with the conditions open and short active at the same time! The conditions +A resistor cannot fail with the conditions open and short active at the same time, +that would be physically impossible! The conditions OPEN and SHORT are thus mutually exclusive. Because of this, the failure mode set $F=fm(R)$ is `unitary~state'. - - -Thus because both fault modes cannot be active at the same time, the intersection of $ R_{SHORTED} $ and $ R_{OPEN} $ cannot exist. - +% +% +%Thus because both fault modes cannot be active at the same time, the intersection of $ R_{SHORTED} $ and $ R_{OPEN} $ cannot exist. +% The intersection of these is therefore the empty set, $ R_{SHORTED} \cap R_{OPEN} = \emptyset $, therefore $ fm(R) \in \mathcal{U} $. @@ -467,33 +478,35 @@ we have banned larger combinations as well. -All components must have unitary state failure modes to be used with the FMMD methodology, -for base~components, this is usually the case. Most simple components fail in one +All components must have unitary state failure modes to be used with the FMMD methodology and +for base~components this is usually the case. Most simple components fail in one clearly defined way and generally stay in that state. However, where a complex component is used, for instance a microcontroller with several modules that could all fail simultaneously, a process of reduction into smaller theoretical components will have to be made. -This is sometimes termed `heuristic~de-composition'. -A modern microcontroller will typically have several modules, which are configured to operate on +This is termed `heuristic~de-composition'. +A modern micro-controller will typically have several modules, which are configured to operate on pre-assigned pins on the device. Typically voltage inputs (\adcten / \adctw), digital input and outputs, PWM (pulse width modulation), UARTs and other modules will be found on simple cheap microcontrollers~\cite{pic18f2523}. For instance the voltage reading functions which consist of an ADC multiplexer and ADC can be considered to be components -inside the microcontroller package. -The microcontroller thus becomes a collection of smaller components +inside the micro-controller package. +The micro-controller thus becomes a collection of smaller components that can be analysed separately~\footnote{It is common for the signal paths in a safety critical product to be traced, and when entering a complex -component like a microcontroller, the process of heuristic de-compostion -applied to it}. +component like a micro-controller, the process of heuristic de-compostion +applied to it.}. -\paragraph{Reason for Constraint} Were this constraint to not be applied -each component could not have $N$ failure modes to consider but potentially -$2^N$. This would make the job of analysing the failure modes +\paragraph{Reason for Constraint.} Were this constraint to not be applied +each component would not contribute $N$ failure modes to consider but potentially +$2^N$. +% +This would make the job of analysing the failure modes in a {\fg} impractical due to the sheer size of the task. - +%Note that the `unitary state' conditions apply to failure modes within a component. %%- Need some refs here because that is the way gastec treat the ADC on microcontroller on the servos \section{Handling Simultaneous Component Faults} @@ -501,34 +514,47 @@ in a {\fg} impractical due to the sheer size of the task. For some integrity levels of static analysis, there is a need to consider not only single failure modes in isolation, but cases where more then one failure mode may occur simultaneously. +% Note that the `unitary state' conditions apply to failure modes within a component. -The scenarios presented here are where two or more components fail simultaneously. +This does not preclude the possibility of two or more components failing simultaneously. +% +The scenarios presented deal with possibility of two or more components failing simultaneously. +% It is an implied requirement of EN298~\cite{en298} for instance to -consider double simultaneous faults\footnote{This is under the conditions -of LOCKOUT in an industrial burner controller that has detected one fault already. +consider double simultaneous faults\footnote{Under the conditions +of LOCKOUT~\cite{en298} in an industrial burner controller that has detected one fault already. However, from the perspective of static failure mode analysis, this amounts to dealing with double simultaneous failure modes.}. +% To generalise, we may need to consider $N$ simultaneous -failure modes when analysing a functional group. This involves finding +failure modes when analysing a functional group. +% +This involves finding all combinations of failures modes of size $N$ and less. %The Powerset concept from Set theory is useful to model this. -The powerset, when applied to a set S is the set of all subsets of S, including the empty set +% +The power-set, when applied to a set S is the set of all subsets of S, including the empty set \footnote{The empty set ( $\emptyset$ ) is a special case for FMMD analysis, it simply means there is no fault active in the functional~group under analysis.} and S itself. -In order to consider combinations for the set S where the number of elements in each subset of S is $N$ or less, a concept of the `cardinality constrained powerset' +% +We augment the concept the power-set concept here to deal with counting the number of +combinations of failures to consider, under the conditions of simultaneous failures. +% +In order to consider combinations for the set S where the number of elements in +each subset of S is $N$ or less, a concept of the `cardinality constrained power-set' is proposed and described in the next section. %\pagebreak[1] \subsection{Cardinality Constrained Powerset } \label{ccp} -A Cardinality Constrained powerset is one where subsets of a cardinality greater than a threshold +A Cardinality Constrained power-set is one where subsets of a cardinality greater than a threshold are not included. This threshold is called the cardinality constraint. To indicate this, the cardinality constraint $cc$ is subscripted to the powerset symbol thus $\mathcal{P}_{cc}$. Consider the set $S = \{a,b,c\}$. -The powerset of S: +The power-set of S: $$ \mathcal{P} S = \{ \emptyset, \{a,b,c\}, \{a,b\},\{b,c\},\{c,a\},\{a\},\{b\},\{c\} \} .$$ @@ -565,7 +591,7 @@ from $1$ to $cc$ thus % \begin{equation} - |{\mathcal{P}_{cc}S}| = \sum^{cc}_{k=1} \frac{|{S}|!}{ k! ( |{S}| - k)!} . + |{\mathcal{P}_{cc}S}| = \sum^{cc}_{k=1} \frac{|{S}|!}{ cc! ( |{S}| - cc)!} . % was k in the frac part now cc \label{eqn:ccps} \end{equation} @@ -733,17 +759,19 @@ associated with the test cases, complete coverage would be verified. \section{Component Failure Modes and Statistical Sample Space} %\paragraph{NOT WRITTEN YET PLEASE IGNORE} A sample space is defined as the set of all possible outcomes. -For a component in FMMD analysis, this set of all possible outcomes is its normal correct +For a component in FMMD analysis, this set of all possible outcomes is its normal--or--correct operating state and all its failure modes. -We are thus considering the failure modes as events in the sample space. +We can consider failure modes as events in the sample space. % When dealing with failure modes, we are not interested in -the state where the component is working perfectly or `OK' (i.e. operating with no error). +the state where the component is working correctly or `OK' (i.e. operating with no error). % We are interested only in ways in which it can fail. -By definition while all components in a system are `working perfectly' +By definition while all components in a system are `working~correctly' that system will not exhibit faulty behaviour. +% We can say that the OK state corresponds to the empty set. +% Thus the statistical sample space $\Omega$ for a component or derived~component $C$ is %$$ \Omega = {OK, failure\_mode_{1},failure\_mode_{2},failure\_mode_{3} ... failure\_mode_{N} $$ $$ \Omega(C) = \{OK, failure\_mode_{1},failure\_mode_{2},failure\_mode_{3}, \ldots ,failure\_mode_{N}\} . $$ @@ -753,10 +781,10 @@ $ fm(C) = \Omega(C) \backslash \{OK\} $ (or expressed as $ \Omega(C) = fm(C) \cup \{OK\} $). -The $OK$ statistical case is the largest in probability, and is therefore +The $OK$ statistical case is the (usually) the largest in probability, and is therefore of interest when analysing systems from a statistical perspective. This is of interest for the application of conditional probability calculations -such as Bayes theorem~\cite{probstat}; +such as Bayes theorem~\cite{probstat}. The current failure modelling methodologies (FMEA, FMECA, FTA, FMEDA) all use Bayesian statistics to justify their methodologies~\cite{nucfta}\cite{nasafta}. @@ -769,7 +797,7 @@ all sets within $\Omega$ are partitioned. Figure \ref{fig:partitioncfm} shows a partitioned set representing component failure modes $\{ B_1 ... B_8, OK \}$ : partitioned sets where the OK or empty set condition is included, obey unitary state conditions. -Because the subsets of $\Omega$ are partitionned we can say these +Because the subsets of $\Omega$ are partitioned we can say these failure modes are unitary state. \begin{figure}[h] @@ -797,7 +825,7 @@ create a derived component. This technique is outside the scope of this paper. } { -This technique is dealt in chapter \ref{fmmd_complex_comp} which shows how derived components may be assembled. +%This technique is dealt in section \ref{sec:symtomabstraction} which shows how derived components may be assembled. } \begin{figure}[h] @@ -870,16 +898,25 @@ We can express their probabilities as $P(B_4) = P(B_1 \cap B_3)$ and $P(B_5) = P %%- \section{Complete UML Diagram} -For a complete UML data model we need to consider the System -as an object. This holds a parts list, and is the -key reference point in the data structure. +In this section we examine the entities used in FMMD and their relationships. +We have been building parts of the data structure up until now, +and we can now complete the picture. +For the complete UML data model we need to consider the System +as a data structure. + +The `parts~list' is the +key reference point and starting point. % in the data structure. +Our base components are kept here. +From these the initial {\fgs} are formed, and from the {\fgs} +{\dcs}. Two other data types/entities are required however: we need to model environmental and operational states and +where they fit into the data structure. A real life system will be expected to perform in a given environment. Environment in the context of this study means external influences the System could be expected to work under. A typical data sheet for an electrical component will give a working temperature range for instance. -Mechanical components will be specified for stress and loading limits. +Mechanical components could be specified for stress and loading limits. \paragraph{Environmental Modelling.} The external influences/environment could typically be temperature ranges, levels of electrical interference, high voltage contamination on supply @@ -891,19 +928,28 @@ can be eliminated by down-rating of components as discussed in section~\ref{down With given environmental constraints, we can therefore eliminate some failure modes from the model. \paragraph{Operational states.} Within the field of safety critical engineering we often encounter -sub-system that include test facilities. We also encounter degraded performance +sub-system that include test facilities. +% +We also encounter degraded performance (such as only performing functions in an emergency) and lockout conditions. -These can be broadly termed operational states, and apply to the -functional groups. +These can be broadly termed operational states. %, and apply to the +%functional groups. +% +We need to determine which UML class is most appropriate to hold a relationship +to operational states. +% Consider for instance an electrical circuit that has a TEST line. When the TEST line is activated, it supplies a test signal which will validate the circuit. This circuit will have two operational states, NORMAL and TEST mode. -It is natural to apply the operational states to functional groups. +% +It seems better to apply the operational states to functional groups. +% Functional groups by definition implement functionality, or purpose of particular sub-systems, and therefore are the best objects to model -operational states. -\paragraph{Inhibit Conditions} +operational states.% with. + +\paragraph{Inhibit Conditions.} Some failure modes may only be active given specific environmental conditions or when other failures are already active. To model this, an `inhibit' class has been added. @@ -928,6 +974,7 @@ are added to UML diagram in figure \ref{fig:cfg} and represented in figure \ref +%% XXX bit of a loose end here, maybe delete this \subsection{Ontological work on FMEA} @@ -1015,11 +1062,11 @@ as an argument and returns a newly created {\dc}. %The $\bowtie$ analysis, a symptom extraction process, is described in chapter \ref{chap:sympex}. The symptom abstraction process must always raise the abstraction level for the newly created {\dc}. -Using $\abslevel$ to symbolise the fault abstraction level, we can now state: +Using $\abslev$ (as described in~\ref{sec:alpha}) to symbolise the fault abstraction level, we can now state: -$$ \bowtie({\FG}^{\abslevel}) \rightarrow c^{{\abslevel}+N} | N \ge 1. $$ +$$ \bowtie({\FG}^{\abslev}) \rightarrow c^{{\abslev}+N} | N \ge 1. $$ -\paragraph{Functional Groups may be indexed} +\paragraph{Functional Groups may be indexed.} We will typically have more than one {\fg} on each level of FMMD hierarchy ( expect the top level where there will only be one) we could index the {\fgs} with a sub-script, and can then uniquely identify them using their level and their index. For example ${\FG}^{3}_{2}$ would be the second {\fg} at the third level of abstraction in an FMMD hierarchy. @@ -1050,13 +1097,16 @@ By applying stages of analysis to higher and higher abstraction levels, we can converge to a complete failure mode model of the system under analysis. Because the symptom abstraction process is defined as surjective (from component failure modes to symptoms) the number of symptoms is guaranteed to be less than or equal to -the number of component failure modes. +the number of component failure modes. This means the top level {\dc} in a hierarchy should have a number of {\fms} less than or equal +to the sum of {\fms} in its base components. In practise however, the number of symptoms greatly reduces as we traverse up the hierarchy. -This is a natural process. When we have complicated systems -they always have a small number of system failure modes in comparison to -the number of failure modes in its sub-systems/components.. +The is echoed in real life systems, where the top level events/failures +are always orders of magnitude smaller than sum of {\fms} in its base components. +%This is a natural process. When we have complicated systems +%they always have a small number of system failure modes in comparison to +%the number of failure modes in its sub-systems/components.. \section{Examples of Derived Component like concepts in safety literature} @@ -1064,27 +1114,30 @@ the number of failure modes in its sub-systems/components.. Idea stage on this section, integrated circuits and some compond parts (like digital resistors) are treated like base components. i.e. this sets a precedent for {\dcs}. +RE WRITE ---- concept is that some complicated components, like 741 are treated as simple components +in the literature. + \begin{itemize} \item Look at OPAMP circuits, pick one (say $\mu$741) - \item Digital transistor perhaps, inside two resistors and a transistor. - \item outline a proposed FMMD analysis - \item Show FMD-91 OPAMP failure modes -- compare with FMMD +% \item Digital transistor perhaps, inside two resistors and a transistor. +% \item outline a proposed FMMD analysis +% \item Show FMD-91 OPAMP failure modes -- compare with FMMD \end{itemize} -The gas burner standard (EN298~\cite{en298}), only considers OPEN and SHORT for resistors -(and for some types of resistors OPEN only). -FMD-91~\cite{fmd91}(the US military failure modes guide) also includes `parameter change' in its description of resistor failure modes. -Now a resistor will generally only suffer parameter change when over stressed. -EN298 stipulates down rating by 60\% to maximum stress -possible in a circuit. So even if you have a resistor that preliminary tells you would -never be subjected to say more than 5V, but there is say, a 24V rail -on the circuit, you have to choose resistors able to cope with the 24V -stress/load and then down rate by 60\%. That is to say the resitor should be rated for a maximum -voltage of $ > 38.4V$ and should be rated 60\% higher for its power consumption at $38.4V$. -Because of down-rating, it is reasonable to not have to consider parameter change under EN298 approvals. - -\clearpage -Two areas that cannot be automated. Choosing {\fgs} and the analysis/symptom collection process itself. +% The gas burner standard (EN298~\cite{en298}), only considers OPEN and SHORT for resistors +% (and for some types of resistors OPEN only). +% FMD-91~\cite{fmd91}(the US military failure modes guide) also includes `parameter change' in its description of resistor failure modes. +% Now a resistor will generally only suffer parameter change when over stressed. +% EN298 stipulates down rating by 60\% to maximum stress +% possible in a circuit. So even if you have a resistor that preliminary tells you would +% never be subjected to say more than 5V, but there is say, a 24V rail +% on the circuit, you have to choose resistors able to cope with the 24V +% stress/load and then down rate by 60\%. That is to say the resitor should be rated for a maximum +% voltage of $ > 38.4V$ and should be rated 60\% higher for its power consumption at $38.4V$. +% Because of down-rating, it is reasonable to not have to consider parameter change under EN298 approvals. +% +% \clearpage +% Two areas that cannot be automated. Choosing {\fgs} and the analysis/symptom collection process itself. \subsection{{\fgs} Sharing components and Hierarchy} @@ -1115,11 +1168,11 @@ in figure~\ref{fig:shared_component}. \label{fig:shared_component} \end{figure} -\subsection{Hierarchy and structure} -By having this structure, the logic circuit element, can accept failure modes from the -power-supply (for instance these might, for the sake of example include: $NO\_POWER$, $LOW\_VOLTAGE$, $HIGH\_VOLTAGE$, $NOISE\_HF$, $NOISE\_LF$. -Our logic circuit may be able to cope with $LOW\_VOLTAGE$ and $NOISE\_LF$, but react with a serious symptom to $NOISE\_HF$ say. -But in order to process these failure modes it must be at a higher stage in the FMMD hierarchy. +% \subsection{Hierarchy and structure} +% By having this structure, the logic circuit element, can accept failure modes from the +% power-supply (for instance these might, for the sake of example include: $NO\_POWER$, $LOW\_VOLTAGE$, $HIGH\_VOLTAGE$, $NOISE\_HF$, $NOISE\_LF$. +% Our logic circuit may be able to cope with $LOW\_VOLTAGE$ and $NOISE\_LF$, but react with a serious symptom to $NOISE\_HF$ say. +% But in order to process these failure modes it must be at a higher stage in the FMMD hierarchy. \pagebreak[4] \section{Defining the concept of `comparison~complexity' in FMEA} @@ -1132,7 +1185,7 @@ But in order to process these failure modes it must be at a higher stage in the When performing FMEA we have a system under investigation, which will comprise of a collection of components which have associated failure modes. The object of FMEA is to determine cause and effect: -from the failure modes (the causes) to the effects (or symptoms of failure). +from the failure modes (the causes, {\fms} of {\bcs}) to the effects (or symptoms of failure) at the top level. % To perform FMEA rigorously we could stipulate that every failure mode must be checked for effects @@ -1518,6 +1571,8 @@ For Functional Group 2 (FG2), let us map: FS5 & \mapsto & S6 \\ FS6 & \mapsto & S5 \end{eqnarray*} +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 diff --git a/submission_thesis/CH5_Examples/copy.tex b/submission_thesis/CH5_Examples/copy.tex index 331fd23..d4f32b6 100644 --- a/submission_thesis/CH5_Examples/copy.tex +++ b/submission_thesis/CH5_Examples/copy.tex @@ -3,6 +3,7 @@ This chapter demonstrates FMMD applied to a variety of common electronic circuits. +In order to implement FMMD in practise, we review the basic concepts and processes of the methodology. \section{Basic Concepts Of FMMD} @@ -60,7 +61,7 @@ Failure modes for part types can be found in the literature~\cite{fmd91}\cite{mi \subsection{Determining the failure modes of components} - +\label{sec:determine_fms} In order to apply any form of Failure Mode Effects Analysis (FMEA) we need to know the ways in which the components we are using can fail. Typically when choosing components for a design, we look at manufacturers' data sheets, which describe the environmental ranges and tolerances, and can indicate how a component may fail/behave @@ -195,7 +196,8 @@ and thus subject to drift/parameter change. %In a system designed to typical safety critical constraints (as in EN298) %these environmentally induced failure modes need not be considered. - +\subsubsection{Resistor Failure Modes} +\label{sec:res_fms} For this study we will take the conservative view from EN298, and consider the failure modes for a generic resistor to be both OPEN and SHORT. i.e. @@ -244,10 +246,10 @@ a signal may be lost. We can map this failure cause to a {\fm}, and we can call it $LOW_{slew}$. \paragraph{No Operation - over stress} -Here the OP\_AMP has been damaged, and the output may be held HIGH LOW, or may be effectively tri-stated +Here the OP\_AMP has been damaged, and the output may be held HIGH or LOW, or may be effectively tri-stated , i.e. not able to drive circuitry in along the next stages of the signal path: we can call this state NOOP (no Operation). % -We can map this failure cause to three symptoms, $LOW$, $HIGH$, $NOOP$. +We can map this failure cause to three {\fms}, $LOW$, $HIGH$, $NOOP$. \paragraph{Shorted $V_+$ to $V_-$} Due to the high intrinsic gain of an op-amp, and the effect of offset currents, @@ -339,10 +341,18 @@ and determine its {\fms}. %\clearpage +\subsubsection{Failure modes of an OP-AMP} + +\label{sec:opamp_fms} +For the purpose of the examples to follow, the op-amp will +have the following failure modes:- + +$$ fm(OPAMP) = \{ LOW, HIGH, NOOP, LOW_{slew} \} $$ \subsection{Comparing the component failure mode sources} + The EN298 pinouts failure mode technique cannot reveal failure modes due to internal failures. The FMD-91 entires for op-amps are not directly usable as component {\fms} in FMEA or FMMD and require interpretation. @@ -350,10 +360,6 @@ component {\fms} in FMEA or FMMD and require interpretation. %For our OP-AMP example could have come up with different symptoms for both sides. Cannot predict the effect of internal errors, for instance ($LOW_{slew}$) %is missing from the EN298 failure modes set. -For the purpose of the examples to follow, the op-amp will -have the following failure modes:- - -$$ fm(OPAMP) = \{ LOW, HIGH, NOOP, LOW_{slew} \} $$ % FMD-91 % @@ -441,7 +447,7 @@ We can now treat $AMP1$ as a pre-analysed, higher level component. The amplifier is an abstract concept, in terms of the components. To a make an `amplifier' we have to connect a a group of components in a specific configuration. This specific configuration corresponds to -a {\fg}. Our use of it as a building block corresponds to a {\dc}. +a {\fg}. Our use of it as a subsequent building block corresponds to a {\dc}. %What this means is the `fault~symptoms' of the module have been derived. @@ -540,13 +546,14 @@ We can now create a {\dc} for the potential divider, $PD$. $$ fm(PD) = \{ PDLow, PDHigh \}$$ -Let us now consider the op-amp. According to -FMD-91~\cite{fmd91}[3-116] an op-amp may have the following failure modes: -latchup(12.5\%), latchdown(6\%), nooperation(31.3\%), lowslewrate(50\%). +%Let us now consider the op-amp. According to +%FMD-91~\cite{fmd91}[3-116] an op-amp may have the following failure modes: +%latchup(12.5\%), latchdown(6\%), nooperation(31.3\%), lowslewrate(50\%). \subsection{Analysing the non-inverting amplifier in terms of failure modes} +From section~\ref{sec:opamp_fms} $$ fm(OPAMP) = \{L\_{up}, L\_{dn}, Noop, L\_slew \} $$ @@ -1256,7 +1263,7 @@ could be easily detected; the failure symptom $FilterIncorrect$ may be less obs %\section{Standard Non-inverting OP AMP} This circuit is described in the Analog Applications Journal~\cite{bubba}[p.37]. -The circuit uses four 45 degree phase shifts, and an inverting amplifier to provide +The circuit implements an oscillator using four 45 degree phase shifts, and an inverting amplifier to provide gain and the final 180 degrees of phase shift (making a total of 360 degrees of phase shift). From a fault finding perspective this circuit is less than ideal. @@ -1751,6 +1758,7 @@ T%he block diagram in figure~\ref{fig \clearpage \section{Pt100 Analysis: Double failures and MTTF statistics} +\label{sec:Pt100} { This section % shows a practical example of @@ -1794,16 +1802,16 @@ diagrams to assist the reasoning process. This chapter describes taking the failure modes of the components, analysing the circuit using FMEA and producing a failure mode model for the circuit as a whole. -Thus after the analysis the Pt100 temperature sensing circuit, may be viewed +Thus after the analysis the $Pt100$ temperature sensing circuit, may be viewed from an FMEA perspective as a component itself, with a set of known failure modes. } \begin{figure}[h] \centering \includegraphics[width=400pt,bb=0 0 714 180,keepaspectratio=true]{./CH5_Examples/pt100.png} - % pt100.jpg: 714x180 pixel, 72dpi, 25.19x6.35 cm, bb=0 0 714 180 - \caption{PT100 four wire circuit} - \label{fig:pt100} + % Pt100.jpg: 714x180 pixel, 72dpi, 25.19x6.35 cm, bb=0 0 714 180 + \caption{Pt100 four wire circuit} + \label{fig:Pt100} \end{figure} @@ -1821,16 +1829,16 @@ look-up tables or a suitable polynomial expression. \begin{figure}[h] \centering \includegraphics[width=150pt,bb=0 0 273 483,keepaspectratio=true]{./CH5_Examples/vrange.png} - % pt100.jpg: 714x180 pixel, 72dpi, 25.19x6.35 cm, bb=0 0 714 180 - \caption{PT100 expected voltage ranges} - \label{fig:pt100vrange} + % Pt100.jpg: 714x180 pixel, 72dpi, 25.19x6.35 cm, bb=0 0 714 180 + \caption{Pt100 expected voltage ranges} + \label{fig:Pt100vrange} \end{figure} The voltage ranges we expect from this three stage potential divider\footnote{ two stages are required for validation, a third stage is used to measure the current flowing through the circuit to obtain accurate temperature readings} -are shown in figure \ref{fig:pt100vrange}. Note that there is +are shown in figure \ref{fig:Pt100vrange}. Note that there is an expected range for each reading, for a given temperature span. Note that the low reading goes down as temperature increases, and the higher reading goes up. For this reason the low reading will be referred to as {\em sense-} @@ -1841,7 +1849,7 @@ and the higher as {\em sense+}. For electronic and accuracy reasons, a four wire circuit is preferred because of resistance in the cables. Resistance from the supply causes a slight voltage -drop in the supply to the Pt100. As no significant current +drop in the supply to the $Pt100$. As no significant current is carried by the two `sense' lines, the resistance back to the ADC causes only a negligible voltage drop, and thus the four wire configuration is more accurate\footnote{The increased accuracy is because the voltage measured, is the voltage across @@ -1853,12 +1861,12 @@ The current flowing though the whole circuit can be measured on the PCB by reading a third sense voltage from one of the load resistors. Knowing the current flowing through the circuit -and knowing the voltage drop over the PT100, we can calculate its +and knowing the voltage drop over the $Pt100$, we can calculate its resistance by Ohms law $V=I.R$, $R=\frac{V}{I}$. Thus a little loss of supply current due to resistance in the cables does not impinge on accuracy. The resistance to temperature conversion is achieved -through the published Pt100 tables\cite{eurothermtables}. +through the published $Pt100$ tables\cite{eurothermtables}. The standard voltage divider equations (see figure \ref{fig:vd} and equation \ref{eqn:vd}) can be used to calculate expected voltages for failure mode and temperature reading purposes. @@ -1879,7 +1887,7 @@ expected voltages for failure mode and temperature reading purposes. \subsection{Safety case for 4 wire circuit} -This sub-section looks at the behaviour of the PT100 four wire circuit +This sub-section looks at the behaviour of the $Pt100$ four wire circuit for the effects of component failures. All components have a set of known `failure modes'. In other words we know that a given component can fail in several distinct ways. @@ -1895,22 +1903,22 @@ Where this occurs a circuit re-design is probably the only sensible course of ac \fmodegloss -\paragraph{Single Fault FMEA Analysis of Pt100 Four wire circuit} +\paragraph{Single Fault FMEA Analysis of $Pt100$ Four wire circuit} \label{fmea} The PTt00 circuit consists of three resistors, two `current~supply' wires and two `sensor' wires. -Resistors according to the European Standard EN298:2003~\cite{en298}[App.A] -, are considered to fail by either going OPEN or SHORT circuit\footnote{EN298:2003~\cite{en298} also requires that components are downrated, -and so in the case of resistors the parameter change failure mode~\cite{fmd-91}[2-23] can be ommitted.}. +Resistors %according to the European Standard EN298:2003~\cite{en298}[App.A] +, are considered to fail by either going OPEN or SHORT (see section~\ref{sec:res_fms}). %circuit\footnote{EN298:2003~\cite{en298} also requires that components are downrated, +%and so in the case of resistors the parameter change failure mode~\cite{fmd-91}[2-23] can be ommitted.}. %Should wires become disconnected these will have the same effect as %given resistors going open. For the purpose of this analyis; $R_{1}$ is the \ohms{2k2} from 5V to the thermistor, -$R_3$ is the PT100 thermistor and $R_{2}$ connects the thermistor to ground. +$R_3$ is the Pt100 thermistor and $R_{2}$ connects the thermistor to ground. We can define the terms `High Fault' and `Low Fault' here, with reference to figure -\ref{fig:pt100vrange}. Should we get a reading outside the safe green zone +\ref{fig:Pt100vrange}. Should we get a reading outside the safe green zone in the diagram we can consider this a fault. Should the reading be above its expected range this is a `High Fault' and if below a `Low Fault'. @@ -1946,14 +1954,14 @@ $R_2$ SHORT & - & Low Fault & Value Out of Range Value \\ From table \ref{ptfmea} it can be seen that any component failure in the circuit should cause a common symptom, that of one or more of the values being `out of range'. Temperature range calculations and detailed calculations -on the effects of each test case are found in section \ref{pt100range} -and \ref{pt100temp}. +on the effects of each test case are found in section \ref{Pt100range} +and \ref{Pt100temp}. %\paragraph{Consideration of Resistor Tolerance} % -%The separate sense lines ensure the voltage read over the PT100 thermistor are not +%The separate sense lines ensure the voltage read over the Pt100 thermistor are not %altered due to having to pass any significant current. -%The PT100 element is a precision part and will be chosen for a specified accuracy/tolerance range. +%The Pt100 element is a precision part and will be chosen for a specified accuracy/tolerance range. %One or other of the load resistors (the one we measure current over) should also %be of this accuracy. % @@ -1961,21 +1969,21 @@ and \ref{pt100temp}. %(typically $\leq \; 50(ppm)\Delta R \propto \Delta \oc $), and should be subjected to %a narrow temperature range anyway, being mounted on a PCB. %\glossary{{PCB}{Printed Circuit Board}} -%To calculate the resistance of the PT100 element % (and thus derive its temperature), +%To calculate the resistance of the Pt100 element % (and thus derive its temperature), %having the voltage over it, we now need the current. %Lets use, for the sake of example $R_2$ to measure the current flowing in the temperature sensor loop. %As the voltage over $R_3$ is relative (a design feature to eliminate resistance effects of the cables). %We can calculate the current by reading -%the voltage over the known resistor $R2$.\footnote{To calculate the resistance of the PT100 we need the current flowing though it. +%the voltage over the known resistor $R2$.\footnote{To calculate the resistance of the Pt100 we need the current flowing though it. %We can determine this via ohms law applied to $R_2$, $V=IR$, $I=\frac{V}{R_2}$, %and then using $I$, we can calculate $R_{3} = \frac{V_{R3}}{I}$.} %As these calculations are performed by ohms law, which is linear, the accuracy of the reading %will be determined by the accuracy of $R_2$ and $R_{3}$. It is reasonable to %take the mean square error of these accuracy figures. -\paragraph{Range and PT100 Calculations} -\label{pt100temp} -Pt100 resistors are designed to +\paragraph{Range and $Pt100$ Calculations} +\label{Pt100temp} +$Pt100$ resistors are designed to have a resistance of \ohms{100} at {0\oc} \cite{aoe},\cite{eurothermtables}. A suitable `wider than to be expected range' was considered to be {0\oc} to {300\oc} for a given application. @@ -1990,8 +1998,8 @@ As the Pt100 forms a potential divider with the \ohms{2k2} load resistors, the upper and lower readings can be calculated thus: -$$ highreading = 5V.\frac{2k2+pt100}{2k2+2k2+pt100} $$ -$$ lowreading = 5V.\frac{2k2}{2k2+2k2+pt100} $$ +$$ highreading = 5V.\frac{2k2+Pt100}{2k2+2k2+pt100} $$ +$$ lowreading = 5V.\frac{2k2}{2k2+2k2+Pt100} $$ So by defining an acceptable measurement/temperature range, and ensuring the values are always within these bounds, we can be confident that none of the @@ -1999,8 +2007,8 @@ resistors in this circuit has failed. To convert these to twelve bit ADC (\adctw) counts: -$$ highreading = 2^{12}.\frac{2k2+pt100}{2k2+2k2+pt100} $$ -$$ lowreading = 2^{12}.\frac{2k2}{2k2+2k2+pt100} $$ +$$ highreading = 2^{12}.\frac{2k2+Pt100}{2k2+2k2+pt100} $$ +$$ lowreading = 2^{12}.\frac{2k2}{2k2+2k2+Pt100} $$ \begin{table}[ht] @@ -2030,7 +2038,7 @@ will detect it. \paragraph{Consideration of Resistor Tolerance.} % -The separate sense lines ensure the voltage read over the Pt100 thermistor is not +The separate sense lines ensure the voltage read over the $Pt100$ thermistor is not altered by to having to pass any significant current. The current is supplied by separate wires and the resistance in those are effectively cancelled out by considering the voltage reading over $R_3$ to be relative. @@ -2058,7 +2066,7 @@ will be determined by the accuracy of $R_2$ and $R_{3}$. It is reasonable to take the mean square error of these accuracy figures~\cite{easp}. -\paragraph{Single Fault FMEA Analysis of PT100 Four wire circuit} +\paragraph{Single Fault FMEA Analysis of $Pt100$ Four wire circuit} \ifthenelse{\boolean{pld}} @@ -2073,10 +2081,10 @@ and are thus enclosed by one contour each. \fmodegloss \begin{figure}[h] \centering - \includegraphics[width=400pt,bb=0 0 518 365,keepaspectratio=true]{./CH5_Examples/pt100_tc.png} - % pt100_tc.jpg: 518x365 pixel, 72dpi, 18.27x12.88 cm, bb=0 0 518 365 + \includegraphics[width=400pt,bb=0 0 518 365,keepaspectratio=true]{./CH5_Examples/Pt100_tc.png} + % Pt100_tc.jpg: 518x365 pixel, 72dpi, 18.27x12.88 cm, bb=0 0 518 365 \caption{Pt100 Component Failure Modes} - \label{fig:pt100_tc} + \label{fig:Pt100_tc} \end{figure} } % \ifthenelse {\boolean{pld}} @@ -2173,38 +2181,40 @@ resistors in this circuit has failed. { \begin{figure}[h] \centering - \includegraphics[width=400pt,bb=0 0 518 365,keepaspectratio=true]{./CH5_Examples/pt100_tc_sp.png} - % pt100_tc.jpg: 518x365 pixel, 72dpi, 18.27x12.88 cm, bb=0 0 518 365 - \caption{PT100 Component Failure Modes} - \label{fig:pt100_tc_sp} + \includegraphics[width=400pt,bb=0 0 518 365,keepaspectratio=true]{./CH5_Examples/Pt100_tc_sp.png} + % Pt100_tc.jpg: 518x365 pixel, 72dpi, 18.27x12.88 cm, bb=0 0 518 365 + \caption{Pt100 Component Failure Modes} + \label{fig:Pt100_tc_sp} \end{figure} } \subsection{Derived Component : The Pt100 Circuit} The Pt100 circuit can now be treated as a component in its own right, and has one failure mode, -{\textbf OUT\_OF\_RANGE}. +{\textbf OUT\_OF\_RANGE}. This is a single, detectable failure mode. The observability of a +fault condition is very good with this circuit.This should not be a surprise, as the four wire $Pt100$ +has been developed for safety critical temperature measurement. % \ifthenelse{\boolean{pld}} { -It can now be represnted as a PLD see figure \ref{fig:pt100_singlef}. +It can now be represented as a PLD see figure \ref{fig:Pt100_singlef}. \begin{figure}[h] \centering - \includegraphics[width=100pt,bb=0 0 167 194,keepaspectratio=true]{./CH5_Examples/pt100_singlef.png} - % pt100_singlef.jpg: 167x194 pixel, 72dpi, 5.89x6.84 cm, bb=0 0 167 194 - \caption{PT100 Circuit Failure Modes : From Single Faults Analysis} - \label{fig:pt100_singlef} + \includegraphics[width=100pt,bb=0 0 167 194,keepaspectratio=true]{./CH5_Examples/Pt100_singlef.png} + % Pt100_singlef.jpg: 167x194 pixel, 72dpi, 5.89x6.84 cm, bb=0 0 167 194 + \caption{Pt100 Circuit Failure Modes : From Single Faults Analysis} + \label{fig:Pt100_singlef} \end{figure} } %From the single faults (cardinality constrained powerset of 1) analysis, we can now create -%a new derived component, the {\empt100circuit}. This has only \{ OUT\_OF\_RANGE \} +%a new derived component, the {\emPt100circuit}. This has only \{ OUT\_OF\_RANGE \} %as its single failure mode. %Interestingly we can calculate the failure statistics for this circuit now. -%Mill 1991 gives resistor stats of ${10}^{11}$ times 6 (can we get special stats for pt100) ??? +%Mill 1991 gives resistor stats of ${10}^{11}$ times 6 (can we get special stats for Pt100) ??? %\clearpage \subsection{Mean Time to Failure} @@ -2487,14 +2497,14 @@ $$ NoOfTestCasesToCheck = 6 + 15 - ( 1 + 1 + 1 ) = 18 $$ As the test case are all different and are of the correct cardinalities (6 single faults and (15-3) double) we can be confident that we have looked at all `double combinations' of the possible faults -in the pt100 circuit. The next task is to investigate +in the Pt100 circuit. The next task is to investigate these test cases in more detail to prove the failure mode hypothesis set out in table \ref{tab:ptfmea2}. \paragraph{Proof of Double Faults Hypothesis } \paragraph{ TC 7 : Voltages $R_1$ OPEN $R_2$ OPEN } -\label{pt100:bothfloating} +\label{Pt100:bothfloating} This double fault mode produces an interesting symptom. Both sense lines are floating. We cannot know what the {\adctw} readings on them will be. @@ -2613,7 +2623,7 @@ As a symptom $TC\_7$ could be described as $FLOATING$. { We can thus draw a PLD diagram representing the failure modes of this functional~group, the Pt100 circuit from the perspective of double simultaneous failures, -in figure \ref{fig:pt100_doublef}. +in figure \ref{fig:Pt100_doublef}. \begin{figure}[h] \centering @@ -2633,13 +2643,13 @@ The Pt100 circuit again, can now be treated as a component in its own right, and \ifthenelse{\boolean{pld}} { -It can now be represented as a PLD see figure \ref{fig:pt100_doublef}. +It can now be represented as a PLD see figure \ref{fig:Pt100_doublef}. \begin{figure}[h] \centering - \includegraphics[width=100pt,bb=0 0 167 194,keepaspectratio=true]{./CH5_Examples/pt100_doublef.png} - % pt100_singlef.jpg: 167x194 pixel, 72dpi, 5.89x6.84 cm, bb=0 0 167 194 + \includegraphics[width=100pt,bb=0 0 167 194,keepaspectratio=true]{./CH5_Examples/Pt100_doublef.png} + % Pt100_singlef.jpg: 167x194 pixel, 72dpi, 5.89x6.84 cm, bb=0 0 167 194 \caption{Pt100 Circuit Failure Modes : From Double Faults Analysis} - \label{fig:pt100_doublef} + \label{fig:Pt100_doublef} \end{figure} } % \ifthenelse {\boolean{pld}} { diff --git a/submission_thesis/mybib.bib b/submission_thesis/mybib.bib index 6bd88ea..b818d6c 100644 --- a/submission_thesis/mybib.bib +++ b/submission_thesis/mybib.bib @@ -137,9 +137,18 @@ YEAR = "1992" } +@BOOK{opmanage, + AUTHOR = "Roger Schroeder", + TITLE = "Operations Management: Contemporary Concepts and Cases ISBN: 978-0073403380", + PUBLISHER = "McGraw-Hill", + YEAR = "2010" +} + +% Safeware: System safety and Computers + @BOOK{safeware, AUTHOR = "Nancy Leveson", - TITLE = "Safeware: System safety and Computers ISBN: 0-201-11972-2", + TITLE = " Safeware: System safety and Computers ISBN: 0-201-11972-2", PUBLISHER = "Addison-Wesley", YEAR = "2005" } diff --git a/submission_thesis/style.tex b/submission_thesis/style.tex index ef65d2b..f230bec 100644 --- a/submission_thesis/style.tex +++ b/submission_thesis/style.tex @@ -15,13 +15,14 @@ \setlength{\textwidth}{160mm} \setlength{\textheight}{220mm} \setlength{\oddsidemargin}{0mm} \setlength{\evensidemargin}{0mm} % +\newcommand{\abslev}{\ensuremath{\alpha}} \newcommand{\oc}{\ensuremath{^{o}{C}}} \newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}} \newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}} \newcommand{\ohms}[1]{\ensuremath{#1\Omega}} \newcommand{\fm}{\em failure~mode} \newcommand{\fms}{\em failure~modes} -\newcommand{\FG}{\ensuremath{\mathbb{G}}} +\newcommand{\FG}{\ensuremath{{G}}} \newcommand{\fg}{\em functional~group} \newcommand{\fgs}{\em functional~groups} \newcommand{\dc}{\em derived~component} @@ -35,7 +36,7 @@ \newcommand{\pic}{\em pair-wise~intersection~chain} \newcommand{\wrt}{\em with~respect~to} \newcommand{\swf}{software~function} -\newcommand{\abslevel}{\ensuremath{\Psi}} +% DO NOT USE THIS ONE USE \abslev \newcommand{\abslevel}{\ensuremath{\Psi}} \newcommand{\fmmdgloss}{\glossary{name={FMMD},description={Failure Mode Modular De-Composition, a bottom-up methodolgy for incrementally building failure mode models, using a procedure taking functional groups of components and creating derived components representing them, and in turn using the derived components to create higher level functional groups, and so on, that are used to build a failure mode model of a SYSTEM}}} \newcommand{\fmodegloss}{\glossary{name={failure mode},description={The way in which a failure occurs. A component or sub-system may fail in a number of ways, and each of these is a failure mode of the component or sub-system}}} diff --git a/submission_thesis/titlepage/titlepage.tex b/submission_thesis/titlepage/titlepage.tex index bc9b897..772d8c0 100644 --- a/submission_thesis/titlepage/titlepage.tex +++ b/submission_thesis/titlepage/titlepage.tex @@ -10,8 +10,17 @@ \vspace{2.15in} -{ \bf A proposed modularisation of Failure Mode Effects Analysis.} - +{ \bf A methodology for the modularisation of Failure Mode Effects Analysis.} + +\vspace{1.15in} +{ +Modularising FMEA has benefits of rigor, re-usability of analysis +and the integration of hardware and software in failure effects modelling. +} + + + + \vspace{1.15in} {\LARGE \bf Brighton University } @@ -22,10 +31,8 @@ \vspace{1.0in} -{\large Version 1.0 \today } -\vspace{0.2in} -{\large Author : R.P. Clark - 2010 } +{\large Author : R.P. Clark - \today } \end{center} From 61f4fa0f8893f83df4f1ee74ed4bd9a101966ffa Mon Sep 17 00:00:00 2001 From: Your Name Date: Thu, 12 Apr 2012 20:34:32 +0100 Subject: [PATCH 2/4] Tacked the symptom abstraction from old_thesis symptom_ex_process into CH4. I think I have repeated the basic description of FMMD about 4 times now! Have to sort that out. Cycle back to patcham now and pop in to see the cats on the way back... --- submission_thesis/CH4_FMMD/Makefile | 8 +- submission_thesis/CH4_FMMD/copy.tex | 1273 ++++++++++++++++- .../CH4_FMMD/top_down_de_comp.dia | Bin 0 -> 1757 bytes 3 files changed, 1275 insertions(+), 6 deletions(-) create mode 100644 submission_thesis/CH4_FMMD/top_down_de_comp.dia 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 0000000000000000000000000000000000000000..4e875ae01b0bae11cfb10a8cbe53fb4b1602eca5 GIT binary patch literal 1757 zcmV<31|s<%iwFP!000021MOT*Z`(K!z2{dL?lq1 zmge)b;oskX`xp(soS%H2rST{DH!tJG0KSn|=IU&CRoBZ;qtWf{Ey`9^To)zE(rZ*D zqyOS8i$~CCG(0~U3?3Vp#dU1%wRhvXF4M_%oec7Lk(>=D@$|>MEUxp}uxZt{n-*D7 z4sPP?Z1~~Qeuksg%xKNd6SkM}Jeib9{G;DAhL6_!m|iC3rrE`^s8VQBua;X)dhD40 zAGK*)RnRD(pMUs;e`p@5z42hH>p^=#>P1}6(|j8T`X*~Sf})603Y{Tzq_N_P{OpsL z!%dD0mmL?bJT6>XT`Y^TF5|S`hMW{dmc)63T9?LXV$`Rk}fo=Whvp<<^nlHhDIG<<9J%kW|!Ni!-QwHMnh2NMYEwU68nthy?0FFLZu z-9ut`_>La9x;J@=D|r=g>XZniJ+c=t3`8WxgduuLG@@Sl>*&*S2rQ7&$Ko$T46l9E z`{6Hj7GH_9XxQabe*wjUj43nx#eVhI)u-n$SbAkF5o?U)?}xF>m9fkW|C@%QAee#B$a@>n?Y7$k*?Q{`2MTM&s9hU8Zvu9Sh~V&4R~HodW9onoU+ z-&?f{yKC(>)_}kL^X>bufA*{cKe2eyw-Q(6br+nuKe&t+X|{r=it}nXsOpuO<%4E5 zU;RDFZjw5k#*Y^xUj77I0n-sQ7)9$r^Eh|e2Xvi<&t>91Nb4&~Pi#A2>;@EP={#Q~ z-LEsruNQ4sJ`<&Lz363Oabq88GcX<=g&jqcq^l-HpbV!V6Vm5g<|haiAW0MvrtD>e z--0Gp*OQOcs;ZMk&?Vox)Wyc2OK(t@l>3xbLuM=x@j7KS7#s=6lz?**R0$BN2&xoR zX$KdBD7`^ZiVm>trle5}P5th?H7JZix+DP~(UNo35`{sJnAc5xZbAY|BrOUZGitLtpt09YNN2~wCgc$}A&GPO z62*uSGimTShiyR^k{I-ufsC0stf?jqiDF0;chNEAiEnTUOPtHpXoRpfRKQ-PsX<`~ z=B#5zkW!5_k+8fLq-i%FgEqZpZTch4ldkmNy#~>gww`LwHQyL%&J@6?h%0W+E-)hO zNd|`5p7YFUk>?jlKC{le)Wyy3^V8+#Q*@n`d(pfgpIyXdS={bVv|W}j zvLv5BHO0YuS3KWC?3hIDMmSKkhy$!f%SZxoF``T`zbn#`Qe}{cB5F)cNv*UeC%6#G zcgXbl*_r2Z8#hdZz@hPAf) z5t4=x=G}&ja}5*7ywIANty#^q&(zEyQEfMYAtU2sm`-aLW(d+mYtK>B>t*LG-#%3o zqUPO3jdOVo@IzS@7Cr|WK#|14a4qQA?#VH3G@TGaeTPh!iyh5OUKS$dtw&1FZzDJt zdoT{UlCay!#Am1&9AV`g{q@E3leM2`JU{s#eR_s@!dU Date: Fri, 13 Apr 2012 09:01:57 +0100 Subject: [PATCH 3/4] title page rule bars --- submission_thesis/titlepage/titlepage.tex | 37 ++++++++++++++--------- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/submission_thesis/titlepage/titlepage.tex b/submission_thesis/titlepage/titlepage.tex index 772d8c0..4504897 100644 --- a/submission_thesis/titlepage/titlepage.tex +++ b/submission_thesis/titlepage/titlepage.tex @@ -12,13 +12,14 @@ { \bf A methodology for the modularisation of Failure Mode Effects Analysis.} -\vspace{1.15in} -{ -Modularising FMEA has benefits of rigor, re-usability of analysis -and the integration of hardware and software in failure effects modelling. -} - +%\vbox +%{ +%Modularising FMEA has benefits of rigor, re-usability of analysis +%and the integration of hardware and software in failure effects modelling. +%%} +% +\rule{380pt}{1pt} \vspace{1.15in} @@ -26,24 +27,32 @@ and the integration of hardware and software in failure effects modelling. {\LARGE \bf Brighton University } \vspace{0.3in} +\rule{120pt}{1pt} +\vspace{0.1in} {\bf PhD Thesis} + +\vspace{0.1in} +\rule{120pt}{1pt} +\vspace{0.3in} \vspace{1.0in} {\large Author : R.P. Clark - \today } +\rule{380pt}{1pt} + \end{center} -\vspace{1.0in} -\begin{verbatim} - Robin Clark - 68 Vale Avenue, - Brighton, - East Sussex - -\end{verbatim} +%\vspace{1.0in} +%\begin{verbatim} +% Robin Clark +% 68 Vale Avenue, +% Brighton, +% East Sussex +% +%\end{verbatim} From 064129093da65b2e1e3031471152ba39be63dd42 Mon Sep 17 00:00:00 2001 From: Your Name Date: Fri, 13 Apr 2012 09:41:49 +0100 Subject: [PATCH 4/4] weakness -> weaknesses --- papers/software_fmea/software_fmea.tex | 2 +- submission_thesis/titlepage/titlepage.tex | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/papers/software_fmea/software_fmea.tex b/papers/software_fmea/software_fmea.tex index f83b39b..44a2c9a 100644 --- a/papers/software_fmea/software_fmea.tex +++ b/papers/software_fmea/software_fmea.tex @@ -135,7 +135,7 @@ failure mode of the component or sub-system}}} % Failure Mode Effects Analysis (FMEA), is a is a bottom-up technique that aims to assess the effect all component failure modes on a system. -It is used both as a design tool (to determine weakness), and is a requirement of certification of safety critical products. +It is used both as a design tool (to determine weaknesses), and is a requirement of certification of safety critical products. FMEA has been successfully applied to mechanical, electrical and hybrid electro-mechanical systems. Work on software FMEA is beginning, but diff --git a/submission_thesis/titlepage/titlepage.tex b/submission_thesis/titlepage/titlepage.tex index 4504897..df881f7 100644 --- a/submission_thesis/titlepage/titlepage.tex +++ b/submission_thesis/titlepage/titlepage.tex @@ -10,7 +10,9 @@ \vspace{2.15in} -{ \bf A methodology for the modularisation of Failure Mode Effects Analysis.} +{ + \bf A methodology for the modularisation of Failure Mode Effects Analysis. +} %\vbox %{