diff --git a/fmmd_concept/System_safety_2011/submission.tex b/fmmd_concept/System_safety_2011/submission.tex index faa29fb..89f18a2 100644 --- a/fmmd_concept/System_safety_2011/submission.tex +++ b/fmmd_concept/System_safety_2011/submission.tex @@ -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 %