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.

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.

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.

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.

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.

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.

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.