OK nearly got the software PID example
finished, one last push....
This commit is contained in:
Robin Clark
parent
08fad4c2f9
commit
dbac2af119
36
mybib.bib
36
mybib.bib
@ -1,3 +1,39 @@
|
||||
@INPROCEEDINGS{5488118,
|
||||
author={Pace, C. and Libertino, S. and Crupi, I. and Marino, A. and Lombardo, S. and Sala, E.D. and Capuano, G. and Lisiansky, M. and Roizin, Y.},
|
||||
booktitle={Instrumentation and Measurement Technology Conference (I2MTC), 2010 IEEE}, title={Compact instrumentation for radiation tolerance test of flash memories in space environment},
|
||||
year={2010},
|
||||
month={may},
|
||||
volume={},
|
||||
number={},
|
||||
pages={652 -655},
|
||||
keywords={FPGA-based design;compact instrumentation;failure data screening;flash memories;latch-up protection;nonvolatile memory arrays;radiation tolerance test;space environment;flash memories;radiation hardening (electronics);random-access storage;tolerance analysis;},
|
||||
doi={10.1109/IMTC.2010.5488118},
|
||||
ISSN={1091-5281},}
|
||||
|
||||
@INPROCEEDINGS{5963919,
|
||||
author={Ghahroodi, M.M. and Zwolinski, M. and Ozer, E.},
|
||||
booktitle={Adaptive Hardware and Systems (AHS), 2011 NASA/ESA Conference on}, title={Radiation hardening by design: A novel gate level approach},
|
||||
year={2011},
|
||||
month={june},
|
||||
volume={},
|
||||
number={},
|
||||
pages={74 -79},
|
||||
keywords={SEU tolerant flip-flop design;SEU-tolerant clock-gating scheme;TMR;area-power overheads;electronic circuits;electronic systems;gate level approach;radiation-hardening techniques;sea-level applications;single-event-upset tolerant flip-flop design;size 65 nm;triple modular redundancy;flip-flops;integrated circuit reliability;logic design;radiation hardening (electronics);},
|
||||
doi={10.1109/AHS.2011.5963919},
|
||||
ISSN={},}
|
||||
|
||||
@INPROCEEDINGS{swseatbelt,
|
||||
author={Emery D Berger},
|
||||
booktitle={Communications of the ACM}, title={Software needs seatbelts and Airbags},
|
||||
year={2012},
|
||||
month={september},
|
||||
volume={},
|
||||
number={},
|
||||
pages={48 - 56},
|
||||
keywords={software reliability},
|
||||
ISSN={Doi:10.1145/2330667.2330683},}
|
||||
|
||||
|
||||
@Book{dcods,
|
||||
author = {Franklin,Powell,Workman},
|
||||
title = {Digital Control of Dynamic Systems},
|
||||
|
||||
@ -33,7 +33,7 @@ of its inputs as failure modes---we can
|
||||
determine its symptoms of failure (i.e. how calling functions will see its failure mode behaviour).
|
||||
|
||||
%
|
||||
We apply the FMMD process to software functions by viewing them in terms of their failure mode behaviour.
|
||||
We apply the FMMD process to software functions by viewing them in terms of their failure mode behaviour.
|
||||
%
|
||||
As software already fits into a hierarchy we have one less analysis decision to make, compared
|
||||
to analysing electronics.
|
||||
@ -601,9 +601,9 @@ software component $read\_4\_20\_input$, i.e. $G_3 = \{read\_4\_20\_input, RADC\
|
||||
& i.e. < 0.88V & \\
|
||||
\hline
|
||||
|
||||
5: post condition fails & software fails & $VAL\_ERR$ \\ \hline
|
||||
|
||||
\hline
|
||||
|
||||
|
||||
\hline
|
||||
|
||||
\end{tabular}
|
||||
@ -755,6 +755,7 @@ For the output, we can use a Pulse Width Modulator (PWM) (this is a common modul
|
||||
allowing a variable power output~\cite{pwm}). PWM's ADC's and MUX's are commonly built into cheap micro-controllers~\cite{pic18f2523}.
|
||||
We can now build more detail into the Yourdon diagram, with the afferent data flow coming through the MUX and ADC on the micro-controller, and the efferent
|
||||
channelled through a PWM module, %again built into the micro-controller,
|
||||
%
|
||||
see figure~\ref{fig:context_diagram2_PID}.
|
||||
\begin{figure}[h]+
|
||||
\centering
|
||||
@ -837,8 +838,9 @@ Identified electronic components:
|
||||
\item HEATER --- Heating element, essentially a resistor.
|
||||
\item Pt100 --- Pt100 Temperature sensor, as analysed in section~\ref{sec:Pt100}.
|
||||
\item PWM --- Internal micro controller pulse width modulation module
|
||||
\item General Purpose I/O (GPIO) ---
|
||||
\item LEDs --- Indication LEDs via GPIO
|
||||
\item micro-controller --- the medium for running the software
|
||||
\item setLEDs --- Set status indication LEDs via GPIO
|
||||
\end{itemize}
|
||||
|
||||
|
||||
@ -1297,12 +1299,74 @@ We apply FMMD analysis to this {\fg} in table~\ref{tbl:ledoutput}.
|
||||
|
||||
|
||||
|
||||
\subsubsection{Final Analysis Stage: PID Temperature Controller}
|
||||
|
||||
The possibility of each software function failing its post condition without a direct
|
||||
underlying cause from one of its components has been included in each analysis stage
|
||||
involving software. This is because software introduces the possibility of
|
||||
anything going wrong! The common causes for software failing are:
|
||||
\begin{itemize}
|
||||
\item Value/RAM corruption typically from interrupt contention problems or accidental over writing~\cite{swseatbelt},
|
||||
but can be from external sources such as radiation changing bits/values at runtime~\cite{5963919, 5488118};
|
||||
\item Address bus errors leading to program errors (program sequence);
|
||||
\item ROM memory failures;
|
||||
\item Unintended behaviour of software.
|
||||
\end{itemize}
|
||||
Because the software is running on a medium, that of the processor or micro-controller
|
||||
our design at the final or highest level (see table~\ref{tbl:pid}), must include all possible failure modes of this medium i.e.
|
||||
$$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$
|
||||
We perform the final FMMD stage by forming a functional group with the {\dcs}
|
||||
determined previously:
|
||||
%
|
||||
\begin{itemize}
|
||||
\item PID
|
||||
\item HeaterOutput
|
||||
\item LEDoutput
|
||||
\item and the function `monitor'.
|
||||
\end{itemize}
|
||||
|
||||
The post condition for the monitor function is that it implements the PID control task correctly.
|
||||
|
||||
|
||||
{
|
||||
\tiny
|
||||
\begin{table}[h+]
|
||||
\caption{ PID standalone controller: Failure Mode Effects Analysis} % title of Table
|
||||
\label{tbl:pid}
|
||||
|
||||
|
||||
|
||||
|
||||
\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: $ Temp LED fails $ & LED will not light & FailureIndicated \\
|
||||
& & \\ \hline
|
||||
|
||||
|
||||
FC2: $ Processor LED fails $ & LED will not light & FailureIndicated \\
|
||||
& & \\ \hline
|
||||
|
||||
FC3: $ PWM LED fails $ & LED will not light & FailureIndicated \\
|
||||
& & \\ \hline
|
||||
|
||||
FC4: GPIO stuck HIGH & LED permanently OFF & FailureIndicated \\ \hline
|
||||
|
||||
|
||||
FC5: GPIO stuck Low & LED permanently ON & FailureIndicated \\ \hline
|
||||
|
||||
|
||||
FC6: Software SetLEDs & Incorrect Indication & IndicationError \\
|
||||
fails to set outputs correctly & Post condition failure & \\ \hline
|
||||
|
||||
|
||||
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user