SISTEMA PARA AUTOMAÇÃO E CONTROLE RESIDENCIAL VIA TWITTER

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE SISTEMAS DE INFORMAÇÃO BACHARELADO SISTEMA PARA AUTOMAÇÃO E CONTROLE RESIDENCIAL VIA TWITTER EDUARDO FELIPPI GADOTTI BLUMENAU /2-10

2 EDUARDO FELIPPI GADOTTI SISTEMA PARA AUTOMAÇÃO E CONTROLE RESIDENCIAL VIA TWITTER Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação Bacharelado. Prof. Miguel Alexandre Wisintainer, Mestre Orientador BLUMENAU /2-10

3 SISTEMA PARA AUTOMAÇÃO E CONTROLE RESIDENCIAL VIA TWITTER Por EDUARDO FELIPPI GADOTTI Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Miguel Alexandre Wisintainer, Mestre Orientador, FURB Prof. Antonio Carlos Tavares, Mestre FURB Prof. Paulo Fernando da Silva, Mestre FURB Blumenau, 09 de dezembro de 2010.

4 Dedico este trabalho a ao meu orientador, família e namorada, que me apoiaram, incentivaram e ajudaram na realização deste.

5 AGRADECIMENTOS Ao meu orientador Miguel Alexandre Wisintainer, por ter acreditado na idéia deste o início, pelo auxílio, incentivo, atenção e amizade. Aos meus pais, Auro Gadotti e Norma Gadotti, que sempre estiveram presente, fornecendo apoio e incentivo, não somente no desenvolvimento deste trabalho, mas em todo o decorrer da faculdade. À minha namorada, Taruana Gomes, que ajudou com conselhos, incentivo, apoio em momentos difíceis e vibrou junto nos momentos de conquista. Aos meus amigos, que me ouviram atentamente e incentivaram desde o início.

6 Se a liberdade significa alguma coisa, será, sobretudo, o direito de dizer às outras pessoas o que elas não querem ouvir. George Orwell

7 RESUMO A automação residencial é o futuro para as casas inteligentes, portanto este trabalho demonstra uma solução para automatizar um ambiente, ligando ou desligando dispositivos eletrônicos, sem a necessidade da utilização de um computador pessoal. O mesmo tem como objetivo usar o meio de comunicação, o Twitter, que é uma rede social em rápida ascendência no mundo globalizado e que pode ser acessada através de qualquer dispositivo com acesso à internet ou até mesmo através de mensagem de celular. Para o sistema embarcado foi utilizado o hardware FEZ. O resultado obtido através desta automação é o controle de ligar e desligar dispositivos tais como lâmpadas, televisores, eletrodomésticos, computadores, entre outros eletrônicos à distância. Palavras-chave: Domótica. Twitter. Microcontrolador. Automação.

8 ABSTRACT Housing automation is the future for smart houses, so this study points out a solution to automate an environment by switching on or switching off electronic devices, without the need of a personal computer. This study aims at using the mean of communication Twitter, a social net which is spreading fast around the world and can be accessed through any device connected to the internet or even through a mobile phone message. For the embedded system was used the FEZ hardware. The result achieved through this automation is the control of switching on and switching off devices such as lights, televisions, domestic appliances, computers among other electronics at distance. Key Words: Domotica, Twitter, Microcontroller, Automation

9 LISTA DE ILUSTRAÇÕES Figura 1 Cenário de envio de comando à residência Figura 2 - Diagrama do módulo Administrador Figura 3 Diagrama do módulo do usuário Figura 4 Diagrama de classes Figura 5 Diagrama de sequência Figura 6 Métodos WebService Figura 7 Tela inicial do sistema TwitterGeradorToken Figura 8 Preenchimento das credenciais para o sistema TwitterGeradorToken Figura 9 Obtendo Token s para o sistema TwitterGeradorToken Figura 10 Arquivo Parametros.xml Figura 11 Arquivo Usuarios.xml Figura 12 Arquivo Equipamentos.xml Figura 13 Arquivo Comandos.xml Figura 14 Site oficial do Twitter Figura 15 Aplicação TweetDeck para PC Figura 16 Aplicação TweetCaster para Android Figura 17 Enviando mensagem via SMS Figura 18 Placa inferior FEZ Domino Figura 19 Placa superior Ethernet Shield Figura 20 Placa controladora CLPIC Figura 21 Diagrama de relação saídas digitais e relés Figura 22 Estado do dispositivo, lâmpada desligada Figura 23 Estado do dispositivo, lâmpada ligada Quadro 1 - Requisitos funcionais Quadro 2 - Requisitos não funcionais Quadro 3 - Regras de negócios Quadro 4 Código fonte de acesso ao WebService Quadro 5 - Código de associação de comando com dispositivos Quadro 6 - Código de envio de sinais às saídas digitais Quadro 7 - Código fonte da interpretação e execução de comandos Quadro 8 - Código fonte da das leituras de mensagens via socket

10 Quadro 9 Descrição do caso de uso Edita Comandos Quadro 10 Descrição do caso de uso Edita Restrições Quadro 11 Descrição do caso de uso Edita Usuários Quadro 12 Descrição do caso de uso Edita Senha Quadro 13 Descrição do caso de uso Edita Intervalo de Leitura de Mensagens Quadro 14 Descrição do caso de uso Edita Cadeia de Comandos Quadro 15 Descrição do caso de uso Envia Comando pelo Twitter Quadro 16 Descrição do caso de uso Obtem Mensagem de Retorno Quadro 17 Descrição do caso de uso Envia Cadeia de Comandos pelo Twitter Quadro 18 Descrição do caso de uso Edita Equipamentos

11 LISTA DE SIGLAS API Application Programming Interface FEZ Freakin easy HTTP - Hypertext Transfer Protocol TCP - Transmission Control Protocol

12 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA AUTOMAÇÃO RESIDENCIAL O TWITTER FRAMEWORK.NET FEZ (GHI) CRIPTOGRAFIA HMAC-SHA TRABALHOS CORRELATOS DESENVOLVIMENTO LEVANTAMENTO DAS INFORMAÇÕES REQUISITOS DO SISTEMA ESPECIFICAÇÃO Diagramas de caso de uso Diagramas de classe IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Webservice gerenciador de mensagens Modo de autenticação oauth Como gerar Token e TokenSecret Operacionalidade da implementação Editar parâmetros Editar usuários Editar equipamentos Editar comandos Enviando uma mensagem Utilizando a página oficial Utilizando cliente TweetDeck em um PC Utilizando cliente TweetCaster em um smartphone Android Utilizando um celular comum para envio de SMS... 39

13 Placa FEZ Placa CLPIC Mudança de estados de um dispositivo elétrico RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A Detalhamento dos casos de uso... 51

14 13 1 INTRODUÇÃO A automação residencial é também conhecida como Casa inteligente, isto significa controlar uma residência remotamente, como por exemplo, ligar ou desligar luzes, dispositivos eletrônicos tais como ferro elétrico, televisão, panela elétrica, aparelho de som ou até mesmo um condicionador de ar. As soluções em automação residencial tornaram-se realidade e tem sido cada vez mais procuradas para serem utilizadas não só em residências, mas também em escritórios e ambientes corporativos. Trata-se de um sonho antigo e ambicioso, transformar um imóvel em um grande robô controlado por um controle remoto à distância. Infelizmente, este tipo de automação implica em uma série de regras e normas que muitas vezes torna a solução inviável de ser instalada. Além disso, os altos custos envolvidos e suas dificuldades de configuração e manuseio também são um fator agravante. Através do desenvolvimento da solução proposta para automação através do Twitter, é possível quebrar uma série de obstáculos apresentados pelos sistemas que utilizam um meio de comunicação proprietária. O Twitter é um serviço web onde é possível escrever mensagens públicas ou privadas de até 140 caracteres. É possível realizar a leitura destas mensagens através de programas que tenham acesso a internet, e então interpretar comandos pré-definidos pelo próprio usuário. O objetivo de automatizar se a residência é fazer com que ela seja controlada à distancia, pela internet e de forma confiável. Este sistema de automação possibilita que este controle seja feito através de qualquer dispositivo que tenha conexões com internet ou até mesmo celulares que permitam o envio de SMS 1, independente do tipo de equipamento ou sistema operacional. Na Figura 1 é demonstrado um cenário ao realizar um comando à residência 1 SMS. Short Message Service (Serviço de mensagem curta).

15 14 sd Visao Geral Residência Placa FEZ WebService Twitter Envia comando Usuário Figura 1 Cenário de envio de comando à residência. 1.1 OBJETIVOS DO TRABALHO O objetivo deste trabalho é apresentar uma solução para automação residencial utilizando como forma de comunicação o Twitter, dispensando a contratação de um serviço de protocolo de internet (IP 2 ) fixo para a residência e um computador. Os objetivos específicos do trabalho são: a) controlar automação residencial através do Twitter; b) utilizar um hardware chamado FEZ 3 a fim de dispensar a utilização de um computador; c) desenvolver uma solução utilizando sensores e atuadores; d) utilizar um WebService para comunicação e autenticação com o Twitter. 2 IP. Internet Protocol (Protocolo de internet). 3 FEZ. Freakin easy (hardware responsável pela lógica e processamento do sistema).

16 ESTRUTURA DO TRABALHO Este trabalho está disposto em quatro capítulos. No primeiro capítulo apresenta-se a introdução, os objetivos e a estrutura do trabalho. No segundo capítulo tem-se a fundamentação teórica, destacando-se os conceitos sobre a automação residencial, Twitter, Framework.Net, hardware FEZ e trabalhos correlatos. No terceiro capítulo é apresentado o desenvolvimento do sistema, incluindo detalhes sobre a especificação, implementação realizada e operacionalidade do mesmo. No quarto capítulo apresenta-se a conclusão e sugestões para trabalhos futuros.

17 16 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo aborda um breve referencial teórico que norteará o desenvolvimento do presente estudo, enfocando os aspectos sobre automação residencial, o Twitter, o Framework.NET, o hardware FEZ, além dos trabalhos correlatos. 2.1 AUTOMAÇÃO RESIDENCIAL Wortmeyer, Freitas e Líum (2005) e Automatic House (2010), afirmam que a automação residencial é algo recente e está em franco crescimento nos últimos anos. Esse processo começou como automação industrial, depois comercial e agora residencial. Seu crescimento deve-se ao avanço das tecnologias, custos reduzidos dos componentes e também pelo aumento da violência nas cidades, proporcionando assim maior segurança às casas através do maior controle, monitoramento e a possibilidade de simular que há pessoas na residência. Através da automação residencial é possível ligar ou desligar luzes, geladeira, microondas, televisão, computador, condicionador de ar, portão eletrônico, ferro elétrico, panela elétrica, entre outros dispositivos eletrônicos. Além da segurança, outros objetivos ao automatizar a residência são de proporcionar conforto, praticidade, produtividade, economia, eficiência e valorização do imóvel. O conceito de imóvel inteligente ou automação residencial também é definido muitas vezes pelo termo Domótica. 2.2 O TWITTER Plácido et al. (2009), definem o Twitter como uma rede social para troca de mensagens instantâneas caracterizada como micro blog. Surgiu em 2006 e seu grande sucesso deve-se a grande disponibilidade de mídia móvel (celular). As mensagens podem ser enviadas através de SMS e as mesmas não podem ultrapassar 140 caracteres, que é aproximadamente o

18 17 tamanho de um SMS. Além de trocar mensagens pessoais, o Twitter pode ser usado com o objetivo de divulgação de notícias, links, promoções, emprego, além do uso corporativo. Ao escolher seguir uma pessoa, você passará a acompanhar as coisas que ela publicar ao passo que ela será notificada por que você a está acompanhando e decidirá se quer seguir você também. Diferente, portanto, de sites como Orkut e Facebook, em que os usuários só têm uma lista de contatos, no Twitter você terá duas: uma com a relação das pessoas que te seguem (seguidores / followers) e outras com aqueles que você segue (following / seguidos). (SPYER, et all, 2009, p. 14). O Twitter é uma ferramenta em crescimento e expansão, sendo o mais novo meio de mídia móvel do mercado e também o mais popular. Seu grande sucesso deve-se à expansão dos sistemas móveis, smartphones e a sua possibilidade de adaptação a estas novas tecnologias. Recentemente, foi alterado o modo de autenticação dos usuários a fim de que a aplicação se torne mais segura e confiável, até mesmo superior à troca de mensagens por correio eletrônico. Sendo assim, não é permitido armazenar a senha do usuário para ser usado pelas aplicações clientes, é permitido somente armazenar uma chave criptografada que é gerada a partir da autenticação do usuário e identificador da aplicação que a utilizará. Esta chave é única para cada usuário e leva em consideração a chave da aplicação que também é única e privada. 2.3 FRAMEWORK.NET De acordo com Microsoft (2010 b), o framework.net trata-se de um componente desenvolvido pela Microsoft que tem como objetivo fornecer um ambiente de programação orientada a objetos que possa ser executado remotamente, minimizar conflitos de implantação e versionamento, melhorar a experiência do desenvolvedor e integração com outros códigos. O framework.net pode ser hospedado por componentes não gerenciados que carreguem o Common language Runtime 4, criando-se assim um ambiente de software que pode ser explorado. O framework também disponibiliza uma biblioteca de classes orientada a objetos de tipo reutilizáveis, reduzindo assim, o tempo associado à programação e aumentando a 4 Common language Runtime. Fundação do Framework. Gerência memória, comunicação remota e segurança.

19 18 facilidade de utilização. Além disso, possibilita a integração de classes de terceiro desenvolvidos no mesmo framework. Existe uma versão deste framework utilizado em sistemas embarcados, chamada Micro Framework, cujas funções são mais limitadas. Esta plataforma de desenvolvimento é adequada a hardware com capacidade reduzida, e é inclusive utilizada por sistemas de robótica que optam pelo framework.net. 2.4 FEZ (GHI) De acordo com Tinyclr (2010), FEZ é uma placa específica baseadas em chipset USBizi, que de acordo com GHI ELETRONICS (2010), suporta programas escritos sob a plataforma Micro Framework.NET. É um hardware de baixo custo direcionado a iniciantes, porém nada impede de ser utilizada de forma profissional. Ideal para sistemas embarcados, suas placas são de proporções bastante reduzidas e possibilitam a ligação com diversos componentes desenvolvidos pela própria empresa. A placa FEZ é desenvolvida pela empresa Tinyclr e utiliza o chip da GHI Eletronics, ambas as empresas situadas nos Estudos Unidos. Portanto, as atualizações e pacotes de desenvolvimentos ficam a cargo da GHI Eletronics. O hardware é composto por quatorze saídas digitais, seis saídas analógicas, alimentação 5V e 3.3V, entrada MicroSD, USB Host, USB Client, USBizi Chip, alimentação externa 6 a 12V e botões de reset e loader. Possui 521KB de memória flash e 98KB de memória RAM, porém as aplicações dispõem apenas 100KB flash e 50KB RAM para uso. A placa FEZ por ser integrada a outras placas ou componentes desenvolvidos pela própria empresa, ou até mesmo por terceiros caso compatível. Estas placas são encaixadas na parte superior, através dos pinos das saídas digitais e analógicas, sem a necessidade da soldagem de componentes.

20 CRIPTOGRAFIA HMAC-SHA1 Esta criptografia é utilizada para realizar a geração dos Token s do usuário, sendo uma combinação do nome do usuário, senha, hora atual, entre outras variáveis. Pode ser criptografadas chaves de qualquer tamanho, porém o resultado sempre será um hash de 160 bits. HMACSHA1 é um tipo de algoritmo de hash com chave que é construído a partir da função hash SHA1 e usado como um HMAC, ou com base de autenticação de mensagem código hash. O processo HMAC mistura uma chave secreta com os dados da mensagem, hashes o resultado com a função hash, mistura que o valor de hash com a chave secreta de novo, então aplica a função hash uma segunda vez. O hash de saída é de 160 bits de comprimento. (MICROSOFT, 2010). Qualquer alteração de dados ou o valor de hash irá resultar em uma incompatibilidade, pois é necessário o conhecimento da chave secreta para alterar a mensagem e reproduzir o valor de hash correto. Portanto, quando os valores de hash originais e computados coincidirem, a mensagem é autenticada. 2.6 TRABALHOS CORRELATOS Reiter Jr. (2006), desenvolveu uma aplicação no ambiente de desenvolvimento Delphi para controlar dispositivos eletrônicos (estado liga/desliga). Este estudo tem como objetivo realizar comunicação utilizando uma controladora com a porta Serial através do Windows ou Linux. Não é necessária a utilização de um PC para seu funcionamento, porém esta controladora não possui acesso a informações externas, como por exemplo, Internet. Censi (2001) desenvolveu uma aplicação de automação residencial utilizando o correio eletrônico como forma de monitoramento de comandos. O objetivo é realizar a leitura da caixa de correio eletrônico de um determinado endereço procurando reconhecer comandos previamente definidos para executar alguma ação. Independente da utilização de um PC para funcionamento, esta aplicação foi desenvolvida sob o hardware Rabbit 2000 TCP/IP, que de acordo com Rabbit (2010), suporta a linguagem de programação C ou Assembly.

21 20 3 DESENVOLVIMENTO Neste capítulo estão descritas as particularidades técnicas do sistema tais como a sua descrição e a apresentação de seus requisitos funcionais e não funcionais, regras de negócio e os principais diagramas de caso de uso e a sua descrição, de atividades, de classes, de relacionamento e principais softwares utilizados. 3.1 LEVANTAMENTO DAS INFORMAÇÕES Ao automatizar-se uma residência é necessária a configuração do sistema como, por exemplo, a decisão de quais equipamentos serão controlados, quais as restrições de acesso, quais são os usuários que utilizarão e demais detalhes técnicos. 3.2 REQUISITOS DO SISTEMA O Quadro 1 apresenta os requisitos funcionais previstos para o sistema e sua rastreabilidade, ou seja, vinculação com os casos de uso associados. Requisitos Funcionais Caso de Uso RF01. O sistema deverá permitir ao Administrador inserir, editar e excluir UC01.01 comandos através da edição de arquivo XML. RF02. O sistema deverá permitir ao Administrador relacionar comandos à UC01.01 ações de automação através da edição de arquivo XML. RF03. O sistema deverá permitir ao Administrador restringir os comandos à UC01.04 Usuários do Twitter através da edição de arquivo XML. RF04. O sistema deverá permitir ao Administrador configurar o tempo de UC01.03 intervalo entre cada leitura de novas mensagens através da edição de arquivo XML. RF05. O sistema deverá permitir ao Administrador editar a senha do usuário UC01.02

22 21 "monitor" do Twitter através da edição de arquivo XML. RF06. O sistema deverá permitir ao Administrador configurar os comandos que receberá retorno de execução através da edição de arquivo XML. RF07. O sistema deverá permitir ao Administrador inserir, editar e excluir uma cadeia de comandos. Execução de vários comandos a partir de um só através da edição de arquivo XML. RF08. O sistema deverá realizar a leitura de mensagens do Twitter para identificar comandos a executar RF09. O sistema deverá permitir ao Administrador inserir, editar, e excluir usuários através da edição de arquivo XML. RF10. O sistema deverá enviar mensagem através do Twitter de retorno quando for necessário. RF11. O sistema deverá permitir ao Usuário o envio de comandos em cadeia. RF12. O sistema deverá permitir ao Administrador inserir, editar e excluir equipamentos através da edição de arquivo XML. UC01.01 UC01.05 UC02.01 UC01.06 UC02.02 UC02.03 UC01.07 Quadro 1 - Requisitos funcionais O Quadro 2 lista os requisitos não funcionais previstos para o sistema. Requisitos Não Funcionais RNF01. O sistema deverá ter acesso à Internet. RNF02. O sistema deverá ser desenvolvido sob a plataforma Micro Framework.Net v4.0 RNF03. O sistema deverá fazer a leitura das mensagens do Twitter através de um WebService. RNF04. O sistema deverá utilizar a API do Twitter para realizar requisições e envio de mensagens. RNF05. O sistema deverá gravar um arquivo log do tipo ".txt" a cada execução de um comando ou havendo erros. RNF06. O sistema deverá gravar as configurações de comandos e parametros em arquivos do tipo ".xml" RNF07. O sistema deverá ser executado em um hardware da empresa GHIEletronics denominado FEZ Domino. RNF08. O sistema deverá realizar a comunicação externa através de protocolos TCP/IP (Ethernet)

23 22 RNF09. O sistema deverá gravar em um arquivo do tipo ".txt" o identificador da ultima mensagem lida. Quadro 2 - Requisitos não funcionais O Quadro 3 lista as regras de negócio previstas para o sistema. Regras de Negócio RN01. O sistema não deverá permitir mais de 150 requisições de leitura ou envio por hora. RN02. O sistema não deverá permitir a execução de comandos que estejam restritos e que o usuário não tenha permissão. RN03. O sistema não deverá permitir a execução de comandos inativos. RN04. O sistema não deverá enviar mensagens de retorno que ultrapassem 140 caracteres. RN05. O sistema deverá interpretar comandos somente do tipo de mensagem configurada pelo usuário. RN06. O sistema deverá possibilitar a leitura de comandos a partir de mensagens diretas (privadas). RN07. O sistema não deverá permitir ler mensagens já lidas anteriormente. RN08. O sistema deverá verificar mensagens para comandos somente do usuário configurado no sistema. RN09. Os log do sistema não poderão ultrapassar 1 (um) megabyte. Quadro 3 - Regras de negócios 3.3 ESPECIFICAÇÃO Esta seção apresenta os diagramas que serão necessários para o entendimento do sistema de automação e comunicação com o Twitter. Para a especificação do sistema utilizouse a notação UML 5, sendo os diagramas gerados através da ferramenta Enterprise Architect. 5 UML. Unified Modeling Language (Linguagem de modelagem unificada).

24 Diagramas de caso de uso Esta sub-seção apresenta na Figura 2 e na Figura 3 os diagramas de casos de uso da solução desenvolvida. Para melhor entendimento do sistema, os detalhamentos dos casos de uso encontram-se no Apêndice A. uc PCT01 - Módulo Administrador UC Edita comandos «extend» UC Edita restrições UC Edita usuários UC Edita Senha Administrador UC Edita interv alo de leitura de mensagens UC Edita cadeia de comandos UC Edita Equipamentos Figura 2 - Diagrama do módulo Administrador.

25 24 Na Figura 3 são ilustradas as funcionalidades que o usuário comum utiliza para automatizar a residência. uc PCT02 - Usuário UC Env ia comando pelo Tw itter UC Obtem mensagem de retorno Usuário UC Env ia cadeia de comando pelo Twitter Figura 3 Diagrama do módulo do usuário Diagramas de classe Na Figura 4 apresenta-se o diagrama de classes. A solução desenvolvida não utiliza um Sistema de Gerenciador de Banco de Dados (SGBD), portanto estas classes não representam entidades no banco de dados, mas sim, estruturas de arquivos XML 6 as quais são utilizadas para manter as informações necessárias ao sistema. Os nomes e atributos foram nomeados visando facilitar a leitura e o entendimento do desenvolvedor. 6 XML. Extensible Markup Language.

26 25 class Diagrama de Classes Parametros - Usuario: char {readonly} - Token: char - TokenSecret: char - Intervalo: int - DataUltimaMensagemLida: char - EnderecoIp: char - MascaraIp: char - GatewayIp: char - EnderecoMacGateway: char Mensagem - Texto: char - Data: char - EnviadorPor: char - EnviadorPorId: int - Seguindo: boolean 1 0..* Comandos «enumeration» TipoComando Simples Encadeado «enumeration» EstadoEquipamento Liga Desliga Usuarios - Id: int - Nome: char - char - UsuarioTwitter: char 0..* 0..* - Id: int - Descricao: char - Comando: char - EquipamentosId: int - TipoComando: TipoComando - EnviaRetorno: boolean - RestricaoUsuarios: char - DataCadastro: char - Ativo: boolean - ListaComandos: char - EstadoEquipamento: boolean 0..* 1 Equipamentos - Id: int - Descricao: char Figura 4 Diagrama de classes. A função de cada classe de entidade está descrita a seguir: a) classe Parametros - classe que possui os atributos referentes aos parâmetros utilizados por todo o sistema; b) classe Mensagem - classe que possui os atributos referentes às mensagens lidas do Twitter; c) classe Usuários - classe que possui os atributos referentes aos dados dos usuários cadastrados no sistema de automação; d) classe Comandos - classe que possui os atributos referentes aos comandos cadastrados no sistema de automação; e) classe Equipamentos - classe que possui os atributos referentes aos equipamentos da residência; f) classe TipoComando - tipo definido (enumeração, constantes do tipo int nomeadas), com valores pré-estabelecidos para o reconhecer o tipo de comando a ser executado;

27 26 g) classe EstadoEquipamentos - tipo definido (enumeração, constantes do tipo int nomeadas), com valores pré-estabelecidos para o reconhecer o estado do equipamento. 3.4 IMPLEMENTAÇÃO A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da implementação Técnicas e ferramentas utilizadas Para a implementação do sistema foi utilizado a ferramenta Microsoft Visual Studio 2008 que permite trabalhar com diversas linguagens da plataforma.net, entre elas o C# que é a linguagem na qual o sistema foi desenvolvimento. Sendo um sistema embarcado é necessária a compilação do sistema em um framework mais compacto, chamado Micro Framework, neste caso utilizado a versão 4.0. O sistema realiza a comunicação externa através da Ethernet com protocolos TCP/IP, sendo assim, é possível comunicar-se com um WebService para gerenciar as mensagens recebidas e enviadas. A Figura 5 ilustra como é realizada a comunicação entre o sistema embarcado e o Twitter ao obter uma leitura de mensagem para então executar o comando de automação e realizar o retorno ao usuário.

28 27 sd Business Process Model Usuário Sistema embarcado (FEZ) Webservice gerenciador Api Twitter Placa controladora (CLPIC) Envia Mensagem() Busca mensagens não lidas() Busca mensgens não lidas() Retona mensagens() Retorna mensagens() Executa comando() Envia mensagem de retorno() Envia mensagem() Recebe mensagem() Figura 5 Diagrama de sequência Webservice gerenciador de mensagens Foi necessário o desenvolvimento específico de um WebService, denominado TwitterGerenciador, para auxiliar na comunicação entre o sistema embarcado e a API do Twitter. O WebService tem como objetivo realizar a autenticação do usuário e retornar as mensagens obtidas de modo otimizados, ou seja, filtra somente informações necessárias para o sistema embarcado. Como resultado, a comunicação fica íntegra, segura, ágil e de fácil manutenção. Um Web Service é uma classe escrita em uma linguagem suportada pela plataforma.net que pode ser acessada via protocolo http. Isso significa dizer que você pode acessar qualquer Web Service disponível na Web e utilizar todas as funcionalidades do mesmo. O acesso sempre será via http, mas internamente existe uma string XML que está empacotada em um protocolo SOAP (Simple Object Access Protocol). O SOAP é um padrão aberto criado pela Microsoft, Ariba e IBM para padronizar a transferência de dados em diversas aplicações, por isso, se dá em XML. (MICROSOFT, 2010 a).

29 28 Este WebService foi desenvolvido exclusivamente para realizar a comunicação entre o sistema embarcado e o Twitter. Faz-se necessário a utilização deste intermediário devido a uma alteração no modo de autenticação (oauth) do usuário, utilizando criptografias (HMAC- SHA1) com chaves públicas e privadas (Token e TokenSecret), criptografia a qual não é suportada pelo hardware FEZ. Esta aplicação é a responsável pela comunicação direta com o Twitter, enviando e recebendo as mensagens do sistema embarcado, servindo assim como um intermediador. A requisição a este sistema através do hardware FEZ é demonstrada no trecho de código fonte a seguir no Quadro 4. var url = " twittergerenciador/gerenciador.asmx/buscamensagensdiretas?psinceid=" + pultimamsgid + "&pcount=1&ptoken=" + ptoken + "&ptokensecret=" + ptokenscret; var serverip = new byte[] { 174, 123, 78, 178 }; //servidor onde está o WS //Realiza conexão com o socket serversocket.connect(serverip, 80); System.Threading.Thread.Sleep(5000); //5 segundos //Constroi o Header da mensagem var request = BuscaHeader(url, referer, extraheaders, requestmethod, postcontenttype, postbody); Quadro 4 Código fonte de acesso ao WebService Na Figura 6 encontram-se as funções publicadas neste WebService. Figura 6 Métodos WebService.

30 Modo de autenticação oauth De acordo com o Twitter (2010 b), oauth é um protocolo de autenticação que permite usuários aprovar uma aplicação cliente para interagir com seu usuário, obtendo e enviando mensagens sem compartilhar a senha e assim proporcionando mais segurança a cada troca de mensagem. Este processo é transparente ao usuário da aplicação, sendo responsabilidade da mesma realizar este tipo de tratamento. Este protocolo foi escolhido pela corporação do Twitter como oficial para todas as aplicações que realizam a comunicação com sua API. No dia 16 de agosto de 2010 foram desativadas as autenticações básicas, impedindo que a senha do usuário trafegue pela rede. Também existe a opção de autenticação xauth, que realiza a comunicação passando diretamente a senha do usuário, porém o uso deste protocolo é mais restrito, e para ser usado deve ser feita uma solicitação para a equipe da empresa, na qual explica-se as razões da utilização deste protocolo e aguarda-se uma aprovação exclusiva à aplicação desejada Como gerar Token e TokenSecret Para gerar as informações de Token e TokenSecret foi necessário o desenvolvimento de outro programa denominado TwitterGeradorToken, sendo necessário executar o programa em um computador com acesso à Internet. Este programa irá direcionar o usuário a uma página do Twitter que informará qual o nome da aplicação a fim de liberar o acesso. Após liberado, o programa irá gerar os Token baseados nos Token privados da aplicação, os quais somente poderão ser usados com a aplicação liberada. A geração destes Token é feita apenas uma única vez, desde que o usuário não mude seu identificador ou senha. Não há data para expiração destas informações. Na Figura 7 é ilustrada a tela inicial deste sistema.

31 30 Figura 7 Tela inicial do sistema TwitterGeradorToken. Na Figura 8, o usuário é direcionado diretamente à pagina do Twitter com o identificador do sistema a ser liberado e com os campos para preenchimento das credenciais do usuário. Figura 8 Preenchimento das credenciais para o sistema TwitterGeradorToken.

32 31 Após preenchimento das credenciais corretas do usuário e clicado no botão Allow, ou seja, permitir acesso, então é mostrado um código chamado PIN. Este código deve ser informado no campo livre abaixo e clicando no botão Update para gerar as informações de Token s que devem ser informadas no arquivo de parâmetros do sistema de automação. Na Figura 9, é demonstrado o envio do código PIN e o recebimento das informações de Token s. Figura 9 Obtendo Token s para o sistema TwitterGeradorToken Operacionalidade da implementação Nesta sub-seção é apresentada a sequência de telas e operações para cada tipo de usuário para conseguir utilizar corretamente o sistema de automação. Todos os arquivos de configuração seguem o padrão XML e são armazenados no cartão de memória MicroSD na placa FEZ, sendo possível alterações de seus registros sem a necessidade da compilação do código fonte do sistema Editar parâmetros No arquivo de parâmetros do sistema, o administrador deve definir variáveis necessárias para que o sistema funcione corretamente. Na Figura 10, é ilustrado o formato do arquivo de parâmentros.

33 32 Figura 10 Arquivo Parametros.xml. Este arquivo é a principal base de configuração do sistema, pois compõe as informações do usuário monitor, senha (que é formado pelos campos Token e TokenSecret, ambos criptografados para maior segurança), intervalo de leitura de mensagem (que não deve ser inferior a 30 segundos) e os respectivos IP s da rede em que o sistema está atuando Editar usuários Na Figura 11, é demonstrado o arquivo de usuário, onde o administrador pode manter os usuários que utilizam o sistema de automação. Este arquivo tem como objetivo manter os usuários documentados para posterior rastreamento caso seja necessário. Figura 11 Arquivo Usuarios.xml.

34 Editar equipamentos No arquivo de equipamentos, o administrador deverá manter os equipamentos que estão sendo automatizados na residência. Cada um deve possuir um código de identificação única para ser relacionado junto ao comando e uma descrição para ser usada nas mensagens de retorno e log s para fácil entendimento do usuário. O campo de identificador do comando é responsável pela associação com os dispositivos eletrônicos, sendo sua numeração a correspondente com a sequência na placa CLPIC. Na Figura 12, é exemplificado um cadastro de equipamentos. Figura 12 Arquivo Equipamentos.xml No quadro 5, encontra-se o código fonte que realiza esta associação e em seguida como é realizado o envio do comando para a placa CLPIC. Public bool Executa(Comando pcomando, Saidas psaidas) { try { switch (pcomando.equipamentosid) { case 1: { psaidas.tomada1.write(pcomando.estadoequipamento); break;

35 34 } case 2: { psaidas.tomada2.write(pcomando.estadoequipamento); break; } case 3: { psaidas.tomada3.write(pcomando.estadoequipamento); break; } case 4: { psaidas.tomada4.write(pcomando.estadoequipamento); break; } case 5: { psaidas.tomada5.write(pcomando.estadoequipamento); break; } } return true; } catch (Exception ex) { //Grava log Funcoes.EscreverLog(PathSd, Erro de exceção ocorrido ao executar comando + pcomando.nome + : + ex, 1, false); return false; } } Quadro 5 Código de associação de comando com dispositivos. No Quadro 6, é apresentado a classe de controle de saídas. public class Saidas { public OutputPort Tomada1 { get; set; } public OutputPort Tomada2 { get; set; } public OutputPort Tomada3 { get; set; } public OutputPort Tomada4 { get; set; } public OutputPort Tomada5 { get; set; } } public Saidas() { //Inicia as saídas e indica o estado inicial Tomada1 = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di3, false); Tomada2 = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di7, false); Tomada3 = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di5, false); Tomada4 = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di8, false); Tomada5 = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di9, false); } Quadro 6 - Código de envio de sinais às saídas digitais.

36 Editar comandos No arquivo de comandos, o administrador deve manter os comandos aceitos pela automação. Cada um deve ter um identificador único para fácil identificação e controle pelo sistema. São configuráveis neste arquivo variáveis como descrição, nome (comando que será identificado na mensagem recebida pelo Twitter), identificador do equipamento, tipo do comando (simples ou encadeado), envio de mensagem de retorno após a execução, restrição a usuários, lista de comandos (no caso de um comando encadeado) e estado do equipamento (liga ou desliga). Na Figura 13, é exemplificado um cadastro de comandos. Figura 13 Arquivo Comandos.xml.

37 36 No quadro 7, é demonstrado o código fonte responsável pela interpretação e execução destes comandos. //Verifica se encontra o nome do comando detro da mensagem if (itemmensagem.texto.indexof(itemcomando.nome) >= 0) { //Verifica se há restrição para usuários if (itemcomando.restricaousuarios!= string.empty &&!(itemcomando.restricaousuarios.indexof(itemmensagem.enviadopor) >= 0)) continue; //Executa o comando var retorno = itemcomando.tipocomando == TipoComandoEnum.Simples? Executa(itemcomando, psaidas) : ExecutaEncadeado(itemcomando, psaidas); //Verifica retorno da execução if (retorno) { //Salva id da mensagem executada Parametros.GravaUltimaMsgId(PathSd, itemmensagem.id); //Verifica necessidade de envio de retorno if (itemcomando.enviaretorno) Mensagem.EnviaMensagem(pToken, ptokensecret, itemmensagem.enviadopor, "Comando_" + itemcomando.descricao + "_executado_com_sucesso"); } else { //Verifica necessidade de envio de retorno if (itemcomando.enviaretorno) Mensagem.EnviaMensagem(pToken, ptokensecret, itemmensagem.enviadopor, "Comando_" + itemcomando.descricao + "_nao_executado_erro_de_execucao"); } } //Proxima mensagem break; Quadro 7 - Código fonte da interpretação e execução de comandos Enviando uma mensagem A seguir alguns exemplos de possibilidades de enviar uma mensagem ao Twitter independente do sistema operacional ou plataforma utilizada, podendo até mesmo utilizar SMS dispensando assim a conexão com a internet e enviando a mensagem através de um simples celular.

38 Utilizando a página oficial Na Figura 14, utiliza-se a página oficial do Twitter ( e seleciona-se a opção Message, usada para o envio de mensagens privadas. Figura 14 Site oficial do Twitter. Este site é compatível com os sistemas operacionais Windows, Mac OS e Linux e suportado pelos principais navegadores como Internet Explorer, FireFox, Chrome e Opera Utilizando cliente TweetDeck em um PC Na Figura 15, utiliza-se uma aplicação cliente que realiza a comunicação com o Twitter. Existem versões para esta aplicação para os sistemas Mac, PC, Linux, iphone, ipod Touch, ipad e Android.

39 38 Figura 15 Aplicação TweetDeck para PC Utilizando cliente TweetCaster em um smartphone Android Na Figura 16, utiliza-se o cliente chamado TweetCaster para celulares com sistema operacional Android. Não há custos para adquirir ou utilizar este aplicativo.

40 39 Figura 16 Aplicação TweetCaster para Android Utilizando um celular comum para envio de SMS de SMS. Na Figura 17, utiliza-se um celular sem acesso à internet, enviando mensagem através Figura 17 Enviando mensagem via SMS.

41 Placa FEZ Este hardware é responsável pela comunicação com o WebService, que por sua vez se comunica com o Twitter. Também, ele interpreta os comandos e envia os sinais necessários para a placa controladora CLPIC através de saídas digitais lógicas. Além da comunicação, contém um cartão MicroSD que armazena todos os parâmetros necessários para o sistema. Na figura 17 e 18 demonstra-se o hardware que é composto por 2 placas, a inferior chamada de FEZ Domino contém o chip da GHI Eletronics, com suporte ao framework.net e na parte superior a placa chamada de Ethernet Shield responsável pela comunicação via Ethernet. Entradas e saídas digitais Mini USB USB Host MicroSD Alimentação externa 6 a 12V Entradas e saídas analógicas Figura 18 Placa inferior FEZ Domino.

42 41 Ligação Terra com a CLPIC Saída Ethernet Saídas digitais ligadas à CLPIC Na Figura 19, é demonstrado o hardware Ehternet Shield. Figura 19 Placa superior Ethernet Shield. No quadro 8, é demonstrado no trecho de código fonte, como é realizada a conexão via socket utilizando as placas FEZ e Ethernet Shield obtendo assim as mensagens do WebService gerenciador. public static byte[] WebRequest(string url, string referer, string extraheaders, string requestmethod, string postcontenttype, string postbody) { byte[] mensagemretorno = null; //Trata Url url = url.substring(7); System.Threading.Thread.Sleep(5000); //5 segundos var serversocket = new FEZ_Shields.Ethernet.uSocket(FEZ_Shields.Ethernet.uSocket.Protocol.TCP, 80); var serverip = new byte[] { 174, 123, 78, 178 }; //servidor onde está o WebService try { //Realiza conexão com o socket serversocket.connect(serverip, 80);

43 42 System.Threading.Thread.Sleep(5000); //5 segundos //Constroi o Header da mensagem var request = BuscaHeader(url, referer, extraheaders, requestmethod, postcontenttype, postbody); //Converte o Header para Array de Bytes var bytestosend = System.Text.Encoding.UTF8.GetBytes(request); //Realiza o envio da requisição e verifica se está Ok. if (serversocket.send(bytestosend, bytestosend.length) > 0) { System.Threading.Thread.Sleep(5000); //5 segundos //Aguarda os dados var timeoutinicial = DateTime.Now.AddSeconds(30); while (serversocket.avilablebytes <= 0 && DateTime.Now < timeoutinicial) { System.Threading.Thread.Sleep(500); //0,5 segundo } mensgem //Declara Buffer que será usado para as receber as partes da var buffer = new Byte[serverSocket.AvilableBytes]; //Realiza leitura do socket até encontrar o final da mensagem // ou até o timeout limite de 60 segundos var timeoutprincipal = DateTime.Now.AddSeconds(60); var finalmensagem = false; //Realiza Loop até ler a mensagem completa do { //Verifica se foi alterado seu tamanho if (buffer.length!= serversocket.avilablebytes) buffer = new Byte[serverSocket.AvilableBytes]; //Limpa Buffer antigo Array.Clear(buffer, 0, buffer.length); //Recebe nova parte da mensagem var bytesread = serversocket.receive(buffer, serversocket.avilablebytes); //Verifica se foi lido algum byte if (bytesread > 0) { //Verifica se é a primeira leitura if (mensagemretorno == null) { //Retira o header da mensagem buffer = RetiraHeader(buffer); bytesread = buffer.length; mensagemretorno = new byte[buffer.length]; } else { //Aumenta o tamanho do array da mensagem var temp = new byte[mensagemretorno.length]; Array.Copy(mensagemRetorno, temp,

44 43 mensagemretorno.length); mensagemretorno = new byte[temp.length + bytesread]; Array.Copy(temp, mensagemretorno, temp.length); } //Limpa array não mais utilizado Array.Clear(temp, 0, temp.length); //Copia a parte da mensagem lida para o Array totalizador Array.Copy(buffer, 0, mensagemretorno, mensagemretorno.length - bytesread, bytesread); de envio > 0) } //Verifica se obteve final da mensagem ou se é método if (Funcoes.BytesToString(buffer).IndexOf("</string>") finalmensagem = true; false); //} while (bytesread > 0 serversocket.avilablebytes!= 0); } while (DateTime.Now < timeoutprincipal && finalmensagem == } } finally { try { //Desconecta o socket serversocket.disconnect(); } catch (Exception){} } try { //Fecha a conexão independete de qualquer evento da rotina. serversocket.close(); } catch (Exception){} } return mensagemretorno; Quadro 8 - Código fonte da das leituras de mensagens via socket Placa CLPIC-628 Esta placa é montada de acordo com a necessidade da residência, como neste trabalho foi optado automatizar cinco dispositivos, então optou-se por uma placa que continha cinco Relés. Esta placa recebe os comandos diretamente da placa FEZ que os executam. Na Figura 20, é demonstrado a placa CLPIC-628.

45 44 Relés que controlam cada tomada Entradas digitais vindas diretamente da placa FEZ Alimentação externa 12V Figura 20 Placa controladora CLPIC-628. placa CLPIC. Na figura 21, é ilustrada a relação entre as saídas digitais da placa FEZ com os relés da composite structure Driagrama de Blocos Placa FEZ Placa Ethernet Shield Saída Digital 3 Relé 1 Placa CLPIC Saída Digital 7 Relé 2 Saída Digital 5 Relé 3 Saída Digital 8 Relé 4 Saída Digital 9 Relé 5 Figura 21 Diagrama de relação saídas digitais e relés.

46 Mudança de estados de um dispositivo elétrico Demonstra-se aqui o resultado do envio de um comando para ligar e desligar uma lâmpada. Na figura 22 é ilustrada uma lâmpada apagada. Figura 22 Estado do dispositivo, lâmpada desligada. Após enviado um comando para o sistema de automação para que fosse ligada esta mesma lâmpada, observa-se o resultado na Figura 23. Figura 23 Estado do dispositivo, lâmpada ligada.

47 RESULTADOS E DISCUSSÃO O desenvolvimento deste sistema permitiu a automatização de dispositivos elétricos utilizando uma ferramenta de rede social moderna e com segurança. Este sistema dispensa a necessidade da contratação de serviços de IP fixa para a residência automatizada, visto que as mensagens serão sempre enviadas ao Twitter e não especificamente à residência. Não foi necessário o desenvolvimento de programas clientes, ou seja, programas desenvolvidos especificamente para realizar a comunicação com o sistema embarcado. É possível utilizar qualquer programa cliente que se comunique com o Twitter ou ainda através de SMS. Sendo assim foi possível, por exemplo, ligar ou desligar uma lâmpada através de qualquer tipo de celular, com ou sem comunicação com internet, e também utilizando computadores com sistemas operacionais Windows, Linux ou Mac. Foi possível também realizar uma automação mais segura em relação às automações que utilizam s, como a aplicação de Censi (2001), as quais são passíveis de falhas de envio e recebimento, assim como problemas de spam. Enquanto s são acessados de forma direta através de qualquer aplicativo que tenha usuário e a senha do mesmo, nesta automação a senha do usuário não é armazenada, logo a mesma não é trafegada pela rede, aumentando assim a sua segurança. O Token utilizado para autenticação do usuário somente será aceito se realizado através do sistema de automação que foi previamente cadastrado no banco de dados da corporação do Twitter. Portanto, alcançou-se o objetivo de desenvolver um sistema de automação utilizando a rede social Twitter, garantindo a segurança, privacidade das mensagens e possibilitando o envio de comandos através de multi-plataformas.

48 47 4 CONCLUSÕES Neste trabalho provou-se que as redes sociais podem ser usadas de forma séria e confiável, podendo ser utilizadas para realizar automações residenciais, dessa forma, aproximando os usuários de sua realidade como navegadores da internet. O sistema desenvolvido atendeu seus objetivos principais e específicos, realizando assim uma automação que utiliza o Twitter como meio de comunicação e o hardware que suporta a plataforma.net orientada a objetos. Este tipo de automação via Twitter mostrou-se também mais segura que uma comunicação por , onde usuário e senha trafegam diretamente pela rede e não há garantias de entrega da mensagem, ao contrário do Twitter. Foi possível também reduzir os custos para o usuário final, caso o sistema venha a ser comercializado, visto que não é necessário o desenvolvimento e a venda de um programa para comunicação com o sistema de automação. Hoje, há programas clientes que realizam comunicação com o Twitter sob diversas plataformas e sem custos. Também como o sistema de automação busca as mensagens do servidor do Twitter não é necessário que a residência possua um endereço de IP fixo. Uma das grandes vantagens de se optar pelo Twitter é a comunicação com o sistema de automação realizado através de multi-plataformas, não existindo limitação para sistema operacional, seja para computadores ou celulares, ainda com a opção da comunicação via SMS. O desenvolvimento deste sistema permitiu a contribuição à comunidade destinada ao hardware FEZ e a linguagem embarcada Micro Framework.Net, uma vez que não há nenhum sistema similar. O sistema foi pioneiro neste tipo de comunicação gerando assim várias dificuldades que foram necessárias ser transpostas, assim como, protocolos de comunicação com a placa de conexão Ethernet e comunicação utilizando socket respeitando as limitações de memória do hardware FEZ. A automação baseada em mensagens recebidas pelo Twitter é o principal diferencial do sistema, porem é também uma de suas limitações. O sistema é dependente deste serviço, logo, caso o site não esteja online o sistema também não estará. O protocolo de comunicação com a API do Twitter é passível de mudanças, que acabou gerando atrasos e dificuldades durante o desenvolvimento do sistema. Para que fosse possível transpor estas dificuldades com autenticações e criptografia dos dados foi necessário

49 48 o desenvolvimento de dois programas de apoio ao sistema de automação, um WebService para realizar a comunicação com o Twitter e o hardware FEZ e outro sistema para gerar as chaves de autenticação do usuário monitor (Token e TokenSecret). Foi necessário o investimento de aproximadamente mil reais na construção do sistema, entre importação do hardware FEZ e Ethernet Shield, componentes para a placa CLPIC e componentes elétricos para montagem de tomadas que são utilizadas para exemplificação do sistema. O sistema foi um desafio desde sua implementação até a construção de seus componentes físicos, um processo que demandou experiência e estudo na área de eletrônica. Este estudo levou à aquisição de importantes conhecimentos em eletrônica e à ampliação dos saberes em sistemas embarcados, especialmente no uso do Micro Framework.Net que está em ascensão. 4.1 EXTENSÕES Embora a implementação do sistema de automação ofereça a configuração externa dos principais parâmetros, e não de forma fixa no programa, outras funcionalidades poderiam ser desenvolvidas, entre elas: a) desenvolvimento de um sistema gerenciador dos arquivos de configuração de forma que a edição seja mais amigável ao administrador; b) inclusão de um arquivo de configuração de cômodos do imóveis, de modo a criar restrições aos usuários por estes cômodos; c) inclusão de uma arquivo de configuração de agendamento de comandos, de modo a possibilitar a execução programada ou recursiva sem a necessidade de estar enviando um comando; d) desenvolvimento da autenticação do usuário utilizando o método xauth, armazenando a senha direta do usuário; e) desenvolvimento de um programa auxiliar mais intuitivo e específico para este sistema, para que o administrador obtenha mais facilmente as informações de Token e TokenSecret do usuário. A criação destas funcionalidades implica em um sistema mais condizente com o mercado e às necessidades dos usuários.