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 %% will react and how to interpret readings---but they do not
%% always cover the failure modes of the hardware being interfaced too. %% always cover the failure modes of the hardware being interfaced too.
% %
When we have analysed a software function---using failure conditions When we have analysed a
of its inputs as failure modes---we can 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). 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. 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 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} to form a {\fg}.
and have its failure mode symptoms, we can create a {\dc}. That {\dc} can be %
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 used by functions that call the function we have just analysed, until
we form a complete failure mode hierarchy of the system under investigation. we form a complete failure mode hierarchy of the system under investigation.
% map the FMMD concepts of {\fms}, {\fgs} and {\dcs} % 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 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}. {\fms}~\cite{fmd91}~\cite{mil1991}~\cite{en298}. %~\cite{en61508}~\cite{en298}.
With software only some library functions are well known and rigorously documented With software only some library functions are well known and rigorously documented
enough to have the equivalent of known failure modes. enough to have the equivalent of known failure modes,
Most software is `bespoke'. most software is `bespoke'.
% %
We need a different strategy to We need a different strategy to
describe the failure mode behaviour of software functions. describe the failure mode behaviour of software functions, %.
We can use definitions from contract programming to assist here. %We
and
can use definitions from contract programming to assist. % here.
\subsection{Contract programming description} \subsection{Contract programming description}
@ -162,9 +168,14 @@ violations could simply occur.
\paragraph{Mapping contract `invariant' violations to symptoms and failure modes.} \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), 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} \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} The diagram in figure~\ref{fig:ftcontext}, shows some equipment which is sending a {\ft}
signal to a micro-controller system. 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. an ADC and its multiplexer.
With the voltage determined at the ADC, we read the intended quantitative With the voltage determined at the ADC, we read the intended quantitative
value from the external equipment. 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} \label{fig:ct1}
\end{figure} \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. 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. 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$ \\ 5: $ADC_{LOW}$ & output low & $LOW$ \\
6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline 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 \hline
@ -490,7 +504,7 @@ which we can call $ CHAN\_NO $.
The reference voltage for the ADC has a 0.1\% accuracy requirement. The reference voltage for the ADC has a 0.1\% accuracy requirement.
% %
If the reference value is outside this, it is also a {\fm} 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). only if we specifically use a test input to measure the reference).
Taken as a component for use in FMEA/FMMD our function has 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 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 \hline
@ -675,7 +690,9 @@ as a hierarchical diagram, see figure~\ref{fig:eulerswhw}. % see figure~\ref{fig
The {\dc} representing the {\ft} reader The {\dc} representing the {\ft} reader
in software shows that by FMMD, we can integrate 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 With this analysis
we have a complete `reasoning~path' linking the failures modes from the we have a complete `reasoning~path' linking the failures modes from the
electronics to those in the software. 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 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. 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 by another software function to read other known signals
via the MUX (i.e. voltage references). This strategy would via the MUX (i.e. voltage references). This strategy would
detect ADC\_STUCK\_AT and MUX\_FAIL failure modes. detect ADC\_STUCK\_AT and MUX\_FAIL failure modes.
@ -773,7 +792,7 @@ start with a structured analysis `Yourdon' context diagram~\cite{Yourdon:1989:MS
\end{figure} \end{figure}
Using figure~\ref{fig:context_diagram_PID} we review the system in terms of its data flow, starting 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. 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 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}. Most micro-controllers feature several general purpose timers~\cite{pic18f2523}.
We can use an internal timer in conjunction with the monitor function 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.} \paragraph{Data flow model to programmatic call tree.}
The Yourdon methodology also gives us a guide as to which software 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 HEATER --- Heating element, essentially a resistor.
\item Pt100 --- Pt100 Temperature sensor, as analysed in section~\ref{sec:Pt100}. \item Pt100 --- Pt100 Temperature sensor, as analysed in section~\ref{sec:Pt100}.
\item PWM --- Internal micro controller pulse width modulation module \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 LEDs --- Indication LEDs via GPIO
\item micro-controller --- the medium for running the software \item micro-controller --- the medium for running the software
\end{itemize} \end{itemize}
@ -985,7 +1004,7 @@ This gives us a {\dc} which we call ReadPt100.
FC4: $RADC_{LOW}$ & ADC may read & $VOLTAGE\_LOW$ \\ \hline FC4: $RADC_{LOW}$ & ADC may read & $VOLTAGE\_LOW$ \\ \hline
FC5: post condition fails & software failure & $VAL\_ERR$ \\ FC5: post condition fails & software failure & $VAL\_ERR$ \\
in function read\_ADC & & \\ \hline in function read\_ADC & read\_ADC & \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
@ -1060,7 +1079,7 @@ We can call the resulting {\dc} Get\_Temperature.
& incorrect temperature & \\ \hline & incorrect temperature & \\ \hline
FC5: post condition fails & software failure & temp\_incorrect \\ 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 \hline
@ -1111,8 +1130,8 @@ an incorrect error value.
& unobservable & \\ & unobservable & \\
& undetectable failure mode & \\ \hline & undetectable failure mode & \\ \hline
FC3: post condition fails & software failure & IncorrectErrorValue \\ FC3: post condition fails & software failure & IncorrectErrorValue \\
in function determine\_set\_point\_error & & \\ \hline in function determine\_set\_point\_error & determine\_set\_point\_error & \\ \hline
\end{tabular} \end{tabular}
@ -1177,7 +1196,7 @@ being the logic and process of the failure mode analysis.
FC3: post condition fails & software failure & IncorrectControlErrorV \\ FC3: post condition fails & software failure & IncorrectControlErrorV \\
in function PID & & \\ \hline in function PID & PID & \\ \hline
\end{tabular} \end{tabular}