Bruce Jacob - - Embedded Systems Research
Embedded Systems Research: OverviewThere are three main problems that our group is investigating in the area of embedded systems:
By way of background, an "embedded system" is a computer that has been embedded into some larger framework to supplant a dedicated electro-mechanical system or circuit. The processor's job is typically control and/or signal processing. The reason it replaces the dedicated system/circuit is because microprocessors are (finally) cheaper than even extremely simple hand-built systems/circuits.
Addressing problem one ...
Embedded systems are designed at a high level using something like MatLab. The control portion of the system ("control" as in control theory) is represented as a set of differential equations, and the plant being controlled (e.g. a motor, a robotic arm, a heating coil, a disk spindle, etc.) is also represented as a set of differential equations. This form of modeling is very high-level; an evaluation of the systems's behavior can be made very quickly; the model is reasonably accurate; and this is "the way it is done" in embedded systems. However, once one has identified a set of control laws that work correctly, one must turn that into software running on a microprocessor. This is done by hand -- it cannot be automated (very successfully) with today's tools. Similarly, once one has identified a hardware specification for the plant being controlled (shape of the robotic arms, number and type of sensors, etc.), one must turn that into a physical design -- and this is also done by hand. Because the transformations are done by hand, there is no guarantee as to how accurately the final physical product reflects the differential equations from which it was specified, designed, and built. Moreover, because the software-level modeling is so high-level, the first time one can actually verify the system is at the point the physical components are integrated. That is, you have to build it before you can test it. Needless to say, that is extremely time-consuming, expensive, and error-prone.
(Here is a Quicktime Movie that illustrates what this is about, and what types of things people at the University of Maryland are doing to address the problem)
Our group has developed a simulation framework (called SimBed) in which one can model on a workstation the actual software and hardware components of the embedded system, as well as a functional model of the plant being controlled. Thus, the system can be designed -- and verified -- before you build any hardware at all. The software that is simulated in the verification is the same software that will be used in the final physical system. The benefit: verification can be relegated to software -- i.e., automated -- which means it can be faster, more comprehensive, and infinitely cheaper.
Addressing problem two ...
We are using the simulation environment described above to investigate novel microprocessor designs that enhance the reliability and predictability of embedded systems. Modern processors use many techniques to increase performance ... it is important to note that the AVERAGE performance of the microprocessor is increased by these mechanisms, and this is usually at the expense of the (predictability of the) INSTANTANEOUS performance. This works well for desktops, laptops, and servers, because users of these machines only care about "how fast does my spreadsheet recalculate?" "how fast is my website loaded?" "how fast is the screen redrawn?" This implies good average performance. However, designers of embedded systems care nothing about average performance and instead care only about the instantaneous performance of the system ... each instance of a piece of code must have the same behavior every time it is executed, otherwise static analysis of the system's behavior becomes VERY complicated and/or enormously pessimistic (yielding a highly inefficient and/or overbuilt system).
What we have been doing is looking at the boundary between hardware and software to find instances where functions traditionally