141 lines
6.4 KiB
TeX
141 lines
6.4 KiB
TeX
%% INTRO
|
|
% the problem
|
|
% the solution
|
|
% why you would want to read the paper
|
|
%
|
|
The certification process of safety critical products for European and
|
|
other international standards often demand environmental stress,
|
|
endurance and Electro Magnetic Compatibility (EMC) testing. Theoretical, or `static~testing',
|
|
is often also required.
|
|
%
|
|
Failure Mode effects Analysis (FMEA) is a tool used
|
|
for static testing. Its use is traditionally applied to hardware (electrical and mechanical) systems.
|
|
%
|
|
With the increasing use of micro-controllers in smart~instruments and control~systems,
|
|
software is increasingly being seen as the `missing~factor' in FMEA analysis.
|
|
%
|
|
This paper presents a new modular variant of FMEA, Failure Mode Modular Decomposition (FMMD).
|
|
%
|
|
Because FMMD is modular and hierarchical, and deals with all its objects in terms of their failure mode behaviour,
|
|
it is ideally suited to creating integrated software and hardware models.
|
|
%
|
|
%%This paper takes a simple example of a hardware/software hybrid (an industry standard {\ft} input), analyses
|
|
%%the hardware and software using FMMD, and then discusses the effectiveness of the
|
|
%%failure modelling from the perspective of the hybrid hardware/software sub-system.
|
|
|
|
|
|
|
|
|
|
%% MIDDLE
|
|
% some background
|
|
% how important software is today, how there is no FMEA to encompass both software and hardware
|
|
% NEED for seamless integrated software hardware failure mode modelling
|
|
%
|
|
FMEA is a bottom-up technique that aims to assess the effects of all
|
|
component failure modes on a system.
|
|
It is used both as a design tool (to determine weaknesses), and is a requirement of certification of safety critical products.
|
|
FMEA has been successfully applied to mechanical, electrical and hybrid electro-mechanical systems.
|
|
%
|
|
Work on software FMEA (SFMEA) is beginning, but at present no technique for SFMEA that
|
|
integrates hardware and software models exists.
|
|
%
|
|
Software in current embedded systems practise sits on top of most modern safety critical control systems [and inside many
|
|
data collection/actuator modules (smart~instruments)], and defines their most important system wide behaviour, interfaces and communications.
|
|
%
|
|
Currently standards that demand FMEA for hardware (e.g. EN298, EN61508),
|
|
do not specify it for software, but instead specify, computer architecture, good software practise,
|
|
review processes and language feature constraints.
|
|
%
|
|
Where FMEA traces component {\fms} to resultant system failures, software has been left in a non-analytical
|
|
limbo of best practises and constraints.
|
|
%
|
|
Where SFMEA has been applied---for some automotive and highly safety critical systems---it has always been
|
|
performed separately from hardware FMEA (HFMEA).
|
|
%
|
|
At present the hardware/software interface is a source for confusion and misunderstanding, and in many organisations,
|
|
the actual design teams for software and hardware work in separate departments.
|
|
%
|
|
Subtle errors of electronic sub-systems for instance, may not be picked up by
|
|
software specialists, and vice versa.
|
|
%
|
|
It would be desirable to have a methodology that provides seamless software and hardware integration in its failure modelling. % methodology.
|
|
%
|
|
FMMD has been designed to integrate mechanical/electronic and software failure models, by treating all modular components
|
|
in terms of their failure modes.
|
|
%
|
|
For instance, a software function, or an electronic or a mechanical component can be assigned a known set of failure modes.
|
|
%
|
|
Because of this, they (software or hardware elements) may be treated as compatible modules under FMMD.
|
|
%
|
|
Also, FMMD has a modular incremental analysis strategy which offers efficiency gains (reduction of state explosion in terms
|
|
of number of checks to make, and the re-use of pre-analysed modules)
|
|
over traditional FMEA.
|
|
|
|
|
|
|
|
%% CONCLUSIONS.
|
|
%
|
|
%
|
|
This paper presents an overview of the FMMD methodology and then an FMMD analysis of a simple software/hardware hybrid sub-system.
|
|
%
|
|
The example system chosen is a {\ft} input circuit consisting of
|
|
a resistive element, multiplexer (MUX), Analogue to Digital Converter (ADC) and two software functions.
|
|
%
|
|
The purpose of this system is to convert an electrical current signal into a value for use in software.
|
|
%
|
|
FMMD is applied to the hardware (resistive element, MUX and ADC) and
|
|
to the software components (two `C' functions), producing one integrated
|
|
failure mode model.
|
|
%
|
|
The {\ft} input circuitry used in the example and its related software, are accepted practise and in common use, and therefore its failure mode
|
|
behaviour is well known and understood.
|
|
%
|
|
For this reason it is a good example to use for comparing the results from FMMD analysis
|
|
with known failure mode behaviour from the field/direct experience of engineers.
|
|
The failure model is then discussed and compared with heuristic
|
|
knowledge of {\ft} inputs, circuitry and software.
|
|
%
|
|
Conclusions are then presented listing the benefits and draw-backs
|
|
of analysing the hardware/software hybrid system using FMMD, and FMMD
|
|
is compared with traditional HFMEA and SFMEA.
|
|
|
|
\clearpage
|
|
|
|
Authors:
|
|
|
|
\begin{table}[h]
|
|
%\center
|
|
\begin{tabular}{||p{3cm}|p{6cm}|p{5cm}||}
|
|
|
|
\hline \hline
|
|
{\em Author } & {\em Email} & {\em Institution} \\ \hline
|
|
& & \\ \hline
|
|
R.P. Clark & r.clark@energytechnologycontrol.com & Energy Technology Control Ltd. \\ \hline
|
|
%R.P.Clark@brighton.ac.uk & Energy Technology Control Ltd \\ \hline
|
|
A. Fish & Andrew.Fish@brighton.ac.uk & Brighton University, UK \\ \hline
|
|
C. Garrett & C.Garrett@brighton.ac.uk & Brighton University, UK \\ \hline
|
|
J. Howse & John.Howse@brighton.ac.uk & Brighton University, UK \\ \hline
|
|
& & \\ \hline
|
|
\hline
|
|
\end{tabular}
|
|
%\caption{Authors}
|
|
\label{tbl:authors}
|
|
\end{table}
|
|
|
|
Presenting Author is R.P. Clark.
|
|
\begin{table}[h]
|
|
%\center
|
|
\begin{tabular}{||p{1cm}|p{12cm}|p{1cm}||}
|
|
\hline \hline
|
|
& Short Biography & \\ \hline \hline
|
|
& R.P. Clark is an embedded software Engineer, working with
|
|
safety critical industrial burner controllers, and the design of safety critical sensors. He is currently
|
|
working for a part-time PhD at Brighton University.
|
|
& \\ \hline
|
|
& & \\ \hline
|
|
\end{tabular}
|
|
%\caption{Authors}
|
|
\label{tbl:bio}
|
|
\end{table}
|
|
|