|
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).
|
|
|
 |
|
|
|
|
|
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:
- 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.
- 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.
- 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 - |
|
|
|
|
|
