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