robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
6f9ff6ab59
Robin_PHD/submission_thesis/CH6_Software_Examples/software.tex
Robin Clark 6f9ff6ab59 last few first person refs found by grep
2013-09-29 22:35:46 +01:00

1425 lines
60 KiB
TeX
Raw Blame History

%%% CHAPTER 6
\label{sec:chap6}
\section{Software and Hardware Failure Mode Concepts}
\label{sec:elecsw}
%
In this chapter it is shown that FMMD can be applied to both software and electronics enabling us to build complete failure models
of typical modern safety critical systems.
%
With modular FMEA i.e. FMMD %(FMMD)
the concepts of failure~modes
of components, {\fgs} and symptoms of failure have been defined. % for a functional group.
%
A programmatic function has similar attributes to an FMMD {\fg}. % with these concepts. %a {\fg} as defined by the FMMD process.
%
An FMMD {\fg} is placed into a hierarchy, likewise
a software function is typically placed into the hierarchy of its call-tree.
%
A software function 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 other functions that may call it.
%
It is shown below that a software function can be mapped to an FMMD {\fg}: its failure modes
are the failure modes of the software components %(other functions
it calls %)
and/or the hardware from which it reads values.
Its outputs are the data it changes, or the hardware actions it performs.
%%
%% Talk about how software specification will often say how hardware
%% will react and how to interpret readings---but they do not
%% always cover the failure modes of the hardware being interfaced too.
%
When a
software function has been analysed---using failure conditions of its inputs as a source of failure modes---its symptoms of failure
can be defined (i.e. how functions that call it will see its failure mode behaviour).
%
FMMD is applied to software functions by viewing them in terms of their failure mode behaviour.
%
That is to say, using FMMD, software functions are treated like {\fgs} of electronic components.
%
%
As software already fits into a hierarchy, there one less analysis decision to make when compared
to analysing electronics.
%
For electrical and mechanical systems, although the original system designers
concepts of modularity and sub-systems in design may provide guidance,
applying FMMD means deciding on the members for {\fgs}
and the subsequent hierarchy.
%
With software already written, the hierarchies are given.
%
To apply FMMD to software, the elements used by a software function are collected along with the function itself
to form a {\fg}.
%
When the failure mode behaviour of this software {\fg} has been analysed and its failure mode symptoms collected, a {\dc} can be created.
%
That {\dc} can be
used by functions that call the function just analysed.
%
This software analysis can be applied from the bottom-up on the software call tree,
until a complete failure mode hierarchy of the system under investigation has been built.
% map the FMMD concepts of {\fms}, {\fgs} and {\dcs}
%to software functions.
%
%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.
% map the FMMD concepts of {\fms}, {\fgs} and {\dcs}
%to software functions.
%
%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}
Software written for safety critical systems is usually constrained to
be modular~\cite{en61508}[3] and non recursive~\cite{misra}[15.2]. %{iec61511}.
%
Because of this direct call trees can be assumed\footnote{A typical embedded system
will have a run time call tree, and (possibly multiple) interrupt sourced call trees.}.
%
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 applying FMMD to a software function, is deciding how to map
its component failure modes %(in electronics the failure modes of its components)---and
and its symptoms of failure in a manner compatible with the FMMD process. %(the failure modes of a function taken as a {\dc}) are.
%
With electronic components, the literature to points to suitable sets of
{\fms}~\cite{fmd91}~\cite{mil1991}~\cite{en298}. %~\cite{en61508}~\cite{en298}.
%
With software only some library functions are well known and rigorously documented
enough to have the equivalent of known failure modes,
most software is `bespoke'.
%
A different strategy is required to
describe the failure mode behaviour of software functions; %.
concepts from contract programming can be used to assist in this. % here.
\subsection{Contract programming description}
\fmmdglossCONTRACTPROG
Contract programming~\cite{dbcbe} is a discipline for building software functions in a controlled
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).
\paragraph{Mapping contract `pre-condition' violations to component failure modes.}
\fmmdglossCONTRACTPROG
A precondition, or requirement for a contract software function
defines the correct ranges of input conditions for the function
to operate successfully.
%
% C Garret said this was unclear so I have added the following two sentences.
%
%If we consider a software function to be a {\fg} in the FMMD sense, i.e.
A software function is considered to be
a collection of code, functions called and %values/
variables used.
%
In this way it is similar to an electronic circuit, which is a collection
of components connected in a specific way.
%
Using this analogy for software, the connections are the functions code, and the
called functions/variables/inputs %and variables
are the components.
%
Erroneous behaviour from called functions and variables/inputs has the same effect as component failure modes
on an electronic {\fg}.
%
%
If it is considered that %consider the
called functions and variables/inputs are the components of a function,
a modular and hierarchical failure mode model
from existing software can be built.
%
Thus for FMMD applied to software, a violation of a pre-condition is considered to be equivalent to a failure mode of `one of its components'.
\paragraph{Mapping contract `post-condition' violations to symptoms.}
\fmmdglossCONTRACTPROG
%
A post-condition is a definition of correct behaviour of a function.
%
A violated post-condition is a symptom of failure, or, in FMMD terms a derived failure mode, for a function.
%
Post conditions could relate to either actions performed (i.e. the state of hardware changed) or an output value of a function.
%
In pure contract programming, a violation of a pre-condition would cause the function to \textbf{not} be executed.
%
In implementation code, a pre-condition violation should cause
an error to be generated, and thus a post-condition to fail.
%
A function can fail for reasons other than corruption of its input data (i.e.
failure caused by variables it uses or return values from functions it calls).
%
Variables can become corrupted, by radiation affecting RAM~\cite{5488118,5963919} or
by another software function erroneously overwriting variables~\cite{swseatbelt}.
%
Current work on software FMEA generally focuses on mapping
variable corruption to failure modes~\cite{procsfmea,procsfmeadb,sfmeaauto,sfmea}.
However, errors other than variable corruption can occur.
%
For instance a microprocessor may have subtle bugs in its instruction set, or
incorrectly handled
interrupt contention~\cite{concurrency_c_tool} which could cause side effects in software.
%
For the failure mode model of any software function,
it must be considered that all failure modes defined by post-condition
violations could simply occur.
%`components'.
\paragraph{Mapping contract `invariant' violations to symptoms and failure modes.}
Invariants are conditions that are considered to be relied on throughout the execution of
a program.
%
Here they are taken to mean invariants applying to data
or conditions that the function under analysis deals with or could be affected by.
%
Invariants in contract programming may apply to inputs to the function (where violations can be considered {\fms} in FMMD terminology),
and to outputs (where violations can be considered symptoms, or derived {\fms}, in FMMD terminology).
\fmmdglossCONTRACTPROG
\subsection{Combined Hardware/Software FMMD}
For the purpose of example, a simple common safety critical industrial circuit
that is nearly always used in conjunction with a programmatic element has been chosen.
%
A common method for delivering a quantitative value in analogue electronics is
to supply a current signal to represent the value to be sent~\cite{aoe}[p.934].
%
Commonly, $4mA$ represents a zero or starting value and $20mA$ represents the full scale,
and this is referred to as {\ft} signalling\footnote{Various current ranges have been used for
value sending via electrical current, {\tenfifty}, being one other range used. However {\ft} signalling
has emerged as the industry standard over the last few decades.}.
%
Using current instead of voltage to transmit an analogue value
has intrinsic electrical safety advantages mainly due to
current being constant in a circuit (Kirchoff's current law~\cite{rdh}[p.160]).
%
What is sent as current is what will
arrive at the receiving end.
%
% Because the current in a loop is constant~\cite{aoe}[p.20],
% resistance in the wires between the source and receiving end is not an issue
% that can alter the accuracy of the signal.
% %
% %This circuit has many advantages for safety.
% If the signal becomes disconnected
% it reads $0mA$ at the receiving end: as this is outside the {\ft} range,
% 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
% supply far too little or far too much current, also making error conditions easy to detect.
% %
% At the receiving end, we only require one simple component to convert the
% current signal into a voltage that we can read with an AD---a resistor---given
% its properties defined by Ohms law. % the humble resistor!
%BLOCK DIAGRAM HERE WITH FT CIRCUIT LOOP
\begin{figure}[h]
\centering
\includegraphics[width=430pt]{./CH5_Examples/ftcontext.png}
% ftcontext.png: 767x385 pixel, 72dpi, 27.06x13.58 cm, bb=0 0 767 385
\caption{Context Diagram for {\ft} loop}
\label{fig:ftcontext}
\end{figure}
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 through a load resistor, and then read into the micro-controller via
an ADC and its multiplexer.
%
With the voltage determined at the ADC, the intended quantitative
value from the external equipment is read.
\section{Simple Software Example: Reading a \ft input into software}
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; plus an additional error indication flag.
The {\ft} input circuitry used in the example and its related software,
are accepted practise and in common use,
and therefore its failure mode behaviour is well known and understood.
%
For this reason it is a good example to use for comparing the results from FMMD analysis
with known failure mode behaviour from the field/direct experience of engineers.
%
% The failure model is then discussed and compared with heuristic knowledge of {\ft} inputs,
% circuitry and software.
% Conclusions are then presented listing the benefits and
% draw-backs of analysing the hardware/software hybrid system using FMMD,
% and FMMD is compared with traditional HFMEA and SFMEA.
%
From figure~\ref{fig:ftcontext} the {\ft} detection is via a \ohms{220} resistor and the voltage is read from an ADC into the software.
%
Because the signal is specified as {\ft}
any value outside the 4mA to 20mA range can be defined as an error condition.
%
As voltage (rather than current) is read by an ADC, Ohms law~\cite{aoe} is used to
determine the mA current detected: $V=IR$, $0.004A \times \ohms{220} = 0.88V$
and $0.020A \times \ohms{220} = 4.4V$.
%
The acceptable voltage range\footnote{For the purpose of clarity resistor tolerance has been ignored.
In a practical {\ft} reader resistor tolerance would be factored into the limits, or
`dead-bands' of $\approx \half mA$ at either end of the range would be implemented.}
is therefore
$$(V \ge 0.88) \wedge (V \le 4.4) \; .$$
This voltage range forms an input requirement and can be considered as an invariant condition
i.e. both a pre-condition and a postcondition;
for the system to be operating correctly the voltage should be within the above bounds.
%
For the purpose of example the `C' programming language~\cite{DBLP:books/ph/KernighanR88} is used.
%
In 'C' a function is declared with parenthesis to
differentiate it from other types of variables (data types or pointers).
%
In this document this format is borrowed, hence the C~language
function called `main' would be presented as \cf{main}.
%
The software function that performs a conversion from the voltage read to
a per~mil representation of the {\ft} input is now discussed.
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 26SEP2013 addition %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The function \cf{read\_4\_20\_input} takes a floating point value for the voltage read,
checks that it is within bounds, and then applies a conversion to a per-mil
value which it returns via a pointer. The source code is presented in figure~\ref{fig:code_read_4_20_input}.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 26SEP2013 addition %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%
A function \cf{read\_ADC} is assumed that returns a floating point %double precision
value which represents the voltage read (see code sample in figure~\ref{fig:code_read_ADC}).
%%{\vbox{
\begin{figure}[h+]
\footnotesize
\begin{verbatim}
/***********************************************/
/* read_4_20_input() */
/***********************************************/
/* Software function to read 4mA to 20mA input */
/* returns a value from 0-999 proportional */
/* to the current input. */
/***********************************************/
int read_4_20_input ( int * value ) {
double input_volts;
int error_flag;
/* require: input from ADC to be
between 0.88 and 4.4 volts */
input_volts = read_ADC(INPUT_4_20_mA);
if ( input_volts < 0.88 || input_volts > 4.4 ) {
error_flag = 1; /* Error flag set to TRUE */
}
else {
*value = ((input_volts - 0.88) / ( 4.4 - 0.88 )) * 999.0;
error_flag = 0; /* indicate current input in range */
}
/* ensure: value is proportional (0-999) to the
4 to 20mA input */
return error_flag;
}
\end{verbatim}
%}
%}\clearpage
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% HP48G program to verify scaling
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% << -> t
% << t .88 - 4.4 .88 - / 999 * >>
% >>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\caption{Software Function: \cf{read\_4\_20\_input}}
\label{fig:code_read_4_20_input}
%\label{fig:420i}
\end{figure}
%\clearpage
The function called by \cf{read\_4\_20\_input}, \cf{read\_ADC} is now examined; this returns a
voltage for a given ADC channel.
%
This function
deals directly with the hardware in the micro-controller on which the software is running. %software on.
%
The function \cf{read\_ADC}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}).
%
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{DBLP:books/ph/KernighanR88}.}
voltage value.
%
%
%
\begin{figure}[h+]
%
\footnotesize
\begin{verbatim}
/***********************************************/
/* read_ADC() */
/***********************************************/
/* Software function to read voltage from a */
/* specified ADC MUX channel */
/* Assume 10 ADC MUX channels 0..9 */
/* ADC_CHAN_RANGE = 9 */
/* Assume ADC is 12 bit and ADCRANGE = 4096 */
/* returns voltage read as double precision */
/***********************************************/
double read_ADC( int channel ) {
int timeout = 0;
int dval = -3.0;
/* require: a) input channel from ADC to be
in valid ADC range
b) voltage ref is 0.1% of 5V */
/* return out of range result */
/* if invalid channel selected */
if ( channnel > ADC_CHAN_RANGE )
return -2.0;
/* set the multiplexer to the desired channel */
ADCMUX = channel;
ADCGO = 1; /* initiate ADC conversion hardware */
/* wait for ADC conversion with timeout */
while ( ADCGO == 1 || timeout < 120 )
timeout++;
if ( timeout < 100 )
/* the following converts ADC12 counts to voltage */
dval = (double) ADCOUT * 5.0 / ADCRANGE;
else
dval = -1.0; /* indicate invalid reading */
/* return voltage as a floating point value */
/* ensure: value is voltage input to within 0.1% */
return dval;
}
\end{verbatim}
\caption{Software Function: \cf{read\_ADC}}
\label{fig:code_read_ADC}
\end{figure}
\clearpage
%
A very simple software structure, a call tree, shown in figure~\ref{fig:ct1} has been obtained.
%
\begin{figure}[h]
\centering
\includegraphics[width=100pt]{./CH5_Examples/ct1.png}
% ct1.png: 151x224 pixel, 72dpi, 5.33x7.90 cm, bb=0 0 151 224
\caption{Call tree for software example}
\label{fig:ct1}
\end{figure}
%
This software is above the ADC hardware in the conceptual call tree---from a programmatic perspective---%in software terms---the
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.
%
The hardware is simply a load resistor, connected across an ADC input
pin on the micro-controller and ground.
%
The resistor and the ADC module of the micro-controller are identified as
the {\bcs} in this design.
%
FMMD is now applied, from the bottom-up, starting with the hardware.
%
%
\subsection{FMMD Process}
%
\paragraph{Hardware only Functional Grouping - Convert mA to Voltage - CMATV.}
%
This {\fg}, $G_1$, contains the load resistor
and the physical Analogue to Digital Converter (ADC).
%
$G_1$ is thus a set of base components: $G_1 = \{R, ADC\}.$
It is a hardware only {\fg}.
%
%
%We now determine the {\fms} of all the components in $G_1$.
The {\fms} of all the components in the {\fg} $G_1$ are now determined.
%
For the resistor the failure mode set from the literature~\cite{en298} is used.
%
Where the function $fm$ returns a set of failure modes for a given component: % we state:
%
$$ fm(R) = \{OPEN,SHORT\}. $$
\vbox{
For the ADC the following failure modes are determined:
\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 maximum 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 defined, analysis can begin on the {\fg} $G_1$, see table~\ref{tbl:cmatv}.
{
\tiny
\begin{table}[h+]
\center
\caption{{\fg} $G_1$: Failure Mode Effects Analysis} % title of Table
\label{tbl:cmatv}
\begin{tabular}{|| l | c | l ||} \hline \hline
\textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
\textbf{cause} & \textbf{Effect} & \textbf{ } \\
\hline \hline
1: $R_{OPEN}$ & resistor open, & $HIGH$ \\
& voltage on pin high & \\ \hline
2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\
& voltage on pin low & \\ \hline \hline
3: $ADC_{STUCKAT}$ & ADC reads out & $V\_ERR$ \\
& fixed value & \\ \hline
4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\
& wrong channel & \\ \hline
5: $ADC_{LOW}$ & output low & $LOW$ \\ \hline
6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline
%
% As Chris Garrett points out there is no software involved at this stage!
%7: post-condition fails & software fails & $V\_ERR$ \\
% & \hline
\hline
\end{tabular}
\end{table}
}
%
%
Common failure symptoms are now collected for $G_1$, these being $\{ HIGH , LOW, V\_ERR \} $.
Using the common failure symptoms
a {\dc} is created, $CMATV$ (an an acronym for {\em Convert milli-amps to Voltage}).
%
%We can express this using the `$\derivec$' function thus:
%$$ CMATV = \; \derivec (G_1) .$$
%
As its failure modes are the collected symptoms of failure from the {\fg} $G_1$,
the failure modes for the new {\dc} are: %we state:
$$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} .$$
%
%
\paragraph{Software and hardware hybrid {\fg} --- RADC.}
\label{sec:readadc}
\label{readADC}
The software function \cf{Read\_ADC} uses the ADC hardware analysed
as the {\dc} CMATV above.
%
%
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, it is seen that
the function must be sent the correct channel number.
%
\fmmdglossCONTRACTPROG
%
A violation of this can be considered a {\fm} for the function,
which is termed $ CHAN\_NO $.
%
The reference voltage for the ADC has a 0.1\% accuracy requirement.
%
If the reference value is outside this, it is also a {\fm}
of this function,
which is termed $V\_REF$\footnote{The failure mode $V\_REF$ is detectable %observable
only if a test input is used to measure a high precision voltage reference.
This validates the supply voltage to the ADC.
This is common practise for safety critical readings when using an ADC.}.
%
Taken as a component for use in FMEA/FMMD the function has
two failure modes.
%Any violations of postconditions for software functions in the {\fg} $G_2$ must be added to this set.
%This postcondition, {\em /* ensure: value is voltage input to within 0.1\% */},
%causes the symptom $VV\_ERR$, which happens to already be in the {\fm} set for this {\fg}.
It can also fail its post condition, which is given the symptom $VV\_ERR$.
%
Therefore it can be treated as a generic component, $\cf{Read\_ADC}$,
by stating:
%
$$ fm(\cf{Read\_ADC}) = \{ CHAN\_NO, VREF, VV\_ERR \} $$
%
With the failure mode model for this function, it is used in conjunction
with the ADC hardware {\dc} CMATV, to form a {\fg} $G_2$, where $G_2 =\{ CMATV, \cf{Read\_ADC} \}$.
%
This {\fg} is analysed in table~\ref{tbl:radc}. %{ hardware/software combined {\fg}.
%
%
{
\tiny
\begin{table}[h+]
\center
\caption{{\fg} $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{cause} & \textbf{Effect} & \textbf{} \\
\hline
1: ${CHAN\_NO}$ & wrong voltage & $VV\_ERR$ \\
& read & \\ \hline
2: ${VREF}$ & ADC volt-ref & $VV\_ERR$ \\
& incorrect & \\ \hline \hline
3: $CMATV_{V\_ERR}$ & voltage value & $VV\_ERR$ \\
& incorrect & \\ \hline
4: $CMATV_{HIGH}$ & ADC may read & $HIGH$ \\
& wrong channel & \\ \hline
5: $CMATV_{LOW}$ & output low & $LOW$ \\ \hline
6: post-condition fails & software fails & $VV\_ERR$ \\
& C function: \cf{Read\_ADC} & \\
\hline
\hline
\end{tabular}
\end{table}
}
%
%
%
The common symptoms of failure from table~\ref{tbl:radc} are collected giving
$\{ VV\_ERR, HIGH, LOW \}$.
%
% Any violations of postconditions for software functions in the {\fg} $G_2$ must be added to this set.
% This postcondition, {\em /* ensure: value is voltage input to within 0.1\% */},
% causes the symptom $VV\_ERR$, which happens to already be in the {\fm} set for this {\fg}.
%
%
%We can now create a {\dc} called $RADC$ thus: $$RADC = \; \derivec(G_2)$$ which has the following
%{\fms}:
A {\dc} called $RADC$ is created with failure modes of:
$$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
%
%
This {\dc} is a hybrid of software and hardware, and is an example of a hardware interface modelled by FMMD.
%
%
%
%
\paragraph{Functional Group - Software - voltage to per mil - VTPM.}
%
The next function higher in the call tree is \cf{read\_4\_20\_input}:
This function calls the function \cf{Read\_ADC} which
is a member of the {\fg} from which the {\dc} $RADC$ was derived.
%
%and therefore sits on top of the {\dc} $RADC$ in the FMMD hierarchy.
%determined above.
%
The pre-conditions for the function \cf{read\_4\_20\_input} are examined % which we can call $RI$
to determine its {\fms}.
%
Its one pre-condition is, {\em /* require: input from ADC to be between 0.88 and 4.4 volts */}.
%
A violation of this pre-condition can become the {\fm} VRNGE (an acronym for Voltage Range); %As this function has one pre-condition
we state,
%
$ fm(\cf{read\_4\_20\_input}) = \{ RI_{VRNGE} \} .$
To this we add the post-condition, {\em ensure: value is proportional (0-999) to the {\ft} input},
which can be termed $VAL\_ERR$: the failure modes for \cf{read\_4\_20\_input} are now defined as:
$$ fm(\cf{read\_4\_20\_input}) = \{ RI_{VRNGE}, RI_{VAL\_ERR} \} .$$
%
\fmmdglossCONTRACTPROG
A {\fg}, $G_3$, is formed with the {\dc} $RADC$ and the
software component \cf{read\_4\_20\_input}, i.e. $G_3 = \{\cf{read\_4\_20\_input}, RADC\} $.
%
{
\tiny
\begin{table}[h+]
\center
\caption{$G_3$: \cf{Read\_4\_20}: Failure Mode Effects Analysis} % title of Table
\label{tbl:r420i}
%
\begin{tabular}{|| l | c | l ||} \hline
\hline
\textbf{Failure} & \textbf{Failure } & \textbf{Derived Component} \\
\textbf{cause} & \textbf{Effect} & \textbf{Failure Mode} \\
%
\hline
1: $RI_{VRGE}$ & voltage & $OUT\_OF\_$ \\
& outside range & $RANGE$ \\ \hline
2: $RI_{VAL\_ERR}$ & software fails & $VAL\_ERR$ \\
post-condition fails & & \\ \hline
%
3: $RADC_{VV\_ERR}$ & voltage & $VAL\_ERR$ \\
& incorrect & \\ \hline \hline
%
4: $RADC_{HIGH}$ & voltage value & $VAL\_ERR$ \\
& incorrect & \\ \hline
%
5: $RADC_{LOW}$ & ADC low voltage & $OUT\_OF\_$ \\
& so out of range & $RANGE$ \\
& i.e. $< 0.88V$ & \\
%
%
\hline
\hline
%
\end{tabular}
\end{table}
}
%
The failure symptoms for the {\fg} are $\{OUT\_OF\_RANGE, VAL\_ERR\}$.
%The postcondition for the function \cf{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
can fail. An $OUT\_OF\_RANGE$ condition will be flagged by the error flag variable, a detectable {\fm}.
The $VAL\_ERR$ will simply mean that the value read is incorrect: an undetectable {\fm}
and therefore undesirable condition.
%
Finally a {\dc} is created to represent a failure mode model for the
combined hardware and software {\ft} input. % failure mode model.
%
This can be named $ R420I $, for {\em read {\ft} input}.
%function $read\_4\_20\_input$. %thus:
%
% $$ R420I = \; \derivec(G_3) .$$
%
This {\dc} has the following {\fms}:
$$fm(R420I) = \{OUT\_OF\_RANGE, VAL\_ERR\} .$$
%
%
% Using the derived components, CMATV and VTPM we create
% a new functional group. This
% integrates FMEA's from software and eletronics
% into the same failure mode model.
%
%
%
This software/hardware FMMD analysis is represented
as a hierarchical diagram, see figure~\ref{fig:eulerswhw}. % see figure~\ref{fig:hd}.
%
% HTR 27OCT2012 % \begin{figure}[h]
% HTR 27OCT2012 % \centering
% HTR 27OCT2012 % \includegraphics[width=200pt]{./CH5_Examples/hd.png}
% HTR 27OCT2012 % % hd.png: 363x520 pixel, 72dpi, 12.81x18.34 cm, bb=0 0 363 520
% HTR 27OCT2012 % \caption{FMMD hierarchy with hardware and software elements}
% HTR 27OCT2012 % \label{fig:hd}
% HTR 27OCT2012 % \end{figure}
%
\begin{figure}[h]
\centering
\includegraphics[width=300pt]{./CH5_Examples/eulerswhw.png}
% eulerswhw.png: 510x344 pixel, 72dpi, 17.99x12.14 cm, bb=0 0 510 344
\caption{Electronics and Software shown in an integrated failure mode
model---an Euler diagram showing relationship between {\dcs} determined from electronics and software---the two outermost contours are software functions,
and the inner two are electronic {\dcs}.}
\label{fig:eulerswhw}
\end{figure}
%
\subsection{Conclusion: {\ft} Reader Software/Hardware FMMD Model}
%
The {\dc} representing the hybrid software and hardware {\ft} reader
demonstrates that FMMD can integrate
software and electrical %electro-mechanical
FMMD models.
%
With this analysis
a complete `reasoning~path' linking the failures modes from the
electronics to those in the software has been created.
%
Each {\fg} to {\dc} transition represents a
reasoning stage\footnote{Each of these reasoning stages, will have a reasoning distance
associated with it, and because {\fgs} are generally small %we can apply XFMEA
XFMEA can be applied
within those stages without undue state explosion problems.}.
%
Each reasoning stage will have an associated analysis report\footnote{Having an analysis report for each {\fg}
in a system analysed under FMMD, automatically provides a context sensitive documentation trail, improving
accessibility to anyone re-viewing or auditing the analysis.}.
%
With traditional FMEA methods the reasoning~distance is large, because
it stretches from the component failure mode to the %top---or---system
top or system level failure.
For this reason applying traditional FMEA to software stretches
the reasoning distance even further. This is exacerbated by the fact that traditional SFMEA is
performed separately from Hardware FMEA (HFMEA)~\cite{sfmea,sfmeaa}, additionally even the software/hardware
interfacing is usually treated as a separate FMEA task~\cite{sfmeainterface,embedsfmea,procsfmea}
\fmmdglossHFMEA
A {\dc} for a {\ft} input in software has now been defined.
%
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, the analysis for the {\ft} input can be re-used.
This {\dc} could thus be re-used.
%(i.e. in a typical system using this type of signalling
%we would often have several {\ft} inputs).
The unsolved symptoms, or undetectable
errors, i.e. $VAL\_ERR$ could be addressed
by another software function to read other known signals
via the multiplexer (MUX) (i.e. voltage references).
%
This strategy would
detect ADC\_STUCK\_AT and MUX\_FAIL failure modes. Where the integrity of
the MUX is very demanding, separate pull down test lines may be implemented on the germane inputs as well.
%
A software specification for a hardware interface will typically concentrate on data formats,
how to interpret raw readings, or what digital signals to apply for actuators~\cite{sfmeainterface}.
%
%Using FMMD the process naturally determines a failure model for the hardware/software interface. % as well~\cite{sfmeainterface}.
The FMMD process naturally determines failure mode models for the hardware/software interface.
\\
The {\ft} example above is based on the paper presented to System Safety in 2012~\cite{syssafe2012}.
% HTR == HATE TO REMOVE
%HTR 18NOV2012 We can represent %the hierarchy in figure~\ref{fig:hd} algebraically,
%HTR 18NOV2012 the analysis hierarchy algebraically using the `$\derivec$' function:
%HTR 18NOV2012 %using the groups as intermediate stages:
%HTR 18NOV2012 \begin{eqnarray*}
%HTR 18NOV2012 G_1 &=& \{R,ADC\} \\
%HTR 18NOV2012 CMATV &=& \;\derivec (G_1) \\
%HTR 18NOV2012 G_2 &=& \{CMATV, read\_ADC \} \\
%HTR 18NOV2012 RADC &=& \; \derivec (G_2) \\
%HTR 18NOV2012 G_3 &=& \{ RADC, read\_4\_20\_input \} \\
%HTR 18NOV2012 R420I &=& \; \derivec (G_3) \\
%HTR 18NOV2012 \end{eqnarray*}
%HTR 18NOV2012 or, a nested definition,
%HTR 18NOV2012 $$ \derivec \Big( \derivec \big( \derivec(R,ADC), read\_4\_20\_input \big), read\_4\_20\_input \Big). $$
%\section
%HTR 18NOV2012 This nested structure means that we have multiple traceable
%HTR 18NOV2012 stages of failure mode reasoning in our analysis. Traditional FMEA would have only one stage
%HTR 18NOV2012 of reasoning for each component failure mode.
\section{Closed Loop Control Hardware/Software Hybrid Example}
It is desirable to model a complete standalone system with FMMD,
not only a standalone system, but ideally a hybrid software/hardware system.
%
Temperature control is typically a first order differential problem, and is often
addressed using the Proportional Integral Differential (PID) algorithm~\cite{dcods}[p.66].
%
Traditionally this was performed in analogue electronics
with trimmer potentiometers providing the P, I and D parameters.
%
Since the introduction of digital computers, it has been possible to
implement PID in software. %pro-grammatically.
%
A PID temperature controller is presented
as a complete example of an electronic/hardware hybrid analysed using FMMD. %would mean an
%analysis of a realistic standalone system without being it becoming an un-wieldingly large task.
% % \paragraph{The PID Temperature Control Algorithm.}
% % PID control starts with a setpoint, or desired value for a process
% % (here the temperature). It reads the process value and determines an error value for it.
% % The aim of the PID controller is to minimise this error term, by setting an output value,
% % which is fed back into the process (in this example the amount of power to supply the heater).
% % The error value is integrated and multiplied by an I constant.
% % A differential of the error value is calculated and multiplied by a D constant.
% % The error value itself is multiplied by a P constant, and all three of these are added
% % to obtain the output required.
% % %
% % A mathematical description of PID with frequency domain modelling (La-Place transforms etc)
% % may be found in~\cite{dcods}[Ch.3.3].
%
\subsection{Design Stage: Implementation on a micro-controller.}
When designing a computer program it is often useful to
start with a system overview.
A structured analysis `Yourdon' context diagram~\cite{Yourdon:1989:MSA:62004} is presented below, see figure~\ref{fig:context_diagram_PID}.
%
\begin{figure}[h]+
\centering
\includegraphics[width=400pt]{./CH5_Examples/context_diagram_PID.png}
% context_diagram_PID.png: 818x324 pixel, 72dpi, 28.86x11.43 cm, bb=0 0 818 324
\caption{Yourdon Context Diagram for a standalone micro-processor implemented PID Temperature Controller.}
\label{fig:context_diagram_PID}
\end{figure}
%
Using figure~\ref{fig:context_diagram_PID} the system in terms of its data flow is reviewed, starting
with the data sources (the Pt100 temperature sensor inputs) and the data sinks (the heater output and the LED indicators).
%
There are two voltage inputs (see section~\ref{sec:Pt100}) from the Pt100 temperature sensor.
%
For the Pt100 sensor, the voltages it outputs are read and %for
this requires an ADC and MUX.
%
\fmmdglossADC
%
For the output, a Pulse Width Modulator (PWM) can be used (this is a common module found on micro-controllers
facilitating
variable power output~\cite{aoe}[p.360]).
%
PWM's ADC's and MUX's are commonly built into cheap micro-controllers~\cite{pic18f2523}[Ch.15].
%
%and add more detail, see figure~\ref{fig:context_diagram2_PID}.
\begin{figure}[h]+
\centering
\includegraphics[width=400pt]{./CH5_Examples/context_diagram2_PID.png}
% context_diagram_PID.png: 818x324 pixel, 72dpi, 28.86x11.43 cm, bb=0 0 818 324
\caption{Yourdon data flow diagram for PID Temperature Controller identifying initial processing nodes.}
\label{fig:context_diagram2_PID}
\end{figure}
%
\clearpage
%
The Yourdon methodology provides model refinement, by zooming into data transform bubbles, analysing them in more
depth and creating more paths and transform bubbles which further define the data flow and processing. % required.
%
The Yourdon diagram is refined, by adding detail to both the afferent data flow coming through the MUX and ADC on the micro-controller and the efferent
channelled through a PWM module. %again built into the micro-controller,
%
This next stage of model refinement is shown in figure~\ref{fig:context_diagram2_PID}.
%
The controlling software is then further refined, by looking at or zooming into transform bubbles
and adding more detail i.e. following the data streams through the process, additional transform bubbles are created as required.
%
The lines connecting the `transform~bubbles' define the data passed between them.
%
When the data flow analysis is finished, each transform bubble represents a software function.
%
Because the connecting lines define the data passed between transform bubbles,
the inputs and outputs of the associated software functions are also defined.
%
The Yourdon methodology thus allows the refinement and modelling
of a process from a data~flow perspective
defining software functions in its final stage (see figure~\ref{fig:contextsoftware}).
%, and
%this in terms of software functions.
%
In all `bare~metal'\footnote{`Bare~metal' is a term used to indicate a micro-processor
controlled system that does not use a traditional operating system. These are generally
coded in 'C' or assembly language and run immediately from power-up.}
software architectures, a rudimentary operating system is required, often referred to as the `monitor'.
%
PID, because the algorithm depends heavily on integral calculus~\cite{dcods}[Ch.3.3] is time sensitive
and it is necessary to execute it at precise intervals determined by its proportional, integral and differential (PID) coefficients.
%
Most micro-controllers feature several general purpose timers~\cite{pic18f2523}.
%
An internal timer can be used in conjunction with the monitor function
to call the PID algorithm at a regular and precise time interval. % specified interval.
%
\paragraph{Data flow model to programmatic call tree.}
The Yourdon methodology also gives guidance as to which software
functions should be called to control the process, or in `C' terms be the main function.
%
\begin{figure}[h]
\centering
\includegraphics[width=400pt]{./CH5_Examples/context_software.png}
% context_software.png: 1023x500 pixel, 72dpi, 36.09x17.64 cm, bb=0 0 1023 500
\caption{Final Yourdon data flow diagram which has defined the software functions for the PID temperature controller}
\label{fig:contextsoftware}
\end{figure}
%
Using figure~\ref{fig:contextsoftware} the transform bubble
to represent the `main' or controlling function in the software must be chosen.
%
This can be thought of as picking one bubble and holding it up.
%
The other bubbles hang underneath
forming the software call tree hierarchy, see figure~\ref{fig:context_calltree}.
%
From examining the diagram, and in common with established embedded programming practise,
this is clearly going to be the monitor function.
%
\begin{figure}[h]+
\centering
\includegraphics[width=300pt]{./CH5_Examples/context_calltree.png}
% context_calltree.png: 800x783 pixel, 72dpi, 28.22x27.62 cm, bb=0 0 800 783
\caption{Software: Yourdon data flow diagram converted to programatic call tree.}
\label{fig:context_calltree}
\end{figure}
%
%
\paragraph{Software Algorithm.}
%
The monitor function will orchestrate the control process.
%
Firstly it will examine the timer value, and when appropriate, call the \cf{PID} function.
%
The \cf{PID} function calls \cf{determine\_set\_point\_error} which calls \cf{convert\_ADC\_to\_T}
which in turn calls \cf{Read\_ADC} (the function developed in the earlier example)
which reads from hardware.
%
With the set point error value the \cf{PID} function will return an output control value to its calling
function (i.e. the PID demand which will be returned to the monitor function).
%
%On returning to the monitor function, it will return the PID demand value.
The PID demand value will be applied via the pulse width modulation (PWM) module.
%
A rudimentary closed loop control system incorporating both hardware and software has been defined.
%
By using the Yourdon methodology a programmatic design frame-work i.e. a call tree structure was obtained.
%
All the components, i.e. hardware elements and software functions
that will be used in the temperature controller are now defined.
%
These are listed, and from the bottom-up, FMMD analysis is begun.
%
\clearpage
\subsection{FMMD Analysis of PID temperature Controller}
%
To summarise from the design stage,
the electronic components identified thus far:
\begin{itemize}
\item ADCMUX --- Electronics, analysed in previous example,
\item TIMER --- Internal micro controller timer,
\item HEATER --- Heating element, essentially a resistor,
\item Pt100 --- Pt100 Temperature sensor, as analysed in section~\ref{sec:Pt100},
\item PWM --- Internal micro controller pulse width modulation module,
\item General Purpose I/O (GPIO) --- I/O used to drive LEDS, %. %source LED current
\item LEDs --- Indication LEDs via GPIO,
\item micro-controller --- the medium for running the software.
\end{itemize}
%
\subsection{Temperature Controller Hardware Elements FMMD.}
%
\paragraph{ADCMUX and Read\_ADC.}
We re-use the {\dc} from section~\ref{readADC}.
$$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
%
%
\paragraph{TIMER.}
%
The internal timer, from a programmer's perspective is a register, which when read
returns an incremented time value.
%
Essentially its a free running integer counter with an interfacing register.
%
Using two's complement mathematics, by subtracting
the time last read value, we can calculate the interval
between readings (assuming the timer has not wrapped around more than once).
%
A timer can fail by
incrementing its value at an incorrect rate, or can stop incrementing.
%
The failure modes of $TIMER$ are defined thus:
$$ fm(TIMER) = \{ STOPPED, INCORRECT\_INTERVAL \}.$$
%
\paragraph{HEATER.}
A heating element is typically some configuration of resistive wire.
It therefore has the same failure modes as a resistor:
$$fm(HEATER) = \{ OPEN, SHORT \} .$$
%
\paragraph{Pt100 Platinum Temperature Sensor.}
The Pt100 four wire configuration was analysed in section~\ref{sec:Pt100}, the {\dc} is re-used here:
$$ fm(Pt100) = \{ OUT\_OF\_RANGE \} . $$
%
%
\paragraph{PWM.}
%The PWM, in use, is a hardware register written to with an integer value~\cite{pic182523}[Ch.15].
From a programmatic perspective a PWM output is a register to which software writes
an unsigned magnitude value~\cite{pic18f2523}[Ch.15].
%
The PWM hardware module
applies this using a mark space ratio proportional to that value, providing
a means of varying the amount of power supplied.
%
When the PWM action is halted, or fails, the digital output pin associated with it
will typically be held in a high or low state.
%
The PWM has the following failure modes:
$$ fm(PWM) = \{ HIGH, LOW \}.$$
\paragraph{Micro-Controller.}
The Micro controller is a complex piece of highly integrated electronics.
%
At a minimum it would include a micro-processor with PROM and RAM
general I/O and external interrupt lines.
%
Typically there are many other I/O modules incorporated (e.g. TIMERS, UARTS, PWM, ADC, ADCMUX, CAN).
%
In this project the ADCMUX, TIMER, PWM and general purpose computing facilities are used.
%
Consider the general~computing, CLOCK, PROM and RAM failure modes:
$$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$
%
\subsection{Temperature Controller Software Elements FMMD}
Identified Software Components:
\begin{itemize}
\item --- \cf{Monitor} (which calls \cf{PID},\cf{output\_control} and \cf{setLEDS}),
\item --- \cf{PID} (which calls \cf{determine\_set\_point\_error} ),
\item --- \cf{determine\_set\_point\_error} (which calls \cf{convert\_ADC\_to\_T}),
\item --- \cf{convert\_ADC\_to\_T} (which calls \cf{read\_ADC}), % which has been analysed as the {\dc} read\_ADC which can be re-used.} % from the last example),
\item --- \cf{read\_ADC} (analysed in the previous section~\ref{sec:readadc}),
\item --- \cf{output\_control} (which sets the PWM hardware according to the PID demand value).
\end{itemize}
%
%
With the call tree structure defined (see figure~\ref{fig:context_calltree}),
a hierarchy compatible with FMMD for analysis has been obtained.
%
However, it is only the top, i.e. the software, part of the hierarchy.
%
FMMD is a bottom-up process, thus it starts with the lowest level, i.e. the electronics.
%
The Yourdon context diagram (see figure~\ref{fig:context_diagram_PID}) is useful here as its data sources and sinks are
by definition the lowest levels in the system.
%
The input, or origin of the afferent data flow can be followed to find system inputs,
and the output, or efferent flow to find the bottom level for outputs/actuators etc.
%
Starting with the afferent flow, the reading of the temperature and its conversion
to a PID calculated heater output demand is examined.
%
\subsubsection{Afferent flow FMMD analysis, Pt100, temperature, set point error, PID output demand.}
%
Staring with the afferent data flow for the temperature readings, the lowest
level in the hierarchy is found, the Pt100 sensor.
%with the software, and consider the hardware elements
%used (if any) by each software function.
%Starting
Beginning at the bottom, a {\fg} is formed with
the function \cf{read\_ADC} and the Pt100.
This gives a {\dc}, %which we call
`Read\_Pt100' (see appendix~\ref{sec:readPt100}).
%
%
%
%The {\dc} Read\_Pt100 is obtained from analysis of a {\fg} comprising of the
%\cf{Read\_ADC} software function and the Pt100 hardware.
%The {\dc} Read\_Pt100 is a failure mode model of the \cf{Read\_ADC} software function and the Pt100
%hardware, this
The {\dc} Read\_Pt100 has the following failure modes:
%
$$ fm (Read\_Pt100) = \{ VOLTAGE\_HIGH, VAL\_ERR, VOLTAGE\_LOW \}. $$
%
%
Moving along the afferent flow, the \cf{convert\_ADC\_to\_T} function is next up the hierarchy.
%
This will call \cf{Read\_ADC} twice, once for the high Pt100 value, again for the lower. % and once for to read a current sense.
%
The resistance of the Pt100 element is then calculated, and with this---using a
polynomial or a lookup table~\cite{eurothermtables}---the temperature determined.
%
\fmmdglossCONTRACTPROG
%
The pre-conditions for the function are that:
\begin{itemize}
% \item The current calculated is within pre-defined bounds i.e. Pt100\_current,
\item The lower Pt100 value is within an acceptable voltage range i.e. Pt100\_lower\_voltage,
\item The higher Pt100 value is within an acceptable voltage range i.e. Pt100\_higher\_voltage,
\item The lower and higher values agree to within a given tolerance i.e. Pt100\_high\_low\_mismatch.
\end{itemize}
%
Any violation of these pre-conditions is equivalent to a failure mode\footnote{An actual measured temperature outside the
pre-defined range would be detected as an unacceptable voltage range failure.}.
%
The post-condition is that it returns a temperature within a given tolerance to the temperature at the sensor.
%
A failure of this post-condition can be termed `temp\_incorrect'.
%
\clearpage
Applying FMMD to the {\fg} formed by \cf{Read\_Pt100} and the function \cf{convert\_ADC\_to\_T}.
gives the {\dc} {Get\_Temperature}.
%
This analysis is presented in table~\ref{tbl:gettemperature}.
%
%The analysis for the Pt100 circuit is presented in table~\ref{tbl:readPt100}.
%
%
Failure symptoms are collected and the {\dc} created with the following failure modes:
%
%
$$fm(Get\_Temperature) = \{ Pt100\_out\_of\_range, temp\_incorrect \} . $$
%\clearpage
%
%
Following the afferent flow further, the function to determine the control error value is examined.
%
This is simply the target temperature subtracted from that measured by the sensor.
%
A {\fg} is formed with the newly {\dc} Get\_Temperature
and the function \cf{determine\_set\_point\_error}.
%
The pre-condition for \cf{determine\_set\_point\_error} is that the temperature read by it
is accurate, and its post-condition is to return the correct control error value.
%
%All single failure modes from a four wire Pt100 sensor are detectable (see section~\ref{sec:singlePt100FMEA}).
%
%For most practical purposes this would suffice, but for the purpose of example
%a particular double failure scenario, potentially giving an undefined value is
%considered (see section~\ref{sec:Pt100floating}).
%
The post-condition can fail, or the temperature read could be incorrect.
%
This could be detectable (i.e. we detect a failure from the Pt100 $ Pt100\_out\_of\_range $)
or undetectable (i.e. the post condition for this function simply fails
or the failure mode $temp\_incorrect$ occurs).
%and so an incorrect value that is detected, KnownIncorrectErrorValue
%where we can detect the Pt100 value is suspect,
%and IncorrectErrorValue where there is simply
%an incorrect value but this cannot be determined (i.e. its an undetectable failure). % this.
%
This analysis is presented in table~\ref{tbl:geterror}.
%
%
%
%
Failure mode symptoms are collected and a new {\dc} GetError created
where:
$$fm(GetError) = \{ KnownIncorrectErrorValue, IncorrectErrorValue \}.$$
%
Following the afferent path the PID algorithm is next in the software call tree.
%
%Here we assume that the PID constants are fixed (i.e. are not parameters).
%
The $GetError$ {\dc} and the \cf{PID} function form a {\fg}.
%
The pre-condition for the \cf{PID} function is that
it receives the correct error value.
%
The post-condition is that it outputs correct control values.
% RESP FOR TIMEING IS ON CALLING FUNCTION AND IS A SEPARATE ERROR- TGHINK ABOUT JITTER.....
% and controll values..... Jitter might not matter, wrong int times would
% controlling function provdes context of use.
%Those familiar with the PID algorithm may realise that digital signal processing algorithms are sensitive to calling frequency.
All digital signal processing algorithms are sensitive to calling frequency, and thus should be time invariant~\cite{fpodsadsp}[p.58].
Were this function to be called at an incorrect rate, its output
could be erroneous (the differential and integral parameters would effectively have been changed).
%
However this problem is a failure mode for the consideration of the function calling it i.e. the context of use. %(see section~\ref{sec:subjectiveobjective}).
%
That is, the \cf{PID} function is called, but its calling function is responsible for the timing,
or in more general terms,
it is the calling function that sets the context for the \cf{PID} function (i.e. what it is used for).
%If this PID were to be used, say as some form of low pass filter, we could consider jitter
%for instance.
%
%In a control environment with PID, jitter would not be a significant factor.
%
%HARK THE HERALD ANGELS SING... HARK????
%
%
%
The {\dc} PID is created, see table~\ref{tbl:pidfunction}, with the following failure modes:
%
$$ fm(PID) = \{ KnownControlValueErrorV, IncorrectControlErrorV \} .$$
%
%
\begin{figure}[h]
\centering
\includegraphics[width=400pt]{./CH5_Examples/euler_afferent_PID.png}
% euler_afferent_PID.png: 1002x342 pixel, 72dpi, 35.35x12.06 cm, bb=0 0 1002 342
\caption{Euler diagram representing the hierarchy of FMMD analysis applied to the afferent branch of call tree for the PID temperature controller example.}
\label{fig:euler_afferent_PID}
\end{figure}
%
%
%
The software call tree for the afferent flow has now been modelled using FMMD;
this is represented as an Euler diagram in figure~\ref{fig:euler_afferent_PID}.
Two call tree branches remain. The LED indication branch and the
PWM/heater output.
%
\subsubsection{Efferent flow, PID demand value to PWM output}
%
The monitor function calls the \cf{output\_control} function with the PID demand.
%
The \cf{output\_control} function then sets the PWM hardware register, which causes the mark space output of the PWM module to
apply the demanded power.
%
A {\fg} with the Heating element, a PWM module and the \cf{output\_control} function is formed to model this branch
of the efferent flow.
%
This {\fg} is a hardware/software hybrid.
%
FMMD analysis is applied to this {\fg} in table~\ref{tbl:heateroutput}.
%
For the \cf{output\_control} function, there is a pre-condition that the PWM module is
configured and working, and has the correct clock frequency.
%
A second pre-condition is that the heating element is connected and working.
%
The post-condition is that it sets the correct value into the PWM register
to implement the power output demand.
%
%
%
A {\dc} is created called HeaterOutput, see table~\ref{tbl:heateroutput},
with the following failure modes:
$$fm(HeaterOutput) = \{ HeaterOnFull, HeaterOff, HeaterOutputIncorrect \} .$$
%
As an aside: the $HeaterOnFull$ failure should raise alarm bells for designers and
upon its discovery, measures may be recommended to inhibit this (such as perhaps
adding a safety relay to cut the power to the heater).
%
%
\begin{figure}[h]
\centering
\includegraphics[width=300pt]{./CH5_Examples/euler_heater_output.png}
% euler_heater_output.png: 392x141 pixel, 72dpi, 13.83x4.97 cm, bb=0 0 392 141
\caption{Euler diagram showing HeaterOutput with its two hardware components, PWM and HEATER, and its software component \cf{output\_control}.}
\label{fig:eulerheateroutput}
\end{figure}
%
%
%
%
\subsubsection{Efferent flow: LED status LEDs}
%
The status LEDS will be controlled by general purpose (GPIO) I/O pins.
%
Three LEDS could be used, one flashing with a human readable mark
space ratio representing the heater output, one flashing at a regular interval to
indicate the processor is alive and another flashing at an interval related to the temperature,
(to indicate if the temperature readings are within expected ranges).
%
Each LED should flash in normal operation, and any LED being permanently on or off
would indicate to the operator that an error had occurred.
%
The pre-condition for this function is that the GPIO
is connected to working LEDS.
%
The post-condition is that the function \cf{setLEDS} will supply correct indication by flashing the LEDs.
%
A {\fg} is formed from the GPIO, the LEDs and the software function \cf{setLEDs}.
%
FMMD analysis is applied to this {\fg} in table~\ref{tbl:ledoutput}.
%
%
%
%
%
\begin{figure}[h]
\centering
\includegraphics[width=300pt]{./CH5_Examples/euler_led_output.png}
% euler_heater_output.png: 392x141 pixel, 72dpi, 13.83x4.97 cm, bb=0 0 392 141
\caption{Euler diagram showing LEDOutput with its three LEDs and GPIO hardware elements,
and its software component setLEDS.}
\label{fig:eulerheateroutput}
\end{figure}
%
%
The {\dc} for the setLED function, GPIO and LEDs has the following failure modes:
$$ fm(LEDoutput) = \{FailureIndicated, IndicationError \} $$
%
%
\subsubsection{Final Analysis Stage: PID Temperature Controller}
%
The possibility of each software function failing its post-condition without a direct
underlying cause from one of its components has been included in each analysis stage
involving software.
%
This is because software introduces the possibility of
anything going wrong!
%
The common causes for software failing are:
\begin{itemize}
\item Value/RAM corruption typically from interrupt contention problems~\cite{concurrency_c_tool} or accidental over writing~\cite{swseatbelt},
but can be from external sources such as radiation changing bits/values at runtime~\cite{5963919, 5488118};
\item Address bus errors leading to program errors (program sequence);
\item ROM memory failures;
\item Unintended behaviour of software.
\item Electro Magnetic Compatibility (EMC) interference.
\end{itemize}
Because the software is running on a medium, that of the processor or micro-controller,
the FMMD analysis at the final or highest level (see table~\ref{tbl:pid}), must include all possible failure modes of this medium i.e.
$$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$
The final FMMD stage forms a {\fg} with the {\dcs}
determined previously:
%
\begin{itemize}
\item the micro-controller,
\item PID,
\item HeaterOutput,
\item LEDoutput,
\item the function \cf{monitor}.
\end{itemize}
%
The post-condition for the monitor function is that it implements the PID control task correctly.
\fmmdglossCONTRACTPROG
A {\dc} for the standalone temperature controller is now created, and given the name TempController.
It will have the following failure modes:
%
\begin{eqnarray*}
fm ( TempController ) = \{ ControlFailureIndicated, \\ ControlFailure, \\ KnownIndicationError, \\ UnknownIndicationError \}.
\end{eqnarray*}
%
%
The failure mode analysis of the complete PID controller is represented
as an Euler diagram in figure~\ref{fig:euler_temp_controller}.
%
%
\begin{figure}[h]
\centering
\includegraphics[width=400pt]{./CH5_Examples/euler_temp_controller.png}
% euler_temp_controller.png: 714x251 pixel, 72dpi, 25.19x8.85 cm, bb=0 0 714 251
\caption{Euler diagram of the temperature controller final analysis stage, showing the hybrid software/hardware {\dcs} and the function at the head of the call tree \cf{monitor}.}
\label{fig:euler_temp_controller}
\end{figure}
%
\subsection{Conclusion: Standalone system, PID Temperature Controller}
%
The PID temperature control example above, shows that complete hybrid software/electronic systems can be
modelled using FMMD.
%
This analysis has revealed system level failure modes that are un-handled and some that are undetectable.
The FMMD model can be traversed from undesirable top level failures to the {\bc} {\fms} that are the causes.
\fmmdglossOBS
%
This means that by using FMMD, the sub-systems which require
re-design to eliminate or reduce the likelihood of undetectable failure modes can be identified.
%
The demands of EN61508~\cite{en61508} for minimum safe failure fraction thresholds~\cite{scsh}[p.52] associated with
SIL levels, make this a desirable feature of any FMEA based methodology.
%
For the failure modes caused
by electronics, reliability statistics can be applied, and the possibilities of using higher rated
components instead of potentially expensive re-design can be simulated/modelled.
%
For software errors, it may be necessary to provide extra functions to provide self checking.
%
EN61508 high reliability software measures such as
duplication of functions with checking functions arbitrating them (diverse programming~\cite{en61508}[C.3.5]) could be applied.
%
For instance, measures may included to validate the processor clocking with an external watchdog and a simple
communications protocol. For PROM and RAM faults measures such as run-time checksums
and ram complement checking can be applied.
%
%Using FMMD in conjunction with extra safety measures it can be ensured that no single hardware failure could lead to a
%system failure, something difficult to prove with current FMEA techniques.
%OK STOP AT PID and follow the other data flows until we are ready to bring them to the top: i.e.
%
%the monitor program.......
%\clearpage
Reference in New Issue View Git Blame Copy Permalink