We have developed a framework for high-level specification of sensor network applications and automatic generation of deployable code. The main elements of the framework are:

• Application specification: In collaboration with other researchers at K-State, we have created a specification style in Cadena to specify programs in the nesC component model. The framework allows global scenarios wherein each component is assigned a location (node id) on which it is to be deployed. Since the actual number of sensors/actuators may be unknown at design time, we also allow logical sensor and actuator components in the design which represent a set of lower-level components.

• Obtaining the Application Topology Graph: Tools have been developed to derive the Application Topology Graph from an application model in Cadena. Several other important nodes and edge attributes such as location, sampling rate, and port type are derived from the model.

• Distributed algorithms and middleware library: Since the application is specified as a global scenario, distributed algorithms and middleware will be needed to implement it on a target platform. We have implemented event notification, RPC, shortest path and breadth first search algorithms on the TeAMS test-bed.

• Derivation of deployable code: We have developed synthesis tools which analyze the ATG and automatically integrated into the code needed to implement the application. These tools also use the ATG and the Network Graph in analysis algorithms to optimize the deployed code.

We have developed an application which detects the path information of object moving in the sensor field by capturing the order of events occurs in the network.

• This application builds a logical topology called DAG (Directed acyclic graph) between the motes in the network which is similar to the tree topology where a child can have multiple parents which are in communication range and a level closer to the root.

• Using a DAG, motes can communicate efficiently to order the events occurring in the sensor field. The root of the DAG is the base station which receives all the events occurred in the network and orders them based on the information it has from previous events received.

• Every event occurring in the network is assigned a time stamp and is identified by a tuple (mote_id, timestamp) which describes that the mote with identity id has detected the object with the timestamp, and ordering all such events based on the timestamps we get the path information.

This project utilizes Cerner's Enterprise Tracking System (ETS) and an application developed by us which monitors a person's movements.

• The person carries a badge which can communicate with an ultrasound receiver. Cerner’s ETS exploits these devices to locate the person.

• The person is equipped with some accelerometers and a PDA. The PDA continuously receives accelerometer values and determines the current posture of the person. The PDA then sends this value to a nurse station. Apart from posture, temperature, light and/or humidity values can also be sent.

We have implemented an event service using a model similar to the OMG's CORBA model for sensor networks. This implementation has been tested on TeAMS. Event service interface implementations, which reside on the motes, are written in nesC. The data routing part, which is done through Stargate Netbridges, is written in the C language.

A typical hardware setup using 3 boards of TeAMS looks like

Where SN stands for Stargate Netbridge, BS stands for base station and PC is computer where the user visualizes the data. In the diagram above, SN1 is parent and SN2 and SN3 are children of SN1. The overall software architecture looks like

Deluge is a protocol used for remote re-programming of nodes in a wireless sensor networks by injecting messages into a network of motes without having the motes directly connected to the PC. The protocol is very useful but is restricted to homogeneous networks wherein all nodes must be programmed with the same code. This project is an attempt to modify the existing protocol to work for heterogeneous networks where different motes function differently and have to be programmed differently. The project was developed using Java and nesC. The protocol was tested on a network of micaZ and on TeAMS. The concept is shown in the following figure:

• Sensing Layer: This layer is implemented by a set of sensing motes deployed along each lane. Each mote is capable of sensing the vehicles passing above it using a proximity sensor. This enables each mote to determine whether or not the segment of the lane immediately above is occupied or not. The Sensing layer provides a query interface with operations to obtain information about the traffic. Currently, the supported operation include an operation to determine occupancy of lane segments up to k hops away, where k is a parameter to the operation.

• Regulation Layer: This layer provides an interface with operations to control the movement of the robot and to obtain its current speed. The implemented operations include commands to turn the robot and to increase or decrease its speed.

• Control Layer: Since the application is specified as a global scenario, distributed algorithms and middleware will be needed to implement it on a target platform. We have implemented event notification, RPC, shortest path and breadth first search algorithms on the TeAMS test-bed.