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

CH6 1st personal pro-noun free

Browse Source
This commit is contained in:
Robin P. Clark 2013-09-13 14:46:13 +01:00
parent 3479015be8
commit 4ca0a12519
3 changed files with 166 additions and 136 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
submission_thesis/CH5_Examples/copy.tex
View File

@ -1219,6 +1219,7 @@ These show that the finer grained models also benefit from lower reasoning dista
\section{Sigma Delta Analogue to Digital Converter (\sd).} %($\Sigma \Delta ADC$)}
\label{sec:sigmadelta}
The following example is used to demonstrate FMMD analysis of a mixed analogue and digital circuit (see figure~\ref{fig:sigmadelta}).
\fmmdglossADC
\begin{figure}[h]
\centering
\includegraphics[width=300pt]{./CH5_Examples/circuit4004.png}
@ -1264,6 +1265,7 @@ It is level converted to an analogue signal by IC3---i.e. a digital 0 becomes a
and fed into the summing integrator completing the negative feedback loop.
%
In essence this implements an over-sampling one bit analogue to digital converter~\cite{ehb}[pp.729-730].
\fmmdglossADC
The output of the flip flop forms a bit pattern representing the value
of the input voltage (i.e. the value of the sum of 1's and 0's is proportional to the voltage value at the input).

294
submission_thesis/CH6_Software_Examples/software.tex
View File

@ -5,17 +5,19 @@
\section{Software and Hardware Failure Mode Concepts}
\label{sec:elecsw}
In this chapter we show that FMMD can be applied to both software and electronics enabling us to build complete failure models
%
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)
we have the concepts of failure~modes
of components, {\fgs} and symptoms of failure. % for a functional group.
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.
@ -31,9 +33,9 @@ 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 a source of failure modes---we can
determine its symptoms of failure (i.e. how functions that call it will see its failure mode behaviour).
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.
@ -41,24 +43,26 @@ FMMD is applied to software functions by viewing them in terms of their failure
That is to say, using FMMD, software functions are treated like {\fgs} of electronic components.
%
%
As software already fits into a hierarchy, we have one less analysis decision to make when compared
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 we may be guided by the original designers
concepts of modularity and sub-systems in design, applying FMMD means deciding on the members for {\fgs}
For electrical and mechanical systems, original 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, we collect the elements used by a software function, 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 we have analysed the failure mode behaviour of this {\fg}
and have its failure mode symptoms, we can create a {\dc}.
When the failure mode behaviour of this {\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 we have just analysed, until
we form a complete failure mode hierarchy of the system under investigation.
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.
%
@ -82,7 +86,7 @@ we form a complete failure mode hierarchy of the system under investigation.
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 we can assume direct call trees\footnote{A typical embedded system
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
@ -93,17 +97,16 @@ What is potentially difficult with applying FMMD to a software function, is deci
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, we can use literature to point us to suitable sets of
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'.
%
We need a different strategy to
A different strategy is required to
describe the failure mode behaviour of software functions, %.
%We
and
can use definitions from contract programming to assist. % here.
definitions from contract programming can be used to assist in this. % here.
\subsection{Contract programming description}
\fmmdglossCONTRACTPROG
@ -121,7 +124,7 @@ 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.
We can consider a software function to be
A software function is considered to be
a collection of code, functions called and %values/
variables used.
%
@ -129,20 +132,20 @@ 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 %and variables
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 we consider the
called functions and variables/inputs to be components of a function,
we can build a modular and hierarchical failure mode model
from existing software.
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, we consider a violation of a pre-condition to be
equivalent to failure mode of `one of its components'.
Thus for FMMD applied to software, a violation of a pre-condition is considered to be
equivalent a failure mode of `one of its components'.
\paragraph{Mapping contract `post-condition' violations to symptoms.}
@ -174,7 +177,7 @@ incorrectly handled
interrupt contention~\cite{concurrency_c_tool} which could cause side effects in software.
%
For the failure mode model of any software function,
we must consider that all failure modes defined by post-condition
it must be considered that all failure modes defined by post-condition
violations could simply occur.
%`components'.
@ -192,8 +195,8 @@ and to outputs (where violations can be considered symptoms, or derived {\fms},
\subsection{Combined Hardware/Software FMMD}
For the purpose of example, we chose a simple common safety critical industrial circuit
that is nearly always used in conjunction with a programmatic element.
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].
@ -242,46 +245,48 @@ The diagram in figure~\ref{fig:ftcontext}, shows some equipment which is sending
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, we read the intended quantitative
value from the external equipment.
%
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 with an additional error indication flag.
representing the current detected; plus an additional error indication flag.
%
Let us assume the {\ft} detection is via a \ohms{220} resistor, and that we read a voltage
Let us assume the {\ft} detection is via a \ohms{220} resistor, and that a voltage is read
from an ADC into the software.
Let us define any value outside the 4mA to 20mA range as an error condition.
%
As we read a voltage, we use Ohms law~\cite{aoe} to determine the mA current detected: $V=IR$, $0.004A * \ohms{220} = 0.88V$
and $0.020A * \ohms{220} = 4.4V$.
Any value outside the 4mA to 20mA range can be defined as an error condition.
%
Our acceptable voltage
range\footnote{For the purpose of clarity we are ignoring resistor tolerance
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 we are ignoring resistor tolerance
for this example. In a practical {\ft} reader we would factor in resistor tolerance to the limits, or
allow `deadbands' of $\approx \half mA$ at either end of the range.}
is therefore
$$(V \ge 0.88) \wedge (V \le 4.4) \; .$$
This voltage range forms our 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).
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.
%
We can now examine a software function that performs a conversion from the voltage read to
a per~mil representation of the {\ft} input current.
The software function that performs a conversion from the voltage read to
a per~mil representation of the {\ft} input current 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
differentiate from other type of variables (data types or pointers).
differentiate it from other type of variables (data types or pointers).
%
In this document we borrow that format, hence the C~language
In this document this format is borrowed, hence the C~language
function called `main' will be presented as \cf{main}.
%
We initially assume a function \cf{read\_ADC} that returns a floating point %double precision
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}).
@ -329,7 +334,7 @@ int read_4_20_input ( int * value ) {
%\label{fig:420i}
\end{figure}
\clearpage
We now look at the function called by \cf{read\_4\_20\_input}, \cf{read\_ADC}, which returns a
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
@ -391,7 +396,7 @@ double read_ADC( int channel ) {
\end{figure}
\clearpage
%
We now have a very simple software structure, a call tree, shown in figure~\ref{fig:ct1}.
A very simple software structure, a call tree, shown in figure~\ref{fig:ct1} has been obtained.
%
\begin{figure}[h]
\centering
@ -409,10 +414,10 @@ 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.
%
We can identify the resistor and the ADC module of the micro-controller as
the base components in this design.
The resistor and the ADC module of the micro-controller are identified as
the {\bcs} in this design.
%
We now apply FMMD starting with the hardware.
FMMD is now applied, from the bottom-up, starting with the hardware.
%
%
\subsection{FMMD Process}
@ -427,13 +432,15 @@ It is therefore a hardware only {\fg}.
%
%We now determine the {\fms} of all the components in $G_1$.
We now determine the {\fms} of all the components in the {\fg} $G_1$.
For the resistor we can use a failure mode set from the literature~\cite{en298}.
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 we can determine the following failure modes:
For the ADC the following failure modes are determined:
\begin{itemize}
\item STUCKAT --- The ADC outputs a constant value,
@ -443,7 +450,7 @@ For the ADC we can determine the following failure modes:
\end{itemize}
}
We can use the function $fm$ to define the {\fms} of an ADC thus:
$$ fm(ADC) = \{ STUCKAT, MUXFAIL,LOW, HIGH \}. $$
$$ fm(ADC) = \{ STUCKAT, MUXFAIL, LOW, HIGH \}. $$
%
With these failure modes defined, analysis can begin on the {\fg} $G_1$, see table~\ref{tbl:cmatv}.
@ -502,26 +509,28 @@ The code fragment in figure~\ref{fig:code_read_ADC} states pre-conditions, as
in valid ADC range
b) voltage ref is 0.1\% of 5V */}.
%
From the above contractual programming requirements, we see that
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} of the function,
which we can call $ CHAN\_NO $.
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 we can call $V\_REF$ (nb: this failure mode is detectable %observable
only if we specifically use a test input to measure the reference).
of this function,
which is termed $V\_REF$ (nb: this failure mode is detectable %observable
only if a test input is used to measure a high precision voltage reference).
%
Taken as a component for use in FMEA/FMMD our function has
two failure modes. We can therefore treat it as a generic component, $Read\_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, $Read\_ADC$,
by stating:
%
$$ fm(Read\_ADC) = \{ CHAN\_NO, VREF \} $$
%
With the failure mode model for our function, we use it in conjunction
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 =\{ CMSTV, Read\_ADC \}$.
%
This analysis is performed in table~\ref{tbl:radc}. %{ hardware/software combined {\fg}.
@ -547,7 +556,7 @@ This analysis is performed in table~\ref{tbl:radc}. %{ hardware/software combine
& wrong channel & \\ \hline
5: $CMATV_{LOW}$ & output low & $LOW$ \\ \hline
6: post-condition fails & software fails & $VV\_ERR$ \\
& C function: Read\_ADC & \\ \hline
& C function: Read\_ADC & \\
\hline
\hline
\end{tabular}
@ -563,7 +572,7 @@ corresponds to $VV\_ERR$, and happens to already be in the {\fm} set for this {
%
%We can now create a {\dc} called $RADC$ thus: $$RADC = \; \derivec(G_2)$$ which has the following
%{\fms}:
We can now create a {\dc} called $RADC$ with its failure modes thus:
A {\dc} called $RADC$ is created with failure modes of:
$$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
%
%
@ -575,7 +584,7 @@ $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
%
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 we derived the {\dc} $RADC$.
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.
@ -689,8 +698,8 @@ 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.
a complete `reasoning~path' linking the failures modes from the
electronics to those in the software has been created.
%
Each functional group to {\dc} transition represents a
reasoning stage\footnote{Each of these reasoning stages, will have a reasoning distance
@ -707,22 +716,24 @@ 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 HFMEA~\cite{sfmea,sfmeaa}, additionally even the software/hardware
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
We now have a {\dc} for a {\ft} input in software.
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, we can also
re-use the analysis for each {\ft} input.
%
Not only have we integrated electronics and software in an FMEA, the analysis for the {\ft} input can 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
%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
via the 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.
%
@ -801,19 +812,23 @@ A structured analysis `Yourdon' context diagram~\cite{Yourdon:1989:MSA:62004} is
\label{fig:context_diagram_PID}
\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} 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).
%
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
will therefore require an ADC and MUX.
There are two voltage inputs (see section~\ref{sec:Pt100}) from the Pt100 temperature sensor.
%
For the output, we can use a Pulse Width Modulator (PWM) (this is a common module found on micro-controllers
%allowing a
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].
We refine the Yourdon diagram, with the afferent data flow coming through the MUX and ADC on the micro-controller, and the efferent
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].
%
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,
%
%and add more detail, see figure~\ref{fig:context_diagram2_PID}.
@ -825,12 +840,13 @@ channelled through a PWM module. %again built into the micro-controller,
\caption{Yourdon Context Diagram for PID Temperature Controller.}
\label{fig:context_diagram2_PID}
\end{figure}
The Yourdon methodology allows us to zoom into data transform bubbles, analyse them in more
depth and create more paths and transform bubbles which further define the data flow and processing. % required.
%
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.
%
This next stage of model refinement is shown in figure~\ref{fig:context_diagram2_PID}.
%
We define the controlling software, by looking at or zooming into transform bubbles
The controlling software is defined, by looking at or zooming into transform bubbles
and refining them by adding detail.
%
Following the data streams through the process, additional transform bubbles are created as required.
@ -851,17 +867,18 @@ defining software functions in its final stage.
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, we need a rudimentary operating system, often referred to as the `monitor'.
software architectures, a rudimentary operating system is required, often referred to as the `monitor'.
%
We bear in mind that PID, because the algorithm depends heavily on integral calculus~\cite{dcods}[Ch.3.3] is time sensitive
and we therefore need to execute it at precise intervals determined by its proportional, integral and differential (PID) coefficients.
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}.
We can use an internal timer in conjunction with the monitor function
%
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 us a guide as to which software
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]
@ -872,8 +889,8 @@ functions should be called to control the process, or in `C' terms be the main f
\label{fig:contextsoftware}
\end{figure}
%
Using figure~\ref{fig:contextsoftware} we can now pick the transform bubble we
want to be the `main' or controlling function in the software.
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.
%
@ -908,14 +925,14 @@ 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.
%
We now have a rudimentary closed loop control system incorporating both hardware and software.
A rudimentary closed loop control system incorporating both hardware and software has been defined.
%
By using the Yourdon methodology we obtain a programmatic design frame-work i.e. a call tree structure.
By using the Yourdon methodology a programmatic design frame-work i.e. a call tree structure was obtained.
%
We now have all the components, i.e. hardware elements and software functions
that will be used in the temperature controller.
All the components, i.e. hardware elements and software functions
that will be used in the temperature controller are now defined.
%
We list these, and begin, from the bottom-up, to apply FMMD analysis.
These are listed, and from the bottom-up, FMMD analysis is applied.
%
\clearpage
\subsection{FMMD Analysis of PID temperature Controller}
@ -941,19 +958,20 @@ $$ 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 we last read it, we can calculate the interval
the time last read value, we can calculate the interval
between readings (assuming the timer has not wrapped around more than once).
%
We can say that a timer can fail by
A timer can fail by
incrementing its value at an incorrect rate, or can stop incrementing.
%
We define the failure modes of $TIMER$ thus:
The failure modes of $TIMER$ are defined thus:
$$ fm(TIMER) = \{ STOPPED, INCORRECT\_INTERVAL \}.$$
%
\paragraph{HEATER.}
@ -978,7 +996,7 @@ 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.
%
We therefore state:
The PWM has the following failure modes:
$$ fm(PWM) = \{ HIGH, LOW \}.$$
\paragraph{Micro-Controller.}
@ -991,7 +1009,7 @@ Typically there are many other I/O modules incorporated (e.g. TIMERS, UARTS, PWM
%
In this project the ADCMUX, TIMER, PWM and general purpose computing facilities are used.
%
We have to therefore consider the general~computing, CLOCK, PROM and RAM failure modes.
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}
@ -1007,28 +1025,28 @@ Identified Software Components:
%
%
With the call tree structure defined (see figure~\ref{fig:context_calltree}),
we have a hierarchy compatible with FMMD for analysis.
hierarchy compatible with FMMD for analysis is obtained.
However, it is only the top, the software, part of the hierarchy.
%
FMMD is a bottom-up process and we must start at the lowest level, the electronics.
FMMD is a bottom-up process thus start at 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.
%
We can follow the input, or afferent data flow to find the bottom levels for system inputs
The input, or afferent data flow can be followed to find the bottom levels for 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, we find the lowest
level in the hierarchy, the Pt100 sensor.
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 at the bottom, we form a {\fg} with
Starting at the bottom, a {\fg} is formed with
the function \cf{read\_ADC} and the Pt100.
This gives us a {\dc}, %which we call
This gives a {\dc}, %which we call
`Read\_Pt100'.
%
%
@ -1043,8 +1061,8 @@ Moving along the afferent flow, the \cf{convert\_ADC\_to\_T} function is next
%
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.
%
We then, calculate the resistance of the Pt100 element, and with this---using a
polynomial or a lookup table~\cite{eurothermtables}---calculate the temperature.
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
%
@ -1055,6 +1073,7 @@ The pre-conditions for the function are that:
\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.
%
Note that a temperature outside the pre-defined range would be detected as an acceptable voltage
@ -1065,9 +1084,10 @@ The post-condition is that it returns a temperature within a given tolerance to
A failure of this post-condition can be termed temp\_incorrect.
%
\clearpage
We apply FMMD to the {\fg} formed by \cf{Read\_Pt100} and the function \cf{convert\_ADC\_to\_T}.
Applying FMMD to the {\fg} formed by \cf{Read\_Pt100} and the function \cf{convert\_ADC\_to\_T}.
gives the {\dc} {Get\_Temperature}.
%
We can call the resulting {\dc} {Get\_Temperature}. This analysis is presented in table~\ref{tbl:gettemperature}.
This analysis is presented in table~\ref{tbl:gettemperature}.
%
The analysis for the Pt100 circuit is presented in table~\ref{tbl:readPt100}.
%
@ -1097,8 +1117,8 @@ considered (see section~\ref{sec:Pt100floating}).
%
The post-condition thus has two variants, an incorrect value that is detected, KnownIncorrectErrorValue
%where we can detect the Pt100 value is suspect,
and IncorrectErrorValue where we simply have
an incorrect value but cannot determine 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}.
%
@ -1207,7 +1227,7 @@ adding a safety relay to cut the power to the heater).
%
The status LEDS will be controlled by general purpose (GPIO) I/O pins.
%
We could have three LEDS, one flashing with a human readable mark
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).
@ -1275,11 +1295,13 @@ determined previously:
%
The post-condition for the monitor function is that it implements the PID control task correctly.
\fmmdglossCONTRACTPROG
We can now create a {\dc} for the standalone temperature controller, and give it the name TempController.
A {\dc} for the standalone temperature controller is now created, and given the name TempController.
It will have the following failure modes:
%
$$fm ( TempController ) = \{ ControlFailureIndicated, ControlFailure, \\
KnownIndicationError, UnknownIndicationError \}.$$
\begin{equationarry}
fm ( TempController ) = \{ ControlFailureIndicated, \\ ControlFailure, \\ KnownIndicationError, \\ UnknownIndicationError \}.
\end{equationarry}
%
%
The failure mode analysis of the complete PID controller is represented
@ -1299,30 +1321,30 @@ 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,
but using the results from FMMD analysis we can trace down to the low level modules that are the cause of problematic
failure modes.
The 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 cause.
\fmmdglossOBS
%
This means that by using FMMD, we can identify the sub-systems which require
re-design to eliminate or reduce the likelihood of undetectable failure modes.
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, we can apply reliability statistics and possibly use higher rated
components instead of expensive re-design.
by electronics, reliability statistics can be applied, and the possibilities of using higher rated
components instead of expensive re-design can be simulated/modelled.
%
For software errors, we could, if necessary provide extra functions to provide self checking.
We could follow EN61508 high reliability software measures such as
duplication of functions with checking functions arbitrating them (diverse programming~\cite{en61508}[C.3.5]).
For software errors, it may be necessary to provide extra functions to provide self checking.
%
We could for instance, validate the processor clocking with an external watchdog and a simple
communications protocol. For PROM and RAM faults we can implement measures such as run-time checksums
and ram complement 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.
%
Using FMMD in conjunction with extra safety measures we can ensure no single failure could lead to a
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 failure could lead to a
system failure, something difficult to prove with current FMEA techniques.

6
submission_thesis/style.tex
View File

@ -80,6 +80,12 @@
% \newcommand{\fmmdname}{\glossary{name={FMMDNAME},description={ }}
%\fmodegloss
\newcommand{\fmmdglossHFMEA}{\glossary{name={system}, description={
Failure Mode Effect Analysis applied to hardware only (i.e. specifically not applied to software)}}}
\newcommand{\fmmdglossADC}{\glossary{name={system}, description={
Analogue to digital converter}}}
\newcommand{\fmmdglossSYS}{\glossary{name={system}, description={
A product designed to work as a coherent entity}}}