robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

More proof reading. Final FMEA table still to finish

Browse Source
This commit is contained in:
Robin Clark 2015-08-23 12:43:27 +01:00
parent 8a9d0714f7
commit 665cbe6640
1 changed files with 51 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

87
papers/JOURNAL_fmea_sw_hw/sw_hw_fmea.tex
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.
%
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
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.
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
use it in another one without complication.
use it in another one without undue complication.
%
Later languages implemented object orientation
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.
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.
%
This is the `functional~group'.
This is the `{\fg}'.
%
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'.
@ -1063,6 +1066,13 @@ This means that failure modes can be traced through linking the
the component {\fms} that can cause them.
%
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.
%
If you modularise from the top down, it is not naturally follow
bottom-level component failure modes would be handled/used.
If modularisation is performed from the top down, it does not naturally follow
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.
@ -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
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
%order
By modularising into a hierarchy, the computing order of complexity is broken down from having a polynomial
to logarithmic order~\cite{ctw}[pp.401-3].
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%FFT%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
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
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
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
%
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
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 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.
%%%%%
@ -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 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.
%
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}
%
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.
%
@ -1522,7 +1533,7 @@ this is clearly going to be the \cf{monitor} function.
%
\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.
%
@ -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 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
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
@ -1659,7 +1670,7 @@ Identified Software Components:
\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{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).
\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$ \\
& 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
\cf{read\_ADC} & FC3: $RADC_{HIGH}$ & voltage value & $VOLTAGE\_HIGH$ \\
RADC & FC3: $RADC_{HIGH}$ & voltage value & $VOLTAGE\_HIGH$ \\
& 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
\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
\cf{convert\_ADC\_to\_T} & FC6: post condition fails & software failure in & $VAL\_ERR$ \\
@ -1839,13 +1850,14 @@ This analysis is presented in table~\ref{tbl:geterror}.
\hline
convert\_ADC\_to\_T & FC1: VOLTAGE\_HIGH & detectable failure & $KnownIncorrectErrorValue$ \\ \hline
convert\_ADC\_to\_T & FC2: VOLTAGE\_LOW & detectable failure & $KnownIncorrectErrorValue$ \\ \hline
convert\_ADC\_to\_T & FC1: VOLTAGE\_HIGH & detectable failure & $KnownIncorrectErrorValue$ \\ \hline
convert\_ADC\_to\_T & FC2: VOLTAGE\_LOW & detectable failure & $KnownIncorrectErrorValue$ \\ \hline
convert\_ADC\_to\_T & FC3: VAL\_ERR & detectable failure & $IncorrectErrorValue$ \\ \hline
\cf{GetError} & FC6: post condition fails & software failure in & $IncorrectErrorValue$ \\
& in function \cf{GetError} & \cf{GetError} & \\ \hline
\cf{determine\_sp\_error} & FC4: post condition fails & software failure in & $IncorrectErrorValue$ \\
& in function & & \\
& \cf{determine\_sp\_error} & \cf{determine\_sp\_error} & \\ \hline
\end{tabular}
\end{table}
@ -1918,7 +1930,7 @@ The {\dc} PID is created, see table~\ref{tbl:pidfunction}, with the following fa
%
$$ 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).
Where the failure mode is not detectable the control will
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
PWM/heater output.
%
\subsubsection{Efferent flow, PID demand value to PWM output}
%
The efferent dataflow, or outputs are now analysed.
@ -1974,7 +1989,7 @@ resulting in the symptoms $HeaterOnFull$ and $HeaterOff$.
\begin{table}[h+]
\center
\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
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
% \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
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
\cf{output\_control} & FC5: post condition fails & software failure in & $HeaterOutputIncorrect$ \\
& in function \cf{output\_control} & \cf{output\_control} & \\ \hline
\end{tabular}
\end{table}
@ -2090,7 +2105,7 @@ The post-condition for the monitor function is that it implements the PID contro
\begin{table}[h+]
\center
\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
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline