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, 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:
- EPCIS deals explicitly with historical data. The lower layers of the stack deal exclusively with real-time processing of EPC data.
- 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.
- 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 Capturing Application: Supervises the operation of the lower-level architectural elements and provides business context by coordinating with other sources of information involved in executing a particular business process step.
- EPCIS Accessing Application: Responsible for carrying out overall enterprise business processes aided by EPC-related data.
- EPCIS-enabled Repository: Records EPCIS-level events and makes them available for query by EPCIS Accessing Applications.
- Partner Application: Trading Partner systems that perform the same role as an EPCIS Accessing Application, but outside of the responding party’s network.
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:
- EPCISEvent: a base class for all event types.
- ObjectEvent: represents an event that happened to one or more entities denoted by EPCs.
- AggregationEvent: represents an event that happened to one or more entities denoted by EPCs that are physically aggregated together.
- QuantityEvent: represents an event concerned with a specific quantity of entities sharing a common EPC class, but where the individual identities of the entities are not specified.
- TransactionEvent: represents an event in which one or more entities denoted by EPCs become associated or disassociated with one or more identified business transactions.
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
- Application Level Events (ALE)
- LLRP