From 610ee0400836a638b3dd51d84344a3e61ab6d300 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Fri, 1 Jun 2012 16:53:37 +0100 Subject: [PATCH] Radical pruning as demanded by supervisors --- submission_thesis/CH4_FMMD/copy.tex | 2030 ++++++++++++++------------- submission_thesis/style.tex | 4 +- submission_thesis/thesis.tex | 2 +- 3 files changed, 1039 insertions(+), 997 deletions(-) diff --git a/submission_thesis/CH4_FMMD/copy.tex b/submission_thesis/CH4_FMMD/copy.tex index 1d9ff49..7fd8337 100644 --- a/submission_thesis/CH4_FMMD/copy.tex +++ b/submission_thesis/CH4_FMMD/copy.tex @@ -17,23 +17,23 @@ % Data types and their relationships are described using UML. % Mathematical constraints and definitions are made using set theory.} % } -{ -\section{Overview} -This chapter defines the FMMD process and related concepts and calculations. -FMMD is in essence modularised FMEA. Rather than taking each component failure mode -and extrapolating top level or system failure symptoms from it, -small groups of components are collected into {\fgs} and analysed, -and then {\dcs} are used to represent the {\fgs}. -These {\dcs} are used to then build further {\fgs} until a hierarchy of {\fgs} -and {\dcs} has been built, converging to a final {\dc} -at the top of the hierarchy. - -Or in other words we take the traditional FMEA process, and modularise it. -We break down each stage of reasoning -into small manageable groups, and use the results of those groups, as {\dcs} -to build higher level groups. -%This has advantages of concentrating -%effort in where modules interact, +% { +% \section{Overview} +% This chapter defines the FMMD process and related concepts and calculations. +% FMMD is in essence modularised FMEA. Rather than taking each component failure mode +% and extrapolating top level or system failure symptoms from it, +% small groups of components are collected into {\fgs} and analysed, +% and then {\dcs} are used to represent the {\fgs}. +% These {\dcs} are used to then build further {\fgs} until a hierarchy of {\fgs} +% and {\dcs} has been built, converging to a final {\dc} +% at the top of the hierarchy. +% +% Or in other words we take the traditional FMEA process, and modularise it. +% We break down each stage of reasoning +% into small manageable groups, and use the results of those groups, as {\dcs} +% to build higher level groups. +% %This has advantages of concentrating +% %effort in where modules interact, %% J. Howse 04MAY2012 REMOVEFirstly, %what is meant by @@ -47,398 +47,399 @@ to build higher level groups. % %% J. Howse 04MAY2012 REMOVEData types and their relationships are described using UML. %% J. Howse 04MAY2012 REMOVEMathematical constraints and definitions are made using set theory. -} +% } \section{Introduction} This chapter -starts with an overview of current failure modelling techniques, and then worked example using the new methodology, +starts with %an overview of current failure modelling techniques, and then +a worked example using the new methodology, Failure Mode Modular De-composition (FMMD). This is followed by a discussion on the design of the FMMD methodology and then an ontological description is given using UML class models. -A notation is then described to index and classify objects created in FMMD hierarchical models. - - -\subsection{Overview of current failure mode modelling techniques} - -We briefly analyse four current methodologies. -Comprehensive overviews of these methodologies may be found -in ~\cite{safeware,sccs,nasafta,nucfta,bfmea}. - -\paragraph{Fault Tree Analysis (FTA).} -FTA~\cite{nasafta,nucfta} is a top down methodology in which a hierarchical diagram is drawn for -each undesirable top level failure/event, presenting the conditions that must arise to cause -the event. -% -It is suitable for large complicated systems with few undesirable top -level failures and focuses on those events considered most important or most catastrophic. -% -Effects of duplication/redundancy of safety systems can be readily assessed. -It uses notations that are readily understood by engineers -(logic symbols borrowed from digital electronics and a fault hierarchy). -However, it cannot guarantee to model all base component failures -or be used to determine system level errors other than those modelled. -% -Each FTA diagram models one top level event. -This creates duplication of modelled elements, -and it is difficult to cross check between diagrams. It has limited -support for environmental and operational states. - - -\paragraph{Fault Mode Effects Analysis (FMEA)} is used principally to determine system reliability. -It is bottom-up and starts with component failure modes, which -lead to top level failure/events. -Each top level failure is assessed by its cost to repair (or perceived criticality) and its estimated frequency. %, using a -%failure mode ratio. -A list of failures according to their cost to repair~\cite{bfmea}, or effect on system reliability is then calculated. -It is easy to identify single component failure to system failure mappings -and an estimate of product reliability can be calculated. -%This can be viewed as a prioritised `to~fix' list. -% -It cannot focus on complex -component interactions that cause system failure modes or determine potential -problems from simultaneous failures. It does not consider changing environmental -or operational states in sub-systems or components. It cannot model -self-checking safety elements or other in-built safety features or -analyse how particular components may fail. - - -\paragraph{Failure Mode Effects Criticality Analysis (FMECA)} is a refinement of FMEA, using -extra variables: the probability of a component failure mode occurring, -the probability that this will cause a given top level failure, and the perceived -criticality. It gives better estimations of product reliability/safety and the -occurrence of particular system failure modes than FMEA but has similar deficiencies. - - -\paragraph{Failure Modes, Effects and Diagnostic Analysis (FMEDA)} is a refinement of -FMEA and FMECA and in addition models self-checking safety elements. It assigns two -attributes to component failure modes: detectable/undetectable and safe/dangerous. - Statistical measures about the system can be made and used to classify a -safety integrity level. It allows designs with in-built safety features to be assessed. -Otherwise, it has similar deficiencies to FMEA. -However, it has limited support -for environmental and operational states in sub-systems or components, -via self checking statistical mitigation. FMEDA is the methodology associated with -the safety integrity standard EN61508~\cite{en61508}. - -\subsection{Summary of Deficiencies in Current Methods} - -\paragraph{Top Down approach: FTA} The top down technique FTA, introduces the possibility of missing base component -level failure modes~\cite{faa}[Ch.9]. Since one FTA tree is drawn for each top level -event, this leads to repeated work, with limited ability for cross checking/model validation. -Also, the analysis process can miss top level events that bottom-up techniques -can reveal. - -%\subsection{Bottom-up approach: } - -\paragraph{State Explosion problem for FMEA, FMECA, FMEDA.} -The bottom-up techniques all suffer from % a problem of -state explosion. -To perform the analysis rigorously, we would need to consider the effect -of a component failure against all other components. Adding environmental -and operational states further increases the state explosion. - -Let $N$ be the number of components in our system, and $K$ be the average number of component failure modes -(ways in which a component can fail). The approximate total number of base component failure modes -is $N \times K$. -% -The total number of cases to examine, to determine the effect of all failure modes -on all -components -will be approximately $(N-1) \times N \times K$. %, in effect a very large set cross product. -% -If $E$ is the number of environmental conditions to consider -in a system, and $A$ the number of applied/operational states (or modes of the system), -the bottom-up analyst is presented with two -additional %cross product -factors, yielding approximately -$(N-1) \times N \times K \times E \times A$. -% -If we put some typical very small embedded system numbers\footnote{These figures would -be typical of a very simple temperature controller, with a micro-controller, sensors, an RS485 interface, -supporting circuitry and heater circuitry.} - into this, say $N=100$, $K=2.5$, $A=2$, and $E=10$ -we have $99 \times 100 \times 2.5 \times 10 \times 2 = 495000 $ checks to perform. -% -To look in detail at half a million fault~scenarios is obviously impractical. - - -% Requirements for an improved methodology The deficiencies identified in the -% current methodologies are used to establish criteria for an improved methodology. - -\paragraph{Reasoning distance - complexity and reachability.} -\label{sec:rd} -Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves -working heuristically. A base component failure will typically -be conceptually removed by several stages from a top level event. -%In electronics terms, all components on the signal path from the component that failed. -The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all the components -that must interact along the signal path to reach the top level event. -Where $C$ represents the set of components in a failure mode causation chain, -$c_i$ represents a component in $C$ and -the function $fm$ returns the failure modes for a given component, equation -\ref{eqn:complexity}, returns the `reasoning~distance'. -\begin{equation} -R_D = \sum_{i=1}^{|C|} |{fm(c_i)}| %\; where \; c \in C -\label{eqn:complexity} -\end{equation} -% -The reasoning distance is a value representing the number of failure modes -to consider to rigorously determine the causation chain -from the base component failure to the system level event. -% -The reasoning distance serves to show that when the causes of a top level -event are completely determined, a large amount of work, not -typical of heuristic or intuitive interpretation, is required. - -Reasoning distances will be large for complicated systems, and this is therefore a weakness in both -FMEA and FTA type analyses. This concept is developed further to create a metric for comparing -complexities from FMEA and FMMD analysis in section~\ref{sec:cc}. - -% could have a chapter on this. -% take a circuit or system and follow all the interactions -% to the components that cause the system level event. - -\paragraph{Multiple Events from one base component failure mode.} -A base component failure may potentially cause more than one -system level failure mode. -It could be possible to identify one top level event associated with -a {\bc} {\fm} and not investigate other possibilities, using FMEA or FTA techniques. - - -\paragraph{Software FMEA models are performed separately from Hardware FMEA.} -%If software FMEA or Software FTA is performed it is always performed separately from -%hardware FMEA. -Work on SFMEA (which is yet to be widely employed in international standards) does not seek to integrate -hardware and software models, but to perform -FMEA on the software in isolation~\cite{procsfmea}. -Some work has been performed using databases -to track the relationships between variables -and system failure modes~\cite{procsfmeadb}, and work has been performed to -introduce automation into the FMEA process~\cite{appswfmea} and code analysis -automation~\cite{modelsfmea}. Performing these analyses separately breaks the reasoning chain for tracing -failure causation through the software hardware interfaces. - -Although the SFMEA and hardware FMEAs are performed separately, -some schools of thought aim for FTA~\cite{nasafta}~\cite{nucfta} (top down - deductive) and FMEA (bottom-up inductive) -to be performed on the same system to provide insight into the -software hardware/interface~\cite{embedsfmea}. -Although this -would give a better picture of the failure mode behaviour, it -is by no means a rigorous approach to tracing errors that may occur in hardware -through to the top (and therefore ultimately controlling) layer of software. -%\section{Requirements for a new static failure mode Analysis methodology} - -\section{Desirable Criteria.} -From the deficiencies outlined above, we can form a set of desirable criteria for an enhanced failure mode methodology. -{ %\small -\label{criteria} -\begin{enumerate} -%\begin{itemize} -\label{fmmdreq} -\item Address the state explosion problem. % 1 -\item Ensure that all component failure modes are considered in the model. % 2 -\item Be easy to integrate mechanical, electronic and software models \cite{sccs}[p.287]. %3 -\item Be modular, in that commonly used {\fgs} can be re-used in other designs/projects. %4 -\item Have a formal basis, i.e. be able to produce mathematical traceability %5 -for its results, such as error causation trees.%, reliability and safety statistics. -%\item It should be easy to use, ideally using a -%graphical syntax (as opposed to a formal symbolic/mathematical text based language). -%\item From the top down, the FMMD model of a system, should follow a logical de-composition of the functionality -%to smaller and smaller functional groupings--or--modules. \cite{maikowski}. -\item Be able to model multiple (simultaneous) failure modes.% 6 % from the base component level up. -\end{enumerate} -%\end{itemize} -} +%A notation is then described to index and classify objects created in FMMD hierarchical models. +% \subsection{Overview of current failure mode modelling techniques} % - -% The design process follows this -%rationale, sub-systems are build t%o perform often basic functions from base components. -%We can term these small groups {\fgs}. +% We briefly analyse four current methodologies. +% Comprehensive overviews of these methodologies may be found +% in ~\cite{safeware,sccs,nasafta,nucfta,bfmea}. % -% Components should be collected -% into small functional groups to enable the examination of the effect of a -% component failure mode on the other components in the group. -% Once we have the failure modes, or symptoms of failure of a {\fg} -% it can now be considered as `derived component' with a known set -% of failure symptoms. We can use this `derived component' to build higher level -% functional groups. -% -% This helps with the reasoning distance problem, -% because we can trace failure modes back through complex interactions and have a structure to -% base our reasoning on, at each stage. -% - - -%Development of the new methodology -% -% \section{An ontology of failure modes} -% In order to address the state explosion problem, the process must be modular -%and deal with small groups of components at a time. This approach should address the state explosion problem : criteria 1. -% An ontology is now developed of -% failure modes and their relationship to environmental factors, -% applied/operational states and the hierarchical nature inherent in product design, -% defining the relationships between the system as a whole, components, -% failure modes, operational and environmental states. -% -% -% Components have sets of failure modes associated with them. -% Failure modes for common components may be found in -% the literature~\cite{fmd91,mil1991}. -% We can associate a component with its failure modes. -% This is represented in UML in figure \ref{fig:component_concept}. -% -% \begin{figure}[h] -% \centering -% \includegraphics[width=200pt,keepaspectratio=true]{./component.png} -% % component.:wq: 467x76 pixel, 72dpi, 16.47x2.68 cm, bb=0 0 467 76 -% \caption{Component with failure modes UML diagram} -% \label{fig:component_concept} -% \end{figure} - -% -% \subsection{Modular Design} -% -% When designing a system from the bottom-up, small groups of components are selected to perform -% simple functions. These can be termed {\fgs}. -% When the failure mode behaviour, or symptoms of failure -% of a {\fg} are determined, it can be treated as a component in its own right. -% -% % Functional groups -% % are then brought together to form more complex and higher level {\fgs}. -% Used in this way the {\fg} has become a {\dc}. The symptoms of failure -% of the {\fg} can be considered the failure modes of its {\dc}. -% Derived~Components can be used to create higher level {\fgs}. -% Repeating this process will lead to identify-able higher level -% groups, often referred to as sub-systems. We can call the entire collection/hierarchy -% of sub-systems the system. - - - -\section{The proposed Methodology} -\label{fmmdproc} -% Any new static failure mode methodology must ensure that it -% represents all component failure modes and it therefore should be bottom-up, -% starting with individual component failure modes. -To ensure all component failure modes are represented, the new methodology must be bottom-up. -% -This seems essential to satisfy criterion 2. -The proposed methodology is therefore a bottom-up process -starting with base~components. -% -Since we are only modelling failure modes, which could arise from -mechanical, electronic or software components, -criterion 3 is satisfied. -% -In order to address the state explosion problem, the process should be modular and hierarchical, -dealing with small groups of components at a time; this should address criterion 1. - - -%\paragraph{Outline of the Failure mode methodology.} -% -A {\em {\fg}}, is defined as a small collection of components -that interact to provide -a function or task within a system. -% -In the proposed methodology components are collected into functional groups -and each component failure (and possibly multiple simultaneous component failures) are considered in the -context of the {\fg}. - -%% GARK -% -The component failures are termed {\em{\fcs}}. %`test~cases'. -For each {\fc} -there will be a corresponding resultant failure, or `symptom', from the perspective of the {\fg}. -% -% MAYBE NEED TO DESCRIBE WHAT A SYMPTOM IS HERE -% -%From the perspective of the {\fg} failures of components will be symptoms. -It is conjectured that many symptoms will be common. That is to say -that component failures will often cause the same symptoms of failure -from the perspective of a {\fg}. - - - -% -A common symptom collection stage is now applied. Here common symptoms are collected -from the results of the {\fcs}. Because it is possible to model combinations of failures, -criterion 6 is satisfied. -% -With a collection of the {\fg} failure symptoms, we can create a {\em{\dc}}. -The failure modes of this new {\dc} are the symptoms of the {\fg} from which it was derived.% from. -This satisfies criterion 4, as we can now treat {\dcs} as pre-analysed -modules available for re-use. - -By using {\dcs} in higher level functional groups, a hierarchy can be built representing -the failure mode behaviour of a system. Because the hierarchy maintains information -linking the symptoms to component failure modes (via {\fcs}), we have traceable -reasoning connections from base component failures to top level failures. -The traceability should satisfy criterion 5. - -% ONTOLOGY - NO ROOM IN 6 PAGES OF PAPER -% \paragraph{Environmental Conditions, Operational States.} -% -% Any real world sub-system will exist in a variable environment -% and may have several modes of operation. -% In order to find all possible failures, a sub-system -% must be analysed for each operational state -% and environmental condition that could affect it. +% \paragraph{Fault Tree Analysis (FTA).} +% FTA~\cite{nasafta,nucfta} is a top down methodology in which a hierarchical diagram is drawn for +% each undesirable top level failure/event, presenting the conditions that must arise to cause +% the event. % % -% A question is raised here: which objects should we -% associate the environmental and the operational states with ? -% There are three objects in our model to which these considerations could be applied. -% We could apply these conditions -% to {\fgs}, components, or {\dcs}. -% -% \paragraph {Environmental Conditions.} -% -% Environmental conditions are external to the -% {\fg} and are often things over which the system has no direct control -% ( e.g. ambient temperature, pressure or electrical interference levels). +% It is suitable for large complicated systems with few undesirable top +% level failures and focuses on those events considered most important or most catastrophic. % % -% Environmental conditions may affect different components in a {\fg} -% in different ways. +% Effects of duplication/redundancy of safety systems can be readily assessed. +% It uses notations that are readily understood by engineers +% (logic symbols borrowed from digital electronics and a fault hierarchy). +% However, it cannot guarantee to model all base component failures +% or be used to determine system level errors other than those modelled. +% % +% Each FTA diagram models one top level event. +% This creates duplication of modelled elements, +% and it is difficult to cross check between diagrams. It has limited +% support for environmental and operational states. % -% For instance, a system may be specified for -% $0\oc$ to $85\oc$ operation, but some components -% may show failure behaviour between $60\oc$ and $85\oc$ -% \footnote{Opto-isolators typically show marked performance decrease after -% $60\oc$ \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}. -% Other components may operate comfortably within that whole temperature range specified. -% Environmental conditions will have an effect on the {\fg} and the {\dc}, -% but they will have specific effects on individual components. % -% It seems obvious that -% environmental conditions should apply to components. -% %A component will hold a set of environmental states that -% %affect it. +% \paragraph{Fault Mode Effects Analysis (FMEA)} is used principally to determine system reliability. +% It is bottom-up and starts with component failure modes, which +% lead to top level failure/events. +% Each top level failure is assessed by its cost to repair (or perceived criticality) and its estimated frequency. %, using a +% %failure mode ratio. +% A list of failures according to their cost to repair~\cite{bfmea}, or effect on system reliability is then calculated. +% It is easy to identify single component failure to system failure mappings +% and an estimate of product reliability can be calculated. +% %This can be viewed as a prioritised `to~fix' list. +% % +% It cannot focus on complex +% component interactions that cause system failure modes or determine potential +% problems from simultaneous failures. It does not consider changing environmental +% or operational states in sub-systems or components. It cannot model +% self-checking safety elements or other in-built safety features or +% analyse how particular components may fail. % -% \paragraph {Operational States} % -% Sub-systems may have specific operational states. -% These could be a general health level, such as -% normal operation, graceful degradation or lockout. -% Alternatively they could be self~checking sub-systems that are either in a normal, alarm/lockout or self~check state. +% \paragraph{Failure Mode Effects Criticality Analysis (FMECA)} is a refinement of FMEA, using +% extra variables: the probability of a component failure mode occurring, +% the probability that this will cause a given top level failure, and the perceived +% criticality. It gives better estimations of product reliability/safety and the +% occurrence of particular system failure modes than FMEA but has similar deficiencies. % -% Operational states are conditions that apply to some functional groups, not individual components. - -%\section{The Non-Inverting Operational Amplifier} -%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 -%described in this chapter. -%When building a system from components, -%we should be able to find all known failure modes for each component. -%For most common electrical and mechanical components, the failure modes -%for a given type of part can be obtained from standard literature~\cite{mil1991} -%\cite{mech}. %The failure modes for a given component $K$ form a set $F$. - -\label{defs} -%% -%% Paragraph component and its relationship to its failure modes -%% +% +% \paragraph{Failure Modes, Effects and Diagnostic Analysis (FMEDA)} is a refinement of +% FMEA and FMECA and in addition models self-checking safety elements. It assigns two +% attributes to component failure modes: detectable/undetectable and safe/dangerous. +% Statistical measures about the system can be made and used to classify a +% safety integrity level. It allows designs with in-built safety features to be assessed. +% Otherwise, it has similar deficiencies to FMEA. +% However, it has limited support +% for environmental and operational states in sub-systems or components, +% via self checking statistical mitigation. FMEDA is the methodology associated with +% the safety integrity standard EN61508~\cite{en61508}. +% +% \subsection{Summary of Deficiencies in Current Methods} +% +% \paragraph{Top Down approach: FTA} The top down technique FTA, introduces the possibility of missing base component +% level failure modes~\cite{faa}[Ch.9]. Since one FTA tree is drawn for each top level +% event, this leads to repeated work, with limited ability for cross checking/model validation. +% Also, the analysis process can miss top level events that bottom-up techniques +% can reveal. +% +% %\subsection{Bottom-up approach: } +% +% \paragraph{State Explosion problem for FMEA, FMECA, FMEDA.} +% The bottom-up techniques all suffer from % a problem of +% state explosion. +% To perform the analysis rigorously, we would need to consider the effect +% of a component failure against all other components. Adding environmental +% and operational states further increases the state explosion. +% +% Let $N$ be the number of components in our system, and $K$ be the average number of component failure modes +% (ways in which a component can fail). The approximate total number of base component failure modes +% is $N \times K$. +% % +% The total number of cases to examine, to determine the effect of all failure modes +% on all +% components +% will be approximately $(N-1) \times N \times K$. %, in effect a very large set cross product. +% % +% If $E$ is the number of environmental conditions to consider +% in a system, and $A$ the number of applied/operational states (or modes of the system), +% the bottom-up analyst is presented with two +% additional %cross product +% factors, yielding approximately +% $(N-1) \times N \times K \times E \times A$. +% % +% If we put some typical very small embedded system numbers\footnote{These figures would +% be typical of a very simple temperature controller, with a micro-controller, sensors, an RS485 interface, +% supporting circuitry and heater circuitry.} +% into this, say $N=100$, $K=2.5$, $A=2$, and $E=10$ +% we have $99 \times 100 \times 2.5 \times 10 \times 2 = 495000 $ checks to perform. +% % +% To look in detail at half a million fault~scenarios is obviously impractical. +% +% +% % Requirements for an improved methodology The deficiencies identified in the +% % current methodologies are used to establish criteria for an improved methodology. +% +% \paragraph{Reasoning distance - complexity and reachability.} +% \label{sec:rd} +% Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves +% working heuristically. A base component failure will typically +% be conceptually removed by several stages from a top level event. +% %In electronics terms, all components on the signal path from the component that failed. +% The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all the components +% that must interact along the signal path to reach the top level event. +% Where $C$ represents the set of components in a failure mode causation chain, +% $c_i$ represents a component in $C$ and +% the function $fm$ returns the failure modes for a given component, equation +% \ref{eqn:complexity}, returns the `reasoning~distance'. +% \begin{equation} +% R_D = \sum_{i=1}^{|C|} |{fm(c_i)}| %\; where \; c \in C +% \label{eqn:complexity} +% \end{equation} +% % +% The reasoning distance is a value representing the number of failure modes +% to consider to rigorously determine the causation chain +% from the base component failure to the system level event. +% % +% The reasoning distance serves to show that when the causes of a top level +% event are completely determined, a large amount of work, not +% typical of heuristic or intuitive interpretation, is required. +% +% Reasoning distances will be large for complicated systems, and this is therefore a weakness in both +% FMEA and FTA type analyses. This concept is developed further to create a metric for comparing +% complexities from FMEA and FMMD analysis in section~\ref{sec:cc}. +% +% % could have a chapter on this. +% % take a circuit or system and follow all the interactions +% % to the components that cause the system level event. +% +% \paragraph{Multiple Events from one base component failure mode.} +% A base component failure may potentially cause more than one +% system level failure mode. +% It could be possible to identify one top level event associated with +% a {\bc} {\fm} and not investigate other possibilities, using FMEA or FTA techniques. +% +% +% \paragraph{Software FMEA models are performed separately from Hardware FMEA.} +% %If software FMEA or Software FTA is performed it is always performed separately from +% %hardware FMEA. +% Work on SFMEA (which is yet to be widely employed in international standards) does not seek to integrate +% hardware and software models, but to perform +% FMEA on the software in isolation~\cite{procsfmea}. +% Some work has been performed using databases +% to track the relationships between variables +% and system failure modes~\cite{procsfmeadb}, and work has been performed to +% introduce automation into the FMEA process~\cite{appswfmea} and code analysis +% automation~\cite{modelsfmea}. Performing these analyses separately breaks the reasoning chain for tracing +% failure causation through the software hardware interfaces. +% +% Although the SFMEA and hardware FMEAs are performed separately, +% some schools of thought aim for FTA~\cite{nasafta}~\cite{nucfta} (top down - deductive) and FMEA (bottom-up inductive) +% to be performed on the same system to provide insight into the +% software hardware/interface~\cite{embedsfmea}. +% Although this +% would give a better picture of the failure mode behaviour, it +% is by no means a rigorous approach to tracing errors that may occur in hardware +% through to the top (and therefore ultimately controlling) layer of software. +% %\section{Requirements for a new static failure mode Analysis methodology} +% +% \section{Desirable Criteria.} +% From the deficiencies outlined above, we can form a set of desirable criteria for an enhanced failure mode methodology. +% { %\small +% \label{criteria} +% \begin{enumerate} +% %\begin{itemize} +% \label{fmmdreq} +% \item Address the state explosion problem. % 1 +% \item Ensure that all component failure modes are considered in the model. % 2 +% \item Be easy to integrate mechanical, electronic and software models \cite{sccs}[p.287]. %3 +% \item Be modular, in that commonly used {\fgs} can be re-used in other designs/projects. %4 +% \item Have a formal basis, i.e. be able to produce mathematical traceability %5 +% for its results, such as error causation trees.%, reliability and safety statistics. +% %\item It should be easy to use, ideally using a +% %graphical syntax (as opposed to a formal symbolic/mathematical text based language). +% %\item From the top down, the FMMD model of a system, should follow a logical de-composition of the functionality +% %to smaller and smaller functional groupings--or--modules. \cite{maikowski}. +% \item Be able to model multiple (simultaneous) failure modes.% 6 % from the base component level up. +% \end{enumerate} +% %\end{itemize} +% } +% +% +% % +% +% % The design process follows this +% %rationale, sub-systems are build t%o perform often basic functions from base components. +% %We can term these small groups {\fgs}. +% % +% % Components should be collected +% % into small functional groups to enable the examination of the effect of a +% % component failure mode on the other components in the group. +% % Once we have the failure modes, or symptoms of failure of a {\fg} +% % it can now be considered as `derived component' with a known set +% % of failure symptoms. We can use this `derived component' to build higher level +% % functional groups. +% % +% % This helps with the reasoning distance problem, +% % because we can trace failure modes back through complex interactions and have a structure to +% % base our reasoning on, at each stage. +% % +% +% +% %Development of the new methodology +% % +% % \section{An ontology of failure modes} +% % In order to address the state explosion problem, the process must be modular +% %and deal with small groups of components at a time. This approach should address the state explosion problem : criteria 1. +% % An ontology is now developed of +% % failure modes and their relationship to environmental factors, +% % applied/operational states and the hierarchical nature inherent in product design, +% % defining the relationships between the system as a whole, components, +% % failure modes, operational and environmental states. +% % +% % +% % Components have sets of failure modes associated with them. +% % Failure modes for common components may be found in +% % the literature~\cite{fmd91,mil1991}. +% % We can associate a component with its failure modes. +% % This is represented in UML in figure \ref{fig:component_concept}. +% % +% % \begin{figure}[h] +% % \centering +% % \includegraphics[width=200pt,keepaspectratio=true]{./component.png} +% % % component.:wq: 467x76 pixel, 72dpi, 16.47x2.68 cm, bb=0 0 467 76 +% % \caption{Component with failure modes UML diagram} +% % \label{fig:component_concept} +% % \end{figure} +% +% % +% % \subsection{Modular Design} +% % +% % When designing a system from the bottom-up, small groups of components are selected to perform +% % simple functions. These can be termed {\fgs}. +% % When the failure mode behaviour, or symptoms of failure +% % of a {\fg} are determined, it can be treated as a component in its own right. +% % +% % % Functional groups +% % % are then brought together to form more complex and higher level {\fgs}. +% % Used in this way the {\fg} has become a {\dc}. The symptoms of failure +% % of the {\fg} can be considered the failure modes of its {\dc}. +% % Derived~Components can be used to create higher level {\fgs}. +% % Repeating this process will lead to identify-able higher level +% % groups, often referred to as sub-systems. We can call the entire collection/hierarchy +% % of sub-systems the system. +% +% +% +% \section{The proposed Methodology} +% \label{fmmdproc} +% % Any new static failure mode methodology must ensure that it +% % represents all component failure modes and it therefore should be bottom-up, +% % starting with individual component failure modes. +% To ensure all component failure modes are represented, the new methodology must be bottom-up. +% % +% This seems essential to satisfy criterion 2. +% The proposed methodology is therefore a bottom-up process +% starting with base~components. +% % +% Since we are only modelling failure modes, which could arise from +% mechanical, electronic or software components, +% criterion 3 is satisfied. +% % +% In order to address the state explosion problem, the process should be modular and hierarchical, +% dealing with small groups of components at a time; this should address criterion 1. +% +% +% %\paragraph{Outline of the Failure mode methodology.} +% % +% A {\em {\fg}}, is defined as a small collection of components +% that interact to provide +% a function or task within a system. +% % +% In the proposed methodology components are collected into functional groups +% and each component failure (and possibly multiple simultaneous component failures) are considered in the +% context of the {\fg}. +% +% %% GARK +% % +% The component failures are termed {\em{\fcs}}. %`test~cases'. +% For each {\fc} +% there will be a corresponding resultant failure, or `symptom', from the perspective of the {\fg}. +% % +% % MAYBE NEED TO DESCRIBE WHAT A SYMPTOM IS HERE +% % +% %From the perspective of the {\fg} failures of components will be symptoms. +% It is conjectured that many symptoms will be common. That is to say +% that component failures will often cause the same symptoms of failure +% from the perspective of a {\fg}. +% +% +% +% % +% A common symptom collection stage is now applied. Here common symptoms are collected +% from the results of the {\fcs}. Because it is possible to model combinations of failures, +% criterion 6 is satisfied. +% % +% With a collection of the {\fg} failure symptoms, we can create a {\em{\dc}}. +% The failure modes of this new {\dc} are the symptoms of the {\fg} from which it was derived.% from. +% This satisfies criterion 4, as we can now treat {\dcs} as pre-analysed +% modules available for re-use. +% +% By using {\dcs} in higher level functional groups, a hierarchy can be built representing +% the failure mode behaviour of a system. Because the hierarchy maintains information +% linking the symptoms to component failure modes (via {\fcs}), we have traceable +% reasoning connections from base component failures to top level failures. +% The traceability should satisfy criterion 5. +% +% % ONTOLOGY - NO ROOM IN 6 PAGES OF PAPER +% % \paragraph{Environmental Conditions, Operational States.} +% % +% % Any real world sub-system will exist in a variable environment +% % and may have several modes of operation. +% % In order to find all possible failures, a sub-system +% % must be analysed for each operational state +% % and environmental condition that could affect it. +% % % +% % A question is raised here: which objects should we +% % associate the environmental and the operational states with ? +% % There are three objects in our model to which these considerations could be applied. +% % We could apply these conditions +% % to {\fgs}, components, or {\dcs}. +% % +% % \paragraph {Environmental Conditions.} +% % +% % Environmental conditions are external to the +% % {\fg} and are often things over which the system has no direct control +% % ( e.g. ambient temperature, pressure or electrical interference levels). +% % % +% % Environmental conditions may affect different components in a {\fg} +% % in different ways. +% % +% % For instance, a system may be specified for +% % $0\oc$ to $85\oc$ operation, but some components +% % may show failure behaviour between $60\oc$ and $85\oc$ +% % \footnote{Opto-isolators typically show marked performance decrease after +% % $60\oc$ \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}. +% % Other components may operate comfortably within that whole temperature range specified. +% % Environmental conditions will have an effect on the {\fg} and the {\dc}, +% % but they will have specific effects on individual components. +% % +% % It seems obvious that +% % environmental conditions should apply to components. +% % %A component will hold a set of environmental states that +% % %affect it. +% % +% % \paragraph {Operational States} +% % +% % Sub-systems may have specific operational states. +% % These could be a general health level, such as +% % normal operation, graceful degradation or lockout. +% % Alternatively they could be self~checking sub-systems that are either in a normal, alarm/lockout or self~check state. +% % +% % Operational states are conditions that apply to some functional groups, not individual components. +% +% %\section{The Non-Inverting Operational Amplifier} +% %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 +% %described in this chapter. +% %When building a system from components, +% %we should be able to find all known failure modes for each component. +% %For most common electrical and mechanical components, the failure modes +% %for a given type of part can be obtained from standard literature~\cite{mil1991} +% %\cite{mech}. %The failure modes for a given component $K$ form a set $F$. +% +% \label{defs} +% %% +% %% Paragraph component and its relationship to its failure modes +% %% \section{Worked Example: Non-Inverting Amplifier} @@ -615,12 +616,12 @@ represented in figure~\ref{fig:dc1}. \caption{From functional group to derived component} \label{fig:dc1} \end{figure} +We then represent the {\dc} as a DAG in figure \ref{fig:dc1dag}. - -We can now represent the potential divider as a {\dc}. -Because we have its symptoms (or failure mode behaviour), -we can treat these as the failure modes of a new {\dc}. -We can represent this as a DAG (see figure \ref{fig:dc1dag}). +% We can now represent the potential divider as a {\dc}. +% Because we have its symptoms (or failure mode behaviour), +% we can treat these as the failure modes of a new {\dc}. +% We can represent this as a DAG (see figure \ref{fig:dc1dag}). \begin{figure}[h+] \centering @@ -641,18 +642,18 @@ We can represent this as a DAG (see figure \ref{fig:dc1dag}). \label{fig:dc1dag} \end{figure} -The derived component is defined by its failure modes and -the functional group used to derive it. -%We can consider this an an orthogonal WHAT???? Group ???? Collection ???? -We now have a {\dc} model for a generic potential divider, and can use it -as a building block for other {\fgs} in the same way as we used the base components $R1$ and $R2$. +% The derived component is defined by its failure modes and +% the functional group used to derive it. +% %We can consider this an an orthogonal WHAT???? Group ???? Collection ???? +% We now have a {\dc} model for a generic potential divider, and can use it +% as a building block for other {\fgs} in the same way as we used the base components $R1$ and $R2$. \clearpage %\paragraph{Failure Mode Analysis of the OP-AMP} -Let use now consider the op-amp. According to -FMD-91~\cite{fmd91}[3-116] an op amp may have the following failure modes: +Let use now consider the op-amp as a {\bc}. According to +FMD-91~\cite{fmd91}[3-116] an op amp may have the following failure modes (with assigned probabilities): latchup(12.5\%), latchdown(6\%), nooperation(31.3\%), lowslewrate(50\%). \nocite{mil1991} @@ -692,16 +693,17 @@ We can represent these failure modes on a DAG (see figure~\ref{fig:op1dag}). %} \clearpage %\paragraph{Modelling the OP amp with the potential divider.} -We can now consider merging the OP amp and the potential divider, to -form a {\fg} to represent the non inverting amplifier. We have the failure modes of the {\dc} for the potential divider, -so we do not need to go back and consider the individual resistor failure modes that defined its behaviour. - - - -We can now create a {\fg} for the non-inverting amplifier -by bringing together the failure modes from \textbf{opamp} and \textbf{PD}. +We now merge the OP amp and the {\dc} $PD$, to +form a {\fg} to represent the non inverting amplifier. +% +%We have the failure modes of the {\dc} for the potential divider, +%so we do not need to go back and consider the individual resistor failure modes that defined its behaviour. +% +%We can now create a {\fg} for the non-inverting amplifier +%by bringing together the failure modes from \textbf{opamp} and \textbf{PD}. +% Each of these failure modes will be given a {\fc} for analysis, -and this is represented in table \ref{ampfmea}. +and this is represented in table \ref{tbl:ampfmea1}. %\clearpage {\footnotesize @@ -735,7 +737,7 @@ and this is represented in table \ref{ampfmea}. %TC7: $R_2$ OPEN & LOW & & LowPD \\ \hline \hline \end{tabular} -\label{ampfmea} +\label{tbl:ampfmea1} \end{table} } @@ -864,12 +866,14 @@ and this is represented in table \ref{ampfmea}. \label{fig:noninvdag1} \end{figure} -Let us consider, for the sake of the example, that the voltage follower (very low gain of 1.0) -amplification characteristics from FS2 and FS6 can be considered as low output from the OPAMP for the application -in hand (say milli-volt signal amplification). +%Let us consider, for the sake of the example, that the voltage follower (very low gain of 1.0) +%amplification characteristics from FS2 and FS6 can be considered as low output from the OPAMP for the application +%in hand (say milli-volt signal amplification). For this amplifier configuration we have three failure modes; $AMPHigh, AMPLow, LowPass$.%see figure~\ref{fig:fgampb}. This model now has two stages of analysis hierarchy, as represented in figure~\ref{fig:dc2}. +From the analysis in table \ref{tbl:ampfmea1} we can create the {\dc} $INVAMP$ which +represents the failure mode behaviour of the non-inverting amplifier. \begin{figure}[h] \centering @@ -879,10 +883,11 @@ This model now has two stages of analysis hierarchy, as represented in figure~\r \label{fig:dc2} \end{figure} -We can now expand the $PD$ {\dc} and have a full FMMD failure %mode -model -drawn as a DAG, which we can use traverse, and thus determine all possible causes to -the three high level symptoms, i.e. the failure~modes of the non-inverting amplifier. +We can now examine the {\dc} $INVAMP$ by drawing it as a DAG. +%expand the $PD$ {\dc} and have a full FMMD failure %mode +%model +We can traverse this DAG, and thus determine all possible causes to +the three high level symptoms, i.e. the failure~modes of the non-inverting amplifier $INVAMP$. % Figure \ref{fig:noninvdag1} shows a fully expanded DAG, from which we can derive information to assist in building models for FTA, FMEA, FMECA and FMEDA failure mode analysis methodologies. @@ -891,16 +896,16 @@ to assist in building models for FTA, FMEA, FMECA and FMEDA failure mode analysi -\paragraph{Worked example. Effect on State explosion.} -The potential divider {\dc} reduced the number of failures to consider from four to two. -The op-amp and potential divider modelled together, reduced the number of -base component failures from eight to three failure symptoms. -% -In general, -because symptoms are collected, we can state -the number of failure symptoms for a {\fg} will be less than or equal to the number -of component failures. -% In practise the number of symptoms is usually around half the +% \paragraph{Worked example. Effect on State explosion.} +% The potential divider {\dc} reduced the number of failures to consider from four to two. +% The op-amp and potential divider modelled together, reduced the number of +% base component failures from eight to three failure symptoms. +% % +% In general, +% because symptoms are collected, we can state +% the number of failure symptoms for a {\fg} will be less than or equal to the number +% of component failures. +% % In practise the number of symptoms is usually around half the %number of component failure modes, for each stage of FMMD analysis. %This methodology has also been applied elsewhere to the inverting amplifier configuration. %One can then use use {\dcs} in more complex circuits where the advantages of FMMD become more obvious, @@ -924,14 +929,71 @@ of component failures. \section{Defining terms} -The worked example used terms such as {\fg}, component, and {\dc}. -This chapter aims to define these terms. +Here we define the terms as used in the worked example. + +\begin{table}[h] +\center +\begin{tabular}{||p{3cm}|p{10cm}||} + +\hline \hline + {\em Definition } & {\em Description} \\ \hline + +System & A product designed to + work as a coherent entity \\ \hline + + + +Base Component & An atomic building block used at the lowest level of the FMMD model + \footnote{In the case of combinatorial packaged parts (such as a chip containing + four op-amps, each op-amp on the chip is considered as one atomic, or {\em{\bc}}).}. + \\ +{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline + + +Component & A building block, this may be a part from a parts list or a sub-assembly. \\ +{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline + + + +%Sub-system & A part of a system, sub-systems may contain sub-systems etc. \\ \hline % in FMMD terminology + %this would be both a {\em{\dc}} and a {\fg}. \\ +%{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline + + +Failure mode & A way in which a component can fail. \\ \hline + +Functional Grouping & A collection of + components with a functional purpose. + \\ \hline + +Symptom & A failure symptom of a {\fg}, caused by % WHICH MUST BE UNIQUE AND SEPARATE WITHIN THE \fg + a combination of its component failure modes. \\ \hline + + +Derived Component & A theoretical component, created to represent the failure + mode behaviour of a {\fg}. \\ + +{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline + + +Unitary State & A component with `unitary~state' failure modes, means that it cannot fail +with more than one of its failure modes at a time.\\ \hline + +Failure Scenario & A single failure mode (or a combination), used to + determine failure mode effects on a {\fg}. +\\ + + \hline +\end{tabular} +\caption{Failure Mode Modular De-composition: definitions and terms} +\label{tbl:fmmd_defs} +\end{table} \subsection{Parts, components and base components} A component is anything we use to build a product or system. It could be something quite complicated -like an integrated micro controller, or quite simple like the humble resistor. +like an integrated micro controller, or quite simple like the resistor. % We can define a component by its name, a manufacturers' part number and perhaps @@ -941,38 +1003,58 @@ Geoffrey Hall, writing in Spacecraft Systems Engineering\cite{scse}[p.619] defines a `part' thus ``{{Part(definition)}---The lowest level of assembly, beyond which further disassembly irrevocably destroys the item''. -This definition of a `part' is useful, but consider combinatorial parts, such as quad packaged op-amps. +This definition of a `part' is useful, but consider parts, such as quad packaged op-amps. +% Here we have four op-amps on one chip. For FMEA we would consider each op-amp in the package as a separate building block for a circuit. +% We, in fact, need to go a little further than the above definition of a part, and say that we want to define an atomic entity used as a building block. %The term component, in American English, can mean a building block or a part. %In British-English a component generally is given to mean the definition for part above. -We define {\bc} to mean a lowest level of assembly `part' or an atomic entity, which ever is the smaller -and component to mean either a part or a sub-assembly. -Definitions used in FMMD are listed in table~\ref{tbl:fmmd_defs} and discussed below. +We define {\bc} to be the lowest level of component that we use as a building block. +This is a choice made by the analyst. +% +Both op-amps and transistors have published statistical failure rates and yet an op-amp is made out of transistors. +% +A circuit designer would consider individual transistors and individual op-amps +as lowest level building blocks. +In fact any component with published failure modes could be considered to be a {\bc}, +but this determination is the choice of the analyst or the guidelines of the +standard~\cite{en298}~\cite{en61508}~\cite{en230} to which we are approving the product to. + +%a lowest level of assembly `part' or an atomic entity, which ever is the smaller +%and component to mean either a part or a sub-assembly. +%Definitions used in FMMD are lisfuckup mode or not?????ted in table~\ref{tbl:fmmd_defs} and discussed below. %% FUCKING STEREO SUB_SYSTEM EXAMPLE, THE FUCKING CHILDRENS SECTION -\subsection{Systems, functional groups, sub-systems and failure modes: sound system example} +\subsection{Systems, functional groupings, components and failure modes: sound system example} -It is helpful here to define the terms, `system', `functional~group', `component', `base~component', `symptom' and `derived~component/sub-system'. +%000000elpful 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. +% +A component is a system that is a part of some larger system. +% A modular system common in most homes is the sound separates audio system or stereo hi-fi. +% This is now used as an example to describe terms used in FMMD. -For instance a stereo amplifier separate/slave is a sub-system. The -whole sound system, consists perhaps of the following `sub-systems': +% +For instance a stereo amplifier separate/slave is a component. +%The +whole sound system, consists perhaps of the following `components': 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' +\paragraph{ {\fgs} and components.} +A components will be composed of `components', recursively down to +the {\bcs}. +% +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'. @@ -992,22 +1074,25 @@ For instance in the CD~player example; if we start at the bottom, we are present 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'. +These are termed `{\fgs}'. % 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. +as one of the base level {\fgs}. \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 +%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 {\fg} 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'. +When we have analysed the fault behaviour of a {\fg}, 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. +% +We can thus make a new `component' derived from the symptoms found as a result of analysing the {\fg}. +% The symptoms of failure 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. @@ -1029,62 +1114,7 @@ Electrical components have detailed data-sheets associated with them. A useful e be failure modes of the component, with environmental factors and MTTF~\cite{sccs}[p.165] statistics. Currently this sort of failure mode information is generally only available for generic component types \cite{mil1991}. -\begin{table}[h] -\center -\begin{tabular}{||p{3cm}|p{10cm}||} -\hline \hline - {\em Definition } & {\em Description} \\ \hline - -System & A product designed to - work as a coherent entity \\ \hline - - - -Base Component & An atomic building block. Typically this would be a part on a parts list. - In the case of combinatorial packaged parts (such as a chip containing - four op-amps, each op-amp on the chip is considered as one atomic, or {\em{\bc}}) - \\ -{\em Constraint} & This object must have a defined set of failure~modes \\ \hline - - -Component & A building block, this may be a part from a parts list or a sub-assembly. \\ \hline - - - -Sub-system & A part of a system, sub-systems may contain sub-systems etc. \\ \hline % in FMMD terminology - %this would be both a {\em{\dc}} and a {\fg}. \\ -%{\em 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 % WHICH MUST BE UNIQUE AND SEPARATE WITHIN THE \fg - a combination of its component failure modes. \\ \hline - - -Derived Component & A theoretical component, created to represent the failure - mode behaviour of a {\fg}. \\ -{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline - - -Unitary State & A component with `unitary~state' failure modes, means that it may cannot fail -with more than one of its failure modes at a time.\\ \hline - -Failure Scenario & A single failure mode (or a combination), used to - determine failure mode effects on a system or {\fg}. -\\ - - \hline -\end{tabular} -\caption{Failure Mode Modular De-composition: definitions and terms} -\label{tbl:fmmd_defs} -\end{table} % \begin{table}[h+] @@ -1107,11 +1137,15 @@ Failure Scenario & A single failure mode (or a combination), used to % \label{tbl:fmmd_defs} % \end{table} -What components all have in common is that they can fail, and fail in -a number of well defined ways. For common base-components +%What components all have in common is that they can fail, and fail in a +% number of well defined ways. +For common {\bcs} there is established literature for the failure modes for the system designer to consider (often with accompanying statistical -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. +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\}$\footnote{The failure modes of the resistor are discussed in section~\ref{sec:resistorfm}.}. @@ -1141,8 +1175,9 @@ each failure mode is referenced back to only one component. This constraint is d %%-%% The lower resistance part will draw more current and therefore have a statistically higher chance of failure.}. -Controlled products are typically built using a large number of base-components and these are traditionally +Controlled products are typically built using a large number of components and these are traditionally kept in a `parts~list'. +% For a safety critical product this is usually a formal document and is used for ordering systems from third parties, and by quality inspectors to ensure the correct parts are being fitted. @@ -1179,12 +1214,17 @@ When modularising failure mode behaviour from the bottom up, it is more meaningf For FMEA appraisals of systems we begin with {\bcs}. %These will have a set of failure modes assigned to them. In order to perform FMEA we require a set of failure modes for each {\bc} in the system under investigation. +% These are failure modes from the perspective of the user -of the component. We are not usually concerned with how the component has failed -internally. What we need to know are the symptoms of failure. +of the component. +% +We are not usually concerned with how the component has failed +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 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. @@ -1220,6 +1260,8 @@ all component failure modes must be considered. A top down approach can miss individual failure modes of components~\cite{faa}[Ch.~9], especially where there are non-obvious top-level faults. +\subsection{FMMD Process in outline.} + In order to analyse from the bottom-up, we need to take small groups of components from the parts~list that naturally work together to perform a simple function. @@ -1500,496 +1542,496 @@ are added to UML diagram in figure \ref{fig:cfg} are represented in figure \ref - -%$$ \mathcal{fm}(C) \rightarrow S $$ -%$$ {fm}(C) \rightarrow S $$ -\paragraph{Abstraction Levels of {\fgs} and {\dcs}} - - -\label{sec:indexsub} -We can indicate the abstraction level of a component by using a superscript. -Thus for the component $c$, where it is a `base component' we can assign it -the abstraction level zero, $c^0$. Should we wish to index the components -(for example as in a product parts-list) we can use a sub-script. -Our base component (if first in the parts-list) could now be uniquely identified as -$c^0_1$. - -We can further define the abstraction level of a {\fg}. -We can say that it is the maximum abstraction level of any of its -components. Thus a functional group containing only base components -would have an abstraction level zero and could be represented with a superscript of zero thus -`${\FG}^0$'. % The functional group set may also be indexed. - -We can apply symptom abstraction to a {\fg} to find -its symptoms. -%We are interested in the failure modes -%of all the components in the {\fg}. An analysis process -We define the symptom abstraction process with the symbol `$\derivec$'. -% is applied to the {\fg}. -% -The $\derivec$ function takes a {\fg} -as an argument and returns a newly created {\dc}. -% -%The $\derivec$ 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 $\abslev$ (as described in~\ref{sec:alpha}) to symbolise the fault abstraction level, we can now state: - -\begin{equation} - \label{eqn:abslevinc} - \derivec({\FG}^{\abslev}) \rightarrow c^{{\abslev}+N} | N \ge 1. -\end{equation} - -\paragraph{Functional Groups may be indexed.} -We will typically have more than one {\fg} on each level of FMMD hierarchy (except the top level, where there will only be one). -We 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. - -\paragraph{The symptom abstraction process in outline.} -The $\derivec$ function processes a functional group and returns a derived component. -Firstly, all the failure modes from all the components in the {\fg} -are used to create failure scenarios, which can be single failure modes -or combinations of failure modes where unitary state failure mode constraints do not apply. -% -With all the failure scenarios, an analyst can -determine how each scenario will affect the {\fg}. -This will give one failure mode behaviour result for each failure scenario. -With these results, we collect common symptoms. -That is to say, that many of the resultant failure modes, will exhibit the same symptom of failure from the perspective -of a user of the {\fg}. -% -We now can treat the functional group as a sort of `super~component'. -% -In order to make this new `super~component' usable, it needs to be in the form of a -component, that is, it has a name, and a set of failure modes. -% -We can do this by creating a new {\dc} and assigning a name to it, and assigning its set of -failure modes being the failure symptoms of the {\fg} from which it was derived. -%A new {\dc} is created -%where its failure modes, are the symptoms from {\fg}. -% -Note that the {\dc} must have a higher abstraction level than the {\fg} -from which it was derived---or---in other words, the symptom abstraction process `$\derivec$' increments -the abstraction level $\abslev$, as stated in equation~\ref{eqn:abslevinc}. - -The symptom abstraction process is described formally and algorithmically -in sections~\ref{sec:formalfmmd} and \ref{sec:algorithmfmmd} respectively. - - -\paragraph{Surjective constraint applied to symptom collection.} -We can stipulate that symptom collection process is surjective~\cite{dmfnt}. -% i.e. $ \forall f in F $ -By stipulating surjection for symptom collection, we ensure -that each component failure mode maps to at least one symptom. -This also ensures that all symptoms have at least one component failure -mode (i.e. one or more failure modes that caused it). -% - -\subsection{FMMD Hierarchy} - -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. 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 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.. - - -\subsection{Derived Component like concepts in safety literature} - -Integrated components such as OP-AMPS are already treated as {\dcs} -in literature. -An Op-AMP is an integrated circuit comprising some hundred or so individual components -but in the literature ~\cite{fmd91}[3-116] is is described as a simple component with a set of failure modes. - -% 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. +% %$$ \mathcal{fm}(C) \rightarrow S $$ +% %$$ {fm}(C) \rightarrow S $$ +% \paragraph{Abstraction Levels of {\fgs} and {\dcs}} % -% \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 -% \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. +% \label{sec:indexsub} +% We can indicate the abstraction level of a component by using a superscript. +% Thus for the component $c$, where it is a `base component' we can assign it +% the abstraction level zero, $c^0$. Should we wish to index the components +% (for example as in a product parts-list) we can use a sub-script. +% Our base component (if first in the parts-list) could now be uniquely identified as +% $c^0_1$. % -% \clearpage -% Two areas that cannot be automated. Choosing {\fgs} and the analysis/symptom collection process itself. - - -% \subsection{{\fgs} Sharing components and Hierarchy} +% We can further define the abstraction level of a {\fg}. +% We can say that it is the maximum abstraction level of any of its +% components. Thus a functional group containing only base components +% would have an abstraction level zero and could be represented with a superscript of zero thus +% `${\FG}^0$'. % The functional group set may also be indexed. % -% With electronics we need to follow the signal path to make sense of failure modes -% effects on other parts of the circuit further down that path. -% %{\fgs} will naturally have to be in the position of starter -% A power-supply is naturally first in a signal path (or failure reasoning path). -% That is to say, if the power-supply is faulty, its failure modes are likely to affect -% the {\fgs} that have to use it. +% We can apply symptom abstraction to a {\fg} to find +% its symptoms. +% %We are interested in the failure modes +% %of all the components in the {\fg}. An analysis process +% We define the symptom abstraction process with the symbol `$\derivec$'. +% % is applied to the {\fg}. +% % +% The $\derivec$ function takes a {\fg} +% as an argument and returns a newly created {\dc}. +% % +% %The $\derivec$ 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 $\abslev$ (as described in~\ref{sec:alpha}) to symbolise the fault abstraction level, we can now state: % -% This means that most electronic components should be placed higher in an FMMD -% hierarchy than the power-supply. -% A shorted de-coupling capactitor caused a `symptom' of the power-supply, -% and an open de-coupling capactitor should be considered a `failure~mode' relevant to the logic chip. -% % to consider. +% \begin{equation} +% \label{eqn:abslevinc} +% \derivec({\FG}^{\abslev}) \rightarrow c^{{\abslev}+N} | N \ge 1. +% \end{equation} % -% If components can be shared between functional groups, this means that components -% must be shareable between {\fgs} at different levels in the FMMD hierarchy. -% This hierarchy and an optionally shared de-coupling capacitor (with line highlighted in red and dashed) are shown -% in figure~\ref{fig:shared_component}. +% \paragraph{Functional Groups may be indexed.} +% We will typically have more than one {\fg} on each level of FMMD hierarchy (except the top level, where there will only be one). +% We 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. % -% \begin{figure} +% \paragraph{The symptom abstraction process in outline.} +% The $\derivec$ function processes a functional group and returns a derived component. +% Firstly, all the failure modes from all the components in the {\fg} +% are used to create failure scenarios, which can be single failure modes +% or combinations of failure modes where unitary state failure mode constraints do not apply. +% % +% With all the failure scenarios, an analyst can +% determine how each scenario will affect the {\fg}. +% This will give one failure mode behaviour result for each failure scenario. +% With these results, we collect common symptoms. +% That is to say, that many of the resultant failure modes, will exhibit the same symptom of failure from the perspective +% of a user of the {\fg}. +% % +% We now can treat the functional group as a sort of `super~component'. +% % +% In order to make this new `super~component' usable, it needs to be in the form of a +% component, that is, it has a name, and a set of failure modes. +% % +% We can do this by creating a new {\dc} and assigning a name to it, and assigning its set of +% failure modes being the failure symptoms of the {\fg} from which it was derived. +% %A new {\dc} is created +% %where its failure modes, are the symptoms from {\fg}. +% % +% Note that the {\dc} must have a higher abstraction level than the {\fg} +% from which it was derived---or---in other words, the symptom abstraction process `$\derivec$' increments +% the abstraction level $\abslev$, as stated in equation~\ref{eqn:abslevinc}. +% +% The symptom abstraction process is described formally and algorithmically +% in sections~\ref{sec:formalfmmd} and \ref{sec:algorithmfmmd} respectively. +% +% +% \paragraph{Surjective constraint applied to symptom collection.} +% We can stipulate that symptom collection process is surjective~\cite{dmfnt}. +% % i.e. $ \forall f in F $ +% By stipulating surjection for symptom collection, we ensure +% that each component failure mode maps to at least one symptom. +% This also ensures that all symptoms have at least one component failure +% mode (i.e. one or more failure modes that caused it). +% % +% +% \subsection{FMMD Hierarchy} +% +% 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. 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 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.. +% +% +% \subsection{Derived Component like concepts in safety literature} +% +% Integrated components such as OP-AMPS are already treated as {\dcs} +% in literature. +% An Op-AMP is an integrated circuit comprising some hundred or so individual components +% but in the literature ~\cite{fmd91}[3-116] is is described as a simple component with a set of failure modes. +% +% % 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 +% % \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. +% +% +% % \subsection{{\fgs} Sharing components and Hierarchy} +% % +% % With electronics we need to follow the signal path to make sense of failure modes +% % effects on other parts of the circuit further down that path. +% % %{\fgs} will naturally have to be in the position of starter +% % A power-supply is naturally first in a signal path (or failure reasoning path). +% % That is to say, if the power-supply is faulty, its failure modes are likely to affect +% % the {\fgs} that have to use it. +% % +% % This means that most electronic components should be placed higher in an FMMD +% % hierarchy than the power-supply. +% % A shorted de-coupling capactitor caused a `symptom' of the power-supply, +% % and an open de-coupling capactitor should be considered a `failure~mode' relevant to the logic chip. +% % % to consider. +% % +% % If components can be shared between functional groups, this means that components +% % must be shareable between {\fgs} at different levels in the FMMD hierarchy. +% % This hierarchy and an optionally shared de-coupling capacitor (with line highlighted in red and dashed) are shown +% % in figure~\ref{fig:shared_component}. +% % +% % \begin{figure} +% % \centering +% % \includegraphics[width=250pt,keepaspectratio=true]{CH5_Examples/shared_component.png} +% % % shared_component.png: 729x670 pixel, 72dpi, 25.72x23.64 cm, bb=0 0 729 670 +% % \caption{Optionally 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. +% +% %\pagebreak[4] +% +% +% +% \section{Double Simultaneous Failures} +% +% The probability for independent double simultaneous component failures (because we would multiply the probabilities of failure) is very low. +% However, some critical systems have to consider these type of eventualities. +% The burner control industry has to consider double failures, as specified in European Norm +% EN298~\cite{en298}. EN298 does not specifically state that +% double simultaneous failures must be considered. What it does say is that +% in the event of a lockout---a condition where an error has been detected and +% the equipment moves to a safe non-functioning state---no secondary failure may cause a dangerous condition. +% % +% This is slightly vague: there are so many possible component failures that could +% cause a secondary failure, that it is very difficult not to interpret this +% as meaning we have to cater for double simultaneous failures for the most critical sections +% of a burner control system. +% % +% In practise---in the field of EN298: burner controllers---this means triple safeguards to ensure the fuel +% is not allowed to flow under an error condition. This would of course leave the possibility of +% other more complex double failures tricking the controller into thinking the +% combustion was actually safe when it was not. +% % +% It would be impractical to +% perform the number of checks (as the checking is a time-consuming human process) required of RFMEA on a system as complex as a burner controller. +% +% It has been shown that, for all but trivial small systems, double failure mode checking +% is impossible from a practical perspective. +% FMMD can reduce the number of checks to make to achieve double simultaneous failure checking -- but by the very nature +% of choosing {\fgs} we will not (in the initial stages) be cross checking all possible +% combinations of double failures in all of the components. +% +% The diagram in figure~\ref{fig:dubsim1}, uses Euler diagrams to model failure modes (as closed contours) and asterisks +% to model failure mode scenarios. The failure scenario is defined by the contours that enclose it. +% Consider a system which has four components $c_1 \ldots c_4$. +% Consider that each of these components may fail in two ways: $a$ and $b$, i.e $fm(c_1) = fm(c_2) = \{a,b\}$. +% Now consider two {\fgs}, $fg1 = \{ c_1, c_2 \}$ and $fg2 = \{ c_3, c_4 \}$. +% +% We list all the possible failure scenarios as $FS1 \ldots FS6$ for each functional group. +% For instance $FS5$ is the result of component $c_2$ failing with failure mode $a$ and component $c_1$ failing +% with failure mode $b$. We can express this as $c_2 a \cup c_1 b$. +% +% +% \begin{figure}[h] % \centering -% \includegraphics[width=250pt,keepaspectratio=true]{CH5_Examples/shared_component.png} -% % shared_component.png: 729x670 pixel, 72dpi, 25.72x23.64 cm, bb=0 0 729 670 -% \caption{Optionally shared Component} -% \label{fig:shared_component} +% \includegraphics[width=300pt,keepaspectratio=true]{CH5_Examples/dubsim1.png} +% % dubsim1.png: 612x330 pixel, 72dpi, 21.59x11.64 cm, bb=0 0 612 330 +% \caption{Simultaneous Failure Mode Scenarios} +% \label{fig:dubsim1} % \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. - -%\pagebreak[4] - - - -\section{Double Simultaneous Failures} - -The probability for independent double simultaneous component failures (because we would multiply the probabilities of failure) is very low. -However, some critical systems have to consider these type of eventualities. -The burner control industry has to consider double failures, as specified in European Norm -EN298~\cite{en298}. EN298 does not specifically state that -double simultaneous failures must be considered. What it does say is that -in the event of a lockout---a condition where an error has been detected and -the equipment moves to a safe non-functioning state---no secondary failure may cause a dangerous condition. -% -This is slightly vague: there are so many possible component failures that could -cause a secondary failure, that it is very difficult not to interpret this -as meaning we have to cater for double simultaneous failures for the most critical sections -of a burner control system. -% -In practise---in the field of EN298: burner controllers---this means triple safeguards to ensure the fuel -is not allowed to flow under an error condition. This would of course leave the possibility of -other more complex double failures tricking the controller into thinking the -combustion was actually safe when it was not. -% -It would be impractical to -perform the number of checks (as the checking is a time-consuming human process) required of RFMEA on a system as complex as a burner controller. - -It has been shown that, for all but trivial small systems, double failure mode checking -is impossible from a practical perspective. -FMMD can reduce the number of checks to make to achieve double simultaneous failure checking -- but by the very nature -of choosing {\fgs} we will not (in the initial stages) be cross checking all possible -combinations of double failures in all of the components. - -The diagram in figure~\ref{fig:dubsim1}, uses Euler diagrams to model failure modes (as closed contours) and asterisks -to model failure mode scenarios. The failure scenario is defined by the contours that enclose it. -Consider a system which has four components $c_1 \ldots c_4$. -Consider that each of these components may fail in two ways: $a$ and $b$, i.e $fm(c_1) = fm(c_2) = \{a,b\}$. -Now consider two {\fgs}, $fg1 = \{ c_1, c_2 \}$ and $fg2 = \{ c_3, c_4 \}$. - -We list all the possible failure scenarios as $FS1 \ldots FS6$ for each functional group. -For instance $FS5$ is the result of component $c_2$ failing with failure mode $a$ and component $c_1$ failing -with failure mode $b$. We can express this as $c_2 a \cup c_1 b$. - - -\begin{figure}[h] - \centering - \includegraphics[width=300pt,keepaspectratio=true]{CH5_Examples/dubsim1.png} - % dubsim1.png: 612x330 pixel, 72dpi, 21.59x11.64 cm, bb=0 0 612 330 - \caption{Simultaneous Failure Mode Scenarios} - \label{fig:dubsim1} -\end{figure} - - - -From figure~\ref{fig:dubsim1} we can see that the double failure modes within the {\fgs} have been examined. -How do we model the double failures that occur across the {\fgs}, for instance -$c_4 a \cup c_1 a$ where $c_4 a$ is a failure mode in FG1 and $c_1 a$ from FG2. -It could be argued that because functional groups are chosen for their functionality, and re-usability, -that component failures in one should not affect a different {\fg}, but this is a weak argument. -Merely double checking within {\fgs} would be marginally better than -only applying it to the most obvious critical elements of a system. - -What is really required is a way that all double simultaneous failures -are checked. - -One way of doing this is to apply double failure mode -checking to all {\fgs} higher up in the hierarchy. - -This guarantees to check the symptoms caused by the -failure modes in the other {\fgs} with the symptoms -derived from the other {\fgs} modelling for double failures. -% -By traversing down the tree, we can automatically determine which -double simultaneous combinations have not been resolved. -% -By applying double simultaneous checking until no single failures -can lead to a top level event, we -implement traceable and provable, complete double failure mode coverage. - -To extend the example in figure~\ref{fig:dubsim1} we can map the failure -scenarios. -For Functional Group 1 (FG1), let us map: -\begin{eqnarray*} - FS1 & \mapsto & S1 \\ - FS2 & \mapsto & S3 \\ - FS3 & \mapsto & S1 \\ - FS4 & \mapsto & S2 \\ - FS5 & \mapsto & S2 \\ - FS6 & \mapsto & S3 -\end{eqnarray*} - -Thus a derived component, DC1, has the failure modes defined by $fm(DC1) = \{ S1, S2, S3 \}$. - - -For Functional Group 2 (FG2), let us map: -\begin{eqnarray*} - FS1 & \mapsto & S4 \\ - FS2 & \mapsto & S5 \\ - FS3 & \mapsto & S5 \\ - FS4 & \mapsto & S4 \\ - FS5 & \mapsto & S6 \\ - FS6 & \mapsto & S5 -\end{eqnarray*} - -Thus a derived component, DC2, has the failure modes defined by $fm(DC2) = \{ S4, S5, S6 \}$ -and these are the result of considering double simultaneous failures of its components. - -A commonly used temperature measuring circuit, the $Pt100$, is analysed -for double simultaneous failure analysis in section~\ref{sec:Pt100}. - -A software tool tracking the analysis process -could check that all possible single and double -failure modes combinations have been analysed as failure scenarios. - -%single -%XXXXXXXXXXXXXXXXXXXXXXXXXX -%This AUTOMATIC check can reveal WHEN double checking no longer necessary -%in the hierarchy to cover dub sum !!!!! YESSSS - - -\section{Conclusion} -%\subsection{Evaluation of FMMD} - -%By applying the methodology in section \ref{fmmdproc}, the wishlist can -%now be evaluated for the proposed FMMD methodology. - -We evaluate the FMMD method using the criteria in section \ref{fmmdreq}. -Table \ref{tbl:comparison} compares the current methodologies and FMMD using these criteria. -{ %\small -\begin{itemize} -\item{State explosion is reduced,} -%State Explosion is reduced, -because small collections of components are dealt within functional groups -which are used to create derived components which are then used in an hierarchical manner. - -\item{All component failure modes must be considered in the model.} -%All component failure modes must be considered in the model. -Since the proposed methodology is bottom-up, -this means that we can ensure/check that all component failure modes are handled. - - -\item{ It should be straightforward to integrate mechanical, electronic and software models,} -%It should be straight forward to integrate mechanical, electronic and software models, -because FMMD models in terms of failure modes only. % we have a generic failure mode entities to model. -%We can describe a mechanical, electrical or software component in terms of its failure modes. -% -Because of this -we can model and analyse integrated electromechanical systems, controlled by computers, -using a common notation. An electronic/software FMMD example is given in~\ref{sec:elecsw}. - -\item{ It should be re-usable, in that commonly used modules can be re-used in other designs/projects.} -%It should be re-usable, in that commonly used modules can be re-used in other designs/projects. -The hierarchical nature, taking {\fg}s and deriving components from them, means that -commonly used {\dcs} can be re-used in a design % (for instance self checking digital inputs) -or even in other projects where the same {\dc} is used. Several examples of re-used {\dcs} -may be found in chapter~\ref{sec:chap5}. - - -\item{ Formal basis: data should be available to produce mathematical proofs and traceability.} -%It should have a formal basis, data should be available to produce mathematical proofs -%for its results -Because the failure mode model of a system is a hierarchy of {\fg}s and {\dcs}, -system level failure modes are traceable back down the fault tree to -component level failure modes. -% -This allows cut sets~\cite{nasafta}[Ch.1p3] -to be determined by traversing the DAG from top level events down to their causes. -% -An added advantage of FMMD, is that there are typically several stages of reasoning -to go from a base component failure mode to a system/top level event. -% -Each of these reasoning stages are represented by {\fg} to {\dc} analysis processes, traversing up the FMMD hierarchy. -% -Compare this to traditional FMEA where -we only have one reasoning stage, that of base component failure mode to top level event. - -% \item{ It should be capable of producing reliability and danger evaluation statistics.} -% The minimal cuts sets for the system level failures can have computed MTTF -% and danger evaluation statistics sourced from the component failure mode statistics~\cite{fmd91,mil1991}. - -% \item{ It should be easy to use, ideally -% using a graphical syntax (as opposed to a formal mathematical one).} -% A modified form of constraint diagram (an extension of Euler diagrams) has -% been developed to support the FMMD methodology. -% This uses Euler circles to represent failure modes, and spiders to collect symptoms, to -% advance a {\fg} to a {\dc}. - - -% \item{ From the top down the failure mode model should follow a logical de-composition of the functionality -% to smaller and smaller functional modules \cite{maikowski}.} -% The bottom-up approach fulfils the logical de-composition requirement, because the {\fg}s -% are built from components performing a given task. +% +% +% +% From figure~\ref{fig:dubsim1} we can see that the double failure modes within the {\fgs} have been examined. +% How do we model the double failures that occur across the {\fgs}, for instance +% $c_4 a \cup c_1 a$ where $c_4 a$ is a failure mode in FG1 and $c_1 a$ from FG2. +% It could be argued that because functional groups are chosen for their functionality, and re-usability, +% that component failures in one should not affect a different {\fg}, but this is a weak argument. +% Merely double checking within {\fgs} would be marginally better than +% only applying it to the most obvious critical elements of a system. +% +% What is really required is a way that all double simultaneous failures +% are checked. +% +% One way of doing this is to apply double failure mode +% checking to all {\fgs} higher up in the hierarchy. +% +% This guarantees to check the symptoms caused by the +% failure modes in the other {\fgs} with the symptoms +% derived from the other {\fgs} modelling for double failures. +% % +% By traversing down the tree, we can automatically determine which +% double simultaneous combinations have not been resolved. +% % +% By applying double simultaneous checking until no single failures +% can lead to a top level event, we +% implement traceable and provable, complete double failure mode coverage. +% +% To extend the example in figure~\ref{fig:dubsim1} we can map the failure +% scenarios. +% For Functional Group 1 (FG1), let us map: +% \begin{eqnarray*} +% FS1 & \mapsto & S1 \\ +% FS2 & \mapsto & S3 \\ +% FS3 & \mapsto & S1 \\ +% FS4 & \mapsto & S2 \\ +% FS5 & \mapsto & S2 \\ +% FS6 & \mapsto & S3 +% \end{eqnarray*} +% +% Thus a derived component, DC1, has the failure modes defined by $fm(DC1) = \{ S1, S2, S3 \}$. +% +% +% For Functional Group 2 (FG2), let us map: +% \begin{eqnarray*} +% FS1 & \mapsto & S4 \\ +% FS2 & \mapsto & S5 \\ +% FS3 & \mapsto & S5 \\ +% FS4 & \mapsto & S4 \\ +% FS5 & \mapsto & S6 \\ +% FS6 & \mapsto & S5 +% \end{eqnarray*} +% +% Thus a derived component, DC2, has the failure modes defined by $fm(DC2) = \{ S4, S5, S6 \}$ +% and these are the result of considering double simultaneous failures of its components. +% +% A commonly used temperature measuring circuit, the $Pt100$, is analysed +% for double simultaneous failure analysis in section~\ref{sec:Pt100}. +% +% A software tool tracking the analysis process +% could check that all possible single and double +% failure modes combinations have been analysed as failure scenarios. +% +% %single +% %XXXXXXXXXXXXXXXXXXXXXXXXXX +% %This AUTOMATIC check can reveal WHEN double checking no longer necessary +% %in the hierarchy to cover dub sum !!!!! YESSSS +% +% +% \section{Conclusion} +% %\subsection{Evaluation of FMMD} +% +% %By applying the methodology in section \ref{fmmdproc}, the wishlist can +% %now be evaluated for the proposed FMMD methodology. +% +% We evaluate the FMMD method using the criteria in section \ref{fmmdreq}. +% Table \ref{tbl:comparison} compares the current methodologies and FMMD using these criteria. +% { %\small +% \begin{itemize} +% \item{State explosion is reduced,} +% %State Explosion is reduced, +% because small collections of components are dealt within functional groups +% which are used to create derived components which are then used in an hierarchical manner. +% +% \item{All component failure modes must be considered in the model.} +% %All component failure modes must be considered in the model. +% Since the proposed methodology is bottom-up, +% this means that we can ensure/check that all component failure modes are handled. +% +% +% \item{ It should be straightforward to integrate mechanical, electronic and software models,} +% %It should be straight forward to integrate mechanical, electronic and software models, +% because FMMD models in terms of failure modes only. % we have a generic failure mode entities to model. +% %We can describe a mechanical, electrical or software component in terms of its failure modes. +% % +% Because of this +% we can model and analyse integrated electromechanical systems, controlled by computers, +% using a common notation. An electronic/software FMMD example is given in~\ref{sec:elecsw}. +% +% \item{ It should be re-usable, in that commonly used modules can be re-used in other designs/projects.} +% %It should be re-usable, in that commonly used modules can be re-used in other designs/projects. +% The hierarchical nature, taking {\fg}s and deriving components from them, means that +% commonly used {\dcs} can be re-used in a design % (for instance self checking digital inputs) +% or even in other projects where the same {\dc} is used. Several examples of re-used {\dcs} +% may be found in chapter~\ref{sec:chap5}. +% +% +% \item{ Formal basis: data should be available to produce mathematical proofs and traceability.} +% %It should have a formal basis, data should be available to produce mathematical proofs +% %for its results +% Because the failure mode model of a system is a hierarchy of {\fg}s and {\dcs}, +% system level failure modes are traceable back down the fault tree to +% component level failure modes. +% % +% This allows cut sets~\cite{nasafta}[Ch.1p3] +% to be determined by traversing the DAG from top level events down to their causes. +% % +% An added advantage of FMMD, is that there are typically several stages of reasoning +% to go from a base component failure mode to a system/top level event. +% % +% Each of these reasoning stages are represented by {\fg} to {\dc} analysis processes, traversing up the FMMD hierarchy. +% % +% Compare this to traditional FMEA where +% we only have one reasoning stage, that of base component failure mode to top level event. +% +% % \item{ It should be capable of producing reliability and danger evaluation statistics.} +% % The minimal cuts sets for the system level failures can have computed MTTF +% % and danger evaluation statistics sourced from the component failure mode statistics~\cite{fmd91,mil1991}. +% +% % \item{ It should be easy to use, ideally +% % using a graphical syntax (as opposed to a formal mathematical one).} +% % A modified form of constraint diagram (an extension of Euler diagrams) has +% % been developed to support the FMMD methodology. +% % This uses Euler circles to represent failure modes, and spiders to collect symptoms, to +% % advance a {\fg} to a {\dc}. +% +% +% % \item{ From the top down the failure mode model should follow a logical de-composition of the functionality +% % to smaller and smaller functional modules \cite{maikowski}.} +% % The bottom-up approach fulfils the logical de-composition requirement, because the {\fg}s +% % are built from components performing a given task. +% % +% +% \item{ Multiple failure modes (conjunction - where more that one failure mode is active) +% may be modelled from the base component level up.} +% %Multiple failure modes (conjunction) may be modelled from the base component level up. +% By breaking the problem of failure mode analysis into small stages +% and building a hierarchy, the problems associated with needing to +% analyse all possible combinations of base level components +% within a system are reduced. +% +% % by an exponential order. +% This is because the multiple failure modes considered +% within {\fgs} have fewer failure modes to consider +% at each FMMD stage. +% Where appropriate, multiple simultaneous failures can be modelled by +% introducing {\fcs} %test~cases +% where the conjunction of failure modes is considered. +% An example demonstrating multiple failure mode analysis may be found in section~\ref{sec:Pt100}. +% \end{itemize} +% } +% +% { %\tiny +% \begin{table}[ht] +% \caption{Features of static Failure Mode analysis methodologies} % title of Table +% \centering % used for centering table +% \begin{tabular}{||l|c|c|c|c|c||} +% \hline \hline +% % \textbf{Des.} & \textbf{FTA} & \textbf{FMEA} & \textbf{FMECA} & \textbf{FDEMA} & \textbf{FMMD} \\ +% \textbf{\tiny Des.} & \textbf{\tiny FTA} & \textbf{\tiny FMEA} & \textbf{\tiny FMECA} & \textbf{\tiny FDEMA} & \textbf{\tiny FMMD} \\ +% \textbf{\tiny Crit.} & \textbf{} & \textbf{} & \textbf{} & \textbf{} & \textbf{} \\ +% % R & wire & res + & res - & description +% \hline +% \hline +% C1: % state exp +% & partial & & & & $\tickYES$ \\ \hline +% C2: % $\forall$ failures +% & &$\tickYES$ & $\tickYES$ & $\tickYES$ & $\tickYES$ \\ \hline +% C3: %mech,elec,s/w & $\tickYES$ +% & & & & & $\tickYES$ \\ \hline +% C4: %modular +% & & & & partial & $\tickYES$ \\ \hline +% C5: %formal +% & partial & partial & partial & partial & $\tickYES$ \\ \hline +% C6: %multiple fm +% & $\tickYES$ & & & partial & $\tickYES$ \\ \hline +% \hline +% \hline +% \end{tabular} +% \label{tbl:comparison} +% \end{table} +% } +% %\clearpage +% +% +% %\subsection{} +% +% +% %This new approach is called +% Failure Mode Modular De-Composition (FMMD) is designed +% to be a more rigorous and `data~complete' model than +% the current four approaches. +% % +% That is, +% from an FMMD model, we should be able to +% derive outline models that the other four methodologies would have been +% able to create. As this approach is modular, many of the results of +% analysed components may be re-used in other projects, so +% test efficiency is improved. +% %Clearly the more complex the original system is the more benefit, +% %i.e. less components and derived components, will be produced from decomposing the +% %system into functional groups. +% +% FMMD is based on generic failure modes, so it is not constrained to a +% particular field. It can be applied to mechanical, electrical or software domains. +% It can therefore be used to analyse systems comprised of electrical, +% mechanical and software elements in one integrated model. +% Furthermore the reasoning path is traceable. By being able to trace a +% top level event down through derived components, to base component +% failure modes, with each step annotated as {\fcs}, the model is easier to maintain. +% +% The example used here is deliberately small for the purpose +% of being presenting the methodology showing more than only one stage of hierarchy, +% worked examples for common electronic circuits, digital analogue hybrids and software electronic +% hybrid systems are given in chapter~\ref{sec:chap5}. +% %FMMD has been applied +% %to larger systems encompassing mechanical, electrical and software +% %elements. +% FMMD represents a new technique in that it +% can address all the criteria in table 3, whereas the other methodologies +% can only cover some. +% +% +% FMMD not only has advantages of efficiency (reduction of state explosion), it also +% provides the capability to model entire electro-mechanical-software systems using a common notation +% and processes. +% %\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}. +% % % -\item{ Multiple failure modes (conjunction - where more that one failure mode is active) -may be modelled from the base component level up.} -%Multiple failure modes (conjunction) may be modelled from the base component level up. -By breaking the problem of failure mode analysis into small stages -and building a hierarchy, the problems associated with needing to -analyse all possible combinations of base level components -within a system are reduced. - -% by an exponential order. -This is because the multiple failure modes considered -within {\fgs} have fewer failure modes to consider -at each FMMD stage. -Where appropriate, multiple simultaneous failures can be modelled by -introducing {\fcs} %test~cases -where the conjunction of failure modes is considered. -An example demonstrating multiple failure mode analysis may be found in section~\ref{sec:Pt100}. -\end{itemize} -} - -{ %\tiny -\begin{table}[ht] -\caption{Features of static Failure Mode analysis methodologies} % title of Table -\centering % used for centering table -\begin{tabular}{||l|c|c|c|c|c||} -\hline \hline -% \textbf{Des.} & \textbf{FTA} & \textbf{FMEA} & \textbf{FMECA} & \textbf{FDEMA} & \textbf{FMMD} \\ -\textbf{\tiny Des.} & \textbf{\tiny FTA} & \textbf{\tiny FMEA} & \textbf{\tiny FMECA} & \textbf{\tiny FDEMA} & \textbf{\tiny FMMD} \\ - \textbf{\tiny Crit.} & \textbf{} & \textbf{} & \textbf{} & \textbf{} & \textbf{} \\ -% R & wire & res + & res - & description -\hline -\hline - C1: % state exp - & partial & & & & $\tickYES$ \\ \hline - C2: % $\forall$ failures - & &$\tickYES$ & $\tickYES$ & $\tickYES$ & $\tickYES$ \\ \hline - C3: %mech,elec,s/w & $\tickYES$ - & & & & & $\tickYES$ \\ \hline - C4: %modular - & & & & partial & $\tickYES$ \\ \hline - C5: %formal - & partial & partial & partial & partial & $\tickYES$ \\ \hline - C6: %multiple fm - & $\tickYES$ & & & partial & $\tickYES$ \\ \hline -\hline -\hline -\end{tabular} -\label{tbl:comparison} -\end{table} -} -%\clearpage - - -%\subsection{} - - -%This new approach is called -Failure Mode Modular De-Composition (FMMD) is designed -to be a more rigorous and `data~complete' model than -the current four approaches. -% -That is, -from an FMMD model, we should be able to -derive outline models that the other four methodologies would have been -able to create. As this approach is modular, many of the results of -analysed components may be re-used in other projects, so -test efficiency is improved. -%Clearly the more complex the original system is the more benefit, -%i.e. less components and derived components, will be produced from decomposing the -%system into functional groups. - -FMMD is based on generic failure modes, so it is not constrained to a -particular field. It can be applied to mechanical, electrical or software domains. -It can therefore be used to analyse systems comprised of electrical, -mechanical and software elements in one integrated model. -Furthermore the reasoning path is traceable. By being able to trace a -top level event down through derived components, to base component -failure modes, with each step annotated as {\fcs}, the model is easier to maintain. - -The example used here is deliberately small for the purpose -of being presenting the methodology showing more than only one stage of hierarchy, -worked examples for common electronic circuits, digital analogue hybrids and software electronic -hybrid systems are given in chapter~\ref{sec:chap5}. -%FMMD has been applied -%to larger systems encompassing mechanical, electrical and software -%elements. -FMMD represents a new technique in that it -can address all the criteria in table 3, whereas the other methodologies -can only cover some. - - -FMMD not only has advantages of efficiency (reduction of state explosion), it also -provides the capability to model entire electro-mechanical-software systems using a common notation -and processes. -%\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}. -% - - diff --git a/submission_thesis/style.tex b/submission_thesis/style.tex index 0ddc53e..b7684fb 100644 --- a/submission_thesis/style.tex +++ b/submission_thesis/style.tex @@ -42,8 +42,8 @@ \newcommand{\fms}{\emp failure~modes} \newcommand{\FG}{\ensuremath{{G}}} \newcommand{\DC}{\ensuremath{{DC}}} -\newcommand{\fg}{\emp functional~group} -\newcommand{\fgs}{\emp functional~groups} +\newcommand{\fg}{\emp functional~grouping} +\newcommand{\fgs}{\emp functional~groupings} \newcommand{\dc}{\emp derived~component} \newcommand{\dcs}{\emp derived~components} \newcommand{\bc}{\emp base~component} diff --git a/submission_thesis/thesis.tex b/submission_thesis/thesis.tex index e377c03..422b284 100644 --- a/submission_thesis/thesis.tex +++ b/submission_thesis/thesis.tex @@ -63,7 +63,7 @@ % numbers at outer edges \pagenumbering{arabic} % Arabic page numbers hereafter \cfoot{Page \thepage\ of \pageref{LastPage}} -\lfoot{Brighton University 2012} %% Year keeps fucking incrementing +\lfoot{University of Brighton 2012} %% Year keeps fucking incrementing \rfoot{R.P.Clark \today} \lhead{Failure Mode Modular De-Composition} \rhead{PhD Thesis}