Cementing Operations:

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.

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

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.

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.

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 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.

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