UNIVERSIDADEFEDERALDO RIO GRANDE DO NORTE PROGRAMA DEPÓS-GRADUAÇÃO EMENGENHARIAELÉTRICA
Utilizando a Televisão Digital como um Meio de
Comunicação para Ambientes Interativos Reais
Julio Cesar Paulino de Melo
UNIVERSIDADEFEDERALDO RIO GRANDE DO NORTE
UNIVERSIDADEFEDERAL DORIOGRANDE DO NORTE
CENTRO DETECNOLOGIA
PROGRAMA DEPÓS-GRADUAÇÃO EMENGENHARIAELÉTRICA
Utilizando a Televisão Digital como um Meio de
Comunicação para Ambientes Interativos Reais
Julio Cesar Paulino de Melo
Orientador: Prof. Dr. Luiz Eduardo Cunha Leite
Dissertação de Mestrado apresentada ao
Programa de Pós-Graduação em Engenharia Elétrica da UFRN (área de concentração: TV Digital e Aplicações) como parte dos requi-sitos para obtenção do título de Mestre em Ciências.
Melo, Julio Cesar Paulino de.
Utilizando a Televisão Digital como um Meio de Comunicação para Ambi-entes Interativos Reais/ Julio Cesar Paulino de Melo - Natal, RN, 2010
72 f. : il
Orientador: Luiz Eduardo da Cunha Leite
Dissertação (mestrado) - Universidade Federal do Rio Grande do Norte. Cen-tro de Tecnologia. Programa de Pós-Graduação em Engenharia Elétrica e de Computação.
1. Televisão digital - Dissertação. 2. Integração Homem-máquina - Disserta-ção. 3. Mídia Digital - DissertaDisserta-ção. 4. Middleware - DissertaDisserta-ção. I. Leite, Luiz Eduardo da Cunha. II. Universidade Federal do Rio Grande do Norte. III. Título
Utilizando a Televisão Digital como um Meio de
Comunicação para Ambientes Interativos Reais
Julio Cesar Paulino de Melo
Dissertação de Mestrado aprovada em 2 de Agosto de 2010 pela banca examinadora com-posta pelos seguintes membros:
Prof. Dr. Luiz Eduardo da Cunha Leite (orientador) . . . ECT/UFRN
Prof. Dr. Luiz Marcos Garcia Gonçalves . . . DCA/UFRN
Prof. Dr. Aquiles Medeiros Filgueira Burlamaqui . . . ECT/UFFN
Agradecimentos
Ao meu orientador, professor Luiz Eduardo, sou grato pela orientação.
Aos professores Aquiles, Guido Lemos, Luiz Marcos e Rudsom pelas revisões, brains-torms e apoio.
Aos colegas do Laboratório Natalnet pela ajuda em todas as horas.
Aos demais colegas de pós-graduação, pelas críticas e sugestões.
À minha família pela confiança durante toda vida.
Esta dissertação foca em prover um mecanismo de comunicação bidirecional entre os telespectadores de um sistema de TV Digital e os chamados Dispositivos de Interação, tais como robôs, por exemplo, dispostos no cenário de um programa TV transmitido ao vivo. Este mecanismo tem por objetivo permitir que os telespectadores controlem os Dispositivos de Interação através dos seus aparelhos de TV, usando o canal de retorno presente em sistemas de TV Digital Interativa, e receber dados desses dispositivos através do canal de broadcast.
Esse sistema foi projetado usando na forma de um sistema de middleware onde os Dispositivos de Interação presentes no cenário do programa de TV são interconectados, formando uma Rede de Dispositivos de Interação. Com essa abordagem, o sistema pro-posto é capaz de gerenciar os dispositivos na rede, controlando a saída e entrada de novos elementos, de forma transparente para os telespectadores. O sistema também permite que os dispositivos da rede se intercomuniquem, com um canal de comunicação integrado sem preocupações com a camada física de comunicação.
Palavras-chave: Middleware, Redes de dispositivos interconectados, Aplicações de
Abstract
This Dissertation aims to provide a communication mechanism between Digital TV viewers and interaction devices, such as robots, for example, placed on the environment from which a TV program is being live broadcasted. Such communication mechanism has the objective to allow viewers controll the Interaction Devices through their TV devices, using the broadcast channel present in Interactive Digital TV systems, and receive data from the devices by the broadcast channel.
This system was projected as a middlewaer system where the Interaction Devices in the TV program set are interconnected, creating a Interactive Device Network. With this approach, the system is capable of manage the devices on the network, controlling the flow of coming and leaving elements, in a transparent way for the viewers. The system yet allows the Interaction Devices communicate each other, with a integrated communication channel with no worries about the physical communication layer.
Sumário i
Lista de Figuras iii
Lista de Tabelas v
1 Introdução 1
1.1 Definição do Problema . . . 2
1.2 Hipóteses de Pesquisa . . . 3
1.2.1 Hipóteses Secundárias . . . 3
1.3 Objetivos . . . 4
1.3.1 Objetivos Específicos . . . 4
1.4 Contribuições Principais . . . 4
1.5 Organização deste Trabalho . . . 5
Lista de Símbolos e Abreviaturas 1 2 Embasamento Teórico 7 2.1 Middleware . . . 7
2.2 Sistemas de TV digital . . . 11
2.2.1 TV Digital . . . 11
2.2.2 Redes de TV digital . . . 12
2.2.3 Interatividade nos Sistemas de TV Digital . . . 13
2.2.4 Conteúdo imperativo: Ginga-j . . . 14
2.2.5 Conteúdo declarativo Nested Context Language (NCL) . . . 15
2.3 Software Baseado em Componentes . . . 15
2.3.1 Modelo de componentes e ambiente de execução Flexcm . . . . 16
3 Cenários Relacionados 19 3.1 Melhorar o desenvolvimento de aplicações que mudam o conteúdo de programas ao Vivo . . . 19
3.2 Melhorar o desenvolvimento de jogos interativos em programas ao vivo . 19 4 Trabalhos Relacionados 21 4.1 Redes de Sensores sem fio Multimídia (WMSN’s) . . . 21
4.2 Distributed Multimedia . . . 22
4.3 Sistemas de Teleoperação e Telepresença . . . 24
4.4 Outros trabalhos relacionados . . . 25
5 Sistema Proposto 29 5.1 Arquitetura do Sistema . . . 30
5.2 Arquitetura do Device Supervisor . . . 31
5.2.1 Serviço de Descoberta de Novos Dispositivos . . . 32
5.2.2 Removendo dispositivos . . . 34
5.3 Comunicando o lado do telespectador com a arquitetura . . . 35
5.3.1 Interactive Device Provider (IDP) Architecture . . . 35
5.4 Arquitetura do Interaction Manager . . . 38
6 Resultados e Testes 41 6.1 Testes simples com sensores - Aplicação WiiMote . . . 41
6.1.1 Broadcast Data Manager . . . 43
6.1.2 Testes com Broadcast Data Manager . . . 43
6.1.3 Implemntação do IDP . . . 44
6.1.4 Avaliação dos resultados da aplicação WiiMote . . . 46
6.2 Controle de Dispositivo de Interação - Aplicação de Telecontrole de Galateia 46 6.2.1 Componente Device Supervisor Component para Galatéia . . . . 46
6.2.2 Interaction Manager e Estratégias de Controle implementadas . . 47
6.2.3 Avaliação dos resultados para a aplicação Galateia Telecontrol . . 47
6.3 Aplicação híbrida . . . 48
6.3.1 Avaliação dos resultados da Aplicação Híbrida . . . 48
7 Considerações Finais 51 7.1 Conclusões . . . 51
7.2 Sumário dos objetivos específicos alcançados . . . 51
7.2.1 Definição da arquitetura do sistema . . . 51
7.2.2 Tratando Diferentes Tipos de Dispositivos . . . 52
7.2.3 Tratando diferentes tipos de protocolos de broadcast . . . 52
7.2.4 Controlando Dispositivos de Interação do lado do telespectador . 52 7.2.5 Aplicações implementadas e resultados de validação . . . 52
7.3 Contribuições Principais . . . 53
7.4 Avaliação Geral . . . 53
7.5 Trabalhos Futuros . . . 53
Bibliografia 55
2.1 Uma proposta de classificação de middleware . . . 9
2.2 Outra classificação de middleware proposta . . . 10
2.3 Uma típica rede de TV digital . . . 13
2.4 Representação de uma rede de TVD com canal de retorno . . . 14
2.5 Visão geral dos pacotes da API Java DTV . . . 15
2.6 Interfaces dos Componentes Flexcm . . . 17
3.1 Um programa de TV ao vivo . . . 20
3.2 Jogo interativo com carro de controle remoto . . . 20
4.1 Arquitetura das WMSNs . . . 22
4.2 Arquitetura comum em sistemas de middleware distribuído . . . 23
4.3 Ouija 2000, sistema implementado para testar interação multi-usuário . . 25
4.4 Uma proposta de modelo unificado de eventos. . . 26
4.5 Aquitetura básica de Hardware/software. . . 27
5.1 Arquitetura do Sistema, blocos em verde relacionam componentes já exis-tentes em sistemas de DTV, blocos azuis foram adicionados por nosso sistema. . . 30
5.2 Device Supervisor Components. . . 31
5.3 Formato do byte stream do Broadcast Data Manager. . . 32
5.4 Interfaces requeridas pelo Device Network Manager. . . 33
5.5 Sequência de eventos na adição de novos dispositivos. . . 33
5.6 Sequência de eventos na remoção de dispositivos. . . 34
5.7 Camadas e componentes do IDP. . . 35
5.8 Classes e Interfaces da Camada de Baixo Nível IDP. . . 37
5.9 Classes e interfaces da Camada de Aplicação. . . 37
5.10 Componentes do Interaction Manager. . . 39
5.11 Interfaces dos componentes do Interaction Manager. . . 40
6.1 Diagrama de componentes para a aplicação do Wiimote. . . 42
6.2 O Broadcast Data Source é uma solução temporária adotada por nós para tratar o envio de dados por um canal de broadcast. . . 43
6.3 O Broadcast Converter implementado para enviar dados através de arqui-vos do Carrossel de dados. . . 44
6.4 Componentes Ncl para implementar o componente Data Handler. . . 45
6.5 Interface implementada para a aplicação WiiMote. . . 45
4.1 Algumas aplicações das WMSN . . . 23
5.1 Principais Requisitos do Sistema . . . 29
Capítulo 1
Introdução
Na área de pesquisas em multimídia, existem muitos esforços em direção da inte-ratividade. O significado do termo Interatividade em si é muito instável e pode mudar de acordo com o contexto envolvido. Alguns autores preferem falar que o termo é uma expressão multicontexto. Jensen [Jensen 2000, Jensen 1999] foca seu trabalho na base teórica da aplicação do termo interatividade em várias áreas da ciência, de acordo com seu trabalho, a definição de interatividade que melhor se adéqua ao campo da computação é a que define interatividade como um meio de controle.
Hoje em dia são comuns situações onde a interatividade é tida como um meio de con-trole. Quando usa uma aplicação de computador, por exemplo, o usuário interage para controlar o computador visando uma tarefa específica. Em alguns programas de TV a interatividade também pode estar presente como um meio de controle. Shows de TV po-dem prover mecanismos de interação remota através dos quais os telespectadores popo-dem executar atividades usando algum canal de comunicação (chamadas telefônicas ou SMS, por exemplo). O decorrer do show irá depender das ações tomadas pelos telespectado-res sendo, de alguma forma, controlado por ele. Em sistemas de TV Digital Interativa (TVDI), a interatividade pode ser provida utilizando o canal de retorno, que provê meios de permitir os telespectadores se comunicar com entidades remotas.
Alguns serviços interativos encontrados em sistemas de TVDI permitem usuários re-ceber e enviar dados para a emissora de TV. Esse mecanismo de comunicação bidirecional pode ser classificado como um meio de interatividade que possibilita a criação de aplica-ções que utilizam as interaaplica-ções do telespectador para criar conteúdo criado diretamente para ele.
dis-positivos eletrônicos, dispostos no cenário de programas de TV ao vivo que podem ser controlados remotamente pelos telespectadores ou enviar dados para estes, serão chama-dos de Dispositivos de Interação.
O conceito associado com a integração de dispositivos pode ser explorado em uma grande variedade de aplicações. Por exemplo, programas como Reality Shows podem ter um robô como participante, que é controlado pelo publico, que pode interagir com outros humanos participantes. Jogos de TV podem promover competições entre telespectado-res usando robôs controlados remotamente. Uma novela ao vivo pode ter características da cena como posição de câmera, organização de objetos, etc., modificas por ações dos telespectadores. O áudio emitido nas salas dos telespectadores pode ser capturado e pro-jetado em estádios, assim os telespectadores podem participar remotamente, torcendo em eventos de esporte; ou em salas de aula, permitindo a participação remota em aulas ao vivo. Sensores especiais podem ser usados em eventos de esporte como corridas automo-bilísticas, jogos de futebol, etc., para monitorar o desempenho dos atletas e prover essa informação para os telespectadores.
Considerando os cenários apresentados no parágrafo anterior, esse trabalho apresenta o projeto, implementação e resultados experimentais demonstrando a realizabilidade de um sistema que permite a comunicação em dois sentidos entre aplicações computacionais executando em aparelhos de TV Digital e Dispositivos de Interação dispostos no cenário de programas ao vivo de TV. Assim o telespectador poderá ter acesso a informações cole-tadas da cena através de sensores, bem como a possibilidade de controlar os dispositivos remotamente.
Embora os programas de TV apresentados possam ser de grande interesse e traze-rem contribuições sociais nos campos de entretenimento, inclusão social, educação, etc., uma série de outros desafios técnicos entra em jogo quando começamos a pensar sobre a implementação de tais programas na prática. No escopo dessa dissertação de mestrado iremos ressaltar esses problemas nas seções que seguem.
1.1
Definição do Problema
No escopo dessa dissertação de mestrado, os seguintes problemas serão abordados. Considerando um Dispositivo de Interação posicionado no cenário de um programa de TV digital ao vivo:
• P1 -Como permitir os telespectadores usarem os Dispositivos de Interação durante
um show de TV de forma transparente?
Mais especificamente, o problema mostrado pode ser subdividido nos subproblemas que seguem para melhor definir o escopo desse trabalho:
• P2 -Como permitir aos Dispositivos de Interação enviarem informação, coletada
da cena do show de TV, para milhões de telespectadores que assistem o show de TV?
• P3 -Como permitir que comandos enviados pelos telespectadores irão chegar aos
1.2. HIPÓTESES DE PESQUISA 3
É importante notar que esse trabalho é uma parte de um projeto de pesquisa com um escopo mais abrangente. Dessa forma alguns problemas como escalabilidade, que lidam com a possibilidade de milhões de telespectadores controlarem simultaneamente um Dispositivo de Interação, foram mantidos fora do escopo desse trabalho. Alguns desse problema serão abordados como objetivos de uma tese de doutorado em progresso [de Azevedo & Gonçalves 2010].
1.2
Hipóteses de Pesquisa
Em virtude dos problemas definidos na seção anterior nós propusemos as seguintes hipóteses de pesquisa:
• H1: Um sistema de middleware baseado em componentes de software pode ser
usado para promover a comunicação entre os telespectadores e os Dispositivos de Interação, permitindo telespectadores controlarem e receberem dados coletados pe-los Dispositivos.
• H2: Um canal de broadcast em uma estação de TV pode ser usado para
transmi-tir os dados coletados pelos Dispositivos de Interação dispostos no cenário de um programa de TV. Uma aplicação para TV digital Interativa pode executar nos re-ceptores de TV para receber os dados enviados e apresentá-los aos telespectadores.
• H3: Aplicações executando nos receptores de TV digital podem usar o canal de
re-torno presente nos padrões de TV digital para enviar comandos dos telespectadores aos Dispositivos de Interação.
1.2.1
Hipóteses Secundárias
Assumindo as hipóteses de pesquisa apresentadas na seção anterior, as seguintes hi-póteses secundárias foram definidas:
• H4: Um sistema de middleware de DTV, executando nos receptores de TV, pode
ser usado para facilitar o desenvolvimento de aplicações que são capazes de receber e manipular dados enviados pelos Dispositivos Interação e para enviar comandos a eles.
• H5:Dispositivos de Interação podem ser interconectados em uma rede e um sistema
de middleware, executando em equipamentos da estação de transmissão de TV, pode ser usado para gerenciar operações como adição, remoção ou atualização de dispositivos.
• H6: Uma aplicação executando nos equipamentos da estação de transmissão de TV
1.3
Objetivos
Nosso trabalho tem dois objetivos principais. O primeiro se resume ao projeto e im-plementação de um sistema de middleware que permita telespectadores se comunicarem de forma bidirecional com uma rede de Dispositivos de Interação localizada no ambiente da emissora. O segundo objetivo é a validação da arquitetura do sistema com um cenário de teste específico.
1.3.1
Objetivos Específicos
Para atingir o objetivo principal dessa dissertação foram especificados os seguintes objetivos específicos:
• SO1:Desenvolver e especificar uma arquitetura de middleware distribuído que
per-mita o gerenciamento e reconfiguração dos sensores dispostos no cenário de um show de TV que também permita a transmissão dos dados coletados pelos disposi-tivos para aplicações executando nos receptores de TVDI [de Melo et al. 2010].
• SO2:Implementar a arquitetura proposta com os requisitos necessários para
permi-tir que seja usado por uma emissora de TV digital, incluindo a habilidade de lidar com diferentes tipos de protocolos de transmissão usados para transmitir dados pelo canal de difusão.
• SO3: Construir uma aplicação de TV digital interativa que consiga receber e
mos-trar ao telespectador os dados coletados pelos sensores e transmitidos pelo canal de difusão.
• SO4: Especificar e implementar uma arquitetura de middleware que permita a
co-municação dos telespectadores com Dispositivos de Interação que estão na emissora de TV [de Melo et al. 2010].
• SO5:Testar o sistema com diferentes cenários.
1.4
Contribuições Principais
Com este trabalho as seguintes contribuições são esperadas:
• C1: A definição do conceito de Dispositivo de Interação no contexto de TV digital
interativa.
• C2: A definição de uma arquitetura de middleware que é capaz de gerenciar uma
rede de sensores localizada na emissora de TV e transmitir os dados coletados por eles de uma forma transparente.
• C1: A definição de uma arquitetura de middleware que permita os telespectadores
1.5. ORGANIZAÇÃO DESTE TRABALHO 5
1.5
Organização deste Trabalho
Capítulo 2
Embasamento Teórico
Para melhor entender nosso trabalho pode ser importante revisar alguns conceitos básicos disponíveis na literatura relacionada: alguns conceitos relativos a middlewaere na arquitetura que vai ser usada do lado do telespectador; conceitos de software baseado em componentes que será usado do lado da emissora; e por fim alguns conceitos relacionados ao Sistema Brasileiro de TV digital (SBTVD).
Esta seção vai focar na explicação de alguns termos principais relacionados com es-sas três áreas mencionadas. A primeira subseção vai cobrir aspectos sobre middleware seguida por uma seção que aborda conceitos de software orientado a componentes finali-zando com a abordagem de alguns conceitos importantes relacionados ao SBTVD.
2.1
Middleware
Uma possível definição de middleware pode se referir a uma camada de software que reside entre a aplicação e outro componente mais complicado e não portável (arquitetura de rede, sistemas operacionais, bancos de dados, etc.). A utilização de middlewaere é comum em campos onde é necessário que haja portabilidade, porém existem muitas im-plementações específicas para serem feitas. Nesses casos, um middleware é projetado e aplicações podem ser desenvolvidas usando as API’s genéricas fornecidas por ele ao in-vés de API’s específicas. Dessa forma, o middleware vai ser responsável por garantir a portabilidade.
De fato, portabilidade é uma das capacidades mais fortes dos middlewares. Porém devido a demanda de sistemas portáveis em muitas áreas e o crescimento dos requisitos desses sistemas muitos tipos de middlewares apareceram, tornando difícil de classificar quais são todos os principais requerimentos para definir um middlewaere completo.
Para definir o que pode ser considerado um middleware pode-se usar alguns conceitos de classificação e agrupamento. A primeira tipologia de classificação que iremos mostrar dividirá os middlewares em quatro tipos diferentes [Vinoski 2004].
lin-guagens bem conhecidas como Lua [of PUC-Rio & Lablua n.d.] e Java.
A classe dos Distribution Middleware se foca em arquiteturas distribuídas. Sistemas nessa classe definem métodos para invocar operações em objetos-alvo sem dependências em código de sua localização, linguagem de programação, plataforma de sistema operaci-onal, protocolo de comunicação e interconexões ou hardware. Este tipo de middleware é exemplificado por qualquer tipo de serviço de objetos distribuídos como CORBA ou Java RMI.
Os últimos dois tipos podem ser agrupados, são eles os serviços de Common
Mid-dleware e Specific Domain MidMid-dleware. O primeiro tipo está relacionado com
middlewa-res que cobrem aplicações comuns de domínio independente como serviços de diretórios, transações, segurança e serviços de eventos, este tipo funciona como uma base para o segundo tipo assim este pode ser desenvolvido sem preocupações com requisitos não es-pecíficos. O segundo grupo define middlewares desenvolvidos para aplicações específicas como telecomunicações, e-comércio, saúde, automação de processos. Uma melhor ilus-tração de como essas diferentes classes de middleware são representadas é mostrada na Figura
2.1.
Esta classificação em quarto grupos pode ser usada para comparar classes e imple-mentações, mas ainda é muito generalista, por exemplo tome um middleware usado em transmissão de multimídia, usando esta solução este middleware pode ser classificado na classe dos de distribuição por causa do seu papel principal, porém este sistema ainda pode prover um sistema de eventos para enviar dados sobre closed caption, por exemplo, dessa forma o mesmo middleware foi classificado como do tipo host/infrastructure.
Este tipo de problema é bem comum na hora de classificar middlewares, a próxima so-lução de classificação tenta ser menos genérica focando em muitos aspectos contidos em diferentes plataformas de middleware para criar 10 diferentes classes que são divididas em dois grupos principais, os Integração Middleware e os Application Middleware [Bishop & Karne 2003], como mostrado na Figura 2.2.
Os Integration Middlewares são semelhantes à classe Distribution que foi mostrada anteriormente, eles focam em serviços distribuídos que possuem diferentes especificações de protocolo que precisam ser transpostas. Essa classe é distribuída em cinco subclasses:
• Procedure Oriented Middleware: Cobre middlewares que usam comunicação entre
processos baseada em skeleton/stub. Uma aplicação cliente faz uma requisição atra-vés de uma interface provida por um componente então esta requisição é passada para o servidor para ser processada e a resposta enviada de volta ao cliente.
• Object Oriented Middleware: Cobre chamadas remotas a objetos como serviços
Corba. Este tipo possui características da classe anterior porém são especificamente orientados à objeto. Diferente da ultima, este tipo de aplicações não se comunicam diretamente com o servidor, elas usam um intermediário chamado Broker que con-verte as chamadas para uma linguagem comum.
• Message Oriented Middleware (MOM): Este tipo é composto principalmente por
2.1. MIDDLEWARE 9
Figura 2.1: Uma proposta de classificação de middleware
Mesage que apenas diferem no sistema usado na passagem de mensagem entre a
fonte e o destino.
• Component Based or Reflective Middleware: Esta classe é um gerenciador de
com-ponentes de software, onde pedaços de software podem ser montadas formando um sistema mais flexível. Os componentes de software podem estar localmente ou re-motamente localizados, o middleware será responsável por tratar os processos de comunicação entre eles.
• Agent Middleware: Este tipo cobre componentes baseados em Inteligência
Artifi-cial onde componentes ativos chamados de Agentes podem ser configurados para realizar uma tarefa específicas porém podem também realizar tarefas adicionais autônomas.
Figura 2.2: Outra classificação de middleware proposta
• Data Access Middleware (DAM): Este conjunto é responsável por qualquer tipo de
transação de dados entre fontes de dados e seus clientes como aplicações de acesso a Banco de Dados, Processamento de Transações e outras. Outros serviços como caching, bloqueio, espera e teste de dados são também cobertos por essa classe.
• Desktop Middleware: Esta classe foca em serviços de uso pessoal, porém
remo-tamente localizados como gerenciamento de arquivos, saída gráfica, serviços de backup e outros.
• Web-Based Middleware: Esta classe é uma das classes mais comuns caracterizada
por serviços como buscadores de páginas, autenticação de sistemas, e-mail, co-brança de contas e outros. Este tipo de middleware é comumente desenvolvido e usado em adição a outros serviços de internet, e ainda pode ser dividida em duas classes secundárias, middlewares e-Commerce e Mobile/Wireless, que diferem no modelo de negócio e fazem uso de outros serviços web para economizar requisitos de segurança e processamento de dados.
• Real Time Middleware: Esta classe é focada em middlewares que suportam
requi-sitos de tempo real. Este conjunto é muito comum em aplicações de multimídia por isso sua subclasse os middlewares Multimedia. Em adição essa classe está presente também em aplicações industriais e de processamento de sensores.
• Specialty Middleware: Esta classe cobre middlewares projetados para aplicações
específicas analogamente à classe Domain Specific discutida previamente.
2.2. SISTEMAS DE TV DIGITAL 11
semelhantes a arquiteturas de middleware.
2.2
Sistemas de TV digital
Principalmente nos capítulos de implementações e testes precisaremos discutir solu-ções que serão adaptadas para cada padrão de DTV. Dessa forma essa seção pretende abordar um pouco sobre alguns dos padrões de TV digital existentes, e concluindo com um pouco mais de informações sobre as linguagens imperativas e declarativas do sistema brasileiro de TVD.
2.2.1
TV Digital
Um sistema básico de Televisão Digital (TVD) consiste de uma estação transmissora, um meio físico sobre o qual o sinal é transmitido, que pode ser o ar ou meios físicos guiados (cabo coaxial, fibra óptica etc.), e um Receptor responsável por receber o sinal transmitido, decodificá-lo e exibi-lo. É necessário que sejam estabelecidos padrões que normatizem todo o processo de captura, compressão, modulação e transmissão dos si-nais de vídeo, além de todas as interfaces físicas entre os equipamentos envolvidos no processo, para garantir a compatibilidade entre os elementos envolvidos.
Como a transmissão é feita através de um fluxo de bits, há a possibilidade de se trans-mitir uma maior quantidade de informação multiplexada, em comparação ao sistema ana-lógico. Graças a esta característica, os sistemas de TV Digital tendem a adotar padrões de codificação de vídeo que suportam resolução superior às disponíveis nos padrões de TV analógica, assim como padrões de codificação de áudio que suportam codificação de um maior número de canais de áudio.
A transmissão digital viabiliza também a transmissão de múltiplos fluxos de vídeo simultaneamente, permitindo a transmissão de mais de um programa de TV simultanea-mente (multi-programação). As tecnologias de transporte permitem também que o fluxo carregue múltiplos formatos de vídeo, de forma que o conteúdo possa ser transmitido em diferentes resoluções, possibilitando a exibição em diferentes dispositivos.
O mecanismo de transporte utilizado para transmissão de vídeo digital com dados agregados comumente utilizado nos sistemas de TV Digital é baseado no padrão MPEG-2. Esse mecanismo define tabelas para inclusão de dados que podem ser informações acerca da programação transmitida, como também aplicações interativas. Alguns sistemas de TV Digital diferem justamente na forma da utilização destas tabelas.
Dentre os sistemas de TV Digital existentes, podem ser destacados [Morris & Smith-Chaigneau 2005] [de Souza Filho et al. 2007] [Soares et al. 2007]:
• DVB(Digital Vídeo Broadcasting ) - Sistema constituído por padrões mantidos pelo
que mais de 170 milhões de receptores sejam compatíveis com o sistema DVB, que inclui definições para transmissão terrestre, via satélite, a cabo e por microondas.
• ATSC(Advanced Television Systems Committee ) - padrão desenvolvido pelo comitê
homônimo americano, atualmente adotado por Estados Unidos, Canadá, México, Coréia do Sul, Argentina e Honduras.
• ISDB(Integrated Services Digital Broadcasting) - conjunto de padrões
desenvolvi-dos e mantidesenvolvi-dos pela organização japonesa ARIB (Association of Radio Industries and Businesses ), que incluem definições para rádio e TV Digital.
• SBTVD(Sistema Brasileiro de TV Digital) - sistema desenvolvido e mantido por um
fórum homônimo criado pelo governo brasileiro, incorpora o padrão de transmis-são terrestre japonês (ISDB-T) aliado à tecnologia desenvolvida no Brasil como uma API para desenvolvimento de aplicações que utilizem recursos de dispositi-vos (como celulares, PDAs, etc) em uma HAN (Home Area Network). Teve sua primeira transmissão oficial em 2 dezembro de 2007.
2.2.2
Redes de TV digital
Entende-se uma rede de TV Digital como o conjunto de componentes necessários para transmissão e recepção de sinal de TV de acordo com um sistema de TV Digital [Yamada et al. 2004] [Leite et al. 2005].
A Figura 2.3 ilustra uma rede de TV Digital representativa, cujos componentes serão descritos logo abaixo.
• Codificador de Vídeo- Equipamento responsável por codificar uma entrada de
vídeo em fluxo de vídeo digital, de acordo com um determinado padrão de codifi-cação (MPEG 2 ou H.264, por exemplo).
• Gerador de Carrossel - Módulo responsável por injetar no multiplexador um
sistema de arquivos (comumente aplicações interativas e seus arquivos) serializado, de maneira cíclica, produzindo o carrossel de dados.
• Servidor de SI (Service Information)- Dispositivo responsável por
geren-ciar as tabelas que fornecem informações sobre o serviço oferecido em um canal de TV agrega tipicamente as informações acerca dos fluxos de áudio e vídeo transmi-tidos nesse canal.
• Multiplexador- Equipamento responsável por unir (multiplexar) todos os fluxos
que compõem o fluxo a ser transmitido. O formato adotado pela maioria dos siste-mas é o MPEG-2 TS, que suporta multiplexação de múltiplas instâncias de vídeo, áudio e conjunto de dados (aplicações e seus arquivos).
• Receptor- Dispositivo responsável por receber, interpretar e exibir o conteúdo do
2.2. SISTEMAS DE TV DIGITAL 13
Figura 2.3: Uma típica rede de TV digital
Uma rede de TV Digital pode incluir também um canal de retorno (rede de interação), de forma a permitir que os telespectadores possam enviar informações de volta à estação de TV. Uma representação visual de uma rede de TV Digital com canal de retorno pode ser vista na Figura 2.4.
2.2.3
Interatividade nos Sistemas de TV Digital
mecanis-Figura 2.4: Representação de uma rede de TVD com canal de retorno
mos definidos por hardware, software e interfaces de comunicação do aparelho receptor do sinal de televisão digital. Dessa forma, o middleware de TVD permite a construção de aplicações independentes do hardware, executáveis em qualquer plataforma de qualquer fabricante.
A compatibilidade entre as aplicações baseadas nos diferentes padrões de TV Digi-tal disponíveis, tais como SBTVD, DVB, ATSC e ISDB, se dá através das definições a cerca do middleware dos receptores. Eles utilizam a tecnologia Java da Sun como parte da solução para a execução de aplicações nos seus receptores. Os middlewares de TV geralmente incluem suporte a linguagens declarativas (como XHTML) e de script.
A parte imperativa dos middlewares de TVD é suportada através da linguagem Java. Para que as aplicações pudessem ser executadas em múltiplos sistemas, de forma se-melhante, foi elaborada uma norma desenvolvida com base no middleware DVB MHP (Multimedia Home Platform) denominada GEM (Globally Executable MHP) [Globally
Executable MHP (GEM) Specification 1.1. 2007], que identifica e dá suporte a APIs
inde-pendentes de sistema específico. Essa especificação é atualmente adotada pelos padrões de middleware procedural japonês (ARIB B.23) [Application Execution Engine
Plat-form for Digital Broadcasting 2004], definições procedurais do middleware americano
Advanced Common Application Platform (ACAP) [ATSC Standard, Advanced Common
Application Platform (ACAP) 2005], Brasileiro (Ginga) [de Souza Filho et al. 2007] e,
ob-viamente, o europeu (MHP) [Globally Executable MHP (GEM) Specification 1.1. 2007].
2.2.4
Conteúdo imperativo: Ginga-j
Ginga-j é o middleware imperativo suportado pelo Ginga, como seu nome sugere ele fornece um conjunto de API’s Java. No começo do processo de desenvolvimento o Ginga-J foi desenvolvido como uma tentativa de fazer o Ginga compatível com as aplicações do MHP. Esta intenção foi superposta pelos requisitos de royalties ligados as APIs usadas no MHP que eram requeridas pelo Ginga-J.
2.3. SOFTWARE BASEADO EM COMPONENTES 15
uma nova API chamada Java DTV [sun microsystems 2010].
A Java DTV é uma API aberta que procura ter o mesmo poder de descrição provido pelas APIs do MHP, porém é livre de royalties. Esta API ainda está em desenvolvimento no contexto brasileiro, porém e uma boa alternativa às APIs do MHP.
Figura 2.5: Visão geral dos pacotes da API Java DTV
2.2.5
Conteúdo declarativo Nested Context Language (NCL)
Como dito antes NCL é o middleware declarativo usado no Ginga. NCL é uma lingua-gem baseada em XML como o HTML com a diferença de que a primeira está preparada para tratar interações temporais entre componentes do documento. Um documento NCL pode declarar, por exemplo, que certo conteúdo de mídia será mostrado por cinco segun-dos e com seu fim outro conteúdo será exibido. Esta capacidade é muito útil para escrever aplicações de DTV uma vez que são sempre relacionadas a conteúdo de mídia.
Como uma opção ao Java, NCL está desempenhando um importante papel no SBTVD, uma vez que já existem muitas aplicações presentes nos programas das emissoras que usam tal linguagem.
Um formatador NCL pode exibir qualquer conteúdo de mídia (vídeos, áudios, do-cumentos como HTML, xhtml e outros), em adição ele também precisa ser capaz de executar arquivos Xlets (aplicações escritas em Java sob o padrão Java DTV) e scripts em NCLua [Sant’Anna et al. 2008].
2.3
Software Baseado em Componentes
Microsystems’ Enterprise JavaBeansTM e Microsoft’s COM+, bem como em protótipos de pesquisa como SEI WaterBeans [Plakosh et al. 1999] e muitos outros. Um com-ponente de software é uma unidade de composição com interfaces bem especificadas e dependências contextuais [Szyperski 1998].
Usando projeto de software baseado em componentes podemos especificar quantos componentes forem necessários para um sistema, e após isso usar as conexões dos com-ponentes para fazer o sistema como um todo funcionar junta. Projeto baseado em compo-nentes não é caracterizado pela granularidade dos compocompo-nentes, mas pela sua equivalên-cia aos que foram especificados no planejamento do software, sua capacidade de serem submetidos a testes e sua independência quando estão sob desenvolvimento.
Um componente de software precisa seguir um modelo de componentes, este modelo vai descrever cada interface que precisa ser implementada e quais vão ser os métodos de acesso providos por cada uma. Um modelo de componentes precisa definir aspectos como tipos, composição e interação dos componentes, em adição é necessário um ambiente de execução que é apenas um gerenciador que é capaz de montar e gerenciar todos os componentes na arquitetura.
2.3.1
Modelo de componentes e ambiente de execução Flexcm
No nosso trabalho o modelo de componentes e o ambiente de execução é descrito pelo Flexcm [Filho et al. 2007]. Flexcm é um ambiente de execução de software baseado no modelo COM da Microsoft, ele permite muitos tipos de operações sobre componen-tes como carregamento em tempo real, atualização, remoção, adição e substituição, tais características são necessárias aos componentes de nosso sistema para permitir o geren-ciamento de muitos tipos de dispositivos em uma rede.
Flexcm define um conjunto de métodos de ciclo de vida e mecanismos de evento. As interfaces que um componente compilável precisa implementar são mostradas na Fi-gura 2.6. Estas interfaces permitem o ambiente de execução carregar e gerenciar cada componente de acordo com as necessidades do modelo de componentes.
Como no COM, o Flexcm também identifica suas interfaces e componentes usando GUIDs. Cada componente Flexcm tem uma interface base comum chamada IUnknown, esta interface segue a mesma idéia da interface IUnknown presente no modelo COM. Os métodos definidos são:
• addRef: Chamado em um componente quando algum outro tenta requerer alguma
de suas interfaces.
• release: Chamado quando um componente libera essa interface.
• queryInterface: Chamado pelo ambiente de execução quando um componente
re-quer uma interface de um componente.
2.3. SOFTWARE BASEADO EM COMPONENTES 17
Figura 2.6: Interfaces dos Componentes Flexcm
• connect: Chamado quando o ambiente de execução provê uma interface para o
componente.
• disconnect: Análogo ao connect, porém faz a ação contrária liberando a interface
quando chamado.
• isConnected: Usado pelo ambiente de execução para saber quando uma interface
está conectada.
• getRequiredInterfaces and getProvidedInterfaces: Usado pelo ambiente de
execu-ção para recuperar as interfaces providas e requeridas por um determinado compo-nente.
• getPorts: Retorna uma lista de objetos que implementam a interface IPort. Os da
interface IPort são semelhantes aos métodos da interface IBaseComponent, porém eles se referem apenas ao objeto que implementa a interface, não ao componente inteiro.
O ambiente de execção Flexcm é composto por quatro componentes principais, o MonitoringManager responsável por coletar informações a cerca do contexto de execução do sistema. As variáveis relevantes ao contexto de execução são dependentes do problema em questão. Por exemplo, um middleware de TV pode manter algumas variáveis que se referem a recursos que não são úteis a um sistema implementado em um celular.
O segundo componente é o ReificationManager que recupera o contexto capturado pelo MonitoringManager. Através do subcomponente InferenceEngine, este component pode inferir informações novas. Por exemplo, se a perda de pacotes de um certo compo-nente está a baixo de 1%, esse compocompo-nente pode inferir que aquele canal de comunicação não é adequado para este componente.
Capítulo 3
Cenários Relacionados
Nosso trabalho pode ser aplicado em muitos cenários, como mostrado na seção de Trabalhos Relacionados, existem muitas semelhanças entre este trabalho e muitos outros no contexto de multimídia distribuída. O principal requisito de nosso sistema é um canal de broadcast que, por exemplo, pode ser o canal físico de uma emissora de TVD ou um canal de broadcast usado em IPTV. De fato nossa arquitetura não é obrigatoriamente limitada a um canal de broadcast, porém sem ele nosso sistema é apenas outro serviço distribuído. Os cenários que serão exibidos nesta seção levarão em conta que um canal de broadcast está disponível.
3.1
Melhorar o desenvolvimento de aplicações que
mu-dam o conteúdo de programas ao Vivo
Com nosso sistema implementado em um sistema de IPTV ou DTV é possível me-lhorar o desenvolvimento de aplicações que possibilitam a interação diretamente com o ambiente da emissora. Usando nosso middleware aplicações podem facilmente requerer ou enviar dados para um dispositivo remoto visando prover aos telespectadores intera-ção com o ambiente do estúdio de TV ou mudar diretamente o conteúdo que está sendo transmitido.
Por exemplo, a Figura 3.1 mostra um cenário onde um programa de TV ao vivo provê ma câmera móvel que pode ser controlada pelo telespectador visando mudar o conteúdo do vídeo que está sendo transmitido. Outros Dispositivos de Interação podem ser integra-dos no sistema como sensores de temperatura, controles de iluminação, etc. Dessa forma os telespectadores podem interagir diretamente com o ambiente do estúdio de TV.
3.2
Melhorar o desenvolvimento de jogos interativos em
programas ao vivo
Figura 3.1: Um programa de TV ao vivo
Um Dispositivo de Interação pode um carro de brinquedo remotamente controlado e o sistema pode ser configurado para permitir apenas um número limitado de telespectadores interagirem diretamente com aquele dispositivo, dessa forma os elementos do jogo no estúdio da emissora podem ser diretamente controlados pelos telespectadores.
Figura 3.2: Jogo interativo com carro de controle remoto
Capítulo 4
Trabalhos Relacionados
Como nosso trabalho está inserido no campo de multimídia existem muitos traba-lhos tanto fortemente quanto fracamente relacionados, nesta seção apresentaremos alguns desses trabalhos, não apenas no campo da multimídia quando no campo de desenvolvi-mento de software baseado em componentes para facilitar a comunicação com diferentes hardwares.
Esta seção foi organizada agrupando os trabalhos relacionados baseado na sua su-per classe, trabalhos que não conseguimos juntar com outros foram agrupados na ultima seção.
4.1
Redes de Sensores sem fio Multimídia (WMSN’s)
Com o conceito de interconexão de diferentes sensores em uma arquitetura de rede existe o conceito das Redes de Sensores sem Fio [Akyildiz et al. 2002b] unindo este con-ceito com o de multimídia distribuída foi criado o concon-ceito das WMSN’s [I. F. Akyildiz & Chowdhury 2008, Akyildiz et al. 2002a].
Diferentemente das redes sem fio comuns aplicadas na indústria, as WMSN’s têm mais requisitos de alto nível como QoS e largura de banda. O conceito de WMSN ainda é relativamente novo, porém já existem muitas aplicações na área, a Figura 4.1 mostra a arquitetura comum usada para construir WMSN’s onde cada componente é ligado através de um canal físico ou através de hubs multimídia.
O conceito e aplicações das WMSN focam em prover aos usuários aceso a conteúdo de multimídia provido por cada dispositivo conectado na rede, como um banco de dados multimídia dinâmico. Como a rede segue os conceitos das WSN ela suporta muitos as-pectos dinâmicos apresentados em redes de sensores como adaptação e auto-organização. De acordo com nossa pesquisa algumas aplicações possíveis do conceito das WMSN’s são mostradas na Tabela 4.1, como podemos ver, aplicações focam diretamente em prover serviços como de monitoramento e coleção de dados, dessa forma os usuários podem acessar os dados e usá-los para alguma utilidade.
Figura 4.1: Arquitetura das WMSNs
WMSN [Kulkarni et al. 2005, Guhaa et al. 1995], porém como mostrado na tabela, muitas aplicações bem difundidas usam direta ou indiretamente o conceito.
Em nosso trabalho são implementados alguns dos conceitos das WMSN’s, embora nossos dispositivos interconectados não são restritos àqueles que aparecem em uma rede wireless alem de nem sempre precisarem ser fontes de multimídia de alguma forma. Em nosso sistema é construída uma rede de dispositivos interconectados que permite outros dispositivos ou aplicações interagirem, de forma bidirecional, diferentemente das redes WMSN’s onde os dados comumente seguem no sentido dispositivo-usuário.
Em adição nosso trabalho pretende implementar acesso indireto aos dados, isto é, os dados recebidos pela rede de multimídia serão enviados através do canal de difusão, isto não é muito comum em muitas das aplicações das WMSNs onde a comunicação é feita diretamente quando um usuário tenta acessar o conteúdo.
4.2
Distributed Multimedia
Continuando no campo de multimídia remota existe uma linha de pesquisa forte, os middlewares de multimídia distribuída. Esses middlewares permitem usuários acessarem conteúdo de multimídia de diferentes pontos de forma concorrente.
Muitos trabalhos nessa area [Lohse et al. 2008, Tyson & et. al. 2008] focam em prover aos usuários um middleware comum que permita aplicações conectarem e receber conteúdo de mídia distribuída. Este tipo de arquitetura comumente segue o mesmo tipo usado nas WMSN’s embora não esteja restritos ao conceito de dispositivos sem fio.
4.2. DISTRIBUTED MULTIMEDIA 23
Redes de sensores multimídia voltados à segurança
Redes de sensores de segurança podem ser usadas para melhorar ou implementar sistemas de segurança. Sistemas de controle de
trá-fego
Redes de sensores podem ser usadas para implementar sistemas avançados de controle de trafego.
Sistemas de monitoramento avançado de saúde
Com o acesso a redes de sensores sem fio multimídia é possível melhorar o monitoramento de dados de pa-cientes.
Monitoramento estrutural e ambiental
O uso de redes de sensores multimídia organizados pode ser muito útil no monitoramento de ambientes naturais ou artificiais.
Controle de Processos Indus-triais
Conteúdo de multimídia pode ser usado para melho-rar ou implementar sistemas industriais críticos ou de tempo real.
Tabela 4.1: Algumas aplicações das WMSN
Figura 4.2: Arquitetura comum em sistemas de middleware distribuído
então aplicações apenas requerem e recebem o conteúdo de multimídia.
Como mostrado na Figura 4.2, arquiteturas comuns a middleware distribuídos são descentralizadas dessa forma a arquitetura pode variar com o tipo de rede utilizada para interconectar cada ponto, diferentemente da arquitetura proposta nas WMSN que seguem o modelo centralizado onde os pontos apenas interagem diretamente com proxies que ficam remotamente localizados.
4.3
Sistemas de Teleoperação e Telepresença
Como nosso sistema define meios de comunicar e controlar dispositivos remotamente localizados através da TV observamos que conceitos de Teleoperação e Telepresença são fortemente relacionados, porém abordaremos mais o conceito de Teleoperação uma vez que o sentimento de presença ainda é muito difícil de ser simulado.
Teleoperação e telepresença são termos que comumente aparecem juntos em muitos sistemas, T.B Sheridan [Sheridan 1995] retrata o aumento no número de aplicações que usam estes conceitos visando progredir em ambas em seu trabalho são relatados os usos de desses conceitos nas áreas de biomedicina, tecnologia espacial, teleoperação de robôs e outras. Um outro trabalho mais recente [Hokayem & Spong 2006] reporta o uso de teleoperação bilateral onde um dispositivo remoto pode ser controlado e prover feedback para aumentar a sensação de imersividade do usuário.
Outro trabalho propõe uma arquitetura onde robôs móveis podem ser telecontrolados por humanos de forma colaborativa [Fong 2001]. O trabalho usa o humano como um assistente à entidade robótica dessa forma ela pode realizar melhores ações usando o feedback do humano. O termo colaborativo no trabalho deles apenas se refere a esse tipo de interação, a colaboração entre o humano e a máquina, de forma que o humano não está diretamente no controle, porém tem o poder de influenciar nas decisões da máquina. Sua relação com nosso trabalho se da no fato de que este tipo de interação onde o humano não controla diretamente o dispositivo é interessante em ambientes de multimídia onde existem muitos usuários, de fato nesse caso o humano dará uma ordem de controle porém a máquina irá decidir baseada na escolha da maioria em questão.
Um trabalho mais próximo mostra um telecontrole interativo pela internet [Goldberg et al. 2000], no trabalho deles é proposto uma arquitetura cliente-servidor onde usuários podem se conectar e teleoperar um braço robótico. Nos experimentos foi usada uma aplicação que simula uma Mesa Ouija para encorajar pessoas a se registrarem e usarem o sistema.
Na interface do sistema mostrada na Figura 4.3, os usuários eram pedidos para usar o mouse para controlar a ouija que é transmitida por uma câmera no lado do servidor. Quando mais de um usuário está tentando controlara a ouija as entradas são combinadas para produzir um único vetor de movimento. A solução de controle que eles utilizaram é a mesma que será usada por nós, em adição nosso sistema vai permitir que os operadores definam qual técnica de controle será usada.
4.4. OUTROS TRABALHOS RELACIONADOS 25
Figura 4.3: Ouija 2000, sistema implementado para testar interação multi-usuário
4.4
Outros trabalhos relacionados
Eventos são muito importantes enquanto lidamos com conteúdo de multimídia então Westermann U. and Jain R. [Westermann & Jain 2007] propuseram uma arquitetura de eventos unificados para conteúdo de multimídia distribuída, no trabalho deles são identi-ficadas necessidades de um ambiente compartilhado onde os diferentes tipos de conteúdo de multimídia sejam disponíveis.
Este trabalho é muito importante haja vista que um ambiente com conteúdo de multi-mídia compartilhado é muito similar ao nosso caso onde diferentes tipos de Dispositivos de Interação são interconectados em um ambiente compartilhado. Para identificar cada classe de eventos eles usam uma representação única mostrada na Figura 4.4, este é um modelo bem definido que podemos usar para melhorar nosso sistema.
Figura 4.4: Uma proposta de modelo unificado de eventos.
na Figura 4.4, porém planejamos implementar alguns dos conceitos propostos por eles em nosso sistema para permitir aplicações tratarem diferentes tipos de dispositivos.
Um outro trabalho bem relacionado descreve um sistema que trata sistemas embar-cados usando componentes de software [Haberl et al. 2008]. Não existe nada novo em usar software para esse fim, porém no sistema deles o foco principal é na arquitetura de componentes.
A arquitetura deles permite atualização, remoção e adição de componentes que tem uma grande similaridade com nossa arquitetura de rede. Eles usam linguagem COLA [Kugele et al. 2007] para prover a interface de declaração de componentes e gerenciar sua estrutura lógica.
4.4. OUTROS TRABALHOS RELACIONADOS 27
Capítulo 5
Sistema Proposto
Como mostrado na seção de cenários relacionados, este trabalho objetiva introduzir uma arquitetura projetada para ser uma extensão aos sistemas de difusão de TVD, para melhorar o desenvolvimento de aplicações que podem interagir diretamente com disposi-tivos remotos. No nosso caso, iremos focar especificamente em disposidisposi-tivos do lado da emissora chamados de Dispositivos de Interação como mostra a Definição 1.
Definição 1. Dispositivos de Interação: Qualquer dispositivo que permita algum tipo
de comunicação automática, de forma uni ou bidirecional, pode ser classificado como um Dispositivo de Interação.
Um dos principais requisitos para o projeto de nossa arquitetura foi não gerar grandes mudanças na arquitetura usada atualmente nos ambientes de TV digital. Baseado neste requisito principal, outras funcionalidades requisitadas por nosso sistema foram listadas na Tabela 5.1.
Requisitos
Permitir o reuso das plataformas de software já existentes nos sistemas de transmissão. Permitir a adição de novos dispositivos de interação ao sistema, em tempo de execução, sem causar problemas aos usuários.
Possibilitar o tratamento de diferentes interfaces de comunicação entre os diferentes tipos de hardware.
Melhorar o processo de implementação de aplicações capazes de se comunicarem com dispositivos de interação.
Melhorar a adaptabilidade de aplicações aos novos dispositivos adicionados ao sistema.
Tabela 5.1: Principais Requisitos do Sistema
5.1
Arquitetura do Sistema
Os três principais componentes do sistema são mostrados na Figura 5.1. Estes com-ponentes provêm os telespectadores acesso aos Dispositivos de Interação. Primeiramente precisamos organizar cada dispositivo de uma forma que eles possam se comunicar uns com os outros ou com entidades externas. Para isso organizamos eles em uma rede ló-gica, onde cada dispositivo precisa se reportar a uma entidade central chamada Device Supervisor.
Figura 5.1: Arquitetura do Sistema, blocos em verde relacionam componentes já existen-tes em sistemas de DTV, blocos azuis foram adicionados por nosso sistema.
Os componentes na arquitetura do sistema são organizados em duas camadas de rede, a física e a lógica. A camada física é responsável por conectar cada dispositivo com o Device Supervisor. Esta camada pode ser implementada usando qualquer meio físico. O Device Supervisor é responsável por tratar todos os tipos de protocolos de comunicação e API’s que sejam usadas na camada física.
A camada lógica é vista por todos os dispositivos e é acessível através do Device Network Manager. Na camada lógica, alguns dispositivos podem ser interconectados para interagir um com o outro ou apenas recuperar informação. Isto é feito de forma transparente através de passagem de mensagens pelo Device Supervisor usando uma API de comunicação única. Usando o Device Supervisor podemos transpor problemas de protocolo que podem aparecer quando diferentes dispositivos precisam comunicar uns com os outros.
É importante notar que esta arquitetura não precisa ser seguida completamente para to-dos os dispositivos que chegarem. Dispositivos de Interação de certo grupo podem definir um protocolo de comunicação interno que seja usado apenas por eles. Estes dispositivos não precisam se preocupar com os meios de comunicação que serão usados pelos outros uma vez que o Device Supervisor já trata esses tipos de problemas.
5.2. ARQUITETURA DO DEVICE SUPERVISOR 31
de comunicar com aplicações com o telespectador. Esta entidade é implementada como um middleware e usa o Interaction Manager para enviar dados para os Dispositivos de Interação. Ela também recebe dados do Device Supervisor através do canal de broadcast. As seções que seguem focam em aprofundar a descrição de cada uma dessas entidades.
5.2
Arquitetura do Device Supervisor
O Device Supervisor é projetado e implementado sobre o modelo de componentes Flexcm. Em adição às principais entidades do Flexcm foram adicionados alguns compo-nentes principalmente porque apenas os compocompo-nentes que representam os Dispositivos de Interação não são suficientes para se auto-gerenciar. Todos os novos componentes adici-onados são mostrados na Figura 5.2, em adição ao ambiente de execução Flexcm estes componentes farão o papel de gerenciamento e interconexão de cada dispositivo na rede.
Figura 5.2: Device Supervisor Components.
O Device Events Manager foca no tratamento das modificações na estrutura lógica ou física da rede. Quando um Dispositivo de Interação é adicionado, ou seu componente de software é atualizado ou removido um evento será gerado e tratado pelo componente Device Events Manager. Dessa forma um evento pode ser gerado e enviado para os teles-pectadores para mudar o que for necessário na aplicação que esteja executando do lado do telespectador.
O Device Network Manager prove meios de integrar canais de comunicações que se-jam dependentes de hardware no Device Supervisor. Quando qualquer novo dispositivo vai ser adicionado ao sistema um componente de software que trata seus protocolos de comunicação precisa ser desenvolvido e adicionado a essa entidade. Dessa forma o De-vice Network Manager é uma agregação de componentes de software representando cada dispositivo atualmente conectado ao sistema.
repetido quantas vezes for necessário para completar o conjunto de dados de todos os dispositivos na rede.
Figura 5.3: Formato do byte stream do Broadcast Data Manager.
O Broadcast Data Manager proverá também acesso aos dados que são gerados pelo Device Events Manager, as mensagens de evento terão o mesmo formato, diferindo apenas no conteúdo que terá uma tag especial permitindo que os tratadores de vento identifiquem que a mensagem é um evento e não um dado específico de um dispositivo.
O Device Manager é responsável por carregar, remover e adicionar componentes de software dos dispositivos no sistema. Trabalhando em conjunto com o Configuration Manager do Flexcm, este componente pode checar quando um componente de software é adicionando a uma base de componentes e adicioná-lo ao ambiente, uma vez que o componente de software estiver carregado no sistema o Device Network Manager será capaz de tratá-lo.
5.2.1
Serviço de Descoberta de Novos Dispositivos
A descoberta de novos dispositivos é feita pelo Device Manager através do método ping da interface IDeviceNetworkCommunication, primeiramente precisamos que um componente de software que implemente essa interface seja carregado no sistema. Uma vez desenvolvido, o componente é adicionado ao banco de componentes. O Device Ma-nager vai carregar o componente no sistema através dos métodos de reconfiguração do Flexcm e ficar esperando usando chamadas contínuas ao método ping para saber se o dispositivo está ativo na rede. As outras interfaces relativas a descoberta de novos dispo-sitivos no sistema são mostradas na Figura 5.4.
Uma vez que um componente está online na rede, o Device Manager vai instanciar um novo componente de software, que implementa ao menos a interface IDevice, e adiciona-lo ao Network Device Manager que vai ser responsável por gerenciar o novo dispositivo. Daqui para frente o Device Network Manager pode recuperar a informação necessária para inserir o dispositivo na rede e gerenciá-lo.
5.2. ARQUITETURA DO DEVICE SUPERVISOR 33
Figura 5.4: Interfaces requeridas pelo Device Network Manager.
para serem adicionados ao sistema, além de checar por novos dispositivos.
É importante notar que cada requisito de hardware necessário para comunicação com cada dispositivo na rede precisa estar acessível ao Device Supervisor, para que seja pos-sível procurar e controlar os dados dos novos dispositivos. A sequência de mensagens envolvidas no processo de adição de novos dispositivos são mostrados na Figura 5.5.
Uma vez que os componentes de software estão prontos, podemos conectar o Dispo-sitivo de Interação especifico na rede. Nesse momento, se o dispoDispo-sitivo precisar de algum tipo especifico de canal físico, o hardware e software para possibilitar a comunicação precisa ser conectado na entidade física que contem o Device Network Manager.
Figura 5.5: Sequência de eventos na adição de novos dispositivos.
com-ponente estão totalmente carregados, um evento "Comcom-ponente Chegando"será disparado para o Device Events Manager. Esta notificação vai ser capturada pelo tratador de even-tos dentro do Broadcast Data Manager, que gerará uma notificação para ser enviada aos telespectadores.
5.2.2
Removendo dispositivos
A remoção de dispositivos existentes na rede é feita similarmente à adição. Um com-ponente possui três formas de ser removido da rede lógica. Primeiramente ele pode re-portar ao Device Monitor que ele está deixando o ambiente físico, dessa forma o Device Monitor apenas precisa remover o componente de software da arquitetura e notificar o Device Event Manager para disparar um evento que notifique a saída.
A segunda maneira é quando o dispositivo é removido sem reportar. O Device Monitor vai saber que o dispositivo está fora da rede na próxima vez que um telespectador ou outro dispositivo tentar interagir com o dispositivo morto através de uma de suas interfaces de comunicação, nesse ponto o mesmo processo feito no primeiro caso será executado.
Finalmente a terceira forma é feita pelo Device Network Manager, cada período de tempo fixo esta entidade checará no sistema por dispositivos mortos chamando seu mé-todo ping. Se algum dos dispositivos não responder ao mémé-todo ping, o dispositivo será removido do sistema através do procedimento descrito no primeiro caso.
Figura 5.6: Sequência de eventos na remoção de dispositivos.
5.3. COMUNICANDO O LADO DO TELESPECTADOR COM A ARQUITETURA35
que será capturado pelo Device Manager para remover componentes de software desne-cessários ao sistema quando um dispositivo deixa a rede. O Device Network Manager vai re-organizar dispositivos que estivessem conectados ao dispositivo que saiu, disparando exceções quando algum método de um dispositivo morto tentar ser acessado.
5.3
Comunicando o lado do telespectador com a
arquite-tura
O sistema apresentado nesse trabalho objetiva possibilitar aplicações de TV digital se comunicarem, receberem informações e monitorar Dispositivos de Interação no cená-rio de programas de TV ao vivo. Porém essas aplicações são comumente desenvolvidas para um middlware de TV especifico, como o MHP, Open TV, Ginga, etc. Para permitir aplicações de TV se comunicarem com os Dispositivos de Interação de forma mais trans-parente em relação ao middleware que esteja executando no receptor do telespectador, desenvolvemos um middleware-aplicação chamado Interactive Device Provider(IDP) que foi projetado para ser implementado sobre qualquer plataforma.
O IDP permite que aplicações se comuniquem e enviem comandos ao Interaction Manager. Este componente é usado para permitir que aplicações recebam informações úteis a certa da rede de dispositivos ou de um conjunto específico deles. Aplicações usarão o IDP como uma camada de abstrações que provêm interfaces diretas com os dispositivos remotos do lado da emissora.
Nossa solução não é uma parte mandatória ao middleware de TV digital que esteja executando do lado do telespectador. Ele é transmitido através do canal de broadcast como sendo uma aplicação interativa, dessa forma o IDP pode ser transmitido e executado com aplicações que dependam dele.
5.3.1
Interactive Device Provider (IDP) Architecture
Como o IDP precisa ser visto pelas aplicações como um canal de comunicação entre elas e a rede do lado da emissora, é preciso que ele trate muitos tipos de informações que são transmitidas através de o canal de broadcast e prover essa informação para as aplicações através de APIs de auto nível.
A arquitetura interna do IDP possuí duas camadas: A Camada de Baixo nível, que é diretamente conectada à plataforma de aplicações do sistema de TV sobre o qual o IDP foi implementado; E a Camada de Aplicação, que é responsável por se comunicar dire-tamente com a aplicação. A Camada de Baixo Nível tem quatro componentes principais que são mostrados na Figura 5.7:
• Data Handler: Este componente é responsável por tratar os dados transmitidos
através do canal de broadcast. Como o IDP é transmitido para o telespectador através dos mesmos mecanismos usados para transmitir qualquer aplicação, este módulo precisa ser mudado quando for necessário tratar diferentes tipos de métodos de transporte. Este componente funciona em paralelo ao sistema visando evitar métodos bloqueantes de forma a avisar aos demais componentes quando algum dado está pronto.
• Data Manager: Este componente interpreta os dados recebidos. Dessa forma o
Data Manager pode recuperar o stream de dados do Data Handler e decodificá-lo. Em nosso sistema os dados podem ser de duas formas. O primeito tipo é usado para representar os eventos gerados pelos Dispositivos de Interação quando uma mudança qualquer é feita na arquitetura lógica ou física da rede de dispositivos. O segundo tipo é relacionado com dados específicos do dispositivo. Quando dados de um dispositivo são recebidos por esse componente ele irá atualizar uma tabela interna com o estado de cada dispositivo, quando são recebidos eventos, ele apenas os repassará para o Event Manager.
• Communication Channel Manager: Este componente gerencia a comunicação
com o canal de retorno. Quando for necessário enviar informações do telespecta-dor para um dispositivo na emissora esse componente será encarregado de fazer a utilização das APIs de canal de retorno.
Cada camada é projetada para tratar dados específicos vindo da emissora ou de apli-cações que usam o IDP. Para ser integrado com nosso middleware uma implementação do IDP precisa ser projetada usando algumas interfaces e organizando cada sub-componente das camadas em partes de software.
A Figura 5.8 mostra uma especificação de classes mais detelhadas para os componen-tes da Camada de Baixo Nível. Esta especificação provê tanto métodos de comunicação quando os mecanismos para interagir com os dados transmitidos pela emissora. Os próxi-mos componentes vão usar estes como base para permitir aplicações interagirem com os dispositivos da emissora. É importante enfatizar que componentes contidos nessa camada podem mudar para suprir o que for necessário para prover novos tipos de eventos, tratar novos tipos de dados ou interagir com novos protocolos de canal de retorno.
A Camada de Aplicação depende dos componentes descritos previamente. Esta ca-mada provê as aplicações formas de tratar os Dispositivos de Interação através de seus três componentes principais listados abaixo:
• Device Manager: Foca em identificar que tipo de dispositivo é usado do lado da
5.3. COMUNICANDO O LADO DO TELESPECTADOR COM A ARQUITETURA37
Figura 5.8: Classes e Interfaces da Camada de Baixo Nível IDP.
enviados por cada dispositivo serão acessados pela aplicação através dos métodos desse componente.
• Life Cycle Manager:Este componente serve para instanciar e gerencia cada um
dos outros componente do IDP. Este componente será o ponto de acesso a todos os outros componentes do IDP, e irá ser responsável por instanciar cada subcompo-nente e integrá-los para que seus papéis sejam desempenhados corretamente.
• Event Manager:Quando eventos são detectados entre os dados recebidos do canal
de broadcast, esses são enviados a esse componente, que se encarregará de gerar um evento para as aplicações se atualizem sobre o estado da rede de dispositivos.
Figura 5.9: Classes e interfaces da Camada de Aplicação.
Na Figura 5.9 mostramos uma possível implementação da Camada de Aplicação. Aplicações que precisem usar os componentes do IDP precisam inicializá-lo através do componente Life Cycle Manager. Dessa forma todos os componentes estarão operacio-nais e futuros dados que venham pelo canal de broadcast serão tratados e notificados à aplicação.
