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

Got to look at appendix A its a bit ropey

Browse Source
This commit is contained in:
Robin Clark 2013-09-26 20:05:48 +01:00
parent 35078d32b8
commit a64abda4ec
3 changed files with 91 additions and 72 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
submission_thesis/CH2_FMEA/copy.tex
View File

@ -780,7 +780,7 @@ looking at a {\fm}'s effects on all other components in the system. % be necessa
%
In practise, a compromise is made between the amount of time/money that can be spent
on analysis relative to the criticality of the project.
Metrics from measuring the amount of work to undertake for FMEA are examined in section~\ref{sec:xfmea}.
Metrics for measuring the amount of work to undertake for FMEA are examined in section~\ref{sec:xfmea}.
\paragraph{Failure Modes and the signal path.}
\fmmdglossSIGPATH

129
submission_thesis/CH6_Software_Examples/software.tex
View File

@ -53,7 +53,7 @@ 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 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.
@ -105,8 +105,8 @@ 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, %.
definitions from contract programming can be used to assist in this. % here.
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
@ -254,10 +254,9 @@ value from the external equipment is read.
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.
%
From figure~\ref{fig:ftcontext} the {\ft} detection is via a \ohms{220} resistor and the a voltage is read
from an ADC into the software.
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 {\ft}
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
@ -275,16 +274,17 @@ This voltage range forms an input requirement and can be considered as an invari
i.e. both a pre-condition and a postcondition;
for the system to be operating correctly the voltage should be within the above bounds.
%
The software function that performs a conversion from the voltage read to
a per~mil representation of the {\ft} input is now discussed.
%
For the purpose of example the `C' programming language~\cite{DBLP:books/ph/KernighanR88} is used.
%
A 'C' function is declared with parenthesis to
In 'C' a function is declared with parenthesis to
differentiate it from other type of variables (data types or pointers).
%
In this document this format is borrowed, hence the C~language
function called `main' will 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 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@ -298,7 +298,7 @@ value which it returns via a pointer. The source code is presented in figure~\re
%
%
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_4_20_input}).
value which represents the voltage read (see code sample in figure~\ref{fig:code_read_ADC}).
%%{\vbox{
@ -344,15 +344,15 @@ int read_4_20_input ( int * value ) {
\label{fig:code_read_4_20_input}
%\label{fig:420i}
\end{figure}
\clearpage
%\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}).
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
@ -420,7 +420,7 @@ A very simple software structure, a call tree, shown in figure~\ref{fig:ct1} has
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.
%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.
@ -433,7 +433,7 @@ 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}
\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).
@ -441,14 +441,14 @@ 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:
@ -539,10 +539,16 @@ 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. Therefore it can be treated as a generic component, $\cf{Read\_ADC}$,
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 \} $$
$$ fm(\cf{Read\_ADC}) = \{ CHAN\_NO, VREF, VV\_ERR \} $$
%
With the failure mode model for our 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} \}$.
@ -580,9 +586,12 @@ This {\fg} is analysed in table~\ref{tbl:radc}. %{ hardware/software combined {\
%
%
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}.
$\{ 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}:
@ -595,7 +604,7 @@ This {\dc} is a hybrid of software and hardware, and is an example of a hardware
%
%
%
\paragraph{Functional Group - Software - voltage to per mil - VTPM }
\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
@ -667,7 +676,8 @@ The $VAL\_ERR$ will simply mean that the value read is incorrect: an undetectabl
and therefore undesirable condition.
%
Finally a {\dc} is created to represent a failure mode model for our
combined hardware and software {\ft} input failure mode model.
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:
%
@ -739,14 +749,15 @@ 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.
%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 MUX (i.e. voltage references).
via the multiplexer (MUX) (i.e. voltage references).
%
This strategy would
detect ADC\_STUCK\_AT and MUX\_FAIL failure modes. Where the integrity of
@ -755,8 +766,8 @@ the MUX is very demanding, separate pull down test lines may be implemented on t
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}.
\\
%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}.
@ -790,7 +801,7 @@ The {\ft} example above is based on the paper presented to System Safety in 2012
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 a first order differential problem, and is often
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
@ -940,7 +951,7 @@ With the set point error value the \cf{PID} function will return an output contr
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 PWM.
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.
%
@ -949,7 +960,7 @@ By using the Yourdon methodology a programmatic design frame-work i.e. a call tr
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 applied.
These are listed, and from the bottom-up, FMMD analysis is begun.
%
\clearpage
\subsection{FMMD Analysis of PID temperature Controller}
@ -1046,18 +1057,19 @@ 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 start at the lowest level, i.e. the electronics.
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 a system.
by definition the lowest levels in the system.
%
The input, or afferent data flow can be followed to find the bottom levels for system inputs
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
@ -1069,9 +1081,12 @@ This gives a {\dc}, %which we call
`Read\_Pt100' (see appendix~\ref{sec:readPt100}).
%
%
%
The {\dc} Read\_Pt100 is a failure mode model of the \cf{Read\_ADC} software function and the Pt100
hardware, this has the following failure modes:
%
%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 \}. $$
%
@ -1093,14 +1108,12 @@ The pre-conditions for the function are that:
\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.
%
Note that a temperature outside the pre-defined range would be detected as an acceptable voltage
failure.
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.
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}.
@ -1108,7 +1121,7 @@ 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}.
%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:
@ -1128,16 +1141,21 @@ 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}).
%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}).
%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 thus has two variants, an incorrect value that is detected, KnownIncorrectErrorValue
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.
%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}.
%
@ -1277,7 +1295,7 @@ FMMD analysis is applied to this {\fg} in table~\ref{tbl:ledoutput}.
\end{figure}
%
%
Our {\dc} for the setLED function, GPIO and LEDs has the following failure modes:
The {\dc} for the setLED function, GPIO and LEDs has the following failure modes:
$$ fm(LEDoutput) = \{FailureIndicated, IndicationError \} $$
%
%
@ -1306,6 +1324,7 @@ The final FMMD stage forms a {\fg} with the {\dcs}
determined previously:
%
\begin{itemize}
\item the micro-controller,
\item PID,
\item HeaterOutput,
\item LEDoutput,
@ -1340,7 +1359,7 @@ as an Euler diagram in figure~\ref{fig:euler_temp_controller}.
The PID temperature control example above, shows that complete hybrid software/electronic systems can be
modelled using FMMD.
%
The analysis has revealed system level failure modes that are un-handled and some that are undetectable.
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
%
@ -1363,8 +1382,8 @@ For instance, measures may included to validate the processor clocking with an e
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 failure could lead to a
system failure, something difficult to prove with current FMEA techniques.
%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.

32
submission_thesis/appendixes/detailed_analysis.tex
View File

@ -766,10 +766,10 @@ FMMD analysis tables from chapter~\ref{sec:chap6}.
\tiny
\begin{table}[h+]
\center
\caption{ standalone temperature controller: Failure Mode Effects Analysis} % title of Table
\caption{Standalone temperature controller: Failure Mode Effects Analysis} % title of Table
\label{tbl:pid}
\begin{tabular}{|| l | c | l ||} \hline
\begin{tabular}{|| l | l | l ||} \hline
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
\hline
@ -778,33 +778,33 @@ FMMD analysis tables from chapter~\ref{sec:chap6}.
\hline
FC1: PID KnownControlValueError & As error is detectable/ & ControlFailureIndicated \\
& observable error can be indicated & \\ \hline
FC1: PID KnownControlValueError & As error is detectable & ControlFailureIndicated \\
& error can be indicated & \\ \hline
FC2: PID IncorrectControlerrorV & undetectable/unobservable & ControlFailure \\
& failure PID will not control properly & \\ \hline
FC2: PID IncorrectControlerrorV & undetectable failure: & ControlFailure \\
& PID will not control properly & \\ \hline
FC3: HeaterOutput & Heater will constantly & ControlFailureIndicated \\
HeaterOnFULL & apply maximum power & \\ \hline
FC4: HeaterOutput & heater will supply & ControlFailureIndicated \\ \hline
HeaterOFF & no power & \\
FC4: HeaterOutput & no power & ControlFailureIndicated \\
HeaterOFF & supplied to heater & \\ \hline
FC5: HeaterOutput & with incorrect hower applied & ControlFailure \\ \hline
HeaterOutputIncorrect & control will not be effective & \\
FC4: HeaterOutput & incorrect power levels & ControlFailure \\
HeaterOutputIncorrect & applied to heater & \\\hline
FC6: LEDOutput & failure of LED system & KnownIndicationError \\
FailureIndicated & where failure is observable & \\ \hline
FC5: LEDOutput & failure of LED system & KnownIndicationError \\
FailureIndicated & where failure is detectable & \\ \hline
FC7: LEDOutput & failure of LED system & UnknownIndicationError \\
IndicationError & where failure is unobservable & \\ \hline
FC6: LEDOutput & failure of LED system & UnknownIndicationError \\
IndicationError & where failure is undetectable & \\ \hline
%% PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED
FC8: micro-controller & un-defined behaviour & ControlFailure \\
FC7: micro-controller & un-defined behaviour & ControlFailure \\
PROM\_FAULT & & \\ \hline
FC9: micro-controller & un-defined behaviour & ControlFailure \\
@ -819,7 +819,7 @@ FMMD analysis tables from chapter~\ref{sec:chap6}.
FC12: micro-controller & processor will not run & ControlFailureIndicated \\
CLOCK\_STOPPED & indicator leds will not flash & \\ \hline
FC13: monitor: & postcondition fails & ControlFailure \\
FC8: monitor: & postcondition fails & ControlFailure \\
software fails & & \\ \hline