UNIVERSITÀ POLITECNICA DELLE...
Transcript of UNIVERSITÀ POLITECNICA DELLE...
UNIVERSITÀ POLITECNICA DELLE MARCHE
FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA
ELETTRONICA __________________________________________________________________________________________
Progetto e realizzazione di una Xlet per applicazioni in ambito sanitario
Relatore :
Prof. Aldo Franco DRAGONI
Correlatore:
Prof. Paolo PULITI
Tesi di Laurea di:
Marchi Erik
________________________________________________________ Anno Accademico 2005-2006
Ringraziamenti Vorrei ringraziare in primis i miei genitori che mi hanno dato la possibilità di scegliere e senza i quali
tutto questo non sarebbe stato possibile.
Un ringraziamento particolare va a tutti i miei zii, cugini e sopratutto a nonna Rina dispensatrice di
saggezza e cuoca irresistibile.
Sono grato al prof. Aldo Franco Dragoni perché devo a lui le mie conoscenze di base dell’ informatica,
grazie per avermi permesso di arricchire le mie conoscenze su una nuova tecnologia in via di sviluppo e
in particolare grazie anche per la fiducia riposta in me e nel mio progetto e per la costante disponibilità
profusa.
Ringrazio l’ Azienda Sanitaria Unica Regionale zona 7 , tutto il personale del CED e del SIA, il Dott.
Fabio Tonucci e l’Ing. Pino Giampieri per avermi fornito gli strumenti e la possibilità di realizzare
questo lavoro.
Ringrazio anche tutti gli altri professori dai quali ho potuto imparare molto e che hanno contribuito alla
mia formazione culturale.
Rendo grazie a Valentina Belfiori, Fabio Maritan e Domenico Ranieri colleghi tirocinanti che sono stati
dei più che validi collaboratori e con i quali ho condiviso questo periodo di tirocinio.
Infine, ma non per importanza, ringrazio tutti i miei amici e compagni di studio con i quali ho trascorso
e continuerò a trascorrere il mio iter accademico.
Indice ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
3
Indice
INTRODUZIONE .......................................................................................................................................6
Capitolo 1 DIGITAL TERRESTRIAL TELEVISION........................................................7
1.1 Struttura e servizi del Digitale Terrestre ...................................................................................8
1.1.1 Architettura di funzionamento...................................................................................................9
1.1.2 Servizi offerti ............................................................................................................................. 10
1.2 Interattività...................................................................................................................................... 11
1.2.1 Canale di ritorno........................................................................................................................ 11
1.2.2 SSL: supporto per canale sicuro.............................................................................................. 12
1.2.3 Scenari di TV interattiva .......................................................................................................... 13
1.2.3.1 iVoD (interactive Video on Demand).......................................................................................... 15
1.3 DTT nel Mondo ............................................................................................................................ 16
1.4 DTT in Europa .............................................................................................................................. 16
1.5 DTT in Italia .................................................................................................................................. 17
1.5.1 Il digitale a due anni dall’avvio ................................................................................................ 18
Capitolo 2 STANDARD DI RIFERIMENTO E TECNOLOGIE
ABILITANTI PER LA DTT ................................................................................... 20
2.1 Lo standard DVB (Digital Video Broadcasting) ................................................................. 20
2.1.1 DVB-T (Terrestrial) .................................................................................................................. 21
2.1.2 Tipologia delle applicazioni ..................................................................................................... 23
2.1.2.1 Applicazioni DVB-J e DVB-HTML ............................................................................................ 23
2.1.2.2 Browser di navigazione in TV ..................................................................................................... 24
2.1.3 Dal DVB-T al DVB-H: la Mobile TV ................................................................................... 25
2.2 Lo standard MHP (Multimedia Home Platform) ............................................................... 26
2.2.1 Architettura base ....................................................................................................................... 28
2.2.1.1 Livello 1: Risorse e periferiche .................................................................................................... 29
2.2.1.2 Livello 2: Software di sistema...................................................................................................... 29
2.2.1.3 API: Java TV ............................................................................................................................. 30
2.2.1.4 Livello 3: Applicazione ............................................................................................................... 32
2.2.1.5 Plug-in ...................................................................................................................................... 33
Indice ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
4
2.2.2 Profili MHP ............................................................................................................................... 33
2.2.2.1 Enhanced Broadcast .................................................................................................................. 34
2.2.2.2 Interactive Broadcast.................................................................................................................. 35
2.2.2.3 Internet Access Broadcast .......................................................................................................... 36
2.2.3 Protocolli DSM-CC Data Carousel e Object Carousel ....................................................... 37
2.3 Il decoder interattivo (Set-Top Box) ....................................................................................... 39
2.3.1 Architettura ................................................................................................................................ 40
2.3.2 Funzionalità hardware e firmware .......................................................................................... 41
2.3.3 Front-end ................................................................................................................................... 41
2.3.4 Demultiplexer MPEG-2........................................................................................................... 42
2.3.5 Video Decoder MPEG-2 e Decoder Audio ......................................................................... 42
2.3.6 Control Unit............................................................................................................................... 43
2.3.7 Bootloader.................................................................................................................................. 43
2.3.8 Funzionalità grafiche ................................................................................................................ 43
2.3.9 Interfacce livelli segnale............................................................................................................ 44
2.3.10 Software e servizi ...................................................................................................................... 44
2.3.11 Navigatore.................................................................................................................................. 44
2.3.12 Requisiti minimi ........................................................................................................................ 45
2.3.13 Telecomando ............................................................................................................................. 45
Capitolo 3 APPLICAZIONI DVB-J: XLET ............................................................................ 47
3.1 Introduzione e principio di funzionamento di una xlet..................................................... 48
3.1.1 Esempio: HelloWorld............................................................................................................... 51
3.2 Gestione delle risorse scarse ...................................................................................................... 52
3.3 Interfaccia grafica ......................................................................................................................... 52
3.3.1 Background layer....................................................................................................................... 55
3.3.2 Video layer ................................................................................................................................. 59
3.3.3 Graphics layer ............................................................................................................................ 61
3.4 Gestione degli eventi del telecomando ................................................................................... 63
Capitolo 4 AMBIENTE DI SVILUPPO.................................................................................... 66
4.1 Introduzione ................................................................................................................................... 66
4.2 Il Simulatore XletView................................................................................................................. 66
4.3 Set-Top Box da sviluppo ADB x-75......................................................................................... 68
4.3.1 Caratteristiche tecniche ............................................................................................................ 69
Indice ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
5
4.3.2 Pannello frontale ....................................................................................................................... 71
4.3.3 Pannello posteriore ................................................................................................................... 72
4.3.4 Telecomando ............................................................................................................................. 73
4.3.5 Settaggio connessione di default ............................................................................................. 74
4.3.6 Firmware upgrade ..................................................................................................................... 74
4.3.7 Upload e debug di una Xlet ..................................................................................................... 76
4.3.8 Xlet description file................................................................................................................... 77
Capitolo 5 PROGETTO E REALIZZAZIONE DEL PORTALE
INFORMATIVO A.S.U.R. ZONA 7 .................................................................... 79
5.1 Obbiettivi del progetto ................................................................................................................ 79
5.2 Descrizione del portale................................................................................................................ 79
CONCLUSIONI .......................................................................................................................................... 85
APPENDICE: Codice ASURXlet ...................................................................................................... 86
SITI E BIBLIOGRAFIA ......................................................................................................................... 99
Introduzione ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
6
INTRODUZIONE La tecnologia digitale è parte integrante della società ormai da molti anni ma, nonostante ciò, il
settore televisivo è rimasto a lungo lontano da processi d’innovazione tecnologica. Infatti è solo agli
inizi del decennio corrente che alcuni paesi come Inghilterra, Spagna, Finlandia e anche Italia hanno
avviato una politica di digitalizzazione della televisione terrestre. Tale politica produrrà la completa
sostituzione delle trasmissione televisive analogiche con trasmissioni televisive digitali (cosiddetto
switch-off) che in Italia e’ stata prevista per il 2012.
La televisione Digitale Terrestre aprirà le porte non solo ad un miglioramento in termini di qualità e
quantità delle trasmissioni televisive ma anche ad un nuovo contesto televisivo nel quale saranno
disponibili servizi interattivi. La fruibilità di un canale interattivo bidirezionale introduce uno
strumento di comunicazione innovativo che potrà essere sfruttato per attivare servizi simili a quelli
già disponibili sulla rete internet. Sia Pubbliche Amministrazioni che enti privati avranno quindi la
possibilità di offrire dei servizi.
Questo elaborato si prefigge di trattare, in modo generale, il mondo della TV Digitale Terrestre
focalizzando l’attenzione sulle tecnologie e gli standard utilizzati, proseguendo con la descrizione
dell’ambiente di sviluppo per le applicazioni MHP e in conclusione spiegando il progetto e la
realizzazione di una applicazione in grado di fornire agli utenti un servizio di informazione e
presentazione dell’Azienda Sanitaria Unica Regionale ASUR Zona 7.
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
7
Capitolo 1
DIGITAL TERRESTRIAL TELEVISION La D.T.T. ( "Digital Terrestrial Television" ) e' una realtà che si sta consolidando in questo
momento, spinta da forti pressioni politiche e dei media stessi; Innovazione optional per i
telespettatori, ma una scelta obbligata, visto e considerato che l’Italia, come altri paesi europei, ha
previsto un passaggio definitivo dalla trasmissione analogica a quella digitale (switch-off) entro il
2012.
I vantaggi immediati saranno molteplici, uno su tutti la possibilità di moltiplicare il numero di canali
trasmissibili attraverso le stesse frequenze oggi utilizzate dalla Tv analogica.
Ogni singola frequenza utilizzata in analogico, infatti, permette di trasmettere un solo canale
televisivo. Sarà dunque possibile trasmettere audio, video e dati insieme, attraverso una codifica
numerica delle informazioni. Si potrà così moltiplicare fino a cinque il numero di canali trasmessi
contemporaneamente su una sola frequenza. Ciò significa che con gli stessi televisori e le stesse
antenne di oggi, aggiungendo il decoder digitale si vedranno una cinquantina di canali anziché i
dodici attuali.
La moltiplicazione dei canali televisivi non è l’unico vantaggio. Vale la pena di evidenziare tra gli
altri, la migliore qualità delle immagini (trattasi di segnale numerico che non risente d’interferenze né
di riduzione del segnale né di disturbi), la possibilità di vedere film nel formato 16:9 anziché nel 4:3
tradizionale, la fruizione di servizi interattivi sempre più sofisticati, permettendo ai canali Tv e alle
trasmissioni televisive di inserire contenuti multimediali innovativi. Citazione www.mhp-
interactive.org . Il passaggio dalla Tv analogica alla Tv digitale coinvolgerà progressivamente oltre 50
milioni di apparecchi televisivi, praticamente tutta la popolazione italiana. Per la ricezione dei
programmi TV digitali, gli utenti dovranno possedere un apposito ricevitore (Set-Top-Box) da
collegare al proprio televisore.
I ricevitori per il DVB-T affiancheranno presto i televisori nelle case dei cittadini italiani, come
avviene per quelli DVB-S per la TV da Satellite; è dunque plausibile cercare di orientare una fetta
della ricerca nella direzione dello sviluppo di questa tecnologia, per poter fornire prestazioni e servizi
sempre migliori, muovendosi parallelamente a quelle che sono le richieste del mercato. Molteplici
sono le applicazioni che si può immaginare di realizzare avendo a disposizione una cosiddetta “TV
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
8
interattiva”, una serie di strumenti utili al cittadino per le operazioni più consuete (operazioni
bancarie, prenotazione esami clinici, espletamento di pratiche burocratiche, teletex avanzato,
connessione ad internet, …). Una consistente fonte di business potrebbe trovarsi in quelle
applicazioni che suscitano l’interesse del telespettatore medio, come il televoto, la partecipazione
diretta a quiz attraverso il telecomando, concorsi a premi, pubblicità interattiva. Oggi non si è ancora
in grado di prevedere con esattezza dove porterà l’introduzione di queste nuove tecnologie, ma è
indubbia la convergenza tra la televisione, l’informatica e le telecomunicazioni.
Al contempo, il coinvolgimento dei cittadini nella Società dell’Informazione, incontra una barriera
nella limitata diffusione del PC rispetto alla totalità della popolazione, determinando la potenziale
esclusione di una larga fascia di essa. L’idea di base resta quella di rendere l’apparecchio televisivo
uno strumento efficace e comodo per sviluppare servizi interattivi, che si aggiungono alla
tradizionale funzione di fruizione dei programmi televisivi (mantenendo, in Italia come in Europa,
l’altissimo tasso di penetrazione della televisione analogica).
Sebbene sia immediato sottolineare i vantaggi dell’innovazione tecnologica – nascita di nuovi servizi,
opportunità di crescita del settore audiovisivo, rafforzamento del grado del pluralismo informativo –
non è da trascurare l’esistenza di talune difficoltà legate al periodo di transizione.
La sfida principale è quella della ricezione da parte degli utenti, la cui riuscita è il presupposto per la
fine delle trasmissioni analogiche. La maggior parte delle famiglie, infatti, al momento dello switch-
off dovrà essere dotata dei decodificatori digitali, per il rischio che il processo tecnologico finisca per
creare nuove fratture sociali. Citazione Libro bianco sulla televisione digitale terrestre.
1.1 Struttura e servizi del Digitale Terrestre
Il passaggio alla TV digitale segna, anzitutto, l’arrivo dell’interattività. Questa innovazione è
presentata nelle sue caratteristiche per mezzo dei seguenti profili:
- Enhanced TV: è caratterizzata da applicazioni interattive che arricchiscono il programma
con contenuti aggiuntivi correlati (testo, immagini fisse, video aggiuntivo) e che permettono
forme progressive di interazione del telespettatore (sondaggio, voto, partecipazione a
giochi);
- Interactive TV: prevede l’interazione con i Centri di servizi relativi alle applicazioni
attraverso Canale di Ritorno (ad es. per mezzo di modem integrato nel decoder); l’utente
può usufruire di servizi come pagamenti o prenotazioni;
- Internet on TV: prevede l’accesso ai servizi internet tramite Canale di Ritorno;
- Personal TV: consente la personalizzazione dal punto di vista della scelta dei programmi e
dell’ora di inizio;
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
9
- Connected TV: per mezzo del terminale televisivo si gestisce una condivisione di file con
altri dispositivi domestici digitali presenti in casa.
1.1.1 Architettura di funzionamento
Alla base del funzionamento della TV interattiva vi è, innanzitutto, un flusso di contenuti da
trasmettere composto da:
- programmi TV, che contengono flussi audio, video e dati supplementari;
- Informazioni di Servizio (SI);
- Informazioni per l’Accesso Condizionato (CA);
- Flusso relativo alla Guida Elettronica dei Programmi (EPG).
Grazie alla tecnica di compressione MPEG-2, l’informazione contenuta in questo flusso di dati
rimane pressoché inalterata pure riducendo notevolmente il bitrate. Questo porta necessariamente
vantaggi in termini di banda e quindi in termini di canali trasmessi pur migliorandone la qualità.
Il multiplexer è previsto per combinare i flussi dati provenienti dall’emittente televisiva per mezzo
del fornitore dei contenuti con quelli provenienti dall’authoriting che genera le applicazioni MHP,
generando in uscita un flusso propriamente detto MPEG-2 Transport Strema (TS) .
Solo i contenuti personalizzati necessitano di collegamento al Canale di Ritorno per essere prelevati;
i contenuti comuni, nei quali coesistono informazioni multimediali e flussi informativi di diversa
natura, sono trasmessi in broadcast.
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
10
Figura 1. Architettura generale della TV interattiva
1.1.2 Servizi offerti
Il processo di creazione di servizi nell’ambito della TV digitale è nel pieno dello sviluppo, infatti con
il migliorare delle prestazioni del Set Top Box e soprattutto sfruttando migliori tecnologie di
realizzazione del canale di ritorno (oggi, nella maggior parte dei casi, realizzato tramite semplice
modem telefonico), si prevede un ulteriore incremento di servizi e della relativa qualità; tuttavia già
oggi, come accennato sopra, abbiamo una evidente innovazione nei possibili servizi:
- Electronic Program Guide (EPG): rappresenta una sorta di guida di orientamento ad alto
livello per il telespettatore con funzioni di ricerca dei contenuti per costruzione di liste di
programmi preferiti o ricerca della programmazione ad una determinata ora del giorno. In
un ampio bouquet offerto dagli operatori TV, tende ad essere un vero e proprio motore di
ricerca;
- Pay per View: prevede che il Set-Top Box venga abilitato a visualizzare un determinato
evento TV, altrimenti non disponibile, per mezzo di pagamento. Questo meccanismo viene
definito Conditional Access System (CAS);
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
11
- Servizi informativi e sociali: in questa categoria sono inclusi i servizi di T-Commerce che
prevedono televendite e acquisti attraverso la TV; servizi di T-Banking tramite portale
informativo che prevede la fornitura di servizi come l’Home Banking; servizi di T-
Government, ossia offerta di servizi di pubblica utilità, servizi di T-Health che prevedono
l’accessibilità a servizi dell’amministrazione sanitaria; inoltre servizi di meteo, oroscopo,
viabilità e servizi in ambito locale (cinema, farmacie, ecc.);
- Personal Video Recording (PVR): per questo servizio è richiesto un set top box munito
di hard-disk da utilizzare come supporto di memoria per la videoregistrazione in digitale di
contenuti audiovisivi o per effettuare download di giochi finora disponibili solo su PC e
Playstation;
- Interactive advertising: prevede che l’utente, oltre che interagire con le trasmissioni
televisive in tempo reale, possa personalizzare il flusso pubblicitario, nonché interagire con
esso richiedendo maggiori informazioni o procedendo all’acquisto del prodotto,
compatibilmente con la programmazione televisiva.
1.2 Interattività
Il settore dei servizi interattivi su DTT è senza dubbio il campo soggetto al maggiore sviluppo. Ciò è
particolarmente importante per paesi come l’Italia o la Spagna che, pur essendo piuttosto evoluti sul
fronte dell’offerta televisiva in termini di densità di reti e capacità di sviluppo di nuovo format,
hanno avuto nel corso degli anni una innovazione di prodotto confinata agli aspetti di contenuto
televisivo. Oggi, la nascita di attività per lo sviluppo di applicazioni interattive è, finalmente, una
realtà. Recentemente la TV interattiva è sbarcata alle Olimpiadi di Torino 2006 grazie ad un progetto
realizzato dalla società Interattiva con la collaborazione della Regione Piemonte, RaiUtile, Rete7 e
Toroc. Il progetto ha dato risalto al modello d'accesso multipiattaforma, l'insieme integrato di
personal computer e Tv digitale. Le applicazioni interattive e i relativi servizi dedicati ai temi dello
sport, delle notizie, degli eventi, del turismo, del traffico, del meteo, dei risultati delle gare e del
calendario.
1.2.1 Canale di ritorno
E’ il supporto all’interattività e alla multimedialità. Come già accennato, per gestire un’applicazione
interattiva, il Set Top Box deve essere collegato ad un Canale di Ritorno. Esso è un canale
bidirezionale che realizza un’interazione tra il telespettatore ed una parte server (Centro Servizi)
relativa ad una qualsivoglia applicazione interattiva. Oggi, nella maggior parte dei casi, il CdR è
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
12
realizzato con il supporto di un semplice modem telefonico interno al decoder, tuttavia tecnologie
migliori stanno facendo il loro ingresso nel mercato, è il caso di Ethernet o ADSL, ma anche di
interfacce radiomobili per accesso a rete GPRS, con la possibilità di svincolarsi dal cablaggio. Un
alto grado di interattività e di personalizzazione è possibile solo con l’utilizzo del CdR, soprattutto se
la capacità di canale è a larga banda.
1.2.2 SSL: supporto per canale sicuro
Secure Sockets Layer (SSL) è un protocollo progettato dalla Netscape Communications
Corporation, autrice del famoso browser Netscape Navigator per realizzare comunicazioni cifrate su
Internet. Nasce come base di sviluppo del protocollo TLS (Transport Layer Security). L' MHP
(Multimedia Home Platform), cioè lo standard che definisce l’interfaccia tra le applicazioni
interattive digitali e il Set Top Box, fornisce il supporto per canale sicuro SSL (esso è indispensabile,
ad esempio, in applicazioni T-Commerce, T-Banking o T-Health). Questo protocollo utilizza la
crittografia per fornire sicurezza nelle comunicazioni e consente alle applicazioni client/server di
comunicare in modo tale da prevenire il “tampering” (manomissione) dei dati, la falsificazione e
l'intercettazione.
Scopo primario di SSL è fornire sistemi di crittografia per comunicazioni affidabili e riservate, ad
esempio in applicazioni quali la posta elettronica, e sistemi di autenticazione.
Il protocollo SSL provvede alla sicurezza del collegamento garantendo:
- Privatezza del collegamento: la crittografia è usata dopo un handshake iniziale per definire una
chiave segreta. Per crittografare i dati è usata la crittografia simmetrica (DES, RC4, ecc.);
- Autenticazione: l'identità nelle connessioni può essere autenticata usando la crittografia
asimmetrica, ovvero a chiave pubblica (RSA, DSS, ecc). Così ogni client comunica in
sicurezza con il corretto server, prevenendo ogni interposizione. È prevista la certificazione
del server e, opzionalmente, quella del client;
- Affidabilità: il livello di trasporto include un controllo dell’integrità del messaggio basato su
un apposito MAC (Message Authentication Code) che utilizza funzioni hash sicure (SHA,
MD5, ecc). In tal modo si verifica che i dati spediti tra client e server non siano stati alterati
durante la trasmissione.
I protocolli di sicurezza si collocano sotto protocolli applicativi quali HTTP, SMTP e NNTP e sopra
il protocollo di trasporto TCP. SSL può essere utilizzato per aggiungere sicurezza a qualsiasi
protocollo che utilizza TCP, ma il loro utilizzo più comune avviene nel protocollo HTTPS che oggi
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
13
rende possibile applicazioni quali il commercio elettronico. SSL utilizza metodi di cifratura a chiave
pubblica e certificati a chiave pubblica per verificare l'identità delle parti coinvolte.
Le fasi basilari richieste sono:
- Negoziazione tra le parti dell’algoritmo da utilizzare;
- Scambio di chiavi segrete tramite cifratura a chiave pubblica e identificazione tramite
l’utilizzo di certificati;
- Cifratura del traffico tra le parti a chiave (segreta) simmetrica;
- Le implementazioni moderne utilizzano chiavi per la cifratura simmetrica a 128 bit o più.
1.2.3 Scenari di TV interattiva
Ad oggi gli scenari di TV interattiva sono molteplici. Nelle tabelle che seguono è presentata una
possibile classificazione di alcuni servizi interattivi secondo la categoria e secondo il tipo di CdR.
Tabella 1. Classificazione dei servizi secondo la categoria
L’insieme dei servizi che permettono l’interazione con fornitori terzi è estremamente vasto e può
andare dalla fornitura di certificati anagrafici, ai servizi di Home Banking, alla vendita di beni fisici,
alla raccolta di scommesse e/o di concorsi pronostici. Sono tutti servizi accomunati dalla necessità di
utilizzare delle funzioni in grado di appurare l’identità della persona che richiede il servizio, o quanto
meno avere la garanzia della sua solvibilità economica.
Queste funzioni si mappano in modo naturale sull’utilizzo appropriato di una Smart Card.
I portali informativi progettati in modo specifico per la navigazione televisiva, sono detti “Walled
Garden”. Essi possono essere visti come il punto di accesso unico a tutte le applicazioni di TV
interattiva che un certo operatore offre ai propri clienti. Essendo il Walled Garden stesso una
applicazione di TV interattiva, questo concetto può essere utilizzato in modo ricorsivo, costruendo
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
14
strutture di navigazione che servono per rendere disponibile l’accesso a molti walled garden. A
queste strutture si da il nome di TV portal.
Figura 2. Scenari di TV interattiva
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
15
Tabella 2. Classificazione dei servizi secondo Canale di ritorno
1.2.3.1 iVoD (interactive Video on Demand)
Il servizio di Video on Demand (su richiesta) [5] permette la visione, in qualsiasi momento, di
programmi televisivi disponibili in un archivio server. Questo tipo di servizio sta riscuotendo un
discreto successo e oggi, alcuni providers televisivi americani, forniscono servizi di iVoD (interactive
VoD). L’interactive VoD aggiunge le classiche funzionalità Fast Forward e Fast Rewind di
riproduzione veloce nei due sensi, salto in avanti e indietro e la modalità di pausa
utilizzabili durante la visione dei programmi.
Le componenti fondamentali di un sistema iVoD sono tre: il STB dell’utente (lato client), la rete di
telecomunicazione e i server con gli archivi. Il STB deve contenere, oltre all’interfaccia di rete, un
buffer di memoria e l’hardware necessario alla sincronizzazione del flusso.
Lo streaming del movie richiesto dall’utente può essere controllato grazie all’utilizzo di un
particolare protocollo chiamato Real-Time Streaming Protocol. Tuttavia il requisito più importante
resta la disponibilità di banda. Attualmente, tecnologie disponibili appropriate per il trasferimento di
dati iVoD sono SONET, ATM, ADSL e HFC. Per questo motivo attualmente si tende ancora a
servizi NVoD (Near VoD) dove una stessa programmazione è trasmessa con uno shift temporale su
più canali digitali. Un altro aspetto da tener presente è che i sistemi con archivi prevedono un
discreto grado di sicurezza, quindi controlli sui comandi utenti per la gestione del copyright, ciò si
traduce in costi per l’utente. Dal punto di vista delle case cinematografiche, questa rappresenta
un’apertura ad una nuova utenza.
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
16
1.3 DTT nel Mondo
La trasmissione di tv digitale terrestre è stata pianificata in molti Paesi al fine di sostituire l'esistente
tecnica di trasmissione analogica con quella digitale. La seguente tabella mostra il lancio del DTT in
diversi Paesi:
Tabella 3. DTT nel Mondo
1.4 DTT in Europa
La Commissione europea, che ha già emanato due recenti comunicazioni in tema di digitale terrestre
– una sul periodo di transizione dall’analogico al digitale e una sulle barriere che ancora si
frappongono all’accesso alle piattaforme a larga banda – ha manifestato l’intenzione di monitorare
questo processo, per assicurare che gli interventi di sostegno che gli Stati porranno in essere siano
conformi ai principi comunitari di libera concorrenza. Per raggiungere questo obiettivo ha invitato
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
17
tutti gli Stati membri a rendere note le proprie strategie, con l’obiettivo di stimolare il più possibile la
transizione rapida ai sistemi di radiodiffusione in tecnica digitale, cercando di minimizzare gli
svantaggi del breve periodo legati alla necessità di operare una modernizzazione tecnica a tutti i
livelli. Il digitale lanciato in Europa inizialmente da poche nazioni come Gran Bretagna, Svezia,
Finlandia, e Spagna non ha avuto gran successo, infatti il massimo di telespettatori realizzato dalle tv
era intorno ai 200.000 utenti; il sistema ha compreso che il servizio offerto deve essere gratuito
(infatti, in Inghilterra e' ricevuto oggi da un numero d'utenti intorno ai 2 milioni); successivamente il
resto delle nazioni Europee si è lanciato in questo progetto.
1.5 DTT in Italia
Per quanto riguarda le date previste per lo switch-off, l’Italia è stata il primo Paese a porsi come
obiettivo (legge n. 66 del 2001) il completamento del passaggio al digitale entro il 31 dicembre 2012.
Il processo di trasformazione viene accelerato e favorito anche attraverso la definizione di una
disciplina transitoria che stabilisce le tappe intermedie per lo sviluppo della nuova tecnologia ed
agevola la diffusione presso le famiglie italiane dei nuovi apparati di ricezione; norme miranti a
realizzare una transizione in tempi rapidi, preferibilmente senza penalizzare l’utenza.
Sono inoltre previsti, già all’atto di approvazione della legge: una fase di avvio della nuova tecnica
trasmissiva con la coesistenza del sistema analogico e del sistema digitale; una temporizzazione
precisa, a partire dal 1° gennaio 2004, degli obblighi di copertura dei multiplex affidati alla
concessionaria del servizio pubblico radiotelevisivo.
L’obbligo per tutti gli altri operatori che intendono ottenere la licenza di operatore di rete di
raggiungere una copertura non inferiore al 50 per cento della popolazione o del bacino locale; Il
primo approccio al digitale terrestre in Italia è stato caratterizzato da una notevole spinta da parte
delle principali emittenti, che sin dai primi mesi del 2004 hanno investito numerose risorse;
esemplificativo può essere lo schema di seguito riportato.
L'Italia sarà, assieme alla Finlandia, il primo paese a fare lo switch-off definitivo (2012), mentre
l'ultimo sarà la Francia nel 2015, ammesso che le iniziative intraprese rispettino i termini fissati
(infatti non è una data troppo realistica, ma perlomeno serve a tracciare una strada per la
sperimentazione). Positivo sarà l’impatto derivante all’economia dalla messa in moto di un
importante processo di investimenti da parte degli operatori del settore e di spesa da parte degli
utenti.
Si tratta di un processo che non investe solo l’Italia ma anche la maggior parte dei Paesi dell’Unione
europea.
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
18
Oggi non si può ancora apprezzare la trasmissione digitale terrestre al cento per cento. Il vantaggio
che può apportare al momento è una visione più nitida delle immagini. L’introduzione della
televisione digitale terrestre gioca un ruolo di primo piano perché questa tecnologia rientra tra quelle
che realizzano l’accesso multipiattaforma a larga banda ed ampliano le possibilità di scelta dei
cittadini; si tratta, insomma, di un salto tecnologico di valore esponenziale. Il dato che è emerso dalla
recente Conferenza Ministeriale Europea, dove si sono confrontate le esperienze in atto nei vari
Paesi, è che ci si stia trovando di fronte ad una semplice trasformazione tecnologica, ma che riveste
implicazioni di carattere sociale, economico e culturale.
1.5.1 Il digitale a due anni dall’avvio
Oggi, in Italia, la Televisione Digitale Terrestre DTT (Digital Terrestrial Television) affianca il servizio
analogico, che continua ad essere erogato perché utilizza canali differenti, e consente di fruire di
insiemi di programmi (multiplex o bouquet). Un multiplex, oltre ai programmi presenti sulle reti
analogiche televisive, radiofoniche e della filodiffusione, offre una programmazione aggiuntiva (ad
esempio, RaiUtile, Rai Doc-Futura, RaiNews24, RaiEdu1, ecc., nel caso dell’azienda RAI).
Figura 3. Ricezione del segnale digitale terrestre in Italia
Capitolo 1: Digital Terrestrial Television ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
19
Nel secondo anno dall’avvio sono presenti sull’intero territorio nazionale 7 multiplex. Vi sono
inoltre numerosi multiplex locali che trasmettono solo in alcune ore. In buona parte del territorio
nazionale è ricevibile almeno un multiplex, assicurando a più del 70% della popolazione l’accesso al
servizio (Figura.3).
La Sardegna e la Valle d’Aosta sono regioni da primato: saranno infatti tra le prime d’Europa a
passare interamente al digitale terrestre, ovvero non sarà più possibile vedere canali analogici e la
popolazione dovrà munirsi di STB per ricevere il segnale.
Figura 4. Programmi televisivi e radiofonici con copertura superiore al 50% della popolazione (updated April 2006)
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
20
Capitolo 2
STANDARD DI RIFERIMENTO E TECNOLOGIE ABILITANTI PER LA DTT
Nel corso del primo capitolo si è fatto breve cenno agli standard che regolano il sistema televisivo
digitale: questi sono visti più in dettaglio in questo capitolo. La componente interattiva della TV
digitale è stata standardizzata a livello europeo attraverso la specifica DVB-MHP (Digital Video
Broadcasting – Multimedia Home Platform) che definisce la piattaforma standard per la
distribuzione ed esecuzione di applicazioni televisive su STB, nonché le specifiche per il loro
sviluppo. La combinazione di STB, piattaforma MHP e canale di ritorno è il fattore abilitante lo
sviluppo dei servizi.
2.1 Lo standard DVB (Digital Video Broadcasting)
La Direttiva europea del 95/47/CE del Parlamento Europeo, del 24 ottobre 1995, relativa
all’impiego di norme per l’emissione di segnali televisivi, stabilisce, riassumendo brevemente, che
«Tutti i servizi televisivi trasmessi ad utenti della Comunità Europea via cavo, satellite ed etere,
devono, nel caso di trasmissioni digitali, utilizzare un sistema di trasmissione standardizzato da un
ente europeo di standardizzazione riconosciuto».
All'origine delle attività europee per lo sviluppo delle tecnologie di trasmissione digitale è nato
quindi il progetto Digital Video Broadcasting (DVB), una vera e propria commissione per lo
sviluppo delle piattaforme digitali, promosso dalla Commissione Europea proprio con lo scopo di
definire una serie di standard comuni.
Al progetto partecipano oltre 300 società di 35 paesi, esse sono direttamente coinvolte nei diversi
settori dell'industria televisiva: la trasmissione, la produzione dell'hardware, lo sviluppo del software,
la gestione delle reti, la produzione dei contenuti. Il progetto DVB ha lo scopo di stabilire un unico
standard condivisibile su scala europea per le trasmissioni televisive digitali. In base al canale
trasmissivo, al tipo di modulazione e al tipo di applicazione digitale, lo
standard DVB si divide in alcuni sotto standard: DVB-S2 (Satellite 2nd generation), DVB-T
(Terrestrial), DVB-C (Cable) e DVB-H (Mobile). Quest’ultimo si propone di rendere mobile la
distribuzione dell’informazione broadcast per permettere ai palmari e agli smartphone di ultima
generazione di attivare una ricezione televisiva, eventualmente sfruttando i network digitali terrestri.
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
21
Fino ad ora l’operato del consorzio DVB è stato encomiabile (basti pensare che gli standard sono
stati recentemente adottati anche dal Giappone e da altri paesi non europei). L’ETSI, l’ente di
standardizzazione europeo, ha pubblicato un set di standard derivati dalle specifiche del progetto
DVB. Di conseguenza tutti i servizi digitali televisivi in Europa sono conformi a tali standard DVB
dell’ETSI. La Direttiva stabilisce anche che «In questo contesto, un sistema di trasmissione
comprende i seguenti elementi: formattazione dei programmi (codifica di sorgente dei segnali audio
e video, multiplazione dei segnali) ed adattamento ai mezzi trasmissivi (codifica di canale,
modulazione e tecniche di dispersione dell’energia) ».
La Direttiva esclude quindi, dal suo ambito di applicabilità, i rimanenti elementi (gestione di
applicazioni, accesso condizionato, sicurezza); l’assenza di tali specifiche ha fatto sì che nella
maggioranza dei Paesi Europei la televisione digitale è stata lanciata da operatori di televisioni a
pagamento che hanno utilizzato differenti standard proprietari per creare mercati verticali.
La loro motivazione si è fondata sul fatto che la mancanza di interoperabilità apportasse un
vantaggio competitivo, legando gli utenti ad una specifica piattaforma. Il regolatore europeo è stato
generalmente riluttante a intervenire su tale problema, al fine di non scoraggiare gli investimenti
nascenti nel settore con vincoli troppo stringenti. Come conseguenza sono state sviluppate
molteplici interfacce software dette API (Application Programming Interface), tutte incompatibili tra
loro. In particolare, i programmi multimediali e interattivi non possono essere eseguiti su ogni
piattaforma, ma vanno sviluppati con riferimento ad una particolare specifica di API. Aspetti
tecnologici che concorrono nella piattaforma digitale In generale si può dire che ogni applicazione
multimediale o interattiva utilizzerà le funzionalità disponibili nel decoder. L’esistenza di varie norme
rende problematica la ricevibilità dei programmi diffusi dalle varie emittenti con un qualsiasi STB.
Per la gestione delle applicazioni, ad esempio, esistono la norma ISO-MHEG5 già in esercizio
commerciale nel Regno Unito e – successiva in ordine di tempo - la norma ETSI/MHP, più
flessibile della prima, in gran parte consolidata e recentemente entrata definitivamente in esercizio in
molti Paesi Europei, ponendo probabilmente le basi per la soluzione del problema sopra citato.
2.1.1 DVB-T (Terrestrial)
E’ lo standard in uso nella trasmissione digitale terrestre e consente la trasmissione e la ricezione di
segnali per mezzo di una normale antenna, disponendo solo di un decoder TV.
E’ il più sofisticato e flessibile standard del sistema DVB se si esclude il DVB-H.
La tecnica di modulazione è di tipo COFDM (Coded Orthogonal Frequency Division Multiplex)
con costellazioni delle portanti QPSK, 16-QAM e 64-QAM, una soluzione tecnica avanzata che
consente di configurare i parametri di trasmissione in modo flessibile per meglio adattarsi alle
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
22
caratteristiche del canale di diffusione terrestre. Il bitrate varia dai 5 Mbps ai 32 Mbps. Le frequenze
utilizzate sono nelle bande VHF/UHF. Inoltre supporta il protocollo internet.
Il sistema DVB-T permette la ricezione fissa, portatile e mobile. Sono possibili due modalità
operative: con 2K portanti per le reti di diffusione convenzionali multifrequenza (MFN), e con 8K
portanti per operare anche su reti a singola frequenza (SFN). L’introduzione di reti SFN, non
possibile nelle trasmissioni televisive analogiche, consente un’utilizzazione ottimale dello spettro.
La definizione della specifica DVB-T risale al novembre 1995, con approvazione come standard
ETSI nel febbraio 1997; il processo di normalizzazione, piuttosto lungo e complesso, è stato
influenzato da vari fattori:
- a complessità tecnica del problema, dovuta anche alla maggiore ostilità della propagazione
del segnale elettromagnetico nelle bande terrestri VHF/UHF rispetto alla diffusione via
satellite;
- la congestione dello spettro di frequenza per la diffusione televisiva terrestre; l’interesse di
soddisfare nuove modalità operative su reti isofrequenziali SFN) anche a grande copertura;
- i diversi piani di introduzione dei servizi digitali terrestri formulati dalle varie
amministrazioni europee.
Figura 5. Penetrazione DVB-T nel mondo (©www.dvb.org - updated Aprile 2006)
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
23
2.1.2 Tipologia delle applicazioni
Le applicazioni possono risiedere permanentemente su un terminale, essere installate oppure
scaricate. Quelle che offrono funzionalità specifiche per un determinato terminale appartengono alla
prima categoria. La seconda e la terza categoria rappresentano le applicazioni che di fatto vengono
offerte agli utenti dai broadcasters.
Queste ultime sono basate su tecnologie Java e HTML e, per poterle eseguire, non necessitano di
alcuna risorsa aggiuntiva sul termina
2.1.2.1 Applicazioni DVB-J e DVB-HTML
Le applicazioni basate su Java prendono il nome di "applicazioni DVB-J" mentre quelle basate
sull’HTML prendono il nome "applicazioni DVB-HTML".
Il DVB-HTML (DVB Hyper Text Mark-up Language) ha avuto finora poco successo, soprattutto
per la sua complessità. Le applicazioni create con queste tecnologia nascono dall’utilizzo di una
versione modularizzata del linguaggio XHTML 1.1 : questo standard unisce i linguaggi di marcatura
HTML e XML per facilitare la creazione di contenuti e supportare più applicazioni: gli elementi
fondamentali (in pratica l'insieme di tag che definiscono la struttura di un documento) sono
raggruppati in una serie di moduli indipendenti, che possono essere implementati o esclusi secondo
le necessità. Gli strumenti designati per curare l’aspetto visuale ed estetico dell’applicazione sono i
CSS2 (Cascading Style Sheets, seconda specifica); il contenuto è visto separato dall’applicazione ed
entrambi possono essere modificati più agevolmente. Inoltre il DVB-HTML prevede le forme di
rappresentazione DOM (Document Object Model), ovvero le applicazioni assumono una struttura
ad albero in maniera da essere neutrali per la piattaforma mentre il linguaggio di scripting resta
comunque un linguaggio etichettato Java, cioè ECMA Script. Un ultimo fattore interessante è
rappresentato dalla possibilità di integrazione tra la parte HTML e il media broadcasting; tuttavia
queste implementazioni restano complicate e poco flessibili.
DVB-J rappresenta lo standard più diffuso, basato su un subset di linguaggio di programmazione
Java. Esso costituisce un software intermedio e aperto per la messa a punto di molti tipi di
applicazioni e servizi anche con modalità interattive.
Le applicazioni DVB-J sono dette Xlet; esse sono eseguite dalla Java Virtual Machine del ricevitore
(unica per tutte le applicazioni) che implementa le Java APIs (Application Programming Interface)
fornite dal middleware MHP per gestire l’accesso alle risorse del ricevitore e rendere l’applicazione
indipendente dal software e dal terminale. Ogni servizio (canale TV) include una AIT (Application
Information Table) per mezzo della quale è possibile ricostruire il flusso dati ricevuto in broadcast in
maniera corretta: essa contiene informazioni sui campi e sui bits. Le applicazioni DVB-J verranno
approfondite nel capitolo successivo.
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
24
2.1.2.2 Browser di navigazione in TV
Diversi produttori di software stanno anticipando di fatto la disponibilità di una funzione che non è
compresa nei correnti profili di standard, ovvero quella di riconoscere, interpretare e visualizzare su
televisione pagine scritte in DVB-HTML per mezzo dei browser.
Questo nuovo livello risulta tipicamente un oggetto Java che riceve le applicazioni interattive
sottoforma di dati HTML che poi visualizza a video tramite opportune chiamate alla piattaforma
MHP nativa. E’ permessa la navigazione di pagine HTML sia in locale sul STB, sia in modo
interattivo tramite l’utilizzo del Canale di Ritorno. Il browser occupa circa 300 KByte nel flusso
MPEG. All’interno dei browser possono essere inseriti oggetti specifici per la compilazione di
moduli a schermo tramite tasti del telecomando o tastiera virtuale su schermo oltre che suite di
strumenti per lo sviluppo di applicazioni interattive, client per e-mail, moduli per invio e ricezione di
SMS e MMS, nonché strumenti di conversione lato server per generare pagine DVB-HTML a
partire da pagine HTML già pubblicate su Internet.
Figura 6. Esempio di browser in TV
I più famosi prodotti disponibili sul mercato sono Ortikon Ace Browser e Pontegra Browser.
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
25
2.1.3 Dal DVB-T al DVB-H: la Mobile TV
Sfruttando i network digitali terrestri, oggigiorno è possibile permettere ai palmari e gli smartphone
di attivare una ricezione televisiva. Questa evoluzione della tecnologia digitale terrestre è
standardizzata a livello fisico-trasmissivo dal DVB-H (DVBHandheld).
Ma non è questo l’unico standard di riferimento per la Mobile TV: in Corea, ad esempio, ma anche
in altri paesi, lo standard adottato è T-DMB (Terrestrial – Digital Multimedia Broadcasting); esiste
anche la soluzione chiamata MediaFlo, proposta da una società di tecnologia americana
(Qualcomm). Il DVB-H è uno standard dell’ETSI e sono state impegnate ben 25 società per la
stesura del rapporto finale del gruppo di lavoro e per la validazione. In Italia, Mediaset e Vodafone
hanno stretto un accordo che sviluppa e rafforza il lancio tecnologico e commerciale della TV
digitale terrestre in mobilità con tecnologia DVB-H, così Vodafone utilizzerà la capacità del
multiplex DVB-H di Mediaset. Si aprono nuovi scenari: le tecnologie del mondo Mobile e quelle del
Media Broadcasting sono sempre più complementari che non alternative: la rete televisiva è ottima
per trasmissioni broadcast unidirezionali ad un grande numero di utenti, mentre la rete mobile ha il
suo punto di forza nella simmetria del canale.
Figura 7. Esempio di Mobile TV
La ricezione della TV mobile deve coesistere con le altre interfacce senza fili presenti nel terminale,
compresi i canali RF del cellulare, il Bluetooth, il Wi-Fi, ecc.; in paesi dove le reti GSM usano la
banda dei 900 MHz (reti GSM900, come, ad esempio, accade anche in Italia), un servizio che utilizza
lo stesso terminale dovrà adottare frequenze inferiori a 700 MHz (canale 49 UHF) per evitare
interferenze con il servizio GSM900 nello stesso terminale. Questi limiti non si applicano alle reti
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
26
GSM che usano le bande di frequenza di 1800 o 1900 MHz (reti GSM1800/1900) o alle reti 3G co-
residenti con la MDTV nello stesso apparecchio.
Attualmente la durata delle batterie rimane l’aspetto più problematico; tutti i moderni sistemi di TV
mobile implementano tecniche di risparmio delle batterie (Time-Slicing o Bandwidth Shrinking) e le
nuove soluzioni di silicio MDTV sono ottimizzate per consumi veramente bassi. Tuttavia, il
problema perenne della durata delle batterie verrà peggiorato dalla contemporanea presenza, nello
stesso terminale, di GPRS/Edge, macchina fotografica, giochi, radio e lettore Mp3.
Una delle maggiori battaglie nel controllo d’accesso dei telefonini si svolge nella gestione della Guida
Elettronica ai Servizi (ESG), che vede come protagonisti i produttori di telefonini, gli operatori e gli
sviluppatori di API per l’ESG e per il middleware della televisione digitale. I sistemi di TV digitale in
mobilità, come gli altri sistemi di Pay TV digitale, richiedono un accesso condizionale (CA) e
soluzioni di gestione digitale dei diritti (DRM). Questa è un’altra battaglia di controllo degli accessi
dei terminali, che è particolarmente sentita nel DVB-H dove sta avvenendo una lotta commerciale
tra i produttori di telefonini e i tradizionali produttori di CA per il DVB.
2.2 Lo standard MHP (Multimedia Home Platform)
Fino a pochi anni fa, lo scenario del broadcasting digitale in Europa, presentava una struttura di tipo
verticale; vi erano, cioè, sviluppi secondo soluzioni proprietarie degli elementi fondamentali per la
ricezione dei servizi interattivi, quali le API, per interpretare le applicazioni garantendo la corretta
visualizzazione. In questo contesto, svariati tipi di ricevitori erano presenti sul mercato, ognuno
abilitante ad un accesso condizionato proprietario.
Negli ultimi anni, invece, si è consolidata una forte tendenza ad adottare soluzioni comuni. Un
mercato orizzontale ha suscitato forte interesse e ha portato verso la definizione di una piattaforma
comune, quindi specifiche comuni e regole comuni per la distribuzione e le esecuzioni di
applicazioni TV su Set Top Box. Nasce quindi lo standard aperto MHP (Multimedia Home
Platform).
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
27
Figura 8. Penetrazione MHP nel mondo (©www.dvb.org - updated Aprile 2006)
Questo standard permette di gestire ed attivare applicazioni diffuse attraverso il segnale broadcast
della Televisione Digitale Terrestre, nonché interagire con esse. Supporta molti generi di
applicazioni, quali EPG, teletext super, E-commerce. Il nucleo della piattaforma MHP è basato su
tecnologia DVB-Java (DVB-J), con un sistema di astrazione dalle risorse fisiche della piattaforma, ed
include una macchina virtuale, chiamata “Java Virtual Machine”. Oggi i produttori di STB seguono,
pertanto, la normativa MHP.
Questo standard è aperto all’utilizzo di ogni soggetto interessato, anche non membro del DVB,
permettendo a gruppi diversi di interoperare, rispettando le specifiche minime della piattaforma; gli
apparati di ricezione diventano intercambiabili tra loro e i gestori delle reti possono utilizzare servizi
diversi verso apparati diversi. I principali benefici della specifica MHP (come per qualunque
standard pubblicato) sono:
- Standard aperto, orientato a garantire la piena interoperabilità tra qualsiasi programma
irradiato e qualsiasi tipo di ricevitore a casa dell’utente (fatta salva la distinzione tra profili);
- Costi più economici per le licenze di utilizzo della piattaforma, rispetto all’utilizzo di
piattaforme proprietarie;
- Possibilità di scegliere tra molti più fornitori, che non nel caso di soluzioni proprietarie.
Poiché si prevede che a lungo termine lo standard DVB-MHP sarà probabilmente adottato quasi
universalmente; la sua introduzione destrutturerà il modello di mercato verticale o proprietario delle
piattaforme software esistenti degli attuali service providers. Tuttavia, nel breve-medio termine,
l’affermazione della piattaforma MHP potrà incontrare vari problemi di affermazione. Lo standard
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
28
presenta anche alcune lacune, tra queste quella di non coprire pienamente l’aspetto dell’accesso
condizionato per il quale, poiché si entra nel campo della Pay Tv, esistono molti standard proprietari
e non si può sperare in nulla di più che nella presenza di STB con Common Interface, cioè con un
ingresso (slot) in grado di ospitare schede del tipo PCMCIA per il supporto di vari standard di
crittazione del segnale televisivo.
In questo modo, l’utente può con lo stesso apparecchio, cambiando solo la scheda PCMCIA,
ricevere canali crittati secondo vari standard.
2.2.1 Architettura base
Lo standard MHP si configura come una piattaforma organizzata su tre distinti
livelli:
1. livello delle applicazioni;
2. livello del software di sistema;
3. livello delle risorse hardware e software;
Il livello del software di sistema gestisce il ciclo di vita delle applicazioni; inoltre controlla i
componenti hardware e le interfacce utente facendo da filtro tra le Xlet in arrivo e le risorse:
quest’ultime comprendono le interfacce verso l’esterno.
Figura 9. Architettura base dello standard MHP
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
29
2.2.1.1 Livello 1: Risorse e periferiche
Le risorse e periferiche (interfacce verso l’esterno) del terminale MHP sono standardizzate solo in
parte, è presumibile pensare che lo svilupparsi della tecnologia porti ad un relativo accrescimento
delle capacità elaborative dei Set-Top-Box. Quella descritta in Tabella 4 è una dotazione solo
ipotetica, dipendente anche dalle scelte commerciali dei produttori di apparecchiature.
Tabella 4. Risorse e periferiche del terminale MHP
2.2.1.2 Livello 2: Software di sistema
Il Software di sistema del terminale MHP ha accesso diretto alle informazioni audio/video ed, in
generale, a tutti i dati trasmessi in conformità degli standard DVB ed MPEG; vengono qui
controllati i componenti hardware, e le interfacce con l’utente, cioè quegli elementi di basso profilo
annoverabili all’ultimo livello dell’architettura funzionale del terminale MHP. Il Software di sistema è
composto da uno strato detto HAL (Hardware Abstraction Layer) per la gestione delle
interconnessioni a basso livello (fisico/elettrico) e da uno strato software (Sistema Operativo) per la
gestione complessiva delle funzionalità del terminale. Il software di sistema è caratterizzato in prima
parte da una Java Virtual Machine (Java VM), che rende il sistema operativo molto semplice e,
soprattutto, estremamente aperto (per quella che è la filosofia del Java stesso); i terminali MHP sono
quindi equivalenti dal punto di vista strutturale, differenti solo in termini di prestazioni, anche perché
le applicazioni stesse devono essere realizzate in linguaggio Java, supportate da interfacce API MHP
(interfacce software con capacità funzionali e procedurali identiche per ogni terminale MHP).
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
30
Figura 10. Architettura del software di sistema
2.2.1.3 API: Java TV
Le API (Application Programming Interface) consentono alle applicazioni di richiamare funzioni del
sistema operativo e utilizzare risorse hardware del STB con modalità unificata, indipendente dalle
applicazioni stesse. In altre parole, le API sollevano gli sviluppatori di applicazioni dal la necessità di
conoscere i dettagli realizzativi del STB e dei suoi elementi hardware. Si può parlare a questo punto
di una vera e propria estensione della piattaforma Java, creata appositamente per implementare tutte
le funzionalità necessarie per la tv digitale (streaming audio e video in diversi formati, controllo
dell'accesso condizionale, accesso ai canali di dati e a servizi informativi, controllo di sintonizzazione
per la selezione ed il cambio di canale, controlli grafici on-screen, sincronizzazione dei media,
controllo del ciclo di vita delle applicazioni); tale piattaforma è nota come Java TV, ufficialmente
adottata dal DVB per il progetto MHP.
L'ambiente software è costituito dalla piattaforma Java, dall'API JavaTV e da un RTOS (real time
operating system). A livello più alto, le applicazioni possono utilizzare le librerie di classi dell'API
JavaTV o della piattaforma Java. Il sistema operativo controlla l'hardware attraverso un insieme di
controlli (device drivers), fornisce a livello di sistema il supporto necessario all'implementazione della
Java VM. Le APIs incapsulano le funzionalità delle librerie del sistema che controllano l'hardware
specifico perla televisione. Le APIs JavaTV forniscono una visione astratta del sistema che permette
alle applicazioni (e quindi agli sviluppatori) di utilizzare le risorse hardware in forma generica.
Questo approccio rende possibile la portabilità delle applicazioni create con queste APIs.
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31
Figura 11. Livelli di architettura del JavaTV
Gli operatori televisivi con approccio “verticale” verso il mercato hanno ovviamente mostrato
scarso interesse per gli standard ed in particolare per quelli riguardanti le API per la gestione della
multimedialità e dell’interattività; per esempio nel Regno Unito, che è il Paese europeo ove la
televisione digitale ha raggiunto la penetrazione più alta (presente presso oltre il 40 per cento delle
famiglie), ogni piattaforma digitale ha scelto una API differente. Quindi un operatore generalista
come la BBC dovrebbe diffondere i suoi servizi digitali interattivi in formati diversi, se volesse
raggiungere tutti gli utenti dotati di STB digitali.
Si può ipotizzare un chiaro interesse dei grandi operatori del settore ad adottare la piattaforma MHP.
Tuttavia, nel breve termine lo standard MHP risulta svantaggiato sul mercato:
- Non è implementato su tutti i decoder oggi in commercio;
- Richiede processori più veloci e potenti di quelli necessari in decoder funzionanti con
standard già in commercio;
- Richiede un maggior quantitativo di memoria per la gestione e l’esecuzione delle
applicazioni interattive;
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
32
- Consente l’accesso Internet solo con il profilo più avanzato e quindi più costoso.
A causa dei requisiti hardware migliori sono previsti costi più elevati rispetto alle soluzioni basate su
piattaforme esistenti. È tuttavia prevedibile che solo tra 2/3 anni i costi associati al sistema MHP
saranno competitivi rispetto ai costi offerti da soluzioni più semplici.
L’uso di piattaforme con APIs differenti rappresenta un ostacolo per lo sviluppo della televisione
digitale terrestre. Le APIs MHP offrono la possibilità di uno standard universale.
Tuttavia resta importante prendere in considerazione soluzioni di APIs aperte, sebbene con
funzionalità più limitate. È indubbiamente necessario che a livello nazionale sia chiara la migrazione
a medio - lungo termine, verso lo standard delle APIs MHP.
2.2.1.4 Livello 3: Applicazione
Un’applicazione è la realizzazione funzionale di un servizio interattivo composto da moduli
programmabili che richiedono funzionalità specifiche residenti nell’hardware o nel software del
terminale. Nella filosofia MHP le applicazioni sono il nodo centrale, tutto il contesto ruota intorno
ad esse;
Lo standard MHP supporta una grossa varietà di applicazioni come:
- EPG (Electronic Program Guide);
- Servizi informativi, teletext avanzato;
- Servizi interattivi, navigazione vincolata, navigazione aperta su Internet;
- Servizi transattivi, servizi per e-commerce.
Tuttavia, non si prevede che ogni STB supporti tutta questa varietà di applicazioni (per venire
incontro ad una situazione di utenza con esigenze molto differenziate e per proporzionare i costi
degli apparati di utente).
Le applicazioni possono essere di tre tipi:
- Residenti: Contengono funzionalità esclusive offerte in modo differente a seconda del
decoder considerato; costituiscono un fattore di differenziazione dei terminali ed un motivo
di competizione commerciale tra i produttori;
- Istallabili: Contengono funzionalità aggiuntive che possono andare ad integrare il
funzionamento delle applicazioni residenti; potrebbero essere offerte da operatori specifici
o dai fornitori dei programmi;
- Scaricabili: Devono essere conformi allo standard; si presume vengano offerte dagli
operatori di servizi telivisiviper arricchire il bouquet dell’offerta al consumatore.
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
33
2.2.1.5 Plug-in
Una soluzione a tutti quei problemi derivanti dall’immissione sul mercato di un nuovo prodotto (in
questo caso lo standard MHP) si trova nell’utilizzo di appositi plug-in: trattasi di componenti
software da installare nei terminali MHP per rendere compatibili i prodotti delle tecnologie
preesistenti (e per evitare che venga posto un freno allo sviluppo del nuovo standard).
Sono previste due tipologie di plug-in:
- Tipo A: Applicato alle tecnologie di più recente ideazione, costituito essenzialmente da uno
strato software per la conversione dell’interfaccia non-MHP (una sorta di traduzione delle
applicazioni). Può essere realizzato e fornito da soggetti molteplici.
- Tipo B: Si applica per aggirare l’architettura MHP, consentendo alle applicazioni di
accedere direttamente all’HAL, alle periferiche o alle risorse del terminale in genere. Deve
essere fornito dai costruttori di terminali.
Figura 12. Plug-in prevista per la specifica MHP
2.2.2 Profili MHP
La piattaforma MHP definisce tre profili di ricevitori (paragonabili a tre aree di interesse
commerciale), basando la suddivisione sulla tipologia di applicazioni supportate dagli stessi:
- Enhanced Broadcasting - EB
- Interactive Broadcasting - IB
- Internet Access – IA
A loro volta i tre profili vengono formalmente divisi in due diversi livelli evolutivi (non escludendo
la possibilità di creare ulteriori livelli e profili con l’affermarsi di quelli esistenti).
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
34
Le interfacce software (APIs) che le applicazioni possono utilizzare sono compatibili tra i profili; ciò
che varia è la disponibilità di predefiniti sottoinsiemi di interfacce, in base alla conformità ad uno o
più profili.
Figura 13. I profili implementativi
La specifica MHP definisce una serie di regole funzionali, tra le quali quelle che governano il ciclo di
vita delle applicazioni scaricabili sulla piattaforma, che sono comuni ai tre profili. Ad ogni profilo di
implementazione corrispondono dotazioni hardware di cui la piattaforma deve obbligatoriamente
disporre ed altre che sono considerate raccomandate o opzionali; varia conseguentemente la
presenza delle interfacce software necessarie a gestire tali periferiche. Alcune interfacce software
possono essere considerate comunque opzionali. Per disciplinare e facilitare l’interpretazione di una
specifica così complessa, è presente nello standard una dettagliata descrizione di quelle che sono le
prestazioni minime.
2.2.2.1 Enhanced Broadcast
Permette servizi di radiodiffusione avanzata per arricchire e completare i servizi televisivi di base per
mezzo di contenuti multimediali (ad esempio brevi audio-video inseribili in notiziari, film, eventi
sportivi, ecc.). Inoltre tale profilo permette la trasmissione di servizi di EPG, teletext avanzato e
giochi, memorizzandoli nella memoria del terminale d’utente.
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
35
I terminali conformi a questo profilo devono necessariamente essere dotati di accesso al canale di
trasmissione broadcast, mentre la presenza del canale di ritorno è soltanto opzionale. È possibile
allestire servizi che combinano le trasmissioni digitali ordinarie con software scaricabili, lasciando ai
broadcaster ed ai costruttori una discreta libertà di progetto.
2.2.2.2 Interactive Broadcast
Questo profilo richiede la presenza del canale di ritorno; permette di aggiungere ai servizi del profilo
Enhanced Broadcasting servizi di tipo interattivo con la possibilità per l’utente di interagire con un
centro servizi attraverso un canale di ritorno (interazione tra un terminale e server remoti). Sarà
quindi possibile offrire servizi di tipo pay come la pubblicità interattiva, le transazioni (home-
banking, commercio elettronico) ecc. In tale profilo la navigazione Internet è implicita, cioè
codificata all’interno delle applicazioni e trasparente per l’utente. I servizi interattivi possono essere
indipendenti o meno dai contenuti trasmessi in broadcast; a questo livello è anche possibile rendere
unidirezionale la trasmissione broadcast, rendendo i contenuti che sono ricevibili da ogni utente,
accessibili solo da coloro che ne hanno l’autorizzazione. Le applicazioni presenti in questo profilo
possono essere scaricabili o residenti.
Le caratteristiche di tale identificativo devono essere compatibili con l’impiego dei protocolli di
comunicazione previsti dalla specifica MHP, e non devono comportare per l’utente la necessità di
ripetere più volte l’inserimento di informazioni personali, testi, sequenze numeriche. La realizzazione
di alcuni di questi servizi potrebbe altresì richiedere che le applicazioni software possano avere
accesso ad una o più smart-card connesse direttamente al terminale MHP tramite lettore di smart-
card “embedded”, ovvero inserito in un modulo CAM-like connesso allo slot di Interfaccia Comune.
Nello specifico, per permettere all’utente di sfruttare a pieno le potenzialità di tali servizi, il terminale
MHP dovrebbe disporre di un lettore smart-card, nonché di librerie software a corredo, in modo tale
da garantire, aggiuntivamente a quanto prescritto dalla specifica MHP, la conformità allo standard
PC/SC, nonché, per quanto riguarda le smartcard, la conformità alle prescrizioni vigenti. Per questo
profilo la specifica prescrive la presenza di almeno un’interfaccia verso un canale bidirezionale che
supporti il protocollo IP, che è anche l’unico protocollo di basso livello (ISO/OSI – Livello 3)
esplicitamente previsto dallo standard per il canale interattivo. Lo stesso profilo prescrive la
disponibilità per le applicazioni di una specifica interfaccia API che consenta la gestione delle
connessioni ad un ISP (anche diverso da quello di default, che viene indicato dal costruttore, o
dall’utente).
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
36
Figura 14. Protocolli supportati per il canale interattivo
Per fornire il canale interattivo sul STB sono previste due modalità: tramite modulo di rete
(Interactive Interface Module) integrato o tramite modulo di rete esterno. Nella seconda modalità la
connessione tra il modulo di rete e il Set Top Box (STB) è realizzata mediante la rete digitale
domestica (In Home Digital Network). Tale rete consente una grande flessibilità di installazione
facendo uso di interfacce standard di grande diffusione su cavo o su portante radio (per es. Ethernet,
Wi-fi, Bluetooth, ecc.).
2.2.2.3 Internet Access Broadcast
Permette l’accesso Internet. Tale profilo offre la possibilità di accedere a servizi di tipo Internet
come navigazione su siti Web e consente di effettuare transazioni commerciali del tipo e-commerce
sfruttando i protocolli di sicurezza già sviluppati per Internet. L’esistenza di questo profilo rende lo
standard MHP tecnicamente molto più potente delle piattaforme esistenti, contemplando le
caratteristiche di entrambi i profili precedenti, rappresenta il vero e proprio punto di convergenza tra
le tecnologie informatiche e televisive. Sarà interessante seguire gli sviluppi dei sistemi con canale
interattivo basati su strutture diverse dal semplice collegamento modem (GSM, UMTS/GPRS,
ADSL/VDSL). I servizi xDSL sono da tenere in considerazione soprattutto nella prospettiva di
supporto alla modalità “always-on”, ovvero quella modalità per cui l’utente ha accesso permanente
alla rete, senza dover stabilire, per ogni sessione di comunicazione, una specifica connessione.
La caratteristica “always-on” ha tutta una serie di implicazioni positive (disponibilità del canale
all’accensione del STB, accesso istantaneo ai servizi, capacità di ricevere informazioni e
aggiornamenti in ogni momento). Dal punto di vista della sicurezza, la specifica prescrive l’utilizzo
del protocollo TLS (IETF RFC 2246), permettendo un livello minimo di autenticazione RSA della
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
37
firma digitale, “hashing” e la crittografia simmetrica. Sono previsti meccanismi, procedure e
dotazioni minime per la gestione dei certificati x509 che consentono l’implementazione
dell’infrastruttura a chiave pubblica - PKI - prevista dalla tecnologia RSA (con lunghezzadella chiave
pubblica minima di 2048 byte per il canale interattivo, e di 4096 byte per l’autenticazione delle
applicazioni software), necessaria anche per l’autenticazione del server all’atto di aprire una sessione
sicura sul canale interattivo.
Il punto più critico per preservare la sicurezza dell’intera infrastruttura di servizio, la gestione della
revoca tempestiva dei certificati compromessi, appare correttamente affrontato solo per il profilo
IB1, anche se il compromesso individuato nella specifica non soddisfa pienamente le esigenze di
sicurezza. E’ comunque consentito negoziare con i costruttori l’implementazione di procedure più
affidabili in caso di applicazioni particolarmente sensibili alla sicurezza. Non è prescritto l’impiego di
tecniche per crittografare la sessione stessa, per cui i dati possono viaggiare in chiaro, se non
diversamente protetti ad un livello superiore. Non è obbligatoria la presenza di un’interfaccia API
che consenta l’autenticazione del client, né è prevista l’implementazione sulla piattaforma delle
procedure TLS (Transport Layer Security) lato server.
L’integrazione dei sistemi di accesso condizionato con la piattaforma può essere realizzata:
- dal costruttore della stessa, che quindi individua, anche concordemente con operatori di
servizi, il/i sistema/i da integrare;
- dall’operatore del servizio televisivo interessato, se il costruttore ha introdotto nel proprio
apparato il dispositivo standard Interfaccia Comune (EN 50221).
2.2.3 Protocolli DSM-CC Data Carousel e Object Carousel
Si è visto che lo strato MHP permette ad un’applicazione di interagire, per mezzo delle API, con le
componenti di sistema presenti nel Set Top Box. Tra queste interazioni le più importanti riguardano
le componenti del mux MPEG: sotto questa categoria possono esser raggruppate le interazioni che
riguardano la lettura della System Information (dalla quale l’applicazione ottiene informazioni
riguardo la programmazione TV, la lingua, la rete broadcast su cui è sintonizzata, la struttura del TS
MPEG, ecc.), le funzioni di Section Filter (per mezzo delle quali l’applicazione può leggere dati
dalle sezioni private del mux MPEG che contengono informazioni nascoste trasmesse dal
broadcaster) e l’accesso al carousel DSM-CC.
DSM-CC (Digital Storage Media - Command and Control) è un protocollo standard per la
trasmissione delle applicazioni ai Set Top Box basato sullo stream MPEG. Il problema della
trasmissione di applicazioni nei sistemi broadcast è la loro natura unidirezionale. La soluzione
proposta è l’utilizzo del carousel. Un broadcaster trasmette i dati, suddivisi in blocchi chiamati
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
38
moduli, implementando un meccanismo ciclico. Il carousel DSM-CC è visto dall’applicazione come
un file system, con la peculiarità di avere una latenza di accesso molto maggiore di quello che si
sperimenta normalmente in un accesso ad un file locale e di essere accessibile solo in lettura.
Il broadcaster trasmette periodicamente ogni file del filesystem, ed il ricevitore rimane in attesa; le
elaborazioni eseguite sul ricevitore forniscono informazioni sui file di interesse. Un esempio di
questo tipo di soluzione è il sistema teletext: ciascuna pagina ha un numero preciso, e viene
trasmessa a turno. Quando un utente digita il numero di una pagina, la televisione aspetta che la
pagina venga trasmessa, dopodichè viene decodificata e visualizzata. Questo è proprio il tipo di
soluzione che viene detto “carousel”.
Figura 15. Multiplazione di un carousel in uno stream TV
DSM-CC supporta due tipi di carousel. Nella TV interattiva, la semplice trasmissione dei dati da un
broadcaster ad un ricevitore viene effettuata utilizzando i data carousel. Un data carousel consiste
in una serie di moduli, dove ogni modulo contiene un dato come un file e può essere diviso in
blocchi per rendere la trasmissione più facile. Gli elementi di un carousel DSM-CC sono contenuti
in un insieme di messaggi. Questi si dividono in due categorie:
- DSM-CC Download Data Message, che contengono i dati appartenenti ai moduli del carousel;
- DSM-CC Download Control Message, che dicono al ricevitore come sono organizzati i
Download Data Message nei moduli definendone la struttura.
La grossa limitazione del data carousel è che non ci sono informazioni sulla natura dei dati quando il
broadcaster trasmette i blocchi attraverso la connessione MPEG-2. Per le applicazioni MHP non è
l’ideale non conoscere la struttura dei file e delle directory in quanto non è possibile distinguere il
codice delle applicazioni dalle risorse. In questi casi l’object carousel (DSM-OC) fornisce una
migliore soluzione. Esso è l’estensione del data carousel ai concetti di file, directory e stream, ovvero
un carousel può contenere un filesystem oltre che un insieme di directory e di file. Ogni oggetto
all’interno dell’object carousel viene trasmesso come un messaggio BIOP (Broadcast Inter-ORB
Protocol) contenuto dentro un modulo data carousel DSM-CC. In un object carousel possono
essere trasportati i seguenti tipi di messaggi:
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
39
- File message (contiene i dati che formano i file);
- Directory message (rappresenta il contenitore logico di un insieme di file message);
- Stream message (è un riferimento allo stream MPEG-2, che contiene i dati audio e video);
- Stream Event (ha funzione di sincronizzazione);
- Service Gateway message (identifica la directory root dell’object carousel).
Ogni object carousel consiste in un “directory tree” diviso in una serie di moduli che a loro volta
contengono files o directory; ogni modulo può avere una grandezza massima di 64 KB e i files non
possono essere divisi su più moduli. Quando tutti i moduli sono stati trasmessi, il ciclo ricomincia.
Per accedere ad un file, il ricevitore deve aspettare finché non riceve il modulo che lo contiene.
Figura 16. Protocolli supportati dal canale broadcast
2.3 Il decoder interattivo (Set-Top Box)
Il decoder interattivo (Set-Top-Box) è l’apparecchio indispensabile per ricevere i canali digitali e
utilizzare i software interattivi. Questo dispositivo permette innanzitutto la decodifica del segnale da
digitale ad analogico per gli apparecchi televisivi analogici che attualmente nel nostro paese
rappresentano la totalità del mercato. Infine consente di eseguire applicazioni Java grazie alla
presenza di una Personal JVM embedded.
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
40
2.3.1 Architettura
In Figura 17 è rappresentata l’immagine dell’architettura del Set-Top-Box o IRD
ricevitore/decodificatore integrato digitale) per evidenziarne le interfacce e i principali blocchi
funzionali.
Figura 17. Architettura del Set-Top Box
L’architettura generale si compone di:
- Un livello hardware e firmware comprendente le interfacce verso l’esterno e il
bootloader, che consente l’aggiornamento del software residente;
- Un livello software residente che include il software di sistema, il navigatore e, ove
necessario, il middleware (JAVA, browsers XML, HTML, ecc.);
- Un livello API per l’ulteriore gamma di applicazioni (EPG, Teletext evoluto).
- Le interfacce verso l’esterno possono comprendere l’ingresso/ uscita RF/IF, le uscite
audio e video, gli ingressi/uscite audio/video e dati, telecomando, l’interfaccia comune, le
interfacce smart-card e il canale di ritorno. Citazione Java TV API Technical overview
Occorre precisare che la dotazione dell’interfaccia comune è obbligatoria per i soli ricevitori con
accesso condizionato integrati negli apparecchi televisivi ed è raccomandata per i set-top-box che
prevedono le funzioni di accesso condizionato. La presenza del canale di ritorno e del relativo strato
software di gestione è raccomandata per i ricevitori di funzionalità estesa.
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
41
Relativamente al software, si fa notare che in tutti i ricevitori terrestri, satellitari e via cavo, è
essenziale la presenza di un navigatore in grado di presentare all’utente il contenuto delle
informazioni sulla programmazione diffuse dagli operatori televisivi, secondo la normativa DVB-
SI.
Le interfacce software (APIs) che permettono di scaricare sull’ IRD applicazioni multimediali sono
raccomandate nei soli ricevitori evoluti.
Di fondamentale importanza, inoltre, è la possibilità di modificare in tutto o in
parte il software residente del IRD.
2.3.2 Funzionalità hardware e firmware
Esaminando nel dettaglio l’architettura di rete proposta, è possibile individuare i blocchi principali
che costituiscono la struttura hardware e firmware dell’IRD. I moduli a fondo chiaro costituiscono la
struttura base dell’IRD terrestre e devono tutti essere considerati come essenziali. I moduli a fondo
scuro rappresentano l’estensione della struttura tramite la quale il STB acquisisce funzionalità estese
(es: multimedialità, interattività, registrazione locale).
Nel caso di servizi provenienti da diversi mezzi di trasmissione (satellite, cavo, terrestre) si
raccomanda che l’utente sia messo in condizione di navigare, in modo semplice, tra i servizi originati
da diversi front-end. La presenza contemporanea nell’IRD terrestre dell’interfaccia comune e del CA
Embedded con relativo lettore di smart-card risponde all’esigenza di massima flessibilità sotto il
profilo del controllo d’accesso. In tal modo un unico IRD è in grado di gestire e offrire all’utente
servizi criptati di differenti operatori sia in multicrypt (EN 50221) sia in simul-crypt (TS 101-197).
2.3.3 Front-end
Il front-end deve essere in grado di ricercare automaticamente ogni segnale presente all’interno
dell’intervallo di frequenze disponibile e riconoscere automaticamente la modalità trasmissiva
(modulazione, il symbol rate e la correzione di errore). Deve inoltre essere in grado di ricevere le
informazioni sulla sintonia tramite le tabelle PSI/SI. Opzionalmente l’IRD si sintonizza sul canale
RF richiesto dall’utente. Una volta acquisiti, i dati relativi alla sintonia devono essere memorizzati in
modo da poter essere rapidamente disponibili.
Queste caratteristiche devono essere condivise da tutti i front-end (terrestre, cavo e satellite) installati
nell’STB. Il front-end del set-top-box terrestre dovrà includere un by-pass RF analogico,
funzionante anche in stand-by. È raccomanda una realizzazione che includa anche il modulatore RF
PAL, per il reinserimento del programma digitale decodificato.
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
42
2.3.4 Demultiplexer MPEG-2
Ricompone i flussi relativi ai programmi a partire dai pacchetti TS ed effettua la sincronizzazione dei
flussi audio e video secondo la codifica di trasporto MPEG-2 definita in ISO/IEC 13818-1.
È necessario inoltre:
- Utilizzare le tabelle MPEG-2 SI-DVB;
- Interpretare il descrittore CA come definito in ETR 289;
- “Demultiplare” un flusso ISO/IEC 13818-1 con data rate fino a 60 Mbit/s;
- Selezionare, opzionalmente, uno o più flussi dati, definiti in EN 300 192, e inviarli a
un’uscita compatibile; Ignorare strutture dati che, allo stato attuale, sono classificate reserved, in modo da garantire la
compatibilità con versioni future.
2.3.5 Video Decoder MPEG-2 e Decoder Audio
Il decoder video deve rispettare gli standard e le linee guida fornite dai seguenti documenti:
- ISO/IEC 13818-1, ISO/IEC 13818-2
- ETS 300 468, ETR 211
- ETR 154.
- ITU-R BT. 1119-1, ETS 300 294
Le caratteristiche minime del video decoder MPEG-2 sono le seguenti:
- Risoluzioni (riferite ai pixel di luminanza) di: 720x576, 544x576, 480x576, 352x576 o
352x288 rappresentabili, sulle uscite video analogiche, anche a pieno schermo (fullscreen);
- Formati 4:3 e 16:9 (aspect ratio information) ;
- Supporto del formato MPEG-1;
- Supporto di bit rate video fino a 15 Mbit/s.
Il decoder audio MPEG dovrà rispettare le linee guida fornite dal DVB ETR 154 che si riferisce
agli standard ISO/IEC 13818-3 e 11172-3.
In particolare:
- Supporto del MPEG layer I e II, III opzionale, ma si raccomanda l’estrazione di almeno una
coppia di canali stereo MPEG-2;
- Supporto delle velocità di campionamento 32, 44.1, 48 kHz e per MPEG-2 22.05 e 24 kHz.
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
43
Per quanto riguarda il sincronismo audio video almeno un decoder audio dovrà rispettare i requisiti
di decoding della ETR 154. Il ritardo relativo introdotto dal decoder fra segnali audio e video non
dovrà superare i 5 ms. Livelli di set-up in linea con DVB ETR 154.
2.3.6 Control Unit
La configurazione minima dell’unità di controllo per l’ IRD a funzionalità estesa dovrà essere di:
- 4 Mbyte RAM;
- 4 Mbyte flash memory;
- 4 Mbyte video RAM;
Ogni STB dovrà avere le seguenti funzioni:
- Orologio e, in via opzionale, calendario in tempo reale, aggiornati via SI;
- Timer opzionale per il controllo dell’ accensione e lo spegnimento automatico.
2.3.7 Bootloader
Questo modulo è realizzato in software residente e ha la funzione di gestire lo scaricamento di tutto
o di parte del software (drivers, SO, e applicazioni) nell’IRD. Il caricamento del software può
avvenire:
- Attraverso il canale broadcast;
- Attraverso un modulo appropriato connesso all’interfaccia comune;
- Utilizzando il canale interattivo;
- Attraverso le interfacce dati.
Si raccomanda che il bootloader sia in grado di prevenire il caricamento di software non certificato e
che il protocollo di sicurezza sia basato su un meccanismo di crittografia asimmetrica (chiave
pubblica/chiave privata, con le chiavi pubbliche presenti nell’IRD).
2.3.8 Funzionalità grafiche
L’IRD deve essere in grado di gestire funzionalità grafiche per il controllo dello stesso tramite on-
screen-display (OSD) e per il navigatore di base basato sulle informazioni DVB SI. La funzionalità
estesa deve essere in grado di gestire opzioni grafiche avanzate e la visualizzazione del segnale OSD.
Deve inoltre soddisfare i seguenti requisiti minimi:
- Risoluzione 720x576 con aspect ratio 16:9 e 4:3;
- Numero di colori 256 più trasparenza con modo di presentazione specificato dalle API ;
- Supporto simultaneo di grafica, video e still pictures;
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
44
- Supporto della sottotitolazione DVB (ETS 300 743).
2.3.9 Interfacce livelli segnale I requisiti delle varie interfacce esterne di cui l’IRD deve/può essere dotato sono elencati qui sotto:
Tabella 5. Interfacce e livelli di segnale
2.3.10 Software e servizi
Nel software del STB si possono distinguere: il software residente di sistema e le applicazioni. Il
software di sistema deve fornire due classi di funzioni: una classe è accessibile solo all’interno del
medesimo software di sistema, come il navigatore di base,mentre l’altra è disponibile internamente
ed esternamente per le varie applicazioni, quali l’EPG, e costituisce l’API dell’ IRD.
2.3.11 Navigatore
Il software di sistema sia per il profilo base sia per quello a funzionalità estesa deve contemplare un
navigatore definito dal costruttore, che permetta all’utente di configurare e di controllare la sintonia
dell’ IRD. Sarà pertanto compito del costruttore stabilire l’aspetto grafico della presentazione dei
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
45
dati. Il navigatore deve fornire la lista di tutti i servizi presenti su tutti i canali accessibili, anche
quando i segnali non trasportino le informazioni SI incrociate. L’utente deve in ogni caso poter
configurare manualmente l’ordine dei canali preselezionati in automatico e richiamare, tramite
telecomando, la funzione di navigazione e aggiornamento dei dati.
2.3.12 Requisiti minimi
Le sperimentazioni preliminari in fase di progetto e definizione dello Standard hanno permesso di
individuare quali sono le caratteristiche hardware e software che devono essere contenute nei
terminali per rispettare i requisiti implementativi minimi dello stesso nel modo migliore. Nella
Tabella 6 sono riportate le caratteristiche dei STB che hanno dato risultati positivi in fase di
sperimentazione.
Tabella 6. Specifiche minime del STB
2.3.13 Telecomando
Affinché le applicazioni MHP producano risultati uguali su Set- Top-Box diversi è necessario che
anche il comportamento degli utenti sia sempre il medesimo; per ottenere ciò è necessario che il
Capitolo 2: Standard di riferimento e tecnologie abilitanti per la DTT ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
46
telecomando, ossia lo strumento che guida l’utente nell’utilizzo dell’applicazione, sia semplice
nell’utilizzo ed anch’esso conforme ad uno standard (Tabella 7).
Tabella 7. Specifiche minime del telecomando del STB
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
47
Capitolo 3
APPLICAZIONI DVB-J: Xlet Un’applicazione mhp viene sviluppata seguendo un modello di business che si basa su più fattori:
- MSO (Multiple Service Operator) i broadcaster, cioè coloro che forniscono la possibilità di
scaricare le applicazioni e i contenuti per la iTV
- MSV (Middleware Software Vendor) gli sviluppatori java/DVB-HTML
- I fornitori dei contenuti ISP (Internet Service Provider)
- Set-top-box Manufacturers
- Users: gli utenti dotati di set-top-box, televisore e telecomando
Date l’innumerevoli combinazioni che possono venire dall’incrocio dei diversi fattori elencati, non
poche possono sembrare le difficoltà nel produrre un’applicazione MHP. Il trucco si trova nelle
interfacce che lo standard MHP mette a disposizione sia a livello software (Figura 18) che hardware
(Figura 19).
MHP è basato su java, (platform indipendent), il set-top-box ha preinstallato una VM java corredata
da API proprietarie e TV API di SUN, che definiscono le modalità di comunicazione tra l'utente, il
set-top-box e il broadcaster. MHP ha definito anche un sotto linguaggio HTML (DVB-HTML per la
precisione) con tag supplementari relativi alla cattura dell'input dell'utente (telecomando). Il set-top-
box ha preinstallato un'applicazione che si chiama Application Manager (di solito java) che gestisce il
caricamento del software creando anche i menu dei canali forniti dal broadcaster. Oltre a ciò il set-
top-box possiede anche un alloggiamento per smartcard (nonché un lettore per le stesse), che offre
servizi sicuri come login utente, servizi a pagamento e altro.
Per ogni tipo di interfaccia si avrà una suite di classi che permetterà di far dialogare l’applicazione
con i dispositivi a disposizione: schermo, telecomando, smart card, canale di ritorno.
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
48
Figura 18. Software layer
Figura 19. Interfaccia MHP application con MHP system
3.1 Introduzione e principio di funzionamento di una xlet
Una Xlet è una particolare applicazione Java concepita per essere scaricata ed eseguita su decoder
interattivi nei quali un software specifico, l'Application Manager, è in grado di controllarne il ciclo di
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
49
vita. MHP definisce una tabella delle informazioni di servizio (SI) denominata AIT (Application
Information Table), che contiene un elemento per ogni applicazione valida per il servizio. L’AIT è
costituita da tutte le informazioni di cui il ricevitore ha bisogno per eseguire una Xlet e per
comunicare all’utente quali applicazioni sono effettivamente disponibili: il nome, la collocazione dei
file relativi e ogni altro parametro fornito con l’applicazione al momento dell’esecuzione. Ogni Xlet
trasmessa è identificata univocamente nell’AIT , in modo che il sistema possa fare riferimento a
ciascuna di queste senza incomprensioni, che potrebbero nascere altrimenti per la possibilità che il
nome o altri attributi di una applicazione possono essere non unici. Dalla Tabella 8 si può notare che
ogni identificatore è costituito da due parti:
- ID Organizzazione (32 bits), unico per ogni organizzazione che produce applicazioni MHP;
- ID Applicazione (16 bits), che può essere il medesimo per due applicazioni diverse, purchè
queste non abbiano identico ID Organizzazione.
Nell’AIT vi è inoltre un indicatore di stato dell’applicazione, in base al quale questa può essere
avviata o interrotta automaticamente dal ricevitore.
Tabella 8. Application Information Table AIT
Come vedremo le similitudini con le Applet, dove l'application manager è rappresentato dal browser
sono molteplici. Per iniziare a costruire una Xlet occorre innanzitutto capire cosa viene fornito da
Sun nelle API Java TV. Infatti è proprio in queste librerie che vengono definite le due interfacce
fondamentali da utilizzare:
- javax.tv.xlet.Xlet che definisce i seguenti metodi:
public void initXlet(XletContext ctx);
public void startXlet();
public void pauseXlet();
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
50
public void destroyXlet(boolean unconditional);
- javax.tv.xlet.XletContext che definisce i seguenti metodi:
public void notifyDestroyed();
public void notifyPaused();
public java.lang.Object getXletProperty(java.lang.String key);
public void resumeRequest();
Entrambe le interfacce servono per interagire con l'application manager in merito al ciclo di vita e al
contesto in cui la Xlet viene eseguita.
La classe principale di ogni Xlet deve sempre implementare javax.tv.xlet.Xlet per poter essere
eseguita sui decoder interattivi MHP.
Come si mostra in Figura 20 il ciclo di vita di una Xlet è caratterizzato da 4 stati:
Loaded: in questo stato la Xlet è stata creata ma non inizializzata, se durante questa fase viene
rilevata un eccezione allora si passa direttamente nello stato Destroyed. Da notare che la Xlet si può
trovare in questo stato solo una volta durante tutto il suo ciclo di vita.
Paused: la Xlet è inizializzata e può trovarsi in questo stato sia dopo che il metodo
initXlet(XletContext) è ritornato con successo dallo stato Loaded oppure dopo che il metodo
pauseXlet() è ritornato con successo dallo stato Active. In entrambi i casi in questo stato la Xlet
dovrebbe limitare al massimo l'utilizzo delle risorse condivise e soprattutto non impegnare la GUI
televisiva.
Active: in questo stato la Xlet è attiva e utilizza le risorse necessarie per fornire i suoi servizi, se
dotata di GUI allora dovrebbe essere l'unica registrata per ricevere gli eventi del telecomando.
Destroyed: in questo stato la Xlet deve rilasciare tutte le risorse in uso per predisporsi
alla terminazione.
Figura 20. Ciclo di vita di una Xlet
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
51
Una sequenza tipica di questo ciclo potrebbe essere:
L' application manager crea una nuova istanza di una Xlet chiamando il suo costruttore (stato
LOADED). La Xlet usa il context passatogli dall'application manager nel metodo
initXlet(XletContext) e si inizializza (stato PAUSED). L'application manager chiama il metodo
startXlet() e la Xlet inizia ad utilizzare le risorse necessarie per fornire i servizi per cui è stata
costruita(stato ACTIVE). L'application manager chiama il metodo destroyXlet(true) e la Xlet rilascia
le risorse, dopodiché viene terminata (stato DESTROYED).
3.1.1 Esempio: HelloWorld
Il primo esempio: HelloXlet.java
import javax.tv.xlet.Xlet; import javax.tv.xlet.XletContext; import javax.tv.xlet.XletStateChangeException; public class HelloXlet implements Xlet{ // L'XletContext è un oggetto usato dalla Xlet per accedere // alle properties del suo environment e per comunicare con // l'application manager che glielo ha passato nella fase // di inizializzazione. private XletContext context; private boolean alreadyActive = false; // Il costruttore tipicamente viene lasciato vuoto visto che tutte // le inizializzazioni dovrebbero stare nel metodo initXlet() public HelloXlet(){} // In questo metodo vengono fatte tutte le inizializzazioni, // se in questa fase qualcosa fallisse verrebbe lanciata un // eccezione. public void initXlet(XletContext context) throws XletStateChangeException{ // si memorizza il context passato dall'Application Manager this.context = context; System.out.println(this.getClass().getName()+" : Inizializzazione avvenuta!"); } // Con questo metodo la Xlet è avviata e vengono richieste // le risorse necessarie come ad esempio lo schermo TV o // gli eventi del telecomando public void startXlet() throws XletStateChangeException{ // controlliamo se la Xlet era già stata messa in stato Active // precedentemente if (alreadyActive){ System.out.println(this.getClass().getName()+" : Hello Again TV World! "); }else { System.out.println(this.getClass().getName()+" : Hello TV World"); alreadyActive = true; } } // Con questo metodo la Xlet viene messa in pausa e dovrebbe // rilasciare tutte le risorse utilizzate public void pauseXlet(){ System.out.println(this.getClass().getName()+" : Xlet in
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
52
pausa!"); // notifichiamo al Context l'avvenuta pausa della Xlet context.notifyPaused(); } // Con questo metodo la Xlet viene terminata, tramite il // parametro boolean la Xlet ha la facoltà di accettare // tale richiesta; nel caso non accettasse di // terminare dovrebbe lanciare un eccezione. public void destroyXlet(boolean unconditional) throws XletStateChangeException { if (unconditional) { System.out.println(this.getClass().getName()+" : la Xlet è stata terminata!"); }else { System.out.println(this.getClass().getName()+ " : la Xlet ha accettato di essere terminata!"); } // notifichiamo al Context l'avvenuta terminazione della Xlet context.notifyDestroyed(); } }
3.2 Gestione delle risorse scarse
Rispetto agli attuali PC, i Set-Top-Box sono sistemi costituiti da risorse hardware limitate, in
particolare memoria scarsa e processori lenti, per questo nell’utilizzo delle periferiche quali il
telecomando, per l’input, il decoder MPEG-2, per l’output (visualizzazione di immagini video), e
modem, affinché l’applicazione possa funzionare correttamente e sfruttare tutte le potenzialità del
Set-Top-Box, si deve tener conto che queste periferiche costituiscono appunto le cosiddette “risorse
scarse”. A tal proposito esistono delle API, le “resource notification API”, definite da DAVIC nel
package org.davic.resource, che servono a notificare alla applicazione se una risorsa è stata tolta o è stata
richiesta da una concorrente.
3.3 Interfaccia grafica
Il modello grafico definito dallo standard MHP è costruito su tre piani o layers, come illustrato in
Figura 21: il Background, il Video e il Graphic layer:
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
53
Figura 21. Livelli grafici MHP
Al livello più basso si ha il Background layer, costituito da un colore o un’immagine statica,
rappresentata da un particolare frame MPEG-2; al livello intermedio si trova il Video layer,
rappresentato dal flusso audio/video del canale TV o da una qualunque altra fonte in formato
MPEG-2; al livello più alto infine è situato il Graphic layer, che contiene la grafica realizzata
nell’applicazione, che a sua volta può essere strutturata su più livelli sovrapposti. Questi tre strati,
che verranno analizzati nei seguenti tre paragrafi, possono essere configurati separatamente, ma c’è
un’interazione tra essi per cui è possibile che si creino dei vincoli da rispettare.
Il modello grafico illustrato è supportato da vari package messi a disposizione dallo standard, tra cui
HAVI (Home Audio Video Interoperability), in cui è definita la classe org.havi.ui.Hscreen, che
rappresenta il dispositivo fisico di visualizzazione. Il ricevitore MHP avrà al massimo un solo
oggetto HScreen attivo; ognuno di questi poi ha un numero di oggetti HScreenDevice ad esso
associati, che rappresentano i layers di visualizzazione dello schermo. In particolare:
- HBackgroundDevice rappresenta il Background layer;
- HVideoDevice rappresenta il Video layer;
- HGraphicsDevice rappresenta il Graphic layer.
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
54
Figura 22. La struttura HScreen
La risoluzione supportata è 720 x 576 pixel con 256 colori, ma questi sono valori minimi:
alcuni ricevitori MHP potrebbero avere risoluzioni più elevate.
Rispetto alle applicazioni grafiche su PC bisogna tenere conto di alcune differenze, riportate di
seguito:
- i pixel non sono perfettamente quadrati;
- il file costitutivo del background deve essere un’immagine video in formato MPEG-2
(.mpg) in loop e non una statica (.jpg), poiché il Set-Top-Box utilizza per la sua
visualizzazione lo stesso decoder impiegato per il Video layer;
- le linee spesse un pixel non sono perfettamente o affatto visualizzabili;
- le coordinate assolute (x, y) vanno considerate a partire da (0, 0) angolo superiore sinistro;
- si possono utilizzare coordinate indipendenti dalla risoluzione, dette “normalizzate”, che si
esprimono con numeri decimali compresi tra 0.0 e 1.0, supportate dalle API HAVI;
- la visualizzazione grafica completa è assicurata in un’area ridotta rispetto alle coordinate
totali, di ampiezza 562 x 460, denominata “Graphic Safe Area” o “Title Safe Area”,
rappresentata in figura 23, che corrisponde dunque alla parte centrale dello schermo e che
perciò risulta sicuramente visibile e non comporta alcuna distorsione, qualunque sia il
televisore considerato (4:3, 16:9).
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
55
Figura 23. Safe Area
3.3.1 Background layer
Per settare uno sfondo sulla nostra applicazione bisognerà innanzitutto tener conto che la periferica
che andremo ad utilizzare, il decoder mpeg2 è una risorsa scarsa, quindi per effettuare qualsiasi tipo
di settaggio bisognerà prima acquisirla usando le resource notification API introdotte nei paragrafi
precedenti. Il package più importante da importare per la gestione di questo layer è org.havi.ui.* ,
riportiamo la classe più rilevante “HScreen”:
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
56
Tabella 9. Metodi della classe HScreen
Vediamo in breve le operazioni da eseguire: per prima cosa si sceglie lo schermo da usare mediante
l’oggetto HScreen, a questo oggetto bisogna associare una HGraphicsDevice che conterrà il set
d’impostazioni assegnate per mezzo di HGraphicsConfigTemplate. Il set di ogni singola
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
57
impostazione è eseguito dal metodo setPreference al quale viene passato il parametro e la priorità;
sarà poi il midlleware a decidere se il settaggio richiesto è attuabile in base alla priorità data e alle
esigenze delle altre eventuali applicazioni che sono in running. Conviene creare una classe che
implementa obbligatoriamente org.davic.resources.ResourceClient dove inserire tutti i metodi per
l’acquisizione, il settaggio e il rilascio della risorsa. Di seguito viene riportata la classe
“BackgroundController”, creata da Steve Morris, che mostra in dettaglio oltre alle fasi sopra elencate
la gestione delle eccezioni .
/********************************************************************************** * THIS SOFTWARE IS COPYRIGHT STEVEN MORRIS 2002. ALL RIGHTS RESERVED * THIS SOFTWARE IS FREE FOR NON COMMERCIAL USE FOR THE PURPOSE OF LEARNING *MHP. ANY USE FOR OTHER PURPOSES IS PROHIBITED UNLESS WRITTEN AGREEMENT * IS OBTAINED. * DISTRIBUTION OF THIS CODE IS PROHIBITED */ // Import the HAVi UI classes that we need for this import org.havi.ui.HScreen; import org.havi.ui.HBackgroundDevice; import org.havi.ui.HBackgroundConfiguration; import org.havi.ui.HBackgroundImage; import org.havi.ui.HStillImageBackgroundConfiguration; import org.havi.ui.HConfigurationException; import org.havi.ui.HPermissionDeniedException; import org.havi.ui.HBackgroundConfigTemplate; // Since some of the graphics configuration requires scarce resources, we // need to use the DAVIC resource notification API import org.davic.resources.*; // We need these (under some circumstances) to let our background be seen import javax.tv.service.selection.*; import javax.tv.media.AWTVideoSizeControl; import javax.tv.media.AWTVideoSize; import java.awt.Rectangle; import javax.tv.xlet.XletContext; /** * This class handles the display of background images in an easy-to * use way. Setting this up can be quite complex, and so in the case * we've relegated it to a separate class to make it a little easier to * understand. */ class BackgroundController implements org.davic.resources.ResourceClient{ // The background device that we will use for displaying the image private HBackgroundDevice backdevice; // The configuration for that background device private HStillImageBackgroundConfiguration backconfig; /** * This method will initialise the video and graphics devices to allow * them to display the background image. */ public boolean init(){ // We first need to get the background device that we will use for displaying the image. To do //this, we need to first decide which // HScreen we will use. In this case (and most others), we will use // the default one. HScreen screen = HScreen.getDefaultHScreen(); // Once we have that, we get the default background device for that HScreen HBackgroundDevice backdevice = screen.getDefaultHBackgroundDevice();
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
58
// Once we have a reference to the device, we can get a configuration for it. // Get a configuration that we can use HBackgroundConfigTemplate backgroundConfigurationTemplate = new HBackgroundConfigTemplate(); backgroundConfigurationTemplate.setPreference(HBackgroundConfigTemplate.FLICKER_FILTERING ,HBackgroundConfigTemplate.REQUIRED); HBackgroundConfiguration backconfig; backconfig = backdevice.getBestConfiguration(backgroundConfigurationTemplate); // Can we reserve the device so that we can change the settings on it? if (backdevice.reserveDevice(this)){ // If we can, we set the configuration of the background device to // the one we got above - this is the default configuration for this device. try{ backdevice.setBackgroundConfiguration(backconfig); }catch (Exception ex){ System.out.println("Can't initialise the background device"); // Release the device so that other applications can use it, if necessary. backdevice.releaseDevice(); return false; } // We need to check if we can put an image in the background in // this configuration, since we can't do this in every configuration. if(backconfig instanceof HStillImageBackgroundConfiguration){ // We can use this this.backconfig = (HStillImageBackgroundConfiguration)backconfig; this.backdevice = backdevice; return true; }else{ // If we can't, we again release the device since it's no use to us. backdevice.releaseDevice(); } } return false; } /** * Free the resources we needed to display background images. * Some implementations leave the image there, but there is an explicit * warning in the MHP specification that this may not happen on all * implementations. If you want to be sure that your image is still * visible, don't do this. */ public void dispose(){ // Check if we have something to dispose of if (backdevice != null){ // RZlease the device and clear any references backdevice.releaseDevice(); backdevice = null; backconfig = null; } } /** * Display a background image */ public void display(String filename){ // Check we have the resources we need to display a background image if(backconfig != null) { // Create a new background image. The image is loaded from the // filename that we pass in. HBackgroundImage backimage = new HBackgroundImage(filename); // Now display the image. This can throw several exceptions, so we // enclose it in a 'try' block try {
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
59
backconfig.displayImage(backimage); } catch (java.io.IOException ioe) { // Ignore it, but print a message to tell the user what's happened. System.out.println("Can't display background image - IO exception"); ioe.printStackTrace(); } catch (HPermissionDeniedException hpde) { // We don't have permission to displayan image. We just ignore it. System.out.println("Can't display background image - permission denied"); } catch (HConfigurationException hce) { // We don't have permission to displayan image. We just ignore it. System.out.println("Can't display background image - configuration exception"); hce.printStackTrace(); } } }
3.3.2 Video layer
La gestione del video layer è molto importante non solo per l’aspetto estetico della nostra interfaccia
grafica.
Non dobbiamo dimenticare, che il broadcaster ha si interessi a fornire l’applicazione MHP, ma si
deve preoccupare anche della trasmissione che sta andando in onda. Mentre in una fase iniziale, nelle
prime applicazioni, si preferiva ridimensionare il video e spostarlo in modo da non sovrapporsi a
menù, pulsanti etc. ora la tendenza e di lasciarlo invariato il più possibile, usando trasparenze o
sovrapposizioni di grafica temporanee, in modo da distogliere il meno possibile l’attenzione del
telespettatore dalla trasmissione. Comunque ci sono casi in cui l’applicazione può pretendere e
merita tutta l’attenzione dell’utente, basta pensare all’inserimento dati o alla conferma di un
movimento in una applicazione e-banking per esempio. Quindi è bene alternare fasi, come la
navigazioni di menù, dove il video sia in primo piano e altre in cui venga eliminato o ridotto.
Per realizzare tutto ciò ci vengono in aiuto le classi javaTV della Sun, ecco un esempio di due metodi
per nascondere o ridimensionare e posizionare il video tratti dalla classe “BackgroundController”,
creata da Steve Morris. import javax.tv.service.selection.*; import javax.tv.media.AWTVideoSizeControl; import javax.tv.media.AWTVideoSize; import java.awt.Rectangle; import javax.tv.xlet.XletContext; /** * Hide the video that may be obscuring our background */ public void hideVideo(XletContext context) { // The background may be hidden by the video when the Xlet starts up. To // solve this, we have to do two things: // 1) stop the video
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
60
// 2) resize the video so that we can see the app underneath it. This is // not always necessary, but some emulators (xletview, I'm looking at you) // don't hide the video when you stop it // Get a reference to the JavaTV ServiceContextFactory ServiceContextFactory factory; factory = ServiceContextFactory.getInstance(); // service context of our Xlet. To do this, we need a // reference to our Xlet context. It's times like this // that show why your application should always keep a // reference to its Xlet context ServiceContext myContext = null; try { myContext = factory.getServiceContext(context); } catch (Exception e) { e.printStackTrace(); } if (myContext != null) { // ServiceContentHandler objects are responsible for // presenting the different parts of the service. This // includes the media components ServiceContentHandler[] handlers; handlers = myContext.getServiceContentHandlers(); for(int i=0; i < handlers.length ; i++) { if (handlers[i] instanceof ServiceMediaHandler) { // This is a Player for part of the service, since // ServiceMediaHandler objects are instances of JMF // Player objects javax.media.Player p = (javax.media.Player) handlers[i]; // this may be all we need to do in order to see our background... p.stop(); p.deallocate(); // ...but some emulator require more AWTVideoSizeControl awtVideoSizeControl; awtVideoSizeControl = (AWTVideoSizeControl) p.getControl("javax.tv.media.AWTVideoSizeControl"); // in this case, we set the size of the video to be 0, but we could set it // to display on part of the screen awtVideoSizeControl.setSize(new AWTVideoSize(new Rectangle(0, 0, 720, 576), new Rectangle(0,0,0,0))); } } }else { System.out.println("Can't get our service context. May not be able to " + "resize the video, so our background may not be visible"); } } public void resizeVideo(XletContext context,int x,int y,int l,int h) { // The background may be hidden by the video when the Xlet starts up. To // solve this, we have to do two things: // 1) stop the video // 2) resize the video so that we can see the app underneath it. This is // not always necessary, but some emulators (xletview, I'm looking at you) // don't hide the video when you stop it // Get a reference to the JavaTV ServiceContextFactory ServiceContextFactory factory; factory = ServiceContextFactory.getInstance(); // From this, we can get a reference to the parent // service context of our Xlet. To do this, we need a // reference to our Xlet context. It's times like this // that show why your application should always keep a // reference to its Xlet context
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
61
ServiceContext myContext = null; try { myContext = factory.getServiceContext(context); } catch (Exception e) { e.printStackTrace(); } if (myContext != null) { // ServiceContentHandler objects are responsible for // presenting the different parts of the service. This // includes the media components ServiceContentHandler[] handlers; handlers = myContext.getServiceContentHandlers(); for(int i=0; i < handlers.length ; i++) { if (handlers[i] instanceof ServiceMediaHandler) { // This is a Player for part of the service, since // ServiceMediaHandler objects are instances of JMF // Player objects javax.media.Player p = (javax.media.Player) handlers[i]; // this may be all we need to do in order to see our background... // ...but some emulator require more AWTVideoSizeControl awtVideoSizeControl; awtVideoSizeControl = (AWTVideoSizeControl) p.getControl("javax.tv.media.AWTVideoSizeControl"); // in this case, we set the size of the video to be 0, but we could set it // to display on part of the screen awtVideoSizeControl.setSize(new AWTVideoSize(new Rectangle(0, 0, 720, 576), new Rectangle(x,y,l,h))); } } }else { System.out.println("Can't get our service context. May not be able to " + "resize the video, so our background may not be visible"); } } Prima di ridimensionare o eliminare addirittura il video layer è bene aver impostato una immagine
nel background layer come descritto nel paragrafo precedente, onde intercorrere a videate nere o
addirittura alla non visualizzazione del livello grafico che ora andremo a trattare.
3.3.3 Graphics layer
Il livello grafico è supportato da diversi package messi a disposizione dallo standard; uno dei
fondamentali è Havi 1.1.
In tale package il container di più alto livello in una Xlet è rappresentato dalla classe
org.havi.ui.HScene, che concettualmente è equivalente a java.awt.Window o java.awt.Frame ma con
caratteristiche specifiche per i decoder digitali, ne riportiamo i metodi principali:
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
62
Tabella 10. Metodi della classe HScene
La classe factory che ci permette di richiedere l'unica istanza della HScene è fornita dallo stesso
package e si chiama org.havi.ui.HSceneFactory. MHP supporta anche le classi AWT contenute nella
versione 1.1.8 del JDK Sun ma spesso è possibile trovare un equivalente nel package Havi e che
quindi dovrebbe essere preferita (es: org.havi.ui.HContainer è più specifica per MHP di
java.awt.Container). Oltre ad Havi e AWT è possibile utilizzare anche un package specifico DVB
org.dvb.ui dove è possibile trovare classi di utilità come la DvbColor che permette di gestire anche le
trasparenze tramite il parametro alpha non presente nella classe java.awt.Color. Data l’importanza
vediamone un tipo di costruttore: DVBColor (int r, int g, int b, int a) dove r,g,b sono i colori
primari red, green, blue e “a”- alpha è la trasparenza, tutti e quattro i parametri hanno un range da 0
a 255. Non tutti i tipi di decoder MHP gestiscono le trasparenze in questo modo, ma lo standard
garantisce almeno 3 livelli: 0 % (opaco), 100 % (completamente trasparente), 30 % di trasparenza. Il
font di sistema supportato in MHP è il “Tiresias”, che deve essere disponibile almeno nelle seguenti
dimensioni:
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
63
- 36 punti (Title);
- 31 punti (Subtitle);
- 26 punti (Body);
- 24 punti (Footnote);
I formati grafici supportati sono: png, jpg, gif e mpg (I-Frame). Vediamo un esempio di codice che
recupera l'istanza di HScene e ci posiziona un HContainer e un HText.
HSceneFactory hsf = HSceneFactory.getInstance(); HScene scene = hsf.getFullScreenScene( HScreen.getDefaultHScreen().getDefaultHGraphicsDevice());// risoluzione a schermo pieno scene.setSize(720,576); scene.setLayout(null); HContainer cont = new HContainer(50,50,650,500); HText text = new HText("Casella di testo!",160, 200, 300, 60, new Font("Tiresias", Font.PLAIN, 26),Color.black,Color.white, new HDefaultTextLayoutManager()); cont.add(text); scene.add(cont); scene.setVisible(true); scene.repaint(); Un altro oggetto molto utile nella creazione di un’interfaccia è HIcon che permette di caricare un
immagine e visualizzarla, per esempio per creare un bottone, in dettaglio:
HIcon (java.awt.Image image, int x, int y, int width, int height) utilizzando java.awt.Toolkit ecco il
nostro bottone: bottone = new HIcon(Toolkit.getDefaultToolkit().getImage("bottone.jpg"), 50, 100, 140, 30); Per dare facilmente l’effetto che il pulsante venga premuto si possono creare due oggetti HIcon con
le rispettive immagini, pulsante rilasciato/pulsante premuto, posizionati sulle stesse coordinate e
agire con il metodo setVisible(true/false) per nascondere l’uno e visualizzare l’altro.
3.4 Gestione degli eventi del telecomando
La gestione del telecomando è banale per chi conosce Java, si basa sugli ascoltatore di eventi; in
MHP si possono usare i package org.havi.ui.event che necessita del focus di un’ oggetto grafico
oppure org.dvb.event. Iniziamo dal primo caso, nel package sono definite le costanti che
corrispondono al codice restituito dal metodo getKeyCode di java.awt.event.KeyEvent ad ogni
pressione di un tasto. L’ascoltatore degli eventi va aggiunto nel metodo initXlet:
scene.addKeyListener((KeyListener)this) e rimosso nel metodo destroyXlet:
scene.removeKeyListener((KeyListener)this). Come mostrato in Tabella 11 gli eventi associati alla
pressione dei un tasto del telecomando definiti nell'MHP sono solamente quelli numerici, le
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
64
frecce di navigazione, il tasto “OK”, il tasto teletext e i quattro tasti colorati (rosso, verde, giallo,
blu).
Tabella 11. Input eventi MHP
Da notare che lo standard MHP non definisce eventi per i tasti “EXIT” e “BACK” che sono
presenti sulla quasi totalità dei decoder e comunque gestiti da org.havi.ui.event.HRcEvent ma
potrebbero generare eventi non-standard e non sempre coerenti sui diversi apparecchi. Vediamo
ora un esempio di codice necessario per l’implementazione del primo metodo, il codice seguente
deve risiedere nella classe principale della Xlet.
public void keyPressed (KeyEvent key) { int pulsantePremuto = key.getKeyCode(); switch(pulsantePremuto){ //Tastierino numerico case KeyEvent.VK_0: case KeyEvent.VK_1: case KeyEvent.VK_2: case KeyEvent.VK_3: case KeyEvent.VK_4: case KeyEvent.VK_5: case KeyEvent.VK_6: case KeyEvent.VK_7: case KeyEvent.VK_8: case KeyEvent.VK_9: //Tasti colorati case HRcEvent.VK_COLORED_KEY_0: //rosso case HRcEvent.VK_COLORED_KEY_1: //verde case HRcEvent.VK_COLORED_KEY_2: //giallo case HRcEvent.VK_COLORED_KEY_3: //blu //Tasti direzionali case HRcEvent.VK_UP: case HRcEvent.VK_DOWN: case HRcEvent.VK_RIGHT: case HRcEvent.VK_LEFT:
Capitolo 3: Applicazioni DVB-J: Xlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
65
case HRcEvent.VK_ENTER: //OK //Vengono passati gli eventi. interfaccia.keyPressed(key); break; //Alla pressione del tasto EXIT del telecomando si //richiama il metodo destroyXlet, per fermare la xlet. case HRcEvent.VK_ESCAPE: try{ destroyXlet(true); } catch (XletStateChangeException xsce){ System.out.println("Premuto tasto EXIT "+xsce.toString()); } break; default: break; } } public void keyTyped(KeyEvent ignored) { } public void keyReleased(KeyEvent ignored) { } Essendo il primo metodo ampiamente documentato e conosciuto vediamo nel dettaglio quello
specifico del DVB. Tale meccanismo è consigliabile rispetto ad AWT perché permette un uso più
oculato e collaborativo nella gestione degli eventi. Infatti rispetto ad AWT dove la registrazione degli
eventi è esclusiva e comprende tutti gli eventi possibili, nel modello dvb è possibile registrarsi per la
notifica dei soli eventi a cui si è realmente interessati. Le classi principali di questo package sono la
EventManger e la UserEventRepository che gestiscono rispettivamente la registrazione degli eventi e
il repository degli eventi a cui si è interessati.
UserEventRepository repository = new userEventRepository("UserRepository"); repository.addAllColourKeys(); EventManager manager = EventManager.getInstance(); // this rappresenta la classe listener manager.addUserEventListener(this, repository); Questo approccio ha l'ulteriore vantaggio di non imporre alla Xlet di richiedere il focus tramite la
HScene (come prevede il modello awt sui Component) risulta quindi essere l'unico approccio da
seguire in tutte quelle applicazioni in cui si vogliono ricevere eventi del telecomando ma non si
dispone una GUI.
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
66
Capitolo 4
AMBIENTE DI SVILUPPO
4.1 Introduzione
Dopo aver visto nei capitoli precedenti le tecnologie usate nel digitale terrestre, le caratteristiche
principali di un’applicazione MHP, con particolare riguardo all’uso del canale di ritorno, andremo a
proporre come è possibile realizzare l’ambiente di sviluppo per l’implementazione, debug e test di
una Xlet. Per l’implementazione, come prima cosa, si avrà bisogno di un PC con installata una Java
Virtual Machine e magari un programma di sviluppo Java, come Eclipse, per
evitare errori di sintassi. Per la fase di debug e una prima fase di test è molto utile utilizzare un
simulatore per applicazioni MHP, per vedere errori in fase di compilazione.
Per la fase di test vera e propria ci sono due modi di procedere:
- il primo consiste nel simulare un broadcaster; necessità di un modulatore COFDM al quale
in ingresso verrà mandata l’applicazione insieme ad un eventuale flusso video, mentre in
uscita vi sarà collegato uno (o più) Set Top Box commerciali;
- il secondo, che è quello che poi andremo ad analizzare in dettaglio, consiste nell’utilizzo di
un Set Top Box da sviluppo, fornito dall’ASUR zona 7, che a differenza di quelli
commerciali, permette l’ upload di applicazioni non solo dall’etere, ma anche in locale,
tramite porta seriale (RS-232).
4.2 Il Simulatore XletView
Tra i vari software freeware di simulazione per applicazioni MHP, che si trovano in rete, spicca
XletView, distribuito da GNU General Public License (GPL) , scaricabile all’indirizzo
www.sourceforge.net .
Per l’installazione si richiede che sul PC sia presente una Java Virtual Machine a partire da JRE 1.4,
JSDK1.4 o versione superiore, della Sun; mentre all’interno del pacchetto troviamo già le API JMF
2.1.1 (Java Media Framework) che servono per incorporare media-data come audio e video nelle
applicazioni Java, applets e Xlet. Dopo aver installato il simulatore bisogna copiare nella cartella
base, le API JavaTV scaricabili dal sito della Sun.
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
67
A questo punto non ci dovrebbero essere problemi per l’avvio del programma; è importante che
insieme alla finestra principale ne compaia anche un’altra, dove verranno scritti gli eventuali
messaggi d’errore, insieme ai messaggi di debug voluti dal programmatore, ovvero tutti i
System.out.println presenti nella Xlet.
Per fare ciò è necessario scrivere la seguente riga di comando, magari mettendola in un file batch:
cd C:\xletview-0.3.6 java -cp javatv_fcs/javatv.jar;xletview.jar;jars/metouia.jar;jars/javassist.jar;jars/nanoxml-2.2.3.jar net.beiker.xletview.Main cd.. Ora le finestre visibili dovrebbero essere le seguenti come mostrato in figura:
Figura 24. XletvView e finestra di debug
Nella schermata principale vengono visualizzati:
- a destra il telecomando con tutti i tasti per simulare, mediante mouse, la periferica
d’ingresso;
- nel riquadro giallo l’eventuale background layer, video layer e il graphics layer;
- i menù per poter eseguire la nostra applicazione.
Dal menu Applications, sotto ManageApplication, bisognerà inserire il classpath e il nome della
classe principale della Xlet.
Una volta che l’applicazione è stata mandata in “run”, dalla schermata di debug mostrata in Figura
25, sarà possibile vedere gli eventuali errori e messaggi.
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
68
Figura 25. XletView e finestra di debug dopo l'avvio
Mentre si programma bisogna tener conto che a differenza del PC, dove abbiamo a disposizione
tutte le API fornite dal JR1.4, sul Set Top Box vi è una versione ridotta della JVM , quindi bisogna
fare attenzione alle specifiche sulle API che si andranno ad usare messe a disposizione su
www.mhp.org e www.dvb.org , altrimenti si rischia di sviluppare applicazioni che “girano” solo su
simulatore.
4.3 Set-Top Box da sviluppo ADB x-75
Per completare il ciclo di sviluppo di una applicazione MHP, dopo che è stata sviluppata con
Eclipse e mandata in esecuzione su Xletview, manca solo la fase finale di test, che come abbiamo
detto consiste nel caricare l'applicazione su un Set Top Box da sviluppo. Riassumendo il nostro
ambiente di sviluppo quindi sarà costituito da un Personal Computer, da una normale TV munita di
presa SCART e da il Set Top Box da sviluppo ADB X-75, tutti elementi forniti dall’Azienda Sanitaria
Unica Regionale Zona 7. Le interconnessioni tra gli apparati appena elencati, come mostrato in
Figura 26, sono:
- il STB riceve in ingresso il segnale televisivo (da una comune antenna), è collegato
tramite SCART alla TV, e tramite seriale RS-232 al PC;
- sia il PC che il STB sono connessi in rete (LAN) successivamente ne chiariremo il motivo.
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
69
Figura 26. Workspace presso l'ASUR zona 7
4.3.1 Caratteristiche tecniche
Una delle più prestigiose ditte che forniscono strumenti per lo sviluppo in campo broadcast è
l'ADB, acronimo di Advanced Digital Broadcast. La serie X-75 comprende Decoder da sviluppo
per tre tecnologie: Cable, Satellite, Terrestrial, in conformità con lo standard DVB, quindi è più
corretto chiamare il nostro strumento ADB T.75.
Andiamo ad elencare innanzitutto i componenti e le caratteristiche Hardware mostrate nella
seguente Tabella 12:
ARCHITETTURA DESCRIZIONE
CPU STi5517 166MHz
Tuner/Front end DVB-T
Flash Memory 16MB
RAM Memory 72 MB
EEPROM 32 kB
Power Supply 90-264 VAC, 47-63Hz
Casing 440x260x50mm
OUTPUTS
RF input/output RF in & RF out (loop trought)
Audio/Video outputs
2xRCA (Stereo Audio), 2xSCART, S/PDIF optical
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
70
Return channel Ethernet lOBaseT, PSTN modem v.92
Data port Debug serial port (RS-232 up to 115.2 kbps)
Front panel display 4x7-segment LED display, 2 LEDs
DVB-CI slot Located on front panel
Smart card slot Located on front panel
ACCESSORI
Power Cable 1.8 m
SCART Cable 1.5 m
RS 232 Cable 2.0 m
CARATTERISTICHE DESCRIZIONE
MPEG VIDEO DECODING
Standards MPEG-2 MP@ML, CD ISO/IEC 13818-1, CD
ISO/IEC13818-2 Video Data Rate 0.5-15Mbps
Format Conversion 4:3 > 16:9 with Pan & Scan and Letterbox
Graphics Planes 4 planes(Background, Stili-piane, Video, OSD)
AUDIO DECODING
Standards MPEG-1 Layer 1&2; lóbitprecision, CD ISO/IEC 13818 3 Sampling Rate 32kHz,44.1kHz,48kHz
Variable Output Le el
16 steps @ 2dB per step
DOLBY Digital AC3 Pass throught to S/PDIF
TERRESTRIAL FRONTEND - T. 75
COFDM(DVB-T) ETSI EN 300 744
Modulation QPSK, QAM16, QAM64
Code rate Guard
Interval
½, 2/3, ¾, 5/6, 7/8 ¼, 1/8, 1/16, 1/32
Transmission modes 2k, 8k
Tabella 12. Specifiche ADB T-75
Un STB di buon livello, reperibile attualmente in commercio, presenta sicuramente le seguenti
caratteristiche:
- modem V.90;
- lettore Smart Card;
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
71
- doppia presa SCART;
- uscita audio RCA;
- uscita audio ottica;
- connettore seriale RS-232 per eventuali periferiche di ingresso;
II nostro Set Top Box da sviluppo, oltre ad avere tutte le caratteristiche di un normale decoder,
presenta:
- una maggior capacità di elaborazione (frequenza processore più elevata)
- una maggiore capacità di memorizzazione;
- interfaccia Ethernet;
- CI Common Interface;
- presa seriale RS-232 bidirezionale (permette l'upload dell'applicazione e il debug).
4.3.2 Pannello frontale
Mostriamo ora nei dettagli il pannello frontale e le funzionalità dei suoi componenti,
rispettivamente in figura 27 e nella tabella 13 componenti sono: 7 pulsanti, 2 indicatori LEDs, un
display, una CI Common Interface e una OCF Smart Card slot.
Figura 27. Pannello frontale ADB T-75
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
72
Tabella 13. Funzionalità pannello frontale
4.3.3 Pannello posteriore
In figura 28 si mostra come è composto il pannello posteriore.
Figura 28. Pannello posteriore ADB T-75
Vediamo in dettaglio i suoi componenti:
1. interruttore alimentazione;
2. presa alimentazione 220V ~ 50Hz;
3. connettore RS-232;
4. ingresso antenna;
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
73
5. uscita antenna (alla TV);
6. RJ11 jack modem;
7. RJ45 jack Ethernet;
8. Uscita AC3 ottica (Audio digitale);
9. SCART (connessione verso TV);
10. SCART (connessione verso eventuale VCR);
11. uscita audio RCA.
4.3.4 Telecomando
II telecomando e le funzionalità dei sui tasti sono mostrate in figura 29; non ci sono molte differenze
rispetto a quello dei comuni decoder, da notare il tasto "APP" che apre e chiude la finestra delle
applicazioni.
Figura 29. Telecomando e relative funzioni
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
74
4.3.5 Settaggio connessione di default
Diamo uno sguardo al menù principale del decoder ADB:
Figura 30. Organizzazione del menù del STB ADB T-75
Tra i vari sottomenù della voce “Setting”, in fondo troviamo “Internet Connection”, una volta
entrati apparirà una schermata dove è possibile scegliere se usare come predefinita la connessione
tramite modem PSTN o tramite Ethernet. La connessione Ethernet permette di far comunicare Il
STB con gli altri dispositivi della rete, a patto che al decoder sia associato un indirizzo IP; per fare
questo ci sono due modi Auto e Manual . Se si imposta “Auto” dal menù, verrà assegnato un
Indirizzo IP dinamico (si suppone che il server della rete abbia abilitato il DHCP). In caso contrario
si dovrà impostare su “Manual” e Si dovranno inserire i valori: IP (statico), Mask, Default Gateway e
il DNS primario e secondario. Modem Setting Se si vuole far connettere in rete il STB, usando il
Modem, bisogna impostare in questa schermata: N telefonico ISP, eventuale prefisso, tipo
composizione (impulsi/tone), username, password ed eventualmente l’opzione “aspetta segnale di
libero”.
4.3.6 Firmware upgrade
Prima di passare all'upload di un'applicazione è necessario aggiornare il firmware fornito dalla
casa madre.
Il software che risiede nel Set Top Box (STB), consiste in due parti principali: il decoder
code e il loader.
Il decoder code, anche chiamato codice di alto livello, è responsabile della ricezione, codifica e
visualizzazione di audio/video, e altri componenti come teletext, sottotitoli, etc.
Il loader non mostra ne video ne audio, ma visualizza all'utente alcune informazioni riguardanti
le fasi del processo o errori di download.
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
75
L'ADB fornisce insieme al STB un software chiamato ADB FastTerm, che interagisce con il loader
per aggiornare il firmware tramite la porta RS-232.
L'applicazione di cui sopra, si mostra come in figura 31; prima di utilizzarla per prima cosa
bisogna impostare il numero della porta COM (dal menù a tendina), sulla quale è connesso il
STB, assicurandosi che questa sia settata con i seguenti parametri:
- Baudrate 115200
- N° bit di dati 8
- Parità NO
- N° bit di stop 1
A questo punto, dal menù File - Open download file, si va ad aprire il file contenente
l'aggiornamento (*.enc), si spegne il STB per almeno 2 secondi, si tiene premuto il tasto freccia
sinistro situato sul pannello frontale e contemporaneamente si riaccende il STB. Il tasto deve
continuare ad essere premuto fino a che non si accendono i LED frontali, a questo punto si lascia il
pulsante e inizia il download del firmware sul STB; in questa fase la barra sulla destra
dell'applicazione inizia a colorarsi fino ad arrivare al 100%.
Figura 31. Finestra FastTerm
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
76
4.3.7 Upload e debug di una Xlet
La ditta produttrice del STB oltre al software “FastTerm”, fornisce anche l’ADB APPLOADER che
permette di trasferire la nostra applicazione, dal PC alla memoria del decoder, sempre tramite porta
seriale. In realtà la comunicazione tra i due dispositivi deve passare attraverso un secondo
programma, che fa da Proxy, il quale può risiedere localmente o trovarsi in un’altra macchina,
l’importante è che abbia un indirizzo IP valido e che sia connessa al STB. Quando si fa partire il
Proxy, bisogna specificare il numero di porta COM (con gli eventuali settagli) dove è connesso il
STB e il nome del file di log comprensivo di classpath; questo programma lavora usando il
protocollo TCP sulla porta standard 4444, a meno che non specificato diversamente. Il file di log è
un file di testo che viene generato dal STB ed è proprio questo che viene usato, in maniera simile al
simulatore, come strumento di debug.
La riga di comando con le varie opzioni e un’ esempio per inizializzare il Proxy sono:
stbproxy.exe -com <port_number>[-port <TCP port number>] [-rate<115200,8,N,1>][-log <logfile>] stbproxy.exe –com 3 –log c:\stb.log
Lavorando sotto Windows apparirà un’icona sulla barra degli strumenti, dove è possibile accedere,
tra le altre cose, all’opzione “svuotare” il file di log. L’ultima cosa da fare prima di passare all’
upload, è configurare il STB, a questo ci pensa un terzo tool chiamato “stbconfig” al quale bisogna
specificare l’indirizzo IP dell’host dove si trova il Proxy e l’eventuale numero di porta, se non si usa
quella di default; il suo scopo è quello di abilitare/disabilitare l’opzione di debug output e security
manager. La riga di comando con le varie opzioni e un’ esempio per configurare il STB ipotizzando
che il Proxy sia in locale, si usi il numero di porta TCP di default e si attivi solo l’opzione di debug
sono:
stbconfig.exe proxy_host_IP[:port] [-debug] [-security] stbconfig.exe localhost -debug Dopo aver effettuato la configurazione del STB si richiede il riavvio dello stesso. Finalmente siamo
arrivati alla fase finale, il Proxy è in running, il STB è configurato, ora manca di avviare il
trasferimento dell’applicazione. Il tool stbupload richiede l’IP del proxy, il nome del description file
(vedremo in seguito cosa sia) completo di classpath, e il classpath della directory base dov’è
contenuta l’applicazione (*.class e file accessori). La riga di comando con le varie opzioni e un’
esempio per fare l’upload di una applicazione contenuta nella directory c:\xlet\class, supponendo il
Proxy in locale con porta di default sono:
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
77
stbupload <proxy_host[:port]> <xlets_descr_file> <pc_base_dir> stbupload localhost c:\xlet\xlet_desciption_file c:\xlet\class Ora l’applicazione è copiata nella directory /home del file system del STB.
4.3.8 Xlet description file
L’Xlet description file riflette il contenuto della tabella AIT (Application Identification Table);
contiene tutte le informazioni e i parametri utili per l’identificazione e l’esecuzione dell’applicazione
da parte del Set Top Box. Vediamone un’ esempio:
Parametri obbligatori: #app <Application ID> <Organisation ID> app 0xhex_number 0xhex_number #Application control flag: 1=autostart 2=present 3=destroy 4=kill control 1 #service bound flag (0 or 1) bound 0 #Basedir of application (must be relative to /home directory) basedir "/home" #Initial class name (fully qualified name) class "your.company.Test" Parametri opzionali: #Name of application preceded by language code name eng "Test" #Parameter of service on which the application should be visible to application manager tsid 0x7 onid 0x46 svid 0x2bd #other flags priority 137 visibility 3 #Classpath extension classpath "" #String params passed to Xlet param = "value 0" param = "value 1" Ora cercheremo di spiegare in dettaglio i campi principali:
app
Ogni organizzazione che produce Xlet, deve essere riconosciuta, ed avere un codice identificativo
univoco, in più ogni applicazione prodotta da quell’ organizzazione deve anch’essa essere
riconoscibile univocamente. Questo per permettere al STB di non eseguire applicazioni maligne non
riconosciute.
Capitolo 4: Ambiente di sviluppo ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
78
control
Questo flag dice al STB come si deve comportare con l’applicazione che ha ricevuto:
se = 1 la manda in esecuzione appena caricata (per avvenire effettivamente l’esecuzione, nelle
impostazioni base del STB deve essere abilitata l’opzione autostart);
se = 2 il STB riceve l’applicazione è la mette disponibile nell’application manager, sarà l’utente poi a
decidere quando farla avviare (premendo app oppure OK, in base al modello di decoder, si
visualizzano le applicazioni disponibili);
se =3 viene distrutta (si usa se caricata con autostart);
se =4 viene killata (si usa se caricata con present);
bound
Questo flag dice se si tratta di una applicazione bound (1) legata al canale e alla trasmissione o
unbound (0) non legata alla trasmissione o addirittura non legata al canale (quindi disponibile
indifferentemente dal canale su cui si è sintonizzati);
basedir
campo contenente il classpath di destinazione dell’applicazione del file system nel STB (deve essere
relativo a /home);
class
deve contenere il nome della classe principale dell’applicazione (per es.:“main.class” )
name
specifica il codice della lingua usata e il nome, relativo all’applicazione, che comparirà
sull’Application Manager;
priority
nel caso in cui l’opzione “autostart” sia settata (nel menu di base del STB) e nell’Application
Manager, vi sono più di una Xlet caricata con il control flag=1, il STB manda in esecuzione
l’applicazione con la priorità più alta.
Capitolo 5: Progetto e realizzazione del portale informativo ASUR zona 7 ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
79
Capitolo 5
PROGETTO E REALIZZAZIONE DEL PORTALE INFORMATIVO A.S.U.R. ZONA 7
5.1 Obbiettivi del progetto
Il progetto svolto si pone l’obbiettivo principale di fornire agli utenti del digitale terrestre un servizio
informativo e di presentazione dell’Azienda Sanitaria Unica Regionale (A.S.U.R.) zona 7 di Ancona.
L’applicazione sviluppata deve considerarsi sostanzialmente come modulo applicativo di base nel
quale si e’ cercato di presentare i contenuti informativi in maniera chiara e semplice rendendolo il
piu possibile accessibile agli utenti. Il modulo base non e’ una struttura statica ma , al contrario, è
stato progettato in maniera tale da renderlo personalizzabile ed espandibile per potersi adattare alle
esigenze dell’ASUR zona 7.
Il prodotto realizzato è esclusivamente a carattere informativo per cui non necessita dell’utilizzo del
canale di ritorno ma è comunque stata prevista la possibilità di aggiungere servizi che sfruttino il
suddetto canale.
5.2 Descrizione del portale
Prima di passare alla descrizione sostanziale del progetto è importante sottolineare che sia il layout
grafico che le informazioni contenute nel portale sono state estratti dal sito ufficiale dell’ ASUR zona
7 ( www.asurzona7.marche.it ).
Per meglio comprendere il contesto in cui il portale si inserisce supponiamo di avere sintonizzato il
nostro televisore, tramite il Set Top Box, su un canale che eroga il servizio informativo in questione.
Come ampiamente descritto nei capitoli precedenti l’applicazione viene scaricata sul Set Top Box e
successivamente eseguita facendo comparire sullo schermo un tasto pilota, come mostrato in figura
32, attraverso il quale sarà possibile accedere al portale.
Per ridurre l’invasività del tasto pilota la dimensione dello stesso viene ridotta dopo 10 secondi
(figura 33) per poi scomparire del tutto dopo altri 10 secondi.
Capitolo 5: Progetto e realizzazione del portale informativo ASUR zona 7 ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
80
Figura 32. Tasto pilota del portale
Figura 33. Tasto pilota ridotto
Capitolo 5: Progetto e realizzazione del portale informativo ASUR zona 7 ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
81
A questo punto non resta che entrare nel portale e per farlo basta premere il tasto ROSSO come
viene indicato nel messaggio apparso sullo schermo (figura 32). Sul televisore viene visualizzata la
pagina di benvenuto come mostrato in figura:
Figura 34. Schermata di benvenuto nel portale
Si può notare che già da questa pagina nella parte bassa dello schermo viene visualizzata una piccola
guida che accompagnerà l’utente per tutta la navigazione nel portale.
Per aumentare l’accessibilità anche i colori dei caratteri e dello sfondo sono stati scelti in maniera
opportuna.
A seconda del tasto colorato premuto si accede al contenuto informativo corrispondente. In questo
caso si suppone di volere accedere al contenuto Farmacie e quindi dopo aver premuto il tasto verde
apparirà la seguente schermata:
Capitolo 5: Progetto e realizzazione del portale informativo ASUR zona 7 ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
82
Figura 35. Schermata Farmacie
Si nota che come detto in precedenza nella parte inferiore dello schermo continua ad essere presente
la guida in linea. Ora la navigazione procede utilizzando i tasti numerici del telecomando; essendo
interessati alle farmacie del Centro viene premuto il tasto numerico 1 e in questo modo viene
visualizzata la seguente pagina:
Capitolo 5: Progetto e realizzazione del portale informativo ASUR zona 7 ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
83
Figura 36. Farmacie zona Centro pagina1
Viene cosi visualizzato un elenco in ordine alfabetico delle farmacie, con relativo indirizzo, presenti
in questa zona ; è inoltre possibile scorrere le pagine premendo i tasti SU e GIU’.
Figura 37. Farmacie zona centro pagina2
Capitolo 5: Progetto e realizzazione del portale informativo ASUR zona 7 ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
84
Oltre ai tasti colorati e a quelli numerici si è scelto di utilizzare il tasto SINISTRA per tornare
indietro nella navigazione e il tasto EXIT per potere terminare l’applicazione e continuare la visione
del canale televisivo.
Sostanzialmente la navigazione si sviluppa in senso orizzontale, premendo i tasti colorati per passare
direttamente alla voce del menu desiderata, e in senso verticale, premendo i tasti numerici per
accedere ai sottomenù.
Per ciò che concerne il codice nell’appendice sono riportate le classi di maggiore importanza:
- MainXlet.java: nella quale sono stati definiti i metodi fondamentali per la gestione del ciclo
di vita della Xlet ;
- XletInterface.java: tramite la quale viene gestita la grafica del portale;
- MyContainer.java: classe che permette di utilizzare un contenitore generico sopra il quale
vengono costruiti i menù personalizzati a seconda dei contenuti.
Oltre a queste tre classi ne sono state implementate altre come MyText: che si occupa della gestione
e organizzazione dei testi che vengono visualizzati sul televisore.
Conclusioni ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
85
CONCLUSIONI Il progetto illustrato ha raggiunto gli obiettivi prefissati, si è giunti alla realizzazione di una Xlet
funzionante, testata ampiamente sul Set Top Box da sviluppo. L’Azienda Sanitaria Unica Regionale
zona 7 ha apprezzato il lavoro svolto che potrà essere sfruttato come punto di partenza per offrire
servizi informativi e di altro tipo ai cittadini. Inoltre la diffusione del digitale terrestre dopo lo
switch-off ricoprirà l’intero bacino di utenza dell’attuale televisione analogica rendendo ancora più
diffusi i servizi offerti che potranno essere sfruttati anche dai cittadini meno informatizzati.
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
86
APPENDICE: Codice ASURXlet MainXlet.java /* * Classe che implementa i metodi fondamentali necessari al funzionamento di una * Xlet, affinchè questa possa essere caricata su Set-Top Box o su un emulatore, * per esempio Xletview. */ import java.awt.Color; import java.awt.Font; import java.awt.Toolkit; import javax.tv.xlet.Xlet; //per creare, inizializzare, avviare, mettere in pausa e //distruggere una xlet,operazioni effettuate dall'application manager import javax.tv.xlet.XletContext; // per ottenere informazioni sull'ambiente di sviluppo della xlet, //una volta che questa viene inizializzata import javax.tv.xlet.XletStateChangeException; // per segnalare che il cambiamento di stato richiesto alla xlet è fallito import org.dvb.event.*; // per determinare gli eventi possibili sulla xlet import org.dvb.ui.DVBColor; import org.havi.ui.event.*; // per determinare le capacità e le modalità di input da parte dell'utente //della piattaforma su cui viene eseguita l'applicazione import org.havi.ui.HScene; // per rappresentare l'area visualizzabile nello schermo (in realtà non //viene creata, sono solo aggiunti i suoi componenti al contenitore) import org.havi.ui.HSceneFactory; // per generare effettivamente un oggetto di tipo HScene import org.havi.ui.HSceneTemplate; import org.havi.ui.HStaticIcon; import org.havi.ui.HStaticText; public class MainXlet implements Xlet, UserEventListener { private XletContext context; private HScene scene; private int c = 0; private EventManager manager; private HStaticText testo2; private UserEventRepository repository; private BackgroundController backgroundManager; private HStaticIcon image, image1; private Thread tread; public HSceneFactory factory = HSceneFactory.getInstance(); XletInterface interfaccia; // metodo per inizializzare la Xlet, operazione segnalata da un messaggio public void initXlet(XletContext xletContext) throws XletStateChangeException { System.out.println("Inizializzazione della xlet"); context = xletContext; } // metodo per eseguire la Xlet, operazione segnalata da un messaggio
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
87
public void startXlet() throws XletStateChangeException { System.out.println("Esecuzione della xlet"); // viene creato un nuovo oggetto di tipo repository che funge da // magazzino per gli eventi possibili mediante il telecomando repository = new UserEventRepository("UserRepository"); repository.addAllColourKeys(); // aggiunti i tasti colorati repository.addAllArrowKeys(); // aggiunti i tasti con le frecce repository.addAllNumericKeys(); // aggiunti i tasti numerici repository.addKey(HRcEvent.VK_ENTER); // aggiunto il tasto "OK" repository.addKey(HRcEvent.VK_ESCAPE); // aggiunyo il tasto "EXIT" repository.addKey(428); // aggiunto il tasto "-" (meno) repository.addKey(427); // aggiunto il tasto "+" (più) repository.addKey(151); // aggiunto il tasto "*" (asterisco) repository.addKey(520); // aggiunto il tasto "#" (cancelletto) System.out.println("Setting Repository completato"); manager = EventManager.getInstance(); // per abilitare la rivelazione // degli eventi manager.addUserEventListener(this, repository); // si aggiungono gli eventi possibili // all'oggetto manager creato backgroundManager = new BackgroundController(); displayBackgroundImage1(); } // metodo per mettere in pausa la Xlet, operazione segnalata da un messaggio public void pauseXlet() { System.out.println("xlet in pausa"); context.notifyPaused(); // notifica al manager dell'applicazione che la // xlet non è attiva, in quanto è entrata in uno // stato di pausa } // metodo per distruggere la Xlet e rilasciare le risorse da questa // utilizzate, operazione segnalata da un messaggio public void destroyXlet(boolean flag) throws XletStateChangeException { System.out.println("Distruggendo Xlet....."); //manager.removeAllUserEventListeners(); interfaccia.destroy(); displayBackgroundExit(); System.out.println("Xlet distrutta"); context.notifyDestroyed(); // notifica al manager dell'applicazione che // la xlet è entrata nello stato // "Destroyed", in quanto è stata distrutta } // metodo per gestire gli eventi associati alla pressione dei tasti del // telecomando del Set-Top-Box public void userEventReceived(UserEvent event) { switch(event.getCode()){ case HRcEvent.VK_ESCAPE: System.out.println("Premuto exit"); try{ displayBackgroundExit(); destroyXlet(true); } catch(XletStateChangeException xsce) {
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
88
xsce.getStackTrace(); } break; case HRcEvent.VK_COLORED_KEY_0: if (c == 0) { System.out.println("Premuto enter"); scene.setVisible(false); testo2.setVisible(false); scene.remove(testo2); scene.remove(image); scene.removeAll(); factory.dispose(scene); factory.dispose(scene); start(); c++; } break; } } // metodo per caricare lo sfondo della Xlet quando questa va in esecuzione public void displayBackgroundImage() { if (backgroundManager.init()) { backgroundManager.display("background.jpg"); backgroundManager.hideVideo(context,0,0,0,0); // per nascondere il video // che potrebbe oscurare lo // sfondo caricato System.out.println("Immagine di background caricata"); } } // metodo per caricare il tasto pilota iniziale public void displayBackgroundImage1() { if (backgroundManager.init()) { backgroundManager.hideVideo(context,0,0,720,576); // per nascondere il video // che potrebbe oscurare lo // sfondo caricato System.out.println("bottone iniziale di background caricato"); HSceneTemplate hst = new HSceneTemplate(); scene =factory.getBestScene(hst); scene.setBounds(0, 0, 500, 200); image= new HStaticIcon(Toolkit.getDefaultToolkit().getImage("ok.jpg"),36,36,139,105); scene.add(image); testo2 = new HStaticText( "Premere il tasto ROSSO per\naccedere ai contenuti interattivi", 36+139, 36, 300, 105); testo2.setFont(new Font("Tiresias", Font.PLAIN, 24)); testo2.setBackground(new DVBColor(0, 0, 255, 200)); testo2.setForeground(Color.white); testo2.setHorizontalAlignment(HStaticText.HALIGN_LEFT); testo2.setVerticalAlignment(HStaticText.VALIGN_CENTER); scene.add(testo2);
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
89
scene.setVisible(true); testo2.setVisible(true); tread =new Thread(); tread.start(); try { Thread.sleep(10000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } testo2.setVisible(false); image.setVisible(false); image1= new HStaticIcon(Toolkit.getDefaultToolkit().getImage("rosso.jpg"),36,36,36,36); scene.add(image1); try { Thread.sleep(10000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } image1.setVisible(false); } } public void displayBackgroundExit() { System.out.println("distruzione background"); backgroundManager.dispose(context); } public void start (){ System.out.println("Esecuzione della xlet"); System.out.println("Loading Background image....."); displayBackgroundImage(); // viene caricata l'immagine di background // (sfondo) interfaccia = new XletInterface(); // creato un nuovo oggetto di tipo // XletInterface, che si occupa // dell'aspetto grafico della Xlet e // del suo comportamento in risposta // all'interazione dell'utente. }
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
90
XletInterface.java /* * Classe che si occupa dell'aspetto grafico della Xlet e del * suo comportamento in risposta all'interazione dell'utente. */ // Per prima cosa, devono essere incluse le librerie necessarie //import java.awt.Color; import java.awt.Color; import java.awt.Font; import java.awt.event.KeyEvent; // per associare un codice a ciascun evento, affinchè a questo //corrisponda un cambiamento grafico della xlet import java.awt.event.KeyListener; // per captare l'evento compiuto import org.dvb.ui.DVBColor; import org.havi.ui.HScene; // per rappresentare l'area visualizzabile nello schermo (in realtà //non viene creata, sono solo aggiunti i suoi componenti al contenitore) import org.havi.ui.HSceneFactory; // per generare effettivamente un oggetto di tipo HScene import org.havi.ui.HSceneTemplate; // per specificare la locazione e le dimensioni dell'oggetto HScene import org.havi.ui.HStaticText; import org.havi.ui.event.HRcEvent; public class XletInterface { public HStaticText testo6; private HScene scene; public static final int EXIT = HRcEvent.VK_ESCAPE; MyContainer first; MyContainer page; KeyListener listener; public XletInterface() { HSceneFactory factory = HSceneFactory.getInstance(); // HSceneFactory ritorna un appropriato contenitore HScene // che l'applicazione sfrutta per visualizzare essa stessa HSceneTemplate hst = new HSceneTemplate(); // un oggetto di questo tipo è necessario poichè // l'applicazione richiede che HSceneFactory // effettivamente gli garantisca l'accesso alla porzione di schermo // voluta, per esempio visualizzazione in full-screen scene =factory.getBestScene(hst); scene.setBounds(36, 29, 635, 510); // per settare i limiti dell'applicazione grafica scene.setLayout(null); scene.setBackgroundMode(HScene.BACKGROUND_FILL); // per settare la modalità di sfondo a "riempito" System.out.println("Creazione scena"); page = new MyContainer(0, 0, 635, 510); first = new MenuPrincipale(page, null); System.out.println("Creazione MenuPrincipale"); page.setVisible(true);
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
91
// per visualizzare l'oggetto, che altrimenti // esisterebbe ma non sarebbe visibile first.setVisible(true); scene.add(page); // per aggiungere il nuovo oggetto di tipo // MyContainer a quello "scene" di tipo HScene testo6 = new HStaticText("CARICAMENTO IN CORSO...", 5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1)); testo6.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo6.setBackground(new DVBColor(255,0,0,255)); testo6.setForeground(Color.white); testo6.setHorizontalAlignment(HStaticText.HALIGN_CENTER); testo6.setVerticalAlignment(HStaticText.VALIGN_TOP); scene.add(testo6); testo6.setVisible(false); scene.addKeyListener(new KeyListener() { public void keyTyped(KeyEvent arg0) { } public void keyPressed(KeyEvent arg0) { MyContainer c = first; while (c.next != null) c = c.next; c.keyPressed(arg0.getKeyCode()); } public void keyReleased(KeyEvent arg0) { } }); // anche il rilascio del tasto premuto è in realtà un evento quindi // bisogna creare il metodo associato, affinchè a lato pratico, non // accada niente System.out.println("KeyListener ATTIVO"); scene.setVisible(true); scene.requestFocus(); scene.validate(); } // Metodo per la distruzione della Xlet public void destroy() { if (scene != null) { System.out.println("Distruzione della Xletinterface"); scene.setVisible(false); scene.removeAll(); page.removeAll(); first.removeAll(); scene.setVisible(false); HSceneFactory.getInstance().dispose(scene); scene = null; } } }
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
92
MyContainer.java import java.awt.BorderLayout; import java.awt.Toolkit; import org.havi.ui.HContainer; import org.havi.ui.HStaticIcon; //per rappresentare un'immagine grafica import org.havi.ui.HStaticText; public class MyContainer extends HContainer implements KeysInterface { private static final long serialVersionUID = 1L; protected MyContainer container = null; HStaticText testo6; protected MyContainer prev = null; XletInterface interfaccia; protected MyContainer next = null; public MyContainer() { super(); } public MyContainer(int x, int y, int w, int h) { super(x, y, w, h); } public void init() { next = null; removeAll(); container.removeAll(); container.setLayout(new BorderLayout()); container.add(this, BorderLayout.CENTER); setLayout(null); System.out.println("Contenitore inizializzato "); } public void initAR() { next = null; removeAll(); interfaccia = new XletInterface(); container.removeAll(); container.setLayout(new BorderLayout()); container.add(this, BorderLayout.CENTER); setLayout(null); System.out.println("Contenitore inizializzato "); } public void update() { System.out.println("Contenitore aggiornato"); } public void keyPressed(int k) { switch (k) {
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
93
case Telecomando.ROSSO: pressedRosso(); break; case Telecomando.VERDE: pressedVerde(); break; case Telecomando.GIALLO: pressedGiallo(); break; case Telecomando.BLU: pressedBlu(); break; case Telecomando.SU: pressedSu(); break; case Telecomando.GIU: pressedGiu(); break; case Telecomando.SINISTRA: pressedSinistra(); break; case Telecomando.DESTRA: pressedDestra(); break; case Telecomando.OK: pressedOK(); break; case Telecomando.UNO: pressed_1(); break; case Telecomando.DUE: pressed_2(); break; case Telecomando.TRE: pressed_3(); break; case Telecomando.QUATTRO: pressed_4(); break; case Telecomando.CINQUE: pressed_5(); break; case Telecomando.SEI: pressed_6(); break; case Telecomando.SETTE: pressed_7();
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
94
break; case Telecomando.OTTO: pressed_8(); break; case Telecomando.NOVE: pressed_9(); break; case Telecomando.ASTERISCO: pressedAsterisco(); break; case Telecomando.CANCELLETTO: pressedCancelletto(); break; case Telecomando.ZERO: pressed_0(); break; case Telecomando.EXIT: pressedExit(); break; case Telecomando.MENO: pressedMeno(); break; case Telecomando.PIU: pressedPiu(); break; } } public void pressedRosso() { next = new MenuPrincipale(container, this); System.out.println("Tasto Rosso premuto -- MenuPrincipale"); } public void pressedVerde() { next = new Farmacie(container, this); System.out.println("Tasto Verde premuto -- Farmacie"); } public void pressedGiallo() { next = new Medici(container, this); System.out.println("Tasto Giallo premuto -- Medici"); } public void pressedBlu() { next = new NumeriUtili(container, this); System.out.println("Tasto Blu premuto -- NumeriUtili"); } public void pressedSu() { System.out.println("Tasto SU premuto -- pagina precedente"); } public void pressedGiu() { System.out.println("Tasto GIU premuto -- pagina successiva");
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
95
} public void pressedSinistra() { System.out.println("Tasto SINISTRA premuto -- torna al menu precedente"); if (prev != null) prev.init(); else System.exit(0); } public void pressedDestra() { } public void pressedOK() { } public void pressed_0() { System.out.println("Tasto 0 premuto "); } public void pressed_1() { System.out.println("Tasto 1 premuto "); } public void pressed_2() { System.out.println("Tasto 2 premuto "); } public void pressed_3() { System.out.println("Tasto 3 premuto "); } public void pressed_4() { System.out.println("Tasto 4 premuto "); } public void pressed_5() { System.out.println("Tasto 5 premuto "); } public void pressed_6() { System.out.println("Tasto 6 premuto "); } public void pressed_7() { System.out.println("Tasto 7 premuto "); } public void pressed_8() { System.out.println("Tasto 8 premuto "); } public void pressed_9() { System.out.println("Tasto 9 premuto "); } public void pressedAsterisco() { } public void pressedCancelletto() { }
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
96
public void pressedPiu() { } public void pressedMeno() { } public void pressedExit() { } //metodo per distruggere la xlet public void destroy(MyContainer container){ if(container!=null){ container.setVisible(false); container.removeAll(); container=null; System.out.println("Distruzione del contenitore completata"); } } protected void addElements() { // richiamo qsto metodo per visualizzare solo l'intestazione HStaticIcon i; // intestazione i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("intestazione.png"), 5, 0, 635,75); add(i); System.out.println("Immagine caricata: Intestazione aggiunta"); } protected void addElements1() { // richiamo qsto metodo per visualizzare i bottoni colorati HStaticIcon a,b,c,d; // bottone rosso a = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneRossoChiaro.jpg"), 5, 76, 157, 53 ); add(a); System.out.println("Immagine caricata: BottoneRossoChiaro aggiunto"); // bottone verde b = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneVerde.JPG"), 5+157+1, 76, 157, 53); add(b); System.out.println("Immagine caricata: BottoneVerde aggiunto"); // bottone giallo
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
97
c = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneGiallo.JPG"), 5+157+1+157+1, 76, 157, 53); add(c); System.out.println("Immagine caricata: BottoneGiallo aggiunto"); d = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneBlu.JPG"), 5+157+1+157+1+157+1, 76, 157, 53); add(d); System.out.println("Immagine caricata: BottoneBlu aggiunto"); } protected void addElements2() { // richiamo qsto metodo per visualizzare i bottoni colorati, //quando sono dentro al verde(farmacie) HStaticIcon i; // bottone rosso i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneRosso.JPG"), 5, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneRosso aggiunto"); // bottone verde i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneVerdeChiaro.JPG"), 5+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneVerdeChiaro aggiunto"); // bottone giallo i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneGiallo.JPG"), 5+157+1+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneGiallo aggiunto"); // bottone blu i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneBlu.JPG"), 5+157+1+157+1+157+1,76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneBlu aggiunto"); } protected void addElements3() { // richiamo qsto metodo per visualizzare i bottoni colorati, //qdo sono dentro al giallo(medici) HStaticIcon i; // bottone rosso i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneRosso.JPG"), 5, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneRosso aggiunto"); // bottone verde i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneVerde.JPG"),
Appendice: Codice ASURXlet ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
98
5+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneVerde aggiunto"); // bottone giallo i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneGialloChiaro.JPG"), 5+157+1+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneGialloChiaro aggiunto"); // bottone blu i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneBlu.JPG"), 5+157+1+157+1+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneBlu aggiunto"); } protected void addElements4() { // richiamo qsto metodo per visualizzare i bottoni colorati, // qdo sono dentro al blu(numeri utili) HStaticIcon i; // bottone rosso i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneRosso.JPG"), 5, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneRosso aggiunto"); // bottone verde i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneVerde.JPG"), 5+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneVerde aggiunto"); // bottone giallo i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneGiallo.JPG"), 5+157+1+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneGiallo aggiunto"); // bottone blu i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneBluChiaro.JPG"), 5+157+1+157+1+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneBluChiaro aggiunto"); } }
Siti e bibliografia ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
99
SITI E BIBLIOGRAFIA
www.dvb.org
www.devicetop.com
www.mhp.org
www.etsi.org
www.mhp-interactive.org
www.sourceforge.net
www.dttlab.it
www.labtv.it
www.cineca.it
www.eclipse.org
www.coremedia.com
www.televisionedigitaleterrestre.it
www.interactivetvweb.org
www.digitaleterrestre.it
www.java.sun.com
www.javastaff.com
www.nionex.com
www.havi.org
www.asurzona7.marche.it
Siti e bibliografia ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
______________
100
Steven Morris, Anthony Smith-Chaigneau: “Interactive TV Standard – A Guide to MHP, OCAP and Java TV”. V.Mignone, A.Morello, M.Visintin: “Lo standard DVB-T per la televisione digitale terrestre”. Edward M. Schwalb: “Libro bianco sulla televisione digitale terrestre”
JavaTV API Technical overview
CEI – Guida alla tecnologia e a i servizi dei ricevitori (Set Top Box e televisori digitali
integrati) per la televisione digitale terrestre