EMBEDDED SYSTEMS

Contents
1]: Introduction 2]: History 3]: Examples of Embedded Systems 4]: Characteristics 4.1]: User Interfaces 4.2]: Simple Systems 4.3]: In more complex systems 4.4]: CPU platforms 4.4.1]: Ready made computer boards 4.4.2]: ASIC and FPGA solutions 4.5]: Peripherals 4.6]: Tools 4.7]: Debugging 4.8]: Reliability 4.9]: High vs. Low Volume 5]: Computer Design Requirements 5.1]: Real time/reactive operation 5.2]: Small size, low weight 5.3]: Safe and reliable 5.4]: Harsh environment 5.5]: Cost sensitivity 6]: System-level requirements 6.1]: End-product utility 6.2]: System safety & reliability 6.3]: Controlling physical systems 6.4]: Power management
1
EMBEDDED SYSTEMS

03 06 10 14

19

22

EMBEDDED SYSTEMS

7]: Life-cycle support 7.1]: Component acquisition 7.2]: System certification 7.3]: Logistics and repair 7.4]: Upgrades 7.5]: Long-term component availability 8]: Business Model 8.1]: Design vs. production costs 8.2]: Cycle time 8.3]: Product families 9]: Design culture 9.1]: Computer culture vs. other cultures 9.2]: Accounting for cost of engineering 9.3]: Inertia 10]: Application 11]: Conclusions 12]: Reference

25

29

31

34 36 37

EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

1. Introduction
We live in a world today in which software plays a critical part. The most critical soft ware is not running on large systems and PCs. rather, it runs inside the infrastructure and in the devices that we use every day. Our transportation, communications, and energy systems won't work if the embedded software contained in our cars, phones, routers and power plants crashes. Evolution of a software system is a natural process. In most systems, evolution takes place during the maintenance phase of their life cycles. Those systems that have reached their limit in evolution have usually reached their end of useful life and may have to be replaced. However, there are systems in which evolution occurs during the operational phase of their life cycles. Such systems are designed to evolve while in use or, in other words, be adaptable. Semantically adaptable systems are of particular interest to industry as such systems often times adapt themselves to environment change with little or no intervention from their developing or maintaining organization. Since embedded systems usually have a restricted hardware configuration, it is difficult to apply the techniques developed for non-embedded systems directly to embedded systems. This paper focuses on evolution through adaptation and develops the concepts and techniques for semantic evolution in embedded systems. As the first step in the development of a software solution, architectures of software systems themselves have to be made semantically evolvable. In this paper we explore various architectural alternatives for the semantic evolution of embedded systems-- these architectures are based on four different techniques that we have identified for semantic evolution in embedded systems. The development of these architectures follows the systematic, process provided by the non-functional requirement (NFR) framework, which also permits the architectures to be rated in terms of their evolvability. As the field of embedded systems is vast, this paper concentrates on those embedded systems that can be remotely controlled. In this application domain the embedded system is connected to an external controller by a communication link such as Ethernet, serial, radio frequency, etc., and receives commands from and sends responses to the external controller via the communication link. The architectures developed in this paper have been partly validated by applying them in a real embedded system--a test instrument used for testing cell phones. These architectures and techniques for semantic evolution in this application domain give a glimpse of what can be done in achieving semantic evolution in software-implemented systems.

Approximately 3 billion embedded CPUs are sold each year, with smaller (4-, 8-, and 16-bit) CPUs dominating by quantity and aggregate dollar amount [1]. Yet, most research and tool development seems to be focused on the needs of high-end desktop and military/aerospace embedded computing. This paper seeks to expand the area of discussion to encompass a wide range of embedded systems. The extreme diversity of embedded applications makes generalizations difficult. Nonetheless, there is emerging interest in the entire range of embedded systems and the related field of hardware/software codesign. 3

EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

This paper and the accompanying tutorial seek to identify significant areas in which embedded computer design differs from more traditional desktop computer design. They also present "design challenges" encountered in the course of designing several real systems. These challenges are both opportunities to improve methodology and tool support as well as impediments to deploying such support to embedded system design teams. In some cases research and development has already begun in these areas -- and in other cases it has not. The observations in this paper come from the author's experience with commercial as well as military applications, development methodologies, and life-cycle support. All characterizations are implicitly qualified to indicate a typical, representative, or perhaps simply an anecdotal case rather than a definitive statement about all embedded systems. While it is understood that each embedded system has its own set of unique requirements, it is hoped that the generalizations and examples presented here will provide a broad-brush basis for discussion and evolution of CAD tools and design methodologies. An embedded system is a special-purpose computer system designed to perform one or a few dedicated functions, often with real-time computing constraints. It is usually embedded as part of a complete device including hardware and mechanical parts. In contrast, a general-purpose computer, such as a personal computer, can do many different tasks depending on programming. Embedded systems have become very important today as they control many of the common devices we use. Since the embedded system is dedicated to specific tasks, design engineers can optimize it, reducing the size and cost of the product, or increasing the reliability and performance. Some embedded systems are mass-produced, benefiting from economies of scale. Physically, embedded systems range from portable devices such as digital watches and MP3 players, to large stationary installations like traffic lights, factory controllers, or the systems controlling nuclear power plants. Complexity varies from low, with a single microcontroller chip, to very high with multiple units, peripherals and networks mounted inside a large chassis or enclosure. The design of this invisible, embedded software is crucial to all of us. Yet, there has been a real shortage of good information as to effective design and implementation practices specific to this very different world. Make no mistake, it is indeed different and often more difficult to design embedded software than more traditional programs. Time, and the interaction of multiple tasks in real-time, must be managed. In general, "embedded system" is not an exactly defined term, as many systems have some element of programmability. For example, Handheld computers share some elements with embedded systems such as the operating systems and microprocessors which power them but are not truly embedded systems, because they allow different applications to be loaded and peripherals to be connected.

EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

2. History
In the earliest years of computers in the 1930-40s, computers were sometimes dedicated to a single task, but were far too large and expensive for most kinds of tasks performed by embedded computers of today. Over time however, the concept of [[programmable controllers]] evolved from traditional [[electromechanical]] sequencers, via solid state devices, to the use of computer technology. One of the first recognizably modern embedded system was the [[Apollo Guidance Computer]], developed by [[Charles Stark Draper]] at the MIT Instrumentation Laboratory. At the project's inception, the Apollo guidance computer was considered the riskiest item in the Apollo project as it employed the then newly developed monolithic integrated circuits to reduce the size and weight. An early mass-produced embedded system was the [[Autonetics D-17]] guidance computer for the [[Minuteman (missile) |Minuteman missile]], released in 1961. It was built from [[transistor]] [[digital circuit logic]] and had a [[hard disk]] for main memory. When the Minuteman II went into production in 1966, the D-17 was replaced with a new computer that was the first high-volume use of integrated circuits. This program alone reduced prices on quad [[Sheffer stroke#NAND gate|nand gate ICs]] from $1000/each to $3/each, permitting their use in commercial products. Since these early applications in the 1960s, embedded systems have come down in price and there has been a dramatic rise in processing power and functionality. The first [[microprocessor]] for example, the [[Intel 4004]] was designed for [[calculator]] s and other small systems but still required many external memory and support chips. In 1978 National Engineering Manufacturers Association released a "standard" for programmable microcontrollers, including almost any computer-based controllers, such as single board computers, numerical, and event-based controllers. As the cost of microprocessors and microcontrollers fell it became feasible to replace expensive knob-based [[analog electronics analog]] components such as [[potentiometer]]s and [[variable capacitor]]s with up/down buttons or knobs read out by a microprocessor even in some consumer products. By the mid-1980s, most of the common previously external system components had been integrated into the same chip as the processor and this modern form of the [[microcontroller]] allowed an even more widespread use, which by the end of the decade was the norm rather than the exception for almost all electronics devices. Embedded systems are the applications that fuel some of the microprocessors that play a hidden but crucial role in our everyday lives. These are the tiny, quick, and smart microprocessors that live inside printers, answering machines, elevators, cars, cash machines, refrigerators, thermostats, wristwatches, and even toasters. Embedded systems are on the cutting 5 EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

edge of consumer electronics, poised to revolutionize various technologies by making them "smarter." A branch of the embedded-systems industry wants to see some of this newly smart equipment hooked up to the Internet, so that networking capabilities become a ubiquitous feature of modern machines. The history of embedded systems goes back at least to the sixties, but the expense and limitations of the early systems limited their use. Embedded systems really took off in 1992, when the PC/104 Consortium was founded by Ampro, RTD, and other manufacturers. The group established a format for Intel microprocessors based on a motherboard approximately four inches square, and just under an inch high. The boards were stackable, allowing a very powerful computer to be assembled in a box approximately four inches square, or even less. The PC/104 was initially targeted at military and medical markets, where it became widely used and respected. When the processor power increased enough to handle multimedia applications, PC/104-based kiosks became possible, and eventually common. Today, there are estimated to be well over 100 different companies making PC/104 products. There are PC/104 cards to add Ethernet, FireWire, hard drives, RAM drives, video cards, audio cards, general I/O, flash cards, modems, GPS, cellular telephone, wireless Internet, and more, to the PC/104 motherboard of your choice. Some off-theshelf PC/104 cases can handle up to 13 or more cards, so your budget is your only constraint. Kiosk development software is also progressing. Amulet Technologies (www.AmuletTechnologies.com) demonstrated a system that will allow LCD touch screens to be programmed in HTML. Since it usually takes C++ programming and several months to program a touch screen interface, the Amulet Technologies system is a major breakthrough. In addition to saving time and money, the technology leaves the interface design to an HTML layout artist, not an engineer. (We managed to program a simple interface with it in less than fifteen minutes from the time we opened the box.) It would be easy and economical to use this technology to make an interface for a hot tub, or a table-top ordering system for customers at restaurants. Interestingly, many of the exhibitors at the 2002 Embedded Systems Conference were marketing systems much smaller than the PC/104 format. In fact, some of the exhibitors were just selling chips, primarily to add Internet connectivity to products ranging from cars to coffee makers. Microchip design has advanced so far over the last few years that it's now possible to build a complete computer system on a chip, including wireless Internet connectivity. These chips can easily be added to thousands of products, and soon will be.

EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

It is unavoidable that computer will continue to become cheaper, smaller and more powerful, and that eventually they will be inexpensive enough to put in nearly every product, including soda straws and matchbooks. In addition, nearly all computer equipped products will have some kind of access to either local networks, or the Internet. Imagine a bathroom shower that will maintain exactly whatever water temperature you tell it to maintain. Aside from meaning no child would ever be accidentally scalded in a bathtub again, this would also mean more efficient and comfortable showers. A computer equipped bathtub would also be smart enough to turn it self off before it overflowed, and send you e-mail to let you know when your bath was ready. Over the next decade, many common household items will be given embedded systems, reinventing them, and changing forever how we interface with them. Like desktop publishing, and later the Internet, embedded systems is a technology that will fundamentally, and permanently, change the way advertising and marketing works. It will also permanently change the kind of products that are made, and how they are made. It's about time, too. For all the benefits industrialization has brought, it has also brought a host of problems as well. The problems go beyond VCR's and microwaves that take an engineering degree to program. For several hundred years, man has increasingly adjusted life to fit the needs of industrialization and the corporate structure that has grown to support it. In the process, we've become slaves of the machines built to sustain us, and some would argue, slaves to the system itself. The development of intelligent products, and intelligent product marketing, made possible by embedded systems, will at least offer the possibility of a world where machines exist for the convenience of people, and not the reverse. Given the tools we have now, this kind of dream is no longer impossible. The rise of embedded systems marks a new phase in industrialization. We've mechanized civilization. Now we have to civilize mechanization.

EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

3. Examples of Embedded Systems

Figure 1 shows one possible organization for an embedded system.

Figure 1. An embedded system encompasses the CPU as well as many other resources.

EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

In addition to the CPU and memory hierarchy, there are a variety of interfaces that enable the system to measure, manipulate, and otherwise interact with the external environment. Some differences with desktop computing may be:

The human interface may be as simple as a flashing light or as complicated as real-time robotic vision. The diagnostic port may be used for diagnosing the system that is being controlled -- not just for diagnosing the computer. Special-purpose field programmable (FPGA), application specific (ASIC), or even non-digital hardware may be used to increase performance or safety. Software often has a fixed function, and is specific to the application.

EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

10

Table 1. Four example embedded systems with approximate attributes. In order to make the discussion more concrete, we shall discuss four example systems (Table 1). Each example portrays a real system in current production, but has been slightly generalized to represent a broader cross-section of 10
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

11

applications as well as protect proprietary interests. The four examples are a Signal Processing system, a Mission Critical control system, a Distributed control system, and a Small consumer electronic system. The Signal Processing and Mission Critical systems are representative of traditional military/aerospace embedded systems, but in fact are becoming more applicable to general commercial applications over time. Using these four examples to illustrate points, the following sections describe the different areas of concern for embedded system design: computer design, system-level design, life-cycle support, business model support, and design culture adaptation. Desktop computing design methodology and tool support is to a large degree concerned with initial design of the digital system itself. To be sure, experienced designers are cognizant of other aspects, but with the recent emphasis on quantitative design life-cycle issues that aren't readily quantified could be left out of the optimization process. However, such an approach is insufficient to create embedded systems that can effectively compete in the marketplace. This is because in many cases the issue is not whether design of an immensely complex system is feasible, but rather whether a relatively modest system can be highly optimized for life-cycle cost and effectiveness. While traditional digital design CAD tools can make a computer designer more efficient, they may not deal with the central issue -- embedded design is about the system, not about the computer. In desktop computing, design often focuses on building the fastest CPU, then supporting it as required for maximum computing speed. In embedded systems the combination of the external interfaces (sensors, actuators) and the control or sequencing algorithms is or primary importance. The CPU simply exists as a way to implement those functions. The following experiment should serve to illustrate this point: ask a roomful of people what kind of CPU is in the personal computer or workstation they use. Then ask the same people which CPU is used for the engine controller in their car (and whether the CPU type influenced the purchasing decision). In high-end embedded systems, the tools used for desktop computer design are invaluable. However, many embedded systems both large and small must meet additional requirements that are beyond the scope of what is typically handled by design automation. These additional needs fall into the categories of special computer design requirements, system-level requirements, life-cycle support issues, business model compatibility, and design culture issues. Embedded systems span all aspects of modern life and there are many examples of their use. Telecommunications systems employ numerous embedded systems from telephone switches for the network to mobile phones at the end-user. Computer networking uses dedicated routers and network bridges to route data. Consumer electronics include personal digital assistants (PDAs), mp3 players, mobile phones, videogame consoles, digital cameras, DVD players, GPS receivers, and printers. Many household appliances, such as microwave ovens, washing machines and dishwashers, are including embedded systems to provide flexibility, efficiency 11 EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

12

and features. Advanced HVAC systems use networked thermostats to more accurately and efficiently control temperature that can change by time of day and season. Home automation uses wired- and wireless-networking that can be used to control lights, climate, security, audio/visual, etc., all of which use embedded devices for sensing and controlling. Transportation systems from flight to automobiles increasingly use embedded systems. New airplanes contain advanced avionics such as inertial guidance systems and GPS receivers that also have considerable safety requirements. Various electric motors brushless DC motors, induction motors and DC motors are using electric/electronic motor controllers. Automobiles, electric vehicles. and hybrid vehicles are increasingly using embedded systems to maximize efficiency and reduce pollution. Other automotive safety systems such as anti-lock braking system (ABS), Electronic Stability Control (ESC/ESP), and automatic four-wheel drive. Medical equipment is continuing to advance with more embedded systems for vital signs monitoring, electronic stethoscopes for amplifying sounds, and various medical imaging (PET, SPECT, CT, MRI) for non-invasive internal inspections.

4. Characteristics
Embedded systems are designed to do some specific task, rather than be a generalpurpose computer for multiple tasks. Some also have [[Real-time computing realtime]] performance constraints that must be met, for reason such as safety and usability; others may have low or no performance requirements, allowing the system hardware to be simplified to reduce costs. # Embedded systems are not always separate devices. Most often they are physically built-in to the devices they control. {{Fact date=September 2007}}. # The software written for embedded systems is often called [[firmware]], and is stored in read-only memory or [[Flash memory]] chips rather than a disk drive. It often runs with limited computer hardware resources: small or no keyboard, screen, and little memory.

4.1 User Interfaces:

Embedded systems range from no user interface at all — dedicated only to one task — to full user interfaces similar to desktop operating systems in devices such as PDAs.

4.2 Simple Systems:

Simple embedded devices use buttons, [[LED]] s, and small character- or digit-only displays, often with a simple [[Menu (computing) |menu system]]. 12
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

13

4.3 In More Complex Systems:

A full graphical screen, with [[touch screen touch]] sensing or screen-edge buttons provides flexibility while minimizing space used: the meaning of the buttons can change with the screen, and selection involves the natural behavior of pointing at what's desired. Handheld systems often have a screen with a "joystick button" for a pointing device. The rise of the [[World Wide Web]] has given embedded designers another quite different option: providing a web page interface over a network connection. This avoids the cost of a sophisticated display, yet provides complex input and display capabilities when needed, on another computer. This is successful for remote, permanently installed equipment such as Pan-Tilt-Zoom cameras and network routers.

4.4 CPU Platforms:

Embedded processors can be broken into two broad categories: ordinary microprocessors (P) and microcontrollers (C), which have many more peripherals on chip, reducing cost and size. Contrasting to the personal computer and server markets, a fairly large number of basic [[CPU architecture]]s are used; there are [[Von Neumann architecture|Von Neumann]] as well as various degrees of [[Harvard architecture]]s, [[RISC]] as well as non-RISC and [[VLIW]]; word lengths vary from 4-bit to 64-bits and beyond (mainly in [[Digital signal processor|DSP]] processors) although the most typical remain 8/16-bit. Most architectures come in a large number of different variants and shapes, many of which are also manufactured by several different companies. A long but still not exhaustive list of common architectures are: [[65816]], [[65C02]], [[68HC08]], [[68HC11]], [[68k]], [[8051]], [[ARM architecture ARM]], [[Atmel AVR| AVR]], [[Blackfin]], [[C167 family|C167]], [[Coldfire]], [[COP8]], [[Zilog Z8|eZ8]], [[eZ80]], [[FR-V]], [[Renesas H8|H8]], [[HT48FXX Flash I/O type series|HT48]], [[M16C]], [[M32C]], [[MIPS architecture|MIPS]], [[MSP430]], [[PIC microcontroller|PIC]], [[PowerPC]], [[R8C]], [[Super Harvard Architecture Single-Chip Computer|SHARC]], [[ST6]], [[SuperH]], [[TLCS-47]], [[TLCS-870]], [[TLCS-900]], [[Tricore]], [[V850]], [[x86 architecture|x86]], [[XE8000]], [[Z80]], etc.

4.4.1 Ready Made Computer Boards:

[[PC/104]] and PC/104+ are examples of available ''ready made'' computer boards intended for small, low-volume embedded and ruggedized systems. These often use [[DOS]], [[Linux]], [[NetBSD]], or an embedded [[real-time operating system]] such as [[MicroC/OS-II]], [[QNX]] or [[VxWorks]].

4.4.2 ASIC and FPGA Solutions:

A common configuration for very-high-volume embedded systems is the [[system on a chip]] (SoC), an [[application-specific integrated circuit]] (ASIC), for which the CPU core was purchased and added as part of the chip design. A related scheme is to use 13
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

14

a [[field-programmable gate array]] (FPGA), and program it with all the logic, including the CPU.

4.5 Peripherals:
Embedded Systems talk with the outside world via [[peripheral]] s, such as: *Serial Communication Interfaces (SCI): [[RS-232]], [[RS-422]], [[RS-485]] etc *Synchronous Serial Communication Interface: [[I2C]], [[JTAG]], [[Serial Peripheral Interface Bus|SPI]], SSC and ESSI *[[Universal Serial Bus]] (USB) *Networks: [[Ethernet]], [[Controller Area Network]], [[LonWorks]], etc *Timers: [[PLL]] (s), Capture/Compare and [[Time Processing Unit]] s *Discrete IO: aka [[General Purpose Input/Output]] (GPIO) *Analog to Digital/Digital to Analog (ADC/DAC)

4.6 Tools:
As for other software, embedded system designers use [[compiler]]s, [[Assembly language#Assembler|assembler]]s, and [[debugger]]s to develop embedded system software. However, they may also use some more specific tools: * In circuit debuggers or emulators (see next section). * Utilities to add a checksum or [[Cyclic redundancy check|CRC]] to a program, so the embedded system can check if the program is valid. * For systems using [[digital signal processing]], developers may use a math workbench such as [[MATLAB]], [[Simulink]], [[MathCad]], or [[Mathematica]] to simulate the mathematics. They might also use libraries for both the host and target which eliminates developing DSP routines as done in [[DSPnano RTOS]] and [[Unison Operating System]]. * Custom compilers and linkers may be used to improve optimization for the particular hardware. * An embedded system may have its own special language or design tool, or add enhancements to an existing language such as [[Forth (programming language)| Forth]] or [[BASIC Stamp|Basic]]. * Another alternative is to add a [[Real-time operating system]] or [[Embedded operating system]], which may have DSP capabilities like [[DSPnano RTOS]]. Software tools can come from several sources: * Software companies that specialize in the embedded market * Ported from the [[GNU]] software development tools * Sometimes, development tools for a personal computer can be used if the embedded processor is a close relative to a common PC processor As the complexity of embedded systems grows, higher level tools and operating systems are migrating into machinery where it makes sense. For example, [[cellphone]] s, [[personal digital assistant]]s and other consumer computers often need significant software that is purchased or provided by a person other than the manufacturer of the electronics. In these systems, an open programming environment such as [[Linux]], [[NetBSD]], [[OSGi]] or [[Embedded Java]] is required so that the third-party software provider can sell to a large market. 14
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

15

4.7 Debugging:
Embedded [[Debugging]] may be performed at different levels, depending on the facilities available. From simplest to most sophisticated they can be roughly grouped into the following areas: * Interactive resident debugging, using the simple shell provided by the embedded operating system (e.g. Forth and Basic) * External debugging using logging or serial port output to trace operation using either a monitor in flash or using a debug server like the [[Remedy Debugger]] which even works for heterogeneous [[multicore]] systems. * An in-circuit debugger (ICD), a hardware device that connects to the microprocessor via a [[JTAG]] or NEXUS interface. This allows the operation of the microprocessor to be controlled externally, but is typically restricted to specific debugging capabilities in the processor. * An [[in-circuit emulator]] replaces the microprocessor with a simulated equivalent, providing full control over all aspects of the microprocessor. * A complete [[emulator]] provides a simulation of all aspects of the hardware, allowing all of it to be controlled and modified and allowing debugging on a normal PC. Unless restricted to external debugging, the programmer can typically load and run software through the tools, view the code running in the processor, and start or stop its operation. The view of the code may be as [[assembly code]] or [[source-code]].

4.8 Reliability:
Embedded systems often reside in machines that are expected to run continuously for years without errors and in some cases recover by themselves if an error occurs. Therefore the software is usually developed and tested more carefully than that for personal computers, and unreliable mechanical moving parts such as disk drives, switches or buttons are avoided. Specific reliability issues may include: #The system cannot safely be shut down for repair, or it is too inaccessible to repair. Examples include space systems, undersea cables, navigational beacons, bore-hole systems, and automobiles. #The system must be kept running for safety reasons. "Limp modes" are less tolerable. Often backups are selected by an operator. Examples include aircraft navigation, reactor control systems, safety-critical chemical factory controls, train signals, engines on single-engine aircraft. #The system will lose large amounts of money when shut down: Telephone switches, factory controls, bridge and elevator controls, funds transfer and market making, automated sales and service. A variety of techniques are used, sometimes in combination, to recover from errors -both software bugs such as memory leaks, and also [[soft error]] s in the hardware: * [[watchdog timer]] that resets the computer unless the software periodically notifies the watchdog 15
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

16

* Subsystems with redundant spares that can be switched over to * Software "limp modes" that provide partial function * [[Immunity Aware Programming]]

4.9 High vs. Low Volume:

For high volume systems such as [[Digital audio player portable music players]] or [[mobile phone]]s, minimizing cost is usually the primary design consideration. Engineers typically select hardware that is just good enough to implement the necessary functions. For low-volume or prototype embedded systems, general purpose computers may be adapted by limiting the programs or by replacing the operating system with a [[realtime operating system

5. Computer Design Requirements

Embedded computers typically have tight constraints on both functionality and implementation. In particular, they must guarantee real time operation reactive to external events, conform to size and weight limits, budget power and cooling consumption, satisfy safety and reliability requirements, and meet tight cost targets.

5.1. Real time/reactive operation

Real time system operation means that the correctness of a computation depends, in part, on the time at which it is delivered. In many cases the system design must take into account worst case performance. Predicting the worst case may be difficult on complicated architectures, leading to overly pessimistic estimates erring on the side of caution. The Signal Processing and Mission Critical example systems have a significant requirement for real time operation in order to meet external I/O and control stability requirements. Reactive computation means that the software executes in response to external events. These events may be periodic, in which case scheduling of events to guarantee performance may be possible. On the other hand, many events may be aperiodic, in which case the maximum event arrival rate must be estimated in order to accommodate worst case situations. Most embedded systems have a significant reactive component. Design challenge:

Worst case design analyses without undue pessimism in the face of hardware with statistical performance characteristics.

5.2. Small size, low weight

Many embedded computers are physically located within some larger artifact. Therefore, their form factor may be dictated by aesthetics, form factors existing in pre-electronic versions, or having to fit into interstices among mechanical 16
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

17

components. In transportation and portable systems, weight may be critical for fuel economy or human endurance. Among the examples, the Mission Critical system has much more stringent size and weight requirements than the others because of its use in a flight vehicle, although all examples have restrictions of this type. Design challenges:

Non-rectangular, non-planar geometries. Packaging and integration of digital, analog, and power circuits to reduce size.

5.3. Safe and reliable

Some systems have obvious risks associated with failure. In mission-critical applications such as aircraft flight control, severe personal injury or equipment damage could result from a failure of the embedded computer. Traditionally, such systems have employed multiply-redundant computers or distributed consensus protocols in order to ensure continued operation after an equipment failure. However, many embedded systems that could cause personal or property damage cannot tolerate the added cost of redundancy in hardware or processing capacity needed for traditional fault tolerance techniques. This vulnerability is often resolved at the system level as discussed later. Design challenge:

Low-cost reliability with minimal redundancy.

5.4. Harsh environment

Many embedded systems do not operate in a controlled environment. Excessive heat is often a problem, especially in applications involving combustion (e.g., many transportation applications). Additional problems can be caused for embedded computing by a need for protection from vibration, shock, lightning, power supply fluctuations, water, corrosion, fire, and general physical abuse. For example, in the Mission Critical example application the computer must function for a guaranteed, but brief, period of time even under non-survivable fire conditions. Design challenges:

Accurate thermal modeling. De-rating components differently for each design, depending on operating environment.

5.5. Cost sensitivity

Even though embedded computers have stringent requirements, cost is almost always an issue (even increasingly for military systems). Although designers of systems large and small may talk about the importance of cost with equal urgency, their sensitivity to cost changes can vary dramatically. A reason for this may be that the effect of computer costs on profitability is more a function of the proportion of 17
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

18

cost changes compared to the total system cost, rather than compared to the digital electronics cost alone. For example, in the Signal Processing system cost sensitivity can be estimated at approximately $1000 (i.e., a designer can make decisions at the $1000 level without undue management scrutiny). However, with in the Small system decisions increasing costs by even a few cents attract management attention due to the huge multiplier of production quantity combined with the higher percentage of total system cost it represents. Embedded computers typically have tight constraints on both functionality and implementation. In particular, they must guarantee real time operation reactive to external events, conform to size and weight limits, budget power and cooling consumption, satisfy safety and reliability requirements, and meet tight cost targets.

Design challenge:

Variable "design margin" to permit tradeoff between product robustness and aggressive cost optimization.

6. System-level requirements
In order to be competitive in the marketplace, embedded systems require that the designers take into account the entire system when making design decisions.

6.1. End-product utility

The utility of the end product is the goal when designing an embedded system, not the capability of the embedded computer itself. Embedded products are typically sold on the basis of capabilities, features, and system cost rather than which CPU is used in them or cost/performance of that CPU.

18

EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

19

One way of looking at an embedded system is that the mechanisms and their associated I/O are largely defined by the application. Then, software is used to coordinate the mechanisms and define their functionality, often at the level of control system equations or finite state machines. Finally, computer hardware is made available as infrastructure to execute the software and interface it to the external world. While this may not be an exciting way for a hardware engineer to look at things, it does emphasize that the total functionality delivered by the system is what is paramount. Design challenge:

Software- and I/O-driven hardware synthesis (as opposed to hardware-driven software compilation/synthesis).

6.2. System safety & reliability

An earlier section discussed the safety and reliability of the computing hardware itself. But, it is the safety and reliability of the total embedded system that really matters. The Distributed system example is mission critical, but does not employ computer redundancy. Instead, mechanical safety backups are activated when the computer system loses control in order to safely shut down system operation. A bigger and more difficult issue at the system level is software safety and reliability. While software doesn't normally "break" in the sense of hardware, it may be so complex that a set of unexpected circumstances can cause software failures leading to unsafe situations. This is a difficult problem that will take many years to address, and may not be properly appreciated by non-computer engineers and managers involved in system design decisions (discusses the role of computers in system safety). Design challenges:

Reliable software. Cheap, available systems using unreliable components. Electronic vs. non-electronic design tradeoffs.

6.3. Controlling physical systems

The usual reason for embedding a computer is to interact with the environment, often by monitoring and controlling external machinery. In order to do this, analog inputs and outputs must be transformed to and from digital signal levels. Additionally, significant current loads may need to be switched in order to operate motors, light fixtures, and other actuators. All these requirements can lead to a large computer circuit board dominated by non-digital components. In some systems "smart" sensors and actuators (that contain their own analog interfaces, power switches, and small CPUS) may be used to off-load interface hardware from the central embedded computer. This brings the additional advantage of reducing the amount of system wiring and number of connector contacts by employing an embedded network rather than a bundle of analog wires. However, this change brings with it an additional computer design problem of partitioning the 19 EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

20

computations among distributed computers in the face of an inexpensive network with modest bandwidth capabilities. Design challenge:

Distributed system tradeoffs among analog, power, mechanical, network, and digital hardware plus software.

6.4. Power management

A less pervasive system-level issue, but one that is still common, is a need for power management to either minimize heat production or conserve battery power. While the push to laptop computing

has produced "low-power" variants of popular CPUs, significantly lower power is needed in order to run from inexpensive batteries for 30 days in some applications, and up to 5 years in others. Design challenge:

Ultra-low power design for long-term battery operation.

20

EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

21

7. Life-cycle support
Figure 2 shows one view of a product life-cycle.

Figure 2. An embedded system lifecycle. First a need or opportunity to deploy new technology is identified. Then a product concept is developed. This is followed by concurrent product and manufacturing process design, production, and deployment. But in many embedded systems, the 21
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

22

designer must see past deployment and take into account support, maintenance, upgrades, and system retirement issues in order to actually create a profitable design. Some of the issues affecting this life-cycle profitability are discussed below.

7.1. Component acquisition

Because an embedded system may be more application-driven than a typical technology-driven desktop computer design, there may be more leeway in component selection. Thus, component acquisition costs can be taken into account when optimizing system life-cycle cost. For example, the cost of a component generally decreases with quantity, so design decisions for multiple designs should be coordinated to share common components to the benefit of all. Design challenge:

Life-cycle, cross-design component cost models and optimization rather than simple per-unit cost.

7.2. System certification

Embedded computers can affect the safety as well as the performance the system. Therefore, rigorous qualification procedures are necessary in some systems after any design change in order to assess and reduce the risk of malfunction or unanticipated system failure. This additional cost can negate any savings that might have otherwise been realized by a design improvement in the embedded computer or its software. This point in particular hinders use of new technology by resynthesizing hardware components -- the redesigned components cannot be used without incurring the cost of system recertification. One strategy to minimize the cost of system recertification is to delay all design changes until major system upgrades occur. As distributed embedded systems come into more widespread use, another likely strategy is to partition the system in such a way as to minimize the number of subsystems that need to be recertified when changes occur. This is a partitioning problem affected by potential design changes, technology insertion strategies, and regulatory requirements. Design challenge:

Partitioning/synthesis to minimize recertification costs.

7.3. Logistics and repair

Whenever an embedded computer design is created or changed, it affects the downstream maintenance of the product. A failure of the computer can cause the entire system to be unusable until the computer is repaired. In many cases embedded systems must be repairable in a few minutes to a few hours, which implies that spare components and maintenance personnel must be located close to the system. A fast repair time may also imply that extensive diagnosis and data collection capabilities 22 EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

23

must be built into the system, which may be at odds with keeping production costs low. Because of the long system lifetimes of many embedded systems, proliferation of design variations can cause significant logistics expenses. For example, if a component design is changed it can force changes in spare component inventory, maintenance test equipment, maintenance procedures, and maintenance training. Furthermore, each design change should be tested for compatibility with various system configurations, and accommodated by the configuration management database. Design challenge:

Designs optimized to minimize spares inventory. High-coverage diagnosis and self-test at system level, not just digital component level.

7.4. Upgrades
Because of the long life of many embedded systems, upgrades to electronic components and software may be used to update functionality and extend the life of the embedded system with respect to competing with replacement equipment. While it may often be the case that an electronics upgrade involves completely replacing circuit boards, it is important to realize that the rest of the system will remain unchanged. Therefore, any special behaviors, interfaces, and undocumented features must be taken into account when performing the upgrade. Also, upgrades may be subject to recertification requirements. Of special concern is software in an upgraded system. Legacy software may not be executable on upgraded replacement hardware, and may not be readily crosscompiled to the new target CPU. Even worse, timing behavior is likely to be different on newer hardware, but may be both undocumented and critical to system operation. Design challenge:

Ensuring complete interface, timing, and functionality compatibility when upgrading designs.

7.5. Long-term component availability

When embedded systems are more than a few years old, some electronic components may no longer be available for production of new equipment or replacements. This problem can be especially troublesome with obsolete processors and small-sized dynamic memory chips. When a product does reach a point at which spare components are no longer economically available, the entire embedded computer must sometimes be redesigned or upgraded. This redesign might need to take place even if the system is no longer in production, depending on the availability of a replacement system. This problem is a significant concern on the Distributed example system. 23
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

24

Design challenge:

Cost-effectively update old designs to incorporate new components.

8. Business model
The business models under which embedded systems are developed can vary as widely as the applications themselves. Costs, cycle time, and the role of product families are all crucial business issues that affect design decisions.

8.1. Design vs. production costs

Design costs, also called Non-Recurring Engineering costs (NRE), are of major importance when few of a particular embedded system are being built. Conversely, production costs are important in high-volume production. Embedded systems vary from single units to millions of units, and so span the range of tradeoffs between designs versus production costs. At the low-volume end of the spectrum, CAD tools can help designers complete their work with a minimum of effort. However, at the high-volume end of the spectrum the designs may be simple enough and engineering cost such a small fraction of total system cost that extensive hand-optimization is performed in order to reduce production costs. CAD tools may be able to outperform an average engineer at all times, and a superior engineer on very large designs (because of the limits of human capacity to deal with complexity and repetition). However, in small designs some embedded computer designers believe that a superior human engineer can outperform CAD tools. In the Small system example a programmer squeezed software into a few hundred bytes of memory by hand when the compiler produced overly large output that needed more 24
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

25

memory than was available. It can readily be debated whether CAD tools or humans are "better" designers, but CAD tools face skepticism in areas that require extraordinary optimization for size, performance, or cost. Design challenge:

Intelligently trade off design time versus production cost.

8.2. Cycle time

The cycle time between identification of a product opportunity and product deployment (also called Time to Market) can be quite long for embedded systems. In many cases the electronics are not the driving force; instead, product schedules are driven by concerns such as tooling for mechanical components and manufacturing process design. Superficially, this would seem to imply that design time for the electronics is not an overriding concern, but this is only partially true. Because the computer system may have the most malleable design, it may absorb the brunt of changes. For example, redesign of hardware was required on the Mission Critical example system when it was found that additional sensors and actuators were needed to meet system performance goals. On the Small example system, delays in making masked ROM changes in order to revise software dominate concerns about modifications (and programmable memory is too expensive). So, although the initial design is often not in the critical path to product deployment, redesign of the computer system may need to be done quickly to resolve problems. Design challenge:

Rapid redesign to accommodate changing form factors, control algorithms, and functionality requirements.

8.3. Product families

In many cases embedded system designs are not unique, and there are a variety of systems of various prices and capabilities forming a product family. To the extent that system designers can reuse components, they lower the total cost of all systems in the product family. However, there is a dynamic tension between overly general solutions that satisfy a large number of niche requirements, and specifically optimized designs for each point in a product family space. Also, there may be cases in which contradictory requirements between similar systems prevent the use of a single subsystem design. In the Mission Critical and Small examples different customers require different interfaces between the embedded system and their equipment. In the Distributed example regulatory agencies impose different safety-critical behavior requirements depending on the geographic area in which the system is deployed. Design challenge:

Customize designs while minimizing component variant proliferation.

EMBEDDED SYSTEMS

25

EMBEDDED SYSTEMS

26

9. Design culture
Design is a social activity as well as a technical activity. The design of desktop computers and CPUs in particular, has matured in terms of becoming more quantitative in recent years. With this new maturity has come an emphasis on simulation and CAD tools to provide engineering tradeoffs based on accurate performance and cost predictions. Computer designers venturing into the embedded arena must realize that their culture (and the underlying tool infrastructure) is unlike what is commonly practiced in some other engineering disciplines. But, because embedded system design requires a confluence of engineering skills, successful computer designers and design methodologies must find a harmonious compromise with the techniques and methodologies of other disciplines as well as company management. Also, in many cases the engineers building embedded computer systems are not actually trained in computer engineering (or, perhaps not even electrical engineering), and so are not attuned to the culture and methodologies of desktop computer design.

9.1. Computer culture vs. other cultures

A specific problem is that computer design tools have progressed to the point that many believe it is more cost-effective to do extensive simulation than build successive prototypes. However, in the mechanical arena much existing practice strongly favors prototyping with less exhaustive up-front analysis. Thus, it may be difficult to convince project managers (who may be application area specialists rather than computer specialists) to spend limited capital budgets on CAD tools and defer the gratification of early prototype development in favor of simulation. Design challenge:

Make simulation-based computer design accessible to non-specialists.

9.2. Accounting for cost of engineering design

One area of common concern is the effectiveness of using engineers in any design discipline. But, some computer design CAD tools are very expensive, and in general organizations have difficulty trading off capital and tool costs against engineering time. This means that computer designers may be deprived of CAD tools that would reduce the total cost of designing a system. Also, in high-volume applications engineering costs can be relatively small when compared to production costs. Often, the number of engineers is fixed, and book-kept as a constant expense that is decoupled from the profitability of any particular system design, as is the case in all four example systems. This can be referred to as the "Engineers Are Free" syndrome. But, while the cost of engineering time may have a 26 EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

27

small impact on product costs, the unavailability of enough engineers to do work on all the products being designed can have a significant opportunity cost (which is, in general, unmeasured). Design challenge:

Improved productivity via using tools and methodologies may be better received by managers if it is perceived to increase the number of products that can be designed, rather than merely the efficiency of engineers on any given product design effort. This is a subtle but, in practice, important distinction.

9.3. Inertia
In general, the cost of change in an organization is high both in terms of money and organizational disruption. The computer industry can be thought of as being forced to change by inexorable exponential growth in hardware capabilities. However, the impact of this growth seems to have been delayed in embedded system development. In part this is because of the long time that elapses between new technology introduction and wide-scale use in inexpensive systems. Thus, it may simply be that complex designs will force updated CAD tools and design methodologies to be adopted for embedded systems in the near future. On the other hand, the latest computer design technologies may not have been adopted by many embedded system makers because they aren't necessary. Tool development that concentrates on the ability to handle millions of transistors may simply not be relevant to designers of systems using 4- and 8-bit microprocessors that constitute the bulk of the embedded CPU market. And, even if they are useful, the need for them may not be compelling enough to justify the pain and up-front expense of change so long as older techniques work. That is not to say that new tools aren't needed, but rather that the force of cultural inertia will only permit adoption of low-cost tools with significant advantages to the problem at hand.

However, the impact of this growth seems to have been delayed in embedded system development. In part this is because of the long time that elapses between new technology introduction and wide-scale use in inexpensive systems. Tool development that concentrates on the ability to handle millions of transistors may simply not be relevant to designers of systems using 4- and 8-bit microprocessors that constitute the bulk of the embedded CPU market. On the other hand, the latest computer design technologies may not have been adopted by many embedded system makers because they aren't necessary. Design challenge:

Find/create design tools and methodologies that provide unique, compelling advantages for embedded design. Rapid redesign to accommodate changing form factors, control algorithms, and functionality requirements.
EMBEDDED SYSTEMS

27

EMBEDDED SYSTEMS

28

10. Application
Embedded systems are omnipresent and play significant roles in modern-day life. Embedded systems are also diverse and can be found in consumer electronics, such as digital cameras, DVD players and printers; in industrial robots; in advanced avionics, such as missile guidance systems and flight control systems; in medical equipment, such as cardiac arrhythmia monitors and cardiac pacemakers; in automotive designs, such as fuel injection systems and auto-braking systems. Embedded systems have significantly improved the way we live today-and will continue to change the way we live tomorrow. The availability of low-cost computational-powerful micro-controllers has made it possible to extend the performance and the functionality of the embedded controllers used in automotive industry to limits that were unthinkable only a few years ago. Nowadays, top class cars are equipped with many (more than 80) embedded controllers that handle different subsystems, such as engine, gear, brakes, suspensions, windows, and dash-board The every increasing complexity and challenges of the automotive requirements in terms of drivability, safety, emissions and fuel consumption imposed by car manufacturers and regulations call for more powerful design approaches and expose the need for a more structured and accurate design flow. The adopted design methodologies have to ensure the development of embedded systems achieving the requested specification and meeting the extremely tight cost and development-time constraints imposed by the market.

28

EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

29

Embedded systems already play an important role not only in consumer electronics but also in many important and safety-critical systems in applications such as avionics, space, railway and transport, process control and medical systems. There are, for instance, already many embedded systems in cars with critical control functions (e.g. ABS braking systems, airbags), and these will become much more widely used in the automotive industry once they can be delivered at prices acceptable to the automotive market.

Hybrid system techniques can provide significant contributions to the improvement of the design flow for embedded systems in the automotive industry, since they allow to clearly represent the complex combination of time and event-based behaviors as well as the interactions between continuous and discrete phenomena. Hybrid formalisms and methodologies proved to be very effective in handling several critical issues of the design flow such as: formalization of system specifications; representation of embedded controller inputs/outputs; plant and environment modeling; representation of multirate asynchronous control loops; description of the control-flow and data-flow components of control algorithms; validation and verification of control algorithms and their implementations; description of the HW/SW implementation requirements. 29
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

30

11. Conclusions
Many embedded systems have requirements that differ significantly both in details and in scope from desktop computers. In particular, the demands of the specific application and the interface with external equipment may dominate the system design. Also, long life-cycles and in some cases extreme cost sensitivity require more attention to optimization based on these goals rather than maximizing the computational throughput. The business and cultural climates in many embedded system design situations are such that traditional simulation-based computer design techniques may not be viable in their current form. Such methodologies may not be cost-effective given constraints on categories of expenditures, may not be seen as worthwhile by non-computertrained professionals, or may simply be solving the wrong problems. Recent interest in hardware/software codesign is a step in the right direction, as it permits tradeoffs between hardware and software that are critical for more costeffective embedded systems. However, to be successful future tools may well need to increase scope even further to include life-cycle issues and business issues.

12. References
1]. www.wikipedia.org 30
EMBEDDED SYSTEMS

EMBEDDED SYSTEMS

31

2]. www.embeddedstar.org 3]. www.embeddedindia.com 4]. www.zdnet.com 5]. Real time concepts for embedded systems by Qing LI.

31

EMBEDDED SYSTEMS