Section 3
Design
Each sensor network has its set of requirements. Some might demand a few sensors that wait for a single master to poll them, for ease of design and lack of network collisions. Others may require that sensors only transmit when a significant event has occurred, in order to minimize network traffic, storage space, and power requirements. Another network may require that its sensors report to a single collator, which then makes the readings available to any monitor to request them, in a publish-subscribe paradigm. There are many more examples. The Snap! toolkit is designed to allow system designers to configure the network to whatever archetype is required. Furthermore, the toolkit does not require that its nodes be redesigned for such changes. In fact, the nodes may be changed even while operating, allowing the designer to change his configuration in response to changing power availability or network reliability.
Similarly, the Snap! toolkit is intended to be independent of a particular microprocessor or controller. Each node is only required to implement the behaviors of a Snap! set forth in the Snap! specification. This is important because the processing required on different nodes may vary from network to network. For instance, a temperature node may require only a small microcontroller to do analog to digital conversion, turn the value into a meaningful number, and support the other Snap! functions. Another node may consist of a high-powered processor and plentiful memory to convert the bitmap output of an attached CCD camera into the JPEG image file format. Both nodes may be a part of the same Snap! network.
In addition to sensors, the Snap! toolkit is also designed to allow actuators and other output devices to be present on the network. An actuator is any kind of output device. It may be something that generates motion or that displays or transmits information. A Snap! network may include light-emitting diodes (LEDs), liquid-crystal displays (LCDs), and electric motors. Other examples of output devices are long-distance transmitters, such as cellular phone modems or short-wave radios, and flash memory cards for persistent storage of data.
The Snap! toolkit is independent of the actual network connectivity. The toolkit places some basic requirements that the network must have, but the choice of the actual protocols and media connecting the nodes is not specified. Of course, the quality of the network connecting the nodes will have an impact on the overall performance of a sensor network built with Snap!: a designer should not expect to transmit several images per second over a network with a bandwidth of 2.4 kilobaud!
3.1 Functional description
The Snap! toolkit takes advantage of the similarities among sensor networks to make prototyping them fast and easy. Simultaneously, it acknowledges their inherent differences, remaining flexible in order to accommodate the needs of different systems. Snap! specifies the behavior of the nodes on a sensor network and describes the logical structure of each node and of the network as a whole. The Snap! design places emphasis on the reusability of hardware and software, rather than on the creation of an optimal solution for a given application.3.2 Design considerations
In order to satisfy the functional goals of the Snap! toolkit, with the above factors in mind, the following considerations were taken into account during its design.3.2.1 SCALEABILITY
A sensor network should be scaleable. A minimal sensor network may contain as few as two nodes: a sensor and an actuator or recording device. A simple heart rate sensor with a wrist-mounted display is one such example. At the opposite end of the spectrum, a complete body-monitoring network may consist of fifty or one hundred sensors. These could include seven different electrodes for an electrocardiogram, various skin temperature monitors, a heart rate sensor, and blood pressure detector. Additionally, on-body sensors for detecting local environmental conditions, such as temperature, global coordinates, atmospheric pressure, and humidity may be part of the system. The Snap! toolkit should be able to accommodate both sensor network designs. It is not necessary, though, that the toolkit support thousands of sensors. While such large networks are conceivable, Snap! does not address these extraordinary cases. The design can avoid unneeded complexity and complication by keeping the number of sensors allowed to a reasonable number.3.2.2 EXTENSIBILITY
One of the most important features of the Snap! toolkit is its extensibility. The addition of new components to a system must not require that it be redesigned. New modules conforming to the Snap! specification must be compatible with existing modules. The network protocol must be capable of being dynamically extended. The Snap! toolkit cannot anticipate all sensors that currently exist and certainly not all modules that might ever become part of a network. The Snap! toolkit should not strictly specify hardware to be used, as it may become obsolete as more powerful components become available. Overall, the design should allow extensions without affecting components already painstakingly designed and debugged.3.2.3 LOW POWER
The Snap! toolkit design must acknowledge that many likely applications will have limited power supplies. One example is a camera placed in a remote location that responds to a certain trigger condition, such as obstruction of a light sensor to monitor rarely seen animal species. When triggered, it records environmental data along with an image. Remote environmental monitoring systems would be expected to run for months or years on a single power supply, and certainly without power lines. Snap! should not require that any piece of hardware constantly draw high currents for computation or communication.3.2.4 FAULT TOLERANT
The Snap! toolkit should allow the design of systems that are fault-tolerant. Each sensor network is vulnerable to different faults. However, the Snap! toolkit should not contain specifications that make it particularly likely to fail given common uses of sensor networks. Common sensor network failures include failure of a central control point, intermittent network connectivity, and the breakdown of a subset of nodes. When a system designer decides that a failure mode is unlikely, his network may permit it. For instance, a designer may be convinced that one node is particularly bulletproof and choose to have a central controller. However, Snap! must not impose a common failure mode on the system designer.3.2.5 PLUG-AND-PLAY
Similar to extensibility is a requirement that the Snap! tool kit provide facilities for a plug-and-play network. It should be possible for new modules to be added to an existing sensor network without reconfiguring the network. This type of auto-detection by the network and its nodes allows for further ease of expansion of capabilities. A sensor network that necessarily requires reconfiguration when adding or subtracting components inhibits the ability to quickly create prototypes.3.3 Snap! architecture
Most of the design emphasis in the Snap! architecture is placed on the nodes. Only a very lightweight specification is required of the network. All the nodes on a Snap! network should implement the Snap! specification, even if they are not all composed of identical hardware. The basic element of communication among the Snap! nodes is a Snap! packet. Understanding its elements first will make later explanations clearer.3.3.1 THE SNAP! PACKET
The Snap! packet contains several fields:
|
| FIGURE 5: Snap! packet format All Snap! packets contain a 2-byte destination address, a 2 byte-source address, 1 opcode byte, 2 bytes of length, and a variable-length payload. |
| Opcode | Description | Payload contents |
|---|---|---|
| Acknowledgment | Short packet for communicating status | One byte acknowledgment code |
| Report | Response to a request or spontaneously generated to communicate current state | Name of variable reported and value of the variable |
| Request | Request another node's variable values | Name of variable requested |
| Set | Changes or assigns a value to a variable on another node | Name of variable to set and new value of the variable |
| Find | Discovers nodes on the network that meet specified criteria | A query string to determine which nodes respond |
| User-defined | Included to allow expansion of networks containing nodes whose behavior cannot be encapsulated by the existing opcodes | Dependent on user specification |
Acknowledgment packets are generated in response to set, find, and some acknowledgment packets, as well as to request packets when the node cannot properly respond to the request. Acknowledgment packets may also be spontaneously generated by devices attempting to determine the composition of the network, those that are attempting to coordinate simultaneous measurement, during a node's bootstrapping, or according to one of its behaviors. Acknowledgment packets describe the node's operating state.
The intention is for the node to respond with FAILURE if the set packet is legal, but current circumstances prevent the node from acting on it. Such a response may cause the sender to resend the packet after a certain delay. An ERROR response indicates that the set packet is inherently flawed and the sending node may need to obtain more information about the destination node before trying again. A device for configuring a network will generate set packets, as ell as other nodes managing the network's behavior.
The variable names follow a hierarchical naming scheme, similar to that used in the Unix file system[citation] and the Java package structure.[citation] In a variable name, the most general classification comes first and a period (.) separates the hierarchical levels. For example, gps may be the general name referring to the entire set of global positioning system data, while gps.lat and gps.lon refer to latitude and longitude specifically. The hierarchy may be arbitrarily deep. Grouping variable names into a hierarchy allows nodes to request and report data in chunks, reducing network overhead. The hierarchy also allows for a logical organization that helps make data analysis and presentation more meaningful.
The datasheet variables are:
Behaviors can vary in functionality and scope depending on the underlying hardware. A very simple microcontroller may limit the behaviors to testing current values against thresholds to decide whether a report packet should be generated. A heart rate node may only report when the heart rate goes above 75% of the maximum value or below 75% of the average. This could reduce network traffic and possibly the power consumption of the node itself. Nodes with more processing power may be able to implement higher level languages such as Java or C.
High-level languages and powerful host processors allow the execution of mobile code or the habitation of software agents on the sensor network. These techniques may allow the system to detect very complicated phenomena. For instance, a process may move among the sensors on person, keeping track of the various sensor readings it encounters. It may discover that adrenaline in the blood stream, combined with elevated heart rate, blood pressure, respiration rate, and skin conductivity, indicates that the person is exhibiting the hallmark signs of a fight-or-flight response. This may cause the system to set off an audio alarm as well as transmit a warning over the long-range communications device. Such a behavior is possible even with threshold recording on a single, lower-powered processor. However, such an arrangement makes the system vulnerable to a single point-of-failure.
The behaviors are represented as variables on the nodes and can be set and read like any other variable. The language in which the behavior is written will determine what encoding scheme is used when performing these operations. For example, an interpreted language may use packets with ASCII contents, while a compiled implementation may set behaviors via packets containing bytecodes. The behaviors can be changed dynamically and nodes may have a default behavior to be executed if no other is set.
The behaviors variables are:
The variable hierarchy may be extended as data is passed along through the sensor network. A designer may cause a node that collates data to create a new data structure that groups various sensors or actuators together. For example, a designer may create a system that has temperature, barometric pressure, and humidity sensors on separate nodes. Another node queries these three as well as a GPS node. The collating device may decide to leave GPS in its own hierarchy, but create a new data type, called environ, that pools the environment readings. This aggregation of data allows the designer to create new abstractions that are more representative of the various network constituents.
3.3.3 VARIABLE DESCRIPTION
A node's variables characterize its static and dynamic behavior. Variable names and values are the only data that are communicated in packets. A node is required to implement a prescribed set of variable names. The required set allows network nodes to learn about the capabilities and variable parameters of other nodes. Each sensor and actuator node will additionally choose to implement another set of variables. This set will be customized according to the functionality of the individual nodes.3.3.4 REQUIRED VARIABLES
3.3.4.1 Datasheet information: ds
The datasheet contains information that is pertinent to all the transducers and actuators on a node or the node itself. IEEE 1451, as well as a general trend among manufacturers to include electronic data sheets on their products inspired the inclusion of the datasheet. Electronic datasheets facilitate plug-and-play and extensibility of the network by allowing nodes to dynamically determine characteristics of other nodes. The nodes do not need to be pre-programmed with information about other nodes before being connected.
3.3.4.2 Metadata: mt
The metadata variable contains information about the variables and the system software. This variable classification is not completely specified.
3.3.4.3 Behaviors: bhv
The behaviors of a node are what allow it to fit so flexibly into a variety of network configurations. Behaviors are small scripts or programs that run on the node. If no behaviors are specified, the node will simply respond to incoming packets, reacting according to the Snap! specification for each type of packet.
3.3.4.4 Measurements
Measurement variables refer to those variables added for a particular node. The examples temp, barom, and gps have already been given. In this discussion, measName refers to any particular measurement variable implemented on the node. If the value of a variable with more than one field is requested, the values for each of the active fields should be reported. Active fields are those that are specified in the format of the multi-field variable. If a variable doesn't make sense for a given transducer, the value is "N/A."
3.3.5 BOOTSTRAPPING
The Snap! design does not explicitly define a bootstrapping behavior; each network may vary. For example, in a Snap! network configured as a master-slave design, each non-master node may wait to be polled before sending data or making communication. For a network on which each node spontaneously generates packets, a node may wait a pre-defined time before sending its reporting format and capabilities. The network designer must decide the bootstrapping which makes the most sense given the particular configuration.
 |
| FIGURE 7: Snap! node A Snap! node contains two modules: the input/output module, which interfaces to transducers, and the network module, which implements the network stack needed to communicate with other nodes. |
To the input/output interface module, the network interface module presents a very simple interface. The network interface module receives packets from other nodes on the network in the implemented network protocol and translates them into the standard packet format. This standardized format is then passed to the input/output module. The network interface module also receives messages in a standard format from the input/output module and converts them into the format used on the implemented network for transmission to other nodes.
The network presented by the network interface module to the input/output module must allow any node on the network to address any other node. It must also provide a greater than zero probability of any single network communication succeeding.
Across instances of a specific hardware platform, many of the Snap! variables will be implemented in a very similar way. The writing of the majority of code for a particular architecture will only have to be done once. Other input/output modules using the same architecture can then take advantage of the library code. The means by which an input/output module reads its sensors or sets its actuators will be unique to each sensor and actuator array. Therefore, custom sensor and actuator code must be developed for each node. Additionally, the tables or functions that store the variable values must be updated from node to node.
The wide range of possible input/output modules gives the Snap! architecture its openness. As long as the input/output module reacts to the packets it receives from the network module as defined in the previous section on packets, it can successfully function as Snap! node. Of course, the way a Snap! module responds to report and set packets, as well as its behaviors and set of measurement variables, determines what role it plays in a network. Some example classes and cases of input/output modules follow.
| Input/output module class | Example |
|---|---|
| Sensor | GPS receiver | Heart rate monitor |
| Actuator | Audible buzzer |
| Water valve | |
| Display | Liquid crystal display touch panel |
| Personal digital assistant | |
| Logger | Hard disk drive |
| Flash memory device | |
| Gateway | Shortwave radio |
| Cellular modem |
An example of a monolithic sensor input/output module is one connecting to a GPS receiver. Although the measurement variable gps may comprise many fields (gps.lat, gps.lon, gps.alt, gps.spd, gps.time, possibly even more), there is only one serial port connection to the actual receiver. This is a useful input/output module that will be incorporated into many Snap! networks.
A module containing transducers for wind speed, barometric pressure, temperature, and humidity moves towards the other end of the composition spectrum. The designer may choose to group the readings of all the transducers under the measurement variable weather, comprising weather.temp, weather.barom, weather.windsp, and weather.humid. Despite the grouping, the node actually communicates with four different transducers and conceivably four different interfaces. The conversion between the raw values of the transducer measurement and the reported values involve different formulae. Despite the differences in the interface complexity between the nodes with single and multiple transducers, they both appear the same to other Snap! nodes.
The behavior of logger, gateway, and display modules may vary from that of a typical Snap! node. It may be enough for a system designer to configure the nodes to send report packets to a logger, without forcing the sensor nodes to query the logger as to the maximum value of its datastore measurement variable. On the other hand, a sensor network with extremely variable composition or with a particularly volatile network connection may have the nodes query the presence of gateway and logger nodes. It may be necessary to discover how much more data they can store or transmit. The exact input/output interface and the implementation and selection of measurement variables is at the discretion of the individual node designer. The designer should keep in mind that for maximum reuse he should make the interface as general as possible. There is a constant tradeoff, though, between reusability of the modules and speed and ease of their development.
Section 4 - A First Implementation
Send comments to the author
3.4 Summary
This section has explained the Snap! specification. It provided a functional description of the Snap! toolkit, elaborated the guidelines used in decision making during the design process, described the packet format and variable structure, depicted the separation of responsibility between the input/output module and the network module, and gave examples of different types of network modules and input/output modules. The next section will illustrate an implementation of the Snap! toolkit and a system built with it.