From df0b9de2db408cbf5f9a52ab9e25ebf10c58fcdd Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Tue, 21 Sep 2010 14:34:23 +0100 Subject: [PATCH] Lunch time edit 21SEP2010, ready for JMC to proof read --- .../component_failure_modes_definition.tex | 39 +++++++++++++------ fmmd_concept/Makefile | 3 ++ fmmd_concept/paper.tex | 2 +- symptom_ex_process/algorithm.tex | 2 +- symptom_ex_process/introduction.tex | 6 +-- symptom_ex_process/process.tex | 19 ++++----- symptom_ex_process/sys_abs.tex | 17 ++++---- symptom_ex_process/topbot.tex | 4 +- 8 files changed, 57 insertions(+), 35 deletions(-) diff --git a/component_failure_modes_definition/component_failure_modes_definition.tex b/component_failure_modes_definition/component_failure_modes_definition.tex index 01a6873..e68097f 100644 --- a/component_failure_modes_definition/component_failure_modes_definition.tex +++ b/component_failure_modes_definition/component_failure_modes_definition.tex @@ -149,24 +149,31 @@ especially where they are non obvious top-level faults. In order to analyse from the bottom-up, we need to take small groups of components from the parts~list that naturally -work together to perform a simple function; -the components to include in a {\fg} are chosen by a human, the analyst. +work together to perform a simple function. +The components to include in a {\fg} are chosen by a human, the analyst. %We can represent the `Functional~Group' as a class. When we have a `{\fg}' we can look at the components it contains, and from this determine the failure modes of all the components that belong to it. % % and determine a failure mode model for that group. -The `{\fg}' as used by the analyst is a collection of component failures modes. +% +% expand 21sep2010 +%The `{\fg}' as used by the analyst is a collection of component failures modes. +The analysts interest is the ways in which the components within the {\fg} +can fail. All the failure modes of all the components with an {\fg} are collected +into a flat set of failure modes. +% Each of these failure modes, and optionally combinations of them, are +formed into `test cases' which are analysed for their effect on the failure mode behaviour of the `{\fg}'. % -From this we can determine a new set of failure modes, the failure modes of the +Once we have the failure mode behaviour of the {\fg}, we can determine a new set of failure modes, the derived failure modes of the `{\fg}'. % Or in other words we can determine how the `{\fg}' can fail. We can now consider the {\fg} as a sort of super component -with a known set of failure modes. +with its own set of failure modes. \subsection{From functional group to newly derived component} @@ -198,8 +205,8 @@ these `derived~failure~modes'. We thus have a `new' component, or system building block, but with a known and traceable fault behaviour. -The UML representation shows a `functional group' having a one to one relationship with a derived~component. -We can represent this using a UML diagram in figure \ref{fig:cfg}. +The UML representation shows a `functional group' having a one to one relationship with a derived~component, +which we represent in the UML diagram in figure \ref{fig:cfg}. The symbol $\bowtie$ is used to indicate the analysis process that takes a functional group and converts it into a new component. @@ -317,7 +324,7 @@ within one package. This property, failure modes being mutually exclusive, is termed `unitary state failure modes' in this study. This corresponds to the `mutually exclusive' definition in -probability theory\cite{probstat}. +probability theory \cite{probstat}. \begin{definition} @@ -389,7 +396,7 @@ with several modules that could all fail simultaneously, a process of reduction into smaller theoretical components will have to be made \footnote{A modern microcontroller will typically have several modules, which are configurged to operate on pre-assigned pins on the device. Typically voltage inputs (\adcten / \adctw), digital input and outputs, -PWM (pulse width modulation), UARTs and other modules will be found on simple cheap microcontrollers\cite{pic18f2523}}. +PWM (pulse width modulation), UARTs and other modules will be found on simple cheap microcontrollers \cite{pic18f2523}}. For instance the voltage reading functions which consist of an ADC multiplexer and ADC can be considered to be components inside the microcontroller package. @@ -409,7 +416,7 @@ failure modes in isolation, but cases where more then one failure mode may occur simultaneously. Note that the `unitary state' conditions apply to failure modes within a component. The scenarios presented here are where two or more components fail simultaneously. -It is an implied requirement of EN298\cite{en298} for instance to +It is an implied requirement of EN298 \cite{en298} for instance to consider double simultaneous faults\footnote{This is under the conditions of LOCKOUT in an industrial burner controller that has detected one fault already. However, from the perspective of static failure mode analysis, this amounts @@ -452,7 +459,7 @@ $$ \mathcal{P}_{1} S = \{ \{a\},\{b\},\{c\} \} $$ A $k$ combination is a subset with $k$ elements. The number of $k$ combinations (each of size $k$) from a set $S$ -with $n$ elements (size $n$) is the binomial coefficient\cite{probstat} shown in equation \ref{bico}. +with $n$ elements (size $n$) is the binomial coefficient \cite{probstat} shown in equation \ref{bico}. \begin{equation} C^n_k = {n \choose k} = \frac{n!}{k!(n-k)!} @@ -648,6 +655,14 @@ $$ F = \Omega(C) \backslash \{OK\} $$ The $OK$ statistical case is the largest in probability, and is therefore of interest when analysing systems from a statistical perspective. This is of interest for the application of conditional probability calculations -such as Bayes theorem. +such as Bayes theorem \cite{probstat}. + + +%%- +%%- Need a complete and more complicated UML diagram here +%%- the other parts were just fragments to illustrate points +%%- +%%- + \vspace{40pt} diff --git a/fmmd_concept/Makefile b/fmmd_concept/Makefile index 884439a..054af3e 100644 --- a/fmmd_concept/Makefile +++ b/fmmd_concept/Makefile @@ -13,3 +13,6 @@ paper: paper.tex fmmd_concept_paper.tex # fmmd_concept_paper.tex: fmmd_concept.tex paper.tex cat fmmd_concept.tex | sed 's/fmmd_concept\///' > fmmd_concept_paper.tex + +bib: + bibtex paper diff --git a/fmmd_concept/paper.tex b/fmmd_concept/paper.tex index 2d9d85c..d64bec6 100644 --- a/fmmd_concept/paper.tex +++ b/fmmd_concept/paper.tex @@ -25,7 +25,7 @@ \input{fmmd_concept_paper} \bibliographystyle{plain} -\bibliography{vmgbibliography,mybib} +\bibliography{../vmgbibliography,../mybib} \today \end{document} diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex index a06c74b..7ea1e37 100644 --- a/symptom_ex_process/algorithm.tex +++ b/symptom_ex_process/algorithm.tex @@ -146,7 +146,7 @@ $$ dtc(F) = TC $$ \caption{Determine Test Cases: dtc: (F) } \label{alg22} \begin{algorithmic}[1] - \REQUIRE {F is a flat set of failure modes } + \REQUIRE {F is a non empty flat set of failure modes } \STATE { All test cases are chosen by the investigating engineer(s). Typically all single component failures are investigated diff --git a/symptom_ex_process/introduction.tex b/symptom_ex_process/introduction.tex index 1498932..db53606 100644 --- a/symptom_ex_process/introduction.tex +++ b/symptom_ex_process/introduction.tex @@ -28,9 +28,9 @@ 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}. +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. } diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index de16042..5cd2993 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -32,9 +32,8 @@ The goal of the process is to produce a set of failure modes from the perspectiv \paragraph{Symptom Identification} When all `test~cases' have been analysed, a second phase can be actioned. % 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. +This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but of the {\fg}/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 @@ -56,7 +55,9 @@ from the components in a functional~group have been handled\footnote{Software ca failure modes have been included in at least one test case, and modelled individually. For Double Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well}. 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. +It is possible here for an automated system to flag unhandled failure modes, +which solves the main failing of top~down methodologies \cite{topdownmiss}, that of not +guaranteeing to model all component failure modes. \ref{requirement at the start} @@ -137,7 +138,7 @@ where $a_n,b_n,c_n$ are component failure modes. \paragraph{Finding all failure modes within the functional group} -For fmMD failure mode analysis, we need to consider the failure modes +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 (where F is the set of all failure modes for all components in the functional group) thus: @@ -188,8 +189,8 @@ $c\_2$ & $fs\_7$ & $g_{7}$ & SP2\\ \hline %\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. +As we are only looking at single fault possibilities for this example each test case +is represented by one failure mode. Chosen combinations of 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 ($g$'s). @@ -237,7 +238,7 @@ Note that $g_6$ 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. i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ would have been $ \{ SP1, SP2, g_6 \}$. Because the process can be computerised, we can easily flag symptoms that have not been -included a derived component. +included as failure modes in a {\dc}. % Aw boring ! no jokes ? % 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!}! % @@ -275,7 +276,7 @@ This generalises the function $\bowtie$ and allows us to build hierarchical failure mode models. Where a {\fg} is composed of derived components, for sake of example -Where $DC_1, DC_2, DC_3 $ are {\dc}'s and $DCFM$ is a set of failure modes thus +where $DC_1, DC_2, DC_3 $ are {\dc}'s and $DCFM$ is a set of failure modes thus $FG = \{ DC_1, DC_2, DC_3 \}$ and $DCFM = FM(FG)$ We can apply the symptom abstraction process $\bowtie$ diff --git a/symptom_ex_process/sys_abs.tex b/symptom_ex_process/sys_abs.tex index 0fa6471..d1e02ff 100644 --- a/symptom_ex_process/sys_abs.tex +++ b/symptom_ex_process/sys_abs.tex @@ -29,10 +29,11 @@ The goal of the process is to produce a set of failure modes from the perspectiv \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. +This looks at the results of the `test~cases' as failure modes from the perspective of +of the {\fg}/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' (or +in other words the sub-system/{\fg} will fail in the same way for a variety of causes. 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, @@ -43,10 +44,12 @@ 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. +We can now consider the functional~group as a component and the 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} +It is possible at this stage for an automated system to flag unhandled failure modes, +which fulfills the wish list in chapter \ref{requirement at the start}, removing +the main drawback with top-down methodologies, that of missing component failure mode +in the model \cite{nancy_crit_fta_top_down}. diff --git a/symptom_ex_process/topbot.tex b/symptom_ex_process/topbot.tex index a1c8d9d..539684d 100644 --- a/symptom_ex_process/topbot.tex +++ b/symptom_ex_process/topbot.tex @@ -6,7 +6,7 @@ In the field of safety critical engineering; to comply with European Law a product must be certified under the appropriate `EN' standard. Typically environmental stress, EMC, electrical stressing, endurance tests, -software~inspections and project~management quality reviews are applied\cite{sccs}. +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. @@ -37,7 +37,7 @@ 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}. +Top down formal fault isolation/finding techniques for electronics are described in \cite{maikowski}. %% %% to fool the graphics insertion to make it compatible