Embed Size (px)
Citation preview
Setembro 2007
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
i
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.
ii
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
iii
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
iv
Índice
1 Introdução ..................................................................................................................................... 1
2 Estado d’Arte ................................................................................................................................ 4
2.1 Simulação Distribuída ...................................................................................................... 5
2.1.1. SMP – Simulation Model Portability ........................................................................ 7
2.1.2. Razão da Distribuição .............................................................................................. 8
2.2 PDES – Parallel and Distributed Event Simulation ......................................................... 9
2.3 DVE – Distributed Virtual Environment .......................................................................... 11
2.4 HLA – High Level Architecture ...................................................................................... 12
2.4.1. Nomenclatura ........................................................................................................ 13
2.4.2. Rules ...................................................................................................................... 14
2.4.3. Interface Specification ........................................................................................... 15
2.4.4. Object Model Template .......................................................................................... 15
2.4.5. Suporte à Reutilização e Interoperabilidade.......................................................... 16
2.5 Web e a Simulação Distribuída ..................................................................................... 16
2.5.1. Web-Based Simulation .......................................................................................... 18
2.5.2. Web Services na Simulação Distribuída ............................................................... 19
2.6 HLA versus a Web-Based Simulation ........................................................................... 21
2.6.1. Arquitectura Distribuída ......................................................................................... 22
2.6.2. Corba ..................................................................................................................... 22
2.6.3. RMI ........................................................................................................................ 24
2.6.4. .Net Framework ..................................................................................................... 26
2.6.5. Comparação .......................................................................................................... 29
2.7 Sumário ......................................................................................................................... 31
3 Arquitectura ................................................................................................................................ 33
3.1 Descrição Geral ............................................................................................................. 33
3.2 Órbita ............................................................................................................................. 34
3.3 Atitude ............................................................................................................................ 35
3.4 Sumário ......................................................................................................................... 36
v
4 Implementação ........................................................................................................................... 37
4.1 Tecnologia ..................................................................................................................... 37
4.2 AOCS Simulador Distribuído ......................................................................................... 38
4.2.1. Bibliotecas ............................................................................................................. 40
4.2.2. Executáveis ........................................................................................................... 41
4.3 Fases de Execução ....................................................................................................... 48
4.4 Sumário ......................................................................................................................... 51
5 Caso de Estudo .......................................................................................................................... 52
5.1 Simulação da missão ..................................................................................................... 52
5.1.1. Dados de Entrada .................................................................................................. 52
5.1.2. Dados de Saída ..................................................................................................... 53
5.1.3. Tempo de Execução .............................................................................................. 56
5.2 Sumário ......................................................................................................................... 56
6 Resultados .................................................................................................................................. 57
6.1 Influência do parâmetro dt ............................................................................................. 57
6.2 Comparação de canais de comunicação ...................................................................... 58
6.3 Localhost versus Rede .................................................................................................. 58
6.4 Comparação de versões................................................................................................ 59
6.5 Tráfego de dados na rede ............................................................................................. 60
6.6 Sumário ......................................................................................................................... 62
7 Conclusão e Trabalho Futuro ..................................................................................................... 64
7.1 Trabalho Futuro ............................................................................................................. 65
A Manual de Utilização .............................................................................................................. 69
A.2 Órbita ............................................................................................................................. 69
A.3 Atitude ............................................................................................................................ 69
A.4 Gestor ............................................................................................................................ 70
A.5 Consola .......................................................................................................................... 71
B Runge-Kutta ........................................................................................................................... 73
vi
Lista de Tabelas
Tabela 2.1: Resumo das características do HLA, Corba, RMI e .Net Framework ........................ 29
Tabela 2.2: Comparação entre HLA, Corba e RMI ....................................................................... 31
Tabela 6.1: Teste com dts iguais ................................................................................................... 57
Tabela 6.2: Teste dts diferentes .................................................................................................... 57
Tabela 6.3: Teste utilizando TcpChannel ...................................................................................... 58
Tabela 6.4: Teste utilizando HttpChannel ..................................................................................... 58
Tabela 6.5: Teste em localhost ..................................................................................................... 59
Tabela 6.6: Teste em rede ............................................................................................................ 59
Tabela 6.7: Comparação de versões ............................................................................................ 60
vii
Lista de Figuras
Figura 2.1: Arquitectura de Alto Nível do SMP2 .............................................................................. 7
Figura 2.2: HLA Runtime Infrastructure ......................................................................................... 13
Figura 2.3: Arquitectura do Corba ................................................................................................. 23
Figura 2.4: Arquitectura do RMI .................................................................................................... 25
Figura 2.5: Arquitectura da .Net Framework ................................................................................. 27
Figura 2.6: Elementos da Infra-estrutura .NET Remoting ............................................................. 28
Figura 3.1: Arquitectura de alto nível do Simulador ...................................................................... 34
Figura 3.2: Comportamento desejado da Órbita ........................................................................... 35
Figura 3.3: Comportamento desejado para a Atitude ................................................................... 36
Figura 4.1: Arquitectura da implementação do simulador ............................................................. 39
Figura 4.2: Classes do projecto Órbita .......................................................................................... 43
Figura 4.3: Classes do projecto Atitude ........................................................................................ 45
Figura 4.4: Classes do projecto Gestor ......................................................................................... 47
Figura 4.5: Primeira fase de execução do Simulador ................................................................... 49
Figura 4.6: Segunda fase de execução do Simulador .................................................................. 49
Figura 4.7: Terceira fase de execução do Simulador .................................................................... 50
Figura 4.8: Quarta fase de execução do Simulador ...................................................................... 50
Figura 6.1: Tráfego de dados da Órbita ........................................................................................ 61
Figura 6.2: Tráfego de dados da Atitude ....................................................................................... 61
Figura 6.3: Tráfego de dados do Gestor ....................................................................................... 62
Figura 6.4: Tráfego de dados da Consola ..................................................................................... 62
Figura A.1: Linha de comandos da Órbita ..................................................................................... 69
Figura A.2: Linha de comandos da Atitude ................................................................................... 70
Figura A.3: Linha de comandos do Gestor .................................................................................... 70
Figura A.4: Linha de comandos da Consola ................................................................................. 71
viii
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
ix
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
1
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 (1643–1716)
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]
2
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 2006-2007, 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
3
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.
4
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.
5
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.
6
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.
7
2.1.1. 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
8
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.
2.1.2. 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.
9
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
10
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, permitindo-
lhe 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 Tnull
enviada de LPA para LPB é uma promessa de LPA indicando que não irá enviar a LPB mensagens
com marcas temporais inferiores a Tnull. 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.
11
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,
12
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 1996. A HLA beneficiou de outros esforços anteriores do DoD: o Distributed
13
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.
2.4.1. 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);
14
• 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.
2.4.2. 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;
15
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.
2.4.3. 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.
2.4.4. 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
16
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.
2.4.5. 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
17
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 client-
server. 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
18
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.
2.5.1. 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).
19
• 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.
2.5.2. 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.
20
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.
21
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.
22
2.6.1. 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.
2.6.2. 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.
23
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.
24
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.
2.6.3. 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,
25
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.
26
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).
2.6.4. .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.
27
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 infra-
estrutura .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.
28
• 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
29
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
J#
Proxy
(Activator.GetObject)
Não possui (registo de
objectos/serviços através de
RemotingConfiguration.
RegisterWellKnownServiceType
Tabela 2.1: Resumo das características do HLA, Corba, RMI e .Net Framework
2.6.5. 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,
30
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
31
RMI Comunicação directa entre objectos
.Net Comunicação directa entre objectos
Time Management
HLA Suporta (através do conceito de relógio simulado)
Corba Não suporta
RMI Não suporta
.Net Não suporta
Transferência de ownership de um objecto
HLA Suporta
Corba Não suporta
RMI Não suporta
.Net 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.
32
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.
33
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.
34
Órbita
ControloEstimação
Atitude
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.
35
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.
36
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.
37
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
38
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.
39
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
40
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.
4.2.1. 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
41
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.
4.2.2. 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.
42
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á
43
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.
-_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 *
OrbitEngine
-_orbitEngine : OrbitEngine *
CommonO
-_orbitPort : int-_channel : TcpChannel __gc *
OrbitServer
-_managerAddress : String __gc *-_managerPort : int-_iCommonM : ICommonM __gc *
ClientManager
#_mass : double#_position : Vector#_velocity : Vector
Body
-G : double = celestialBodyG
CelestialBody
-muE : double = earthMUE-R : double = earthR-J[5] : double = {-1, 0, 1082.63e-6, -2.54e-6, -1.61e-6}
Earth
-muM : double = moonMUM
Moon
-mSat : double = 120
Satellite
-muS : double = sunMUS
Sun
-_dt : double-_time : SimTime-_earth : Earth-_moon : Moon-_sun : Sun-_satellite : Satellite
Universe
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.
44
• 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.
45
-_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
Satellite
-_attitudeMatrix : Matrix-_sunVector : Vector-_commandedRotation : double-_sunAngle : double-_eclipse : int
SolarPanels
-_angularVelocity : Vector-_attitudeMatrix : Matrix-_quaternion : Quaternion-_previousQuaternion : Quaternion
Angular
-_q1 : double-_q2 : double-_q3 : double-_q4 : double
Quaternion-_xx : double-_yy : double-_zz : double-_xy : double-_xz : double-_yz : double
Inertia
-_sunSensorA : SunSensor-_sunSensorB : SunSensor-_sunSensorC : SunSensor-_sunSensorD : SunSensor-_magnetometer : Magnetometer-_starSensor : StarSensor-_gyroscope : Gyroscope
Sensors
-_attitudeMatrix : Matrix-_anglesSensor : Vector-_anglesSat : Vector-_sun : Vector-_sunMeasure : Vector-_x : double-_y : double-_h : double-_lengthX : double-_lengthY : double-_flagEclipse : int
SunSensor
-_attitudeMatrix : Matrix-_refQuaternion : Quaternion-_measureQuaternion : Quaternion
StarSensor
-_attitudeMatrix : Matrix-_magField : Vector-_magMeasure : Vector-_magSat : Vector-_igrfLatitude : double-_igrfLongitude : double-_igrfAltitude : double-_igrfDate : double
Magnetometer
-_centerRotation : Matrix-_topRotation : Matrix-_sensors : Vector-_gyroMeasure : Vector-_trueW : double-_measuredW : double-_reads : double-_assemblyErrors : double
Gyroscope
-_position : Vector-_satRelPosition : Vector-_force : Vector-_torque : Vector-_forceIntensity : double-_finalTime : double-_n : int
Thruster
-_mTorque : Vector-_inertia : double-_actualInput : double-_speedRPM : double-_a0Coeff : double-_a1Coeff : double-_a2Coeff : double-_b2Coeff : double-_inputV : double-_speed : double
ReactionWheel-_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
Actuators
-_year : int-_month : int-_day : int-_hour : int-_minute : int-_second : int-_simulDuration : double-_dt : double-_satellite : Satellite *-_clientOrbit : ClientOrbit *
AttitudeEngine
-_attitudePort : int-_channel : TcpChannel __gc *
AttitudeServer
-_iCommonO : ICommonO __gc *
ClientOrbit
-_attitudeEngine : AttitudeEngine *
CommonA
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.
46
• 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,
47
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:
-_iCommonA : ICommonA __gc *-_ic : GCAttitudeInitialConditions __gc *
ClientAttitude
-_iCommonO : ICommonO *-_ic : GCOrbitInitialConditions __gc *
ClientOrbit
CommonM
-_manager : ManagerEngine *
GUIServer
-_clientOrbit : ClientOrbit *-_clientAttitude : ClientAttitude *
ManagerEngine
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.
48
• 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.
49
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).
50
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
51
4.4 Sumário
Neste capítulo justificou-se a tecnologia utilizada na implementação do simulador e apresentou-se a
arquitectura que serviu de base a essa mesma implementação. A arquitectura definida aliada à
tecnologia utilizada permitiu que se desenvolvesse o simulador com características distribuídas com
maior facilidade, para isso contribuiu a clara separação entre o que é simulação de órbita, simulação
de atitude, gestão destas simulações e a sua visualização.
52
Capítulo 5
Caso de Estudo
Com o presente capítulo pretende-se antes de apresentar resultados de desempenho exemplificar a
utilização do simulador recorrendo à simulação da missão ESEO, isto é, usando os dados que serão
utilizados nessa simulação. Mais concretamente, serão aqui indicados quais os dados, de entrada e
de saída, o seu formato, e ainda o tempo de execução da simulação.
Para realizar uma simulação é necessário ter em execução quatro aplicações, são elas a Atitude, a
Órbita, o Gestor e a GUI ou a Consola. Em cada uma destas é necessário introduzir dados, como
por exemplo, os portos de escuta de comunicação da aplicação em questão e o IP de outra
aplicação que sirva de servidor. Este processo e os dados necessários encontram-se explicados no
Anexo Manual de Utilização.
5.1 Simulação da missão
5.1.1. Dados de Entrada
Existe um conjunto de dados que é necessário fornecer para a execução de uma simulação, alguns
já foram referidos anteriormente, como a data e hora da missão. Para além da data e da hora, há
também a duração da missão, dados específicos para a simulação da órbita e dados específicos
para a simulação da atitude. A seguir é apresentado o conteúdo do ficheiro XML usado na Consola
para fornecer esses mesmos dados, cujos valores são os que serão usados na missão ESEO:
<InitialConditions>
<!-- simulation duration -->
<duration>2419200.0</duration>
<!-- simulation date -->
<year>2008</year>
<month>11</month>
<day>21</day>
<hour>22</hour>
53
<minute>45</minute>
<second>0</second>
<!-- orbit -->
<orbitSet>1</orbitSet>
<orbitDt>1.0</orbitDt>
<orbitA>24478100.0</orbitA>
<orbitE>0.7922216300</orbitE>
<orbitI>7.0</orbitI>
<orbitRaan>270.0</orbitRaan>
<orbitW>178.0</orbitW>
<orbitM>360.0</orbitM>
<!-- attitude -->
<attitudeDt>1.0</attitudeDt>
<attitudeInertiaXX>7.5684</attitudeInertiaXX>
<attitudeInertiaYY>6.2306</attitudeInertiaYY>
<attitudeInertiaZZ>6.1261</attitudeInertiaZZ>
<attitudeInertiaXY>-0.1526</attitudeInertiaXY>
<attitudeInertiaXZ>-0.1109</attitudeInertiaXZ>
<attitudeInertiaYZ>0.1446</attitudeInertiaYZ>
<attitudeQ1>0</attitudeQ1>
<attitudeQ2>0</attitudeQ2>
<attitudeQ3>0</attitudeQ3>
<attitudeQ4>1</attitudeQ4>
<attitudeWX>0</attitudeWX>
<attitudeWY>0</attitudeWY>
<attitudeWZ>0</attitudeWZ>
</InitialConditions>
5.1.2. Dados de Saída
Como dados de saída do simulador, há a considerar dados relativos à órbita e dados relativos à
atitude, cujo formato será de seguida apresentado. Estes dados tanto são escritos em ficheiro como
são enviados para o Gestor e por sua vez para a GUI para visualização.
54
Dados de Saída da Órbita
Os dados de saída da Órbita têm todos o mesmo formato, porque se tratam de dados referentes a
corpos celestes e ao satélite, em que apenas interessa a posição (em metros) e velocidade (em
metros por segundo) no instante de tempo a que esses dados dizem respeito:
t;px;py;pz;vx;vy;vz
• t = instante de tempo da simulação ao qual os valores seguintes dizem respeito
• px = posição do corpo na coordenada x
• py = posição do corpo na coordenada y
• pz = posição do corpo na coordenada z
• vx = velocidade do corpo na coordenada x
• vy = velocidade do corpo na coordenada y
• vz = velocidade do corpo na coordenada z
Exemplos de saída de dados do satélite e dos diferentes corpos celestes:
Satélite
0;74199465043.0059;117233035678.904;50824557703.5096;-38001.7574913884;14021.0112958723;4462.68905466365
1;74199427041.0033;117233049692.199;50824562166.1676;-38002.2417337812;14005.5785200028;4462.62757922365
2;74199389038.5343;117233063690.061;50824566628.7663;-38002.6902882863;13990.1448039155;4462.57050834826
3;74199351035.6346;117233077672.488;50824571091.3101;-38003.1031516277;13974.7103054792;4462.51784244349
Terra
0;74199300623.1797;117227952360.601;50824537515.2936;-26245.1681089655;13622.8240377551;5906.2170474081
1;74199274378.01;117227965983.423;50824543421.5097;-26245.1711941262;13622.8192180876;5906.21495571679
2;74199248132.8373;117227979606.24;50824549327.7236;-26245.1742792858;13622.8143984195;5906.21286402519
3;74199221887.6615;117227993229.052;50824555233.9354;-26245.1773644444;13622.8095787506;5906.21077233328
Lua
0;73813477340.2748;117269446854.184;50817370379.0434;-26384.1914307333;12736.5872550958;5447.59087481602
1;73813450956.0832;117269459590.769;50817375826.6333;-26384.1918471758;12736.5821313423;5447.58882595827
2;73813424571.8911;117269472327.348;50817381274.2211;-26384.1922636174;12736.5770075944;5447.58677710335
3;73813398187.6987;117269485063.923;50817386721.8068;-26384.1926800581;12736.5718838519;5447.58472825126
Sol
Uma vez que o corpo celeste Sol é considerado o referencial da componente de simulação da
Órbita, os seus valores tanto de posição como de velocidade são todos zero, daí que se tenha
optado por não enviar estes dados para o Gestor, o que faz com que este corpo não tenha dados de
saída.
55
Dados de Saída da Atitude
Os dados de saída relevantes do módulo Atitude são os valores dos quaterniões no referencial
inercial e no referencial orbital, bem como os valores da velocidade angular nos mesmos
referenciais.
Os quaterniões são uma extensão ao conjunto dos números complexos e representam, neste caso,
a orientação do satélite em relação a cada um dos referenciais (inercial e orbital). Esta orientação é
dada por quatro grandezas.
O referencial inercial é um sistema de referência que está por exemplo parado, no caso da
componente de simulação da Atitude este sistema é representado pelo referencial da Terra.
O referencial orbital é o referencial cujo eixo dos zz aponta para o centro da Terra e o eixo dos yy
aponta para o equinócio vernal (ponto da órbita da Terra em que se regista uma igual duração do
dia e da noite, e que ocorre por volta do dia 21 de Março), sendo o eixo dos xx o produto externos
dos dois eixos anteriores.
Os dados relativos ao Quaternião têm o seguinte formato:
t;q1;q2;q3;q4
• t = instante de tempo da simulação ao qual os valores seguintes dizem respeito
• q1, q2 e q3 formam o vector (q1, q2, q3) da entidade matemática quaternião
• q4 representa o decimal da entidade matemática quaternião
Em relação aos dados da Velocidade Angular estes têm o formato:
t; wx;wy;wz
• t = instante de tempo da simulação ao qual os valores seguintes dizem respeito
• wx = velocidade angular na coordenada x
• wy = velocidade angular na coordenada y
• wz = velocidade angular na coordenada z
Exemplos de dados de saída do módulo Atitude:
Quaternião no Referencial Inercial
0;-0.227367386218888;-0.67103558040098;0.675349143797151;0.204740947278179
1;-0.227367386218888;-0.67103558040098;0.675349143797151;0.204740947278179
2;-0.227367386218888;-0.67103558040098;0.675349143797151;0.204740947278179
3;-0.227367386218888;-0.67103558040098;0.675349143797151;0.204740947278179
Quaternião no Referencial Orbital
0;0;0;0;1
1;-0.000556709116309714;-0.00102350035875634;-0.000768781886281072;0.999999025747719
2;-0.00111184930122281;-0.00204783882461487;-0.00153209085631595;0.999996111414883
3;-0.00166543286918305;-0.00307299826070007;-0.00228996781294891;0.999991269493121
56
Velocidade Angular no Referencial Inercial
0;0;0;0
1;0;0;0
2;0;0;0
3;0;0;0
Velocidade Angular no Referencial Orbital
0;-0.454734772437776;-1.34207116080196;1.3506982875943
1;-0.456920567288173;-1.34054921051389;1.35129349598394
2;-0.459099909352249;-1.33902892118824;1.35188135611595
3;-0.461272831015619;-1.33751028137388;1.35246192593133
5.1.3. Tempo de Execução
Para este caso de estudo foram medidos os tempos de execução dos módulos Órbita e Atitude, e o
total da simulação. Desta forma tem-se uma ideia de onde o simulador demora mais tempo que
como se pode verificar é na Atitude, o que é normal dada a sua complexidade e a interacção que
tem com a Órbita. Nestes tempos não estão contemplados os tempos de envio de dados da Órbita e
da Atitude para o Gestor, nem o tempo da consequente escrita destes dados para ficheiro, o que
faria aumentar os seguintes tempos:
Tempo de Execução da Órbita: 786.141 s
Tempo de Execução da Atitude: 6718.609 s
Tempo Total de Execução da Simulação: 6721.375 s
5.2 Sumário
Com este caso de estudo procurou-se apresentar a aplicação do simulador a uma situação real,
com os respectivos dados de entrada e os dados resultantes da simulação executada. Apresentou-
se ainda a título de curiosidade os tempos de execução deste mesmo caso, que representa a
simulação de 28 dias de missão do satélite.
57
Capítulo 6
Resultados
São aqui apresentados os resultados relativos à realização de alguns testes ao simulador. Estes
testes incidem principalmente sobre a componente de comunicação, seja a nível de desempenho ou
apenas de tráfego de dados. Juntamente com a descrição de cada teste é feita uma análise dos
resultados desse teste, havendo no final do capítulo uma síntese destas análises.
6.1 Influência do parâmetro dt
O parâmetro dt é um dos dados de entrada tanto da Órbita como da Atitude, podendo ter valores
distintos para cada um destes módulos, e representa a frequência com que é efectuado o cálculo
referente ao Runge-Kutta. O que de seguida se apresenta é a influência que este parâmetro tem na
simulação. O teste foi realizado com todos os módulos na mesma máquina e utilizou-se o valor
43200 segundos, que corresponde a 12 horas de missão, como duração da simulação.
Os tempos obtidos e presentes na tabela 6.1 correspondem à situação em que tanto a Órbita como
a Atitude usaram como dt o mesmo valor, neste caso 1 segundo.
Módulo Tempo (s)
Órbita 718,719
Atitude 1341,562
Tabela 6.1: Teste com dts iguais
Para obter os tempos da tabela 6.2, alterou-se apenas o dt da Órbita para 60 segundos.
Módulo Tempo (s)
Órbita 8,031
Atitude 2369,453
Tabela 6.2: Teste dts diferentes
De acordo com os tempos apresentados em ambas as tabelas, verifica-se que a alteração de dt na
Órbita melhorou o seu desempenho e que afectou negativamente a Atitude. Esta situação ocorre
devido à dependência da Atitude de dados que são calculados na Órbita, em que a frequência do
58
pedido destes dados e o número de elementos que contêm esses mesmos dados tem em conta o dt
definido na Órbita. No segundo caso em particular, a Atitude pede 120 elementos (2 x 60) com
dados à Órbita de 60 em 60 iterações, o que acaba por atrasar o processamento da Atitude, além
do envio de dados para o Gestor. No futuro deverá ser pensada uma solução mais eficiente para
este processo do pedido de informação da Atitude à Órbita.
6.2 Comparação de canais de comunicação
Disponibilizando o .Net Framework duas alternativas para implementação de canais de
comunicação entre processos remotos, foi necessário optar por uma delas e para isso serviu este
teste, em que é comparado o desempenho do simulador usando ambas as alternativas com as
configurações destas por defeito: TcpChannel (envio de dados em binário) e HttpChannel (envio de
dados em XML). Neste teste a simulação teve a duração de 300 segundos, o dt da Órbita e da
Atitude tinham o mesmo valor (1 segundo) e todos os módulos se encontravam na mesma máquina.
Na tabela 6.3 apresentam-se os tempos relativos à utilização de TcpChannel na comunicação entre
Órbita, Atitude e Gestor.
Módulo Tempo (s)
Órbita 1,297
Atitude 1,922
Gestor 1,937
Tabela 6.3: Teste utilizando TcpChannel
A utilização de HttpChannel leva aos valores de tempos presentes na tabela 6.4.
Módulo Tempo (s)
Órbita 37,015
Atitude 39,125
Gestor 39,129
Tabela 6.4: Teste utilizando HttpChannel
As tabelas anteriores vieram confirmar que a utilização de HttpChannel prejudica o desempenho de
aplicações distribuídas, devendo-se este facto à serialização/deserialização dos dados para/de
XML, o que não acontece nos TcpChannel em que os dados são enviados em formato binário.
6.3 Localhost versus Rede
Foi analisado o desempenho do simulador a funcionar na mesma máquina (localhost) e com os
vários módulos distribuídos por máquinas distintas (em rede). Para esta análise foi utilizada uma
duração da missão de 300 segundos, e dts iguais de 1 segundo para a Órbita e Atitude,
apresentando-se nas tabelas que se seguem os tempos medidos.
59
A primeira tabela, tabela 6.5, contém os tempos do funcionamento na mesma máquina, ou seja,
comunicação local entre os diversos módulos.
Módulo Tempo (s)
Órbita 1,297
Atitude 1,922
Gestor 1,937
Consola 2,313
Tabela 6.5: Teste em localhost
Na segunda tabela, tabela 6.6, estão os tempos verificados para um funcionamento em rede do
simulador.
Módulo Tempo (s)
Órbita 19,730
Atitude 19,937
Gestor 19,938
Consola 23,453
Tabela 6.6: Teste em rede
Segundo as tabelas anteriores, verifica-se que o funcionamento em rede aumentou o tempo de
execução de cada um dos módulos, afectando negativamente o desempenho do simulador. No
entanto, este aumento é consistente entre os diferentes módulos, não havendo uma grande
discrepância de valores entre eles. O aumento verificado deve-se em grande parte à quantidade de
dados que circula na rede, e ao facto de o Gestor tornar o sistema centralizado, acabando por ser
uma fonte de estrangulamento no fluxo dos dados.
6.4 Comparação de versões
A primeira versão do simulador, tal como foi referido no início deste documento, tinha alguns
problemas, um deles era o consumo de memória. Este problema não permitia que se chegasse ao
fim da simulação dos 28 dias de missão do satélite ESEO. Com esta nova versão do simulador é
possível realizar toda a simulação da missão do satélite sem a ocorrência de falhas a nível de
memória.
Apresenta-se de seguida uma comparação em termos de tempos de execução entre as duas
versões do simulador. Para esta comparação a duração da simulação foi de 300 segundos, que
equivale a 5 minutos de duração da missão. Os tempos de execução medidos foram:
60
Versão Tempo (s)
Primeira 5,260
Segunda (localhost) 2,313
Segunda (rede) 23,453
Tabela 6.7: Comparação de versões
Como se pode observar pela tabela 6.7, a nova versão do simulador além de corrigir problemas,
principalmente relacionados com a memória, permitiu também um melhoramento do desempenho
deste (quando a funcionar com todos os módulos na mesma máquina). O funcionamento em rede
mais uma vez fica aquém das expectativas como se viu no teste 6.4.
6.5 Tráfego de dados na rede
O presente teste visa apresentar a utilização de rede que é feita pelo simulador, mais
concretamente por cada um dos módulos que o compõem, sendo apresentado para cada um
destes, um gráfico que demonstra o número total de pacotes (eixo das ordenadas) por segundo
(eixo das abcissas). O tempo presente nestes gráficos é o tempo real/físico ao passo que nos testes
anteriores era o tempo de utilização de processador que acaba por ser inferior ao real. Para a
obtenção destes dados e consequentes gráficos foi utilizado o programa Ethereal, que permite
analisar protocolos de rede. Na data de realização deste teste tentou-se instalar esta aplicação
noutros computadores que não o de desenvolvimento (que já possuía o Ethereal instalado), mas o
ficheiro de instalação após o download ficava sempre corrompido, o que obrigou à execução deste
teste quatro vezes (quatro simulações com os mesmos dados iniciais), uma para cada módulo a
correr no computador que tinha o Ethereal já instalado. Esta prática resultou em quatro gráficos que
não se relacionam directamente devido ao eixo das abcissas (tempo), além disso o início e fim da
captura de pacotes, por parte do Ethereal, é feito de forma manual o que também acrescenta um
erro nos valores correspondentes ao mesmo eixo.
Para este teste a duração da simulação foi de 300 segundos, com iguais dts de 1 segundo tanto
para a Órbita como para a Atitude.
Órbita
Pela figura 6.1 verifica-se que o módulo Órbita tem principalmente dois momentos de transferência
de dados através da rede. O primeiro por volta dos 20 segundos desta simulação que corresponde
ao envio do buffer inicial para a Atitude, o segundo, entre os 50 e os 90 segundos, coincidiu com o
envio dos restantes dados de simulação para a Atitude e ao mesmo tempo para o Gestor.
61
Figura 6.1: Tráfego de dados da Órbita
Atitude
A figura 6.2 evidencia um pico entre os 10 e os 20 segundos, que corresponderá à recepção do
buffer inicial da Órbita juntamente com as condições iniciais vindas do Gestor. Depois deste pico há
uma continuação de recepção e envio de dados até ao fim da execução da simulação da atitude do
satélite.
Figura 6.2: Tráfego de dados da Atitude
Gestor
O gráfico da figura 6.3, da execução do módulo Gestor, possui basicamente três picos, o primeiro
dirá respeito ao envio das condições iniciais para a Órbita e para a Atitude, o segundo
corresponderá à recepção de dados vindos da Órbita e o último aos dados vindos da Atitude,
havendo ao longo da sua execução o envio de dados para a Consola.
62
Figura 6.3: Tráfego de dados do Gestor
Consola
Na figura 6.4, pode se observar que o tráfego de dados relativos à Consola é caracterizado por dois
períodos que resultam praticamente da recepção de dados enviados pelo Gestor.
Figura 6.4: Tráfego de dados da Consola
6.6 Sumário
Da análise resultante dos testes anteriores verifica-se que a distribuição em rede atrasa a
simulação, contrariando a ideia de que os sistemas distribuídos podem melhorar o desempenho de
aplicações desenvolvidas dessa forma, no entanto algumas melhorias podem ainda ser efectuadas
ao simulador.
Foi possível confirmar que a utilização de TcpChannel é preferível à utilização de HttpChannel,
quando se está perante aplicações cujo desempenho é importante.
63
Quanto aos gráficos relativos ao tráfego de dados entre os diferentes módulos, verificou-se que
estes eram caracterizados pela existência de diversos picos e “tempos mortos”, que resultam muito
da utilização de estruturas de dados partilhadas pelas várias theads que estão em execução em
cada servidor (Órbita, Atitude e Gestor), originando numa acumulação de pedidos de acesso a
essas estruturas e atrasando as respostas a esses pedidos. Uma possível solução para este
problema poderá passar pela descentralização da gravação de dados em ficheiros, isto é, em vez
de a Órbita e a Atitude enviarem dados para o Gestor escrever em ficheiro, estas passariam a fazê-
lo localmente. Outra solução seria colocar a Órbita e a Atitude a enviarem os dados úteis à
visualização directamente para a GUI/Consola e não para o Gestor. Estas duas soluções libertavam
bastante o Gestor, que acaba por ser um pouco o bottleneck do sistema, podendo este ficar apenas
para a transmissão de comandos entre GUI/Consola e Órbita e Atitude, e ainda caso se justifique e
seja implementado um serviço de autenticação (tal como é sugerido na secção 7.1 Trabalho
Futuro), este poderia ser da responsabilidade do Gestor.
64
Capítulo 7
Conclusão e Trabalho Futuro
Nesta tese foram introduzidos conceitos de simulação e de simulação distribuída. Foram
apresentadas arquitecturas e tecnologias, algumas mais ligadas ao desenvolvimento de
simuladores distribuídos, como é o caso do HLA, outras mais a aplicações distribuídas genéricas
(Corba, RMI e .Net Framework). Discutiu-se o papel dos Web Services na simulação e verificou-se
que ainda existe algum trabalho a realizar nesta área da simulação distribuída.
A arquitectura apresentada permitiu uma fácil e lógica separação dos constituintes de um simulador
de satélite, estando mesmo ao nível da arquitectura que é muitas vezes usada na indústria. Nesta
arquitectura faz-se uma clara distinção entre o que é simulação de órbita e o que é simulação de
atitude do satélite.
Para levar a cabo este trabalho optou-se por desenvolver o simulador usando a .Net Framework, na
sua vertente C++, ou seja, através da utilização de Managed Extensions para C++, uma vez que a
linguagem teria de ser à partida C++. Esta escolha permitiu um rápido e facilitado desenvolvimento
da componente distribuída do simulador.
Na implementação descreveram-se as diversas partes que constituem o simulador, bem como
alguns detalhes mais significativos de implementação. O simulador é então constituído pelas já
referidas órbita e atitude, e ainda por um módulo gestor da simulação e outro responsável pela
apresentação de resultados ao utilizador, sendo cada um destes módulos processos independentes
capazes de funcionar numa rede assente na Internet.
Através da realização de alguns testes ao simulador verificou-se que o funcionamento de forma
distribuída na rede atrasa um pouco a simulação em comparação com um funcionamento distribuído
mas com todos os módulos na mesma máquina. Outra situação que se constatou é a ocorrência de
picos e “tempos mortos” na transferência de dados entre os vários componentes do simulador. Esta
situação deve-se ao acesso concorrente a estruturas de dados partilhados entre threads dos
servidores que compõem o simulador, que não permitem que os pedidos sejam respondidos de
forma imediata.
65
Concluindo, à parte de pequenos problemas e atrasos, conseguiu-se desenvolver um simulador
distribuído de um satélite que dá resposta ao objectivo para que foi criado: o teste e validação dos
algoritmos de estimação e controlo do satélite, e ainda explorar a simulação distribuída.
7.1 Trabalho Futuro
À data de escrita deste documento ainda não havia sido testado o comportamento dos Sensores,
nem integrado e testado o código dos Actuadores, embora este já estivesse implementado, o que é
algo a fazer, bem como uma revisão do sistema de excepções especialmente a nível das
comunicações entre os diferentes módulos.
De momento apenas é possível emitir o comando de início da simulação, indo esta até ao fim, mas
em certas situações pode ser útil pausar ou parar a simulação. Para isso seria necessário introduzir
esses comandos no Gestor, na Órbita e na Atitude, e nas várias classes da Órbita e Atitude ter
forma de facilmente propagar o comando, por exemplo, herdando de uma classe que
implementasse as acções a tomar aquando da recepção desse comando. Tendo a pausa e a
paragem de uma simulação implementada, seria também interessante ter uma operação de
carregamento de simulação, isto é, o utilizador pausava ou parava uma simulação, esta era gravada
para ficheiro e mais tarde poderia ser retomada, carregando para isso os ficheiros gravados
necessários.
No futuro pode-se pensar em implementar um sistema de autenticação de utilizadores, interagindo o
simulador com uma base de dados e assim ter um histórico de simulações por utilizador.
Como foi referido no capítulo de introdução deste documento, parte do desenvolvimento do
simulador distribuído foi acompanhado por investigadores da empresa Critical Software. Deste
acompanhamento resultaram algumas sugestões, tendo ficado algumas delas como propostas para
trabalho futuro. Uma das principais propostas de trabalho futuro é colocar o simulador compatível
com a especificação SMP, para que seja mais fácil a sua reutilização noutras missões. Esta
alteração facilitava também a utilização do simulador como ferramenta de casos de estudo da
empresa Critical Software, permitindo que esta testasse modelos desenvolvidos para produtos seus.
O SMP não foi seguido desde o início do desenvolvimento do simulador, pois quando tomei
conhecimento deste standard o simulador já ia numa fase avançada de implementação.
Em relação ao SSETI, pretendo continuar a colaborar com a equipa em que estou inserido numa
aproximação voluntarista de modo a assegurar a utilização do simulador na missão ESEO em 2008.
Poderei ainda corrigir possíveis problemas que apareçam, implementar mais funcionalidades e
passar o testemunho no que toca ao possível desenvolvimento do simulador para a missão
seguinte, do satélite ESMO.
66
Referências
1. SSETI - Express. Disponível online via http://www.sseti.net/the-express-mission/index.php
[acedido em 4 de Agosto de 2007]
2. SSETI – ESMO. Disponível online via http://www.sseti.net/the-esmo-mission/index.php [acedido
em 4 de Agosto de 2007]
3. European Student Earth Orbiter (ESEO) – ESEO Management Plan, Phase B. ESA (2007)
4. ESA – Modelling & Simulation. Simulation Model Portability. Disponível online via
http://www.esa.int/TEC/Modelling_and_simulation/TEC2DCNWTPE_0.html [acedido em 3 de Maio
de 2007]
5. Ayani, R.: A parallel simulation scheme based on the distance between objects. Proceedings of
the SCS Multiconference on Distributed Simulation, Vol. 21. SCS Simulation Series (1989) 113-118
6. Bryant, R.E.: Simulation of packet communication architecture computer systems. MIT-LCS-TR-
188, Massachusetts Institute of Technology, Cambridge, Massachusetts (1977)
7. Carson, J.S.: Introduction to Modeling and Simulation. Proceedings of the 2005 Winter Simulation
Conference (2005) 16-23
8. Chandy, K.M., Misra. J.: Asynchronous distributed simulation via a sequence of parallel
computations. Communications of the ACM, 24(4) (1981) 198-205
9. Chandy, K.M., Misra. J.: Distributed Simulation: A case study in design and verification of
distributed programs. IEEE Transactions on Software Engineering, SE-5(5) (1979) 440-452
10. Chandy, K.M., Sherman R.: The conditional event approach to distributed simulation.
Proceedings of the SCS Multiconference on Distributed Simulation, Vol. 21. SCS Simulation Series
(1989) 93-99
11. Coulouris, G., Dollimore, J., Kindberg, T.: Distributed Systems – Concepts and Design. 3rd edn.
Addison-Wesley (2001)
12. Dahmann, J.S., Fujimoto, R.M., Weatherly, R.M.: The Department of Defense High Level
Architecture. Proceedings of the 1997 Winter Simulation Conference (1997) 142-149
13. Fishwick, P.A.: Web-Based Simulation. Proceedings of the 1997 Winter Simulation Conference
(1997) 100-102
14. Fishwick, P.A.: Web-Based Simulation: Some personal observations. Proceedings of the 1996
Winter Simulation Conference (1996) 772-779
15. Fujimoto, R.M.: Parallel discrete event simulation. Communications of the ACM, 33(10) (1990)
30-53
16. Fujimoto, R.M.: Parallel and Distributed Simulation Systems. Proceedings of the 2001 Winter
Simulation Conference (2001) 147-157
17. Fujimoto, R.M.: Parallel and Distributed Discrete Event Simulation: Algorithms and Applications.
Proceedings of the 1993 Winter Simulation Conference (1993) 106-114
67
18. Fujimoto, R.M., Nicol, D.M.: State of the art in parallel simulation. Proceedings of the 1992 Winter
Simulation Conference (1992) 246-254
19. IEEE: IEEE Std 1516-2000, IEEE Standard for Modeling and Simulation (M&S) High Level
Architecture (HLA) – Framework and Rules (2000)
20. IEEE: IEEE Std 1516.1-2000, IEEE Standard for Modeling and Simulation (M&S) High Level
Architecture (HLA) – Federate Interface Specification (2000)
21. IEEE: IEEE Std 1516.2-2000, IEEE Standard for Modeling and Simulation (M&S) High Level
Architecture (HLA) – Object Model Template (OMT) Specification (2000)
22. IEEE: IEEE Std 1516.3-2003, IEEE Recommended Practice for High Level Architecture (HLA)
Federation Development and Execution Process (FEDEP) (2003)
23. Ikonen, J., Porras, J., Harju, J.: Analyzing Distributed Simulation. Proceedings of Eurosim’98
(1998) 33-38
24. Jefferson, D.R.: Virtual Time. ACM Transactions on Programming Languages and Systems, 7(3)
(1985) 404-425
25. Jefferson, D.R., Sowizral, H.: Fast concurrent simulation using the Time Warp mechanism, part I:
Local control. Technical Report N-1906-AF, RAND Corporation (1982)
26. Lubachevsky, B.D.: Efficient distributed event-driven simulations on multiple-loop networks.
Communications of the ACM, 32(1) (1989) 111-123
27. Marques, J.A., Guedes, P.: Tecnologia de Sistemas Distribuídos. FCA – Editora de Informática
(1998)
28. Nicol, D.M.: The cost of conservative synchronization in parallel discrete-event simulations.
Journal of the ACM (1993)
29. Page, E.H.: Web-Based Simulation. Disponível online via
www.mitre.org/news/the_edge/august_98/wbs.html [acedido em 26 de Novembro de 2006] (1998)
30. Reichenthal, S.W.: Re-Introducing Web-Based Simulation. Proceedings of the 2002 Winter
Simulation Conference (2002) 847-852
31. Wilson, A.L., Wetherly, R.M.: The Aggregate Level Simulation Protocol: An evolving system.
Proceedings of the 1994 Winter Simulation Conference (1994) 781-787
32. Box, D.: SOAP: Simple Object Access Protocol. Internet-Draft, IETF (1999)
33. Goldfarb, C.F.: SGML Handbook. Oxford University Press (1990)
34. Chiu, K., Govindaraju, M., Bramley, R.: Investigating the Limits of SOAP Performance for
Scientific Computing. Proceedings of the 11th IEEE International Symposium on High Performance
Distributed Computing. IEEE Computer Society (2002)
35. van Engelen, R.A., Gallivan, K.A.: The gSOAP toolkit for Web services and peer-to-peer
computing networks. Proceedings of the 2nd IEEE/ACM International Symposium on Cluster
Computing and the Grid. Berlin, Germany (2002)
68
36. Fishwick, P.A.: Using XML for Simulation Modeling. Proceedings of the 2002 Winter Simulation
Conference (2002) 616-622
37. McLean, C., Leong, S., Harrel, C.: Simulation Standards: Current Status, Needs and Future
Directions. Proceedings of the 2003 Winter Simulation Conference (2003) 2019-2026
38. Danahoo, M.J.: Practical C++ Sockets. Disponível online via
http://cs.baylor.edu/~donahoo/practical/CSockets/practical/ [acedido em 5 de Novembro de 2006]
39. Guillaume, R.: Equação Diferencial de 4 Corpos Celestes. Documentação ESEO-AOCS. IST
[Anexo B deste documento]
40. Fritzen, P.: Model Re-use through the SMP2 Standard. VEGA (2004)
41. Arguello, L., Miró, J., Gujer, J.J., Nergaard, K.: SMP: A Step Towards Model Reuse in
Simulation. Bulletin 103. ESA (2000)
69
A Manual de Utilização
O presente manual visa ajudar novos utilizadores a usar o AOCS Simulador Distribuído, focando-se
esta ajuda nos módulos Órbita, Atitude, Gestor e Consola.
A aplicação permite que o utilizador realize a simulação de uma missão completa do satélite ESEO,
simulação essa que incide sobre a componente AOCS deste satélite.
Cada um dos módulos referidos anteriormente é um executável da aplicação, e por isso são
executados sequencialmente. A única ordem de lançamento dos executáveis que existe é a de que
antes de se arrancar a Consola, se deve ter já em execução a Órbita, a Atitude e o Gestor.
Para correr o simulador é necessário ter instalado em cada computador que executar um módulo o
Microsoft .Net Framework 1.1, que pode ser obtido em: http://msdn2.microsoft.com/en-
us/netframework/Aa569264.aspx.
Aconselha-se a utilização do simulador através de consolas de linhas de comando, tal como se
apresenta de seguida:
A.2 Órbita
Para lançar o servidor Órbita basta indicar qual o porto reservado para que sejam possíveis as
comunicações entre este e o Gestor e a Atitude.
Exemplo de execução da Órbita com o porto 1111:
Figura A.1: Linha de comandos da Órbita
Como se pode verificar pela figura A.1, assim que o módulo Órbita entra em execução, este
apresenta o IP da máquina em que se encontra e uma mensagem para se premir ENTER caso o
utilizador queira terminar o servidor.
No caso de se proceder ao início de uma simulação, são indicadas as fases pelas quais passa o
servidor e de seguida aparece novamente indicação para o utilizador terminar a execução do
módulo Órbita, caso assim o deseje.
A.3 Atitude
À semelhança da Órbita, a Atitude também precisa de receber como argumento o porto para que o
Gestor se lhe possa ligar.
70
Exemplo de execução da Atitude com o porto 2222:
Figura A.2: Linha de comandos da Atitude
Em termos de mensagens durante a execução o módulo Atitude tem exactamente o mesmo
comportamento que o módulo Órbita, como se pode verificar pela figura A.2.
A.4 Gestor
Uma vez que o Gestor comunica com todos os restantes módulos, este precisa de definir um porto
para receber os pedidos da GUI/Consola e outro para associar à comunicação com a Órbita e
Atitude.
Assim que entra em execução a aplicação Gestor pede ao utilizador para inserir os dados relativos
ao servidor Órbita e Atitude, mais concretamente os respectivos IPs e portos, para puder comunicar
com estes.
Exemplo de execução do Gestor:
Figura A.3: Linha de comandos do Gestor
Tal como se pode ver na figura A.3, o Gestor apresenta o IP da máquina na qual se encontra em
execução e de seguida pede ao utilizador os dados indicados anteriormente: porto para as
comunicações com a GUI/Consola, porto para as comunicações com a Órbita e Atitude, IP e porto
da Órbita, e por último IP e porto da Atitude. Após o que apresenta a mensagem para indicar ao
utilizador que este pode terminar o servidor premindo ENTER, depois desta mensagem tem uma
outra informando o utilizador que se encontra à espera de ligações de clientes, neste caso que a
Consola dê início a uma simulação. Assim que esta o faz, é apresentado um conjunto de
71
mensagens relativas à fase de processamento em que se encontra o Gestor, podendo o utilizador
premir ENTER no final da simulação, se quiser terminar o servidor Gestor.
A.5 Consola
A Consola liga-se ao Gestor, logo precisa de saber o seu IP e porto, para estabelecer ligação e
iniciar a simulação.
Exemplo de execução da Consola:
Figura A.4: Linha de comandos da Consola
A Consola apenas precisa de receber do utilizador a indicação de qual é o IP e o porto do servidor
Gestor, e assim que tem estes dados dá início a uma simulação, desencadeando as mensagens
que são apresentadas após a introdução do porto do Gestor, tal como se pode verificar na figura
A.4.
A parameterização da missão é feita através de um ficheiro XML, com o nome ci.xml, que se deve
encontrar na mesma directoria que o executável correspondente à Consola. Esse ficheiro deve ter a
seguinte estrutura (os valores utilizados são os presentes no capítulo Caso de Estudo e que
correspondem à simulação da missão ESEO):
<InitialConditions>
<!-- simulation duration -->
<duration>2419200.0</duration>
<!-- simulation date -->
<year>2008</year>
<month>11</month>
<day>21</day>
<hour>22</hour>
<minute>45</minute>
<second>0</second>
72
<!-- orbit -->
<orbitSet>1</orbitSet>
<orbitDt>1.0</orbitDt>
<orbitA>24478100.0</orbitA>
<orbitE>0.7922216300</orbitE>
<orbitI>7.0</orbitI>
<orbitRaan>270.0</orbitRaan>
<orbitW>178.0</orbitW>
<orbitM>360.0</orbitM>
<!-- attitude -->
<attitudeDt>1.0</attitudeDt>
<attitudeInertiaXX>7.5684</attitudeInertiaXX>
<attitudeInertiaYY>6.2306</attitudeInertiaYY>
<attitudeInertiaZZ>6.1261</attitudeInertiaZZ>
<attitudeInertiaXY>-0.1526</attitudeInertiaXY>
<attitudeInertiaXZ>-0.1109</attitudeInertiaXZ>
<attitudeInertiaYZ>0.1446</attitudeInertiaYZ>
<attitudeQ1>0</attitudeQ1>
<attitudeQ2>0</attitudeQ2>
<attitudeQ3>0</attitudeQ3>
<attitudeQ4>1</attitudeQ4>
<attitudeWX>0</attitudeWX>
<attitudeWY>0</attitudeWY>
<attitudeWZ>0</attitudeWZ>
</InitialConditions>
73
B Runge-Kutta
74
75
