From 467d9b4b562eddc23f245639ab232206bcceabce Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Fri, 23 Nov 2012 21:16:46 +0000 Subject: [PATCH] Working through software FMMD --- submission_thesis/CH5_Examples/software.tex | 219 +++++++++++++++----- 1 file changed, 168 insertions(+), 51 deletions(-) diff --git a/submission_thesis/CH5_Examples/software.tex b/submission_thesis/CH5_Examples/software.tex index e0afc80..b1b1624 100644 --- a/submission_thesis/CH5_Examples/software.tex +++ b/submission_thesis/CH5_Examples/software.tex @@ -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\_$ \\ - & wrong channel & $RANGE$ \\ \hline + 4: $RADC_{LOW}$ & ADC low voltage & $OUT\_OF\_$ \\ + & so out of range & $RANGE$ \\ + & i.e. < 0.88V & \\ + \hline \hline @@ -611,6 +613,41 @@ as a hierarchical diagram, see figure~\ref{fig:eulerswhw}. % see figure~\ref{fig \label{fig:eulerswhw} \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, @@ -739,19 +776,10 @@ Identified electronic components: \item micro-controller --- the medium for running the software \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} @@ -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 \}.$$ \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 -used (if any) by each software function. +We start with the afferent flow from the Pt100. +%with the software, and consider the hardware elements +%used (if any) by each software function. 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 -\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}. -