Many people don’t realize that RFID has been used in various applications for more than 60 years. The vast majority of these were closed loop applications using active tags (think big, relatively expensive, reusable tags). But now the theme is world-wide open ended applications of auto-id. Tagged products move across the end-to-end supply chain without the tags being returned to the source. Several enablers are needed to make this open ended vision work:
- very small, very inexpensive (i.e. disposable) tags. To keep the cost down, these usually carry a bare minimum of data, basically just an ID.
- the development of tag standards (data standards and air protocol standards) to allow a tag to work between various trading partners without a prior agreement on use of specific tags and readers from a specific vendor.
- the development of EPCglobal Network standards (ONS, EPC-IS, EPC-DS) for sharing product movement data across multiple trading partners.
When approaching RFID, many people focus first on trying to understanding the tags, readers, antennas—the obvious physical part. But if you are just able to read a tag—so what? All you have gotten is that bare minimum ID contained in the tag itself, which doesn’t tell you anything. You need a means to find the information associated with that tagged object. And often that information sits outside your company.
As goods traverse the supply chain from component supplier to manufacturer to distributor to retailer (and back for repairs or recycling), there are various parties that need to contribute information and obtain information about those goods. And simply sharing point-to-point with trading partners doesn’t cut it. It requires interoperability across the global network. This created the need for the EPCglobal Network. While it’s easy to get technical, the basic concepts are not that hard to understand, and over the long term have important business implications.
The RFID Vision
The vision of standards-based, open-ended RFID is simple enough. An RFID tag is attached to an object you want to track, such as an individual piece of merchandise (item), a case, or a pallet. Now this “tagged object” can be read at various points, as it traverses the supply chain. This gives you a series of information triplets, often referred to as “sightings” or “observations” of the movement of that object through the chain:
- This specific object was seen
- at this exact location (one of the read points)
- at this exact time.
Figure 1 illustrates an example of a supply chain, with the various read-points shown in the circles at some of the points where you might want to track the object.
Examples of RFID Read Points as a Tagged Object Flows Through a Supply Chain
It seems simple enough, until you start digging in and asking questions like:
- Exactly what information do tagged objects provide at each of these read points?
- How do I find information beyond what is in the tag of the object?
- How are these product movement events made visible to players in the supply chain?
Electronic Product Codes (EPC)
Let’s tackle this first question—what information does the tagged object provide to the readers at each of these read points? Before you skip over this “technical” section, note that the EPC represents the central organizing mechanism for the EPCglobal Network. In particular, if you want to understand ONS, you need to understand the concept behind the Manager Code, which is explained briefly in the forth paragraph below.
The information returned by a tag depends on the type of tag (for example some active tags attached to a shipping container hold the entire shipping manifest for the container). In this article we will focus on the EPC standard passive tags mandated by the major retailers, DoD, and others, since that is what ONS and EPC-IS were designed to support. When EPC tags are interrogated (a fancy word for “read”), they will return their unique Electronic Product Code, which consists of four components as shown in Figure 2:
Figure 2 - Format of EPC Number (96-bit version)
The first field of the EPC specifies the format of the number this tag is using. EPCglobal supports other formats in addition to the 96-bit format illustrated here, but this 96-bit format is the one expected by major retailers and accepted by the DoD and others.
The second field, Manager Code, is key to guaranteeing uniqueness and creating a distributed and scalable infrastructure. EPCglobal wants companies to manage their own EPCs, so they assign Manager Codes to organizations that want to create valid EPCs. By using one of the Manager Codes they’ve been assigned, a company can guarantee that the EPCs they create are globally unique—i.e. each tagged object will be the only object on the planet with that exact number (provided everyone else follows the rules). The manufacturer of the item will often, but not always, be the owner of the Manager Code for the tag, since they will be applying the tag. Exceptions to this may be when a third party or the retailer applies the tag.
The Object Class indicates what type of object has been tagged – for example a six-pack of 12 oz cans of Classic Coca Cola, with special packaging for Christmas 2006, designed for the Canadian market could have its own unique code.
The Serial Number is used to differentiate one tagged object from the next one coming off the production line, even though they are exactly identical products and packaging.
Those familiar with GTIN, used by the retailer industry, will notice that this flavor of EPC is basically a GTIN plus a serial number, also called a Serialized GTIN or SGTIN. The EPCglobal standard allows for other number formats such as SSCC for identifying shipping loads and GRAI for identifying reusable assets, as well as number formats from other industries besides retail, such as CAGE and DoDAAC codes used by the DoD.
ONS and EPC-IS: The path to enlightenment…
or at least to more information about tagged objects
OK, so a tagged object passing by an RFID reader will give you its EPC, essentially saying something like “I am 21.47C3A92.D23AC6.4DE7AE03C”. That number  alone doesn’t really tell you anything at all about the object. If you happen to be the organization that created that number, you can setup your own proprietary infrastructure to look up that EPC in your internal database and discover exactly what that object is. However, how does the rest of the world find out what that EPC means? This is where ONS and EPC-IS come in.
EPC-IS is a standard interface for obtaining additional information about an object if you know its EPC. Given the EPC from the tag, the EPC-IS returns information about that object. In actuality, there may be business logic and multiple databases behind the EPC-IS, as illustrated in figure 3. However, the Querying Application does not see nor care where the EPC-IS gets the data.
Figure 3 - Example Query to an EPC-IS interface
Notice that EPC-IS returns both core product and manufacturing time information. Core product information is things like the type of product and packaging associated with the class of Objects. Manufacturing time information is information like the date of manufacturing or batch number associated with a specific instance of an object, derived from its serial number. The Querying application can also “subscribe” to events about an object using the EPC-IS. For example, it could request to be notified when a particular case of products is loaded onto the truck at a particular facility.
The philosophy here is a distributed database. The data about objects like products, cases, and pallets is not to be contained in some centralized mega-database, but rather it is contained in individual EPC-IS instances. Who better to manage the public interface (EPC-IS) to this type of data about products, shipments, etc. than the manufacturer or other similar party that is already doing all the work of creating and managing that data in their systems?
Why you need ONS
Now imagine that you are a retailer with millions of items, cases, and pallets flowing through your DCs, from thousands of different suppliers. You want to find the data for each of those tagged items or cases or pallets. But for those objects, the data is spread out across thousands of different EPC-IS databases, distributed around the world. How does the retailer locate the EPC-IS interface for each of those items? That is exactly the purpose of ONS.
The ONS mechanism is very simple. You give it the EPC (or the Manager Code within the EPC) and ONS passes back to you the URL that points to the EPC-IS repository for that object.
Figure 4 - Using ONS to Find the EPC-IS
Once you have the URL for the EPC-IS, you can get information about the object, as we saw earlier in Figure 3. The ONS can also be used to get other URLs for an object. For example, the ONS could potentially give you the URL of the human readable website for technical support and download of user manuals for the product.
EPC-DS: The key to a Federated Model
Of course the manufacturer is not the only one recording events about the movement of a tagged object as it travels through the supply chain. Product lifecycle events including “sightings” (“this object was seen at this location at this time”), environmental events (e.g. “this case of frozen food was exposed to above freezing temperature from time X to time Y”), and other events are recorded by many players, including transportation carriers, third party logistics providers, consolidators and deconsolidators, the retailer, and potentially many other supply chain participants. In other words, many players (besides the owner of the Manager’s Code for the EPC) need to add to the dynamic lifecycle data about the object as it progresses across the chain.
Lifecycle Data Created by Many Players Across the Chain
This creates the need for a truly distributed database about the lifecycle of an object as it moves through the supply chain. Recall that the ONS only provides a pointer to the EPC-IS for a single company—the owner of the Manager Code, usually the manufacturer. So how do you find all the other lifecycle information created by all the other various organizations handling that object as it traverses the supply chain?
That is the purpose of the EPC Discovery Services (EPC-DS). For each manager code, there will be an EPC-DS to keep track of the events throughout the lifecycle of objects using that manager code. As organizations record events about an object throughout its lifecycle, they notify the EPC Discovery Services for the manager of that object about the existence of the event. For example, if an object is picked from the DC of the Retailer, and it wanted to make that event visible to the other players in the chain, it would notify the manager of the EPC-DS for that object, which in the example below is the manufacturer of that object.
[Note: The EPC-DS is still being defined. The description in this article illustrates one possible approach to solving the problem and is intended to help convey some understanding of how EPC-DS could work, rather than to be a definitive statement. In the end, EPCglobal will define the architecture of the EPC-DS, which may differ from what is described here.]
Example of Supply Chain Participant notifying owner of the Manager Code of a new event about the object
Note again the highly distributed architecture. Information about events is stored by the supply chain player who is already managing those events and information. In this scenario, the EPC-DS merely records a pointer back to the event information.
The architecture of the ONS, EPC-IS, and EPC-DS is illustrated in Figure 7 below. It can be viewed as a three level architecture:
- The Root ONS is used to find the owner of the Manager Code for the object— usually the manufacturer.
- The Local ONS is used to find the local information under control of that manufacturer. These include the EPC-IS interfaces for Core Product information and Manufacturing Time information (batch number, etc.) and the EPC-DS.
- The EPC-DS is used to find all the lifecycle events for the object, which have been recorded throughout the supply chain, including events generated and stored by the manufacturer (e.g. product shipped, product returned, etc.). As noted earlier, this component is still being defined, and may end up looking different than what is illustrated here.
Figure 7 - Architecture of EPC Data Networks
This architecture achieves scalability by distributing the responsibility for storing and managing information to each organization that is already (or at least should be) generating, storing, and managing that information.
Putting it all in Context
When we talk about creating a “single version of the truth” between companies, the EPC network alone is not enough, because there is a need for sharing and synchronizing many kinds of other data such as location data, forecasts, schedules, project plans, product designs, business documents, etc. This will involve many other networks and sharing mechanisms, some of which will be integrated with the EPC network. For example, the GDS network (Global Data Synchronization, standards defined by UCCNet) and EPC networks are complementary. Figure 8 illustrates this relationship. Understanding the relationship between GDS and EPC networks is a deep enough subject for another whole article.
Source: An Integrated View of the GDS and EPCglobal Networks, Published by IBM and GCI
Figure 8 - Relationship between GDS and EPCglobal Networks
Where we’re at
We are very early in the actual implementation of EPCglobal Networks. Most companies are still struggling with the very basics of RFID, such as getting acceptable read rates from RFID tags throughout the end-to-end supply chain processes, dealing with mixed mode operations (RFID + non-RFID products and processes), developing new procedures, and getting employees to comply with them. To those in the heat of battle, the implementation of an end-to-end data sharing network must seem like a faraway dream indeed.
And there is still considerable standards development work needed. The EPC-DS is still being defined. There is a vital need for standards for the security infrastructure. Nobody is going to start sharing this kind of confidential data until they are certain that only authorized people within their trading partners can access it. To be scalable, this requires security standards that are still to be developed for the EPCglobal Network.
Where to go from here
For the time being, companies are taking a point-to-point approach to sharing data. They are sharing EPC data and events directly between trading partners, not unlike the way major retailers share POS data directly with their suppliers today. That approach will only take us so far. The point-to-point approach will become prohibitively expensive and unmanageable as we try to incorporate more and more players and intermediaries across the end-to-end supply chain. That is the whole reason that so much effort has been put into defining a highly scalable architecture and approach like the EPCglobal Network. Adoption of a scalable approach is the only way to take supply chains to this next level.
The potential of such end-to-end networks is too great to ignore. It will create truly instrumented global supply chains with fine-grained, real-time visibility. This is tremendously powerful, enabling:
- new levels of business intelligence and analytics
- deep and precise understanding of supply chain flows
- a whole new level of precision, speed, and synchronization
- early warning systems to mitigate issues
- autonomic processes with inherent intelligence and independent decision-making built into the infrastructure, reducing the need for human intervention
- deeper understanding of customer behavior, needs, and wants
Because of this, leading supply chain players are already building strategies for using the EPCglobal Network and are starting to experiment with the technology. They realize that this is a chance to get ahead of the pack. For logistics providers and network infrastructure providers, there is opportunity to offer differentiated services. And precisely because implementing this is not easy, major retailers and manufacturers who can get there first will create a strong competitive advantage in performance, and ultimately in serving the customer better.
 The EPC number here is represented in “hex” or base 16. The letters A, B, C, D, E, and F therefore represent the numbers 10,11, 12, 13, 14, and 15 respectively, so even though you see letters in this representation, the EPC is actually strictly numerical.