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

off to tunbridge wells

Browse Source
This commit is contained in:
Robin P. Clark 2012-11-28 18:38:36 +00:00
parent d5bb69dad5
commit bb463d4296
3 changed files with 79 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
submission_thesis/CH2_FMEA/copy.tex
View File

@ -157,6 +157,8 @@ for unearthing potential failure scenarios.
%The core of Cartesianism is that you have a mind: a separate function of your'self'. If you have an invisible self called a mind - you are in the subject/object dichotomy. Non-dualism is mostly learned in Eastern philosophies and will refer to the mind as an integer of the self - not separate from it.
%You can not jump from one to the other. And, they both must be learned as referential contexts to who 'you' are in the world you live in.
%
\paragraph{Subjective and Objective thinking in relation to FMEA.}
\label{sec:subjectiveobjective}
FMEA is always performed in the context of the use of the equipment.
In terms of philosophy this is in the domain of the subjective and the objective.
We can using objective reasoning trace a component level failure to a system level event,

2
submission_thesis/CH5_Examples/Makefile
View File

@ -7,7 +7,7 @@ PNG_DIA = blockdiagramcircuit2.png bubba_oscillator_block_diagram.png circuit1
tree_abstraction_levels.png vrange.png sigma_delta_block.png ftcontext.png ct1.png hd.png \
sigdel1.png sdadc.png bubba_euler_1.png bubba_euler_2.png eulersd.png eulersdfinal.png \
eulerfivepole.png eulerswhw.png context_diagram_PID.png context_diagram2_PID.png context_software.png \
context_calltree.png
context_calltree.png euler_afferent_PID.png

113
submission_thesis/CH5_Examples/software.tex
View File

@ -5,22 +5,21 @@
\section{Software and Hardware Failure Mode Concepts}
\label{sec:elecsw}
FMMD can be applied to software, and thus we can build complete failure models
In this chapter we show that FMMD can be applied to software enabling us to build 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.
%
A programmatic function has similarities with a {\fg} as defined by the FMMD process.
%
An FMMD {\fg} is placed into a hierarchy.
A software function is placed into a hierarchy, that of its call-tree.
A software function typically 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 functions that may call it.
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.
%
We can map a software function to a {\fg} in FMMD. Its failure modes
We show that we can map a software function to a {\fg} in FMMD: its failure modes
are the failure modes of the software components (other functions it calls)
and the hardware from which it reads values.
Its outputs are the data it changes, or the hardware actions it performs.
@ -28,18 +27,28 @@ 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 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).
We can thus apply the FMMD % $\derivec$
process to software functions, by viewing them in terms of their failure
mode behaviour. To simplify things as well, software already fits into a hierarchy.
%
We apply the FMMD process to software functions by viewing them in terms of their failure mode behaviour.
%
As software already fits into a hierarchy we have one less analysis decision to make, compared
to analysing electronics.
%
For Electronics 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}
and the subsequent hierarchy. With software already written, that hierarchy is fixed.
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 its-self
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}
%to software functions.
%
@ -73,7 +82,9 @@ With electronic components, we can use literature to point us to suitable sets o
{\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
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.
@ -97,26 +108,28 @@ We can consider a software function 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.
In this analogy the connections are the code, and the functions and variables are the components.
Using this analogy for software, the connections are the functions code, and the
called functions and variables are the components.
%
%EHHRHHHUH
%EERRGHHH COUGH COUGH
Erroneous behaviour from called functions and variables/inputs has the same effect as component failure modes
on an electronic {\fg}.
%
%
If we consider the
calls and variables/inputs to be components of a function,
called functions and variables/inputs to be components of a function,
we can build a modular and hierarchical failure mode model
from existing software.
%
any erroneous behaviour from them has the same effect as component failure modes
on an electronic {\fg}. %HHmmm HHHHMMMM XXXXXX gora den har nar dets finns into nagon some harker hela tiden
%
For a software function, we consider a violation of a pre-condition to be
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'.
\paragraph{Mapping contract `post-condition' violations to symptoms.}
A post condition is a definition of correct behaviour by a function.
A violated post condition is a symptom of failure, or derived failure mode, of a function.
A post condition is a definition of correct behaviour of a function.
%
A violated post condition is a symptom of failure, or derived failure mode, from a function.
%
Post conditions could be 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 not cause the function to
be executed.
@ -723,7 +736,7 @@ we will need an ADC and MUX.
%
For the output, we can use a Pulse Width Modulator (PWM) (this is a common module found on micro-controllers
allowing a variable power output~\cite{pwm}). PWM's ADC's and MUX's are commonly built into cheap micro-controllers~\cite{pic18f2523}.
We can now build more detail into the Yourdon diagram, with the afferent data flow coming through the MUX and ADC on the micro-controller, and the afferent
We can now build more detail into the Yourdon diagram, with 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,
see figure~\ref{fig:context_diagram2_PID}.
\begin{figure}[h]+
@ -736,7 +749,7 @@ see figure~\ref{fig:context_diagram2_PID}.
The Yourdon methodology allows us to zoom into data transform bubbles and analyse them in more
detail.
%
We define the controlling software, by looking at or zooming into its trafnsform bubble.
We define the controlling software, by looking at or zooming into its transform bubble.
We have the inputs and outputs from the software.
We refine the data flow within the software and thus define software functions.
%, and
@ -744,11 +757,14 @@ We refine the data flow within the software and thus define software functions.
%
We follow the data streams through the process, creating transform bubbles as required.
In all `bare~metal' software architectures, we need a rudimentary operating system, often referred to as the monitor.
PID, because the algorithm depends heavily on integration, is time sensitive
and we therefore need to invoke at specific intervals.
%
We bare in mind that PID, because the algorithm depends heavily on integral calculus, is time sensitive
and we therefore need to call at precise intervals specific to its integration and differential coefficients.
%
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.
%
\paragraph{Data flow model to programmatic call tree.}
The Yourdon methodology also gives us a guide as to which software
functions should be called to control the process, or in `C' terms be the main function.
@ -764,6 +780,7 @@ Using figure~\ref{fig:contextsoftware} we can now pick the transform bubble we
want to be the `main' or controlling function in the software.
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 is clearly going to be the monitor function.
\begin{figure}[h]+
\centering
\includegraphics[width=300pt]{./CH5_Examples/context_calltree.png}
@ -771,23 +788,26 @@ forming the software call tree hierarchy, see figure~\ref{fig:context_calltree}.
\caption{Software yourdon diagram converted to programatic call tree.}
\label{fig:context_calltree}
\end{figure}
%
This is clearly going to be the monitor function.
\paragraph{Software Algorithm.}
The monitor function will orchestrate the control process.
Firstly it will examine the timer value, and when appropriate, call the PID function, which will call first
the determine\_set\_point\_error function with that calling convert\_ADC\_to\_T
which calls Read\_ADC (the function developed in the earlier example).
With the set point error value the PID function will call the output control function with its PID
demand.
%
With the set point error value the PID function will return
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 PWM.
We now have a rudimentary closed loop control system incorporating both hardware and software.
%
Using the Yourdon methodology we have the system design: we have all the components, hardware elements and software functions
Using the Yourdon methodology we have the system design: we have all the components, i.e. hardware elements and software functions
that will be used in the temperature controller.
We list these and begin, from the bottom-up,
to apply FMMD analysis.
We list these, and begin, from the bottom-up, to apply FMMD analysis.
\clearpage
\subsection{FMMD Analysis of PID temperature Controller}
@ -859,7 +879,7 @@ Identified Software Components:
\item --- determine\_set\_point\_error (which calls convert\_ADC\_to\_T)
\item --- convert\_ADC\_to\_T (which calls read\_ADC which we can re-use from the last example)
\item --- read\_ADC
\item --- output\_Control (which sets the PWM hardware according to the PID demand value)
\item --- 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}), we can now analyse these
components from the bottom-up, starting with the electronics.
@ -1047,6 +1067,9 @@ However this problem is a failure mode for the function calling it.
The calling function sets the context for the PID algorithm (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.
This harks back to the context of use (see section~\ref{sec:subjectiveobjective}) discussion, the subjective
being the context the {\dc} is used for/in, and the objective
being the logic and process of the failure mode analysis.
{
\tiny
@ -1067,7 +1090,7 @@ for instance. In a control environment with PID jitter would not be a significan
& observable/detectable & \\
& failure mode & \\ \hline
FC2: $, IncorrectErrorValue $ & pre-condition violated & IncorrectControlErrorV \\
FC2: $ IncorrectErrorValue $ & pre-condition violated & IncorrectControlErrorV \\
& unobservable & \\
& undetectable failure mode & \\ \hline
@ -1080,6 +1103,22 @@ for instance. In a control environment with PID jitter would not be a significan
We now create a PID {\dc}, 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}
We have now modelled the the software call tree for the afferent flow, we represent this 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.
%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.......