OBJECTSTORE
Handling RFID data accurately and at speed
You could water your lawn pretty quickly if you could use the fire hydrant
on your street. But if you hooked up your garden hose directly to the hydrant,
you’d wind up with a hose blown apart, a big pool of water and a very
angry fire chief. If you deploy an RFID system by directly hooking RFID
readers to your backend systems, the results will be similarly disastrous.
What’s needed is the right architecture not only to maintain accuracy
and authenticity, but to make meaning of the vast volumes of data.
RFID readers will deliver a gush of data. Our estimates are that pallet-,
case- and item-level tracking, combined with data generated by RFID readers
as items move within the enterprise, will increase the volume of data by
100 to 1,000 times today’s levels.
Effective RFID implementations must borrow from the architectural principles
developed for financial trading systems, process control and large-scale
network management. Like RFID systems, these systems process terabytes of
data, correct errors in real time, correlate events, detect patterns, re-organise
and cleanse data and recover from faults – all in real time. RFID
architectures should embrace three central principles of these systems.
1. Develop an operational data management architecture
An operational data management architecture is a software system that captures
events at the “edge” of the enterprise, where operational activity
occurs, rather than in the centre, where business-oriented transaction processing
occurs. These architectures act as a cache for transactional, enterprise
systems, and then communicate via middleware once actionable information
is identified.
By digesting your RFID event traffic close to the source – at the
“edge” of the enterprise – only the meaningful and validated
events are passed on to central IT systems. This digestion process is more
than basic filtering – it’s data cleansing, consolidation, and
summarisation; it’s exception handling of many types – automated
and human-made; it’s compensation for unreliable technical infrastructure
– application, hardware, network failure; it’s adjustment for
unreliable RFID tag-reader environments. Digestion of data close to the
source allows this complex processing to occur, and exceptions to be handled
locally thus protecting central IT systems from the flood of data.
Operational data management architectures are common in the financial industry
– for example, trading systems collect market data in real time, execute
trading strategies heuristically, identify trading opportunities, and forward
the results to traders for action. These systems eventually generate the
trades tracked by back-office systems, but billions of dollars are invested
every year on the operational stages needed that precede the actual trade.
This kind of data management and applied intelligence will become more prevalent
as RFID adoption encourages companies to deploy intelligence at the point
of operational activity.
2. Employ RFID data “concentrators”
You could water your lawn using water from a hydrant if you could step down
the pressure and flow. One way to deal with the gush of RFID data is to
develop RFID data “concentrators” that help control the flow
and provide filtering and aggregation of EPC event streams (see figure below).
An RFID data concentrator is software that collects and processes raw RFID
event flows close to the source of the data (principle 1). There are three
primary elements: RFID middleware, event processing, and an in-memory data
cache – combined they achieve the reliable speed you need.
RFID middleware provides the interface for applications to receive events
from RFID readers. There are many commercial implementations of RFID middleware
available today. Additionally, the EPCglobal standards organisation (EPCglobal
is organised by EAN International and the Uniform Code Council (UCC) to
drive the global adoption and implementation of the EPCglobal Network) is
in the process of defining a standard for RFID middleware, the ALE (Application
Level Event) standard, which defines a reader-neutral interface for receiving
events from RFID readers.
Event processing handles high-volume, high-performance flows of events by
organising raw events into pipelines. Pipelining is a concept found in hardware
and software systems of many types, including the central processing units
(CPUs) in your computer, in software designed for handling stock market
feeds in real time, and transaction processing systems that your credit
card company uses. Pipelines allow the events to be categorised, then process
those categories with a set of simple tasks, as each thread gets a slice
of processing time from the CPU. By performing a large number of operations
on data in small “bursts”, overall throughput is increased,
and the average speed that any individual event can be processed is increased,
as well.
Finally, an in-memory database, or data cache, makes the concentrator work
in real time. In-memory data management techniques are crucial to accommodate
the real-time nature of RFID. It’s a basic law of physics: memory
is 1,000 times faster than disk. Physics is the reason why MIT’s (Massachusetts
Institute of Technology) Auto-ID centre included a “Real Time In-Memory
Event Database,” or REID, as part of its first RFID reference architecture.
Similarly, Stanford’s CEP research has employed an “in-core-memory”
database. While this cache provides much the same reliability, availability,
and fault tolerance of a database, the distinction of calling this element
a “cache” is to distinguish it from the enterprise application
database, shown at right in the data concentrator diagram.
3. Create pipelines for distribution
Developers often start small projects that are successful. But as the project
scope expands, data volume grows far more rapidly than expected. The system
can’t scale and the project winds up becoming a disaster (think exploded
garden hoses and pools of water). RFID deployments are particularly susceptible
to this “success disaster” syndrome. Increasing numbers of RFID
readers will lead to more streams of data, which can quickly overwhelm the
system. The way to handle the load is through pipeline processing.
Once you have an RFID data concentrator architecture in place, set up pipelines
to handle the streams of data. Pipelines separate streams of EPC data to
handle load and coordinate or process the data streams after they have been
captured. To achieve additional scalability, you may need more than one
concentrator distributed on a set of distributed machines, each one controlling
a domain of RFID activity, distributed on multiple machines. For instance,
let’s say you have deployed EPC readers at a distribution center with
30 dock doors. Half the readers are tied into one RFID data concentrator
and half into another. You should create several pipelines from each concentrator.
One will feed data into a local inventory database, one into a regional
database, and one into financial applications.
As rollouts of major RFID projects unfold, companies will quickly find they
are going to be overwhelmed by data, unless they follow these three basic
principles and build an RFID architecture that will scale, not fail.
ObjectStore® is a global provider of real-time data
management products. Its products enable corporate data caching and complex
event processing, and its leading object database is renowned for performance
and scalability. In the UK ObjectStore can be reached on 01753 216350. Or
at info-emea@objectstore.net
By Mark Palmer RFID technical evangelist with ObjectStore. www.objectstore.com
|
•
Home
|
