Building Intelligence
Neil Gershenfeld and Raffi Krikorian
briefing notes draft: June 11, 2002

Architecture  Vision  Timeline  Implementation  Standardization  Sponsorship  Specification


Architecture

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.


Vision

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.



Timeline

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 tangible interface was provided so that physical interactions could update these data.

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 Carrier Comfort Network (CCN) devices such as fan coils and thermostats interfaced to embedded Web servers with both local and remote readout and programming. This was followed by a test installation in Barcelona in September 2001, developed with the Metapolis architectural collective led by Vicente Guallart and Enric Ruiz and supported by a network for Catalan institutions. This group was seeking to pick up where Antonio Gaudi left off. Gaudi brought enormous expressiveness 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.



Implementation

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.


Standardization

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.


Sponsorship

Corporate partners are working with this project at many levels. At the highest, a number of companies have made naming grants for spaces in the new building, in order to seed long-term activity in areas of joint interest, and develop strategic partnerships to jointly manage relevant resources for shared activities on both sides. These include Motorola for embedded processing, Lego for play, Mastercard for financial transactions, Swatch for design, and British Telecom and Telmex for communications. Corporate Research Partners are members across the Media Labs and base a research group there; these also include companies such as HP, Intel, the United States Postal Service, and eircom. Sponsors of Media Lab research consortia and of the Center for Bits and Atoms receive royalty-free rights to all of the shared intellectual property; this cost tracks the carrying cost of a research employee, and buys the work of about 400 people in a $40M/yr program. Below that, Affiliate sponsors participate in the programs without free intellectual property access, and a number of vendors are providing materials at internal costs as part of their participation in the project.

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.



Specification
(transferred to sponsors under license)

circuit diagrams
printed circuit board layouts
microcode
interface software