EPCglobal is a joint venture between GS1 (formerly known as EAN International) and GS1 US (formerly the Uniform Code Council, Inc.). It is an organization set up to achieve worldwide adoption and standardization of Electronic Product Code (EPC) technology.
The main focus of the group currently is to create both a worldwide standard for RFID and the use of the Internet to share data via the EPCglobal Network.
EPCglobal's board of governors includes representatives from EPCglobal, GS1, Auto-ID Labs, Cisco Systems, DHL/Exel Supply Chain, Haier Group Company, Johnson & Johnson, Kimberly-Clark Corporation, LG Electronics, Lockheed Martin Corporation, METRO AG, Novartis Pharma AG, Office of the Secretary of Defense, Procter & Gamble, Sony Corporation, The Dow Chemical Company and Wal-Mart Stores, Inc.
Contents |
EPCglobal was formed in October, 2003 as the successor organization to the MIT Auto-ID Center, the original creator of the EPC technology. EPCglobal manages the EPC network and standards, while its sister organization, Auto-ID Labs, manages and funds research on the EPC technology.
EPC Information Services (EPCIS) is an EPCglobal standard designed to enable EPC-related data sharing within and across enterprises. This data sharing is aimed at enabling participants in the EPCglobal Network to obtain a common view of the disposition of EPC-bearing objects within a business context. The initial version of the EPCIS standard was ratified on April 12, 2007 and provided basic capability that meets the requirements of a set of use cases that the EPCglobal community identified as a minimal useful set. As such, the EPCIS standard can be used by any application in any industry. However, the standard supports extensibility so end users and industry groups can address specific application and industry use cases through industry and custom extensions or companion specifications.
The EPCIS standard defines standard interfaces to enable EPC-related data to be captured and subsequently to be queried using a set of service operations and an associated data model. The capture and query of EPC-related data will typically involve the use of persistent databases, though application-to-application sharing can occur without persistent databases. The standard specifies only the interfaces between applications that capture EPC-related data and those that need access to it. It does not specify how the service operations or databases themselves should be implemented. The interfaces enable interoperability while the implementations allow for competition.
EPCIS differs from elements at the lower layers of the EPCglobal Architecture in three key respects:
The EPCglobal Architecture defines and includes a list of EPC-related roles and standards.
EPCIS Interfaces: There are three EPCIS Interfaces. The EPCIS Capture Interface defines the delivery of EPCIS events from EPCIS Capturing Applications to EPCIS Repositories and to EPCIS Accessing Applications and trading partners via a real-time push. The EPCIS Query Control Interface defines operations that EPCIS Accessing Applications and trading partners can use to obtain EPCIS data subsequent to capture. The EPCIS Query Control Interface provides two modes of interaction. In “on-demand” or “synchronous” mode, a client makes a request through the EPCIS Query Control Interface and receives a response immediately. In “standing request” or “asynchronous” mode, a client establishes a subscription for a periodic query. Each time the periodic query is executed, the results are delivered asynchronously to a recipient via the EPCIS Query Callback Interface. The EPCIS Query Callback Interface may also be used to deliver information immediately upon capture.
There are two kinds of EPCIS data: event data and master data. Event data is created in the process of carrying out business processes, and is captured through the EPCIS Capture Interface and made available for query through the EPCIS Query Interfaces. Master data is additional data that provides the necessary context for interpreting the event data. It is available for query through the EPCIS Query Control Interface, but the means by which master data enters the system is not specified in the 1.0 specification.
The standard defines the structure of meaning of event and master data through an Abstract Data Model, a Data Definition Layer and a Core Event Types module. The Core Event Types module specifies the events that are created by EPCIS Capturing Applications and published to an EPCIS infrastructure using the EPCIS Capture Interface described above. These events are returned to EPCIS Accessing Applications in response to requests invoked through the EPCIS Query Control Interface or in response to standing requests made by an EPCIS Accessing Application. The five event types defined within the Core Event Types module are:
Reader Protocol (RP) is an interface standard specifying the interactions between a device capable of reading/writing tags and application software. The informal summary of the charter was "Define an interface supporting Reading, Writing and Killing tags, and the supporting operations necessary for those actions." The goal was to define an open and extensible interface that reader vendors could embrace supporting most operations in a standard (common) way, yet not dictate implementation nor preclude vendor extension and innovation.
Version 1.1 was ratified and made publicly available in August, 2006. Notable features include commands to read, write and kill tags, access to 'User Memory' as well as identity information, extensive configuration-related commands, rich reporting options, asynchronous notifications, multiple Message Transport Bindings (MTBs) including serial, TCP and HTTP transports and XML and Text message formats, ReadPoints and Sources (originally dubbed 'Virtual Reader') and rich extensibility mechanisms.
There is no version 1.0. A very early draft of the work-in-progress specification was released on the internet with the moniker "1.0", but the document was a very early file (mostly template) that didn't include most of the design points even at that time, let alone later additions and refinements. The document itself is clearly a very early and incomplete document, as obvious to even a casual review. The workgroup opted to change the version number to 1.1 to avoid confusion with this document, and to reflect the significant advances since the earlier work.