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

Working through software FMMD

Browse Source
This commit is contained in:
Robin Clark 2012-11-23 21:16:46 +00:00
parent fc89b68499
commit 467d9b4b56
1 changed files with 168 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

219
submission_thesis/CH5_Examples/software.tex
View File

@ -555,8 +555,10 @@ software component $read\_4\_20\_input$, i.e. $G_3 = \{read\_4\_20\_input, RADC\
4: $RADC_{LOW}$ & ADC may read & $OUT\_OF\_$ \\ 4: $RADC_{LOW}$ & ADC low voltage & $OUT\_OF\_$ \\
& wrong channel & $RANGE$ \\ \hline & so out of range & $RANGE$ \\
& i.e. < 0.88V & \\
\hline
\hline \hline
@ -611,6 +613,41 @@ as a hierarchical diagram, see figure~\ref{fig:eulerswhw}. % see figure~\ref{fig
\label{fig:eulerswhw} \label{fig:eulerswhw}
\end{figure} \end{figure}
\subsection{Conclusion: {\ft} Reader Software/Hardware FMMD Model}
The {\dc} representing the {\ft} reader
in software shows that by FMMD, we can integrate
software and electro-mechanical FMMD models.
With this analysis
we have a complete `reasoning~path' linking the failures modes from the
electronics to those in the software.
Each functional group to {\dc} transition represents a
reasoning stage.
%
Each reasoning stage will have an associated analysis report.
%
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. This is exacerbated by the fact that traditional SFMEA is
performed separately from HFMEA~\cite{sfmea,sfmeaa}, additionally even the software/hardware
interfacing is treated as a separate FMEA task~\cite{sfmeainterface,embedsfmea,procsfmea}
We now have a {\dc} for a {\ft} input in software.
Typically, more than one such input could be present in a real-world system.
Not only have we integrated electronics and software in an FMEA, we can also
re-use the analysis for each {\ft} input in the system.
The unsolved symptoms, or unobservable errors, i.e. $VAL\_ERR$ could be addressed
by another software function to read other known signals
via the MUX (i.e. voltage references). This strategy would
detect ADC\_STUCK\_AT and MUX\_FAIL failure modes.
A software specification for a hardware interface will concentrate on
how to interpret raw readings, or what signals to apply for actuators.
Using FMMD we can determine an accurate failure model for the interface as well~\cite{sfmeainterface}.
%HTR 18NOV2012 We can represent %the hierarchy in figure~\ref{fig:hd} algebraically, %HTR 18NOV2012 We can represent %the hierarchy in figure~\ref{fig:hd} algebraically,
@ -739,19 +776,10 @@ Identified electronic components:
\item micro-controller --- the medium for running the software \item micro-controller --- the medium for running the software
\end{itemize} \end{itemize}
Identified Software Components:
\begin{itemize}
\item --- Monitor (which calls PID algorithm and sets status LEDS)
\item --- PID (which calls determine\_set\_point\_error and output\_control)
\item --- determine\_set\_point\_error (which calls convert\_ADC\_to\_T)
\item --- convert\_ADC\_to\_T (which calls read\_ADC which we can re-use from the last example)
\item --- read\_ADC
\item --- output\_Control (which sets the PWM hardware according to the PID demand value)
\end{itemize}
With the call tree structure, we can now analyse these
components from the bottom-up, starting with the electronics.
\subsection{Temperature Controller Hardware Elements FMMD} \subsection{Temperature Controller Hardware Elements FMMD}
@ -797,50 +825,139 @@ We have to therefore consider the general~computing, CLOCK, PROM and RAM failure
$$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$ $$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$
\subsection{Temperature Controller Software Elements FMMD} \subsection{Temperature Controller Software Elements FMMD}
Identified Software Components:
\begin{itemize}
\item --- Monitor (which calls PID algorithm and sets status LEDS)
\item --- PID (which calls determine\_set\_point\_error and output\_control)
\item --- determine\_set\_point\_error (which calls convert\_ADC\_to\_T)
\item --- convert\_ADC\_to\_T (which calls read\_ADC which we can re-use from the last example)
\item --- read\_ADC
\item --- output\_Control (which sets the PWM hardware according to the PID demand value)
\end{itemize}
With the call tree structure defined (see figure~\ref{fig:context_calltree}), we can now analyse these
components from the bottom-up, starting with the electronics.
We must start from the bottom-up with the software, and consider the hardware elements We start with the afferent flow from the Pt100.
used (if any) by each software function. %with the software, and consider the hardware elements
%used (if any) by each software function.
Starting at the bottom we form a {\fg} with Starting at the bottom we form a {\fg} with
the function read\_ADC. the function read\_ADC and the Pt100.
This gives us a {\dc} we shall call ReadPt100.
{
\tiny
\begin{table}[h+]
\caption{ Read\_Pt100: Failure Mode Effects Analysis} % title of Table
\label{tbl:readPt100}
\begin{tabular}{|| l | c | l ||} \hline
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
\hline
\textbf{Failure} & \textbf{Failure } & \textbf{Derived Component} \\
\textbf{cause} & \textbf{Effect} & \textbf{Failure Mode} \\
\hline
FC1: $RI_{VRGE}$ & voltage & $VOLTAGE\_HIGH$ \\
& outside range & \\ \hline
FC2: $RADC_{VV_ERR}$ & voltage & $VAL\_ERR$ \\
& incorrect & \\ \hline \hline
FC3: $RADC_{HIGH}$ & voltage value & $VAL\_ERR$ \\
& incorrect & \\ \hline
FC4: $RADC_{LOW}$ & ADC may read & $VOLTAGE\_LOW$ \\ \hline
\end{tabular}
\end{table}
}
The {\dc} Read\_Pt100 is a failure mode model of the Read\_ADC function and the Pt100
hardware, and has the following failure modes:
$$ fm (Read\_Pt100) = \{ VOLTAGE\_HIGH, VAL\_ERR, VOLTAGE\_LOW \}. $$
We can now move along in the afferent flow, and we come to the convert\_ADC\_to\_T function.
This will call Read\_ADC thrice, one for the high Pt100 value, again for the lower and once for to read a current sense.
This will then, calculate the resistance of the Pt100 element---using a
polynomial or a lookup table---and calculate the temperature.
The pre-conditions for the function are that:
\begin{itemize}
\item The current calculated is within pre-defined bounds i.e. Pt100\_current,
\item The lower Pt100 value is within an acceptable voltage range i.e. Pt100\_lower\_voltage,
\item The higher Pt100 value is within an acceptable voltage range i.e. Pt100\_higher\_voltage,
\item The Lower and higher values agree to within a given tolerance i.e. Pt100\_high\_low\_mismatch.
\end{itemize}
Any violation of these pre-conditions is equivalent to a failure mode.
Note that a temperature outside the pre-defined range will also cause these errors.
The postcondition is that it returns a temperature within a given tolerance to the temperature at the sensor.
A failure of this post-condition can be termed temp\_incorrect.
We now apply FMMD to the {\fg} formed by Read\_Pt100 and the function convert\_ADC\_to\_T.
We can call the resulting {\dc} Get\_Temperature.
{
\tiny
\begin{table}[h+]
\caption{ Get\_Temperature: Failure Mode Effects Analysis} % title of Table
\label{tbl:gettemperature}
\begin{tabular}{|| l | c | l ||} \hline
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
\hline
\textbf{Failure} & \textbf{Failure } & \textbf{Derived Component} \\
\textbf{cause} & \textbf{Effect} & \textbf{Failure Mode} \\
\hline
FC1: $Pt100:Voltage\_High$ & Pt100 voltage too high & Pt100\_out\_of\_range \\
& Pt100\_higher\_voltage & \\
& OR Pt100\_current & \\ \hline
FC2: $Pt100:Voltage\_Low$ & Pt100 voltage too low & Pt100\_out\_of\_range \\
& Pt100\_lower\_voltage & \\
& OR Pt100\_current & \\ \hline
FC3: $Pt100\_high\_low\_mismatch$ & temperature can be calculated & Pt100\_out\_of\_range \\
& from either high or low & \\
& reading, but should correlate & \\ \hline
FC4: $Pt100\_current$ & the current applied is & Pt100\_out\_of\_range \\
& necessary to calculate resistance, & \\
& but should be within given bounds & \\ \hline
FC4: $Pt100:VAL\_ERR$ & could cause an out of & temp\_incorrect\\
& range error, but may also & \\
& cause us to read an & \\
& incorrect temperature & \\ \hline
\hline
\end{tabular}
\end{table}
}
We now collect the failure symptoms for the {\dc} Get\_Temperature and can state:
$$fm(Get\_Temperature) = \{ Pt100\_out\_of\_range, temp\_incorrect \}$$
%\clearpage %\clearpage
\section{Conclusion: Software/Hardware FMMD Model}
The {\dc} representing the {\ft} reader
in software shows that by FMMD, we can integrate
software and electro-mechanical FMMD models.
With this analysis
we have a complete `reasoning~path' linking the failures modes from the
electronics to those in the software.
Each functional group to {\dc} transition represents a
reasoning stage.
%
Each reasoning stage will have an associated analysis report.
%
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. This is exacerbated by the fact that traditional SFMEA is
performed separately from HFMEA~\cite{sfmea,sfmeaa}, additionally even the software/hardware
interfacing is treated as a separate FMEA task~\cite{sfmeainterface,embedsfmea,procsfmea}
We now have a {\dc} for a {\ft} input in software.
Typically, more than one such input could be present in a real-world system.
Not only have we integrated electronics and software in an FMEA, we can also
re-use the analysis for each {\ft} input in the system.
The unsolved symptoms, or unobservable errors, i.e. $VAL\_ERR$ could be addressed
by another software function to read other known signals
via the MUX (i.e. voltage references). This strategy would
detect ADC\_STUCK\_AT and MUX\_FAIL failure modes.
A software specification for a hardware interface will concentrate on
how to interpret raw readings, or what signals to apply for actuators.
Using FMMD we can determine an accurate failure model for the interface as well~\cite{sfmeainterface}.