Mums proof reading from the weekend
This commit is contained in:
parent
459d924cae
commit
3e3ec9a563
@ -32,11 +32,11 @@ Mathematical constraints and definitions are made using set theory.
|
||||
\section{Introduction}
|
||||
This chapter describes the data types and concepts for the Failure Mode Modular De-composition (FMMD) method.
|
||||
When analysing a safety critical system using
|
||||
this technique, we need clearly defined failure modes for
|
||||
this methodology, we need clearly defined failure modes for
|
||||
all the components that are used to model the system.
|
||||
In our model we have a constraint that
|
||||
In our model, we have a constraint that
|
||||
the component failure modes must be mutually exclusive.
|
||||
When this constraint is complied with we can use the FMMD method to
|
||||
When this constraint is complied with, we can use the FMMD method to
|
||||
build hierarchical bottom-up models of failure mode behaviour.
|
||||
%This and the definition of a component are
|
||||
%described in this chapter.
|
||||
@ -62,8 +62,8 @@ build hierarchical bottom-up models of failure mode behaviour.
|
||||
\label{fig:component}
|
||||
\end{figure}
|
||||
|
||||
Let us first define a component. This is anything which we use to build a
|
||||
product or system with.
|
||||
Let us first define a component. This is anything with which we use to build a
|
||||
product or system.
|
||||
It could be something quite complicated
|
||||
like an integrated microcontroller, or quite simple like the humble resistor.
|
||||
We can define a
|
||||
@ -136,7 +136,7 @@ to see how they could be caused. Some apply statistical techniques to
|
||||
determine the likelihood of component failures
|
||||
causing specific system level errors. For example, Bayes theorem \ref{bayes}, the relation between a conditional probability and its inverse,
|
||||
can be applied to specific failure modes in components and the probability of them causing given system level errors.
|
||||
Another top down technique is to apply cost benefit analysis
|
||||
Another top down methodology is to apply cost benefit analysis
|
||||
to determine which faults are the highest priority to fix\cite{bfmea}.
|
||||
The aim of FMMD analysis is to produce complete failure
|
||||
models of safety critical systems from the bottom-up,
|
||||
@ -198,8 +198,9 @@ and creates a new {\dc} from it.
|
||||
%must consider all the failure modes of the components in the functional
|
||||
%group.
|
||||
The newly created {\dc} requires a set of failure modes of its own.
|
||||
These failure modes are the failure mode behaviour of the {\fg} that it was derived from.
|
||||
Because these new failure modes were derived from a {\fg} we can call
|
||||
These failure modes are the failure mode behaviour of the {\fg} from which it was derived.
|
||||
%
|
||||
Because these new failure modes were derived from a {\fg}, we can call
|
||||
these `derived~failure~modes'.
|
||||
%It then creates a new derived~component object, and associates it to this new set of derived~failure~modes.
|
||||
We thus have a `new' component, or system building block, but with a known and traceable
|
||||
@ -309,8 +310,8 @@ fm : \mathcal{FG} \rightarrow \mathcal{F}
|
||||
|
||||
\paragraph{Design Descision/Constraint}
|
||||
An important factor in defining a set of failure modes is that they
|
||||
should be represent the failure modes as simply and minimally as possible.
|
||||
It should not be possible, for instance for
|
||||
should represent the failure modes as simply and minimally as possible.
|
||||
It should not be possible, for instance, for
|
||||
a component to have two or more failure modes active at once.
|
||||
Were this to be the case, we would have to consider additional combinations of
|
||||
failure modes within the component.
|
||||
@ -348,7 +349,7 @@ An example of a component with an obvious set of ``unitary~state'' failure mode
|
||||
Electrical resistors can fail by going OPEN or SHORTED.
|
||||
|
||||
For a given resistor R we can apply the
|
||||
the function $fm$ to find its set of failure modes thus $ fm(R) = \{R_{SHORTED}, R_{OPEN}\} $.
|
||||
function $fm$ to find its set of failure modes thus $ fm(R) = \{R_{SHORTED}, R_{OPEN}\} $.
|
||||
A resistor cannot fail with both conditions open and short active at the same time! The conditions
|
||||
OPEN and SHORT are thus mutually exclusive.
|
||||
Because of this, the failure mode set $F=fm(R)$ is `unitary~state'.
|
||||
@ -356,13 +357,13 @@ Because of this, the failure mode set $F=fm(R)$ is `unitary~state'.
|
||||
|
||||
Thus because both fault modes cannot be active at the same time, the intersection of $ R_{SHORTED} $ and $ R_{OPEN} $ cannot exist.
|
||||
|
||||
The intersection of these is therefore the empty set, $$ R_{SHORTED} \cap R_{OPEN} = \emptyset $$,
|
||||
The intersection of these is therefore the empty set, $ R_{SHORTED} \cap R_{OPEN} = \emptyset $,
|
||||
therefore
|
||||
$ fm(R) \in \mathcal{U} $.
|
||||
|
||||
|
||||
|
||||
We can make this a general case by taking a set $F$ (where $f_1, f_2 \in F$) representing a collection
|
||||
We can make this a general case by taking a set $F$ (with $f_1, f_2 \in F$) representing a collection
|
||||
of component failure modes.
|
||||
We can define a boolean function {\ensuremath{\mathcal{ACTIVE}}} that returns
|
||||
whether a fault mode is active (true) or dormant (false).
|
||||
@ -394,7 +395,7 @@ All components must have unitary state failure modes to be used with the FMMD me
|
||||
Where a complex component is used, for instance a microcontroller
|
||||
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
|
||||
\footnote{A modern microcontroller will typically have several modules, which are configured 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}}.
|
||||
For instance the voltage reading functions which consist
|
||||
|
@ -164,7 +164,7 @@ As the relationships {\em enclosure} and {\em pair-wise intersection} are mutual
|
||||
and {\em enclosure} is transitive and {\em pair-wise intersection} is not, we can represent
|
||||
an {\em enclosure} relationship as a directed vertice and
|
||||
{\pic} as non-directed on the same graph.
|
||||
Figures \ref{fig:eulerg1} and \ref{fig:eulerg_enc} show euler diagrams with corresponding
|
||||
Figures \ref{fig:eulerg1} and \ref{fig:eulerg_enc} show Euler diagrams with corresponding
|
||||
graphs. The next section will introduce the concept of a {\pic}
|
||||
and will present graphs where both enclosure and pair-wise
|
||||
intersection are represented on the same graph.
|
||||
@ -310,7 +310,7 @@ that are not, or would not become members of the {\pic} $P$.
|
||||
\end{definition}
|
||||
That is to say, the the number of zones within a {\pic} is not affected by changes in the diagram
|
||||
that do not alter the {\pic}.
|
||||
This allows us to analyses {\pic}s separately, thus reducing the $2^N$ overhead of analysing an Euler diagram for available zones.
|
||||
This allows us to analyse {\pic}s separately, thus reducing the $2^N$ overhead of analysing an Euler diagram for available zones.
|
||||
\pagebreak[3]
|
||||
\subsection{Available Zone Searching}
|
||||
|
||||
|
@ -28,7 +28,7 @@ The Failure Mode Modular De-composition
|
||||
(FMMD) methodology presented here provides a more detailed and analytical
|
||||
modelling system from which
|
||||
the data models from FTA, FMEA and the statistical approach can be
|
||||
derived from.
|
||||
derived.
|
||||
It also applies analysis stages to the failure mode analysis process
|
||||
ensuring that all component failure modes must be considered in the model.
|
||||
|
||||
@ -40,7 +40,7 @@ paper
|
||||
{
|
||||
chapter
|
||||
}
|
||||
presents a bottom up modular technique, a variant of FMEA, where instead of looking
|
||||
presents a bottom up modular methodology, a extension and refinement of FMEA, where instead of looking
|
||||
at individual component failure modes and deciding on their impact on the SYSTEM
|
||||
it uses the component failure modes, to build modules or derived components.
|
||||
This methodology has been named Failure Mode Modular De-composition (FMMD)
|
||||
@ -77,8 +77,8 @@ This places a burden of taking individual component failure modes
|
||||
and trying to determine what affects this will have at SYSTEM level.
|
||||
Justifications for this methodology are often statistical and Bayes Theorem \cite{probstat}
|
||||
is often cited.
|
||||
This lacks precision, or in order words, determinability prediction accuracy,
|
||||
as often the compoinent failure mode cannt be proven to cause a SYSTEM level failure, only to make it more likely.
|
||||
This lacks precision, or in other words, determinability prediction accuracy,
|
||||
as often the component failure mode cannt be proven to cause a SYSTEM level failure, only to make it more likely.
|
||||
Also, it can miss combinations of failure modes that will cause SYSTEM level errors.
|
||||
|
||||
\subsection { Statistical Analyis }
|
||||
@ -86,16 +86,16 @@ Also, it can miss combinations of failure modes that will cause SYSTEM level err
|
||||
|
||||
This uses MTFF and other statisical models to determine the probability of
|
||||
failures occurring. A component failure mode, given its MTTF
|
||||
the probability oif detecting the fault and its safety safety relevant validation time $\tau$,
|
||||
the probability of detecting the fault and its safety relevant validation time $\tau$,
|
||||
contributes a simple risk factor that is summed
|
||||
in to give a final risk result. Thus a statistical
|
||||
model can be implemented on a spreadsheet, where each component
|
||||
has a calculated risk, and estimated risk importance
|
||||
and these are all summed to give the final asssement figure.
|
||||
and these are all summed to give the final assement figure.
|
||||
|
||||
The Statistical Analysis method is used from two perspectives,
|
||||
Probability of Failure on Demand (PFD), and Probability of Failure
|
||||
in contiuous Operation, Failure in Time (FIT) and measured in failures per billion ($10^9$) hours of operation.
|
||||
in continuous Operation, Failure in Time (FIT) and measured in failures per billion ($10^9$) hours of operation.
|
||||
For instance with the anti-lock system on a automobile braking
|
||||
system, we would be interested in PFD.
|
||||
For a continuously running nuclear powerstation
|
||||
@ -106,7 +106,7 @@ lack of determinability prediction accuracy, as FMEA above.
|
||||
|
||||
By this we may have the MTTF of some critical component failure
|
||||
modes, but we can only guess, in most cases what the safety case outcome
|
||||
will be if it occurrs.
|
||||
will be if it occurs.
|
||||
|
||||
This leads to having components within a SYSTEM partitioned into different
|
||||
safety level zones \cite{en61508}. This is a vague way of determining
|
||||
@ -123,7 +123,7 @@ of the Safety Integrity Levels (SIL) of EN61508 \cite{en61508}.
|
||||
\item All component failure modes must be considered in the model.
|
||||
\item It should be easy to integrate mechanical, electronic and software models.
|
||||
\item It should be re-usable, in that commonly used modules can be re-used in other designs/projects.
|
||||
\item It should have a formal babsis, that is to say it should be able to produce mathematical proofs
|
||||
\item It should have a formal basis, that is to say, it should be able to produce mathematical proofs
|
||||
for its results.
|
||||
\item It should be capable of producing reliability and danger evaluation statistics.
|
||||
\item It should be easy to use.
|
||||
@ -150,11 +150,11 @@ An industrial burner is a nice example of a safety critical system.
|
||||
It has some lethal risks and some environmental.
|
||||
It could, by igniting an explosive mixture, cause an explosion.
|
||||
By burning incorrect proportions of fuel and air, it could be ineffecient and waste
|
||||
resources, or worse could cause poisinous burning (typically carbon monoxide, but also
|
||||
where flame temperature is very high, can produce NOX emmissions)
|
||||
resources, or worse could cause poisonous burning (typically carbon monoxide, but also
|
||||
where flame temperature is very high, can produce NOX emmissions).
|
||||
|
||||
To prevent igniting an explosive mixture, air is pumped though the furnace
|
||||
chanber on start-up, and this is verified with an air pressure switch.
|
||||
chamber on start-up, and this is verified with an air pressure switch.
|
||||
|
||||
|
||||
NEED A DIAGRAM HERE
|
||||
@ -177,7 +177,7 @@ The flame scanner is thus a two resistor voltage divider.
|
||||
\subsection{The Flame Scanner}
|
||||
\subsubsection{Macro FTA perspective}
|
||||
|
||||
SHOW ALL TOP LEVEL FAULTS. EXPLOSION, POISINOUS BURNING CO, POISINOUS BURNING NOX, FAILS TO LIGHT etc
|
||||
SHOW ALL TOP LEVEL FAULTS. EXPLOSION, POISONOUS BURNING CO, POISONOUS BURNING NOX, FAILS TO LIGHT etc
|
||||
|
||||
Follow the explosion tree down to flame scanner fails ON, and OFF
|
||||
|
||||
@ -188,12 +188,12 @@ Each of the resistors is considered critical, in the statistical case, and so th
|
||||
is added inot the DANGEROUS section.
|
||||
|
||||
For FMEA the resistor failures add up to the SYSTEM level, show this is inappropriate
|
||||
and makes several jumps in applied knowledge, thus bayes theorem etc
|
||||
and makes several jumps in applied knowledge, thus Bayes theorem etc
|
||||
|
||||
\subsubsection{Micro FMMD perspective}
|
||||
|
||||
|
||||
Here show how the flame scanner becomes a black box, or component in itsself.
|
||||
Here show how the flame scanner becomes a black box, or component in itself.
|
||||
How it is now available to be integrated into higher level designs.
|
||||
|
||||
%and then an ignition position is checked.
|
||||
@ -217,8 +217,8 @@ air pressure sensor
|
||||
\section{Base Level Components}
|
||||
|
||||
A common factor with all safety critical systems, is
|
||||
the bought in components. Be these
|
||||
electrical, mechanical or firmware, they all
|
||||
base level -or- bought in components. Be these
|
||||
electrical, mechanical or firmware, they should all
|
||||
have known failure modes.
|
||||
|
||||
\subsection { Failure modes defining the component}
|
||||
|
@ -7,7 +7,7 @@
|
||||
\begin{abstract}
|
||||
This paper describes a process for analysing safety critical systems, to formally prove how safe the
|
||||
designs and built -in safety measures are. It provides
|
||||
the rigourous method for creating a fault effects model of a system from the bottom up using {\bc} level fault modes.
|
||||
the rigorous method for creating a fault effects model of a system from the bottom up using {\bc} level fault modes.
|
||||
Using symptom extraction, and taking {\fgs} of components, a fault behaviour
|
||||
hierarchy is built, forming a fault model tree.
|
||||
From the fault model trees,
|
||||
@ -21,7 +21,7 @@ EN298, EN61508, EN12067, EN230, UL1998.
|
||||
{
|
||||
This chapter describes a process for analysing safety critical systems, to formally prove how safe the
|
||||
designs and built -in safety measures are. It provides
|
||||
the rigourous method for creating a fault effects model of a system from the bottom up using {\bc} level fault modes.
|
||||
the rigorous method for creating a fault effects model of a system from the bottom up using {\bc} level fault modes.
|
||||
Using symptom extraction, and taking {\fgs} of components, a fault behaviour
|
||||
hierarchy is built, forming a fault model tree.
|
||||
From the fault model trees,
|
||||
@ -41,8 +41,7 @@ EN298, EN61508, EN12067, EN230, UL1998.
|
||||
|
||||
The purpose of the FMMD methodology is to apply formal techniques to
|
||||
the assessment of safety critical designs, aiding in identifying detected and undetected faults
|
||||
\footnote{Undetectable faults
|
||||
are faults which may occur but are not self~detected, or are impossible to detect by the system.}.
|
||||
\footnote{Undetectable faults are faults which may occur but are not self~detected, or are impossible to detect by the system.}.
|
||||
Formal methods are just beginning to be specified in some safety standards.\footnote{Formal methods
|
||||
such as the Z notation appear as `highly recommended' techniques in the EN61508 standard\cite{en61508}, but
|
||||
apply only to software currently.} However, some standards are now implying the handling of
|
||||
@ -73,7 +72,7 @@ The statistical method
|
||||
requires additional Mean Time To Failure (MTTF) data for all part failure modes.
|
||||
|
||||
The FMMD methodology applies defined stages and processes that will
|
||||
create a modular fault mode hierarchy. From this
|
||||
create a modular fault mode hierarchy. From this,
|
||||
complete fault analysis trees can be determined. It uses a modular approach, so that repeated sections
|
||||
of system design can be modelled once, and re-used.
|
||||
%formally prove safety critical
|
||||
@ -107,7 +106,7 @@ components that interact and naturally form {\fgs}. The initial {\fgs} are thus
|
||||
From the point of view of fault analysis, we are not interested in the components themselves, but in the ways in which they can fail.
|
||||
|
||||
For this study a {\fg} will mean a collection of components.
|
||||
In order to determine the symptoms or failure modes of a {\fg}
|
||||
In order to determine the symptoms or failure modes of a {\fg},
|
||||
we need to consider all failure modes of its components.
|
||||
By analysing the fault behaviour of a `{\fg}' with respect these failure modes
|
||||
we can derive a new set of possible failure modes.
|
||||
@ -294,7 +293,7 @@ In FTA\cite{nucfta}\cite{nasafta} terminology, these paths through the tree are
|
||||
A hierarchy of levels of faults becoming more abstract at each level should
|
||||
converge to a small sub-set of system level errors.
|
||||
|
||||
This thinning out of the number of system level errors is borne out in practise;
|
||||
This thinning out of the number of system level errors is borne out in practice;
|
||||
real time control systems often have a small number of major reportable faults (typically $ < 50$),
|
||||
even though they may have accompanying diagnostic data.
|
||||
|
||||
@ -541,7 +540,7 @@ simply be given a different index number and re-used.
|
||||
|
||||
It is common in safety critical systems to use redundancy.
|
||||
Two or sometimes three control systems will be assigned to the same process.
|
||||
An arbittration system, the arbiter, will decide which channel may control
|
||||
An arbitration system, the arbiter, will decide which channel may control
|
||||
the equipment.
|
||||
Where a system has several independent parallel control channels, each one can be a separate FMMD hierarchy.
|
||||
|
||||
|
@ -290,7 +290,7 @@ the test case failure modes will cause.
|
||||
In the case of a simple
|
||||
electronic circuit, we could calculate the effect on voltages
|
||||
within the circuit given certain component failure modes, for instance.
|
||||
The affect of these unusual volatges would then be a failure
|
||||
The affect of these unusual voltages would then be a failure
|
||||
mode of the functional group and become the result of the test case.
|
||||
When each test case has been analysed, we have a set of
|
||||
results. These are the failure modes of the functional group.
|
||||
@ -460,7 +460,7 @@ $$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
The symptom abstraction technique allows us to take a functional group of components,
|
||||
The symptom abstraction methodology 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.
|
||||
The checks and constraints applied in the algorithm ensure that all component failure
|
||||
@ -475,7 +475,7 @@ as the hierarchy progresses upwards.
|
||||
%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,
|
||||
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
|
||||
@ -483,7 +483,7 @@ The number of causes for any of these faults is very large.
|
||||
It does not matter to the user, which combination of component failure~modes caused the fault.
|
||||
But as the hierarchy goes up in abstraction level, the number of faults goes down.
|
||||
|
||||
\subsection{Tracable Fault Modes}
|
||||
\subsection{Traceable Fault Modes}
|
||||
|
||||
Because the fault modes are determined from the bottom-up, the causes
|
||||
for all high level faults naturally form trees.
|
||||
|
@ -7,7 +7,7 @@ and then determining how that {\fg} can fail.
|
||||
%
|
||||
With this information, we can treat the {\fg}
|
||||
as a component in its own right.
|
||||
This new component, is a derived from the {\fg}.
|
||||
This new component, is derived from the {\fg}.
|
||||
In the field of safety engineering this derived component corresponds 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.
|
||||
%
|
||||
|
@ -191,13 +191,13 @@ $c\_2$ & $fs\_7$ & $g_{7}$ & SP2\\ \hline
|
||||
Table~\ref{tab:fexsymptoms} shows the analysis process.
|
||||
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}.
|
||||
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).
|
||||
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 the {\fg} $FG$ to be $\{g_2, g_4, g_5\}$
|
||||
As failure modes, these
|
||||
As failure modes, these are
|
||||
identical from the perspective of the functional~group.
|
||||
That is to say, the way in which functional~group fails if $g_2$, $g_4$ or $g_5$ % failure modes
|
||||
occur, is going to be the same.
|
||||
@ -234,7 +234,7 @@ We can thus apply the function $fm$ on this newly derived component thus:
|
||||
|
||||
$$ fm(DC) = \{ SP1, SP2, SP3 \} $$
|
||||
|
||||
Note that $g_6$ has \textbf{not dissappeared from the analysis process}.
|
||||
Note that $g_6$ has \textbf{not disappeared 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
|
||||
@ -253,7 +253,7 @@ from base level components cannot be overlooked.
|
||||
The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}).
|
||||
}
|
||||
%
|
||||
The newly derived component $DC$ is availble for use to form higher level functional groups, and we can thus
|
||||
The newly derived component $DC$ is available 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}$
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
@ -1,3 +1,9 @@
|
||||
%%
|
||||
%%
|
||||
%% OBSOLETE DO NOT EDIT
|
||||
%%
|
||||
%%
|
||||
%%
|
||||
\section{The Symptom Extraction Process}
|
||||
|
||||
% TO DO: separate these two:
|
||||
|
@ -3,20 +3,20 @@
|
||||
|
||||
\subsection{Static Analysis}
|
||||
|
||||
In the field of safety critical engineering; to comply with
|
||||
European Law a product must be certified under the appropriate `EN' standard.
|
||||
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}.
|
||||
|
||||
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,
|
||||
Three main methodologies are currently used,
|
||||
Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis).
|
||||
The FMMD technique is a static modelling methodology, aimed primarily as design verification for
|
||||
The FMMD process is a static modelling methodology, aimed primarily as design verification for
|
||||
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 technique, statistical, FTA and FMEA models
|
||||
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.
|
||||
@ -60,7 +60,7 @@ Top down formal fault isolation/finding techniques for electronics are described
|
||||
%% this study needs to use this term to keep the interested/in context.
|
||||
The term `sub-system' is typically used in top down methodologies.
|
||||
It has two equivalents in FMMD.
|
||||
Both {\fg} and {\dc} correspond to the top doiwn concept of a `sub-system'.
|
||||
Both {\fg} and {\dc} correspond to the top down concept of a `sub-system'.
|
||||
In FMMD a {\fg} becomes a {\dc} after analysis.
|
||||
The term sub-system will be used alongside both {\fg} and {\dc} where necessary.
|
||||
|
||||
@ -73,7 +73,7 @@ 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}
|
||||
The FMMD technique does not follow the `natural fault finding' or top down approach,
|
||||
The FMMD methodology 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
|
||||
|
Loading…
Reference in New Issue
Block a user