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

software fmea.....started BUT IN LATEX

Browse Source
This commit is contained in:
Robin Clark 2012-07-29 21:14:21 +01:00
parent cb0d63b4b7
commit 5db87d00d5
2 changed files with 83 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
mybib.bib
View File

@ -55,6 +55,13 @@ Baiqiao HUANG
Software FMEA Approach Based on Failure Modes
Database
@ARTICLE{sfmeaauto,
AUTHOR = "Barbara J. Czerny et all. Delphi Corporation.",
TITLE = "Effective Application of Software Safety Techniques for Automotive Embedded Control Systems",
JOURNAL = "Occupant Safety, Safety-Critical Systems, and Crashworthiness (SP-1923)",
YEAR = "2005"
}
@ARTICLE{procsfmeadb,
AUTHOR = "Baiqiao HUANG",
TITLE = "Software FMEA Approach Based on Failure Modes Database",
@ -62,7 +69,6 @@ Database
YEAR = "2009"
}
@BOOK{misra,
AUTHOR = "Gavin McCall",
TITLE = "MISRA:C:2004 Guidelines for the use of the C language in critical systems ISBN 978-0-9524156-4-0 ",

75
papers/fmea_software_hardware/software_fmea.tex
View File

@ -109,7 +109,7 @@ failure mode of the component or sub-system}}}
}
%\title{Developing a rigorous bottom-up modular static failure mode modelling methodology}
\title{Applying Failure Mode Effects Analysis (FMEA) across the Software/Hardware Interface}
\title{Applying Failure Mode Effects Analysis (FMEA) to Software/Hardware Hybrid Systems}
%\nodate
\maketitle
@ -534,7 +534,7 @@ from knowledge of the software systems criteria for these.
\section{Software FMEA - variables in place of components}
For software FMEA we take the variables used by the system,
and examine what could happen if they are corrupted.
and examine what could happen if they are corrupted in various ways~\cite{procsfmea, embedsfmea}.
From the function $read\_4\_20\_input()$ we have the variables $error\_flag$,
$input\_volts$ and $value$: from the function $read\_ADC()$, $timeout$, $ADCMUX$, $ADCGO$, $dval$.
We must now determine putative system failure modes for these variables becoming corrupted.
@ -544,14 +544,14 @@ We must now determine putative system failure modes for these variables becoming
\tiny
\begin{table}[h+]
\caption{SFMEA {\ft}} % title of Table
\label{tbl:r420i}
\label{tbl:sfmea}
\begin{tabular}{|| l | c | l ||} \hline
\textbf{Failure} & \textbf{failure} & \textbf{System Failure} \\
\textbf{Scenario} & \textbf{effect} & \\ \hline
\hline
$error\_flag$ & set FALSE & $VAL\_ERROR$ \\
& & error flag \\ \hline
& & \\ \hline
$error\_flag$ & set TRUE & invalid \\
& & error flag \\ \hline
@ -591,12 +591,60 @@ We must now determine putative system failure modes for these variables becoming
\section{Software FMEA - failure modes of the medium ($\mu P$) of the software}
Microprocessors/Microcontrollers have sets of known failure modes, these include RAM, ROM
EEPROM failure,
oscillator clock timing
EEPROM failure\footnote{EEPROM failure is not applicable for this example.} and
oscillator clock timing~\cite{sfmeaauto}.
{
\tiny
\begin{table}[h+]
\caption{SFMEA {\ft}} % title of Table
\label{tbl:sfmeaup}
\begin{tabular}{|| l | c | l ||} \hline
\textbf{Failure} & \textbf{failure} & \textbf{System Failure} \\
\textbf{Scenario} & \textbf{effect} & \\ \hline
\hline
$RAM$ & variable corruption & All errors \\
& & from table~\ref{tbl:sfmea} \\ \hline
$RAM$ & program flow & process \\
& & halts / crashes \\ \hline
$OSC$ & stopped & process \\
& & halts \\ \hline
$OSC$ & too & ADC \\
& fast & value errors \\ \hline
$OSC$ & too & ADC \\
& slow & value errors \\ \hline
$ROM$ & program & All errors \\
& corruption & from table~\ref{tbl:sfmea} \\ \hline
$ROM$ & constant & All errors \\
& /data corruption & from table~\ref{tbl:sfmea} \\ \hline
\hline
\end{tabular}
\end{table}
}
\section{Software FMEA - The software hardware interface}
As FMEA is applied separately to software and hardware
the interface between them is an undefined factor.
Ozarin~\cite{sfmeainterface} recommends that an FMEA report be written
to focus on the software/hardware interface.
The hardware to software interface for the {\ft} example is handled
by the 'C' function $read\_ADC()$.
\section{Conclusion}
%
@ -604,8 +652,11 @@ The FMMD method has been demonstrated using an the industry standard {\ft}
input circuit and software.
%
The {\dc} representing the {\ft} reader
shows that by taking a modular approach for FMEA, i.e. FMMD, we can integrate
software and electro-mechanical models.
shows that by taking a
%modular approach for FMEA, i.e. FMMD, we can integrate
four FMEA reports we can model the failure mode behaviour from
several perspectives, for
software and electrical systems% models.
%
With this analysis
we have stages along the `reasoning~path' linking the failure modes from the
@ -613,11 +664,19 @@ electronics to those in the software.
Each {\fg} to {\dc} transition represents a
reasoning stage.
%
%
With traditional FMEA methods the reasoning~distance is large, because
it stretches from the component failure mode to the top---or---system level failure.
%For this reason applying traditional FMEA to software stretches
%the reasoning distance even further.
%
In fact these reasoning paths overlap ---or even by-pass one another---
it is very difficult to gauge cause and effect. For instance
were the ADC to have a small value error, say adding
a small percentage onto the value, we would be unable to
detect this under the analysis conditions for this model, or
be able to pinpoint it.
{