Previously we published an article entitled, RFID Middleware is Extinct: The Intelligent Sensor Network is Born, where author Louis Sirico made the controversial proclamation that "RFID Middleware is not a long-term solution." The article has been viewed nearly 20,000 times and we’ve received feedback from countless professionals. After all this scrutiny, the industry experts agree: an RFID reader is actually a sensor device and it needs to be treated as one.

RFID-centric middleware applications and appliances have consistently failed to scale beyond a pilot project because they focus on RFID and not the other devices necessary to facilitate a complete business process. Implementations that truly derive value from RFID integrate the technology into their existing infrastructures. This means that RFID readers need to be choreographed with other sensors and devices using business logic. If you can’t create a correlation between a device and a business process, the device is useless.

This in-depth article provides criteria for selecting an Intelligent Sensor Network platform, including detailed considerations for software, hardware, appliances, and costs.

The Evolution of the Enterprise Network

Years ago, the local area network or LAN formed as a means for connected computers to share files and printers. Today’s network is far more sophisticated. An enterprise network may have tens-of-thousands of devices connected to it, including industrial sensors and automation devices. There can be environmental sensors, program logic controllers, digital cameras, vehicle mount computers, bar code scanners, and the list goes on. Even with the enormous diversity of devices, they can be placed into one of two categories:

1. With intelligence
2. Without intelligence

Devices with intelligence have some kind of processing capabilities while devices without intelligence rely upon another device for instruction and control.

Devices are connected by either a wire or are wireless. This is often referred to as the data transport mechanism. Communication can be either synchronously in real time or asynchronously using messages. These options alone can present a significant challenge when gathering data and managing devices.

Add another option – the communication protocol (basically the language) the device uses and you have even more complexity. For more details, see the article, Standards Used By Wireless Sensor Networks.

For an enterprise to effectively use and manage the devices and device data, it will require a hardware abstraction layer, which provides a common interface for the disparate devices.

Additionally, given that not all devices have the ability to communicate with more than one system at a time, a control layer is also required to coordinate conversations from multiple systems (e.g., to record temperature data in one system and send alerts to another system).

A network with this level of sophistication requires a platform that facilitates the creation of an Intelligent Sensor Network or ISN. If you would like more information on the ISN, we have explained it in much greater detail in the article, RFID Middleware is Extinct: The Intelligent Sensor Network is Born.

Forming the Intelligent Sensor Network

Edge Processing and Centralized Processing

When working with devices that do not have intelligence or with groups of devices, processing is required at the “edge,” meaning, close to the devices. Proper control and coordination requires speed.

Consider the example of 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. An enterprise system that is hosted in another building may not be able to process business rules fast enough to keep up with these devices – this is why device event processing must occur at the edge, close to the devices. You NEED the speed, otherwise latency impacts performance and the system starts missing events, which in the case of RFID means missed tag reads.

Using our Intelligent Sensor Network platform, the aforementioned sensors are grouped together as “freezer #3”. Rules are defined for the group; which means the rules are automatically applied to all the sensors in that group. The rules include data filtering (i.e. not reporting the extremely subtle changes) and smoothing (for example, rounding the temperature changes from 1/100th of a degree to one degree).

The system only reports what is requested by the enterprise systems and what is permitted – nothing more. Of course, the communication must use a secure messaging layer that ensures delivery.

Considerations for Selecting an ISN Platform

The fact is, your network is evolving, and what you have connected today may not be what’s connected tomorrow. Considering the needs of the future is vital when selecting your ISN platform. When evaluating platforms that facilitate the creation of an ISN there are numerous considerations. Yet, there are two key criteria that nearly always determine success or failure: flexibility and scalability. We will examine how these two factors impact each aspect of an ISN platform.

Software Considerations

Flexibility in this context means the ability to programmatically interface with different kinds of sensors in order to apply business logic. There are a number of vendors that provide niche applications to be avoided, such as:

• Device management ONLY for RFID equipment;
• Connectors ONLY for specific enterprise back-ends (a single WMS or ERP);
• Communication layers that are not required by the devices.

As mentioned above, processing of business logic must occur near the edge, close to the devices. As the sensor network physically expands then the ISN platform must reside in multiple physically locations. Therefore, support for a distributed architecture is required for scalability.

More specifically, here are a series of questions that the experts ask when performing an evaluation.

Device Management

Q: Does the ISN platform support ALL of the devices currently required or planned for?
Take the time to perform an inventory of what is in each facility. Consider stationary, mobile, and hand-held RFID readers, RFID Printer/encoders and high speed label applicators, PLCs, sensors, switches, and operator feedback devices.

Q: How does the ISN platform interface and manage these devices?
Note if it supports the use of standards (LLRP, ALE) or if it communicates natively (byte stream). There are typically advantages and disadvantages to each interface. Also look for support for different protocols for the same reader type. There are cases where for security reasons, HTTPS may be needed at one location, LLRP at another, and byte stream at another.

Q: How does the platform perform device firmware upgrades?
Can the upgrade be performed remotely while the device is on? Can the upgrade be scheduled to occur automatically when the device is not in operation? Finally, can it revert to the last know good firmware in the case of a problem?

Q: What methods of reader coordination are supported?

• Peer to Peer: one reader to another;
• Group Polling: combine readers in a group to synchronize polling;
• Trigger Polling: switch begins and ends read cycle, i.e. photo-eye, door switch, etc.

Each of these methods may be needed to support optimal performance for a RFID read point.

Development Tools

Q: What programming languages are supported? (.NET, Java, other)
How do the supported languages and the ISN platform handle device events to facilitate the creation of business logic? The ISN platform needs to provide an API for all the major development languages used in handheld or desktop applications. The language used for rapidly processing tag and sensor information at the edge needs to be optimized for high volume and reliable event driven transaction. As an example, Omnitrol Networks uses Service Description Language (a variety of Business Process Execution Language) which is event and state drive language for sensor networks.

Q: What standards are supported?
For RFID related projects, the ALE, EPCIS, and LLRP standards are extremely important for interfacing with EPC-compliant readers.

Q: How is business logic applied to devices?
This is one of the most important questions associated with scalability. Business rules must be modular, easily distributed, and managed. Devices, and groups of devices, should be able to subscribe to applicable business rules & be updated automatically in the event of a change to the business rule.
Take the following example: Let’s assume we build a business rule that coordinates a dock door switch, two RFID readers, four antennas, and a light stack. If the door is open, turn on the readers and start capturing tags; compare the tag data to the shipping order to ensure the pallets are loaded on the right truck, and flash a green light if OK, and red light if not OK. Many middleware systems allow you to copy code to each device so you write it once and apply it many times. This is nice if you get it right the first time. Consider later when the business rule is updated to determine if the pallets are loaded in the correct order. Imagine manually copying the code for every dock door. It is far better to have the devices subscribe to the business rules. One business rule is modified and all of the devices that subscribe to it are automatically updated.

Database Support

Q: What databases are supported?
Is the supported database vendor specific? If so, what is the license cost for the database? If standard SQL is supported, what functionality is lost compared to the vendor specific interface?

Q: How is database persistence handled?
What happens if the system looses connection to the database?

Q: Is there support for a local database?
Does the system have the capability to support a local database proxy instead of constant database inserts, updates, and queries to a database housed in a data center?

Serialization Support

One of the most important and overlooked capabilities is support for serialization – the ability to obtain or generate a unique ID from a distributed system. This is critical when provisioning or printing an RFID tag or serialized bar code.

The Importance of a Sensor Simulator

The system must include a sensor simulator, which simulates not only RFID readers, but the other devices you expect to use. This allows for the building of business logic without purchasing equipment and testing how the back-end can scale as the sensor network expands.

A sensor simulator can also be used to calibrate, refine, and test the ISN. A sensor simulator can simulate conditions that you cannot (or at least would not want to) occur in reality. For example, you can simulate a high-acidity signal from a bioreactor, without having to create a physical high-acidity condition (or high temperature condition, or high vibration condition – whatever parameter you choose).

Hardware Considerations

Once again, flexibility and scalability are the two key considerations in our evaluation. One of the biggest questions facing companies is should they purchase an all-in-one appliance or build a system (or systems) to fit their requirements. The table below outlines the primary differentiators.

All-in-One Appliance or Build-to-Fit?

At first glance, most people consider the built-to-fit option to be a more flexible solution simply because you can add what you need as you need it. Based on what we have experienced in real world projects appliances are better suited for versatility & deployment scalability than building to fit. Simply because most appliances have a variety of readily available industrial grade connectors that already have devices drivers installed and working. This is a serious advantage if the device is already deployed in a production environment. Need to add a new device six months from now? No problem, just plug it in. In the build-to-fit solution, you may need to install a card, install devices drivers, and maybe even upgrade your operating system. Of course, your system is off-line while this upgrade is being performed.

	Appliances	Build-to-fit
Components	Self-Contained	Size Computer to requirements Only Purchase the components needed
Form Factor	Small (1U)	Varies based on components required
Installation	All software and drivers included	Software and drivers must be installed
Replicas	MMS Create image and apply across all appliances	Image copy may only be possible OS
MTBF	5 years	Varies by component
Warranty/Support	One warranty / SLA for everything	More complex to manage May be different for each component

Appliances nearly always win out in industrial environment that requires durability. The connector types on a desktop computer are not typically ruggedized, and an appliance which is sealed and without a fan won’t gather dirt the way a computer does. Additionally, some appliances have no hard disk; everything is stored in non-volatile memory (meaning you don’t loss data if power is cut off). Not only does this provide significant performance advantages, there’s no chance of a hard disk crash that results in data loss and a complete system rebuild.

As you grow to a distributed architecture, appliances create a uniform solution. Having a spare device to swap out in the event of a problem is easier than building a new one to match what’s already built. Plus, the warranty of the appliance includes everything in it and is with one vendor.

Not All Appliances are Created Equal

In a supply chain project for a major aerospace company a middleware appliance company was selected for communication and coordination of their Motorola RFID readers. The appliance performed admirably during the pilot project with four readers. When the project expanded to fourteen readers, and added dock door switches with light stacks for operator feedback, the middleware could not process all events which appeared as missed tag reads. Ultimately, the middleware appliance was replaced by another vendor with a more scalable architecture.

What are the Environmental & Operating Conditions?

Whether you opt for an appliance or build-to-fit, there are a number of important questions to consider for each location in each facility that your equipment is going to be installed.

Q: Where will the equipment be located - in an industrial, retail, office, or other location?

Q: Will the equipment operate indoors, outdoors, or both?

Q: What are the specific environmental conditions at each location? (This could vary even within a facility)

Operating, and storage, temperature – minimum: ____, maximum: _____, average: _____.

Will the equipment be exposed to water, high humidity, or condensation?

What level of dust, dirt, salt, metal filings, grease is the equipment going to be exposed to?
Heavy, medium, light, none.

Is there any RF or electrical interference?

Will the equipment be in a fixed location or mobile (installed on a vehicle or cart)?
Measure shock/impact (g-force) and vibration

Q: What are the space limitations (dimensions) for each installation location?

Q: What is the proximity to devices to be managed? This allows you to determine cable requirements.

Q: What are the power requirements at the installation locations?
AC-powered (if so, for what region?) or battery powered. Note the volts & cycles.

Important Considerations When Comparing Equipment

Q: Does the equipment have an Ingress Protection (IP) rating? This will immediately tell you a lot about the durability.

Q: Is the unit sealed or does it require a fan for cooling? In dirty environments, especially where metal/wood filings are present, a fan cooled unit may not last long.

Q: What is the minimum maximum operating temperature (not storage) of the equipment?

Q: What kind of connector types (power, antenna, GPIO) are on the unit?

Q: What is the Mean Time Between Failure (MTBF) rating?

Of course, you can always consider industrial enclosures. For more in-depth information, see our article titled, The Importance of Equipment Enclosures.

Cost Considerations

Of course, no evaluation would be complete without considering the costs. During the past several months, several companies implementing RFID solutions have been lured by Microsoft BizTalk RFID Software because it is “free”. After an actual examination of the true costs, it was no surprise that it wasn’t free. However, what was a surprise is how many different line items are required. At a high level, here is the actual cost:

Medium Size Project	Unit Price	Qty	Cost
BizTalk Server Hardware Costs	$5,011	1	$5,011
BizTalk RFID Server Hardware Costs	$5,011	3	$15,033
Microsoft BizTalk Software Costs	$20,269	1	$20,269
Microsoft BizTalk RFID Software Costs	$8,798	3	$26,394
Additional HW	$14,390	3	$43,170
HW Support and Maintenance	$11,379	1	$11,379
Software Support and Maintenance	$8,399	1	$8,399
Total			$129,655

Examine each of the licenses required:
Software required:

• Microsoft BizTalk Server R2: not free – only the RFID component is free;
• Windows Server 2003 with Service Pack 1 or 2: you need an operating system;
• Microsoft Internet Information Services (IIS) 6.0: you need a web server for the browsers to connect to;
• Microsoft Office Excel 2003: required for data analysis
• Microsoft Office InfoPath 2003;
• Microsoft Visual Studio 2005 with C# .NET: required for development of business rules;
• Microsoft SQL Server 2005: required to store the event data from the RFID readers;
• Microsoft SQL Server 2005 Analysis Services: required to analyze the data in the database;
• Microsoft SQL Server 2005 Notification Services: required for alerting;
• Windows SharePoint Services 2.0;
• Microsoft Management Console (MMC) 3.0: required for management;
• Microsoft BizTalk RFID Server: this license is free!

Of course, multiply these software license costs for each system you need to build.

The Greatest Unforeseen Costs

Here are the most expensive items that our clients have found that they did not plan for:

• A tool for secure, guaranteed communication with the backend systems;
  Typically, a secure messaging system or VPN is needed along with a message queuing system.
  
  
• Do you need a database?
  A database to hold the event data can be expensive if each client (i.e. device) needs a license.
  
  
• Need another computer for a development?
  Did you consider the person that needs to build the business logic? Add another license of everything for this.
  
  
• Devices should be on an isolated switch;
  Most IT managers do not want their RFID readers on the same network switches as office computers. Therefore, consider a Level 5 switch for your RFID readers. Many appliances already have these built in.

Conclusion

The ISN platform you select may ultimately be the most important factor for long term success of failure. Consider flexibility and scalability in all aspects of your evaluation. Your enterprise network will evolve and the choice you make now will ultimately determine how easy, or painful, the growing process.

This article has been viewed 6819 times.