Connecting sensors to ROADNet

The purpose of this document is to give you a basic introduction to the terms, design and components that may be used to integrate your sensor network into the ROADNet real-time data distribution system (see VORB). This document contains detailed design descriptions and attempts identify important issues that must be addressed for a successful integration. Feedback should be sent to the ROADNet team so that we may improve upon this page.

What is the ROADNet real-time data distribution and analysis system?
The ROADNet real-time data distribution system is designed to operate on top of the Internet. It is a network of Internet connected computers that work together to bring data from sensors to end users in real-time, while providing medium duration queuing capabilities to deal with network outages. This real-time data distribution network (the VORB system) is being designed to automatically reconfigure itself when a sub-system outage occurs or when an additional data request arrives. The real-time system will also provide analysis tools that will allow the user to conduct analysis on the sensor data while it is still in the system. For more information on the real-time data distribution and analysis system visit: http://roadnet.ucsd.edu/vorb1201.html.

An earlier version of this system has been in use for many years gathering seismic data for Frank Vernon, a researcher at the Institute of Geophysics and Planetary Physics at Scripps Institution of Oceanography. A November 2001 Southern California earthquake shows the speed of this system; in this instance researchers were warned of the occurrence of the quake four seconds before the shock waves arrived. As might be expected, the added latency of this system is minimal and we will strive to keep it at a minimum as we add improvements.

This system will allow multiple researchers to benefit from each other's sensor data (should they choose to make it available) in order to effectively increase the size of their sensor network. For example, a person with meteorological stations in downtown Seattle could combine their measurements with someone who has sensors in Tacoma. Researchers could potentially combine data from sensors in different disciplines as well. For example, a climate researcher might find it useful to compare his snow pack sensor data with ocean temperature sensor data. Or a graduate student searching for a thesis project could combine two disparate data sets and discover interesting correlations. Building the VORB system on top of the Internet abstracts the underlying architecture. In other words, the researchers doing the data analysis do not need to understand how the data is transported to them or how the sensors are connected.

However, we must first understand how to connect sensors to this system. The final step in this process is connecting to an ORB gateway. This gateway is capable of talking to the sensors while at the same time talking to the VORB world.  It is effectively the DMZ between the sensors and the VORB world.

Physical Connections

The above diagram shows a basic connectivity diagram for a sensor, which would be connected to the VORB system. The far left is a "sensor unit," which will be described in greater detail below. This sensor unit must be converted to speak IP so that it can be connected to an Internet connection. This assumes you have already figured out how to achieve IP connectivity at your sensor, either wirelessly or wired. After you are speaking IP, the world is the limit. The next step is to install the ORB gateway.  It does not need to be located at any particular location, but needs Internet connectivity. The ORB gateway is responsible for knowing how to talk to the sensor, and for sending this sensor data to the real-time data distribution system. It is also the first point in this network where data can be queued in the event of a network outage. As such it makes sense to put this as close to the "sensor unit" as possible. However, this may not always be possible, or you may want to connect multiple sensors to one ORB gateway.

After the data passes through the ORB Gateway, it is injected back into the Internet via a network of VORB systems that relay the data to various clients and do intermediate processing. Additionally, if you want to archive your data you will need to place your own archiver at some Internet connected location. It will connect to the VORB network as if it were a client so that it can gather the data from the sensors in real-time. In other words the VORB system will not archive your data, but instead will give you the newest data as soon as possible.  However, in the event of an impassable outage it will queue the data for as long as it has space (some systems can store data for days, weeks or years, it depends on how they are designed).

The above graphic is a logical network diagram that shows how the data flows through the system. The first cloud would be the local IP backbone. We would consider this the last mile network in that it would entail the network connections that connect your sensors, aggregate their connections at relay sites, and interconnect those relay sites to a central Internet connection. In a simplified design this final aggregation point is where you would place the ORB gateway, as shown. After the data passes through the ORB gateway it enters another cloud. This is a dynamic route through any number of VORB systems that relay the data. Each of these VORB systems must be connected to the same IP network (preferably the Internet). They communicate with each other and the data flows through them in some path determined by the VORB system. Researchers will connect to this VORB system to query their data, and you can also connect archivers to the VORB system. This archiver will collect all of your data from the network and save it on disk. We are planning for it to be able to inject that data back into the VORB network should there be a need to look at older data.

Sensor Configurations
In this next section I will discuss the "sensor unit" which is the first device in the above diagram. There are a number of interesting trade offs that make this unit highly variable. It also has a direct effect on how you design the rest of your system.

There are two basic designs to the sensor unit. It involves a simple sensor that is directly connected to the network (method A). The other involves a data logger, which is primarily used to store data samples should the sensor connectivity to the outside world be lost.

There is a trade off involved here based on your cost/benefit. Is it of greater benefit to have every sample of data or to deploy more and possibly redundant sensors? To understand this you need to understand the cost of method A vs. method B per sensor. An example is given below:

As you can see in the above example, there is a large price difference between the two sensor unit designs. If you have $25k to spend on sensors, that would give you 45 method A sensors or 16 method B sensors.

The next step is to determine what your expected reliability is in the network components between your sensors and your ORB gateway. It would be nice to do this empirically, as that would give you a clear answer; however most of the time this needs to be determined subjectively. What are the network components? Is it just a 5 foot serial cable (those are pretty reliable), a short wireless network with a great Signal to Noise Ratio (SNR), a long distance link? If your link is not very reliable or if you must have every sample then you might want to think about a data logger.

From another perspective, in the above example you can place approximately 2.81 method A sensors for each method B sensor. If you are smart in your placement, maybe those additional sensors could become more useful and at the same time provide redundancy for individual sensor outages. These are the complex issues you must address with each deployment plan, and are highly dependent on hardware and personnel costs.

Some Solutions
At this point in time we are unable to give you definitive advice on what equipment is right for your particular project, but we can give you some examples of gear we have worked with that has given us reasonable results. The suitability of this gear to your applications is not guaranteed. Additionally, we appreciate feedback and alternatives to these solutions, as many solutions are available.

The above table shows some devices that are available. There are others. The Wavelan/EC-S is useful for connecting RS-232 based sensors to an existing 802.11b wireless infrastructure, or an existing wired infrastructure. However, this consumes quite a bit of power. This is a good solution for integrating into a wireless environment, but requires that the existing environment have an accessible AP.

The next device is a simple data sampler for reading the value of an analog signal. It is only capable of 8-bits, but it is quite inexpensive and gives you an idea of what capabilities exist in off the shelf hardware. You could connect this device to a Wavelan/EC-S and simply connect your analog sensor. Then from your office or the ORB gateway you could query the device for its current value.

The Freewave units are serial radios that provide a digital carrier detect signal to denote a working link. These are used in a lot of sensor networks but do not speak IP. As such you will need to convert them to IP further down the road.

The final device is a CerfCube, which is an embedded computer of approximately 3" square in size. It has 3 RS-232 ports, an Ethernet port, and a CF flash slot for flash memory or a wireless card. It consumes only a little power for its capabilities. We are working on making this into an ORB gateway, but at the time of this writing we are not yet certain that we will be able to make it work.

Next Steps

• Identify sensor and sensor interface
• Identify sensor interface connectivity solutions and IP connectivity sources
• Identify power requirements
• Plan locations of ORB gateways and data archives
  
• Ways to reduce size and cost

Many people have strict requirements and as such they must tweak their systems to meet certain needs while sacrificing others. For example, some users insist that their device only consume 1 watt of power, but are willing to give up the ability to query the sensor in real-time. This can be accomplished by power cycling the device; i.e., by only turning it on for 60 seconds every hour or thereabouts. This reduces power consumption approximately 1/60th. However, there will be additional power drain for the device, which must control the power cycling, and additional costs to develop that capability into your system. Additionally, when the connectivity is not constant it is nice to have a logic line on the radio that can tell you when a connection has been established. This is not available on the wavelan/EC-S (although other solutions are available). Alternatively, it is available on Freewave and related radios. However, those only act as serial radios and do not speak IP, but they do provide a point to multipoint architecture, and as such would be a solution for some situations.

This document was created by: Todd Hansen (ROADNet Systems Coordinator) with the assistance of the ROADNet team. 2/23/02