Utilizando a Televisão Digital como um Meio de Comunicação para Ambientes Interativos Reais

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA Utilizando a Televisão Digital como um Meio de Comunicação para Ambientes Interativos Reais Julio Cesar Paulino de Melo Natal, RN, agosto de 2010

2 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉ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 requisitos para obtenção do título de Mestre em Ciências. Natal, RN, agosto de 2010

3 Divisão de Serviços Técnicos Catalogação da publicação na fonte. UFRN / Biblioteca Central Zila Mamede Melo, Julio Cesar Paulino de. Utilizando a Televisão Digital como um Meio de Comunicação para Ambientes Interativos Reais/ Julio Cesar Paulino de Melo - Natal, RN, f. : il Orientador: Luiz Eduardo da Cunha Leite Dissertação (mestrado) - Universidade Federal do Rio Grande do Norte. Centro 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 - Dissertação. 4. Middleware - Dissertação. I. Leite, Luiz Eduardo da Cunha. II. Universidade Federal do Rio Grande do Norte. III. Título RN/UF/BCZM CDU (043.2)

4 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 composta 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 Prof. Dr. Guido Lemos de Souza Filho DI/UFPB

5 Aos meus pais, Lourdes e Chagas, pela confiança e apoio nessa jornada.

6 Agradecimentos Ao meu orientador, professor Luiz Eduardo, sou grato pela orientação. Aos professores Aquiles, Guido Lemos, Luiz Marcos e Rudsom pelas revisões, brainstorms 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. À CAPES, pelo apoio financeiro.

7 Resumo 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 proposto é 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 TV digital.

8 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. Keywords: Middleware, Interconnected devices network, DTV applications.

9 Sumário Sumário Lista de Figuras Lista de Tabelas i iii v 1 Introdução Definição do Problema Hipóteses de Pesquisa Hipóteses Secundárias Objetivos Objetivos Específicos Contribuições Principais Organização deste Trabalho Lista de Símbolos e Abreviaturas 1 2 Embasamento Teórico Middleware Sistemas de TV digital TV Digital Redes de TV digital Interatividade nos Sistemas de TV Digital Conteúdo imperativo: Ginga-j Conteúdo declarativo Nested Context Language (NCL) Software Baseado em Componentes Modelo de componentes e ambiente de execução Flexcm Cenários Relacionados Melhorar o desenvolvimento de aplicações que mudam o conteúdo de programas ao Vivo Melhorar o desenvolvimento de jogos interativos em programas ao vivo Trabalhos Relacionados Redes de Sensores sem fio Multimídia (WMSN s) Distributed Multimedia Sistemas de Teleoperação e Telepresença i

10 4.4 Outros trabalhos relacionados Sistema Proposto Arquitetura do Sistema Arquitetura do Device Supervisor Serviço de Descoberta de Novos Dispositivos Removendo dispositivos Comunicando o lado do telespectador com a arquitetura Interactive Device Provider (IDP) Architecture Arquitetura do Interaction Manager Resultados e Testes Testes simples com sensores - Aplicação WiiMote Broadcast Data Manager Testes com Broadcast Data Manager Implemntação do IDP Avaliação dos resultados da aplicação WiiMote Controle de Dispositivo de Interação - Aplicação de Telecontrole de Galateia Componente Device Supervisor Component para Galatéia Interaction Manager e Estratégias de Controle implementadas Avaliação dos resultados para a aplicação Galateia Telecontrol Aplicação híbrida Avaliação dos resultados da Aplicação Híbrida Considerações Finais Conclusões Sumário dos objetivos específicos alcançados Definição da arquitetura do sistema Tratando Diferentes Tipos de Dispositivos Tratando diferentes tipos de protocolos de broadcast Controlando Dispositivos de Interação do lado do telespectador Aplicações implementadas e resultados de validação Contribuições Principais Avaliação Geral Trabalhos Futuros Bibliografia 55 A Informações adicionais 59

11 Lista de Figuras 2.1 Uma proposta de classificação de middleware Outra classificação de middleware proposta Uma típica rede de TV digital Representação de uma rede de TVD com canal de retorno Visão geral dos pacotes da API Java DTV Interfaces dos Componentes Flexcm Um programa de TV ao vivo Jogo interativo com carro de controle remoto Arquitetura das WMSNs Arquitetura comum em sistemas de middleware distribuído Ouija 2000, sistema implementado para testar interação multi-usuário Uma proposta de modelo unificado de eventos Aquitetura básica de Hardware/software Arquitetura do Sistema, blocos em verde relacionam componentes já existentes em sistemas de DTV, blocos azuis foram adicionados por nosso sistema Device Supervisor Components Formato do byte stream do Broadcast Data Manager Interfaces requeridas pelo Device Network Manager Sequência de eventos na adição de novos dispositivos Sequência de eventos na remoção de dispositivos Camadas e componentes do IDP Classes e Interfaces da Camada de Baixo Nível IDP Classes e interfaces da Camada de Aplicação Componentes do Interaction Manager Interfaces dos componentes do Interaction Manager Diagrama de componentes para a aplicação do Wiimote O Broadcast Data Source é uma solução temporária adotada por nós para tratar o envio de dados por um canal de broadcast O Broadcast Converter implementado para enviar dados através de arquivos do Carrossel de dados Componentes Ncl para implementar o componente Data Handler Interface implementada para a aplicação WiiMote iii

12 6.6 Diagrama de classes que implementão o Device supervisor para a aplicação Robot Control Aplicação Híbrida, tratando Galateia e WiiMote

13 Lista de Tabelas 4.1 Algumas aplicações das WMSN Principais Requisitos do Sistema v

14 Capítulo 1 Introdução Na área de pesquisas em multimídia, existem muitos esforços em direção da interatividade. 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 controle. 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 podem prover mecanismos de interação remota através dos quais os telespectadores podem 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 telespectadores 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 receber 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 interações do telespectador para criar conteúdo criado diretamente para ele. Em ambientes de TVDI, os dados enviados pelos telespectadores comumente são processados e armazenados em servidores para serem usados em um segundo momento. De outro ponto de vista os dados podem ser também enviados diretamente para dispositivos eletrônicos (robôs, por exemplo) que fazem parte do cenário de um programa de TV ao vivo. Nesse caso, os dados poderiam ser interpretados como comandos enviados pelos telespectadores para controlar os dispositivos. Dessa forma os telespectadores poderiam ver os dispositivos através da TV e controlá-los através de um controle remoto. Em um cenário mais abrangente os próprios dispositivos podem recolher informação através de sensores e enviá-la através do canal de retorno ou mesmo to canal físico de transmissão (canal de broadcast). Para facilitar a leitura do texto no escopo desse trabalho os dis-

15 2 CAPÍTULO 1. INTRODUÇÃO 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 chamados 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 telespectadores 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 projetado 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 automobilí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 coletadas 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 trazerem 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 Dispositivos de Interação para serem processados?

16 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 pelos Dispositivos. H2: Um canal de broadcast em uma estação de TV pode ser usado para transmitir 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 receptores 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 retorno presente nos padrões de TV digital para enviar comandos dos telespectadores aos Dispositivos de Interação Hipóteses Secundárias Assumindo as hipóteses de pesquisa apresentadas na seção anterior, as seguintes hipó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 pode ser usado para tartar comandos enviados por aplicações de DTV e processá-los visando controlar os Dispositivos de Interação.

17 4 CAPÍTULO 1. INTRODUÇÃO 1.3 Objetivos Nosso trabalho tem dois objetivos principais. O primeiro se resume ao projeto e implementaçã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 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 permita 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 dispositivos para aplicações executando nos receptores de TVDI [de Melo et al. 2010]. SO2: Implementar a arquitetura proposta com os requisitos necessários para permitir 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 mostrar 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 comunicaçã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 controlarem entidades reais localizadas no estúdio de TV mudando diretamente o conteúdo de vídeo ao vivo.

18 1.5. ORGANIZAÇÃO DESTE TRABALHO Organização deste Trabalho Este trabalho está dividido em seis capítulos principais, o primeiro é o Capítulo 2 onde são apresentados muitos conceitos importantes que o usuário necessita saber para entender melhor a área principal deste trabalho. O Capítulo 3 apresenta algumas aplicações que nosso sistema é capaz de implementar, este capítulo procura mostrar ao leitor alguns tipos de aplicações onde nosso sistema pode ser aplicado. Seguindo a ordem, o Capítulo 4 mostra a clássica seção de trabalhos relacionados onde pretendemos mostrar alguns trabalhos que consideramos relacionados com o nosso de alguma forma. Os próximos dois capítulos Capítulo 5 e 6 estão relacionados com o projeto, implementação e testes do sistema. Finalmente o ultimo Capítulo 7 onde discutimos os resultados gerais e trabalhos futuros a serem realizados.

19 6 CAPÍTULO 1. INTRODUÇÃO

20 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 essas 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 finalizando 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 implementaçõ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 invé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]. O primeiro tipo proposto é o Host Infrastructure Middlewaere que foca em prover meios comuns de comunicação e descrição de diferentes aplicações. Este tipo de middlewaere provê serviços para criar e reusar multiplexação de eventos, comunicação interprocessos, concorrência e objetos de sincronização. Essa classe pode ser facilmente comparada com as máquinas virtuais que são necessárias para execução de algumas lin-

21 8 CAPÍTULO 2. EMBASAMENTO TEÓRICO 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 operacional, 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 Middleware e Specific Domain Middleware. O primeiro tipo está relacionado com middlewares 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 especí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 ilustraçã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 implementaçõ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 soluçã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 atravé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 converte as chamadas para uma linguagem comum. Message Oriented Middleware (MOM): Este tipo é composto principalmente por arquiteturas baseadas em eventos com clientes remotos. Esta classe pode ainda ser dividida em mais duas, os middlewares Publish/Subscribe e os Passing/Queeing

22 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 componentes de software, onde pedaços de software podem ser montadas formando um sistema mais flexível. Os componentes de software podem estar localmente ou remotamente 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 Artificial 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. O conjunto dos Application Middlewares é dividido em mais cinco classes. Este conjunto cobre classes que preenchem requisitos de aplicações específicas:

23 10 CAPÍTULO 2. EMBASAMENTO TEÓRICO 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 remotamente 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, , cobranç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 requisitos 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. Esta outra classificação é mais especifica o que nos permite entender melhor o que um middleware pode ser, porém ainda é difícil dizer de forma direta se um determinado sistema é um middleware ou não, por exemplo, nessa ultima classificação não classifica as máquinas virtuais como middlewares, porém é fato que possuem muitas características

24 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 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 sinais 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 transmitir uma maior quantidade de informação multiplexada, em comparação ao sistema analó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 simultaneamente (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 Projeto DVB (DVB Project), um consórcio composto por mais de 270 membros, e que são publicados por um comitê formado por ETSI (European Telecommunications Standards Institute ), CENELEC (European Committee for Electrotechnical Standardization ) e EBU (European Broadcasting Union ). Atualmente estima-se

25 12 CAPÍTULO 2. EMBASAMENTO TEÓRICO 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 desenvolvidos e mantidos 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 transmissão terrestre japonês (ISDB-T) aliado à tecnologia desenvolvida no Brasil como uma API para desenvolvimento de aplicações que utilizem recursos de dispositivos (como celulares, PDAs, etc) em uma HAN (Home Area Network). Teve sua primeira transmissão oficial em 2 dezembro de 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 codificaçã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 gerenciar 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 transmitidos 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 sistemas é 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 fluxo de transporte recebido das emissoras. Esse receptor, que na sua forma desacoplada é conhecido como set-top box, pode ser visto como um computador adaptado para as necessidades do ambiente televisivo, possuindo processador, memória, sistema operacional, etc. Nele é instalado um middleware que implementa uma camada de abstração possibilitando a execução de aplicações comuns em set-top boxes de fabricantes e especificações de hardware diferentes.

26 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 Interatividade nos Sistemas de TV Digital Atualmente os sistemas de Televisão Digital especificam uma camada de middleware, sobre a qual as aplicações interativas para TV podem ser executadas. O middleware de TVD controla as principais facilidades disponíveis no receptor, tais como grade de programação, menus de opção e a possibilidade de execução de aplicações, fazendo com que a TV Digital possua caráter interativo. O middleware é capaz de fornecer uma abstração do sistema para as aplicações e os usuários, escondendo toda a complexidade dos mecanis-

27 14 CAPÍTULO 2. EMBASAMENTO TEÓRICO 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 Digital 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 semelhante, foi elaborada uma norma desenvolvida com base no middleware DVB MHP (Multimedia Home Platform) denominada GEM (Globally Executable MHP) [Globally Executable MHP (GEM) Specification ], que identifica e dá suporte a APIs independentes de sistema específico. Essa especificação é atualmente adotada pelos padrões de middleware procedural japonês (ARIB B.23) [Application Execution Engine Platform 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, obviamente, o europeu (MHP) [Globally Executable MHP (GEM) Specification ] 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. Este fato tornou difícil a implementação do Ginga-J no começo da operação da TV digital no Brasil. A necessidade de royalties no MHP encorajou o desenvolvimento de

28 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 Conteúdo declarativo Nested Context Language (NCL) Como dito antes NCL é o middleware declarativo usado no Ginga. NCL é uma linguagem 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 segundos 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, documentos 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 Projetos baseados em componentes são ferramentas bastante conhecidas na área de desenvolvimento de software, encontrados em muitos produtos importantes como Sun

29 16 CAPÍTULO 2. EMBASAMENTO TEÓRICO 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 componente 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 componentes para fazer o sistema como um todo funcionar junta. Projeto baseado em componentes não é caracterizado pela granularidade dos componentes, mas pela sua equivalência 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 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 componentes 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 gerenciamento 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 Figura 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 requer uma interface de um componente. Os componentes Flexcm explicitamente declaram suas interfaces providas e requeridas, eles podem ainda prover informações sobre o status de conexão de suas interfaces e reconectar quando necessário. Todas essas características são providas através da interface IBaseComponent. Esta interface define os seguintes métodos:

30 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 componente. 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 componente está a baixo de 1%, esse componente pode inferir que aquele canal de comunicação não é adequado para este componente. Os últimos componentes são o ConfigurationManager e o CommunicationManager,

31 18 CAPÍTULO 2. EMBASAMENTO TEÓRICO o primeiro é responsável pelo carregamento e configuração da arquitetura de componentes além do gerenciamento de cada um. O segundo é uma ferramenta que permite aos componentes se comunicarem uns com os outros.

32 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 mudam o conteúdo de programas ao Vivo Com nosso sistema implementado em um sistema de IPTV ou DTV é possível melhorar 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 integrados 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 É comum a presença de atividades competitivas em shows de TV onde o telespectador interage através de uma linha telefônica para completar uma dada atividade para ganhar certo prêmio. Neste caso nossa arquitetura pode permitir que o telespectador controle um Dispositivo de Interação para completar a mesma atividade de uma forma mais interativa.

33 20 CAPÍTULO 3. CENÁRIOS RELACIONADOS 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 O tipo de aplicação ilustrado na Figura 3.2 é suportado por muitos sistemas de broadcast que provêm canais de retorno, a diferença é que aplicações precisam ser completamente escritas pela emissora desde a arquitetura de controle até a aplicação que executará no lado do telespectador, usando nosso sistema o desenvolvimento poderia ser mais rápido viabilizando a aplicação.

34 Capítulo 4 Trabalhos Relacionados Como nosso trabalho está inserido no campo de multimídia existem muitos trabalhos tanto fortemente quanto fracamente relacionados, nesta seção apresentaremos alguns desses trabalhos, não apenas no campo da multimídia quando no campo de desenvolvimento 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 super 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 conceito com o de multimídia distribuída foi criado o conceito 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 aspectos 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. Como o campo das WMSN é novo não existem ainda aplicações que usam diretamente seu conceito, foram encontrados muitos trabalhos que relatam sobre protocolos de roteamento, arquitetura de rede [Gerla & Xu 2003, Tezcan & Wang 2008, Shu et al. 2007], porém apenas poucos desses trabalhos mencionam diretamente o conceito de

35 22 CAPÍTULO 4. TRABALHOS RELACIONADOS 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. Este tipo de arquitetura é comumente massivamente distribuída, embora como nas WMSN s em muitos dos casos o canal de comunicação é usado apenas em um sentido,

36 4.2. DISTRIBUTED MULTIMEDIA 23 Redes de sensores multimídia voltados à segurança Sistemas de controle de tráfego Sistemas de monitoramento avançado de saúde Monitoramento estrutural e ambiental Controle de Processos Industriais Redes de sensores de segurança podem ser usadas para melhorar ou implementar sistemas de segurança. Redes de sensores podem ser usadas para implementar sistemas avançados de controle de trafego. Com o acesso a redes de sensores sem fio multimídia é possível melhorar o monitoramento de dados de pacientes. O uso de redes de sensores multimídia organizados pode ser muito útil no monitoramento de ambientes naturais ou artificiais. Conteúdo de multimídia pode ser usado para melhorar 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. A arquitetura de middleware distribuído é relacionada com nosso trabalho, pois iremos prover para as aplicações um middleware para simplificar a comunicação que haverá entre os telespectadores e os dispositivos remotos. Nosso middleware pode ser classificado como um middleware distribuído que compartilha a rede de dispositivos na emissora com o conteúdo da aplicação no telespectador, em adição nós provemos às aplicações um canal de comunicação bidirecional que não é provido normalmente em middlewares distribuídos de multimídia.

37 24 CAPÍTULO 4. TRABALHOS RELACIONADOS 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. Um outro trabalho fortemente relacionado apresenta estudos sobre o impacto de prover telepresença à telespectadores de TV [Kim 1997]. O estudo apresentado é baseado em resultados experimentais obtidos com a manipulação de duas variáveis principais, os estímulos visuais e o ângulo de visão. Com os resultados obtidos foi proposto um modelo que relata a experiência do telespectador sobre o conteúdo de mídia. Os experimentos mostram que pessoas são mais susceptíveis a comerciais quando eles sentem o estado de telepresença. Embora o trabalho deles seja relacionado com o nosso, em nosso trabalho não estamos realizando experimentos sobre as reações do telespectador, mas provendo uma forma de implementar teleoperação e telepresença em multimídia. Uma outra diferença é nosso sistema não muda nada no ambiente do lado do telespectador.

38 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 identificadas 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 multimí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. Como eventos são importantes em sistemas de multimídia nossa arquitetura provê um canal de eventos que permite aos dispositivos enviarem eventos para as aplicações do lado do telespectador. Nosso sistema de eventos é bem mais simples do que o mostrado

39 26 CAPÍTULO 4. TRABALHOS RELACIONADOS 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 embarcados 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. A diferença entre a arquitetura usada por eles e a usada por nós é a ausência de um middleware distribuído. De fato o trabalho mostrado por eles tem um tipo de serviço distribuído que é usado para conectar entidades, mas não permite que essas entidades interajam. Em adição no nosso sistema de componentes usamos o modelo Flexcm ao invés da linguagem COLA.

40 4.4. OUTROS TRABALHOS RELACIONADOS 27 Figura 4.5: Aquitetura básica de Hardware/software.

41 28 CAPÍTULO 4. TRABALHOS RELACIONADOS

42 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 dispositivos remotos. No nosso caso, iremos focar especificamente em dispositivos 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 Para implementar uma solução genérica para o sistema, sua arquitetura foi dividida em três entidades principais. Duas delas estão localizadas na emissora: o Device Supervisor, que é responsável por tratar toda os Dispositivos de Interação e organizá-los como uma rede lógica e física; e o Interaction Manager, que deve tratar o canal de comunicação com os telespectadores, permitindo que eles interajam com os Dispositivos de Interação na rede. O outro componente está do lado do telespectador: o Interaction Device Provider, que é um middleware a nível de aplicação que provê API s e mecanismos para permitir que aplicações de DTV interajam com os Dispositivos de Interação.

43 30 CAPÍTULO 5. SISTEMA PROPOSTO 5.1 Arquitetura do Sistema Os três principais componentes do sistema são mostrados na Figura 5.1. Estes componentes 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á existentes 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 todos 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. A terceira entidade da arquitetura é o Interactive Device Provider, que está a cargo

44 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 componentes principalmente porque apenas os componentes que representam os Dispositivos de Interação não são suficientes para se auto-gerenciar. Todos os novos componentes adicionados 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 telespectadores 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 sejam 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 Device Network Manager é uma agregação de componentes de software representando cada dispositivo atualmente conectado ao sistema. O componente Broadcast Data Manager é usado por componentes de software externos para recuperar dados de cada dispositivo na rede e transmiti-los para os telespectadores através do canal de broadcast. Este componente prove acesso a um stream de bytes que contem todos os dados contidos em cada dispositivo na rede. Os dados são descritos na forma de bytes de acordo com a especificação na Figura 5.3, o segundo campo será

45 32 CAPÍTULO 5. SISTEMA PROPOSTO 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 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 Manager 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 dispositivos 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 adicionalo 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. Após um período de 10 segundos ou algum outro tempo especificado pelo operador do sistema, o Device Manager pode checar se existem novos componentes de software

46 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 possí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 Dispositivo de Interação especifico na rede. Nesse momento, se o dispositivo 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. Quando os componentes de software requeridos para interfacear com o novo com-

47 34 CAPÍTULO 5. SISTEMA PROPOSTO ponente estão totalmente carregados, um evento "Componente Chegando"será disparado para o Device Events Manager. Esta notificação vai ser capturada pelo tratador de eventos dentro do Broadcast Data Manager, que gerará uma notificação para ser enviada aos telespectadores Removendo dispositivos A remoção de dispositivos existentes na rede é feita similarmente à adição. Um componente possui três formas de ser removido da rede lógica. Primeiramente ele pode reportar 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é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. Na Figura 5.6 podemos ver a sequência de mensagens nas três situações onde um dispositivo é removido. Em ambos os casos o Component Event Handler vai gerar um evento

48 5.3. COMUNICANDO O LADO DO TELESPECTADOR COM A ARQUITETURA35 que será capturado pelo Device Manager para remover componentes de software desnecessá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 arquitetura 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 transparente 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 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. Figura 5.7: Camadas e componentes do IDP.