Tesina Informatica Zeuss, Tesine di Maturità di Informatica

Scarica Tesina Informatica Zeuss e più Tesine di Maturità in PDF di Informatica solo su Docsity!

DA AGGIUNGERE!!! Pagina 1

ITT G. MARCONI

ESAME DI STATO 2017 RAFFAELE CALZÀ - 5BI LUCA MORANDINI - 5AI

Zeus

Materie coinvolte

• Sistemi e reti
• Tecnologie e progettazione
• Informatica DA AGGIUNGERE!!! Pagina 2

Indice

1. INTRODUZIONE ..…….……….……….……….……….……….…………….

2. PROGETTO ZEUS ……….……….……….……….……….………………….

2.1. Com’è nata l’idea ……….……….……….……….……….……….……….………… 2.2. Cos’è il Progetto Zeus ……….……….……….……….……….……….……………. 2.3. Suddivisione del lavoro ..……….……….……….……….……….…………….……

3. TECNOLOGIE ALLA BASE DI ZEUS .…….….……….……….………….…

3.1. Node.js ……….………….………….………….………….………….………….…… 3.2. MongoDB ……….………….………….………….………….………….……………

4. STAZIONE .….…….….…….….…….….…….….…….….…….….………..

4.1. Hardware ……….………….………….………….………….………….…………… 4.2. Energia ……….………….………….………….………….………….………….….. 4.3. Protocollo Zeus ……….………….………….………….………….………………… 4.4. Connessione dati ……….………….………….………….………….…………..…..

5. SERVER BACKEND .….…….….…….….…….….…….….…….….……….

5.1. Protocollo Zeus ……….………….………….………….………….………….…….. 5.2. Coda di lavoro ……….………….………….………….………….………….……… 5.3. Gestione degli errori ……….………….………….………….………….………..…

6. SERVER FRONTEND .….…….….…….….…….….…….….…….….……..

6.1. Funzionalità ……….………….………….………….………….…………………… 6.2. Realizzazione ……….………….………….………….………….………….………. 6.3. Sicurezza del servizio ……….………….………….………….………….………… 6.4. Sistema di notifiche ……….………….………….………….………….…….……..

7. CLIENT .….…….….…….….…….….…….….…….….…….….…….….…

7.1. La struttura ……….………….………….………….………….…….…….……..… 7.2. Web App ……….………….………….………….………….………….……….…… 7.3. App mobile ……….………….………….………….………….………….……….…

8. CONCLUSIONI .….…….….…….….…….….…….….…….….…….….…..

8.1. L’evoluzione del progetto ……….………….………….………….………….……. 8.2. Sitografia ……….………….………….………….………….………….…………… DA AGGIUNGERE!!! Pagina 5

Zeus - 1. Introduzione

1. Introduzione L’agricoltura è un insieme di processi molto complesso con l’obiettivo di produrre alimenti ed è alla base di moltissime economie nazionali in tutto il mondo. Essendo un'attività molto delicata, può essere compromessa da cambiamenti climatici, interventi umani errati e scelte sbagliate. Un fattore particolarmente influente è la quantità di acqua che alimenta le piante: se è insufficiente causa siccità, al contrario se è fornita in dose eccessiva può provocare gravi danni come allagamenti che provocano una drastica riduzione della produzione stagionale e di conseguenza un significativo danno economico per l’agricoltore. Per questo motivo è essenziale avere un controllo accurato e costante sul quantitativo di acqua che fornisce nutrimento ad ogni singola pianta nel corso della stagione produttiva. 2. Progetto Zeus

2.1. Com’è nata l’idea

Al giorno d'oggi sul mercato sono presenti delle centraline elettroniche in grado di aprire e chiudere gli impianti irrigui secondo un timer preimpostato. Questi sistemi, seppure comodi, presentano numerosi svantaggi come la mancanza di una verifica sul flusso di acqua che irriga le piante, che può anche risultare insufficiente all'oscuro del contadino, e la necessità di doversi recare sul posto per modificare le fasce orarie di apertura o per disattivare la programmazione automatica in caso di necessità come ad esempio durante un lungo periodo piovoso. Si tratta quindi di una soluzione parziale che a sua volta comporta altri problemi e disagi per gli agricoltori. Zeus nasce con l'obiettivo di rimediare a tutte queste problematiche garantendo l'affidabilità dell'irrigazione applicando un controllo costante sull'acqua che scorre negli impianti, offrendo la possibilità di gestire in modo centralizzato tutte le campagne da remoto da qualsiasi posto tramite un’app, permettendo la personalizzazione rapida delle fasce orarie di ogni campagna tutto ad un costo inferiore rispetto alle attuali soluzioni. Un secondo fine di Zeus è quello di digitalizzare il mondo dell’agricoltura in quanto per molti anni l’intervento della tecnologia è stato esile e minimo. Questo progetto punta ad innovare il settore agro-alimentare con l’introduzione di strumenti tecnologici per l’ottimizzazione del rendimento produttivo. Pagina 7

Zeus - 2. Progetto Zeus Su richiesta dell’Azienda Agricola di Silvano Bertamini, grande produttrice di alimenti ortofrutticoli nella zona di Arco e Riva, è iniziato lo sviluppo del progetto Zeus. Questa azienda possiede molti appezzamenti e, ovviamente, molti impianti irrigui attualmente gestiti in modo autonomo. Le soluzioni attuali però non soddisfano le loro esigenze in quanto necessitano di una sistema che possa essere controllato in modo centralizzato da remoto ma soprattutto che sia affidabile e sicuro per monitorare e ottimizzare la produzione di diversi tipi di frutta.

2.2. Cos’è il Progetto Zeus

Come già detto, Zeus è un sistema complesso per gestire gli impianti irrigui nelle campagne. Dal punto di vista pratico, nelle campagne vengono installate alcune stazioni appositamente progettate per intervenire sugli impianti e per stabilire una connessione tra l’utente e le proprie campagne attraverso Internet. Gli agricoltori registrati possono scaricare dagli store di iOS e Android l’applicazione ufficiale o, in alternativa, utilizzare la web app che, connettendosi ai server Zeus, consente di operare sugli impianti aggiungendo delle fasce orarie di apertura oppure di monitorare eventuali problemi in tempo reale. Gli agricoltori vengono registrati nel sistema dagli amministratori solamente dopo aver installato almeno una stazione nelle loro campagne, poiché in caso contrario, anche se registrati, non riuscirebbero ad eseguire nessuna azione. Zeus, a differenza di altre soluzioni, garantisce il corretto funzionamento degli impianti e, in caso di anomalie, notifica immediatamente l’agricoltore. Essendo un sistema centralizzato e controllabile da remoto, in caso di piogge è possibile sospendere momentaneamente l’irrigazione senza doversi recare fisicamente ad ogni impianto. Attualmente il progetto è costituito da sette applicazioni distinte che svolgono le loro attività in modo indipendente l’una dall’altra. Per le stazioni sono stati sviluppati due programmi, il client prevedere un’app mobile e una web app, mentre il server è composto da tre processi distinti. Pagina 8

Zeus - 3. Tecnologie alla base di Zeus Nel progetto Zeus il lavoro è stato suddiviso nel seguente modo: Raffaele Calzà ha lavorato sul client sviluppando le due interfacce e l’interazione con il sistema, e sul server frontend creando il web service REST e gestendo la sicurezza del progetto. Luca Morandini ha progettato le stazioni e si è occupato dello sviluppo del server backend realizzando il protocollo di comunicazione tra il server e le stazioni e la gestione della coda di lavoro tra il web service e server backend.

3. Tecnologie alla base di Zeus

3.1. Node.js

Le due applicazioni server sono state sviluppate in Node.js, piattaforma in continua crescita con lo scopo di realizzare applicazioni robuste, scalabili e flessibili. Node.js è infatti disponibile per Windows, Linux e macOS. Il linguaggio di programmazione utilizzato dalla piattaforma è JavaScript ( con alcune funzionalità aggiuntive ) che garantisce una semplicità di sviluppo ed efficienza essendo un linguaggio interpretato. Il runtime di Node.js è costruito sul motore JavaScript V8 utilizzato anche da Google Chrome. Inoltre la sua architettura è basata su un modello I/O non bloccante e ad eventi, che rendono il framework leggero, in termini di richiesta di risorse hardware, e performante, evitando problemi di dead locking fra processi, problema tipico dei modelli multi-thread. Il progetto è open source pubblicato su GitHub ed è sostenuto da una community di sviluppatori che ogni giorno contribuiscono alla sua crescita. L’ecosistema dei pacchetti di Node.js è NPM ( Node Package Manager ) che mette a disposizione migliaia di moduli JavaScript per ogni occorrenza.

3.2. MongoDB

La gestione dei dati del servizio viene svolta attraverso un database NoSQL ( non relazionale ) molto agile e scalabile: il DBMS MongoDB. MongoDB è molto diverso da un database relazionale come MySQL o MS SQL Server in quanto non prevede l’esistenza di tabelle ed associazioni ma è basato sui documenti che sono indipendenti tra loro. Pagina 10

Zeus - 3. Tecnologie alla base di Zeus Ogni documento ha uno schema dinamico ( dynamic schema ) cioè i documenti all’interno di una collezione (che corrisponde ad una relazione) possono avere campi differenti e quindi non è necessario che abbiano la stessa struttura. Queste caratteristiche lo rendono un DBMS molto flessibile alle esigenze che consentono di adattare lo schema alle esigenze del progetto senza particolari sforzi. Inoltre è possibile aggiungere dei sotto-documenti ( embedded documents ) ai documenti memorizzati in una collezione consentendo di adattare la base di dati in modo fedele alla realtà ( rich data model ). MongoDB è molto facile da usare e sicuro in quanto non è vulnerabile ad attacchi tipici di database relazionali come le SQL-injections. Inoltre è estremamente efficiente (prevede la possibilità di creare indici) e facilmente scalabile. I documenti vengono memorizzati su disco in formato BSON ( una variante binaria di JSON ). La base di dati di Zeus è formata da sei collezioni che memorizzano tutte le informazioni necessarie al funzionamento del sistema ed alcuni dati di amministrazione.

Collezione Contenuto

stations La collezione memorizza tutte le stazioni Zeus con il relativo indirizzo IP users Salva gli utenti che si sono iscritti a Zeus farmlands La collezione contiene le campagne di tutte gli utenti con la relativa stazione di appartenenza, un campo che indica lo stato attuale e un valore che determina se la campagna è dotata di sensore di pressione dell’acqua nell’impianto events Contiene tutte le fasce orarie di funzionamento dell’impianto di tutte le campagne con il tipo di evento (semiautomatico o programmato) e lo stato attuale activities Tutte le attività che gli utenti eseguono sulle loro stazioni e le informazioni che le stazioni devono comunicare ai relativi proprietari. Ad ogni attività viene associata il numero di tentativi di invio da parte del server alla stazione. logs La collezione memorizza tutti i messaggi di log e gli errori delle due applicazioni server suddivisi per categorie. La collezione è utilizzata solo per scopi amministrativi in quanto l’utente può vedere solo gli errori riguardanti le proprie stazioni. Pagina 11

Zeus - 3. Tecnologie alla base di Zeus Pagina 13 Stazione e server backend SVILUPPATO DA: LUCA MORANDINI (5AIS)

Zeus - 3. Tecnologie alla base di Zeus Pagina 14

Zeus - 4. Stazione Attraverso il Particle Cloud è possibile scalare rapidamente il numero di dispositivi fino a raggiungere una distribuzione che comprende moltissimi microprocessori che possono essere aggregati in gruppi per la gestione centralizzata. Per questo progetto è stato deciso di utilizzare Electron al posto di una scheda Arduino in quanto offre diversi vantaggi tra cui la dimensione molto ridotta rispetto ad un Arduino Uno, l’integrazione con un modulo GSM senza la necessità di collegare schede esterne ( shield ) e la presenza di innumerevoli librerie sviluppate dalla stessa Particle che consentono di svolgere molte operazioni tra cui la creazione di un socket UDP, la gestione semplificata delle ore e la memorizzazione di dati su un supporto persistente.

Cos’è Electron

Electron è una scheda elettronica dotata di modulo 3G in grado di ricevere e inviare dati attraverso le reti mobili, le stesse usate dai telefoni cellulari. Il modulo cellulare installato sulla scheda è un U-blox SARA-U270 (per la versione europea), il processore è un ARM Cortex M3 a 32 bit molto economico che garantisce performance migliori rispetto ad Arduino Uno che monta un ATmega328P a 8 bit. Electron dispone anche di 1MB di memoria flash sul quale è possibile memorizzare, oltre al firmware, l’applicazione utente ed è dotato di 128KB di RAM. Questa scheda è costituita da 14 pin di input/output digitali e 12 pin analogici. In questo modo ogni stazione Zeus è in grado, con un po' di lavoro a livello software, di operare gestendo fino a 12 impianti distinti indipendentemente.

La base della stazione

Le stazioni Zeus si basano sulla versione di Electron con modulo 3G per due motivi principali: efficienza e copertura del servizio. Essendo un'evoluzione della prima versione, Electron 3G risulta essere più efficiente del suo predecessore, sia per quanto riguarda il microcontrollore che per il modulo cellulare. Essendo in grado di raggiungere una velocità di trasmissione superiore, per inviare la stessa quantità di dati impiega meno tempo rispetto alla versione 2G e di conseguenza l'antenna utilizza meno energia per portare a termine l’operazione. Per quanto riguarda la copertura, Particle sconsiglia fortemente Electron 2G poiché molti operatori telefonici hanno intenzione di dismettere le reti di seconda generazione negli anni 2017-2018. A cura di Luca Morandini Pagina 16 Figura 3. Particle Electron

Zeus - 4. Stazione Sul suolo italiano TIM ha programmato la rimozione della propria rete 2G a partire dal 2020 per sostituirla con reti 3G/4G di nuova generazione molto più veloci e performanti.

La stazione Zeus

Per quanto riguarda la stazione, ad ogni campagna (che corrisponde ad un impianto irriguo) vengono associati un pin digitale per gestire l’apertura dell'elettrovalvola ed uno analogico utilizzato per monitorare la pressione con cui l'acqua circola all’interno dell’impianto. Electron mette a disposizione del firmware in esecuzione 2047 byte di memoria EEPROM non volatile nel quale è possibile salvare dati in modo permanente utilizzabili anche dopo un riavvio del dispositivo. A livello software sono disponibili due funzioni che consentono di salvare e leggere dati da questa memoria. La stazione Zeus utilizza la memoria EEPROM per salvare fin dal primo avvio il proprio identificativo ( SUID ) ed altre informazioni essenziali come l’indirizzo IP di un server Zeus, le informazioni riguardanti le campagne che gestisce quali ID, pin associato, stato corrente e se possiede un sensore di pressione o meno. Inoltre nella memoria vengono memorizzati tutti gli eventi che il server ha inviato alla stazione. L’elenco di eventi memorizzati rispecchia in modo fedele la situazione del database sul server e di conseguenza ogni stazione è in grado di lavorare senza dover contattare ogni volta un server. Quindi anche in caso di malfunzionamento della parte server, le stazioni sarebbero comunque in grado di intervenire sugli impianti senza nessuna limitazione poiché tutti gli eventi che deve gestire sono salvati nella propria EEPROM. Di seguito ( figura 4 ) viene mostrato lo schema generale di una stazione Zeus. A cura di Luca Morandini Pagina 17 Figura 4. Schema della stazione Zeus

Zeus - 4. Stazione Per ottimizzare il risparmio di energia utilizzata dalle stazioni sono state adottate delle soluzioni a livello software. Tutti gli algoritmi per il risparmio di batteria sono basati sulla variazione della quantità di corrente utilizzata da Electron durante lo svolgimento delle varie attività. Come si può notare dall’immagine ( figura 6 ), quando la scheda trasmette dati consuma moltissima energia ( figura 6, immagine a destra ), mentre quando è in stato sleep ( riposo ) e non svolge nessuna operazione consuma pochissimo ( figura 6, immagine a sinistra ). Per questo motivo durante lo sviluppo è stato di estrema importanza ridurre al minimo la quantità di dati trasmessi dalla stazione, non solo per rimanere nel piano mensile fornito dall’operatore, ma anche per mantenere basso il consumo di energia. Il modulo acceso mentre trasmette dati richiede una grande quantità di energia per alimentare l’antenna. Di conseguenza minore è il tempo di trasmissione e meno energia consumerà la stazione. Il modulo consuma una certa quantità di energia anche se non trasmette dati, soltanto rimanendo acceso. Per questo motivo dato che di notte quasi sicuramente l’utente non apporterà modifiche ai propri dati, le stazioni non si collegano al server e restano isolate fino al mattino seguente quando si connetteranno nuovamente per l'intera giornata. Per garantire il servizio anche nelle ore notturne, le stazioni si attivano ogni venti minuti per verificare se è programmata l'apertura di qualche impianto e infine ritornano nello stato sleep per risparmiare batteria. Durante questi controlli periodici notturni il modulo GSM rimane spento in modo da ridurre al minimo il consumo di corrente. Viene riattivato ogni mattina per consentire alla stazione di collegarsi al server. Lo sleep è un particolare stato della scheda elettronica che consente di risparmiare moltissima energia poiché quando è attivo viene spento il modulo cellulare e viene disattivato il microcontrollore. A cura di Luca Morandini Pagina 19 Figura 6. Consumo di energia nelle varie fasi (immagine di Particle)

Zeus - 4. Stazione

Comunicazione

Durante la giornata la stazione può comunicare con un server Zeus ogni 5 minuti in fasce orarie ben definite mentre nel tempo restante sospende le attività e imposta il modulo cellulare in standby per ridurre il consumo di corrente. Dato che gli orari delle comunicazioni sono prestabiliti e fissi, le stazioni devono rimanere sincronizzate con il server per poter comunicare. Per ovviare a questo problema, prima di sospendere il microcontrollore vengono calcolati i secondi di standby elaborando la differenza tra l'ora attuale e il successivo turno di comunicazione che è facilmente derivabile con un semplice calcolo matematico che arrotonda l’ora corrente alla successiva fascia oraria.

4.3. Protocollo Zeus

La comunicazione e lo scambio di messaggi tra le stazioni e il server avviene grazie ad un protocollo ideato appositamente per il sistema basato su UDP.

Il consumo di dati

Essendo UDP un protocollo non connesso e non affidabile, la gestione degli errori e le perdite di pacchetti sono affidati a livello superiore al protocollo Zeus. Questa scelta, nonostante richieda un maggiore lavoro per implementare i vari controlli, è stata effettuata per diversi motivi tra cui l'efficienza del server e la ridotta capacità di dati che una stazione può inviare mensilmente. Per mantenere ridotti i costi annuali di ogni centralina, il contratto con il provider di rete prevede una quantità massima di dati da trasmettere o ricevere pari a 1MB mensile. A causa di questo limite, durante la progettazione del sistema è stato essenziale ridurre al minimo il numero di byte trasmessi per ogni singolo messaggio ed UDP è risultato essere la soluzione migliore. I messaggi del protocollo Zeus inviati dalla stazione o dal server hanno una lunghezza che può variare da 1 a 7 byte in base al fatto che si tratti di una semplice conferma o di invio di dati utili al funzionamento.

UDP vs TCP

UDP aggiunge ad ogni pacchetto un header fisso di 8 byte mentre TCP ha un carico di 20 byte per ogni messaggio. TCP conferma la ricezione di ogni pacchetto con un messaggio contenente solo un header di 20 byte mentre UDP, essendo un protocollo non connesso, non prevede una conferma di corretta ricezione. Nel caso di Zeus, è comunque previsto l’invio di un messaggio di risposta per confermare l’arrivo a destinazione del comando. A cura di Luca Morandini Pagina 20