Infrastruttura
Il sistema BIGStudio2 è costituito da più componenti:
L’applicativo (desktop o web) BIGStudio2, che funge da interfaccia fra l’utente e il sistema sottostante;
Il MasterGateway, che si occupa di mantenere in collegamento fra loro tutte le componenti e di far transitare le informazioni;
BIGOmnia, il cervello del sistema, si occupa di gestire tutte le automazioni configurate lato interfaccia;
I gateway, che si occupano della comunicazioni fra il sistema è l’esterno (ad esempio il gateway KNX si occupa della comunicazione sul bus KNX); i gateway possibili sono elencati e descritti nella sezione apposita.
Infine, l’ultimo componente costituente è SQLServer, il servizio di SQL che permette l’accesso al database.
Tutti i componenti (escluso l’applicativo) sono servizi di Windows e sono presenti solo sulla macchina server.
Per il corretto funzionamento di BIGStudio2 è necessario che tutti i componenti siano avviati e funzionino correttamente. Monitoraggio da parte dell’utente Il corretto funzionamento dei componenti di BIGStudio2 può essere monitorato tramite i pallini colorati presenti nella parte sinistra della barra di stato dell’applicativo; per ogni componente (escluso SQLServer) è presente un pallino il cui colore rappresenta lo stato:
Monitoraggio da parte dell’utente
Il corretto funzionamento dei componenti di BIGStudio2 può essere monitorato tramite i pallini colorati presenti nella parte sinistra della barra di stato dell’applicativo; per ogni componente (escluso SQLServer) è presente un pallino il cui colore rappresenta lo stato:
- Il servizio è fermo.
- Il servizio è avviato ma non riesce al dispositivo esterno; è visibile nei pallini rappresentati gateway e solitamente è una situazione temporanea tipica della fase di avvio: il servizio si avvia e il pallino diventa giallo, quando si collega al dispositivo esterno (ad esempio il bus KNX) diventa verde. Nel caso in cui il pallino rimanga giallo è necessario verificare la configurazione del gateway e il corretto funzionamento del dispositivo a cui il gateway si collega.
- Il servizio funziona correttamente.
Monitoraggio automatico del sistema
Univocità dell’impianto
Ciascun installazione è ora identificata da un nome impianto da definire nelle Impostazioni → Monitoraggio sistema → Nome impianto che viene utilizzato all’interno delle mail di segnalazione di errore (o rientro errore) per identificare l’impianto da cui deriva l’errore.
Per ora è a discrezione di chi fa l’installazione, da inserire al primo avvio di BIGStudio (lo richiede con un popup ad ogni avvio se non è impostato), poi verrà impostato nel setup e/o creato con Simone un WebService che controllerà l’univocità del nome e manterrà un archivio delle installazioni.
Segnalazioni
Le eventuali segnalazioni di errore vengono inviate per mail all’indirizzo indicato nella chiave di registro MailPassiveCheckService presente sotto il nodo BIG/BIGStudio2.
L’indirizzo è configurabile nei setting di BIGStudio (in caso di indirizzi multipli questi possono essere divisi da ‘;’).
Stato dei servizi
Tutti i servizi di Windows associati ai componenti sono configurati in modalità di avvio Automatico o Automatico (ritardato) in modo che siano avviati all’avvio della macchina.
Inoltre, il Master Gateway e BIGOmnia effettuano periodicamente verifiche sullo stato dei servizi di Windows associati a componenti BIGStudio:
Se i servizi sono correttamente avviati non viene effettuata nessuna azione;
- Se viene trovato un servizio con stato Avvio in corso o Arresto in corso viene riverificato lo stato del servizio per 5 volte (a distanza di 10 secondi);
se durante una successiva verifica il servizio risulta avviato non viene effettuata nessuna azione;
se durante una successiva verifica il servizio risulta interrotto viene fatto ripartire;
se al termine lo stato è ancora in Avvio in corso o Arresto in corso viene forzata l’interruzione del servizio e il suo riavvio;
Se viene trovato un servizio con stato Arrestato il servizio viene fatto ripartire
La lista dei servizi da monitorare è costituita da tutti i servizi non disabilitati che soddisfano almeno uno dei seguenti requisiti:
- Il nome è SRVMASTERGATEWAY
- Il nome inizia con SRVKONNEXFALCON
- Il nome inizia con SRVBIG
A questi servizi si aggiungono quelli presenti nella chiave di registro BIGServicesToCheck presente sotto il nodo BIG/BIGStudio2.
La verifica viene effettuata un minuto dopo l’avvio e poi periodicamente in base ai setting di BIGStudio (chiavi di registro CheckServicesInterval e CheckServicesMaxAttempt):
Figura 10
Se dopo CheckServicesMaxAttempt tentativi un servizio non risulta avviato viene inviata una segnalazione via mail.
Se dopo aver inviato la mail di segnalazione errore il servizio viene riavviato correttamente in un tentativo successivo viene inviata una mail di rientro errore.
Esempio di log del Master Gateway in caso di servizi funzionanti:
>> INFO: CheckAndRestartStoppedServices started...
>> INFO: CheckAndRestartStoppedServices info →
*** Service srvBIGOmnia correctly running!
*** Service srvKonnexFalcon.NETGateway correctly running!
*** Service MSSQL$SQLBIGSTUDIO correctly running!
Esempio di log del Master Gateway in caso di servizi stoppato:
>> INFO: CheckAndRestartStoppedServices info →
*** Service srvBIGInnoEdgeGateway NOT RUNNING but Stopped
*** Service srvBIGInnoEdgeGateway status = Running
***Service srvBIGInnoEdgeGateway RESTARTED!
*** Service srvBIGOmnia NOT RUNNING but Stopped
*** Service srvBIGOmnia status = Running
***Service srvBIGOmnia RESTARTED!
*** Service srvKonnexFalcon.NETGateway NOT RUNNING but Stopped
*** Service srvKonnexFalcon.NETGateway status = Running
***Service srvKonnexFalcon.NETGateway RESTARTED
*** Service MSSQL$SQLBIGSTUDIO correctly running!
Stato di attivazione del gateway
Oltre al controllo precedente viene eseguito solo dal Master Gateway un controllo dello stato di attivazione dei gateway: il Master invia periodicamente ad ogni gateway connesso un messaggio di handshake e rileva la risposta.
Se dopo N tentativi di handshake un gateway non risponde viene stoppato (l’automatismo del riavvio dei servizi lo farà ripartire).
Se dopo M tentativi di handshake un gateway non risponde (compreso il riavvio) viene inviata una segnalazione e viene riavviato il conteggio degli handshake per quel gateway.
Se dopo aver inviato la mail di segnalazione errore il servizio viene ritorna a rispondere all’handshake viene inviata una mail di rientro errore.
N è definito tramite la chiave di registro CheckHandShakeMaxAttemptBeforeStop.
M è definito tramite la chiave di registro CheckHandShakeMaxAttemptBeforeSendMessage.
Figura 11
Esempio di log del Master Gateway in caso di servizi funzionanti:
CheckAliveBIGServices started…
CheckAliveBIGServices send hello to 956B0F41-9CD1-4E44-8E1C-080B21990F6D
CheckAliveBIGServices send hello to A08D9D13-D387-42C8-AD88-93D525F2AA3B
CheckAliveBIGServices received hello from 956B0F41-9CD1-4E44-8E1C-080B21990F6D
CheckAliveBIGServices received hello from A08D9D13-D387-42C8-AD88-93D525F2AA3B
Esempio di log del Master Gateway in caso di servizio che non risponde all’handshake (neanche dopo il riavvio):
CheckAliveBIGServices started…
CheckAliveBIGServices send hello to 956B0F41-9CD1-4E44-8E1C-080B21990F6D
CheckAliveBIGServices send hello to A08D9D13-D387-42C8-AD88-93D525F2AA3B
CheckAliveBIGServices received hello from 956B0F41-9CD1-4E44-8E1C-080B21990F6D […]
CheckAliveBIGServices stopped service srvKonnexFalcon.NETGateway after 10 minutes of hello silence[…]
CheckAliveBIGServices send email for gateway Konnex Falcon .NET Gateway after 15 minutes of hello silence
Connessione del gateway del dispositivo controllato
Il master riceve anche le segnalazioni riguardo la connessione del gateway al dispositivo controllato.
Nel caso in cui il gateway rimanga scollegato dal dispositivo per più di N secondi viene inviata una segnalazione (il tempo è comprensivo anche degli eventuali riavvii dei servizi previsti dai servizi stessi o da altri meccanismi).
Se dopo aver inviato la mail di segnalazione errore il servizio si riconnette correttamente viene inviata una mail di rientro errore.
Il tempo massimo di attesa prima di una riconnessione è configurabile da BIGStudio (setting CheckconnectionsMaxWait)
Figura 12
Esempio di log del Master Gateway:
All’avvio
Gateway :BIG InnoEdge Gateway (956B0F41-9CD1-4E44-8E1C-080B21990F6D) disconnected from the controlled device! Start disconnection timer…
Gateway :Konnex Falcon .NET Gateway (A08D9D13-D387-42C8-AD88-93D525F2AA3B) disconnected from the controlled device! Start disconnection timer…
Alla connessione al dispositivo di un gateway
Gateway :BIG InnoEdge Gateway (956B0F41-9CD1-4E44-8E1C-080B21990F6D) connected to the controlled device! Stop disconnection timer…
In caso di mancata riconnessione nel tempo previsto
Gateway :Konnex Falcon .NET Gateway (A08D9D13-D387-42C8-AD88-93D525F2AA3B) has been disconnected from the device for more than 200 seconds! Sending mail!
Controllo interno del sistema – Stato del gateway
Ciascun gateway monitora lo stato della connessione al dispositivo esterno a cui deve collegarsi, in particolare:
Falcon.NET Gateway: tenta la connessione 15 volte (a distanza di 10 secondi) e se al termine dei tentativi non si è ancora collegato il servizio si riavvia.
ModBusGateway : risulta sempre come connesso.
BlueWaveGateway: tenta la connessione al software FlyStart.
DormaKabaSaflockSystem6000Gateway: tenta la connessione ogni 10 secondi per le prime 100 volte, poi allunga il tempo di attesa senza fine.
GSMGateway: tenta la connessione al modem GSM ogni 10 secondi per 5 volte poi ogni 10 minuti senza fine.
InnoEdgeGateway: pinga all’avvio e poi su richiesta.
IntesisWMP: tenta la connessione ai dispositivi Intesis all’avvio e poi su richiesta.
MBus: risulta sempre come connesso.
SaltoISGateway: tenta la connessione al server Salto ogni 10 secondi per le prime 100 volte, poi allunga il tempo di attesa senza fine.
(questa è la situazione attuale, qualcuno potrebbe essere migliorabile)
Ordine delle segnalazioni d’errore
Gli errori hanno priorità pari all’elenco precedente, perciò:
Viene controllato l’avvio di tutti i servizi
Nel caso in cui un servizio non sia partito nel tempo previsto viene inviata la segnalazione
Per tutti i gateway viene tentato l’handshake periodicamente
Nel caso in cui un servizio non risponda nel tempo previsto viene inviata la segnalazione solo se il servizio risulta attivo
Per tutti i gateway viene controllata la connessione al dispositivo
Nel caso in cui un servizio non si colleghi al dispositivo nel tempo previsto viene inviata la segnalazione solo se il servizio è attivo e risponde all’handshake
La singola segnalazione di errore invece viene reinviata periodicamente (es. se il servizio non parte ed è previsto un controllo ogni 5 minuti e l’invio mail dopo 2 tentativi falliti verrà inviata una segnalazione ogni 10 minuti; lo stesso vale per gli altri tipi di errore.)
Buone norme da mantenere nella configurazione dei tempi:
Tempo controllo dello stato dei servizi < Intervalli handshake * tentativi prima di segnalazione handshake
Tempo controllo dello stato dei servizi < Attesa massima in caso di disconnessione
In caso contrario se i servizi muoiono un attimo dopo il controllo dei servizi c’è il rischio che partano le altre segnalazioni quando in realtà il problema principale è il servizio fermo e potrebbe essere risolto dal controllo dello stato dei servizi senza disturbare l’utente.
Tempo controllo handshake * numero di handshake mancanti prima del riavvio < Tempo controllo dello stato dei servizi
Così l’eventuale stop per mancato handshake sfrutta il riavvio del controllo dello stato dei servizi e si evita di fare due stop consecutivi se intanto non è passato il controllo dello stato a riavviare
Tempo controllo handshake * numero di handshake mancanti prima del riavvio < Attesa massima in caso di disconnessione
Così ci accertiamo che il controllo dell’handshake sia valido prima di mandare l’eventuale segnalazione di mancata connessione (se infatti non c’è handshake non ci deve essere segnalazione di mancata connessione ma di mancato handshake).
Una buona configurazione può essere la seguente
Figura 13
Il Master
Ogni 5 minuti controlla lo stato dei servizi.
Se dopo 3 minuti non riceve handshake stoppa il servizio.
Se dopo 7 minuti non riceve handshake invia la segnalazione.
Se dopo 6 minuti non si è connesso al dispositivo invia la segnalazione.
BIGOmnia controlla ogni 10 minuti lo stato dei servizi.