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 praktische Methode, sich über die aktuellen Bedingungen eines Dings zu informieren. Eigenschaften können statisch sein (z.B. "Hersteller" und "Modellnummer") oder dynamisch (z.B. "Temperatur"). Sie richten Eigenschaften basierend auf der Asset-Struktur, der Geschäftsprozesse und der Lösungen ein, die Sie bereitstellen möchten.
Wenn Sie eine Eigenschaft erstellen, können Sie folgende Arten von Bindungen 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. Dies wird 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.
|
 |
Informationen zum Einrichten von Eigenschaftsbindungen, ob lokal oder remote, finden Sie unter Eigenschaftsbindungen verwalten.
|
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 zugehörigen VTQ-Eigenschaften aktualisiert.
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. Angenommen, der aktuelle festgelegte Zeitstempel einer VTQ-Eigenschaft für eine Entität ist 2020-02-04 20:16:20. Beim Importieren einer neuen Version dieser Entität wird eine ältere VTQ-Eigenschaft festgelegt, z.B. 2019-12-24 19:00:45. Dies führt dazu, dass das HistoricalDataLogged-Ereignis für diese Eigenschaft ausgelöst wird. Alle Abonnements für dieses Ereignis in der Eigenschaft werden ausgeführt.
Warnungen
Informationen zu Warnungen finden Sie unter Warnungen.
Aspekte von Eigenschaften
Eigenschaften können die folgenden Aspekteinstellungen haben:
• 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 die Einstellung aktiviert bzw. auf "wahr" 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 die Einstellung ausgewählt bzw. auf "wahr" festgelegt ist, sind die Daten statisch und können nicht zur Laufzeit geschrieben werden. Die einzige Methode, den Wert zu ändern, besteht in der Änderung des Standardwerts. Dies ist für statische Konfigurationsdaten nützlich.
• Protokoll – Wenn die Einstellung ausgewählt bzw. auf "wahr" festgelegt ist, wird der Eigenschaftswert automatisch in einem Wert-Stream protokolliert, wenn sich die Daten ändern (auf Basis des Datenänderungstyps).
|
|
Wenn das Datenänderungsereignis unter bestimmten Umständen 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. Der 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
Diese Einstellung gibt an, wann ein Datenänderungsereignis von einer Eigenschaftswertänderung ausgelöst wird. Sie verwenden sie, wenn andere Prozesse basierend auf dem Wert der Eigenschaft 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 – Das Ereignis wird für jede Eigenschaftswertänderung für Abonnenten ausgelöst.
• Nie – Es wird kein Änderungsereignis ausgelöst.
• Ein – Für die meisten Werte löst jede Änderung ein Ereignis aus. Für komplexere Basistypen wie Infotables können andere Ereignisregeln gelten.
• Aus – Das Ereignis wird ausgelöst, wenn der neue Wert in den booleschen Wert "false" ausgewertet wird.
• Wert – Für numerische Typen wird das Änderungsereignis ausgelöst, wenn sich der neue Wert um mehr als den Schwellenwert geändert hat. Für nicht numerische Typen wird das Änderungsereignis ausgelöst, wenn sich der Wert in irgendeiner Weise vom ursprünglichen 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
|
Der Name der Eigenschaft am Edge.
|
||
|
Cache-Methode
|
Die Cache-Methode bietet die folgenden Möglichkeiten zum Lesen der gebundenen Edge-Eigenschaftswerte.
• 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
|
Die Zeitspanne (in Sekunden), 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
|
Gibt den Wert an, 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
|
Push-Typ gilt nur für Edge-optimierte Dingeigenschaften. 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
|
Diese Option ist 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
|
Das Timeout für Aufrufe von Remote-Dingen, 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