wonilee

Wi-Fi chip maker GainSpan Corp. and Wi-Fi positioningservice provider Ekahau Inc. have embarked on a strategic partnership,integrating Ekahau's technology with GainSpan's embedded software on its GS1010ultra low power system-on-a-chip (SoC).

This will allow GS1010-based Wi-Fi sensor nodes and locationtags to work with the Ekahau Positioning Engine (EPE), according to the twocompanies. As a part of the agreement, Ekahau will license the EPE and EkahauVision application to GainSpan customers; this will enable them to addlocation-awareness to their applications.

"The Ekahau Real Time Location System (RTLS) istargeted at providing location awareness in environments where technologiessuch as GPS do not perform adequately. Unfortunately in the asset and peopletagging industry these environments are all too common," said VijayParmar, GainSpan president and CEO. "Ekahau RTLS technology and GainSpan'slow power Wi-Fi SoC provide a reliable mechanism for people and asset trackingeven in these environments."

Pervasive computers can solve some very big problems. Attached to railcars, pervasive computers communicate directly with each other to determine their orientation according to their contents, manifests, and destinations ( Figure 1 ). Attached to power transmission structures, they ensure that our critical infrastructure is always available and remains safe and secure. Pervasive computers are useful in a wide range of markets, such as agriculture, health care, logistics and asset management, energy conservation, and manufacturing.

Figure 1. The rail industry relies on paper manifests and manual labor to verify the assembly and contents of railcars. Pervasive computers attached to each railcar can automate this process, saving a tremendous amount of time and improving the flow of goods in supply chains

To achieve this vision of pervasive computing, we need a new approach to its software, infrastructure, and applications. Conventional approaches attach sensors to a wireless transceiver (called a "node") and then process the millions of real-world data points at a central server, often located long distances away from the phenomenon of interest, a function we'll call "sense and send." This approach is central to the wireless sensor networks (or WSNs) industry. In this article, we describe the inherent problems with sense and send and how businesses can move beyond this paradigm.

Sense and Send Applied
Among the most obvious sense and send applications are those that deal directly with wire replacement. Foremost among these is monitoring the condition of the environment—its moisture, humidity, temperature, and chemical composition—for agriculture, seismology, pollution monitoring, and other fields. Nodes gather data locally and forward them to a server for analysis. In essence, monitoring environmental conditions entails robust data logging with a simplified, wireless information retrieval system.

High-latency, low-frequency condition monitoring is sense and send at its most basic, although other monitoring can place stringent demands on the system. Condition-based maintenance (CBM), for instance, involves instrumenting engines and similar heavy machinery or structures to monitor their vibration signatures. When the signatures fall out of specification, technicians can be dispatched to address potential issues before they become problems. When large numbers of nodes are collecting large amounts of data, the wireless connections become saturated. The applications also consume significant amounts of power because they are constantly sensing and sending with little processing or data aggregation taking place at the local node level.

Pervasive applications rarely end once data is captured; further action is often required. An application may need to swivel a camera, close a solenoid, or sound an alarm. Yet in sense and send, the node itself can't make the decision to actuate; it can only forward the relevant data to a server that must process the information to make a decision. When servers are numerous network hops away, latency prevents actuation in real time.

The situation becomes even more precarious when applications require the nodes to be mobile. Nodes may be attached to cargo containers, pallets, crates, or people moving into and out of an environment, e.g., firefighters in a building or railcars moving in and out of railyards. These mobile nodes are not connected to the same server at all times—in fact they may not be within reach of a server at all. However, they are still required to perform their functions, such as halting a railcar that is dangerously close to derailing. Pervasive applications such as this one require logic on the node.

A significant set of application classes have requirements that go beyond sense and send. Some examples include:

• Responding to events or state locally to allow pervasive applications to execute autonomously, thereby taking context-aware actions determined by business rules. Furthermore, applications that require low-latency actions can be executed by the nodes in real time.

• Collaboration between nodes enables new functionality, such as voting, weighting, and summarization. Nodes can determine their neighbors and work with them to determine the orientation of a railcar, track a firefighter in a building, or collectively analyze heat, motion, and sound signatures to classify that a human is present.

• Local filtering of data, data analysis and classification, and removal of false positives to ensure that pervasive applications only use communication and power resources as required, reducing costly battery replacement maintenance operations and removing reliance on potential single points of failure (a network gateway or back-end server).

A New Approach
We need a different paradigm that provides a new level of flexibility and programmability. Since data processing, analysis, and internode collaboration are the primary functions required to address pervasive application needs, the focus needs to be on the computer rather than the sensor or network interface. Rather than making RFIDs smarter, approach the problem from the other side by making computers smaller. To illustrate this approach, let's look at the components of a pervasive computer and compare pervasive computers to WSNs and RFID systems ( Figure 2 ).

Figure 2. A visual representation of the capabilities of various real-world technologies. Pervasive computers solve a wide range of large real-world problems not addressed by previous approaches

A pervasive computer consists of the typical components you'd find in the computer sitting on your desk—a central processing unit (CPU), input and output devices, and a communications interface. The primary difference is that pervasive computers are small (about the size of a quarter), run on batteries, communicate wirelessly, and have very different input and output devices (such as sensors and actuators instead of keyboards and mice). Pervasive computers monitor and control the physical world through the use of sensors and actuators.

Remove the CPU from a pervasive computer and the system is no longer programmable. It cannot process, filter, or analyze data. It cannot make decisions, coordinate with other pervasive computers, or autonomously control the environment. These systems, consisting of peripherals (sensors) connected to a wireless link or network, are called wireless sensor networks. Similarly, remove the networking component from a WSN system and the system can only communicate with a master within range in a point-to-point manner. These are called active RFID systems. Finally, remove the power source and you get a passive RFID system.

Challenges
To satisfy the demands of these new application classes, the developer can either focus on low-level details or sacrifice application flexibility. In the first case, building a system from the ground up, the developer has to worry about radio frequencies, frequency hopping, latency, power tradeoffs, interference, distance, network routing strategies, security, and countless other physical and link-layer characteristics. If the developer manages to get a handle on these issues, he or she is then faced with programming nodes in a low-level language such as embedded C.

All software applications require four main components—the ability to develop an application, deploy the application in a product, integrate the product with existing infrastructure, and manage the product remotely. Although C is efficient, it lacks abstraction support and is poorly suited for applications distributed among millions of computers. Moreover, lifecycle support does not exist for programs running on the small computers themselves. Tools such as debuggers and simulators are missing or incomplete, as are other postdevelopment tools used for deploying and managing the networks. Updating software on WSN nodes can require an update of the entire firmware on the node to make a single parameter change.

Faced with this, WSN vendors have resorted to the simplified sense and send approach, placing conditions on what can and cannot be accomplished. Moreover, customization is limited to basic configuration changes. Parameters can be tweaked, but not exceeded. Innovators in organizations large and small are prevented from turning their visions into reality by both approaches—low-level full-system design and sense and send products.

Solution
We must move beyond the "dumb" devices of wireless sensor networks and RFID to value-rich applications with pervasive computers. By treating devices as computers, developers can build their ideas into solutions. They can leverage tools, paradigms, and interfaces made familiar from their experience with laptops and servers. Low-level details of embedded computers are abstracted by standard APIs while retaining flexibility.

Figure 3. The Sentilla software suite addresses the full software life cycle of an application, from development to deployment to integration to management (Click image for larger version)

The software platform enables the full application life cycle of development, deployment, integration, and management. Sentilla developers use Java technology to build applications and embed business rules into pervasive computers using familiar Java software tools, APIs, and interfaces. For the first time, Java technology on low-cost, low-power hardware (such as wireless microcontrollers used in sense and send systems) turns billions of microcontrollers into fully functional computers without requiring new, or more expensive hardware.

Beyond development, the pervasive computers—with their DA, processing, and autonomous response—are miniature data centers providing services to enterprises through service-oriented architecture (SOA) interfaces. Sentilla's approach doesn't require IT managers to learn new management tools and dashboards; the pervasive computers are remotely managed—displayed and controlled as computers—by tools such as OpenView and Tivoli. Using these familiar interfaces and computer tools, such as Java and SOA, pervasive applications can be developed in days, rather than months.

The concept of wireless sensor networking originally burst onto the scene with an article in 1999 about "smart dust"—computers that can be sprayed on the wall, deployed anywhere throughout the environment, and collaborate to solve big problems. The industry has strayed from the concept of smart dust, reduced to sense and send. The potential for pervasive computers remains; all that is required is for the six million Java developers to be given familiar tools to build their vision. Sentilla's software accomplishes our new vision of pervasive computing, making innovative, killer applications possible—what idea do you want to build?