EPCglobal

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, the United States Office of the Secretary of Defense, Procter & Gamble, Sony Corporation, The Dow Chemical Company and Wal-Mart Stores, Inc.

History

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.

EPCIS

Introduction

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.

Relationship to the EPCglobal Architecture Framework

EPCIS differs from elements at the lower layers of the EPCglobal Architecture in three key respects:

  1. EPCIS deals explicitly with historical data. The lower layers of the stack deal exclusively with real-time processing of EPC data.
  2. EPCIS often deals not just with raw EPC observations, but with observations that include meaning relative to the physical world and to specific business steps and business processes. The lower layers of the stack are purely observational in nature.
  3. EPCIS typically operates and exists in a more diverse IT environment than the lower levels of the EPCglobal Architecture. This is due to a combination of factors including the desire to share EPCIS data between enterprises that are likely to have different solutions, the persistent nature of EPCIS data, and to EPCIS being the natural point of entry into other enterprise systems.

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.

Event Data and Master Data

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:

Real world usage of EPCIS

EPCIS is used mainly in two ways. Either it serves as a layer for sharing and/or storing information in a supply chain. In the Norwegian food chain, EPCIS is used to collect the "breadcrumbs" of all the pallets travelling through the value chain with goods lying on top. [1]

The other way of using EPCIS is as an event infrastructure to build applications on top of, or around. By utilizing EPCIS standards, a world of different data capture solutions open up, ready to provide information to your solution more or less out of the box. Also information can in this way easily be shared among different systems, having EPCIS as the one and only real truth about the different objects floating around in the real world. This makes it an information hub. EPCIS may easily be used to record logistic information as well as lifecycle events and sensor data.

EPCIS solutions

There have been several implementations over the years since EPCIS was drafted, however, a shift away from client/server models toward cloud-based solutions has been underway recently.

Reader Protocol

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.

See also

References

  1. ↑ http://www.rfidjournal.com/articles/view?8137
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.