From c3e8946c39f3bb897cfa4796de4d744b714ae642 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 30 Oct 2010 12:29:15 +0100 Subject: [PATCH 01/11] Looking through for errors b4 John Howse submssn --- symptom_ex_process/process.tex | 63 ++++++++++++++++++++++++---------- 1 file changed, 44 insertions(+), 19 deletions(-) diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index e32d6fc..e34694e 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -270,6 +270,11 @@ from base level components cannot be overlooked. The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). } % +This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component +with known failure modes +(although at a higher level of abstraction). +This process can be repeated using {\dcs} to build a +hierarchical fault~mode model. The newly derived component $DC$ is available for use to form higher level functional groups, and we can thus consider DC as being in the set of components i.e. $DC \in \mathcal{C}$ @@ -277,11 +282,11 @@ consider DC as being in the set of components i.e. $DC \in \mathcal{C}$ \subsection{Defining the analysis process \\ as a function} -Where $\mathcal{F}$ is the set of all sets of failure modes, and $\mathcal{DC}$ +Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$ is the set of all derived components, we can define the symptom abstraction process thus: $$ %\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent -\bowtie : \mathcal{F} \rightarrow \mathcal{DC} +\bowtie : \mathcal{FG} \rightarrow \mathcal{DC} $$ \paragraph{Extending $\bowtie$ to {\dcs}} @@ -293,21 +298,38 @@ This generalises the function $\bowtie$ and allows us to build hierarchical failure mode models. Where a {\fg} is composed of derived components, for sake of example -where $DC_1, DC_2, DC_3 $ are {\dc}s and $DCFM$ is a set of failure modes thus -$FG = \{ DC_1, DC_2, DC_3 \}$ and $DCFM = FM(FG)$. +where $DC_1, DC_2, DC_3 $ are {\dc}s we could collect these into a {\fg} thus +$FG_{derived} = \{ DC_1, DC_2, DC_3 \}$. + +$DCFM$ is a set of failure modes from the new {\fg} $FG_{derived},$ +$DCFM = fm(FG_{derived})$. We can apply the symptom abstraction process $\bowtie$ -to the failure mode set $DCFM$. +to the {\fg} comprised of derived components +because we can obtain a failure mode set, +(the failure mode set we have named $DCFM$). + +Thus we can now move up another abstaction level by applying +symptom abstraction/extraction to the functional group +$FG_{derived}$ shown in equation \ref{eqn:fgderived}. + +\begin{equation} +\label{eqn:fgderived} + \bowtie ( FG_{derived} ) = DC_{derived} +\end{equation} + The case where a {\fg} has been created from {\dcs} using function `$\bowtie$' leads us to -{\dc}s at a higher level of fault abstraction. +{\dc}s at a higher level of failure mode abstraction. +A notation will be described in the next section +to keep track of the abstraction level of a {\dc}. -$$ +%%$$ %\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent -\bowtie : DCFM \rightarrow DC -$$ +%%\bowtie : FG_{derived} \rightarrow DC +%%$$ % %\begin{equation} % \bowtie(FG_{cfm}) = DC @@ -315,14 +337,21 @@ $$ % %or applying the function $fm$ to obtain the $FG_{cfm}$ set % -To put this in context, where FG is a functional group, sourced from base or derived components, -we may state the process of -analysing the failure modes in the {\fg} and returning a {\dc} thus: -\begin{equation} - \bowtie(fm(FG)) = DC -\end{equation} +%%To put this in context, where FG is a functional group, sourced from base or derived components, +%%we may state the process of +%%analysing the failure modes in the {\fg} and returning a {\dc} thus: +%%\begin{equation} +%% \bowtie((FG)) = DC +%%\end{equation} +In other words by analysing a functional group containing derived components +we have a new derived component as our result. +This naturally +builds a bottom-up failure mode model, +with each iteration the model becomes more abstract will eventually reach +the SYSTEM level. + %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} @@ -334,10 +363,6 @@ analysing the failure modes in the {\fg} and returning a {\dc} thus: % \caption{Deriving a new diagram} -This sub-system or {\dc} $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 {\dcs} to build a -hierarchical fault~mode model. From 35942a023cfd1fe1813bda6887e472043741feb5 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 30 Oct 2010 12:55:42 +0100 Subject: [PATCH 02/11] . --- symptom_ex_process/process.tex | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index e34694e..77388ad 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -109,7 +109,6 @@ for each test case. \pagebreak[1] \section{A theoretical `Derived Component' example} - Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. $$ FG = \{ C_1 , C_2 , C_3 \} $$ @@ -178,6 +177,7 @@ This can be seen as all the failure modes that can affect the failure mode group \subsection{Analysis of the functional group failure modes} +\label{theoreticalsx} For this example we shall consider single failure modes. %For each of the failure modes from $fm(FG)$ we shall %create a test case ($g_i$). Next each test case is examined/analysed @@ -286,9 +286,13 @@ Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{ is the set of all derived components, we can define the symptom abstraction process thus: $$ %\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent -\bowtie : \mathcal{FG} \rightarrow \mathcal{DC} +\bowtie : \mathcal{FG} \rightarrow \mathcal{DC} . $$ +Given by +$ \bowtie ( FG ) = DC $ +as per the example in preceeding section \ref{theoreticalsx}. + \paragraph{Extending $\bowtie$ to {\dcs}} It is useful to further define the $\bowtie$ function, to From 02b3ea57a4bd1e835a6534e77f796e906a4fa11e Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 30 Oct 2010 15:12:03 +0100 Subject: [PATCH 03/11] . --- symptom_ex_process/process.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index 77388ad..c1c191e 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -1,4 +1,4 @@ - +\nocite{safeware} \section{Overview of Symptom Extraction Process} % TO DO: separate these two: From 70d9a59b71a84d21df58604fcd8f668f9559da28 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 30 Oct 2010 15:35:54 +0100 Subject: [PATCH 04/11] Added common mode chapter --- common_mode/Makefile | 20 +++++++ common_mode/common_mode.tex | 98 +++++++++++++++++++++++++++++++++++ common_mode/paper.tex | 31 +++++++++++ lifecycle_modelling/paper.tex | 31 +++++++++++ thesis.tex | 3 ++ 5 files changed, 183 insertions(+) create mode 100644 common_mode/Makefile create mode 100644 common_mode/common_mode.tex create mode 100644 common_mode/paper.tex create mode 100644 lifecycle_modelling/paper.tex diff --git a/common_mode/Makefile b/common_mode/Makefile new file mode 100644 index 0000000..1d82cca --- /dev/null +++ b/common_mode/Makefile @@ -0,0 +1,20 @@ + +# + + +paper: paper.tex common_mode_paper.tex + #latex paper.tex + #dvipdf paper pdflatex cannot use eps ffs + pdflatex paper.tex + mv paper.pdf common_mode.pdf + okular common_mode.pdf + + + +# Remove the need for referncing graphics in subdirectories +# +common_mode_paper.tex: common_mode.tex paper.tex + cat common_mode.tex | sed 's/common_mode\///' > common_mode_paper.tex + +bib: + bibtex paper diff --git a/common_mode/common_mode.tex b/common_mode/common_mode.tex new file mode 100644 index 0000000..2efbcb2 --- /dev/null +++ b/common_mode/common_mode.tex @@ -0,0 +1,98 @@ + + + + +\ifthenelse {\boolean{paper}} +{ +\abstract{ +This paper describes how the Failure Mode Modular De-composition (FMMD) methodology +can be applied to the problems of common mode failure +analysis. +% +Common mode failures are often difficult to +determine in embedded real time systems. +% +Environmental effects can lead to component failure +modes, that can occur in separate sub-systems +in a system, but interact to create unexpected fault. +% WHAT IS DID +The FMMD methodology can model and warn for two types of common mode failures. +Failures caused by separate sub-systems relying on +a common component, and environmental effects that can induce failure +modes in components in separate sub-systems. +% WHAT I FOUND +From the FMMD data model it is possible to link the environmental effects +and ensure determine the weak points in a design, where the failure modes may interact. +For the component dependency case, the dependent component +can be automatically highlighted by traversing the data model. +% WHY YOU WOULD WANT TO READ IT +This feature of FMMD proides another tool in the safety engineers +repotiore, one that can shake out difficult to find common mode failure +effects. +} +} +{ +\paragraph{Chapter overview} +This chapter describes how the % Failure Mode Modular De-composition (FMMD) +FMMD methodology +can be applied to the problems of common mode failure +analysis. +% +Common mode failures are often difficult to +determine in embedded real time systems. +% +Environmental effects can lead to component failure +modes, that can occur in separate sub-systems +in a system, but interact to create unexpected fault. +% WHAT IS DID +The FMMD methodology can model and warn for two types of common mode failures. +Failures caused by separate sub-systems relying on +a common component, and environmental effects that can induce failure +modes in components in separate sub-systems. +% WHAT I FOUND +From the FMMD data model it is possible to link the environmental effects +and ensure determine the weak points in a design, where the failure modes may interact. +For the component dependency case, the dependent component +can be automatically highlighted by traversing the data model. +% WHY YOU WOULD WANT TO READ IT +This feature of FMMD proides another tool in the safety engineers +repotiore, one that can shake out difficult to find common mode failure +effects. + +} + + +\section{Introduction} + +\ifthenelse {\boolean{paper}} +{ +paper +} +{ +chapter +} + + +Outline the fmmd process. + + +Show modules with common dependencies (like on a power supply, a powersupply could have a fault +like nopisy output) + + +Trace a theoretical example and show how FMMD detects this (common dependency - like two +{\dc}s being depemdent on the same failure mode. + + +Then show an environmental effect, such as temperature and how +it can induce faults in sepatate modulkes that +would not be obviously related. + +Trace a theoretical example and show how FMMD detects this +i.e. the environmental factor affecting both systems and causing a problem. + + +what about the third way it can be affected. + +Like a chain of relays...... all could get welded .... think about that one..... + diff --git a/common_mode/paper.tex b/common_mode/paper.tex new file mode 100644 index 0000000..0be7084 --- /dev/null +++ b/common_mode/paper.tex @@ -0,0 +1,31 @@ + +\documentclass[a4paper,10pt]{article} +\usepackage{graphicx} +\usepackage{fancyhdr} +\usepackage{tikz} +\usepackage{amsfonts,amsmath,amsthm} +\input{../style} +\usepackage{ifthen} +\newboolean{paper} +\setboolean{paper}{true} % boolvar=true or false + + +%\newtheorem{definition}{Definition:} + +\begin{document} +\pagestyle{fancy} + +%\outerhead{{\small\bf Statistical Basis for Current Static Analysis Methodologies}} +%\innerfoot{{\small\bf R.P. Clark } } + % numbers at outer edges +\pagenumbering{arabic} % Arabic page numbers hereafter +\author{R.P.Clark} +\title{Modelling and Uncovering Common Mode Failures using FMMD} +\maketitle +\input{common_mode_paper} + +\bibliographystyle{plain} +\bibliography{../vmgbibliography,../mybib} + +\today +\end{document} diff --git a/lifecycle_modelling/paper.tex b/lifecycle_modelling/paper.tex new file mode 100644 index 0000000..3bcb0b8 --- /dev/null +++ b/lifecycle_modelling/paper.tex @@ -0,0 +1,31 @@ + +\documentclass[a4paper,10pt]{article} +\usepackage{graphicx} +\usepackage{fancyhdr} +\usepackage{tikz} +\usepackage{amsfonts,amsmath,amsthm} +\input{../style} +\usepackage{ifthen} +\newboolean{paper} +\setboolean{paper}{true} % boolvar=true or false + + +%\newtheorem{definition}{Definition:} + +\begin{document} +\pagestyle{fancy} + +%\outerhead{{\small\bf Statistical Basis for Current Static Analysis Methodologies}} +%\innerfoot{{\small\bf R.P. Clark } } + % numbers at outer edges +\pagenumbering{arabic} % Arabic page numbers hereafter +\author{R.P.Clark} +\title{Product Lifecycle Modelling with FMMD} +\maketitle +\input{life_cycle_modelling_paper} + +\bibliographystyle{plain} +\bibliography{../vmgbibliography,../mybib} + +\today +\end{document} diff --git a/thesis.tex b/thesis.tex index 2ddcf9d..59762ba 100644 --- a/thesis.tex +++ b/thesis.tex @@ -132,6 +132,9 @@ Safety critical in that it must not overheat, and that it must alarm for incorrect temperature. +\chapter{Modelling and uncovering Common Mode Failures using FMMD} +\input{common_mode/common_mode} + \chapter{FMMD Used as a design aide} \input{fmmd_design_aide/fmmd_design_aide} From f79845b8997a6f7e7c30468ea2273bd0601b5794 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 30 Oct 2010 15:39:00 +0100 Subject: [PATCH 05/11] Common mode failure analysis, needs to be traceable. --- symptom_ex_process/process.tex | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index c1c191e..a1c3f7a 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -33,6 +33,13 @@ Each test case must be considered in the for the case of each applied states or environmental conditions that it may be exposed to. In this way all failure mode behaviour due to the test case conditions will be examined. +As part of this analysis process, records must be kept +detailing each test case result along with its resultant +{\fg} failure mode. +This data will be kept in the model and can be used to +examine environmentally sourced common mode failure scenarios. + + %%- A {\fg} may, in the case of an electronic circuit have %%- applied states. For instance test modes, shutdown or lockout modes etc. %%- which are inputs to the circuit. From 514ba73d82f25450ffb37c06ba70ecec889c7d93 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 30 Oct 2010 16:01:49 +0100 Subject: [PATCH 06/11] . --- .../component_failure_modes_definition.tex | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/component_failure_modes_definition/component_failure_modes_definition.tex b/component_failure_modes_definition/component_failure_modes_definition.tex index 77948a6..ce4ed04 100644 --- a/component_failure_modes_definition/component_failure_modes_definition.tex +++ b/component_failure_modes_definition/component_failure_modes_definition.tex @@ -664,6 +664,12 @@ such as Bayes theorem \cite{probstat}. %%- the other parts were just fragments to illustrate points %%- %%- +\section{Complete UML Diagram} +\section{From UML Model to Data Model} +\subsection{Directed Acyclic Graph} +\subsection{Traversing the datamodel} +\subsubsection{Common mode failure detection} +\subsubsection{Common dependency detection} \vspace{40pt} From 785aa0624ee907c9968f5f13b286b0af400a7974 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 30 Oct 2010 17:10:27 +0100 Subject: [PATCH 07/11] . --- symptom_ex_process/introduction.tex | 2 +- thesis.tex | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/symptom_ex_process/introduction.tex b/symptom_ex_process/introduction.tex index f7025b7..5042f07 100644 --- a/symptom_ex_process/introduction.tex +++ b/symptom_ex_process/introduction.tex @@ -30,7 +30,7 @@ Once a hierarchy is in place, it can be converted into a fault data model. From the fault data model, automatic generation of FTA \cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets \cite{nucfta} are possible. Also statistical reliability/probability of failure~on~demand \cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced -automatically, where component failure mode statistics are available \cite{mil1991}. +automatically \footnote{Where component failure mode statistics are available \cite{mil1991}}. % This chapter 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/thesis.tex b/thesis.tex index 59762ba..789645f 100644 --- a/thesis.tex +++ b/thesis.tex @@ -132,7 +132,7 @@ Safety critical in that it must not overheat, and that it must alarm for incorrect temperature. -\chapter{Modelling and uncovering Common Mode Failures using FMMD} +\chapter{Modelling and Uncovering Common Mode Failures using FMMD} \input{common_mode/common_mode} \chapter{FMMD Used as a design aide} From d434799c20bc4eda8c4e3010b3b8bce414451a8f Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 30 Oct 2010 17:43:35 +0100 Subject: [PATCH 08/11] . --- lifecycle_modelling/Makefile | 3 ++- lifecycle_modelling/lifecycle_modelling.tex | 13 +++++++++++++ lifecycle_modelling/paper.tex | 2 +- symptom_ex_process/introduction.tex | 4 +++- 4 files changed, 19 insertions(+), 3 deletions(-) diff --git a/lifecycle_modelling/Makefile b/lifecycle_modelling/Makefile index ef01561..3d6209c 100644 --- a/lifecycle_modelling/Makefile +++ b/lifecycle_modelling/Makefile @@ -1,6 +1,7 @@ # - +# +# paper: paper.tex lifecycle_modelling_paper.tex #latex paper.tex diff --git a/lifecycle_modelling/lifecycle_modelling.tex b/lifecycle_modelling/lifecycle_modelling.tex index 86d9ac9..e0b1582 100644 --- a/lifecycle_modelling/lifecycle_modelling.tex +++ b/lifecycle_modelling/lifecycle_modelling.tex @@ -27,6 +27,7 @@ paper chapter } +\section{discovering a `new' failure mode in a component} Give general idea of how a new failure mode can be integrated into the model. @@ -36,3 +37,15 @@ How it will generally be limited to small sections of th FMMD tree. Give specific example, pretend a new failure mode is discovered in a SCHOTTKY diode. + +Often an electronic component will have a new failure mode `discovered' +I am using as an example a diode which has an exponential relationship +with temperature and reverse leakage current. This is +a failure mode that would not be initially considered in a design. +But when combined with high value resistors could give incorrect voltage readings in some circuits. +I how the FMMD model can have this new failure mode added and what +impact it has on the FMMD data model. + +\section{Discovering New Failure Mode behaviour ina {\dc}} + +\section{New or additional evironmental Conditions} diff --git a/lifecycle_modelling/paper.tex b/lifecycle_modelling/paper.tex index 3bcb0b8..bf05eb6 100644 --- a/lifecycle_modelling/paper.tex +++ b/lifecycle_modelling/paper.tex @@ -22,7 +22,7 @@ \author{R.P.Clark} \title{Product Lifecycle Modelling with FMMD} \maketitle -\input{life_cycle_modelling_paper} +\input{lifecycle_modelling_paper} \bibliographystyle{plain} \bibliography{../vmgbibliography,../mybib} diff --git a/symptom_ex_process/introduction.tex b/symptom_ex_process/introduction.tex index 5042f07..5a8e86c 100644 --- a/symptom_ex_process/introduction.tex +++ b/symptom_ex_process/introduction.tex @@ -32,5 +32,7 @@ of FTA \cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets \cite{nucfta} Also statistical reliability/probability of failure~on~demand \cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced automatically \footnote{Where component failure mode statistics are available \cite{mil1991}}. % -This chapter focuses on the process of building the blocks, the symptom extraction or abstraction process, that is key to creating an FMMD hierarchy. +This chapter focuses on the process of converting {\fgs} to {\dcs}, or building the `blocks' of the FMMD hierarchy. +We can term this stage in FMMD analysis as the `symptom extraction' process. +The symptom extraction or abstraction process, is the key process in creating an FMMD hierarchy. } From 2bd6b307b9464190cbfccfc1966802812afb07cd Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 30 Oct 2010 17:51:32 +0100 Subject: [PATCH 09/11] . --- fmmd_concept/fmmd_concept.tex | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/fmmd_concept/fmmd_concept.tex b/fmmd_concept/fmmd_concept.tex index 67f116c..50fdbea 100644 --- a/fmmd_concept/fmmd_concept.tex +++ b/fmmd_concept/fmmd_concept.tex @@ -7,7 +7,7 @@ \abstract{ This paper proposes a methodology for creating failure mode models of safety critical systems, which -have a common notation +has a common notation for mechanical, electronic and software domains and apply an incremental and rigorous approach. @@ -328,10 +328,14 @@ give a value for the `safety level' for the equipment in a given environment. %%-• The operational profile (environmental stress factors). This uses MTFF and other statisical models to determine the probability of -failures occurring. A component failure mode, given its MTTF +failures occurring. +% +A component failure mode, given its MTTF the probability of detecting the fault and its safety relevant validation time $\tau$, contributes a simple risk factor that is summed -in to give a final risk result. Thus a statistical +in to give a final risk result. +% +Thus a statistical model can be implemented on a spreadsheet, where each component has a calculated risk, a fault detection time (if any), an estimated risk importance and other factors such as de-rating and environmental stress. From bf210d6bcabdfe3cfb4c6c1156db5ca10a3a7b68 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 30 Oct 2010 18:09:28 +0100 Subject: [PATCH 10/11] Added a skeleton test rigs chapter --- test_rigs/Makefile | 20 +++++++++ test_rigs/paper.tex | 31 ++++++++++++++ test_rigs/test_rigs.tex | 90 +++++++++++++++++++++++++++++++++++++++++ thesis.tex | 3 ++ 4 files changed, 144 insertions(+) create mode 100644 test_rigs/Makefile create mode 100644 test_rigs/paper.tex create mode 100644 test_rigs/test_rigs.tex diff --git a/test_rigs/Makefile b/test_rigs/Makefile new file mode 100644 index 0000000..63e4f52 --- /dev/null +++ b/test_rigs/Makefile @@ -0,0 +1,20 @@ + +# + + +paper: paper.tex test_rigs_paper.tex + #latex paper.tex + #dvipdf paper pdflatex cannot use eps ffs + pdflatex paper.tex + mv paper.pdf test_rigs.pdf + okular test_rigs.pdf + + + +# Remove the need for referncing graphics in subdirectories +# +test_rigs_paper.tex: test_rigs.tex paper.tex + cat test_rigs.tex | sed 's/test_rigs\///' > test_rigs_paper.tex + +bib: + bibtex paper diff --git a/test_rigs/paper.tex b/test_rigs/paper.tex new file mode 100644 index 0000000..dbf7991 --- /dev/null +++ b/test_rigs/paper.tex @@ -0,0 +1,31 @@ + +\documentclass[a4paper,10pt]{article} +\usepackage{graphicx} +\usepackage{fancyhdr} +\usepackage{tikz} +\usepackage{amsfonts,amsmath,amsthm} +\input{../style} +\usepackage{ifthen} +\newboolean{paper} +\setboolean{paper}{true} % boolvar=true or false + + +%\newtheorem{definition}{Definition:} + +\begin{document} +\pagestyle{fancy} + +%\outerhead{{\small\bf Statistical Basis for Current Static Analysis Methodologies}} +%\innerfoot{{\small\bf R.P. Clark } } + % numbers at outer edges +\pagenumbering{arabic} % Arabic page numbers hereafter +\author{R.P.Clark} +\title{FMMD used to assist the design of production test rigs} +\maketitle +\input{test_rigs_paper} + +\bibliographystyle{plain} +\bibliography{../vmgbibliography,../mybib} + +\today +\end{document} diff --git a/test_rigs/test_rigs.tex b/test_rigs/test_rigs.tex new file mode 100644 index 0000000..70546b6 --- /dev/null +++ b/test_rigs/test_rigs.tex @@ -0,0 +1,90 @@ + + + + +\ifthenelse {\boolean{paper}} +{ +\abstract{ +This paper describes how the Failure Mode Modular De-composition (FMMD) methodology +can be applied to the design of automated production test rigs +analysis. +% +Test rigs are often used as part of the production process +to ensure that the SYSTEM is not only operating +correctly but also calibrated where necessary. +% +% WHAT IS DID +Mention Chris Garret and Maikowqski theses : both directly relevant. +% WHAT I FOUND +From the FMMD data model it is possible to link +sub-systems under test to +{\dcs} determined from the FMMD process. +Armed with this knowledge +the tester can be pointed to the +likely faulty components. +% WHY YOU WOULD WANT TO READ IT +This feature of FMMD proides another tool in the safety engineers +repotiore, one that can shake out difficult to find +component failures from a high level test result failure. +} +} +{ +\paragraph{Chapter overview} +This chapter describes how the % Failure Mode Modular De-composition (FMMD) +FMMD methodology +can be applied to the problems of +test rig design and construction. +% + +% +Test rigs are often used as part of the production process +to ensure that the SYSTEM is not only operating +correctly but also calibrated where necessary. +% +% WHAT IS DID +Mention Chris Garret and Maikowqski theses : both directly relevant. +% WHAT I FOUND +From the FMMD data model it is possible to link +sub-systems under test to +{\dcs} determined from the FMMD process. +Armed with this knowledge +the tester can be pointed to the +likely faulty components. +% WHY YOU WOULD WANT TO READ IT +This feature of FMMD proides another tool in the safety engineers +repotiore, one that can shake out difficult to find +component failures from a high level test result failure. +} + + +\section{Introduction} + +\ifthenelse {\boolean{paper}} +{ +paper +} +{ +chapter +} + +\subsection{Description of a typical `test rig'} + + +Outline the fmmd process. + + +Show modules +which would be testable by a test rig + +values read or logical conditions from {\dcs} +at a mid-level. + + +Trace a theoretical example and show how FMMD detects the +possible causes of the test rig failure. + + +Exlain why this would save time and money, and possibly +because testing is typically done in house +reveal any unknown failure modes of {\dcs} or even base components. + diff --git a/thesis.tex b/thesis.tex index 789645f..b834d4e 100644 --- a/thesis.tex +++ b/thesis.tex @@ -138,6 +138,9 @@ for incorrect temperature. \chapter{FMMD Used as a design aide} \input{fmmd_design_aide/fmmd_design_aide} +\chapter{FMMD used to aid the design of production test rigs} +\input{test_rigs/test_rigs} + \chapter{FMMD use throughout product lifecycle} \input{lifecycle_modelling/lifecycle_modelling} From 53352f41d87e0db41a23770a5da443a9345b982e Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Thu, 4 Nov 2010 08:05:52 +0000 Subject: [PATCH 11/11] morning edit --- fmmd_concept/fmmd_concept.tex | 104 ++++++++++++++++++++-------------- 1 file changed, 60 insertions(+), 44 deletions(-) diff --git a/fmmd_concept/fmmd_concept.tex b/fmmd_concept/fmmd_concept.tex index 50fdbea..b57eb89 100644 --- a/fmmd_concept/fmmd_concept.tex +++ b/fmmd_concept/fmmd_concept.tex @@ -7,14 +7,14 @@ \abstract{ This paper proposes a methodology for creating failure mode models of safety critical systems, which -has a common notation +have a common notation for mechanical, electronic and software domains and apply an incremental and rigorous approach. %% What I have done %% The Four main static failure mode analysis methodologies were examined and -in in the context of newer European safety standards assessed. +in the context of newer European safety standards assessed. Some of the defeciencies in these methodologies lead to a wish list for a more ideal methodology. @@ -27,7 +27,7 @@ methodology is developed. The has been named Failure Mode Modular De-Composition %% Sell it %% In addition to addressing the traditional weaknesses of -Fault Tree Analysis (FTA), Fault Mode Effects Analysis (FMEA), Faliue Mode Effects Criticallity Analysis (FMECA) +Fault Tree Analysis (FTA), Fault Mode Effects Analysis (FMEA), Failure Mode Effects Criticallity Analysis (FMECA) and Failure Mode Effects and Diagnostic Analysis (FMEDA), FMMD provides the means to model multiple failure mode scenarios as specified in newer European Safety Standards \cite{en298}. The proposed methodology is bottom-up and @@ -145,14 +145,14 @@ are held in a computer program, we can determine if the model is complete \subsection{General Comments on bottom-up and top down approaches} -\paragraph{A general Problem with top-down} +\paragraph{A general defeciency in top-down systems analysis} With a top down approach the investigator has to determine -a set of undesireable outcomes or accidents. +a set of undesirable outcomes or accidents. As most accidents are unexpected and the causes unforseen \cite{safeware} it is fair to say that a top down approach is not guaranteed to predict all possible undesirable outcomes. It also can miss known component failure modes, by -simple not de-composing down to that level of detail. +simply not de-composing down to that level of detail. \paragraph{A general problem with bottom-up} With the bottom up techniques we have all the known component failure modes @@ -165,22 +165,22 @@ we cannot consider them all and human judgement is used to decide which interactions are important. Let N be the number of components in our system, and K be the average number of component failure modes -(ways in which the component can fail). The total number of base component failure modes -is $N \times K$. To even examine the affect that one failure mode has on all the other components +(ways in which the component can fail). The total number of base comp failure modes +is $N \times K$. To examine the affect that one failure mode has on all the other components will be $(N-1) \times N \times K$, in effect a set cross product. Complicate this further with applied states or environmental conditions and another order of cross product of complexity is added. -We may have a peice of self checking circuity for instance that +We may have a piece of self checking circuitry for instance that has two states, normal and testing mode commanded by a logic line. Or we may have a mechanical device that has a different -failure mode behaviour for say, differnet ambient pressures or temperatures. +failure mode behaviour for say, different ambient pressures or temperatures. If $E$ is the number of applied states or environmental conditions to consider in a system, the job of the bottom-up analyst is complicated by a cross product factor again $(N-1) \times N \times K \times E$. -If we put some typical very small embedded system numbersi\footnote{these figures would +If we put some typical very small embedded system numbers\footnote{these figures would be typical of a very simple temperature controller, with a micro-controller sensor and heater circuit} into this, say $N=100$, $K=2.5$ and $E=10$ we have $99 \times 100 \times 2.5 \times 10 = 247500 $. To look in detail at a quarter of a million test cases is obviously impractical. @@ -188,7 +188,7 @@ To look in detail at a quarter of a million test cases is obviously impractical. If we were to consider multiple simultaneous failure modes we have yet another complication cross product. -For instance for looking at double simultaneous failure modes +For instance for looking at double simultaneous failure modes, the equation reads $(N-2) \times (N-1) \times N \times K \times E$. The bottom-up methodologies FMEA, FMECA and FMEDA take single failure modes and link them @@ -198,8 +198,8 @@ component failure mode to the SYSTEM level. -\paragraph{Ideal Static failure mode methodology} -An ideal Static failure mode methodology would build a failure mode model +\paragraph{Ideal static failure mode methodology} +An ideal static failure mode methodology would build a failure mode model 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 @@ -217,7 +217,7 @@ 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 +systems in the early 1960s and was not designed as a rigorous fault/failure mode methodology. It is more like a structure to be applied when discussing the safety of a system, with a top down hierarchical notation, that guides the analysis. This methodology was designed for @@ -244,7 +244,7 @@ The investigation will typically point to a particular failure of a component. The methodology is now applied to find the significance of the failure. Its is based on a simple equation where $S$ ranks the severity (or cost \cite{fmea}) of the identified SYSTEM failure, -$O$ its occurrance, and $D$ giving the failures detectability. Muliplying these +$O$ its occurance, and $D$ giving the failures detectability. Muliplying these together, gives a risk probability number (RPN), given by $RPN = S \times O \times D$. This gives in effect @@ -286,7 +286,7 @@ The results, as with FMEA are an $RPN$ number determining the significance of th %%-WIKI- while various forms of FMEA predominate in other industries. -\subsubsection{ FMEA weaknesses } +\subsubsection{ FMECA weaknesses } \begin{itemize} \item Possibility to miss the effects of failure modes at SYSTEM level. \item Possibility to miss environmental affects. @@ -314,7 +314,7 @@ The component may be mitigated by a vatriety of factors \item Coverage of self checking \end{itemize} -Ultimately this tequnique calculates a risk factor for each component. +Ultimately this technique calculates a risk factor for each component. The risk factors of all the components are summed and give a value for the `safety level' for the equipment in a given environment. @@ -327,7 +327,7 @@ give a value for the `safety level' for the equipment in a given environment. %%-• The design strength (de-rating, safety factors) and %%-• The operational profile (environmental stress factors). -This uses MTFF and other statisical models to determine the probability of +This uses MTFF and other statistical models to determine the probability of failures occurring. % A component failure mode, given its MTTF @@ -342,21 +342,29 @@ and other factors such as de-rating and environmental stress. This can be calculated, with one component failure mode per row, on a spreadsheet and these are all summed to give the final assessment figure. -\paragraph{Two statistical perspectives} -The Statistical Analysis method is used from two perspectives, +\subsubsection{Two statistical perspectives} +he Statistical Analysis method is used from two perspectives, Probability of Failure on Demand (PFD), and Probability of Failure -in continuous Operation, Failure in Time (FIT) and measured in failures per billion ($10^9$) hours of operation. +in continuous Operation, Failure in Time (FIT). +\paragraph{Failure in Time (FIT)}. + +Continuous operation is measured in failures per billion ($10^9$) hours of operation. +For a continuously running nuclear powerstation +we would be interested in its operational FIT values. + +\paragraph{Probability of Failure on Demand (PFD)}. For instance with the anti-lock system on a automobile braking system, we would be interested in PFD. -For a continuously running nuclear powerstation -we would be interested in its 24/7 operation FIT values. +That is to say the ratio of it failing +to succeeding on demand. +\subsubsection{FMEDA and determinability prediction accuracy}. This suffers from the same problems of lack of determinability prediction accuracy, as FMEA above. % We have to decide how particular components failing will impact on the SYSTEM or top level. This involves a `leap of faith'. For instance, a resistor failing in a sensor circuit -may be part of a critical monitioring function. +may be part of a critical monitoring function. The analyst is now put in a position where he must assign a critical failure possibility to it. % @@ -365,10 +373,10 @@ of how that resistor would/could affect that circuit, but because the circuitry it is part of critical section it will be linked to a critical system level fault. % A $\beta$ factor, the hueristically defined probability -of the failure causign the system fault may be applied. +of the failure causing the system fault may be applied. % But because there is no detailed analysis of the failure mode behaviour -of the component, traceable to the SYSTEM level, it becomnes more +of the component, traceable to the SYSTEM level, it becomes more guess work than science. With FMEDA, there is no rigorous cause and effect analysis for the failure modes. Unintended side effects that lead to failure can be missed. @@ -405,6 +413,10 @@ for its results. \item It should be capable of producing reliability and danger evaluation statistics. \item It should be easy to use, Ideally using a graphical syntax (as oppossed to a formal mathematical one). \item From the top down, the failure mode model should follow a logical de-composition of the functionality +for its results. +\item It should be capable of producing reliability and danger evaluation statistics. +\item It should be easy to use, ideally using a graphical syntax (as oppossed to a formal mathematical one). +\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}. \item Multiple failure modes may be modelled from the base component level up. \end{itemize} @@ -412,7 +424,7 @@ to smaller and smaller functional modules \cite{maikowski}. \section{Design of a new static failure mode based methodology} -\paragraph{New methodology Must be bottom-up} +\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. @@ -422,7 +434,7 @@ The traditional fault finding, or natural fault finding is to work from the top down. % On encountering a -fault, the symptom is first know at the top or +fault, the symptom is first observed at the top or SYSTEM level. By de-composing the functionality of the faulty system and testing we can further de-compose the system until we find the faulty base level component. @@ -432,10 +444,10 @@ Simpler and simpler functional blocks are discovered as we delve further into the way the system works and is built. \paragraph{Design Decision: Methodology must be bottom-up.} -In oder to ensure that all component failure modes are handled, +In order to ensure that all component failure modes are handled, this methodology must start at the bottom, with base component failure modes. In this way automated checking can be applied to all component failure modes -to ensure none have been inadvertantly excluded from the process. +to ensure none have been inadvertently excluded from the process. \paragraph{Need for a `bottom-up' system de-composition} There is an apparent conflict here. The natural way to @@ -450,7 +462,7 @@ and then taking those to form higher level The philosophy of top down de-compositon is very similar. Top down de-compositon applies functional de-composition, because it seeks to break the system down -into manageable and separatetly testable entities. +into manageable and separately testable entities. A second justification for this is that the design process for a product requires both top down and bottom-up thinking. @@ -463,17 +475,21 @@ The base components will typically have several failure modes each. Given a typical embedded system may have hundreds of components This means 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. +at SYSTEM level' criticism of the FTA, FMEDA and FMECA methodologies. \paragraph{Design Decision: Methodolgy must reduce and collate errors at each functional group stage.} -SYSTEMS typically have far fewer failure modes then the sum of their component failure modes. +SYSTEMS typically have far fewer failure modes than the sum of their component failure modes. SYSTEM level failures may be caused by a variety of component failure modes. A SYSTEM level failure mode is an abstracted failure mode, in that it is a symptom of some lower level failure or failures. % ABSTRACTION For instance a failed resistor in a sensor at a base component level is a specific -failure mode. For example it could be called `RESISTOR 1 OPEN'. -Its symptom in a functional group comprising the sensor channel that reads from it may be more abstract. +failure mode. +% +For example it could be called `RESISTOR 1 OPEN'. +Its symptom in a functional group comprising the sensor channel that reads from it may be more abstract +or in other words describe the effect more generally. +% We might call it `READING~HIGH' perhaps. At a higher level still this may be called `SENSOR CHANNEL 1' fault. At a system level it may simply be a `SENSOR FAILURE'. @@ -489,7 +505,7 @@ of failure modes as the abstraction level reaches the SYSTEM level. The next problem is how to we build a failure mode model that converges to a finite set of SYSTEM level failure modes. % -It would be better would be to analyse the failure mode behaviour of each +It would be better to analyse the failure mode behaviour of each functional group, and determine the ways in which it, rather than its components, can fail. % @@ -506,7 +522,7 @@ The number of symptoms of failure should be equal to or less than the number of component failure modes, simply because often there are several potential causes of failure symptoms. % -When we have the the symptoms, we can start thinking of the {\fg} as a component in its own right. +When we have the symptoms, we can start thinking of the {\fg} as a component in its own right. %with a simplified and reduced set of failure symptoms. % We can now create a new {\dc}, where its failure modes @@ -538,7 +554,7 @@ are the same failure w.r.t. the {\fg}. % We can now treat the {\fg} as a component, and call it a {\dc}, in other words, a sub-system with a known set of failure modes. % -We can now create a new{\dc} and assign it these common symptoms +We can now create a new {\dc} and assign it these common symptoms as its failure modes. % This {\dc} can be used to build higher level @@ -548,7 +564,7 @@ an entire system. It can be considered complete when all failure modes from all components are handled and connectable to a SYSTEM level failure mode. -\paragraph{Directed Acyclic Graph}. This will naturally form a DAG +\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 @@ -577,7 +593,7 @@ 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} failure behaviour. +cause the same failure symptoms in the {\fg} failure behaviour. We can collect these failures as common symptoms. % When we have our set of symptoms, we can now create @@ -605,8 +621,8 @@ This ensures that all component failure modes are handled. \subsubsection{ It should be easy to integrate mechanical, electronic and software models.} -Because component failure modes are considered, we have a generic enitity to model. -We can describe a mecanical, electrical or software component in terms of its failure modes. +Because component failure modes are considered, we have a generic entity 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 electro mechanical systems, controlled by computers, @@ -670,7 +686,7 @@ chosing {\fg}s and working bottom-up this hierarchical trait will occur as a nat \section{Conclusion} -This paper provides the backgroud for the need for a new methodology for +This paper provides the background for the need for a new methodology for static analysis that can span the mechanical electrical and software domains using a common notation. \vspace{60pt}