Abstract— This paper presents a proposal for communication between consumer electronic devices and interactive applications based on the Brazilian standard for Digital TV. The integration process among the involved technologies as well as the role of each element in the proposed infrastructure is described in details. The main goal of this infrastructure is to join together, in the same environment, software technologies such as the Digital TV middleware (Ginga-NCL), a framework for the management of Home Networks (OSGi), and communication technologies that are more appropriated to the Brazilian interactive Digital TV market. In order to validate this infrastructure, some scenarios involving wireless communication technologies and Set-Top Boxes are created. The use of this infrastructure proved to be appropriated to provide new applications and services used on Digital TV to the users.

Keywords— Digital TV, Ginga-NCL, Home Networking, Infrastructure, OSGi.

I. INTRODUÇÃO

MAIORIA dos dispositivos eletrônicos modernos residenciais, pessoais ou móveis possui alguma

tecnologia de comunicação embarcada que possibilita trocar informações entre si. Essa tendência é decorrente do crescimento da quantidade de tecnologias de comunicação de dados como Bluetooth, Universal Serial Bus (USB) e Firewire, dentre outras. Com isso, diversas aplicações podem ser propostas, como, por exemplo, um celular que se comunica com uma geladeira solicitando informações sobre a quantidade de caixas de leite existente.

Essa integração fica mais fácil se introduzirmos um novo dispositivo denominado Gateway Residencial que integrado às redes domésticas possibilita: criar um elo comum de comunicação entre vários dispositivos domésticos usando diferentes tipos de tecnologias de comunicação e acessar serviços em outras redes domésticas (ver Fig. 1) [1].

Entre os dispositivos eletrônicos mais comuns nas residências (especificamente no Brasil), que podem ser integrados a uma rede doméstica, está a televisão. De fato, com o surgimento da TV Digital Interativa (TVDI),

O. B. Maia, Universidade Federal do Amazonas (UFAM), Manaus,

Amazonas, Brasil, orlewilson_maia@ufam.edu.br N. S. Viana, Universidade Federal do Amazonas (UFAM), Manaus,

Amazonas, Brasil, nairon_viana@ufam.edu.br W. S. da Silva Jr., Universidade Federal do Amazonas (UFAM), Manaus,

Amazonas, Brasil, waldirjr@ufam.edu.br V. F. de Lucena Jr., Universidade Federal do Amazonas (UFAM),

Manaus, Amazonas, Brasil, vicente@ufam.edu.br

possibilitou-se uma integração interessante entre aparelho de televisão e plataformas para redes domésticas [2]. Com o progresso da TVDI ao redor do mundo, os Set-Top Boxes (STBs), cujo objetivo primário era permitir que as televisões analógicas pudessem receber os sinais digitais, ganharam algumas melhorias no hardware, tais como maior poder de processamento e aumento da memória interna, e novas funcionalidades, como a execução de aplicativos interativos [3].

Figura 1. Exemplo de um Gateway Residencial.

Além disso, acredita-se que a médio e longo prazo os STBs

acumularão características de um Gateway Residencial popular [4]. No caso do Brasil, que está em fase de implantação da TVDI, existe um plano para substituir as TVs analógicas por TVs digitais até 2016. Enquanto isso não acontece, os STBs terão uma notável posição no mercado e nas residências dos brasileiros.

Com isso, um STB pode ser usado para criar um ambiente apropriado de colaboração entre aplicativos interativos da TVDI e os serviços disponibilizados pelos dispositivos domésticos, promovendo um ambiente de entretenimento bem como oferecendo novos serviços aos usuários, como, por exemplo, gerenciar o consumo de energia da residência, monitorar a temperatura de uma sala ou mesmo monitorar os batimentos cardíacos de um paciente, entre outros.

No entanto, existem algumas dificuldades a serem vencidas para assegurar uma colaboração entre TVDI e redes domésticas. Seria interessante, por exemplo, dispor de um Gateway Residencial compatível com a grande variedade de tecnologias de comunicação disponíveis em eletrônicos de consumo [5]. Além disso, não foi prevista uma camada física ou camada de rede na arquitetura nos STBs que possibilite uma comunicação padronizada entre TVDI e dispositivos domésticos [6].

O. B. Maia, N. S. Viana, Student, IEEE, W. S. da Silva Jr., V. F. de Lucena Jr., Member, IEEE

An Infrastructure for Managing Residential Devices through the Declarative Environment of

the Brazilian iDTV Middleware

A

Este trabalho contribui com a proposição, construção e validação de uma infraestrutura de comunicação entre um STB adequado ao modelo brasileiro de TVDI e dispositivos domésticos em um sistema de automação residencial. Essa infraestrutura possibilitará novos tipos de aplicações e cenários promovendo assim ao telespectador uma nova experiência com o gerenciamento da sua residência interconectada ao seu receptor de TV.

Uma análise de algumas abordagens de integração entre Redes Domésticas e TVDI é mostrada na Seção 2 e na Seção 3 é apresentada a infraestrutura proposta entre o middleware brasileiro de TVDI e Redes Domésticas. O processo de desenvolvimento do ambiente e a implementação de um estudo de caso para validar a infraestrutura são descritos nas Seções 4 e 5. Algumas considerações sobre o Ginga são descritas na Seção 6. Por fim, na Seção 7 são apresentadas algumas conclusões e perspectivas de trabalhos futuros.

II. INTEGRAÇÃO ENTRE REDES DOMÉSTICAS E TV DIGITAL

Neste trabalho, foram analisadas algumas abordagens de integração entre dispositivos eletrônicos localizados em uma rede doméstica sob três aspectos: (1) formas de comunicação entre dispositivos eletrônicos; (2) gerenciamento de dispositivos através de um Gateway Residencial; e (3) utilização da TV/STB como um Gateway Residencial.

Com relação ao aspecto (1) pode-se citar o trabalho de [7], que propôs um sistema de controle de dispositivos domésticos através de um celular via Bluetooth. Devido ao fato de que alguns dispositivos domésticos não possuem interfaces de comunicação integradas a eles, foram desenvolvidos adaptadores com Bluetooth conectados a esses dispositivos através da porta serial (RS 232). Uma desvantagem dessa abordagem é a necessidade de se criar novos adaptadores e integrá-los aos dispositivos domésticos para que esses possam encontrar outros dispositivos na casa.

Considerando o tema (2) podem-se citar os trabalhos descritos em [8] e [9] que utilizaram o Open Services Gateway Initiative (OSGi) no Gateway Residencial. O OSGi especifica uma plataforma de software que define componentes que permitem a conexão da rede residencial com o mundo externo, tendo como base um modelo orientado a serviços. O modelo é construído sob conceitos de modularidade e componentes de software. O framework também provê um mecanismo para o gerenciamento de serviços através de unidades de aplicações conhecidas como bundles [10]. Com o uso do OSGi, possibilitou-se o uso de tecnologias de comunicação de baixo custo, como Bluetooth, ZigBee e WiFi, e o acesso de conteúdos e serviços localizados localmente (através dos dispositivos eletrônicos) ou remotamente (através de provedores de serviços). Já em [11], os dispositivos são gerenciados remotamente através de uma página Web disponível pelo Gateway Residencial o qual utiliza a especificação Universal Plug and Play (UPnP) e a tecnologia de comunicação ZigBee. O principal foco desses trabalhos foi o uso de recursos limitados, como a baixa taxa de transmissão de dados e o baixo consumo de energia.

Os trabalhos relacionados ao aspecto (3) exploram a idéia de integração entre TV/STB e Gateway Residencial. Uma das primeiras idéias de se utilizar a TV para gerenciar dispositivos domésticos foi a criação de uma camada de protocolo denominada Home Audio Video interoperability (HAVi) [12]. O HAVi oferece suporte a dispositivos multimídias (áudio e vídeo) e a comunicação entre esses dispositivos é realizada através do padrão IEEE 1394. Sua principal desvantagem está relacionada ao gerenciamento exclusivo entre dispositivos multimídias e à necessidade de criar uma Application Programming Interface (API) para se comunicar com outras tecnologias de comunicação, como Bluetooth, WiFi, dentre outros [13].

No trabalho descrito em [2], a conexão entre um aplicativo interativo da TVDI e um dispositivo que administra remotamente os dispositivos eletrônicos é realizada através de comandos usando redes Transmission Control Protocol / Internet Protocol (TCP/IP). Em [14] é apresentado um framework denominado Digital TV – Home Network Framework (DTV-HNF) que gerencia solicitações originadas das aplicações da TVDI para acessar serviços de um dispositivo conectado à rede doméstica através do uso de services plugins, os quais provêm uma interface aos aplicativos da TVDI para acessar os serviços dos dispositivos localizados na rede doméstica.

Uma desvantagem encontrada nesses trabalhos é que eles não oferecem suporte a uma comunicação bidirecional. Ou seja, somente os aplicativos interativos da TVDI podem acessar os serviços dos dispositivos eletrônicos localizados em uma rede doméstica.

Para suprir essa dificuldade, os trabalhos propostos em [15]-[17] descrevem uma integração entre TVDI e Gateway Residencial em um mesmo ambiente. Ou seja, em um mesmo dispositivo (STB, por exemplo) estão presentes características tanto de uma TVDI quanto de um Gateway Residencial. Nesses trabalhos, tanto um aplicativo da TVDI pode acessar os serviços de um dispositivo eletrônico, quanto os dispositivos eletrônicos podem interagir com um aplicativo da TVDI.

Em nenhum dos trabalhos analisados foi proposto um modelo de colaboração entre um aplicativo declarativo (como o Ginga-NCL) e um Gateway Residencial. Além disso, não existe uma infraestrutura de comunicação que permita a comunicação entre um STB baseado no modelo brasileiro de TVDI e um Gateway Residencial. O trabalho apresentado neste artigo propõe um modelo de colaboração que preenche as lacunas descritas anteriormente, principalmente àquelas relacionadas ao modelo brasileiro de TVDI.

III. INFRAESTRUTURA DE COMUNICAÇÃO GINGANCL-OSGI

O desenvolvimento da infraestrutura de comunicação entre STB do modelo brasileiro de TVDI e dispositivos domésticos gerenciados por um Gateway Residencial levou em conta: as tecnologias de comunicação; a especificação utilizada pelo Gateway Residencial para o gerenciamento dos dispositivos eletrônicos; e a criação de um mecanismo de comunicação

entre o middleware do modelo brasileiro de TVDI e a especificação utilizada pelo Gateway Residencial escolhida anteriormente.

Dentre uma grande variedade de tecnologias de comunicação que podem ser encontradas no mercado, optou-se nesse trabalho pelo uso das redes sem fios baseadas em Bluetooth, WiFi e ZigBee, considerando: a não utilização de cabos para conectar os dispositivos eletrônicos, o que é fundamental para trabalhar com dispositivos móveis em uma residência; que essas tecnologias são suportadas por vários dispositivos, como telefones celulares, impressoras, máquinas fotográficas digitais, televisores, etc; que todas elas são de fácil utilização; e que a distância típica entre os dispositivos domésticos é pequena, não sendo necessário o uso de tecnologias que tenham um grande alcance de sinal.

Como plataforma de software que permitirá que os aplicativos da TVDI gerenciem dispositivos localizados na Rede Doméstica, optou-se pelo OSGi pelas seguintes razões: os serviços dos dispositivos são gerenciados localmente pelo framework OSGi não necessitando realizar uma busca na rede para conhecer os dispositivos existentes na residência; a identificação dos dispositivos é representada por uma interface Java o que aumenta sua compatibilidade com outros dispositivos programáveis; a descoberta de serviços é realizada por meio de uma busca no registro de serviços e não pelo envio de mensagem remotas; e além de oferecer suporte ao gerenciamento de vários dispositivos (de várias tecnologias de comunicação), o OSGi tem suporte a outras especificações para Redes Domésticas, como o UPnP e Jini possibilitando expansões futuras.

Por fim, para descrever o mecanismo de comunicação entre o middleware brasileiro de TVDI (Ginga) e a especificação utilizada pelo Gateway Residencial (OSGi), apresentaremos algumas características do Ginga.

O Ginga é o middleware do Internacional Standard for Digital Television (ISDTV) baseado nas especificações J.200, J.201 e J.202 [18]. Ele é constituído basicamente de quatro estruturas: (1) ambiente declarativo denominado Ginga-NCL, representado pela Nested Context Language (NCL); (2) ambiente procedural denominado Ginga-J, representado pelos aplicativos desenvolvidos em Java; (3) um núcleo comum denominado Ginga Common Core; e (4) uma ponte de comunicação entre Ginga-NCL e Ginga-J [18]-[19].

O Ginga-J é uma máquina de execução que provê um ambiente para o desenvolvimento de aplicações baseada em Java denominada xlet. Já o Ginga-NCL possui uma máquina de apresentação responsável pelo processamento e interpretação de documentos NCL. O Ginga Common Core é responsável pelo processamento de conteúdos comuns ao Ginga-NCL e Ginga-J, como JPEG, MPEG, MP3, HTML e assim por diante, através de Adapters. Um Adapter é um componente que prepara uma região da tela da TV baseada

nas informações contidas no documento NCL e cria um Player para executar a mídia desejada. Finalmente, a ponte entre o Ginga-NCL e o Ginga-J fornece um mecanismo de comunicação entre os aplicativos do Ginga-NCL com os aplicativos do Ginga-J e vice-versa.

Para representar a TVDI na infraestrutura de comunicação proposta neste trabalho, escolheu-se o Ginga-NCL. Destaca-se que o Ginga-NCL será o primeiro a ser implantado nos STBs brasileiros. Além disso, pode-se explorar algumas de suas características, como a sincronização temporal-espacial entre mídias (áudio, vídeo, textos, imagens) e dispositivos eletrônicos. Um cenário utilizando essa característica do Ginga-NCL em ambientes domésticos seria, por exemplo, em um determinado momento de um filme de terror, ser acionado um mecanismo de busca de dispositivos eletrônicos que podem ser ligados/desligados ou fazer algum tipo de barulho para tornar o ambiente adequado à cena do filme.

Com base nas análises realizadas nessa seção, o presente trabalho contribui para a comunidade científica com a proposição, construção e validação de uma infraestrutura de comunicação, doravante denominada GingaNCL-OSGi, que possibilita a interação entre o middleware brasileiro Ginga-NCL e o framework OSGi.

Uma visão geral da infraestrutura GingaNCL-OSGi é ilustrada na Fig. 2. Nessa figura são mostrados os componentes criados na camada de software que possibilitam a comunicação entre Ginga-NCL e OSGi, as tecnologias de comunicação escolhidas e alguns exemplos de dispositivos eletrônicos e seus respectivos serviços. Além desses componentes, foram criados dois novos Adapters que trabalham como uma ponte de comunicação entre esses componentes. Os componentes que fazem parte do GingaNCL-OSGi são: DeviceBundle: representa um dispositivo eletrônico localizado na Rede Doméstica. Ele possui um arquivo do tipo Manifesf no qual são descritas informações padrões sobre o dispositivo, como o nome do provedor, a versão do dispositivo, o identificador do dispositivo no ambiente do OSGi, etc. Além disso, para oferecer ao telespectador informações mais detalhadas sobre os serviços desse dispositivo, criou-se outro arquivo do tipo Property para representar o nome usual do dispositivo, o nome dos serviços disponíveis e a descrição de cada serviço.

Figura 2. Infraestrutura GingaNCL-OSGi.

ListenerServerBundle – esse componente possui três papéis. O primeiro está relacionado ao registro de serviços no Service Registry. Ele possui um serviço denominado ListenerService, o qual aguarda que alguma ação aconteça no Servive Registry (como registro, modificação ou desinstalação de algum serviço). No instante que um DeviceBundle registra os seus serviços no Service Registry, o ListenerServerBundle obtém informações contidas nos arquivos Manifest e Property em formato eXtensible Markup Language (XML). O seu segundo papel é informar os serviços disponíveis no Service Registry a um aplicativo do Ginga-NCL quando solicitado, possibilitando que o telespectador tenha acesso aos dispositivos localizados em sua residência. E o seu terceiro papel é invocar o serviço desejado pelo telespectador através do aplicativo interativo. CommunicationBridge – ele é composto por duas classes Java denominadas BundleContextBridge e GingaNCLContextBridge. Essas classes têm como papel armazenar o contexto de um bundle e o objeto de um aplicativo Ginga-NCL, respectivamente. Além disso, no GingaNCLContextBridge é informado o nome da funcionalidade do aplicativo interativo que o identificará no ambiente do OSGi. ExporterBundle – para que um aplicativo interativo possa acessar algum serviço do DeviceBundle, é necessário conhecer a sua referência no Service Registry. Com esse intuito, esse componente exporta o seu contexto no BundleContextBridge o qual permite ao aplicativo interativo solicitar ao ListenerServerBundle os serviços registrados no Service Register através do OSGiAdapter.

GingaNCLBundle – para que um bundle OSGi possa ter acesso a algum aplicativo interativo, é necessário registrar esse aplicativo como um serviço no ambiente do OSGi. Para isso, o aplicativo interativo armazena o objeto que o representa no GingaNCLContextBridge através do GingaNCLAdapter. Além disso, criou-se um listener, denominado GingaNCLAdapterListener, com o objetivo de gerenciar as solicitações de criação ou exclusão de serviços que representam o aplicativo interativo no ambiente do OSGi. Assim, qualquer DeviceBundle pode acessar os serviços oferecidos por um aplicativo interativo após a busca de sua referência no Service Registry. ExtendedAdapters – para garantir a integridade do Ginga Common Core, dois novos Adapters denominados OSGiAdapter e GingaNCLAdapter foram desenvolvidos. O OSGiAdapter é responsável por recuperar o contexto de um bundle armazenado no BundleContextBridge e solicitar ao ListenerServerBundle os serviços registrados no Service Registry. Após isso, OSGiAdapter pode acessar algum DeviceBundle e usufruir de seus serviços. Já o GingaNCLAdapter armazena um objeto Ginga-NCL para GingaNCLContextBridge, possibilitando que o GingaNCLBundle o registre como um serviço no Service Registry. Com isso, o DeviceBundle pode acessar esse serviço e se comunicar com um aplicativo interativo.

Com o uso desses componentes, as características tanto do Ginga-NCL quanto do OSGi não foram modificadas, ou seja, os aplicativos interativos são acessados pelos bundles através de um serviço que os representa no ambiente do OSGi e os serviços OSGi são acessados pelos aplicativos interativos após a sua descoberta no Service Registry. Nas subseções a seguir, são descritos os mecanismos de comunicação entre aplicativos Ginga-NCL e serviços OSGi.

Figura 3. Acessando os serviços OSGi através dos aplicativos Ginga-NCL.

A. Acessando os serviços OSGi através dos aplicativos interativos Ginga-NCL

Na Fig. 3, é mostrado o processo de comunicação dos aplicativos interativos Ginga-NCL com os serviços localizados no ambiente do OSGi. Os componentes utilizados nesse processo são: ListenerServerBundle, DeviceBundle, ExporterBundle, OSGiAdapter e BundleContextBridge (pertencente ao CommunicationBridge).

No momento em que o GingaNCL-OSGi é iniciado, o ListenerServerBundle registra os seus serviços no Service Registry (passo 1 da Fig. 3). Uma de suas responsabilidades é armazenar a descrição dos serviços que são registrados no Service Registry e prover uma lista destes em formato XML. Para isso, o ListenerServerBundle fica aguardando por algum registro de novos serviços no Service Registry através de um listener denominado ServiceListener. Quando um DeviceBundle registra os seus serviços, o ListenerServerBundle lê algumas informações contidas nos arquivos Manifest e Property desse bundle (passo 2), essas informações ajudarão na escolha dos serviços pelo telespectador. Para garantir que esses serviços descritos em formato XML pelo ListenerServerBundle sejam recuperados pelo aplicativo interativo, outro bundle, denominado ExporterBundle, é utilizado para armazenar o seu contexto no BundleContextBridge (passo 3).

Em seguida, o OSGiAdapter recupera o contexto do ExporterBundle armazenado no BundleContextBridge (passo 4) e utiliza esse contexto para solicitar ao ListenerServerBundle os serviços registrados no Service Registry (passo 5). Após isso, os serviços dos dispositivos localizados na residência são mostrados na tela da televisão através do OSGiAdapter (passo 6). Por fim, o OSGiAdapter solicita ao ListenerServerBundle invocar o serviço escolhido pelo telespectador (passo 7).

Figura 4. Acessando os aplicativos Ginga-NCl através dos bundles OSGi.

B. Acessando os aplicativos interativos Ginga-NCL através dos bundles OSGi

Na Fig. 4 é ilustrado o acesso dos bundles OSGi aos aplicativos interativos Ginga-NCL. Nesse processo, são usados os componentes: DeviceBundle, GingaNCLAdapter, GingaNCLBundle, e GingaNCLContextBridge (pertencente ao CommunicationBridge).

Quando um Player do GingaNCLAdapter executa uma mídia que esteja sincronizada a um serviço que disponibilizará o acesso a esse aplicativo interativo, o GingaNCLAdapter armazena um objeto GingaNCL no GingaNCLContextBridge e informa o nome da funcionalidade que o identificará no Service Registry (passo 1 da Fig. 4).

No momento que esse objeto é armazenado, o GingaNCLBundle é informado através do GingaNCLAdapterListener que existe uma solicitação para registrar uma funcionalidade de um aplicativo interativo no ambiente do OSGi. Com isso, o GingaNCLBundle recupera esse objeto e o nome que o identificará no ambiente do OSGi (passo 2) e o registra no Service Registry como um serviço (passo 3).

Finalmente, quando algum DeviceBundle necessitar se comunicar com esse aplicativo interativo, ele realizará uma busca no Service Registry e recuperará a referência do serviço que representa esse aplicativo interativo (passo 4). Dessa maneira, o DeviceBundle pode acessar os serviços correspondentes ao GingaNCLAdapter (enviar uma mensagem de alerta de incêndio, por exemplo) que estão relacionados a uma região descrita no documento NCL (passo 5).

IV. IMPLEMENTAÇÃO DO GINGANCL-OSGI

Para que a concepção do GingaNCL-OSGi fosse implementada e testada, uma plataforma baseada em um PC foi utilizada para emular a TVDI (Ginga-NCL) e o Gateway Residencial (OSGi). A plataforma é caracterizada por um computador com processador Intel Pentium 4.3 GHz, 1 GByte

de memória RAM. O sistema operacional utilizado foi o Ubuntu 8.04, versão do kernel 2.6.24. Para representar o middleware declarativo Ginga-NCL e o framework OSGi, foram utilizados o Ginga-NCL Emulator versão 1.1.1 e o Knopflerfish versão 1.3.4, respectivamente.

A plataforma GingaNCL-OSGi é a união do middleware declarativo Ginga-NCL com o framework OSGi. Foi necessário integrar o Ginga-NCL Emulator e Knopflerfish em uma mesma Java Virtual Machine (JVM), ou seja, no instante que a JVM é inicializada, tanto o Ginga-NCL Emulator quanto o Knopflerfish são executados. Para isso, modificou-se o código fonte do Ginga-NCL Emulator definindo um ClassLoader específico para carregar as classes do Ginga-NCL Emulator e do Knopflerfish. Dessa maneira, os Adapters do Ginga-NCL passam a ter acesso aos serviços localizados no ambiente do OSGi assim como os bundles OSGi podem usufruir das funcionalidades dos Adapters do Ginga-NCL.

A implementação dos componentes que formam a infraestrutura GingaNCL-OSGi foi dividida em três grupos: (1) componentes gerais: são aqueles que tem uma participação comum entre Ginga-NCL e OSGi (DeviceBundle e CommunicationBridge); (2) componentes da interação do Ginga-NCL para o OSGi: são aqueles que participam da comunicação entre os aplicativos interativos com os serviços dos dispositivos gerenciados pelo OSGi (ExporterBundle, ListenerServerBundle e OSGiAdapter); e (3) componentes da interação do OSGi para o Ginga-NCL: são aqueles que participam da comunicação entre os dispositivos domésticos com os aplicativos interativos (GingaNCLAdapter e GingaNCLBundle).

Por fim, para que tanto o OSGiAdapter quanto o GingaNCLAdapter possam ser utilizados na plataforma GingaNCL-OSGi, dois arquivos do Ginga-NCL Emulator foram configurados: mimedefs.ini e ctrldelfs.ini. No primeiro, foram criados novos alias do tipo application/x-osgi-service, que quando executados possibilitam que um aplicativo interativo possa ter acesso aos serviços localizados na Rede Doméstica, e application/x-ginga-create-service, que quando solicitados registram uma funcionalidade do aplicativo interativo em forma de serviço no ambiente do OSGi. Já no arquivo ctrldelfs.ini, deve-se informar a localização desses novos Adapters.

V. EXPERIMENTOS E RESULTADOS

A fim de verificar o funcionamento da plataforma GingaNCL-OSGi desenvolvida, criou-se uma aplicação de gerenciamento de um sistema de temperatura e ventilação. Para isso, um bundle denominado ZigBeeFanBundle foi desenvolvido para representar um sensor de temperatura e um ventilador. Ele tem o papel de gerenciar as solicitações originadas de um telespectador através do aplicativo interativo, enviar os comandos (ligar ou desligar) ao ventilador, e ler o valor do sensor de temperatura. Essa troca de informações é realizada via ZigBee. Além disso, o ZigBeeFanBundle também envia mensagens ao aplicativo interativo informando à resposta referente a solicitação.

O ZigBeeFanBundle é representado fisicamente por uma placa constituída de um sensor de temperatura, um sensor de luminosidade, uma interface para o módulo XBee-Pro e um microcontrolador da Artmega8. Também foi integrada outra placa formada por quatro relés onde um deles foi utilizado para ligar/desligar o ventilador.

Depois do desenvolvimento dos métodos que representam os serviços do ZigBeeFanBundle, este foi instalado e executado na plataforma GingaNCL-OSGi. Uma vez inicializado, o ZigBeeFanBundle fica aguardando alguma solicitação para ligar/desligar o ventilador ou ler o valor do sensor de temperatura por parte do aplicativo interativo. Para isso, ele utiliza o ListenerServerBundle que coleta algumas informações contidas nos arquivos Manifest e Property do ZigBeeFanBundle após o registro dos seus serviços no Service Registry. Depois disso, essas informações são armazenadas e disponibilizadas pelos serviços do ListenerServerBundle.

O próximo passo é habilitar a comunicação entre o aplicativo interativo com o ZigBeeFanBundle. Para isso, utilizou-se o ExporterBundle para armazenar o seu contexto no BundleContextBridge e permitir que o OSGiAdapter tenha acesso ao ListenerServerBundle. Feito isso, o OSGiAdapter solicita ao ListenerServerBundle o nome usual, a descrição e os serviços do ZigBeeFanBundle. Em seguida, no arquivo NCL são definidas novas mídias do tipo application/x-osgi-service que representarão as informações do ZigBeeFanBundle. Para que o telespectador possa saber se a sua solicitação foi realizada com sucesso, foram criados o MessengerAdapter e o MessengerPlayer. Também foi criado um novo alias denominado application/x-ginga-messenger nos arquivos mimedefs.ini e ctrldelfs.ini para que este novo Adapter possa ser executado.

Quando uma mídia do tipo application/x-ginga-messenger é inicializada pelo vídeo apresentado na tela da TV, o MessengerPlayer exporta um objeto Ginga-NCL para o GingaNCLContextBridge informando que precisa registrar um novo serviço denominado SendMessageToGingaNCL. Nesse instante, o GingaNCLBundle fica sabendo da solicitação através de seu listener GingaNCLAdapterListener e o registra no Service Registry.

No exemplo aqui descrito, é inicializado o processo de gerenciamento do ventilador e monitoramento do sensor de temperatura através de um aplicativo interativo. Primeiramente é apresentada uma informação na tela da TV mostrando que o telespectador deverá apertar o botão vermelho de seu controle remoto para saber quais dispositivos domésticos estão localizados em sua casa. Em seguida, o MessengerAdapter é inicializado e solicita ao GingaNCLBundle que registre um serviço denominado SendMessageToGingaNCL. Além disso, o OSGiAdapter solicita ao ListenerServerBundle os dispositivos registrados no Service Registry e então os dispositivos são mostrados na tela da TV (ver Fig. 5).

Figura 5. Visualizando os dispositivos eletrônicos localizados na residência.

Caso o telespectador escolha, por exemplo, o ventilador,

uma lista de serviços deste dispositivo é mostrada na tela da TV. Quando o telespectador escolher a opção Turn On Fan, o OSGiAdapter solicita ao ListenerServerBundle que execute o método turnOnFan do ZigBeeFanBundle. Na sequência o ZigBeeFanBundle envia a mensagem para a placa microcontroladora que por sua vez liga o ventilador através do relé. Neste momento, a placa envia a mensagem Fan Turned On ao ZigBeeFanBundle, que por sua vez invoca o método SendMessageToGingaNCL do MessengerPlayer passando como parâmetro a mensagem. Por fim, a mensagem é mostrada na tela da TV do telespectador (ver Fig. 6).

Figura 6. Ligando o ventilador através do aplicativo interativo.

Caso o telespectador escolha a opção Get Local

Temperature, o OSGiAdapter solicita ao ListenerServerBundle que execute o método getTemperature do ZigBeeFanBundle. Em seguida, o ZigBeeFanBundle envia uma mensagem para a placa microcontroladora que, por sua vez, lê o valor do sensor de temperatura. Após isso, o valor da temperatura é enviado ao ZigBeeFanBundle que se comunica com o MessengerPlayer através de seu método SendMessageToGingaNCL, passando como parâmetro a mensagem Local Temperature 27 ˚C, por exemplo. Finalmente, a mensagem é exibida na tela da TV do telespectador, conforme ilustrada na Fig. 7.

Figura 7. Exibindo o valor do sensor de temperatura através de um aplicativo interativo.

VI. CONSIDERAÇÕES SOBRE O GINGA

O desenvolvimento de aplicações para a TV Digital é uma área muito promissora no Brasil. De forma semelhante, aplicações e serviços disponibilizados em redes domésticas ainda são pouco estudados e a maioria dos trabalhos encontrados sobre o assunto é de âmbito internacional. Ao investigar essas novas áreas, este trabalho enfrentou alguns desafios: fornecer à comunidade uma visão do estado da arte; coletar referências adequadas; buscar especificações abertas; compreender novos modelos e arquiteturas; e contribuir para a consolidação do padrão brasileiro de TVDI.

Com relação ao Ginga, em específico ao Ginga-NCL, demonstrou-se que é possível adicionar novos componentes de forma a criar um ambiente de integração entre o modelo brasileiro de TVDI e dispositivos localizados em uma rede doméstica sem alterar as peculiaridades de ambos os ambientes. Além disso, quando a ponte de comunicação entre Ginga-J e Ginga-NCL estiver operacional, será possível que os aplicativos desenvolvidos e executados no ambiente Java acessem dispositivos localizados em uma rede doméstica através dos componentes criados para o Ginga-NCL.

Além disso, outros cenários podem ser explorados. Por exemplo, quando uma pessoa chega em casa, ela é reconhecida pela televisão através de seu telefone celular e em seguida um aplicativo interativo recomenda uma lista de programas que ela poderia assistir baseado no seu perfil.

VII. CONCLUSÕES E PERSPECTIVAS

O principal objetivo deste trabalho foi a proposição, construção e validação de uma infraestrutura de comunicação entre dispositivos domésticos e um STB baseado no modelo brasileiro de TVDI. Para isso, foi criada a plataforma GingaNCL-OSGi, permitindo a interação entre aplicativos do Ginga-NCL e dispositivos domésticos gerenciados pelo OSGi.

Nesta infraestrutura, algumas das principais tecnologias de comunicação foram avaliadas de modo a escolher as mais adequadas aos lares brasileiros. Estratégias de comunicação entre TV e dispositivos domésticos considerando o modelo brasileiro de TVDI foram estudadas. Ao final, foram criados

cenários para validar essa infraestrutura. As características peculiares tanto do Ginga-NCL quanto do OSGi não foram alteradas. Ou seja, um aplicativo interativo acessa os serviços disponíveis na rede doméstica e um bundle acessa um aplicativo Ginga-NCL através de um serviço que o representa no ambiente do OSGi.

A próxima atividade deste trabalho será desenvolver uma ferramenta de autoria para facilitar a criação de novos Adapters de forma que possam ser utilizados tanto na solicitação de algum serviço de um dispositivo gerenciado pelo OSGi quanto no registro de funcionalidades de um aplicativo interativo que serão executadas pelos dispositivos domésticos.

AGRADECIMENTOS

Os autores gostariam de agradecer a Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES), ao Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq) e ao Centro de Pesquisa e Desenvolvimento em Tecnologia Eletrônica e da Informação (CETELI) pelo suporte para a implementação desse trabalho.

REFERÊNCIAS [1] R. P. D. Redondo, A. F. Vilas, M. R. Cabrer, and J. J. P. Arias,

“Exploiting osgi capabilities from mhp applications”, Journal of Virtual Reality and Broadcasting, vol. 4, no. 16, July 2007.

[2] D. Tkachenko, N. Kornet, and A. Kaplan, “Convergence of iDTV and home network platforms”, First IEEE Consumer Communications and Networking Conference, pp. 624-626, 5-8 Jan. 2004.

[3] S. Morris, and A. Smith-Chaigneau. Interactive TV Standards: A Guide to MHP, OCAP and JavaTV. Burlington: Focal Press, 2005, p. 585.

[4] F. T. H. den Hartog, M. Balm, C. M. de Jong, and J. J. B. Kwaaitaai, “Convergence of residential gateway technology”, IEEE Communications Magazine, vol.42, no. 5, pp. 138-143, May 2004.

[5] L. Gong, “A software architecture for open service gateways”, IEEE Internet Computing, vol.5, no. 1, pp. 64-70, Jan/Feb 2001.

[6] F. M. Matsubara, S. Miura, S. Imai, and S. Akatsu, “DTV architecture design for multimedia network environments”, International Conference on Consumer Electronics, pp. 147-148, 8-12 Jan. 2005.

[7] H. Kanma, N. Wakabayashi, R. Kanazawa, and H. Ito, “Home appliance control system over bluetooth with a cellular phone”, IEEE Transactions on Consumer Electronics, vol. 49, no. 4, pp. 1049–1053, Nov. 2003.

[8] B. Rose, “Home networks: a standards perspective”, IEEE Communications Magazine, vol. 39, no. 12, pp. 78–85, Dec. 2001.

[9] K. Hofrichter, “The residential gateway as service platform”, International Conference on Consumer Electronics, vol. 1, pp. 304–305, June 2001.

[10] A. L. Tavares, and M. T. Valente, “A gentle introduction to OSGi”, SIGSOFT Softw. Eng. Notes vol. 33, no. 5, pp. 1–5, Aug. 2008.

[11] K. Kim, C. Park, K. Seo, I. Chung, and J. Lee, “Zigbee and the upnp expansion for home network electrical appliance control on the internet”, The 9th International Conference on Advanced Communication Technology, vol. 3, pp. 1857–1860, Feb. 2007.

[12] P. Marshall, “Home networking: a tv perspective”, Electronics and Communication Engineering Journal, vol. 13, no. 5, pp. 209–212, Oct. 2001.

[13] Specification of the Home Audio/Video Interoperability (HAVi) Architecture. HAVi, Inc. Version 1.1, May 2001.

[14] D. Tkachenko, N. Kornet, A. Dodson, L. Li and R. Khandelwal, “A framework supporting interaction of idtv applications and ce devices in home network”, Second IEEE Consumer Communications and Networking Conference, vol. 1, pp. 605–607, Jan. 2005.

[15] M. R. Cabrer, R. P. D. Redondo, A. F. Vilas, J. J. P. Arias, and J. G. Duque, “Controlling the smart home from tv”, IEEE Transactions on Consumer Electronics, vol. 52, no. 2, p. 421–429, May 2006.

[16] M. Yang, N. Sheng, B. Huang, and J. Tu, “Collaboration of set-top box and residential gateway platforms”, IEEE Transactions on Consumer Electronics, vol. 53, no. 3, pp. 905–910, Aug. 2007.

[17] C. Lin, P. Wang, and T. Hou, “A wrapper and broker model for collaboration between a set-top box and home service gateway”, IEEE Transactions on Consumer Electronics, vol. 54, no. 3, pp. 1123–1129, Aug. 2008.

[18] G. L. Souza Filho, L. E. C. Leite, and C. E. C. F. Batista, “Ginga-j: The procedural middleware for the brazilian digital tv system”, Journal of the Brazilian Computer Society, vol. 13, no. 1, pp. 47–56, Mar. 2007.

[19] L. F. G. Soares, R. F. Rodrigues, and M. F. Moreno, “Ginga-ncl: The declarative environment of the brazilian digital tv system”, Journal of the Brazilian Computer Society, vol. 13, no. 1, pp. 37–46, Mar. 2007.

Orlewilson Bentes Maia concluiu a graduação em Ciência da Computação (Bacharel) pelo Centro de Ensino Superior FUCAPI (CESF) em 2006. Obteve o título de Mestre em Engenharia Elétrica na área de Controle e Automação de Sistemas pela Universidade Federal do Amazonas (UFAM) em 2009. É aluno do doutorado do programa de pós-graduação em Engenharia Elétrica da Universidade Federal

de Minas Gerais (UFMG). Atualmente desenvolve pesquisas na área de TV Digital, IPTV e Redes Domésticas.

Nairon Saraiva Viana concluiu a graduação em Sistemas de Informação (Bacharel) pelo Instituto Federal do Piauí (IFPI) em 2006. Obteve o título de Mestre em Engenharia Elétrica na área de Controle e Automação de Sistemas pela Universidade Federal do Amazonas (UFAM) em 2009. É aluno do doutorado do programa de pós-graduação em Engenharia Elétrica da Universidade Federal de Minas

Gerais (UFMG). Atualmente desenvolve pesquisas na área de Engenharia de Software, Sistemas de Automação e Redes Domésticas.

Waldir Sabino da Silva Jr. concluiu a graduação em Engenharia Elétrica (Bacharel) pela UFAM em 2001. Obteve o título de Mestre e Doutor pela Universidade Federal do Rio de Janeiro (UFRJ) em 2004 e 2010. Desde 2006 é membro do Departamento de Engenharia Elétrica da UFAM. Atualmente desenvolve pesquisas na área de Telecomunicações, Compressão de Sinais, Morfologia

Matemática e Processamento de Sinais.

Vicente Ferreira de Lucena Jr. obteve o título de Doutor (Dr.-Ing) pela Universidade de Stuttgart em 2002. Desde 1990 é membro do Departamento de Engenharia Elétrica na Universidade Federal do Amazonas (UFAM). Desde 2003 possui um grupo de pesquisas localizado no CETELI. Atualmente desenvolve pesquisas na área de Desenvolvimento de Software Baseado em Componentes,

Sistemas de Automação Industrial, Técnicas de Reuso de Software e Desenvolvimento de Sistemas para TVDI.