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

evening edit of paper

Browse Source 
waiting for supervisors to REPLY
This commit is contained in:
robin 2012-04-10 20:26:54 +01:00
parent c218ca7374
commit 4e1012d9fa
2 changed files with 61 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
papers/software_fmea/hd.dia
View File

Binary file not shown.

105
papers/software_fmea/software_fmea.tex
View File

@ -175,10 +175,10 @@ it can be applied to electrical and/or mechanical systems.
%
The hierarchical structure of software is then examined,
and definitions from contract programming are used
to define failure modes and failure symptoms in
to define failure modes and failure symptoms for
software functions.
%
With these definitions we can apply a modular form of FMEA
With these definitions we can apply the FMMD modular form of FMEA
to existing software\footnote{Existing software excluding recursive~\cite{misra}[16.2] code, and unstructured non-functional languages}.
}
@ -222,11 +222,12 @@ base component {\fms}, and translating them into system level events/failures~\c
In a complicated system, mapping a component failure mode to a system level failure
will mean a long reasoning distance; that is to say the actions of the failed component will have to be traced through
several sub-systems and the effects of other components on the way.
%
With software at the higher levels of these sub-systems
we have another layer of complication.
we have yet another layer of complication.
In order to integrate software, in a meaningful way we need to re-think the
FMEA concept of mapping a base component failure to a system level event.
FMEA concept of simply mapping a base component failure to a system level event.
One strategy would be to modularise FMEA. To break down the failure effect
@ -234,16 +235,16 @@ reasoning into small modules.
%
If we pre-analyse modules, and then they
can be combined with others, into
larger sub-systems, and eventually form a hierarchy of failure mode behaviour for the entire system.
larger sub-systems, we can eventually form a hierarchy of failure mode behaviour for the entire system.
%
With higher level modules, we can approach the level that the software re-sides in.
With higher level modules, we can reach the level that the software resides in.
%
For instance, to read a voltage into software via an ADC we rely on an electronic sub-system
that conditions the input signal and then routes it through a multiplexer to the ADC.
%
We could easily consider this electronics a module, and with a
failure mode model for it, it makes modelling the software to hardware interface
far simpler.
We could easily consider this electronics a `module', and with a
failure mode model for it, modelling the software to hardware interface
becomes far simpler.
%
The failure mode model, would give us the ways in which the signal conditioning
and multiplexer could fail. We can use this to work out how our software
@ -251,7 +252,7 @@ could fail, and with this create a modular FMEA model of the software.
\section{Modularising FMEA}
\section{Modularising FMEA: The FMMD process in more detail.}
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
@ -331,8 +332,9 @@ a theoretical system.
%
There are three functional groups comprised of
{\bcs}. These are analysed individually using FMEA.
That is to say their component failure modes are examined, and the
the ways in which the {\fgs} fail; and how its symptoms of failure are determined.
That is to say their component failure modes are examined, and thus
the ways in which the {\fgs} can fail. The ways in which a
{\fg} can fail, can be viewed as symptoms of failure for the {\fg}.
%
The `$\bowtie$' function is now applied to create {\dcs}.
These are shown in figure~\ref{fig:fmmdh} above the {\fgs}.
@ -373,8 +375,9 @@ are the failure modes of the software components (other functions it calls)
and the hardware its reads values from.
Its outputs are the data it changes, or the hardware actions it performs.
When we have analysed a software function, initially using its input failure modes
we can determine its symptoms of failure (how calling functions will see its failure mode behaviour).
When we have analysed a software function---using failure conditions
of its inputs as failure modes---we can
determine its symptoms of failure (i.e. how calling functions will see its failure mode behaviour).
We can thus apply the $\bowtie$ process to software functions, by viewing them in terms of their failure
mode behaviour. To simplify things as well, software already fits into a hierarchy.
@ -393,7 +396,7 @@ and the subsequent hierarchy. With software already written, that hierarchy is f
\subsection{Software, a natural hierarchy}
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 a direct call tree. Functions call functions
from the top down and eventually call the lowest level library or IO
functions that interact with hardware/electronics.
@ -482,7 +485,7 @@ value from the external equipment.
\subsection{Simple Software Example}
Consider a function that reads a {\ft} input, and returns a value between 0 and 999 (i.e. per mil $\permil$)
Consider a software 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 additional error indication flag .
%
Let us assume the {\ft} detection is via a \ohms{220} resistor, and that we read a voltage
@ -503,7 +506,7 @@ a per~mil representation of the {\ft} input current.
%
For 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}).
value which represents the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}).
%%{\vbox{
@ -559,7 +562,7 @@ deals directly with the hardware in the micro-controller that we are running the
Its 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}).
%
It takes the raw ADC reading and converts it into a i
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.
@ -631,7 +634,7 @@ We now have a very simple software structure, a call tree, shown in figure~\ref{
\label{fig:ct1}
\end{figure}
This software is above the hardware in the conceptual call tree---by that, 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.
%
FMEA is always a bottom-up process and so we must begin with this hardware.
@ -651,12 +654,13 @@ We now apply FMMD starting with the hardware.
This functional group contains the load resistor
and the physical Analogue to Digital Converter (ADC).
Our functional group, G is thus the set of base components $G = \{R, ADC\}$.
Our functional group, $G_1$ is thus the set of base components: $G_1 = \{R, ADC\}$.
We now determine the {\fms} of all the components in $G_1$.
For the resistor we can use a failure mode set from the literature~\cite{en298}.
Where the function $fm$ returns a set of failure modes for a given component we can state:
$$ fm(R) = \{OPEN,SHORT\}. $$
\vbox{
For the ADC we can determine the following failure modes:
\begin{itemize}
@ -665,16 +669,16 @@ For the ADC we can determine the following failure modes:
\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}
}
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}.
With these failure modes, we can analyse our first functional group, see table~\ref{tbl:cmatv}.
{
\tiny
\begin{table}[h+]
\caption{CMATV: Failure Mode Effects Analysis} % title of Table
\caption{$G_1$: Failure Mode Effects Analysis} % title of Table
\label{tbl:cmatv}
\begin{tabular}{|| l | c | l ||} \hline
@ -711,11 +715,14 @@ With these failure modes, we can analyse our first functional group, see table~r
}
We now have the symptoms for the hardware functional group, $\{ HIGH , LOW, V\_ERR \} $.
We now collect the symptoms for the hardware functional group, $\{ HIGH , LOW, V\_ERR \} $.
We now create a {\dc} to represent this called $CMATV$.
As its failure modes, are the symptoms of failure from the functional group we can now state:
$$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} $$
We can express this using the `$\bowtie$' function thus:
$$ CMATV = \; \bowtie (G_1) .$$
As its failure modes, are the symptoms of failure from the functional group we can now state:
$$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} .$$
\paragraph{Functional Group - Software - Read\_ADC - RADC}
@ -723,25 +730,31 @@ $$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} $$
The software function $Read\_ADC$ uses the ADC hardware analysed
as the {\dc} CMATV above.
We know from the contractual programming requirements, that
the function needs to be sent the correct channel number.
The code fragment in figure~\ref{fig:code_read_ADC} states pre-conditions, as
{\em/* require: a) input channel from ADC to be
in valid ADC range
b) voltage ref is 0.1\% of 5V */}.
%
From the above contractual programming requirements, we see that
the function must be sent the correct channel number.
%
A violation of this can be considered a {\fm} of the function,
which we can call $ CHAN\_NO $.
%
The reference voltage for the ADC has a 0.1\% requirement.
The reference voltage for the ADC has a 0.1\% accuracy requirement.
%
If the reference value is outside of this, it is also a {\fm}
of this function, which we can call $V\_REF$.
Taken as a component for use in FMEA/FMMD our function has
two failure modes. We can therefore treat it as a generic component, $RA$,
two failure modes. We can therefore treat it as a generic component, $Read\_ADC$,
by stating:
$$ fm(RA) = \{ CHAN\_NO, VREF \} $$
$$ fm(Read\_ADC) = \{ CHAN\_NO, VREF \} $$
As we have a failure mode model for our function, we can now use it in conjunction with
with the ADC hardware {\dc} CMATV, to form a {\fg}, where $G=\{ CMSTV, Read\_ADC \}$.
with the ADC hardware {\dc} CMATV, to form a {\fg} $G_2$, where $G_2 =\{ CMSTV, Read\_ADC \}$.
We now analyse this hardware/software combined {\fg}.
@ -750,17 +763,17 @@ We now analyse this hardware/software combined {\fg}.
{
\tiny
\begin{table}[h+]
\caption{RADC: Failure Mode Effects Analysis} % title of Table
\caption{$G_2$: Failure Mode Effects Analysis} % title of Table
\label{tbl:radc}
\begin{tabular}{|| l | c | l ||} \hline
\textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
\textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
\hline
1: $RA_{CHAN\_NO}$ & wrong voltage & $VV\_ERR$ \\
1: ${CHAN\_NO}$ & wrong voltage & $VV\_ERR$ \\
& read & \\ \hline
2: $RA_{VREF}$ & voltage & $VV\_ERR$ \\
2: ${VREF}$ & voltage & $VV\_ERR$ \\
& incorrect & \\ \hline \hline
@ -786,13 +799,13 @@ We now analyse this hardware/software combined {\fg}.
We now have the symptoms of failure for the {\fg} analysed (see table~\ref{tbl:radc})
We now collect the symptoms of failure for the {\fg} analysed (see table~\ref{tbl:radc})
as $\{ VV\_ERR, HIGH, LOW \}$. We can add as well the violation of the postcondition
for the function.
This postcondition, {\em /* ensure: value is voltage input to within 0.1\% */ },
corresponds to $VV\_ERR$, and is already in the {\fm} set for this {\fg}.
We can now create a {\dc} called $RADC$ which has the following
We can now create a {\dc} called $RADC$ thus: $$RADC = \; \bowtie(G_2)$$ which has the following
{\fms}:
$$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
@ -804,22 +817,23 @@ $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
\paragraph{Functional Group - Software - voltage to per mil - VTPM }
This function sits on top of the $RADC$ {\dc} determined above.
We look at the pre-conditions for the function $read\_4\_20\_input$ $(RI)$, % which we can call $RI$
We look at the pre-conditions for the function $read\_4\_20\_input$ , % which we can call $RI$
to determine its {\fms}.
Its pre-condition is, {\em /* require: input from ADC to be between 0.88 and 4.4 volts */}.
We can map this violation of the pre-condition, to the {\fm} VRNGE; %As this function has one pre-condition
we can state,
$$ fm(RI) = \{ VRNGE \} .$$
$$ fm(read\_4\_20\_input) = \{ VRNGE \} .$$
We can now form a functional group with the {\dc} $RADC$ and the software component $RI$, i.e. $G=\{RI, RADC\}$.
We can now form a functional group with the {\dc} $RADC$ and the
software component $read\_4\_20\_input$, i.e. $G_3 = \{read\_4\_20\_input, RADC\} $.
{
\tiny
\begin{table}[h+]
\caption{Read\_4\_20: Failure Mode Effects Analysis} % title of Table
\caption{$G_3$: Read\_4\_20: Failure Mode Effects Analysis} % title of Table
\label{tbl:r420i}
\begin{tabular}{|| l | c | l ||} \hline
@ -852,7 +866,7 @@ We can now form a functional group with the {\dc} $RADC$ and the software compon
}
The failure symptoms for the {\fg} are $\{OUT\_OF\_RANGE, VAL\_ERR\}$.
The postcondition for the function $read\_4\_20\_input$ ($R420I$), {\em /* ensure: value is proportional (0-999) to the
The postcondition for the function $read\_4\_20\_input$, {\em /* ensure: value is proportional (0-999) to the
4 to 20mA input */} corresponds to the $VAL\_ERR$ and is already in the set of failure modes.
% \paragraph{Final Functional Group}
For single failures these are the two ways in which this function
@ -861,7 +875,10 @@ The $VAL\_ERR$ will simply mean that the value read is simply wrong.
We can finally make a {\dc} to represent a failure mode model for our function $read\_4\_20\_input$ thus:
$$fm(R420I) = \{OUT\_OF\_RANGE, VAL\_ERR\}$$
$$ R420I = \; \bowtie(G_3) .$$
This new {\dc} has the following {\fms}:
$$fm(R420I) = \{OUT\_OF\_RANGE, VAL\_ERR\} .$$
%
% Using the derived components, CMATV and VTPM we create