Informe Preliminar: Estado del Arte de Receptores Set-Top-Box Aplicaciones

Transcripción

1 Informe Preliminar: Estado del Arte de Receptores Set-Top-Box Aplicaciones ÁREA DE APLICACIONES TELEMÁTICAS INVESTIGADORES JUAN MAURICIO VILLANUEVA CHRISTIAN VELASQUEZ DIAZ INICTEL-UNI Lima, Febrero de

2 Contenido CAPITULO I ARQUITECTURA DE HARDWARE Y SOFTWARE DEL SET TOP BOX Introducción Set-Top-Box Arquitectura de Set-Top-Box Software del Set-Top-Box Conclusiones... 8 CAPITULO II ESTUDIO DE LOS APLICATIVOS EXISTENTES PARA SET-TOP- BOX Aplicativos Existentes para Set-Top-Box Estúdio de Caso 1: Guia de TV personalizada Estudio de Caso 2: Monitoreamiento y Control usando GINGA Estudio de Caso 3: Voto Electrónico T-Voto CAPITULO III SISTEMA OPERATIVO Y NIVELES DE PROGRAMACION PARA SET-TOP-BOX Middleware MHP Multimedia Home Platform DASE DTV Application Software Environment ARIB Association of Radio Industries and Businesses Middleware Ginga Ginga-NCL Ginga-J API JavaTV API DAVIC API HAVi API DVB Ambientes de Emulación para la Programación de GINGA Emulador GINGA-J: XLetView Emulador GINGA-NCL: Set-Top-Box Virtual CAPITULO IV APLICACIONES ITERATIVAS - DEFINCIONES Introducción Componentes de la TV Interactiva Aplicaciones de Interactividad CAPITULO V STB COMERCIALES - ESPECIFICACIONES Introducción Receptores de TV digital Set-Top-Box en el Brasil Marca PROVIEW XPS Marca PROVIEW XPS1000i Interactivo Marca INVIX Marca MIXLASER REFERENCIAS ANEXO A APLICACIÓN XLETVIEW A.1 Código de Programa Aplicación XletView ANEXO B APLICACIÓN VIRTUAL SET-TOP-BOX B.1 Archivo: main.ncl B.2. Archivo: hackerteen.lua

3 CAPITULO I ARQUITECTURA DE HARDWARE Y SOFTWARE DEL SET TOP BOX 1.1. Introducción En la práctica, el sistema de televisión digital se resume a una conversión de la señal de TV analógica para un formato digital que puede ser emitido por satélite, terrestre o cable, sio posteriormente decodificado por el propio televisor (televisión digital) o a través de un receptor llamado set-top-box [1]. Así también, la Televisión Digital Interactiva es un desafío para los desarrolladores que investigan las potencialidades de los programas interactivos. Una gran diferencia es la posibilidad de comunicación con los telespectadores vía un canal de retorno. Actualmente, la televisión abierta utiliza los artificios de otros medios de comunicación (teléfono, Internet, fax, mensajes, SMS) con la finalidad de que el telespectador participe indirectamente de la programación. Con la televisión digital interactiva se puede concretizar un dialogo del espectador con el programa a través del canal de retorno o del acceso de datos recibido y almacenados en el set-top-box [1]. El set-top-box tiene un papel fundamental en la implementación de nuevas funcionalidades de la Televisión Digital Interactiva. Este nuevo componente del sistema es responsable por mantener la compatibilidad con un parque instalado de televisores, adicionando nuevas funcionalidades: desde la transmisión de video de alta calidad hasta un nivel elevado de interactividad. Asociado al hardware del Set-Top-Box, se tiene el Middleware Ginga, una recomación ITU-T H.761, desarrollado para ser el modelo del Middleware para Televisión Digital del Brasil y que hoy en día es parte del estándar adoptado por el Perú. La conjunción entre el Set-Top-Box y el GINGA, permiten desarrollar componentes y aplicaciones para TV digital, adicionando servicios a los usuarios, con nuevas funcionalidades, muchas de estas ya disponibles comercialmente por las redes de TV a cable o satelitales, tales como [1]: Guías de Programación Electrónica (Conocido como EPG), y mensajes de texto Juegos interactivos on-line Video sobre demanda 3

4 Sistema de pay-per-view. En este panorama, en esta sección se estudiara las arquitectura convencional del hardware y software, y como estas interactúan durante la ejecución de aplicaciones interactivas Set-Top-Box El set-top-box es un dispositivo externo, el cual viabiliza que un televisor convencional (Televisión analógica) pueda reproducir programas de televisión emitidos con tecnología digital. Los componentes físicos que constituyen un set-topbox son [1]: Placa del sistema Sintonizador Modulador/ demodulador Demultiplexador Decodificador Procesador gráfico CPU (Central Processing unit) Memoria Disco Interfaces físicas Así también, se pueden clasificar los Set-Top-Box en tres categorías [1]: Broadcast TV, Enhanced TV y Advanced Services. Estas clasificaciones serán descritas a seguir: a) Broadcast TV: Los set-top-box para difusión de TV (broadcast TV) son utilizados para los servicios tradicionales de TV, adicionado de un sistema pay-per-view e instrumentos básicos de navegación. Sin embargo, permiten la recepción de datos en formato digital. También disponen de una cantidad limitada de memoria, limitado número de puertos de interface y una capacidad de procesamiento limitada. Sin embargo, han sido proyectadas de forma a soportar algunos sistemas avanzados, tales como el servicio de mensajes y video-on-demand. b) Enhanced TV: La diferencia de los set-top-box de la categoría Enhanced TV consiste en incluir un canal de retorno. Los Enhanced set-top-box soportan comercio electrónico, video sobre demanda, y un navegador para 4

5 conexión a Internet. La presencia del canal de retorno posibilita comunicaciones por y por chat. Estos set-top-box tienen una capacidad de procesamiento y una capacidad de memoria mayor en relación a los set-top-box Broadcast TV. c) Advanced Services: Los set-top-box de servicios avanzados presentan una velocidad de procesamiento cerca de 10 veces superior a los set-top-box Broadcast TV. Las capacidades mejoradas de este tipo de set-top-box en conjunto con el canal de retorno de elevada velocidad, permiten que este tipo de set-top-box tenga acceso a una variedad de servicios de Internet e interactividad. Generalmente, este tipo de set-top-box viene asociado a un disco duro incorporado Arquitectura de Set-Top-Box Los set-top-box son sistemas embarcados proyectados para un propósito específico: recepción de señales de TV digital, recuperación del video y exhibición en una TV. La Figura 1.1 se ilustra la arquitectura en camadas de un set-top-box genérico. Figura 1.1. Arquitectura general de un Set-Top-Box. Na camada superior, se tienen los servicios y contenidos que pueden ser producidos en una transmisión de TV digital. Ejemplos de estos servicios son las guías de programación electrónica (EPG), sistema pay-per-view, juegos on-line, programas interactivos, etc. La segunda camada, se tienen las aplicaciones. Estas aplicaciones son responsables por promover el tipo de servicio de la camada superior. En la tercera camada, el Middleware, que básicamente tiene como función realizar una interface entre el hardware del set-top-box y las aplicaciones. De esta forma, las aplicaciones pueden ejecutarse de forma transparente sin la preocupación 5

6 con la forma de acceso al hardware de un set-top-box específico [1]. De esta forma el desarrollo y portabilidad de las aplicaciones se torna más simple, debido a que todas las aplicaciones usan una misma API en común. En la cuarta camada, se tienen los componentes multimedia de decodificación y codificación, así como los otros módulos multimedia. En la quinta camada, el sistema operacional, es responsable por el funcionamiento del hardware, proveyo una camada de abstracción al hardware del set-top-box. En la última camada tenemos el hardware de un set-top-box, que es constituido por una CPU, dispositivos de entrada y salida, almacenamiento, decodificación, sintonización, etc. En la Figura 1.2, se ilustra la arquitectura del hardware de un set-top-box convencional [1], el cual puede ser dividido en tres etapas: Etapa Inicial (Front End): interfaces de sintonización de las señales. En esta primera etapa se realiza la recepción de una señal provenientes de de tres posibles medios de transmisión: terrestre, clave o satélite. El sintonizador (tuner) selecciona la frecuencia de recepción y modula en banda base la señal de entrada. La señal es muestreada para crear la representación digital del mismo que es realizada por el conversor analógico/digital. Las próximas etapas son la demodulación y la corrección de error de la señal, que luego enseguida es encaminado a la etapa intermediaria. Etapa intermedia: interfaces de transporte de control de sistemas. En la etapa intermediaria se tiene la demultiplexación del flujo MPEG-2, que separa audio, video y datos contenidos en el flujo de transporte. La selección de los paquetes de audio, video o datos es realizado de acuerdo con las acciones del usuario, que son llevadas a la CPU por las interfaces de entrada y salida. Etapa final: decodificadores de audio y video y la etapa de salida de las señales para la TV. En la etapa final es realizada la decodificación del flujo MPEG-2 que fue seleccionada en la etapa intermedia. Este flujo es convertido nuevamente 6

7 para una señal analógica, modulada en banda base y enviada para exhibición en un equipo de TV convencional. Figura 1.2. Arquitectura del hardware de un set-top-box convencional. Desde un punto de vista de hardware, los componentes de la arquitectura del Set-Top-Box que diferencian los diferentes estándares de Televisión Digital (ISDB-T, DBV, ATSC, etc), son los circuitos integrados demodulador y decodificador de video Software del Set-Top-Box Para la arquitectura del hardware descrito en la Figura 1.2, existen herramientas de software divididas en varias camadas, como se ilustra en la Figura 1.3. Estas herramientas de software hacen uso de las funcionalidades del hardware, para interactuar con el telespectador y entregarlo al contenido televisivo interactivo. Figura 1.3. Arquitectura del hardware de un set-top-box convencional. La camada inferior del software es formada por un conjunto de controladores de dispositivos necesarios para que un sistema operativo de tiempo real ejecutado en 7

8 la camada adyacente pueda controlar el hardware. A diferencia de los sistemas operativos de computadoras personales, el sistema operativo del set-top-box dispone de recursos más escasos que un micro-computador, como una memoria menor y procesadores con menor velocidad. En la camada del sistema operativo, se encuentra el Middleware, que es la camada responsable por proporcionar una interface de programación de aplicación (API Application Programming Interface) a los desarrolladores de aplicaciones. Esta interface es indepiente del hardware y de las tecnologías de comunicación, facilitando el desarrollo de aplicaciones de software. Entre los estándares de middleware, están el estándar Europeo MHP (Multimedia Home Plataform) de la DVB (Digital Video Broadcasting), el americano DASE (DTV Application Software Environment) de la ATSC (Advanced Television Systems Committee), el estándar ARIB de la ISDB-T de Japón, y el GINGA del estándar brasileño ISDB-Tb. Finalmente, la camada de aplicación, donde residen los aplicativos producidos que permiten realizar la interactividad con los diversos servicios, entregando así al telespectador el contenido digital en la televisión Conclusiones Los Set-Top-Box permiten la decodificación de señales obtenidas a partir de televisión digital terrestre, cable o satelital, para reproducirlo en una televisión analógica. Los Set-Top-Box se encuentran asociados a un software denomina de Middleware, que permite ejecutar aplicaciones interactivas en el set-top-box. Para el caso particular del estándar brasileiro ISDB-Tb es el Middleware Ginga y para el estándar Japonés ISDB-T es el Middleware BML. Para los diferentes estándares de televisión digital en el mundo (ISDB-T, DBV, ATSC, etc), las arquitecturas de hardware de los set-top-boxes se diferencian principalmente por el tipo de demodulador y el decodificador MPEG-2/MPEG-4. 8

9 CAPITULO II ESTUDIO DE LOS APLICATIVOS EXISTENTES PARA SET-TOP-BOX 2.1. Aplicativos Existentes para Set-Top-Box En esta sección se estudiaran algunas de las principales aplicaciones en Televisión Digital, tales como: Guía de TV personalizada Monitoreamio y Control: Aplicaciones en Domótica. Voto electrónico T-Voto Estúdio de Caso 1: Guia de TV personalizada El cambio del sistema analógico al sistema digital ha traído consigo dos consecuencias principales: el aumento en la transmisión de nuevos canales con el mismo ancho de banda y la posibilidad de enviar aplicaciones multiplexadas con contenido audiovisual. Ya que nuevos canales emergen debido al aumento de la transmisión, es necesario crear nuevos mecanismos que permitan que los televidentes puedan interactuar con ellos. La guía electrónica de programación (EPG) son de gran ayuda al espectador de TV, sin embargo como nuevos canales están disponibles, una sobrecarga de información es inevitable, por lo cual el EPG es inapropiado. Las EPG tradicionales se convirtieron poco atractivas, debido a que toma demasiado tiempo para que los espectadores busquen entre cientos de opciones su programa favorito, ante esta situación, los sistemas de recomación personalizados son necesarios. Diferente de las funciones de EPG que permiten la búsqueda básica, un sistema de TV personalizado puede crear un perfil para cada espectador de TV y recomar programas que mejor se adapten a este perfil, evitando la búsqueda en muchas opciones EPG para encontrar el programa favorito. El perfil del espectador de TV, puede ser interpretado de un modo explicito donde el sistema recibe la información sobre sus preferencias o puede ser interpretado de un modo implícito donde el sistema puede deducir las preferencias de los espectadores de TV al analizar sus antecedentes de comportamiento [2]. Con la finalidad de aprovechar las funcionalidades ofrecidas por el sistema digital (nuevos canales, aplicaciones interactivas), los espectadores de TV con sistema analógico necesitan de un nuevo equipo llamado SET TOP BOX, el cual es un 9

10 dispositivo que trabaja conectado a la TV y convierte la señal digital recibida del proveedor a audio/video que la TV analógico debe presentar. El SET TOP BOX, necesariamente necesita de una capa de software que permita conectar el hardware a las aplicaciones interactivas llamada Middleware. El middleware del sistema brasileño de DTV es GINGA [2]. En este trabajo se ha desarrollado una extensión al middleware Ginga-NCL a través de la aplicación de un nuevo módulo incorporado al núcleo común Ginga llamado Recommer. El módulo Recommer es responsable de recopilar, almacenar, procesar y recomar los programas de televisión a los espectadores de la televisión. Para desarrollar el módulo Recommer, se utilizó el middleware Ginga- NCL desarrollado por la PUC-Rio (Pontificia Católica Universidad de Río de Janeiro, Brasil), implementado en C / C + +. El código fuente está disponible bajo la licencia GPLv2 y de acuerdo con los patrones definidos por el sistema brasileño de televisión digital. En este sistema de recomación las solicitudes de procedimiento son desarrollados usando le lenguaje Java y las aplicaciones declarativas en NCL [2]. La Figura 2.1 se ilustra la representación del middleware Ginga, que consta de tres etapas capas: Resident Applications: Responsable de la exposición (frecuentemente llamado capa de presentación). Ginga Common Core: Conjunto de módulos responsables del procesamiento de datos, filtrado de información en el flujo de transporte, estabilidad de datos. Stack Protocol Layer: Responsable de apoyar la comunicación de protocolos tales como: HTTP, RTP y TS. Figura 2.1. Arquitectura del Middleware Ginga-RECOMMENDER. 10

11 En la Figura 2.2, se ilustra la arquitectura del módulo RECOMMENDER, el cual se encuentra dividido en dos parte: La primera parte describe los componentes integrados al código fuente del middleware tales como el Agent Local, el Agent Schedule, el Agent Filter y el Agent Data. La segunda parte describe los componentes añadidos al Set Top Box: Sqlite, una libreria C que implementa la conexión de una base de datos SQL y Weka (Waikato Environment for Knowledge Analysis), el código fuente que provee un conjunto de algoritmos para aprer sobre la máquina y el data mining [2]. Figura 2.2. Arquitectura del modulo Recommer Estudio de Caso 2: Monitoreamiento y Control usando GINGA El proyecto DIGA (Automatización digital en monitoreo y control usando tecnología Ginga), es un sistema innovador en la domótica y la automatización del hogar. Domótica se puede definir como la integración de la tecnología en el diseño inteligente de un recinto. Esto es, un conjunto de sistemas capaces de automatizar una vivia, aportando servicios de gestión energética, seguridad, bienestar y comunicación, y que pueden estar integrados por medio de redes interiores y exteriores de comunicación, cableadas o inalámbricas, y cuyo control goza de cierta ubicuidad, desde dentro y fuera del hogar [3]. Se propone agregar funcionalidades al Middleware Ginga, como las aplicaciones en el seguimiento y control en la automatización del hogar, optimizando de esta manera el uso del Set top Box. Con este fin DIGA hace uso de los dispositivos 11

12 (sensores, tecnología RFID, etc.) que accesan al Set Top Box de la TV digital a través de la red inalámbrica (IEEE x) dentro del hogar. Estos servicios agregados a los set top box (software y contenidos) también podran ser accedidos externamente a través de Internet o la tecnología celular (EDGE, GSM, GPRS, etc). Por tanto la idea central del proyecto es compartir la estructura computacional del set top box, agregando servicios para el cuidado de su hogar, tal como el monitoreo del ambiente físico (seguridad del hogar y de empresas), monitoreo personal (signos vitales de salud), automatización residencial y aplicaciones que estimulan la producción de contenidos entre usuarios, como por ejemplos, aplicaciones P2P entre comunidades con intereses comunes en los ámbitos del proyecto. Dadas sus limitaciones parte de los servicios agregados serian ejecutados en el propio Set Top Box, en cuanto a las tareas que exijan mayor poder y/o solicitudes de mayor espacio de memoria, como aplicaciones de salud, serán ejecutadas en una base de datos centralizada, especificadas para algunas funcionalidades del DIGA. (para especificar las características de DIGA.) Por tanto el Set Top Box también funcionaria como una especie de Gateway entre los dispositivos de monitoreo y contrólenla Base de datos DIGABEM (DIGital Automation Monitoring Based in Embedded Model) que integra el proyecto. Aunque son compatibles con cualquier modelo de set-top-box (Zapper, por ejemplo), el DIGA está orientado para el GINGA, el middleware de televisión digital de Brasil, resultado de la investigación llevada a cabo por el SBTVD (Estándar Brasileño de Televisión Digital), establecido por el Decreto 4901 de noviembre 26 de El desarrollo de este proyecto tiene como objetivo la implementación de cuatro componentes: a) DIGA SALUD: Software que integra dispositivos de monitoreo de señales vitales de salud personal (SVSP), tales como el oximetría de pulso, tensiómetro, medidor de glucosa, etc. Como se ilustra en Figura 2.3, el DIGA SALUD, puede ser colocado, si el caso, junto al cuerpo del paciente para que este pueda moverse con normalidad. La información de estas señales puede ser proporcionada por el usuario a cualquier institución o profesional de salud. 12

13 Figura 2.3.Contexto de acción de DIGA SAUDE. b) DIGA CASA: Integra dispositivos de monitoreo físico, tales como: sensores de temperatura, sensores de presencia, sensores para detectar la apertura de puertas y ventanas, etc. Su primera función es monitorear el ambiente y enviar las señales de los sensores y las cámaras al Set Top Box, parte de estas señales serán procesadas localmente, generando o no procedimientos inmediatos (envio de SMS urgentes, s, etc.). Figura 2.4. Contexto de acción de DIGA CASA c) DIGA MUNDO: El propósito de este componente es expandir el concepto de DIGA SAUDE, agregando una estructura de control basada en software que permita al usuario ser también monitoreado permanentemente, por una central de atimiento (DIGA - CA). DIGA MUNDO podrá anticiparse a algunas situaciones de riesgo al cruzar datos on-line (DIGA SAUDE) con datos offline (consultas y exámenes) y alertar al usuario para los procedimientos preventivos en situaciones de riesgos. 13

14 d) DIGAM AQUI: Software de interacción (Applying Quality to Universal Interfaces), el cual es un conjunto de APIs (Application Programming Interfaces), que permiten al usuario de DIGA MUNDO, crear y accesar comunidades de intereses comunes, por ejemplo, una comunidad de personas diabéticas. Para el control de seguridad del hogar y de los signos vitales de salud personal, en este trabajo, se implementaron los siguientes prototipos: DIGA Security Center e o DIGA Doctor, como se ilustra en la Figura 2.5, tenio como centro un monitor de pantalla ancha y un set-top box. Figura 2.5. Prototipos implementados de DIGA Descripción de DIGA Security Center Las Figuras 2.6 y 2.7 ilustran un ambiente residencial sio monitoreada por DIGA Security Center, el cual se encuentra alojado en el set-top-box. El medio ambiente contiene sensores y cámaras distribuidas por toda la casa, y el estado de los sensores y las imágenes generadas por cada cámara puede ser visto desde cualquier TV integrada al sistema, vía web. 14

15 Figura 2.6. Control residencial realizado por DIGA Security Center. Con la ayuda del control remoto el usuario de DIGA, pueda escoger con que cámara deseara recibir las imágenes (garaje, puerta principal, habitaciones, jardines, etc.), lo que permite una mayor seguridad en la vivia. Además de las cámaras de control, DIGA realiza un control de electrodomésticos, puertas de accesos u otros productos electrónicos. Una vez que el set-top box si está conectado a la Internet, es posible supervisar en tiempo real, desde cualquier habitación de la persona que se encuentre en el hogar y el manejo de sensores y alarmas a través de la web. Por ejemplo, las cámaras distribuidas por la residencia para vigilar a los niños que requieren una vigilancia intensiva. Figura 2.7. Escenario de control residencial. Descripción de DIGA Doctor La Figura 2.8 ilustra un escenario típico de aplicación DIGA Doctor. Esto surge como premisa de proporcionar un control y apoyo a las personas que se encuentran en mal estado de salud o con enfermedades que requieren de supervisión médica intensiva. 15

16 Imaginemos a una mujer de edad avanzada, recibio a través de un terminal móvil de TV, un asesoramiento profesional de cómo medir la presión arterial. Figura 2.8. Ejemplo de escenario de una aplicación DIGA doctor. En el caso de la cirugía, la necesidad postoperatoria atención con respecto a la recuperación y el control de determinadas variables para la evaluación de su estado (físico o psicológico). En la actualidad, las personas en estas situaciones, generalmente ingresan a los centros de salud (con altos costos) [4] Estudio de Caso 3: Voto Electrónico T-Voto La T-Voto es una aplicación que provee al espectador interactividad con el programa que está sio transmitido. Durante la exhibición de un programa de televisión se le pide al espectador que revele su opinión a través de una votación como se ilustra en la Figura 2.9. De forma similar a los programas de Reality Shows, en la cual se tiene la posibilidad de realizar una votación para eliminar o apoyar a un participante del programa, o una encuesta que se realiza durante la presentación de un programa [5]. El espectador manifestara su opinión directamente con el control remoto, donde informara cual es su opción y enviará su voto por el emisor de la TV. 16

17 Figura 2.9. Aplicación T-Voto. Una estación de televisión (Servidor de Generación de Contenido) transmitirá (vía satelital, terrestre o portable) la señal de vídeo, para los receptores de televisión digital interactiva, que durante el tiempo de duración del programa, se ejecutara la aplicación interactiva en la cual el espectador podrá votar, y por medio de un canal de retorno (p.e. conexión a Internet) será capaz de registrar su voto en el. 17

18 CAPITULO III SISTEMA OPERATIVO Y NIVELES DE PROGRAMACION PARA SET- TOP-BOX 3.1. Middleware Para evitar la proliferación de estándares para middleware, los principales sistemas existentes para la televisión digital terrestre - americano, europeo y japonés - han adoptado un middleware estándar en sus receptores digitales. Estos son Middleware diferentes, aunque con características específicas, los cuales siguen las recomaciones de la norma GEM (UIT-T J.201) (UIT-T, 2001) MHP Multimedia Home Platform MHP, es el middleware desarrollado, para el estándar DVB, adoptado por Europa [ETSI TS 102 B ]. MHP tiene por objeto proporcionar un entorno para la televisión interactiva, indepiente de hardware y software específicos, abiertos e interoperables para los receptores y decodificadores para TV digital. Su entorno de ejecución se basa en el uso de una máquina virtual de Java y un conjunto de interfaces de programación (API). Estas API permiten a los programas escritos en Java el acceso a los recursos y las instalaciones del receptor digital de una manera estandarizada. Una aplicación DVB usando API de Java se llama aplicación DVB-J [6]. Además del uso del API Java, el MHP introduce la posibilidad de usar un lenguaje de programación semejante a HTML (utilizada en internet para la programación de páginas Web), denominada DVB-HTML. En la Figura 3.1, muestra la arquitectura del estándar europeo DVB Figura 3.1. Estándar de televisión digital DVB MHP. 18

19 DASE DTV Application Software Environment La DASE fue desarrollado por el ATSC como estándar de los EE.UU. para la capa de middleware de set top boxes de TV digital [DASE de 2003]. Al igual que en el MHP, la DASE adopta una máquina virtual de Java como un mecanismo que facilita la ejecución de aplicaciones que permite la interactividad. También de forma similar a MHP, la DASE permite el uso de lenguajes declarativos, usadas en web como HTML y JavaScript. El middleware MHP y DASE no fueron diseñados para ser compatibles entre sí. Esto significa que un servicio desarrollado en una de estas estándares no funcionará con otro. La figura 2 muestra la arquitectura de capas de la estándar ATSC [6]. Figura 3.2. Estándar de televisión digita ATSC -DASE ARIB Association of Radio Industries and Businesses El middleware de ISDB (Integrated Services Digital Broadcasting) está estandarizado por la organización japonesa ARIB. Este middleware está compuesto por algunas normas, como ARIB STD-B24 (Data Coding and Transmission Specification for Digital Broadcasting) que define un lenguaje declarativo llamado BML (Broadcast Markup Language) [ARIB B-24, 2004]. Este lenguaje, basado en el lenguaje estándar de servicios Web XML (Extensible Markup Language), es utilizado para la especificación de los servicios multimedia para TV digital [6]. Otra especificación del middleware es la ARIB STD-B23 (Application Execution Engine Platform for Digital Broadcasting), que se basa en la especificación DVB-MHP. Este último estándar refleja una tencia de ARIB intentar establecer una base común entre los estándares de middleware MHP y DASE. La Figura 3.3 ilustra la estándar japonés ISDB-T [6]. 19

20 Figura 3.3.Estándar de televisión digital ISDB -ARIB Middleware Ginga Proyectando el desarrollo de aplicaciones interactivas para la televisión digital terrestre en el Perú, a continuación se desarrollara un estudio detallado del middleware Ginga, el cual fue adoptado en el año Para el sistema brasileño de TV digital (SBTVD), basado en el estándar japonés, fue definido un middleware propio denominado GINGA. En la Figura 3.4 se muestra el estándar SBTVD, incluido su middleware. Figura 3.4. Arquitectura en capas del estándar SBTVD. Ginga es la capa de software intermedio (middleware) que permite el desarrollo de aplicaciones interactivas para televisión digital, indepientemente de la plataforma de hardware de fabricantes de terminales de acceso (set top boxes) [7]. Este middleware puede dividirse en un conjunto de aplicaciones declarativas y aplicaciones procedurales. Para ello, Ginga se divide en dos grandes subsistemas 20

21 interconectados, Ginga-J (para las aplicaciones procedurales Java) y Ginga-NCL (para aplicaciones declarativas NCL). Depio de la funcionalidad del diseño de cada aplicación, un paradigma de programación es más adecuado que el otro [6]. En particular, las aplicaciones declarativas frecuentemente hacen uso de scripts, cuyo contenido es de naturaleza procedural. Por otra parte, una aplicación declarativa puede hacer referencia a una aplicación procedural, de la misma forma, una aplicación procedural puede hacer referencia a una aplicación declarativa, que contiene, por ejemplo, contenido gráfico, o puede construir y comenzar una presentación de aplicaciones con contenido declarativo. Por lo tanto, ambos tipos de aplicaciones Ginga pueden utilizar los beneficios que brindan los ambientes para las aplicaciones declarativos y procedurales [6]. La arquitectura de implementación de referencia del middleware Ginga, puede ser dividida en tres módulos: Ginga-CC (Common Core), el entorno de presentación Ginga-NCL (declarativo) y el entorno de ejecución Ginga-J (procedural) [7]. La arquitectura del middleware GINGA se ilustrada en la Figura 3.5. Figura 3.5.Arquitectura del middleware Ginga. La Figura 3.6 presenta un ambiente de ejecución común a las propuestas del middleware para la televisión digital. El Ambiente presenta una máquina de ejecución para las aplicaciones procedurales, una máquina de presentación para las aplicaciones declarativas y elemento-puente, que hace el mapeamiento bidireccional entre objetos procedurales y declarativos. [6]. 21

22 Interacciones con Usuarios Aplicación Aplicación Aplicación Aplicación Aplicación Maquina de Ejecución Elementos Puente Maquina de Presentación Monitor de Ciclo de Vida API Rede Acceso Servicio de Interface Eventos y Video Digital Otras Condicional Información Grafica Datos Difusión (MPEG) Midia Sistema Operacional Hardware Software Nativo Figura 3.6. Arquitectura del ambiente de ejecución de las aplicaciones para TV digital. Recomaciones ITU-T J Ginga-NCL Ginga-NCL fue desarrollado por la PUC Rio, destinadas a proporcionar una infraestructura para la presentación de las solicitudes declarativa escrito en el lenguaje de NCL (Nested contexto lingüístico). NCL es una aplicación XML (extensible Markup Language), con facilidades para especificar los aspectos de la interactividad, en tiempo-espacio entre los objetos de los medios de comunicación, la adaptabilidad, soporte a múltiples dispositivos y producción en vivo de programas interactivo no lineares. [7] Sio una aplicación XML, el lenguaje de NCL posee una estricta separación entre el contenido y la estructura, NCL no define los medios de comunicación por sí mismos. En cambio, mantiene los medios de comunicación, junto con una presentación multimedia. Sin embargo, un documento de NCL sólo define cómo los objetos de los medios de comunicación están estructurados y relacionados en el tiempo y el espacio. [8]. El video (MPEG, etc.), audio (AAC, etc.), imagen (JPEG, GIF, etc.) y texto (TXT, HTML, etc.), son ejemplos de objetos de medios de comunicación. Entre estos objetos se destacan los objetos de vídeo y audio en SBTVD [9]. Otro objeto importante es aquel basado en XHTML. NCL no sustituye a XHTML sino que complementa lo que es incapaz de cumplir como un lenguaje declarativo. A diferencia de XHTML el lenguaje NCL no mezcla la definición de contenido de un documento con su estructura. [9]. El ambiente declarativo es en sí muy limitado. Las aplicaciones que utilizan un lenguaje declarativo debe tener su enfoque sobre el sincronismo, sio el foco de la 22

23 lengua NCL exactamente eso, no la interactividad, ya que la interacción es tratada como resultado de la sincronización [8]. En NCL, un documento XHTML es un tipo de elemento de los medios de comunicación. De forma semejante, lenguajes imperativos pueden ser adicionados y utilizados como medios de comunicación. En concreto, el Ginga-NCL, debe ofrecer soporte a dos lenguajes procedurales, como son LUA y JAVA. Lua es el lenguaje script de NCL, y Java debe seguir las especificaciones de Ginga-J. [10]. LUA es un lenguaje de programación extensible diseñado para una programación procedimental general con utilidades para la descripción de datos. También ofrece un buen soporte para la programación orientada a objetos, programación funcional y programación orientada a datos. Se prete que Lua sea usado como un lenguaje de script potente y ligero para cualquier programa que lo necesite. [11]. Sio un lenguaje de extensión, Lua no tiene noción de programa principal (main): sólo funciona embebido en un cliente anfitrión, denominado programa contenedor o simplemente anfitrión (host). Éste puede invocar funciones para ejecutar un segmento de código Lua, puede escribir y leer variables de Lua y puede registrar funciones C para que sean llamadas por el código Lua. [11]. La utilización de LUA ofrece algunas ventajas, como: además de ser un proyecto de código abierto y desarrollado en C, LUA combina la programación procedural con poderosas construcciones para descripción de datos, basadas en tablas asociativas y semántica extensibles. Es notable por su alto rimiento y bajo consumo de recursos, en comparación con otros lenguajes interpretados [12] Ginga-J Ginga-J fue desarrollado por la Universidad Federal de Paraiba (UFPb), para proveer una infraestructura de ejecución de aplicaciones basadas en lenguaje Java, llamadas Xlet, con funcionalidades orientadas específicamente al medio ambiente de la televisión digital [7]. El Xlets no necesita ser previamente almacenados en el STB, pues puede ser enviado por el canal de distribución. Es decir, el modelo Xlet se basa en la transferencia de código ejecutable por el canal de distribución para el STB y posterior carga y ejecución del mismo, de forma automática o manual. Un Xlet es muy similar a un applet web o MIDlet en celulares u otros dispositivos móviles [13]. 23

24 El entorno de ejecución Ginga-J define un conjunto de APIs, los cuales pueden ser divididos en tres partes, como se ilustra en la Figura 3.7. El API (1), innovaciones que dan soporte a las aplicaciones brasileñas, en especial a la de contenido social; el API (2), también innovaciones brasileñas, pero que pueden ser exportadas para otros sistemas; y el API (3), que sigue el núcleo común del patrón GEM. Figura 3.7. Representación de los APIs de Ginga-J. En su versión actual el Ginga-J sigue las especificación del GEM (Globally Executable MHP) e ITU J.200, J.201 y J.202, sio por lo tanto compatible con los demás middlewares de TV digital que siguen estas especificaciones. El GEM está basado en el middleware MHP y especifica un conjunto de APIs, para ser usadas en el desarrollo de aplicaciones para la TV digital, incluyo las APIs provenientes de los paquetes de Sun JavaTV, DAVIC [DAVIC, 1999] e HAVI [HAVi, 2001]. A continuación se presenta un resumen de los APIS más usados: API JavaTV El API JavaTV es una extensión de la plataforma Java que sirve para apoyar la producción de contenidos interactivos de forma procedural para la televisión digital. El objetivo principal de la API JavaTV es proporcionar un conjunto de métodos, clases e interfaces para facilitar la creación de aplicaciones diseñadas para ejecutarse en distintas plataformas para la recepción de televisión digital indepiente de las tecnologías utilizadas en la red de transmisión [14]. JavaTv soporta un alto nivel de interactividad, calidad grafica y de procesamiento para ser ejecutado dentro de un set top box, siempre y cuando este equipada con la maquina virtual de Java, necesaria para interpretar los bytecodes generados. Utilizando su arquitectura la API JavaTV es capaz de realizar funcionalidades tales como: 24

25 Streaming de audio y vídeo: Además de la streaming de vídeo y audio procedente de la estación, es posible generar otras aplicaciones con otros flujos. Acceso a datos en el canal de transmisión: JavaTV pueden recibir datos para las aplicaciones. Aplicaciones con interactividad: Las aplicaciones que pueden utilizar esta API pueden procesar datos y devolverlos a través de un canal de retorno. Gestión del Ciclo de vida de las aplicaciones: permitio que las aplicaciones coexistan con el contenido de TV convencional y que permite el intercambio de canal sin que la aplicación deje de existir. La API JavaTv tiene varias librerías, que son responsables de proveer una estructura básica del sistema. Las librerías están dispuestas de la siguiente forma: javax.tv.carousel: proporciona acceso a archivos broadcast y directorio de datos a través de APIs que trabajan con el paquete java.io; javax.tv.graphics: permite que los Xlets, puedan obtener su repositorio principal; javax.tv.locator: proporciona una forma para referenciar datos en programas accesibles por la API JavaTV; javax.tv.media: define una extensión para JMF (Java Media Framework) con la finalidad de gestionar los medios de comunicación en tiempo real; javax.tv.media.protocol: proporciona acceso a un flujo de datos broadcast genérico; javax.tv.net: permite acceso a datagramas IP (Internet Protocol) transmitidos en un stream broadcast; javax.tv.service: proporciona mecanismos para accesar a la base de datos; javax.tv.util: soporta la creación y gestion de eventos del temporizador; javax.tv.xlet: proporciona interfaces para el desarrollo de aplicaciones y la comunicación entre las aplicaciones y el administrador. 25

26 API DAVIC El sistema DAVIC (Digital Audio Visual Council) es un conjunto de especificaciones que presenta algunos requisitos de sistemas audiovisuales para proporcionar interoperabilidad de extremo a extremo. Así, estos patrones se pueden utilizar en sistemas de televisión digital para proporcionar contenido al usuario final y también para permitir la interactividad con el mismo usuario [14]. El sistema DAVIC tiene su propio API, y por lo tanto puede ser considerado middleware como de alto nivel (aunque es común que empiecen a operar en conjunto con un middleware de bajo nivel). A continuación se enumeran los paquetes que forman parte de la API DAVIC incluido en el Ginga-J [14]: org.davic.media org.davic.resources org.davic.mpeg org.davic.mpeg.sections org.davic.net org.davic.net.dvb org.davic.net.tuning API HAVi HAVi (Home Audio Video Interoperability) es un API que permite al programador crear elementos, como la interfaz del usuario. Provee una extensión del paquete java.awt, permitio, asimismo, soporte de control remoto, transparencia, entre otros. El objetivo principal de una interfaz de usuario es proporcionar un entorno operativo fácil de usar. La arquitectura HAVi permite que los usuarios controlen dispositivos de forma familiar a través de un control remoto o delante de una pantalla. A continuación se enumeran los paquetes que forman parte de la API HAVi incluido en la Ginga-J [14]: org.havi.ui org.havi.ui.event API DVB En el desarrollo del middleware patron MHP, el DVB incluye algunos paquetes para exter la funcionalidad ofrecida por JavaTV, HAVi y DAVIC. Estas 26

27 características incluyen API de información de servicio, de intercomunicación entre Xlets, persistencia, etc. Algunas de las características también se incluyeron en el GEM. A continuación se enumeran los paquetes que forman parte de la API DVB incluida en la Ginga-J [14]: org.dvb.application org.dvb.dsmcc org.dvb.event org.dvb.io.ixc org.dvb.io.persistent org.dvb.lang org.dvb.media org.dvb.net org.dvb.net.tuning org.dvb.net.rc org.dvb.test org.dvb.ui 3.4. Ambientes de Emulación para la Programación de GINGA En la Figura 3.8 se ilustran las opciones para el desarrollo de aplicativos, los cuales pueden ser: Nivel de interactividad (interactividad local o remota). Desarrollador (emisora o usuario). Ambiente de ejecución. Figura 3.8. Directrices principales para el desarrollo de aplicativos para TV digital 27

28 Las aplicaciones pueden ser desarrolladas tanto por emisoras de televisión como por los usuarios. En el caso que sea desarrollada por una emisora, la aplicación será enviada al Set Top Box, a través de un canal de transmisión. En el caso de ser desarrollada por el usuario esta trá que ser enviada al Set Top Box a través de una entrada externa (USB portable, puerta de red, tarjeta de memoria, etc.) Una vez definido el nivel de interactividad y de desarrollo, se debe definir, el ambiente de ejecución. Ginga ofrece dos ambientes de ejecución: para aplicaciones declarativas Ginga-NCL y para aplicaciones no-declarativas Ginga-J. El lenguaje de programación declarativo son lenguajes de alto nivel de abstracción, usualmente ligada a un dominio u objetivo específico. Allí, el programador sólo proporciona el conjunto de tareas a realizar, no se ocupa de los detalles de cómo el ejecutor (intérprete, compilador u otra máquina virtual de ejecución) realmente implementara esas tareas. En una programación no declarativa, debemos informar cada paso a ser ejecutado. Se puede afirmar que el programador posee un nivel alto de conocimiento sobre el código, sio capaz de establecer todo el flujo de control y ejecución de su programa. Con el desarrollo de aplicaciones, nivel de interactividad y el ambiente de ejecución definidas, se puede, definir los pasos siguientes para crear estos aplicativos. El diagrama de la Figura 3.9 se ilustra las opciones que el desarrollador tiene disponible en cada ambiente para implementar los niveles de interactividad. Figura 3.9. Diagrama con las opciones de desarrollo 28

29 En el ambiente Ginga-NCL, podemos crear objetos que serán exhibidos a través del Formateador NCL, estos objetos también son llamados Nodo de contenido, estos pueden ser: Objetos de Mídia: que hace referencia a un elemento de comunicación como video, audio, imagen, texto, etc. Objetos XHTML: que hace referencia a un elemento XHTML. Objetos Lua: que referencia un elemento para dar soporte a la programación no declarativa utilizando script Lua. En el ambiente de ejecución de Xlets, o Ginga-J, se define la cantidad de Xlets necesarios. Esta cantidad depe del número de características distintivas que se llevarán a cabo para resolver el problema. Se recomia crear un Xlet para cada función específica, por ejemplo, en la Figura 3.10 se ilustra una aplicación interactiva de un programa deportivo, para el cual se han desarrollado los siguientes Xlets: xlet1: Visión de la cámara xlet2: Propaganda xlet3: 100 m planos xlet4: Salto con garrocha xlet5: Lanzamiento de Martillo xlet6: Salto alto xlet7: Lanzamiento de dardo xlet8: Selección de cámaras Para que el desarrollador pueda crear las ocho (8), este debe definir que API es la más adecuada y que soporte las características que se requieren implementar. Figura Pantalla exhibio varias Xlets. 29

30 Como suele ser difícil para un desarrollador de tener una red de televisión digital experimental, disponible en la mayoría de los casos, el medio ambiente es simulado con el uso de las estaciones de prueba o con emuladores de software. Para el desarrollo de aplicaciones existen varios emuladores, que simulan el papel del middleware, entre ellos el más utilizado para el ambiente Ginga-J es el XleTView,y para el ambiente Ginga-NCL.el Virtual Set Top Box Emulador GINGA-J: XLetView XletView, es un emulador usado para ejecutar Xlets en una PC, es de código abierto, y esta bajo la licencia de software libre GPL (General Public License), además de tener una implementación de referencia a la API JavaTV, trae consigo implementaciones de otras APIs especificadas en el estándar MHP (Multimedia Home Platform), como HAVI (Home Audio Video Interoperability), DAVIC (Digital Audio Video Council) e implementaciones especificadas por la propia DVB ( Digital Video Broadcasting), además de las bibliotecas de PersonalJava. Versiones actualizadas del XletView puede ser descargado libremente en la dirección electrónica: XletView está desarrollado en Java y para su ejecución indepientemente del sistema operativo, es necesario utilizar el Java 2 Standard Development Kit para compilar Xlets y ejecutar el XletView. Este emulador utiliza la JMF (Java Media Framework) 2.1.1, pero con algunas deficiencias, como la incapacidad de exhibir video MPEG (Moving Picture Grupo de expertos) relacionados o controlados por un Xlet. Un Xlet, es una aplicación Java que proporciona interactividad para la TV digital. Es similar a un applet, que es adicionado en paginas HTML, el Xlet es incluido en un servicio de TV digital. El middleware identifica un puente de entrada a la aplicación y ejecuta la aplicación utilizando la maquina virtual de Java. En la Figura 3.11 se ilustra la interface del XletView. 30

31 Figura Interface XletView. Con el propósito de utilizar el Emulador de Set-Top-Box para Ginga-J, usando la interface XletView, a continuación se desarrollara un aplicativo para TV digital utilizando el API JavaTV, el cual introduce el concepto de Xlet, que son aplicaciones en Java. La aplicación consiste en utilizar el Emulador del Set-Top-Box para Ginga-J, para ejecutar una aplicación, la cual mostrara en la pantalla un texto inicial, y enseguida este texto, cambiara para otro, equivalente al botón presionado por el control remoto. Para la ejecución de un aplicativo Xlet, es necesario tener instalado los siguientes programas y librerías: Java 2 Standard Development Kit (jdk-6u2-windos-i586-p): el cual se puede descargar de: Ambiente de ejecución para el desarrollo Java. IDE (Integrated Development Enviroment): es un ambiente integrado de desarrollo, y un programa de computador que reúne las características y herramientas de apoyo al desarrollo de software con el objetivo de agilizar este proceso. El IDE a utilizar es el Eclipse, el cual puede ser descargado de: JavaTV Api (api_itv-1_o-src): se descarga del siguiente link: JavaTv es un Api que nos ofrece un conjunto de clases e interfaces a fin de proveer funcionalidades y servicios interactivos de TV para el Set Top Box. 31

32 XletView (xletview-o.3.6): a descargar del siguiente link: Emulador para las aplicaciones Xlet. El código fuente para esta aplicación, se nombrado como ExemploXlet.java, el cual se encuentra en el ANEXO A. Debido a que el XletView solo acepta archivos.class (Xlets), para ser ejecutados, se utilizara la librería XletView.jar, que incluye recursos de la plataforma HAVi (Home Audio Video Interoperability). El XletView.jar es una librería Java de componentes gráficos desarrollados especialmente para la creación de interfaces para ambientes de TV. Para testear las aplicaciones haremos uso de la clase HscenseFactory y Hscene del API HAVi. El IDE Eclipse convierte los archivos.java en archivos.class, que son lo que van a utilizar. En la Figura 3.12 se ilustra, como los archivos.class y las librerías javatv.jar y xletview.jar son incluidas en el Build Path de Java. Figura 312. IDE Eclipse: Java Build Path para incluir las librerías javav.jar y xletview.jar. Para realizar el teste con el emulador, se ejecuta el XletView.jar, que se encuentra en el directorio donde fue descargado, hacio doble click sobre el archivo. En la Figura 3.13 se ilustra la pantalla inicial del XletView. 32

33 Figura Pantalla inicial del XletView Enseguida, se ejecutara el archivo que contiene nuestro programa ExemploXlet.class. Para este propósito, en la interface de la Figura 3.13, ir al menú Applications, luego a Manager applications, como ilustrado en la Figura Figura Pantalla del Administrador de aplicaciones. Para cargar un Xlet en el Emulador del Set-Top-Box, se debe llamarlo dentro de la carpeta Default Group, un directorio nativo de XletView. Así también, se puede crear otro subdirectorio hacio click en New Group, construyo un grupo particular de xlets. Enseguida, se cargar la xlet, dentro del Default Group, hacio click en New Application, luego en new app 1, con lo que aparecerá en el lado derecho tres cajas de texto, como se ilustra en la Figura 3.15, las cuales deben ser editadas para la ejecución del xlet. Name: Nombre del proyecto, con que la Xlet se mostrara en el menú aplicaciones. Path (ruta): Directorio donde se encuentra la Xlet. 33

34 Xlet: Archivo.class de la aplicación que será cargada. Figura Introducir información en una Xlet. Enseguida, se procede a cambiar el nombre del proyecto si es necesario, indicar la ruta donde se encuentra el archivo.class y por último el nombre del archivo. Finalmente, hacer click en el botón save & close. En la Figura 3.16, se ilustran las cajas de texto editadas. Figura Pantalla con el nombre, ruta y nombre del archivo editados. Luego de realizar la configuración, se procede a ejecutar la aplicación, hacio click en el menú Applications, el cual despliega una lista de las aplicaciones cargadas. Enseguida hacer click en la aplicación escogida, en este caso la aplicación con el nombre Hola Mundo, como se ilustra en la Figura

35 Figura Elección de la aplicación de nombre Hola Mundo. En la Figura 3.18 se ilustra la pantalla inicial de la aplicación, en la cual muestran dos textos Hola Mundo Java y Control Remoto. En esta aplicación, el texto Control Remoto, cambiara a otro texto conforme se presione un botón del control remoto. Por ejemplo, si se presiona el botón número 2 del control remoto, el nuevo texto, será: Boton Numerico: 2, como ilustrado en la Figura Para regresar a la pantalla inicial de la aplicación, hacer click en Applications, y escoger la opción Reload Current, reiniciando la aplicación a su estado inicial. Para cerrar el emulador haga click en Menú y luego escoger Exit Alt+F4. Figura Visualización inicial de la aplicación al ser ejecutada. Figura Pantalla en que aparece el nombre del botón clicleado. En este caso, el botón número Emulador GINGA-NCL: Set-Top-Box Virtual Set Top Box Virtual Ginga-NCL es una máquina virtual construida para facilitar el proceso de distribución e implantación de Ginga-NCL versión C++, en versión del reproductor del NCL, que consta con las características más avanzadas de 35

36 presentación de aplicaciones declarativas, mejor rimiento y mayor proximidad a una aplicación real embebida en un Set Top Box. El Emulador Set Top Box Virtual Ginga-NCL puede ser descargado de la dirección electrónica: La máquina virtual fedora-fc7-ginga-i386 ó Set Top Box Virtual fue creada y configurada por el equipo de Laboratorio TeleMídia de la Pontificia Universidad Católica de Rio de Janeiro (PUC-Rio, Brasil), utilizando el software VMWare Workstation 6. El VMvare Workstation puede ser descargado de la siguiente dirección electrónica: La maquina virtual, presenta como principales ventajas: Fácil instalación, no se requiere realiza configuraciones de kernel, ni de boot. Portabilidad entre diferentes sistemas operativos. Optimo ambiente de pruebas de aplicaciones NCL/NCLua Ambiente completo para los desarrolladores del propio middleware. Para simular una aplicación en el Set Top Box Virtual, es necesario tener instalado los siguientes programas Software de virtualización: VMWare Player (Windows ó Linux). VMWare Workstation (Windows ó Linux) VMWare Fusion (Mac OS X) Maquina Virtual fedora-fc7-ginga-i386.zip Después de descargar la maquina virtual fedora-fc7-ginga-i386.zip, descomprimir el archivo en un directorio del disco duro, ejecutar el VMware Worstation, y hacer click en Open Existing VM or Team, y escoger el archivo fedora-fc7-ginga-i386.vmx, iniciándose la instalación, como se ilustra en la Figura

37 Figura Archivo para instalación del Set Top Box virtual en el VMware. Al ejecutar la máquina virtual, se iniciara un proceso de arranque. No modifique la selección predeterminada en el gestor de arranque (GRUB). Así, el núcleo y toda la configuración grafica del Set Top Box serán cargados. La opción por defecto es Ginga-NCL Development Set-Top-Box v.x.x.xx. En la Figura 3.21 se ilustra la aplicación cargando el Grub por defecto. Figura Cargando el Ginga-NCL Development Set-Top-Box v Enseguida, aparecerá la pantalla con la inicialización del Ginga-NCL Set Top Box, como ilustrado en la Figura En esta pantalla se proporciona información referente a: Cuál es el mapeamiento usado por Ginga-NCL para las teclas de control remoto sobre el teclado de la PC. Cuál es la dirección IP automáticamente asociado al Set Top Box. El usuario y password con el que se podrá conectar vía ssh y SCP. La dirección del directorio donde se cargaran las aplicaciones, etc. 37

38 Figura Inicialización del Set Top Box virtual Ginga-NCL. Enseguida, se construyen dos archivos para implementar una aplicación de un juego llamado HACKERTEEN PROTOTYPE [15], como se ilustra en la Figura 3.23, que tiene las siguientes reglas: El juego tiene reglas sencillas. Se compone de una baraja de 25 cartas (5 copias de las 5 cartas numeradas del 1 al 5). Cada jugador empieza con 5 tarjetas aleatorias. El espectador asume el papel de Yago y sólo puede ver las 5 cartas de el héroe. Él juega contra la computadora, que controla Impius. Los personajes se colocan en la pantalla en un tablero con 23 posiciones. Yago es el primero en jugar, y, posteriormente, Impius y así sucesivamente. En su turno de juego, un personaje que usa una tarjeta y se desplaza al número de las posiciones indicadas por la tarjeta elegida. Cuando un jugador utiliza una tarjeta que indica el número exacto de las posiciones para llegar a su rival, está actuando como un atacante de un duelo. Un duelo es un desafío intelectual en el ámbito de Internet. El atacante muestra todas las cartas que posee con la distancia exacta a la rival. Si tiene más cartas del mismo valor que el defensor, gana el duelo. Para evitar la pérdida, el defensor debe mostrar el mismo número de tarjetas que el atacante mostró. En este caso, el defensor es el siguiente en el juego y ambos jugadores reciben cartas de la baraja para completar nuevamente una mano de 5 cartas. 38

39 Hay algunas reglas adicionales. Un personaje no puede utilizar una tarjeta con un valor mayor que su distancia al rival. Si un personaje no puede usar las cartas de su mano, pierde automáticamente. Cuando la cubierta se vacíe (el número de cartas en la baraja se muestra en la esquina inferior derecha de la pantalla), el jugador con más posiciones gana. En caso de un empate, Impius gana. El ganador del juego es quien gana tres desafíos. Los puntos se muestran en la pantalla. Los archivos que contienen los código fuente para implementar esta aplicación se encuentran en el ANEXO B y serán ejecutados en el Set Top Box Virtual: main.ncl hackerteen.lua Figura Juego HACKERTEEN PROTOTYPE ejecutándose en el Set-Top- Box Virtual usando Ginga-NCL. Para poder cargar una aplicación en el Set Top Box Virtual, se trá que contar con el WinSCP, al ejecutar lo aparecerá la pantalla que aparece en el Figura 3.24, en la cual se trá que colocar la dirección IP, del Set Top Box virtual, luego hacer un click en el botón Login. 39

40 Figura Pantalla de conexión al Set Top Box Virtual. Enseguida, aparecerá una pantalla en la cual se solicitara el nombre de usuario y el password, para poder logearse e ingresar al Set Top Box Virtual. Username: root Password: telemidia Con los permisos respectivos, enseguida, se tiene una nueva interface, como ilustrado en la Figura 3.25, en la cual se pueden cargar las aplicaciones NCL, que se encuentran en el lado izquierdo de la interfaz (el cual por defecto hace referencia a la unidad C de la PC). En el lado derecho de esta interface, se tiene el directorio del Set Top Box Virtual. Las aplicaciones desarrolladas, deben ser copiadas en el directorio del Set-Top-Box virtual /misc/ncl30. Figura Interface en la que se muestra el directorio de la PC y el directorio del Set Top Box Virtual. Una vez copiado la aplicación en el directorio del Set Top Box Virtual, se procederá a ejecutarlo. Para este propósito, se utilizara la herramienta llamada Putty, el cual también se conectara al Set Top Box Virtual, del mismo modo como se 40

41 conecto con el WinSCP, con la misma IP, usuario y password. En la Figura 3.26 se ilustra el programa putty conectado con el Set Top Box Virtual. Figura Putty conectado al Set Top Box Virtual. Enseguida, se procederá a colocar los comandos necesarios para ejecutar la aplicación, como se ilustra en la Figura Figura Comando para ejecutar la aplicación: /misc/launcher.sh /misc/ncl30/carpeta del archivo/archivo.ncl. En la Figura 3.28 se ilustra la aplicación ejecutándose dentro del Set top Box Virtual. Figura Aplicación ejecutándose dentro del Set Top Box Virtual. 41