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

working on JOURNAL article looking at the software FMMD

Browse Source 
and descriptions.
This commit is contained in:
Robin Clark 2015-08-22 12:42:10 +01:00
parent 12a4e0e337
commit 53e54604d4
1 changed files with 175 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

209
papers/JOURNAL_fmea_sw_hw/sw_hw_fmea.tex
View File

@ -62,12 +62,18 @@ failure mode of the component or sub-system}}}
\newcommand{\frategloss}{\glossary{name={failure rate}, description={The number of failure within a population (of size N), divided by N over a given time interval}}}
\newcommand{\pecgloss}{\glossary{name={PEC},description={A Programmable Electronic controller, will typically consist of sensors and actuators interfaced electronically, with some firmware/software component in overall control}}}
\newcommand{\bcfm}{base~component~failure~mode}
\newcommand{\cf}[1]{\textbf{#1()}}
\newcommand{\cf}[1]{{\tiny \textbf{#1()}}}
\newcommand{\swhw}{software~hardware}
\newcommand{\sw}{software}
\newcommand{\hw}{hardware}
\newcommand{\uP}{micro~processor}
\usepackage{color, colortbl}
\definecolor{Gray}{gray}{0.9}
\definecolor{LightGray}{gray}{0.97}
\definecolor{LightCyan}{rgb}{0.88,1,1}
\definecolor{Blue}{rgb}{0.0,0.0,0.7}
\definecolor{Red}{rgb}{0.9,0.0,0.0}
\definecolor{Green}{rgb}{0.0,0.5,0.0}
\def\layersep{1.8cm}
@ -1390,6 +1396,7 @@ as a complete example of an electronic/hardware hybrid analysed using FMMD. %wou
% % may be found in~\cite{dcods}[Ch.3.3].
%
\subsection{Design Stage: Implementation on a micro-controller.}
%
When designing a computer program it is often useful to
start with a system overview.
A structured analysis `Yourdon' context diagram~\cite{Yourdon:1989:MSA:62004} is presented below, see figure~\ref{fig:context_diagram_PID}.
@ -1397,7 +1404,7 @@ A Yourdon context diagram shows an overview of a system, with the data inputs an
The circle in the middle defines the processing applied to those inputs and outputs.
The context diagram can be later refined by introducing more circles with data paths between them.
Finally a {\swhw} hierarchy can be derived from a Yourdon diagram, which assists
in the design of hybrid {\swhw} systems.
in the design of the software (specifically the structure of the call tree and the hardware/software interfaces).
%
\begin{figure}[h]+
@ -1411,16 +1418,16 @@ in the design of hybrid {\swhw} systems.
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 (see section~\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~\ref{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.
%
%\fmmdglossADC
%
For the output, a Pulse Width Modulator (PWM) can be used (this is a common module found on micro-controllers
facilitating
variable power output~\cite{aoe}[p.360]).
For the output, a Pulse Width Modulator (PWM)\footnote{PWM provides a means to modulate an output i.e. very power levels}
can be used (this is a common module found on micro-controllers
facilitating variable power output~\cite{aoe}[p.360]).
%
PWM's ADC's and MUX's are commonly built into cheap micro-controllers~\cite{pic18f2523}[Ch.15].
%
@ -1445,9 +1452,11 @@ 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}.
%
The controlling software is then further refined, by looking at or zooming into transform bubbles
This is refined 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.
%
%%%%%
%%%%%
The lines connecting the `transform~bubbles' define the data passed between them.
%
When the data flow analysis is finished, each transform bubble represents a software function.
@ -1521,20 +1530,28 @@ 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 the \cf{PID} function will return an output control value to its calling
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.
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
function (i.e. the PID demand which will be returned to the monitor function).
%
%On returning to the monitor function, it will return the PID demand value.
The PID demand value will be applied via the pulse width modulation (PWM) module.
%
A rudimentary closed loop control system incorporating both hardware and software has been defined.
%A rudimentary closed loop control system incorporating both hardware and software has been defined.
With the hardware and software elements defined, and incorporated into a hierarchy, the
overall structure of the temperature controlled has now been designed.
%
By using the Yourdon methodology a programmatic design frame-work i.e. a call tree structure was obtained.
%
All the components, i.e. hardware elements and software functions
that will be used in the temperature controller are now defined.
%
These are listed, and from the bottom-up, FMMD analysis is begun.
As each of these elements can be analysed as components in FMMD
analysis can begin.
%
%These are listed, and from the bottom-up, FMMD analysis is begun.
%
\clearpage
%\subsection{FMMD Analysis of PID temperature Controller}
@ -1639,7 +1656,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{sec:readadc}),
\item --- \cf{read\_ADC} (analysed in the previous section~\ref{syssafe2012}),
\item --- \cf{output\_control} (which sets the PWM hardware according to the PID demand value).
\end{itemize}
%
@ -1662,15 +1679,15 @@ to a PID calculated heater output demand is examined.
%
\subsubsection{Afferent flow FMMD analysis, Pt100, temperature, set point error, PID output demand.}
%
Staring with the afferent data flow for the temperature readings, the lowest
Starting with the afferent data flow for the temperature readings, the lowest
level in the hierarchy is found, the Pt100 sensor.
%with the software, and consider the hardware elements
%used (if any) by each software function.
%Starting
Beginning at the bottom, a {\fg} is formed with
the function \cf{read\_ADC} and the Pt100.
This gives a {\dc}, %which we call
`Read\_Pt100'. % (see appendix~\ref{sec:readPt100}).
%
%
%
@ -1678,9 +1695,9 @@ This gives a {\dc}, %which we call
%\cf{Read\_ADC} software function and the Pt100 hardware.
%The {\dc} Read\_Pt100 is a failure mode model of the \cf{Read\_ADC} software function and the Pt100
%hardware, this
The {\dc} Read\_Pt100 has the following failure modes:
The {\dc} convert\_ADC\_to\_T has the following failure modes:
%
$$ fm (Read\_Pt100) = \{ VOLTAGE\_HIGH, VAL\_ERR, VOLTAGE\_LOW \}. $$
$$ fm (convert\_ADC\_to\_T) = \{ VOLTAGE\_HIGH, VAL\_ERR, VOLTAGE\_LOW \}. $$
%
%
Moving along the afferent flow, the \cf{convert\_ADC\_to\_T} function is next up the hierarchy.
@ -1713,21 +1730,71 @@ gives the {\dc} {Get\_Temperature}.
%
This analysis is presented in table~\ref{tbl:gettemperature}.
%
Beginning at the bottom, a {\fg} is formed with
the function \cf{read\_ADC} and the Pt100: this coresponds to the `C' function
\cf{convert\_ADC\_to\_T}.
When FMMD analysis has been performed this gives a {\dc}, named
`convert\_ADC\_to\_T'. % (see appendix~\ref{sec:readPt100}).
\begin{table}[h+]
\center
\caption{ convert\_ADC\_to\_T: Failure Mode Effects Analysis} % title of Table
\label{tbl:gettemperature}
\begin{tabular}{|| l | l | c | l ||} \hline
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
\hline
\rowcolor{LightCyan}
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
\rowcolor{LightCyan}
\textbf{} & \textbf{cause} & \textbf{Effect} & \\
\hline
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$ \\
& ADC failure & \\ \hline \hline
\cf{read\_ADC} & FC3: $RADC_{HIGH}$ & voltage value & $VOLTAGE\_HIGH$ \\
& ADC reads High & \\ \hline
\cf{read\_ADC} & 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$ \\
& in function \cf{read\_ADC} & \cf{read\_ADC} & \\ \hline
\cf{convert\_ADC\_to\_T} & FC6: post condition fails & software failure in & $VAL\_ERR$ \\
& in function \cf{convert\_ADC\_to\_T} & \cf{convert\_ADC\_to\_T} & \\ \hline
\end{tabular}
\end{table}
%\fmmdglossADC
Collecting symptoms from table~\ref{tbl:tbl:gettemperature}, the {\dc} $convert\_ADC\_to\_T$ is assigned the following failure modes:
$$
fm(convert\_ADC\_to\_T) = \{ VOLTAGE\_HIGH , VOLTAGE\_LOW, VAL\_ERR\} .
$$
%The analysis for the Pt100 circuit is presented in table~\ref{tbl:readPt100}.
%
%
Failure symptoms are collected and the {\dc} created with the following failure modes:
%
%
$$fm(Get\_Temperature) = \{ Pt100\_out\_of\_range, temp\_incorrect \} . $$
%\clearpage
%
%
Following the afferent flow further, the function to determine the control error value is examined.
%
This is simply the target temperature subtracted from that measured by the sensor.
%
A {\fg} is formed with the newly {\dc} Get\_Temperature
A {\fg} is formed with the newly formed {\dc} convert\_ADC\_to\_T
and the function \cf{determine\_set\_point\_error}.
%
The pre-condition for \cf{determine\_set\_point\_error} is that the temperature read by it
@ -1741,9 +1808,9 @@ is accurate, and its post-condition is to return the correct control error value
%
The post-condition can fail, or the temperature read could be incorrect.
%
This could be detectable (i.e. we detect a failure from the Pt100 $ Pt100\_out\_of\_range $)
This could be detectable (i.e. the symptoms $\{ VOLTAGE\_HIGH , VOLTAGE\_LOW \} $
or undetectable (i.e. the post condition for this function simply fails
or the failure mode $temp\_incorrect$ occurs).
or the failure mode $VAL\_ERR$ occurs).
%and so an incorrect value that is detected, KnownIncorrectErrorValue
%where we can detect the Pt100 value is suspect,
%and IncorrectErrorValue where there is simply
@ -1753,6 +1820,32 @@ This analysis is presented in table~\ref{tbl:geterror}.
%
%
%
\begin{table}[h+]
\center
\caption{ GetError: Failure Mode Effects Analysis} % title of Table
\label{tbl:geterror}
\begin{tabular}{|| l | l | c | l ||} \hline
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
\hline
\rowcolor{LightCyan}
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
\rowcolor{LightCyan}
\textbf{} & \textbf{cause} & \textbf{Effect} & \\
\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
\end{tabular}
\end{table}
%
Failure mode symptoms are collected and a new {\dc} GetError created
where:
@ -1789,12 +1882,50 @@ it is the calling function that sets the context for the \cf{PID} function (i.e
%HARK THE HERALD ANGELS SING... HARK????
%
%
%
\begin{table}[h+]
\center
\center
\label{tbl:geterror}
\caption{ PID: 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
\hline
\rowcolor{LightCyan}
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
\rowcolor{LightCyan}
\textbf{} & \textbf{cause} & \textbf{Effect} & \\
\hline
GetError & FC1: $KnownIncorrectErrorValue$ & safe heater control & KnownControlValueErrorV \\ \hline
GetError & FC2: $KnownIncorrectErrorValue$ & safe heater control & KnownControlValueErrorV \\ \hline
GetError & FC3: $IncorrectErrorValue$ & unsafe heater control & IncorrectControlErrorV \\ \hline
\cf{GetError} & FC6: post condition fails & software failure in & IncorrectControlErrorV \\
& in function \cf{GetError} & \cf{GetError} & \\ \hline
\end{tabular}
\end{table}
%%
The {\dc} PID is created, see table~\ref{tbl:pidfunction}, with the following failure modes:
%
$$ fm(PID) = \{ KnownControlValueErrorV, IncorrectControlErrorV \} .$$
%
%
To add some perspective here, 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.
Part of FMMD failure analysis is recognising that a design may have
undetectable errors. re-design of the modules affected can be identified by their position in the hierarchy
and thus solutions devised.
\begin{figure}[h]
\centering
\includegraphics[width=400pt]{../../submission_thesis/CH5_Examples/euler_afferent_PID.png}
@ -1812,6 +1943,8 @@ PWM/heater output.
%
\subsubsection{Efferent flow, PID demand value to PWM output}
%
The efferent dataflow, or outputs are now analysed.
%
The monitor function calls the \cf{output\_control} function with the PID demand.
%
The \cf{output\_control} function then sets the PWM hardware register, which causes the mark space output of the PWM module to
@ -1840,7 +1973,7 @@ $$fm(HeaterOutput) = \{ HeaterOnFull, HeaterOff, HeaterOutputIncorrect \} .$$
%
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).
adding a safety relay to cut the power to the heater if the $HeaterOnFull$ exceeds a given time limit).
%
%
\begin{figure}[h]
@ -1913,7 +2046,10 @@ The common causes for software failing are:
\end{itemize}
Because the software is running on a medium, that of the processor or micro-controller,
the FMMD analysis 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 \}.$$
\begin{eqnarray*}
fm (micro-controller) = \{ PROM\_FAULT, \\ RAM\_FAULT, \\ CPU\_FAULT, \\ ALU\_FAULT, \\ CLOCK\_STOPPED \}.
\end{eqnarray*}
The final FMMD stage forms a {\fg} with the {\dcs}
determined previously:
%
@ -2021,7 +2157,12 @@ can now no longer be missed or forgotten in the analysis process.
The {\sw} faces no surprise {\hw} errors that it has no sensible
way of dealing with.
Errors introduced by the {\uP} are unresolved in this example. But they are listed.
Errors introduced by the {\uP} are unresolved in this example but are listed.
Some errors like RAM are in practical terms impossible to test with a 100\% coverage.
For other errors self-checking methods linked to external watchdog processors
can validate correct working of a micro-controller
and provide a higher degree of statistical integrity.
Re-useability --- the electronics --- the Pt100 --- s/w functions to read ADC values