Stephen Moody, an RFID Program Coordinator for the Combat Feeding Program of the US Army's Natick Soldier Research Development, presented a fascinating case study entitled: "DoD Active RFID Applications for Supply Chain Security and Shelf Life Management." It is easy to underestimate RFID as something akin to a glorified barcode or a "traveling database". But many active RFID tags are far more sophisticated in that they incorporate environmental sensors. The US Army sends tons of rations to the troops in Iraq and elsewhere. These shipments are made in ships holding thousands of standardized shipping containers. How can the US Army be sure the shipments have not been tampered with or exposed to unacceptable environmental conditions? The answer is active RFID tags with sophisticated sensors for a number of environmental events: temperature, radiation, light, chemical agents, biological agents, shock, door sensors, etc. If somebody is doing something to a shipment of food, or if it just gets too hot for too long, the US Army knows when it happened and where it happened. This is simply one of scores of applications for active RFID in an organization like the US Army. But what does one do with all that data? According to Moody, "the greatest barrier to the successful implementation and adoption of RFID is integration to legacy systems."
One of the other challenges for RFID is the current lack of standards. In some ways this is unavoidable: RFID is not a specific product, technology or protocol. RFID is a family of technologies that incorporate radio frequency and are used to identify "stuff." As Sue Hutchinson, the Director of Industry Adoption for EPCglobal US put it, RFID provides the answer to the question "where's my stuff?" But the type of RFID may involve passive RFID, where the tag has no power source and is a write-once technology, to active RFID, including ultra wide-band (UWB), all the way to GPS and beyond. With such a diversity of technologies, standards become even more important. Lacking these standards, however, flexible development and integration tools become even more important.
Consider the food safety example above, somewhere in an ERP system the information resides for the supplier name, items ordered, supply date, carrier and so forth. Does this information get integrated to the data on the RFID tag? What happens if food from one supplier is more prone to spoilage or to lose palatability under prolonged high temperatures? How can the US Army, or any organization for that matter, take full advantage of RFID applications if key information sits locked in a silo such as an ERP or supply chain system?
Information integration is the key. But how does one best handle RFID integration with an ERP or other existing application? To answer that, we first need to consider the RFID system being used. RFID systems involve tags (some with built in sensors), programmers, readers, networks and so on. But most do not include middleware. And the hooks provided are inconsistent. Text files, XML, .NET objects, java objects and Web Services are provided inconsistently. For an organization to be prepared to integrate the data from a reader, they can benefit from a middleware solution like iBOLT that provides the ability to consume any of these data types and orchestrate them within an overall business process. Or they can create interfaces from directly within an eDeveloper application. Even when dedicated applications are written to take advantage of RFID data, middleware and business process management software is still needed to facilitate integration to legacy systems. Ideally, these middleware systems are service-oriented including event driven capabilities, discoverable web services and more.
Unfortunately, too many RFID early adopters are resorting to hefty J2EE or.Net based programming projects rather than utilizing a development tool like eDeveloper V10 or a simplified visually-oriented business process design tools like iBOLT. As the world begins to find more and more uses for RFID, it will be useful for serious organizations to incorporate eDeveloper and iBOLT for integration to RFID data, whether it comes in raw text or XML format or is served up by a Web Service or programming object like .NET or XML.
With RFID, the emergence of integration file standards is far from certain. The Auto ID Center has proposed an XML format known as PML as a standard. You can read about it on the XML CoverPages hosted by OASIS. But the adoption of the standard is far from ubiquitous, especially in the Active RFID world which tends to look at organizations like EPCglobal with at least some degree of suspicion.
The good news for eDeveloper programmers is that since PML is just a flavor of XML, you can access RFID data with standard eDeveloper XML tools. To see what you’re avoiding, take a look at the PM example below. For more information on RFID and iBOLT, you can access Magic Software’s RFID related webinars.
Using PML in eDeveloper V10
eDeveloper V10 includes a new capability called XML Integration. This approach makes PML’s use within eDeveloper much easier. In fact, you can now develop applications using eDeveloper with no database at all and simply use XML files, including PML for RFID and other Auto ID related applications.
When using a PML data source containing RFID data, you can create eDeveloper tasks (batch and online) that use the PML files as their view (main files and linked files). You can define an PML data source in the Data repository (remember PML is XML) and define a task to manipulate and handle the PML. You can check that the XML task is compatible with the XML schema by using the XMLValidate and XMLValidationError functions. Namespaces are automatically handled by eDeveloper.
There are two XML development methodologies to choose from. You can develop applications using XML in the data repository or you can develop using XML with BLOBs. If you use both methods, then the BLOB takes precedence.
With eDeveloper V10, a task that uses XML (such as PML) will first open the entire XML file (if it is not already open) and then populate the tables. It then executes the defined task, whether that be query, insert, update or delete. Finally, when closing the task, if the data has changed, then eDeveloper V10 writes the XML BLOB or file back over the original XML source.
eDeveloper V10's XML Integration feature provides two functions that allow you to verify that the XML is compatible with the XML schema.
The functions are XMLValidate, which validates an XML document against its schema; and XMLValidationError, a function that returns the errors of the last XMLValidate. This will help you to determine whether your PML file is valid based on the PML schema, which of course is found in the .xsd file.
With eDeveloper V10, you can use the Get Definition function to discover the properties of a PML file that contains RFID data and map them to an eDeveloper table. Like all XML files, PML files are described by .xsd metadata that contains the XML schema definition. During a Get Definition, if an element’s/attribute’s type is defined using a SimpleType or as a reference to a Global element, it will be converted to the appropriate Primitive xsd data type from which it is derived.
Primitive xsd data types are mapped to corresponding eDeveloper attributes. Once this occurs, the field attributes can be changed without restriction. A default picture (most of the time you can think of this as length) will be assigned (as specified in the table). When the type is based on a SimpleType, which defines length, the picture will be updated with the length specified for the SimpleType.
What About Other RFID Data Integration Types
To be sure, RFID vendors are not uniform or universal in their support of RFID data via PML or XML. Fortunately, eDeveloper has built in functions for the other common methodologies as well. Some vendors supply RFID Web Services, which means you can use the eDeveloper V10 Web Services wizard. That’s even easier than dealing directly with PML or other forms of XML.
Occasionally, programming objects such as java objects or COM objects are provided, in which case eDeveloper can call and pass information to these objects. Keep in mind that Active RFID enables two-way data communication and write-many read-many (WMRM) storage with an RFID tag, whereas, generally speaking passive RFID is a write-once read many (WORM) technology. That means your eDeveloper applications need Active RFID if they are going to do any of the more sophisticated RFID applications.
Ways to Apply RFID Technology in eDeveloper Applications
Going back to Sue Hutchinson’s comment, RFID helps to answer the question: “where’s my stuff?” One way to determine this is to sense the immediate presence of an FID tag next to a reader. This approach works well, with say, tagged parts that are passing along an assembly line. The parts are always within range of the reader. Another example of good stationary reader approaches might be warehouse doors. Some work has even been done to create “smart shelves” that sense the RFID tag of products as they are pulled on or off the shelf. For these close proximity applications, passive RFID may be satisfactory.
But the real world does not always have these convenient thresholds.
One of the technologies developing around RFID are Real-Time Locating Systems (RLTS). These systems measure the wave properties of an RFID signal to determine the location of an RFID tag. The readers are generally placed in a grid and then tuned to a room or outdoor location. Since waves travel inconsistently through and around walls, etc., bandwidth is a consideration with RLTS. In cramped spaces, UWB is often preferred and it may offer energy saving advantages as well. Battery life in an RFID tag is another important consideration. Beacons that emit constant signals use more energy and have shorter battery life than systems that simply “chirp” at an established interval.
Software algorithms that calculate the location of a tag by comparing signal strengths on a grid of sensors are quite sophisticated. But they aren’t always accurate. Practical field applications show that errant readings are fairly common. When possible, a location should be calculated based on the average of several readings and not just a single reading. This approach leads to a great deal of accuracy.
RLTS can be used in applications such as worker safety systems. Companies like BP use active RFID in their employee badges so that if disaster strikes at a refinery or other hazardous work location, systems can be used to pinpoint the locations of workers and visitors. Needless to say, the RFID readers in these systems have to be “hardened” to withstand violent environmental conditions such as fire and explosion.
Another common use of RLTS is in asset management software systems. These often take on specialized use in various industries. Nurses need to know which room an IV cart or other mobile medical equipment was left in. Newspapers need to know where the paper stock rolls are in their automated factory. Truckyard operators need to know which spot particular trailers are located in, etc.
Glorified barcodes? Perhaps. But when was the last time a barcode could tell you whether the product it tagged has been kept at safe temperatures or automatically report its location? Sure we know we scanned it into inventory six months ago, but don’t ask us to actually find it in the store or warehouse.
