Newer
Older
# Introduzione
Il progetto presentato dal gruppo2 si occupa di fornire ad un utente funzionalità di domotica in una LAN, e sono le seguenti: controllo remoto delle luci, sistema di antifurto e metodo di deterrenza delle intrusioni.
# 1. Specifiche funzionali
## 1.1. Controllo tramite sensori ed attuatori
Il sistema nella LAN è costituito da una beaglebone (con attuatori e led) e un arduino (che presenta un sensore di luminosità).
Gli attuatori simulano gli interruttori e i sensori di movimento. Questi ultimi controllano l'attivazione dell'allarme dell'antifurto e, assieme agli interruttori e al sensore di luminosità, lo stato delle luci.
La parte in cloud consiste di un server che fornisce una webapp, dalla quale poter controllare gli elementi della LAN; il servizio di autenticazione con Keycloak; il domain manager, responsabile di mantenere la consistenza dei dati; e il cloud app manager, il quale s'interfaccia con il broker mosquitto che è connesso in bridge con la beaglebone della LAN.
I servizi sono stati resi sicuri con l'implementazione di HTTPS e per il broker con TLS (e WSS).
# 2. Analisi
## 2.1. Installazione del sistema in reti private
L'installazione del sistema avviene senza configurazioni particolari poiché l'uso di mosquitto, con la configurazione da noi impostata, rende il sistema plug-n-play, ovvero è sufficiente collegarlo alla rete domestica per avere le funzionalità disponibili.
## 2.2. Accessibilita' da rete pubblica e da rete privata
Tutti i microservizi comunicano tra di loro grazie a connessioni ai broker mosquitto. I due broker sono connessi tra loro grazie al bridging, che ci permette di effettuare lo scambio di comandi su entrambi i servizi.
La connettibilità è indistintamente garantita sia da LAN sia da remoto grazie all'impiego di brokers Mosquitto. L'architettura che ne garantisce il funzionamento è la seguente: un broker è posizionato in remoto con IP pubblico e statico (smartcity) al quale si connettono il broker della LAN, della webApp ed il CloudAppManager. In questo modo, con il bridging effettuato a smartcity, siamo in grado di inviare e ricevere messaggi su ongi microservizio che lo richieda.
In entrambi i casi, il login è gestito tramite Keycloak che permette l'accesso alla webapp che si interfaccia al resto del sistema.
Grazie a questa caratteristica, l'accesso può avvenire sia dalla rete pubblica che da quella privata, senza distinzioni.
## 2.3. Caratteristiche del traffico dati da sostenere e vincoli in tempo reale
Essendo un sistema di domotica, è necessario che i comandi impartiti dall'utente vengano attutati una ed una sola volta ed in tempo utile, in modo tale da non inficiare l'esperienza dell'utente.(..esperienza migliore di analogica...) La quantità di traffico da gestire non è eccessiva, dal momento che le uniche 2 fonti di produzione di messaggi oltre a quella umana sono la BBGPIO che pubblica a tempo costante di 10s ed il microservizio dell'antifurto che pubblica ogni 8s.
La componente umana la riteniamo non precisamente quantificabile, ma proporzionale nella quantità di messaggi prodotti rispetto al numero di lampadine e sensori/interruttori.
## 2.4. Tecniche viste a lezione con cui soddisfare i requisiti
Per soddisfare i requisiti, e' possibile usare delle chiamate REST o il protocollo MQTT. Entrambe queste modalita' sono utilizzabili poiche' permettono la comunicazione tra servizi diversi.
L'implementazione dei microservizi permette un tempo di installazione minore grazie alla dimensione inferiore dei file. Inoltre la scalabilita' del sistema viene semplificata di molto, infatti ...
# 3. Approccio tecnologico
## 3.1. Vantaggi dell'uso di un message broker e come lo giudichiamo rispetto alle altre scelte
Il message broker risulta fondamentale nello sviluppo di un'applicazione formata da vari microservizi, poiche' permette a questi di registrarsi all'ascolto di topic specifici dai quali ricevere i messaggi degli altri microservizi. In questo modo il lavoro svolto da ognuno e' inferiore rispetto ad un progetto dello stesso tipo che non si avvale dell'utilizzo di mqtt.
L'utilizzo di mosquitto assicura il recapito di oggi messaggio nel numero a noi necessario.
La scelta effettuata risulta migliore rispetto all'uso di chiamate REST per la sua scalabilità. Volendo rappresentare il sistmea con un grafo non orientato in cui i nodi sono i microservizi e gli archi le connessioni tra i di essi, grazie al message broker otteniamo un grafo molto più sparso, in cui i microservizi comunicano con esso, anzichè istanziare una connessione per ogni altro microservizio.
Anche la manutenibilità migliora.
# 4. Architettura del software
## 4.1. Organizzazione del software (evidenziandone i moduli)
Il Webserver, configurato per usare HTTPS, fornisce la Webapp al client grazie all'uso di API REST. Il Webserver e' in grado di mantenere molteplici sessioni allo stesso tempo.
Ogni richiesta effettuata tramite API e' gestita da un nuovo Thread, il quale esegue il codice di una classe; una volta gestita la richiesta, il Thread viene eliminato.
La Webapp e' suddivisa in 3 parti:
- L'autenticazione: la prima pagina che viene fornita serve per ridirigere l'utente alla pagina di login su Keycloak.
- La lista di domini: in questa pagina vengono mostrati tutti i domini appartenenti all'utente autenticato. Nel caso in cui questi sia amministratore di un dominio, a destra dello stato viene mostrato un cestino, per poterlo eliminare; inoltre il bottone dello stato e' cliccabile, consentento la sua attivazione/spegnimento. Al contrario, se non e' un amministratore e il dominio e' attualmente attivo, egli puo' solamente accedere alla pagina d'interazione.
- L'interazione con il proprio dominio: questa e' la pagina principale del progetto, in cui si possono vedere tutti i dettagli del dominio installato. In alto si trovano fino a 3 bottoni che rappresentano i microservizi installati nel dominio scelto. Alla loro pressione, mostrano la UI relativa al loro microservizio, con la quale interagire per apportare modifiche.
Il Domain Manager e' un microservizio che opera in cloud, con funzionalita' sia da server REST sia da client con interazioni con il database (DB) dell'intero sistema. Si occupa di soddisgare le richieste provenienti dalla Webapp, controllandone la validita' e la consistenza con il DB e inoltrarle al Cloud App Manager (CAM). Ogni richiesta della Webapp viene soddisfatta istanziando un nuovo Thread e, dopo aver verificato l'autorizzazione tramite token di Keycloak, interagisce con il DB e effettua una chiamata al CAM. Terminate queste due interazioni, viene servita la risposta alla Webapp.
- BeagleBone (BB)
- Mosquitto
- Luci: Microservizio che opera in LAN che si occupa di gestire l'accensione e lo spegnimento delle lampadine sia tramite interruttore che tramite sensori di movimento. Nel caso in cui il sensore crepuscolare di Arduino rileva che e' giorno, il sensore di movimento non viene attivato. I comandi e gli stati delle lampadine vengono letti e scritti su due topic distinti del broker Mosquitto presente sulla BB. La persistenza dello stato del microservizio e' mantenuto in locale su un file testuale in formato JSON, che viene aggiornato ad ogni variazione dello stato, ad esempio accensione o spegnimento di una lampadine, aggiunta di una nuova lampadina e modifica del sensore di movimento.
- Scenari: gestisce la deterrenza delle intrusioni riproponendo uno schema di accensione e spegnimento delle luci quando l'utente attiva l'antifurto. Lo schema segue precisamente lo stato delle luci scelto dall'utente dopo che questo ha attivato la modalita' di apprendimento; una volta disattivata, lo schema e' disponibile poiche' viene immediatamente salvato su un file come sequenza di JSON. La persistenza e' garantita grazie all'uso di tre file che vengono aggiornati in momenti diversi: uno ricorda quale schema e' attivo; il secondo permette il funzionamento dell'automa e memorizza lo stato attuale; mentre il terzo e' usato per salvare gli interruttori e la luce attualmente in uso.
- Antifurto
Questo componente della LAN scrive sul broker Mosquitto della BB i valori del sensore di luminosita', usato dal microservizio delle luci.
## 4.2. Distribuzione delle funzionalita' tra i moduli, attivita' e loro interazione
# 5. Descrizione dell'implementazione
## 5.1. UML delle classi implementate
## 5.2. Descrizione della UI
La pagina principale della Webapp permette l'interazione completa con il sistema. Questo significa che il suo utilizzo permette di avere sia una visione real-time di ciò che accade nella LAN, sia di comandare da remoto gli attuatori connessi.
All'avvio della Webapp, viene fatta una RPC ad ogni microservizio installato nel dominio per mostrare correttamente tutti i dati disponibili all'utente; inoltre viene richiesto al server se l'utente è in realtà l'amministratore del dominio, per mostrare funzionalità aggiuntive.
In alto si trovano fino a 3 bottoni che, una volta premuti, mostrano la pagina corrispondente al loro microservizio.
- Luci
La pagina è formata da una tabella in cui sono mostrati il nome della luce ed il suo stato. La luce può venire accesa/spenta semplicemente cliccando lo switch che ne mostra lo stato.
Al fondo dell'elenco delle luci, è presente un bottone che permette la creazione di una nuova luce. Questo processo richiede all'utente di scegliere il luogo/nome della luce, un pulsante libero e un led libero della BBGPIO. Nel momento in cui la Webapp riceve la conferma di creazione dal microservizio, la luce appena creata viene mostrata a schermo.
- Scenari
La pagina è composta da una tabella e da dei bottoni al fondo di essa. Nella tabella vengono mostrati gli scenari (il nome, la data di creazione e lo stato). I bottoni permettono di attivare la funzione di apprendimento e l'antifurto. Nel caso in cui il visualizzatore sia l'amministratore del dominio, è anche presente un terzo bottone per modificare gli interruttori usati.
In ogni momento è possibile cambiare lo stato attuale in quello di apprendimento, di antifurto o di attesa.
Mentre l'antifurto è spento, tutti gli scenari sono spenti e non è possibile attivarli; viceversa all'attivazione dell'antifurto viene immediatamente attivato uno scenario da parte del microservizio, che può essere cambiato (attivando uno scenario diverso) o disabilitato (spegnendo lo scenario attivo).
- Antifurto
La pagina presenta una barra di attenzione, una campanella e lo stato dell'antifurto; inoltre nel caso in cui si sia amministratore del dominio, è presente un pulsante che permette la configurazione delle porte, l'aggiunta di un sensore di movimento e la modifica della soglia (ovvero del valore oltre il quale far scattare l'allarme).
Dalla Webapp, un utente normale può solamente attivare/disattivare l'antifurto e controllare il valore a cui è arrivato l'antifurto (oltre a sapere se l'allarme è stato attivato).
# 6. Validazione del software
## 6.1. Procedure usate per verificare il corretto funzionamento del sistema