Oct 12, 2006In late summer 2006, EPCglobal completed its testing of prototypical software based on the EPC Information Services (EPCIS) specification. This set of protocols was designed to let end users of RFID technology exchange data with their supply-chain partners regarding the movement of EPC-tagged goods. The tests were an important step toward the ratification of the EPCIS specification as an EPC data standard. The specification is currently a candidate standard.
The specific goal of the tests was to ensure that different software products built on the candidate standard could interoperate, and that the specification was interpreted—and interpretable—in a consistent manner by all parties involved. To be an effective data standard, all software built on that standard needs to interpret each part of the specification consistently, so that if company A requests RFID read-event data from company B, the latter's EPCIS layer of software will easily recognize the request and reply to it in a standard data format.
"We invited every willing party from the EPCglobal community to join us," says Craig Asher, IBM software group product manager and cochair of the EPCglobal EPCIS working group, which developed the specification and conducted the testing. In addition to IBM, 11 other organizations attended the testing sessions: Auto-ID Labs Cambridge (which also hosted the tests), Avicon, BEA Systems, Bent Systems, GlobeRanger, Internet Initiative Japan (IIJ), NEC, Oracle, Polaris Networks, Samsung and T3Ci.
Eight of the above 12 companies submitted EPCIS-based software to the tests, while representatives from the other four observed the presentations, contributed comments and asked questions. Asher declined to reveal which companies entered their software, but IBM and a number of other companies involved in the tests, including BEA Systems, have released EPCIS software based on the current EPCIS candidate standard.
During the tests, the eight participants paired off and simulated real-world events that would exploit both the data-query and data-capture functions of the EPCIS software. "For example," says Asher, "one company would play the role of a manufacturer, and another would act as a distributor." They would request and exchange data pursuant to the EPCIS protocols, then switch roles and test the same queries and responses.
Asher says all issues found during testing sessions—or, in some cases, ambiguities in how the specification reads—have since been resolved, expect for one. He expects that final problem to be ironed out by next week. "None of the issues were big show-stoppers," says Ken Traub, chief technology officer for RFID and edge servers at BEA Systems, and the lead editor of the EPCIS specification.
Traub says he was surprised by the number of prototypical software products submitted for the testing sessions, adding that it's a good sign for end users of RFID since it shows there will likely be more than a few EPCIS-standardized software products on the market to choose from.
According to Asher, the EPCIS working group's next step, once the final interoperability glitch is worked out, is to revise the candidate standard and hold a vote to make it a proposed standard. Once it reaches this milestone, the group will seek approval from several technical and business committees within EPCglobal before sending it on to the board of governors for ratification as a standard. EPCglobal expects the board to ratify the standard by year's end.
Another important and related initiative, Asher says, is being addressed by a joint requirements group EPCglobal convened to develop requirements and guidelines for a specification that would provide a common vocabulary of business terms for all industries using the EPCglobal network. Having members use consistent business terms—whether in the fast-moving consumer goods, health-care/pharmaceutical or transportation and logistics industries—will facilitate pan-industry use of the EPCIS platform, he explains. Currently, companies in separate industries sometimes use different terminology for common business processes, such as shipping and receiving.
"To truly facilitate a cross-industry specification, we need a standard vocabulary," Asher notes. "We are actively working on the vocabulary, and we are all pushing forward on that."
