Oh doh looks like I forgot some typos in the ch5 I sent to Chris
This commit is contained in:
parent
45ee8ed8c2
commit
1bf30e003b
@ -8,33 +8,24 @@ of a system's components and determining the effects of these failures
|
|||||||
on the behaviour and safety of the system."
|
on the behaviour and safety of the system."
|
||||||
\end{quotation}.
|
\end{quotation}.
|
||||||
|
|
||||||
\section{Concepts}
|
|
||||||
|
|
||||||
\paragraph{Forward and backward searches}
|
|
||||||
|
|
||||||
A forward search starts with possible failure causes
|
|
||||||
and uses logic and reasoning to determine system level outcomes.
|
|
||||||
A backward search starts with system level events
|
|
||||||
works back down (and not necessarily to
|
|
||||||
base components in a system) using de-composition of
|
|
||||||
of the system and logic.
|
|
||||||
FMEA based methodologies are forward searches\cite{Lutz:1997:RAU:590564.590572} and top down
|
|
||||||
methodologies such as FTA~\cite{nucfta,nasafta}
|
|
||||||
|
|
||||||
\paragraph{Reasoning distance}
|
|
||||||
A reasoning distance is the number of stages of logic and reasoning
|
|
||||||
required to map a failure cause to its potential outcomes.
|
|
||||||
%.... general concept... simple ideas about how complex a
|
|
||||||
%failure analysis is the more modules and components are involved
|
|
||||||
% cite for forward and backward search related to safety critical software
|
|
||||||
%{sfmeaforwardbackward}
|
|
||||||
|
|
||||||
\section{FMEA}
|
\section{FMEA}
|
||||||
|
|
||||||
%\subsection{FMEA}
|
%\subsection{FMEA}
|
||||||
%\tableofcontents[currentsection]
|
%\tableofcontents[currentsection]
|
||||||
|
\paragraph{FMEA basic concept.}
|
||||||
|
|
||||||
|
FMEA~\cite{safeware}[pp.341-344] is widely used, and proof of its use is a mandatory legal requirement
|
||||||
|
for a large proportion of safety critical products sold in the European Union.
|
||||||
|
The acronym FMEA can be expanded as follows:
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{F - Failures of given component} Consider a component in a system,
|
||||||
|
\item \textbf{M - Failure Mode} Look at one of the ways in which it can fail (i.e. determine a component `failure~mode'),
|
||||||
|
\item \textbf{E - Effects} Determine the effects this failure mode will cause to the system we are examining,
|
||||||
|
\item \textbf{A - Analysis} Analyse how much impact this symptom will have on the environment/people/the system its-self.
|
||||||
|
\end{itemize}
|
||||||
|
%
|
||||||
FMEA is a broad term; it could mean anything from an informal check on how
|
FMEA is a broad term; it could mean anything from an informal check on how
|
||||||
how failures could affect some equipment in an initial brain-storming session
|
how failures could affect some equipment in an initial brain-storming session
|
||||||
in product design, to formal submission as part of safety critical certification.
|
in product design, to formal submission as part of safety critical certification.
|
||||||
@ -67,21 +58,11 @@ the effectiveness of FMEA.
|
|||||||
% % \item Analysis
|
% % \item Analysis
|
||||||
% % \end{itemize}
|
% % \end{itemize}
|
||||||
|
|
||||||
\clearpage
|
%\clearpage
|
||||||
\paragraph{FMEA basic concept.}
|
|
||||||
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
|
|
||||||
\item \textbf{F - Failures of given component} Consider a component in a system
|
|
||||||
\item \textbf{M - Failure Mode} Look at one of the ways in which it can fail (i.e. determine a component `failure~mode')
|
|
||||||
\item \textbf{E - Effects} Determine the effects this failure mode will cause to the system we are examining
|
|
||||||
\item \textbf{A - Analysis} Analyse how much impact this symptom will have on the environment/people/the system itsself
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
FMEA is a procedure based on the low level components of a system, and an example
|
FMEA is a procedure which starts with the failure modes of the low level components of a system, an example
|
||||||
analysis will serve to demonstrate it in practise.
|
analysis will serve to demonstrate it in practise.
|
||||||
|
|
||||||
\paragraph{ FMEA Example: Milli-volt reader}
|
\paragraph{ FMEA Example: Milli-volt reader}
|
||||||
@ -148,7 +129,7 @@ approach in looking for system failures.
|
|||||||
\section{Theoretical Concepts in FMEA}
|
\section{Theoretical Concepts in FMEA}
|
||||||
|
|
||||||
|
|
||||||
\subsection{The unacceptability of a single component failure causing a catastrophe}
|
\paragraph{The unacceptability of a single component failure causing a catastrophe}
|
||||||
|
|
||||||
FMEA, due to its inductive bottom-up approach, is very good
|
FMEA, due to its inductive bottom-up approach, is very good
|
||||||
at finding potential single component failures that could have catastrophic implications.
|
at finding potential single component failures that could have catastrophic implications.
|
||||||
@ -157,7 +138,7 @@ for unearthing these failure scenarios.
|
|||||||
It is less useful for determining catastrophic events for multiple
|
It is less useful for determining catastrophic events for multiple
|
||||||
simultaneous\footnote{Multiple simultaneous failures are taken to mean failure that occur within the same detection period.} failures.
|
simultaneous\footnote{Multiple simultaneous failures are taken to mean failure that occur within the same detection period.} failures.
|
||||||
|
|
||||||
\subsection{Impracticality of Field Data for modern systems}
|
\paragraph{Impracticality of Field Data for modern systems}
|
||||||
|
|
||||||
Modern electronic components, are generally very reliable, and the systems built from them
|
Modern electronic components, are generally very reliable, and the systems built from them
|
||||||
are thus very reliable too. Reliable field data on failures will, therefore be sparse.
|
are thus very reliable too. Reliable field data on failures will, therefore be sparse.
|
||||||
@ -172,7 +153,25 @@ However, we can use FMEA (more specifically the FMEDA variant, see section~\ref{
|
|||||||
working from known component failure rates, to obtain
|
working from known component failure rates, to obtain
|
||||||
statistical estimates of the equipment reliability.
|
statistical estimates of the equipment reliability.
|
||||||
|
|
||||||
|
\paragraph{Forward and backward searches}
|
||||||
|
|
||||||
|
A forward search starts with possible failure causes
|
||||||
|
and uses logic and reasoning to determine system level outcomes.
|
||||||
|
Forward search types of fault analysis is said to be `inductive'.
|
||||||
|
|
||||||
|
A backward search starts with (undesirable) system level events
|
||||||
|
works back down to potential causes using de-composition of
|
||||||
|
of the system and logic.
|
||||||
|
FMEA based methodologies are forward searches\cite{Lutz:1997:RAU:590564.590572} and top down
|
||||||
|
methodologies such as FTA~\cite{nucfta,nasafta}
|
||||||
|
Forward search types of fault analysis is said to be `deductive'.
|
||||||
|
\paragraph{Reasoning distance}
|
||||||
|
A reasoning distance is the number of stages of logic and reasoning
|
||||||
|
required to map a failure cause to its potential outcomes.
|
||||||
|
%.... general concept... simple ideas about how complex a
|
||||||
|
%failure analysis is the more modules and components are involved
|
||||||
|
% cite for forward and backward search related to safety critical software
|
||||||
|
%{sfmeaforwardbackward}
|
||||||
\subsection{FMEA and the State Explosion Problem}
|
\subsection{FMEA and the State Explosion Problem}
|
||||||
|
|
||||||
\paragraph{Rigorous Single Failure FMEA}
|
\paragraph{Rigorous Single Failure FMEA}
|
||||||
@ -369,7 +368,7 @@ for a project manager.
|
|||||||
\item \textbf{Guidelines} To system architectures and development processes
|
\item \textbf{Guidelines} To system architectures and development processes
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
FMEDA is the methodology behind statistical (safety integrity level)
|
FMEDA is the fundamental methodology of the statistical (safety integrity level)
|
||||||
type standards (EN61508/IOC5108).
|
type standards (EN61508/IOC5108).
|
||||||
It provides a statistical overall level of safety
|
It provides a statistical overall level of safety
|
||||||
and allows diagnostic mitigation for self checking etc.
|
and allows diagnostic mitigation for self checking etc.
|
||||||
@ -386,12 +385,6 @@ For software it provides procedural quality guidelines and constraints (such as
|
|||||||
programming languages and/or features.
|
programming languages and/or features.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
\subsection{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
\subsection{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
||||||
\label{sec:FMEDA}
|
\label{sec:FMEDA}
|
||||||
\textbf{Failure Mode Classifications in FMEDA.}
|
\textbf{Failure Mode Classifications in FMEDA.}
|
||||||
|
@ -725,6 +725,7 @@ as a building block for other {\fgs} in the same way as we used the base compone
|
|||||||
%
|
%
|
||||||
\paragraph{Failure Mode Analysis of a generic op-amp.}
|
\paragraph{Failure Mode Analysis of a generic op-amp.}
|
||||||
%
|
%
|
||||||
|
\label{sec:opamp_fms}
|
||||||
%\clearpage
|
%\clearpage
|
||||||
Let us now consider the op-amp as a {\bc}. According to
|
Let us now consider the op-amp as a {\bc}. According to
|
||||||
FMD-91~\cite{fmd91}[3-116] an op amp may have the following failure modes %(with assigned probabilities):
|
FMD-91~\cite{fmd91}[3-116] an op amp may have the following failure modes %(with assigned probabilities):
|
||||||
|
@ -606,15 +606,15 @@ Both approaches are followed in the next two sub-sections.
|
|||||||
|
|
||||||
\subsection{First Approach: Inverting OPAMP using a Potential Divider {\dc}}
|
\subsection{First Approach: Inverting OPAMP using a Potential Divider {\dc}}
|
||||||
|
|
||||||
We cannot simply re-use the $PD$ from section~\ref{subsec:potdiv}, not simply because
|
We cannot simply re-use the {\dc} $PD$ from section~\ref{subsec:potdiv}, not just because
|
||||||
the potential divider is inverted, but, in addition the
|
the potential divider is inverted, but in addition, it facilitates the
|
||||||
output feedback forms a current balance with the input signal. %---that potential divider would only be valid if the input signal were negative.
|
output feedback forming a current balance with the input signal. %---that potential divider would only be valid if the input signal were negative.
|
||||||
%We want if possible to have detectable errors.
|
%We want if possible to have detectable errors.
|
||||||
%HIGH and LOW failures are more observable than the more generic failure modes such as `OUTOFRANGE'.
|
%HIGH and LOW failures are more observable than the more generic failure modes such as `OUTOFRANGE'.
|
||||||
%If we can refine the operational states of the functional group, we can obtain clearer
|
%If we can refine the operational states of the functional group, we can obtain clearer
|
||||||
%symptoms.
|
%symptoms.
|
||||||
Were the input to be guaranteed % the input will only be
|
Were the input to be guaranteed % the input will only be
|
||||||
positive, we could the potential divider (see table~\ref{tbl:pdneg}).
|
positive, we can view it as an inverted potential divider (see table~\ref{tbl:pdneg}).
|
||||||
|
|
||||||
\begin{table}[h+]
|
\begin{table}[h+]
|
||||||
\caption{Inverted Potential divider: Single failure analysis}
|
\caption{Inverted Potential divider: Single failure analysis}
|
||||||
@ -1010,7 +1010,7 @@ We begin by identifying functional groups from the components in the circuit.
|
|||||||
|
|
||||||
Looking first at the components in the signal path, we notice that we have a non-inverting
|
Looking first at the components in the signal path, we notice that we have a non-inverting
|
||||||
amplifier formed by R1,R2 and IC1. In fact apart from being
|
amplifier formed by R1,R2 and IC1. In fact apart from being
|
||||||
inverted visually on the schematic it is identical to the example
|
inverted visually on the schematic, it is identical to the example
|
||||||
used in section~\ref{sec:noninvamp} (the first practical example used to demonstrate FMMD).
|
used in section~\ref{sec:noninvamp} (the first practical example used to demonstrate FMMD).
|
||||||
We thus re-use this and can express the failure modes for it thus:
|
We thus re-use this and can express the failure modes for it thus:
|
||||||
|
|
||||||
@ -1129,9 +1129,9 @@ Here it is more intuitive to model the resistors not as a potential divider, but
|
|||||||
\end{table}
|
\end{table}
|
||||||
|
|
||||||
Collecting the symptoms we can see that this amplifier fails
|
Collecting the symptoms we can see that this amplifier fails
|
||||||
in 4 ways %$\{ AMPHigh, AMPLow, LowPass, AMPIncorrectOutput\}$.
|
in four ways. %$\{ AMPHigh, AMPLow, LowPass, AMPIncorrectOutput\}$.
|
||||||
%We can now
|
%We can now
|
||||||
we create a derived component, $SEC\_AMP$, to represent it
|
We create a derived component, $SEC\_AMP$, to represent it
|
||||||
with failure modes described by:
|
with failure modes described by:
|
||||||
$$ fm(SEC\_AMP) = \{ AMPHigh, AMPLow, LowPass, AMPIncorrectOutput \} .$$
|
$$ fm(SEC\_AMP) = \{ AMPHigh, AMPLow, LowPass, AMPIncorrectOutput \} .$$
|
||||||
|
|
||||||
@ -1763,7 +1763,7 @@ Thus, $BUFF45$ is a {\dc} representing an actively buffered $45^{\circ}$ phase s
|
|||||||
From the block circuit diagram (figure~\ref{fig:circuit3}), we see that there are three
|
From the block circuit diagram (figure~\ref{fig:circuit3}), we see that there are three
|
||||||
$45^{\circ}$ phase shifter circuits in series. Together these apply a $135^{\circ}$ phase shift to the signal.
|
$45^{\circ}$ phase shifter circuits in series. Together these apply a $135^{\circ}$ phase shift to the signal.
|
||||||
%
|
%
|
||||||
We use this property to model a higher level {\dc}, that of a 135 degree phase shifter.
|
We use this property to model a higher level {\dc}, that of a $135^{\circ}$ phase shifter.
|
||||||
%
|
%
|
||||||
The three $BUFF45$ {\dcs} form a
|
The three $BUFF45$ {\dcs} form a
|
||||||
functional group which is analysed in table~\ref{tbl:phs135buffered}.
|
functional group which is analysed in table~\ref{tbl:phs135buffered}.
|
||||||
@ -1820,7 +1820,7 @@ Finally we form a final {\fg} with $PHS135BUFFERED$ and $PHS225AMP$,
|
|||||||
\end{tabular}
|
\end{tabular}
|
||||||
\end{table}
|
\end{table}
|
||||||
%
|
%
|
||||||
Collecting symptoms from table~\ref{tbl:buff45}, we can create a derived component $BUFF45$ which has the following failure modes:
|
collecting symptoms from table~\ref{tbl:buff45}, we can create a derived component $BUFF45$ which has the following failure modes:
|
||||||
$$
|
$$
|
||||||
fm (BUFF45) = \{ 0\_phaseshift, NO\_signal .\} % 90\_phaseshift,
|
fm (BUFF45) = \{ 0\_phaseshift, NO\_signal .\} % 90\_phaseshift,
|
||||||
$$
|
$$
|
||||||
@ -1968,7 +1968,7 @@ to analyse in the future.
|
|||||||
%is higher, by an order of $O(N^2)$.
|
%is higher, by an order of $O(N^2)$.
|
||||||
Smaller functional groups mean less by-hand checks are required.
|
Smaller functional groups mean less by-hand checks are required.
|
||||||
It also means a more finely grained model. This means that
|
It also means a more finely grained model. This means that
|
||||||
there are more {\dcs} and this increases the potential for re-use of pre-analysed {\dcs}.
|
there are more {\dcs} and therefore increases the potential for re-use of pre-analysed {\dcs}.
|
||||||
% HTR The more we can modularise, the more we decimate the $O(N^2)$ effect
|
% HTR The more we can modularise, the more we decimate the $O(N^2)$ effect
|
||||||
% HTR of complexity comparison.
|
% HTR of complexity comparison.
|
||||||
%
|
%
|
||||||
@ -2046,7 +2046,8 @@ of the input voltage (i.e. the value of the sum of 1's and 0's is proportional t
|
|||||||
The parts for the \sd are a mixture of analogue (resistors, capacitors, OpAmps) and digital
|
The parts for the \sd are a mixture of analogue (resistors, capacitors, OpAmps) and digital
|
||||||
(D type flip flop, and a digital clock). We examine the failure modes of all components in this circuit below.
|
(D type flip flop, and a digital clock). We examine the failure modes of all components in this circuit below.
|
||||||
%
|
%
|
||||||
IC1,2 and 3 are all OpAmps and we have failure modes from section~\ref{sec:opamp_fms}.
|
IC1,IC2 and IC3 are all OpAmps and we have failure modes for this component type
|
||||||
|
from section~\ref{sec:opamp_fms}.
|
||||||
%
|
%
|
||||||
$$ fm(OPAMP) = \{ HIGH, LOW, NOOP, LOW\_SLEW \} $$
|
$$ fm(OPAMP) = \{ HIGH, LOW, NOOP, LOW\_SLEW \} $$
|
||||||
%
|
%
|
||||||
@ -2146,36 +2147,29 @@ It therefore has the failure modes of an Op-amp.
|
|||||||
|
|
||||||
\begin{table}[h+]
|
\begin{table}[h+]
|
||||||
\center
|
\center
|
||||||
|
|
||||||
% \center
|
% \center
|
||||||
\caption{ High Impedance Signal Buffer : Failure Mode Effects Analysis} % title of Table
|
\caption{ High Impedance Signal Buffer : Failure Mode Effects Analysis} % title of Table
|
||||||
|
|
||||||
This is an OpAmp in a signal buffer configuration.
|
|
||||||
As it is performing one particular function
|
|
||||||
we my consider it as a derived component, that of a High Impedance Signal Buffer (HISB).
|
|
||||||
|
|
||||||
\begin{tabular}{|| l | l | c | c | l ||} \hline
|
\begin{tabular}{|| l | l | c | c | l ||} \hline
|
||||||
|
|
||||||
%\textbf{Failure Scenario} & & \textbf{failure result} & & \textbf{Symptom} \\
|
%\textbf{Failure Scenario} & & \textbf{failure result} & & \textbf{Symptom} \\
|
||||||
% & & & & \\
|
% & & & & \\
|
||||||
\textbf{Failure} & & \textbf{$HISB$ } & & \textbf{Derived Component} \\
|
\textbf{Failure} & & \textbf{$HISB$ } & & \textbf{Derived Component} \\
|
||||||
\textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\
|
\textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\
|
||||||
|
|
||||||
\hline\hline
|
\hline\hline
|
||||||
|
|
||||||
FS1: $IC2$ $HIGH$ & & output perm. high & & HIGH \\
|
FS1: $IC2$ $HIGH$ & & output perm. high & & HIGH \\
|
||||||
FS2: $IC2$ $LOW$ & & output perm. low & & LOW \\
|
FS2: $IC2$ $LOW$ & & output perm. low & & LOW \\
|
||||||
FS3: $IC2$ $NOOP$ & & no current to output & & $NOOP$ \\
|
FS3: $IC2$ $NOOP$ & & no current to output & & $NOOP$ \\
|
||||||
FS4: $IC2$ $LOW\_SLEW$ & & delay signal & & $LOW\_{SLEW}$ \\ \hline
|
FS4: $IC2$ $LOW\_SLEW$ & & delay signal & & $LOW\_{SLEW}$ \\ \hline
|
||||||
|
|
||||||
|
|
||||||
\end{tabular}
|
\end{tabular}
|
||||||
\end{table}
|
\end{table}
|
||||||
% \hline
|
% \hline
|
||||||
%
|
%
|
||||||
% \end{tabular}
|
% \end{tabular}
|
||||||
% \end{table}
|
% \end{table}
|
||||||
We create the {\dc} $HISB$ and its failure mode may be stated as $$fm(HISB) = \{HIGH, LOW, NOOP, LOW_{SLEW} \}$$.
|
This is an OpAmp in a signal buffer configuration.
|
||||||
|
As it is performing one particular function
|
||||||
|
we my consider it as a derived component, that of a High Impedance Signal Buffer (HISB).
|
||||||
|
%
|
||||||
|
We create the {\dc} $HISB$ and its failure mode may be stated as $$fm(HISB) = \{HIGH, LOW, NOOP, LOW_{SLEW} \}.$$
|
||||||
|
|
||||||
\subsubsection{Digital level to analogue level conversion ($DL2AL$).}
|
\subsubsection{Digital level to analogue level conversion ($DL2AL$).}
|
||||||
The integrator is implemented in digital electronics, but the output from the D type flip flop is a digital signal.
|
The integrator is implemented in digital electronics, but the output from the D type flip flop is a digital signal.
|
||||||
@ -2186,8 +2180,9 @@ to the inverting input of IC3.
|
|||||||
|
|
||||||
\paragraph{Potential divider Formed by R3,R4.}
|
\paragraph{Potential divider Formed by R3,R4.}
|
||||||
We re-use the analysis from table~\ref{tbl:pdfmea}, and use the derived component $PD$
|
We re-use the analysis from table~\ref{tbl:pdfmea}, and use the derived component $PD$
|
||||||
to represent the potential divider formed by R3 and R4. Because PD is a derived component, we can denote this
|
to represent the potential divider formed by R3 and R4.
|
||||||
by super-scripting it with its abstraction level of 1, thus $PD$.
|
%Because PD is a derived component, we can denote this
|
||||||
|
%by super-scripting it with its abstraction level of 1, thus $PD$.
|
||||||
$$
|
$$
|
||||||
fm(PD) = \{ HIGH, LOW \}.
|
fm(PD) = \{ HIGH, LOW \}.
|
||||||
$$
|
$$
|
||||||
@ -2301,7 +2296,7 @@ have created our first {\dcs}. %and can now take stock of the situation
|
|||||||
These are:
|
These are:
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item SUMJINT --- A summing junction and integrator,
|
\item SUMJINT --- A summing junction and integrator,
|
||||||
\item HISB --- A High impedance buffer,
|
\item HISB --- A high impedance buffer,
|
||||||
\item DIGITALBUFF --- A one bit digital buffer,
|
\item DIGITALBUFF --- A one bit digital buffer,
|
||||||
\item DL2AL --- A digital to analog level converter,
|
\item DL2AL --- A digital to analog level converter,
|
||||||
\item DIGBUF --- A digital one bit buffer/memory.
|
\item DIGBUF --- A digital one bit buffer/memory.
|
||||||
@ -2313,7 +2308,7 @@ We now use these {\dcs} to create higher level {\fgs}.
|
|||||||
We represent this
|
We represent this
|
||||||
in the Euler diagram in figure~\ref{fig:eulersd}.
|
in the Euler diagram in figure~\ref{fig:eulersd}.
|
||||||
The next stage is to create {\fgs} from these initial {\dcs}
|
The next stage is to create {\fgs} from these initial {\dcs}
|
||||||
and make a complete failure mode mode for the {\sd}.
|
and make a complete failure mode for the {\sd}.
|
||||||
|
|
||||||
\begin{figure}[h]
|
\begin{figure}[h]
|
||||||
\centering
|
\centering
|
||||||
@ -2468,8 +2463,8 @@ We analyse the buffered {\sd} circuit in table~\ref{tbl:sdadc}.
|
|||||||
\end{tabular}
|
\end{tabular}
|
||||||
\end{table}
|
\end{table}
|
||||||
%\clearpage
|
%\clearpage
|
||||||
We now collect the symptoms for the \sd $ \;
|
We now collect the symptoms for the \sd
|
||||||
\{OUTPUT\_OUT\_OF\_RANGE, OUTPUT\_INCORRECT\}$.
|
$$ \; \{OUTPUT\_OUT\_OF\_RANGE, OUTPUT\_INCORRECT\}.$$
|
||||||
We can now create a {\dc} to represent the analogue to digital converter, $SADC^4$.
|
We can now create a {\dc} to represent the analogue to digital converter, $SADC^4$.
|
||||||
$$fm(SSDADC) = \{OUTPUT\_OUT\_OF\_RANGE, OUTPUT\_INCORRECT\}$$
|
$$fm(SSDADC) = \{OUTPUT\_OUT\_OF\_RANGE, OUTPUT\_INCORRECT\}$$
|
||||||
We now show the final {\dc} hierarchy in figure~\ref{fig:eulersdfinal}.
|
We now show the final {\dc} hierarchy in figure~\ref{fig:eulersdfinal}.
|
||||||
@ -2583,15 +2578,15 @@ of components, {\fgs} and symptoms of failure for a functional group.
|
|||||||
A programmatic function has similarities with a {\fg} as defined by the FMMD process.
|
A programmatic function has similarities with a {\fg} as defined by the FMMD process.
|
||||||
%
|
%
|
||||||
An FMMD {\fg} is placed into a hierarchy.
|
An FMMD {\fg} is placed into a hierarchy.
|
||||||
A Software function is placed into a hierarchy, that of its call-tree.
|
A software function is placed into a hierarchy, that of its call-tree.
|
||||||
A software function typically calls other functions and uses data sources via hardware interaction, which could be viewed as its `components'.
|
A software function typically calls other functions and uses data sources via hardware interaction, which could be viewed as its `components'.
|
||||||
It has outputs, i.e. it can perform actions
|
It has outputs, i.e. it can perform actions
|
||||||
on data or hardware
|
on data or hardware
|
||||||
which will be used by functions that may call it.
|
which will be used by functions that may call it.
|
||||||
|
%
|
||||||
We can map a software function to a {\fg} in FMMD. Its failure modes
|
We can map a software function to a {\fg} in FMMD. Its failure modes
|
||||||
are the failure modes of the software components (other functions it calls)
|
are the failure modes of the software components (other functions it calls)
|
||||||
and the hardware its reads values from.
|
and the hardware from which it reads values.
|
||||||
Its outputs are the data it changes, or the hardware actions it performs.
|
Its outputs are the data it changes, or the hardware actions it performs.
|
||||||
%%
|
%%
|
||||||
%% Talk about how software specification will often say how hardware
|
%% Talk about how software specification will often say how hardware
|
||||||
@ -2631,7 +2626,7 @@ and the subsequent hierarchy. With software already written, that hierarchy is f
|
|||||||
Software written for safety critical systems is usually constrained to
|
Software written for safety critical systems is usually constrained to
|
||||||
be modular~\cite{en61508}[3] and non recursive~\cite{misra}[15.2]. %{iec61511}.
|
be modular~\cite{en61508}[3] and non recursive~\cite{misra}[15.2]. %{iec61511}.
|
||||||
Because of this we can assume direct call trees~\footnote{A typical embedded system
|
Because of this we can assume direct call trees~\footnote{A typical embedded system
|
||||||
will have a run time call tree, and interrupt driven call tress}. Functions call functions
|
will have a run time call tree, and (possibly multiple) interrupt sourced call tress.}. Functions call functions
|
||||||
from the top down and eventually call the lowest level library or IO
|
from the top down and eventually call the lowest level library or IO
|
||||||
functions that interact with hardware/electronics.
|
functions that interact with hardware/electronics.
|
||||||
|
|
||||||
@ -2691,8 +2686,8 @@ that can alter the accuracy of the signal.
|
|||||||
%
|
%
|
||||||
%This circuit has many advantages for safety.
|
%This circuit has many advantages for safety.
|
||||||
If the signal becomes disconnected
|
If the signal becomes disconnected
|
||||||
it reads $0mA$ at the receiving end: as this is outside the {\ft} range
|
it reads $0mA$ at the receiving end: as this is outside the {\ft} range,
|
||||||
it is easy to detect as an error condition rather than an incorrect value.
|
it is easily detectable as an error condition rather than an incorrect value.
|
||||||
%
|
%
|
||||||
Should the driving electronics go wrong at the source end, it will usually
|
Should the driving electronics go wrong at the source end, it will usually
|
||||||
supply far too little or far too much current, also making error conditions easy to detect.
|
supply far too little or far too much current, also making error conditions easy to detect.
|
||||||
@ -2717,7 +2712,7 @@ The diagram in figure~\ref{fig:ftcontext}, shows some equipment which is sending
|
|||||||
signal to a micro-controller system.
|
signal to a micro-controller system.
|
||||||
The signal is locally driven over a load resistor, and then read into the micro-controller via
|
The signal is locally driven over a load resistor, and then read into the micro-controller via
|
||||||
an ADC and its multiplexer.
|
an ADC and its multiplexer.
|
||||||
With the voltage detected at the ADC the multiplexer can read the intended quantitative
|
With the voltage determined at the ADC we read the intended quantitative
|
||||||
value from the external equipment.
|
value from the external equipment.
|
||||||
|
|
||||||
\subsection{Simple Software Example}
|
\subsection{Simple Software Example}
|
||||||
@ -2730,7 +2725,7 @@ Let us assume the {\ft} detection is via a \ohms{220} resistor, and that we read
|
|||||||
from an ADC into the software.
|
from an ADC into the software.
|
||||||
Let us define any value outside the 4mA to 20mA range as an error condition.
|
Let us define any value outside the 4mA to 20mA range as an error condition.
|
||||||
%
|
%
|
||||||
As a voltage, we use ohms law~\cite{aoe} to determine the voltage ranges: $V=IR$, $0.004A * \ohms{220} = 0.88V$
|
As we read a voltage voltage, we use Ohms law~\cite{aoe} to determine the mA current detected: $V=IR$, $0.004A * \ohms{220} = 0.88V$
|
||||||
and $0.020A * \ohms{220} = 4.4V$.
|
and $0.020A * \ohms{220} = 4.4V$.
|
||||||
%
|
%
|
||||||
Our acceptable voltage range is therefore
|
Our acceptable voltage range is therefore
|
||||||
@ -2795,9 +2790,9 @@ We now look at the function called by \textbf{read\_4\_20\_input}, \textbf{read\
|
|||||||
voltage for a given ADC channel.
|
voltage for a given ADC channel.
|
||||||
%
|
%
|
||||||
This function
|
This function
|
||||||
deals directly with the hardware in the micro-controller that we are running the software on.
|
deals directly with the hardware in the micro-controller on which the software is running. %software on.
|
||||||
%
|
%
|
||||||
Its job is to select the correct channel (ADC multiplexer) and then to initiate a
|
The software's job is to select the correct channel (ADC multiplexer) and then to initiate a
|
||||||
conversion by setting an ADC 'go' bit (see code sample in figure~\ref{fig:code_read_ADC}).
|
conversion by setting an ADC 'go' bit (see code sample in figure~\ref{fig:code_read_ADC}).
|
||||||
%
|
%
|
||||||
It takes the raw ADC reading and converts it into a
|
It takes the raw ADC reading and converts it into a
|
||||||
@ -2874,7 +2869,7 @@ We now have a very simple software structure, a call tree, shown in figure~\ref{
|
|||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
This software is above the hardware in the conceptual call tree---from a programmatic perspective---%in software terms---the
|
This software is above the hardware in the conceptual call tree---from a programmatic perspective---%in software terms---the
|
||||||
software is reading values from the `lower~level' electronics.
|
the software is reading values from the `lower~level' electronics.
|
||||||
%
|
%
|
||||||
FMEA is always a bottom-up process and so we must begin with this hardware.
|
FMEA is always a bottom-up process and so we must begin with this hardware.
|
||||||
%
|
%
|
||||||
@ -3127,7 +3122,7 @@ The postcondition for the function $read\_4\_20\_input$, {\em /* ensure: value i
|
|||||||
% \paragraph{Final Functional Group}
|
% \paragraph{Final Functional Group}
|
||||||
For single failures these are the two ways in which this function
|
For single failures these are the two ways in which this function
|
||||||
can fail. An $OUT\_OF\_RANGE$ will be flagged by the error flag variable.
|
can fail. An $OUT\_OF\_RANGE$ will be flagged by the error flag variable.
|
||||||
The $VAL\_ERR$ will simply mean that the value read is simply wrong.
|
The $VAL\_ERR$ will simply mean that the value read is incorrect.
|
||||||
|
|
||||||
We can finally make a {\dc} to represent a failure mode model for our function $read\_4\_20\_input$ thus:
|
We can finally make a {\dc} to represent a failure mode model for our function $read\_4\_20\_input$ thus:
|
||||||
|
|
||||||
@ -3165,8 +3160,9 @@ as a hierarchical diagram, see figure~\ref{fig:eulerswhw}. % see figure~\ref{fig
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
We can represent the hierarchy in figure~\ref{fig:hd} algebraically, using the `$\derivec$' function
|
We can represent %the hierarchy in figure~\ref{fig:hd} algebraically,
|
||||||
using the groups as intermediate stages:
|
the analysis hierarchy algebraically using the `$\derivec$' function:
|
||||||
|
%using the groups as intermediate stages:
|
||||||
\begin{eqnarray*}
|
\begin{eqnarray*}
|
||||||
G_1 &=& \{R,ADC\} \\
|
G_1 &=& \{R,ADC\} \\
|
||||||
CMATV &=& \;\derivec (G_1) \\
|
CMATV &=& \;\derivec (G_1) \\
|
||||||
@ -3207,7 +3203,7 @@ it stretches from the component failure mode to the top---or---system level fail
|
|||||||
For this reason applying traditional FMEA to software stretches
|
For this reason applying traditional FMEA to software stretches
|
||||||
the reasoning distance even further. This is exacerbated by the fact that traditional SFMEA is
|
the reasoning distance even further. This is exacerbated by the fact that traditional SFMEA is
|
||||||
performed separately from HFMEA~\cite{sfmea,sfmeaa}, additionally even the software/hardware
|
performed separately from HFMEA~\cite{sfmea,sfmeaa}, additionally even the software/hardware
|
||||||
interfacing is treated as a seperate FMEA task~\cite{sfmeainterface,embedsfmea,procsfmea}
|
interfacing is treated as a separate FMEA task~\cite{sfmeainterface,embedsfmea,procsfmea}
|
||||||
|
|
||||||
|
|
||||||
We now have a {\dc} for a {\ft} input in software.
|
We now have a {\dc} for a {\ft} input in software.
|
||||||
|
Loading…
Reference in New Issue
Block a user