Update specifiche x SOUR

This commit is contained in:
Samuele E. Locatelli
2019-04-23 14:22:19 +02:00
parent 263e2f9bb2
commit e2c01c66bd
16 changed files with 26 additions and 26 deletions
+26 -26
View File
@@ -347,18 +347,13 @@ Riepilogo valori nell'albero REDIS legati ai canali di comunicazione con il clou
| ------ | ------------------------------------------- | -------- | -------------------------------------------------------------------------------------- |
| SERVER | SOUR:MConnect | {folder} | Folder che contiene i canali di comunicazione IN/OUT tra HMI e MaestroConnect |
| SERVER | SOUR:MConnect:ChannelsIN | {folder} | Folder che contiene i canali IN INGRESSO (Maestro Connect --> HMI) |
| SERVER | SOUR:MConnect:ChannelsIN:DataError | {folder} | Folder che contiene l'elenco degli errori segnalati |
| SERVER | SOUR:MConnect:ChannelsIN:DataError:20181105 | HashList | Tabella errori |
| SERVER | SOUR:MConnect:ChannelsIN:DataError:20181105 | HashList | Tabella che contiene l'elenco degli errori segnalati |
| SERVER | SOUR:MConnect:ChannelsIN:AlertHMI | {folder} | Folder che contiene l'elenco degli alert (generati dal cloud) che HMI deve preesentare |
| SERVER | SOUR:MConnect:ChannelsIN:DataReq | {folder} | Folder che contiene l'elenco delle richieste di file export verso cloud |
| SERVER | SOUR:MConnect:ChannelsIN:DataReq:20181104 | HashList | Tabella richiesta produzione files |
| SERVER | SOUR:MConnect:ChannelsIN:LogReq | {folder} | Folder che contiene l'elenco degli eventi di notifica verso HMI |
| SERVER | SOUR:MConnect:ChannelsIN:LogReq:20181106 | HashList | Tabella interventi manutenzione |
| SERVER | SOUR:MConnect:ChannelsIN:DataReq | HashList | Tabella richiesta produzione files export verso cloud |
| SERVER | SOUR:MConnect:ChannelsIN:LogReq | HashList | Tabella che contiene l'elenco degli eventi di notifica verso HMI |
| SERVER | SOUR:MConnect:ChannelsOUT | {folder} | Folder che contiene i canali IN USCITA (HMI --> Maestro Connect) |
| SERVER | SOUR:MConnect:ChannelsOUT:DataReq | {folder} | Folder che contiene l'elenco dei task di file export eseguiti verso cloud |
| SERVER | SOUR:MConnect:ChannelsIN:DataReq:20181104 | HashList | Tabella files prodotti corrispondenti a richieste |
| SERVER | SOUR:MConnect:ChannelsOUT:LogReq | {folder} | Folder che contiene l'elenco dei log prodotti su richiesta |
| SERVER | SOUR:MConnect:ChannelsOUT:LogReq:20181104 | HashList | Tabella log prodotti su richiesta |
| SERVER | SOUR:MConnect:ChannelsIN:DataReq | HashList | Tabella files prodotti corrispondenti a richieste |
| SERVER | SOUR:MConnect:ChannelsOUT:LogReq | HashList | Tabella log prodotti su richiesta |
<div style="page-break-after: always;"></div>
@@ -370,7 +365,6 @@ In particolare definisce gli aspetti necessari a garantire la realizzazione del
1. Nuova prestazione di **notifica da parte del cloud di Maestro Connect** di informazioni verso le HMI 2.0 - MaestroConnect può inviare notifiche a HMI 2.0, come ad esempio "Allerta loperatore HMI 2.0 con opportuna segnalazione visuale per consultare MaestroConnect riguardo lavvenuta scadenza di unazione di Manutenzione Ordinaria"
2. Nuova prestazione di **richiesta da MaestroConnect a HMI per eseguire un task** (ad es. produrre un file BackupExpress, file di log eventi HMI, etc). Questa prestazione sarà utilizzata dai ServiceHotliners che potranno così generare e prelevare file di log dalla macchina con comandi "quasi real-time" remoti
3. Nuova prestazione per la **gestione utenti** di MaestroConnect
### Aspetti tecnici salienti
@@ -396,7 +390,7 @@ In particolare si ipotizza di impiegare un canale diretto e privilegiato [B] di
Si ipotizza di impiegare unarea REDIS per poter svolgere il compito di trasferire informazioni speciali a due vie tra Maestro Connect e HMI 2.0 secondo le modalità di seguito descritte, e con riferimento a questo esempio di partizionamento del DB REDIS:
![RedisDB](images/SchemaRedisDB.png)
![RedisDB](images/SchemaRedisDB3.png)
- Unarea principale **MConnect** come "contenitore logico" dell funzionalità per la connessione diretta, così organizzato:
- **MConnect**
@@ -436,7 +430,7 @@ Ad esempio nella schermata riportata di seguito si rappresentano due errori rile
Esempio:
![DataReq](images/DataErr.png)
![DataReq](images/DataErr2.png)
<div style="page-break-after: always;"></div>
@@ -444,7 +438,7 @@ Esempio:
Nel canale **AlertHMI** saranno salvate le richieste di notifica inerenti gli eventi di manutenzione di ogni natura/tipologia, secondo le seguenti regole:
- una HashTable giornaliera (che verrà eventualmente eliminata dal gateway/cloud tramite cancellazione/TTL)
- una HashTable **globale** (che verrà ripulita dal gateway/cloud tramite cancellazione puntuale)
- in ogni HashTable è organizzata in formato Key/Value
- ogni riga ha una chiave UNIVOCA generata dal cloud/gateway
- ogni riga è una notifica indipendente dal resto di un intervento in area Manutenzione
@@ -454,14 +448,14 @@ Nel canale **AlertHMI** saranno salvate le richieste di notifica inerenti gli ev
- HMI 2.0 potrà leggere tutte le righe ed eventualmente raggruppare le richieste per tipologia a livello di interfaccia
- L'utente sarà guidato a cliccare sui link per andare su MaestroConnect
In particoalre per le 2 tipologie di notifiche ad ora implementate:
In particolare per le 2 tipologie di notifiche ad ora implementate:
- valore "TroubleShooting" - HMI notifica al suo operatore bordo macchina con un colore opportuno un msg, o icona, o qualsivoglia per segnalare "c'è uno o più allarmi da gestire, consulta MaestroConnect"
- valore "Maintenance" - HMI notifica al suo operatore bordo macchina con un colore opportuno diverso dal precedente, per segnalare "c'è una o più azioni di manutenzione ordinaria da eseguire" gli UT decidono poi come gestire un "Cancel" della segnalazione, che ha il solo scopo di "eliminare temporaneamente" la notifica stessa. MaestroConnect cancellerà la URL di notifica SOLO quando un utente autorizzato dichiarerà EFFETTUATA l'azione suggerita per il TroubleShooting o per la Manutenzione La URL inviata da MaestroConnect al momento non genera altre info
Esempio
![DataReq](images/AlertHMI.png)
![DataReq](images/AlertHMI2.png)
In questo caso riportato abbiamo
@@ -476,7 +470,7 @@ Sarà compito del cloud eliminare tutte le righe di richiesta cessate le cause d
Nel canale **DataReq** saranno salvate le richieste di dati, secondo le seguenti regole:
- una HashTable giornaliera (che verrà eventualmente eliminata dal gateway/cloud tramite cancellazione/TTL, tipicamente TTL=30gg)
- una HashTable **globale** (che verrà ripulita dal gateway/cloud tramite cancellazione puntuale)
- in ogni HashTable è organizzata in formato Key/Value
- ogni riga ha una chiave UNIVOCA generata dal cloud/gateway come key
- ogni riga è un TASK da eseguire
@@ -489,7 +483,7 @@ Nel canale **DataReq** saranno salvate le richieste di dati, secondo le seguenti
Esempio:
![DataReqIN](images/DataReqIN.png)
![DataReqIN](images/DataReqIN2.png)
<div style="page-break-after: always;"></div>
@@ -497,7 +491,7 @@ Esempio:
Nel canale **LogReq** saranno inviate le richieste di salvataggio dei log secondo le seguenti regole:
- una HashTable giornaliera (che verrà eventualmente eliminata dal gateway/cloud tramite cancellazione/TTL, tipicamente TTL=30gg)
- una HashTable **globale** (che verrà ripulita dal gateway/cloud tramite cancellazione puntuale)
- in ogni HashTable è organizzata in formato Key/Value
- ogni riga ha una chiave UNIVOCA generata dal cloud/gateway come key
- ogni riga è un TASK da eseguire
@@ -511,7 +505,7 @@ Nel canale **LogReq** saranno inviate le richieste di salvataggio dei log second
Esempio:
![DataReqIN](images/LogReqIN.png)
![DataReqIN](images/LogReqIN2.png)
Come si vede sono stati registrati 3 richieste:
@@ -526,11 +520,16 @@ Come si vede sono stati registrati 3 richieste:
### **ChannelsOUT**: notifica verso Cloud di avvenuta esecuzione di richieste
HMI 2.0 utilizza un ulteriore folder "esterno", allocato su gateway, e dedicato ai file prodotti da HMI 2.0. Il file - con opportuno naming - viene processato da MaestroConnect e di conseguenza eliminato una volta caricato.
HMI 2.0 utilizza **una apposita procedura di upload tramite SDK**, tramite la qule i file prodotti da HMI 2.0 sono inviati sul cloud.
Per agevolare il processo e rendere maggiormente controllata l'esecuzione, si chiede la notifica dei task file-based su apposita area REDIS.
La procedura è descritta in maggior dettaglio nella documentazione dedicata all'SDK stesso, ma in termini denerali si tratta di invocare l'SDK come di seguito descritto:
Ogni file prodotto è una risposta ad un evento ricevuto tramite ChannelsIN (es: Backupexpress).
* Chiamata a **TryUpLoadFile**
* Invio di un cancellation token e di un oggetto Progress di tipo Result
* Invio del path completo del file da caricare
* inzio opzionale del nome del file (se si volesse cambiare il nome del file rispetto a qeullo presente sul filesystem, ad esempio per usare un nome standard)
Per agevolare il processo e rendere maggiormente controllata l'esecuzione, si chiede la notifica dei task file-based su apposita area REDIS, copiando il risultato delal chiamata al servizio di pubblicazione direttamente nell'area REDIS di ChannelsOUT corrispondente alla richiesta in ChannelsIN, dove ogni risposta ad un file inviato è relativa ad una richiesta ricevuto tramite ChannelsIN (es: Backupexpress).
<div style="page-break-after: always;"></div>
@@ -540,7 +539,7 @@ In questo caso sono riportati puntulamente i dati relativi ai richiesti e proces
Esempio:
![DataReqOUT](images/DataReqOUT2.png)
![DataReqOUT](images/DataReqOUT3.png)
Esempio JSon **SUCCESSO**
@@ -557,6 +556,7 @@ Esempio JSon **SUCCESSO**
"Message": "Upload Done!"
}
```
Esempio JSon **ERRORE**
```JSon
@@ -584,7 +584,7 @@ La mancata scrittura in toto della riga indica che il task di produzione del fil
Nel canale **LogReq** saranno inviate le risposte alle richieste di salvataggio dati di log secondo le seguenti regole:
- una HashTable giornaliera (che verrà eventualmente eliminata dal gateway/cloud tramite cancellazione/TTL, tipicamente TTL=30gg)
- una HashTable **globale** (che verrà ripulita dal gateway/cloud tramite cancellazione puntuale)
- in ogni HashTable è organizzata in formato Key/Value
- ogni riga ha una chiave UNIVOCA corrispondente alla richiesta ricevuta (e cui fare riferimento come risposta)
- HMI 2.0 andrà a salvare nel canale duale (ChannelsIN:LogReq) il risultato di ogni richiesta nella forma di un record JSON serializzato corrispondende alla richiesta
@@ -597,7 +597,7 @@ Nel canale **LogReq** saranno inviate le risposte alle richieste di salvataggio
Esempio:
![FileLog](images/LogReqOUT.png)
![FileLog](images/LogReqOUT2.png)
Di seguito sono esplicitamente riportati i campi e formati richeisti e concordati nell'incontro hangout del 2019.01.30 per le 3 tipologie di dati, eventualmente declinati secondo le necessità di ogni UTE coinvolta.
BIN
View File
Binary file not shown.
Binary file not shown.

Before

Width:  |  Height:  |  Size: 116 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 103 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 7.0 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 58 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 97 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 119 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 91 KiB