Robin_PHD/sw_model/sw_model.tex

%
% strucure
%
% introduce concept, mapping s/w to FMMD
%
% 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.

}
 
\ifthenelse {\boolean{paper}}
{
\section{Basic Concepts Of FMMD}

\paragraph{Creating an fault hierarchy}

%%- bias this to software...

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


In order to perform FMMD analysis, which is a bottom up ethodology, 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.
For software we already have the hierarchy, thanks to the nature of the `call tree'
in procedural languages.
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 can fail their post conditions).


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}.
} % ifdef papaer
{
}



\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}).
}



\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}