332 lines
13 KiB
TeX
332 lines
13 KiB
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.
|
|
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}
|
|
|