JMC PR
This commit is contained in:
parent
fabd666ce7
commit
fa5821e8f3
@ -2138,6 +2138,8 @@ and ensuring the
|
||||
values are always within these bounds, we can be confident that none of the
|
||||
resistors in this circuit has failed.
|
||||
%
|
||||
\label{sec:ptbounds}
|
||||
%
|
||||
To convert these to twelve bit ADC (\adctw) counts:
|
||||
%
|
||||
$$ highreading = 2^{12}.\frac{2k2+Pt100}{2k2+2k2+pt100} $$
|
||||
@ -2163,7 +2165,7 @@ $$ lowreading = 2^{12}.\frac{2k2}{2k2+2k2+Pt100} $$
|
||||
\label{ptbounds}
|
||||
\end{table}
|
||||
%
|
||||
Table \ref{ptbounds} gives ranges that determine correct operation. In fact it can be shown that
|
||||
Table~\ref{ptbounds} gives ranges that determine correct operation. In fact it can be shown that
|
||||
for any single error (short or opening of any resistor) this bounds check
|
||||
will detect it.
|
||||
%
|
||||
|
@ -41,7 +41,7 @@ FMMD is applied to software functions by viewing them in terms of their failure
|
||||
That is to say, using FMMD, software functions are treated like {\fgs} of electronic components.
|
||||
%
|
||||
%
|
||||
As software already fits into a hierarchy we have one less analysis decision to make, when compared
|
||||
As software already fits into a hierarchy, we have one less analysis decision to make when compared
|
||||
to analysing electronics.
|
||||
%
|
||||
For electrical and mechanical systems, although we may be guided by the original designers
|
||||
@ -941,7 +941,7 @@ $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
|
||||
%
|
||||
%
|
||||
\paragraph{TIMER.}
|
||||
The internal timer, from a programmers perspective is a register, which when read
|
||||
The internal timer, from a programmer's perspective is a register, which when read
|
||||
returns an incremented time value.
|
||||
%
|
||||
Essentially its a free running integer counter with an interfacing register.
|
||||
@ -1129,8 +1129,8 @@ could be erroneous (the differential and integral parameters would effectively h
|
||||
%
|
||||
However this problem is a failure mode for the consideration of the function calling it i.e. the context of use (see section~\ref{sec:subjectiveobjective}).
|
||||
%
|
||||
That is, the \cf{PID} function is called, and the calling function is responsible for the timing,
|
||||
or in more general terms
|
||||
That is, the \cf{PID} function is called, but its calling function is responsible for the timing,
|
||||
or in more general terms,
|
||||
it is the calling function that sets the context for the \cf{PID} function (i.e. what it is used for).
|
||||
%If this PID were to be used, say as some form of low pass filter, we could consider jitter
|
||||
%for instance.
|
||||
@ -1187,8 +1187,8 @@ A {\dc} is created called HeaterOutput
|
||||
with the following failure modes:
|
||||
$$fm(HeaterOutput) = \{ HeaterOnFull, HeaterOff, HeaterOutputIncorrect \} .$$
|
||||
%
|
||||
As an aside: the $HeaterOnFull$ failure should raise alarm bells for a designers
|
||||
and upon its discovery, measure may be recommended to inhibit this (such as perhaps
|
||||
As an aside: the $HeaterOnFull$ failure should raise alarm bells for designers and
|
||||
upon its discovery, measures may be recommended to inhibit this (such as perhaps
|
||||
adding a safety relay to cut the power to the heater).
|
||||
%
|
||||
%
|
||||
@ -1207,7 +1207,7 @@ adding a safety relay to cut the power to the heater).
|
||||
%
|
||||
The status LEDS will be controlled by general purpose (GPIO) I/O pins.
|
||||
%
|
||||
We could have, three LEDS, one flashing with a human readable mark
|
||||
We could have three LEDS, one flashing with a human readable mark
|
||||
space ratio representing the heater output, one flashing at a regular interval to
|
||||
indicate the processor is alive and another flashing at an interval related to the temperature,
|
||||
(to indicate if the temperature readings are within expected ranges).
|
||||
@ -1290,7 +1290,7 @@ as an Euler diagram in figure~\ref{fig:euler_temp_controller}.
|
||||
\centering
|
||||
\includegraphics[width=400pt]{./CH5_Examples/euler_temp_controller.png}
|
||||
% euler_temp_controller.png: 714x251 pixel, 72dpi, 25.19x8.85 cm, bb=0 0 714 251
|
||||
\caption{Euler diagram of the temperature controller final anaysis stage, showing the hybrid software/hardware {\dcs} and the function at the head of the call tree `monitor'.}
|
||||
\caption{Euler diagram of the temperature controller final analysis stage, showing the hybrid software/hardware {\dcs} and the function at the head of the call tree `monitor'.}
|
||||
\label{fig:euler_temp_controller}
|
||||
\end{figure}
|
||||
%
|
||||
@ -1311,14 +1311,14 @@ The demands of EN61508~\cite{en61508} for minimum safe failure fraction threshol
|
||||
SIL levels, make this a desirable feature of any FMEA based methodology.
|
||||
%
|
||||
For the failure modes caused
|
||||
by electronics we can apply reliability statistics, and possibly use higher rated
|
||||
by electronics, we can apply reliability statistics and possibly use higher rated
|
||||
components instead of expensive re-design.
|
||||
%
|
||||
For software errors, we could, if necessary provide extra functions to provide self checking.
|
||||
We could follow EN61508 high reliability software measures such as
|
||||
duplication of functions with checking functions arbitrating them (diverse programming~\cite{en61508}[C.3.5]).
|
||||
%
|
||||
We could for instance validate the processor clocking with an external watchdog and a simple
|
||||
We could for instance, validate the processor clocking with an external watchdog and a simple
|
||||
communications protocol. For PROM and RAM faults we can implement measures such as run-time checksums
|
||||
and ram complement checking.
|
||||
%
|
||||
|
Loading…
Reference in New Issue
Block a user