Vending Machines avanzate basate su principi di Physical ... · ed e previsto che questo fenomeno...

Alma Mater Studiorum · Universita di Bologna

SCUOLA DI SCIENZE

Corso di Laurea in Scienze di Internet

Vending Machines avanzate

basate su principi di Physical Web

e Internet of Things

Relatore:Chiar.mo Prof.Luciano Bononi

Presentata da:Luca Comellini

Sessione IIAnno Accademico 2014/2015

a Giulia

Indice

Indice i

Elenco delle figure v

Listings vii

1 Introduzione 1

2 Internet of Things 5

2.1 Stato dell’arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Microsoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Microsoft Azure IoT . . . . . . . . . . . . . . . . . . . . . 11

2.2.2 Windows 10 IoT . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Ubuntu Core per Internet of Things . . . . . . . . . . . . . . . . . 14

2.3.1 Container . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.2 Architettura di Snappy . . . . . . . . . . . . . . . . . . . . 15

2.4 Intel IoT Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5 Project Brillo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.6 IPv6 e possibilita di indirizzamento univoco . . . . . . . . . . . . 21

2.7 Grande mole di dati . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.8 Adozione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Physical Web 31

3.1 Physical Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Eddystone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.1 Elementi comuni . . . . . . . . . . . . . . . . . . . . . . . 32

i

INDICE

3.2.2 Eddystone-URL . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.3 Eddystone-UID . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.4 Eddystone-TLM . . . . . . . . . . . . . . . . . . . . . . . 35

4 Tecnologie alternative 39

4.1 Beacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.1 iBeacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.2 AltBeacon . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.3 Android Beacon Library . . . . . . . . . . . . . . . . . . . 42

5 Implementazione 45

5.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1.2 Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2 Web Application - Client . . . . . . . . . . . . . . . . . . . . . . . 52

5.2.1 JavaScript, jQuery e jQuery Mobile . . . . . . . . . . . . . 52

5.2.2 WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2.3 Service Workers . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3 Applicazione Android . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.3.1 Proximity Beacon API . . . . . . . . . . . . . . . . . . . . 59

5.3.2 Nearby Messages API . . . . . . . . . . . . . . . . . . . . 65

5.3.3 Geofencing API . . . . . . . . . . . . . . . . . . . . . . . . 69

5.4 Distributore Automatico . . . . . . . . . . . . . . . . . . . . . . . 71

5.4.1 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.4.2 WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.4.3 Broadcast del beacon . . . . . . . . . . . . . . . . . . . . . 74

5.5 Utilizzo delle applicazioni - Casi d’uso . . . . . . . . . . . . . . . 76

5.5.1 Scoperta di un beacon . . . . . . . . . . . . . . . . . . . . 76

5.5.2 Ricezione di una notifica push . . . . . . . . . . . . . . . . 77

5.5.3 Entrata in una Geofence . . . . . . . . . . . . . . . . . . . 78

5.5.4 Apertura dell’applicazione . . . . . . . . . . . . . . . . . . 80

5.5.5 Rifornimento distributore . . . . . . . . . . . . . . . . . . 82

5.6 Sviluppi futuri - Web Application . . . . . . . . . . . . . . . . . . 83

ii

INDICE

5.6.1 Geofencing . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.6.2 Web Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 85

5.6.3 Profilo utente . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.7 Sviluppi futuri applicazione Android . . . . . . . . . . . . . . . . 86

5.7.1 Posizionamento . . . . . . . . . . . . . . . . . . . . . . . . 86

5.7.2 Preferenze . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6 Conclusioni 87

Bibliografia 89

iii

INDICE

iv

Elenco delle figure

2.1 Evoluzione dell’Internet of Things . . . . . . . . . . . . . . . . . . 6

2.2 Windows 10 IoT Family . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Universal Windows Platform . . . . . . . . . . . . . . . . . . . . . 13

2.4 Architettura di Snappy Ubuntu Core . . . . . . . . . . . . . . . . 17

2.5 Intel IoT Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6 Piattaforma Weave di Google per la connessione di oggetti IoT . . 21

2.7 Rapida crescita degli oggetti connessi a Internet . . . . . . . . . . 25

2.8 Value at Stake per l’Europa . . . . . . . . . . . . . . . . . . . . . 27

2.9 Suddivisione del Value at Stake per l’Europa . . . . . . . . . . . . 29

2.10 Economia dell’Internet of Things . . . . . . . . . . . . . . . . . . 29

3.1 Lista dei tipi di frame Eddystone . . . . . . . . . . . . . . . . . . 33

3.2 Eddystone-URL frame . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3 Schema dei prefissi Eddystone-URL . . . . . . . . . . . . . . . . . 35

3.4 Eddystone-URL encoding . . . . . . . . . . . . . . . . . . . . . . 36

4.1 Confronto tra Eddystone, AltBeacon, iBeacon e altri . . . . . . . 40

4.2 Esempio di utilizzo di un iBeacon . . . . . . . . . . . . . . . . . . 41

5.1 Schema del database . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 Struttura della piattaforma beacon di Google . . . . . . . . . . . 60

5.3 Neaby: richiesta di utilizzo Bluetooth . . . . . . . . . . . . . . . . 69

5.4 Scoperta di un beacon . . . . . . . . . . . . . . . . . . . . . . . . 77

5.5 Scoperta di un beacon nell’applicazione Android . . . . . . . . . . 78

5.6 Notifica push Web Application . . . . . . . . . . . . . . . . . . . . 79

v

ELENCO DELLE FIGURE

5.7 Esempio di notifica all’entrata in una Geofence . . . . . . . . . . . 79

5.8 Home per Android e Web Application . . . . . . . . . . . . . . . . 80

5.9 Insieme di immagini dell’applicazione web . . . . . . . . . . . . . 81

5.10 Insieme di immagini dell’applicazione Android . . . . . . . . . . . 83

5.11 Secondo insieme di immagini dell’applicazione web . . . . . . . . . 84

vi

Listings

5.1 Codice PHP di una richiesta al database di tutti i prodotti in un

distributore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 Estratto del codice YAML di gestione del progetto . . . . . . . . . 49

5.3 Estratto del codice Python dello script principale main.app . . . . 51

5.4 Esempio di funzione ajax di jQuery del file JavaScript principale,

adattato per questioni di spazio. . . . . . . . . . . . . . . . . . . . 53

5.5 Estratto del codice JavaScript che si occupa di comunicare con il

distributore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.6 Estratto del codice per la registrazione di un beacon. . . . . . . . 62

5.7 Estratto del codice per la creazione di un attachment di un beacon. 64

5.8 Estratto del codice che effettua la sottoscrizione ai messaggi Neraby 67

5.9 Estratto del codice che effettua la sottoscrizione ai messaggi Neraby 68

5.10 Estratto del codice che crea una Geofence . . . . . . . . . . . . . 70

5.11 Estratto del codice Python del servizio WebSocket nel distributore 72

5.12 Estratto del codice Python del servizio WebSocket nel distributore,

con aggiornamento diretto del server . . . . . . . . . . . . . . . . 73

5.13 Codice di esempio che trasmette il beacon URL . . . . . . . . . . 75

5.14 Codice di esempio che trasmette il beacon UID . . . . . . . . . . . 75

vii

LISTINGS

viii

Capitolo 1

Introduzione

Negli ultimi anni l’interesse verso l’Internet of Things e cresciuto costantemente

ed e previsto che questo fenomeno avra una boom esponenziale nel prossimi anni,

con addirittura 17 mila miliardi di dispositivi connessi previsti per il 2020. Per

Internet of Things si intende un’evoluzione dell’uso di Internet, in cui gli oggetti

si rendono riconoscibili e acquisiscono “intelligenza” grazie alla possibilita di co-

municare informazioni su loro stessi o di accedere a quelle messe a disposizione da

altri. La disponibilita di connessioni a Internet e sempre maggiore e a basso costo

e con i prossimi sviluppi legati principalmente all’IPv6 sara possibile connettere

alla rete praticamente qualsiasi oggetto. Questo sviluppo portera innumerevoli

benefici, di cui si trattera ampiamente all’interno di questo elaborato. Come cia-

scuna innovazione tecnologica, tuttavia, i benefici si accompagneranno a nuove

problematiche:

• Scoperta

Una delle sfide principali e quella di venire a conoscenza degli oggetti smart,

connessi, attorno a noi, che in qualche modo devono pubblicizzare la loro

presenza per essere scoperti e utilizzati.

• Interazione

La molteplicita di oggetti connessi a Internet rendera sempre piu onerosa

l’installazione e l’utilizzo di un’applicazione specifica per ognuno di essi.

Per esempio un’applicazione diversa per ogni produttore di lampadine, ser-

rature, robot per la pulizia dei pavimenti o termostati smart. Inoltre, il

1

1. INTRODUZIONE

download da uno store e l’installazione di un’applicazione, per un singolo

oggetto che si utilizzera probabilmente una sola volta, risulta essere uno

scoglio gravoso per molti utenti, viste anche le dimensioni che le applica-

zioni raggiungono al giorno d’oggi, sia per la quantita di dati richiesti per

il download, sia in termini di memoria occupata una volta installate.

In una prima fase e quindi stato analizzato e implementato un sistema che

permetta a chiunque, in qualsiasi momento, di scoprire e interagire con un og-

getto senza dover intraprendere lunghi processi, sfruttando gli strumenti offerti

dal progetto Physcal Web, che si pone come obbiettivo quello di risolvere le pro-

blematiche appena descritte. Questo progetto, guidato da Google, e open source

e non brandizzato, e viene proposto come standard, nella speranza che venga

adottato dai diversi produttori di software e hardware. Da una parte e presen-

te un trasmettitore Bluetooth, che invia continuamente un beacon, seguendo le

specifiche del protocollo Eddystone-URL, per segnalare la propria presenza al

mondo circostante, continuamente e indipendentemente dalla presenza di un sog-

getto ricevente. Dall’altra parte ci sara, a seconda della piattaforma ricevente, un

browser o uno strumento di ricezione all’interno del sistema operativo. L’intento

finale del progetto Physical Web e quello di creare uno standard, in modo che la

scoperta possa essere integrata come funzionalita all’interno dei diversi sistemi.

Essendo il contenuto trasmesso da questi beacon degli URL, indipendentemen-

te da come e stato implementato, una volta passata la fase di ricezione, verra

utilizzato un qualsiasi browser per aprire la pagina dell’oggetto e interagire con

esso.

In una seconda fase, sono state individuate tecnologie alternative, piu mature,

in modo da essere utilizzate fin da subito senza imprevisti. Infatti, essendo le

tecnologie legate al Physical Web ancora agli albori, le funzionalita al momento

disponibili sono dipendenti dalle implementazioni effettuate dai vari browser e

sistemi operativi, e comunque non ancora complete o alla pari di quelle presenti

in applicazioni native. E stato quindi fatto un confronto con una applicazione

nativa per Android realizzata ad hoc, che sfruttando gli strumenti resi disponibili

dal sistema, individua dei beacon Eddystone-UID, leggendone e interpretandone

i dati ad esso associati. A questi e infatti possibile legare dei dati a piacere,

che verranno resi disponibili all’applicazione. Essendo il dato principale un URL,

2

lo stesso che viene utilizzato per l’Eddystone-URL, questo non va a stravolgere

la struttura del progetto; l’applicazione e inoltre in grado di intercettare anche

le richieste di visualizzazione della pagina effettuate dall’eventuale servizio di

individuazione degli URL, nel caso fosse gia implementato all’interno del sistema,

e di mostrare correttamente la lista dei prodotti ad esso associati.

In questo elaborato si propone un’applicazione pratica delle tecnologie appe-

na descritte alle vending machines, ovvero i distributori automatici di prodotti

(cibi, bevande, biglietti ferroviari, prodotti di qualsiasi genere) posti all’interno

di luoghi pubblici. In particolare, e stata sviluppata una piattaforma che con-

sente agli utenti di individuare la presenza di distributori automatici attraverso

la ricezione di un segnale trasmesso da un beacon Bluetooth. Una volta ricevuto

quest’ultimo, all’interno dell’applicazione web o Android, l’utente puo interagire

con il distributore tramite il proprio dispositivo mobile personale, con il quale

si rapporta quotidianamente, trovando quindi un’interfaccia semplice e familiare.

L’interazione potra essere costituita dalla consultazione dei prodotti disponibili e

delle informazioni associate, l’acquisto degli stessi e la fruizione di offerte speciali.

3

1. INTRODUZIONE

4

Capitolo 2

Internet of Things

2.1 Stato dell’arte

Sempre piu spesso il mondo connesso include oggetti fisici. Macchinari, spedizioni,

infrastrutture e dispositivi sono dotati di reti di sensori e attuatori che consentono

loro di monitorare l’ambiente circostante, comunicare il proprio stato, ricevere

istruzioni, e anche compiere azioni sulla base delle informazioni ricevute. Per

esempio, persino le persone possono essere dotate di dispositivi equipaggiati con

sensori per monitorare il loro stato di salute. Questo e cio che si intende con il

termine “Internet of Things”, abbreviato convenzionalmente in “IoT”. Miliardi

di dispositivi in tutto il mondo sono attualmente connessi a Internet, compresi

computer e smartphone. E stimato che entro la fine del 2015 questo numero

raggiungera i 15 miliardi, con un’ulteriore notevolmente aumento previsto per il

prossimo decennio, con stime che vanno da 50 miliardi di dispositivi fino a mille

miliardi.[12]

Portando macchinari e beni quali container o letti ospedalieri nel mondo con-

nesso, l’Internet of Things consente nuove modalita di monitoraggio e la gestione

di tutte le “parti in movimento” che compongono un business. In qualsiasi mo-

mento, il reparto di gestione puo vedere lo stato e il flusso di beni o materiali

all’interno di una fabbrica, i centri di distribuzione o addirittura sugli scaffali

dei negozi. Monitorando i macchinari in tempo reale, le aziende sono in gra-

do di controllare meglio il flusso di merci all’interno delle fabbriche ed evitare

5

2. INTERNET OF THINGS

interruzioni, prendendo provvedimenti immediati o attuando una manutenzione

preventiva quando sorgono problemi. Oggetti con attuatori integrati in aggiunta

ai sensori possono essere programmati per agire per conto proprio. L’adozione

diffusa dell’Internet of Things richiedera tempo, ma questo lasso sara sempre mi-

nore, grazie al continuo miglioramento delle tecnologie alla base, come i sensori

miniaturizzati e le reti wireless.

Alcuni degli impieghi piu promettenti sono nei settori della sanita, delle in-

frastrutture e della pubblica amministrazione, per aiutare la societa ad affrontare

alcune delle sue sfide piu grandi. Il monitoraggio remoto, per esempio, ha il po-

tenziale per fare una grande differenza nella vita delle persone affette da malattie

croniche e contemporaneamente di ridurre una fonte significativa di costi sanita-

ri. La capacita di monitorare e controllare reti elettriche e idriche potrebbe avere

importanti ripercussioni per il risparmio di energia, le emissioni di gas serra, e le

perdite d’acqua. Utilizzando sensori per raccogliere informazioni e ottimizzare le

operazioni, le funzioni pubbliche come la raccolta dei rifiuti potranno diventare

molto piu efficienti e rapide.

Figura 2.1: Evoluzione dell’Internet of Things

Realizzare il pieno potenziale dell’Internet of Things non e pero facile. Per

sfruttare l’elevato valore potenziale di queste applicazioni, le aziende dovranno

6

disporre di sistemi in grado di dare un senso all’enorme quantita di dati che questi

sensori remoti possono fornire. Ad esempio, con un uso piu diffuso degli RFID1,

alcune aziende potrebbero monitorare centinaia di migliaia, o forse addirittura

milioni, di oggetti in tempo reale, richiedendo notevoli capacita analitiche.

Unire il mondo fisico e digitale, comporta anche importanti implicazioni per

la privacy, la sicurezza e persino sull’organizzazione delle aziende stesse. Come

qualsiasi altra connessione dati, le connessioni che permettono a macchine remote

di agire senza un operatore umano sono soggette all’attacco da parte di hacker

e criminali. I dati raccolti tramite il monitoraggio della salute potrebbero esse-

re oggetto di abusi. Gli oggetti che gestiscono la smart grid di una casa (che

per esempio possono accendere e spegnere selettivamente l’impianto di clima-

tizzazione o gli elettrodomestici, per risparmiare energia o approfittare di costi

dell’elettricita minori) fanno aumentare le preoccupazioni sulla privacy. Questi

problemi dovranno essere affrontati preventivamente prima che la societa e le

imprese siano in grado di godere di tutti i vantaggi dell’IoT.[12]

La definizione “Internet of Things” non ha origini recenti; alcuni professori del

Massachusetts Institute of Technology, infatti, hanno iniziato a parlare quasi una

ventina di anni fa di un mondo dove le cose (oggetti e sensori) erano connesse e in

grado di condividere dati. I dati provenienti da questi dispositivi forniscono infor-

mazioni sul business che prima era impossibile ottenere. Il valore inestimabile dei

dati ricevuti da questi dispositivi connessi e quello che rende l’Internet of Things

cosı importante. Avendo accesso a questi dati le aziende possono ottimizzare i

loro processi di business, individuare nuove opportunita, avere elementi necessari

per prendere una decisione informata, capire e prevedere il comportamento dei

clienti e partner, in modi che prima non erano immaginabili. Attualmente l’In-

ternet of Things e a un punto di svolta. Sebbene gli esperti di tecnologia abbiano

anticipato per anni un mondo con miliardi di dispositivi intelligenti e connessi,

diversi fattori sono confluiti recentemente facendo accelerare l’adozione dell’IoT

in diversi scenari di business.

Fra i fattori che stanno spingendo l’adozione dell’IoT possiamo trovare:

1Radio-Frequency IDentification ovvero identificazione a radio frequenza

7


• Calo del costo dell’hardware:

Il costo dei componenti dell’Internet of Things come microchip, sensori

GPS, di temperatura e accelerometri e crollato grazie al volume delle richie-

ste. Inoltre l’avanzamento tecnologico ha permesso di avere chip sempre piu

piccoli ma al contempo piu potenti e quindi in grado di eseguire software

piu complessi e avanzati.

• Aumento delle macchine che comunicano tra di loro:

Le comunicazioni Machine-to-Machine (M2M), sono in forte aumento ed e

previsto che entro il 2020 il 50% delle aziende ne avra adottato una qualche

forma.[7] M2M significa che un oggetto, ad esempio un macchinario, e in

grado di comunicare autonomamente un’informazione, come l’accadimento

di un evento, a un’altra macchina che e in grado di analizzare questi dati e

dargli un senso.

• Aumento delle connessioni:

In passato le soluzioni IoT erano limitate solo a connessioni cablate o wi-

reless all’interno di una rete locale, ma alimentati dalla capacita che le

reti cellulari avanzate possono fornire, anche gli operatori mobili stanno

iniziando ad adottare l’IoT.

• Le soluzioni cloud offrono costi minori, scalabilita e flessibilita:

Con la crescita di servizi come Microsoft Azure, Amazon Web Service e

Google Compute/App Engine, il cloud storage e la potenza di elaborazio-

ne sono sempre piu accessibili e disponibili, ampliando cosı la capacita di

analizzare grandi quantita di dati. Scenari di Internet of Things che in-

corporano archiviazione nel cloud, analisi e altri strumenti, permettono di

avere ulteriori vantaggi di scalabilita e flessibilita di cui le imprese hanno

bisogno quando viene iniziata o espansa una soluzione IoT.

• I benefici economici potenziali sono in costante aumento:

Secondo il McKinsey Global Institute, l’Internet of Things ha il potenziale

per creare un impatto economico compreso tra i 2.7 e i 6.2 mila milardi di

dollari.[12]

8

L’Internet of Things si riferisce all’uso di sensori, attuatori e tecnologie di co-

municazione dati costruiti all’interno di oggetti fisici, dalle strade alle case fino ai

pacemaker, che danno l’opportunita di tracciare, coordinare o controllare questi

oggetti attraverso una rete dati o Internet. Sono presenti tre step nell’applicazio-

ne dell’Internet of Things: cattura dei dati dall’oggetto (per esempio informazioni

sulla posizione o anche piu complesse), aggregazione delle informazioni attraverso

una connessione e interpretazione di quelle informazioni, sia valutando la neces-

sita di un’azione immediata, sia raccogliendo i dati nel tempo per progettare un

miglioramento del processo. L’Internet of Things puo essere sfruttato per creare

valore aggiuntivo in molteplici modi. In aggiunta all’incremento della produtti-

vita nelle operazioni correnti, puo creare nuovi tipi di prodotti e servizi e nuove

strategie: i sensori remoti per esempio rendono possibili servizi pay-as-you-go

come quelli delle auto a noleggio come Enjoy o Car2Go, che hanno fatto il lo-

ro ingresso nel mercato italiano negli ultimi anni. Le tecnologie dell’Internet of

Things spaziano dal semplice tag identificativo a complessi sensori e attuatori.

I tag RFID possono essere associati potenzialmente a qualsiasi oggetto. Sofisti-

cati dispositivi multisensore che comunicano informazioni riguardo la posizione,

le performance, l’ambiente e le condizioni stanno diventando sempre piu comuni.

Con nuove tecnologie come i Micro Electro-Mechanical Systems1 (MEMS) sta di-

ventando possibile inserire sensori altamente sofisticati in virtualmente qualsiasi

oggetto. In virtu del fatto che questi sono prodotti utilizzando processi simili a

quelli dei semiconduttori, il loro prezzo sta calando rapidamente. Con l’aumento

di disponibilita di tecnologie sempre piu sofisticate, le aziende non solo possono

tenere traccia del flusso dei prodotti o dei beni fisici, ma possono anche gestire le

performance delle singole macchine e sistemi. Questi sensori possono anche es-

sere integrati nelle infrastrutture, per esempio sensori magnetici nelle strade che

permettono di contare il numero dei veicoli che stanno passando, consentendo

aggiustamenti della viabilita in tempo reale modificando il tempo dei semafori.

Altrettanto importante quanto i sensori e gli attuatori, sono i collegamenti dati

che trasmettono queste informazioni e i programmi che li analizzano e danno loro

1Sistemi “intelligenti” che abbinano funzioni elettroniche, di gestione dei fluidi, ottiche, bio-logiche, chimiche e meccaniche in uno spazio ridottissimo, integrando la tecnologia dei sensori,degli attuatori e le piu diverse funzioni di gestione dei processi

9


un senso. Sempre piu spesso le applicazioni dell’Internet of Things includono

impostazioni nelle quali possono essere scatenate azioni automaticamente sulla

base dei dati ricevuti dai sensori. Per esempio una fabbrica puo reagire automa-

ticamente in base al flusso di materiale ricevuto, oppure e possibile far scattare

il verde in un semaforo solo quando il sensore nell’asfalto sente che ci sono delle

vetture in attesa o ancora avvisare un medico quando il battito cardiaco di un

paziente con un dispositivo di monitoraggio, assume valori fuori soglia.[12]

Utilizzi base dell’Internet of Things sono gia ad un buon livello di maturita.

Una delle principali applicazioni gia in uso prevede l’impiego di tag RFID per

tracciare il flusso di materia prima, componenti e beni attraverso i processi di

produzione e distribuzione. Questi tag emettono un segnale radio che puo esse-

re utilizzato per individuare precisamente la loro posizione, quindi per esempio,

mentre un prodotto si muove all’interno di una fabbrica, dei computer possono

tracciare esattamente dove si trova in ogni istante. Utilizzando questa infor-

mazione le aziende possono individuare colli di bottiglia e agire di conseguenza,

gestendo i tempi di introduzione di ulteriori oggetti nel sistema o programmando

l’arrivo dei camion per il ritiro delle merci gia pronte. I tag RFID nei container o

nelle scatole sono utilizzati per tracciare i prodotti durante il loro tragitto all’in-

terno dei magazzini, degli hub di distribuzione e fino agli scaffali e in alcuni casi

fino all’arrivo al cliente. Tracciare questi flussi permette alle aziende di ottimiz-

zare i processi di approvvigionamento ed evitare che le disponibilita siano scarse

o che i magazzini si carichino eccessivamente. I tag RFID sono utilizzati anche

in sistemi di pagamento automatico dei pedaggi come il Telepass, che consentono

di velocizzare il flusso nelle strade a pedaggio. In un altro esempio, FedEx offre

un programma che permette ai consumatori di tracciare il progresso della spe-

dizione quasi costantemente, inserendo un piccolo dispositivo (grande come un

cellulare) all’interno del pacco. Questo dispositivo contiene un GPS e sensori per

monitorare la temperatura, umidita, pressione e esposizione alla luce che possono

essere critici per spedizioni come quelle di campioni biologici o di dispositivi elet-

tronici sensibili. Questi dispositivi sono programmati per inviare la posizione e

le condizioni atmosferiche periodicamente di modo che il cliente possa conoscere

esattamente dove si trova e le sue condizioni e quindi sapere immediatamente

se e andato fuori rotta o e stato esposto a condizioni rischiose. Questo tipo di

10

disponibilita dei dati continua ha forti ed importanti implicazioni soprattutto per

le aziende che operano con lunghe e complesse catene di distribuzione.[12]

Nei paragrafi successivi si analizzano diverse soluzioni attualmente presenti sul

mercato.

2.2 Microsoft

Microsoft e interessata al mercato offerto dall’Internet of Things e ha creato

recentemente delle soluzioni specifiche, alcune gia disponibili come Windows IoT

Core e altre in fase di test come Azure IoT.

2.2.1 Microsoft Azure IoT

Microsoft Azure e la famosa piattaforma di cloud computing creata da Microsoft

che offre soluzioni PaaS 1 e IaaS 2 con diversi servizi a cui e stato aggiunto quello

per l’Internet of Things. In questo modo e possibile monitorare beni per miglio-

rarne l’efficienza, analizzare ed elaborare la mole di dati ricevuta. All’interno

di Microsoft Azure e stata creata quindi una sezione specializzata per l’IoT. E

possibile trovare:

• Event Hub: un centro di raccolta per tutti gli eventi scatenati da sensori

o oggetti, che promette di poter gestire milioni di device quasi in tempo

reale.

• Stream Analytics: permette di creare dashboard e avvisi per analizzare

i dati ricevuti.

• Machine Learning: uno strumento per poter fare analisi e manutenzione

predittiva.

• Notification Hubs: un centro per le notifiche con uno strumento per

gestirle in modo scalabile e veloce.

1Platform as a Service2Infrastructure as a Service

11


E stato inoltre creato un progetto open source chiamato “ConnectTheDots.io”

per facilitare la connessione dei piccoli dispositivi al cloud di Microsoft Azure e

appunto sfruttare questi strumenti. In questo progetto sono presenti esempi di

codice, script di configurazione e guide per aiutare gli sviluppatori a impostare i

device e i sensori e a connetterli con il cloud per poter analizzare le informazioni

ricevute.

2.2.2 Windows 10 IoT

Microsoft ha annunciato Windows 10 IoT, che potra essere installato su diverse

tipologie di dispositivi, spaziando dai piccoli device come i gateway, passando per

dispositivi mobili fino a grossi macchinari aziendali o attrezzature mediche. Win-

dows 10 IoT offre la possibilita di scrivere applicazioni che possono essere eseguite

su qualsiasi piattaforma e meccanismi per garantire connessioni in sicurezza con

i suoi strumenti cloud di Azure IoT. Inoltre supporta nativamente meccanismi di

comunicazione M2M. Nella Figura 2.2 e possibile vedere le differenze e i requisiti

minimi delle varie versioni di Windows 10 IoT e i servizi offerti. Essendo Win-

Figura 2.2: Windows 10 IoT Family1

dows 10 stato annunciato recentemente, delle tre diverse versioni, attualmente e

1Fonte http://www.smashingrobotics.com/microsoft-announces-windows-10-iot-core-public-release/

12

disponibile soltanto Windows 10 IoT Core che era stata rilasciata anticipatamente

come preview per permettere agli sviluppatori di testare la piattaforma.

Windows 10 IoT Core e una nuova versione di Windows mirata a piccoli de-

vice, soprattutto embedded, che non necessariamente possiedono uno schermo.

Per i dispositivi embedded con uno schermo non e comunque possibile utilizzare

Windows Shell, l’interfaccia grafica di Windows, ma e possibile sviluppare una

Universal Windows app, decidendone l’interfaccia e le funzionalita. Una Universal

Windows app e costruita sopra la Universal Windows Platform, una piattafor-

ma comune per qualsiasi dispositivo con Windows 10, che permette di avere il

layer di API principale a disposizione qualunque sia la versione di Windows 10

utilizzata sul dispositivo. Sono disponibili anche API specializzate per quelle che

Windows definisce “famiglie” di dispositivi e una di queste e la IoT family. Ad

esempio un’applicazione che ha come target questa famiglia dispone di un set

di API aggiuntive specifiche e puo assumere che queste siano sempre presenti.

Con Windows 10 non e piu possibile specificare una particolare versione del si-

stema operativo, ma e appunto possibile decidere la famiglia di dispositivi che

si vuole andare a raggiungere.[13] Nella Figura 2.3 e possibile vedere come sono

organizzate le API nella Universal Windows Platform.

Figura 2.3: Universal Windows Platform[13]

IoT Core e disegnato per avere delle basse barriere d’entrata e per la faci-

lita di costruire applicazioni. Su questa piattaforma e possibile utilizzare diversi

linguaggi tra cui: C++, C#, JavaScript, Node.js e Python.

Windows 10 IoT Core e al momento disponibile solo per due piattaforme nativa-

mente: Raspberry Pi 2 e MinnowBoard MAX. Sono presenti pero altri strumenti

come le librerie Windows Remote Arduino e Windows Virtual Shields for Ardui-

no. La prima libreria rende possibile la comunicazione con un Arduino attraverso

13


una connessione USB o Bluetooth. Con la seconda libreria e possibile invece

scrivere uno Sketch Arduino per Arduino UNO e comunicare con una Universal

Window Application eseguibile su qualsiasi dispositivo Windows inclusi i telefoni

Windows Lumia. Per esempio e possibile sfruttare praticamente tutti i sensori

all’interno di un Windows Phone, in entrambe le direzioni. Questo vuol dire che

e possibile sia rilevare dati dall’Arduino per far compiere azioni al telefono, sia

utilizzare i sensori di questo per esempio per scatenare azioni nell’Arduino. Per

poter sviluppare applicazioni per Windows 10 IoT Core e necessario avere un

computer con Windows 10 e Visual Studio 2015.

2.3 Ubuntu Core per Internet of Things

Ubuntu e una distribuzione Linux basata su Debian, sviluppata da Canonical

nel 2004 che ha visto una grande adozione sia in ambito server che desktop, con

numeri in costante aumento.[17]

Nel mese di dicembre 2014, Canonical ha annunciato “Snappy Ubuntu Core”,

una versione minimale di Ubuntu Server con supporto ai container e aggiorna-

menti transazionali. Snappy e un’evoluzione di Ubuntu Server Just Enough Ope-

rating System (JeOS), progettato per funzionare in ambienti virtualizzati. Con

un footprint di soli 380 MB, un kernel specializzato per ambienti server e senza

interfaccia grafica, JeOS era perfetto per l’esecuzione di Linux su macchine vir-

tuali; le dinamiche del mercato server e il loro indirizzamento verso le architetture

a container hanno pero spinto Canonical ad annunciare Snappy come il nuovo si-

stema operativo Linux minimale basato su Ubuntu, per gli oggetti dell’Internet

of Things e per sistemi cloud che li governano.

2.3.1 Container

Le applicazioni con una struttura a container incapsulano il runtime, il framework,

le librerie e il codice, eliminando la dipendenza dal sistema operativo sottostan-

te. Un host che esegue questi container, richiede un sistema operativo minimale

in quanto non interagira mai con gli strumenti esposti da esso, utilizzando solo

l’ambiente di runtime. Questo approccio contrasta con l’attuale modello di di-

14

stribuzione di Linux, dove il sistema operativo viene fornito con molti strumenti

che le applicazioni a container non potrebbero mai utilizzare. Molte distribuzio-

ni si stanno adattando a questo approccio minimalistico, trainate da CoreOS1

una delle prime distribuzioni ad adottare queste soluzioni e anche Red Hat che

ha dato vita a un’iniziativa chiamata “Project Atomic” che ottimizza Red Hat

Enterprise, Fedora e CentOS per l’uso dei container.2

Anche l’architettura dell’Internet of Things richiede un sistema operativo mini-

male per gli oggetti che agiscono come gateway per l’IoT e che solitamente hanno

risorse limitate. Queste distribuzioni di Linux “snellite”, giocano quindi un ruolo

fondamentale nel connettere i vari sensori al cloud e Ubuntu Core ne e un vali-

do esempio. All’interno di Ubuntu Core, le applicazioni e i dati associati, sono

completamente isolate le une dagli altri per evitare problemi di compatibilita e

sicurezza. Sia le applicazioni che il sistema operativo vengono aggiornati in modo

atomico, cioe viene scaricata una nuova “immagine” e tentata l’installazione, ma

se questa operazione non va a buon fine si ritorna automaticamente allo stato

precedente del sistema (rollback). Per gli aggiornamenti del sistema operativo

una volta installati, il sistema tenta un riavvio: se questo va a buon fine la nuova

immagine, viene etichettata come buona e diventa quella di default; se il pro-

cesso fallisce, torna automaticamente all’immagine precedente. Questo sistema e

chiamato “transazionale” o “basato su immagini”. Questo permette di avere un

sistema con interruzioni o downtime ridotti al minimo, ideale per ambienti dove

la prevedibilita e l’affidabilita sono di importanza primaria.

2.3.2 Architettura di Snappy

Snappy e diversa da una tradizionale distribuzione Linux basata sui pacchetti,

come Ubuntu per desktop o server. Ogni parte del sistema e isolata in file di sola

lettura e lo stesso avviene per ogni singola applicazione. Gli sviluppatori possono

quindi aggiornare le loro applicazioni senza preoccuparsi di creare problemi alle

altre installate. Anche se Ubuntu Core e alla base di Snappy, questa non include il

1https://coreos.com/2http://www.projectatomic.io/

15


tradizionale gestore dei pacchetti apt-get presente nelle varie distribuzioni basate

su Debian, ma un tool chiamato snappy.

Snappy e ideato e ottimizzato per eseguire container Docker con il suo mo-

tore e strumenti a linea di comando pre-installati. Qualsiasi applicazione che

puo essere eseguita in Docker puo essere facilmente essere portata su Snap-

py. Quest’ultimo e per sua natura modulare ed espandibile, architettato per

gestire efficientemente le operazioni delle applicazioni e del sistema operativo

sottostante.[19]

Come e possibile vedere in Figura 2.4, sono presenti quattro strati che compon-

gono l’infrastruttura:

• Hardware: la parte fisica del dispositivo, chiamata Enablement, fornita da

un produttore di hardware o da Canonical.

• Sistema: il sistema operativo, Ubuntu Core.

• Framework: servizi di terze parti creati dai venditori in collaborazione

con Canonical per fornire funzionalita specifiche, librerie e fare da media-

zione per le risorse condivise, come sensori e documenti. Al contrario delle

applicazioni, questi hanno dei permessi speciali che permettono loro di inte-

ragire con il sistema. Gli sviluppatori scrivono le applicazioni avendo come

target un determinato framework, ad esempio Docker. I framework sono

indipendenti, non possono dipendere su altri framework e sono mantenuti

autonomamente senza impattare il sistema.

• Applicazioni: le applicazioni che vengono eseguite in Snappy sono chiama-

te Snapps e possono essere eseguite solo all’interno di un framework. Sono

distribuite sotto forma di pacchetti e ognuna ha la sua directory isolata sul

filesystem.[19]

Docker

Docker permette di “impacchettare” un’applicazione con tutte le sue dipendenze

in un’unita standard per lo sviluppo di software. Un container Docker incapsula

il software in un filesystem completo che ha tutto il necessario per essere eseguito:

16

Figura 2.4: Architettura di Snappy Ubuntu Core[19]

codice, runtime, librerie di sistema, strumenti di sistema, qualsiasi cosa sia instal-

labile in un server. Questo garantisce che verra sempre eseguita allo stesso modo,

indipendentemente dall’ambiente in cui si trova. I container condividono il kernel

tra di loro, ma eseguono un processo isolato in userspace nel sistema operativo

ospite. Non essendo legati a una specifica architettura possono essere eseguiti

su qualsiasi computer, infrastruttura o cloud.[2] Docker e diventato velocemente

uno standard de facto per i container e recentemente ha deciso di collaborare

con altre aziende per creare un vero standard per i container software, chiamato

Open Container Project1. In questo sforzo per creare uno standard si sono unite

numerose aziende, tra cui: Amazon, Google, Microsoft, Oracle, VMware, IBM,

Cicso e HP.

Snappy Ubuntu Core e disponibile su varie piattaforme e dispositivi: sono

disponibili immagini per Virtual Machine su piattaforme cloud come Amazon

EC2, Microsoft Azure e Google Compute Engine; tra i dispositivi supportati

invece si trovano per esempio Raspberry Pi 2, Beaglebone Black e Odroid-C1.

Canonical prevede di creare un marketplace dove i fornitori di framework e gli

sviluppatori di applicazioni possono pubblicare i loro prodotti. Un tipico flusso

per lanciare un’applicazione su Snappy include l’avvio di un’istanza di Snappy

1http://www.opencontainers.org/

17


Ubuntu Core, l’installazione di un framework pubblicato sul marketplace e infi-

ne la distribuzione di Snapps. L’azienda ha come obiettivo quello di creare un

marketplace universale con Snapps che possono essere mirate per il deployment

di applicazioni mobili, IoT e cloud.[19]

Linux ha visto una crescita enorme negli ultimi due decenni e grazie agli sforzi

di vendor come Red Hat e Canonical, sta diventando un sistema operativo vali-

do per eseguire e supportare carichi di lavoro aziendali. Linux e al momento il

sistema operativo preferito per il cloud: supportando quest’ultimo e molteplici

device, Canonical ha ideato Snappy per poter fornire un sistema semplice, simile

a quanto si ha oggi per l’installazione di applicazione nel mondo mobile e che ha il

potenziale per diventare uno dei punti principali dell’aumento e sviluppo dell’In-

ternet of Things.[1] E riuscita persino a collaborare con aziende come Microsoft

e Amazon per il rilascio delle loro API mirate all’IoT e di produttori di hardware

come Intel nel progetto Intel IoT Gateway.[20][21]

2.4 Intel IoT Platform

Intel IoT Platform e sia un modello di riferimento end-to-end sia una famiglia di

prodotti di Intel che grazie anche all’integrazione con soluzioni di terze parti for-

nisce strumenti fondamentali per connettere, senza interruzioni e in modo sicuro,

i dispositivi a Internet o al cloud attraverso una connessione sicura e creando

inoltre valore aggiunto attraverso l’analisi dei dati. Intel inoltre sostiene che gra-

zie al suo developer kit e possibile portare innovazione sul mercato in modo piu

veloce, grazie a un processo semplificato e all’aiuto di maggiori componenti per

soddisfare il vasto spettro di casi d’uso dell’IoT. I punti centrali della piattaforma

sono:

• Sicurezza: e possibile avere dati affidabili grazie a una forte integrazione

tra sicurezza hardware e software che inizia dove i dati sono piu resistenti

agli attacchi.

• Interoperabilita: e possibile utilizzare tecnologie che comunicano tra loro

senza interruzioni e aiutano ad accelerare i tempi di entrata sul mercato e

a ridurre i costi di deployment e di mantenimento delle soluzioni IoT.

18

• Scalabilita: possibilita di ottenere una computazione scalabile dal piccolo

device fino al cloud, grazie a processori che vanno da Intel Quark1 fino a

Intel Xeon e dispositivi basati su processori Intel, gateway e datacenter.

• Gestibilita: possibilita di ottenere una gestione dei dati avanzata dai

sensori fino ai datacenter.

Uno dei punti centrai di questa architettura e appunto l’IoT Gateway. Questo

permette di connettere dispositivi datati e infrastrutture next-generation all’IoT,

integrando tecnologie e protocolli di rete, controllori embedded, sicurezza e gesti-

bilita sui quali possono essere eseguite applicazioni di terze parti. Rappresenta

quindi e un componente critico all’interno di questo framework ed e il risultato

della collaborazione tra diverse aziende per permettere il trasferimento di dati

in modo continuativo e senza interruzioni dagli oggetti al cloud, che vede come

elementi fondamentali l’utilizzo di dispositivi e software pre-approvato. Intel IoT

Gateways inoltre permette agli sviluppatori di creare e distribuire in modo flessi-

bile, sicuro ed economico soluzioni IoT per una vasta gamma di segmenti business.

Intel IoT Gateways offre una scelta di processori Intel per le diverse esigente ap-

plicative, il supporto per diversi sistemi operativi come Ubuntu Linux e Microsoft

Windows 10 e una gestione robusta delle funzionalita dei dispositivi.[9]

Figura 2.5: Intel IoT Platform[9]

1Intel Quark e una linea di System on Chip (SoC) a 32-bit di Intel, ideata per dispositivi dipiccole dimensioni e dal basso consumo energetico, utilizzata in nuovi settori di mercato comeper esempio nei dispositivi indossabili.

19


2.5 Project Brillo

Google ha creato un nuovo progetto con il nome in codice di “Brillo”1. Annun-

ciato al Google I/O 2015, l’evento annuale tenuta da Google per presentare nuovi

prodotti o tecnologie, sara disponibile come anteprima per gli sviluppatori alla

fine del 2015, si pone come obiettivo quello di governare gli oggetti dell’Internet

of Things all’interno della casa. Brillo sara un sistema operativo minimale deri-

vato da Android, in modo da potersi adattare alla risorse limitate degli oggetti

dell’IoT, ma comunque garantendo la compatibilita con un vasta gamma di piat-

taforme hardware e facendo leva sui numerosi hardware supportati da Android.

Google inoltre afferma che in questo modo gli sviluppatori si potranno concen-

trare solo sullo scrivere applicazioni per Brillo o a costruire nuovo hardware, dato

che il resto e gia stato implementato. Per garantire la compatibilita e interopera-

bilita tra i vari componenti, i produttori di hardware dovranno passare attraverso

un programma di certificazione. Oltre a Brillo e stato presentato anche un lin-

guaggio per far comunicare i dispositivi tra di loro, chiamato Weave. Questo e

indipendente da Brillo, probabilmente per spingerne l’adozione come standard.

I dispositivi Android saranno in grado di rilevare automaticamente e interagire

con i device Brillo grazie a Weave e all’integrazione all’interno del Google Play

services2 e il supporto sara facilmente disponibile anche in iOS. Con questo pro-

tocollo sara possibile dialogare sia con i dispositivi direttamente o attraverso il

cloud come possibile vedere in Figura 2.6. Ovviamente Weave sara compatibile

con Nest3 di Google, che comprende il termostato “intelligente”, il rilevatore di

fumo e un sistema di video sorveglianza. Questo supporto e allargato anche a

tutti i dispositivi dell’ecosistema Nest, denominata Works with Nest4, ovvero che

possono interagire con il termostato al momento punto centrale della piattaforma.

In passato Google aveva gia provato a proporre una soluzione per la domotica

con “Android@Home”, che non prevedeva l’utilizzo dell’Internet of Things, ma il

progetto non e andato a buon fine.

1https://developers.google.com/brillo/2Google Play Services e un servizio proprietario installato nei dispositivi Android che

fornisce accesso a API per accesso ai servizi offerti da Google, come la localizzazione.3https://nest.com/4https://nest.com/works-with-nest/

20

Figura 2.6: Piattaforma Weave di Google1

2.6 IPv6 e possibilita di indirizzamento univoco

Internet Protocol version 6 (IPv6) e la versione dell’Internet Protocol designata

come successore dell’IPv4, la versione attualmente in uso. Uno dei motivi prin-

cipali sottostante l’adozione di questa nuova versione e l’insufficienza di spazio

per l’indirizzamento di dispositivi in rete che si ha con la versione 4. Quindi la

caratteristica piu importante e quella di un piu ampio spazio di indirizzamento a

disposizione:

• IPv6 riserva 128 bit per gli indirizzi IP e gestisce 2128 (circa 3, 4 × 1038)

indirizzi;

• IPv4 riserva 32 bit per l’indirizzamento e gestisce 232 (circa 4, 3 × 109)

indirizzi.

In altri termini, con l’IPv4 sono disponibili solamente 4.294.967.296 indirizzi,

mentre con l’IPv6 questo numero aumenta in maniera considerevole arrivando

a 340.282.366.920.938.463.463.374.607.431.768.211.456 indirizzi che si traducono

1http://www.theverge.com/2015/5/28/8683147/google-brillo-weave-internet-of-things-solution

21


in 655.570.793.348.866.943.898.599 indirizzi IPv6 unici per ogni metro quadrato

di superficie terrestre, mentre per l’IPv4 sono solamente 7 per ogni chilometro

quadrato. Questi numeri enormi fanno capire che sara possibile avere un indirizzo

IP univoco per ogni singolo oggetto o addirittura ogni singolo componente ed

essere in grado di raggiungerlo in qualsiasi momento da qualsiasi luogo. Proprio

per questo motivo rappresenta uno dei punti centrali dell’Internet of Things.

2.7 Grande mole di dati

L’Internet of Things genera un grande volume di dati e al momento solo una

piccola parte di questi raggiunge i data center. Sebbene il traffico dei data center

e previsto raggiungera 8.6 ZB1 nel 2018, la quantita di dati generata dall’IoT nel

2018 sara piu di 400 ZB o in altre parole circa 50 volte la somma del traffico dei

data center. Ad esempio:

• Un Boeing 787 genera 40 terabyte (TB) di dati per ogni ora di volo, di cui

solo 0.5 TB di questi sono trasmessi a un data center per essere analizzati

o conservati.

• Un grande negozio raccoglie approssimativamente 10 GB di dati ogni ora e

soltanto 1 GB di questi viene tramesso a un data center.

• Un impianto di produzione automatizzato genera circa 1 TB di dati ogni

ora e solo 5 GB sono trasmessi a un data center.

• Una operazione di estrazione mineraria di una grossa azienda puo generare

fino a 2.4 TB di dati al minuto

Con il migliorare della capacita dei data center molti piu dati generati localmente

dai dispositivi potra essere inviata a quest’ultimi. Globalmente la quantita di dati

creata dall’IoT passera dai circa 110 ZB all’anno registrati nel 2013 a circa 400

ZB nel 2018. Inoltre questa quantita di dati sara 277 volte superiore a quella

trasmessa dai device degli utenti e 47 volte superiore al traffico inviato ai data

center, previsto per il 2018.[5] Quindi una delle sfide piu importanti sara quella

1Zettabyte. 1 ZB equivale a 1 miliardo di terabyte

22

di interpretare questa grande mole di dati e di “dare un senso” a tutte le letture

dei vari sensori.

2.8 Adozione

L’Internet of Things e ancora nelle prime fasi di adozione, ma ha gia una vasta

varieta d’usi in costante espansione. Con i proliferare delle tecnologie applicate

all’Internet of Things aumenta il potenziale per soddisfare alcuni dei piu gros-

si bisogni, tra cui il miglioramento della produttivita delle risorse e la gestione

delle infrastrutture. Smard grid per l’elettricita, l’acqua e la rete dei trasporti

ne sono un esempio. Le aziende elettriche e idriche sono state tra le prime a

sfruttare queste tecnologie. I sensori sono essenziali per i sistemi basati su smart

grid perche danno agli operatori una modalita per monitorare l’utilizzo e lo stato

della rete in tempo reale. Questo significa che anziche attendere una chiamata

del cliente che si ritrova senza luce, la compagnia elettrica puo individuare mal-

funzionamenti mentre stanno accadendo e in certe circostanze persino ripristinare

il servizio reindirizzando la corrente per evitare il componente danneggiato. Una

compagnia di servizi americana ha installato una sistema di smart grid e una

rete elettrica aggiornata, che permette di offrire agli utenti un servizio senza in-

terruzioni. Questi sensori, connessi a Internet, vengono anche utilizzati per fare

rilevazioni sismiche sotterranee e monitorare il flusso d’acqua all’interno dei tubi

di fornitura. Nell’industria energetica i sensori sono utilizzati per mappare aree

ricche di combustibili fossili inesplorate e per individuarne l’esatta posizione.

Le tecnologie dell’Internet of Things posso anche avere un impatto diretto nel-

le vite umane e nella salute. Il concetto chiamato “Quantified Self”, che involve

l’uso di sensori per tracciare le prestazioni degli esercizi o monitorare la salute,

e un trend sempre piu popolare alimentato dalle tecnologie IoT. Per esempio di-

verse aziende commercializzano wearable device, sensori indossabili che permetto

all’utente di tracciare il numero di chilometri che ha corso, il battito cardiaco e

altri dati generati durante un esercizio fisico, che possono poi essere utilizzati per

controllare la salute. I medici eseguono “endoscopie capsulari” utilizzando delle

micro-camere a forma di pillola, con sensori wireless capaci di comunicare dati

23


mentre viaggiano all’interno del sistema digestivo di un paziente, trasmettendo

le immagini a un computer.

Numerosi avanzamenti tecnologici stanno migliorando l’efficacia delle applica-

zioni dell’Internet of Things e contemporaneamente riducendo i costi. Il prezzo

dei tag RFID e dei sensori sta precipitando e nuovi sviluppi come i MEMS stanno

consentendo nuovi usi. La vendita dei sensori e cresciuta annualmente del 70%

dal 2010 e gli avanzamenti tecnologici stanno rendendo piu accessibili sensori piu

sofisticati. Sempre piu tipologie di sensori vengono integrati nei dispositivi e una

migliorata gestione dell’energia permette a questi device di eseguire operazioni

per periodi piu lunghi senza la necessita di interventi. Le tecniche di miniatu-

rizzazione e i grossi volume di produzione rendono possibile installare i sensori

persino nei device piu piccoli. Per esempio uno smartphone puo avere un singolo

chip che include un sensore di posizione, un termometro e un rilevatore di movi-

mento. Inoltre la diffusione di connessioni wireless ad alta velocita sta ampliando

l’area coperta dall’Internet mobile, aiutando ad aprire la strada a maggiori usi

dell’Internet of Things.[12]

L’azienda americana Cisco, nel 2013, stimava che il 99.4% degli oggetti fisici

sono ancora scollegati. Questo significa che solo circa 10 miliardi dei 1500 miliardi

di oggetti a livello globale, sono collegati. A un livello piu individuale, ci sono

ad oggi circa 200 oggetti collegabili per persona. Questi dati mettono in luce il

vasto potenziale del collegamento tra tutti gli oggetti non ancora collegati.

Ad ogni modo, la crescita di Internet e senza precedenti. E stato stimato

che nell’anno 2000 ci fossero circa 200 milioni di dispositivi connessi ad Internet.

Spinti dai progressi della tecnologia mobile e da tendenze come “bring your own

device”1 (BYOD), tra le altre cose, questo numero e aumentato fino ad arriva-

re ai circa 10 miliardi di oggi, facendoci entrare nell’era dell’Internet of Things.

La prossima ondata di crescita significativa di Internet avverra grazie alla con-

fluenza di persone, processi, dati e cose, quella che Cisco chiama Internet of

Everything.[10] In Figura 2.7 e possibile vedere questo trend di crescita che por-

tera ai 50 miliardi di dispositivi connessi nel 2020. Sono presenti quattro fasi: la

1“Porta il tuo dispositivo” e un’espressione utilizzata per riferirsi alle politiche aziendali chepermettono di portare i propri dispositivi personali nel posto di lavoro, e utilizzarli per averegli accessi privilegiati alle informazioni aziendali e alle loro applicazioni

24

Figura 2.7: Rapida crescita degli oggetti connessi a Internet1

prima che inizia nel 1995, “Fixed computing” dove e l’utente ad andare al dispo-

sitivo; la seconda nel 2000, “Mobility” dove il dispositivo si muove con l’utente;

la terza nel 2013, “Internet of Things” l’era dei dispositivi; l’ultima nel 2020,

“Internet of Everything” dove qualsiasi cosa e connessa, persone, cose, processi e

dati.

L’IoT e spinto ulteriormente da molti altri fattori. In primo luogo dai trend

tecnologici, incluso il sostanziale aumento della potenza di elaborazione, della

capacita di storage e della larghezza di banda a prezzi sempre minori; la rapi-

da crescita del cloud, dei social media, e del mobile computing; la capacita di

analizzare Big Data2 e trasformali in informazioni utili; infine una migliore capa-

cita di combinare tecnologie (sia hardware che software) in modi piu significativi,

permettendo di ricavare maggior valore dalla loro connessione.

In secondo luogo, le barriere alla connettivita continuano a diminuire. Per

esempio, come affrontato nella Sezione 2.6, l’IPv6 supera i limiti dell’IPv4 per-

mettendo di connettere un numero altissimo di dispositivi, persone, processi dati

e cose a Internet. Per l’IPv4 il numero di indirizzi era limitato a 4.294.967.296.

Incredibilmente, l’IPv6 permette di crearne abbastanza per fornire 4.800 miliardi

1Fonte: Cisco IBSG, 2013 [10]2Big data e il termine utilizzato per descrivere una raccolta di dati cosı estesa in termini di

volume, velocita e varieta da richiedere tecnologie e metodi analitici specifici per l’estrazione divalore.

25


di indirizzi per ogni stella conosciuta nell’universo.

Inoltre, i form factor continuano a ridursi. Ad oggi un computer della gran-

dezza di un granello di sale (1x1x1 mm) comprende una cella solare, una batteria

dello spessore di una pellicola, la memoria, un sensore di pressione e un’antenna

wireless e radio. Una telecamera del medesimo spessore ha una risoluzione di

250x250 pixel. Un sensore delle dimensioni di un granello di polvere (0.05x0.005

mm) puo rilevare e comunicare la temperatura, pressione e movimento. Questi

sviluppi sono importanti perche in futuro gli oggetti connessi ad Internet potranno

essere talmente piccoli da essere persino difficili da vedere ad occhio nudo.

Infine, l’Internet of Everything riflette che il valore delle creazioni si e sposta-

to verso la potenza dei collegamenti e piu nello specifico verso l’abilita di creare

informazioni per quelle connessioni. Le aziende non possono piu fare affidamento

esclusivamente sulle competenze chiave interne e sulla conoscenza dei loro dipen-

denti. Hanno bisogno anche di catturare velocemente informazioni da svariate

sorgenti esterne. Questo avverra tramite le connessioni rese possibili dall’Internet

of Thing (Everything).[10]

Il Value at Stake, secondo Cisco, e il valore dei potenziali profitti (maggiori

entrate e minori costi), che puo essere creato per le aziende che saranno capaci di

sfruttare l’IoT. Cisco prevede che il Value at Stake dell’Internet of Things sara

di 14.4 mila miliardi di dollari per le aziende e le industrie di tutto il mondo, nel

prossimo decennio. Nello specifico, nei prossimi dieci anni, questo rappresenta

una opportunita per incrementare i profitti globali delle aziende di circa il 21%.

In altre parole, da oggi al 2022, un valore di 14.4 mila miliardi di dollari

generato dall’IoT, sara disponibile per le imprese a livello globale. L’IoT creera

sia nuovo valore, sia ridistribuira valore tra early adopter e i ritardatari, in base

a quanto sapranno sfruttare le opportunita presentate dall’Internet of Things.

A livello globale, l’analisi di Cisco dimostra che la maggior parte del potenziale

Value at Stake (66%, o 9.5 mila miliardi di dollari) si ha dalla trasformazione

basata su casi d’uso specifici per le industrie, come smart grid, smart factories,

smart building1. Il restante 34% e prodotto dai tre casi d’uso cross-industry,

come la riduzione del time to market2 o l’outsourcing dei processi aziendali. In

1reti, fabbriche e edifici intelligenti2il tempo che intercorre dall’ideazione di un prodotto alla sua effettiva commercializzazione

26

Figura 2.8: Il Value at Stake dell’Europa corrisponde al 30% del totale1

Europa 2.6 mila miliardi del potenziale Value at Stake verranno dai casi d’uso

specifici, mentre 1.7 mila miliardi saranno dati dai casi d’uso cross-industry.

Cisco ha calcolato il Value at Stake adottando un approccio bottom-up con-

siderando il valore creato da piu di 50 casi d’uso solo nel settore privato, sia

specifici che cross-industry, e li ha accorpati in 21 esempi significativi sia dal

punto di vista del materiale che del valore. E stata inoltre eseguita un’analisi

top-down per verificare la completezza e l’ordine di grandezza del piu specifico

approccio bottom-up. Infine e stato controllato che i valori dei casi d’uso fossero

unici.[10]

La quota Europa del Value at Stake e di 4.3 mila milardi di dollari nei prossimi

10 anni. Questo rappresenta il 30% dei 14.4 mila miliardi di dollari a livello

globale. Nella Figura 2.8 e inoltre possibile vedere l’impatto benefico per regione,

ottenuto dividendo il Value at Stake per la grandezza dell’output economico di

ogni regione.

Le aziende europee che sfrutteranno al meglio l’IoT raccoglieranno i frutti del

valore in uno dei due seguenti modi:

• Catturando il nuovo valore creato dall’innovazione tecnologica

1Fonte: Cisco IBSG, 2013 [10]

27


• Ottenendo un vantaggio competitivo e guadagnando quote di mercato a

discapito di altre aziende che sono state meno capaci di capitalizzare nella

transizione di mercato dell’IoT.

A livello mondiale ci sono cinque principali fattori trainanti del Value at Stake.

Questi sono illustrati nella Figura 2.9 e sono gli stessi anche in Europa:

• Utilizzo delle risorse (1.85 mila miliardi di dollari)

L’IoT riduce le spese generali, di vendita e amministrative e i costi dei beni

venduti migliorando l’esecuzione dei processi di business e l’efficienza del

capitale.

• Produttivita dei dipendenti (1.06 mila miliardi di dollari)

L’Internet of Things crea una maggiore efficienza sul lavoro che risulta in

minori ore di lavoro rendendole piu produttive.

• Innovazione, inclusa la riduzione del time to market (766 miliardi

di dollari)

L’IoT aumenta il ritorno sugli investimenti in Ricerca e Sviluppo, riduce i

tempi del time to market e crea ulteriori flussi di entrate grazie ai nuovi

business model e opportunita.

• Catene di distribuzione e logistica (440 miliardi di dollari)

L’Internet of Things elimina gli sprechi e migliora l’efficienza dei processi

• Esperienza utente (206 miliardi di dollari)

L’IoT aumenta il valore della durata dei cliente e incrementa la quota di

mercato aggiungendone altri.

Come mostrato in Figura 2.10, l’Internet of Things include tre tipi di connes-

sioni: Machine to Machine (M2M), Person to Machine (P2M) e Person to Person

(P2P). Combinate, le connessioni P2M e P2P contribuiranno per il 58% del va-

lore totale dell’IoT entro il 2022, mentre le connessioni M2M contribuiranno per

il rimanente 42%. E importante notare che mentre le connessioni M2M stanno

rapidamente diventando una fonte considerabile di valore, il risultato finale di


28

Figura 2.9: Suddivisione del Value at Stake per l’Europa1

Figura 2.10: Economia dell’Internet of Things2

queste connessioni e sempre quello di portare benefici alla persone. In definitiva,

l’economia dell’Internet of Things riguarda la possibilita di permettere alle per-

sone di essere piu produttive ed efficaci, prendendo decisioni migliori e di godere

di una migliore qualita della vita.


29


30

Capitolo 3

Physical Web

3.1 Physical Web

Come illustrato in precedenza, grazie all’Internet of Things sempre piu dispositivi

stanno diventando “intelligenti” e connessi a Internet. Tra le nuove esigenze

che si vengono a creare troviamo quella di individuare questi oggetti, scoprendo

cosı la loro esistenza e la possibilita di interagire con essi in modo semplice e

immediato. Il progetto “Physical Web” si pone come obbiettivi, da una parte

di pubblicizzare la presenza degli oggetti smart attraverso dei beacon Bluetooth,

chiamati Eddystone-URL e dall’altra quello di intercettare e interpretare questi

segnali. Questo progetto, pur essendo proposto da Google, e open source e non

brandizzato, in modo da incentivarne l’adozione come standard.

L’idea alla base del Physical Web e quella di estendere le potenzialita del

Web al mondo fisico intorno a noi. Questo comprende quindi la creazione di un

ecosistema dove gli oggetti smart possono trasmettere URL nell’area intorno a

loro. Ogni oggetto che dispone di un display, come un tablet o uno smartphone

nelle vicinanze puo intercettare questo URL, interpretarlo e mostrarlo all’utente.

Si rispecchia sostanzialmente il comportamento presente oggi in un motore di

ricerca:

• L’utente richiede un lista delle cose nelle vicinanze

• Viene mostrata una lista ordinata

31

3. PHYSICAL WEB

• L’utente sceglie un elemento

• L’URL viene aperto e mostrato all’interno di un browser

La parte che si occupa di pubblicizzare l’URL si chiama Eddystone-URL.

3.2 Eddystone

Eddystone e la specifica di un protocollo che definisce il formato dei messaggi

inviati da dispositivi Bluetooth Low Energy, chiamati messaggi beacon. Descrive

diversi tipi di frame che possono essere utilizzati individualmente o combinati per

creare dei beacon che possono essere utilizzati per una varieta di applicazioni.

La progettazione di Eddystone si e concentrata principalmente su alcuni aspetti

chiave:

• Funzionamento con le API Bluetooth di Android e iOS

• Semplice implementazione per una vasta gamma di dispositivi Bluetooth

Low Energy esistenti

• Compatibilita con le specifiche del Bluetooth Core Specification1

• Architettura flessibile che consente lo sviluppo di nuovi tipi di frame

Al momento sono disponibile tre tipi di frame: Eddystone-URL, Eddystone-UID

e Eddystone-TLM

3.2.1 Elementi comuni

Ogni frame Eddystone deve contenere i seguenti tipi di dati PDU:

• Il tipo di dato Service Solicitation come definito nel Bluetooth Core Spe-

cification Supplement (CSS) v5. Il Service Solicitation UUIDs, lista di 16

bit, deve contenere il Service UUID di Eddystone: 0xFEAA. Questo vie-

ne incluso per permettere lo scan in background da parte dei dispositivi

iOS.[16]

1https://www.bluetooth.org/en-us/specification/adopted-specifications

32

• Il tipo di dato Service Data, lista di 16 bit, deve essere il Service UUID di

Eddystone: 0xFEAA [16]

Il tipo specifico di frame e codificato nei quattro bit di ordine superiore del primo

ottetto nel Service Data associato al Service UUID.[8] I possibili valori sono mo-

strati in Figura 3.1. I quattro bit di ordine inferiore sono riservati per usi futuri

Figura 3.1: Lista dei tipi di frame con i corrispettivi valori in bit[8]

e devono essere 0000.

3.2.2 Eddystone-URL

Il frame Eddystone-URL fa il broadcast di un URL utilizzando un formato di

codifica compressa in modo da adattarsi agli spazi limitati del pacchetto di ad-

vertisment. Una volta codificato, l’URL puo essere utilizzato da qualsiasi client

con acceso a Internet. Per esempio, un client nelle vicinanze di un beacon

Eddystone-URL che trasmette l’URL https://goo.gl/WVBu4W, puo decidere di

visitarlo, in questo caso risolvendo l’indirizzo di uno dei distributori automatici

della simulazione.

Il frame Eddystone-URL, incorpora tutte le caratteristiche di UriBeacon, del

quale ne e l’evoluzione. Questo frame e la colonna portante del Pyhsical Web, un

progetto con lo scopo di facilitare la scoperta di contenuti web nelle vicinanze.

Le specifiche del frame sono mostrate in Figura 3.2. Il campo Frame Type, come

detto in precedenza, specifica il tipo di frame.

33

3. PHYSICAL WEB

Figura 3.2: Specifiche del tipo di frame Eddystone-URL[8]

Tx Power Level

Tx power e la potenza ricevuta a 0 metri, in dBm. Questo valore puo variare da

-100dBm a +20 dBm con granularita di 1 dBm.

Il modo migliore per determinare un valore preciso da inserire in questo campo

e quello di misurare l’output reale a 1 metro di distanza dal beacon e quindi

aggiungere 41dBm a questo valore. 41dBm e la perdita di segnale che si ha per

ogni metro di distanza Il valore di questo campo e un numero intero con segno a

8 bit, come specificato da TX Power Level Bluetooth Characteristic.[15][8]

URL Scheme Prefix

Il byte URL Scheme Prefix definisce lo schema di identificazione, un prefisso

opzionale che come il resto dell’URL e codificato.

HTTP URL encoding

Lo schema degli URL HTTP, definito dal documento RFC 1738 [4], puo essere

ad esempio “https://goo.gl/WVBu4W”, ed e utilizzato per indicare una risorsa

Internet accessibile tramite HTTP (HyperText Transfer Protocol).

La codifica consiste in una sequenza di caratteri. I codici carattere esclu-

si dall’encoding dell’URL, sono utilizzati come codici di espansione del testo.

34

Figura 3.3: Schema dei prefissi per gli URL nel frame Eddystone-URL[8]

Quando uno user agent riceve un Eddystone-URL, i byte codificati nell’URL

sono sostituiti tramite l’espansione del testo seguendo lo schema in Figura 3.4.

3.2.3 Eddystone-UID

Il frame Eddystone-UID fa il broadcast di un Beacon ID di 16-byte, opaco e

unico. Questo si suddivide in un namespace ID di 10 byte e di un instance ID

di 6 byte, rispettivamente una stringa univoca, identificativa del beacon e un

codice di istanza scelto in base all’applicazione. Il Beacon ID puo essere utile per

mappare un dispositivo in un database. Il namespace ID puo essere utilizzato

per raggruppare una particolare serie di beacon, mentre l’instance ID identifica

il singolo dispositivo all’interno del gruppo. La suddivisione del namespace e

instanza puo essere anche utilizzata per ottimizzare le strategie di scansione dei

dispositivi BLE, per esempio filtrando solo in base al namespace.[8]

3.2.4 Eddystone-TLM

Il frame Eddystone-TLM fa il broadcast di informazioni di telemetria riguardanti

il beacon stesso come valori di voltaggio della batteria, temperatura del disposi-

tivo, conteggio dei pacchetti di broadcast inviati. Dato che il frame Eddystone-

TLM non contiene un ID del beacon, deve essere accoppiato con un frame che

35

3. PHYSICAL WEB

Figura 3.4: Encoding per gli URL nel frame Eddystone-URL[8]

36

fornisca un ID, cioe un Eddystone-UID o Eddystone-URL e la trasmissione dovra

essere intervallata a uno di questi due.[8]

37

3. PHYSICAL WEB

38

Capitolo 4

Tecnologie alternative

4.1 Beacon

Sono presenti due principali alternative agli Eddystone: AltBeacon e iBeacon. I

motivi principali per cui non sono stati utilizzati in questa tesi derivano dal fatto

che gli iBeacon sono proprietari e non ufficialmente supportati in Android, mentre

gli AltBeacon richiedono un’ulteriore libreria esterna per l’utilizzo. Inoltre, non

meno importante, nessuno dei due offre l’elasticita offerta dagli Eddystone, in

quanto consentono un solo tipo di advertisement, utilizzabile solo all’interno di

applicazioni native. Anche nel caso dell’utilizzo degli Eddystone-UID all’interno

dell’applicazione nativa, questi permettono una maggiore flessibilita grazie alla

possibilita di poter associare ad essi dei dati, in qualsiasi momento.

4.1.1 iBeacon

iBeacon e un protocollo proprietario di Apple introdotto nel 2013 e richiede una

licenza per poter sviluppare hardware compatibile.[3] Come e possibile vedere in

Figura 4.1, l’identificativo del beacon si suddivide in tre parti:

• UUID: un identificativo univoco specifico per l’applicazione o il caso d’uso.

• Major: un ulteriore identificativo che puo indicare per esempio una sotto-

regione della piu grande regione specificata dall’UUID.

39

4. TECNOLOGIE ALTERNATIVE

Figura 4.1: Confronto tra Eddystone, AltBeacon, iBeacon e altri2

• Minor: un ultimo identificativo che permette un’ulteriore suddivisione

specifica per una regione.

Nella Figura 4.2 e possibile vedere un esempio di questa suddivisione per dei

negozi in tre diverse citta: l’UUID e sempre lo stesso e viene utilizzato per identi-

ficare la catena, il Major cambia per ognuna di queste citta, mentre il Minor viene

utilizzato per indicare il reparto di ciascun negozio. Sono presenti due modalita

di utilizzo:

• Monitoraggio della regione: In modo simile alle geofence, un’applicazio-

ne puo richiedere di essere notificata, anche quando si trova in background,

se un utente entra o esce da una regione definita da un beacon. Quan-

do l’applicazione fa questa richiesta di iniziare a monitorare una regione,

deve specificare l’UUID. Un’applicazione puo monitorare fino a 20 regioni,

ma utilizzando un singolo UUID per diverse posizioni, come nell’esempio

dei negozi fatto prima, una singola applicazione puo arrivare a monitorare

molte piu posizioni fisiche.

• Ranging: Al contrario del monitoraggio che consente di monitorare entra-

te/uscite dal range di azione del beacon, il ranging fornisce una lista di tutti

40

Figura 4.2: Esempio di utilizzo di un iBeacon[3]

i beacon individuati in una data regione contenente anche la distanza dal

dispositivo a questi. Il ranging funziona solamente quando l’applicazione e

aperta, in primo piano. La distanza ricevuta dai beacon viene categorizzata

in quattro diversi stati: immediate, indica con un alto livello di fiducia che

il beacon e fisicamente molto vicino al dispositivo ed molto probabile che

sia praticamente sopra; near, se non e presente nessun ostacolo tra il bea-

con e il dispositivo, questo si trova a circa 1-3 metri di distanza, ma se sono

presenti degli ostacoli che causano un’attenuazione del segnale, questo stato

potrebbe anche non comparire mai; far, indica che e stato individuato un

beacon ma che il livello di fiducia non e abbastanza elevato per determinare

se sia near o immediate, ma va tenuto in considerazione che questo non vuol

dire necessariamente che il beacon non sia vicino; unknown, la prossimita

del beacon non puo essere determinata e questo puo indicare che non ci

sono abbastanza dati presenti per determinare uno stato o che il ranging e

appena iniziato.[3]

4.1.2 AltBeacon

AltBeacon e una specifica di protocollo per il broadcast di beacon open ideata

da Radius Networks3 nel 2014, per sopperire alla mancanza di uno standard

aperto e alla disponibilita di beacon per la piattaforma Android. Inizialmente

2http://developer.radiusnetworks.com/3http://www.radiusnetworks.com/

41


era stata sviluppata una libreria per interagire con gli iBeacon, ma Apple non

ne permette l’utilizzo all’interno di sistemi Android ed e quindi stata ritirata.[18]

Successivamente e quindi stata ideata una piattaforma compatibile con quella

di Apple, ma aperta e disponibile per qualsiasi sistema operativo, cosı da poter

garantire un supporto anche se in maniera non ufficiale. E possibile vedere un

confronto tra queste tecnologie e quella Eddystone nella Figura 4.1 dove viene

specificata l’interoperabilita tra AltBeacon e iBeacon grazie a una struttura degli

identificativi simile. Si puo notare come l’identificativo diviso in tre parti rispecchi

quello degli iBeacon e ne garantisca quindi la compatibilita:

• id1: 16 byte per l’identificazione univoca dell’applicazione

• id2: 2 byte per una suddivisione dei casi d’uso

• id3: ulteriori 2 byte per una maggiore specializzazione del caso d’uso

Anche per quanto riguarda gli strumenti per individuare i beacon, sono gli stessi

degli iBeacon, descritti nella sezione precedente: Monitoring e Ranging. Radius

Networks, oltre ad aver ideato un protocollo, vende diversi tipi dei beacon di

cui viene garantita la compatibilita con i tre diversi tipi di protocollo. In questi

e possibile utilizzare contemporaneamente iBeacon e AltBeacon, alternandoli,

mentre se si vuole fare il broadcast di Eddystone non sara possibile utilizzare gli

altri due.

4.1.3 Android Beacon Library

Rappresenta la libreria ufficiale per individuare AltBeacon, ma che permette di

poter utilizzare anche qualsiasi altro tipo di beacon all’interno di Android. Come

accennato precedentemente sono supportati ufficialmente solo gli AltBeacon e gli

Eddystone, ma vista la similarita dei primi con gli iBeacon, vengono supportati

anche quest’ultimi. La libreria viene caricata all’avvio del sistema operativo ed

e in grado di lanciare applicazioni anche se l’utente non le ha ancora aperte (e

sufficiente che le abbia avviate almeno una volta dopo l’installazione) e di ge-

stirne la loro esecuzione. Infatti implementando un’opportuna classe all’interno

dell’applicazione, questa puo essere risvegliata dalla libreria all’avvistamento di

42

un beacon e verra lanciata una normale attivita, che potrebbe risultare addirittu-

ra nell’apertura dell’applicazione senza nessuna richiesta dell’utente.[14] Questo

oltre a risultare in un forte utilizzo della batteria del dispositivo, visto che la

libreria in automatico effettuera una scansione dei beacon ogni 5 minuti, se non

impostata diversamente, puo anche risultare in una esperienza utente poco grade-

vole. Visto che sono presenti all’interno di Android delle API per la piattaforma

beacon di Google e quindi degli Eddystone, mi e sembrato opportuno utilizzarle,

rispetto ad una libreria di terze parti, che oltretutto va contro ad alcune delle best

practice specificate da Google, come la ricerca in background di beacon e l’invio

attivo di notifiche d una volta individuati, anche se non richiesto espressamente

dall’utente.

43


44

Capitolo 5

Implementazione

In questo capitolo verra trattata l’applicazione dell’Internet of Things e del Phy-

sical Web alle vending machines.

E stata creata una Web Application, tramite l’utilizzo di HTML5, CSS, Ja-

vaScript e jQuery e una applicazione per Android utilizzando Java. All’interno

dell’applicazione web, utilizzando jQuery vengono effettuate chiamate asincrone

GET e POST al WebServer, che si comporta come un proxy, per richiedere e

trasmettere dati al database endpoint di backend. Questo endpoint, sviluppato

in PHP, dopo aver cercato le informazioni richieste nel database, implementato

in SQLite, risponde con il JSON appropriato. Essendo le risposte in JSON, lo

stesso processo di richiesta e interpretazione e utilizzato con i meccanismi appro-

priati anche all’interno dell’applicazione Android. La Web Application e l’appli-

cazione Android inoltre comunicano direttamente con il distributore automatico,

mediante l’utilizzo di un WebSocket.

Di seguito verranno viste nel dettaglio le varie parti del sistema.

5.1 Server

L’implementazione lato server e suddivisa in due parti: Database e Web Ser-

ver.

45

5. IMPLEMENTAZIONE

5.1.1 Database

Il database si occupa di immagazzinare tutti i dati relativi ai distributori auto-

matici. Sono disponibili due tipi di informazione principali.

Informazioni relative al distributore:

• Produttore: il costruttore del distributore automatico

• Rifornitore: l’azienda che si occupa di rifornire di prodotti il distributore

• Posizione: l’indirizzo in cui e posizionato il distributore

• Piano: il piano dell’edificio, se rilevante, in cui e situato

• Nome della zona: nominativo della zona in cui sono raggruppati i distri-

butori (es. dipartimento di matematica)

Informazioni relative ai prodotti:

• Nome: il nome del prodotto

• Produttore: l’azienda produttrice del prodotto

• Tipologia: il tipo di prodotto (es. snack, bevanda)

• Immagine: la rappresentazione del prodotto da mostrare all’utente

Queste informazioni sono poi poste in relazione tra di loro per conoscere l’effet-

tiva disponibilita dei prodotti all’interno dei singoli distributori. Come risultato

finale, in aggiunta alle informazioni precedenti, si possono quindi conoscere:

• Posizione: la posizione all’interno del distributore, informazione necessaria

per erogare il prodotto

• Quantita: la disponibilita relativa al prodotto

• Prezzo: il prezzo del prodotto

• Scadenza: la data di scadenza del prodotto

46

Figura 5.1: Schema del database

1 f unc t i on g e t a l l p r o d u c t s ( $id , $quant i ta ) {2 $query = ”SELECT prodotto . nome ,3 prodotto . immagine ,4 d i s t r i b u t o r e p r o d o t t o . prezzo ,5 d i s t r i b u t o r e p r o d o t t o . quant ita ,6 prodotto . t i p o l o g i a ,7 d i s t r i b u t o r e p r o d o t t o . po s i z i one ,8 d i s t r i b u t o r e p r o d o t t o . i d p rodo t to ” ;9 $query = $query . ” FROM prodotto j o i n d i s t r i b u t o r e p r o d o t t o on

10 prodotto . id = d i s t r i b u t o r e p r o d o t t o . i d p rodo t to j o i n11 d i s t r i b u t o r e on d i s t r i b u t o r e p r o d o t t o . i d d i s t r i b u t o r e =

d i s t r i b u t o r e . id ” ;12 $query = $query . ” WHERE d i s t r i b u t o r e . id = ” . $ id . ” and

quant i ta >= ” . $quant i ta . ” ; ” ;13

14 $ r e s u l t s = f e t c h d a t a ( $query ) ;15

16 re turn $ r e s u l t s ;17 } ;

Listing 5.1: Codice PHP di una richiesta al database di tutti i prodotti in undistributore

47

5. IMPLEMENTAZIONE

Nella Figura 5.1 e possibile vedere lo schema del database con i relativi vincoli

di integrita mentre nella Listing 5.1 e possibile vedere parte del codice PHP che

viene eseguito lato server facendo una richiesta di tutti i prodotti all’interno del

distributore, passato come parametro alla funzione.

5.1.2 Web Server

Il Web Server e ospitato su Google App Engine, principalmente per far fronte

alla necessita di tutta la piattaforma di avere un certificato SSL valido. Infatti,

per poter utilizzare i Service Worker, che verranno illustrati nella Sezione 5.2.3,

tutte le pagine devono essere realizzate in HTTPS e di conseguenza anche tutte

le comunicazioni tra le varie parti del sistema e le richieste a risorse esterne

devono rispettare tale protocollo. All’interno del web server sono ospitate tutte

le pagine HTML, con i relativi CSS, le immagini dei prodotti e i file JavaScript.

Inizialmente il database e il web server erano collocati sulla stessa macchina, ma

in seguito alla necessita di passare a HTTPS, e stata spostata solo la parte web

su GAE per due motivi: in primo luogo perche la parte database era gia stata

implementata in SQLite, non supportato dalla piattaforma, che prevede soltanto

un piano a pagamento per poter utilizzare i database proprietari; in secondo

luogo perche in questo modo e stato aggiunto un ulteriore strato a protezione del

database.

Google App Engine

Gogle App Engine (GAE), rappresenta una piattaforma di cloud computing, of-

ferta come Platform as a Service (PaaS), che permette di sviluppare e ospitare

applicazioni nei data center gestiti da Google. Le applicazioni vengono eseguite

in delle sandbox e distribuite su piu server. Google App Engine offre un ridi-

mensionamento automatico delle risorse per le applicazioni. All’aumentare delle

richieste vengono allocate automaticamente maggiori risorse, in modo da fron-

teggiare la domanda aggiuntiva. Questo processo viene gestito interamente dalla

piattaforma e l’utente non puo impostare nessun parametro. Nella piattaforma

Google App Engine e possibile utilizzare quattro linguaggi per gestire il progetto:

Python, Java, PHP e Go. Per questo progetto e stato scelto Python.

48

La struttura del progetto e gestita da un file YAML, app.yaml, in cui sono de-

scritti tutti i path raggiungibili e le operazioni da eseguire quando viene richiesto

quel percorso. Un esempio in merito e mostrato in un estratto del codice nella

Listing 5.2. All’inizio del file vengono date alcune direttive tra cui il nome del-

l’applicazione, la versione e il linguaggio da utilizzare, in questo caso Python 2.7.

Successivamente sono mostrati gli handlers, ovvero le direttive che si occupano

di gestire le chiamate, composti da una lista di URL validi per l’applicazione e le

operazioni da effettuare quando questi vengono richiesti. Per qualsiasi altro URL

al di fuori di quelli elencati, viene mostrato un messaggio di errore.

All’interno del file e possibile incontrare tre diversi tipi di handler, di seguito

verranno mostrati alcuni esempi:

• Singolo file statico: richiedendo la radice, ovvero “/”, viene restituita la

Home Page, cioe il file “index.html”.

• Cartella di file statici: attraverso una regular expression, qualsiasi file

con estensione .gif, .png o .jpg, richiesto all’interno della cartella “img”,

contenente le immagini, viene restituito al browser.

• Script: questo tipo di handler esegue lo script “main.py” per gestire la

richiesta, in questo esempio a “/postdata”. Verra chiamata l’applicazione

“app” all’interno dello script, mostrata nella Listing 5.3; per questo motivo

viene indicato come “main.app”.

1 a p p l i c a t i o n : vending−machine

2 v e r s i on : 1

3 runtime: python27

4 a p i v e r s i o n : 1

5 th r e ad sa f e : yes

6

7 hand le r s :

8 − u r l : /

9 s t a t i c f i l e s : index . html

10 upload: index . html

11 − u r l : /img / ( . ∗ \ . ( g i f | png | jpg ) ) $

12 s t a t i c f i l e s : img/\1

49

5. IMPLEMENTAZIONE

13 upload: img / . ∗ \ . ( g i f | png | jpg ) $

14 − u r l : / postdata

15 s c r i p t : main . app

Listing 5.2: Estratto del codice YAML di gestione del progetto

Lo script Python si occupa di gestire le richieste ai database di backend,

sia quello contenente i dati relativi ai distributori, sia quello delle iscrizioni alle

notifiche push. Sempre per quanto riguarda le notifiche push e presente anche una

componente che si occupa dell’invio al client, tramite il Google Cloud Messaging.

Al momento le notifiche possono essere inviate solo su Chrome OS, Chrome per

dispositivi mobili Android e per qualsiasi Sistema Operativo desktop.

Nella Listing 5.3 viene mostrato il codice che si occupa di gestire gli handler

associati allo script e due esempi di richieste. Il primo esempio riguarda una

chiamata POST all’endpoint del database delle sottoscrizioni push, invocata tra-

mite /push. Viene creata la richiesta con l’identificatore univoco in possesso del

client, associata al campo “subscription” e invocata la chiamata POST tramite

la “urlfetch”. In questo modo viene salvata nel database, per poi poter inviare

notifiche push successivamente al client. Nella Sezione 5.2.3 verranno illustrate

con maggior dettaglio le notifiche push. Nel secondo esempio vengono presi i

parametri della URL della chiamata GET, che ha invocato la funzione /getdata,

e vengono composti per creare la chiamata GET all’endpoint del database dei

distributori automatici.

50

1 c l a s s PushPage ( webapp2 . RequestHandler ) :2 de f post ( s e l f ) :3 u r l = s e r ve r Ur l+“push . php”4 req = s e l f . r eque s t . get ( “ s u b s c r i p t i o n ” )5 data = {“ s u b s c r i p t i o n ” : req }6 form data = u r l l i b . ur l encode ( data )7 r e s u l t = u r l f e t c h . f e t c h ( u r l=ur l ,8 payload=form data ,9 method=u r l f e t c h .POST)

10 l o gg ing . i n f o ( req )11

12 c l a s s getDataPage ( webapp2 . RequestHandler ) :13 de f get ( s e l f ) :14 u r l = s e r ve r Ur l+“ getdata . php?”15 args = s e l f . r eque s t . arguments ( )16 data = {}17 f o r a in args :18 data [ a ] = s e l f . r eque s t . get ( a )19

20 form data = u r l l i b . ur l encode ( data )21 l o gg ing . i n f o ( form data )22

23 r e s u l t = u r l f e t c h . f e t c h ( u r l+“%s ” % form data )24

25 l o gg ing . i n f o ( r e s u l t . s t a t u s c o d e )26 s e l f . r e sponse . wr i t e ( r e s u l t . content )27

28...

29

30 app = webapp2 . WSGIApplication ( [31 ( “/ send push ” , SendPushHandler ) ,32 ( “/push” , PushPage ) ,33 ( “/ getdata ” , getDataPage ) ,34 ( “/ re sponse ” , getRespJson ) ,35 ( “/ postdata ” , postDataPage )36 ] , debug=True )

Listing 5.3: Estratto del codice Python dello script principale main.app

51

5. IMPLEMENTAZIONE

5.2 Web Application - Client

Nella componente client sono state impiegate diverse tecnologie e framework, tra

cui jQuery, Materialize e WebSocket.

5.2.1 JavaScript, jQuery e jQuery Mobile

La componente principale dell’applicazione web e stata sviluppata in JavaScript,

facendo ampio uso di una delle sue piu famose librerie, jQuery. Sebbene sia

fruibile anche tramite desktop, lo sviluppo si e concentrato maggiormente sulla

versione mobile e quindi e stato utilizzata anche la libreria jQuery Mobile che

offre funzionalita aggiuntive mirate all’ambiente mobile. La scelta di privilegiare

il mobile e dettata dal fatto che attualmente non e ancora disponibile la ricerca

di beacon Bluetooth in ambiente desktop; inoltre l’utilizzo dei distributori auto-

matici, per la natura stessa del servizio, si applica maggiormente ai dispositivi

mobili. Inoltre Chrome OS e l’unico sistema operativo desktop, in versione stabi-

le, in cui e possibile utilizzare le funzioni offerte da Web Bluetooth che verranno

affrontate nella Sezione 5.6.2

Nella Listing 5.4 e possibile vedere un estratto del codice JavaScript prin-

cipale. In questo caso si vede una chiamata HTTP asincrona effettuata con la

funzione ajax di jQuery all’indirizzo “/getdata”. In questa richiesta vengono

passati tre parametri: il tipo di dati che si vuole chiedere, in questo caso i pro-

dotti; l’identificativo del distributore automatico per cui si stanno richiedendo; la

quantita minima che deve avere un prodotto per comparire nella risposta. Que-

sto ultimo parametro e stato aggiunto per semplificare la pagina di rifornimento

del distributore, visualizzando anche i prodotti che sono esauriti e che sono so-

litamente presenti in quel distributore. Il Server rispondera a questa richiesta,

e dopo aver interrogato il database, ritornera un JSON contenente tutti i dati

relativi ai prodotti. Nell’esempio e possibile vedere come ad ogni iterazione del

ciclo each relativa ad ogni prodotto, verra creato il codice HTML contenente i

dati di quest’ultimo, come result.nome per il nome del prodotto, result.immagine

per visualizzare l’immagine relativa o per esempio result.posizione che conterra

la posizione del prodotto all’interno del distributore.

52

1 $ . a jax ({2 type : ’GET’ ,3 u r l : ’ / getdata ’ ,4 data : {5 type : ’ p r odo t t i ’ ,6 machine : theId ,7 quant i ta : quant i ty8 } ,9 dataType : ’ j s on ’

10 }) . done ( func t i on ( re sponse ) {11 $ ( re sponse ) . each ( func t i on ( index , r e s u l t ) {12 r e s u l t I d . push ( r e s u l t . i d p rodo t to ) ;13 $ ( ’#r e s u l t ’ ) . append ( ’<div c l a s s=“ c o l l 2 c o l s4 ”> \14 <div c l a s s=“ card ”> \15 <a c l a s s=“ prodotto ” \16 data−p o s i z i o n e=’ + r e s u l t . p o s i z i o n e + ’ \17 data−id=’ + r e s u l t . i d p rodo t to + ’ \18 data−name=“ ’ + r e s u l t . nome + ” ’> \19 <div c l a s s=“card−image va l ign−wrapper”> \20 <div id=“ s h i e l d ” data−id=’+r e s u l t . i d p rodo t to+’>\21 </div> \22 <img c l a s s=“ va l i gn ” s r c=“ ’ + r e s u l t . immagine + ” ’> \23 </div> \24 </a> \25

...26 </div> ’ ) ;27 }) ;28

...29

30

31 }) . f a i l ( f unc t i on ( ) {32 a l e r t ( t h i s . responseText ) ;33 }) ;

Listing 5.4: Esempio di funzione ajax di jQuery del file JavaScript principale,adattato per questioni di spazio.

53

5. IMPLEMENTAZIONE

Materialize

Materialize e un framework di front-end, basato sul Material Design di Google1,

che fornisce funzioni e strumenti per creare pagine web secondo questo stile.

Questo framework, che a sua volta fa largo uso di jQuery, permette di gestire

l’interfaccia da mostrare all’utente mediante l’uso di classi CSS e di funzioni.

5.2.2 WebSocket

Una funzione fondamentale per la piattaforma e svolta dal WebSocket, che si

occupa di far dialogare tra loro, in maniera diretta, il distributore automatico e

l’applicazione. WebSocket e una tecnologia web che fornisce canali di comunica-

zione full-duplex attraverso una singola connessione TCP. L’API del WebSocket

e stata standardizzata dal W3C2 e il protocollo WebSocket e stato standardizzato

dall’IETF3. Nella Listing 5.5 vengono mostrate le tre funzioni che si occupano di

spedire e ricevere dati dal distributore. Al momento dell’acquisto tramite l’appli-

cazione, viene aperto un WebSocket e attraverso la funzione send vengono inviati

al distributore i prodotti selezionati nella pagina. Quest’ultimo rimane poi in

attesa di una risposta, che puo essere di errore oppure puo contenere il messaggio

inviato dal distributore automatico. Se tutto e andato a buon fine questi dati

arriveranno nella onmessage e verranno letti e processati per poi venire mostrati

nella pagina.

1 var ws = new WebSocket ( ”wss : //vm. beacon−machine . eu :8080 ” ) ;

2

3 dataToSend = JSON. s t r i n g i f y ({4 prodo t t i : i d p r o d o t t i ,

5 p o s i z i o n e : p o s i z i o n e p r o d o t t i

6 }) ;

7

8 ws . onopen = func t i on ( ) {9 // Web Socket i s connected , send data us ing send ( )

10 ws . send ( dataToSend ) ;

1Descrizione del Material Design alla pagina: http://www.google.it/design/spec/material-design/introduction.html

2World Wide Web Consortium3Internet Engineering Task Force

54

11 } ;

12

13 ws . oner ro r = func t i on ( evt ) {14 a l e r t ( ” Errore d i comunicazione con i l WebSocket de l d i s t r i b u t o r e

” ) ;

15 } ;

16

17 ws . onmessage = func t i on ( evt ) {18 var rece ived msg = evt . data ;

19 p r o d u c t l i s t = JSON. parse ( rece ived msg ) ;

20 // proce s s the r e c e i v e d data

21...

22 }

Listing 5.5: Estratto del codice JavaScript che si occupa di comunicare con il

distributore.

5.2.3 Service Workers

Un Service Worker e uno script eseguito in background dal browser, separatamente

rispetto a una pagina web, che offre funzionalita che non richiedono la visualizza-

zione di una pagina o l’interazione da parte dell’utente. E un Working Draft del

W3C1, quindi ancora in una prima fase di specifiche e ancora lontano dall’esse-

re una raccomandazione. Per questo le funzionalita disponibili sono in continuo

aumento, ma dipendono anche dalla specifica adozione di ogni singolo browser

utilizzato. Essendo questo Working Draft promosso da Google, ovviamente Chro-

me e il browser con la maggiore adozione delle API. Fra queste si possono trovare

funzioni per intercettare le richieste di rete di una pagina e rispondere a seconda

delle esigenze, per esempio con contenuti presenti in una cache o per inviare no-

tifiche push. In futuro e prevista l’aggiunta di metodi per il geofencing di cui si

trattera nella Sezione 5.6.1 e per sincronizzare dati in background.

Alcune caratteristiche dei Service Worker sono:

• Sono dei JavaScript Worker, quindi non possono accedere direttamente al

DOM2, pero possono comunicare con le pagine che li controllano attra-

1World Wide Web Consortium: http://www.w3.org/2Document Object Model

55

5. IMPLEMENTAZIONE

verso dei messaggi inviati tramite l’interfaccia postMessage e quelle pagine

possono modificare il DOM all’occorrenza.

• Sono dei proxy di rete programmabili e quindi permettono di controllare

come vengono gestite le richieste di rete per quella pagina

• Vengono terminati quando non in uso e riavviati all’occorrenza, quindi non

si puo fare affidamento ad uno stato globale all’interno delle funzioni onfetch

e onmessage.

Un Service Worker ha un ciclo di vita completamente separato rispetto alla

pagina web e richiede di essere installato. Come primo passo quindi e necessario

procedere alla sua registrazione, chiamando la funzione register, tipicamente al-

l’interno del file JavaScript principale. Come conseguenza di questa chiamata, il

browser iniziera la fase di installazione in background, durante la quale alcuni file

statici vengono salvati in cache. Se tutto e andato a buon fine il Service Worker

sara installato e si passera alla fase di attivazione dove solitamente si controllano i

file in cache e vengono cancellati quelli non aggiornati. Dopo questi step il Service

Worker controllera tutte le pagine all’interno del suo scope, ad esclusione della

pagina che ha richiesto l’installazione, che sara controllata solo dal caricamento

successivo. Una volta che il Service Worker prende il controllo, puo trovarsi in

due stati: puo essere terminato per risparmiare memoria oppure si occupera di

gestire tutti gli eventi di richieste o messaggi che vengono fatte dalla pagina.

In questa implementazione, all’installazione del Service Worker, vengono aggiun-

ti nella cache: la home page, i file JavaScript di jQuery, jQuery Mobile e di

Materialize, i loro rispettivi CSS e le icone in stile Material Design di Google1.

In questo modo verranno direttamente intercettate le richieste di rete per que-

sti file e restituiti direttamente dal Service Worker. Questo processo puo pero

esporre a rischi: se si dovessero verificare malfunzionamenti durante la richie-

sta di questi file, infatti, l’installazione del SW fallirebbe, senza nessun avviso o

notifica, ne direttamente all’utente, ne nei log. Nel processo di installazione e

quindi opportuno richiedere un numero ristretto di file e procedere a popolare

la cache successivamente. Il Service Worker provera comunque ad installarsi al

1https://www.google.com/design/icons/

56

successivo caricamento della pagina. Dopo il primo caricamento, salvera dinami-

camente tutte le immagini dei prodotti e le restanti pagine html, in questo modo

l’applicazione risultera da subito piu fluida e immediata.

Notifiche push

All’interno del Service Worker oltre a registrare un Listener per le richieste di

rete e possibile associarne uno ulteriore per la rilevazione di notifiche push e

della loro apertura. Al momento, pure essendo l’API delle notifiche push uno

standard, non e ancora del tutto completa e adottata da tutti i browser. Questa

API e disponibile solo su Chrome per Android e per i vari Sistemi Operativi

desktop, per il momento attraverso il Google Cloud Messaging1, in attesa che

lo standard venga ampiamente adottato. Anche Mozilla sta implementando le

notifiche push all’interno di Firefox, ma e prevista la disponibilita per l’utilizzo

nei Service Worker in Firefox 42, che dovrebbe essere presentato nella versione

stabile a novembre 2015.

La notifica che viene inviata dal server e un JSON in cui e possibile inserire

qualsiasi tipo di dato che sara disponibile nell’evento di ricezione, ma quando si

creera la notifica nel Service Worker per visualizzarla, sara possibile disporre di

cinque soli campi:

• Titolo: il titolo da mostrare all’utente per la notifica

• Corpo: il testo del messaggio all’interno della notifica mostrato all’utente

• Icona: l’icona che verra visualizzata

• Vibrazione: e possibile specificare un pattern di vibrazioni del dispositivo

mobile da effettuare alla ricezione della notifica.

• Tag: un tag con cui e possibile identificare la notifica o il gruppo di notifiche.

Per esempio, inviando piu notifiche con lo stesso tag, come comportamento

predefinito verra visualizzata solo l’ultima e quindi tutte le altre andranno

perse, perche sovrascritte. Recentemente e stata aggiunta la possibilita di

richiedere le notifiche presenti attraverso la funzione getNotifications() e

1GCM: https://developers.google.com/cloud-messaging/

57

5. IMPLEMENTAZIONE

sara quindi possibile per esempio raggruppare le notifiche con lo stesso tag

e visualizzare un contatore.

• Dati: dalla versione 44 di Chrome (diventata stabile a fine luglio 2015) e

stata aggiunta la possibilita di associare un campo data alla notifica. In

questo modo e possibile passare qualsiasi tipo di stringa alla notifica e per

esempio decidere quale URL mostrare al momento dell’apertura. Per motivi

di sicurezza comunque sara possibile aprire soltanto URL all’interno dello

scope.

Attualmente nell’implementazione sono presenti tutti i campi presentati e all’in-

terno del campo data viene passata la URL da aprire. Inoltre sono stati aggiunti

nel JSON dei campi per poter inviare notifiche solo se l’utente e in determi-

nate zone, attraverso il Geofencing, tuttavia questa funzionalita non e ancora

completamente implementata (Sezione 5.6.1).

5.3 Applicazione Android

Allo stato attuale, le tecnologie Web utilizzate nella web application non sono

ancora del tutto mature, soprattutto per quanto riguarda la componente di ricer-

ca dei beacon, che al momento e disponibile solo in Chrome per iOS. Per quanto

riguarda Android, gli sviluppatori hanno rilasciato un’applicazione di test per la

ricerca dei beacon, che simula quello che verra a breve integrato nel sistema ope-

rativo. Dal momento che e necessario installare un’applicazione per simulare una

scoperta del beacon “senza app” e stato deciso di implementare un’applicazione

nativa per Android cosı da aver maggiore controllo su questa fase e per confron-

tare il diverso approccio che si ha in una piattaforma piu matura come quella

Android. Per sfruttare tutte le API della piattaforma beacon di Google e stato

utilizzato il secondo tipo di frame offerto dalla famiglia Eddystone, l’Eddystone-

UID ideato proprio per l’utilizzo all’interno di un’applicazione mobile. Di seguito

verranno illustrate le varie componenti della piattaforma che sono state utilizzate

per l’applicazione.

58

5.3.1 Proximity Beacon API

L’API Proxymity Beacon fa parte della piattaforma per i beacon Bluetooth Low

Energy (BLE) di Google. Questa API consente di gestire dei dati associati ai

beacon BLE utilizzando un’architettura REST, e quindi possibile effettuare chia-

mate GET, POST, PUT e DELETE in base all’operazione che si vuole effettuare.

Una volta registrato il beacon e possibile associare dati che verranno salvati nel

cloud. In questo modo e possibile gestire e aggiornare le informazioni associate

ad ogni beacon anche dopo che questi sono stati posizionati, senza bisogno di

accedervi fisicamente. L’API consente inoltre di eseguire aggiornamenti batch in

modo da fornire sempre le informazioni piu aggiornate senza dover aggiornare

manualmente ogni singolo beacon e dato che queste informazioni sono salvate nel

cloud questo metodo e scalabile e a bassa latenza. Un attachment che e asso-

ciato al beacon puo essere utilizzato come segnale contestuale dall’applicazione

utilizzando l’API Nearby. Nella Figura 5.2 e possibile vedere la struttura della

piattaforma beacon. Nella parte destra si vede come dopo la scoperta di un bea-

con viene fatta la richiesta al cloud e la risposta con i dati riguardanti il beacon

viene utilizzata nell’applicazione tramite l’API Nearby Messages. Nella parte si-

nistra si vede la registrazione e la successiva gestione del beacon. Questa ultima

parte e stata implementata ad hoc tramite uno script Python.

Durante la fase di registrazione o di update del beacon e possibile associare le

seguenti informazioni:

• Advertised ID: un oggetto contenente il tipo di beacon utilizzato e una co-

difica dell’identificativo effettivamente emesso del beacon, obbligatorio solo

nella fase di registrazione. Il campo contenente il tipo di beacon puo esse-

re: EDDYSTONE : quello utilizzato in questo progetto, un formato aperto

sviluppato da Google supportato sia da Android che iOS; IBEACON : un

beacon compatibile con le specifiche di Apple iBeacon; ALTBEACON : un

altro tipo di beacon aperto, sviluppato da Radius Networks1. Nella fase

di update visto che verra aggiornata direttamente la risorsa, questo campo

sara ignorato.

2Fonte: https://developers.google.com/beacons/overview1http://www.radiusnetworks.com/

59

5. IMPLEMENTAZIONE

Figura 5.2: Struttura della piattaforma beacon di Google2

• Status: lo stato attuale del beacon, parametro obbligatorio. Puo essere:

ACTIVE, lo stato normale del beacon, ovvero attivo, che sta trasmettendo;

DECOMISSIONED, il beacon non e piu utilizzato; INACTIVE, il beacon

non e piu visibile a nessun dispositivo. Gli ultimi due stati sono irreversibili.

• Expected stability: campo opzionale in cui inserire la previsione della

“stabilita” della posizione del beacon. Puo essere: STABLE, non e previsto

che si muova, per esempio all’entrata di un negozio; PORTABLE, indica

che solitamente e stabile ma potrebbe muoversi, per esempio all’interno di

un piccolo negozio; MOBILE, si muove frequentemente, per esempio un

oggetto personale o un Food Truck ; ROVING, in continuo movimento, per

esempio su un autobus o un treno.

• Latitude and longitude: la posizione del beacon espresso con coordinate

di latitudine e longitudine. E un campo facoltativo.

• Indoor floor level: campo opzionale, indica in quale piano di un edificio

60

si trova il beacon. Deve essere una stringa come restituita dalle API di

Google Maps.

• Google Places API Place ID: anche questo un campo facoltativo dove e

possibile specificare la stringa identificativa del luogo in cui e posizionato il

beacon. E generata chiamando le API Google Places e richiedendo il Place

ID.

• Freeform text description: Un campo di testo libero in cui e possibile

inserire una descrizione del beacon. Sono disponibili 140 caratteri.

• Properties: un oggetto contenente una lista di chiavi e valori, come puo

essere un JSON, in cui e possibile inserire le proprieta e caratteristiche del

beacon quali il livello della batteria o la versione del firmware.

Per poter utilizzare questa API e necessario abilitarla nella Google Developers

Console e utilizzare le giuste credenziali ogni volta che si vuole registrare, aggior-

nare o aggiungere un attachment ai beacon.

Registrazione

Nella Listing 5.6 e possibile vedere il codice utilizzato per registrare un beacon

nel cloud. Nelle prime righe viene fatta una richiesta di autenticazione tramite

OAuth 2.0 in cui viene fornito uno scope, ovvero il set limitato di permessi che

vengono richiesti dallo script. La risposta con le credenziali e il token necessario

per effettuare la richiesta di registrazione vengono salvati nella variabile creden-

tials e successivamente il campo access token viene inserito nell’header alla voce

Authorization. Questo passaggio si ripete immutato per tutte le operazioni e

quindi in seguito verra omesso. Dopo la fase di autenticazione, viene mostrato il

JSON contenente i dati relativi a un ipotetico beacon posizionato nel distribu-

tore automatico del Dipartimento di Informatica. All’interno vi sono: il campo

obbligatorio che identifica il beacon, lo stato impostato come attivo, la latitudine

e longitudine, la stringa del Google Place ID, la stabilita prevista e una breve

descrizione. Infine viene fatta una richiesta POST contenente gli header creati e

il JSON dei dati all’endpoint di registrazione salvato nella variabile URL.

61

5. IMPLEMENTAZIONE

1...

2 f l ow = OAuth2WebServerFlow ( c l i e n t i d=CLIENT ID ,

3 c l i e n t s e c r e t=CLIENT SECRET,

4 scope=“ https : //www. g o o g l e a p i s . com/auth/

u s e r l o c a t i o n . beacon . r e g i s t r y ” ,

5 r e d i r e c t u r i=“ http :// example . com/

auth re turn ” )

6

7 s t o rage = Storage ( “ c reds . data ” )

8 c r e d e n t i a l s = run ( flow , s t o rage )

9

10 headers = {“Content−Type” : “ a p p l i c a t i o n / http ” , “ Author i zat ion ” : “

Bearer ”+c r e d e n t i a l s . a c c e s s t ok en }11

12 data ={13 “ ad v e r t i s e d I d ” : {14 “ type ” : “EDDYSTONE” ,

15 “ id ” : “NmVuZGluZy1tYRI0VnibrA==”

16 } ,

17 “ s t a t u s ” : “ACTIVE” ,

18 “ p lace Id ” : “ChIJSdIWg7rUf0cRjRXgU18xUgw” ,

19 “ latLng ” : {20 “ l a t i t u d e ” : 44 .497088 ,

21 “ l ong i tude ” : 11.356054

22 } ,

23 “ e x p e c t e d S t a b i l i t y ” : “STABLE” ,

24 “ d e s c r i p t i o n ” : “VendingMachine Dipartimento In fo rmat i ca ”

25 }26

27 u r l = “ https : // proximitybeacon . g o o g l e a p i s . com/ v1beta1 / beacons :

r e g i s t e r ’ ’

28 r = r e q u e s t s . post ( ur l , data=j son . dumps( data ) , headers=headers )

Listing 5.6: Estratto del codice per la registrazione di un beacon.

In risposta a una richiesta di registrazione effettuata con successo si ricevera un

JSON contenente gli stessi dati inviati in fase di registrazione e un parametro ag-

giuntivo beaconName contenente il nome assegnato al beacon. Questo parametro

sara necessario per le altre fasi di gestione.

62

Aggiornamento

Tramite una richiesta di update, si puo aggiornare un beacon precedentemente

registrato, effettuando una richiesta PUT specificando come URL quello identi-

ficativo del beacon, come puo essere https://proximitybeacon.googleapis.com/v1beta1

/beacons/3!36656e64696e672d6d61123456789bac/. Come nel caso della registrazione si

possono specificare i parametri desiderati ad eccezione del campo status, che anche

se presente verra ignorato perche per modificare questo parametro sono presenti

endpoint specifici. Se un campo era presente nella fase di registrazione o in un

update precedente e non viene specificato, verra eliminato.

Attivazione, disattivazione, dismissione

Come anticipato nella sezione precedente sono presenti tre endpoint specifici per

attivare, disattivare o dismettere un beacon registrato. Per esempio per attivare

un beacon e necessario fare una richiesta POST all’URL https://proximitybeacon.

googleapis.com/v1beta1/beacons/3!36656e64696e672d6d61123456789bac:activate. Per effet-

tuare le altre due operazioni bastera sostituire activate con deactivate o decom-

mission in base al tipo di richiesta che si vuole effettuare. Se viene utilizzato

decommission, il beacon non sara piu utilizzabile in futuro con quell’identificativo.

Aggiunta Attachment

Una richiesta per creare un attachment deve contenere due campi:

• namespacedType: composto da il namespace ovvero il nome assegnato al

progetto sul cloud, non modificabile; type che identifica il tipo di dati del-

l’attachment e puo essere una stringa di caratteri scelta liberamente ad

eccezione del carattere “/” e essere lungo fino a 100 caratteri.

• data: il contenuto dell’attachment, ovvero i dati che si vogliono associare al

beacon. Deve essere codificato in base64 1 e puo essere fino a 1024 bytes. E

possibile associare qualsiasi tipo di dato purche rispetti queste specifiche.

1http://tools.ietf.org/html/rfc4648#section-4

63

5. IMPLEMENTAZIONE

Nella Listing 5.7 e possibile vedere il codice utilizzato per creare un attachment

per il beacon registrato nella sezione precedente 5.3.1. Dopo aver effettuato l’au-

tenticazione qui omessa, viene creato un JSON contenente l’URL del distributore,

un titolo, una descrizione, la posizione descritta a parole e quella tramite coordina-

te GPS e infine un ipotetico stato delle promozioni per quel distributore. Succes-

sivamente viene codificato il dato e inserito nell’apposito campo del JSON finale.

Questa volta nell’URL di richiesta e inserito il nome del beacon ricevuto come

risposta in fase di registrazione beacons/3!36656e64696e672d6d61123456789bac e

fatta una richiesta POST all’endpoint attachment.

1...

2 dataToEncode = {3 “ u r l ” : “ https : // vending−machine . appspot . com/? id=3” ,

4 “ t i t l e ” : “Vending Machine” ,

5 “ d e s c r i p t i o n ” : “ D i s t r i b u t o r e automatico ” ,

6 “ p o s i t i o n ” : “ Dipartimento d i In format ica , piano −1” ,

7 “ latLng ” : {“ l a t i t u d e ” : 44 . 497088 , “ l ong i tude ” : 11 . 356054 ,

8 “ promotion ” : “Promozione 2x1 in cor so ! ”}9 }

10

11 dataEncoded = base64 . b64encode ( s t r ( dataen ) )

12

13 data = {14 ”namespacedType” : ”vending−machine/ id ” ,

15 ” data ” : dataEncoded

16 }17 u r l = ” https : // proximitybeacon . g o o g l e a p i s . com/ v1beta1 / beacons

/3!36656 e64696e672d6d61123456789bac / attachments ”

18 r = r e q u e s t s . post ( ur l , data=j son . dumps( data ) , headers=headers )

Listing 5.7: Estratto del codice per la creazione di un attachment di un beacon.

Se la richiesta e andata a buon fine si ricevera come risposta un JSON contenente

gli stessi dati inviati con in aggiunta il campo attachmentName contenente il

nome assegnato al beacon.

64

Eliminazione Attachment

Per quanto riguarda gli attachment non esiste la possibilita di modifica; di con-

seguenza nel caso si volessero aggiornare i dati associati a un determinato type

(descritto nella sezione precedente) oppure eliminarli, e possibile effettuare una

richiesta DELETE all’URL contenente l’identificativo dell’attachment restituito

in fase di creazione per eliminarlo e eventualmente ricrearlo successivamente con i

nuovi dati. Per esempio per eliminare l’attachment creato nella sezione precedente

sara necessario effettuare una richiesta DELETE a https://proximitybeacon.googleapis

.com/v1beta1/beacons/3!36656e64696e672d6d61123456789bac/attachments/ddb71ff1−5d9f−491

d−b3c1−69bb108d915a.

Lista beacon e attachment

E possibile richiedere sia una lista dei beacon registrati che la lista dei singoli

attachment per ogni beacon. Per effettuare queste due richieste e necessario fare

una richiesta GET a https://proximitybeacon.googleapis.com/v1beta1/beacons e https://

proximitybeacon.googleapis.com/v1beta1/beacons/3!36656e64696e672d6d61123456789bac/attachments

/ rispettivamente. Nella seconda richiesta viene specificato il beacon, in que-

sto caso restituira gli attachment rispettivi al beacon registrato nelle sezioni

precedenti.

Per tutte queste operazioni, anche dove non e stato specificato espressamente, sara

sempre necessario autenticarsi. Nel caso dell’applicazione mobile l’autenticazione

avviene tramite una API Key inserita all’interno del codice.

5.3.2 Nearby Messages API

L’API Nearby permette di far interagire tra loro dispositivi diversi che si trova-

no nelle vicinanze. Questi dispositivi devono essere connessi a Internet, ma non

necessariamente nella stessa rete. Neaby sfrutta una combinazione di Bluetooth,

Bluetooth Low Energy, Wi-Fi e ultrasuoni per comunicare un codice di accoppia-

mento univoco fra due dispositivi. Il server facilita lo scambio di messaggi tra i

dispositivi che rilevano lo stesso codice. La sequenza seguente mostra gli eventi

che portano a uno scambio di messaggi:

65

5. IMPLEMENTAZIONE

1. Un’applicazione pubblica una richiesta di associare un payload binario (il

messaggio) con un codice univoco (token). Di conseguenza il server crea

un’associazione temporanea tra il messaggio e il token.

2. Il dispositivo che pubblica questo messaggio, utilizza una combinazione di

Bluetooth, Bluetooth Low Energy, Wi-Fi e ultrasuoni per rendere il token

rilevabile dai dispositivi nelle vicinanze. Inoltre, questo dispositivo, utiliz-

za le stesse tecnologie per fare una scansione di token in arrivo da altri

dispositivi.

3. Un’applicazione che ha fatto una sottoscrizione, la associa con un token e

utilizza le stesse tecnologie appena descritte per inviare il proprio token al

dispositivo che pubblica e per rilevare il token inviato dall’altro dispositivo.

4. Quando una delle due parti rileva il token dell’altro dispositivo, lo invia al

server.

5. Il server facilita lo scambio di messaggi fra i due dispositivi quando sono

entrambi associati con un token comune e le chiavi dell’API utilizzata dal-

le applicazioni sono associate allo stesso progetto nella Google Developers

Console.

Si tratta quindi di un tipo di API publish-subscribe che permette di trasferire

piccoli payload binari tra dispositivi connessi a Internet. Questo vuol dire che un

dispositivo pubblica un messaggio (publish) e l’altro effettua una sottoscrizione

(subscribe) dicendo che e in attesa di ricevere messaggi. I beacon sono un caso

particolare di questo meccanismo ed e possibile specificare la strategia Strategy.

BLE ONLY, al momento della sottoscrizione nell’app come mostrato nella Listing

5.8, per indicare che si vuole effettuare solo una scansione di dispositivi BLE. In

questo modo l’API non attivera una scansione Wi-Fi o Bluetooth normale, ma

solo quella Bluetooth Low Energy e questo permette di ridurre notevolmente i

tempi di scansione ed il consumo di batteria. La parte di publish viene effettuata

attraverso la Proximity Beacon API, come descritto nella Sezione 5.3.1, mentre

e possibile vedere la parte di subscribe nella Listing 5.8. Per motivi di spazio

in questa Listing viene mostrato solo lo scheletro delle funzioni e in seguito nella

66

Listing 5.9 verranno illustrate le azioni intraprese al momento della ricezione di un

messaggio, ovvero le operazioni all’interno della funzione onFound. La prima riga

mostra la creazione di un filtro, in cui viene specificato che si vogliono ricevere

solamente i messaggi provenienti dal namespace “vending-machine” con tipo “id”.

Visto che e possibile associare diversi attachment con tipi diversi, in questo modo

e possibile ricevere solo quelli rilevanti per l’applicazione. Nelle righe successive

viene creato il messageListener in cui e possibile compiere operazioni al momento

della ricezione di un messaggio o quando questo verra perso, ovvero non ci si

trovera piu all’interno del campo di emissione del beacon. Come ultima cosa

viene mostrata la sottoscrizione in cui sono specificati il filtro e il listener appena

creati e la strategia da utilizzare.

1...

2 mMessageFilter = new MessageF i l t e r . Bu i lder ( ) . includeNamespacedType ( ”

vending−machine” , ” id ” ) . bu i ld ( ) ;

3 messageLi s tener = new MessageListener ( ) {4 // Cal led each time a new message i s d i s cove r ed nearby .

5 @Override

6 pub l i c void onFound ( Message message ) {7 // message found

8 // read i t

9 }10 pub l i c void onLost ( Message message ) {11 // message l o s t

12 }13

14...

15

16 Nearby . Messages . s u b s c r i b e ( mGoogleApiClient , messageListener ,

Strategy .BLE ONLY, mMessageFilter )

17 . s e tResu l tCa l lback (new ErrorCheckingCal lback ( ” s u b s c r i b e ( ) ” ) ) ;

Listing 5.8: Estratto del codice che effettua la sottoscrizione ai messaggi Neraby

La Listing 5.9 mostra parte del contenuto della funzione onFound che viene chiama-

ta al momento della ricezione di un messaggio. Dopo aver effettuato un controllo

per accertarsi di leggere solamente la corretta tipologia di dati, viene copiato

il contenuto del messaggio in un oggetto JSON jMess. Successivamente vengo-

67

5. IMPLEMENTAZIONE

no letti i vari valori contenuti nel JSON ricevuto e inseriti negli appositi campi

dell’oggetto “beacon” creato appositamente per gestire le informazioni relative a

questi. Per esempio sono presenti la posizione del distributore, la sua descrizione,

il titolo del messaggio da visualizzare, la promozione in corso e l’URL relativa

al distributore. Questo oggetto beacon verra utilizzato dalle varie componen-

ti dell’applicazione, per esempio per visualizzare i dati relativi al distributore

automatico da cui si e ricevuto il messaggio. I dati relativi alla posizione del

distributore non vengono al momento utilizzati, si veda la Sezione 5.7.

1 i f ( message . getType ( ) . equa l s ( ” id ” ) ) {2 byte [ ] data = message . getContent ( ) ;

3 jMess = new JSONObject (new St r ing ( data ) ) ;

4 jLatLng = new JSONObject ( ) ;

5 BeaconData beacon = new BeaconData ( ) ;

6

7 i f ( jMess != n u l l ) {8 t ry {9 beacon . s e t P o s i t i o n ( jMess . g e t S t r i n g ( ” p o s i t i o n ” ) ) ;

10 beacon . s e t D e s c r i p t i o n ( jMess . g e t S t r i n g ( ” d e s c r i p t i o n ” ) ) ;

11 beacon . setPromotion ( jMess . g e t S t r i n g ( ” promotion ” ) ) ;

12 beacon . setURL ( jMess . g e t S t r i n g ( ” u r l ” ) ) ;

13 beacon . s e t T i t l e ( jMess . g e t S t r i n g ( ” t i t l e ” ) ) ;

14 jLatLng = jMess . getJSONObject ( ” latLng ” ) ;

15 beacon . s e tLa t i tude ( jLatLng . getDouble ( ” l a t i t u d e ” ) ) ;

16 beacon . setLong i tude ( jLatLng . getDouble ( ” l ong i tude ” ) ) ;

17 }18 }19 }

Listing 5.9: Estratto del codice che effettua la sottoscrizione ai messaggi Neraby

La prima volta che viene aperta l’applicazione, Nearby chiedera il permesso di

poter attivare il Wi-Fi e Bluetooth automaticamente per la fase di ricerca, come

mostrato in Figura 5.3. In questo modo anche se l’utente avra il Bluetooth disatti-

vato, quando iniziera una scansione, questo verra attivato automaticamente, sen-

za effettuare nessuna richiesta aggiuntiva, per tutta la durata di questa fase e di-

sattivato non appena si passera a una diversa attivita all’interno dell’applicazione

o se questa verra messa in background.

68

Figura 5.3: Neaby: richiesta di utilizzo Bluetooth

5.3.3 Geofencing API

Per facilitare l’individuazione dei distributori automatici, all’apertura dell’ap-

plicazione viene effettuata una richiesta al server di tutti i distributori e viene

aggiornata una lista di Geofence. In questo modo e possibile impostare delle

aree attorno al distributore automatico, individuare automaticamente quando un

utente entra in una di queste tramite l’API Geofence ed effettuare operazioni di

conseguenza. La richiesta della lista delle geofence viene fatta all’endpoint “/po-

sition”, che effettua una chiamata al database e risponde con un JSON. Nella

Listing 5.10 e possibile vedere le operazioni che vengono effettuate una volta ri-

cevuta questa lista, contenuta nell’oggetto resp. Nel database dei distributori, le

posizioni vengono salvate con l’indirizzo e quindi viene utilizzata l’API Geocoding

per trasformare questi indirizzi in coordinate GPS, necessarie per impostare una

geofence. E possibile rilevare quest’ultimo aspetto nelle prime righe del codice,

dove viene creata una nuova istanza Geocoder e viene utilizzata per richiedere le

coordinate GPS attraverso la sua funzione getFromLocationName a cui viene passato

l’indirizzo contenuto nell’oggetto appena ricevuto resp, restituito tramite la richie-

sta della stringa “posizione”. Questa stringa e ad esempio “Mura Anteo Zamboni,

7, 40126 Bologna” per il distributore relativo al Dipartimento di Informatica. Se

sono state ricevute delle coordinate GPS corrispondenti, si puo procedere alla

creazione della geofence e all’inserimento di questa nella lista comprendente tutte

69

5. IMPLEMENTAZIONE

le geofence che si vogliono creare. Per ognuna di queste viene creato un nuovo

oggetto Geofence in cui vengono impostati:

• RequestId: utilizzato per identificare la geofence, utile per quando non

sara piu necessaria e si vorra procedere all’eliminazione

• CircularRegion: attraverso i parametri latitue, longitude e

GEOFENCE RADIUS IN METERS, viene impostata l’area da “osserva-

re”. I primi due valori sono quelli ricevuti attraverso la risoluzione del-

l’indirizzo, mentre l’ultimo e definito all’interno dell’applicazione e ha un

valore di 100 metri. Questo valore e stato impostato secondo le linee guida

dell’API che suggeriscono di utilizzare un’area di queste dimensioni perche

la localizzazione essendo calcolata da piu sorgenti, ovvero Wi-Fi, rete cel-

lulare e GPS in base alle situazioni, potrebbe non essere sempre altamente

precisa e quindi con questo valore si evitano la maggior parte degli errori.

• ExpirationDuration: con questo valore si indica per quanto tempo la

geofence deve rimanere attiva. Nell’applicazione e stato impostato un valore

di 48 ore, perche comunque queste verranno aggiornate ad ogni apertura

dell’applicazione.

• TransitionTypes: e possibile impostare a quali eventi di “transizione” si

e interessati, in questo caso l’entrata e l’uscita da una geofence.

Nell’ultima riga gli identificativi delle geofence vengono salvati permanentemen-

te, in questo modo e possibile gestirle anche se l’applicazione viene chiusa e se

necessario eliminarle alla riapertura dell’applicazione o aggiornarle con i valori

nuovi ricevuti dal server.

1...

2 gcoder = new Geocoder ( g e t A c t i v i t y ( ) , Loca le . ge tDe fau l t ( ) ) ;

3 List<Address> address ;

4

5 address = gcoder . getFromLocationName ( resp . g e t S t r i n g ( ” p o s i z i o n e ” ) ,1 ) ;

6

7 i f ( address . s i z e ( ) > 0) {8 double l a t i t u d e = addre s s e s . get (0 ) . ge tLat i tude ( ) ;

9 double l ong i tude = addre s s e s . get (0 ) . getLongitude ( ) ;

70

10

11 mGeofenceList . add (new Geofence . Bu i lder ( )

12 . s e tRequest Id ( obj . g e t S t r i n g ( ”nome zona” ) )

13 . s e tC i r cu l a rReg ion (

14 l a t i t u d e ,

15 l ong i tude ,

16 GEOFENCE RADIUS IN METERS

17 )

18 . s e tExp i ra t ionDurat ion (GEOFENCE EXPIRATION IN MILLISECONDS)

19 . s e tTrans i t ionTypes ( Geofence .GEOFENCE TRANSITION ENTER |20 Geofence .GEOFENCE TRANSITION EXIT)

21 . bu i ld ( ) ) ;

22 mGeofences . put ( obj . g e t S t r i n g ( ”nome zona” ) ) ;

23 }24

...

Listing 5.10: Estratto del codice che crea una Geofence

5.4 Distributore Automatico

Per simulare l’attivita del distributore automatico, e stato utilizzato un Raspberry

Pi nel quale e inserita una chiavetta Bluetooth 4.0 che si occupa di trasmettere i

due tipi di beacon: Eddystone-URL e Eddystone-UID. Nel dettaglio sono attivi

due servizi: uno script in Python che implementa un WebSocket e uno script in

Node.js che si occupa dell’emissione dei beacon.

5.4.1 Raspberry Pi

Il Raspberry Pi e un single-board computer economico, ma completo, ideale per

lo sviluppo. Per questo progetto e stato utilizzato un Raspberry Pi 2, versione

B, che ha un processore ARM Cortex-A7. Dato che l’architettura ARMv7 e

supportata ufficialmente da Linux, sono disponibili diverse distribuzioni Linux,

al contrario del primo modello del Raspberry Pi che doveva adottare una versione

modificata di Debian. E stata quindi installata una versione di Debian minimale,

con solo le librerie necessarie per il WebSocket e lo stack Bluetooth, per renderlo

il piu performante possibile.

71

5. IMPLEMENTAZIONE

5.4.2 WebSocket

Il WebSocket, una volta ricevuta una richiesta dal client, decide in base a una

probabilita prefissata se erogare il prodotto o rifiutare la transazione. Questo

e stato previsto per simulare un guasto nel motore del distributore che eroga

il prodotto o per simulare un prodotto che si incastra e non cade. Come per

tutto il resto della piattaforma, anche in questo caso, il WebSocket deve avere

un certificato SSL valido per poter essere chiamato dal client, quindi e stato

creato un certificato personale attraverso il servizio StartSSL.[11] Nella Listing

5.11 viene mostrata una prima implementazione in cui e presente la funzione che

si occupa di decidere se erogare o meno il prodotto, decision() e quella principale

che risponde alle richieste inviate dal client, vending(), che in base alla decisione

risponde con “1”, se il prodotto e stato erogato o “0” altrimenti. In questo caso la

complessita del software eseguito dal distributore e minima e quindi si limitano le

possibilita di errori e anche la quantita di dati che deve trasferire e molto ridotta.

Con questa implementazione pero si lascia il compito di aggiornare il database sul

server al client che sta effettuando l’acquisto in quel momento e quindi si ha un

controllo limitato sull’esito dell’operazione, in quanto si potrebbero verificare, ad

esempio, problemi di connessione oppure l’utente potrebbe effettuare una chiusura

forzata dell’applicazione e lasciare il database non sincronizzato con l’effettiva

disponibilita del distributore.

1 de f d e c i s i o n ( ) :

2 num = random . random ( )

3 re turn num < 0 .85

4

5 @asyncio . co rout ine

6 de f vending ( websocket , path ) :

7 re sponse = {}8 name = y i e l d from websocket . recv ( )

9 p r o d u c t l i s t = j son . l oads (name)

10 prodo t t i = p r o d u c t l i s t [ “ p rodo t t i ” ]

11 p o s i z i o n i = p r o d u c t l i s t [ “ p o s i z i o n e ” ]

12

13 f o r key , item in enumerate ( p rodo t t i ) :

14 i f d e c i s i o n ( ) :

15 #prodotto erogato

72

16 re sponse . s e t d e f a u l t ( s t r ( item ) ,1 )

17 e l s e :

18 #prodotto NON erogato

19 re sponse . s e t d e f a u l t ( s t r ( item ) ,0 )

20

21 y i e l d from websocket . send ( j son . dumps( re sponse ) )

Listing 5.11: Estratto del codice Python del servizio WebSocket nel distributore

Per questo lo script e stato rivisto aggiungendo la chiamata diretta al server da

parte del distributore. Nella Listing 5.12 si possono vedere le differenze rispetto

alla prima implementazione. Come prima cosa viene creata una lista di prodotti

che verranno inviati al server e successivamente viene popolata dai prodotti ero-

gati. Nel caso il prodotto non venga erogato viene creato un dizionario che sara

restituito al client. Se sono stati erogati dei prodotti, viene creato il JSON da

inviare al database sul server, contenente tre parametri:

• upload type: il tipo di operazione che si vuole effettuare, in questo caso

un aggiornamento delle quantita dei prodotti

• machine: l’identificativo del distributore sul quale si vuole effettuare l’o-

perazione

• id prodotto: una lista dei prodotti da aggiornare

Viene quindi effettuata una chiamata POST che ha come parametri l’URL del-

l’endpoint, specificato all’inizio di questa Listing e la struttura dati appena creata.

Come risposta si ricevera un JSON contenente la lista dei prodotti appena inviati

e le rispettive quantita aggiornate. Questa lista viene unita a quella dei prodotti

non erogati, che per essere identificati avranno una quantita di “-1”. Se invece

sono presenti solo prodotti non erogati verranno copiati direttamente nella varia-

bile da inviare al client. L’ultima riga, come nella Listing precedente mostra la

risposta che viene inviata al client alla fine di tutto questo processo.

1 p r o d o t t i S e r v e r = [ ]

2 u r l = “ https : // vending−machine . appspot . com/ postdata ”

3

4 f o r key , item in enumerate ( p rodo t t i ) :

73

5. IMPLEMENTAZIONE

5 i f d e c i s i o n ( ) :

6 #prodotto erogato

7 p r o d o t t i S e r v e r . append ( item )

8 e l s e :

9 #prodotto NON erogato

10 re sponse . s e t d e f a u l t ( s t r ( item ) ,−1)

11

12 i f p r o d o t t i S e r v e r :

13 data = {“ upload type ” : “update” ,

14 “machine” : idMachine ,

15 “ id p rodo t to [ ] ” : p r o d o t t i S e r v e r }16 serverResp = r e q u e s t s . post ( ur l , data=data )

17 ServerJson = json . l oads ( serverResp . t ex t )

18 f i n a l R e s u l t = se rve rJ son . copy ( )

19 f i n a l R e s u l t . update ( re sponse )

20 e l s e :

21 f i n a l R e s u l t = response

22

23 y i e l d from websocket . send ( j son . dumps( f i n a l R e s u l t ) )

Listing 5.12: Estratto del codice Python del servizio WebSocket nel distributore,

con aggiornamento diretto del server

Andrebbe valutato, soprattutto in base alla connessione a Internet presente sul

distributore, ma anche all’hardware disponibile, quale soluzione e opportuno

adottare.

5.4.3 Broadcast del beacon

Per la componente che si occupa di creare i beacon e stato scelto di realizzare

lo script in Node.js in quanto sono disponibili delle librerie per interagire con

il Bluetooth e creare i vari parametri di advertising dell’Eddystone-URL. Que-

ste sono facilmente utilizzabili nel Raspberry Pi, infatti e sufficiente utilizzare il

gestore dei pacchetti npm, attraverso il comando npm install eddystone−beacon per

installare la libreria necessaria per trasmettere il segnale, che a sua volta si oc-

cupera di installare tutte le dipendenze necessarie.[6] Come si puo vedere nella

Listing 5.13, nello script sara necessario richiedere la libreria e poi utilizzare la

funzione per trasmettere l’URL.

74

1 var eddystoneBeacon = r e q u i r e ( ’ eddystone−beacon ’ ) ;2

3 var opt ions = {4 txPowerLevel : −22 // o v e r r i d e TX Power Level , d e f a u l t va lue i s

−21,5 tlmCount : 2 , // 2 TLM frames6 t lmPeriod : 10 // every 10 advert i s ements7 } ;8

9 u r l = ’ https : // goo . g l /WVBu4W’10 eddystoneBeacon . a d v e r t i s e U r l ( ur l , [ opt i ons ] ) ;

Listing 5.13: Codice di esempio che trasmette il beacon URL

1 var namespaceId = ’ 36656 e64696e672d6d61 ’ ;2 var in s t a nc e Id = ’ 123456789 bac ’ ;3

4 eddystoneBeacon . adver t i s eU id ( namespaceId , in s tance Id , [ opt i ons ] ) ;

Listing 5.14: Codice di esempio che trasmette il beacon UID

La funzione advertiseUrl accetta come input due parametri: l’URL da tra-

smettere e le opzioni. Il primo parametro delle opzioni riguarda il livello di po-

tenza della trasmissione, di default a -21. Il secondo e il terzo parametro servono

per impostare rispettivamente quanti frame TLM inviare e ogni quanto. Questi

frame, che come gia accennato sono di diagnostica del beacon, vengono interval-

lati a quelli che trasmettono l’URL e in questo caso si hanno 2 frame TLM ogni

10 frame URL. Nell’implementazione sono stati utilizzati i valori di default, quin-

di l’ultima riga diventera eddystoneBeacon.advertiseUrl(“https://goo.gl/WVBu4W”);. In

modo simile e possibile creare un broadcast per l’Eddystone-UID utilizzato al-

l’interno dell’applicazione Android. Nella Listing 5.14 e possibile vedere la parte

di codice che si occupa di effettuare questa operazioni. A differenza del beacon

Eddystone-URL, per quello UID e necessario specificare degli identificativi per il

namespace e per l’istanza, che in questo caso sono rispettivamente un hash del

dominio utilizzato per il sito web e una stringa casuale. Questi vengono passati

come parametri alla funzione adverdiseUid,che si occupera di creare il broadcast

dell’UID, aggiungendo se necessario delle opzioni come per la Listing 5.13.

75

5. IMPLEMENTAZIONE

5.5 Utilizzo delle applicazioni - Casi d’uso

In questa sezione verranno illustrati i casi d’uso per l’applicazione web e quella

nativa e descritte le loro varie componenti. Le motivazioni principali per lo svi-

luppo di queste applicazioni sono quelle di poter scoprire gli oggetti connessi a

Internet e di poter interagire con esse.

5.5.1 Scoperta di un beacon

Questa fase utilizza due approcci diversi. L’applicazione nativa deve essere aperta

e iniziata una fase di scansione, dal momento che non e possibile utilizzare le

API Nearby Message quando l’applicazione e in background, ma e stato dato per

scontato che se l’utente ha installato l’applicazione e a conoscenza della possibilita

di individuare distributori automatici e quindi la aprira nel momento del bisogno.

Per l’applicazione web, sia utilizzando l’applicazione di test per Android, che la

funzionalita gia integrata di iOS, si vedra comparire un messaggio all’interno

dell’area notifiche.

Applicazione web

L’utente riceve una notifica nel menu a tendina del proprio dispositivo mobile solo

quando lo schermo viene acceso e viene aperto il centro notifiche nelle vicinanze

di un distributore, ovvero di un beacon Bluetooth, come mostrato in Figura

5.4a. Nel caso di iOS verra visualizzato come mostrato in Figura 5.4b all’interno

della sezione Chrome. Ogni beacon ha la URL che punta al contenuto di quel

distributore, quindi aprendo la notifica si viene indirizzati alla pagina con la lista

di tutti i prodotti presenti (Figura 5.8a).

Applicazione Android

All’apertura dell’applicazione, come mostrato in Figura 5.5a, viene richiesto di

effettuare uno swipe per iniziare lo scan dei beacon; questo perche una delle

best practice suggerite per l’uso dell’API e quello di non iniziare operazioni di

ricerca se non espressamente richiesto dall’utente. Effettuando lo swipe si inizia la

ricerca, mostrata in Figura 5.5b e non appena viene individuato il primo beacon si

76

(a) Web app Android (b) Web app iPhone

Figura 5.4: Scoperta di un beacon in Android e iOS

passa alla schermata in Figura 5.5c, dove vengono popolati i vari campi presenti

nel messaggio ricevuto. In questo caso il messaggio era quello dell’attachment

registrato nella Listing 5.7. Nell’applicazione Android si ha un maggior controllo

su quali elementi visualizzare quando si trova un beacon rispetto alla soluzione

dell’applicazione web, che richiede automaticamente solo la stringa contenuta nel

manifest del sito web. Infatti e possibile associare qualsiasi tipo di dato al beacon

e la visualizzazione e completamente gestita dall’applicazione.

5.5.2 Ricezione di una notifica push

Un altro caso d’uso si ha quando l’utente riceve una notifica push. Nella Figura

5.6 e possibile vederne la ricezione per la web app. All’utente verranno mostrati i

campi Titolo e Corpo, come descritti in 5.2.3, completamente personalizzabili. In

questo caso non sara possibile avere dei criteri in base a cui riceverle, in quanto

non sono ancora disponibili meccanismi per creare delle geofence (Sezione 5.6.1) e

quindi non e possibile sapere se l’utente si trova nelle vicinanze di un distributore.

Sara quindi necessario utilizzare un’apposita pagina da far visualizzare all’utente

77

5. IMPLEMENTAZIONE

(a) Schermata iniziale (b) Ricerca del beacon (c) Beacon trovato

Figura 5.5: Scoperta di un beacon nell’applicazione Android

quando apre la notifica, contenente per esempio la lista delle promozioni in corso

e in cui si specifica che si deve ricercare il distributore. In futuro come spiegato

nella Sezione 5.6.2 sara possibile inoltre controllare che l’utente sia effettivamen-

te davanti al distributore facendo una scansione direttamente all’interno della

pagina.

5.5.3 Entrata in una Geofence

L’utilizzo delle geofence e al momento possibile soltanto nell’applicazione An-

droid. L’informazione dell’entrata in una geofence viene utilizzata per visualiz-

zare una notifica sulla presenza di un distributore nelle vicinanze e l’utente viene

invitato ad aprire l’applicazione per avere maggiori informazioni. Nella Figura 5.7

viene mostrato un esempio di notifica. Aprendo la notifica si arrivera alla vista

della ricerca del beacon cosı da essere sicuri che l’utente sia abbastanza vicino da

individuare il distributore automatico.

78

Figura 5.6: Notifica push Web Application

Figura 5.7: Esempio di notifica all’entrata in una Geofence

79

5. IMPLEMENTAZIONE

(a) Vista principale Web Application (b) Vista principale in Android

Figura 5.8: Home per Android e Web Application

5.5.4 Apertura dell’applicazione

In tutti i casi precedentemente descritti, ad eccezione del caso delle notifiche push

per la web application, come risultato si arriva all’apertura dell’applicazione in cui

vengono mostrati i prodotti disponibili per quel distributore. Quindi dopo aver

trovato un beacon, aver ricevuto una notifica o essere entrati in una geofence, si

vedra la pagina principale mostrata in Figura 5.8a per la web application e 5.8b

per l’applicazione Android.

Applicazione web

Per quanto riguarda l’applicazione web, nella Figura 5.9a viene visualizzato un

esempio di messaggio che puo essere mostrato all’utente, un toast, un piccolo pop-

up per dare un feedback o fornire informazioni. In questo caso viene informato

l’utente che tenendo premuto su un prodotto potra visualizzare le informazioni

nutrizionali e gli ingredienti di quest’ultimo. Questa azione viene mostrata in

Figura 5.9b, dove viene creato un pop-up contenente tutti i dati relativi al pro-

dotto. In Figura 5.9c e possibile invece vedere come facendo un “tap” su uno o piu

80

(a) Esempio di toast allaprima apertura

(b) Informazioni relativeal prodotto

(c) Bottone carrello percomprare

Figura 5.9: Insieme di immagini dell’applicazione web

prodotti vengono selezionati e compare un bottone con cui e possibile finalizzare

l’acquisto.

Nella Figura 5.11e viene visualizzata la richiesta di aggiungere la pagina alla

homescreen. Questa richiesta viene gestita automaticamente dal browser, se sono

presenti i campi all’interno del manifest della pagina, e viene proposta dopo che

la pagina viene visitata per almeno due volte in un certo intervallo di tempo.

Ovviamente sara sempre possibile aggiungere la pagina manualmente alla home-

screen dal menu di Chrome, con lo stesso risultato, ma in questo modo si pone

l’utente a conoscenza della possibilita ottenendo un maggior coinvolgimento. Se

si decide di aggiungere la pagina alla homescreen, come mostrato in 5.11f viene

creata un’icona come se fosse un’applicazione nativa e una volta aperta si ha

l’impressione che questa lo sia, in quanto non compare neanche piu la barra di

navigazione del browser. La pagina che verra aperta da quell’icona e impostata

lato server all’interno del manifest, normalmente si apre la home page, ma non

essendo rilevante in questo contesto perche dipendente dal beacon nelle vicinanze,

e possibile aprire per esempio una pagina delle promozioni o in futuro una ricer-

81

5. IMPLEMENTAZIONE

ca dei beacon, quando le API del Web Bluetooth saranno completate (Sezione

5.6.2).

Applicazione Android

In modo simile all’applicazione web, e presente un menu che si puo aprire sia effet-

tuando uno swipe dall’estremita sinistra del display oppure premendo l’hamburger

menu in alto a sinistra. Nella Figura 5.10a e possibile vedere il menu dell’applica-

zione aperto. La prima parte mostra un ipotetico profilo con cui si e autenticati.

La seconda opzione “Nearby Beacons” riporta alla schermata iniziale di ricerca

del beacon vista in 5.5a, dove e possibile cercare i distributori automatici nelle

vicinanze. La voce preferenze non e al momento utilizzata, le possibili implemen-

tazioni verranno affrontate nella Sezione 5.7.2. L’ultima voce porta a una pagina

di informazioni generali sull’applicazione. Successivamente viene mostrato un

esempio di come vengono visualizzate le varie richieste mentre vengono esegui-

te nella Figura 5.10b e di messaggio di avvenuta erogazione del prodotto nella

Figura 5.10c. In modo simile questi messaggi toast vengono utilizzati anche per

gli eventuali errori, per esempio alla mancata erogazione del prodotto. Inoltre

effettuando uno swipe dall’alto verso il basso e possibile aggiornare manualmente

la lista dei prodotti.

5.5.5 Rifornimento distributore

Questa parte e stata implementata solamente nella web application, principal-

mente perche non rilevante per la user experience degli utenti, che viene parago-

nata fra le due implementazioni. Nella 5.11a e possibile vedere il menu laterale

che compare toccando l’hamburger menu oppure facendo uno swipe dall’estremita

sinistra del display. Qui e possibile vedere le varie pagine presenti per rifornire il

distributore o caricare nuovi prodotti nel database, un toggle che mostra se le no-

tifiche push sono attive o meno e un link per il login (si veda 5.6.3). Nella Figura

5.11b viene mostrata la prima pagina per rifornire il distributore, che mostra i

prodotti che erano presenti ma esauriti in modo da poter rifornire velocemente,

visto che raramente vengono cambiati i prodotti all’interno di un distributore, e i

prodotti con ancora una disponibilita per poterne aumentare il numero. Premen-

82

(a) Menu delle opzioni perAndroid

(b) Esempio di richiesta incorso

(c) Esempio di toast all’e-rogazione

Figura 5.10: Insieme di immagini dell’applicazione Android

do l’immagine a forma di “+” e possibile aggiungere prodotti che non sono mai

stati inseriti all’interno di quel distributore e viene aperta una pagina come quella

della Figura 5.11c. Infine l’ultima pagina presente e quella per aggiungere un pro-

dotto nuovo all’interno del database, come mostrato in Figura 5.11d. In questo

caso quindi verranno chiesti il nome del prodotto, il produttore, la tipologia di

prodotto e un’immagine da associarvi.

5.6 Sviluppi futuri - Web Application

Come gia detto tutte queste tecnologie sono nel pieno del loro sviluppo e quindi

vengono aggiunte continuamente nuove API e funzionalita. Tra le piu interes-

santi e rilevanti per questa applicazione troviamo: Gefencing e Web Bluetooth.

Un’ulteriore possibile estensione potrebbe essere effettuata aggiungendo i profili

utente.

83

5. IMPLEMENTAZIONE

(a) Menu delle opzionidisponibili

(b) Pagina di rifornimentocon prodotti gia utilizzati

(c) Pagina di rifornimentocon prodotti nuovi

(d) Pagina per caricare unnuovo prodotto

(e) Richiesta di aggiuntaalla homescreen

(f) Icona come applicazio-ne nativa

Figura 5.11: Secondo insieme di immagini dell’applicazione web

84

5.6.1 Geofencing

Un’estensione dell’API geolocation gia presente all’interno del browser, permette

di creare delle zone da “osservare” e di scatenare eventi nel momento in cui l’u-

tente entra in una di queste. Questa API, che sara disponibile attraverso i Service

Worker, permettera allo sviluppatore di accedere alla posizione anche dopo che la

Web Application verra chiusa, per questo ci sono importanti problemi di privacy

che devono essere presi in considerazione e sono ancora in fase di decisione le

precauzioni da intraprendere. Quando questa API sara disponibile, per esempio,

sara possibile inviare notifiche agli utenti solo se si trovano in determinate zone e

questo risulta molto utile per questa applicazione, in quanto sara possibile inviare

notifiche mirate solo agli utenti vicino a un distributore, senza disturbare gli altri.

5.6.2 Web Bluetooth

L’API Web Bluetooth permette di interagire con dispositivi Bluetooth diretta-

mente da una pagina web. Per motivi di sicurezza questa connessione puo essere

iniziata solo attraverso l’azione dell’utente, come per esempio la pressione di un

bottone. Questa API e al momento disponibile solo in Chrome 45 su Chrome

OS (canale beta) e in Chrome 46 per Android, attualmente nel canale dev, ma

comunque non e attiva di default e va impostato un flag. Attualmente sono state

implementate funzionalita per ricevere informazioni base, ma quella piu interes-

sante per questa applicazione, cioe di poter leggere i dati di Advertising di un

beacon, non e ancora presente. In futuro inoltre, a specifica ultimata, sara possi-

bile connettersi direttamente con i dispositivi e si potranno quindi scambiare dati

direttamente con il distributore.

5.6.3 Profilo utente

Come sviluppo futuro dell’applicazione si potra aggiungere la possibilita di ef-

fettuare un Login, permettendo quindi di avere un proprio profilo, attraverso il

quale vengono proposte offerte personalizzate o ordinati i prodotti all’interno del

distributore in base alle preferenze. In questa area inoltre sara possibile salvare

le proprie preferenze di pagamento.

85

5. IMPLEMENTAZIONE

5.7 Sviluppi futuri applicazione Android

Come per l’applicazione web si potrebbe prevedere l’implementazione di un profilo

utente dove salvare le preferenze dei prodotti, per esempio per proporre promozio-

ni mirate oppure programmi di fidelizzazione. Inoltre grazie soprattutto alle API

presenti in Android, si potrebbero prevedere funzionalita aggiuntive per esempio

grazie al posizionamento.

5.7.1 Posizionamento

Attraverso l’utilizzo degli attachment nei beacon Eddystone-UID e possibile ri-

cevere all’interno dell’applicazione qualsiasi tipo di informazione. Al momento

vengono associate le coordinate GPS del distributore e con questa informazio-

ne si potrebbe visualizzare una mappa che mostri la posizione del distributore e

dell’utente e le indicazioni per raggiungerlo, cosı da poterlo indirizzare al punto

esatto. In modo simile, visto che l’applicazione scarica la lista delle geofence, e

quindi delle posizioni dei distributori, si potrebbe mostrare una mappa visualiz-

zando tutti i distributori nella zona. Queste funzionalita possono essere sfruttate

dalla Google Places API, vista anche la presenza di un identificativo del luogo

all’interno del beacon.

5.7.2 Preferenze

Nella sezione preferenze, oltre alle impostazioni generali dell’applicazione, potreb-

bero essere presenti delle impostazioni per le modalita di ricezione delle notifiche,

per esempio per filtrare solamente i distributori da cui si vogliono ricevere pro-

mozioni. Inoltre qui troverebbero luogo le impostazioni riguardati il profilo e le

modalita di pagamento ad esso associate.

86

Capitolo 6

Conclusioni

La costante evoluzione tecnologica sta portando alla luce nuove possibilita, che

un tempo non erano nemmeno immaginabili. Uno dei settori che si e rivoluzio-

nato maggiormente negli ultimi anni e quello delle telecomunicazioni e questo

ha portato sia a una riduzione dei costi per le connessioni a Internet, sia ad un

aumento delle loro capacita e prestazioni; di conseguenza queste connessioni sono

diventate piu accessibili e affidabili permettendo alle persone e alle cose di accede-

re a Internet quasi ininterrottamente. Grazie agli sviluppi attualmente in corso,

principalmente legati all’introduzione del protocollo IPv6 per l’assegnazione degli

indirizzi su Internet, a breve sara inoltre possibile raggiungere direttamente ognu-

no di questi dispositivi connessi, in qualsiasi parte del mondo esso sia. In questo

modo si potra collegare qualsiasi tipo di oggetto a Internet e trarne i benefici che

questo comporta, ad esempio: la possibilita di ricevere aggiornamenti costanti

sullo stato dei sensori all’interno di un oggetto, aggregare e interpretare i dati

per avere una comprensione migliore delle dinamiche all’interno di un’azienda o

ancora far eseguire ad essi delle azioni in base ad eventi, siano essi innescati da

delle persone o da altri oggetti.

Nel presente elaborato, dopo aver analizzato lo stato dell’arte, i benefici, le

problematiche e gli attuali interessi da parte di alcuni dei maggiori player verso

l’Internet of Things e stata analizzata in particolare la necessita di individuare e

a controllare la miriade di dispositivi connessi, destinati ad aumentare esponen-

zialmente nei prossimi anni. E stato quindi individuato e analizzato il progetto

“Physical Web”, che si pone come obbiettivi proprio quelli di risolvere queste

87

6. CONCLUSIONI

problematiche. Questo progetto ancora in via sperimentale, sebbene guidato da

Google, e open source e non brandizzato e viene proposto come standard, nella

speranza venga adottato dai diversi produttori di software e hardware. La so-

luzione proposta dal Physical Web prevede la creazione di un ecosistema dove

gli oggetti smart possano trasmettere URL nell’area intorno a loro. Questo puo

essere effettuato ad esempio mediante l’utilizzo di beacon Bluetooth che trasmet-

tono un identificativo dell’oggetto (l’URL) che e possibile aprire con un normale

browser. Infatti questo progetto si ripropone di sfruttare le potenzialita offerte

dal web e di estenderle al modo fisico attorno a noi, permettendo ad ogni oggetto

che dispone di un display, come un tablet o uno smartphone nelle vicinanze di

intercettare questo URL, interpretarlo e mostrarlo all’utente.

Sono state quindi realizzate ad hoc tutte le componenti necessarie per creare

questo ecosistema e analizzate nell’utilizzo applicate a delle vending machines.

Dopo aver implementato la componente che si occupa di inviare l’URL tramite

il protocollo Eddystone-URL, e stata gestita e creata tutta la parte di interazio-

ne con l’utente, che avviene in seguito all’individuazione del beacon, attraverso

un’interfaccia web.

Infine, essendo queste tecnologie ancora nel pieno dello sviluppo, sono state

paragonate ad altre piu mature, sempre facenti parte della piattaforma becon di

Google. E stata implementata un’applicazione Android, che attraverso l’utilizzo

degli Eddystone-UID individua i beacon e presenta le informazioni del distributore

automatico associate. Questa applicazione e stata infine paragonata nelle sue

funzionalita all’applicazione web.

Da questo confronto si e potuto constatare come le tecnologie web, anche

se molto promettenti, non siano ancora completamente pronte per un utilizzo

nel prossimo futuro, soprattutto per la mancanza di integrazione di componenti

per la ricerca dei beacon. Al contrario l’applicazione Android risulta sfruttare

tecnologie piu mature e quindi su cui e possibile fare maggiore affidamento.

In virtu dell’immediatezza di queste tecnologie e degli innumerevoli sbocchi

potenziali si ipotizza un’adesione crescente, visto anche l’interesse dimostrato da

sempre piu soggetti e sviluppatori. Si puo inoltre immaginare che questi ostacoli

si supereranno nel breve periodo, grazie anche alla rapidita di evoluzione delle

tecnologie, portando ad una diffusione nei settori piu disparati.

88

Bibliografia

[1] The cloud market. URL http://thecloudmarket.com/. 18

[2] Docker. URL https://www.docker.com/. 17

[3] Apple. ibeacon for developers. URL https://developer.apple.com/

ibeacon/. 39, 41

[4] Masinter & McCahill Berners-Lee. Rfc1738. URL https://www.ietf.org/

rfc/rfc1738.txt. 34

[5] Cisco. Cisco global cloud index: Forecast and methodology, 2013–2018.

URL http://www.cisco.com/c/en/us/solutions/collateral/

service-provider/global-cloud-index-gci/Cloud_Index_White_

Paper.pdf. 22

[6] Don Coleman. Create an eddystone beacon using node.js. URL https:

//github.com/don/node-eddystone-beacon. 74

[7] Barb Edson. Creating the internet of your things.

URL http://download.microsoft.com/download/C/F/7/

CF78575B-711E-4E1B-8BAB-3ED1657DFA82/Creating_the_Internet_

of_Your_Things.pdf. 8

[8] Google. Specification for eddystone, an open beacon format from google.

URL https://github.com/google/eddystone. 33, 34, 35, 36, 37

[9] Intel. The intel R© iot platform: Secure, scalable, interopera-

ble. URL https://www-ssl.intel.com/content/www/us/en/

internet-of-things/iot-platform.html. 19

89

http://thecloudmarket.com/

https://www.docker.com/

https://developer.apple.com/ibeacon/

https://developer.apple.com/ibeacon/

https://www.ietf.org/rfc/rfc1738.txt

https://www.ietf.org/rfc/rfc1738.txt

http://www.cisco.com/c/en/us/solutions/collateral/service-provider/global-cloud-index-gci/Cloud_Index_White_Paper.pdf



https://github.com/don/node-eddystone-beacon

https://github.com/don/node-eddystone-beacon

http://download.microsoft.com/download/C/F/7/CF78575B-711E-4E1B-8BAB-3ED1657DFA82/Creating_the_Internet_of_Your_Things.pdf



https://github.com/google/eddystone

https://www-ssl.intel.com/content/www/us/en/internet-of-things/iot-platform.html

https://www-ssl.intel.com/content/www/us/en/internet-of-things/iot-platform.html

BIBLIOGRAFIA

[10] Doug Handler Joseph Bradley, Joel Barbier. Embracing the internet of eve-

rything to capture europe’s share of $14.4 trillion. 2013. 24, 25, 26, 27, 28,

29

[11] Start Commercial Limited. Startcom certificate policy & practice statements.

URL https://www.startssl.com/policy.pdf. 72

[12] J Manyika, M Chui, J Bughin, R Dobbs, P Bisson, and A Marrs. Disruptive

technologies: Advances that will transform life. Business, and the Global

Economy, 2013. 5, 7, 8, 10, 11, 24

[13] Microsoft. Guide to universal windows platform (uwp) apps. URL https://

msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx. 13

[14] Radius Networks. Android beacon library. URL http://altbeacon.

github.io/android-beacon-library. 43

[15] Bluetooth Developer Portal. Tx power level. URL https://developer.

bluetooth.org/gatt/characteristics/Pages/CharacteristicViewer.

aspx?u=org.bluetooth.characteristic.tx_power_level.xml. 34

[16] Bluetooth SIG Proprietary. Supplement to the bluetooth core specifica-

tion. URL https://www.bluetooth.org/DocMan/handlers/DownloadDoc.

ashx?doc_id=291904. 32, 33

[17] World Wide Web Technology Surveys. Usage statistics and market share

of linux for websites. URL http://w3techs.com/technologies/details/

os-linux/all/all. 14

[18] Doug Thompson. Apple cracks down on ibeacon for android. URL http:

//beekn.net/2014/07/ibeacon-for-android/. 42

[19] Ubuntu. Snappy, . URL https://developer.ubuntu.com/en/snappy/. 16,

17, 18

[20] Ubuntu. Intel and canonical collaborate around iot ga-

teways, . URL https://insights.ubuntu.com/2015/06/02/

intel-and-canonical-collaborate-around-iot-gateways/. 18

90

https://www.startssl.com/policy.pdf

https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx

https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx

http://altbeacon.github.io/android-beacon-library

http://altbeacon.github.io/android-beacon-library

https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicViewer.aspx?u=org.bluetooth.characteristic.tx_power_level.xml



https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=291904

https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=291904

http://w3techs.com/technologies/details/os-linux/all/all

http://w3techs.com/technologies/details/os-linux/all/all

http://beekn.net/2014/07/ibeacon-for-android/

http://beekn.net/2014/07/ibeacon-for-android/

https://developer.ubuntu.com/en/snappy/

https://insights.ubuntu.com/2015/06/02/intel-and-canonical-collaborate-around-iot-gateways/

https://insights.ubuntu.com/2015/06/02/intel-and-canonical-collaborate-around-iot-gateways/

BIBLIOGRAFIA

[21] Ubuntu. Ubuntu core on the internet of things, . URL http://www.ubuntu.

com/internet-of-things/. 18

91

http://www.ubuntu.com/internet-of-things/

http://www.ubuntu.com/internet-of-things/

Vending Machines avanzate basate su principi di Physical ... · ed e previsto che questo fenomeno...

Documents

Transcript of Vending Machines avanzate basate su principi di Physical ... · ed e previsto che questo fenomeno...