Created corrections reply document
This commit is contained in:
parent
53e54604d4
commit
8a9d0714f7
@ -62,7 +62,7 @@ failure mode of the component or sub-system}}}
|
|||||||
\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{\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{\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{\bcfm}{base~component~failure~mode}
|
||||||
\newcommand{\cf}[1]{{\tiny \textbf{#1()}}}
|
\newcommand{\cf}[1]{{\footnotesize \textbf{#1()}}}
|
||||||
\newcommand{\swhw}{software~hardware}
|
\newcommand{\swhw}{software~hardware}
|
||||||
\newcommand{\sw}{software}
|
\newcommand{\sw}{software}
|
||||||
\newcommand{\hw}{hardware}
|
\newcommand{\hw}{hardware}
|
||||||
@ -1585,7 +1585,7 @@ Each electronic {\dc} will be described and cited in more detail below.
|
|||||||
|
|
||||||
\paragraph{ADCMUX and Read\_ADC.}
|
\paragraph{ADCMUX and Read\_ADC.}
|
||||||
The {\dc} from \cite{syssafe2012} is re-used for this analysis. %section~\ref{readADC}.
|
The {\dc} from \cite{syssafe2012} is re-used for this analysis. %section~\ref{readADC}.
|
||||||
This analysis was performed on a `C' function which
|
This analysis was performed on a `C' function (\cf{Read\_ADC}) which
|
||||||
read a value from an analogue to digital converter (ADC) hardware element.
|
read a value from an analogue to digital converter (ADC) hardware element.
|
||||||
The analysis revealed that it could fail in three ways.
|
The analysis revealed that it could fail in three ways.
|
||||||
$$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
|
$$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
|
||||||
@ -1593,10 +1593,10 @@ $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
|
|||||||
%
|
%
|
||||||
\paragraph{TIMER.}
|
\paragraph{TIMER.}
|
||||||
%
|
%
|
||||||
The internal timer, from a programmer's perspective is a register, which when read
|
A hardware timer, from a programmer's perspective is a register, which when read
|
||||||
returns an incremented time value.
|
returns an incremented time value.
|
||||||
%
|
%
|
||||||
Essentially its a free running integer counter with an interfacing register.
|
Essentially its a free running, precisely clocked integer counter with an interfacing register.
|
||||||
%
|
%
|
||||||
Using two's complement mathematics, by subtracting
|
Using two's complement mathematics, by subtracting
|
||||||
the time last read value, we can calculate the interval
|
the time last read value, we can calculate the interval
|
||||||
@ -1647,7 +1647,10 @@ Typically there are many other I/O modules incorporated (e.g. TIMERS, UARTS, PWM
|
|||||||
In this project the ADCMUX, TIMER, PWM and general purpose computing facilities are used.
|
In this project the ADCMUX, TIMER, PWM and general purpose computing facilities are used.
|
||||||
%
|
%
|
||||||
Consider the general~computing, CLOCK, PROM and RAM failure modes:
|
Consider the general~computing, CLOCK, PROM and RAM failure modes:
|
||||||
$$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$
|
\begin{eqnarray*}
|
||||||
|
fm (micro-controller) = \{ PROM\_FAULT, \\ RAM\_FAULT, \\ CPU\_FAULT, \\ ALU\_FAULT, \\ CLOCK\_STOPPED \}.
|
||||||
|
\end{eqnarray*}
|
||||||
|
%$$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:
|
Identified Software Components:
|
||||||
@ -1722,7 +1725,7 @@ pre-defined range would be detected as an unacceptable voltage range failure.}.
|
|||||||
%
|
%
|
||||||
The post-condition is that it returns a temperature within a given tolerance to the temperature at the sensor.
|
The post-condition 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'.
|
A failure of this post-condition is that the wrong value would be returned: this {\fm} is named $VAL\_ERR$.
|
||||||
%
|
%
|
||||||
\clearpage
|
\clearpage
|
||||||
Applying FMMD to the {\fg} formed by \cf{Read\_Pt100} and the function \cf{convert\_ADC\_to\_T}.
|
Applying FMMD to the {\fg} formed by \cf{Read\_Pt100} and the function \cf{convert\_ADC\_to\_T}.
|
||||||
@ -1782,7 +1785,7 @@ When FMMD analysis has been performed this gives a {\dc}, named
|
|||||||
|
|
||||||
|
|
||||||
%\fmmdglossADC
|
%\fmmdglossADC
|
||||||
Collecting symptoms from table~\ref{tbl:tbl:gettemperature}, the {\dc} $convert\_ADC\_to\_T$ is assigned the following failure modes:
|
Collecting symptoms from table~\ref{tbl:gettemperature}, the {\dc} $convert\_ADC\_to\_T$ is assigned the following failure modes:
|
||||||
$$
|
$$
|
||||||
fm(convert\_ADC\_to\_T) = \{ VOLTAGE\_HIGH , VOLTAGE\_LOW, VAL\_ERR\} .
|
fm(convert\_ADC\_to\_T) = \{ VOLTAGE\_HIGH , VOLTAGE\_LOW, VAL\_ERR\} .
|
||||||
$$
|
$$
|
||||||
@ -1832,7 +1835,7 @@ This analysis is presented in table~\ref{tbl:geterror}.
|
|||||||
\rowcolor{LightCyan}
|
\rowcolor{LightCyan}
|
||||||
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
|
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
|
||||||
\rowcolor{LightCyan}
|
\rowcolor{LightCyan}
|
||||||
\textbf{} & \textbf{cause} & \textbf{Effect} & \\
|
\textbf{} & \textbf{cause} & \textbf{Effect} & \\ \hline
|
||||||
|
|
||||||
|
|
||||||
\hline
|
\hline
|
||||||
@ -1896,7 +1899,7 @@ it is the calling function that sets the context for the \cf{PID} function (i.e
|
|||||||
\rowcolor{LightCyan}
|
\rowcolor{LightCyan}
|
||||||
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
|
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
|
||||||
\rowcolor{LightCyan}
|
\rowcolor{LightCyan}
|
||||||
\textbf{} & \textbf{cause} & \textbf{Effect} & \\
|
\textbf{} & \textbf{cause} & \textbf{Effect} & \\ \hline
|
||||||
|
|
||||||
|
|
||||||
\hline
|
\hline
|
||||||
@ -1919,9 +1922,9 @@ To add some perspective here, if the failure mode is detectable i.e. $KnownContr
|
|||||||
it is the responsibility of the calling function to act on this and attempt a safety measure (in this case to turn off the heater and indicate an error condition).
|
it is the responsibility of the calling function to act on this and attempt a safety measure (in this case to turn off the heater and indicate an error condition).
|
||||||
Where the failure mode is not detectable the control will
|
Where the failure mode is not detectable the control will
|
||||||
in all likelihood apply an incorrect output.
|
in all likelihood apply an incorrect output.
|
||||||
Part of FMMD failure analysis is recognising that a design may have
|
A feature of the FMMD failure analysis process is that it can reveal that a design may have
|
||||||
undetectable errors. re-design of the modules affected can be identified by their position in the hierarchy
|
undetectable errors: re-design of the areas affected --- determined by where they are first recognised in the call tree --- identifies their position in the hierarchy
|
||||||
and thus solutions devised.
|
and thus solutions can be devised.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -1938,7 +1941,7 @@ and thus solutions devised.
|
|||||||
%
|
%
|
||||||
The software call tree for the afferent flow has now been modelled using FMMD;
|
The software call tree for the afferent flow has now been modelled using FMMD;
|
||||||
this is represented as an Euler diagram in figure~\ref{fig:euler_afferent_PID}.
|
this is represented as an Euler diagram in figure~\ref{fig:euler_afferent_PID}.
|
||||||
Two call tree branches remain. The LED indication branch and the
|
Two smaller call tree branches remain. The LED indication branch and the
|
||||||
PWM/heater output.
|
PWM/heater output.
|
||||||
%
|
%
|
||||||
\subsubsection{Efferent flow, PID demand value to PWM output}
|
\subsubsection{Efferent flow, PID demand value to PWM output}
|
||||||
@ -1963,9 +1966,35 @@ configured and working, and has the correct clock frequency.
|
|||||||
A second pre-condition is that the heating element is connected and working.
|
A second pre-condition is that the heating element is connected and working.
|
||||||
%
|
%
|
||||||
The post-condition is that it sets the correct value into the PWM register
|
The post-condition is that it sets the correct value into the PWM register
|
||||||
to implement the power output demand.
|
to implement the power output demand. The result of a failure in these pre or post conditions
|
||||||
%
|
would be the heater output being incorrect $HeaterOutputIncorrect$.
|
||||||
|
As the PWM controls a digital output, this could also fail by sticking HIGH or LOW
|
||||||
|
resulting in the symptoms $HeaterOnFull$ and $HeaterOff$.
|
||||||
%
|
%
|
||||||
|
\begin{table}[h+]
|
||||||
|
\center
|
||||||
|
\label{tbl:heateroutput}
|
||||||
|
\caption{ heateroutput: Failure Mode Effects Analysis} % title of Table
|
||||||
|
\begin{tabular}{|| l | l | c | l ||} \hline
|
||||||
|
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
|
||||||
|
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
|
||||||
|
\hline
|
||||||
|
\rowcolor{LightCyan}
|
||||||
|
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
|
||||||
|
\rowcolor{LightCyan}
|
||||||
|
\textbf{} & \textbf{cause} & \textbf{Effect} & \\ \hline
|
||||||
|
|
||||||
|
|
||||||
|
\hline
|
||||||
|
PWM & FC1: Output sticks HIGH & heater always on & $HeaterOnFull$ \\ \hline
|
||||||
|
PWM & FC2: Output sticks LOW & heater always off & $HeaterOff$ \\ \hline
|
||||||
|
HEATER & FC3: SHORT & heater always off & $HeaterOff$ \\ \hline
|
||||||
|
HEATER & FC4: OPEN & heater always off & $HeaterOff$ \\ \hline
|
||||||
|
\cf{heateroutput} & FC5: post condition fails & software failure in & $HeaterOutputIncorrect$ \\
|
||||||
|
& in function \cf{heateroutput} & \cf{heateroutput} & \\ \hline
|
||||||
|
|
||||||
|
\end{tabular}
|
||||||
|
\end{table}
|
||||||
%
|
%
|
||||||
A {\dc} is created called HeaterOutput, see table~\ref{tbl:heateroutput},
|
A {\dc} is created called HeaterOutput, see table~\ref{tbl:heateroutput},
|
||||||
with the following failure modes:
|
with the following failure modes:
|
||||||
@ -2006,10 +2035,6 @@ The post-condition is that the function \cf{setLEDS} will supply correct indicat
|
|||||||
%
|
%
|
||||||
A {\fg} is formed from the GPIO, the LEDs and the software function \cf{setLEDs}.
|
A {\fg} is formed from the GPIO, the LEDs and the software function \cf{setLEDs}.
|
||||||
%
|
%
|
||||||
FMMD analysis is applied to this {\fg} in table~\ref{tbl:ledoutput}.
|
|
||||||
%
|
|
||||||
%
|
|
||||||
%
|
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
\begin{figure}[h]
|
\begin{figure}[h]
|
||||||
@ -2022,7 +2047,7 @@ FMMD analysis is applied to this {\fg} in table~\ref{tbl:ledoutput}.
|
|||||||
\end{figure}
|
\end{figure}
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
The {\dc} for the setLED function, GPIO and LEDs has the following failure modes:
|
FMMD analysis is applied to this {\fg} resulting in the {\dc} for the setLED function, GPIO and LEDs has the following failure modes:
|
||||||
$$ fm(LEDoutput) = \{FailureIndicated, IndicationError \} $$
|
$$ fm(LEDoutput) = \{FailureIndicated, IndicationError \} $$
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
@ -2062,6 +2087,47 @@ determined previously:
|
|||||||
\end{itemize}
|
\end{itemize}
|
||||||
%
|
%
|
||||||
The post-condition for the monitor function is that it implements the PID control task correctly.
|
The post-condition for the monitor function is that it implements the PID control task correctly.
|
||||||
|
\begin{table}[h+]
|
||||||
|
\center
|
||||||
|
\label{tbl:heateroutput}
|
||||||
|
\caption{ heateroutput: Failure Mode Effects Analysis} % title of Table
|
||||||
|
\begin{tabular}{|| l | l | c | l ||} \hline
|
||||||
|
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
|
||||||
|
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
|
||||||
|
\hline
|
||||||
|
\rowcolor{LightCyan}
|
||||||
|
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
|
||||||
|
\rowcolor{LightCyan}
|
||||||
|
\textbf{} & \textbf{cause} & \textbf{Effect} & \\ \hline
|
||||||
|
|
||||||
|
|
||||||
|
\hline
|
||||||
|
micro-controller & FC1: $PROM\_FAULT$ & heater always on & $ControlFailure$ \\ \hline
|
||||||
|
micro-controller & FC2: $RAM\_FAULT$ & heater always off & $ControlFailure$ \\ \hline
|
||||||
|
micro-controller & FC3: $CPU\_FAULT$ & heater always off & $ControlFailure$ \\ \hline
|
||||||
|
micro-controller & FC4: $ALU\_FAULT$ & heater always off & $ControlFailure$ \\ \hline
|
||||||
|
|
||||||
|
micro-controller & FC5: $CLOCK\_STOPPED$ & heater always off & $ControlFailure$ \\ \hline
|
||||||
|
\hline
|
||||||
|
|
||||||
|
PID & & & \\ \hline
|
||||||
|
PID & & & \\ \hline
|
||||||
|
PID & & & \\ \hline
|
||||||
|
|
||||||
|
|
||||||
|
LEDOutput & & & \\ \hline
|
||||||
|
LEDOutput & & & \\ \hline
|
||||||
|
LEDOutput & & & \\ \hline
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
\cf{monitor} & FC99: post condition fails & software failure in & $ControlFailure$ \\
|
||||||
|
& in function \cf{monitor} & \cf{monitor} & \\ \hline
|
||||||
|
|
||||||
|
\end{tabular}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
|
|
||||||
%\fmmdglossCONTRACTPROG
|
%\fmmdglossCONTRACTPROG
|
||||||
A {\dc} for the standalone temperature controller is now created, and given the name TempController.
|
A {\dc} for the standalone temperature controller is now created, and given the name TempController.
|
||||||
It will have the following failure modes:
|
It will have the following failure modes:
|
||||||
|
Loading…
Reference in New Issue
Block a user