Introduzione a ThingWorx > Programmazione per l'IoT > Modellazione: perché sono disponibili le thing shape e i modelli di oggetto?
Modellazione: perché sono disponibili le thing shape e i modelli di oggetto?
Poiché il modello ThingWorx è orientato agli oggetti, è possibile definire "componenti" riutilizzabili, quindi utilizzare tali componenti per definire gli oggetti nel modello. Le modifiche ai componenti riutilizzabili si riflettono automaticamente sugli oggetti definiti da tali componenti. L'obiettivo è definire i comportamenti in un'unica posizione e fare in modo che tutti gli oggetti ereditati si comportino in base alla definizione corrente degli oggetti padre. In tal modo, non è necessario apportare le stesse modifiche a molti oggetti in caso di aggiornamento.
Le thing shape e i modelli di oggetto sono stati implementati per semplificare la gestione del modello di eredità. Le thing shape sono i componenti della definizione di base. Quando un oggetto o un modello di oggetto deve condividere la definizione di una thing shape, l'oggetto o il modello di oggetto "implementa" la thing shape. In genere, le thing shape devono avere comportamenti univoci, ovvero eseguono un insieme univoco di servizi e funzionalità. Un modello di oggetto può implementare più di una thing shape. Si consiglia di definire un oggetto mediante un modello di oggetto.
Di seguito viene illustrato un esempio semplice. Un sito dispone di tipi diversi di apparecchiature. Ogni apparecchiatura esegue una funzione molto diversa per il sito. Per semplicità, si presupponga che siano disponibili tre tipi di apparecchiature:
Trasformatore
Miscelatore
Unità di trattamento dell'aria
Il sito potrebbe disporre di cinque trasformatori, venti unità di trattamento dell'aria e dodici miscelatori. Ciascuno di questi tre tipi di apparecchiature è molto diverso, ma potrebbero essere presenti anche degli aspetti comuni. Si presupponga che ogni apparecchiatura venga monitorata dal sistema ERP dell'azienda; pertanto, si dispone di dati comuni (proprietà dell'oggetto). Si presupponga inoltre che sia necessario aggiornare il sistema di gestione della manutenzione delle unità di trattamento dell'aria e dei trasformatori in base a criteri di misurazione specifici utilizzati per la manutenzione basata sulle condizioni (CBM, Condition Based Maintenance).
Quando si analizza questo modello fisico e si decide come convertirlo in un modello ThingWorx, è necessario considerare tre raggruppamenti distinti di comportamento:
1. Comportamento degli asset ERP
2. Comportamento della manutenzione basata sulle condizioni (CBM, Condition Based Maintenance)
3. Comportamento specifico del tipo di apparecchiatura
In questo esempio si desidera definire almeno due thing shape per sfruttare il funzionamento del modello ThingWorx. Di seguito sono riportate le due thing shape.
1. La thing shape ERP_Asset, poiché questo è un aspetto comune per ogni apparecchiatura nel sito. In tal modo, qualsiasi modifica alla thing shape ERP_Asset viene automaticamente riflessa in ogni apparecchiatura presente nel sito.
2. CBM_Asset, perché più tipi di asset necessitano di questa funzionalità; se la si definisce come una thing shape, tutte le modifiche vengono ereditate mediante l'implementazione degli oggetti. Se la manutenzione dei miscelatori passa in futuro a un modello CBM, si può far sì che i miscelatori implementino questa thing shape tramite il modello di oggetto Miscelatore (illustrato di seguito). In tal modo, non è necessario aggiornare tutti i miscelatori.
È possibile quindi creare tre modelli di oggetto, uno per ciascun tipo di apparecchiatura. I modelli di oggetto sono stati progettati per semplificare la creazione e la gestione degli oggetti di una definizione specifica. In questo esempio, l'utilizzo di modelli di oggetto dei tre tipi di apparecchiature consente di creare un oggetto che rappresenta un asset specifico semplicemente utilizzando il modello di oggetto e assegnando all'oggetto un nome univoco.
Modello di oggetto Trasformatore
Il modello di oggetto Trasformatore viene definito implementando le thing shape ERP_Asset e CMB_Asset. Nel modello di oggetto Trasformatore devono inoltre essere definiti tutti i servizi, gli eventi, le proprietà e le sottoscrizioni specifici dei trasformatori. Per definire ogni trasformatore nel modello ThingWorx, utilizzare quindi il modello di oggetto Trasformatore e un nome univoco.
In alternativa, si potrebbe anche definire una thing shape Trasformatore. In tal caso, il modello di oggetto Trasformatore implementerebbe tre thing shape: ERP_Asset, CMB_Asset e Trasformatore. Questo approccio è corretto, ma non è necessario se la thing shape Trasformatore non viene implementata da altri modelli di oggetto.
Modello di oggetto Miscelatore
Il modello di oggetto Miscelatore viene definito implementando la thing shape ERP_Asset. I miscelatori non utilizzano il modello di manutenzione CBM, pertanto la thing shape correlata non è necessaria. Nel modello di oggetto Miscelatore devono inoltre essere definiti tutti i servizi, gli eventi, le proprietà e le sottoscrizioni specifici dei miscelatori. Per definire ogni miscelatore nel modello ThingWorx, utilizzare quindi il modello di oggetto Miscelatore e un nome univoco.
Modello di oggetto Unità di trattamento dell'aria
Il modello di oggetto Unità di trattamento dell'aria è simile al modello di oggetto Trasformatore. Tale modello deve implementare entrambe le thing shape ERP_Asset e CMB_Asset. Tutti i servizi, gli eventi, le proprietà e le sottoscrizioni specifici delle unità di trattamento dell'aria devono essere definiti anche nel modello di oggetto Unità di trattamento dell'aria. Quindi, per ogni unità di trattamento dell'aria utilizzare il modello di oggetto Unità di trattamento dell'aria e un nome univoco per definire l'unità di trattamento dell'aria nel modello ThingWorx.
Ora che tutti gli asset sono stati definiti, si dispone di un modello a elevata manutenibilità. Se è necessario apportare modifiche a ERP_Asset, è possibile effettuarle in un'unica posizione ed eseguirne il test. Una volta distribuita, ogni apparecchiatura nel sito eredita automaticamente la nuova funzionalità.