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.
Most importantly, ALE isolates against hardware and vendor changes, smoothes scalability problems, and resolves the complex programmatic synchronization that would otherwise be necessary to share multiple reader resources among back-end applications.
Processing the event stream
ALE isn't the only tool needed to round out a complete RFID infrastructure, however. Making higher-level sense out of the flood of low-level RFID data is not an easy task, and not something that you can entrust to the post-mortem latency inherent in traditional BAM (business activity monitoring) software.
A solution, though, can be found in ESP (event stream processing) and CEP (complex event processing) software. Although CEP-based solutions have been around for a while, primarily in government or military applications, within the past few years viable commercial deployments have begun to appear.
When viewed as a single category, complex event stream processing mines low-level data to infer high-level patterns and trends developing in real time across multiple systems and sources. By collecting event data and infusing it with additional scope -- such as details on location, state, causality, and time reference -- these applications can rake supercharged events across complex rule sets, isolating exceptions and uncovering seemingly unrelated cause-and-effect relationships in real time.
It's one thing to isolate an error, but it?s entirely more relevant to see the whole causal relationship leading up to that error. This is easily achievable using CEP/ESP, and the software can then direct alerts and triggers back into your enterprise systems -- ERP, manufacturing execution, or warehouse management systems, for example.
Sophisticated ESP products, such as Progress for RFID from Progress Software and StreamBase Systems? Stream Processing Engine platform, can tap RFID and additional enterprise systems to build a more thorough event profile. For example, these solutions can easily correlate historic data, such as service-level issues or intrinsic customer value, with real-time RFID-based insight -- say, a purchase order that's been picked but is stuck on the shop floor. Alerts from the ESP system can notify managers that an important order is about to be screwed up again and then display stock that's available on another loading dock, allowing it to be diverted to the higher priority.
Traditional methods of analyzing data -- with polled and scheduled reporting -- impose latencies too great to withstand the real-time surge of data in RFID. Using ESP's in-memory pattern matching and native temporal services, the enterprise is alerted to overarching patterns as they occur. Whether it's perishable fruit rotting in a stalled loading dock or detecting shopping patterns on a retail floor, ESP offers the chance to adjust business rules with real-time agility.
Perhaps ESP's most alluring quality is that its deployments do not require alterations to existing systems. ESP typically runs alongside transaction processing systems, communicating into the enterprise by way of a messaging service or custom adaptor.
Specific to RFID, ESP can improve data validity by scrubbing out the inevitable glitches, collisions, and partial reads. And it's capable of addressing many early-game RFID anomalies, such as flow direction by consolidating added data from motion controllers into discrimination analysis.
As RFID implementation costs drop and tag data becomes increasingly smarter, application sophistication will rise. Accounting for future RFID imperatives -- for example, environmental data or tag updates along a supply-chain route -- will necessitate efficient correlation and analysis. So, although complex event stream processing may not be a requirement for RFID today, it is a smart approach for maintaining insight into tomorrow's highly distributed, real-time networks.
Inside the broadcast booth
Building an RFID infrastructure means programming not only custom software using ALE but also the hardware interfaces of RFID readers. Thus, for all but the smallest of deployments, this is no easy task. A much better option for streamlining integration and ensuring data integrity is to use the variety of middleware tools and platforms now available from a number of vendors.
On the forefront of RFID network management, Sun Microsystems released a major update in February: Sun Java System RFID Software 3.0. The package comprises Sun Java System RFID Event Manager, Sun Java System RFID Information Server, a developer kit, and a management console module.
The Information Server provides reader support and application query services, while Event Manager tackles event processing to filter and smooth data input. Most importantly, the package delivers excellent distributed fail-over, something that's crucial to the zero-downtime tolerance of RFID.
The new version includes APIs that address reader and printer functionality. Another highlight is the addition of Java ME (formerly J2ME) support, for embedding intelligent processing directly onto devices, an excellent next-step advance into building smart readers and appliances capable of interconnecting with automation devices throughout the warehouse without centralized server control. In addition, Sun has included support for both ALE and the EPC-IS (EPCglobal Information Services) interface for RFID data exchange among trading partners, as well as support for SAP's AII (Auto-ID Infrastructure).
A component of SAP's NetWeaver application, AII offers mySAP Business Suite customers straight-through integration of RFID data, which is useful in supply-chain, warehouse, and inventory management app-lications. AII includes good event management features and support for the range of legacy and modern devices, including bar codes, PLCs (programmable logic controllers), and Bluetooth devices. Other tools, such as the Auto-ID Cockpit, help warehouse managers drill down into active processes to monitor state and location status of orders.
Support for SAP's Auto-ID Infrastructure is also available in the recently updated RFID Anywhere 2.0 package from iAnywhere, a Sybase subsidiary. This package delivers a middleware platform similar to that from Sun, including both Site Manager and Component Manager modules, although it lacks the capability for on-device deployment.
This basic offering will be insufficient for enterprise-grade projects, however. These customers will need to upgrade to the full Sybase RFID Enterprise 2.0 package, which bundles the RFID Anywhere software with tools for event management, data analysis, and full-on business process integration. This SOA-supporting combo delivers good developer perks, such as Microsoft Visual Studio extensions for generating shell code, RFID network simulation tools, and the capability to interface with a variety of interrogator interfaces, proximity sensors and controllers, and legacy technologies.
Looking to broaden its install base, SAP recently announced a partnership with Intermec, an RFID device manufacturer, to target small and midsize customers with affordable RFID solutions. There are a number of other key middleware players in the market as well -- such as early trailblazer ConnecTerra, recently acquired by BEA -- and IBM, with its WebSphere RFID Premises Server and device-embeddable layer.
Mixed signals
Despite the growing list of hardware and software tools, make no mistake: RFID is still very much an emerging market. Don?t let any vendor's marketing gimmick convince you otherwise. If you're planning to deploy RFID today, prepare to face device compatibility issues, buggy software and firmware, global numbering standards that still need to be ironed out, and security threats in need of redress.
With respect to middleware, most of the first generation of interrogator hardware was pretty dumb. As next-gen readers and printers begin to add more edge-processing functionality, a fixed middleware layer will become less crucial. Focus will shift entirely to bridging the RFID infrastructure with BI (business intelligence) and creatively applying data from that infrastructure to business processes -- for example, using complex event steam processing.
Until RFID becomes as ubiquitous as the bar code, plan to take steps to future-proof your RFID blueprint, rather than simply meeting mandated compliance. By investing in scalable, extensible platforms that can adapt to future usage models, you'll ensure that your investments today will retain their value in the next RF wave and beyond.
[InfoWorld Electronic News -- 04/18/06]
