ISO/IEC 19987:2017

INTERNATIONAL ISO/IEC
STANDARD 19987
Second edition
2017-10
Information technology — EPC
Information Services (EPCIS) Standard
Technologies de l’information — Norme relative aux services
d’information sur les codes de produit électronique
Reference number
©
ISO/IEC 2017
© ISO/IEC 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2017 – All rights reserved

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. In the field of information technology, ISO
and IEC have established a joint technical committee, ISO/IEC JTC 1.
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. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2
(see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such
patent rights. Details of any patent rights identified during the development of the document will
be in the Introduction and/or on the ISO list of patent declarations received (see
www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and
does not constitute an endorsement.
For an explanation on 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 the
following URL: www.iso.org/iso/foreword.html.
This document was prepared by the GS1 and was adopted, under the PAS procedure, by Joint
Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its approval by
national bodies of ISO and IEC.
This second edition cancels and replaces the first edition (ISO/IEC 19987:2015), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— A mechanism is introduced to declare that a prior EPCIS event is in error, for use when it is
impossible to correct the historical trace by means of ordinary EPCIS events.
— An optional eventID is added to all EPCIS events.
— The Simple Event Query is enhanced to clarify that queries for extension or ILMD fields
apply only to top‐level XML elements, and a new set of query parameters is introduced to
query for XML elements nested within top‐level elements.
— The role of an EPCIS document as a means to transmit events point‐to‐point is clarified.
© ISO/IEC 2017 – All rights reserved iii

— The EPCIS Header in the XML schemas is enhanced to allow for optional inclusion of master
data.
— The use of extension elements within and is deprecated.
— Section 12 regarding conformance is added.
iv © ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
Document Summary
Document Item Current Value
Document Name EPC Information Services (EPCIS) Standard
Document Date Sep 2016
Document Version 1.2
Document Issue
Document Status Ratified
Document Description enables disparate applications to create and share visibility event data,
both within and across enterprises.
Log of Changes
Release Date of Change Changed By Summary of Change
1.0 Initial version
1.1 May 2014 EPCIS 1.1 is fully backward compatible with EPCIS 1.0.1.
EPCIS 1.1 includes these new or enhanced features:
Support for class-level identification is added to
ObjectEvent, AggregationEvent, and
TransformationEvent through the addition of quantity lists.
A new event type, TransformationEvent, provides for the
description of events in which inputs are consumed and
outputs are produced.
The “why” dimension of all event types are enhanced so that
information about the sources and destinations of business
transfers may be included.
The “why” dimension of certain event types are enhanced so
that item/lot master data may be included.
The SimpleEventQuery is enhanced to encompass the above
changes to event types.
The introductory material is revised to align with the GS1
System Architecture.
The XML extension mechanism is explained more fully.
The QuantityEvent is deprecated, as its functionality is fully
subsumed by ObjectEvent with the addition of quantity lists.
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 2 of 131
© ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
Release Date of Change Changed By Summary of Change
1.2 Sep 2016 EPCIS 1.2 is fully backward compatible with EPCIS 1.1 and
1.0.1.
EPCIS 1.2 includes these new or enhanced features:
A mechanism is introduced to declare that a prior EPCIS
event is in error, for use when it is impossible to correct the
historical trace by means of ordinary EPCIS events. This
mechanism includes the errorDeclaration structure in an
EPCIS event and associated query parameters.
An optional eventID is added to all EPCIS events. Its main
intended use is to allow for an error declaration event to
(optionally) refer to one or more corrective events.
The Simple Event Query is enhanced to clarify that queries
for extension or ILMD fields apply only to top-level XML
elements, and a new set of query parameters is introduced
to query for XML elements nested within top-level elements.
The role of an EPCIS document as a means to transmit
events point-to-point is clarified.
The EPCIS Header in the XML schemas is enhanced to allow
for optional inclusion of master data.
The use of extension elements within and
is deprecated.
Section 12 regarding conformance is added.
Disclaimer ®
GS1 , under its IP Policy, seeks to avoid uncertainty regarding intellectual property claims by requiring the participants in
the Work Group that developed this EPC Information Services (EPCIS) Standard to agree to grant to GS1 members a
royalty-free licence or a RAND licence to Necessary Claims, as that term is defined in the GS1 IP Policy. Furthermore,
attention is drawn to the possibility that an implementation of one or more features of this Specification may be the subject
of a patent or other intellectual property right that does not involve a Necessary Claim. Any such patent or other
intellectual property right is not subject to the licencing obligations of GS1. Moreover, the agreement to grant licences
provided under the GS1 IP Policy does not include IP rights and any claims of third parties who were not participants in the
Work Group.
Accordingly, GS1 recommends that any organisation developing an implementation designed to be in conformance with this
Specification should determine whether there are any patents that may encompass a specific implementation that the
organisation is developing in compliance with the Specification and whether a licence under a patent or other intellectual
property right is needed. Such a determination of a need for licencing should be made in view of the details of the specific
system designed by the organisation in consultation with their own patent counsel.
THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF
MERCHANTABILITY, NONINFRINGMENT, FITNESS FOR PARTICULAR PURPOSE, OR ANY WARRANTY OTHER WISE ARISING
OUT OF THIS SPECIFICATION. GS1 disclaims all liability for any damages arising from use or misuse of this Standard,
whether special, indirect, consequential, or compensatory damages, and including liability for infringement of any
intellectual property rights, relating to use of information in or reliance upon this document.
GS1 retains the right to make changes to this document at any time, without notice. GS1 makes no warranty for the use of
this document and assumes no responsibility for any errors which may appear in the document, nor does it make a
commitment to update the information contained herein.
GS1 and the GS1 logo are registered trademarks of GS1 AISBL.
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 3 of 131
© ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
Table of Contents
1 Introduction . 7
2 Relationship to the GS1 System Architecture . 7
2.1 Overview of GS1 standards . 8
2.2 EPCIS in relation to the “Capture” and “Share” layers . 8
2.3 EPCIS in Relation to trading partners . 10
2.4 EPCIS in relation to other GS1 System Architecture components . 11
3 EPCIS specification principles . 13
4 Terminology and typographical conventions . 14
5 EPCIS specification framework . 14
5.1 Layers . 14
5.2 Extensibility . 16
5.3 Modularity . 16
6 Abstract data model layer . 16
6.1 Event data and master data . 17
6.1.1 Transmission of master data in EPCIS . 19
6.2 Vocabulary kinds . 20
6.3 Extension mechanisms . 21
6.4 Identifier representation . 22
6.5 Hierarchical vocabularies . 22
7 Data definition layer . 23
7.1 General rules for specifying data definition layer modules . 23
7.1.1 Content . 23
7.1.2 Notation . 24
7.1.3 Semantics . 25
7.2 Core event types module – overview . 25
7.3 Core event types module – building blocks . 29
7.3.1 Primitive types . 29
7.3.2 Action type . 29
7.3.3 The “What” dimension . 30
7.3.4 The “Where” Dimension – read point and business location . 33
7.3.5 The “Why” dimension . 36
7.3.6 Instance/Lot master data (ILMD) . 39
7.4 Core event types module – events . 40
7.4.1 EPCISEvent . 40
7.4.2 ObjectEvent (subclass of EPCISEvent) . 43
7.4.3 AggregationEvent (subclass of EPCISEvent) . 46
7.4.4 QuantityEvent (subclass of EPCISEvent) – DEPRECATED . 49
7.4.5 TransactionEvent (subclass of EPCISEvent) . 50
7.4.6 TransformationEvent (subclass of EPCISEvent) . 53
8 Service layer . 55
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 4 of 131
© ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
8.1 Core capture operations module . 57
8.1.1 Authentication and authorisation . 57
8.1.2 Capture service . 57
8.2 Core Query operations module . 58
8.2.1 Authentication . 59
8.2.2 Authorisation . 59
8.2.3 Queries for large amounts of data . 60
8.2.4 Overly complex queries . 60
8.2.5 Query framework (EPCIS query control interface) . 60
8.2.6 Error conditions . 66
8.2.7 Predefined queries for EPCIS . 68
8.2.8 Query callback interface . 79
9 XML bindings for data definition modules . 80
9.1 Extensibility mechanism . 80
9.2 Standard business document header . 82
9.3 EPCglobal Base schema . 83
9.4 Master data in the XML binding . 84
9.5 Schema for core event types . 85
9.6 Core event types – examples (Non-Normative) . 97
9.6.1 Example 1 – Object Events with instance-level identification . 97
9.6.2 Example 2 – Object Event with class-level identification . 98
9.6.3 Example 3 – Aggregation event with mixed identification . 99
9.6.4 Example 4 – Transformation event . 100
9.7 Schema for master data document . 101
9.8 Master data – example (non-normative) . 103
10 Bindings for core capture operations module . 104
10.1 Message queue binding . 104
10.2 HTTP binding . 105
11 Bindings for core query operations module . 106
11.1 XML schema for core query operations module . 106
11.2 SOAP/HTTP binding for the query control interface . 114
11.3 AS2 Binding for the query control interface . 122
11.3.1 GS1 AS2 guidelines (Non-Normative) . 124
11.4 Bindings for query callback interface . 126
11.4.1 General Considerations for all XML-based bindings . 127
11.4.2 HTTP binding of the query callback interface . 127
11.4.3 HTTPS binding of the query callback interface . 127
11.4.4 AS2 Binding of the query callback interface . 128
12 Conformance . 129
12.1 Conformance of EPCIS data . 129
12.2 Conformance of EPCIS capture interface clients . 129
12.3 Conformance of EPCIS capture interface servers . 129
12.4 Conformance of EPCIS query interface clients . 130
12.5 Conformance of EPCIS query interface servers . 130
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 5 of 131
© ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
12.6 Conformance of EPCIS query callback interface implementations . 130
13 References . 130
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 6 of 131
© ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
1 Introduction
This document is a GS1 standard that defines Version 1.2 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 as of EPCIS 1.2 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 a standard data sharing
interface 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
[CBV1.2]. 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.
2 Relationship to the GS1 System Architecture
This section is largely quoted from [EPCAF] and [GS1Arch], and shows the relationship of EPCIS to
other GS1 standards.
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 7 of 131
© ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
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.
2.2 EPCIS in relation to the “Capture” and “Share” layers
The following diagram 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.)
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 8 of 131
© ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
To/from
external
eCOM (GS1 XML / EANCOM) Interface
parties
GDSN Interface
EPCIS Query Interface
Possible
(3&,6$FFHVVLQJ
(3&,6
bypass for
$SSOLFDWLRQVDQGRWKHU
real-time 5HSRVLWRU\
(QWHUSULVHOHYHO
“push”
$SSOLFDWLRQV
Share
EPCIS Capture
Capture
Interface
Various app-specific Interfaces
'DWD
&DSWXUH
$SSOLFDWLRQ
Human
'DWD&DSWXUH:RUNIORZ
Interfaces
ALE Interface
)LOWHULQJ 
&ROOHFWLRQ(QJLQH
Composite
Element
LLRP Interface
String
,QWHUIDFH
RFID Reader
6\VWHP&RPSRQHQW
RFID Air Interface Barcode Symbology
RFID Tag Barcode
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.
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 9 of 131
© ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
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 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:
 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.
 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.
 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 partners, that provide GDSN
descriptive attributes of real-world entities identified by GS1 identification keys,
including trade items, parties, and physical locations.
Transaction Trade transactions triggering or confirming the execution of a function within a GS1 XML
data business process as defined by an explicit business agreement (e.g., a supply
EANCOM
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 Details about physical or digital activity in the supply chain of products and EPCIS
data 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
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 10 of 131
© ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
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.
The following figure illustrates the flow of data between trading partners, emphasising the parts of
the EPCIS standard involved in the flow of visibility event data.
6HUYLFHVIRU *'61*OREDO
'LVFRYHU\216HWF 5HJLVWU\
GS1 Networked Services
Trading Partner 1 Trading Partner 2
EPCIS Query traffic – on-demand queries and
standing queries
eCOM (GS1 XML / EANCOM) Interface
GDSN Interface
EPCIS Query EPCIS Query
and data pools
Interface (Control Interface (Control
and Callback) and Callback)
(3&,6$FFHVVLQJ (3&,6$FFHVVLQJ
(3&,6 (3&,6
$SSOLFDWLRQVDQG $SSOLFDWLRQVDQG
5HSRVLWRU\ 5HSRVLWRU\
RWKHU(QWHUSULVHOHYHO RWKHU(QWHUSULVHOHYHO
$SSOLFDWLRQV $SSOLFDWLRQV
EPCIS Capture EPCIS Capture
Interface
Interface
App-specific App-specific
Interfaces Interfaces
'DWD&DSWXUH,QIUDVWUXFWXUH 'DWD&DSWXUH,QIUDVWUXFWXUH
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],
from which the above diagram and much of the above text is quoted, and [EPCAF], from which
much of the following text is quoted.
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 11 of 131
© ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
Ŷ 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 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-enabled
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 actually three EPCIS Interfaces. 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. All three of these EPCIS interfaces are specified
normatively in this document.
Ŷ 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.
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 12 of 131
© ISO/IEC 2017 – All rights reserved

EPC Information Services (EPCIS) Standard
Ŷ 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.
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
...