LWiSSy: Uma Linguagem Específica de Domínio Para Modelagem de Sistemas de Redes de Sensores e Atuadores Sem Fio

Tamanho: px
Começar a partir da página:

Download "LWiSSy: Uma Linguagem Específica de Domínio Para Modelagem de Sistemas de Redes de Sensores e Atuadores Sem Fio"

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO DISSERTAÇÃO DE MESTRADO LWiSSy: Uma Linguagem Específica de Domínio Para Modelagem de Sistemas de Redes de Sensores e Atuadores Sem Fio Priscilla Victor Dantas Natal-RN Setembro 2012

2 Priscilla Victor Dantas LWiSSy: Uma Linguagem Específica de Domínio para Modelagem de Sistemas de Redes de Sensores e Atuadores Sem Fio Dissertação de Mestrado submetida ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como parte dos requisitos necessários para a obtenção do grau de Mestre em Sistemas e Computação. Orientador(a) Prof.ª Dr.ª Flávia Coimbra Delicato Co-orientador(a) Prof.ª Dr.ª Thaís Vasconcelos Batista Universidade Federal do Rio Grande do Norte UFRN Departamento de Informática e Matemática Aplicada DIMAp Natal-RN Setembro 2012

3 UFRN / Biblioteca Central Zila Mamede Catalogação da Publicação na Fonte Dantas, Priscilla Victor. LWiSSy: uma linguagem específica de domínio para modelagem de sistemas de redes de sensores e atuadores sem fio. / Priscilla Victor Dantas. Natal, RN, f. : il. Orientadora: Profa. Dra. Flávia Coimbra Delicato. Co-orientadora: Profa. Dra. Thaís Vasconcelos Batista. Dissertação (Mestrado) Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação. 1. Redes de sensores sem fio Dissertação. 2. Atuadores sem fio - Dissertação. 3. LWiSSy - Dissertação. 4. Linguagem específica de domínio Dissertação. 5. Modularização Dissertação. I. Delicato, Flávia Coimbra. II. Batista, Thaís Vasconcelos. III. Universidade Federal do Rio Grande do Norte. IV. Título. RN/UF/BCZM CDU

4 Aos meus pais, avós e irmã, pela compreensão, incentivo, apoio e carinho que me ofereceram, dedico mais essa conquista como gratidão.

5 AGRADECIMENTOS Este ciclo que aqui se encerra é apenas mais um dos vários que pretendo concluir durante minha vida acadêmica. Trata-se na realidade de mais uma porta aberta após anos de dedicação a esta pesquisa. Desde já gostaria de agradecer a Deus, pois ao longo deste ciclo fui abençoada pela presença de várias pessoas importantes e, sem as quais, eu não teria conseguido superar os percalços do caminho. As minhas orientadoras Flávia e Thaís, sem as quais eu não teria sequer começado este ciclo. Agradeço em especial a Flávia, a qual me acompanha desde a graduação e que, mesmo sem perceber, me fez descobrir todo o potencial que eu tenho e sempre procurou me ajudar nos momentos mais difíceis, mesmo que a distância. Aos meus pais, minha avó e minha irmã que nunca duvidaram da minha capacidade e sempre me ajudaram com palavras de apoio e incentivo. A Taniro, meu parceiro de pesquisa que desde o início me ajudou bastante e com o qual eu espero trabalhar mais vezes. As minhas amigas Paula, Amanda, Isolda, Tati, Renata Souza e Thaís Burity que por muitas vezes me fizeram enxergar além dos problemas e, me arrisco a dizer, até me carregaram diante algumas dificuldades, deixo aqui o meu imenso agradecimento por tudo.

6 O ignorante afirma, o sábio duvida, o sensato reflete. Aristóteles

7 RESUMO DANTAS, Priscilla Victor. LWiSSy: Uma Linguagem Específica de Domínio para Modelagem de Sistemas de Redes de Sensores e Atuadores Sem Fio. Natal, Dissertação (Mestrado em Sistemas e Computação) Programa de Pós- Graduação em Sistemas e Computação/Departamento de Informática e Matemática Aplicada, Universidade Federal do Rio Grande do Norte, Natal, As Redes de Sensores e Atuadores Sem Fio (RSASF) vêm emergindo rapidamente e têm atraído o interesse da comunidade de pesquisa e da indústria, graças a vários fatores, dentre eles a aplicabilidade desse tipo de rede nos mais diversos domínios de aplicações (aviação, engenharia civil, medicina, dentre outros). Além disso, avanços na comunicação sem fio e miniaturização dos componentes de hardware também contribuíram para a rápida proliferação dessas redes. Apesar disso, ainda existem alguns desafios a serem transpostos a fim de se atingir o pleno potencial de utilização das RSASF. Dentre estes, o desenvolvimento de sistemas de RSASF aparece como um dos mais relevantes atualmente, haja vista a quantidade de variáveis envolvidas no processo de desenvolvimento. Atualmente, uma vasta gama de plataformas de RSASF e diversas linguagens de programação de baixo nível podem ser empregadas no desenvolvimento desses sistemas. Dessa forma, é necessário que o desenvolvedor possua tanto conhecimento de baixo nível relativo à plataforma da RSASF, quanto conhecimento específico do domínio de cada uma das aplicações presentes no sistema. A fim de efetuar o desacoplamento da utilização destes conhecimentos durante o processo de desenvolvimento, de forma a facilitar tal processo, este trabalho propõe LWiSSy (Domain Language for Wireless Sensor and Actuator Networks Systems), uma linguagem para modelagem de sistemas para RSASF baseada no uso de DSLs (Domain Specific Language). As DSLs, pelo fato de aumentarem o nível de abstração da programação e modularizarem a construção de sistemas em

8 várias etapas, permitirão que ambos os especialistas envolvidos (domínio e redes) possam contribuir diretamente durante o desenvolvimento do sistema e de maneira mais desacoplada do que ocorre atualmente. Além dos benefícios supracitados, LWiSSy possibilitará ainda a decomposição do sistema em diferentes níveis de abstração, haja vista a necessidade de representar diferentes características (estrutural e comportamental) e granulosidades (programação em nível de rede, em nível de grupos de nós e em nível de nó) em um único sistema. Palavras-chave: Redes de Sensores e Atuadores Sem Fio, LWiSSy, Linguagem Específica de Domínio, modularização.

9 ABSTRACT DANTAS, Priscilla Victor. LWiSSy: Uma Linguagem Específica de Domínio para Modelagem de Sistemas de Redes de Sensores e Atuadores Sem Fio. Natal, Dissertação (Mestrado em Sistemas e Computação) Programa de Pós- Graduação em Sistemas e Computação/Departamento de Informática e Matemática Aplicada, Universidade Federal do Rio Grande do Norte, Natal, The field of Wireless Sensor and Actuator Networks (WSAN) is fast increasing and has attracted the interest of both the research community and the industry because of several factors, such as the applicability of such networks in different application domains (aviation, civil engineering, medicine, and others). Moreover, advances in wireless communication and the reduction of hardware components size also contributed for a fast spread of these networks. However, there are still several challenges and open issues that need to be tackled in order to achieve the full potential of WSAN usage. The development of WSAN systems is one of the most relevant of these challenges considering the number of variables involved in this process. Currently, a broad range of WSAN platforms and low level programming languages are available to build WSAN systems. Thus, developers need to deal with details of different sensor platforms and low-level programming abstractions of sensor operational systems on one hand, and they also need to have specific (high level) knowledge about the distinct application domains, on the other hand. Therefore, in order to decouple the handling of these two different levels of knowledge, making easier the development process of WSAN systems, we propose LWiSSy (Domain Language for Wireless Sensor and Actuator Networks Systems), a domain specific language (DSL) for WSAN. The use of DSLs raises the abstraction level during the programming of systems and modularizes the system building in several steps. Thus, LWiSSy allows the domain experts to directly contribute in the development of WSANs without having knowledge on low level sensor platforms,

10 and network experts to program sensor nodes to meet application requirements without having specific knowledge on the application domain. Additionally, LWiSSy enables the system decomposition in different levels of abstraction according to structural and behavioral features and granularities (network, node group and single node level programming). Keywords: Wireless Sensor and Actuator Network, LWiSSy, Domain Specific Language, modularization.

11 LISTA DE FIGURAS FIGURA 2-1 ATUAÇÃO DE UM NÓ SINK NUMA RSASFS FIGURA 2-2 COMPONENTES DO HARDWARE DE UM NÓ SENSOR FIGURA 2-3 PILHA DE PROTOCOLOS DAS RSSFS FIGURA 2-4 HARDWARE CONSTITUINTE DO DISPOSITIVO SUN SPOT FIGURA 2-5 MICAZ MOTE FIGURA 2-6 DIVERSAS VERSÕES DE ARDUÍNO FIGURA 2-7 XBEE SHIELD FIGURA 2-8 ARTEFATOS ENVOLVIDOS NA ABORDAGEM MDA FIGURA 2-9 OS TRÊS PASSOS PRINCIPAIS NO PROCESSO MDA FIGURA 2-10 TRANSFORMAÇÃO PIM PARA PSM FIGURA 4-1 METAMODELO DA DSL INTERMEDIÁRIA COM DESTAQUE PARA AS DIFERENÇAS ENTRE ELA E A PROPOSTA EM [LOSILLA, 2007] FIGURA 4-3 MODELO GRÁFICO QUE REPRESENTA A VISÃO ESTRUTURAL EM LWISSY FIGURA 4-4 MODELO GRÁFICO QUE REPRESENTA A VISÃO COMPORTAMENTAL EM LWISSY FIGURA 4-5 MODELO GRÁFICO QUE REPRESENTA A VISÃO DE REFINAMENTO EM LWISSY FIGURA 4-6 CONSTRUÇÃO DA INFRAESTRUTURA MDA UTILIZADA FIGURA 4-7 ADAPTAÇÃO DO PROCESSO DE DESENVOLVIMENTO PROPOSTO EM [RODRIGUES, 2011] FIGURA 4-8 VISÃO ESTRUTURAL DO SISTEMA FIRE DETECTION SYSTEM ESPECIFICADA PELO ESPECIALISTA DE DOMÍNIO FIGURA 4-9 VISÃO COMPORTAMENTAL DA APLICAÇÃO TEMPERATURE MONITORING ESPECIFICADA PELO ESPECIALISTA DE DOMÍNIO FIGURA 4-10 VISÃO COMPORTAMENTAL DA APLICAÇÃO TRIGGER ALARM ESPECIFICADA PELO ESPECIALISTA DE DOMÍNIO FIGURA 4-11 VISÃO DE REFINAMENTO DO SISTEMA FIRE DETECTION SYSTEM ESPECIFICADA PELO ESPECIALISTA DE REDES FIGURA 5-1 MODELAGEM DA APLICAÇÃO DE SHM COM A DSL INTERMEDIÁRIA FIGURA 5-2 MODELAGEM DA APLICAÇÃO BURNING FOREST COM A DSL INTERMEDIÁRIA FIGURA 5-3 MODELAGEM ESTRUTURAL DO SISTEMA ACCIDENTAL FALL DETECTION SYSTEM UTILIZANDO A DSL LWISSY FIGURA 5-4 MODELAGEM COMPORTAMENTAL DA APLICAÇÃO POSITION SENSING UTILIZANDO A DSL LWISSY FIGURA 5-5 MODELAGEM COMPORTAMENTAL DA APLICAÇÃO MOVEMENT SENSING UTILIZANDO A DSL LWISSY FIGURA 5-6 MODELAGEM COMPORTAMENTAL DA APLICAÇÃO VIDEO CHECK UTILIZANDO A DSL LWISSY FIGURA 5-7 MODELAGEM COMPORTAMENTAL DA APLICAÇÃO FALL CHECK UTILIZANDO A DSL LWISSY FIGURA 5-8 MODELAGEM DE REFINAMENTO DO SISTEMA ACCIDENT FALL DETECTION SYSTEM UTILIZANDO A DSL LWISSY FIGURA 5-9 MODELAGEM DO SISTEMA ACCIDENTAL FALL DETECTION UTILIZANDO A DSL PROPOSTA POR [LOSILLA, 2007] FIGURA 5-10 MODELAGEM EM NÍVEL DE REDE DO SISTEMA ACCIDENTAL FALL DETECTION SYSTEM UTILIZANDO A DSL PROPOSTA POR [SHIMIZU, 2011]

12 FIGURA 5-11 MODELAGEM EM NÍVEL DE GRUPOS DE NÓS DO SISTEMA ACCIDENTAL FALL DETECTION SYSTEM UTILIZANDO A DSL PROPOSTA POR [SHIMIZU, 2011] FIGURA 5-12 MODELAGEM EM NÍVEL DE NÓS DO SISTEMA ACCIDENTAL FALL DETECTION SYSTEM UTILIZANDO A DSL PROPOSTA POR [SHIMIZU, 2011]

13 Lista de tabelas TABELA 2-1 CARACTERIZAÇÃO DAS RSASFS SEGUNDO A CONFIGURAÇÃO TABELA 2-2 COMPARAÇÃO DE CÓDIGO BLOQUEANTE E DIVIDIDO EM FASES TABELA 3-1 SUMARIZAÇÃO DAS CARACTERÍSTICAS DAS DSLS DISCUTIDAS NESTE CAPÍTULO E LWISSY TABELA 5-1 RESULTADO GERAL DA ANÁLISE COMPARATIVA ENTRE AS DSLS TABELA 5-2 VISÃO GERAL DO EXPERIMENTO

14 Lista de abreviaturas e siglas ADC - Analog to Digital Converter APT Automatically Programmed Tool AST - Abstract Syntax Tree BNF - Backus-Naur Form CIM - Computation Independent Model CLDC - Connected Limited Device Configuration CPU Central Process Unit DC Direct Current DSL Domain Specific Language EMF Eclipse Modeling Framework ESRT - Event-to-Sink Reliable Transfer GEF - Graphical Editing Framework GMF Graphical Modeling Framework IDE Integrated Development Environment IEEE Institute of Electrical and Electronics Engineers J2ME Java Micro Edition LEACH Low-Energy Adaptive Clustering Hierarchy LQRP - Link Quality Routing Protocol LWiSSy Domain Language for Wireless Sensor Networks Systems M2M Model to Model M2T Model to Text MATLAB Matrix Laboratory

15 MDA Model Driven Architecture MDD Model Driven Development MIDP Mobile Information Device Profile nesc network embedded systems C OCL Object Constraint Language OMG - Object Management Group PC Personal Computer PDM - Platform Definition Model PIM Platform Independent Model PROC Proactive Routing with Coordination PSFQ Pump Slowly, Fetch Quickly PSM Platform Specific Model QoS Quality of Service RMST Reliable Multi-Segment Transport RSSF Redes de Sensores e Atuadores Sem Fio RSSF - Redes de Sensores Sem Fio SHM Structural Health Monitoring SMP - Sensor Management Protocol SO Sistema Operacional SQDDP - Sensor Query and Data Dissemination Protocol Sun SPOT - Sun Small Programmable Object Technology TADAP - Task Assignment and. Data Advertisement Protocol tinyos - Tiny Operational System UML Unified Modeling Language

16 USA United States of America USB Universal Serial Bus VM Virtual Machine XMI XML Metadata Interchange XML extensible Markup Language

17 Sumário Lista de tabelas Lista de abreviaturas e siglas Sumário Introdução Motivação Objetivos Organização do documento Conceitos Básicos Redes de Sensores e Atuadores Sem Fio Arquitetura Modelos de comunicação e entrega de dados em RSASFs Qualidade de serviço (QoS) em RSASFs Plataformas para RSASF Sun SPOT TinyOS Arduíno Linguagem Específica de Domínio Vantagens e Desvantagens de DSLs Ferramentas de Modelagem Desenvolvimento Dirigido a Modelos Modelos Transformações Trabalhos Relacionados Modelagem de Sistemas para RSASF Utilizando LWiSSy... 63

18 4.1. DSL para RSASF: Primeira versão LWiSSy Visão estrutural Visão comportamental Visão de refinamento Descrição da Infraestrutura MDA Desenvolvimento de sistemas utilizando LWiSSy Exemplo ilustrativo Avaliação Análise da DSL Intermediária Proposta Prova de conceito Cenários de mudança LWiSSy Análise Comparativa Experimento Controlado Conclusões e Trabalhos Futuros Referências Anexo A. Questionários

19 1. Introdução Redes de Sensores e Atuadores Sem Fio (RSASF) constituem atualmente uma área de pesquisa bastante promissora devido, em parte, aos grandes avanços recentes na microeletrônica e nas tecnologias de redes sem fio, e em parte à sua potencial aplicação em diferentes domínios, como por exemplo, militar, monitoramento ambiental e de habitat, controle e monitoramento industrial, monitoramento de estruturas civis, segurança, monitoramento da saúde de pacientes, dentre inúmeras outras [WANG, 2008]. Uma RSASF é composta por dispositivos, geralmente alimentados por baterias, que incorporam diversas funcionalidades (processamento, sensoriamento, comunicação sem fio, atuação, etc.) e são espacialmente distribuídos em uma região que se deseja monitorar [SADILEK, 2007]. Sistemas de RSASFs são compostos por uma ou mais aplicações que observam o mundo físico e obtêm informações úteis a partir dele. Logo após os dados serem obtidos pelos elementos de sensoriamento, eles são processados e analisados para que decisões sejam tomadas com base neles e, caso necessário, operações concretas sejam executadas no ambiente monitorado [LOSILLA, 2007] através do uso dos elementos atuadores. Por exemplo, em uma aplicação de irrigação de plantio presente em um sistema de RSASF, um sensor pode coletar variáveis ambientais diversas (como umidade e temperatura) e, a partir dos dados coletados, enviar a informação para os nós sensores vizinhos (aqueles que estão espacialmente próximos), de forma a determinar se certa área do plantio necessita ou não de irrigação. Caso a irrigação seja necessária, um nó atuador pode acionar as mangueiras para que estas efetuem a irrigação da área em questão. A primeira geração de sistemas de RSASFs adotava uma abordagem de projeto específico da aplicação [HEINZELMAN, 2002], tendo como objetivo principal obter eficiência em energia, tendo em vista as restrições de bateria dos 19

20 nós. Nesse contexto, a maioria dos sistemas, os quais eram compostos por apenas uma aplicação, era desenvolvido como software monolítico construído para uma dada plataforma de sensores alvo e um dado sistema operacional (SO). Os desenvolvedores de sistemas precisavam conhecer vários detalhes da operação da rede e dos protocolos utilizados e construir seus programas ou usando as abstrações de baixo nível providas pelo SO dos sensores, ou diretamente sobre o hardware. Os sistemas eram, portanto, desenvolvidos em linguagem de programação de baixo nível, determinadas a partir da escolha da plataforma de sensores alvo, para que então fossem especificados os aspectos relativos ao domínio do problema. A falta de uma metodologia formal ou sistemática para prover suporte a todo o ciclo de vida de desenvolvimento desses sistemas resultava em projetos dependentes de plataforma e código difícil de manter, alterar e reusar. Como exemplo do cenário descrito acima, pode-se imaginar a situação na qual uma empresa deseja desenvolver um software para o monitoramento de estruturas de plataformas de petróleo. Caso a empresa decida contratar uma equipe de programadores especializados em programação de RSASFs, estes encontrarão diversas barreiras no desenvolvimento do sistema, as quais estão diretamente relacionadas com o conhecimento do domínio do problema (ou seja, a área da engenharia civil centrada no monitoramento de estruturas), tais como conhecimentos sobre a estrutura e o tipo da plataforma, fatores que afetam a saúde (estrutural) da plataforma, forma de distribuição dos sensores e atuadores para obter as melhores medições, além de toda a parte relativa aos modelos matemáticos necessários para executar na rede. Por outro lado, se a empresa contratar apenas especialistas do domínio de monitoramento de estruturas, estes encontrarão dificuldades na implementação dos programas, já que engenheiros civis em geral constroem suas aplicações usando a linguagem C ou MATLAB, e não possuem conhecimento de programação de mais baixo nível usada em RSASFs. 20

21 Nesse contexto, é possível perceber que o desenvolvimento de sistemas para RSASFs impõe vários desafios para o programador, requerendo habilidades e conhecimentos distintos. Por um lado, existe a necessidade de conhecimento específico de plataformas de RSASFs e de lidar com um baixo nível de abstração na construção dos sistemas, e por outro, conhecimento específico sobre o domínio da aplicação a ser executada na rede, que pode envolver as mais diversas áreas do conhecimento humano. Claramente, há diferentes níveis de abstração envolvidos no desenvolvimento de sistemas para RSASF, sendo que especialistas em domínios desejam preferencialmente lidar com abstrações de mais alto nível, enquanto que especialistas em redes podem ser expostos a lidar com abstrações de mais baixo nível. Adicionalmente, há várias decisões de projeto na área de RSASFs que envolvem conhecimento tanto de alto nível (sistema e aplicações) quanto de baixo nível (protocolos e configurações da rede), já que a existência de otimizações específicas do sistema e de cada uma das aplicações comprovadamente contribuem para a eficiência em energia global da rede [YU, 2004]. Nota-se ainda que, com as abordagens tradicionais de programação para RSASF, nenhum tipo de reuso (conhecimento, programação, domínio) é facilitado, dificultando assim qualquer mudança de plataforma visto que todo o sistema terá que ser refeito do zero. Por fim, é importante ressaltar que o custo com a manutenção do sistema é elevado, uma vez que as linguagens de programação utilizadas possuem baixo nível de abstração Motivação Há atualmente uma grande diversidade de plataformas que oferecem suporte ao desenvolvimento e execução de sistemas para RSASFs, cada uma com seus próprios requisitos, ambientes e ferramentas associados. Por exemplo, os sensores da família MICA [Crossbow, 2012] utilizam o sistema operacional tinyos [TinyOS, 2012], o qual disponibiliza para os desenvolvedores a linguagem nesc (um dialeto da linguagem C otimizado para as limitações de 21

22 memória de um sistema de RSASF) [nesc, 2012]. Os sensores Sun SPOT [Sun SPOT, 2012] utilizam a linguagem Java, versão MicroEdition, para desenvolvimento de sistemas, os quais executam diretamente sobre o hardware sem necessidade de sistema operacional, haja vista a utilização da máquina virtual da plataforma J2ME, Squawk Virtual Machine. Já os sensores da plataforma open-source Arduíno [Projeto Arduíno, 2012] utilizam uma linguagem própria baseada em C/C++. O desenvolvimento de aplicações para RSASFs não é uma tarefa fácil, uma vez que tais redes apresentam requisitos específicos, como limitações críticas dos recursos dos nós, abstrações de baixo nível disponíveis para construir programas e a necessidade de gerenciar, de modo eficiente, a comunicação e a coordenação dos nós (que muitas vezes chegam à ordem de centenas ou até milhares de nós em uma rede). Além de demandar requisitos específicos, as RSASFs também se caracterizam por uma enorme heterogeneidade com respeito ao software, as tecnologias de rádios empregadas, as capacidades dos nós, aos protocolos de redes, as estratégias de segurança que podem ser utilizadas, aos mecanismos de localização e de mobilidade, dentre outros. Em adição, há uma grande heterogeneidade nos requisitos das aplicações já que, como visto, RSASFs podem ser úteis para uma ampla gama de domínios. Diferentemente dos sistemas de RSASFs de primeira geração, os quais foram citados anteriormente, o projeto de redes atuais e futuras tem seguido novas tendências e sofrido importantes mudanças. Dentre elas, há uma tendência em projetar sistemas de RSASFs de larga escala para diferentes aplicações, as quais podem rodar concomitantemente ou não nos nós instalados. Ou seja, a abordagem de projetar redes específicas para uma única aplicação alvo tem sido substituída pela construção de redes de propósito geral, onde a infraestrutura de sensoriamento é compartilhada por múltiplas aplicações [BHATTACHARYA, 2010]. Esta nova geração de sistemas para RSASF, que tem sido denominada de Redes de Sensores Compartilhadas (Shared Sensor Networks ou Federated Sensor Networks [LEONTIADIS, 2012]) ou sistemas 22

23 multifuncionais, oferece vantagens em termos de custo e flexibilidade, uma vez que os nós sensores são compartilhados entre as diversas aplicações que compõem o sistema. Além disso, nessa nova abordagem, os nós dessas redes devem ser programados para cada uma das aplicações, preferencialmente através de interfaces de alto nível que abstraiam as características das plataformas subjacentes e permitam aos desenvolvedores representarem os requisitos de seus domínios de aplicações utilizando linguagens com as quais estejam mais familiarizados. Nesses cenários emergentes, é indesejável (e improvável) que, em tempo de projeto, os desenvolvedores já saibam as características das plataformas de RSSF nas quais suas aplicações irão executar. Ao mesmo tempo em que é importante possibilitar a participação dos especialistas de domínio durante o processo de desenvolvimento do sistema e desacoplar o sistema da infraestrutura de rede subjacente na qual ele irá executar, sendo, portanto necessário prover interfaces de alto nível de abstração, também é essencial haver a possibilidade de otimização (refinamento) do sistema de RSASF como um todo e de cada uma das aplicações geradas, haja vista as limitações de recursos existentes neste tipo de rede. Tal refinamento muitas vezes requer a manipulação de funcionalidades de baixo nível, como por exemplo, o modelo de entrega de dados ou a topologia de rede utilizada, o que gera um tradeoff entre o alto grau de abstração desejado por especialistas de domínio e o potencial de otimização requerido pelos especialistas de redes. Adicionalmente, a programação de uma RSASF dá-se em diferentes granulosidades, podendo envolver desde a especificação de um processo de alto nível (macro-programação), descrevendo toda a infraestrutura do sistema, até a especificação do processamento individual a ser realizado internamente por cada nó da rede (micro-programação), passando pela programação de grupos de nós, ou seja, a descrição de cada uma das aplicações presentes no sistema (em termos do fluxo de dados ou de controle necessário para realizar todos os passos do processo). Portanto, podem-se 23

24 identificar diferentes níveis de abstração em termos dos requisitos dos usuários envolvidos e da granulosidade da programação, com impacto direto na capacidade de otimização provida pelos diferentes níveis de abstração. Neste trabalho argumenta-se que a adoção de uma DSL (Domain Specific Language) durante este processo é uma solução que permite a programação de sistemas para RSASF em diferentes níveis de abstração, de acordo com o especialista envolvido, harmonizando a lacuna existente entre os conhecimentos de nível específico de cada uma das aplicações e de nível de plataformas de RSASFs, tirando o melhor proveito de ambos, e que mantém um alto nível de otimização destas aplicações. Nesse trabalho propomos a linguagem LWiSSy (Domain Language for Wireless Sensor Networks Systems). Além de promover os benefícios supramencionados, os elementos de LWiSSy permitem a especificação de sistemas de modo a, por um lado, esconder detalhes de implementação quando desejado e, por outro lado, expor tais detalhes quando necessário (com o intuito de melhorar o desempenho da rede). Com o intuito de gerar, de maneira rápida, eficiente e automática, o códigofonte dos sistemas modelados com LWiSSy, este trabalho utilizará a abordagem MDD (Model Driven Development) proposta em [RODRIGUES, 2011]. No MDD o sistema é construído a partir de modelos, os quais são mapeados de um nível de abstração para outro através de definições de transformações. Os modelos são gerados com base em metamodelos, os quais são modelos que definem a estrutura e regras de formação da linguagem na qual os modelos serão expressos. No decorrer do trabalho será demonstrado como o uso de linguagens específicas de domínio pode aumentar o nível de abstração durante a modelagem de sistemas, aumentar o reuso de conhecimento de nível do especialista de domínio, facilitar o desenvolvimento de sistemas multifuncionais e permitir a realização de otimizações nos sistemas e nas aplicações que o 24

25 compõem. Em caso de mudança de plataforma-alvo, os modelos gerados podem ser reusados para a remodelagem do sistema desde que metamodelos e programas de transformação que definem a nova plataforma-alvo sejam construídos Objetivos O objetivo geral deste trabalho é propor a linguagem LWiSSy, uma linguagem específica para o domínio de RSASF que será gerada com base na UML (Unified Modeling Language). LWiSSy possibilitará: (i) a participação direta do especialista de domínio durante o ciclo de desenvolvimento de sistemas para RSASF; (ii) a decomposição do sistema em diferentes níveis de abstração, haja vista a necessidade de representar diferentes características (estrutural e comportamental) e granulosidades (programação em nível de rede, em nível de grupos de nós e em nível de nó) em um único sistema. O metamodelo que define a linguagem será especificado com expressividade suficiente para atender uma ampla gama de domínios, levando sempre em consideração a legibilidade, para que não seja exigido, do especialista de domínio, um profundo conhecimento a respeito de RSASF. Com a utilização da infraestrutura MDA (Model Driven Architecture) proposta em [RODRIGUES, 2011] não será necessário especificar os metamodelos das plataformas que serão utilizadas (Sun SPOT e tinyos), nem definir os respectivos programas de transformação de modelo para texto (M2T), uma vez que estes artefatos já foram desenvolvidos. Os objetivos secundários deste trabalho: Definição dos programas de transformação entre modelos (M2M - Model to Model), para que seja possível efetuar as transformações necessárias entre a linguagem proposta e os modelos das plataformas; 25

26 Análise de LWiSSy por meio de um experimento controlado com o objetivo de avaliar se a adoção da linguagem afeta no entendimento de sistemas de RSASF; Análise comparativa entre LWiSSy e outras duas DSLs presentes na literatura ([LOSILLA, 2007] e [SHIMIZU, 2011]) a fim de avaliar a expressividade da linguagem proposta neste trabalho e seus benefícios com relação a outras propostas existentes Organização do documento O restante deste trabalho está estruturado em cinco capítulos. O Capítulo 2 apresenta os conceitos básicos necessários para o entendimento deste trabalho. O Capítulo 3 discorre sobre alguns trabalhos relacionados presentes na literatura. O Capítulo 4 expõe, em detalhes, LWiSSy, a linguagem proposta, e a infraestrutura MDA utilizada. O processo de avaliação do trabalho é discutido no Capítulo 5. Por fim, o Capítulo 6 apresenta as conclusões e os trabalhos futuros. 26

27 2. Conceitos Básicos Este Capítulo apresenta alguns conceitos básicos que serão úteis para a compreensão do trabalho. A Seção 2.1 abrange a área de Redes de Sensores e Atuadores Sem Fio, contendo descrições básicas como arquitetura, funcionamento e exemplos de aplicações. A Seção 2.2 faz uma breve descrição acerca das plataformas para redes de sensores e atuadores sem fio que serão utilizadas. O conceito de Linguagem Específica de Domínio (Domain Specific Language - DSL) será discutido na Seção 2.3. A Seção 2.4 apresenta as ferramentas de modelagem que foram utilizadas durante o desenvolvimento de LWiSSy. Por fim, a Seção 2.5 discorre sobre a abordagem MDA utilizada no presente trabalho durante o processo de desenvolvimento de sistemas para RSASF Redes de Sensores e Atuadores Sem Fio Uma RSASF é uma Rede Sem Fio do tipo ad hoc, composta por dezenas a milhares de dispositivos eletrônicos de baixo custo, que tem como principal objetivo realizar tarefas de sensoriamento de forma distribuída em benefício de aplicações clientes e executar ações no ambiente monitorado. Elas diferem das redes de computadores tradicionais por vários motivos, dentre os quais podemos citar: não utilização de meios físicos de comunicação, baixos recursos de memória e processador, quantidade limitada de energia, entre outros. Embora um nó sensor possua pouca capacidade computacional e de energia, um esforço colaborativo entre vários nós sensores proporciona a realização de tarefas com uma eficiência muito maior. Para que isso seja possível é necessário distribuir os sensores no ambiente de forma que as propriedades essenciais sejam preservadas. Tal distribuição pode ser feita de maneira estratégica ou de forma aleatória (ad hoc). 27

28 Os nós sensores coletam as informações do ambiente (temperatura, pressão, etc.), comunicam-se uns com os outros, fazendo um processamento local antes, se necessário, e enviam os dados coletados para os nós sorvedouros (sink node), que, por sua vez, coletam as informações enviadas pelos nós sensores e as entrega ao usuário ou a aplicação final. O sorvedouro, diferentemente dos demais nós da rede, geralmente possui maior poder computacional, não tem restrição de energia e localiza-se geograficamente distante da área onde os sensores estão instalados. Esses nós funcionam como uma interface entre a aplicação e a rede. A Figura 2-1 exibe um exemplo da atuação de um nó sorvedouro numa RSASF. O nó E coleta um determinado fenômeno e comunica-se com seus vizinhos, a fim de levar a informação até o Ponto de Acesso. Figura 2-1 Atuação de um nó sink numa RSASFs. Nós sensores podem ser distribuídos em diversos locais, inclusive de difícil acesso. Assim sendo, é fundamental que a rede consiga operar durante longos períodos de tempo sem a intervenção humana. Além disso, os nós são alimentados, no geral, por baterias não recarregáveis, portanto o tempo de vida operacional da RSASF é severamente limitado pela capacidade da bateria dos seus nós. Dessa maneira, todas as etapas de projeto e funcionamento de RSASFs devem levar em conta o consumo de energia e procurar otimizá-lo. RSASFs em geral possuem uma alta densidade de nós, o que faz com que vários sensores monitorem o mesmo fenômeno, gerando dados redundantes. 28

29 Como a maior fonte de consumo de energia nos sensores é a transmissão de dados, grande parte das pesquisas visam propor soluções para obter e rotear os dados de forma eficiente em energia, a fim de estender o tempo de vida global da rede. No entanto, independente da solução escolhida, deve haver um equilíbrio entre o consumo de energia e a qualidade global do dado entregue à aplicação. Por sua vez, os nós atuadores, os quais operam em resposta a situações interpretadas pelos nós sensores, possuem a função de modificar valores do meio a fim de corrigir falhas e controlar o objeto monitorado. As redes compostas de atuadores apresentam um grande interesse em diferentes áreas como a área médica, onde sistemas embutidos podem liberar medicamentos de acordo com as necessidades do paciente [LOUREIRO, 2003]. Além dos fatores já mencionados, RSASF possuem uma estrutura topológica altamente dinâmica. Dependendo da aplicação, nós podem se movimentar, podem ser retirados da rede ao terem seus recursos esgotados, novos nós podem ser adicionados ou podem ser temporariamente desligados por medida de economia de energia, alterando assim a topologia ativa da rede. As condições ambientais onde a rede está instalada também podem sofrer alterações. Logo, as RSASFs devem possuir um elevado grau de auto-organização e adaptação. A maioria dos protocolos de roteamento de dados baseia-se na comunicação multi-hop de curto alcance e adotam algum mecanismo de agregação de dados dentro da rede, diminuindo assim o número de mensagens transmitidas através dos sensores Arquitetura Redes de sensores e atuadores sem fio são compostas por três componentes organizacionais, são eles: infraestrutura, pilha de protocolos e aplicação. Esta Seção tem como objetivo explorar estes componentes. 29

30 A infraestrutura de uma RSASF consiste nos nós da rede (características físicas e capacidades) e no seu estado de instalação no ambiente. O hardware de um nó sensor é composto tipicamente por quatro subsistemas: sensoriamento, processamento, comunicação e energia (Figura 2-2). Figura 2-2 Componentes do hardware de um nó sensor. O subsistema de sensoriamento é composto pelos dispositivos de sensoriamento e pelo conversor de sinal analógico para digital (ADC). Os dispositivos de sensoriamento têm capacidade de sensoriar diversos tipos de condições ambientais, como: temperatura, umidade, movimento veicular, níveis de ruído, níveis de stress mecânico de objetos, e características como velocidade, direção e tamanho de um objeto. Um nó sensor pode conter uma ou mais unidades de sensoriamento. Sua função é coletar, eventualmente agregar, e transmitir seus próprios dados e os dos seus vizinhos para os nós sorvedouros. Já o subsistema de processamento tem o objetivo de controlar os sensores, executar os protocolos de comunicação e os algoritmos de processamento de 30

31 dados e gerenciar os procedimentos necessários para que haja colaboração entre os nós. O subsistema de comunicação é composto, geralmente, por um dispositivo de rádio frequência. No entanto, também é possível utilizar um dispositivo ótico ativo ou passivo. O subsistema de comunicação que utiliza rádio frequência é composto por um transceiver, uma antena e um conjunto de componentes discretos para configurar as características da camada física. O qual pode operar em três modos: recepção, transmissão e desligado (power-off). Por fim, o subsistema de energia é composto por uma bateria e um conversor DC-DC. Existem vários tipos de bateria que podem ser utilizadas em um nó sensor e cada uma possui suas particularidades. Quanto ao conversor DC-DC, ele recebe uma voltagem DC de entrada e produz uma voltagem DC de saída que, no geral, é diferente da primeira. Ele é responsável por fornecer uma tensão constante para o sensor e o seu fator de eficiência determina o tempo de vida da bateria. Dependendo da aplicação outros subsistemas podem existir, como por exemplo, o de localização (para determinar com precisão a posição de um nó) e o de movimento (para mover o nó para um local que permita a realização de uma tarefa). Além dos subsistemas citados acima, o projeto de um nó sensor pode incluir um sistema operacional rudimentar que gerencia a operação do nó sensor da forma mais eficiente possível. Um exemplo de sistema operacional desenvolvido especialmente para sensores, e utilizado em grande parte do hardware hoje existente, é o TinyOS. Outra plataforma com destaque é o Sun SPOT devido ao uso da linguagem Java ME. O estado de instalação da rede no ambiente diz respeito à localização dos nós sensores no espaço físico, à densidade da rede e a possíveis deslocamentos no caso de nós sensores móveis. De acordo com [RUIZ, 2003], as RSASFs 31

32 podem ser classificadas segundo a sua configuração conforme mostrado na Tabela 2-1. Composição Organização Mobilidade Densidade Distribuição Configuração Homogênea Rede composta de nós que apresentam a mesma capacidade de hardware. Eventualmente os nós podem executar software diferente. Heterogênea Rede composta por nós com diferentes capacidades de hardware. Hierárquica RSASF em que os nós estão organizados em grupos (clusters). Cada grupo terá um líder (cluster-head) que poderá ser eleito pelos nós comuns. Os grupos podem organizar hierarquias entre si. Plana Rede em que os nós não estão organizados em grupos. Estacionária Todos os nós sensores permanecem no local onde foram depositados durante todo o tempo de vida da rede. Móvel Rede em que os nós sensores podem ser deslocados do local onde inicialmente foram depositados. Balanceada Rede que apresenta uma concentração e distribuição de nós por unidade de área considerada ideal segundo a função objetivo da rede. Densa Rede que apresenta uma alta concentração de nós por unidade de área. Esparsa Rede que apresenta uma baixa concentração de nós por unidade de área. Irregular Rede que apresenta uma distribuição não uniforme dos nós na área monitorada. Regular Rede que apresenta uma distribuição uniforme de nós sobre a área monitorada. Tabela 2-1 Caracterização das RSASFs segundo a configuração. Com relação aos modelos de entrega de dados, as RSASFs podem ser classificadas como periódicas, contínuas, reativas ou dirigidas a eventos. Nas redes periódicas, os nós sensores coletam os dados em intervalos de tempos pré-determinados. Um exemplo são aplicações de monitoramento de temperatura. A temperatura não muda bruscamente a todo o momento. Portanto, estas aplicações não precisam executar constantemente nos nós 32

33 sensores. Quando a coleta de dados se dá de maneira contínua, os nós sensores devem coletar os dados continuamente. Um exemplo são as aplicações que monitoram pacientes cardíacos. Tais aplicações devem capturar os dados constantemente a fim de garantir a integridade física do paciente. Nas redes reativas, os nós sensores coletam os dados apenas quando o observador solicita-os. As aplicações militares que monitoram as forças presentes em um campo de batalha podem ser citadas como este tipo de rede. Neste tipo de aplicação o observador pode solicitar manualmente que ocorra uma atualização dos dados coletados. Já nas aplicações dirigidas a eventos, os nós sensores coletam os dados, apenas, caso algum evento de interesse do observador ocorra. Aplicações que monitoram queimadas podem exemplificar este tipo de sensoriamento. Nelas, o observador pode solicitar que ele seja informado caso a temperatura na região seja superior a um determinado valor. Por fim, é importante ressaltar que diversas formas de sensoriamento podem ser combinadas em uma única aplicação. Como exemplo é possível citar a mesma aplicação militar descrita anteriormente. Afinal, é notável que tal aplicação alcançará resultados melhores caso ela seja reativa e dirigida a eventos, evitando assim surpresas desagradáveis para as tropas no campo de batalha. Quanto a pilha de protocolos utilizada em uma RSASF (Figura 2-3), esta consiste em cinco camadas horizontais (aplicação, transporte, rede, enlace de dados e física) e três planos verticais (gerenciamento de energia, gerenciamento de tarefas e gerenciamento de mobilidade). A camada de aplicação refere-se aos protocolos de nível de aplicação que são de uso comum para as diferentes aplicações. Diferentes tipos de software de aplicação, dependendo da tarefa de sensoriamento, podem ser construídos e utilizados para interação com a RSASF. No entanto, alguns autores, como [AKYILDIZ, 2002], afirmam que os protocolos para a camada de aplicação ainda são poucos explorados. Dessa maneira, alguns autores sugerem três protocolos possíveis para apoio às aplicações: protocolo de gerenciamento de sensores 33

34 (SMP), o qual tem por finalidade tornar o hardware e o software das camadas mais baixas transparentes para as aplicações que gerenciam a rede de sensores; protocolo de anúncio de dados e designação de tarefas (TADAP), que visa fornecer à aplicação cliente da rede interfaces para conduzir a disseminação de seus interesses ou para receber anúncios de dados enviados pelos sensores; e protocolo de consulta e disseminação de dados (SQDDP), que fornece, para as aplicações, interfaces para a emissão de suas consultas e para a coleta das respostas que chegam da rede. Figura 2-3 Pilha de protocolos das RSSFs. A camada de transporte é responsável pela manutenção do fluxo de dados entre a origem e o destino, caso a aplicação necessite. Em geral, o fluxo da informação disseminada em uma RSASF pode ser classificado como: flooding (nós sensores fazem broadcast de suas informações para seus vizinhos que fazem broadcast desses dados para outros até que o ponto de acesso seja alcançado), unicast (nós sensores podem se comunicar diretamente com o ponto de acesso usando protocolos de roteamento multi-hop), ou multicast (nós sensores formam grupos e usam o multicast para comunicação entre os 34

35 membros do grupo). Uma grande vantagem da utilização do flooding ou do broadcast trata-se da ausência de um protocolo complexo da camada de rede para efetuar roteamento e gerenciamento de localização dos nós. O objetivo da camada de rede é tratar do roteamento dos dados. Exemplos de protocolos de roteamento: LQRP (Link Quality Routing Protocol), Tiny Beaconing, LEACH, PROC, entre outros. Já a camada de enlace tem como objetivo assegurar conexões confiáveis em uma rede de comunicação. A camada física abrange as técnicas de transmissão, recepção, e modulação utilizadas na rede. Como a comunicação entre os nós é responsável pela maior parte do consumo de energia em uma RSASF, a eficiência em termos de energia assume uma importância significativa durante o projeto da camada física. Os três planos de gerenciamento permitem a coordenação dos nós sensores quanto à realização das tarefas de sensoriamento e quanto ao consumo global de energia da rede. Eles são necessários para que os nós sensores possam trabalhar juntos de forma eficiente em termos de energia, roteamento de dados em redes com sensores móveis e compartilhamento de recursos entre si. O plano de gerenciamento de energia permite gerenciar a forma como a energia é gasta pelos nós sensores. Por exemplo, um nó sensor pode desligar seu receptor após receber uma mensagem de um de seus vizinhos, evitando a recepção de mensagens duplicadas. Um sensor com baixo nível de energia pode decidir não participar mais do roteamento de mensagens e reservar o restante de sua energia para o sensoriamento. Com esse intuito, o sensor deve avisar seus vizinhos de sua decisão, enviando-lhes essa informação em broadcast. Todas estas decisões são responsabilidades do plano de gerenciamento de energia. O plano de gerenciamento de tarefas permite balancear e escalonar as tarefas de sensoriamento de uma região específica. Não é necessário que todos os sensores localizados na região alvo definida pela aplicação estejam ativos ou contribuam ao mesmo tempo para a realização da tarefa. Como resultado, 35

36 alguns nós participam mais na realização da tarefa do que outros, dependendo do seu nível de energia ou do grau com que possam contribuir para a tarefa. Sem este plano de gerenciamento, cada nó sensor irá apenas trabalhar individualmente. Do ponto de vista de toda a rede, ela será mais eficiente somente se cada nó puder colaborar um com o outro. Desta forma a vida útil de uma rede de sensores e atuadores sem fio pode ser prolongada. Já o plano de gerenciamento de mobilidade permite detectar e registrar o movimento dos nós, de modo a manter sempre uma rota para o usuário e a guardar, para cada nó, a informação sobre quem são seus vizinhos. Com relação às aplicações é possível afirmar que diversas aplicações utilizando RSASF vêm sendo desenvolvidas. Estas aplicações podem ser homogêneas ou heterogêneas quanto aos tipos, dimensões e funcionalidades dos nós utilizados. Dessa maneira, o uso de RSASFs habilita uma ampla gama de aplicações potenciais, pertencentes aos mais variados ramos do conhecimento humano. A seguir algumas áreas, onde RSASF podem ser empregadas, são exemplificadas: Militar: Monitoramento de forças, equipamentos e munições amigas, vigilância do campo de batalha, reconhecimento de forças e terrenos inimigos, detecção e reconhecimento de ataques biológicos, químicos e nucleares, sistemas inteligentes de mira, dentre outros. Como RSASF são compostas por centenas a milhares de nós de baixo custo e descartáveis, a destruição destes por ações inimigas não prejudicará tanto a operação militar quanto a destruição de um sensor tradicional, de maior custo. Ambiental: Monitoração de variáveis ambientais em locais internos como prédios e residências, e locais externos como florestas, desertos, oceanos, vulcões, etc. Aplicações nesta área podem incluir o rastreamento do movimento de pássaros, o monitoramento em grande escala da Terra e a exploração planetária; o monitoramento biológico e ambiental das águas, solos e da atmosfera. 36

37 Medicina: Monitoramento de pacientes, realização de diagnósticos, administração de drogas em hospitais, o monitoramento de dados fisiológicos humanos, e o monitoramento de médicos e pacientes dentro de um hospital. Doméstica: Eletrodomésticos podem possuir nós sensores e atuadores inteligentes embutidos. Esses nós podem interagir entre si e com redes externas via Internet ou satélite, permitindo que usuários gerenciem dispositivos domésticos local ou remotamente de forma fácil e integrada. Além das áreas já citadas, RSASFs também são utilizadas em outros setores. No entanto, tais setores utilizam RSASF de forma mais genérica para segurança, monitoramento, controle, atuação e monitoramento de ambientes externos e internos. Dentre estes setores podemos citar: produção industrial, no monitoramento em indústrias petroquímicas, fábricas, refinarias e siderúrgicas de parâmetros como fluxo, pressão, temperatura e nível, identificando problemas como vazamento e aquecimento; áreas industriais, no monitoramento de dados em regiões de difícil acesso e manutenção; extração de petróleo e gás, nas plataformas em alto mar, onde o monitoramento da extração de petróleo e gás é bastante crítico; e na indústria de aviação, neste setor sensores sem fio são utilizados no lugar dos cabos responsáveis pela interconexão do sistema de controle da tecnologia fly-by-wire Modelos de comunicação e entrega de dados em RSASFs Comunicação de infraestrutura e comunicação da aplicação são os tipos de comunicação geralmente suportados por RSASF. A comunicação de infraestrutura é responsável pela troca de mensagens entre os nós a fim de configurar, manter ou otimizar a operação da rede. As trocas de mensagens para descobrir o caminho dos nós sensores e atuadores aos nós sorvedouros e as mensagens utilizadas para a formação de clusters e 37

38 para a eleição de novos líderes são consideradas comunicações de infraestrutura. A comunicação de aplicação responsabiliza-se pela transferência dos interesses da aplicação para a rede, a partir da qual a entrega de dados tem início, e pela transferência dos dados coletados sobre o fenômeno em estudo, desde sua origem até a aplicação destino. O interesse da aplicação deve ser especificado em relação ao fenômeno estudado, evitando que o usuário precise ter conhecimento quanto à infraestrutura e aos protocolos de comunicação subjacentes. Após a definição do interesse da aplicação, os dados começam a ser coletados e enviados pela rede. O tipo de tráfego da aplicação será determinado pelo modelo de entrega de dados (os modelos existentes são definidos na Seção 2.1.1). A maioria das aplicações de RSASF admite a perda de dados, assim um mecanismo elaborado para garantia de envio de dados não é justificado. Vários protocolos de roteamento utilizam técnicas com o intuito de diminuir a perda de dados, como o Difusão Direcionada, que repassa os dados através de vários caminhos. No entanto, durante as comunicações de infraestrutura a rede precisa de uma entrega confiável de dados, pois isto garantirá o gerenciamento correto de toda a rede. A partir desta necessidade, alguns protocolos foram criados, dentre estes podemos citar: PSFQ (Pump Slowly, Fetch Quickly), ESRT (Event-to-Sink Reliable Transfer) e RMST (Reliable Multi-Segment Transport) Qualidade de serviço (QoS) em RSASFs Há uma ampla variedade de definições possíveis para o conceito de QoS em redes de sensores e atuadores [FROLIK, 2004], [IYER, 2003], [PERILLO, 2003], [PERILLO, 2003]. Em [FROLIK, 2004] QoS em uma RSASF é definida em termos da resolução espacial da rede. Já [YU, 2004] considera a latência como um requisito crucial para várias aplicações. Enquanto outros autores argumentam 38

39 que, para alguns tipos de aplicações, o tempo de vida da rede é um requisito crítico. Com base nas afirmações acima é possível observar que o tipo de aplicação alvo influencia consideravelmente nos requisitos de QoS desejados. Nesse sentido, em [FROLIK, 2004] aplicações de RSASFs são classificadas em duas classes: dirigidas a desempenho e dirigidas a custo. As aplicações dirigidas a desempenho caracterizam-se pelas restrições de energia e largura de banda, além de demandar dados em tempo real, ou seja, a latência é um requisito de QoS crítico. Já as aplicações dirigidas a custo possuem requisitos de latência menos severos e uma maior restrição com relação à energia e os requisitos mais importantes são o tempo de vida e a acurácia dos dados Plataformas para RSASF Esta Seção descreve as duas plataformas de redes de sensores e atuadores sem fio que serão utilizadas ao longo deste trabalho: Sun SPOT e TinyOS. Além disso, apesar de não ser utilizada neste trabalho, a plataforma Arduíno é descrita para ilustrar ainda mais a diversidade de plataformas para RSASF existentes atualmente Sun SPOT Sun SPOT (Sun Small Programmable Object Technology) é a alcunha dada para um elemento de RSASF (um nó sensor, especificamente), desenvolvido pela Sun Microsystems. Sua plataforma de hardware inclui uma gama de sensores embutidos, bem como uma interface amigável para dispositivos externos. Trata-se de uma plataforma experimental que foi projetada de maneira a permitir que programadores que nunca tenham trabalhado com dispositivos embutidos possam pensar em programas com funcionalidades voltadas para RSASF. Ela se destaca das demais plataformas para redes de sensores por utilizar a linguagem Java, o que facilita bastante a programação e possibilita a 39

40 utilização de ferramentas de desenvolvimento padrão (IDEs) como o NetBeans. Por utilizar a máquina virtual (VM) Squawk, que permite que as aplicações sejam executadas on the bare metal (direto no hardware, o que diminui o overhead e melhora o desempenho), os nós sensores não necessitam de um sistema operacional. Sua plataforma de hardware inclui uma gama de sensores embutidos, bem como uma interface amigável para dispositivos externos. Os dispositivos de sensoriamento Sun SPOT são constituídos por uma placa de processador, uma placa de sensor e uma bateria, sendo embalados em uma caixa de plástico (Figura 2-4). A menor estação base possui apenas a placa de processador em uma caixa de plástico. Figura 2-4 Hardware constituinte do dispositivo Sun SPOT. A placa do sensor é composta por: Um acelerômetro de 3 eixos (com duas possíveis escalas: 2G ou 6G); Um sensor de temperatura; Um sensor de luz; 8 leds compostos por três cores cada um; 6 entradas analógicas legíveis por um ADC; 2 interruptores momentâneos; 40

41 5 pinos de I/O de propósito geral; 4 pinos de saída de corrente alta. Cada Sun SPOT possui um processador ARM970T 32-bit 180Mhz com 512K RAM e 4M Flash. A placa de processador utiliza um rádio de 2.4GHz com uma antena integrada na placa. O rádio é um TI CC2420 (anteriormente ChipCon) e é compatível com IEEE Cada placa de processador tem uma interface USB (utilizada para se conectar ao PC). Existem dois leds, um vermelho e um verde. E por fim há um micro controlador Atmel Atmega88 de 8 bits utilizado como controlador de potência. Todo dispositivo Sun SPOT possui uma bateria recarregável de íon lítio de 3.7V e 750 mah que é recarregada sempre que o dispositivo é conectado a um PC ou a um hub USB. A estação base Sun SPOT não possui bateria o que faz com que sua energia fique diretamente ligada a uma conexão USB com o PC host. Se a bateria for ativada tanto pela CPU quanto pelo rádio ela poderá suportar até 7 horas de operações. Podendo ser prorrogado caso o processador entre no modo sleep e caso o rádio seja desligado quando não estiver em uso. No modo sleep a bateria irá durar mais de 900 dias. Caso todos os 8 leds sensores da placa estejam ativos a bateria irá durar por cerca de 3 horas. A estação base, a qual se diferencia dos demais dispositivos por não possuir bateria nem placa de sensores, nas plataformas Sun SPOT se conecta a sua respectiva máquina de desenvolvimento (um PC) e permite a escrita de programas que podem ser executados no próprio PC que utiliza o rádio da estação base para se comunicar com dispositivos Sun SPOTs remotos. As ferramentas de desenvolvimento também fazem uso da estação base para implantar e depurar aplicações em Sun SPOTs remotos. Observa-se que qualquer dispositivo Sun SPOT pode ser utilizado como estação base. No entanto, este dispositivo não poderá utilizar os sensores disponíveis em sua placa. 41

42 Os sensores Sun SPOT utilizam a implementação Java ME que suporta a CLDC 1.1 (Connected Limited Device Configuration) [CLDC, 2012], especificação para utilização da plataforma Java ME em dispositivos com recursos muito limitados, e MIDP 1.0 (Mobile Information Device Profile) [MIDP, 2012], especificação para utilização da plataforma Java em dispositivos móveis. Além disso, os sensores também oferecem as funcionalidades básicas de um sistema operacional. As plataformas que suportam a utilização do Sun SPOT são atualmente: Windows Seven, Macintosh X 10.4 rodando tanto baseado no Power PC quanto na Intel, Linux (Fedora Core 5, SuSE 10.1 e Ubuntu 9.10) e Solaris x86. O Sun SPOT ainda fornece um simulador que é capaz de rodar uma aplicação Sun SPOT em um computador desktop. Isso permite testar um programa antes de sua implantação em um SPOT real, ou caso não exista um SPOT real disponível. Se uma estação base partilhada estiver disponível, um SPOT virtual (dispositivo Sun SPOT simulado) também pode interagir através do rádio com SPOTs reais TinyOS TinyOS é um sistema operacional open source projetado para redes de sensores e atuadores sem fio que foi desenvolvido originalmente como um projeto de pesquisa na Universidade da Califórnia em Berkley, USA. Atualmente existe uma comunidade internacional de usuários e desenvolvedores. O TinyOS possui uma arquitetura baseada em componentes que torna possível a rápida implementação enquanto diminui o código fonte gerado, devido à existência de vários componentes já programados, o que é um importante requisito considerando as severas restrições de memória de um nó. A biblioteca de componentes do TinyOS inclui protocolos de rede, serviços distribuídos, drivers de diferentes sensores e ferramentas de aquisição de dados - todas podem ser usadas de modo completo ou refinadas para uma aplicação personalizada. Além disso, possui um modelo de programação adaptado para aplicações 42

43 orientadas a eventos. Como prova do seu sucesso, o TinyOS já foi portado para várias plataformas de hardware de nós sensores (ex. família mica, família telos, etc.) [TinyOS, 2012]. Um dos representantes da família MICA é o mote (outra denominação de nó) conhecido como MICAz (Figura 2-5). Ele é equipado com um processador Atmel128L com uma capacidade máxima de processamento de oito milhões de instruções por segundo quando operando a 8MHz. Ele também possui um transceptor RF que opera com o IEEE /Zigbee [IEEE TG4, 2012] trabalhando a uma frequência de 2,4-2,4835 GHz. O MICAz funciona com TinyOS (v1.1.7 ou posterior) e é compatível com diversas placas de sensoriamento disponíveis [MARTINCIC, 2005]. Figura 2-5 MICAz Mote. NesC (network embedded systems C) é uma extensão da linguagem de programação C utilizada na implementação de aplicações para TinyOS tendo sido projetada para incorporar os princípios de estruturação e os modelos de execução do TinyOS. As aplicações desenvolvidas são muito dependentes do hardware e os nós rodam apenas um único fluxo por vez, ou seja, não há suporte a programação multi-thread. O TinyOS possui algumas características importantes que influenciaram o design do nesc: uma arquitetura baseada em componentes, um modelo de concorrência simples baseado em eventos e operações divididas em fases (split-phase) para lidar com a característica de tarefas não preemptivas do TinyOS [GRAY, 2003]. 43

44 Arquitetura baseada em componentes: TinyOS provê um conjunto de componentes reutilizáveis. Uma aplicação conecta componentes usando a especificação de ligações (wirings) que é totalmente independente da implementação dos componentes. Assim, cada aplicação customiza o conjunto de componentes que usa. Tarefas e concorrência baseada em eventos: Existem duas fontes de concorrência no TinyOS: tarefas (tasks) e eventos (events). Tarefas são mecanismos de computação. Elas são executadas até sua conclusão e não possuem preempção entre si. Eventos também são executados até a conclusão, mas podem causar preempção na execução de tarefas ou outros eventos. Eventos podem ser tanto a conclusão de uma operação dividida em fases (splitphase operation) ou um evento do ambiente onde o nó está instalado. A execução do TinyOS é totalmente dirigida a eventos representando interrupções de hardware. Operações divididas em fases (split-phase operations): Como tarefas são executadas não preemptivamente o TinyOS não possui operações bloqueantes. Todas as operações que podem ter uma execução demorada são divididas em fases: a requisição da operação e sua conclusão são funções distintas. Um exemplo típico de uma operação dividida em fases é o envio de um pacote: um componente pode chamar o comando send para iniciar a transmissão de rádio da mensagem; e o componente de comunicação sinaliza senddone quando a transmissão estiver completa. A Tabela 2-2 mostra a comparação entre código bloqueante e um código de fases divididas [TinyOS, 2012]. Código Bloqueante 1 if (send() == SUCCESS) { 2 sendcount++; 3 } Código Dividido em Fases 1 // start phase 2 send(); 3 //completion phase 4 void senddone(error_t err) { 5 if (err == SUCCESS) { 6 sendcount++; 7 } 44

45 8 } Tabela 2-2 Comparação de código bloqueante e dividido em fases Arduíno O conceito Arduíno surgiu na Itália em 2005 com o objetivo de criar um dispositivo para controlar projetos/protótipos construídos de uma forma menos dispendiosa que outros sistemas disponíveis no mercado [Projeto Arduíno, 2012]. Trata-se de um projeto open-source e sua plataforma de hardware é composta apenas por um microcontrolador Atmel AVR (Figura 2-6), a qual deve ser customizada de acordo com as necessidades dos desenvolvedores (inserção de sensores, atuadores, entre outros). Figura 2-6 Diversas versões de Arduíno A customização das placas pode ser feita através de shields (Figura 2-7) que nada mais é do que extensões que permitem a interação do Arduíno com diversas tecnologias (Xbee, Ethernet, por exemplo). 45

46 Figura 2-7 Xbee shield. O desenvolvimento de aplicações para esta plataforma deve ser efetuado através da IDE Arduíno [Projeto Arduíno, 2012], a qual é escrita em Java e deriva dos projetos Wiring [Wiring, 2012] e Processing [Processing, 2012]. Ela é fácil de instalar e usar para novatos, e suficientemente flexível para usuários avançados. A IDE apresenta um editor de código incrementando com sintaxe high-light e outras opções para tratar do envio de programas do computador para o nó. A linguagem usada é baseada em C e algumas construções de C++, e inclui também uma biblioteca própria, além das funções de uma parte da biblioteca padrão C. Além da biblioteca original, há muitas outras disponíveis na comunidade, desenvolvidas por usuários colaboradores, que facilitam diversas outras tarefas. O software Arduíno roda em Windows, Macintosh OSX e sistemas operacionais Linux. O Arduíno é capaz de monitorar o ambiente através de uma variedade de sensores e pode atuar nele através do controle de luzes, motores ou outros atuadores. Além disso, os projetos Arduíno podem ser stand-alone ou conectados a um computador através de Adobe Flash, Max/MSP, entre outros. Quanto a questões relativas a pesquisas científicas é possível observar trabalhos relacionados com o desenvolvimento de software para ambientes inteligentes. O destaque neste aspecto se dá ao preço do Arduíno que, se 46

47 comparado ao preço de outras plataformas torna-se relativamente mais acessível. Um fator importante e que auxilia bastante durante o desenvolvimento de aplicações utilizado a plataforma Arduíno trata-se da documentação disponibilizada no site do projeto. Também há um fórum onde usuários da comunidade participam ativamente fornecendo informações e tirando dúvidas. Apesar das vantagens listadas acima, ao contrário das outras plataformas utilizadas na área de RSASF, é necessário possuir algum conhecimento de eletrônica básica para que seja possível avançar no uso da plataforma Arduíno, dificultando ainda mais a participação do especialista de domínio no desenvolvimento de sistemas para RSASF. Além disso, devido às características de programação com diferentes componentes eletrônicos, não existe atualmente um ambiente oficial para simulação de aplicações com Arduíno, uma desvantagem bastante crítica quando se trata de grandes ambientes como numa RSASF. Existem alguns simuladores desenvolvidos por terceiros que realizam apenas operações básicas e aplicações simples como as dos tutoriais Linguagem Específica de Domínio Segundo [CZARNECKI, 2005] uma DSL é uma linguagem que oferece um poder de expressividade focado em um domínio particular de problema, tal como uma classe específica de aplicações ou aspectos de aplicações. Um domínio é uma área de interesse restrita, um ponto de vista concreto ou uma família de produtos relacionados, caracterizada por um conjunto de terminologias e conceitos. A abstração é a característica principal de uma DSL, pois permite uma compactação de conceitos e uma redução à essência do problema, contrariamente a outras linguagens como Java, C, entre outras. DSLs existem há um longo tempo. [MERNIK, 2005] cita exemplos da linguagem APT para controle numérico, que data de , e da mais famosa BNF, ou Backus-Naur Form, linguagem para especificação de gramáticas criada 47

48 em Desde então diversas linguagens vêm sendo desenvolvidas e utilizadas, e a literatura nesta área é bastante rica ([DEURSEN, 2000] e [MERNIK, 2005]). As DSLs fazem parte das linguagens de programação de quarta geração (4GL) 1. Uma linguagem específica de domínio pode ser textual (permitindo a especificação de programas através de códigos fonte) ou visual (permitindo a especificação de modelos ou diagramas), e normalmente possui três elementos: a sintaxe abstrata, a sintaxe concreta e a sintaxe de serialização. A sintaxe abstrata define os conceitos do domínio e as relações e restrições que se aplicam a estes conceitos. Em linguagens textuais, ela é representada por uma árvore (Abstract Syntax Tree ou AST) que armazena as palavras do vocabulário da linguagem e seu agrupamento válido em forma de sentenças. Em linguagens visuais, a sintaxe abstrata corresponde ao metamodelo que define a estrutura dos modelos que podem ser criados [GUIZZARDI, 2002]. Uma vez que os modelos são uma especificação de uma conceitualização do domínio, podendo ser considerado uma ontologia [KURTEV, 2006]. A sintaxe concreta provê o sistema para representar os conceitos do domínio de forma concreta. Consiste de símbolos, que podem ser caracteres organizados em palavras segundo uma gramática bem definida (linguagem textual), ou ícones gráficos com características visuais que representam diferentes atributos, como: cor, posição, tamanho e forma (linguagem visual) [GUIZZARDI, 2002]. Trata-se de uma representação superficial, que pode ser diferente da representação interna que é obtida com a sintaxe abstrata. De fato, uma DSL pode possuir múltiplas sintaxes concretas ([KLEPPE, 2007]). A sintaxe de serialização ([GRONBACK, 2009]) permite persistir os modelos de forma que estes possam ser interpretados, processados e intercambiados 1 Linguagens de programação de alto nível com objetivos específicos. Este tipo de linguagem descreve o que deve ser feito em oposição a como deve ser feito, característico das 3GL (Linguagem desenhada com o propósito de ser compreendida por humanos. Exemplos deste tipo de linguagens são o ALGOL, C ou Java). 48

49 entre diferentes ferramentas de modelagem. Por exemplo, o XML Metadata Interchange (XMI) é um padrão do OMG utilizado tanto na MDA quanto no EMF para representar modelos em formato XML. A definição da linguagem normalmente requer a construção de um metamodelo que seja capaz de capturar os pontos comuns e variáveis do domínio. Ele é usado para se referir a um tipo de metadado. Trata-se de uma definição das regras e das construções necessárias à criação de modelos sintáticos, utilizados também para compreender e analisar sistemas. Assim sendo, o metamodelo é fundamental para impelir, induzir, guiar e restringir o comportamento da DSL [BÉZIVIN, 2005] Vantagens e Desvantagens de DSLs DSLs permitem que soluções possam ser expressas na linguagem e ao nível de abstração do especialista de domínio. Deste modo, estes especialistas conseguem compreender, validar, ou até mesmo desenvolver DSLs. Elas permitem assim a validação e a otimização ao nível do domínio. As alterações em nível de requisitos também são rapidamente realizadas pelo especialista, pois basta efetuar a alteração da parte do modelo afetada pela mudança ([DEURSEN, 2000]). Devido à elevada facilidade de uso e à programação considerada simples e reduzida, as DSLs aumentam a produtividade, confiança, manutenção e portabilidade. Tornam-se também facilmente utilizáveis por alguém que não seja necessariamente um programador (end-users). Deste modo, aumentam a capacidade de teste seguindo determinadas abordagens [DEURSEN, 2000]. Apesar de ser uma linguagem que possui todas as vantagens apontadas anteriormente, existem também algumas desvantagens no seu uso e desenvolvimento. Uma das áreas mais afetadas é a área financeira. Os custos associados ao desenvolvimento de uma DSL são geralmente elevados, pois o desenho, a 49

50 implementação, a manutenção e o treinamento dos utilizadores das DSLs geralmente ultrapassam os custos inicialmente previstos. Daí que apenas 16% dos trabalhos planeados consigam chegar ao fim, cumprindo o calendário proposto e com o orçamento previsto, 31% dos projetos são cancelados e 53% possuem custos maiores que os planeados ([DEURSEN, 2000]). A reduzida informação disponível acerca de como e quando desenvolver uma DSL é também uma desvantagem deste tipo de linguagem. Além disso, a interoperabilidade com outras linguagens já estabelecidas é dificultada, uma vez que DSLs não são padronizadas Ferramentas de Modelagem Para implementar LWiSSy, foi usado o ambiente Eclipse Helios [Eclipse Helios, 2012] com o framework EMF/GMF ([EMF, 2012], [GMF, 2012]). Estas ferramentas serão descritas ao longo desta Seção. A IDE Eclipse é uma plataforma de modelagem que suporta a metamodelagem e, além disso, é altamente flexível e open source. O Eclipse Modeling Framework (EMF) pode gerar código fonte a partir de metamodelos definidos com base nos diagramas UML, ou seja, metamodelos que são instâncias dos diagramas UML, mas estes não contém a definição da sintaxe concreta. O Graphical Editing Framework (GEF), framework do Eclipse, oferece métodos para criar editores de modelos visuais. O EMF não suporta geração de código para o GEF, dessa forma os metamodelos precisam de codificação manual para suportar a sintaxe concreta. O Graphical Modeling Framework (GMF), framework do Eclipse, tem como objetivo efetuar uma ligação generativa entre o EMF e o GEF, para que a definição do diagrama seja ligada ao modelo do domínio como um input para a geração de um editor visual. O GMF usa uma DSL de apresentação para definir a sintaxe concreta. O resultado (as definições de ligações concretas e estruturais) é processado essencialmente para produzir código fonte. O 50

51 mapeamento entre o modelo do domínio e os itens do modelo da sintaxe concreta também são suportados no GMF. O código fonte gerado depende das características do GEF e EMF. Embora o conceito do GMF seja simples, ele possui alguns pontos fracos: A geração não é baseada na transformação do modelo. Consequentemente, os passos da compilação são codificados manualmente, assim, mudar a transformação implica mudar o código fonte e reconstruir o compilador. No caso de transformação de modelos tais transformações podem ser realizadas em tempo de execução; Devido ao EMF, o GMF é restrito apenas para Java Desenvolvimento Dirigido a Modelos O desenvolvimento dirigido a modelos (MDD) é uma abordagem que utiliza modelos para guiar todo o ciclo de desenvolvimento de sistemas. Em 2001, o padrão MDA foi apresentado pela OMG (Object Management Group) a fim de atender às necessidades do paradigma de desenvolvimento dirigido a modelos. Segundo [MILLER, 2003], um modelo de um sistema é a descrição ou especificação do sistema e de seu ambiente. Nesse padrão, os modelos são considerados artefatos principais que serão utilizados ao longo de todo o ciclo de desenvolvimento do sistema. Dessa maneira, o modelo deixou de ser encarado apenas como um documento auxiliar e passou a ser visto como parte real do sistema. Com essa mudança surgiu à necessidade de consistência entre todas as fases de desenvolvimento do sistema e o modelo, visto que o modelo é responsável pela orientação de todo o processo de desenvolvimento. Durante tal processo são criados diversos modelos, no entanto cada um utiliza os elementos relevantes a um determinado ponto de vista, como por exemplo, um modelo contendo apenas elementos relacionados ao domínio do problema. 51

52 Modelos A MDA apresenta uma nomenclatura uniforme para classificar os diversos tipos de modelos construídos ao longo do ciclo de desenvolvimento do sistema (Figura 2-8 [MILLER, 2003]). O primeiro modelo definido pelo MDA é o CIM (Computation Independent Model). Trata-se do documento de requisitos do sistema, o qual é produzido durante a fase de análise. O referido modelo, dentre os modelos definidos, possui o nível mais elevado de abstração e é independente de qualquer visão computacional. Figura 2-8 Artefatos envolvidos na abordagem MDA O próximo modelo a ser definido é o PIM (Platform Independent Model). Modelo este que é considerado o artefato central do processo de desenvolvimento do sistema. Diferentemente do CIM, o PIM possui uma visão computacional, no entanto ele é independente de tecnologia de implementação, ou seja, este modelo não leva em consideração detalhes específicos de uma determinada plataforma. A modelagem do PIM utilizará uma Linguagem 52

53 Específica de Domínio (DSL) para que os especialistas do domínio possam modelar suas aplicações sem que seja necessário o conhecimento específico em programação de baixo nível. O PSM (Platform Specific Model) é definido logo após a definição do PIM. Tal modelo, gerado na fase de projeto do sistema, contém detalhes específicos e relevantes para o tipo de plataforma utilizada pelo sistema. Mais de um PSM pode ser gerado a partir do mesmo PIM, de acordo com as tecnologias disponíveis. Isso é muito útil, uma vez que grande parte dos sistemas atuais utiliza mais de uma tecnologia. Por fim, durante a fase de implementação, a geração de código é efetuada. O código é gerado com base no PSM, onde a plataforma utilizada deve ser definida Transformações Com os modelos definidos é necessário efetuar a conversão de um modelo para outro. Tais conversões são efetuadas por meio de transformações. Segundo [KLEPPE, 2003] (p. 24) Uma transformação é a geração automática de um modelo alvo a partir de um modelo fonte, de acordo com uma definição de transformação. Uma definição de transformação é um conjunto de regras de transformação que, juntas, descrevem como um modelo em uma linguagem fonte pode ser transformado em um modelo em uma linguagem alvo. Uma regra de transformação é a descrição de como um ou mais construções na linguagem fonte podem ser transformadas em um ou mais construções na linguagem alvo. No entanto, o padrão MDA não especifica técnicas robustas de transformações entre modelos, nem recomenda qualquer regra de transformação de modelos genérica ou pré-definida. Em MDA as seguintes transformações (Figura 2-9) podem ser efetuadas: 53

54 Figura 2-9 Os três passos principais no processo MDA. PIM para PIM: O nível de detalhamento da especificação do sistema pode ser aumentado, gerando assim um PIM mais específico, ou seja, conterá mais informações importantes no processo de transformação. Está transformação é chamada de Model to Model (M2M). PIM para PSM: Para que o PIM possa ser transformado em PSM ele deve inicialmente ser combinado com um metamodelo PDM (Platform Definition Model), metamodelo composto por elementos que descrevem a plataforma (Figura 2-10). Com a combinação entre o PIM e o PDM é possível gerar um modelo que leva em conta características específicas da plataforma. Durante a transformação de PIM para PSM é possível gerar vários modelos, cada um compondo uma parte do sistema, isso reduz o acoplamento e aumenta a coesão. Está transformação é chamada de Model to Model (M2M). Figura 2-10 Transformação PIM para PSM. PSM para código fonte: Por meio do PSM já há a possibilidade de geração de código fonte. Durante essa transformação detalhes da arquitetura, das 54

55 regras de negócio e especificações sobre o comportamento do sistema devem ser levados em consideração. Está transformação é chamada de Model to Text (M2T). Metamodelos precisam ser definidos para que o processo de transformação entre modelos aconteça de maneira automática. 55

56 3. Trabalhos Relacionados Apesar de ser uma área emergente, já existem diversos trabalhos acerca da utilização de DSLs para o desenvolvimento de aplicações para RSASF [AKBAL- DELIBAS, 2009], [LOSILLA, 2007], [SHIMIZU, 2011], [BOONMA, 2011]. No entanto, nos trabalhos reportados atualmente na literatura, ou os autores propõem a utilização de apenas um modelo gráfico ([AKBAL-DELIBAS, 2009], [LOSILLA, 2007]), razão esta que acaba dificultando a modelagem dos sistemas, ou, mesmo desenvolvendo mais de uma DSL, não propõem a divisão entre modelos estruturais e comportamentais ([SHIMIZU, 2011]), não havendo uma separação clara entre estes dois aspectos. Com isso, as linguagens propostas acabam tornando-se ou extensas demais (e, portanto muito genéricas), a fim de englobar todas as características possíveis, tanto da rede, quanto dos sistemas, dessa forma, dificultando a programação dos sistemas tanto quanto se fosse utilizada uma linguagem de programação, ou simplistas demais, mantendo fixas algumas características importantes para os sistemas, e, portanto especializando-se em demasia ao ponto de não contemplarem características básicas da área de RSASF e, assim, inviabilizando a programação eficiente dos sistemas. Estabelecer um equilíbrio entre a generalidade e a especificidade é um desafio ao se projetar uma DSL. Neste trabalho buscamos encontrar uma solução de compromisso nesse sentido. Buscamos também oferecer uma solução que promova uma clara separação de interesses entre os especialistas envolvidos no desenvolvimento de sistemas para RSASF, visto que tal separação promove uma melhora na modularidade dos sistemas e, por sua vez, ocasiona a diminuição dos custos tanto de tempo quanto de capital envolvidos durante a fase de desenvolvimento. Em [AKBAL-DELIBAS, 2009], é apresentado o framework Baobab. Trata-se de um framework MDD para o desenvolvimento de sistemas para RSSF. Na 56

57 proposta do Baobab é descrito um metamodelo que inclui os componentes e comportamentos mais comuns da área de RSSF. Além disso, a DSL que compõe o framework pode ser estendida pelos próprios desenvolvedores para englobar novos domínios de aplicações e plataformas para RSSF. O metamodelo engloba ainda a modelagem de requisitos não-funcionais, como a formação de clusters na rede, e funcionais. Adicionalmente, a DSL suporta a inclusão de restrições OCL (Object Constraint Language), característica esta que garante que todos os modelos gerados pela DSL serão válidos. Por se tratar de um framework MDD, também é possível gerar o código fonte das aplicações modeladas. A DSL descrita em [AKBAL-DELIBAS, 2009] difere da linguagem LWiSSy pelo fato de agregar muitas informações de baixo nível de abstração em seu metamodelo (definição de algoritmos de cluster, gerenciamento do ciclo de trabalho considerando informações de cluster, dentre outros), o que dificulta a modelagem de sistemas pelo especialista de domínio. Adicionalmente, o metamodelo deve ser especificado por meio de apenas um modelo gráfico, o que causa uma dependência entre os especialistas de domínio e de redes, os quais terão que efetuar a modelagem em conjunto. Além disso, o fato do metamodelo proposto ser muito extenso e ainda existir a possibilidade de extensão do mesmo pelos próprios desenvolvedores, a modelagem dos sistemas de RSSF pode se tornar tão complexa quanto à programação em baixo nível. Moppet, um framework de desenvolvimento dirigido a modelos para RSSF, é proposto em [BOONMA, 2011] com o objetivo de auxiliar na construção de aplicações para RSSF, bem como estimar a performance destas. O framework é capaz de prever o consumo de energia e o ciclo de vida dos nós da rede sem que para isto seja necessário efetuar a geração de código-fonte. Além disso, é possível gerar o código-fonte das aplicações na linguagem nesc e, portanto, implantá-lo em nós que suportam a plataforma TinyOS. Assim como a DSL proposta em [AKBAL-DELIBAS, 2009], a DSL definida no framework Moppet engloba algumas características com baixo nível de abstração (protocolos de roteamento e hardware dos nós utilizados) e, dessa maneira, o desenvolvimento 57

58 de aplicações com esta DSL, em geral, tem que considerar o trabalho em conjunto dos especialistas envolvidos no desenvolvimento (especialistas de domínio e de redes). Adicionalmente, até mesmo para o especialista de redes, esta DSL não é de fácil usabilidade, uma vez que alguns conceitos de RSSF que são utilizados por toda aplicação da área não são facilmente modelados, como por exemplo, a comunicação entre os nós, a qual não é considerada. Em [LOSILLA, 2007] é apresentada uma abordagem MDE para o desenvolvimento de sistemas de RSSF. Nesta abordagem é proposta uma linguagem que tem como objetivo ajudar especialistas de domínio a incluir toda a informação necessária ao sistema por meio de modelos. Este trabalho também efetua a geração automática do código fonte do sistema para RSSF. Apesar de LWiSSy ter sido desenvolvida com base no metamodelo proposto em [LOSILLA, 2007], eles diferem em alguns aspectos. Em [LOSILLA, 2007] apenas um modelo gráfico é gerado, o que acaba dificultando a separação de interesses (especialistas de domínio e de redes) e de características estruturais e comportamentais durante a modelagem dos sistemas. Além disso, o metamodelo possui um alto nível de abstração e, por sua vez, não abrange características importantes da área de RSASF, como: suporte a agregação de dados, definição da topologia da rede, inserção de componentes de decisão durante a modelagem comportamental do sistema, dentre outras. O trabalho descrito em [SHIMIZU, 2011] propõe a divisão do processo de desenvolvimento de sistemas para RSASF em três modelos distintos. Tal divisão foi proposta porque, segundo o autor, a programação de sistemas para RSASF pode ser efetuada considerando três enfoques diferentes, os quais possuem características distintas. Além disso, ainda é possível solucionar o tradeoff existente entre o custo de prototipagem e a capacidade de otimização de desempenho das aplicações presentes no sistema. Os enfoques observados, ou níveis de granulosidade, são os seguintes: nível de rede, nível de grupos de nós sensores e nível de nó. Os modelos do nível de 58

59 rede devem focar em abstrações da rede e descrever o processamento de dados considerando a rede como um todo. Neste modelo é possível definir os pontos de agregação, de fusão e os nós sink da rede. Já os modelos de nível de grupos de nós dependem do modelo de nível de rede e descrevem características relacionadas à comunicação e tratam um grupo de nós como uma entidade única. Por fim, o modelo de nível de nó também depende do modelo de nível de rede e descreve o comportamento de cada um dos nós considerando características de hardware. Ainda em [SHIMIZU, 2011], a construção da aplicação é dividida em duas fases: prototipagem e otimização. Na fase de prototipagem o desenvolvedor determina apenas o modelo de nível de rede, enquanto que os modelos de nível de grupos de nós e de nível de nó são gerados automaticamente a partir do modelo de rede (apesar do modelo em nível de nó depender diretamente apenas do modelo de rede, a geração deste modelo ocorre somente após a geração automática do modelo de grupos de nós) e por fim um modelo executável é gerados automaticamente com base nos modelos anteriores. Na fase de otimização, que pode ser vista como um ciclo, o desenvolvedor executa o modelo executável gerado, monitora seu desempenho, refina o modelo (rede, grupo ou nó), que julgar necessário, a fim de otimizá-lo e efetua a geração automática dos demais modelos (da mesma maneira que ocorre durante a fase de prototipagem) para gerar um modelo executável e reiniciar a fase de otimização. Nota-se que no trabalho de Shimizu ([SHIMIZU, 2011]) os modelos, diferentemente dos modelos utilizados em LWiSSy, podem ser vistos como programas, uma vez que tratam-se de modelos executáveis, representados por diagramas de classe UML. Apesar de propor a construção de várias DSLs, o trabalho descrito em [SHIMIZU, 2011] limita-se a modelagem de aspectos estáticos de sistemas de sensoriamento, não contemplando a parte comportamental do sistema, 59

60 característica esta que é crucial para a modelagem das aplicações de RSASF que compõem o sistema. Além disso, o trabalho não efetua consideração sobre a participação de desenvolvedores com diferentes conhecimentos e habilidades, ou seja, o especialista de domínio e o especialista de rede. Dessa forma, estes especialistas continuam dependentes entre si durante a modelagem do sistema. Adicionalmente, os metamodelos propostos não tratam algumas características de baixo nível que são primordiais durante a modelagem das aplicações. Alguns exemplos disto são a ausência de protocolos de comunicação, protocolos de controle de topologia da rede e de dispositivos presentes na rede (atuadores, portas que efetuam a comunicação entre os nós sink e as estações base). Além das diferenças já citadas acima com relação aos metamodelos propostos em [AKBAL-DELIBAS, 2009], [BOONMA, 2011] e [LOSILLA, 2007], ao contrário destes, LWiSSy efetua a divisão, através do uso de modelos gráficos distintos, da modelagem de sistemas de RSASF em três níveis, os quais serão descritos na Seção 4.2. A utilização de apenas um metamodelo nas DSLs anteriores dificultava a modelagem das aplicações e não possibilitava o suporte ao tratamento do tradeoff entre o custo de prototipagem e a capacidade de otimização de desempenho (refinamento). Outro fator que merece destaque é o tratamento da rede considerando diferentes níveis de granulosidade, assim como ocorre em [SHIMIZU, 2011], uma vez que RSASF podem ser analisadas tanto considerando o nível da rede como um todo, ou os grupos de nós específicos que compõem a rede e, até mesmo, considerando individualmente cada um dos nós que integram a rede e que podem ter características distintas seja em relação a plataforma utilizada, quanto com relação ao processamento dos dados. LWiSSy permite ainda que os especialistas de domínio e de redes modelem seus respectivos modelos de maneira independente, restringindo assim o trabalho em grupo destes especialistas ao nível de análise dos requisitos, característica esta que diminui a dependência entre os diferentes perfis de desenvolvedor envolvidos no desenvolvimento de sistemas para RSASF. Tal 60

61 dependência poderia causar atrasos durante o ciclo de desenvolvimento dos sistemas. Além disso, LWiSSy incorpora ainda um modelo comportamental, no qual é possível definir todo o fluxo de cada uma das aplicações inseridas nos nós sensores. Outra característica importante consiste na inserção de protocolos para RSASF, os quais não existiam nas DSLs anteriores e, por sua vez, as soluções geradas (código fonte) sempre exigiam uma atividade de refinamento de código muito extensa, uma vez que todo sistema de RSASF considera diversos protocolos durante o seu desenvolvimento. Uma característica importante e que não é tratada em nenhum dos trabalhos relacionados consiste na capacidade de modelagem de diversas aplicações em um mesmo sistema. Esta capacidade, a qual só está presente em LWiSSy, torna-a adequada para os cenários emergentes de redes de sensores e atuadores compartilhadas. Além disso, nenhum dos trabalhos relacionados efetuou algum tipo de avaliação qualitativa dos metamodelos gerados, sendo esta uma característica importante para garantir que o metamodelo proposto pode, de fato, ser utilizado durante o processo de desenvolvimento de sistemas para RSASF. Para concluir este Capítulo, a Tabela 3-1 apresenta uma comparação sumarizada entre as características presentes em todos os trabalhos que foram discutidos e LWiSSy. LWiSSy Baobab Moppet Losilla Shimizu Separação de interesses Suporte a modelagem estrutural e comportamental Definição de vários modelos gráficos Divisão de características estruturais e comportamentais em modelos diferentes Suporte a parâmetros de refinamento Suporte a modelagem de

62 Redes de Sensores Compartilhadas Validação de modelos com OCL - - Modelos executáveis Geração automática de código-fonte Previsão do tempo de vida e performance do sistema Tabela 3-1 Sumarização das características das DSLs discutidas neste Capítulo e LWiSSy. 62

63 4. Modelagem de Sistemas para RSASF Utilizando LWiSSy Este Capítulo inicialmente (Seção 4.1) descreve a DSL que deu origem ao desenvolvimento de LWiSSy. Logo após (Seção 4.2), a linguagem LWiSSy, cujo objetivo é facilitar a modelagem de aplicações para RSASF, com relação às características já descritas é apresentada. Na Seção 4.3, a infraestrutura MDA utilizada para apoiar o processo de desenvolvimento MDA empregado neste trabalho é descrita. Por último, na Seção 4.4, são apresentados/exemplificados os passos para o desenvolvimento de um sistema de RSASF com a utilização da linguagem proposta DSL para RSASF: Primeira versão Em [LOSILLA, 2007] foi proposta uma linguagem que tinha como objetivo ajudar os especialistas de domínio a incluir toda a informação necessária para o desenvolvimento de uma aplicação para RSSF por meio de modelos. Tal DSL, proposta por Losilla ([LOSILLA, 2007]), foi o ponto de partida da linguagem proposta neste trabalho, LWiSSy. No entanto, antes da especificação de LWiSSy, uma DSL intermediária foi proposta ([RODRIGUES, 2011]), a qual será detalhada nesta Seção. Tal DSL foi o ponto de partida para a confirmação das vantagens desse tipo de abordagem no desenvolvimento de aplicações de RSSF e também para a identificação de limitações que motivaram o projeto de LWiSSy. Para desenvolver a DSL intermediária foi realizada uma extensa revisão da literatura sobre DSLs para RSSFs ([LOSILLA, 2007], [AKBAL-DELIBAS, 2009], [SADILEK, 2007], [BUCKL, 2008]). Ao término da revisão a DSL descrita em [LOSILLA, 2007] foi escolhida como base para o desenvolvimento da DSL intermediária (Figura 4-1). As motivações para tal escolha foram: (i) a DSL proposta por Losilla ([LOSILLA, 2007]) preenchia os requisitos funcionais de 63

64 uma ampla gama de aplicações de RSSF, e (ii) possuía um nível de abstração que não incluía decisões de programação. Algumas modificações foram efetuadas para que a DSL definida pudesse suportar alguns requisitos nãofuncionais e a utilização de atuadores no desenvolvimento de aplicações para RSASF. Tal DSL foi construída para ajudar especialistas do domínio a descrever as suas aplicações usando apenas conceitos de RSASF com os quais eles eram familiarizados. Figura 4-1 Metamodelo da DSL intermediária com destaque para as diferenças entre ela e a proposta em [LOSILLA, 2007]. A DSL proposta por Losilla ([LOSILLA, 2007]) inclui tanto características estruturais quanto comportamentais da aplicação. Em aplicativos 64

65 desenvolvidos usando esta DSL, todos os objetos modelados são incluídos em uma aplicação de RSSF (elemento WSNApplication), onde essa aplicação é estruturalmente descrita como um conjunto de Regions. Uma Region é caracterizada pela proximidade física dos nós dentro dela. Todos os nós responsáveis pela execução de uma mesma tarefa são agrupados em um NodeGroup. Nodegroups são implantados próximos uns dos outros e são agrupados em uma Region. NodeGroups diferentes podem ser conectados através de um WirelessLink. O elemento NodeDefinition descreve o tipo de nós (por exemplo, SPOT [Sun SPOT, 2012]) que será utilizado na implementação da aplicação para cada NodeGroup. Nodegroups ainda guardam informações sobre quantos nós pertencem ao grupo (atributos minnumnodes e maxnumnodes). Behaviour é o elemento que representa o comportamento dos nós de um grupo (simulando uma máquina de estado). O comportamento dos nós de um mesmo NodeGroup é definido em termos de FunctionalUnits que podem ser tanto de Comunicação (CommUnit) ou unidades de tempo (TimerUnit). A funcionalidade representada por um FunctionalUnit é definida através de uma enumeração denominada FunctionalUnitType. Assim, a cada FunctionalUnit é atribuída um FunctionalUnitType que representa um comportamento específico. Por exemplo, o FunctionalUnitType RECEIVE_MSG_RADIO define o comportamento para esperar por uma mensagem de entrada (recebida via rádio), o FunctionalUnitType TIMER define um temporizador em milissegundos que deve terminar antes do início da próxima FunctionalUnit, etc. Além de definir as funcionalidades a serem realizadas pelos nós, o controle de fluxo também deve ser definido para especificar completamente a lógica da aplicação. UnitLinks são elementos que ligam as FunctionalUnits especificadas dentro de um NodeGroup, definindo a sequência em que elas serão executadas. Além disso, FunctionalUnits podem ser designadas para Resources através de um ResourceLink. ResourceLinks podem ser definidos como Sensor, Port ou ConfigParam de acordo com a necessidade do desenvolvedor. 65

66 Apesar de muitas características positivas, a DSL descrita anteriormente, que e foi inicialmente proposta pelo nosso grupo de pesquisa, não contempla alguns elementos importantes que devem ser considerados durante o desenvolvimento de aplicações para RSASF. Assim, novos elementos foram introduzidos na DSL original proposta em [LOSILLA, 2007]. As principais mudanças efetuadas na DSL estão destacadas na Figura 4-1 e serão detalhadas abaixo: Atuadores: o componente Actuator, definido para representar nós atuadores, foi inserido na DSL para que esta pudesse suporta o desenvolvimento de aplicações para a área de RSASF. Atuadores podem ser de dois tipos: Shaker ou Relay. Shakers são geradores de vibração que podem ser utilizados para análise ou testes em aplicações SHM [CHINTALAPUDI, 2006], por exemplo. Relays são basicamente switches eletrônicos; Componentes de envio de dados: subconjunto de componentes (DataDeliveryUnit, DataPacket e Data) responsável pelo controle da estratégia de envio de dados (substituição do componente CommUnit da DSL original) a partir de um nós sensor para outro nó sensor ou sink. Com a inserção destes componentes tornou-se possível definir o modelo de entrega de dados (atributo modeldelivery do componente DataDeliveryUnit) que será utilizado pela aplicação, bem como os pacotes de dados que serão enviados (componentes DataPacket e Data); Gerenciamento de Leds: o component LedsUnit, definido para representar os LEDs presentes na placa dos nós, permite o gerenciamento destes (função liga/desliga e definição da cor atual do LED) de acordo com as necessidades da aplicação. Trata-se de uma importante característica das aplicações, uma vez que eles são utilizados como um tipo de interface de comunicação com os usuários a partir do momento que a aplicação é implantada; Configuração do rádio: uma especialização do componente FunctionalUnit, RadioConfigurationUnit, foi desenvolvida com o objetivo de contribuir para o 66

67 controle de energia que é gasto pelos rádios dos nós presentes na rede, visto que é possível definir o ciclo de trabalho (atributo dutycycle deste componente) dos rádios; Suporte a agregação de dados: com a inclusão deste conceito, por meio do componente AggregationUnit, tornou-se possível trabalhar com redes de sensores e atuadores sem fio de larga escala, já que a operação de agregação permite diminuir o número de dados trafegados na rede, que por sua vez melhora a precisão dos dados coletados, torna a rede menos vulnerável a falhas e imprecisões de um único nó e diminui o consumo de energia; Componente de decisão: a inserção do componente DecisionUnit introduz operações de fluxo de controle nas aplicações, expandindo a quantidade de aplicações para RSASF que podem ser definidas pela DSL. Mesmo com as modificações efetuadas na DSL intermediária, após uma análise profunda da mesma observou-se que esta ainda apresentava algumas lacunas de grande importância e que por isso precisavam ser tratadas. A principal delas era que a DSL continuava sendo vista como um único metamodelo, fator este que impossibilitava a definição do comportamento da aplicação de maneira desacoplada da definição da estrutura da rede e que não possibilitava o suporte ao tratamento do tradeoff entre o custo de prototipagem e a capacidade de otimização de desempenho (refinamento das aplicações). Além disso, ainda era necessário que, ou os dois especialistas trabalhassem em conjunto, ou o especialista de domínio precisaria ter alguns conhecimentos sólidos (como detalhes de topologia de rede) acerca de RSASF, uma vez que apenas um metamodelo havia sido definido. Outro fator importante é que a DSL intermediária não suportava o desenvolvimento de um sistema de RSASF composto por diversas aplicações, dessa forma ela não suportava o desenvolvimento de sistemas para redes de sensores compartilhadas. Portanto, a fim de contornar tais limitações a linguagem LWiSSy foi desenvolvida. 67

68 4.2. LWiSSy Como discutido anteriormente, este trabalho propõe LWiSSY, uma linguagem de domínio para a modelagem de sistemas de RSASF. Com a utilização de LWiSSY, o processo de desenvolvimento destes sistemas leva em consideração as seguintes dimensões: (i) dimensão do perfil do desenvolvedor, o qual pode ser um especialista de domínio ou de redes; (ii) dimensão da granulosidade da especificação, que pode abranger a programação da rede como um todo (macroprogramação), de um grupo de nós ou de um único nó (micro-programação); e (iii) dimensão de projeto, a qual pode ser estrutural, comportamental ou de refinamento. Além das dimensões acima citadas, a necessidade de resolução do tradeoff entre o custo de prototipagem dos sistemas, por parte dos especialistas de domínio, e da capacidade de otimização (refinamento), por parte dos especialistas de rede, foi um fator determinante no projeto de LWiSSy. Para acomodar tal necessidade, o metamodelo de LWiSSy é composto por três modelos gráficos, definidos através de pacotes UML, que representam diferentes visões providas pela linguagem, como será apresentado ao longo desta Seção. A utilização de apenas um modelo gráfico ocasionaria a junção de conceitos comportamentais e estruturais em um único modelo, o que dificultaria a modelagem dos sistemas, uma vez que os elementos utilizados para expressar conceitos estruturais são semanticamente diferentes daqueles utilizados para expressar conceitos comportamentais. Adicionalmente, as atividades dos especialistas envolvidos no processo de desenvolvimento dos sistemas ficariam acopladas caso apenas um modelo gráfico fosse utilizado. O metamodelo de LWiSSy representa a dimensão de projeto (item iii supracitado) e é organizado em três visões, a saber: estrutural, comportamental e de refinamento. Cada uma dessas visões inclui componentes para projetar sistemas de acordo com as necessidades tanto da dimensão da granulosidade da especificação quanto da dimensão do perfil do desenvolvedor. O especialista 68

69 de domínio é responsável pela modelagem das visões estrutural e comportamental. Já o especialista de redes efetua a modelagem da visão de refinamento. A visão estrutural lida com a especificação em nível da rede e dos grupos de nós. Já a visão comportamental trata da especificação tanto em nível de grupo de nós quanto no nível dos nós individuais. Por meio da visão de refinamento é possível efetuar a especificação de características otimizacionais em nível da rede e dos grupos de nós Visão estrutural O subconjunto do metamodelo de LWiSSy apresentado na Figura 4-2 representa a visão que abrange as características estruturais das RSASF (visão estrutural). Ela destina-se aos especialistas de domínio e aborda a programação da rede como um todo e dos grupos de nós. Por meio desta visão o especialista de domínio pode criar uma RSASF, através do componente WSANSystem, sem que seja necessário possuir conhecimentos profundos acerca desta área, uma vez que para isto basta que o especialista defina o nome (atributo name do componente WSANSystem) do sistema de RSASF que ele deseja criar. Feito isto, faz-se necessária à criação de regiões (componente Region). Uma região consiste de um agrupamento de nós que se localizam em uma mesma região geográfica, ou seja, nós que serão dispostos próximos uns dos outros no ambiente físico. Mais uma vez, o especialista terá apenas que definir o nome da região (atributo name do componente Region) e latitude e longitude (atributos latitude e longitude do componente Region), caso um ambiente externo seja considerado. 69

70 Figura 4-2 Modelo gráfico que representa a visão estrutural em LWiSSy. Por sua vez, as regiões serão compostas por grupos de nós (componente NodeGroup). Um grupo de nós trata-se de uma entidade a qual agrupa nós que irão desempenhar tarefas semelhantes na rede. Dessa forma, o especialista deve definir quais e quantos grupos de nós irão integrar o seu sistema. Durante a modelagem de um grupo de nós, o especialista terá que definir o nome do grupo de nós (atributo name do componente NodeGroup), a quantidade mínima e máxima de nós pertencentes àquele grupo (atributos minnumnodes e maxnumnodes do componente NodeGroup) e o tempo de vida desejado (atributo lifetime do componente NodeGroup). O tempo de vida do grupo pode ser definido como LONG ou SHORT, valor este que influenciará na tarefa do especialista de redes quanto ao gerenciamento do consumo de energia dos grupos de nós. Isto porque caso seja definido o valor LONG será necessário utilizar políticas de gerenciamento de energia mais restritivas, uma vez que o especialista de domínio deseja que àquele grupo permaneça ativo na rede por muito tempo. Caso contrário, quando o valor SHORT é escolhido, o especialista 70

71 de redes visualiza que as políticas podem ser menos restritivas já que não é esperada uma longa permanência daquele grupo na rede. Convém destacar que o atributo de tempo de vida do grupo de nós foi incluído na modelagem de LWiSSy por se tratar de um requisito de QoS crítico para diversas aplicações da área de RSASF, como por exemplo: monitoramento de marés e oceanos, que permitem a melhoria da previsão climática de secas e inundações e a determinação dos índices de precipitação pluviométrica; detecção de focos de incêndio em florestas, afim de agilizar a localização e o combate ao fogo, etc. Isto ocorre porque muitos destes ambientes onde as redes são instaladas são de difícil acesso para o ser humano o que dificulta o acesso a esses elementos para manutenção. Além disso, o valor definido para o atributo lifetime impacta diretamente na escolha dos protocolos de comunicação e roteamento que serão utilizados pelo sistema e definidos durante a modelagem da visão de refinamento efetuada pelo especialista de redes. A escolha destes protocolos é impactada, pois ambos lidam diretamente com o consumo de energia da rede, seja a fim de economizar ou não este recurso. Nós pertencentes a grupos diferentes poderão estabelecer comunicação uns com os outros através de conexões sem fio (componente WirelessLink), nas quais devem ser definidos o grupo de nós que origina a comunicação (atributo source do elemento WirelessLink) e o grupo de nós alvo da comunicação (atributo target do elemento WirelessLink). Após a definição dos grupos de nós, o especialista de domínio precisa definir ainda quais recursos (componente Resource) serão implantados nos nós que compõem cada um dos grupos. Assim sendo, o especialista de domínio pode definir um recurso como sendo um sensor (componente Sensor) caso ele deseje acoplar uma ou mais placas de sensores (sensores de temperatura, de localização, de luminosidade, entre outros) nos nós sensores presentes naquele grupo. Caso seja necessária à utilização de atuadores (componente Actuator) o 71

72 especialista poderá definir o tipo de atuador que será utilizado (relay ou shaker). O especialista pode ainda definir recursos do tipo porta (componente Port), os quais são utilizados por nós sink para conectá-los as estações base seja por meio de portas USB ou seriais. Por fim, faz-se necessária a definição das aplicações (componente Application) que serão executadas por cada um dos grupos de nós presentes no sistema. Esta característica de permitir a execução de múltiplas aplicações em uma mesma infraestrutura de sensoriamento faz com que LWiSSy suporte a modelagem da nova geração de sistemas para RSASF (Shared Sensor Networks). Durante a modelagem deste elemento, o especialista de domínio deve definir o nome da aplicação (atributo name do componente Application), uma descrição (atributo description do componente Application), caso ache necessário, a quantidade de nós que desempenharão as atividades relacionadas com aquela aplicação (atributo nodesquantity do componente Application), a acurácia dos dados desejada pela aplicação (atributo dataaccuracyrange do componente Application) e a latência máxima esperada (atributo maxlatency do componente Aplication). Dentre os atributos supracitados dois merecem uma atenção especial, sendo eles dataaccuracyrange e maxlatency. O primeiro deles lida com um importante requisito de QoS, a saber, a precisão (acurácia) dos dados que é exigida pelas aplicações e que norteia a decisão sobre qual protocolo de comunicação será utilizado, visto que diferentes protocolos proveem diferentes garantias de QoS. Esse atributo pode assumir valores entre 0 e 1, onde 0 significa que a precisão dos dados não é importante para a aplicação (como em algumas aplicações de monitoramento ambiental, por exemplo) e 1 significa que a precisão é um requisito crítico para a aplicação (como em aplicações para monitoramento em health care e em indústrias petroquímicas). O segundo atributo, maxlatency, o qual deve ser definido em milissegundos, lida com o intervalo de tempo entre o momento em que determinada ação é 72

73 sensoriada até o momento em que essa informação é armazenada no seu destino final, seja um nó sink ou um outro nó da rede. Este atributo deve ser definido com base no documento de requisitos do sistema e seu valor afeta diretamente o consumo de energia da rede e o protocolo de comunicação que será utilizado, pois quanto menor for a latência máxima definida, mais intensa será a comunicação entre os nós da rede, causando um aumento no consumo de energia e a necessidade de utilização de um protocolo de comunicação confiável a fim de garantir que a maior quantidade possível de pacotes transmitidos sejam recebidos. Após uma rápida análise da visão descrita acima é possível notar que há dois tradeoffs na visão estrutural. O primeiro deles acontece entre os atributos lifetime (componente NodeGroup) e dataaccuracyrange (componente Applicaton), visto que não é possível garantir uma acurácia de dados elevada caso políticas de gerenciamento de energia que visam um gasto mínimo sejam utilizadas. O outro tradeoff ocorre entre os atributos lifetime (componente NodeGroup) e maxlatency (componente Application). Como apresentado no parágrafo anterior, a latência máxima definida impactará no consumo de energia da aplicação. No entanto, convém ressaltar que este consumo não decrescerá monotonicamente ao passo que o valor da latência máxima for aumentado [YU, 2004]. Para garantir que estes conflitos não sejam inseridos durante a modelagem de sistemas para RSASF, o metamodelo de LWiSSy não permite a configuração dos atributos lifetime e dataaccuracyrange em seus valores máximos simultaneamente, nem a definição de latências máximas inferiores a 1,5 segundos caso o atributo lifetime seja configurado como LONG (para se chegar a este valor foram utilizadas as equações definidas em [SCHURGERS, 2001]) Visão comportamental Assim como ocorre com a visão estrutural, o subconjunto de componentes do metamodelo de LWiSSy que compõem a visão comportamental, descrita nesta 73

74 Seção (Figura 4-3), destina-se aos especialistas de domínio. Essa visão lida com a programação de grupos de nós e de nós individuais e é responsável pelo projeto do comportamento de cada uma das aplicações que integram o sistema de RSASF e, portanto, será necessário produzir um modelo comportamental para cada uma das aplicações presentes no sistema. Figura 4-3 Modelo gráfico que representa a visão comportamental em LWiSSy. Nesta visão, o especialista deve inicialmente definir um ponto de partida pelo qual a aplicação começará (componente InitialState). Feito isto, o especialista chega ao core do modelo, onde ele poderá definir o conjunto de todas as atividades que integram a aplicação (componente Activity). Para modelar a dependência entre as atividades e o fluxo da aplicação, o especialista pode encadear as atividades por meio do relacionamento link presente no componente Activity. Cada uma das atividades executadas pela aplicação pode utilizar qualquer um dos recursos presentes no grupo de nós sobre o qual a aplicação será instalada. Para isto, basta que o especialista de domínio instancie o atributo usedresourcename (presente no componente Activity) com o nome dos recursos 74

75 que ele deseja utilizar. Os tipos de atividades disponíveis em LWiSSy são: Join, Fork, Choice e Action. O componente Fork efetua uma divisão no fluxo principal da aplicação em dois fluxos paralelos. Este componente permite a execução de atividades concorrentes nos nós caso a plataforma suporte esta característica. Com a utilização do componente Join é possível unir os fluxos paralelos, gerados pelo fork, em apenas um único fluxo principal. O terceiro componente, Choice, representa uma estrutura condicional. Com isso, ao utilizá-lo o especialista de domínio deve definir uma guarda (atributo guard do componente Choice), que nada mais é do que uma condição que deve ou não ser satisfeita após o término da atividade anterior a esta, e cenários (atividades) de saída que serão executados de acordo com o resultado obtido durante a análise da guarda. A expressão if Temp > 40 pode ser considerada um exemplo de guarda que analisará o resultado da coleta dos dados de temperatura para definir qual será a próxima atividade a ser executada pela aplicação. Neste caso, o atributo Temp é um recurso que foi definido durante a visão estrutural e que compõe o grupo de nós responsável pela execução desta aplicação. O último e mais complexo dos componentes que representam uma atividade trata-se do componente Action. Todo elemento definido como uma Action deve ter um nome associado (atributo name) e, caso o especialista de domínio ache necessário, uma descrição (atributo description). Este componente deve ser utilizado para modelar funcionalidades específicas de RSASF durante a modelagem da aplicação. Ele é composto por cinco componentes: Timer, Aggregation, LED, Send e Common. O componente Timer deve ser utilizado pelo especialista caso seja necessário utilizar algum tipo de temporizador (timer) durante o fluxo da aplicação. Ele pode ser útil em aplicações onde a coleta ou o envio de dados seja periódico, sendo realizado em intervalos de tempo constantes e predefinidos, em contraste com aplicações dirigidas a eventos onde a coleta e o envio de dados dependem da ocorrência de um determinado evento e não consideram o fator tempo. 75

76 Durante a modelagem de um componente deste tipo, o especialista de domínio deve determinar um intervalo de tempo em milissegundos (atributo timer) e o tipo de timer a ser utilizado (atributo type), o qual pode ser contínuo (disparado a cada ciclo daquela aplicação) ou pontual (disparado apenas durante o primeiro ciclo de atividades da aplicação). O segundo componente do tipo Action trata-se do componente Aggregation. Ele deve ser empregado em aplicações onde se desejam realizar operações de agregações de dados. Diversas aplicações de RSASF utilizam algum tipo de agregação antes de enviarem os dados coletados para os nós sink ou estações base. Isso se faz necessário pela grande quantidade de nós sensores presentes na rede, o que acaba gerando uma maior transmissão de dados e, por sua vez, o aumento de colisões e perda de pacotes, além do elevado consumo de energia por parte dos nós sensores, visto que a comunicação é a principal responsável pelo consumo de energia. Dessa forma, a agregação dos dados pode melhorar a precisão dos dados coletados, tornar a rede menos vulnerável a falhas e imprecisões de um único nó e diminuir o consumo de energia [NAKAMURA, 2007]. Em uma agregação é necessário definir a variável onde o resultado da agregação será armazenado (atributo variable) e a função de agregação que será utilizada (atributo function), a qual pode ser um dos valores predefinidos por LWiSSy (AVERAGE, COUNT, MIN e MAX), ou pode ser definida pelo especialista posteriormente (USER_DEFINED), visto que a agregação pode envolver técnicas mais complexas, como media móvel ponderada, inferências bayesianas, várias técnicas estatísticas ou probabilísticas, dentre outras. A agregação possui dois atributos de controle, sendo eles: o número de amostras que o sensor irá agregar (atributo numberofsamples) e o intervalo de tempo n o qual o nó estará disponível para receber os dados coletados (atributo delay). Caso o intervalo de tempo (delay) seja atingido durante o processo de agregação e a quantidade de amostras não seja a esperada, a agregação será efetuada a fim de garantir o 76

77 bom funcionamento da aplicação, ou seja, o atributo delay é mandatório no processo de agregação. O componente LED trata do gerenciamento dos LEDs que se encontram na placa do nó. Através dele é possível ligar e desligar os LEDs (atributo status), bem como escolher a cor que será utilizada pelos mesmos (atributo color) quando estiverem ligados. Os LEDs podem desempenhar o papel de atuadores por meio da emissão de sinais de alerta durante a ocorrência de algum evento inesperado, por exemplo. A penúltima funcionalidade inerente a área de RSASF que LWiSSy trata é o envio de mensagens entre os nós da rede. Esta funcionalidade é suportada pelo componente Send. Por meio dele, o especialista de domínio pode definir o tipo de modelo de entrega de dados que será utilizado (atributo pushmodel) pela aplicação e o meio pelo qual a mensagem será dissipada na rede (atributo sendmessageby). Além disso, o atributo parameter será utilizado de acordo com o modelo de entrega de dados escolhido. Caso o tipo EVENT_DRIVEN seja configurado, o especialista deverá definir qual a condição (evento de interesse) que deve ser considerada para que os dados sejam enviados. No entanto, caso o tipo PERIODIC seja configurado, o especialista deverá determinar o intervalo de tempo, em milissegundos, no qual os dados devem ser enviados. O último componente a ser descrito, Common, engloba várias funcionalidades da área de RSASF que, ao contrário das demais até agora citadas, não possuem tantas configurações e por isso foram armazenadas em um único componente. Para utilizá-lo o especialista de domínio precisa apenas definir o atributo type para dos tipos predefinidos em CommonType. Dentre as funcionalidades mapeadas para este componente aparecem: a configuração dos rádios dos nós, a leitura de dados provenientes de um sensor ou de uma porta, o recebimento por porta ou rádio de mensagens, o envio de uma ação por meio de um atuador à rede e a exibição dos dados recebidos por uma estação base. Convém destacar que a configuração dos rádios pode ser considerada uma 77

78 funcionalidade mais complexa, pois se faz necessária a definição do ciclo de trabalho (duty cycle) do mesmo. No entanto, tal característica é considerada de baixo nível de abstração para ser tratada pelo especialista de domínio e, por isso, será tratada diretamente pelo especialista de redes durante a modelagem da visão de refinamento. Por fim, o especialista de domínio pode configurar um ou mais estados finais para a sua aplicação (componente FinalState). Em alguns casos este componente não é modelado, pois se trata de uma aplicação cíclica. Ao término da descrição desta visão pode-se concluir que ela é uma instanciação do diagrama de atividades da UML com foco na área de RSASF. Tal diagrama foi escolhido como base por representar os estados de uma atividade e por ser orientado a fluxos de controle, características estas que são mais facilmente absorvidas e utilizadas por profissionais que não conhecem os diagramas da UML. Além disso, quando se considera um alto nível de abstração, todo o fluxo das aplicações pode facilmente ser modelado por meio deste tipo de diagrama Visão de refinamento A última visão a ser descrita será a visão de refinamento (Figura 4-4). Essa visão lida com a dimensão estrutural da rede, englobando características específicas de RSASF, como os protocolos a serem utilizados. É importante ressaltar que detalhes de modelagem do comportamento dos protocolos está fora do escopo deste trabalho. Ao utilizar a visão de refinamento de LWiSSY, inicialmente o especialista de redes deverá efetuar uma análise dos modelos anteriores, que foram definidos pelo especialista de domínio, para que ele possa efetuar a escolha da melhor configuração de protocolos de RSASF considerando a questão de refinamento da rede com relação aos parâmetros de QoS definidos durante a fase de levantamento de requisitos do sistema. 78

79 Figura 4-4 Modelo gráfico que representa a visão de refinamento em LWiSSy. Feito isto, o especialista deve determinar quais os protocolos de transporte (atributo transportprotocol do componente System), caso algum seja utilizado, e de roteamento (atributo routingprotocol do componente System) serão utilizados pelo sistema (System). Além disso, ele pode acessar os grupos de nós (componente GroupOfNodes), que foram definidos durante a modelagem da visão estrutural (componente NodeGroup), para definir quais os tipos de nós sensores serão utilizados (nodetypes). Neste caso, se o especialista de redes definir que os nós utilizados serão do tipo SPOT (opção predefinida do componente NodeType), consequentemente ele estará definindo que a plataforma Sun SPOT será utilizada, ou seja, essa escolha está relacionada à plataforma de sensores específica a ser empregada. Cada grupo de nós pode ser constituído por um ou mais tipos de nós, de acordo com as aplicações que serão executadas. Por fim, o especialista terá que definir qual a estratégia de comunicação que será utilizada por cada uma das aplicações (atributo commstrategy do 79

80 componente App) e,caso durante a modelagem comportamental da aplicação alguma atividade do tipo ConfigRadio tenha sido definida, ele deverá modelar qual o ciclo de trabalho (atributo dutycycle do componente App) dos rádios de acordo com todo o comportamento daquela aplicação Descrição da Infraestrutura MDA Para possibilitar o desenvolvimento de sistemas para RSASF utilizando LWiSSy, este trabalho utiliza a infraestrutura MDA definida em [RODRIGUES, 2011]. A visão geral da construção da infraestrutura pode ser vista na Figura 4-5. Figura 4-5 Construção da infraestrutura MDA utilizada. A atividade Construir programa de transformação M2M é composta pela criação do programa de transformação de modelo para modelo. Neste caso, foi criado um programa de transformação entre o metamodelo de LWiSSy o os metamodelos específicos de plataforma existentes na infraestrutura utilizada. Finalmente, a atividade Construir programa de transformação M2T visa efetuar a geração de código fonte a partir de modelos específicos de plataforma. Nesta atividade, devem ser desenvolvidos os templates de código, que 80

81 funcionam como esqueletos para cada plataforma-alvo. Os templates que serão utilizados já haviam sido desenvolvidos anteriormente (disponíveis em [RODRIGUES, 2011]). As atividades descritas produzem todos os artefatos de software incluídos na infraestrutura MDA. Com a definição destes artefatos (metamodelos DSL/PIM, metamodelos PSM para plataformas RSASF e transformações M2M e M2T), é possível utilizar a abordagem MDA para a construção de sistemas de RSASF utilizando LWiSSy Desenvolvimento de sistemas utilizando LWiSSy Esta Seção apresenta os passos necessários para desenvolver um sistema de RSASF por meio da linguagem LWiSSy fazendo uso dos artefatos definidos durante a construção da infraestrutura MDA utilizada. O processo de desenvolvimento a ser seguido está sintetizado no diagrama de atividades UML da Figura 4-6. A primeira atividade no diagrama, "Análise de requisitos", é realizada por ambos os especialistas considerados neste trabalho, o especialista de domínio e o especialista em redes, e representa a etapa onde eles levantam todas as informações necessárias para a construção do sistema. Esta é uma atividade tradicional de elicitação de requisitos realizada em qualquer processo de desenvolvimento de software [PRESSMAN, 2004]. Os artefatos de software produzidos como resultados dessa atividade (diagramas UML de Casos de Uso, documentos textuais, etc.) representam os requisitos do sistema e constituem o CIM (Computation Independent Model), que será utilizado nas fases posteriores pelos desenvolvedores (os dois tipos de especialistas) envolvidos na construção do sistema de RSASF. O documento inclui requisitos funcionais (relacionados com a lógica da aplicação) e requisitos não-funcionais (relacionados com a configuração da plataforma de RSASF e requisitos de QoS, como tempo de vida 81

82 da rede e a acurácia dos dados). O CIM deve ser utilizado pelos especialistas de domínio e de redes nas atividades "Modelar sistema com LWiSSY" e "Escolher plataforma, respectivamente. Este trabalho não engloba a modelagem do CIM durante o desenvolvimento dos sistemas. Figura 4-6 Adaptação do processo de desenvolvimento proposto em [RODRIGUES, 2011]. Com o término da análise de requisitos, os especialistas de domínio e de redes podem efetuar a tarefa Modelar sistema com LWiSSY, a qual é composta pela modelagem das três visões anteriormente detalhadas. Além disso, o especialista de redes ainda deve definir a plataforma de RSASF que será utilizada para o desenvolvimento do sistema ( Escolher plataforma ), de acordo com os requisitos do sistema. Em seguida, a atividade "Aplicar transformações M2M" é realizada pela infraestrutura MDA. Essa atividade tem como entrada os modelos PIM, com o 82

83 seu metamodelo associado (LWiSSy), e o metamodelo PSM da plataforma de RSASF escolhida pelo especialista de redes, e gera como saída uma instância do PSM que representa a concretização do sistema nesta plataforma específica. Tal PSM, se necessário, é refinado pelo especialista de redes na atividade "Refinar Modelo", a fim de incrementar o modelo gerado automaticamente com informações referentes às especificidades relacionadas com a rede da plataforma alvo, ou escolher uma biblioteca de aplicativos que melhor se adapte ao gerenciamento dos requisitos não-funcionais relacionados, por exemplo, às características da área alvo ou as políticas de economia de recursos da rede. Finalmente, é realizada a atividade "Aplicar transformações M2T". Esta atividade tem duas entradas: o modelo PSM refinado pelo especialista de redes e o modelo de código da plataforma escolhida ( Regras de transformação M2T ), e gera como saída os códigos fonte do sistema que serão implantados nos nós da rede de acordo com as aplicações que serão executadas em cada um deles e do grupo de nós ao qual o nó pertence. O código-fonte gerado nesta fase já é compilável, mas ele ainda pode ser refinado por ambos os especialistas, de rede e domínio (cada um considerando seu conhecimento específico), na atividade "Refinar Código", a fim de adicionar melhorias como funções específicas das aplicações ou parâmetros de protocolos que não são automaticamente gerados pelo processo Exemplo ilustrativo Nesta Seção, um sistema simples de RSASF será projetado utilizando LWiSSy, a fim de ilustrar as etapas do processo de desenvolvimento e ressaltar as características da DSL proposta. O objetivo desse sistema é controlar LEDs em nós de RSASF de acordo com a temperatura local de uma floresta na qual estão implantados 30 nós sensores. Quando a temperatura do ambiente monitorado ultrapassa 40º C, um LED vermelho é ligado nos nós e uma mensagem é enviada para um nó sink, que dispara um alarme; caso contrário, os LEDs não são ligados nem os alarmes são disparados. 83

84 Inicialmente, o especialista de domínio precisa projetar a parte estrutural do sistema. O especialista especifica, utilizando a visão estrutural de LWiSSy, todos os componentes estruturais da rede e promove as conexões entre eles, como ilustrado na Figura 4-7. Nesse caso, o especialista está lidando com a programação do sistema de RSASF como um todo (macro-programação). Figura 4-7 Visão estrutural do sistema Fire Detection System especificada pelo especialista de domínio. Nesse sistema, denominado Fire Detection System, duas regiões foram definidas. A primeira região, SensorNodesRegion, é composta de nós sensores implantados no ambiente e a segunda região, SinkNodeRegion, é composta por um único sink localizado remotamente. O grupo de nós SensingNodes deve ser composto por no máximo 30 nós. Já a região SinkNodeRegion possui um grupo de nós chamado SinkNode, o qual é composto por um único nó. O grupo de nós SensingNodes é composto por sensores (TemperatureSensor) enquanto que o grupo de nós SinkNode é composto por um atuador (AlarmActuator). Finalmente, duas aplicações, Temperature Monitoring e Trigger Alarm, são definidas, representando respectivamente as tarefas de sensoriamento e de atuação. Feito disso, o especialista de domínio precisa modelar os aspectos comportamentais específicos de cada uma das aplicações, utilizando a visão comportamental de LWiSSy. Convém acrescentar que o fluxo comportamental modelado para as aplicações será implantado em cada um dos nós que a 84

85 compõe. Assim sendo, este comportamento pode ser considerado como o comportamento individual de cada um dos nós. O comportamento da aplicação Temperature Monitoring é mostrado na Figura 4-8, na qual a aplicação é dividida em seis atividades. Inicialmente, os rádios são configurados (atividade ConfigurateRadio) e os dados referentes à temperatura são coletados (atividade ReadTemperature). Na atividade SendMessage, uma mensagem é enviada apenas se a temperatura local for superior a 40º C. Essa característica é modelada pelo elemento Send e o seu atributo PushModelType foi configurado para o valor EVENT_DRIVEN, onde o atributo parameter possui o valor if (TemperatureSensor > 40). Adicionalmente ao envio da mensagem, um LED vermelho é ligado (atividade LEDRedOn) e permanece neste estado durante cinco segundos (definição de componente Timer). Por fim, o LED é desligado (atividade LEDRedOff) e a aplicação retorna à atividade ReadTemperature. Figura 4-8 Visão comportamental da aplicação Temperature Monitoring especificada pelo especialista de domínio. O último modelo projetado pelo especialista de domínio define a visão comportamental para a aplicação Trigger Alarm (Figura 4-9). Está aplicação é composta por quatro atividades e, assim como a aplicação anterior, o comportamento desta é cíclico. 85

86 Figura 4-9 Visão comportamental da aplicação Trigger Alarm especificada pelo especialista de domínio. Inicialmente o radio do nó sink que executa esta aplicação é configurado (atividade ConfigurateRadio). Feito isto, a aplicação fica em stand by a espera de dados enviados pelos nós sensores da aplicação. Caso uma mensagem chegue ao sink (atividade ReceiveMessage) significa que a temperatura ultrapassou os 40ºC e ele dispara um alarme (atividade TriggerAlarm) por meio de um atuador. Feito isto, após 60 segundos (definição de componente Timer), o sink volta para a segunda atividade. Por fim, o último modelo, referente à visão de refinamento em LWiSSy, é especificado pelo especialista de redes e envolve elementos de refinamento, como ilustrado na Figura Várias características projetadas como parte dos modelos anteriores, como lifetime e dataaccuracyrange, precisam ser consideradas neste modelo, uma vez que elas afetam diretamente a escolha dos melhores protocolos a serem utilizados. Este modelo inclui o protocolo de comunicação (FLOODING) e a topologia usada na rede (FLAT). Depois dessas etapas, o especialista de redes pode gerar automaticamente o código fonte utilizando a infraestrutura MDA descrita anteriormente. 86

87 Figura 4-10 Visão de refinamento do sistema Fire Detection System especificada pelo especialista de redes. 87

88 5. Avaliação Neste Capítulo é realizada a avaliação da linguagem LWiSSy (Seção 5.2) por meio de duas abordagens diferentes, a fim de determinar se os objetivos deste trabalho, definidos na Seção 0, foram alcançados. No entanto, antes de dar início a avaliação da linguagem LWiSSy, uma prova de conceito e alguns cenários de mudança envolvendo a DSL intermediária (Seção 5.1) são exibidos a fim de relatar os benefícios que já eram obtidos pela sua utilização durante o desenvolvimento de sistemas para RSASF Análise da DSL Intermediária Proposta Para se avaliar os benefícios obtidos com o uso da DSL inicialmente proposta, na construção de aplicações de RSASF, foi conduzida uma prova de conceito, descrito na Seção Error! Reference source not found.. Feito isto, são descritos cenários de mudanças, com o intuito de explorar a flexibilidade da DSL intermediária quanto a eventuais alterações efetuadas em alguns dos requisitos do sistema, bem como avaliar a complexidade envolvida nestas alterações Prova de conceito A prova de conceito modelada com a DSL intermediária foi extraída de um importante domínio de aplicação de RSASF: monitoramento da saúde de estruturas civis (Structural Health Monitoring - SHM) [CHINTALAPUDI, 2006] Structural Health Monitoring O objetivo das aplicações de monitoramento da saúde estrutural (SHM) é detectar e localizar danos em estruturas civis, como prédios, pontes, dentre outras. Todas as estruturas reagem a vibrações, forçadas ou causadas pelo ambiente (naturais). Vibrações naturais podem ser geradas por terremotos, ventos, veículos em movimento, ondas, entre outros, enquanto vibrações forçadas são geradas por shakers e outros dispositivos. Há várias propostas de 88

89 algoritmos para realizar detecção e localização de danos em estruturas. A prova de conceito do presente trabalho foi baseada em [CHINTALAPUDI, 2006], onde são apresentados dois algoritmos para SHM. O primeiro trata da localização e o segundo da detecção de danos. Nesta prova de conceito, apenas o algoritmo de detecção de danos é analisado, cujo objetivo é detectar a presença de danos em um edifício usando (i) acelerômetros capazes de detectar variações no comportamento da estrutura, e (ii) um computador externo ao processo de detecção dados; e determinar a existência de danos estruturais. Para a execução com sucesso, desse algoritmo, são necessários no mínimo trinta nós sensores, a serem dispostos em cada andar do edifício monitorado, para obter dados com a precisão necessária para detectar qualquer anormalidade. O algoritmo de detecção funciona da seguinte forma: inicialmente, os sensores coletam a assinatura inicial da estrutura monitorada e enviam essa informação para o nó coletor (sink) conectado a um computador. Essa leitura inicial consiste na assinatura de uma estrutura "saudável" (não danificada) e é usada para fins de comparação com as medições posteriores dos sensores. Em uma segunda fase, o sink calcula um conjunto de funções (como detalhado em [CHINTALAPUDI, 2006]) e armazena os resultados para cada assinatura da estrutura, centralizando as funções que necessitam de um maior processamento em um computador e não em cada nó sensor. A assinatura de uma estrutura é obtida após ter sido efetuada a coleta dos sinais de aceleração pelos sensores e representa a resposta vibracional da estrutura a estímulos recebidos. Após a coleta, é aplicada uma Transformada Rápida de Fourier (FFT) no sinal de aceleração coletado. A seguir, usa-se um método para extração dos valores de frequência dos picos do espectro de frequência gerado pela FFT. Esses valores de frequências dos picos são as frequências respectivas aos modos de vibração da estrutura. Os valores de frequências obtidas em cada sensor, considerando a taxa de amostragem utilizada, referem-se aos primeiros picos do espectro de frequência retornado pela FFT, e vão compor a chamada assinatura da estrutura. 89

90 Vários tipos de hardware de sensores fornecem as funcionalidades necessárias para uma aplicação de SHM. Nesta prova de conceito é desenvolvida uma aplicação para rodar em nós sensores Sun Spot ([Sun SPOT, 2012]), com a seguinte configuração: nós Sun SPOT modelo MPR 2400, que operam com rádio IEEE , associados a placas de sensoriamento com acelerômetro de 3 eixos. O hardware do nó sink (ou estação base) é desconectado das placas de sensoriamento e conectado a um computador pessoal através de um cabo USB, usando uma porta USB padrão. O computador pessoal receberá os dados coletados pelos nós sensores e aplicará o algoritmo de detecção de danos Modelagem da aplicação SHM A modelagem de aplicações para RSASF com a DSL intermediária segue os mesmos passos que são utilizados por LWiSSy e que foram detalhados na Seção 4.4. No entanto, neste caso, a atividade Modelar sistema com LWiSSy será efetuada com o auxílio do metamodelo da DSL intermediária ao invés do metamodelo de LWiSSy, o que ocasionará a produção de modelos PIM da DSL intermediária. Além disso, as regras de transformação M2M utilizadas são aquelas definidas em [RODRIGUES, 2011]. Os demais passos do ciclo de desenvolvimento são executados da mesma forma para ambas as DSLs. Esta característica já permite-nos visualizar que a adoção deste ciclo de desenvolvimento de sistemas para RSASF possibilita o reuso de diversos artefatos, o que pode facilitar o desenvolvimento e a manutenção destes sistemas. De acordo com o processo utilizado, a primeira atividade tem com o objetivo a produção do modelo CIM. Como já mencionado anteriormente, a modelagem deste modelo não faz parte do escopo deste trabalho. Logo após, o especialista de domínio inicia a modelagem da aplicação utilizando a DSL intermediária e o modelo CIM. Em paralelo a esta atividade, o especialista de redes analisa o CIM e escolhe qual plataforma de RSASF melhor se adapta aos requisitos da 90

91 aplicação-alvo. Como já detalhado na Seção anterior, a plataforma Sun SPOT é utilizada. A modelagem da aplicação SHM pode ser visualizada na Figura 5-1. Nela observa-se que duas a aplicação é composta por duas regiões (downtier e uptier) e três tipos de nós: floor1, o qual é composto por acelerômetros; SinkNode, o qual possui uma porta USB e Shaker, composto por um atuador. A primeira região, downtier, é dividida em um grupo de nós (Damage_detection_1), o qual, por sua vez, apresenta um único fluxo comportamental definido em Collects_building_data. Figura 5-1 Modelagem da aplicação de SHM com a DSL intermediária. 91

92 O fluxo comportamental Collects_building_data pode ser visto como uma máquina de estados, onde os estados são representados pelas unidades funcionais (FunctionalUnit, RadioConfigUnit, LedsUnit, TimerUnit, AggregationUnit e DataDeliveryUnit) e as transições podem ser vistas como os UnitLinks, os quais efetuam as conexões entre as unidades funcionais. Dessa forma, este fluxo comportamental pode ser descrito da seguinte maneira: os nós do grupo são ligados (startsensing); os rádios pertencentes a estes nós são configurados (configradiosensing); os LEDs vermelhos dos nós são acesos (redlight); os acelerômetros dos nós são calibrados (calibrate); a aplicação fica em stand by durante 22 segundos (timer22s); os atuadores são disparados (actuator); mais uma vez a aplicação entra no modo stand by por 20 segundos; os LEDs amarelos dos nós são acesos (yellowlighton); os nós coletam dados dos acelerômetros (getsamples); a agregação dos dados coletados pelos nós é efetuada (getaverage); os LEDs amarelos dos nós são desligados (yellowlightoff); os dados coletados e agregados são enviados ao nó sink (senddata) e, por fim, a aplicação permanece no modo stand by por 24 horas antes que o processo comece novamente. Enquanto isso, o fluxo comportamental (getdata) modelado para o grupo de nós (sinknode) da segunda região (uptier) funciona como segue: o nó sink é ligado (startsink); o seu rádio é configurado (configradio); o nó fica esperando que dados sejam enviados para ele (receivedata) e, quando isso ocorre, ele os envia para um computador (storedata) por meio de uma porta USB. Feito isto, os especialistas devem efetuar as atividades posteriores a modelagem da aplicação, as quais podem ser vistas na Figura Cenários de mudança Nesta subseção são discutidos quatro cenários de mudanças (denotados por SC), os quais representam situações típicas em ambientes de RSASF, sendo elas: (i) mudança do protocolo de comunicação adotado na rede; (ii) mudança dos requisitos da aplicação; (iii) desenvolvimento de uma nova aplicação para a 92

93 mesma plataforma de RSASF; e (iv) execução da aplicação em uma plataforma de RSASF diferente. SC1. Mudança de protocolos de nível de rede. Há diversos protocolos especificamente projetados para RSSF [LEVIS, 2006], cada um mais adequado para diferentes topologias e atendendo diferentes requisitos de QoS. Uma mudança de topologia da rede ou da densidade dos nós instalados pode demandar a escolha de um novo protocolo para executar nos sensores. Utilizando a presente proposta, caso haja a necessidade de alteração do protocolo de rede usado, o especialista de redes teria que realizar mudanças no modelo PSM da aplicação gerado, durante a atividade Refinar Modelo. Para mudar o protocolo faz-se necessária uma atualização no PSM que foi gerado automaticamente pelo processo MDA. Esta atualização é composta de três fases: a primeira é a remoção dos métodos, responsáveis pelo protocolo de rede, que estão declarados, mas que não serão mais utilizados; a segunda é a adição de novos métodos que implementam o novo protocolo necessário; e a terceira, é refazer o construtor da classe atualizando o fluxo do programa. É importante observar que todos os aspectos relacionados ao domínio ficam totalmente transparentes ao especialista de redes no momento da troca de protocolo, fazendo com que todas as mudanças realizadas neste nível sejam claramente separadas da modelagem feita pelo especialista de domínio. SC2. Mudança dos requisitos da aplicação. Em caso de mudanças nos requisitos da aplicação, serão necessárias mudanças ao nível do modelo PIM, realizadas pelo especialista de domínio. Um caso típico de mudança consiste nos requisitos de QoS da aplicação. Supondo a aplicação de SHM, se ao longo do monitoramento e análise de dados for detectada uma situação de dano potencial em uma estrutura, passa a ser mais relevante ter uma resposta rápida da rede em vez de aumentar seu tempo de vida. Tal requisito pode ser traduzido para uma alteração na política de energia e na taxa de envio de dados. Para alterar a política de energia tudo que o especialista de domínio 93

94 precisa fazer é modificar o valor do ciclo de trabalho do elemento RadioConfigUnit. Para mudar a taxa de envio de dados, o especialista de domínio terá apenas que alterar o valor do temporizador TimerUnit que controla o tempo de espera antes de cada envio de dados. Desta, forma a transformação M2M irá gerar o modelo PSM utilizando as configurações que condizem com a escolha do especialista. Todas estas alterações podem ser efetuadas sem a participação do especialista de redes. SC3. Nova aplicação. Este cenário ilustra o reuso obtidos dos artefatos em nível de plataforma quando uma nova aplicação é modelada em uma plataforma que é especifica na infraestrutura MDA utilizada. Uma aplicação pertencente ao domínio de monitoramento de desastres ambientais, especificamente de detecção de queimadas é considerada neste cenário. Em [FARIAS, 2005] é descrita uma aplicação para monitorar queimadas baseada no uso de 50 sensores. Resumidamente, os sensores são divididos em dois grupos: no primeiro, com 49 sensores, os nós foram distribuídos pela floresta a fim de coletar os dados e enviá-los para o sorvedouro; no segundo grupo um nó, o sorvedouro, recebe os dados enviados pelos nós sensores e envia-os para um computador externo através de uma conexão USB. Para esta aplicação (Figura 5-2), foram criadas duas regiões representando a área sensoreada e a área ocupada pelo nó sink, respectivamente. Para a área sensoreada, região sensing, um grupo de nós (sensingforest) foi modelado, contendo um componente Behaviour chamado collectdata e que é responsável pela coleta de dados sobre a temperatura local e o envio destes ao nó sink. Já na segunda região, sink, o grupo de nós antenna foi modelado, o qual é composto pelo componente antennabehaviour. Este componente tem como tarefa receber os dados coletados pelos nós sensores e enviá-los para um computador externo a rede. Além disso, caso uma queimada seja detectada na floresta, ele disparará um alerta Com a aplicação modelada com a DSL, o especialista em redes efetua a atividade Escolher Plataforma e usa a infraestrutura MDA para fazer a 94

95 transformação M2M e gerar um modelo específico desta aplicação na plataforma escolhida (Sun SPOT). Por último, seriam realizados os refinamentos tanto no modelo específico de plataforma quanto no código gerado após a transformação M2T. Figura 5-2 Modelagem da aplicação Burning Forest com a DSL intermediária. Desta forma é possível perceber que com o ciclo de desenvolvimento de sistemas para RSASF utilizado é possível modelar outras aplicações, de diversos domínios, usando a mesma infraestrutura e reusando todos os artefatos reutilizáveis da infraestrutura MDA (DSL, PSMs, transformações M2M e transformações M2T). 95

96 SC4. Mudança da plataforma de RSASF. Em um cenário típico do ambiente RSASF, uma mesma aplicação posteriormente necessita ser executada em outra plataforma. Sem a utilização do ciclo de desenvolvimento e da infraestrutura propostos em [RODRIGUES, 2011], o código completo da aplicação precisaria ser reescrito a partir do zero. Ao utilizar tal ciclo de desenvolvimento exige-se, apenas, a construção das transformações M2M e M2T de acordo com a plataforma requerida. Após a realização destas atividades, as únicas etapas exigidas para se reusar a especificação da aplicação para essa nova plataforma são: selecionar a transformação M2M que transforma modelos da DSL para a plataforma desejada a fim de gerar um modelo de aplicação, realizando qualquer refinamento exigido no modelo gerado e, em seguida, aplicar a transformação M2T correspondente (e refinar o código gerado) LWiSSy Inicialmente, uma análise comparativa entre LWiSSy e as DSLs propostas por [LOSILLA, 2007] e por [SHIMIZU, 2011] foi efetuada a fim de determinar o poder de expressividade das três DSLs com relação à capacidade de otimização (refinamento), separação de interesses (diferentes perfis de desenvolvedor envolvidos), modelagem comportamental e estrutural do sistema, e programação da rede considerando diferentes níveis de granularidade. Logo após, um experimento controlado foi conduzido para analisar o impacto da utilização de LWiSSy com relação à eficácia da linguagem em facilitar a compreensão e manutenção de sistemas de RSASF Análise Comparativa Esta Seção efetua uma análise comparativa entre LWiSSy e as DSLs propostas por [LOSILLA, 2007] e [SHIMIZU, 2011]. Para realizar esta comparação, o mesmo sistema para RSASF foi modelado com as três DSLs e, por fim, uma análise entre os modelos gerados foi efetuada para avaliar o poder de 96

97 expressividade das três DSLs com relação à capacidade de otimização (refinamento), separação de interesses (diferentes perfis de desenvolvedor envolvidos), modelagem comportamental e estrutural do sistema, e programação da rede considerando diferentes níveis de granularidade. O sistema modelado pertence ao domínio de AAL (Ambient Assisted Living) [DELICATO, 2009]. Sistemas AAL visam prover suporte não intrusivo às tarefas diárias das pessoas com o objetivo de garantir uma maior qualidade de vida aos indivíduos. A ideia básica é monitorar algumas variáveis presentes tanto no ambiente onde o indivíduo se localiza quanto no próprio indivíduo, a fim de garantir uma assistência rápida, automatizada e eficiente em situações de emergência. Nesse contexto, um cenário baseado em um sistema para detecção de quedas acidentais foi escolhido para a modelagem utilizando as DSLs supramencionadas Descrição do sistema O sistema AAL modelado, nomeado Accidental Fall Detection System, monitora um indivíduo e avalia informações coletadas por sensores a fim de analisar variáveis que permitam detectar a ocorrência de uma possível queda. Para que seja possível efetuar esta análise é preciso obter dados a respeito da localização na qual o indivíduo se encontra, dos seus sinais corporais, de movimentos bruscos que ele possa ter realizado e do tempo em que ele permanece em uma mesma posição. Caso uma queda seja detectada, ações como enviar um alerta para o serviço de emergência e iniciar o monitoramento dos sinais vitais são disparadas. A fim de possibilitar a detecção de quedas, o ambiente deve estar equipado com nós sensores capazes de capturar tais informações e com nós atuadores capazes de efetuar uma chamada para o hospital ou um centro de saúde sempre que uma queda ocorrer. Além disso, os nós devem, por exemplo, realizar uma análise dos dados recebidos por meio da execução de algoritmos de processamento de imagem. Considerando tais 97

98 requisitos, a RSASF para o sistema AAL aqui descrito será composta de um nó sensor (equipado de acelerômetros) presente em um crachá e acoplado ao indivíduo monitorado, três sensores de imagens (câmeras), três nós sensores fixos (equipados com sensores de localização) e vários atuadores com diferentes funções. Com o intuito de analisar os dados obtidos, faz-se necessária a definição de uma estação central que será responsável pelo processamento da informação recebida a fim de detectar a queda. O sistema de RSASF para o cenário descrito funciona da seguinte maneira. Sensores instalados em uma parede formam a triangulação da posição do indivíduo monitorado utilizando sinais de RSSI (received signal strength indication) e podem detectar qualquer mudança na posição do mesmo. Enquanto isso, o nó sensor instalado no crachá detecta movimentos bruscos e determina se o indivíduo está parado ou em movimento. Os dados capturados são então enviados para a central de controle. Se o indivíduo efetuar um movimento atípico, a central envia um sinal para que nós atuadores liguem as câmeras. Feito isto, a central recebe as imagens da sala e efetua um processamento com o objetivo de descobrir se o indivíduo está apenas caminhando ou se ele está em queda. No caso de detecção de queda, a central entra em contato com um hospital ou serviço de emergência através de um nó atuador Modelagem do sistema utilizando diferentes DSLs A primeira DSL utilizada para modelagem do sistema descrito foi LWiSSy. No modelo estrutural, definido pelo especialista de domínio (Figura 5-3), o sistema foi dividido em três regiões. A região UserLocationRegion é formada pelos grupos de nós BadgeGroup e MovementGroup, que são responsáveis pela coleta de dados do ambiente e do indivíduo, respectivamente. Por sua vez, a região UserVideoRegion é composta pelo grupo de nós VideoGroup, o qual gerencia as câmeras presentes no ambiente. Por fim, a região CentralStationRegion também é composta por apenas um grupo de nós, ProcessingGroup, o qual é responsável 98

99 pelo processamento dos dados coletados para detecção da queda e gerenciamento dos atuadores presentes na rede. Além disso, ainda foram definidos os tipos de recursos que serão utilizados em cada grupo de nós (movementsensor, positionsensor, etc.), a quantidade de nós presente em cada um dos grupos de nós, as conexões existentes na rede e as aplicações que serão executadas pelo sistema. Figura 5-3 Modelagem estrutural do sistema Accidental Fall Detection System utilizando a DSL LWiSSy. Após a definição do modelo estrutural, o especialista de domínio efetuou a modelagem comportamental de cada uma das quatro aplicações que compõem o sistema, a saber, Position Sensing, Movement Sensing, Video Check e Fall Check. A aplicação Position Sensing (Figura 5-4) é responsável pela coleta de dados sobre a posição do indivíduo no ambiente monitorado. Esta aplicação é composta por três atividades. Na primeira atividade, ConfigurateRadio, o rádio do nó sensor desta aplicação é configurado. Feito isto, os dados são coletados a partir dos nós sensores instalados no crachá do indivíduo, através da atividade ReadPositionData, a fim de definir qual a posição atual do mesmo no ambiente. 99

100 Após a coleta dos dados, estes são enviados a estação central a cada 20 minutos por meio da atividade SendGatheredData. Ao término do envio dos dados, a aplicação voltará a executar a segunda tarefa. Figura 5-4 Modelagem comportamental da aplicação Position Sensing utilizando a DSL LWiSSy. A aplicação Movement Sensing (Figura 5-5) é responsável pela coleta de dados sobre a movimentação do indivíduo no ambiente monitorado. Esta aplicação assemelha-se muito com a aplicação Position Sensing uma vez que o fluxo computacional será o mesmo; a única mudança diz respeito aos dados coletados a partir do ambiente. Nesta aplicação os dados são coletados a partir dos nós sensores instalados na parede com o intuito de analisar a movimentação do indivíduo pelo ambiente. Portanto, a única atividade que difere das apresentadas no modelo anterior é a atividade de leitura dos dados dos sensores, a qual neste modelo é nomeada de ReadMovementData e efetua a leitura dos dados dos nós sensores acima descritos. 100

101 Figura 5-5 Modelagem comportamental da aplicação Movement Sensing utilizando a DSL LWiSSy. A aplicação Video Check (Figura 5-6), a qual é iniciada a partir de uma solicitação da estação central apenas se uma possibilidade de queda for detectada, liga as câmeras de vídeo e envia as imagens coletadas à estação central. O modelo comportamental desta aplicação é composto por quatro atividades. A primeira atividade, ConfigurateRadio, configura os rádios dos nós presentes na aplicação. Logo após, as imagens coletadas pelas câmeras são lidas pelos nós sensores presentes na rede (atividade ReadCameraData) e enviadas a estação base (atividade SendGatheredData). Figura 5-6 Modelagem comportamental da aplicação Video Check utilizando a DSL LWiSSy. A última aplicação a ser modelada é a aplicação Fall Check (Figura 5-7). Esta aplicação deve ser implantada na estação central. Inicialmente, o rádio dos nós pertencentes à aplicação são configurados (atividade ConfigurateRadio). Feito 101

102 isto, os dados sobre a movimentação e posição do indivíduo no ambiente são recebidos (atividades ReceiveMovementData e ReceivePostionData, respectivamente), um processamento a fim de determinar se há possibilidade de queda é efetuado (atividade AnalyzeFall) e, caso haja, as câmeras de vídeo do ambiente são disparadas (atividade TurnOnCameras) e os dados coletados pelas câmeras são recebidos pela estação central (atividade ReceiveCameraData) para que uma nova análise seja efetuada a fim de detectar se realmente ocorreu uma queda (atividade AnalyzeImages). Caso a queda tenha de fato acontecido, a aplicação aciona um hospital ou serviço de emergência (atividade CallToEmergency), desliga as câmeras (atividade TurnOffCameras), uma vez que as imagens que registraram a queda já foram obtidas, e aguarda trinta minutos para começar a receber dados do ambiente novamente. Figura 5-7 Modelagem comportamental da aplicação Fall Check utilizando a DSL LWiSSy. 102

103 Para finalizar a modelagem do sistema AAL com a DSL LWiSSy, o especialista de redes efetuou a modelagem de refinamento do sistema, conforme mostrado na Figura 5-8. Durante esta modelagem, foram definidos a topologia da rede (FLAT) e o protocolo de comunicação utilizado (FLOODING). Além disso, foram determinados quais os tipos de nós sensores utilizados (neste caso, todos os grupos utilizam nós da plataforma Sun SPOT [Sun SPOT, 2012]), bem como os demais protocolos da rede. Figura 5-8 Modelagem de refinamento do sistema Accident Fall Detection System utilizando a DSL LWiSSy. A próxima modelagem do sistema AAL que será descrita (Figura 5-9) foi projetada com a DSL proposta por [LOSILLA, 2007]. Assim como ocorre em LWiSSy, a DSL de Losilla é composta pelos elementos região e grupo de nós. Dessa forma, as mesmas regiões que foram definidas com o uso de LWiSSy também foram definidas neste modelo, sendo elas: UserLocationRegion, UserVideoRegion e CentralStationRegion. A primeira região a ser descrita será a UserLocationRegion. Ela é composta por dois elementos do tipo NodeGroup: MovementGroup e BadgeGroup. No elemento MovementGroup são definidos dois fluxos comportamentais. O primeiro fluxo executa a coleta de dados acerca dos movimentos efetuados pelo indivíduo no ambiente monitorado pela rede (Functional Unit 103

104 ReadMovementData) e armazena-os em sua memória RAM (Functional Unit StoreRAM1). A inserção de um componente Timer (externally fired) com o range de 20 minutos indica a inclusão de um timer do tipo one shot neste fluxo, ou seja, este timer será considerado apenas durante a primeira execução do fluxo comportamental. O segundo fluxo modelado neste grupo de nós é responsável por recuperar os dados coletados pelos nós sensores a partir da memória RAM (Functional Unit RetrieveRAM1) e enviá-los a estação central por meio da Functional Unit SendGatheredData. Assim como no fluxo anterior, um elemento Timer foi definido, mas o timer presente neste fluxo é cíclico e, portanto, sempre será considerado ao longo da execução deste fluxo. Figura 5-9 Modelagem do sistema Accidental Fall Detection utilizando a DSL proposta por [LOSILLA, 2007]. O segundo NodeGroup presente nesta região, BadgeGroup, possui fluxos comportamentais semelhantes aos modelados no NodeGroup anterior. No 104

Redes de Computadores sem Fio

Redes de Computadores sem Fio Redes de Computadores sem Fio Prof. Marcelo Gonçalves Rubinstein Programa de Pós-Graduação em Engenharia Eletrônica Faculdade de Engenharia Universidade do Estado do Rio de Janeiro Programa Introdução

Leia mais

Abordagem Dirigida a Modelos para Redes de Sensores sem Fio

Abordagem Dirigida a Modelos para Redes de Sensores sem Fio UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO DISSERTAÇÃO DE MESTRADO

Leia mais

Using MDA for Building Wireless Sensor Network Applications

Using MDA for Building Wireless Sensor Network Applications Using MDA for Building Wireless Sensor Network Applications Taniro C. Rodrigues, Priscilla V. Dantas, Flávia C. Delicato, Paulo F. Pires DIMAp - Universidade Federal do Rio Grande do Norte {tanirocr, pridnt,

Leia mais

Redes de Sensores sem Fio: um levantamento *

Redes de Sensores sem Fio: um levantamento * Redes de Sensores sem Fio: um levantamento * Douglas Machado Monteiro 1, Francisco Tiago Avelar 1 1 Curso de Ciência da Computação Universidade Federal de Santa Maria (UFSM) {avelar, douglas}@inf.ufsm.br

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

Autores: Ruy de Oliveira Wendell Farias 2014 1

Autores: Ruy de Oliveira Wendell Farias 2014 1 Autores: Ruy de Oliveira Wendell Farias 2014 1 Tópicos Introdução às Redes de Sensores Sem Fio RSSF Modos de funcionamento Principais aplicações dessas redes Desafios Considerações Finais Demonstrações

Leia mais

Programação para Dispositivos Móveis. Prof. Wallace Borges Cristo

Programação para Dispositivos Móveis. Prof. Wallace Borges Cristo Programação para Dispositivos Móveis Prof. Wallace Borges Cristo Acesso a informação Notícias, Ringtones, Vídeos Messenger/Chat Jogos Acesso a instituições financeiras M-commerce (Mobile Commerce) Aplicações

Leia mais

Ferramentas Web para controle e supervisão: o que está por vir

Ferramentas Web para controle e supervisão: o que está por vir Artigos Técnicos Ferramentas Web para controle e supervisão: o que está por vir Marcelo Salvador, Diretor de Negócios da Elipse Software Ltda. Já faz algum tempo que ouvimos falar do controle e supervisão

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

Projetos I Resumo de TCC. Luiz Rogério Batista De Pieri Mat: 0413829 5

Projetos I Resumo de TCC. Luiz Rogério Batista De Pieri Mat: 0413829 5 Projetos I Resumo de TCC Luiz Rogério Batista De Pieri Mat: 0413829 5 MAD RSSF: Uma Infra estrutura de Monitoração Integrando Redes de Sensores Ad Hoc e uma Configuração de Cluster Computacional (Denise

Leia mais

MC714 - Sistemas Distribuídos. Leandro Villas

MC714 - Sistemas Distribuídos. Leandro Villas MC714 - Sistemas Distribuídos Aula de Hoje Aula Passada Nomeação Aula de Hoje Introdução ao problema de sincronização Relógios Físicos Algoritmos de Sincronização Sincronização de Relógios em Redes sem

Leia mais

Introdução a computação móvel. Middlewares para Rede de Sensores sem Fio. Uma avaliação na ótica de Adaptação ao Contexto

Introdução a computação móvel. Middlewares para Rede de Sensores sem Fio. Uma avaliação na ótica de Adaptação ao Contexto Introdução a computação móvel Monografia: Middlewares para Rede de Sensores sem Fio Uma avaliação na ótica de Adaptação ao Contexto Adriano Branco Agenda Objetivo do trabalho O que é uma WSN Middlewares

Leia mais

Projeto de controle e Automação de Antena

Projeto de controle e Automação de Antena Projeto de controle e Automação de Antena Wallyson Ferreira Resumo expandido de Iniciação Tecnológica PUC-Campinas RA: 13015375 Lattes: K4894092P0 wallysonbueno@gmail.com Omar C. Branquinho Sistemas de

Leia mais

Suporte à Engenharia Reversa para o ambiente SEA

Suporte à Engenharia Reversa para o ambiente SEA Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis

Leia mais

Há dois tipos de configurações bidirecionais usados na comunicação em uma rede Ethernet:

Há dois tipos de configurações bidirecionais usados na comunicação em uma rede Ethernet: Comunicação em uma rede Ethernet A comunicação em uma rede local comutada ocorre de três formas: unicast, broadcast e multicast: -Unicast: Comunicação na qual um quadro é enviado de um host e endereçado

Leia mais

Administração de Sistemas de Informação Gerenciais

Administração de Sistemas de Informação Gerenciais Administração de Sistemas de Informação Gerenciais UNIDADE V: Telecomunicações, Internet e Tecnologia Sem Fio. Tendências em Redes e Comunicações No passado, haviam dois tipos de redes: telefônicas e redes

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Capítulo 8 Arquitetura de Computadores Paralelos

Capítulo 8 Arquitetura de Computadores Paralelos Capítulo 8 Arquitetura de Computadores Paralelos Necessidade de máquinas com alta capacidade de computação Aumento do clock => alta dissipação de calor Velocidade limitada dos circuitos => velocidade da

Leia mais

Sistemas distribuídos:comunicação

Sistemas distribuídos:comunicação M. G. Santos marcela@estacio.edu.br Faculdade Câmara Cascudo - Estácio de Sá 16 de abril de 2010 Formas de comunicação Produtor-consumidor: comunicação uni-direccional, com o produtor entregando ao consumidor.

Leia mais

ANÁLISE DE REDES HIERÁRQUICAS PARA ATENDIMENTO DE LOCAIS REMOTOS

ANÁLISE DE REDES HIERÁRQUICAS PARA ATENDIMENTO DE LOCAIS REMOTOS ANÁLISE DE REDES HIERÁRQUICAS PARA ATENDIMENTO DE LOCAIS REMOTOS Fabiana da Silva Podeleski Faculdade de Engenharia Elétrica CEATEC podeleski@yahoo.com.br Prof. Dr. Omar Carvalho Branquinho Grupo de Pesquisa

Leia mais

ListenU uma Ferramenta para Monitoramento Ambiental Usando Redes de Sensores Sem Fio

ListenU uma Ferramenta para Monitoramento Ambiental Usando Redes de Sensores Sem Fio XIV Semana de Informática SEMINF, 12 a 15 de Abril de 2011 ListenU uma Ferramenta para Monitoramento Ambiental Usando Redes de Sensores Sem Fio Ilan Sousa 1, 2, Lauro Américo 1,2, Lilian Freitas 1,2, Aldebaro

Leia mais

IW10. Rev.: 02. Especificações Técnicas

IW10. Rev.: 02. Especificações Técnicas IW10 Rev.: 02 Especificações Técnicas Sumário 1. INTRODUÇÃO... 1 2. COMPOSIÇÃO DO IW10... 2 2.1 Placa Principal... 2 2.2 Módulos de Sensores... 5 3. APLICAÇÕES... 6 3.1 Monitoramento Local... 7 3.2 Monitoramento

Leia mais

Alessandro F. Cunha O que são sistemas embarcados?

Alessandro F. Cunha O que são sistemas embarcados? Alessandro F. Cunha O que são sistemas embarcados? 1. Introdução Alguma vez você já se deu conta que o microondas de sua casa tem uma capacidade computacional maior do que tinha o projeto Apolo, que levou

Leia mais

Sistemas Operacionais

Sistemas Operacionais UNIVERSIDADE BANDEIRANTE DE SÃO PAULO INSTITUTO POLITÉCNICO CURSO DE SISTEMAS DE INFORMAÇÃO Sistemas Operacionais Notas de Aulas: Tópicos 7 e 8 Estrutura do Sistema Operacional São Paulo 2009 1 Sumário

Leia mais

Capítulo VI Telecomunicações: Redes e Aplicativos

Capítulo VI Telecomunicações: Redes e Aplicativos Capítulo VI Telecomunicações: Redes e Aplicativos Uma rede nada mais é do que máquinas que se comunicam. Estas máquinas podem ser computadores, impressoras, telefones, aparelhos de fax, etc. Se interligarmos

Leia mais

Evolução na Comunicação de

Evolução na Comunicação de Evolução na Comunicação de Dados Invenção do telégrafo em 1838 Código Morse. 1º Telégrafo Código Morse Evolução na Comunicação de Dados A evolução da comunicação através de sinais elétricos deu origem

Leia mais

Desenvolvimento de um Framework de Jogos 3D para Celulares

Desenvolvimento de um Framework de Jogos 3D para Celulares Desenvolvimento de um Framework de Jogos 3D para Celulares Fabrício Brasiliense Departamento de Informática e Estatística(INE) Universidade Federal de Santa Catarina (UFSC) Campus Universitário Trindade-

Leia mais

4 Computação Paralela 4.1. Introdução

4 Computação Paralela 4.1. Introdução 4 Computação Paralela 4.1. Introdução Nos últimos anos observa-se uma tendência cada vez maior do aumento da demanda computacional na resolução de grandes problemas. Exemplos de aplicações que exigem alto

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN SISTEMAS OPERACIONAIS Apostila 03 Estrutura do Sistema Operacional UNIBAN 1.0 O Sistema Operacional como uma Máquina Virtual A arquitetura (conjunto de instruções, organização de memória, E/S e estrutura

Leia mais

Introdução sobre à porta USB

Introdução sobre à porta USB Introdução sobre à porta USB O USB (Universal Serial Bus) surgiu em 1995 com uma parceria entre várias companhias de alta tecnologia (Compaq, Hewlett-Packard, Intel, Lucent, Microsoft, NEC e Philips).

Leia mais

S.T.A.I. (SERVIÇOS TÉCNICOS DE AUTOMAÇÃO INDUSTRIAL) REDE PROFIBUS PA ALISSON TELES RIBEIRO

S.T.A.I. (SERVIÇOS TÉCNICOS DE AUTOMAÇÃO INDUSTRIAL) REDE PROFIBUS PA ALISSON TELES RIBEIRO g S.T.A.I. (SERVIÇOS TÉCNICOS DE AUTOMAÇÃO INDUSTRIAL) REDE PROFIBUS PA ALISSON TELES RIBEIRO SUMÁRIO 1. Objetivo 2. História 3. O Que é Profibus? 4. Profibus PA 5. Instrumentos 6. Bibliografia 1. OBJETIVO

Leia mais

Tipos de Sistemas Distribuídos

Tipos de Sistemas Distribuídos (Sistemas de Informação Distribuída e Pervasivos) Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência

Leia mais

Prof. Manuel A Rendón M

Prof. Manuel A Rendón M Prof. Manuel A Rendón M Tanenbaum Redes de Computadores Cap. 1 e 2 5ª. Edição Pearson Padronização de sistemas abertos à comunicação Modelo de Referência para Interconexão de Sistemas Abertos RM OSI Uma

Leia mais

J2ME PLATAFORMA DE DESENVOLVIMENTO JAVA PARA DISPOSITIVOS MÓVEIS

J2ME PLATAFORMA DE DESENVOLVIMENTO JAVA PARA DISPOSITIVOS MÓVEIS J2ME PLATAFORMA DE DESENVOLVIMENTO JAVA PARA DISPOSITIVOS MÓVEIS Ana Paula Carrion 1, Késsia Rita da Costa Marchi 1, Jaime Willian Dias 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil anapaulacarrion@hotmail.com,

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

William Stallings Arquitetura e Organização de Computadores 8 a Edição

William Stallings Arquitetura e Organização de Computadores 8 a Edição William Stallings Arquitetura e Organização de Computadores 8 a Edição Capítulo 7 Entrada/saída Os textos nestas caixas foram adicionados pelo Prof. Joubert slide 1 Problemas de entrada/saída Grande variedade

Leia mais

SOS: Sensoriamento Overlay Seguro em Redes de Sensores Sem Fio Hierárquicas

SOS: Sensoriamento Overlay Seguro em Redes de Sensores Sem Fio Hierárquicas SOS: Sensoriamento Overlay Seguro em Redes de Sensores Sem Fio Hierárquicas Leonardo B. Oliveira, A.A.F. Loureiro, Ricardo Dahab, Hao Chi Wong UNICAMP, UFMG, PARC Agenda Introdução Solução Simulação Resultados

Leia mais

OpenFlow: abrindo portas para inovações nas redes de nossos campi

OpenFlow: abrindo portas para inovações nas redes de nossos campi 1 OpenFlow: abrindo portas para inovações nas redes de nossos campi Leandro Haruo Aoyagi Universidade Federal de São Carlos, Campus Sorocaba Sorocaba, São Paulo Email: aoyagi.haruo@gmail.com Resumo A comunidade

Leia mais

CONSTRUÇÃO DE VEÍCULO MECATRÔNICO COMANDADO REMOTAMENTE

CONSTRUÇÃO DE VEÍCULO MECATRÔNICO COMANDADO REMOTAMENTE CONSTRUÇÃO DE VEÍCULO MECATRÔNICO COMANDADO REMOTAMENTE Roland Yuri Schreiber 1 ; Tiago Andrade Camacho 2 ; Tiago Boechel 3 ; Vinicio Alexandre Bogo Nagel 4 INTRODUÇÃO Nos últimos anos, a área de Sistemas

Leia mais

5 Sistema Experimental

5 Sistema Experimental 5 Sistema Experimental Este capitulo apresenta o sistema experimental utilizado e é composto das seguintes seções: - 5.1 Robô ER1: Descreve o robô utilizado. É dividida nas seguintes subseções: - 5.1.1

Leia mais

ATIVIDADE 1. Definição de redes de computadores

ATIVIDADE 1. Definição de redes de computadores ATIVIDADE 1 Definição de redes de computadores As redes de computadores são criadas para permitir a troca de dados entre diversos dispositivos estações de trabalho, impressoras, redes externas etc. dentro

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 1- MODELO DE CAMADAS 1. INTRODUÇÃO A compreensão da arquitetura de redes de computadores envolve a compreensão do modelo de camadas. O desenvolvimento de uma arquitetura de redes é uma tarefa complexa,

Leia mais

FICHA DE CURSO. 1. Designação do Curso: 2. Denominação do Diploma ou Certificado. 3. Objectivos Gerais e Enquadramento: 4.

FICHA DE CURSO. 1. Designação do Curso: 2. Denominação do Diploma ou Certificado. 3. Objectivos Gerais e Enquadramento: 4. 1. Designação do Curso: Curso de Especialização Pós-Graduada em Computação Móvel Aplicada 2. Denominação do Diploma ou Certificado Diploma de Pós-Graduação em Computação Móvel Aplicada 3. Gerais e Enquadramento:

Leia mais

FAdC i Frauscher Advanced Counter i

FAdC i Frauscher Advanced Counter i FAdC i Frauscher Advanced Counter i PT FAdC i FRAUSCHER Advanced Counter i Detecção de via livre para requisitos especiais O FAdCi é uma variante especialmente econômica da mais nova geração de contagem

Leia mais

Marcus Vinicius Cruz Xavier. Rascunho do trabalho de conclusão de curso

Marcus Vinicius Cruz Xavier. Rascunho do trabalho de conclusão de curso Universidade Federal de Santa Catarina Departamento de Informática e Estatística Curso de Bacharelado em Ciências da Computação Marcus Vinicius Cruz Xavier Rascunho do trabalho de conclusão de curso Título

Leia mais

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

Leia mais

Estrutura de um Rede de Comunicações. Redes e Sistemas Distribuídos. Tarefas realizadas pelo sistema de comunicação. Redes de comunicação de dados

Estrutura de um Rede de Comunicações. Redes e Sistemas Distribuídos. Tarefas realizadas pelo sistema de comunicação. Redes de comunicação de dados Estrutura de um Rede de Comunicações Profa.. Cristina Moreira Nunes Tarefas realizadas pelo sistema de comunicação Utilização do sistema de transmissão Geração de sinal Sincronização Formatação das mensagens

Leia mais

Transformação de modelos em processos de desenvolvimento de software

Transformação de modelos em processos de desenvolvimento de software 1068 X Salão de Iniciação Científica PUCRS Transformação de modelos em processos de desenvolvimento de software Vinycio de Correa Lunelli 1, Profa. Dra. Ana Paula Terra Bacelo 1 1 Faculdade de Informática,

Leia mais

Gerenciamento de Redes

Gerenciamento de Redes Gerenciamento de Redes As redes de computadores atuais são compostas por uma grande variedade de dispositivos que devem se comunicar e compartilhar recursos. Na maioria dos casos, a eficiência dos serviços

Leia mais

Projeto de Múltiplas RSSF operando sobre. Fibra óptica

Projeto de Múltiplas RSSF operando sobre. Fibra óptica Anais do XIX Encontro de Iniciação Científica ISSN 1980178 Projeto de Múltiplas RSSF operando sobre Maria Caroline de Andrade PUC-Campinas Centro de Ciências Exatas, Ambientais e de Tecnologias maria.ca@puccampinas.edu.br

Leia mais

UNIVERSIDADE FEDERAL DE VIÇOSA CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS DEPARTAMENTO DE INFORMÁTICA. Pizzaria Manão

UNIVERSIDADE FEDERAL DE VIÇOSA CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS DEPARTAMENTO DE INFORMÁTICA. Pizzaria Manão UNIVERSIDADE FEDERAL DE VIÇOSA CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS DEPARTAMENTO DE INFORMÁTICA Pizzaria Manão Emilio Gonçalves 41281 Fabrício Luís Santos da Silva 50293 Filipe Ribeiro Nalon 50295

Leia mais

Exercícios Rede de Computadores I (27/05/2006)

Exercícios Rede de Computadores I (27/05/2006) UNIVERSIDADE FEDERAL DE VIÇOSA CENTRO DE CIÊNCIAS EXATAS E TECNOLOGICAS DEPARTAMENTO DE INFORMÁTICA Exercícios Rede de Computadores I (27/05/2006) Marcelo Santos Daibert Juiz de Fora Minas Gerais Brasil

Leia mais

Introdução à Informática. Aula 04. Sistemas Operacionais Aplicativos e Utilitários Transmissão e meios de transmissão de dados. Prof.

Introdução à Informática. Aula 04. Sistemas Operacionais Aplicativos e Utilitários Transmissão e meios de transmissão de dados. Prof. Aula 04 Sistemas Operacionais Aplicativos e Utilitários Transmissão e meios de transmissão de dados Sistema Operacional Um conjunto de programas que se situa entre os softwares aplicativos e o hardware:

Leia mais

RASTREAMENTO VEICULAR SEGURANÇA & LOGÍSTICA. Funcionalidade Gerenciamento Equipamentos Comunicação Benefícios

RASTREAMENTO VEICULAR SEGURANÇA & LOGÍSTICA. Funcionalidade Gerenciamento Equipamentos Comunicação Benefícios RASTREAMENTO VEICULAR SEGURANÇA & LOGÍSTICA Funcionalidade Gerenciamento Equipamentos Comunicação Benefícios Soluções ICS A ICS desenvolve soluções que utilizam hardware com tecnologia de ponta. Os softwares

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

Protocolo MiWi (Tradução parcial)

Protocolo MiWi (Tradução parcial) Protocolo MiWi (Tradução parcial) INTRODUÇÃO Aplicações empregando redes sem fio são cada vez mais comuns. Existe uma grande expectativa de que dispositivos caseiros e/ou industriais possam se comunicar

Leia mais

DESENVOLVIMENTO DE UMA FERRAMENTA DIDÁTICA PARA GERENCIAMENTO DE REDES DE SENSORES SEM FIO ZIGBEE

DESENVOLVIMENTO DE UMA FERRAMENTA DIDÁTICA PARA GERENCIAMENTO DE REDES DE SENSORES SEM FIO ZIGBEE DESENVOLVIMENTO DE UMA FERRAMENTA DIDÁTICA PARA GERENCIAMENTO DE REDES DE SENSORES SEM FIO ZIGBEE Cássia C. Silva cassia.silva@cba.ifmt.edu.br Ruy de Oliveira Ruy@cba.ifmt.edu.br Valtemir E. Nascimento

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Hardware Sistema de Entrada/Saída Visão Geral Princípios de Hardware Dispositivos de E/S Estrutura Típica do Barramento de um PC Interrupções

Leia mais

Sensor Data Streams. Redes de Sensores Sem Fio. Helen Peters de Assunção Jeferson Moreira dos Anjos

Sensor Data Streams. Redes de Sensores Sem Fio. Helen Peters de Assunção Jeferson Moreira dos Anjos Sensor Data Streams Redes de Sensores Sem Fio Helen Peters de Assunção Jeferson Moreira dos Anjos Data Stream Systems Nova classe de aplicações: Dados chegando rapidamente, em intervalos variáveis e com

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO Contribuições do MDA para o desenvolvimento de software Anna Carla Mohr Verner Helder Eugenio dos Santos Puia Florianópolis,

Leia mais

Rodrigo Teles Hermeto 1,Elias Teodoro da Silva Junior 2

Rodrigo Teles Hermeto 1,Elias Teodoro da Silva Junior 2 Criação e organização de agrupamentos utilizando um algoritmo centralizado de atribuição de identificadores para redes de sensores sem fio hierárquicas Rodrigo Teles Hermeto 1,Elias Teodoro da Silva Junior

Leia mais

A Camada de Rede. A Camada de Rede

A Camada de Rede. A Camada de Rede Revisão Parte 5 2011 Modelo de Referência TCP/IP Camada de Aplicação Camada de Transporte Camada de Rede Camada de Enlace de Dados Camada de Física Funções Principais 1. Prestar serviços à Camada de Transporte.

Leia mais

Protocolo de comunicação para redes móveis aplicado ao trânsito

Protocolo de comunicação para redes móveis aplicado ao trânsito Universidade Federal de Ouro Preto - UFOP Instituto de Ciências Exatas e Biológicas - ICEB Departamento de Computação - DECOM Protocolo de comunicação para redes móveis aplicado ao trânsito Aluno: Luiz

Leia mais

Arquitetura TCP/IP. Parte III Endereçamento IP e roteamento. Fabrízzio Alphonsus A. M. N. Soares

Arquitetura TCP/IP. Parte III Endereçamento IP e roteamento. Fabrízzio Alphonsus A. M. N. Soares Arquitetura TCP/IP Parte III Endereçamento IP e roteamento Fabrízzio Alphonsus A. M. N. Soares Tópicos Formato do endereço Classes de endereços Endereços especiais Sub-rede e máscara VLSM (Variable Length

Leia mais

Gerência de Redes e Serviços de Comunicação Multimídia

Gerência de Redes e Serviços de Comunicação Multimídia UNISUL 2013 / 1 Universidade do Sul de Santa Catarina Engenharia Elétrica - Telemática 1 Gerência de Redes e Serviços de Comunicação Multimídia Aula 3 Gerenciamento de Redes Cenário exemplo Detecção de

Leia mais

O que é uma rede industrial? Redes Industriais: Princípios de Funcionamento. Padrões. Padrões. Meios físicos de transmissão

O que é uma rede industrial? Redes Industriais: Princípios de Funcionamento. Padrões. Padrões. Meios físicos de transmissão O que é uma rede industrial? Redes Industriais: Princípios de Funcionamento Romeu Reginato Julho de 2007 Rede. Estrutura de comunicação digital que permite a troca de informações entre diferentes componentes/equipamentos

Leia mais

Tecnologia da Informação Apostila 02

Tecnologia da Informação Apostila 02 Parte 6 - Telecomunicações e Redes 1. Visão Geral dos Sistemas de Comunicações Comunicação => é a transmissão de um sinal, por um caminho, de um remetente para um destinatário. A mensagem (dados e informação)

Leia mais

Redes de Sensores Sem Fio

Redes de Sensores Sem Fio Disciplina 2º.semestre/2004 aula2 Redes de Sensores Sem Fio Antônio Alfredo Ferreira Loureiro loureiro@dcc.ufmg.br Depto. Ciência da Computação UFMG Linnyer Beatrys Ruiz linnyer@dcc.ufmg.br Depto. Engenharia

Leia mais

Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Emissor: Receptor: Meio de transmissão Sinal:

Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Emissor: Receptor: Meio de transmissão Sinal: Redes - Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Comunicação sempre foi, desde o início dos tempos, uma necessidade humana buscando aproximar comunidades distantes.

Leia mais

Tipos de Sistemas Distribuídos (Cluster e Grid)

Tipos de Sistemas Distribuídos (Cluster e Grid) Tipos de Sistemas Distribuídos (Cluster e Grid) Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência

Leia mais

FAdC Frauscher Advanced Counter

FAdC Frauscher Advanced Counter FAdC Frauscher Advanced Counter PT FAdC FRAUSCHER Advanced Counter A detecção de via livre do futuro O Frauscher Advanced Counter (FAdC) é a mais nova geração de sistemas de contagem de eixos com base

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 6 Estrutura de Sistemas Operacionais Prof.: Edilberto M. Silva http://www.edilms.eti.br Baseado no material disponibilizado por: SO - Prof. Edilberto Silva Prof. José Juan Espantoso

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

MONITORAMENTO RESIDENCIAL UTILIZANDO O ZABBIX E O PADRÃO IEEE 802.15.4 RESIDENTIAL MONITORING USING ZABBIX AND IEEE 802.15.

MONITORAMENTO RESIDENCIAL UTILIZANDO O ZABBIX E O PADRÃO IEEE 802.15.4 RESIDENTIAL MONITORING USING ZABBIX AND IEEE 802.15. MONITORAMENTO RESIDENCIAL UTILIZANDO O ZABBIX E O PADRÃO IEEE 802.15.4 W. ROMEIRO * e F. COSTA Instituto Federal de Ciências e Tecnologias do Rio Grande do Norte wr.romeiro@gmail.com * Artigo submetido

Leia mais

FACSENAC. Versão:1.5. Identificador do documento: Projeto Lógico de Redes. Versão do Template Utilizada na Confecção: 1.0. Histórico de revisões

FACSENAC. Versão:1.5. Identificador do documento: Projeto Lógico de Redes. Versão do Template Utilizada na Confecção: 1.0. Histórico de revisões FACSENAC ECOFROTA Documento de Projeto Lógico de Rede Versão:1.5 Data: 21/11/2013 Identificador do documento: Projeto Lógico de Redes Versão do Template Utilizada na Confecção: 1.0 Localização: FacSenac

Leia mais

4. Controlador Lógico Programável

4. Controlador Lógico Programável 4. Controlador Lógico Programável INTRODUÇÃO O Controlador Lógico Programável, ou simplesmente PLC (Programmiable Logic Controller), pode ser definido como um dispositivo de estado sólido - um Computador

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

Redes. Pablo Rodriguez de Almeida Gross

Redes. Pablo Rodriguez de Almeida Gross Redes Pablo Rodriguez de Almeida Gross Conceitos A seguir serão vistos conceitos básicos relacionados a redes de computadores. O que é uma rede? Uma rede é um conjunto de computadores interligados permitindo

Leia mais

Sistemas Operacionais Abertos. Prof. MSc. André Yoshimi Kusumoto andrekusumoto.unip@gmail.com

Sistemas Operacionais Abertos. Prof. MSc. André Yoshimi Kusumoto andrekusumoto.unip@gmail.com Sistemas Operacionais Abertos Prof. MSc. André Yoshimi Kusumoto andrekusumoto.unip@gmail.com Caracterização de Sistemas Distribuídos Coulouris, Dollimore and Kindberg. Distributed Systems: Concepts and

Leia mais

PRÓTOTIPO MÓVEL DE TELEMEDICINA PARA AUXILIO DE DIAGNOSTICO CARDIACO COM ECG EM CARATER EMERGENCIAL

PRÓTOTIPO MÓVEL DE TELEMEDICINA PARA AUXILIO DE DIAGNOSTICO CARDIACO COM ECG EM CARATER EMERGENCIAL PRÓTOTIPO MÓVEL DE TELEMEDICINA PARA AUXILIO DE DIAGNOSTICO CARDIACO COM ECG EM CARATER EMERGENCIAL Adson Diego Dionisio da SILVA 1, Saulo Soares de TOLEDO², Luiz Antonio Costa Corrêa FILHO³, Valderí Medeiros

Leia mais

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos Capítulo 8 Sistemas com Múltiplos Processadores 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos 1 Sistemas Multiprocessadores Necessidade contínua de computadores mais rápidos modelo

Leia mais

- Aula 1 - ARQUITETURA DE COMPUTADORES

- Aula 1 - ARQUITETURA DE COMPUTADORES - Aula 1 - ARQUITETURA DE COMPUTADORES Em arquitetura de computadores serão estudados aspectos da estrutura e do funcionamento dos computadores. O objetivo é apresentar de forma clara e abrangente a natureza

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Apresentação...3. Vantagens...3. Instalação...4. Informações Técnicas...5. Especificações Técnicas...9

Apresentação...3. Vantagens...3. Instalação...4. Informações Técnicas...5. Especificações Técnicas...9 1 ÍNDICE Apresentação...3 Vantagens...3 Instalação...4 Informações Técnicas...5 Especificações Técnicas...9 2 APRESENTAÇÃO: O SS100 Moto é um rastreador exclusivo para Motos desenvolvido com os mais rígidos

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula Complementar - MODELO DE REFERÊNCIA OSI Este modelo se baseia em uma proposta desenvolvida pela ISO (International Standards Organization) como um primeiro passo em direção a padronização dos protocolos

Leia mais

Características Básicas de Sistemas Distribuídos

Características Básicas de Sistemas Distribuídos Motivação Crescente dependência dos usuários aos sistemas: necessidade de partilhar dados e recursos entre utilizadores; porque os recursos estão naturalmente em máquinas diferentes. Demanda computacional

Leia mais

Arquitetura de uma Rede JXTA

Arquitetura de uma Rede JXTA Page 1 of 6 Redes de Proteção SP Produtos de Rede Confiança e credibilidade. fone Produtos TrendNet: qualidade, (011) 6197-0707 garantia e ótimo custo/benefício. www.tudoderedesdeprotecao.com.br http://www.trendware.com.br

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

Simplifique a complexidade do sistema

Simplifique a complexidade do sistema 1 2 Simplifique a complexidade do sistema Com o novo controlador de alto desempenho CompactRIO Rodrigo Schneiater Engenheiro de Vendas National Instruments Leonardo Lemes Engenheiro de Sistemas National

Leia mais

Thin Clients : aumentando o potencial dos sistemas SCADA

Thin Clients : aumentando o potencial dos sistemas SCADA Artigos Técnicos Thin Clients : aumentando o potencial dos sistemas SCADA Tarcísio Romero de Oliveira, Engenheiro de Vendas e Aplicações da Intellution/Aquarius Automação Industrial Ltda. Um diagnóstico

Leia mais

Metas de um Sistema Distribuído

Metas de um Sistema Distribuído Metas de um Sistema Distribuído Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do

Leia mais

Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software. Eduardo Barbosa da Costa

Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software. Eduardo Barbosa da Costa Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software Eduardo Barbosa da Costa Juiz de Fora, MG Julho de 2008 Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software

Leia mais

UNIVERSIDADE FEDERAL DE VIÇOSA DEPARTAMENTO DE INFORMÁTICA COMPUTAÇÃO MÓVEL CONTROLE DE GASTOS PARA ORÇAMENTO DOMÉSTICO

UNIVERSIDADE FEDERAL DE VIÇOSA DEPARTAMENTO DE INFORMÁTICA COMPUTAÇÃO MÓVEL CONTROLE DE GASTOS PARA ORÇAMENTO DOMÉSTICO UNIVERSIDADE FEDERAL DE VIÇOSA DEPARTAMENTO DE INFORMÁTICA COMPUTAÇÃO MÓVEL CONTROLE DE GASTOS PARA ORÇAMENTO DOMÉSTICO Fred Paulino Ferreira, Leonardo Couto, Renato Maia, Luiz G. Montanha Departamento

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Serviço de Controle e Programação para Dispositivos Remotos para Aplicações Interativas e Imersivas na TV Digital

Serviço de Controle e Programação para Dispositivos Remotos para Aplicações Interativas e Imersivas na TV Digital Serviço de Controle e Programação para Dispositivos Remotos para Aplicações Interativas e Imersivas na TV Digital Eduardo Agostinho¹, Victor Nogueira³, Samuel Azevedo³, Luiz Marcos Gonçalves³, Anelisa

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Faculdades SENAC Análise e Desenvolvimento de Sistemas 12 de agosto de 2010 Um sistema no qual componentes localizados em redes, se comunicam e coordenam suas ações somente por passagem de mensagens. Características:

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Objetos distribuídos e invocação remota Introdução Comunicação entre objetos distribuídos Chamada de procedimento remoto Eventos e notificações Objetos

Leia mais