%% 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 takes a simple example of a hardware/software hybrid (an industry standard {\ft} input), analyses it
using hardware and software FMEA, and then discusses the effectiveness of  the
failure modelling from the perspective of the hybrid hardware/software sub-system.
%
FMEA performed on mechanical and electronic 
systems can be termed Hardware FMEA (HFMEA), and on software, SFMEA.
%
This paper highlights the pitfalls and benefits of applying HFMEA and SFMEA
to a hybrid system.
%


%% MIDDLE
% some background
% how important software is today, how there is no FMEA to encompass both software and hardware
%
FMEA is a bottom-up technique that aims to assess the effect 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 SFMEA is beginning, but
at present no technique for SFMEA that
integrates hardware and software models %known to the authors 
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 % scientifically 
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  HFMEA.
%
The {\ft} input circuitry used in the example and its related software, are accepted practise and in common use, and therefore the failure mode
behaviour is well known and understood. 
%
For this reason it is a good example to use for comparing the  results from the SFMEA and HFMEA methodologies
with known failure mode behaviour from the field/direct experience of engineers.

%% CONCLUSIONS.
%
%
This paper presents an  analysis of a simple software/hardware hybrid sub-system, the {\ft} input circuit consisting of
a resistive element, multiplexer (MUX), Analogue to Digital Converter (ADC) and two software functions.
The purpose of this sub-system is to convert an electrical current signal into a value for use in software.
%
HFMEA is applied to the hardware (resistive element, MUX and ADC) and SFMEA to the software components (two `C' functions), producing two separate 
failure mode models for the {\ft} input.
%
The two failure models are 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 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{10cm}|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}