MIT's Media Laboratory is
embarking on an ambitious construction project that will significantly enlarge
its intellectual as well as physical space. Along with rebuilding its existing
I.M. Pei building
, the Pritzker-Prize-winning architect Fumihiko Maki has designed
an adjoining new 196,000 sq ft building
. Site preparation for this structure began in the Fall of 2001,
with construction starting in 2002 and occupancy expected early in 2005.
Along with existing Media Lab activities, this facility will house new initiatives including the Center for Bits and Atoms, which will bring together both the technical and theoretical infrastructure required to simultaneously shape the content of information and its physical properties on length scales from atomic nuclei to global networks, and the Okawa Center for Future Children, which will be exploring internally and externally the impact of emerging information technologies on the development of children and the environments they live in around the globe.
These resources are all
being designed in the Media Lab tradition of large interdisciplinary shared
workspaces. The building is divided into interlocking
multi-story labs
built around a soaring central atrium with transparent
elevators
, to enhance the visibility within and among the labs. For maximum
flexibility, building services are distributed and accessed via a re-configurable
floor system that provides distributed access to data and power on a 4-foot
grid throughout lab and office spaces. Walls serve only to provide visual
and aural isolation where needed and can easily be relocated.
This flexible arrangement
will necessarily create unusual adjacencies, such as bringing small children
next to dangerous machine tools. In such an environment it is essential
that the building be able to accommodate and respond to the changing needs
of both its occupants and the physical plant itself. For this reason, the
building is also being designed as a testbed for fine-grained Internet connectivity
in the infrastructure, along with scalable distributed computing to operate
it. This document explains what is being done, why, and how, with a focus
on the role of using low data-rate IP
protocols over mature RS485
and powerline
wiring to low-cost powered devices. It will serve as an active
tracking site throughout the life of the project.
The logical architecture of the building rests on two key beliefs: first, that Internet connectivity must be extended to the most rudimentary components of the building, rather than be mediated through intermediate devices. And second, that each of these elements must contain enough data and processing power to be able to execute and locally reprogram its functions without assuming the existence of another computer. These are both driven by concern for scalability.
While the desirability of Internet connectivity is perhaps obvious, its necessity warrants comment. There are many other standards in use for home and industrial networking, including X10, Lonworks, CAN bus, emWare, BACnet, and CCN. While each of these have merits in the domains for which they were developed, all face some combination of the same scaling problems that the suite of Internet protocols (IP, UDP, TCP, ARP, ...) address: limited interoperability, restrictive embedded assumptions about how they will be used, lack of discovery and routing through hierarchical networks, limited addressing, and proprietary licensing restrictions.
Fixing these problems will
bring each of these alternatives closer to both the technical and social
architecture of the Internet, suggesting that it would be better to jump
to using the Internet protocols directly. The primary historical reason why
this has not been done has been their cost, measured in dollars as well as
relevant resources such as milliwatts, package pins, or installation effort.
But work at the Media Lab and elsewhere has shown that a complete Internet
node can be implemented with a few hundred bytes of code
, corresponding to a few thousand transistors, or tens of cents
worth of silicon. What makes this possible is "delayering": most of the
code and complexity in the Internet stack in a conventional computer is
associated with inter-layer message passing, which is a technical reflection
of the human bureaucracies that develop and use them. A dedicated stack
in a device as a simple as a light switch can reduce this overhead by orders
of magnitude while still remaining standards-compliant.
Another reason why there are so many competing standards is the differences in their performance requirements. While it is possible to run the Internet protocols over physical layers that provide guarantees on bandwidth and latency, the typical timing of commodity networks can exceed the time scale of many "real-time" requirements by so many orders of magnitude that a probabilistic performance bound does provide a statistically significant system guarantee. For example, from the 10 msec time scale of human perception to the 10 nsec time scale of an ethernet bit, there is 6 orders of magnitude available for protocol overhead.
A more-severe but less-obvious issue with using Internet protocols is their hidden cost. When a permanent computer is added to a network in a building, a system operator must assign it a network address, associate that address with both a name and a media access address, register that name in a name server, make sure that the computer is properly configured to find names and routes, and provide services the computer might need including file storage and backups, and remote software maintenance. The cost the of the fraction of the sysop's time and servers dedicated to the new computer is acceptable if the computer costs $1,000, but not if it costs $1. If a light bulb or elevator call button is to be economically connected to the Internet, it can't assume that a support person will be responsible for its configuration.
An alternative is suggested by the simple X10 home automation protocol, which uses a small set of addresses to enable devices such as lights and switches to directly communicate. This notion can be generalized to an embedded IP device by giving it a simple data structure that contains addresses of devices that it needs to communicate with, along with fragments of algorithms specifying the conditions under which messages are sent among them, and the conditions under which these data can be changed. Many such devices taken together then form a giant distributed data structure, as well as a distributed parallel computer that processes relevant information. Rather than necessarily routing messages through servers, as is now done in many building control systems, the servers become descriptive rather than prescriptive: they can observe and interact with the network nodes, but are not necessary to operate them.
If local devices do not rely on remote computers, then it must be possible to program them locally. This requires a locally-accessible notion of identity. To connect to the Internet a computer must have a numerical address (e.g., 18.85.0.1), and it can have an easier-to-remember name (e.g., media.mit.edu). Both of these intentionally have no spatial meaning, and hence don't capture a local sense of identity (e.g., "the switch on the wall next to my office door"). For this reason, an essential element of the system design will be the role of local interactions in determining functional identity. A light switch could be introduced to a light that it is to control by, for example, pushing a programming button on the switch followed by one on the light, or using a wired or wireless tool to carry the address from one to the other. In either case, the user introduces an association by physical interaction, then the devices communicate over the network to update their data structures and control algorithms. Such physical interactions can easily be extended to represent one-to-many and many-to-one controls, as well as analog decisions. All of these could still be set remotely over the network, but crucially they don't need to be.
There are many consequences of such an architecture. It is more reliable, because the single points of failure in the servers have been eliminated (a vulnerability that has been brought home by the dramatic failure of some building control systems following damage to the building). And it is cheaper to build, because just two such devices form a useful system rather than requiring central services. Even more importantly, it is cheaper to build because the logical configuration does not need to be reduced in advance to a detailed specification. Instead of preparing drawings showing how lights will connect to switches, and having a contractor (hopefully) follow those drawings during construction, it is necessary only to provide connections to power and data for the lights and switches and then their associations can be established later by the users. This savings recurs if the use of the space changes, requiring the control associations to change.
Perhaps even more significant is the economic impact of operating such a building. An obvious application is energy efficiency. For example, the air supplied to a room can be locally adjusted based on not just a thermostat setting, but on also aggregating data including the number of people in the room and the state of the windows and outside air. The room's VAV unit can directly receive information from those devices and act on it appropriately. That in turn leads to an even greater prospective impact: on human efficiency. The people in a building usually cost much more than the energy used by the building. If, in the same example, the data fusion and computation distributed over the sensors can help a room determine not just its temperature but the comfort of its occupants, the impact on their productivity could be much more dramatic than just a reduction in energy consumption.
Finally, the most intriguing aspect of a programmable building lies in the intersection of its logical and physical architecture. Right now there is a clear division of labor, with one architect determining the character of the physical space, and another the organization of its network and computing. But as these components become more tightly integrated, so will their functions. Inevitably, this will lead to a richer notion of "architect", as the designer of the space can also shape the look and feel of active aspects including illumination and modes of interaction, while the work of the designer of the network can be seen in physical as well as digital worlds.
In the Media Lab, an early
seed of this activity was the work of a precocious undergrad, Matt Hancher.
In 1999 he started development of the "Filament"
series of circuit boards, building on work of Pehr Anderson and
Rob Poor. These paired a simple microcontroller with an ethernet controller
and twisted-pair media access in order to effectively provide a serial port
with an IP address using just tens of dollars in parts. In its first incarnation
it simply turned ASCII bytes into broadcast UDP packets.
This was developed for practical
reasons, because a number of Lab projects growing out of activities associated
with the Things That Think Consortium were building devices and interfaces
outside of traditional computers, and they needed a way to communicate without
tying them to a conventional computer. An example is an installation
that was done at the Museum of Modern Art in New York City in
1999, that sought to provide supporting electronic information for a landmark
architecture exhibition by using the furniture in the gallery as an information
interface rather than by imposing kiosks that would take visitors out of the
visual and social space of the museum. A telling comment came at the opening,
when a beaming elderly Trustee of the museum expressed her delight with the
installation by proclaiming that she hates computers, but that here she could
access information without using a computer. What made it possible was 17 Filaments in a table
, along with many other embedded microcontrollers, but in a very
real sense having so much computing so finely distributed does effectively
make it disappear as a distinguishable entity.
The next important step
came with the arrival of H. Shrikumar, who is notable for having squeezed
a complete Web server
into a few hundred bytes of code and fit it into an 8-bit 8-pin
processor that costs about a dollar in commodity quantities. This suggested
that low-cost nodes such as the Filament could be viewed as servers as well
as clients, providing information in a form that is directly accessible
to any Web browser. But Shri's work also underscored the hidden cost in
machines and people if such Web nodes relied on information in conventional
servers in order to be able to carry out their commands, which led to his
development of distributed data structures and control algorithms so that
the information associated with a device could be resident in the device.
Then, inspired by the ideas of Prof. Hiroshi Ishii, a
Design development of the
Media Lab's expansion began in 2000, and the next major project milestone
came in August 2001 in a jointly-developed trial with United Technologies
showing
to structural engineering
, showing how it could be essential to an architect's creative communication.
But not only has that tight integration receded with the rise of engineering
through independent subcontracting teams, the increasingly-important computational
architecture of a building is nearly universally a completely independent
subsystem overlaid onto it.
Working with the Metapolis
and Catalan teams, this project developed a structural
system
based around channels from Eutrac, so
that each beam guided forces, AC power, DC power, and data. These were
used to construct a test house in a theatrical space, with the tiny network nodes
shown against a backdrop of what might be the world's largest Web browser
. This installation demonstrated
on a much larger scale how the elements of embedded IP and distributed
control with tangible interfaces could operate, and in fact was particularly
validated because much of the effort in debugging the installation lay with
the instabilities of conventional computer operating systems rather than
the relative predictability of the embedded nodes.
The installation team included
leaders in the "Internet 2" effort that is developing ultra-high-speed network
technology. By the end of the project, the track system was referred to
as "Internet 0," because it sought to create a layer below today's Internet
that provides a foundation for its interface to the physical world, and because
of the shared belief that significant new value in future network growth
will lie in low-bit-rate embedded applications in areas such as health care
. These ideas will be further explored with MIT's home of the future effort.
The planned building construction schedule is for contracts to be let
over the summer of 2002, followed by the start of construction, then for
major control components (such as air handlers) to be installed in 2003,
distributed devices (such as thermostats) in 2004, and occupancy in 2005.
Following the opening of the building, it is expected to serve as both a showcase for the new products installed and as a testbed for exploring higher-value aspects of building intelligence beyond its basic functionality, such as predictive modeling of user needs, and feedback control based on more sophisticated measures of the comfort and efficiency of the occupants. And as the products mature they are likely to be used in follow-up flagship structures on a commercial basis with partners, such as a Frank Gehry commission back in Barcelona.
The architecture
of the most complete installation to date, in Barcelona, sought
to use existing standard as much as possible, but necessarily had to do some
new development at their interfaces. The physical transport chosen for the
data in the track system was RS485, because of its
ubiquity in building control systems, and more importantly because its electrical
interface permits the network geometry to be arbitrary. This is essential
because the structure could have multiple branches and closed loops in the
mechanical design which would necessarily be reflected in the electrical
layout, and any of the communication alternatives that require impedance
matching at junctions would impose active hubs at mechanical connections,
significantly adding to the construction complexity as well as cost. A passive
multidrop network was taken as an essential design constraint.
The decision to use topology-independent
RS485 limited the bit rate in the track to on the order to 100 kbps
, so that reflections from discontinuities in a building-scale structure
could be ignored over the time scale of a bit. While this is very slow compared
to current networks, the target applications are low-bit-rate devices,
and the desirability of the ease of installation was rapidly evident during
construction. The use of RS485 provided reliable communications with a dollar-scale
cost of physical media access circuitry as well as compatibility with the
enormous industrial installed base of RS485 systems. In most installations
(like Barcelona, and the Media Lab's new building) it is likely to coexist
with a wireless 802.11 network. 802.11 provides 10
Mbps, along with mobility, but comes at a much higher per-node cost, along
with a need for an independent power source. The RS485/IP system was aimed
at simple relatively-fixed components such as lights and switches; 802.11
is appropriate for more expensive mobile devices such as laptops and PDAs.
802.11 could of course be used to provide a higher-bandwidth channel to
more expensive devices that use the track for power and mechanical assembly
as well as local I/O.
Beyond providing a mechanical mounting for devices, two rails in the track were used to supply an AC hot and neutral, two rails were used for 9V DC and ground, and two were used for the differential RS485 signalling. The AC served to power appliances such as lamps. While it was not necessary to separately provide DC, that reduced the complexity of the network nodes since they would otherwise all need DC power supplies. The differential data encoding provided good noise immunity; the runs could easily be larger than the natural logical scale of a segment.
RS485 imposes no constraints on the logical signalling used over the physical layer; we used a conventional UART to encode with serial ASCII framing the bytes of IP packets, along with their UDP or TCP headers. These were compressed from 40 to 6 bytes to save bandwidth by removing unnecessary fields, just as headers are compressed in a PPP modem connection. Although interoperability was not an issue because there are no legacy IP-over-RS485 devices to talk to, such compression is easily removed for a standard SLIP encoding. For the Barcelona installation dedicated messages were defined to represent the kinds of nodes and their messages, but the packet payload could easily carry either proprietary protocols such as Carrier Comfort Network being tunneled through an IP transport, or open-standard messages such as XML.
A number of IP-enabled devices
were developed to interface to the RS485 network, including buttons,
digital and analog I/O interfaces, a triac module for AC switching, and
a serial port targeted at communicating with a reader of low-cost ID tags,
and an ethernet interface to connect to a conventional CAT5-wired network.
Beyond providing connectivity to remote networks, the ethernet interface
is also important for scalability. RS485 has limits in both the bandwidth
and fanout of a single segment (32-128 devices, depending on interface input
impedance), hence is appropriate for directly connecting logically-related
devices, such as a lighting track or a room's control system. These segments
can then be joined with ethernet connections to active hubs, which is an
acceptable cost at the segment level.
The Barcelona project used RS485 for the physical layer, for both its
convenience in a new installation and its compatibility with existing building
control components, but a powerline version of this system will be developed
for use with existing wiring. Emerging standards such as HomePlug use aggressive
modulation schemes to attain reasonable data rates over noisy and lossy
powerlines, bringing the cost above the leaf nodes targeted here, but by
dropping the data rate to the speeds required by control systems it becomes
possible to use much simpler software RF techniques to provide reliable modulation
for the shared-channel serial protocols. And although the Barcelona
installation did not use wireless nodes because the focus was on the building
rather than user mobility, they will be developed for mobile nodes. Below
the cost and bit rate of 802.11, possible wireless protocols include both
IRDA and Bluetooth. Neither
of these was designed for native peer-to-peer IP traffic, but both can carry
such messages as payloads. Emerging research transports
will also be investigated.
IP-enabling a building does raise a range of security concerns, as well as point to possible solutions. Restricting remote access to approved uses and users will require reliable network security, but that is no different from the demands placed on any corporate firewall the protects sensitive information, and the device implementations can use cryptographic standards such as IPSEC and SSH. Added security can be provided by associating logical access with physical access, so that potentially-dangerous operations require authentication by a device in person as well as over the network, and vulnerable parts of the network are kept separate from ones that are intentionally easily-accessible. There is also a risk of physical damage caused by incorrect commands accidentally executed by authorized users; this will require clearly identifying in the protocol implementation the fixed functionality required by the manufacturer, and the circumstances under which users can add associations on to that.
Although IP is a mature open standard, embedding it in building systems raises a number of standards questions. This starts with the form factor. The track system used for the Barcelona installation was convenient where mechanical access needed to be distributed, and could be standardized as conventional lighting tracks have been. But for distributed control systems there will need to be a standard for separate electrical connectors and wiring. And if the integration with structural systems is further developed, there will need to be a standard for their form factors and joining systems.
RS485 does not specify how
channel contention is handled, which is not an issue in a conventional master-slave
configuration, but does need to be addressed for peer-to-peer networking.
Both here and for low data-rate powerline signalling, activity detection
as well as modulation will need to be specified as part of the media access
to implement CSMA/CD-like channel sharing.
At the logical layer, either a dedicated IP port could be defined for these messages, or an existing port such as 80 (for HTTP packets) could be used. HTTP does add overhead, but also provides immediate interoperability. The obvious way to standardize the messages sent over HTTP would be through an XML definition, such as those in Universal Plug and Play or Brazil.
The node addressing could use IPV4, which is widely deployed, but the 32 bits of address space would require that the local segments do some kind of Network Address Translation internally in order to reuse addresses. IPV6 provides 128 bits for addressing (corresponding to roughly 1000 addresses per square meter over the Earth's surface). That's easily enough to assign a unique address to any device, but isn't yet compatible with all Internet-connected computers.
These questions span the levels of description of many standards bodies, including IETF, IEEE, ISO, ANSI, EIA, and DIN. An open meta-standardization question is the appropriate home(s) for these issues. This is not something that this project can answer directly, but it can contribute to by providing exemplary embodiments of complete systems, as well as helping identify the fundamental guiding principles, and then defer to the community of partners on the implementation details.
Along with free access to intellectual property, the Labs work closely with the sponsors on developing and transferring reductions to practice so that their much-more-expensive internal labor can start with things that are known to work, and the Labs also help provide a context for this effort including external visibility and partnerships across the sponsor community. Over the lifecycle of the building project, research prototypes will be introduced into sponsor products, debugged and installed in the building as a launch test site, then used for both market visibility and the development of added-value services.
circuit diagrams
printed circuit board layouts
microcode
interface software