D1.1.1 - IoT_|_ToI. - Istituto Superiore Mario Boella

Transcript

D1.1.1 - IoT_|_ToI. - Istituto Superiore Mario Boella
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
IoT_|_ToI
POR F.E.S.R. 2007/2013
DELIVERABLE
WP1 – GESTIONE E COORDINAMENTO
D1.1.1 – DESCRIZIONE PROGETTO
Numero Deliverable:
D1.1.1
Numero WP:
1
Titolo WP:
Numero Task:
1.1- 1.7
Titolo Task:
Redatto da:
Data di consegna
prevista:
Nome file:
GESTIONE E COORDINAMENTO
M. De Gennaro (Magneti Marelli)
15/04/2012
Data di consegna
effettiva:
D1.1.1.docx
Livello di riservatezza (PU; RE; CO; EC):
PU
Stato documento (F: final; D: draft; RD: revised
draft):
F
Data di inizio progetto e durata:
D1.1.1.docx
15/04/2012
01/04/2012 , due anni
Versione:
1.0
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
Indice
Indice ........................................................................................................................2
Lista Tabelle ............................................................................................................4
Introduzione - sintesi della proposta progettuale ..............................................5
1.
Idea e motivazioni alla base del progetto, problematica affrontata e
obiettivi generali .....................................................................................................6
2.
Coerenza, sinergia e grado di integrazione rispetto alla TP/LS di
appartenenza e al piano generale di attività del Polo ...................................... 13
3. Stato dell’arte scientifico-tecnologico ........................................................... 14
4. Innovazioni perseguite nel progetto .............................................................. 15
5. Sostenibilità tecnico-economica .................................................................... 17
3.6 Integrazione con altre iniziative ed evoluzioni future ................................ 19
La proposta di progetto copre diversi campi di attività che sono collegabili
a progetti tuttora in corso o precedentemente sviluppati dalle società
partecipanti. ........................................................................................................... 19
Un ulteriore sviluppo, di più lungo termine, è dato dalle comunicazioni
Vehicle to Grid (V2G). In questo paradigma i veicoli comunicano con
l’infrastruttura di gestione dell’energia elettrica per il coordinamento della
produzione/immagazzinamento dell’energia elettrica. Le macchine ibride
possono infatti produrre energia necessaria alla rete in caso di un picco di
richiesta che non può essere soddisfatta; viceversa i veicoli elettrici
possono fungere da accumulatori di energia in avanzo sulla rete. Tutte
queste operazioni hanno la necessità di una comunicazione real-time tra la
rete (grid) ed il veicolo che possono essere abilitate grazie agli studi che
verranno effettuati nel progetto. ......................................................................... 19
3.7 Modalità di management e controllo del progetto ..................................... 19
3.8 Ricadute, impatti attesi e diffusione/applicabilità dei risultati ................. 20
4.2 Eventi di verifica del progetto ....................................................................... 21
4.3 Descrizione del progetto attraverso Work Packages ................................ 22
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
Lista Figure
Figura 1. V- model per IoT_|_ToI .................Errore. Il segnalibro non è definito.
Figura 2. Test Site del Progetto IoT_|_ToI ...Errore. Il segnalibro non è definito.
Figura 3. Disposizione dei parcheggi lungo l’area del Test Site del Progetto
IoT_|_ToI......................................................Errore. Il segnalibro non è definito.
Figura 4. Posizionamento antenne di comunicazione V2X ... Errore. Il segnalibro
non è definito.
Figura 5. Posizionamento delle telecamere .Errore. Il segnalibro non è definito.
Figura 6. Posizionamento delle sonde ambientali ...... Errore. Il segnalibro non è
definito.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
Lista Tabelle
Tabella 1. Modello di Caso d’uso .................Errore. Il segnalibro non è definito.
Tabella 2. CU1.0.1 - Collezione dati di nodi IoT fissi e mobili da parte del CCT
.....................................................................Errore. Il segnalibro non è definito.
Tabella 3. CU 1.0.2 - Richiesta di parcheggi liberi ..... Errore. Il segnalibro non è
definito.
Tabella 4. CU 1.0.3 - Invio tempi di rosso / verde dei semafori ................ Errore. Il
segnalibro non è definito.
Tabella 5. CU 1.0.4 - Informazioni dello stato del traffico...... Errore. Il segnalibro
non è definito.
Tabella 6. CU 2.1.1 - Rilevamento dello stato delle sorgenti di luce di un
semaforo ......................................................Errore. Il segnalibro non è definito.
Tabella 7. CU 2.1.2 - Rilevamento dello stato di un semaforo ................. Errore. Il
segnalibro non è definito.
Tabella 8. CU 2.1.3 - Rilevamento dello stato dei parcheggi discreti ....... Errore. Il
segnalibro non è definito.
Tabella 9. CU 2.1.4 - Rilevamento dello stato dei parcheggi continui ...... Errore. Il
segnalibro non è definito.
Tabella 10. CU 2.1.5 - Rilevamento dello stato delle corsie (Eventi Elementari)
.....................................................................Errore. Il segnalibro non è definito.
Tabella 11. CU 2.1.6 - Rilevamento dello stato delle corsie (Eventi Dedotti)
.....................................................................Errore. Il segnalibro non è definito.
Tabella 12. CU 2.2.1 - Misurazione e invio dati concentrazioni inquinanti da
postazioni fisse ............................................Errore. Il segnalibro non è definito.
Tabella 13. CU 2.2.2 - Misurazione e invio dati concentrazioni inquinanti da
postazioni mobili ..........................................Errore. Il segnalibro non è definito.
Tabella 14. CU 2.3.1 - Stima della densità del traffico veicolare ............. Errore. Il
segnalibro non è definito.
Tabella 15. CU 2.3.2 - Trasferimento dati V2V (Bidirezionale) ................ Errore. Il
segnalibro non è definito.
Tabella 16. CU 2.3.3 - Trasferimento dati V2I (Bidirezionale) .................. Errore. Il
segnalibro non è definito.
Tabella 17. CU 2.4.1 - Collezione dati da veicoli (Posizione, Velocità,
Accelerazione, ecc.).....................................Errore. Il segnalibro non è definito.
Tabella 18. CU 2.4.2 - Collezione dati di terra e immagini (Parcheggi, Traffico,
Semafori) .....................................................Errore. Il segnalibro non è definito.
Tabella 19. CU 2.4.3 - Collezione dei dati derivati e relativi alla gestione dei dati,
con elenco comunicazioni, ricalcoli, valori statistici, disponibilità ed affidabilità del
sistema ........................................................Errore. Il segnalibro non è definito.
Tabella 20. CU 2.5.1 - Correzione del posizionamento del nodo IoT ....... Errore. Il
segnalibro non è definito.
Tabella 21. CU 2.6.1 - Ricerca parcheggi liberi in area definita dalla posizione
vettura richiedente .......................................Errore. Il segnalibro non è definito.
Tabella 22. CU 2.6.2 - Individuazione stato semaforico e invio ai veicoli di
aggiornamenti ..............................................Errore. Il segnalibro non è definito.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
Tabella 23. CU 2.6.3 - Segnalazione di stato traffico . Errore. Il segnalibro non è
definito.
Tabella 24. CU 2.7.1 - Individuazione stato meteo ed eventuale informativa
all’utente veicolo ..........................................Errore. Il segnalibro non è definito.
Tabella 25. Requisiti funzionali ....................Errore. Il segnalibro non è definito.
Tabella 26. Requisiti tecnici dei componenti Errore. Il segnalibro non è definito.
Tabella 27. Disposizione parcheggi lungo il Test Site Errore. Il segnalibro non è
definito.
Tabella 28. Tipi di inquadrature e rilevazioni effettuate dalle telecamere . Errore. Il
segnalibro non è definito.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
Introduzione - sintesi della proposta progettuale
La proposta progettuale Internet of Things: road-Traffic over Internet (IoT_|_ToI) propone di
declinare il problema delle Internet of Things nella gestione del traffico stradale e
dell’inquinamento urbano da esso provocato.
Nella proposta, i due diversi problemi (traffico e inquinamento) vengono affrontati in modo
unificato tramite la raccolta e gestione di dati distribuiti. Nella fattispecie si ritiene che siano
proprio i veicoli, ed alcuni “strategici” nodi fissi di infrastruttura, a fungere da nodi IoT per la
raccolta di dati di monitoraggio e per innescare il processo decisionale - mirato ad azioni
correttive sul traffico.
Pertanto lo scenario proposto declina il tema IoT in un caso 1) pratico e fattibile a medio
termine, 2) corrispondente ad un problema reale, 3) di rilevanza territoriale, considerata
l’importanza del settore veicolare, 4) affrontabile con strumenti realizzativi concreti (quali una
piattaforma di comunicazione tra veicoli e veicoli o infrastrutture che verrà sviluppata da Magneti
Marelli, i dispositivi di visione per il rilevamento del traffico e dei parcheggi, sviluppati da C
System e Ivrea Sistemi, ed un data base intelligente, sviluppato da Hicare, che collezioni i dati di
traffico e inquinamento per il centro di controllo del traffico).
La proposta IoT_|_ToI perseguirà i seguenti obiettivi teorici e/o pratici:

Studio delle problematiche IoT orientate alle comunicazioni veicolari per il controllo e la
gestione del traffico urbano;

Progettazione e realizzazione di una piattaforma di comunicazione per infrastrutture fisse
e nodi veicolari;

Progettazione di protocolli di comunicazione e di raccolta dei dati provenienti dai nodi
fissi e mobili allestiti;

Progettazione di un dimostratore presso il centro di controllo del traffico per la raccolta ed
elaborazione di dati distribuiti sul territorio tramite nodi veicolari, sensori ambientali e
telecamere fisse;

Progettazione di più dimostratori veicolari, equipaggiati con una piattaforma di
comunicazione con le infrastrutture per lo scambio di informazioni inerenti il traffico, e con
dispositivi di visualizzazione delle informazioni di traffico provenienti dal centro di
controllo;

Studio simulativo di algoritmi di IoT-driven per il green-routing (incluse problematiche
legate alla ricerca dei parcheggi liberi);

Integrazione in un Test Site scelto dei dimostratori fissi e veicolari per la preparazione di
una dimostrazione finale del progetto che evidenzi i risultati raggiunti.
Il progetto rientra nella categoria interpolo in quanto presenta sinergie con il polo della
Meccatronica e dei Sistemai Avanzati di Produzione (MESAP) di cui ISMB è socio.
Il tema proposto e, più in particolare, le attività svolte da ISMB, aderiscono infatti alla traiettoria
PRODOTTI SMART del polo della Meccatronica e, più nel dettaglio, alla linea di sviluppo dei
prodotti smart MECHA (MECHatronics Automation). Pertanto i costi di ISMB vengono riferiti
rispettivamente a tali traiettoria e linea.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
1. Idea e motivazioni alla base del
problematica affrontata e obiettivi generali
IoT_|_ToI
progetto,
Il progetto Internet of Things: road-Traffic over Internet (IoT_|_ToI) affronta il problema del
monitoraggio e controllo del traffico stradale urbano e della prevenzione dell’inquinamento,
attraverso la raccolta di dati da entità distribuite (fisse o mobili) secondo il modello IoT.
La raccolta di tali informazioni viene attuata tramite sensoristica a bordo veicoli e infrastrutture
di strada - telecamere per il rilevamento delle posizioni veicolari, di postazioni libere di parcheggi,
e sensori ambientali integrati in veicoli e infrastrutture.
Le informazioni raccolte vengono poi inviate verso un centro di controllo ed elaborazione dati
che estrae le statistiche di interesse ed invia informazioni di traffico ai veicoli presenti nell’area
monitorata dal centro di elaborazione.
Questo di tipo di architettura di sistema permette l’attivazione di diversi servizi, tra i quali il
monitoraggio dello stato di occupazione dei parcheggi, la stima del livello di congestione delle
strade della rete urbana e il conseguente bilanciamento del carico stradale, attraverso la
comunicazione wireless tra veicoli e infrastrutture locali, queste ultime collegate al centro di
elaborazione e controllo.
I servizi offerti permettono la limitazione dei tempi di percorrenza media e quindi le emissioni
dei veicoli, specie in aree che già ne siano particolarmente afflitte, e facilita la gestione del traffico
rispondendo alle esigenze degli utenti così come delle diverse aree urbane.
Studi recenti hanno infatti evidenziato i costi del tempo passato mediamente in automobile per
persona come mostrato nella seguente tabella.
E’ inoltre noto che problemi come quelli delle polveri sottili stanno recentemente attanagliando
le principali città – non ultima Torino - con punte negative nell’inverno 2009-2010 (59 giorni di
supermanto dei limiti nei primi 3 mesi dell’anno contro i 35 consentiti per legge). Infine, si
sottolinea che la problematica della ricerca di parcheggio provoca, soprattutto nelle grandi città,
un considerevole aumento dell’inquinamento e della congestione del traffico; per contro la
gestione di informazioni sulla disponibilità di parcheggi liberi in vicinanza ovvero dello stato di
occupazione di quelli vicini alla destinazione, rappresenterebbero una possibile soluzione al
problema.
In tale ambito, il progetto IoT_|_ToI si propone i seguenti obiettivi:

Realizzazione di un dimostratore infrastrutturale che permetta il supporto dei seguenti
servizi: (i) monitoraggio del traffico veicolare e distribuzione di dati sulla congestione della
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
rete stradale urbana; (ii) stima dell'occupazione dei parcheggi e diffusione di tale
informazione ai veicoli che transitano in prossimità dell'area interessata.

Realizzazione di un dimostratore veicolare che usufruirà dei servizi messi a disposizione
dal dimostratore infrastrutturale, grazie all’integrazione a bordo veicolo di dispositivi di
comunicazione wireless che ricevano le informazioni di traffico e stato parcheggi dalle
infrastrutture circostanti, e di dispositivi di visualizzazione delle informazioni al guidatore.

Sviluppo di protocolli e algoritmi per la raccolta e la distribuzione dei dati relativi al traffico
veicolare, tramite l'utilizzo di comunicazione wireless veicolo-veicolo e veicoloinfrastruttura e la comunicazione via cavo tra infrastruttura e centro di controllo.

Definizione della configurazione ottimale dell'architettura di rete, con particolare
attenzione (i) ai parametri di comunicazione wireless per garantire i requisiti esistenti
sulla copertura del servizio, e (ii) all'integrazione di sistemi di correzione del segnale GPS
per ottenere informazioni accurate sul posizionamento dei veicoli.

Implementazione al centro di controllo di algoritmi e piattaforme software per la
validazione ed elaborazione dei dati raccolti, al fine di estrarre le statistiche di interesse.
Tali obiettivi verranno raggiunti tramite lo sviluppo di strumenti ICT e sfruttando il paradigma IoT.
In particolare, il progetto si articola nelle seguenti attività di ricerca industriale e sviluppo
sperimentale:

Progettazione del dimostratore infrastrutturale nell'area torinese di Corso Castelfidardo,
localizzata tra il Politecnico di Torino e l’Istituto Superiore Mario Boella (ISMB). Il
dimostratore comprenderà punti di accesso fissi operanti con tecnologia wireless 802.11
e collegati via cavo ad un centro di controllo ed elaborazione dati presso ISMB. I punti di
accesso fissi saranno collegati alle telecamere fisse per il monitoraggio del traffico e dei
parcheggi, e alle sonde ambientali che rileveranno dei parametri sensibili
dell’inquinamento di origine veicolare in ambiente cittadino (CO, NO2, polveri sottili).

Progettazione di più dimostratori veicolari, equipaggiati con: una piattaforma di
comunicazione wireless 802.11 progettata analogamente a quella infrastrutturale e poi
personalizzata per uso veicolare, un GPS, sonde ambientali e dispositivi di
visualizzazione delle informazioni provenienti dal centro di controllo tramite
comunicazione wireless con infrastrutture. I vari dispositivi a bordo veicolo andranno
opportunamente integrati nell’architettura veicolare.

Definizione e studio simulativo di protocolli ed algoritmi per la raccolta di dati relativi ai
veicoli che transitano nella zona di interesse e che parcheggiano nelle aree limitrofe. Le
soluzioni sviluppate opereranno in modo distribuito, sfruttando le comunicazioni interveicolo e provvederanno alla consegna dei dati aggregati ai punti di accesso fissi. Tali
dati saranno integrati con informazioni rilevate tramite telecamere, in modo da migliorare
la percezione dell’area da monitorare tramite dati provenienti da fonti differenti.

I dati raccolti tramite le tecniche citate al punto precedente saranno trasferiti via cavo al
centro di controllo, dove verranno elaborati da algoritmi specificatamente sviluppati,
implementati e validati all'interno del progetto. Le statistiche così ottenute sulla
congestione di traffico e stato di occupazione dei parcheggi verranno distribuite verso i
veicoli, tramite un percorso inverso nella rete dell'informazione e l'implementazione di
protocolli di routing multihop. Analogamente, il centro di controllo distribuirà dati per la
correzione del segnale GPS rilevato dai veicoli, che è noto risultare inaccurato in
ambiente urbano.

I parametri di configurazione delle piattaforme di comunicazione veicolari, delle antenne
a bordo veicolo e dei punti di accesso fissi dovranno essere ottimizzati per fornire una
sufficiente copertura radio della area interessata e una buona qualità della
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
comunicazione sui canali di frequenza utilizzati (basso livello di interferenza, limitati effetti
di fading).

Uso delle telecamere fisse per la raccolta di informazioni di traffico. Come già
brevemente citato nei punti relativi ai dimostratori fissi e veicolari, nell’ambito del progetto
IoT_|_ToI la raccolta delle informazioni avviene anche mediante l'uso di telecamere fisse.
Queste sono utilizzate per tre scopi principali: monitoraggio dello stato d'uso dei
parcheggi, apprendimento e monitoraggio dello stato dei semafori, monitoraggio del
traffico. Un aspetto innovativo risiede nell'assenza di controllo umano per raggiungere i
tre scopi. Si intende infatti progettare e realizzare algoritmi di analisi intelligente delle
immagini e meccanismi di segnalazione generale o particolare della situazione attuale,
persino con consigli sulla guida.
In Figura 1 è mostrato un esempio di allestimento del Test Site in Corso Castelfidardo in Torino,
con i vari nodi IoT fissi e mobili, ed il centro di controllo del traffico.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
centro di
controllo
del traffico
Politecnico di
Torino e ISMB
Politecnico di
Torino e ISMB
nodo IoT mobile
nodo IoT fisso
Collegamento via cavo
Collegamento WiFi 802.11
Figura 1. Collegamenti tra nodi IoT fissi, mobili e centro di controllo del traffico.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
Nella Figura 2 è indicata un’architettura logica dei nodi IoT fissi, mobili, e del centro di controllo
del traffico.
All’interno del nodo IoT mobile sarà presente la piattaforma di comunicazione WiFi 802.11, che
permetterà di inviare ai nodi IoT fissi e mobili le informazioni sul proprio stato (posizione, velocità,
accelerazione), nonché le informazioni provenienti dai sensori ambientali (stato inquinamento –
livello di emissioni catturate dai sensori nella posizione corrente).
Il nodo IoT fisso più vicino riceverà dai nodi IoT mobili le informazioni e sua volta le inoltrerà via
cavo al centro di controllo del traffico. Le informazioni saranno ricevute e salvate in un opportuno
Data Base. Gli algoritmi di controllo del traffico, accedendo al Data Base, faranno le opportune
elaborazioni e invieranno le informazioni relative allo stato del traffico (stato semafori, stato
occupazione corsie, ecc. ) verso i nodi IoT fissi, in modo geo - referenziato (quindi ogni nodo IoT
fisso riceverà le informazioni relative alla propria area circostante).
Inoltre il centro di controllo del traffico fornirà una correzione DGPS per ciascun veicolo
comunicante con i nodi IoT fissi, di cui sia a conoscenza (cioè nodi IoT mobili presenti nel Data
Base).
Tutte le informazioni inviate dal centro di controllo del traffico ai nodi IoT fissi saranno inoltrate ai
nodi IoT mobili attraverso un canale di comunicazione 802.11.
Quando un nodo IoT mobile riceverà le informazioni da un nodo IoT fisso, le mostrerà sull’HMI di
bordo, in modo che l’utente finale (il guidatore), le possa utilizzare durante la guida.
I colori delle frecce in Figura 2 indicano i due versi di flusso dati: il nero indica l’invio di tutti i dati
verso il centro di controllo, il quale li raccoglie all’interno di un appropriato Data Base avviando
l’opportuna elaborazione; in parallelo all’elaborazione dei dati ricevuti viene attivata la correzione
DGPS. Il colore blu invece indica il flusso inverso, dal centro di controllo verso i nodi IoT fissi e
poi verso i nodi mobili.
Il salvataggio dei dati provenienti dai nodi IoT fissi e mobili avviene all’interno di un Data Base
che dovrà memorizzare i dati ricevuti in base ai tempi di ricezione e ai nodi che li hanno inviati. I
dati presenti all’interno del Data Base dovranno essere aggiornati in base al tipo di dato, per fare
ciò bisognerà studiare ed implementare delle opportune strategie di aggiornamento.
La Figura 2 rappresenta sia componenti funzionali che dispositivi HW (telecamere, sensori
ambientali, etc...) presenti nei vari nodi. Alcuni moduli funzionali non necessariamente saranno
realizzati in dispositivi distinti. Ad esempio, il modulo software che gestisce l’HMI di bordo
potrebbe risiedere nello stesso componente HW dove verrà implementato il modulo software
della comunicazione, anche se funzionalmente i due moduli hanno obiettivi differenti e quindi
sono mostrati separatamente.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
Sensori ambientali
Sensori
ambientali
Telecamere
nodo IoT fisso
Piattaforma di Comunicazione 802.11
Piattaforma di Comunicazione 802.11
HMI di
bordo
GPS +
correzione
DGPS
nodo IoT mobile
Correzione
DGPS
Data Base
Algoritmi di gestione traffico
centro di controllo del traffico
Dati inviati verso la piattaforma di
comunicazione
Informazioni inviate da un nodo
IoT veicolare ad un nodo IoT fisso
Informazioni inviate da un nodo
IoT fisso al centro di controllo del
traffico via cavo
Informazioni dal Data Base agli
algoritmi di controllo e
all’algoritmo di correzione DGPS.
Informazioni inviate dal centro di
controllo ai nodi IoT fissi.
Informazioni inviate da un nodo
IoT fisso ad un nodo IoT veicolare
Informazioni inviate dalla
piattaforma di comunicazione ai
componenti a bordo vettura.
Figura 2. Architettura dei nodi IoT fissi, mobili e centro di controllo del traffico.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
Le attività sono pianificate secondo la seguente roadmap (specificata nel dettaglio nel Capitolo
4):

Definizione dei casi d’uso del sistema cooperativo veicolare – infrastrutturale, conseguente
definizione di specifiche e architettura di veicoli e infrastrutture, interfacce tra le due entità;
scelta delle informazioni di scambio tra veicoli e infrastrutture; scelta della tecnologia di
comunicazione tra le possibili varianti dello standard IEEE/ETSI 802.11; analisi degli
strumenti per l’elaborazione dei dati e definizione dell’architettura della base dati usata dal
centro di controllo; definizione dell’architettura del sistema di visione e dei sensori
ambientali. (M1-M6).

Soluzioni algoritmiche: analisi di soluzioni protocollari per la comunicazione wireless;
algoritmi di visione per controllo del traffico e gestione parcheggi; algoritmi per l’integrazione
dei dati e la distribuzione verso i veicoli; algoritmi di correzione GPS delle posizioni veicolari.
(M7-M18).

Sviluppo dei nodi IoT: sviluppo di nodi prototipali veicolari e di nodi di infrastruttura in
tecnologia IEEE 802.11 e ottimizzazione dei parametri di comunicazione; sviluppo del
sistema di correzione del segnale GPS; visualizzazione delle posizioni veicolari iniziali e
corrette su dispositivi a bordo veicolo; sviluppo prototipale di un sistema di visione ed
identificazione dei veicoli tramite telecamere e sua integrazione nell’architettura di sistema;
integrazione dei sensori ambientali nei nodi IoT. (M7-M18).

Integrazione, verifica e validazione sul Test Site: test dei singoli componenti veicolari,
integrazione dei componenti a bordo vettura e test; test dei singoli componenti
infrastrutturali, integrazione dei componenti nell’infrastruttura stradale e test; posizionamento
dei veicoli e infrastrutture nell’area del Test Site e validazione del sistema cooperativo
complessivo; analisi statistica dei dati prelevati del Test Site; preparazione della
dimostrazione finale e dimostrazione (M13-M24).
Le tematiche affrontate e i risultati che saranno raggiunti nell’ambito del progetto sono di
particolare rilevanza per le pubbliche amministrazioni dei centri urbani, che sono chiamati a
garantire bassi livelli di emissioni e una mobilità sostenibile. Analogamente, sono di interesse per
le compagnie di trasporto pubblico e di gestione di parcheggi, con ricadute estremamente
positive sull’efficienza del sistema.
La comunicazione wireless tra veicoli e con infrastrutture è anche di notevole interesse per i
centri di ricerca e per Magneti Marelli, dal momento che essa è uno dei temi di studi degli ultimi
anni in ambito europeo per i sistemi di trasporto privati.
Si sottolinea infine che la comunicazione intra veicolare - tra i vari dispositivi a bordo veicolo:
dispositivo di visualizzazione informazioni al guidatore, dispositivo di comunicazione wireless,
sensori, è un ramo del campo automotive che negli ultimi anni sta acquisendo sempre maggiore
interesse, ed è facilmente integrabile con le tematiche del Polo della Meccatronica. In particolare,
esiste già un accordo di mutua divulgazione dei risultati di questo progetto con il progetto
SIMEBUS del Polo della Meccatronica, con duplice vantaggio per entrambi i progetti.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
2. Coerenza, sinergia e grado di integrazione rispetto
alla TP/LS di appartenenza e al piano generale di
attività del Polo
La “Internet of Things” (IoT) rappresenta oggi un modello di interazione con i dati, piuttosto che
una vera e propria architettura di rete. L’idea di base è che tutti gli oggetti, anche quelli facenti
parte della quotidianità, possano essere identificabili, raggiungibili e interrogabili. Il principale
problema della IoT è rappresentato dalla scalabilità delle soluzioni tecnologiche che comporta
necessariamente il superamento dei paradigmi esistenti: non più una raggiungibilità esaustiva e
deterministica, bensì una comunicazione spesso event-driven e best-effort. Inoltre IoT fa ampia
leva sulle capacità di aggregazione dei dati. Ultimo ma non meno importante, IoT richiede la
costruzione di una struttura di raccolta, distribuzione e rappresentazione (visualizzazione)
efficace dei dati, senza la quale la grossa mole di informazioni diverrebbe inutilizzabile.
Virtualmente il modello proposto della IoT si adatta ad una pletora di possibili “oggetti”: la
presente proposta si concentra su Internet-Things che si riferiscono al contesto urbano,
raccolgono dati di traffico e sfruttano le comunicazioni wireless veicolo-veicolo e veicoloinfrastruttura (V2V e V2I) per la raccolta e l’aggregazione delle informazioni, nonché per la
distribuzione di informazioni di controllo. I dati raccolti sono finalizzati al monitoraggio di traffico
(compresa la raccolta di dati di congestione e di occupazione di parcheggi) e all’elaborazione di
statistiche che possano essere utili ai veicoli per minimizzare il tempo di percorrenza (e dunque di
livelli di emissione) e di ricerca di parcheggi.
Secondo l’intenzione del Consorzio proponente, l’impostazione scelta offre i seguenti vantaggi:

La scelta delle applicazioni e del contesto ambientale-urbano prospetta
un’implementazione significativa delle tematiche IoT calandole in una realtà a medio
termine;

Molte tematiche delle IoT sono presenti. Nella fattispecie, vengono affrontate i seguenti
key open issues:: scalabilità della soluzione; ottimizzazione dell’uso di reti di
comunicazione wireless; raccolta di dati eterogenei in modalità sollecitata o eventdriven; creazione di piattaforme di elaborazione e rappresentazione visuale dei dati;
distribuzione di informazioni per il controllo delle things;

L’applicazione risponde a tematiche di sostenibilità che coniugano le direttive europee
(si citano le keyword FP7: green routing ed environmental monitoring);

Il progetto propone la realizzazione di dimostratori che avranno una propria valenza
pratica nelle due seguenti applicazioni: 1) campagna di raccolta di dati reali da veicoli
per la stima della congestione stradale e dell’occupazione dei parcheggi; 2)
elaborazione di tali dati per la creazione di informazioni di controllo volte alla riduzione
dei tempi di percorrenza e della ricerca di parcheggio dei veicoli;

Le comunicazioni veicolari infine avranno un proprio spazio, costituendo un asset
strategico per economica piemontese, fortemente polarizzato sul veicolare.
In particolare i benefici riguardano alcuni sviluppi e numerose ricadute, relative alla creazione di
una piattaforma e uno standard di integrazione e gestione dei dati a bordo auto: il progetto
inizierà ad affrontare il tema occupandosi dell’integrazione delle piattaforme di visualizzazione
dati, del GPS e della piattaforma di comunicazione.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
3. Stato dell’arte scientifico-tecnologico
Le reti di comunicazione veicolari hanno recentemente ricevuto grande attenzione, da parte del
mondo sia scientifico che industriale. Tali sistemi di rete permettono infatti il supporto di
applicazioni di fondamentale importanza per la sicurezza stradale e per la realizzazione di una
mobilità sostenibile.
In una rete veicolare, vi sono due modalità di comunicazione: veicolo-veicolo (V2V) e veicoloinfrastruttura (V2I o I2V). Il primo è tipicamente usato per lo scambio di informazioni tra veicoli per
servizi di sicurezza stradale. Il secondo mira ad estendere l’orizzonte delle reti veicolari tramite
nodi gateway posizionati a bordo strada, i quali permettono di connettersi a Internet o a centri di
controllo per ottenere informazioni sullo stato della rete e del traffico stradale o i cosiddetti servizi
di informazione e intrattenimento (infotainment). Entrambe le modalità di comunicazione possono
poi far uso di trasmissioni multi-hop per estendere l’area di copertura della rete.
I protocolli di comunicazione per reti veicolari impiegati a livello internazionale sono DSRC [S1]
(standardizzato da ETSI, ISO e CEN in Europa, e da FCC negli Stati Uniti d’America), 802.11p
[S2] (standardizzato da IEEE), e CALM [S3] (standardizzato da ISO). Tali protocolli danno la
possibilità di comunicare a breve o media distanza, tipicamente nelle bande a 5.9 GHz. Mentre
DSRC e 802.11p sembrano essere state progettate con l’obiettivo primario di fornire sicurezza
stradale, CALM è maggiormente orientato al supporto di applicazioni infotainment. Vale inoltre la
pena citare il progetto ITS (Intelligent Transportation System) che in ambito europeo ha dato vita
a numerose iniziative, tra cui eSafety, EasyWay e il Car-2-Car Communication Consortium
(C2C-CC) [S4]. Quest’ultimo in particolare ha l’importante ruolo di riunire i maggiori produttori di
veicoli e alcuni centri di ricerca per creare uno standard europeo e armonizzare tali specifiche
con le regolamentazioni internazionali nel campo dei sistemi di trasporto intelligenti.
Riguardo all’aspetto dell’instradamento del traffico dati in reti veicolari, recentemente sono stati
proposti numerosi protocolli in letteratura. Tra gli approcci proposti, merita particolare attenzione il
cosiddetto routing geografico, o Greedy Perimeter Stateless Routing (GPSR) [Karp00,
Lochert05]: assumendo di conoscere la posizione della destinazione, è possibile consegnare
traffico senza sapere preventivamente il percorso da seguire, ma semplicemente inviandolo al
veicolo che in quel momento è più vicino alla destinazione. Un altro interessante protocollo è
TrafRoute [Frank09], che sfrutta l’approccio source routing e la presenza di infrastruttura nel caso
il traffico dati debba essere consegnato a grande distanza dal nodo sorgente. Il percorso
scoperto tramite TrafRoute è una sequenza di identificatori, che non si riferiscono a veicoli ma a
punti fissi (landmarks) che devono essere attraversati.
Nell’ambito dei protocolli per la distribuzione e della raccolta dei dati, si citano le soluzioni
presentate in [Korkmaz04, Zhao08]. In particolare la prima prevede la diffusione di informazione
tramite broadcasting e l’elezione di nodi incaricati ad inoltrare i dati a tutti i veicoli della rete,
mentre la seconda mira ad estendere l’area di copertura di nodi di infrastruttura tramite l’uso di
veicoli che ritrasmettano i dati in modalità multi-hop. Il lavoro in [Borsetti09] invece propone una
tecnica per la diffusione localizzata e il mantenimento dell’informazione all’interno di specifiche
aree di interesse.
Si sottolinea che rispetto ai lavori esistenti o alle attività di progetto attualmente in corso, la
proposta IoT_|_ToI presenta numerosi aspetti innovativi. Innanzitutto, la proposta mira a
coniugare comunicazioni wireless da una parte ed algoritmi per la raccolta di campioni sullo stato
del traffico veicolare dall’altra. Lo specifico contesto porta alla necessità di definire nuovi
meccanismi e protocolli per la raccolta di tali dati, in modo da ottenere statistiche affidabili.
Inoltre, applicazioni quali la rilevazione distribuita dello stato dei parcheggi e la distribuzione di
tale informazione, richiedono di selezionare accuratamente le modalità di comunicazione
(broadcast/geocast/ unicast), al fine di soddisfare la qualità del servizio richiesta dagli utenti.
I meccanismi sopra menzionati saranno poi combinati con un servizio di distribuzione di
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
correzione delle coordinate GPS, che costituisce un elemento di novità. Non solo, ma questi
meccanismi di correzione permetteranno l’implementazione di numerosi servizi (che richiedono
un posizionamento accurato) tramite dispositivi GPS a basso costo, evitando l’uso del GPS
differenziale.
Infine, a testimonianza della competenza e della rilevanza internazionale delle attività svolta dai
partner coinvolti nella proposta IoT_|_ToI, si cita che Magneti Marelli ha partecipato al progetto
Integrato Europeo SAFESPOT, “Smart Vehicles on Smart Roads”, in cui è stato sviluppato un
primo sistema di comunicazione a bordo veicolo basato sulla tecnologia wireless a corto raggio, e
che attualmente partecipa al progetto Europeo, CoVel - “Cooperative Vehicle Localization for
Efficient Urban Mobility”, incentrato sulla comunicazione per mobilità efficiente.
In ambito regionale, il progetto VICSUM, guidato dal Politecnico di Torino e svolto in
collaborazione con CRF (Centro Ricerche Fiat) e CSP (Centro Supercalcolo Piemonte), e
finanziato dalla Regione Piemonte, ha studiato la problematica della mobilità sostenibile
attraverso la definizione, progettazione e, infine, la realizzazione di scenari di intervento in cui il
ruolo cardine è giocato dai sistemi di Information Technology. VICSUM ha definito un’architettura
di rete di comunicazione mobile dove i veicoli stessi giocano un ruolo fondamentale nella raccolta
di informazioni (sulla viabilità, sui servizi locali, sulle attrattive turistiche, e sull’offerta
commerciale) così come nella loro distribuzione e condivisione. I risultati del progetto VICSUM
[V1][V2] saranno quindi presi come punto di partenza per lo sviluppo di alcune delle soluzioni che
si intendono studiare e sviluppare nell'ambito del progetto IoT_|_ToI.
[S1] http://www.its.dot.gov/telecom/tele_dsrc.htm
[S2] http://grouper.ieee.org/groups/802/11/Reports/tgp_update.htm
[S3] http://www.calm.hu/
[S4] http://www.car-to-car.org/
[Karp00] B. Karp, H. T. Kung, “GPSR: greedy perimeter stateless routing for wireless networks,”
6th ACM conference on Mobile computing and networking, New York, NY, USA, 2000.
[Lochert05] C. Lochert, M. Mauve, H. Füßler, H. Hartenstein, “Geographic routing in city
scenarios,” ACM SIGMOBILE Mobile Computing and Communications Review, 9(1):69–72, 2005.
[Frank09] R. Frank, E. Giordano, P. Cataldi, M. Gerla, “TrafRoute: An Efficient Routing Scheme
for Vehicular Networks,” Technical Report 90018, University of California Los Angeles (UCLA),
2009.
[Korkmaz04] G. Korkmaz, E. Ekici, F. Ozguner, U. Ozguner, ``Urban Multihop Broadcast Protocol
for Inter-vehicle Communication System,'' ACM VANET, 2004.
[Zhao08] J. Zhao, T. Arnold, Y. Zhang, G. Cao, ``Extending Drive-Thru Data Access by Vehicleto-Vehicle Relay,'' ACM VANET, 2008.
[Borsetti09] D. Borsetti, M. Fiore, C. Casetti, C.-F. Chiasserini, “When Services Go Local”, ACM
MSWiM, Tenerife, Spain, 2009.
[V1] L. Liquori, D. Borsetti, C. Casetti C.-F. Chiasserini, “An Overlay Architecture for Vehicular
Networks”, Networking 2008, Singapore, 2008.
[V2] S. Annese, C. Casetti, C.-F. Chiasserini, N. Di Maio, A. Ghittino, M. Reineri, “Seamless
Connectivity and Routing in Vehicular Networks with Infrastructure,” IEEE Journal on Selected
Areas in Communications (IEEE JSAC), in press.
4. Innovazioni perseguite nel progetto
Come anticipato dal titolo del progetto (IoT_|_ToI Internet of Things: road-Traffic over Internet),
il progetto declina la Internet of Things in ambito urbano, con particolare attenzione al
monitoraggio ambientale e del traffico.
Il tema è interessante in quanto propone una soluzione di chiaro impatto, non puramente
teorica, e finalizzata alla gestione di problemi reali (congestione di traffico e inquinamento). Per
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
giunta lo studio cala il concetto di IoT in un contesto tecnologico ugualmente di avanguardia,
quello delle comunicazioni veicolari.
Pertanto le innovazioni sottese sono raggruppabili in due sottoinsiemi ugualmente significativi:

innovazioni relative alla gestione scalabile dei dati IoT;

innovazioni relative all’applicazione dei concetti IoT in ambito VANET (Vehicular Ad hoc
NETworks).
Le innovazioni relative al settore IoT riguardano due dei principali punti aperti sottesi in
letteratura [1]:
1. la raccolta (e l’indirizzamento) di grandi quantità di dati. Se si fa riferimento al problema
specifico dell’autoconfigurazione della rete wireless di interconnessione delle cose è
difficile immaginare un’unica rete (virtualmente infinita) di nodi IoT distribuiti in modo
indefinito. La soluzione proposta fa riferimento ad un indirizzamento georeferenziato degli
oggetti, gestito a livello di rete a pacchetto tramite i nodi veicolari che fungono quindi da
proxy;
2. La gestione (anche storica) di grandi quantità dati, la conoscenza (a priori o appresa) degli
oggetti (compreso il naming), l’aggregazione dei dati e la visualizzazione: tale problema è
ben noto anche alla Comunità Europea che ha sottolineato l’esigenza di un’opportuna
governance [2].
Occorre premettere che il paradigma IoT propone una sovrapposizione di informazione
generica, per cui è possibile che diversi contesti adottino e adattino il paradigma diversamente –
per cui potranno esistere soluzioni disgiunte e diversamente ottimizzate.
Pertanto nel settore IoT le innovazioni si collocano contemporaneamente a livello
applicativo (in quanto rispondono alla progettazione di una soluzione reale con impatto fino al
livello di gestione dati) e a livello di innovazione Europea, (in quanto affronta temi discussi a
livello scientifico in programma FP7).
Le innovazioni nel settore specifico IoT-VANET [1], riguardano l’impiego di VANET come
strumento abilitante per comunicazioni T2T (thing to thing): vehicle-to-person, vehicle-toinfrastructure, vehicle-to-environment.
Il tema si coniuga bene con le problematiche di IoT in quanto, la disponibilità di dati fortemente
decentralizzati permette di migliorare la conoscenza dello stato del traffico stradale e quindi di
prendere decisioni migliori per il suo smaltimento: evidenti sono anche le ricadute ambientali.
A ciò si aggiunga che le comunicazioni veicolari VANET costituiscono tuttora uno dei temi di
ricerca “aperti” in ambito ICT. Le tecnologie di comunicazione veicolare costituiscono oggi un
argomento ancora vivo e non del tutto consolidato; inoltre le conoscenze del settore riguardano
principalmente la teoria e la conoscenza simulativa delle problematiche: si osserva a tale
proposito che in Europa sono solo recentemente stati avviati nell’ambito FP7 i Field Operational
Test (FoT), finalizzati ad una conoscenza pratica (hands-on) del contesto.
Inoltre i principali enti di standardizzazione (IEEE e ETSI) stanno attualmente lavorando alla
definizione degli standard di comunicazione tra i veicoli, aprendo la strada ad una lunga serie di
applicazioni (dal controllo del traffico alla sicurezza di guida).
Pertanto il frame work del progetto ben si adatta alla sperimentazione di tali tecnologie
emergenti, sia pure in un contesto applicativo specifico (IoT).
Non possono quindi essere trascurate le ricadute di innovazione nel settore VANET,
particolarmente rilevante per le aziende torinesi del settore automobilistico e, per il comparto
Piemontese in generale.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
Pertanto nel settore IoT-VANET le innovazioni si collocano contemporaneamente a livello
europeo (in quanto contestuale e potenzialmente sinergico ai FoT) e locale (considerata la
rilevanza); inoltre le innovazioni attese possono essere classificate sia a livello di soluzione
tecnica (ovvero di tecnologia abilitante di base) che a livello applicativo.
Le soluzioni attese comprendono quindi contenuti di ricerca di base (con ottime opportunità di
pubblicazione in ambito internazionale) ma anche tecnologico di prodotto (con discrete
opportunità brevettuali).
[1] Si citano a titolo di esempio tre white paper (research report) dell’HammerSmith Group:
“The Internet of things: Networked objects and smart devices”,February 2010;
“The Internet of things: Vehicles as networked objects”, July 2009
“Clicks and Mortar – Web 4.0, The Internet of Things”, May 2009.
[2] Line of action 1 – Governance, del documento Commission of the European Communities
(2009-06-18). "Internet of Things — An action plan for Europe" (pag.5)
5. Sostenibilità tecnico-economica
L’elevato livello nonché l’equilibrato mix di competenze tecniche dei partner di questo progetto
(Università, Istituto di Ricerca, Azienda di componentistica automotive, Piccole Imprese con
conoscenze tecniche specialistiche nel settore della progettazione elettronica e software),
consentiranno di coprire adeguatamente tutti gli aspetti realizzativi del progetto.
Nel merito specifico del rispetto dei tempi e dei costi di realizzazione saranno utilizzate in
particolare le competenze che derivano dalle peculiarità del settore di appartenenza delle
aziende manifatturiere come ad esempio Magneti Marelli che renderanno disponibili le migliori
risorse derivanti dalla lunga esperienza nella progettazione e realizzazione di prodotti elettronici
automotive che, come noto nel mercato, richiedono il rispetto di vincoli di costo ed affidabilità
molto elevati.
Il livello di rischio sarà minimizzato dall’utilizzo in elevata misura di soluzioni tecniche e criteri di
progettazione derivanti dall’esperienza di realizzazione di dispositivi di produzione.
Al contempo saranno utilizzati idonei strumenti di analisi del rischio adottati in azienda nel
processo di ricerca e sviluppo prodotto ed opportunamente adeguati alle esigenze del progetto.
Nello specifico lo strumento sarà costituito da un questionario mediante il quale ciascun
partner, a cadenza regolare, potrà verificare rispondendo ai quesiti formalizzati il livello di
adeguatezza e le eventuali criticità in modo da definire tempestivamente azioni correttive o
soluzioni alternative.
Una analisi preliminare dei principali rischi connessi alla realizzazione del progetto in oggetto
ha portato a definire alcuni aspetti di rilievo riassunti nel prospetto seguente.
Componente/Tecnologia
Modulo di comunicazione
con tecnologia IEEE
802.11
D1.1.1.docx
ANALISI DEL PRELIMINARE RISCHIO
Livello di rischio
Probabilità
(Basso/Medio/Alto)
(Basso/Medio/Alto)
Basso
Medio
Azioni Correttive
Utilizzo di schede
Standard o impegno di
tecnologie di
comunicazione
alternative (es. GPRS)
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
Disponibilità di dati
puntuali da infrastruttura
Medio
Medio
Ricostruzione dati
mediante RSU (Road
Side Unit) mobile.
Sensori di rilevamento
esterni (telecamera,
sensori ambientali)
Basso
Basso
Utilizzo di soluzioni
standard già consolidate.
Utilizzo GPS senza
correzioni; revisione degli
Use Cases in ottica di
realizzabilità.
Localizzazione precisa
GPS
Medio
Basso
Fattibilità degli Use Cases
definiti
Medio
Basso
Gestione dei dati in tempo
reale nel data base e
collegamenti con algoritmi
esterni al data base.
Basso
Medio
Revisione degli Use
Cases non fattibili in
ottica di realizzabilità.
Revisione del data base
esistente di Hicare,
focalizzata sugli aspetti
caratteristici del progetto.
Le verifiche di fattibilità saranno effettuate a cadenze regolari nel corso di svolgimento del
progetto e riguarderanno ogni sotto-componente del sistema, con particolare attenzione alle
soluzioni più innovative che verranno preventivamente valutate in termini di effettiva realizzabilità.
Ciò consentirà in caso di dubbi o di rischio di infattibilità di ricorrere a soluzioni alternative in
grado comunque di garantire il soddisfacimento degli obiettivi di progetto stabiliti.
La scelta dei vari componenti HW a bordo vettura e sulle infrastrutture fisse sarà effettuata
considerando gli eventuali rischi, indicati nella tabella, ed eventuali soluzioni di back up.
Per quanto riguarda invece l’analisi dei rischi dovuti ai dati che vengono scambiati tra i nodi, e il
data base di gestione di tali dati, la procedura che verrà compiuta è la seguente.
I dati raccolti dai vari nodi IoT fissi e mobili verranno storicizzati nel database multidimensionale
proprietario di Hicare (piattaforma "Lilith Enterprise"). La struttura gerarchico/relazionale del
database permetterà di accedere ai dati con grande efficienza (in termini di velocità e
occupazione disco) e di analizzare i dati sfruttando i potenti strumenti di front end sviluppabili nel
framework Lilith.
Una base dati relazionale (implementata su MySql) verrà affiancata a quella multidimensionale
proprietaria per offrire un accesso open agli algoritmi di controllo traffico.
I dati che verranno scambiati tra i nodi IoT fissi e mobili e con il centro di controllo saranno
strutturati in messaggi standard per la comunicazione. Il contenuto dei messaggi includerà
sicuramente un identificativo del nodo inviante, un tempo di invio, e dei parametri caratteristici
che indichino il tipo di dato (dato ambientale, dato da telecamera, dato da veicolo,ecc).
La criticità legata all’invio dei messaggi via WiFi è dovuta alla non certezza di ricezione dei
messaggi. I protocolli di comunicazione WiFi utilizzati infatti non garantiscono che tutti i messaggi
inviati siano effettivamente ricevuti dai nodi. Questa criticità deve essere gestita sia dal lato di chi
invia che da chi riceve.
Dal lato trasmissione, il nodo che invia un messaggio può decidere di inviarlo più volte per essere
certo che almeno uno dei messaggi venga ricevuto. La strategia di invio sarà decisa
opportunamente durante la fase di architettura e specifiche del sistema di comunicazione.
Dal lato ricezione, il nodo che riceve il messaggio deve operare alcuni controlli per assicurarsi
che il messaggio ricevuto sia nuovo (cioè non già ricevuto); se il messaggio è nuovo viene
elaborato opportunamente mentre se già ricevuto viene scartato.
Il Data Base dovrà essere in grado di gestire la criticità dei dati in termini di allineamento
temporale. Se il data base riceve più messaggi consecutivi con lo stesso identificatore, con lo
stesso contenuto e con tempi di invio molto simili, dovrà decidere, sulla base delle tempistiche
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
predefinite, se gestire tutti i messaggi, cancellarne alcuni o sovrascrivere dei contenuti nelle
tabelle.
6. Integrazione con altre iniziative ed evoluzioni future
La proposta di progetto copre diversi campi di attività che sono collegabili a progetti tuttora in
corso o precedentemente sviluppati dalle società partecipanti.
La comunicazione intra veicolare, tra i vari dispositivi a bordo veicolo ed il sistema di
comunicazione VANET, è un ramo del campo automotive che negli ultimi anni sta acquisendo
sempre maggiore interesse, ed è facilmente integrabile con le tematiche del Polo della
Meccatronica. In particolare, esiste già un accordo di mutua divulgazione dei risultati di questo
progetto con il progetto SIMEBUS del Polo della Meccatronica, con duplice vantaggio per
entrambi i progetti.
La comunicazione VANET, tra veicoli e infrastrutture, è uno degli aspetti chiave su cui la
Comunità Europea ha investito fondi negli ultimi anni, con l’obiettivo di introdurre tale tecnologia a
bordo dei veicoli per ridurre di diversi punti percentuali gli incidenti automobilistici e le loro
conseguenze.
Magneti Marelli ha partecipato al progetto Integrato Europeo SAFESPOT, “Smart Vehicles on
Smart Roads”, in cui è stato sviluppato un primo sistema di comunicazione a bordo veicolo
basato sulla tecnologia wireless a corto raggio.
Attualmente Magneti Marelli partecipa ad un altro progetto Europeo, CoVel - “Cooperative
Vehicle Localization for Efficient Urban Mobility”, che è incentrato sulla comunicazione a corto e
medio raggio per mobilità efficiente, e quindi ha molti punti in comune con la proposta corrente.
Le attività che verranno portate avanti nel progetto relativamente ai sistemi di comunicazione
seguono anche gli sviluppi che a livello europeo si stanno ottenendo in ETSI e nel consorzio
C2C, in cui diversi partner sono coinvolti.
In ambito regionale, si evidenzia come la proposta progettuale presenti diversi punti di contatto
con il progetto VICSUM, guidato dal Politecnico di Torino e svolto in collaborazione con CRF e
CSP, e finanziato dalla Regione Piemonte. In particolare, VICSUM ha studiato la problematica
della mobilità sostenibile attraverso la definizione, progettazione e, infine, la realizzazione di
scenari di intervento in cui il ruolo cardine è giocato dai sistemi di Information Technology.
VICSUM ha definito un’architettura di rete di comunicazione mobile dove i veicoli stessi giocano
un ruolo fondamentale nella raccolta di informazioni (sulla viabilità, sui servizi locali, sulle
attrattive turistiche, e sull’offerta commerciale) così come nella loro distribuzione e condivisione. I
risultati del progetto VICSUM saranno quindi presi come punto di partenza per lo sviluppo di
alcune delle soluzioni che si intendono studiare e sviluppare nell'ambito del progetto IoT_|_ToI.
Un ulteriore sviluppo, di più lungo termine, è dato dalle comunicazioni Vehicle to Grid (V2G). In
questo paradigma i veicoli comunicano con l’infrastruttura di gestione dell’energia elettrica per il
coordinamento della produzione/immagazzinamento dell’energia elettrica. Le macchine ibride
possono infatti produrre energia necessaria alla rete in caso di un picco di richiesta che non può
essere soddisfatta; viceversa i veicoli elettrici possono fungere da accumulatori di energia in
avanzo sulla rete. Tutte queste operazioni hanno la necessità di una comunicazione real-time tra
la rete (grid) ed il veicolo che possono essere abilitate grazie agli studi che verranno effettuati nel
progetto.
7 Modalità di management e controllo del progetto
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
Per la realizzazione del progetto verranno il più possibile utilizzati, con i necessari adeguamenti,
le metodologie e gli strumenti normalmente impiegati nel processo di progettazione nell’ambito
della ricerca e sviluppo applicata alla realizzazione di prodotti di produzione.
Si prevede di utilizzare il modello a V (successivamente ripreso nel Capitolo 4.1) implementando
gli strumenti di verifica al termine di ogni fase del ciclo di sviluppo. Come citato già nel Capitolo
3.5, ciò consentirà di attuare le necessarie azioni correttive minimizzando il rischio di incorrere in
successive infattibilità e di compromettere l’esito del progetto.
Tutti i partner di progetto utilizzeranno la metodologia definita fornendo le evidenze del rispetto
del processo (verbali di riunione, design review, piani di verifica e validazione e report di test).
Sarà cura del partner capofila supportare i partner nella corretta attuazione del processo e
monitorarne l’attuazione.
Verranno selezionati ed utilizzati gli strumenti informatici idonei a supportare le varie fasi di
progetto (pianificazione, definizione e verifica dei requisiti e delle specifiche, design,
implementazione e validazione).
In ottica di contenimento dei costi si farà ricorso il più possibile a strumenti standard e di
comune conoscenza (ad esempio i diversi strumenti di Microsoft: Office, Project).
Verrà costituito uno Steering Committee composto da un rappresentante di ogni Azienda
Partner con il compito di monitorare lo svolgimento del progetto e definire le eventuali azioni
correttive.
Lo Steering Committee si riunirà con cadenza minima trimestrale o secondo le necessità
puntuali che dovessero insorgere.
Al fine di garantire una corretta ed efficace condivisione della documentazione di progetto sarà
istituito un idoneo strumento informatico (collaboration tool) fornito dei necessari requisiti di
sicurezza e salvaguardia dei dati.
8 Ricadute, impatti attesi e diffusione/applicabilità dei
risultati
Il problema del controllo del traffico e dell’inquinamento da esso provocato è attuale a livello
europeo.
Il progetto si propone di allestire strumenti ICT per la gestione di tali problemi. Considerando il
partenariato del progetto e gli strumenti già sviluppati dai partner stessi, l’obiettivo, per quanto
ambizioso, risulta perseguibile. Seppure non sia verosimile la costruzione di una soluzione
industriale, è sicuramente possibile lo sviluppo di un prototipo e, quindi, l’acquisizione delle
conoscenze che accelerino una soluzione a tali annosi problemi.
Alla luce di quanto detto si può affermare che la prima ricaduta riguarda l’obiettivo stesso
del progetto, ovvero l’accelerazione di soluzioni ai problemi di inquinamento e
congestione del traffico. Tali ricadute hanno un evidente impatto sulla sostenibilità urbana.
A tale proposito, si desidera evidenziare che la proposta contiene alcune idee innovative. Per
esempio, qualora si dimostrassero fattibili, il controllo di congestione e la stima dei parcheggi
liberi, rappresenterà un’innovazione di servizio e permetterà di diminuire situazioni di
superamento dei parametri di inquinamento e di migliorare la qualità di vita dei cittadini.
Il progetto prevede la sperimentazione su rete wireless veicolare di standard da poco introdotti,
come l’802.11p. Questo rappresenta un’attività in linea con quanto presente al momento a livello
internazionale (come descritto nel Capitolo 3.4, stanno partendo in questi mesi gli International
Field Operational Test). Pertanto una seconda importante ricaduta è rappresentata dalla
crescita di competenza verticale e non solo teorica nel settore veicolare. I piani di
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
disseminazione già intrapresi congiuntamente da alcuni partner (per esempio Magneti Marelli e
ISMB nel progetto Industria 2015 “Easy Rider”) assicureranno piani per le ricadute territoriali.
Non possono quindi essere escluse ricadute di innovazione nel settore VANET,
particolarmente rilevante per le aziende torinesi del settore automobilistico e, più in
generale, per la crescita del comparto Piemontese.
Entrando nel merito del partenariato occorre dire che i partner industriali, in particolare
Magneti Marelli, avranno ricadute in termini di miglioramento dei propri prodotti e servizi –
o quanto meno un’accelerazione nel loro sviluppo.
Torino inoltre dispone già di un sistema di controllo del traffico per i mezzi pubblici, gestito da
Mizar in collaborazione con 5T. Mizar è interessata quindi ai risultati del progetto perché potranno
essere considerati un primo passo in ottica di un aggiornamento futuro dei sistemi di gestione dei
mezzi pubblici.
Infine occorre menzionare un’altra possibile ricaduta nel settore della sostenibilità. Il traffico,
soprattutto nelle grandi città, è in continuo aumento e di conseguenza anche gli incidenti ad esso
correlati come mostra il grafico seguente:
Il progetto persegue la riduzione delle alte concentrazioni di traffico e la diminuzione dei tempi
di ricerca del parcheggio e quindi considera, tra le possibili ricadute indirette, anche la
potenziale riduzione degli incidenti.
9. Eventi di verifica del progetto
In considerazione della durata del progetto (2 anni) saranno istituite n. 2 milestones annuali di
verifica.
In occasione di ciascuna milestone di verifica saranno messi a disposizione per verifica sia i
deliverable tecnici prodotti fino a quel punto del progetto, sia i report finanziari.
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
10. Descrizione del progetto attraverso Work Packages
Il progetto è stato suddiviso in cinque Work Packages, con relativi task.
La suddivisione in Work Packages è stata ottenuta seguendo il modello di sviluppo a V (indicato
nella figura sottostante).
Il WP1 è di gestione e coordinamento, e ha la durata intera del progetto, in quanto segue
l’andamento delle attività.
Il WP2 si occupa di definizione delle specifiche del sistema cooperativo veicoli - infrastrutture e
dei sottosistemi componenti, ricavando per il sistema complessivo e per i componenti sia le
specifiche che l’architettura di base.
Il WP3 e WP4 sono sviluppati in parallelo temporalmente: partendo dalle architetture dei
componenti del sistema veicolo e del sistema infrastruttura, si svilupperanno i moduli hardware e
software.
Il WP5 si occuperà del test dei singoli componenti dell’architettura veicolare/infrastrutturale,
dell’integrazione dei componenti nei nodi veicolari/infrastrutturali, dei test singoli dei veicoli e dei
nodi infrastrutturali, e conseguentemente del test del sistema cooperativo complessivo, eseguito
sul Test Site. Nell’ambito del WP5 sarà anche eseguita la dimostrazione finale del progetto.
WP1
Gestione e Coordinamento
Piani di Test
WP5
WP2
Integrazione, Verifica e
Validazione su Test Site
Specifiche
Report di Test
WP3
WP4
Soluzioni algoritmiche
Sviluppo dei nodi IoT
Ciclo di sviluppo a V e work package definiti.
La tabella seguente illustra i task in base al nome, ai mesi di inizio e fine e al partner
responsabile.
D1.1.1.docx
Deliverable D1.1.1.
WP
Livello di riservatezza - PU
Nome
Gestione e coordinamento
Mese
di
fine
Partner
Responsabile
M1
M24
Magneti Marelli
Collezione report periodici di attività
tecniche e amministrative
M1
M24
Magneti Marelli
T1.1
Pianificazione attività e monitoraggio.
M1
M24
Magneti Marelli
T1.2
Rendicontazione di spese e report
tecnici periodici
M1
M24
Istituto Superiore
Mario Boella
T1.3
Rendicontazione di spese e report
tecnici periodici
M1
M24
Politecnico di Torino,
Dipartimento di
Elettronica
T1.4
Rendicontazione di spese e report
tecnici periodici
M1
M24
Hicare
T1.5
Rendicontazione di spese e report
tecnici periodici
M1
M24
C System
T1.6
Rendicontazione di spese e report
tecnici periodici
M1
M24
Capetti Elettronica
T1.7
Rendicontazione di spese e report
tecnici periodici
M1
M24
Ivrea Sistemi
M1
M6
Magneti Marelli
Definizione delle specifiche
T2.0
Integrazione contenuti tecnici del Work
Package
M1
M6
Magneti Marelli
T2.1
Definizione casi d’uso e requisiti del
sistema di comunicazione WiFi
M1
M3
Istituto Superiore
Mario Boella
T2.2
Architettura e specifiche del sistema
veicolo
M1
M6
Magneti Marelli
T2.3
Architettura e specifiche della rete di
comunicazione WiFi per veicoli e
infrastrutture
M1
M6
Politecnico di Torino,
Dipartimento di
Elettronica
T2.4
Architettura e specifiche della base dati
M1
M6
Hicare
T2.5
Architettura e specifiche del sistema di
visione
M1
M6
C System
T2.6
Specifiche del sistema di visione
M1
M6
Ivrea Sistemi
T2.7
Architettura e specifiche dei sensori per
rilevazioni ambientali
M1
M6
Capetti Elettronica
M7
M18
Istituto Superiore
Mario Boella
M15
M18
Istituto Superiore
Mario Boella
M7
M18
Istituto Superiore
Mario Boella
M7
M18
Politecnico di Torino,
Soluzioni algoritmiche
WP3
Mese
di
inizio
T1.0
WP1
WP2
IoT_|_ToI
T3.0
T3.1
T3.2
D1.1.1.docx
Integrazione contenuti tecnici del Work
Package
Comunicazione wireless tra nodi IoT.
Protocolli di comunicazione wireless
Deliverable D1.1.1.
Livello di riservatezza - PU
IoT_|_ToI
per raccolta e distribuzione dei dati
T3.3
Algoritmi di visione per controllo traffico
e gestione parcheggi
M7
M18
C System
T3.4
Piattaforme per la gestione di dati e
algoritmi di data fusion
M7
M18
Hicare
T3.5
Logiche di gestione ed integrazione
della correzione DGPS nella
piattaforma di comunicazione veicolare
M16
M18
Magneti Marelli
M7
M18
Magneti Marelli
Sviluppo dei nodi IoT
WP4
Dipartimento di
Elettronica
T4.0
Integrazione contenuti tecnici del Work
Package
M15
M18
Magneti Marelli
T4.1
Sviluppo dei nodi IoT mobili e supporto
allo sviluppo dei nodi fissi
M7
M18
Magneti Marelli
T4.2
Sviluppo del sistema di correzione
DGPS per aumentare la precisione di
posizione dei nodi mobili e sviluppo dei
nodi IoT fissi
M7
M18
Istituto Superiore
Mario Boella
T4.3
Realizzazione del sistema di visione
per monitoraggio stato traffico e
occupazione parcheggi
M7
M18
Ivrea Sistemi
T4.4
Integrazione dei sensori ambientali sui
nodi IoT
M7
M18
Capetti Elettronica
Integrazione, verifica e validazione su Test
Site
M13
M24
C System
T5.0
Integrazione contenuti tecnici del Work
Package
M22
M24
C System
T5.1
Integrazione e validazione delle
componenti HW dei nodi fissi
M13
M18
Capetti Elettronica
T5.2
Installazione ed integrazione del
sistema di visione sul Test Site e
validazione
M13
M18
C System
T5.3
Validazione della comunicazione
I2V/V2V
M13
M18
Politecnico di Torino,
Dipartimento di
Elettronica
T5.4
Installazione ed integrazione delle
componenti a bordo veicolo e
validazione
M19
M24
Magneti Marelli
T5.5
Integrazione del sistema di
comunicazione sui nodi fissi e
validazione
M18
M24
Istituto Superiore
Mario Boella
T5.6
Analisi statistica dei dati del Test Site
M13
M18
Hicare
WP5
D1.1.1.docx
Deliverable D1.1.1.
Livello di riservatezza - PU
Milestones
N.
Titolo
Organizzazione
M1.1 preliminare del
progetto
Deliverables
N.
Titolo
D1.1.1 IoT_|_ToI_DOC
D1.2.1 IoT_|_ToI_RT
M1.2 Documentazione D1.2.2 IoT_|_ToI_R
D1.2.3 IoT_|_ToI_PDT
Casi d’uso e
M2.1 requisiti del
sistema
Architetture e
specifiche dei
M2.2
sistemi
cooperativi.
Soluzioni
M3.1
algoritmiche
Nodi IoT_|_ToI
M4.1
mobili
Nodi IoT_|_ToI
M4.2
fissi
M4.3 Sistema Visione
Validazione di
M5.1
componenti
Integrazione di
tutti i sistemi a
M5.2 bordo veicolo /
infrastruttura e
validazione
Validazione
sistema
M5.3
complessivo su
test site
M1.3 Evento finale
D1.1.1.docx
D2.1.1 IoT_|_ToI_RT_CasiD’usoERequisiti
D2.1.2 IoT_|_ToI_PDT_Sistema
D2.2.1 IoT_|_ToI_RT_ArchitettureSpecificheSistemi
D2.2.2 IoT_|_ToI_PDT_Componenti
D2.2.3 IoT_|_ToI_PDT_Integrazione
D3.1.1 IoT_|_ToI_RT_SoluzioniAlgoritmiche
D4.1.1 IoT_|_ToI_P _Nodi IoT_mobili
D4.2.1 IoT_|_ToI_P _Nodi IoT_fissi
D4.3.1 IoT_|_ToI_P_SistemaVisione
D5.1.1 IoT_|_ToI_RT_ValidazioneComponenti
D5.2.1 IoT_|_ToI_RT_ValidazioneIntegrazione
D5.3.1 IoT_|_ToI_RT_ValidazioneSistema
IoT_|_ToI