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 stellt zwei Verbindungsfronten offen: Die erste, die für Kunden/Anwendungen reserviert ist, die IoT-Daten konsumieren, 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 muss es dem Hub ermöglichen, das Protokoll und die Mittel 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 "verbindet", 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. Es 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 Anschlüsse 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

Wenn also eine Sitzung eine Anfrage nach Handles stellt. Der Hub wird für beide eine Unterstützungsanfrage an alle Connectoren stellen. Wenn ein Connector das Protokoll verwaltet, das durch den Pfad eines Handles freigegeben wird, reagiert er positiv auf die Anfrage des Hubs und ist dafür verantwortlich, die Daten abzurufen und sicherzustellen, dass sie mit der Entwicklung dieser Daten auf dem neuesten Stand bleiben.

Betrieb

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

Es kann mit einer Ereignisdatenbank verglichen werden, die; für jede verarbeitete Daten; weiß, wie man die Akteure, die Interesse an diesen Daten gezeigt haben, vor einer Entwicklung warnt.

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, eine Sitzung zu erstellen. 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 Assoziation 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 Sitzungs-ID dieses Handles, dessen Wert, ein Zustand und ein Zeitstempel angegeben

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.

Wenn dies der Fall ist, ordnet er den Handle mit der von der Sitzung festgelegten 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.

Ist der Griff nicht bekannt, wird er hingegen alle Stecker "durchsuchen". Der Hub platziert dann die zu verbindenden Handles in eine spezielle Liste, die schrittweise entstapelt wird. Jeder so ungestapelte Griff wird den verschiedenen Steckern unterworfen. Connectors, die den Wert unterstützen können, manifestieren sich und der Hub wird sie bitten, diesen Handle zu verwalten.

Ein Stecker, der einen Griff unterstützt, versucht zunächst, den Wert des Griffs abzurufen. Dazu öffnet es eine Verbindung im Zielprotokoll (falls dies noch nicht geschehen ist) und versucht dann, sich mit dem Handle zu verbinden. So baut er einen Assoziationspfad, einen Wert, einen Zustand und einen Zeitstempel auf. Die Aussage ermöglicht es, die Machbarkeit des Wertrückgewinnungsprozesses zu spezifizieren.

Der Stecker bringt dieses Team zurück zum Hub. Der Hub speichert es intern und benachrichtigt die Sitzung(en), die an diesem Pfad interessiert sind.

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 ein Datenstück für eine Sitzung von Interesse ist, eine Liste der zugehörigen Identifier-Assoziationen und -Handles erstellt wird, während auf die Sitzung gewartet wird, um eine Anfrage zum Abruf von Updates zu stellen.

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 Gang basiert, fragt er periodisch die Datenquelle nach Änderungen der Werte ab, 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 oder welche Sitzungen an diesem Weg interessiert sind. Wenn keine aktive Sitzung interessiert ist, bittet er die Connectors, diesen Pfad nicht mehr zu unterstützen und ihn zu entlasten.

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. Er speichert Wert parallel, indem er ihn intern mit dem Pfad verknüpft. Das Paket, das die Änderungen für eine Sitzung enthält, wird gelöscht, wenn die Sitzung es abruft.

Status eines Griffs

In manchen Fällen ist der Zugriff über einen Connector nicht möglich (Konfigurationsprobleme, fehlerhafter Sensor, HS-Infrastruktur ...). Wenn der Hub den Wert eines Handles an eine Sitzung ü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 ein anderer Status als "Gut" für einen bestimmten Handle 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 anzuzeigen.

Berechnungs-Engine: Handhabungsfehler

Der Hub kann die Implementierung einer Compute-Engine erfordern, die speziell für Geschäftsanforderungen eingerichtet wird. Einige Daten der Sensoren müssen vor der Veröffentlichung der Sitzungen verarbeitet werden, insbesondere zur Meldung von Fehlern.

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 im Laufe der Zeit ändert, wie etwa eine Temperatur, kann ein zugehöriger Fehler bei mehreren Aktualisierungen ihres Wertes aktiv bleiben, sofern ihre Berechnungsregel weiterhin gültig ist. Der Fehler speichert die Informationen über das Datum der Ankunft des Fehlers, sodass, wenn eine Temperatur vor 10 Minuten aktualisiert wurde, aber eine Schwelle für 2 Stunden überschreitet, die 2 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 Defekt. Diese Typen hängen vom Unternehmen ab und müssen daher 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.