diff --git a/symptom_ex_process/abstract.tex b/symptom_ex_process/abstract.tex index c8ccd04..ac93d95 100644 --- a/symptom_ex_process/abstract.tex +++ b/symptom_ex_process/abstract.tex @@ -1,32 +1,41 @@ + +% +% this is like an advert, why you should read this paper !!!! +% + \begin{abstract} In failure mode analysis, it is essential to know the failure modes of the sub-systems and components used. This paper outlines a technique for determining the failure modes of a sub-system given its components. % -This paper describes a process for taking a functional~group of components, -applying FMEA analysis on all the component failure modes possible in that functional~group, -and then determining how that functional group can fail. +%This paper describes a process for taking a functional~group of components, +%applying FMEA analysis on all the component failure modes possible in that functional~group, +%and then determining how that functional group can fail. % -With this information, we can treat the functional group -as a component in its own right. -This new component is a derived from the functional~group. -In the field of safety engineering this derived component corresponds to a low~level sub-system. - -Once the failure modes have been determined for a sub-system/derived~component, -this derived component can be combined with others to form functional groups -to model higher level sub-systems/derived~components. -In this way a hierarchy to represent the fault behaviour -of a system can be built from the bottom~up. This process can continue -until there is a complete hierarchy representing the failure mode -behaviour of the entire system under analysis. +%With this information, we can treat the sub-system +%as a component in its own right. +%This new component is a derived from the sub-system~group. +%In the field of safety engineering this derived component corresponds to a low~level sub-system. +% +Once the failure modes have been determined for a sub-system, +we can consider this to be a `derived component' +which can be combined with others to form +to model higher level sub-systems, which in turn can +be converted to derived components. +In this way a hierarchy representing the fault behaviour +of a system can be built from the bottom~up. +%This process can continue +%until there is a complete hierarchy representing the failure mode +%behaviour of the entire system under analysis. %FMMD hierarchy %Using the FMMD technique the hierarchy is built from the bottom up to ensure complete failure mode coverage. Because the process is bottom-up, syntax checking and tracking can ensure that -no component failure mode can be overlooked. -Once a hierarchy is in place it can be converted into a fault data model. +no component failure mode may be overlooked. +Once a hierarchy is in place it can be converted into a +Failure Mode Modular de-Composition (FMMD) fault data model. % -From the fault data model, traditional FTA and FMEA models (sub-sets of the fault data model) can be derived if desired. +From the FMMD fault data model, traditional FTA and FMEA models (essentially sub-trees of the FMMD fault data model) can be derived if desired. % % %This paper focuses on the process of building the blocks, the symptom extraction or abstraction process, that is key to creating an FMMD hierarchy. diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex index 45b3515..382b537 100644 --- a/symptom_ex_process/algorithm.tex +++ b/symptom_ex_process/algorithm.tex @@ -27,8 +27,8 @@ the functional~group must take the abstraction level of the highest assigned to any of its components. % $DC$ can be used as a system building block at a higher -level of fault abstraction. Because the derived components -merge to form functional groups, a converging hierarchy is +level of fault abstraction. Because derived components +are collected to form functional groups, a converging hierarchy is naturally formed with the abstraction level increasing with each tier. @@ -45,7 +45,7 @@ analysis. Let $FG$ be the set of components in the functional group under analysis, and $c$ be components that are members of it. This function returns a flat set of failure modes $F$. -$$ FG \mapsto F$$ +$$ FM: \mathcal{FG} \mapsto \mathcal{F}$$ %% %% Algorithm 1 %% @@ -88,7 +88,7 @@ The test cases are collections of failure modes. These could be formed from single failure modes or failure modes in combination. Let $TC$ be the set of test cases associated withthe functional group $FG$. -$$ DTC: F \mapsto TC$$ +$$ DTC: \mathcal{F} \mapsto \mathcal{TC} $$ %% %% Algorithm 2 @@ -152,7 +152,7 @@ The next stage is to analyse the effect of each test case on the functional grou The test cases are now analysed for their impact on the behaviour of the functional~group. Let $R$ be a set of results indexed by $j$ (the same index used to identify the test cases $tc_{j}$). -$$ATC: TC \mapsto R $$ +$$ATC: \mathcal{TC} \mapsto \mathcal{R} $$ \begin{algorithm}[h+] ~\label{alg:sympabs3} @@ -183,7 +183,7 @@ This stage analyses the results from bottom-up FMEA analysis ($R$), and collects results that, from the perspective of the functional~group, have the same failure symptom. Let set $SP$ be the set of symptoms for the functional group $FG$. -$$FCS: R \mapsto SP $$ +$$FCS: \mathcal{R} \mapsto \mathcal{SP} $$ \begin{algorithm}[h+] @@ -241,7 +241,7 @@ This derived component may now be used to build new functional groups at higher levels of fault abstraction. Let $DC$ be a derived component with its own set of failure~modes. -$$ CDC: SP \mapsto DC $$ +$$ CDC: \mathcal{SP} \mapsto \mathcal{DC} $$ \begin{algorithm}[h+] ~\label{alg:sympabs5} @@ -254,6 +254,7 @@ $$ CDC: SP \mapsto DC $$ \STATE { $ f_l = ConvertToFaultMode(sp_l) $} \STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes} \ENDFOR + \RETURN DC %\hline \end{algorithmic} @@ -261,13 +262,13 @@ $$ CDC: SP \mapsto DC $$ Algorithm \ref{alg:sympabs55} is the final stage in the process. We now have a derived~component $DC$, which has its own set of failure~modes. This can now be -used in conjection with other components (or derived~components) -to form functional~groups at a higher level of failure~mode~abstraction. +used in with other components (or derived~components) +to form functional~groups at higher levels of failure~mode~abstraction. Hierarchies of fault abstraction can be built that can model an entire SYSTEM. \section{Linking all five stages} -$$ \bowtie: FG \mapsto DC $$ +$$ \bowtie: \mathcal{FG} \mapsto \mathcal{DC} $$ \begin{algorithm}[h+] @@ -286,7 +287,8 @@ $$ \bowtie: FG \mapsto DC $$ \end{algorithmic} \end{algorithm} -The symptom abstraction technique allows us to take a functional group of components, analyse the failure +The symptom abstraction technique allows us to take a functional group of components, +analyse the failure mode behaviour and create a new entity, a derived~component, that has its own set of failure modes. The checks and constraints applied in the algorithm ensure that all component failure modes are covered. diff --git a/symptom_ex_process/fmmd.tex b/symptom_ex_process/fmmd.tex index ad9ba8d..add268d 100644 --- a/symptom_ex_process/fmmd.tex +++ b/symptom_ex_process/fmmd.tex @@ -3,9 +3,13 @@ % Describe FMMD \section{Background: FMMD outline} -The symptom abstraction process described here, is a core process in the Failure Mode Modular De-Composition (FMMD) -modelling technique. FMMD builds a hierarchy of failure mode behaviours from the bottom up. -Collections of base components are grouped into functional~groups, which are analysed +The symptom abstraction process described here, is a core process in the +%Failure Mode Modular De-Composition +FMMD modelling technique. FMMD builds a hierarchy of failure mode behaviours from the bottom up. +To start with collections of base components are grouped into functional~groups, which are analysed and then treated as components in thier own right. These higher level, or derived compoenents, can be used to build derived components at higher levels of abstraction, and ultimately -are used to build an FMMD fault model hierarchy the system modelled. +are used to build an FMMD fault model hierarchy of the system modelled. +Intermediate FMMD structures may be re-used in other designs, and +re-used in repeated sections of a design (consider a system +with several safety critical digital inputs for instance). diff --git a/symptom_ex_process/introduction.tex b/symptom_ex_process/introduction.tex index 3c41b97..b59f35a 100644 --- a/symptom_ex_process/introduction.tex +++ b/symptom_ex_process/introduction.tex @@ -1,10 +1,5 @@ { \section{Introduction} -In failure mode analysis, it is essential to -know the failure modes of the sub-systems and components used. -This paper outlines a technique for determining the failure modes of a sub-system given -its components. -% This chapter describes a process for taking a functional group of components, applying FMEA analysis on all the component failure modes possible in that functional~group, and then determining how that functional group can fail. diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index b103678..df2ab48 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -1,5 +1,5 @@ -\section{The Symptom abstraction Process} +\section{The Symptom Extraction Process} % TO DO: separate these two: @@ -73,7 +73,7 @@ Determine which test cases produce the same fault symptoms {\em from the perspec -\section{A general derived Component/Sub-System example} +\section{A theoretical `Derived Component' example} Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. @@ -137,7 +137,7 @@ This can be seen as all the failure modes that can affect the failure mode group For this example we shall consider single failure modes. %For each of the failure modes from $FM(FG)$ we shall -%create a test case ($fgfm_i$). Next each test case is examined/analysed +%create a test case ($g_i$). Next each test case is examined/analysed %and its effect on the functional group determined. \par @@ -147,13 +147,13 @@ For this example we shall consider single failure modes. {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\ {\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline % -$a\_1$ & $fs\_1$ & $fgfm_{1}$ & SP2 \\ \hline -$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline -$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline -$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline -$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline -$c\_1$ & $fs\_6$ & $fgfm_{6}$ & SP3 \\ \hline -$c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline +$a\_1$ & $fs\_1$ & $g_{1}$ & SP2 \\ \hline +$a\_2$ & $fs\_2$ & $g_{2}$ & SP1 \\ \hline +$a\_3$ & $fs\_3$ & $g_{3}$ & SP2\\ \hline +$b\_1$ & $fs\_4$ & $g_{4}$ & SP1 \\ \hline +$b\_2$ & $fs\_5$ & $g_{5}$ & SP1 \\ \hline +$c\_1$ & $fs\_6$ & $g_{6}$ & SP3 \\ \hline +$c\_2$ & $fs\_7$ & $g_{7}$ & SP2\\ \hline % \hline \end{tabular} @@ -167,12 +167,12 @@ As we are only looking at single fault possibilities for this example each failu is represented by a test~case. The Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}. The test cases are analysed w.r.t. the functional~group. -These become functional~group~failure~modes ($fgfm$'s). +These become functional~group~failure~modes ($g$'s). The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. -For the sake of example, let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ to be +For the sake of example, let us consider the fault symptoms of $\{g_2, g_4, g_5\}$ to be identical from the perspective of the functional~group. -That is to say, the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes +That is to say, the way in which functional~group fails if $g_2$, $g_4$ or $g_5$ % failure modes occur, is going to be the same. For example, in our CD player example, this could mean the common symptom `no\_sound'. No matter which component failure modes, or combinations thereof cause the problem, @@ -181,12 +181,12 @@ It may be of interest to the manufacturers and designers of the CD player why it as far as we the users are concerned, it has only one symptom, `no\_sound'! We can thus group these component failure modes into a common symptom, $SP1$, thus -$ SP1 = \{fgfm_2, fgfm_4, fgfm_5\}$. +$ SP1 = \{g_2, g_4, g_5\}$. % These can then be joined to form a spider. Likewise -let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. -Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}, -s lone symptom can be assigned its own symptom set $SP3 = \{fgfm_6\}$. +let $SP2 = \{g_1, g_3, g_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. +Let $\{g_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}, +s lone symptom can be assigned its own symptom set $SP3 = \{g_6\}$. We have now in $SP1$, $SP2$ and $SP3$ as the three ways in which this functional~group can fail. In other words we have derived failure modes for this functional~group. @@ -207,11 +207,11 @@ We can thus apply the function $FM$ on this newly derived component thus: $$ FM(DC) = \{ SP1, SP2, SP3 \} $$ -Note that $fgfm_6$, while %being a failure mode has +Note that $g_6$, while %being a failure mode has % not being grouped as a common symptom has \textbf{not dissappeared from the analysis process}. Were the designer to have overlooked this test case, it would appear as a failure mode of the derived component. -i.e. were it not to have been grouped in $SP3$, $ FM(DC)$ would have been $ \{ SP1, SP2, fgfm_6 \}$. +i.e. were it not to have been grouped in $SP3$, $ FM(DC)$ would have been $ \{ SP1, SP2, g_6 \}$. This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). The newly derived compoennt $DC$ is availble for use to form higher level functional groups, and we can thus diff --git a/symptom_ex_process/symptom_ex_process.tex b/symptom_ex_process/symptom_ex_process.tex index 56c4c98..e24e69e 100644 --- a/symptom_ex_process/symptom_ex_process.tex +++ b/symptom_ex_process/symptom_ex_process.tex @@ -3,7 +3,7 @@ { \input{abstract} \input{fmmd} -\input{introduction} +%\input{introduction} \input{topbot} \input{sys_abs} \input{process} diff --git a/symptom_ex_process/sys_abs.tex b/symptom_ex_process/sys_abs.tex index c2771af..0fa6471 100644 --- a/symptom_ex_process/sys_abs.tex +++ b/symptom_ex_process/sys_abs.tex @@ -1,10 +1,10 @@ -ection{The Symptom abstraction Process} +\section{The Symptom Extraction Process} % TO DO: separate these two: \paragraph{Symptom Extraction Described} -The objective of `symptom abstraction' is to analyse the functional~group and find +The objective of `symptom extraction' is to analyse the functional~group and find how it can fail when specified components within it fail. Once we know how functional~group can fail, we can treat it as a component or sub-system @@ -50,212 +50,3 @@ Were failure~modes missed, any failure mode model could be dangerously incomplet It is possible here for an automated system to flag unhandled failure modes. \ref{requirement at the start} -%%% -%%%\section{The Process : To analyse a base level Derived~Component/sub-system} -%%% -%%%To sumarise: -%%% -%%%\begin{itemize} -%%% \item Determine a minimal functional group -%%% \item Obtain the list of components in the functional group -%%% \item Collect the failure modes for each component -%%%% \item Draw these as contours on a diagram -%%%% \item Where si,ultaneous failures are examined use overlapping contours -%%%% \item For each region on the diagram, make a test case -%%% \item Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group -%%% \item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use. -%%%Determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider'). -%%% \item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component. -%%% \item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component. -%%%\end{itemize} -%%% -%%% -%%% -%%% -%%%\section{A general derived Component/Sub-System example} -%%% -%%%Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. -%%% -%%%$$ FG = \{ C_1 , C_2 , C_3 \} $$ -%%% -%%%Each component has a set of related fault modes (i.e. ways in which it can fail to operate correctly). -%%%Let us define the following failure modes for each component, defining a function $FM()$ -%%%that is passed a component and returns the set of failure modes associated with it -%%%\footnote{Base component failure modes are defined, often with -%%%statistics and evironmental factors in a variety of sources. \cite{mil1991} -%%%}. -%%% -%%%To re-cap from the definitions chapter \ref{chap:definitions}. -%%% -%%%Let the set of all possible components be $\mathcal{C}$ -%%%and let the set of all possible failure modes be $\mathcal{F}$. -%%% -%%%We can define a function $FM$ -%%% -%%%\begin{equation} -%%%FM : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} -%%%\end{equation} -%%% -%%%defined by (where $C$ is a component and $F$ is a set of failure modes): -%%% -%%%$$ FM ( C ) = F $$ -%%% -%%%%\\ -%%% -%%%And for this example: -%%% -%%%$$ FM(C_1) = \{ a_1, a_2, a_3 \} $$ -%%%$$ FM(C_2) = \{ b_1, b_2 \} $$ -%%%$$ FM(C_3) = \{ c_1, c_2 \} $$ -%%% -%%% -%%%\paragraph{Finding all failure modes within the functional group} -%%% -%%%For FMMD failure mode analysis, we need to consider the failure modes -%%%from all the components in the functional group as a flat set. -%%%This can be found by applying function $FM$ to all the components -%%%in the functional~group and taking the union of them thus: -%%% -%%%$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} FM(C_j) $$ -%%% -%%%We can actually overload the notation for the function FM -%%%and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: -%%% -%%%\begin{equation} -%%%FM : FG \mapsto \mathcal{F} -%%%\end{equation} -%%% -%%%Applied to the functional~group $FG$ in the example above: -%%%\begin{equation} -%%% FM(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \} -%%%\end{equation} -%%% -%%%This can be seen as all the failure modes that can affect the failure mode group $FG$. -%%% -%%%\subsection{Analysis of the functional group failure modes} -%%% -%%%For this example we shall consider single failure modes. -%%%%For each of the failure modes from $FM(FG)$ we shall -%%%%create a test case ($fgfm_i$). Next each test case is examined/analysed -%%%%and its effect on the functional group determined. -%%% -%%%\par -%%%%\vspace{0.3cm} -%%%\begin{table}[h] -%%%\begin{tabular}{||c|c|c|c||} \hline \hline -%%% {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\ -%%% {\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline -%%%% -%%%$a\_1$ & $fs\_1$ & $fgfm_{1}$ & SP2 \\ \hline -%%%$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline -%%%$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline -%%%$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline -%%%$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline -%%%$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\ \hline -%%%$c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline -%%%% -%%% \hline -%%%\end{tabular} -%%%\caption{Component to functional group to failure symptoms example} -%%%\label{tab:fexsymptoms} -%%%\end{table} -%%%%\vspace{0.3cm} -%%% -%%%Table~\ref{tab:fexsymptoms} shows the analysis process. -%%%As we are only looking at single fault possibilities for this example each failure mode -%%%is represented by a test~case. -%%%The Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}. -%%%The test cases are analysed w.r.t. the functional~group. -%%%These become functional~group~failure~modes ($fgfm$'s). -%%%The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. -%%% -%%%For the sake of example, let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ to be -%%%identical from the perspective of the functional~group. -%%%That is to say, the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes -%%%occur, is going to be the same. -%%%For example, in our CD player example, this could mean the common symptom `no\_sound'. -%%%No matter which component failure modes, or combinations thereof cause the problem, -%%%the failure symptom is the same. -%%%It may be of interest to the manufacturers and designers of the CD player why it failed, but -%%%as far as we the users are concerned, it has only one symptom, -%%%`no\_sound'! -%%%We can thus group these component failure modes into a common symptom, $SP1$, thus -%%%$ SP1 = \{fgfm_2, fgfm_4, fgfm_5\}$. -%%%% These can then be joined to form a spider. -%%%Likewise -%%%let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. -%%%Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}. -%%% -%%% -%%%We have now in $SP1$, $SP2$ and $fgfm_6$ as the three ways in which this functional~group can fail. -%%%In other words we have derived failure modes for this functional~group. -%%%We can place these in a set of symptoms, $SP$. -%%%% -%%%$$ SP = \{ SP1, SP2, fgfm_6 \} $$ -%%%% -%%%% -%%%These three symptoms can be considered the set of failure modes for the functional~group, and -%%%we can treat it as though it were a {\em black box} -%%%or a {\em component} to be used in higher level designs. -%%%% -%%%The next stage of the process could be applied automatically. -%%%Each common symptom becomes a failure mode of -%%%a newly created derived component. Let $DC$ be the newly derived component. -%%%This is assigned the failure modes that were derived from the functional~group. -%%%We can thus apply the function $FM$ on this newly derived component thus: -%%% -%%%$$ FM(DC) = \{ SP1, SP2, fgfm_6 \} $$ -%%% -%%%Note that $fgfm_6$, while %being a failure mode has -%%%not being grouped as a common symptom -%%%has \textbf{not dissappeared from the analysis process}. -%%%Were the designer to have overlooked this test case, it would appear in the derived component. -%%%This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! -%%%The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). -%%% -%%% -%%%\subsection{Defining the analysis process as a function} -%%% -%%%It is useful to define this analysis process as a function. -%%%Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now -%%%write -%%% -%%%$$ -%%%\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent -%%%$$ -%%%% -%%%%\begin{equation} -%%%% \bowtie(FG_{cfm}) = DC -%%%%\end{equation} -%%%% -%%%%or applying the function $FM$ to obtain the $FG_{cfm}$ set -%%%% -%%%Where DC is a derived component, and FG is a functional group: -%%% -%%%\begin{equation} -%%% \bowtie(FM(FG)) = DC -%%%\end{equation} -%%% -%%% -%%%%The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour. -%%%%The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' symbol, as in figure \ref{fig:gensubsys4} -%%% -%%%% \begin{figure}[h+] -%%%% \centering -%%%% \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg} -%%%% % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 -%%%% \label{fig:gensubsys3} -%%%% \caption{Deriving a new diagram} -%%% -%%% -%%%This sub-system or derived~component $DC$ , with its three error modes, can now be treated as a component (although at a higher level of abstraction) -%%%with known failure modes. -%%%This process can be repeated using derived~components to build a -%%%hierarchical -%%%fault~mode -%%%model. -%%% -%%% -%%% -%%% -%%% diff --git a/symptom_ex_process/topbot.tex b/symptom_ex_process/topbot.tex index ecef0de..8f65f67 100644 --- a/symptom_ex_process/topbot.tex +++ b/symptom_ex_process/topbot.tex @@ -18,6 +18,8 @@ However, FMMD also provides the mathematical frame work to assist in the production of these three results of static analysis. From the model created by the FMMD technique, the three above failure mode descriptions can be derived. +FMMD can model electrical, mechanical and software using a common notation, +and can thus model an entire electro mechanical software controlled system. \subsection{Top Down or natural trouble shooting} It is interesting here to look at the `natural' trouble shooting process. @@ -136,10 +138,6 @@ Electrical components have detailed datasheets associated with them. A useful ex be failure modes of the component, with environmental factors and MTTF statistics. Currently this sort of failure mode information is generally only available for generic component types\cite{mil1991}. - -%At higher levels of analysis, functional~groups are pre-analysed sub-systems that interact to -%erform a given function. - %\vspace{0.3cm} \begin{table}[h] \center @@ -165,5 +163,3 @@ Base Component & Any bought in component, which \\ \caption{Symptom Extraction Definitions} \label{tab:symexdef} \end{table} -%\vspace{0.3cm} -