Device Squad

Sybase RFID Anywhere update invites developers to build more intelligent environments

The only real problem I have with Sybase iAnywheres December 4 announcement of its RFID Anywhere 3.0 is that the products name is much narrower than its true scope. In a conversation that I had last week with Martyn Mallick, the companys director of RFID and Mobile Solutions, I suggested that they might do well to tell people that "RFID" really stands for "Robust Framework for Intelligent Devices"—with those little radio-frequency ID tags as a special case and an overloading of that acronym.

Philosophically, you can tell that RFID Anywhere comes from the same company as the SQL Anywhere suite of database and connectivity engines and tools that I reviewed in eWEEK in September. Were looking at technology thats designed to be embedded close to where work takes place in the real world, not to sit in a glass house with a team of attendants to burp it and wipe its nose. Whats most important to realize about RFID Anywhere is that its not just an RFID sensor interface layer: Its also a .Net-compatible programming environment that lets a developer put business logic right into the cerebellum, so to speak, of the enterprise IT brain.

For example, Mallick suggested, a warehouse full of lettuce might have environmental sensors tracking temperatures in different areas, an RFID tag on each pallet of cases of lettuce awaiting sale, and an RFID reader on every forklift truck that moves goods in and out of storage—with location sensors in the building that capture the location where any pallet is picked up or put down. If a warehouse zone gets warmer than normal due to a failure of its cooling equipment, the pallets that are known to have been stored in that zone can be flagged by the system for local sale—even if that means accepting a lower price—rather than long-distance shipment, thereby getting the goods to a customer before they spoil.

The wide variety of devices supported by RFID Anywhere encourages developers to think in terms of a wide variety of sensors as leaves on their logic trees, instead of letting any one sensor vendors interface tools and libraries dominate a design. Its all part of the kind of thinking thats both useful and necessary as enterprises come to rely on tomorrows federated architectures of diverse automated systems, perhaps with multiple supply-chain partners as their owners, rather than yesterdays monolithic and often surprisingly labor-intensive approaches to IT.

Tell me what your sensors are detecting at