ISO/IEC 19987:2024

International
Standard
ISO/IEC 19987
Third edition
Information technology — EPC
2024-03
Information Services (EPCIS)
Technologies de l'information — Services d'information sur les
codes de produit électronique
Reference number
© ISO/IEC 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2024 – All rights reserved
ii
Foreword
ISO (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardization.
National bodies that are members of ISO or IEC participate in the development of International
Standards through technical committees established by the respective organization to deal
with particular fields of technical activity. ISO and IEC technical committees collaborate in
fields of mutual interest. Other international organizations, governmental and non-
governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of document should be noted (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may
involve the use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity
or applicability of any claimed patent rights in respect thereof. As of the date of publication of
this document, ISO and IEC had not received notice of (a) patent(s) which may be required to
implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at
www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and
does not constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT),
see www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by GS1 (as EPCIS Standard, Release 2.0) and drafted in
accordance with its editorial rules. It was adopted, under the JTC 1 PAS procedure, by Joint
Technical Committee ISO/IEC JTC 1, Information technology.
This third edition cancels and replaces the second edition (ISO/IEC 19987:2017), which has
been technically revised.
The main changes are as follows:
— addition of JSON/SON-LD syntax (alongside XML);
— addition of REST bindings (alongside SOAP/WSDL);
— complete overhaul of UML diagrams;
— clarification on distinction between standard vocabulary and user vocabulary;
— new AssociationEvent;
— new “How” event dimension;
— overview of EPCIS even “dimensions” with cross-references to relevant sections in EPCIS
(this document) and CBV (ISO/IEC 19988);
© ISO/IEC 2024 – All rights reserved
iii
— new Persistent Disposition indicating non-transient business state of an object;
— new SensorElement to accommodate sensor data;
— addition of certificationInfo to core EPCISEvent;
— update of SimpleEventQuery parameters;
— removal of support for Simple Master Data Query and EPCIS Master Data Document.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
© ISO/IEC 2024 – All rights reserved
iv
EPCIS Standard
Table of Contents
1 Introduction . 1
2 Relationship to the GS1 System Architecture . 2
2.1 Overview of GS1 standards . 2
2.2 EPCIS in relation to the “Capture” and “Share” layers . 3
2.3 EPCIS in Relation to trading partners . 4
2.4 EPCIS in relation to other GS1 System Architecture components . 5
3 EPCIS specification principles . 8
4 Terminology and typographical conventions . 9
5 EPCIS specification framework . 10
5.1 Layers .1 0
5.2 Extensibility .1 1
5.3 Modularity . 11
6 Abstract data model layer . 13
6.1 Event data and master data . 13
6.1.1 Transmission of master data in EPCIS . 15
6.2 Standard vocabulary and user vocabulary . 15
6.3 Extension mechanisms . 17
6.4 Identifier representation . 18
6.5 Hierarchical vocabularies . 19
7 Data definition layer . 20
7.1 General rules for specifying data definition layer modules . 20
7.1.1 Content .2 0
7.1.2 Notation .2 1
7.1.3 Semantics .2 1
7.2 Core event types module – overview . 23
7.2.1 UML Diagrams of EPCIS Event Types . 24
7.2.2 Overview of EPCIS event "dimensions" (non-normative) . 25
7.2.3 Table of vocabulary types . 28
7.3 Core event types module – building blocks . 29
7.3.1 Primitive types .2 9
7.3.2 Action type .3 0
7.3.3 The “What” dimension . 31
7.3.4 The "When" dimension . 32
7.3.5 The “Where” Dimension – read point and business location . 33
7.3.6 The “Why” dimension . 36
7.3.7 The “How” dimension . 40
7.3.8 Instance/Lot master data (ILMD) . 47
7.4 Core event types module – events . 48
7.4.1 EPCISEvent .4 8
7.4.2 ObjectEvent (subclass of EPCISEvent) . 52
7.4.3 AggregationEvent (subclass of EPCISEvent) . 56
7.4.4 TransactionEvent (subclass of EPCISEvent) . 60
7.4.5 TransformationEvent (subclass of EPCISEvent) . 65
7.4.6 AssociationEvent (subclass of EPCISEvent) . 68
© ISO/IEC 2024 – All rights reserved
v
EPCIS Standard
8 Service Layer . 74
8.1 Core capture operations module . 76
8.1.1 Authentication and authorisation . 76
8.1.2 Capture service .7 7
8.2 Core Query operations module . 78
8.2.1 Authentication .7 8
8.2.2 Authorisation and redaction. 79
8.2.3 Queries for large amounts of data . 79
8.2.4 Overly complex queries . 80
8.2.5 Query framework (EPCIS query control interface) . 80
8.2.6 Error conditions .8 6
8.2.7 Predefined queries for EPCIS . 88
8.2.8 Query callback interface . 121
9 XML bindings for data definition modules . 122
9.1 Extensibility mechanism . 122
9.2 Standard business document header . 125
9.3 EPCglobal Base schema . 125
9.4 Master data in the XML binding . 126
9.5 Schema for core event types . 127
9.6 Core event types – examples (Non-Normative) . 128
10 JSON/JSON-LD bindings for data definition . 129
10.1 Brief introduction to JSON and JSON-LD in the context of EPCIS . 129
10.1.1 JavaScript Object Notation (JSON) . 130
10.1.2 JSON for Linked Data (JSON-LD) . 131
10.1.3 Features of the JSON-LD context resource . 132
10.1.4 Compact URI Expressions (CURIEs) . 133
10.2 Expression and validation of EPCIS data structures in JSON and JSON-LD . 134
10.2.1 Expressing data fields expecting simple values . 134
10.2.2 Validating data fields expecting simple values . 136
10.2.3 Validation of fields (e.g. 'action') that expect a string value from an
enumerated list . 138
10.2.4 Expressing simple lists of values . 139
10.2.5 Validating lists of values . 140
10.2.6 Expressing lists of elements with inline attributes expressing type . 140
10.2.7 Modelling and validating subclasses of EPCIS event . 143
10.2.8 Comparison of how validation rules are expressed in XSD, JSON Schema and
SHACL 144
10.2.9 Mapping core SBDH fields to the JSON/JSON-LD data format for EPCIS . 146
10.2.10 Online validation tools for JSON Schema and SHACL . 146
10.2.11 Libraries and toolkits providing JSON-LD support . 146
10.3 Validation schema (references to normative content) . 146
10.4 Non-normative examples in JSON and JSON-LD . 147
11 Bindings for core capture operations module . 147
11.1 Message queue binding . 147
11.2 HTTP binding . 148
12 REST Bindings . 149
12.1 Code conventions . 149
12.2 Introduction to REST . 149
© ISO/IEC 2024 – All rights reserved
vi
EPCIS Standard
12.3 Content negotiation, service discovery and custom headers for EPCIS . 151
12.4 Authentication and Authorization . 153
12.5 Pagination . 154
12.6 Capturing EPCIS Events . 154
12.6.1 Capture Interface . 155
12.6.2 Capture Jobs Interface . 156
12.7 Events interface. 157
12.7.1 EPCIS events collections . 157
12.7.2 EPCIS events endpoints . 157
12.7.3 Event filtering with the EPCIS query language . 158
12.7.4 Top-level resources . 159
12.8 Query control interface . 160
12.8.1 Creating and using named queries . 162
12.8.2 Deleting named queries . 162
12.8.3 Subscribing to named queries . 162
12.8.4 EPCIS query language . 167
12.8.5 EPCIS query in the URL . 168
12.9 Backward Compatibility of REST bindings with EPCIS 1.2 . 169
12.10 EPCIS Error Conditions and HTTP Status Code Mapping . 169
13 Bindings for core query operations module . 172
13.1 XML schema for core query operations module . 172
13.2 SOAP/HTTP binding for the query control interface . 173
13.3 AS2 Binding for the query control interface . 174
13.3.1 GS1 AS2 guidelines (Non-Normative) . 175
13.4 Bindings for query callback interface . 177
13.4.1 General Considerations for all XML-based bindings . 178
13.4.2 HTTP binding of the query callback interface . 178
13.4.3 HTTPS binding of the query callback interface . 179
13.4.4 AS2 Binding of the query callback interface . 179
14 Conformance . 180
14.1 Conformance of EPCIS XML data . 180
14.2 Conformance of EPCIS capture interface clients . 180
14.3 Conformance of EPCIS capture interface servers . 180
14.4 Conformance of EPCIS query interface clients . 181
14.5 Conformance of EPCIS query interface servers . 181
14.6 Conformance of EPCIS query callback interface implementations . 181
14.7 Conformance of JSON/JSON-LD bindings . 181
14.8 Conformance of REST Interface for EPCIS 2.0 Servers . 182
15 UML Diagrams for SBDH . 184
15.1 UML aligned with text of SBDH specification . 185
15.2 UML aligned with XSD of SBDH specification . 185
16 List of abbreviations (non-normative) . 185
17 References . 187

© ISO/IEC 2024 – All rights reserved
vii
EPCIS Standard
Index of figures
Figure 2-1 EPCIS in relation to the "Capture" and "Share" layers . 3
Figure 2-2 EPCIS in relation to other GS1 System Architecture components . 5
Figure 5-1 Layers of the EPCIS specification framework . 10
Figure 6-1 Structure of event data and master data in EPCIS . 14
Figure 7-1 EPCIS data definition notation . 21
Figure 7-2 EPCIS UML with Ontology focus . 24
Figure 7-3 EPCIS UML with Syntax focus . 24
Figure 7-4 Example of the distinction between a read point and a business location . 35
Figure 7-5 Coordinate reference systems . 46
Figure 7-6 Association and Aggregation with returnable transport units (RTIs) . 69
Figure 7-7 Association and Aggregation with containers . 70
Figure 7-8 Association and Aggregation in a room . 70
Figure 8-1 EPCIS Service Layer . 75
Figure 10-1 RDF Triple: Subject-Property-Value . 130
Figure 10-2 Supporting multiple formats for EPCIS / CBV 2.0 . 134
Figure 12-1 Client first uses OPTIONS to discover which versions are supported and
making GET request . 153
Figure 12-2 Authentication and authorisation . 153
Figure 12-3 Endpoint: Capture Interface workflow . 155
Figure 12-4 EPCIS query as URL query parameters . 158
Figure 12-5 Endpoint: Named queries workflow . 161
Figure 12-6 Client creates a named query for EPCIS events and uses pagination to
retrieve all EPCIS events . 162
Figure 12-7 Scheduled query workflow . 164
Figure 12-8 Event streaming query workflow . 165
Figure 12-9 Query subscription with Webhook (HTTP Callback) . 166
Figure 12-10 Query subscription with a WebSocket . 167
Figure 15-1 UML aligned with text of SBDH . 185
Figure 15-2 UML aligned with XSD of SBDH . 185
© ISO/IEC 2024 – All rights reserved
viii
EPCIS Standard
1 Introduction
This document is a GS1 standard that defines Version 2.0 of EPC Information Services
(EPCIS). The goal of EPCIS is to enable disparate applications to create and share
visibility event data, both within and across enterprises. Ultimately, this sharing is
aimed at enabling users to gain a shared view of physical or digital objects within a
relevant business context.
“Objects” in the context of EPCIS typically refers to physical objects that are identified
either at a class or instance level and which are handled in physical handling steps of
an overall business process involving one or more organisations. Examples of such
physical objects include trade items (products), logistic units, returnable assets, fixed
assets, physical documents, etc. “Objects” may also refer to digital objects, also
identified at either a class or instance level, which participate in comparable business
process steps. Examples of such digital objects include digital trade items (music
downloads, electronic books, etc.), digital documents (electronic coupons, etc.), and so
forth. Throughout this document the word “object” is used to denote a physical or
digital object, identified at a class or instance level, that is the subject of a business
process step. EPCIS data consist of “visibility events,” each of which is the record of
the completion of a specific business process step acting upon one or more objects.
The EPCIS standard was originally conceived as part of a broader effort to enhance
collaboration between trading partners by sharing of detailed information about
physical or digital objects. The name EPCIS reflects the origins of this effort in the
development of the Electronic Product Code (EPC). It should be noted, however, that
EPCIS does not require the use of Electronic Product Codes, nor of Radio-Frequency
Identification (RFID) data carriers, and does not even require instance-level
identification (for which the Electronic Product Code was originally designed). The
EPCIS standard applies to all situations in which visibility event data is to be captured
and shared, and the presence of “EPC” within the name is of historical significance
only.
EPCIS provides open, standardised interfaces that allow for seamless integration of
well-defined services in inter-company environments as well as within companies.
Standard interfaces are defined in the EPCIS standard to enable visibility event data to
be captured and queried using a defined set of service operations and associated data
standards, all combined with appropriate security mechanisms that satisfy the needs of
user companies. In many or most cases, this will involve the use of one or more
persistent databases of visibility event data, though elements of the Services approach
could be used for direct application-to-application sharing without persistent
databases.
With or without persistent databases, the EPCIS specification specifies only standard
data sharing interfaces between applications that capture visibility event data and
those that need access to it. It does not specify how the service operations or
databases themselves should be implemented. This includes not defining how the
EPCIS services should acquire and/or compute the data they need, except to the
extent the data is captured using the standard EPCIS capture operations. The
interfaces are needed for interoperability, while the implementations allow for
competition among those providing the technology and implementing the standard.
EPCIS is intended to be used in conjunction with the GS1 Core Business Vocabulary
(CBV) standard [CBV2.0]. EPCIS and the CBV are developed, maintained and
published by GS1; EPCIS and the CBV are also published within ISO's PAS process as
ISO/IEC 19987 and ISO/IEC 19988, respectively. The CBV standard provides
definitions of data values that may be used to populate the data structures defined in
the EPCIS standard. The use of the standardised vocabulary provided by the CBV
standard is critical to interoperability and critical to provide for querying of data by
reducing the variation in how different businesses express common intent. Therefore,
applications should use the CBV standard to the greatest extent possible in
constructing EPCIS data.
The companion EPCIS and CBV Implementation Guideline [EPCISGuideline] provides
additional guidance for building visibility systems using EPCIS and CBV, including
detailed discussion of how to model specific business situations using EPCIS/CBV data
and methods for sharing such data between trading partners.
© ISO/IEC 2024 – All rights reserved
EPCIS Standard
2 Relationship to the GS1 System Architecture
This section is largely quoted from [GS1Arch], and shows the relationship of EPCIS to
other GS1 standards.
2.1 Overview of GS1 standards
GS1 standards support the information needs of end users interacting with each other
in supply chains, specifically the information required to support the business
processes through which supply chain participants interact. The subjects of such
information are the real-world entities that are part of those business processes. Real-
world entities include things traded between companies, such as products, parts, raw
materials, packaging, and so on. Other real-world entities of relevance to trading
partners include the equipment and material needed to carry out the business
processes surrounding trade such as containers, transport, machinery; entities
corresponding to physical locations in which the business processes are carried out;
legal entities such as companies, divisions; service relationships; business transactions
and documents; and others. Real-world entities may exist in the tangible world, or
may be digital or conceptual. Examples of physical objects include a consumer
electronics product, a transport container, and a manufacturing site (location entity).
Examples of digital objects include an electronic music download, an eBook, and an
electronic coupon. Examples of conceptual entities include a trade item class, a
product category, and a legal entity.
GS1 standards may be divided into the following groups according to their role in
supporting information needs related to real-world entities in supply chain business
processes:
■ Standards which provide the means to identify real-world entities so that they
may be the subject of electronic information that is stored and/or communicated
by end users. GS1 identification standards include standards that define unique
identification codes (called GS1 identification keys).
■ Standards which provide the means to automatically capture data that is carried
directly on physical objects, bridging the world of physical things and the world of
electronic information. GS1 data capture standards include definitions of barcode
and radio-frequency identification (RFID) data carriers which allow identifiers to be
affixed directly to a physical object, and standards that specify consistent
interfaces to readers, printers, and other hardware and software components that
connect the data carriers to business applications.
■ Standards which provide the means to Share information, both between trading
partners and internally, providing the foundation for electronic business
transactions, electronic visibility of the physical or digital world, and other
information applications. GS1 standards for information sharing include this EPCIS
Standard which is a standard for visibility event data. Other standards in the
“Share” group are standards for master data and for business transaction data, as
well as discovery standards that help locate where relevant data resides across a
supply chain and trust standards that help establish the conditions for sharing data
with adequate security.
The EPCIS standard fits into the “Share” group, providing the data standard for
visibility event data and the interface standards for capturing such information from
data capture infrastructure (which employs standards from the “Capture” group) and
for sharing such information with business applications and with trading partners.
© ISO/IEC 2024 – All rights reserved
EPCIS Standard
2.2 EPCIS in relation to the “Capture” and “Share” layers
Figure 2-1 EPCIS in relation to the "Capture" and "Share" layers

The diagram above shows the relationship between EPCIS and other GS1 standards in
the “Capture” and “Share” groups. (The “Identify” group of standards pervades the
data at all levels of this architecture, and so is not explicitly shown.)
As depicted in the diagram above, the EPCIS Capture Interface exists as a bridge
between the “Capture” and “Share” standards. The EPCIS Query Interface provides
visibility event data both to internal applications and for sharing with trading partners.
At the centre of a data capture application is the data capture workflow that supervises
the business process step within which data capture takes place. This is typically
custom logic that is specific to the application. Beneath the data capture workflow in
the diagram is the data path between the workflow and GS1 data carriers: barcodes
and RFID. The green bars in the diagram denote GS1 standards that may be used as
interfaces to the data carriers. At the top of the diagram are the interfaces between
the data capture workflow and larger-scale enterprise applications. Many of these
interfaces are application- or enterprise-specific, though using GS1 data as building
blocks; however, the EPCIS interface is a GS1 standard. Note that the interfaces at the
top of the diagram, including EPCIS, are independent of the data carrier used at the
bottom of the diagram.
The purpose of the interfaces and the reason for a multi-layer data capture
architecture is to provide isolation between different levels of abstraction. Viewed from
the perspective of an enterprise application (i.e., from the uppermost blue box in the
figure), the entire data capture application shields the enterprise application from the
details of exactly how data capture takes place. Through the application-level
interfaces (uppermost green bars), an enterprise application interacts with the data
capture workflow through data that is data carrier independent and in which all of the
interaction between data capture components has been consolidated into that data. At
a lower level, the data capture workflow is cognizant of whether it is interacting with
© ISO/IEC 2024 – All rights reserved
EPCIS Standard
barcode scanners, RFID interrogators, human input, etc., but the transfer interfaces
(green bars in the middle) shield the data capture workflow from low-level hardware
details of exactly how the data carriers work. The lowest level interfaces (green bars
on the bottom) embody those internal data carrier details. EPCIS and the “Share” layer
in general differ from elements in the Capture layer in three key respects:
1. EPCIS deals explicitly with historical data (in addition to current data). The Capture
layer, in contrast, is oriented exclusively towards real-time processing of captured
data.
2. EPCIS often deals not just with raw data captured from data carriers such as
barcodes and RFID tags, but also in contexts that imbue those observations with
meaning relative to the physical or digital world and to specific steps in operational
or analytical business processes. The Capture layers are more purely observational
in nature. An EPCIS event, while containing much of the same “Identify” data as a
Filtering & Collection event or a barcode scan, is at a semantically higher level
because it incorporates an understanding of the business context in which the
identifier data were obtained. Moreover, there is no requirement that an EPCIS
event be directly related to a specific physical data carrier observation. For
example, an EPCIS event may indicate that a perishable trade item has just
crossed its expiration date; such an event may be generated purely by software.
3. EPCIS operates within enterprise IT environments at a level that is much more
diverse and multi-purpose than exists at the Capture layer, where typically
systems are self-contained and exist to serve a single business purpose. 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 overall 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).
2.3 EPCIS in Relation to trading partners
GS1 standards in the “Share” layer pertain to three categories of data that are shared
between end users:
Data Description GS1
standards
Master data Data, shared by one trading partner to many trading GDSN
partners, that provide descriptive attributes of real-world
entities identified by GS1 identification keys, including trade
items, parties, and physical locations.
Transaction data Trade transactions triggering or confirming the execution of GS1 XML
a function within a business process as defined by an
EANCOM
explicit business agreement (e.g., a supply contract) or an
implicit one (e.g., customs processing), from the start of
the business process (e.g., ordering the product) to the end
of it (e.g., final settlement), also making use of GS1
identification keys.
Visibility event data Details about physical or digital activity in the supply chain EPCIS
of products and other assets, identified by keys, detailing
where these objects are in time, and why; not just within
one organisation’s four walls, but across organisations.
Transaction Data and Visibility Event Data have the characteristic that new documents
of those types are continually created as more business is transacted in a supply chain
in steady state, even if no new real-world entities are being created. Master data, in
contrast, is more static: the master data for a given entity changes very slowly (if at
all), and the quantity of master data only increases as new entities are created, not
merely because existing entities participate in business processes. For example, as a
given trade item instance moves through the supply chain, new transaction data and
visibility event data are generated as that instance undergoes business transactions
(such as purchase and sale) and physical handling processes (packing, picking,
stocking, etc.). But new master data is only created when a new trade item or location
is added to the supply chain.
© ISO/IEC 2024 – All rights reserved
EPCIS Standard
Figure 2-2 EPCIS in relation to other GS1 System Architecture components

The figure above illustrates the flow of data between trading partners, emphasising the
parts of the EPCIS standard involved in the flow of visibility event data.
In addition to the use of the EPCIS Query Interface as illustrated above, trading
partners may by mutual agreement use the EPCIS Document structure defined in
section 9.3 as a means to transport a collection of EPCIS events, optionally
accompanied by relevant master data, as a single electronic document.
2.4 EPCIS in relation to other GS1 System Architecture components
The following outlines the responsibilities of each element of the GS1 System
Architecture as illustrated in the figures in the preceding sections. Further information
may be found in [GS1Arch].
■ RFID and Barcode Readers Make observations of RFID tags while they are in the
read zone, and observations of barcodes when reading is triggered.
■ Low-Level [RFID] Reader Protocol (LLRP) Interface Defines the control and delivery
of raw RFID tag reads from RFID 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 RFID tag reads, over time
intervals delimited by events defined by the EPCIS Capturing Application (e.g.
tripping a motion detector). No comparable role typically exists for reading
barcodes, because barcode readers typically only read a single barcode when
triggered.
■ Filtering & Collection (ALE) Interface Defines the control and delivery of filtered
and collected RFID tag read data from the Filtering & Collection role to the Data
Capture Workflow 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
© ISO/IEC 2024 – All rights reserved
EPCIS Standard
duplicates and has been filtered by criteria defined by the EPCIS Capturing
Application. In the case of barcodes, comparable data is delivered to the Data
Capture Workflow role directly from the barcode reader in the form of a GS1
Element String.
■ Data Capture Workflow 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 Data
Capture Workflow may, for example, coordinate a conveyor system with Filtering &
Collection events and barcode reads, may check for exceptional conditions and
take corrective action (e.g., diverting a bad object into a rework area), may
present information to a human operator, and so on. The Data Capture Workflow
understands the business process step or steps during which EPCIS event data
capture takes place. This role may be complex, involving the association of
multiple Filtering & Collection events and/or barcode reads with one or more
business events, as in the loading of a shipment. Or it may be straightforward, as
in an inventory business process where there may be readers deployed that
generate observations about objects that enter or leave the shelf. Here, the
Filtering & Collection-level event or barcode read and the EPCIS-level event may
be so similar that very little actual processing at the Data Capture Workflow level
is necessary, and the Data Capture Workflow merely configures and routes events
from the Filtering & Collection interface and/or barcode readers directly through
the EPCIS Capture Interface to an EPCIS Repository or a business application. A
Data Capture Workflow whose primary output consists of EPCIS events is called an
“EPCIS Capturing Application” within this standard.
■ 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).” There are three EPCIS
Interfaces, specified normatively in this document:
□ The EPCIS Capture Interface defines the delivery of EPCIS events from
EPCIS Capturing Applications to other roles that consume the data in real time,
including EPCIS Repositories, and real-time “push” to EPCIS Accessing
Applications and trading partners.
□ The EPCIS Query Control Interface defines a means for EPCIS Accessing
Applications and trading partners to obtain EPCIS data subsequent to capture,
typically by interacting with an EPCIS Repository. 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 (or “pushed”) to a recipient via the EPCIS Query Callback
Interface. The EPCIS Query Callback Interface may also be used to deliver
information immediately upon capture; this corresponds to the “possible
bypass for real-time push” arrow in the diagram.
■ 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 EPCIS visibility event data.
■ EPCIS 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.
© ISO/IEC 2024 – All rights reserved
EPCIS Standard
The interfaces within this stack are designed to insulate the higher levels of the
architecture from unnecessary details of how the lower levels are implemented. One
way to understand this is to consider what happens if certain changes are made:
■ The Low-Level [RFID] Reader Protocol (LLRP) and GS1 Element String insulate the
higher layers from knowing what RF protocols or barcode symbologies are in use,
and what reader makes/models have been chosen. If a different reader is
substituted, the information sent through these interfaces remains the same.
■ In situations where RFID is used, the Filtering & Collection Interface insulates the
higher layers from the physical design choices made regarding how RFID tags are
sensed and accumulated, and how the time boundaries of events are triggered. If
a single four-antenna RFID reader is replaced by a constellation of five single-
antenna “smart antenna” readers, the events at the Filtering & Collection level
remain the same. Likewise, if a different triggering mechanism is used to mark the
start and end of the time interval over which reads are accumulated, the Filtering
& Collection event remains the same.
■ EPCIS insu
...