The Identity Resolution Service (IRS) is a key component to understanding how Vuforia Studio works. It’s part of the of the Experience Service that your experience connects to that manages mappings used for linking identifiers, like bar codes or ThingMarks, to a certain experience. This is also what makes Vuforia Studio experiences different from one another.

In its simplest form, the IRS provides a way to map a URN (Uniform Resource Name) to a value. For example, the URN might represent a ThingMark, and the value might be a reference to an experience. Then, when you publish the experience from within Vuforia Studio, a link between the ThingMark and the experience is created as shown in the image below (See image 1 below).

When publishing experiences, you also have the option to use the same ThingMark, or a different one. For example, you may have created an Operational AR experience and a Service AR experience; each experience might contain different content, but you still want them linked to the same ThingMark. The ThingMark could be linked to a specific product, and perhaps even a specific serial numbered product (See image 2 above). Once you scan the ThingMark, Vuforia View asks you which experience you want to run.

The IRS is a very flexible and generic mapping tool which allows you to create rich collections of data. In image 3 below, we show how a URN (in this example, a ThingMark) can be mapped to an intermediate item (another URN), which in turn is mapped to the experience and also a couple of property values.

When this ThingMark is scanned, the IRS will traverse this structure, collecting all the values along the way.

The IRS works in the following way (see the diagram below from right to left):

The various URNs that are visited are gathered, and the value of their properties are delivered in the result. In some cases, the value may be used as a parameter (for example, the value being substituted for the name if referenced in the result). In the example above, the property values collected may represent attributes of the model, like color or price, and these values can be displayed in the experience when it is launched.

In the final example below, you’ll see another property of the IRS. The path to the value does not have to be unique. For example, there can be multiple starting URNs (three different ThingMarks in this example) that can gather different property values along the way. However, they all lead to the same experience (See image 4 below). Just as above, the final value, the experience may substitute the various property values that were gathered along the way, so that when the experience is launched, it is configured to represent the exact state of the product that is identified by the ThingMark that was scanned.

At this point, we’re close to being able to model our digital twin so that we can uniquely identify an instance of an item using different techniques (for example, ThingMarks or barcodes) in order to manage all of the information pertaining to the unique product instance.

In this section of the tutorial, we’ll demonstrate all of the concepts mentioned above while building up to an example of how you might manage a fleet of products (quadcopters in this use case) where each product maintains its own values for the following:

We will also show how to utilize ThingWorx by allowing each physical object its own IoT presence.

The experience we’re creating will take a number of parameters which we will define using property values stored in the IRS:

As the IRS navigates the URN mapping, it will gather the property values mentioned above and propagate them to the template. Here, the name is substituted by the value.

This section walks you through the steps to create the mappings of your experience.