diff --git a/fmmd_concept/fmmd_concept.tex b/fmmd_concept/fmmd_concept.tex index 3057b50..ff7a3fa 100644 --- a/fmmd_concept/fmmd_concept.tex +++ b/fmmd_concept/fmmd_concept.tex @@ -52,21 +52,25 @@ paper { chapter } -presents a bottom up modular methodology, a extension and refinement of FMEA, where instead of looking +presents a bottom up modular methodology, a extension and refinement to the FMEA, where instead of looking at individual component failure modes and deciding on their impact on the SYSTEM -it uses the component failure modes, to build modules or derived components. +it uses the component failure modes, to build modules or derived components, +using incremental steps to build a hierarchical model. +% This methodology has been named Failure Mode Modular De-composition (FMMD) because it de-composes a SYSTEM into a hierarchy of modules or {\dc}s. +% It does this by working from the bottom up, taking small groups of components, {\fgs}, and then analysing how they can fail. This analysis is performed using FMEA from a micro rather than a macro perspective. -Thus instead of looked at a component failure modes, and determining how -it {\em might} cause a failure at SYSTEM level, we are looking at how -it will affect the {\fg}. +Thus instead of looking at a component failure modes, and determining how +they {\em may} cause a failure at SYSTEM level, we are looking at how +they {\em will} affect the {\fg}. When we know the failure modes of a {\fg} we can treat it as a `black box' or {\dc}. With {\dc}s we can build {\fgs} at higher levels of analysis, until we have a complete hierarchy representing the failure behaviour of the SYSTEM. +% Because all the failure modes of all the components are held in a computer program, we can determine if the model is complete (i.e. all component failure modes have been included in the model). @@ -78,21 +82,22 @@ are held in a computer program, we can determine if the model is complete \paragraph{Ideal Static failure mode methodology} An ideal Static failure mode methodology would build a failure mode model -from which the the other four could be derived. +from which the traditional four models could be derived. It would address the short-comings in the other methodologies, and would have a user friendly interface, with a visual (rather than mathematical/formal) syntax with icons to represent the results of analysis phases. - -There are four static analysis failure mode methodologies in common use. -Each has its advantages and drawbacks, and each is suited for -a different phase in the product life cycle. -These four methodologies are discussed briefly below. +% +%There are four static analysis failure mode methodologies in common use. +%Each has its advantages and drawbacks, and each is suited for +%a different phase in the product life cycle. +The four methodologies in current use are discussed briefly below. \subsection { FTA } This, like all top~down methodologies introduces the very serious problem -of missing component failure modes, or modelling at -a too high level of failure mode abstraction. +of missing component failure modes \cite{faa}[Ch.9] +%, or modelling at +%a too high level of failure mode abstraction. FTA was invented for use on the minuteman nuclear defence missile systems in the early 1960's and was not designed as a rigorous fault/failure mode methodology. It is more like a structure to @@ -263,6 +268,54 @@ to smaller and smaller functional modules \cite{maikowski}. \section{Proposed Methodology \\ Failure Mode Modular De-Composition (FMMD)} +\paragraph{New methodology Must be bottom-up} +In order to ensure that all component failure modes have been covered +the methodology will have to work from the bottom-up +and start with the component failure modes. +% +\paragraph{How to build a SYSTEM failure behaviour model} +The next problem is how to we build a failure mode model +that converges to a finite set of SYSTEM level failure modes. +% +\paragraph{incremental stages and {\fg}s} +We can use incremental stages to build the hierarchy. +we can take small {\fg}s of components, where the {\fg} +is a small set of components that perform a simple +task. +This should be small enough to be able to consider all the failure +modes of its components. +We can consider these failure modes from the perspective +of the {\fg}. In other words, for each component failure mode in the {\fg}, +we create a `test case' and decide how each failure affects the functional group. +% +With the results from the test cases we will now have the ways in which the +{\fg} can fail. +% +We can now treat the {\fg} as a component, or rather a {\dc}. +We can refine this further, by grouping the common symptoms, or results that +are the same failure w.r.t. the {\fg}. +% +We can now create a {\dc} and assign these common symptoms +as its failure modes. +% +This {\dc} can be used to build higher level +{\fg}s, and naturally a hierarchy is being formed, which is +a failure mode behaviour model. +\paragraph{Directed Acyclic Graph}. This will naturally form a DAG +meaning that for all SYSTEM failure modes, we will be able to trace +back through the DAG to possible component failure mode causes. +If statistical models exist for the component failure modes +these failure causation trees (or minimal cut sets \cite{nucfta}) +can be used to calculate Mean Time to Failure (MTTF) or Probability of Failure on demand (PFD) figures. +% +Because common symptoms are being collected, as we build the tree up-ward +the number of failure modes decreases (or exceptionally stays the same) at each level. +% +This decreasing of the number of failure modes is bourne out {\irl}. +Of the thousands of component failure modes in a typical product +there are generally only a handful of SYSTEM level failure modes. +% + \subsection{Outline of the FMMD process} FMMD builds {\fg}s of components from the bottom-up. @@ -272,7 +325,7 @@ We can perform a failure mode effects analysis on each of the component failure modes within the {\fg}. We can thus ensure that all component failure modes are covered. We can then treat the {\fg} as a `black box' or component in its own right. We can now look at how the {\fg} can fail. Many of the component failure modes will -cause the same failure symptoms in the {fg} fialure behaviour. +cause the same failure symptoms in the {fg} failure behaviour. We can collect these failures as common symptoms. When we have out set of symptoms, we can now create a {\dc}. The {\dc} will have as its set of failures @@ -301,7 +354,8 @@ or even in other projects where the same {\dc} is used. for its results} Because the failure mode mode of a SYSTEM is a hierarchy of {\fg}s and derived components SYSTEM level failure modes are traceable back down the tree to -component level failure modes. This proivides causation minimal cut sets \cite{sccs} +component level failure modes. This proivides causation trees \cite{sccs} or, minimal cut sets +\footnote{Here minimal cut sets represent combinations of component failure modes that can result in s SYSTEM level failure.} for all SYSTEM failure modes. \subsubsection{ It should be capable of producing reliability and danger evaluation statistics.} diff --git a/style.tex b/style.tex index e4b80fb..7c5d864 100644 --- a/style.tex +++ b/style.tex @@ -74,6 +74,7 @@ \newcommand{\dcs}{\em derived~components} \newcommand{\bc}{\em base~component} \newcommand{\bcs}{\em base~components} +\newcommand{\irl}{in real life} \newcommand{\enc}{\ensuremath{\stackrel{enc}{\longrightarrow}}} \newcommand{\pin}{\ensuremath{\stackrel{pi}{\longleftrightarrow}}} %\newcommand{\pic}{\em pure~intersection~chain}