- Overview
The sensor network filesystem project is a method to enable standardized end-to-end (from user to sensor nodes) communication and control over a sensor network. In order to do this, we export a POSIX-style filesystem interface to sensor networks that enable users to view and update data, organize groups of sensors, and retask sensor nodes. In SNFS, sensor nodes that implement the SNFS protocols are able to appear as simple directories that export data as files. Users are able to create new directories
Currently, many sensor network applications use custom method(s) and interfaces to interact with users. Users must learn how to use per-application interfaces for common management tasks. Also it is often difficult to diagnose and debug a sensor network after deployment without further retasking the network. Such retasking may entail reprogramming the interface, networking protocol, and sensor node application.
- Scenarios
We envision three primary uses for the Sensor Network Filesystem.
- Management and Tasking
Current methods of tasking and management are application specific. An interface designed for one particular sensor network application may not work with other applications. This may be true even if two applications are similar due to differences in the networking protocols used to communicate with the sensor networks. By exposing a well understood filesystem interface, management software can be constructed to use this interface. A single management application could serve multiple sensor networks and provide powerful methods to task a sensor network and probe the status of the network.
- Communication Between Networks
Although current sensor network deployments consist of a single physical network, future deployments may consist of multiple sensor networks that need to communicate with each other. For example, one sensor network may be located in Oklahoma, another in southern Kansas, and finally one in northern Texas. In the case that one of these networks detects a tornado, it would be desirable to read data from all the sensor networks and adjust the behavior of one or more of these networks.
By running an application on the end host, data from one network can be communicated with other networks via simple filesystem commands. For example, a user would modify a file within a sensor directory that affects the sampling rate of the application.
- Debugging and Prototyping
Sensor network applications that implement the SNFS protocols will expose data stored on the sensor node as a regular file. Sensor devices are also exposed as files. This will allow users to investigate the current data contents of different sensor nodes, and if necessary, alter the data contained in a particular file. The user will also have the ability to read and write data to sensors and actuators. This will the user to debug currently running programs and to create new prototype scripts that use the sensor network.
- Technical Details
The SNFS consists of three major components:
- The SNFS modules running on the sensor nodes
- The FUSE server implementing the SNFS semantics
- The end-host that mounts the in dependant FUSE servers
These components are organized according to the figure. Each sensor node that participates in the SNFS must implement a set of protocols and datastructures. We currently provide a set of TinyOS modules to implement these protocols and datastructures. Each physically contiguous sensor network is controlled and tasked by a single FUSE server. This FUSE server is responsible for translating filesystem commands into a set of messages that are consumed by the sensor network. Besides being able to communicate with the sensor network, we assume the FUSE server is also capable of connecting to the internet. The FUSE server exports an NFS server so that end-user machines can remotely mount and issue commands to the sensor network.
- Filesystem Semantics
| FUSE Command | Sensor Network Operation |
|---|---|
| mkdir directory | Create group called directory |
| cp/mv file_name PATH | Move Registry item file_name to group/sensor identified by PATH |
| cp/mv sensor_name PATH | Relocate node sensor_name to group identified by PATH |
| cp/mv object_file PATH | Task the group/sensor, identified by PATH, with the object_file program |
| cat file_name | Reads Registry item file_name |
| echo string file_name | Create/update Registry item file_name with content string |
| cat sensor_device | Reads data value from sensor_device hardware |
| echo string sensor_device | Issue a command, string to sensor_device hardware |
- Current Status
- FUSE Example works with simulated backend
- Basic File Registry done
- Basic Grouping mechanism done
- Started on Sensor Registry (LED working)
- People
- Patrick Widener
- Jean-Charles Tournier
- James Horey
