Premiers pas avec ThingWorx > La programmation pour l'IoT > Modélisation : pourquoi des formes d'objet et des modèles d'objet sont-ils disponibles ?
Modélisation : pourquoi des formes d'objet et des modèles d'objet sont-ils disponibles ?
Dans la mesure où le modèle ThingWorx est orienté objets, vous pouvez définir des "composants" réutilisables, puis les utiliser afin de définir les objets du modèle. Toute modification apportée aux composants réutilisables est automatiquement appliquée aux objets définis par ces composants. Il s'agit de définir des comportements au même endroit et de faire en sorte que l'intégralité des objets hérités se comportent selon la définition actuelle des objets parents. Ainsi, vous n'êtes pas contraint d'apporter les mêmes modifications à de nombreux objets lorsqu'il est nécessaire d'appliquer une mise à jour.
Les formes d'objet et les modèles d'objet ont été implémentés pour que l'actualisation du modèle d'héritage puisse être effectuée facilement. Les formes d'objet sont les composants de définition de base. Lorsqu'un objet ou un modèle d'objet doit partager la définition d'une forme d'objet, l'objet ou le modèle d'objet "implémente" la forme d'objet. Les formes d'objet doivent généralement avoir des comportements uniques, ce qui signifie qu'elles exécutent un ensemble unique de services et de fonctionnalités. Un modèle d'objet peut implémenter plusieurs formes d'objet. Il est recommandé d'utiliser un modèle d'objet pour définir un objet.
Prenons un exemple simple. Un site possède plusieurs types d'équipements différents. Les équipements du site remplissent des fonctions très différentes. Pour simplifier l'exemple, imaginons que ces équipements se décline dans les trois types suivants :
Transformateur
Mélangeur
Centrale de traitement d'air
Admettons que le site comporte cinq transformateurs, vingt centrales de traitement d'air et douze mélangeurs. Ces trois types d'équipement sont très différents. Mais peut-être partagent-ils également des points communs. Supposons que ces équipements sont suivis par le système ERP de l'entreprise et qu'ils partagent donc des données communes (propriétés d'objet). Partons également du principe que les centrales de traitement d'air et les transformateurs doivent régulièrement fournir des données au système de gestion de maintenance pour appliquer la maintenance conditionnelle (CBM).
Pour analyser ce modèle physique et décider comment le convertir en un modèle ThingWorx, il nous faut prendre en compte trois regroupements distincts de comportement :
1. Comportement d'actif ERP
2. Comportement de maintenance conditionnelle (CBM)
3. Comportement spécifique au type d'équipement
Dans cet exemple, vous devriez idéalement définir au moins deux formes d'objet pour tirer profit du fonctionnement du modèle ThingWorx. Ils se présentent comme suit :
1. Forme d'objet Actif_ERP : il s'agit du point commun entre les trois types d'équipement du site. Ainsi, toute modification apportée à la forme d'objet Actif_ERP serait automatiquement appliquée à chaque équipement du site.
2. Forme d'objet Actif_CBM : puisque cette fonctionnalité est nécessaire pour plusieurs types d'actifs, définissez-la en tant que forme d'objet pour que les objets qui l'implémentent puissent hériter des modifications qui y sont apportées. Si la maintenance des mélangeurs devient un jour conditionnelle, il sera possible de paramétrer le modèle d'objet (explication ci-dessous) pour que les mélangeurs implémentent cette forme d'objet, sans devoir mettre à jour les mélangeurs individuellement.
Vous pouvez désormais créer un modèle d'objet pour chaque type d'équipement, soit trois modèles. Les modèles d'objet ont été conçus pour faciliter la création et l'actualisation des objets basés sur une définition spécifique. Dans le présent exemple, utiliser un modèle d'objet pour chacun des trois équipements vous permet de créer un objet qui représente un actif spécifique en utilisant simplement le modèle d'objet concerné pour donner un nom unique à cet objet.
Modèle d'objet de transformateur
Le modèle d'objet de transformateur serait défini par l'implémentation des formes d'objet Actif_ERP et Actif_CBM. Il faudrait également définir l'intégralité des propriétés, services, événements et abonnements spécifiques aux transformateurs dans le modèle d'objet de transformateur. Ensuite, utilisez le modèle d'objet de transformateur pour donner un nom unique à chaque transformateur afin de les définir dans le modèle ThingWorx.
Vous auriez également pu définir une forme d'objet de transformateur. Dans ce cas, votre modèle d'objet de transformateur implémenterait trois formes d'objet : Actif_ERP, Actif_CBM et la forme d'objet de transformateur. Bien que cette approche fonctionne très bien, elle n'est pas nécessaire si aucun autre modèle d'objet implémente la forme d'objet de transformateur.
Modèle d'objet de mélangeur
Le modèle d'objet de mélangeur serait défini par l'implémentation de la forme d'objet Actif_ERP. Puisque les mélangeurs ne sont pas soumis à une maintenance conditionnelle, la forme Actif_CBM n'est pas nécessaire. Il faudrait également définir l'intégralité des propriétés, services, événements et abonnements spécifiques aux mélangeurs dans le modèle d'objet de mélangeur. Ensuite, utilisez le modèle d'objet de mélangeur pour donner un nom unique à chaque mélangeur afin de les définir dans le modèle ThingWorx.
Modèle d'objet de centrale de traitement d'air
Le modèle d'objet de centrale de traitement d'air est semblable au modèle d'objet de transformateur. Il doit implémenter des formes d'objet Actif_ERP et Actif_CBM. Il faudrait également définir l'intégralité des propriétés, services, événements et abonnements spécifiques aux centrales de traitement d'air dans le modèle d'objet de centrale de traitement d'air. Ensuite, utilisez le modèle d'objet de centrale de traitement d'air pour donner un nom unique à chaque centrale de traitement d'air afin de les définir dans le modèle ThingWorx.
Maintenant que tous les actifs sont définis, vous disposez d'un modèle très facile à actualiser. S'il est nécessaire d'apporter des modifications à Actif_ERP, il est possible de les effectuer et de les tester au même endroit. Une fois ces modifications déployées, chaque équipement du site hériterait automatiquement des nouvelles fonctionnalités.
Est-ce que cela a été utile ?