-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathContestodisviluppo.tex
73 lines (53 loc) · 8.22 KB
/
Contestodisviluppo.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}
\chapter{Contesto di sviluppo}
In ambito Edge Computing, un ecosistema IoT necessita di tre componenti principali: un dispositivo che raccolga i dati dall'ambiente circostante tramite sensori, un motore di esecuzione in grado di interpretare tali informazioni e un server Cloud (si veda fig. \ref{ecosistema}). All'interno di quest'ultimo sono presenti le descrizioni dei device di interesse e, inoltre, vengono conservati i dati processati dall'engine.
\begin{figure}[H]
\centering
\includegraphics[width=0.8\linewidth]{pics/edgestructure}
\caption{Ecosistema IoT basato sull'Edge Computing}
\label{ecosistema}
\end{figure}
\section{Measurify}
Measurify è il server Cloud che è stato impiegato per questo progetto: una piattaforma Cloud-based, astratta e measurement-oriented creata dall'Elios Lab dell'Università degli Studi di Genova per gestire oggetti intelligenti negli ecosistemi IoT. Measurify modella tali oggetti come risorse web esponendoli attraverso API che rispettano un'architettura REST (REpresentational State Transfer). In questo modo, l'accesso remoto a dati e risorse avviene attraverso un'interfaccia HTTP(S), indipendente dalla piattaforma, per supportare lo sviluppo di applicazioni che si servono di tali oggetti. Le risorse delle API associate al dispositivo specifico sul quale il motore è in esecuzione sono configurabili da remoto con un'applicazione client (ad esempio una web application) che le modifica per gestire l'engine.
Per poter accedere a Measurify sono necessari username ed password che permettono di ricevere un token di sicurezza. Nel caso in questione si tratta di un JSON Web Token (JWT), che andrà inserito nell'header di tutte le richieste HTTP(S) successive per garantirne l'autorizzazione.
All'interno di Measurify è presente una struttura descrittiva dei dispositivi associati al proprio username (si veda fig. \ref{cloudAPI}). Questa è composta da diversi campi che definiscono l'oggetto in questione:
\begin{itemize}
\item \textbf{Thing}: è l'oggetto generico che è soggetto a misurazioni da parte dei dispositivi (ad esempio una persona, una macchina, una casa, una città, ecc.);
\item \textbf{Feature}: è la grandezza fisica misurata da un dispositivo (ad esempio il battito cardiaco, la temperatura ambientale, ecc.);
\item \textbf{Device}: è un'istanza del dispositivo in uso che ha una descrizione virtuale sul Cloud API ;
\item \textbf{Script}: è un file che contiene informazioni su come l'Edge Engine debba manipolare, memorizzare e trasmettere al cloud gli stream di dati provenienti dai sensori o da altri dispositivi. Può trattarsi di una funzione molto complessa per gli engine più potenti oppure un semplice insieme di parametri (ad esempio la velocità di acquisizione o il numero di dati da inviare assieme) per quelli di fascia inferiore;
\item \textbf{Measurement}: è il valore di una grandezza fisica misurato dal sensore
di un dispositivo per uno specifico oggetto;
\end{itemize}
\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{pics/cloudAPI}
\caption{Struttura del server Cloud Measurify}
\label{cloudAPI}
\end{figure}
\section{Edge Engine}
Edge Engine è composto da una serie di funzioni unite in un motore di esecuzione che viene eseguito su un host perimetrale. Il progetto nasce inizialmente con lo scopo di essere eseguito su piattaforme di fascia bassa. Di conseguenza, la prima versione ne prevede l’utilizzo solo su scheda di sviluppo ESP32-DevKitC V4 con modulo ESP32-WROVER-B su piattaforma Arduino, mantenendo però la possibilità di adattamento del codice a più dispositivi, come sarà mostrato nel capitolo successivo.
Il funzionamento dell'engine si può riassumere in macro-processi: accesso al Cloud, richiesta della propria descrizione virtuale, richiesta degli script da eseguire, lettura dati dai sensori, elaborazione locale dei dati, memorizzazione dei dati e invio degli stessi al Cloud.
L’engine, oltre a username e password necessari per l’accesso al Cloud, deve essere dotato di un identificativo univoco chiamato \textit{id}, inserito all'interno del codice, che gli permetta di identificare ed accedere alla propria rappresentazione virtuale e di specificare la provenienza di tutte le informazioni che andrà a comunicare.
In seguito all'autenticazione, l'engine deve richiedere la propria rappresentazione virtuale, che ne descrive l'identità, i parametri di configurazione e le funzionalità, fornendo dunque gli identificativi degli script da eseguire. Sul Cloud, per ognuno di questi, deve essere stata in precedenza creata una risorsa di tipo \textit{script} che potrà essere ottenuta dall’engine tramite una GET request. Gli script e la descrizione virtuale sono tutti e soli gli elementi di configurazione aggiornabili da remoto. Una volta ottenuti può iniziare la fase operativa.
L’elaborazione locale dei dati raccolti avviene quindi attraverso gli script, una composizione di un set predefinito di operazioni semplici, la cui implementazione viene precaricata nell'engine. Queste possono essere applicate agli stream di dati nell'ordine desiderato per formarne anche di complessi i quali producono in uscita nuovi stream. L'upload di questi dati sul Cloud può avvenire in due possibili modi: in modo continuo, ovvero il dato viene inviato non appena viene letto e/o processato, oppure a lotti, ovvero si può specificare il numero di misure da raggiungere perché queste vengano inviate in blocco dopo essere state memorizzate una ad una.
L'invio dei dati avviene attraverso una POST request sulla rotta delle API dedicata, fornendo nel body della chiamata, oltre al dato, anche diverse informazioni di tracciabilità, come l'identificativo del dispositivo e dello script che lo ha generato.
Durante l’esecuzione potrebbero verificarsi dei malfunzionamenti che, nel caso, devono essere comunicati dettagliatamente al Cloud, in modo da rendere noto se e quando questi si siano effettivamente verificati. Così facendo si dà anche la possibilità di prendere le dovute contromisure per correggere alcuni errori o, semplicemente, interpretare correttamente alcune situazioni inaspettate quali l'assenza prolungata di comunicazioni verso il server da parte del dispositivo, che potrebbe essere dovuta a molteplici problematiche (connessione, autenticazione fallita, server temporaneamente offline, ecc.).
In figura \ref{edgecloud} è possibile vedere una struttura schematica dell'architettura del sistema Edge Engine - Measurify.
\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{pics/edgearch}
\caption{Architettura Edge Engine - Measurify}
\label{edgecloud}
\end{figure}
\section{Evoluzione del progetto}
A partire dal progetto Edge Engine per Arduino, l’intento è quello di realizzare un prodotto multipiattaforma per dispositivi di tipo PC (Windows/ Linux/ MacOS).
La prima versione di Edge Engine nasce per essere utilizzata esclusivamente su dispositivi Arduino, pertanto, nonostante la maggior parte delle classi sia indipendente dalla piattaforma, ne restano due, \texttt{APIRest} e \texttt{Connection}, specifiche per Arduino. La prima si occupa di gestire le richieste HTTP da e verso il Cloud, mentre la seconda di gestire il modulo WiFi. Entrambe, dal momento che i task che eseguono necessitano di librerie esterne specifiche, sono giocoforza legate alla piattaforma sulla quale vengono eseguite (si veda fig. \ref{arduinodep}). Pertanto, il primo passo per rendere il codice multipiattaforma è la creazione di ulteriori classi wrapper \texttt{APIRest\_windows} e \texttt{Connection\_windows}, affinché si generalizzi sempre di più questo aspetto dell'Edge Engine.
\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{pics/arduinodependent}
\caption{Esempio di codice dipendente dalla piattaforma nella classe \texttt{Connection}}
\label{arduinodep}
\end{figure}
Inoltre, tutte le funzioni specifiche di Arduino utilizzate nel progetto devono essere sostituite da funzioni equivalenti al fine di permettere un utilizzo del sistema su dispositivi di tipo PC (ad esempio la funzione \texttt{Serial.print} è sostituita da \texttt{cout}).
Nel prossimo capitolo verrà discusso il porting di Edge Engine per dispositivi PC, mantenendo però anche la possibilità di esecuzione su piattaforme Arduino.