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

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Adaptação de Veículos Autónomos e Inteligentes e Análise de Desempenho no Flight Simulator X Abel Fernando Neto Moreira dos Santos Mestrado Integrado em Engenharia Informática e Computação Orientador: Luís Paulo Gonçalves dos Reis (Professor Auxiliar, FEUP) Co-Orientador: Daniel Augusto Gama de Castro Silva Junho de 2010

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 Abel Fernando Neto Moreira dos Santos 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

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. i

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. ii

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! Abel Fernando Neto Moreira dos Santos iii

Í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 iv

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 v

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 vi

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 vii

Lista de Tabelas Tabela 1 Unidades de medida suportadas... 40 Tabela 2 Terminologias diferentes para mesmas propriedades... 49 viii

Abreviaturas e Símbolos FSX API SDL TDL Flight Simulator X. Simulador de voo da Microsoft e ferramenta base de desenvolvimento deste trabalho Application programming interface Scenario Description Language. Linguagem desenvolvida para definição do cenário do mundo Team Description Language. Linguagem desenvolvida para especificação de equipas de veículos extensible Markup Language. Framework para definir linguagens de anotação extensible Markup Language Schema. Linguagem para definição de regras de validação de documentos XML XML XML Schema C# Linguagem de programação desenvolvida pela Microsoft ATC Air Traffic Control ix

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 1

Introdução 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. 2

Introdução 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. 3

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. 4

Revisão Bibliográfica 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 5

Revisão Bibliográfica 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 6

Revisão Bibliográfica 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 contrário do FSX,, tornando-se tornando impossível de adaptar nestass 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 simulação em caso de salvamento. No entanto, essas especificações são sempre resumidas a barcos. Figura 2 - Imagens do simulador naval Ship Simulator 2008 É 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 mponentes e a condução dos veículos num ambiente simulado [14]. Os fabricantes 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 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 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, encontrado tornando 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 uspensão dos veículos, possuindo possibilidade de múltiplas configurações ao nível da 7

Revisão Bibliográfica 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 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 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 simulador VTI[15], desenvolvido para a Sewdish Road and Traffic Research Institute, enquanto outros fabricantes automóveis seguem também a Volkswagen e desenvolvem os seus próprios simuladores como Daimler-Benz, Mazda[16] [16], Ford, entre outros. Em termos académicos, referência para o simulador NADS-1[17] [17], um dos maiores simuladores da actualidade, com nove graus de liberdade usado na University of Iowa. Nesta área de simulação, um dos últimos desenvolvidos é pertencente à Toyota[18] e é actualmente o 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 verificar a eficácia das soluções desenvolvidas. 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 desenvolver com agentes, 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 efectuar um percurso que os leve até determinado ponto, num ambiente 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 [21]. Figura 3 - Um dos veículos participantes no Darpa Grand Challenge de 2007 8

Revisão Bibliográfica 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 multiveí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. 9

Revisão Bibliográfica 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 multiagentes 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 10

Revisão Bibliográfica 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 multiatributo [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 11

Revisão Bibliográfica 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. 12

Revisão Bibliográfica 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. 13

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 14

Integração no Projecto Global 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 15

Integração no Projecto Global 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. Estudo veículos dos Levantamento de propriedades dos veículos Construção painel controlo do de Adaptação dos novos veículos no simulador Figura 11 Plano de desenvolvimento da adaptação dos novos tipos de veículos 16

Integração no Projecto Global 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 17

Integração no Projecto Global responsável, morada, código ICAO 1 e IATA 2 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 18

Integração no Projecto Global Figura 14 Definição do elemento aeroporto 19

Integração no Projecto Global 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 20

Integração no Projecto Global 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 21

Integração no Projecto Global 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 22

Integração no Projecto Global 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. 23

Integração no Projecto Global 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). Definição do tipo de análise Desenvolver aplicação Desenvolver métricas usáveis para avaliação 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 24

Integração no Projecto Global 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 25

Integração no Projecto Global 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 26

Integração no Projecto Global 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. 27

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 28

Adaptação de Novos Veículos 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 29

Adaptação de Novos Veículos 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. 30

Adaptação de Novos Veículos 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 31

Adaptação de Novos Veículos 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 32