From 8e358419b054b8d17e3531c434a13b7c9b97775a Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Wed, 27 Oct 2010 22:11:34 +0100 Subject: [PATCH] After JMC proof read of paper compiled version --- symptom_ex_process/algorithm.tex | 10 ++++++++-- symptom_ex_process/fmmd.tex | 8 +++++--- symptom_ex_process/process.tex | 33 ++++++++++++++++---------------- symptom_ex_process/sys_abs.tex | 13 +++++++++++-- symptom_ex_process/topbot.tex | 20 +++++++++++-------- 5 files changed, 52 insertions(+), 32 deletions(-) diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex index cf8d833..0a09a1f 100644 --- a/symptom_ex_process/algorithm.tex +++ b/symptom_ex_process/algorithm.tex @@ -185,7 +185,13 @@ $$ dtc(F) = TC $$ The function \textbf{chosen} means that the failure modes for a particular test case have been chosen by a human operator and are additional to those chosen by the automated process (i.e they are special case test cases involving multiple failure modes) The function \textbf{unitarystate} means that all test cases can have no pairs of failure modes sourced from the component. +\ifthenelse {\boolean{paper}} +{ +%% perhaps ref a paper here XXXXX +} +{ This is discussed in section \ref{unitarystate}. +} %% %% Algorithm 2 %% @@ -368,7 +374,7 @@ These results are the failure modes of the functional group. %% %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. -This stage collects results into `Symptom' sets. +This stage collects results into `symptom' sets. Each result from the preceding stage is examined and collected into common symptom sets. That is to say, each result in a symptom set, from the perspective of the functional group @@ -438,7 +444,7 @@ Component failure modes must be mutually exclusive. That is to say only one specific failure mode may be active at any time. This condition/property has been termed unitary state failure mode. Ensuring that no result belongs to more than -one Symptom set, enforces this, for the derived +one symptom set, enforces this, for the derived component created in the next stage. } { diff --git a/symptom_ex_process/fmmd.tex b/symptom_ex_process/fmmd.tex index d443403..cde6fc6 100644 --- a/symptom_ex_process/fmmd.tex +++ b/symptom_ex_process/fmmd.tex @@ -5,14 +5,16 @@ \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. +FMMD modelling methodology. FMMD builds a hierarchy of failure mode behaviours from the bottom up. To start with collections of base components are chosen to form functional~groups, which are analysed w.r.t. its failure mode behaviour. These functional groups can then be treated as components in their own right. -These higher level, or derived compoenents, +% +These higher level, or derived components, can be used to build derived components at higher levels of abstraction, and ultimately are used to build an FMMD fault model hierarchy of the system modelled. +% Intermediate FMMD structures may be re-used in other designs, and re-used in repeated sections of a design (consider a system -with several safety critical digital inputs for instance). +with several safety critical digital inputs, for instance). diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index 2ac6d1a..e32d6fc 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -29,21 +29,20 @@ The goal of the process is to produce a set of failure modes from the perspectiv \paragraph{Environmental Conditions or Applied States} -Each test case must be considered in the light of any applied states or -environmental conditions that it may be exposed to. - -A {\fg} may, in the case of an electronic circuit have -applied states. For instance test modes, shutdown or lockout modes etc. -which are inputs to the circuit. -In this case each test case from the {\fg} must be analysed with -respect to all these states. - -A mechanical device may be required to work in different -temperature or pressure ranges for instance and its failure mode behaviour may -change due to enviromental factors. - - +Each test case must be considered in the for the case of each applied states or +environmental conditions that it may be exposed to. In this way all +failure mode behaviour due to the test case conditions will be examined. +%%- A {\fg} may, in the case of an electronic circuit have +%%- applied states. For instance test modes, shutdown or lockout modes etc. +%%- which are inputs to the circuit. +%%- In this case each test case from the {\fg} must be analysed with +%%- respect to all these states. +%%- +%%- A mechanical device may be required to work in different +%%- temperature or pressure ranges for instance and its failure mode behaviour may +%%- change due to enviromental factors. +%%- \paragraph{Symptom Identification} When all `test~cases' have been analysed, a second phase can be actioned. % applied. @@ -294,8 +293,8 @@ 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 -$FG = \{ DC_1, DC_2, DC_3 \}$ and $DCFM = FM(FG)$ +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$ to the failure mode set $DCFM$. @@ -303,7 +302,7 @@ to the failure mode set $DCFM$. The case where a {\fg} has been created from {\dcs} using function `$\bowtie$' leads us to -{\dc}'s at a higher level of fault abstraction. +{\dc}s at a higher level of fault abstraction. $$ %\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent diff --git a/symptom_ex_process/sys_abs.tex b/symptom_ex_process/sys_abs.tex index 2074c8f..2d6ca8c 100644 --- a/symptom_ex_process/sys_abs.tex +++ b/symptom_ex_process/sys_abs.tex @@ -34,19 +34,28 @@ The goal of the process is to produce a set of failure modes from the perspectiv Each test case must be considered in the light of any applied states or environmental conditions that it may be exposed to. +\paragraph{Electronics} A {\fg} may, in the case of an electronic circuit have applied states. For instance test modes, shutdown or lockout modes etc. which are inputs to the circuit. In this case each test case from the {\fg} must be analysed with respect to all these states. +\paragraph{Mechanical} A mechanical device may be required to work in different temperature or pressure ranges for instance and its failure mode behaviour may change due to enviromental factors. +\paragraph{Software} +A software function may have an applied state, where it must modify +its general behaviour. +For instance some states in an embedded real time system +may require special error or emergency handling behaviour. +This could be in the form of global variable which could indicate a system condition +such as NORMAL\_OPERATION, GRACEFUL\_DEGRADATION \cite{en61508}[SECTION XX] LOCKOUT or SHUTDOWN +for instance. - -\paragraph{Symptom Identification} +\subsection{Symptom Identification / collection} When all `test~cases' have been analysed, a second phase is applied. % This looks at the results of the `test~cases' as failure modes from the perspective of diff --git a/symptom_ex_process/topbot.tex b/symptom_ex_process/topbot.tex index 801592d..2928c2a 100644 --- a/symptom_ex_process/topbot.tex +++ b/symptom_ex_process/topbot.tex @@ -10,16 +10,18 @@ software~inspections and project~management quality reviews are applied \cite{sc Static testing is also applied. This is theoretical analysis of the design of the product from the safety perspective. +% Three main methodologies are currently used, Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis). -The FMMD process is a static modelling methodology, aimed primarily as design verification for +The FMMD process is a static modelling methodology, aimed primarily for design verification of safety critical systems. +% However, FMMD also provides the mathematical framework to assist in the production of the three traditional methods of static analysis. From the model created by the FMMD methodology, statistical, FTA and FMEA models 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. +and can thus model an entire electro-mechanical software controlled system. \subsection{Top Down or \\ natural trouble shooting} It is interesting here to look at the `natural' trouble shooting process. @@ -69,7 +71,7 @@ The term sub-system will be used alongside both {\fg} and {\dc} where necessary. A top down fault analysis system will take a system and divide it into several sub-systems, and determine the safety dependencies of the System on those sub-systems. In the case of large complicated -Systems, the sub-systems themselves may be broken down into simpler sub-systems. +systems, the sub-systems themselves may be broken down into simpler sub-systems. A top down hierarchy is shown in figure \ref{fig:tdh}. \subsection{FMMD - Bottom~up Analysis} @@ -78,8 +80,10 @@ 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. +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 of the system can be built. By working from the bottom up, we can trace all possible sources @@ -108,10 +112,10 @@ of the components. It is helpful here to define the terms, `system', `functional~group', `component', `base~component', `symptom' and `derived~component/sub-system'. These are listed in table~\ref{tab:symexdef}. -A System, is any coherent entity that would be sold as a product. % safety critical product. +A system, is 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': +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 @@ -187,8 +191,8 @@ Sub-system & A part of a system, \\ & derived~components may by derived \\ & 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 +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