%
% strucure
%
% introduce concept, mapping s/w to FMMD
% how can we represent a software function in terms of failure modes
%
% yourdon data flow. Show transform bubbles and process for converting to a hierarchy of functiona calls
% show h/w at the bottom, and s/w on top.
% describe where s/w h/w interface occurs
%
% Talk about pre and post coonditions of contract s/w
% get some nice refs on contract s/w
% Now make the distinction that
% pre condition violations are like componnt fault modes, and that a software function is
% like a {\fg}. Now show that an analysed s/w function is a {\dc} where the 
% symptoms of failure are failed post conditions.

% now take a simple example, temp sensing
% and design it top down.
% interface to digitial I/O and an ADC


\ifthenelse {\boolean{paper}}
{
\begin{abstract} 
This paper
%
% describes a methodology (Failure Mode Modular De-Composition - FMMD) that using a common notation
% models failure mode behaviour in software, electronic and mechanical
% domains. The methodology therefore can model integrated
% software/electrical/mechanical systems. This paper concentrates
% on the software modelling, begining with
% a discussion on general software stucture, afferent. transform and effenet 
% data flow, and then the hierarchical call tree nature of software.
% Software functions are then described from a failure mode perspective
% integrating concepts from FMEA analysis, and the concepts of pre and post conditions.
% The paper then shows how FMMD models from electrical and mechanical
% domains can be seamlessly integrated with the software failure mode models.
% 
% With a methodology that provides a common notation for these three domians
% complete and connected failure mode modelling can be applied to 
% real time systems, such as safety critical smart devices and 
% embedded industrial control machinery.

\end{abstract}
}
{
\section{Introduction}
This chapter
%
% describes a methodology (Failure Mode Modular De-Composition - FMMD) that using a common notation
% models failure mode behaviour in software, electronic and mechanical
% domains. The methodology therefore can model integrated
% software/electrical/mechanical systems. This paper concentrates
% on the software modelling, begining with
% a discussion on general software stucture, afferent. transform and effenet 
% data flow, and then the hierarchical call tree nature of software.
% Software functions are then described from a failure mode perspective
% integrating concepts from FMEA analysis, and the concepts of pre and post conditions.
% The paper then shows how FMMD models from electrical and mechanical
% domains can be seamlessly integrated with the software failure mode models.
% 
% With a methodology that provides a common notation for these three domians
% complete and connected failure mode modelling can be applied to 
% real time systems, such as safety critical smart devices and 
% embedded industrial control machinery.

}
 

\section{Basic Concepts Of FMMD}

\paragraph{Creating an fault hierarchy}

%%- bias this to software...

The main core concept of the FMMD methodology is to build a hierarchy of fault behaviour
from the part
level up to highest system levels. 

This means that we model 
components of a system with respect to their failure modes.
Electrical and mechanical components have known and 
well understood failure modes~\cite{mill1991}~\cite{fmd91}.
Software functions (apart from some standard library procedures) generally are custom written
for a given application.
In order to model system which include mechanical and electronic
parts with software, we need some way of represent software functions
in terms of their failure mode behaviour. Also
we need to integrate them into a hierarchical failure mode model.

In order to perform FMMD analysis, which is a bottom up methodology, the first stage is to choose
components that interact and naturally form {\fgs}. The initial {\fgs} are thus collections of base parts.
%These parts all have associated fault modes. A module is a set fault~modes. 
From the point of view of fault analysis, we are not interested in
the components themselves, but in the ways in which they can fail.
Contract programming defines software functions in terms of
pre-conditions, post conditions and invariants.
Breaking any of these is a failure mode, and contract
programming defines software failure modes useful for FMMD modelling.


\subsection{Software in terms of failure modes}
 

For software we already have the hierarchy, thanks to the nature of the `call~tree'
in procedural languages.
A function can fail when its post-conditions are not obeyed/completed/kept.
In terms of a treating a function as a component, post condition
violations are its failure modes.
Let us consider two functions $f1()$ and $f(2)$ which have 
post condition violation conditions. 

$$  PostCondVoliations(f1) = \{ {pcf1}_1, {pcf1}_2 \} $$
$$  PostCondVoliations(f2) = \{ {pcf2}_1, {pcf2}_2 \} $$

A function which calls other functions can thus be treated as a functional group. 
Let us consider a function $f()$ which calls $f1(),f2()$.


\vbox{
\begin{verbatim}
 function f() {
  f1();
  f2();
}
\end{verbatim}
} % vbox

Its input failure modes
are its pre-condition violations, let us define these as
$$  PreCondVoliations f() = \{ {prf}_1, {prf}_2 \} $$

For an FMMD model we need to extend the concepts of contract programming slightly.
Contract programming deals with functions in isolation.
We need the failure modes to propagate up a hierarchy
(as they do in real software systems).
We need to consider the failure effects of the called functions
failing their post-conditions as well as the pre-condition failures
defined for $f()$.

Considering the function $f()$ as an FMMD {\fg}, the failure modes
we must consider to analyse its failure mode behaviour are
its pre-condition violations and the failed post conditions of
the functions its calls.

$$ fm(f()) = \{ {prf}_1, {prf}_2, {pcf1}_1, {pcf1}_2, {pcf2}_1, {pcf2}_2 \} $$

We can now use these failure modes to help analyse how the 
function $f()$ can fail. We can analyse how these
pre-condition violations will affect the $f()$
and  treat these as failure symptoms of the function $f()$.

We can also add new post conditions to $f()$ 
(as in contract programming) to define the correct behaviour
of $f()$.

Together these become the symptoms of failure of function $f()$.

We can now treat $f()$ as a component and use its
symptoms as failure modes.
A function calling $f()$, using FMMD would have to
consider these failure modes, when calling $f()$.


In this way a software hierarchy, in terms of failure
modes can be built up.
This is an extension of contract programming in that it
provides a formal basis for linking functions together
into a software hierarchy.
It also means that any failed post conditions
of a function called, must be considered in the failure model,
something that can be checked and controlled by a software tool.

 


%This we cannot change. 


\subsection{Interfacing Software to Electronic {\wrt} failure modes}

Software functions, call other `lower level' functions.
The lowest level functions generally either provide some 
for of data transformation (i.e. a mathematical function such as {\em sin(x)})
or interact with inputs and outputs (I/O). 

Software interaction with I/O is generally via to
electronics. Where mechanical components are present, they are generally
controlled by electronic actuators, and measured via electronic transducers~\cite{elecsys}[pp194-273].
Obviously in order to integrate software with electronic components we need
to define this interface.

A typical and common function is being able to read a voltage into
a computer program. This example is discussed in section \ref{sec:adc}.

In terms of software, we can consider the data transformations and functions used/called by a function to be the components.
The functions called will have known failure modes (i.e. they could fail their post conditions).
In FMMD terms these are the failure modes of the derived component.

We can view the {\swf} as a {\fg}, with components being I/O modules used
and/or functions called.
In the case of I/O modules, these will be derived components with their own sets of failure modes.
If a function calls a function,  the failure modes would be failed post-conditions of the called function.


\subsection{FMMD Process}

Diagram showing components with failure modes,
the functional group; the collection of failure modes;
the analysis stage; the symptoms, and finally the derived component.


Now diagram showing software function,
with pre-conditions, invariants and post conditions.

define postcondition.
define pre-condition:
define invariant:

Now an integrated diagram, showing the 
pre-condition violations as failure modes 





For this study a {\fg} will mean a collection of components.
In order to determine the symptoms or failure modes of a {\fg},
we need to consider all failure modes of its components.
By analysing the fault behaviour of a `{\fg}' with respect these failure modes
we can derive a new set of possible failure modes.
Thus we can consider how a software function will react to the failure modes of the functions it calls.
%
This new set of faults is the set of derived faults from the perspective of the {\fg}, and is thus at a higher level of 
fault~mode abstraction. Thus we can say that the {\fg} as an entity, can fail in a number of well defined ways.

In other words we have taken a {\fg}, and analysed how it can fail according to the failure modes of its parts.
These new failure~modes are derived failure modes.
%The ways in which the module can fail now becomes a new set of fault modes, the fault~modes
%being derived from the {\fg}. 
We can now create a new `{\dc}' which has
the failure symptoms of the {\fg} as its set of failure modes.
We thus consider that our software function can fail in a number of given ways.
This new {\dc} is at a higher failure mode abstraction
level than the {\bcs}.


\subsection{ An example function analysed in terms of failure modes }

OK here an example reading an ADC
The values could be out of range (a pre-condition)
The post condition is sending back a voltage, with an error condition


This simple ADC read function contains no self checking
we cannot be sure the multiplexer switching a selection
of inputs to it is functioning, and we do not know
the ADC reference voltage is accurate.

What this means is the fundamental aspects of safely reading a voltage, i.e.
we are reading the right input, and the accuracy or the reading cannot be detected.
What we have here are effectively undetectable failure modes.


\section{example of Software to Electronics Interfacing}
\label{sec:adc}

\subsection{ A more detailed function with ADC checking features }

For safety critical product
OK here an example reading an ADC, but testing the MUX
and a mid range voltage ref + span and zero.

The values could still be out of range (a pre-condition)
The post condition is sending back a voltage, with an error condition


\subsection{ Higher level failure mode analysis }




\ifthenelse {\boolean{paper}}
{
Reference the symptom abstraction paper here
}
{
This analysis and symptom collection process is described in detail in the Symptom extraction (see chapter \ref{symptomex}).
}




%\begin{comment}
%
%:Title: Control system principles
%
%:Tags: Block diagrams 
%
%
%
%An example of a control system with a feedback loop. Block diagrams like this
%
%are quite time consuming to create by hand. The relative node placement feature
%
%makes it a bit easier, but it works best when the nodes have equal widths. 
%
%However, the results are quite pleasing and hopefully worth the effort. 
%
%You can probably speed up the process by creating custom macros. 
%
%\end{comment}
%






%
%\tikzstyle{block} = [draw, fill=blue!20, rectangle, 
%
%    minimum height=3em, minimum width=6em]
%
%\tikzstyle{sum} = [draw, fill=blue!20, circle, node distance=1cm]
%
%\tikzstyle{input} = [coordinate]
%
%\tikzstyle{output} = [coordinate]
%
%\tikzstyle{pinstyle} = [pin edge={to-,thin,black}]
%
%
%
%% The block diagram code is probably more verbose than necessary
%
%\begin{tikzpicture}[auto, node distance=2cm,>=latex']
%
%    % We start by placing the blocks
%
%    \node [input, name=input] {};
%
%    \node [sum, right of=input] (sum) {};
%
%    \node [block, right of=sum] (controller) {Controller};
%
%    \node [block, right of=controller, pin={[pinstyle]above:Disturbances},
%
%            node distance=3cm] (system) {System};
%
%    % We draw an edge between the controller and system block to 
%
%    % calculate the coordinate u. We need it to place the measurement block. 
%
%    \draw [->] (controller) -- node[name=u] {$u$} (system);
%
%    \node [output, right of=system] (output) {};
%
%    \node [block, below of=u] (measurements) {Measurements};
%
%
%
%    % Once the nodes are placed, connecting them is easy. 
%
%    \draw [draw,->] (input) -- node {$r$} (sum);
%
%    \draw [->] (sum) -- node {$e$} (controller);
%
%    \draw [->] (system) -- node [name=y] {$y$}(output);
%
%    \draw [->] (y) |- (measurements);
%
%    \draw [->] (measurements) -| node[pos=0.99] {$-$} 
%
%        node [near end] {$y_m$} (sum);
%
%\end{tikzpicture}
%




\section{ Modern Devices }

From the automobile to the microwave oven, we increasingly rely on
embedded computing, controlling electro mechanical
devices etc etc etc

\section{ Data Flow Modelling }

A computer system can be considered to simply process data, and data flow modelling
exists in various forms.~\cite{yourdon}~\cite{sommerville}

Essentially data flow modelling starts with a context diagram, where
the inputs and outputs to a process are identified.
These inputs and outputs connect to a process `bubble'
representing the computing, or data transformation.


Data flow diagrams (DFDs) are directed graphs~\cite{embupsys}[pp.120].
The arcs represent data flow, and the bubbles
represent procedures that transform data. 
A `bubble' can be further
decomposed, or zoomed into, to a more detailed 
DFD which shows the subprocedures and data flows within it.

EXAMPLE CONTEXT DIAGRAM


The data input to the system is afferent data flow, the data actually processed is
known as transform data and the data output is termed `efferent' flow.

The next stage in the process is to consider the transform, or computing bubble.
Each stream of input data is taken to transform `bubbles' that 
process the data and pass it on to other bubles which process the data to be sent out.

%%- Hereby the Data flow diagrams (DFDs) are directed graphs.
%%-  The arcs represent data, and the nodes (circles or bubbles)
%%-  represent processes that transform the data. A process can be further
%%-  decomposed to a more detailed DFD which shows the subprocesses and data flows within it.

This process can continue zooming into each `bubble' until the transformation processes they
represent are simple enough to implement  as functions in a programming language.

The next stage, is to pick a transform bubble somewhere in the middle 
of these diagrams and assign it as the `main' \cite{kandr} or start
function.

As a design methodology, ignoring real time constraints, this is a very good way
of analysiing a problem and getting a good software structure.

What is interesting though is that this naturally determines a hierarchy
where the hardware, the sensors and actuators in an embedded system,
naturally fall to the lowest point in the software hierarchy.

n fact because we use electronics to measure mechanical devices,
we can establish a hierarchy of the three domians 
in terms of software.
That is to say Software at the top of the hierarchy, Electronics below it, and mechanical
systems below electronics.

%%-s is the process of identifying, modeling and documenting how data moves around an information system.
%%- Data Flow Modeling examines processes (activities that transform data from one form to another), data stores (the
%%- holding areas for data), external entities (what sends data into a system or receives data from a system),
%%- and data flows (routes by which data can flow).
%%-Discuss afferent efferent flow, how h/w naturally goes at the bottem end 
%%-of the software structure.

Establish this general structure


SW

ELEC

MECH



\section{ Software structure}
All software has a natural hierarchy or call tree structure.
The first called function will call others and the hierarchy
will be controlled by a call stack.


\section{FMEA applied to s/w}

%tref navy Msc
Failure Mode Effects analysis can be applied to software.
We can treat a software function as a component.
It has a set of failure modes, or outputs that
can be incorrect. In contract programming these correspond to the post-conditions for the function.
The parameters passed to the function, or return values from functions it calls,
can be considered the pre-conditions.

Because of the hierichical nature of software functions
we can consider functions from the FMMD perspective as
{\dcs}.
The failure modes of the {\dc} are where failures
in post conditions occur.
The failure modes to consider for a function, or pre-condition
failures, are the parameters passed to it and any values 
it uses (external data or values from function calls that it makes).
Recursion potentially complicates this, however  
functions are banned for high integrity levels
of most standards in the field of embedded computing.
EN61508\cite{en61508} specifically bans recursive
calls for SIL 2 on higher. Some microcontroller families~\cite{PIC18}
make classic recursion impossible, by using memory mapping for
parameters as opposed to a general purpose stack.
\paragraph{Design Constraint: FMMD and recursive function calls} 
FMMD will not support recursion in its modelling of software.


Now need a simple example C program, where I have functions
with pre and post conditions and show these as an fmmd hierarchy
really nice touch would be to have the pre and post conditions
as comments and then to automatically process them into an FMMD analysis tool


All the functions it calls are components 
that are used to build it.

\section{Failure Modes and functions}

Describe functions, how pre conditions map to
input failure modes and post conditions to 
failure mode symptoms.

Traditionally written as a form of guard.

Here we are interested in the ways the functions can fail.
They can fail if given the wrong data, or there can be a mistake in the code
which causes an incorrect output.



\section{ Applying Software to the FMMD Hierarchy}

Follow the natural call function hierarchy, model the 
flow of failure modes and symptom collection as before.



\section{interfacing Software to Hardware}

\subsection{The medium on which software executes}
Software, is an abstract formal representation of the procedures
and mathematical processing to achieve a goal. For it to run
in the `real~world', it has to run on some form of
processor. Typically this will, in the case of embedded safety critical
applications, be on some form of micro-controller.

Modern micro controllers are highly intgerated devices.
A typical low cost micro-controller will
have at least the following functional modiules intgrated into it:

\begin{itemize}
\item Analogue to Digital Converter (ADC), 
\item Universal Asynchronous Receiver Transmitter (UART), 
\item Serial Peripheral Interface (SPI), a synchronous serial data link used to transfer data between chips on a PCB , 
\item Controller Area Network (CAN) an industrailly hardened shhort messaging serial bus, 
\item Capture Compare PWM CCP (counters, timers and pulse width modulation output), 
\item interrupt triggering facilities
\item digital I/O. 
\end{itemize}

Need to consider the failure modes of all these components.

For ADC we also need to consider the MUX and how it interfaces with general I/O 
pins.

this later makes the example where we test the ADC and the MUX by
forcing logical values onto the I/O pins the ADC reads.


%% Super bbc micro all on one 28 pin chip

Obviously were a microcontroller to fail internally,
it could fail and not affect any of its other modules.
Should a failure occur in an unused module, the 
application would never detect it.
This means that we could easily have more than one 
failure at any given time.
This means that were we to try to place a microcontroller into a failure model,
apart from being unwieldingly large, it would
disobey the unintary state failure mode constraint of FMMD (see section \ref{unitarystate}).

\paragraph{The need to de-compose highly integrated components}


\paragraph{Consider module activation within highly integrated component as a soource of failure}

\subsection{Context of firmware in a small System}

Nature of this is sensors and actuators.
Describe.
Example of failure modes of a hardware element being
integrated into s/w

Use prev example of milli-volt amp with check resistor.



\section{Software Example Analysed using FMMD}