robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

After JMC proof read of paper compiled version

Browse Source
This commit is contained in:
Robin Clark 2010-10-27 22:11:34 +01:00
parent 528413b3a6
commit 8e358419b0
5 changed files with 52 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
symptom_ex_process/algorithm.tex
View File

@ -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.
}
{

8
symptom_ex_process/fmmd.tex
View File

@ -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).

33
symptom_ex_process/process.tex
View File

@ -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

13
symptom_ex_process/sys_abs.tex
View File

@ -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

20
symptom_ex_process/topbot.tex
View File

@ -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