UNIVERSITÀ POLITECNICA DELLE MARCHE - AIRT Labairtlab.dii.univpm.it/it/system/files/thesis/marchi-erik-thesis.pdf · 2.3.6 Control Unit..... 43 2.3.7 Bootloader ... Ogni singola

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


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;


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.


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);


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 è


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


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


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


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.


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


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.


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


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.


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


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)


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.


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.


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


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).


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


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


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).


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.


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;


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.


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).


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.


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).


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


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


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:


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.


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.


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.


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.


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;


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


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


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.


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


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();


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


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


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:


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.


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).


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”:


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


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();


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 {


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


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


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:


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:


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


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:


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.


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.


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.


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


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;


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


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;


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


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.


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


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:


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.


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.


80

Figura 32. Tasto pilota del portale

Figura 33. Tasto pilota ridotto


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:


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:


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


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


______________

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) {


______________

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);


______________

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. }


______________

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);


______________

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; } } }


______________

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) {


______________

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();


______________

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");


______________

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() { }


______________

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


______________

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"),


______________

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

Documents

UNIVERSITÀ POLITECNICA DELLE MARCHE - AIRT Labairtlab.dii.univpm.it/it/system/files/thesis/marchi-erik-thesis.pdf · 2.3.6 Control Unit..... 43 2.3.7 Bootloader ... Ogni singola