More proof reading. Final FMEA table still to finish
This commit is contained in:
parent
8a9d0714f7
commit
665cbe6640
@ -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
|
||||||
|
Loading…
Reference in New Issue
Block a user