Despite the hype, the truth is that RFID deployments made little headway in 2005. New standards, prohibitive costs, and the lack of upper-level business context left most companies tuned out to this much-ballyhooed technology.
Larger companies that have rolled out RFID have done so primarily in experimental, proof-of-concept deployments. These pioneers have quickly learned that RF-enabling the enterprise takes more than mere tags and interrogators. Deriving true business value demands tuning out the noise from RFID discussions and channeling their insights into the business logic running your enterprise.
But hope is here. Middleware revisions from key vendors and the relatively recent availability of low-cost hardware based on the new Gen2 RFID standard have pushed RFID back onto the table for many companies. This new generation of products allows companies to move beyond general asset management and inventory tracking and blend this newfound event stream into actual business processes.
Catching the radio wave
For the uninitiated, an RFID network can be broken down into three primary ingredients: hardware, including readers, tags, and RF-related components; the middleware connection and processing engines; and the API through which enterprise applications tap data. The intricacies of hardware notwithstanding, RFID's is most complex in the middleware layer.
To diminish network latency, processing engines should be located as close to RFID readers as possible -- in the warehouse rather than in a back-office datacenter, for example, which means each warehouse should have its own, independent engine. Engines must be scalable, robust, and capable of interpreting a variety of readers while parsing and managing a flood of streaming data at high burst rates.
Next, an events management subengine winnows nuance from noise. By providing basic rules and pattern-matching that aggregates and filters data, it can minimize the barrage before it hits the corporate network.
Finally, the interface API makes it possible to move RFID data between storage, enterprise applications, programmable logic devices and automation controllers, and the sundry other I/O systems and controllers that production-grade systems employ.
The primary means for interfacing these devices is the ALE (Application Level Events) specification. Initially developed as part of the Massachusetts Institute of Technology Auto-ID Center?s Savant application, ALE has become the de facto standard by which most vendors can enable middleware applications for RFID. Today ALE falls under the wing of EPCglobal, a consortium of standards bodies and supply-chain interests, and is part of the EPCglobal Network plan for interconnecting low-level EPC (Electronic Product Code) data with higher-level enterprise systems.
At its core, ALE is based on SOA. It abstracts an interface of services, similar to how SQL abstracts the internal machinations of relational databases. Applications can query the engine through the ALE without concern for network protocols or device specifics.
In addition to consolidating multiple EPC read sources, this functionality brings a number of benefits. For example, the ALE makes it easy to weed out tags from a particular manufacturer or area on a warehouse floor. Time-based and delta change criteria are also useful in exception handling, such as isolating a tag that's passed a given point once and then later regains focus.