Jan 15, 2017I was recently asked to consult on a small RFID project for a nonprofit organization that had already researched radio frequency identification technologies and knew which tags and readers to use to address their business problem. On the software side, they felt they could save money by not purchasing middleware or hiring a systems integrator, especially since they already understood how to read tags using the software development kit (SDK) provided by their reader vendor, and how to build a user interface for their application.
But as is often the case when an IT organization builds an RFID application for the first time, they were tripped up by the database. More specifically, they were not sure exactly what data should be stored.
There are three kinds of data to think about. First and most important is the "event data"—that is, records stored every time you read or write to a tag. Each event should include the "what" (the ID numbers read from the tags), "when" (date and time), "where" (location) and "why" (other business context information).
In the "what" dimension, be sure to decode the tag's raw data. If you are tagging consumer products, for example, you will want to decode the tag data into a Global Trade Item Number (GTIN) and serial number. Other applications may use a different type of identifier. If your reader vendor's SDK doesn't do this, you'll need to license a software library that does so, or write it yourself.
The "when" is straightforward, but don't forget to capture the time zone.
For the "where" dimension, you'll need to decide how to identify locations. One way is to assign unique identifying codes to each location of interest—a code for each building, for example, or for each storage bin if you require greater granularity. The other way is to use a geolocation (latitude and longitude), provided your reader is capable. Most mobile phone-based readers will be able to do this.
Finally, the "why" dimension says what was happening business-wise. Were you reading the tag or writing to it? Were you creating a new tag, taking inventory, removing items from storage, putting them away, selling items or destroying them? The more completely you capture the business context, the more useful the data will be.
The second kind of data is "master data"—static data that your application needs to understand the event data. For example, RFID tags on products carry a product ID, and the master data maps each product ID to that item's name and description, as well as other business information. When you use codes to specify "where," master data maps the location codes in your events to an address or to latitude and longitude.
The third kind of data comes into play if your application creates unique serial numbers for tagged items. This information is updated by your application each time it creates a new number—the data records what serial numbers your application already assigned and what the next one is. It's critical to back up this data carefully so your application never assigns a duplicate code.
Now that you have a solid data design, document your software deployment design and you will be in good shape to adapt as your business requirements evolve. And be sure to ask the four questions before you start.
Ken Traub is the founder of Ken Traub Consulting, a Mass.-based firm providing services to companies that rely on advanced software technology to run their businesses. Send your software questions to swsavvy@kentraub.com.
