0018-9162/07/$25.00 © 2007 IEEE32 Computer Published by the IEEE Computer SocietyCOVER FEATUREWe see the main culprit as the lack of rigorous tech-niques for embedded systems design. At one extreme,computer science research has largely ignored embed-ded systems, using abstractions that actually removephysical constraints from consideration. At the other,embedded systems design goes beyond the traditionalexpertise of electrical engineers because computationand software are integral parts of embedded systems. Fortunately, with crises comes opportunity—in thiscase, the chance to reinvigorate computer scienceresearch by focusing on embedded systems design. Theembedded systems design problem certainly raises tech-nology questions, but more important, it requires build-ing a new scientific foundation that will systematicallyand even-handedly integrate computation and physi-cality from the bottom up.2Support for this foundationwill require enriching computer science paradigms toencompass models and methods traditionally found inelectrical engineering.3,4In parallel, educators will need to renew the computerscience curriculum. In industry, trained electrical engi-neers routinely design software architectures, andtrained computer scientists routinely deal with physi-cal constraints. Yet embedded systems design is periph-eral to both computer science and electrical engineeringcurricula. Much of the cultural wall between the twofields can be traced to differences between the discretemathematics of computer science and the continuousThe wall between computer science and electrical engineering has kept the potential ofembedded systems at bay. It is time to build a new scientific foundation with embedded systems design as the cornerstone,which will ensure a systematic and even-handed integration of the two fields.Thomas A. Henzinger, EPFLJoseph Sifakis, VerimagComputer science is maturing. Researchers havesolved many of the discipline’s original, defin-ing problems, and many of those that remainrequire a breakthrough that is impossible toforesee. Many current research challenges—theSemantic Web, nanotechnologies, computational biol-ogy, and sensor networks, for example—are pushingexisting technology to the limits and into new applica-tions. Many of the brightest students no longer aim tobecome computer scientists, but choose to enter directlyinto the life sciences or nanoengineering.1At the sametime, computer technology has become ubiquitous indaily life, and embedded software is controlling com-munication, transportation, and medical systems. From smart buildings to automated highways, theopportunities seem unlimited, yet the costs are often pro-hibitive, and dependability is generally poor. The auto-motive industry is a good example. As each car receivesan ever-increasing number of electronic control units,software complexity escalates to the point that currentdevelopment processes and tools can no longer ensuresufficiently reliable systems at affordable cost.Paradoxically, the shortcomings of current design, val-idation, and maintenance processes make software themost costly and least reliable part of embedded appli-cations. As a result, industries cannot capitalize on thehuge potential that emerging hardware and communi-cation technologies offer.The Discipline of Embedded Systems DesignOctober 2007 33mathematics of traditional engineering. Theindustry desperately needs engineers who feelequally at home in both worlds. The embed-ded systems design discipline has the poten-tial to produce such integrated talent. Butdefining its scientific foundation will take aconcerted, coordinated effort on the part ofresearch, academia, industry, and policymakers.THE DESIGN PROBLEMAn embedded system is an engineering arti-fact involving computation that is subject tophysical constraints. The physical constraintsarise through the two ways that computa-tional processes interact with the physicalworld: reaction to a physical environment andexecution on a physical platform. Common reaction con-straints specify deadlines, throughput, and jitter and orig-inate from behavioral requirements. Common executionconstraints bound available processor speeds, power, and hardware failure rates and originate from imple-mentation choices. Control theory deals with reaction constraints; computer engineering deals with executionconstraints. The key to embedded systems design is gain-ing control of the interplay between computation andboth kinds of constraints to meet a given set of require-ments on a given implementation platform.General versus embedded systems designSystems design derives an abstract system representa-tion from requirements—a model—from which a sys-tem can be generated automatically. Software design,for example, derives a program from which a compilercan generate code; hardware design derives a hardwaredescription from which a computer-aided design toolcan synthesize a circuit. In both domains, the designprocess usually mixes bottom-up activities, such as thereuse and adaptation of component libraries, and top-down activities, such as successive model refinement tomeet a set of requirements.Although they are similar to other computing systemsbecause they have software, hardware, and an environ-ment, embedded systems differ in an essential way: Sincethey involve computation that is subject to physical constraints, the powerful separation of computation(software) from physicality (platform and environ-ment)—traditionally, a central enabling concept in com-puter science—does not work for embedded systems.Instead, embedded systems design requires a more holis-tic approach that integrates essential paradigms fromhardware and software design and control theory.Differing design principlesEmbedded systems design is not a straightforwardextension of either hardware or software design. Rather,design theories and practices for hardware and softwareare tailored toward the individual properties of thesetwo domains, often using abstractions that are diamet-rically opposed. Hardware systems designers, for example, composea system from interconnected, inherently parallel build-ing blocks, which can represent transistors, logic gates,functional components such as adders, or architecturalcomponents such as processors. Although the abstrac-tion level changes, the building blocks are always deter-ministic, or probabilistic, and their composition isdetermined by how data flows among them. A buildingblock’s