2. Architetture di sistema
n questo capitolo saranno analizzate più nel dettaglio le architetture possibili per il sistema, facendo riferimento a quanto già disponibile in commercio, partendo dalla scelta del protocollo di comunicazione wireless; si effettuerà quindi un confronto tra le varie architetture, e si provvederà a scegliere quella più adatta a risolvere le problematiche presentate nel capitolo precedente.
I
2.1 Il protocollo di comunicazione wireless
Tutti i costruttori che hanno scelto di integrare un transceiver radio all’interno del casco, come detto, hanno optato per il protocollo Bluetooth.
Da cosa è giustificata questa uniformità di decisioni?
Il protocollo Bluetooth, sviluppato a partire dal 1994 da un gruppo di aziende che comprende Ericsson, Intel, IBM, Nokia, Motorola e altri, consente la creazione di una rete locale tra dispositivi radio (piconet) in cui un dispositivo assume il ruolo di master, e gestisce tutte le comunicazioni all’interno della rete. La connessione punto-punto tra due soli nodi è ottenibile come mera semplificazione della piconet complessiva. Tale rete radio opera in una banda di libero utilizzo (banda ISM) quindi non è necessaria alcuna concessione governativa per trasmettere. La portata del protocollo dipende dalla classe di potenza dei dispositivi, ma al massimo arriva a 100 metri (Power Class 1): in un sistema come quello trattato in questo lavoro di tesi è sufficiente la Power Class 2, che garantisce una
apprestiamo a sviluppare. Inoltre il protocollo Bluetooth nasce per essere proposto come standard a basso costo, e negli ultimi anni ha iniziato ad affacciarsi sul mercato “consumer”, beneficiando di fenomeni di economie di scala che hanno fatto ulteriormente crollare i costi di produzione dei dispositivi.
A tal proposito si vedano, nelle figure 2.1 e 2.2, due grafici di fonte SG Cowen Estimate che riportano le stime di mercato riguardanti i volumi di produzione ed i costi dei chipset; c’è da dire, purtroppo, che questo andamento è per ora contrastato dalle filosofie di marketing di alcuni produttori, che inquadrano il Bluetooth come un accessorio di fascia medio- alta, piú simile ad un gadget tecnologico che a qualcosa di realmente utile, ma la sempre maggiore diffusione sul mercato non potrà che scardinare questa visione.
Figura 2.1: Stime di vendita di chipset Bluetooth
Figura2.2: Andamento stimato dei prezzi per i chipset Bluetooth
Il protocollo Bluetooth nasce come standard a basso consumo e basso ingombro (infatti è stato sviluppato appositamente per applicazioni portatili), e la dimensione tipica di un chipset è paragonabile a quella di una moneta.
Tutte queste caratteristiche fanno del Bluetooth la scelta ideale quando si ha a che fare con problemi di “cable replacement” in applicazioni mobili, e quando il raggio che deve essere coperto dalle trasmissioni è limitato (si tratta pur sempre di un protocollo low power). Ultimamente si registra infatti un notevole interesse per il Bluetooth anche da parte dell’industria automobilistica, che conta, con questa tecnologia, di poter ridurre la complessità ed il peso dei cablaggi all’interno delle auto; ogni auto di nuova produzione ha infatti al suo interno svariati chilometri di cavi, il cui peso (si arriva a 50 Kg) e ingombro stanno cominciando ad influire pesantemente sul peso complessivo dell’auto, sui costi e sulla complessità di produzione, sulla difficoltà di manutenzione e persino sulla quantità di inquinanti emessi.[1]
Appurate le qualità del protocollo Bluetooth, l’analisi si sposta sul come utilizzare questo protocollo all’interno del nostro sistema. E’ opportuno partire dalla descrizione delle architetture dei sistemi di interfono Bluetooth descritti nel capitolo precedente.
Come detto, tutti questi sistemi nascono da un’evoluzione degli auricolari per telefoni GSM dotati di connettività Bluetooth. Sebbene la derivazione dagli auricolari per telefonia abbia praticamente permesso la nascita di questi sistemi, che non avrebbero visto la luce se non ci fosse stato, a monte, il lavoro di sviluppo per gli auricolari stessi, è in questa derivazione che si riscontra il “peccato originale” di queste realizzazioni:
così come il link tra auricolare e telefono consiste in un collegamento punto-punto, resta un collegamento punto-punto anche quello tra i due caschi quando si implementa la funzionalità di interfono; uno dei due caschi assume il ruolo di master della piconet, mentre l’altro assume quello di slave.
La capacità di effettuare telefonate è realizzata sconnettendo dalla rete il casco slave, e connettendo al suo posto il telefono GSM, che deve disporre della tecnologia Bluetooth; così però non solo si esclude la possibilità di effettuare chiamate a tre, ma in realtà solo uno dei due motociclisti ha a disposizione il telefono, dato che il master della piconet può cedere il suo ruolo solo se viene spento. L’accesso ad altre fonti audio (un lettore MP3 portatile, ad esempio) non è esplicitamente citato dai costruttori dei sistemi, ma teoricamente resta possibile, anche se per un solo utente ed al prezzo di disattivare la funzione di interfono, e sempre che tali fonti dispongano della tecnologia Bluetooth e supportino il profilo headset.
Potrebbe destare perplessità il fatto che tutti i costruttori abbiano scelto un protocollo dalle vaste potenzialità per poi sfruttare solo alcune di queste,
solo per non trovarsi a dover intervenire sul software che gestisce lo stack di protocollo: in realtà è sufficiente dare uno sguardo al mercato dei dispositivi Bluetooth per notare che praticamente non esistono in commercio applicazioni in cui il protocollo viene usato per implementare reti di comunicazione: per questo genere di applicazioni infatti il mercato si è orientato su protocolli diversi, ricorrendo principalmente allo standard IEEE 802.11 (Wi-Fi).
Un’architettura più adatta agli scopi di questo lavoro è stata realizzata, come prototipo funzionante, dal Dipartimento di Ingegneria dell’Informazione [2] [3] [4]. In questo sistema si superano i problemi delle altre realizzazioni ricorrendo ad una piconet Bluetooth a tre nodi: ai due nodi rappresentati dai caschi, e realizzati ricorrendo a due semplici auricolari Bluetooth per telefoni cellulari, si introduce un nodo sulla moto, ed è quest’ultimo ad avocare a se il ruolo di master della piconet, diventando inoltre un access point che rende disponibile tutta una serie di altri servizi audio, connessi ad esso con altri protocolli di comunicazione, wireless o cablati; l'access point dunque, effettuando le conversioni di protocollo e controllando i flussi di dati, si comporta da gateway. Questo nodo è dato dall’unione di un transceiver Bluetooth che riporta in banda base i dati modulati e gestisce il flusso dei dati nella piconet, e di un DSP (Digital Signal Processor), che controlla un codec e l’interfaccia utente, e che comunica con il transceiver tramite una porta UART. Si passa dunque da una rete come viene mostrata in figura 2.3, dove però i due link a radiofrequenza sono mutuamente esclusivi, alla rete che si può vedere in figura 2.4.
Figura 2.3: Architettura attualmente in commercio
Figura 2.4: architettura con rete Bluetooth a tre nodi
Si fa notare come la scelta di usare dei comuni auricolari sia particolarmente pagante da un eventuale punto di vista commerciale: il sistema centralina è compatibile con ogni dispositivo che supporta il profilo headset e potrebbe esserne venduto a parte. Inoltre il peso di un auricolare (comprensivo delle batterie necessarie al suo funzionamento) è limitato a
pochi grammi, pur disponendo di un’autonomia di alcune ore di conversazione, ed il suo ingombro è tale che una eventuale integrazione in un casco non rappresenta un problema.
La decisione di utilizzare per la centralina sulla moto (master della piconet) quella che nella terminologia Bluetooth è chiamata una configurazione host – host controller, oltre che obbligata dall’assenza in commercio di chipset bluetooth dotati “on board” di una potenza di calcolo sufficiente ad applicazioni di una certa complessità, offre anche i seguenti vantaggi:
• Il carico di lavoro del chipset Bluetooth (host controller) può essere ridotto a piacimento, partizionando l’applicazione (o meglio, lo stack di protocollo Bluetooth), affinché giri in parte sul chipset Bluetooth ed in parte sul DSP (host). Questo facilita l’integrazione del codice dell’applicazione specifica con il firmware che gestisce i livelli più bassi dello stack; d’altronde lo stesso stack di protocollo è stato pensato per facilitare questa operazione, essendo organizzato in layers orizzontali, alcuni dei quali come il layer HCI (Host Controller Interface) o quello RFCOMM sono stati previsti come punti preferenziali per la partizione.
Ovviamente quanto più si alleggerisce il carico di lavoro dell’host controller, tanto più si appesantisce quello dell’host.
• Il DSP fornisce risorse di connettività aggiuntive a quelle che si trovano integrate sul chipset Bluetooth.
Nel complesso questa architettura presenta anche degli svantaggi rispetto a quella adottata dai costruttori commerciali, o comunque dei punti in cui essa non risponde appieno ai desiderata: in particolare si possono far notare i seguenti problemi:
basso costo particolarmente stringenti a cui si è fatto riferimento nel capitolo precedente, rende critica la fase di scelta dei componenti stessi.
• La rete Bluetooth a tre nodi esclude il telefono GSM. Potrebbe sembrare strano, ad un utente che dispone di un telefono dotato di connettività Bluetooth e che voglia utilizzare un sistema realizzato “con tecnologia Bluetooth”, il non poter usare il proprio telefono con una connessione wireless. Da questo punto di vista sarebbe opportuno integrare il telefono nella piconet, lasciando al contempo la possibilità di connettere al sistema, in alternativa, un telefono non Bluetooth con una connessione cablata.
• Non è presente alcun supporto alla soppressione del rumore (eccezion fatta per gli eventuali accorgimenti meccanici che potrebbero essere presi in fase di integrazione degli auricolari nei caschi): come detto i nodi casco sono dei comuni auricolari per telefonia cellulare, e non implementano nessun algoritmo di elaborazione del segnale, che eventualmente dovrebbe essere a carico del DSP; quest’ultimo, d’altronde non ha modo di stimare le caratteristiche del rumore (banda, densità spettrale di potenza) presente all’interno dei caschi, a meno di non ricorrere ad algoritmi particolari [5].
Oltre a queste architetture già realizzate, si potrebbe dunque pensare ad un’altra configurazione per il sistema, in modo da rispondere alle precedenti osservazioni: si potrebbe pensare appunto di realizzare una piconet in grado di gestire fino a quattro nodi, includendo in essa l’eventuale telefono GSM Bluetooth, e sarebbe utile un ulteriore ingresso audio per il DSP, ingresso da
dedicare alla stima del rumore per provvedere poi alla sua cancellazione. Si giunge così al seguente schema:
Figura 2.5: Architettura con piconet a quattro nodi
Nel prossimo capitolo sarà esposta l’architettura che si ritiene più adatta a rispondere alle specifiche del sistema, e saranno motivate le scelte che hanno portato a prendere tale decisione. Si descriverà inoltre il procedimento che ha portato alla scelta sia dei componenti hardware del sistema, che della filosofia alla base della scrittura del software.
