Early on in any IT project architects need to decide which software
products best solve their business problems. “Build versus Buy”, and if
“Buy” what are the best and most efficient products. In principal any IT
problem could be solved and coded using even Assemblers. In the early
90s, people used C/C++ for their early internet systems. Yes, no one
would even think about such choices anymore. We long have learned to
rely on Java, Web Servers, and Application Servers. They are geared
towards Internet problems and come with much functionality out of the box.

Looking at RFID business problems, it has not been so clear in the past.
Many existing systems are “Build” type solutions for which developers
use .Net or Java and are accessing RFID readers’ API directly, trying
to build a minimum level of infrastructure code to address some key
technical requirements. I bet there are thousands of those individual
“infrastructure” implementations being used right now. Some of them
present an enormous maintenance burden.

What are our key requirements for RFID platforms products? Surely, they
have to address connectivity to RFID readers, also sensors if possible.
Data come in real time, often in volumes that are not predictable in a
reliable way. RFID data are basically read events that need to be
filtered and transformed into business events. This is similar to
processing requirements of high volume financial systems. Credit card
processing systems that obtain a high volume of events need to correlate
such basic events into business events and trigger actions. RFID systems
are inherently event-driven. They can very much benefit from
event-processing engines such as Esper. Those systems allow to filter
and process RFID events in memory and in real-time. They provide event
correlation, for easy detection of business events from low-level RFID
events. Esper, for instance, provides time-based queries, making it easy
to detect for example if an item has been in a zone for too long.

Another key requirement is based on the light-weight environments we
typically want to build. RFID systems are on the edge on the enterprise,
and as such need to run and perform on inexpensive hardware. Heavy
application server architectures are a fundamentally wrong approach. The
IT industry recognized this problem several years ago and defined OSGi
as a common standard for such appliances. It is being used in
refrigerators, and many day-to-day appliances that are produced in high
volumes; a nice, light-weight and flexible industry standard that avoids
the burden of for example having to run application servers on a small
appliance.

In summary, requirements for RFID platform products being used for IT
projects have many clear and common characteristics. Sufficient and
appropriate RFID Reader adapters, being able to handle high volumes of
load, event processing engines are some key criteria. In addition, the
product needs to be open enough so developers can use their trusted
development environments. A last, but very important criteria is the
light-weight approach that RFID systems and appliances can use in order
to keep hardware cost to a minimum. After all, appliances should run on
the edge of the enterprise, easy to maintain, and with low hardware
costs, but in high volumes. RFID systems that meet those requirements
will help the industry advance and become standard software. No need to
build your own RFID platform anymore.

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.