Acquisizione Dati Tramite RS-232 del Decoder del Digitale Terrestre ed Invio Tramite Lo Stack TCP/IP

Transcript

1 UNIVERSITA POLITECNICA DELLE MARCHE FACOLTA DI INGEGNERIA Corso di Laurea in Ingegneria Informatica e dell Automazione Acquisizione Dati Tramite RS-232 del Decoder del Digitale Terrestre ed Invio Tramite Lo Stack TCP/IP Relatore Prof. Aldo Franco Dragoni Tesi di Laurea di Riccardo Biancucci Anno Accademico 2007 / 2008

2 Indice 1 - Introduzione. pag MHP, Una Breve Panoramica Il Contesto: La Televisione Digitale Terrestre DVB-T: Elementi Correlati allo Sviluppo di Applicazioni MHP Il Middleware MHP MHP, Alcune API e Funzionalità di Specifico Interesse org.dvb.test.dvbtest java.lang.runtime Broadcast Filesystem Memorizzazione Persistente Return Channel Considerazioni Operative e Qualche Proof of Concept Acquisizione Dati da Interfaccia RS Accesso al Filesystem Persistente Classe DataRetriever Interfaccia DataRetrieverInterface Classe DataRetrieverOsmosys Connettersi ad un ISP Classe NetConnection

3 4.5 - Invio dei Dati ad Un Sistema Remoto Tramite TCP/IP pag Classe TCPClient Classe SocketIOUtil Un Server per La Ricezione dei Dati Inviati Classe TCPServer Classe TCPServerTest Classe SocketIOUtil in TCPServer Accedere ad Una Risorsa nell Object Carousel Un File di Configurazione Classe ConfigFileParser Una Xlet Minimale Classe RS232toTCP Conclusioni Fonti di Documentazione in Formato Elettronico e Bibliografia. 84 2

4 1 - Introduzione Alcune caratteristiche della piattaforma DVB-MHP (Digital Video Broadcasting Multimedia Home Platform) per la televisione digitale terrestre, quali l elevato grado di programmabilità tramite un linguaggio di programmazione completo e di uso diffuso come Java e tramite una parte delle API standard in tale linguaggio, la disponibilità del cosiddetto return channel che permette di sfruttare, almeno in parte, le potenzialità di Internet, il costituire, almeno nell area europea, uno standard sia di fatto che, per gran parte, anche formale, rendono un Set Top Box (o STB per brevità) conforme alle specifiche MHP un terminale adatto alla fruizione, oltre che dei tipici contenuti televisivi, di una vasta gamma di servizi, servizi non necessariamente appartenenti o correlati all ambito dell intrattenimento. Inoltre i fattori tipici del nuovo sistema televisivo e della citata piattaforma tecnologica su cui esso è imperniato, che hanno reso e stanno rendendo (a differenza di altri sistemi televisivi digitali, anch essi potenzialmente interattivi, ad esempio la tv satellitare) la relativa utenza sempre più di massa, costituiscono un ulteriore incentivo a considerare la televisione digitale terreste ed i STB MHP (o dispositivi equivalenti, ormai il relativo hardware e software è integrato spesso nei televisori) mezzi idonei anche per l erogazione di servizi. Ulteriore punto a favore, nell ottica menzionata, è costituito dalla semplicità intrinseca dei metodi di interazione, tramite telecomando; paradigma ormai consolidato da decenni praticamente presso la totalità della popolazione ed ereditato anche nell uso di un terminale MHP; unitamente al fatto che per esempio un STB è un mezzo a basso costo (o relativamente a basso costo) rispetto ad altri adatti alla fruizione di servizi telematici (tipicamente, un PC), ciò potrebbe rendere più agevole raggiungere con un dato servizio anche quelle categorie di utenza tradizionalmente più refrattarie alla tecnologia o meno propense ad investire in tale ambito, come ad esempio una consistente parte delle popolazione al di sopra di una certa età. Con un occhio di riguardo proprio a queste ultime considerazioni, una delle tipologie di servizio ipotizzabili, non correlate all ambito del tradizionale contenuto televisivo o all intrattenimento in generale, potrebbe essere quella che preveda di utilizzare un terminale MHP come una sorta di ponte per inviare a ad un sistema remoto dei dati acquisiti da un dispositivo ad esso collegato, magari dati di tipo biometrico, nell ottica di un sistema di tele-monitoraggio in ambito medico, ad esempio. 3

5 E infatti possibile reperire STB che dispongano di una interfaccia di connessione conforme allo standard EIA RS-232 (una comune porta seriale, tipicamente); ad esempio alcuni dispositivi di comune uso in ambito medico, quali alcune macchine per l ECG, dispongono della medesima interfaccia, il che rende questo tipo di connessione attualmente la principale candidata per gli scopi ipotizzati. Il presente elaborato si pone come uno studio preliminare atto ad analizzare metodi, tecnologie e problematiche correlate nell ottica di poter utilizzare un terminale MHP, tramite una opportuna applicazione, per acquisire dati attraverso l interfaccia seriale e poi inviarli ad un sistema remoto, sfruttando l implementazione del return channel (tramite connessione ad un ISP, volendo veicolare i dati attraverso Internet); in particolare, l analisi sarà rivolta alle funzionalità ed alle interfacce di programmazione potenzialmente utili all obiettivo descritto, tra quelle messe a disposizione dal middleware MHP. Da qui in avanti, riferendosi alla piattaforma MHP, alla relativa specifica ed API in essa incluse, ove non diversamente esplicitato, si intenderà riferirsi alla versione 1.0.2: si opta per il minimo comun denominatore dato che non vi è ancora una diffusione significativa di dispositivi implementanti il ramo 1.1 della specifica e che con tipologie di servizi come quelle ipotizzate le caratteristiche esclusive della specifica più recente non sarebbero essenziali; inoltre, nell ottica di erogare un servizio anche se di diverso tipo e più tradizionale, massimizzare il bacino di utenza può essere un fattore importante. Si consideri poi che la maggioranza dei STB in commercio di fatto implementa MHP 1.0 ma i produttori spesso non si curano di ottenere la certificazione relativa o semplicemente dichiarare la particolare revisione implementata; ed ancora, anche dando tutto il peso che meriterebbero alle certificazioni, la test suite che deve essere eseguita con successo da un terminale MHP per ottenerle, è attualmente ferma alla versione Ecco quindi altri due motivi per cui si ripiega sulla specifica 1.0.2, la prima tra quelle tuttora disponibili, anche rispetto alla 1.0.3, sebbene quest ultima, comprensiva di errata corrige 3, venga indicata come quella (attualmente) definitiva per quel che riguarda il ramo

6 2 - MHP, Una Breve Panoramica Come già accennato, MHP (Multimedia Home Platform) è il nome collettivo per un insieme di specifiche per un middleware aperto basato su Java, specifiche definite dal DVB-Project intorno al quale si raccoglie un consorzio di importanti aziende attive nell ambito del video digitale e delle telecomunicazioni. Le specifiche MHP sono definite in modo che un sistema conforme possa funzionare con tutte le tecnologie di trasmissione DVB (chiaramente, MHP verrà qui considerato in particolare in relazione allo standard DVB-T). Inoltre gli standard DVB sono stati in seguito adottati anche in aree extra europee e la loro adozione è tuttora in espansione. Da MHP è anche stato tratto un sottoinsieme chiamato Globally Executable MHP o GEM, che non contiene la parte relativa specificamente alle direttive DVB per quel che riguarda la trasmissione dati, in modo da avere un middleware applicabile anche in mercati che usino differenti formati di trasmissione, o anche in contesti non necessariamente legati alla ricezione di contenuti ed applicazioni trasmessi in broadcast (ad esempio GEM è stato anche adottato nella specifica del profilo di interattività per il noto formato multimediale Blu-ray Disc) con il vantaggio di mantenere una parziale interoperabilità. Attualmente, sia MHP che GEM sono pubblicati come standard aperti dall ETSI (European Telecommunications Standards Institute) Di seguito si danno alcuni cenni generali relativi ad MHP, iniziando dall ambito in cui tale middleware è più utilizzato e da alcuni elementi dello standard DVB-T correlati al concetto di applicazione MHP, per poi analizzare brevemente quanto propone la specifica MHP in sé, con particolare riguardo alle interfacce di programmazione Il Contesto: La Televisione Digitale Terrestre La televisione digitale terrestre o DTT (Digital Terrestrial Television), sul punto di soppiantare del tutto, anche in base ad un apposito quadro normativo, il sistema di trasmissione analogico, può essere vista, nella realtà italiana, come l ultimo tassello che si aggiunge a quel processo che in poco più di un decennio ha portato i principali flussi informativi alla codifica digitale. 5

7 I vantaggi del sistema DTT risiedono principalmente nei seguenti elementi: - l adozione, appunto, di un sistema di trasmissione digitale che rispetto al classico sistema analogico presenta maggiore robustezza rispetto alle interferenze, possibile miglior quantità del segnale trasportato (in termini di maggiore informazione veicolata), occupazione di minore banda nell intervallo delle frequenze utilizzabili per la trasmissione; il tutto implica potenzialmente una maggiore qualità visiva e maggiore quantità di canali televisivi disponibili; - la presenza di un canale di ritorno bidirezionale che collegando il ricevitore ad una rete di telecomunicazioni permetta all utente di interagire, attraverso opportuni stadi intermedi, con il fornitore di contenuti (emittente televisiva) e/o con eventuali fornitori di servizi aggiuntivi/correlati (di fatto, ad oggi questa caratteristica si traduce nell implementare sui ricevitori DTT quanto necessario affinché siano tecnicamente disponibili, almeno in parte, le potenzialità offerte da Internet); - la compatibilità del segnale, a livello fisico, con il segnale analogico: questo implica la possibilità per l utente di ricevere il segnale digitale con gli apparati, in quanto ad antenne e cablaggi, pre-esistenti; - l adozione, sia per quel che riguarda la codifica (non con riferimento alla contrapposizione binaria/analogica ma più in generale ed ad alto livello alle strutture dati veicolate) delle informazioni trasmesse che riguardo alla gestione dei vari aspetti dell interattività a livello di terminale dell utente, di tecnologie che, quantomeno nell area europea, costituiscono ad oggi uno standard di fatto, nonché anche formale in buona parte, in quanto molto di quanto messo a punto dal consorzio DVB (Digital Video Broadcasting) per i sistemi DVB-T (DVB-Terrestrial) ed MHP è stato ratificato dall ETSI (European Telecommunications Standards Institute). Gli ultimi due punti costituisco una forte base per un sempre maggiore allargamento dell utenza del sistema DTT (il che, in realtà, nel nostro paese, è anche un fatto direttamente implicato dal quadro normativo in essere) ed anche per una sempre maggiore fruizione della cosiddetta itv (interactive TV), probabilmente più di quanto sia avvenuto sino ad oggi nel quadro per esempio della televisione satellitare che pur ne ha teoricamente le potenzialità tecniche; infatti la fruizione di servizi interattivi nell ambito del sistema DTT è facilitato dal fatto che i fornitori di tali servizi si trovano ad operare su una piattaforma che sostanzialmente standardizza tutti gli elementi necessari all interoperabilità e che nasconde le differenze proprie degli specifici dispositivi in possesso dell utenza. 6

8 La seguente figura mostra una rappresentazione, a livello indicativo e macroscopico, di una tipica catena di trasmissione relativa al sistema DTT, che vede i suoi principali elementi nel fornitore di contenuti, nell fornitore di applicazioni (che vengono eseguite sul terminale dell utente) per l interattività, in un eventuale fornitore di servizi terzo rispetto ai primi due (servizi anche non necessariamente strettamente correlati ai tipici contenuti del servizio televisivo), negli stadi necessari per un eventuale feedback da parte dell utente attraverso Internet e negli apparati per il mixaggio e la modulazione affinché sia i contenuti audio-visuali che altri tipi di dati siano trasmessi in modo conforme alle specifiche DVB-T; e, ovviamente, nel terminale in possesso dell utente, elemento tutt altro che trascurabile in quanto ospita il middleware MHP, elemento importante nell economia complessiva di tutto il sistema. (immagine tratta da ) 7

9 In questa visione complessiva del sistema DTT, si può puntualizzare che, teoricamente, non si potrebbe dare per scontata la disponibilità per tutti gli utenti del return cannel, in quanto, in linea di principio, un produttore di ricevitori per la tv digitale, potrebbe anche costruire un dispositivo conforme alle specifiche per la gestione di un flusso dati DVB-T senza implementare il middleware MHP (la cui specifica prevede appunto nel terminale la presenza di hardware atto a fornire un qualche tipo di connessione remota e le relative interfacce di programmazione per usarlo, indipendenti dal dispositivo specifico); inoltre la stessa specifica MHP prevede un profilo (si tornerà in seguito sui profili definiti dalla specifica MHP) di conformità che non include obbligatoriamente il return channel. Tuttavia, almeno nell area europea, si tratta di un inconveniente che fortunatamente rimane solo sulla carta in quanto i produttori di dispositivi per la ricezione della DTT hanno sin dall inizio della produzione di massa di tali prodotti implementato anche le specifiche MHP, inclusive nella totalità dei casi (quantomeno statisticamente parlando ) della caratteristica return channel (in genere, ad oggi, tramite inclusione di modem PSTN) DVB-T: Elementi Correlati allo Sviluppo di Applicazioni MHP Le scelte tecnologiche che si possono operare nell implementazione di un sistema televisivo digitale ed interattivo sono innumerevoli, come testimonia ad esempio la grande quantità di formati disponibili per la codifica digitale di audio e video. Senza uno standard che copra un area geografica quantomeno relativantemente vasta, sia i fruitori di contenuti e servizi che i fornitori dei medesimi, si troverebbero in un sistema afflitto da varie difficoltà ed inefficienze e caratterizzato con tutta probabilità da tante scelte ugualmente sbagliate. Le specifiche per la TV digitale a livello europeo, con un lavoro iniziato negli anni 80, sono state formalizzate e ed in seguito ratificate come standard ETSI dal consorzio DVB (Digital Video Broadcasting). Sono state definite tre specifiche principali: DVB-S, DVB-C, DVB-T relative alla trasmissione digitale rispettivamente satellitare, via cavo e via etere ma esclusivamente tramite apparati a terra, ovvero terrestre, appunto. Tali specifiche prevedono il formato MPEG-2, al momento della scelta già ampiamente diffuso, per l audio ed il video (per l audio, esattamente le specifiche MPEG-2 layer I e MPEG-2 layer II ), quello DSM-CC per il trasporto nel medesimo segnale anche di dati di tipo non audio-visuale (basandosi sul fatto che un MPEG Transport Stream o MPEG-TS è per sua specifica adatto anche ad incapsulare contenuti aggiuntivi a quelli audio-video). 8

10 Infine in tempi più recenti è stata formalizzata, allo scopo di fornire strumenti unificati principalmente per l interattività, la specifica DVB-MHP (più comunemente referenziata, così come nel presente testo, semplicemente come MHP ), con la versione più remota tra quelle ad oggi pubblicamente disponibili, la 1.0.2, datata giugno Lo standard DVB definisce tutte le caratteristiche che deve possedere un sistema per la trasmissione digitale. Per quel che riguarda il livello logico: - formato audio/video - regolamentazione dei flussi dati - formato dei pacchetti - segnalazione dei servizi - uso di dati non audio/video e protocolli esterni Relativamente al livello fisico, la specifica definisce le caratteristiche del segnale nei vari mezzi fisici inerenti i diversi ambiti DVB-S/C/T Essendo interessati all ambito del sistema DTT, ci si focalizzerà ovviamente sullo standard DVB-T, o meglio, come da titolo del presente paragrafo, su alcuni specifici aspetti, spesso rilevanti nello sviluppo di una applicazione MHP o che comunque potrebbero esserlo nell implementare una applicazione adatta agli scopi delineati inizialmente nel presente elaborato. Un singolo MPEG-2 TS (Transport Stream) può contenere più Packetized Elementary Stream o PES (uno o più PES compongono un singolo programma o servizio televisivo); per come sono strutturati i pacchetti del TS, un demultiplexer può selezionare un Elementary Stream accettando tutti i pacchetti con un dato PID (Packet IDentifier) e può quindi ricostruire un programma completo conoscendo i PID dei relativi flussi audio, video ed eventualmente flussi contenenti dati aggiuntivi. La PSI (Program Specific Information) è la struttura dati attraverso la quale un decoder riesce ad associare i vari PID, e quindi i singoli PES, ad un programma televisivo. Essa si compone di quattro tabelle: - la PAT (Program Association Table) stabilisce in un TS la corrispondenza tra un programma e la definizione (ovvero la PMT) del programma stesso. Ogni TS deve quindi contenere una PAT non criptata; - la PMT ( Program Map Table) stabilisce la corrispondenza tra un programma ed i PES che lo compongono (tramite i PID); 9

11 - la NIT ( Network Information Table) contiene i dati di rete relativi ai TS: frequenze di canale, numeri dei transponder, modulazione, etc.; - la CAT (Conditional Access Table) stabilisce la correlazione tra i sistemi di oscuramento dei programmi ed i vari TS del flusso MPEG-2; I dati di queste tabelle sono trasmessi in pacchetti di TS aventi uno specifico PID riservato a tale scopo dalla specifica e la ritrasmissione ciclica di questi particolari pacchetti avviene con una frequenza più elevata rispetto ad altri in modo che il dispositivo terminale possa rapidamente accedere al programma selezionato dall utente. La PSI fornisce quindi l informazione necessaria al terminale per il demultiplexing e la decrittazione di qualunque evento o servizio contenuto in un TS. A tale struttura dati deve essere aggiunta una ulteriore serie di tabelle che contengono informazioni sui servizi disponibili, sugli eventi, descrizioni testuali, informazione per il raggruppamento dei servizi in categorie ed altro. Tale insieme di tabelle prende il nome di DVB-SI (DVB Services Information) e si compone dei seguenti elementi: - BAT (Bouquet Association Table): contiene il nome del bouquet con i servizi che lo compongono; - SDT (Service Description Table): contiene le descrizioni dei servizi del bouquet; - EIT (Event Information Table): contiene i metadati relativi ai programmi, ad esempio ora di inizio, durata, nome, etc.; - RST (Running Status Table): contiene valori flag che descrivono lo stato di un evento; gli stati possibili sono iniziato / non-iniziato; - TDT (Time and Date Table): fornisce ora e data relativamente al fuso orario di riferimento; - TOT (Time Offset Table): fornisce ora e data della zona dove viene ricevuto il TS; - ST (Stuffing Table) : valida/invalida sezioni esistenti; 10

12 In un TS MPEG-2 è inoltre possibile incapsulare anche dati, genericamente intesi, ovvero che non siano dati relativi a flussi audio o video né necessariamente dei metadati che si applicano a tali tipi. Il metodo adottato nella specifica DVB-T a questo scopo è il DSM-CC (Digital Storage Media Command and Control; standard ISO/IEC ); in particolare l implementazione di questo sistema permette di avere nello stream un broadcast filesystem, una struttura dati assimilabile appunto ad un tradizionale file system ed interpretabile in tal modo dal software di sistema del terminale, così come da una applicazione MHP. Dal punto di vista della trasmissione dati, la particolarità di una rete broadcast è evidentemente quella di essere monodirezionale; infatti è il server (in questo caso l emittente televisiva) che decide quali dati, a cui possono accedere tutti i client (in questo caso i terminali mhp), inviare. Nell ambito di riferimento, tutti i file di un filesystem appunto in broadcast vengono trasmessi ciclicamente ed il terminale dovrà attendere quelli di cui necessita in base allo status in cui si trova; la logica è del tutto analoga ad esempio a quella del servizio teletext nella tv analogica. Questo meccanismo prende il nome di carosello o carousel (in inglese) per analogia con il famoso programma televisivo degli anni 60 in cui un certo numero di contenuti veniva riproposto ciclicamente. Nel DSM-CC i dati, per essere trasmessi, vengono organizzati in moduli ai quali viene aggiunta una descrizione che ne indica il contenuto. I moduli vengono poi trasmessi ripetendo ciclicamente la stessa sequenza. Questo standard, il DSM-CC, prevede due tipi di carosello: - il Data Carousel: il server che trasmette i pacchetti dati non dà alcuna indicazione sul contenuto dei medesimi; quindi in questo caso il terminale deve analizzare tutti i pacchetti che riceve e ricostruire il contenuto per recuperare le informazioni di interesse; - l Object Carousel: modello sicuramente più adatto alle situazioni più complesse, si pone come layer aggiuntivo al Data Carousel e fornisce funzionalità analoghe a quelle (basilari) di un tradizionale filesystem; in effeti è questo il tipo di carousel adottato nello standard DVB-T; Il contenuto di un Object Carousel è inteso essere una struttura di directory ad albero; per la trasmissione essa viene divisa in più moduli, ciascuno dei quali, come si era già accennato, include una ulteriore struttura dati che descrive il contenuto; un modulo può contenere più file e/o directory, la dimensione massima di un modulo è di 64 kb con l eccezione di moduli dedicati ad ospitare esclusivamente un singolo file di dimensioni maggiori di 64kB, qualora ve ne fossero (non è ammesso invece dividere file che superino i 64 kb in più moduli). Ovviamente i moduli vengono poi trasmessi ciclicamente, secondo appunto il paradigma a carosello. 11

13 Il terminale, per ottenere uno specifico file, deve quindi attendere di ricevere il modulo che lo contiene (potrà identificare il modulo dai metadati associati) per poi analizzarlo ed estrarre il file di interesse. Questo metodo può essere svantaggioso quando la quantità di dati è elevata ma non è inconsueto che i terminali MHP abbiano capacità di memorizzazione locale persistente, così che si possa effettuare anche una sorta di caching locale in modo da non dover sempre attendere una nuova iterazione del carousel per accedere agli stessi dati. Il meccanismo descritto viene usato per trasmettere i file che compongono le applicazioni MHP (quindi quantomeno uno o più file di bytecode Java) ed eventuali altri file usati come risorsa dall applicazione stessa. Infine, per la natura intrinseca del sistema e del contesto, un broadcast filesystem è ovviamente accessibile in sola lettura. Un semplice esempio di un possibile contenuto di un Object Carousel: a.jpg [ 1256 bytes] b.jpg [ 4040 bytes] c.jpg [ bytes] d [ directory] d/t.txt [ bytes] classes [ directory] classes/c1.class [ bytes] classes/c2.class [ bytes] classes/c3.class [ bytes] sì può configurare un Object Carousel con un modulo1 che contenga a.jpg, b.jpg, la directory d ed il file d/t.txt; il file c.jpg necessiterà di un modulo2 dedicato così come classes/c2.class può andare da solo in un modulo3 ; infine la directory classes ed i restanti due file in un modulo Il Middleware MHP L Uso di un middleware aperto e standardizzato per la tv interattiva implica che i produttori di dispositivi possano puntare a mercati multipli piuttosto che sviluppare prodotti sulle specifiche di una particolare emittente e/o fornitore di servizi; allo stesso tempo applicazioni progettate per essere eseguite nel medesimo ambiente standard possono essere trasmesse in broadcast da diversi fornitori di servizi; il tutto apre la possibilità di un mercato effettivamente orizzontale. 12

14 Nei primi anni in cui erano disponibili servizi di TV digitale, le uniche risposte alla necessità di API per eseguire applicazioni interattive sui STB erano sistemi proprietari, e ciò certo non favoriva lo sviluppo di un mercato orizzontale. Il DVB Project considerò una naturale evoluzione dei suoi successi nell ambito degli standard per quel che riguarda puramente la trasmissione l iniziare a lavorare, nel 1997, su un insieme di specifiche per un ambiente software aperto e standardizzato il cui nucleo fosse basato su tecnologia Java. La prima dimostrazione, comprensiva di trasmissione aerea, di applicazioni MHP e ricevitori implementanti tali specifiche ebbe luogo all esposizione IFA nel 1999 in Germania; la prima versione della specifica MHP venne ratificata dall ETSI nel Luglio del 2000; i primi servizi facenti uso dello standard DVB-T ed MHP vennero resi disponibili in Finlandia nel Ad ora, sono tre le principali versioni (o rami, tenendo presente che per ognuna esistono delle revisioni minori e che di nessuna delle tre è stato già deprecato l uso in quanto obsoleta, anzi in realtà solo implementazioni della prima sono effettivamente diffuse) pubblicate della specifica MHP. Ogni nuova versione è pensata principalmente per introdurre nuove caratteristiche, con un occhio di riguardo al concetto, relativamente alla connettività Internet, che si vada sempre più verso un mondo a banda larga. In ogni versione rimane comunque pienamente supportata una modalità di utilizzo broadcast only e una che non richieda elevate velocità all interfaccia che il terminale implementa (ed alla rete a cui essa si connette) per fornire le già citate funzionalità di return channel. Segue un elenco sintetico delle principali caratteristiche di ogni versione della specifica x: broadcasted applications, dati via tcp/ip, implementabile su dispositivi per ricezione DVB-S/C/T x: aggiunge alla 1.0.x stored applications, download di applicazioni via tcp/ip, supporto a smartcard ed a video e grafica in alta definizione, video ondemand, e, opzionale, browser per l appositamente definito linguaggio di formattazione contenuti DVB-HTML x: aggiunge alla 1.1.x supporto alla IP-TV, secondo una modalità definita internamente e denominata DVB-IPTV ed anche secondo paradigmi di terze parti. La più remota revisione del ramo 1.0, la tuttora pubblicamente disponibile, è datata Giugno 2001, mentre la più recente revisione della versione 1.2 risale ad Aprile

15 Sono anche state definite due estensioni, applicabili a ciascuna delle differenti versioni della specifica: la prima, del 2004, atta a fornire ad un STB funzionalità di PVR (Personal Video Recorder); la seconda, risalente a Febbraio 2008, riguarda l ambito dell accesso condizionale ed ha lo scopo di facilitare servizi di PayTv complessi. Semplificando al massimo, da un punto di vista funzionale MHP definisce cosa il software presente sul teminale (compresivo appunto della parte che implementi il middlware MHP) deve fornire in quanto ad ambiente di esecuzione per applicazioni interattive (cosa che implica di conseguenza alcune necessità a livello hardware, ma al produttore del STB viene lasciata massima libertà nelle scelte specifiche, così come per il sistema operativo ed il come implementare la specifica per quel che riguarda il middleware). MHP definisce anche la forma in cui le applicazioni vengono distribuite (trasmesse) ai terminali, inclusa la modalità di segnalare che applicazioni interattive sono presenti in un transport stream. MHP non è una specifica che si pone in concorrenza con altre ugualmente utili alla distribuzione di contenuti ed all interattività, come ad esempio possono essere quelle di un linguaggio dichiarativo come HTML (specifiche che vanno poi implementate in opportuni motori o engine, software): la linea di principio alla base della specifica MHP suppone (sembrerebbe un po semplicisticamente per la verità) che per esempio un engine HTML possa senza sostanziali problemi essere implementato come una applicazione MHP, e che nel caso emergano nuovi requisiti da soddisfare sia più semplice e conveniente aggiornare e ridistribuire una applicazione MHP che una nativa dipendente da uno specifico hardware e/o sistema operativo. MHP prevede quindi un sistema di distribuzione delle applicazioni che offre agli operatori coinvolti nell anello del flusso informativo relativo alla DTT le potenzialità e la robustezza del modello applicazioni scaricabili (ricevibili tramite trasmissione in broadcast, in questo caso), mantenendo per l utente una esperienza di fruizione agevole, priva di necessità di interventi di gestione/configurazione da parte di quest ultimo. Dal punto di vista dell architettura, usando la metafora degli strati, comune relativamente ai sistemi software, il software che implementa l ambiente di esecuzione MHP, essendo infatti classificato come middleware, è uno strato che opera sopra il sistema operativo specifico di ogni terminale e fornisce servizi ad altri componenti software in esecuzione, a cui ci riferisce comunemente appunto come applicazioni MHP. La specifica MHP prevede inoltre un ulteriore componente software, detto Application Manager, responsabile della attivazione delle applicazioni ricevute nel transport stream e della gestione del ciclo di vita delle stesse. L Application Manager, posto che le sue funzionalità e modalità di intefacciamento con esso sono standardizzate, è previsto sia implementato come sw nativo e non come applicazione MHP esso stesso. 14

16 Dando ora qualche riferimento sintetico ma un minimo concreto, MHP prevede un ambiente di esecuzione il cui nucleo sia costituito da una Java Virtual Machine e da un sottoinsieme delle classi disponibili in un ambiente Java standard versione così come definito dalle relative specifiche di Sun Microsystems. Per la precisione, il nucleo del middleware mhp è un sottoinsieme di Pesonal Java 1.2, ambiente Java a suo tempo definito da Sun per l implementazione nei cosiddetti personal mobile devices (ed ora specifica/prodotto non più supportati, sostituito da altre versioni di ambiente Java con scopi analoghi), ambiente comuque a sua volta basato su quello standard Sono anche state incluse, in numero ridotto rispetto al resto, alcune API non presenti nell ambiente Java standard ma in versioni successive (non superiori alla comunque); ad esempio le classi appertenenti al package java.security.cert (utili alla gestione di certificati di sicurezza), così come definite nelle specifiche Pesonal Java 1.2a; tale package non è incluso nell ambiente java standard 1.1.8, ma è presente a partire dalla versione 1.2. Alcune delle API nell insieme originario costituito dall ambiente Java standard, sono state escluse dalla specifica MHP, o perché ritenute non imprescindibili nel contesto di destinazione e quindi sacrificabili per ridurre i costi in termini di dimensione del middleware, o perché semplicemente ritenute del tutto non necessarie nell ambito specifico. Inoltre, alcune delle classi dell ambiente Java standard sono state modificate nelle direttive per la loro implementazione; le ragioni di queste modifiche sono di due tipi: ottimizzare il consumo di memoria e necessità specifiche di funzionalità troppo differenti da quelle definite in Java standard; da notare che il secondo caso può portare ad una differente semantica tra una data API in MHP e la sua omonima in Java standard, pur con una forma identica. Ad un nucleo così definito, sono stati aggiunti diversi gruppi di API, dovuti a Sun e ad altre organizzazioni terze sia a quet ultima che al DVB project, atti a rispondere alle necessita specifiche di un contesto come quello di un ambiente di esecuzione di applicazioni interattive per la TV digitale: - Java TV 1.0: API precedentemente definite da Sun dirette appunto all ambito della tv digitale, sebbene prive di funzionalità specifiche per l interazione con il modello di organizzazione dell informazione proprio dello standard trasmissivo DVB; tra l altro esse includono la classe XLet che presenta forti analogie con il concetto di applet eseguita in un web browser e che definisce il modello di riferimento per una applicazione MHP; 15

17 - JMF (Java Media Framework) 1.0: una parte di questa API è stata inclusa allo scopo di fornire funzionalità di controllo dei flussi audio/video (ad esempio, mettere in pausa, avviare la riproduzione etc. ); alcuni degli elementi adottati sono stati anche modificati nella loro definizione per introdurre funzionalità più specifiche per l ambito televisivo (ad esempio, gestione sottotitoli, cambiamento fattore di scala/posizionamento del frame, nuovo metodo di riferimento ai contenuti nel formato URL, in modo da poter referenziare servizi e specifici stream nella struttura dati DVB-T); - DAVIC (Digital Audio VIsual Council) API part 9: risponde alle necessità per quanto riguarda l implementazione di alcuni concetti basilari dello standard MPEG, la sintonizzazione, il filtraggio delle sezioni di un flusso MPEG, gestione di alcune risorse specifiche di un terminale per la tv digitale, lettura delle informazioni relative all accesso condizionale ai contenuti; - HAVi (Home Audio Video interoperability) API: fornisce integrazione tra video e grafica, widgets per l interfaccia grafica adatti anche allo schermo di un televisore tradizionale, ed altro relativo a gestire le difficoltà poste da un tradizionale televisore in ambito grafico; è in sostanza l API di riferimento per quel che riguarda la creazione di una interfaccia utente grafica in una applicazione MHP; - DVB MHP API: sotto questo nome vanno tutte quelle API, appositamente definite per la specifica MHP, che forniscono funzionalità, non presenti negli altri gruppi di API adottati, specificamente utili per un terminale televisivo o atte ad accedere alle informazioni in un flusso DVB-T; come ad esempio fornire accesso alle tabelle di informazione definite dalla specifica DVB-T, l uso del return channel, o, in ambito di interfaccia utente, layout di teso adatto ad un televisore, caricamento di font ricevuti in broadcast, composizione con trasparenze tra diversi piani grafici. Il primo passo nell implementare un applicazione MHP consiste, per definizione, nell implementare (da intendere anche nell accezione specifica del linguaggio Java) la già citata interfaccia (nuovamente, termine da intendere nell accezione specifica del linguaggio Java) Xlet, dato che essa ne definisce il modello basilare di riferimento. Di seguito sarà quindi spesso equivalente usare il termine Xlet come sinonimo di applicazione MHP. 16

18 Affinché una applicazione MHP possa essere attivata, sono necessarie alcune condizioni preliminari: - il terminale deve essere a conoscenza della disponibilità di tale applicazione nel flusso DVB-T che viene ricevuto; - deve essere possibile verificare che il terminale risulti conforme al profilo MHP (si tornerà in seguito sui profili di conformità alla specifica MHP) di cui la data applicazione necessita; - l utente deve essere abilitato all esecuzione di tale applicazione nella fascia temporale di interesse; - devono essere disponibili tutti i dati necessari all esecuzione dell applicazione o localmente o nell Object Carousel incapsulato nel MPEG TS (nettamente più comune la seconda opzione). La presenza di una applicazione è segnalata in una tabella supplementare, definita dalla specifica MHP, all interno della precedentemente menzionata struttura dati DVB-SI inclusa in un segnale DVB-T: ogni servizio o canale televisivo che trasporta applicazioni deve avere anche una AIT (Application Information Table), all interno della quale si trovano tutte le informazioni relative alle applicazioni attivabili mentre si è sintonizzati sullo specifico servizio/canale. Le principali informazioni associate ad una applicazione sono un identificatore univoco, composto da un Organization ID di 32 bit (univoco per ogni organizzazione che produca applicazioni MHP) ed un Application ID di 16 bit, i file che l applicazione necessiterà di referenziare ed i class file del bytecode Java che la compongono, ed eventuali parametri di avvio. Quando un terminale si sintonizza su un canale contenente applicazioni, L Application Manager analizza la lista delle applicazioni relative al canale di provenienza per poi disattivarle; quindi vengono caricate le applicazioni segnalate nella nuova AIT; una applicazione per rimanere attiva nel passaggio da un canale all altro, dovrebbe essere segnalata nella nuova AIT come external application. MHP prevede per una applicazione o Xlet che dir si voglia, un ciclo di vita precisamente strutturato che passa attraverso i quattro stati: - loaded - paused - active - destroyed 17

19 Le possibili sequenze di transizione sono indicate nel seguente diagramma: (immagine tratta da ) Nel caso una Xlet generi un errore che ne implichi l interruzione, viene sempre portata nello stato destroyed, transizione alla quale è associato il rilascio delle risorse allocate a tale applicazione. L Interfaccia Xlet definisce dei metodi relativi alle transizioni di stato la cui implementazione nella specifica applicazione provvederà ad eseguire le eventuali azioni necessarie in corrispondenza della transizione associata; inoltre ad una Xlet, tramite il metodo initxlet, nel passaggio allo stato paused, viene fornito un riferimento al relativo oggetto di tipo XletContext, al quale, tramite i metodi appositamente definiti dalla specifica MHP la Xlet può richiedere un cambiamento di stato o notificarne uno avvenuto all Application Manager, nel caso la transizione di stato sia stata invocata ad esempio da un altra Xlet. Infatti un applicazione può raccogliere informazioni sulle altre ed interagire anche relativamente alle transizioni di stato; inoltre tutti gli elementi nella AIT al momento valida sono accessibili a tutte le applicazioni che li richiedano. MHP non è uno standard monolitico che richiede la totale implementazione della specifica al fine della conformità: alcune caratteristiche rimangono in generale opzionali, inoltre, la specifica definisce tre differenti profili di conformità, sostanzialmente in relazione di inclusione tra loro, riguardo alle caratteristiche la cui implementazione è obbligatoria per ciascun profilo (ovvero: il primo profilo si configura come un sottoinsieme delle caratteristiche richieste nel secondo, idem tra il secondo ed il terzo). 18

20 Si hanno, citando gli elementi probabilmente più rilevanti: - Enhanced Broadcast Profile: non impone l implemnetazione della caratteristica che va sotto il nome di return channel (sostanzialmente disponibilità di funzionalità di connessione remota), include quanto serve per l interattività locale tramite le applicazioni trasmesse in broadcast; impone anche qualche restrizione sui parametri delle immagini JPEG che possono essere usate; - Interactive Broadcast Profile: aggiunge l imposizione di una qualche forma di return channel (l hardware per la connessione ed il protocollo a livello fisico vengono lasciati alla scelta dell implementatore) e della disponibilità su questa connessione dei protocolli tcp/ip e dns; http 1.0/1.1 sono opzionali, sebbene è molto comune che un teminale MHP fornisca quantomeno anche l implementazione del protocollo http 1.0; - Internet Access Profile: profilo definito solo a partire dalla versione 1.1 della specifica, aggiunge supporto obbligatorio ad http 1.1 e prevede come opzionale un client in grado di interpretare contenuti DVB-HTML, un linguaggio di makup definito ad hoc a partire da varie specifiche del W3C. L obbligatorietà o meno di alcune caratteristiche affinché un terminale sia conforme ad un dato profilo, possono variare a seconda che ci si riferisca alla versione 1.0.x o ad una successiva della specifica MHP. La seguente tabella riporta la situazione di varie caratteristiche relativamente a ciascun profilo, in base alla specifica 1.0.x ed 1.1.x: 19

21 (tabella tratta da 20

22 La AIT contiene per ogni Xlet una struttura dati denominata Application Descriptor che contiene l informazione riguardo a di quale profilo (e quale versione) l applicazione necessita per poter essere eseguita; quando il terminale riceve una nuova AIT, come parte del processo di analaisi di questa, controllerà gli identificativi di profilo ed i numeri di versione associati ad ogni applicazione; ciò permette di determinare a priori quali applicazioni sono eseguibili e di non tentare eventualmente l esecuzione di applicazioni che necessitino di risorse non implementate. Inoltre, una applicazione in esecuzione può determinare a quale profilo e versione è conforme il terminale, così come quali caratteristiche opzionali sono eventualmente supportate.; questo avviene attraverso apposite classi dell API MHP che riflettono, tramite i dati/oggetti contenuti, alcune proprietà dello specifico sistema (In modo analogo per esempio alla classe System in un ambiente java standard); ciò può tornare utile nel caso una applicazione voglia verificare, un volta attiva, se può eventualmente fare qualcosa che vada oltre le possibilità garantite dal profilo a cui è stata associata in sede di generazione della AIT. 21

23 3 - MHP, Alcune API e Funzionalità di Specifico Interesse Si prenderanno in esame qui di seguito alcune caratteristiche funzionali definite dalla specifica ed alcune interfacce di programmazione tra quelle che compongono l API MHP, particolarmente, per certo o potenzialmente, utili nell ottica di determinare quanto necessario, per quel che riguarda il fronte di sviluppo di applicazioni MHP, in relazione agli obiettivi inizialmente indicati; ovvero, principalmente: - acquisire dati, o accedere ai medesimi altrimenti acquisiti, nel terminale MHP da un dispositivo esterno locale tramite connessione conforme allo standard EIA (Electronic Industries Alliance) RS-232 con connettore DE-9 (la comune porta seriale ); - inviare tali dati ad un sistema remoto, usando le API per la gestione del return channel e quelle per le funzionalità di rete comuni ad un ambiente di esecuzione Java standard org.dvb.test.dvbtest Si prende in esame questa classe semplicemente in quanto la definizione della medesima è l unica parte della specifica MHP in cui si menziona la connessione RS-232. La classe DVBTest è pensata per permettere ad applicazioni di test di registrare, su un sistema esterno al terminale MHP, messaggi di debug durante l esecuzione o messaggi relativi allo stato di terminazione. Relativamente alla definizione delle azioni corrispondenti ai metodi (metodi pubblici si sottintende sempre) definiti in questa classe che implementino tali funzionalità, si lascia a alla particolare implementazione del middleware MHP la scelta di quale connessione fisica si debba utilizzare per le citate operazioni di logging. Una tra le varie opzioni suggerite, è appunto la connessione RS-232. L unico di questi metodi (i quali tutti tra l altro restituiscono il tipo void) la cui semantica sia connessa ad un flusso dati in ingresso nel terminale MHP tramite porta seriale (se tale dovesse essere la scelta della connessione in una qualche specifica implementazione) è prompt(java.lang.string id, int controlcode, java.lang.string message) 22

24 questo metodo è inteso essere usato per sincronizzare un client MHP di test con un test-server; il metodo deve essere bloccante finché il client non riceve da parte del server un acknowledgment negativo o positivo per lo specifico messaggio inviato. E nelle linee guida per l implementazione, tra le opzioni suggerite per la connessione attraverso cui rivevere l acknowledgment, figura RS java.lang.runtime Ogni applicazione può disporre di un oggetto della classe java.lang.runtime che permette di interagire con l ambiente in cui l applicazione stessa è in esecuzione. Una istanza di Runtime si ottiene attraverso l apposito metodo statico (non è contemplato che una xlet crei una sua nuova istanza di questa classe, quindi la definizione di Runtime non prevede costruttori): public static Runtime getruntime() Questa classe oltre a permettere di ottenere informazioni sull ambiente di esecuzione Java/MHP e sulle risorse di sistema, permette anche di caricare ed eseguire codice binario nativo per lo specifico s.o. su cui è in esecuzione il middleware java/mhp, con i metodi public void load(string filename) public void loadlibrary(string libname) ed i metodi exec distinti tramite differente definizione degli argomenti. Questi ultimi in particolare permettono non solo di avviare un file eseguibile nativo in un processo separato, ma anche di eseguire comandi implementati dallo specifico sistema operativo su cui è in esecuzione l ambiente java/mhp: public Process exec(string command) throws IOException esegue in un processo separato il comando di sistema (o file eseguibile, referenziato tramite path completo) rappresentato dalla stringa command; restituisce un oggetto di tipo Process, rappresentativo del nuovo processo generato e che permette la gestione del medesimo; public Process exec(string command, String[] envp) 23

25 throws IOException esegue in un processo separato il comando di sistema (o file eseguibile, referenziato tramite path completo) rappresentato dalla stringa command, settando le variabili di ambiente rappresentate dalle stringhe nell array envp (secondo la sintassi, per ogni stringa, nome=valore ); se envp è null, il nuovo processo eredita la configurazione delle variabili di ambiente del processo padre; restituisce un oggetto di tipo Process, rappresentativo del nuovo processo generato e che permette la gestione del medesimo; public Process exec(string[] cmdarray) throws IOException public Process exec(string[] cmdarray, String[] envp) throws IOException metodi con semantica identica ai due precedentemente descritti, eccetto per il fatto che il comando da eseguire comprensivo di eventuali argomenti viene passato come array di stringhe anziché come stringa unica. Nell ottica degli obiettivi inerenti il presente elaborato, la classe Runtime può risultare di particolare interesse nella misura in cui i metodi appena descritti permettano di eseguire comandi propri del sistema operativo del STB MHP che avviino un processo di acquisizione dati dalla connessione RS-232, eventualmente memorizzando poi tali dati in una memoria non volatile del STB, nel caso non vi sia una modalità più diretta per renderli disponibili alla applicazione MHP. La classe Runtime è definita nelle specifiche per un ambiente Java standard ed adottata nella specifica MHP senza particolari direttive esplicite riguardo alla sua implementazione, ad eccezione del fatto che è contemplata la possibilità che i metodi descritti nel presente paragrafo inoltrino una eccezione di tipo SecurityException a seconda delle scelte implementative relative alle politiche di sicurezza scelte per lo specifico STB Broadcast Filesystem Nell ambiente di esecuzione MHP, spesso l unico file system a cui una applicazione accede è quello di tipo comunemente detto broadcast, riferendosi alla struttura dati implementata e trasmessa nel TS secondo il paradigma del DSM-CC Object Carousel, ed a cui il middleware MHP fornisce accesso fornendone alle applicazioni, tramite le apposite API, una astrazione come filesystem gerarchico; filesystem al quale, per ovvie ragioni inerenti l unidirezionalità di un flusso dati in broadcast, lato applicazioni MHP, si ha accesso in sola lettura. 24

26 E previsto di poter utilizzare alcune delle classi del package Java standard java.io al fine di compiere determinate operazioni relative ad un file presente in un Object Carousel, tramite l opportuno oggetto che lo rappresenti in una applicazione; tuttavia la natura particolare del file system in broadcast ha un certo impatto sul modo in cui l implementazione delle classi di java.io funzionano in tali circostanze. La differenza più ovvia, oltre a quella di avere un file system read-only, riguarda la latenza: avendo a che fare con un DSM-CC Object Carousel, il STB deve attendere che il modulo contenente la risorsa, a cui l applicazione ha richiesto accesso, venga ricevuto prima che il file possa essere effettivamente disponibile alla xlet, e ciò può implicare anche tempi di attesa dell ordine di alcuni secondi. Dal punto di vista dello sviluppo di una applicazione MHP e del prepararne la trasmissione, il problema, specie se seguente l interazione dell utente con la xlet, della possibile latenza elevata può essere mitigato sostanzialmente in due modi: - configurare l object carousel in modo che i file richiesti più spesso dalla applicazione siano trasmessi sufficientemente di frequente tanto da ridurre la latenza a livelli che si ritengono accettabili; è opportuno inoltre inserire tali file se possibile nel medesimo modulo del carousel, in quanto questo facilita il caching locale, se operato dal STB; - scrivere il codice dell applicazione in modo che il file nell object carousel a cui si vuole accedere sia richiesto, quando la specifica esigenza è sufficientemente predicibile, con un opportuno anticipo sul momento in cui esso sarà effettivamente necessario tanto da mantenere i tempi di attesa accettabili. Le API relative al DSM-CC Object Carousel definite in MHP aggiungono a quelle Java standard per gestione ed accesso ai file il supporto a caratteristiche proprie di un filesystem basato su un object carousel, estranee ad un filesystem convenzionale, come il caricamento asincrono (ad esempio poter leggere il contenuto di un file senza che l operazione di input sia bloccante fino alla sua terminazione). Tali API forniscono inoltre accesso a quelle parti di un carousel non relative alla trasmissione di file/directory: infatti, come anche dal nome stesso, un DSM-CC Object Carousel è definito in modo tale da trasmettere, in generale, oggetti, non solo file, e quindi poter incorporare altri tipi di data stream oltre a quelli utili a rappresentare un filesystem. Una seconda rilevante differenza tra un filesystem come vista a livello applicazione di un DSM-CC Object Carousel, rispetto ad un file system convenzionale, riguarda il l importanza del caching. 25