May 12, 2013Your RFID project has been green-lighted. You know where you're going to deploy the technology and what benefits you hope to achieve. The next step is for your systems integrator or in-house development team to create a solid design document. It's as essential to your project as a blueprint is to a new home construction. Often these documents focus on the hardware. But to ensure your company will gain from the RFID data your new system collects, the design document must also address the following software issues.
Decide what data will be programmed into the tags. Some tags carry just a unique identifier, while others include a section for user memory that can be programmed with passwords or store data about tag reads for asset tracking, maintenance records or other uses. The identifier could be a random code programmed by the tag manufacturer or a standard, such as an airline industry baggage code, library item identifier or Electronic Product Code. If it's an EPC, will you use a Serialized Global Trade Item Number (SGTIN), Global Individual Asset Identifier (GIAI) or another variation? If you are encoding the tags yourself, the design should include a software component that assigns unique IDs and tracks available numbers in a database.
Keep track of all software components with a block diagram. The block diagram should include all components at the business level, such as enterprise resource planning, warehouse management and inventory systems, as well as reporting dashboards. Also include any components deployed in the field, such as middleware and software embedded in mobile and fixed readers.
Define each interface between the block diagram components. This will ensure you are collecting all the data needed to support your business goals. Make sure these interfaces can support changes as your business evolves. Can data elements be added without disrupting operations? Each interface should be extensible via a documented mechanism.
Also be sure the data flowing in each part of the block diagram is appropriate for that layer. Close to the readers, the data may be low-level and designed to exploit a particular tag hardware feature or reader command. Closer to the enterprise applications, the information should become more independent of the data-capture technology. A good test is to ask if a change in data-capture technology would imply a big change to the information at the enterprise level. If so, it's a sign that the software design is not layered properly.
Consider standards. They can make your design more resilient to changes in requirements and allow you to choose hardware and software from different vendors. Relevant standards include the Low Level Reader Protocol (LLRP) to talk to your readers, Application Level Events (ALE) to bridge readers to data-capture business logic, and EPC Information Services (EPCIS) to bring events to the enterprise in a technology-independent way.
Ken Traub is the founder of Ken Traub Consulting, a Mass.-based firm providing services to software product companies and enterprises that rely on advanced software technology to run their businesses. Send your software questions to swsavvy@kentraub.com.
