CAPÍTULO 1
INTRODUÇÃO
A modelagem e simulação de sistemas de redes de comunicação de dados se
constituem em ferramentas valiosas, pois elas fornecem uma maneira de
avaliar o desempenho destas sem que se perturbe o seu funcionamento ou até
mesmo antes de sua construção. Elas fornecem também uma maneira de se
estudar diferentes alternativas para sua configuração, através de análises do
tipo “o que ocorreria se...”, que contribuem para o aumento da confiabilidade
dos componentes e da totalidade da rede.
O Sistema Brasileiro de Coleta de Dados Baseado em Satélites consiste de
plataformas coletoras de dados, satélites retransmissores e estações terrenas,
entre elas o Centro de Controle de Missão, que estão interligados por enlaces
de comunicação. Este sistema, a seguir denominado simplesmente de SBCD,
é utilizado em aplicações ambientais dos satélites da MECB (Missão Espacial
Completa Brasileira) e será modelado neste trabalho como uma rede de
comunicação de dados que possui um 'link' baseado em satélite.
As questões associadas com a quantificação do número de plataformas de
coleta de dados, a distribuição geográficas e a operação satisfatória destas,
tendo em vista a dependência que elas apresentam em relação aos satélites
em sua órbita terrestre, resultam complexas e de elevado custo, envolvendo
freqüentemente até entidades externas ao Instituto, interessadas na obtenção
e tratamento desses dados.
Desta forma a possibilidade de se estudar, de antemão, aspectos ligados à
estruturação, operação e desempenho do sistema, visando projetar a sua
melhor configuração e reduzir os custos de sua implantação e operação,
tornam a simulação uma alternativa interessante de ferramenta para a análise
17
deste tipo de sistema.
1.1 MOTIVAÇÃO E ORIGEM
A presente dissertação se originou a partir da proposta de um projeto de
engenharia de responsabilidade da Gerência do Segmento Solo da MECB
(SSM), da Coordenadoria de Engenharia e Tecnologia Espacial (ETE) do
Instituto Nacional de Pesquisas Espaciais (INPE).
O objetivo original do projeto era desenvolver técnicas e/ou ferramentas que
permitissem analisar a capacidade e a forma de operação do SBCD, com
vistas a orientar o seu crescimento e definir procedimentos para se obter um
melhor desempenho do sistema.
A criação de um simulador para auxiliar na análise da capacidade do sistema e
permitir o seu melhor aproveitamento foi inicialmente identificada em Tude et
al. (1986), em um relatório técnico que descreve os enlaces de subida
(Plataforma de Coleta de Dados -Transponder), de descida (Transponder Estação Terrena) e o processo de modulação a bordo do satélite.
A SSM elaborou posteriormente uma especificação
de requisitos para o
Simulador do Sistema Brasileiro de Coleta de Dados, visando efetuar uma
licitação pública para a sua construção (INPE, 1995).
As especificações apresentadas e as características peculiares do sistema
tornaram o simulador de elevado risco para as firmas concorrentes, que
precisariam reunir especialistas com conhecimentos de várias áreas distintas
para a sua construção, elevando, por conseguinte, o preço final solicitado,
inviabilizando o projeto (Braga, 1995), (Elebra, 1995), (Iman, 1995).
O presente trabalho baseia-se na documentação existente sobre o projeto
18
citado e retoma a idéia de desenvolvimento do simulador com base numa
abordagem acadêmica, caracterizada pelo uso das técnicas e ferramentas de
simulação discretas disponíveis no Laboratório Associado de Computação e
Matemática Aplicada (LAC) para fins didáticos e de pesquisa, visando a
criação de um protótipo do mesmo e a realização de um estudo completo de
simulação do SBCD.
As limitações devidas ao escopo acadêmico e à abrangência do protótipo,
entretanto, não devem ser vistos como fatores que impliquem na existência de
restrições definitivas às capacidades do sistema, que está dotado de todas as
condições (estruturação, flexibilidade, etc.) que o permitem evoluir e vir a se
tornar um simulador completo do SBCD, capaz de contemplar todas as
necessidades da SSM.
1.2 OBJETIVOS
O objetivo geral da pesquisa descrita neste trabalho é a realização de um
estudo de simulação do SBCD (Sistema Brasileiro de Coleta de Dados
Baseado em Satélites), tendo como foco principal a análise do tráfego de
mensagens na rede de comunicação de dados constituídas pelo sistema real.
Um estudo completo de simulação compreende todas as etapas envolvidas na
análise
e
criação
do
simulador,
desde
a
definição
do
problema,
desenvolvimento do modelo, sua experimentação e o apoio à tomada de
decisão (Kienbaum, 1989).
Conforme formulado acima, o objetivo geral da pesquisa é de longo prazo e de
escopo muito abrangente, tendo como componente principal a criação de um
modelo computacional de simulação (simulador) do SBCD, com capacidade
para analisar a configuração, operação e desempenho do sistema real,
permitindo a tomada de decisões estratégicas sobre o mesmo.
19
O
simulador
será
utilizado
para
determinar
importantes
parâmetros
operacionais do sistema, tais como configurações limites e o número máximo
de PCDs que podem ser utilizadas pelo sistema, permitir a avaliação do seu
desempenho para uma dada configuração, além de permitir analisar
alternativas para a atualização do sistema, relacionados com diferentes
configurações de Plataformas de Coleta de Dados - PCDs (tipo, número,
localização, etc.), com as Estações de Recepção de Coleta de Dados - ERCDs
(tipo, número, localização, etc.) e com os satélites em utilização (número,
órbitas, etc.).
Devido à complexidade e à abrangência do objetivo geral, e à necessidade de
desenvolvimento do próprio simulador, entretanto, este trabalho priorizará,
como objetivo específico, a execução das etapas de definição do problema, de
determinação dos requisitos, de elaboração da análise e da prototipação do
simulador.
Um outro objetivo específico do trabalho é a utilização de uma abordagem de
simulação discreta orientada a objetos para explorar as vantagens desta
técnica na modelagem do problema e, permitir a rápida prototipação de um
simulador do sistema SBCD.
A execução das corridas e a análise de resultados da simulação serão
apresentados em parte como continuação da pesquisa e do desenvolvimento
aqui apresentados, uma vez que o simulador tenha sido completado com todos
os recursos necessários para tal, conforme projetados neste trabalho.
Para isto antecipa-se, com base no conhecimento adquirido sobre o sistema
SBCD e na experiência de utilização de interfaces de simulação de
características semelhantes, quais serão os procedimentos a serem seguidos
para uso do simulador na montagem dos cenários, no planejamento dos
experimentos, na execução das corridas de simulação, e na análise e
20
apresentação dos resultados, com a finalidade de auxiliar a equipe que estará
futuramente encarregada do simulador.
1.3 ESTRATÉGIA E MÉTODOS
O sistema foi analisado como um problema típico de simulação discreta, no
qual o sistema real é visualizado como uma rede de comunicação de dados e
o objetivo principal é a análise do tráfego de mensagens nesta rede.
O paradigma de orientação a objetos é utilizado para a criação de um modelo
computacional de simulação do sistema adotando-se uma estratégia de
desenvolvimento iterativo e incremental, na qual as funcionalidades do
simulador são expandidas de forma gradual.
O uso da linguagem de simulação MODSIM III possibilita o emprego da
metodologia e da estratégia de desenvolvimento escolhidos.
1.4 ESTRUTURA DO TRABALHO
Esta dissertação está estruturada da seguinte forma. No Capítulo 1 fez-se uma
pequena introdução do trabalho, a motivação que originou a dissertação, seus
objetivos e a estratégia e os métodos utilizados na condução da pesquisa. O
capítulo termina com a apresentação da estrutura geral do trabalho.
A seguir, no Capítulo 2, é apresentado o contexto geral no qual a pesquisa se
insere, consistindo da formulação do problema, da análise das alternativas de
abordagem, da fundamentação teórica do uso de simulação orientada a objeto
como técnica de análise, bem como a escolha da ferramenta de
implementação do protótipo do simulador.
No Capítulo 3 é feita a descrição geral do SBCD.
21
No Capítulo 4 são descritos os requisitos funcionais do simulador, que
norteiam a condução das fases de análise e de projeto. Como resultado, são
apresentadas a estrutura dos módulos e de classes das componentes do
protótipo do simulador e são estabelecidas as limitações para o seu
desenvolvimento.
O Capítulo 5 descreve a implementação do protótipo, as fases de evolução da
pesquisa e o estágio de desenvolvimento atual do protótipo.
O capítulo 6 estabelece as linhas mestras para a continuação desta pesquisa,
destacando aspectos relacionados com o aperfeiçoamento e a adição de
novas facilidades ao simulador, discutindo questões relacionadas com a
verificação e validação do mesmo, e fazendo uma projeção sobre como será o
estudo de simulação a ser realizado como sistema SBCD.
Por último, no Capítulo 7, são apresentadas as conclusões deste trabalho.
22
CAPÍTULO 2
FUNDAMENTAÇÃO E CONTEXTO DA PESQUISA
Neste capítulo serão apresentados os principais conceitos sobre os quais o
desenvolvimento deste trabalho está baseado. Serão feitas considerações
sobre
a
formulação
do
problema,
com
sua
complexidade
e
multidisciplinaridade intrínsecas e sobre as possíveis alternativas de análises
existentes para o mesmo. Com relação à técnica de abordagem escolhida, a
simulação de sistemas, descreve-se a seguir suas principais etapas e
conceitos, o uso de orientação a objetos, bem como a linguagem MODSIM III
empregada para a elaboração do protótipo.
2.1 A FORMULAÇÃO DO PROBLEMA
O problema é visto como uma rede de comunicação de dados, envolvendo
estações de coleta e de recebimento de dados, satélites e links.
O SBCD contempla todos os processos, desde a geração das mensagens
pelas PCDs, o enlace de subida para o satélite, o processo de transposição de
freqüência, o enlace de descida até as estações terrenas, até o processo de
recepção e tratamento dos dados, que serão disponibilizados para os usuários
finais, tanto em sua forma bruta, como pré-formatados.
Com base no conceito de sistemas, pode-se caracterizar o SBCD como um
sistema complexo, composto por subsistemas ativos (PCDs – satélites –
ERCDs) e dotado de uma estrutura geral, que descreve a forma como estes
subsistemas interagem. Modificações da configuração, do comportamento e da
forma de interação dos subsistemas podem ser estudadas através de
investigações de natureza analítica ou numérica.
23
Para se entender as características destes subsistemas e suas formas de
interação são requeridos conhecimentos profundos de diversas disciplinas. O
estudo do SBCD precisa considerar, no mínimo, tópicos relativos à área de
simulação, engenharia de “software”, telecomunicações e redes e mecânica
celeste (Escobal, 1965) (Há, 1990) (Pressman, 1992).
2.2 ALTERNATIVAS DE ABORDAGEM
O estudo de um sistema, visando conhecer como interagem os seus diversos
componentes e/ou avaliar o seu desempenho quando submetido a novas
condições de operação, pode ser realizado utilizando-se diversas formas de
abordagem, conforme descritas na Figura 2.1 (Law e Kelton,1992).
Sistema
Experimento
com um Modelo
do Sistema
Experimento
com o
Sistema Real
Modelo
Físico
Modelo
Matemático
Solução
Analítica
Simulação
Fig. 2.1 - Alternativas para estudar um sistema.
FONTE: Law e Kelton (1992).
Do que está apresentado na Figura 2.1, pode-se sintetizar, para o caso do
24
problema em estudo, que as alternativas de abordagem disponíveis são as
seguintes:
1) Experimento com o sistema real;
2) Modelagem matemática e solução analítica; e
3) Estudo de simulação.
No caso do SBCD fica descartada a experimentação com um modelo físico,
também chamado icônico, construído em escala do sistema real, pois este
seria de difícil realização e de limitados resultados para o problema em
questão.
2.2.1 EXPERIMENTO COM O SISTEMA REAL
Alterar o sistema real e operá-lo sob as novas condições, é provavelmente a
escolha mais confiável, não havendo nenhum questionamento quanto a
validade do estudo. Entretanto, é muito pouco provável que se faça um
experimento dessa natureza, porque isto pode comprometer, seriamente, o
funcionamento normal do sistema.
No experimento com o sistema real, abordagem empírica, usa-se todo o
conhecimento pessoal adquirido com a experiência prática de operação do
sistema, para analisar o seu comportamento. Esse tipo de abordagem
apresenta alto risco associado quando se deseja avaliar o comportamento do
sistema nos casos de modificações de projeto, seja pela inclusão de novos
elementos e, também, no caso de se estabelecer alterações na política de
funcionamento vigente.
Para o primeiro caso, por exemplo, incluir uma nova PCD é a alteração mais
25
comum na rede. Porém, somente após a sua instalação, em uma presumível
localização favorável, se poderá avaliar as conseqüências decorrentes desta
nova plataforma sobre o conjunto de mensagens que, anteriormente, seriam
transmitidas no sistema.
Caso não se obtenha os resultados esperados, uma nova tentativa deverá ser
realizada com o sistema em pleno funcionamento, implicando no transporte e
reinstalação dos equipamentos em outra posição. Dependendo da região onde
a plataforma deva operar, certamente incidirão custos adicionais, decorrentes
da mudança de local e, ainda assim, levarem, mais uma vez, a resultados
desfavoráveis.
O estabelecimento de diferentes políticas de funcionamento, também são de
difícil implementação, pois as modificações planejadas não podem ser
testadas previamente, e têm que ser efetivadas com o sistema em operação,
com todos os riscos associados ao processo.
2.2.2 MODELO MATEMÁTICO E SOLUÇÃO ANALÍTICA
Avaliações a partir de um modelo são recomendadas para os sistemas que
não permitam experimentos reais, ou que possam vir a comprometer sua
operação normal. Em outros casos, o sistema pode, ainda, nem existir, mas se
deseja conhecer as várias configurações possíveis, para orientar como
construí-lo. Por essa razão, é necessário criar um modelo que o represente e
que permita estudá-lo como substituto do sistema verdadeiro.
A grande maioria dos modelos construídos com a finalidade de estudo são
modelos matemáticos. Estes modelos representam o sistema em termos de
seus relacionamentos lógicos e quantitativos, que são manipulados e alterados
para se saber como o modelo reage e, então, se concluir como o sistema deve
reagir, caso o modelo matemático criado for válido.
26
Na abordagem analítica, deve-se obter um modelo matemático que descreva o
sistema real para que as análises de seu comportamento possam ser
realizadas, via a alteração das variáveis do modelo. A maior dificuldade dessa
técnica refere-se a dificuldade em se obter o modelo matemático que descreva
o sistema desejado.
Ao se construir um modelo matemático, ele deve ser examinado para se
verificar se é possível responder as perguntas, acerca do sistema que ele
representa. Se o modelo for simples, pode-se trabalhar, diretamente, com suas
quantidades e relacionamentos para se conseguir uma solução analítica exata.
Logo, se existe uma solução analítica para o modelo matemático e ela é
eficiente, deve-se optar por esta forma de solução.
2.2.3 ESTUDO DE SIMULAÇÃO
“Simulação é o processo de se elaborar um modelo de um sistema real e
conduzir experimentos com esse
modelo, tendo como propósito a
compreensão do comportamento do sistema ou a avaliação de diversas
estratégias (dentro dos limites impostos por um critério ou conjunto de critérios)
para a operação do sistema”. (Shannon ,1975)
Muitos sistemas reais são complexos, de modo que modelos matemáticos
válidos são igualmente complexos, impedindo qualquer possibilidade de se
obter uma solução analítica. Nesses casos, o modelo deve ser estudado
usando-se a simulação, isto é, exercitar numericamente o modelo com
entradas representativas e observar como elas afetam o seu comportamento.
Um estudo de simulação pode ser representado, segundo um diagrama, que
recebe o nome de ciclo de vida do modelo.
27
2.3 CICLO DE VIDA DO MODELO
O ciclo de vida do modelo pode ser visto como processo de transformação
aplicado à informação disponível sobre um sistema. Num nível mais elevado, o
processo é composto das seguintes etapas:
1) Definição do problema;
2) Desenvolvimento do modelo e sua experimentação; e
3) Apoio à decisão. (Kienbaum, 1989)
Num nível mais detalhado, cada etapa do processo é decomposta em
processos mais simples, que transformam a representação do problema
original em formas distintas, sucessivas e interligadas. A cada evolução do
desenvolvimento deve haver pelo menos um passo correspondente de
verificação de qualidade do progresso realizado, que se convenciona chamar
de Estágio de Aferição de Credibilidade - EAC.
O ciclo de vida do modelo, como mostra a Figura 2.2, é composto de dez
formas de representação do problema correspondentes aos estágios de
desenvolvimento
do
modelo.
Os
estágios
de
desenvolvimento
são
representados pelos símbolos ovais. As setas em linhas tracejadas descrevem
os processos que relacionam os estágios de desenvolvimento e as linhas
cheias os processos de verificação de qualidade. Os processos, descritos
originalmente em Balci (1985), são apresentados de forma resumida no
apêndice B.
Deve-se observar que o ciclo de vida não é estritamente seqüencial. A direção
das setas indica apenas a progressão cronológica das atividades durante o
desenvolvimento do estudo. O ciclo de vida, no entanto, é iterativo e
28
incremental, esperando-se que realimentações ocorram entre os passos.
(Balci,1985)
As formas de representação existentes, da definição do sistema e dos
objetivos do estudo até os resultados do modelo, correspondem à etapa de
desenvolvimento do problema. As que lhe antecedem corresponde à etapa de
definição do problema e as lhe sucedem à etapa de apoio à tomada de
decisão.
29
PROBLEMA
COMUNICADO
Formulação do
problema
Verificação do problema
formulado
PROBLEMA
FORMULADO
DECISORES
Avaliação da viabilidade do
uso de simulação
Estudo das técnicas
de solução
Aferição da
aceitabilidade
dos resultados
TÉCNICA DE
SOLUÇÃO PROPOSTA
(SIMULAÇÃO)
APOIO
INTEGRADO À
DECISÃO
Verificação da definição do
sistema e dos seus objetivos
DEF. DO SISTEMA
E DOS OBJETIVOS
DO ESTUDO
Formulação do modelo
Certificação
do modelo
conceitual
MODELO
CONCEITUAL
Redefinição
Verificação
do modelo
conceitual
Validação do
modelo
RESULTADOS
DO
MODELO
Validação dos
dados
Representação
do modelo
MODELO
COMUNICATIVO
Verificação
do modelo
programado
Programação
Experimentação
MODELO
PROGRAMADO
Aferição da
credibilidade
dos resultados
MODELO
EXPERIMENTAL
Projeto de
experimentos
Fig. 2.2 - Ciclo de Vida do Modelo em um Estudo de Simulação.
FONTE: Balci (1985).
30
2.4 SIMULAÇÃO DISCRETA E SUAS ESTRATÉGIAS
A simulação computacional pode ser classificada em dois grandes grupos,
quanto ao tipo de sistema em estudo e a forma de controle de tempo utilizada:
simulação contínua e simulação discreta.
Na simulação contínua o modelo é descrito usando um conjunto de equações
diferenciais que serão solucionadas numericamente em função do tempo. São
exemplos desta área os problemas de escoamento de fluidos e problemas
hidráulicos.
A simulação discreta, por outro lado, descreve o sistema em termos de
relacionamentos lógicos que causam mudanças das variáveis de estado em
determinados instantes de tempo, em vez de continuamente sobre o tempo.
Exemplos deste tipo de problemas podem ser encontrados em sistemas
constituídos por redes de filas, tais como clientes em um posto de gasolina
para abastecer, aeronaves aguardando decolagem ou pouso, etc.
Na simulação discreta, a mudança das variáveis de estado se faz de forma
instantânea podendo transcorrer quaisquer quantidades de tempo simulado
entre os eventos. Somente se está interessado no estado do sistema, quando
uma de suas partes componentes, muda de estado. O SBCD, em estudo, se
enquadra nesta segunda categoria.
Existem várias formas de abordagem para a construção de modelos de
simulação discreta, conhecidas como estratégias de simulação, que são
denominadas: Eventos, Atividades, Três Fases e Processos (Pidd, 1992).
A abordagem utilizada neste trabalho está baseada em processos, que
adicionalmente é implementada através do uso do paradigma de orientação a
31
objetos, o que resulta em aspectos particulares para as etapas de modelagem
e desenvolvimento, que são abordados a seguir.
2.5 SIMULAÇÃO ORIENTADA A OBJETOS
De uma forma simplificada, fala-se de simulação orientada a objetos quando
um sistema é modelado e implementado usando metodologias e linguagens
orientada a objetos.
A primeira linguagem de programação orientada a objetos foi SIMULA, que era
originalmente designada como uma linguagem de simulação de finalidade
geral. SIMULA já fornecia objetos, classes e herança, algumas das
características fundamentais da programação orientada a objetos. Outra
linguagem desenvolvida no início da década de 80, que contribuiu de forma
significativa para a orientação a objetos, foi Smalltalk. Smalltalk fornecia um
ambiente gráfico que estendia os conceitos de tipagem dinâmica, classe e
herança encontradas em SIMULA (Kienbaum, 1994) (Roberts et Al, 1998).
Na simulação orientada a objetos o sistema em estudo é descrito como uma
coleção de objetos que interagem. Os comportamentos dos objetos são
descritos por meio de métodos, e as suas características estão contidas nos
atributos dos objetos que podem ser representadas por variáveis. Tudo que o
objeto conhece está em suas variáveis e tudo que ele pode fazer são os seus
métodos. Essa estrutura mapea claramente os objetos significativos do mundo
real que constituem o sistema sendo modelado.
A Figura 2.3 apresenta uma visão simplificada da estrutura de um modelo
orientado a objetos. As elipses representam classes de objetos, as setas
cheias indicam as heranças implementadas e as setas tracejadas a
colaboração existentes entre os objetos instanciados. Na orientação a objetos,
32
os objetos que pertencem as classes, interagem ou se comunicam através de
troca de mensagens.
Classe
Classe
Classe
Classe
Classe
Classe
Classe
Classe
Classe
Herança
Colaboração
Fig. 2.3 - Estrutura do Modelo Orientado a Objeto.
FONTE: Yilmaz (1998).
2.5.1 CONCEITOS BÁSICOS
Os conceitos fundamentais da abordagem orientada a objetos e como elas se
relacionam com o modelo em simulação, descritos por Roberts e Heim (1988),
são apresentados a seguir.
Classe é usada para definir um tipo de dado abstrato particular. A definição de
classe irá especificar a estrutura de dados implementada e as operações que
podem ser executadas sobre os dados. Essa propriedade de juntar dados e
código em um único objeto (ou classe) é conhecida como encapsulamento.
Uma classe é descrita pelos atributos (variáveis) que seus objetos possuem e
métodos (funções) que podem atuar sobre esses objetos.
Objeto é uma instância de uma classe específica. Ela contém todas as
informações desta classe específica e as ações que podem ser executados
33
nos dados, invocando-se os métodos da classe. O mecanismo usado para se
efetuar a chamada dos métodos de um objeto é pelo meio de mensagens.
Uma mensagem para um objeto requisita a execução de um procedimento.
Uma mensagem invoca um método (procedimento) no objeto receptor para
produzir um comportamento requerido.
Herança possibilita que as classes sejam organizadas em hierarquias de modo
que uma classe que é subordinada a outra classe automaticamente herde
todas as variáveis e métodos da classe superior.
Polimorfismo é a possibilidade de se enviar uma mesma mensagem a um
objeto, cuja execução vai depender do tipo de objeto instanciado. Uma mesma
operação pode se comportar diferentemente quando definida em classes
diferentes.
2.5.2 PROTOTIPAGEM RÁPIDA DE PROGRAMAS
Uma das razões pelas quais Orientação a Objetos (OO) se tornou bastante
popular nas comunidades científicas e de engenharia de software é a sua
propalada característica de permitir aos seus usuários maior produtividade e
rapidez no processo de desenvolvimento dos programas (Yourdon, 1994).
Estas qualidades de OO seriam resultantes da capacidade de reutilização dos
componentes já desenvolvidos, bem como da aplicação de um estilo de
desenvolvimento que se poderia denominar de prototipagem rápida de
programas.
Esta última característica torna OO especialmente atraente para ser usada no
desenvolvimento de simuladores e no uso destes na realização de estudos de
simulação, segundo Kienbaum e Paul (1994).
A figura 2.4 a seguir (adaptada de Kienbaum e Paul, 1994), originalmente
34
inspirada a partir do ciclo de vida do projeto de software OO descrito pelo
Object Management Group (Yourdon, 1994), retrata o ciclo de vida do
desenvolvimento de sistemas destinados à simulação quando se aplica esta
filosofia de projeto.
CICLO DE VIDA
DA
PROGRAMAÇÃO OO
REQUISITO
M
O
D
E
L
A
G
E
M
O
B
J
E
T
O
S
P
R
O
T
Ó
T
I
P
O
ANÁLISE / PROJETO
IMPLEMENTAÇÃO
TESTE
IMPLANTAÇÃO
MODELO
SIMULAÇÃO
COORDENAÇÃO
E
CICLO DE VIDA DO MODELO DE SIMULAÇÃO
SISTEMA REAL
REUSO
Fig. 2.4 - Prototipagem Rápida de Sistemas para Simulação.
A abordagem OO é empregada tanto para o processo de desenvolvimento do
protótipo, como, também, para o desenvolvimento (ciclo de vida) do modelo de
simulação, mostrando que estes dois processos podem ser vistos como
mantendo, inicialmente, uma certa relação de independência. A cada ciclo de
35
desenvolvimento do protótipo, baseado na metodologia orientada a objetos,
este vai, progressivamente, incorporando novas funcionalidades. Desta forma,
o modelo de simulação construído vai se tornando cada vez mais completo. Ao
incorporar todos os requisitos de projeto, o protótipo se converterá no próprio
simulador almejado.
2.6 ESTUDO E ESCOLHA DA FERRAMENTA COMPUTACIONAL
Dentre as alternativas existentes de ferramentas computacionais, para
desenvolver o estudo do SBCD, usando a tecnologia de simulação, há,
basicamente, quatro opções:
1) Usar um modelo comercial pronto (off-the-shelf);
2) Modificar um modelo existente;
3) Usar um ambiente (framework) de desenvolvimento de modelos; e
4) Desenvolver um modelo customizado usando linguagens de simulação.
Um modelo comercial é normalmente a melhor escolha, se houver um
disponível. Suas vantagens são que ele já está desenvolvido, tem suporte do
fabricante, já terá sido testado através de aplicações anteriores e pode ser
usado imediatamente, sem atrasos. Suas desvantagens são o preço e o fato
de que os pacotes comerciais são, em sua maioria, fechados e não permitem
modificações.
Um modelo comercial testado neste trabalho, considerado como opção inicial,
foi o STK – Satellite Tool Kit (AGI, 2001), existente na ETE. Este modelo foi
considerado insatisfatório, em virtude da impossibilidade de atender os
requisitos mínimos do simulador, tanto no que diz respeito a montagem e
36
recuperação de um cenário constituídos por diversas PCDs-satélites-ERCDs,
como pela posterior simulação do envio e recepção das mensagens coletadas
por aquelas estações terrestres.
No entanto, alguns benefícios foram obtidos com base nesta experiência com
o sistema STK, pois o pacote serviu como referência, para a construção do
protótipo, tanto na exemplificação da forma de animação das órbitas dos
satélites, quanto no uso dos elementos “two-line”, padronizados pelo NORAD
(“North American Aerospace Defense Command”), para a propagação orbital
(Sousa, 2000).
Modificar um modelo existente, para adaptá-lo ao sistema pretendido, como
preconizado na segunda opção, é uma tarefa difícil. Tecnologias proprietárias,
mesmo quando elas são fornecidas de forma aberta, para serem utilizadas em
pesquisa e desenvolvimento, precisam de um completo entendimento, antes
que as alterações necessárias no modelo sejam implementadas. Além disso,
os desenvolvedores originais podem não estar dispostos ou não serem
acessíveis para se obter deles todo o auxílio necessário.
Um exemplo de ferramenta que se pode adaptar e utilizar neste trabalho é a
propagação orbital (Kelso, 1995), disponível nas linguagens de programação
Fortran e Pascal. O mesmo não ocorreu com os sistemas comerciais, à
semelhança do STK, que não tornam público os códigos fontes e uma
documentação mínima que permita modificar o produto para as características
desejadas no estudo de simulação do SBCD.
O emprego da terceira opção, se baseia no uso de um ambiente (framework)
de construção de modelos, e fornece um ponto de partida intermediário entre o
modelo pré-construído (sistema comercial) e o desenvolvimento completo do
modelo, reduzindo o tempo e o custo para o sua implementação. O processo
se torna mais rápido, devido ao uso de componentes fornecidos em uma
37
biblioteca de objetos, que podem ser adaptados e estendidos para executar as
funcionalidades de um protótipo ou de uma aplicação completa de simulação.
Uma tentativa neste sentido foi feita também para o SBCD, tendo-se utilizado o
pacote comercial COMNET III, disponível no LAC, que permite a análise e a
avaliação de uma grande variedade de redes de comunicação de dados,
desde simples redes locais – LAN, até complexas redes corporativas
distribuídas por uma grande área – WAN. (Caci, 1997a)
O COMNET III permite a construção do modelo de simulação, a partir da
identificação da topologia da rede. A topologia da rede consiste na montagem
dos recursos existentes, que são descritos através de blocos de construção,
objetos, para representar os nós e os “links” do sistema. Os nós são os pontos
com funções de processamento, tipicamente computadores e equipamentos de
transmissão, que se conectam aos links. Estes, por sua vez, representam os
meios de transmissão, que ligam dois ou mais nós.
Com o COMNET III foi possível construir um modelo simples que se mostrou
inadequado devido a impossibilidade de simular aspectos importantes
existentes no sistema real. O fato do segmento espacial está projetado para
operar com satélites de órbitas baixas, necessita que o posicionamento dos
satélites, em relação as estações terrestres, sejam constantemente alterados.
Com isso, a comunicação PCD - satélite - ERCD, é totalmente dependente da
visibilidade das estações terrestres em relação ao satélite. Esta característica
não pode ser implementada no modelo, pela inexistência de blocos de
construção móveis, que pudessem simular o segmento espacial.
A Figura 2.5 mostra o modelo construído do SBCD com o auxílio do ambiente
de simulação COMNET III.
38
Fig. 2.5 - Modelo do SBCD construído no COMNET III.
Outra dificuldade encontrada foi na definição do link de subida, PCD – satélite.
Ele precisou ser definido como sendo um link do tipo ALOHA, (“broadcast”) por
não existir outro com as características mais próximas do sistema real. Ocorre
que este tipo de link, na realidade, não se comporta como o protocolo
empregado no SBCD, principalmente no caso de colisão de mensagens.
Uma outra ferramenta pesquisada foi SIMPROCESS que, apesar de se
destinar a análise e modelos de processos de negócios, poderia auxiliar na
análise do SBCD, combinando os recursos de simulação do programa, com a
possibilidade de animação gráfica. Novamente, a solução se mostrou
inadequada, em virtude de não se poder contar com os códigos fontes e a
documentação completa do SIMPROCESS. Com isso, utilizar o programa
implicaria em um risco elevado, por não permitir modificações nos objetos préconstruídos, que se fizessem necessários, durante o andamento do trabalho.
39
Por fim, se não há nenhum modelo apropriado disponível, baseado em pacotes
prontos, ferramentas ou ambientes de desenvolvimento pré-existentes, a
opção que resta para efetuar um estudo de simulação, é construí-lo, usando-se
uma moderna linguagem de simulação. O tempo e o custo de desenvolvê-lo
podem ser elevados, mas são plenamente justificáveis dados os benefícios em
termos de flexibilidade na construção e manutenção do modelo.
Desta forma optou-se pelo desenvolvimento de um simulador próprio para o
sistema, e para tanto, foi escolhida a linguagem de simulação MODSIM III,
devido as característica que serão apresentadas a seguir.
2.7 LINGUAGEM MODSIM III
A linguagem de simulação escolhida, por atender bem às características do
projeto, foi MODSIM III, que é uma linguagem de simulação discreta, dotada
de recursos avançados para o desenvolvimento de interfaces gráficas,
permitindo a rápida prototipação de sistemas baseados na metodologia de
orientação a objetos.
MODSIM III é uma linguagem própria de programação de alto nível, gerando
código C++ numa etapa intermediária, que é compilado usando o compilador
da plataforma utilizada, estando disponível nos ambiente Windows 95, 98, NT
e em plataformas UNIX.
MODSIM III dispõe de um ambiente completo de desenvolvimento, consistindo
de uma camada para simulação, editor gráfico, gerente de compilação,
debugger interativo e bibliotecas pré-construídas, possibilitando desta forma ao
programador a elaboração de aplicações complexas, com qualidade e maior
rapidez.
As bibliotecas fornecidas com a linguagem incluem módulos que fornecem
40
toda as capacidades necessárias para se programar modelos de simulação
discreta, como também, módulos para desenvolver interfaces do usuário e
mecanismos de apresentação de resultados.
Os objetos em MODSIM III são codificados em dois módulos distintos, o de
Definição e o de Implementação. O módulo de Definição descreve o tipo de
objeto, declarando suas variáveis e métodos. A lógica do que eles fazem e
como eles afetam as variáveis do objeto são descritas no módulo de
Implementação. A seguir é apresentado um exemplo de um módulo de
Definição e o de Implementação para um objeto aeronave, adaptado de
MODSIM III (Caci, 1997b).
2.7.1 MÓDULO DEFINIÇÃO
Aeronave = OBJECT
VelCruzeiro : REAL;
EmVoo : BOOLEAN;
ASK METHOD DetVelCruzeiro (IN v : REAL);
TELL METHOD Voar (IN Dist : REAL);
END OBJECT;
O módulo de Definição para o objeto Aeronave declara as variáveis e os
métodos (funções) que o objeto usa no modelo de simulação. Nesse exemplo,
o objeto aeronave possui duas variáveis que representam seu estado e dois
métodos do que o ele pode fazer. A variável VelCruzeiro indica a velocidade de
cruzeiro para uma aeronave, e EmVoo, se a aeronave está em vôo ou não.
41
2.7.2 MÓDULO IMPLEMENTAÇÃO
OBJECT AeronaveObj
ASK METHOD VelCruzeiro (IN Velocidade : REAL);
BEGIN
VelCruzeiro := Velocidade;
END METHOD;
TELL METHOD Voar (IN Distancia : REAL);
BEGIN
EmVoo := TRUE;
WAIT DURATION Distancia/VelCruzeiro);
END WAIT;
EmVoo := FALSE;
OUTPUT (“Pouso seguro em “, SimTime);
END METHOD;
END OBJECT;
Os métodos apresentados no bloco de implementação descrevem os
comportamentos do objeto. No exemplo acima, a aeronave é capaz de
descrever o comportamento de dois métodos.
Quando a aeronave é requisitada para executar o comando ASK METHOD
VelCruzeiro, ela registra, instantaneamente, a velocidade de cruzeiro fornecida.
No caso de se requisitar a execução do comando TELL METHOD Voar, o
objeto aeronave calcula o tempo de vôo requerido para cobrir a distância
passada na chamada do método. Esta atividade, então, interrompe sua
execução até que o período de tempo calculado tenha sido gasto dentro do
modelo de simulação, antes de completar o restante do código, neste caso
imprimindo a notificação de pouso seguro.
Diferente do ASK, o método TELL é usado para descrever comportamentos
42
que tenham de simular tempo transcorrido. Enquanto este método é
interrompido, aguardando o tempo de simulação passar, outros métodos, de
outros objetos, podem estar sendo executados.
2.7.3 DISPONIBILIDADE DA LINGUAGEM DE SIMULAÇÃO
A disponibilidade da linguagem de simulação MODSIM III em sua versão
acadêmica e de pesquisa na pós-graduação em computação do Instituto
Tecnológico de Aeronáutica (ITA) do Centro Técnico Aeroespacial (CTA) e a
existência de um convênio de cooperação com a pós-graduação em
computação aplicada do INPE (CAP/INPE) permitiu que a linguagem fosse
utilizada para implementação do protótipo.
43
CAPÍTULO 3
SISTEMA DE COLETA DE DADOS BASEADO EM SATÉLITES
O sistema de coleta de dados ambientais dos satélites da MECB permite a
obtenção de forma automática dos dados ambientais, medidos em um grande
número de pontos sobre todo o território nacional, através do uso de
plataformas de coleta de dados.
Além da rede de plataforma de coleta de dados, o sistema se compõe de uma
rede de estações de recepções, que completam o segmento solo, e pelos
“transponders” a bordo dos satélites, que constituem o segmento espacial. Um
esboço simplificado do sistema está mostrado na Figura 3.1 e se encontra
descrito a seguir (Tude, 1986 ) (Yamaguti, 1994) (INPE, 1995).
Fig. 3.1 - Sistema Brasileiro de Coleta de Dados.
FONTE: INPE (2001a).
45
3.1 PLATAFORMAS DE COLETA DE DADOS
As Plataformas de Coleta de Dados, conforme mostra a figura 3.2, têm a
finalidade de efetuarem a coleta automática de dados ambientais destinados a
aplicações de monitoração tais como o de controle do fluxo de correnteza e
alarme
de
inundações,
controle
de
irrigação,
qualidade
da
água,
gerenciamento dos recursos hídricos, medidas da qualidade do ar e do clima,
migração de animais, etc.
A coleta de dados é feita por um conjunto de sensores definidos de acordo
com o tipo de monitoração desejada e da interface de aquisição de dados. Os
sensores normalmente usados são para a monitoração da qualidade e nível
dos rios e reservatórios de água, radiação solar, direção e velocidade do vento,
temperatura e umidade do solo, precipitação e concentração de ozônio, etc.
Fig. 3.2 - Plataforma de Coleta de Dados.
FONTE: INPE (2001b).
Os dados coletados, incluindo o “status” e a identificação da PCD, são
armazenados e formatados em uma mensagem padrão e transmitidos para o
46
satélite. Embora a emissão seja repetida após um certo intervalo de tempo, a
comunicação só se realiza de forma efetiva quando o satélite passa sobre um
ponto que tem visibilidade simultânea, tanto em relação à PCD quanto à
estação receptora. A potência de transmissão varia de 1 a 3 Watts com um
período de repetição podendo variar de 30 a 200 segundos. O fornecimento de
energia para as PCDs é feito por baterias e painéis solares.
As PCDs usadas no Sistema Brasileiro de Coleta de Dados podem utilizar dois
canais diferentes para a transmissão das mensagens - canal de 401.62 MHz
ou de 401,65 MHz.
As transmissões dos sinais das PCDs são aleatórias em freqüência e no
tempo. Devido ao movimento dos satélites, todos os sinais por eles recebidos
sofrem de desvio em sua freqüência de aproximadamente ± 12 kHz (efeito
Doppler). O desvio de freqüência depende da localização da PCD, da posição
do satélite e de sua velocidade no momento da transmissão. Devido aos
efeitos aleatórios incidentes sobre a freqüência e a geração das mensagens, o
canal de acesso para os “transponders” a bordo dos satélites é considerado
compartilhável por todas as PCDs visíveis em qualquer instante. Se duas ou
mais mensagens coincidirem, entretanto, tanto em freqüência, quanto em
instante de chegada, haverá uma colisão e todas elas serão perdidas.
O sistema deve ser capaz de atender entre 500 e 2000 PCDs (seu número
exato deverá ser determinado também a partir dos resultados da simulação),
até 20 satélites em órbita e até 20 estações terrenas. As PCDs podem estar
distribuídas em todo território brasileiro, e seus sinais devem ser recebidos e
processados com probabilidade de sucesso superior a 95% durante as
passagens favoráveis do satélite.
As passagens favoráveis do satélite são definidas como aquelas durante as
quais a PCD consegue fazer em média três transmissões durante o período de
47
visibilidade mútua PCD-satélite-estação terrena. O número de passagens
favoráveis em 24 horas depende da localização da PCD.
A taxa de repetição e a potência das mensagens transmitidas pelas PCDs
podem ser alteradas, de forma que pelo menos uma mensagem livre de erros
consiga ser transmitida por dia pelo sistema.
3.2 OS SATÉLITES
Não há nenhum processamento do sinal a bordo dos satélites, nem há
qualquer capacidade para armazenamento e uma posterior retransmissão de
mensagens. Os “transponders” a bordo dos satélites apenas modulam as
mensagens recebidas nas freqüências de 401,65 MHz ou de 401,62 MHz,
efetuam um ganho de potência sobre seu sinal, e as retransmitem para uma
estação terrena localizada em Cuiabá (GS), operando na banda S na
freqüência de 2267 MHz.
No caso dos satélites CBERS1 (já em operação), CBERS2, e SCD3 as
mensagens recebidas das PCDs também serão retransmitidas diretamente
para estações receptoras terrenas (ERCDs) que estiverem no campo de
visibilidade simultânea PCD-satélite-ERCD, e que operam na banda UHF em
462,5 MHz.
48
Fig. 3.3 - Satélite SCD1 em órbita.
FONTE: INPE (2001c).
Na estação de recepção, os sinais na banda S e UHF recebidos são
convertidos para banda base para procura e detecção dos sinais das PCDs.
Quando um sinal de PCD é detectado, um canal de processamento é alocado
para a demodulação e armazenamento da mensagem na estação. No caso de
estação na banda S (estações de Cuiabá e Alcântara) todas as mensagens
recebidas são enviadas para o Centro de Missão de Coleta de Dados
(Cachoeira Paulista), após o término da passagem do satélite,
para
processamento, armazenamento em banco de dados e disseminação aos
usuários.
3.3 ESTAÇÕES DE RECEPÇÃO DE COLETA DE DADOS
A ERCD é um sistema completo destinado a aquisição e acompanhamento do
satélite, recepção e processamento de dados para o Sistema Brasileiro de
Coleta de Dados de satélites de órbitas baixas. Devido ao esquema de acesso
aleatório, a ERCD efetua a procura e detecção do sinal da PCD, antes de
recuperar os dados. Os dados recuperados são armazenados em um banco de
dados e disponibilizados para os usuários, tanto em sua forma original (bruta),
49
como após ter passado por uma crítica e formatação. Os usuários podem
acessar esses dados usando um computador tipo PC conectando-se a ERCD
através da rede pública de telefonia e pela INTERNET.
A ERCD pode processar dois ou mais sinais simultâneos das PCDs
dependendo do número de canais de processamento determinado de acordo
com a necessidade do usuário. O processador de coleta de dados executa as
funções destinadas a designação do canal, configuração e monitoração do
“hardware”, banco de dados e facilidades de comunicação.
A estação de recepção pode receber e processar tanto os sinais das
plataformas de coleta de dados do INPE como das redes existentes operando
no sistema internacional ARGOS. Como as PCDs operam com um canal
específico de freqüência, a ERCD pode ser programada para operar com
diferentes formatos de mensagens.
Estão disponíveis dois tipos de ERCDs, uma que opera na banda S, no enlace
de descida, usando uma antena com capacidade de auto-acompanhamento,
conforme ilustração contida na Figura 3.4.
50
Fig. 3.4 – Estação Terrena de Cuiabá.
FONTE: INPE (2001d).
O outro tipo de estação de recepção opera na faixa de UHF, utilizando-se de
uma antena de baixo custo. O primeiro tipo de estação permite uma cobertura
de uma grande área, enquanto o segundo é um sistema que necessita de
menores investimentos.
3.4 EXEMPLOS DE CONSULTAS DO SBCD
Como um dos exemplos de uso das informações disponibilizadas pelo SBCD
para os usuários finais, a figura 3.5 apresenta um relatório de monitoramento
hidrológico diário, produzido pela Agência Nacional de Energia Elétrica
(ANEEL), tendo em vista a geração da Energia Elétrica em diversas bacias
hidrográficas brasileiras.
51
Fig. 3.5 - Monitoramento Hidrológico Diário.
FONTE: ANEEL (2001).
Outro tipo de saída pode ser visualizada na figura 3.6, que apresenta o
Relatório dos Dados Coletados nos últimos 5 dias, captados por PCDs
Meteorológicas. O exemplo escolhido foi o da plataforma instalada no
município de Caldas Novas – GO, onde são apresentadas as informações
coletadas, daquela localidade, que foram recebidas, com êxito, pelo Centro de
Missão do SBCD.
52
Fig. 3.6 - Relatório dos Dados Coletados nos últimos 5 dias.
FONTE: INPE (2001e).
53
CAPÍTULO 4
ESPECIFICAÇÃO DE REQUISITOS E MODELAGEM FUNCIONAL
Este capítulo apresenta a especificação dos requisitos previamente definidos
pelos usuários e operadores do simulador e, com base nestes, é feita a
modelagem funcional do sistema e a modelagem de objetos do protótipo.
A modelagem funcional do simulador na forma de grandes componentes ou
módulos visa decompô-lo em elementos que implementem todas as
características exigidas para que este represente adequadamente o sistema
real, tendo-se sempre em consideração os objetivos do estudo.
Ela engloba o modelo computacional do sistema propriamente dito e as
funcionalidades associadas à interface gráfica de interação com o usuário.
Inicialmente são apresentados os requisitos do simulador, conforme as
especificações contidas em INPE (1995). Em seguida são apresentados os
modos de operação da interface gráfica com o usuário, e é feita a proposta de
uma estrutura para os módulos componentes principais do simulador. Por fim,
apresenta-se o modelo de classes criado e as limitações do protótipo, que
refletem as restrições do escopo e abrangência adotadas no desenvolvimento
do presente trabalho.
4.1 REQUISITOS GERAIS
Os requisitos do simulador, utilizados no desenvolvimento do modelo e do
protótipo do sistema, foram definidos tomando-se como referência as
especificações contidas em INPE (1995).
55
O modelo computacional para simulação deve contemplar todos os processos
compreendidos pelo SBCD, desde o processo de geração das mensagens
pelas PCDs, os enlaces de subida para o satélite, o processo de transposição
de freqüência e ganho de potência realizado pelo “transponder” a bordo do
mesmo, o enlace de descida até a estação terrena em Cuiabá (GS), ou
estações terrenas - ERCDs, e o processo de recepção e tratamento dos dados
realizado por estas últimas.
O simulador será utilizado para se analisar e avaliar o desempenho global do
sistema em diferentes cenários de operação envolvendo fatores dos seguintes
tipos: configurações de PCDs (tipo, número, localização, etc.); configurações
das estações de recepção (tipo, número, localização, etc.); constelações de
satélites em utilização (órbitas, altitude, potência de retransmissão, etc.); e
alternativas de operação do sistema de acordo com estratégias diferenciadas
(intervalo entre mensagens, potência de transmissão).
A lista de requisitos gerais inclui algumas exigências referentes à própria
capacidade de operação do simulador. As principais delas são: o sistema deve
ser capaz de representar até 2000 PCDs, até 20 satélites em órbita e até 20
estações receptoras terrenas (GS ou ERCDs); ele deve ainda permitir a
operação simultânea de mais de um satélite, bem como de mais de uma
estação terrena, a apresentação dos resultados da simulação de forma gráfica
e textual e oferecer ajuda “on line” para o usuário.
4.1.1 REQUISITOS GENÉRICOS DA INTERFACE GRÁFICA
A interface do sistema deve permitir a representação gráfica e a animação de
todas as entidades do sistema, tais como a rede de PCDs, com sua
localização determinada automaticamente ao serem inseridas sobre um mapa
do Brasil georeferenciado, bem como os satélites e suas respectivas órbitas,
as estações terrenas e os enlaces de comunicação estabelecidos entre eles.
56
A interface deve estar baseada em janelas gráficas e menus, cuja utilização se
fará de forma homogênea para todas as operações de criação, especificação e
execução do modelo de simulação. As configurações do modelo deverão ser
feitas “on line”, com o posicionamento na tela dos elementos gráficos e a
parametrização destes, pela atribuição de valores definidos pelo usuário no
início da simulação, ou a partir de parâmetros 'default' designados pelo sistema
na falta destes.
4.1.2 REQUISITOS DOS COMPONENTES ESPECÍFICOS
O módulo principal deve permitir o gerenciamento de todas as operações do
simulador, e a correta interação entre os seus módulos componentes durante a
execução das corridas de simulação. As corridas devem poder ser
interrompidas para a redefinição dos parâmetros do sistema de maneira
interativa e o monitoramento das variáveis de estado por meio de “displays”
durante sua execução. O módulo principal provê ainda meios para a realização
de outras tarefas básicas relacionadas com o estudo de simulação, tais como a
execução dos experimentos e a coleta de dados das corridas.
O módulo principal é responsável pela identificação e tratamento de possíveis
erros, tanto nas situações de anormalidade no funcionamento do modelo,
quanto em relação a possíveis desvios do comportamento ideal previsto para a
operação do sistema real, tais como desvios de órbitas previstas dos satélites,
resultantes de distorções relativas ao seu ponto de injeção em órbita,
velocidade e ângulos de posicionamento, assim como mal alinhamento de
suas antenas devido a movimentos erráticos dos mesmos verificados durante
sua operação.
O módulo principal é finalmente responsável pela geração dos relatórios
contendo informações do tipo: janela de visibilidade por passagem do satélite
por dia de uma determinada plataforma em relação a uma determinada
57
estação terrena; o número de mensagens recebidas de cada PCD (por estação
ou conjunto de estações, referentes a uma passagem do satélite ou a um dia
de operação do sistema), a distribuição do número de mensagens geradas por
uma PCD ou conjunto de PCDs que foram recebidas em um intervalo de
tempo ou em um dia de operação, seja por uma determinada estação, ou pelo
satélite ou pelo sistema como um todo.
Cada um dos demais objetos componentes do sistema possui ainda um
conjunto de atributos mínimos e de funcionalidades requeridas para a definição
completa de sua configuração dentro do modelo e para a execução de todas
as operações por eles efetuadas no sistema.
Estes atributos individuais e funcionalidades estão listados a seguir:
Para as PCDs:
1) Uma série de atributos do tipo: potência de transmissão efetiva atingida
pelo conjunto PCD/antena, localização (latitude, longitude, altitude), taxa
de repetição (intervalo de tempo entre duas mensagens consecutivas),
comprimento da mensagem, freqüência da portadora utilizada no satélite
(e sua faixa de variação), estabilidade do oscilador (influencia a
freqüência e a dispersão do sinal gerado), cabeçalho identificador do
gerador da mensagem, instante inicial da transmissão, estrutura e
formato da mensagem transmitida por cada PCD;
2) A simulação de uma determinada configuração de PCDs, com seu
número total e sua distribuição espacial definidas pelo usuário;
3) A geração de uma série de pulsos ou mensagens para cada PCD da
rede, de acordo com um conjunto de especificações previamente
introduzidos pelo usuário, com base nos parâmetros acima mencionados;
58
4) A armazenagem destes conjuntos de mensagens durante o tempo de
visibilidade simultânea para cada passagem do satélite, em relação a
cada PCD e a rede como um todo; e
5) A
utilização
de
geradores
de
números
aleatórios
para
os
procedimentos de geração dos pulsos e para a determinação da
freqüência e instante inicial de operação do oscilador de cada PCD.
Para as estações terrenas:
1) Uma série de atributos do tipo: localização (latitude, longitude, altitude);
ângulo mínimo de elevação, G/T, freqüência da portadora (Banda S ou
UHF), largura da banda, C/No, probabilidade de detecção de mensagens,
probabilidade de falso alarme, número de canais disponíveis para
processamento das PCDs;
2) Determinação da capacidade de detecção e de processamento do
sinal emitido pelo satélite, de acordo com uma série de especificações
designadas para cada uma das estações terrenas;
3) Determinação da disponibilidade de um canal para processamento do
sinal e da probabilidade final deste ser processado corretamente, de
acordo os parâmetros mencionados;
4) Determinação da freqüência de colisão dos sinais das várias PCDs; e
5) Associação dos sinais das PCDs com uma série de parâmetros de
“status” da mensagem sendo recebida, tais como: identificação da PCD
de origem, freqüência de colisão com outras PCDs, suficiência de tempo
para processo de varredura e aquisição, disponibilidade de canal,
59
probabilidade final do processamento correto da mensagem, desvio
Doppler no início da transmissão do sinal pela PCD.
Para os satélites:
1) Uma série de atributos do tipo: elementos de definição da órbita,
atitude e forma de estabilização, potência de transmissão (Bandas S e
UHF) ou potência de retransmissão nos demais casos, G/T, freqüência e
estabilidade do oscilador;
2) A simulação da órbita e atitude de cada satélite componente do
sistema (SCD1, SCD2, SCD3, CBERS1, CBERS2). Esta função deve
conter facilidades para a inclusão futura de outros tipos de missões
(novos satélites);
3) A simulação em um dado instante, e para uma dada PCD, do efeito
Doppler (espectro de freqüência, sua taxa de variação), com base no
azimute e elevação do satélite em relação à estação terrena (GS ou
ERCD);
4) Utilização de diferentes sistemas de coordenadas, bem como o
fornecimento de facilidades destinadas à transformação entre eles,
incluindo os seguintes sistemas: geocêntrico inercial, geocêntrico terrestre
e topocêntrico terrestre (Kuga, 1995);
5) A consideração de que, uma vez em órbita, a variação da posição do
satélite e de sua velocidade podem ser determinadas através da
propagação de elementos keplerianos, conforme descritos pela Teoria de
Brouwer; e
60
6) A avaliação dos ângulos de atitude do satélite com relação às PCDs e
às estações terrenas (GS ou ERCDs), dos ângulos relativos à visibilidade
simultânea (cumulativa) entre o satélite e as PCDs, e entre o satélite e as
estações terrenas, bem como o azimute e a elevação de cada estação e
de cada PCD com relação ao satélite.
4.2 MODOS DE OPERAÇÃO DO SIMULADOR
Os modos de operação do simulador, casos de uso (Jacobson, 1992 e 1998),
são aqueles associados com as formas de interação do usuário com o sistema,
que precisam ser implementadas através de sua interface gráfica.
A Figura 4.1 mostra que o simulador é dotado de quatro modos de operação
principais: montagem de cenário (subdividido em configuração do cenário e
inicialização das entidades); projeto de experimentos; simulação (subdividido
em inicialização da execução, simulação, exibição e controle, geração de
resultados); e análise e apresentação de resultados.
61
MONTAGEM DE CENÁRIO
- Configuração dos cenários
- Inicialização das entidades
PROJETO DE EXPERIMENTOS
SIMULAÇÃO
- Inicialização da execução
- Simulação
- Exibição e controle
- Geração de resultados
ANÁLISE
E
APRESENTAÇÃO DOS RESULTADOS
Fig. 4.1 - Modos de Operação do Simulador.
O modo montagem de cenário destina-se a entrada dos elementos que
comporão o sistema a ser simulado, formado pelas PCDs, os satélites e as
Estações de Recepção de dados, com os seus respectivos atributos.
62
Através de uma interface gráfica, o usuário irá descrever a rede de coleta de
dados a ser analisada, que tanto poderá ser carregada a partir da base de
dados de estações anteriormente cadastradas, como criá-la no momento,
posicionando as estações, via “mouse”, em suas coordenadas geográficas. A
qualquer instante, são permitidas atualizações no cenário, seja na forma de
inclusão de novas PCDs, como de alterações de suas características ou
mesmo desativação de outras.
As Estações de Recepção de dados, de forma semelhante as PCDs, podem
também ser incluídas no cenário a partir da base de dados e serem
atualizadas posteriormente.
O satélite será escolhido a partir da entrada de suas efemérides ou da lista de
satélites cadastrados. Desta forma serão descritas os objetos básicos do
ambiente a ser simulado.
O modo projeto de experimentos corresponde à entrada dos demais
parâmetros associados com a experimentação do cenário e que serão
utilizados durante a corrida de simulação. Esses parâmetros, fornecidos pelo
usuário, servirão para identificar o cenário montado, a semente para a geração
das variáveis aleatórias, bem como a velocidade de simulação desejada, etc.
Neste estágio estes dados são apenas armazenados para servirem de entrada
para o modo simulação, que juntamente com os atributos das entidades
introduzidos no modo cenário, irão permitir a avaliação do sistema.
O modo simulação é acionado após a conclusão de todo o cenário e do projeto
de experimentos, e corresponde à execução e ao controle de toda a dinâmica
do sistema, fazendo com que os objetos tenham um comportamento ativo, de
acordo com as características definidas para cada elemento.
Assim, as PCDs irão coletar e transmitir os dados ambientais, através de
63
mensagens de formatos fixos, em intervalos de tempo regulares, que serão
recebidas e retransmitidas pelo satélite que estiver visualizando a PCD para a
Estação de Recepção em terra que esteja posicionada em sua área de
cobertura naquele momento. As mensagens geradas pelas PCDs serão
atualizadas progressivamente pelos diversos objetos que interagem durante a
comunicação, isto é, PCDs, satélites e Estações de Recepção.
Desta forma, são registrados todos os possíveis estados que uma mensagem
possa sofrer durante todo o ciclo de comunicação. O módulo de simulação
produz como saída, na forma de registros nas mensagens geradas, todo o
comportamento resultante da comunicação entre os elementos do sistema.
Como exemplos de registros efetuados nos campos existentes, durante o fluxo
de mensagens, podem ser citados: a identificação do caminho percorrido, os
tempos de transmissão, retransmissão e recebimento, os desvios de
freqüência ocasionados pelo efeito Doppler, as potências resultantes.
Finalmente, o modo de análise e apresentação dos resultados utiliza os
registros nas mensagens geradas na simulação, efetuados progressivamente
pelos objetos participantes do “link” de comunicação, como fonte de entrada
para as análises estatísticas e apresentações de resultados em formatos prédefinidos. As análises poderão ser realizadas diretamente na interface gráfica
do simulador e, também, consultando-se os relatórios gerados. Desta forma, é
possível se verificar o comportamento de um cenário do sistema construído
para o período de tempo de simulação estipulado.
A interação com o usuário, em todos os modos de operação, é disponibilizada
através do módulo de interface gráfica, que possibilita desde a entrada dos
dados necessários à simulação, a visualização de todo o processo simulado e
a apresentação e impressão dos resultados Esta comunicação é realizada
através de menus, caixas de diálogos e pelo “mouse”.
64
Em geral, o modelo construído de um simulador é bem mais detalhado do que
o modelo analítico, permitindo a inclusão de distúrbios estocásticos e políticas
de funcionamento individuais, em praticamente, todos os objetos do sistema.
4.3 MODELAGEM FUNCIONAL
A modelagem funcional consiste na estruturação do modelo computacional na
forma de grandes componentes ou módulos que são os elementos que
implementam
as
funcionalidades
exigidas
para
que
ele
represente
adequadamente o sistema real, tendo-se como referência os objetivos
propostos.
Ela contempla, além do modelo computacional de simulação propriamente dito,
as interações associadas à interface gráfica com o usuário final, que é feita
com base nos casos de uso levantados, que descrevem os modos de
operação do simulador.
Com base nos modos de operação do simulador descritos no item anterior e
explorando-se a modularidade, que são características intrínsecas tanto do
modelo quanto da própria linguagem de simulação MODSIM III, é possível se
formular uma estrutura básica para representar as principais componentes do
simulador, o que é feito na Figura 4.2. Os módulos que compõem o protótipo
estão descritos no capítulo 5 - Implementação.
65
PRINCIPAIS
CASOS DE USO
Montagem
de Cenário
Projeto
de
Experimentos
Ajuda
I
N
T
E
R
F
A
C
E
Repositório de
Configurações
Repositório de
Experimentação
Módulo Satélites
C
O
M
PCD
Módulo PCD
O
Inicialização,
Simulação
com Animação,
Interação,
Reinicialização e
Geração de
Resultados
U
S
U
Á
R
I
O
Inicia Simulação,
Interrompe corrida,
Reinicializa
Experimentação
M
Ó
D
U
L
O
Análise e
Apresentação
de Resultados
Módulo Help
M
A
P
W
I
N
Geração de
Relatórios
SATÉLITES
Geração de
Trajetórias
Controle de
Visibilidade
ERCD
Módulo Estações
MÓDULO PRINCIPAL
Simulação
Experimentação
Tratamento de Erros
Geração
de Dados
Arquivo
de Dados e
Resultados
Relatórios
Dados e
Resultados
Gráficos
Apresentação
de Resultados
Módulo Result
Fig. 4.2 - Componentes do Simulador.
66
4.4 DIAGRAMA DE CLASSES
No paradigma de orientação a objetos, uma classe ou objeto é constituído por
sua estrutura de dados e pelas operações a ele associadas, que implementam
suas funcionalidades e realizam a comunicação entre eles através de
mensagens.
Para se determinar que entidades, classes ou objetos, são necessários na
descrição do sistema e os tipos de funcionalidades que elas necessitam
implementar, é necessário se construir uma estrutura de classes.
Como descrito anteriormente, o SBCD é essencialmente composto por três
grupos distintos de objetos que interagem de modo a permitir que os dados
ambientais, coletados pelos grupos das PCDs, sejam, transmitidos para os
satélites, que por sua vez, os retransmitem para estações em terra,
completando, desta forma, um ciclo completo de comunicação realizada com
sucesso.
Portanto, a estrutura hierárquica básica de classes consiste de três ramos
principais representando as PCDs, os satélites e as ERCDs que efetivam a
transmissão dos dados
ambientais coletados, via, a outra estrutura
fundamental no processo, representada pela classe de mensagens.
O diagrama de classes do protótipo do simulador para o SBCD é mostrado na
figura 4.3. Os retângulos representam as classes componentes da estrutura
apresentada.
67
Menu
Background
Paleta
MapWindown
Mensagem
Plataforma
PCD
Fixa
Satélite
Móvel
ERCD
Banda S
UHF
Fig. 4.3 - Diagrama de Classes do Simulador.
As características comuns das três classes principais do sistema, PCD, satélite
e ERCD, são descritas numa classe denominada plataforma. Estas, também,
se relacionam com a classe das mensagens que, por sua vez, representa e
registra o tráfego de mensagens efetivamente realizado no sistema.
Tanto as PCDs, quanto os satélites e ERCDs são subdivididos em tipos, de
acordo com características físicas de seu posicionamento, PCDs móveis ou
fixas, ou de freqüência de transmissão/recepção, Bandas S ou UHF.
As classes Menu, “Background” e Paleta são apresentadas no modelo por
68
disponibilizarem requisitos importantes desejáveis do sistema. Elas estão
incorporadas na classe MapWindown, que por sua vez, implementa a interface
gráfica do simulador com o usuário final.
4.5 LIMITAÇÕES DO MODELO E DOS REQUISITOS DO PROTÓTIPO
Os requisitos originalmente descritos foram limitados em alguns aspectos para
fins deste trabalho, tendo em vista o seu escopo acadêmico e a limitação de
tempo de desenvolvimento do mesmo, a saber:
Para a trajetória dos satélites serão utilizadas as rotinas de propagação orbital
fornecidas
pelo
NORAD
(Kelso,
1999),
obtidas
via
internet
em
www.celestrak.com, que retornam a posição e a velocidade de satélite para
instantes desejados. O conjunto de elementos que identificam um satélite,
gerados pelo NORAD para a propagação orbital, são chamados NORAD “twoline”, ou efemérides, podendo estes também ser obtidos via internet, no
endereço acima citado. O formato do elemento NORAD “two-line” é
apresentado no apêndice A.
Não serão considerados os erros provenientes de desvios no ponto de injeção
do satélite: ponto, velocidade e ângulo de injeção, bem como os possíveis
desalinhamentos das antenas em virtude de movimentos erráticos do satélite.
Não será feito tratamento de ruídos de outra origem, que não os diretamente
relacionados com as colisões de mensagens com freqüências sobrepostas e
que tenham sido geradas simultaneamente (exclui-se, portanto, cobertura de
nuvens, radiações de fontes externas ao sistema, etc.).
69
CAPÍTULO 5
IMPLEMENTAÇÃO
A metodologia de desenvolvimento adotada para a criação do protótipo do
simulador está baseada na simulação orientada a objetos e a linguagem de
implementação que está sendo utilizada é MODSIM III.
A metodologia de orientação a objetos foi escolhida devido às características
do projeto. Os benefícios esperados pela adoção desta metodologia vão desde
a maior facilidade na concepção do modelo, com base em princípios modernos
de engenharia de software, bem como em sua modularização, extensibilidade
e reusabilidade. Além disto o uso da orientação a objetos permite a adoção de
um estilo incremental de programação e possibilita um rápido desenvolvimento
de protótipos, mesmo para complexos sistemas de simulação.
Durante o estudo da linguagem MODSIM III foram avaliados os diversos
exemplos de modelos de simulação contidos no “software”, que serviram de
complemento ao aprendizado e foram tomados como referência para a
programação do simulador.
As componentes e módulos identificados na modelagem funcional são
detalhados e descritos com base em objetos, que implementam as
necessidades funcionais requisitadas em cada um deles. Os objetos com
maior afinidade entre si são mantidos agrupados para uma melhor
modularidade do sistema.
A documentação apresentada a seguir, destina-se a fornecer uma descrição
dos módulos de definição que compõem o protótipo do simulador. Os módulos
de definição definem a interface de interação de cada objeto com os demais
objetos componentes do sistema e são em geral suficientes para a
71
compreensão de todos os seus atributos e funcionalidades, dispensando a
consulta ao seu código de implementação, a menos que o analista deseje
compreendê-lo em detalhes para utilizá-lo em outra situação ou modificá-lo.
A extensão do código que descreve o modelo na versão inicial do protótipo é,
aproximadamente, de mil
linhas. Abaixo
são ilustrados
os módulos
desenvolvidos em MODSIM III, que serão detalhados nos próximos tópicos.
1) MSSBCD - Programa principal do simulador;
2) DMAPWIN - Módulo de exibição e controle ou interface gráfica do
protótipo;
3) DPCD - Módulo das Plataformas de Coleta de Dados;
4) DSATELITE - Módulo dos satélites;
5) DERCD - Módulos das Estações de Recebimento Terrestres;
6) DRESULT - Módulo de Apresentação de Resultados; e
7) DHELPDLG - Módulo de Ajuda.
5.1 MSSBCD - PROGRAMA PRINCIPAL DO SSBCD
MAIN MODULE SSBCD ;
FROM Gprocs
IMPORT HandleEvents ;
FROM MapWin IMPORT MapWindow ;
BEGIN
NEW (MapWindow) ;
ASK MapWindow TO Init ;
LOOP
72
HandleEvents (TRUE) ;
END LOOP ;
END MODULE .
O programa principal é utilizado apenas para controlar a interação do usuário
com os diversos menus e suas listas de comandos disponibilizados na
interface gráfica, o que é feito através da rotina HandleEvents.
Embora denominado e implementado como sendo o programa principal do
simulador, na prática ele é somente uma extensão da sua interface gráfica,
conforme explicado abaixo. Isto foi feito desta forma porque a própria estrutura
de programas em MODSIM III exige que haja um programa principal, separado
das demais componentes do protótipo usadas na implementação da interface
gráfica e do modelo do sistema.
5.2 DMAPWIN - MÓDULO DE EXIBIÇÃO E CONTROLE
DEFINITION MODULE MapWin ;
FROM Window IMPORT WindowObj ;
FROM Gpalet
IMPORT PaletteObj, PaletteButtonObj ;
FROM Graphic
IMPORT GraphicLibObj ;
FROM Text
IMPORT TextObj ;
FROM Image
IMPORT ImageObj ;
FROM Menu
IMPORT MenuBarObj, MenuItemObj ;
FROM RandMod IMPORT RandomObj ;
FROM IOMod
IMPORT StreamObj, ALL FileUseType ;
TYPE
OffsetRandomObj = OBJECT (RandomObj) ;
ASK METHOD OffsetStream (IN offset : INTEGER) ;
END OBJECT ;
ComMenuBarObj = OBJECT (MenuBarObj) ;
ASK METHOD DoSave ;
ASK METHOD DoLoad ;
OVERRIDE
73
ASK METHOD BeSelected ;
END OBJECT ;
MessageNodeObj = OBJECT
Message : STRING;
ASK METHOD SetMessage(IN message : STRING) ;
END OBJECT ;
MapPaletteObj = OBJECT (PaletteObj) ;
Select
: PaletteButtonObj ;
GroundStation
: PaletteButtonObj ;
Satellite
: PaletteButtonObj ;
PcdStation
: PaletteButtonObj ;
CurrentSelection : PaletteButtonObj ;
ASK METHOD InitChildren ;
OVERRIDE
ASK METHOD BeSelected ;
END OBJECT ;
MapWindowObj = OBJECT (WindowObj) ;
Menubar
: ComMenuBarObj ;
Background
: ImageObj ;
Palette
: MapPaletteObj ;
MessageCount : TextObj ;
ASK METHOD Init ;
ASK METHOD UpdateMessageCount (IN num : INTEGER) ;
ASK METHOD VerifySim () : BOOLEAN ;
ASK METHOD CreateNewNode () : ImageObj ;
OVERRIDE
ASK METHOD MouseMove (IN x, y : REAL) ;
ASK METHOD MouseClick (IN x, y : REAL ;
IN buttonDown : BOOLEAN) ;
END OBJECT ;
VAR
MapWindow
: MapWindowObj ;
GraphicLib
: GraphicLibObj ;
Random
: OffsetRandomObj ;
InSimulation
: BOOLEAN ;
OrbitRoot
: ImageObj;
Showitem
: MenuItemObj;
Hideitem
: MenuItemObj;
74
END MODULE.
Este módulo descreve a interface gráfica principal disponibilizada pelo protótipo
do simulador. Ele é o módulo que implementa a interação do usuário com o
protótipo e que aciona a chamada do módulo principal descrito nos requisitos,
que tem a finalidade de controlar toda a agenda de eventos da simulação. Na
implementação feita o módulo principal, correspondente à descrição existente
nos requisitos e apresentada na figura 4.2, está sendo representado pelas
bibliotecas de componentes pré-existentes do MODSIM III, que realiza o
controle da agenda de eventos e aciona a chamada dos demais módulos
componentes do modelo.
Com a evolução do protótipo este módulo de interface incorporará o trecho de
programa visto acima e será convertido no próprio programa principal do
simulador, embora ele continuará na verdade a representar a interface gráfica
com o usuário. O módulo principal descrito nos requisitos (figura 4.2),
continuará a ser representado pelas bibliotecas de controle geral do MODSIM
III, sendo que algumas funcionalidades previstas para ele pelos requisitos
(condução da experimentação, tratamento de erros, geração e armazenagem
dos dados de saída das corridas) poderão estar sendo implementadas no
programa principal (interface gráfica) ou gerarem novos módulos componentes
do simulador, a exemplo do que foi feito com o módulo análise dos resultados.
A implementação atual do módulo interface gráfica pode ser resumida
conforme a descrição a seguir.
O objeto MapWindowObj define a janela principal e incorpora outros objetos
necessários para a montagem do cenário, da animação dos componentes
ativos do modelo e da apresentação de resultados parciais da simulação. Esta
interface gráfica é composta da barra de menu, com as funcionalidades
disponíveis no simulador, da imagem de fundo que incorpora o mapa da
75
América do Sul, da paleta que permite criar ou modificar um cenário com os
objetos necessários, para descrever as PCDs (figura 5.1), a ERCD e o satélite
desejado, bem como os demais controles, destinados a conduzir a análise
preliminar do SBCD, que são visualizados através de mensagens.
Fig. 5.1 - Entrada de Dados da PCD.
Outros objetos disponíveis neste módulo são o gerador de número aleatórios,
OffsetRandomObjt
e,
o
MessageNodeObj
destinado
ao
registro
mensagens que trafegam no modelo.
5.3 DPCD - MÓDULO DAS PLATAFORMAS DE COLETA DE DADOS
DEFINITION MODULE Pcd ;
FROM Image
IMPORT ImageObj ;
FROM GrpMod IMPORT QueueObj ;
FROM IOMod
IMPORT StreamObj ;
FROM Sat
IMPORT SatelliteObj ;
FROM MapWin IMPORT MessageNodeObj ;
TYPE
76
das
PcdStationQObj = OBJECT (QueueObj[ANYOBJ:PcdStationObj]) ;
ASK METHOD InitSim ;
ASK METHOD RandomStation (IN source : PcdStationObj) :
PcdStationObj ;
END OBJECT ;
PcdStationObj = OBJECT (ImageObj) ;
MeanTimeBtwnMsg
: REAL ;
ASK METHOD SetMeanTimeBtwnMsg (IN time : REAL) ;
TELL METHOD Simulate ;
ASK METHOD SendMessage (IN target : SatelliteObj;
IN MessageNode : MessageNodeObj) ;
OVERRIDE
ASK METHOD ObjInit ;
ASK METHOD ObjTerminate ;
ASK METHOD BeSelected ;
CLASS
PcdStations
: PcdStationQObj ;
ASK METHOD NewPcdStations ;
ASK METHOD SavePcdStations (IN file : StreamObj) ;
ASK METHOD LoadPcdStations (IN file : StreamObj) ;
END OBJECT ;
VAR
AnimationSpeed
: INTEGER ;
NumMsgAttempted : INTEGER ;
END MODULE .
Este módulo descreve as Plataformas de Coletas de Dados, e objetos
correlatos às PCDs. O primeiro objeto, PcdStationQObj, destina-se a
incorporar a fila de PCDs criadas no cenário, e controla o início de simulação
destas plataformas através do procedimento InitSim. O outro procedimento,
RandomStation, possibilita a escolha aleatória de uma PCD das existentes na
fila mantida pelo objeto anterior.
O objeto PcdStationObj descreve as características das plataformas e as suas
funcionalidades, através dos atributos e dos métodos incorporados na classe
77
para permitir a simulação do funcionamento das PCDs. O método Simulate
destina-se a controlar o tempo simulado transcorrido na operação normal da
plataforma. O método SendMessage destina-se a enviar uma mensagem para
um satélite, e os métodos ObjInit, ObjTerminate e BeSelect, respectivamente,
para criar, terminar e selecionar um determinado objeto. A classe de objeto do
tipo fila, anteriormente apresentada, permite a inclusão de novas PCDs, pela
execução do procedimento NewPcdStations e, também, possibilitam que as
plataformas
criadas
sejam
salvas
ou
recuperadas
em
disco,
pelos
procedimentos SavePcdStations e LoadPcdStations.
A variável AnimationSpeed controla a velocidade da animação dos objetos
instanciados e a NumMsgAttempted o número de mensagens transmitidas.
5.4 DSATELITE - MÓDULO DOS SATÉLITES
DEFINITION MODULE Satélite ;
FROM GrpMod IMPORT QueueObj, RankedObj ;
FROM Gtypes
IMPORT PointType ;
FROM IOMod
IMPORT StreamObj ;
FROM Ground
IMPORT GroundStationObj ;
FROM MapWin IMPORT MessageNodeObj ;
FROM Animate IMPORT DynImageObj, DynDClockObj;
FROM Line
IMPORT PolylineObj;
TYPE
SatelliteQObj = OBJECT (QueueObj[ANYOBJ:SatelliteObj]) ;
ASK METHOD InitSim ;
ASK METHOD RandomStation : SatelliteObj ;
END OBJECT ;
SatelliteObj = OBJECT (DynImageObj) ;
Quadrant
: INTEGER;
OrbitPosition : REAL;
OrbitVelocity : REAL;
OrbitCenterX : REAL;
OrbitCenterY : REAL;
78
OrbitRadius
: REAL;
Orbit
: PolylineObj;
TELL METHOD Simulate ;
ASK METHOD ComputeQuadrant;
ASK METHOD ComputePosition (IN orbitPostion : REAL;
OUT x, y : REAL);
ASK METHOD SetOrbitData (IN radius, position : REAL);
ASK METHOD SendMessage (IN target : GroundStationObj ;
IN MessageNode : MessageNodeObj) ;
ASK METHOD ReceiveMessage (IN MessageNode :
MessageNodeObj );
ASK METHOD ShowOrbit;
ASK METHOD HideOrbit;
OVERRIDE
ASK METHOD ObjInit ;
ASK METHOD ObjTerminate ;
ASK METHOD DynamicUpdate (IN CurrentTime, ElapsedTime :
REAL);
CLASS
Satellites
: SatelliteQObj ;
ASK METHOD NewSatellites ;
ASK METHOD SaveSatellites (IN file : StreamObj) ;
ASK METHOD LoadSatellites (IN file : StreamObj) ;
END OBJECT ;
VAR
AnimationSpeed : INTEGER ;
SimNumMsg
: INTEGER ;
END MODULE .
As caraterísticas e o comportamento dos satélites são definidos neste módulo.
O primeiro objeto, SatelliteQObj, visa permitir a inclusão de um cenário com
mais de um satélite. O início de simulação desses objetos é efetuado pelo
procedimento InitSim. O procedimento RandomStation permite a escolha
aleatória de um satélite entre os existentes na fila para que seja efetuada a
comunicação.
79
O objeto SatelliteObj é definido como um objeto dinâmico, o que o torna
passível de movimentação dentro do cenário. O método Simulate destina-se a
controlar o tempo simulado gasto nas operações realizadas pelo satélite. O
método ReceiveMessage possibilita o recebimento de uma mensagem enviada
pela PCD e o método SendMessage, destina-se a enviar uma mensagem para
uma estação terrestre. Os métodos ObjInit e ObjTerminate servem,
respectivamente, para criar e eliminar um satélite. O método SetOrbitData faz o
posicionamento inicial do satélite na orbita desejada. O seu posicionamento
durante a simulação é calculado por ASK METHOD ComputePosition, que por
sua vez passa a nova posição para o método DynamicUpdadte para atualizar a
movimentação do satélite em sua órbita. Os métodos ShowOrbit e HideOrbit,
por sua vez, exibem ou não a órbita percorrida pelo satélite.
A classe de objetos SatelliteQObj permite que novos satélites sejam incluídos
na fila, via a chamada do método NewSatellites e, também, possibilitam que os
satélites existentes sejam gravados em disco ou recuperados pelos métodos
SaveSatellites e LoadSatellites.
A variável AnimationSpeed controla a velocidade da animação dos objetos e a
SimNumMsg armazena o total de mensagens simuladas.
5.5 DERCD - MÓDULO DAS ESTAÇÕES DE RECEPÇÃO TERRESTRES
DEFINITION MODULE ERCD ;
FROM Image
IMPORT ImageObj ;
FROM GrpMod IMPORT QueueObj ;
FROM IOMod
IMPORT StreamObj ;
FROM MapWin IMPORT MessageNodeObj ;
TYPE
GroundStationQObj = OBJECT
(QueueObj[ANYOBJ:GroundStationObj]) ;
ASK METHOD RandomStation : GroundStationObj ;
END OBJECT ;
80
GroundStationObj = OBJECT (ImageObj) ;
MeanTimeBtwnMsg
: REAL ;
ASK METHOD SetMeanTimeBtwnMsg (IN time : REAL) ;
ASK METHOD ReceiveMessage (IN MessageNode :
MessageNodeObj );
OVERRIDE
ASK METHOD ObjInit ;
ASK METHOD ObjTerminate ;
ASK METHOD BeSelected ;
CLASS
GroundStations : GroundStationQObj ;
ASK METHOD NewGroundStations ;
ASK METHOD SaveGroundStations (IN file : StreamObj) ;
ASK METHOD LoadGroundStations (IN file : StreamObj) ;
END OBJECT ;
VAR
Messages : QueueObj;
filemsg
: StreamObj;
END MODULE .
O primeiro objeto, GroundStationQObj, descrito neste módulo, destina-se a
incorporar a fila de ERCDs criadas no cenário, e controla a escolha aleatória
de uma Plataforma de Recepção das existentes na fila, através do
procedimento RandomStation.
O objeto GroundStationObj descreve as características existentes nas ERCDs.
O procedimento SetMeanTimeBtwnMsg fornece o tempo médio entre as
mensagens. O método ReceiveMessage permite a recepção de uma
mensagem enviada pelo satélite, e os métodos ObjInit, ObjTerminate e
BeSelect, respectivamente, para criar, terminar e selecionar um determinado
objeto do tipo GroundStationObj. A classe de objetos do tipo fila,
GroundStationQObj, permite a inclusão de novas ERCDs via o procedimento
NewGroundStations e, também, possibilitam que as plataformas criadas sejam
salvas ou recuperadas de disco, via os métodos SaveGroundStations e
81
LoadGroundStations, respectivamente.
A variável messages, do tipo fila, destina-se a armazenar as mensagens
recebidas pela ERCD, e filemsg descreve o nome do arquivo no qual as
mensagens serão gravadas em disco.
5.6 DRESULT – MÓDULO DE APRESENTAÇÃO DE RESULTADOS
Este módulo será responsável pela apresentação e análise dos resultados
gerados durante a corrida de simulação. Ele deve ser capaz de emitir todos os
relatórios solicitados nos requisitos do simulador, entre eles: janela de
visibilidade por passagem do satélite por dia de uma determinada plataforma
em relação a uma determinada estação terrena; o número de mensagens
recebidas de cada PCD (por estação ou conjunto de estações, referentes a
uma passagem do satélite ou a um dia de operação do sistema), a distribuição
do número de mensagens geradas por uma PCD ou conjunto de PCDs que
foram recebidas em um intervalo de tempo ou em um dia de operação, seja
por uma determinada estação, ou pelo satélite ou pelo sistema como um todo.
Na versão atual do protótipo este módulo ainda não foi estudado em detalhes e
não foi objeto de qualquer tipo de implementação.
5.7 DHELPDLG - MÓDULO DE AJUDA
DEFINITION MODULE HelpDlg ;
FROM Form
IMPORT DialogBoxObj ;
FROM Window IMPORT WindowObj ;
TYPE
HelpDialogBoxObj = OBJECT (DialogBoxObj) ;
ASK METHOD DisplayFile (IN filename : STRING;
IN window : WindowObj) ;
OVERRIDE
82
ASK METHOD ObjInit ;
END OBJECT ;
END MODULE .
O objeto descrito neste módulo destina-se a auxiliar o usuário final a operar o
protótipo
do
simulador
através
de
consultas
“on
line”.
O
objeto
HelpDialogBoxObj é composto por dois processos destinados a inicializar e a
exibir um texto de ajuda, passado por parâmetro, em uma janela criada na
interface gráfica.
5.8 ESTÁGIOS DE DESENVOLVIMENTO DA PESQUISA E DO PROTÓTIPO
A pesquisa compreendeu uma fase inicial de estudo do problema, envolvendo
a determinação dos requisitos necessários para o desenvolvimento do
simulador, sua estruturação geral e a implementação de uma primeira versão
dos seus componentes básicos (Interface Gráfica com o usuário, PCDs,
ERCDs e Satélites), para servir como catalisador do esforço de implementação
nas etapas seguintes. Esta fase inicial foi concluída com um artigo (Kienbaum
et al., 1999) apresentado no Simpósio de Pesquisa Operacional e Logística da
Marinha, em 1999 (SPOLM99), que apresentou a proposta da pesquisa e
descreveu a primeira versão da interface gráfica interativa construída.
Uma segunda etapa da pesquisa consistiu em situar o problema dentro do
contexto maior que é o estudo completo de simulação a ser conduzido com o
sistema, em elaborar a documentação inicial do protótipo, e em detalhar a
questão da estrutura dos seus módulos componentes. A segunda etapa da
pesquisa também foi objeto de um trabalho para congresso (Travassos et al.,
2001), que está sendo submetido para apresentação no XVIII Congresso
Brasileiro de Pesquisa Operacional (SOBRAPO 2001).
No tocante ao desenvolvimento do protótipo, a segunda etapa se caracterizou
83
pela inclusão de diversas melhorias em aspectos da implementação inicial, e
foram acrescentadas novas funcionalidades na interface gráfica de interação
com o usuário, resultando na versão atual do simulador apresentada na Figura
5.1 e descrita a seguir.
Fig. 5.2 - Interface Gráfica Interativa do Simulador.
No modo de operação montagem de cenário, o protótipo atual do simulador
permite a construção de configurações da rede de plataformas de coleta de
dados
e
das
estações
terrenas
sobre
mapa
da
América
do
Sul
georeferenciado, onde a determinação das coordenadas de localização das
PCDs e estações terrenas é realizada de forma automática pelo sistema.
As configurações são criadas escolhendo-se objetos da paleta e posicionandoos na tela, após o que é feita a designação de valores a seus atributos, através
de caixas de diálogo apropriadas que são apresentadas na tela para cada tipo
84
de objeto que está sendo especificado. As configurações criadas podem ser
salvas em arquivos de dados e reutilizadas posteriormente na forma de
cenários pré-construídos.
Com relação à entrada de dados que serão utilizados na experimentação, os
atributos ativos das PCDs compreendem sua localização e seu intervalo de
geração entre mensagens. Os demais atributos estão sendo registrados para
posterior utilização.
O satélite tem como atributos ativos o registro das freqüências utilizadas em
sua operação (Bandas S e UHF), sua localização e velocidade em órbita,
sendo os demais atributos, como a potência de transmissão e retransmissão,
G/T e estabilidade do oscilador, também registrados para uso futuro.
Para as Estações de Recepção estão ativados nos objetos instanciados, a sua
localização, freqüência da portadora, número de canais de processamento
disponíveis e estado de operação. Os demais atributos, da mesma forma que
os casos similares de PCD e satélite, não são utilizados no presente modelo e
são registrados para futura implementação.
O modo projeto de experimentos ainda necessita ser detalhado, mas já é
possível se determinar a duração da corrida de simulação através do número
de mensagens geradas na execução, bem como se introduzir uma semente
para ser utilizada na geração dos números aleatórios, embora isto seja feito
atualmente na caixa de diálogo que dá início à simulação, devendo
posteriormente ser implementado na forma de um menu apropriado, contendo
todas as facilidades destinadas a este modo.
No modo simulação, o simulador permite a realização de corridas simples de
simulação, com a geração de mensagens, a atribuição de valores ao seu
conteúdo, e o registro de seus parâmetros básicos durante a corrida de
85
simulação, como instante de geração e conteúdo, para fins de monitoramento.
A simulação se baseia atualmente apenas no tráfego de mensagens entre
cada PCD, satélite e a ERCD. Todo o processo se inicia na PCD a partir da
geração e transmissão de mensagens que têm freqüência, tamanho e período
de transmissão estipulados para cada plataforma. O instante inicial de
transmissão é gerado de forma aleatória, em virtude de não ser possível
estipulá-lo para as plataformas instaladas. A potência da plataforma ainda está
sendo
registrada
apenas
para
efeito
de
documentação
e
futura
implementação. Os métodos implementados para os satélites possibilitam
receber e reenviar as mensagens, que são recebidas e registradas nas
estações de recepção para posterior análise e apresentação de resultados.
A animação inclui a fixação da velocidade de execução pelo usuário no início
da corrida, através da designação de um valor entre 0 e 9 ao parâmetro
velocidade, bem como a exibição ou ocultação da trajetória descrita pelos
satélites em sua projeção sobre o solo e a comunicação entre os nós da rede
na forma de linhas representativas do tráfego de mensagens.
Alguns aspectos da versão atual precisam, no entanto, ser melhorados ou
ainda estão pendentes como, por exemplo, a incorporação da órbita dos
satélites por meio do propagador de órbita, o tratamento da questão da
visibilidade das plataformas ao longo destas trajetórias e todas as facilidades
relacionadas com o módulo de análise e apresentação dos resultados.
O capítulo 6, a seguir, apresenta o próximo estágio de desenvolvimento na
forma de pesquisa futura a ser realizada com o sistema, cobrindo os aspectos
já identificados como ainda incompletos na versão atual, bem como projetando
a questão da adição de facilidades para a criação do projeto de experimentos,
da execução das corridas de simulação e da análise e apresentação dos
resultados
86
O desenvolvimento do sistema prosseguirá de acordo com o processo de
natureza incremental descrito, onde cada estágio de detalhamento do
problema será explorado através da construção de um estágio correspondente
de sua implementação.
87
CAPÍTULO 6
PESQUISA E DESENVOLVIMENTO FUTUROS
Este
capítulo
descreve
a
direção
a
ser
seguida
pela
pesquisa
e
desenvolvimento futuros do simulador e do estudo de simulação a ser
realizado com o mesmo. Os aspectos cobertos são bem amplos e vão desde a
melhoria de facilidades já existentes; a implementação de novas facilidades
identificadas como essenciais a partir dos requisitos; procedimentos para
verificação e validação do simulador; procedimentos para elaboração do
projeto de experimentos; e, por fim, propostas para a sua utilização para
análise da configuração, da operação e do desempenho do sistema.
6.1 APERFEIÇOAMENTO E NOVAS FACILIDADES NO SIMULADOR
6.1.1 MONTAGEM DE CENÁRIO
Deverão ser incorporados comandos adicionais, disponibilizados através de
menus, como alternativa ao processo de seleção/arrasto via “mouse”, para
inclusão e manutenção dos elementos componentes dos cenários.
Todos os parâmetros fornecidos, via interface de diálogo com o usuário,
necessários
a
execução da simulação sofrerão críticas na entrada,
minimizando os erros oriundos de digitação.
Pretende-se implementar acesso a banco de dados relacionais para permitir
consultas não estruturadas à base de dados de configuração, como também
às de projeto de experimentos e de resultados da simulação. Para isto será
necessário se obter a nova versão do MODSIM III que já disponibiliza, em sua
forma nativa, objetos apropriados para implementação de acesso completo a
banco de dados relacionais (GOBLE et al.,1998).
89
6.1.2 PROJETO DE EXPERIMENTO
A montagem dos projetos de experimento será objeto da criação de um menu
específico para conter todas as facilidades relacionadas com este modo de
operação, entre elas: a atribuição do valor de duração das corridas de
simulação, a seleção de sementes, e a determinação de instantes para
interrupção de corridas, destinadas à verificação das variáveis de estado e/ou
modificação destas para reinicialização da simulação.
O projeto de experimento deverá considerar ainda a questão da criação de
unidades experimentais que sejam formadas pela variação controlada dos
atributos de cada um ou de um grupo de elementos componentes do cenário,
constituídos por PCDs, Satélites e Estações. Com isto será possível alternar
situações em que um elemento ou grupo de elementos tem seus atributos
especificados com valores alto, médio ou baixo, e o efeito cruzado destas
variações possam ser estudados com base nos resultados gerados para cada
unidade experimental ensaiada.
6.1.3 SIMULAÇÃO
Serão incorporados no protótipo o posicionamento e a velocidade do satélite, a
partir do propagador de elementos orbitais do modelo NORAD SGP4 – para
satélites próximos da Terra. Para tanto a interface de entrada de dados dos
satélites deverá ser modificada para permitir que sejam recuperados o conjunto
de elementos “two-line” que identificam o satélite simulado.
Uma vez que se tenha obtido sucesso na inclusão da chamada da rotina de
propagação orbital pelo simulador, outros requisitos poderão ser rapidamente
incorporados, tais como: a determinação da distância (“range”), da velocidade
relativa (“range-rate”), range-rate-rate, azimute e elevação do satélite em
relação à PCD e à estação terrena; o processamento da região de visibilidade
90
do satélite durante sua passagem; a identificação das estações inoperantes e
sua exclusão da correspondente rodada de simulação; e as limitações de
comunicação devido ao número de canais disponíveis para processamento das
mensagens nas estações de recepção.
Outra característica importante, influenciada diretamente pela incorporação do
propagador de órbitas no simulador é o tratamento de colisões de mensagens.
Devido ao deslocamento do satélite no espaço, se aproximando ou se
afastando das PCDs, ocasiona um desvio na freqüência originalmente
transmitida,
quando
ela
for
recebida
pelo
satélite
(efeito
Doppler)
(Blitzkow,1975). A freqüência resultante pode então, se sobrepor a uma outra
mensagem recebida no mesmo instante, acarretando em uma colisão de
mensagens. Assim, este efeito poderá sofrer o tratamento adequado, quando
da execução do processo de recebimento da mensagem pelo satélite, durante
a simulação.
Um menu destinado a execução e ao controle da simulação deverá ser
disponibilizado, para ser usado depois que o modelo estiver pronto para ser
simulado. O menu deverá conter comandos para iniciar, terminar ou parar uma
rodada de simulação. A opção de parar deverá interromper a simulação
momentaneamente, quando poderão ser analisadas as variáveis de estado do
sistema.
A
opção
de
terminar
uma
simulação
deverá
interromper
definitivamente a rodada de simulação, no instante da execução do comando,
preservando as operações já concluídas.
Serão incluídos em menu específico, parâmetros para controle da velocidade
de animação, exibição ou não de resultados parciais e do relógio, antes e
durante a corrida de simulação
Algumas estatísticas básicas (mínimo, máximo, média, desvio padrão) poderão
ser apresentadas “on line” a partir do monitoramento de alguns objetos do
91
sistema, ou armazenadas para serem observadas depois que a simulação for
completada.
Deverá ser considerado ainda o tratamento de erros dos dados utilizados
durante as corridas de simulação, que sejam provenientes de desvios da
injeção nas órbitas dos satélites: ponto, velocidade e ângulo de injeção, bem
como de mal alinhamento das antenas devido a movimentos erráticos dos
satélites. (Souza, 1989)
6.1.4 ANÁLISE DOS RESULTADOS
Um menu de relatórios apresentará as várias opções de relatórios préformatados disponíveis no simulador. Os relatórios estarão armazenados na
forma de arquivos para permitir consultas a partir de um editor de texto ou sua
impressão.
Através de um menu de resultados gráficos, os dados gerados durante a
experimentação também poderão ser visualizados para a condução das
análises apropriadas.
6.1.5 FACILIDADES ADICIONAIS DA INTERFACE GRÁFICA
O menu de ajuda fornecerá a opção de auxílio “on line” das funcionalidades do
sistema de modo sensível ao contexto da chamada. Além disso, toda a
documentação do sistema será fornecida em arquivos para consulta imediato
pelo usuário.
6.2 VERIFICAÇÃO E VALIDAÇÃO DO PROTÓTIPO
Verificação é a certificação de que um programa de simulação implementa e
executa corretamente o modelo conceitual de simulação de um sistema real. A
92
simplicidade da formulação deste conceito esconde muitas vezes a enorme
dificuldade de se checar inteiramente um programa de simulação de larga
escala (Law e Kelton, 1992).
Validação está relacionada com a determinação se o modelo conceitual de
simulação do sistema representa corretamente o sistema real. Se um modelo é
válido, então as decisões tomadas com base neste deverão ser semelhantes
àquelas que seriam tomadas a partir da experimentação feita diretamente com
o sistema real, se isto fosse possível (Law e Kelton, 1992).
Um roteiro completo para a execução dos procedimentos relacionados com a
verificação e validação de modelos de simulação pode ser visto em (Kienbaum,
1989), que contém um “survey” da literatura publicada sobre o assunto. O
receituário pode ser descrito em 13 itens, agrupados sob a denominação de
Estágios de Aferição de Credibilidade (EACs), acompanhados de um
procedimento para aplicação destes critérios por um painel de especialistas,
que desta forma podem concluir sobre a confiabilidade do modelo,
classificando-o como aceitável ou não aceitável.
A equipe encarregada do simulador deve ter em mente, porém, que a prática
mostra que a validação de um simulador emprega apenas parte das técnicas
de validação apresentadas e que, adicionalmente, podem haver métodos mais
eficientes que podem ser desenvolvidos para a aplicação particular em
consideração (Law e Kelton, 1992).
6.3 PROJETO DE EXPERIMENTOS
O projeto de experimentos é a etapa do estudo de simulação em que se faz o
planejamento e a especificação dos parâmetros que serão acompanhados
durante as corridas de simulação, podendo ele ser ainda subdividido em três
atividades menores: a identificação dos fatores, a definição das unidades
93
experimentais e a seleção das variáveis de resposta.
Na identificação dos fatores precisam ser levadas em consideração uma série
de questões, que devem ser respondidas de acordo com o conhecimento de
especialistas sobre o sistema. Algumas das questões que estarão sendo
formuladas aos operadores do SBCD para a elaboração do projeto de
experimentos serão:
1) Que fatores são considerados relevantes para experimentação?
2) Quais são os modos alternativos de operação do sistema?
3) Que
modificações
nos
valores
dos
parâmetros
devem
ser
consideradas?
4) Que variações são possíveis na quantidade disponíveis de recursos
(PCDs, Satélites, Estações de Recepção)?
A definição das unidades experimentais significa a escolha de um conjunto
completo de fatores, que são os parâmetros a serem monitorados, associados
com os demais aspectos determinantes de uma corrida, tais como as
condições de início e término, a escolha da semente para os geradores das
variáveis aleatórias, o comprimento da corrida, o período de “aquecimento”,
que é o tempo durante o qual as estatísticas são desprezadas, e outros. Esta
atividade está mais afeita ao analista que desenvolveu o simulador e o
conhece em profundidade do que aos operadores do sistema.
A identificação dos fatores e o grupamento destes numa unidade experimental
pronta para a execução de uma corrida é feita no início desta etapa, através de
uma análise cuidadosa a partir de propostas de experimentos (“screening
experiments”) que podem ainda ser descartados.
94
Finalmente, a seleção das variáveis de resposta, se constitui também num
importante aspecto desta etapa, que terá conseqüências sobre as fases
seguintes do ciclo de vida, isto é, na execução da simulação, no tipo de análise
e apresentação dos resultados, e na qualidade do apoio à tomada de decisão.
Para a escolha das principais variáveis de saída a serem medidas pelo
modelador é preciso ter em mente que as variáveis de resposta são variáveis
aleatórias e as conclusões sobre elas vão requerer uma análise estatística
cuidadosa.
6.4 SIMULAÇÃO E ANÁLISE DE RESULTADOS
Finalmente, apresenta-se neste tópico algumas considerações sobre o uso do
simulador em sua forma final para a condução da análise do sistema SBCD
propriamente dita. São identificadas quatro situações de interesse, que
agrupam o monitoramento de diversos parâmetros de um dado tipo, a saber: a
análise de configuração; a análise de estratégias de operação; a análise do
desempenho do sistema; e a análise de sensibilidade a condições extremas de
operação do simulador.
Estes estudos só serão possíveis a partir da incorporação das facilidades
descritas no item 6.1 ao protótipo do simulador, de forma a dotá-lo de todos os
recursos necessários a um sistema completo de simulação, como é o caso do
COMNET III mostrado na Figura 2.5, com o qual se desenvolveu o primeiro
modelo do SBCD, conforme mencionado no item 2.6.
Os casos identificados a seguir tão pouco são considerados exaustivos,
podendo os operadores do SBCD identificarem novos estudos de interesse a
partir destas análises, e até proporem modificações no próprio modelo,
buscando dotá-lo de novas capacidades para outros tipos de análise não
previstas abaixo.
95
6.4.1 ANÁLISE DE CONFIGURAÇÃO
1) Modificação de configurações: testar cenários baseados em casos
reais de operação do sistema, prever situações de instalações de novas
PCDs, inclusive a questão da colocação destas de forma concentrada em
determinadas
regiões,
procurando-se
determinar
qual
a
melhor
configuração destas, evitando-se interferências oriundas da distribuição
da própria rede de PCDs.
6.4.2 ANÁLISE DE OPERAÇÃO
1) Modificação de Intervalos entre mensagens: variar os intervalos entre
mensagens para cada tipo de PCD para identificar se isto afeta aspectos
do desempenho do sistema, tais como número de colisões e conseqüente
perda de mensagens na recepção e eventuais efeitos cruzados
resultantes disto com as variações de freqüência ocasionadas pelo efeito
Doppler.
2) Potência dos sinais: verificar o efeito da variação de potência dos
sinais emitidos pelas PCDs e a relação desta com a questão do ganho
dos “transponders” no satélite e sua retransmissão com sucesso para as
estações terrenas.
3) Canais das estações de recepção: a quantidade de canais disponíveis
e a alocação destes a cada instante para cada uma das bandas afeta
diretamente a capacidade de processamento no recebimento das
mensagens.
4) Influência das trajetórias dos satélites e regiões de visibilidade:
dimensionar os períodos de visibilidade mútua das plataformas com as
96
estações de recepção terrena, durante a passagem do satélite, nas suas
diversas órbitas.
5) Tratamento de colisões e efeito Doppler: alterar a posição relativa de
PCD crítica (baixo número de mensagens transmitidas com sucesso
devido a colisões de mensagens em freqüência) para posições mais
favoráveis, visando aumentar a probabilidade de se transmitir mensagens
válidas.
6.4.3 ANÁLISE DE DESEMPENHO DO SISTEMA
1) Desempenho do sistema será avaliado com base em relatórios
gerados pelo simulador, que devem conter no mínimo o seguinte: tempo
de visibilidade por passagem do satélite por dia por PCD em relação a
uma determinada estação terrena; número de mensagens recebidas por
estação, referentes a uma passagem do satélite; número de mensagens
recebidas de cada PCD por estação, referentes a uma passagem do
satélite e sem repetição; a distribuição do número de mensagens geradas
por uma PCD que foram recebidas em um intervalo de tempo ou em um
dia de operação, seja por uma determinada estação ou por uma
determinada estação e um satélite.
2) Simulação de quebra de plataformas, estações e satélites: avaliar a
influência no desempenho do sistema, considerando a desativação de
PCDs, plataformas de recepção, e até mesmo de satélites, quando
houver mais de um.
6.4.4 ANÁLISE DE SENSIBILIDADE
1) Determinação de configurações limites e sensibilidade a parâmetros
extremos: identificar casos limites, nos quais o sistema apresenta
97
saturação de mensagens bem sucedidas para a configuração simulada
ou em que o simulador passa a se comportar de forma inválida.
98
CAPÍTULO 7
CONCLUSÕES
Este trabalho apresentou um estudo completo de simulação para a modelagem
e a simulação do Sistema Brasileiro de Coleta de Dados baseado em Satélites,
tendo como foco principal a análise do tráfego de mensagens na rede de
comunicação de dados constituída pelo sistema real.
O simulador visa determinar importantes parâmetros operacionais do sistema,
tais como configurações limites e o número máximo de PCDs que podem ser
utilizadas, permitir a avaliação do seu desempenho para uma dada
configuração, além de permitir analisar alternativas para sua atualização,
relacionados com diferentes configurações de PCDs (tipo, número, localização,
etc.), com as estações receptoras ERCDs (tipo, número, localização, etc.) e
com os satélites em utilização (número, órbitas, etc.).
O desenvolvimento do simulador foi feito baseado na metodologia de
orientação a objetos. Esta metodologia foi escolhida devido às características
do projeto e aos benefícios esperados pela adoção da mesma, que vão desde
a maior facilidade na concepção do modelo, com base em princípios modernos
de engenharia de software, bem como em sua modularização, extensibilidade
e reusabilidade.
Os benefícios esperados foram confirmados e além disto o uso da orientação a
objetos permitiu a adoção de um estilo incremental de programação e
possibilitou um rápido desenvolvimento do protótipo, mesmo levando-se em
consideração à complexidade conceitual do modelo em questão.
Apesar do objetivo geral do projeto de pesquisa ter sido formulado de forma
bastante ampla, a concentração dos esforços nas etapas de definição do
99
problema, de determinação de requisitos, de elaboração da análise e do
projeto, e da prototipação do simulador permitiu que o objetivo prático fosse
atingido com sucesso, o que é evidenciado pelo protótipo do simulador
implementado, em comparação com o nível de conhecimento e das técnicas
de abordagens disponíveis para o problema no início das atividades deste
trabalho.
Os objetivos de natureza teórica ou acadêmica propostos também foram
atingidos, tanto o de caráter geral, de apresentar o problema dentro de um
contexto maior que é o estudo de simulação a ser conduzido com o sistema,
quanto os de caráter específicos, relacionados com o uso de uma abordagem
de simulação discreta orientada a objetos para permitir a rápida prototipação
do simulador.
Como principal realização pode ser destacada a estruturação geral para os
módulos componentes do simulador, e a implementação de algumas de suas
principais funcionalidades, tendo sido atingido um estágio de desenvolvimento
bastante avançado, tanto em relação à sua interface gráfica de interação com
o usuário, quanto aos demais componentes do protótipo.
Os recursos ainda incompletos na versão atual do protótipo foram projetados
para implementação futura com base nos requisitos, e sua inclusão está
prevista para uma próxima etapa de desenvolvimento. A construção do sistema
deverá prosseguir, adotando-se uma estratégia de desenvolvimento do tipo
incremental,
buscando-se
retratar
cada
estágio
da
compreensão
e
detalhamento do modelo com um protótipo correspondente, até a conclusão
satisfatória de todos os requisitos de desenvolvimento estabelecidos para o
projeto.
Por fim, foram antecipados alguns problemas relacionados com o uso do
simulador, com base no conhecimento adquirido sobre o sistema SBCD e na
100
experiência com a utilização de sistemas de simulação de características
semelhantes, visando auxiliar a equipe de desenvolvedores e de usuários em
suas futuras tarefas de projeto de experimentos, execução da simulação e
análise dos resultados gerados pelo modelo.
Trabalhos posteriores podem ser elaborados para a apresentação do sistema
de simulação na sua forma final e para a apresentação dos resultados das
simulações realizadas com o mesmo.
101
REFERÊNCIAS BIBLIOGRÁFICAS
Agência Nacional de Energia Elétrica (ANEEL). Monitoramento hidrológico
diário. Disponível em:
<http://www.aneel.gov.br/sih/teleme/dados/relhidro.htm>. Acesso em: jun.
2001.
Analytical Graphics Inc. (AGI). Satellite Tool Kit. [online]. Disponível em:
<www.stk.com>. Acesso em: jun. 2001.
Balci, O. Guidelines for successful simulation studies. Blacksburg: Virginia
Tech. Department of Computer Science, Nov. 1985. (Technical Report TR85-2).
Blitzkow, D. Elementos que influem na precisão dos sistemas Doppler de
posicionamento. São José dos Campos: INPE, 1975. 29 p. (INPE-705RRE/017).
Braga, R. L. C. Sistema simulador de coleta de dados – SSCD. Proposta
técnica International Bussiness Machines/Instituto Nacional de Pesquisas
Espaciais. Rio de Janeiro: IBM-Brasil, 1995. 131 p.
Caci Products. Comnet III user’s manual: planning for network managers. La
Jolla: 1997a.
Caci Products. Modsim III - object oriented simulation: reference manual.
La Jolla: 1997b.
103
Elebra Sistemas de Defesa e Controles & Elebra Comunicação de Dados.
Desenvolvimento, instalação e treinamento do software simulador do
sistema de coleta de dados. Proposta técnica Elebra Sistemas de Defesa
e Controles & Elebra Comunicação de Dados/Instituto Nacional de
Pesquisas Espaciais. São Paulo: Elebra, 1995. 66 p.
Elmaghraby, S. E. The role of modeling in IE design. Industrial Engineering,
v. 19, n. 6, p. 292-305, Jun. 1968.
Escobal, P. R. Methods of orbit determination. New York: John Wiley, 1965.
479 p.
Goble, J. et al. Modsim III – A tutorial with advances in database access and
HLA support. [CD-ROM]. In: Winter Simulation Conference, Washington,
D.C., 1988. Proceedings. Washington, D.C., Dez. 1998.
Ha, T. T. Digital satellite communications. 2.ed. New York: McGraw-Hill,
1990. 574 p.
Iman Comercial e Engenharia de Sistemas. Simulador do sistema de coleta
de dados. Proposta técnica Iman Comercial e Engenharia de
Sistemas/Instituto Nacional de Pesquisas Espaciais. São Paulo: Iman,
1995. 48 p.
Instituto Nacional de Pesquisas Espaciais (INPE). Sistema de coleta de
dados dos satélites. Missão espacial completa brasileira: a missão.
Disponível em:
<http://www.inpe.br/programas/mecb/Port/satelites/scd2/misscd2.htm>.
Acesso em: ago. 2001a.
Instituto Nacional de Pesquisas Espaciais (INPE). Sistema de coleta de
dados de Cachoeira Paulista. Missão espacial completa brasileira:
104
serviços aos usuários de coleta de dados. Disponível em:
<http://www.inpe.br/programas/mecb/Port/satelites/scd1/pcd1.jpg>. Acesso
em: ago. 2001b.
Instituto Nacional de Pesquisas Espaciais (INPE). SCD-1 na sua órbita.
Centro de missão de coleta de dados: galeria de fotos. Disponível em:
<http://www.cmcd.inpe.br/imacmcd/orbview.jpg>. Acesso em: ago. 2001c
Instituto Nacional de Pesquisas Espaciais (INPE). Estação terrena de
Cuiabá. Missão espacial completa brasileira: galeria de fotos – solo.
Disponível em: <http://www.inpe.br/programas/mecb/Port/fotos/cuiaba2.jpg>.
Acesso em: ago. 2001d.
Instituto Nacional de Pesquisas Espaciais (INPE). PCDs meteorológicas.
Centro de missão de coleta de dados: produtos. Disponível em:
<http://www.cmcd.inpe.br/port/dados.html>. Acesso em: jun. 2001e.
Instituto Nacional de Pesquisas Espaciais (INPE). Data collection system
simulator requirements specification. São José dos Campos: INPE
MECB, 1995. 18 p. (A-DRS-2004).
Jacobson, I. et al. Object-oriented software engineering - A use case driven
approach. New York: Addison Wesley, l992. 524 p.
Jacobson, I. et al. The unified software development process. New York:
Addison Wesley, l998. 463 p.
Kelso, T. S. Orbit determination. Satellite Times, v. 1, n. 6, p. 80-81, JulyAug. 1995.
105
Kelso, T. S. Documentation for NORAD SGP4/SDP4 units. [online].
Disponível em: <www.celestrak.com/software/satellite/sgp4-plb26a.zip>.
Acesso em: Nov. 1999.
Kienbaum, G. S. Uma visão integrada sobre metodologia e ambiente para
modelagem e simulação assistidas por computador. São José dos
Campos. 218 p. Dissertação (Mestrado em Análise de Sistemas e
Aplicações) - Instituto Nacional de Pesquisas Espaciais, 1989.
Kienbaum, G. S. A Framework for Automatic Simulation Modeling Using
an Object-Oriented Approach. West London. 396 p. Tese (Doutorado em
Ciências da Computação) - Brunel University, 1995.
Kienbaum, G. S.; Paul, R. J. H-ACDNET: An object-oriented graphical user
interface for simulation modeling of manufacturing systems. Simulation
Practice and Theory, n. 2, p. 141-157, 1994.
Kienbaum, G. S., et al. Arquitetura para um simulador do sistema de coleta de
dados baseado em satélites da MECB. In: Simpósio de Pesquisa
Operacional da Marinha, 3.; Simpósio de Logística da Marinha, 4.,
(SPOLM’99), Rio de Janeiro, 1999. Resumo dos trabalhos. Rio de
janeiro: CASNAV, 1999. p 48-49.
Kuga, H. K. ; Rao, R. K. Introdução à mecânica celeste. São José dos
Campos: INPE, 1995. 74 p. (INPE-5615-PUD/064).
Law, A. M. ; Kelton, W.D. Simulations modeling & analysis. 2.ed. New York:
McGraw-Hill, 1992. 759 p.
106
Nance, R. E. Model representation in discrete event simulation: the conical
methodology. Blacksburg: Virginia Tech. Dept. of Computer Science, Mar.
1981. (Tech. Rep. CS81003-R).
Pidd, M. Computer simulation in management science. New York: John
Wiley & Sons, 1992. 351 p.
Pressman, R. S. Software engineering: a practitioner’s approach. New York:
McGraw-Hill, 1992. 793 p.
Roberts, C. A. et al. An overview of object-oriented simulation. Simulation, v.
70, n. 6, p. 359-367, June 1998.
Shannon, R. E. Systems simulation: art and science. Englewood Cliffs:
Prentice-Hall, 1975. 387 p.
Sousa, C. T. Geolocalização de transmissores com satélites usando
desvio doppler em tempo-quase-real. São José dos Campos. 175 p.
(INPE-8391-TDI/771). Tese (Doutorado em Engenharia e Tecnologia
Espaciais) - Instituto Nacional de Pesquisas Espaciais, 2000.
Souza, L. C. G. Rede experimental de plataforma de coleta de dados e
localização – descrição da rotina “ORBIT”. São José dos Campos: INPE,
fev. 1989. 29 p. (INPE-4798-NTE/287).
Travassos, P. R. N. et al. Um estudo de simulação do sistema brasileiro de
coleta de dados baseado em satélites. Submetido ao: XXXIII Simpósio
Brasileiro de Pesquisa Operacional. Campos do Jordão: nov. 2001.
Tude, E.A.P. et al. Análise do sistema de coleta de dados da MECB/SS.
São José dos Campos: INPE, 1986. 999 p. (INPE-3820-NTE/253).
107
Yamaguti, W, et al. Collection and treatment of the environment data with the
brazilian satellite SCD1. Revista Brasileira de Ciências Mecânicas, v. 16,
p 205-211, fev. 1994. Special Issue.
Yilmaz, L. A. Taxonomical review of object-oriented simulation model
verification and validation techniques. Blacksburg: Department of
Computer Science, Virginia Polytechnic Institute and State University, Mar.
1998. (Technical Report TR-98-6).
Yourdon, E. Object-oriented systems design: an integrated approach.
Englewood Cliffs: Prentice-Hall, 1994. 400 p.
108
APÊNDICE A
FORMATO DOS ELEMENTOS NORAD “TWO-LINE”
O conjunto de elementos NORAD “Two-line” consiste de três
linhas de dados para cada satélite no seguinte formato:
AAAAAAAAAAAAAAAAAAAAAAAA
1 NNNNNU NNNNNAAA NNNNN.NNNNNNNN +.NNNNNNNN +NNNNN-N+NNNNN-N N NNNNN
2 NNNNN NNN.NNNN NNN.NNNN NNNNNNN NNN.NNNN NNN.NNNN NN.NNNNNNNNNNNNNN
Linha 0 define o nome do satélite de até 24 caracteres. (linha opcional).
Linhas 1 e 2 contém os elementos orbitais no formato padrão “Two-Line”
idênticos aos que são usados pelo NORAD e NASA.
Descrição do formato:
Linha 1
Coluna
Descrição
01
Número da Linha
03-07
Número do Satélite
08
Classificação (U = Não Classificado)
10-11
Designador Internacional (dois últimos dígitos do ano do
lançamento)
12-14
Designador Internacional (número de lançamento no ano)
15-17
Designador Internacional (parte do lançamento)
19-20
Época do Ano (dois últimos dígitos do ano)
21-32
Época (dia do anos e parte fracionária do dia)
34-43
Primeira Derivada do Movimento Médio
45-52
Segunda Derivada do Movimento Médio (ponto decimal assumido)
109
54-61
Termo de arrasto BSTAR (ponto decimal assumido)
63
Tipo de Efemérides
65-68
Número do Elemento
69
Dígito Verificador (Módulo 10)
Linha 2
Coluna
Descrição
01
Número da Linha
03-07
Número do Satélite
09-16
Inclinação [graus]
18-25
Ascensão reta do nó ascendente [graus]
27-33
Excentricidade (ponto decimal assumido)
35-42
Argumento do Perigeu [graus]
44-51
Anomalia Média [graus]
53-63
Movimento Médio [revoluções. por dia]
64-68
Número de Revoluções na Época [Revoluções]
69
Dígito Verificador (Módulo 10)
Exemplo:
NOAA 14
1 23455U 94089A 97320.90946019 .00000140 00000-0 10191-3 0 2621
2 23455 99.0090 272.6745 0008546 223.1686 136.8816 14.11711747148495
110
APÊNDICE B
PROCESSOS DO CICLO DE VIDA DO MODELO
O Ciclo De Vida Do Modelo, descritos originalmente em Balci (1985), é
composto por dez processos indicados pelas setas tracejadas, conforme
mostrado na figura 2.1. A ordem de execução de cada processo é indicada
pelas setas, mas um erro identificado num determinado passo pode requerer
que se retorne a passos anteriores e se recomece todo o procedimento
novamente. Os processos são definidos de forma resumida a seguir.
B.1 FORMULAÇÃO DO PROBLEMA
Quando um problema é identificado, um decisor (patrocinador) inicia o seu
estudo comunicando-o ao analista. O problema que é comunicado raramente
se encontra claramente definido, especificado ou organizado. Assim, a
formulação, às vezes denominada de estruturação ou definição, do problema é
o processo pelo qual o problema inicialmente comunicado é transcrito num
problema formulado de maneira suficientemente clara e bem definida para
possibilitar a condução da pesquisa.
B.2 ESTUDO DAS TÉCNICAS DE SOLUÇÃO
Todas as técnicas alternativas que podem vir a ser utilizadas na solução do
problema precisam ser identificadas. A técnica que tiver custo elevado, ou que
for julgada insuficiente para atender os objetivos do estudo, deve ser
descartada. Entre aquelas que restarem deve ser escolhida a de maior
proporção benefícios/custos esperado com seu emprego.
Algumas vezes o problema comunicado é formulado sob a influência de uma
técnica de solução antecipadamente arbitrada. Ignorar simplesmente o
111
processo de investigação das técnicas de solução não é uma prática
aconselhável, podendo conduzir a soluções excessivamente caras, quando
não absolutamente erradas.
Com o resultado do processo de investigação, deve ser acionado o
responsável pelo gerenciamento do modelo, que será encarregado da
verificação do problema formulado e da verificação da factibilidade de se
aplicar a técnica escolhida na solução, antes de se prosseguir para o próximo
processo do ciclo de vida.
B.3 FORMULAÇÃO DO SISTEMA
As características do sistema que dizem respeito ao problema formulado
devem ser estudadas e consideradas na formulação do modelo e na sua
simulação. Seis são as características importantes que devem ser observadas
num sistema: (1) sua constituição e as modificações que ela sofre; (2) seu
meio ambiente; (3) seu comportamento não intuitivo; (4) sua performance nas
respostas
(particularmente
nos
extremos
do
espectro);
(5)
suas
interdependências; e (6) sua organização. (Shannon,1975)
B.4 FORMULAÇÃO DO MODELO
A formulação do modelo é o processo através do qual o modelo conceitual do
sistema é construído, O modelo conceitual é o modelo que existe na cabeça do
modelador. (Nance,1981)
A modelagem exige um criativo balanceamento de tendências opostas. Se por
um lado o modelo não pode excluir elementos essenciais do sistema, por outro
lado não se deve incluir detalhes desnecessários. A falta de um elemento
importante pode invalidar a representação do modelo. A inclusão de detalhes
desnecessários torna o modelo mais complexo. A fronteira do sistema é o ente
112
que separa os elementos que devem ser incluídos no modelo daqueles que
devem permanecer fora dele.
B.5 REPRESENTAÇÃO DO MODELO
É o processo pelo qual o modelo conceitual é transcrito num modelo
comunicativo. Um modelo comunicativo pode ser representado de diferentes
formas distintas. Para um mesmo sistema podem ser elaborados diversos tipos
de modelos comunicativos. Um deles pode ser em linguagem natural, para o
pessoal não técnico; um outro pode ser feito na forma de diagrama de blocos;
para a programação, etc.
B.6 PROGRAMAÇÃO
O processo de programação consiste na transcrição do modelo comunicativo
para o modelo programado Embora o modelo programado possa ser
construído utilizando-se de uma linguagem de programação de alto nível, como
o Fortran, Pascal ou C, geralmente é preferível se fazer uso de uma linguagem
de simulação. Esta linguagem reduz significativamente o tempo necessário
para a elaboração do modelo programado por colocar à disposição do usuário
as seguintes funções pré-programadas: (1) uma estratégia de abordagem (um
arcabouço conceitual, ou esqueleto, que serve de base para estruturação e
controle do programa representativo do modelo); (2) um mecanismo de
controle do tempo simulado; (3) um gerador de números aleatórios; (4) funções
de distribuições estocásticas para geração de variáveis aleatórias; (5)
mecanismos de análise estatísticas; e (6) diagnósticos para facilitar a
identificação dos erros de programação.
B.7 PROJETO DE EXPERIMENTOS
Este processo consiste em formular uma estratégia que possibilite a coleta da
113
informação desejada sobre o modelo para que o analista possa fazer
inferências válidas sobre ele incorrendo num custo mínimo (Shannon, 1975). O
modelo experimental é o modelo programado acrescido de uma descrição
executável das operações contidas na referida estratégia.
B.8 EXPERIMENTAÇÃO
É o processo de experimentar com o modelo com o propósito específico.
Alguns propósitos de experimentação são: (1) comparação de diferentes
políticas de operação do sistema; (2) avaliação do seu comportamento; (3)
análise de sensibilidade; (4) previsão; (5) otimização; e (6) determinação de
relações funcionais internas do sistema (Shannon, 1975).
B.9 REDEFINIÇÃO
A redefinição é um processo que consiste em (1) atualizar o modelo
experimental para que ele venha a representar a forma corrente do sistema; (2)
alterá-lo para obter um novo conjunto de resultados; (3) modificá-lo sob
qualquer outro aspecto visando sua manutenção; (4) modificá-lo para
reutilização em outro contexto; ou (5) redefinir um novo sistema a ser
modelado, visando uma solução alternativa do problema.
B.10 APRESENTAÇÃO DOS RESULTADOS DO MODELO
Este processo consiste na interpretação dos resultados do modelo e na
apresentação destes para os decisores, que se encarregarão de aceitá-los ou
não. Todos os modelos de simulação são descritivos, isto é, eles descrevem o
comportamento do sistema sem qualquer julgamento prévio do que é um “bom”
ou “mau” resultado (os modelos que fazem isto são chamados prescritivos). A
conclusão sobre a solução do problema fica, desta forma, inteiramente sob a
responsabilidade do analista, que é o responsável pela execução da análise e
114
interpretação dos resultados.
B.11 ESTÁGIOS DE AFERIÇÃO DE CREDIBILIDADE
“É preciso ter mente que ninguém resolve o problema, o que se resolve é um
modelo do problema real” (Elmaghraby, 1968). Um aspecto crucial de um
estudo de simulação é a aferição de credibilidade das diversas formas de
representação do modelo construído, que vão sendo criadas a cada passo do
ciclo de vida.
Uma vez que o modelo é uma abstração da realidade, não se pode falar de
sua precisão em termos absolutos. Por isto as medidas usadas, como a
credibilidade, a qualidade e a validade, são relativas aos resultados desejáveis
de serem obtidos, tendo em vista os objetivos do estudo. Em alguns casos, um
nível de credibilidade de apenas 60% nos resultados poderia ser satisfatório,
em outros poderia ser exigido uma credibilidade bem maior, por exemplo 90%.
115
APÊNDICE C
TABELA C.1 - RELAÇÃO DE PCDs FIXAS INSTALADAS
Estação
UF
Latitude
Longitude
Estação
UF
Latitude
Longitude
Abunã
Acima do Córrego
Grande
Açude Boqueirão Paraiba
Açude Boqueirão Parelhas
Açude Gavião
Água Clara
Água Vermelha
Águas do Verê
Alcantara
Alegrete
Altamira
Anagé
Anapólis
Apiúna
Aquidauana
Araçuaí
Aragarças
Araguaina
Aranjuez
Araripina
Arcoverde
Argoim
Aruanã
Arumã Jusante
Arumã Jusante
Atalaia
B Horizonte
Balsa de Santa
Maria
Balsa do Cerro Azul
Balsas HIDRO
Balsas MET
Bananal
Barão de Grajau
Barra do Batatal
Barra do Escuro
Barra do Garça
Barra do Pirai
Barra do Turvo
RO
MT
09°42'00''
16°40'00''
65°21'00''
55°09'00''
SC
27°10'00''
49°55'00''
PA
07°29'24''
36°08'11''
RN
06°41'00''
36°37'00''
CE
MS
SP
PR
MA
RS
PA
BA
GO
SC
MS
MG
MT
TO
BO
PE
PE
BA
GO
AM
AM
AL
PA
PR
06°15'00''
20°26'00''
19°51'00''
25°46'00''
02°24'00''
29°46'00''
03°12'00''
14°37'05''
16°22'45''
27°01'00''
20°29'00''
16°51'00''
15°54'03''
07°12'00''
16°33'18''
07°27'30''
08°26'01''
12°33'00''
14°49'00''
04°44'00''
04°44'00''
09°31'00''
05°23'00''
24°10'00''
38°54'00''
52°53'00''
50°21'00''
52°56'00''
44°24'00''
55°47'00''
52°13'00''
41°08'59''
48°56'44''
49°23'00''
55°47'00''
42°04'00''
52°14'44''
48°12'00''
68°05'29''
40°25'02''
37°03'19''
39°32'00''
51°10'00''
62°08'00''
62°08'00''
36°02'00''
52°53'00''
53°44'00''
BA 12°10'00''
SP 20°35'01''
GO 15°04'00''
MG 19°55'00''
RS 26°50'00''
MG 14°47'00''
RR -03°21'00''
BA 11°20'00''
SC 28°15'00''
AC 11°01'00''
AC 11°01'00''
GO 15°21'48''
BA 14°12'26''
SC 27°06'00''
PA 04°38'00''
MT 16°04'00''
SP 22°40'50''
SP 22°40'00''
45°20'00''
48°35'41''
48°59'00''
43°56'00''
49°03'00''
43°33'00''
59°49'00''
43°48'00''
49°11'00''
68°44'00''
68°44'00''
51°10'34''
41°46'41''
48°55'00''
56°18'00''
57°41'00''
45°00'09''
45°00'00''
PA
BA
GO
AL
SP
01°05'00''
13°57'41''
17°43'33''
10°01'00''
23°36'00''
57°02'00''
42°36'24''
48°36'54''
36°18'00''
48°30'00''
PR
MA
MA
SP
MA
SP
MG
MT
RJ
SP
24°47'00''
06°31'00''
08°36'00''
22°41'00''
06°46'00''
24°35'21''
16°16'00''
15°47'00''
22°28'00''
24°45'30''
49°16'00''
46°03'00''
45°46'00''
44°19'00''
43°01'00''
48°16'16''
45°12'00''
52°12'00''
43°50'00''
48°30'27''
Barragem OesteTaio
Barreiras
Barretos
Barro Alto
Belo Horizonte
Blumenau
Boca da Caatinga
Bonfim
Boqueirão
Braço do Norte
Brasiléia
Brasiléia
Britânia
Brumado
Brusque
Buburê
Cáceres
Cachoeira Paulista
Cachoeira Paulista
HIDRO
Cachoeira Porteira
Caitité
Caldas Novas
Camacari
Campina do M.
Alegre
Campo A. de Goias
Campo Bom
Campos do Jordão
Canal Pacajus
Canastra I
Capim Branco
Caquella
Caracarai
Caracarai
Caraguatatuba
Caratinga
Carauri
Careaçu
Barra dos Bugres
Barra Mansa
GO 17°40'00''
RS 29°41'00''
SP 22°45'01''
CE 04°13'57''
SC 16°19'00''
MG 18°45'00''
BO 21°29'49''
RR -01°48'00''
RR -01°48'00''
SP 23°40'00''
MG 19°47'00''
05°00'00''
MG 22°03'00''
MT 15°04'00''
22°28'00''
47°37'00''
51°02'00''
45°36'27''
38°23'14''
48°11'00''
48°16'00''
67°55'35''
61°08'00''
61°08'00''
45°26'00''
42°08'00''
67°00'00''
45°42'00''
57°11'00''
44°27'00''
Continua
117
TABELA C.1 - CONTINUAÇÃO
Estação
UF
Latitude
Longitude
Carolina
Caruaru
Cataguases
Catalão
Ceres
Chapadão do Céu
COGERH Acude
Gaviao
COGERH Jaguaribe
Colatina
Conceição do
Araguaia
Conceição do
Araguaia
Concisa
Concisa
Córrego do Nado
SUDECAP
Coxim
Crixás
Cruzeiro
Cruzeiro do Sul
Cruzeiro do Sul
Cruzeta
Cucui
Cuiabá
Cuiabá
Cunha
Descoberto Jusante
Dona Francisca
EB-0 Jaguaribe
Eirunepê
El Carmen
Eldorado
Ererê EB-1
Estrada GO-56
Estrada MT 738
Eunapólis
Farol de Itapua
Faz Panambi
Faz. Boa Fortuna
Fazenda Alegria
Fazenda Angical
Fazenda Corredeira
Fazenda Maringá
Fazenda Nanci
Fazenda Veneza
MA
PE
MG
GO
GO
GO
CE
07°20'00''
08°14'17''
21°23'00''
18°09'16''
15°20'52''
18°24'02''
03°54'15''
47°28'00''
35°54'57''
42°42'00''
47°55'46''
49°36'06''
52°40'22''
38°33'32''
CE
ES
PA
05°53'52''
19°32'00''
08°15'00''
38°37'59''
40°38'00''
49°16'00''
PA
08°17'00''
49°15'00''
MT
MT
MG
09°43'00''
09°43'00''
19°49'12''
60°35'00''
60°35'00''
43°57'13''
MS 18°26'00''
GO 14°31'58''
SP 22°34'53''
AC 07°37'00''
AC 07°37'00''
RN 06°25'00''
AM -01°11'00''
MT 15°37'00''
MT 15°35'00''
SP 23°04'01''
DF 16°03'00''
RS 29°37'00''
CE 04°40'28''
AM 06°41'00''
BO 15°53'28''
SP 24°31'00''
CE 04°09'49''
GO 21°06'00''
MS 20°44'00''
BA 16°17'26''
RS 30°05'00''
TO 08°05'64''
AL 09°29'00''
PA 05°30'00''
TO 12°17'00''
SP 21°19'00''
PA 03°16'00''
BA 15°35'00''
PI 05°35'00''
54°48'00''
49°56'01''
44°58'01''
72°40'00''
72°40'00''
36°47'00''
66°50'00''
56°05'00''
56°06'00''
44°57'01''
48°16'00''
53°21'00''
37°49'11''
69°54'00''
64°37'38''
48°07'00''
38°26'11''
48°05'00''
56°07'00''
39°34'47''
51°02'00''
46°39'12''
35°51'00''
48°18'00''
48°18'00''
47°29'00''
48°10'00''
39°31'00''
43°02'00''
Estação
Fazenda Vista
Alegre
Fernando de
Noronha
Ferros
Flores de Goias
Fluviópolis
Fontanilhas
Formosa Rio Preto
Formoso
Fortaleza
Foz do Cachoeira
Fragosos
Gavião
Goiana
Goiânia
Goiatuba
Governador
Valadares
Grajau II
Guaira
Guaratingueta
HIDRO Itajuba
Horizonte EB-2
Hotel Cataratas
Huatajata
Humaita
Iate Clube
Ibiaporã
Ibimirim
Ibirama
Iguatu
Ilha da Pintada
Ilhéus
Indaial
Ipanguaçu
Ipatinga
Ipirá
Ipiranga Novo
Ipiranga Novo
Ipojuca
Iporá
Iporanga
Iraí
Irecê
Itaberaí
Itaete
Itaicaba
UF
Latitude
Longitude
AM
04°54'00''
60°01'00''
PE
03°51'00''
32°25'00''
MG
GO
PR
MT
BA
SP
PA
SC
PR
AM
PE
GO
GO
MG
19°14'00''
14°30'47''
26°02'00''
11°25'00''
11°03'00''
22°39'00''
06°02'00''
25°38'00''
26°09'00''
04°50'00''
07°38'39''
16°35'52''
18°01'00''
18°52'00''
43°02'00''
47°00'24''
50°35'00''
58°39'00''
45°12'00''
44°31'00''
57°36'00''
51°58'00''
49°23'00''
66°45'00''
34°56'57''
49°16'39''
49°22'00''
41°56'00''
MA
PR
SP
MG
CE
PR
BO
AM
PR
BA
PE
SC
CE
RS
BA
SC
RN
MG
BA
AM
AM
PE
GO
SP
RS
BA
GO
BA
CE
05°48'00''
24°04'00''
22°48'00''
18°12'00''
04°08'25''
25°41'00''
16°12'26''
07°30'00''
25°36'00''
12°03'08''
08°32'17''
27°03'00''
06°22'00''
30°01'00''
14°45'23''
27°12'00''
05°25'36''
19°29'00''
12°09'42''
02°52'00''
02°52'00''
08°30'52''
16°25'31''
24°35'00''
27°10'00''
11°17'21''
16°01'45''
12°59'00''
04°39'28''
46°08'00''
54°15'00''
45°12'00''
45°15'00''
38°29'42''
54°26'00''
68°42'18''
63°01'00''
54°35'00''
40°48'32''
37°40'42''
49°31'00''
39°18'00''
51°15'00''
39°13'55''
49°50'00''
36°52'18''
42°31'00''
39°44'49''
69°40'00''
69°40'00''
35°00'21''
51°07'04''
48°35'00''
53°14'00''
41°53'39''
49°47'40''
40°57'00''
37°50'58''
Continua
118
TABELA C.1 - CONTINUAÇÃO
Estação
Itajubá MET
Itambé
Itirá
Itumbiara
Ituporanga
Ivinhema I
Jaguaquara
Jaguaribe
Jaguaruna Jus.
Jaíba
Januária
Jardim do Seridó
Jataí
Jequié
Jequitinhonha
Jiparaná
Ji-Paranã
Juazeiro
Jupiá Jusante
Juquiá
Jus. Nova
Anhandava
Jusante Peixoto
Juvenilia
Labréa
Ladário
Laranjal Paulista
Lavras
Leopoldina
Macaia
Machado
Manaus
Manoel Duarte
Manoel Viana
Marabá
Marcelino Ramos
Marcionílio Souza
Mário de Carvalho
MET Altamira
MET Cachoeira
Porteira
MET Cruzeiro do
Sul
MET Humaitá
MET Marabá
MET Pires do Rio
MET São Félix do
Araguaia
UF
Latitude
Longitude
Estação
MG
BA
MG
GO
SC
MS
BA
CE
MG
MG
MG
RN
GO
BA
MG
RO
RO
BA
MS
SP
SP
22°24'37''
15°15'00''
16°46'00''
18°24'34''
27°24'00''
22°23'00''
13°34'23''
05°54'00''
19°46'00''
15°37'00''
15°29'00''
06°31'00''
17°55'25''
13°52'23''
16°26'00''
10°53'00''
10°50'00''
09°25'00''
20°52'00''
24°19'00''
21°07'00''
45°26'58''
40°38'00''
42°02'00''
49°11'30''
49°36'00''
53°32'00''
39°56'27''
38°38'00''
44°48'00''
43°36'00''
44°21'00''
36°56'00''
51°43'03''
40°04'19''
40°59'00''
61°57'00''
61°55'00''
40°38'00''
51°38'00''
47°38'00''
50°15'00''
MT 09°38'00''
MG 14°16'00''
AM 07°15'00''
MS 19°02'00''
SP 22°57'00''
MG 21°15'00''
MG 21°32'00''
MG 21°09'00''
MG 21°42'01''
AM 03°08'00''
RJ 22°05'00''
RS 29°36'00''
PA 05°21'00''
RS 27°28'00''
BA 13°08'29''
MG 19°32'00''
PA 03°12'00''
PA 01°05'00''
56°15'00''
44°11'00''
64°48'00''
57°33'00''
47°49'00''
45°00'00''
42°38'00''
44°56'00''
45°53'27''
60°00'00''
43°33'00''
55°29'00''
49°09'00''
51°54'00''
41°31'51''
42°38'00''
52°12'00''
57°02'00''
AC
07°36'00''
72°46'00''
AM
PA
GO
MT
07°30'00''
05°20'00''
17°18'00''
11°37'00''
63°01'00''
49°07'00''
48°16'00''
50°41'00''
Milagres
Miracatú
Miraflores
Missão Surucucu
Mocidade
Monteiro Lobato
Montes Claros
Montes Claros de
Goiás
Morpara
Mossoró
Moura
Muçum
Natal
Nossa Senhora
Amparo
Obidos
Oiapoque
Orleans Montante
Palmeiras de Goiás
Paracatu
Paraibuna
Paranã
Passo Mariano Pinto
Passo Montenegro
Passo Santa Maria
Passo Socorro
Patos de Minas
Pedra do Ó
Pedra Selada
Pedras Negras
Pedras Negras
Pedro Afonso
Perimetral Norte
Petrolina
Piatã
Pindamonhangaba
Pindaré Mirim
Pipiripau Montante
Piracicaba
Pirapama
Pirapora
Pirapora -Barreiro
Pires do Rio
Ponte Mística
Ponte Nova
Ponte Rio Branco
UF
Latitude
Longitude
BA 12°54'41''
SP 24°16'48''
BO 11°06'26''
RR -02°47'00''
RR -03°27'00''
SP 22°58'00''
MG 16°44'00''
GO 16°00'39''
39°44'45''
47°27'34''
66°24'36''
63°48'00''
60°55'00''
45°50'00''
43°52'00''
51°24'24''
BA
RN
AM
RS
RN
RJ
12°11'00''
05°11'00''
01°30'00''
29°10'00''
05°48'00''
22°22'00''
43°13'00''
37°20'00''
61°40'00''
51°52'00''
35°12'00''
44°07'00''
PA 01°54'00''
AP -03°48'00''
SC 28°21'00''
GO 16°48'34''
MG 17°13'00''
SP 23°24'00''
TO 12°33'00''
RS 29°19'00''
RS 29°42'00''
RS 28°35'00''
RS 28°12'00''
MG 18°36'00''
PA 04°34'00''
RJ 22°18'00''
RO 12°50'00''
RO 12°50'00''
TO 08°58'00''
PA -00°39'00''
PE 09°09'00''
BA 13°09'51''
SP 22°55'00''
MA 03°34'00''
DF 15°39'00''
SP 22°43'00''
PE 08°14'00''
MG 17°20'00''
MG 17°22'00''
GO 17°20'00''
RS 28°11'00''
MG 20°23'00''
BA 12°17'00''
55°30'00''
51°51'00''
49°17'00''
49°56'06''
46°52'00''
45°38'00''
47°51'00''
56°03'00''
51°26'00''
54°55'00''
50°45'00''
46°32'00''
54°03'00''
44°09'00''
62°56'00''
62°56'00''
48°10'00''
56°52'00''
40°22'00''
41°46'15''
45°28'00''
45°24'00''
47°35'00''
47°39'00''
35°15'00''
44°56'00''
44°57'00''
48°15'00''
54°44'00''
42°54'00''
39°00'00''
Continua
119
TABELA C.1 - CONTINUAÇÃO
Estação
UF
Latitude
Longitude
Estação
UF
Latitude
Longitude
Ponte Sul Goiania
Porangatu
Porto Amazonas
Porto Capanema
Porto Cercado
Porto Conceição
Porto do Cavalo
Porto dos Buenos
Porto dos Gauchos
Porto Esperança
Porto Ferreira
Porto Jau
Porto Jofre
Porto Murtinho
Porto Nacional
Porto Nacional
Porto Paraiso do
Norte
Porto São José
Porto Velho
Porto Vitória
Posse
Prainha Velha
Prainha Velha
Propriá
Queluz
Quirinópolis
Recife
Registro
Ribeira
Ribeirão Preto
Rio Bonito
Rio Branco
Rio do Sul Novo
Rio Grande Regatas
Rio Negro
Rio Novo
Rio Pardo
Rio Verde
Rosário do Oeste
Rosário do Sul
Rurrenabaque
S Félix do Xingu
S Gabriel da
Cachoeira
S Martinho da Serra
S10 - S. Gabriel
Cachoeira
GO
GO
PR
PR
MT
MT
MG
MG
MT
MS
SP
SP
MT
MS
TO
TO
PR
18°07'00''
13°18'33''
25°33'00''
25°34'00''
16°26'00''
17°09'00''
17°01'00''
21°36'00''
11°32'00''
19°37'00''
21°51'00''
22°54'00''
17°20'00''
21°42'00''
10°43'00''
10°42'00''
23°19'00''
50°09'00''
49°07'03''
49°53'00''
53°56'00''
56°20'00''
57°23'00''
45°30'00''
45°30'00''
57°25'00''
57°27'00''
47°30'00''
50°02'00''
56°47'00''
57°52'00''
48°25'00''
48°26'00''
52°40'00''
SC
PR
BA
SP
PR
PI
GO
RR
SP
RJ
BA
AM
PE
MT
27°18'00''
25°32'00''
12°55'53''
23°22'00''
25°38'00''
09°15'00''
17°51'22''
00°26'00''
22°41'00''
21°32'00''
14°16'00''
03°06'00''
08°31'40''
11°36'00''
49°20'00''
53°02'00''
38°21'39''
45°54'00''
51°58'00''
45°39'00''
50°33'53''
61°46'00''
44°10'00''
42°11'00''
41°18'00''
67°56'00''
36°27'35''
50°40'00''
PR
RO
PR
GO
AM
AM
SE
SP
GO
PE
SP
SP
SP
SC
AC
SC
RS
PR
MG
RS
GO
MT
RS
BO
PA
AM
22°43'00''
08°46'00''
25°32'00''
14°04'57''
07°15'00''
07°15'00''
10°13'00''
22°32'43''
18°26'05''
08°03'52''
24°29'28''
24°39'23''
21°11'00''
27°11'00''
09°58'00''
27°11'00''
30°01'00''
26°06'00''
21°29'00''
29°59'00''
17°47'07''
14°55'00''
30°15'00''
14°26'25''
06°38'00''
00°08'00''
53°10'00''
63°55'00''
53°02'00''
46°21'48''
60°24'00''
60°24'00''
36°50'00''
44°46'24''
50°24'49''
34°55'29''
47°50'11''
49°00'28''
47°48'00''
49°59'00''
67°40'00''
49°37'00''
52°04'00''
49°48'00''
43°08'00''
52°22'00''
50°57'53''
56°23'00''
54°54'00''
67°32'01''
51°59'00''
67°05'00''
RJ
MS
AP
AM
21°39'00''
18°23'00''
00°41'00''
00°08'00''
41°45'00''
57°21'00''
52°53'00''
67°05'00''
AM
00°08'00''
67°04'00''
MT
RS
SP
17°10'00''
29°57'00''
22°38'43''
55°59'00''
51°43'00''
44°35'03''
SC
AM
AM
MG
MG
28°10'00''
03°28'00''
03°28'00''
16°22'00''
19°28'00''
48°58'00''
68°45'00''
68°45'00''
45°04'00''
41°11'00''
GO 19°05'00''
AM 09°02'00''
AM 09°02'00''
AP -00°53'00''
PE 07°55'49''
BA 11°38'54''
SP 24°23'27''
SP 22°48'22''
BA 12°05'49''
BA 13°24'00''
50°32'00''
68°34'00''
68°34'00''
52°00'00''
38°17'19''
38°58'58''
47°55'52''
44°50'34''
41°38'46''
44°15'00''
RS
AM
29°15'50''
00°08'00''
53°29'31''
67°05'00''
Salseiro
Salto Osorio
Salvador
Santa Branca
Santa Clara
Santa Filomena
Santa Helena
Santa Maria Boiaçu
Santana Bonsucesso
Santo A. de Pádua
Santo Antônio
Santo António Içá
São Bento do Una
São Félix do
Araguaia
São Fidélis
São Francisco
São Francisco I
São Gabriel da
Cachoeira
São Gabriel da
Cachoeira
Sao Jerônimo
Sao Jerônimo
São José do
Barreiro
São Martinho
São Paulo Olivença
São Paulo Olivença
São Romão
Sao Sebastiao da
Encruzilhada
São Simão
Seringal Caridade
Seringal Caridade
Serra do Navio
Serra Tallhada
Serrinha
Sete Barras
Silveiras
Souto Soares
Sta. Maria da
Vitória
Sucunduri
Tabatinga
Taguatinga
Taió
Tapuruquara
AM
AM
TO
SC
AM
59°02'00''
69°57'00''
46°26'00''
49°59'00''
65°02'00''
06°47'00''
04°15'00''
12°24'00''
27°07'00''
00°24'00''
Continua
120
TABELA C.1 - CONCLUSÃO
Estação
Tapuruquara
Taraqua
Taraquá
Tefé
Tefé
Teixeira de Freitas
Tibagi
Timbó
Trecho Médio
Tubarão
Uba do Sul
Ubaitaba
Uberaba
Ulianópolis
União da Vitória
Uruguaiana
Usina Luis Dias
Vianópolis
Vicentinópolis
Viçosa
Vila Bela Sant
Trindade
Vila Bitencourt
Vila Bittencourt
Vila Bittencourt
Vila do Apiaú
Vila Matias
Vilhena
Villa Tunari
Vitória da
Conquista
Vitória de Santo
Antão
Votupoca
Xambioá
Xingó
UF
Latitude
Longitude
AM 00°24'00''
AM -00°04'00''
AM -00°04'00''
AM 03°22'00''
AM 03°22'00''
BA 17°34'32''
PR 24°30'00''
SC 26°49'00''
MT 13°29'00''
SC 28°29'00''
PR 24°03'00''
BA 14°19'00''
MG 19°42'57''
PA 03°51'02''
PR 26°14'00''
RS 29°45'00''
MG 22°22'00''
GO 16°48'00''
GO 17°42'45''
MG 20°46'00''
RO 15°01'00''
65°02'00''
68°14'00''
68°14'00''
64°22'00''
64°22'00''
39°43'58''
50°24'00''
49°16'00''
51°27'00''
49°01'00''
51°37'00''
39°19'00''
47°57'05''
47°30'07''
51°04'00''
57°05'00''
45°19'00''
48°29'58''
49°47'50''
42°52'00''
59°57'00''
AM 01°24'00''
AM 01°24'00''
AM 01°24'00''
RR -02°33'08''
MG 18°35'00''
RO 12°17'00''
BO 16°58'27''
BA 14°53'10''
69°25'00''
69°25'00''
69°25'00''
61°18'24''
41°56'00''
60°05'00''
63°28'00''
40°48'03''
PE
08°07'42''
35°18'10''
SP
TO
AL
24°27'43''
06°23'00''
04°39'00''
47°58'56''
48°33'00''
38°04'00''
121