Modellierung: Warum gibt es Dingformen und Dingvorlagen?
Da das ThingWorx Modell objektorientiert ist, können Sie wiederverwendbare "Komponenten" definieren und dann diese Komponenten verwenden, um die Dinge im Modell zu definieren. Änderungen an den wiederverwendbaren Komponenten werden automatisch in die Dinge übernommen, die durch diese Komponenten definiert werden. Die Idee dahinter ist, Verhaltensweisen nur an einem Ort zu definieren und festzulegen, dass sich alle geerbten Objekte gemäß der aktuellen Definition der Elternobjekte verhalten. Auf diese Weise müssen Sie nicht die gleichen Änderungen an vielen Dingen vornehmen, wenn eine Aktualisierung erforderlich ist.
Dingformen und Dingvorlagen wurden implementiert, um die Verwaltung des Vererbungsmodells zu vereinfachen. Dingformen sind die grundlegenden Definitionskomponenten. Wenn ein Ding oder eine Dingvorlage die Definition einer Dingform teilen soll, "implementiert" das Ding oder die Dingvorlage die Dingform. Im Allgemeinen sollten Dingformen eindeutige Verhaltensweisen haben, also einen eindeutigen Satz Dienste und Funktionen ausführen. Eine Dingvorlage kann mehr als eine Dingform implementieren. Es wird empfohlen, ein Ding unter Verwendung einer Dingvorlage zu definieren.
Betrachten wir ein einfaches Beispiel. An einem Standort gibt es verschiedene Typen von Apparaturen. Die Funktion der einzelnen Apparaturen am Standort ist sehr verschieden. Der Einfachheit halber gehen wir von drei Apparaturtypen aus:
• Transformator
• Mischer
• Klimagerät
Der Standort verfügt z.B. über fünf Transformatoren, zwanzig Klimageräte und zwölf Mischer. Jeder dieser drei Apparaturtypen ist sehr verschieden. Es kann jedoch auch einige Gemeinsamkeiten geben. Wir gehen davon aus, dass jede Apparatur vom ERP-System des Unternehmens verfolgt wird und daher gemeinsame Daten (Dingeigenschaften) hat. Außerdem nehmen wir an, dass die Klimageräte und Transformatoren das Wartungsverwaltungssystem im Hinblick auf bestimmte Metriken aktualisieren müssen, die für die zustandsorientierte Instandhaltung (Condition Based Maintenance, CBM) verwendet werden.
Wenn Sie dieses physische Modell analysieren und entscheiden, wie es in ein ThingWorx Modell übersetzt werden soll, müssen drei eigenständige Verhaltensgruppen berücksichtigt werden:
1. Verhalten von ERP-Assets
2. Verhalten der zustandsorientierten Instandhaltung
3. Für den Apparaturtyp spezifisches Verhalten
In diesem Beispiel sollten Sie mindestens zwei Dingformen definieren, um von der Funktionsweise des ThingWorx Modells zu profitieren. Es handelt sich um folgende:
1. Dingform "ERP_Asset" – Da alle Apparaturen am Standort dieses gemeinsam haben. Auf diese Weise wird jede Änderung an der Dingform "ERP_Asset" automatisch in jede Apparatur am Standort übernommen.
2. Dingform "CBM_Asset" – Da mehrere Asset-Typen diese Funktion benötigen, definieren Sie sie als Dingform; alle Änderungen werden durch Implementieren von Dingen geerbt. Wenn die Wartung der Mischer in Zukunft in ein CBM-Modell übertragen wird, können Sie festlegen, dass die Mischer diese Dingform durch die Mischer-Dingvorlage (siehe unten) implementieren und müssen nicht alle Ihre Mischer aktualisieren.
Jetzt können Sie drei Dingvorlagen erstellen, eine für jeden Apparaturtyp. Dingvorlagen wurden entwickelt, um die Erstellung und Verwaltung von Dingen einer bestimmten Definition zu vereinfachen. Mithilfe der drei Dingvorlagen für Apparaturtypen in diesem Beispiel können Sie ein Ding erstellen, das ein bestimmtes Asset darstellt, indem Sie einfach die Dingvorlage verwenden und dem Ding einen eindeutigen Namen zuweisen.
Transformator-Dingvorlage
Die Transformator-Dingvorlage wird definiert, indem Sie die Dingformen "ERP_Asset" und "CMB_Asset" implementieren. Alle spezifischen Eigenschaften, Dienste, Ereignisse und Abonnements der Transformatoren sollten ebenfalls in der Transformator-Dingvorlage definiert werden. Verwenden Sie dann für jeden Transformator die Transformator-Dingvorlage und einen eindeutigen Namen, um den Transformator im ThingWorx Modell zu definieren.
Alternativ können Sie auch eine Transformator-Dingform definieren. In diesem Fall würde die Transformator-Dingvorlage drei Dingformen implementieren: die Dingformen "ERP_Asset", "CMB_Asset" und "Transformator". Dieser Ansatz funktioniert gut, ist jedoch nicht erforderlich, wenn andere Dingvorlagen die Transformator-Dingform nicht implementieren.
Mischer-Dingvorlage
Die Mischer-Dingvorlage wird definiert, indem Sie die ERP_Asset-Dingform implementieren. Die Mischer verwenden nicht das CBM-Wartungsmodell, daher wird die zugehörige Dingform nicht benötigt. Alle spezifischen Eigenschaften, Dienste, Ereignisse und Abonnements der Mischer sollten ebenfalls in der Mischer-Dingvorlage definiert werden. Verwenden Sie dann für jeden Mischer die Mischer-Dingvorlage und einen eindeutigen Namen, um den Mischer im ThingWorx Modell zu definieren.
Klimagerät-Dingvorlage
Die Klimagerät-Dingvorlage ist der Transformator-Dingvorlage ähnlich. Sie sollte die Dingformen "ERP_Asset" und "CMB_Asset" implementieren. Alle spezifischen Eigenschaften, Dienste, Ereignisse und Abonnements der Klimageräte sollten ebenfalls in der Klimagerät-Dingvorlage definiert werden. Verwenden Sie dann für jedes Klimagerät die Klimagerät-Dingvorlage und einen eindeutigen Namen, um die Klimageräte im ThingWorx Modell zu definieren.
Nachdem alle Assets definiert wurden, haben Sie ein sehr gut verwaltbares Modell. Wenn Änderungen am ERP_Asset erforderlich sind, können diese an einem zentralen Ort durchgeführt und getestet werden. Nach der Bereitstellung erbt jedes Gerät am Standort automatisch die neuen Funktionen.