• PT
  • EN
  • ES

Fórum SBTVD

Da primeira patente no final do século XIX de um sistema de televisão eletro-mecânico por Paul Nipkow, até a primeira patente do sistema totalmente elétrico no início do século XX, muita coisa mudou e muita ainda vai mudar.
As técnicas digitais, até pouco tempo exclusivas dos computadores, têm permeado uma série de produtos cada vez mais suis generis e se apresentado como uma das mais irreversíveis realidades contemporâneas. De liquidificadores a aviões, os microprocessadores são “cérebros” que dão inteligência aos aparelhos e os tornam aptos a oferecer ao usuário facilidades e informações. Por conta disso, as técnicas computacionais têm permitido mudanças bastante perceptíveis nos produtos, além de outras ainda não tão evidentes. Este salto tecnológico faz chegar ao mercado avanços há poucos anos inimagináveis, fazendo repetir o ciclo evolutivo do consumo tecnológico, trazendo a reboque novos acrônimos que rapidamente passam a fazer parte do vocabulário cotidiano. Produtos tais como DVD, LCD, DLP, PDP, telefone celular TDMA, CDMA, GSM, 3-G, MP3, iPod, redes sem fio, mídia center, AC-3, DTS, entre uma infi- nidade de outros tornam a vida cotidiana quase que impossível sem o acesso a estas maravilhas tecnológicas.
A televisão, que por décadas tem tido uma presença vigorosa como meio de comunicação social e, por isso mesmo, é um produto altamente massificado e de maior penetração nos lares, não poderia ficar de fora desta festa. Com a superposição da informática e das telecomunicações o campo de atuação da televisão adquire uma enorme diversificação. Com referencial de qualidade de imagem seis vezes superior ao atual sistema e no mínimo quatro vezes superior ao tradicional DVD, mais do que uma mera evolução da televisão analógica a TV digital, além de imagens e som extraordinários, traz a possibilidade de interação com o cidadão. Novos serviços até então desconhecidos podem ser oferecidos e tudo a um clique de distância, esteja ele onde estiver: em casa, no trabalho, no carro, no metrô, no celular… Uma nova era em que o televisor passa a ser a via de acesso à auto-estrada da informação, assegurando ao telespectador fácil acesso a toda esta tecnologia pela facilidade na recepção de televisão terrestre. O receptor de televisão deixa de ser um elemento passivo que sempre tratou de um sistema “simples” de receber imagens transmitidas de uma câmera de vídeo, para se tornar uma nova plataforma de comunicações com impactos na sociedade ainda não completamente delineados. Um verdadeiro terminal para interagir com o mundo, cuja maneira de acessar informações muda muito e decreta o fim da televisão como hoje conhecemos.
Um século de acelerada evolução tecnológica da televisão se passou desde as primeiras invenções, mas a era da informação está apenas começando, já que quando o tema é televisão digital, certamente a palavra mais apropriada é convergência.
Com a TV digital, as possibilidades que se abrem são fantásticas e três são, pelo menos, as principais vantagens. A mais óbvia é a excelente recepção de som e imagem.
A interatividade é, provavelmente, a mudança mais notável. As emissoras de televisão vêm estimulando a interatividade há mais de uma década por meio do telefone ou internet, mas, com a TV digital, é possível interagir com a programação e acessar uma inimaginável variedade serviços, tais como; e-government, tbanking, t-commerce, empunhando apenas o controle remoto e tudo se resolve em apenas um clique.
Por último, mas não por fim, a portabilidade é uma das maiores conquistas por permitir aos cidadãos – sem o hábito da leitura em ônibus superlotados, aos solavancos por ruas esburacadas – ter acesso às informações durante a ida e volta do trabalho. Aqui cabe esclarecer um equívoco bastante comum. Por dispositivos portáteis devem ser entendidos os aparelhos conhecidos como handheld (Celular, PDA e etc.) especialmente recomendados para telas pequenas para resolução de perfil básico, que, via de regra, são alimentados por uma bateria interna, enquanto os móveis são geralmente os dispositivos embarcados em veículos automotores que podem receber sinais tanto de alta definição como de perfil básico.
Ao considerar todos estes aspectos, é fácil concluir que as possibilidades para as especificações dos receptores são muitas. Adicione a isto um grupo formado por atores (stakeholders) muito heterogêneo com interesses conflituosos, e, por fim, acrescente que as especificações dos receptores devem permear todas as demais do SBTVD e, portanto, demandam negociação e harmonização, nem sempre fáceis com outros grupos, numa escala superior à das demais normas do sistema. Como resultado é mais fácil ainda imaginar que os trabalhos não foram muito tranqüilos e alguns dos maiores desa- fios foi e continua sendo a constante negociação e harmonização de interesses e a pressão de um cronograma apertado para o desenvolvimento de produtos capazes de atender o lançamento da TV digital.
O Decreto Presidencial 5820 estabeleceu que o Sistema Brasileiro de TV Digital Terrestre (SBTVD) deve adotar como base o modelo ISDB-T, incorporando as inovações tecnológicas aprovadas pelo Comitê de Desenvolvimento. Neste caso é importante conceituar corretamente sistema e padrão. Sistema é o conjunto de padrões tecnológicos que compõem harmonicamente o sistema de TV digital, enquanto que padrões geralmente demandam anos, senão décadas para serem desenvolvidos e testados, o que requer altíssimos investimentos.
Assim, as especificações dos receptores, alinhadas com as determinações do Fórum SBTVD, sempre estiveram ancoradas na premissa de que, para tornar os receptores viáveis economicamente, a relevância do mercado internacional precisa ser considerada sem perder de vista as grandes tendências mundiais, partindo, portanto, de padrões existentes. O próprio sistema japonês está fortemente ancorado no europeu, ao qual técnicos japoneses implementaram significativas melhorias. Além disso, ao optar por padrões mundiais a importação e exportação de produtos, programas e serviços interativos ficam facilitados, ampliando o volume de negócios internacionais de alta tecnologia.
Tendo em vista os avanços tecnológicos previsíveis para as próximas décadas, um outro grande desafio foi elaborar especificações para os receptores de forma a garantir flexibilidade suficiente para incorporar as novas técnicas. As especificações devem atender igualmente à diversidade de interesses sócio-econômicos nacionais e internacionais, possibilitando implementações que variam em custo, complexidade e aplicações e, ao mesmo tempo, garantir que os serviços essenciais sejam corretamente recebidos em todos os receptores instalados desde a primeira unidade produzida até quanto durarem as transmissões digitais, sem deixar legado ou repúdio.
Para o equacionamento desta questão foi necessário recorrer ao precursor da televisão brasileira e nasceu o que se convencionou chamar informalmente de Modelo Chateaubriand, ou apenas Chatô. A alusão ao pioneiro da televisão brasileira é feita ao considerar que o primeiro produto importado da RCA ainda hoje, ao ser ligado, imagem e som são exibidos, mesmo depois de 60 anos e dos grandes avanços tecnológicos conquistados pela televisão analógica.
Baseada nas premissas mencionadas, a primeira ação para os trabalhos de especificação dos receptores foi identificar cenários, descrever os casos de uso e, em seguida, levantar os requisitos.

Levantamento de requisitos;
Análise dos requisitos (exposição de motivos);
Negociação dos requisitos;
Especificação dos requisitos;
Classificação dos requisitos.
Para garantir implementações que variam em custo e complexidade e ainda assegurar que os serviços essenciais sejam recebidos enquanto durarem as transmissões digitais sem deixar legado, a Norma classifica os requisitos dos receptores em obrigatórios, recomendáveis, opcionais, não recomendáveis e proibidos. Para cada uma dessas categorias a Norma trata individualmente dos requisitos e especificações de processamento de áudio, vídeo e dados entre outros, para os receptores one-seg e full-seg.
Entretanto, as técnicas adotadas nas transmissões analógicas e digitais não são interoperáveis e, para atender ao imenso parque instalado de televisores analógicos, devem ser oferecidos ao mercado conversores de sinais digitais para analógicos, conhecidos pelo termo em inglês “set-top box”, que poderão ser facilmente conectados aos atuais televisores, possibilitando a estes velhos aparelhos acesso à grande parte dos benefícios da tecnologia digital. Nasce, assim, o Modelo Chateaubriand em duas versões: os conversores digitais e o televisor com receptor digital built-in.
O sistema apresentado pode ser basicamente dividido em dois grandes módulos; front-end e back-end.

Front-end
Este módulo pode ser representado por dois subsistemas; demodulação e decodificação de canal. A função do subsistema de Codificação de Canal e Modulação é a de atribuir ao fluxo de dados transmitido proteção, os quais conferem robustez ao sinal. Por outro lado, o receptor deve restaurar o feixe de bits originalmente transmitido fazendo uso das ferramentas para correção de erros de modo que seja adequadamente entregue ao demultiplexador.
Em linhas gerais, o que diferencia cada sistema de TV digital hoje existente é a forma como o sinal é transmitido (codificação do canal e modulação), já que, na geração do fluxo de bits, todos empregam padrões bastante similares para multiplexação e codificação dos sinais fontes (áudio, vídeo, dados e etc). Neste quesito, o módulo de front-end é a diferença chave dos receptores, enquanto na transmissão a adição de redundância é um importante elemento para a robustez em ambientes hostis. Do lado do receptor o módulo de processamento de sinal deve proporcionar uma fácil sintonia, mesmo em ambientes de campo eletromagnético fraco, ruidoso e repleto de reflexões para a recuperação da portadora, sincronização de bits e estimação do canal, especialmente ao ligar o receptor. Mesmo utilizando técnicas de modulação há tempo conhecidas – tais como: aleatorização, codificação Reed-Solomon, entrelaçamento externo e interno de dados, codificação convolucional (todos com adição de redundância), como também diferentes interleaving (sem redundância) – a forma como estas técnicas se compõem é o grande diferencial.
Considerando o decreto presidencial, o modelo da camada- física escolhida para o módulo do front-end foi o mesmo adotado pelo ISDB-T. As alterações em relação às especifi- cações japonesas são apenas no que se refere à canalização, relação de proteção co-canal e canal adjacente em VHF e na freqüência de FI. Afora estes pontos, a forma de processar o sinal, desde a sintonia de canais até a recuperação do fluxo de bits, obedecem rigorosamente as especificações ARIB (Association of Radio Industries and Businesses).
Back-end
No Sistema Brasileiro de TV Digital este foi o módulo que maiores alterações sofreu em relação ao sistema japonês e pode ser subdividido nos subsistemas que seguem:

Demultiplexação:
A camada de transporte permite que informações contidas em um ou mais serviços sejam associadas em um único fluxo de bits. Os componentes individuais de áudio, vídeo, dados e serviços auxiliares de cada serviço, além de informações complementares para a apresentação sincronizada nos receptores, são combinados e o feixe resultante modulado é transmitido pelo canal de televisão. Esta camada, conhecida por MPEG-2 System, é responsável pela multiplexação e demultiplexação destes sinais e é baseada na recomendação internacional ITU-T H.222, a mesma utilizada em todos os sistemas de televisão digital hoje existentes. Cada um apresenta algumas particularidades, também aplicáveis ao Sistema Brasileiro de Televisão Digital, para atender especificidades aos requisitos locais, como, por exemplo, canal virtual, classificação indicativa, entre outros, além dos aspectos culturais e de linguagem. Apesar de originalmente a recomendação ter sido desenvolvida para a família MPEG-2, sua evolução permitiu suportar conteúdos da família MPEG-4 e, especialmente, o padrão ITU-T H.264.
Na recepção, os componentes individuais de áudio, vídeo, dados e serviços auxiliares e informações de sincronização do serviço selecionado são separados e re-convertidos em imagens, sons, conteúdos interativos, textos, serviços de informação, guia de programação, entre outros.

Decodificação do Sinal Fonte:
A função básica da codificação de sinais fonte é reduzir a taxa de bits para valores compatíveis com a banda de 6 MHz atribuída a cada canal de televisão. Considerando uma eficiência espectral pouco maior que 3 bits/Hz, dependendo do modo em que o sinal foi codificado e modulado, a taxa máxima permitida gira em torno de 18 a 20 Mbps. Entretanto, a imagem da televisão digital de alta definição, com a sua nova relação de aspecto visual 16:9, é composta por mais de dois milhões de elementos de imagem aos quais são atribuídos diferentes valores de claridade, cor e saturação, o que gera uma taxa perto de 1 Gbps. Sem um método eficiente e padronizado de compressão é fácil concluir que a televisão de alta definição e a convergência permaneceriam no campo da ficção e nos sonhos dos pioneiros da televisão.
Para reduzir este imenso fluxo de dados são aplicadas técnicas para eliminar redundâncias de imagens, entre elas: a temporal, com semelhanças entre imagens sucessivas; a espacial, com semelhanças entre pixels adjacentes; e a espectral, com diferentes planos de cor. Assim, a compressão de vídeo permite à emissora enviar apenas os dados necessários, ou seja, apenas as diferenças de cada quadro da imagem em lugar de um quadro inteiro, removendo as informações repetitivas. No receptor, o decodificador recebe do demultiplexador o fluxo de bits correspondente a cada tipo de informação (áudio, vídeo, dados e etc.) e, para que sejam corretamente exibidos, executa a recuperação de todos os elementos suprimidos na transmissão. A grosso modo seria o mesmo que transportar suco, de cuja origem é retirada a água natural e somente a polpa é transportada para, no destino final, receber nova adição de água.
Os países que operam TV digital já há algum tempo empregam técnicas de compressão definidas pelo padrão MPEG-2. Entretanto, dado o fato de o Brasil ter optado mais tardiamente pela TV digital, o país pôde se beneficiar de progressos alcançados em pesquisa e desenvolvimento e, de forma pioneira, adotou o padrão AVC/H.264 na televisão terrestre, o qual oferece eficiência de compressão cerca de duas vezes maior que seu antecessor.

Middleware:
Arquitetura de software que viabiliza a TV interativa e pode ser definida como um ambiente que abstrai a arquitetura de hardware e a do sistema operacional dos receptores.
Deve ser disponibilizada em formato padronizado no que se refere às interfaces de programação das aplicações interativas, ao formato de dados e ao modo de execução das aplicações, o que confere ao receptor um comportamento quase que autônomo para esta funcionalidade. É um ambiente em tempo real que permite aos desenvolvedores de aplicações a possibilidade da utilização de todas as características do decodificador sem que sejam exigidos conhecimentos sobre a arquitetura dos receptores.
Cada um dos padrões mundialmente disponíveis adotou a técnica mais adequada à sua realidade. O Brasil não fugiu a esta regra e desenvolveu o seu próprio modelo baseado nas ferramentas de programação declarativa e procedural, conhecidas, respectivamente, como Ginga-NCL e Ginga-J.

Canal de Interatividade:
Subsistema responsável por estabelecer a comunicação entre os usuários do receptor e os provedores de conteúdos.
De forma geral, o canal de interatividade utiliza a infra-estrutura das redes de telecomunicações para enviar e receber dados. Por ser um subsistema ortogonal a qualquer sistema de TV digital, pode admitir um grande número de soluções tecnológicas, tais como: Redes de Telefonia Fixa, Redes de Telefonia Celular (GSM, GPRS, CDMA, etc.), Redes de Fibra Ótica, Redes LAN, WLAN, Wi-Fi, WiMAX entre tantas outras.
Considerando a grande diversidade tecnológica comercialmente disponível e as que certamente estão por surgir; e ainda, os mais diversos e heterogêneos cenários de oferta de serviços em cada região do País, a construção de uma solução inovadora precisou ser desenvolvida. Com o propósito de flexibilizar as mais diversas possibilidades aderentes ao sistema, foi definido um conjunto de funcionalidades essenciais requeridas para admitir qualquer que seja a infra-estrutura de telecomunicações disponível regionalmente. A grande flexibilidade proposta também oferece ao usuário a opção de selecionar aquela mais apropriada para a sua região, assim como permite que futuras técnicas possam ser agregadas ao modelo sem deixar legado. Para tornar a especificação viável, o sistema foi dividido em dois módulos que se complementam. O primeiro deve ser instalado no receptor digital e o segundo no dispositivo externo do canal de interatividade.
No que concerne ao receptor, a arquitetura visa operacionalizar o sistema e garantir a integridade do aparelho de recepção quando um dispositivo externo for conectado via porta USB, de forma a evitar que aplicações maliciosas sejam instaladas. Esta arquitetura pode ser subdividida basicamente em duas partes:
a) gerenciador de autenticação: ao conectar o dispositivo externo na porta USB do receptor, o sistema verifica a integridade e a autenticidade da aplicação do serviço de canal de interatividade. Qualquer dispositivo externo com aplicações de serviço não autorizado pelo fabricante do receptor não é reconhecido (aprovado). Quando a aplicação de serviço do dispositivo externo é devidamente autenticada, os componentes de device-driver, protocolos da camada física/enlace e arquivo de configuração são executados pelo sistema operacional e armazenados em memória RAM.
b) gerenciador de dispositivos externos: responsável por garantir que apenas aplicações autorizadas sejam executadas e também por configurar, monitorar e controlar o ciclo de vida do dispositivo conectado à porta USB, o sistema lê os atributos contidos no arquivo de configuração e notifica o sistema operacional para operacionalizar os devices-drivers associados ao dispositivo externo. As informações necessárias para instalar e con- figurar o dispositivo externo, que devem ser transferidas ao receptor, estão descritas no arquivo de configuração.
Por “Dispositivo Externo” entende-se qualquer dispositivo capaz de transmitir e receber dados por meio de qualquer rede de telecomunicação que seja aderente ao sistema de comunicação com o canal de interatividade.
A forma como todos os subsistemas aqui mencionados estão interligados na formação do sistema é demonstrada a seguir.
As principais diferenças entre o sistema japonês e o brasileiro são as apontadas no quadro abaixo.

Denota-se, assim, que a decisão brasileira foi adotar um sistema híbrido, “nipo-brasileiro”, ao utilizar a estrutura básica do sistema japonês e implementar inovações importantes sem, entretanto, perder de vista as premissas básicas inicialmente definidas. A aderência aos padrões internacionais está mantida, muitas vezes com desempenho e robustez superior a do sistema japonês.
Resumo
Este artigo apresenta a arquitetura de referência do middleware Ginga do Sistema Brasileiro de TV Digital Terrestre, chamando atenção para as diversas inovações introduzidas, que fazem desse middleware um dos mais expressivos e eficientes.
Palavras-chave: Ginga, NCL, Lua, Java, middleware, ambiente declarativo, ambiente imperativo, TV Digital.
Introdução
Middleware é uma camada de software posicionada entre o código das aplicações e a infra-estrutura de execução (plataforma de hardware e sistema ope- racional), como ilustrado pelo Modelo de Referência do Sistema Brasileiro de TV Digital Terrestre, apresentado na Figura 1.
Um middleware para aplicações de TV digital consiste de máquinas de execução das linguagens oferecidas e bibliotecas de funções, que permitem o desenvolvimento rápido e fácil de aplicações.
O universo das aplicações de TVD (TV Digital) pode ser particionado em um conjunto de aplicações declarativas e em um conjunto de aplicações imperativas. A entidade inicial de uma aplicação, isto é, aquela que dispara a aplicação, é que define a que conjunto a aplicação pertence, dependendo se essa entidade é codificada segundo uma linguagem declarativa ou imperativa. Note que aplicações declarativas podem conter entidades imperativas e vice-versa, o que as caracteriza é apenas a entidade inicial.
Linguagens declarativas enfatizam a descrição declarativa de uma tarefa em vez de sua decomposição passo a passo, em uma definição algorítmica do fluxo de execução de uma máquina, como fazem as descrições imperativas. Por ser de mais alto nível de abstração, tarefas descritas de forma declarativa são mais fáceis de serem concebidas e entendidas, sem exigir um programador especialista, como é usualmente necessário nas tarefas descritas de forma imperativa. Contudo, uma linguagem declarativa usualmente visa um determinado domínio de aplicações e define um modelo específico para esse domínio. Quando uma tarefa casa com o modelo da linguagem declarativa, o paradigma declarativo é, em geral, a melhor escolha. Linguagens imperativas são bem expressivas e de propósito geral, porém, a um elevado custo. Como mencionado, elas usualmente exigem um programador especialista, geralmente colocam em risco a portabilidade de uma aplicação, e o controle da aplicação é muito mais sujeito a erros cometidos pelo programador. No entanto, nos casos em que o foco de realização de uma tarefa não casa com o foco da linguagem declarativa, o paradigma imperativo é, em geral, a melhor escolha.
Por tudo o mencionado acima, os middlewares para TV digital provêem suporte para o desenvolvimento seguindo tanto o paradigma declarativo quanto o imperativo. Muitas vezes, como é o caso do sistema Japonês, a entidade inicial de uma aplicação é sempre declarativa, mas outras entidades podem ser codificadas segundo o paradigma imperativo. Muitas vezes, como é o caso do sistema americano e europeu, é oferecido suporte tanto para aplicações declarativas quanto para aplicações imperativas, mas, em ambos os casos, entidades seguindo um paradigma diferente da entidade inicial podem ser definidas.
O ambiente declarativo de um middleware dá o suporte necessário às aplicações declarativas, enquanto o ambiente imperativo dá o suporte necessário às aplicações imperativas. No caso do middleware do padrão brasileiro, os dois ambientes são exigidos nos receptores fixos e móveis, enquanto apenas o ambiente declarativo é exigido nos receptores portáteis.
O Sistema Brasileiro de TV Digital Terrestre (SBTVD) trouxe como principal inovação seu middleware, denominado Ginga1. Em seu ambiente declarativo o Ginga provê suporte para o desenvolvimento de aplicações declarativas desenvolvidas na linguagem NCL (Nested Context Language), que podem conter entidades imperativas especificadas na linguagem Lua. Principalmente por sua grande eficiência e facilidade de uso, Lua é a linguagem de script de NCL. Em seu ambiente imperativo, o Ginga provê suporte a aplicações desenvolvidas em Java. Uma ponte desenvolvida entre os dois ambientes provê suporte a aplicações híbridas com entidades especificadas em NCL, Lua e Java.
Este artigo tem por finalidade apresentar algumas das características do Ginga e sua arquitetura de referência. A Seção 2 é dedicada à arquitetura de referência, a Seção 3 aos ambientes declarativos e imperativos do Ginga e, finalmente, a Seção 4 é reservada às considerações finais.
Arquitetura de Referência
A arquitetura do Ginga pode ser dividida em três módulos principais: Ginga-CC, Ginga-NCL e Ginga-J, como mostra a Figura 2. Os dois últimos módulos compõem a camada de Serviços Específicos do Ginga.
1 – Por que o nome Ginga? Ginga é uma qualidade de movimento e atitude que os brasileiros possuem e que é evidente em tudo o que fazem. A forma como caminham, falam, dançam e se relacionam com tudo em suas vidas. Ginga é flexibilidade, é adaptação, qualidades inerentes ao middleware brasileiro.
Ginga-J é o subsistema lógico do middleware Ginga responsável pelo processamento de aplicações imperativas escritas utilizando a linguagem Java. A especifi- cação desse subsistema caberá à Norma ABNT NBR 15606-4 e é assunto da Seção 3.1.
Ginga-NCL é o subsistema lógico do middleware Ginga responsável pelo processamento de aplicações declarativas NCL. NCL (Nested Context Language) e sua linguagem de script Lua compõem a base para o desenvolvimento de aplicações declarativas no SBTVD. A especificação desse subsistema cabe às Normas NBR 15606-2 e ABNT NBR 15606-5, e é assunto da Seção 3.2.
Ginga-CC (Ginga Common Core) é o subsistema lógico provedor de todas as funcionalidades comuns ao suporte dos ambientes declarativo (Ginga-NCL), e imperativo (Ginga-J). A arquitetura do sistema garante que apenas o módulo Ginga-CC deva ser adaptado à plataforma em que o Ginga será embarcado. Ginga-CC provê, assim, um nível de abstração da plataforma de hardware e sistema operacional, acessível por meio de APIs (Application Program Interfaces) bem definidas.
Um conjunto de exibidores monomídia comuns faz parte dos componentes do Ginga-CC. As características de tais exibidores são definidas na Norma ABNT NBR 15606-1. Eles são exibidores de áudio, vídeo, texto e imagem, incluindo, entre eles, o exibidor MPEG-4/H.264, implementado por hardware. O acesso a tais exibidores se dá através de adaptadores, responsáveis por notificar eventos de apresentação e seleção (interação do usuário).
Entre os exibidores também se encontra o exibidor (agente do usuário) HTML, especificado nas Normas ABNT NBR 15606-2 e ABNT NBR 15606-5. A Seção 3.2 discute um pouco mais o suporte a aplicações HTML oferecido pelo middleware Ginga.
Na Figura 2, o Gerenciador Gráfico é o responsável pelo gerenciamento do modelo conceitual do plano gráfico de apresentação. É ele que define o plano de exibição do vídeo principal H.264, os planos de exibição dos outros objetos de mídia que compõem uma aplicação TVD, e como esses planos se superpõem. A Norma ABNT NBR 15606-1 é responsável também pela tal definição.
Todo o acesso a dados obtidos através do canal de retorno (ou canal de interatividade) é também de responsabilidade do Ginga-CC. As diversas possibilidades de canal de interatividade são especificadas na Norma ABNT NBR 15607.
Ainda na Figura 2, os componentes DSM-CC e Processador de Dados oferecem o suporte para obtenção de dados, obtidos através de seções especiais MPEG-2, especificados na Norma ABNT NBR 15606-3. O componente de Persistência é o encarregado pelo gerenciamento do armazenamento de dados requisitados pelas aplicações, enquanto o componente Sintonizador é o responsável pela sintonização e controle do canal de rádio frequência.
Os demais componentes do Ginga-CC são opcionais e dependem da implementação particular de cada receptor.
O Gerenciador de Contexto é o encarregado de colher informações do dispositivo receptor, informações sobre o perfil do usuário e sua localização, e torná-las disponíveis ao Ginga-NCL e Ginga-J, para que eles possam efetuar adaptação de conteúdos ou da forma como conteúdos deverão ser apresentados, conforme determinado pelas aplicações.
Ao Gerenciador de Atualizações cabe o controle das atualizações de todo o software residente e do middleware Ginga, durante o ciclo de vida de um dispositivo receptor.
Os componentes CA (Conditional Access) e DRM (Digital Right Management) são os responsáveis por determinar os privilégios de acesso às diversas mídias que compõem uma aplicação (programa) TVD.
Sobre o suporte oferecido pelo Ginga-CC, os módulos de serviço específico do Ginga (Ginga-NCL e Ginga-J) são implementados, como discutido na próxima seção.
Ambientes Declarativo e Imperativo do Middleware Ginga

Diferente de outros sistemas, por exemplo o sistema europeu, não existe qualquer relacionamento mestreescravo entre os ambientes declarativo e imperativo do middleware Ginga. Ao contrário, eles são ambientes pares com processo muito bem definido de comunicação, especificado por APIs simbolizadas na Figura 2, pela Ponte.

O Ambiente Ginga-J
Como já mencionado, o ambiente imperativo Ginga- J oferece suporte a aplicações desenvolvidas usando a linguagem Java.
Ginga-J é dividido em três módulos, conforme ilustra a Figura 2: a máquina virtual Java; o núcleo e suas APIs, também chamadas APIs verdes do Ginga-J; módulo responsável pelo suporte às APIs específicas do Ginga-J, chamadas de APIs amarela e vermelha do Ginga-J.
Ginga-J seguirá a especificação da Norma ABNT NBR 15606-4. As APIs verde do núcleo são as responsáveis por manter o sistema compatível o máximo possível com os sistemas americano e europeu.
As APIs específicas do Ginga, que podem ser exportadas para outros sistemas, são chamadas de amarelas. Entre elas estão aquelas que provêem suporte a múltiplos usuários, a múltiplos dispositivos e a múltiplas redes. Estão também aquelas que oferecem suporte às aplicações que podem ser recebidas, armazenadas e executadas em um tempo futuro.
O suporte para as necessidades específicas de aplicações voltadas para o Brasil, em especial aplicações de inclusão social, são endereçadas pela API vermelha do Ginga-J.
Ginga-J tem por base um conjunto de pacotes Java, comuns a diversos middlewares imperativos, conforme será especificado na Norma ABNT NBR 15606-4.
Entre as APIs específicas, cabe ainda ressaltar aquelas que se comunicam com o ambiente declarativo Ginga-NCL. Uma aplicação Java pode agir como entidade filha de uma aplicação declarativa, ou como uma entidade inicial, controlando o ciclo de vida de uma entidade filha declarativa.
Quando a entidade Java é a entidade inicial, ela pode criar, modificar e destruir documentos declarativos NCL através das APIs de comandos de edição Ginga, conforme especificado na Norma ABNT NBR 15606-2.
Quando a entidade Java é uma entidade filha, ela atua como um objeto de mídia NCL, podendo se registrar para receber eventos NCL. Eventos NCL poderão, a partir de então, acionar métodos das classes Java do objeto. Objetos de mídia NCL com código imperativo Java podem também comandar condições de disparos de relacionamentos NCL, usados no sincronismo temporal e espacial da apresentação de conteúdos. Podem também manipular variáveis globais de aplicações declarativas, responsáveis pela determinação da adaptação de conteúdos ou da forma como conteúdos são apresentados.
As APIs amarela e vermelha, e as APIs da ponte são inovações brasileiras do ambiente imperativo Ginga-J, que o distingue dos demais ambientes imperativos dos middlewares do sistema europeu e americano.

O Ambiente Ginga-NCL
Ginga-NCL é a inovação totalmente brasileira do SBTVD. O ambiente tem por base a linguagem NCL (uma aplicação XML) e sua linguagem de script Lua.
Os ambientes declarativos dos sistemas americano (ACAP-X), europeu (DVB-HTML) e japonês (BML-ARIB) têm por base a linguagem XHTML. XTHML carrega o legado de tecnologias anteriormente desenvolvidas para navegação textual. Em sentido contrário, aplicações para TVD são usualmente centradas no vídeo. Além disso, o modelo da linguagem XHTML tem o foco no suporte à interação do usuário telespectador. Outros tipos de relacionamentos, como relacionamentos de sincronização espaçotemporal e relacionamentos para definição de alternativas (adaptação de conteúdo e de apresentação), são usualmente definidos através de uma linguagem imperativa, no caso de todos os três sistemas citados na linguagem ECMAScript.
Diferente das linguagens baseadas em XHTML, NCL define uma separação bem demarcada entre o conteúdo e a estrutura de uma aplicação, provendo um controle não invasivo da ligação entre o conteúdo e sua apresentação e leiaute.
O modelo da linguagem NCL visa um domínio de aplicações mais amplo do que o oferecido pela linguagem XHTML. NCL visa não apenas o suporte declarativo à interação do usuário, mas o sincronismo espacial e temporal em sua forma mais ampla, tratando a interação do usuário como um caso particular. NCL visa também o suporte declarativo a adaptações de conteúdo e de formas de apresentação de conteúdo, o suporte declarativo a múltiplos dispositivos de exibição e a edição/produção da aplicação em tempo de exibição, ou seja, ao vivo. Esses são também os focos da maioria das aplicações para TV digital, o que torna NCL a opção preferencial no desenvolvimento da maioria das aplicações de TVD. Para os poucos casos particulares, como por exemplo, quando a geração dinâmica de conteúdo é necessária, NCL provê o suporte de sua linguagem de script Lua. Alternativamente, as APIs da ponte com o Ginga-J podem ser usadas acionando o suporte imperativo oferecido pela linguagem Java.
Como a NCL tem uma separação mais acurada entre o conteúdo e a estrutura de uma aplicação, ela não define nenhuma mídia por si. Ao contrário, ela define a “cola” que prende as mídias em apresentações multimídia. NCL apenas define como objetos de mídia são estruturados e relacionados, no tempo e no espaço. Como uma linguagem de cola, ela não restringe ou prescreve os tipos de conteúdo dos objetos de mídia. Nesse sentido, podemos ter objetos de imagem, de vídeo, de áudio, de texto, de código imperativo (Xlet e Lua, no SBTVD), entre outros, como objetos de mídia NCL. Quais objetos de mídia têm suporte depende dos exibidores de mídia que estão acoplados ao formatador NCL (na verdade, que têm suporte no Ginga-CC, veja na Figura 2). No SBTVD, um desses exibidores é o decodificador/ exibidor MPEG-4, implementado em hardware no receptor de televisão digital. Dessa forma, o vídeo e o áudio MPEG-4 são tratados como todos os demais objetos de mídia que podem ser relacionados utilizando NCL; em outras palavras, eles são simplesmente parte de uma aplicação de TVD.
Outro objeto de mídia NCL que deve obrigatoriamente ser suportado pelo Ginga-NCL é o objeto de mídia baseado em XHTML. A NCL não substitui, mas embute documentos (ou objetos) baseados em XHTML. Como acontece com outros objetos de mídia, qual linguagem baseada em XHTML tem suporte em um formatador NCL é uma escolha de implementação e, portanto, depende de qual navegador XHTML, incorporado no formatador NCL (na verdade suportado pelo Ginga-CC), atua como exibidor dessa mídia.
Como consequência, é possível ter navegadores BML, DVB-HTML e ACAP-X individualmente embutidos em um exibidor de documento NCL. É possível, ainda, ter todos eles. Assim, aplicações declarativas desenvolvidas para aqueles sistemas também executariam com o suporte oferecido pelo middleware Ginga. Resta mencionar que as Normas ABNT NBR 15606-2 e ABNT NBR 15606-5 defi- nem apenas um conjunto de funcionalidades básicas para XHTML e suas tecnologias derivadas como obrigatórias. A escolha de outras funcionalidades adicionais é opcional.
Voltando nossa atenção para a Figura 2, o componente Formatador NCL tem como responsabilidade orquestrar toda a execução de uma aplicação NCL, garantindo que os relacionamentos espaço-temporais definidos pelo autor da aplicação sejam respeitados. A máquina de execução Lua é responsável pelo processamento do código imperativo Lua.
Lua é uma linguagem de programação imperativa efi- ciente, rápida e leve, projetada para estender aplicações. Lua combina uma sintaxe simples para programação imperativa com construções poderosas para descrição de dados, baseada em tabelas associativas e em semântica extensível. Lua é tipada dinamicamente, é interpretada e tem gerenciamento automático de memória, com coleta de lixo incremental. Essas características fazem de Lua uma linguagem ideal para configuração, automação (scripting) e prototipagem rápida (geração rápida de aplicações). Lua é uma das linguagens de script mais eficientes; muito mais rápida do que ECMAScript, e com um footprint de memória bem menor, como indica a Figura 3, obtida do site de avaliação de linguagens(http://shootout.alioth.debian.org/); Lua é, em média, sete vezes mais rápida e com um uso de memória 40 vezes menor. Lua é hoje a linguagem mais importante na área de entretenimento.
O Formatador NCL trata de aplicações recebidas pelo Ginga-CC e depositadas em uma estrutura de dados chamada “base privada”. Existe uma base privada por canal de radiofrequência. Cabe ao componente Gerenciador de Bases Privadas a tarefa de receber comandos para ativação e manipulação dessas aplicações. Como anteriormente mencionado, no Ginga-NCL, uma aplicação de TVD pode ser gerada ou modificada ao vivo (em tempo real), através de comandos de edição. O conjunto de comandos de edição, especificados na Norma ABNT NBR 15606-2, pode ser dividido em três grupos.

O primeiro grupo de comandos é responsável pela ativação e desativação de uma base privada, ou seja, a habilitação de aplicações de um determinado canal de TV. Em uma base privada, aplicações NCL podem ser ativadas, pausadas, retomadas e desativadas, por meio de comandos bem definidos pertencentes ao segundo grupo de comandos. O terceiro grupo define comandos para modificações de uma aplicação ao vivo.
Finalmente, como o Ginga-J, o Ginga-NCL oferece suporte a múltiplos dispositivos de entrada e saída. Tal facilidade declarativa – juntamente com os comandos de edição ao vivo, únicos do sistema brasileiro – provê suporte para o grande domínio de aplicações interativas de TVD que se descortina: as aplicações para as chamadas TV em comunidade (Community ou Social TV), em que uma comunidade de usuários cria ao vivo, sobre o conteúdo e as aplicações recebidas, novas aplicações (geração de novos conteúdos e informações personalizados), que são trocadas entre seus membros para exibição em tempo real ou sob demanda.
Considerações Finais
O Sistema Brasileiro é, atualmente, o mais avançado sistema de TV digital terrestre, não apenas por usar as tecnologias mais avançadas, mas, principalmente, por dispor de tecnologias inovadoras, como é o caso de seu middleware Ginga.
A implementação de referência do Ginga-NCL foi desenvolvida em código aberto e pode ser obtida em www.gingancl.org.br, sob a licença GPLv2. A máquina Lua também se encontra disponível pelo mesmo site, com uso da licença MIT. Ferramentas de autoria para o desenvolvimento de aplicações NCL, também em código aberto, estão disponíveis ainda no mesmo site, bem como tutoriais, livros, artigos e exemplos de várias aplicações NCL e Lua. Em http://clube.ncl.org.br, um repositório de aplicações interativas é encontrado; lá autores podem divulgar suas idéias, talentos, e, ainda, suas técnicas de desenvolvimento usando a linguagem NCL com scripts Lua.
Várias listas de discussão e contribuições no desenvolvimento de aplicações podem ser encontradas na comunidade Ginga, em www.softwarepublico.gov.br. Documentos, artigos e tutoriais a respeito do middleware Ginga, podem ser obtidos em www.ginga.org.br.
[ABNT NBR 15606-1] Televisão digital terrestre – Codificação de dados e especificações de transmissão para radiodifusão digital – Parte 1: Codificação de dados.
[ABNT NBR 15606-2] 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.
[ABNT NBR 15606-3] Televisão digital terrestre – Codificação de dados e especificações de transmissão para radiodifusão digital – Parte 3: Especificação de transmissão de dados.
Televisão digital terrestre – Codificação de dados e especificações de transmissão para radiodifusão digital – Parte 4: Ginga-J para receptores fixos e móveis. Em elaboração.
[ABNT NBR 15606-5] 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 NBR 15607-1] Televisão digital terrestre – Canal de interatividade – Parte 1: Protocolos, interfaces físicas e interfaces de software.

Este artigo da série sobre o Sistema Brasileiro de Televisão Digital apresenta a arquitetura de canal de interatividade e as tecnologias de comunicação de rede aplicáveis. A especificação técnica está disponível na Norma ABNT NBR 15607, e distribuída em três partes: 1- Protocolos, interfaces físicas e interfaces de software (já publicada); 2- Dispositivos externos; 3- Interfaces de configuração para as tecnologias de acesso (em elaboração).
A concepção inicial de interatividade na televisão digital está associada à possibilidade de comunicação de dados das estações receptoras com os aplicativos eventualmente disponibilizados através do sinal de difusão de uma emissora. A comunicação da emissora com os receptores é realizada a partir de uma estação transmissora que envia os dados em broadcasting à grande quantidade de receptores simultaneamente. Por outro lado, a transmissão de dados do receptor para a emissora é realizada por um subsistema, comumente chamado de canal de retorno ou canal de interatividade. No SBTVD tal comunicação de interatividade é bidirecional por meio do protocolo TCP/IP.
A Figura 1 mostra os três subsistemas do sistema de TV Digital. O sistema de difusão que realiza a geração e o empacotamento das informações para a transmissão em broadcast. O receptor realiza a operação inversa para disponibilizar as informações para os usuários. Por último, o canal de interatividade, que permite a comunicação dos usuários com aplicativos e serviços da emissora e, além disto, permitiria também acessar dados em servidores não necessariamente localizados junto das estações transmissoras. No modelo, os servidores de conteúdos de aplicativos interativos podem situar-se fisicamente em qualquer localidade com acesso à Internet.

Camadas do modelo OSI
O modelo OSI de arquitetura em camadas de protocolos de comunicação é utilizado para a definição das tecnologias que podem ser utilizadas no Sistema Brasileiro de TV Digital. A solução de canal de interatividade deverá ser adequada para cada contexto em particular, considerando-se as particularidades e disponibilidades das redes de comunicações e tecnologias locais. Várias tecnologias poderão ser utilizadas como alternativas para acesso do usuário ao canal de interatividade.
Tais tecnologias encontram-se listadas a seguir e são especificadas na norma ABNT NBR 15607: modems discados, ethernet (ADSL, FTTH, DOCSIS), ISDN, GSM-GPRS, GSM-EDGE, CDMA-1xRTT, CDMAHSDPA, WiMAX e Wi-Fi.

Os protocolos empregados nas camadas superiores, em geral para dar suporte à internet, estão indicados na tabela abaixo.

Protocolos para canal de difusão e interatividade
O detalhamento do protocolo para o canal de interatividade, que carrega a requisição, e para o canal de broadcasting, que carrega a resposta, é apresentado conforme a tabela abaixo.

Dispositivos externos
Para prover o acesso do usuário ao canal de interatividade é necessária a utilização de um modem, conforme visto anteriormente. A Figura 2 ilustra um esquema de difusão, recepção e acesso à rede IP, através de um modem externo ao receptor digital.
O Sistema Brasileiro de Televisão Digital oferece ao usuário a opção de escolha do meio de telecomunicação mais conveniente para a funcionalidade do canal de interatividade dentre uma gama ampla de possibilidades, levando-se em consideração as especificidades e heterogeneidade das redes de comunicações. O SBTVD permite o emprego da funcionalidade de canal de retorno como um dispositivo externo ao receptor ou televisor digital. É possível ainda a forma embutida do modem de comunicação nos receptores.

Arquitetura do receptor
A Figura 3 ilustra uma organização modular para a implementação do serviço de interatividade a ser usado no receptor do Sistema Brasileiro de Televisão Digital.

O hardware representa os componentes físicos do receptor. O sistema operacional é voltado a um sistema embarcado para gerenciamento de recursos e aplicações. Os drivers são módulos de software que permitem a comunicação com dispositivos físicos. O gerenciador de autenticação é o modulo de software responsável por prover o procedimento de autenticação de serviços. O gerenciador de dispositivo é responsável pelo gerenciamento de dispositivos externos. As aplicações representam os aplicativos gerais que serão executados no receptor.

Entre as camadas de protocolo e a camada de aplicações, existe uma camada intermediária responsável por fornecer APIs para utilização do canal de interatividade. Essa camada é conhecida por middleware, que permite abstrair do receptor as especificidades do sistema operacional e do hardware.

Dispositivos externos autenticados
A Figura 4 apresenta componentes do dispositivo externo para o serviço de canal de interatividade, para prover compatibilidade de comunicação entre este módulo e o receptor do Sistema Brasileiro de Televisão Digital.

O Certificado Digital (CD) contém um conjunto de informações referentes à entidade para a qual o certificado foi emitido; a chave pública é referente à chave privada, de posse única da entidade especificada no certificado.
A chave privada do dispositivo externo é gerada em conjunto com a chave pública, e é utilizada no processo de autenticação do dispositivo externo pelo receptor, ambas com tamanho de 1024 bits. O RSA é o algoritmo criptográfico empregado.
Os drivers permitem a comunicação com o dispositivo físico e encontram-se carregados na memória RAM do receptor. É obrigatório que o fabricante do dispositivo externo forneça todos os drivers necessários para a instalação do dispositivo externo.
É utilizado um arquivo de configuração (XML), no formato XML, contendo as seguintes informações: família da tecnologia de acesso ao qual o dispositivo pertence, nome dos drivers, nome dos protocolos e dependência de drivers.
Na figura 4, o aplicativo de configuração (Ginga) é opcional, o qual deve deve ser executado após à montagem do dispositivo externo, visando a configuração do modem.
O processo de instalação e configuração do dispositivo externo pode ser visualizado através do fluxograma da Figura 5.

Configuração do canal de interatividade
A Figura 6 apresenta o fluxograma de configuração do canal de interatividade, que consiste num diagrama genérico, que pode ser aplicado às diversas tecnologias aderentes ao Sistema Brasileiro de Televisão Digital. Entretanto, cada padrão de comunicação possui um conjunto de parâmetros específicos, utilizados pelo receptor na configuração do dispositivo externo. Esses parâmetros encontram-se definidos na ABNT NBR 15607, Parte 3.
Após a iniciação do sistema, um evento plug and play é gerado pelo evento de conexão do dispositivo externo e deve disparar o mecanismo de verificação do serviço do dispositivo externo. Caso o dispositivo externo tenha sido validado, conforme os passos apresentados anteriormente, um ou mais drivers de comunicação devem ser instalados no receptor. Na seqüência, deve ser feita a leitura do arquivo XML contendo os parâmetros de configuração. Caso haja o arquivo de configuração, este deve ser lido e sinalizado ao middleware para sua máquina de execução. Caso não haja o arquivo de configuração, deve ser prevista a montagem de um diálogo de configuração.
Deve ser gerada uma mensagem sinalizando “dispositivo externo pronto” para middleware contendo um apontamento para o arquivo XML de configuração. Caso o dispositivo externo já se encontre configurado, o sistema deve passar para o estado de serviço de comunicação interativa iniciado. Caso contrário, deve haver duas possibilidades de configuração: manual ou automática. Na configuração manual, deve ser disponibilizada uma interface gráfica para o usuário por meio de diálogos de configuração. Na segunda possibilidade seleciona-se, conforme a tecnologia de canal de interatividade especí- fica do driver, o arquivo XML de configuração dentre os diversos arquivos que podem ser recebidos por meio de comunicação DSM-CC. Este arquivo, caso exista, pode ser utilizado para a função de configuração. Deve ser gerada uma mensagem ao usuário dizendo se este aceita ou não a configuração automática. Caso não seja aceita, deve ser oferecida ao usuário a possibilidade de configuração manual por meio de chamada do aplicativo de configuração no menu do receptor.

Conclusão
As especificações do canal de interatividade do Sistema Brasileiro de Televisão Digital permitem a utilização de várias tecnologias de comunicações de dados. A tecnologia a ser adotada deverá ser adequada para cada localidade e depende da disponibilidade das redes de acesso.

A concepção dos receptores digitais e dos dispositivos externos permite fácil atualização e padronização de novas interfaces entre os mesmos, de forma a possibilitar a adoção de futuras tecnologias de comunicações apropriadas para a interatividade do Sistema Brasileiro de Televisão Digital.
As normas técnicas do SBTVD ampliaram sobremaneira as tecnologias previstas na estrutura normativa do ARIB, com grande ênfase dada às tecnologias de comunicação sem fio. Estas tecnologias, que possibilitam a conexão à rede Internet, tendem a predominar nesta década, a exemplo do que ocorreu com a introdução da telefonia celular que, em curto período de tempo, ultrapassou o número de telefones fixo.
Saiba Mais
As normas de TV digital estão acessíveis gratuitamente através do site www.abnt.org.br/tvdigital. Para saber mais sobre o canal de interatividade, procure pela Norma: ABNT NBR 15607-1: Televisão digital terrestre – Canal de interatividade – Parte 1: Protocolos, interfaces físicas e interfaces de software
FÓRUM SBTVD 24
Revista da SET – ed. 105