Digital Twin 202 - Configurations avec le service de résolution d'identité (IRS)
Prérequis
Introduction
Le service de résolution d'identité (IRS) est un composant clé du fonctionnement de Vuforia Studio. Il est partie intégrante de l'Experience Service auquel votre expérience se connecte et qui gère les mappages utilisés pour lier des identificateurs, tels que des codes-barres ou des ThingMarks à une expérience donnée. C'est également l'élément qui permet de différencier les expériences Vuforia Studio les unes des autres.
Sous sa forme la plus simple, l'IRS fournit un moyen de mapper un URN (Uniform Resource Name) à une valeur. L'URN peut, par exemple, représenter un ThingMark, et la valeur peut être une référence à une expérience. Lorsque vous publiez l'expérience à partir de Vuforia Studio, un lien est créé entre le ThingMark et l'expérience, comme illustré ci-dessous (voir image 1 ci-dessous).
Lorsque vous publiez des expériences, vous avez également la possibilité d'utiliser le même ThingMark ou d'en utiliser un autre. Par exemple, vous pouvez avoir créé une expérience de réalité augmentée portant sur le fonctionnement et une expérience de réalité augmentée portant sur la maintenance. Chacune d'elles possède un contenu différent, mais vous souhaitez qu'elles soient toutes deux liées au même ThingMark. Le ThingMark peut être lié à un produit spécifique, voire même à un numéro de série particulier de ce produit (voir image 2 ci-dessous). Une fois que vous avez scanné le ThingMark, Vuforia View vous demande quelle expérience vous souhaitez exécuter.
L'IRS est un outil de mappage générique très flexible qui permet de créer des collections de données très riches. Dans l'image 3 ci-dessous, nous montrons le mappage d'un URN (dans cet exemple un ThingMark) à un élément intermédiaire (un autre URN), lui-même mappé à l'expérience et à deux valeurs de propriété.
Lorsque vous scannez ce ThingMark, l'IRS parcourt la structure pour collecter toutes les valeurs.
L'IRS fonctionne de la façon suivante (voir le diagramme ci-dessous, de la droite vers la gauche) :
1. Un ThingMark unique est scanné (1).
2. Ce ThingMark est mappé à l'URN (Uniform Resource Name) d'un objet qui contient la configuration spécifique d'un modèle d'objet (2).
3. Le modèle d'objet est ensuite mappé à une expérience publiée qui est présentée à un utilisateur dans Vuforia View (3).
Les différents URN rencontrés sont rassemblés, et les valeurs de leurs propriétés sont fournies dans le résultat. Dans certains cas, la valeur peut être utilisée comme paramètre (par exemple, la valeur remplacée par le nom, si référencé dans le résultat). Dans l'exemple ci-dessus, les valeurs de propriété collectées peuvent représenter des attributs du modèle, tels que la couleur et le prix, et ces valeurs peuvent s'afficher dans l'expérience lors de son lancement.
Dans l'exemple final ci-dessous, vous pouvez voir une autre propriété de l'IRS. Le chemin de la valeur ne doit pas nécessairement être unique. Ainsi, plusieurs URN de départ (trois ThingMarks différents dans cet exemple) peuvent collecter des valeurs de propriété différentes durant le processus. Cependant, tous pointent vers la même expérience (voir image 4 ci-dessous). Comme indiqué ci-dessus, la valeur finale, l'expérience, peut substituer les différentes valeurs de propriété qui ont été rassemblées, de sorte qu'à son lancement, l'expérience est configurée pour représenter exactement l'état du produit identifié par le ThingMark scanné.
A ce stade, nous sommes pratiquement en mesure de modéliser notre jumeau numérique pour pouvoir identifier de manière unique l'instance d'un élément, à l'aide de la technique choisie, par exemple, des ThingMarks ou des codes-barres. Nous pouvons ainsi gérer toutes les informations relatives à cette instance de produit unique.
Dans cette section du tutoriel, nous allons présenter tous les concepts mentionnés ci-dessus, et les illustrer par un exemple montrant comment gérer une flotte de produits (des quadrirotors dans ce cas d'utilisation) où chaque produit conserve ses propres valeurs pour les éléments suivants :
• Représentation
• Configuration : des modèles différents équipés d'accessoires différents
• Identité : dans cet exemple, la couleur du quadrirotor
Nous allons également vous expliquer comment utiliser ThingWorx en permettant à chaque objet physique sa propre présence IoT.
| Bien que ce ne soit pas le cas ici, ThingWorx peut également être utilisé pour conserver toutes les informations associées au fonctionnement d'un modèle, telles que la consommation de batterie, la vitesse du vol, etc. Toutefois, l'intégralité de ce cas d'utilisation peut être utilisée comme point de départ pour créer une expérience plus complète incluant des informations sur le fonctionnement du modèle. |
L'expérience que nous sommes en train de créer nécessite un certain nombre de paramètres que nous allons définir à l'aide des valeurs de propriété stockées dans l'IRS :
• Couleur
• Nom de l'objet dans ThingWorx qui représente l'objet spécifique
• Nom de la représentation visuelle du modèle
Au fur et à mesure que l'IRS parcourt le mappage d'URN, il rassemble les valeurs de propriété mentionnées ci-dessus pour les transmettre au modèle. Ici, le nom est remplacé par la valeur.
Cette section va vous guider tout au long des étapes de création des mappages de votre expérience.
