From 6b1e5bf4ab54a0dcfe2ea49b8ac5c2c436ee4211 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Wed, 20 Oct 2010 19:25:59 +0100 Subject: [PATCH] . --- fmmd_concept/fmmd_concept.tex | 43 ++++++++++++++++++++++++++++++++--- 1 file changed, 40 insertions(+), 3 deletions(-) diff --git a/fmmd_concept/fmmd_concept.tex b/fmmd_concept/fmmd_concept.tex index f801e34..f5f0afe 100644 --- a/fmmd_concept/fmmd_concept.tex +++ b/fmmd_concept/fmmd_concept.tex @@ -8,6 +8,10 @@ creating failure mode models of safety critical systems, which has a common and integrateable notation for mechanical, electronic and software domains. +%% What I have done +%% +%% What I have found +%% In addition, the methodology address the traditional weaknesses of Fault Tree Analysis (FTA), Fault Mode Effects Analysis (FMEA), Faliue Mode Effects Criticallity Analysis (FMECA) and Failure Mode Effects and Diagnostic Analysis (FMEDA). @@ -231,6 +235,8 @@ The analyst is now put in a position where he must assign a critical failure possibility to it. There is no analysis of how that resistor would/could affect that circuit, but because of the circuitry it is part of critical section it is linked to a critical system level fault. +A $\beta$ factor, the hueristically defined probability +of the failure causign the system fault may There is no cause and effect analysis for the failure modes. Unintended side effects that lead to failure can be missed. @@ -290,6 +296,7 @@ in \cite{maikowski}. This top down technique de-composes by functionality. Simpler and simpler functional blocks are discovered as we delve further into the way the system works and is built. +\paragraph{Need for a `bottom-up' system de-composition} What is required here is to mimic this top-down de-composition with a bottom up technique. @@ -297,11 +304,37 @@ By taking components that form {\fg}s form the nottom up and then taking those to form higher level {\fg}s we can mimic the analysis process from the bottom up. +\paragraph{Problem with functional group hierarchy} +A hierarchy of functional grouping, leading to a system model +still leaves us with the problem of the number of component failure modes. +The base components will typically have several failure modes each. +Given a typical ebedded system may have hundreds of components +this menas that we have to tie base component failure modes +to SYSTEM level errors. This is the `possibility to miss failure mode effects +at SYSTEM level' critism of the FTA, FMEDA and FMECA methodologies. + + \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} +What would be better would be to analyse the failure mode behaviour in each +functional group, and determine the ways in which it, rather than its +components can fail. +\paragraph{Compinent failures and {\fg} failure symptoms} +In other words we want to find out what the symptoms of the failures in the {\fg}s +are. +The number of symptoms of failure should be equal to or +less than the number of compoinent failure modes, simply because +often there are several potential causes of failure symptoms. +When we have this we can treat the {\fg} as a component in its own right, +with a simplified and reduced set of failure symptoms. +We create a new {\dc}, where its failure modes +are the failure symptoms of the {\fg}. +In this way as we build the hierarchy, we naturally abstract the +failure mode behaviour, but can check that all failure modes in +the hierarchy have been considered and tied to causing symptoms. +\paragraph{incremental stages and {\dcs}} 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 @@ -407,11 +440,12 @@ all failure modes within a system are greatly by an exponential order. \begin{itemize} \item It can be checked, automatically that, all component failure modes have been considered in the model. -\item Because we are modelling with {\fgs} and {\dcs} these can be generic, i.e. mechanical, electronic or software components. +\item Because we are modelling with failure modes the {\fgs} and {\dcs} these can be generic, i.e. mechanical, electronic or software components. \item The {\dcs} are re-usable, in that commonly used modules can be re-used in other designs/projects. \item It will have a formal basis, that is to say, it is able to produce mathematical proofs for its results (MTTF and the cause trees for SYSTEM level faults). -\item Overall reliability and danger evaluation statistics can be computed. +\item Overall reliability and danger evaluation statistics can be computed. By knowing all causation trees +the statistical probabilities (from base component data) for all causes can be simply added. \item A graphical representation based on Euler diagrams is used. \item From the top down the failure mode model will follow a logical de-composition of the functionality; by chosing {\fg}s and working bottom-up the hierarchy this happens as a natural consequence. @@ -421,5 +455,8 @@ chosing {\fg}s and working bottom-up the hierarchy this happens as a natural con \section{Conclusion} +This paper provides the backgroud for the need for a new methodology for +static analysis that can span the mechanical electrical and software domains +using a common notation. \vspace{30pt} \today