Workshop on Embedded Systems

Cambridge, Massachusetts
March 29-31, 1999

Session: Computer Everywhere
Session: Networking Infrastructure
Session: Design
Session: Control
Discussion

Summaries by Peter H. Salus

Though most folks aren't conscious of it, their homes and workplaces are full of computers—or at least parts of computers. Cars, bread machines, TVs, VCRs, coffeemakers, rice cookers, dish and clothes washers, etc., etc., are full of computing power.

The Workshop on Embedded Systems, co-sponsored by the MIT Media Lab and USENIX, spent three days considering the issues and the problems.

The wide success of Hasbro's "Furby" has demonstrated just how much we can do with a six-for-a-dollar chip.

Among the "fun" things considered were "things that think": intelligent refrigerators, pantries, and cutting boards, where food freshness and suchlike would be continually monitored. ("Your can of tomatoes should be used or thrown away within 10 days.") Just what happens to someone like me, who buys yogurt and keeps it weeks beyond its expiry, so that it separates and I pour off the whey to cook with the residue, is unclear.

One extremely interesting talk, though, was by David Smith, president and CEO of Object Automation, Inc. "The promise of object-oriented technology has long been that of reusable, portable software components," he said. "Contemporary computing technologies, like COM and CORBA, coupled with those that accompany the evolution of personal computing . . . the PC itself, plus networking and internetworking, have provided an environment where this promise has become a reality. The benefits that derive from the reality of truly reusable software components are enormous, even though much of that benefit is yet to be realized." He emphasized factory improvements, as they spur the "fourth industrial revolution."

Talking to your box of breakfast cereal may not be in vain in the future. Whether it will be rewarding is another question. I had a vision of foodstuffs and other household products clamoring at me as I freewheel down the aisles of my supermarket. No, thanks.

Some of the graduate students at the Lab are experimenting with building circuits on paper with a Xerox machine. Metallic inks seem to work fine and (experimentally) they can do away with the chip in packaging. (They did a box of mix that responds to pressure on a list with the print of that specific recipe.) Perhaps there will be an electronically dense wrap so that we can cut off the packages' eyes and ears.

But the creation of neat things isn't all.

Session: Computer Everywhere

The Personal Node (PN)
G.G. Finn and Joe Touch, University of Southern California

PN is a small wallet-card that connects to the Internet. Among the points made were:

• Bodies on line: heart attacks not treated in time cost $130 billion a year.

• Remote needs: objects that can find us.

The most interesting questions and answers:

• How does one distinguish what's important? Simple set of buttons; half-size of PalmPilot; then shrink down.

• Geographic addressing? Perhaps GPS.

• Authentication for financial transactions? We'd like this — mapped to user.

• Policy issues: privacy; tracking. What does privacy mean? We don't know. What about anonymity?

• How does the device know good guys from bad guys? There are more than merely aggregation problems.

Several folks questioned the value of IR and RF links and one remarked that the authors were wrong on the IP issue.

Discourse with Disposable Computers: How and Why Will You Talk to Your Tomatoes
David Arnold, Bill Segall, Julian Boot, Simon Kaplan, and Melfyn Lloyd, DSTC

These guys have read too much Neal Stephenson. Picture Hiro's pizza box extrapolated to chewing-gum wrappers. Now, anticipate the clamor as you pass a trash can. Think of the event volume.

The most pressing discussion concerned the "noise" level; the notion of "content-based routing"; and the fact that a subscription model is dependent on receivers, not senders.

Smart Office Spaces
Bora Akyol, Alden Jackson, Rajesh Krishnan, David Mankins, Craig Partridge, Nicholas Shectman, and Gregory Troxel, BBN Technologies

This was an entertaining, "toy" paper. I was irritated by some sexist remarks ("a confident touch typist should be able to edit a file if she has access to a keyboard . . . ") in the paper, but they're not "content." It is over 30 years since I was introduced to the notion of the paperless office. I'm not holding my breath. However, the concept of "smart spaces" is fetching in a sci-fi movie, if not at large.

Scaling was the most important topic of discussion. Working within one office, or even a group of offices, lacks the real complexities of the world. Moreover, with a sea of devices, how much security can there be? Will we end up with "stealth management"?

Session: Networking Infrastructure

AirJava: Networking for Smart Spaces
Kevin Mills, NIST

This was a different presentation on smart spaces. Mills sees us as "wireless islands" in a "global wired ocean." He foresees "many kinds of multicasting."

He was queried about "active construction" of a combination between Linux and JavaVM. Mills said they were "beginning construction" in the summer.

Further questions involved:

• Widget replication—we need core functionality, not JavaVM that gets in the way when you start playing with Jini.

• The financial threshold: about $10.

• The NRC panel on power for the "dismounted soldier." We need new and better battery technology.

Finally, it was noted that none of the attendees was a "hardware guy," and that those are the folks who may be most important.

Bringing the Internet to All Electronic Devices
Chris Sontag and Michael Howard, emWare, Inc.

This paper began with an assumption that I thought was important and well-articulated: What's the ultimate value of networking all these devices? We must make certain that the cost involved is lower than the gain.

Considerations include processor performance, power, memory, storage, and network limitations. Understanding costs and the problems involving end-user education are very important.

Questions that struck me:

• How do we change program locations? We reload portions or whole applications.

• How do we program? What sort of APIs can we have? We definitely need very flexible products.

• Security? With so many devices isn't physical security a problem, too? There's much work to be done.

RETHER: A Software-Only Real-Time Ethernet for PLC Networks
Tzi-cker Chiueh, State University of New York

RETHER is a software-only realtime Ethernet for networks made up of programmable logic controllers. I really liked this paper because it constrained its domain: PLCs are used overwhelmingly in industrial automation. At the same time, the software involved must be both fault-tolerant and not socket-based.

The discussion was quite animated. The use of single shared media assumes a point-to-point link, and whether each node needs to know which other node is using RT was among the topics. The speed of bandwidth growth was another subject. This led to the question of the capacity/performance curve and whether service guarantees were feasible. The final queries dealt with statistical loading and efficiency.

Session: Design

Pebble, A Component-based Operating System for Embedded Applications
Eran Gabber and Christopher Small, Lucent Technologies/Bell Labs; John Bruno, University of California, Santa Barbara; José Brustoloni and Avi Silberschatz, Lucent Technologies/ Bell Labs

Pebble is an OS designed for high-end embedded communications devices. It comprises a set of replaceable, user-level components. There are benchmark results that appear to demonstrate Pebble's effectiveness.

• What about priorities? Done inside the scheduler — interrupts are converted to schedules and delivered immediately, but not acted upon immediately.

• Portal generation is a one-time event.

• Is portal generation interruptable? Only when you are placing into the table.

• Untrusted components: you can still spoof the system. Software checking is needed.

• The scheduler knows about all the threads: "If you can't trust your scheduler, who can you trust?"

Massively Distributed Systems: Design Issues and Challenges
Dan Nessett, 3Com Corporation

Nessett envisions systems involving billions of nodes; the paper discusses the engineering problems this entails. The discussion included questions about unifying principles, measurement, testing and debugging, etc.

• What about the health industry? It's never an early adopter.

• Is there a way to control complexity through software? Central control is an impossibility.

Session: Control

Learning in Intelligent Embedded Systems
Daniel D. Lee, Lucent Technologies/ Bell Labs; H. Sebastian Seung, MIT

Lee and Seung have built a robot dog that learns to identify sounds and faces. It looks great, does its thing, and is built out of $700 worth of off-the-shelf parts. The mathematics was worth the price of admission. Watching the "dog" "walk" and search and identify was very impressive. It's the perfect pet for a small apartment.

Using Mobile Code Interfaces to Control Ubiquitous Embedded Systems
Kari Kangas and Juha Röning

All the code appeared to be in Java; insecurity is still a major drawback. The discussion focused on:

• different kinds of mobile-code protocols

• comparisons with Inferno involving the fact that this avoids using only one language (37KB of code)

• uses of code standardization

Challenges in Embedded Database System Administration
Margo Seltzer, Harvard University; Michael Olsen, Sleepycat Software

This was a really interesting paper because of the topics covered and the points made.

While the paper per se involved database architecture and the problems entailed by administration of embedded databases, perhaps the best portion of the paper was its list of aphorisms, some of which were:

1. SQL sucks.

2. Size matters.

3. Speed matters.

4. You don't need the whole Swiss army knife.

5. Service, service, service.

6. You get paid a lot, your life should be difficult; but the software should be bulletproof when it's rolled out.

7. Underestimate your user.

8. People hate surprises.

9. Resilience in the face of failures is important.

I'll stop here. The discussion involved the sheer size of some of the code; that complexity is still something we don't have a handle on; and that by-and-large humans adapt to failure.

Discussion

What Have We Learned? Where Do We Go?
Dan Geer, CertCo

Workshop co-chair Dan Geer led a (to me) interesting and important discussion concerning a variety of points central to the notion of the future of workshops like this one.

One participant, for example, said that he felt the workshop had been too diffuse, "all over the place," and (though interesting) had contained nothing he found of value. There were so many pieces — networking, security, ubiquity, control, robustness, etc., etc. — that he was like the blind men and the elephant.

Geer asked, "Who or what is missing?" Hardware guys, chip designers, etc., appeared to be the most obvious. The DNS folks and the IPv6 folks were also absent.

It was obvious that while no one was willing to define what an embedded system is, everyone thought they'd know one when they saw one. Even the question of what exactly a device is was brought up.

After a discussion of resilience and recovery, "Do we standardize?" was asked. Co-chair Mike Hawley indicated a strong "no." "Standards are an Ice Age," he said.

It became clear that we should become accustomed to living with incoherence (identity, language, scope of detection); that important questions were: "how do I talk to you?" and "explain yourself."

There was a lot of talk about hybrid vigor. Diversity is important in development. This vigor needs to be felt in domestic technology, factories, transportation, and office services. If it works (well enough), it will get installed.

The workshop concluded with a proposal that it be done "again, only better." Make it three days once a year or two days twice a year, preferably the latter. Keep the joint Media Lab / USENIX / Cambridge venue until we have a reason not to. Each morning is a case study of an actual deployed system—invited on the basis of its known relevance and using demos if at all practical. Make the afternoon some mix of theoretical results and general argument, possibly broken out into topic groups. Keep the number of participants small but get reps from the areas that should have been there this time but were not. Keep the workshop style as long as possible. Have, if someone will do it, some organized sense of what is unsolved (such as whether every device should be required to "explain itself" on demand) and keep a scorecard on progress. Pay as much attention to what has failed in the market (of ideas or of money) and why. Keep a place for refereed work (so those with a need for formal bibliography growth can participate) but have no qualms about inviting the rest of the event. Continue to have meals together but arrange both meeting and eating spaces to maximize conversation. Evolve into side-by-side events if and only if specialization is essential to progress. Geer: "Think big — somebody will and why not us?"