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

C Garrett modifications to Software Chapter

Browse Source 
Just need to move analysis tables to the appendix.
This commit is contained in:
Robin Clark 2013-03-10 15:01:29 +00:00
parent c7aff98c7e
commit b158fcb636
2 changed files with 44 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
submission_thesis/CH5_Examples/eulerswhw.dia
View File

Binary file not shown.

69
submission_thesis/CH5_Examples/software.tex
View File

@ -30,8 +30,8 @@ Its outputs are the data it changes, or the hardware actions it performs.
%% will react and how to interpret readings---but they do not
%% always cover the failure modes of the hardware being interfaced too.
%
When we have analysed a software function---using failure conditions
of its inputs as failure modes---we can
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).
%
@ -47,8 +47,12 @@ and the subsequent hierarchy.
With software already written, the hierarchies are given.
%
To apply FMMD to software, we collect the elements used by a software function, along with the function itself
to form a {\fg}. When we have analysed the failure mode behaviour of this {\fg}
and have its failure mode symptoms, we can create a {\dc}. That {\dc} can be
to form a {\fg}.
%
When we have analysed the failure mode behaviour of this {\fg}
and have its failure mode symptoms, we can create a {\dc}.
%
That {\dc} can be
used by functions that call the function we have just analysed, until
we form a complete failure mode hierarchy of the system under investigation.
% map the FMMD concepts of {\fms}, {\fgs} and {\dcs}
@ -83,12 +87,14 @@ its failure modes and symptoms are.
With electronic components, we can use literature to point us 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'.
enough to have the equivalent of known failure modes,
most software is `bespoke'.
%
We need a different strategy to
describe the failure mode behaviour of software functions.
We can use definitions from contract programming to assist here.
describe the failure mode behaviour of software functions, %.
%We
and
can use definitions from contract programming to assist. % here.
\subsection{Contract programming description}
@ -162,9 +168,14 @@ violations could simply occur.
\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 {failure modes} in FMMD terminology).
and to outputs (where violations can be considered {\fms} in FMMD terminology).
\subsection{Combined Hardware/Software FMMD}
@ -207,7 +218,7 @@ and this is referred to as {\ft} signalling which has intrinsic electrical saf
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
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, we read the intended quantitative
value from the external equipment.
@ -370,7 +381,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---from a programmatic perspective---%in software terms---the
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.
@ -447,7 +458,10 @@ With these failure modes, we can analyse our first functional group, see table~\
5: $ADC_{LOW}$ & output low & $LOW$ \\
6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline
7: post condition fails & software fails & $V\_ERR$ \\ \hline
%
% As Chris Garrett points out there is no software involved at this stage!
%7: post condition fails & software fails & $V\_ERR$ \\
% & \hline
\hline
@ -490,7 +504,7 @@ which we can call $ 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 we can call $V\_REF$ (this failure mode is observable
of this function, which we can call $V\_REF$ (this failure mode is detectable %observable
only if we specifically use a test input to measure the reference).
Taken as a component for use in FMEA/FMMD our function has
@ -540,7 +554,8 @@ We analyse this hardware/software combined {\fg}.
5: $CMATV_{LOW}$ & output low & $LOW$ \\ \hline
6: post condition fails & software fails & $VV\_ERR$ \\ \hline
6: post condition fails & software fails & $VV\_ERR$ \\
& C function: Read\_ADC & \\ \hline
\hline
@ -675,7 +690,9 @@ as a hierarchical diagram, see figure~\ref{fig:eulerswhw}. % see figure~\ref{fig
The {\dc} representing the {\ft} reader
in software shows that by FMMD, we can integrate
software and electro-mechanical FMMD models.
software and electrical %electro-mechanical
FMMD models.
%
With this analysis
we have a complete `reasoning~path' linking the failures modes from the
electronics to those in the software.
@ -698,7 +715,9 @@ 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 undetectable
%unobservable
errors, i.e. $VAL\_ERR$ could be addressed
by another software function to read other known signals
via the MUX (i.e. voltage references). This strategy would
detect ADC\_STUCK\_AT and MUX\_FAIL failure modes.
@ -773,7 +792,7 @@ start with a structured analysis `Yourdon' context diagram~\cite{Yourdon:1989:MS
\end{figure}
Using figure~\ref{fig:context_diagram_PID} we review the system in terms of its data flow, starting
with the data sources ( the Pt100 inputs) and the data syncs (the heater output and the LED indicators).
with the data sources ( the Pt100 inputs) and the data sinks (the heater output and the LED indicators).
%
We have two voltage inputs (see section~\ref{sec:Pt100}) from the Pt100 temperature sensor.
For the Pt100 sensor, we will need to read the voltages it outputs and for this
@ -812,7 +831,7 @@ and we therefore need to execute it at precise intervals determined by its propo
%
Most micro-controllers feature several general purpose timers~\cite{pic18f2523}.
We can use an internal timer in conjunction with the monitor function
to call the PID algorithm at a specified interval.
to call the PID algorithm at a regular time interval. % specified interval.
%
\paragraph{Data flow model to programmatic call tree.}
The Yourdon methodology also gives us a guide as to which software
@ -874,7 +893,7 @@ Identified electronic components:
\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 source LED current
\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}
@ -985,7 +1004,7 @@ This gives us a {\dc} which we call ReadPt100.
FC4: $RADC_{LOW}$ & ADC may read & $VOLTAGE\_LOW$ \\ \hline
FC5: post condition fails & software failure & $VAL\_ERR$ \\
in function read\_ADC & & \\ \hline
in function read\_ADC & read\_ADC & \\ \hline
\end{tabular}
\end{table}
@ -1060,7 +1079,7 @@ We can call the resulting {\dc} Get\_Temperature.
& incorrect temperature & \\ \hline
FC5: post condition fails & software failure & temp\_incorrect \\
in function convert\_ADC\_to\_T & & \\ \hline
in function convert\_ADC\_to\_T & convert\_ADC\_to\_T & \\ \hline
\hline
@ -1111,8 +1130,8 @@ an incorrect error value.
& unobservable & \\
& undetectable failure mode & \\ \hline
FC3: post condition fails & software failure & IncorrectErrorValue \\
in function determine\_set\_point\_error & & \\ \hline
FC3: post condition fails & software failure & IncorrectErrorValue \\
in function determine\_set\_point\_error & determine\_set\_point\_error & \\ \hline
\end{tabular}
@ -1177,7 +1196,7 @@ being the logic and process of the failure mode analysis.
FC3: post condition fails & software failure & IncorrectControlErrorV \\
in function PID & & \\ \hline
in function PID & PID & \\ \hline
\end{tabular}