Middleware Ginga. Jean Ribeiro Damasceno. Escola de Engenharia Universidade Federal Fluminense (UFF) Rua Passo da Pátria, 156 Niterói RJ Brasil

Middleware Ginga Jean Ribeiro Damasceno Escola de Engenharia Universidade Federal Fluminense (UFF) Rua Passo da Pátria, 156 Niterói RJ Brasil jeanrdmg@yahoo.com.br Abstract. The open middleware Ginga is an intermediate software layer, between the hardware/os and applications, which offers a range of facilities for the development of content and applications for Digital TV, hiding from them the complexity of mechanisms established by the communication protocols, operating system and hardware equipment. The middleware Ginga is divided into two main interconnected modules, which allow the development of applications following two different programming paradigms. These two modules are called Ginga-J (for procedural Java applications) and Ginga- NCL (for declarative NCL applications). Resumo. O middleware aberto Ginga é uma camada de software intermediária entre o hardware/so e as aplicações, que oferece uma série de facilidades para o desenvolvimento de conteúdo e aplicativos para TV Digital, escondendo dos mesmos a complexidade dos mecanismos definidos pelos protocolos de comunicação, do sistema operacional e do hardware do equipamento. O middleware Ginga é subdividido em dois módulos principais interligados, que permitem o desenvolvimento de aplicações seguindo dois paradigmas de programação diferentes. Esses dois módulos são chamados de Ginga-J (para aplicações procedurais Java) e Ginga-NCL (para aplicações declarativas NCL). 1. Introdução Ginga é o nome do middleware aberto do Sistema Brasileiro de TV Digital (SBTVD) [SBTVD 2008]. O nome foi escolhido em reconhecimento à cultura, arte e contínua luta por liberdade e igualdade do povo brasileiro. Ginga é a camada de software intermediário (middleware), entre o hardware/sistema Operacional e as aplicações, que oferece uma série de facilidades para o desenvolvimento de conteúdo e aplicativos para TV Digital, entre elas a possibilidade desses conteúdos serem exibidos nos mais diferentes sistemas de recepção, independente da plataforma de hardware do fabricante e tipo de receptor (TV, celular, PDAs etc.). As aplicações executadas sobre Ginga são classificadas em duas categorias, dependendo da forma em que elas são escritas. Aplicações procedurais são escritas usando a linguagem Java e aplicações declarativas são escritas usando linguagem NCL. O middleware aberto Ginga é subdividido em dois subsistemas principais interligados,

que permitem o desenvolvimento de aplicações seguindo os dois paradigmas de programação diferentes. Dependendo das funcionalidades requeridas no projeto de cada aplicação, um paradigma será mais adequado que o outro. Esses dois subsistemas são chamados de Ginga-J (para aplicações procedurais Java) e Ginga-NCL (para aplicações declarativas NCL). Todas as propostas de sistemas de Televisão Digital especificam middlewares sobre os quais as aplicações de TV Interativa podem ser executadas. Middleware é o neologismo criado para designar camadas de software que não constituem diretamente aplicações, mas que facilitam o uso de ambientes ricos em tecnologia da informação. A camada de middleware concentra serviços como identificação, autenticação, autorização, diretórios, certificados digitais e outras ferramentas para segurança [Leite 2003]. No contexto de TV Digital, o middleware vem a ser o software que controla suas principais facilidades (grade de programação, menus de opção), inclusive a possibilidade de execução de aplicações, dando suporte à interatividade [Leite 2003]. Uma das principais vantagens da chegada da TV digital ao país é a possibilidade de interatividade entre o usuário e a televisão. O usuário deixa de ter um papel passivo de telespectador e passa a ter um papel ativo, permitindo-lhe atuar com o programa transmitido, tomando ações que podem interferir na forma e no conteúdo exibidos na televisão. Abre-se um leque de possibilidades tais como compras através da TV, acesso à Internet, banco na TV, exibição de publicidade de forma personalizada, de acordo com preferências e características do usuário, dentro outros. Os middlewares possibilitam a execução de programas de televisão interativos nos Receptores Digitais ou Terminais de Acesso, escondendo dos mesmos a complexidade dos mecanismos definidos pelos protocolos de comunicação, do sistema operacional e do hardware do equipamento, para que o desenvolvimento das aplicações seja simplificado. Dessa forma, a padronização de uma camada de middleware permite a construção de aplicações independentes do hardware e do sistema operacional, executáveis em qualquer plataforma de qualquer fabricante, facilitando a portabilidade das aplicações, permitindo que sejam transportadas para qualquer receptor digital (ou set top box) que suporte o middleware adotado. Em comparação com os sistemas de middleware concebidos para os outros padrões de TV Digital, algumas das funcionalidades do Ginga são inovadoras, desenvolvidas especificamente para a realidade brasileira. No Brasil, o uso da TV como objeto de inclusão digital é prioridade do governo [Diário 2003]. Neste contexto, o desenvolvimento de aplicações interativas para TV Digital ocupa lugar de destaque. No caso especial do Brasil, é extremamente importante realçar que o middleware adotado no Sistema Brasileiro de Televisão Digital permite o desenvolvimento de programas mais adequados à realidade desse público. Realidade esta diferente daquela encontrada em outros países que já possuem seus Sistemas de Televisão Digital implantados há mais tempo. O middleware deve oferecer um bom suporte ao desenvolvimento de aplicações visando à inclusão social e digital da população brasileira, como aplicações para ensino, saúde etc. O restante do artigo está organizado da seguinte forma. A Seção 2 apresenta a arquitetura do Middleware Ginga, mostrando os seus três grandes módulos: o ambiente de apresentação Ginga-NCL (declarativo), o ambiente de execução Ginga-J (procedural)

e o Ginga-CC (Common Core). A Seção 3 dá uma visão geral dos middlewares adotados em outros sistemas de TV Digital. A Seção 4 faz uma comparação do middleware Ginga com os middlewares de outros sistemas de TV Digital. As considerações finais são apresentadas na Seção 5. 2. Arquitetura do Middleware Ginga Para o Sistema Brasileiro de TV Digital foi definido um middleware próprio, denominado Ginga. Diferentemente dos sistemas hipermídia convencionais, onde prevalece o modelo pull de serviço, isto é, onde cabe ao formatador solicitar um novo documento e buscar o conteúdo dos objetos, como ocorre, por exemplo, com navegadores web, em TV o modelo de serviço é do tipo push. Nesse caso, a emissora fornece por difusão fluxos de áudio e vídeo multiplexados com outros dados. Alguns objetos de mídia podem até ser recebidos por demanda, mas o serviço do tipo push é predominante. Além de inverter o paradigma do serviço, usuários podem começar a assistir um programa já iniciado. Mais ainda, usuários podem desejar trocar de canal, e conseqüentemente sair e entrar em programas já em andamento. Outro aspecto desafiador é a edição de documentos durante a exibição. Em programas ao vivo e programas modificados por retransmissoras, essa facilidade é bastante interessante. Semelhante a projetos de edificações, a melhor forma de lidar com um sistema complexo como é o caso de um sistema de TV digital interativa é através da representação de sua arquitetura. Uma arquitetura mostra os principais elementos de um sistema, explicitando suas interações e escondendo os detalhes menos importantes sob o ponto de vista adotado. Uma arquitetura de TV digital representando as camadas de tecnologias existentes é apresentada na Figura 1. Figura 1. Arquitetura de TV digital com tecnologias usadas em cada camada A figura 2 apresenta os padrões de referência do sistema brasileiro de TV digital terrestre, incluindo seu middleware de nome Ginga.

Figura 2. Padrões de referência do sistema brasileiro de TV digital A idéia central da arquitetura em camadas é cada uma oferecer serviços para a camada superior e usar os serviços oferecidos pela inferior. Dessa forma, as aplicações que executam na TV digital interativa usam uma camada de middleware, que intermedeia toda a comunicação entre a aplicação e o resto dos serviços oferecidos pelas camadas inferiores. A finalidade da camada de middleware ou camada do meio é oferecer um serviço padronizado para as aplicações (camada de cima), escondendo as peculiaridades e heterogeneidades das camadas inferiores (tecnologias de compressão, de transporte e de modulação) [Montez 2005]. O uso do middleware facilita a portabilidade das aplicações, permitindo que sejam transportadas para qualquer receptor digital (ou set top box) que suporte o middleware adotado. Essa portabilidade é primordial em sistemas de TV digital, pois é muito complicado considerar como premissa que todos os receptores digitais sejam exatamente iguais. Quando se busca os requisitos de um middleware, tendo por base as aplicações a serem desenvolvidas em um sistema de TV digital, quatro pontos chamam a atenção: Suporte à sincronização de mídias. - Sincronização baseada na estrutura. - Suporte a canal de retorno. Suporte a múltiplos dispositivos de exibição. Suporte ao desenvolvimento de programas ao vivo (em tempo de exibição). Suporte à adaptação do conteúdo e da forma como o conteúdo é exibido. No caso especial do Brasil, o middleware também oferece um bom suporte ao desenvolvimento de aplicações visando à inclusão social, como aplicações para ensino, saúde etc. A Figura 3 ilustra a penetração da TV nos domicílios brasileiros.

Figura 3. Importância da TV na Inclusão Social Com esses requisitos em foco, o universo das aplicações Ginga pode ser particionado em um conjunto de aplicações declarativas e um conjunto de aplicações procedurais. Para isso, o middleware Ginga é subdividido em dois subsistemas principais interligados, Ginga-J (para aplicações procedurais Java) e Ginga-NCL (para aplicações declarativas NCL). Dependendo das funcionalidades requeridas no projeto de cada aplicação, um paradigma de programação será mais adequado que o outro. As linguagens declarativas são mais intuitivas (de mais alto nível) e, por isso, mais fáceis de usar, normalmente não exigindo um perito programador. Contudo, as linguagens declarativas têm de ser definidas com um foco específico. Quando o foco da aplicação não casa com o da linguagem, o uso de uma linguagem procedural não é apenas vantajoso, mas se faz necessário. O uso de linguagens procedurais usualmente requer um perito em programação. Uma aplicação híbrida é aquela cujo conjunto de entidades possui tanto conteúdo do tipo declarativo quanto procedural. Uma aplicação, entretanto, não precisa ser puramente declarativa ou puramente procedural. Sem erro pode-se afirmar que, nos sistemas de TV digital, os dois tipos de aplicação coexistirão, sendo então conveniente que o dispositivo receptor integre o suporte aos dois tipos em seu middleware. Isso ocorre nos middlewares de todos os sistemas, incluindo o middleware Ginga. Em particular, as aplicações declarativas freqüentemente fazem uso de scripts, cujo conteúdo é de natureza procedural. Além disso, uma aplicação declarativa pode fazer referência a um código Java TV Xlet embutido. Da mesma forma, uma aplicação procedural pode fazer referência a uma aplicação declarativa, contendo, por exemplo, conteúdo gráfico, ou pode construir e iniciar a apresentação de aplicações com conteúdo declarativo. Portanto, ambos os tipos de aplicação Ginga podem utilizar as facilidades dos ambientes de aplicação declarativo e procedural.

A arquitetura da implementação de referência do middleware Ginga pode ser dividida em três grandes módulos: Ginga-CC (Common Core), o ambiente de apresentação Ginga-NCL (declarativo) e o ambiente de execução Ginga-J (procedural). A arquitetura do middleware GINGA está ilustrada na Figura 4. A arquitetura e as facilidades Ginga foram projetadas para serem aplicadas a sistemas de radiodifusão e receptores terrestres. Adicionalmente, a mesma arquitetura e facilidades podem ser aplicadas a sistemas que utilizam outros mecanismos de transporte de dados (como sistema de televisão via satélite ou a cabo). Figura 4. Arquitetura do middleware Ginga A Figura 5 apresenta um ambiente de execução comum às propostas de middleware para TV digital. O Ambiente apresenta uma Máquina de Execução para aplicações procedurais, uma Máquina de Apresentação para aplicações declarativas e Elementos-ponte, que fazem o mapeamento bidirecional entre objetos procedurais e declarativos. Figura 5. Arquitetura do ambiente de execução de aplicações para TV digital. Recomendações ITU-T J.2000.

2.1. Ginga NCL Ginga-NCL, ambiente obrigatório para receptores portáteis e fixos, é um subsistema lógico do sistema Ginga, responsável pelo processamento de documentos NCL. Um componente-chave do Ginga-NCL é a máquina de interpretação do conteúdo declarativo (formatador NCL). Outros módulos importantes são o exibidor (user agent) XHTML e a máquina de apresentação Lua, que é responsável pela interpretação dos scripts Lua [ABNT15606-5 2008]. A única linguagem declarativa que oferece suporte a todos os requisitos mencionados para um middleware é a linguagem NCL (Nested Context Language), desenvolvida no Laboratório TeleMídia da PUC-Rio [PUC-RIO 2008], e escolhida como base do Ginga. NCL é uma das principais linguagens existentes para a definição do sincronismo temporal. Como vantagem adicional, e imprescindível em um sistema de TV digital, NCL também provê suporte a variáveis, que podem ser manipuladas através de código procedural, entre eles o de sua linguagem de script Lua, quando há necessidade de alterações na lógica de programação. NCL foi concebida de forma modular. Módulos agrupam de modo coerente, elementos e atributos XML que possuam alguma relação semântica entre si. Essa estruturação permite que as funcionalidades da linguagem sejam reunidas de acordo com as necessidades de uma determinada aplicação. Sendo assim, um subconjunto das funcionalidades de NCL foi reunido para compor um perfil apropriado ao desenvolvimento de programas de TV não-lineares [Rodrigues 2006]. Lua, também desenvolvida no Departamento de Informática da PUC-Rio, constitui-se hoje em padrão internacional de fato na área de entretenimento, em especial jogos. Vários dos principais jogos lançados nos últimos anos utilizaram Lua em seu desenvolvimento. Lua é leve, fácil de usar e possui um altíssimo desempenho. Para facilitar o desenvolvimento de aplicações Ginga-NCL, a PUC-Rio desenvolveu também a ferramenta Composer [PUC-RIO 2008]. Composer é um ambiente de autoria voltado para a criação de programas NCL para TV digital interativa. Nessa ferramenta, as abstrações são definidas em diversos tipos de visões que permitem simular um tipo específico de edição (estrutural, temporal, leiaute e textual). Essas visões funcionam de maneira sincronizada, a fim de oferecer um ambiente integrado de autoria. 2.2. Ginga Java Ginga-J é uma especificação de middleware distribuído, que reside em um dispositivo Ginga (dispositivo que embarque o middleware Ginga um receptor de televisão digital), com possibilidade de possuir componentes de software nos dispositivos de interação (celulares, PDA etc). Um dos principais objetivos do Ginga é a interação com dispositivos portáteis. Mais do que apenas transmitir para esses dispositivos o Ginga-J deve também ser capaz de receber e interpretar os dados dos celulares, PDAs, controles, etc, para que haja interação com o usuário. A Figura 6 apresenta o contexto em que a pilha do software Ginga-J é executada, que também é válido para Ginga-NCL.

Figura 6. Contexto do Ginga O dispositivo Ginga deve ter acesso a fluxos de áudio, vídeo, dados e outros recursos de mídia, que devem ser transmitidos através do ar, cabo, satélite ou através de redes IP. As informações recebidas devem ser processadas e apresentadas aos telespectadores. O telespectador pode interagir com o dispositivo Ginga através de dispositivos de interação que podem conter componentes de software Ginga de forma que o dispositivo de interação possa enviar informações para o dispositivo Ginga utilizando as funcionalidades providas na especificação Ginga. Estes componentes de softwar, que podem ser instalados nos dispositivos de interação, permitem que as funcionalidades dos mesmos sejam exploradas, utilizando funcionalidades da API Ginga-J, por aplicações nos dispositivos Ginga (receptores de televisão digital). Para que um dispositivo de interação possa ser utilizado, ele deve estar registrado com o dispositivo Ginga, e durante esse processo o dispositivo de interação pode receber o componente de software necessário para viabilizar a comunicação com o dispositivo Ginga. Como resposta à informação enviada pelo telespectador, o dispositivo de Ginga deve apresentar a saída de vídeo e áudio utilizando seu próprio monitor e alto-falantes ou os dos dispositivos de interação. Um único dispositivo pode ter capacidade de entrada e saída simultâneas. Por exemplo, um dispositivo de interação pode ser um PDA conectado à plataforma Ginga através de uma rede sem fio. Utilizando tal dispositivo de interação, um telespectador pode enviar comandos (eventos de usuário) à plataforma através do teclado do PDA e os aplicativos da plataforma podem enviar conteúdo visual para ser apresentado na tela do PDA. Um dispositivo de interação pode também ter capacidades de captura e reprodução de som, de forma que o telespectador possa enviar fluxos de áudio e vídeo para o dispositivo Ginga, utilizando os dispositivos de interação que dêem suporte a essa funcionalidade. Vários telespectadores podem interagir com a plataforma Ginga simultaneamente. Nesse caso, cada telespectador pode ter um dispositivo de interação e a plataforma deve distinguir os comandos enviados por e para cada dispositivo. O dispositivo Ginga pode também enviar informações para os transmissores de conteúdo quando da existência de um canal de retorno (conexão com a Internet, por exemplo).

Um componente-chave do ambiente de aplicação Ginga-J (procedural) é a máquina de execução do conteúdo procedural, composta por uma máquina virtual Java. Através da máquina virtual Java é possível que aplicações desenvolvidas na linguagem Java possam ser executadas no terminal de acesso. Vale lembrar que o Ginga-J não é mandatário para todos os perfis de terminais de acesso. Para dispositivos móveis, tais como celulares, não está prevista a obrigatoriedade da existência deste subsistema. Isso implica que aplicações Java podem não ser executadas em dispositivos móveis (devido aos seus recursos limitados). Esse ponto deve ser levado em consideração pelos produtores de conteúdo. A definição Ginga-J é composta por API (Interfaces de Programação de Aplicativos) projetadas para suprir todas as funcionalidades necessárias para a implementação de aplicativos para televisão digital, desde a manipulação de dados multimídia até protocolos de acesso. O subsistema foi construído para garantir a compatibilidade com o padrão GEM (Globally Executable MHP) [GEM 2002]. O GEM trata-se de uma série de APIs padronizadas pelo ITU. Para que um middleware seja compatível com o padrão GEM este deverá implementar as APIs especificadas pelo GEM. O Ginga-J foi construído de forma a ser compatível com o padrão GEM, embora possua um conjunto de APIs específicas para o SBTVD. Desta forma é possível a construção de aplicações que possam ser executadas no middleware, desde que estas utilizem o conjunto de APIs especificadas pelo GEM. Estas aplicações podem ser testadas através do uso de emuladores disponíveis sob domínio público, tais como OpenMHP e XletView. Testes efetivos de aplicações feitas em Java ainda não podem ser executadas no middleware disponível, já que o Ginga-J ainda não foi disponibilizado, até o momento da escrita deste texto. O ambiente de execução Ginga-J, desenvolvido no Laboratório LAVID da UFPB [LAVID 2008], utiliza a linguagem Java e é dividido em três partes: as APIs vermelhas, inovações que dão suporte às aplicações brasileiras, em especial as de inclusão social; as APIs amarelas, também inovações brasileiras, mas que podem ser exportadas para os outros sistemas; e as APIs verdes, que seguem o núcleo comum do padrão GEM [GEM 2002]. As APIs são mostradas na figura 7. Figura 7. Ginga-J. APIs vermelha, amarela e verde do Ginga-J [ISDTV-T 2006].

O modelo Ginga-J distingue entre as entidades e recursos de hardware, software do sistema e aplicativos conforme descrito na Figura 8 [ABNT/CEET 2007]. Figura 8. Arquitetura Ginga-J e ambiente de execução As aplicações residentes podem ser implementadas usando funções não padronizadas, fornecidas pelo Sistema Operacional do dispositivo de Ginga, ou por uma implementação particular do Ginga. Os aplicativos residentes também podem incorporar funcionalidades providas pelas API padronizadas Ginga-J. Aplicativos transmitidos (Xlets) sempre devem utilizar API padronizadas fornecidas pelo Ginga-J. No desenvolvimento de um middleware é necessário que haja uma máquina virtual Java em execução no terminal de acesso e mecanismos que permitam à máquina virtual Java enviar dados a serem exibidos pela placa gráfica, além de acesso aos recursos do hardware, através de chamadas específicas do sistema operacional no qual o middleware estará embarcado. Um ponto observado é a inexistência clara das fronteiras entre o sistema operacional e o middleware. Não existe uma padronização de quais APIs o sistema operacional deve fornecer ao middleware. Isso gera alguns problemas, como uma forte dependência entre o middleware e o sistema operacional. A separação em camadas independentes seria interessante para que o middleware possa ser executado de forma independente da plataforma de hardware. 2.3. Ginga Common Core O núcleo comum Ginga (Ginga Common Core) concentra serviços necessários tanto para a máquina de apresentação (declarativo) quanto para a máquina de execução (procedural). Esse subsistema faz a interface direta com o sistema operacional, fazendo uma ponte estreita com o hardware. É nele onde é feito o acesso ao sintonizador de canal, ao sistema de arquivos, terminal gráfico, dentre outros. É composto pelos decodificadores de conteúdo comuns e por procedimentos para obter conteúdos transportados em fluxos de transporte (transport streams) MPEG- 2 e através do canal de interatividade. Decodificadores de conteúdo comuns servem

tanto às aplicações procedurais quanto às declarativas que necessitam decodificar e apresentar tipos comuns de conteúdo como PNG, JPEG, MPEG e outros formatos. O núcleo comum Ginga também deve obrigatoriamente suportar o modelo conceitual de exibição, conforme descrito na ABNT NBR 15606-1. A Figura 9 mostra os componentes básicos do Common Core, descritos a seguir. Figura 9. Ginga Common Core Sintonizador: É o módulo responsável por sintonizar o canal, escolhendo um canal físico e um dos fluxos de transporte que estão sendo enviados neste canal. Filtro de Seções: Uma vez sintonizado, o middleware deve ser capaz de acessar partes específicas do fluxo de transporte. Para isso, existe o Filtro de Seção, ele é capaz de buscar no fluxo a parte exata que as APIs necessitam para suas execuções. Funcionando exatamente como um filtro, deixando passar apenas as informações requeridas pela API. Processador de Dados: É o elemento responsável por acessar, processar e repassar os dados recebidos pela camada física. Ele também fica encarregado de notificar os outros componentes, sobre qualquer evento que tenha sido recebido. Persistência: O Ginga é capaz de salvar arquivos, mesmo depois do processo que o criou tenha sido finalizado, para que este possa ser aberto em outra oportunidade. Este é o módulo que dá suporte para que isso ocorra. Iniciador de Aplicações: Este módulo é o gerenciador de aplicações, ou seja, ele fica responsável por carregar, configurar, inicializar e executar qualquer aplicação dos ambientes declarativos e procedurais. Ele também é responsável por controlar o ciclo de vida dessas aplicações, retirando-as quando necessário, além de controlar os recursos utilizados por essas APIs. Adaptador do A/V Principal: Com o Adaptador de A/V Principal, as aplicações conseguem enxergar o fluxo de áudio e vídeo. Isso se faz necessário quando uma aplicação precisa controlar suas ações, de acordo com o que está sendo transmitido. Gerenciador de Gráfico: Os padrões de middleware definem como as imagens, vídeos, dados, etc, são apresentados para os usuário, gerenciando as apresentações da mesma forma que é definida no padrão ARIB [ARIB B-24, 2004].

Gerenciador de Atualizações: Componente que gerencia as atualizações feitas no sistema, verificando, baixando e atualizando o middleware sempre que necessário, para correção de possíveis erros encontrados em versões anteriores. Isto deve ser feito em tempo de execução, sem incomodar o uso normal da TV pelo usuário. Exibidor de Mídia: São as ferramentas necessárias para exibir os arquivos de mídias recebidos, como por exemplo, os tipos MPEG, JPEG, TXT, MP3, GIF, HTML, etc. Interface com o Usuário: Este módulo é responsável por captar e interpretar os eventos gerados pelo usuário, tais como, comandos do controle remoto e avisar aos outros módulos interessados. Gerenciamento de Contexto: É o responsável por capturar as preferências do usuário, alertando os outros componentes interessados nessas preferências. Essas informações podem ser os horários em que o usuário assiste a TV, ou bloqueio e desbloqueio de canais, entre outras. Canal de Retorno: Ele provê a interface das camadas superiores com o canal de interação (ou canal de retorno). Além disso, ele deve gerenciar o canal de retorno de forma que dados sejam transmitidos assim que o canal esteja disponível, ou forçar a transmissão caso o usuário ou uma aplicação tenha definido o horário exato. Acesso Condicional: Este componente está encarregado de restringir conteúdos inapropriados recebidos pelos canais de programação, oferecendo assim segurança ao middleware. 3. Middlewares Adotados em outros Sistemas de TV Digital Buscando evitar uma proliferação de padrões de middleware, os principais sistemas existentes de TV digital, terrestre norte-americano, europeu e japonês adotam um padrão de middleware em seus receptores digitais. Os diferentes middlewares embora com características específicas, seguem recomendações do padrão GEM (ITU-T J.201) (ITU-T, 2001). 3.1. MHP Multimedia Home Platform A comunidade que desenvolve as tecnologias para TV digital percebeu, há algum tempo, que provedores de serviços não teriam sucesso comercial se tivessem que desenvolver serviços interativos que não fossem portáveis em set top boxes de diferentes fabricantes. Em 1997 o grupo DVB começou a especificar uma camada de middleware, que deu origem à plataforma MHP em junho de 2000 [ETSI TS 102 B12 2004], primeiro padrão aberto para televisão interativa. Um ano após a primeira versão, em abril de 2001, foi lançada a especificação MHP 1.1. O MHP busca oferecer um ambiente de TV interativa, independente de hardware e software específicos, aberto e interoperável, para receptores e set top boxes de TV digital. Seu ambiente de execução é baseado no uso de uma máquina virtual Java e um conjunto de interfaces de programação de aplicações (APIs). Essas APIs possibilitam aos programas escritos em Java o acesso a recursos e facilidades do

receptor digital de forma padronizada. Uma aplicação DVB usando API Java é denominada aplicação DVB-J. Além do uso da API Java, o MHP 1.1 introduziu a possibilidade de usar uma linguagem de programação semelhante ao HTML (empregada na internet para programação das páginas web), denominada DVB-HTML. Aplicações DVB-J e DVB-HTML possuem a capacidade de: carregar (download), através de um canal de interatividade, aplicações interativas; armazenar aplicações em memória persistente (disco rígido, por exemplo); acessar leitores de smart cards; controlar aplicações de internet, tais como navegador web e leitor de e-mail. Além do MHP, o MHEG-5 (padrão ISO/IEC 13522-5) é adotado na camada de middleware no DVB-T. O MHEG é um padrão usado para representar apresentações multimídia, permitindo interatividade do usuário com o conteúdo da apresentação. No caso da TV digital, o MHEG-5 pode ser usado para representar um guia de programação eletrônico (EPG), por exemplo. A especificação do MHP herdou uma série de características que já existiam no MHEG, tal como o uso de carrossel. Atualmente existe um esforço conjunto para que as especificações de ambos os padrões possam coexistir em uma mesma TV digital. A Figura 10 ilustra o padrão europeu DVB. Figura 10. O padrão de televisão digital DVB MHP 3.2. DASE DTV Application Software Environment O DASE foi desenvolvido pelo ATSC como um padrão norte-americano para a camada de middleware em set top boxes de TVs digitais [DASE 2003]. De forma similar ao MHP, o DASE adota uma máquina virtual Java como mecanismo que facilita a execução de aplicações que permitem interatividade. Também de forma similar ao

MHP, o DASE permite o uso de linguagens declarativas, usadas na web, como HTML e JavaScript. As semelhanças entre esses dois padrões param neste ponto. Os middlewares MHP e DASE não foram projetados para serem compatíveis entre si. Isto significa que um serviço desenvolvido para um desses padrões não irá funcionar com o outro. A Figura 11 apresenta a arquitetura em camadas do Padrão ATSC. Figura 11. O padrão de televisão digital ATSC DASE O DASE está sendo substituído pelo ACAP (Advanced Common Application Platform) e OCAP (OpenCable Applications Platform), nos EUA para transmissões a Cabo e Satélite, para melhor compatibilidade com os demais padrões em uso. O ACAP é o resultado da harmonização dos padrões de middleware OCAP do CableLabs, e DASE, do ATSC, que assegura compatibilidade entre as transmissões por cabo e terrestres. Assim como o OCAP, o ACAP é derivado do padrão MHP por meio da especificação GEM. O OCAP é voltado para as plataformas de TV a cabo, e o principal objetivo de sua especificação é permitir que as aplicações sejam executadas em qualquer sistema dos EUA. 3.3. ARIB Association of Radio Industries and Businesses O middleware do ISDB (Integrated Services Digital Broadcasting) é padronizado pela organização japonesa ARIB. Esse middleware é formado por alguns padrões, como o ARIB STD-B24 (Data Coding and Transmission Specification for Digital Broadcasting) que define uma linguagem declarativa denominada BML (Broadcast Markup Language) [ARIB B-24, 2004]. Essa linguagem, baseada na linguagem padrão de serviços web XML (Extensible Markup Language), é usada para especificação de serviços multimídia para TV digital. Outra especificação do middleware é o ARIB-STD B23 (Application Execution Engine Platform for Digital Broadcasting), que é baseada na especificação DVB-MHP. Esse último padrão traduz uma tendência do ARIB de tentar estabelecer um núcleo comum entre o seu padrão de middleware, o MHP e o DASE. A Figura 12 ilustra o padrão japonês ISDB.

Figura 12. O padrão de televisão digital ISDB ARIB 3.4. GEM Globally Executable MHP O GEM foi proposto, inicialmente, para que as aplicações MHP pudessem ser utilizadas sobre as plataformas do middleware dos EUA (CableLabs) e do Japão (ARIB). O GEM é considerado um acordo de harmonização. Isso porque, além de capturar as interfaces e toda a semântica definidas pelo MHP (independentes da plataforma DVB), o GEM inclui as necessidades impostas por outros padrões internacionais [GEM 2002]. A CableLabs participou da composição da primeira versão do GEM, para tornar compatível seu middleware para a TV a cabo americana, o OCAP. E, mais recentemente, o middleware japonês ARIB e o canditado a padrão americano ACAP também tiveram suas necessidades de harmonização com o GEM concluídas e podem, dessa forma, ser classificados como padrões compatíveis com o GEM. Formalmente, o GEM por si só não pode ser considerado uma especificação completa para terminais de acesso. O correto é dizer que GEM é um framework a partir do qual um terminal de acesso pode ser implementado, ou ainda, que o GEM é um padrão ao qual implementações existentes devem se adaptar para obter uma conformidade que garante a execução global de aplicações. O padrão define, portanto, um conjunto de APIs, garantias semânticas, protocolos e formatos de conteúdo com os quais as aplicações (agora globalmente interoperáveis) podem contar para a constituição de serviços interativos, executáveis em qualquer plataforma definida pelos padrões internacionais compatíveis. Por definir um framework baseado no padrão MHP, o documento de especificação do GEM é na realidade uma listagem de referências a outros documentos do consórcio DVB e salienta aquelas que devem ser substituídas de acordo com a infraestrutura de implementação das novas especificações compatíveis. Esses pontos de flexibilização do GEM devem ser, então, preenchidos por equivalentes funcionais mecanismos que lançam mão de outras tecnologias (definidas pelas respectivas organizações de TV digital) para implementar uma funcionalidade análoga àquela proposta pelo DVB. Tais tecnologias passam a ser qualificadas como equivalentes

funcionais somente após negociações entre o consórcio DVB e cada uma das organizações que requisitam a conformidade com o GEM. No GEM, diferente do DVB, são definidos apenas os dois primeiros perfis: o Enhanced Broadcast e o Interactive Broadcast. A Figura 13 mostra o GEM e a sua relação com middlewares de outros padrões de TV Digital. Figura 13. O GEM e a relação com middlewares de outros padrões de TV Digital 4. Comparação do Middleware Ginga com os Middlewares adotados em outros Sistemas de TV Digital Praticamente todos os middleware para TV digital terrestre oferecem suporte para o desenvolvimento de aplicações usando os dois paradigmas de programação, procedural e declarativo. Alguns middlewares só oferecem o suporte para aplicações declarativas (puras ou híbridas). Outros informalmente oferecem o suporte apenas a aplicações nãodeclarativas. A maioria dos middlewares, no entanto, são compostos dos ambientes procedurais e declarativos. Os middlewares declarativos dos sistemas de TV digital europeu (DVB-HTML), americano (ACAP-X) e japonês (BML) possuem, cada um, a implementação de uma máquina de apresentação para controle de suas aplicações declarativas. Na realidade essas máquinas de apresentação são navegadores XHTML. Isso traz alguns problemas: o modelo conceitual do HTML é extremamente simples, e está centrado na interatividade com o usuário, privilegiando a interatividade em detrimento da sincronização e adaptabilidade de conteúdo. A sincronização e adaptabilidade são realizadas através de scripts procedurais (ECMA-Scripts). O middleware Ginga busca suprir essa deficiência, introduzindo uma nova linguagem (NCL), capaz de prover mecanismos de adaptabilidade e sincronização de forma declarativa, sem a necessidade de scripts procedurais, como ocorre em outros middlewares.

A tabela 1 ilustra os ambientes dos middlewares dos sistemas americano, europeu, japonês e brasileiro para receptores fixos e móveis. Tabela 1. Ambientes de aplicações para receptores fixos e móveis Middleware Sistema de TVD Ambiente Declarativo Ambiente Procedural ACAP Americano/ATSC ACAP-X [ATSC A-101 2005] (linguagem declarativa = XHTML) like; linguagem não-declarativa = ECMAScript) ACAP-J [ATSC A-101 2005] (linguagem procedural = Java) MHP Europeu/DVB-T DVB-HTML [ETSI TS 102 8121 V1.2.2, 2006] (linguagem declarativa = XHTML like; linguagem não-declarativa = ECMAScript) ARIB-BML Japonês/ISDB-T ARIB BML [ARIB B-24 2004] (linguagem declarativa = BML (XHTML like; linguagem nãodeclativa= ECMAScript) Ginga Brasileiro/SBTV Ginga-NCL [ABNT NBR 15606-2 2007] (linguagem declarativa = NCL; linguagem não declarativa = Lua) MHP [ETSI TS 102 812 V1.2.2, 2006] (linguagem procedural = Java) Opcional (GEM [ETSI TS 102 819 V1.3.1 2005] like); não implementado) Ginga-J (Linguagem procedural = Java) A tabela 2 ilustra os ambientes dos middlewares dos sistemas japonês e brasileiro para receptores portáteis. Tabela 2. Ambientes de aplicações para receptores portáteis Middleware Sistema de TVD Ambiente Declarativo Ambiente Procedural ARIB-BML Japonês/ISDB-T ARIB-BML [ARIB B-24 2004] X (linguagem declarativa = BML (XHTML like; linguagem nãodeclarativa = ECMAScript) Ginga Brasileiro/SBTVD Ginga-NCL [ABNT NBR 15606-5 2007] (linguagem declarativa = NCL; linguagem não-declarativa = Lua) Opcional o Ginga-J Diferente dos outros sistemas, os ambientes de apresentação e execução do middleware Ginga se complementam, unidos por uma ponte em uma implementação sem nenhuma redundância, o que confere ao sistema uma ótima eficiência, tanto em termos de uso de CPU quanto de ocupação de memória. Ao contrário dos outros sistemas, Ginga, desde seu projeto inicial, foi desenvolvido tendo em mente os dois ambientes de programação. Podem-se levantar aspectos pontuais nos quais existem divergências entre os padrões de middleware. Por exemplo, para se adicionar novas funcionalidades ao middleware DASE é necessário o acréscimo de novos interpretadores para diferentes aplicações. Dependendo do tipo de aplicação (declarativa ou procedural) para o qual o interpretador foi projetado, o mesmo será alocado no respectivo ambiente de execução. Já no MHP, os interpretadores são chamados de plug-ins e têm funcionalidade análoga a dos interpretadores do DASE, podendo ser alocados em diferentes ambientes de execução. No ARIB, por sua vez, apenas plug-ins relacionados a aplicações procedurais podem ser adicionados ao middleware, pois o mesmo trabalha com a forma declarativa exclusivamente através da linguagem BML (Broadband Markup Language).

A definição de perfis de plataforma também apresenta diferenças. O perfil Enhanced Broadcast do MHP corresponde ao DASE nível 1, ambos sem canal de retorno e destinados apenas à difusão de TV digital. O DASE nível 2 inclui suporte para critérios de segurança e pequenas condições de interatividade, enquanto o perfil Interactive Broadcast do MHP possui boa interatividade, disponibilizando o suporte ao protocolo IP sobre o canal de retorno. O DASE nível 3 e o perfil Internet Access do MHP têm como foco a interatividade e a integração com a Internet, necessitando, como conseqüência, de um maior poder de processamento (processadores e memória) nos terminais de acesso. O middleware ARIB não entra em detalhes sobre perfis em suas especificações disponíveis, mas sabe-se que existem perfis que definem como se dá apresentação de aplicações nos terminais de acesso. Perfis de apresentação especificam a forma de exibição de aplicações para os usuários, considerando restrições como mobilidade e tipo de display. Para a adaptação correta de perfis, o ARIB define padrões de conformidade que se prendem aos tipos de funcionalidades que cada classe de hardware pode ter. O sistema ACAP, por sua vez, define os perfis ACAP-X only e ACAP-X & ACAP-J, que, em conformidade com o GEM, são equivalentes funcionais aos perfis do MHP. O Ginga-NCL foi desenvolvido de forma modular, possuindo perfis (profiles) tanto para dispositivos fixos quanto para portáteis. Por enquanto, existem apenas implementações protótipos para dispositivos portáteis. A BML e o Ginga-NCL parecem ser, atualmente, os mais apropriados para servirem de middleware em dispositivos portáteis. Ambos oferecem profiles diferenciados, visando especificamente esse contexto. A NCL, se comparada a BML, é mais apropriada para o desenvolvimento de aplicações hipermídia e, principalmente, de TV Digital. Isso porque têm foco no sincronismo e adaptabilidade, fatores importantes no desenvolvimento de aplicações de TV Digital. A BML é baseada em XHTML e tem foco declarativo apenas na interatividade. 5. Conclusão Este trabalho apresentou as principais características do middleware aberto Ginga, que é o padrão de middleware do Sistema Brasileiro de TV Digital. A finalidade da camada de middleware é oferecer um serviço padronizado para as aplicações, escondendo as peculiaridades e heterogeneidades das camadas inferiores, oferecendo uma série de facilidades para o desenvolvimento de conteúdo e aplicativos para TV Digital independente da plataforma de hardware do fabricante e tipo de receptor, facilitando a portabilidade das aplicações. O Ginga dá suporte às aplicações declarativas e procedurais, sendo compatível com as definições internacionais ITU. Ao integrar tanto com Ginga-J quanto com o Ginga-NCL, oferece-se ao desenvolvedor da aplicação de TV digital a possibilidade de trabalhar tanto com uma linguagem procedural quanto com uma linguagem declarativa. Desta forma, pode-se utilizar o que for mais adequado para determinada situação. Tanto o ambiente declarativo quanto o procedural de um middleware deve dar suporte a sincronização de mídias, suporte a múltiplos dispositivos de exibição, suporte ao desenvolvimento de programas ao vivo (em tempo de exibição), suporte à adaptação do

conteúdo e da forma como o conteúdo é exibido. Todos os middlewares que apresentam os dois ambientes de programação permitem que cada um deles use as facilidades do outro por meio de uma ponte definida através de APIs bilaterais padronizadas. O middleware necessita apresentar alinhamento com padrões internacionais, de forma a possibilitar a exportação do conteúdo televisivo produzido no país, bem como a exibição de conteúdo produzido por outros países nos televisores do Brasil, promovendo, dessa forma, o desenvolvimento econômico e o intercâmbio cultural no país. Visando promover a compatibilidade do Ginga com os middlewares de outros Sistemas de Televisão Digital e, dessa forma, possibilitar o intercâmbio de conteúdo televisivo entre os países que adotam tais sistemas, o Ginga segue o framework GEM (Globally Executable MHP). O framework GEM é adotado pelos middlewares dos principais sistemas de televisão digital atuais, como é o caso do ACAP (americano), ARIB (japonês) e MHP (europeu). A grande vantagem da adoção de um middleware nacional (Ginga), além de torná-lo o mais adequado possível à realidade brasileira, é justamente fortalecer a indústria nacional de software. Com a massificação da interatividade, a indústria nacional de software poderá ter escala para produzir aplicativos de qualidade. Como o middleware brasileiro é intercambiável com os demais middlewares internacionais (graças a um conjunto de especificações GEM), a partir da escala interna, a indústria brasileira de software poderá inclusive exportar seu conteúdo. 6. Referências ABNT NBR 15606-2 (2007) Associação Brasileira de Normas Técnicas, Televisão digital terrestre Codificação de dados e especificações de transmissão para radiodifusão digital Parte 2: Ginga-NCL para receptores fixos e móveis Linguagem de aplicação XML para codificação de aplicações, Sistema Brasileiro de TV Digital Terrestre, NBR 15606-2. ABNT NBR 15606-5 (2007) Associação Brasileira de Normas Técnicas. Televisão digital terrestre Codificação de dados e especificações de transmissão para radiodifusão digital - Parte 5: Ginga-NCL para receptores portáteis Linguagem de aplicação XML para codificação de aplicações, Sistema Brasileiro de TV Digital Terrestre, NBR 15606-5. ABNT NBR 15606-5 (2008) Associação Brasileira de Normas Técnicas. Televisão digital terrestre Codificação de dados e especificações de transmissão para radiodifusão digital - Parte 5: Ginga-NCL para receptores portáteis Linguagem de aplicação XML para codificação de aplicações. ABNT/CEET (2007) Televisão digital terrestre - Codificação de dados e especificações de transmissão para transmissão digital Parte 4: Ginga-J - Ambiente para a execução de aplicações procedurais. ARIB B-24 (2004) - Terrestrial Integrated Services Digital Broadcasting, XML-based Multimedia Coding Scheme, ARIB Standard b-24 Data Coding and Transmission Specifications for Digital Broadcasting, version 1.0 ATSC A-101 (2005) Advanced Television Systems Committee Advanced Application Platform (ACAP), ATSC Standard: Document A/101, Washington, D.C., Agosto.

DASE (2003) DTV Application Software Environment - ATSC Standard A/100. Março. Diário Oficial da União. Decreto-lei 4.901, de 26 de novembro de 2003. Institui o Sistema Brasileiro de Televisão Digital SBTVD, e dá outras providencias. Diário Oficial da República Federativa do Brasil, Brasília, 27 de nov. 2003. Seção 1, Pág. 7. ETSI TS 102 B12 (2005) European Telecommunications Standards Institute. Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1.1, Especificação Técnica ETSI TS 102 B12, maio. ETSI TS 102 812 V1.2.2 (2006) Digital Video Broadcasting Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1.1 European Telecommunications Standards Institute, TS 102 812 V1.2.2. ETSI TS 102 819 V1.3.1 (2005) Digital Video Broadcasting (DVB) Globally Executable MHP (GEM) Specication 1.0.2. European Telecommunications Standards Institute, TS 102 819 V1.3.1. GEM (2002) ETSI European Telecommunicaions Standards Institute. Globally Executable MHP (GEM). TS 102 819, Novembro. ISDTV-T Forum. (2006) Volume 4 of ISDTV-T Standard 06. ISDTV-T Forum Draft, December. ITU-T Recommendation X.509 (2001) ISO/IEC 9594-8: 2001, Information technology Open Systems Interconnection Public-Key and Attribute Certificate Frameworks. LAVID (2008) Laboratório LAVID da UFPB <http://www.lavid.ufpb.br/> Acesso em: 23 de novembro de 2008. Leite, L.E.C., Batista, C.E.C., Filho, G.L.S., Kulesza, R., Alves, L.G.P., Bressan, G., Rodrigues, R.F., Soares, L.F.G. (2003) FlexTV Uma Proposta de Arquitetura de Middleware para o Sistema Brasileiro de TV Digital. Revista de Engenharia de Computação e Sistemas Digitais, Disponível em: <http://www.pcs.poli.usp.br/revista/>acesso em: 23 de novembro de 2008. Montez, C. and Becker, V. (2005) TV Digital Interativa: conceitos, desafios e perspectivas para o Brasil. Florianópolis: Ed. da UFSC, 2ª edição. PUC-RIO (2008) <http://www.ncl.org.br/> Acesso em: 23 de novembro de 2008. Rodrigues, R.F. and Soares, L.F.G. (2006) Produção de Conteúdo Declarativo para TV Digital Rogério Ferreira Rodrigues. XXXIII Seminário Integrado de Software e Hardware Semish 2006. SBTVD (2008) Sistema Brasileiro de TV Digital <http://sbtvd.cpqd.com.br/> Acesso em: 13 de dezembro de 2008.