More proof reading. Final FMEA table still to finish

This commit is contained in:
Robin Clark 2015-08-23 12:43:27 +01:00
parent 8a9d0714f7
commit 665cbe6640

View File

@ -704,18 +704,21 @@ dominant computer language FORTRAN~\cite{f77} became a limiting factor.
% %
Programs written in FORTRAN became clumsy when they became large. Programs written in FORTRAN became clumsy when they became large.
% %
All variables were global. All variables were globally stored (even local function variables
which were effectively `static').
% %
A miss-spelled variable could cause chaos. Because of implicit typing miss-spelled variables could cause chaos.
% %
Also it was often difficult to pull a function Also it was often difficult to pull a function
out of one program and place it in another if it used some of the global variables. out of one program and place it in another if it used some of the global variables.
Newer computer languages were invented where modularity was encouraged. Newer computer languages were invented where modularity was encouraged.
Instead of FORTRANs global scope for variables, individual functions in a newer languages like `C' Instead of FORTRANs global scope for variables, individual functions in a newer languages like `C'
started to have `local' variables. This meant that started to have `local' variables.
%
This meant that
a programmer could take a function from a `C' program and a programmer could take a function from a `C' program and
use it in another one without complication. use it in another one without undue complication.
% %
Later languages implemented object orientation Later languages implemented object orientation
which grouped functions and data together into modules called classes, where which grouped functions and data together into modules called classes, where
@ -1030,15 +1033,15 @@ These modules can be brought together to form even larger modules.
Eventually there is one large module which represents the entire system. Eventually there is one large module which represents the entire system.
Because the terms module and sub-system are quite general term, and possibly over-used, Because the terms module and sub-system are quite general terms, and possibly over-used,
a new term has been used to take their place in FMMD. a new term has been used to take their place in FMMD.
% %
This is the `functional~group'. This is the `{\fg}'.
% %
Quite simply when identifying a group of components that perform a particular task Quite simply when identifying a group of components that perform a particular task
the term `functional~group' describes it as a group that performs a function. the term `{\fgs}' describes it as a group that performs a function.
% %
It also means that a function~group can contain other functional~groups without It also means that a function~group can contain other {\fgs} without
dragging along the semantic baggage that comes with the terms `module' and 'sub-system'. dragging along the semantic baggage that comes with the terms `module' and 'sub-system'.
@ -1063,6 +1066,13 @@ This means that failure modes can be traced through linking the
the component {\fms} that can cause them. the component {\fms} that can cause them.
% %
This gives rigorous failure mode traceability through the model. This gives rigorous failure mode traceability through the model.
This means:
\begin{itemize}
\item All failure modes must be handled by the analyst,
\item All top or system level failure symptoms can be traced back to their potential causes.
\end{itemize}
% %
@ -1072,8 +1082,8 @@ starting with individual component failure modes.
% %
That way, all component failure modes must be considered. That way, all component failure modes must be considered.
% %
If you modularise from the top down, it is not naturally follow If modularisation is performed from the top down, it does not naturally follow
bottom-level component failure modes would be handled/used. that all bottom-level component failure modes would be handled/used~\cite{faa}[Ch.9].
% %
Starting at the bottom means having to deal with each component failure mode from the beginning. Starting at the bottom means having to deal with each component failure mode from the beginning.
@ -1191,8 +1201,7 @@ access to frequency analysis of digital samples called the Fast Fourier Transfor
This took the Discrete Fourier Transform (DFT), and applied de-composition to its This took the Discrete Fourier Transform (DFT), and applied de-composition to its
mesh of (often repeated) complex number calculations~\cite{fpodsadsp}[Ch.8].} mesh of (often repeated) complex number calculations~\cite{fpodsadsp}[Ch.8].}
% %
By doing this it breaks the computing order of complexity down from having a polynomial %n exponential By modularising into a hierarchy, the computing order of complexity is broken down from having a polynomial
%order
to logarithmic order~\cite{ctw}[pp.401-3]. to logarithmic order~\cite{ctw}[pp.401-3].
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%FFT%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%FFT%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
It also means that {\fgs} are re-usable (analogous to software classes). It also means that {\fgs} are re-usable (analogous to software classes).
@ -1418,14 +1427,15 @@ in the design of the software (specifically the structure of the call tree and t
Using figure~\ref{fig:context_diagram_PID} the system in terms of its data flow is reviewed, starting Using figure~\ref{fig:context_diagram_PID} the system in terms of its data flow is reviewed, starting
with the data sources (the Pt100 temperature sensor inputs) and the data sinks (the heater output and the LED indicators). with the data sources (the Pt100 temperature sensor inputs) and the data sinks (the heater output and the LED indicators).
% %
There are two voltage inputs (for a detailed analysis and discussion of a four wire Pt100 configuration see~\ref{clark}[5]) from the Pt100 temperature sensor. There are two voltage inputs (for a detailed analysis and discussion of a four wire Pt100 configuration see~\cite{clark}[5]) from the Pt100 temperature sensor.
% %
For the Pt100 sensor, the voltages it outputs are read and %for For the Pt100 sensor, the voltages it outputs are read and %for
this requires an ADC and MUX. this requires an Analogue to digital converter\footnote{An ADC reads a voltage and converts it to
an integer made available in a readable register.} (ADC) and a multiplexer\footnote{A multiplexer takes several inputs and routes one selected input to the multiplexer output.} (MUX).
% %
%\fmmdglossADC %\fmmdglossADC
% %
For the output, a Pulse Width Modulator (PWM)\footnote{PWM provides a means to modulate an output i.e. very power levels} For the output, a Pulse Width Modulator (PWM)\footnote{PWM provides a means to modulate an output i.e. vary power levels}
can be used (this is a common module found on micro-controllers can be used (this is a common module found on micro-controllers
facilitating variable power output~\cite{aoe}[p.360]). facilitating variable power output~\cite{aoe}[p.360]).
% %
@ -1452,7 +1462,7 @@ channelled through a PWM module. %again built into the micro-controller,
% %
This next stage of model refinement is shown in figure~\ref{fig:context_diagram2_PID}. This next stage of model refinement is shown in figure~\ref{fig:context_diagram2_PID}.
% %
This is refined by looking at or zooming into transform bubbles This is performed by looking at or zooming into transform bubbles
and adding more detail i.e. following the data streams through the process, additional transform bubbles are created as required. and adding more detail i.e. following the data streams through the process, additional transform bubbles are created as required.
%%%%% %%%%%
@ -1477,7 +1487,7 @@ software architectures, a rudimentary operating system is required, often referr
% %
The `monitor' function calls the PID function at a regular and precise interval. The `monitor' function calls the PID function at a regular and precise interval.
% %
The PID function, because the algorithm depends heavily on integral calculus~\cite{dcods}[Ch.3.3] is time sensitive The PID function, because the algorithm implements integral calculus~\cite{dcods}[Ch.3.3] is time sensitive
and it is necessary to execute it at precise intervals determined by its proportional, integral and differential (PID) coefficients. and it is necessary to execute it at precise intervals determined by its proportional, integral and differential (PID) coefficients.
% %
Most micro-controllers feature several general purpose timers~\cite{pic18f2523}. Most micro-controllers feature several general purpose timers~\cite{pic18f2523}.
@ -1498,10 +1508,11 @@ functions should be called to control a process, or in `C' terms be the main fun
\end{figure} \end{figure}
% %
Using figure~\ref{fig:contextsoftware} the transform bubble Using figure~\ref{fig:contextsoftware} the transform bubble
to represent the `main' or controlling function in the software must be chosen. to represent the \cf{main}\footnote{All software functions will be written in bold with a pair of brackets
to distingish them as such. The `C' main function is thus presented as \cf{main}.}
or controlling function in the software must be chosen.
%
% %
All software functions will be written in bold with a pair of brackets
to distingish them as such. The `C' main function is thus presented as \cf{main}.
% %
This can be thought of as picking one bubble and holding it up. This can be thought of as picking one bubble and holding it up.
% %
@ -1522,7 +1533,7 @@ this is clearly going to be the \cf{monitor} function.
% %
\paragraph{Software Algorithm.} \paragraph{Software Algorithm.}
% %
The monitor function will orchestrate the control process. The \cf{monitor} function will orchestrate the control process.
% %
Firstly it will examine the timer value, and when appropriate, call the \cf{PID} function. Firstly it will examine the timer value, and when appropriate, call the \cf{PID} function.
% %
@ -1530,7 +1541,7 @@ The \cf{PID} function calls \cf{determine\_set\_point\_error} which calls \cf{co
which in turn calls \cf{Read\_ADC} (a function developed and analysed using FMMD in~\cite{syssafe2012}) which in turn calls \cf{Read\_ADC} (a function developed and analysed using FMMD in~\cite{syssafe2012})
which reads from hardware. which reads from hardware.
% %
With the set point error value\footnote{In the field of controll engineering the setpoint error value ids often simply referred to as the `error' term. With the set point error value\footnote{In the field of control engineering~\cite{dcods} the setpoint error value is often simply referred to as the `error' term.
In this context it is the difference between the target temperature and the temperature read. For instance were the target temperature In this context it is the difference between the target temperature and the temperature read. For instance were the target temperature
to be $200^{\circ} C$ and the temperature read to be $150^{\circ} C$ the error value would be $-50^{\circ} C$} to be $200^{\circ} C$ and the temperature read to be $150^{\circ} C$ the error value would be $-50^{\circ} C$}
the \cf{PID} function will return an output control value to its calling the \cf{PID} function will return an output control value to its calling
@ -1659,7 +1670,7 @@ Identified Software Components:
\item --- \cf{PID} (which calls \cf{determine\_set\_point\_error} ), \item --- \cf{PID} (which calls \cf{determine\_set\_point\_error} ),
\item --- \cf{determine\_set\_point\_error} (which calls \cf{convert\_ADC\_to\_T}), \item --- \cf{determine\_set\_point\_error} (which calls \cf{convert\_ADC\_to\_T}),
\item --- \cf{convert\_ADC\_to\_T} (which calls \cf{read\_ADC}), % which has been analysed as the {\dc} read\_ADC which can be re-used.} % from the last example), \item --- \cf{convert\_ADC\_to\_T} (which calls \cf{read\_ADC}), % which has been analysed as the {\dc} read\_ADC which can be re-used.} % from the last example),
\item --- \cf{read\_ADC} (analysed in the previous section~\ref{syssafe2012}), \item --- \cf{read\_ADC} (analysed in~\cite{syssafe2012}),
\item --- \cf{output\_control} (which sets the PWM hardware according to the PID demand value). \item --- \cf{output\_control} (which sets the PWM hardware according to the PID demand value).
\end{itemize} \end{itemize}
% %
@ -1760,20 +1771,20 @@ When FMMD analysis has been performed this gives a {\dc}, named
Pt100 & FC1: out of range reading & Pt100 voltage & $VOLTAGE\_HIGH$ \\ Pt100 & FC1: out of range reading & Pt100 voltage & $VOLTAGE\_HIGH$ \\
& from the Pt100 resistors. & outside range & $VOLTAGE\_LOW$ \\ \hline & from the Pt100 resistors. & outside range & $VOLTAGE\_LOW$ \\ \hline
\cf{read\_ADC} & FC2: $RADC_{VV_ERR}$ & voltage & $VAL\_ERR$ \\ RADC & FC2: $RADC_{VV_ERR}$ & voltage & $VAL\_ERR$ \\
& ADC failure & \\ \hline \hline & ADC failure & \\ \hline \hline
\cf{read\_ADC} & FC3: $RADC_{HIGH}$ & voltage value & $VOLTAGE\_HIGH$ \\ RADC & FC3: $RADC_{HIGH}$ & voltage value & $VOLTAGE\_HIGH$ \\
& ADC reads High & \\ \hline & ADC reads High & \\ \hline
\cf{read\_ADC} & FC4: $RADC_{LOW}$ & voltage value & $VOLTAGE\_LOW$ \\ RADC & FC4: $RADC_{LOW}$ & voltage value & $VOLTAGE\_LOW$ \\
& ADC reads low & from ADC value low & \\ \hline & ADC reads low & from ADC value low & \\ \hline
\cf{read\_ADC} & FC5: post condition fails & software failure in & $VAL\_ERR$ \\ RADC & FC5: post condition fails & software failure in & $VAL\_ERR$ \\
& in function \cf{read\_ADC} & \cf{read\_ADC} & \\ \hline & in function \cf{read\_ADC} & \cf{read\_ADC} & \\ \hline
\cf{convert\_ADC\_to\_T} & FC6: post condition fails & software failure in & $VAL\_ERR$ \\ \cf{convert\_ADC\_to\_T} & FC6: post condition fails & software failure in & $VAL\_ERR$ \\
@ -1844,8 +1855,9 @@ This analysis is presented in table~\ref{tbl:geterror}.
convert\_ADC\_to\_T & FC3: VAL\_ERR & detectable failure & $IncorrectErrorValue$ \\ \hline convert\_ADC\_to\_T & FC3: VAL\_ERR & detectable failure & $IncorrectErrorValue$ \\ \hline
\cf{GetError} & FC6: post condition fails & software failure in & $IncorrectErrorValue$ \\ \cf{determine\_sp\_error} & FC4: post condition fails & software failure in & $IncorrectErrorValue$ \\
& in function \cf{GetError} & \cf{GetError} & \\ \hline & in function & & \\
& \cf{determine\_sp\_error} & \cf{determine\_sp\_error} & \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
@ -1918,7 +1930,7 @@ The {\dc} PID is created, see table~\ref{tbl:pidfunction}, with the following fa
% %
$$ fm(PID) = \{ KnownControlValueErrorV, IncorrectControlErrorV \} .$$ $$ fm(PID) = \{ KnownControlValueErrorV, IncorrectControlErrorV \} .$$
% %
To add some perspective here, if the failure mode is detectable i.e. $KnownControlValueErrorV$ For perspective, if the failure mode is detectable i.e. $KnownControlValueErrorV$
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.
@ -1944,6 +1956,9 @@ this is represented as an Euler diagram in figure~\ref{fig:euler_afferent_PID}.
Two smaller 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}
% %
The efferent dataflow, or outputs are now analysed. The efferent dataflow, or outputs are now analysed.
@ -1974,7 +1989,7 @@ resulting in the symptoms $HeaterOnFull$ and $HeaterOff$.
\begin{table}[h+] \begin{table}[h+]
\center \center
\label{tbl:heateroutput} \label{tbl:heateroutput}
\caption{ heateroutput: Failure Mode Effects Analysis} % title of Table \caption{ HeaterOutput: Failure Mode Effects Analysis} % title of Table
\begin{tabular}{|| l | l | c | l ||} \hline \begin{tabular}{|| l | l | c | l ||} \hline
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ % \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline % \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
@ -1990,8 +2005,8 @@ PWM & FC1: Output sticks HIGH & heater always on & $
PWM & FC2: Output sticks LOW & heater always off & $HeaterOff$ \\ \hline PWM & FC2: Output sticks LOW & heater always off & $HeaterOff$ \\ \hline
HEATER & FC3: SHORT & heater always off & $HeaterOff$ \\ \hline HEATER & FC3: SHORT & heater always off & $HeaterOff$ \\ \hline
HEATER & FC4: OPEN & heater always off & $HeaterOff$ \\ \hline HEATER & FC4: OPEN & heater always off & $HeaterOff$ \\ \hline
\cf{heateroutput} & FC5: post condition fails & software failure in & $HeaterOutputIncorrect$ \\ \cf{output\_control} & FC5: post condition fails & software failure in & $HeaterOutputIncorrect$ \\
& in function \cf{heateroutput} & \cf{heateroutput} & \\ \hline & in function \cf{output\_control} & \cf{output\_control} & \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
@ -2090,7 +2105,7 @@ The post-condition for the monitor function is that it implements the PID contro
\begin{table}[h+] \begin{table}[h+]
\center \center
\label{tbl:heateroutput} \label{tbl:heateroutput}
\caption{ heateroutput: Failure Mode Effects Analysis} % title of Table \caption{ TempController: Failure Mode Effects Analysis} % title of Table
\begin{tabular}{|| l | l | c | l ||} \hline \begin{tabular}{|| l | l | c | l ||} \hline
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ % \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline % \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline