PUC

Monografia em Ciência da Computação

Atuação na Presença de Conectividade Intermitente

Bruno Azevedo Chagas

Departamento de Informática

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO

RUA MARQUÊS DE SÃO VICENTE, 225 - CEP 22451-900

RIO DE JANEIRO - BRASIL

Atuação na Presença de Conectividade Intermitente

Bruno Azevedo Chagas

bchagas@inf.puc-rio.br

Abstract. In this work, we propose an approach to deal with distributed actuation in ubiquitous computing environments, such as Internet of Things (IoT) environments with various connected devices. We present an approach based on an analogy with transactions in Web Services to enable a sequence of action commands in physical ele-ments to run in a managed way. The main feature of our proposal is to use a physical transaction abstraction for the controlled execution of distributed action commands. We seek a characterization of this problem and propose strategies to treat it properly, with the background motivation of a technology to provide multimodal interaction in a smart environment. Our contribution is to propose the integration of concepts of multi-modal interaction and service-oriented architectures (SOA and Web Services) to sup-port the development of more effective and improved ubiquitous computing environ-ments and applications, from the perspective of users’ interaction.

Keywords: Internet of Things, Ubiquitous Computing, Actuator, Multimodal Interac-tion, Middleware.

Resumo. Neste trabalho propomos uma abordagem para tratar de atuação distribuída em ambientes de computação ubíqua, como por exemplo ambientes de Internet das Coisas (IoT – Internet of Things) com diversos dispositivos conectados. Apresentamos uma abordagem baseada em uma analogia com transações em Web Services para pos-sibilitar que uma sequência de comandos de atuação em ambientes físicos seja execu-tada de forma gerenciada. A principal característica da nossa proposta é usar uma abs-tração de transação física para a efetivação controlada de comandos de atuação de for-ma distribuída. Procuramos uma caracterização para este problema, bem como propor estratégias para tratá-lo de forma adequada, tendo como pano de fundo o cenário mo-tivacional de uma tecnologia para prover interação multimodal em um ambiente “smart”. Nossa contribuição é propor a integração de conceitos de interação multimo-dal e arquiteturas orientadas a serviços (SOA e Web Services) para apoiar o desenvol-vimento de ambientes e aplicações de Computação Ubíqua mais eficazes e melhorados, a partir da perspectiva da interação dos usuários.

Palavras-chave: Internet das Coisas, Computação Ubíqua, Atuadores, Interação Mul-timodal, Middleware.

ii

Responsável por publicações:

Rosane Teles Lins Castilho Assessoria de Biblioteca, Documentação e Informação PUC-Rio Departamento de Informática Rua Marquês de São Vicente, 225 - Gávea 22451-900 Rio de Janeiro RJ Brasil Tel. +55 21 3527-1516 Fax: +55 21 3527-1530 E-mail: bib-di@inf.puc-rio.br Web site: http://bib-di.inf.puc-rio.br/techreports/

iii

Sumário

1 Introdução 1

2 Interação multimodal 1

3 Interação multimodal e Computação ubíqua 3

4 Atuação distribuída 3

4.1 Transações físicas 4

4.2 Transações em Web Services 5

4.3 Estratégias para tratamento de atuação distribuída 7

5 Juntando tudo: um exemplo de aplicação 10

6 Conclusão 11

Referências 12

1

1 Introdução

Na Internet das Coisas (IoT – Internet of Things), dispositivos periféricos podem ser con-trolados remotamente a partir de outros dispositivos – como smartphones – através de conectividade sem fio de curto alcance, como o Bluetooth. De acordo com comandos recebidos, estes dispositivos podem ter seu estado modificado e promover um efeito no ambiente ao redor (mover-se, modificar a luminosidade, a temperatura, etc.). Devi-do à natureza efêmera e instável da conectividade em tais ambientes, os comandos de atuação podem não ser completamente executados ou confirmados pelos dispositivos. O problema se agrava se considerarmos a heterogeneidade de dispositivos, suas carac-terísticas e estados que podem ser encontrados em um determinado ambiente, onde problemas de falta de energia ou mesmo impedimentos físicos podem modificar a res-posta de um determinado dispositivo a um controle.

Neste trabalho, procuramos uma caracterização para este problema, bem como pro-por estratégias para tratá-lo de forma adequada, tendo como pano de fundo o cenário motivacional de uma tecnologia para prover interação multimodal em um ambiente “smart”. Este trabalho está estruturado da seguinte forma: esta breve introdução, se-guida de uma apresentação do conceito de interação multimodal na seção 2 . Na seção 3 relacionamos este conceito com a computação ubíqua, o que compõe o panorama da nossa motivação para este trabalho. Na seção 4 caracterizamos atuação distribuída, o tema principal do trabalho, bem como fundamentamos e apresentamos as estratégias propostas para tratamento do assunto. Na seção 5 procuramos integrar os conceitos apresentados até então em uma aplicação de exemplo que consideramos útil, de forma a relacionar os conceitos apresentados com o nosso panorama motivacional. Finalmen-te, na seção 6 apresentamos nossas conclusões e apontamos para algumas direções que nos parecem relevantes de trabalhos futuros.

2 Interação multimodal

No sentido geral, um sistema multimodal suporta a comunicação com o usuário atra-vés de diferentes modalidades, tais como voz, o gesto, e digitando. Desde a concepção das primeiras GUIs (Graphical User Interfaces), o paradigma WIMP (Windows, Icons, Menus, and Pointing device) tem sido o modelo mais utilizado para a interação huma-no-computador (van Dam, 1997). Esse paradigma utiliza-se, principalmente, de gráfi-cos e interações por meio de dispositivos de tecla (e.g. teclado, controle remoto) e apon-tadores (e.g. mouse). O trabalho seminal “put-that-there” de Bolt (Bolt, 1980), no entan-to, trouxe o conceito de interação multimodal. Neste tipo de interação, os usuários po-dem interagir com computadores por meio de múltiplas modalidades e sensores de forma orquestrada (Turk, 2014). Uma modalidade é um estímulo sobre um determina-do sentido humano (audição, olfato, tato, paladar, ou visão). Um sensor particular é um dispositivo no qual informações geradas pelo usuário são adquiridas (teclados para aquisição de texto, microfones, reconhecedores de gestos etc.). Literalmente, "multi" refere-se a "mais do que um" e o termo "modal" pode abranger a noção de "modalida-de", i.e., o tipo de canal de comunicação utilizado para transmitir ou adquirir informa-ção, bem como a de "modo", i.e., o estado que determina a forma como a informação é interpretada para extrair ou transmitir um significado (Nigay & Coutaz, 1993).

Para exemplificar, considere o trabalho “put-that-there”, que propõe um sistema para planejamento tático de unidades militares em um mapa, por meio de interações mul-

2

timodais como gestos e comandos de voz. O usuário pode mover uma unidade apon-tando-lhe seu dedo e realizando o comando de voz “put that”, receber como resposta uma voz sintetizada com a pergunta “where?”, apontar para a posição desejada e em seguida falar “there”. Essas funcionalidades são suportadas por meio de reconhecedo-res e sintetizadores. Os reconhecedores identificam determinadas informações em sen-sores — e.g., os reconhecedores de gestos e fala (ASR – Audio Speech Recognition). Já os sintetizadores produzem informações percebidas pelos sentidos humanos — e.g., sintetizadores de texto para fala (TTS – Text-To-Speech), avatar 3D (indivíduo virtual para interagir com o usuário) e diversos atuadores (e.g. iluminação, movimento e chei-ro).

A interação multimodal pode ser representada como um loop conforme ilustrado na Figura 1. As diversas entradas são combinadas em um processo de fusão, onde o sis-tema infere, a partir das diversas informações sensoreadas, a intenção do usuário. Esta intenção é então transformada numa mudança do estado do sistema, que será comuni-cada para o usuário através de diversas saídas, em um processo análogo a fusão, cha-mado fissão.

Figura 1 – Uma representação do loop de interação multimodal (Dumas, et al., 2009).

Do ponto de vista da arquitetura de sistemas, a interação multimodal introduz sig-nificativas complexidades: o sistema precisa perceber e processar múltiplas entradas, em paralelo, de forma contínua, distribuída e, muitas vezes, probabilística (Dumas, et al., 2009). Naturalmente, isso exige um sistema consideravelmente mais sofisticado, capaz de realizar estes processamentos em um tempo de resposta adequado para o usuário.

A natureza mais sofisticada das aplicações multimodais pode ainda ser considera-velmente ampliada se aplicarmos estes conceitos em um contexto de computação ubí-qua, onde o usuário interage não com um sistema apenas, mas com um ecossistema de dispositivos ao seu redor.

3

3 Interação multimodal e Computação ubíqua

A Computação ubíqua (Weiser, 1991) propõe melhorar o uso do computador fazendo o uso de muitos computadores disponíveis e embarcados no ambiente físico, enquanto tornando-os invisíveis para o usuário, que estaria interagindo continuamente com cen-tenas de computadores sem fio interligados nas proximidades (Weiser, 1993). Em tal contexto, a interação multimodal parece ser uma alternativa bastante natural e útil para prover os (ecos)sistemas com a inteligência necessária para responder aos usuários. Em especial, as tecnologias de sensores, atuadores, interação e conectividade desenvolvi-das na comunidade de Computação ubíqua podem prover tanto uma infraestrutura de implementação como um terreno fértil para aplicação das técnicas, conceitos e arquite-turas de interação multimodal.

Um exemplo interessante foi investigado por Perry et al. (2004), onde interação mul-timodal foi utilizada em uma “smart home” para prover assistência a pessoas idosas em viver de forma independente. O sistema foi concebido para proporcionar informações sensíveis ao contexto ao residente, que poderia interagir com o sistema através de voz e gestos de modo que, juntamente com as informações do ambiente e da atividade dos dispositivos no ambiente, eliminam a necessidade de dispositivos auxiliares para inte-ração.

Estudos abrangendo interação multimodal neste contexto oferecem um grande po-tencial de pesquisa em diversas áreas, da Interação Humano-Computador aos Sistemas Distribuídos, de modo que acreditamos que a troca de experiências entre essas comu-nidades se faz cada vez mais necessária. Por exemplo, interações multimodais são normalmente consideradas em cenários com um único usuário e um único sistema, de modo que interação entre usuários e um ecossistema de computação ubíqua ainda é um tópico a ser melhor investigado. Outro tópico aparentemente negligenciado, é o tratamento de atuação em tais contextos. Aparentemente, uma ênfase maior é dada na parte de sensoriamento como forma de obter informações de contexto sobre os usuá-rios em ambientes “smart”. Isso está diretamente relacionado ao processo de fusão das entradas no sistema, ao passo que a atuação estaria mais relacionada ao processo de fissão, na parte da geração das saídas do loop multimodal. Assim sendo, parece haver necessidade de mais estudos sobre técnicas e formas de atuação de usuários sobre os ambientes, o que envolve em muitas situações lhe dar com múltiplos usuários e com um ecossistema de dispositivos ao redor, aumentando consideravelmente a complexi-dade da tecnologia necessária.

4 Atuação distribuída

Atuadores são elementos que produzem movimento, atendendo a comandos que po-dem ser manuais, elétricos ou mecânicos1. Como exemplo, pode-se citar atuadores de movimento, como motores, válvulas, luzes ou qualquer elemento que realize um co-mando recebido de outro dispositivo, com base em um comando de entrada a ser se-guido. Em um sistema mais complexo, normalmente interagimos com uma série de atuadores, que podemos chamar aqui de dispositivos periféricos. Neste trabalho, nos re-ferimos a dispositivo periférico como um dispositivo conectado que é capaz de modifi-car o ambiente com ações. Pode se tratar de uma luz, um ar condicionado, um aparelho de TV ou uma cortina, conectada a uma rede local que permite o seu controle remoto.

1 WIKIPEDIA, 2015. Atuador. [Online] Disponível em: http://pt.wikipedia.org/wiki/Atuador [Acesso

em 06 12 2015].

4

Assim sendo, não estamos pensando em um atuador isoladamente, mas em um dispo-sitivo que, por meio de seus atuadores, modifica o estado do ambiente onde está inse-rido. A maneira de se modificar o estado do ambiente é enviando comandos para os periféricos.

Alguns periféricos, mais básicos, são capazes apenas de responder comandos indi-viduais. Por exemplo, uma luz pode apenas responder aos comandos de “ligar” e “des-ligar”. Outros, tem a capacidade de executar internamente uma lista de comandos em sequência, para assim se atingir um estado final desejado. Por exemplo, uma cortina do tipo persiana pode responder a um comando “escurecer totalmente” de modo que exe-cuta um comando para expandir até o final primeiro, seguido de um comando para fechar as suas palhetas. Há ainda a possibilidade de se combinar múltiplos periféricos de modo a se atingir um objetivo desejado no ambiente. Por exemplo, ao deitar-se, um usuário gosta de dormir com o quarto totalmente escuro, o que pode ser obtido com o comando de “desligar” para a luz, seguido de um comando “escurecer totalmente” pa-ra a cortina. Outro ainda pode gostar de uma luz ambiente fraca, e agrega ao final des-ta sequência um comando para ligar uma luz ambiente (e.g., uma luminária) em uma intensidade fraca. E assim sucessivamente. Com isso, introduzimos o conceito de Plano de Atuação, que compreende a sequência de comandos de atuação que devem executados com o objetivo de se obter um determinado estado final no ecossistema. Tal plano de atuação pode envolver um ou mais dispositivos periféricos, assim como outros sub-planos de atua-ção, alguns internos aos dispositivos afetados (e.g., “escurecer totalmente”), outros ainda definidos pelo usuário ou pelo próprio sistema em sua estratégia de execução. É importante ressaltar ainda que, em algumas situações, o ecossistema pode desempe-nhar diversas atuações em paralelo (como por exemplo, no caso do plano de atuação pa-ra dormir citado acima). Em outras contudo, um sequência determinada das ações é desejada, de modo que o resultado possa ser alcançado, onde uma ação só pode ser executada após concluída a anterior. Pense por exemplo em um sistema de segurança doméstico, onde o alarme só pode ser ligado após as portas estarem trancadas e estas são trancadas, por sua vez, 15 segundos após o usuário sair de casa. Repare que a exe-cução de um plano de atuação corresponde exatamente ao processo de fissão na parte da geração das saídas do loop de interação multimodal, se pensarmos os atuadores co-mo os dispositivos que irão produzir os estímulos de feedback para o usuário.

4.1 Transações físicas

O conceito de Plano de Atuação introduzido na seção anterior pode ser pensado como uma transação física. Na área de banco de dados, uma transação é uma sequência de operações num sistema de gerência de banco de dados que são tratadas como um bloco único e indivisível (atômico) durante uma recuperação de falhas, capaz também de prover isolamento entre acessos concorrentes na mesma massa de dados. Analogamen-te, propomos o conceito de transação física como uma sequência de operações indivisíveis no mundo físico que correspondem a uma operação lógica atômica para alguma entidade controla-dora, capaz também de prover gerenciamento de concorrência no acesso aos recursos físicos con-trolados. Do ponto de vista lógico e teórico, não há diferenças conceituais entre um transação física e uma transação em um sistema de banco de dados, por exemplo. No entanto, em nossa definição incluímos dois aspectos que tornam a aplicação prática do conceito de transação no mundo físico diferenciada. Primeiramente, enfatizamos o fato de estarmos tratando de características do mundo físico ao nosso redor. Claro que po-demos pensar que a escrita e leitura de dados em um banco de dados é, em última ins-tância, um efeito no mundo físico, que ocorre eletromagneticamente nos dispositivos

5

de memória do banco de dados. No entanto, a escala de tempo e de tamanho deste efei-to nos faz praticamente abstrair os fenômenos físicos, e pensarmos apenas em termos lógicos sobre os dados. No caso das transações físicas, estes efeitos são notáveis nas su-as dimensões do mundo físico, ocorrendo em uma escala de tempo bem maior, de mo-do que o efeito físico e o tempo para obtê-lo em si não podem ser ignorados. Outro as-pecto que também destacamos na nossa definição é a existência de um referencial, que chamamos entidade controladora. Com isso queremos enfatizar que os limites do bloco que delimitam a transação são definidos por um referencial: para um dispositivo, a transação pode começar e terminar de acordo com as suas capacidades de atuação, mas para o usuário, por exemplo, uma transação pode ser uma operação de mais alto nível, que afeta vários dispositivos (pense por exemplo no caso do comando “preparar para dormir” do usuário, que se desmembra em um comando “escurecer totalmente” para a cortina).

Observado por este enfoque, transações físicas sobre um ecossistema, mesmo que em uma área local, apresentam uma forte analogia com transações distribuídas em sis-temas de arquitetura orientada a serviços (SOA – Service Oriented Architectures), co-mo o caso de sistemas baseados em Web Services. Aplicações baseadas em Web Servi-ces devem garantir a manipulação de dados de forma consistente e os resultados dos processos de negócios. É comum que os serviços de negócio neste contexto executem em vários provedores de serviços diferentes e fracamente acoplados, podendo demorar horas ou até dias para serem completados, de modo que nos parece fazer sentido re-correr a literatura que trata de transações em Web Services para buscar recursos que possam ser aplicados no contexto do que estamos chamando de transações físicas.

4.2 Transações em Web Services

Desde a sua criação, as tecnologias de Web Services vem sendo ampliadas para prover funcionalidades de processamento de transações (Choi, et al., 2005). Transações de Web Services combinam vários serviços, possivelmente localizados em sistemas hete-rogêneos, em uma única operação lógica (Paul, et al., 2007). Elas podem, portanto, ser pensadas como transações em bancos de dados distribuídos, também chamados de multi-bancos de dados (multidatabases). Tipicamente, as tradicionais propriedades ACID de transações de bases de dados (Atomicidade, Consistência, Isolamento e Du-rabilidade) são relaxadas em tais sistemas, pois os bloqueios e restrições necessárias reduziriam severamente a utilidade do sistema (Paul, et al., 2007).

Alguns protocolos foram propostos para tratamento de transações com Web Servi-ces. Dentre eles, destacamos o WS-Transaction (OASIS, 2009; OASIS, 2007) e o fra-mework WS-Coordination (OASIS, 2009a) como os mais populares para utilização na prática e objetos de estudo na literatura relacionada (Curbera, et al., 2003; Choi, et al., 2005; Alrifai, et al., 2006).

A especificação WS-Coordination (OASIS, 2009a) define um framework que procura estabelecer uma visão comum sobre o resultado final de um processo transacional ba-seado em Web Services, independentemente do protocolo de transação específico utili-zado. Ele define dois conceitos-chave: 1) o Coordenador, que é uma entidade que resi-de no lado do cliente e é responsável por alcançar um resultado da transação acordado globalmente do ponto de vista do cliente, 2) o Participante, que é uma entidade que reside no lado do provedor do serviço e é responsável pela comunicação com o Coor-denador de acordo com o protocolo (Figura 2).

6

Figura 2 – Representação do WS-Coordination framework (Alrifai, et al., 2006).

A especificação WS-Transaction (OASIS, 2009; OASIS, 2007) se conecta ao framework WS-Coordination e descreve dois modelos de protocolo de transações para suportar a semântica de dois tipos de interação de negócio em alto-nível: AtomicTransaction (AT), que é semelhante às transações ACID tradicionais e destina-se a interações de curta du-ração, e BusinessActivity (BA), que se destina a transações de longa duração, onde os critérios ACID são relaxados entre sistemas fracamente acoplados onde bloqueio de recursos com exclusividade é impossível ou não é prático. No âmbito de uma Atomic-Transaction, o coordenador dirige todos os participantes, quer para todos completem (commit) ou cancelem (rollback) tudo, ao passo que no âmbito de uma BusinessActivity, o coordenador poderá instruir cada participante individualmente. Ainda é útil aprofun-darmos um pouco mais de BusinessActivity (OASIS, 2007) que define dois protocolos de coordenação específicos que podem ser usados com o framework extensível do WS-Coordination: BusinessAgreementWithCoordinatorCompletion e BusinessAgreementWithPar-ticipantCompletion. No primeiro, os participantes contam com o coordenador para in-formá-los quando tiverem recebido todas as solicitações para realizar o trabalho dentro da atividade solicitada, enquanto que no último, os próprios participantes sabem quando tiverem concluído todas as solicitações e devem comunicar ao coordenador sobre isso. A Figura 3 ilustra o diagrama de estados abstratos para as duas situações. Mais do que os detalhes específicos de cada protocolo definido, chamamos a atenção para a etapa de compensação, que permite que um serviço mesmo após completo, rever-ta o seu estado no caso da necessidade de um rollback.

7

Figura 3 – Diagrama de estados abstratos para os protocolos propostos pela especificação WS-BusinessActivity: (a) BusinessAgreementWithCoordinatorCompletion e (b) BusinessAgreementWithParticipantCompletion (Alrifai, et al., 2006).

4.3 Estratégias para tratamento de atuação distribuída

Baseado nas estratégias de transações com Web Services apresentadas na seção anterio-res, nós agora propomos uma estratégia análoga para tratamento de transações físicas. Propomos um framework de coordenação de interação baseado em dois papéis: 1) Co-ordenador, o dispositivo responsável por disparar e orquestrar todos os comandos ne-cessários para atingir uma determinada finalidade; e 2) Participante, o dispositivo peri-férico, capaz de responder a comandos que irão provocar efeitos no mundo físico ao redor. Analogamente ao caso com Web Services, podemos considerar que há dois tipos de transações físicas: atômicas, que são executadas instantaneamente e conseguem ga-rantir as propriedades ACID tradicionais de transações, e operações, que exigem tempo (perceptível na escala humana) para executar e não podem garantir as propriedades ACID. No primeiro caso, temos como exemplos os casos isolados de: ligar e desligar

(a)

(b)

8

uma luz, trancar e destrancar uma fechadura, ou mesmo uma operação isolada em um aparelho de controle remoto (e.g., uma TV), como ligar e desligar, mudar para um ca-nal, etc. No segundo caso, estarão comandos como por exemplo: expandir ou recolher uma cortina, abrir ou fechar um portão de garagem, ou mesmo modificar a temperatu-ra ambiente em um aparelho de ar condicionado (ainda que a modificação no aparelho possa ser instantânea neste caso, até que a temperatura ambiente atinja o alvo, terá transcorrido um tempo). Dentro deste framework, propomos um conjunto de quatro es-tados principais que podem ser utilizados para o gerenciamento das transações:

Em execução: quando um comando iniciou a sua execução;

Completo: quando um comando finalizou com sucesso;

Em compensação (reversão): quando um comando está em processo de re-versão após um pedido de cancelamento (rollback), que pode ser solicitado tanto durante a sua execução, como após já ter sido completo (no caso de vá-rios comandos orquestrados por dispositivos diferentes, o coordenador pode solicitar um rollback devido a falha em algum outro dispositivo). Repare ain-da que uma reversão pode ser disparada tanto pelo Coordenador, no caso de uma falha em um dos comandos envolvendo vários dispositivos (ou mesmo um pedido de “abortar” pelo usuário), quanto pelo próprio dispositivo, no caso de uma falhar interna na execução de alguma ação de atuação;

Falha: quando um comando finalizou com falha.

A Figura 4 ilustra o protocolo proposto com os estados acima e suas respectivas transições possíveis.

Figura 4 – Diagrama de estados abstratos para o protocolo de transação física.

O caso de transações atômicas é o mais trivial, no entanto pode não ser possível em tais cenários, mesmo nas situações mais simples, se pensarmos em operações de um pouco mais alto nível. Imagine por exemplo uma operação “fechar casa” definida por um usuário para ser executada quando ele sair de casa. Devido aos altos custos da energia, o usuário pretende que, durante esta operação, todas as luzes de todos os cô-modos sejam desligadas e que as trancas das janelas, bem como a fechadura principal das portas sejam trancadas. Na nossa conceituação proposta, este objetivo poderia ser alcançado apenas através de transações atômicas nos níveis dos dispositivos envolvi-

Em execução Completo

Falha

Em reversão

Gerado pelo Coordenador Gerado pelo Participante

9

dos, mas que, quando combinados, se tornam uma operação. O fato que a atuação refle-te necessariamente num efeito físico no ambiente torna a garantia das propriedades ACID difícil e pouco prática. Mesmo que trabalhássemos com um protocolo “preparar para commitar”, comum em bancos de dados, de modo que cada dispositivo ficasse em um estado “reservado” e não executasse efetivamente nenhuma ação até a recepção de um “commit”, nada impediria que um erro ou uma diferença nos tempos de execução entre os diferentes dispositivos ferisse facilmente o princípio do isolamento, por exem-plo, tornando o seu estado de sucesso parcial visível, mesmo em uma situação de falha do objetivo final. Assim sendo, acreditamos é mais prático trabalharmos com os princí-pios ACID relaxados, e propormos estratégias para lhe dar com esta realidade.

Neste contexto, podemos imaginar então alguns tipos de operações, que podem auxi-liar o coordenador a fazer o gerenciamento dos dispositivos participantes. Em uma si-tuação de falha, propomos três possíveis comportamentos:

Tentar novamente: onde o coordenador irá tentar executar novamente uma parte do plano de ação, até que obtenha um resultado. Nestas situações, as restrições de tempo não são tão críticas para o usuário, que está mais interes-sado que o resultado final seja alcançado. Pode-se colocar um limite de tenta-tivas (que pode infinito), até se desista definitivamente, mudando para uma das estratégias seguintes;

Deixe como está: onde o coordenador simplesmente irá deixar o ambiente co-mo está, não se importando com falhas parciais ao longo de uma operação. Isto pode ser útil no caso em que falhas e sucessos parciais não são críticas, como por exemplo em uma situação em que o usuário chega em casa, e nem todas as suas rotinas de automação são executadas: o ar condicionado, por exemplo, não ligou como desejado, mas o usuário aceita conviver com está situação e ligá-lo manualmente, pelo benefício de todas as outras coisas (possivelmente mais importantes para ele) que aconteceram com sucesso em seu ambiente (e.g., alarmes que desligaram, luzes que acenderam, etc.). É de-sejável que haja uma notificação do estado final e das sub-operações, a fim de possibilitar a intervenção e contorno das situações;

Reverter: esta seria a situação mais crítica, onde realmente não seria possível conviver com sucessos ou falhas parciais. Por exemplo, numa operação “es-friar sala” que, devido ao calor frequente na cidade, precisa que as janelas se-jam fechadas e que o ar condicionado seja ligado e ajustado para uma certa temperatura. No caso de uma falha em uma dessas etapas, toda a operação fica comprometida, pois a janela fechada sem o ar condicionado levará a uma situação de temperatura interna pior que a anterior, assim como o ar condicionado ligado com as janelas abertas levará a um desperdício indese-jado de energia. Assim sendo, um procedimento de reversão deve ser inicia-do no caso de falha em alguma etapa, para parar ações subsequentes retor-nar o dispositivo ao estado anterior que estava antes do início da operação.

O protocolo aqui proposto se assemelha aos protocolos definidos para BusinessActi-vity com Web Services. No entanto, assumimos como mais útil o protocolo BusinessA-greementWithCoordinatorCompletion pois consideramos que, nos contextos que estamos tratando, os dispositivos periféricos são menos inteligentes. Assim sendo, o coordena-dor é o responsável por notificar o final real de uma operação. Repare, no entanto, que tanto o coordenador como participante podem reportar uma falha ou solicitar um roll-back, que deverá então ser propagado para os outros participantes pelo coordenador, de acordo com a estratégia de exceção adotada.

10

Além disso, é importante destacar o papel do coordenador em orquestrar os partici-pantes. Neste sentido, ele deverá não somente disparar os comandos para cada disposi-tivo envolvido, mas também ter uma gestão da sequência dos comandos e da ocorrên-cia de conflitos. Para controle da sequência de execução, basicamente podemos assumir que há comados que podem ser executados em paralelo, como por exemplo na rotina “fechar casa”, onde não importa a ordem, mas sim que todas as fechaduras sejam tran-cadas e as luzes apagadas, e comandos que dependem de uma sequência, como no caso de “esfriar sala”, onde só será possível ajustar a temperatura do ar condicionado após este ter sido ligado. O diagrama de estados da Figura 4 facilitam a gestão de conflitos: um comando só pode ser iniciado se um dispositivo não está em nenhum dos estados intermediários apresentados, mas em um estado “esperando comandos”, que seria o estado padrão de todos os dispositivos após iniciar ou finalizar um ciclo. A figura cen-tralizada do coordenador facilita consideravelmente esta gestão, uma vez que uma operação concorrente sobre algum dispositivo pode ser detectada pelo coordenador, eu pode então enfileirar a operação, ou simplesmente rejeitá-la2.

5 Juntando tudo: um exemplo de aplicação

Iniciamos este trabalho discutindo a aplicação de conceitos de interação multimodal em ambientes de computação ubíqua, como por exemplo ambientes “smart” com di-versos dispositivos de IoT. As estratégias de gerenciamento de atuação apresentadas na seção anterior podem ser pensadas como estratégias de “fissão” dentro do loop das saídas num sistema de interação multimodal, onde cada modo é provido por um dis-positivo diferente, e pode ser acionado através de comandos disponibilizados pelos dispositivos. Esta abordagem, com as estratégias aqui apresentadas, pode ser imple-mentada em um middleware para prover interação multimodal através de dois níveis principais de abstrações: eventos, para lidar com as entradas dos usuários, que passari-am por um processo “fusão”, e transações físicas, para a entrega de comandos distribu-ídos aos dispositivos afetados, em um processo análogo à “fissão”. As duas pontas po-dem ser combinadas por meio de um mecanismo de CEP (Complex Event Processing) de modo a prover alto grau de customização, extensibilidade e flexibilidade, desacoplan-do totalmente as entradas e as saídas do sistema. Acreditamos que tais características são altamente desejáveis neste tipo de sistema, que tem natureza altamente distribuída, heterogênea e imprevisível, como vem se mostrando as aplicações atuais de IoT. Tal middleware pode funcionar como um sistema operacional de ambientes que interconec-ta dispositivos e usuários, provendo interação customizável e extensível: os eventos podem ser configurados de modo a detectar as ações de interesse do usuário, de acor-do com os sensores existentes no ambiente; as operações constituem os comandos pos-síveis dos atuadores “elementares” existentes no ambiente, mas podem estendidas pelo próprio usuário, que poderia criar rotinas de alto nível para objetivos que envolveriam interação em diversas etapas, com um ou mais de um dispositivo (Figura 5). As estra-tégias de gerenciamento de atuação propostas na seção anterior fornecem um protoco-lo de alto-nível que pode facilitar a criação de tal tecnologia, o que tornaria o ambiente mais “smart”, e bastante programável pelo usuário.

2 Nota: Há estratégias de tratamento de transações concorrentes que também podem ser trazidas do

mundo dos Web Services, como por exemplo em (Alrifai, et al., 2006). No entanto, um aprofunda-mento deste tema neste momento está fora da proposta deste trabalho.

11

Figura 5 – Exemplo de aplicação: um sistema operacional de ambientes.

6 Conclusão

Neste trabalho propomos uma abordagem para tratar de atuações em ambientes de computação ubíqua. Apresentamos uma abordagem baseada em uma analogia com transações em Web Services para possibilitar que uma sequência de comandos de atua-ção em ambientes físicos seja executada de forma gerenciada. A principal característica da nossa proposta é usar uma abstração de transação física para a efetivação controlada de comandos de atuação de forma distribuída. Acreditamos que tal estratégia pode ser implementada em ambientes “smart” de modo a facilitar a interação de usuários com tais ambientes. Por exemplo, a mesma pode ser implementada em um middleware para prover interação multimodal através de dois níveis principais de abstrações: eventos, para lidar com as entradas dos usuários, que passariam por um processo “fusão”, e transações físicas, para a entrega de comandos distribuídos aos dispositivos afetados, em um processo análogo à “fissão”. Nossa contribuição é propor a integração de con-ceitos de interação multimodal e arquiteturas orientadas a serviços (SOA e Web Servi-ces) para apoiar o desenvolvimento de ambientes e aplicações de Computação Ubíqua mais eficazes e melhorados, a partir da perspectiva da interação dos usuários. Clara-mente, o assunto foi explorado em seus aspectos iniciais, o que pode significar a aber-tura de perspectivas interessantes de pesquisas futuras. Dentre elas, destacamos a pró-pria implementação da aplicação proposta na seção 5, uma vez que tal proposta de sis-tema operacional necessita e integra conceitos de diversas áreas de pesquisa de uma forma bastante particular. Desde infraestrutura de redes e comunicação (como por exemplo, as tecnologias de middleware) até técnicas de interação (como por exemplo, interação multimodal), passando por arquiteturas de sistemas (como por exemplo, ar-quiteturas orientadas a serviços) e pelas tecnologias de computação ubíqua (como por exemplo, a IoT) parecem apresentar elementos que precisam ser melhor integrados de modo a prover as funcionalidades dos (ecos)sistemas tecnológicos do futuro, na dire-ção do que este trabalho é apenas uma proposta inicial.

Middleware

aOS

Eventos Operações

12

Referências

ALRIFAI, M., DOLOG, P. & NEJDL, W., 2006. Transactions concurrency control in web service environment. Web Services, 2006. ECOWS'06. 4th European Conference on, pp. 109-118.

BOLT, R. A., 1980. Put-That-There: Voice and Gesture at the Graphics Interface. Proceedings of the 7th Annual Conference on Computer Graphics and Interactive Techniques (New York, NY, USA, 1980), pp. 262-270.

CHOI, S. et al., 2005. Maintaining consistency under isolation relaxation of web services transactions. Web Information Systems Engineering–WISE 2005, pp. 245-257.

CURBERA, F. et al., 2003. The next step in Web services. Commun. ACM, Volume 46, 10 (October 2003), pp. 29-34.

DUMAS, B., LALANNE, D. & OVIATT, S., 2009. Multimodal interfaces: A survey of prin-ciples, models and frameworks. Human Machine Interaction, Issue Springer Berlin Hei-delberg, pp. 3-26.

NIGAY, L. & COUTAZ, J., 1993. A design space for multimodal systems: concurrent pro-cessing and data fusion. Proceedings of the INTERACT'93 and CHI'93 conference on Human factors in computing systems, pp. 172-178.

OASIS, 2007. Web Services Business Activity (WS-BusinessActivity) Version 1.1. [Online] Disponível em: http://docs.oasis-open.org/ws-tx/wstx-wsba-1.1-spec-os/wstx-wsba-1.1-spec-os.html [Acesso em 07 Dezembro 2015].

OASIS, 2009a. Web Services Coordination (WS-Coordination) Version 1.2. [Online] Dis-ponível em: http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec.html [Acesso em 07 Dezembro 2015].

OASIS, 2009. Web Services Atomic Transaction (WS-AtomicTransaction) Version 1.2. [Online] Disponível em: http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec.html [Acesso em 07 Dezembro 2015].

PAUL, D., HENSKENS, F. & HANNAFORD, M., 2007. Isolation and web services transactions. PDCAT, pp. 181-182.

PERRY, M., DOWDALL, A., LINES, L. & HONE, K., 2004. Multimodal and ubiquitous computing systems: Supporting independent-living older users. Information Technol-ogy in Biomedicine, IEEE Transactions on, Volume 8(3), pp. 258-270.

TURK, M., 2014. Multimodal interaction: A review. Pattern Recognition Letters, Vol-ume 36, pp. 189-195.

VAN DAM, A., 1997. Post-WIMP user interfaces. Communications of the ACM, Vol-ume 40.2, pp. p. 63-67.

WEISER, M., 1991. The computer for the 21st century. Scientific American, Volume 265(3), pp. 94-104.

WEISER, M., 1993. Some computer science issues in ubiquitous computing. Commun. ACM, July, Volume 36, 7, pp. 75-84.