editing fmmdset and using FG and C instead of modules and derived sets etc
This commit is contained in:
parent
cc2fd46219
commit
d33bbb8a22
Binary file not shown.
BIN
fmmdset/fmmdh.jpg
Normal file
BIN
fmmdset/fmmdh.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 34 KiB |
@ -130,10 +130,24 @@ at a higher abstraction level.
|
||||
\subsubsection{An algebraic notation for identifying FMMD enitities}
|
||||
Each component $C$ is a set of failure modes for the component.
|
||||
We can define a function $FM$ that returns the
|
||||
set of failure modes $S$ for the component.
|
||||
set of failure modes $F$ for the component $C$.
|
||||
|
||||
Let the set of all possible components be $\mathcal{C}$
|
||||
and let the set of all possible failure modes be $\mathcal{F}$.
|
||||
|
||||
We can define a function $FM$
|
||||
|
||||
\begin{equation}
|
||||
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.
|
||||
|
||||
$$ FM ( C ) = F $$
|
||||
|
||||
|
||||
%$$ \mathcal{FM}(C) \rightarrow S $$
|
||||
$$ {FM}(C) \rightarrow S $$
|
||||
%$$ {FM}(C) \rightarrow S $$
|
||||
|
||||
We can indicate the abstraction level of a component by using a superscript.
|
||||
Thus for the component $C$, where it is a `base component' we can asign it
|
||||
@ -223,7 +237,7 @@ We can represent this analysis process in a diagram see figure \ref{fig:onestage
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=400pt,bb=0 0 555 520,keepaspectratio=true]{fmmdset/fmmdh.png}
|
||||
\includegraphics[width=400pt,bb=0 0 555 520,keepaspectratio=true]{fmmdset/fmmdh.jpg}
|
||||
% fmmdh.png: 555x520 pixel, 72dpi, 19.58x18.34 cm, bb=0 0 555 520
|
||||
\caption{FMMD Example Hierarchy}
|
||||
\label{fig:fmmdh}
|
||||
@ -235,15 +249,20 @@ We can represent this analysis process in a diagram see figure \ref{fig:onestage
|
||||
Figure \ref{fig:fmmdh} shows a hierarchy of failure mode de-composition.
|
||||
|
||||
It can be seen that the derived fault~mode sets are higher level abstractions of the fault behaviour of the modules.
|
||||
We can take this one stage further by combining the $D^{1}_{N}$ sets to form modules. These
|
||||
$M^2_{N}$ fault mode collections can be used to create $D^3_{N}$ derived fault~modes sets and so on.
|
||||
We can take this one stage further by combining the derived component $C^{1}_{N}$ sets to form functional~groups. These
|
||||
$FG^2_{N}$ functional~groups can be used to create $C^3_{N}$ derived components and so on.
|
||||
At the top of the hierarchy, there will be one final (where $t$ is the
|
||||
top level) set $D^{t}_{N}$ of abstract fault modes. The causes for these
|
||||
system level fault~modes will be traceable down to part fault modes.
|
||||
top level) component $C^{t}_{N}$ and {\em its fault modes, are the failure modes of the SYSTEM}. The causes for these
|
||||
system level fault~modes will be traceable down to part fault modes, traversing the tree
|
||||
through the lower level functional groups and components.
|
||||
each SYSTEM level fault may have a number of paths through the
|
||||
tree to different low level of base component failure modes.
|
||||
In FTA terminology, these paths through the tree are called `minimal cut sets'.
|
||||
|
||||
|
||||
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;
|
||||
real time control systems often have a small number of major reportable faults (typically $ < 50$),
|
||||
even though they may have accompanying diagnostic data.
|
||||
@ -287,6 +306,13 @@ Also this means that we may need dummy modules so as not to violate jumping up t
|
||||
%% CASE STUDY BEGIN
|
||||
|
||||
\subsection{Case Study FMMD Hierarchy:\\ Simple RS-232 voltage reader}
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=340pt,bb=0 0 532 192,keepaspectratio=true]{./mvsblock.jpg}
|
||||
% mvsblock.png: 532x192 pixel, 72dpi, 18.77x6.77 cm, bb=0 0 532 192
|
||||
\caption{Milli-Volt Sensor Block Diagram}
|
||||
\label{fig:mvsblock}
|
||||
\end{figure}
|
||||
|
||||
|
||||
%%% This is the tikz picture ??/
|
||||
@ -300,13 +326,13 @@ Also this means that we may need dummy modules so as not to violate jumping up t
|
||||
%\end{figure}
|
||||
%
|
||||
Consider a simple electronic system, that provides say two milli-volt amplifiers
|
||||
which passes the values onward via serial link - RS232. This is simple in concept, plug in a
|
||||
which passes the values onward via serial link - RS232 (see figure \ref{fig:mvsblock}). This is simple in concept, plug in a
|
||||
computer, run a terminal program, and the instrument will report the milli volt readings in ASCII
|
||||
with any error messages.
|
||||
|
||||
% in CRC checksum protected packets.
|
||||
|
||||
It is interesting to look at one of `functional groups'. The milli-volt amplifiers are a good example.
|
||||
It is interesting to look at one of `functional~groups'. The milli-volt amplifiers are a good example.
|
||||
These can be analysed by taking a functional~group, the components surrounding the op-amp,
|
||||
a few resistors to determine offset and gain,
|
||||
a safety resistor, and perhaps some smoothing capacitors.
|
||||
@ -327,12 +353,22 @@ via the RS232 serial line.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=400pt,bb=0 0 749 507,keepaspectratio=true]{fmmdset/millivolt_sensor.png}
|
||||
% millivolt_sensor.png: 749x507 pixel, 72dpi, 26.42x17.89 cm, bb=0 0 749 507
|
||||
\caption{Hierarchial Module Diagram : Millivolt Sensor Example}
|
||||
\label{fig:mvs}
|
||||
\includegraphics[width=400pt,bb=0 0 783 638,keepaspectratio=true]{./millivolt_sensor.jpg}
|
||||
% millivolt_sensor.jpg: 783x638 pixel, 72dpi, 27.62x22.51 cm, bb=0 0 783 638
|
||||
\caption{FMMD Hierarchy: Milli-volt sensor Example}
|
||||
\label{fig:vs}
|
||||
\end{figure}
|
||||
|
||||
|
||||
%
|
||||
% \begin{figure}[h]
|
||||
% \centering
|
||||
% \includegraphics[width=400pt,bb=0 0 749 507,keepaspectratio=true]{fmmdset/millivolt_sensor.png}
|
||||
% % millivolt_sensor.png: 749x507 pixel, 72dpi, 26.42x17.89 cm, bb=0 0 749 507
|
||||
% \caption{Hierarchial Module Diagram : Millivolt Sensor Example}
|
||||
% \label{fig:mvs}
|
||||
% \end{figure}
|
||||
|
||||
This has a number of obvious functional~groups, the PCB power supply, the milli-volt amplifiers,
|
||||
the analog to digital conversion circuitry, the micro processor and the UART (serial link - RS232 transceiver).
|
||||
It would make sense when analysing this system to take each one of these functional~groups in turn and examine them closely.
|
||||
@ -401,13 +437,25 @@ a `CHANNEL\_1' input fault.
|
||||
%\end{list}
|
||||
\end{description}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Thus we have looked at a single part fault and analysed its effect from the
|
||||
bottom up on the system as a whole, going up through the abstraction layers.
|
||||
|
||||
\subsection{Natural Fault finding}
|
||||
|
||||
Suppose that we were handed one of these `dual milli-volt' sensors and told that it had a ``Channel 1''
|
||||
fault and asked to trouble shoot and hopefully fix it.
|
||||
The natural process would be to work from the top down.
|
||||
First of all we would look at perhaps a circuit schematic.
|
||||
We might, not beliving the operator that the equipment is actually faulty, feed in a known and valid milli-volt signal into the input.
|
||||
On verifying it was actually faulty,
|
||||
we could then find the ADC port pins used to make the reading, and measure a voltage on them.
|
||||
We would find that the voltage was indeed out of range and our attention would turn to
|
||||
the circuitry between the input milli-volt signal and the ADC/Microcontroller.
|
||||
On examining this we would probably measure the in circuit resistances
|
||||
and discover the faulty resistor.
|
||||
With the natural fault finding process, we have narrowed down until we come to
|
||||
the faulty component. FMMD analysis works from the bottom~up, and this is
|
||||
because it must cover all component failure modes.
|
||||
%%
|
||||
%% END CASE STUDY
|
||||
%%
|
||||
@ -465,8 +513,8 @@ This is commponly referred to as a multi-channel safety critical system.
|
||||
Where there are 2 channels and one arbiter, the term 1oo2 is used (one out of two).
|
||||
The Ericsson AXE telephone exchange hardware is a 1oo2 system, and the arbiter (the AMD)
|
||||
can detect and switch control within on processor instruction. Should a hardware error
|
||||
be detected,\footnote{or in a test plant environment more likely someone coming along and `borrowing' a cpu board from
|
||||
your working exchange} the processor will side to the redundant side without breaking any telephone calls
|
||||
be detected,\footnote{Or in a test plant environment, more likely someone coming along and `borrowing' a cpu board from
|
||||
your working exchange} the processor will switch to the redundant side without breaking any telephone calls
|
||||
or any being set up. An alarm will be raised to inform that this has happened, but the impact to
|
||||
the 1oo2 system, is a one micro-processor instruction delay to the entire process.
|
||||
|
||||
|
Binary file not shown.
BIN
fmmdset/millivolt_sensor.jpg
Normal file
BIN
fmmdset/millivolt_sensor.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
BIN
fmmdset/mvsblock.jpg
Normal file
BIN
fmmdset/mvsblock.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 13 KiB |
Binary file not shown.
Binary file not shown.
Before Width: | Height: | Size: 7.6 KiB After Width: | Height: | Size: 7.7 KiB |
Loading…
Reference in New Issue
Block a user