Distributed Information & Automation Laboratory

EPC Information Service

Introduction

The EPC Information Service [EPCIS] is a specification for a standard interface for accessing EPC-related information. Because an Electronic Product Code (EPC) gives each object a unique serial number, each individual object can be tracked independently and fine-grained real-time information about each individual object can be collected, stored and acted upon. EPC Information Services are a way for supply chain partners to share and exchange information efficiently, because a standard interface allows trading partners to use the same functions or methods for querying data across the supply chain, leading to reduced times integrating with partners if everyone uses the same interface, even though they may store the information in different types of underlying databases.

EPC Information Services are very different from the Global Data Synchronization Network [GDSN] (i.e. UCCNet, Transora, WWRE etc.). Whereas GDSN is primarily concerned with synchronization of class-level (SKU-level) master data about products, EPCIS is primarily concerned with sharing of serial-level data. EPC Information Services also have a much more distributed architecture - there is no ‘central provider’ with EPCIS. EPC Information Service is just a technical specification for a data communication interface, a bit like HTTP, TCP/IP or USB / Firewire (IEEE 1394, i-Link). It is not a centrally managed subscription-only service hosted by EPCglobal.

EPC Information Services are being designed to support both on-demand polling access and a ‘push’ model supporting standing queries. Depending on how the security for each individual EPCIS implementation is configured, you might be granted the right to define your own standing queries – or you might only have the option of ‘subscribing’ to an existing query which was pre-defined by the owner or provider of a particular EPCIS service.

EPC-related Data falls into two broad categories:

1. timestamped event data collected throughout the lifecycle of an object
   e.g. Observations (low-level tag readings), Measurements (sensor data, e.g. temperature history), Containment History, Higher-level Location History, Associations with Business Transactions.
2. quasi-static attributed data defined at serial-level but not continuously updated
   e.g. Date of Manufacture, Date of Expiry, Custom Configuration etc.

EPCIS Interface specification

The EPCIS work group within the EPCglobal Software Action Group are currently writing a technical specification for the EPC Information Service interface. There are representatives of end-users (Proctor & Gamble, Albertsons, Wal-Mart, Gillette etc.) and a number of technology solution providers. The end-users are driving the requirements - and the technology solution providers (and members of Auto-ID Labs) are thinking through the technical implications.

The EPCIS interface specification is specifically intended to not favour any particular choice of:

• Underlying database (whether relational/SQL, object-based or document-based/XML)
• Underlying operating system (Windows, Mac OS, Unix, Linux, other)
• Programming language (Java, C#, .NET, etc.)
• Integration with a particular vendor’s legacy information systems

The EPC Information Service lies at the top layer of the EPC Network technology stack, as shown in Figure 1.

Figure 1: The EPC Network (2005)

EPCIS is the first layer where business logic can be mixed with read ‘events’ coming from RFID readers. All the layers underneath EPCIS (e.g. Filtering & Collection [ALE], Reader Protocol etc.) are primarily concerned with simple triples of data (Reader, Tag EPC, timestamp). EPCIS allows for higher-level meanings to be stored or accessed, involving business processes and business transactions.
i.e. Shipment #XXX corresponding to P.O. # YYY arrived at time #ZZZ
rather than just (EPCs 123, 456, 789 seen at Reader 842 at time #ZZZ)
The EPC Information Service work group is aiming to complete the Last Call Working Draft for EPCIS v1.0 by Q2/2005. The reviews by the whole Software Action Group community as well as IP reviews and testing of implementability / interoperability will then take around 6 months.
EPCglobal are hoping to publish EPCIS v1.0 as a specification by the end of 2005.

The EPC Information Service Specification will specify the standard interfaces for:

• Query (getting data from an EPCIS)
• Capture (putting data into an EPCIS)

Implementing EPCIS

In terms of implementing an EPC Information Service, you can choose to either host your own EPCIS interface coupled to your existing databases for serial level data or subscribe to a technology solution provider hosting a managed EPCIS service.
If you are a manufacturer, your trading partners will probably be able to find your EPCIS by using the Object Name Service (ONS), doing a lookup based on the EPC of your products. However, if you are a distributor or retailer, it is much less likely that ONS will also point to your EPC Information Services. The reason is that ONS uses DNS technology, which although very robust and mature (it powers the internet), is not well-suited for real-time dynamic updates - nor is DNS particularly secure, whereas flows of goods (at serial-level) are sensitive data.

Instead, serial-level pointers can be stored securely within registries called Discovery Services. Discovery Service registries can be updated by each custodian on handover, with serial-level EPC lookup.

The sophistication of the query language provided via EPCIS is related to the issue of ‘throttling’ the amount of data which is retrieved and transmitted - in a way which may at first seem counter-intuitive. Suppose you have three sets of data…

• An observation history of which tagged objects have been read by which readers, when

• Serial-level attribute data - e.g. about the size or colour of a particular object - or its use-by date

• Master data about locations of readers within a store or distribution centre

In a retail store, you might want to ask where is a particular clothing item in a particular size and colour - and want it to flash a light on a map on a browser screen. You actually only want to know a set of reader locations (x,y) but you need to consider subsets and intersections of these data sets.

If you are limited to a very simple (inflexible) query mechanism, the application needs to retrieve all three sets of data and work out the intersections. That’s a lot of data to send! If instead, you support a more sophisticated query mechanism where you can include multiple constraints simultaneously, then you can send just a much smaller quantity of data.

However, there are some potential problems with supporting totally arbitrary queries - but generally, the reduction in the amount of data which needs to be sent to the application/client greatly outweighs the slight increase in processing time/power needed to filter on several constraints simultaneously. It’s the logical ‘NOT’ combinations which can be problematic.

EPCIS will initially only handle simple queries which it can answer directly, from the databases / applications to which it is locally connected. It is the role of applications to co-ordinate multiple queries to multiple EPCIS services, in order to manage complex queries.

References

Mark Harrison, EPC Information Service - Data Model and Queries, Auto-ID White paper, Oct 2003.

Learn more...

For further details about EPCIS, please write to Mark Harrison at mgh12eng.cam.ac.uk