Adaptação de Veículos Autónom os e Inteligentes e Análise ...€¦ · 4.1.1 Extensão da linguagem SDL ... 6 – Conclusões e Trabalho Futuro ... C# Linguagem de programação

FACULDADE DE

Adaptação de Veículos AutónomInteligentes e Análise de D

Abel Fernando Neto Moreira dos Santos

Mestrado Integrado em Engenharia Informática

Orientador: Luís Paulo Gonçalves dos Reis (Professor Auxiliar, FEUP)

Co-Orientador: Daniel Augusto Gama de Castro Silva

ACULDADE DE ENGENHARIA DA UNIVERSIDADE DO

Adaptação de Veículos AutónomInteligentes e Análise de Desempenho no

Flight Simulator X


Mestrado Integrado em Engenharia Informática e Computação

Luís Paulo Gonçalves dos Reis (Professor Auxiliar, FEUP)

Orientador: Daniel Augusto Gama de Castro Silva

Junho de 2010

NIVERSIDADE DO PORTO

Adaptação de Veículos Autónomos e esempenho no


e Computação

Luís Paulo Gonçalves dos Reis (Professor Auxiliar, FEUP)

Orientador: Daniel Augusto Gama de Castro Silva

© Abel Fernando Neto Moreira dos Santos, 2010

Adaptação de Veículos Autónomos e Inteligentes e Análise de desempenho no Flight Simulator X


Mestrado Integrado em Engenharia Informática e Computação

Aprovado em provas públicas pelo Júri:

Presidente: Rosaldo José Fernandes Rossetti (Professor Auxiliar Convidado, FEUP)

Vogal Externo: Artur José Carneiro Pereira (Professor Auxiliar, UA)

Orientador: Luís Paulo Gonçalves dos Reis (Professor Auxiliar, FEUP)

____________________________________________________

30 de Junho de 2010

i

Resumo

O Homem, cada vez mais, apercebe-se da importância de colocar máquinas remotamente operadas a efectuar trabalhos perigosos, a desenvolver soluções para melhorar a sua qualidade de vida e a sua produtividade, chegando mesmo a utilizar ambientes simulados para testar novas tecnologias, novas metodologias.

Este projecto surge no âmbito de um projecto de maior dimensão, centrado no estudo da coordenação de agentes em missões de vigilância, procura e salvamento e, como tal, necessita de um ambiente simulado para as realizar, para as testar.

Assim, primeiramente, utilizando o simulador Flight Simulator X como base de trabalho, são adaptados novos veículos, terrestres, marítimos e submergíveis ao mesmo, garantindo que estes novos veículos tenham um comportamento tal como os veículos a que se predispõem a simular e, dessa forma, que possam efectuar missões conjuntas de veículos heterogéneos na plataforma de simulação.

Numa segunda fase, com os novos veículos criados, são efectuadas missões compostas por grupos de veículos autónomos aéreos, terrestres, marítimos e submergíveis. Todos os comportamentos dos veículos e acções efectuadas são registadas em ficheiros (uma telemetria dos veículos) que por sua vez são analisados, consoante as missões que os veículos estão a executar, e assim elabora-se uma análise de desempenho sobre a mesma, permitindo dessa forma tentar perceber quais os algoritmos de controlo de veículos que possuem melhor desempenho para determinada tarefa. Esta análise de desempenho, permite também tirar ensinamentos para se melhorarem os algoritmos de controlo de veículos autónomos.

Este documento, faz um estudo do que está feito nas áreas necessárias para atingir os objectivos acima mencionados e apresenta soluções funcionais para os problemas em análise.

ii

Abstract

Man is increasingly realizing the importance of placing remotely operated machines to

perform dangerous work, to develop solutions to improve quality of life and productivity, such that it has to consider the use of simulated environments to test new technologies and methodologies.

This project comes as a part of a larger project focused on studying the coordination of agents in surveillance, search and rescue missions, and thus it requires a simulated environment to carry out and test such missions.

On a first stage, Flight Simulator X is used as a base, with new and adapted land, sea and submersible types of vehicles, ensuring that these behave just like the vehicles they are simulating, thus being able to perform joint missions with heterogeneous vehicles in the simulation platform.

On a second step, the newly created vehicles are used to undertake missions composed by groups of autonomous vehicles by air, land, sea and submersible. All the behaviors of these vehicles, as well as actions taken, are registered on files (a telemetry of the vehicles), which are then analyzed, depending on what missions they are undertaking, and a performance analysis is prepared, allowing to understand which vehicle control algorithms perform better for such a task. This performance analysis also allows drawing lessons to improve autonomous vehicles control algorithms.

This paper presents a study of what is already done in the areas needed to achieve the objectives mentioned earlier and provides solutions to the problems analyzed.

iii

Agradecimentos

Gostava de agradecer aos orientadores do projecto, orientador Luís Paulo Gonçalves dos

Reis e co-orientador Daniel Augusto Gama de Castro Silva, este último de uma forma especial por ser o mentor do projecto global em que este trabalho assenta e pelas longas reuniões e debates muito construtivos que tivemos ao longo do projecto assim como a disponibilidade demonstrada para me aconselhar nas diversas situações que ocorreram durante o mesmo.

Um muito obrigado!


iv

Índice

1 - Introdução ............................................................................................................................... 1

1.1 Contexto e Motivação ......................................................................................................... 1 1.2 Objectivos ........................................................................................................................... 2

1.3 Estrutura da Dissertação ..................................................................................................... 2

2 - Revisão Bibliográfica .............................................................................................................. 4

2.1 Adaptação de veículos ........................................................................................................ 4 2.1.1 Agentes ....................................................................................................................... 4

2.1.2 Simuladores de veículos terrestres e marítimos .......................................................... 6 2.2 Análise de desempenho ..................................................................................................... 10 2.3 Trabalho prévio ................................................................................................................. 11

2.3 Resumo ............................................................................................................................. 13

3 – Integração no Projecto Global ............................................................................................ 14 3.1 Arquitectura ...................................................................................................................... 14

3.2 Adaptação de veículos ...................................................................................................... 15 3.2.1 SDL ........................................................................................................................... 17

3.2.2 TDL ........................................................................................................................... 21

3.3 Análise de desempenho dos agentes ................................................................................. 23 3.4 Aplicações Desenvolvidas ................................................................................................ 24

3.4.1 Painel de Controlo .................................................................................................... 24 3.4.2 Ferramenta de Controlo do Agente ........................................................................... 25

3.5 Resumo ............................................................................................................................. 27

4 – Adaptação de Novos Veículos ............................................................................................. 28 4.1 Configuração do cenário ................................................................................................... 28

4.1.1 Extensão da linguagem SDL ..................................................................................... 28 4.1.2 Aplicação de configuração do cenário ...................................................................... 39

4.2 Configuração de equipas ................................................................................................... 48 4.2.1 Definição da linguagem TDL ................................................................................... 48 4.2.2 Aplicação de configuração de equipas ...................................................................... 51

4.3 Integração com o FSX ...................................................................................................... 53 4.3.1 Controlo de veículos ................................................................................................. 54 4.3.2 Veículos Submergíveis ............................................................................................. 55 4.3.3 Características de Navegação Submersa ................................................................... 56

4.4 Resumo ............................................................................................................................. 61

5 – Análise de Desempenho ....................................................................................................... 62 5.1 Missão ............................................................................................................................... 62

v

5.2 Métricas............................................................................................................................. 63

5.3 Perfil .................................................................................................................................. 64

5.4 Aplicação .......................................................................................................................... 65

5.6 Resumo ............................................................................................................................. 68

6 – Conclusões e Trabalho Futuro ............................................................................................ 69 6.1 Satisfação dos Objectivos ................................................................................................. 69 6.2 Trabalho Futuro ................................................................................................................ 70

Referências .................................................................................................................................. 72

Anexo A: Exemplo de uma SDL ............................................................................................... 75

Anexo B: Exemplo de uma TDL ............................................................................................. 100

vi

Lista de Figuras

Figura 1 – Ambiente do simulador 3D Driving School ........................................................ 7 Figura 2 - Imagens do simulador naval Ship Simulator 2008 ............................................... 7

Figura 3 - Um dos veículos participantes no Darpa Grand Challenge de 2007 .................... 8

Figura 4 – Submarino Robótico .......................................................................................... 10 Figura 5 – Flight Simulator X ............................................................................................. 12 Figura 6 – Simulador X-Plane ............................................................................................ 12 Figura 7 – Simulador Flight Gear ....................................................................................... 13 Figura 8 – Simulador 2D Piccolo........................................................................................ 13 Figura 9 – Arquitectura do projecto, adaptada de [44] ....................................................... 15 Figura 10 – Representação dos novos tipos de veículos a incluir no simulador ................. 16

Figura 11 – Plano de desenvolvimento da adaptação dos novos tipos de veículos ............ 16

Figura 12 – Definição do elemento Scenario ...................................................................... 17 Figura 13 – Definição do elemento de bases de operações ................................................. 18 Figura 14 – Definição do elemento aeroporto .................................................................... 19 Figura 15 – Definição do elemento de Controladores ........................................................ 20 Figura 16 – Definição do elemento de Áreas de não Circulação ........................................ 20

Figura 17 – Definição do elemento de Tipo de Agentes ..................................................... 21 Figura 18 – Definição do elemento de Equipa .................................................................... 22 Figura 19 – Definição do elemento Agente, pertencente à equipa ..................................... 22

Figura 20 – Fluxo de informação gerado durante uma simulação ...................................... 23

Figura 21 – Plano de desenvolvimento da Análise de Desempenho .................................. 24

Figura 22 – Interface da aplicação de configuração do Cenário ......................................... 25

Figura 23 – Interface da aplicação de configuração das Equipas ....................................... 26

Figura 24 – Interface da aplicação de Controlo de Agente. Configuração de manobras .... 26

Figura 25 – Definição do elemento de base de operações estendida para os novos tipos de veículos ....................................................................................................................................... 29

Figura 26 – Definição do elemento Porto ........................................................................... 30 Figura 27 – Exemplo das estruturas referenciadas num Porto ............................................ 30

Figura 28 – Definição do elemento Via de Navegação ...................................................... 31 Figura 29 – Definição do elemento Cais ............................................................................. 31 Figura 30 – Definição do elemento Berths ......................................................................... 31 Figura 31 – Definição de Espaço de Atracagem ................................................................. 32 Figura 32 – Definição do elemento de uma rampa de acesso ............................................. 32

Figura 33 – Definição do elemento Doca Seca ................................................................... 33 Figura 34 - Definição do elemento de Base Terrestre ........................................................ 34 Figura 35 – Definição do elemento Estrada ........................................................................ 35 Figura 36 – Definição do elemento Parque de Estacionamento ......................................... 35

Figura 37 – Visualização das propriedades do elemento de Tipos de Agente .................... 35

vii

Figura 38 – Definição do elemento de Características Físicas dos Veículos. ..................... 37

Figura 39 – Definição do elemento de Características de Performance dos Veículos ........ 38

Figura 40 – Interface de Configuração do Porto ................................................................. 41 Figura 41 – Interface de configuração de uma Via de Navegação ..................................... 41

Figura 42 – Interface de configuração de Espaços de Atracagem ...................................... 42

Figura 43 – Interface de configuração de Cais ................................................................... 42 Figura 44 – Interface de configuração de uma Doca Seca .................................................. 43 Figura 45 – Interface de configuração de uma Rampa de Acesso ...................................... 43

Figura 46 – Interface de configuração de uma Base Terrestre............................................ 44

Figura 47 – Interface de configuração de Estradas ............................................................. 45 Figura 48 – Interface de configuração de um veículo marítimo ......................................... 46

Figura 49 – Interface de configuração de Veículo Submergível......................................... 47

Figura 50 – Interface de configuração de um Veículo Terrestre ........................................ 47

Figura 51 – Extensão da definição do elemento de Estado para suportar novos veículos .. 50

Figura 52 – Extensão do elemento de veículo real simulado de forma a suportar novos tipos de veículos .......................................................................................................................... 50

Figura 53 – Interface de configuração do estado de um Veículo Marítimo ........................ 51

Figura 54 - Interface de configuração do estado de um Veículo Submergível ................... 52

Figura 55 – Interface de configuração do estado de um Veículo Terrestre ........................ 52

Figura 56 – Interfaces de comunicação com o simulador ................................................... 53 Figura 57 - Processo de configuração de veículos no FSX. ................................................ 54 Figura 58 - Rota a efectuar pelo veículo. O círculo é o ponto de referência de chegada .... 55

Figura 59 - Processo de controlo de um submarino. ........................................................... 56 Figura 60 - Componente horizontal e vertical da velocidade do veículo. ........................... 57

Figura 61 - À esquerda, exemplo de uma manobra de um submarino e respectivos pontos de referência. À direita, exemplo da variação da altitude do submarino entre o local de partida e o ponto de referência seguinte..................................................................................................... 57

Figura 62 - Demonstração dos pontos de referência e raio de acção considerado como ponto de referência pelo FSX ...................................................................................................... 58

Figura 63 - Gráfico de cálculo da altura do veículo na posição em que se encontra pelo segundo método de resolução ..................................................................................................... 58

Figura 64 - Possibilidade do veículo ainda se encontrar a caminho do ponto de referência 1 (wp1) mas devido a ter entrado no raio de acção wp1, o simulador considera que o veículo já se encontra a caminho de wp2 ......................................................................................................... 59

Figura 65 – Vista de topo do percurso efectuado por um submarino ................................. 60

Figura 66 – Vista em perspectiva do percurso efectuado pelo submarino .......................... 60

Figura 67 – Exemplo esquemático de uma simulação em relação ao tempo. Cada veículo pode executar várias missões na mesma simulação .................................................................... 63

Figura 68 – Cada simulação efectuada regista os logs dentro de uma pasta específica ...... 65

Figura 69 – Interface principal da aplicação da Análise de Performance ........................... 66

Figura 70 – Interface de configuração de Métricas pertencentes à avaliação de uma Missão ..................................................................................................................................................... 67

Figura 71 – Interface dinâmica de estatísticas .................................................................... 67

viii

Lista de Tabelas

Tabela 1 – Unidades de medida suportadas ........................................................................ 40 Tabela 2 – Terminologias diferentes para mesmas propriedades ....................................... 49

ix

Abreviaturas e Símbolos

FSX Flight Simulator X. Simulador de voo da Microsoft e ferramenta base de desenvolvimento deste trabalho

API Application programming interface SDL Scenario Description Language. Linguagem desenvolvida para definição do

cenário do mundo TDL Team Description Language. Linguagem desenvolvida para especificação de

equipas de veículos XML eXtensible Markup Language. Framework para definir linguagens de anotação XML Schema

eXtensible Markup Language Schema. Linguagem para definição de regras de validação de documentos XML

C# Linguagem de programação desenvolvida pela Microsoft ATC Air Traffic Control

1

1 - Introdução

Este documento pretende analisar o que existe desenvolvido na área de estudo, simulação de veículos e análise de desempenho de veículos autónomos e demonstrar soluções que preencham as falhas encontradas.

Neste capítulo analisa-se o contexto em que surge o trabalho de forma a enquadrar o projecto, além de se apresentarem as motivações e objectivos do mesmo, identificando assim os problemas a resolver.

Os dois principais desafios deste projecto são o desenvolvimento de novos tipos de veículos para o simulador Flight Simulator X e o desenvolvimento de uma aplicação que permita efectuar uma análise de desempenho sobre missões efectuadas por veículos autónomos.

No final do capítulo, procede-se a uma descrição dos assuntos abordados nos restantes capítulos do documento.

1.1 Contexto e Motivação

Desde os seus primórdios, que o Homem tenta melhorar a sua forma de viver, a sua forma de sobreviver, seja na descoberta de novos utensílios que facilitam o seu quotidiano, seja na interacção social que faz entre os seus, tornando-se uma criatura menos vulnerável e mais forte.

Essa posição torna-se bastante visível com a revolução industrial, onde as inovações eram maioritariamente para melhorar a produtividade em relação ao trabalho humano, tornando-o mais rápido e barato, ou seja, com a criação de máquinas para fazerem trabalhos repetitivos.

Mais recentemente, tomou-se consciência da importância de máquinas para substituir pessoas em locais de difícil acesso ou perigosos. Sentiu-se assim a necessidade de criar máquinas que substituíssem as pessoas e, para tal, teriam de ser operados remotamente ou autónomos. Consciente da extrema importância deste paradigma, a DARPA criou a DARPA Grand Challenge com o objectivo de promover a investigação e promoção de agentes autónomos, neste caso, de carros autónomos que têm de, sem interacção humana, fazer uma longa viagem[1].

A extrema importância deste novo paradigma de evolução não se fica por aqui. Existem invenções e projectos-piloto que não podem ser implementados e testados devido aos custos monetários enormes e à grande probabilidade de falharem ou mesmo, como acontece nas missões espaciais, de haver apenas uma hipótese para executar a missão. Surgiu assim a necessidade de criação de simuladores que tentam ser representações o mais pormenorizadas

Introdução

2

possíveis do mundo real, onde os agentes são executados e testados permitindo assim que esses agentes simulados estejam a um pequeno passo de poderem executar missões na realidade.

Devido a essas vantagens, há alguns anos que também são usados agentes para controlar barcos e aviões, seja para testes de aviões civis como militares ou mesmo para a criação e implementação de veículos operados remotamente, não simulados, para executarem missões militares, de monitorização e de sobrevivência. O departamento de defesa dos Estados Unidos da América tem investido milhões de dólares e continuará a investir nos próximos anos para a evolução deste tipo de veículos[2].

Cientes da importância desta temática no presente e no futuro, cada vez mais investigadores se debruçam nesta problemática, de controlo de veículos autónomos e surge assim o projecto de Coordenação Dinâmica de Agentes para Operações de Vigilância, Busca e Salvamento.

Perante este projecto global, surgiu a necessidade de se criar/utilizar uma plataforma de simulação que permitisse efectuar os estudos na área do controlo autónomo de veículos. A plataforma, idealmente deveria suportar vários tipos de veículos (aéreos, terrestres, marítimos e submergíveis) que pudessem interagir entre si e executassem missões conjuntas.

Dessa necessidade, surge então este projecto, inserido no projecto de maior dimensão focado no estudo da coordenação de agentes em missões de vigilância, procura e salvamento.

No âmbito desta necessidade de desenvolvimento de novos produtos, de novas metodologias, torna-se assim importante o desenvolvimento de um inovador sistema de simulação com suporte para vários tipos de veículos e com suporte de execução de missões multi-veículos, de forma a se conseguir responder aos desafios que surgem.

Como complemento do desenvolvimento, para teste e melhoria dos controlos autónomos de veículos, torna-se necessário a avaliação da simulação efectuada e das metodologias utilizadas.

1.2 Objectivos

No contexto do projecto de maior dimensão, este projecto tem explicitamente duas vertentes de desenvolvimento:

• Numa primeira fase, de forma a responder à necessidade encontrada, o objectivo é adaptar novos veículos ao simulador Flight Simulator X (carros, barcos e submarinos) e, com estes novos veículos e com os aviões presentes no projecto principal, torna-se possível a elaboração de missões conjuntas entre veículos terrestres (carros e camiões), marítimos (barcos e submarinos) e aéreos (aviões), seja em missões de busca, salvamento, monitorização ou de outra.

• Uma segunda parte do projecto consiste na análise de desempenho dos agentes de forma a optimizar, tal como um bando de pássaros optimiza a sua táctica de voo em grupo, o desempenho dos agentes em diferentes tipos de missões. Para tal, pretende-se criar uma aplicação que utilizando toda a informação produzida pelos agentes autónomos durante as suas missões (sejam eles os aviões já existentes ou os novos que são adaptados, nomeadamente veículos terrestres, marítimos e submergíveis), apresente uma análise de desempenho do veículo ao longo do tempo, permitindo verificar quais os aspectos que devem ser melhorados. Toda a informação recolhida é armazenada para que se possa fazer repetição das missões, caso necessário.

1.3 Estrutura da Dissertação

Além deste capítulo, este documento tem mais cinco capítulos.

Introdução

3

O capítulo 2 faz uma análise do Estado da Arte, que engloba o estudo do ambiente de simulação a utilizar, o estudo de agentes para controlo de veículos e um estudo sobre alguns tipos de simulação/simuladores existentes nas áreas de veículos terrestres e marítimos. Numa segunda parte do Estado da Arte, é analisado o trabalho que existe feito na análise de desempenho, tendo em atenção que não se pretende verificar tendências durante simulações mas sim, para cada simulação, verificar qual o desempenho que ela obteve.

No capítulo 3 é apresentada a arquitectura global do trabalho em que este projecto se insere, é feita uma revisão do que esse trabalho já tem desenvolvido e faz-se uma análise da arquitectura daquilo que é necessário desenvolver.

Os capítulos 4 e 5 contêm o desenvolvimento efectuado neste projecto. No capítulo 4 é descrito todo o processo necessário e efectuado para o desenvolvimento dos novos tipos de veículos no simulador, desde a concepção até ao seu funcionamento e no capítulo 5 é descrito o trabalho efectuado na avaliação de desempenho dos veículos e das simulações, tanto a nível da aplicação desenvolvida como das métricas existentes.

Por fim, no capítulo 6 apresentam-se as conclusões do projecto e perspectivas de trabalho futuro.

4

2 - Revisão Bibliográfica

Este trabalho foca-se na extensão de um simulador de veículos aéreos, seleccionado entre vários existentes e pretende que o simulador passe a dispor de veículos terrestres (carros), veículos marítimos (barcos) e veículos submergíveis (submarinos) controláveis autonomamente e com características idênticas às dos veículos que se pretende simular, tornando assim a plataforma mais diversificada em termos de veículos disponíveis e com um leque de simulação muito mais alargada, com a possibilidade de execução de tarefas mais diversificadas para a coordenação e cooperação de múltiplos agentes. Um segundo ponto consiste na análise de desempenho que os agentes simulados conseguem obter na concretização das suas missões.

Sendo assim, de seguida faz-se um estudo sobre potenciais simuladores aéreos que sirvam de base a este trabalho, de simuladores de veículos terrestres, marítimos e submergíveis existentes, ao desenvolvimento de agentes e metodologias para análise de desempenho.

2.1 Adaptação de veículos

Nesta secção são abordados os temas do estado da arte referentes à adaptação de veículos, nomeadamente um estudo sobre agentes e, mais relevante, que tipos de simulação, simuladores e projectos existem que utilizem veículos terrestres, marítimos e submergíveis.

2.1.1 Agentes

No mundo que não pára de se desenvolver e de evoluir, as habituais arquitecturas lineares começam a perder força. Surgem cada vez mais os agentes que permitem resolver os problemas de forma autónoma, mantendo o controlo das suas decisões e do seu conhecimento, além de poderem ser utilizados em ambientes distribuídos[3].

Os agentes têm sido reconhecidos e essencialmente utilizados em áreas de Inteligência Artificial, para problemas de planeamento, extracção de conhecimento, problemas de lógica e negociação de multi-atributos, além da obrigatória comunicação que existe entre agentes.

Podemos definir então agente como uma entidade computacional que tem potencialidade de perceber o cenário em que actua, de comunicar com o mesmo e de comunicar com outros agentes, decidindo e actuando consoante as suas percepções.

Revisão Bibliográfica

5

Isso é possível graças aos sensores que o agente tem, que lhe permitem analisar o meio e obter as suas percepções sobre o mesmo, agindo de seguida consoante os seus conhecimento e decidindo então qual a melhor estratégia de implementação[4-5].

As principais propriedades de um agente são então a sua autonomia, ou seja, a capacidade do agente agir autonomamente, sem intervenção humana, a partir do seu conhecimento [6], a comunicação (e compreensão, obviamente) e interacção com outros agentes do cenário. São reactivos perante alterações de condições do cenário, alteração de comportamento de outros agentes ou de qualquer tipo de condições que afectam a sua missão, pró-activo na medida que pode e deve adaptar a sua missão consoante os objectivos que pretende executar e podem ir sofrendo alterações com o passar do tempo. A mobilidade que, tal como já foi referido anteriormente, consiste na possibilidade dos agentes terem possibilidade de serem executados de forma distribuída, em máquinas e locais diferentes. A cooperação entre agentes, possibilitada pela comunicação que existe entre eles, permite que os agentes cooperem e definam entre si estratégias, de forma a melhorar o seu desempenho nas tarefas que têm de efectuar. Finalmente, a aprendizagem em que o agente, com base em acções passadas, consegue perceber quais as melhores acções, perante uma determinada situação, que deve executar para obter os melhores resultados.

Em termos de ambiente onde os agentes operam, de onde recolhem informação que vai interferir nas suas decisões, existem algumas propriedades que devem ser destacadas [7].

O cenário pode então ser totalmente visível pelo agente ou parcialmente visível, caso haja propriedades no cenário que o agente não tem possibilidade de aceder. Pode ser estático, ou seja, não sofre qualquer alteração ao longo do tempo, por exemplo, numa representação do mundo real a velocidade e direcção do vento é sempre constante ou dinâmico, em que as condições vão mudando consoante as decisões dos agentes, como por exemplo, a velocidade e direcção do vento estão constantemente a sofrer alterações. Essas condições podem ser discretas, caso mudem em momentos predefinidos ou então de forma contínua, em que as propriedades do cenário vão mudando e actualizando em tempo de execução (vento está constantemente a sofrer alterações), numa simulação perfeita do mundo real. O cenário pode ser determinista no caso de, independentemente da acção efectuada o resultado esperado ser previsível ou não determinista quando o efeito das acções efectuadas não é completamente determinado. As acções efectuadas podem também ser episódicas, ou seja, singulares ou então podem num determinado momento provocar alterações nas decisões do futuro (apagar um incêndio vai provocar alterações de poluição e vento). Por fim, o cenário pode conter apenas um único agente autónomo ou então, e o mais comum e útil, vários agentes. Esses agentes, como anteriormente também foi referido, recolhem informação do cenário, comunicam entre si, podem ser cooperativos e trabalhar em equipa ou então serem competitivos entre si.

No presente trabalho, o cenário espera-se parcialmente visível aos agentes, com acções dinâmicas em que as acções efectuadas podem interferir no futuro e nas acções futuras, num ambiente dinâmico, em constante alteração e composto por vários agentes que cooperam entre si.

Em termos de arquitectura de agentes, existem várias propostas apresentadas por diferentes estudos. A escolha da arquitectura ideal, não tem uma resposta óbvia, dependendo do tipo de sistema e acções que se pretendem.

Assim, Wooldridge [8] apresentou três arquitecturas, a deliberativa, uma abordagem clássica de inteligência artificial que possui modelos simbólicos explícitos do mundo, a reactiva, que não utiliza o raciocínio lógico a apenas reage em tempo real e uma arquitectura híbrida, que combina as características referidas anteriormente, a deliberativa e a reactiva.

Posteriormente, Russel e Norving propuseram cinco arquitecturas de agentes[7]. Propuseram então uma arquitectura reflexiva simples que é a igual à reactiva, proposta por Wooldridge e referida anteriormente. Uma arquitectura de representação do estado do mundo que consiste na representação do estado do mundo que é actualizada dinamicamente pelo agente. Esta arquitectura permite, a partir da mesma percepção do agente, desencadear acções


6

diferentes. Uma terceira proposta baseia-se em agentes baseados em objectivos. O agente tem a informação sobre o estado do mundo e sobre os objectivos que pretende atingir e desta forma faz um estudo da melhor acção que pode executar em determinada situação. Outra arquitectura corresponde à de agentes baseados em utilidade, que utilizam uma medida de satisfação no cumprimento do seu objectivo. Um exemplo clássico desta arquitectura é o robô que tem de efectuar uma tarefa mas está a ficar sem bateria. Deve tentar efectuar a tarefa ou deve primeiro carregar a bateria? Consoante o conhecimento que tem, vai escolher a opção que lhe permite maior satisfação dos seus objectivos. Por fim, foram apresentados os agentes adaptativos, que aprendem e melhoram o seu desempenho com a experiência adquirida ao longo do tempo de forma a melhorarem o seu desempenho. Esse conhecimento é obtido através do feedback obtido pelas diferentes experiências que tem.

Novamente Wooldridge, voltou a apresentar uma nova arquitectura, desta feita, uma arquitectura em camadas [4]. Essa arquitectura é organizada em camadas dispostas hierarquicamente em que existe interacção entre as camadas e a entidade superior escolhe, consoante a informação disponibilizada pelas camadas inferiores que são compostas por exemplo por sensores, as acções que melhor se adaptam nesse instante.

Dentro das muitas arquitecturas que entretanto foram propostas, algumas delas mais complexas, é necessário também referir a arquitectura BDI (Belief-Desire-Intention) [9]. É uma arquitectura deliberativa que, tal como o nome indica, segue-se pelas crenças, desejos e intenções do agente, ou seja, pelo conhecimento do mundo que o agente tem, pelo seu desejo de executar um objectivo e pela intenção de executar tarefas que o levem a esse objectivo.

Este estudo de agentes é necessário na medida que os novos veículos a desenvolver, tal como os aviões já desenvolvidos, têm de tomar decisões e comunicar uns com os outros, sendo portanto importante perceber os princípios de funcionamento de veículos autónomos.

2.1.2 Simuladores de veículos terrestres e marítimos

A indústria dos jogos de computador, continua em expansão nos dias de hoje, gerando milhões de euros anualmente, havendo por isso uma grande diversidade de software, em diferentes plataformas e de diversos âmbitos.

Apesar de já se ter escolhido um software que servirá de base para a realização do trabalho – o Flight Simulator X – é importante estudar, na área específica deste trabalho, o que existe em termos de simulação de veículos terrestres e marítimos e perceber até que ponto representam a realidade.

Por exemplo, existe imenso software com veículos terrestres disponível no mercado. Exemplo desse software é o 3D Driving School, cujo aspecto gráfico pode ser verificado na Figura 1 [10], um simulador de trânsito, desenvolvido para aulas em escolas de condução, que a pessoa (o aluno) tem de conduzir, virtualmente, por um cenário virtual, respeitando as regras de trânsito (do mundo real) e coexistindo com trânsito gerado por veículos autónomos. Outro exemplo é o Euro Truck Simulator [11], um simulador de condução de camiões pelas estradas da Europa em que a pessoa tem de transportar uma carga de um local para outro pelas estradas da Europa, num ambiente simulado e com trânsito autónomo, tendo em atenção limitações como o combustível que tem disponível e as horas de condução que é possível um camionista trabalhar consecutivamente.

Na área de simuladores de veículos marítimos, o mais relevante é o Ship Simulator (ver Figura 2) [12-13], um simulador de veículos marítimos que pode ser adquirido para ser executada num computador pessoal mas que também tem uma versão profissional, que encontra-se disponível para ser vendida e construída à medida para um ambiente fidedigno de simulação naval, tendo como parceiros de referência a Royal Navi, entre outras, dado proporcionar um ambiente de treino simulado bastante real, com propriedades específicas como as ondas e força das marés, planos de navegação, eficiência de combustível, entre outros aspectos. A versão profissional é mesmo possível ser ligada a instrumentos físicos de um navio

para um ambiente de simulação fidedigno. Em termos gráficos são 3D de boa qualidade, tanto dos navios como do cenário.

Figura

Tanto os simuladores terrestres, 3D Driving School e Truck Simulator, como marítimos, Ship Simulator, aqui apresentados não possuem API’s públicas para desenvolvimento, ao contrário do FSX, tornandono primeiro a simulação disponível é tal como a adquirimos, no Ship Simulator, é mesmo possível encomendar novas especificações à empresa proprietária do simulador além do mesmo já ter, por exemplo, ambiente de simulaçãespecificações são sempre resumidas a barcos.

É também conhecido que os construtores automóveis possuem os seus próprios

simuladores. Seja para simular acidentes ou mesmo de estrada, onde são testados os componentes e a condução dos veículos num ambiente simulado

Os fabricantes automóveis desenvolvem alguns dos simuladores mais fiéis à realidade existentes no mercado, simuladores que não apenas simulam veículos num transmitem também as reacções proporcionadas pelo ambiente.

Em termos académicos, este tipo de simulação é sobretudo usada para estudo comportamental das pessoas num ambiente controlado e seguro. Para os construtores são o ponto de partida para o desenvolvimento de novos produtos. Permite que estes antes de serem construídos fisicamente, ainda num estado precoce de estudo e desenvolvimento, sejam logo testados, afinados e corrigidos problemas de desenvolvimento que possam ser encontradotornando o processo de desenvolvimento assim mais rápido e mais barato.

Por norma, estes sistemas representam fielmente os veículos que simulam fisicamente e em termos de desempenho, nomeadamente ao nível de pormenores como a resposta da direcção e da suspensão dos veículos, possuindo possibilidade de múltiplas configurações ao nível da

Figura


7

para um ambiente de simulação fidedigno. Em termos gráficos são 3D de boa qualidade, tanto dos navios como do cenário.

Figura 1 – Ambiente do simulador 3D Driving School

Tanto os simuladores terrestres, 3D Driving School e Truck Simulator, como marítimos, Ship Simulator, aqui apresentados não possuem API’s públicas para desenvolvimento, ao

, tornando-se impossível de adaptar nestas plataformas veículos autónomos. Se no primeiro a simulação disponível é tal como a adquirimos, no Ship Simulator, é mesmo possível encomendar novas especificações à empresa proprietária do simulador além do mesmo já ter, por exemplo, ambiente de simulação em caso de salvamento. No entanto, essas especificações são sempre resumidas a barcos.

É também conhecido que os construtores automóveis possuem os seus próprios simuladores. Seja para simular acidentes ou mesmo de estrada, onde são testados os

mponentes e a condução dos veículos num ambiente simulado [14]. automóveis desenvolvem alguns dos simuladores mais fiéis à realidade

existentes no mercado, simuladores que não apenas simulam veículos num transmitem também as reacções proporcionadas pelo ambiente.

Em termos académicos, este tipo de simulação é sobretudo usada para estudo comportamental das pessoas num ambiente controlado e seguro. Para os construtores são o

tida para o desenvolvimento de novos produtos. Permite que estes antes de serem construídos fisicamente, ainda num estado precoce de estudo e desenvolvimento, sejam logo testados, afinados e corrigidos problemas de desenvolvimento que possam ser encontradotornando o processo de desenvolvimento assim mais rápido e mais barato.

Por norma, estes sistemas representam fielmente os veículos que simulam fisicamente e em , nomeadamente ao nível de pormenores como a resposta da direcção e

uspensão dos veículos, possuindo possibilidade de múltiplas configurações ao nível da

Figura 2 - Imagens do simulador naval Ship Simulator 2008

para um ambiente de simulação fidedigno. Em termos gráficos são 3D de boa qualidade, tanto

Driving School

Tanto os simuladores terrestres, 3D Driving School e Truck Simulator, como marítimos, Ship Simulator, aqui apresentados não possuem API’s públicas para desenvolvimento, ao

s plataformas veículos autónomos. Se no primeiro a simulação disponível é tal como a adquirimos, no Ship Simulator, é mesmo possível encomendar novas especificações à empresa proprietária do simulador além do mesmo

o em caso de salvamento. No entanto, essas

É também conhecido que os construtores automóveis possuem os seus próprios simuladores. Seja para simular acidentes ou mesmo de estrada, onde são testados os

automóveis desenvolvem alguns dos simuladores mais fiéis à realidade existentes no mercado, simuladores que não apenas simulam veículos num ambiente virtual mas

Em termos académicos, este tipo de simulação é sobretudo usada para estudo comportamental das pessoas num ambiente controlado e seguro. Para os construtores são o

tida para o desenvolvimento de novos produtos. Permite que estes antes de serem construídos fisicamente, ainda num estado precoce de estudo e desenvolvimento, sejam logo testados, afinados e corrigidos problemas de desenvolvimento que possam ser encontrados,

Por norma, estes sistemas representam fielmente os veículos que simulam fisicamente e em , nomeadamente ao nível de pormenores como a resposta da direcção e

uspensão dos veículos, possuindo possibilidade de múltiplas configurações ao nível da

Imagens do simulador naval Ship Simulator 2008

simulação e possuindo um ambiente de simulação bastante envolvente. Este tipo de simulador, tipicamente possui ambientes gráficos detalhados além de uma interacção com o bastante próxima do real, nomeadamente com sistemas com seis graus de liberdade.

Estes simuladores, devido à sua representação da realidade, são também usados para treino, seja de condutores que pretendem aprender a circular na estrada, seja de competição que pretendem treinar.

Um exemplo, na alta competição, como na Fórmula 1, equipas como Williams e McLaren usam simuladores para os seus pilotos se adaptarem a novas alterações no monolugar, experimentarem novas afinações ou para onde vão correr.

Nos automóveis, o primeiro simulador de condução surgiu nos anos setenta, com três graus de liberdade, pelas mãos da Volkswagen. Em comparação com os mais actuais, era um simulador limitado, nomeadamente em termos de interface gráfica mas deu o sinal de partida para muitos outros desenvolvimentos.

Surge posteriormente o Research Institute, enquantodesenvolvem os seus próprio

Em termos académicos, referência simuladores da actualidade, com nove graus de liárea de simulação, um dos últimos desenvolvidos mais avançado simulador de condução existente cujo principal objectivo da sua construção centrou-se na análise das características dos condutores para desenvolvimento de tecnologia de segurança activa para os automóveis e, posteriormente, se verifidesenvolvidas.

Alguns sistemas inteligentes, já estão mesmo integrados em carros de produção, como o sistema de parqueamento assistido, que reconhece o lugar de estacionamento e, autonomamente, estaciona o carro ou o cruise contvelocidade a que circula consoante o tráfego na estrada

Mas uma das entidades que mais promove projectos de veículos autónomos, é da Defesa dos Estados Unidos. Um dos projectos mais conhecidos, o DARPA Grand Challenge (a Figura 3 mostra um dos veículodiferentes edições teve como ambiente o deserto ou a cidade, é um exemplo do que é possível desenvolver com agentes, ao permitirem que, já no mundo real, seja possível aos veícircularem autonomamente. Nesse contexto, existem diversos estudos que analisam diversas técnicas de controlo autónomo de veículos terrestres em missões, que neste caso, consiste em efectuar um percurso que os leve até determinado ponto, num ambiente

No campo dos submarinos, existe um vasto estudo em robots controlados autonomamencomo podemos verificar pela bibliografia, sendo que um exemplo é apresentado na Figura4 [21].

Figura 3 - Um dos veículos participantes no Darpa Grand Challenge


8

simulação e possuindo um ambiente de simulação bastante envolvente. Este tipo de simulador, tipicamente possui ambientes gráficos detalhados além de uma interacção com o bastante próxima do real, nomeadamente com sistemas com seis graus de liberdade.

Estes simuladores, devido à sua representação da realidade, são também usados para treino, seja de condutores que pretendem aprender a circular na estrada, seja de competição que pretendem treinar.

Um exemplo, na alta competição, como na Fórmula 1, equipas como Williams e McLaren usam simuladores para os seus pilotos se adaptarem a novas alterações no monolugar, experimentarem novas afinações ou para se adaptarem a uma pista do campeonato do mundo

Nos automóveis, o primeiro simulador de condução surgiu nos anos setenta, com três graus de liberdade, pelas mãos da Volkswagen. Em comparação com os mais actuais, era um

nomeadamente em termos de interface gráfica mas deu o sinal de partida para muitos outros desenvolvimentos.

Surge posteriormente o simulador VTI[15], desenvolvido para a Sewdish Road and Traffic , enquanto outros fabricantes automóveis seguem também a Volkswagen e

próprios simuladores como Daimler-Benz, Mazda[16]Em termos académicos, referência para o simulador NADS-1[17]

simuladores da actualidade, com nove graus de liberdade usado na University of Iowaum dos últimos desenvolvidos é pertencente à Toyota[18]

mais avançado simulador de condução existente cujo principal objectivo da sua construção se na análise das características dos condutores para desenvolvimento de tecnologia de

segurança activa para os automóveis e, posteriormente, se verificar a eficácia das soluções

Alguns sistemas inteligentes, já estão mesmo integrados em carros de produção, como o sistema de parqueamento assistido, que reconhece o lugar de estacionamento e, autonomamente, estaciona o carro ou o cruise control adaptativo que permite adaptar, autonomamente, a velocidade a que circula consoante o tráfego na estrada[19].

Mas uma das entidades que mais promove projectos de veículos autónomos, é da Defesa dos Estados Unidos. Um dos projectos mais conhecidos, o DARPA Grand Challenge (a Figura 3 mostra um dos veículos participantes) que teve a sua última edição em 2007, e que nas diferentes edições teve como ambiente o deserto ou a cidade, é um exemplo do que é possível

, ao permitirem que, já no mundo real, seja possível aos veícircularem autonomamente. Nesse contexto, existem diversos estudos que analisam diversas técnicas de controlo autónomo de veículos terrestres em missões, que neste caso, consiste em efectuar um percurso que os leve até determinado ponto, num ambiente real

No campo dos submarinos, existe um vasto estudo em robots controlados autonomamencomo podemos verificar pela bibliografia, sendo que um exemplo é apresentado na Figura4

Um dos veículos participantes no Darpa Grand Challenge

simulação e possuindo um ambiente de simulação bastante envolvente. Este tipo de simulador, tipicamente possui ambientes gráficos detalhados além de uma interacção com o utilizador bastante próxima do real, nomeadamente com sistemas com seis graus de liberdade.

Estes simuladores, devido à sua representação da realidade, são também usados para treino, seja de condutores que pretendem aprender a circular na estrada, seja de pilotos de alta

Um exemplo, na alta competição, como na Fórmula 1, equipas como Williams e McLaren usam simuladores para os seus pilotos se adaptarem a novas alterações no monolugar,

se adaptarem a uma pista do campeonato do mundo

Nos automóveis, o primeiro simulador de condução surgiu nos anos setenta, com três graus de liberdade, pelas mãos da Volkswagen. Em comparação com os mais actuais, era um

nomeadamente em termos de interface gráfica mas deu o sinal de partida

Sewdish Road and Traffic automóveis seguem também a Volkswagen e

[16], Ford, entre outros. [17], um dos maiores

berdade usado na University of Iowa. Nesta [18] e é actualmente o

mais avançado simulador de condução existente cujo principal objectivo da sua construção se na análise das características dos condutores para desenvolvimento de tecnologia de

car a eficácia das soluções

Alguns sistemas inteligentes, já estão mesmo integrados em carros de produção, como o sistema de parqueamento assistido, que reconhece o lugar de estacionamento e, autonomamente,

rol adaptativo que permite adaptar, autonomamente, a

Mas uma das entidades que mais promove projectos de veículos autónomos, é da Defesa dos Estados Unidos. Um dos projectos mais conhecidos, o DARPA Grand Challenge (a Figura

s participantes) que teve a sua última edição em 2007, e que nas diferentes edições teve como ambiente o deserto ou a cidade, é um exemplo do que é possível

, ao permitirem que, já no mundo real, seja possível aos veículos circularem autonomamente. Nesse contexto, existem diversos estudos que analisam diversas técnicas de controlo autónomo de veículos terrestres em missões, que neste caso, consiste em

real [20]. No campo dos submarinos, existe um vasto estudo em robots controlados autonomamente,

como podemos verificar pela bibliografia, sendo que um exemplo é apresentado na Figura4

Um dos veículos participantes no Darpa Grand Challenge de 2007


9

No campo de desenvolvimento de simuladores para simulação de veículos autónomos, é frequente estes serem desenvolvidos à medida consoante os aspectos que se pretendem desenvolver, ou seja, simula-se um ambiente e os veículos que necessitamos para testar novos algoritmos, novas estratégias.

Um exemplo desta abordagem é o caso do Ciber-Rato, um simulador de ambiente e de veículos[22]. Este surge no seguimento de um concurso, o Micro-Rato, que consiste no desenvolvimento de um robô que se encontra num labirinto e tem de encontrar a zona de chegada de um labirinto. Para tal, é necessário construir o hardware do robô e os algoritmos para a utilização do mesmo. Com o surgimento do Ciber-rato, deixa de ser necessário gastar tempo na construção do robô e os investigadores de veículos autónomos podem-se concentrar apenas no essencial do seu trabalho, ou seja, no desenvolvimento de algoritmos de controlo.

Neste caso, o Ciber-Rato simula o cenário em que se desenrola a acção e também os componentes de hardware dos robots. Os componentes de hardware dos robots simulados recolhem também eles informação, sendo que os agentes utilizam a informação gerada pelo simulador para operarem o veículo e atingirem os seus objectivos.

Existem muitos outros exemplos de simuladores construídos de raiz para responderem às necessidades específicas encontradas, sejam para veículos terrestres ou marítimos.

Mais recentemente, surgiram outras alternativas de construção de simuladores que respondem às necessidades dos investigadores. Com o crescente desenvolvimento efectuado nos motores de jogos comerciais, que actualmente conseguem efectuar simulação física e interacção com o ambiente de forma muito realista, além de interfaces de visualização de qualidade, surge uma tendência para modificar esse software de forma a, de uma forma relativamente barata, simples, muito mais rápida que a construção de simuladores de raiz e com grande fidelidade da descrição das propriedades dos veículos e do cenário, este se adapte aos veículos que pretendemos e, assim, se torne possível utilizar esses simuladores para desenvolver plataformas de estudo de veículos autónomos.

Esses simuladores devem ser de código aberto ou devem possuir uma API que possibilite a sua adaptação aos cenários que se pretendem desenvolver.

Um exemplo de um simulador deste tipo é o USARSim[23], baseado no motor do Unreal e desenvolvido essencialmente para missões de busca e salvamento efectuadas por veículos autónomos terrestres. Uma das suas principais utilizações acontece na competição RoboCup Rescue.

Um outro exemplo de simulador deste tipo é o Simbad[24], um simulador de código aberto com visualização 3D. No entanto, este simulador é utilizado em cenários em que a física não é muito relevante dado que não suporta cálculo de física, apenas colisões simples. É sobretudo indicado para testes simples de algoritmos de controlo de veículos.

A Microsoft dispõe de um simulador de raiz para este tipo de desenvolvimento, o Microsoft Robotics Studio[25] que possui um ambiente de simulação mas permite também efectuar o desenvolvimento de algoritmos para robôs reais, tornando a fronteira entre o controlo de veículos simulados e reais muito ténue. Em termos de física e visualização é dos que melhor desempenhos proporciona, além de ser possível adaptar-se de forma a melhor responder ao ambiente e veículos que se pretendem desenvolver.

O MissionLab[26] permite executar vários veículos simultaneamente e de vários tipos, sejam eles aéreos, terrestres e marítimos. No entanto, em termos de visualização não é exemplar além de não suportar qualquer simulação física.

Utilizando a ferramenta MATLAB/Simulink[27] é possível desenvolver ambientes multi-veículo, que podem funcionar em equipa. Existem vários casos de sucesso da utilização deste software para simular veículos terrestres, marítimos e submergíveis.

No âmbito da simulação exclusivamente submergível, existe o projecto SubSim[28], um projecto de código aberto assente numa arquitectura que permite estender ou alterar o simulador consoante as necessidades encontradas. Possuem uma visualização simplificada mas possui motor físico. Devido a isto, torna-se um simulador submergível bastante completo e eficaz.


10

Foram então apresentados vários tipos de simulação possíveis, desde exemplos de software fechado sem possibilidade de se efectuar desenvolvimento e investigação sobre a plataforma, passou-se pela análise de simuladores existentes que fazem representações muito próximas dos veículos reais e são instrumentos de desenvolvimento e teste e, finalmente, são analisadas algumas soluções comerciais que se podem adaptar às necessidades que o investigar necessita, sendo por isso mais simples que a construção de raiz de um ambiente simulação específica para um certo estudo. Neste último grupo de simuladores foram analisadas algumas das soluções existentes que suportam um ou vários tipos de veículos a desenvolver neste projecto, nomeadamente de veículos terrestres, marítimos e submergíveis. Este estudo, permitiu analisar o que existe feito na área da simulação, verificar o nível de realismo existente nos vários tipos de simuladores e perceber o quão importante é construir uma plataforma que represente os veículos de forma fidedigna assim como permitir perceber o funcionamento e comportamento dos vários tipos de veículos.

Figura 4 – Submarino Robótico

2.2 Análise de desempenho

Num mundo cada vez mais global, todo o mercado torna-se mais competitivo, obrigando as empresas a melhorarem a sua eficiência ao mesmo tempo que a população mais se preocupa com questões como a qualidade e preservação do ambiente. A mesma população que cada vez mais respeito tem pela vida e por isso tende a procurar soluções para substituir o Homem em funções que colocam a sua vida e integridade em perigo.

Estes são alguns dos exemplos que fazem com que, cada vez mais, se aposte na criação de agentes, simulados ou robóticos, de forma a ultrapassar esses desafios.

Como é natural, os agentes devem ser desenvolvidos e adaptados para cada funcionalidade que se pretende, seja ela negociar ou efectuar missões/objectivos e como é óbvio, é necessária verificar o desempenho que ele obtém no cumprimento das suas funções.

Na área de análise de desempenho de agentes, existem dois tipos que se podem destacar: a análise de desempenho de um sistema multi-agente ou o desempenho que os agentes têm na execução das tarefas para as quais foi pensado, implementado e executado.

No primeiro caso, essa medida é sobretudo executada para melhorar a computação dos agentes no sistema, o consumo de recursos computacionais dos agentes nas suas tarefas, nas suas transacções e o tempo de resposta[29].

Deve-se ter em atenção nestes casos de se fazer a distinção entre sistema multi-agentes homogéneos, em que todos os agentes têm as mesmas funcionalidades ou em sistema multi-agentes heterogéneos pois as necessidades dos segundos são variáveis de agente para agente.

Quanto aos parâmetros que este tipo de análise destaca na sua avaliação, encontra-se o número de agentes no sistema, o tempo computacional de cada agente, a memória utilizada, o estado do agente, a comunicação entre agentes e a dependência entre agentes[30-31], de forma a verificar em que ou quais os processos que estão a consumir mais recursos do sistema, podendo


11

proceder-se a uma optimização dos agentes ou então, criar perfis de execução para a melhorar o desempenho do sistema[30] [32-33].

Por outro lado, que é a análise mais importante para o trabalho a desenvolver na medida que se pretende medir o desempenho de agentes heterogéneos na execução de missões definidas, existe a avaliação da qualidade dos agentes ou avaliação das estratégias dos agentes nas suas missões, consoante o objectivo pretendido.

Este tipo de análise de desempenho permite então perceber qual a estratégia do agente que melhor se adapta a cada situação, consoante as condições do ambiente que se encontram. Um exemplo da aplicação deste tipo de análise, trata-se de verificar o desempenho dos agentes num ambiente simulado de uma cadeia de fornecimento [34] em que, consoante as variações do ambiente, verificam qual o sistema de agentes com melhor estratégia para atingir o objectivo. Sistemas esses, que tal como o sistema em estudo neste trabalho, são composto por um ambiente dinâmico, com propriedades que se vão alterando e com vários intervenientes que comunicam entre si de forma a chegarem a uma solução. Neste caso, consoante as alterações do ambiente de simulação, os agentes seleccionam o critério que acreditam ser o melhor para atingir o seu objectivo.

Verifica-se então que, consoante a escolha de determinados critérios de selecção, obtêm-se comportamentos diferentes por parte dos agentes e variações da eficácia de cada agente perante a situação, podendo então, para determinadas condições do ambiente, uma estratégia ser melhor que essa mesma estratégia num cenário com as condições de ambiente diferentes.

A estratégia é demarcada inicialmente e pretende-se assim saber qual a melhor metodologia para, em determinado ambiente, maximizar os ganhos ao atingir o seu objectivo.

No caso da cadeia de fornecimento, perante as condições de ambiente, para um dado parâmetro de análise, ordena-se qual o tipo de estratégia que melhor resultado proporcionou. No caso de haver vários parâmetros de análise, torna-se então importante definir qual a prioridade e qual a importância de cada um para o objectivo final dos agentes (porque para uma determinada missão que utiliza apenas um parâmetro, uma estratégia pode ser a mais adequada mas para outra pode ser completamente desadequada) e então, no final verifica-se qual a estratégia que, no conjunto, melhor resposta proporciona.

Significa então que, no caso de um sistema de simulação de agentes heterogéneos, num ambiente dinâmico, é possível avaliar o seu desempenho, efectuando uma avaliação multi-atributo [35], na medida em que existem vários parâmetros que influenciam o resultado final. Para a efectuar, utiliza-se então uma função de utilidade, com ponderações para cada parâmetro dependendo do tipo de missão que se queira avaliar. Para tal, e como já anteriormente foi referido [33, 36], são criados perfis de avaliação, cada um com uma função de utilidade baseada no tipo de missão a realizar, por exemplo, uma missão de salvamento, tem parâmetros de avaliação (rapidez de execução, distância, entre outros) e respectivas ponderações (importância relativa de cada parâmetro em análise) diferentes dos parâmetros de avaliação e respectivas ponderações do transporte de mercadorias.

2.3 Trabalho prévio

Sendo o trabalho de maior dimensão, no qual este trabalho está incorporado, o estudo da coordenação e cooperação entre agentes (veículos aéreos), sendo nesta fase desejável que o tipo de agentes disponíveis fosse alargado para veículos terrestres (carros e camiões) e veículos aquáticos (barcos e submarinos), e dado ser economicamente impossível a realização desse estudo em agentes robóticos (físicos) além de muito moroso em termos temporais, torna-se indispensável a escolha de um simulador para a realização do trabalho.

Existiam quatro critérios fundamentais para a escolha de um simulador para um trabalho científico deste tipo[37]. A capacidade do simulador representar fielmente o mundo, como o vento, chuva, temperatura além da representação fiel de características de veículos. Um segundo


12

atributo é a abertura do software, nomeadamente a existência ou não de uma API de forma a ser possível adaptar as propriedades dos veículos existentes, do ambiente e a forma de interacção entre os veículos. Um terceiro aspecto é a possibilidade de alterar especificações durante a simulação, como a criação de erros nos agentes para testes em caso de avaria e por último, e dado tratar-se um de trabalho científico, menos importante para o grande objectivo do trabalho, o aspecto gráfico do simulador.

Perante estas premissas, verificou-se qual a plataforma que melhor responde aos requisitos. Podem-se agrupar as plataformas em dois tipos: motores de jogo e simuladores. No

primeiro, o mais importante é o aspecto visual da aplicação. Nos simuladores, o principal objectivo é o de simular, com o maior detalhe possível, o mundo que se retrata de forma à experiência de simulação ser o mais fiel possível ao mundo real e, portanto, esta será a melhor opção para um trabalho científico como o que se trata.

Neste campo, existiam principalmente quatro simuladores objecto de estudo. O Flight Simulator X, X-Plane, Flight Gear e Piccolo.

O Flight Simulator X, simulador de voo desenvolvido pela Microsoft, [38-39] tem um cenário razoável do mundo (como a Figura 5 o comprova) mas com a possibilidade de se instalar extensões que passam a representar ainda com maior detalhe certas áreas do globo (cidades, aeroportos, paisagens). O comportamento da simulação é determinado por um conjunto de tabelas que contém vários parâmetros. Tem uma boa documentação, em termos de quantidade e qualidade, uma API e acesso a muitas variáveis internas do simulador, o que permite o desenvolvimento de novas funcionalidades. Em termos de plataforma, é possível desenvolver na plataforma .NET da Microsoft, C/C++ e existe até algum desenvolvimento em JAVA [40].

O X-Plane [41] é bastante detalhado em termos gráficos (como se vê na Figura 6), tendo uma representação do mundo bastante completa. Em termos de variáveis de simulação é bastante completo, não sendo por acaso que é um simulador utilizado para treinos de voo reais.

Figura 5 – Flight Simulator X Figura 6 – Simulador X-Plane

Tal como o X-Plane, o Flight Gear [42] tem uma representação bastante extensa do mundo, como mostra a Figura 7. É bastante flexível em termos de protocolos e facilidade de aceder às variáveis internas de simulação. De qualquer maneira, tem a grande desvantagem de ter pouca documentação disponível.

O Piccolo [43] em termos gráficos é bastante elementar, sendo em 2D, como comprova a Figura 8. De qualquer maneira, é possível importar a informação gerada por ele para ser visualizada num simulador com mais qualidade gráfica como o Flight Simulator ou Flight Gear.

Em termos de falhas, tanto o Flight Simulator X como o X-Plane permitem a ocorrência de falhas no simulador.

Concluiu-se que não existe um simulador superior a todos os outros e que o simulador deve ser escolhido consoante o objectivo do trabalho.


13

Figura 7 – Simulador Flight Gear Figura 8 – Simulador 2D Piccolo

Neste caso, optou-se pelo Flight Simulator X dado que faz uma representação pormenorizada do mundo ao fazer uso de centenas de variáveis, tem disponível uma API e uma boa documentação, permite a ocorrência de falhas além de ter uma interface gráfica de qualidade. Para este projecto, essa escolha permitirá assim a criação de novos tipos de veículos autónomos (carros, barcos e submarinos) que podem, tal como os aviões, efectuar missões.

2.3 Resumo

Neste capítulo efectuou-se uma revisão bibliográfica sobre os desenvolvimentos efectuados nas áreas de desenvolvimento do projecto. Fez-se uma análise ao conceito de agentes, já que o objectivo final deste trabalho é que os veículos se movimentem e efectuem missões autonomamente, prosseguiu-se por uma análise aos desenvolvimentos na área de simulação de veículos terrestres e marítimos, as áreas a desenvolver na adaptação de novos veículos ao simulador e finalizou-se com uma análise bibliográfica sobre como efectuar avaliações de desempenho, para este trabalho, de desempenho dos agentes ao executar missões.

Por fim, demonstrou-se o porquê deste trabalho estar assente na plataforma de simulação Flight Simulator X.

14

3 – Integração no Projecto Global

Neste capítulo é analisada a arquitectura do projecto assim como é abordado o trabalho já efectuado no âmbito do projecto de maior dimensão sobre o qual assenta este trabalho.

3.1 Arquitectura

Este trabalho encontra-se inserido num outro projecto de maior dimensão e pretende-se construir um sistema com um ambiente de simulação composto por vários veículos autónomos, que se coordenam entre si de forma a realizarem missões de busca e salvamento, de detecção e combate a incêndios, entre outras.

Dessa maneira, é possível analisar, estudar e comparar metodologias de coordenação multi-agentes que sejam mais eficazes do que as disponíveis actualmente.

A arquitectura proposta para o trabalho global em que este trabalho se insere, encontra-se esquematizada na Figura 9.

No centro da arquitectura encontra-se a plataforma de simulação, o Flight Simulator X que pode ter 1 ou N agentes em execução, um ou mais agentes ATC, uma ferramenta de logs, um painel de controlo além de tudo isto poder ser monitorizado por um utilizador.

Os agentes, que podem ser aviões, carros, barcos ou submarinos, funcionam sobre a plataforma e podem comunicar e negociar entre si para executarem missões conjuntas.

O agente ATC, é o responsável por monitorizar a actividade de todos os outros agentes e assim, em caso de avaria com um desses agentes, informa os restantes do sucedido. Perante os aviões, tem uma funcionalidade adicional na medida que servirá de controlador aéreo, ou seja, vai coordenar os aviões nas operações de descolagem e aterragem. Adicionalmente, pode existir um agente com a funcionalidade de fazer também a gestão de tráfego marítimo num porto (entrada e saída de barcos e submarinos no porto de forma a não haver choques). Eventualmente, pode haver também um agente ATC para controlo de tráfego terrestre num terminal de veículos terrestres. Existe um agente ATC para cada aeroporto, porto e eventualmente, para cada base terrestre.

A ferramenta de log tem essencialmente duas funcionalidades. É responsável por guardar toda a informação gerada pela plataforma de simulação e pelos agentes (dos veículos e pelos agentes ATC), tornando com isso possível a repetição de missões e também a análise de dados para efectuar uma análise de desempenho.

Finalmente, o painel de controlo é a interface entre o sistema e o utilizador. A partir deste, é possível configurar agentes, cenário e monitorizar acontecimentos. A configuração de agentes

Integração no Projecto Global

15

consiste na definição dos agentes e de seus atributos, como o tipo de agente, o nome, o modelo, os sensores que transporta entre outras características.

Figura 9 – Arquitectura do projecto, adaptada de [44]

Na Figura 9, encontram-se duas zonas sombreadas. Essas são as áreas que este trabalho vai intervir, na adaptação ou mesmo na criação de um módulo novo.

3.2 Adaptação de veículos

Sombreado na Figura 9 a vermelho, encontra-se a área responsável pelos agentes que são executados na plataforma e, como tal, é nessa área que se dá a adaptação dos novos veículos ao simulador. Nesse campo, já se encontra desenvolvido um agente para controlo de veículos aéreos (aviões) sendo que, a partir desse agente são executados os novos tipos de veículos, terrestres (carros), marítimos (barcos) e submergíveis (submarinos), como exemplificado na Figura 10.

Torna-se assim necessário efectuar a adaptação das propriedades dos novos veículos aos novos agentes.

Para o conseguir é necessário obedecer a um processo de desenvolvimento, exemplificado na Figura 11. Fez-se um estudo das características dos novos tipos de veículos a desenvolver, seguiu-se a análise e levantamento das características mais relevantes para mapear esses veículos, seja no FSX, seja em outro simulador/estudo. De seguida torna-se necessário o desenvolvimento do Painel de Controlo para os novos tipos de veículos e estruturas afectas a estes e, para finalizar, a adaptação destes novos veículos, a partir das características levantadas, no simulador FSX, passando este último a possuir novos tipos de veículos controláveis e aptos a executarem missões autónomas.

Em termos de modelos visuais para os novos tipos de veículos, são usados os modelos de veículos terrestres e marítimos que o simulador possui como cenário (veículos não controláveis do simulador que servem para preencher o mundo). De qualquer maneira, é possível


16

desenvolver nesta área novos modelos gráficos, dado que o simulador permite tal desenvolvimento ou então adquirir modelos já feitos por comunidades de utilizadores online do simulador FSX. Apesar dos modelos visuais não influenciarem de maneira nenhuma o desempenho dos veículos em simulação, é mais agradável a visualização de modelos idênticos aos que existem na realidade e não, por exemplo, simular um barco mas na imagem estar representado um avião.

Figura 10 – Representação dos novos tipos de veículos a incluir no simulador

Seguidamente encontra-se, em traços gerais o desenvolvimento já efectuado no âmbito do projecto global e que, em alguns casos, servem de base para o desenvolvimento dos novos tipos de veículos. Primeiramente, é apresentada a estrutura desenvolvida para mapeamento das propriedades pertencentes aos veículos já desenvolvidos (aviões) - sejam essas propriedades utilizadas posteriormente para configuração do veículo no simulador FSX ou não, mas são propriedades consideradas uma mais-valia para compreender as especificações dos veículos ou úteis para futuros desenvolvimentos. Segue-se uma análise à aplicação já desenvolvida, nomeadamente ao nível de menus de configuração para aviões e os tipos de manobras que os aviões já podem executar.

Figura 11 – Plano de desenvolvimento da adaptação dos novos tipos de veículos

Estudo dos veículos

Levantamento de propriedades dos veículos

Adaptação dos novos veículos no simulador

Construção do painel de controlo


17

No âmbito do projecto global, foram definidas duas linguagens para descrição de propriedades de forma estruturada, a Scenario Description Language (SDL) e a Team Description Language (TDL)[45].

De uma forma resumida, estas são duas especificações, em XML, sendo que as SDL apresentam informação que permite descrever um cenário, enquanto a TDL contém informação que permite descrever uma equipa. Devido à especificação em XML, qualquer nova propriedade que seja necessário acrescentar ou actualizar é elaborada sem provocar problemas de interpretação dos dados e com facilidade.

De seguida é detalhado para quê e como funcionam cada uma destas especificações e quão importantes são para o desenvolvimento deste trabalho.

3.2.1 SDL

Como foi referido, a SDL é a linguagem que define as propriedades do cenário. Na raiz dessa linguagem encontram-se quatro tipos de informação distinta: as Bases (bases), Controladores (Controllers), Tipos de Agente (Agent Types) e áreas interditas de voo/circulação (noFlyAreas), como exemplificado na Figura 12.

Os conceitos de Bases, Controllers, Agent Types e noFlyAreas foram criados anteriormente de forma a ser possível descrever, pormenorizadamente, bases aéreas e todas as suas estruturas físicas de funcionamento de uma base, os controladores de veículos, a especificação completa dos vários tipos de veículos possíveis de serem simulados e a especificação de zonas de voo interditas, respectivamente.

Figura 12 – Definição do elemento Scenario

Bases No cenário podem não existir ou pode haver N bases de operações, como mostra a Figura

13. Uma base de operações é um centro de operações que pode conter várias estruturas operacionais, neste caso, pode conter um aeroporto, um porto e/ou uma base terrestre. De notar que uma base só suporta uma estrutura operacional de cada tipo por casa base. Um exemplo, podemos definir uma base como “Base do Porto” que contém o Aeroporto Francisco Sá Carneiro. Para tal, uma base de operações precisa de ter definidos um nome para a base, o tipo de veículos que pode albergar (terrestres, aéreos, marítimos e submergíveis), alguma descrição e detalhes históricos da base, assim como a localização, informação e contactos da pessoa responsável pela mesma, disponibilidade e, finalmente e o mais importante, quais as estruturas que se encontram na base. As propriedades de um aeroporto já estão definidas, sendo que as propriedades de uma base terrestre (groundBase) e porto (port), são desenvolvidas neste trabalho e, como tal, estão descritas mais detalhadamente mais à frente.

Aeroporto (airport)

A informação descrita no aeroporto, e que se encontra exemplificada na Figura 14, é suficiente para se conseguir mapeá-lo completamente. Para tal, a linguagem criada para o aeroporto suporta descrições genéricas como um nome, descrição, contacto da pessoa


18

responsável, morada, código ICAO 1e IATA2 e o norte magnético. Em termos de mapeamento do cenário, é possível efectuar-se uma descrição completa das pistas de aterragem e descolagem do aeroporto através das coordenadas, comprimento, largura, tipo de solo e descrição das pistas. Dependendo da sua orientação, as pistas têm designações diferentes (por exemplo, na direcção sul�norte a pista tem uma identificação mas na direcção norte�sul, a mesma pista física tem uma designação diferente). Essa diferença é resolvida através das designações baseEnd e reciprocalEnd.

Figura 13 – Definição do elemento de bases de operações

As vias de táxi (taxiways), destinadas a serem usadas para o avião se deslocar do hangar/parque para a pista de descolagem, ou vice-versa, contêm uma designação, o tipo de solo, a largura e o path. O path é a forma encontrada para se mapearem as vias de comunicação sendo que é abordado com mais pormenor mais adiante.

Como os aviões nem sempre estão em funcionamento, é também mapeado espaços de parque, que contêm a habitual descrição, designação, as coordenadas, o raio que tem disponível para um avião e a companhia a quem está reservado. Existe também o conceito de hangar, edifício de parque dos aviões, que tem uma designação, descrição e o mapeamento das suas dimensões (shape).

Há também a possibilidade de se mapear um ou vários heliportos, locais de aterragem e descolagem de helicópteros, através das coordenadas, designação, o tipo de solo no local e o raio do heliporto.

Finalmente, são mapeados também estruturas utilitárias (utilities), que são equivalentes a estações de serviço e que têm a possibilidade de abastecer os veículos com combustível, bateria ou água, além da localização da sala de controlo.

Controladores (Controllers)

Os controladores são agentes que controlam o tráfego de veículos, seja para coordenar as aterragens, movimentação de aviões no solo e descolagens num aeroporto como o controlo das operações de entrada e saída de barcos de um porto ou até mesmo de um terminal de veículos terrestres (são referenciados posteriormente de ATC agents).

1 International Civil Aviation Organization 2 International Air Transport Association


19

Figura 14 – Definição do elemento aeroporto


20

Os controladores precisam da descrição da área de jurisdição onde actuam e exercem as suas competências e as frequências que usam para comunicar com os veículos que entrem na sua área de jurisdição, Figura 15. Áreas de Não Circulação (NoFlyAreas)

Estas áreas são definidas para que nenhum tipo de veículo, seja ele aéreo, terrestre ou marítimo possa circular, seja por motivos geográficos, políticos, militares ou outros.

Para delimitar estas áreas, é necessário um identificador, o tipo de veículo que está limitado a circular na área, o intervalo de tempo que estão interditos de circular e, como não poderia deixar de ser, a delimitação territorial das áreas de não circulação, seja através de círculos ou através polígonos, como demonstra a Figura 16.

Figura 15 – Definição do elemento de Controladores

Figura 16 – Definição do elemento de Áreas de não Circulação


21

Tipos de Agente (AgentTypes) Aqui encontram-se os vários tipos de veículos disponíveis que posteriormente são usados

por uma equipa descrita na TDL. Os tipos de agentes estão subdivididos em cinco componentes, como se pode verificar na Figura 17: informação relativa ao veículo simulado (simulatedAgentType), informação relativa ao agente real (realAgentType), propriedades físicas do mesmo (physical), propriedades de desempenho (performance) e as suas configurações de espaços de carga (payloads layout).

Em simulatedAgentType encontra-se o nome atribuído ao agente simulado. O realAgentType contêm a marca e modelo do veículo que está a ser simulado (por exemplo, Boeing) e o tipo de veículo que está a referir (avião, carro, barco ou submarino), a referência do veículo e outros atributos que se pretendam adicionar.

Características físicas (physical), de desempenho (performance) e de carga (payloads layout) contêm uma série de atributos pertencentes ao veículo.

Nas características físicas dos veículos, que neste caso, encontram-se apenas desenvolvidas para veículos aéreos, temos propriedades como o comprimento, largura, altura, peso, capacidade de combustível, capacidade máxima de carga, o número e tipo de motores, entre outros.

Em termos de desempenho temos a velocidade máxima e de cruzeiro do veículo, o seu consumo de combustível e a sua capacidade de manobra, entre outros.

Finalmente, no que respeita aos payloads, cada veículo pode ter um ou N payloads sendo que cada um deles tem uma dimensão (descrita com o comprimento, largura e altura desse local de carga) e um peso máximo que pode ter armazenado.

Mais adiante, esta área, tal como acontece na descrição das bases de operações, são desenvolvidas e explicadas com mais pormenor de forma a suportar os novos tipos de veículos terrestres, marítimos e submergíveis.

Figura 17 – Definição do elemento de Tipo de Agentes

3.2.2 TDL

A TDL contém a informação relativamente às equipas de agentes. Podem existir uma ou N equipas de agentes sendo que cada uma pode ter um ou N agentes de qualquer tipo (seja aéreo, terrestre ou marítimo).

A TDL está desenvolvida para suportar veículos aéreos sendo que mais adiante é estendida e explicada mais pormenorizadamente para os novos tipos de veículos, terrestres, marítimos e submergíveis.

Em termos de especificação, a TDL contém informação genérica como um nome, uma descrição, o histórico das ocorrências, a utilidade, o tipo de propósito para que existe, o contacto de um responsável assim como a base ou as bases que podem utilizar (descritas na SDL), áreas


22

restritas de voo para a equipa (additionalNoFlyAreas) e os agentes que pertencem à equipa, que pode conter um ou N agentes (correspondendo a 1 ou N veículos), como demonstram a Figuras 18 e 19.

Em relação aos agentes que pertencem à equipa, o agente é descrito com informação genérica como um nome, descrição, localização inicial, informação sobre o veículo real que está a simular, neste caso, número de cauda. É também descrito a carga que o veículo possui quando inicializado e verificado o estado do veículo, ou seja, qual o estado do veículo no início da simulação. Para veículos aéreos, é verificado o estado das luzes, se ligadas ou desligadas, posição dos flaps, do leme, entre outras. É também sobretudo ao nível do estado que mais tarde a TDL é desenvolvida de forma a suportar os novos tipos de veículos.

Figura 18 – Definição do elemento de Equipa

Figura 19 – Definição do elemento Agente, pertencente à equipa


23

3.3 Análise de desempenho dos agentes

O componente da análise de desempenho corresponde à zona sombreada a azul na Figura 9, correspondente à arquitectura do projecto global. Antes de efectuar a análise de desempenho, é necessário saber que informação está disponível para proceder à análise.

Está definido então que, cada agente de cada veículo gera informação em quatro ficheiros distintos: Estado (State), Estado do Ambiente (ambState), Eventos (Events) e Mensagens (Message). Significa então que, por exemplo, numa missão composta por três carros, dois aviões, um barco e um submarino, são gerados sete ficheiros de Estado, sete ficheiros de Estado do Ambiente, sete ficheiros de Eventos e sete ficheiros de Mensagens (um ficheiro de cada tipo para cada agente). A Figura 20 mostra graficamente o fluxo de informação criado.

Figura 20 – Fluxo de informação gerado durante uma simulação

No ficheiro Estado é guardado o estado do veículo em cada instante, como por exemplo a velocidade do veículo em cada instante, a sua posição no mundo e meio em que circula, quantidade de combustível, dispositivos activados como luzes do veículo, entre outros. Estes valores são registados em intervalos de tempo reduzidos (a cada 0,2 segundos). No ficheiros de estado de ambiente é guardada a informação relativa ao ambiente no local onde o veículo se encontra, tal como velocidade do vento, temperatura, entre outros elementos. No ficheiro de Eventos são descritos os eventos despoletados pelo veículo, como por exemplo, no caso de um carro dos bombeiros, o momento que este descarrega a água, a ocorrência de avarias e alterações na comunicação com restantes veículos e, finalmente, no ficheiro de Mensagens, são registadas as mensagens que o agente vai trocando com outros agentes que pertencem à equipa durante uma missão.


24

Os agentes ATC, geram também um ficheiro onde são registadas todas as Mensagens que são trocadas com os outros agentes veículos (ATC Message), tal como acontece com o ficheiro de Mensagens (Message) dos veículos.

Adicionalmente, para cada missão, é gerado também um ficheiro, Scenario, que monitoriza as alterações que acontecem no cenário.

Tendo então disponível esta informação, procede-se à implementação da análise de desempenho.

Após o estudo do Estado da Arte, verificou-se que, na generalidade, os estudos de desempenho efectuados a agentes baseiam-se na comparação de resultados obtidos entre o trabalho feito por uma pessoa versus o mesmo trabalho efectuado pelo novo agente ou então, nos casos em que já existe um agente desenvolvido, compara-se o desempenho entre as duas versões dos agentes numa mesma missão para verificar quais os ganhos de desempenho efectuados.

Outros estudos, apresentados no Estado da Arte, sugerem a análise de desempenho consoante o objectivo pretendido que, no caso deste trabalho, engloba a análise de várias propriedades, podendo então ser considerado uma avaliação multi-atributo em que se utiliza uma função de utilidade consoante a missão que se está a efectuar. Ou seja, para cada tipo de missão, seja ela de detecção de incêndios, apagar incêndios, salvamento de pessoas ou outras, será construída uma função de utilidade que, utilizando os dados que os agentes fornecem em tempo de execução, nos dá uma análise de desempenho, tanto de cada agente como da equipa de agentes que efectuou a missão.

Conhecendo-se o tipo de dados que existe e definido que está o tipo de análise de desempenho a efectuar (multi-atributo), desenvolve-se uma aplicação dinâmica e extensível que permita a análise e desenvolve-se métricas de análise para cada tipo de missão a avaliar (ver Figura 21).

Figura 21 – Plano de desenvolvimento da Análise de Desempenho

3.4 Aplicações Desenvolvidas

No âmbito do projecto global, foram já desenvolvidas duas aplicações com interface para o utilizador, a de painel de controlo e outra de controlo/monitorização de agentes.

A primeira, tem como principal finalidade a possibilidade de configuração das propriedades das linguagens descritas anteriormente, a TDL e a SDL e permite a comunicação directamente com a segunda aplicação que faz a ligação com o simulador FSX.

3.4.1 Painel de Controlo

A primeira aplicação, de painel de controlo, encontra-se apta a configurar o cenário para bases aéreas e os respectivos tipos de veículos, como se pode verificar na Figura 22, contendo também a interface para configuração de equipas de veículos, visível na Figura 23. Esta aplicação é estendida para passar também a efectuar a configuração de tipos veículos terrestres, marítimos e submergíveis, aspectos que são analisados com mais pormenor no próximo capítulo.

Como se verifica, é possível configurar todos os atributos definidos na SDL e TDL a partir desta aplicação. Os dados podem ser carregados a partir de ficheiros XML que obedecem ao

Definição do tipo de análise

Desenvolver aplicação

Desenvolver métricas usáveis para avaliação


25

Schema desenvolvido SDL, TDL sendo que, a inserção de novas propriedades ou edição de propriedades já existentes são também elas guardadas nos ficheiros XML. Isso significa que é possível mapear cenários e equipas, guardá-las e utilizá-las em missões posteriormente.

3.4.2 Ferramenta de Controlo do Agente

A segunda aplicação, além de ser a plataforma que controla cada veículo, ou seja, a plataforma que permite de forma manual, fazer o pedido de manobras a efectuar pelos veículos, de forma a serem testados antes de serem operados autonomamente, permite também visualizar graficamente as acções e posições dos diferentes veículos no simulador.

Figura 22 – Interface da aplicação de configuração do Cenário

Em termos de visualização, a plataforma funciona ligada através do Google Maps e, durante a execução de uma missão, coloca no mapa os pontos de passagem dos veículos. Os veículos suportados são os aviões, que podem executar manobras de diferentes tipos, nomeadamente:

• Deslocamento de um ponto para o outro • Helicoidais • Círculos • Manobras de descolagem e aterragem • Manter velocidade do veículo durante a viagem • Intercepção de veículos A Figura 24 apresenta a interface de controlo manual de manobras. Em termos de interface com o utilizador, esta aplicação mantêm-se para a adaptação dos

novos veículos. No entanto, devido às características dos novos veículos, estes podem executar um menor número de manobras. Assim, os veículos terrestres e marítimos apenas suportam


26

manobras de deslocamento de um ponto a outro e os submarinos, adicionalmente em relação aos veículos marítimos e terrestres, suportam a execução de helicoidais quando estão submersos. Em termos de lógica, esta plataforma é também desenvolvida no âmbito deste trabalho de forma a adaptar no simulador os novos veículos e novos tipos de simulação, analisados nos capítulos seguintes.

Figura 23 – Interface da aplicação de configuração das Equipas

Figura 24 – Interface da aplicação de Controlo de Agente. Configuração de manobras


27

3.5 Resumo

Neste capítulo foi apresentada a arquitectura do sistema do projecto global, dando-se ênfase à arquitectura a desenvolver no âmbito deste projecto específico, nomeadamente na área da adaptação de novos veículos e na área de análise de desempenho dos veículos/equipas de veículos.

Foi também feito um levantamento do trabalho já desenvolvido dado que na questão da definição das linguagens, interface de configuração das linguagens e aplicação de monitorização é desenvolvida sobre a plataforma existente.

Com a informação levantada neste capítulo, tornam-se claros os desenvolvimentos necessários para a execução do trabalho, nomeadamente ao nível da extensão das linguagens (após análise do funcionamento do que já existe desenvolvido) e da sua aplicação funcional, e do trabalho a efectuar ao nível da análise de desempenho, cujos desenvolvimentos são efectuados nos próximos capítulos.

28

4 – Adaptação de Novos Veículos

Neste capítulo procede-se à análise de todos os passos efectuados para a adaptação dos novos veículos ao simulador FSX.

Está subdividido em três partes fundamentais, configuração do cenário, configuração das equipas e, finalmente, a integração no FSX.

4.1 Configuração do cenário

Para a configuração do cenário, é necessário efectuar-se a extensão da linguagem SDL para os novos tipos de veículos, seguindo-se o desenvolvimento da aplicação de configuração das propriedades referentes à linguagem.

A adaptação destas propriedades ao simulador é analisada juntamente com as propriedades das equipas no subcapítulo 4.3.

4.1.1 Extensão da linguagem SDL

A primeira tarefa a efectuar neste trabalho, após o estudo descrito no Estado da Arte, é a definição das propriedades relevantes que são intervenientes num simulador, seja ele aéreo, de veículos terrestres, veículos marítimos ou submergíveis.

Dado este trabalho estar inserido num trabalho de maior dimensão, e estando a definição da linguagem efectuada para veículos aéreos, procede-se então à extensão da linguagem para um âmbito mais global, a de cenários e veículos terrestres, marítimos e submergíveis.

Este trabalho tem de ser efectuado tomando em consideração alguns pressupostos: • O ambiente de desenvolvimento a utilizar, neste caso o Microsoft Flight Siulator X • As definições e propriedades utilizadas nas áreas de estudo • O objectivo final deste trabalho. Assim, é pretendido que se consiga fazer uma definição da linguagem que esteja em

conformidade com as definições técnicas usadas em cada uma das áreas de simulação analisadas, que permita uma descrição pormenorizada do cenário e veículos e que seja possível, através dessa linguagem, adaptar os novos veículos ao simulador referido.

Assim, na definição da linguagem SDL, e tendo em consideração o estudo efectuado nas áreas de veículos terrestres, marítimos e submergíveis, focaram-se dois pontos principais de extensão da linguagem SDL, a extensão de bases de operações (baseOfOperations) de forma a

Adaptação de Novos Veículos

29

suportarem bases terrestres e marítimas e a extensão das propriedades dos novos tipos de agentes (Agent Type).

A Figura 25 apresenta a composição das bases de operações, além de poderem ter ou não um aeroporto (airport), podem ser também constituída por um ou nenhum Porto (Port) e por uma ou nenhuma base terrestre (groundBase).

Para cada tipo de base, é necessário identificar e mapear elementos que permitam, por si só, reconstruir o cenário identificado.

Base Marítima Assim, para se descrever um Porto (Port), no caso de uma base de operações

(baseOfOperations) ter um Porto, este é identificado através de um nome (name), uma descrição (description), um contacto da entidade responsável (contactPerson) e a sua localização (location) que além da morada completa contêm coordenadas precisas onde se encontra o Porto, como mostra a Figura 26.

Figura 25 – Definição do elemento de base de operações estendida para os novos tipos de veículos

De forma mais específica, são então mapeados uma série de atributos específicos do Porto. A Figura 27 mostra algumas da principais estruturas existentes num Porto, de forma a melhor se perceber como um Porto é constituído.

Assim, são mapeadas as vias de navegação (waterways), exemplificadas na Figura 28. Estas são as “estradas” de um Porto, as zonas por onde as embarcações podem navegar dentro do Porto. Um Porto pode ter várias vias de navegação em que cada uma delas tem uma descrição, uma largura e uma profundidade. Estas métricas são bastante relevantes pois são elas que indicam quais as dimensões máximas que uma embarcação pode ter para poder circular dentro de um Porto. Ao contrário das estradas, que habitualmente têm faixas de rodagem específicas para cada sentido, as vias de navegação são usadas para navegar em qualquer dos sentidos se bem que as normas indicam que se deve circular o mais à direita possível. Para finalizar o mapeamento das vias de navegação, existe também um Path que, tal como usado nos aviões, indicam as coordenadas de início e de fim da via de navegação, a existência ou não de ligações a outras vias de navegação, seja nas suas extremidades, seja mesmo a possibilidade de uma via ser interceptada por uma outra via noutro local que não as suas extremidades. Normalmente, as vias de navegação são interceptadas/ligam-se a outras vias de navegação, tal


30

como um grafo não dirigido. Esta arquitectura de grafo, porém, torna também possível, por exemplo, a uma via de navegação ligar-se a uma estrada (importante no caso de futuramente utilizarem-se veículos anfíbios).

Figura 26 – Definição do elemento Porto

Figura 27 – Exemplo das estruturas referenciadas num Porto

Num Porto, existem também estruturas designadas por cais/molhe (quays) que são as estruturas sólidas de apoio, que permitem o transbordo entre os veículos marítimos e “terra”, além de permitir aos mesmos veículos atracarem no Porto, podendo aí amarrarem-se, sendo estas estruturas descritas na Figura 29.

Assim, um Porto pode ter vários cais e cada cais tem uma designação e descrição (que dá mais pormenores técnicos sobre o tipo de cais que se trata), uma largura e o tipo de piso que o cais tem (por exemplo se é de cimento, terra, madeira, ou outro).

Tal como usado para descrever as vias de navegação, é utilizado um path que descreve a rede de cais existente num Porto, através das coordenadas de um ponto de início e um ponto de fim. Ou seja, os cais existentes num Porto são descritos como uma série de cais representados por segmentos de recta ligados entre si. Os cais podem estar conectados uns aos outros pelas extremidades mas também podem conectarem-se a um ponto intermédio de outro cais ou mesmo ser um cais único no cenário.


31

Figura 28 – Definição do elemento Via de Navegação

Figura 29 – Definição do elemento Cais

Quanto aos locais em que habitualmente se encontram parados os veículos marítimos (berths), faz-se a distinção de três tipos de estrutura, como demonstrado na Figura 30. Os locais onde estes veículos podem atracar, seja para embarque/desembarque ou simplesmente parar dentro de um porto (mooringSpace) e duas infra-estruturas de construção/manutenção de embarcações, designadamente as rampas de acesso (slipway) e as docas secas (dryDock).

Figura 30 – Definição do elemento Berths

Os locais de atracagem (“estacionamentos” dos veículos marítimos e submergíveis) são constituídos pela designação e descrição além de conter o tipo de embarcações que pode receber e a sua profundidade máxima. Para uma descrição precisa da sua localização, são necessárias as coordenadas do local de atracagem (constituídas, como de habitual, pela latitude, longitude e


32

altitude), pelo comprimento do local de atracagem e respectiva largura. Para finalizar, a descrição de um local de atracagem, existe a propriedade que indica em que posições uma embarcação pode atracar e qual o cais que serve esse local de atracagem (mooresTo), Figura 31.

Figura 31 – Definição de Espaço de Atracagem

As rampas de acesso das embarcações de terra à água, idealmente para proceder ao lançamento de embarcações à água ou para as retirar de água para reparações (slipway) são descritas, tal como os locais de atracagem, por uma designação, uma descrição, o tipo de embarcação que suporta, um comprimento, uma largura e as coordenadas da sua localização. Adicionalmente, para um mapeamento completo de uma rampa de acesso, é necessário obter o ângulo de inclinação da rampa e o tipo de material que é composto o piso da rampa (madeira, cimento, ferro ou outro). Adicionalmente, uma rampa de acesso também tem o peso máximo que uma embarcação pode ter para usar a rampa. A Figura 32 exemplifica a informação necessária de uma rampa.

Figura 32 – Definição do elemento de uma rampa de acesso


33

Quanto às docas secas (dryDocks), são estruturas onde as embarcações atracam para efectuarem manutenção. Estas são, de uma forma simples, compostas por um tanque estanque que contém uma comporta que permite à embarcação entrar dentro do tanque. A comporta fechando, torna-se possível retirar toda a água de forma a tornar o tanque livre de água (doca seca), permitindo que a embarcação possa ser reparada/proceder a manutenção num ambiente fora de água. Após a reparação/manutenção, a doca volta a encher-se de água até esta atingir o nível da água fora de doca e permita a embarcação sair da doca seca novamente para o mar/rio. A Figura 33 apresenta as várias propriedades que descrevem uma doca seca, e que são descritas de seguida.

Figura 33 – Definição do elemento Doca Seca

Tal como acontece na rampa de acesso, a doca seca é mapeada com uma designação, descrição, o tipo de embarcação que pode suportar, as coordenadas, o seu comprimento e a largura. Cada doca seca tem uma profundidade, ou seja, a distância entre o nível do mar/água e a profundidade da doca assim como um volume total de água que alberga até o nível de água da doca seca ser igual ao nível de água do mar. A embarcação, para usar a doca seca não pode ter um calado3 superior à profundidade da doca seca.

Devido à necessidade de encher e esvaziar a doca seca, é necessário ter o valor do fluxo de água que entre/sai para/da doca seca durante a operação(waterFlow).

Finalmente, e tal como acontece também num aeroporto, o Porto tem também um conjunto de utilidades (utilities) que podem fornecer água, combustível ou mesmo carregar baterias às embarcações.

Base Terrestre O mapeamento do cenário de uma base de veículos terrestres (groundBase), tem uma série

de atributos que são partilhados com o Porto, como por exemplo o nome da base terrestre, a descrição, o contacto da pessoa responsável e morada completa da base, como demonstra a Figura 34.

3 Distância vertical entre a superfície da água e a parte mais baixa da quilha (componente do fundo da embarcação)


34

Em termos de aspectos específicos de uma base terrestre, encontra-se o sistema de estradas da base, esquematicamente descrito na Figura 35. Assim, uma base terrestre pode ser composta por várias estradas, que se interceptam entre si, tal como acontece no porto com as vias de navegação. Cada uma dessas estradas tem uma designação, a especificação do tipo de piso que é composto e uma largura. De forma a simplificar a definição de vias e sentido de trânsito, tal como acontece no mundo, existe uma propriedade que especifica o número total de vias que a estrada tem (totalNumberOfLanes), uma outra que especifica quantas dessas vias têm sentido inverso ao especificado no path (reverseLanes) e uma outra propriedade específica qual, o sentido do transito, se pela direita ou pela esquerda (trafficIsRightHand). A localização exacta de cada uma das estradas é definida pelo Path, que tal como acontece nas vias de navegação, têm um ponto inicial e um ponto final, contendo as coordenadas exactas e as ligações que essas estradas fazem com outras estradas, criando assim um grafo. No caso especifico das estradas, o ponto inicial e final de cada estrada indicam também o sentido da estrada, ou seja, indica o sentido da estrada de forma definir qual o lado direito e esquerdo da estrada e assim ser claro quantas vias existem em cada sentido.

Figura 34 - Definição do elemento de Base Terrestre

Uma base terrestre também pode ter um ou mais parques de estacionamento (parkingSpacesGround), Figura 36. Cada um destes parques de estacionamento tem uma designação e uma descrição e é composto por um ou mais lugares de estacionamento (parkingSpace). Cada lugar de estacionamento é mapeado por dois pontos, um ponto inicial e um ponto final (tal como se mapeiam as estradas). Esses pontos indicam as coordenadas de início e fim do lugar de estacionamento. Adicionalmente, existe uma propriedade que indica a largura do lugar de estacionamento.

Tal como num Porto, uma base terrestre pode ter um ou vários locais para fornecimento de combustível, água ou recarregamento de baterias de veículos eléctricos, ou seja, estações de serviço.

Desta maneira, torna-se possível descrever, com precisão, toda uma base terrestre, tanto ao nível da sua descrição como a nível de todas as estruturas úteis que ela contém.


35

Figura 35 – Definição do elemento Estrada

Figura 36 – Definição do elemento Parque de Estacionamento

Veículos Para adaptar novos veículos, procedeu-se então à extensão de propriedades específicas

para os novos tipos de veículos a desenvolver (agentTypes), cuja sua estrutura é apresentada na Figura 37.

Como o objectivo do trabalho é adaptar veículos terrestres, marítimos e submergíveis, procedeu-se ao estudo das propriedades destes tipos de veículos e procedeu-se à extensão da linguagem de forma a suportar estes novos tipos de veículos. De uma forma genérica, qualquer tipo de veículos tem cinco áreas distintas de propriedades identificadoras, a saber, a identificação de um veículo no simulador FSX (simulatedAgentType), informações genéricas do veículo real (realAgentType), propriedades físicas (physical), propriedades de desempenho (performance) e configuração dos locais de carga de um veículo (payloadsLayout).

Figura 37 – Visualização das propriedades do elemento de Tipos de Agente

Após a análise dos novos tipos de veículos que se pretendem implementar, verificou-se que a identificação de um veículo no simulador, a informação genérica de um veículo real


36

(como modelo e designação) e as configurações dos locais de carga são genéricos a qualquer tipo de veículo, inclusivamente aos veículos aéreos, desenvolvidos anteriormente.

Sendo assim, para implementar os novos tipos de veículos, terrestres, marítimos e submergíveis, é sobretudo nas áreas de propriedades físicas e de desempenho que é necessário estender a linguagem de forma a suportar os novos tipo.

Durante o trabalho de levantamento das propriedades físicas e de desempenho dos novos tipos de veículos, rapidamente se verifica que a definição de propriedades dos veículos é uma área muito extensa. Além da diversidade de tipos de veículos terrestres, marítimos e submergíveis, dentro de uma qualquer destas áreas podem existir imensas especificações diferentes. Por exemplo, um veículo marítimo pode ter dimensões muito díspares, desenhos de casco e tipos de propulsão diferentes, assim como formas de se manobrar, entre outras propriedades diversas. Tendo em atenção o objectivo final desta extensão da linguagem a novos veículos e às potencialidades do simulador a utilizar, o FSX, optou-se por uma extensão que incluísse propriedades essenciais para uma simulação o mais representativa da realidade possível dos novos tipos de veículos, deixando propriedades secundárias e que não tenham interferência na operacionalidade dos novos veículos de fora da extensão da linguagem.

Por outro lado, surgiu a dúvida sobre como proceder com algumas das características técnicas dos veículos. Por exemplo, um veículo terrestre, tem um peso, um determinado motor com determinada potência e com uma determinada caixa de velocidades, entre outros componentes. No entanto, verificou-se que não é necessário obter informação tão detalhas sobre componentes e pormenores técnicos neste trabalho.

Optou-se assim por um cenário que descrevesse toda a informação necessária à simulação correcta de cada um destes novos veículos sem perdas e ao mesmo tempo, sem especificar informação irrelevante. Um exemplo, é a retirada de propriedades técnicas e a sua substituição por propriedades de desempenho. Outro exemplo, é a substituição da potência e localização relativa dos motores num veículo marítimo apenas pelas prestações que a embarcação permite.

De forma a se compreender melhor estas necessidades, são de seguida indicadas as propriedades físicas, exemplificadas na Figura 38 e de desempenho, exemplificadas na Figura 39, para cada tipo de veículo, seja terrestre, marítimo e submergível, que permitem atingir o objectivo final do trabalho.

Em termos de propriedades físicas, em qualquer tipo de veículo, seja ele aéreo, terrestre, marítimo ou submergível, existem itens que são genéricos. Assim, um veículo tem um comprimento (length), uma altura (height), peso quando se encontra vazio (emptyWeight), um peso máximo de carga que pode transportar (maxPayload), o número de motores que o veículo tem (nEngines) e a máxima quantidade de combustível (ou energia) que pode transportar (maxFuel ou maxBattery, respectivamente).

Além destas propriedades físicas, cada tipo de veículo contêm propriedades únicas a si. Assim, no caso de veículos terrestres, estes veículos têm como características físicas próprias a largura do veículo (width) e o número de rodas que o veículo possui (nWheels).

Os veículos marítimos e submergíveis têm como características físicas a largura (beam), a área do leme (rudderArea) caso exista, o comprimento e número de âncoras (anchorLength) e das cordas de amaragem (mooringLines), caso elas existam. De forma a simplificar, é admitido que o comprimento das cordas é igual em todas as cordas que a embarcação possui.

Nos veículos marítimos (barcos), como propriedades físicas relevantes encontram-se a distância entre a linha de água e o fundo do veículo (maxDraft) sendo que os veículos submergíveis têm duas propriedades físicas exclusivas, a área do leme vertical, caso exista (seaplaneArea) e o número e volume máximo total dos tanques de lastro que o veículo tem.

Os tanques de lastro são responsáveis por aumentar ou diminuir o peso do veículo com água, permitindo que, caso o lastro seja elevado, o veículo possa submergir, sendo que para emergir, o lastro é reduzido. Para as manobras de emersão e submersão, além do lastro, tem influência o leme vertical quando existe ou motores rotativos que propulsionam o veículo para a direcção pretendida. O posição relativa dos lemes, motores e a possibilidade de estes últimos


37

serem ou não rotativos não são, para o ambiente de simulação, primordiais na medida que, como de seguida é demonstrado, essa informação pode ser obtida através das propriedades de desempenho.

Figura 38 – Definição do elemento de Características Físicas dos Veículos.

Em termos de desempenho dos veículos, colocou-se uma série de propriedades que são partilhadas transversalmente por qualquer tipo de veículo.

Assim, velocidade máxima (maxSpeed), velocidade de cruzeiro (cruiseSpeed), autonomia (range) , consumo de combustível, caso exista, dado em volume por unidade de tempo (fuelFlow), consumo de energia, caso exista, dado em energia por unidade de tempo (energyFlow) e coeficiente aerodinâmico (dragCoefficient) são transversais a qualquer tipo de veículo.

Em termos de desempenho, veículos terrestres, são constituídos também pelo ângulo máximo de ataque, ou seja, a inclinação máxima do terreno que o veículo pode transpor (maxAttackAngle) e também pelo raio mínimo necessário para o veículo fazer uma volta de 90º (min90DegTurnRadius).

Os veículos marítimos, por sua vez, possuem a especificação do raio mínimo necessário para a embarcação poder efectuar uma viragem de 90º (min90DegTurnRadius).


38

Finalmente, os veículos submergíveis, também possuem o raio de viragem mínimo necessário para virar o submergível num ângulo de 90º (min90DegTurnRadius) mas possuem também outras propriedades. A velocidade máxima do submergível debaixo de água, habitualmente inferior à velocidade na superfície da água (maxUnderwaterSpeed), a profundidade máxima que o submergível pode atingir de forma a operar com normalidade (maxDepth) e a velocidade vertical máxima que o submergível pode atingir (maxVerticalVelocity).

Com todas estas especificações, torna-se possível simular um qualquer veículo, seja terrestre, marítimo ou submergível, com acções e reacções próximas dos veículos reais que estão a simular, sem no entanto ser necessária uma configuração do veículo muito extensiva e com muitos pormenores de construção.

Figura 39 – Definição do elemento de Características de Performance dos Veículos


39

4.1.2 Aplicação de configuração do cenário

Após a definição das linguagens SDL e TDL, é necessário torná-las funcionais. Assim sendo, é necessário criar uma aplicação que permita configurar e guardar todos os campos que as linguagens definem para todos os veículos, para todas as equipas, para todos os cenários.

Sendo as linguagens descritas num XML Schema, a operação de carregamento e guarda da informação procede-se directamente para ficheiros XML.

Sendo assim, é construída uma interface onde o utilizador pode adicionar, editar ou apagar a informação que segue os padrões definidos na linguagem.

A interface está dividida em dois separadores, essencialmente. No primeiro são efectuadas as configurações relativas à linguagem SDL, referente ao cenário e no segundo as configurações relativas à linguagem TDL.

Os menus de configuração, seguem essencialmente a estrutura existente nos XML Schema de definição da linguagem.

Assim, no separador de cenário podemos fazer as configurações de um aeroporto, de um porto e de uma base terrestre. É também neste primeiro separador que se pode acrescentar novos veículos dos tipos suportados (terrestres, marítimos e submergíveis) para serem utilizados.

Durante a configuração das várias propriedades que são trabalhadas, seja ao nível de cenário, seja ao nível de veículos, é frequente atribuir-se unidades de medida. Dado que é frequente usar-se diferentes unidades de medida consoante aquilo que é necessário descrever (por exemplo, o comprimento de uma estrada pode ser dado em quilómetros mas o comprimento de um veículo terrestre é dado em metros ou centímetros, assim como a velocidade de um carro é frequentemente definida em km/h enquanto a velocidade de uma embarcação é definida em nós). Sempre que é definida uma medida, é necessário indicar as unidades em que esta está descrita.

Na Tabela 1 são enumeradas todas as unidades de medida que podem ser seleccionadas na interface de configuração. Consonante o tipo de medida que se esteja a trabalhar, é possível seleccionar a unidade pretendida.

Porto A partir do menu principal de configuração do cenário, acedendo ao porto, é possível

editar a informação genérica do porto, editar ou apagar actuais serviços de apoio ou mesmo adicionar novos. Os serviços de apoio, são “estações de serviço” que se encontram no porto para apoio aos veículos marítimos e submergíveis. A Figura 40 apresenta o menu de um porto.

Como acontece na linguagem, um porto pode conter várias vias de navegação. A partir do menu do porto, acedendo à interface das vias de navegação, o utilizador pode adicionar novas vias de navegação ao porto ou editar/apagar as já existentes. Como está definido na linguagem, é necessário especificar as coordenadas iniciais, finais e porventura um ou vários pontos intermédias das vias de navegação (tal como uma recta que é definida por dois pontos). No caso de haver pontos intermédios, o utilizador pode adicionar a quantidade de pontos que necessitar ou apagar existentes, no local de configuração de pontos intermédios. Nos pontos definidos, é possível definir as ligações que ocorrem entre a presente via de navegação e outras. É através desta definição de ligações dos pontos pertencentes à actual via de navegação com outras que se define o grafo de vias de navegação/comunicação por onde os veículos podem/devem circular.

Para a definição de novas ligações entre vias de navegação, Figura 41, o utilizador ao carregar no botão de adicionar é confrontado com todas as vias de navegação que se encontram disponíveis, sendo que deve marcar aquela a que se pretende ligar. Automaticamente são listadas as ligações que a actual via de navegação possui com outras, sejam elas no ponto inicial, final ou nalgum dos intermédios. Para apagar alguma ligação, a ligação pretendida deve ser seleccionada nas listas de ligações existentes e carrega-se no botão de apagar.


40

Tabela 1 – Unidades de medida suportadas

Tipo Nome Símbolo Ângulos Graus Deg

Radianos Rad Área Pés quadrados Ft2

Quilómetros quadrados Km2 Metros quadrados M2 Milhas quadradas Mi2

Massa Onça Oz Grama G

Quilograma Kg Libra Lb

Velocidade Milhas por hora Mph Quilómetros por hora Kph

Milhas náuticas por hora Kts Polegadas por segundo In/s

Metros por segundo M/s Volume Galão Gal

Litro L Milha cúbica Mi3

Quilómetro cúbico Km3 Metro cúbico M3 Pés cúbicos Ft3

Polegada cúbica In3 Energia Ampere Amp

Miliampere mAmp Altura Acima água do mar Amsl

Acima do solo Agl Comprimento Milhas náuticas Nm

Milhas Mi Quilómetros km

Metros M Centímetros Cm

Pés Ft Polegadas In

Na interface de configuração dos lugares de atracagem, acedida através do porto, é

possível editar ou apagar lugares já existentes (listados automaticamente) assim como adicionar novos com as especificações pretendidas. Na adição de novos lugares, dentro da informação necessária de preencher especificada na linguagem, destaca-se a designação do tipo de embarcações que nesse local pode atracar, seleccionando os tipos possíveis na check list disponível e indicando o cais que o auxilia e a posição que a embarcação pode atracar em relação ao cais (se atraca de bombordo4, estibordo5, proa 6ou popa7), como se pode constatar na Figura 42.

4 Lado esquerdo da embarcação 5 Lado direito da embarcação 6 Dianteira da embarcação 7 Parte posterior da embarcação


41

Figura 40 – Interface de Configuração do Porto

Figura 41 – Interface de configuração de uma Via de Navegação

Através da interface do porto é possível aceder ao cais, apresentado na Figura 43, sendo que o funcionamento é muito idêntico ao que acontece com as vias de navegação, ou seja, é possível editar a informação dos cais já existentes (que são listados automaticamente), apagar cais ou adicionar novos cais ao porto. Como descrito na linguagem, o cais é especificado por uma série de atributos que devem ser preenchidos. A adição dos pontos iniciais, finais e intermédios do cais processam-se tal como sucede nas vias de navegação, explicadas anteriormente. A principal diferença provém do facto de quando são adicionadas novas ligações, são apresentadas ao utilizador a lista de outros cais disponíveis em vez de vias de navegação,


42

criando assim a rede de cais do Porto. Como segunda opção, é possível também conectar um cais a uma estrada.

Figura 42 – Interface de configuração de Espaços de Atracagem

Na interface de configuração de docas secas, é possível editar qualquer um dos campos e apagar docas já existentes (listadas automaticamente pela aplicação) assim como permite adicionar novas docas ao porto. Para adicionar uma nova doca seca, o utilizador deve preencher todos os campos, correspondentes à definição da linguagem e que podem ser analisados na Figura 44.

Figura 43 – Interface de configuração de Cais

Finalmente, na configuração do porto existe o menu para configuração das rampas de lançamento, apresentado na Figura 45. O utilizador pode, tal como acontece nas docas secas, editar a informação existente ou apagar rampas já existentes assim como adicionar novas


43

rampas ao porto que se está a descrever o cenário. Ao adicionar uma nova rampa, o utilizador tem de especificar as propriedades definidas anteriormente na SDL.

Figura 44 – Interface de configuração de uma Doca Seca

Figura 45 – Interface de configuração de uma Rampa de Acesso

Em qualquer dos menus apresentados anteriormente, se o utilizador não pretender guardar a informação após efectuar alterações, basta carregar no botão para cancelar.

Base Terrestre Na interface de configuração de uma base terrestre, é possível editar/adicionar informação

sobre a mesma assim como, tal como acontece no porto, proceder às mesmas operações de gestão de utilitários para veículos terrestres, as estações de serviço.

No mesmo menu, o utilizador pode efectuar a gestão de parques de estacionamento. Assim, o utilizador pode adicionar novos parques de estacionamento à base terrestre (por exemplo, o parque P1 FEUP), indicando uma designação e uma descrição. Um parque de estacionamento é um aglomerado de lugares de estacionamento e uma base pode ter vários parques. É possível editar/apagar parques já existentes. Em cada parque, é possível definir um ou vários lugares de estacionamento. Assim, após seleccionar o parque a que é desejado adicionar lugares de estacionamento (seleccionado na lista gerada automaticamente pela aplicação), o utilizador pode adicionar novos lugares, seleccionando o tipo de lugar (para


44

veículos pesados, ligeiros ou outros) e a largura do lugar. Para cada lugar, são definidas as coordenadas de um ponto inicial e do ponto final do lugar de estacionamento (desta maneira indica também o comprimento do lugar, além da sua localização exacta onde se encontra o lugar e onde os veículos podem estacionar, como demonstrado pela Figura 46.

A partir do menu da base terrestre é possível aceder às estradas da base. O funcionamento das estradas e construção da rede de estradas e muito idêntico ao utilizado para descrever as vias marítimas. Assim, é possível adicionar novas estradas à base, sendo que a estrada deve ter uma designação, o tipo de piso que tem, uma largura e o número de faixas de rodagem que possui. Adicionalmente existe o campo que indica quantas faixas existem para um dos lados, sendo que este valor tem de ser inferior ou igual ao número total de faixas de rodagem. Uma check box indica se o trânsito se desloca pelo lado direito (como é o caso de Portugal) quando está seleccionada ou não.

Cada rua é definida por um ponto inicial, um ponto final e, eventualmente, por nenhum, um ou vários pontos intermédios, sendo que cada um destes contém as suas próprias coordenadas. Neste campo, a diferença para as vias de navegação analisadas anteriormente, encontra-se no facto de as conexões serem efectuadas por defeito a outras estradas e não a outras vias, formando-se assim uma rede de estradas. A Figura 47 apresenta a interface a utilizar para efectuar as configurações descritas.

Figura 46 – Interface de configuração de uma Base Terrestre

Com esta interface, o utilizador tem a possibilidade de fazer a descrição completa e pormenorizada de estruturas habituais que são encontradas dentro de uma base de operações.

Veículos A partir do menu principal, o utilizador tem hipótese de adicionar novos veículos ao

sistema, ou seja, definir novos tipos/modelos de veículos que se podem usar. Por exemplo, o utilizador pode definir o veículo terrestre da marca Honda e modelo Civic na sua versão de três portas. Caso o utilizador pretenda apagar um veículo existente, pode efectuá-lo sendo apenas necessário seleccionar na combo box o veículo que pretende apagar e pressionar o respectivo botão.

Após a definição do tipo de veículo, e tal como definido na linguagem SDL, o utilizador deve configurar as suas características físicas, de desempenho e de carga. Assim, após seleccionar o veículo que pretende configurar, acede-se ao respectivo menu de configuração que é diferente consoante o tipo de veículo em questão na medida que apesar de todos os menus


45

estarem subdivididos em três blocos, características físicas, de desempenho e de carga, as propriedades são específicas para cada tipo de veículo.

Figura 47 – Interface de configuração de Estradas

Veículos marítimos Os veículos marítimos, seguindo a especificação da linguagem SDL, têm como

propriedades físicas que o utilizador deve preencher/editar para que cumpram as especificações reais do veículo que se está a simular, o comprimento do veículo, a sua altura, o seu peso quando não tem carga, o peso máximo de carga que pode transportar, a quantidade de combustível que pode transportar, a largura, a área do leme e qual a dimensão máxima do calado. No caso do combustível, é possível definir se o carro consome combustível fóssil ou se funciona a bateria. Dependendo da opção que o utilizador escolher, ficará disponível o campo indicado para isso. Além dos valores para cada propriedade, o utilizador em todas as especificações que são referidas anteriormente, tem de especificar também as unidades que estão a ser usadas. As unidades são escolhidas a partir das combo box que se encontram ao lado da propriedade indicada. Adicionalmente, é indicado o número de motores que o veículo tem e o tipo de motor que é, se é um motor de pistões, jacto, entre outros. Quanto às âncoras e às cordas, são descritas separadamente mas com uma estrutura idêntica. O utilizador tem de indicar o comprimento médio das cordas/âncoras que o veículo possui, as unidades em que estão descritas e o número total de cordas/âncoras disponíveis.

Em termos de desempenho, devem ser preenchidas todas as especificações definidas anteriormente na linguagem. Em todas estas propriedades é necessário identificar as unidades que se estão a referir os valores.

A terceira área de configuração corresponde aos locais de carga do veículo. Um veículo pode não ter locais de carga, pode ter um ou mesmo vários locais de carga. Assim sendo, deve ser especificado quais os locais de carga que existem. Os locais de carga são locais onde os veículos posteriormente podem carregar a carga/equipamento necessário para efectuar missões. Por exemplo, um veículo com poucos locais de carga e dimensões pequenas não será indicado para transportar grandes volumes.


46

Para tal, é possível adicionar novos locais de carga, editar ou apagar os existentes. Na definição de um novo local de carga, é necessário atribuir-lhe um nome, a capacidade máxima de carga que pode transportar e as dimensões que o compartimento tem, nomeadamente comprimento, largura e altura. É também especificado a posição que esse compartimento tem no veículo. Esses valores são especificados tendo como referência o centro geométrico do veículo, ou seja, a partir do centro geométrico do veículo, especifica-se a distância que o local de carga se encontra em três dimensões, x, y, z..

Na Figura 48 podemos observar a interface de configuração dos veículos marítimos.

Figura 48 – Interface de configuração de um veículo marítimo

Veículos submergíveis Nos veículos submergíveis, tal como nos veículos marítimos, as propriedades físicas que

são necessárias de ser configuradas são o comprimento, altura, o número de motores e respectivo tipo, o peso em vazio, o máximo de carga que pode transportar, a largura, a área do leme e, após selecção do tipo de propulsão (gasolina ou bateria) a quantidade/capacidade máxima que pode transportar. Adicionalmente, é necessário indicar a área do leme vertical do veículo além da capacidade média dos tanques de lastro existentes e o número de tanques disponíveis. Em termos de cordas e âncoras, processa-se tal como nos veículos marítimos, definindo para cada tipo o comprimento médio e o número total de unidades disponíveis.

Em termos de desempenho, tal como os veículos marítimos, é necessário especificar a velocidade cruzeiro do veículo, a sua autonomia, o fluxo de combustível/bateria que consome, a velocidade máxima quando navega emerso, o raio mínimo necessário para o veículo dar uma volta de 90º e o coeficiente aerodinâmico. Em termos específicos deste tipo de veículos, existe a velocidade máxima horizontal que pode atingir quando está submerso, a velocidade máxima vertical que consegue circular e a profundidade máxima que o veículo pode operar.

Quanto aos espaços de carga, estes veículos também os têm, sendo que podem não ter nenhum, um ou vários e o seu funcionamento é igual ao descrito nos veículos marítimos.

A Figura 49 exemplifica a configuração de um veículo submergível.


47

Figura 49 – Interface de configuração de Veículo Submergível

Veículos terrestres Em termos de características físicas, como qualquer veículo, é necessário especificar o

comprimento, altura, número e tipo de motores, o peso quando está vazio, o peso máximo que pode transportar de carga, a quantidade máxima de combustível/bateria que pode transportar e a largura. No caso específico dos veículos terrestres, é necessário especificar o número total de rodas e também o número de rodas que possuem tracção.

Nas especificações de desempenho, é necessário indicar o raio mínimo necessário para o veículo efectuar uma volta de 90º, a velocidade de cruzeiro, a velocidade máxima, a autonomia que possui, o consumo de combustível, o coeficiente aerodinâmico e também o ângulo máximo de ataque, ou seja, o ângulo máximo de inclinação que o terreno pode ter para que o veículo o possa transpor.

A gestão de espaços de carga é igual à que existe para veículos marítimos e submergíveis, sendo que já se encontra descrita anteriormente.

O utilizador pode sempre visualizar e editar a informação existente em qualquer configuração de qualquer veículo, seja para corrigir dados, seja para actualizar os dados dos veículos, como mostra a Figura 50.

Figura 50 – Interface de configuração de um Veículo Terrestre


48

Após todas as configurações apresentadas estarem efectuadas, os veículos tornam-se totalmente descritos e, portanto, estão aptos a ser utilizados no simulador.

4.2 Configuração de equipas

Para a configuração de equipas, é necessário efectuar-se a definição da linguagem para as equipas que suportem os novos tipos de veículos, seguindo-se o desenvolvimento da aplicação de configuração das propriedades referentes à linguagem das novas equipas.

A adaptação das propriedades aqui desenvolvidas no simulador é desenvolvida, juntamente com as propriedades do cenário, no subcapítulo 4.3.

4.2.1 Definição da linguagem TDL

A linguagem TDL define equipas de agentes que se relacionam entre si e procuram atingir os objectivos definidos.

No seguimento do que já havia acontecido com a SDL, anteriormente foi inicializada uma linguagem que suportava equipas de veículos constituídas por aviões. Tal como na SDL, pretende-se após o estudo do estado da arte efectuar uma extensão da linguagem de forma a suportar os novos veículos numa equipa, sejam eles terrestres, marítimos ou submergíveis.

Sendo a TDL uma linguagem descritiva de uma equipa, e por isso, bastante genérica, a extensão centra-se no tipo de veículos que a mesma pode acolher.

Uma equipa pode ser constituída por um ou vários veículos sendo que cada veículo tem as suas próprias características como um nome (name), uma descrição (description), o local onde se encontra no início da simulação (initialLocation), o estado do veículo no início da simulação (state), o nome do agente simulado (simulatedAgent), informação específica do homólogo real que está a ser simulado (realAgent) e, finalmente, da carga que o agente contém (Payload).

A linguagem tem de ser estendida ao nível do estado inicial dos diferentes tipos de veículos e para complementar a informação sobre os veículos reais que se estão a simular.

Em termos de estado inicial do veículo antes do início da simulação, é considerado que todos os veículos se encontram parados e que qualquer tipo de veículo tem uma quantidade de combustível (fuel) ou uma quantidade de bateria (battery) disponível.

A figura 51 apresenta as propriedades dos estados iniciais dos diferentes tipos de veículos analisados neste trabalho.

No caso de o veículo ser terrestre, além do combustível/bateria que contém, é importante fornecer a indicação do estado das luzes, ou seja, quais as luzes do veículo que se encontram acesas (lightsCar), sendo que um veículo possui duas luzes frontais, duas traseiras e uma no habitáculo, as luzes habituais de um automóvel. Existe também a informação se possui ou não portas abertas (doorsOpen) e qual o ângulo que as suas rodas de direcção fazem em relação ao veículo (equivalentWheelTurnAngle)

Em termos de veículos marítimos, estes também possuem uma série de luzes para as quais é verificado o seu estado (lightsBoat). Essas luzes são da ponte (cabin), do mastro (masthead), da popa (stern), as luzes laterais (sidelights), o farol de reboque (towing), o farol de iluminação de um raio de 360º(allAround) e a luz de relâmpago (strobe).

É também verificado qual o estado das âncoras (anchor) e do leme (rudder) caso existam e, finalmente, é verificado o ângulo que os motores fazem em relação ao veículo (equivalentEngineAngle), ou seja, se se encontram alinhados com o eixo longitudinal do veículo ou não. Como é natural, no caso dos motores serem fixos, o ângulo será sempre de 0º.

Nos veículos submergíveis, tal como nos veículos marítimos, é verificado o estado das âncoras, do leme, do ângulo que os motores fazem em relação ao veículo e das luzes. Neste caso, as luzes são da cabine, do leme (rudder), bombordo (port), de estibordo (starboard), proa


49

(bow) e a luz relâmpago (strobe). Adicionalmente, é também verificado o estado do leme vertical (seaplane), que é responsável, além dos tanques de lastro e dos motores com rotação de posição quando existem, por fazer o submergível subir ou descer. Da mesma forma, é também indicado o ângulo que os motores fazem na vertical em relação à posição do veículo.

A Figura 52 apresenta os realAgent, identificadores do veículo real que está a ser simulado, temos que os veículos terrestres têm uma matrícula (plate) e o número identificador de veículo, que é um número único para cada veículo (VIN8). No caso dos veículos marítimos e submergíveis, ambos têm o nome do veículo, como por exemplo RMS Queen Mary 2 (name) e o número único identificador do veículo(hullNumberIMO).

Com a definição completa da linguagem TDL aqui estendida para suportar os novos tipos de veículos, é possível descrever equipas constituídas por vários veículos, sendo que podem ser aéreos, terrestres, marítimos e submergíveis, sendo que cada um dos veículos tem a informação sobre o seu estado inicial e sobre a sua identificação única tendo em consideração o veículo que está a simular.

Chegados a esta parte, após a definição da SDL e TDL, podemos também verificar algumas particularidades de cada tipo de veículo. Como sabemos, para cada tipo de veículo existe uma terminologia própria para descrever as suas características. Por exemplo, na gíria marítima, descreve-se como proa e popa quando se pretende referir à parte frontal e traseira da embarcação, respectivamente. Por esse motivo, existem algumas propriedades que foram descritas na linguagem, que genericamente se referem a mesmas propriedades/especificações dos diferentes veículos mas que possuem diferentes nomes, consoante o tipo de veículo que se esteja a referir.

Na Tabela 2, são apresentados dois exemplos de propriedades idênticas existentes nos vários tipos de veículos analisados mas que possuem terminologia diferente consoante o tipo de veículo.

Podemos verificar que em termos de propriedade física dos veículos (descrita na SDL), a designação da largura dada por um veículo aéreo é dada por Wingspan, num veículo terrestre é Width e nos veículos marítimos é descrita como Beam.

Em termos de terminologia referente a luzes, para descrever as luzes mais recuadas que um veículo possui (descrita na TDL), no caso de um veículo aéreo é representada por Logo, num veículo terrestre por Rear (que pode ser esquerda ou direita) e nos veículos marítimos é normalmente designada por Stern ou Rudder.

Neste aspecto, e dada a natureza dos veículos, podemos também verificar que a terminologia dos veículos marítimos (barcos) e submergíveis (submarinos) é idêntica.

Tabela 2 – Terminologias diferentes para mesmas propriedades

Aéreo Terrestre Marítimo Submergível Observação Wingspan Width Beam Beam Largura do

veículo Logo light Rear right/left

light Stern light Stern/Rudder

light Luzes

posteriores

8 Vehicle Identification Number


50

Figura 51 – Extensão da definição do elemento de Estado para suportar novos veículos

Figura 52 – Extensão do elemento de veículo real simulado de forma a suportar novos tipos de veículos


51

4.2.2 Aplicação de configuração de equipas

No segundo separador do menu principal do painel de controlo, encontra-se a configuração das equipas. Como definido na linguagem TDL, o conceito de equipa é um conjunto de veículos que interagem entre si de forma a cooperarem na execução e conclusão de tarefas.

O menu está subdividido em duas partes essencialmente. À esquerda procedem-se às configurações genéricas da equipa tal como adição de novas equipas, edição de informação referente a equipas previamente criadas e possibilidade de eliminar equipas existentes. Os campos a preencher são nome, descrição, o tipo de veículos que a equipa possui, a sua história, propósito e as bases em que a equipa actua. No lado direito encontra-se a lista dos agentes que a equipa tem e é aqui que, além dos veículos aéreos, desenvolvidos previamente, se podem adicionar os novos tipos de veículos, terrestres, marítimos e submergíveis. Convém recordar que as áreas da linguagem TDL que necessitaram de ser estendidas para suportar novos veículos foram o estado do veículo e os identificadores do veículo real que está a ser simulado. Assim sendo, é possível agora adicionar novos tipos de veículos. Para tal, o utilizador, no menu de equipa pode adicionar um novo veículo. Deve preencher a informação genérica a qualquer veículo, nomeadamente o nome do veículo, a sua descrição e localização. É também neste menu que se tem de preencher a primeira parte da extensão efectuada. Se o veículo adicionado é terrestre, no quadro de Real Agent é necessário incluir a informação do VIN e a sua matrícula. Caso o veículo a adicionar seja marítimo ou submergível, é escrito o número de identificação da embarcação, que tal como o VIN nos automóveis, é único e o nome da embarcação.

A configuração do estado, depende do tipo de veículo que é escolhido no momento da adição de novos veículos. Assim, após escolher o veículo que se pretende configurar, acede-se ao menu cujas opções são específicas para cada tipo de veículo.

Para veículos marítimos, cuja interface é apresentada na Figura 53, as configurações do estado possíveis são as luzes, se acesas ou apagadas. Essa informação é passada por uma check list para cada luz, que pode ser da ponte, mastro, popa, luzes laterais, farol de reboque, o farol de iluminação de um raio de 360º e a luz de relâmpago. É também necessário colocar na caixa de texto a informação sobre a âncora e posição do leme. Consoante o tipo de propulsão utilizada para o veículo, é através desta interface que é indicada a quantidade que o veículo dispõe, seja de combustível, seja de bateria. Finalmente, é também indicado o ângulo que o motor está a fazer na horizontal em relação ao veículo e seleccionado na combo box a respectiva unidade de medida. Caso o motor seja fixo ou não faz nenhum ângulo com o corpo do veículo, coloca-se zero.

Da mesma forma, quando se tratam de veículos submergíveis, o menu é específico para configuração destes veículos, como se pode constatar pela interface apresentada na Figura 54. Assim, é possível configurar se as luzes da cabine, do leme, bombordo, de estibordo, proa e a

Figura 53 – Interface de configuração do estado de um Veículo Marítimo


52

luz relâmpago, estão acesas ou apagadas. Tal como nos veículos marítimos, é indicado o ângulo horizontal do motor, a posição do leme e da âncora assim como a quantidade de combustível/energia que o veículo tem. Adicionalmente, é necessário especificar o ângulo que o motor faz na vertical (o motor pode rodar na horizontal e na vertical, sendo que se especifica cada uma das componentes em separado) e a posição do leme vertical.

Figura 54 - Interface de configuração do estado de um Veículo Submergível

Por fim, para veículos terrestres, as configurações de estado do veículo são as luzes, neste caso as do habitáculo, duas frontais (direita e esquerda) e duas traseiras (direita e esquerda). Existe também uma check box para verificar se possui portas abertas ou não e, da mesma forma usada nos veículos marítimos, a quantidade de combustível ou bateria que o veículo possui. É também verificado o ângulo que as rodas direccionais estão a fazer em relação ao veículo A Figura 55 apresenta a interface de configuração do estado dos veículos terrestres.

Após a definição das características estáticas dos veículos efectuadas anteriormente na SDL, acabou-se de efectuar a configuração do estado do veículo no início da missão. Desta forma, já estão configuradas todas as variáveis dos veículos necessárias para efectuar movimentos dos veículos, faltando a ligação destas configurações com o simulador Flight Simulator X.

Figura 55 – Interface de configuração do estado de um Veículo Terrestre


53

4.3 Integração com o FSX

Nesta fase pretende-se utilizar os dados recolhidos anteriormente no simulador, dando assim as propriedades físicas e de desempenho aos novos veículos.

Existem duas formas de configurar no FSX os novos veículos, como apresentado na Figura 56. Uma, através da sua API, que permite leitura das definições dos veículos ou mesmo a alteração das definições em tempo real. A outra, através de ficheiros de configuração de veículos[46-47].

Figura 56 – Interfaces de comunicação com o simulador

Em relação aos ficheiros de configuração de veículos, existem dois tipos distintos, aircraft.cfg e sim.cfg. Os primeiros têm especificações pormenorizadas de propriedades específicas de aviões. Os segundos, são considerados pelo simulador FSX como sendo ficheiros de configuração de objectos incluídos no cenário de simulação e, por isso, podem ser utilizados para outros tipos de veículos.

Os ficheiros de configuração de veículos são ficheiros de texto estruturado que o simulador possui para qualquer avião e onde constam as diferentes propriedades estáticas do mesmo, ou seja, é possível visualizar e editar as especificações técnicas de um veículo. Essas propriedades técnicas vão desde o comprimento, largura, altura, peso até à configuração das luzes, além de muitas outras especificações.

Numa análise, verifica-se que existem propriedades que podem ser definidas tanto ao nível do ficheiro de configuração como, em tempo de execução, a nível da API do FSX.

Pretende-se então, a partir destas ferramentas, configurar no simulador os novos veículos. Perante a situação, e dado que é necessário utilizar as duas componentes devido às várias propriedades que são necessárias configurar, optou-se por incluir todas as configurações iniciais possíveis no ficheiro de configuração e apenas aquelas que não podem ser efectuadas via ficheiro de configuração, são efectuadas em tempo de execução, neste caso, logo que o veículo é carregado e inicializado pelo simulador.

Na prática, após todas as configurações efectuadas ao veículo, o utilizador dá indicação para lançar o veículo no simulador. Antes de isso acontecer, o sistema abre o ficheiro de configuração de um veículo/objecto existente no simulador e substitui as suas características originais pelas características do veículo que foi configurado e pretendemos utilizar no simulador. A informação a incluir no ficheiro segue a estrutura referenciada pela documentação do simulador de forma a que este consiga carregar e interpretar os dados contidos. Após todos os dados incluídos no ficheiro de configuração do veículo/objecto, ele é gravado, fechado e o novo veículo carregado para o simulador, como apresentado na Figura 57. Estando o veículo carregado já no simulador, ou seja, sendo ele colocado graficamente no simulador com as características definidas no ficheiro de configuração, é necessário concluir a configuração das características do veículo que não são possíveis de definir no ficheiro de configuração. Para tal, automaticamente após o veículo ser carregado e antes de ser possível efectuar qualquer manobra com o veículo, em tempo de execução, são configuradas as propriedades remanescentes para


54

que o veículo possua um desempenho tal como o existente na realidade, seja a simular um carro, um barco ou um submarino.

Após estas configurações, o veículo está apto a realizar manobras no simulador. Como seria expectável, essas manobras dependem das especificações configuradas, ou seja, o raio de viragem necessário do veículo ou a velocidade que ele atinge são dependentes das configurações efectuadas e apresentadas.

Figura 57 - Processo de configuração de veículos no FSX.

4.3.1 Controlo de veículos

Estando os novos veículos terrestres, marítimos e submergíveis criados, é necessário então controlá-los.

Para tal, são utilizados os controlos de manobras desenvolvidos anteriormente para os aviões. Esses controlos são, essencialmente, de deslocação do ponto actual do veículo a outro ponto e de círculos (no caso de veículos terrestres e marítimos, sem componente vertical). No caso dos submarinos, tal como acontece nos aviões, também pode fazer helicoidais e é possível manobrá-los na vertical, mas ao invés de terem uma componente vertical positiva em relação à terra, tem uma componente negativa em relação à altura da água do mar.

Torna-se possível efectuar este tipo de manobras dadas as potencialidades do FSX e pelo facto de os novos veículos serem tratados pelo simulador como veículos já existentes no simulador mas desta feita com características alteradas às pretensões do utilizador.

Para cada tipo de manobra, é calculada a trajectória que o veículo deve seguir, do local onde o veículo se encontra até ao local que se pretende que ele atinja. A Figura 58 mostra o exemplo de uma trajectória definida para um veículo. Nessa trajectória são calculados vários pontos de referência por onde o veículo deve passar. Essa lista de pontos (waypoints) é então enviada para o FSX que usando as capacidades de piloto automático permite que o veículo percorra a trajectória definida. Dadas as configurações introduzidas no início da simulação, aspectos como a velocidade e raios de viragem mínima dos veículos são garantidos e


55

correspondem à especificação introduzida, apesar de ser o piloto automático do simulador a ficar encarregue de o fazer.

Figura 58 - Rota a efectuar pelo veículo. O círculo é o ponto de referência de chegada

4.3.2 Veículos Submergíveis

Como descrito, este trabalho consiste na adaptação de veículos terrestres, marítimos e submergíveis ao FSX.

Como verificado anteriormente, os veículos já podem ser configurados, inicializados e mesmo controlados para manobras efectuadas no simulador. Tanto os veículos marítimos como os terrestres, que andam na superfície da água e da terra, estão aptos a fazerem as missões que lhes competem. Mas os veículos submergíveis têm ainda limitações.

A primeira é o facto de um veículo submergível de baixo de água ter prestações diferentes, nomeadamente ao nível da velocidade máxima debaixo de água e a velocidade máxima vertical que o veículo suporta.

A segunda, sendo o FSX um simulador aéreo, tem o cenário terrestre e aéreo mapeados mas não possui cenário abaixo da água, ou seja, o simulador não suporta alturas negativas em relação ao mar logo não suporta, por defeito, veículos que possam navegar em baixo de água.

Para colmatar estes entraves, optou-se por simular o funcionamento dos veículos submergíveis quando estes navegam abaixo da água.

Como verificado anteriormente, as rotas a seguir pelos veículos são calculadas e são enviadas listas de pontos de referências pertencentes à trajectória para o simulador, que fará o veículo percorrer por esses pontos. Como o simulador não suporta altitude negativa, apesar de no cálculo da rota existir altitude negativa, o simulador apenas reconhece como que o veículo se encontrasse sempre na mesma altitude mas variando a posição da latitude e longitude.

Dado que os pontos de referência possuem altura negativa, a estratégia para resolver este problema passa por:

• Enviar pontos de referência para o simulador • O veículo começa a traçar a rota • Para cada instante predefinido (a cada 0,2 segundos), é solicitado ao FSX que envie a

posição actual do veículo (latitude e longitude, sendo a altura a zero) e qual é o seu ponto de referência. A Figura 59 apresenta a troca de informação que existe entre a aplicação e o simulador quando se trata de um submarino. Primeiro a aplicação envia a rota a efectuar através de uma lista de pontos de referência e a cada instante o simulador retorna a posição em que o veículo se encontra.

• Interpolando o ponto de referência actual e seguinte (a partir da latitude e longitude), calcula-se a altitude para cada instante do veículo submergível


56

Figura 59 - Processo de controlo de um submarino.

4.3.3 Características de Navegação Submersa

Dadas as limitações do simulador na área de veículos submersos (não foi projectado para os suportar e como tal não permite navegação submersa), para simular o veículo é necessário garantir, em tempo de execução, que o seu desempenho vai de encontro às suas propriedades quando submerso.

Tendo em atenção as propriedades relevantes trabalhadas anteriormente, destacam-se a velocidade do veículo quando se desloca debaixo de água, a velocidade máxima vertical que o veículo pode atingir e a profundidade máxima.

No caso da profundidade máxima, é um limite que se coloca no cálculo da trajectória, de forma a que a profundidade pretendida não seja superior à profundidade possível do veículo.

Já para a velocidade, é necessário haver uma comunicação com o próprio simulador, dado que é o simulador que, a partir das suas potencialidades, desloca os veículos no cenário, consoante as características técnicas do veículo em questão.

Assim sendo, de forma a simular correctamente os veículos quando submersos, é necessário utilizar uma vez mais, a API do FSX em tempo de execução. Desta feita, logo que um veículo passe a navegar debaixo de água, é dada a indicação ao simulador que a velocidade do veículo é diferente, passa a ser a velocidade do veículo configurada para navegar debaixo de água. A partir desse momento, o simulador passa a manobrar o veículo à velocidade máxima que é indicada, habitualmente inferior à velocidade quando navega à superfície. A partir do momento que o veículo volta à superfície, novamente em tempo de execução é enviada a indicação ao simulador, a partir da sua API, que a velocidade do veículo passou a ser a velocidade de navegação à superfície.

Para controlar a velocidade vertical do veículo e garantir que a mesma se encontra dentro dos parâmetros do veículo, usou-se a mesma técnica apresentada no caso anterior. Dado não haver possibilidade da parte da API de controlar a velocidade vertical, usou-se a mesma variável da velocidade do veículo (velocidade horizontal) mas de forma dinâmica.

Relembrando a questão das velocidades, os veículos submergíveis possuem duas velocidades quando submersos, velocidade máxima horizontal e velocidade máxima vertical.

Em cada instante, é verificada a velocidade horizontal a que o veículo circula e, consoante a inclinação da trajectória calculada anteriormente, obtêm-se a componente vertical da velocidade. Esta componente, tem de ser inferior à velocidade máxima vertical suportada pelo veículo. Assim sendo, se for superior à velocidade vertical máxima do veículo, através da API é indicada uma nova velocidade máxima horizontal do veículo para que, a sua componente vertical permaneça dentro dos limites estabelecidos. Caso a componente vertical se encontre


57

dentro dos parâmetros do veículo, aí a velocidade indicada ao simulador é a velocidade máxima horizontal que o veículo pode atingir quando submerso

A Figura 60 exemplifica a componente horizontal e vertical da velocidade do veículo sendo que a velocidade máxima do veículo é diminuída se a velocidade vertical for superior à suportada pelo veículo.

Figura 60 - Componente horizontal e vertical da velocidade do veículo.

Primeira Abordagem de Simulação Submarina Numa primeira abordagem, o cálculo para simular a profundidade efectuou-se de uma

maneira directa. A partir da latitude ou longitude do ponto de referência anterior e do ponto de referência

seguinte, calculou-se a equação reduzida da recta, na forma y=mx+b e com isso deduzimos a altitude do veículo no local que se encontra. A Figura 61 apresenta um exemplo de descida do submarino durante a execução de uma manobra.

Figura 61 - À esquerda, exemplo de uma manobra de um submarino e respectivos pontos de referência. À direita, exemplo da variação da altitude do submarino entre o

local de partida e o ponto de referência seguinte

Esta abordagem, contudo, tem um problema. No simulador, o veículo não precisa de passar necessariamente nos pontos de referência

que indicam a rota. O simulador atribui a cada ponto um raio de acção por onde o veículo tem de passar e não apenas no ponto com as coordenadas exactas, como demonstrado na Figura 62.

Por esse motivo, a abordagem utilizada, apesar de satisfatória, não era a ideal na medida que potenciava um maior erro pela localização actual do veículo poder não se encontrar na equação reduzida da recta e também pelo facto de por vezes o simulador indicar que se encontrava no waypoint seguinte apesar das coordenadas corresponderem ao ponto anterior. Na prática, podia fazer com que acontecessem algumas mudanças de altitude do veículo mais bruscas enquanto noutras situações, na mesma manobra, o veículo podia manter-se estável.


58

Para contornar esse potencial problema, utilizou-se a segunda abordagem, de forma a manter a altura mais fiel ao funcionamento normal de um veículo submergível.

Figura 62 - Demonstração dos pontos de referência e raio de acção considerado como ponto de referência pelo FSX

Segunda abordagem de Simulação Submarina Desta feita, em vez de apenas se usar o ponto de referência anterior e o actual, é usado

também o seguinte. Assim sendo, é calculada a equação da recta que passa pelo ponto de referência anterior (já ultrapassado pelo veículo) e o ponto de referência seguinte, recta A da Figura 63. A partir da recta A, é calculada a recta perpendicular, que intercepta o ponto de referência actual, recta B.

Para calcular a altura, é calculada agora a equação de uma nova recta, recta C, que é descrita entre o ponto de referência anterior e intersecta o local onde se encontra o veículo no momento. Esta recta, intercepta também a recta perpendicular calculada, recta B. Como é conhecida a altura que o veículo deve possuir no ponto de referência anterior e como sabemos a altura que o veículo deve possuir quando passa no ponto de referência actual (que por sua vez é a mesma da recta perpendicular, recta B), resolvendo a equação da recta em ordem à altura obtemos a altura do veículo no instante que ele se encontra. A Figura 63 apresenta de forma esquemática as rectas e pontos calculados nesta abordagem.

Figura 63 - Gráfico de cálculo da altura do veículo na posição em que se encontra pelo segundo método de resolução

No caso de, devido ao raio de acção dos pontos de referência, o ponto de referência considerado pelo simulador como sendo o actual na realidade já ser o seguinte na medida que o


59

veículo ainda se encontrar entre dois pontos de referência anteriores, este procedimento é novamente efectuado utilizando os pontos de referência anteriores para cálculo do declive da recta e respectiva altura, eliminando possíveis erros, que contudo seriam menores, como exemplificado na Figura 64.

Todo este procedimento é utilizado para todos os instantes que são requisitadas as coordenadas ao simulador, passando assim a existir as coordenadas completas do veículo, seja em latitude, longitude e altitude (profundidade), que são guardadas pelo sistema e, portanto, obtêm-se uma simulação completa dos veículos submergíveis.

Figura 64 - Possibilidade do veículo ainda se encontrar a caminho do ponto de referência 1 (wp1) mas devido a ter entrado no raio de acção wp1, o simulador

considera que o veículo já se encontra a caminho de wp2

Para demonstrar o funcionamento dos novos veículos, é apresentada nas figuras 65 e 66 a rota efectuada por um veículo submergível. Na Figura 65, é apresentada a rota visualizada do topo, como se estivéssemos num avião a olhar na vertical para baixo a visualizar o submarino a manobrar e, como tal, não dá para identificar a profundidade a que ele se encontra.

Na Figura 66, é mostrada a rota do mesmo veículo na mesma manobra mas em perspectiva. Desta forma, podemos acompanhar a profundidade a que o submergível se encontra ao longo da sua trajectória. Podemos verificar que o veículo começa na superfície e navega durante algum tempo na superfície até que começa a submergir. Pode-se verificar que nesta manobra o submarino efectuava uma curva ligeira ao mesmo tempo que submergia a uma velocidade constante.

Todavia, esta abordagem não consegue responder a um caso específico, a possibilidade de haver pedidos de deslocamento exclusivamente verticais.

Tratando-se de uma manobra submersa, também esta tem de ser simulada. A abordagem utilizada para resolver este caso, passou então por simular o deslocamento na vertical do submarino, garantindo que esse deslocamento se encontra dentro dos parâmetros técnicos do mesmo.

Assim, quando é dada a indicação para o submarino se deslocar para uma posição que se encontra imediatamente abaixo da sua posição actual, é iniciado um processo de descida do veículo. É calculada a distância entre o local actual do submarino e o local de destino e procede-se ao deslocamento do veículo na vertical, que é efectuado a uma velocidade não superior à suportada pelo veículo e, como tal, a duração da manobra dependerá de dois factores, das características do submarino que está a operar e da profundidade a que se pretende atingir.


60

Figura 65 – Vista de topo do percurso efectuado por um submarino

Figura 66 – Vista em perspectiva do percurso efectuado pelo submarino

Esta abordagem é utilizada tanto para manobras verticais descendentes como para manobras verticais ascendentes.


61

4.4 Resumo

Procedeu-se à extensão das linguagens de cenário e de equipas, de forma a ser possível incluir novos tipos de veículos e, assim, permitir que estes sejam configuráveis e integrados no simulador FSX. Em anexo pode ser consultado um exemplo da linguagem SDL e outro exemplo da linguagem TDL. Para veículos submergíveis é, adicionalmente, implementado um sistema de simulação de utilização submersa que interage directamente com o FSX de forma garantir que, apesar de este último não suportar qualquer tipo de operação submersa de forma nativa, estes possam ser usados, consoante as suas especificações técnicas.

62

5 – Análise de Desempenho

A segunda componente do trabalho destina-se à análise de desempenho dos veículos em missões conjuntas.

Dado já se terem desenvolvido os novos tipos de veículos e estes já poderem ser utilizados em missões conjuntas, é possível desenvolver a aplicação de análise de desempenho.

A análise de desempenho tem de preencher alguns requisitos essenciais, a saber: • Analisar desempenho de um veículo • Analisar desempenho de uma equipa de veículos • Possibilidade de comparar desempenho de várias simulações Para responder a estes requisitos, foi planeada e implementada uma aplicação que permite

responder a estes e a outros desafios. Assim sendo, a aplicação além de analisar o desempenho, seja de um veículo ou de uma

missão, deve ser dinâmica no tipo de dados e de veículos a usar, no tipo de métricas a utilizar/desenvolver e que disponha de ferramentas de configuração de análise multi-atributo adaptáveis pelo utilizador à situação que se pretende analisar.

5.1 Missão

O conceito missão é usado como sendo o tipo de tarefa que um veículo ou uma equipa executa. Isto significa que durante uma simulação, uma equipa pode executar diferentes tipos de missões ou pode mesmo acontecer que um veículo, durante a simulação pode ele mesmo executar diferentes tipos de missões.

Um exemplo prático, esquematizado na Figura 67, é a possibilidade de se encontrarem simulações em que um veículo terrestre (veículo 4) começa por fazer procura de um foco de incêndio (missão 3), encontra-o e a partir desse momento passa a combater o incêndio (missão2). No caso da equipa ter mais veículos, que comunicam entre si, é possível que outros veículos venham ajudar a combater o incêndio e outros continuem a efectuar as tarefas a que estavam afectos, podendo ou não ser missões de procura e combate a incêndio.

Figura 67 – Exemplo esquemático de uma simulação em relação ao tempo. Caveículo pode executar várias missões na mesma simulação

Este conceito de missão tem es

as métricas a utilizar dependem do tipo de missão que por sua vez vai sendo alterado ao longo do tempo.

No âmbito do projecto global, existem já uma série de missões que podem ser executadas, a saber:

• Missão de Procura, seja de uma pessoa, um incêndio ou outra entidade.• Missão de Detecção, seja de um tipo de gradiente de um foco de poluição ou de outro

tipo de detecção. • Missão de seguir um veículo ou uma pessoa.• Missão de descarga de carga, como por exemplo, descarga de água sobre um incêndio.• Missão de transporte de uma carga de um local para outro.• Missão de análise ao longo de uma área, como por exemplo, verifi

poluição do ar.

5.2 Métricas

As métricas são as componentes de avaliação de perfis, que são analisados na secção seguinte, também as métricas têm funções de avaliação consoante se esteja a avaliar um veículo

As métricas além de serem as componentes de avaliação, é também a elas que são atribuídos pesos, lhe atribuímos qual a importância relativa no cálculo da função de avaliação final de uma missão.

Para tornar a aplicação a mais dinâmica possívperfil seguem uma escala de 0 (sem importância) até 100 (muito importante). Esta escala é utilizada quantitativamente consoante a importância relativa da métrica em questão.

Num cenário em que existe um perfil de exemplo, gasto de gasolina, velocidade e carga, se se entende que as três métricas são muito importantes para a análise, então podem atribuir às três um peso de 100. Na prática, o sistema, a partir desta análise quantitativa, atribuí a cada uma das componentes uma importância de 33,33%. Desta forma, mesmo que o utilizador pretenda adicionar ou eliminar uma das métricas ao perfil, o cálculo da importância relativa de cada métrica é efectuado automaticamente.

De forma a facilitar a análise dos dados, são representados os dados tanto de cada uma das métricas, assim como o somatório total das métricas consoante o peso relativo de cada uma, tornando assim a análise de cada componente em avaliação e do desempenho geral maiperceber e com isso, mais fácil de, a partir destes dados, se retirarem elações e efectuaremmelhorias nos algoritmos dos veículos.

Quanto ao tipo de função de utilidade de cada métrica, e tal como já referido, há dois tipos que são propostos. Métricas para veículos e métricas de avaliação de equipas.

Análise de Desempenho

63

Exemplo esquemático de uma simulação em relação ao tempo. Caveículo pode executar várias missões na mesma simulação

Este conceito de missão tem especial relevância no cálculo do desempenho as métricas a utilizar dependem do tipo de missão que por sua vez vai sendo alterado ao longo

bito do projecto global, existem já uma série de missões que podem ser executadas,

Missão de Procura, seja de uma pessoa, um incêndio ou outra entidade.Missão de Detecção, seja de um tipo de gradiente de um foco de poluição ou de outro

Missão de seguir um veículo ou uma pessoa. Missão de descarga de carga, como por exemplo, descarga de água sobre um incêndio.Missão de transporte de uma carga de um local para outro. Missão de análise ao longo de uma área, como por exemplo, verifi

As métricas são as componentes de avaliação de desempenho. Tal como acontece nos perfis, que são analisados na secção seguinte, também as métricas têm funções de avaliação consoante se esteja a avaliar um veículo ou uma equipa.

As métricas além de serem as componentes de avaliação, é também a elas que são atribuídos pesos, lhe atribuímos qual a importância relativa no cálculo da função de avaliação

r a aplicação a mais dinâmica possível, os pesos a atribuir a cada métrica num perfil seguem uma escala de 0 (sem importância) até 100 (muito importante). Esta escala é utilizada quantitativamente consoante a importância relativa da métrica em questão.

Num cenário em que existe um perfil de avaliação composto por três métricas, por exemplo, gasto de gasolina, velocidade e carga, se se entende que as três métricas são muito importantes para a análise, então podem atribuir às três um peso de 100. Na prática, o sistema, a

antitativa, atribuí a cada uma das componentes uma importância de 33,33%. Desta forma, mesmo que o utilizador pretenda adicionar ou eliminar uma das métricas ao perfil, o cálculo da importância relativa de cada métrica é efectuado automaticamente.

a facilitar a análise dos dados, são representados os dados tanto de cada uma das métricas, assim como o somatório total das métricas consoante o peso relativo de cada uma, tornando assim a análise de cada componente em avaliação e do desempenho geral maiperceber e com isso, mais fácil de, a partir destes dados, se retirarem elações e efectuaremmelhorias nos algoritmos dos veículos.

Quanto ao tipo de função de utilidade de cada métrica, e tal como já referido, há dois tipos . Métricas para veículos e métricas de avaliação de equipas.

Exemplo esquemático de uma simulação em relação ao tempo. Cada veículo pode executar várias missões na mesma simulação

pecial relevância no cálculo do desempenho na medida que as métricas a utilizar dependem do tipo de missão que por sua vez vai sendo alterado ao longo

bito do projecto global, existem já uma série de missões que podem ser executadas,

Missão de Procura, seja de uma pessoa, um incêndio ou outra entidade. Missão de Detecção, seja de um tipo de gradiente de um foco de poluição ou de outro

Missão de descarga de carga, como por exemplo, descarga de água sobre um incêndio.

Missão de análise ao longo de uma área, como por exemplo, verificar níveis de

. Tal como acontece nos perfis, que são analisados na secção seguinte, também as métricas têm funções de avaliação

As métricas além de serem as componentes de avaliação, é também a elas que são atribuídos pesos, lhe atribuímos qual a importância relativa no cálculo da função de avaliação

, os pesos a atribuir a cada métrica num perfil seguem uma escala de 0 (sem importância) até 100 (muito importante). Esta escala é utilizada quantitativamente consoante a importância relativa da métrica em questão.

avaliação composto por três métricas, por exemplo, gasto de gasolina, velocidade e carga, se se entende que as três métricas são muito importantes para a análise, então podem atribuir às três um peso de 100. Na prática, o sistema, a

antitativa, atribuí a cada uma das componentes uma importância de 33,33%. Desta forma, mesmo que o utilizador pretenda adicionar ou eliminar uma das métricas ao perfil, o cálculo da importância relativa de cada métrica é efectuado automaticamente.

a facilitar a análise dos dados, são representados os dados tanto de cada uma das métricas, assim como o somatório total das métricas consoante o peso relativo de cada uma, tornando assim a análise de cada componente em avaliação e do desempenho geral mais fácil de perceber e com isso, mais fácil de, a partir destes dados, se retirarem elações e efectuarem-se

Quanto ao tipo de função de utilidade de cada métrica, e tal como já referido, há dois tipos . Métricas para veículos e métricas de avaliação de equipas.


64

Dado que um dos requisitos é a não inclusão de algum tipo de conhecimento a não ser o existente nos logs dos veículos durante a execução, todas as métricas têm de ser calculadas sem qualquer base de dados pré-concebida. Para as definir, é necessário utilizar técnicas de análise exploratória de dados, detectando aqueles que nos são mais relevantes.

Por esse motivo, genericamente, as funções de desempenho utilizadas na avaliação de desempenho são de análise da variação de desempenho de determinada métrica ao longo da simulação.

As métricas implementadas para avaliação de veículos de forma individual são, entre outras:

• Consumo de combustível - Demonstra a variação ao longo do tempo do consumo efectuado pelo veículo. É verificado se o veículo durante o tempo de funcionamento tem ou não um desempenho próximo do ideal.

• Espaço percorrido - Numa missão de procura/detecção, é relevante verificar se o veículo efectua trabalho útil, ou seja, se procura uma grande área. Neste caso, não só a velocidade interessa mas também se a área procurada pelo veículo são áreas novas ou repetidas. Quanto menos vezes o veículo passar no mesmo local, melhor é o seu desempenho de procura, por exemplo, de um foco de incêndio ou uma pessoa.

• Velocidade – Verifica a variação da velocidade ao longo da missão e o quanto o veículo se desloca abaixo da sua possibilidade

• Tempo de funcionamento útil – é verificado se o veículo esteve o máximo de tempo possível a executar realmente missões ou se por avaria ou impossibilidade técnica, esteve demasiado tempo inoperacional/sem efectuar trabalho útil.

Quanto às métricas de avaliação de equipa são algo diferentes, no geral, não são apenas a soma das partes dos veículos intervenientes. Ressalta-se, em parte, o caso da métrica de procura/detecção, é verificado se todos os veículos com essa missão distribuem o espaço a pesquisar sem haver trabalho repetido.

No caso de análises de desempenho efectuadas envolvendo os vários veículos da equipa, foram implementadas outras métricas:

• Consumo de combustível - neste caso a avaliação do consumo é efectuada comparativamente com os restantes veículos da equipa ou mesmo de outras equipas (quando se pretende uma avaliação multi-equipa)

• Consumo de combustível vs carga transportada - Para análise de desempenho de um problema de transportes pode não ser apenas importante o consumo de combustível mas também a capacidade de carga. Por exemplo, um veículo pode consumir cinco litros de combustível para percorrer cem quilómetros e pode transportar carga até dez quilogramas e outro, para a mesma distância, vinte litros mas pode transportar duzentos quilogramas. Para o transporte de uma tonelada de carga, torna-se importante não apenas o consumo mas sim o rácio entre consumo e aquilo que pode transportar.

• Área percorrida – é efectuada uma análise à área percorrida pelos elementos da equipa e verificado se os diferentes veículos não fazem trabalho repetido.

5.3 Perfil

Devido à variedade de tipos de análise que se podem efectuar, procedeu-se à definição do Perfil de avaliação. O Perfil de avaliação é um agregado de métricas que se podem utilizar para avaliar missões.

O Perfil tem duas características essenciais. Por um lado é composto por um conjunto de métricas, cada uma com um peso de avaliação próprio. Por outro, não estando as métricas associadas directamente ao tipo de missão a avaliar, é possível, para o mesmo tipo de missão, utilizar-se diferentes tipos de peso de avaliação das métricas ou mesmo utilizar diferentes métricas e diferentes pesos de métricas para avaliar o mesmo tipo de missão.


65

Além de tornar a aplicação mais dinâmica e mais configurável, estas possibilidades têm especial importância na análise de desempenho pois torna-se possível avaliar a mesma missão com diferentes funções de utilidade, escolhidas para melhorar o desempenho dos agentes para determinado fim/especificidade.

Um exemplo prático das possibilidades oferecidas pelo perfil pode ser demonstrado por uma missão de procura de um foco de incêndio. Para essa missão podem existir vários perfis criados que apesar de conter as mesmas métricas, os pesos diferentes adaptam-se consoante o que se pretende. No caso do combustível, um perfil pode dar uma importância muito relevante ao consumo de combustível efectuado pelos veículos enquanto utilizando o outro perfil o consumo de combustível é menosprezado. Os resultados são, então, diferentes o que permite que analisando os dados se consiga optimizar os agentes de forma a tirarem mais partido de uma determinada métrica que outra num caso e noutro caso tire mais partido de outra métrica.

Em termos de perfis, é necessária a definição de dois tipos distintos de perfis de avaliação, tal como de métricas. Os perfis de avaliação para um veículo e o perfil de avaliação para avaliação de equipas de veículos.

Isto deve-se ao facto das funções de avaliação, consoante se está a avaliar um veículo ou uma equipa poderem ser diferentes, não sendo a avaliação das equipas por isso apenas o somatório das partes envolvidas.

5.4 Aplicação

Os dados a analisar são obtidos através de ficheiros com informação estruturada, gerada pelos veículos aéreos, terrestres, marítimos e submergíveis.

Para cada simulação efectuada por uma equipa de veículos, é criada uma pasta onde são armazenados todos os ficheiros de log produzidos na mesma, ou seja, todos os ficheiros produzidos por todos os veículos intervenientes (ver Figura 68). Deve-se notar que durante a simulação efectuada, um veículo pode efectuar vários tipos de tarefas/missões. Por exemplo, um veículo terrestre pode efectuar, durante uma simulação, uma missão de procura e outra missão de salvamento.

Figura 68 – Cada simulação efectuada regista os logs dentro de uma pasta específica

Na aplicação, após seleccionada a pasta que contém todos os dados de uma determinada simulação, todos os dados são imediatamente carregados.

Após carregados, as potencialidades do sistema passam a estar disponíveis. Torna-se possível efectuar as análises de desempenho pretendidas, sejam elas a uma determinada equipa ou a um conjunto de equipas, a um veículo de uma equipa.

Uma das características dinâmicas da aplicação é verificada pela possibilidade de adição de novas métricas de avaliação, seja métricas de avaliação de veículos, seja métricas de avaliação de equipas através da aplicação. Para tal, no menu de configurações, é possível fazê-lo, atribuindo um nome à métrica, um nome de função da métrica e o tipo de métrica que se trata (veículos ou equipas). Cada métrica tem uma função de avaliação associada sendo que as funções de avaliação têm um formato comum de argumentos. Significa que, além das funções de avaliação construídas neste trabalho, é possível acrescentar novas bastando para tal


66

acrescentar o algoritmo pretendido ao programa, sem ser necessário alterar mais nenhuma parte da aplicação. No caso de funções já inutilizadas ou em caso de erro, é possível também eliminar funções existentes no sistema. A Figura 69 apresenta a interface principal da aplicação, onde se podem efectuar as configurações descritas.

Figura 69 – Interface principal da aplicação da Análise de Performance

Na interface principal da aplicação, após carregar os dados, uma das primeiras acções a efectuar é a configuração dos tipos de missões. São listados os vários tipos de missões existentes e após seleccionar a que pretendemos configurar, abre-se um novo menu de configuração da missão. Aí, para uma missão podemos criar ou eliminar perfis. Como anteriormente foi referido, o perfil é associado a um tipo de avaliação, a um veículo ou a uma equipa. Após criado o perfil, é possível editar todo o seu conteúdo. A partir das opções disponibilizadas, é possível adicionar ao perfil novas métricas de avaliação. É apresentada uma lista de métricas disponíveis para o perfil que podem ser adicionadas ao perfil. Por outro lado, é possível também remover do perfil métricas que haviam sido adicionadas mas que não são necessárias. O utilizador pode então atribuir os pesos a cada umas das métricas pertencentes ao perfil em avaliação. Como referido, os pesos são uma avaliação quantitativa numa escala de 0 – 100. Após guardar as alterações, é possível adicionar e remover novos perfis à missão. O utilizador pode e deve efectuar esta configuração para todos os tipos de missões existentes nos logs carregados através da interface demonstrada na Figura 70.

No menu de configuração principal, o utilizador tem a possibilidade de seleccionar o tipo de análise que pretende fazer, se ao veículo, se à equipa, se a várias equipas. No caso de ser a várias equipas, selecciona as que pretende na checklist que é criada dinamicamente e que contém todas as simulações carregadas. A forma de carregamento de simulações é igual, seja para carregar uma, seja para carregar n simulações.

Caso contrário, selecciona apenas a equipa que pretende analisar e no caso de querer analisar o desempenho de um veículo em específico, deve seleccionar o veículo a analisar.

Finalmente, a última configuração a efectuar são a escolha dos perfis a utilizar na avaliação. Para isso, são listadas todas os tipos de missões existentes, dinamicamente, e para cada um o utilizador selecciona qual dos perfis, configurados anteriormente, deseja utilizar para efectuar a avaliação.

Após todas estas configurações, dá-se o pedido de efectuar o cálculo das estatísticas do sistema.


67

Figura 70 – Interface de configuração de Métricas pertencentes à avaliação de uma Missão

As estatísticas são dispostas, para cada métrica, em gráficos de percentagem de utilidade em função do tempo e qual a percentagem de utilidade conseguida por cada métrica. O último gráfico corresponde à agregação do desempenho das várias métricas com os seus pesos respectivos, ao mesmo tempo que é classificada, no geral, o desempenho final de toda a simulação. A Figura 71 demonstra um exemplo bastante simples, com apenas duas métricas em análise e o gráfico referente à agregação de todas as métricas intervenientes. Como se pode observar pelo gráfico agregado, o peso das duas métricas neste exemplo é equivalente.

Com esta aplicação dinâmica e configurável, torna-se possível efectuar a análise de desempenho de qualquer simulação efectuada. Isso, e com a apresentação dos gráficos em função do tempo de execução tanto das métricas como da função de avaliação final, permite uma análise pormenorizada e cuidada da simulação e com isso, torna-se possível estudar e implementar melhorias nos agentes que controlam os veículos de forma a melhorarem a qualidade de simulação e a rapidez de atingir os seus objectivos.

Figura 71 – Interface dinâmica de estatísticas


68

5.6 Resumo

Desenvolveu-se uma aplicação dinâmica e extensível que permite carregar logs de execução de veículos e condições de cenário e a partir dos mesmos efectuar uma análise de desempenho de forma a perceber quais os aspectos que podem ser melhorados na execução de missões. Foram também desenvolvidas métricas de análise de desempenho para um grupo de missões restrito mas a aplicação suporta a inclusão de novas métricas para análise de desempenho de missões não abordadas sem necessitar de alterar a sua arquitectura.

69

6 – Conclusões e Trabalho Futuro

Neste capítulo pretende-se apresentar a apreciação final e global da satisfação dos objectivos propostos para o projecto assim como as principais direcções e recomendações para trabalho futuro.

6.1 Satisfação dos Objectivos

Neste trabalho pretende-se então adaptar novos veículos ao simulador Flight Simulator X para torná-lo numa plataforma de veículos heterogéneos capaz de executar diversos tipos de missões conjuntas (por exemplo, missões de busca e salvamento) e, posteriormente, a partir dos dados recolhidos durante as missões, efectuar uma análise de desempenho dos agentes.

O projecto foi inicializado com uma familiarização do projecto global a que este trabalho se encontra inserido, dando sobretudo ênfase ao objectivo final pretendido neste trabalho. Esta componente foi conseguida, sobretudo, através de documentação já efectuada no âmbito do projecto global e com reuniões com a respectiva equipa de análise e desenvolvimento dos restantes módulos. Esta fase permitiu uma melhor integração na equipa de trabalho. Posto isto, procedeu-se ao estudo do Estado da Arte sobre a problemática em questão e pormenorizou-se a arquitectura dos módulos a desenvolver.

Foi sobretudo nesta fase que se completou todo o conhecimento necessário à adaptação dos novos veículos na medida que foi necessário estudar e compreender o funcionamento dos veículos para efectuar a construção das linguagens SDL e TDL, essenciais à integração dos veículos no simulador FSX. Já durante a integração dos novos veículos no simulador são verificadas com exactidão algumas das limitações inerentes ao facto do simulador ser um simulador de voo e não de veículos terrestres, marítimos e submergíveis, nomeadamente ao nível da navegação submersa e de outras limitações menores que foram sendo ultrapassadas, permitindo, chegando a esta parte, a apresentação de uma solução funcional de um simulador que permite o funcionamento de vários tipos de veículos.

Chegado a este ponto, é possível manobrar sobre a plataforma FSX, além dos veículos nativos do simulador, veículos terrestres, marítimos e submergíveis que têm características físicas e de desempenho correspondentes aos veículos reais que estão a simular e têm um comportamento tal como estes. As características físicas e de desempenho dos vários veículos podem ser facilmente configuradas pelo utilizador antes de se efectuar uma simulação com os mesmos.

Conclusões e Trabalho Futuro

70

No âmbito da análise de desempenho, tomou-se consciência da importância de avaliar algoritmos de controlo de veículo (desenvolvidos no âmbito do projecto global e que são usados para os vários tipos de veículos, sejam eles aéreos, terrestres, marítimos e submergíveis).

Assim sendo, foi efectuado o estudo das formas de avaliação de tarefas e apresentada uma arquitectura que respondesse ao problema. Procedeu-se assim, não apenas à implementação de uma aplicação estática e apenas focada na análise de desempenho dos casos restritos em análise mas sim de uma aplicação que respondesse aos desafios propostos, nomeadamente à análise de desempenho das missões em estudo neste projecto mas que permitisse a inclusão de novos tipos de análise para futuros desafios. Optou-se também por uma ferramenta configurável ao nível de funções de avaliação de desempenho, não propondo assim uma solução óptima única mas sim uma solução que indicasse os resultados de desempenho consoante as necessidades específicas de cada caso em estudo. Esta solução, permite visualizar de uma forma gráfica o desempenho dos agentes ao longo do tempo de simulação, conseguindo a partir daí perceber quais os instantes que os veículos possuem desempenhos óptimos/melhores assim como os instantes que os veículos possuem desempenhos inferiores. Esta análise torna-se bastante relevante pois de uma forma simples permite perceber quais os aspectos que devem ser melhorados de forma a melhor o desempenho geral dos veículos e das equipas.

Com isto, os objectivos que inicialmente foram propostos foram cumpridos, dado que foram projectadas e desenvolvidas duas soluções funcionais, ao nível de integração de novos veículos e ao nível da análise de desempenho, que respondem às necessidades encontradas.

6.2 Trabalho Futuro

Esta área de trabalho é bastante propícia a constantes melhorias e optimizações do trabalho efectuado, no entanto há certos aspectos que podem ser enumerados para trabalho futuro dado que não puderam ser abordados neste projecto.

No que concerne à adaptação de veículos, um trabalho a efectuar consiste na construção de modelos visuais para veículos, principalmente submergíveis dado que não existem modelos para estes.

Na área de simulação submersa, como demonstrado anteriormente, o simulador FSX possui várias limitações dado não ter sido projectado com esse propósito. Uma delas, é relativa ao facto de não possuir cenário descrito debaixo de água, o que obrigou a simular a navegação submersa. Apesar da simulação funcionar correctamente, não é possível obter informação relativa à profundidade real do rio/mar/oceano (o único limite de profundidade são as características/limitações do veículo). Um dos possíveis desenvolvimentos futuros poderá ser da adaptação do simulador de forma a também existir descrição do fundo do mar, nomeadamente da profundidade existente, tornando a simulação submersa mais próxima da realidade. Uma das possibilidades poderá passar pela utilização da API The Google Elevation API[48], uma ferramenta que possibilita a consulta da altura de qualquer localização da face da terra, inclusivamente do fundo do mar/oceano, podendo dessa forma colmatar a falha do FSX, incrementando mais realismo à aplicação.

Outros desenvolvimentos podem ser efectuados no campo do desenvolvimento de novos tipos de veículos, nomeadamente de veículos anfíbios, veículos terrestres e submergíveis ou outros tipos de veículos.

No campo da análise de desempenho, existe a possibilidade de desenvolvimento de novas métricas para adicionar à aplicação desenvolvida, sejam elas mais optimizadas para avaliação das missões existentes, sejam novas métricas para actuais ou futuras missões ou mesmo desenvolvimento de métricas na área da inteligência artificial, dado que esta é uma área com muito potencial de desenvolvimento. Outro dos aspectos a desenvolver futuramente consiste na interpretação dos valores da aplicação de desempenho pelos agentes de controlo de veículo. Neste trabalho, é apresentada uma solução que calcula o desempenho dos veículos nas missões

Conclusões e Trabalho Futuro

71

efectuadas e demonstra, temporalmente, o comportamento do veículo ao longo do tempo, sendo que o desenvolvedor tem de analisar os dados apresentados e experimentar soluções. O desenvolvimento futuro consiste no estudo e adaptação de uma extensão à ferramenta que permita, automaticamente, analisar os dados e verificar o porquê das variações de desempenho, permitindo a que os agentes de controlo de veículo aprendam autonomamente com a análise de desempenho efectuada.

Também no campo da análise de desempenho, uma outra possibilidade de desenvolvimento futuro pode passar pelo desenvolvimento de uma solução online que permita aprender e melhorar com as missões já analisadas mas também com as que se encontram em execução. Uma solução deste tipo poderia até fomentar mais a utilização da plataforma por uma comunidade de investigadores mais abrangente, havendo assim mais desenvolvimentos na área, mais análises de desempenho efectuadas e, portanto, proporcionando desenvolvimento mais rápido e optimizado da análise de desempenho existente.

72

Referências

1. DARPA. Urban Challenge. DARPA - Defense Advanced Research Projects Agency 2007 Novembro [consultado em 2010, Janeiro]; Disponível em: http://www.darpa.mil/grandchallenge/index.asp.

2. Department of Defense, Unmanned Aircraft Systems Roadmap 2005-2030. 2005, EUA: Department of Defense - Office of the Secretary of Defense.

3. M. Woodridge, An Introduction to Multi Agent Systems. 2002, UK: John Wiley & Sons, Ltd.

4. M. Woodridge and N.R. Jennings, Intelligent Agents Theory and Practice. Vol. 10. 1995, UK: Knowledge Engineering Review.

5. B. Hayes-roth, Architecture for Adaptive Intelligent Systems. Artificial Intelligence. Vol. 72. 1995, UK: Elsevier Science Publishers Ltd. 329 - 365.

6. H.S. Nwana, Software Agents: An Overview. Vol. 11. 1996, UK: Knowledge Engineering Review.

7. S. Russel and P. Norvig, Artificial Intelligence – A Modern Approach. 2003, EUA: Prentice Hall.

8. M.J. Woodridge and N.R. Jennings, Agent Theories, Architectures, and Languages: A Survey. 1995, Holanda: Proceedings of the workshop on agent theories, architectures, and languages on Intelligent agents.

9. A. Rao and M. Georgeff, Modeling Rational Agents within a BDI Architecture, ed. R.i. agents. 1991, EUA: Proceedings of the 2nd International Conference on Principles of Knowledge Representation and Reasoning (KR'91). 317-328.

10. 3D Driving School. 3D Driving School Infos 2001 [consultado em 2009, Novembro]; 3D-Fahrschule:Disponível em: http://www.3dfahrschule.de/uk_infos.htm.

11. Euro Truck Simulator. Euro Truck Simulator 2007 [consultado em 2009, Dezembro]; SCS Software:Disponível em: http://www.eurotrucksimulator.com/.

12. Ship Simulator 2008 Features. Ship Simulator 2008 2008 [consultado em 2009, Dezembro]; VSTEP:Disponível em: http://www.shipsim.com.

13. Ship Simulator Professional v2.0. Ship Simulator Professional v2.0 2008 [consultado em 2009, Dezembro]; VSTEP:Disponível em: http://www.shipsimpro.com/.

14. J. Leitão, Agentes Autónomos Controláveis. 2000, PT: FEUP - Tese de Doutoramento. 15. VTI's simulator. VTI Swedish National Road and Transport Research Institute

2010[consultado em 2010, Fevereiro]; Disponível em: http://www.vti.se/templates/Page____11865.aspx.

16. K. Yoshimoto and T. Suetomi, The history of research and development of driving simulators in japan, ed. S.i.o.D.S. Conference-Asia/Pacific. Vol. 1 (2). 2008: Journal of Mechanical Systems for Transportation and Logistics. 159-169.

17. C. Schwarz, T. Gates, and Y. Papelis, Motion Characteristics of the National Advanced Driving Simulator, ed. D.S.C.N.A. Proceedings. 2003.

Referências

73

18. Toyota, M.C. Toyota Develops World-class Driving Simulator. 2007 [consultado em 2010, Fevereiro]; Disponível em: http://www.toyota.co.jp/en/news/07/1126_1.html.

19. J. Hedrick, A. Girard, and S. Spry, Intelligent Cruise-control Applications: Real-time, Embedded Hybrid Control Software. Vol. 12 (1). 2005, EUA: IEEE Robotics and Automation Magazine.

20. J.C. Bebel, N. Howard, and T. Patel, An Autonomous System Used in the DARPA. 2004, USA: Proceedings. The 7th International IEEE Conference on Intelligent Transportation Systems. 487-490.

21. Yuh, J., Design and Control of Autonomous Underwater Robots: A survey. Autonomous Robots. Vol. 8 (1). 2000: Kluwer Academic Publishers. 7-24.

22. N. Lau, A. Pereira, A. Melo, A. Neves, J. Figueiredo, Ciber-Rato: Um Ambiente de Simulação de Robots Móveis e Autónomos. Rev. DETUA. Vol. 3 (7). 2002. 647-650.

23. S. Carpin, M. Lewis, J. Wang, S. Balakirsky, C. Scrapper, USARSim: a robot simulator for research and education, ed. I.I.C. Robotics and Automation. 2007. 1400 - 1405.

24. L. Hugues, N. Bredeche, and T. Futurs, Simbad: an Autonomous Robot Simulation Package for Education and Research. in Proceedings of The Ninth International Conference on the Simulation of Adaptive Behavior (SAB'06). Roma, Italy - Springer's Lecture Notes in Computer Sciences / Artificial Intelligence series (LNCS/LNAI). 2006. 831-842.

25. J. Jackson, Microsoft robotics studio: A technical introduction, ed. I. Robotics & Automation Magazine. Vol. 14 (4). 2007. 82-87.

26. R. Arkin. MissionLab v7.0. 2006 [consultado em 2010, Março]; Disponível em: http://www.cc.gatech.edu/ai/robot-lab/research/MissionLab/.

27. MathWorks. Simulink 3D Animation. 2009 [consultado em 2010, Março]; Disponível em: http://www.mathworks.com/products/3d-animation/index.html.

28. A. Boeing and T. Bräunl, SubSim: An autonomous underwater vehicle simulation package. Proceedings of the 3rd International Symposium on Autonomous Minirobots for Research and Edutainment (AMiRE 2005). 2006: Springer Berlin Heidelberg. 33-38.

29. L.C. Lee, H.S. Nwana, D.T. Ndumu, P. De Wilde, The Stability, Scalability and Performance of Multi-agent Systems. BT Technology Journal, ed. B.T. Journal. Vol. 16 (3). 1998: Kluwer Academic Publishers. 94-103.

30. H. Kargupta, I. Hamzaoglu, and B. Stafford, Scalable, Distributed Data Mining Using An Agent Based Architecture. a, ed. P.t.T.I.C.o.t.K.D.a.D. Mining. 1997: Proceedings of High Performance Computing. 211-214.

31. K. Hallenborg, Core Design Pattern For Efficient Multi-Agent. 2004: Advanced Studies in Software and Knowledge Engineering. 29-36.

32. M. Hornick, Data Mining Agents for Efficient Hardware Utilization. Vol. 20. 2006, Alemanha: Informatik Forschung und Entwicklung

33. N.K.Nagwani, Performance Measurement Analysis for Multi-agent Systems. 2009, EUA: International Conference on Intelligent Agent & Multi-Agent Systems. 1-4.

34. S. D'Amours, J.M. Frayret, and J. Gaudreault, Study of the Performance of Multi-behaviour Agents for Supply Chain Planning. 2009, Holanda: Computers in Industry 60 (9). 698-708.

35. A. Sobotka, Multi-Attribute Analysis for the Eco-Energetic. 2009: Technological and Economic Development Of Economy 15 (4). 593-611.

36. R. Gimenes, D.C. Silva, L.P. Reis, E. Oliveira, Using Flight Simulation Environments with Agent-Controlled UAVs. 2008: p. 21-26.

37. Microsoft. Microsoft Flight Simulator - Developers' Corner. Microsoft Flight Simulator 2008 [consultado em 2009, Novembro]; Disponível em: http://www.microsoft.com/Products/Games/FSInsider/developers/Pages/default.aspx.

Referências

74

38. Microsoft. ESP SDK Overview. Microsoft MSDN 2008 [consultado em 2009, Novembro]; Disponível em: http://msdn.microsoft.com/en-us/library/cc526948.aspx.

39. jSimConnect. jSimConnect Web Site. 2007 [consultado em 2010, Janeiro]; Disponível em: http://lc0277.nerim.net/wiki/index.php?jsimconnect.

40. X-Plane. X-Plane 2007 [consultado em 2009, Dezembro]; Laminar Research Disponível em: http://www.x-plane.com./.

41. Flight Gear Flight Simulator. Flight Gear Flight Simulator 2007 [consultado em 2009, Dezembro]; Disponível em: http://www.flightgear.org/.

42. Cloud Cap Technology. Piccolo system software. Piccolo system software 2007 [consultado em 2009, Novembro]; Disponível em: http://www.cloudcaptech.com/piccolo_system.shtm.

43. D.C. Silva, Dynamic Agent Coordination for Applications in Surveillance and Search & Rescue Operations. 2008.

44. D.C. Silva, L.P. Reis, and E. Oliveira, Flexible Scenario and Team Description Languages. 2010, Porto, Portugal: (Submetido para Publicação).

45. Microsoft. SimObject Container SDK Microsft MSDN 2010 [consultado em 2010, Março]; Disponível em: http://msdn.microsoft.com/en-us/library/cc527032%28v=MSDN.10%29.aspx.

46. Microsoft. Simulation Variables. Microsft MSDN 2008 [consultado em 2009, Novembro]; Disponível em: http://msdn.microsoft.com/en-us/library/cc526981.aspx.

47. Google. The Google Elevation API. 2010 [consultado em 2010, Junho]; Disponível em: http://code.google.com/apis/maps/documentation/elevation/#Introduction..

75

Anexo A: Exemplo de uma SDL

<?xml version="1.0" encoding="utf-8"?> <scenario xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="dcs:scenario"> <bases> <baseOfOperations id="b1"> <name>Base da Maia</name> <mobility water="true" underwater="false" land="true" air="true" />

<description>Small airfield, with one runway roughly N/S oriented, close to LPPR</description> <history>Created in 1983, it has been upgraded a few times in the past few years, providing it with a tower, some hangars, fuel, coffee</history>

<contactPerson> <name>Daniel Silva</name> <title>Mr.</title> <institution>FEUP / LIACC</institution> <position>Ph.D. Researcher</position> <address>Rua Street, 1234</address> <zipCode>4200-000</zipCode> <city>Gondomar</city> <stateDistrictRegion>Porto</stateDistrictRegion> <country>Portugal</country> <telephone>+351 123456789</telephone> <cellphone>+351 987654321</cellphone> <fax>+351 222345678</fax> <email>[email protected]</email> <additionalInformation name="preferredHours">12 to 18</additionalInformation> <additionalInformation name="timeZone">GMT</additionalInformation> </contactPerson> <location> <address>Vilar da Luz</address> <zipCode>4100-465</zipCode> <city>Maia</city> <stateDistrictRegion>Porto</stateDistrictRegion>

Exemplo de uma SDL

76

<country>Portugal</country> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> </location> <availability available="always"> </availability> <airport> <name>Maia Airfield</name> <description>Used for light traffic, flight schools, and by enthusiasts</description> <contactPerson> <name>Daniel Silva</name> <title>Mr.</title> <institution>FEUP / LIACC</institution> <position>Ph.D. Researcher</position> <address>Rua Street, 1234</address> <zipCode>4200-000</zipCode> <city>Gondomar</city> <stateDistrictRegion>Porto</stateDistrictRegion> <country>Portugal</country> <telephone>+351 123456789</telephone> <cellphone>+351 987654321</cellphone> <fax>+351 222345678</fax> <email>[email protected]</email> <additionalInformation name="preferredHours">12 to 18</additionalInformation> <additionalInformation name="timeZone">GMT</additionalInformation> </contactPerson> <location> <address>Vilar da Luz</address> <zipCode>4100-465</zipCode> <city>Maia</city> <stateDistrictRegion>Porto</stateDistrictRegion> <country>Portugal</country> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> </location> <ICAO>LPVL</ICAO> <IATA /> <magVar>-4.951</magVar> <runways> <runway id="r16-34"> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">668</altitude> </coordinates>

Exemplo de uma SDL

77

<length lengthUnit="Meter">1700</length> <width lengthUnit="Meter">30</width> <surface>Concrete</surface> <baseEnd> <designation>16</designation> <startpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo /> </startpoint> <heading headingType="True">140.04</heading> <endpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo /> </endpoint> </baseEnd> <reciprocalEnd> <designation>34</designation> <startpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo /> </startpoint> <heading headingType="True">320.04</heading> <endpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo /> </endpoint> </reciprocalEnd> </runway> </runways> <helipads> <helipad id="h01"> <designation>Helipad One</designation> <surface>Concrete</surface> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude>

Exemplo de uma SDL

78

<altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">3</radius> </helipad> </helipads> <taxiways> <taxiway id="x01"> <designation>Taxiway A</designation> <surface>Concrete</surface> <width lengthUnit="Foot">100</width> <path> <startpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo> <rway idr="r16-34" /> </connectsTo> </startpoint> <midpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo /> </midpoint> <midpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo> <xway idr="x01" /> </connectsTo> </midpoint> <midpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo> <xway idr="x01" /> </connectsTo> </midpoint> <endpoint> <coordinates> <latitude>41º 16' 43'' N</latitude>

Exemplo de uma SDL

79

<longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo> <rway idr="r16-34" /> <xway idr="x01" /> </connectsTo> </endpoint> </path> </taxiway> </taxiways> <parkingSpaces> <parking parkingType="Medium" id="p01"> <designation>Parking Ramp A</designation> <description>Usually used for medium sized aircraft</description> <airlines> <airline>TAP</airline> </airlines> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Foot">10</radius> </parking> </parkingSpaces> <hangars> <hangar id="g1"> <designation>Hangar 1</designation> <description>Usually used to store bla bla</description> <shape> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <height lengthUnit="Meter">7</height> <usefulArea areaUnit="Square Meter">42</usefulArea> <doors doorType="DualSideSlip"> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 43'' N</latitude>

Exemplo de uma SDL

80

<longitude>8º 30' 7'' W</longitude> </vertex> <length lengthUnit="Meter">2</length> <height lengthUnit="Meter">6</height> </doors> </shape> </hangar> </hangars> <utilities> <fuelFacility id="u01" fuelType="Avgas"> <designation>Jet Fuel One</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2</radius> <quantity volumeUnit="Litre">100</quantity> </fuelFacility> <tower id="u02"> <designation>Tower</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2.55</radius> <height lengthUnit="Meter">765</height> </tower> <water id="u03"> <designation>Water</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2.55</radius> <quantity volumeUnit="Litre">350</quantity> </water> <batteryFacility id="u04"> <designation>Battery</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2.55</radius> </batteryFacility> </utilities> </airport> <port> <name>Maia Airfield</name>

Exemplo de uma SDL

81

<description>Used for light traffic, flight schools, and by enthusiasts</description> <contactPerson> <name>Daniel Silva</name> <title>Mr.</title> <institution>FEUP / LIACC</institution> <position>Ph.D. Researcher</position> <address>Rua Street, 1234</address> <zipCode>4200-000</zipCode> <city>Gondomar</city> <stateDistrictRegion>Porto</stateDistrictRegion> <country>Portugal</country> <telephone>+351 123456789</telephone> <cellphone>+351 987654321</cellphone> <fax>+351 222345678</fax> <email>[email protected]</email> <additionalInformation name="preferredHours">12 to 18</additionalInformation> <additionalInformation name="timeZone">GMT</additionalInformation> </contactPerson> <location> <address>Vilar da Luz</address> <zipCode>4100-465</zipCode> <city>Maia</city> <stateDistrictRegion>Porto</stateDistrictRegion> <country>Portugal</country> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> </location> <magVar>-4.951</magVar> <waterways> <waterway id="w1"> <designation>Waterway One</designation> <width lengthUnit="Meter">12.5</width> <depth lengthUnit="Foot">30</depth> <path> <startpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo/> </startpoint> <endpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates>

Exemplo de uma SDL

82

<connectsTo/> </endpoint> </path> </waterway> <waterway id="w2"> <designation>Waterway Two</designation> <width lengthUnit="Meter">15</width> <depth lengthUnit="Foot">40</depth> <path> <startpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo/> </startpoint> <endpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo> <wway idr="w1"/> </connectsTo> </endpoint> </path> </waterway> </waterways> <quays> <quay id="q1" quayType="pier"> <designation>Quay One</designation> <description>The Big Quay</description> <width lengthUnit="Meter">2.5</width> <surface>Wood</surface> <path> <startpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo/> </startpoint> <endpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo/>

Exemplo de uma SDL

83

</endpoint> </path> </quay> <quay id="q2" quayType="pier"> <designation>Quay Two</designation> <description>The Small Quay</description> <width lengthUnit="Meter">1.5</width> <surface>Wood</surface> <path> <startpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo/> </startpoint> <endpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo> <qWay idr="q1"/> </connectsTo> </endpoint> </path> </quay> </quays> <berths> <mooringSpace id="r1"> <designation>Mooring One</designation> <description>The Mooring Space</description>

<boatType passengers="false" rollOnRollOff="false" fish="false" recreation="false" containers="false" bulk="false" bulkLiquid="false" pipeline="false" tug="true" military="true" scientific="true" underwater="true" />

<depth lengthUnit="Foot">5</depth> <maxBoatLength lengthUnit="Meter">30</maxBoatLength> <mooringWidth lengthUnit="Meter">5</mooringWidth> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <mooresTo mooringSide="port">q1</mooresTo> </mooringSpace> <slipway id="r2"> <designation>Slipway One</designation> <description>The Slipway</description>

Exemplo de uma SDL

84


<length lengthUnit="Foot">5</length> <width lengthUnit="Meter">5</width> <angle angleUnit="Degrees">25</angle> <surface>Concrete</surface> <maxWeight massUnit="Kilogram">50</maxWeight> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> </slipway> <dryDock id="r3"> <designation>Dry Dock One</designation> <description>The Dry Dock</description>


<length lengthUnit="Foot">5</length> <width lengthUnit="Meter">5</width> <depth lengthUnit="Foot">5</depth> <height lengthUnit="Foot">5</height> <dryDockVolume volumeUnit="Cubic Meter">300</dryDockVolume>

<waterFlow volumeUnit="Cubic Meter" timeUnit="Second">7.5</waterFlow>

<coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> </dryDock> </berths> <utilities> <fuelFacility id="u05" fuelType="Avgas"> <designation>Jet Fuel One</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2</radius> <quantity volumeUnit="Litre">100</quantity> </fuelFacility> <tower id="u06"> <designation>Tower</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude>

Exemplo de uma SDL

85

<altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2.55</radius> <height lengthUnit="Meter">765</height> </tower> <water id="u07"> <designation>Water</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2.55</radius> <quantity volumeUnit="Litre">350</quantity> </water> <batteryFacility id="u08"> <designation>Battery</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2.55</radius> </batteryFacility> </utilities> </port> <groundBase> <name>Maia Airfield</name> <description>Used for light traffic, flight schools, and by enthusiasts</description> <contactPerson> <name>Daniel Silva</name> <title>Mr.</title> <institution>FEUP / LIACC</institution> <position>Ph.D. Researcher</position> <address>Rua Street, 1234</address> <zipCode>4200-000</zipCode> <city>Gondomar</city> <stateDistrictRegion>Porto</stateDistrictRegion> <country>Portugal</country> <telephone>+351 123456789</telephone> <cellphone>+351 987654321</cellphone> <fax>+351 222345678</fax> <email>[email protected]</email> <additionalInformation name="preferredHours">12 to 18</additionalInformation> <additionalInformation name="timeZone">GMT</additionalInformation> </contactPerson> <location> <address>Vilar da Luz</address> <zipCode>4100-465</zipCode> <city>Maia</city> <stateDistrictRegion>Porto</stateDistrictRegion>

Exemplo de uma SDL

86

<country>Portugal</country> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> </location> <magVar>-4.951</magVar> <roads> <road id="o1" name="EN1"> <designation>Estrada Nacional Um</designation> <surface>Dirt</surface> <width lengthUnit="Meter">5</width> <totalNumberOfLanes reverseLanes="1">2</totalNumberOfLanes> <trafficIsRightHand>true</trafficIsRightHand> <path> <startpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo/> </startpoint> <endpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo/> </endpoint> </path> </road> <road id="o2" name="EN2"> <designation>Estrada Nacional Dois</designation> <surface>Dirt</surface> <width lengthUnit="Meter">5</width> <totalNumberOfLanes reverseLanes="1">2</totalNumberOfLanes> <trafficIsRightHand>true</trafficIsRightHand> <path> <startpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo/> </startpoint> <endpoint> <coordinates> <latitude>41º 16' 43'' N</latitude>

Exemplo de uma SDL

87

<longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <connectsTo> <rdway idr="o1" /> </connectsTo> </endpoint> </path> </road> </roads> <parkingsGround> <parkingSpacesGround> <designation>Parque de Estacionamento</designation> <description>Um parque</description> <parkingSpace id="k1" parkingType="Ligeiros"> <parkStartpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> </parkStartpoint> <parkEndpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> </parkEndpoint> <width lengthUnit="Meter">3</width> </parkingSpace> <parkingSpace id="k2" parkingType="Pesados"> <parkStartpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> </parkStartpoint> <parkEndpoint> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> </parkEndpoint> <width lengthUnit="Meter">4</width> </parkingSpace> </parkingSpacesGround> </parkingsGround> <garages> <garage id="e1">

Exemplo de uma SDL

88

<designation>Garagem Um</designation> <description>Uma Garagem</description> <shape> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <height lengthUnit="Meter">7</height> <usefulArea areaUnit="Square Meter">42</usefulArea> <doors doorType="DualSideSlip"> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <length lengthUnit="Meter">2</length> <height lengthUnit="Meter">6</height> </doors> </shape> </garage> </garages> <utilities> <fuelFacility id="u09" fuelType="Avgas"> <designation>Jet Fuel One</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2</radius> <quantity volumeUnit="Litre">100</quantity> </fuelFacility> <tower id="u10"> <designation>Tower</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2.55</radius> <height lengthUnit="Meter">765</height>

Exemplo de uma SDL

89

</tower> <water id="u11"> <designation>Water</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2.55</radius> <quantity volumeUnit="Litre">350</quantity> </water> <batteryFacility id="u12"> <designation>Battery</designation> <coordinates> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> <altitude measured="amsl">755</altitude> </coordinates> <radius lengthUnit="Meter">2.55</radius> </batteryFacility> </utilities> </groundBase> </baseOfOperations> </bases> <controllers> <controller id="c01" baseID="b01" role="civilian" requiredAction="Inform"> <area id="a01"> <denomination>Controller Area Alpha</denomination> <medium water="false" underwater="false" land="false" air="false" /> <availability available="always"></availability> <polygon> <minAlt lengthUnit="Foot" measured="amsl">-600</minAlt> <maxAlt lengthUnit="Foot" measured="agl">1000</maxAlt> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 53'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 48'' N</latitude> <longitude>8º 30' 9'' W</longitude> </vertex> </polygon> </area> <frequencies> <frequency freqType="approach" frequencyUnit="Hertz">121.9</frequency> <frequency freqType="tower" frequencyUnit="Hertz">122.4</frequency> <frequency freqType="ground" frequencyUnit="Hertz">121.5</frequency>

Exemplo de uma SDL

90

<frequency freqType="departure" frequencyUnit="Hertz">122.8</frequency> </frequencies> </controller> </controllers> <agentTypes> <agentType id="y1"> <simulatedAgentType> <simTitle>Woa_FEUP_Lusitania</simTitle> </simulatedAgentType> <realAgentType> <category>Aircraft</category> <vehicleType>Light Aircraft</vehicleType> <manufacturer>FEUP</manufacturer> <model>SSLTF</model> <variation>v2</variation> </realAgentType> <physical> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> <emptyWeight massUnit="Kilogram">342</emptyWeight> <maxPayload massUnit="Kilogram">125</maxPayload> <nEngines engineType="Piston">1</nEngines> <maxFuel volumeUnit="Gallon" fuelType="Avgas">135</maxFuel> <wingspan lengthUnit="Centimeter">165.7</wingspan> <wingArea areaUnit="Square Meter">125</wingArea> </physical> <performance> <cruiseSpeed velocityUnit="Nautical Mile per Hour (Knot)">110</cruiseSpeed> <maxSpeed velocityUnit="Nautical Mile per Hour (Knot)">137</maxSpeed> <range lengthUnit="Nautical Mile">930</range> <fuelFlow volumeUnit="Gallon" timeUnit="Hour">1.2</fuelFlow> <dragCoefficient>0.571243</dragCoefficient> <stallSpeed velocityUnit="Nautical Mile per Hour (Knot)">58</stallSpeed> <climbRate velocityUnit="Meter per Second">924</climbRate> <ceiling lengthUnit="Foot">18100</ceiling> <requiredRunwayLength lengthUnit="Centimeter">980</requiredRunwayLength> <maxTakeoffWeight massUnit="Kilogram">637</maxTakeoffWeight> </performance> <payloadsLayout> <payloadInfo name="PayloadLeft"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">-6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">6</maxCargo>

Exemplo de uma SDL

91

</payloadInfo> <payloadInfo name="PayloadCenter"> <relativeLocation> <displacementX lengthUnit="Meter">4.5</displacementX> <displacementY lengthUnit="Meter">0</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">20</width> <length lengthUnit="Centimeter">10</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">3</maxCargo> </payloadInfo> <payloadInfo name="PayloadRight"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">6</maxCargo> </payloadInfo> </payloadsLayout> </agentType> <agentType id="y2"> <simulatedAgentType> <simTitle>WoA_TFS_A330-200_GE_AFR-Air France</simTitle> </simulatedAgentType> <realAgentType> <category>Passenger Aircraft</category> <vehicleType>A330</vehicleType> <manufacturer>Airbus</manufacturer> <model>A330-200</model> <variation>Air France</variation> </realAgentType> <physical> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> <emptyWeight massUnit="Kilogram">342</emptyWeight> <maxPayload massUnit="Kilogram">125</maxPayload> <nEngines engineType="Jet">4</nEngines> <maxFuel volumeUnit="Gallon" fuelType="Avgas">135</maxFuel> <wingspan lengthUnit="Centimeter">165.7</wingspan> <wingArea areaUnit="Square Meter">125</wingArea> </physical> <performance> <cruiseSpeed velocityUnit="Nautical Mile per Hour (Knot)">110</cruiseSpeed>

Exemplo de uma SDL

92

<maxSpeed velocityUnit="Nautical Mile per Hour (Knot)">137</maxSpeed> <range lengthUnit="Nautical Mile">930</range> <fuelFlow volumeUnit="Gallon" timeUnit="Minute">3.54</fuelFlow> <dragCoefficient>0.571243</dragCoefficient> <stallSpeed velocityUnit="Nautical Mile per Hour (Knot)">58</stallSpeed> <climbRate velocityUnit="Meter per Second">924</climbRate> <ceiling lengthUnit="Foot">18100</ceiling> <requiredRunwayLength lengthUnit="Centimeter">980</requiredRunwayLength> <maxTakeoffWeight massUnit="Kilogram">637</maxTakeoffWeight> </performance> <payloadsLayout> <payloadInfo name="PayloadLeft"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">-6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">6</maxCargo> </payloadInfo> <payloadInfo name="PayloadCenter"> <relativeLocation> <displacementX lengthUnit="Meter">4.5</displacementX> <displacementY lengthUnit="Meter">0</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">20</width> <length lengthUnit="Centimeter">10</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">3</maxCargo> </payloadInfo> <payloadInfo name="PayloadRight"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">6</maxCargo> </payloadInfo> </payloadsLayout> </agentType>

Exemplo de uma SDL

93

<agentType id="y3"> <simulatedAgentType> <simTitle></simTitle> </simulatedAgentType> <realAgentType> <category>Car</category> <vehicleType>Car</vehicleType> <manufacturer>Toyota</manufacturer> <model>Prius</model> <variation>Working Brakes</variation> </realAgentType> <physical> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> <emptyWeight massUnit="Kilogram">342</emptyWeight> <maxPayload massUnit="Kilogram">125</maxPayload> <nEngines engineType="Other">2</nEngines> <maxFuel volumeUnit="Gallon" fuelType="Avgas">135</maxFuel> <width lengthUnit="Centimeter">165.7</width> <nWheels withTraction="2">4</nWheels> </physical> <performance> <cruiseSpeed velocityUnit="Nautical Mile per Hour (Knot)">110</cruiseSpeed> <maxSpeed velocityUnit="Nautical Mile per Hour (Knot)">137</maxSpeed> <range lengthUnit="Nautical Mile">930</range> <fuelFlow volumeUnit="Gallon" timeUnit="Minute">3.54</fuelFlow> <dragCoefficient>0.571243</dragCoefficient> <maxAttackAngle angleUnit="Degrees">45</maxAttackAngle> <min90DegTurnRadius lengthUnit="Centimeter">150</min90DegTurnRadius> </performance> <payloadsLayout> <payloadInfo name="PayloadLeft"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">-6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">6</maxCargo> </payloadInfo> <payloadInfo name="PayloadCenter"> <relativeLocation> <displacementX lengthUnit="Meter">4.5</displacementX> <displacementY lengthUnit="Meter">0</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">20</width>

Exemplo de uma SDL

94

<length lengthUnit="Centimeter">10</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">3</maxCargo> </payloadInfo> <payloadInfo name="PayloadRight"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">6</maxCargo> </payloadInfo> </payloadsLayout> </agentType> <agentType id="y4"> <simulatedAgentType> <simTitle></simTitle> </simulatedAgentType> <realAgentType> <category>Boat</category> <vehicleType>Boat</vehicleType> <manufacturer>Cunard</manufacturer> <model>Queen Mary</model> <variation>I</variation> </realAgentType> <physical> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> <emptyWeight massUnit="Kilogram">342</emptyWeight> <maxPayload massUnit="Kilogram">125</maxPayload> <nEngines engineType="Other">2</nEngines> <maxFuel volumeUnit="Gallon" fuelType="Avgas">135</maxFuel> <beam lengthUnit="Centimeter">165.7</beam> <anchorLength nAnchors="2" lengthUnit="Meter">50</anchorLength> <mooringLines nLines="2" lengthUnit="Meter">50</mooringLines> <maxDraft lengthUnit="Meter">40</maxDraft> </physical> <performance> <cruiseSpeed velocityUnit="Nautical Mile per Hour (Knot)">110</cruiseSpeed> <maxSpeed velocityUnit="Nautical Mile per Hour (Knot)">137</maxSpeed> <range lengthUnit="Nautical Mile">930</range> <fuelFlow volumeUnit="Gallon" timeUnit="Minute">3.54</fuelFlow> <dragCoefficient>0.571243</dragCoefficient> <min90DegTurnRadius lengthUnit="Centimeter">150</min90DegTurnRadius> </performance> <payloadsLayout>

Exemplo de uma SDL

95

<payloadInfo name="PayloadLeft"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">-6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">6</maxCargo> </payloadInfo> <payloadInfo name="PayloadCenter"> <relativeLocation> <displacementX lengthUnit="Meter">4.5</displacementX> <displacementY lengthUnit="Meter">0</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">20</width> <length lengthUnit="Centimeter">10</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">3</maxCargo> </payloadInfo> <payloadInfo name="PayloadRight"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">6</maxCargo> </payloadInfo> </payloadsLayout> </agentType> <agentType id="y5"> <simulatedAgentType> <simTitle></simTitle> </simulatedAgentType> <realAgentType> <category>Boat</category> <vehicleType>Boat</vehicleType> <manufacturer>Cunard</manufacturer> <model>Queen Mary</model> <variation>I</variation> </realAgentType>

Exemplo de uma SDL

96

<physical> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> <emptyWeight massUnit="Kilogram">342</emptyWeight> <maxPayload massUnit="Kilogram">125</maxPayload> <nEngines engineType="Other">2</nEngines> <maxFuel volumeUnit="Gallon" fuelType="Avgas">135</maxFuel> <beam lengthUnit="Centimeter">165.7</beam> <maxDraft lengthUnit="Meter">40</maxDraft> </physical> <performance> <cruiseSpeed velocityUnit="Nautical Mile per Hour (Knot)">110</cruiseSpeed> <maxSpeed velocityUnit="Nautical Mile per Hour (Knot)">137</maxSpeed> <range lengthUnit="Nautical Mile">930</range> <fuelFlow volumeUnit="Gallon" timeUnit="Minute">3.54</fuelFlow> <dragCoefficient>0.571243</dragCoefficient> <min90DegTurnRadius lengthUnit="Centimeter">150</min90DegTurnRadius> </performance> <payloadsLayout> <payloadInfo name="PayloadLeft"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">-6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">6</maxCargo> </payloadInfo> <payloadInfo name="PayloadCenter"> <relativeLocation> <displacementX lengthUnit="Meter">4.5</displacementX> <displacementY lengthUnit="Meter">0</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">20</width> <length lengthUnit="Centimeter">10</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">3</maxCargo> </payloadInfo> <payloadInfo name="PayloadRight"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions>

Exemplo de uma SDL

97

<width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">6</maxCargo> </payloadInfo> </payloadsLayout> </agentType> <agentType id="y6"> <simulatedAgentType> <simTitle></simTitle> </simulatedAgentType> <realAgentType> <category>Submarine</category> <vehicleType>DSV</vehicleType> <manufacturer>US Navy</manufacturer> <model>Alvin</model> <variation>Woods Hole OI</variation> </realAgentType> <physical> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> <emptyWeight massUnit="Kilogram">342</emptyWeight> <maxPayload massUnit="Kilogram">125</maxPayload> <nEngines engineType="Other">2</nEngines> <maxFuel volumeUnit="Gallon" fuelType="Avgas">135</maxFuel> <beam lengthUnit="Centimeter">165.7</beam> </physical> <performance> <cruiseSpeed velocityUnit="Nautical Mile per Hour (Knot)">110</cruiseSpeed> <maxSpeed velocityUnit="Nautical Mile per Hour (Knot)">137</maxSpeed> <range lengthUnit="Nautical Mile">930</range> <fuelFlow volumeUnit="Gallon" timeUnit="Minute">3.54</fuelFlow> <dragCoefficient>0.571243</dragCoefficient>

<maxUnderwaterSpeed velocityUnit="Nautical Mile per Hour (Knot)">137</maxUnderwaterSpeed>

<maxVerticalVelocity velocityUnit="Nautical Mile per Hour (Knot)">137</maxVerticalVelocity>

<maxDepth lengthUnit="Nautical Mile">2</maxDepth> <min90DegTurnRadius lengthUnit="Centimeter">150</min90DegTurnRadius> </performance> <payloadsLayout> <payloadInfo name="PayloadLeft"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">-6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height>

Exemplo de uma SDL

98

</dimensions> <maxCargo massUnit="Kilogram">6</maxCargo> </payloadInfo> <payloadInfo name="PayloadCenter"> <relativeLocation> <displacementX lengthUnit="Meter">4.5</displacementX> <displacementY lengthUnit="Meter">0</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">20</width> <length lengthUnit="Centimeter">10</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">3</maxCargo> </payloadInfo> <payloadInfo name="PayloadRight"> <relativeLocation> <displacementX lengthUnit="Meter">2.5</displacementX> <displacementY lengthUnit="Meter">6.5</displacementY> <displacementZ lengthUnit="Meter">0.5</displacementZ> </relativeLocation> <dimensions> <width lengthUnit="Centimeter">30</width> <length lengthUnit="Centimeter">20</length> <height lengthUnit="Centimeter">15</height> </dimensions> <maxCargo massUnit="Kilogram">6</maxCargo> </payloadInfo> </payloadsLayout> </agentType> </agentTypes> <noFlyAreas> <area id="a02"> <denomination>Romulan Neutral Zone</denomination> <medium water="false" underwater="false" land="false" air="true" /> <availability available="always"></availability> <polygon> <minAlt lengthUnit="Foot" measured="agl">-600</minAlt> <maxAlt lengthUnit="Foot" measured="amsl">1000</maxAlt> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex>

Exemplo de uma SDL

99

</polygon> </area> </noFlyAreas>

</scenario>

100

Anexo B: Exemplo de uma TDL

<?xml version="1.0" encoding="UTF-8"?> <teams xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="dcs:teams teams.xsd" xmlns="dcs:teams"> <team id="t1"> <name>Team Tim</name> <description>Equipa com nome engraçado</description> <history>This team was created back in 2009 with the intention of serving as a team</history> <purposes>Bem, algumas missões engraçadas</purposes> <mobility water="true" underwater="true" land="true" air="true" /> <contactPerson> <name>Daniel Silva</name> <title>Mr.</title> <institution>FEUP-DEI / LIACC</institution> <position>Ph.D. Researcher</position> <address>Rua Street, 1234</address> <zipCode>4200-000</zipCode> <city>Gondomar</city> <stateDistrictRegion>Porto</stateDistrictRegion> <country>Portugal</country> <telephone>+351 123456789</telephone> <cellphone>+351 987654321</cellphone> <fax>+351 222345678</fax> <email>[email protected]</email> <additionalInformation name="Preferred Hours">14 to 17</additionalInformation> <additionalInformation name="Time Zone">GMT</additionalInformation> </contactPerson> <usableBases> <base baseID="b1"/> </usableBases> <additionalNoFlyAreas> <area id="n1">

Exemplo de uma TDL

101

<denomination>Romulan Neutral Zone</denomination> <medium air="true" land="true" water="true" underwater="true" /> <availability available="always"></availability> <polygon> <minAlt measured="amsl" lengthUnit="Foot">-600</minAlt> <maxAlt measured="amsl" lengthUnit="Foot">1000</maxAlt> <vertex> <latitude>4º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> <vertex> <latitude>41º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </vertex> </polygon> </area> <area id="n2"> <denomination>Central Urban</denomination> <medium air="true" land="true" water="false" underwater="false" /> <availability available="periodic"> <timeSlot every="1" repeat="Day"> <startDate>2000-01-01</startDate> <startTime>07:00:00</startTime> <endDate>2100-12-31</endDate> <endTime>22:00:00</endTime> </timeSlot> </availability> <circle> <minAlt measured="agl" lengthUnit="Foot">0</minAlt> <maxAlt measured="amsl" lengthUnit="Foot">5000</maxAlt> <center> <latitude>4º 16' 43'' N</latitude> <longitude>8º 30' 7'' W</longitude> </center> <radius lengthUnit="Kilometer">25</radius> </circle> </area> </additionalNoFlyAreas> <agents> <agent id="a1" agentTypeID="y1"> <name>Lusitania</name> <description>Primeiro agente a voar</description> <initialLocation baseID="b1" locationID="p02"> <heading headingType="True">180</heading> </initialLocation> <state> <fuel volumeUnit="Litre">2.5</fuel>

Exemplo de uma TDL

102

<lights cabin="false" logo="false" wing="false" recognition="false" panel="false" strobe="false" taxi="false" landing="false" beacon="false" nav="false" />

<doorsOpen>false</doorsOpen> <gearDown>true</gearDown> <flapsHandlePosition>3</flapsHandlePosition> <rudder>-0.01334</rudder> <aileron>-0.1213</aileron> <elevator>0.01223</elevator> </state> <simulatedAgent> <tailNumber>NLS01</tailNumber> </simulatedAgent> <realAgent> <communication> <controlFrequency frequencyUnit="MegaHertz">1245.75</controlFrequency> <activeFrequency frequencyUnit="MegaHertz">121.2</activeFrequency> <standByFrequency frequencyUnit="MegaHertz">124.5</standByFrequency> </communication> <ATC> <callSign>Air One</callSign> <tailNumber>NLS01</tailNumber> <name>Lusitania</name> </ATC> </realAgent> <payloads> <payload name="PayloadCenter"> <sensors> <sensor sensorType="CO2"> <dimensions> <width lengthUnit="Centimeter">20</width> <length lengthUnit="Centimeter">18</length> <height lengthUnit="Centimeter">14</height> </dimensions> <weight massUnit="Kilogram">4</weight> <operatingRequirements> <temperature>-40ºC - 75ºC</temperature> <humidity>0 - 99%</humidity> <voltage>3 - 5.5 vdc</voltage> <current>10 mA</current> <powerConsumption><100mW</powerConsumption> </operatingRequirements> <specifications> <specification name="Detects">CO2</specification> <specification name="Method">Infrared</specification> <specification name="Range">0-2000ppm</specification> <specification name="Accuracy">5%</specification> <specification name="Resolution">10ppm</specification> <specification name="Output Range">0-22 mA</specification> <specification name="Response Time">5 ms</specification> </specifications> </sensor> </sensors>

Exemplo de uma TDL

103

<cargo type="water" quantity="180"/> </payload> </payloads> </agent> <agent id="a2" agentTypeID="y6"> <name>U-boat</name> <description>Segundo agente no (fundo) do mar</description> <initialLocation baseID="b01" locationID="p02"> <heading headingType="True">180</heading> </initialLocation> <state> <fuel volumeUnit="Litre">2.6</fuel>

<lightsSub cabin="true" rudder="true" port="true" starboard="true" bow="true" strobe="true"/>

<equivalentEngineAngle angleUnit="Degrees">10</equivalentEngineAngle> <equivalentEnginePitch angleUnit="Degrees">10</equivalentEnginePitch> </state> <simulatedAgent> <tailNumber>NLS01</tailNumber> </simulatedAgent> <realAgent> <communication> <controlFrequency frequencyUnit="MegaHertz">1245.75</controlFrequency> <activeFrequency frequencyUnit="MegaHertz">121.2</activeFrequency> <standByFrequency frequencyUnit="MegaHertz">124.5</standByFrequency> </communication> <ATC> <callSign>Air One</callSign> <tailNumber>NLS01</tailNumber> <name>Lusitania</name> </ATC> </realAgent> <payloads> <payload name="PayloadCenter"> <sensors> <sensor sensorType="CO2"> <dimensions> <width lengthUnit="Centimeter">20</width> <length lengthUnit="Centimeter">18</length> <height lengthUnit="Centimeter">14</height> </dimensions> <weight massUnit="Kilogram">4</weight> <operatingRequirements> <temperature>-40ºC - 75ºC</temperature> <humidity>0 - 99%</humidity> <voltage>3 - 5.5 vdc</voltage> <current>10 mA</current> <powerConsumption><100mW</powerConsumption> </operatingRequirements> <specifications> <specification name="Detects">CO2</specification> <specification name="Method">Infrared</specification>

Exemplo de uma TDL

104

<specification name="Range">0-2000ppm</specification> <specification name="Accuracy">5%</specification> <specification name="Resolution">10ppm</specification> <specification name="Output Range">0-22 mA</specification> <specification name="Response Time">5 ms</specification> </specifications> </sensor> </sensors> <cargo type="water" quantity="180" /> </payload> </payloads> </agent> <agent agentTypeID="y3" id="a3"> <name>Ford</name> <description>Segundo agente na terra</description> <initialLocation baseID="b01" locationID="p02"> <heading headingType="True">180</heading> </initialLocation> <state> <fuel volumeUnit="Litre">2.6</fuel>

<ligthsCar cabin="true" frontLeft="true" frontRight="true" rearLeft="true" rearRight="true"/>

<doorsOpen>true</doorsOpen> <equivalentWheelTurnAngle angleUnit="Degrees">10</equivalentWheelTurnAngle>

</state> <simulatedAgent> <tailNumber>NLS01</tailNumber> </simulatedAgent> <realAgent> <communication> <controlFrequency frequencyUnit="MegaHertz">1245.75</controlFrequency> <activeFrequency frequencyUnit="MegaHertz">121.2</activeFrequency> <standByFrequency frequencyUnit="MegaHertz">124.5</standByFrequency> </communication> <ATC> <callSign>Air One</callSign> <tailNumber>NLS01</tailNumber> <name>Lusitania</name> </ATC> </realAgent> <payloads> <payload name="PayloadCenter"> <sensors> <sensor sensorType="CO2"> <dimensions> <width lengthUnit="Centimeter">20</width> <length lengthUnit="Centimeter">18</length> <height lengthUnit="Centimeter">14</height> </dimensions> <weight massUnit="Kilogram">4</weight> <operatingRequirements>

Exemplo de uma TDL

105

<temperature>-40ºC - 75ºC</temperature> <humidity>0 - 99%</humidity> <voltage>3 - 5.5 vdc</voltage> <current>10 mA</current> <powerConsumption><100mW</powerConsumption> </operatingRequirements> <specifications> <specification name="Detects">CO2</specification> <specification name="Method">Infrared</specification> <specification name="Range">0-2000ppm</specification> <specification name="Accuracy">5%</specification> <specification name="Resolution">10ppm</specification> <specification name="Output Range">0-22 mA</specification> <specification name="Response Time">5 ms</specification> </specifications> </sensor> </sensors> <cargo type="water" quantity="180" /> </payload> </payloads> </agent> <agent agentTypeID="y4" id="a4"> <name>Titanic</name> <description>Segundo agente na água</description> <initialLocation baseID="b01" locationID="p02"> <heading headingType="True">180</heading> </initialLocation> <state> <fuel volumeUnit="Litre">2.6</fuel>

<ligthsBoat cabin="true" masthead="true" stern="true" sidelights="true" towing="true" allAround="true" strobe="true"/>

<anchor> 10 </anchor> <rudder>11</rudder> <equivalentEngineAngle angleUnit="Degrees">10</equivalentEngineAngle> </state> <simulatedAgent> <tailNumber>NLS01</tailNumber> </simulatedAgent> <realAgent> <communication> <controlFrequency frequencyUnit="MegaHertz">1245.75</controlFrequency> <activeFrequency frequencyUnit="MegaHertz">121.2</activeFrequency> <standByFrequency frequencyUnit="MegaHertz">124.5</standByFrequency> </communication> <ATC> <callSign>Air One</callSign> <tailNumber>NLS01</tailNumber> <name>Lusitania</name> </ATC> </realAgent> <payloads> <payload name="PayloadCenter">

Exemplo de uma TDL

106

<sensors> <sensor sensorType="CO2"> <dimensions> <width lengthUnit="Centimeter">20</width> <length lengthUnit="Centimeter">18</length> <height lengthUnit="Centimeter">14</height> </dimensions> <weight massUnit="Kilogram">4</weight> <operatingRequirements> <temperature>-40ºC - 75ºC</temperature> <humidity>0 - 99%</humidity> <voltage>3 - 5.5 vdc</voltage> <current>10 mA</current> <powerConsumption><100mW</powerConsumption> </operatingRequirements> <specifications> <specification name="Detects">CO2</specification> <specification name="Method">Infrared</specification> <specification name="Range">0-2000ppm</specification> <specification name="Accuracy">5%</specification> <specification name="Resolution">10ppm</specification> <specification name="Output Range">0-22 mA</specification> <specification name="Response Time">5 ms</specification> </specifications> </sensor> </sensors> <cargo type="water" quantity="180" /> </payload> </payloads> </agent> </agents> </team> </teams>

Documents

Adaptação de Veículos Autónom os e Inteligentes e Análise ...€¦ · 4.1.1 Extensão da linguagem SDL ... 6 – Conclusões e Trabalho Futuro ... C# Linguagem de programação