I spent the day in Boston yesterday at the the Embedded System Conference. I was supposed to go back today, but I'm a bit under the weather, so I'm staying in my office.
I worked on embedded systems years ago: those were the days when what you could expect for a processor in an embedded system was an 8051 or maybe a 6802. Back when I was an accelerator Physicist, the electrical engineers and I retrofitted an isotope-production cyclotron with 6802-based stepping motor controllers; the motors attached to the cyclotron's tuning dials, and the boards had serial interfaces to a PDP-11, which monitored the cyclotron and ran a program that attempted to keep the cyclotron tuned properly via the controller boards.
I knew then at the gut level that an embedded system did not imply a small system: those cyclotrons occupied 1000-square-foot concrete vaults, drew kilowatts of power, and put a concentrated beam of protons on a target. I also knew at a gut level that reliability can be critical in an embedded system, and that embedded systems often have hard real-time constraints.
The "embedded does not mean small" message came home to me again yesterday. So did the reliability message.
When you think of embedded systems, cell phone handsets may come to mind. From a software engineer's point of view, however, cars are embedded systems, and so are telephone PBX systems, and airplanes.
Cars are now becoming not only embedded systems but distributed systems. Ten years ago, they typically had two computers, referred to as control modules. Many weird problems were solved by swapping out or re-flashing the BCM, or Body Control Module.
These days, an automobile typically has many control units, all networked together over one or more busses. Automotive engineers use a bunch of standards -- they have as long as I can remember -- but now many of their standards seem to be related to their embedded computer software and the interfaces to the control units.
Think about telecom again: the software for a big telephone switch is massively parallel and can easily amount to 10's of millions of lines of code. If the switch handles, say, all the 911 traffic for the East Coast, perhaps its reliability matters just a teeny bit. How are you going to guarantee that reliability?
Posted by Martin Heller on September 19, 2007 07:35 AM
