d3.1_out

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.

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 WP3: Remanufacturing Information Services

Lead Partner 1: SAP

Security Classification PU (Public)

Date 31 May 2013

Version 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.”

Project –No Date

Classification

285541 31-May-13

PU

D3.1 - THE PRODUCT ID MAPPING AND RESOLUTION STRATEGY

ii

Document history

Version Date Comments Author

1.0 06/03/13 First version Petro Kazmirchuk (SAP)

1.1 15/03/13 Revision of 1st Version Oscar Garcia (TIE)

1.2 22/03/13 Finalizing the document Nicolas Liebau (SAP)

1.3 31/05/13 Major update. Petro Kazmirchuk (SAP)

The research leading to these results has received funding from the European Community’s Seventh Framework Programme

(FP7/2007-2013) under grant agreement no285541.

Project –No Date

Classification

285541 31-May-13

PU


iii

Table of contents

1 EXECUTIVE SUMMARY .......................................................................................................................... 1

2 INTRODUCTION ........................................................................................................................................ 2

3 PRODUCT IDENTIFICATION SCHEMES ............................................................................................. 4

3.1 ELECTRONIC PRODUCT CODE .................................................................................................................. 4 3.2 VEHICLE IDENTIFICATION NUMBER......................................................................................................... 5 3.3 VEHICLE LICENSE PLATE ......................................................................................................................... 5 3.4 MANUFACTURER PART NUMBER .............................................................................................................. 5

4 ID MANAGEMENT METHOD.................................................................................................................. 6

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

5 UNDERSTANDING SEMANTICS OF A PRODUCT IDENTIFIER ..................................................... 8

5.1 SGTIN URI ............................................................................................................................................. 8 5.2 GTIN ....................................................................................................................................................... 8 5.3 VIN ......................................................................................................................................................... 9 5.4 VEHICLE LICENSE PLATES ...................................................................................................................... 10 5.5 MPN ..................................................................................................................................................... 10

6 COLLABORATION OF THE ID MANAGEMENT COMPONENTS ................................................. 12

6.1 ID MAPPING .......................................................................................................................................... 12 6.2 ID CONSOLIDATION ............................................................................................................................... 14 6.3 ID RESOLUTION ..................................................................................................................................... 14 6.4 ASSEMBLY TRAVERSAL ......................................................................................................................... 17

7 REASSIGNABLE PRODUCT IDENTIFIERS........................................................................................ 20

8 CONCLUSION ........................................................................................................................................... 22

9 APPENDIX A: REFERENCES ................................................................................................................. 23

Project –No Date

Classification

285541 31-May-13

PU


iv

List of abbreviations

BoL Beginning-of-life (of a product)

DMZ Demilitarized zone

EoL End-of-life (of a product)

EPC Electronic Product Code

EPCDS EPC Discovery Services

EPCIS EPC Information Services

FPID Federated product identifier

GCP GS1 company prefix

GEPIR Global Electronic Party Information Registry

GTIN Global Trade Item Number

GUI Graphical user interface

MoL Middle-of-life (of a product)

MPN Manufacturer part number

NAPTR Name Authority Pointer

OEM Original equipment manufacturer

ONS Object Name Service

REST Representational State Transfer

UPC Universal Product Code

VIN Vehicle Identification Number

VLP Vehicle license plate

WMI World Manufacturer Identifier

Project –No Date

Classification

285541 31-May-13

PU


1

1 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 up-

to-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


2

2 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:

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.

Cloud

Gateway

Client

1. Register

4. Search

5. Matching

advertisements

with FPIDs

6. Request

by FPID

3. Post advertisements

7. Return

product data

2. Gather

product

data

Figure 1 – Sharing and searching for product data in the PREMANUS Network

Project –No Date

Classification

285541 31-May-13

PU


3

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:

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 product’s 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.

FPIDs

Public IDs DMZ

Internal IDs Infrastructure of

the information provider

Figure 2 – Different types of product identifiers

Project –No Date

Classification

285541 31-May-13

PU


4

3 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 manufacturer’s 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


5

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


6

4 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


7

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


8

5 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


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:

1 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


9

Indicator digit GCP (6-10 digits) Item reference

(2-6 digits)

Check digit Serial number

(not part of

GTIN)

0 0716123 12384 6 12345

Moved to front of

the item reference

OEM ID Item reference Dropped Serial number

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"/>




With its help the plugin can find out that all GCPs starting from 07 are 7 digits in length.

5.3 VIN


1HGCM82633A004352

All VINs have 17 alphanumeric characters, structured according to the following table:

Project –No Date

Classification

285541 31-May-13

PU


10

World Manufacturer

Identifier (3

characters)

Vehicle Descriptor

Section (5 characters)

Check

digit

Vehicle Identifier Section (8

characters)

1HG CM826 3 3A004352

OEM ID Item reference Dropped Serial number. If the third

character in WMI is 9, then the 12

– 14th characters are appended to

OEM ID

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 manufacturer’s 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:

Project –No Date

Classification

285541 31-May-13

PU


11

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 product’s 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 BMW’s 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:

Project –No Date

Classification

285541 31-May-13

PU


12

6 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>

Project –No Date

Classification

285541 31-May-13

PU


13

</idTuple>

The core service adds scheme-agnostic data and passes it back to the requestor:

<fpid>

<idTuple originalId="716123123846;12345">





</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">





</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.

Project –No Date

Classification

285541 31-May-13

PU


14

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>


Project –No Date

Classification

285541 31-May-13

PU


15



<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 This syntax is similar to EPC Tag Pattern URI [2, p. 76].

2 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.

Project –No Date

Classification

285541 31-May-13

PU


16

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

Project –No Date

Classification

285541 31-May-13

PU


17

<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 Daimler’s 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

Project –No Date

Classification

285541 31-May-13

PU


18

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 user’s 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.

Project –No Date

Classification

285541 31-May-13

PU


19

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.

Project –No Date

Classification

285541 31-May-13

PU


20

7 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 car’s 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.

Project –No Date

Classification

285541 31-May-13

PU


21

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.

Project –No Date

Classification

285541 31-May-13

PU


22

8 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 manufacturer’s 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 manufacturer’s 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.

Project –No Date

Classification

285541 31-May-13

PU


23

9 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.

d3.1_out

Documents