diff --git a/submission_thesis/CH4_FMMD/cfg.dia b/submission_thesis/CH4_FMMD/cfg.dia index 2a4e48d..59f028b 100644 Binary files a/submission_thesis/CH4_FMMD/cfg.dia and b/submission_thesis/CH4_FMMD/cfg.dia differ diff --git a/submission_thesis/CH4_FMMD/copy.tex b/submission_thesis/CH4_FMMD/copy.tex index 52851fa..15ea58c 100644 --- a/submission_thesis/CH4_FMMD/copy.tex +++ b/submission_thesis/CH4_FMMD/copy.tex @@ -1599,6 +1599,25 @@ We may now use the {\em INVAMP} {\dc} in even higher level {\fgs}. An analysis report is generated for each stage in the FMMD % {\fg} to {\dc} process. %\footnote % +The UML model in figure~\ref{fig:cfg} describes a hierarchical structure similar to that of a file system with directories, +but instead of directory and file nodes, there are closely linked {\fgs} and {\dcs} pairs, that perform a similar structural functions. +% +The NONINVAMP example is shown as an instance +diagram below (see figure~\ref{fig:instanceNONINVAMP}). +% +By tracing the component failure modes to symptoms +(which would defined in the analysis reports) +the failure causation logic can be followed and thus the DAG's derived (see figure~\ref{fig:noninvdag1}). +% +\begin{figure}[h] + \centering + \includegraphics[width=400pt]{./CH4_FMMD/instance_diagram_NONINVAMP.png} + % instance_diagram_NONINVAMP.png: 1162x657 pixel, 72dpi, 40.99x23.18 cm, bb=0 0 1162 657 + \caption{Instance diagram for the NONINVAMP example.} + \label{fig:instanceNONINVAMP} +\end{figure} + + % \paragraph{Traceability and quality of FMMD analysis.} By having an analysis report report for each analysis stage, %i.e. {\fg} to {\dc}, @@ -1756,496 +1775,7 @@ The abstraction level concept is formally defined in section~\ref{sec:abstractio -% -% %$$ \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. -% % -% % \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=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. -% % -% -% \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}. -% % -% +