Programme Factories of the Future PPP Strategic Objective ICT-2011.7.

3 Virtual Factories and Enterprises Project Title Product Remanufacturing Service System Acronym PREMANUS Project # 285541

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Work Package Lead Partner Security Classification Date Version

WP3: Remanufacturing Information Services 1: SAP PU (Public) 31 May 2013 1.3

COPYRIGHT
Copyright 2013 by PREMANUS Consortium

Legal Disclaimer
The information in this document is provided as is, and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law. This document may not be copied, reproduced, or modified in whole or in part for any purpose without written permission from all of the Copyright owners. In addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced. The circulation of this document is restricted to the staff of the PREMANUS partner organisations and the European Commission. All information contained in this document is strictly confidential and may not be divulged to third parties without the express permission of all of the Copyright owners. All rights reserved. This document may change without notice.

The PREMANUS project (285541) is co-funded by the European Union under the Information and Communication Technologies (ICT) theme of the 7th Framework Programme for R&D (FP7). This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of its content.

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Document history
Version 1.0 1.1 1.2 1.3 Date 06/03/13 15/03/13 22/03/13 31/05/13 Comments First version Revision of 1 Version Finalizing the document Major update.
st

Author Petro Kazmirchuk (SAP) Oscar Garcia (TIE) Nicolas Liebau (SAP) Petro Kazmirchuk (SAP)

The research leading to these results has received funding from the European Communitys Seventh Framework Programme (FP7/2007-2013) under grant agreement no285541.

ii

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Table of contents
1 2 3 EXECUTIVE SUMMARY .......................................................................................................................... 1 INTRODUCTION ........................................................................................................................................ 2 PRODUCT IDENTIFICATION SCHEMES ............................................................................................. 4 3.1 3.2 3.3 3.4 4 ELECTRONIC PRODUCT CODE .................................................................................................................. 4 VEHICLE IDENTIFICATION NUMBER......................................................................................................... 5 VEHICLE LICENSE PLATE ......................................................................................................................... 5 MANUFACTURER PART NUMBER .............................................................................................................. 5

ID MANAGEMENT METHOD.................................................................................................................. 6 4.1 4.2 ID MANAGEMENT COMPONENTS ............................................................................................................. 6 FEDERATED PRODUCT IDENTIFIER ........................................................................................................... 6

UNDERSTANDING SEMANTICS OF A PRODUCT IDENTIFIER ..................................................... 8 5.1 5.2 5.3 5.4 5.5 SGTIN URI ............................................................................................................................................. 8 GTIN....................................................................................................................................................... 8 VIN ......................................................................................................................................................... 9 VEHICLE LICENSE PLATES ...................................................................................................................... 10 MPN ..................................................................................................................................................... 10

COLLABORATION OF THE ID MANAGEMENT COMPONENTS ................................................. 12 6.1 6.2 6.3 6.4 ID MAPPING .......................................................................................................................................... 12 ID CONSOLIDATION ............................................................................................................................... 14 ID RESOLUTION ..................................................................................................................................... 14 ASSEMBLY TRAVERSAL......................................................................................................................... 17

7 8 9

REASSIGNABLE PRODUCT IDENTIFIERS........................................................................................ 20 CONCLUSION ........................................................................................................................................... 22 APPENDIX A: REFERENCES ................................................................................................................. 23

iii

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

List of abbreviations
BoL DMZ EoL EPC EPCDS EPCIS FPID GCP GEPIR GTIN GUI MoL MPN NAPTR OEM ONS REST UPC VIN VLP WMI Beginning-of-life (of a product) Demilitarized zone End-of-life (of a product) Electronic Product Code EPC Discovery Services EPC Information Services Federated product identifier GS1 company prefix Global Electronic Party Information Registry Global Trade Item Number Graphical user interface Middle-of-life (of a product) Manufacturer part number Name Authority Pointer Original equipment manufacturer Object Name Service Representational State Transfer Universal Product Code Vehicle Identification Number Vehicle license plate World Manufacturer Identifier

iv

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Executive Summary

Reliable product identification strategy is an issue of vital importance for the PREMANUS middleware. Remanufacturing decisions must have a sound foundation on accurate, complete and upto-date product data. This data has to be gathered across participants of the PREMANUS network that have possessed a particular product instance throughout its entire lifecycle. Since each company may refer to a product using a different numbering scheme, there is a need to develop a common denominator for these schemes that will allow identifying a product instance uniquely in the PREMANUS network. From now on these identifiers will be referred to as Federated product identifiers (FPIDs). Please note the change from the previous version of this deliverable, where these identifiers were called PREMANUS ID. This deliverable proposes a detailed product ID Management strategy. Chapter 2 provides an overview of the data gathering process in the PREMANUS Network. Chapter 3 describes the product identification standards chosen for the prototype implementation. Then in Chapter 4 the concept of FPID is introduced. Its correspondence to other commonly used product ID standards follows in Chapter 5. A detailed description of the relevant workflows in Chapter 6 proves that the developed concept satisfies all the requirements. Finally, the issue of reassignable product IDs is tackled in Chapter 7.

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Introduction

The deliverable D2.2 (Sections 3.2, 3.3) has outlined the high-level requirements for the product ID management. Particularly, it defines ID mapping and ID resolution, and the workflows, in which they are used. In addition, the upcoming deliverable D2.4 (Chapter 3) will provide more detailed view on the data publishing process. Based on these documents, the following end-to-end process provides a complete view over lifecycle data of a given product to an information consumer, i.e. a remanufacturer: Client

6. Request by FPID 2. Gather product data

5. Matching advertisements with FPIDs 4. Search

7. Return product data

3. Post advertisements 1. Register Gateway

Cloud

Figure 1 Sharing and searching for product data in the PREMANUS Network 1. The Information Provider deploys the Gateway on its premises, and registers in the Cloud. 2. The Gateway aggregates the data that this company wants to share with the PREMANUS Network. It is converted from an information structure used in the company to the QLM ontology. As part of this transformation process, public identifiers of products must be transformed to the FPID scheme that conforms to QLM. 3. The Gateway creates advertisements from this data and publishes them in the Cloud. Each advertisement corresponds to an event that happened with a particular product instance (e.g. completed assembling, performed maintenance, sold to an end customer etc.) 4. An Information Consumer performs a search for a particular product instance or for a whole class of products in the Cloud. E.g. a remanufacturer received a car engine at its end-of-life, and wants to look up its maintenance history to decide whether to remanufacture it or send to utilization. 5. The Cloud returns a list of matching advertisements to the Client. 6. The Information Consumer chooses advertisements he is interested in, and the Client requests the information from the corresponding Gateways, providing the chosen FPIDs and UDEFs. 7. The Gateway converts the submitted FPID back to the public identifier. This identifier is used to query the product data in databases of the Information Provider and send it back to the Client using the QLM data model. The term public identifier refers to any kind of a product identifier that is not an internal identifier .
2

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

E.g. an inventory number does not bear any semantics outside the owning company, and is kept confidential. Instead, a public ID may be an EAN-13 number encoded in a barcode and attached to a product, so that anybody can see it. Another example of a public ID is a vehicle license plate. The PREMANUS middleware never deals with internal IDs. FPIDs are based on public IDs and enhance them with additional capabilities required in the PREMANUS project that will be described in the further chapters. This is illustrated by the following figure:

FPIDs

Public IDs

DMZ

Infrastructure of Internal IDs the information provider

Figure 2 Different types of product identifiers Thus, the following requirements for ID Management were defined: 1. The solution must support various product identification schemes to minimize intrusion into IT infrastructure and business processes of Partners. Core functionality should be generic, and additional product identification schemes will be provided by plugins. Such a modular architecture should facilitate flexibility and extensibility by any Partner. 2. The solution should be able to work only with products that are individually identifiable, i.e. have serial numbers. 3. In addition to looking up individual items, an Information Consumer should be able to use wildcard search. 4. During a products lifecycle it will be maintained by many parties that might be outside the PREMANUS Network. Therefore, the product information available to it will have blank spots. E.g. a license plate of a car may be changed without respective advertisement posted to the Cloud. The proposed design must be able to handle such issues, so that information integrity is not violated. 5. The proposed design must deal only with product identifiers. Additional information about a product, like category, country of manufacture, bill of materials and so on, is not available to the ID Management component. 6. Potential bottlenecks should be avoided to ensure horizontal scalability.

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Product identification schemes

Numerous product identification schemes have developed over the years. They may be mandatory or not, international or restricted to a specific region, industry-specific or cross-industry. Books have ISBNs, software components and database records often have GUIDs, drugs in the US have NDCs. For example, Joint Information Systems Committee [1] provides a compact summary of 20 different schemes that were evaluated for use in the UK higher education community, in order to implement the Distributed National Electronic Resource. For this research only a few schemes were chosen based on the following criteria: it focuses on PLM and takes into account the growing interest to RFID for product identification purposes; an individual instance of a product, rather than a class, must be identified; the standards are widely used.

Therefore, four identification schemes were chosen: Electronic Product Code, Vehicle Identification Number, Vehicle license plate and Manufacturer part number. Three of them are standardized; however, the last one is a non-standard identifier that includes a manufacturers name, a model number and a serial number. These four schemes are rather different by their nature. This will ensure generality of the solution, so that more schemes can be added with no disruption of core concepts. 3.1 Electronic Product Code

Electronic Product Code (EPC) is a universal identifier for any physical object, standardized and promoted by EPCglobal, Inc. This company is a subsidiary of GS1 the association that invented Universal Product Code (UPC) and barcodes back in 1970s and radically changed the retail world. EPC is a newer coding scheme that encompasses UPC and other GS1 keys, and is suited for use in RFID tags. Unlike UPC and European Article Number (EAN) standards that identify classes of products, EPC identifies an individual instance of a product or asset. The common denominator of all EPC and GS1 codes is Pure Identity EPC URI [2, p. 28]: The term Pure Identity EPC URI is used to refer specifically to the text form EPC takes within computer systems, including electronic documents, databases, and electronic messages The structure of the EPC URI guarantees worldwide uniqueness of the EPC across all types of physical objects and applications When asking the question do these two data structures refer to the same physical object? where each data structure uses an EPC URI to refer to a physical object, the question may be answered simply by comparing the full EPC URI strings. Here is an example: urn:epc:id:sgtin:0614141.112345.400 This is a URN that consists of a namespace (till the last colon) and a body. EPCglobal, Inc. manages various URN namespaces under the urn:epc and urn:epcglobal prefixes [3]. The namespace signifies that this is a particular type of EPC, called SGTIN (Serialized Global Trade Item Number) and defines the syntax of the body. SGTIN is used to identify trade items and is derived from the Global Trade Item Number (GTIN) and a serial number. GTIN in turn is a superset of UPC and EAN keys, and thus one can find it printed in a form of barcode on almost all goods in a supermarket. After careful consideration of all GS1 keys, their purposes and mappings to EPC URIs, it became

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

clear that for the scope of this research it is sufficient to implement the support for the two formats that are used to identify a trade item: EPC URI (only sgtin namespace) GTIN + serial number

Other GS1 keys, like SSCC, GLN, GRAI and others, are used to identify returnable assets, shipping containers, and physical locations. Global Electronic Party Information Registry (gepir.org) is an official web service from GS1 that provides access to all registered company prefixes. Particularly, it allows looking up company information by a GTIN number, issued by this company. 3.2 Vehicle Identification Number

A Vehicle identification number (VIN) is a unique serial number used by the automotive industry to identify individual motor vehicles, motorcycles and mopeds. It consists of 17 alphanumeric characters: 1-3: World Manufacturer Identifier 4-9: Vehicle Descriptor Section 10-17: Vehicle Identifier Section

WMIs are allocated by local authorities in respective countries (e.g. KBA in Germany), coordinated worldwide by Society of Automotive Engineers (SAE). Small manufacturers use a 9 as the third digit, and the 12th, 13th and 14th position of the VIN for a second part of the identification [4]. So, their WMIs are six digits long. The complete database of more than 33,000 international WMI codes is available through an annual subscription from SAE [5]. 3.3 Vehicle license plate

The registration identifier is an alphanumeric code that is allocated by a government of a respective country or province and uniquely identifies a vehicle within this region. It is printed on a plate attached to the vehicle. In many countries it is allowed to reassign this number to a different car. Exact syntax and semantics depends on an issuing authority; however, a country prefix is always available and standardized as International license plate country code [6]. 3.4 Manufacturer part number

Existence of a central authority to allocate product codes is not always the case. Often manufacturers assign their own model and serial numbers to their products (hereinafter called MPN). Car engine numbers is a typical example. Such a number always refer to an individual engine, cannot be reassigned to another engine, and each manufacturer ensures that the numbers of their engines do not overlap. But there is no global standard for them. Therefore, the solution must be able to handle the case when a product is identified by the combination of: Manufacturer or brand name; Model number, which is common for all products of the same design; Serial number, which is unique for each product instance.

The solution will have to take into account that different people may refer to a manufacturer or brand by a slightly different name, e.g. BMW vs. BMW AG.

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

ID management method

The following ideas lie in the foundation of the proposed ID management method: 1. A product identifier needs four elements to identify a product globally and enhance the search for product data: a scheme (e.g. MPN, SGTIN or VIN), OEM ID (specific to this scheme), an item reference (e.g. model number) and a serial number (individual for each product instance). For some schemes, like car license plates, OEM ID and item reference are empty. 2. If a product has several identifiers, they must be kept together in a list in the Cloud. In order to understand that two different identifiers refer to the same product, a Partner submits these identifiers together in a single advertisement. The Cloud should match them with product IDs submitted before. If the match is successful, the newly submitted IDs are consolidated with the known ones. From now onwards all other Partners can refer to this product using either of the IDs from this list. 3. OEM IDs from this list all refer to the same manufacturer. For example, if a car has an RFID tag embedded in its keychain, the GS1 company prefix (GCP) from this tag and the WMI code from VIN must refer to the same company. These ideas are elaborated further in this chapter. 4.1 ID Management components

Based on analysis of the product information gathering process, the ID Management implementation is broken down into three components: 1. ID Mapping component converts a public product identifier to FPID at the second step of gathering product information during advertisement publishing. It can be deployed as part of either the Gateway or the Cloud. This is the only component that needs understanding of specific product identification schemes with the help of ID Mapping plugins. This activity is performed without human intervention. 2. ID Consolidation component processes FPIDs of submitted advertisements at the Cloud side, to extract all the data needed for ID resolution. For example, the registry of known OEMs is updated. This activity is performed without human intervention at the third step of gathering product information. 3. ID Resolution component is deployed in the Cloud and allows resolving an FPID or an FPID wildcard into other information associated with it first of all, list of advertisements. Therefore, it plays the central role in the search process (steps 4 and 5), defining e.g. what advertisements should be returned in response to a certain FPID. But the search is not limited to the ID Resolution, because there are other criteria that affect the search result. For instance, an Information Consumer may specify the needed type of events and information (providing a list of respective UDEF codes), and processing them is out of scope of this research. This activity may include interaction with a human. The detailed walkthrough of these activities is described in Chapter 6. 4.2 Federated product identifier

Federated product ID (FPID) is a globally unique identifier of an individual product instance that contains one or more ID tuples. Each ID tuple corresponds to a public product ID submitted with an advertisement and contains four elements:

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

1. ID scheme signifies a type of the product ID, for example SGTIN or MPN. It defines exact syntax and semantics of the following elements in the ID tuple. In case of SGTIN, the OEM ID must be GCP, whereas in case of MPN, the OEM ID must be an official company name. ID scheme is a plain string that can take a value from a list of the product identification schemes supported by the PREMANUS Network through plugins. For each ID scheme there must be a corresponding plugin that understands the semantics of this numbering scheme. The proposed solution aims at the distinct separation of the core components and plugins, so that new product identification schemes can be added easily. ID scheme does not specify the syntax of an originating public ID. Often a single identifier can be represented in many forms. For instance, SGTIN can be a string (EPC URI), a combination of GTIN and a serial number, or a binary (SGTIN-64 or SGTIN-96). Still this is the same identifier that refers to a particular product instance. For example, if Partners submit the same SGTIN in different forms, it may be processed by different ID Mapping plugins that must return the same ID tuple with the SGTIN ID scheme. 2. OEM ID is an identifier of the original manufacturer (i.e. the one who assigned this public identifier to the product). It must be unique within the specified ID scheme. 3. Item reference is an identifier of a class of products, e.g. a model number. It must be unique within a given OEM. 4. Serial number is an identifier of an individual instance of a product. It must be unique within a given Item reference. Two elements in an ID tuple are mandatory: ID scheme and serial number. It would be too restrictive to demand that a product ID always includes OEM ID and an item reference in some form. In the case when they are absent, the ID scheme by its nature must ensure that a serial number is sufficient to identify a product instance uniquely. A car license plate is an example of such product ID.

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Understanding semantics of a product identifier

As mentioned in Section 4.1, ID Mapping plugins are responsible for extracting OEM ID, an item reference and a serial number from a public identifier, and creating FPID. If several public identifiers referring to the same product are submitted together, the resulting FPID will have an ID tuple for each public ID. In addition, finding out a manufacturer name from this OEM ID can improve search capabilities, as will be shown in Section 6.3. Whereas Chapter 3 has provided a high-level description of the chosen identification schemes, this chapter explains in details, how respective ID Mapping plugins convert public identifiers into FPIDs. 5.1 SGTIN URI

Here is an example of identifiers that this ID Mapping plugin accepts: urn:epc:id:sgtin:0716123.012384.12345 This is EPC URI that consists of a namespace (till the last colon) and a body. As explained in Section 3.1, the only supported namespace is urn:epc:id:sgtin. The body of SGTIN consists of three numbers, delimited by dots: 1. GS1 company prefix (GCP) [7] varies from 6 to 10 digits in length. It is allocated to a managing entity by a local GS1 member organization in a respective country for a fee. This authority principle guarantees the worldwide uniqueness of the prefix. 2. Item reference varies from 3 to 7 digits in length. It is assigned by the managing entity to a class of identical objects. Total length of the GS1 company prefix and the item reference must be 13 digits [2, p. 30]. 3. Serial number is assigned by the managing entity to identify an individual item in a respective class. It may contain up to 20 digits and English characters [8, p. 99]. So, the conversion to FPID is trivial for this kind of identifiers. The first element becomes OEM ID, the second item reference, and the third serial number. The resulting ID tuple looks like this:

5.2

GTIN

Here is an example of identifiers that this ID Mapping plugin accepts: 716123123846;12345 Where the first part is GTIN itself (12 14 digits) and the second part is a serial number1. 12-digit number is UPC-12 (used mostly in the United States) 13-digit number is EAN-13 (European Article Number) or JAN-13 (Japanese Article Number) 14-digit number is a full GTIN-14

GTIN-8 is used only for small items, where a 12-digit number would not fit on the package. Since it is not the case in the remanufacturing context, this code is not supported in the prototype. UPC, EAN and JAN can easily be converted to GTIN-14 just by appending zeros in front. This is the first step in the conversion to FPID. Then its structure is dissected according to the following table:

Since a semicolon is rarely used within public IDs, it was chosen as a delimiter for all ID mapping plugins that need it.

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Indicator digit

GCP (6-10 digits)

Item reference (2-6 digits) 12384 Item reference 6

Check digit

Serial number (not part of GTIN) 12345 Serial number

0 Moved to front of the item reference

0716123 OEM ID

Dropped

Table 1 GTIN structure The resulting ID tuple looks like this:

As explained in Section 4.2, the ID scheme here must be SGTIN. Therefore, the name of this plugin corresponds to the syntax that it accepts rather than the ID scheme that it produces. The main problem for the plugin is to find out where GCP ends and an item reference number starts, since they vary in length. In GTIN the total length of GCP and the item reference is 12 digits. Companies that produce a lot of goods need longer item references, so they purchase shorter GCPs from GS1 that are more expensive. According to the latest ONS standard [9, p. 29] the right way to find a GCP length would be to make a NAPTR query to the ONS, get the pointer to the service that provides the full list of GCP lengths, and query it to get the right length for a given GCP. Unfortunately there is no such service today, at least officially. However, GS1 has published an XML file [10] that allows determining GCP length from the first GTIN digits. This file looks like this: <entry prefix="06" gcpLength="7"/> <entry prefix="07" gcpLength="7"/> <entry prefix="081" gcpLength="9"/> <entry prefix="084" gcpLength="8"/> With its help the plugin can find out that all GCPs starting from 07 are 7 digits in length. 5.3 VIN

Here is an example of identifiers that this ID Mapping plugin accepts: 1HGCM82633A004352 All VINs have 17 alphanumeric characters, structured according to the following table:

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

World Manufacturer Identifier (3 characters) 1HG OEM ID

Vehicle Descriptor Section (5 characters) CM826 Item reference 3

Check digit

Vehicle Identifier Section (8 characters) 3A004352 Serial number. If the third character in WMI is 9, then the 12 14th characters are appended to OEM ID

Dropped

Table 2 VIN structure As the VIN structure is known in advance, the VIN plugin can convert a VIN code to an ID tuple without external data sources. Still, finding out a respective manufacturers name is useful in the proposed ID Management method. In a production environment, the WMI database from SAE would be used for this purpose. For the prototype purposes, an online tool VIN View [11] is used to find out a manufacturer by VIN. The resulting ID tuple:

5.4

Vehicle license plates

Since formats of vehicle license plates vary depending on a country and region, the syntax in this case is more sophisticated compared to the previous ID schemes: <VLP> <countryCode type=UN>GB</countryCode> <plate>BD51SMR</plate> </VLP> This example contains the license plate BD51SMR and the country code of Great Britain as listed by the United Nations [6]. The XML format enables the flexibility needed e.g. when some plates include a state code and others do not. Although insignificant for the ID Management use cases, these elements should be preserved, because they may be interpreted by the Gateway or the Client. What is significant for the ID Management method, is that the OEM ID and Item reference elements must be empty (there is no manufacturer), and the serial number must be unique within the VLP ID scheme. Taking only the license plate itself would not guarantee uniqueness. Therefore, other elements, like a country code, should be merged into the serial number as well. The exact mechanism of this merge is up to developers of the plugin, because the reverse process is not needed, as will be shown in Section 6.1. In the prototype implementation the resulting ID tuple looks like this:

The plugin must also indicate to the core ID Mapping component that this is a reassignable identifier that must not be used to identify a product without a persistent identifier like VIN. This behavior is further explained in Chapter 7. 5.5 MPN

This plugin should be used to refer to a product by its manufacturer name, model number and serial number, for example:
10

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

AB SKF;VKN 350;5984 Model numbers and serial numbers can go directly into Item reference and Serial number in the ID tuple, under the assumption that they are taken from a products label or accompanying documentation without changes. However, different people and IT systems may refer to manufacturers by varying names. For example, an automobile repair shop may use Bayerische Motoren Werke, whereas a remanufacturer will search for BMW. The solution proposes to employ an instant answer engine that allows submitting an unofficial or abbreviated company name and retrieve an official company name that is inserted into the ID tuple as OEM ID. The following engines were evaluated for this purpose: DuckDuckGo.com for the search query BMW provides an instant answer of possible meanings, where the first one correctly refers to the automobile manufacturer. However, the text is taken from Wikipedia and is intended to be read by a human. It would be nearly impossible to extract the official company name from this text. WolframAlpha.com interprets the search query Philips as a male given name Philip, whereas the needed result is Koninklijke Philips Electronics N.V. It can be achieved with the query Philips company. But the same template applied as Vestas company yields Vestas (VWS) instead of Vestas Wind Systems A/S. Further attempts, trying to achieve some consistent output, continued but eventually failed. Wikidata.org is a knowledge base providing access to structured data migrated from Wikipedia. However, the migration process is far from completion, many needed entities are still missing, thus this project is not ready for production use. Freebase.com is a knowledge base provided by Google. It correctly interprets the search query Vestas and returns an entity page that has a name Vestas and a list of aliases: Vestas Wind Systems A/S and Vestas Wind Systems. The list of BMWs aliases includes Bayerische Motoren Werke and Bayerische Motoren Werke AG. Further experiments showed that this knowledge base provides data that closely matches the needs of the MPN plugin. So, it was chosen to be used in the prototype implementation. Evi.com already uses Freebase as one of its information sources, and does not have any additional benefit for the prototype.

Experimenting with Freebase has shown that the notion of official company names would not bring any benefit for the ID Management method. One can argue that an acronym indicating a type of the business entity, like Inc. should be included in the OEM ID, others may disagree with this. Apparently, the element name of an entity in Freebase uniquely identifies the entity, thus it can be taken as the OEM ID. The mid element that is the URL of the entity may be used as well. The list of aliases should be cached, so that the plugin at first looks in the local storage, and only if nothing is found, the request to Freebase is made. A brand name may be used as the OEM ID just like a company name. Freebase provides the means to find out the owner of a brand, so that the Cloud can be made aware of this link, still distinguishing between the two entities. The resulting ID tuple:

11

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Collaboration of the ID Management components

The following UML sequence diagrams show how the ID Management system is decomposed into services, and what messages they accept. 6.1 ID Mapping

This workflow starts when the Gateway sends a message to the ID Mapping core service asking to convert a public ID to FPID. An example message: ConvertToFpid (GTIN, 716123123846;12345) Both parameters are plain strings. The first parameter specifies the syntax of the public ID. The second parameter is a public ID itself. In this particular example it is a GS1 key UPC-12 and a serial number.

Figure 3 ID Mapping workflow The core service dispatches the request to the corresponding plugin according to the ID scheme. All these plugins must conform to a common interface. In this case it is the plugin that understands the syntax and semantics of GTIN codes. It converts the public ID to an ID tuple according to the steps described in Chapter 5. If a query to a third-party web service is required, a local cache may be used to speed up this process. If a company name of the OEM ID is available from such a web service, the plugin should submit it to the ID Consolidation component, described in the next section. This submission is performed separately from the advertisement, and its format and timing is out of scope of this deliverable and would not affect the proposed method. Here is an example output of an ID Mapping plugin: <idTuple> <idScheme>SGTIN</idScheme> <oemId>0716123</oemId> <itemRef>012384</itemRef> <serialNo>12345</serialNo>

12

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

</idTuple> The core service adds scheme-agnostic data and passes it back to the requestor: <fpid> <idTuple originalId="716123123846;12345"> <idScheme>SGTIN</idScheme> <oemId>0716123</oemId> <itemRef>012384</itemRef> <serialNo>12345</serialNo> </idTuple> </fpid> Then the FPID is inserted in the advertisement and posted to the Cloud. The originalId attribute contains the public ID exactly as it was passed to the ID Mapping service. It is needed for the Information Provider to look up product data in its internal databases at the step 7 of the product information gathering process. Also it may be interpreted by the Client software e.g. to display in GUI. Several public IDs that refer to the same product instance may be supplied to the ID Mapping service together in order to support the following use case. Consider a car dealer that has sold a car and wants to publish an advertisement about it to the PREMANUS Network. They may submit both the VIN of the car and the SGTIN encoded in the RFID tag in the keychain. In this case the ID Mapping service must accept a list of pairs (publicIdType, publicId), and for each pair a corresponding plugin is invoked. The resulting FPID looks like this: <fpid> <idTuple originalId="716123123846;12345"> <idScheme>SGTIN</idScheme> <oemId>0716123</oemId> <itemRef>012384</itemRef> <serialNo>12345</serialNo> </idTuple> <idTuple originalId="1HGCM82633A004352"> <idScheme>VIN</idScheme> <oemId>1HG</oemId> <itemRef>CM826</itemRef> <serialNo>3A004352</serialNo> </idTuple> </fpid> This FPID will be consolidated in the Cloud with known FPIDs, and from now onwards all other Partners can refer to this car using either of these public IDs, whatever is more suitable for them.

13

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Essentially, the call to the ConvertToFpid operation means May I use this public identifier to refer to a product? If for some reason (e.g. an invalid check digit in GTIN) the answer is negative, and the ID Mapping service throws an exception, the Information Provider will have to handle it. This is the reason why ID Mapping must be performed prior to posting advertisements, even if the ID Mapping component is deployed in the Cloud. If it was allowed to post advertisements with public IDs, and the ID Mapping process was performed post factum, it would complicate exception handling and hinder performance predictability, since an ID Mapping plugin may call external web services. The ID Mapping service is stateless, and its output depends solely on the input. Particularly, it allows easy scalability through replication. 6.2 ID Consolidation

Upon receiving an advertisement from an Information Provider, the ID Consolidation component, deployed in the Cloud, will process it and update the following persistent collections, stored in the Cloud: 1. Product collection, where each entry contains a set of advertisements grouped by a product instance, identified by a consolidated FPID that includes all known ID tuples of this product. All FPIDs in these entries are unique. Each ID tuple from a submitted FPID is matched with FPIDs in the collection. If there is FPID with a matching ID tuple, the new ID tuples are added to the existing FPID, and the new advertisement is added to the existing ones respectively. Otherwise, the new FPID and advertisement are added to the collection as a new entry. Advertisement content (including FPID) is always stored as submitted by an Information Provider, without changes. 2. OEM collection, where each item describes a manufacturer with a set of OEM IDs of respective schemes. At first, from the submitted FPID, OEM IDs and their ID schemes are taken. Then the component tries to match at least one submitted OEM ID with known OEM IDs with respect to the schemes. If it fails, but a manufacturer name from the ID Mapping plugin is available, it is matched with known OEM IDs from the MPN ID scheme (this is the only case when distinguishing between ID schemes is needed outside ID Mapping). In the prototype implementation this is implemented as a simple string case-insensitive comparison. More advanced implementation may choose to use fuzzy string comparison or drop insignificant parts of a company name, like Inc. If the match fails, a new manufacturer record is added to the collection. A manufacturer record may have multiple OEM IDs of the same scheme. For example, Daimler can register several GCPs, in case a single prefix is not sufficient for their business. In the case of the MPN scheme, several OEM IDs refer to distinct, but still related legal entities or brands. These two tuples should belong to the same OEM entry, because e.g. the same GCP may be used to identify cars of several brands belonging to Daimler. 6.3 ID Resolution

The ID Resolution component is responsible for resolving an FPID wildcard into other information associated with it and stored in the Cloud. Here is a sample XML that an Information Consumer can submit to the ID Resolution component: <fpidWildcard> <idScheme>SGTIN</idScheme>

14

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

<oemId>0716123</oemId> <itemRef>012384</itemRef> <serialNo>*</serialNo> <result>advertisements</result> </fpidWildcard> The main differences between an FPID wildcard and an ID tuple are: Each of its elements (except <result>) may be replaced with an asterisk1 or simply skipped, if it is not known or important to the Information Consumer, or it does not make sense for a particular ID scheme (e.g. a vehicle license plate cannot have OEM ID and item reference). Also, a numeric range (e.g. [200-350]) can be used for OEM ID, item reference and serial number, but it will match only elements with a numeric value. The <result> element specifies what kind of result is needed. In this case the list of matching advertisements will be returned.

In this example the Information Consumer is interested in advertisements that refer to any instance of the product that is identified by any form of SGTIN with the specified OEM ID and item reference. The possible values for the <result> element are: 1. advertisements the wildcard is matched against each ID tuple in the consolidated FPIDs. More than one FPID can be matched, and advertisements grouped by respective FPIDs are returned. If no asterisks or ranges are used, the size of the result set will be more than one only for reassignable IDs. 2. fpid the resolution is the same as for advertisements, except that consolidated FPIDs are returned without advertisements. This case is needed e.g. when converting a reassignable public ID to FPID. 3. oemInfo to retrieve entries from the OEM collection. In the most common use case, when the wildcard specifies only an ID scheme and OEM ID, the result will have only single or no elements. This design provides support for two basic use case scenarios for an Information Consumer: search by public ID and multistep search. Search by a public ID is used when an Information Consumer knows one of public IDs of a product instance. Since the ID Resolution component accepts only FPID wildcards2, the public ID at first is sent to the ID Mapping service3.

1 2

This syntax is similar to EPC Tag Pattern URI [2, p. 76].

Allowing the ID Resolution component to accept public IDs would require understanding of various product identification schemes, and thus would violate the system decomposition described in Section 4.1.
3

Note the use of terms service vs. component. ID Mapping should be a RESTful or SOAP service. It is deployed in the Cloud and must be accessible to the Gateway and the Client. Whereas ID Consolidation and ID Resolution are internal software components of the Cloud, and do not need to be accessible from outside. Thus, developers are free to choose how they are implemented and invoked.

15

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Figure 4 Search by a public ID Then the Client software submits this wildcard together with other search criteria to the Cloud. In turn it passes the wildcard to the ID Resolution component and gets back a list of advertisements that is further processes by the Cloud and finally returned to the Client. Here is an example of a search query: <search> <fpidWildcard> <idScheme>VLP</idScheme> <serialNo>GBBD51SMR</serialNo> <result>advertisements</result> </fpidWildcard> <content> <udef>a.c.h.2_24.8</udef> <udef>9_11.14.14</udef> </content> <provider> <accessRestriction>public</accessRestriction> </provider> </search> It stands for Give me advertisements referring to cars this plate was assigned to. The advertised content must be Bill of materials or Product Status Definition. Respective information providers allow public access. Having structured the query this way, it becomes easier for the Cloud to dissect it into parts that must be processed by different components, connected into a pipeline. <fpidWildcard> is passed to the ID Resolution, then the resulting advertisements are filtered by another component that understands

16

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

<content>, the result is passed to the third component that understands <provider> and finally passed back to the Client. The following diagram provides an example scenario of a multistep search. It demonstrates use of various <result> elements. Here a user starts with asking for company information about Daimler. The result in particular contains the Daimlers WMI code (1B6) that is submitted to find FPIDs of all Daimler cars that have a VIN known to the Cloud. From the returned list a specific VIN is chosen and corresponding advertisements are retrieved.

Figure 5 Multistep search The intermediate lifeline of the Cloud is skipped for clarity. As the ID Resolution component does not need understanding of specific product ID schemes and consuming external data sources, the time to resolve an FPID wildcard depends solely on the performance of the underlying database storing the Product and OEM collections. 6.4 Assembly Traversal

Retrieving information about a single component may not always be sufficient to make a remanufacturing decision. For example, when analyzing a car engine, maintenance information about the car itself (or even multiple cars, if the engine was moved from one to another) is needed as well. Therefore, an Information Consumer must be able to traverse recursively parent and child assemblies. After retrieval of product information a user can find out what components this product has or to which assembly belongs. The QLM standard supports this with the PART_OF class that specifies parent-of and child-of links. Two alternative solutions were investigated: Allow the Client to submit complex queries asking for advertisements that refer to parent and child assemblies of a given public ID. So, the Cloud discovers these links and traverses them. Perform the traversal on the client side, performing several search rounds.

The only advantage of the first approach is reduced amount of network communication, and therefore
17

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

reduced latency. However, it would require all advertisements to include PART_OF data, and it would complicate the implementation of the Cloud. Moreover, not all Information Providers would like to share this data with the Cloud. The overall design guideline of the PREMANUS Network is that minimal amount of data should be published in advertisements. Also, the second approach provides more flexibility for specific use cases, and the user can control the process. Therefore, the second approach was chosen, and the following diagram provides the overview:

Figure 6 Assembly traversal workflow These are the necessary steps in the process: 1. The Client submits a search query to the Cloud and retrieves matching advertisements. 2. The needed advertisements are chosen, and a query for product information is submitted to the corresponding Gateways. This query contains FPID of the examined product and UDEFs that signify what kind of information is needed particularly the PART_OF data. 3. The Gateway gathers the product data and converts it to the QLM format. Also the ID Mapping service is invoked to convert public IDs to FPIDs. The PART_OF data will contain FPIDs of a parent and all child assemblies. 4. The Client software extracts these FPIDs and submits them in the next search query to the Cloud. Whether all FPIDs or a chosen subset is submitted may depend on users preferences or requirements of a particular decision process. 5. The returned advertisements are used to retrieve further information about parent and child assemblies. For example, if initially a car engine number was submitted, a car itself will be a parent assembly, and all components of the engine that have serial numbers will be child assemblies.

18

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

This process can be repeated recursively to retrieve more information. Unlike the three previous sections, this workflow is not a component of the ID Management method per se, but rather an example how the previously described three components can be combined to gather more data about a product.

19

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Reassignable product identifiers

Until now the research assumed that a link from a product identifier to a physical product is persistent, i.e. an identifier is assigned once and forever. Although this assumption is valid for most product identification schemes supported in the prototype, the vehicle license plate is an exception. Including support for this scheme has extended the research to look into issues specific to reassignable product identifiers. These are tags that can be easily moved from one product to another, while the former one still exists. As a consequence, they do not have any link to OEM ID or an item reference, so the respective elements in the ID tuple will be empty. As will be shown in this section, these identifiers are less reliable than persistent identifiers, require extra care, and thus should be avoided when possible. Although all examples in this section refer to VLPs, the proposed method is sufficiently generic to support other types of reassignable IDs. Consider the following use case. A car (e.g. BMW) arrives in a garage for maintenance. A technician writes down the performed work and identifies the car by its license plate. Later the cars owner decides to sell the BMW and buy e.g. Porsche, and he retains the old registration plate. When he comes to this garage again, the technician will be confused, as by the logs this registration plate belongs to a BMW. In order to resolve this issue, the technician should search for this plate number in the Cloud, retrieve the respective VIN, and identify whether this plate number still points to a correct VIN. If the VIN points to a BMW, but instead it is a Porsche, the technician has to look for its VIN on the chassis and post the advertisement to the Cloud that the registration plate was changed. Mapping this use case to the workflows described in the previous section, here is how an advertisement with VLP must be posted to the Cloud:

Figure 7 Posting an advertisement with a vehicle license plate Compared to the workflow described in Section 6.1, an additional step with ID Resolution is required. Here the process starts when the Gateway requests the ID Mapping service to convert a license plate number to FPID. This FPID is submitted to the ID Resolution component (the intermediate lifeline of the Cloud is skipped for clarity) and resolved into a consolidated FPID that contains both the same VLP and a VIN. The Gateway verifies that the VIN is correct and posts an advertisement with this consolidated FPID. This workflow assumes that somebody else has already associated the VLP with the VIN. Alternatively, if the Partner already knows both VLP and VIN, the usual workflow from the Section 6.1 is followed on condition, that the ID Mapping service is provided with both IDs.

20

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Here is an example of FPID with VLP that must be posted with an advertisement: <fpid> <idTuple originalId= "..."> <idScheme>VLP</idScheme> <serialNo>GBBD51SMR</serialNo> <observedOn>2013-02-25</observedOn> </idTuple> <idTuple originalId="1HGCM82633A004352"> <idScheme>VIN</idScheme> <oemId>1HG</oemId> <itemRef>CM826</itemRef> <serialNo>3A004352</serialNo> </idTuple> </fpid> The additional XML element <observedOn> specifies the date, when this license plate was observed together with the VIN. In most cases it will be the date of the advertised event. So why does an Information Provider need to go through this extra hassle? The motivation behind this design decision is based on the following points: A vehicle license plate alone is not sufficient to identify a vehicle reliably in the middleware that deals with historical data (like the PREMANUS Network). Therefore, posting an advertisement just with a license plate must be forbidden. The Information Provider takes the responsibility, that the information in a submitted advertisement is correct. Particularly, if two persistent product identifiers are submitted together, the Information Provider guarantees that they do link to the same physical product. If a pair of reassignable and persistent identifiers is posted together, the Information Provider cannot guarantee that they will link to the same physical product in any point in time. The only thing that can be guaranteed, is that the reassignable ID was associated with the persistent ID in a certain point in time (specified in the <observedOn> element), when the advertised event (like car maintenance) took place. The Information Provider can share product data only if an Information Consumer finds respective advertisements in the Cloud. Putting more data in an advertisement (like a license plate in addition to VIN) increases chances to be found.

If an Information Provider knows when a license plate was attached or detached from the car, this data may be put into <assignedOn> and <assignedTill> XML elements next to the <observedOn> element. Having this data is not mandatory for the ID Management method, but useful. These three elements may be of type xs:date or xs:dateTime, depending on an industry domain and use case scenarios. In the prototype implementation, only a date is specified. The ID Consolidation component uses this data to consolidate reassignable IDs. For example, if multiple advertisements with the same pair (VIN, VLP) and different <observedOn> dates are published, the consolidated FPID will have only the earliest and the latest date.
21

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Conclusion

Due to the remanufacturing context, linking a product to its original manufacturer has crucial importance. Moreover, the literature review showed that various widely accepted standards, like EPC, VIN, IMEI and USB VID, follow the same triplet in product IDs: OEM ID, item reference, serial number. That is why this pattern became the foundation of the proposed ID Management method. If two product identifiers have equal ID scheme and the triplet, they must refer to the same product. In spite of differences among the product data sources, the ID Mapping mechanism ensures that different Partners can submit various product IDs referring to the same product, and the Cloud will be able to preserve this identity. A vehicle license plate is an example of a product ID that does not fit into this triplet, but still is important for remanufacturing. Instead of a manufacturer identifier, it may have a country and state code, giving a link to a geographical location of a product. However, in our context this knowledge has no value (at least, as of now), so ID Consolidation and Resolution do not handle this structure. That is why all content of a license plate is put into the third element of the triplet serial number. A prototype of the ID Mapping service has been developed in Java. It consumes three third-party web services: 1. GEPIR is used to find out a manufacturers name by GTIN. 2. Freebase is used by the MPN ID Mapping plugin to resolve different names referring to the same company or brand. 3. VIN View is used to find out a manufacturers name by VIN. Implementation of the ID Consolidation and ID Resolution components was not done yet, since it depends heavily on other components in the PREMANUS Cloud, especially the database. Once these issues are solved, their implementation will consist of a few database queries, and should be fairly trivial.

22

Project No Date Classification

285541 31-May-13 PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

Appendix A: References

[1] JISC, "Information object numbering systems (IONS)," Joint Information Systems Committee, Manchester, 1999. [2] GS1, EPC Tag Data Standard 1.6, GS1 AISBL, 2011. [3] IANA, "Uniform Resource Names (URN) Namespaces," 2013. [Online]. Available: http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml. [4] Wikipedia, "Vehicle Identification Number," 20 April 2013. [Online]. Available: http://en.wikipedia.org/w/index.php?title=Vehicle_Identification_Number&oldid=551218351. [5] SAE Global Standardization, "WMI/VIN Information," [Online]. Available: http://www.sae.org/standardsdev/groundvehicle/vin.htm. [6] Wikipedia, "List of international vehicle registration codes," 18 April 2013. [Online]. Available: http://en.wikipedia.org/w/index.php?title=List_of_international_vehicle_registration_codes. [7] GS1 US, "The GS1 Company Prefix," [Online]. Available: http://www.gs1us.org/resources/standards/company-prefix. [8] GS1 Australia, "GS1 Application Identifiers (AIs)," 2010. [Online]. Available: http://www.gs1au.org/assets/documents/info/user_manuals/a/gs1_application_identifiers.pdf. [9] GS1, Object Name Service (ONS) Version 2.0.1, Global Standards One, 2013. [10] GS1, "Global Company Prefix (GCP) Length Tool," 31 January 2013. [Online]. Available: http://www.gs1.org/gcp_length. [11] AnalogX, "VIN View," 6 May 2009. [Online]. Available: http://www.analogx.com/contents/vinview.htm.

23