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

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. 

More generally the flow of data follows a pattern of afferent, transform and efferent. 

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


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