BOZZA INIZIALE DI TESI

Amazon AWS IoT

Analisi e sperimentazione del servizo IoT di Amazon
Daniele De Marchi
Università degli Studi di Udine

Anno Accademico 2019-2020

 Sommario
1 L’Internet delle Cose 2

1.1 Nascita e importanza attuale 2

1.2 Le definizioni di “Internet delle Cose” 3

1.3 Un confronto tra IoT e IT 4

2 Amazon Web Services 7

2.1 Perché AWS 7

2.2 I servizi per l’IoT forniti da AWS 8

2.3 Software per i dispositivi 8

2.3.1 FreeRTOS 8
2.3.2 Kit Device SDK di AWS IoT 9
2.3.3 AWS Greengrass 9
2.4 AWS IoT Core 10

2.4.1 Gateway dei dispositivi 11

2.4.2 Broker dei messaggi 11
2.4.3 Autenticazione e autorizzazione 11
2.4.4 Registro 11
2.4.5 Shadow dei dispositivi 12
2.4.6 Motore delle regole 13
2.5 Servizi complementari 13

2.5.1 SQS-SNS 13
2.5.2 Lambda Functions 13
2.5.3 Timestream 14
3 Presentazione del progetto 15

3.1 On-board diagnostic 15

3.1.1 ELM 327 16

3.2 Raspberry Pi 16

4 Realizzazione del progetto 17

 1

4.1 Architettura generale 18

4.2 AWS IoT SDK 20

4.2.1 Configurazione del dispositivo 20

4.2.2 Device Shadow 20
4.2.3 Funzionamento del dispositivo 20
4.3 AWS IoT Core 21

4.3.1 Creazione e gestione dei dispositivi 22

4.3.2 Sicurezza 22
4.3.3 Formato dei messaggi inviati 23
4.3.4 Regole 24
4.4 Timeseries Database – InfluxDB 25

4.5 Presentazione dei Dati e Interazione coi dispositivi 25

5 Conclusioni 26

6 Bibliografia 27
 2

1 L’Internet delle Cose

I dispositivi elettronici stano diventando sempre più piccoli e presenti nella nostra vita
quotidiana. Dispositivi come smart light, termostati ed elettrodomestici intelligenti sono ormai
sempre pìù attorno a noi, per non parlare, inoltre, di assistenti vocali come Amazon Alexa o Google
Home. Grazie all’avanzamento della tecnologia avvenuto negli ultimi anni, questi oggetti sono in
grado di connettersi e comunicare tra loro tramite la rete Internet. Con le stime sempre più al rialzo
del numero di dispositivi connessi ci stiamo muovendo sempre di più verso un modo di Internet
delle Cose.
In questo capitolo si fornirà una breve introduzione sul mondo dell’IoT, cercando di fornire una
definizione di cosa si intende per “Internet delle Cose”, presentando le sfide principali che
contraddistinguono questo nuovo, ma ormai sempre più presente, mondo. Si approfondiranno, poi,
il protocollo di messaggistica MQTT e i database per serie temporali, che verranno
successivamente sfruttati nella sperimentazione della piattaforma AWS IoT.
1.1 Nascita e importanza attuale
La nascita dell’era dell’IoT viene spesso fatta coincidere con il periodo a cavallo tra gli anni
2008 e 2009, nel quale il numero di dispositivi connessi ad Internet ha raggiunto e superato il
numero di abitanti del nostro pianeta.
La persona che viene spesso citata in letteratura per aver coniato il termine “Internet of Things” è
l’ingegnere inglese Kevin Ashton, che usò tale termine mentre lavorava per la multinazionale
Procter & Gamble (P&G), per descrivere il collegamento di oggetti ad Internet tramite tag RFID.
In realtà, senza nulla togliere al lavoro di K. Ashton e degli altri ricercatori che lavoravano von lui,
il concetto di IoT nasce ben prima. L’espressione IoT fu coniata ed usata per la prima volta da Peter
T. Lewis nel Settembre 1985 in una conferenza del Black Caucus a Washington DC.
Prima di indicarli come IoT, si è spesso parlato degli stessi argomenti o di aspetti strettamente
correlati indicandoli con le espressioni come “Pervasive Computing”, “Ubiquitous Computing” o
anche “Machine-to-Machine (M2M)”.
 3

Quello che è certo è che né Peter T. Lewis né Kevin Ashton potevano immaginare il reale impatto
che l’internet delle cose avrebbe avuto sul mondo attuale: secondo le stime wel sito web
iot-analytics.com, infatti, il numero globale degli oggetti connessi ad oggi è di circa diciassette
miliardi, di cui sette miliardi sono oggetti IoT (in questo numero non sono compresi gli smartphone,
tablets, portatili e telefoni fissi), con stime di crescita fino ad un volume di ventidue miliardi di
oggetti intelligenti per il 2025 (figura 1.1). Le opportunità di mercato sono, di conseguenza,
anch’esse stimate a rialzo: sempre secondo iot-Analytics, ci si aspetta che il mercato IoT cresca del
37%, raggiungendo nel 2025 un valore di spesa di 1.567 miliardi di dollari.
Questi numeri portano inevitabilmente a un forte cambiamento nel modo in cui persone e aziende
potranno interagire con l’ambiente circostante: gestire e monitorare in tempo reale oggetti connessi
a Internet, permette di aprire nuove strade per il processo decisionale automatizzato1, basato sui dati
forniti dai dispositivi.

1
Il processo decisionale automatizzato è quello strumento che consente di prendere decisioni
impiegando mezzi tecnologici (ad esempio, macchinari, algoritmi, software, etc.) con o senza l’intervento di
un soggetto che sia in grado di influenzare o modificare l’esito del processo.
 4

1.2 Le definizioni di “Internet delle Cose”

Al termine “Internet of Things”, nonostante venga ampiamente usato, non è mai stato
assegnato un significato universalmente riconosciuto. Wikipedia definisce l’IoT come “a system of
interrelated computing devices, mechanical and digital machines, objects, animals or people that
are provided with unique identifiers (UIDs) and the ability to transfer data over a network without
requiring human-to-human or human-to-computer interaction.” In questa definizione si mette in
evidenza, quindi, il fatto di avere dispositivi connessi tra loro, con un’identità precisa, in grado di
scambiarsi dati senza l’interazione umana.
Organizzazioni internazionali che si occupano della standardizzazione di processi hanno fornito
ulteriori definizioni di IoT. L' Institute of Electrical and Electronics Engineers (IEEE) è
un'associazione internazionale di scienziati professionisti con l'obiettivo della promozione delle
scienze tecnologiche e ha fornito il seguente significato: “una rete di oggetti, ognuno dotato di
propri sensori, che sono connessi ad Internet”. Questa definizione si concentra, quindi,
principalmente sull’aspetto fisico dell’IoT.
L'Istituto Europeo per gli Standard nelle Telecomunicazioni, in inglese European
Telecommunications Standards Institute, acronimo ETSI, sebbene non menzioni esattamente le
parole “Internet of Things”, ha espresso un concetto simile definendo l’idea di “machine to machine
(M2M) comunication”: “M2M è il concetto di comunicazione tra due o più entità, che non
necessitano di intervento umano. M2M ha lo scopo di automatizzare processi decisionali e di
comunizacione”.
Nel 2010, l’Internet Engineering Task Force (IETF) fornisce la propria visione di IoT: “L’Internet
delle cose è quella rete di oggetti elettronici, software, sensori, attuatori e connettività che permette
a oggetti di scambiare dati con i produttori, operatori e/o altri dispositivi”.
Sebbene le definizioni siano diverse, rappresentano comunque rappresentano facce della stessa
medaglia: oggetti dotati di sensori, in grado di interagire con l’ambiente circostante, mantenendo
una connessione a Internet e comunicando con altri dispositivi e/o persone.
1.3 Un confronto tra IoT e IT
In (D. Hanes 2017) viene fornito un paragone molto efficace per capire quanto il mondo dell’IoT e
l’Internet tradizionale, sebbene a primo impatto sembrino trattare degli stessi argomenti, siano in
realtà due campi molto differenti: “Facendo un paragone con il mondo dell’architettura,
comparare l’Internet delle Cose all’Internet Tradizionale è come comparare la progettazione di un
complesso residenziale alla progettazione di uno stadio”.
 5

Con questa semplice frase, anche una persona estranea al mondo dell’informatica può rendersi
conto che metodi che sono stati adottati nelle reti tradizionali diventano inefficaci se applicati a un
sistema IoT. La differenza principale riguarda i dati: mentre nei sistemi IT tradizionali il focus
principale riguarda l’affidabilità e disponibilità (quella che in inglese viene definita “System
availability”) delle applicazioni, l’IoT invece si concentra principalmente sui dati, come vengono
generati, raccolti, trasportati nella rete, analizzati e di conseguenza sfruttati.

Sono state identificate sei aree di criticità principali che necessitano di nuove soluzioni pensate
appositamente per sistemi IoT:
● Scalabilità: l’enorme numero di oggetti connessi supera di molto il numero di dispositivi in
una rete IT tradizionale. Lo spazio degli indirizzi IPv4 ormai è saturo e quindi si ha la
necessità di usare il protocollo IPv6.
● Sicurezza: nelle reti tradizionali, sebbene soggette comunque ad attacchi, sono stati adottati
molti sistemi di sicurezza soprattutto nei punti nevralgici della rete, come ad esempio
l’utilizzo di firewall. Questi sistemi non sono però adatti a soluzioni IoT, in quanto
quest’ultimi sono fisicamente esposti al mondo esterno e spesso dislocati in zone
geografiche ampie. Quindi, si ha la necessità di garantire la sicurezza in ogni nodo di una
rete di oggetti: è importante avere un forte meccanismo di autenticazione e autorizzazione,
garantire l’integrità e confidenzialità dei dati in transito, rendere i dispositivi resilienti ad
attacchi fisici e garantire la sicurezza nello storage dei dati.
● Vincoli sulla potenza dei dispositivi e capacità della rete: le capacità computazionali dei
dispositivi di raccolta dati sono, solitamente, estremamente limitate. Inoltre, gli oggetti
spesso non dispongono di una connessione affidabile ad Internet, e le connessioni
supportano una bassa velocità di connessione. Si ha dunque, la necessità di nuove tecnologie
per la “connessione dell’ultimo miglio”
● Elevato volume di dati generato: i dispositivi sono in grado di generare una quantità di
dati estremamente alta, spesso esagerata. Le capacità di analisi dei dati vanno distribuite in
tutta la rete IoT, dai dispositivi (effettuando un primo filtraggio e aggregazione dei dati) fino
al cloud.
● Necessità di analisi real time: Nei sistemi IT tradizionali i dati vengono perlopiù elaborati
in batch o comunque con vincoli temporali non stretti. In contrasto, nell’ambito IoT si ha
 6

bisogno di un’analisi dei dati in tempi stretti. Da qui la necessità di spostare le capacità di
analisi dei dati il più possibile vicino alla fonte.
Tutti i fattori elencati hanno contribuito a rendere evidente l’inadeguatezza delle architetture
tradizionali. Nel 2014 il comitato di architettura IoTWorld Forum (guidato da Cisco, IBM, ed altri)
ha pubblicato un modello di riferimento architettonico IoT a sette livelli, al fine di decomporre i
vari problemi in sottobroblemi di dimensione minore e indentificare le varie tecnologie disponibili
per ogni strato.
● Livello 1: i dispositivi fisici. Le "cose" in IoT, ovvero, sensori, attuatori, microcontrollori.
● Livello 2: connettività. Può essere sviluppata in diversi sottolivelli: collegamento
fisico/dati, rete/trasporto, livello di applicazione.

● Livello 3: livello di calcolo edge/fog. Serve a ridurre il volume dei dati mediante filtri,
aggregazioni, pre-elaborazioni.
● Livello 4: archiviazione. È il livello intermedio che separa i dati in tempo reale generati da
eventi ai livelli inferiori dalle elaborazioni offline basate su query nei livelli superiori.
● Livello 5: livello di astrazione, necessario per rendere coerenti i dati eterogenei per i livelli
più alti. Consente anche la virtualizzazione di più archivi di dati.
● Livello 6: applicazioni. Monitoraggio e controllo, analisi dei dati.
● Livello 7: livello umano: ad esempio come vengono utilizzati i dati nei processi aziendali.
7
 8

2 Amazon Web Services

Amazon Web Services (AWS) è la piattaforma cloud più completa e utilizzata del mondo,
offre più di 175 servizi completi da data center a livello globale. Milioni di clienti, incluse le
start-up in più rapida crescita, le più grandi aziende e le agenzie governative leader di settore,
utilizzano AWS per diminuire i costi, diventare più agili e innovarsi in modo più rapido.
2.1 Perché AWS
AWS offre un numero notevolmente maggiore di servizie di funzionalità all’interno dei
servizi stessi rispetto a qualsiasi altro provider cloud, dalle infrastrutture per il calcolo,
l’archiviazione e i database fino alle nuove tecnologie, quali il machine learning, l’intelligenza
artificiale, i data lake, analytics e Internet delle cose.
AWS offre l’infrastruttura cloud globale più vasta. Nessun altro provider di servizi cloud offre la
stessa quantità di regioni, ognuna con più zone di disponibilità connesse con una latenza bassa,
throughput elevato e rete ad alta ridondanza. AWS opera in 77 zone di disponibilità distribuite su 24
regioni geografiche in tutto il mondo, tra cui uan nuova regione aperta a Milano nel 2020.
La società di ricerca Gartner Research posiziona AWS nel quadrante dei leader nel nuovo quadrante
magico 2020 per le soluzioni Cloud Infrastructure & Platform Services, posizionandosi prima in
entrambi i campi di valutazione (abilità di esecuzione e completezza della visione) tra i 7 fornitori
leader elencati nel report (Figura 1.1).
 9

2.2 I servizi per l’IoT forniti da AWS

AWS offre molti servizi orientati all’IoT, che vanno da sistemi operativi dedicati per
constrained devices, a software per l’analisi approfondita dei dati e machine learning, andando a
coprire tutti i vari aspetti descritti nel capitolo precedente.

2.3 Software per i dispositivi

2.3.1 FreeRTOS
FreeRTOS è un sistema operativo in tempo reale, open source, per microcontroller sviluppato
al fine di rende semplice programmare, distribuire, proteggere, collegare e gestire dispositivi edge
di piccole dimensioni e a basso consumo. Distribuito gratuitamente con licenza open source MIT,
FreeRTOS include un kernel e una gamma di librerie di software in espansione utilizzabili in tutti i
settori e le applicazioni. Tra queste, è incluso il collegamento sicuro dei dispositivi di piccole
dimensioni e a basso consumo a servizi AWS Cloud come AWS IoT Core o dispositivi edge più
potenti che eseguono AWS IoT Greengrass.
Dispositivi basati su microcontrollori come l’ESP32 (Figura 1.2) dispongono di memoria e capacità
computazonali limitate e hanno, di conseguenza, bisogno di un sistema operativo leggero ma in
grado, comunque, di garantire funzionalità di connessione a reti locali o cloud.
FreeRTOS mira a risolvere questo problema, aggiungendo inoltre librerie per interagire facilmente
con i servizi AWS.

È possibile connettere i dispositivi FreeRTOS a servizi cloud come

AWS IoT Core, a un dispositivo edge locale o a un dispositivo mobile tramite Bluetooth Low
 10

Energy e aggiornarli in remoto utilizzando la caratteristica di aggiornamento Over The Air (OTA)
disponibile con AWS IoT Device Management, come illustrato in figura 1.3

Figura 2.3 Possibili modi in cui è possibile interfacciare un dispositivo dotato di sistema operativo
FreeRTOS con i servizi Amazon Web Services.

2.3.2 Kit Device SDK di AWS IoT

I Device SDK per AWS IoT consentono di connettere in modo semplice e rapido i dispositivi
hardware o le applicazioni mobili ad AWS IoT Core. Il kit Device SDK di AWS IoT sono librerie
open source che consentono ai dispositivi di connettersi, autenticarsi e scambiare messaggi con
AWS IoT Core tramite i protocolli MQTT, HTTP o WebSockets. Il kit Device SDK di AWS IoT
supporta C, JavaScript e Arduino, e include librerie client, guida per gli sviluppatori ed esempi per
l’utilizzo.
2.3.3 AWS Greengrass
AWS Greengrass è un software che estende le funzionalità del cloud AWS a dispositivi che
operano localmente, permettendo così a tali dispositivi di organizzare e analizzare i dati in maniera
locale e quindi più vicino alla fonte dei dati stessa, consentendo, contemporaneamente, a tali
dispositivi di comunicare tra loro in maniera sicura all’interno della rete locale.
Si tratta, quindi, di un software per dispositivi edge, che permette a dispositivi senza un accesso
diretto ad internet di beneficiare dei servizi del cloud. Grazie a Greengrass sarà possibile eseguire
funzioni Lambda (vedasi sezione 1. ), per effettuare una prima analisi dei dati locale, e
eventualmente si possono effettuare operazioni più complesse di data analytics e machine learning,
in quanto i dispositivi edge sono solitamente dotati di una buona potenza computazionale, tutte
 11

operazioni che in dispositivi a basse prestazioni non sarebbe possibile effettuare, senza però dover
delegare queste funzioni al cloud ma eseguendo tutto localmente.
Greengrass permette, inoltre, di sfruttare tutte le features di IoT Core, come device shadows,
autenticazione e autorizzazione e broker dei messaggi, presentati nella sezione successiva.
2.4 AWS IoT Core
Aws IoT Core costituisce la spina dorsale dei servizi IoT (figura 1.. consente a dispositivi
connessi di interagire in modo semplice e sicuro con applicazioni nel cloud e altri dispositivi. AWS
IoT Core è in grado di supportare miliardi di dispositivi e migliaia di miliardi di messaggi, ed è in
grado di elaborare e instradare tali messaggi agli endpoint di AWS e ad altri dispositivi in modo
sicuro e affidabile.
I dispositivi connessi, come sensori, attuatori, dispositivi integrati, elettrodomestici intelligenti e
dispositivi indossabili, si connettono ad AWS IoT Core tramite protocollo HTTPS, WebSockets o
MQTT protetto. In AWS IoT Core è incluso un gateway dei dispositivi che consente la
comunicazione bidirezionale sicura, a bassa latenza e basso overhead tra i dispositivi connessi, il
tuo cloud e le applicazioni.

2.4.1 Gateway dei dispositivi

Il gateway dei dispositivi funge da punto di accesso per il collegamento dei dispositivi IoT ad
AWS. Il gateway dei dispositivi gestisce tutte le connessioni dei dispositivi attivi e implementa
semantica per più protocolli. Attualmente, il gateway dei dispositivi supporta i protocolli MQTT,
 12

WebSockets e HTTP 1.1. Per i dispositivi che si collegano utilizzando MQTT o WebSockets, il
gateway dei dispositivi manterrà connessioni bidirezionali di lunga durata, consentendo a questi
dispositivi di inviare e ricevere messaggi in qualsiasi momento e a bassa latenza. Il gateway dei
dispositivi è interamente gestito e ridimensiona automaticamente le risorse per supportare fino a un
miliardo di dispositivi senza dover gestire alcuna infrastruttura.
2.4.2 Broker dei messaggi
La comunicazione in AWS IoT viene gestita tramite un message broker, in grado di gestire
milioni di connessioni concorenti. Permette di ricevere e fare da tramite tra i vari protocolli di
comuncazione sopra descritti, in modo che dispositivi diversi, che usano tecnologie diverse,
possono comunicare tra loro. I messaggi prodotti dai dispositivi o dai client (ad esempio un
applicazione web che vuole comunicare coi dispositivi) vengono pubblicati nel broker dei
messaggi, che si occuperà anche di gestire le sottoscrizioni ai vari topic. I messaggi vengono
identificati dai topic, definiti dalle applicazioni. Quando il broker riceve un messaggio da un
dispositivo in un determinato topic, lo ripubblica a tutti i client e devices che hanno effettuato
l’iscrizione a tale topic.
2.4.3 Autenticazione e autorizzazione
AWS IoT Core offre autenticazione reciproca e crittografia in tutti i punti di connessione,
perciò non si verificherà mai alcuno scambio di dati tra dispositivi e AWS IoT Core senza
accertamenti di identità. Per le connessioni MQTT l’autenticazione è pasata su certificati X.509. È
possibile mappare policy per ciascun certificato per autorizzare l'accesso di dispositivi e
applicazioni e revocare l'accesso in qualsiasi momento senza toccare il dispositivo.
2.4.4 Registro
AWS IoT fornisce un registro che semplifica la gestione degli oggetti. Gli oggetti sono
identificati da un nome. Gli oggetti possono anche avere attributi, che sono coppie nome–valore
utili al fine di organizzare il parco di oggetti, che è possibile usare per archiviare le informazioni
sull'oggetto, ad esempio il numero di serie o il produttore.
2.4.5 Shadow dei dispositivi
È possibile creare versioni virtuali e persistenti dei dispositivi, chiamate "shadow" dei
dispositivi (versioni ombra), che includono l'ultimo stato noto del dispositivo, consentendo ad
applicazioni e altri dispositivi di leggerne i messaggi e interagire con esso. La shadow dei
dispositivi conserva l'ultimo stato noto e lo stato futuro impostato per ciascun dispositivo anche
quando è offline.
 13

Il formato della versioni ombra, e un documento JSON, diviso in 3 categorie (figura 1.5)
● Desired: Stato desiderato del dispositivo
● Reported: Stato attuale riportato dal dispositivo
● Delta: Differenza tra stato attuale e stato riportato
Per capire meglio il funzionamento di questa funzionalità facciamo un esempio: consideriamo di
avere a disposizione una smart light e di voler cambiare il colore. Usando la versione ombra del
dispositivo in figura 1.5, è possibile impostare lo stato desiderato della lampadina, ad esempio, al
colore rosso. Il dispositivo, che attualmente sta emettendo luce blu, viene comunicato tramite
protocollo mqtt o html, lo stato desiderato e quindi potrà agire di conseguenza per portarsi in tale
stato. Se il dispositivo non ha accesso ad AWS IoT per problemi di connessione, non potrà rilevare
il cambiamento richiesto e quindi lo stato attuale del dispositivo rimarrà quello con colore blu, e di
conseguenza nella Shadow sarà presente un delta tra le due configurazioni.
Il cambiamento, però, non viene perso. Una volta ristabilita la connessione, il dispositivo riceverà
l’aggioramento desiderato dall’utente, e potrà quindi portarsi nello stato desiderato.
Tramite questa funzionalità viene, dunque, implementato un meccanismo di richiesta/risposta, che
permette di inviare semplici comandi al dispositivo
 14

2.4.6 Motore delle regole

Il motore di regole consente di creare applicazioni IoT che raccolgono, elaborano, analizzano
e operano sui dati generati dai dispositivi connessi in tutto il mondo senza dover gestire alcuna
infrastruttura. Valuta i messaggi in entrata pubblicati in AWS IoT Core, trasformandoli e
distribuendoli verso un altro dispositivo o servizio cloud in base a regole aziendali personalizzate.
Una regola può essere applicata ai dati provenienti da uno o più dispositivi e può eseguire una o più
azioni in parallelo.
Il motore di regole può anche instradare i messaggi verso endpoint AWS quali AWS IoT Analytics,
AWS Lambda, Amazon Kinesis, Amazon S3, Amazon DynamoDB, Amazon Simple Notification
Service (SNS), Amazon Simple Queue Service (SQS).
Le regole vengono create tramite una sintassi simil SQL, che consente di filtrare e trasformare i
messaggi in arrivo, in base al tipo e al valore del dato.
2.5 Servizi complementari
Tra i molti servizi messi a disposizione dagli Amazon Web Services, alcuni possono risultare
utili al fine di realizzare un sistema IoT.
2.5.1 SQS-SNS
Amazon Simple Queue Service (SQS) è uno dei primi servizi introdotti da Amazon nel 2004:
è servizio di accodamento dei messaggi distribuito. SQS offre due tipi di code di messaggi.
Sono disponibili due tipi di code: le code standard e le code First In First Out.
Le code standard offrono elevate prestazioni, ordinamento semplificato e distribuzione di tipo
at-least-once. Le code FIFO di SQS sono invece progettate per garantire che i messaggi vengano
elaborati esattamente una sola volta, nell'ordine in cui sono inviati.
Amazon Simple Notification Service (SNS) è invece un servizio di messaggistica per la
comunicazione system-to-system. Permette la comunicazione tra sistemi attraverso i modelli
pub/sub, publish/subscribe che permettono la messaggistica tra applicazioni disaccoppiate
2.5.2 Lambda Functions
AWS Lambda è una piattaforma di calcolo senza server (serverless) guidata dagli eventi
(event driven). AWS Lambda esegue il codice in un'infrastruttura di calcolo ad alta disponibilità ed
eseguirà tutte le attività di amministrazione delle risorse di calcolo, tra cui la manutenzione del
server e del sistema operativo, il provisioning della capacità e la scalabilità automatica e il
monitoraggio e il logging del codice senza il bisogno che l’utente si proccupi di effettuare queste
operazioni.
 15

Lambda supporta molti linguaggi di programmazione, tra cui java, Python, Javascript e C#.
2.5.3 Timestream
Lanciato ufficialmente a ottobre 2020, Timestream fornisce un servizio di database di serie
temporali, in maniera simile a quanto offre InfluxDB.
È in grado di gestire migliaia di miliardi di eventi al giorno ed è supportato dal software di
creazione e visualizzaione di dashboard Grafana (che verrà successivamente sfruttato nella
realizzazione del progetto).
 16

3 Presentazione del progetto

Inizialmente avevo pensato di sviluppare un’applicazione per la telemetria e diagnostica
remota di un’automobile tramite porta OBD-2 e RaspberryPi, sfruttando i servizi forniti da AWS.
3.1 On-board diagnostic
La diagnostica di bordo (in inglese on-board diagnostic, acronimo di OBD) permette
l’autodiagnosi e la segnalazione degli errori o guasti di un autoveicolo. Introdotta inizialmente nei
primi anni 1980, le prime implementazioni di tali dispositivi permettevano soltanto di accendere
una spia in caso di problemi, senza però fornire ulteriori informazioni riguardo il possibile problema
del veicolo.
Le versioni moderne di diagnostica di bordo permettono, invece, una più accurata analisi dello stato
del veicolo, utilizzando una porta di comunicazione digitale (figura 2.1) per fornire informazioni in
tempo reale. Gli errori e malfunzionamenti dell’auto sono inoltre segnalati tramite codici standard
DTC (“Diagnostic Trouble Codes”) che permettono di identificare rapidamente e risolvere
malfunzionamenti del veicolo.
Il successivo standard OBD-2, introdotto nei primi anni ’90, fu reso obbligatorio per tutti i veicoli
venduti negli Stati Uniti nel 1996 e successivamente nel 2001 in Europa, con l’equivalente standard
EOBD (direttiva europea “European emission stardard Directive 98/69/EC”). Lo scopo principale
per l’introduzione obbligatoria, sia in Europa che nel Nord America fu il controllo
di alcuni sistemi definiti “emission relevant” cioè quelli che, se rotti, possono portare a un aumento
delle emissioni, come catalizzatore, sonda lambda, ecc., mentre gli altri sistemi (es. airbag,
climatizzatore, ecc.) hanno un'autodiagnosi non standard, definita a piacimento da ogni costruttore
automobilistico.
 17

3.1.1 ELM 327

3.2 Raspberry Pi
 18

4 Realizzazione del progetto

Sono stati individuati quattro tipi di dati, divisi in base alla frequenza con i quali verranno letti e
conseguentemente inviati:
● Dati ad alta frequenza di rilevazione: rilevati dal dispositivo ogni secondo. Questi dati
possono essere, ad esempio, velocità del veicolo, giri motore, posizione acceleratore e
pressione del collettore di aspirazione
● Dati a media frequenza di rilevazione: rilevati ogni dieci secondi. In questa categoria sono
state individuate misurazioni come la pressione del carburante, temperatura del collettore
di aspirazione, temperatura liquido motore. In questa categoria di dati ricadono quindi tutte
quelle misurazioni che possono variare velocemente, ma non necessitano della stessa
frequenza di campionamento di misurazioni come i giri motore
● Dati a bassa frequenza di rilevazione: rilevati ogni cinque minuti. Rientrano in questa
categoria il livello del carburante e la tensione rilevata della batteria
● Dati di rilevazione errore: rilevati quando occorre un errore nel veicolo. Si tratta quindi dei
“Diagnosti Trouble Code” (DTC), che vengono generati dalla centralina dell’autovettura in
presenza di un malfunzionamento di quest’ultima.
Essendo lo scopo finale di questo elaborato analizzare e sperimentare i servizi offerti da AWS per
l’IoT, e non quello di sviluppare un dispositivo vero e proprio, e a causa della difficoltà nel testare
la soluzione sopra proposta, (necessità di utilizzare in veicolo a ogni sperimentazione), è stata
proposta la seguente modifica al progetto:
invece di ricavare i dati di funzionamento e diagnostica di un’automobile, è stato deciso di ricavare
dati di funzionamento e diagnostica di un computer.
I seguenti dati verranno rilevati: carico cpu, memoria fisica e virtuale, utilizzo della rete, memoria
disponibile e occupata dei dischi rigidi, quantità di carica rimanente (se presente una batteria nel
sistema) e controllo di processi bloccati.
Con un po’ di fantasia, è possibile immaginare tali dati, come dati di funzionamento di
un’automobile (Tabella 3.1).

Dati alta frequenza
Dati media frequenza
Dati bassa frequenza
Dati alta frequenza
Tabella 3.1
4.1 Architettura generale
È stata quindi progettata e realizzata l’architettura come in Figura 3.1.
Automobile
Km/h, RPM, pressione
collettore di aspirazione
Temperatura collettore
aspirazione, temperatura
liquido motore
livello del carburante,
tensione rilevata della
batteria
Diagnosti Trouble Code
19
Computer
Carico Cpu, memoria fisica e
virtuale, utilizzo della rete
Memoria disponibile e
occupata dei dischi rigidi,
media carico Cpu ultimi 10s
Livello di carica della
batteria
Controllo dei processi
 20

L’alta mobilità di un veicolo rende inefficaci infrastrutture basate su tecnologie come LoRaWan,
ZigBee o altre tecnologie con un limitato raggio d’azione.
Il dispositivo si connetterà direttamente ad AWS, tramite SDK dedicato. Il device, quindi, necessita
di una connessione diretta ad internet, che può essere ottenuta tramite una connessione a rete mobile
(GSM-3G-4G), oppure tramite WiFi connettendosi a un telefono cellulare all’interno
dell’automobile che lavora in modalità “Access Point”.
Un’ulteriore alternativa alla connessione diretta a internet del device è quella illustrata in Figura
3.2, e si basa su Bluetooth Low Energy, ma richiede la creazione di un app mobile, cosa che esula
dallo scopo dell’elaborato.
In contesti applicativi alternativi, si potrebbe pensare ad un dispositivo Edge che funge da tramite
tra i dispositivi e AWS IoT Core, e quindi sfruttare tecnologie come la sopra citata LoRaWan.
Una volta connesso, il dispositivo comunicherà, tramite protocollo MQTT, le misurazioni effettuate
dai vari sensori. I dati, tramite il motore delle regole, verranno selezionati, modificati e inoltrati a
vari servizi AWS che effettueranno differenti operazioni a seconda del contesto.
I dati verranno poi salvati in un database di serie temporali (InfluxDB) e successivamente
visualizzati tramite dei pannelli di controllo creato tramite il software di presentazione dei dati
“Grafana”. Per realizzare un’applicazione end-to-end completamente ospitata su AWS,
l’applicazione Grafana è stata installata in un’istanza Amazon EC2 2.
È stato inoltre creato un semplice Bot Telegram che in automatico manderà dei messaggi di allarme
nel caso si verifichino delle determinate e prestabili condizioni. Tale applicazione si interfaccia ad
AWS tramite il servizio chiamato API Gateway 3, che realizza una semplice API, guidata da una
funzione Lambda, nella quale risiede l’effettivo codice che gestisce il Bot.

4.2 AWS IoT SDK

Per il software del dispositivo è stato usato il linguaggio di programmazione Python, per il
quale esiste l’apposito software development kit fornito da AWS. Tale SDK supporta connessioni

2
Amazon Ealstic Compute Cloud (EC2) permette agli utenti di affittare computer virtuali sui quali
eseguire le loro applicazioni. EC2 permette l'implementazione di applicazione fornendo un servizio web
attraverso il quale un utente può avviare un Amazon Machine Image per creare una macchina virtuale, la
quale chiama un'istanza contenente il software desiderato. Un utente può creare, lanciare, e chiudere istanze
server, pagando i server ad ora, per questo viene definito "elastico".
3
Amazon API Gateway è un servizio AWS per la creazione, la pubblicazione, la gestione, il
monitoraggio e la protezione di API REST, HTTP e WebSocket a qualsiasi livello. Tramite tale servizio si
possono creare API in grado di accedere ad AWS o ad altri servizi Web, nonché ai dati archiviati nel cloud
AWS.
 21

tramite il protocollo WebSocket e MQTT over TLS. Come già detto è stato deciso di utilizzare il
protocollo MQTT.
Sebbene sia possibile connettersi ad AWS IoT anche senza l’utilizzo dell’SDK, ma con, ad
esempio, librerie client generiche come Paho MQTT, l’utilizzo dello strumento fornito da Amazon
semplifica molti aspetti della connessione e funzionamento. Infatti, oltre alle funzioni per la
pubblicazione dei messaggi e sottoscrizione ai topic MQTT, l’SDK fornisce le seguenti features:
● Auto-riconnessione in caso di errore implementata con un simil-backoff esponenziale, nel
quale è possibile impostare tempo base di riconnessione e tempo massimo. Il tempo di attesa
per ritentare la connessione è dato dalla seguente formula
𝑐𝑢𝑟𝑟𝑒𝑛𝑡 𝑛 𝑏𝑎𝑠𝑒 𝑚𝑎𝑥
𝑡 (
= 2 𝑡 , 𝑡 )
● Nel caso di mancanza di connessione i messaggi non vanno persi ma vengono salvati in una
coda. È quindi possibile configurare una velocità con cui i messaggi, una volta ristabilita la
connessione con AWS, vengono rinviati. Tale velocità è detta “Draining Frequency”
● Rilevazione automatica dei cambiamenti della Device Shadow
4.2.1 Configurazione del dispositivo
La configurazione del dispositivo viene salvata in un file JSON. Tale configurazione conterrà
il nome del dispositivo, la locazione dei certificati X.509 per la connessione sicura, e alcuni
parametri di funzionamento, come quali misurazioni effettuare e la frequenza con cui vengono
effettuate.
4.2.2 Device Shadow
Il formato della Device Shadow è illustrato in Figura 3.2. L’utilizzo principale che viene fatto
di questa funzionalità è quella di comunicare al dispositivo quali misurazioni effettuare.
4.2.3 Funzionamento del dispositivo
Il dispositivo, una volta avviato, inizierà ad effettuare le misurazioni e, a seconda della
presenza o assenza di connessione a internet, invierà le misurazioni o le inserirà all’interno della
coda in attesa della rete.
 22

Figura 4.2 Device Shadow del dispositivo, impostando i parametri su Enabled, o Disabled, è possibile
comunicare al dispositivo se effetuare o meno tale misurazione

Le misurazioni effettuate ogni dieci secondi e quelle effettuate ogni cinque minuti vengono inviate
singolarmente, mentre per le misurazioni effettuate ogni secondo vengono inizialmente mantenute
in un array e successivamente inviate ogni n secondi in un singolo messaggio (di base è impostato
30 secondi, quindi verrà inviato un array di 30 misurazioni).
È stata fatta questa scelta perché altrimenti, inviando un messaggio ogni secondo, si avrebbe un
elevatissimo numero di messaggi e AWS calcola il costo di utilizzo anche in base al numero di
messaggi, e conseguenti regole che vengono attivate da ogni messaggio.
Oltre alla pubblicazione dei messaggi, il dispositivo effettua la sottoscrizione ad un topic personale.
Quando viene pubblicato un messaggio qualsiasi in quel topic, il dispositivo risponderà con la
configurazione attuale e alcuni parametri di funzionamento. In questo modo è stato implementato
un semplice meccanismo di richiesta/risposta con il quale è possibile interrogare il dispositivo e, se
tutto funziona correttamente, si otterrà una risposta a conferma del corretto funzionamento del
device.
I dispositivi pubblicano i messaggi in topic dedicati, ogni dispositivo avrà quindi topic di
pubblicazione diversi.
4.3 AWS IoT Core
AWS IoT Core costituisce, come dice il nome, il nucleo dell’architettura proposta. Funge da
gateway per i dispositivi e da broker dei messaggi.
Tramite tale servizio, inoltre, sono stati creati i dispositivi, con relativi certificati di sicurezza e sono
state definite le regole di ricezione dei messaggi. La console di servizio AWS IoT core permette
inoltre di monitorare le connessioni dei dispositivi e il volume di messaggi generato (Figura 3.).
 23

AWS IoT Core pubblica in alcuni topic MQTT, detti topic riservati, messaggi relativi all’utilizzo e
funzionamento del servizio. Ad esempio, ogni volta che un dispositivo si connette o disconnette,
viene pubblicato un messaggio in automatico. Questo tipo di messaggio si è reso utile per rilevare lo
stato di connessione del dispositivo e, inoltre, nel caso il dispositivo non si disconnetta in maniera
corretta, è possibile ottenere il motivo di tale disconnessione non desiderata.
4.3.1 Creazione e gestione dei dispositivi
I dispositivi possono essere creati e gestiti in più modi: tramite interfaccia a linea di comando
AWS CLI, Console di gestione Web oppure tramite uno qualsiasi dei Software Development Kit
forniti da AWS.
Per lo scopo di tale progetto, sono stati creati un numero limitato di dispositivi e quindi la creazione
è stata effettuata “manualmente” tramite Console Web. Nel caso si lavori con un elevato numero di
devices sarà necessario automatizzare la creazione tramite SDK.
Tramite il servizio Device Defender è possibile monitorare in modo continuo i parametri di
sicurezza provenienti dai dispositivi e da AWS IoT Core per rilevare eventuali comportamenti
anomali. Nel caso in cui vengano rilevati comportamenti non corretti, AWS IoT Device Defender
invia un avviso per permette di rilevare l’errore e intervenire tempestivamente. Ad esempio, picchi
nel traffico in uscita potrebbero indicare che un dispositivo sta prendendo parte a un attacco DDoS.
4.3.2 Sicurezza
L’autenticazione dei dispositivi è gestita tramite certificati X.509. Tali certificati sono stati
creati tramite AWS IoT core. È inoltre possibile creare in maniera autonoma tali certificati,
registrando un proprio root CA all’interno del servizio, col quale verranno firmati i certificati per i
singoli dispositivi.
In caso di malfunzionamento di un dispositivo, o sospetto furto della chiave privata, è possibile
revocare il certificato.
L’autorizzazione nei servizi AWS è gestita tramite documenti denominati policy. Tali documenti, in
formato JSON (figura 3.3), definiscono cosa può fare o meno una risorsa nell’ecosistema AWS.
Per garantire un’elevata sicurezza, le policy devono essere create seguendo un principio di minima
autorizzazione necessaria. Al fine di raggiungere questo obbiettivo, ai dispositivi è stato concesso di
connettersi a IoT Core solo tramite il proprio id personale, e può pubblicare messaggi e iscriversi
solo a topic a lui dedicato. In questo modo i dispositivi sono isolati tra loro e non possono effettuare
operazioni per conto di altri devices.
 24

Una volta creata la policy, si dovrà associare a un determinato certificato X.509 e di conseguenza
verrà assegnata al dispositivo.
La protezione dei messaggi in transito è garantita dall’utilizzo di TLS per le connessioni che
utilizzano il protocollo MQTT.

Figura 4.3 Esempio di policy di autorizzazione in Amazon Web Services. La policy è suddivisa in tre campi
principali: “Effect” permette di specificare se l’azione specificata viene permessa o meno. “Action”
specifica l’azione che si sta specificando. In “Resource” andrà scritta la risorsa a cui si vuole dare (o non
dare) il permesso. In questa policy, ad esempio, si permette la connessione a un dispositivo alla piattaforma
IoT, ma solo tramite Id personale, in questo modo il dispositivo non può fingere di essere un altro device.

4.3.3 Formato dei messaggi inviati

I dati vengono strutturati in un documento JSON. Ogni misurazione conterrà uno timestamp,
che verrà generato dal dispositivo. È importante che l’orario della misurazione sia accurato, e per
questo il dispositivo effettua una sincronizzazione del proprio orologio tramite richiesta a un server
NTP (Network Time Protocol) 4.
Nel messaggio è inoltre presente un campo che indica quali misurazioni sono state effettuate e
quindi i dati relativi alle singole misurazioni.

4
Il Network Time Protocol, in sigla NTP, è un protocollo per sincronizzare gli orologi dei computer
all'interno di una rete, con tempi di latenza variabili ed inaffidabili. L'NTP è un protocollo client-server
appartenente al livello applicativo. Utilizza il tempo coordinato universale ed è quindi indipendente dai fusi
orari. Attualmente è in grado di sincronizzare gli orologi dei computer su internet entro un margine di 10
millisecondi e con una accuratezza di almeno 200 microsecondi all'interno di una LAN in condizioni ottimali
(Network Time Protocol s.d.).
 25

4.3.4 Regole
Sono state definite le seguenti regole per l’esecuzione delle azioni:
● Regola per misurazioni a media e bassa frequenza: questa regola rileva la ricezione del
messaggio, seleziona i campi relativi alle misurazioni e fa scattare il funzionamento di una
Lambda Function che si occupa di estrarre i valori delle misurazioni e salvarli direttamente
nel database
● Regola per misurazioni ad alta frequenza: questa regola viene attivata una volta ricevuto il
messaggio contenente l’array di trenta misurazioni rilevate ogni secondo, come definito
precedentemente. Il messaggio ricevuto viene poi inoltrato ad una coda SQS, dalla quale
sarà poi possibile estrarre i dati in un secondo momento per un’analisi o per il semplice
inserimento in un database
● Regola rilevazione processo bloccato: questa regola viene attivata quando il dispositivo
rileva un processo del computer che non risponde. Vengono passati i dati a una funzione
Lambda che invierà un messaggio di avviso tramite il Bot Telegram
● Regola rilevazione batteria quasi esaurita (figura 3.4) : attivata quando il livello della
batteria del dispositivo scende sotto il 20% oppure quando la durata stimata della batteria è
inferiore ai 30 minuti. Anche questa regola attiva una funzione lambda che avvisa l’utente
tramite un messaggio via Telegram
● Regola per la rilevazione di disconnessione/disconnessione: questa regola monitora i
messaggi generati in automatico da AWS IoT Core al momento di connessione o
disconnessione del dispositivo. Tali dati vengono poi salvati in una tabella DynamoDB
(servizio database fornito da AWS). Nel caso di disconnessione anomala, viene salvato il
timestamp e il motivo della disconnessione.
● Regola per implementare il meccanismo di interrogazione dei dispositivi: l’utilizzo di questa
regola serve per implementare il meccanismo di richiesta/risposta precedentemente
descritto, al fine di monitorare il corretto funzionamento del dispositivo.
4.4 Timeseries Database – InfluxDB
Per lo storage dei dati è stato scelto il database di serie temporali InfluxDB. La scelta è
ricaduta su quest’ultimo e non sul servizio offerto da AWS, Timestream, sebbene sia possibile
 26

inserire dati in quest’ultimo direttamente dal motore delle regole senza dover passare per una
funzione Lambda, come invece è necessario fare per InfluxDB.
Il motivo principale è che InfluxDB, secondo la piattaforma DB-Engines, è il database più popolare
nel campo dei DBMS per serie temporali, mentre Timestream è un servizio lanciato solo
recentemente e quindi deficita ancora di supporto e guide esaustive.
Inoltre, in Timestream è possibile inserire una sola misurazione per record inserito. Quindi, ad
esempio, nel caso della misurazione dell’attività della rete, in cui abbiamo un campo kb ricevuti per
secondo e un second campo kb inviati per secondo, sarà necessario inserirli in due serie temporali
separate, sebbene si riferiscano allo stesso dominio applicativo.
InfluxDB offre invece una maggiore flessibilità per quanto riguarda la struttura del record.
4.5 Presentazione dei Dati e Interazione coi dispositivi
L’interazione coi dispositivi avviene in due modi principali: un Bot Telegram e una dashboard
realizzata tramite il software Grafana.
Tramite il Bot Telegram è possibile abilitare o disabilitare la ricezione dei messaggi di allarme, e
scegliere quali misurazioni deve effettuare il dispositivo. È inoltre possibile ottenere le informazioni
attuali sullo stato della connessione del dispositivo.
Come detto in precedenza, tramite il BoT l’utente riceverà anche gli avvisi riguardanti
malfunzionamenti (processo bloccato).
Per la visualizzazione dei dati sono state create delle dashboard, divise per tipo di misurazione.
Le dashboard sono divise in due parti in cui vengono visualizzati i dati ad alta o media frequenza di
misurazione. I dati a media frequenza sono aggiornati in tempo reale ad ogni nuova misurazione.
Per ottenere i dati ad alta frequenza sarà invece necessario andare a leggere la coda SQS in cui essi
risiedono e inserirli in InfluxDb. A tal fine è stato creato un semplice programma in Javascript, che
funziona tramite NodeJs.
 27

5 Conclusioni
Grazie all’utilizzo di una piattaforma collaudata e presente su gran parte del mondo come
AWS è possibile costruire in maniera efficace soluzioni per l’IoT in poco tempo.
Il vantaggio principale di utilizzare una piattaforma di questo tipo è sicuramente quello di non
doversi preoccupare della costruzione dell’infrastruttura fisica. I servizi di AWS, “scalano” in
automatico, senza che l’utente debba specificare alcun parametro, e sarà possibile gestire un numero
virtualmente illimitato di dispositivi e messaggi concorrenti.
Appoggiarsi inoltre a questa piattaforma, non è necessario preoccuparsi della sicurezza di
un’infrastruttura di grosse dimensioni come potrebbe essere quella creata per un’applicazione IoT,
ma ci si può limitare a curare soltanto la sicurezza dei dispositivi.
La difficoltà iniziale per l’utilizzo della piattaforma non è bassa, e per poter sviluppare
un’applicazione efficace bisogna conoscere molti altri servizi forniti dagli Amazon Web Services.
Infatti, nella realizzazione di questo progetto, sono stati utilizzati i seguenti servizi:
● AWS IoT Core
● AWS Lambda
● AWS Simple Queue Service
● API Gateway
● DynamoDB
● AWS Elastic Compute Cloud (EC2)
● AWS CloudWatch (Log di attività dei servizi)
● AWS IAM (gestione delle autorizzazioni e policy)
Una volta però imparati questi servizi, e possibilmente molti altri utili alla realizzazione di sistema
IoT, le possibilità di realizzazione di applicazioni per l’Internet of Things sono pressochè illimitate.
Per esempio in questo elaborato non sono stati approfonditi argomenti come l’intelligenza artificiale
e i big data, campo importante, se non fondamentale, del mondo dell’Internet delle cose.
A questo, viene ora illustrato un possibile utilizzo dei servizi AWS per la creazione di un sistema di
Connected Home, e un ulteriore possibile utilizzo
 28

6 Bibliografia
D. Hanes, G. Salgueiro, P.Grossetete, R. Barton, J. Henry. IoT Fundamentals: Networking
Technologies, Protocols and Use Cases for the Internet of Things. Cisco Press, 2017.
Internet of Things. s.d. https://en.wikipedia.org/wiki/Internet_of_things.
Network Time Protocol. s.d. https://it.wikipedia.org/wiki/Network_Time_Protocol.
R. Minerva, A. Biru, D. Rotondi. Towards a definition of the Internet of Things (IoT). IEEE Internet
Initiative | iot.ieee.org, 2015.
Stolikj, M. Building blocks for the internet of things. Technische Universiteit Eindhoven, 2015.