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

AF comments implemented... still defining the D

Browse Source 
function though
This commit is contained in:
Robin Clark 2012-07-13 19:32:43 +01:00
parent 46c0c9980a
commit 59a30b38c1
1 changed files with 48 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
papers/fmmd_software_hardware/software_fmmd.tex
View File

@ -121,7 +121,7 @@ failure mode of the component or sub-system}}}
% {-\baslineskip}
% {0.5\baselineskip}
% {\normalfont\normalsize\itshape}}%
\linespread{0.94}
\linespread{0.95}
\begin{document}
%\pagestyle{fancy}
@ -301,23 +301,23 @@ of failure mode behaviour for the entire system.
With higher level modules, we can reach the level in which the software resides.
%
For instance, to read a voltage into software via an Analogue to Digital Converter (ADC) we rely on an electronic sub-system
that conditions the input signal and then routes it through a multiplexer to the ADC.
that conditions the input signal and then routes it through a multiplexer (MUX) to the ADC.
%
% up to here committed AF comments 12JUL2012
%
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.
We could easily consider this conditioning and MUX circuit `module'; with a
failure mode model defined for it modelling the software to hardware interface
becomes possible.
%
The failure mode model, would give us the ways in which the signal conditioning
This 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
could fail, and with this create a modular FMEA model of the software.
could fail, and with this develop a modular FMEA model of the software.
\section{Modularising FMEA: The FMMD process in more detail.}
\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
@ -326,10 +326,12 @@ perform (ideally) a simple and well defined task called {\fgs}.
We can then analyse the failure mode behaviour of a {\fg}
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},
we now treat the {\fg} as a {\dc}, where the failure modes of the {\dc} are the symptoms of failure of the {\fg}.
When we have its failure mode behaviour,
called the symptoms of failure from the perspective of the {\fg},
we 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 then 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
is given in~\cite{syssafe2011}.
%This methodology is called Failure Mode Modular De-Composition (FMMD).
@ -338,7 +340,7 @@ is given in~\cite{syssafe2011}.
The main aim of %Failure Mode Modular Discrimination (FMMD)
FMMD is to build a hierarchy of failure behaviour from the {\bc}
level up to the top, or system level, with analysis stages ({\fgs}) %and corresponding {\dcs}
level up to the top, or system level, with analysis stages % ({\fgs}) %and corresponding {\dcs}
between each
transition to a higher level in the hierarchy.
%
@ -358,8 +360,8 @@ we can determine its symptoms of failure.
%In fact we can call these
%the symptoms of failure for the {\fg}.
%
With these symptoms (a set of derived faults from the perspective of the {\fg})
we can now state that the {\fg}
%With these symptoms (a set of derived faults from the perspective of the {\fg})
%we can now state that the {\fg}
% (as an entity in its own right)
can fail in a number of well defined ways.
%
@ -395,10 +397,11 @@ We use the symbol `$\derivec$' to represent the creation of a derived component
from a {\fg}. This symbol is convenient for drawn hierarchy diagrams.
% % (see figure~\ref{fmmdh}).
We define the $\derivec$ function, where $\FG$ is the set of all {\fgs} and $\DC$ is the set of all {\dcs},
$ \derivec ( {\FG} ) \mapsto {\DC} .$
$ \derivec ( {\FG} ) \rightarrow {\DC} .$
We show an FMMD hierarchy in figure~\ref{fig:fmmdh}.
Using this diagram, we can follow the creation of the hierarchy in
a theoretical system.
%
%Using this diagram, we can follow the creation of the hierarchy in
%a theoretical system.
%
There are three functional groups comprised of
{\bcs}. These are analysed individually using FMEA.
@ -408,7 +411,7 @@ the ways in which the {\fgs} can fail. The ways in which a
%
The `$\derivec$' function is now applied to create {\dcs}.
These are shown in figure~\ref{fig:fmmdh} above the {\fgs}.
Now that we have {\dcs}, we can use them to form a higher level functional group.
Now that we have {\dcs}, we can use them to form a higher level {\fg}.
We apply the same FMEA process to this and can derive a top level
derived component (which has the system---or top---level failure modes).
@ -439,7 +442,7 @@ derived component (which has the system---or top---level failure modes).
Note the diagram of the FMMD hierarchy is very similar to a simple non-recursive
programmatic function call tree.
\section{Software: How can we apply FMEA}
\section{FMEA applied to Software} % : How can we apply FMEA}
%If FMEA can be applied to software we can build complete failure models
%of typical modern safety critical systems.
@ -453,7 +456,9 @@ An FMMD {\fg} is placed into a hierarchy.
%
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
on data or hardware
which will be used by functions that may call upon it.
@ -462,19 +467,20 @@ 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)
and the hardware from which it reads values.% from.
and the hardware from which it reads values. % from.
%
Its outputs are the data it changes, or the hardware actions it performs.
When we have analysed a software function---treating failure conditions
of its inputs as `{\fms}'---we can
of its inputs as {\fms}---we can
determine its symptoms of failure. % (i.e. how calling functions will see its failure mode behaviour).
%
We can thus apply the $\derivec$ function to software functions, by viewing them in terms of their failure
mode behaviour. To simplify things, software already fits into a hierarchy.
%
For electronic and mechanical systems, although we may be guided by the original designers
concepts of modularity and sub-systems in design, applying FMMD means deciding on the members for {\fgs}
concepts of modularity %and sub-systems
in design, applying FMMD means deciding on the members for {\fgs}
and the subsequent hierarchy. With software already written, that hierarchy is fixed/given.
% map the FMMD concepts of {\fms}, {\fgs} and {\dcs}
@ -495,8 +501,8 @@ Functions call functions
from the top down and eventually call the lowest level library or IO
functions that interact with hardware/electronics.
What is potentially difficult with a software function, is deciding what
are its `failure~modes', and later what are its `failure~symptoms'.
What is potentially difficult with a software function is deciding what
are its failure~modes, and later what are its failure~symptoms.
%
With electronic components, we can use literature to point us to suitable sets of
{\fms}~\cite{fmd91,mil1991,en298}.%,en61508}.%~\cite{en298}.
@ -522,8 +528,7 @@ to operate successfully.
For a software function, a violation of a pre-condition is
in effect a failure mode of `one of its components'.
%
%\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 violated post condition is a symptom of failure of a function.
@ -544,7 +549,7 @@ to supply a current signal to represent the value to be sent~\cite{aoe}[p.934].
Usually, $4mA$ represents a zero or starting value and $20mA$ represents the full scale,
and this is referred to as {\ft} signalling.
%
{\ft} has an electrical advantage as well, because the current in a loop is constant~\cite{aoe}[p.20].
{\ft} has an electrical advantage as well because the current in a loop is constant~\cite{aoe}[p.20].
Thus resistance in the wires between the source and the receiving end is not an issue
that can alter the accuracy of the signal.
%
@ -555,7 +560,7 @@ and is therefore easy to detect as an error rather than an incorrect value.
Should the driving electronics go wrong at the source end, it will usually
supply far too little or far too much current, making an error condition easy to detect.
%
At the receiving end, need a resistor to convert the
At the receiving end, one needs a resistor to convert the
current signal into a voltage that we can read with an ADC.%
%we only require one simple component to convert the
%current signal into a voltage that we can read with an ADC: the humble resistor!
@ -572,7 +577,7 @@ current signal into a voltage that we can read with an ADC.%
\end{figure}
The diagram in figure~\ref{fig:ftcontext}, shows some equipment which is sending a {\ft}
The diagram in figure~\ref{fig:ftcontext} shows some equipment which is sending a {\ft}
signal to a micro-controller system.
The signal is locally driven over a load resistor, and then read into the micro-controller via
an ADC and its multiplexer.
@ -583,7 +588,7 @@ value from the external equipment.
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 .
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
from an ADC into the software.
@ -604,7 +609,7 @@ a per~mil representation of the {\ft} input current.
For the purpose of example the `C' programming language~\cite{DBLP:books/ph/KernighanR88} is
used\footnote{ C coding examples use the Misra~\cite{misra} and SIL-3 recommended language constraints~\cite{en61508}.}.
We initially assume a function \textbf{read\_ADC} which returns a floating point %double precision
value which represents the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}).
value representing the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}).
%%{\vbox{
@ -656,7 +661,7 @@ Its job is to select the correct channel (ADC multiplexer) and then to initiate
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
floating point\footnote{the type, `double' or `double precision', is a
floating point\footnote{the type `double' or `double precision' is a
standard C language floating point type~\cite{DBLP:books/ph/KernighanR88}.}
voltage value.
@ -752,13 +757,13 @@ We start with the hardware,
and then add each of the software functions.
This forms the fault mode hierarchy represented in figure~\ref{fig:hd}.
\paragraph{Functional Group - Convert mA to Voltage - CMATV}
\paragraph{Functional Grouping - Convert mA to Voltage - (CMATV)}
This functional group contains the load resistor
This {\fg} contains the load resistor
and the physical Analogue to Digital Converter (ADC).
%
Our functional group, $G_1$ is thus the set of base components: $G_1 = \{R, ADC\}$.
Our {\fg}, $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}.
@ -829,7 +834,7 @@ As its failure modes are the symptoms of failure from the functional group we ca
$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} .$
\paragraph{Functional Group - Software - Read\_ADC - RADC}
\paragraph{Functional Group - Software - Read\_ADC - (RADC)}
The software function $Read\_ADC$ uses the ADC hardware analysed
as the {\dc} CMATV above.
@ -919,12 +924,13 @@ $ 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$ , % 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 */}.
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,
we can state
%
$ fm(read\_4\_20\_input) = \{ VRNGE \} .$
%
@ -982,7 +988,7 @@ $fm(R420I) = \{OUT\_OF\_RANGE, VAL\_ERR\} .$
% integrates FMEA's from software and eletronics
% into the same failure mode model.
We can now represent the software/hardware FMMD analysis
as a hierarchical diagram, see figure~\ref{fig:hd}.
as a hierarchical diagram; see figure~\ref{fig:hd}.
% \begin{figure}[h]
% \centering
@ -1047,7 +1053,7 @@ as a hierarchical diagram, see figure~\ref{fig:hd}.
%\clearpage
\section{Conclusion}
%
The FMMD method has been demonstrated, using an the industry standard {\ft}
The FMMD method has been demonstrated using an the industry standard {\ft}
input circuit and software.
%
The {\dc} representing the {\ft} reader