Special-purpose computers are taking over a diverse array of tasks. The typical, new car contains dozens of microprocessors, a commercial airplane, hundreds. Embedded systems—as special-purpose computing devices are called—are running rampant in the modern home, playing an increasingly important role in entertainment devices, heating systems, and kitchen appliances. They are also cropping up in new guises, notably in the form of wireless sensor networks (see "A Tiny Revolution").
As embedded systems gain a stronger foothold, there has been an explosion in the complexity of the technology that goes into them. Whereas once such systems were constructed completely from special-purpose hardware, now some of the functions are being implemented in software. Similarly, the hardware in embedded systems is taking on a more software-like role as size and power constraints force components to be used for multiple purposes. "It's an interdisciplinary movement," says Edward Lee. "We are blending traditional EE with CS."
EECS Professor Alberto Sangiovanni-Vincentelli in his kitchen at home in Berkeley. (Photo by Peg Skorpinski) A key element of the blend is that things happen both concurrently and sequentially, which makes it a challenge to ensure that these new systems behave predictably. To address this challenge and others, Lee and Alberto Sangiovanni-Vincentelli, in parallel projects, are laying out a theoretical framework for embedded systems.
Sangiovanni, in his "platform-based design" approach, envisions system components as multicolored Lego blocks that can be reliably assembled in a variety of combinations. A specification's constraints of power, memory, cost, etc., determine which type of block of a particular color to use. "There are many types of blue blocks and many types of red ones and white ones, and you use one of each to build a house according to the specification," says Sangiovanni. "For a new application, you may develop a new type of red block, or even a purple block, but you have to develop it so that the interfaces will connect."
An advantage of this framework is that it allows the different pieces of an embedded system to be manufactured by independent agents and then reliably assembled. It also enables developers to focus on finding the optimal combination of blocks to meet the specification, rather than on the blocks' implementations. "That an embedded system blends hardware and software is completely irrelevant to what it does," Sangiovanni notes.
Nonetheless, behind the scenes, combining blocks that blend software with hardware poses a myriad of technical challenges. One issue is timing. In hardware, all the components operate concurrently, while in software, there are linear sequences of actions and no easy way to specify when they happen. This makes standard software awkward to use for applications that rely on the precise execution of tasks, such as a car ignition system. "The basic abstractions of software are not suited to embedded computing," Lee says. "Software is lousy at expressing timing."
A related problem is concurrency; that is, when software is performing multiple tasks in parallel. The prevailing model for concurrency, "threads of execution," has the disadvantage that interactions between programs are difficult for programmers to anticipate. When software programs squabble over resources, the result can be a computer crash. This is tolerable (barely) on a home computer but not on a special-purpose computer that is performing a critical task.
For these reasons, programmers of embedded systems software often resort to working directly in assembly code, a strategy that is not viable in the long term as applications become increasingly sophisticated. To create easy-to-code embedded software that is reliable, Lee says, all the core abstractions of computing—programming languages, operating systems, architectures, networking techniques, and memory and power management—need to be modified. "It's an enormous challenge," he says. " A lot of pieces of the picture are fuzzy still."