.

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