204 lines
6.4 KiB
TeX
204 lines
6.4 KiB
TeX
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
% $Id: sw_as_plds.tex,v 1.2 2008/11/04 07:40:50 robin Exp $
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%
|
|
%
|
|
%%\documentclass{entcs} \usepackage{formatmacro} \usepackage{epsfig} \usepackage{pspicture} \usepackage{pstricks} \usepackage{subfigure} \usepackage{tikz}
|
|
|
|
\ifthenelse {\boolean{paper}}
|
|
{
|
|
\begin{abstract}
|
|
This chapter describes
|
|
the flow of data through a software system,
|
|
and how
|
|
software elements be represented in a propositional logic diagram.
|
|
When we have the software in a common notation with electrical
|
|
and mechanical systems, we can apply analysis to complete
|
|
embedded systems.
|
|
in the same diagram
|
|
When represented in this way they can be combined with other PLD's representing hardware and mechanical elements.
|
|
Thus, Fault Mode Effects Analysis (FMEA) can be applied to electro/software/mechanical systems
|
|
using a common mathematically based formal graphical notation.
|
|
Thus critical interfaces \cite{sec:interfaces} between sub-systems in different diciplines
|
|
can be modelled from a fault perspective.
|
|
\end{abstract}
|
|
}
|
|
{}
|
|
%
|
|
%\begin{keyword}
|
|
% fault~tree fault~mode EN298 EN61508 EN12067 EN230 UL1998 safety~critical logic euler venn propositional
|
|
%\end{keyword}
|
|
%\end{frontmatter}
|
|
%
|
|
|
|
\section{Introduction}
|
|
|
|
The code in software defines logical equations and these determine the flow, or path software takes through the code.
|
|
Because computer languages are very well defined, they can be viewed as formal languages.
|
|
Becuase of this, they can be mapped onto propositional logic.
|
|
|
|
Software can be viewed in terms of program flow stages.
|
|
Transitioning between one stage and another depends on decisions made from
|
|
variable states. This corresponds to the standard software structures, if-then-else
|
|
do-while etc.
|
|
|
|
Generally the flow of data follows a pattern of afferent, transform and efferent.
|
|
That is to say data is input, processed and data is output.
|
|
|
|
%At a program flow stage, the software may initiate actions.
|
|
In a safety critical control system
|
|
typically, an embedded
|
|
electro-mechanical system, a micro controller will read from external sensors, and then apply
|
|
outputs to control the equipment under supervision.
|
|
|
|
|
|
\subsection{Afferent, Transform and Afferent Data Flow}
|
|
|
|
Need a diagram showing data flow context.
|
|
|
|
Then need a diagram showing the example.
|
|
Identified functions.
|
|
Inheriting the failure modes from the hardware they read.
|
|
And then the transform function above them perhaps resolving things.
|
|
Think this should be a pt100 and temp controller example.
|
|
|
|
\subsection{Mapping the Data Flow into a PLD diagram}
|
|
|
|
Each test case in a PLD software diagram, corresponds to an action
|
|
taken by the software. This action could be to modify an internal flag or variable,
|
|
or it could be to modify an output that can actuate an action outside the micro-controller.
|
|
|
|
A simple example illustrates this, a simple micro-controller program,
|
|
that reads an IR detector and then displays status on a bank of LEDs.
|
|
Also that it has a self test IR LED, and a mechanical shutter
|
|
to prove the detector can determine dark IR conditions.
|
|
|
|
|
|
\section{Theoretical Example: Youdon to PLD}
|
|
|
|
discuss hardware or software transform of data types. Same process as far as data flow is concerned.
|
|
The two visual formats complement each other.
|
|
|
|
\begin{itemize}
|
|
\item Context diagram
|
|
\item Transform bubbles
|
|
\item software structure
|
|
\item Software structure mapped to PLD with $\mu$P failure modes
|
|
\end{itemize}
|
|
|
|
|
|
|
|
\clearpage
|
|
\begin{verbatim}
|
|
// example C code
|
|
|
|
main () {
|
|
|
|
// program flow point main #1
|
|
set_up_microcontroller_hardware();
|
|
|
|
while ( 1 ) {
|
|
|
|
// program flow point main #1.1
|
|
delay(20 milli seconds);
|
|
|
|
// program flow point main #1.2
|
|
self_test();
|
|
|
|
// program flow point main #1.3
|
|
read_inputs();
|
|
|
|
// program flow point main #1.4
|
|
if ( ir_self_test_passed ) {
|
|
|
|
// program flow point main #1.4.1
|
|
flash_green_led();
|
|
|
|
// program flow point main #1.4.2
|
|
if ( ir_detected )
|
|
// program flow point main #1.4.2.1
|
|
flash_yellow_led();
|
|
else
|
|
// program flow point main #1.4.2.2
|
|
flash_blue_led();
|
|
}
|
|
// program flow point main #1.5
|
|
else {
|
|
// program flow point main #1.5.1
|
|
flash_red_led(); // indicate internal ERROR
|
|
}
|
|
|
|
}
|
|
\end{verbatim}
|
|
|
|
\clearpage
|
|
%
|
|
% \begin{figure}[h+]
|
|
% \includegraphics[scale=0.40]{sw_as_plds/ir_det_pld.eps}
|
|
% \caption{}
|
|
% \label{fig:ir_det_pld}
|
|
% \end{figure} % OR
|
|
%
|
|
%\begin{figure}[h]
|
|
% \centering
|
|
% \includegraphics[width=400pt,bb=0 0 675 1023,keepaspectratio=true]{sw_as_plds/ir_det_pld.png}
|
|
% % ir_det_pld.png: 675x1023 pixel, 72dpi, 23.81x36.09 cm, bb=0 0 675 1023
|
|
% \caption{IR Detector C code as PLD}
|
|
% \label{fig:ir_det_pld}
|
|
%\end{figure}
|
|
%
|
|
%
|
|
%Note that the function calls in the example code, will
|
|
%each create their own PLD diagram, which can be considered as being nested in
|
|
%the main diagram.
|
|
%
|
|
%{\huge DIAGRAM REQUIRED OF NESTED DIAGRAMS FOR FUNCTION CALLS}
|
|
%Note it should be possible to automatically generate
|
|
%diagrams from code.
|
|
%Analyse C code for instance and make these types of diagrams.
|
|
%
|
|
%\subsection{Afferent, processing and Efferent flow}
|
|
%
|
|
%A concept from Yourdon dataflow analysis, is that there
|
|
%is Afferent, processing and Efferent flow.
|
|
%That is to say information comes in (afferent flow)
|
|
%is processed and the actions or data out, are the efferent flow.
|
|
%
|
|
%In a real time system, this corresponds to a hierarchy where
|
|
%electrical and mechanical systems sit at either end with the
|
|
%computer providing the processing. re-phrase.
|
|
%
|
|
%Need tree diagram here with MECH as lowest, electronics and then SW
|
|
%as typical program structure.
|
|
%{\huge DIAGRAM REQUIRED}
|
|
%
|
|
%
|
|
%
|
|
%
|
|
%\section{General Placement of Software in an Embedded System}
|
|
%
|
|
%Sw acts as transfrom flow . Sensors (electronics ) are afferent flow.
|
|
%Actuators are efferent flow.
|
|
%
|
|
%The s/w sits in the midlle.
|
|
%The s/w can apply checking to <F9>and therefore naturally sits at the top of the hierarchy.
|
|
%
|
|
%Similarities with Yourdon dataflow method here
|
|
%\clearpage
|
|
%
|
|
%%%\bibliography{vmgbibliography,mybib}
|
|
%%
|
|
%%
|
|
%%Typeset in \ \ {\huge \LaTeX} \ \ on \ \ \today
|
|
%%
|
|
%%\begin{verbatim}
|
|
%%CVS Revision Identity $Id: sw_as_plds.tex,v 1.2 2008/11/04 07:40:50 robin Exp $
|
|
%%\end{verbatim}
|
|
%%Compiled last \today
|
|
%%\end{document}
|
|
%%
|
|
%%\theend
|
|
%%
|
|
%%
|
|
%%
|