Hub: Panoramica
- Per iniziare
Training
Il Hub Immersivo rappresenta il livello software che interfaccia l'esposizione dei dati e il suo consumo da parte del Beholder.
Rappresenta uno strato universale di indirezione tra un consumatore (ad esempio un giocatore Immersive Beholder) e i dati, indipendentemente dai protocolli utilizzati per accedervi.
Presentazione generale
Il ruolo dell'Hub è ricevere richieste dai consumatori di dati IoT destinati alla supervisione o manutenzione e fornire informazioni adattate alle esigenze dei suoi consumatori in risposta.
L'Hub espone due fronti di connessione: il primo, dedicato a client/applicazioni che consumano dati IoT, ti permette di contattare l'Hub e inviargli richieste tramite un fronte REST. La seconda, la facciata tecnica, permette all'Hub di recuperare dati tramite un protocollo dedicato.
Internamente, il Hub si basa su tre concetti:
- La maniglia
- La sessione
- Il connettore
Manici
I handle rappresentano un percorso verso un dato. Consiste in:
- Un identificatore univoco per il richiedente associato a questi dati
- Un percorso, che rappresenta la "stringa di connessione" ai dati
Il percorso dovrebbe permettere all'Hub di determinare il protocollo e i mezzi per accedere ai dati. È simile a una catena di connessione che permette all'Hub di avviare la tecnologia/protocollo di connessione corretta e di sapere come "unire" i dati per recuperarli.
Prendiamo l'esempio di un " Sensore di temperatura ». Questo potrebbe essere associato a tre proprietà:
- Il valore attuale della temperatura.
- La temperatura massima tollerata.
- La temperatura è tollerata.
Queste tre proprietà potevano essere memorizzate e recuperate tramite due diversi protocolli/tecnologie:
- UCI UA —per il valore attuale.
- Excel : Per le soglie massime e minime tollerate.
I tre percorsi quindi necessari per avere i dati di questo sensore di temperatura sarebbero rispettivamente:
• 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
Il primo percorso è un classico percorso OPC-UA: ns=3;s=BAT6062.ETAG2.TEMP.T652145, i seguenti due sono stati formattati per essere compresi dal connettore Excel dell'Hub: indicano di aprire il file Excel situato nel percorso relativo SITE/GESTBAT/QUALITVIE.xslx e leggere le colonne C e D della linea 22.
Spetta all'Hub interpretare questi percorsi, accedere a questi dati e sempre inviare ai software interessati un valore aggiornato di tali dati.
Se la temperatura cambia, l'Hub si affiderà al protocollo OPC UA per recuperare il valore corrente; se cambiano le soglie di temperatura massima e minima accettabile, l'Hub deve assicurarsi di poter leggere la cella del/i file/i Excel pertinente per recuperare il valore.
La formattazione del percorso permette all'Hub di determinare quale protocollo utilizzare per unire i dati.
L'Hub non ha idea di quale sia il ruolo aziendale di un dato: non è il suo ruolo.
Sessioni
Una sessione rappresenta un accesso effettuato da un consumatore (software di supervisione, sinottico o processo) che desidera sia accedere ai dati sia essere informato sull'evoluzione di questi dati nel tempo.
Quando un edificio è supervisionato, esposta un numero predefinito di apparecchiature che sono esse stesse associate a dati (di mira da Manici). Vedi l'esempio di un sensore di temperatura nel punto precedente.
La sessione può essere pensata come un elenco di handle.
L'Hub riceve questa lista di Handle. Chiederà all'Hub di recuperare i valori collegati e di essere aggiornato sulla loro futura evoluzione.
Pertanto, quando l'Hub rileva l'evoluzione del valore obiettivo da un handle, garantisce che la sessione o le sessioni che hanno richiesto di elaborare i dati lo ricevano quando effettuano una richiesta di aggiornamento.
Connettore
Un connettore rappresenta un canale per accedere ai dati tramite un particolare protocollo (OPC UA, Excel, REST, SQL, Modbus, ecc.).
Un connettore può essere visto come un plug-in che verrà aggiunto all'Hub per estendere le possibilità. L'Hub dispone di connettori per un gran numero di protocolli o tecnologie conosciute (OPC UA, Excel, MQTT, ...).
GraphicStream ha sviluppato un'interfaccia di programmazione API in .Net che permette di creare un connettore dedicato alle tue esigenze per un particolare protocollo, consentendo a una sessione di emettere richieste di monitoraggio Handles che mirano ai dati accessibili in quel protocollo.
Il connettore ha due ruoli all'interno dell'Hub:
- Accesso ai dati
- Assicurati di tenere l'Hub informato sui cambiamenti di questi dati nel tempo
Ad esempio, quando una sessione emette una richiesta di handle. L'Hub, per entrambi, farà richiesta di supporto a tutti i connettori. Se un connettore gestisce il protocollo esposto dal percorso di un handle, risponderà favorevolmente alla richiesta dell'Hub e sarà responsabile di cercare di recuperare i dati e assicurarsi di rimanere aggiornato sull'evoluzione di questi dati.
Funzionamento
L'Hub è quindi il software principale, il conduttore che gestisce l'elaborazione di maniglie, sessioni e connettori.
Può essere paragonata a un database di eventi che; per ogni dato elaborato; sa come avvisare gli attori che hanno espresso interesse per questi dati di uno sviluppo.
Collegare una sessione
Il diagramma alla fine di questo punto mostra la connessione di una sessione con l'Hub e l'implementazione di un processo interno per supportare i handle che saranno emessi dalla sessione.
Il primo passo per accedere all'Hub è creare una sessione. Il client quindi invierà una richiesta di accesso all'Hub.
Se questa richiesta viene accettata, l'Hub restituisce un identificatore di sessione (un GUID) che sarà utilizzato dal client per identificarsi in futuri scambi.
Il secondo passaggio consisterà nella creazione di una lista di handle da inviare all'Hub. Questa lista è un'associazione tra un handle e il suo percorso associato a un identificatore intero. Questo identificatore sarà utilizzato dall'Hub quando restituisce un aggiornamento dei dati. Per ogni valore mirato da un handle, indicherà l'identificatore specificato dalla sessione per questo handle, il suo valore, uno stato e un timestamp
In sintesi, il client invia i seguenti dati all'Hub in un passaggio chiamato "registrazione" degli handle:
• son identifiant de session<
• une liste de [{id :int, handle}]
Quando uno o più valori vengono rilevati come cambiati, l'Hub restituisce i seguenti dati alla sessione interessata a quei valori:
• une liste de [{id :int, valeur, date, status}]
La stessa sessione non deve fornire lo stesso identificatore per due handle con un percorso diverso.
L'identificatore di un handle è contestuale alla sessione. Per lo stesso percorso, due sessioni diverse possono indicare un ID differente.
Quando l'Hub riceve una lista di handle da elaborare, determinerà per ciascuno di essi se il percorso indicato è già noto.
Se sì, associa l'handle all'identificatore specificato dalla sessione e inserisce il valore attuale noto nella lista dei valori da restituire a quella sessione. L'elaborazione per questo handle termina lì.
Se la maniglia non è nota, al contrario, "canvascerà" tutti i connettori. L'Hub poi posiziona le manette da collegare in una lista speciale che verrà gradualmente smontata. Ogni maniglia quindi spostata sarà inviata ai diversi connettori. I connettori in grado di gestire il valore si manifesteranno e l'Hub chiederà loro di gestire questa maniglia.
Un connettore che supporta un handle cercherà prima di recuperare il valore. Per farlo, apre una connessione nel protocollo target (se non l'ha già fatto) e poi cerca di unirsi all'handle. Crea così un'associazione tra percorso, valore, stato e timestamp. Lo stato viene utilizzato per specificare la fattibilità del processo di recupero del valore.
Il connettore invia questa associazione indietro all'Hub. L'Hub la memorizza internamente e notifica la/le sessione interessata a questo percorso.
Il processo di invio di nuovi handle all'Hub tramite una sessione può essere ripetuto quante volte necessario. In ambienti con reti limitate, è consigliabile moltiplicare il numero di chiamate per ridurre la dimensione delle chiamate.
Se una Maniglia non può essere supportata da un connettore, rimane nel pool di Manette da supportare finché un connettore non accetta di processarla o non viene aggiunto un nuovo connettore compatibile all'hub.
Aggiornamento interno dei dati
Lo schema seguente spiega internamente l'aggiornamento di un dato mirato da un handle supportato. Abbiamo visto nel punto precedente che se un dato è di interesse per una sessione, viene preparato un elenco di associazioni di identificatori e handle associati mentre si attende che la sessione emetta una richiesta per recuperare gli aggiornamenti.
Il rilevamento di un aggiornamento di valore è responsabilità del connettore. Se il connettore si basa su un cosiddetto protocollo 'basato su eventi', attenderà un evento che indichi il cambiamento di valore. Se il connettore si basa su un approccio attivo, interrogherà regolarmente la sorgente dati per rilevare eventuali variazioni nei valori che gli è stato chiesto di supportare.
Se viene rilevata una modifica, il connettore notifica all'Hub il percorso interessato, qualsiasi nuovo valore, una data di modifica di quel valore o lo stato e lo stato.
L'Hub analizzerà queste informazioni e determinerà quali sessioni sono interessate a questo percorso. Se nessuna sessione attiva è interessata, chiede ai connettori di non supportare più questo percorso e di scaricarlo.
Prepara un nuovo pacchetto per ogni sessione che combina l'ID della sessione per quel percorso, il valore, lo stato e un timestamp che verrà restituito alla prossima richiesta di recupero di aggiornamento emessa dalla sessione. Memorizza il valore in parallelo associandolo internamente al percorso. Il pacchetto contenente le modifiche per una sessione viene svuotato quando la sessione lo recupera.
Stato di un handle
In alcuni casi, l'accesso alla handle tramite un connettore non è possibile (problemi di configurazione, guasto del sensore, infrastruttura HS, ecc.). Quando l'hub comunica a una sessione il valore di una maniglia, deve specificarne lo stato.
Ecco i diversi stati possibili:
- Non gestito: Il handle non può essere gestito dal sistema.
- UnplugedConnector: Il connettore associato alla maniglia non è accessibile.
- NoConnectorFound: Il protocollo specificato dalla maniglia non corrisponde a nessun connettore.
- Non raggiungibile: Il connettore non riesce a recuperare il valore della maniglia.
- Errore del connettore: Il connettore è in errore.
- Bene: Il connettore recuperava correttamente il valore.
- Mai aggiornato: Il handle è configurato correttamente ma il sistema non segnala alcun valore.
- Timedoutout: L'ultimo valore è troppo vecchio, è timeout.
Quando uno stato diverso da "Good" viene riportato per un determinato handle, apparirà come disconnesso nel sistema. L'utente potrà passare il mouse sulla variabile associata per vedere i dettagli dell'errore.
Se un cliente si è registrato per un handle, l'hub ha l'obbligo di restituire almeno una data per esso, anche se l'hub non sa come gestirla o ha difficoltà a recuperarne il valore. Per farlo, associa uno degli stati precedenti.
Motore di calcolo: guasti nella gestione
L'hub potrebbe richiedere l'implementazione di un motore di calcolo che sarà configurato per soddisfare esigenze specifiche del business. Alcuni dati provenienti dai sensori richiedono l'elaborazione prima di essere esposti alle sessioni, in particolare per la segnalazione dei guasti.
Per un sensore di temperatura, l'hub può, ad esempio, associare un elenco di guasti legati al superamento delle soglie per avvertire il cliente di un guasto: temperatura troppo alta.
Quando si modifica il valore di un handle, se il motore di calcolo ha identificato un difetto, fornisce oltre al valore dell'handle una lista di fallimenti associati che verranno processati dal giocatore per visualizzare la variabile associata come predefinito nell'interfaccia.
Quando una variabile evolve nel tempo, come una temperatura, un guasto associato può rimanere attivo su diversi aggiornamenti del suo valore se la regola di calcolo rimane valida. Il guasto mantiene l'informazione della data di arrivo del guasto, quindi se una temperatura è stata aggiornata 10 minuti fa, ma supera una soglia per 2 ore, le 2 informazioni sono presentate correttamente nelle applicazioni client.
Le informazioni insite in un Guasto sono le seguenti:
- Il nome
- La data del difetto
- Un elenco dei metadati associati al calcolo (la soglia nel caso di esempio della temperatura).
- Un tipo di difetto. Questi tipi dipendono dal business, quindi devono essere sincronizzati tra l'applicazione client e i manager dell'hub.
La gestione dei guasti non è obbligatoria per tutti i handle, solo quando è necessaria una specifica business rule.
Se un sensore di guasto segnala un valore booleano con "vero" come guasto attivo, questa maniglia può essere trattata direttamente come guasto nell'applicazione beholder senza dover generare un guasto sul lato Hub.
Stato del connettore
Oltre agli aggiornamenti dei valori di gestione, l'hub ha la capacità di riportare alle sue sessioni lo stato interno dei suoi connettori e la salute del sistema nel suo complesso.
Quindi, se una delle sue fonti dati è temporaneamente non disponibile, gli utenti collegati a un hub vengono notificati che c'è un problema con uno o più sottoelementi del sistema.
Lo stato dei connettori è presentato in un lettore Beholder come segue.
Lo stato dei connettori è solo a scopo informativo e non è richiesto per il funzionamento del sistema.