Written By Louis Sirico with brilliant contributions from Carlos Arteaga and Tony Woods
"RFID Middleware is not a long term solution". It has taken me some time to muster the nerve to publicly proclaim what many experts in the RFID industry have whispered behind closed doors for years. This should be a little less surprising as several big name providers have recently dropped out of the market. Yet, now that I have published this bold announcement, I'm left with the enormous task of backing it up and describing the evolutionary process that has taken place.
Let me start by clarifying what I mean by RFID middleware. Forrester Research defines RFID middleware as "Platforms for managing RFID data and routing it between tag readers or other auto identification devices and enterprise systems." What is unfortunate is that many RFID middleware applications were developed with a premise that the universe revolves around RFID data. These in-a-box applications were meant as quick fixes for encoding and printing a RFID label that's slapped on a pallet, and then reading tags as they pass through a portal. These applications are really Band-Aid-ware. If you have a small, pilot project fenced off in the corner of your warehouse they're fine to show a proof-of-concept, but once you enter the real world, RFID data must be integrated with all your other devices, not just routed to them. Once implementers tried to do more than a simple process, they started running into limitations that have slowed adoption of a technology that has incredible value when put into operation correctly.
In order to understand why RFID middleware is dying off, the industry must change its perception of RFID altogether. Which leads to my second bold proclamation:
A RFID reader is actually a sensor and it needs to be treated as one.
Reading a RFID tag is a sensor input, basically the equivalent of a barcode scan. Writing a tag is both a sensor input and an output (read the tag; write the new contents, read again to confirm tag write operation). What scared people and made them treat RFID with kid gloves is how fast these operations occur. I heard many people warn, "we must have a layer that sits between RFID and everything else otherwise all the data will clog corporate systems." Right concern, wrong approach.
What manufacturing plant or distribution center doesn't already have sensors and other industrial devices? Implementations that truly derive value from RFID integrate the technology into their existing infrastructures. RFID readers are choreographed with other devices using business logic to create an Intelligent Sensor Network (ISN).
Most importantly, the platform supports a distributed architecture that allows business logic to be performed where it is most effective and work within network constraints. Multiple facilities, each with their own ISN can be combined together, while maintaining centralized management, asynchronous communication, and secure integration. It allows companies to establish an Intelligent Network Sensor Infrastructure (ISNI). Let us examine ISNI in detail.
Sensors and Other Devices
The ISN is comprised of sensors and other industrial automation devices. Even with an enormous diversity of makes and models, they can be divided into two categories: without intelligence and with intelligence. Sensors without intelligence include:
Sensors with intelligence can execute instructions based on an event such as an input or output. These include:
Other devices that make up part of the infrastructure include human interface devices such as:
For industrial facilities, we must mention other industrial automation devices such as diverters, motors (i.e. the one that makes a conveyor move), servos, and robotics. There are undoubtedly sensors and devices I have not mentioned, but don't worry. The main point to understand here is that depending on the process you are trying to automate, you will most likely need to use a combination of sensors and other devices that work together.
When you start combining all the sensors and devices together is when things get interesting. It is also where most RFID middleware applications start stumbling.
A single device, like a hand-held, can contain a group of sensors. A sophisticated hand-held model can have a bar-code scanner, RFID reader, keyboard input, touch screen, and 802.11 wireless networking. A PDA phone may include a Global Positioning System (GPS), cellular communication (GPRS), Bluetooth, and a touch screen. What’s important is that these multi-sensor single-devices have intelligence that coordinates all the sensors together in real time. Most likely, the manufacturer of the unit provides a way of programmatically interfacing with all the device’s capabilities.
When you start connecting multiple devices together from different manufacturers it gets a LOT harder. Most likely, a group of sensors is going to require real-time communication and control. First, you have to worry about physically connecting the sensors. Second, you need to develop software that configures, controls, and obtains data from the different devices as well as coordinates them with one another. If the devices come from different manufacturers they probably have different methods of doing this. I’ve talked to many developers that have underestimated the effort it takes to do this. All of this has to be done before you can start applying business logic. A better approach is to use an ISN platform with a hardware abstraction layer (sometimes referred to as Edge-ware).
A hardware abstraction layer is comprised of small, distributed modules, and acts as a universal translator to each and every device on your network. Together, they provide a common business interface for all your applications to communicate with sensors, groups of sensors, and other devices.
The foundation of any network is communications. It is typically easier to understand device communication when it is described in the same terms as human communication. You need to communicate with a device in the language it understands. Standards are usually the best way to talk to devices. For example, the ISO/IEC 24730-1:2006 standard defines a common way of interfacing with Real Time Location Systems (RTLS) while the EPC Global Low Level Reader Protocol (LLRP) standard is designed more for passive RFID systems. Like most technologies, standards evolve over time and they are not always backwards compatible with previous versions. To make matters more complicated, an older device may support an older standard and may not be upgradeable to the new standard. Even when you have a standard, a device may have unique extensions that give you nifty features you want to use. What happens when the device that is perfect for you does not support standards or, worse yet, a standard does not exist? Then you must use the manufacturer’s method of interface.
If you are confused by all this, don’t worry; the point here is that it can be very challenging for applications to communicate with a network of different devices. A superior hardware abstraction layer provides as much uniformity as possible among similar devices types, supports standards, if available, and allows for configuration of unique features of individual sensors. Once you can speak the same language as your device, the methods of communication can vary. Traditional conversation can occur with paper messages, e-mail or electronic messages, wired telephone, a wireless telephone, a cellular telephone, satellite communication, or something else. A sensor or group of sensors is no different (except for the paper message part). The hardware abstraction layer needs to be able to talk using either real-time or message based communications.
Real-time (or near real-time) communication is required for rapid reactions to a device event, i.e., divert this carton after scanning this bar code. Message-based communication is required because sometimes your sensor, or group of sensors, may not always be connected to the network. We’ll discuss message-based communication later in this article.
The most overlooked reason for having a communication layer is the coordination of conversations to and from a single device from multiple systems. Most sensors and devices only allow a single application to access it at a time. That means only one application can talk to a device at a time. So, that application must be able to handle requests from other applications, including the management system, which we’ll talk about more in the next section.
If you are deploying in different countries, the perfect equipment for use in the United States may not be the perfect equipment for use in Europe or Asia. If you have a communication layer such as what is described here, you can develop one application that interfaces with different equipment. Plus, devices of similar type can be swapped out more easily, allowing you to combine the right technologies for the solution without months of software development. Don’t just consider what equipment you can support today; consider how easy it will be to support new and upgraded equipment in the future.
Sensor and Device Management
When you have thousands of sensors and devices in your infrastructure, you’ll realize why a centralized ISNI management system is a fundamental requirement. A management system should provide for the configuration and tuning of everything inyour ISNI. It must communicate directly with the control layer because configuration and control needs priority over other applications in order to address monitoring and alerting. The communication must also be as close to real-time as possible.
Here’s why: Let’s say the temperature rises too high in a refrigeration unit. Most temperature sensors can only communicate with one system at a time. If the sensor is recording the temperature in one system, how can it alert that there’s a problem? It is critical that the control layer not only keep recording the temperature, but also alert that it is outside of normal.
When you have an enterprise of sensors and devices, the management system should also expose a complete set of configuration properties for every sensor or device through a centralized, visual interface. It should also allow for grouping of devices and allow configuration management and maintenance rules.
A good management system can save you a significant amount of money. Here are a few examples:
Your management system should be extendable and support standards. For example, to ensure all your devices are time synchronized, your management system must support a Network Time Protocol (NTP). Of course, it should also support Simple Network Management Protocol (SNMP)—an application layer protocol that facilitates the exchange of management information between network devices.
At the heart of the ISN is an event processor. Any kind of sensor input or output is considered an event and there may be literally millions of sensor events occurring per second. Each event can be communicated in real time or in a message and every one needs to be handled as close to real time as possible.
Therefore, the event processor must have a massively parallel, distributed architecture. The event processor handles sensor events as they occur and buffers them for processing. Since not all of the events handled by the event processor will have an impact on other systems it must be able to filter and smooth all the buffered event data. For example, a temperature sensor may report fractional changes in temperature every second, but you only want to report and record when the temperature changes 1°F or more.
The event processor must also be the layer that enforces security. For example, event data can generate an alert that notifies an administrator, but the same data may not be authorized to go to a particular system. This example is actually defined as business rules, which we’ll discuss in the next section.
The definition of RFID middleware makes no mention of “business logic”, yet this is where you benefit most. An ISNI platform must allow you to define rules based on sensor events. Simple business rules include alerts – if this condition occurs, then take the following action. A powerful business rules engine coordinates multiple sensors together and allows combinations of sensor inputs to produce alerts.
The most difficult function for the business rules processor is to filter and smooth event data. This significantly reduces the amount of event data that would otherwise be sent to enterprise systems. Recall earlier that RFID can have hundreds of sensor inputs per second. Traditional RFID middleware focused on filtering RFID data. An ISN platform supports many kinds of sensors, not just RFID.
As business rules are built, they can be combined to create a sophisticated workflow process. The business rules can not only generate alerts, but messages or reports that serve as the interface to other systems. The Application Level Events or ALE standard from EPCglobal is an important method of interfacing with intelligent RFID readers and should be supported by an ISN platform.
The business rules engine must have security in order to prevent event data from being accessed without proper authorization. Although the rules can be defined using a number of different methods, they must be executed by the event processor. This provides for the most secure and rapid alerting.
Take the following example: let’s say we have a Freezer that contains RFID tagged items. Inside the freezer there is a door switch, a temperature sensor, and a RFID reader. The door switch reports the status of the door to the event processor every second. The temperature sensor reports to the event processor subtle changes 10 times per second. The RFID reader reports tag data as often as 500 events per second. Using our ISN platform, we can group these sensors together as “freezer #3”. We can then define rules that are applied to the sensors, including filtering and smoothing. We can also control how often the data is reported and what systems are allowed to access the information.
Finally, business rules can not only be built based on what happens, but where it happens. That’s why we need location information.
Each sensor needs to be associated with a location. A sensor can be anywhere and its location can be stationary or moving. That’s why a Location Processing System or LPS is required. The location of a fixed position sensor can be determined simply by performing a look-up in the LPS (e.g., the bar code reader is at work area 12.)
Moving sensors are a little more complicated. Technology has evolved to the point where there are many methods of determining location. Their position can be determined using other sensors.
Here are some examples of how the location of a sensor can be determined:
Each of these methods of location has there own Position Engine (PE) for determining location. Some intelligent sensors even have one or more location engines built-in. Since the methods of determining location can vary, the LPS should not only be able to use position engines, but also be able to automatically switch between them. For Example, at a facility with an 802.11 based RTLS inside and GPS outside. This allows you to combine the location information from different areas or facilities and monitor them in a central location. Besides, if the LPS cannot support different position engines, then how will it support future technologies yet to come?
The LPS must be able to interface with business rules. This can be very tricky because the methods of communicating with different position engines can vary drastically. The LPS must convert all different protocols from all the different position sensors into a common protocol, such as the ISO 24730 standard.
The LPS should also have a visualization engine, such as the one pictured below. When you have thousands of devices you will realize why the visualization engine needs filtering capabilities. In other words, only display objects with a certain characteristic. For example, only display the automatic defibrillators.
The LPS must let you correlate location data and sensor data. You visually define a zone around a sensor based on the sensor type. For example if a RFID reader reads a tag with certain signal strength, then you know the tag is in that area. The same can be applied to a bar code scan. If the position of the handheld scanner is known because you are using an 802.11 based RTLS, then you know approximately where the item with that bar code is located because it is in the zone. The position of sensors and sensor data are updated as often as the synchronization says to do it.
Communication with enterprise and external systems must be based on the defined business rules. A single event may have an impact on multiple applications. The ISN platform requires the intelligence to manage the applications that want event data and the format those applications want the data. When you combine the event processor and the business rules, the ISN platform is responsible for taking event data and pushing it into the network for every registered application that wants it and is authorized to have it. One of the biggest failures of many RFID middleware applications is that they only allowed data to be routed to a single system, in most cases a database. The one system would then have to connect to all the other systems, creating a bottleneck, not to mention a single point of failure.
Business rules can be created and accessed by enterprise and external systems several ways. They can:
The communications layer should use a combination of secure messaging and a Service-oriented Architecture (SOA), so that device event data can be brought to enterprise systems. The world’s largest enterprise application providers (IBM, Microsoft, Sybase, SAP, etc.) agree that a SOA is the preferred method for sharing data.
The communication layer should also be able to support any method of message transport. For example: send an e-mail, output a file (i.e. XML) via FTP or HTTP, interface with standards such as SAP AII over HTTP, JMS, MSMQ, SMS, or allow you to develop your own.
Each message must be queued with guaranteed delivery. Event messages may be generated very often or rather infrequently to support the occasionally connected (asynchronous) devices (mobile computer or hand-held) and systems. For example: you may update your manufacturing execution system (MES) every 10 seconds, your warehouse management system (WMS) every five minutes, your enterprise resource planning system (ERP) every 30 minutes, and your trading partners every eight hours.
The method of communication with any of these should not matter. The communication layer should support automatic switching between the available types of communications when one is slow or broken; this includes Ethernet, 802.11, serial (RS-232 or RS-485), cellular (GPRS), dial-up modem, Bluetooth, Infrared, Active-Sync, or something else I have failed to mention. In the real world, you may prefer to communicate with hand-held scanners using 802.11 based wireless networking to send messages in real time, but if the device travels out of range, then it should automatically switch to GPRS with message based communication (connect every hour to send all messages).
I have listed numerous considerations, but I hope the main point I have made is that before you start building applications, you need to establish your infrastructure.
I have also listed many of the features you should consider when making a purchasing decision. Here’s a few more that should be mentioned:
Supports a distributed, scalable, architecture
Consider how many sensors and other devices you have and where they are located. You will quickly understand why you need a distributed architecture. Since these devices may not be connected all the time, you must be able to execute business rules right on an intelligent sensor.
Consider what would happen if your event process is running on a single server and that server goes down. How do you continue to process events? Do you stop your entire operation until your server is back up? The event processor needs to be on a platform that supports automatic fail-over. It should also support load balancing – the ability to distribute work among multiple servers. This is particularly important during peak operating times or if you have more than one facility.
Support for Security
This includes features such as device authentication via certificates and data encryption, especially when communicating with enterprise systems and trading partners.
It is supported by a stable vendor with a proven track record for deploying enterprise solutions
It is supported by a stable vendor with a proven track record for deploying enterprise solutions
This is particularly important now that several RFID middleware companies have dropped out of the market.
Many of you reading this may say, "We don't need all this". That may be true today, but consider tomorrow.
In closing, I’d like to be clear that this article is not meant as a checklist of what an infrastructure should support before you make a purchase. It is meant to show the importance of having a well thought out architecture for your enterprise infrastructure. There is no doubt there will be new sensor technologies in the future. The investment you make today may be what you have to live with for years to come.
I hope that this article demonstrates why so many RFID middleware applications have failed to scale beyond the simplest tasks. Too many companies have found themselves being forced to replace their RFID middleware and throw away their investments.
This article has been viewed 11138 times.