From 72ec87fe21d0690f38a057aa566fe3e95be4b70b Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sun, 15 Aug 2010 21:07:41 +0100 Subject: [PATCH] .:wq --- .../component_failure_modes_definition.tex | 2 +- fmmdset/fmmdset.tex | 87 ++++++++++--------- fzd/fzd.tex | 2 +- introduction/introduction.tex | 9 +- mybib.bib | 12 +++ statistics/statistics.tex | 2 +- style.tex | 6 ++ symptom_ex_process/symptom_ex_process.tex | 1 + vmgbibliography.bib | 10 +++ 9 files changed, 84 insertions(+), 47 deletions(-) diff --git a/component_failure_modes_definition/component_failure_modes_definition.tex b/component_failure_modes_definition/component_failure_modes_definition.tex index 384726c..7bbe54e 100644 --- a/component_failure_modes_definition/component_failure_modes_definition.tex +++ b/component_failure_modes_definition/component_failure_modes_definition.tex @@ -129,7 +129,7 @@ determine the likelihood of component failures causing specific system level errors. For example, Bayes theorem \ref{bayes}, the relation between a conditional probability and its inverse, can be applied to specific failure modes in components and the probability of them causing given system level errors. Another top down technique is to apply cost benefit analysis -to determine which faults are the highest priority to fix\cite{FMEA}. +to determine which faults are the highest priority to fix\cite{bfmea}. The aim of FMMD analysis is to produce complete failure models of safety critical systems from the bottom-up, starting, where possible with known base~component failure~modes. diff --git a/fmmdset/fmmdset.tex b/fmmdset/fmmdset.tex index 058dedd..cdd134c 100644 --- a/fmmdset/fmmdset.tex +++ b/fmmdset/fmmdset.tex @@ -7,8 +7,8 @@ \begin{abstract} This paper describes a process for analysing safety critical systems, to formally prove how safe the designs and built -in safety measures are. It provides -the rigourous method for creating a fault effects model of a system from the bottom up using base~component level fault modes. -Using symptom extraction, and taking functional~groups of components, a fault behaviour +the rigourous method for creating a fault effects model of a system from the bottom up using {\bc} level fault modes. +Using symptom extraction, and taking {\fgs} of components, a fault behaviour hierarchy is built, forming a fault model tree. From the fault model trees, modular re-usable sections of safety critical systems, @@ -89,28 +89,27 @@ The main idea of the methodology is to build a hierarchy of fault modes from the level up to highest system levels. The first stage is to choose -components that interact and naturally form {\em functional groups}. {Functional groups} are thus collections of base parts. +components that interact and naturally form {\fgs}. The initial {\fgs} are thus collections of base parts. %These parts all have associated fault modes. A module is a set fault~modes. - From the point of view of fault analysis, we are not interested in the components themselves, but in the ways in which they can fail. -For this study a functional group will mean a collection of components. -In order to determine the symptoms or failure modes of a {\em functional group} +For this study a {\fg} will mean a collection of components. +In order to determine the symptoms or failure modes of a {\fg} we need to consider all failure modes of its components. By analysing the fault behaviour of a `functional group' with respect these failure modes we can derive a new set of possible failure modes. % -This new set of faults is the set of derived faults from the perspective of the functional~group, and is thus at a higher level of -fault~mode abstraction. Thus we can say that the functional~group as an entity, can fail in a number of well defined ways. +This new set of faults is the set of derived faults from the perspective of the {\fg}, and is thus at a higher level of +fault~mode abstraction. Thus we can say that the {\fg} as an entity, can fail in a number of well defined ways. -In other words we have taken a functional group, and analysed how it can fail according to the failure modes of its parts. +In other words we have taken a {\fg}, and analysed how it can fail according to the failure modes of its parts. These new failure~modes are derived failure modes. %The ways in which the module can fail now becomes a new set of fault modes, the fault~modes %being derived from the functional~group. -We can now create a new `derived~component' which has +We can now create a new `{\dc}' which has the failure symptoms of the functional~group as its set of failure modes. This new derived~component is at a higher failure mode abstraction -level than the base components. +level than the {\bcs}. %What this means is the `fault~symptoms' of the module have been derived. % %When we have determined the fault~modes at the module level these can become a set of derived faults. @@ -119,19 +118,25 @@ level than the base components. %to represent the fault behaviour of the entire system. This can be seen as using the modules we have analysed %as parts, parts which may now be combined to create new functional groups, %but as parts at a higher level of fault abstraction. -Applying the same process with derived components we can bring derived components -together to form functional groups and create new derived components +Applying the same process with {\dcs} we can bring {\dcs} +together to form functional groups and create new {\dcs} at a higher abstraction level. +\ifthenelse {\boolean{paper}} +{ +Reference the symptom abstraction paper here +} +{ +This analysis and symptom collection process is described in detail in the Symptom extraction chapter\ref{symptomex}. +} -This analysis and symptom collection process is described in detail in the Symptom extraction chapter. \subsubsection { Definitions } \begin{itemize} -\item base component - a component with a known set of unitary state failure modes -\item functional group - a collection of components chosen to perform a particular task -\item derived failure mode - a failure symptom of a functional group -\item derived component - a functional group after analysis +\item {\bc} - a component with a known set of unitary state failure modes +\item {\fg} - a collection of components chosen to perform a particular task +\item {\em derived failure mode} - a failure symptom of a functional group +\item {\dc} - a new component derived from an analysed {\fg} \end{itemize} \subsubsection{An algebraic notation for identifying FMMD enitities} @@ -163,29 +168,29 @@ the abstraction level zero thus $C^0$. Should we wish to index the components Our base component (if first in the parts~list) could now be uniquely identified as $C^0_1$. -A functional group can use the variable name $FG$. A functional group is a collection +A {\fg} can use the variable name $FG$. A {\fg} is a collection of components. We thus define $FG$ as a set of components that have been chosen as members -of a functional~group. -We can further define the abstraction level of a functional group. +of a {\fg}. +We can further define the abstraction level of a {\fg}. We can say that it is the maximum abstraction level of any of its components. Thus a functional group containing only base components would have an abstraction level zero and could be represented with a superscript of zero thus $FG^0$. The functional group set may also be indexed. -We can apply symptom abstraction to a functional group to find +We can apply symptom abstraction to a {\fg} to find a set of derived failure modes. We are interested in the failure modes -of all the components in the functional group. An analysis process -defined by the symbol `$\bowtie$' is applied to the functional~group. +of all the components in the {\fg}. An analysis process +defined by the symbol `$\bowtie$' is applied to the {\fg}. Using $\alpha$ to symbolise the fault abstraction level, we can state: $$ \bowtie(FG^{\alpha}) \rightarrow C^{{\alpha}+1} $$ The $\bowtie$ function processes each member (component) of the set $FG$ and extracts all the component failure modes, which are used by the analyst to -determine the derived failure modes. A new derived component is created +determine the derived failure modes. A new {\dc} is created where its failure modes are the symptoms from $FG$. -Note that the component will have a higher abstraction level than the functional -group it analysed. +Note that the component will have a higher abstraction level than the {\fg} +it was derived from. \subsubsection{FMMD Hierarchy} @@ -196,10 +201,10 @@ An example of a simple system will illustrate this. \subsection {Example FMEA process using an FMEA diagram} -Consider a simple functional~group $ FG^0_1 $ derived from two base components $C^0_1,C^0_2$. +Consider a simple {\fg} $ FG^0_1 $ derived from two base components $C^0_1,C^0_2$. -We can apply $\bowtie$ to the functional~group $FG$ -and it will return a derived component at abstraction level 1 (with an index of 1 for completeness) +We can apply $\bowtie$ to the {\fg} $FG$ +and it will return a {\dc} at abstraction level 1 (with an index of 1 for completeness) $$ \bowtie( FG^0_1 ) = C^1_1 $$ @@ -212,10 +217,10 @@ By way of exqample applying ${FM}$ to obtain the failure modes $f_N$ $$ {FM}(C^0_2) = \{ f_3, f_4, f_5 \} $$ -The analyst now considers failure modes $f_{1..5}$ in the context of the functional group. +The analyst now considers failure modes $f_{1..5}$ in the context of the {\fg}. The result of this process will be a set of derived failure modes. Let these be $ \{ s_6, s_7, s_8 \} $. -We can now create a derived component $C^1_1$ with this set of failure modes. +We can now create a {\dc} $C^1_1$ with this set of failure modes. Thus: @@ -257,15 +262,15 @@ We can represent this analysis process in a diagram see figure \ref{fig:onestage Figure \ref{fig:fmmdh} shows a hierarchy of failure mode de-composition. It can be seen that the derived fault~mode sets are higher level abstractions of the fault behaviour of the modules. -We can take this one stage further by combining the derived component $C^{1}_{{N}}$ sets to form functional~groups. These -$FG^2_{N}$ functional~groups can be used to create $C^3_{{N}}$ derived components and so on. +We can take this one stage further by combining the {\dc} $C^{1}_{{N}}$ sets to form {\fgs}. These +$FG^2_{N}$ {\fgs} can be used to create $C^3_{{N}}$ {\dcs} and so on. At the top of the hierarchy, there will be one final (where $t$ is the top level) component $C^{t}_{{N}}$ and {\em its fault modes, are the failure modes of the SYSTEM}. The causes for these system level fault~modes will be traceable down to part fault modes, traversing the tree -through the lower level functional groups and components. +through the lower level {\fgs} and components. each SYSTEM level fault may have a number of paths through the tree to different low level of base component failure modes. -In FTA terminology, these paths through the tree are called `minimal cut sets'. +In FTA\cite{nucfta}\cite{nasafta} terminology, these paths through the tree are called `minimal cut sets'. A hierarchy of levels of faults becoming more abstract at each level should @@ -276,7 +281,7 @@ real time control systems often have a small number of major reportable faults ( even though they may have accompanying diagnostic data. -The FMMD hierarchy is of the form of a directed acyclic graph. +The FMMD hierarchy is of the form of a directed acyclic graph\cite{alg}. % XXX better citation really required Each stage of analysis builds the acyclic graph by adding to the top of the tree, leaving the previous work unchanged, very much in the way that the source code control system git\cite{git} manages source code trees. @@ -346,11 +351,11 @@ with any error messages. % in CRC checksum protected packets. -It is interesting to look at one of `functional~groups'. The milli-volt amplifiers are a good example. -These can be analysed by taking a functional~group, the components surrounding the op-amp, +It is interesting to look at a particular {\fg}. The milli-volt amplifiers are a good example. +These can be analysed by taking a {\fg}, the components surrounding the op-amp, a few resistors to determine offset and gain, a safety resistor, and perhaps some smoothing capacitors. -These components form a functional group. This circuit is then analysed for all the fault combinations +These components form a {\fg}. This circuit is then analysed for all the fault combinations of its parts. This produces a collection of possible symptoms/fault~modes for the milli-volt amplifier. The two amplifiers are now connected to an ADC which converts the voltages to binary words for the microprocessor. The micro-processor then uses the values to determine if the readings are valid and then formats text to send @@ -383,7 +388,7 @@ via the RS232 serial line. % \label{fig:mvs} % \end{figure} -This has a number of obvious functional~groups, the PCB power supply, the milli-volt amplifiers, +This has a number of obvious {\fgs}, the PCB power supply, the milli-volt amplifiers, the analog to digital conversion circuitry, the micro processor and the UART (serial link - RS232 transceiver). It would make sense when analysing this system to take each one of these functional~groups in turn and examine them closely. diff --git a/fzd/fzd.tex b/fzd/fzd.tex index 546ab8b..9909213 100644 --- a/fzd/fzd.tex +++ b/fzd/fzd.tex @@ -676,7 +676,7 @@ Note : In figure \ref{fig:picwaie} note that contours \em{D} and \em{E} are in \subsection { Rule 5: Multiple Zone Creation } -A circular reference (often described as a circuit \cite{gtl} \cite{alggraph}) containing more than one pair of pure intersections +A circular reference (often described as a circuit\cite{alg}) containing more than one pair of pure intersections indicates the possibility of a multiple intersection of the contours in the path. The converse is true. Should there be no circular path, there can be diff --git a/introduction/introduction.tex b/introduction/introduction.tex index 0fd7f6a..3c3454d 100644 --- a/introduction/introduction.tex +++ b/introduction/introduction.tex @@ -297,9 +297,9 @@ A classic example of an automated system failing, is the therac-25. This was an X-ray dosage machine, that, due to software errors caused the deaths of several patients and injured more during the 1980's. The Therac-25 was a designed from a manual system, which had checks and interlocks, -and was subsequently computerised. Software bugs were the primary causes of the radiation +and was subsequently computerised. Software safety interlock problems were the primary causes of the radiation overdoses. -\cite{therac} +\cite{safeware}[App. A] Any new safety critical analysis methodology should be able to model software, electrical and hardware faults using a common notation. @@ -484,13 +484,16 @@ On the day of the launch the temperature of this seal was out of range. A bottom up safety approach would have revealed this as a fault. The FTA in use by NASA and the US Nuclear regulatory commisssion -allows for enviromental considerations such as temperature\cite{NASA}\cite{NUK}. +allows for enviromental considerations such as temperature\cite{nasafta}\cite{nucfta}. But because of the top down nature of the FTA technique, the safety designer must be aware of the environemtnal constraints of all component parts in order to use this correctly. This element of FTA is discussed in \ref{surveysc} \section{Therac 25} + +\cite{safeware}[App. A] + %% Here need more detail of what therac 25 was and roughly how it failed %% with refs to nancy %% and then highlight the fact that the safety analysis did not integrate software and hardware domains. diff --git a/mybib.bib b/mybib.bib index 1ca5c7b..831edca 100644 --- a/mybib.bib +++ b/mybib.bib @@ -36,7 +36,19 @@ YEAR = "2009" } +@BOOK{ince, + AUTHOR = "D. C. Ince", + TITLE = "In Introduction to discrete Mathematics, Formal System specification and Z", + PUBLISHER = "Oxford University Press", + YEAR = "1992" +} +@BOOK{safeware, + AUTHOR = "Nancy Leveson", + TITLE = "Safeware: System safety and Computers ISBN: 0-201-11972-2", + PUBLISHER = "Addison-Wesley", + YEAR = "2005" +} @BOOK{bfmea, AUTHOR = "Robin E McDermot et all", diff --git a/statistics/statistics.tex b/statistics/statistics.tex index af2d6c1..ec77f0d 100644 --- a/statistics/statistics.tex +++ b/statistics/statistics.tex @@ -82,7 +82,7 @@ probablistic approach - no direct causation paths to the higher~abstraction faul Often for instance a component in a module within a module within a module etc that has a probability of causing a SYSTEM level fault. -Philosophy behind FTA\cite{NASA}\cite{NUK}. +Philosophy behind FTA\cite{nasafta}\cite{nucfta}. The idea being that probabilities can be assigned to components failing, causing system level errors. diff --git a/style.tex b/style.tex index c2b58b5..4df10b4 100644 --- a/style.tex +++ b/style.tex @@ -68,6 +68,12 @@ \newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}} \newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}} \newcommand{\ohms}[1]{\ensuremath{#1\Omega}} +\newcommand{\fg}{\em functional~group} +\newcommand{\fgs}{\em functional~groups} +\newcommand{\dc}{\em derived~component} +\newcommand{\dcs}{\em derived~components} +\newcommand{\bc}{\em base~component} +\newcommand{\bcs}{\em base~components} %----- Display example text (#1) in typewriter font %\newcommand{\example}[1]{\\ \smallskip\hspace{1in}{\tt #1}\hfil\\ diff --git a/symptom_ex_process/symptom_ex_process.tex b/symptom_ex_process/symptom_ex_process.tex index b465332..3509a60 100644 --- a/symptom_ex_process/symptom_ex_process.tex +++ b/symptom_ex_process/symptom_ex_process.tex @@ -11,6 +11,7 @@ } { +\label{symptomex} \input{./symptom_ex_process/introduction} \input{./symptom_ex_process/topbot} %\input{./symptom_ex_process/sys_abs} diff --git a/vmgbibliography.bib b/vmgbibliography.bib index f78d769..a40f3af 100644 --- a/vmgbibliography.bib +++ b/vmgbibliography.bib @@ -98,6 +98,16 @@ } +@ARTICLE{howse:spider, + AUTHOR = "John Howse, Gem Stapleton and John Taylor", + TITLE = "Spider Diagrams", + JOURNAL = "London Mathematical Society", + volume = "8", +% number = "4", + pages = "145-194", + month = "December", + YEAR = "2005" +} @conference{akehurst:o2.0its, author = "D.~Akehurst and P.~Linington and O.~Patrascoiu",