Is RFID Finally Hitting the Masses?

By Juan Carlos Ramírez (IDLink Solutions)

As an RFID entrepreneur I’ve followed closely probably all of the RFID and sensor technologies in the last 3 years of my life. Being part of this exciting emerging technology makes you think about how “smart” things and objects will change the world and the way we live our everyday lives.

Among all of the potential RFID uses, I guess it’s natural to wonder which one of those will be the one to impact the end user in a greater and most significant way. In my opinion I think NFC technology, which is pretty much RFID for the mobile phones, is the one poised to dramatically change the RFID landscape. Giving access to product information to the end consumer could be huge. Your mobile phone could now be your credit card, your car keys and more. What about using it to access information about products in your preferred store? Wouldn’t that be great.

Last week, the most important Telco companies in the US made a major announcement. They decided to join efforts to push towards NFC adoption by creating a payment services company. This announcement was followed by Google’s CEO presentation of the next Android NFC enabled phone, not to mention Apple’s and RIM’s plans towards the same direction.

Now, this opens a whole new debate and a very interesting one by the way. NFC operates under in HF instead of UHF, which is probably the most popular RFID technology for industrial and supply chain operations. Will NFC make HF win over Near Field UHF for item level applications?

In the end, I think we are evolving towards a smarter world. Things will be interconnected and big streams of information will flow in all directions. How are we supposed to handle all that information? That’s where RFID middleware will come into place.

Dataflow and the Rifidi Edge Server

This is the first in a series of blog posts that give a technical overview of the architecture of the Rifidi Edge Server.

The most basic (and important) function of the Rifidi Edge Server is to collect data from sensors, filter them, and deliver them to systems that use the data for business processes.  This diagram gives a high-level depiction of how data are collected and flow through the edge server.  The data begin their journey as they are produced by sensors.  While these sensors are normally hardware RFID readers, such as an Alien 9800, Symbol XR400, etc, data might also be produced by a legacy barcode reader, a database, or even another edge server.  The Sensor Abstraction Layer provides a way for users to develop their own plugins for their custom sensors.

As data are collected from the sensors, they are pumped into a high speed internal message bus through which other internal edge server components can access them.  Because sensors have the ability to produce an enormous number of events, users normally want to filter them.  The Application Layer Events (ALE) specification from EPCglobal provides a standard API for collecting and filtering RFID data.  The Rifidi Edge Server has an implementation of the ALE 1.1 specification.  Internally, the ALE layer uses an event stream processor called Esper to collect data according to the ALE rules.

Some users will decide that they do not want to use ALE in their solution.  Because the Rifidi Edge Server is built on an extremely flexible architecture, they can create a custom data collection layer and hook it up directly to the internal message bus.

Future architecture posts will describe other aspects of the Rifidi Edge Server in more detail.

What’s in a Name?

Going into the RFID Journal Live trade show, I assumed that I had spent the past eight to ten months of my life developing an edge server — a piece of middleware that connects to RFID readers, collects data from them, filters the data, and pushes the data up to a higher level business application. Was I ever wrong. What I had actually been working on was an application platform. Talking to all the people at the trade show reminded me once again of just how general of a technology RFID is. Not only are there many classes of deployments (RTLS, inventory, supply chain, asset tracking, etc), but even within similar classes, deployments differ greatly depending on all kinds of variables — from the physical layout of a facility to the IT infrastructure that is already in place — that are unique to that situation.

Because there is no such thing as an off-the-shelf RFID deployment, middleware that is not completely malable is unuseful. This is why describing Rifidi Edge Server as simply an edge server is limiting; it implies that Rifidi Edge Server is a static piece of software. Describing it as an application platform, however, better captures how it will be used in practice. Much like JBoss is not so much an application server as it is a platform for building J2EE solutions, Rifidi Edge Server is more of a platform for constructing RFID applications rather than a solution in and of itself. In deployments, Rifidi Edge Server will be used as a core that provides a base set of tools and functionality that developers will tailor to their particular needs by writing extensions and plugins to it.

You might say that the difference between describing Rifidi Edge Server as an ‘edge server’ or as an ‘application platform’ is simply a marketing device. But to me, as a developer, it represents a fundamental difference in how I view the code. Before the show, I knew extensibility was a priority; now I know it is vital. With this refined viewpoint, I am looking forward to the next few months.