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 clienti/applicazioni che consumano dati IoT, permette di contattare l'Hub e inviargli richieste tramite un fronte REST. La seconda 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. È composto da:
- Un identificatore univoco per il richiedente associato a questi dati
- Un percorso, che rappresenta la "stringa di connessione" ai dati
Il percorso deve 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
Quindi, quando una sessione rilascia 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 che rimanga aggiornato sull'evoluzione di tali dati.
Funzionamento
L'Hub è quindi il software principale, il conduttore che gestisce l'elaborazione di maniglie, sessioni e connettori.
Può essere paragonato a un database di eventi che; per ogni dato elaborato; sa come avvertire gli attori che hanno mostrato 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 invierà quindi 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 passo consisterà nel creare 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'ID della sessione di quell'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 diverso.
Quando l'Hub riceve una lista di handle da elaborare, determinerà per ciascuno di essi se il percorso indicato è già noto.
Se lo fa, associa l'handle all'identificatore specificato dalla sessione e inserisce il valore attuale noto nell'elenco dei valori da restituire a quella sessione. L'elaborazione per questa impugnatura si ferma qui.
Se la maniglia non è nota, al contrario, "canvasculerà" tutti i connettori. L'Hub poi posiziona le maniglie da collegare in una lista speciale che verrà smontata gradualmente. Ogni maniglia così spostata sarà sottoposta ai diversi connettori. I connettori che possono supportare il valore si manifesteranno e l'Hub chiederà loro di gestire questo handle.
Un connettore che supporta una maniglia tenterà prima di recuperare il valore della maniglia. Per farlo, apre una connessione nel protocollo bersaglio (se non l'ha già fatto) e poi cerca di unirsi all'handle. Costruisce così un percorso di associazione, un valore, uno stato e un timestamp. La dichiarazione consente di specificare la fattibilità del processo di recupero del valore.
Il connettore riporta questa squadra all'Hub. L'Hub lo 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 sia necessario. In ambienti con rete limitata, è consigliabile aumentare 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
Il seguente schema 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 preparata una lista di associazioni e handle associati mentre la sessione lancia 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 la variazione di valore. Se il connettore si basa su un'andatura attiva, interrogherà periodicamente la sorgente dati per eventuali modifiche ai valori che le è 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 aggiornamento emessa dalla sessione. Immagazzina valore in parallelo associandolo internamente al percorso. Il pacchetto contenente le modifiche di una sessione viene rimosso quando la sessione lo recupera.
Stato di un handle
In alcuni casi, l'accesso tramite un connettore non è possibile (problemi di configurazione, sensore difettoso, infrastruttura HS...). Quando l'hub comunica il valore di un handle a una sessione, deve specificarne il status.
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 "Buono" viene segnalato per un determinato handle, apparirà come disconnesso nel sistema. L'utente potrà passare il mouse sopra la variabile associata per avere i dettagli dell'errore.
Se un cliente si è registrato per un handle, l'hub ha l'obbligo di restituire almeno una dato, anche se l'hub non sa come gestirlo o ha problemi a recuperarne il valore. Per farlo, combina 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 specifiche esigenze aziendali. Alcuni dati provenienti dai sensori richiedono l'elaborazione prima di essere esposti alle sessioni, in particolare per la segnalazione di 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 cambia 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 le informazioni sulla data di arrivo del guasto, quindi se una temperatura è stata aggiornata 10 minuti fa, ma supera una soglia per 2 ore, le due informazioni vengono 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 dall'azienda, 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.