Hub: Überblick

• Erste Schritte

Training

Die Hub-Immersivität stellt die Softwareschicht dar, die zwischen der Datenexposition und deren Nutzung durch den Betrachter verbunden ist.

Sie stellt eine universelle Schicht der Indirektion zwischen einem Konsumenten (zum Beispiel einem Immersive Beholder-Player) und Daten dar, unabhängig davon, welche Protokolle zum Zugriff verwendet werden.

Allgemeine Darstellung

Die Aufgabe des Hubs besteht darin, Anfragen von Konsumenten zu IOT-Daten zu erhalten, die zur Überwachung oder Wartung bestimmt sind, und Informationen bereitzustellen, die an die Bedürfnisse der Nutzer angepasst sind.

Der Hub bietet zwei Verbindungsfronten: Die erste, die für IoT-Datenverbrauchende Kunden/Anwendungen reserviert ist, ermöglicht es Ihnen, den Hub zu kontaktieren und Anfragen über eine REST-Front zu senden. Die zweite, technische Fassade, ermöglicht es dem Hub, Daten über ein dediziertes Protokoll abzurufen.

Intern basiert der Hub auf drei Konzepten:

• Der Griff
• Die Sitzung
• Der Stecker

Griffe

Handles stellen eine Route zu einem Datenstück dar. Sie besteht aus:

• Eine eindeutige Kennung für den Anfragenden, der mit diesen Daten verknüpft ist
• Ein Pfad, der die "Verbindungszeichenkette" zu den Daten darstellt

Der Pfad sollte es dem Hub ermöglichen, das Protokoll und die Möglichkeiten zum Zugriff auf die Daten zu bestimmen. Es ähnelt einer Verbindungskette, die es dem Hub ermöglicht, die richtige Technologie/das richtige Verbindungsprotokoll zu starten und zu wissen, wie man die Daten "verbinden" kann, um sie abzurufen.

Nehmen wir das Beispiel eines " Temperatursensor ». Dies könnte mit drei Eigenschaften verbunden sein:

• Der aktuelle Wert der Temperatur.
• Die maximal tolerierte Temperatur.
• Die Temperatur wird toleriert.

Diese drei Eigenschaften konnten über zwei verschiedene Protokolle/Technologien gespeichert und abgerufen werden:

• UCI UA —für den aktuellen Wert.
• Excel : Für die maximal und minimal tolerierten Schwellenwerte.

Die drei Pfade, die somit notwendig sind, um die Daten dieses Temperatursensors zu erhalten, wären jeweils:

•	ns=3;s=BAT6062.ETAG2.TEMP.T652145
•	XLSX://SITE/GESTBAT/QUALITVIE.xslx?Sheet=Temps&col=C&cell=22
•	XLSX://SITE/GESTBAT/QUALITVIE.xslx?Sheet=Temps&col=D&cell=22

Der erste Pfad ist ein klassischer OPC-UA-Pfad: ns=3;s=BAT6062.ETAG2.TEMP.T652145, die folgenden beiden wurden so formatiert, dass sie vom Excel-Connector des Hubs verstanden werden können: Sie zeigen an, die Excel-Datei im relativen Pfad zu öffnen SITE/GESTBAT/QUALITVIE.xslx und die Kolumnen zu lesen C und D der Strecke 22.

Es liegt am Hub, diese Pfade zu interpretieren, auf diese Daten zuzugreifen und stets einen aktuellen Wert dieser Daten an die interessierten Softwareanbieter zurückzusenden.

Wenn sich die Temperatur ändert, verlässt sich der Hub auf das OPC UA-Protokoll, um den aktuellen Wert abzurufen; wenn sich die maximalen und minimal akzeptablen Temperaturschwellenwerte ändern, muss der Hub sicherstellen, dass er die Zelle der entsprechenden Excel-Datei(en) lesen kann, um den Wert abzurufen.

Sitzungen

Eine Sitzung stellt einen Zugriff eines Verbrauchers (Überwachungssoftware, Synoptik oder Prozess) dar, der sowohl auf Daten zugreifen möchte, als auch über die Entwicklung dieser Daten im Laufe der Zeit informiert bleiben möchte.

Wenn ein Gebäude beaufsichtigt wird, wird eine festgelegte Anzahl von Geräten freigelegt, die selbst mit Daten verknüpft sind (Zielerfassung durch die Griffe). Siehe das Beispiel eines Temperatursensors im vorherigen Punkt.

Die Sitzung kann als Liste von Handles betrachtet werden.

Der Hub erhält diese Liste der Handles. Er wird den Hub auffordern, die verknüpften Werte abzurufen und über ihre zukünftige Entwicklung auf dem Laufenden zu bleiben.

Wenn der Hub also die Entwicklung des von einem Handle anvisierten Werts erkennt, stellt er sicher, dass die Sitzung oder Sitzungen, die die Daten verarbeiten sollen, diese erhalten, wenn sie eine Aktualisierungsanfrage stellen.

Steckverbinder

Ein Connector stellt einen Kanal für den Zugriff auf Daten über ein bestimmtes Protokoll dar (OPC UA, Excel, REST, SQL, Modbus usw.).

Ein Stecker kann als Stecker betrachtet werden, das am Hub hinzugefügt wird, um die Möglichkeiten zu erweitern. Der Hub verfügt über Steckverbinder für eine große Anzahl bekannter Protokolle oder Technologien (OPC UA, Excel, MQTT, ...).

GraphicStream hat eine API-Programmierschnittstelle in .Net entwickelt, mit der Sie einen Connector erstellen können, der Ihren Anforderungen für ein bestimmtes Protokoll zugeordnet ist und es einer Sitzung ermöglicht, Handles Monitoring Requests zu senden, die auf Daten in diesem Protokoll zugegriffen sind.

Der Connector hat innerhalb des Hubs zwei Aufgaben:

• Zugang zu den Daten
• Stellen Sie sicher, dass der Hub über Änderungen in diesen Daten im Laufe der Zeit informiert wird

Zum Beispiel, wenn eine Sitzung eine Anfrage nach Handles stellt. Der Hub stellt für beide Kontakte eine Anfrage zur Unterstützung. Wenn ein Connector das Protokoll verwaltet, das durch den Pfad eines Handles offengelegt wird, reagiert er positiv auf die Anfrage des Hubs und ist dafür verantwortlich, die Daten abzurufen und die Entwicklung dieser Daten auf dem neuesten Stand zu halten.

Betrieb

Der Hub ist daher die Hauptsoftware, der Leiter verwaltet die Verarbeitung von Griffen, Sitzungen und Verbindern.

Sie kann mit einer Ereignisdatenbank verglichen werden, die; für jedes verarbeitete Datenstück; weiß, wie sie die Akteure, die ihr Interesse an diesen Daten bekundet haben, vor einer Entwicklung warnen kann.

Eine Sitzung verbinden

Das Diagramm am Ende dieses Punktes zeigt die Verbindung einer Sitzung mit dem Hub und die Implementierung eines internen Prozesses zur Unterstützung der von der Sitzung ausgesendeten Handles.

Der erste Schritt bei jedem Zugriff auf den Hub ist das Erstellen einer Sitzung. Der Client stellt daher eine Anmeldeanfrage an den Hub.

Wenn diese Anfrage angenommen wird, liefert der Hub eine Session-Identifikatorin (eine GUID), die vom Client zur Identifikation in zukünftigen Austauschen verwendet wird.

Der zweite Schritt besteht darin, eine Liste von Handles zu erstellen, die an den Hub gesendet werden. Diese Liste ist eine Verbindung zwischen einem Handle und seinem Pfad, der mit einer ganzzahligen Identifikatorin verbunden ist. Dieser Identifier wird vom Hub verwendet, wenn er eine Datenaktualisierung zurückgibt. Für jeden von einem Handle anvisierten Wert wird die von der Sitzung für diesen Handle angegebene Identifikator, dessen Wert, ein Zustand sowie ein Zeitstempel angezeigt

Zusammenfassend sendet der Client die folgenden Daten in einem Schritt namens "Registrierung" der Handles an den Hub:

•	son identifiant de session<
•	une liste de [{id :int, handle}]

Wenn ein oder mehrere Werte als geändert erkannt werden, gibt der Hub die folgenden Daten an die an diesen Werten interessierten Sitzungen zurück:

•	une liste de [{id :int, valeur, date, status}]

Wenn der Hub eine Liste von Handles erhält, die verarbeitet werden sollen, bestimmt er für jeden davon, ob der angegebene Pfad bereits bekannt ist.

Falls ja, ordnet er den Handle mit der von der Sitzung angegebenen Identifikator zu und fügt den bekannten aktuellen Wert in die Liste der Werte ein, um zu dieser Sitzung zurückzukehren. Die Verarbeitung dieses Handles endet dort.

Wenn der Handle nicht bekannt ist, wird er hingegen alle Stecker "durchsuchen". Der Hub legt dann die zu verbindenden Handles in eine spezielle Liste, die schrittweise entstapelt wird. Jeder so entstapelte Handle wird den verschiedenen Steckern zugelegt. Die Connectors, die den Wert verarbeiten können, manifestieren sich selbst, und der Hub bittet sie, diesen Handle zu verwalten.

Ein Connector, der einen Handle unterstützt, versucht zunächst, den Wert abzurufen. Dazu öffnet er eine Verbindung im Zielprotokoll (falls dies noch nicht geschehen ist) und versucht dann, den Handle zu verbinden. So wird eine Zuordnung von Pfad, Wert, Zustand und Zeitstempel erstellt. Der Zustand wird verwendet, um die Zulässigkeit des Wertwiederherstellungsprozesses zu spezifizieren.

Der Connector sendet diese Assoziation zurück an den Hub. Der Hub speichert sie intern und benachrichtigt die an diesem Pfad interessierten Sitzungen.

Interne Aktualisierung der Daten

Das folgende Schema erklärt intern die Aktualisierung eines Datens, der von einem unterstützten Handle angesprochen wird. Wir haben im vorherigen Punkt gesehen, dass, wenn eine Daten für eine Sitzung von Interesse sind, eine Liste zugehöriger Identifier-Assoziationen und Handles erstellt wird, während darauf wartet, dass die Sitzung eine Anfrage zum Abruf von Updates ausstellt.

Die Erkennung einer Wertaktualisierung liegt in der Verantwortung des Connectors. Wenn der Connector auf einem sogenannten 'ereignisbasierten' Protokoll basiert, wartet er auf ein Ereignis, das die Wertänderung anzeigt. Wenn der Connector auf einem aktiven Ansatz basiert, fragt er regelmäßig die Datenquelle ab, um Änderungen an den Werten zu erkennen, die er unterstützen soll.

Wenn eine Änderung erkannt wird, informiert der Connector den Hub über den betroffenen Pfad, einen neuen Wert, ein Änderungsdatum zu diesem Wert oder Status und Status.

Der Hub analysiert diese Informationen und bestimmt, welche Sitzung(en) an diesem Pfad interessiert sind. Wenn keine aktive Sitzung interessiert ist, bittet er die Connectors, diesen Pfad nicht mehr zu unterstützen und ihn zu entladen.

Es bereitet für jede Sitzung ein neues Paket vor, das die Sitzungs-ID für diesen Pfad, den Wert, den Zustand und einen Zeitstempel kombiniert, der an die nächste Aktualisierungsanfrage der Sitzung zurückgegeben wird. Es speichert den Wert parallel, indem er intern mit dem Pfad verknüpft wird. Das Paket, das die Änderungen für eine Sitzung enthält, wird beim Abrufen der Sitzung gelöscht.

Status eines Griffs

In manchen Fällen ist der Zugriff über einen Connector nicht möglich (Konfigurationsprobleme, Sensorfehler, HS-Infrastruktur usw.). Wenn der Hub einer Sitzung den Wert eines Handles übermittelt, muss er dessen Status angeben.

Hier sind die verschiedenen möglichen Status:

• Unbearbeitet: Der Handle kann vom System nicht verwaltet werden.
• UnpluggedConnector: Der mit dem Griff verbundene Stecker ist nicht zugänglich.
• NoConnectorFound: Das vom Griff angegebene Protokoll passt zu keinem Stecker.
• Unerreichbar: Der Stecker kann den Wert des Griffs nicht abrufen.
• ConnectorError: Der Stecker ist fehlerhaft.
• Gut: Der Stecker hat den Wert korrekt abgerufen.
• NieAktualisiert: Der Handle ist korrekt konfiguriert, aber das System meldet keinen Wert.
• Timeout: Der letzte Wert ist zu alt, dann ist es Zeit.

Wenn für einen bestimmten Handle ein anderer Status als "Gut" gemeldet wird, wird dieser im System als getrennt angezeigt. Der Benutzer kann mit der Maus über seine zugehörige Variable fahren, um die Details des Fehlers zu sehen.

Berechnungs-Engine: Handhabungsfehler

Der Hub kann die Implementierung einer Rechen-Engine erfordern, die speziell für Geschäftsanforderungen eingerichtet wird. Einige Daten der Sensoren müssen vor der Aufnahme der Sitzungen verarbeitet werden, insbesondere für die Fehlermeldung.

Für einen Temperatursensor kann der Hub beispielsweise eine Liste von Fehlern im Zusammenhang mit Überschreitung von Schwellenwerten verknüpfen, um den Kunden vor einem Fehler zu warnen: Temperatur zu hoch.

Beim Ändern des Wertes eines Handles stellt die Berechnungs-Engine, wenn sie einen Fehler identifiziert hat, zusätzlich zum Wert des Handles eine Liste zugehöriger Fehler bereit, die vom Spieler verarbeitet werden, um die zugehörige Variable standardmäßig in der Schnittstelle anzuzeigen.

Wenn sich eine Variable wie eine Temperatur im Laufe der Zeit entwickelt, kann ein zugehöriger Fehler bei mehreren Aktualisierungen ihres Wertes aktiv bleiben, sofern ihre Berechnungsregel weiterhin gültig ist. Der Fehler behält die Informationen über das Datum der Ankunft des Fehlers, sodass, wenn eine Temperatur vor 10 Minuten aktualisiert wurde, aber einen Schwellenwert für 2 Stunden überschreitet, die beiden Informationen korrekt in den Client-Anwendungen angezeigt werden.

Die Informationen, die einem Failure innewohnen, sind wie folgt:

• Der Name
• Das Datum des Mangels
• Eine Liste der Metadaten, die mit der Berechnung verbunden sind (der Schwellenwert im Beispiel der Temperatur).
• Eine Art des Defekts. Diese Typen hängen vom Unternehmen ab, daher müssen sie zwischen der Client-Anwendung und den Hub-Managern synchronisiert werden.

Steckverbinderstatus

Zusätzlich zu Updates zur Verwaltung von Werten kann der Hub seinen Sitzungen den internen Zustand seiner Connectors und den Zustand des Systems insgesamt berichten.

Wenn also eine seiner Datenquellen vorübergehend nicht verfügbar ist, werden Nutzer, die mit einem Hub verbunden sind, darüber informiert, dass es ein Problem mit einem oder mehreren Unterelementen des Systems gibt.

Der Status der Verbinder wird in einem Beholder-Player wie folgt dargestellt.