back



  
 
Overview of EPCglobal Architecture
 

EPCIS sits at the highest level of the EPCglobal Architecture Framework, both above the level of raw EPC observations (e.g., Tag Protocol and Reader Protocol), as well as above the level of filtered, consolidated observations (e.g., Filtering & Collection Interface).

In the diagram, the plain green bars denote interfaces governed by EPCglobal standards, while the blue shadowed boxes denote roles played by hardware and/or software components of the system.

A single physical software or hardware component may play more than one role. For example, a “smart reader” may perform middleware functions and expose the ALE interface as its external interface. In that case, the reader is playing both the Reader and Middleware role in the diagram, and the Reader Protocol Interface is internal to the smart reader (if it exists at all). Likewise, it is common to have enterprise applications such as Warehouse Management Systems that simultaneously play the role of EPCIS Capturing Application (e.g. detecting EPCs during product movement during truck loading), an EPCIS-enabled Repository (e.g. recording case-to-pallet associations), and an EPCIS Accessing Application (e.g. carrying out business decisions based on EPCIS-level data).


Overview of the EPC Architecture Framework: EPCIS and other EPC Standards
While EPCIS is an integral part of the EPCglobal Network, it differs from elements at the lower layers of the Architecture in three key respects:

  1. EPCIS deals explicitly with historical data (in addition to current data). The lower layers of the stack, in contrast, are oriented exclusively towards real-time processing of EPC data.

  2. EPCIS often deals not just with raw EPC observations, but also in contexts that imbue those observations with meaning relative to the physical world and to specific steps in operational or analytical business processes. The lower layers of the stack are more purely observational in nature. An EPCIS-level event, while containing much of the same EPC data as a Filtering & Collection event, is at a semantically higher level because it incorporates an understanding of the business context in which the EPC data were obtained. Moreover, there is no requirement that an EPCIS event be directly related to a specific physical tag observation. For example, an EPCIS Quantity Event contains information that may be generated purely by software, such as an inventory application.

  3. EPCIS operates within enterprise IT environments at a level that is much more diverse and multi-faceted than the lower levels of the EPCglobal Network Architecture. In part, and most importantly, this is due to the desire to share EPCIS data between enterprises which are likely to have different solutions deployed to perform similar tasks. In part, it is also due to the persistent nature of EPCIS data. And lastly, it is due to EPCIS being at the highest level of the EPCglobal Network Architecture, and hence the natural point of entry into other enterprise systems, which vary widely from one enterprise to the next (or even within parts of the same enterprise).
The responsibilities of each element of the EPCglobal Architecture Framework are outlined as follows:
Readers
Make multiple observations of RFID tags while they are in the read zone.

Reader Protocol Interface
Defines the control and delivery of raw tag reads from Readers to the Filtering & Collection role. Events at this interface say “Reader A saw EPC X at time T.”

Filtering & Collection
This role filters and collects raw tag reads, over time intervals delimited by events defined by the EPCIS Capturing Application (e.g. tripping a motion detector).

Filtering & Collection (ALE) Interface
Defines the control and delivery of filtered and collected tag read data from the Filtering & Collection role to the EPCIS Capturing Application role. Events at this interface say “At Logical Reader L, between time T1 and T2, the following EPCs were observed,” where the list of EPCs has no duplicates and has been filtered by criteria defined by the EPCIS Capturing Application.

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 step of a business process. The EPCIS Capturing Application may, for example, coordinate a conveyor system with Filtering & Collection events, may check for exceptional conditions and take corrective action (e.g., diverting a bad case into a rework area), may present information to a human operator, and so on.

EPCIS Interfaces
The interfaces through which EPCIS data is delivered to enterprise-level roles, including EPCIS Repositories, EPCIS Accessing Applications, and data exchange with partners. Events at these interfaces say, for example, “At location X, at time T, the following contained objects (cases) were verified as being aggregated to the following containing object (pallet).”

EPCIS Accessing Application
Responsible for carrying out overall enterprise business processes, such as warehouse management, shipping and receiving, historical throughput analysis, and so forth, aided by EPC-related data.

EPCIS-enabled Repository
Records EPCIS-level events generated by one or more EPCIS Capturing Applications, and makes them available for later query by EPCIS Accessing Applications.

Partner Application
Trading Partner systems that perform the same role as an EPCIS Accessing Application, though from outside the responding party’s network. Partner Applications may be granted access to a subset of the information that is available from an EPCIS Capturing Application or within an EPCIS Repository.

ONS
Network service that is used to look up pointers to EPCIS Repositories, starting from an EPC Manager Number or full Electronic Product Code. Specifically, ONS provides a means to look up a pointer to the EPCIS service provided by the organization who commissioned the EPC of the object in question. The most common example is where ONS is used to discover an EPCIS service that contains product data from a manufacturer for a given EPC.

Discovery Capability
A mechanism, currently under development, for locating all EPCIS-enabled Repositories that might have data about a particular EPC. This is useful when the relevant EPCIS services might not otherwise be known to the party who wishes to query them, such as when the handling history of an object is desired but not known (e.g. in support of track-and-trace across a multi-party supply chain).

The interfaces within this stack are designed to insulate the higher levels of the stack from unnecessary details of how the lower levels are implemented.

- back -



 
Date Of Publication: 01.04.2008
  Copyright © GS1 Germany 2008. All rights reserved Optimised for 1024 x 768 pixel