trunk/c_hgr0/c_hgr0.tex

%$Header: /home/dashley/cvsrep/e3ft_gpl01/e3ft_gpl01/dtaipubs/esrgubka/c_hgr0/c_hgr0.tex,v 1.7 2004/03/17 01:37:52 dtashley Exp $

\chapter{The Holy Grail}

\label{chgr0}

\beginchapterquote{``It seems that mathematical ideas are arranged somehow in strata, 
                   the ideas in each stratum being linked by a complex of 
                                   relations both among themselves and with those above and below.  
                                   The lower the stratum, the deeper (and in general the more difficult)
                                   the idea.  Thus the idea of an `irrational' is deeper than that 
                                   of an integer \ldots{}  Let us concentrate our attention on 
                                   the relations between the integers, or some other group of 
                                   objects lying in some particular stratum.  
                                   Then it may happen that one of these relations can be 
                                   comprehended completely, that we can recognize and prove, 
                                   for example, some property of the integers, without any 
                                   knowledge of the contents of lower strata 
                                   \ldots{}  But there are also many theorems about integers 
                                   which we cannot appreciate properly, and still less prove, 
                                   without digging deeper and considering what happens 
                                   below.''}{G. H. Hardy, A Mathematician's Apology, 
                                   pp. 110-111\index{Hardy, G. H.}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}
%Section tag:  INT0
\label{chgr0:sint0}

Engineers in general and software engineers in particular are often
contentious and arrogant.  It is common for
embedded software developers to derogate each other's work.  The enabling
element for this type of contention is that there is \emph{no single right way}
to construct an embedded software system, and few clear unequivocal metrics
of goodness.  Without an unambiguous way of comparing different
software solutions and deciding which is better (and why), differences of
opinion and and rivalries are unavoidable.

In this chapter, we concentrate on the holy grail\footnote{In this context
we define \emph{holy grail} as an unattainable set of goals.}
of embedded software development.  We seek a set of unattainable
goals to clarify our thought processes.  We seek to identify what we are
trying to achieve in embedded software systems and in embedded software development.

There are several attributes of software in general and embedded
software in particular that make it difficult to devise unequivocal
metrics of goodness.

First, software has more degrees of freedom in its construction
than other engineering endeavors.
In \cite[p. 6]{bibref:b:boochoodwithapps}, Booch \index{Booch, Grady} writes:

\begin{quote}
\emph{``A home-building
company generally does not operate its own tree farm from which to harvest trees
for lumber; it is highly unusual for a construction firm to build an
on-site steel mill to forge custom girders for a new building.  Yet in the
software industry such practice is common.  Software offers the ultimate
flexibility, so it is possible for a developer to express almost any kind
of abstraction.  This flexibility turns out to be an incredibly seductive
property, however, because it also forces the developer to craft virtually
all the primitive building blocks upon which these higher level abstrctions
stand.  While the construction industry has uniform building codes and 
standards for the quality of raw materials, few such standards exist in the
software industry.  As a result, software development remains a labor-intensive
business.''}
\end{quote}

Additionally,  Booch writes \cite[p. 51]{bibref:b:boochoodwithapps}:

\begin{quote}
\emph{``Modules serve as the physical containers in which we declare the classes and
objects of our logical design.  This is no different than the situation faced
by the electrical engineer designing a board-level computer.  NAND, NOR, and 
NOT gates might be used to construct the necessary logic, but these gates
must be physically packaged in standard integrated circuits, such as a 7400,
7402, or 7404.  Lacking any such standard software parts, the software engineer
has considerably more degrees of freedom---as if the electrical engineer had
a silicon foundry at his or her disposal.''}
\end{quote}

Electronic hardware designers have less freedom in hardware designs than software
designers do in software designs.  Available hardware components are
naturally limited by physical phenomena, such the number of pins
that can be placed on an integrated circuit package, that tend to
limit the complexity of the connectivity between hardware components.
It is much harder
to create a truly bad hardware design than a truly bad software design.

Second, metrics of goodness are more obvious and easier to agree
on in other engineering disciplines than in software engineering.
For example, in the design of electronic hardware, serious disagreements 
among hardware
designers are rare because it is easier to reach agreement about the
measures of goodness of a hardware design.  Given two [competing] hardware
designs, it is almost always clear which is better, based on simple
critera such as cost, circuit board area, power consumption, etc.
Measures of software design goodness are less clear and obvious.

Third, software---especially small embedded software---often allows
tradeoffs between management of complexity and other desirable
attributes, such as minimum ROM consumption or the best real-time
characteristics.  In many cases, it is easy to modify software
to use less ROM or RAM or to perform better in a real-time sense,
but at the expense of a clear and consistent design (i.e. management of
complexity).
Many disagreements between software developers
arise because developers can't agree which tradeoffs should be
made between
clear structure of the software (i.e. effective management of complexity)
and other desirable attributes.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Overview Of Desirable Attributes}
%Section tag:  ODA0
\label{chgr0:soda0}

This section briefly enumerates what we consider to be the desirable
attributes of small embedded software and the product development
process and infrastructure.  Each attribute is discussed in more
detail later in the chapter.  Each desirable attribute below is 
numbered with a ``\desirablepropertyprefix'' number so that it
can be cross-referenced.

\begin{enumerate}

\item \textbf{Desirable Properties of Embedded Software}

\begin{enumerate}

\item \textbf{Minimum Program Memory Consumption   
      \desirablepropertyemit\label{dp:chgr0:soda0:minpm}.} 
          An embedded software load
      should use as little ROM or other program memory as possible.
          Microcontrollers containing more ROM are more costly, and so
          a primary goal is to minimize ROM consumption so that the
          least expensive microcontrollers can be used.

\item \textbf{Minimum RAM Consumption 
      \desirablepropertyemit\label{dp:chgr0:soda0:minram}.}
          Minimization of RAM
      consumption is a primary goal so that the least 
          expensive microcontrollers can be used.

\item \textbf{Minimum EEPROM Consumption 
      \desirablepropertyemit\label{dp:chgr0:soda0:mineeprom}.}  
          Minimization of 
      EEPROM consumption is a primary goal so that the least
          expensive microcontrollers can be used.

\item \textbf{Optimal CPU Cycle Utilization
      \desirablepropertyemit\label{dp:chgr0:soda0:bestcpucycle}.}  
          We seek to design
      systems that, for a given set of requirements, can 
      meet the requirements most efficiently with respect
      to CPU demands.  Such systems enable the use of slower [less costly]
      microcontrollers, are less likely to conceal behavior, 
          and are easier to modify.

\item \textbf{Minimal Possibility Of Concealed Behavior
      \desirablepropertyemit\label{dp:chgr0:soda0:minpconcealedbeh}.}  
          We seek to build
      software systems that are not likely to
      conceal behavior during product testing.  Systems that have a large
      ability to conceal behavior may pass product testing but
      still exhibit defects for customers.  The inability to conceal behavior
      is closely related to other desirable characteristics:

\begin{enumerate}

\item \textbf{Minimization Of State Space 
      \desirablepropertyemit\label{dp:chgr0:soda0:minss}.}  
          Many software defects are tied to
      software that holds more state than necessary.  We seek to correctly
      identify the minimum necessary state space of the software and to
          construct software that is minimally stateful.

\item \textbf{Minimization Of Scheduling Freedom
      \desirablepropertyemit\label{dp:chgr0:soda0:minschedfreedom}.}  
          We seek to minimize the way in which
      external events can affect the way software components are scheduled for
      execution.  Simpler \emph{is} better.

\item \textbf{Minimization Of Non-Linear Behavior
      \desirablepropertyemit\label{dp:chgr0:soda0:minnonlin}.}  
          Systems with 
      strongly non-linear or chaotic tendencies are undesirable.

\end{enumerate}

\item \textbf{Robustness.
      \desirablepropertyemit\label{dp:chgr0:soda0:robustness}}  
          We seek to build systems that are robust with
      respect to state upset of the controller, intermittent failure of
          sensors and actuators, modeling errors, component aging, and variable
      real-time loading of the software.

\item \textbf{Maximum Re-Usability Of Code
      \desirablepropertyemit\label{dp:chgr0:soda0:maxreusecode}.}  
          We seek to be able to re-use
      software components, and we seek to be able to develop 
          new products with a minimum of new software component development.  
          This goal related to both economy and to software quality.
      Repeatedly reinventing the wheel is expensive, and it also introduces quality
      concerns---it is more reliable to reuse software components
      that have had prolonged exposure in existing products.

\item \textbf{Testability and Instrumentability
      \desirablepropertyemit\label{dp:chgr0:soda0:testability}.}
          We desire to construct software systems that are testable and
          instrumentable.  This desirable attribute includes the detection of
          internal errors, the measurement of timing margins, and other requirements
          and best practices.

\end{enumerate}

\item \textbf{Desirable Properties of a Product Development Process}

\begin{enumerate}

\item \textbf{Minimum Development Time
      \desirablepropertyemit\label{dp:chgr0:soda0:mindevtime}.}  
          We seek to minimize the time to bring 
      product to market.

\item \textbf{Feedback Path From Defects And Near Defects To Process, Training,
      And Tools
          \desirablepropertyemit\label{dp:chgr0:soda0:feedbackpath}.}  
          We seek to be able to record defects (that make it into
      production) and near defects (that nearly make it into production),
      and feed these back into the product development process 
          (in the event that any process step could have prevented
      the defect or near defect), into the training for software developers, and into
      the tool set (if the defect or near defect is automatically detectable).

\end{enumerate}

\item \textbf{Desirable Properties of Human Environment}

\begin{enumerate}

\item \textbf{Self-Actualizing Experience for Employees
      \desirablepropertyemit\label{dp:chgr0:soda0:saexperience}.}  
          We seek to provide a self-actualizing
      experience for employees.  Any employee should leave 
          a company with far more skills
      than they had on their arrival.

\item \textbf{Best Experiences for the Top 20\% of Employees
      \desirablepropertyemit\label{dp:chgr0:soda0:betop20}.}  
          It is common knowledge that the most
      capable 20\% of software developers make 80\% of the competitive contribution.
      It is also common knowledge that this 20\% is the most sensitive to working conditions
      which impair productivity.
      We seek to make it easier for this 20\% to be the most productive.\footnote{Note that this
      notion of protecting the most productive employees is built into the work environment
      so that we don't often think of this goal.  For example, in a dentist's office, the
      dentist certainly \emph{could} schedule appointments and follow up with insurance
      claims, but economically it is more feasible to have an administrative staff do
      this.  Similarly, when obtaining technical support for a software product, one rarely reaches  
      the actual software developers.  We also do not claim that we need to identify the
      20\%, simply that we need to remove institutional productivity barriers.}

\end{enumerate}

\item \textbf{Desirable Properties of Administrative System}

\begin{enumerate}

\item \textbf{A Place For Everything, And Everything In Its Place
      \desirablepropertyemit\label{dp:chgr0:soda0:placeforeverything}.}  
          We seek administrative
      neatness and consistency.

\item \textbf{Elimination Of Redundant Information
      \desirablepropertyemit\label{dp:chgr0:soda0:lackredinfo}.}  
          Redundant information in product
      development is harmful in two ways.  First, it is tedious and costly to [manually] maintain
      the same information in different places.  Second, such an arrangement is a change
      risk, because the information may be updated in one place but not another.

\end{enumerate}

\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Detailed Description Of Desirable Attributes}
%Section tag:  DDA0
\label{chgr0:sdda0}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection[Minimum ROM, RAM, And EEPROM Consumption]
           {Minimum ROM, RAM, And EEPROM Consumption 
           (\desirablepropertycite{dp:chgr0:soda0:minpm},
                   \desirablepropertycite{dp:chgr0:soda0:minram},
                   and 
                   \desirablepropertycite{dp:chgr0:soda0:mineeprom})}
%Subsection tag:  MRE0
\label{chgr0:sdda0:mre0}

Typical inexpensive microcontrollers come in families of parts with
the same CPU core but different amounts of ROM, RAM, and EEPROM; with different
numbers of I/O pins; and often with different I/O peripherals.  
Almost invariably, members of a 
family are priced so that the parts with more capability are more expensive.

Because of the cost differential, there is often substantial pressure
on microcontroller software developers to create software which
uese as little ROM, RAM, and EEPROM as possible; so that the least
expensive parts can be used.  Additionally, it often happens that
a software load consumes nearly all the resources of the
largest available part in a family, so that no options are available
if the software cannot be made to fit.

Thus, strategies to minimize the consumption of ROM, RAM, and EEPROM
are of great interest in embedded software development.

Somewhat counterintuitively, the rigorous application of ROM-, RAM-, and
EEPROM-reduction strategies from the \emph{start} of a product development
may actually \emph{increase} the probability of a product development 
failure.  If these strategies are applied from the very start of a 
product development, there will be little or no ``fat'' left in software modules
that can be trimmed if ROM, RAM, or EEPROM limits are reached.
The rigorous application of ROM-, RAM-, and EEPROM-reduction strategies
must be accompanied by an increased respect for storage size limits.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection[Optimal CPU Cycle Utilization]
           {Optimal CPU Cycle Utilization 
           (\desirablepropertycite{dp:chgr0:soda0:bestcpucycle})}
%Subsection tag:  BCC0
\label{chgr0:sdda0:bcc0}

In many applications, it may be advantageous to use the least-capable
microcontroller with the slowest clock rate that will suffice for the
application.  The reasons that this may be advantageous are:

\begin{enumerate}
\item More capable microcontrollers are generally more costly.
\item It may be advantageous to operate a micrcontroller at less than
      the maximum allowable clock frequency.
   \begin{enumerate}
   \item A system with a higher clock rate usually consumes more power, and
         the relationship is often approximately linear.
   \item There may be certain frequencies at which the embedded system should
         not emit signals.  (For example, in an automotive application, the 
                 AM and FM radio bands are to be avoided.  If the clock frequency of
                 the system is chosen so that the frequency or a harmonic is in these
                 bands, the system must be shielded or otherwise made more expensive.)
   \end{enumerate}
\end{enumerate}

The general principles that apply to optimization for CPU-cycle efficiency are:

\begin{enumerate}
\item The mechanisms that pervade the system must be examined carefully and
      optimized.  Typical mechanisms that must be optimized are:

          \begin{enumerate}
          \item \textbf{Time measurement mechanisms.}
                The notion of \emph{time} typically pervades an
                        embedded system.  It is typical for many 
                        software components to contain state-machine logic
                        with transition functions that are functions of time.
                        Decisions about how to represent time and how to test
                        elapsed time can have a \emph{profound} effect on 
                        the performance of the system.
      \item \textbf{IPC mechanisms.}
                The mechanisms by which 
          \end{enumerate}
\end{enumerate}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection[Minimal Possibility of Concealed Behavior]
           {Minimal Possibility of Concealed Behavior 
           (\desirablepropertycite{dp:chgr0:soda0:minpconcealedbeh})}
%Subsection tag:  mpc0
\label{chgr0:sdda0:mpc0}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection[Minimization of State Space]
              {Minimization of State Space 
              (\desirablepropertycite{dp:chgr0:soda0:minss})}
%Subsubsection tag:  mss0
\label{chgr0:sdda0:mpc0:mss0}

Many embedded software defects are directly attributable to software which
holds more state than necessary.  It is a common observation that
novice programmers have difficulty in designing state-minimal 
embedded software components---in extreme cases, novice programmers have
even implemented purely combinational mappings as sequential machines.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection[Minimization of Scheduling Freedom]
              {Minimization of Scheduling Freedom 
              (\desirablepropertycite{dp:chgr0:soda0:minschedfreedom})}
%Subsubsection tag:  msf0
\label{chgr0:sdda0:mpc0:msf0}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection[Minimization of Non-Linear Behavior]
              {Minimization of Non-Linear Behavior
              (\desirablepropertycite{dp:chgr0:soda0:minnonlin})}
%Subsubsection tag:  mnl0
\label{chgr0:sdda0:mpc0:mnl0}


\subsection{Freedom From Redundant Information}


\subsection{Robustness}
\label{chgr0:sdda0:srob0}


\subsection{Maximum Re-Usability Of Source Code}


\subsection{Minimum Development Time}


\subsection{Feedback Path From Defects To Product Development Process, Training, And Tools}


%\subsection{Self-Actualizing Experience For Employees}


%\subsection{Best Experiences For The Top 20\% Of Employees}


%\subsection{Administrative Neatness}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\noindent\begin{figure}[!b]
\noindent\rule[-0.25in]{\textwidth}{1pt}
\begin{tiny}
\begin{verbatim}
$RCSfile: c_hgr0.tex,v $
$Source: /home/dashley/cvsrep/e3ft_gpl01/e3ft_gpl01/dtaipubs/esrgubka/c_hgr0/c_hgr0.tex,v $
$Revision: 1.7 $
$Author: dtashley $
$Date: 2004/03/17 01:37:52 $
\end{verbatim}
\end{tiny}
\noindent\rule[0.25in]{\textwidth}{1pt}
\end{figure}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% $Log: c_hgr0.tex,v $
% Revision 1.7  2004/03/17 01:37:52  dtashley
% Edits.
%
% Revision 1.6  2004/03/12 11:24:07  dtashley
% General edits and changes.
%
% Revision 1.5  2004/02/22 19:27:47  dtashley
% Edits.
%
% Revision 1.4  2003/03/18 06:20:34  dtashley
% Section on "robustness" labeled so could be referred to from rational counting
% algorithm section.
%
% Revision 1.3  2002/08/22 03:56:55  dtashley
% Aesthetic changes.
%
% Revision 1.2  2001/07/01 19:28:00  dtashley
% Move out of binary mode for use with CVS.
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% $History: c_hgr0.tex $
% 
% *****************  Version 3  *****************
% User: Dashley1     Date: 3/07/01    Time: 12:17a
% Updated in $/uC Software Multi-Volume Book (A)/Chapter, HGR0, Holy Grail
% Edits.
% 
% *****************  Version 2  *****************
% User: Dashley1     Date: 6/13/00    Time: 7:49p
% Updated in $/uC Software Multi-Volume Book (A)/Chapter, HGR0, Holy Grail
% Initial check-in.
% 
%End of file C_HGR0.TEX