Quanto segue si riferisce a 2 tesi per la Laurea specialistica da svolgesi
presso il DISI e altre 2 proposte da svolgersi presso MOTRONICA (www.motronica.it)
una societa' di Genova che si occupa di automazione e controllo macchine
soprattutto per ambiti portuali.
Sul primo
problema e' possibile ritagliare una Prova Triennale.
(1) Implementation of a set of functionalities for the
management of an overlay network.
Introduction
and problems
Voronoi diagrams are gaining attention in several P2P applications managing
a wide number of distributed and mobile entities, such as resource discovery in
auction-like networks or realization of networked virtual environments for
distributed MMOGRP. Some
proposals have been made to organize P2P using Voronoi tassellation (see VON
network), however the maintenance protocol is often heavy.
Clustering techniques can be used to decrease the overlay maintenance
cost.
A
solution
HyVonNe
(Hybrid Voronoi Network) is a clusered architecture,
where the space is partitioned in Voronoi regions, each one including a limited
number of nodes managed by a Region Leader, that are created and deleted
depending on the spatial density of the nodes.
The resulting two-layers structure (node space and Voronoi regions) is
scalable and extendable, allows to reduce the propagation of the entity position
updates in the network and to maintain the load balancing among regions.
Proposal
In
order to evaluate HyVonNe behaviour, it is necessary to consider some form of
simulation or emulation of such network. To
this aim we considered HyperCast, an API library to implement communication over
a P2P network organized over a Delaunay triangulation (the dual of a Voronoi
diagram). The proposal is then
to study HyperCast and to define an extention that allow to manage HyVonNe
components.
The basic operation to be defined and implemented will be the insertion, lookup (that is routing over hyvVonNe), and deletion of a node and of a Leader (Voronoi Vertex). Particular attention must be devoted to the concurrent aspects of such functionalities.
Further
reading:
•
Information on HyVonNe available at www.disi.unige.it/person/GianuzziV/2008-IJGUC.pdf
and www.disi.unige.it/person/GianuzziV/HyVonNeCisis2008.pdf
• Information
on the HyperCast software is available from www.cs.virginia.edu/hypercast.
Required
Skills
HyperCast is
written in Java, so a good knowledge of such a programming language is required.
The tests of the added features must be performed using Virtual Machines, VmWare
or User Mode Linux.
(2) Evaluation of RTP/RTCP
protocols scalability and
behaviour under a many-to-many traffic model
The
internet Real-time Transport Protocol (RTP) is a standard internet protocol for
real time traffic delivery, such as audio or video. It is usually deployed on
top of User Datagram Protocol (UDP) and used in conjunction with Real-time
Transport Control Protocol (RTCP), which is used to monitor transmission
statistics and overall quality.
RTP
is a protocol born to support audio/video multicast conference over the
internet. Today, it has been extensively used in unicast applications and is
suitable for every application more sensitive to jitter and delay than packet
loss, such as media streaming; it is the technical foundation at the heart of
VoIP applications.
The
problem
Standard
RTP usage involves a very limited number of media streams,maybe involving a very
large number of partecipants.
If
a telco company wants to build a core communication network aimedat providing
audio services based only on IP technology, the hosts of this network will have
to cope with a potentially high number of different audio streams. For example,
a base station in a cellular radio network will have an open connection for
every mobile partecipanting in a call; another example could be a media gateway
providing access to other private networks or the PSTN that must manage all
calls to the outside.
What
happens when a single host must open and maintain several RTPstreams, in the
order of tens or hundreds? The RTP protocol is quite complex, specially on the
receive side, performing operations such as synchronization and jitter
calculations, error correction, etcetera. In particular, it should be
interesting to understand how the synchronization methods scale and perform when
a single host maintains several different open streams.
Proposal
The
work could be organized in three distinct phases:
RTP
is a complex protocol. First, a careful study of the standard should be carried
out. Then, one or more open source implementations should be chosen, based on
how much complete they are, and their specific
features should be understood, along with eventual differences from the
standard.
This
phase involves the creation of an hardware and software environment
that recreates the situation described before, where every
host performs several RTP connections. This testbed must be used to collect
proper data about RTP performance and scalability with this communication
pattern, to understand if it could pose unexpected problems.
This
phase should detail what parts of the RTP standard in this context are useless
or counter-productive, define proposals to achieve better performance, and
solutions to eventual problems risen in previous phases. If time remains, an RTP
implementation could be modified to experiment some of the proposed
modifications.
I sistemi embedded utilizzati in ambiente Automotive hanno requisiti molto
stretti rispetto alla gestione delle latenze e dei tempi di riposta. In
particolare le interfacce uomo macchina richiedono un feedback continuo
all'utente per poter garantire che le informazioni siano sempre aggiornate e
consistenti con la situazione in cui l'impianto sta lavorando.
Sui sistemi embedded piu'¹ moderni viene usato un sistema operativo completo e le
sorgenti di latenza da tenere sotto controllo sono svariate, sia all'interno del
kernel, sia nelle applicazioni utente.
Filoni di ricerca
- Strumenti di analisi prestazioni hard e soft real time
- Sistemi di profiling driver nel kernel Linux
- Sistemi di profiling spazio utente, applicativi grafici e librarie
Esercitazioni in laboratorio
- Ricompilazione kernel Linux con patch real time e analisi delle prestazioni
tramite piccoli programmi scritti in C
- Utilizzo dei sistemi di profiling OProfile e SystemTap disponibili negliultimi kernel Linux con varie applicazioni grafiche
- Analisi delle prestazioni di un driver Ethernet
Obiettivo della tesi
L'obiettivo della tesi consiste nel trovare metodologie di sviluppo, sia a
livello di linguaggi, che di algoritmi, che di paradigmi di programmazione, per
migliorare la risposta in latenza (soft e hard real time) di un sistema embedded
basato su architettura x86, ARM o altro.
Metodologia
La tesi si svolgera' presso la sede di Genova di Motronica, dove il candidato
avra' accesso agli strumenti di sviluppo necessari.
Dopo essersi familiarizzato con il sistema embedded U-Vision, il candidato dovra' innanzitutto fare una valutazione delle prestazioni del sistema e delle sorgenti
di latenza piu' importanti.
In seguito dovra' , in base a questo esempio concreto, sviluppare dei metodi di
sviluppo volti a migliorare la risposta di tali punti critici. Dovra' infine applicare i metodi trovati per verificare quantitativamente le migliorie
apportate.
Sara' possibile verificare praticamente ogni stadio di sviluppo della tesi sia in
laboratorio, grazie ad un simulatore, sia sul campo, presso alcuni porti dove
sono presenti sistemi di movimentazione di Reggiane Cranes and Plants.
L'esatta localizzazione di un veicolo e' un problema fondamentale nei sistemi in mobilità .
La ricerca ha prodotto negli anni molte soluzioni a questo problema, proponendo svariati sistemi di localizzazione.
Le diverse tecniche sfruttano differenti tipi di sensore: telecamere, ultrasuoni, sensori acustici, sensori magnetici (bussole), odometri, piattaforme inerziali, GPS ecc..
Anche i dispositivi di comunicazione wireless, di cui spesso sono dotati i veicoli, possono essere usati per la localizzazione;
in particolare e' spesso possibile conoscere la potenza del segnale radio ricevuto mediante la quale si puo' ricavare una stima della distanza dalla sorgente del segnale. Quindi, usando piu' sorgenti poste in posizioni note, tramite tecniche di multilaterazione e' possibile stimare la posizione del veicolo ricevente.
Questa soluzione ha il vantaggio di non richiedere sensori aggiuntivi per la localizzazione ma, sfrutta solamente l'hardware gia' presente per la comunicazione tra i veicoli.
Filoni di ricerca
- Sistemi di localizzazione non basati sul mondo GPS.
- Algoritmi di localizzazione basati sulla base dei tempi o sulla potenza del segnale o ibridi (es. Finger print, NNSS- Nearest Neighbors in Signal Space...).
Esercitazioni in laboratorio
- Utilizzo di particolari software di simulazione (RPS: Radiowave Propagation Simulator),
che permettono di costruire delle mappe di potenza di un ambiente, a partire dal suo layout, dalla
posizione degli Access Point e degli ostacoli (es. radioplan,ns-2,...).
L'esercitazione e di creare una mappa di potenza dei segnali da un mappa di termial container fornita da noi.
- Utilizzo e studio (performance) di algoritmi di localizzazione (es. NNSS) su una mappa creata con un RPS.
Obiettivo della tesi
L'obiettivo della tesi e' quello di studiare o implementare un sistema di localizzazione per un parco di veicoli.
Ciascun veicolo deve essere dotato di un dispositivo di comunicazione wireless che fornisce la potenza del segnale ricevuto.
I veicoli, partendo da posizioni note, devono autolocalizzarsi tramite lo scambio di informazioni e il rilevamento della potenza dei segnali radio ricevuti.
Metodologia
Il cadidato dovra' innanzitutto analizzare i seguenti stati dell'arte:
-Stato dell'arte dei sistemi di localizzazione non basati sul mondo GPS (es. skyhook(*)...)
-Stato dell'arte e implementazioni dei algoritmi di localizzazione (NNSS,..).
Successivamente il candidato deve studiare o sviluppare un algoritmo che permetta ad un parco macchine di autolocalizzarsi sfruttando la comunicazione
wireless.
Inizialmente l'algoritmo viene simulato su PC, tramite programmi per la simulazione di reti di comunicazione mobili (es. ns-2) , RPS oppure realizzando un apposito simulatore in un linguaggio a scelta (C, C++, Java, Matlab ecc.).
Alla conclusione della tesi saranno effettuati dei tests nel mondo reale presso un porto dove sono presenti delle macchine della Reggiane Cranes and
Plants.
(*)
http://www.skyhookwireless.com/howitworks/coverage.php
http://www.skyhookwireless.com/developers/sdk.php