AOCS Simulador Distribuído

Transcrição

1 AOCS Simulador Distribuído BRUNO MIGUEL BARROS DOS SANTOS Dissertação para obtenção do Grau de Mestre em ENGENHARIA INFORMÁTICA E DE COMPUTADORES Júri Presidente: Prof. Paulo Jorge Pires Ferreira Orientador: Prof. Mário Rui Fonseca dos Santos Gomes Co-orientador: Prof. João Manuel Brisson Lopes Vogais: Prof. Pedro Miguel Pinto Ramos Prof. João António Madeiras Pereira Setembro 2007

2 Agradecimentos Gostaria de agradecer aos meus pais e irmão pelo apoio demonstrado ao longo da minha vida pessoal e académica. Agradeço ao Filipe Cardoso, o coordenador da equipa de Simulação do SSETI-IST, pela paciência e tempo dispendido comigo, de modo a que o simulador fosse a bom porto. Ao colega e amigo Nuno Oliveira, agradeço as nossas sessões de discussão de ideias e problemas. Agradeço ao meu orientador, Professor Mário Rui Gomes, pelo incentivo, motivação e a sua sempre boa disposição, e ainda por ter aceite orientar um trabalho que não é propriamente da sua área. Por último, gostaria ainda de agradecer aos Engenheiros Tiago Simões e José Freitas da Critical Software pelo acompanhamento de parte do meu trabalho. i

3 Resumo A simulação tem vindo a desempenhar um papel bastante importante na engenharia de processos para sistemas espaciais. No caso particular de um satélite faz todo o sentido que se faça o desenho, a prototipagem, a verificação e a validação do software que será incorporado no satélite antes mesmo de o fazer, pois a construção de um satélite é um investimento caro. A simulação distribuída, através de tecnologia e ambientes distribuídos, procura dar resposta ao crescimento do tempo de simulação derivado da complexidade e do aumento de dimensão dos sistemas simulados. Nesta tese propõe-se a arquitectura para um simulador distribuído de um satélite específico, como forma de explorar a simulação distribuída. Esta arquitectura contempla a simulação de órbita e a simulação de atitude do satélite em questão, o que vai permitir testar os algoritmos de estimação e controlo que serão implementados no software do satélite. Procurou-se separar o que é cálculo de órbita do que é cálculo de atitude, para tornar cada um destes cálculos, processos independentes. Desta forma é possível através da distribuição que cada um dos processos tenha processamento dedicado, estando em máquinas distintas. Palavras-Chave Simulação, Simulação Distribuída, Internet, Satélite, Órbita, Atitude, Estimação, Controlo ii

4 Abstract Simulation is playing an increasingly important role in the system engineering process for space systems. In the case of a satellite it makes all sense to design, prototype, verify and validate the software that will make part of it before the hardware is produced, because the build of a satellite is expensive. Distributed simulation, through technology and distributed environments, tries to answer the problem of the increase of the time of the simulation cause of the complexity and growing dimension of the simulated systems. This thesis proposes an architecture for a distributed simulator of a specific satellite, as a way to explore distributed simulation. This architecture has in account the simulation of the orbit and the simulation of the attitude of the satellite, which allows the test of the algorithms of estimation and control that will be implemented in the satellite. It was looked to separate what is orbit calculation from what is attitude calculation, in order to treat each of the calculations as independent processes. This way, it is possible to have both processes with dedicated processing, in distinct computers. Keywords Simulation, Distributed Simulation, Internet, Satellite, Orbit, Attitude, Estimation, Control iii

5 Índice 1 Introdução Estado d Arte Simulação Distribuída SMP Simulation Model Portability Razão da Distribuição PDES Parallel and Distributed Event Simulation DVE Distributed Virtual Environment HLA High Level Architecture Nomenclatura Rules Interface Specification Object Model Template Suporte à Reutilização e Interoperabilidade Web e a Simulação Distribuída Web-Based Simulation Web Services na Simulação Distribuída HLA versus a Web-Based Simulation Arquitectura Distribuída Corba RMI Net Framework Comparação Sumário Arquitectura Descrição Geral Órbita Atitude Sumário iv

6 4 Implementação Tecnologia AOCS Simulador Distribuído Bibliotecas Executáveis Fases de Execução Sumário Caso de Estudo Simulação da missão Dados de Entrada Dados de Saída Tempo de Execução Sumário Resultados Influência do parâmetro dt Comparação de canais de comunicação Localhost versus Rede Comparação de versões Tráfego de dados na rede Sumário Conclusão e Trabalho Futuro Trabalho Futuro A Manual de Utilização A.2 Órbita A.3 Atitude A.4 Gestor A.5 Consola B Runge-Kutta v

7 Lista de Tabelas Tabela 2.1: Resumo das características do HLA, Corba, RMI e.net Framework Tabela 2.2: Comparação entre HLA, Corba e RMI Tabela 6.1: Teste com dts iguais Tabela 6.2: Teste dts diferentes Tabela 6.3: Teste utilizando TcpChannel Tabela 6.4: Teste utilizando HttpChannel Tabela 6.5: Teste em localhost Tabela 6.6: Teste em rede Tabela 6.7: Comparação de versões vi

8 Lista de Figuras Figura 2.1: Arquitectura de Alto Nível do SMP Figura 2.2: HLA Runtime Infrastructure Figura 2.3: Arquitectura do Corba Figura 2.4: Arquitectura do RMI Figura 2.5: Arquitectura da.net Framework Figura 2.6: Elementos da Infra-estrutura.NET Remoting Figura 3.1: Arquitectura de alto nível do Simulador Figura 3.2: Comportamento desejado da Órbita Figura 3.3: Comportamento desejado para a Atitude Figura 4.1: Arquitectura da implementação do simulador Figura 4.2: Classes do projecto Órbita Figura 4.3: Classes do projecto Atitude Figura 4.4: Classes do projecto Gestor Figura 4.5: Primeira fase de execução do Simulador Figura 4.6: Segunda fase de execução do Simulador Figura 4.7: Terceira fase de execução do Simulador Figura 4.8: Quarta fase de execução do Simulador Figura 6.1: Tráfego de dados da Órbita Figura 6.2: Tráfego de dados da Atitude Figura 6.3: Tráfego de dados do Gestor Figura 6.4: Tráfego de dados da Consola Figura A.1: Linha de comandos da Órbita Figura A.2: Linha de comandos da Atitude Figura A.3: Linha de comandos do Gestor Figura A.4: Linha de comandos da Consola vii

9 Lista de Abreviaturas ALSP Aggregate Level Simulation Protocol AOCS Attitude and Orbit Control Subsystem API Application Programmer Interface CGI Common Gateway Interface CIL Common Intermediate Language CLR Common Language Runtime CVS Concurrent Versions System DCOM Distributed Component Object Model DII Dynamic Invocation Interface DIS Distributed Interactive Simulation DOM Document Object Model DVE Distributed Virtual Environment ESA European Space Agency ESEO European Student Earth Orbiter ESMO European Student Moon Orbiter FOM Federation Object Model GC Garbage Collector GUI Graphical User Interface HLA High Level Architecture HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol IDE Integrated Development Environment IDL Interface Definition Language IEEE Institute of Electrical and Electronics Engineers IIOP Internet Inter-Orb Protocol IIS Internet Information Services IP Internet Protocol IST Instituto Superior Técnico JIT Just-In-Time JNI Java Native Interface viii

10 JVM Java Virtual Machine MDA Model Driven Architecture MIME Multipurpose Internet Mail Extensions OMG Object Management Group OMT Object Model Template ORB Object Request Broker PDES Parallel and Distributed Event Simulation PDU Protocol Data Unit RMI Remote Method Invocation RTI Runtime Infrastructure SGML Standard Generalized Markup Language SMP Simulation Model Portability SOAP Simple Object Access Protocol SOM Simulation Object Model SSETI Student Space Exploration and Technology Initiative TCP Transmission Control Protocol UDP User Datagram Protocol UML Unified Modeling Language URL Uniform Resource Locator W3C World Wide Web Consortium WWW World Wide Web XML Extensible Markup Language ix

11 Capítulo 1 Introdução for Distinction Sake, a Deceiving by Words, is commonly called a Lye, and a Deceiving by Actions, Gestures, or Behavior, is called Simulation... Robert South ( ) A utilidade da simulação torna-se evidente quando se está perante sistemas críticos ou sistemas cujo desenvolvimento seja financeiramente dispendioso. É o caso da construção de satélites. Daí que organizações como a ESA procedam à simulação deste tipo de sistemas antes de partir para a sua implementação. A ESA é o organismo na Europa responsável por concretizar missões ao espaço e assegurar que o investimento feito no espaço continua a trazer benefícios aos cidadãos da Europa e do mundo. A ESA é uma organização internacional constituída por 17 estados membros, a coordenação de recursos intelectuais e financeiros de todos eles permite a realização de programas e actividades que estão fora do alcance de um único país europeu. O trabalho da ESA é definir e executar o programa espacial europeu, este envolve a Terra, o seu ambiente espacial imediato, o nosso Sistema Solar e o Universo, assim como desenvolver tecnologias baseadas em satélites e serviços, e ainda promover a indústria Europeia. A ESA trabalha também com organizações espaciais não europeias. O SSETI foi criado no ano 2000 pela ESA, com o objectivo de envolver os estudantes europeus em missões espaciais reais. Permite assim dar experiência aos estudantes e aumentar a sua motivação para trabalharem em áreas ligadas à ciência e tecnologia espacial, ajudando a assegurar a disponibilidade de uma força de trabalho competente e talentosa para o futuro. Em última instância o programa SSETI tornar-se-á uma rede de suporte às actividades e educação relacionada com a área espacial para todos os estudantes, focando primariamente no envolvimento dos estudantes nas missões espaciais reais, incluindo micro, nano e pico satélites, incluindo outras oportunidades. O SSETI ESEO será o segundo satélite da ESA criado por estudantes, vindo no seguimento do SSETI Express [1]. O ESEO é também a nível técnico o precursor do micro satélite SSETI ESMO [2] 1

12 e servirá para testar hardware em ambientes extremos de radiação para futuras missões de exploração para além da orbita terrestre. A plataforma do satélite ESEO está a ser desenvolvida por equipas de estudantes, tal como o foi o SSETI Express. A integração e teste dos vários subsistemas terão lugar durante , tendo em vista o lançamento do ESEO em 2008, lançamento esse que será feito usando o Ariane 5 ou o Soyuz. Um destes será o escolhido para colocar o ESEO em órbita geostacionária. Todos os resultados serão disponibilizados ao público e utilizados para fins educacionais. O SSETI ESEO tem como objectivos de missão: Demonstrar o sucesso da iniciativa educacional da ESA, assim como, encorajar, motivar e desafiar os estudantes a melhorarem os seus conhecimentos na área da investigação e exploração do espaço; Tirar fotografias da Terra e/ou de outros corpos celestiais para propósitos educacionais; Fornecer medições dos níveis de radiação e dos seus efeitos em componentes através de múltiplas passagens na cintura de Van Allen; Adquirir experiência com as tecnologias para utilização em futuras missões. Para conhecer em maior detalhe o ESEO, a sua missão e a sua estrutura consultar [3]. Aquando da criação da iniciativa, também em 2000, foi criada no IST uma equipa para trabalhar no ESEO na área de AOCS. A equipa conta actualmente com a participação de mais de 30 alunos do IST (e também de alguns antigos membros) de diferentes áreas de Engenharia (Aeroespacial, Electrotécnica, Física, Informática e Mecânica), o que traz uma mais valia ao projecto permitindo uma interdisciplinaridade concreta e real. Esta equipa tem a cargo o desenho e concepção tanto de hardware como de software. No hardware há a destacar o desenvolvimento de um actuador e diversos sensores, em termos de software destaca-se o desenvolvimento de algoritmos de estimação e controlo (usando a informação dos sensores e operando sobre os actuadores), e de um sistema operativo capaz de gerir todos estes elementos, comunicando entre eles e com o resto do satélite. Todos estes componentes, hardware e software, farão parte do satélite. Para além da equipa de AOCS existem ainda outras equipas que estão também a desenvolver componentes para o satélite e para a ground station. Estando-se na presença de um sistema complexo e delicado, como o é um satélite que vai para o espaço, surgiu a necessidade de se criar um simulador que teste e verifique o correcto funcionamento dos algoritmos que fazem parte do software do satélite. Mais concretamente, o simulador simula a atitude e a órbita descrita pelo satélite de modo a aferir o comportamento da componente de estimação e do mecanismo de controlo. O simulador começou a ser desenvolvido antes da minha entrada na equipa do ESEO do IST, por membros que não tinham muitos conhecimentos no desenvolvimento de aplicações (até essa altura ainda não havia elementos de Informática no grupo), daí que a primeira versão do simulador tenha sido criada com alguns problemas e com alguns remendos. Quando entrei para a equipa propus, juntamente com outro colega, o desenvolvimento de uma nova versão do simulador, de modo a 2

13 resolver os problemas anteriores, a melhorar a nível de desempenho e utilização, e a permitir outro tipo de interacção e funcionalidade, como é o caso do funcionamento distribuído na Internet. Espera-se que no futuro este simulador por nós desenvolvido sirva de base ao desenvolvimento de outros que sejam necessários para outras missões, como é o caso do ESMO. Na arquitectura por nós proposta, o simulador decompõe-se em dois módulos: o de cálculo, constituído por algoritmos de estimação e controlo, e o gráfico, dotado de inúmeros recursos gráficos de apresentação. Estes módulos interagem através da rede Internet, permitindo a ambos usufruir de processamento dedicado, o que aumenta o seu desempenho. A meu cargo ficou o desenvolvimento do módulo de cálculo, que tem também internamente um funcionamento distribuído entre as partes que o constituem. Tendo ficado a cargo do outro colega o desenvolvimento do módulo gráfico. Portanto, o que aqui se apresenta é o trabalho e a pesquisa realizada com vista ao desenvolvimento de um simulador distribuído na Internet de um satélite, neste caso em concreto o satélite será o ESEO. A Critical Software é uma das empresas que apoia a equipa SSETI do IST. Esta empresa, sediada em Coimbra, e com instalações em Lisboa, fornece soluções, serviços e tecnologias para sistemas de informação críticos de missões e negócios. A empresa tem clientes na área do espaço, como por exemplo a ESA, daí haver algum envolvimento com o SSETI no IST, financeiro (na aquisição de componentes), e também com estágios e apoio personalizado nas áreas de construção de software e simulação. No caso do presente trabalho, houve um acompanhamento por parte de duas pessoas desta empresa ao longo do último semestre de desenvolvimento deste. Este acompanhamento serviu para discutir ideias, problemas, soluções, etc. que me surgiram durante a realização do trabalho. Para além disso recebi também algumas sugestões que se encontram na forma de trabalho futuro neste mesmo documento. No capítulo 2 (Estado d Arte) apresenta-se algum do trabalho realizado na área da Simulação Distribuída, bem como arquitecturas e tecnologias usadas ou que têm potencialidade para ser usadas no desenvolvimento de aplicações deste género. O capítulo 3 (Arquitectura) incide sobre o modelo ou arquitectura proposto(a) para um simulador distribuído de um satélite. No capítulo 4 (Implementação) são descritos os aspectos de implementação do modelo proposto no capítulo 3. O capítulo 5 (Exemplo de Utilização) demonstra um exemplo de utilização do simulador, dando ênfase aos dados de entrada e aos dados de saída deste. No capítulo 6 (Resultados) são apresentados os resultados de alguns testes realizados ao simulador. Por fim, no capítulo 7 (Conclusões e Trabalho Futuro) são realizadas as conclusões e apresentadas algumas sugestões de trabalho futuro. 3

14 Capítulo 2 Estado d Arte A Simulação tornou-se numa ferramenta importante para a modelação de sistemas ou processos, pois permite a experimentação e análise destes antes da sua construção ou modificação, evitando ou antecipando assim problemas do sistema real. Infelizmente os modelos de simulação estão a ficar cada vez maiores, o que leva a um crescimento do tempo de simulação, reduzindo a sua utilidade. A Simulação Distribuída tem vindo a ser utilizada para reduzir o crescimento do tempo de simulação e veio também facilitar o desenvolvimento de simuladores com componentes de modelos que podem ser desenvolvidos independentemente em plataformas heterogéneas e geograficamente distribuídas. Neste documento são introduzidos conceitos básicos tanto da Simulação em geral, como da Simulação Distribuída em particular. Em relação à Simulação Distribuída são ainda apresentadas duas categorias de simulação (simulações analíticas e ambientes virtuais), associados às simulações analíticas estão dois mecanismos de sincronização (conservativo e optimista). A arquitectura HLA (High Level Architecture), foi desenvolvida pelo Departamento de Defesa dos EUA (DoD), motivada pelo desejo de reduzir custos e aumentar a qualidade através da interoperabilidade e reutilização no desenho e execução de simulações distribuídas. Com o aparecimento da World Wide Web (WWW), foi introduzido o conceito de Web-Based Simulation. A relação entre o HLA e a Web-Based Simulation reside basicamente na noção de interoperabilidade. Uma das áreas de investigação associada à Web-Based Simulation é a Modelação e Simulação Distribuída, o que inclui actividades que implicam o uso de arquitecturas ou tecnologias orientadas à Web, como é o caso de CORBA e RMI, para suportar a execução das simulações distribuídas. É apresentada uma comparação entre estas duas arquitecturas (CORBA e RMI) e a arquitectura HLA, evidenciando-se as implicações que estas trazem à Simulação Distribuída. Uma tecnologia bastante utilizada na implementação de aplicações distribuídas é a.net Framework da Microsoft, a qual disponibiliza diversas funcionalidades que permitem um rápido e fácil desenvolvimento deste tipo de aplicações, o que faz da tecnologia uma opção a ter em consideração na área da simulação distribuída. 4

15 Através do uso de standards abertos, os web services conferem às aplicações interoperabilidade e fornecem um vasto leque de serviços independentemente da linguagem e da arquitectura do servidor e dos clientes. O protocolo SOAP é usado como framework para o envio de mensagens XML entre servidor e clientes, sendo estas mensagens enviadas através de HTTP. Estas características podem ser aplicadas à Simulação Distribuída para que esta tire partido da interoperabilidade. A tecnologia XML pode também ser utilizada na modelação de simulações. Ambas as aplicações são aqui discutidas. 2.1 Simulação Distribuída A Simulação tornou-se numa ferramenta importante no planeamento, avaliação e análise do desenho de novos sistemas, modificação de sistemas existentes e das regras de operação e controlo destes. Tem vindo a ser utilizada em áreas como a física, química, economia, telecomunicações, etc. O que é uma Simulação? Uma Simulação é um sistema que representa ou emula o comportamento de um outro sistema ao longo do tempo; uma Computer Simulation é quando o sistema que efectua a emulação é um programa de computador. Definições e Conceitos De seguida são apresentados os principais conceitos associados à Simulação: modelos, eventos, processos. Um modelo é a representação de um sistema ou processo. Um modelo de simulação é uma representação que incorpora tempo e as mudanças que ocorrem ao longo deste. Um modelo discreto é um no qual o estado se altera apenas em pontos discretos do tempo e não continuamente. Um modelo pode incorporar aspectos lógicos, matemáticos e estruturais de um sistema ou processo. Um modelo de eventos discretos baseia-se nos conceitos de estado, eventos, actividades e processos. O tempo é um componente crítico. Um modelo de eventos discretos é um no qual o estado muda apenas em pontos discretos do tempo. Quando um evento ocorre, este pode fazer com que ocorram novos eventos, actividades e processos. Um evento é uma ocorrência instantânea que altera o estado do modelo. Uma actividade é uma duração de tempo, que é iniciada por um evento em conjunto com o modelo que se encontra num certo estado. Uma entidade é um objecto no modelo, que tem atributos, sendo alguns modificáveis para permitir a individualização de entidades. Entidades dinâmicas normalmente representam algum objecto do mundo real, estas são criadas no tempo zero ou aquando da ocorrência de um evento. 5

16 Um recurso é uma entidade que providencia um serviço para as entidades dinâmicas. Um recurso normalmente tem uma capacidade finita que representa uma restrição do sistema. Como é utilizada a Simulação? Um modelo de simulação é um modelo descritivo de um processo ou sistema, e geralmente inclui parâmetros que permitem que o modelo seja configurável, isto é, para permitir um número infinito de configurações de sistemas ou processos. Sendo um modelo descritivo, pode-se usar um modelo de simulação para experimentar, avaliar e comparar, qualquer número de alternativas do sistema. Avaliação, comparação e análise são as razões chave para a realização de simulação. Prever o desempenho do sistema e identificar os seus problemas e as suas causas são os resultados chave. As vantagens e valor da Simulação, e as desvantagens A Simulação permite a experimentação com o modelo de um sistema. Sem um modelo, ou se experimenta com o sistema real (se existir) ou se procede sem experimentação e análise, correndo potenciais riscos. A simulação permite a identificação de problemas, bottlenecks e falhas de desenho antes da construção ou modificação do sistema. Permite a comparação das diferentes alternativas de desenho e regras de operação. Avaliação e comparações podem ser realizadas antes da alocação de recursos e investimento no projecto. A simulação permite o estudo da dinâmica do sistema, como é que este se comporta ao longo do tempo e como é que os subsistemas e componentes interagem. Um modelo de simulação providencia o único método para estudar novos e não existentes sistemas dinâmicos complexos. Por outro lado, muitas vezes as simulações consomem muito tempo, a informação não está disponível ou custa a obter, e o tempo disponível para tomar decisões não é suficiente para a realização de um estudo fiável. Analistas de simulação inexperientes, ou aqueles demasiado focados no software de simulação e tecnologia podem detalhar demasiado o modelo e demorar muito tempo com o desenvolvimento deste, resultando no esquecimento dos objectivos originais e dos prazos estabelecidos. Estas situações levam muitas vezes os gestores a concluir que a simulação, apesar de ser uma tecnologia promissora e interessante, é demasiado cara e consome muito tempo para a maioria dos projectos. Um bom modelo de simulação fornece não apenas medidas numéricas do desempenho do sistema, mas também conhecimento sobre esta. De seguida é apresentado um standard criado pela ESA para a definição de modelos de simulação reutilizáveis. 6

17 SMP Simulation Model Portability A ESA está envolvida no desenvolvimento de simuladores espaciais há vários anos, e tem vindo a desenvolver simulações em várias áreas, como a análise, engenharia, teste e validação, preparação de operações e treino. Sendo estes simuladores desenvolvidos por diferentes grupos e em diferentes fases de um projecto, houve a necessidade de criar um standard de forma a reduzir o custo de desenvolvimento de um simulador. Com este objectivo em vista, a ESA liderou a especificação do Simulation Model Portability (SMP). O SMP permite a reutilização e portabilidade de modelos de simulação entre simuladores num único projecto espacial ou mesmo entre diferentes projectos, contribuindo assim para uma redução do esforço de desenvolvimento. A primeira versão do SMP, designada SMP1, foi lançada em 2001 e foi utilizada durante algum tempo, tempo sido aplicado com sucesso ao desenvolvimento de alguns simuladores em projectos da ESA. Mas, a falta de suporte a tecnologias de engenharia de software modernas levou a que se desse início ao processo de desenvolvimento de uma nova versão do standard, a SMP2. O SMP2 assenta no desenho baseado em componentes e na Model Driven Architecture (MDA) tal como é promovida pela Object Management Group (OMG), é também baseado nos standards abertos do UML e do XML. Um dos princípios básicos do SMP é a separação entre os aspectos específicos do modelo e os aspectos independentes, tal como se pode verificar na figura 2.1. Esta separação isola o standard de rápidas alterações na tecnologia, sendo a sua implementação independente da plataforma, que pode depois ser traduzido para diferentes tecnologias. Figura 2.1: Arquitectura de Alto Nível do SMP2 7

18 Outro princípio básico do SMP2 é a separação dos aspectos de tempo de desenho dos aspectos de execução do sistema, como se pode ver na figura 2.1. A vista do tempo de desenho descreve a estrutura do modelo, as suas interfaces e funcionalidades, e a vista do tempo de execução descreve como é que os modelos podem ser assemblados de forma a constituírem um sistema executável e completo. Esta aproximação permite a definição de blocos reutilizáveis e a forma como são integrados num sistema executável. Isto estende o SMP1, que identificava estes conceitos com a gestão de modelos e a integração de modelos, mas não especificava como é que isto era atingido Razão da Distribuição Os modelos de simulação estão a ficar cada vez maiores e, como consequência o tempo requerido para a simulação está a crescer. Computadores multiprocessador e ambientes de processamento distribuído têm sucessivamente sido utilizados para reduzir o crescimento do tempo de simulação, pois por definição, os sistemas de Simulação Distribuída eliminam a lista de eventos globalmente partilhada usada nos sistemas de simulação sequencial. A tecnologia da Simulação Distribuída facilita ainda a construção de uma simulação de larga escala com componentes de modelos que podem ser desenvolvidos independentemente em plataformas heterogéneas e geograficamente distribuídas. São quatro os principais benefícios que se obtêm ao executar uma simulação de forma distribuída: 1. Redução do tempo de execução Subdividindo a computação de uma simulação em computações menores e executando-as concorrentemente em diversos computadores leva a uma redução do tempo de computação; 2. Distribuição geográfica A execução de um programa de simulação num conjunto de computadores geograficamente distribuídos permite a criação de mundos virtuais com múltiplos participantes fisicamente localizados em diferentes locais; 3. Integração de simuladores de diferentes fabricantes Em vez de se traduzir simuladores de diferentes fabricantes para um único computador, traz menos custos a ligação destes simuladores, cada um correndo no seu computador. O que leva a uma computação distribuída entre vários computadores; 4. Tolerância a faltas A utilização de vários computadores leva a um aumento da tolerância a faltas. Se um computador ou processador falhar, é possível que outro retome o seu lugar e continue a desenvolver o seu trabalho, permitindo que a simulação prossiga apesar da falha. Por outro lado, se a simulação estiver a correr num só computador e este falhar, toda a simulação irá parar. 8

19 A simulação distribuída tem vindo a ser utilizada principalmente no seguinte tipo de aplicações: Aplicações Militares Entretenimento Interacções Sociais e Colaboração no Negócio Educação e Treino Redes de Telecomunicações Circuitos Lógicos Digitais e Sistemas de Computadores Transportes A simulação distribuída é afectada por todos os elementos de um sistema distribuído, como por exemplo, software, hardware e rede de comunicação. O software inclui uma parte específica de utilizador e uma parte específica de sistema. A parte utilizador consiste principalmente no algoritmo de distribuição e outros elementos de software controláveis pelo utilizador. O algoritmo de distribuição toma conta da correcta simulação, sincronização e deadlocks. A parte específica do sistema contém o sistema operativo, device drivers, buffers internos, etc. A parte hardware consiste no equipamento de processamento e de transmissão. A rede de comunicação é usada para comunicação entre os computadores e é normalmente considerada a principal fraqueza dos ambientes distribuídos. A parte da rede de comunicação contém todos os elementos envolvidos na transmissão de uma mensagem de um computador para outro. Segundo [16] existem duas categorias de simulação, que são: 1. Simulações usadas principalmente para análise (simulações analíticas) em que o objectivo principal é o cálculo de resultados da simulação o mais rápido possível de modo a aumentar a efectividade da ferramenta de simulação. 2. Simulações usadas para criar ambientes virtuais neste caso procuram-se criar ambientes virtuais para treino, entretenimento, e teste de avaliação de dispositivos, que normalmente têm intervenção humana e/ou de hardware. 2.2 PDES Parallel and Distributed Event Simulation Em simulações analíticas é bastante importante uma correcta sincronização da execução da simulação paralela/distribuída e para isso é preciso gerir o tempo. A gestão do tempo assegura não só que os eventos são processados na ordem correcta, mas ajuda também a assegurar que execuções repetidas de uma simulação com as mesmas entradas produzem exactamente os mesmos resultados. Os algoritmos de gestão de tempo normalmente assumem que uma simulação consiste numa colecção de processos lógicos (logical processes - LPs) que comunicam entre si trocando mensagens temporalmente marcadas (timestamped messages) ou eventos. O objectivo dos mecanismos de sincronização é assegurar que cada LP processe os eventos segundo a ordem 9

20 temporal com que foram marcados este requisito é denominado de restrição de causalidade local (local causality constraint). Pode ser demonstrado que se cada LP respeitar esta restrição, a execução da simulação de forma paralela/distribuída irá produzir exactamente os mesmos resultados se esta fosse executada de forma sequencial. Cada LP pode ser visto como uma simulação sequencial de eventos discretos. O que significa que cada LP mantém um estado local e uma lista de eventos temporalmente marcados que foram atribuídos ao LP em questão (incluindo eventos locais que LP tenha atribuído a si mesmo), mas que não foram ainda processados. Esta lista de eventos pendentes deve conter também os eventos enviados por outros LPs a este LP. O ciclo principal de processamento do LP repetidamente remove o evento com menor marca temporal e processa-o, o que pode ser visto como uma sequência de computações de eventos. Cada LP mantém um relógio do tempo da simulação que indica a marca temporal do evento processado pelo LP mais recentemente. Qualquer evento agendado por um LP deve ter uma marca temporal superior ao tempo da simulação aquando do agendamento do evento. Os algoritmos de gestão de tempo podem ser classificados como sendo conservativos eventos dependentes nunca são processados fora de ordem, isto é, nunca ocorrem erros de sincronização ou optimistas permitem a ocorrência de erros de sincronização, mas fornecem mecanismo para recuperar. Sincronização Conservativa Os algoritmos conservativos têm de determinar quando é que é seguro processar um evento, isto é, têm de saber ou ter forma de saber se todos os eventos nos quais o evento em questão depende já foram processados. Para isso, um LP não pode processar um evento com marca temporal T enquanto não garanta que não surja mais tarde um evento com uma marca temporal inferior a T. Os primeiros algoritmos foram propostos por Chandy e Misra [9] e Bryant [6]. Estes assumiram que a topologia que indicava que LPs enviavam mensagens para outros era conhecida, e que as mensagens chegavam ao canal de entrada segundo a ordem das marcas temporais. Desta forma garantiam que a marca temporal da última mensagem recebida no canal era menor que a marca temporal que qualquer mensagem subsequente que chegasse nesse canal. Esta informação permite que um LP determine o limite inferior da marca temporal de futuras mensagens, permitindolhe determinar se é seguro processar o evento. Se um LP não tiver eventos seguros, então bloqueia-se, podendo esta situação levar a um deadlock. Mensagens Null são usadas para evitar deadlocks. Uma mensagem null com marca temporal T null enviada de LP A para LP B é uma promessa de LP A indicando que não irá enviar a LP B mensagens com marcas temporais inferiores a T null. As mensagens null não correspondem a qualquer actividade da simulação. Os processos enviam as mensagens null após processarem cada evento. As mensagens null fornecem informação adicional ao processo receptor que pode ser usada por este para determinar que outros eventos são seguros para processar. Este algoritmo evita alguns deadlocks sob algumas restrições. 10

21 Contudo, este algoritmo pode gerar muitas mensagens null, por isso mais tarde Chandy e Misra [8] desenvolveram outro algoritmo que leva também à ocorrência de deadlock, mas que consegue detectá-lo e quebrá-lo. Foram propostos inúmeros outros mecanismos conservativos a descrição destes pode ser vista em [15] e [18]. Alguns protocolos usam uma sincronização em que estão ciclicamente numa de duas situações: (a) a determinar quais os eventos que são seguros para processar, e (b) a processar estes eventos, [5], [10], [26] e [28]. Para determinar quais os eventos seguros, é usada por vezes a distância entre LPs. Esta distância é a quantidade mínima de tempo de simulação que deve decorrer para um evento num LP afectar, directa ou indirectamente, outro LP, [5] e [26], podendo ser usada por um LP para determinar limites para as marcas temporais de eventos futuros que receba de outros LPs. Sincronização Optimista O mecanismo Time Warp inventado por Jefferson e Sowizral, [24] e [25], é o método optimista mais conhecido. Quando um LP recebe um evento com uma marca temporal menor que a de um ou mais eventos que já tenha processado, este faz o rollback e processa novamente estes eventos na ordem das marcas temporais. Fazer o rollback de um evento envolve repor o estado do LP para o estado em que estava antes de processar o evento (para isso são guardados checkpoints), e fazer o unsend de mensagens enviadas pelos eventos que foram desfeitos (rolled back). Um mecanismo elegante para o unsend de mensagens designa-se anti-messages. Uma anti-message é uma cópia duplicada de uma mensagem enviada anteriormente. Sempre que uma anti-message e a correspondente mensagem original estiverem ambas na mesma fila de processamento, então as duas são eliminadas. Para fazer o unsend de uma mensagem, um processo apenas necessita de enviar a anti-message correspondente. Se a mensagem original já tiver sido processada, o receptor efectua o rollback da mensagem, produzindo provavelmente novas anti-messages. Através deste processo recursivo todos os efeitos de uma mensagem errada serão eventualmente apagados. Muitos outros algoritmos optimistas foram propostos, [15] e [18], procurando a maioria limitar a quantidade de computação optimista. 2.3 DVE Distributed Virtual Environment Os Distributed Virtual Environments (DVEs) são uma tecnologia de simulação distribuída que permitem a criação de ambientes virtuais gerados por computador aos quais os utilizadores, muitas vezes em localizações geograficamente distantes, se podem ligar. Sendo este o principal objectivo, o de criar uma representação suficientemente realista de um sistema, como percepcionado pelos participantes ligados ao ambiente. O significado de suficientemente realista depende do que se esteja a simular, por isso nem todos os aspectos do ambiente simulado têm de ser minuciosamente detalhados. As aplicações típicas desta tecnologia são o treino e o entretenimento, e por exemplo, 11

22 num treino de voo interessa que o sistema seja o mais realista possível ao nível da resposta aos comandos e outros efeitos como fumo e vento, ao passo que o detalhe do realismo de árvores neste caso não seja importante, pois não influencia a efectividade de um treino de voo. Interessa também que o resultado de um treino ou da avaliação do sistema simulado não seja influenciado por artefactos do ambiente virtual. Existe um certo grau de tolerância no erro colocado nas aplicações, que varia de aplicação para aplicação e que afecta os requisitos deste tipo de sistemas de simulação. DIS Distributed Interactive Simulation O Distributed Interactive Simulation (DIS) foi intensivamente utilizado para o desenvolvimento de DVEs para o treino na comunidade de Defesa. O principal objectivo do DIS era permitir a interoperabilidade entre simuladores separadamente desenvolvidos. O DIS utilizava os seguintes princípios de desenho: Nós de simulação autónomos; Transmissão de informação verdadeira dos nós; Transmissão apenas de informação de alteração de estado; Utilização de algoritmos dead reckoning para extrapolar informação do estado de entidades. Um aspecto chave no DIS para o suporte de interoperabilidade entre simuladores é a definição de PDUs standard que são enviadas entre os simuladores. Outro aspecto importante no DIS é a utilização de algoritmos dead reckoning, os quais permitem reduzir a comunicação entre processos ou simuladores. A ideia básica é estimar, por exemplo, a posição de um objecto dada a sua última posição, velocidade, direcção, etc. evitando o envio frequente de informação relativa à actualização do estado do objecto. Para que os valores estimados não se afastam muito dos reais, devido à estimação feita a partir de dados anteriores e não actuais, é normalmente aplicado o mesmo algoritmo localmente para cada iteração da aplicação, sendo comparados os valores obtidos com os reais. Quando se verifica um erro superior a um determinado valor predefinido é enviada informação para que seja feita uma correcção aos valores que foram estimados. 2.4 HLA High Level Architecture A High Level Architecture (HLA) fornece um standard que permite reduzir o custo e o tempo de desenvolvimento de sistemas de simulação e aumentar as suas capacidades facilitando a reutilização e a interoperabilidade entre os simuladores componentes. Baseado num processo que envolveu governo, mundo académico e indústria, o Defense Modeling and Simulation Office (DMSO) do Department of Defense (DoD) dos Estados Unidos da América desenvolveu a HLA, adoptando-a como arquitectura standard para todas as suas simulações a 10 de Setembro de A HLA beneficiou de outros esforços anteriores do DoD: o Distributed 12

23 Interactive Simulation (DIS) e o Aggregate Level Simulation Protocol (ALSP) [31]. O Institute of Electrical and Electronics Engineers (IEEE) aprovou também a HLA como standard (IEEE-1516). A HLA é aplicável a um vasto leque de áreas funcionais que vão do treino à análise passando por sistemas de aquisição. É aplicável a simulações construtivas com representações puras de software, a simulações man-in-the-loop, e a interfaces para live systems. A HLA consiste nos seguintes componentes: HLA Rules: regras a que as simulações devem obedecer para estarem de acordo com o standard; HLA Interface Specification: define como é que os simuladores interagem com a Runtime Infrastructure (RTI), figura 2.2; HLA Object Model Template: especifica que informação é transmitida entre simulações e como está documentada. Figura 2.2: HLA Runtime Infrastructure A HLA é uma arquitectura para simulações e aplicações de modelação e não é por si só, um simulador, ferramenta de modelação ou pacote de software Nomenclatura Como muitas outras tecnologias a HLA tem a sua própria terminologia [19], das quais se destacam os seguintes termos: Federate: simulador individual ou componente executável. Estes são os simuladores independentes que a HLA integra numa simulação colaborativa; Federation: simulação composta por dois ou mais federates e um Federation Object Model (FOM) que são usados como um todo para atingir determinado objectivo específico; Federation Execution: operação actual, ao longo do tempo, de um conjunto de federates que estão interligados por uma runtime infrastructure (RTI); 13

24 Federation Object Model (FOM): especificação que define a informação trocada em tempo de execução para atingir um dado conjunto de objectivos por parte das federation. Inclui classes objecto, atributos de classes objecto, classes de interacção, parâmetros de interacção, e outra informação relevante; Simulation Object Model (SOM): especifica o tipo de informação que um federate individual pode fornecer às federations, assim como a informação que um federate individual pode receber de outros federates numa federation. Objecto: conceptualmente, um objecto HLA é uma entidade que a simulação modela. Literalmente, um objecto é um contentor para informação partilhada que é criado por um federate durante a execução de uma federation e persiste enquanto a federation se executar ou até que seja destruído. Interacção: acção explicita tomada por um federate que pode ter algum efeito ou impacto noutro federate que pertença à execução de uma federation; Runtime Infrastructure (RTI): software que fornece interfaces de serviços comuns durante a execução de uma federation para a sincronização e troca de informação. Object Model Template (OMT): modelo standard usado para definir a forma, tipo, e estrutura da informação partilhada numa federation e para outra informação de interface Rules As HLA Rules [19] descrevem as responsabilidades das federações e dos federados, existindo cinco regras para cada um destes componentes: 1. As federations devem possuir um FOM, documentado de acordo com o OMT; 2. Numa federation, todas as representações dos objectos no FOM devem estar nas federations, e não na RTI; 3. Durante a execução de uma federation, toda a troca de informação FOM entre federates deve ocorrer via RTI; 4. Durante a execução de uma federation, os federates devem interagir com a RTI de acordo com a HLA Interface Specification; 5. Durante a execução de uma federation, um atributo de uma instância de um objecto deve pertencer apenas a um federate em cada instante; 6. Os federates devem possuir um SOM, documentado de acordo com o OMT; 7. Os federates devem ser capazes de actualizar e/ou reflectir quaisquer atributos de objectos dos seus SOMs e enviar e/ou receber interacções externas de objectos SOM, tal como especificado nos seus SOMs respectivos; 14

25 8. Os federates devem ser capazes de transferir e/ou aceitar dinamicamente o domínio de um atributo durante a execução de uma federation, tal como especificado nos seus SOMs respectivos; 9. Os federates devem ser capazes de variar as condições sobre as quais fornecem actualizações dos atributos dos objectos, tal como especificado nos seus SOMs respectivos; 10. Os federates devem ser capazes de gerir os respectivos tempos locais de modo a que lhes permita coordenar a troca de informação com outros membros de uma federation Interface Specification A HLA Interface Specification [20] descreve os serviços disponibilizados pela RTI aos federados, e pelos federados à RTI. A HLA Interface Specification é fornecida como Application Programmer Interface (API) de diversas formas que incluem CORBA IDL, C++, ADA95 e Java. Existem seis classes de serviços: Federation Management: fornece as funções básicas para a criação e operação de uma federation; Declaration Management: providencia o meio para os federates declararem que informação vão fornecer e requerer durante a execução de uma federation; Object Management: oferece criação, eliminação, identificação e outros serviços ao nível do objecto; Ownership Management: suporta a transferência dinâmica de domínio de objectos/atributos durante a execução. Este serviço é necessário porque em qualquer instante, apenas um federate, designado o owner, pode actualizar o valor de um atributo particular; Time Management: suporta a sincronização das trocas de informação da execução da simulação; Data Distribution Management: suporta o redireccionamento eficiente da informação entre os federates durante o curso de execução de uma federation. A HLA Interface Specification define a forma como estes serviços são acedidos, funcionalmente e numa interface de programador Object Model Template O HLA Object Model Template [21] fornece uma framework comum usada para a definição da informação contida em cada HLA object model para cada federation e simulação (federate), é considerada uma linguagem de interfaces para a HLA. O objectivo principal do OMT é facilitar a interoperabilidade entre simulações e a reutilização de componentes de simulação. Para isso, baseia-se no paradigma publicar e subscrever (publish and subscribe), em que quem fornece informação publica (publish) atributos relevantes dos objectos apropriados e actualiza-os, quem 15

26 recebe informação subscreve (subscribe) os atributos e lê-os. Estes são descobertos através das federations FOM. São especificados dois tipos de object models na HLA: HLA Federation Object Model: descreve o conjunto de objectos, atributos e interacções partilhados entre uma federation; HLA Simulation Object Model: descreve a simulação (federate) em termos dos tipos de objectos, atributos e interacções que pode oferecer a futuras federations Suporte à Reutilização e Interoperabilidade O DoD define a interoperabilidade como sendo a habilidade de uma simulação fornecer serviços para, e aceitar serviços de, outras simulações, e utilizar os serviços de maneira a que operem efectivamente em conjunto. Esta definição vai de encontro ao principal objectivo da HLA, em que diferentes simulações devem partilhar informação com vista a cumprir um objectivo comum. Segundo o parágrafo anterior existem dois elementos associados à interoperabilidade: partilha de informação e interpretação consistente de informação. A HLA requer que os federates sejam construídos com as funcionalidades necessárias para interagir com a RTI e que troquem informação com outros federates através das interfaces especificadas pela HLA. A HLA requer também que todos os federates e federations documentem as características das representações dos seus objectos relevantes a outros potenciais utilizadores de federates e federations. Esta documentação, na forma de OMT, facilita a troca de informação necessária à interpretação consistente de informação partilhada. Enquanto que a interoperabilidade diz respeito à troca de informação entre federates distintos em execução, a reutilização lida com a adaptação de componentes (ideias, simulações inteiras, linhas de código) durante o desenvolvimento de uma nova simulação. Para facilitar a reutilização é necessário que haja componentes bem definidos (os federates). As regras da HLA, a especificação da interface, e o OMT fornecem as ferramentas essenciais para a interoperabilidade. A HLA por si só não é suficiente para garantir a interoperabilidade, apenas fornece a framework técnica para as simulações e para os programadores de federations para que estes possam atingir o grau de interoperabilidade necessário de forma a atingirem os seus objectivos. 2.5 Web e a Simulação Distribuída De seguida é apresentada uma comparação dos objectivos, estrutura, operações e mecanismos de comunicação da Web com os respectivos da Simulação Distribuída. Comparação dos Objectos A web foca-se na acessibilidade da informação, tendo como objectivo primário fornecer um universo de informação. A simulação centra-se na criação e análise de informação, neste contexto o seu 16

27 principal objectivo é fornecer conhecimento, ou respostas a questões importantes através da experimentação e da modelação, que poderia ser difícil ou custosa de obter. A simulação é um processo que tenta prever aspectos do comportamento dos sistemas criando modelos aproximados destes. Tanto a web como a simulação distribuída fornecem informação/conhecimento através da computação, no entanto focam-se em diferentes aspectos do conhecimento, por isso os requisitos funcionais e o desempenho pode variar significativamente. Comparação da Estrutura A web assenta sobre a Internet. Os web browsers standard operam por cima da arquitectura fornecendo ferramentas universais de acesso à informação. Os browsers recebem a informação em documentos HTML standard, fazem o parse dos documentos e geram uma estrutura hierárquica designada Document Object Model (DOM). Servidores web operam em localizações distribuídas, e respondem a pedidos de documentos HTML usando um protocolo standard, Hypertext Transport Protocol (HTTP). Muitos objectos fluem do servidor web para o browser segundo o modelo clientserver. Nestes objectos incluem-se: objectos HTML, gráficos, scripts, texto e outros objectos registados como Multi-Purpose Mail Extensions (MIME). Todos estes objectos e muitos outros vão de encontro ao objectivo da web, a acessibilidade da informação. Tal como a web, também a simulação distribuída assenta na Internet. Contudo, por razões de desempenho, algumas simulações podem ser restringidas a uma intranet ou sub-rede. No domínio da HLA, os federates operam numa federation segundo o paradigma peer-to-peer. Embora a HLA se tenha tornado um standard e incorpore a RTI e o ficheiro FOM, para os federates não foi definido nenhum standard. Os federates são tipicamente construídos de acordo com a necessidade da simulação. Uma das razões é que a HLA foi baseada na premissa de que nenhuma simulação consegue satisfazer todas as aplicações nem todos os utilizadores. No entanto, a premissa ignora a ideia de que uma ferramenta de simulação standard pode satisfazer a maioria dos utilizadores de simulação, tal como um web browser standard satisfaz a maioria dos utilizadores da web. Comparação das Operações As operações da web centram-se na geração e apresentação de documentos HTML documentos que incluem informação e funcionalidade. Os autores geram HTML estático usando editores, e os software developers geram HTML dinâmico com a assistência de código. A funcionalidade de um documento é testada carregando o documento num browser, e utilizando ferramentas de debug de scripts quando necessário. Tipicamente a criação de HTML e desenvolvimento e teste de scripts, pertencem a um pequeno processo cíclico, sendo estas actividades relativamente fáceis, e que requerem pouca disciplina a nível de engenharia de software. Os web browsers recebem informação para apresentar através de um processo que comunica com um servidor web, submete queries e descarrega HTML. Depois de receber a informação, o carregamento do documento 17

28 procede à medida que o browser faz o parse do HTML, assembla objectos DOM, e compila os scripts usando plug-ins de parsers de linguagens de script. Do lado da simulação distribuída, na HLA existe um processo de desenvolvimento de federations, chamado FEDEP [22]. Tipicamente o processo inclui os passos tradicionais do desenvolvimento de software, tais como desenho, codificação, e teste. O desenvolvimento de uma federation pode levar a uma quantidade considerável de trabalho e requerer uma elevada aptidão a nível de engenharia. À medida que os federates são desenvolvidos, estes vão sendo testados independentemente e com outros federates. A informação usada na simulação é pré-processada e associada com a lógica do programa à medida que os federates se inicializam e se juntam às federations em execução. Os federates trocam informação utilizando o mecanismo publish-and-subscribe incorporado na HLA. Os federates também enviam e recebem mensagens, chamadas interacções, para outros federates. Finalmente, os federates desassociam-se de uma federation e assim que esta termina, os analistas analisam a informação gerada pela simulação. Comparação da Comunicação A comunicação entre um browser e um servidor é realizada usando HTTP que assenta sobre TCP/IP. O browser estabelece uma conexão cliente-servidor, envia e recebe a informação, e fecha a conexão. O padrão de comunicação caracteriza-se por bursts infrequentes iniciados pelo utilizador. Os utilizadores não toleram erros aleatórios ou omissões de texto, por isso a comunicação HTTP é lossless. Comunicação na HLA é maioritariamente opaca e não conforme com standards. Uma RTI pode implementar a comunicação usando um protocolo proprietário, outra pode usar CORBA, e ainda outra pode usar comunicação inter-processo. À parte do protocolo, a comunicação é peer-to-peer, o que possibilita maior flexibilidade que comunicação cliente-servidor. Pequenos bursts frequentes caracterizam o padrão de comunicação na simulação distribuída. A flexibilidade disponível em algumas implementações da RTI permite comunicações lossless e lossy Web-Based Simulation As tecnologias web e as tecnologias de simulação distribuída têm crescido independentemente, e apesar da simulação distribuída preceder a web, vê-se que hoje é a web que influência a simulação distribuída. No passado, a web-based simulation era muito associada ao Java a operar sobre a HLA [29]. Também em [29] são apresentadas cinco áreas de foco da web-based simulation: Simulação como hipermédia: simulação de texto, imagem, áudio, vídeo a natureza do desenho da WWW permite a produção, armazenamento e descarregamento de informação que contenha qualquer tipo de elemento anterior. A simulação como aplicação web tem potencial para alterar as metodologias de ensino e treino da simulação como técnica, e de áreas que aplicam simulação (engenharia, física, biologia). 18

29 Metodologia de investigação de simulação: a facilidade para rapidamente colocar modelos, resultados, e publicações na web permite novas aproximações na conduta de investigação de simulação, e de investigação científica em geral. A publicação electrónica de modelos de simulação levanta considerações adicionais. Acesso baseado em web a programas de simulação: esta área inclui a execução remota de simulações existentes a partir de um web-browser através de forms HTML e scripts CGI, e o desenvolvimento de simulações mobile-code (ex. applets) que correm do lado do cliente. Simulação e modelação distribuída: nesta área incluem-se actividades que lidam com o uso da WWW e de tecnologias web-oriented (ex. CORBA, Java RMI) como infra-estrutura de suporte à execução de simulações distribuídas. Simulação da World Wide Web (WWW): modelação e análise da WWW para caracterização do desempenho e optimização. Do ponto de vista de um web developer, o objectivo principal da web-based simulation é permitir que as simulações sejam servidas, recebidas e processadas de forma standard usando tecnologias Internet e a WWW Web Services na Simulação Distribuída Actualmente a maioria dos sistemas distribuídos são desenvolvidos com base em web services. Derivado da utilização de standards abertos, os web services permitem a criação de serviços independentemente da linguagem e da arquitectura do servidor e dos clientes e permitem ainda interoperabilidade entre aplicações. O SOAP e o XML são dois dos standards abertos utilizados pelos web services. O SOAP é um protocolo para envio de mensagens através de HTTP entre servidor e clientes e o XML é o formato dessas mesmas mensagens. A vantagem em usar HTTP é que os serviços podem ser efectuados mesmo através de medidas de segurança como firewalls, uma vez que o acesso HTTP não é normalmente restrito. SOAP SOAP significa Simple Object Access Protocol e foi desenvolvido em conjunto pela IBM, Microsoft e outras empresas. O SOAP é um protocolo de invocação de objectos baseado em XML e foi originalmente desenvolvido para a comunicação de aplicações distribuídas usando HTTP, permitindo o acesso a serviços e objectos remotos e, a servidores independentemente da plataforma. O SOAP, segundo a especificação original (1.0) [32], tinha dois objectivos principais: 1. Fornecer um protocolo standard de invocação de objectos construído sobre standards da Internet, usando o HTTP como transporte e XML para a codificação da informação; 2. Criar um protocolo extensível e formato que possa evoluir. 19

30 A ideia principal por trás da criação do SOAP foi melhorar a interoperabilidade da Internet e integrar vários sistemas de negócio. O DCOM e o Corba são considerados muito complexos, especialmente do lado do cliente. O SOAP por outro lado é simples, fácil de utilizar por cima de protocolos de comunicação existentes, baseado em XML e independente de implementação. Sendo baseado em XML, é compatível com muitos modelos de programação e permite que as aplicações facilmente troquem informação através da Internet. Envio de mensagens As mensagens SOAP são codificadas usando XML, o que requer que toda a informação seja enviada na forma de cadeia de caracteres (ASCII strings). A descrição da informação toma a forma de tags de início e fim, o que constitui metade ou mais do tamanho da mensagem. O processo de envio das mensagens SOAP pode ser dividido em várias etapas, que podem não corresponder directamente a funções numa implementação: 1. Percorrer as estruturas de informação que representam a mensagem; 2. Converter a representação máquina da informação para ASCII; 3. Escrever o ASCII para o buffer; 4. Iniciar a transmissão pela rede. Recepção de mensagens Apesar de a recepção de mensagens SOAP ser de algum modo o inverso de enviar, os problemas são diferentes. Conceptualmente pode-se dividir o processo de recepção nas seguintes etapas: 1. Leitura da rede para o buffer; 2. Fazer o parse do XML; 3. Handle dos elementos; 4. Converter os dados ASCII para representação máquina. XML O XML, extensible Markup Language, foi desenvolvido em 1996 sob a supervisão do W3C, World Wide Web Consortium. É uma linguagem para documentos que contenham informação estruturada, tendo sido criado com o propósito de facilitar a partilha de informação entre diferentes sistemas, especialmente os que comunicam via Internet. O XML é uma forma restrita de SGML, Standard Generalized Markup Language, sendo os documentos XML compatíveis com documentos SGML. O SGML é uma linguagem de markup mais genérica, logo mais complexa. O que se procurou com o XML foi obter algo mais simples e flexível, que suporta ainda a leitura por parte de humanos e das aplicações. 20

31 Através do XML é possível criar tags, ao contrário por exemplo do HTML, que é inflexível tanto ao nível da semântica das tags como do conjunto de tags que disponibiliza. Um documento XML não é mais que um ficheiro de texto hierarquicamente estruturado. Papel na Simulação Distribuída Dadas as características do SOAP aliadas às do XML, esta dupla pode ser aplicada à Simulação Distribuída como mecanismo de comunicação entre clientes e servidores, independentemente da plataforma destes e da linguagem em que foram desenvolvidos, permitindo assim uma maior interoperabilidade entre componentes de simulação ou simuladores. Uma das desvantagens do desenvolvimento de simuladores distribuídos através da utilização de web services é o baixo desempenho [34]. Esta deve-se ao facto da informação ser enviada em XML e devido ao processo de serialização e deserialização dos dados. Na procura de uma solução para este problema, existente não só na simulação distribuída mas também nos sistemas distribuídos em geral, foi desenvolvida uma ferramenta, o gsoap [35]. O gsoap é uma ferramenta madura, activa, open source e foi desenvolvida tendo como prioridades o desempenho e interoperabilidade de arquitecturas máquina. O XML é considerado a intersecção natural entre a web e a modelação [36]. Na modelação de uma simulação procura-se capturar conceitos como estado, evento, e tempo do modelo ou objecto de interesse. A flexibilidade do XML e o facto deste permitir a criação de tags, abre a possibilidade de se criarem novas linguagens de markup, especificas ou não, para a modelação da simulação em questão. Ao nível dos standards de simulação, o XML tem sido apontado como formato de eleição para a descrição de características de partes, produtos, etc. e respectivos requisitos de recursos e processos. 2.6 HLA versus a Web-Based Simulation Como foi indicado no tópico anterior, uma das áreas de desenvolvimento da Web-Based Simulation é a Simulação e Modelação Distribuída, estando envolvidas arquitecturas como o Corba, o RMI e a.net Framework ou mais concretamente o.net Remoting, que têm em comum com a HLA o facto de suportarem a execução distribuída de aplicações, por isso têm algumas similaridades, no entanto, as diferenças existentes podem ter um impacto significativo no desenvolvimento das aplicações ou na sua execução. De seguida será apresentada uma breve comparação destas quatro importantes arquitecturas, focando o impacto que estas têm na simulação distribuída. 21

32 Arquitectura Distribuída A comparação destas três arquitecturas será regulada pelos seguintes elementos básicos de uma arquitectura distribuída: linguagem de definição de interfaces, gestor de objectos e serviço de nomes. A linguagem de definição de interfaces é bastante importante no suporte a aplicações distribuídas porque estas requerem um nível de comunicações mais abstracto que as aplicações comuns. As interfaces são a forma ideal de permitir a interoperabilidade entre objectos distribuídos, pois um objecto deve assumir o mínimo possível acerca da implementação de determinado método de outro objecto visto que esse método pode-se referir a outros objectos localizados noutro computador. Para isso uma interface não é mais do que um contracto estabelecido para a implementação de objectos e contêm apenas uma lista de métodos a disponibilizar por esse objecto. O gestor de objectos é responsável por passar a referência de objectos a clientes que os requisitem, instanciar objectos e realizar o marshalling do pedido de objectos de máquinas diferentes. O gestor de objectos esconde os detalhes acerca da localização dos objectos, sendo indiferente se um método se invoca local ou remotamente. O serviço de nomes é o mecanismo através do qual o servidor informa os clientes acerca dos objectos disponíveis para acesso. Sabendo quais os objectos que podem ser servidos, os clientes facilmente descobrem a assinatura e os argumentos dos vários métodos que podem invocar sobre esses objectos, obtêm uma referência para um objecto, e começam a invocar métodos nesse objecto. Desta forma uma aplicação distribuída adquire um comportamento flexível e dinâmico, sendo possível estabelecer a comunicação entre objectos apenas em tempo de execução. Em relação aos três elementos indicados no parágrafo anterior, na HLA, a linguagem de definição de interfaces é definida utilizando o OMT, o gestor de objectos é representado pela RTI e o serviço de nomes corresponde à execução da federation Corba Em 1989 foi formado o Object Management Group (OMG) com o intuito de promover a adopção de sistemas distribuídos de objectos de modo a fazer-se uso dos sistemas distribuídos e ter as vantagens da utilização de programação orientada a objectos no desenvolvimento de aplicações. Em 1991, este grupo, um consórcio de múltiplas empresas, deu por concluída a primeira especificação da arquitectura Corba (Common Object Request Broker Architecture). Na figura 2.3 pode-se observar a arquitectura que constitui o Corba. 22

33 Figura 2.3: Arquitectura do Corba De seguida é apresentada a arquitectura Corba segundo os elementos enumerados anteriormente. Linguagem de Interfaces A linguagem de interfaces usada pelo Corba designa-se por Interface Definition Language (IDL). A IDL é puramente declarativa e a sua sintaxe é praticamente igual à do C++, só que a IDL apenas define interfaces e não implementações. Numa aplicação Corba, a IDL é primeiro escrita e depois compilada para código para uma linguagem suportada. Os elementos definidos na IDL são implementados nessa linguagem usando o código gerado como base. As linguagens actualmente suportadas pelo Corba são: Ada, C, C++, Cobol, Java e Smalltalk. A IDL permite definir módulos, interfaces, tipos, atributos e métodos. Um módulo permite agrupar interfaces e outras definições IDL em unidades lógicas namespaces. Uma interface descreve que métodos estão disponíveis num objecto Corba que implemente essa interface. A linguagem de definição de interfaces suporta herança múltipla, como a IDL é só declarativa, a herança diz respeito às interfaces e não à implementação que é interna aos objectos. A IDL suporta tipos básicos (short, int, long, float, double, char, boolean, etc.), tipos construídos e referências de objectos. Os atributos correspondem a propriedades dos objectos e são usados para armazenar informação, sendo normalmente acedidos através de métodos de acesso. Um atributo pode ser apenas de leitura ou de escrita/leitura. Um método é identificado pelo nome, tipo dos argumentos que recebe e tipo do retorno. Tanto os clientes como os servidores Corba podem ser implementados em qualquer das linguagens suportadas e funcionar sem terem conhecimento das linguagens uns dos outros. 23

34 Gestor de Objectos No Corba o mecanismo responsável pela gestão de objectos tem o nome de Object Request Broker (ORB). O ORB medeia o mecanismo de invocação entre objectos, sendo apresentado na literatura do Corba como o bus a que se ligam as componentes de software para interactuarem entre si, estejam localizadas local ou remotamente. Conceptualmente o ORB representa uma entidade entre objectos cliente e servidor, mas na realidade consiste em software que reside tanto no cliente como no servidor. Quando um cliente requisita um objecto a mensagem vai primeiro para ORB na sua máquina, o ORB cliente estabelece ligação com o ORB servidor, o servidor retorna uma referência do objecto requisitado para o seu ORB e este retorna essa referência para o cliente. Todo este processo é transparente para as aplicações, implica apenas que todas as máquinas envolvidas possuam o software de ORB instalado. No ORB é possível fazer invocação dinâmica e estática de objectos. Na invocação dinâmica, a mensagem de invocação é produzida no momento da invocação, a partir da informação existente sobre o método. A invocação estática envolve stubs cliente e servidor (a estes dá-se o nome de skeleton ), em que cada um deles é uma interface para o objecto no servidor. Um stub liga um objecto ao ORB na sua máquina e é geralmente gerado a partir da IDL, de modo a que o programador não tenha de se preocupar em escrever chamadas ao ORB. O skeleton é usado apenas no servidor e o stub é apenas usado no cliente, e visto que toda a comunicação é feita através do ORB, o skeleton e o stub não necessitam estar na mesma linguagem. Serviço de Nomes O Corba fornece um mecanismo designado Dynamic Invocation Interface (DII) que evita a utilização de stubs pré-compilados. Com o DII, o cliente descobre o objecto remoto, de seguida é obtida a interface desse objecto de modo a que o cliente determine qual o método que pretende invocar. A informação acerca do método (argumentos, retorno e excepções) é então obtida, podendo-se criar e enviar o pedido de invocação do método no objecto remoto. Um servidor pode criar um repositório de interfaces que contenha as interfaces que podem ser dinamicamente acedidas pelos clientes. Estes repositórios são pesquisáveis para localizar interfaces que interessem ao cliente. Numa LAN a interoperabilidade entre clientes é transparente, pois o ORB em cada máquina é capaz de descobrir todos os outros ORBs. No espaço da Internet, deve ser utilizado o Internet Inter-Orb Protocol (IIOP) que estende o protocolo TCP/IP RMI O Remote Method Invocation (RMI) foi incluído como fazendo parte das bibliotecas standard do Java a partir da versão 1.1 do Java Development Kit (JDK 1.1). O RMI estende o modelo de objectos do Java de forma a suportar objectos distribuídos na linguagem Java. Em particular, 24

35 permite que os objectos invoquem métodos em objectos remotos usando a mesma sintaxe que usariam para objectos locais. Estando incluído no Java, o RMI partilha a independência de plataforma deste, sendo necessária apenas uma instalação da Java Virtual Machine (JVM) na máquina onde será implementado um cliente ou servidor RMI, sendo assim compatível com a JVM de qualquer plataforma. A figura 2.4 apresenta a arquitectura que representa o RMI. Figura 2.4: Arquitectura do RMI Linguagem de Interfaces Fazendo parte do Java, é natural que o RMI use a sintaxe de interfaces deste como a sua própria linguagem de interface dos objectos. Esta opção simplifica e facilita o desenho e implementação das aplicações. As únicas exigências são: a interface deve herdar da interface java.rmi.remote e todos os métodos definidos numa interface remota devem levantar excepções do tipo java.rmi.remoteexception ou de uma das suas subclasses. Gestor de Objectos No que toca à implementação de objectos remotos, o RMI tem uma aproximação bastante semelhante à do Corba, podendo uma interface ser compilada separadamente em stub cliente e skeleton servidor. Tipicamente os objectos remotos são subclasse de UnicastRemoteObject e implementam a interface remota desejada. O objecto remoto é instanciado e associado a um nome usando a classe java.rmi.naming, em que esta usa um sistema parecido ao do Uniform Resource Locator (URL): rmi://maquina:porto/nomedoobjecto. A execução de objectos remotos envolve algum risco a nível de segurança, daí que no RMI seja necessário utilizar uma instância de Java.rmi.RMISecurityManager para implementar uma policy de segurança. O RMISecurityManager é responsável por determinar se os métodos estão a ser invocados local ou remotamente e por proteger contra operações inseguras ou não autorizadas. 25

36 Serviço de Nomes O RMI possui uma classe que faculta a atribuição de nomes a objectos remotos, a listagem de objectos disponíveis num servidor e a procura de objectos específicos, essa classe é o java.rmi.registry.registry. Visto que esta classe tem de estar em execução como processo à parte antes que os objectos possam ser registados e servidos, ela desempenha o papel de servidor no RMI. O registry pode ser usado pelo cliente para localizar classes remotas, descarregar os stubs cliente apropriados e invocar métodos. Fazendo o RMI parte do Java, o cliente não precisa de nenhum processo especial para executar, sendo toda a comunicação feita através das classes de comunicação do JDK, que neste caso fazem uso do TCP/IP. O RMI, como faz parte do Java, só pode interagir com aplicações que não estejam implementadas em Java através da Java Native Interface (JNI) Net Framework A framework.net é uma plataforma de computação que simplifica o desenvolvimento de aplicações em ambientes altamente distribuídos, o que a torna uma opção a considerar na área da simulação distribuída. A framework tem dois componentes principais: a common language runtime e a biblioteca de classes.net. A common language runtime gere código em tempo de execução, fornecendo serviços como a gestão de memória, gestão de threads, e invocações remotas, para além de forçar a coerência de tipos e outras formas de verificações de código de modo a assegurar segurança e robustez às aplicações desenvolvidas. A biblioteca de classes não é mais do que uma colecção, compreensiva e object-oriented, de classes que podem ser utilizadas para o desenvolvimento de aplicações. A arquitectura geral da.net Framework é a apresentada na figura 2.5, em que se pode verificar o suporte de várias linguagens de programação, isto só é possível porque essas linguagens compilam para uma linguagem intermédia conhecida como Common Intermediate Language (CIL), através de compilação just-in-time (JIT) para código nativo. A combinação destes conceitos é conhecida como Common Language Runtime (CLR). A grande desvantagem desta framework é o facto de se ficar limitado ao sistema operativo Windows. 26

37 Figura 2.5: Arquitectura da.net Framework Um componente importante da.net framework e que é útil no desenvolvimento de aplicações de simulação com funcionalidades distribuídas é o.net Remoting, que é apresentado de seguida..net Remoting A infra-estrutura.net Remoting é uma aproximação abstracta à comunicação entre processos, que separa os objectos remotos de um cliente específico ou do domínio aplicacional de um servidor e de um mecanismo específico de comunicação. O.Net Remoting utiliza canais para comunicar as chamadas de métodos entre dois objectos em diferentes domínios de aplicação. Os canais dependem de formatters para criar a representação dos dados que irão ser enviados nesses mesmos canais. A seguinte lista, complementada com a figura 2.6, sumaria os principais componentes da infraestrutura.net Remoting: Channels: o.net Remoting fornece dois tipos de implementação de canais HttpChannel e TcpChannel; Formatters: cada canal usa um formatter diferente para codificar os dados, e são fornecidos dois: BinaryFormatter: usa a representação binária nativa; SoapFormatter: usa XML-encoded SOAP como formato de mensagem. 27

38 Sinks: a infra-estrutura.net Remoting suporta pontos de extensão chamados sinks. As classes do BinaryFormatter e do SoapFormatter são exemplos de sinks fornecidos pelo sistema. Podendo o programador criar sinks próprios para realizar tarefas como comprimir dados ou cifrá-los; Proxy: os clientes comunicam com objectos remotos através de uma referência para um objecto proxy. A proxy é uma representação do objecto remoto no domínio local da aplicação. A proxy protege o cliente da complexidade associada ao marshaling (formatação dos parâmetros a enviar ao objecto remoto) e aos protocolos de comunicação remota; Host: este é o processo que aloja o endpoint remoto. A escolha do host afecta o tipo de canal que pode ser utilizado para comunicar com o objecto remoto. Os possíveis host são: Aplicação Windows do tipo serviço; Internet Information Services (IIS) e ASP.Net; Aplicação Windows; Aplicação de consola. Figura 2.6: Elementos da Infra-estrutura.NET Remoting O ponto forte do sistema remoto reside na sua facilidade de permitir a comunicação entre objectos de aplicações de diferentes domínios ou mesmo processos, usando diferentes protocolos de transporte, formatos de serialização, tempo de vida dos objectos, e modos de criação de objectos. Adicionalmente possibilita intervir em praticamente qualquer etapa do processo de comunicação. No que toca aos elementos básicos de uma arquitectura distribuída tem-se que como linguagem de interfaces a.net Framework suporta diversas linguagens: C#, C++, Visual Basic.Net e J#. O gestor 28

39 de objectos cria uma proxy para o objecto requisitado pelo cliente, este processo é feito através de uma invocação do GetObject da classe Activator. A.Net Framework não possui um serviço de nomes, os objectos/serviços são registados no sentido em que são disponibilizados pelo servidor (através do método RegisterWellKnownServiceType da classe RemotingConfiguration), mas não há qualquer forma centralizada de registo como um serviço de nomes. A tabela seguinte resume as características de cada uma das arquitecturas anteriores, segundo os elementos enumerados no início desta secção: Linguagem de Interfaces Gestor de Objectos Serviço de Nomes HLA OMT RTI Execução da federation Corba IDL ORB DII RMI Java (java.rmi.remote) Java (java.rmi.naming) Java (java.rmi.registry.registry).net C#, C++, Visual Basic.Net e Proxy Não possui (registo de J# (Activator.GetObject) objectos/serviços através de RemotingConfiguration. RegisterWellKnownServiceType Tabela 2.1: Resumo das características do HLA, Corba, RMI e.net Framework Comparação Após se ter apresentado as quatro arquitecturas, é agora feita uma comparação entre as suas principais características. O Corba ao suportar diversas linguagens permite que o middleware seja implementado na linguagem mais conveniente e que este interaja com qualquer cliente Corba. Embora o HLA possua APIs para Ada, C++ e Java, a responsabilidade da interacção entre federates implementados em diferentes linguagens é colocada na implementação da RTI, o que traz alguma complexidade ao desenvolvimento de federations HLA em múltiplas linguagens, ao contrario do que se passa no Corba. No caso do RMI, não é possível desenvolver em diferentes linguagens, apenas em Java, sendo necessário usar a JNI para a interacção com programas que não tenham sido desenvolvidos em Java. A.Net Framework suporta tal como o Corba diversas linguagens, mas o seu leque é mais restrito que neste último. Suporta devido ao facto de compilar para uma linguagem intermédia a CIL. O HLA é uma arquitectura específica para simulações distribuídas, ao passo que o Corba, o RMI e o.net são arquitecturas genéricas para aplicações distribuídas. Por esta razão, o HLA tem um melhor suporte à simulação através das regras aplicadas às federations e de serviços específicos de simulação, como por exemplo o Time Management este serviço é essencial para o correcto funcionamento de uma federation, pois todas as simulações possuem o conceito de um relógio simulado. Para as restantes arquitecturas não faz sentido que possuam este tipo de serviços, 29

40 porque uma aplicação implementada numa destas arquitecturas pode nem ter a noção de tempo simulado. A comunicação entre objectos remotos no Corba, RMI e.net Framework é mais complexa pois estes suportam comunicação directa entre objectos, ao contrário do HLA que apenas fornece serviços para publicar e subscrever. O HLA tem uma característica única: a de permitir a transferência de ownership de um objecto, o que se torna uma ferramenta de modelação bastante poderosa em certo tipo de simulações. Já no Corba, RMI e.net o mesmo não se passa, um objecto instanciado por um servidor pertencerá sempre a esse servidor. O HLA não especifica o protocolo usado para a comunicação, deixando esta questão em aberto para a implementação da RTI, o que pode impedir a interoperabilidade entre RTIs de diferentes fabricantes. O Corba e o RMI usam ambos protocolos específicos. No RMI é utilizado o TCP/IP, enquanto que o Corba usa um protocolo próprio, o IIOP, que assenta sobre o TCP/IP. A.Net Framework disponibiliza dois tipos de canais (TcpChannel e HttpChannel). O RMI tem a vantagem de possuir um mecanismo como o RMISecurityManager, que dá alguma segurança às operações remotas. O JDK possui ainda classes que implementam cifras e assinaturas digitais. A tabela 2.2 resume a comparação anterior: Aplicações alvo HLA Aplicações de simulação distribuída Corba Aplicações distribuídas genéricas RMI Aplicações distribuídas genéricas.net Aplicações distribuídas genéricas Linguagens suportadas HLA APIs para Ada, C++ e Java (restringida à implementação da RTI) Corba Diversas linguagens RMI Java.Net C#, C++, Visual Basic.Net e J# Protocolo de comunicação HLA Não especifica Corba IIOP (assenta em TCP/IP) RMI TCP/IP.Net TcpChannel e HttpChannel Comunicação entre objectos remotos HLA Disponibiliza serviços para publicar e subscrever Corba Comunicação directa entre objectos 30

41 RMI.Net HLA Corba RMI.Net HLA Corba RMI.Net Comunicação directa entre objectos Comunicação directa entre objectos Time Management Suporta (através do conceito de relógio simulado) Não suporta Não suporta Não suporta Transferência de ownership de um objecto Suporta Não suporta Não suporta Não suporta Tabela 2.2: Comparação entre HLA, Corba e RMI Conclusão As quatro arquitecturas suportam os três elementos enumerados anteriormente: linguagem de interfaces, gestor de objectos e serviço de nomes; excepto a.net Framework em relação ao serviço de nomes. A HLA, por definição, é mais apropriado para aplicações ligadas à simulação por ser específica para estas e devido aos serviços orientados à simulação que fornece. O Corba ao não estar ligado a uma única linguagem possibilita a integração de legacy systems com sistemas actuais implementados mesmo em outras linguagens. O RMI tira partido da superioridade do Java como linguagem orientada aos objectos, sendo uma importante ferramenta para os programadores Java que desenvolvem aplicações distribuídas, derivado da flexibilidade inerente à invocação remota de métodos. A.Net Framework, tal como o Corba, suporta várias linguagens e, tal como o RMI, é executada numa máquina virtual. Mas ao contrário destes dois não é multi-plataforma, estando-se limitado ao sistema operativo Windows. Permite no entanto uma elevada flexibilidade no desenvolvimento de aplicações distribuídas devido à sua poderosa biblioteca. 2.7 Sumário A aplicação dos sistemas distribuídos à simulação trouxe diversos benefícios, no entanto a passagem de simuladores de execução sequencial a simuladores de execução distribuída é difícil, pois existem muitos mais factores a ter em conta. Foi aqui dada uma breve introdução à Simulação e à Simulação Distribuída, tendo sido apresentada no contexto desta última um dos principais factores extra a ter em conta no desenvolvimento de sistemas distribuídos a sincronização. 31

42 A reutilização e a interoperabilidade estão na base da criação da arquitectura HLA. A HLA define as regras, a interface specification e o object model template, para suportar a reutilização e a interoperabilidade entre os federates. Para além da HLA a interoperabilidade é um conceito também comum à Web-Based Simulation, não fosse esta possível principalmente devido aos web services, como se pôde constatar. Conclui-se portanto que a interoperabilidade tem um papel importante na Simulação Distribuída, o que faz sentido, pois esta facilita o desenvolvimento de componentes simulador por parte de diferentes fabricantes e a sua utilização em aplicações já existentes. A Simulação Distribuída é uma área na qual já é feita investigação há bastantes anos, cerca de 30 anos, sendo por isso extensa e possuindo diversos tópicos de discussão. Nem todos foram aqui referidos como é óbvio, procurou-se mostrar aqueles que tiveram mais impacto na história da Simulação Distribuída. No entanto ainda existe trabalho a fazer, nomeadamente ao nível de standards, adoptando e reformulando existentes e criando novos. Melhorar a tecnologia dos web services de modo a puderem ser utilizados em simulações que requerem um elevado desempenho. 32

43 Capítulo 3 Arquitectura O presente capítulo propõe a arquitectura de alto nível para o simulador em questão. Sendo feita uma descrição dessa arquitectura e também de cada uma das partes que a constituem, que são a Órbita e a Atitude. 3.1 Descrição Geral O simulador tem como objectivo testar os algoritmos de estimação e controlo que irão ser incorporados no satélite. A simulação de um satélite divide-se em duas partes: simulação de órbita movimento do satélite em volta da terra tendo em conta a força gravítica da terra, sol e lua; e simulação de atitude movimento de rotação do satélite devido à velocidade angular e forças aplicadas pelos propulsores de correcção de atitude. Portanto, faz sentido que na arquitectura do simulador do satélite se contemple um módulo que represente a órbita e outro que represente a atitude, e que estes interajam entre si. Na figura 3.1 é apresentada a arquitectura de mais alto nível do simulador. Esta incorpora os módulos referidos no parágrafo anterior, Órbita e Atitude, e ainda dois módulos que fazem parte do software de voo AOCS, isto é, fazem parte do satélite, mas que a nível de implementação não farão parte do simulador, sendo sim processos externos com interfaces adequadas à comunicação com o simulador, mas que são considerados na arquitectura pois são eles que contém os algoritmos de estimação e controlo. Na prática o simulador irá apenas simular a órbita e a atitude, enviando esta última, dados para o módulo de estimação e recebendo dados do módulo controlo. A Estimação irá estimar/prever a atitude do satélite com base na órbita, no instante seguinte, para que o Controlo altere a atitude caso esta não esteja a apontar na direcção desejada. 33

44 Órbita Atitude Estimação Controlo Figura 3.1: Arquitectura de alto nível do Simulador Os principais componentes do simulador e que aqui importam discutir são a Órbita e a Atitude, em que a primeira é responsável pela criação de um Universo que contêm uma representação da Terra, da Lua e do Sol e a representação orbital do satélite. Contento o componente Atitude a representação da atitude do satélite, que inclui sensores, actuadores, painéis solares, etc. Ambos estes módulos são de seguida apresentados em maior pormenor. 3.2 Órbita No módulo Órbita é simulada a trajectória percorrida pelo satélite, ou seja, a sua órbita. Para isso é necessário ter em conta os corpos celestes que possam afectar a trajectória do satélite, e neste caso são considerados a Terra, a Lua e o Sol. A Terra e o Sol são ainda importantes a nível de referenciais. É preciso ter também em consideração, a data de lançamento da missão para puder calcular a posição dos corpos celestes e do satélite nessa data, pois a órbita é calculada a partir desse momento. O comportamento desejado no módulo Órbita está patente na figura 3.2. Este módulo recebe como entrada de dados um dt (de quanto em quanto tempo é calculada a posição e velocidade dos corpos celestes e do satélite), a duração da simulação, a data de lançamento da missão, entre outros dados. Após receber estes dados é realizado o cálculo das condições iniciais, que corresponde a calcular a posição e velocidade inicial dos corpos celestes e do satélite. De seguida o módulo deve ficar num ciclo enquanto a sua duração for inferior à duração da simulação. Em cada iterada deste ciclo é realizado o método Runge-Kutta [39] de quarta ordem sobre o sistema composto pela Terra, Lua, Sol e Satélite. 34

45 Figura 3.2: Comportamento desejado da Órbita Com isto consegue-se a simulação da órbita do satélite numa determinada data e durante um determinado tempo. 3.3 Atitude O módulo Atitude simula a atitude do satélite e à semelhança do projecto Órbita também tem em consideração a data de lançamento da missão, além de outros dados necessários à inicialização de entidades físicas, como por exemplo o momento angular do satélite. A simulação da atitude do satélite é feita com base nos seus sensores e actuadores, e tem em conta os dados vindos da simulação da órbita (posição do satélite por exemplo). Como se pode verificar pela figura 3.3, o comportamento pretendido para o módulo Atitude é bastante parecido com o do módulo Órbita. No entanto, a Atitude é constituída por entidades diferentes das da Órbita, portanto o método Runge-Kutta será aplicado a essas entidades, como é o caso do referencial inercial e dos binários (torques). Após a execução do Runge-Kutta é feita uma actualização da atitude a nível de actuadores, sensores, etc. 35

46 Figura 3.3: Comportamento desejado para a Atitude É portanto desta forma feita a simulação da atitude com a duração e data introduzidas no sistema. 3.4 Sumário O modelo proposto assenta na clara separação do módulo Órbita do módulo Atitude, de modo a que cada um tenha o seu próprio processo de execução e assim permitir o desenvolvimento do simulador como aplicação distribuída. O comportamento de alto nível de cada um dos módulos referidos é bastante parecido, pois ambos executam uma simulação, mas de modelos distintos. 36

47 Capítulo 4 Implementação Neste capítulo descreve-se a implementação da arquitectura descrita no capítulo anterior. É justificada a tecnologia utilizada e é dada uma descrição de cada projecto que compõe o simulador, bem como das classes que os constituem e ainda detalhes de implementação relevantes. No final do capítulo são enumeradas as principais fases de execução do simulador implementado. 4.1 Tecnologia O programa que representa o simulador foi desenvolvido na linguagem C++, utilizando-se as Managed Extensions para C++ da Microsoft.Net Framework 1.1 e ainda uma biblioteca chamada Practical C++ Sockets [38]. A primeira versão do simulador foi desenvolvida em C++, pois as pessoas envolvidas só conheciam praticamente C, por ser ensinado numa disciplina de introdução à programação em diversos cursos do IST, no entanto sabiam da existência do C++ e de algumas das suas capacidades, como por exemplo, a definição de classes, overloading de operadores, etc. A versão por mim desenvolvida está também em C++, devido ao aproveitamento de código que se fez e para permitir que os restantes membros da equipa possam fazer verificações e correcções aos algoritmos. C++ Managed Extensions As Managed Extensions para C++ são uma derivação da Microsoft à linguagem C++, que inclui extensões gramaticais e sintácticas, palavras-chave e atributos, de forma a aproximar a sintaxe e a linguagem do C++ à framework.net. Estas extensões permitem que o código C++ seja gerado para CLR na forma de managed code, continuando a interagir com código nativo. Managed refere-se ao facto de que a aplicação desenvolvida corre ou é gerida pela máquina virtual do.net que funciona como uma sandbox aumentando a segurança na forma de verificações em tempo de execução, como por exemplo, verificações associadas a buffers. Uma das funcionalidades do.net e destas extensões bastante úteis é a existência de um garbage collector (GC), que facilita bastante a vida do programador, não tendo este de se preocupar com a 37

48 gestão da memória, podendo-se concentrar no desenvolvimento das funcionalidades realmente importantes da aplicação em questão. O interessante destas extensões é que permitem que se tire partido das funcionalidades presentes na framework.net, o que inclui as facilidades no desenvolvimento de aplicações distribuídas na Internet, através do uso do.net Remoting, o que é o caso das simulações distribuídas. Uma vez que a linguagem escolhida foi o C++, utilizaram-se também as Managed Extensions para C++, e por consequência a.net Framework. Esta opção permitiu que a componente distribuída fosse desenvolvida de uma forma mais rápida, e se tirasse partido das funcionalidades oferecidas pela.net Framework. A grande desvantagem que esta utilização trouxe foi que o simulador (parte de cálculo) passou a ser executável apenas em ambiente Windows. Em relação às restantes opções apresentadas em 2.6, a escolha não poderia ser o RMI devido à sua dependência do Java. A HLA e o Corba requeriam que se despendesse mais algum tempo para os conhecer melhor, especialmente a nível de implementação/utilização. No entanto, de entre os dois a escolha seria a HLA devido à sua orientação à simulação distribuída. A biblioteca Practical C++ Sockets não é mais do que um wrapper de classes de um subconjunto da API Berkeley C Socket para sockets TCP e UDP. Recorreu-se à utilização desta biblioteca para efectuar a comunicação entre a GUI/Consola e o Gestor, uma vez que existe uma incompatibilidade entre as Managed Extensions para C++ e a biblioteca wxwidgets usada na GUI. 4.2 AOCS Simulador Distribuído A nível de implementação considerou-se o simulador como sendo constituído por duas partes: a visual/gráfica que lida com a representação gráfica dos dados, seja na forma de gráficos cartesianos ou de objectos 3D com animações que representam os corpos celestes (Terra, Lua e Sol) ou o próprio Satélite, e que lida também com a configuração da simulação, que implica entrada de dados por parte do utilizador; e a parte de cálculo que lida com a simulação propriamente dita e sobre a qual incide grande parte deste trabalho. Esta última parte, de cálculo, não contempla nenhuma forma de interagir com o simulador, e visto que isso faz parte da componente visual que foi desenvolvida por outra pessoa em paralelo, houve a necessidade de criar algo que o permitisse fazer, daí se ter criado um projecto chamado Consola, que não é mais do que uma aplicação de linha de comandos que faz arrancar a simulação e assim testar o simulador enquanto este não se encontrava completo. A arquitectura da implementação do simulador é a presente na figura 4.1, que como se pode verificar é constituída pelos componentes introduzidos no capítulo anterior (Arquitectura), Órbita e Atitude, e ainda pelos componentes Gestor e GUI ou Consola. 38

49 Figura 4.1: Arquitectura da implementação do simulador A arquitectura representada na figura 4.1 facilitou o desenvolvimento do simulador como aplicação distribuída. Mais concretamente, a Órbita, Atitude, Gestor e GUI/Consola, são processos independentes que podem estar geograficamente distribuídos e a comunicar através da Internet. Os primeiros três processos enumerados anteriormente (Órbita, Atitude e Gestor) funcionam como servidores e clientes uns dos outros, ao passo que a GUI/Consola é apenas cliente do Gestor. Para a implementação deste simulador distribuído assumiu-se que o sistema será limitado a um reduzido número de utilizadores e simulações em simultâneo. O Gestor é essencial para este sistema em particular, porque é ele que coordena o início e fim da simulação, o acesso aos dados por parte da GUI/Consola, a gravação destes mesmos dados para ficheiro, etc. A GUI acede às coordenadas do satélite (presentes no Gestor) em keplerianos ou cartesianos para apresentar a posição do satélite em tempo-real, bem como as posições orbitais dos restantes corpos celestes simulados. O simulador foi desenvolvido de forma gradual, módulo a módulo. Começou-se por desenvolver a Órbita por ser mais simples, estar completamente especificada a nível algorítmico e haver dados que permitissem verificar o seu correcto funcionamento. De seguida implementou-se a componente do Gestor responsável pela comunicação com o módulo Órbita, de forma a haver alguma interacção com esta através da rede. Após se testar esta interacção, passou-se ao desenvolvimento do módulo Atitude, que foi realizado em duas fases: numa primeira fase criou-se o core deste módulo, que não contempla Sensores e Actuadores, tendo estes ficado para a segunda fase. No entanto, antes de passar a esta segunda fase, desenvolveu-se a componente do Gestor associada à comunicação 39

50 com a Atitude, e ainda o módulo Consola, tendo assim ficado o ciclo de comunicação completo. Por último procedeu-se à criação dos Sensores e Actuadores do módulo Atitude, terminando esta. À medida que se ia desenvolvendo cada módulo, ia-se também testando o seu funcionamento, no caso da Órbita utilizou-se um software chamado STK para simular órbitas e verificar a correcção dos valores calculados pelo simulador AOCS. A implementação completa do simulador (contando com a GUI ou neste caso a Consola) é composta por quatro projectos executáveis, e por outros projectos que resultam em bibliotecas (estáticas ou dinâmicas). Os projectos executáveis são considerados executáveis porque são aplicações per se. De seguida são descritos os vários constituintes do simulador, no lugar da GUI será apresentada a Consola Bibliotecas Foram criados no total oito projectos que originam bibliotecas, quatro estáticas (.lib) e quatro dinâmicas (.dll). A criação de bibliotecas facilita o desenvolvimento, pois permite separar o código de forma lógica, e a reutilização de código em diferentes projectos sem ter de o repetir em todos esses projectos. Os projectos que originam bibliotecas são: Vector, Matrix, Time, Relativity, e os necessários à comunicação: NICommonTypes, NICommonM, NICommonO, NICommonA. Todos eles são apresentados de seguida. Bibliotecas Estáticas As bibliotecas estáticas criadas são basicamente classes que representam entidades matemáticas e o tempo, e são usadas por praticamente todos os projectos executáveis, podendo ser integradas noutros projectos/simuladores. O facto de as classes poderem ser reutilizadas noutros projectos e de não virem a sofrer actualizações frequentes levou a que se escolhesse torná-las bibliotecas estáticas e não dinâmicas, além de que desta forma o desempenho também é favorecido. As bibliotecas estáticas são: Vector - Esta biblioteca tem a classe Vector do objecto que representa um vector 3D. Pode ser usado para conter a posição ou velocidade de qualquer corpo num dado referencial. A classe define as operações algébricas básicas como a soma, subtracção, o produto escalar e vectorial com outro vector, bem como a multiplicação por um escalar. Matrix - A classe Matrix contida nesta biblioteca representa uma matriz, podendo ser usada como matriz de atitude de um corpo rígido. Para isso, possui três vectores que são as colunas da matriz de atitude do corpo. Suporta manipulações algébricas básicas tais como a soma com outra matriz, a subtracção e o produto por um escalar ou o produto com um vector. Time - A esta biblioteca pertence a classe SimTime que representa o tempo no simulador. Ela armazena a data e hora inicial, actual e final, em ano, mês, dia, hora, minuto e segundo. Guarda também a duração real da simulação em segundos, possui ainda as principais funcionalidades 40

51 do calendário Julianos, não tendo nenhuma limitação na escolha da data. O tempo é incrementado através do operador +=, existindo ainda outras diversas operações definidas. Relativity - Nesta biblioteca está definido um conjunto de métodos que permitem calcular vectores relativos a vectores, vectores relativos a matrizes e matrizes relativas a matrizes. Depende por isso das bibliotecas Vector e Matrix apresentadas anteriormente. Bibliotecas dinâmicas As bibliotecas dinâmicas não são mais do que interfaces com métodos definidos e que servem principalmente para permitir a comunicação entre os diferentes módulos, ou seja, é a definição dos métodos remotos. Embora uma das bibliotecas não seja a definição de métodos, mas sim tipos/estruturas de dados. As bibliotecas dinâmicas são: NICommonTypes - Esta biblioteca contém a definição de estruturas de dados comuns às várias bibliotecas dinâmicas. Como as restantes bibliotecas dinâmicas representam as interfaces com a definição dos métodos remotos disponibilizados por cada um dos principais componentes do simulador (Gestor, Órbita e Atitude), as estruturas de dados aqui definidas suportam os dados que são enviados entre os componentes enumerados. Os dados são apenas structs do C++ com ints e doubles, ou seja, tipos básicos do C++. NICommonM - Nesta biblioteca está definida a interface ICommonM, que contém a definição dos métodos que o Gestor disponibiliza aos outros componentes. Disponibiliza por exemplo métodos à GUI que fornecem a esta dados dos vários corpos (Satélite, Terra, Lua, Sol), à Órbita e à Atitude métodos para a gravação de dados para ficheiro. NICommonO - A interface ICommonO definida nesta biblioteca permite que a Órbita disponibilize métodos ao Gestor e à Atitude. Um deles é por exemplo o arranque da simulação da Órbita por parte do Gestor, outro é o envio de dados relativos à posição do Satélite para a Atitude. NICommonA - Esta biblioteca define a interface ICommonA, a qual permite que a Atitude sirva o Gestor. Um exemplo é o arranque da simulação como acontece com a Órbita Executáveis De seguida são introduzidos os projectos executáveis que compõem o trabalho que serviu de base a esta dissertação, estes são a Órbita, a Atitude, o Gestor e a Consola. A Órbita e a Atitude são constituídas por diversas classes representando algumas componentes do satélite ao qual o simulador desenvolvido diz respeito. O Gestor é uma aplicação que faz a ponte entre a parte visual e a parte de cálculo. Para a Órbita, Atitude e Gestor será dada uma pequena descrição do projecto e das classes que o constituem. 41

52 Antes de passar à descrição de cada projecto executável e das suas classes, importa aqui referir alguns detalhes de implementação e opções tomadas a este nível. Uma vez que se está perante um sistema distribuído na Internet é normal o recurso a threads para servir vários clientes, sejam eles utilizadores ou outros servidores, e até a nível interno de um processo, é o caso por exemplo da Atitude que possui uma thread dedicada ao pedido de dados à Órbita de forma a que a thread principal não fique bloqueada para efectuar esses pedidos. Com o uso das threads vem a utilização de mecanismos de controlo de concorrência, para que não haja a alteração de dados partilhados entre diferentes threads, enquanto um método de uma thread estiver a operar sobre esses mesmos dados. Esta situação ocorre por exemplo na Órbita, onde uma thread produz dados para um buffer que é partilhado com a thread que atende os pedidos da Atitude, e em que esta última retira dados desse buffer. Para a comunicação entre os diferentes módulos (excepto entre GUI/Consola e Gestor), optou-se por utilizar TcpChannel ao invés de HttpChannel, que é a outra opção que o.net Remoting fornece. Fez-se esta escolha porque os sockets TCP são mais eficientes que os sockets HTTP, derivado do facto de que o TcpChannel envia os dados, por defeito, em formato binário, ao passo que o HttpChannel serializa os dados para o formato XML, embora isto possa ser configurado. A escrita dos dados de saída, considerados os resultados da simulação, foi implementada para ficheiros de texto com um formato próprio e não para ficheiros XML, por exemplo. A escrita para ficheiro XML ia implicar a escrita de mais dados, tags e atributos, o que iria fazer com que esse processo fosse mais lento e o ficheiro resultante tivesse uma maior dimensão. A opção tomada tanto serve para os dados escritos em ficheiro, como para os dados que são enviados do Gestor para a GUI/Consola, visto que neste caso é usada uma cadeia de caracteres. Existe ainda um header file, chamado Constants, que define as constantes comuns a todos os projectos, não pertencendo por isso a nenhum projecto em particular. Órbita Para a implementação deste módulo foi praticamente traduzir para código a arquitectura apresentada no capítulo anterior, introduzindo apenas as funcionalidades necessárias ao comportamento distribuído. Na figura 4.2 encontram-se representadas todas as classes necessárias à implementação da Órbita, e sua comunicação com os restantes módulos. Neste módulo existe um detalhe de implementação que vale a pena aqui referir que é a realização de um buffering antes de começar a simulação propriamente dita. A realização deste buffering surgiu porque o módulo atitude é computacionalmente mais pesado e precisa pelo menos dos dados do primeiro cálculo realizado pela órbita, então para evitar que a atitude ficasse bloqueada à espera de dados da órbita, o que se fez foi colocar a órbita a criar um buffer inicial e a enviá-lo para a atitude antes mesmo desta última dar início à sua simulação, para além disso a atitude quando já 42

53 se encontra em modo de simulação e pede dados à órbita, esta envia-lhe dados que a atitude apenas precisará mais tarde, o que só é possível devido à existência do buffering inicial. Universe -_dt : double -_time : SimTime -_earth : Earth -_moon : Moon -_sun : Sun -_satellite : Satellite Body #_mass : double #_position : Vector #_velocity : Vector Satellite -msat : double = 120 Sun -mus : double = sunmus CelestialBody -G : double = celestialbodyg Moon -mum : double = moonmum Earth -mue : double = earthmue -R : double = earthr -J[5] : double = {-1, 0, e-6, -2.54e-6, -1.61e-6} OrbitEngine -_year : int -_month : int -_day : int -_hour : int -_minute : int -_second : int -_set : int -_simulduration : double -_dt : double -_a : double -_e : double -_i : double -_raan : double -_w : double -_m : double -_universe : Universe * -_clientmanager : ClientManager * CommonO -_orbitengine : OrbitEngine * OrbitServer -_orbitport : int -_channel : TcpChannel gc * ClientManager -_manageraddress : String gc * -_managerport : int -_icommonm : ICommonM gc * Figura 4.2: Classes do projecto Órbita Descrição das diversas classes pertencentes ao módulo Órbita: Body - A classe Body contém toda a informação que é comum a todos os corpos definidos para o simulador. Define a massa, posição e velocidade do corpo. CelestialBody - A classe CelestialBody é uma subclasse da anterior Body e neste simulador apenas contém a constante gravitacional do corpo celeste, porque se trata de uma constante que tanto a Terra, como a Lua e o Sol possuem, mas não o Satélite. 43

54 Satellite - A classe Satellite é uma subclasse da Body, herdando desta as variáveis massa, posição e velocidade. Representa o próprio satélite sendo apenas necessário definir o valor da sua massa. Earth - A classe Earth é subclasse da classe CelestialBody e contém a massa da Terra, o seu raio equatorial e os coeficientes do desenvolvimento polinomial de Legendre do potencial gravítico (estes são correcções aplicadas a planetas não esféricos). Moon - Tal como a classe anterior também a classe Moon é uma subclasse da classe CelestialBody, mas apenas contém definida a massa da Lua. Sun - Como as duas anteriores classes, a classe Sun também é subclasse da classe CelestialBody, contendo também apenas a massa do Sol. Universe - A classe Universe constitui o sistema planetário considerado neste simulador, isto é, os corpos celestiais Terra, Lua, Sol e o Satélite. ClientManager - A classe ClientManager é a responsável por efectuar as invocações remotas da Órbita ao Gestor. Contém o endereço IP da máquina onde está localizado o processo Gestor, bem como o seu porto de escuta de ligações, e ainda uma instância da sua interface (ICommonM) para que a Órbita lhe possa enviar informação e efectuar pedidos. OrbitEngine - Esta classe suporta toda a simulação do lado da Órbita, pois possui uma instância da classe ClientManager e da Universe, entre outros dados para as condições iniciais. CommonO - A classe CommonO implementa os métodos definidos na interface da Órbita (ICommonO). Apenas contém uma instância da classe anterior OrbitEngine de modo a puder invocar-lhe métodos para a obtenção de informação da simulação da Órbita. OrbitServer - A classe OrbitServer é responsável por disponibilizar um canal para que os processos dos outros projectos (Gestor e Atitude) possam comunicar com o processo Órbita. Atitude Na implementação do módulo Atitude, e tal como na Órbita, além de se considerar o que está representado na arquitectura do capítulo anterior, foi necessário também introduzir funcionalidades associadas à comunicação com os outros módulos. A figura 4.3 contém as classes que permitiram a implementação do módulo Atitude, com vista à simulação desta e à sua comunicação com os outros módulos. Algumas destas classes representam componentes existentes no próprio satélite, como a roda inercial, o sensor de sol e o de estrelas, o giroscópio, etc. 44

55 Satellite -_dt : double -_time : SimTime -_l : Vector -_earthrelposition : Vector -_orbitalposition : Vector -_earthposition : Vector -_moonposition : Vector -_inertia : Inertia -_refinercial : Angular -_reforbital : Angular -_planisphere : Matrix -_magnetic : Matrix -_moonangles : Vector -_sunvector : Vector -_sunangles : Vector -_earthangles : Vector -_sensors : Sensors -_solarpanels : SolarPanels -_actuators : Actuators Actuators -_direction : Vector -_thrusterstorque : Vector -_thrustersforce : Vector -_reactionwheel : ReactionWheel -_thrusteracs1 : Thruster -_thrusteracs2 : Thruster -_thrusteracs3 : Thruster -_thrusteracs4 : Thruster -_thrusterrcs1 : Thruster -_thrusterrcs2 : Thruster -_thrusterrcs3 : Thruster -_thrusterrcs4 : Thruster -_thrusterocs : Thruster -_canparams : Thruster -_actuationtype : bool -_thrustertype : bool Angular -_angularvelocity : Vector -_attitudematrix : Matrix -_quaternion : Quaternion -_previousquaternion : Quaternion Inertia -_xx : double -_yy : double -_zz : double -_xy : double -_xz : double -_yz : double StarSensor Quaternion -_q1 : double -_q2 : double -_q3 : double -_q4 : double -_attitudematrix : Matrix -_refquaternion : Quaternion -_measurequaternion : Quaternion ReactionWheel -_mtorque : Vector -_inertia : double -_actualinput : double -_speedrpm : double -_a0coeff : double -_a1coeff : double -_a2coeff : double -_b2coeff : double -_inputv : double -_speed : double Gyroscope -_centerrotation : Matrix -_toprotation : Matrix -_sensors : Vector -_gyromeasure : Vector -_truew : double -_measuredw : double -_reads : double -_assemblyerrors : double Magnetometer -_attitudematrix : Matrix -_magfield : Vector -_magmeasure : Vector -_magsat : Vector -_igrflatitude : double -_igrflongitude : double -_igrfaltitude : double -_igrfdate : double Sensors -_sunsensora : SunSensor -_sunsensorb : SunSensor -_sunsensorc : SunSensor -_sunsensord : SunSensor -_magnetometer : Magnetometer -_starsensor : StarSensor -_gyroscope : Gyroscope AttitudeEngine -_year : int -_month : int -_day : int -_hour : int -_minute : int -_second : int -_simulduration : double -_dt : double -_satellite : Satellite * -_clientorbit : ClientOrbit * SunSensor -_attitudematrix : Matrix -_anglessensor : Vector -_anglessat : Vector -_sun : Vector -_sunmeasure : Vector -_x : double -_y : double -_h : double -_lengthx : double -_lengthy : double -_flageclipse : int Thruster -_position : Vector -_satrelposition : Vector -_force : Vector -_torque : Vector -_forceintensity : double -_finaltime : double -_n : int SolarPanels -_attitudematrix : Matrix -_sunvector : Vector -_commandedrotation : double -_sunangle : double -_eclipse : int CommonA -_attitudeengine : AttitudeEngine * AttitudeServer -_attitudeport : int -_channel : TcpChannel gc * ClientOrbit -_icommono : ICommonO gc * Figura 4.3: Classes do projecto Atitude São de seguida descritas cada uma das classes representadas na figura anterior: Satellite - A classe Satellite neste projecto tem uma implementação diferente da realizada no projecto Órbita. Aqui contém sensores, actuadores, painéis solares, uma representação da inércia, entre outros elementos que permitem realizar a simulação da atitude do satélite. Inertia - A classe Inertia representa o objecto matriz de inércia. Foi desenhada para conter a matriz de inércia simétrica do satélite, descrita nos eixos geométricos. Quaternion - Esta classe representa a atitude em quaterniões, e contém apenas quatro decimais que representam a parte vector (q1, q2, q3) e a parte decimal (q4) de um quaternião. 45

56 Angular - A classe Angular é o objecto atitude do satélite. É composta pelo vector velocidade angular, matriz atitude e um quaternião. Contém toda a informação cinemática angular de um corpo rígido. Sensors - A classe Sensors contém instâncias de todos os sensores existentes no satélite e por sua vez no simulador. SunSensor - A classe SunSensor define o sensor de sol do satélite. StarSensor - A classe StarSensor define o sensor de estrela do satélite. Magnetometer - A classe Magnetometer define o magnetómetro do satélite. Gyroscope - A classe Gyroscope define o giroscópio do satélite. Actuator - A classe Actuator contém instâncias de todos os actuadores presentes no satélite. Thruster - Esta classe define cada thruster do satélite, seja orbital ou de atitude. ReactionWheel - A classe ReactionWheel representa a roda inercial presente no satélite. magigrf - O magigrf não se trata de uma classe mas sim de um ficheiro de funções (open source) que permitem calcular o campo magnético da Terra usando o modelo IGRF10. GaussError - Esta classe define o erro gaussiano, definido pelo erro médio e o desvio padrão. Pode ser adicionado a qualquer valor com um formato decimal (double). ClientOrbit - A classe ClientOrbit é a responsável por efectuar as invocações remotas da Atitude à Órbita. Contém o endereço IP da máquina onde está localizado o processo Órbita, bem como o seu porto de escuta de ligações, e ainda uma instância da sua interface (ICommonO) para que possa obter dados da simulação da Órbita. AttitudeEngine - Esta classe suporta toda a simulação do lado da Atitude, pois possui uma instância da classe ClientOrbit e da classe Satellite, entre outros dados para as condições iniciais. CommonA - A classe CommonA implementa os métodos definidos na interface da Atitude (ICommonA). Apenas contém uma instância da classe anterior AttitudeEngine de modo a puder invocar-lhe métodos para a obtenção de informação da simulação da Atitude. AttitudeServer - A classe AttitudeServer é responsável por disponibilizar um canal para que o processo do projecto Gestor possa comunicar com o processo Atitude. Gestor O Gestor é o responsável por fazer a ponte entre a GUI/Consola e a Órbita e a Atitude, funcionando como um ponto central para o início e fim da simulação e a gravação de dados para ficheiro, 46

57 podendo no futuro efectuar autenticações de utilizadores no sistema, entre outras funcionalidades que se achem interessantes e úteis desenvolver, de modo a tornar o simulador mais seguro, robusto e com mais opções de funcionamento. Este módulo Gestor possui mecanismos de buffer para receber os dados provenientes da Órbita e da Atitude e que serão enviados para a GUI/Consola. Na subsecção Tecnologia deste mesmo capítulo referiu-se a utilização de uma biblioteca chamada Practical C++ Sockets, esta é usada mais concretamente na classe GUIServer que será apresentada. As classes constituintes deste módulo são as presentes na figura 4.4: ManagerEngine -_clientorbit : ClientOrbit * -_clientattitude : ClientAttitude * ClientAttitude -_icommona : ICommonA gc * -_ic : GCAttitudeInitialConditions gc * ClientOrbit -_icommono : ICommonO * -_ic : GCOrbitInitialConditions gc * GUIServer -_manager : ManagerEngine * CommonM ManagerServer Figura 4.4: Classes do projecto Gestor A seguir é descrita cada uma das classes da figura anterior: ClientOrbit - A classe ClientOrbit é a responsável por efectuar as invocações remotas do Gestor à Órbita. Contém o endereço IP da máquina onde está em execução o processo Órbita, bem como o seu porto de escuta de ligações, e ainda uma instância da sua interface (ICommonO) para que o Gestor possa comunicar com a Órbita. ClientAttitude - A classe ClientAttitude é praticamente igual à classe ClientOrbit, a diferença reside no facto de que a ClientAttitude efectua as invocações remotas do Gestor à Atitude, tendo para isso uma instância da interface ICommonA, além dos restantes elementos que permitem ao Gestor saber a localização do processo Atitude que pretende contactar. ManagerEngine - Esta é a principal classe do projecto Manager, contém por isso uma instancia da ClientOrbit e da ClientAttitude, bem como outros objectos para suportar a gravação de dados vindos da Órbita e da Atitude para ficheiro, e para suportar o envio de alguns destes dados para a GUI a pedido desta. 47

58 CommonM - A classe CommonM implementa os métodos definidos na interface do Gestor, a ICommonM. ManagerServer - A classe ManagerServer é responsável por disponibilizar um canal para que os processos dos outros projectos (Órbita e Atitude) possam comunicar com o processo Gestor. GUIServer - A classe GUIServer recebe os pedidos da GUI/Consola e reencaminha-os para a classe ManagerEngine, ou seja, à semelhança da classe ManagerServer disponibiliza um canal para a GUI/Consola, mas com base na implementação da biblioteca Practical C++ Sockets. Consola O projecto Consola foi criado para que fosse possível executar o simulador e testá-lo, uma vez que o projecto GUI estava a ser desenvolvido ao mesmo tempo que o resto do simulador por outro aluno. A Consola não tem tantas funcionalidades quanto a GUI, mas serviu perfeitamente para os propósitos que foi criada. Com a Consola é possível enviar os dados das condições iniciais ao Gestor, como se fossem introduzidos pelo utilizador através da interface gráfica, indicar-lhe para dar início e fim à simulação, e ainda obter deste os dados dos corpos Terra, Lua, Sol e Satélite. Resumidamente, a Consola permitiu a obtenção de resultados de simulação sem a sua visualização gráfica. A comunicação com o Gestor é feita através da utilização da já referida biblioteca Practical C++ Sockets, em que os dados são enviados numa cadeia de caracteres para evitar incompatibilidades de máquinas. Os dados enviados para o Gestor são lidos de um ficheiro XML, pois facilita a identificação dos dados e a sua alteração. 4.3 Fases de Execução São quatro as principais fases de execução do simulador, correspondendo estas às etapas ou estados da simulação. Na situação correspondente à primeira fase tem-se três servidores (Órbita, Atitude e Gestor) e um cliente, em que não estão ainda em comunicação, como se vê na figura 4.5. Tem-se assim o sistema pronto a iniciar uma sessão de simulação. 48

59 Figura 4.5: Primeira fase de execução do Simulador Na figura 4.6 está representada a segunda fase, na qual, após o utilizador ter inserido os dados necessários ao arranque da simulação, a GUI/Consola envia esses mesmos dados para o Gestor (1) que consequentemente os envia para a Órbita e para a Atitude (2). Com estes dados a Órbita e a Atitude calculam as condições iniciais do sistema, após este cálculo a Atitude pede o buffer inicial (3 e 4) à Órbita (que esta criou no cálculo das suas condições iniciais). Após todo este processo, o simulador fica pronto a dar início à simulação propriamente dita. Figura 4.6: Segunda fase de execução do Simulador A terceira fase, figura 4.7, corresponde ao início da simulação, em que a GUI/Consola emite esse mesmo comando ao Gestor (1), que por sua vez o retransmite à Órbita e à Atitude (2). 49

60 Figura 4.7: Terceira fase de execução do Simulador A quarta fase é representada pela figura 4.8, que contêm várias operações que são executadas em paralelo, daí que a figura não tenha numeração de ordenação dos eventos. Esta situação demonstra o funcionamento do sistema em plena execução da simulação. O módulo Órbita simula a órbita do satélite e vai enviando esses dados para o Gestor. O módulo Atitude simula a atitude do satélite, quando precisa de dados relativos à órbita deste pede-os à Órbita, e ao mesmo tempo vai enviando os dados resultantes da simulação da atitude para o Gestor. A GUI/Consola ao longo da simulação vai pedindo dados da simulação (sejam de órbita ou de atitude) ao Gestor, que lhe envia quando os tem. Figura 4.8: Quarta fase de execução do Simulador 50