233 lines
9.2 KiB
TeX
233 lines
9.2 KiB
TeX
% $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}
|
|
|