A.G.C de Sá 1 ; B.A. de Mello 2 ; CEP: alexgcsa@gmail.com. bramlo@gmail.com

Transcrição

1 1 Geração automática de um modelo para simulação do SEP A.G.C de Sá 1 ; B.A. de Mello 2 ; 1 Departamento de Ciência da Computação UFLA Lavras, MG CEP: alexgcsa@gmail.com 2 Ciências da Computação UFFS Chapecó, SC bramlo@gmail.com Resumo. A construção de modelos de simulação pode apresentar um custo demasiadamente alto comprometendo o equilíbrio entre custo e benefício da simulação de sistemas. O reuso de componentes simuladores já existentes na composição de novos modelos pode contribuir com a redução do esforço de modelagem. Apesar disso, é necessário esforço para configurar a interface desses componentes selecionados separadamente para que possam cooperar entre si num único modelo de simulação. Este trabalho apresenta um módulo que facilita a construção dos arquivos de configuração de elementos para execução sobre a arquitetura DCB. O DCB (Distibuted Cosimulation Backbone) propõe técnicas de interoperabilidade de sistemas heterogêneos com a finalidade de facilitar e agilizar a detecção e correção de problemas de cooperação entre componentes (ou elementos) distintos de um sistema, sejam eles locais ou remotos. Cada elemento que compõe o modelo é cadastrado em um Gerenciador de Repositórios Distribuídos também desenvolvido para o DCB. O módulo de configuração automática está integrado a este ambiente. A relevância da configuração automática está na rapidez e na facilidade de projetar sistemas através de recursos computacionais, visto que diminui o esforço do projetista que desse modo não precisará compreender as estruturas internas do DCB para que possa configurar elementos e também reduz a quantidade de erros de modelagem. Isso favorece o projetista permitindo maior concentração em partes essenciais do modelo, como por exemplo, a sua fidelidade em relação ao sistema real. Palavras chaves: Configuração automática, Sistema, Elemento, DCB. 1 Apoio CNPq (bolsa PIBIC - UFLA) - Edital PRP No. 03/2009

2 1 INTRODUÇÃO O projeto de sistemas eletro-eletrônicos e mecânicos têm benefícios no uso de recursos computacionais para simular o comportamento de sistemas. O uso de técnicas de modelagem e simulação permite identificar e corrigir problemas, reduzir custos de produção, detectar falhas antes da construção de protótipos e no estudo de sistemas existentes. De acordo com os recursos utilizados para a construção, os modelos podem ser considerados homogêneos ou heterogêneos. Ao contrário de modelos homogêneos, modelos heterogêneos utilizam de modo combinado em um mesmo modelo, partes que se diferenciam em termos de linguagem de descrição, interface, ou modo de tratamento do tempo. Em geral é oneroso simular sistemas reais que demandam a composição de partes distintas para sua representação porque exigem esforço adicional na integração das partes para que a colaboração entre elas seja correta. Essa dificuldade também está ligada à dinamicidade, distribuição e/ou precisão do modelo esperado. A bibliografia apresenta estudos que propõem soluções de engenharia utilizando simulação. Em Zafalon e Lobato (2006), a High Level Architecture (HLA), IEEE (2000), é citada como ferramenta de modelagem e simulação para aplicações de controle de tráfego de uma cidade. Nele, semáforos, carros e qualquer componente de trânsito podem ser simulados através de recursos computacionais. Já em Lee at al. (2001), a simulação (termoenergética) computacional é utilizada para verificação e análise de soluções para a eficiência energética de edifícios diante de problemas de iluminação e uso de aparelhos que demandam grandes quantidades de energia. Porém, um dos desafios encontrados na construção de modelos está na correta comunicação entre componentes. O trabalho de tradução de interface para a comunicação de modelos heterogêneos não é simples. Com o objetivo de facilitar o trabalho de construção de modelos heterogêneos, o DCB, Mello et al. (2005), utilizado neste trabalho, faz uso de técnicas de cooperação entre elementos heterogêneos (e/ou distribuídos) de simulação buscando preservar a integridade do elemento. A idéia central do DCB é que o elemento fique independente do restante do modelo, comunicando-se apenas com seu gateway, Strassburger et al. (1998), e que não realize atividades que não competem a ele, por exemplo, a execução de ações remotas. A partir de seus métodos é possível passar a responsabilidade das tarefas de comunicação para os serviços internos do DCB. Outra vantagem do DCB é que este já tem suporte apropriado para gerenciamento de repositórios distribuídos de elementos, Mello e Parreiras (2009). Este trabalho apresenta a especificação e o desenvolvimento de um módulo cujo objetivo é automatizar o trabalho de configuração de modelos para execução local ou distribuída. O trabalho apresenta o uso deste módulo na construção de um modelo do SEP (Supervisor Eletrônico de Plantio). O SEP, Mello e Caimi (2008), têm como objetivo monitorar o trabalho de plantio em semeadoras disparando avisos quando um comportamento não desejado ocorre. O módulo de configuração automática foi construído para gerar os arquivos de configuração de elementos na construção de modelos para execução no DCB. Esse módulo utiliza dados cadastrados em um Repositório Distribuído de Elementos, Mello e Parreiras (2009), como fonte de informações para geração dos arquivos de configuração. O modelo do SEP apresentado neste trabalho detalha as etapas de construção do modelo identificando os benefícios do uso de recursos que permitam aumentar o nível de abstração do trabalho dos projetistas de modelos. 2 MATERIAIS E MÉTODOS 2.1 O DCB O DCB é uma plataforma de simulação que provê de recursos necessários para cooperação de elementos heterogêneos e/ou distribuídos. Todas suas atividades são

3 transparentes ao componente simulado pelo fato de que todas elas são realizadas respeitando políticas internas do próprio DCB. Quatro módulos principais são responsáveis pelo controle e realização de tarefas: o DCBS, o DCBR, o NDCB e o Gateway. O DCBS realiza tarefas de envio de mensagens para outros elementos do modelo. O DCBR decodifica/recebe mensagens advindas de elementos origem. Já o NDCB realiza atividades para manter a comunicação entre elementos, respeitando o tempo global do modelo. A necessidade da utilização do Gateway está na comunicação de interfaces distintas dos componentes. A Figura 1 apresenta a estrutura geral do DCB. O único módulo interno do DCB que executa operações remotas é o NDCB. Os demais realizam gerenciamento local para garantir a correta cooperação entre o elemento e o restante do modelo. Figura 1 Estrutura geral do DCB. 2.2 Gerenciador de Repositórios Distribuídos O ambiente de gerenciamento de repositórios distribuídos de elementos foi desenvolvido com o principal objetivo de localizar e gerenciar elementos para que possam ser reconhecidos e reutilizados em novos modelos. O gerenciador de repositórios permite agilizar a construção de modelos para execução na arquitetura do DCB, Mello e Parreiras (2009). Nessa ferramenta foram desenvolvidas várias funcionalidades tais como: cadastro de elementos (arquivos e informações) e usuários (administrador ou tradicional), consulta de elementos em nodos locais ou remotos, download de elementos registrados em nodos remotos, etc. Porém nesse trabalho restringiu-se ao uso do módulo de cadastro de elementos, como parte integrante da configuração. O cadastro de elementos permite ao usuário (projetista) futuramente localizar e selecionar elementos e utilizá-los na composição de modelos para simulação de sistemas reais. Embora a composição de elementos desenvolvidos a partir de requisitos diferentes possa exigir adaptações, facilidades no acesso aos elementos facilitam o trabalho do projetista. Amory et al. (2002) recomenda a preferência por elementos com código aberto para viabilizar a realização de alterações se necessário. O módulo de cadastro também está integrado ao Gerenciador de Repositórios Distribuídos e foi feito baseado na arquitetura do DCB. Foi preciso fazer modificações nesse módulo de cadastro, para que informações importantes fossem armazenadas e utilizadas posteriormente com precisão. Essas modificações estão incluídas principalmente no cadastro de atributos e no tipo de sincronia do elemento. O registro de um elemento tem diversas informações associadas a ele, tais como: porta de entrada, IP, atributos de entrada e de saída, tipo de sincronia, etc. A maior relevância dessas informações do elemento para a sua configuração está em seus atributos de entrada e de saída, porque a partir desses é possível fazer a troca de mensagens entre elementos para que esses possam cooperar. Para que o sistema seja modelado por completo, o que é recomendável é necessário que todos os elementos desse sistema sejam cadastrados no

4 Gerenciador de Repositórios Distribuídos. Desse modo a informações referentes aos elementos cadastrados estarão registradas em arquivos no formato XML, o que facilita o carregamento dessas informações para algum tipo de manipulação. Assim, com o controle desses dados, pode ser realizada a configuração automática dos elementos, respeitando os princípios de modelagem da arquitetura utilizada. 2.3 Construção do Módulo de Configuração Para a construção do módulo responsável pela configuração automática de componentes foi utilizada a linguagem de programação Java, justo que esse módulo foi integrado a uma ferramenta que foi feita utilizando essa linguagem. Também foi utilizado o ambiente NetBeans IDE para desenhar a interface gráfica e descrever os métodos que realizam a tarefa de configuração. Existem linguagens dedicadas à simulação, no entanto, a maioria dessas linguagens não tem a flexibilidade exigida pelo DCB, o que tornam seus recursos indesejáveis para construção do configurador em relação ao Java. O uso do padrão XML na geração automática do arquivo de configuração de elementos foi mantido porque o DCB implementa os métodos de configuração de modelos a partir de tags XML. 3 RESULTADOS E DISCUSSÃO Esta seção apresenta o módulo de configuração automática de elemento construído para gerar os arquivos de configuração necessários para a execução de modelos no DCB e o seu uso no projeto e construção de um modelo do SEP (Supervisor Eletrônico de Plantio). O SEP pode combinar elementos eletro-eletrônicos e mecânicos, o que torna a construção do modelo mais onerosa. 3.1 Módulo de Configuração O módulo de configuração permite o controle dos atributos de entrada e saída dos elementos cadastrados no (s) repositório (s) reconhecidos pelo Gerenciador de Repositórios Distribuídos, sejam eles remotos ou locais. Para que isso aconteça de forma transparente ao usuário (projetista) do modelo, uma interface amigável é proposta a fim de melhorar a integração desse usuário às tarefas do configurador. A Figura 2 mostra a interface de cadastro de atributos e de configuração de elementos do modelo SEP presentes no gerenciador de repositórios distribuídos. Para que um elemento possa ser utilizado pelo configurador automático, ele deve estar previamente cadastrado no banco de dados do repositório que utiliza persistência em XML. Na configuração do elemento, os seus dados são carregados e colocados em uma lista de atributos para que possam ser manipulados. Isso torna fácil o controle da origem dos atributos de entrada e do destino dos atributos de saída. Cada elemento é disponibilizado em uma janela independente facilitando a visualização dos atributos configurados. O módulo não verifica a correção da configuração.

5 Figura 2 Interface de cadastro de atributos e de configuração de um elemento. A tarefa de selecionar o atributo fonte e atributo destino pode ser feita repetidamente para que ocorra vinculação de atributos. O registro das informações de identificação (id) dos elementos destino é cadastrado no momento da vinculação. A janela que permite visualizar a configuração do elemento possui três colunas: a do atributo fonte ( atrib_fonte ), a do atributo destino ( atrib_dest ) e o id do elemento destino, que somente é válido se for um inteiro. Este método de configuração é bem distinto do ASDA Ambiente de Simulação Distribuída Automática, Bruschi e Santana (2002), que propõe um sub-módulo de especificação gráfica de modelos. Porém de modo similar, esse ambiente propõe afastar o usuário da tarefa de transcrição do modelo em um programa de simulação e também da análise estatística dos resultados, mostrando as informações da configuração em uma simples tabela. Feitas todas as vinculações dos atributos fonte (atributo de saída do elemento) e destino para qual o elemento enviará mensagens através de seus métodos (portas de comunicação), o elemento fonte pode ter sua identificação registrada em um campo da tela. Com a adição dos atributos de entrada do elemento e as vinculações de seus atributos de saída como parâmetros da configuração automática é possível fazê-la a partir delas seguindo um padrão de modelagem. No final da configuração, um arquivo de saída (Figura 3 Exemplo do Arquivo de Configuração de um Elemento) em um formato padrão XML é gerado para cada elemento. Entretanto, toda a modelagem da configuração depende apenas do usuário que está configurando. Ele precisa conhecer bem as características do sistema, entre elas: pra quem um elemento envia mensagens, seu id, seus atributos, os ids destinos, etc. Figura 3 Exemplo do Arquivo de Configuração de um Elemento. A Figura 3 mostra o arquivo de configuração resultante de um elemento exemplo. O arquivo é composto por tags, também chamada de rótulos ou marcas, que delimitam as

6 informações para a configuração. A composição é feita por tags dentro de tags, sendo que essas que definem as cooperações entre elementos e suas informações essenciais. A primeira é a CONFIG que é a tag principal (raiz) de configuração. O rótulo INFO informa todas as características do elemento, tal como identificação do elemento e da federação, número da porta e o tipo de sincronia utilizada. Outra informação presente em INFO está presente em ATRIBUTE, que é a descrição dos atributos de entrada e saída do elemento. Quando o elemento tem destino para atributos de outros elementos, a tag DESTINATION é necessária, enquanto para atributos de entrada essa última não deve estar presente. Por fim, a tag FEDERATION descreve elementos presentes no modelo proposto, ou seja, quais são a identificação do modelo e dos elementos que estão cooperantes e presentes nesse modelo tag FEDERATE. 3.2 Construção de um modelo do SEP Na segunda etapa do trabalho, um modelo de Supervisor Eletrônico de Plantio SEP (Figura 4) foi construído. O primeiro objetivo desta etapa foi demonstrar que o uso de modelos na representação de sistemas heterogêneos, mesmo combinando elementos reais e simulados, o que exige maior flexibilidade do ambiente de simulação, são úteis nas etapas de projeto de sistemas. O segundo objetivo foi validar a viabilidade da configuração automática de elementos. O SEP possui quatro elementos principais: a Semeadora, o Disco Alveolado, o Sensor de Passagem de Sementes e o Centro de Controle. Um controlador de Tempo Virtual Global (FedGVT) também é necessário para manutenção do tempo e é integrado ao modelo na forma de um elemento. Todos foram modelados utilizando-se a linguagem Java e em seguida cadastrados no Gerenciador de Repositórios Distribuídos. Numa segunda versão do modelo, o sensor de passagem foi substituído por um sensor real. As comunicações com os demais elementos simulados e os arquivos de configuração permaneceram inalteradas. A construção dos recursos necessários para a integração de elementos reais em modelos simulados foi realizada em um trabalho previamente desenvolvido, Chaves at al. (2009). Figura 4 Arquitetura do SEP. O elemento sensor é um conjunto de LEDs (Light-Emitting Diode) infravermelhos que detectam a passagem de sementes individualmente. A cada nova semente (passagem) detectada é gerado um pulso elétrico que incrementa um contador de sementes. Em Chaves at al. (2009) foi desenvolvido um módulo de software (driver) na linguagem C que

7 monitora a porta de comunicação com o elemento real e é responsável por traduzir os dados coletados para valores inteiros reconhecidos pela parte simulada do modelo. Uma controladora (hardware) é responsável por receber os sinais gerados pelos elementos e repassá-los ao módulo de software ou receber informações do driver e repassar os sinais corretos para os elementos. Como a controladora oferece, no lado do driver, uma interface reconfigurável para cooperação com o elemento real, o configurador automático desenvolvido neste trabalho pode ser utilizado sem alterações específicas para elementos reais. A cooperação é gerenciada por regras implementadas por um protocolo específico para integração de elementos reais a modelos simulados. Os arquivos de configuração gerados pelo configurador automático construído neste trabalho são válidos tanto para a versão totalmente virtual do modelo do SEP quanto para a versão que combina um elemento real com elementos simulados. Diante das várias configurações realizadas sobre a arquitetura do SEP, pode-se colocar em execução todos os componentes cadastrados, com suas características mais importantes e também incluindo todos os parâmetros essenciais. Foi mostrada nos testes realizados e de acordo com as configurações realizadas, a cooperação entre eles, sendo que a sincronização necessária para a troca de mensagens entre elementos foi completamente respeitada. Além disso, a partir das abordagens utilizadas no configurador, o código do elemento e o XML gerado com a configuração não foram modificados, respeitando-se assim, os princípios do DCB. 4 CONCLUSÕES Uma das tarefas mais importantes na construção de modelos de representação está na correta configuração de modelos. É dentro dessa configuração que serão descritas informações sobre elementos e como esses irão cooperar sobre a arquitetura utilizada. É nesse contexto que o configurador desenvolvido neste trabalho está incluído. Para que a configuração seja validada, um modelo de um Supervisor Eletrônico de Plantio SEP foi proposto. Com a construção do SEP foi possível verificar que a configuração automática torna o trabalho do projetista de sistemas mais rápido, fácil e preciso. Dentre as vantagens, torna-se desnecessário entender políticas internas do DCB e o padrão XML utilizado para a realização da configuração, o que reduz erros de modelagem e consumo de tempo. Entretanto, para que a configuração automática seguisse um padrão correto foi essencial a criação de algumas abordagens para resolver questões relacionadas ao projeto do configurador que são importantes principalmente para o projetista do sistema. Isso também foi encontrado quando o modelo SEP foi cadastrado no Gerenciador de Elementos Distribuídos. Exemplos dessas questões ou problemas encontrados são: como desenhar uma interface intuitiva para o usuário, como os dados serão representados nessa interface para que seja gerado o XML do elemento, o que escolher como ferramenta para gerar esse arquivo XML, quais informações serão necessárias para a configuração e qual o padrão de modelo SEP será desenvolvido. Contudo, é necessário melhorar o módulo de configuração atual, para que esse possa, através das informações cadastradas pelos usuários do gerenciador, gerar os gateways do elemento. Dessa forma, os gateways nos quais os elementos se comunicam com restante do modelo possam ser criados automaticamente, sofrendo alterações apenas quando esses fugirem do padrão. Essa seria outra tarefa integrada à configuração automática de elementos para que a comunicação entre elementos heterogêneos e/ou distribuídos do sistema real simulado seja realizada. Outra função prevista para ser integrada ao configurador automático é a capacidade de verificar ligações inviáveis entre atributos dos elementos.

8 Agradecimentos Os autores desse artigo agradecem ao Conselho Nacional de Desenvolvimento Científico e Tecnológico - CNPq pelo auxílio financeiro e ao Departamento de Ciência da Computação da Universidade Federal de Lavras pelo apoio técnico. 5 BIBLIOGRAFIA Amory, A., Moraes, F., Oliveira L., Hessel, F. e Calazans, N. Desenvolvimento de um Ambiente de Co-Simulação Distribuído e Heterogêneo, Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS), Rio Grande do Sul Bruschi, S. M; Santana, R. H. ASDA - Um Ambiente de Simulação Distribuída Automático f. Tese (Doutorado em Ciências da Computação e Matemática Computacional) - ICMC- Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, São Paulo Chaves, T. M. ; Mello, B. A. ; Caimi, L. L. Adaptação de elementos reais na interface do DCB para simulação de modelos heterogêneos. XXXV LATIN-AMERICAN CONFERENCE ON INFORMATICS, 2009, Pelotas. Proceedings of CLEI'2009, Institute for Electrical and Electronic Engineers (IEEE). IEEE P1516: Framework and Rules. New Jersey: IEEE Press, Lee, A. S. ; Westphal, F. S. ; Lamberts, R. Verificação da eficiência energética de um edifício de escritórios através de simulação computacional: Estudo de caso no departamento de Engenharia Civil da UFSC. VI Encontro Nacional e III Encontro Latino-Americano sobre Conforto no Ambiente Construído, São Pedro, SP, Brasil Mello, B. A. ; Feijo Souza, U.R. ; Sperb, J.K. ; Wagner, F.R.. Tangram: Virtual Integration of IP Components in a Distributed Co-simulation. IEEE Design and Test of Computers, v. 22, n. 5, p , Mello, B. A. ; Caimi, L. L. Simulação na validação de sistemas computacionais para a agricultura de precisão. Revista Brasileira de Engenharia Agrícola e Ambiental, v. 12, p , Mello, B. A. ; Parreiras, A. A.. Distributed management of elements for modeling and simulation of heterogeneous models. Summer Computer Simulation Conference, 2009, Istambul, Turquia. Proceedings of Summer Computer Simulation Conference (SCSC'2009). San Diego, USA : Society for Modeling and Simulation International, p , Strassburger, S. ; Schulze, T. ;Klein, U. ; Henriksen, J. O.. "Internet-based simulation using off-the-shelf simulation tools and HLA", WSC, vol. 2, pp , 1998 Winter Simulation Conference (WSC'98), Zafalon, G. F. D. ; Lobato, R. S. High Level Architecture (HLA). Disciplina de Simulação de Sistemas Programa de Pos-Graduação em Ciência da Computação, DCCE/IBILCE/UNESP, São Paulo, DIREITOS AUTORAIS Os autores, Alex Guimarães Cardoso de Sá e Braulio Adriano de Mello, são os únicos responsáveis pelo conteúdo do material impresso incluído no seu trabalho.