Lots of Information about Embedded Systems

Examples of multiply-embedded systems
- Familiar and not so familiar embedded systems.

What Are Embedded Systems?
- Examples of real embedded systems, multiply-embedded systems, reactive embedded systems, and what what makes these things embedded.

Defining Embedded Systems
- Defining Embedded Systems is HARD! Here are several attempts, including definition by omission, by prevalence or invisibility, by prophesy, and other random thoughts.

Creating Embedded Systems
- Overview of the parts of an embedded system, trends, and considerations like power consumption, real time requirements, memory, reliability, and user interfaces

Examples of Real Embedded Systems

A large segment of technology-based products are electronic, and most are becoming “smart” devices. This simply means that the device contains some sort of brain that controls its behavior. This brain is like the one inside your computer - since it usually doesn’t have all this stuff connected to it that you have on your computer at home, it is referred to as a microcontroller or microprocessor. And since it is usually inside the device, it is called embedded. Embedded systems are devices that contain microprocessors to do their jobs.

Many of today’s electronic products are possible because electronics have gotten smaller and cheaper. The first television sets were huge, heavy, and temperamental. Now look at the size of an LCD display! Amazing!

Familiar Embedded Systems

Some embedded systems are familiar products - portable music players and cell phones are great examples. The microprocessors in these devices are not as fast and powerful as the ones in your computer, but they are designed to have just the right requirements for the product. And since they are so small, music players and cell phones have shrunk over time as well.

Not so familiar embedded systems

But just because electronics are getting smaller doesn’t mean that large products can’t be embedded. Consider an automated assembly line for cars - all of those robotic systems are controlled by specialized microprocessors that are designed to control motors and motion control, rather than hard drives and wireless modems. The microprocessors in these products are customized as well. Size really doesn’t matter in the embedded world.

This embedded system is 8 feet wide and is used for a very specific purpose - to apply a glue sealant between two panes of glass to create an insulated glass window. It doesn’t display images, it doesn’t play music, it doesn’t download from the internet. It just seals glass units.

For users to fully accept technology, the product. devices, or service must provide a solution to the customer’s needs. Do the embedded systems above achieve this?

Many people have good and bad experiences with electronic personal organizers. With this one, it is easy to lose the stylus. Others cause repetitive stress injuries in the thumb. The display on some is hard to read. So what do users do? Complain, return the devices, and try something else. One might argue that different users have different needs, but what if we could design a device with all of the users needs in mind?

Even though embedded systems have been around for a while, there is no agreed-upon definition for what an actual embedded system is. Let’s digress for a bit into more interesting information about embedded systems.

For more information on the history and definitions of embedded systems and considerations for designing them, click on the links below.

What Are Embedded Systems?

Examples of Real Embedded Systems

Nearly everything seems to be embedded - here are some of the most common embedded systems used in everyday life:

navigation systems badge readers cell phones
battery chargers elevators PDAs
clocks smoke detectors keyboards
ultrasonic toothbrushes vending machines cash registers
printers garage door openers crock pots
microwave ovens ceiling fans hot tubs

Examples of multiply-embedded systems

Some devices and products have MORE THAN ONE microprocessor in them. Take a new car for example - how many embedded processors does it have?

Survey says …

sun roof tire pressure detection systems antilock brakes
DVD player automatic headlights and high beams child-proof locks
GPS navigation sensor checks (oxygen, temp, oil level) automatic stability control
cruise control climate control automatic transmission
keyless entry memory for seats and mirror settings airbag control
heated seats the infamous “check engine” light garage door opener

Reactive Embedded Systems

Some embedded systems are called “reactive” systems because they react to conditions in their environment. These are similar to the sensors in a car to detect when the engine temperature goes too high, but these are often even more hidden from the average person.

These systems detect external conditions and react to changes in these conditions. Reactions may be to record data (such as temperature, vibration, weight, position), to sound an alarm, to turn on or off motors or devices, or to send messages to other processors. They often act as sentries (e.g., alarm systems) and monitors. An interesting one can detect and record extreme shocks in vibration and temperature. The devices are often strapped to shipping containers to record when a shipment may be damaged in transit.

So what makes these things embedded?

Before, we talked about the brains inside the device. And how these brains can be specifically designed just to run the functions needed. For example, your washing machine doesn’t need to do floating point match and download streaming video, and your ultrasonic toothbrush doesn’t need a color display. So don’t spend money on a microprocessor that does more than you need.

The low end microprocessor are dirt cheap in quantity - practically free for a high volume product. These are 4-bit and 8-bit micros that would load Windows XP in a brisk 30 minutes (as if a 32-bit operating system could run on an 8-bit micro, but you get the idea). But who needs Windows when you just need to check a few sensors, scan for a radio station and adjust the side mirror? So heck, make everything configurable with its own little brain!

Defining Embedded Systems

Defining Embedded Systems is HARD!

This is the question of the decade! Embedded systems have been around for years, and each of us owns a scad of them, but no agreed-upon definition exists! (Beware, a digression is impending, but with relevant references intermixed . . .)

A cheap and dirty definition:

“If it’s got a plug or a charger, chances are it’s an embedded system.”

Here is my definition, which is similar with a few clarifications….with the idea that some brains need to be included.

“An embedded system is an electronic device like a cell phone, DVD player, or appliance that contains a special computer that only performs the programs needed to make that device work correctly.”

…and the ubiquitous follow-on clarification…

“These computers are different from personal computers, which can perform a nearly endless array of user-selected programs like word processing, spreadsheets and email and photo editing programs. While most devices have only one embedded processor, others like cars contain many embedded processors to control individual tasks like windshield wiper delays, fuel injection, and antilock brake functions.”

Whew! A mouthful. I know. Have you ever tried describing exactly what you do to your family and friends? And as you explain and re-clarify you see their eyes glaze over? Defining embedded systems is tough - most descriptions don’t tell what an embedded system is. They list characteristics of embedded systems, or indicate what an embedded system is not, and then provide examples of recognizable embedded systems in hope that the reader will have an ah-hah moment and connect the dots.

“People use the term embedded system to mean any computer system hidden inside…products such as VCRs, digital watches, etc.”
[David E. Simon, An Embedded Software Primer.]

There is no general consensus about what an embedded system is nor is there a complete list of characteristic properties of such systems.
[Bas Graaf, Marco Lormans, and Hans Toetenel, Information Technology and Systems, Delft University of Technology, The Netherlands]

Ha! Therefore we have free rein! Here is my favorite definition-by-description:

“You already have a non-PC chip embedded in your car and stereo and rice cooker and phone. These chips are dumb chips, with limited ambitions. A chip in your car’s brakes doesn’t have to do floating-point math, spreadsheets, or video processing; it only needs to brake like a bulldog.”
[New Rules for the New Economy, 10 Radical Strategies for a Connected World, by Kevin Kelly]

Here are two decent definitions from the internet; a short one and a long one:

“Embedded systems are tiny computers embedded in many kinds of products.”
[Canadian Center for Occupational Health & Safety]

“An embedded system is a large or small computer system that is built into a product, a piece of equipment or another computer system, and that performs some task useful to the product, equipment or system. It is a computer system that is programmed to perform a particular task. This task may be very simple or very complex; that is not a relevant distinction. ‘But’ you say, ‘all computers are programmed to perform tasks!’ True, however an embedded system is programmed to perform its task from the time it is powered up until it is shut down. Its programming cannot be changed except in ways that its original programmer intended.”
[The Innovations in Design Lab]

Very few references actually shove a stake in the ground and provide a short-and-sweet working definition that is useful without clarification. One reason is that short-and-sweet “correct” definitions leave you wanting specifics. For example, these definitions are reasonable and they make sense to folks already in the embedded systems field, but can be rather cryptic for everyone else:

“A computing device that performs a dedicated function.”
[Microsoft Windows Embedded Developer Center]

Personally, I am extremely hesitant to use a Microsoft-based operating system in a critical embedded device. Blue Screen of Death on my cell phone is annoying; Blue Screen of Death on my antilock brakes is somewhat less amusing.

“Computers masquerading as non-computers.”
[Stephen A. Edwards, Columbia University.]

Cute. Has relevance and appeal. But what’s it mean?

“Any device that includes a programmable computer but is not itself a general-purpose computer.”
[Charles J. Kim, Howard University]

Okay, but this assumes that the general populace knows what a general purpose computer it. “Is that like my Dell?” a friend asked me.

All true. All succinct. None terrifically enlightening.

Definition by Omission, Prevalence, or Invisibility

Sometimes it is easier to define something by describing what it is not.

“Embedded systems do not provide standard computing services and normally exist as part of a bigger system.” [Sandeep Agrewal and Pankaj Bhatt]

“[D]evices other than desktop PCs, servers, and notebooks. ” [Tony Givargis, University of California, Irvine]

Although this sounds flippant at first read, it is actually a reasonable definition by omission. As long as “device” means some electronic thing with some sort of smarts.

How many embedded systems or embedded computers do you have in your house? (Send me your counts!) We rely on these devices without fully understanding their prevalence or importance until the coffee pot fails to perk 10 minutes before the alarm clock goes off in the morning, or the smoke detectors all start chirping at 2AM for a battery change.

(Smoke detectors should not have a real time clock in them - but how do they know to start being incredibly annoying in the middle of the night? And that after you pull out the main 9V battery (that is supposedly near death), there is another little lithium cell hidden behind the “non user serviceable” seal? And that it takes 2 layers of 5mm wetsuits and a suitcase piled on top of them in the basement to drown out the sound of the periodic chirps as you try to get back to sleep before you can wake up and drive to the store to purchase 7 new 9V batteries for every detector in the house because when one chirps they all chirp?)

On a 10 minute walk through my house, I found 202 embedded devices - now this is just whole devices, not individual embedded processors. For example, I counted both my car and my cell phone as single embedded devices, although my car could have over 100 embedded processors in it and my phone has about 3.

“These systems are invisible to us but they shape our world.” The Innovations in Design Lab

“Embedded- systems . . . are called ‘embedded’ because they are an integral component of the device’s ability to function and are not always readily visible to the untrained eye.”
Gary North, Gary North Online

“Embedded systems pervade every aspect of life, often going unnoticed to the end user while at the same time enabling new activities, even a new quality of life.”
[Prof. Mariagiovanna Sami, ALaRI Scientific Director, University of Lugano]

“A large organization could have hundreds of thousands of embedded systems. Because embedded systems are so pervasive, they can stop your business from functioning before you even know that they exist.”
[Gary North, Gary North Online]

“The number of processors in embedded systems already exceeds the number of processors in PCs, and this trend is expected to continue.” Embedded System Design

[Peter Marwedel, University of Dortmund published by Kluwer Academic Publishers]

“Only 2% of the world’s microprocessors run on traditional desktops and servers.” [Ken Klein, CEO, Wind River Systems]

Definition by Prophesy

As a dear friend of mine would say, “You are an engineer and engineers just make gadgets.” Nip tirade in the bud right there. Well, dear, your life REVOLVES around gadgets, so deal. Gadgets used to be little disconnected thingies that did some little interesting functions that appealed to early adopters and Star Trekkie types. Welcome of the new millennium where these little gadgets are all starting to talk to one another and provide a new backbone of communications and information.

“Embedded systems can be defined as information processing systems embedded into enclosing products such as cars, telecommunication or fabrication equipment. Such systems come with a large number of common characteristics, including real-time constraints, and dependability as well as efficiency requirements. Following the success of information technology (IT) for office and workflow applications, embedded systems are considered to be the most important application area of IT during the coming years. [emphasis added]”
Prof. Mariagiovanna Sami, ALaRI Scientific Director, University of Lugano]

…This is a excellent term, “enclosing product,” that appears only about 5 times in Google (as of 2/2/3005) as a noun in this context…perhaps a new term is being coined? Here it is again:

“Embedded systems are information processing systems that are embedded into an enclosing product. Examples of embedded systems include information processing systems in transportation, telecommunication, manufacturing and medical applications. … According to many predictions, embedded systems will be the main market of information technology in the future.”
[Embedded System Design by Peter Marwedel.]

And then the government always has to get involved. . . Here’s an amusing thought: the lack of a formal definition for “embedded systems” has even been sent to a committee that provides advice to the federal government.

“[The board] will assemble a study committee of approximately 12 members . . . It will then convene a series of meetings and small workshops . . . the committee will attempt to answer questions such as: What are embedded systems? How do they differ from more traditional computing systems?”
[The National Academies. (Okay, I avoided the main focus of the committee work, which is to study networked embedded systems, but you get the idea when the first question is to define what the base technology is!)]

On the other hand, the National Science Foundation is offering federal grants for embedded systems projects, recognizing the future role of embedded systems in information technology:

  • Embedded and hybrid systems: The National Science Foundation solicits proposals for the embedded and hybrid systems program through the division of computer-communications research. This program supports fundamental research in embedded systems, emphasizing the role of information technology, specifically embedded software, as an active element in control, diagnosis, and decision support for physical and engineered systems. Embedded systems combine interacting elements:
    • the temporal-spatial properties and continuous dynamics of the physical system to be monitored or controlled;
    • the concurrency, real-time, and synchronization properties and resource demands of software that controls the system;
    • characteristics and services of the computational platform (both hardware and system software).

    Some Other Definitions

“Any system where the user doesn’t want to know that it includes a processor.”
[Dr. Doug Locke, Locke Consulting, LLC, www.doug-locke.com.]

“An embedded system is a mixed hardware / software system dedicated for a specific application and is part of and reactive to a larger, physical system to which it is at least logically connected.”
[Bas Graaf, Marco Lormans, and Hans Toetenel, Information Technology and Systems, Delft University of Technology, The Netherlands]

“An embedded system is an information processing system that responds to externally generated input stimuli within a finite and specified period.”
[Gul N. Khan, Ryerson University]

“Computers purchased as a part of some other piece of equipment.”
[Philip Koopman, Carnegie Melon University.]

Creating Embedded Systems

An embedded system is a different beast than your personal computer, and the some of the challenges developing embedded systems are also different. Embedded developers generally learn a wide array of skills because we must be more aware of both the hardware and software in the device. Your software is connected pretty darn closely to the hardware, and your job is more than making sure that the compile and link return no errors. You’ll spend less time in your cube and more time in the lab with the hardware folks and integration/ test folks. (In some companies, you will BE the hardware, test and integration folks!)

Some of the characteristics of embedded systems and development methods used to create them are listed below. This is not comprehensive, but designed to be an introductory overview.

Parts of an Embedded System

An embedded system has several typical parts. Usually it has much less hardware support than a PC - the only hardware that is included is hardware that needed for the application. It includes a microprocessor which is generally MUCH less powerful than whatever is in your personal computer, some memory (RAM), some nonvolatile storage (memory like your hard drive that remembers data when the power is turned off), buttons or sensors to provide input, and often a display. The device also has a battery and/or a power supply that plugs into the wall. Think about your phone or DVD player - embedded systems generally don’t need a disk drive, CDROM, high resolution video, keyboard, multimedia, or high speed networking capabilities [Rehman and Paul, 2003]. However, cell phones are now transferring high speed data, and the storage devices (like USB memory sticks) require very little power and are being integrated into embedded devices.

(picture of embedded system components here)

Central Processing Unit (CPU)
The CPU is within the microprocessor, and is the brains of the device. It controls all timing, communications with memory and the outside world, updating any displays, lights, or output devices, and reads all input data from external devices like keypads and buttons. The CPU contains the ALU, or Arithmetic Logic Unit that performs data processing operations like addition and subtraction, and logical operations. It also contains internal registers needed to access and decode the program instructions.
Memory (RAM)
RAM is memory that is used for temporary storage of variables. The microprocessor usually contains some RAM, and additional RAM may be included as separate chips.
Nonvolatile Memory (ROM or Flash)
ROM is Read Only Memory. This is where the main program is usually stored. It is written once when the device is manufactured, and then never changed. Flash is a different and newer kind of memory that can also be used to store the program. One difference is because it can be rewritten like a hard drive. Nonvolatile memory is used to store any data that must be saved over time. In the past, only ROM was include inside the microprocessor; now it is common to find flash memory inside as well.
Embedded systems typically wait for, and then respond to, data that they sense from the outside world. Common inputs include sensors and buttons. My microwave waits until I enter a time using numbered buttons. When I press start, it takes the number I entered and runs the microwave for that period of time. The rest of the time, my microwave sits happily on the counter waiting for someone to press more buttons.
Buttons are digital inputs (the button is either pressed or not pressed .) Inputs may be analog as well. The thermometer on my window sill measures the temperature outside every few minutes, and then displays the value for me to see at any time. Analog data like temperature must be converted into digital signals that the computer can understand. This is done using A/D (analog to digital) converters that are often included as an internal part of the microprocessor.
Embedded systems don’t just sense external conditions, they often respond by moving motors, flashing lights, and sending data messages through cables or over the air. My microwave responds to the “START” button by shooting microwaves into my cup to heat my cold coffee. Outputs can also be analog or digital. To create analog outputs, a DAC (digital to analog converter) is used.

Trends in Embedded Systems

Technological advancements allow four different trends in embedded systems: smaller size, lower price, same features-different technology, and new features.

The first trend is size; embedded systems are getting smaller and smaller as the components inside them shrink. Semiconductors (e.g., chips, ICs, microprocessors, memories) continue to shrink as manufacturers try to pack the same functionality in a smaller package. Remember the first cell phones that came in suitcases? How about the first portable video recorders were? Check out this 1967 General Electric portable video tape recorder tri-pack: TE-23 cctv camera, TH-31 monitor and the TD-1 tape recorder. [Ref] This is an embedded system!

Ancient GE video recorder

The second trend is toward lower prices for the same devices. This is due partially to cheaper components and performing some design and manufacturing done overseas, but it is also due to component customization. A single custom ASIC (application specific integrated circuit) can be created to perform the tasks of several individual hardware chips and support circuitry. An entire circuit board can be shrunk into a chip! Creating an ASIC is a common step in the development and manufacturing process of a product. If the product is successful, a larger profit can be had if the cost to build the device is decreased, and an ASIC can make this possible.

The third trend is in maintaining functionality using a different technology. For example, consider old and new phone answering machines. When answering machines first came out, they were larger than most phones and somewhat expensive. Messages were stored on tape and the device had many moving parts. Moving parts are potential points of failure, leading to returns and reduced profits. New answering machines perform the same functions as the older machines, although messages are stored digitally on memory chips rather than on tape. Fewer moving parts and cheaper components result in a more robust product with fewer returns and increased profit for the manufacturer.

A fourth trend, and maybe the most obvious, is creating totally new devices, or creating new features for existing devices. Washing machines can now sense the level of water “dirtiness” and adjust the wash cycle accordingly. Your car can remember exactly how you like your seat positioned. Cell phones now take pictures and video and allow you to send these to your friends and family over the air. USB memory sticks are replacing floppies for easy transfer of large data files and pictures. (Remember backing up your computer in the 1980’s using 360K DD 5.25″ floppies? Then the high density, and then the much loved 1.44M 3 1.2 ” floppies came along, and in funky colors.]

Even if embedded systems seem “low tech” compared to your personal computer, many technological advances are targeted specifically at the embedded market to improve characteristics (like power consumption) that are less important to the PC market.

Power Consumption

As a developer, you will be more concerned about how often your device needs be charged than if your device can support high speed graphics for multi-player interactive games (at least for the present!). The hardware design will determine a baseline level of power consumption for your device, but careless software can radically reduce battery life.

The code I write affects how fast the battery drains? Yup. More specifically, how you write the code is as important as what you write. Although this may sound strange, a major goal when writing embedded software is to keep it from running. All the time that your code is running, the battery is being drained at a higher rate than if the microprocessor is sitting there doing nothing (i.e., in “idle” or “sleep” mode). Inefficient code takes longer to execute and it keeps the microprocessor busy for longer periods of time. And the battery bars start dropping!

What does “idle mode” mean? Think of it this way - you work in the mail room and whenever a package or letter comes in, you have to deliver it to the correct department. Say you deliver a letter to the marketing department and when you return, another letter is waiting, so you have to turn around and walk all the way back to marketing again. And so on. You could end up exhausted at the end of the day. So you get the idea to wait up to an hour before delivering anything to marketing . . .if the marketing folks are okay with receiving letters up to one hour late, then you only have to walk over up to 8 times a day rather than continuously. You save energy and you have time to do other things, and you are not exhausted at the end of the day.

You can use the same technique to conserve power (battery life) in embedded systems. Microprocessors are like people in a way - if you don’t ask them to do anything, they don’t tire out (drain the battery) as quickly. Running a local 5K race for charity requires more energy than watching the Saturday Monster Garage Marathon. Your cell phone battery lasts a lot longer when you don’t make phone calls. Anything that is not really time critical can be done less frequently to conserve power.

Embedded folks have special language to refer to processors that are in “idle mode” or “sleep mode.” These modes are pretty self-explanatory; when the processor is in sleep mode, it’s almost dead to the world. It is not very aware of what is going around it, and as a consequence, it draws very little power. But it has to “wakes up” regularly to check things out and see if it has to do anything. If something important and unexpected happens, the processor can be roused from sleep mode with a special interrupt. In idle mode, the processor is awake and “listening” but may not doing much. In this mode, it can respond to requests much more quickly but burns through batteries faster.

But good power consumption is more than just minding idle and sleep modes.

Software can save (or waste) battery life even when it’s doing its normal job. It depends on how efficiently it does its job.

Using the mail room example again: you might walk to marketing using a direct route, or you might wander by the courtyard and the cafeteria each time because the view is nice. But your manager might suggest that you take the stairs and walk through the dreary middle of the building to get there faster. Same thing with embedded systems - you will end up at some point rewriting parts of your code to run faster and more efficiently so it isn’t wasting power wandering through inefficient code. These software revisions change no functionality, but are just to save battery life.

“Live long and prosper: juggling performance and battery life in hand held systems” by Boris Donskoy, at EDN.com

Real Time Requirements

An important part of designing embedded systems right the first time is to pay close attention to the requirements. Not a favorite activity for most developers, but embedded systems often have real-time constraints that are more important that a flashy user interface and cool packaging.

Back to the mail delivery example. Maybe the folks in marketing only open their department door every hour on the hour for just 60 seconds at a time. If you are a little late delivering the mail, you have to wait another hour for the door to open again. But what if they need that FedEx document RIGHT NOW? You just failed a major “hard” timing requirement.

The “canonical definition of a real-time system” (from Donald Gillies), is the following:

“A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred.” (Emphasis added.)

Let’s talk about different TYPES of Time… Embedded engineers must assure not only that the system performs as advertised, but that it guarantees timing behavior - timing constraints can radically affect how the system must be designed. Below are different TYPES of TIME that embedded engineers must handle… (adopted from Agrawal and Bhatt) and Ganssle.

  • Hard real time: System responses must be within the deadline, late response means system failure (e.g., medical equipment monitoring vital functions)
  • Soft real time: Requirements based on average response time. Deadlines are important, but still functions correctly with delay (e.g., airline reservations)
  • Firm real time: Multiple definitions 1) soft real time, but no benefit from late delivery, 2) shorter soft requirement and longer hard requirement, e.g., mechanical ventilator can be few seconds late, but not more.
  • Real real time: Hard real time with very short response time.


Embedded systems typically have significantly less memory than regular computers. This places a challenge on the developers to carefully plan how much memory is needed for the device, and to make sure that the software is written efficiently in the available space. While it may be tempting to just throw in a larger memory chip, that drives up the total cost of the device and your company makes less money for each one sold. Although some folks may say that software is free because it is just ones and zeros, this simply is not the case for price-critical embedded systems.


Many embedded systems must run for long periods of time without failure. System reliability may be for safety (pacemakers are turned on once and expected to run indefinitely), remote access (a transmitter at the top of a cell phone tower or attached to a whale for location tracking is more difficult to service) or product life (embedded systems in sneakers, some toys, and singing birthday cards are not designed to be repaired). With some devices, death could result in the time it takes to reboot the system. Next time your computer presents the “[program name] has detected an error and must close” message, think about what software you’d like running in the navigation control unit during your next airline flight.

Okay, this sounds a little doom-and-gloom, but reliability is a major consideration when designing, developing, and testing embedded systems. And reliability is more than just ensuring that the system doesn’t need to be periodically rebooted; reliability refers to the selection of appropriate parts (hardware and software), stress testing, life cycle testing (simulating the wear and tear on a device during its entire life cycle), and failure mode analysis (how does it fail, and what happens when it fails?).

All devices can fail in one way or another, and part of the challenge is predicting what types of failures can occur and then ensuring that the device fails in a safe manner.

For example, if your anti-lock brakes fail, you’d expect that normal braking function will still perform without the extra ABS feature. This is often referred to as “failing gracefully” in which the minimum functionality is retained.

Another example is my scuba diving computer, which has some basic features that tell me how much air I have in my tank and how deep I am. It can also compute how long I can stay at this depth before I risk the bends, depending on what type of gas I am breathing (e.g., regular air, air enriched with oxygen, pure oxygen, helium and oxygen). If the computer fails or enters some type of lockout mode, it is supposed to default to a “dumb” gauge and just provide basic information: my depth and the air left in my tank. In this case, failure mode will still give me the information I need to return safely to the surface. Of course it may flood and stop working completely, but one reliability goal is to have the device try to fail with at least some minimum functionality.

User Interfaces

A major challenge in designing effective embedded systems is the user interface. As users, we like consistency and intuitive interfaces, and we don’t like to read the manual. So the interface had better be pretty self-explanatory.

Most embedded systems do not have a Windows-like display. So designing a custom display allows us to start with a blank slate and do whatever we want! Use wild colors! Put buttons in rows or in circles! And use different colored LEDs to make it flash like a Christmas tree!


Pick up several devices and look for common elements like ON/OFF buttons. Since this is the first button you look for, it is generally in a logical place. The ON button for all my remote controls is either on the top right or the bottom right, and most of them are green buttons to contrast the black ones. (Except TiVO. There is always the exception…) Consistency teaches us to expect the ON button to be in a similar place for other remotes and devices, and a check around my house shows this to be true. While some actually say “On/Off,” a trend is towards the international symbol for the power ON/OFF switch:
universal power symbol

Using recognizable symbols and standard layouts makes your device less confusing and easier for the user to learn.

An entire field of research and development focuses on the creation of appropriate user interfaces. There are a lot of ways to do it correctly, and apparently even MORE ways to screw it up. Since I am not an expert, but a student in the field of user interfaces, I offer some humorous examples of User Interfaces Gone Bad. If you let even ONE person try your proposed user interface, you will receive valuable feedback.