Dingeigenschaften
Dingeigenschaften werden verwendet, um die Datenpunkte zu beschreiben, die zu einem Ding gehören. Beispielsweise kann ein Kunde eine Eigenschaft "Name" und eine Eigenschaft "Adresse" haben. Ein Lkw kann die folgenden Eigenschaften haben: "Fahrer", "Kapazität" und "Ort".
Eigenschaften sind eine einfache und effektive Methode, die aktuellen Bedingungen eines Dings zu überwachen. Bei den Eigenschaften kann es sich um folgende handeln:
• Statisch – Werte, die sich nicht ändern, z.B. Hersteller und Modellnummer
• Dynamisch – Werte, die sich im Laufe der Zeit ändern, z.B. Temperatur.
Sie richten Eigenschaften basierend auf der Asset-Struktur, der Geschäftsprozesse und der Lösungen ein, die Sie bereitstellen möchten.
Typen von Eigenschafts-Bindungen
Wenn Sie eine Eigenschaft erstellen, können Sie folgende Bindungstypen auswählen:
• Keine
Eine Eigenschaft für ein lokales Ding. Dies ist die Standardeinstellung.
• Lokal gebunden
Verknüpft die Eigenschaft mit einer Eigenschaft, die für ein anderes Ding auf dem ThingWorx Server definiert ist. Sie können diese Eigenschaft als schreibgeschützt definieren, und sie kann trotzdem einen Wert von einer anderen Eigenschaft auf dem Server erhalten. Diese Art von Bindung wird für gewöhnlich nicht für Remote-Geräte verwendet, es sei denn, Sie erstellen eine lokale Bindung zu einer remote gebundenen Eigenschaft.
• Remote gebunden
Wenn ein Remotegerät zuerst eine Verbindung zu einem ThingWorx Server herstellt, bindet der Server das Remotegerät an das entsprechende Ding. Sobald das Remote-Gerät gebunden ist, müssen Sie eine Remote-Bindung zwischen jeder Eigenschaft, die für dieses Remote-Gerät definiert ist, und dem Remote-Ding erstellen, das das Gerät in ThingWorx repräsentiert. ThingWorx verwendet diese Bindung, um Aktualisierungen für jeden Eigenschaftswert von einem Remotegerät über eine aktive WebSocket-Verbindung zu senden und zu empfangen.
 |
Wenn ein lokales Ding und ein Remote-Ding über eine Eigenschaft mit dem gleichen Namen verfügen und eine weitere Eigenschaft an die Einstellung der Remote-Eigenschaft gebunden ist, legt die Remote-Eigenschaft auch den Wert der lokalen Eigenschaft fest.
|
|
|
Nachdem der Wert der Remote-Eigenschaft für das Remote-Ding in Composer geändert wurde, wird er nicht in ThingWorx gespeichert, und das DataChange-Ereignis wird nicht ausgelöst. Nur die Eigenschaftsaktualisierung wird an das Edge gesendet.
|
 |
Informationen zum Einrichten von Eigenschafts-Bindungen, ob lokal oder remote, finden Sie unter Eigenschafts-Bindungen verwalten.
|
Eigenschaftsdetails
Jede Eigenschaft hat einen Namen, eine Beschreibung und einen ThingWorx Datentyp, der als Basistyp in ThingWorx bezeichnet wird. Je nach Basistyp sind möglicherweise zusätzliche Felder aktiviert. Ein einfacher skalarer Typ, wie eine Zahl oder eine Zeichenfolge, fügt Basisfelder wie den Standardwert hinzu. Komplexere Basistypen haben mehr Optionen. Beispielsweise schließt der Basistyp INFOTABLE die Möglichkeit ein, einen Data Shape zu definieren, um die Datenstruktur der Infotable zu beschreiben. Weitere Informationen finden Sie unter Basistypen von Eigenschaften.
Ein Ding-Eigenschaftswert besteht aus drei Merkmalen: Wert, Zeitstempel und Qualität (VTQ). VTQ-Werte können angegeben oder automatisch festgelegt werden. Zulässige Qualitätsstatus befinden sich in der QualityStatus-Klasse. Wenn eine Eigenschaft festgelegt oder aktualisiert wird, werden alle ihre VTQ-Eigenschaften aktualisiert.
Eigenschaftswerte aktualisieren
Im Allgemeinen kann eine Eigenschaft in Composer aktualisiert werden, indem Sie me.PropertyName = Wert festlegen. Der Zeitstempel gibt den aktuellen Zeitstempel des Servers wieder. Für historische Aktualisierungen können Sie die Dienste UpdatePropertyValues und UpdatePropertyValuesBatched verwenden, mit denen Sie Wertaktualisierungen mehrerer Eigenschaften durchführen können. Eigenschaftswerte können nicht auf NULL festgelegt werden. Weitere Informationen zu diesen Diensten finden Sie in der nachfolgenden Tabelle.
|
Option
|
Beschreibung
|
||
|---|---|---|---|
|
UpdatePropertyValues
|
• Akzeptiert einen einzelnen Infotable-Parameter "values", der aus mehreren Zeilen besteht.
• Jede Zeile enthält den Eigenschaftsnamen, den Wert und die Qualität sowie den Aktualisierungszeitstempel.
• Eigenschaftswerte können nicht auf NULL festgelegt werden.
Standardmäßig werden die Wertaktualisierungen für jede Eigenschaft separat ausgeführt. Legen Sie die Einstellung GroupPropertyValuesByTime im Abschnitt BasicSettings der Datei platform-settings.json auf true fest, um die Werte nicht nach Eigenschaft, sondern nach Zeitstempel zu sortieren und zu gruppieren.
Wenn die obige Einstellung auf true festgelegt ist, werden die durch Daten ausgelösten Ereignisse und Warnungen für alle Eigenschaften, die mit demselben Zeitstempel aktualisiert wurden, zusammen ausgelöst. Anschließend werden Multi-Ereignis-Abonnements, die für einige oder alle diese Ereignisse registriert wurden, nur einmal pro Zeitstempel ausgeführt, wobei die übereinstimmenden Ereignisse im Parameter "events" übergeben werden.
|
||
|
UpdatePropertyValuesBatched
|
• Akzeptiert einen einzelnen Infotable-Parameter batches, der aus mehreren Zeilen besteht.
• Jede Zeile enthält einen Batch von Eigenschaftswerten und den Aktualisierungszeitstempel.
• Der Feldwert von batch ist eine Infotable, die aus mehreren Zeilen besteht. Jede Zeile enthält den Eigenschaftsnamen, den Wert und die Qualität.
• Eigenschaftswerte können nicht auf NULL festgelegt werden.
Die Werte der Eigenschaften werden nach Zeitstempeln der Batches sortiert und gruppiert, d.h. die durch Daten ausgelösten Ereignisse und Warnungen für alle Eigenschaften, die mit demselben Zeitstempel aktualisiert wurden, werden zusammen ausgelöst. Anschließend werden Multi-Ereignis-Abonnements, die für einige oder alle diese Ereignisse registriert wurden, nur einmal pro Zeitstempel ausgeführt, wobei alle übereinstimmenden Ereignisse im Parameter events übergeben werden.
|
|
|
Vermeiden Sie beim Schreiben von benutzerdefinierten Diensten das Generieren von Code, der gleichzeitig dieselbe Eigenschaft einer gegebenen Entität ändern kann. Sie können beispielsweise einen Eigenschaftswert nicht gleichzeitig vergrößern oder verkleinern, da dies zu unvorhersehbaren Eigenschaftswerten führen kann. Ebenso ist das Vergrößern von Eigenschaften, damit sie wie Leistungsindikatoren in Abonnements agieren, eine häufige Fehlanwendung, die zu Ungenauigkeit führt.
|
Das HistoricalDataLogged-Ereignis wird ausgelöst, wenn ein historischer Eigenschaftswert festgelegt wird. Beispiel: Wenn der aktuelle Zeitstempel einer VTQ-Eigenschaft 2020-02-04 20:16:20 ist und ein historischer Wert mit dem Zeitstempel 2019-12-24 19:00:45 importiert wird, wird das Ereignis ausgelöst. Alle Abonnements für dieses Ereignis werden entsprechend ausgeführt.
Warnungen
Informationen zu Warnungen finden Sie unter Warnungen.
Aspekte von Eigenschaften
Eigenschaften können die folgenden Aspekteinstellungen haben:
• Basistyp – Stellt Kontext zu den Daten bereit, die in der Eigenschaft gespeichert sind. Weitere Informationen finden Sie unter Basistypen von Eigenschaften.
• Hat Standardwert – legt einen Standardwert für die Eigenschaft fest, wenn das Ding initialisiert wird.
• Index – Bei Auswahl dieser Option wird die Eigenschaft gespeichert und im Eigenschafts-Persistenzanbieter der Datenbank indiziert, um die Suche mithilfe des Diensts QueryImplementingThingsOptimized zu verbessern. Weitere Informationen finden Sie unter Indizierte Eigenschaften.
◦ Nur Eigenschaften, die sich selten ändern, sollten indiziert werden. Telemetrie-Dateneigenschaften sollten nicht indiziert werden.
◦ Wenn Index ausgewählt ist, wird die Einstellung Persistent machen automatisch ausgewählt, und die Bearbeitung der Einstellung Persistent machen ist deaktiviert.
◦ Wenn die Einstellung Index nachträglich deaktiviert ist, bleibt Persistent machen ausgewählt, aber die Bearbeitung wird erneut aktiviert, damit Sie die Einstellung festlegen oder die Auswahl aufheben können.
◦ Nur die folgenden Basistypen unterstützen die Einstellung Index: STRING, NUMBER, INTEGER, LONG, BOOLEAN, DATETIME, THINGNAME, USERNAME, GROUPNAME, HYPERLINK, IMAGELINK, MASHUPNAME, MENUNAME, DASHBOARDNAME, TEXT, GUID, NOTIFICATIONCONTENTNAME, NOTIFICATIONDEFINITIONNAME, STYLETHEMENAME und THINGGROUPNAME.
• Persistent machen – Wenn diese Option ausgewählt bzw. auf true festgelegt ist, wird jede Wertänderung in der Datenbank persistent gemacht. Das Schreiben von persistenten Eigenschaften in die Datenbank findet asynchron statt, um Deadlocks zu vermeiden. Während der Eigenschaftswert sofort festgelegt wird, findet das Schreiben in die Datenbank asynchron zu einem späteren Zeitpunkt statt. Die folgenden Validierungen finden statt, bevor ein persistenter Eigenschaftswert in die Datenbank geschrieben wird:
◦ Das Ding muss noch vorhanden sein.
◦ Das Ding muss eine ID haben.
◦ Die Ding-ID und die ID des ausstehenden Schreibvorgangs müssen übereinstimmen.
◦ Das Ding muss die Eigenschaft weiterhin mit dem gleichen Namen wie der ausstehende Schreibvorgang definieren.
◦ Die definierte Eigenschaft muss noch persistent sein.
Aktualisierungen und Neustarts haben keinen Einfluss auf die Warteschlangenverarbeitung.
• Schreibgeschützt – Wenn diese Option ausgewählt bzw. auf true festgelegt ist, sind die Daten statisch und können nicht zur Laufzeit geschrieben werden. Die einzige Methode, ihren Wert zu ändern, besteht in der Änderung des Standardwerts. Dies ist für statische Konfigurationsdaten nützlich.
• Protokoll – Wenn diese Option ausgewählt bzw. auf true festgelegt ist, wird der Eigenschaftswert basierend auf dem Datenänderungstyp automatisch in einem Wert-Stream protokolliert, wenn sich die Daten ändern.
|
|
Wenn ein Datenänderungsereignis nicht ausgelöst wird, wird der Wert-Stream-Eintrag evtl. nicht protokolliert, aber der festgelegte Eigenschaftswert wird beibehalten. Es ist möglich, dass Eigenschaften für eine Entität festgelegt werden, aber der entsprechende Wert-Stream-Schreibvorgang gelöscht wird, weil die Warteschlange mit diesen Schreibvorgängen voll ist und nicht in die Datenbank geleert werden kann. Dies kann auftreten, wenn das Volumen der eingehenden Schreibvorgänge größer ist als die konfigurierte Geschwindigkeit, in der die Warteschlange geleert wird. Dies kann in platform-settings.json pro Persistenzanbieter optimiert werden. Ein Verlust der Verbindung zwischen ThingWorx und Datenbank kann auch dazu führen, dass die Warteschlange gesichert und nicht schnell geleert wird.
|
• Umfang – Wählen Sie den Umfang der Eigenschaft aus.
Informationen zu Datenänderungen
Datenänderungstyp
Die Datenänderungstyp-Einstellung gibt an, wann ein Datenänderungsereignis von einer Eigenschaftswertänderung ausgelöst wird. Dies ist nützlich, wenn andere Prozesse basierend auf dem Eigenschaftswert initiiert werden müssen. Jedem Abonnenten wird eine Änderungsnachricht mit einer Infotable zugesendet, die den alten und den neuen Eigenschaftswert enthält. Sie können z.B. ein Abonnement für Änderungen an der Eigenschaft DeliverySchedule einrichten. Wenn sich der Zeitplan ändert, können Sie den Fahrer per SMS benachrichtigen.
Folgende Optionen sind für Datenänderungstyp verfügbar:
• Immer – Löst unabhängig vom Wert jedes Mal ein Datenänderungsereignis aus, wenn sich der Eigenschaftswert ändert.
Nie – Deaktiviert Datenänderungsereignisse für die Eigenschaft. Es werden keine Ereignisse ausgelöst.
Ein – Löst ein Datenänderungsereignis aus, wenn sich der Eigenschaftswert ändert. Bei den meisten Basistypen löst jede Änderung ein Ereignis aus. Für komplexere Basistypen wie Infotables können andere Ereignisregeln gelten.
• Aus – Löst nur dann ein Datenänderungsereignis aus, wenn der neue Wert als Boolean false ausgewertet wird.
Wert – Für numerische Basistypen wird nur dann ein Datenänderungsereignis ausgelöst, wenn sich der neue Wert um mehr als einen definierten Schwellenwert vom vorherigen Wert unterscheidet. Für nicht numerische Typen wird das Änderungsereignis immer dann ausgelöst, wenn sich der Wert ändert. Die Protokollierung des Werts in einem Wert-Stream erfolgt nur, wenn sich der Wert geändert hat.
Veraltet
Wenn Sie das Kontrollkästchen Veraltet aktivieren, wird die Entität als veraltet markiert. Geben Sie die Version, ab der die Entity als veraltet gelten soll, im Format major.minor.patch ein. Optional können Sie einen Kommentar hinzufügen.
Informationen zu Remote-Bindungen
In der folgenden Tabelle werden die Optionen aufgeführt, die verfügbar sind, wenn die Option Bindung auf Remote gebunden festgelegt ist.
|
Option
|
Beschreibung
|
||
|---|---|---|---|
|
Remote-Eigenschaftsname
|
Gibt den Namen der Eigenschaft am Edge an.
|
||
|
Cache-Methode
|
Definiert, wie der Server den Wert der gebundenen Edge-Eigenschaft abruft. Die folgenden Optionen sind verfügbar:
• Aus Server-Cache lesen verhindert Serveranforderungen an den Edge-Eigenschaftswert. Es wird nur der Wert vom Server abgerufen. Alle Aktualisierungen am auf dem Server zwischengespeicherten Edge-Eigenschaftswert sind abhängig vom Datenänderungstyp und von der Scanrate (d.h. Wert-Push-Definition der Edge-Eigenschaft) der Edge-Eigenschaft. Ohne die richtigen Einstellungen der Edge-Eigenschaft ist es möglich, dass der Server nie den Edge-Eigenschaftswert erhält und nur den Standardwert der Servereigenschaft zurückgibt. Wenn der Datenänderungstyp der Edge-Eigenschaft, an die Sie eine Bindung durchführen, ALWAYS oder VALUE ist, entspricht der Cache-Typ standardmäßig dieser Einstellung.
• Bei jedem Lesevorgang von Remote abgerufen ruft den Edge-Eigenschaftswert vom Edge für jede Anforderung ab. Bei dieser Option findet keine Zwischenspeicherung statt. Wenn der Datenänderungstyp der Edge-Eigenschaft, an die Sie eine Bindung durchführen, NEVER ist, entspricht der Cache-Typ standardmäßig dieser Einstellung.
• Für bestimmte Zeit zwischengespeichert steuert die Häufigkeit von Anforderungen an die Edge-Eigenschaft. Nach der ersten Anforderung greift der Server auf die Edge-Eigenschaft zu, um den Wert abzurufen, und stellt für die definierte Anzahl von Sekunden keine weitere Anforderung an die Edge-Eigenschaft. Beachten Sie, dass die Edge-Eigenschaft während dieser Zeit den Serverwert (über Push) aktualisieren kann.
|
||
|
Cache-Intervall
|
Legt die Zeitspanne (in Sekunden) fest, für die der Server den Edge-Eigenschaftswert zwischenspeichert, bevor eine Anforderung des Eigenschaftswerts diesen vom Edge abruft. Der Wert wird immer bei der ersten Anforderung vom Edge abgerufen.
|
||
|
Starttyp
|
Bestimmt den Wert, der zum Initialisieren einer remote gebundenen Eigenschaft verwendet wird, wenn das zugehörige Ding gestartet oder neu gestartet wird. Dieser initialisierte Wert löst kein Eigenschaftsänderungsereignis aus.
• Standardwert verwenden – Legt den Anfangswert der Eigenschaft auf den angegebenen Standardwert fest, trotz des Edge-seitigen Wertes. Wenn die Eigenschaft persistent gemacht wird, wird der anfängliche Wert auf den letzten Wert festgelegt, der in der Datenbank persistent gemacht wurde.
• Edge-Wert lesen – Fragt den aktuellen Wert vom Edge ab, sodass der Wert auf dem Server immer synchron mit dem Edge-Wert ist, selbst wenn das Ding auf dem Server neu gestartet wird.
|
||
|
Push-Typ
|
Gilt nur für Edge-erweiterte Ding-Eigenschaften. Diese Komponenten können ihre Wertänderungen mit einem Push an den Server übertragen. Sie können diese Funktion mit der Servereigenschaftsbindung konfigurieren.
• Push basierend auf Wertänderung – Sie können einen Schwellenwert für eine Wertänderung konfigurieren. Wenn Sie diese Einstellung verwenden, können Sie auch den Push-Schwellenwert festlegen, bei dem es sich um eine Totzone handelt, die überschritten werden muss, bevor ein neuer Wert vom Edge an den Server übergeben wird.
• Keine Push-Übertragung
• Immer Push-Übertragung
|
||
|
Push-Schwellenwert
|
Verfügbar, wenn Push-Typ auf Push basierend auf Wertänderung festgelegt ist. Sie gibt den Bereich (plus oder minus) um den Edge-Eigenschaftswert an, damit der Eigenschaftswert-Push erfolgt. Der Eigenschaftswert muss sich um mehr als den angegebenen Wert ändern.
|
||
|
Wenn getrennt
|
Gibt an, wie die Bindung des Remote-Eigenschaftswerts verarbeitet werden soll, wenn die Verbindung zum Remote-Ding vorübergehend verloren geht.
• Werte ignorieren, die sich ändern, wenn getrennt.
• Alle Änderungen in einem einzelnen zuletzt geänderten Wert kombinieren – Sendet den letzten geänderten Wert, wenn die Verbindung wiederhergestellt wird.
|
||
|
Timeout
|
Legt das Timeout für Aufrufe von Remote-Dingen fest, während eine Eigenschaft gelesen oder geschrieben wird.
• Systemstandard verwenden – Die Standardeinstellung sind 30 Sekunden.
• Benutzerdefiniertes Timeout. Fügen Sie dies zu Timeout-Intervall (s) hinzu.
|
Verwandte Links