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

Fault Scenario now, not test~case

Browse Source
This commit is contained in:
Robin Clark 2011-06-25 15:59:37 +01:00
parent c40b0dc8f7
commit d3141cdd76
1 changed files with 33 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

63
fmmd_concept/System_safety_2011/submission.tex
View File

@ -10,6 +10,8 @@
\usepackage{lastpage}
\usetikzlibrary{shapes,snakes}
\newcommand{\tickYES}{\checkmark}
\newcommand{\fc}{\em fault scenario}
\newcommand{\fcs}{\em fault scenarios}
\date{}
%\newboolean{paper}
@ -346,7 +348,8 @@ In the proposed methodology components are collected into functional groups
and each component failure (and optionally combinations) are considered in the
context of the {\fg}.
%
The component failures (and optional combinations) are termed `test~cases'. For each test~case
The component failures (and optional combinations) are termed {\fcs}. %`test~cases'.
For each {\fc}
there will be a corresponding resultant failure, or `symptom', from the perspective of the {\fg}.
%
% MAYBE NEED TO DESCRIBE WHAT A SYMPTOM IS HERE
@ -360,7 +363,7 @@ from the perspective of a {\fg}.
%
A common symptom collection stage is now applied. Here common symptoms are collected
from the results of the test~cases. Because optional combinations of failures are possible,
from the results of the {\fcs}. Because optional combinations of failures are possible,
multiple failures can be modelled, satisfying criterion 6.
%
With a collection of the {\fg} failure symptoms, we can create a {\dc}.
@ -370,7 +373,7 @@ modules available for re-use.
By using {\dcs} in higher level functional groups, a hierarchy can be built representing
the failure mode behaviour of a system. Because the hierarchy maintains information
linking the symptoms to test~cases to component failure modes, we have traceable
linking the symptoms to {\fcs} to component failure modes, we have traceable
reasoning connections from base component failures to top level failures.
The traceability should satisfy criterion 5.
@ -558,14 +561,14 @@ and determine how they affect the operation of the potential divider.
\ifthenelse {\boolean{pld}}
{
Each labelled asterisk in the diagram represents a failure mode scenario.
The failure mode scenarios are given test case numbers, and an example to clarify this follows
The failure mode scenarios are given {\fc} numbers, and an example to clarify this follows
in table~\ref{pdfmea}.
\begin{figure}[h+]
\centering
\includegraphics[width=200pt,keepaspectratio=true]{./noninvopamp/fg1a.png}
% fg1a.jpg: 430x271 pixel, 72dpi, 15.17x9.56 cm, bb=0 0 430 271
\caption{potential divider with test cases}
\caption{potential divider with {\fcs}}
\label{fig:fg1a}
\end{figure}
}
@ -577,8 +580,8 @@ in table~\ref{pdfmea}.
{
For this example we can look at single failure modes only.
For each failure mode in our {\fg} `potential~divider'
we can assign a test case number (see table \ref{pdfmea}).
Each test case is analysed to determine the `symptom'
we can assign a {\fc} number (see table \ref{pdfmea}).
Each {\fc} is analysed to determine the `symptom'
on the potential dividers' operation. For instance
were the resistor $R_1$ to go open, the circuit would not be grounded and the
voltage output from it would float high (+ve).
@ -644,15 +647,15 @@ This is represented in the DAG in figure \ref{fig:fg2adag}.
\centering % used for centering table
\begin{tabular}{||l|c|c|l||}
\hline \hline
\textbf{Test} & \textbf{Pot.Div} & \textbf{Symptom} \\
\textbf{Case} & \textbf{Effect} & \textbf{Description} \\
\textbf{Fault} & \textbf{Pot.Div} & \textbf{Symptom} \\
\textbf{Scenario} & \textbf{Effect} & \textbf{Description} \\
% R & wire & res + & res - & description
\hline
\hline
TC1: $R_1$ SHORT & LOW & LowPD \\
TC2: $R_1$ OPEN & HIGH & HighPD \\ \hline
TC3: $R_2$ SHORT & HIGH & HighPD \\
TC4: $R_2$ OPEN & LOW & LowPD \\ \hline
FS1: $R_1$ SHORT & LOW & LowPD \\
FS2: $R_1$ OPEN & HIGH & HighPD \\ \hline
FS3: $R_2$ SHORT & HIGH & HighPD \\
FS4: $R_2$ OPEN & LOW & LowPD \\ \hline
\hline
\end{tabular}
\label{pdfmea}
@ -665,7 +668,7 @@ We can now collect the symptoms of failure. From the four base component failure
have two symptoms, where the potential divider will give an incorrect low voltage (which we can term $LowPD$)
or an incorrect high voltage (which we can term $HighPD$).
We can represent the collection of these symptoms by drawing connecting lines between
the test cases and naming them (see figure \ref{fig:fg1b}).
the {\fcs} and naming them (see figure \ref{fig:fg1b}).
\begin{figure}[h+]
\centering
\includegraphics[width=200pt,keepaspectratio=true]{./noninvopamp/fg1b.png}
@ -805,15 +808,15 @@ from the potential divider {\dc}, represented by figure~\ref{fig:fgamp}.
\label{fig:fgamp}
\end{figure}
We can now place test cases on this (note this analysis considers single failure modes only
where we want to model multiple failures, we can over lap contours, and place the test cases in overlapping
We can now place {\fcs} on this (note this analysis considers single failure modes only
where we want to model multiple failures, we can over lap contours, and place the {\fcs} in overlapping
regions) see figure~\ref{fig:fgampa}.
\begin{figure}[h+]
\centering
\includegraphics[width=200pt,keepaspectratio=true]{./noninvopamp/fgampa.png}
% fgampa.jpg: 430x330 pixel, 72dpi, 15.17x11.64 cm, bb=0 0 430 330 hno
\caption{Amplifier Functional Group with Test Cases}
\caption{Amplifier Functional Group with {\fcs}}
\label{fig:fgampa}
\end{figure}
}
@ -824,7 +827,7 @@ regions) see figure~\ref{fig:fgampa}.
{
We can now create a {\fg} for the non-inverting amplifier
by bringing together the failure modes from \textbf{opamp} and \textbf{PD}.
Each of these failure modes will be given a test case for analysis,
Each of these failure modes will be given a {\fc} for analysis,
and this is represented in table \ref{ampfmea}.
}
@ -838,27 +841,27 @@ and this is represented in table \ref{ampfmea}.
\centering % used for centering table
\begin{tabular}{||l|c|c|l||}
\hline \hline
\textbf{Test} & \textbf{Amplifier} & \textbf{Symptom} \\
\textbf{Case} & \textbf{Effect} & \textbf{Description} \\
\textbf{Fault} & \textbf{Amplifier} & \textbf{Symptom} \\
\textbf{Scenario} & \textbf{Effect} & \textbf{Description} \\
% R & wire & res + & res - & description
\hline
\hline
TC1: $OPAMP$ & Output & AMPHigh \\
FS1: $OPAMP$ & Output & AMPHigh \\
LatchUP & High & \\ \hline
TC2: $OPAMP$ & Output Low& AMPLow \\
FS2: $OPAMP$ & Output Low& AMPLow \\
LatchDown & Low gain & \\ \hline
TC3: $OPAMP$ & Output Low & AMPLow \\
FS3: $OPAMP$ & Output Low & AMPLow \\
No Operation & & \\ \hline
TC4: $OPAMP$ & Low pass & LowPass \\
FS4: $OPAMP$ & Low pass & LowPass \\
Low Slew & filtering & \\ \hline
TC5: $PD$ & Output High & AMPHigh \\
FS5: $PD$ & Output High & AMPHigh \\
LowPD & & \\ \hline
TC6: $PD$ & Output Low & AMPLow \\
FS6: $PD$ & Output Low & AMPLow \\
HighPD & Low Gain & \\ \hline
%TC7: $R_2$ OPEN & LOW & & LowPD \\ \hline
\hline
@ -868,8 +871,7 @@ and this is represented in table \ref{ampfmea}.
}
Let us consider, for the sake of example, that the voltage follower (very low gain of 1.0)
amplification chracteristics from
TC2 and TC6 can be considered as low output from the OPAMP for the application
amplification chracteristics from FS2 and FS6 can be considered as low output from the OPAMP for the application
in hand (say milli-volt signal amplification).
For this amplifier configuration we have three failure modes, $AMPHigh, AMPLow, LowPass$.%see figure~\ref{fig:fgampb}.
@ -1180,7 +1182,8 @@ This is because the multiple failure modes are considered
within {\fgs} which have fewer failure modes to consider
at each FMMD stage.
Where appropriate, multiple simultaneous failures can be modelled by
introducing test~cases where the conjunction of failure modes is considered.
introducing {\fc} %test~cases
where the conjunction of failure modes is considered.
\end{itemize}
}
@ -1232,7 +1235,7 @@ It can therefore be used to analyse systems comprised of electrical,
mechanical and software elements in one integrated model.
Furthermore the reasoning path is traceable. By being able to trace a
top level event down through derived components, to base component
failure modes, with each step annotated as test cases, the model is easier to maintain.
failure modes, with each step annotated as {\fcs}, the model is easier to maintain.
%\today
%