Workshop on Embedded Systems
March 29-31, 1999
Session: Computer Everywhere
Session: Networking Infrastructure
Summaries by Peter H. Salus
Though most folks aren't conscious of it, their homes and workplaces
are full of computersor 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
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
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
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
David Arnold, Bill Segall, Julian Boot, Simon Kaplan, and Melfyn Lloyd,
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
He was queried about "active construction" of a combination between
Linux and JavaVM. Mills said they were "beginning construction" in the
Further questions involved:
- Widget replicationwe 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
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
- 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
Pebble, A Component-based Operating System for Embedded
Eran Gabber and Christopher Small, Lucent Technologies/Bell Labs; John
Bruno, University of California, Santa Barbara; José Brustoloni
and Avi Silberschatz, Lucent Technologies/
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
- 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.
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
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:
- SQL sucks.
- Size matters.
- Speed matters.
- You don't need the whole Swiss army knife.
- Service, service, service.
- You get paid a lot, your life should be difficult; but the
software should be bulletproof when it's rolled out.
- Underestimate your user.
- People hate surprises.
- 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.
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 systeminvited 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?"