% $Id: ons calling functionsin Exp $

% 

\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{ 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.
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

:'e,'f move .


\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 funtional group.
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.


\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}.
%What this means is the `fault~symptoms' of the module have been derived.
%
%When we have determined the fault~modes at the module level these can become a set of derived faults.
%By taking sets of derived faults (module level faults) we can combine these to form modules
%at a higher level of fault abstraction. An entire hierarchy of fault modes can now be built in this way,
%to represent the fault behaviour of the entire system. This can be seen as using the modules we have analysed
%as parts, parts which may now be combined to create new functional groups, 
%but as parts at a higher level of fault abstraction. 
\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{ 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}

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}