robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Started on CiA paper

Browse Source
This commit is contained in:
Robin Clark 2013-04-20 11:22:41 +01:00
parent 33e1565cd2
commit 8876358777
3 changed files with 412 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
papers/CiA/Makefile Normal file
View File

@ -0,0 +1,17 @@
PNG = distcon.png
%.png:%.dia
dia -t png $<
all: ${PNG} distcon270.png
pdflatex cia
pdflatex cia
acroread cia.pdf || okular cia.pdf || evince cia.pdf
distcon270.png: distcon.png
convert -rotate 270 distcon.png distcon270.png
bib:
bibtex cia

395
papers/CiA/cia.tex Normal file
View File

@ -0,0 +1,395 @@
%%% OUTLINE
\documentclass[twocolumn]{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{\derivec}{{D}}
\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~grouping}
\newcommand{\FG}{\mathcal{G}}
\newcommand{\DC}{\mathcal{DC}}
\newcommand{\fgs}{functional~groupings}
\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}}
\newcommand{\fmmdgloss}{\glossary{name={FMMD},description={Failure Mode Modular De-Composition, a bottom-up methodolgy for incrementally building failure mode models, using a procedure taking functional groups of components and creating derived components representing them, and in turn using the derived components to create higher level functional groups, and so on, that are used to build a failure mode model of a system}}}
\newcommand{\fmodegloss}{\glossary{name={failure mode},description={The way in which a failure occurs. A component or sub-system may fail in a number of ways, and each of these is a
failure mode of the component or sub-system}}}
\newcommand{\fmeagloss}{\glossary{name={FMEA}, description={Failure Mode and Effects analysis (FMEA) is a process where each potential failure mode within a system, is analysed to determine system level failure modes, and to then classify them {\wrt} perceived severity}}}
\newcommand{\frategloss}{\glossary{name={failure rate}, description={The number of failure within a population (of size N), divided by N over a given time interval}}}
\newcommand{\pecgloss}{\glossary{name={PEC},description={A Programmable Electronic controller, will typically consist of sensors and actuators interfaced electronically, with some firmware/software component in overall control}}}
\newcommand{\bcfm}{base~component~failure~mode}
\newcommand{\cb}{CANbus}
\def\layersep{1.8cm}
\newboolean{pld}
\setboolean{pld}{false} % boolvar=true or false : draw analysis using propositional logic diagrams
\newboolean{dag}
\setboolean{dag}{true} % boolvar=true or false : draw analysis using directed acylic graphs
% \setlength{\topmargin}{0in}
% \setlength{\headheight}{0in}
% \setlength{\headsep}{0in}
% \setlength{\textheight}{22cm}
% \setlength{\textwidth}{18cm}
% %\setlength{\textheight}{24.35cm}
% %\setlength{\textwidth}{20cm}
% \setlength{\oddsidemargin}{0in}
% \setlength{\evensidemargin}{0in}
% \setlength{\parindent}{0.0in}
% %\setlength{\parskip}{6pt}
% % \setlength{\parskip}{1cm plus4mm minus3mm}
% \setlength{\parskip}{0pt}
% \setlength{\parsep}{0pt}
% \setlength{\headsep}{0pt}
% \setlength{\topskip}{0pt}
% \setlength{\topmargin}{0pt}
% \setlength{\topsep}{0pt}
% \setlength{\partopsep}{0pt}
% \setlength{\itemsep}{1pt}
% \renewcommand\subsection{\@startsection
% {subsection}{2}{0mm}%
% {-\baslineskip}
% {0.5\baselineskip}
% {\normalfont\normalsize\itshape}}%
\linespread{1.0}
\begin{document}
%\pagestyle{fancy}
%\fancyhf{}
%\fancyhead[LO]{}
%\fancyhead[RE]{\leftmark}
%\cfoot{Page \thepage\ of \pageref{LastPage}}
%\rfoot{\today}
%\lhead{Developing a rigorous bottom-up modular static failure mode modelling methodology}
%\lhead{Developing a rigorous bottom-up modular static failure modelling methodology}
% numbers at outer edges
\pagenumbering{arabic} % Arabic page numbers hereafter
\author{R.Clark$^\star$, C.~Garrett$^\dagger$, \\ % J.~Howse$^\dagger$ \\
$^\star${\em Energy Technology Control, UK. r.clark@energytechnologycontrol.com} \and $^\dagger${\em University of Brighton, UK}
}
%\title{Developing a rigorous bottom-up modular static failure mode modelling methodology}
\title{Applying FMEA to distributed {\cb} Systems}
%\nodate
\maketitle
\paragraph{Keywords:} static failure mode modelling; safety-critical; software fmea; SFMEA; HFMEA; CANBUS; CAN; Controller Area Network
%\small
\abstract{ This paper presents a modularised FMEA methodology suitable for analysing distributed
real time control systems.
%
It has the advantages over traditional FMEA of being able to
analyse hybrid software hardware systems, and coping with multiple failures.
%
{\cb} systems are by nature distributed control systems joined %
by a common {\cb}.
%
This means that for each {\cb} node there are at least two hardware software interfaces.
%
Because of this it is virtually impossible to apply meaningful traditional FMEA methodologies to
{\cb} systems.
%
This paper firstly highlights the limitations with traditonal FMEA,
and then describes a new modularised variant, Failure Mode Modular De-composition
which addresses the problems of software/hardware hybrid systems.
%The paper first discussed work performed on software FMEA, and then shows the need
%for a modelling methodology that can cope with mixed software hardware systems.
% \em
}
%
\section{Introduction}
\subsection{FMEA History and limitations}
Failure Mode Effects Analysis is the process of taking
component failure modes, %and by reasoning,
tracing their effects through a system
and determining what system level failures could be thus caused.
%
FMEA dates from the 1940s where simple electro-mechanical systems were the norm.
Modern control systems nearly always have a significant software/firmware element,
and not being able to model software with current FMEA methodologies
is a cause for criticism~\cite{safeware}[Ch.12]. Difficulties in integrating mechanical and electronic/software
failure models are discussed in ~\cite{SMR:SMR580}.
%
\subsection{Current work on Software FMEA}
Software FMEA (SFMEA) seeks to apply the failure effects philosophy---tracing a failure mode to a system level failure--
to software. Typically this involves speculating the effects of faulty data (variables) in the computer systems
and their resulting failure effects.
%
SFMEA usually does not seek to integrate
hardware and software models, but to perform
FMEA on the software in isolation~\cite{procsfmea}.
%
Work has been performed using databases
to track the relationships between variables
and system failure modes~\cite{procsfmeadb}, to %work has been performed to
introduce automation into the FMEA process~\cite{appswfmea} and to provide code analysis
automation~\cite{modelsfmea}.
%
Although the SFMEA and hardware FMEAs are performed separately,
some schools of thought aim for Fault Tree Analysis (FTA)~\cite{nasafta,nucfta} (top down - deductive)
and FMEA (bottom-up inductive)
to be performed on the same system to provide insight into the
software hardware/interface~\cite{embedsfmea}.
%
Although the techniques above help
give a better picture of the systems failures that software may introduce, they are
by no means a rigorous approach to tracing errors that may occur in hardware
through to the top (and therefore ultimately controlling) layers of software.
\subsection{{\cb} systems have by nature multiple software and hardware interfaces}
CanBus systems typically contain sensors, actuators and control nodes.
%
These are typically separate entities connected via {\cb}.
%
Each of these have hardware and software elements (see figure~\ref{fig:distcon});
this means that traditional FMEA methods are not suitable for analysing {\cb} systems.
%
A modularised variant of FMEA, Failure Mode Modular De-composition (FMMD)~\cite{syssafe2011} has been
designed, which addresses modelling software hardware hybrids~\cite{syssafe2012}. % and additionally multiple failures.
%
With MTTF statistics for component failures, the FMMD model can be used to produce
statistics suitable for use in a safety integrity level assessment~\cite{en61508}.
\begin{figure}[h]
\centering
\includegraphics[width=180pt]{./distcon270.png}
% discon.png: 0x0 pixel, 0dpi, nanxnan cm, bb=
\caption{Example of typical signal flow through distributed hardware and software hybrid nodes on a {\cb}.}
\label{fig:distcon}
\end{figure}
\section{Failure Mode Modular de-composition (FMMD)}
FMMD is a modularised variant of traditional FMEA.
Instead of taking each component failure mode, and analysing that in the context of the entire system,
we break the analysis problem into small modules from the bottom-up and build a modular failure mode hierarchy.
%
To modularise FMEA, we must create small modules from the bottom-up.
We can do this by taking collections of base~components that
perform (ideally) a simple and well defined task, we call these `{\fgs}'.
%
We analyse the failure mode behaviour of a {\fg}
using all the failure modes of all its components.
%
We then have the failure mode behaviour of the {\fg}---or
the symptoms of failure from the perspective of the {\fg}---
with this we treat the {\fg} as a {\dc}.
The failure modes of the {\dc} are the symptoms of failure of the {\fg} analysed.
%
%This {\dc} is typically a small module, such as an amplifier.
%
We can then use {\dcs} to build higher level {\fgs} until we have a complete hierarchical model
of the failure mode behaviour of a system.
%
An example of this process, applied to an inverting op-amp configuration
is given in~\cite{syssafe2011}.
%-------
\clearpage
%-----------------------------------------------------------
\section{How FMMD is applied to Software} % : How can we apply FMEA}
FMMD views software in terms of its functions, rather than as a set of variables.
FMMD seeks to build a hierarchical model, whereas traditional SFMEA
takes the single failure to system level error approach by
seeing variables/data as entities
which may be corrupted (and thus cause failures).
%
%If FMEA can be applied to software we can build complete failure models
%of typical modern safety critical systems.
With %modular FMEA i.e.
FMMD %(FMMD)
we have the developed concepts of failure~modes
of components, {\fgs}, symptoms of failure and {\dcs}.
%
A programmatic function has similarities with a {\fg} as defined by the FMMD process.
%
An FMMD {\fg} is placed into a hierarchy.
%
A software function is placed into a hierarchy, that of its call-tree.
%
A software function typically calls other functions and uses data sources via hardware interaction,
which could be viewed as its components.
%
It has outputs, i.e. it can perform actions
on data or hardware
which will be used by functions that may call upon it.
%
We can map a software function to a {\fg} in FMMD.
%
Its failure modes
are the failure modes of the software components (other functions it calls)
and the hardware from which it reads values. % from.
%
Its outputs are the data it changes, or the hardware actions it performs.
When we have analysed a software function---treating failure conditions
of its inputs as {\fms}---we can
determine its symptoms of failure. % (i.e. how calling functions will see its failure mode behaviour).
%
%We can thus apply the $\derivec$ function to software functions, by viewing them in terms of their failure
%mode behaviour. To simplify things, software already fits into a hierarchy.
%
For electronic and mechanical systems, although we may be guided by the original designers
concepts of modularity %and sub-systems
in design, applying FMMD means deciding on the members for {\fgs}
and the subsequent hierarchy.
%
With software already written, that hierarchy is fixed/given.
% map the FMMD concepts of {\fms}, {\fgs} and {\dcs}
%to software functions.
%
%However, we need to map a the FMMD concepts of {\fms}, {\fgs} and {\dcs}
%to software functions.
% failure modes of a function in order to
%map FMMD to software.
\subsection{Software, a natural hierarchy}
Software written for safety critical systems is usually constrained to
be modular~\cite{en61508}[vol.3] and non recursive~\cite{misra}[15.2]. %{iec61511}.
Because of this we can assume a direct call tree.
%
Functions call functions
from the top down and eventually call the lowest level library or IO
functions that interact with hardware/electronics.
What is potentially difficult with a software function is deciding what
are its failure~modes, and later what are its failure~symptoms.
%
With electronic components, we can use literature to point us to suitable sets of
{\fms}~\cite{fmd91,mil1991,en298}. %,en61508}.%~\cite{en298}.
%
With software, only some library functions are well known and rigorously documented
enough to have the equivalent of known failure modes.
Most software is `bespoke'. We need a different strategy to
describe the failure mode behaviour of software functions.
We can use definitions from contract programming to assist here.
%
\subsection{Contract programming description}
%
Contract programming is a discipline~\cite{dbcbe} for building software functions in a controlled
and traceable way. Each function is subject to pre-conditions (constraints on its inputs),
post-conditions (constraints on its outputs) and function wide invariants (rules).
%
%\paragraph{Mapping contract `pre-condition' violations to failure modes.}
%
A precondition, or requirement for a contract software function
defines the correct ranges of input conditions for the function
to operate successfully.
%
For a software function, a violation of a pre-condition is
in effect a failure mode of `one of its components'.
%
%\paragraph{Mapping contract `post-condition' violations to symptoms}
%
A post condition is a definition of correct behaviour by a function.
A violated post condition is a symptom of failure of a function.
Post conditions could be either actions performed (i.e. the state of hardware changed) or an output value of a function.
%
%\paragraph{Mapping contract `invariant' violations to symptoms and failure modes}
%
Invariants in contract programming may apply to inputs to the function (where they can be considered {\fms} in FMMD terminology),
and to outputs (where they can be considered {failure symptoms} in FMMD terminology).
An example of a hardware software hybrid analysed by FMMD may be found in~\cite{syssafe2012}.
%-----------------------------------------------------------------------
\subsection{{\cb} as modelled by FMMD}
{\cb} interfaces are modelled as components in the system in an FMMD analysis, and therefore
contribute their own failure modes.
A {\cb} node analysed by FMMD, will as the result of the failure modes of its top of hierarchy {\dc},
have a list of {\fms}. These {\fms} represent the ways in which this particular system element can fail,
and would assist a designer in formulating the error codes to return in the status words for that {\cb} node.
\section{Example {\cb} system}
-------------------------------------------------------------------
-------------------------------------------------------------------
-------------------------------------------------------------------
Pick an example here and then analyse it at a high level.
-------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------------------------------------------
\subsection{FMMD analysis hierarchy}
-------------------------------------------------------------------
-------------------------------------------------------------------
-------------------------------------------------------------------
Provide some details about how the model can be used
to model failures and their causes, and SIL.
-------------------------------------------------------------------
--------------------------------------------------------------------
------------------------------------------------------------------
\section{Conclusions}.
Advantages of applying FMMD to {\cb}:
\begin{itemize}
\item complete failure mode model of the system including software and {\cb} elements.
\item analysis is re-usable, up to canbus node level
\item multiple failures can be modelled, allowing the theoretical impact of redundant systems to be assessed
\item MTTF component statistics used in conjunction with the FMMD model allow SIL assessments.
\end{itemize}
\nocite{en298}
\nocite{en61508}
{
\footnotesize
\bibliographystyle{plain}
\bibliography{../../vmgbibliography,../../mybib}
}
%\today
\end{document}

BIN
papers/CiA/distcon.dia Normal file
View File

Binary file not shown.