EPC Information Service (EPCIS)
Mark Harrison
Cambridge Auto-ID Lab
Institute for Manufacturing
University of Cambridge
Mark.Harrison@https://www.doczj.com/doc/0b15392748.html,
1.Introduction
This presentation provides an overview of our Java web service prototypes of the EPC Information Service (EPCIS) and the EPCIS Discovery Service (formerly known as Dynamic ONS), as well as an update on the latest thinking from the SAG EPCIS working group.
2.EPC Information Service (EPCIS)
The EPC Information Service provides a uniform programmatic interface to allow various clients to capture, secure, and access EPC-related data and the business transactions with which that data is associated. In the revised architecture of the EPC Network, EPCIS largely replaced the role of the PML Server / PML Service and also aspects of the Physical Markup Language.
The original EPC network architecture envisioned by the Auto-ID Centre, consisted of a collection of technology components, including tags and readers, Savant, the Object Name Service (ONS) and the Physical Markup Language (PML). The version 1.0 specifications released in September 2003 described each of these components as building blocks. This is illustrated in Figure 1.
In the last year, the technical action groups have been working on a revised set of specifications to form the basis for the EPCglobal Network standards. In many cases, there is a major shift of emphasis away from defining components and towards defining interfaces that may be implemented by various components. This approach should make it much easier to test and certify compliance with particular standards, especially when the functionality of various components expands – e.g. smart readers which also implement sophisticated filtering. The revised architecture is illustrated conceptually in Figure 2.
[ conceptual diagram – not authoritative ].
Figure 2. Revised EPC Network Architecture (September 2004)
[ conceptual diagram – not authoritative ].
The key to affordable global adoption of the EPC Network was always to use relatively simple passive RFID tags with very limited memory capacity and to store the additional EPC-related data in networked databases. Initially, David Brock proposed the Physical Markup Language (PML) as an XML schema for representing all of the EPC-related data, including physical attributes of objects, such as dimensions, mass – as well as observations and sensor measurements. In order to make this work more manageable, the
effort on PML was refocused to concentrate on a well-defined PML Core, to mark up the
low-level event data captured from the EPC Network of sensors, including identity sensors such as RFID readers.
3.Web Services
More recently, with increasing adoption of web service technology, there is much greater emphasis on direct programmatic access to the precise item of data of interest, eliminating the need for client applications to parse through large markup documents to extract the information they require.
A classical use of a web service is in a stock quote monitoring program. While various websites such as https://www.doczj.com/doc/0b15392748.html, provide human-readable web pages of information about stock prices, together with graphs and forecasts, a stock quote monitoring program often only requires rapid access to a numeric value – the instantaneous (or time-delayed) stock price – and it is disadvantageous if it must search through (parse) the entire document merely to extract a simple numeric value hidden somewhere within the document.
Web services are usually defined in terms of WSDL (Web Services Description Language) files, which are XML documents which define the methods or functions which are available, as well as the input parameters and data types and the returned data type. WSDL files also can include transport bindings to specify how the message is sent over the network – these include the endpoint – the networked data object which provides those methods – and the proxy – the URI address which handles calls to that object.
4.Categories of EPCIS data and relationships
There are many categories of EPC-related data. Some of these are attribute data, such as the mass or dimensions of an object or its date of manufacture. Other relations are dynamically built up over time, such as the history of where an object has been observed within a factory, distribution centre or retail store.
Of the attribute data, some are defined at product-class level, while others are defined at instance level (i.e. may be different for each instance of a product class, e.g. date of manufacture, expiry date).
For the timestamped historical data, we want to be able to determine both the current state of an object (e.g. its current location, temperature), as well as its history (trace of locations visited, temperature history). We may also want to be able to query the data using keys other than the EPC of the object. For example, in a product recall scenario, we might want to find out the identities of all objects which passed through a particular contaminated location within a particular time range. Since the Tag Data Standards specification v1.1r1.24 defines how to encode a Global Location Number (GLN) into an EPC – so locations are also valid EPCs – and the location EPC would be the main parameter for such a query, with a list of object EPCs being returned.
5.Business Logic
Another important distinguishing feature of EPCIS is that it is the lowest level in the EPC Network architecture where ‘business logic’ may be introduced. The output of the filtering platform (‘Application Level Events’) says nothing about the interpretation in terms of business events. For example, an ALE report may indicate that a pallet and several cases were seen together (within a particular event cycle timeframe) at a particular location, such as a dock door. However, that information alone does not imply that the cases were aggregated onto the pallet – nor that it represents a particular shipment, nor whether it was being despatched or received. ALE merely provides raw observation reports from the sensor network, which need to be combined with additional context information in order to construct ‘business events’ upon which applications such as ERP, WMS systems can act.
EPCIS can serve as a repository for storing both the low-level observation reports from ALE, as well as higher-level business logic relations, such as a particular shipment arriving and consisting of a particular list of cases, aggregated to a particular pallet.
6.EPCIS as a platform to support multiple underlying databases Just as one of the original aims of Savant was to provide a platform into which several vendors of reader could ‘plug-in’, with the output being significant ‘detection events’ communicated in a standard format to applications. This is illustrated in Figure 3.
Figure 3. Savant as a ‘platform’ for interfacing to EPC readers from multiple vendors. The platform provides a uniform interface to client applications, in just the same way that an operating system provides vendor-unspecific print functions to applications, while vendor-specific printer drivers translate commands into vendor-specific code.
In the same way, EPCIS is designed as a platform with a uniform query and update interface to applications, while the actual implementation details and data binding to existing databases and information systems is not specified by EPCIS. EPCIS should therefore support simultaneous binding to multiple databases and information systems from multiple vendors, as well as EPCIS as a managed application service, like web
hosting or DNS provision. This is illustrated in Figure 4.
Figure 4. Applications use the EPCIS as a standard interface to EPC-related data, even though it may be stored in underlying databases and information systems of different types and from different vendors. Applications may need to access multiple EPCIS services across the supply chain to handle more complex queries which require information from several custodians of the object.
In order to accommodate various types of data relationships such as observations, measurement, containment, associations with particular transactions, EPCIS is being designed as a modular framework, with a very lightweight core functionality, which merely described which ‘profiles’ or relationship types are implemented on any particular instantiation providing an EPCIS interface. From the list of profile IDs, it is then possible to query for the profile interface definition, most likely in terms of a WSDL file.
From this, an application then knows which methods (functions) are available to it, how
to construct the commands for performing queries or updates – and how to connect to the EPCIS interface over the network.
7.Security technologies
Until this point, we have not mentioned security. EPCIS provides an opportunity for trading partners to share information and massively increase the visibility of product flows within supply chains. However, it is essential that this can be done in a secure way, so that companies can be assured that they retain control of who has access to which subsets of their data. There are various aspects of security that need to be considered:
Authentication – who is making the request, who is providing the data in response
Access control – does the requestor have the correct role-based access privileges to entitle them to read (or even update) that specific information
Federation and single sign-in – the underlying information accessed via EPCIS may be fragmented not only across a supply chain, but also within a company, across several underlying systems.
Web services security is developing and much of the current interest is around XML Digital Signatures, which allow both the sender and receiver to mutually authenticate that they are conversing with each other. Regarding access control, technologies such as XACL and XACML (XML Access Control Markup Langauge) allow fine-grained policies to be defined about which roles are allowed read / update permission to particular subsets of data. For federation, technologies such as SAML (Security Assertion Markup Language) allow different systems to exchange tokens which confirm that a particular user has the right to access particular information.
8.Coordination role by client applications
Of course, the EPCIS proposed at this stage has neither any artificial intelligence built in, nor does it attempt to proxy requests to other EPCIS instances on behalf of the client making the request. EPCIS can usually only provide access to data that it can access locally. It is the role of client applications to break down complex queries which need to contact multiple EPCIS services and to co-ordinate the sequence of queries and combination of the results. This is completely analogous to the way that a web browser client may request a web page, which itself contains images held on different webservers – in this case, the client application (web browser) needs to separately retrieve those images from the other webservers, in order to build up the full picture for the web page. Furthermore, the instance-level data is fragmented across the unique supply chain path followed by each individual object. For example, a distribution company may hold records of the temperature history of perishable goods while in transit. The Object Name Service (ONS) does not provide serial-level pointers to EPCIS, nor is the DNS technology on which it is based suitable for dynamically updated serial-level pointers
across the supply chain. The EPCIS Discovery Service provides a mechanism for each custodian to update a registry, so that each can indicate on a per-EPC basis that they hold some data related to a particular EPC. This is what was formerly known as ‘Dynamic ONS’ or the custodian sequence registry. There are of course opportunities for the registry to not only hold a list of EPCIS URLs for a given EPC – but also associated timestamps or even a flag to indicate whether an individual serialised object is marked for recall, thus enabling more pro-active finer-grained product recalls, even before the recalled objects have reached the end of their supply chain paths.
9.Our latest prototypes
We have developed prototypes of the PML Server/Service for over two years. Our latest prototypes are implemented using the Java Web Services Development Pack (JWSDP 1.3) from Sun Microsystems, together with a PostgreSQL relational database for storing the underlying data. After writing get…() and set…() methods to query and update the timestamped relations. we then use the JAXRPC tools to automatically generate the WSDL files which describe the web service – and also in the client-side code which accesses our prototypes of EPCIS and the EPCIS Discovery Service. We have developed web page interfaces for viewing the tables of relationships. These display both the current state and historical trace of relationships for Observations, Measurements, Containment and Transactions.
The next stages of our development work will involve making our prototypes more modular / profile-based, supporting queries and updates of attribute data, using well-defined XML schema and Xpath/XQL queries and the use of the various emerging web service security technologies mentioned above to provide authenticated fine-grained access controls to only selected parts of the data.
We also intend to learn more about Resource Description Framework (RDF) technologies, since these will be relevant for automating inferencing based on the kinds of fundamental simple relationship assertions accessed via EPCIS.