diff --git a/papers/software_fmea/abs.tex b/papers/software_fmea/abs.tex index 909b477..0cb4641 100644 --- a/papers/software_fmea/abs.tex +++ b/papers/software_fmea/abs.tex @@ -1,71 +1,113 @@ -%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. -% - - %% 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', +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 generally, software is increasingly being seen as a missing factor in FMEA analysis. +% +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. -This paper demonstrates the pitfalls and benefits of applying HFMEA and SFMEA +% +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 important software is today, how there is no FMEA to encompass both software and hardware % -Failure Mode Effects Analysis (FMEA), is a bottom-up technique that aims to assess the effect all +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 software FMEA (SFMEA) is beginning, but +% +Work on SFMEA is beginning, but at present no technique for SFMEA that integrates hardware and software models %known to the authors -exists. FMEA performed on mechanical and electronic -systems can be termed Hardware FMEA (HFMEA). +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. % -Software generally, sits on top of most modern safety critical control systems -and defines its most important system wide behaviour and communications. Currently standards that demand FMEA for hardware (e.g. EN298, EN61508), -do not specify it for Software, but instead specify, good practise, +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 software FMEA (SFMEA) has been applied, it is -performed a separately from the HFMEA. +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 (a {\ft} input circuit, MUX, ADC and two software functions -that are used to convert the electrical current signal into a value for use in software). -HFMEA is applied to the hardware and SFMEA to the software components. -The two failure models are then compared, and then compared with heuristic -knowledge about {\ft} inputs circuitry and software. - -Conclusions are then reached giving a positive and negative aspects +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. +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}||} + & Short Biography & \\ \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} diff --git a/papers/software_fmea/abs_pre.tex b/papers/software_fmea/abs_pre.tex index 7870043..35b5f7d 100644 --- a/papers/software_fmea/abs_pre.tex +++ b/papers/software_fmea/abs_pre.tex @@ -58,6 +58,6 @@ \begin{document} -\section*{FMEA applied to a hybrid software and hardware sub-system} +\section*{FMEA applied to hybrid software and hardware systems}