Section 2
Background
Learning from successes and failures in the Boston Marathon, the system was redesigned for the San Francisco Marathon later the same year. In addition to the sensor set used in Boston, the runners also carried cellular phones, adding the recording of real-time subjective data to the sensor readings. The PIA team also modified the MarathonMan system for use by the United States Army. The Army used the system, with more rugged packaging and without wireless communication, to monitor soldiers during field training exercises at Fort Bening.[citation]
2.1 A History of Personal Information Architecture sensor networks
The Personal Information Architecture group (PIA) began putting bodies online in 1997 as part of its Black Boxes project. The evolution of these systems provided impetus and experience for Snap!'s development.2.1.1 MARATHONMAN
PIA designed its first system, MarathonMan, for the 1997 Boston Marathon. It comprised a heart rate monitor, a Global Positioning System receiver (GPS), an accelerometer for measuring cadence, and a body core temperature monitor. A separate device with its own microcontroller collated the data from all the sensors. This device sent the data to a palmtop computer, which both recorded and sent them via cellular modem to the Internet. The data from the palmtop could be analyzed in the event that the Internet link disconnected any time during the event.[citation][www site]
|
| FIGURE 2: MarathonMan system PIA first developed MarathonMan to enable online body monitoring. The system featured a main collating board that knew how to interpret the signals of each sensor. The collator polled each constituent sensor, then sent the values to a palmtop computer that stored the data and transmitted them via cellular modem to the Internet. |
Climbers carried the GeoPak systems in their backpacks to monitor changing conditions as they ascended Mt. Everest. Each GeoPak consisted of a custom designed controller board attached to five sensors: a GPS receiver, a photoresistor for measuring light levels, a thermistor for measuring temperature, a humidity sensor, and a barometric pressure sensor. The controller board also flash memory on-board for persistent data logging, as well as a connection to short-wave radio for data transmission.[citation][www site]
 |
| FIGURE 3: GeoPak system GeoPak recorded environmental conditions on Mt. Everest in 1998. The GeoPak board integrated controller and memory. The controller knew the protocols of each sensor. It polled each sensor, stored the values on-board, and relayed them via shortwave radio to a remote monitoring station. |
 |
| FIGURE 4: BioPak system BioPak monitored physiological conditions of climbers on Mt. Everest in 1998. BioPak sensor boards knew how to communicate with the transducers to which they were attached. All the sensor boards communicated via a uniform protocol with the master controller. The master controller stored the data in off-board flash memory, and sent the data via shortwave radio to a remote monitoring station. |
Despite the commonalties between the systems, PIA essentially designed each system from scratch. Some of the changes were unavoidable. The marathon runners demanded that the systems be comfortable and lightweight. Otherwise, no useful data could be collected because the equipment would affect runners' performance. The Fort Bening systems used the same hardware and software as the San Francisco marathon, but repackaged it for the expected shocks of combat simulation. The delicacy with which the runners handled the systems could not be expected of the Marines. The systems used on Mount Everest had to be built to withstand the harsh mountain environment. The conditions required that the included components have greater ranges of operation. The GeoPaks had to operate for several days without a change of batteries. The climbers could then leave them in a remote location to monitor the weather without devoting precious time and energy to their maintenance.
On the other hand, the system redesign was extremely expensive in terms of time spent developing hardware and software. The architectures of the systems differed remarkably. The software interfacing with each of the sensors had to be modified to fit the particular system. For instance, the sensors used in the C2C project were sufficiently different that the extensible properties of the BioPak system could not be readily adapted for its needs. Thus, despite the fact that the systems differed only minimally in their function, each required a massive engineering effort to complete, with little reuse of code or hardware. This problem of reinventing the wheel as new system requirements arose motivated the creation of a sensor toolkit.
Descriptions of sensor networks vary along several axes. These include:
The purpose of each sensor network constrains or determines the choice made along these axes, as well as others. The Snap! design gives the system designer great leeway in all of the axes. A toolkit that is too limiting ceases to be useful. The technologies presented in this section either make specific choices along these axes that provided insight when designing Snap! or attempted to enable sensor network construction via different means than those Snap! uses.
The sanctioned 1451.2, "A Smart Transducer Interface for Sensors and Actuators,"[citation] describes the interface between a sensor module, which consists of a single transducer with one or more channels, and a device that controls the sensor module and is also attached to the sensor network. The standard is divided into two parts: the physical interface and the definition of a transducer electronic datasheet, or TEDS. The TEDS contains device identification and characterization data, as well as a means with which to specify the translation from the transducer's raw output to a meaningful representation.[citation][www site]
The 1451 standard set, if successful, will reduce the burden of the sensor network designer. No longer will he struggle with the outrageous number of protocols defined by each sensor manufacturer. With respect to the goals of the Snap! system, however, 1451 is overkill. The standard presents too many requirements to the system prototyper. For example, 1451.2 specifies the exact number of data lines and the timing diagrams for the signals on the lines to each transducer. The TEDS contains data fields that may only be useful in exceptional circumstances. The time it would take a node designer to implement the 1451.2 standard prevents it from being used to prototype networks quickly and easily.
Additionally, 1451 includes standards for interoperability within the nodes themselves. In order to allow the system designer maximum flexibility, Snap! describes the external behavior of nodes, and only minimally within nodes. The system designer determines the implementation details on the node level. The interoperability to be gained by incorporating the standard into Snap!, or simply building 1451-compliant networks is not a necessary design feature of Snap! However, Snap! includes some of 1451's end-to-end description, as discussed in section 3.
LonWorks and other industrial networks, such as CEBus and CAN bus, all have properties that allow for flexibility along several of the description axes. Often, however, any specific network contains a constraint that is undesirable in a toolkit that seeks to be human-scale and as flexible as Snap! endeavors to be. That is, each of the networks is an implementation of something that could be built using the Snap! toolkit. Each of the networks, though, represents a potential use for Snap! Thus, the Snap! design considered the various capabilities of each specific network. If Snap!'s design fundamentally prevented it accomplishing what an existing implementation could, the design had to be reassessed.
Both of these groups are conducting research that pushes the bounds of the sensor community. Undoubtedly, they must answer questions similar to those faced by Snap! during its development. However, the significant differences between the goals of each system leave a wide chasm between the groups when answering the questions. While it is important to be aware of developments in these groups, as well as the dozens of other research groups conducting investigations into all areas of sensor research, the differing goals between non-overlapping systems must be kept in mind both during development and evaluation of a given system.
On the other hand, the Snap! system is designed to make the creation of new sensors easy, in addition to permitting plug-and-play of existing sensors. The Snap! system is designed to work with an extremely wide array of sensors, some which may not even exist yet. Snap! also allows for the dynamic reconfiguration of its nodes' behaviors. The FitSense system functions in only one mode and its ease of extensibility cannot be determined. Finally, the Snap! system is completely open, whereas FitSense is a corporation and motivated to retain its proprietary technology. The FitSense system presents a good solution for sensor networks with needs satisfied by the nodes that FitSense offers and the predetermined network configuration.
Send comments to the author
2.2 Need for Snap!
The systems described above all encompassed goals and component sets common to many sensor networks.
2.3 Related work
The domain of inquiry surrounding sensor networks is absurdly large. Research into sensor networks includes those on satellites orbiting the earth photographing the habitats of manatees, spread across the continent recording the current weather conditions, dispersed as dust detecting tanks crossing a battlefield, and on a single person running a marathon. There are dozens of sensor protocols and means for creating sensor networks.
2.3.1 IEEE 1451
The Institute of Electrical and Electronics Engineers (IEEE) has been developing a set of standards for creating digital networks of smart sensors. This set of standards, labeled 1451, comprises four parts. Only one has been officially approved, with the other three proceeding slowly. The four parts progress hierarchically from the interface among several different analog and digital transducers (1451.4), through the collation of the signals (1451.3), to the final digital presentation of the sensor data (1451.2), and concluding with the communication between the devices on the sensor network (1451.1).[citation][www site]2.3.2 LONWORKS AND OTHER INDUSTRIAL NETWORKS
Echelon Corporation [citation][www site] markets a sensor networking solution based on its NeuoronChip and LonTalk protocol. The network possesses several desirable qualities. The nodes themselves are dynamically re-configurable, the network protocol is media-independent, and an entire suite of external applications exists to monitor the network remotely. Example applications of the network include controlling aircraft or automating buildings and homes.2.3.3 SMART DUST AND
A research group at the University of California-Berkeley is producing Smart Dust. [citation][www site] Its goal is to encapsulate a transducer (often a MEMS device), input/output and control circuitry, and wireless, optical communication in a single unit smaller than 1.5 mm3. The Smart Dust project demonstrates what can be done when sensors are pushed to their physical size limits. The group envisions the dust being spread over an area via micro-air vehicles or being attached to a computer user's fingertips as a new interface device.
A group at MIT is also developing technologies for small, short-range, wireless sensor networks. The 
AMPSAmps project focuses expressly on the problems associated with powering the nodes and communicating within such a new network paradigm.[citation][www site]2.3.4 FITSENSE
FitSense [citation][www site] has developed the BodyLAN, a wireless digital link connecting sensors that are worn on the body. Their current array of sensors, some of which were used in the MarathonMan project, includes a body core temperature monitor, devices to measure environmental data, speedometers and odometers, motion-sensors, blood oxygen content sensors, energy expenditure estimators, and other vital sign monitors. The system is plug-and-play, so new sensors can be added to the network without reconfiguration of the other devices. The FitSense system overlaps with some of the goals of the Snap! project. Of existing sensor networks, the FitSense system most closely matches the physical size that the Snap! system addresses.2.4 Summary
This section reviewed the several projects within the Personal Information Architecture group that have involved capturing and recording data from bodies and other small areas. It highlighted specific characteristics of the architectures of each of the projects. Finally, the section concluded with a survey of related research into sensor networks. The next section will explain fully the goals of the Snap! system, its design constraints, and the design chosen to meet the goals and requirements.