From 244b6685b0c9c0179d53f4f7703ebb54f1200093 Mon Sep 17 00:00:00 2001 From: "Robin P. Clark" Date: Mon, 30 Apr 2012 19:34:00 +0100 Subject: [PATCH] Abstract for FMMD software paper send to supervisors just now. --- papers/fmmd_software_hardware/Makefile | 9 ++ papers/fmmd_software_hardware/abs.tex | 139 ++++++++++++++++++ papers/fmmd_software_hardware/abs_end.tex | 6 + papers/fmmd_software_hardware/abs_pre.tex | 63 ++++++++ .../fmmd_software_hardware/software_fmmd.tex | 94 ++++++++---- 5 files changed, 280 insertions(+), 31 deletions(-) create mode 100644 papers/fmmd_software_hardware/abs.tex create mode 100644 papers/fmmd_software_hardware/abs_end.tex create mode 100644 papers/fmmd_software_hardware/abs_pre.tex diff --git a/papers/fmmd_software_hardware/Makefile b/papers/fmmd_software_hardware/Makefile index 8b09167..d0bd8bd 100644 --- a/papers/fmmd_software_hardware/Makefile +++ b/papers/fmmd_software_hardware/Makefile @@ -12,3 +12,12 @@ all: ${PNG} bib bib: bibtex software_fmmd + + + +abs: # bib + cat abs_pre.tex > abstract.tex + cat abs.tex >> abstract.tex + cat abs_end.tex >> abstract.tex + pdflatex abstract + acroread abstract.pdf diff --git a/papers/fmmd_software_hardware/abs.tex b/papers/fmmd_software_hardware/abs.tex new file mode 100644 index 0000000..ca4544e --- /dev/null +++ b/papers/fmmd_software_hardware/abs.tex @@ -0,0 +1,139 @@ +%% 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 De-Composition (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 sub-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 sub-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. + +\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} + diff --git a/papers/fmmd_software_hardware/abs_end.tex b/papers/fmmd_software_hardware/abs_end.tex new file mode 100644 index 0000000..d44b9ad --- /dev/null +++ b/papers/fmmd_software_hardware/abs_end.tex @@ -0,0 +1,6 @@ +%%% +%%% +%%% +%%% + +\end{document} diff --git a/papers/fmmd_software_hardware/abs_pre.tex b/papers/fmmd_software_hardware/abs_pre.tex new file mode 100644 index 0000000..8c69efd --- /dev/null +++ b/papers/fmmd_software_hardware/abs_pre.tex @@ -0,0 +1,63 @@ + + +\documentclass{article} +%\documentclass[twocolumn,10pt]{report} +\usepackage{graphicx} +\usepackage{fancyhdr} +%\usepackage{wassysym} +\usepackage{tikz} +\usepackage{amsfonts,amsmath,amsthm} +\usetikzlibrary{shapes.gates.logic.US,trees,positioning,arrows} +%\input{../style} +\usepackage{ifthen} +\usepackage{lastpage} +\usetikzlibrary{shapes,snakes} +\newcommand{\tickYES}{\checkmark} +\newcommand{\fc}{fault~scenario} +\newcommand{\fcs}{fault~scenarios} +\date{} +%\renewcommand{\encodingdefault}{T1} +%\renewcommand{\rmdefault}{tnr} +%\newboolean{paper} +%\setboolean{paper}{true} % boolvar=true or false +\newcommand{\ft}{\ensuremath{4\!\!\rightarrow\!\!20mA} } +\newcommand{\permil}{\ensuremath{{ }^0/_{00}}} +\newcommand{\oc}{\ensuremath{^{o}{C}}} +\newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}} +\newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}} +\newcommand{\ohms}[1]{\ensuremath{#1\Omega}} +\newcommand{\fm}{failure~mode} +\newcommand{\fms}{failure~modes} +\newcommand{\fg}{functional~group} +\newcommand{\FG}{\mathcal{G}} +\newcommand{\DC}{\mathcal{DC}} +\newcommand{\fgs}{functional~groups} +\newcommand{\dc}{derived~component} +\newcommand{\dcs}{derived~components} +\newcommand{\bc}{base~component} +\newcommand{\FMMD}{ModularFMEA} +\newcommand{\bcs}{base~components} +\newcommand{\irl}{in real life} +\newcommand{\enc}{\ensuremath{\stackrel{enc}{\longrightarrow}}} +\newcommand{\pin}{\ensuremath{\stackrel{pi}{\longleftrightarrow}}} +%\newcommand{\pic}{\em pure~intersection~chain} +\newcommand{\pic}{\em pair-wise~intersection~chain} +\newcommand{\wrt}{\em with~respect~to} +\newcommand{\abslevel}{\ensuremath{\Psi}} +\setlength{\topmargin}{0in} +\setlength{\headheight}{0in} +\setlength{\headsep}{0in} +\setlength{\textheight}{22cm} +\setlength{\textwidth}{16cm} +\setlength{\oddsidemargin}{.2in} +\setlength{\evensidemargin}{.2in} +\setlength{\parindent}{0.0in} +\setlength{\parskip}{6pt} + + +\begin{document} + + +\section*{Failure Mode Modular De-composition applied to a hybrid software/hardware system} + + diff --git a/papers/fmmd_software_hardware/software_fmmd.tex b/papers/fmmd_software_hardware/software_fmmd.tex index 52af453..0d4529d 100644 --- a/papers/fmmd_software_hardware/software_fmmd.tex +++ b/papers/fmmd_software_hardware/software_fmmd.tex @@ -132,42 +132,43 @@ failure mode of the component or sub-system}}} %\small \abstract{ \em +\input{abs} %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 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 -at present no technique for SFMEA that -integrates hardware and software models % known to the authors -exists. -% -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, -review processes and language feature constraints. - -%This is a weakness; w -Where FMEA % scientifically -traces component {\fms} -to resultant system failures, software has been left in a non-analytical -limbo of best practises and constraints. -% -If software and hardware integrated FMEA were possible, electro-mechanical-software hybrids could -be modelled; and could thus be `complete' failure mode models. -%Failure modes in components in say a sensor, could be traced -%up through the electronics and then through the controlling software. -Presently FMEA, stops at the glass ceiling of the computer program. - -This paper presents a modular variant of FMEA, Failure Mode Modular De-Composition (FMMD), a methodology which -can be applied to software, and is compatible -and integrate-able with FMMD performed on mechanical and electronic systems. +% Failure Mode Effects Analysis (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 +% at present no technique for SFMEA that +% integrates hardware and software models % known to the authors +% exists. +% % +% 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, +% review processes and language feature constraints. +% +% %This is a weakness; w +% Where FMEA % scientifically +% traces component {\fms} +% to resultant system failures, software has been left in a non-analytical +% limbo of best practises and constraints. +% % +% If software and hardware integrated FMEA were possible, electro-mechanical-software hybrids could +% be modelled; and could thus be `complete' failure mode models. +% %Failure modes in components in say a sensor, could be traced +% %up through the electronics and then through the controlling software. +% Presently FMEA, stops at the glass ceiling of the computer program. +% +% This paper presents a modular variant of FMEA, Failure Mode Modular De-Composition (FMMD), a methodology which +% can be applied to software, and is compatible +% and integrate-able with FMMD performed on mechanical and electronic systems. } \today @@ -962,6 +963,37 @@ This nested structure means that we have multiple traceable stages of failure mode reasoning in our analysis. Traditional FMEA would have only one stage of reasoning for each component failure mode. + +\section{Heuristic Comments on {\ft} Input Circuit} + +Part of the design philosophy of a {\ft} loop, is that +if anything goes wrong, we should be able to detect it. +In fact unless all electrical elements in the loop +are in working order we will detect a failure in +the majority of cases. +\subsection{Sending side of a {\ft} loop} +A current loop has to be actively maintained. If the sending side looses power, +the current will drop to zero, and thus be detectable as an error because it is below 4mA. +Should the sending circuitry fail, it is far more likely to drive too high or too low, rather than supply +an erroneous but in bounds ($4mA \ge \wedge \le 20mA$) value. +\subsection{Receiving side of a {\ft} loop} +The most common fault is disconnection, and this is easily detected ($0mA\; \le \; 4mA$--out of bounds). +Other failure modes, such as the resistor going open or shorted +also immediately push the voltage signal out of bounds. +The software side of the interface, is easy to test, either as software modules +or as an integrated system (hand-held precision current sources are cheaply available). + +\subsection{What could go wrong---Production} +PCB construction contractors are well known for random polarity placement of diodes. +Less likely is that the resistor fitted will be an incorrect value, which could +lead to the range being incorrect. Were this the case, we would have to be very unlucky +and get a value very close to our chosen \ohms{220} for this to be a problem, and +in safety critical equipment, a production test rig would pick this up. +Worse perhaps, a resistor with poor temperature coefficient could be +erroneously chosen (this would be a cheaper component), and could contribute small errors. + + + %\clearpage \section{Conclusion}