EPC: Components  (Part 2 of a series)

Read Part 1

Note: This article was written prior to the announcement that EAN.UCC had finalized an agreement to develop commercial applications of EPC. Information available at the time was used as the basis for this article.

EPC Components

The basic components of EPC are:

• technology specifications (e.g., frequency, reader/tag communications, capacity)
• object naming convention (vendor and product identification)
• data content
• data structure

Again, there's nothing particularly new here. Every application standard must (and does) include these elements. Where the EPC concept is somewhat different, however, is in the integration of three additional components:

• object name repository
• physical markup language
• data handling software utilities

Although under development, these three components are not yet fully in place. Even the basic components of EPC are continuing to evolve. For example, the object name (vendor and item ID) has recently been increased from a 96-bit to a 128-bit code. Thus it's safe to say that no company today can truly implement EPC.

Object Name Repository

In order to ensure that current data is available for all items marked with EPC -- even for object names not in the recipient's data base -- the EPC concept proposes the establishment of an Internet-based repository of all object names.

As proposed, the repository would be comprised of thousands of individual vendors' databases, each containing files only of its own products. A network directory, similar to the Domain Naming Service (DNS) would point all queries to the appropriate database. 

Whether companies access the object name repository periodically, to check for updated data, or on an as-needed basis, to add new items to their database, the repository would ensure that data on every item identified by EPC would be accessible to all interested parties at all times. This would help maintain the data integrity of companies' information systems.

The concept of a repository isn't particularly new, nor are any of the benefits noted above breaking new ground. For example, EAN product codes for many countries are available via the web. Book identification codes (International Standard Book Number -- ISBN) are available via the web, distributor or publisher databases.

The significant difference between those systems and EPC is that the Auto-ID Center proposes developing software to automate lookup of object names (see below) as part of the overall EPC program.

Physical Markup Language (PML)

In order to make a web-based repository useful, companies must be able to easily access and understand product data stored on a vast array of remote servers. PML, based on eXtensible Markup Language (XML), is intended to provide a universal language structure to identify both static and dynamic data about any conceivable item.

In much the same way that HTML and XML are continually expanded and enhanced, the Auto-ID Center envisions that PML will continually evolve to meet new needs.

Insofar as ePC is envisioned for use across the entire range of raw materials and finished goods, the possible types of item attributes and descriptive data is immense.

Because of the scope and complexity of defining these attributes, most existing coding standards (such as MH10.8 Data Identifiers and EAN.UCC Application Identifiers) have relied on widely-accepted standards developed by ANSI, EDIFACT, CEN, ISO and other high-level standards bodies.

Incorporating existing standards would simplify adoption by users who have already implemented information systems based on internationally-recognized standards. Any new language or methodology that does not allow their use runs the risk of being dismissed by the user community.

Current indications are, however, that the Auto-ID Center is focused on developing an entirely new language and descriptors.

Data Management Software

One of the challenges facing companies who want to adopt EPC is data management. Faced with a potential flood of data from individual items, decisions must be made about how to handle it.

What data should be routed internally -- and to which department(s)? What data should be communicated to which trading partners? What data should be ignored in a particular location?

Typically, developing the means to address these issues have been left to each individual company.

This is where EPC is truly different.

The Auto-ID Center is developing a series of software utilities that could be configured to meet the needs of each location within an application. One utility might parse (or "smooth") the data read from each tag and decide how to handle it. Another might route it to the appropriate internal or external database(s) -- whether at the supplier, carrier, customer or retail store -- or pass on only dynamic data that has changed since the last time the tag was interrogated.

For example, one utility might check the object name repository to update or validate product data on a periodic basis. Another utility might communicate receiving data to accounts payable and inventory.

Each utility would be part of an overall data management strategy. They would interface not only with internal and external databases but would also interact with each other and might incorporate inputs from other sources, such as scales, temperature sensors and so forth.

Utilities would, in theory, operate automatically, either handling data management tasks transparently in the background or prompting a human operator to make a decision or take an action if necessary.

The concept of automating data management and communications is far from new. What is new is the development of a set of standard, open source utilities to accomplish it.

Regardless of whether item or pallet tracking is eventually implemented, the concept of developing a series of standard utilities to manage data capture and exchange is interesting.

Conclusion

As noted above, the Auto-ID Center is not the only organization promoting a holistic approach. Other organizations are also hard at work developing integrated approaches to item identification and data management. One such group is i3W, integrated item-intelligent World (www.i3w.info), sponsored by the Technology Innovation Center, a faculty of the University of Central England, Birmingham. i3W in some ways goes beyond the efforts of EPC by recognizing a full range of AIDC technologies -- from bar codes to smart cards -- and works to incorporate existing standards as part of its integrated item-intelligent world view.

It should also be recognized that AIM, its member companies and its partners in other sectors have, for years, advocated a holistic approach to item identification and data management based, in great part, on the principle that technologies should be used to complement each other, not compete against each other.

Nonetheless, irrespective of the sponsoring organization or specific terminology used, the general concepts being proposed by the Auto-ID Center are valuable discussion points in furthering an integrated (or holistic) approach to item identification and data management.

Because of the amount of publicity the Auto-ID Center has received, it's important to understand how EPC differs from -- and is similar to -- existing and developing item identification systems.

If nothing else, EPC has helped raise awareness of the potential of RFID among a much broader audience. Whether or not EPC is ever implemented, the increased awareness it has generated may be its most important result.