diff --git a/component_failure_modes_definition/component_failure_modes_definition.tex b/component_failure_modes_definition/component_failure_modes_definition.tex index c18c9a8..01a6873 100644 --- a/component_failure_modes_definition/component_failure_modes_definition.tex +++ b/component_failure_modes_definition/component_failure_modes_definition.tex @@ -587,45 +587,45 @@ of failure modes within components, but also ensuring that combinations across c do not involve any pairs of failure modes within the same component. A recursive algorithm and proof is described in appendix \ref{chap:vennccps}. -\paragraph{Practicality} -Functional Group may consist, typically of four or five components, which typically -have two or three failure modes each. Taking a worst case of mutiplying these -by a factor of five (the number of failure modes and components) would give -$25 \times 15 = 375$ - - - -\begin{verbatim} - -# define a factorial function -# gives 1 for negative values as well -define f(x) { - if (x>1) { - return (x * f (x-1)) - } - return (1) - -} -define u1(c,x) { - return f(c*x)/(f(1)*f(c*x-1)) -} -define u2(c,x) { - return f(c*x)/(f(2)*f(c*x-2)) -} - -define uc(c,x) { - return c * f(x)/(f(2)*f(x-2)) -} - -# where c is number of components, and x is number of failure modes -# define function u to calculate combinations to check for double sim failure modes -define u(c,x) { -f(c*x)/(f(1)*f(c*x-1)) + f(c*x)/(f(2)*f(c*x-2)) - c * f(c)/(f(2)*f(c-2)) -} - - -\end{verbatim} - +%%\paragraph{Practicality} +%%Functional Group may consist, typically of four or five components, which typically +%%have two or three failure modes each. Taking a worst case of mutiplying these +%%by a factor of five (the number of failure modes and components) would give +%%$25 \times 15 = 375$ +%% +%% +%% +%%\begin{verbatim} +%% +%%# define a factorial function +%%# gives 1 for negative values as well +%%define f(x) { +%% if (x>1) { +%% return (x * f (x-1)) +%% } +%% return (1) +%% +%%} +%%define u1(c,x) { +%% return f(c*x)/(f(1)*f(c*x-1)) +%%} +%%define u2(c,x) { +%% return f(c*x)/(f(2)*f(c*x-2)) +%%} +%% +%%define uc(c,x) { +%% return c * f(x)/(f(2)*f(x-2)) +%%} +%% +%%# where c is number of components, and x is number of failure modes +%%# define function u to calculate combinations to check for double sim failure modes +%%define u(c,x) { +%%f(c*x)/(f(1)*f(c*x-1)) + f(c*x)/(f(2)*f(c*x-2)) - c * f(c)/(f(2)*f(c-2)) +%%} +%% +%% +%%\end{verbatim} +%% \pagebreak[1] \section{Component Failure Modes \\ and Statistical Sample Space} diff --git a/components_as_plds/components_as_plds.tex b/components_as_plds/components_as_plds.tex index 0c29891..2334e08 100644 --- a/components_as_plds/components_as_plds.tex +++ b/components_as_plds/components_as_plds.tex @@ -50,7 +50,7 @@ all possible failure modes, and where appropriate, how these failure modes will affect other components in the circuit. Safety analysis of components forming critical circuitry, -is currently performed using scenario based test cases\cite{EN298}, % \cite{gastec}, \cite{tuv}. +is currently performed using scenario based test cases\cite{en298}, % \cite{gastec}, \cite{tuv}. These involve experts checking a circuit for failure modes on a circuit and how these will affect the system, based on their expertise. Because this is a human process, diff --git a/introduction/introduction.tex b/introduction/introduction.tex index d7a2f15..65580da 100644 --- a/introduction/introduction.tex +++ b/introduction/introduction.tex @@ -13,8 +13,6 @@ both the deterministic and probablistic approaches. -%specific `simultaneous failures'\cite{EN298},\cite{EN230},\cite{EN12067} -%and the probability to dangerous fault approach\cite{EN61508}. The visual notation developed was initially designed for electronic fault modelling. However, it was realised that it could be applied to mechanical and software domains as well. @@ -166,7 +164,7 @@ One is a general number of acceptable failures per hour\footnote{The common metr hours of operation} of operation or a given statistical failure on demand. This is the probablistic approach and is embodied in the European Standard -EN61508 \cite{EN61508} (international standard IOC1508). +EN61508 \cite{en61508} (international standard IOC1508). \paragraph{Deterministic safety Measures} The second philosophy, applied to application specific standards, is to investigate @@ -405,7 +403,7 @@ to reduce the possibility of this last condition. \section{Motivation for developing a formal methodology} A feature of many safety critical systems specifications, -including EN298, EN230 \cite{EN298} \cite{EN230} +including EN298, EN230 \cite{en298} \cite{en230} is to demand, at the very least that single failures of hardware or software cannot @@ -455,7 +453,7 @@ for individual component failures and their effects on other components when the For a very small system with say 1000 failure modes this would demand a potential of 500,000 checks for any automated checking process. \vskip 0.3cm - European legislation\cite{EN298} directs that a system must be able to react to two component failures + European legislation\cite{en298} directs that a system must be able to react to two component failures and not go into a dangerous state. \vskip 0.3cm This raises an interesting problem from the point of view of formal modelling. Here we have a binary cross product of all components @@ -496,8 +494,8 @@ overdosed 6 people between 1985 and 1987. An earlier computerised version of the therac-25 (the therac-20) used the same software but kept the hardware interlocks from the previous manual operation machines. The hardware interlocks on the therac-20 functioned correctly and the faulty software in it caused no accidents. -A safety study for the device, using Fault Tree Analysis% \cite{nucfta} -carried out in 1983 +A safety study for the device, using Fault Tree Analysis % \cite{nucfta} +carried out in 1983 excluded the software \cite{safeware}[App. A]. diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index 2ca3e54..4c87c4a 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -10,7 +10,7 @@ when specified components within it fail. Once we know how a functional~group can fail, we can treat it as a component or sub-system with its own set of failure modes. -\paragraph{fmEA applied to the Functional Group} +\paragraph{FMEA applied to the Functional Group} As the functional~group is a set of components, the failure~modes that we have to consider are all the failure modes of its components. Each failure mode (or combination of) investigated is termed a `test case'. @@ -62,9 +62,11 @@ To sumarise: % \item Obtain the list of components in the functional group \item Collect the failure modes of each component into a flat set. \item Choose all single instances (and optional selected combinations\footnote{ -Some specific combinations of failure modes might be included, or with EN298 \cite{en298} -all possible double failure mode conditions} of the failure modes to +Some specific combinations of failure modes might be included. For instance where +a very reliable part is duplicated but very critical, like the 4 engines on a 747 +aircraft.}) of the failure modes to form `test cases'. + \item If required create test cases from all valid double failure mode combinations within the {\fg}. % \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 @@ -93,7 +95,7 @@ statistics and evironmental factors in a variety of sources. \cite{mil1991} \ifthenelse {\boolean{paper}} { -\subsection{Define Failure mode function fm} +\subsection{Define Failure mode function $fm$} } { To re-cap from the definitions chapter \ref{chap:definitions}.