From cd7991d89462222537423c3531a65d4ccd45c872 Mon Sep 17 00:00:00 2001 From: Robin Date: Sat, 24 Jul 2010 12:27:14 +0100 Subject: [PATCH] . --- symptom_ex_process/Makefile | 8 +- symptom_ex_process/abstract.tex | 15 +- symptom_ex_process/fmmd.tex | 10 +- symptom_ex_process/introduction.tex | 4 +- symptom_ex_process/paper.tex | 2 + symptom_ex_process/process.tex | 25 +- symptom_ex_process/symptom_ex_process.tex | 790 +--------------------- symptom_ex_process/sys_abs.tex | 418 ++++++------ symptom_ex_process/topbot.tex | 4 +- 9 files changed, 255 insertions(+), 1021 deletions(-) diff --git a/symptom_ex_process/Makefile b/symptom_ex_process/Makefile index 611bbdd..42cebbc 100644 --- a/symptom_ex_process/Makefile +++ b/symptom_ex_process/Makefile @@ -2,9 +2,10 @@ # # Make the propositional logic diagram a paper # +SOURCE = abstract.tex algorithm.tex fmmd.tex introduction.tex paper.tex process.tex sys_abs.tex topbot.tex - -paper: paper.tex symptom_ex_process_paper.tex +paper: paper.tex symptom_ex_process_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 @@ -14,7 +15,6 @@ paper: paper.tex symptom_ex_process_paper.tex # Remove the need for referncing graphics in subdirectories # -symptom_ex_process_paper.tex: symptom_ex_process.tex paper.tex +symptom_ex_process_paper.tex: symptom_ex_process.tex paper.tex $(SOURCE) cat symptom_ex_process.tex | sed 's/symptom_ex_process\///' > symptom_ex_process_paper.tex -#component_failure_modes_definition_paper.tex diff --git a/symptom_ex_process/abstract.tex b/symptom_ex_process/abstract.tex index e54f9cc..c8ccd04 100644 --- a/symptom_ex_process/abstract.tex +++ b/symptom_ex_process/abstract.tex @@ -11,28 +11,23 @@ and then determining how that functional group can fail. With this information, we can treat the functional group as a component in its own right. This new component is a derived from the functional~group. -In the field of safety engineering this derived component correspond to a low~level sub-system. -%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. +In the field of safety engineering this derived component corresponds to a low~level sub-system. Once the failure modes have been determined for a sub-system/derived~component, this derived component can be combined with others to form functional groups -to model -higher level sub-systems/derived~components. +to model higher level sub-systems/derived~components. In this way a hierarchy to represent the fault behaviour of a system can be built from the bottom~up. This process can continue until there is a complete hierarchy representing the failure mode behaviour of the entire system under analysis. %FMMD hierarchy -Using the FMMD technique the hierarchy is built from the bottom up to ensure complete failure mode coverage. +%Using the FMMD technique the hierarchy is built from the bottom up to ensure complete failure mode coverage. 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/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}. +From the fault data model, traditional FTA and FMEA models (sub-sets of the fault data model) can be derived if desired. % % -This paper focuses on the process of building the blocks, the symptom extraction or abstraction process, that is key to creating an FMMD hierarchy. +%This paper focuses on the process of building the blocks, the symptom extraction or abstraction process, that is key to creating an FMMD hierarchy. \end{abstract} diff --git a/symptom_ex_process/fmmd.tex b/symptom_ex_process/fmmd.tex index b2d1b17..ad9ba8d 100644 --- a/symptom_ex_process/fmmd.tex +++ b/symptom_ex_process/fmmd.tex @@ -1,3 +1,11 @@ -Describe FMMD +% Describe FMMD + +\section{Background: FMMD outline} +The symptom abstraction process described here, is a core process in the Failure Mode Modular De-Composition (FMMD) +modelling technique. FMMD builds a hierarchy of failure mode behaviours from the bottom up. +Collections of base components are grouped into functional~groups, which are analysed +and then treated as components in thier own right. These higher level, or derived compoenents, +can be used to build derived components at higher levels of abstraction, and ultimately +are used to build an FMMD fault model hierarchy the system modelled. diff --git a/symptom_ex_process/introduction.tex b/symptom_ex_process/introduction.tex index 108434e..3c41b97 100644 --- a/symptom_ex_process/introduction.tex +++ b/symptom_ex_process/introduction.tex @@ -1,4 +1,5 @@ { +\section{Introduction} In failure mode analysis, it is essential to know the failure modes of the sub-systems and components used. This paper outlines a technique for determining the failure modes of a sub-system given @@ -36,7 +37,4 @@ Also statistical reliability/probability of failure~on~demand\cite{en61508} and automatically, 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/symptom_ex_process/paper.tex b/symptom_ex_process/paper.tex index 1eedeb4..65ea25a 100644 --- a/symptom_ex_process/paper.tex +++ b/symptom_ex_process/paper.tex @@ -30,4 +30,6 @@ \bibliography{../vmgbibliography,../mybib} \today + + \end{document} diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index 40c113b..b103678 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -94,7 +94,7 @@ and let the set of all possible failure modes be $\mathcal{F}$. We can define a function $FM$ \begin{equation} -FM : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} +\mathcal{FM} : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} \end{equation} defined by (where $C$ is a component and $F$ is a set of failure modes): @@ -102,8 +102,8 @@ defined by (where $C$ is a component and $F$ is a set of failure modes): $$ FM ( C ) = F $$ %\\ - -And for this example: +e.g. +%And for this example: $$ FM(C_1) = \{ a_1, a_2, a_3 \} $$ $$ FM(C_2) = \{ b_1, b_2 \} $$ @@ -152,7 +152,7 @@ $a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline $a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline $b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline $b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline -$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\ \hline +$c\_1$ & $fs\_6$ & $fgfm_{6}$ & SP3 \\ \hline $c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline % \hline @@ -185,14 +185,14 @@ $ SP1 = \{fgfm_2, fgfm_4, fgfm_5\}$. % These can then be joined to form a spider. Likewise let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. -Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}. +Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}, +s lone symptom can be assigned its own symptom set $SP3 = \{fgfm_6\}$. - -We have now in $SP1$, $SP2$ and $fgfm_6$ as the three ways in which this functional~group can fail. +We have now in $SP1$, $SP2$ and $SP3$ as the three ways in which this functional~group can fail. In other words we have derived failure modes for this functional~group. We can place these in a set of symptoms, $SP$. % -$$ SP = \{ SP1, SP2, fgfm_6 \} $$ +$$ SP = \{ SP1, SP2, SP3 \} $$ % % These three symptoms can be considered the set of failure modes for the functional~group, and @@ -205,14 +205,17 @@ a newly created derived component. Let $DC$ be the newly derived component. This is assigned the failure modes that were derived from the functional~group. We can thus apply the function $FM$ on this newly derived component thus: -$$ FM(DC) = \{ SP1, SP2, fgfm_6 \} $$ +$$ FM(DC) = \{ SP1, SP2, SP3 \} $$ Note that $fgfm_6$, while %being a failure mode has -not being grouped as a common symptom +% not being grouped as a common symptom has \textbf{not dissappeared from the analysis process}. -Were the designer to have overlooked this test case, it would appear in the derived component. +Were the designer to have overlooked this test case, it would appear as a failure mode of the derived component. +i.e. were it not to have been grouped in $SP3$, $ FM(DC)$ would have been $ \{ SP1, SP2, fgfm_6 \}$. This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). +The newly derived compoennt $DC$ is availble 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}$ \subsection{Defining the analysis process as a function} diff --git a/symptom_ex_process/symptom_ex_process.tex b/symptom_ex_process/symptom_ex_process.tex index 029cd70..33b80ae 100644 --- a/symptom_ex_process/symptom_ex_process.tex +++ b/symptom_ex_process/symptom_ex_process.tex @@ -1,795 +1,21 @@ - \ifthenelse {\boolean{paper}} { -\begin{abstract} -In failure mode analysis, it is essential to -know the failure modes of the sub-systems and components used. -This paper outlines a technique for determining the failure modes of a sub-system given -its components. -% -This paper describes a process for taking a functional~group of components, -applying FMEA analysis on all the component failure modes possible in that functional~group, -and then determining how that functional group can fail. -% -With this information, we can treat the functional group -as a component in its own right. -This new component is a derived from the functional~group. -In the field of safety engineering this derived component correspond to a low~level sub-system. -%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/derived~component, -this derived component can be combined with others to form functional groups -to model -higher level sub-systems/derived~components. -In this way a hierarchy to represent the fault behaviour -of a system can be built from the bottom~up. This process can continue -until there is a complete hierarchy representing the failure mode -behaviour of the entire system under analysis. -%FMMD hierarchy -Using the FMMD technique the hierarchy is built from the bottom up to ensure complete failure mode coverage. -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/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}. -% -% -This paper focuses on the process of building the blocks, the symptom extraction or abstraction process, that is key to creating an FMMD hierarchy. -\end{abstract} +\input{abstract} +\input{fmmd} +\input{introduction} } { -\section{Introduction} - -In failure mode analysis, it is essential to -know the failure modes of the sub-systems and components used. -This paper outlines a technique for determining the failure modes of a sub-system given -its components. -% -This chapter describes a process for taking a functional group of components, -applying FMEA analysis on all the component failure modes possible in that functional~group, -and then determining how that functional group can fail. -% -% -With this information, we can treat the functional group -as a component in its own right. -This new component is a derived from the functional~group. -In the field of safety engineering this derived component correspond to a low~level sub-system. -%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/derived~component, -this derived component can be combined with others to form functional groups -to model -higher level sub-systems/derived~components. -% -In this way a hierarchy to represent the fault behaviour -of a system can be built from the bottom~up. This process can continue -until there is a complete hierarchy representing the failure mode -behaviour of the entire system under analysis. -%FMMD hierarchy -Using the FMMD technique the hierarchy is built from the bottom up to ensure complete failure mode coverage. -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/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}. -% -This chapter focuses on the process of building the blocks, the symptom extraction or abstraction process, that is key to creating an FMMD hierarchy. - - +\input{introduction} } +\input{topbot} -%\clearpage +\input{sys_abs} -\section{Fault Finding and Failure Mode Analysis} - -\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 currently used, -Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis). -The FMMD technique is aimed primarily as design verification for -safety critical systems. -However, FMMD also provides the mathematical frame work -to assist in the production of these three results of static analysis. -From the model created by the FMMD technique, the three above failure mode -descriptions can be derived. - -\subsection{Top Down or natural trouble shooting} -It is interesting here to look at the `natural' trouble shooting process. -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 suspected area or sub-system within the -equipment will next be looked into. -The trouble shooter will look for behaviour that is unusual or incorrect -to determine the next area or sub~system to look into, each time -moving to a more detailed lower level. -Specific measurements -and checks will be made, and finally a component or a low level sub-system -will be found to be faulty. -A natural fault finding process is thus top~down. -Top down fault isolation/finding techniques are described in \ref{NETWORKDECOMPOSITION}. -\subsection{FMMD - Bottom~up Analysis} -The FMMD technique does not follow the `natural fault finding' or top down approach, -it instead works from the bottom up. -Starting with a collection of base~components 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 as it has a known set of failure modes. -By reusing the `components' derived from functional~groups an entire -hierarichal failure mode mode of the system can be built. -By working from the bottom up, we can trace all possible sources -that could cause a particular mode of equipment failure. -This means that at the design stage of a product all component failure -modes must be considered. The aim here is for complete failure mode coverage. -This also means that we can obtain 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. - - -%{ -%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 `derived~component/sub-system'. -These are listed in table~\ref{tab:symexdef}. - -A System, is really any coherent entity that would be sold as a product. % 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 components, which -may themselves be sub-systems. However each `component' -will have a fault/failure behaviour and it should -always be possible to obtain a set of failure modes -for each `component'. -%In FMMD terms a sub-system is a derived component. - -If we look at the sound system example, -the CD~player could fail in several distinct ways, -and this couldbe due to a large number of -component failure modes. -%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. -We can define a functional~group as 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'. -The fault behaviour will consist of a set of `symptoms' caused by combinations -of the component failure modes. -We can make a new `component' derived from the functional~group. -The symptoms are the failure modes of this new `derived component'. - -%We can now call our functional~group a sub-system or a derived~component. -%The goal here is to know how it 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} - -Electrical components have detailed datasheets associated with them. A useful extension of this could -be failure modes of the component, with environmental factors and MTTF statistics. -Currently this sort of failure mode 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}[h] -\center -\begin{tabular}{||l|l||} \hline \hline - {\em Definition } & {\em Description} \\ \hline -System & A product designed to \\ - & work as a coherent entity \\ \hline -Sub-system & A part of a system, \\ --or- derived component & sub-systems may contain sub-systems. \\ - & derived~components may by derived \\ - & from derived components \\ \hline -Failure mode & A way in which a System, \\ - & Sub-system or component can fail \\ \hline -Functional Group & A collection of sub-systems and/or \\ - & components that interact to \\ - & perform a specific function \\ \hline -Base Component & Any bought in component, which \\ - & hopefully has a known set of failure modes \\ \hline - \hline -\end{tabular} -\caption{Symptom Extraction Definitions} -\label{tab:symexdef} -\end{table} -%\vspace{0.3cm} - - -\section{The Symptom abstraction Process} - -% TO DO: separate these two: - -\paragraph{Symptom Extraction Described} - -The objective of `symptom abstraction' is to analyse the functional~group and find -how it can fail -when specified components within it fail. -Once we know how 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} -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'. -Each `test case' is analysed. -% -The component failure modes in each test case -are examined with respect to their effect on the functional~group. -% -The aim of this analysis is to find out how the functional~group reacts -to each of the test case conditions. -The goal of the process is to produce a set of failure modes from the perspective of the functional~group. - - - - -\paragraph{Symptom Identification} -When all `test~cases' have been analysed, a second phase is applied. -% -This looks at the results of the `test~cases' as symptoms -of the sub-system. -Single component failures (or combinations) within the functional~group may cause unique symptoms. -However, many failures, when looked at from the perspective of the functional group, will have the same symptoms. -These can be collected as `common symptoms'. -To go back to the CD~player example, a failed -output stage, and a failed internal audio amplifier, -will both cause the same failure; $no\_sound$ ! - - - - -\paragraph{Collection of Symptoms} -The common symptoms of failure and lone~component failure~modes are identified and collected. -We can now consider the functional~group as a component and the common symptoms as its failure modes. -Note that here because the process is bottom up, we can ensure that all failure modes -associated with a functional~group have been handled. -Were failure~modes missed, any failure mode model could be dangerously incomplete. -It is possible here for an automated system to flag unhandled failure modes. -\ref{requirement at the start} - - -\section{The Process : To analyse a base level Derived~Component/sub-system} - -To sumarise: - -\begin{itemize} - \item Determine a minimal functional group - \item Obtain the list of components in the functional group - \item Collect the failure modes for each component -% \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 - \item Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group - \item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use. -Determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider'). - \item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component. - \item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component. -\end{itemize} - - - - -\section{A general derived Component/Sub-System example} - -Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. - -$$ FG = \{ C_1 , C_2 , C_3 \} $$ - -Each component 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, defining a function $FM()$ -that is passed a component and returns the set of failure modes associated with it -\footnote{Base component failure modes are defined, often with -statistics and evironmental factors in a variety of sources. \cite{mil1991} -}. - -To re-cap from the definitions chapter \ref{chap:definitions}. - -Let the set of all possible components be $\mathcal{C}$ -and let the set of all possible failure modes be $\mathcal{F}$. - -We can define a function $FM$ - -\begin{equation} -FM : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} -\end{equation} - -defined by (where $C$ is a component and $F$ is a set of failure modes): - -$$ FM ( C ) = F $$ - -%\\ - -And for this example: - -$$ FM(C_1) = \{ a_1, a_2, a_3 \} $$ -$$ FM(C_2) = \{ b_1, b_2 \} $$ -$$ FM(C_3) = \{ c_1, c_2 \} $$ - - -\paragraph{Finding all failure modes within the functional group} - -For FMMD failure mode analysis, we need to consider the failure modes -from all the components in the functional group as a flat set. -This can be found by applying function $FM$ to all the components -in the functional~group and taking the union of them thus: - -$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} FM(C_j) $$ - -We can actually overload the notation for the function FM -and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: - -\begin{equation} -FM : FG \mapsto \mathcal{F} -\end{equation} - -Applied to the functional~group $FG$ in the example above: -\begin{equation} - FM(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \} -\end{equation} - -This can be seen as all the failure modes that can affect the failure mode group $FG$. - -\subsection{Analysis of the functional group failure modes} - -For this example we shall consider single failure modes. -%For each of the failure modes from $FM(FG)$ we shall -%create a test case ($fgfm_i$). Next each test case is examined/analysed -%and its effect on the functional group determined. - -\par -%\vspace{0.3cm} -\begin{table}[h] -\begin{tabular}{||c|c|c|c||} \hline \hline - {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\ - {\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline -% -$a\_1$ & $fs\_1$ & $fgfm_{1}$ & SP2 \\ \hline -$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline -$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline -$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline -$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline -$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\ \hline -$c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline -% - \hline -\end{tabular} -\caption{Component to functional group to failure symptoms example} -\label{tab:fexsymptoms} -\end{table} -%\vspace{0.3cm} - -Table~\ref{tab:fexsymptoms} shows the analysis process. -As we are only looking at single fault possibilities for this example each failure mode -is represented by a test~case. -The Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}. -The test cases are analysed w.r.t. the functional~group. -These become functional~group~failure~modes ($fgfm$'s). -The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. - -For the sake of example, let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ to be -identical from the perspective of the functional~group. -That is to say, the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes -occur, is going to be the same. -For example, in our CD player example, this could mean the common symptom `no\_sound'. -No matter which component failure modes, or combinations thereof cause the problem, -the failure symptom is the same. -It may be of interest to the manufacturers and designers of the CD player why it failed, but -as far as we the users are concerned, it has only one symptom, -`no\_sound'! -We can thus group these component failure modes into a common symptom, $SP1$, thus -$ SP1 = \{fgfm_2, fgfm_4, fgfm_5\}$. -% These can then be joined to form a spider. -Likewise -let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. -Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}. - - -We have now in $SP1$, $SP2$ and $fgfm_6$ as the three ways in which this functional~group can fail. -In other words we have derived failure modes for this functional~group. -We can place these in a set of symptoms, $SP$. -% -$$ SP = \{ SP1, SP2, fgfm_6 \} $$ -% -% -These three symptoms can be considered the set of failure modes for the functional~group, and -we can treat it as though it were a {\em black box} -or a {\em component} to be used in higher level designs. -% -The next stage of the process could be applied automatically. -Each common symptom becomes a failure mode of -a newly created derived component. Let $DC$ be the newly derived component. -This is assigned the failure modes that were derived from the functional~group. -We can thus apply the function $FM$ on this newly derived component thus: - -$$ FM(DC) = \{ SP1, SP2, fgfm_6 \} $$ - -Note that $fgfm_6$, while %being a failure mode has -not being grouped as a common symptom -has \textbf{not dissappeared from the analysis process}. -Were the designer to have overlooked this test case, it would appear in the derived component. -This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! -The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). - - -\subsection{Defining the analysis process as a function} - -It is useful to define this analysis process as a function. -Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now -write - -$$ -\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent -$$ -% -%\begin{equation} -% \bowtie(FG_{cfm}) = DC -%\end{equation} -% -%or applying the function $FM$ to obtain the $FG_{cfm}$ set -% -Where DC is a derived component, and FG is a functional group: - -\begin{equation} - \bowtie(FM(FG)) = DC -\end{equation} - - -%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} - -% \begin{figure}[h+] -% \centering -% \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg} -% % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 -% \label{fig:gensubsys3} -% \caption{Deriving a new diagram} - - -This sub-system or derived~component $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 derived~components to build a -hierarchical -fault~mode -model. - - - - - -%\section{A Formal Algorithmic Description of `Symptom Abstraction'} -\section{Algorithmic Description} - -The algorithm for {\em symptom extraction} 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 derived~component/sub-system $DC$. -%The sub-system $SS$ is a collection -%of failure~modes of the sub-system. -Note that -$DC$ is a derived component at a higher level of fault analysis abstraction, -than the functional~group it was derived from. -However, it can still be treated -as a component with a known set of failure modes. -\paragraph{Enumerating abstraction levels} -If $DC$ were to be included in a functional~group, -that functional~group must be considered to be at a higher level of -abstraction than a base level functional~group. -% -In fact, if the abstraction level is enumerated, -the functional~group must take the abstraction level -of the highest assigned to any of its components. -% -$DC$ can be used as a system building block at a higher -level of fault abstraction. Because the derived components -merge to form functional groups, a converging hierarchy is -naturally formed with the abstraction level increasing with each tier. - - -The algorithm, representing the function $\bowtie$, has been broken down into five stages, each following on from the other. -These are described using the Algorithm environment in the next section \ref{algorithms}. -By defining the process and describing it using set theory, constraints and -verification checks in the process can be stated formally. - -\clearpage -\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine} - -The first stage is to find the failure modes to consider for -analysis. -Let $FG$ be the set of components in the functional group under analysis, and $c$ -be components that are members of it. -%% -%% Algorithm 1 -%% - -\begin{algorithm}[h+] - ~\label{alg:sympabs1} -\caption{Determine failure modes: $FG \mapsto F$} \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} - -\ENSURE{ Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG | FM(c) \neq \emptyset$ } - -\STATE {let $F=FM(FG)$ be a set of all failure modes to consider for the functional~group $FG$} - -%\STATE {Collect all failure modes from all the components in FG into the set $FG_{cfm}$} -%\FORALL { $c \in FG $ } -%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$} -%\ENDFOR - -%\hline -Algorthim \ref{alg:sympabs11} has taken a functional~group $FG$ and returned a set of failure~modes $F=FM(FG)$ where each component has a known set of failure~modes. -The next task is to formulate `test cases'. These are the combinations of failure~modes that will be used -in the analysis stages. - - -\end{algorithmic} -\end{algorithm} - -\clearpage -\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases} - -From the failure modes associated with the functional~group -we now need to determine test cases. -The test cases are collections of failure modes. -These could be formed from single failure modes or failure modes in combination. -Let $TC$ be the set of test cases associated withthe functional group $FG$. - -%% -%% Algorithm 2 -%% - - -\begin{algorithm}[h+] - ~\label{alg:sympabs2} -\caption{Determine Test Cases: $F \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 $ } \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}(F))$} - \COMMENT { require that the test case is a member of the powerset of $F$ } - \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 F)) \wedge (f \in \bigcup TC) $ } - \COMMENT { This corresponds to checking that at least each failure mode is considered at - least once in the analysis; more rigorous cardinality constraint - checks may be required for some safety standards} - -% some european standards -% imply checking all double fault combinations\cite{en298} } - -%\hline -Algorithm \ref{alg:sympabs22} has taken the set of failure modes $ F=FM(FG) $ and returned a set of test cases $TC$. -The next stage is to analyse the effect of each test case on the functional group. - -\end{algorithmic} -\end{algorithm} - -\clearpage -\subsection{Algorithmic Description of Symptom Abstraction \\ Analyse Test Cases} -%% -%% Algorithm 3 -%% -The test cases are now analysed for their impact on the behaviour of the functional~group. -Let $R$ be a set of results indexed by $j$ (the same index used to identify the test cases $tc_{j}$). - - -\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 $ } \COMMENT{Add $rc_j$ to the set 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} - - -\clearpage -\subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms} -%% -%% Algorithm 4 -%% -This stage analyses the results from bottom-up FMEA analysis ($R$), and collects -results that, from the perspective of the functional~group, have the same failure symptom. -Let set $SP$ be the set of symptoms for the functional group $FG$. - -\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} - -\clearpage -\subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component} -%% -%% Algorithm 5 -%% -This final stage, is the creation of the derived component. -This derived component may now be used to build -new functional groups at higher levels of fault abstraction. -Let $DC$ be a derived component with its own set of failure~modes. - -\begin{algorithm}[h+] - ~\label{alg:sympabs5} - -\caption{Treat the symptoms as failure modes of the Derived~Component/Sub-System: $ SP \mapsto DC $} \label{alg:sympabs55} - -\begin{algorithmic}[1] - - \STATE { Let $DC$ be a derived component with failure modes $f$ indexed by $l$ } - \FORALL { $sp_l \in SP$ } - \STATE { $ f_l = ConvertToFaultMode(sp_l) $} - \STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes} - \ENDFOR -%\hline - -Algorithm \ref{alg:sympabs55} is the final stage in the process. We now have a -derived~component $DC$, which has its own set of failure~modes. This can now be -used in conjection with other components (or derived~components) -to form functional~groups at a higher level of failure~mode~abstraction. -Hierarchies of fault abstraction can be built that can model an entire SYSTEM. -\end{algorithmic} -\end{algorithm} - - -\section{To conclude} - -The symptom abstraction technique allows us to take a functional group of components, analyse the failure -mode behaviour and create a new entity, a derived~component, that has its own set of failure modes. -This process naturally takes one step to building a hierarchical failure mode model -from the bottom-up. - -\subsection{Hierarchical Simplification} - -Because symptom abstraction collects fault modes, the number of faults to handle decreases -as the hierarchy progresses upwards. -This is seen by casual observation of real life Systems. At the highest levels the number of faults -is significantly less than the sum of its component failure modes. -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 to the user, which combination of causes caused the fault. -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 likelyhood of the component failures, -the MTTF and SIL\cite{en61508} levels can be automatically calculated. +\input{process} +\input{algorithm} \vspace{40pt} \today diff --git a/symptom_ex_process/sys_abs.tex b/symptom_ex_process/sys_abs.tex index 6e2cfc2..c2771af 100644 --- a/symptom_ex_process/sys_abs.tex +++ b/symptom_ex_process/sys_abs.tex @@ -50,212 +50,212 @@ Were failure~modes missed, any failure mode model could be dangerously incomplet It is possible here for an automated system to flag unhandled failure modes. \ref{requirement at the start} - -\section{The Process : To analyse a base level Derived~Component/sub-system} - -To sumarise: - -\begin{itemize} - \item Determine a minimal functional group - \item Obtain the list of components in the functional group - \item Collect the failure modes for each component -% \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 - \item Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group - \item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use. -Determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider'). - \item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component. - \item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component. -\end{itemize} - - - - -\section{A general derived Component/Sub-System example} - -Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. - -$$ FG = \{ C_1 , C_2 , C_3 \} $$ - -Each component 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, defining a function $FM()$ -that is passed a component and returns the set of failure modes associated with it -\footnote{Base component failure modes are defined, often with -statistics and evironmental factors in a variety of sources. \cite{mil1991} -}. - -To re-cap from the definitions chapter \ref{chap:definitions}. - -Let the set of all possible components be $\mathcal{C}$ -and let the set of all possible failure modes be $\mathcal{F}$. - -We can define a function $FM$ - -\begin{equation} -FM : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} -\end{equation} - -defined by (where $C$ is a component and $F$ is a set of failure modes): - -$$ FM ( C ) = F $$ - -%\\ - -And for this example: - -$$ FM(C_1) = \{ a_1, a_2, a_3 \} $$ -$$ FM(C_2) = \{ b_1, b_2 \} $$ -$$ FM(C_3) = \{ c_1, c_2 \} $$ - - -\paragraph{Finding all failure modes within the functional group} - -For FMMD failure mode analysis, we need to consider the failure modes -from all the components in the functional group as a flat set. -This can be found by applying function $FM$ to all the components -in the functional~group and taking the union of them thus: - -$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} FM(C_j) $$ - -We can actually overload the notation for the function FM -and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: - -\begin{equation} -FM : FG \mapsto \mathcal{F} -\end{equation} - -Applied to the functional~group $FG$ in the example above: -\begin{equation} - FM(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \} -\end{equation} - -This can be seen as all the failure modes that can affect the failure mode group $FG$. - -\subsection{Analysis of the functional group failure modes} - -For this example we shall consider single failure modes. -%For each of the failure modes from $FM(FG)$ we shall -%create a test case ($fgfm_i$). Next each test case is examined/analysed -%and its effect on the functional group determined. - -\par -%\vspace{0.3cm} -\begin{table}[h] -\begin{tabular}{||c|c|c|c||} \hline \hline - {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\ - {\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline -% -$a\_1$ & $fs\_1$ & $fgfm_{1}$ & SP2 \\ \hline -$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline -$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline -$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline -$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline -$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\ \hline -$c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline -% - \hline -\end{tabular} -\caption{Component to functional group to failure symptoms example} -\label{tab:fexsymptoms} -\end{table} -%\vspace{0.3cm} - -Table~\ref{tab:fexsymptoms} shows the analysis process. -As we are only looking at single fault possibilities for this example each failure mode -is represented by a test~case. -The Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}. -The test cases are analysed w.r.t. the functional~group. -These become functional~group~failure~modes ($fgfm$'s). -The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. - -For the sake of example, let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ to be -identical from the perspective of the functional~group. -That is to say, the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes -occur, is going to be the same. -For example, in our CD player example, this could mean the common symptom `no\_sound'. -No matter which component failure modes, or combinations thereof cause the problem, -the failure symptom is the same. -It may be of interest to the manufacturers and designers of the CD player why it failed, but -as far as we the users are concerned, it has only one symptom, -`no\_sound'! -We can thus group these component failure modes into a common symptom, $SP1$, thus -$ SP1 = \{fgfm_2, fgfm_4, fgfm_5\}$. -% These can then be joined to form a spider. -Likewise -let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. -Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}. - - -We have now in $SP1$, $SP2$ and $fgfm_6$ as the three ways in which this functional~group can fail. -In other words we have derived failure modes for this functional~group. -We can place these in a set of symptoms, $SP$. -% -$$ SP = \{ SP1, SP2, fgfm_6 \} $$ -% -% -These three symptoms can be considered the set of failure modes for the functional~group, and -we can treat it as though it were a {\em black box} -or a {\em component} to be used in higher level designs. -% -The next stage of the process could be applied automatically. -Each common symptom becomes a failure mode of -a newly created derived component. Let $DC$ be the newly derived component. -This is assigned the failure modes that were derived from the functional~group. -We can thus apply the function $FM$ on this newly derived component thus: - -$$ FM(DC) = \{ SP1, SP2, fgfm_6 \} $$ - -Note that $fgfm_6$, while %being a failure mode has -not being grouped as a common symptom -has \textbf{not dissappeared from the analysis process}. -Were the designer to have overlooked this test case, it would appear in the derived component. -This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! -The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). - - -\subsection{Defining the analysis process as a function} - -It is useful to define this analysis process as a function. -Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now -write - -$$ -\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent -$$ -% -%\begin{equation} -% \bowtie(FG_{cfm}) = DC -%\end{equation} -% -%or applying the function $FM$ to obtain the $FG_{cfm}$ set -% -Where DC is a derived component, and FG is a functional group: - -\begin{equation} - \bowtie(FM(FG)) = DC -\end{equation} - - -%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} - -% \begin{figure}[h+] -% \centering -% \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg} -% % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 -% \label{fig:gensubsys3} -% \caption{Deriving a new diagram} - - -This sub-system or derived~component $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 derived~components to build a -hierarchical -fault~mode -model. - - - - - +%%% +%%%\section{The Process : To analyse a base level Derived~Component/sub-system} +%%% +%%%To sumarise: +%%% +%%%\begin{itemize} +%%% \item Determine a minimal functional group +%%% \item Obtain the list of components in the functional group +%%% \item Collect the failure modes for each component +%%%% \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 +%%% \item Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group +%%% \item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use. +%%%Determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider'). +%%% \item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component. +%%% \item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component. +%%%\end{itemize} +%%% +%%% +%%% +%%% +%%%\section{A general derived Component/Sub-System example} +%%% +%%%Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. +%%% +%%%$$ FG = \{ C_1 , C_2 , C_3 \} $$ +%%% +%%%Each component 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, defining a function $FM()$ +%%%that is passed a component and returns the set of failure modes associated with it +%%%\footnote{Base component failure modes are defined, often with +%%%statistics and evironmental factors in a variety of sources. \cite{mil1991} +%%%}. +%%% +%%%To re-cap from the definitions chapter \ref{chap:definitions}. +%%% +%%%Let the set of all possible components be $\mathcal{C}$ +%%%and let the set of all possible failure modes be $\mathcal{F}$. +%%% +%%%We can define a function $FM$ +%%% +%%%\begin{equation} +%%%FM : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} +%%%\end{equation} +%%% +%%%defined by (where $C$ is a component and $F$ is a set of failure modes): +%%% +%%%$$ FM ( C ) = F $$ +%%% +%%%%\\ +%%% +%%%And for this example: +%%% +%%%$$ FM(C_1) = \{ a_1, a_2, a_3 \} $$ +%%%$$ FM(C_2) = \{ b_1, b_2 \} $$ +%%%$$ FM(C_3) = \{ c_1, c_2 \} $$ +%%% +%%% +%%%\paragraph{Finding all failure modes within the functional group} +%%% +%%%For FMMD failure mode analysis, we need to consider the failure modes +%%%from all the components in the functional group as a flat set. +%%%This can be found by applying function $FM$ to all the components +%%%in the functional~group and taking the union of them thus: +%%% +%%%$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} FM(C_j) $$ +%%% +%%%We can actually overload the notation for the function FM +%%%and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: +%%% +%%%\begin{equation} +%%%FM : FG \mapsto \mathcal{F} +%%%\end{equation} +%%% +%%%Applied to the functional~group $FG$ in the example above: +%%%\begin{equation} +%%% FM(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \} +%%%\end{equation} +%%% +%%%This can be seen as all the failure modes that can affect the failure mode group $FG$. +%%% +%%%\subsection{Analysis of the functional group failure modes} +%%% +%%%For this example we shall consider single failure modes. +%%%%For each of the failure modes from $FM(FG)$ we shall +%%%%create a test case ($fgfm_i$). Next each test case is examined/analysed +%%%%and its effect on the functional group determined. +%%% +%%%\par +%%%%\vspace{0.3cm} +%%%\begin{table}[h] +%%%\begin{tabular}{||c|c|c|c||} \hline \hline +%%% {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\ +%%% {\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline +%%%% +%%%$a\_1$ & $fs\_1$ & $fgfm_{1}$ & SP2 \\ \hline +%%%$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline +%%%$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline +%%%$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline +%%%$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline +%%%$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\ \hline +%%%$c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline +%%%% +%%% \hline +%%%\end{tabular} +%%%\caption{Component to functional group to failure symptoms example} +%%%\label{tab:fexsymptoms} +%%%\end{table} +%%%%\vspace{0.3cm} +%%% +%%%Table~\ref{tab:fexsymptoms} shows the analysis process. +%%%As we are only looking at single fault possibilities for this example each failure mode +%%%is represented by a test~case. +%%%The Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}. +%%%The test cases are analysed w.r.t. the functional~group. +%%%These become functional~group~failure~modes ($fgfm$'s). +%%%The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. +%%% +%%%For the sake of example, let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ to be +%%%identical from the perspective of the functional~group. +%%%That is to say, the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes +%%%occur, is going to be the same. +%%%For example, in our CD player example, this could mean the common symptom `no\_sound'. +%%%No matter which component failure modes, or combinations thereof cause the problem, +%%%the failure symptom is the same. +%%%It may be of interest to the manufacturers and designers of the CD player why it failed, but +%%%as far as we the users are concerned, it has only one symptom, +%%%`no\_sound'! +%%%We can thus group these component failure modes into a common symptom, $SP1$, thus +%%%$ SP1 = \{fgfm_2, fgfm_4, fgfm_5\}$. +%%%% These can then be joined to form a spider. +%%%Likewise +%%%let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. +%%%Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}. +%%% +%%% +%%%We have now in $SP1$, $SP2$ and $fgfm_6$ as the three ways in which this functional~group can fail. +%%%In other words we have derived failure modes for this functional~group. +%%%We can place these in a set of symptoms, $SP$. +%%%% +%%%$$ SP = \{ SP1, SP2, fgfm_6 \} $$ +%%%% +%%%% +%%%These three symptoms can be considered the set of failure modes for the functional~group, and +%%%we can treat it as though it were a {\em black box} +%%%or a {\em component} to be used in higher level designs. +%%%% +%%%The next stage of the process could be applied automatically. +%%%Each common symptom becomes a failure mode of +%%%a newly created derived component. Let $DC$ be the newly derived component. +%%%This is assigned the failure modes that were derived from the functional~group. +%%%We can thus apply the function $FM$ on this newly derived component thus: +%%% +%%%$$ FM(DC) = \{ SP1, SP2, fgfm_6 \} $$ +%%% +%%%Note that $fgfm_6$, while %being a failure mode has +%%%not being grouped as a common symptom +%%%has \textbf{not dissappeared from the analysis process}. +%%%Were the designer to have overlooked this test case, it would appear in the derived component. +%%%This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! +%%%The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). +%%% +%%% +%%%\subsection{Defining the analysis process as a function} +%%% +%%%It is useful to define this analysis process as a function. +%%%Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now +%%%write +%%% +%%%$$ +%%%\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent +%%%$$ +%%%% +%%%%\begin{equation} +%%%% \bowtie(FG_{cfm}) = DC +%%%%\end{equation} +%%%% +%%%%or applying the function $FM$ to obtain the $FG_{cfm}$ set +%%%% +%%%Where DC is a derived component, and FG is a functional group: +%%% +%%%\begin{equation} +%%% \bowtie(FM(FG)) = DC +%%%\end{equation} +%%% +%%% +%%%%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} +%%% +%%%% \begin{figure}[h+] +%%%% \centering +%%%% \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg} +%%%% % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 +%%%% \label{fig:gensubsys3} +%%%% \caption{Deriving a new diagram} +%%% +%%% +%%%This sub-system or derived~component $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 derived~components to build a +%%%hierarchical +%%%fault~mode +%%%model. +%%% +%%% +%%% +%%% +%%% diff --git a/symptom_ex_process/topbot.tex b/symptom_ex_process/topbot.tex index 076d86e..ecef0de 100644 --- a/symptom_ex_process/topbot.tex +++ b/symptom_ex_process/topbot.tex @@ -66,7 +66,7 @@ of the components. \subsection{Systems, functional groups, sub-systems and failure modes} -It is helpful here to define some terms, `system', `functional~group', `component', `base~component' and `derived~component/sub-system'. +It is helpful here to define some terms, `system', `functional~group', `component', `base~component', `symptom' and `derived~component/sub-system'. These are listed in table~\ref{tab:symexdef}. A System, is really any coherent entity that would be sold as a product. % safety critical product. @@ -156,6 +156,8 @@ Failure mode & A way in which a System, \\ Functional Group & A collection of sub-systems and/or \\ & components that interact to \\ & perform a specific function \\ \hline +Symptom & A failure mode of a functional group, caused by \\ + & a combination of its component failure modes \\ \hline Base Component & Any bought in component, which \\ & hopefully has a known set of failure modes \\ \hline \hline