# Annotation of /pubs/books/ucbka/trunk/c_hgr0/c_hgr0.tex

Wed Aug 14 23:10:36 2019 UTC (4 years, 9 months ago) by dashley
File MIME type: application/x-tex
File size: 21144 byte(s)
Change keyword substitution (migration from cvs to svn).

 1 dashley 140 %$Header$ 2 3 \chapter{The Holy Grail} 4 5 \label{chgr0} 6 7 \beginchapterquote{It seems that mathematical ideas are arranged somehow in strata, 8 the ideas in each stratum being linked by a complex of 9 relations both among themselves and with those above and below. 10 The lower the stratum, the deeper (and in general the more difficult) 11 the idea. Thus the idea of an irrational' is deeper than that 12 of an integer \ldots{} Let us concentrate our attention on 13 the relations between the integers, or some other group of 14 objects lying in some particular stratum. 15 Then it may happen that one of these relations can be 16 comprehended completely, that we can recognize and prove, 17 for example, some property of the integers, without any 18 knowledge of the contents of lower strata 19 \ldots{} But there are also many theorems about integers 20 which we cannot appreciate properly, and still less prove, 21 without digging deeper and considering what happens 22 below.''}{G. H. Hardy, A Mathematician's Apology, 23 pp. 110-111\index{Hardy, G. H.}} 24 25 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 26 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 27 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 28 \section{Introduction} 29 %Section tag: INT0 30 \label{chgr0:sint0} 31 32 Engineers in general and software engineers in particular are often 33 contentious and arrogant. It is common for 34 embedded software developers to derogate each other's work. The enabling 35 element for this type of contention is that there is \emph{no single right way} 36 to construct an embedded software system, and few clear unequivocal metrics 37 of goodness. Without an unambiguous way of comparing different 38 software solutions and deciding which is better (and why), differences of 39 opinion and and rivalries are unavoidable. 40 41 In this chapter, we concentrate on the holy grail\footnote{In this context 42 we define \emph{holy grail} as an unattainable set of goals.} 43 of embedded software development. We seek a set of unattainable 44 goals to clarify our thought processes. We seek to identify what we are 45 trying to achieve in embedded software systems and in embedded software development. 46 47 There are several attributes of software in general and embedded 48 software in particular that make it difficult to devise unequivocal 49 metrics of goodness. 50 51 First, software has more degrees of freedom in its construction 52 than other engineering endeavors. 53 In \cite[p. 6]{bibref:b:boochoodwithapps}, Booch \index{Booch, Grady} writes: 54 55 \begin{quote} 56 \emph{A home-building 57 company generally does not operate its own tree farm from which to harvest trees 58 for lumber; it is highly unusual for a construction firm to build an 59 on-site steel mill to forge custom girders for a new building. Yet in the 60 software industry such practice is common. Software offers the ultimate 61 flexibility, so it is possible for a developer to express almost any kind 62 of abstraction. This flexibility turns out to be an incredibly seductive 63 property, however, because it also forces the developer to craft virtually 64 all the primitive building blocks upon which these higher level abstrctions 65 stand. While the construction industry has uniform building codes and 66 standards for the quality of raw materials, few such standards exist in the 67 software industry. As a result, software development remains a labor-intensive 68 business.''} 69 \end{quote} 70 71 Additionally, Booch writes \cite[p. 51]{bibref:b:boochoodwithapps}: 72 73 \begin{quote} 74 \emph{Modules serve as the physical containers in which we declare the classes and 75 objects of our logical design. This is no different than the situation faced 76 by the electrical engineer designing a board-level computer. NAND, NOR, and 77 NOT gates might be used to construct the necessary logic, but these gates 78 must be physically packaged in standard integrated circuits, such as a 7400, 79 7402, or 7404. Lacking any such standard software parts, the software engineer 80 has considerably more degrees of freedom---as if the electrical engineer had 81 a silicon foundry at his or her disposal.''} 82 \end{quote} 83 84 Electronic hardware designers have less freedom in hardware designs than software 85 designers do in software designs. Available hardware components are 86 naturally limited by physical phenomena, such the number of pins 87 that can be placed on an integrated circuit package, that tend to 88 limit the complexity of the connectivity between hardware components. 89 It is much harder 90 to create a truly bad hardware design than a truly bad software design. 91 92 Second, metrics of goodness are more obvious and easier to agree 93 on in other engineering disciplines than in software engineering. 94 For example, in the design of electronic hardware, serious disagreements 95 among hardware 96 designers are rare because it is easier to reach agreement about the 97 measures of goodness of a hardware design. Given two [competing] hardware 98 designs, it is almost always clear which is better, based on simple 99 critera such as cost, circuit board area, power consumption, etc. 100 Measures of software design goodness are less clear and obvious. 101 102 Third, software---especially small embedded software---often allows 103 tradeoffs between management of complexity and other desirable 104 attributes, such as minimum ROM consumption or the best real-time 105 characteristics. In many cases, it is easy to modify software 106 to use less ROM or RAM or to perform better in a real-time sense, 107 but at the expense of a clear and consistent design (i.e. management of 108 complexity). 109 Many disagreements between software developers 110 arise because developers can't agree which tradeoffs should be 111 made between 112 clear structure of the software (i.e. effective management of complexity) 113 and other desirable attributes. 114 115 116 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 117 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 118 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 119 \section{Overview Of Desirable Attributes} 120 %Section tag: ODA0 121 \label{chgr0:soda0} 122 123 This section briefly enumerates what we consider to be the desirable 124 attributes of small embedded software and the product development 125 process and infrastructure. Each attribute is discussed in more 126 detail later in the chapter. Each desirable attribute below is 127 numbered with a \desirablepropertyprefix'' number so that it 128 can be cross-referenced. 129 130 \begin{enumerate} 131 132 \item \textbf{Desirable Properties of Embedded Software} 133 134 \begin{enumerate} 135 136 \item \textbf{Minimum Program Memory Consumption 137 \desirablepropertyemit\label{dp:chgr0:soda0:minpm}.} 138 An embedded software load 139 should use as little ROM or other program memory as possible. 140 Microcontrollers containing more ROM are more costly, and so 141 a primary goal is to minimize ROM consumption so that the 142 least expensive microcontrollers can be used. 143 144 \item \textbf{Minimum RAM Consumption 145 \desirablepropertyemit\label{dp:chgr0:soda0:minram}.} 146 Minimization of RAM 147 consumption is a primary goal so that the least 148 expensive microcontrollers can be used. 149 150 \item \textbf{Minimum EEPROM Consumption 151 \desirablepropertyemit\label{dp:chgr0:soda0:mineeprom}.} 152 Minimization of 153 EEPROM consumption is a primary goal so that the least 154 expensive microcontrollers can be used. 155 156 \item \textbf{Optimal CPU Cycle Utilization 157 \desirablepropertyemit\label{dp:chgr0:soda0:bestcpucycle}.} 158 We seek to design 159 systems that, for a given set of requirements, can 160 meet the requirements most efficiently with respect 161 to CPU demands. Such systems enable the use of slower [less costly] 162 microcontrollers, are less likely to conceal behavior, 163 and are easier to modify. 164 165 \item \textbf{Minimal Possibility Of Concealed Behavior 166 \desirablepropertyemit\label{dp:chgr0:soda0:minpconcealedbeh}.} 167 We seek to build 168 software systems that are not likely to 169 conceal behavior during product testing. Systems that have a large 170 ability to conceal behavior may pass product testing but 171 still exhibit defects for customers. The inability to conceal behavior 172 is closely related to other desirable characteristics: 173 174 \begin{enumerate} 175 176 \item \textbf{Minimization Of State Space 177 \desirablepropertyemit\label{dp:chgr0:soda0:minss}.} 178 Many software defects are tied to 179 software that holds more state than necessary. We seek to correctly 180 identify the minimum necessary state space of the software and to 181 construct software that is minimally stateful. 182 183 \item \textbf{Minimization Of Scheduling Freedom 184 \desirablepropertyemit\label{dp:chgr0:soda0:minschedfreedom}.} 185 We seek to minimize the way in which 186 external events can affect the way software components are scheduled for 187 execution. Simpler \emph{is} better. 188 189 \item \textbf{Minimization Of Non-Linear Behavior 190 \desirablepropertyemit\label{dp:chgr0:soda0:minnonlin}.} 191 Systems with 192 strongly non-linear or chaotic tendencies are undesirable. 193 194 \end{enumerate} 195 196 \item \textbf{Robustness. 197 \desirablepropertyemit\label{dp:chgr0:soda0:robustness}} 198 We seek to build systems that are robust with 199 respect to state upset of the controller, intermittent failure of 200 sensors and actuators, modeling errors, component aging, and variable 201 real-time loading of the software. 202 203 \item \textbf{Maximum Re-Usability Of Code 204 \desirablepropertyemit\label{dp:chgr0:soda0:maxreusecode}.} 205 We seek to be able to re-use 206 software components, and we seek to be able to develop 207 new products with a minimum of new software component development. 208 This goal related to both economy and to software quality. 209 Repeatedly reinventing the wheel is expensive, and it also introduces quality 210 concerns---it is more reliable to reuse software components 211 that have had prolonged exposure in existing products. 212 213 \item \textbf{Testability and Instrumentability 214 \desirablepropertyemit\label{dp:chgr0:soda0:testability}.} 215 We desire to construct software systems that are testable and 216 instrumentable. This desirable attribute includes the detection of 217 internal errors, the measurement of timing margins, and other requirements 218 and best practices. 219 220 \end{enumerate} 221 222 \item \textbf{Desirable Properties of a Product Development Process} 223 224 \begin{enumerate} 225 226 \item \textbf{Minimum Development Time 227 \desirablepropertyemit\label{dp:chgr0:soda0:mindevtime}.} 228 We seek to minimize the time to bring 229 product to market. 230 231 \item \textbf{Feedback Path From Defects And Near Defects To Process, Training, 232 And Tools 233 \desirablepropertyemit\label{dp:chgr0:soda0:feedbackpath}.} 234 We seek to be able to record defects (that make it into 235 production) and near defects (that nearly make it into production), 236 and feed these back into the product development process 237 (in the event that any process step could have prevented 238 the defect or near defect), into the training for software developers, and into 239 the tool set (if the defect or near defect is automatically detectable). 240 241 \end{enumerate} 242 243 \item \textbf{Desirable Properties of Human Environment} 244 245 \begin{enumerate} 246 247 \item \textbf{Self-Actualizing Experience for Employees 248 \desirablepropertyemit\label{dp:chgr0:soda0:saexperience}.} 249 We seek to provide a self-actualizing 250 experience for employees. Any employee should leave 251 a company with far more skills 252 than they had on their arrival. 253 254 \item \textbf{Best Experiences for the Top 20\% of Employees 255 \desirablepropertyemit\label{dp:chgr0:soda0:betop20}.} 256 It is common knowledge that the most 257 capable 20\% of software developers make 80\% of the competitive contribution. 258 It is also common knowledge that this 20\% is the most sensitive to working conditions 259 which impair productivity. 260 We seek to make it easier for this 20\% to be the most productive.\footnote{Note that this 261 notion of protecting the most productive employees is built into the work environment 262 so that we don't often think of this goal. For example, in a dentist's office, the 263 dentist certainly \emph{could} schedule appointments and follow up with insurance 264 claims, but economically it is more feasible to have an administrative staff do 265 this. Similarly, when obtaining technical support for a software product, one rarely reaches 266 the actual software developers. We also do not claim that we need to identify the 267 20\%, simply that we need to remove institutional productivity barriers.} 268 269 \end{enumerate} 270 271 \item \textbf{Desirable Properties of Administrative System} 272 273 \begin{enumerate} 274 275 \item \textbf{A Place For Everything, And Everything In Its Place 276 \desirablepropertyemit\label{dp:chgr0:soda0:placeforeverything}.} 277 We seek administrative 278 neatness and consistency. 279 280 \item \textbf{Elimination Of Redundant Information 281 \desirablepropertyemit\label{dp:chgr0:soda0:lackredinfo}.} 282 Redundant information in product 283 development is harmful in two ways. First, it is tedious and costly to [manually] maintain 284 the same information in different places. Second, such an arrangement is a change 285 risk, because the information may be updated in one place but not another. 286 287 \end{enumerate} 288 289 \end{enumerate} 290 291 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 292 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 293 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 294 \section{Detailed Description Of Desirable Attributes} 295 %Section tag: DDA0 296 \label{chgr0:sdda0} 297 298 299 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 300 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 301 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 302 \subsection[Minimum ROM, RAM, And EEPROM Consumption] 303 {Minimum ROM, RAM, And EEPROM Consumption 304 (\desirablepropertycite{dp:chgr0:soda0:minpm}, 305 \desirablepropertycite{dp:chgr0:soda0:minram}, 306 and 307 \desirablepropertycite{dp:chgr0:soda0:mineeprom})} 308 %Subsection tag: MRE0 309 \label{chgr0:sdda0:mre0} 310 311 Typical inexpensive microcontrollers come in families of parts with 312 the same CPU core but different amounts of ROM, RAM, and EEPROM; with different 313 numbers of I/O pins; and often with different I/O peripherals. 314 Almost invariably, members of a 315 family are priced so that the parts with more capability are more expensive. 316 317 Because of the cost differential, there is often substantial pressure 318 on microcontroller software developers to create software which 319 uese as little ROM, RAM, and EEPROM as possible; so that the least 320 expensive parts can be used. Additionally, it often happens that 321 a software load consumes nearly all the resources of the 322 largest available part in a family, so that no options are available 323 if the software cannot be made to fit. 324 325 Thus, strategies to minimize the consumption of ROM, RAM, and EEPROM 326 are of great interest in embedded software development. 327 328 Somewhat counterintuitively, the rigorous application of ROM-, RAM-, and 329 EEPROM-reduction strategies from the \emph{start} of a product development 330 may actually \emph{increase} the probability of a product development 331 failure. If these strategies are applied from the very start of a 332 product development, there will be little or no `fat'' left in software modules 333 that can be trimmed if ROM, RAM, or EEPROM limits are reached. 334 The rigorous application of ROM-, RAM-, and EEPROM-reduction strategies 335 must be accompanied by an increased respect for storage size limits. 336 337 338 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 339 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 340 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 341 \subsection[Optimal CPU Cycle Utilization] 342 {Optimal CPU Cycle Utilization 343 (\desirablepropertycite{dp:chgr0:soda0:bestcpucycle})} 344 %Subsection tag: BCC0 345 \label{chgr0:sdda0:bcc0} 346 347 In many applications, it may be advantageous to use the least-capable 348 microcontroller with the slowest clock rate that will suffice for the 349 application. The reasons that this may be advantageous are: 350 351 \begin{enumerate} 352 \item More capable microcontrollers are generally more costly. 353 \item It may be advantageous to operate a micrcontroller at less than 354 the maximum allowable clock frequency. 355 \begin{enumerate} 356 \item A system with a higher clock rate usually consumes more power, and 357 the relationship is often approximately linear. 358 \item There may be certain frequencies at which the embedded system should 359 not emit signals. (For example, in an automotive application, the 360 AM and FM radio bands are to be avoided. If the clock frequency of 361 the system is chosen so that the frequency or a harmonic is in these 362 bands, the system must be shielded or otherwise made more expensive.) 363 \end{enumerate} 364 \end{enumerate} 365 366 The general principles that apply to optimization for CPU-cycle efficiency are: 367 368 \begin{enumerate} 369 \item The mechanisms that pervade the system must be examined carefully and 370 optimized. Typical mechanisms that must be optimized are: 371 372 \begin{enumerate} 373 \item \textbf{Time measurement mechanisms.} 374 The notion of \emph{time} typically pervades an 375 embedded system. It is typical for many 376 software components to contain state-machine logic 377 with transition functions that are functions of time. 378 Decisions about how to represent time and how to test 379 elapsed time can have a \emph{profound} effect on 380 the performance of the system. 381 \item \textbf{IPC mechanisms.} 382 The mechanisms by which 383 \end{enumerate} 384 \end{enumerate} 385 386 387 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 388 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 389 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 390 \subsection[Minimal Possibility of Concealed Behavior] 391 {Minimal Possibility of Concealed Behavior 392 (\desirablepropertycite{dp:chgr0:soda0:minpconcealedbeh})} 393 %Subsection tag: mpc0 394 \label{chgr0:sdda0:mpc0} 395 396 397 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 398 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 399 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 400 \subsubsection[Minimization of State Space] 401 {Minimization of State Space 402 (\desirablepropertycite{dp:chgr0:soda0:minss})} 403 %Subsubsection tag: mss0 404 \label{chgr0:sdda0:mpc0:mss0} 405 406 Many embedded software defects are directly attributable to software which 407 holds more state than necessary. It is a common observation that 408 novice programmers have difficulty in designing state-minimal 409 embedded software components---in extreme cases, novice programmers have 410 even implemented purely combinational mappings as sequential machines. 411 412 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 413 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 414 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 415 \subsubsection[Minimization of Scheduling Freedom] 416 {Minimization of Scheduling Freedom 417 (\desirablepropertycite{dp:chgr0:soda0:minschedfreedom})} 418 %Subsubsection tag: msf0 419 \label{chgr0:sdda0:mpc0:msf0} 420 421 422 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 423 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 424 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 425 \subsubsection[Minimization of Non-Linear Behavior] 426 {Minimization of Non-Linear Behavior 427 (\desirablepropertycite{dp:chgr0:soda0:minnonlin})} 428 %Subsubsection tag: mnl0 429 \label{chgr0:sdda0:mpc0:mnl0} 430 431 432 \subsection{Freedom From Redundant Information} 433 434 435 \subsection{Robustness} 436 \label{chgr0:sdda0:srob0} 437 438 439 \subsection{Maximum Re-Usability Of Source Code} 440 441 442 \subsection{Minimum Development Time} 443 444 445 \subsection{Feedback Path From Defects To Product Development Process, Training, And Tools} 446 447 448 %\subsection{Self-Actualizing Experience For Employees} 449 450 451 %\subsection{Best Experiences For The Top 20\% Of Employees} 452 453 454 %\subsection{Administrative Neatness} 455 456 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 457 458 \noindent\begin{figure}[!b] 459 \noindent\rule[-0.25in]{\textwidth}{1pt} 460 \begin{tiny} 461 \begin{verbatim} 462 dashley 278 $HeadURL$ 463 $Revision$ 464 $Date$ 465 $Author$ 466 dashley 140 \end{verbatim} 467 \end{tiny} 468 \noindent\rule[0.25in]{\textwidth}{1pt} 469 \end{figure} 470 471 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 472 % 473 %End of file C_HGR0.TEX

## Properties

Name Value
svn:eol-style native
svn:keywords Author Date Id Revision URL Header