From 35a08f62e8bc86f2ceda10262c7a9198cfae264a Mon Sep 17 00:00:00 2001 From: Robin Date: Sun, 1 Aug 2010 16:41:15 +0100 Subject: [PATCH] after talk with Andrew Fish 30JUL2010 --- symptom_ex_process/algorithm.tex | 145 ++++++++++++++++++++++--------- symptom_ex_process/fmmd.tex | 2 +- symptom_ex_process/process.tex | 28 +++--- symptom_ex_process/topbot.tex | 12 +-- 4 files changed, 128 insertions(+), 59 deletions(-) diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex index a2f5f1d..3dc399b 100644 --- a/symptom_ex_process/algorithm.tex +++ b/symptom_ex_process/algorithm.tex @@ -18,34 +18,62 @@ 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. +We can assign an attribute of abstraction level to +components $\alpha$, where $\alpha$ is a natural number, ($\alpha \in \mathcal{N}$). +For a base component let the abstraction level be zero. +If we apply the symptom abstraction process $\bowtie$ +the reulting derived~component will have an $\alpha$ value +one higher that the highest $\alpha$ value of any of the components +in the functional group used to derive it. +Thus a derived component sourced from base components +will have an $\alpha$ value of 1. % -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. +%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. % -$DC$ can be used as a system building block at a higher -level of fault abstraction. Because derived components -are collected to form functional groups, a converging hierarchy is +%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. +% +With a derived component $DC$ having an abstraction level +attribute $\alpha$ we can use this to track the +level of fault abstraction through a hierarchy. Because base and derived components +are collected to form functional groups, a 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. +%\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group} +% \IF{$c.\alpha > \alpha_{max}$} +% $\alpha_{max} = c.\alpha$ +% \ENDIF +%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$} +%\ENDFOR + + +The algorithm, representing the function $\bowtie$, has been broken down into five consecutive stages. 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. This function returns a flat set of failure modes $F$. +From the earlier definition of the function `FM': -$$ FM: \mathcal{FG} \mapsto \mathcal{F}$$ +The function $FM$ applied to a component returns the failure modes for that component. + +The function $FM$ takes a flat set components $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$. + +$$ FM: \mathcal{FG} \rightarrow \mathcal{F}$$ + + +%Let $FG$ be the set of components in the functional group under analysis, and $c$ +%be components that are members of it. This function returns a flat set of failure modes $F$. +given by +$$FM(FG) = F$$ %% %% Algorithm 1 %% @@ -54,31 +82,33 @@ $$ FM: \mathcal{FG} \mapsto \mathcal{F}$$ ~\label{alg:sympabs1} \caption{FM( $FG$ )} \label{alg:sympabs11} \begin{algorithmic}[1] -\REQUIRE {FG is a set of components} +\REQUIRE {FG is a set of components (a functional~group)} \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$ } +\FORALL { $c \in FG $ } +\REQUIRE{ Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; such \; that\; FM(c) \neq \emptyset$ } +\ENDFOR \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 \RETURN { $F$ } %\hline - +% \end{algorithmic} \end{algorithm} -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 +Algorthim \ref{alg:sympabs11} has taken a functional~group $FG$ and returned a set of failure~modes $F=FM(FG)$ +(given that each component has a known set of failure~modes). +The next task is to formulate `test cases'. These are a collection of combinations of these failure~modes and will be used in the analysis stages. - + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \clearpage \subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases} @@ -86,10 +116,14 @@ 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$. +Let $TC$ be the set of test cases associated with the functional group $FG$. $$ DTC: \mathcal{F} \mapsto \mathcal{TC} $$ +given by + +$$ DTC(F) = TC $$ + %% %% Algorithm 2 %% @@ -109,25 +143,37 @@ $$ DTC: \mathcal{F} \mapsto \mathcal{TC} $$ \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} + %\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))$} + \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 ) $} + %\ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $} + \ENSURE { $\forall j1,j2 \in J \; such\; that\; tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 $} \COMMENT { Test cases must be unique } \ENDFOR - + \IF{Single fault checking} \STATE { let $f$ represet a component failure mode } - \ENSURE { That all failure modes are represented in at least one test case } - \ENSURE { $ \forall f | (f \in F)) \wedge (f \in \bigcup TC) $ } + %\ENSURE { That all failure modes are represented in at least one test case } + \ENSURE { $ \forall f \;such\;that\; (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} + \ENDIF + \IF{Double fault checking} + \STATE { let $f1,f2$ represet a component failure modes } + %\ENSURE { That all failure modes are represented in at least one test case } + \ENSURE { $ \forall f1,f2 \;where\; \not(f1,f2) \in c\;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ } + \COMMENT { This corresponds to checking that at least each possible double failure mode is considered at + least once in the analysis; more rigorous cardinality constraint + checks may be required for some safety standards. Not if both failure modes + in the check are sourced from the same component $c$ the test case is impossible + under unitary state failure mode conditions} + \ENDIF \RETURN $TC$ % some european standards @@ -144,13 +190,17 @@ The next stage is to analyse the effect of each test case on the functional grou + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \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}$). +Let $R$ be a set of test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$). $$ATC: \mathcal{TC} \mapsto \mathcal{R} $$ @@ -163,7 +213,8 @@ $$ATC: \mathcal{TC} \mapsto \mathcal{R} $$ \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} + %\STATE { $ rc_j \in R $ } \COMMENT{Add $rc_j$ to the set R} + \STATE{ $ R := R \cap rc_j $ } \COMMENT{Add $rc_j$ to the set R} \ENDFOR \RETURN $R$ @@ -174,6 +225,9 @@ $$ATC: \mathcal{TC} \mapsto \mathcal{R} $$ Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \clearpage \subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms} %% @@ -210,8 +264,7 @@ $$FCS: \mathcal{R} \mapsto \mathcal{SP} $$ 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 ) $} - \REQUIRE {$ \forall a \in sp_l | \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$} - + \ENSURE {$ \forall a \in sp_l \;such\;that\; \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 @@ -231,6 +284,9 @@ We now have a set $SP$ of the symptoms of failure. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \clearpage \subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component} %% @@ -252,7 +308,9 @@ $$ CDC: \mathcal{SP} \mapsto \mathcal{DC} $$ \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} + %\STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes} + \STATE { $DC := DC \cap f_l$ } \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes} + \ENDFOR \RETURN DC %\hline @@ -276,11 +334,11 @@ $$ \bowtie: \mathcal{FG} \mapsto \mathcal{DC} $$ \begin{algorithmic}[1] - \STATE {F = FM (FG)} - \STATE {TC = DTC (F)} - \STATE {R = ATC (TC)} - \STATE {SP = FCS (R)} - \STATE {DC = CDC (SP)} + \STATE {F = FM (FG)} \COMMENT{ collect all the failure modes from the from the components in the functional~group } + \STATE {TC = DTC (F)} \COMMENT{ determine all test cases to apply to the functional group } + \STATE {R = ATC (TC)} \COMMENT{ analyse the test cases, for failure mode behaviour of the functional~group } + \STATE {SP = FCS (R)} \COMMENT{ find common symptoms of failure for the functional group } + \STATE {DC = CDC (SP)} \COMMENT{ create a derived component } \RETURN $DC$ @@ -299,7 +357,8 @@ from the bottom-up. 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 +%This is seen by casual observation of real life Systems. NEED A GOOD REF HERE +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 diff --git a/symptom_ex_process/fmmd.tex b/symptom_ex_process/fmmd.tex index 748445b..5f63710 100644 --- a/symptom_ex_process/fmmd.tex +++ b/symptom_ex_process/fmmd.tex @@ -2,7 +2,7 @@ % Describe FMMD -\section{Background: FMMD outline} +\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. diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index 66e79a4..3a46670 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -57,16 +57,17 @@ It is possible here for an automated system to flag unhandled failure modes. 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 Choose a set of components to form a functional group. +% \item Obtain the list of components in the functional group + \item Collect the failure modes of each component into a flat set. + \item Choose all single instances and selected combinations of the failure modes to +form `test cases'. % \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 Using the `test cases' determine their effects on the failure~mode behaviour of the functional group. + \item Collect common~symptoms. i.e. determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}. + \item The common~symptoms are now the fault mode behaviour of the functional~group. \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} @@ -94,7 +95,7 @@ and let the set of all possible failure modes be $\mathcal{F}$. We can define a function $FM$ \begin{equation} -\mathcal{FM} : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} +{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): @@ -205,9 +206,9 @@ 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, SP3 \} $$ +$$ FM(DC) = \{ SP1, SP2, SP3 \} $$ -Note that $g_6$, while %being a failure mode has +Note that $g_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 as a failure mode of the derived component. @@ -217,6 +218,7 @@ The process must not allow failure modes to be ignored or forgotten (see project 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} @@ -259,3 +261,9 @@ hierarchical fault~mode model. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % diff --git a/symptom_ex_process/topbot.tex b/symptom_ex_process/topbot.tex index 0f56f8d..8d78816 100644 --- a/symptom_ex_process/topbot.tex +++ b/symptom_ex_process/topbot.tex @@ -1,5 +1,5 @@ -\section{Fault Finding and Failure Mode Analysis} +\section{Fault Finding \\ and Failure Mode Analysis} \subsection{Static Analysis} @@ -21,7 +21,7 @@ can be derived. FMMD can model electrical, mechanical and software using a common notation, and can thus model an entire electro mechanical software controlled system. -\subsection{Top Down or natural trouble shooting} +\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 @@ -173,7 +173,8 @@ System & A product designed to \\ 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 + & from derived components \\ + & Constraint: This object must have a defined set of failure~modes \\ \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 \\ @@ -181,8 +182,9 @@ Functional Group & A collection of sub-systems and/or \\ & 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 +Base Component & Any bought in component, or \\ + & lowest level module/or part \\ + & Constraint: This object must have a defined set of failure~modes \\ \hline \hline \end{tabular} \caption{Symptom Extraction Definitions}