CarTel is a distributed, mobile sensor network and telematics system. Applications built on top of this system can collect, process, deliver, analyze, and visualize data from sensors located on mobile units such as automobiles. A small embedded computer on the car interfaces with a variety of sensors in the car, processes the collected data, and delivers it to an Internet server. Applications running on the server analyze this data and provide interesting features for users.

We have used CarTel in several applications, including:

• Commute and traffic portal: A Web site that shows all the trips made by a driver and makes personalized route recommendations based on the driver's own history as well as the aggregate driving history of other drivers with information along common paths. The portal provides interesting ways to visualize one's trips, and tools to analyze this data.

Note: This Boston Globe article on CarTel (which summarizes some of the applications of our project very well) suggests that “more often than not” it is better to hit the freeway than the byways in the Boston area. That happened to be true for a particular user's commute during his typical travel times. In reality, our data shows that things are much more complicated and depend on several factors, including which roads are being considered, the time of day, the day of week, weather conditions, and so on. If, upon reading the article, you decide to hit the freeway even against your better judgement, your commute may in fact take longer than you wanted it to — your mileage may, quite literally, vary!

• MyRoute: CarTel's rich data set obtained from GPS-equipped cars enables us to model delays observed on various road segments as statistical distributions. These delay distributions are used by algorithms that compute optimal routes at different times of day between two points. “Optimal” does not always mean “shortest” or “shortest time”; it might also mean “most likely to get me to place X by 9am”. MyRoute is a CarTel-affiliated project done jointly with our CSAIL colleagues, Sejoon Lim, Daniela Rus, and David Gifford.

• P2 (Pothole Patrol), a road surface monitoring system.

• Fleet testbed, a 27-car CarTel deployment in the cars of a local limo company (PlanetTran). This testbed also serves as the “vehicle” for much of our research, allowing us to deploy software and applications on a running system (in addition, some user's cars also have CarTel nodes).

• Wi-Fi Monitoring, mapping the proliferation of 802.11 access points in the Boston metro area.

• On-board automotive diagnostics & notification: Use the OBD-II interface to monitor and report internal performance characteristics such as emissions, gas mileage, RPM, etc. These reports can be combined with historical data, thus highlighting long-term changes in a car's behavior. Such a system would be able to provide the driver with early trouble notification. In the future, with enough participation, this system could compare and “mine” data across multiple cars of similar make and age to identify anomalies in particular cars (e.g., “all the other cars show a value between X and 1.3X for this sensor, but your car shows a value of X/2, which is suspicious”).

• Cars as mules. We have developed CafNet (“carry and forward network”) protocols that will allow cars to serve as data mules, delivering data between nodes that are otherwise not connected to one another. For example, these protocols could be used to deliver data from sensor networks deployed in the field to Internet servers without requiring anything other than short-range radio connectivity on the sensors (or at the sensor gateway node).

Unlike traditional automotive telematics systems that rely on cellular or satellite connectivity, CarTel uses wireless networks opportunistically. It uses a combination of WiFi, Bluetooth, and cellular connectivity, using whatever mode is available and working well at any time, but shields applications from the underlying details. Applications running on the mobile nodes and the server use a simple API to communicate with each other. CarTel's communication protocols handle the variable and intermittent network connectivity. To simplify application development, CarTel uses two well-known programming abstractions—pipes and databases—adapting them to the intermittently connected, mobile environment.

The CarTel system has three main software components. The portal is the central location that hosts CarTel applications and functions as the point of control and configuration for the distributed system. The portal is also the sink for all data sent from the mobile nodes. To simplify application development, we have developed ICEDB, a delay-tolerant continuous query processor. To transfer data efficiently, we have developed opportunistic wireless network protocols that can connect rapidly (at vehicular speeds) to access points and techniques to cope with intermittent connectivity.

CarTel applications running on the portal can either issue continuous queries using an API exported by ICEDB, or simply ask to transfer a sequence of data items from one node to another akin to a pipe (using dpipe, explained below). Both models are simple and resemble SQL and UNIX pipes, respectively.

CarTel's network subsystem has three useful components that higher layers can choose to use: opportunistic protocols, dpipe, and CafNet.

• Opportunistic protocols: Using only client-side modifications, CarTel nodes are able to achieve end-to-end connectivity across a changing set of WiFi access points much faster than in current stacks, which makes it possible to use even when the client is in range of an access point for only a few seconds. The bulk of the time can then be spent in data transfer.

• dpipe: dpipe is a delay-tolerant pipe, a transport abstraction that allows a producer node and consumer node to reliably transport data even across an intermittently connected network. dpipe optimizes for the case when the IP address of an end-point changes often.

• - CafNet: CafNet (carry and forward network) is a delay-tolerant stack that enables mobile data muling and allows data to be sent across an intermittently connected network. dpipe subsumes some of its functions now, but dpipe doesn't handle data muling.

ICEDB is a continuous query processor to process streaming data, but differs from traditional stream processing applications in how query results are sent to the querying application (running on the portal). Because network connectivity is variable and intermittent, with ICEDB:

• Queries specify what sensor data must be acquired and at what rate, how the data should be sub-sampled, filtered, and summarized on the mobile node, and in what (dynamic) priority order results should be sent back to the portal.

• Query results stream in across an intermittently connected network, and populate a relational database at the portal.

• Applications issue SQL queries on the portal's relational database to retrieve data they need for further analysis, visualization, etc. These are snapshot queries that run on whatever data is currently available. Applications do not wait synchronously for the results of continuous queries.

Thus, applications can think of the data distributed across the mobile network as being stored locally in a standard SQL relational database, which simplifies how they are written. The programming model is familiar, essentially the same as what web developers today use. ICEDB deals with the underlying complexity of distributing queries to the mobile nodes (where they run in situ), coping with the network's vagaries, and ensuring that the results are available locally.

ICEDB handles heterogeneous sensor data, allowing the set of sensors to be expanded without requiring major software changes on the remote nodes. Each sensor has an adapter running on the node that handles the details of configuring and extracting information from that sensor and converting it into a normalized form. To ease management and deployment, when a new sensor is added, or when the functions of an adapter need to be modified, only the adapter module needs to change.

The portal includes a geo-spatial data visualization system that stores sensor data from cars. It organizes data in terms of traces, which are sets of sensor readings collected during a particular drive. Users are given a simple graphical query interface for selecting the traces they are interested in and visualizing various summaries, statistics, and maps within or across the traces they select.

Click here to see a brief walk-through of the portal.

The central enabling component of our system is a small yet powerful embedded computer running Linux 2.6 (previously, 2.4). We currently use Soekris net4801, though other similar devices running Linux would also work. Our unit has a 586-class processor running at 266 MHz with 128 MB of RAM and 1 GB (or more) of Flash. It has 2 serial ports and a USB 1.1 port for external devices. This expandable unit comes in rugged package.

Reasonably accurate location and time information are critical to most of our applications. We use a commodity GPS unit with a USB interface for this purpose.

Most cars made after 1996 provide access to the internal computer through OBD-II interface. We use an OBD-to-serial adapter from ScanTool.net. This adapter provides a modem-like interface and can be automatically queried over a serial port.

In order to upload collected data and download software updates we use miniPCI WiFi card. The picture shows the WiFi card is plugged into the MiniPCI slot of the embedded computer.

Many of the applications mentioned earlier deploy additional sensors, for vibration, images, etc. The embedded computer in the car also provides Bluetooth connectivity (via a USB dongle) to any external Bluetooth-enabled devices (e.g., cell phone).

Currently, the following software packages have been released. Please consult their respective pages for packages and documentation.

• CafNet
• ICEDB

* A Measurement Study of Vehicular Internet Access Using Unplanned 802.11 Networks. Vladimir Bychkovsky, Bret Hull, Allen Miu, Hari Balakrishnan, and Samuel Madden, in Proc. ACM MOBICOM, 2006. Award paper. Abstract PDF

* CarTel: A Distributed Mobile Sensor Computing System. Bret Hull, Vladimir Bychkovsky, Kevin Chen, Michel Goraczko, Allen Miu, Eugene Shih, Yang Zhang, Hari Balakrishnan, and Samuel Madden, in Proc. ACM SenSys, 2006. Abstract PDF

* IceDB: Continuous Query Processing in an Intermittently Connected World. Yang Zhang, Bret Hull, Vladimir Bychkovsky, Hari Balakrishnan, and Samuel Madden. In Proc. ICDE 2007. Abstract PDF

* The CarTel Mobile Sensor Computing System. Demonstration at ACM SenSys 2006. Best demo award.

* CafNet: A Carry-and-Forward Delay-Tolerant Network. MEng Thesis, MIT EECS, Feb. 2007. Abstract with link to PDF

• Faculty PIs: Hari Balakrishnan, Sam Madden

• Current students & postdocs: Vladimir Bychkovsky, Jakob Eriksson, Lewis Girod, Bret Hull, Yang Zhang

• Alumni: Kevin Chen (MEng), Hongyi Hu (MEng), Michel Goraczko (staff), Allen Miu, Eugene Shih

The CarTel project is funded by the National Science Foundation under grants CNS-0205445 and CNS-0520032, and in part (the CafNet stack and the WiFi measurement study) by the T-Party Project, a joint research program between MIT and Quanta Computer Inc., Taiwan.

To learn more, contact Hari Balakrishnan, Sam Madden, and/or the CarTel team (send a note to cartel at the domain nms.csail.mit.edu).