diff --git a/.gitignore b/.gitignore index 56aa0c2..4ea4138 100644 --- a/.gitignore +++ b/.gitignore @@ -15,6 +15,6 @@ *.bbl *.blg -*paper.tex +*_paper.tex *.txt diff --git a/symptom_abstraction/Makefile b/symptom_abstraction/Makefile index 439f031..dcbf296 100644 --- a/symptom_abstraction/Makefile +++ b/symptom_abstraction/Makefile @@ -2,18 +2,25 @@ # # Make the propositional logic diagram a paper # +SOURCE = symptom_abstraction.tex -all: - pdflatex symptom_abstraction.tex - okular symptom_abstraction.pdf +# abstract.tex algorithm.tex fmmd.tex introduction.tex paper.tex process.tex sys_abs.tex topbot.tex -#paper: paper.tex logic_diagram_paper.tex -# latex paper.tex -# dvipdf paper -# okular paper.pdf +paper: paper.tex symptom_abstraction_paper.tex $(SOURCE) + #cat introduction.tex | sed s/chapter/paper/ > introduction.tex + #latex paper.tex + #dvipdf paper pdflatex cannot use eps ffs + pdflatex paper.tex + mv paper.pdf symptom_ex_process_paper.pdf + okular symptom_ex_process_paper.pdf # Remove the need for referncing graphics in subdirectories # -#logic_diagram_paper.tex: logic_diagram.tex -# cat logic_diagram.tex | sed 's/logic_diagram\///' > logic_diagram_paper.tex +symptom_abstraction_paper.tex: symptom_abstraction_paper.tex paper.tex $(SOURCE) + cat symptom_abstraction.tex | sed 's/symptom_abstraction\///' > symptom_abstraction_paper.tex + + +bib: $(SOURCE) + bibtex paper + diff --git a/symptom_abstraction/paper.tex b/symptom_abstraction/paper.tex new file mode 100644 index 0000000..cce8a05 --- /dev/null +++ b/symptom_abstraction/paper.tex @@ -0,0 +1,35 @@ + +\documentclass[a4paper,10pt]{article} +\usepackage{graphicx} +\usepackage{fancyhdr} +\usepackage{tikz} +\usepackage{amsfonts,amsmath,amsthm} +\usepackage{algorithm} +\usepackage{algorithmic} +\usepackage{ifthen} +\newboolean{paper} +\setboolean{paper}{true} % boolvar=true or false + +%\input{../style} + +%\newtheorem{definition}{Definition:} + +\begin{document} +\pagestyle{fancy} + +%\outerhead{{\small\bf Symptom Extraction Process}} +%\innerfoot{{\small\bf R.P. Clark } } + % numbers at outer edges +\pagenumbering{arabic} % Arabic page numbers hereafter +\author{R.P.Clark} +\title{Symptom Extraction Process} +\maketitle +\input{symptom_abstraction_paper} + +\bibliographystyle{plain} +\bibliography{../vmgbibliography,../mybib} + +\today + + +\end{document} diff --git a/symptom_abstraction/symptom_abstraction.tex b/symptom_abstraction/symptom_abstraction.tex index c25f0c5..f2cf60d 100644 --- a/symptom_abstraction/symptom_abstraction.tex +++ b/symptom_abstraction/symptom_abstraction.tex @@ -2,152 +2,25 @@ \ifthenelse {\boolean{paper}} { \begin{abstract} -In modular systems design, it is often very useful to -know the failure modes of the sub-systems used. -This paper outlines a technique for determining the failure modes of a sub-system given -its component parts. -%, and the failure modes of those parts. - - -The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint -diagrams\cite{constraint} to model failure modes and failure mode common symptom collection. -The technique is designed for making building blocks for a hierarchical fault model. - -Once the failure modes have been determined for a sub-system, -that sub-system may be treated as a `component' or `black box' and used -in conjunction with other such analysed sub-systems, to model -higher level sub-systems. In this way a hierarchy to represent the fault behaviour -of a system can be built. - - -%FMMD hierarchy -The hierarchy is built from the bottom up. -Starting with component failure modes at the bottom. -Because the process is bottom-up, syntax checking and tracking can ensure that -no component failure mode can be overlooked. -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\cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced -automatically, where component failure mode statistics are available\cite{mil1991}. - -This paper focuses on the process of building the blocks that are used in the hierarchy. - +This paper applies the symptom extraction technique +using Propositional Logic diagrams, to identify +symptom groups in functional~groups under +analysis. \end{abstract} } -{} +{ +\section{introduction} +This chapter applies the symptom extraction technique +using Propositional Logic diagrams, to identify +symptom groups in functional~groups under +analysis. +} %\clearpage -\section{Introduction} -Fault finding is intinctively performed from the top-down. -A faulty piece of equipment is examined and will have a -symptom or specific fault. The area or sub-system within the -equipemnt will next be looked into. Secific measurements -and checks will be made, and finally a component or a low level sub-system -will be found to be faulty. -The technique here works the other way. It works from the bottom up. -Starting with a collection of compoents that form -a simple functional group, the effect of all component error modes are -examined, as to their effect on the functional group. -The effects on the functional group can then be collected as common symptoms, -and now we may treat the functional group as a component. It has a known set of failure modes. -By working from the bottom up, we can trace all possible sources -that could cause a particular mode of equipment failure. -This means that we can obtainm statistical estimates based on the known reliabilities -of the components. -It also means that every component failure mode must at the very least be considered. \subsection{Static Analysis} -In the field of safety critical engineering; to comply with -European Law a product must be certified under the approriate `EN' standard. -Typically environmental stress, EMC, electrical stressing, endurance tests, -software~inspections and project~management quality reviews are applied\cite{sccs}. - -Static testing is also applied. This is theoretical analysis of the design of the product from the safety -perspective. -Three main techniques are currenly used, -Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis). -The technique outlined here aims to provide a mathematical frame work -to assist in the production of these three results of static analysis. - -{ -The aims are -\begin{itemize} - \item To automate the process where possible - \item To apply a documented trail for each analysis phase (determination of functional groups, and analysis of component failure modes on those groups) - \item To use a modular approach so that analysed sub-systems can be re-used - \item Automatically ensure no failure mode is unhandled - \item To produce a data model from which FTA, FMEA and statistical failure models may be obtained automatically -\end{itemize} -} - - -\subsection{Systems, functional groups, sub-systems and failure modes} - -It is helpful here to define some terms, `system', `functional~group', `component', `base~component' and `sub-system'. - -A System, is really any coherent entity that would be sold as a safety critical product. -A sub-system is a system that is part of some larger system. -For instance a stereo amplifier separate is a sub-system. The -whole Sound System, consists perhaps of the following `sub-systems': -CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface. - -%Thinking like this is a top~down analysis approach -%and is the way in which FTA\cite{nucfta} analyses a System -%and breaks it down. - -A sub-system will be composed of component parts, which -may themselves be sub-systems. However each `component part' -will have a fault/failure behaviour and it should -always be possible to obtain a set of failure modes -for each `component'. - -If we look at the sound system again as an -example; the CD~player could fail in serveral distinct ways, no matter -what has happened to it or has gone wrong inside it. - - -Using the reasoning that working from the bottom up forces the consideration of all possible -component failures (which can be missed in a top~down approach) -we are presented with a problem. Which initial collections of base components should we choose ? - -For instance in the CD~player example; to start at the bottom; we are presented with -a massive list of base~components, resistors, motors, user~switches, laser~diodes all sorts ! -Clearly, working from the bottom~up we need to pick small -collections of components that work together in some way. -These are termed `functional~groups'. For instance the circuitry that powers the laser diode -to illuminate the CD might contain a handful of components, and as such would make a good candidate -to be one of the base level functional~groups. - - -In choosing the lowest level (base component) sub-systems we would look -for the smallest `functional~groups' of components within a system. A functional~group is a set of components that interact -to perform a specific function. - -When we have analysed the fault behaviour of a functional group, we can treat it as a `black box'. -We can now call our functional~group a sub-system. The goal here is to know how will behave under fault conditions ! -%Imagine buying one such `sub~system' from a very honest vendor. -%One of those sir, yes but be warned it may fail in these distinct ways, here -%in the honest data sheet the set of failure modes is listed! -This type of thinking is starting to become more commonplace in product literature, with the emergence -of reliability safety standards such as IOC1508\cite{sccs},EN61508\cite{en61508}. -FIT (Failure in Time - expected number of failures per billion hours of operation) values -are published for some micro-controllers. A micro~controller -is a complex sub-system in its self and could be considered a `black~box' with a given reliability. -\footnote{Microchip sources give an FIT of 4 for their PIC18 series micro~controllers\cite{microchip}, The DOD -1991 reliability manual\cite{mil1991} applies a FIT of 100 for this generic type of component} - -As electrical components have detailed datasheets a useful extension of this would -be failure modes of the component, with environmental factors and MTTF statistics. - -Currently this sort of information is generally only available for generic component types\cite{mil1991}. - - -%At higher levels of analysis, functional~groups are pre-analysed sub-systems that interact to -%erform a given function. \vspace{0.3cm} %\begin{table}[p] @@ -208,7 +81,9 @@ in a region enclosed by the contours representing the failure modes it investiga The effect on the sub-system of each test case is analysed. %It is then represented on the diagram by an asterisk on the contour representing the failure mode. -The `test~case~results' are archived. +The `test~case~results' are archived. +That is to say the results from each test case are now associated with the +asterisk point. When all test cases have been analysed, we switch our attention to a higher abstraction level. % We treat the sub-system as a black box, or as a component part itsself. % We can now look at the test case results from the perspective of a `user' @@ -268,7 +143,7 @@ is represented as a contour. These contours represent the failure modes of the s \section{A general Sub-System example} -Consider a functional group $FG$ with component parts $A$,$B$ and $C$. +Consider a functional group $FG$ with component parts $C_1$,$C_2$ and $C_3$. Each part has a set of related fault modes (i.e. ways in which it can fail to operate correctly). Let us define the following failure modes for each component part, defining a function $FM()$ where $K$ is a component part and $F$ is its set of failure modes\footnote{Base component failure modes are defined, often with @@ -281,9 +156,9 @@ $$ \\ For our example above \\ -$$ FM(A) = \{ a_1, a_2, a_3 \} $$ -$$ FM(B) = \{ b_1, b_2 \} $$ -$$ FM(C) = \{ c_1, c_2 \} $$ +$$ FM(C_1) = \{ a_1, a_2, a_3 \} $$ +$$ FM(C_2) = \{ b_1, b_2 \} $$ +$$ FM(C_3) = \{ c_1, c_2 \} $$ We can now represent the sub-system as a set of component faulure modes $FG_{cfm}$, thus @@ -371,7 +246,7 @@ This is performed on the diagram by linking the test cases with lines to form `s For the sake of example let us consider the fault symptoms $SP1 = \{fs_2, fs_4, fs_5\}$ to be an identical failure mode at the {\em sub-system} level. These can then be joined to form a spider. Likewise let $SP2 = \{fs_1, fs_3, fs_7\}$ be an identical failure mode at the {\em sub-system} level. -Let $\{fs_6\}$ be a distinct failure mode at {\em sub-system} level. +Let $SP3 = \{fs_6\}$ be a distinct failure mode at {\em sub-system} level. The diagram can now be drawn as in figure \ref{fig:gensubsys3}. @@ -399,7 +274,7 @@ The result of this will be, a set of failure modes for the sub-system, as thoug or a {\em component} to be used in higher level designs. -We have now in $SP1$, $SP2$ and $fs_6$ the three ways in which this sub-system can fail. +We have now in $SP1$, $SP2$ and $SP_3$ the three ways in which this sub-system can fail. In other words we have derived failure modes for this sub-system. @@ -447,7 +322,7 @@ In other words we have derived failure modes for this sub-system. This sub-system may now therfore, be represented as three separate failure modes. We may now treat this sub-system as we would a component with a known set of failure modes. -The failure modes of the Sub-system $SS$ are now the set $SS_{fm} = \{ SP1, Sp2, fs_6 \}$. +The failure modes of the Sub-system $SS$ are now the set $SS_{fm} = \{ SP1, SP2, SP_3 \}$. Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now write @@ -491,222 +366,7 @@ with known failure modes. -\clearpage -\section{A Formal Algorithmic Description of `Symptom Abstraction'} -The algorithm for {\em symptom abstraction} is described in -this section -%describes the symptom abstraction process -using set theory. - -The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$ -and converts it to a sub-system $SS$. -The sub-system $SS$ is a collection -of failure~modes of the sub-system. -The sub-system $SS$ may now be treated -as a component with a known set of failure modes. -Thus $SS$ can be used as a system building block at a higher -level of fault abstraction. - - -The algorithm has been broken down into five stages, each following on from the other. - -\begin{algorithm}[h+] - ~\label{alg:sympabs1} -\caption{Determine failure modes: $FG \mapsto FG_{cfm}$} \label{alg:sympabs11} -\begin{algorithmic}[1] -%\REQUIRE Obtain a list of components for the System $S$ under investigation. -%ENSURE Decomposition of $S$ into atomic components where each component $c$ has a know set of $fm$ failure modes. - - -%\STATE Determine functional groups $fg_n \subset S$ of components, where n is an index number and the number of functional groups found. - -\STATE { Let $FG$ be a set of components } \COMMENT{ The functional group should be chosen to be minimally sized collections of components that perform a specific function} -\STATE { Let $c$ represent a component} -\STATE { Let $CFM$ represent a set of failure modes } -\STATE { $FM(c) \mapsto CFM $} \COMMENT {Let the function $FM$ take a component and return a set of all its failure modes} - -%\ENSURE { $ \forall c | c \in FG \wedge FM(c) \neq \emptyset $} -%\ENSURE { $ c | c \in FG \wedge FM(c) \neq \emptyset $} -\ENSURE{ Each component $c \in FG $ has a known set of failure modes i.e. $FM(c) \neq \emptyset$ } -%\REQUIRE{ Ensure that all components belong to at least one functional group $\bigcup_{i=1...n} fg_i = S $ } -%symptom_abstraction -% okular - -\STATE {let $FG_{cfm}$ be a set of failure modes} - -\STATE {Collect all failure modes from the components into the set $FM_{cfm}$} -%\FORALL { $c \in FG $ } -%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from the components into the set $FM_{cfm}$} -%\ENDFOR - -%\hline -Algorthim \ref{alg:sympabs11} has taken a functional group $FG$ and returned a set of failure~modes $FG_{cfm}$. -The next task is to formulate `test cases'. These are the collections of failure~modes that will be used -in the analysis stages. - - -\end{algorithmic} -\end{algorithm} - - -\begin{algorithm}[h+] - ~\label{alg:sympabs2} -\caption{Determine Test Cases: $FM_{cfm} \mapsto TC $} \label{alg:sympabs22} -\begin{algorithmic}[1] - - \REQUIRE {Determine the test cases to be applied} - - \STATE { All test cases are now chosen by the investigating engineer(s). Typically all single - component failures are investigated - with some specially selected combination faults} - - \STATE { Let $TC$ be a set of test cases } - \STATE { Let $tc_j$ be set of component failure modes where $j$ is an index of $J$} - \COMMENT { Each set $tc_j$ is a `test case' } - \STATE { $ \forall j \in J | tc_j \in TC $ } - - %\STATE { $ \bigcup_{j=1...N} tc_j = \bigcup TC $ } - %\COMMENT { All $tc_j$ test cases sets belong to $TC$ } - - %\REQUIRE { $ TC \subset \bigcup (FM_{cfm}) $ } - %\COMMENT { $TC$ is the set of all test_cases -% Let TC be a subset of the powerset of the failure modes $ FG_{cfm} $, -%i.e. only failure modes present in $ FG_{cfm} $ are present in sets belonging to $ TC $} - - - \COMMENT { Ensure the test cases are complete and unique } - - \FORALL { $tc_j \in TC$ } - %\ENSURE {$ tc_j \in \bigcap FG_{cfm} $} - \ENSURE {$ tc_j \in \mathcal{P} FG_{cfm} $} - \COMMENT { require that the test case is a member of the powerset of $FM_{cfm}$ } - \ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $} - \COMMENT { Test cases must be unique } - \ENDFOR - - - - \STATE { let $f$ represet a component failure mode } - \REQUIRE { That all failure modes are represented in at least one test case } - \ENSURE { $ \forall f | (f \in FM_{cfm}) \wedge (f \in \bigcup TC) $ } - \COMMENT { This corresponds to checking that at least each failure mode is considered at least once in the analysis; some european standards -imply checking all double fault combinations\cite{en298} } - -%\hline -Algorithm \ref{alg:sympabs22} has taken the set of failure modes $FM_{cfm}$ and returned a set of test cases $TC$. -The next stages is to analyse the effect of each test case on the functional group. - -\end{algorithmic} -\end{algorithm} - -\begin{algorithm}[h+] - ~\label{alg:sympabs3} -\caption{Analyse Test Cases: $ TC \mapsto R $} \label{alg:sympabs33} -\begin{algorithmic}[1] - \STATE { let r be a `test case result'} - \STATE { Let the function $Analyse : tc \mapsto r $ } \COMMENT { This analysis is a human activity, examining the failure~modes in the test case and determining how the functional~group will fail under those conditions} - \STATE { $ R $ is a set of test case results $r_j \in R$ where the index $j$ corresponds to $tc_j \in TC$} - \FORALL { $tc_j \in TC$ } - \STATE { $ rc_j = Analyse(tc_j) $} \COMMENT {this is Fault Mode Effects Analysis (FMEA) applied in the context of the functional group} - \STATE { $ rc_j \in R $ } - \ENDFOR - -%\hline -Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case. -\end{algorithmic} -\end{algorithm} - - - - -\begin{algorithm}[h+] - ~\label{alg:sympabs4} - -\caption{Find Common Symptoms: $ R \mapsto SP $} \label{alg:sympabs44} - -\begin{algorithmic}[1] - - - %\REQUIRE {All failure modes for the components in $fm_i = FM(fg_i)$} - \STATE {Let $sp_l$ be a set of `test cases results' where $l$ is an index set $L$} - \STATE {Let $SP$ be a set whose members are sets $sp_l$} - \COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system} -% - %\COMMENT{This corresponds to a fault symptom of the functional group $FG$} - %\COMMENT{where double failure modes are required the cardinality constrained powerset of two must be applied to each failure mode} - - \FORALL { $ r_j \in R$ } - \STATE { $sp_l \in \mathcal{P} R \wedge sp_l \in SP$ } - \STATE { $sp_l \in \bigcap R \wedge sp_l \in SP$ } \COMMENT{ Collect common symptoms. - Analyse the sub-system's fault behaviour under the failure modes in $tc_j$ and determine the symptoms $sp_l$ that it -causes in the functional group $FG$} - %\ENSURE { $ \forall l2 \in L ( \forall l1 \in L | \exists a \in sp_{l1} \neq \exists b \in sp_{l2} \wedge l1 \neq l2 ) $} - - \ENSURE {$ \forall a \in sp_l | \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$} - - \COMMENT { Ensure that the elements in each $sp_l$ are not present in any other $sp_l$ set } - - \ENDFOR - - - - \STATE { The Set $SP$ can now be considered to be the set of fault modes for the sub-system that $FG$ represents} - -%\hline -Algorithm \ref{alg:sympabs44} raises the failure~mode abstraction level. -The failures have now been considered not from the component level, but from the sub-system or -functional group level. -We now have a set $SP$ of the symptoms of failure. - -\end{algorithmic} -\end{algorithm} - -\begin{algorithm}[h+] - ~\label{alg:sympabs5} - -\caption{Treat the symptoms as failure modes of the Sub-System: $ SP \mapsto SS $} \label{alg:sympabs55} - -\begin{algorithmic}[1] - - \STATE { Let $SS$ be a set of faliure modes with failure modes $f$ indexed by $l$ } - \FORALL { $sp_l \in SP$ } - \STATE { $ f_l = ConvertToFaultMode(sp_l) $} - \STATE { $ f_l \in SS $} - \ENDFOR -%\hline - -Algorithm \ref{alg:sympabs55} is the final stage in the process. We now have a -sub-system $SS$, which has its own set of failure~modes. This can now be treated -as a component, and used to form functional~groups at a higher level of failure~mode~abstraction. -\end{algorithmic} -\end{algorithm} - - - -\clearpage \section{To conclude} -The technique provides a methodology for bottom-up analysis of the fault behaviour of complex safety critical systems. - -\subsection{Hierarchical Simplification} - -Because symptom abstraction collects fault modes, the number of faults to handle decreases -as the hierarchy progresses upwards. -This is seen in real life Systems. At the highest levels the number of faults -reduces. A Sound system might have, for instance only four faults at its highest or System level, -\small -$$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT\}$$ -\normalsize -The number of causes for any of these faults is very large ! -It does not matter which combination of causes caused the fault to the user. -But as the hierarchy goes up in abstraction level the number of faults goes down. - -\subsection{Tracable Fault Modes} - -Because the fault modes are determined from the bottom-up, the causes -for all high level faults naturally form trees. -Minimal cut sets \cite{nasafta} can be determined from these, and by -analysing the statistical likely hood of the component failures -the MTTF and SIL\cite{en61508} levels can be automatically calculated.