Robin_PHD/sw_as_plds/sw_as_plds.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}
%\documentclass{entcs} \usepackage{formatmacro}  \usepackage{epsfig} \usepackage{pstricks} \usepackage{subfigure} \usepackage{tikz}
%
%\newcommand{\Fam}{{\mathbb F}}
%\newcommand{\Pow}{{\mathbb P}}
%\newcommand{\Dis}{{\vee}}
%\newcommand{\Con}{{\wedge}}
%\newcommand{\FMEA}{{\bowtie}}
%
%\newcommand{\Nat}{{\mathbb N}}
%\newcommand{\Real}{{\mathbb R}}
%\newcommand{\Complex} {{\mathbb C}}
%\newcommand{\Rational} {{\mathbb Q}}
%
%%\bibliographystyle{unsrt}
%%\newtheorem{theorem}{Thoeorem}
%
%\def\lastname{Clark}
%\begin{document}
%\begin{frontmatter}
%  \title{ Software Component Failure Analysis } \author{Robin Clark\thanksref{ALL}\thanksref{r.clark@energytechnologycontrol.com}}
%  \address{ Energy Technology Control\\
%    25 North Street, Lewes, BN7 2PE, Great Britain} 
%

\ifthenelse {\boolean{paper}}
{
\begin{abstract} 
This chapter describes how software can be represented by first order logic, and how
software elements be represented in a propositional logic 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.
\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 euations and these determine the flow, or path software takes though 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. 

At a program flow stage, the software may initiate actions. Typically, in an embedded
system, a micro controller will read from external sensors, and then apply
outputs to control the equipment under supervision. 

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 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.


\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 mwethod 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
%
%
%