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

lunchtime edit

Browse Source
This commit is contained in:
Your Name 2012-04-05 14:32:21 +01:00
parent 2305f58a37
commit 0eca387b18
2 changed files with 106 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
papers/software_fmea/mybib.bib
View File

@ -145,6 +145,14 @@ methodology",
YEAR = "2005" YEAR = "2005"
} }
@BOOK{easw,
AUTHOR = "Nancy Leveson",
TITLE = "Engineering a safer world ISBN: 978-0262016629",
PUBLISHER = "MIT Press",
YEAR = "2012"
}
@BOOK{bfmea, @BOOK{bfmea,
AUTHOR = "Robin E McDermot et all", AUTHOR = "Robin E McDermot et all",
TITLE = "The Basics of FMEA ISBN: 0-527-76320-9", TITLE = "The Basics of FMEA ISBN: 0-527-76320-9",
@ -240,6 +248,12 @@ methodology",
YEAR = "2002" YEAR = "2002"
} }
@BOOK{kandr,
AUTHOR = "Kernighan,Ritchie",
TITLE = "The C programming Language 2nd edition",
PUBLISHER = "Prentise Hall",
YEAR = "1988"
}
@BOOK{probstat, @BOOK{probstat,
AUTHOR = " M~R~Spiegel", AUTHOR = " M~R~Spiegel",

128
papers/software_fmea/software_fmea.tex
View File

@ -172,13 +172,19 @@ With these definitions we can apply FMEA
to existing software\footnote{Existing software excluding recursive code, and unstructured non-functional languages}. to existing software\footnote{Existing software excluding recursive code, and unstructured non-functional languages}.
} }
\section{FMEA Process} \section{FMEA Background}
%What FMEA is, briefly variants... %What FMEA is, briefly variants...
Failure Mode effects Analysis is the process of taking Failure Mode effects Analysis is the process of taking
component failure modes, and by reasoning, tracing their effects through a system component failure modes, and by reasoning, tracing their effects through a system
and determining what system level failure modes could be caused. and determining what system level failure modes could be caused.
FMEA dates from the 1940s where simple electro-mechanical systems were the norm.
Modern control systems nearly always have a significant software/firmware element,
and not being able to model software with current FMEA methodologies
is a cause for criticism~\cite{easw}~\cite{safeware}~\cite{bfmea}.
Several variants of FMEA exist, Several variants of FMEA exist,
traditional FMEA being a associated with the manufacturing industry, with the aims of prioritising traditional FMEA being a associated with the manufacturing industry, with the aims of prioritising
@ -203,13 +209,17 @@ all the above variants of FMEA.
\section{Modularising FMEA} \section{Modularising FMEA}
In outline, in order to modularise FMEA, we must create small modules form the bottom-up. In outline, in order to modularise FMEA, we must create small modules from the bottom-up.
We can do this by taking collections of base~components that We can do this by taking collections of base~components that
perform (ideally) a simple and well defined task. perform (ideally) a simple and well defined task.
%
We can call these {\fgs}. We can then analyse the failure mode behaviour of a {\fg} We can call these {\fgs}. We can then analyse the failure mode behaviour of a {\fg}
using all the failure modes of all its components. using all the failure modes of all its components.
%
When we have its failure mode behaviour, or the symptoms of failure from the perspective of the {\fg}, When we have its failure mode behaviour, or the symptoms of failure from the perspective of the {\fg},
we now treat the {\fg} as a {\dc}; where the failure modes of the {\dc} are the symptoms of failure of the {\fg}. we now treat the {\fg} as a {\dc}; where the failure modes of the {\dc} are the symptoms of failure of the {\fg}.
%
%
We can now use {\dcs} to build higher level {\fgs} until we have a complete hierarchical model We can now use {\dcs} to build higher level {\fgs} until we have a complete hierarchical model
of the failure mode behaviour of a system. An example of this process, applied to an inverting op-amp configuration of the failure mode behaviour of a system. An example of this process, applied to an inverting op-amp configuration
is given in~\cite{syssafe2011}. is given in~\cite{syssafe2011}.
@ -297,12 +307,16 @@ of typical modern safety critical systems.
With modular FMEA (FMMD) we have the concepts of failure~modes With modular FMEA (FMMD) we have the concepts of failure~modes
of components, {\fgs} and symptoms of failure for a functional group. of components, {\fgs} and symptoms of failure for a functional group.
A programmatic function is very similar to a functional group. A programmatic function is very similar to a f via hardware interactionunctional group.
It calls other functions, and uses data sources, which could be viewed as its `components'. It calls other functions, and uses data sources via hardware interaction, which could be viewed as its `components'.
It has outputs which will be used by functions that may call it. It has outputs which will be used by functions that may call it.
map the FMMD concepts of {\fms}, {\fgs} and {\dcs}
However, we need to define a clear concept of failure modes of a function in order to to software functions.
map FMMD to software. %
%However, we need to map a the FMMD concepts of {\fms}, {\fgs} and {\dcs}
to software functions.
% failure modes of a function in order to
%map FMMD to software.
\subsection{Software, a natural hierarchy} \subsection{Software, a natural hierarchy}
@ -317,25 +331,30 @@ functions that interact with hardware/electronics.
Contract programming is a discipline~\cite{dbcbe} for building software functions in a controlled Contract programming is a discipline~\cite{dbcbe} for building software functions in a controlled
and traceable way. Each function is subject to pre-conditions (constraints on its inputs), and traceable way. Each function is subject to pre-conditions (constraints on its inputs),
post-conditions (constraints on its outputs) and function wide invariants (rules). post-conditions (constraints` on its outpu'ts) and function wide invariants (rules).
\paragraph{Mapping contract pre-condition violations to failure modes} \paragraph{Mapping contract `pre-condition' violations to failure modes}
A precondition, or requirement for a contract software function A precondition, or requirement for a contract software function
defines the correct ranges of input conditions for the function defines the correct ranges of input conditions for the function
to operate successfully. to operate successfully.
For a software function, a violation of a pre-condition is For a software function, a violation of a pre-condition is
in effect a failure mode of one of its components. in effect a failure mode of `one of its com'ponents.
\paragraph{Mapping contract post-condition violations to symptoms} \paragraph{Mapping contract `post-condition' violations to symptoms}
A post condition is a definition of correct behaviour by a function. A post condition is a definition of correct behaviour by a function.
This could be an action performed or an output value.
A violated post condition is a symptom of failure of a function. A violated post condition is a symptom of failure of a function.
Post conditions could be either actions performed (i.e. the state of hardware changed) or an output value of a function.
\paragraph{Mapping contract `invariant' violations to symptoms and failure modes}
Invariants in contract programming may apply to inputs to the function (where the can be considered {\fms} in FMMD terminology),
and to outputs (where the can be considered {failure symptoms} in FMMD terminology).
\subsection{Software FMEA} \subsection{Software FMEA}
@ -343,18 +362,29 @@ A violated post condition is a symptom of failure of a function.
Consider a function that reads a {\ft} input, and returns a value between 0 and 999 (i.e. per mil $\permil$) Consider a function that reads a {\ft} input, and returns a value between 0 and 999 (i.e. per mil $\permil$)
representing the current detected with an error indication flag . representing the current detected with an additional error indication flag .
Let us assume the {\ft} detection is via a \ohms{220} resistor., and that we read a voltage Let us assume the {\ft} detection is via a \ohms{220} resistor., and that we read a voltage
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 a voltage, we use ohms law~\cite{aoe} to determine the voltage ranges: $V=IR$, $0.004A * \ohms{220} = 0.88V$
and $0.020A * \ohms{220} = 4.4V$. Our acceptable voltage range is therefore $V >= 0.88 \wedge V<= 4.4$. and $0.020A * \ohms{220} = 4.4V$.
%
Our acceptable voltage range is therefore $V >= 0.88 \wedge V<= 4.4$.
This voltage range forms our input requirement. This voltage range forms our input requirement.
We can now examine software function. For the purpose of example the `C' programming language is used. %
We assume a function {\em read\_ADC()} which returns a double precision We can now examine a software function that performs a conversion from the voltage read to
value which holds the voltage read. a per~mil representation of the {\ft} input current.
{\vbox{ %
or the purpose of example the `C' programming language is used.
We initially assume a function \textbf{read\_ADC} which returns a floating point %double precision
value which holds the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}).
%%{\vbox{
\begin{figure}
\footnotesize \footnotesize
\begin{verbatim} \begin{verbatim}
/* Software function to read 4mA to 20mA input */ /* Software function to read 4mA to 20mA input */
@ -384,22 +414,28 @@ int read_4_20_input ( int * value ) {
return error_flag; return error_flag;
} }
\end{verbatim} \end{verbatim}
} %}
} %}
\label{fig:code_read_4_20_input}
\caption{Software Function: \textbf{read\_4\_20\_input}}
\label{fig:420i}
\end{figure}
Note that the function above calls another, `read\_ADC', which returns a We now look at the function called by \textbf{read\_4\_20\_input}, \textbf{read\_ADC}, which returns a
voltage for a given ADC channel. This function voltage for a given ADC channel. This function
deals directly with the hardware in the micro-controller we are running the software on. deals directly with the hardware in the micro-controller we are running the software on.
Its job is to select the correct channel (ADC multiplexer) and then to initiate a Its job is to select the correct channel (ADC multiplexer) and then to initiate a
conversion by setting an ADC 'go' bit. conversion by setting an ADC 'go' bit (see code sample in figure~\ref{code_read_ADC}).
It takes the raw ADC reading and converts it into a floating point\footnote{the type, `double' or `double precision', is a standard C language floating point type~\cite{kandr}.}
voltage value.
%{\vbox{
\begin{figure}
{\vbox{ \label{fig:code_read_ADC}
\footnotesize \footnotesize
\begin{verbatim} \begin{verbatim}
/* Software function to read voltage from a */ /* Software function to read voltage from a */
@ -440,8 +476,10 @@ double read_ADC( int channel ) {
return dval; return dval;
} }
\end{verbatim} \end{verbatim}
} \caption{Software Function: \textbf{read\_ADC}}
} \end{figure}
%}
%}
We now have a very simple software structure, a call tree, shown in figure~\ref{fig:ct1}. We now have a very simple software structure, a call tree, shown in figure~\ref{fig:ct1}.
@ -477,15 +515,23 @@ $$ fm(R) = \{OPEN,SHORT\}. $$
For the ADC we can determine the following failure modes: For the ADC we can determine the following failure modes:
$$ fm(ADC) = \{ STUCKAT, MUXFAIL, LOWOUT, HIGHOUT \}. $$ \begin{itemize}
\item STUCKAT --- The ADC outputs a constant value,
\item MUXFAIL --- The ADC cannot select its input channel correctly,
\item LOW --- The ADC output is always LOW, or zero ADC counts,
\item HIGH --- The ADC output is always HIGH, or max ADC counts.
\end{itemize}
With these failure modes, we can analyse our first functional group. We can use the function $fm$ to define the {\fms} of an ADC thus:
$$ fm(ADC) = \{ STUCKAT, MUXFAIL,LOW, HIGH \}. $$
With these failure modes, we can analyse our first functional group, see table~ref{tbl:cmatv}.
{ {
\tiny \tiny
\begin{table}[h+] \begin{table}[h+]
\caption{CMATV: Failure Mode Effects Analysis} % title of Table \caption{CMATV: Failure Mode Effects Analysis} % title of Table
\label{tbl:phs225amp} \label{tbl:cmatv}
\begin{tabular}{|| l | c | l ||} \hline \begin{tabular}{|| l | c | l ||} \hline
\textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
@ -507,8 +553,8 @@ With these failure modes, we can analyse our first functional group.
4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\ 4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\
& wrong channel & \\ \hline & wrong channel & \\ \hline
5: $ADC_{LOWOUT}$ & output low & $LOW$ \\ 5: $ADC_{LOW}$ & output low & $LOW$ \\
6: $ADC_{HIGHOUT}$ & output high & $HIGH$ \\ \hline 6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline
\hline \hline
@ -561,7 +607,7 @@ We can now analyse this hardware/software combined {\fg}.
\tiny \tiny
\begin{table}[h+] \begin{table}[h+]
\caption{RADC: Failure Mode Effects Analysis} % title of Table \caption{RADC: Failure Mode Effects Analysis} % title of Table
\label{tbl:phs225amp} \label{tbl:radc}
\begin{tabular}{|| l | c | l ||} \hline \begin{tabular}{|| l | c | l ||} \hline
\textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
@ -630,7 +676,7 @@ We can now form a functional group with the {\dc} $RADC$ and the software compon
\tiny \tiny
\begin{table}[h+] \begin{table}[h+]
\caption{Read\_4\_20: Failure Mode Effects Analysis} % title of Table \caption{Read\_4\_20: Failure Mode Effects Analysis} % title of Table
\label{tbl:phs225amp} \label{tbl:r420i}
\begin{tabular}{|| l | c | l ||} \hline \begin{tabular}{|| l | c | l ||} \hline
\textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
@ -705,12 +751,22 @@ The derived component representing the {\ft} reader
in software shows that by taking a modular approach for FMEA, we can integrate in software shows that by taking a modular approach for FMEA, we can integrate
software and electro-mechanical FMEA models. software and electro-mechanical FMEA models.
We now have a {\dc} for a {\ft} input in software.
Typically, more than one such input could be present in a real-world system.
Not only have we integrated electronics and software in an FMEA, we can also
re-use the analysis for each {\ft} input in the system.
The unsolved symptoms, or unobservable errors, i.e. $VAL\_ERR$ could be addressed The unsolved symptoms, or unobservable errors, i.e. $VAL\_ERR$ could be addressed
by another software function to read other known signals by another software function to read other known signals
via the MUX (i.e. voltage references). This strategy would via the MUX (i.e. voltage references). This strategy would
detect ADC STUCK AT and MUX FAIL failure modes. detect ADC STUCK AT and MUX FAIL failure modes.
%
Detailing this however, is beyond the scope %and page-count
of this paper.
Detailing this however, is beyond the scope and page-count of this paper.
%Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!! %Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!!