You know that little light that turns from green to red on your Brita filter when it needs to be changed? That's an embedded system. That keyfob that makes it oh-so-convenient to open your SUV's hatchback from twenty feet? Embedded system. The timer on your oven that tells you your casserole is finished? You guessed it. Embedded systems aren't just the obviously complex things you may use.
As the march of technology continues, more and more objects are becoming smarter. In your home, you probably have embedded systems in your thermostat, television, kid's toys, and just about any kitchen appliance that's less than fifteen years old. On the road, there's an embedded system in nearly every traffic light, gasoline pump, flashy billboard and sprinkler system you pass. Heck, in your car alone there are probably a number of embedded systems, if not dozens.
Since embedded simply means "inside something else", and system is a generic term to describe something that is organized for a purpose, the term "embedded system" is pretty generic. However, it is generally accepted that the following things are required:
- Power Supply: The system must draw power from some source. This may be through solar cells, batteries, kinetic energy, or even an electromagnetic field. Often a discontinuous power source such as light or movement will be used to charge a rechargeable battery or supercap, and electrical power will be drawn from there.
- Input: The system must recieve input to process. For a small monitoring system this may be as simple as a microswitch to detect physical contact, a thermistor to measure temperature, or a Hall effect sensor to pick up changes in a magnetic field (the latter of these is often used with electromagnets to sense axles of cars and measure traffic speed or density; this is how those morning news anchors can say "The East-West tollway is jammed from Naper to Belmont" without actually needing to look at it). A system that directly interacts with people may have more obvious input via a keypad or knob.
- Processor/Program: The "system" part of "embedded system" implies that there is some sort of logic in place to take the signals coming in and process them. This system will usually (but not always) be a microcontroller with a program (usually in assembly language or C, but more and more commonly in higher-level languages like Java) stored in EEPROM or Flash memory. This program often contains a state machine to keep track of what it's doing, and a watchdog to reset the hardware (and/or warn a human) if anything catastrophic or unexpected happens.
- Output: Obviously, once this input is processed, something must be done with it. This may mean switching a light on, changing the speed of a coolant pump, positioning a servo, or broadcasting a radio signal. Often the output is used to create a feedback loop: the system measures an input (such as the voltage from a thermistor) and uses that output to adjust an output (such as the current to a heating element) in order to maintain a desired temperature range.
Though these three elements may come in many guises or quantities, they are the basic building blocks of the overall system. (Of course, one could postulate that these are the building blocks of just about any computer system, but I digress...)
I am. Or rather, people like me are. I am an embedded systems programmer, and have written software for several of the applications I mentioned above. Since embedded systems span such a wide range of complexity and application, so does my job: one project will be designing a simple feedback system for an air pump, and the next will be developing the complete user interface for a refrigerator that can play MP3s. (I don't question the usefulness of some of these products; we get contracts and we write the software, and it's up to the clients to figure out why the world needs a stove with a built-in speakerphone.)
I'm glad to work in the field I do, because what I "do" changes based on the project I'm working on. Occasionally it can get tedious or boring, but on the whole it's a very interesting job. Yet it can be extremely nervewracking at the same time. Why, you ask? Consider this: if Minesweeper crashes while you're playing a game, or your system BSODs while you're typing a Word document, you get pissed off, that's about it.
If I make a mistake, you die.
I am, of course, generalizing for drama's sake. Obviously, if a digital watch crashes, it doesn't cause a breach in the space-time continuum or anything. If the coolant temperature sensor in your car fails, the controller will simply use a default value, and your car will run a bit rougher and less efficiently, but that's about it. Many embedded systems fail without Joe Public ever realizing it. But consider what happens if the thermistor responsible for measuring cavity temperature in an oven fails, and constantly returns an open circuit -- zero voltage, infinite resistance. Since the thermistor's resistance drops as temperature increases, the program reads this, consults its lookup table, and deduces that the oven must be stone cold. But the user has asked for a temperature of 450 degrees Fahrenheit to cook his pizza! The oven activates the heating elements at full intensity. Forever. If that oven doesn't have some logic built in to realize that nothing is getting warmer when it should be, something is going to combust.
Aside from electrical and mechanical failures, an embedded systems programmer has to plan for his own mistakes. If there's no watchdog present to ping -- letting the microcontroller know the code is still working correctly and hasn't crashed -- you had better hope that cruise control system in your car was programmed by a freaking genius, because one segmentation fault and you and your auto are barreling down I-55 at ninety miles per hour with a car that no longer gives a damn what you do to the pedals.
Again, I'm being melodramatic for effect; automobile control systems (or any other system that may put a user in a life-threatening situation) are so rigorously tested there's almost no chance of a mistake slipping through unnoticed. But my point is that when you design an embedded system, you're directly interacting with the environment more closely than any PC applications programmer ever does -- and that's simultaneously the most frustrating and the most rewarding part of the job.
Where Do We Go From Here?
As technology improves, the primary enablers of embedded systems -- lower power consumption, smaller size, and easier power generation -- improve with it. There's no doubt that more and more embedded systems will show up (or, in most cases, stay hidden) around us as time goes on. This concerns privacy activists and conspiracy theorists, but should everyday people be concerned? As someone who helps design them, let me be the first to tell you: No, not at all! Embedded systems are wonderful and nifty and good and will massage your back and give you flowers!
And as someone who knows the issues, let me tell you: The Year 2000 problem wasn't the real problem. There are many, many systems out there which use a 32-bit timestamp, systems which are permanently embedded, use non-erasable ROM to store their software, and are contained within things that will almost certainly still be in use by 2038. Personal computers may be safe, but do you think every computerized traffic light in the world will have been replaced in thirty years? Don't bet on it.