Aplicação de agentes inteligentes capazes de desempenhar o papel de membros na execução

de trabalhos em equipa, em ambiente virtual 3D OpenSimulator

!

!!

Andreas Carocha Vilela

Orientadores:

Rui Prada

Leonel Morgado

Dissertação submetida à UNIVERSIDADE DE TRÁS-OS-MONTES E ALTO DOURO

para obtenção do grau de MESTRE

em Informática, de acordo com o disposto no DR – 1ª série–A, Decreto-Lei n.º 74/2006 de 24 de Março e no

Regulamento de Estudos Pós-Graduados da UTAD DR, 2.ª série – Deliberação n.º 2391/2007

Aplicação de agentes inteligentes capazes de desempenhar o papel de membros na execução

de trabalhos em equipa, em ambiente virtual 3D OpenSimulator

Andreas Carocha Vilela

Orientadores:

Rui Prada

Leonel Morgado

Orientação Científica: Rui Prada Professor Auxiliar Departamento de Engenharia Informática Instituto Superior Técnico – Universidade Técnica de Lisboa Leonel Caseiro Morgado Professor Auxiliar Departamento de Engenharias Escola de Ciências e Tecnologia - ECT Universidade de Trás-os-Montes e Alto Douro

i

Resumo

A possibilidade de treino de uma tarefa efectuada em equipa exige a disponibilidade de horário e alguma homogeneidade de preparação dos membros do processo de treino, o que limita as possibilidades de treino individual de uma tarefa. A generalização do uso de novas tecnologias na sociedade, proporciona a criação de um ambiente de treino totalmente simulado. Por sua vez, a aplicação de agentes inteligentes a estes cenários, em substituição de alguns dos elementos humanos da equipa, permite ultrapassar limitações relacionadas com o treino individual de um processo de equipa, fazendo com que este decorra mesmo que só parte dos membros humanos esteja disponível ou preparada.

Este trabalho apresenta uma proposta que visa contribuir para a resolução deste problema, aplicando este estudo ao caso prático de formação de mecânicos da Força Aérea Portuguesa em operações de manutenção de motores de aeronaves F-16, partilhando um mesmo espaço virtual 3D em OpenSimulator.

Desta forma, esta dissertação descreve e analisa os vários elementos seguidos para atingir essa integração, conseguindo assim aplicar agentes inteligentes ao caso de estudo em questão, combatendo as limitações de treino individual de uma tarefa executada em equipa.

Palavras-chave: Agentes inteligentes, formação, tarefas em equipa, mundos virtuais 3D, F-16, OpenSimulator.

ii

iii

Abstract

The possibility of training a task carried out in a team requires the availability of time and somewhat homogeneous preparation of all members of the training process, which limits the possibilities of individual training of a task. The increasing use of new technologies in general provides the opportunity for creation of a simulated training environment. Simultaneously, applying intelligent agents to these scenarios, in replacement of the human team elements, can help overcome the limitations related to the individual training task, by allowing the training to take place even if only some of the human team members are available or prepared.

This work presents a proposal that aims to help solve this problem, by applying this study to the practical case of training of Portuguese Air Force mechanics involved in the maintenance of F-16 aircraft engines, sharing a virtual 3D space in OpenSimulator.

Thus, this dissertation describes and analyzes the procedures followed to achieve this integration, applying intelligent agents to the case study, fighting the limitations of individual training of a task intended for a team.

Keywords: Intelligent agents, training, team tasks, 3D virtual worlds, F-16, OpenSimulator.

iv

v

Agradecimentos

Agradeço, em primeiro lugar, aos meus pais pelo apoio que sempre me proporcionaram ao longo de toda a minha vida... Pela dedicação, educação, valores e princípios que sempre me incutiram e que eu tanto valorizo...

O meu agradecimento ao Professor Doutor Leonel Caseiro Morgado e ao Professor Doutor Rui Prada, orientadores deste trabalho, pelas suas ideias, sugestões e orientações que permitiram a sua realização.

Aos meus irmãos pelo apoio, disponibilidade e ajuda que me ofereceram na elaboração desta dissertação.

À minha namorada, por ser como é, demonstrando ao longo deste percurso apoio, força, confiança e compreensão mesmo nos momentos mais difíceis.

E a todos aqueles que, directa ou indirectamente, contribuíram para a execução desta dissertação.

vi

vii

Índice

!!1"#"INTRODUÇÃO".............................................................................................................................................."1!1.1! –!CONTEXTUALIZAÇÃO!............................................................................................................................................!1!1.2! –!OBJECTIVOS!............................................................................................................................................................!2!1.3! –!METODOLOGIA!ADOPTADA!.................................................................................................................................!2!1.4! –!ESTRUTURA!DA!DISSERTAÇÃO!............................................................................................................................!3!

2! –"INSTALAÇÃO"DE"MOTOR"EM"AERONAVE"F#16"............................................................................"5!2.1! –!DESCRIÇÃO!DO!CASO!DE!ESTUDO!.......................................................................................................................!5!2.2!–!PROCESSO!DE!FORMAÇÃO!NA!FORÇA!AÉREA!PORTUGUESA!..............................................................................!6!2.3!–!ANÁLISE!DE!TAREFAS!...............................................................................................................................................!6!2.4!–!REQUISITOS!DO!SISTEMA!.........................................................................................................................................!7!

3! –"MUNDOS"VIRTUAIS".............................................................................................................................."9!3.1! –!PANORAMA!GERAL!................................................................................................................................................!9!3.1.1$–$Second$Life$........................................................................................................................................................$11!3.1.2$–$Project$Wonderland$......................................................................................................................................$12!3.1.3$–$Active$Worlds$...................................................................................................................................................$14!3.1.4$–$Open$Cobalt$......................................................................................................................................................$15!

3.2! –!OPENSIMULATOR!...............................................................................................................................................!16!3.3! –!UTILIZAÇÃO!DE!AGENTES!INTELIGENTES!E!SEU!IMPACTO!..........................................................................!18!

4! –"ABORDAGENS"DE"INTELIGÊNCIA"ARTIFICIAL"..........................................................................."21!4.1! –!ALGORITMOS!DE!PLANEAMENTO!....................................................................................................................!21!4.2! –!PARTIAL!ORDER!PLANNING!.............................................................................................................................!24!

5! –"ARQUITECTURA"E"MODELO"DE"INTEGRAÇÃO"..........................................................................."25!5.1! –!DEFINIÇÃO!DA!ARQUITECTURA!.......................................................................................................................!25!5.2!–!ESPAÇO!3D!..............................................................................................................................................................!26!5.3!–!ANÁLISE!DE!TAREFAS!DO!CASO!DE!ESTUDO!.......................................................................................................!28!5.4!–!CONVERSÃO!DE!ACÇÕES!PARA!AMBIENTE!3D!...................................................................................................!32!

6! –"SISTEMA"DESENVOLVIDO"................................................................................................................"35!6.1!–!FUNCIONAMENTO!DO!SISTEMA!............................................................................................................................!35!6.1.1$–$Avatares$automatizados$.............................................................................................................................$35!6.1.2$–$Objectos$3D$.......................................................................................................................................................$36!6.1.3$–$Web$Services$....................................................................................................................................................$36!6.1.4$–$Base$de$dados$..................................................................................................................................................$37!

6.2!–!TESTES!E!VALIDAÇÃO!.............................................................................................................................................!40!6.2.1$Possibilidade$de$uma$equipa,$em$simultâneo,$treinar$o$processo$de$instalação$do$motor$

Pratt$&$Whitney$F100$numa$aeronave$FQ16$....................................................................................................$40!6.2.2$Possibilidade$de$uma$equipa$composta$por$utilizadores$e$avatares$automáticos,$em$

simultâneo,$treinar$o$processo$de$instalação$do$motor$Pratt$&$Whitney$F100$numa$aeronave$FQ

16$.........................................................................................................................................................................................$40!6.2.3$Os$avatares$automatizados$devem$agir$de$forma$correcta$e$de$acordo$com$o$processo$de$

manutenção$mecânica$...............................................................................................................................................$42!6.2.4$Os$avatares$devem$tomar$iniciativas$sem$a$necessidade$de$um$comando$do$utilizador$...$43!6.2.5$Permitir$que$o$comportamento$dos$mecânicos$virtuais$seja$razoavelmente$semelhante$ao$

comportamento$dos$mecânicos$reais$..................................................................................................................$44!

viii

6.2.6$O$tempo$de$resposta$dos$mecânicos$virtuais$deve$assegurar$que$a$simulação$se$mantenha$

credível$aos$utilizadores$humanos$........................................................................................................................$45!7! – CONCLUSÕES"E"PROPOSTAS"DE"TRABALHO"FUTURO"............................................................"47!7.1! –!CONCLUSÕES!.......................................................................................................................................................!47!7.2!–!TRABALHO!FUTURO!...............................................................................................................................................!47!

8! – REFERÊNCIAS"...................................................................................................................................."48!9! – ANEXOS"................................................................................................................................................."50!

ix

Índice de figuras "

FIGURA!1!–!Imagem!referente!à!descrição!de!uma!tarefa!(TO)!.......................................................................!5!FIGURA!2!–!Exemplo!de!aula/sessão!no!Second!Life!.........................................................................................!12!FIGURA!3!–!Campo!de!andebol,!para!treino!de!movimentações!no!Second!Life!...................................!12!FIGURA!4!–!MPK20!...........................................................................................................................................................!13!!FIGURA!5!–!Plataforma!Active!Worlds!.....................................................................................................................!14!FIGURA!6!–!Exemplo!de!utilização!da!plataforma!Open!Cobalt!....................................................................!15!FIGURA!7!–!Agente!pedagógico:!Steve!.....................................................................................................................!19!FIGURA!8!–!Agente!pedagógico:!Adele!.....................................................................................................................!19!!FIGURA!9!–!Agente!pedagógico:!Herman!the!bug!...............................................................................................!20!FIGURA!10!–!“The!monkey!wants!the!bananas!that!hanging!from!the!ceiling!in!the!location!B”!..!22!FIGURA!11!–!Planos!de!ordem!parcial!e!total!.......................................................................................................!23!FIGURA!12!–!Arquitectura!do!sistema!.....................................................................................................................!25!!FIGURA!13!–!Hangar!para!formação!de!mecânicos!............................................................................................!26!!FIGURA!14!–!Avião!Fr16!disponível!para!formação!...........................................................................................!27!!FIGURA!15!–!Motor!Pratt!&!Whitney!F100!pronto!para!formação!..............................................................!27!!FIGURA!16!–!Mapa!de!localização!de!cada!mecânico!........................................................................................!28!!FIGURA!17!–!Acção!genérica!de!remover!um!parafuso!....................................................................................!29!!FIGURA!18!–!“Remover!quatro!parafusos!da!fuselagem!do!avião”!.............................................................!29!!FIGURA!19!–!Acção!genérica!para!instalar!um!apoio!no!motor!....................................................................!30!!FIGURA!20!–!“Instalação!de!três!apoios!no!motor”!............................................................................................!30!!FIGURA!21!–!Acção!“chegar!junto!da!fuselagem!do!avião”!..............................................................................!32!!FIGURA!22!–!Acção!“fazer!take!do!objecto!parafuso”!........................................................................................!33!!FIGURA!23!–!Acção!“deslocarrse!para!junto!da!mesa!de!ferramentas”!.....................................................!33!!FIGURA!24!–!Acção!“fazer!rez!do!parafuso!em!cima!da!mesa”!......................................................................!34!!FIGURA!25!–!Diagrama!ErR!da!base!de!dados!implementada!.......................................................................!38!!FIGURA!26!–!Dicionário!de!dados!da!base!de!dados!desenvolvida!.............................................................!39!!FIGURA!27!–!Software!criado!para!gerir!o!avatar!no!ambiente!3D!.............................................................!40!!FIGURA!28!–!AlgoritmoInstalacaoMotor.exe!!.......................................................................................................!41!!FIGURA!29!–!Exemplo!de!um!momento!de!actuação!dos!avatares!automatizados!..............................!42!!FIGURA!30!–!Exemplo!de!movimentação!efectuado!por!um!avatar!(teletransporte)!.........................!44!!!!

x

!!!!!!!!!!!!!!!!!

1

1 - Introdução

1.1 – Contextualização

A execução de determinadas tarefas pode levar à necessidade das mesmas serem realizadas em grupo. No entanto, a homogeneidade de preparação e disponibilidade de horário por parte de todos os membros de um processo de treino são aspectos-chave, o que limita assim a possibilidade de treino individual do mesmo. Por sua vez, a tecnologia veio revolucionar os sistemas de ensino, no entanto, estes treinos em equipa enfrentam ainda algumas necessidades e limitações a nível do treino individual. O capítulo 3 desta dissertação dá uma perspectiva do panorama actual das tecnologias disponíveis a este nível.

A evolução das tecnologias, proporcionou o aparecimento de diversas possibilidades técnicas para a criação de sistemas multi-utilizador 3D. Desta forma, destaca-se a utilização de game engines (ex: Unreal Engine1, Unity 3D2, etc) e de mundos virtuais 3D.

Assim, o crescente uso de tecnologias como os mundos virtuais 3D multi-utilizador proporcionam novas abordagens e oportunidades em diversas áreas, nomeadamente no sistema educativo (Esteves et al., 2010). O uso destas tecnologias em práticas de formação tem vindo a ganhar relevo, tendo sido recentemente adoptada a expressão “serious games” como área de trabalho frequentemente associada a este tema (embora os mundos virtuais sejam usados na educação de formas que frequentemente não têm quaisquer aspectos de jogo). Segundo Krause (2009), a simulação de actividades da vida real, em ambientes virtuais 3D, é considerado um subconjunto de “serious games”.

A tecnologia multi-utilizador 3D conta com milhões de utilizadores espalhados por todo o mundo (Woodcook, 2008) e imensos produtos comerciais disponíveis (Leal, 2007). O conhecido Second Life3 ou o World of Warcraft4 são exemplos disso mesmo.

São diversas as organizações que exploram estes sistemas 3D com os mais variados objectivos, tais como: divulgação de novos produtos ou marcas, contacto com potenciais clientes, comércio electrónico, comunicação com outros utilizadores, fins educativos (como já se referiu) ou mesmo como meio de expressão política e debate (Book, 2008).

Existe ainda uma discrepância entre o mundo da educação e a revolução tecnológica que está a decorrer nos mundos digitais. Mundos virtuais como o Second Life ou OpenSimulator5, utilizados como ambientes de ensino e aprendizagem, vêm ao encontro do actual momento digital (Greis & Faria, 2007). Estes sistemas são ambientes de simulação nos quais não existem objectivos prévios a serem alcançados, existindo a possibilidade de construção de ambientes simulados em 3D e a capacidade de integrar estes mesmos ambientes com a Internet. Estas tecnologias permitem interligar utilizadores que se encontrem separados fisicamente, proporcionando comunicação entre eles ou mesmo a realização de acções de forma colaborativa.

1 http://www.unrealengine.com/ 2 http://unity3d.com/ 3 http://secondlife.com/ - Mundo virtual 3D criado pela empresa Linden Lab, também abreviado por SL. 4 http://eu.battle.net/wow/ 5 http://opensimulator.org/

2

Assim, os mundos virtuais 3D tornam-se importantes pois permitem criar ambientes de treino simulados, proporcionando aos utilizadores a interacção com as diversas partes que constituem o sistema.

Por sua vez, a utilização de mundos virtuais 3D torna possível a aplicação de agentes inteligentes nestes cenários de treino, em substituição de alguns dos membros da equipa, permitindo deste modo que o treino decorra, mesmo que só parte dos membros humanos esteja disponível ou igualmente preparada. Esta proposta permite resolver problemas associados ao treino individual na execução de trabalhos em equipa.

Pretendeu-se assim, através da utilização de uma das tecnologias disponíveis para a criação de sistemas multi-utilizador 3D, da aplicação de técnicas de planeamento automatizado e da integração de agentes inteligentes, apresentar e validar esta abordagem de forma a resolver problemas associados ao treino individual na execução de trabalhos em equipa, proporcionando assim uma mais-valia ao que actualmente existe. Este presente trabalho foi aplicado num caso de estudo desenvolvido para a Força Aérea Portuguesa.

O mundo virtual 3D OpenSimulator foi a plataforma seleccionada para desenvolver este sistema. Esta escolha deve-se ao facto deste projecto se integrar num outro trabalho em curso que tem o intuito de criar, em ambiente virtual OpenSimulator, um simulador 3D próprio para a formação de mecânicos da Força Aérea Portuguesa. Mais à frente, nesta dissertação, serão apresentadas e explicadas as principais características desta tecnologia.

1.2 – Objectivos

Este trabalho tem como intuito apresentar e validar abordagens que permitam resolver questões relacionadas com o treino individual, aquando aplicado em tarefas realizadas em equipa. Assim, o objectivo desta dissertação é analisar e desenvolver agentes inteligentes capazes de desempenhar o papel de membros na execução de tarefas em equipa, partilhando um mesmo espaço virtual 3D em tecnologia OpenSimulator.

1.3 – Metodologia adoptada

Para atingir o objectivo proposto estabeleceu-se um conjunto de etapas que enumeram as diversas metas de trabalho deste projecto. Estas etapas não foram necessariamente executadas de forma sequencial, pois algumas destas ocorreram de forma paralela em determinadas fases do projecto. Desta forma, são aqui descritas as várias etapas que compõem o processo que a concretiza:

• 1a Etapa: Escolha do caso de estudo e definição dos principais requisitos do

sistema.

• 2a Etapa: Estudo das plataformas tecnológicas para mundos virtuais 3D e análise mais detalhada da opção selecionada.

3

• 3a Etapa: Estudo das várias abordagens de inteligência artificial e selecção da

técnica mais adequada.

• 4a Etapa: Desenvolvimento de um algoritmo para planeamento de acções.

• 5a Etapa: Análise das tarefas do caso de estudo (Instalação de um motor Pratt & Whitney F100 numa aeronave F-16).

• 6a Etapa: Tradução das acções do processo, provenientes da análise das tarefas, em interacções com a interface 3D.

• 7a Etapa: Desenvolvimento de componentes no mundo 3D, para integração com o sistema de treino.

• 8a Etapa: Criação de agentes inteligentes capazes de desempenhar o papel de um elemento no processo de equipa, com base nos dados do plano de acções.

• 9a Etapa: Testes e validação do sistema implementado.

1.4 – Estrutura da dissertação

A presente dissertação está dividida em sete capítulos, sendo o primeiro capitulo esta introdução, que teve como foco identificar a proposta pretendida, assim como detalhar a metodologia adoptada que compõe este processo. Foram também identificadas as razões e a importância que levaram a desenvolver este trabalho.

No capitulo 2, “Instalação de motor em Aeronave F-16”, é apresentado o caso de estudo deste trabalho, o processo de formação da Força Aérea Portuguesa e é feita uma análise dos requisitos do sistema.

O capitulo 3, “Mundos virtuais”, encontra-se dividido em 3 secções, onde é dada uma visão geral, do ponto de vista do programador, dos mundos virtuais, assim como são apresentadas as principais plataformas existentes. Para além disso, este capitulo explica também, em mais detalhe, a plataforma utilizada para desenvolver este trabalho e analisa o impacto da utilização de agentes inteligentes em sistemas de aprendizagem.

O capitulo 4, “Abordagens de Inteligência Artificial”, encontra-se dividido em 2 secções. Este capitulo apresenta algumas técnicas de planeamento de acções, assim como os tipos de algoritmos de ordem parcial ou total. É também detalhado o algoritmo que apresenta características mais adequadas.

No capitulo 5, “Arquitectura e modelo de integração”, encontra-se dividida em 4 secções. É apresentada a arquitectura seguida neste trabalho e o espaço virtual de treino 3D criado para o sistema. É também feita uma análise detalhada das tarefas do caso de estudo e mostra alguns exemplos de conversões de acções para o mundo virtual 3D, etapa necessária para construir o processo de treino em ambiente 3D.

4

No capitulo 6, “Sistema desenvolvido”, é apresentado o funcionamento do sistema e uma explicação das componentes que constituem o mesmo. São também identificados e apresentados os testes realizados ao sistema, bem como os seus resultados.

Por fim, no capitulo 7, “Conclusões e propostas de trabalho futuro”, é apresentada uma reflexão sobre o resultado do trabalho desenvolvido e lançam-se algumas sugestões de trabalho de investigação e desenvolvimento.

5

2 – Instalação de motor em Aeronave F-16

2.1 – Descrição do caso de estudo

O treino prático de algumas operações na Força Aérea Portuguesa6 (FAP) pode implicar o envolvimento de aviões ou motores fazendo com que estes não possam estar disponíveis durante esse processo, tornando-se assim momentos de formação particularmente dispendiosos.

A adopção de um ambiente de formação virtual 3D pretende contribuir para aumentar a eficiência destes momentos de formação com componentes reais, permitindo aos formandos a possibilidade de praticar as tarefas de manutenção e os aspectos de coordenação entre membros da equipa de forma simulada, sem envolvimento de recursos físicos – com a ambição de aumentar a preparação prévia dos formandos para a posterior formação prática com aviões e motores reais.

O processo de treino segue um conjunto de várias tarefas de execução, podendo estas serem ou não interdependentes. Na manutenção em mecânica aeronáutica, estes processos são especificados pelos fabricantes através de documentos designados “Technical Orders” (TO), que descrevem as várias fases das tarefas de execução, em texto e diagramas (a Figura 1 apresenta um exemplo de aspecto gráfico de uma TO).

Figura 1 – Imagem referente a uma descrição de uma tarefa (TO). (Lockheed Martin Corp., 2009).

Por opção conjunta dos investigadores deste projecto e dos formadores de carácter prático,

definiu-se como objectivo inicial para o simulador, entre as várias tarefas de manutenção mecânica possíveis, o processo de instalação de um motor Pratt & Whitney F1007 numa aeronave F-168. Assim, as TO associadas a este motor (Lockheed Martin Corp., 2009) apresentam todas as acções que completam um determinado processo no motor.

6 http://www.emfa.pt/www/index.php 7 http://www.pratt-whitney.com/products/military/f100.asp 8 http://www.emfa.pt/www/aeronavesdetalhe.php?lang=pt&cod=f16

6

2.2 – Processo de formação na Força Aérea Portuguesa

Na Força Aérea Portuguesa, o processo de formação inicia-se logo após a selecção da especialidade do militar. Esta formação-base é efectuada no Centro de Formação Militar e Técnica da Força Aérea (CFMTFA9), na base da Ota10. Após esta etapa, os militares são destacados para as bases aéreas existentes em Portugal, com base na sua classificação final e preferência. Dentro de uma base aérea existem várias secções e estas, de acordo com as suas necessidades, organizam o plano para os militares.

É o caso da Base Aérea Nº 5 (BA5), em Monte Real, Leiria, a partir da qual actuam as aeronaves F-16 da FAP. Aqui, os militares depois de destacados para a secção de operações de linha da frente e manutenção de motores, têm uma formação simples sobre as componentes gerais da aeronave F-16, sendo que posteriormente a esta, iniciam o curso de formação nesta mesma área denominado “Curso do Motor F100-PW-220E Nível O”. Esta formação específica, com a duração de aproximadamente 250 horas, integra não só fases teóricas, mas também fases práticas que têm necessariamente de ser efectuadas sobre componentes mecânicos reais, inclusivamente para certificação das competências de manutenção mecânica.

É nas fases de carácter prático que a criação de um ambiente virtual 3D de treino, apoiado por avatares automáticos, pode proporcionar vantagens à Força Aérea Portuguesa. Assim, este permite aumentar a eficiência dos momentos de formação, possibilitando aos formandos a prática de tarefas em equipa, de forma simulada, sem a necessidade de envolvimento de recursos físicos.

O conjunto de informações excluídas e apresentadas nesta secção provem de uma entrevista realizada com o responsável da componente de formação da BA5, Major Rui Carvalho. O relatório completo proveniente desta entrevista encontra-se no anexo I desta dissertação.

2.3 – Análise de tarefas

Para facilitar a análise informática do processo de instalação em causa, enquanto processo multi-agente, os dados foram complementados com registos de vídeo e imagem dos processos reais e transformados num guião multi-agente (Teixeira & Pinto, 2010).

Este desdobramento da TO de tarefas em guião multi-agente é muito importante para se aplicar agentes inteligentes em substituição de seres humanos na execução de tarefas em equipa. Por exemplo, sem a identificação clara de quais os papéis a desempenhar por cada avatar numa acção a elaborar em grupo (mais que um mecânico simultaneamente) não teríamos condições para definir um plano ordenado das acções necessárias a executar para concluir o processo, aspecto essencial para a generalidade das abordagens de desenvolvimento de agentes inteligentes.

O capitulo 5 desta dissertação analisa, de forma mais detalhada, o conjunto de tarefas deste processo com o intuito de facilitar a interpretação informática do mesmo.

9 http://www.emfa.pt/www/unidadedetalhe.php?lang=pt&cod=1F300 10 http://portugalfotografiaaerea.blogspot.com/2009/08/fotografia-aerea-base-aerea-da-ota.html

7

2.4 – Requisitos do sistema

Depois de definido, como primeiro objectivo, o processo de instalação de um motor Pratt & Whitney F100 numa aeronave F-16 é necessário identificar os principais requisitos que o sistema terá que satisfazer. Para isso, é indispensável efectuar um processo de análise ao caso de estudo em questão.

Depois de algumas reuniões e da entrevista previamente mencionada com os responsáveis da FAP, conseguimos obter as informações necessárias para caracterizar os utilizadores do sistema, o ambiente ou contexto em que estes estão inseridos e a forma de actuação dos mesmos no sistema.

Os utilizadores do sistema são mecânicos da Força Aérea que pretendem receber a formação nesta vertente. Estes, em ambiente de treino, têm a responsabilidade de desempenhar o papel de um mecânico num processo elaborado em equipa.

Relativamente ao ambiente ou contexto, este decorre, normalmente, dentro de um hangar, local onde se encontram diversos aviões e motores em testes ou manutenção. Este espaço é caracterizado como sendo um local de treino, com a disponibilidade de várias ferramentas para a execução do trabalho.

A nível de actuação dos utilizadores, estes devem efectuar as acções a que são propostos, com base no processo de treino em questão. No entanto, estes podem movimentar-se de forma livre no hangar.

Por sua vez, o sistema deve, de forma remota, possibilitar o treino de mecânicos a qualquer momento. Este deve permitir ao utilizador treinar o processo de instalação juntamente com outros utilizadores, desempenhando assim cada um o respectivo papel atribuído. No entanto, o sistema necessita de estar preparado para permitir o treino mesmo que não esteja completo o número de mecânicos intervenientes, proporcionando deste modo a aplicação de agentes automáticos capazes de desempenhar o papel de um membro do processo. Para além destes aspectos, o ambiente deste sistema terá que ser um ambiente imersivo 3D, o mais próximo possível do contexto real de formação.

Existe um outro trabalho em curso na UTAD, em paralelo deste e na qual este se vai integrar, desenvolvido por outros colegas, que permite criar, em ambiente virtual OpenSimulator, um simulador 3D próprio para a formação de mecânicos da Força Aérea Portuguesa. De realçar que a sua modelação foi baseada no ambiente de treino real destes formandos. Assim, este trabalho aqui apresentado deve-se integrar nesse mesmo trabalho em curso.

Com base nos dados resultantes da análise efectuada podem-se extrair os principais requisitos de integração e funcionais que este sistema terá que cumprir. Desta forma, os requisitos de integração são:

• Utilização da plataforma OpenSimulator • Cada acção do processo de treino apenas pode ser executada pelo mecânico ou

mecânicos que a si são atribuídos • Sistema de decisão deve ser externo em relação à plataforma

O primeiro requisito de integração trata-se de uma necessidade de software. Esta justifica-

se pois, como foi mencionado está em desenvolvimento um ambiente simulado em 3D para este sistema, desenvolvido por outros alunos. Esta plataforma de código fonte aberto apresenta

8

também vantagens em comparação com outras tecnologias, como se poderá ver no capitulo 3 desta dissertação. Por sua vez, o segundo requisito de integração, também referente ao trabalho desenvolvido no âmbito do outro projecto, exige que cada acção do processo de treino possa ser executada, unicamente, pelo mecânico ou mecânicos a si associados.

O outro requisito de integração exige que o sistema de decisão seja externo à plataforma, pois na arquitectura seguida pelo outro trabalho em desenvolvimento, no qual este se vai integrar, definiu-se este principio. Desta forma, esta componente poderá ser acedida no futuro por outros sistemas sem qualquer problema.

Por sua vez, os requisitos funcionais são:

• Possibilidade de uma equipa, em simultâneo, treinar o processo de instalação de um motor Pratt & Whitney F100 numa aeronave F-16

• Possibilidade de uma equipa composta por utilizadores e avatares automáticos, em simultâneo, treinar o processo de instalação de um motor Pratt & Whitney F100 numa aeronave F-16

• Os avatares automatizados devem agir de forma correcta e de acordo com o processo de manutenção mecânica

• Os avatares devem tomar iniciativas sem a necessidade de um comando do utilizador

• Permitir que o comportamento dos mecânicos virtuais sejam razoavelmente semelhantes ao comportamento dos mecânicos reais

• O tempo de resposta dos mecânicos virtuais deve assegurar que a simulação se mantenha credível aos utilizadores humanos

O primeiro requisito funcional aqui mencionado pertence também ao outro trabalho em desenvolvimento, sendo este requisito comum a ambos os trabalhos. Por sua vez, o segundo requisito funcional do sistema leva à possibilidade de uma equipa, composta por utilizadores e avatares automáticos, treinar o processo de instalação, de forma simultânea.

O terceiro requisito exige que os avatares automatizados executem as devidas acções do processo de instalação, de forma correcta. No entanto, o quarto requisito requer que o mesmo tome a iniciativa na execução de acções sem a necessidade de ordem por parte de outro utilizador.

Os restantes requisitos exigem que o comportamento dos mecânicos virtuais e o seu tempo de resposta na execução de tarefas permitam, respectivamente, tornar que estes sejam semelhantes aos utilizadores humanos e proporcionar uma simulação credível aos utilizadores reais do sistema.

9

3 – Mundos virtuais 3.1 – Panorama geral

Apesar da plataforma de mundos virtuais estar definida, esta secção pretende dar um panorama geral das alternativas, para a melhor enquadrar tecnologicamente.

Tem-se verificado, ao longo dos últimos anos, um interesse crescente por mundos virtuais multi-utilizador, sendo estes já utilizados por milhões de utilizadores mundialmente (Woodcock, 2008). Estas plataformas possuem como características comuns a partilha de um espaço, sincronismo, persistência, interactividade entre os utilizadores, socialização e possibilidade de conteúdos gráficos.

“Os universos virtuais já ultrapassaram a fronteira do jogo. Existem hoje espaços para os quais os utilizadores ‘migraram’... onde estudam, trabalham e vivem” (Amaral, 2007). Estes sistemas têm-se tornado cada vez mais presentes no quotidiano dos utilizadores. Existem alguns estudos onde indicam que a utilização média de cada utilizador ronda as 22 horas semanais e a idade média de utilização é de 25,5 anos. Estima-se que, no final de 2011, 80% dos utilizadores da Internet irão utilizar mundos virtuais (Correia & Eiras, 2010).

Segundo Morgado (2009), um mundo virtual define-se como sendo “plataformas informáticas (jogos ou ambientes sociais), onde podem estar telepresentes imersivamente vários jogadores ou utilizadores, que podem comunicar entre si. Ou seja, a participação desses utilizadores no mundo dá-se através de uma personagem virtual (avatar) e – aspecto fundamental – é através deste avatar que o utilizador interage com o mundo e por ele é afectado.”

Os últimos tempos têm proporcionado o nascimento de diversas tecnologias para desenvolvimento de mundos virtuais. De seguida é apresentado, do ponto de vista do programador, a divisão de tecnologias:

• Motores de jogo; • Mundos virtuais comerciais; • Mundos virtuais com criação de conteúdo programado; • Mundos virtuais open source;

Criar um mundo virtual ou jogo de raiz, com as características necessárias, torna-se um processo demasiado complexo e moroso. No entanto, consegue-se fazer um mundo virtual, ainda que simples, utilizando um motor de jogo existente no mercado (ex: Unity 3D, Unreal Engine, etc). Os motores disponibilizam uma série de funcionalidades que podem ser utilizadas pelos programadores de jogos (Pozzer, 2007).

Estes motores de jogo permitem ajudar e abstrair o programador no desenvolvimento, incluindo componentes muito úteis, tais como: motor para renderização de gráficos, um motor para simulação de física ou detecção de colisões, suporte a animações, sons, gestão de memória, ou mesmo suporte a inteligência artificial.

Em contrapartida, a utilização de um motor de jogo pode trazer algumas limitações. Por exemplo, aspectos relacionados com a criação de conteúdo online e com a possibilidade de comunicar com os outros utilizadores do meio (ex: voz, chat) podem não satisfazer as

10

necessidades do sistema pretendido. Certas restrições podem levar à necessidade de alteração ou criação de novos módulos, tornando-se assim um processo mais difícil para o programador.

De um modo geral, os últimos anos têm assistido ao nascimento de imensos mundos virtuais baseados na Internet, cada um deles com objectivos distintos (Leal, 2007). O exemplo mais notável, na categoria de jogos comerciais, é o jogo World of Warcraft, um MMORPG11 com 12 milhões de utilizadores (Correia & Eiras, 2010). Este grupo de mundos virtuais concentra-se na vertente de jogo e apresenta objectivos específicos ao utilizador tais como níveis, vidas ou pontos.

Por outro lado, existem mundos virtuais com determinadas características que se diferenciam de outras tecnologias. Estes, para além de fornecerem um ambiente colectivo e de comunicação, permitem a possibilidade de cada utilizador construir o seu próprio espaço, onde pode desenvolver actividades, interagir com objectos e com outros habitantes. Por sua vez, estas tecnologias permitem que um sistema esteja isolado (tal como acontece em outros sistemas de formação) ou integrado num espaço mais vasto (onde haja, por exemplo, interacção social de grupos diferentes de formandos que andem num ambiente virtual em tarefas distintas). Os mundos virtuais Second Life, OpenSimulator12, Project Wonderland13, Active Worlds14 e Open Cobalt15 são exemplos deste tipo de tecnologias.

Estas tecnologias têm vindo a marcar presença em diversas áreas, um exemplo disso, é a sua utilização como espaço de debate político e agenda social. Existem diversas acções efectuadas, principalmente no ambiente Second Life. É também de realçar a presença da Presidência da República com um espaço neste ambiente. No entanto, existem organizações que se encontram representadas nestes ambientes com o intuito de negócio ou somente de presença.

Destaca-se, essencialmente, o uso destas tecnologias referidas como ambientes virtuais de treino e aprendizagem, sendo este o tema que se vai abordar e que se baseia este projecto.

Para além das funcionalidades conhecidas destes mundos virtuais, as simulações e roleplaying estão entre as potencialidades mais valiosas. Estas plataformas permitem que os utilizadores assumam diferentes papéis e participem em diferentes simulações, praticando habilidades da vida real no espaço virtual e explorando situações das quais eles não poderiam participar com a mesma segurança e facilidade no mundo real.

Os mundos virtuais supra referidos permitem a programação de comportamentos para objectos e avatares do mundo virtual, bem como a sua interacção com sistemas externos. Assim, estes tipo de plataformas tornam-se as mais adequadas para o fim a que esta dissertação se destina: a aplicação de agentes inteligentes capazes de desempenhar o papel de um membro, na execução de trabalhos em equipa.

De seguida serão abordadas as plataformas mencionadas, de forma mais detalhada.

11 Massively Multiplayer Online Role-Playing Games 12 http://opensimulator.org/wiki/Main_Page 13 http://java.net/projects/wonderland/ 14 http://www.activeworlds.com/ 15 http://www.opencobalt.org/

11

3.1.1 – Second Life O Second Life é um mundo virtual 3D desenvolvido e criado pela empresa Linden Lab, em

2003. Este recorre ao protocolo Second Life Grid Open Grid Protocol 16 (SLGOGP). Posteriormente, o mesmo foi tornado público assim como o software cliente Second Life que veio proporcionar o aparecimento de uma nova plataforma alternativa designada OpenSimulator, anteriormente já referida e descrita com mais detalhe na próxima secção.

Esta plataforma divide o espaço virtual em regiões, cada qual com 256x256 metros sendo que toda a informação referente é enviada através de streaming implementado sobre UDP17, tolerando assim a falhas relacionadas com perda e chegada fora de ordem de pacotes (Fitzgerald, 2007).

Ao conjunto de todas as regiões organizadas numa grelha bidimensional dá-se o nome de “grid”, sendo que o conjunto destas resulta num espaço contínuo – onde o conteúdo e todos os utilizadores se ligam ao mesmo mundo a partir de qualquer ponto da grid – existindo a possibilidade de comunicação entre utilizadores em regiões distintas. Cada região pode conter avatares ou objectos, sendo que cada um destes pode conter vários recursos (ex: outros objectos, bloco de notas, texturas, etc) nos seus inventários. Entre os diversos tipos de recursos, é de realçar a existência de scripts que são programas que se executam dentro do mundo virtual. Estes scripts são escritos na linguagem LSL18, baseados em eventos e permitem interagir, dar comportamentos a outros objectos e comunicar com sistemas exterior ao mundo virtual, via Internet.

Cada região é ainda a responsável por efectuar a gestão de todo o conteúdo local (objectos, texturas, programas, sons e animações) que se encontre nessa região, lida ainda com a comunicação entre avatares via chat (“chat público”) e determina as posições dos objectos e avatares que por lá se encontram. O software que faz a gestão de cada região é conhecido como simulador ou sim, normalmente correndo um por CPU (Sequeira, 2009).

A nível de custos de manutenção e alojamento será mais simples alugar uma ou várias ilhas privadas na grid do mundo virtual Second Life, no entanto, há que ter em conta que a criação de objectos (upload de certos elementos – texturas, sons, animações, etc) não é gratuita, tornando-se uma opção dispendiosa a nível monetário quando se pretende a construção de muitos componentes externos.

Para além disso, o Second Life apresenta algumas desvantagens. O facto de estar alojado em servidores situados nas instalações da empresa Linden Lab, torna-se dependente de uma única empresa. É um aspecto a ter em conta quando se pretende desenvolver um sistema próprio de mundo virtual, com disponibilidade total e confidencialidade de dados.

Como já foi mencionado, de entre as várias utilizações do Second Life, destaca-se o seu uso em áreas de ensino e aprendizagem. As figuras 2 e 3 mostram, respectivamente, dois ambientes distintos criados nesse âmbito: exemplo de uma sessão 3D e um campo de andebol criado para treino de movimentações no Second Life (Lopes et al., 2008).

16 http://wiki.secondlife.com/wiki/Open_Grid_Protocol 17 User Data Protocol – protocolo que permite a comunicação entre diferentes computadores, sendo esta comunicação sem conexão, não garante a chegada dos pacotes em ordem particular. 18 Linden Scripting Language (http://wiki.secondlife.com/wiki/LSL_Portal)

12

Figura 2 – Exemplo de aula/sessão no Second Life. [De: http://www.portaleducacao.com.br]

Figura 3 – Campo de andebol, para treino de movimentações no Second Life. (Lopes et al., 2008).

3.1.2 – Project Wonderland

O Project Wonderland, actualmente designado por Open Wonderland, foi desenvolvido e financiado pela empresa Sun Microsystems (recentemente adquirida pela empresa Oracle). Actualmente, este não é financiado pela Oracle e tornou-se um projecto apoiado por uma comunidade independente.

É uma plataforma de software de código-fonte aberto em Java. Esta possibilita a construção de mundos virtuais 3D colaborativos, tendo como principal objectivo fornecer ferramentas de código fonte aberto para a colaboração entre utilizadores e ferramentas de desenvolvimento. Estas ferramentas incluem visualizadores de PDF, HTML e vídeo, apresentação de slides, streaming de vídeo, som e partilha de ambientes de trabalho virtuais.

13

Esta tecnologia baseia-se na arquitectura cliente/servidor usando o servidor de jogos da Sun denominado Project Darkstar19, herdando assim as características de escalabilidade e de infraestrutura de software de persistência do servidor. Além deste servidor, esta tecnologia depende de outros projectos de código fonte aberto, sendo eles: Java3D20, Project Looking Glass21 e jVoiceBridge22.

A interface do Wonderland é flexível e eficiente, pois foi concebida para trabalhar com o Firefox, GIMP, MSN, AutoCAD ou qualquer outro aplicativo que possa ser executado no ambiente gráfico X do Linux (Pereira et al., 2010).

Um exemplo de aplicação baseada nesta plataforma era o espaço virtual da Sun Microsystems, denominado MPK20 (Figura 4), sendo que este mundo virtual tinha o intuito de promover a interacção e colaboração entre os seus funcionários.

Figura 4 – MPK20 [De: http://labs.oracle.com/]

Desta forma, os funcionários da empresa (dos quais muitos se encontram em teletrabalho)

poderiam-se encontrar, colaborar e trabalhar como o fariam num dia-a-dia normal, partilhando documentos, reunindo-se e comunicando por texto ou voz semelhante ao ambiente real.

19 Plataforma open-source middleware, criado pela Sun Microsystems para jogos online multiplayer. Este software de servidor gere as comunicações, o estado e a persistência do ambiente virtual. 20 http://java3d.java.net/ - É uma API que consiste numa hierarquia de classes Java servindo como interface para o desenvolvimento de sistemas gráficos tridimensionais. 21 http://java.sun.com/developer/technicalArticles/J2SE/Desktop/lookingglass/ - É construído em cima da API Java3D e trata da gestão de ambientes 3D. 22 http://java.net/projects/jvoicebridge/ - Fornece som espacial ao projecto Wonderland.

14

3.1.3 – Active Worlds É uma plataforma para disponibilização online de conteúdo 3D em tempo real, com

aplicações empresariais e pessoais. Esta tecnologia permite aos utilizadores conversarem entre si e construir conteúdo 3D. Para aceder a esta plataforma é necessário o uso de um software cliente próprio permitindo este que um utilizador se conecte, explore e comunique. Este software funciona de forma semelhante a um browser web 2D, pois este descarrega toda a informação de um mundo 3D, no momento de acesso ao mesmo.

Esta plataforma é dividida em “mundos”, contendo diversos ambientes para os utilizadores comunicarem e em determinadas áreas, poderem construir o seu próprio espaço. Estes “mundos” podem ser propriedade da empresa que desenvolveu a plataforma (Active Worlds) ou mesmo de utilizadores individuais, podendo estes ser comprados no próprio site da plataforma. Estes “mundos” são limitados ao tamanho, tamanho esse que só permite a criação de conteúdo dentro desse espaço e onde os objectos não podem passar para fora dessa área. Posteriormente, cada proprietário, atribui permissões especificas aos utilizadores do seu espaço.

O universo Active Worlds oferece centenas de mundos para contruir e explorar, no entanto, o principal e mais conhecido mundo, é denominado por Alpha World. A Figura 5 mostra um mundo virtual fornecido por esta plataforma.

O estudo efectuado em Pereira et al. (2009) analisa a utilização desta plataforma como mundo virtual 3D, aplicando este à educação para crianças.

Figura 5 – Plataforma Active Worlds. [De: http://wiki.activeworlds.com/]

15

3.1.4 – Open Cobalt

Anteriormente definida como Open Croquet, esta é uma plataforma de desenvolvimento em código fonte aberto que permite criar mundos virtuais colaborativos e multi-utilizador, possibilitando a integração de aplicações tridimensionais e bidimensionais (Figura 6).

Esta tecnologia usa tecnologia peer-to-peer23 que permite aliviar a carga dos servidores, existindo assim uma menor exigência a nível de largura de banda, o que também é vantajoso para utilizadores de redes sem fios. Por sua vez, esta plataforma ainda não demonstrou encontrar-se preparada para um grande número de utilizadores em simultâneo, uma vez que em caso de ocorrência de erros obriga o reinício do servidores onde estes ocorrem (VanDrimmelen, 2007).

Assim, esta permite a interligação de mundos virtuais distintos, construídos por cada utilizador, sendo executado em computadores pessoais ou servidores, isto é, não existe um único mundo virtual, mas sim vários, que poderão estar ou não interligados.

Figura 6 – Exemplo de utilização da plataforma Open Cobalt.

[De: http://www.opencobalt.org/about/uses/]

23 É uma arquitectura de sistemas distribuídos caracterizada pela descentralização das funções na rede, onde cada nó pode realizar funções de servidor assim como de cliente.

16

3.2 – OpenSimulator

A plataforma OpenSimulator foi a tecnologia seleccionada para desenvolver o objectivo desta dissertação, conforme se expôs no capitulo de introdução desta dissertação. Para além de algumas vantagens relativamente a outras tecnologias, que de seguida são abordadas, esta escolha deve-se também ao facto de existir um requisito de integração deste projecto, que leva à necessidade de desenvolver o mesmo na plataforma OpenSimulator.

Esta tecnologia permite o desenvolvimento de um ambiente virtual standard para que qualquer aplicação o use como uma framework, possibilitando com facilidade a criação e personalização de um mundo virtual próprio.

É uma plataforma desenvolvida em C#, correndo em sistemas Windows através da framework .NET e em sistemas baseados em Unix através da utilização da framework Mono. Esta é de código-fonte aberto e permite utilizar a mesma tecnologia de software-cliente que o Second Life, embora nem todas as funcionalidades estejam ainda integradas nos servidores OpenSimulator. Em contrapartida, existem algumas funcionalidades que só funcionam com os servidores OpenSimulator. Esta tecnologia surgiu depois de tornado público o protocolo de comunicação entre servidores Second Life Grid e o software cliente Second Life.

Este protocolo, denominado Second Life Grid Open Grid Protocol (SLGOGP), permite aos mundos virtuais construídos a partir das plataformas Second Life Grid ou OpenSimulator apresentarem imensas características em comum. O seu espaço virtual é dividido em pedaços ou regiões que podem variar de tamanho, podendo ter regiões com maiores proporções que o Second Life, fornecendo meios de acesso e de privacidade em subdivisões, permitindo assim que os utilizadores controlem o ponto de vista (câmara) independentemente do movimento do avatar. Tal como acontece no Second Life, ao conjunto de regiões, organizadas numa grelha bidimensional, dá-se o nome de “grid”, no entanto, um servidor pode alojar várias regiões e uma “grid” pode ser composta por regiões alojadas no mesmo servidor ou estarem distribuídas por vários.

A implementação de soluções que recorram à utilização do protocolo é facilitada pela existência da biblioteca libopenmetaverse24, em código-fonte aberto, que permite iniciar sessões de clientes em servidores e, de forma mais simplificada, aceder às várias funcionalidades do protocolo. É através da utilização desta biblioteca que será possível integrar avatares automatizados nesta plataforma.

As implementações subjacentes das plataformas Second Life e OpenSimulator são diferentes, mas são habitualmente transparentes do ponto de vista do software-cliente (por exemplo, enquanto os servidores Second Life Grid armazenam alguma informação num servidor de ficheiros, o OpenSimulator utiliza uma base de dados para o mesmo efeito, sendo que esta situação é transparente para o software-cliente) (Sequeira, 2009).

Apesar de se estar a tornar mais estável e perto de uma versão 1.0, o projecto OpenSimulator é considerado ainda um produto em fase inicial (alfa), o que indica que existe um desenvolvimento contínuo através do código-base e sem data de lançamento oficial. Existe um número considerável de colaboradores que trabalham nos vários componentes, quer no desenvolvimento, quer na detecção e correcção de erros (Pereira et al., 2010).

Todos os recursos principais do Second Life Grid estão presentes no OpenSimulator, no entanto, realçam-se os objectos 3D, inventário e scripts que são os principais recursos

24 É uma biblioteca cliente/servidor, anteriormente conhecida por libSecondLife, desenvolvida em .Net, que permite aceder e criar mundos virtuais 3D que implementem o protocolo Second Life (http://lib.openmetaverse.org/wiki/Main_Page)

17

utilizados para a elaboração do projecto. A criação de objectos, em ambientes OpenSimulator, é semelhante à que acontece no Second Life, com a possibilidade de criar objectos com maiores dimensões e construir até 45 mil objectos, ao contrário dos 15 mil permitidos no Second Life. Existem ainda outras diferenças e limitações entre estas duas plataformas que podem ser encontradas no estudo efectuado em Vilela et al. (2010).

Existem duas abordagens possíveis para permitir a comunicação com sistemas exteriores ao mundo virtual, via Internet. Uma delas, que já foi aqui mencionada, é através da utilização de scripts (escritos na linguagem LSL) que correm no servidor, baseados em eventos, permitindo assim aceder a sistemas externos e interagir com os vários componentes do mundo virtual. A outra forma possível, é através do uso da biblioteca libopenmetaverse que permite a criação de clientes automatizados ou bots25, capazes de comunicar com diferentes sistemas e usufruir das diversas funcionalidades que o OpenSimulator proporciona.

Ao nível da execução, o OpenSimulator utiliza ficheiros de configuração para definir os parâmetros necessários ao arranque e funcionamento deste. O ficheiro inicial é o OpenSim.ini, que se encontra no directório /bin, onde se encontra a configuração geral do sistema, das quais se incluem parâmetros dos módulos, da grid, entre outros. Este ficheiro é suportado por outros ficheiros de configurações das regiões (baseados em XML), de serviços de rede e de configuração da cache. A parte central do OpenSimulator é definida por entidades, funções e serviços que fornecem a base para um simulador de física, motor de script local e um gestor de utilizadores.

Uma configuração completa do OpenSim consiste na componente das regiões e nos serviços necessários a todo o seu funcionamento. Destes serviços destacam-se o serviço de utilizadores, serviço de gestão de inventário, serviço de grid e serviço de activos. A forma como os serviços são executados pode ser feita em dois modos distintos: em standalone (forma independente) ou em gridmode (integrado numa grelha de servidores) (OpenSimulator, 2011).

Um sistema implementado em modo standalone, executa o simulador de regiões e todos os serviços num único processo, ou seja, num único executável: OpenSim.exe (OpenSimulator, 2011). Por sua vez, quando executado em modo gridmode, os vários aspectos da simulação são separados e divididos em múltiplos processos, podendo estes ser executados em diferentes máquinas, proporcionando assim a criação de um sistema dimensionável.

25 Avatar automatizado, controlado por uma aplicação externa.

18

3.3 – Utilização de agentes inteligentes e seu impacto

A utilização de agentes inteligentes, em ambientes semelhantes ao que este projecto

apresenta, pode proporcionar diversas funcionalidades e serviços aos intervenientes do sistema. Os agentes podem desempenhar diferentes tipos de papéis para tal efeito.

Avanços significativos nas áreas de tecnologia e comunicação têm proporcionado novas oportunidades de forma a facilitar a aprendizagem humana através de tecnologias como agentes inteligentes (Baylor, 1999).

A aplicação de agentes inteligentes como personagens ou guias de navegação em ambientes de realidade virtual, bem como na sua interacção com outros utilizadores neste tipo de ambientes têm sido alvo de alguns trabalhos científicos (Araujo et al., 2007).

Agentes inteligentes, quando aplicados a sistemas de aprendizagem e treino, têm o papel de auxiliar e melhorar a qualidade do sistema educativo. Estes agentes pedagógicos devem possuir, pelos menos uma, das seguintes características: comunicar com outros alunos, cooperar em determinada tarefa, capacidade para discutir e interagir, ajudar e saber ensinar. A prioridade destes agentes passa por tentar estimular os alunos de forma a darem o melhor no processo de aprendizagem (Garrido et al., 2010).

Um agente inteligente pedagógico pode agir de diferentes formas e com diferentes papéis em determinada situação. Este pode actuar como professor, apoiar no processo de aprendizagem ou mesmo participar como um colega estudante em determinado ambiente colaborativo. Um agente inteligente pode também orientar um aluno no ambiente virtual, explicar conteúdos, efectuar perguntas, dar feedback e dar apoio no processo de aprendizagem, actuando em todos os momentos em conformidade com a necessidade ou objectivo do aluno. É particularmente importante que o agente actue sempre de forma pedagógica (Soliman & Guetl, 2010).

Alguns estudos concluem que se o agente se assemelhar e interagir como um ser humano, este irá reforçar o processo de aprendizagem e aumentar a motivação dos alunos (Atkinson, 2002). Estes agentes inteligentes pedagógicos permitem assim aumentar o envolvimento dos alunos, proporcionar novos valores e formas de aprendizagem, melhorar as interações entre o computador e o aluno bem como actuar como uma personagem integrante do sistema.

Existem outros factores importantes que podem influenciar, dependendo do tipo de ambiente a que os mesmos se destinam, no processo de aprendizagem: comportamento dos agentes, modos de interacção e de comunicação (chat, voz ou gestos), papel social do agente (expert, motivador e orientador), entre outros.

Na figura 7 é mostrado o STEVE26, um dos agentes pedagógicos virtuais mais conhecidos, desenvolvido pelo USC Information Sciences Institute’s Center for Advanced Research in Technology for Education27 (CARTE) (Johnson & Rickel, 1999). Este agente, aplicado ao treino de funções navais, tem o objectivo de interagir com os estudantes, efectuando a demonstração de algumas tarefas e ajudar na execução das mesmas. A figura 8, é apresentada a Adele28, outro agente pedagógico criado pela mesma instituição. Este agente, corre no browser e foi desenhado para integrar materiais de ensino electrónicos. Este foi essencialmente usado para fins medicinais.

26 Soar Training Expert for Virtual Environments 27 http://www.isi.edu/isd/carte/ 28 Agent for Distance Learning: Light Edition.

19

Figura 7 – Agente pedagógico: Steve. (Johnson & Rickel, 1999).

Figura 8 – Agente pedagógico: Adele. (Johnson & Rickel, 1999).

Por sua vez, a figura 9 apresenta o agente pedagógico criado pela North Carolina State

University29, Herman the Bug. Este agente, representado por um insecto, tinha o intuito de interagir com as crianças num sistema de aprendizagem no domínio da fisiologia e anatomia de plantas. Enquanto que as crianças interagiam com o sistema, o agente observava as suas acções, fornecendo explicações em diversos momentos. Durante este processo, este efectuava diversas animações (ex: andar, voar, nadar, pescar, teletransporte, saltos, etc).

29 http://www.ncsu.edu/

20

Figura 9 – Agente pedagógico: Herman the Bug. (Johnson & Rickel, 1999).

No entanto, é importante reflectir sobre a aplicação de agentes inteligentes em determinados ambientes virtuais 3D. Estes podem proporcionar algumas desvantagens; o uso de ambientes virtuais 3D ou agentes inteligentes podem distrair os alunos dos objectivos principais do curso; a aparência e o comportamento do agente inteligente, por vezes, está longe da aparência humana e pode afectar pela negativa o sistema de aprendizagem (Garrido et al., 2010).

21

4 – Abordagens de Inteligência Artificial 4.1 – Algoritmos de Planeamento

A Inteligência Artificial é uma área da ciência da computação, nascida em 1943, que estuda e compreende métodos ou dispositivos que simulem a capacidade humana de raciocinar, perceber, tomar decisões e resolver problemas (Ciriaco, 2008). Esta área encontra-se presente em diversos tipos de sistemas do nosso dia-a-dia.

De entre as técnicas de Inteligência Artificial, é o planeamento automatizado que melhor se adequa às necessidades deste projecto tendo em conta os requisitos do mesmo. Este sistema necessita de gerar, de forma automática, o plano de acções referente ao processo de manutenção mecânica em questão, possibilitando assim a aplicação de agentes inteligentes ao sistema.

O problema do planeamento está entre as áreas mais importantes da Inteligência Artificial, pois inicialmente integrou duas das suas principais áreas: a pesquisa e a prova de teoremas (Russel, 2004).

No entanto, o planeamento automatizado está intimamente ligado ao raciocínio. Um programa com capacidade de planear é capaz de fazer escolhas hipotéticas, estabelecer compromissos e ordenar as suas escolhas segundo os critérios que melhor servem os seus objectivos. O planeador consegue ainda avaliar se os compromissos tomados até então conduzem a um plano completo e coerente (Caeiro et al., 2001). O planeamento é feito com o objectivo de atingir um estado final, baseando-se num conjunto de estados iniciais do sistema.

Qualquer exercício ou conjunto de tarefas de nível prático necessita de uma representação do seu conhecimento, de maneira a poder ser interpretada por técnicas de planeamento. Essa representação deve ser composta por estados, objectivos e acções. Os estados são expressões básicas que descrevem características iniciais do mundo analisado (ex: Livre(B) – O objecto “B” encontra-se no estado “Livre”); os objectivos são expressões que, através de estados, representam o objectivo final pretendido; as acções são todas as operações possíveis de serem executadas no mundo analisado. Por sua vez, cada acção tem que ter associado um conjunto de pré-condições e pós-condições.

A representação do conhecimento é um dos pontos mais importantes no desenvolvimento de um bom planeamento, uma vez que define não só os tipos das pesquisas a serem executadas como até mesmo a viabilidade de se fazer uma pesquisa ou não (Amorim et al., 2009). Uma escolha fraca de estados, objectivos e acções pode tornar complexo todo o processamento.

Foram desenvolvidas algumas linguagens com o intuito de serem capazes de expressar a maior quantidade possível de problemas e ao mesmo tempo simples o suficiente para ser adaptável em algoritmos. Destaca-se a linguagem STRIPS30, conhecida como a linguagem básica de representação de planeadores clássicos. Com o desenvolvimento da área de planeamento, apareceram problemas mais complexos e foi exigido que linguagens mais expressivas fossem criadas. Destas linguagens, destacam-se a ADL31 e a PDDL32.

Contudo, é a linguagem STRIPS que merece especial atenção pois foi aquela em que se baseou uma etapa do trabalho desta dissertação.

30 Stanford Research Institute Problem Solver 31 Action Description Language 32 Planning Domain Definition Language

22

Um sistema composto no formato da linguagem STRIPS é formado, tal como já foi referido, por um estado inicial, um objectivo final a atingir e um conjunto de acções possíveis, tendo cada uma delas uma denominação, pré e pós-condições associadas à mesma. É importante referir que um sistema, para além do estado inicial e final, deve ser representado na forma mais simples possível, isto é, possuir acções bem especificadas. A figura 10 apresenta um exemplo de representação no formato da linguagem STRIPS.

Figura 10 – “The monkey wants the bananas that hanging from the ceiling in location B”.

Depois de um sistema estar definido na linguagem STRIPS torna-se mais fácil a interpretação do mesmo por algoritmos ou outro tipo de estruturas. No entanto, a escolha do algoritmo adequado terá que ser com base numa análise específica a cada problema, pois cada algoritmo tem as suas características próprias. Existem diversos algoritmos, mas para a componente de ordens e planeamento de tarefas, iremos abordar dois tipos de algoritmos: partial-order planning e total-order planning.

Os algoritmos baseados em partial-order planning são algoritmos que constroem um plano sem uma ordem exacta de execução. São caracterizados como sendo algoritmos não determinísticos pois, existem diversas formas e caminhos para se conseguir atingir o objectivo final, não sendo obrigatório haver um determinado caminho específico. Um plano gerado por estes algoritmos é composto por quatro componentes: um conjunto de acções, uma ordem parcial para as acções, um conjunto de relações causais, um conjunto de condições em aberto, isto é, aquelas condições que ainda não foram cumpridas por nenhuma acção do plano parcial. Estas quatro componentes são tratadas durante o processo de geração do plano parcial, processo este que se inicia no estado inicial do sistema e termina quando não existem mais condições em aberto e o objectivo final foi atingido. Este tipo de algoritmos, em cada iteração, identificam

23

uma acção com pré-condição não satisfeita, introduz no plano a acção cuja pós-condição satisfaz a pré-condição não satisfeita, actualiza os links causais e verifica se existem lacunas no plano, corrigindo o mesmo em caso de problemas (Costa, 2010). Estes algoritmos são muito completos e geralmente produzem óptimas soluções, contudo estes algoritmos podem encontrar dificuldades em gerar um planeamento correcto quando aplicados a sistemas muito complexos ou possuírem uma representação do conhecimento fraca.

Por sua vez, os algoritmos baseados em total-order planning são semelhantes aos anteriores, pois ambos têm a mesma estrutura e visam atingir uma determinada meta. No entanto, estes algoritmos geram um plano que consiste num conjunto de acções sequenciais, com uma determinada ordem especifica de execução. A figura 11 mostra exemplos de planos gerados por algoritmos de ambos os tipos.

Figura 11 – Planos de ordem parcial e total (Costa, 2010).

24

4.2 – Partial Order Planning

A escolha do tipo de algoritmo é um processo muito importante no desenvolvimento de um planeador. Esta escolha depende muito das características do sistema ao qual o mesmo se vai destinar.

Desta forma, o sistema a ser aplicado trata-se de um processo executado em equipa, composto por diversas acções (com pré e pós-condições associadas), podendo cada uma delas ser efectuada por um actor específico ou mesmo em equipa. De realçar que, em determinado tempo do processo, não existe ordem específica de execução de tarefas. Assim sendo, com base nas características do sistema pretendido, um algoritmo baseado em partial-order planning é o mais adequado.

Para iniciar o desenvolvimento do algoritmo, foi preciso primeiramente elaborar a representação do conhecimento do sistema, em linguagem STRIPS. Esta etapa é explicada com mais detalhe na secção “Análise de tarefas do caso de estudo”, do próximo capitulo. Depois de elaborada a representação do conhecimento e de seleccionado o tipo de algoritmo adequado, passou-se ao desenvolvimento do algoritmo em si. Para além de existirem diversas implementações deste tipo de algoritmo, este foi criado praticamente de raiz. Foi desenvolvido na linguagem C# e, através dos parâmetros de entrada do sistema, gera um plano parcial das acções para o sistema pretendido.

É importante mencionar que o algoritmo desenvolvido sofreu algumas adaptações de forma a gerar um plano tendo em conta os actores a atribuir em cada acção. Estas alterações levaram à adição de um novo campo em cada acção do plano, identificando assim qual o mecânico ou mecânicos que desempenham determinada operação.

25

5 – Arquitectura e modelo de integração

5.1 – Definição da arquitectura

No sentido de atingir o objectivo desta dissertação, foi necessária a elaboração de uma arquitectura que permitisse a aplicação de avatares automatizados, controlados pelo sistema de decisão, ao processo de treino 3D em mundo virtual OpenSimulator. O esquema seguinte (Figura 12) visa dar uma ideia geral da arquitectura implementada.

Figura 12 – Arquitectura do sistema. Este sistema, para dar resposta aos requisitos do mesmo, exige o funcionamento de várias

componentes associadas a si, que se encontram detalhas no próximo capitulo. Para tal, foi necessário configurar um servidor de OpenSimulator, um servidor Web e criar uma base de dados para o sistema. Deste modo, a arquitectura permite também ao utilizador aceder ao mundo virtual.

26

5.2 – Espaço 3D

Esta secção apresenta, de uma forma geral, o espaço virtual 3D criado no âmbito do trabalho desenvolvido pelos outros colegas, para acolher e proporcionar exercícios de treino mecânico ao nível do processo de instalação de um motor em aeronave F-16. Este espaço tenta reproduzir um ambiente de treino similar ao que os mecânicos da FAP encontrariam em contexto real de formação.

Neste ambiente de treino 3D podem-se encontrar diversos elementos característicos do dia-a-dia de um qualquer profissional da Força Aérea, nomeadamente, a presença de vários aviões F-16, de motores de avião, mesas de ferramentas e um hangar.

Figura 13 – Hangar para formação de mecânicos. É dentro deste hangar (Figura 13) que se encontram todas as partes necessárias para a

formação dos mecânicos. Podemos também encontrar um avião para ser usado no processo de treino (Figura 14) ou mesmo encontrar motores prontos a iniciar a sua utilização (Figura 15). Outros tipos de itens, tais como peças necessárias no processo de formação ou parafusos estão ocultos, estando unicamente visíveis quando o processo de treino estiver a decorrer.

27

Figura 14 – Avião F-16 disponível para formação.

Figura 15 – Motor Pratt & Whitney F100 pronto para formação.

28

5.3 – Análise de tarefas do caso de estudo

Tal como foi referido no capitulo 2 desta dissertação, em conjunto com os responsáveis da formação da Base Aérea Nº5, definiu-se como objectivo inicial o processo de instalação de um motor Pratt & Whitney F100 numa aeronave F-16. Esta secção vai analisar esse processo e apresentar as soluções adoptadas de forma a facilitar a interpretação informática do mesmo.

O processo de análise e representação é muito importante para se desenvolver uma boa representação do sistema e consequentemente um bom planeamento. Desta forma, a análise de tarefas do sistema pretendido é uma etapa muito importante deste trabalho pois o seu resultado reflecte-se noutras etapas do mesmo.

De realçar que a descrição ou representação de tarefas de um sistema deve ser feita da forma mais simples possível. Deste modo, possuir acções bem especificadas e com poucas alterações associadas a si, permite futuramente, de uma maneira mais fácil, resolver questões relacionadas com erros no momento da sua execução. Por exemplo, se uma acção estiver devidamente especificada, em caso de execução incorrecta, conseguir-se-á obter com mais precisão um nível de erro, conseguindo saber assim mais informações quanto ao problema encontrado, o que permite ajudar o aluno ou formando que errou.

O processo de instalação referido, em contexto real, exige a presença de quatro mecânicos (Figura 16). Geralmente, três mecânicos desempenham o papel normal na instalação do motor e um quarto mecânico que desempenha o papel de supervisor.

Figura 16 – Mapa de localização de cada mecânico. A primeira tarefa do processo de treino (o esquema de acções e o protocolo completo do

processo de instalação são apresentados no anexo II e anexo III, respectivamente) consiste em remover quatro parafusos da fuselagem do avião F-16, com a intenção de posteriormente se instalar as pads33 na fuselagem do avião. Esta é uma tarefa elaborada em grupo, pelo que, os quatro mecânicos têm um determinado papel na mesma. Assim, esta tarefa é constituída por quatro acções, tendo cada mecânico a responsabilidade de executar uma. Cada uma destas acções tem o objectivo de remover um parafuso; a execução de cada uma terá associada uma alteração no estado do sistema.

33 São peças que se instalam no avião (uma de cada lado) com o intuito de auxiliar no processo de instalação do motor.

29

No entanto, esta tarefa deve ser representada por uma acção genérica de remoção de um parafuso (Figura 17), sendo esta posteriormente replicada 4 vezes para cada slot de parafuso necessário, representando desta forma a tarefa de remoção dos quatro parafusos (Figura 18).

Figura 17 – Acção genérica para remover um parafuso.

Figura 18 – “Remover quatro parafusos da fuselagem do avião”.

A figura 17 mostra o formato da representação adequada, na forma de uma acção genérica.

Neste caso, esta acção desempenhada por um determinado mecânico “mec” permite que um parafuso “p” passe do estado Apertado para Desapertado em determinado slot “s”, ou seja, a variável do tipo parafuso sofreu alterações ao nível do seu estado passando de Apertado para Desapertado. Esta acção apresenta uma pré-condição e uma pós-condição, que definem as alterações de estado do sistema antes e depois da execução da mesma. Posteriormente, o algoritmo com base nos estados do sistema irá gerar um conjunto de acções para satisfazer as tarefas do processo. Desta forma, a figura 18 apresenta o resultado, após o processamento do algoritmo, para definir a tarefa de remoção dos quatro parafusos no plano.

Por exemplo, a acção de remover o parafuso 1 tem a pré-condição “Apertado(s1, p1)” e a pós-condição “~Apertado(s1, p1)”. Assim, depois desta acção ser executada correctamente, o parafuso “p1” deixou de estar apertado no slot “s1” da fuselagem do avião.

Assim sendo, em caso de execução incorrecta de uma acção por parte de um mecânico, as restantes acções associadas aos outros mecânicos não são afectadas, sendo possível a sua distinção. Desta forma, em caso de intervenção incorrecta de um aluno/formando ou mesmo inacção, o sistema pode encontrar o ponto concreto em falha. Por sua vez, uma tarefa de grupo

30

só é considerada concluída quando todas as acções forem executadas correctamente. Além disso, só se prossegue para a tarefa seguinte quando se concluir uma tarefa de grupo por completo.

Uma outra tarefa do processo consiste em instalar três apoios no carro de instalação do motor na aeronave. Tal como a tarefa anterior, esta é uma tarefa de grupo e deve ser executada pelos mecânicos intervenientes. Esta tem como objectivo instalar três apoios de forma a elevar o motor para que possa posteriormente ser introduzido no avião.

Neste caso, ao representar uma acção genérica para instalar um apoio no motor (Figura 19), posteriormente, replicando esta pelo número de apoios a instalar, permite definir a tarefa de instalação dos três apoios (Figura 20).

!!!!!!!

Figura 19 - Acção genérica para instalar um apoio no motor.

!!

Figura 20 – “Instalação de três apoios no motor”.

A acção genérica de instalar um apoio (figura 19) apresenta o formato adequado de representação. Por sua vez, a figura 20 mostra aquilo que seria o resultado da definição da tarefa de instalação dos 3 apoios no motor, após o processamento do algoritmo.

Cada acção, quando executada, permite alterar o estado de um determinado apoio no sistema. Neste caso, um determinado mecânico “mec” executa a acção, permitindo assim que um apoio passe do estado “~InstaladoApoio(ap)” para “InstaladoApoio(ap)”, sendo a variável “ap” um apoio do motor. Como se referiu anteriormente, o processo de instalação do motor na aeronave F-16 é efectuado por quatro mecânicos. Nesta tarefa específica, três deles têm o papel de instalar os três apoios (um por mecânico) e o quarto mecânico supervisiona a tarefa, verificando posteriormente se a instalação dos componentes foi executada correctamente. Esta tarefa de supervisionamento, efectuada pelo quarto mecânico, é a seguinte acção do processo.

Em suma, a análise do processo para execução por parte de agentes inteligentes consiste em representar o sistema em acções genéricas de forma a poderem ser manipuladas pelo algoritmo, sendo estas posteriormente utilizadas no plano para satisfazer as condições do mesmo. Os

31

anexos II e III exibem o resultado da análise do processo completo, sendo respectivamente, a representação das acções do sistema e o protocolo de instalação do motor na aeronave F-16. No entanto, é importante referir que, apesar de ser efectuada uma análise a todas as tarefas do caso de estudo, o protótipo implementado neste trabalho não se encontra totalmente finalizado, estando preparado para treino até à tarefa de instalação dos três apoios no motor, necessitando deste modo, num futuro próximo, de adaptação para as restantes acções do processo em falta.

Desta forma, consegue-se implementar um sistema com agentes inteligentes capazes de desempenhar o papel do ser humano, proporcionando assim um ambiente de treino individual com ampla liberdade de acção que possa ser efectuado por uma equipa de formandos com menos pessoas do que as necessárias à execução da tarefa, por apenas uma pessoa, ou até mesmo sem qualquer pessoa, apenas para observação da tarefa em execução automática por avatares controlados.

32

5.4 – Conversão de acções para ambiente 3D

O plano de acções, suas ordens e respectivos actores, resultantes do processamento do

algoritmo baseado em partial-order planning, sofreram modificações de forma a adaptarem-se ao ambiente de treino 3D pretendido. Esta etapa do projecto converteu cada acção do plano em acções no mundo virtual 3D.

Por exemplo, a acção de remover um determinado parafuso, traduziu-se em quatro acções no ambiente 3D: chegar junto da fuselagem do avião, fazer take34 do objecto parafuso, deslocar-se para junto da mesa de ferramentas e fazer rez35 desse mesmo parafuso em cima da mesa. Estas quatro acções são ilustradas nas figuras 21, 22, 23 e 24, respectivamente. !!

!!!!!!!!!!!!

Figura 21 – Acção “chegar junto da fuselagem do avião”.

O processo de remoção de um parafuso inicia-se nesta primeira acção. Esta acção leva à necessidade do mecânico, representado pelo avatar, deslocar-se até junto da fuselagem do avião, local onde grande parte do processo de treino se desenrola.

Esta deslocação é feita através dos comandos de movimentação disponíveis, que se encontram no software cliente utilizado para aceder ao mundo virtual. No caso do avatar ser representado por um bot, este faz a movimentação através da utilização de funções disponíveis na biblioteca libopenmetaverse.

34 Acção de pegar um objecto, colocando-o no inventário 35 Largar um objecto no mundo 3D proveniente do inventário

33

Figura 22 – Acção “fazer take do objecto parafuso”.

A segunda acção, que exige que o avatar se encontre junto à fuselagem do avião, trata-se de seleccionar o parafuso e escolher a opção take. Após esta acção, o parafuso foi desapertado e ficou no inventário do respectivo avatar.

Figura 23 – Acção “deslocar-se para junto da mesa de ferramentas”.

34

A terceira acção, que deve ser executada depois do parafuso estar desapertado, consiste na deslocação do mecânico desde a zona de trabalhos no avião até à mesa de ferramentas.

Figura 24 – Acção “fazer rez do parafuso em cima da mesa”. A quarta e última acção, resume-se à necessidade do avatar colocar o parafuso

anteriormente guardado, proveniente do seu inventário, em cima da mesa de ferramentas. Este processo de conversão para adaptação ao ambiente 3D foi repetido para todas as

acções do plano, possibilitando assim a implementação de agentes inteligentes no ambiente de treino 3D. O documento anexo IV apresenta alguns exemplos de conversão das acções para adaptação ao ambiente 3D.

35

6 – Sistema desenvolvido 6.1 – Funcionamento do sistema

O funcionamento do sistema, de um modo geral, tem início quando são dadas ordens ao mesmo para iniciar o processo de treino. Após esta ordem, o sistema gera um plano de acções resultante do processamento do algoritmo e guarda esses dados em base de dados de forma a poder consultá-los durante o processo. Posteriormente, os objectos 3D comunicam via pedidos HTTP com um servidor web de forma a manter sincronismo e registo de estados entre si. Por sua vez, em caso de necessidade de mecânicos no inicio do treino, os avatares iniciam o respectivo papel que lhes é atribuído. Consequentemente, a presença de mecânicos virtuais durante o processo de treino, leva à necessidade do sistema calcular e atribuir o seu comportamento, de forma dinâmica.

A abordagem seguida em Lopes et al. (2008) assemelha-se à abordagem utilizada neste trabalho. As próximas secções explicam, com mais detalhe, as componentes que permitem o completo funcionamento do sistema.

6.1.1 – Avatares automatizados

Os avatares automatizados, controlados pela componente de decisão, são clientes capazes de interagir e comunicar através das diversas funcionalidades que o OpenSimulator proporciona. Tal como referido na secção anterior acerca do OpenSimulator, isto só é possível através da utilização da biblioteca libopenmetaverse. Visto esta biblioteca ter sido desenvolvida em .Net, optou-se por criar os mecânicos virtuais através da linguagem C#. Esta biblioteca permite efectuar acções dentro do mundo virtual sem a necessidade de utilizar um software cliente para acesso ao mesmo, através desta consegue-se iniciar a sessão dos avatares e programar diversos comportamentos (acções, deslocações, gestos) de forma a desempenharem as suas funções.

Inicialmente, pensou-se em ter um plano de acções do processo de treino por cada avatar, no entanto, com a necessidade de sincronização com o sistema e de ligação ao conjunto de acções convertidas para o mundo 3D, desistiu-se desta abordagem. Optou-se por guardar as informações do processo de treino, o estado actual de execução e o conjunto de tarefas para cada avatar executar em base de dados externa a cada um. É importante referir que a inteligência do avatar no mundo é calculada dinamicamente por parte do sistema. Através do estado do processo de treino no ambiente 3D, o sistema gera o comportamento a tomar pelos avatares para atingir os objectivos. Pode-se assim concluir que o sistema de mecânicos automatizados é constituído por um agente (componente de decisão) e um conjunto de quatro avatares (componentes visuais) controlados por esse mesmo agente.

Cada avatar pode representar o papel de um determinado mecânico. Para tal, foram criados quatro programas, sendo cada um destinado ao papel de cada mecânico no processo de treino. Estes, têm muitas características em comum, nomeadamente questões relacionadas com o login, movimentações no mundo virtual, execução de tarefas e logout do avatar no fim do treino.

Estes programas foram implementados de forma a estar em permanente verificação de tarefas, ou seja, estes verificam de 5 em 5 segundos se existem novos comportamentos a serem

36

executados, com base no estado actual do processo de treino. Estes dados encontram-se guardados em tabelas da base de dados desenvolvidas para apoiar o sistema.

No caso de existirem tarefas por efectuar, o cliente automatizado, através das funções disponíveis na biblioteca libopenmetaverse, desempenha a tarefa no espaço 3D. Após a sua conclusão, essa tarefa é actualizada na base de dados, passando ao estado resolvido. No entanto, o avatar antes de executar um comportamento verifica se este pode ser executado e se é adequado com base no estado do sistema, ou seja, através do estado das tarefas resolvidas e das relações entre a lista de links e ordens parciais de acções provenientes do planeamento, o programa consegue assim sincronizar-se com o sistema, permitindo deste modo esperar pela realização de tarefas por parte de outros mecânicos ou mesmo determinar o momento certo para avançar para o próximo passo.

A adopção desta metodologia permite a existência de sincronismo e conhecimento do estado do sistema por parte de qualquer interveniente no mesmo.

6.1.2 – Objectos 3D

Os objectos 3D intervenientes no sistema necessitam de efectuar comunicação entre si ou comunicação com sistemas externos. Estes conseguem comunicar através da utilização de scripts, escritos na linguagem LSL, baseados em eventos. Os scripts, para além da troca de informações com sistemas exteriores, permitem interagir e dar comportamentos a objectos.

Assim, cada objecto interveniente no sistema, através do uso de scripts que correm do lado do servidor, comunicam com o servidor Web, sendo esta comunicação através de pedidos HTTP. Desta forma, um objecto 3D, quando necessita de registar ou obter informação executa a função llHttpRequest que irá efectuar um pedido HTTP ao Web Service desenvolvido.

No entanto, existem outros objectos que não fazem comunicação com outros sistemas. Estes trocam informações com objectos através do uso de canais privados, dentro de uma região (llRegionSay). Neste tipo de processo de troca de mensagem, o objecto remetente indica o canal que pretende transmitir informação no momento do envio e o objecto destinatário necessitará de estar à escuta nesse mesmo canal. Este tipo de comunicação via canais privados é utilizado, por exemplo, quando se inicia o processo de treino permitindo deste modo reiniciar o estado de todos os objectos 3D participantes no sistema.

O código dos scripts criados, em linguagem LSL, para estes objectos 3D encontram-se no documento anexo V.

6.1.3 – Web Services Esta é a componente que desempenha o papel de decisão no sistema, é aqui que são

atribuídos os comportamentos a cada avatar, de forma dinâmica. Através da análise do estado do processo de treino no ambiente 3D, gera o comportamento ou tarefas que cada mecânico automatizado deverá ter para atingir os objectivos e manda os mesmos executarem esse resultado, em determinados momentos do processo.

Esta componente funciona também como uma ponte entre o mundo virtual 3D e a base de dados do sistema. São estes Web Services que permitem a obtenção ou registo de dados no

37

sistema. Estes serviços web são baseados em REST36 e permitem a comunicação HTTP através da utilização de operações GET37. A resposta destes serviços encontra-se estruturada na linguagem XML.

Os Web Services têm o objectivo de fornecer os métodos adequados e necessários para adaptar o espaço 3D a um ambiente de treino. Desta forma, foram criados dois Web Services para satisfazer as necessidades do mesmo.

O primeiro serviço, denominado “ProcessoInstalacao”, apresenta os principais métodos, como por exemplo: obter os dados da próxima acção a executar por determinado mecânico ou mesmo registar uma tarefa como concluída. Também é o responsável, no início do processo, por aceitar o número de mecânicos reais fazendo posteriormente a gestão dos avatares automáticos a participar no processo. É também este serviço que, em determinados momentos do processo, calcula o comportamento a executar por cada avatar. Por outro lado, o outro serviço “ElementoKey”, trata questões relacionadas com as keys dos objectos 3D do mundo virtual, fornecendo métodos de registo e acesso de dados.

O código dos Web Services encontram-se no documento anexo V desta dissertação.

6.1.4 – Base de dados

A base de dados do sistema foi desenvolvida em ambiente Microsoft SQL Server38 que, como o Servidor Web, está sempre acessível.

O diagrama E-R (Figura 25) apresenta a estrutura definida para a base de dados do sistema. Tal como mostra a figura, foi necessária a criação de 6 tabelas de forma a satisfazerem os requisitos do sistema. Relativamente ao conjunto de informações geradas pelo algoritmo, estas são guardadas nas tabelas “PlanOperator”, “Links” e “PartialOrders”. A primeira tabela trata as informações relativamente ao plano de acções gerado (ex: nome da acção, pré e pos condições associadas e actor da mesma), enquando que as restantes tabelas são responsáveis por guardar dados relativos a acções causais e ordens parciais entre acções.

Estas três tabelas são preenchidas quando é mandado iniciar o processo de treino no ambiente 3D. Nesse mesmo momento, o sistema gera o plano do processo de treino e preenche as três tabelas de forma a posteriormente poder consultar estes dados.

Por outro lado, as tabelas “KeysSystem” e “PlanOperatorToAction3D” tratam dados relacionados com o ambiente 3D. A primeira tabela, é a responsável por guardar as keys39 dos objectos 3D participantes no sistema (ex: parafusos da fuselagem do avião) sendo estes dados preenchidos, geralmente, quando se inicia o processo de treino no ambiente virtual. Por sua vez, a tabela “PlanOperatorToAction3D” guarda o conjunto de acções no espaço 3D referentes a cada acção do processo. Cada entrada desta tabela apresenta um nome, uma descrição e um estado de execução que determina se a mesma foi realizada ou não no mundo virtual. Durante a execução de tarefas no ambiente de treino virtual existem alguns componentes intervenientes no mesmo que, através de código LSL, permitem verificar se existem alterações de estado no

36 http://www.infoq.com/articles/rest-introduction 37 Método que permite enviar dados como parte de um URL, sob a forma de parâmetros. 38 http://www.microsoft.com/sqlserver/en/us/default.aspx 39 É uma chave identificadora presente no ambiente SecondLife e OpenSimulator. Também tratada como UUID (Universally Unique Identifier).

38

sistema (ex: o mecânico 1 chegou junto da fuselagem do avião), proporcionando assim alterações nesta tabela. De realçar que esta tabela apresenta ainda um campo denominado “descricao_ajuda_action” que permite, em caso de necessidade, fornecer um texto de ajuda ao avatar.

Por fim, a tabela “SystemInteligentAgents_TasksPerAgent” é a tabela que guarda os comportamentos gerados pelo sistema, para cada avatar automático, com o intuito de serem executados pelos mesmos. Esta tabela, para além de identificar o mecânico a executar um determinado comportamento, apresenta um tipo de tarefa, dados necessários referentes à mesma e um estado de execução. Esta tabela é preenchida à medida que o sistema gera comportamentos, de forma dinâmica, a executar por parte de cada avatar. De seguida, é mostrado um exemplo de dados desta mesma tabela: (id - 1; mecNumber - 3; typeTask - 4; dataTask – “p1;e3c35629-345f-4144-a9ee-1acd839d5e2f”; stateTask - False).

Figura 25 – Diagrama E-R da base de dados implementada.

O seguinte dicionário de dados (Figura 26) permite uma melhor percepção da base de

dados implementada. Desta forma, a base de dados desenvolvida torna possível obter o estado actual do sistema a qualquer momento.

39

Figura 26 – Dicionários de dados da base de dados desenvolvida.

40

6.2 – Testes e validação

A validação do sistema é feita através de testes e análise dos resultados concluindo por fim, se o sistema funciona correctamente e de acordo com os requisitos. Assim, foi utilizado um ambiente de testes dividido em seis partes, número total de requisitos funcionais do sistema, sendo que para cada um deles foram elaboradas metodologias distintas de forma a testar o seu funcionamento. 6.2.1 Possibilidade de uma equipa, em simultâneo, treinar o processo de instalação do motor Pratt & Whitney F100 numa aeronave F-16

Este requisito não necessita de testes associados a si para ser validado pois, ao adoptar a

tecnologia OpenSimulator, este aspecto é cumprido. Esta plataforma já permite a possibilidade de vários utilizadores interagirem e treinarem o processo de instalação em questão, de forma simultânea. Assim, este sistema também permite a possibilidade de uma equipa, em simultâneo, treinar o processo de instalação.

6.2.2 Possibilidade de uma equipa composta por utilizadores e avatares automáticos, em simultâneo, treinar o processo de instalação do motor Pratt & Whitney F100 numa aeronave F-16

Parte deste requisito é satisfeito, tal como no requisito anterior, pela adopção da plataforma OpenSimulator, pois esta já possibilita vários utilizadores interagirem e treinarem o processo de instalação em questão, de forma simultânea. No entanto, uma equipa pode ser composta por avatares automáticos. Desta forma, é necessário validar o funcionamento dos mesmos e a possibilidade destes de desempenhar o papel de um mecânico no processo de treino em equipa.

6.2.2.1 Metodologia adoptada e condições do teste Os avatares automatizados, como anteriormente referido, foram desenvolvidos em

linguagem C#, sendo criados sob a forma de um programa Console Application40. Estes programas, representados no ambiente virtual por avatares, comunicam com o mesmo através da biblioteca libopenmetaverse. A Figura 27 apresenta o software criado para gerir o avatar no mundo 3D.

40 É uma aplicação para computador, desenhada para ser usada em interface de texto. O utilizador apenas interage com a aplicação com o teclado, ao contrário de aplicações mais completas.

41

Figura 27 – Software criado para gerir o avatar no ambiente 3D.

O teste consistiu em executar os programas desenvolvidos e iniciar o processo de treino no

ambiente virtual. Desta forma, consegue-se testar se os mesmos satisfazem a condição deste requisito.

6.2.2.2 Resultados e conclusão

Os avatares automatizados foram testados e pode-se concluir que estes são capazes de desempenhar o papel de um membro do processo de treino. Estes, juntamente com utilizadores, possibilitam o treino do processo de instalação do motor Pratt & Whitney F100 numa aeronave F-16, de forma simultânea. Assim, pode-se concluir que os mecânicos virtuais implementados vão ao encontro das necessidades do requisito em análise.

42

6.2.3 Os avatares automatizados devem agir de forma correcta e de acordo com o processo de manutenção mecânica

Para validar a forma de agir dos avatares, assim como a sua execução de acordo com o processo de manutenção mecânica, foram elaborados testes tanto ao plano gerado pelo processamento do algoritmo bem como às acções que os mecânicos virtuais executam posteriormente.

6.2.3.1 Metodologia adoptada e condições do teste

Para testar o algoritmo desenvolvido, foi criada uma aplicação de linha de comandos para o efeito, de forma a proporcionar a verificação do resultado do mesmo. Este terá que gerar um plano de acções e, para além disso, uma lista de ordens parciais e links para relacionar as mesmas. De realçar que todas as acções do processo necessitam de estar incluídas no resultado do algoritmo. Por sua vez, o plano gerado deve atribuir o respectivo actor ou actores de cada acção.

A Figura 28 mostra a aplicação que foi criada para testar as condições supra referidas, devendo estas serem satisfeitas para validar o funcionamento do mesmo. O teste ao algoritmo consistiu em executar o programa desenvolvido (AlgoritmoInstalacaoMotor.exe) e analisar assim o resultado gerado pelo mesmo.

Figura 28 – AlgoritmoInstalacaoMotor.exe

Para verificar se as acções dos avatares automáticos são executadas correctamente e de acordo com o plano, executaram-se os respectivos programas dos mesmos e verificou-se se os mesmos desempenhavam o seu respectivo papel atribuído e de acordo com as ordens de tarefas do plano. A Figura 29 apresenta um exemplo de um momento da acção dos vários mecânicos automáticos no processo de manutenção.

43

Figura 29 – Exemplo de um momento de actuação dos avatares automatizados.

6.2.3.2 Resultados e conclusão

Após a execução do teste ao resultado do algoritmo, segundo o processo descrito acima, pode-se concluir que este se encontra correcto, de acordo com as condições que este tinha que satisfazer. O plano gerado pelo algoritmo encontra-se completo, incluindo a lista de ordens parciais e links relacionais entre as acções do mesmo. Para além disso, este algoritmo atribui os respectivos actores para cada acção do plano.

Por sua vez, os testes aos avatares controlados por programa permitem concluir que a sua forma de agir se encontra correcta e de acordo com o processo de manutenção mecânica em questão.

6.2.4 Os avatares devem tomar iniciativas sem a necessidade de um comando do utilizador

Este requisito não necessita de testes específicos associados a si pois encontra-se validado a partir dos testes realizados anteriormente. Os avatares automatizados, da forma como foram desenvolvidos, não necessitam de um comando do utilizador para tomar iniciativas. Estes verificam se existem comportamentos ou tarefas a fazer e iniciam a execução dos mesmos sem qualquer tipo de ordem ou comando externo por parte do utilizador.

44

6.2.5 Permitir que o comportamento dos mecânicos virtuais seja razoavelmente semelhante ao comportamento dos mecânicos reais

Para verificar se o comportamento dos mecânicos automatizados é razoavelmente semelhante ao comportamento dos mecânicos reais é preciso testar os mesmos no ambiente virtual de treino. Para validar este requisito, é necessário que os mecânicos virtuais estejam preparados para reproduzir um comportamento, o mais idêntico possível, ao de um mecânico real.

6.2.5.1 Metodologia adoptada e condições do teste

Para validar o comportamento dos mecânicos virtuais, é preciso testar os mesmos em

ambiente virtual de treino normal. Desta forma, o teste consistiu em executar os programas referentes a cada mecânico virtual e iniciar o processo de treino no ambiente virtual.

Sendo que a finalidade deste requisito é analisar o comportamento dos avatares automáticos, teve-se especial atenção à sua movimentação, gestos e à forma como estes interagem com os objectos do sistema.

6.2.5.2 Resultados e conclusão

Após a verificação do comportamento dos avatares no processo de treino, pode-se concluir que um aspecto falhou nos testes. A deslocação do mesmo pelo espaço virtual não é feita através do acto de “andar”, tornando-se assim num defeito no comportamento do mecânico virtual.

A plataforma OpenSimulator permite a deslocação normal do mesmo, no entanto nas versões combinadas entre libopenmetaverse e OpenSimulator utilizadas neste projecto, o movimento de “andar” não se encontra em perfeito funcionamento. É ainda um defeito da biblioteca para algumas versões do OpenSimulator. De realçar que a combinação de libopenmetaverse e Second Life não apresenta qualquer defeito a este nível.

Contudo, minorou-se o problema com a utilização da funcionalidade de teletransporte de um local para o outro, permitindo assim que o processo de treino decorra normalmente. A Figura 30 exibe um exemplo de movimentação efectuado por um avatar automático através da utilização de teletransporte.

45

Figura 30 – Exemplo de movimentação efectuado por um avatar (teletransporte).

6.2.6 O tempo de resposta dos mecânicos virtuais deve assegurar que a simulação se mantenha credível aos utilizadores humanos

Para analisar o tempo de resposta dos mecânicos automatizados na execução de acções, foram elaborados testes e efectuada uma análise em algumas acções do processo de treino. O tempo de resposta destes não deve ser muito superior ao tempo de resposta de um utilizador humano.

6.2.6.1 Metodologia adoptada e condições do teste Para se conseguir obter um resultado do tempo de resposta do mecânico automático na

execução de acções, é necessário testar este processo com mecânicos reais e mecânicos virtuais, conseguindo assim obter resultados e fazer uma comparação. Sendo assim, o teste consistiu em iniciar o processo de treino com utilizadores reais e mecânicos virtuais.

É importante referir que os utilizadores reais utilizados neste teste, são utilizadores com alguma experiência de utilização destes ambientes.

A tabela seguinte apresenta os valores obtidos (em segundos), nos testes realizados, durante a execução de algumas acções no ambiente 3D. No entanto, os valores apresentados na tabela são valores médios que surgiram após a repetição de cada acção entre três a cinco vezes.

46

Esta análise ao tempo de resposta permite fazer uma comparação entre o mecânico real e o mecânico virtual.

Acção 3D Mecânico real Mecânico virtual Chegar junto da fuselagem do avião ≈ 2s ≈ 5s Fazer take do objecto parafuso ≈ 3s ≈ 6s Deslocar-se para junto da mesa de ferramentas ≈ 4s ≈ 6s Fazer rez do parafuso em cima da mesa ≈ 4s ≈ 7s Fazer take do objecto pad ≈ 3s ≈ 6s Apertar pad na fuselagem do avião ≈ 5s ≈ 7s

Tabela 1 – Comparação entre o tempo de resposta de um mecânico real com

mecânico virtual.

6.2.6.2 Resultados e conclusão

Depois de efectuada uma análise aos tempos de resposta de cada tipo de utilizador, pode-se concluir que os utilizadores reais apresentam melhor tempo de execução que os utilizadores virtuais. Este aspecto verifica-se devido ao facto de os mecânicos virtuais terem sido desenvolvidos de forma a estarem em constante verificação de tarefas (verificação de 5 em 5 segundos), proporcionando assim um pequeno atraso no tempo de resposta entre cada acção.

No entanto, o tempo de resposta de utilizadores reais pode depender de outros factores externos, nomeadamente a experiência de utilização do software cliente por parte dos mecânicos reais.

Pode-se concluir que o tempo de resposta dos avatares automatizados, apesar de ser superior a um mecânico real, não afecta a simulação do processo de treino. O seu tempo de resposta é aceitável, o que proporciona uma normal simulação, permitindo assim que esta se torne credível aos utilizadores humanos.

47

7 – Conclusões e propostas de trabalho futuro 7.1 – Conclusões

O objectivo principal deste trabalho era analisar e desenvolver agentes inteligentes capazes de desempenhar o papel de membros na execução de tarefas em equipa, objectivo esse que foi testado e alcançado com sucesso. Independentemente do trabalho futuro que venha a ser desenvolvido, acredita-se que a aplicação de agentes inteligentes permite resolver questões relacionadas com limitações de tarefas em equipa, constituindo uma mais-valia para a formação e ensino profissional.

Existe, neste momento, um protótipo funcional deste sistema e pronto a ser testado por mecânicos reais pois só dessa forma é que será possível uma optimização de todo o sistema. No entanto, este protótipo ainda não se encontra totalmente finalizado, necessita de adaptação com as restantes acções do processo em falta.

Contudo, este sistema pode ver apontadas algumas limitações. A adopção da abordagem do plano de acções em base de dados e do calculo dinâmico do comportamento do avatar do lado do sistema, em vez de ser no próprio avatar, poderia não ter sido o melhor caminho, pois deste modo torna impossível recalcular dinamicamente o comportamento no mesmo, isto é, o avatar não possui um sistema de decisão próprio, mas sim reage consoante o comportamento que a componente de decisão externa lhe atribui dinamicamente, com base no estado actual do sistema e com o intuito de atingir os objectivos. Por outro lado, nas versões utilizadas do OpenSimulator, a forma de movimentação no mundo virtual 3D por parte dos mecânicos virtuais é limitada, sendo assim um aspecto a melhorar neste sistema futuramente.

Além disso, o nível de detalhe de modelação de certos objectos 3D também pode ser melhorado de forma a proporcionar um sistema mais próximo do contexto real de formação.

Desta forma, foi conseguido um sistema de treino 3D que proporciona vantagens à formação técnica da Força Aérea Portuguesa, evitando assim o envolvimento de recursos físicos.

7.2 – Trabalho futuro

Actualmente, estão em desenvolvimento na UTAD outros trabalhos, em paralelo a este, que permitem antever algumas possibilidades de melhoria a este sistema, numa vertente de ajuda e auxílio ao formando no momento do treino. Num futuro próximo, é expectável que possa vir a haver trabalhos que dêem continuidade a este. Com o objectivo de melhorar e adicionar funcionalidades a este sistema desenvolvido, tecem-se aqui algumas considerações para apoio a trabalhos futuros. Como prioridade penso que será de finalizar o protótipo desenvolvido, adaptando as restantes acções do processo em falta. Posteriormente, será importante aumentar o nível de detalhe de modelação de certos objectos no ambiente de treino 3D pois permite aproximar o aspecto visual do ambiente ao contexto real. É também importante reformular a abordagem do plano de acções, possibilitando que cada avatar recalcule dinamicamente o seu plano de acções, em vez do sistema.

Por fim, outra sugestão de melhoria é acrescentar um sistema de apoio e ajuda mais completo aos utilizadores (ex: criar um agente virtual unicamente para acompanhar cada mecânico).

48

8 – Referências

- Amaral, I. (2007). A @migração para o ciberespaço – a dimensão social dos mundos virtuais. - Amorim, A., Leal, L., & Freitas, M. (2009). Planejamento em Inteligência Artificial. - Araujo, A., Carvalho, L., & Costa, R. (2007). Avaliação da influência de Agentes Humanos Inteligentes sobre a navegação de usuários em Ambientes Virtuais. - Atkinson, R. K. (2002). Optimizing learning from examples using animated pedagogical agents. Journal of Educational Psychology. - Baylor, A. L. (1999). Intelligent agents as cognitive tools for education. Education Technology. - Book, B. (2004). Moving Beyong the Game: Social Virtual Worlds. Consultado a 27 de Julho de 2011 em http://www.virtualworldsreview.com/papers/BBook_SoP2.pdf. - Book, B. (2008). Consultado a 19 de Julho de 2011 em http://www.virtualworldsreview.com/info/whatis.shtml. - Caeiro, C., Serra, D., Jorge, J., & Anielo, M. (2001). Estudo sobre Inteligência Artificial. Consultado a 23 de Agosto de 2011 em http://www.citi.pt/educacao_final/trab_final_inteligencia_artificial/ia.html - Ciriaco, D. (2008). Consultado a 17 de Agosto de 2011. O que é a Inteligência Artificial? http://www.tecmundo.com.br/1039-o-que-e-inteligencia-artificial-.htm - Correia, M., & Eiras, B. (2010). “Mundos Virtuais: Que vida existe no Second Life?”. - Costa, A. (2010). Exemplo de STRIPS e POP no mundo dos blocos. - Esteves, M., Fonseca, B., Morgado, L., & Martins, P. (2010). Improving teaching and learning of computer programming through the use of the Second Life virtual world. - Fitzgerald, M. (2007); How I Did It: Philip Rosedale, CEO, Linden Lab. Interview with Philip Rosedale. Inc. Electronic Magazine. Acedido a 11 de Setembro de 2011 em http://www.inc.com/magazine/20070201/hidi-rosedale.html - Garrido, P., Martinez, F., & Guetl, C. (2010). Enhancing Intelligent Pedagogical Agents in Virtual Worlds. - Greis, L., & Faria, E. (2007). Second Life: uma proposta de utilização pedagógica. - Johnson, W. L., & Rickel, J. W. (1999). Animated pedagogical agentes: Face-to-face interaction in interactive learning environments. - Krause, D. (2009). Serious Game in Second Life: Kitchen fire simulation on swiss projects. Consultado a 9 de Setembro de 2011 em http://web3dblog.wordpress.com/2009/05/09/serious-game-in-second-life-kitchen-fire-simulation-on-swiss-projects/ - Leal, D. (2007).Mundos Virtuais On-line: Um Mini-guia. Consultado 9 de Julho de 2011 em http://www.masternewmedia.org/pt/2007/04/10/mundos_virtuais_online_um_miniguia.htm - Lockheed Martin Corp. (2009). TO 1F-16AM-2-70JG-10-21 - Organizational Maintenance Engine Removal and Installation – Model F100-PW-220/220E – USAF/EPAF Series – F-16a/B Mid-Life Update aircract, Technical Manual Job Guide. Bethesda, MD, EUA: Lockheed Martin Corporation. - Lopes, A., Pires, B., Cardoso, M., Santos, A., Peixinho, F., Sequeira, P., & Morgado, L. (2008). Sistema de criação de movimentos de Andebol em Second Life para Formação de Treinadores. Prisma.com 6, ISSN 1646-3153. 33-49.

49

- Madeira, A., Antunes, R., Morgado, L., & Pereira, A. (2008). Controlo de assiduidade em aulas efectuadas em mundos virtuais - Second Life. - Morgado, L. (2009). Os mundos virtuais e o ensino-aprendizagem de procedimentos. Educação & Cultura Contemporânea, ISSN 1807-2194, 13 (6), 35-48 - Neto, J. (2008). O uso do Second Life como ambiente virtual de aprendizagem. Consultado a 11 de Agosto de 2011 em http://www.comunidadesvirtuais.pro.br/seminario4/trab/jamn.pdf - OpenSimulator (2011). Configuration. Consultado a 14 de Agosto de 2011 em http://opensimulator.org/wiki/Configuration#Standalone_vs._Grid - Pereira, A., Martins, P., Morgado, L., Fonseca, B. (2009). A virtual environment study in entrepreneurship education of young children, Journal of Virtual Worlds Research, 1(2). - Pereira, J., Morgado, L., & Silva, P. (2010). Implementação de OpenSimulator com funcionalidade de voz em ambiente empresarial. - Pozzer, C. (2007). Introdução ao desenvolvimento do motor do Jogo. - Russel, S. J. (2004). Inteligência Artificial, 2a edição. - Sequeira, L. (2009). Mechanisms of three-dimensional content transfer between the OpenSimulator and Second Life Grid platforms. Master dissertation. Vila Real, Portugal: UTAD. - Soliman, M., & Guetl, C. (2010). Intelligent Pedagogical Agents in Immersive Virtual Learning Environments: A Review. - Teixeira, L., & Pinto, I. (2010). Guia de instalação de motor em aeronave F-16. Relatório de projecto 2009-2010, Licenciatura em Tecnologias de Informação e Comunicação. Vila Real, Portugal: UTAD. - VanDrimmelen, J. (2007). 7 Ways Croquet is better than Second Life. Consultado a 27 de Julho de 2011 em http://edutechie.com/2007/07/7-ways-croquet-is-better-than-second-life/ - Vilela, A., Cardoso, M., Martins, D., Santos, A., Moreira, L., Paredes, H., Martins, P., & Morgado, L. (2010). Privacy challenges and methods for virtual classrooms in Second Life Grid and OpenSimulator. In "2010 Second International Conference on Games and Virtual Worlds for Serious Applications (VS-GAMES)”. - Woodcock, B. (2008). Charts An Analysis of MMOG Subscription Growth Version 23.0. Consultado a 28 de Julho de 2011 em http://www.mmogchart.com/Chart2.html.

50

9 – Anexos

Anexo I – Relatório de entrevista com o responsável da formação da Base Aérea N5. Anexo II – Esquema de representação das acções do processo de instalação do motor. Anexo III – Protocolo completo de instalação do motor na aeronave F-16. Anexo IV – Resultado de algumas conversões de acções para adaptação ao ambiente 3D. Anexo V – Sistema completo implementado (OpenSimulator, código de scripts em LSL dos objectos 3D, web services, avatares automatizados e backup da base de dados). Este anexo segue no DVD que acompanha a presente dissertação.

51

Anexo I – Relatório de entrevista com o responsável da formação da Base Aérea N.º 5

O processo de formação começa após a selecção de especialidade por parte do militar, sendo este processo com base nas suas notas, testes psicotécnicos e consoante as suas capacidades e vantagens que poderá proporcionar à Força Aérea Portuguesa. Posteriormente, o aluno apresenta-se e consoante a sua futura especialidade, este recebe formação no Centro de Formação Militar e Técnica da Força Aérea (CFMTFA), na Ota. Esta formação inicial varia em termos de duração (no mínimo 6 meses) consoante a especialidade do militar.

Consoante a classificação do militar na formação inicial, este escolhe a Base Aérea preferencial, consoante as vagas que existirem e cada Base Aérea apresenta várias secções. Desta forma, na BA5 (Monte Real), mais propriamente a secção de operações de linha da frente ou manutenção, inicia o processo com uma formação básica em “Partes gerais da aeronave F-16” que dura, aproximadamente, duas semanas. Depois, o aluno começa o curso específico da área, constituído por partes teóricas e práticas, denominado “Curso do Motor F-100-PW-220E Nível O”. Este curso, que tem a duração total de cerca de 250 horas, apresenta uma componente de avaliação que obriga o militar a ter mais de 75% na componente teórica para aprovação. No entanto, na parte prática, é o formador que avalia a execução das tarefas, classificando-o como apto ou inapto. Caso o formando fique classificado como inapto, este volta a repetir o processo até ficar apto no processo. Esta formação técnica vai do nível 1 até ao nível 5, sendo que cada formador tem que ter nível máximo para poder exercer as suas funções.

52

Esquema(de(acções(do(processo(de(instalação(de(motor(em(aeronave(F716(

Acção:'RemoverParafusoFuselagem(f,'s,'p,'mec)'

!

Pré%condição:!!

Fuselagem(f,'s,'p)'Apertado(s,p)'

Acção:'AlinharPads(a,'mec):'

Pré%condição:'''~PadsAlinhadas(a)'Desapertado(s1,p1)'Desapertado(s2,p2)'Desapertado(s3,'p3)'Desapertado(s4,'p4)'

!

Pós%condição:!'

Desapertado(s,p)'

Pós%condição:'

PadsAlinhadas(a)''

Acção:'InstalarApoioMotor(c,'ap,'mec)'

Pré%condição:'''~InstaladoApoio(ap)'

Pós%condição:!!

InstaladoApoio(ap)'

Acção:'ApertarPads(a,'mec):'!Pré%condição:'''~PadsInstaladas(a)'PadsAlinhadas(a)''

Pós%condição:!

PadsInstaladas(a)'Apertado(s1,'p1)'Apertado(s2,'p2)'Apertado(s3,'p3)'Apertado(s4,'p4)'

Anexo II – Esquema de representação das acções do processo de instalação do motor.

53

Acção:'ElevarMotor(c,'mec)'!Pré%condição:'''~MotorElevado(c)'SupervisorDeuOrdem(c)'

Pós%condição:!!

MotorElevado(c)''

Acção:'InstalarApoioCalhaAviao(a,'mec)'Pré%condição:'''CalhaAviao(a,'ap)'~InstaladoApoioCalha(a)'

Pós%condição:!!

InstaladoApoioCalha(a)'

Acção:'AproximarCarroInstalacao(c,'mec)'!Pré%condição:'''MotorElevado(c)'~AproximadoAviao(c)'

!

Pós%condição:!'AproximadoAviao(c)'

Acção:'SupervisorDarOrdem(c,'mec)'

Pré%condição:'''~SupervisorDeuOrdem(c)'InstaladoApoio(ap1)'InstaladoApoio(ap2)'InstaladoApoio(ap3)'

Pós%condição:!!

SupervisorDeuOrdem(c)'

Acção:'AjustarCarroInstalacao(c,'mec)'Pré%condição:'''AproximadoAviao(c)'~Ajustado(c)'

Pós%condição:!'Ajustado(c)'

54

Acção:'BloquearRodas(c,'mec)'

Pré%condição:'''

Ajustado(c)'

~CarroBloqueado(c)'

Pós%condição:!'

CarroBloqueado(c)'

Acção:'InstalarApoioCarroNaPad(c,'ap,'mec)'

!Pré%condição:'''

~InstaladoApoio(ap)'

!

Pós%condição:!'

InstaladoApoio(ap)'

Acção:'RodarJackScrewFrente(c,'mec)'

Pré%condição:'''InstaladoApoio(c,'apEsquerdo)'

InstaladoApoio(c,'apDireito)'

~JackscrewFrenteRodado(c)'

Pós%condição:!'

JackscrewFrenteRodado(c)'

Acção:'RodarManivelas(c,'mec)'

Pré%condição:'''

~InstaladoApoio(ap1)'

~ManivelasRodadas(c)'

~MotorDeslocado(c,'a)'

Pós%condição:!'

ManivelasRodadas(c)'

MotorDeslocado(c,a)'

Acção:'RemoverConjuntoSuporteFrente(c,'mec)'

!Pré%condição:'''

InstaladoApoio(ap1)'

!

Pós%condição:!'

~InstaladoApoio(ap1)'

'

55

Acção:'AlinharLigacaoApoiosImpulso(c,'m,'ap,'mec)'Pré%condição:'''MotorDeslocado(c,'a)'~AlinhadaLigacao(m,'ap)'

Pós%condição:!'AlinhadaLigacao(m,'ap);'

Acção:'IntroduzirApoiosImpulso(m,'a,'mec)'Pré%condição:'''AlinhadaLigacao'(m,'apEsq)'AlinhadaLigacao'(m,'apDir)'~ColocadosApoiosImpulso(m,'a)'

Pós%condição:!'ColocadosApoiosImpulso(m,'a)''

Acção:'InstalarMeiasLuas(m,'a,'lado,'mec)'Pré%condição:'''ColocadosApoiosImpulso(m,'a)'~MeiasLuasInstaladas(m,'a,'lado)'

Pós%condição:!'MeiasLuasInstaladas(m,'a,'lado)'

Acção:'VerificarAlinhamentoSeal(m,'mec)'!Pré%condição:'''~SealVerificado(m,'a)'

Pós%condição:!'SealVerificado(m,'a)'

Acção:'SupervisaoAccao(c,'mec)'

Pré%condição:'''~SupervisionouAccao(c,'a)''

Pós%condição:!'

SupervisionouAccao(c,'a)''

56

Acção:'RemoverCarroInstalacao(c,'a,'mec)'

Pré%condição:'''DesligadaLigacaoPads(a)'~RemovidoCarroInstalacao(a)'

Pós%condição:!'RemovidoCarroInstalacao(a)'

Acção:'DesligarCarroPadsFuselagem(c,'a,'mec)'

Pré%condição:'''SealVerificado(m,'a)'~DesligadaLigacaoPads(a)'

Pós%condição:!

!DesligadaLigacaoPads(a)'

Acção:'LigarPowerTakeoffShaft(a,'mec)'Pré%condição:'''~LigadoPowerTakeoffShaft(a)'

Pós%condição:!

'LigadoPowerTakeoffShaft(a)'

Acção:'LigarFichaElectrica(a,'f,''ent,'mec)'

Pré%condição:'''~LigadaFichaElectrica(a,'f,'ent)'

Pós%condição:!'LigadaFichaElectrica(a,'f,'ent)'

Acção:'ApertarFichaP1ComBracadeira(a,'f,'ent,'mec)'

Pré%condição:'''LigadaFichaElectrica(a,'P1,'J1)'~ApertadaBracadeira(a,'P1,'J1)'

Pós%condição:!'ApertadaBracadeira(a,'P1,'J1)'

57

Acção:'Ligar7ºAndarCompressor(a,'mec)'

Pré%condição:'''~Ligado7ºAndarCompressor(a)'

Pós%condição:!

Ligado7ºAndarCompressor(a)''

Acção:'LigarManeteGas(a,'mec)'

Pré%condição:'''~LigadaManeteGas(a)'

Pós%condição:!

LigadaManeteGas(a)'

Acção:'Ligar13ºAndarCompressor(a,'mec)'

Pré%condição:'''~Ligado13ºAndarCompressor(a)'

Pós%condição:!Ligado13ºAndarCompressor(a)''

Acção:'RemoverRetrateis(a,'mec)'

Pré%condição:'''~RemovidosRetrateis(a)'

Pós%condição:!

RemovidosRetrateis(a)'

Acção:'FrenarParafusosApoioImpulso(a,'mec)'

Pré%condição:'''~FrenadosParafusosApoioImpulso(a)'

Pós%condição:!

FrenadosParafusosApoioImpulso(a)'

58

Acção:'DesapertarPads(a,'mec):'!Pré%condição:'''PadsInstaladas(a)'Apertado(s1,'p1)'

Apertado(s2,'p2)'

Apertado(s3,'p3)'

Apertado(s4,'p4)'

Pós%condição:!~PadsInstaladas(a)'Desapertado(s1,p1)'Desapertado(s2,p2)'

Desapertado(s3,'p3)'

Desapertado(s4,'p4)'

Acção:'InstalarParafusosFuselagem(a,'mec)'

Pré%condição:'''~InstaladosParafusosFuselagem(a)'

Pós%condição:!

InstaladosParafusosFuselagem(a)'

Acção:'LigarFichaAoInterruptorBaixaPressaoOleo(a,'f,'mec)'

Pré%condição:'''~LigadaFichaAoInterruptor(a,'f)'

Pós%condição:!

'LigadaFichaAoInterruptor(a,'f)'

Acção:'LigarTuboCombustivel(a,'mec)'

Pré%condição:'''~LigadoTuboCombustivel(a)'

Pós%condição:!

'LigadoTuboCombustivel(a)'

Acção:'RemoverPadsFuselagem(a,'mec)'

Pré%condição:'''~PadsInstaladas(a);'~PadsRemovidas(a);'

Pós%condição:!

'PadsRemovidas(a)'

59

'Acção:'LigarLinhaArrefecimento(a,'linha,'mec)'Pré%condição:'''~LigadaLinhaArrefecimento(a,'linha)'

Pós%condição:!

LigadaLinhaArrefecimento(a,'linha)'

Acção:'LigarApoioLateral(a,'mec)'Pré%condição:'''~LigadoApoioLateral(a)'

Pós%condição:!

'LigadoApoioLateral(a)'

Acção:'InspeccaoVisual(a,'mec)'

Pré%condição:'''~EfectuadaInspeccaoComponentes(a)'

Pós%condição:!

'EfectuadaInspeccaoComponentes(a)'

Acção:'LigarFuelShutoffValveAoCockpit(a,'mec)'Pré%condição:'''~LigadoFuelShutoffValveAoCockpit(a)'

Pós%condição:!

'LigadoFuelShutoffValveAoCockpit(a)'

Acção:'InicializarMotor(a,'mec)'Pré%condição:'''~InicializadoMotor(a)'

Pós%condição:!

'InicializadoMotor(a)'

60

PROCOLOCO&DE&INSTALAÇÃO&DE&MOTOR&EM&AERONAVE&F16&

!

!

!

1.!Remover!quatro!parafusos!da!fuselagem!do!avião!(dois!de!cada!lado).!

!

!

!

!

!

!

! !

!

! !! !! !!

!

!

2.!Instalar!as!“Pad’s”!na!fuselagem!do!avião!(uma!do!lado!esquerdo!e!outra!do!lado!direito).!!

!!!!!!!!2.1.!Alinhar!pads!para!instalar.!

!

! !

!

!

!

!

RemoverParafusoFuselagem(f,!s1,!p1,!mec1);!

RemoverParafusoFuselagem(f,!s2,!p2,!mec2);!

RemoverParafusoFuselagem(f,!s3,!p3,!mec3);!

RemoverParafusoFuselagem(f,!s4,!p4,!mec4);!

Inicio&

AlinharPads(a,!mecTodos);!

!

Anexo III – Protocolo completo de instalação do motor na aeronave F-16

61

2.2.!Apertar!as!pads!com!os!parafusos!

!

!

! ! !

!!!!!!!!!!!

!!3.!Elevar!e!nivelar!o!motor.!

!!!!!!3.1.!Instalação!de!três!apoios!no!motor!(1!à!frente!e!2!atrás)!para!elevar!o!motor.!Devem!ser!colocados/instalados!os!três,!individualmente...!

!

!

!

!

!

!

!!!!!!!3.2.!Depois!de! instalados!os!três!apoios!para!elevar!o!motor,!são!precisos!3!mecânicos!sincronizados! a! rodar! as! manivelas! dos! apoios.! A! ordem! de! sincronização! é! dada! pelo!supervisor.!

ApertarPads(a,!mecTodos);!

!

InstalarApoioMotor(c,!ap1,!mec1);!

InstalarApoioMotor(c,!ap2,!mec2);!

InstalarApoioMotor(c,!ap3,!mec3);!

62

!!!!!!!!

4.! Com! o! motor! alinhado! longitudinalmente! ao! avião,! acoplar! o! motor! ao! avião! pela!colocação!do!apoio!superior!na!calha!do!avião.!

! 4.1!Instalação!de!apoio!superior!na!calha!do!avião!(forward!mount)!

!

!

!

!! !!!!!!!!!!!!

!! 4.2!Aproximar!e!ajustar!carro!de!instalação.!

!

!

!! !

!

!

!

SupervisorDarOrdem(c,!mec4);!

ElevarMotor(c,!mecTodos);!

InstalarApoioCalhaAviao(a,!mecTodos);!

AproximarCarroInstalacao(c,!mecTodos);!

AjustarCarroInstalacao(c,!mecTodos);!

63

a. Rodar o Jackscrew da frente e baixar o necessário para que possa ser

transferido o peso do motor para o avião, devem-se rodar os pins de

fuselagem até que estejam soltos, para que seja possível essa

transferência.

7. Remover o conjunto de apoio de suporte da frente do motor. Este suporte faz

parte do carro de instalação (adapter).

8. Com dois técnicos de cada lado do motor iniciar a introdução do motor.

a. O motor é introduzido dentro do avião através de umas manivelas que

estão no carro de instalação, quando elas são rodadas o motor vai

correndo pela calha do avião. A medida que isto vai acontecendo o

supervisor verifica se nada está a ser forçado e se existe folga.

i. Do lado esquerdo o mecânico 1 controla o alinhamento do motor

tendo em conta o 7º andar;

NOTA: Neste momento o motor está apoiado na calha do avião e no conjunto de

apoio traseiro do carro de instalação.

!!!!!!!4.3!Depois!de!efectuado!o!alinhamento,!necessário!bloquear!rodas.!

!

!

!

!

!!!!!!!

!!!!!!5.! Ligar! carro! de! instalação! às! pads! instaladas! na! fase! 2.! O! carro! de! instalação! tem! dois!apoios(um!de!cada!lado),!esses!apoios!são!instalados!nas!Pads!e!seguros!por!um!parafuso.!

!

!

!

! !!

6.!Transferir!o!peso!para!o!avião.!Esta!operação!é!feita!no!jackscrew!da!frente.!

!

!!!!!

BloquearRodas(c,!mecTodos);!

InstalarApoioCarroNaPad(c,!apEsquerdo,!mec1);!

InstalarApoioCarroNaPad(c,!apDireito,!mec3);!

64

! !

! !

! !

! !

!

!

!

7.!Remover!o!conjunto!de!apoio!de!suporte!da!frente!do!motor.!Este!suporte!faz!parte!do!

carro!de!instalação.!

!

! !

! !

! !

! !

! !

! !

! !

!

!

!

!

8.! Com! dois! técnicos! de! cada! lado,! iniciar! a! introdução! do! motor! no! avião.! O! motor! é!

introduzido!dentro!do!avião!através!de!umas!manivelas!que!estão!no! carro!de! instalação,!

quando!elas! são! rodadas!o!motor!vai! correndo!pela!calha!do!avião.!A!medida!que! isto!vai!

acontecendo,!o!supervisor!verifica!se!existe!alguma!folga!ou!problema.!

!

!

!

!

!

!

!

!

RodarJackscrewFrente(c,!mecTodos);!

!

RemoverConjuntoSuporteFrente(c,!mecTodos);!

Neste!momento,!o!motor!encontracse!apoiado!na!calha!do!avião!e!no!conjunto!de!

apoio!traseiro!do!carro!de!instalação.!

65

!

!

!

!

!

9.!Alinhar!as!ligações!dos!apoios!de!impulso!(uma!de!cada!lado).!

!

! !! !! !!

!

!

10.!Introduzir!os!apoios!de!impulso.!

!

!!!!!!!!!!!!!! !! !! !! !

!!!

!

RodarManivelas(c,!mecTodos);!

SupervisaoAccao(c,!mec4);!

AlinharLigacaoApoiosImpulso(c,!m,!apEsq,!mec1);!

AlinharLigacaoApoiosImpulso(c,!m,!apDir,!mec3);!

!

IntroduzirApoiosImpulso(m,!a,!mecTodos);!

!

66

11.!Instalar!meias!luas!(ambos!os!lados).!

!!!!!!!!!!!!!!! !! !! !! !

!

!

12.!Verificar!pela!entrada!de!ar,!o!perfeito!alinhamento!do!seal!da!entrada!de!ar!do!motor.!Se!encaixar!perfeitamente,!é!porque!está!alinhado.!

!

!

!

!

!

13.!Remover!o!carro!de!instalação.!

!!!!!!13.1.!Desligar!o!carro!de!instalação!das!pads!da!fuselagem!!!! !! !! !!

!

InstalarMeiasLuas(m,!a,!ladoEsquerdo,!mec1);!

InstalarMeiasLuas(m,!a,!ladoDireito,!mec3);!

VerificarAlinhamentoSeal(m,!a,!mecTodos);!

!

DesligarCarroPadsFuselagem(c,!a,!mecTodos);!

!

67

!!!!!!13.2.!Remover!completamente!o!carro!de!instalação.!

!! !! !! !! !! !!!! !! !! !! !! !!!

Ligações&do&lado&esquerdo&(podem&decorrer&ao&mesmo&tempo&que&as&ligações&do&lado&direito):&

!

!!!!!14.!Ligar!Power!Takeoff!Shaft.!Requer!aperto!dos!parafusos.!!

!

!!!!!!!!!!!!!!!!!

!

!!!!!

!

!

!

RemoverCarroInstalacao(c,!a,!mecTodos);!

!

Neste! momento,! o! motor! está! completamente! colocado! no! avião.!Faltam!completar!ligações!ao!avião!(lado!esquerdo!e!lado!direito).!

LigarPowerTakeoffShaft(a,!mecTodos);!

!

68

15.!Ligar!as!cablagens!eléctricas!(são!5!fichas).!Apertar!uma!ficha!(P1)!com!braçadeira.!

!

!

!

!

!

!

!

!

!

!

!

! !! !! !! !! !! !! !! !! !!

16.!Ligar!7º!andar!de!compressor.!!! !! !! !! !! !!!17.!Ligar!manete!de!gás.!!!! !! !

LigarFichaElectrica(a,!P300,!J300,!mecTodos);!

LigarFichaElectrica(a,!P1,!J1,!mecTodos);!

ApertarFichaP1ComBracadeira(a,!P1,!J1,!mecTodos);!

LigarFichaElectrica(a,!P2,!J2,!mecTodos);!!

LigarFichaElectrica(a,!P3,!J3,!mecTodos);!

LigarFichaElectrica(a,!P145,!J145,!mecTodos);!

!

Ligar7ºAndarCompressor(a,!mecTodos);!

!

LigarManeteGas(a,!mecTodos);!

69

18.!Ligar!13º!andar!de!compressor.!

!

!

!

!

!!!!!!!!!!! !! !! !! !! !

!

19.!Frenar!parafusos!do!apoio!de!impulso.!

!

!! !! !! !!

!!

20.!Remover!retrateis.!

!

! !! !! !

Ligar13ºAndarCompressor(a,!mecTodos);!

FrenarParafusosApoioImpulso(a,!mecTodos);!

RemoverRetrateis(a,!mecTodos);!

70

!

!

21.!Remover!e!instalar!parafusos!na!fuselagem!(depois!de!retiradas!as!pads).!

!!!!!!!21.1.!Desapertar!e!remover!pads!da!fuselagem!do!avião.!

!

!

! !

! !

! !

!

!

!!!!!!!21.2.!Instalar!parafusos!na!fuselagem!

!

! !

! !

! !

!

!

Ligações&do&lado&direito&(podem&decorrer&ao&mesmo&tempo&que&as&ligações&do&lado&esquerdo):&

&

22.!Ligar!P146!à!J146.!

!

&

&

!

!

23.!Ligar!7932P1!ao!interruptor!de!baixa!pressão!de!óleo.!

!

! !

! !

! !

DesapertarPads(a,!mecTodos);!

RemoverPadsFuselagem(a,!mecTodos);!

InstalarParafusosFuselagem(a,!mecTodos);!

LigarFichaElectrica(a,!P146,!J146,!mecTodos);!

!

LigarFichaAoInterruptorBaixaPressaoOleo(a,!7932P1,!mecTodos);!

!

71

24.!Ligar!tubo!entrada!de!combustível.!!! !! !! !! !! !!25.!Ligar!linhas!de!arrefecimento!(DEEC!e!EDU);!!!! !! !! !! !

!

26.!Ligar/confirmar!a!ligação!do!13º!andar!de!compressor!! !! !! !! !!

!27.!Frenar!parafusos!do!apoio!de!impulso.!

!

! !! !! !

28.!Ligar!apoio!lateral.!

!

!! !! !! !!

29.!Efectuar!a!inspecção!visual!para!confirmação!que!tudo!está!correctamente!ligado.!!! !! !

LigarTudoCombustivel(a,!mecTodos);!

!

LigarLinhaArrefecimento(a,!DEEC,!mecTodos);!

LigarLinhaArrefecimento(a,!EDU,!mecTodos);!

Ligar13ºAndarCompressor(a,!mecTodos);!

FrenarParafusosApoioImpulso(a,!mecTodos);!

LigarApoioLateral(a,!mecTodos);!

InspeccaoVisual(a,!mecTodos);!

72

!

30.!Ligar!Fuel!Shutoff!valve!no!cockpit.!

!

!! !! !! !! !!

!31.!Inicializar!o!motor.!

LigarFuelShutoffValveAoCockpit(a,!mecTodos);!

InicializarMotor(a,!mecTodos);!

&&&&&&Protocolo&de&instalação&completo...&

73

Anexo IV – Resultado de algumas conversões de acções para adaptação ao ambiente 3D.

Acção Conversão para ambiente 3D

RemoverParafusoFuselagem r Chegar junto da fuselagem do avião r Fazer take do objecto parafuso r Deslocar-se para junto da mesa de ferramentas r Fazer rez do parafuso em cima da mesa

AlinharPads r Deslocar-se para junto da mesa de ferramentas r Fazer take de dois objectos Pad r Chegar junto da fuselagem do avião r Fazer rez do objectos Pad r Tocar na Pad e na fuselagem para alinhar

InstalarApoioMotor r Deslocar-se para junto da mesa de ferramentas r Fazer take do objecto ApoioMotor r Chegar junto do carrinho de instalação do motor r Fazer rez do objecto ApoioMotor r Tocar no objecto ApoioMotor e no local do motor para instalar

SupervisorDarOrdem r Chegar junto do motor de instalação r Verificar apoios instalados r Dar ordem para elevar motor

IntroduzirApoiosImpulso r Deslocar-se para junto da mesa de ferramentas r Fazer take dos objectos ApoiosImpulso r Chegar junto do avião r Fazer rez dos objectos ApoiosImpulso r Tocar nos objectos ApoiosImpulso e no avião para se introduzir

os apoios InstalarMeiasLuas r Deslocar-se para junto da mesa de ferramentas

r Fazer take do objecto MeiaLua r Chegar junto do avião r Fazer rez do objecto MeiaLua r Tocar no objecto MeiaLua e no avião para instalar

LigarFichaElectrica r Chegar junto do local da ficha eléctrica r Tocar nas duas pontas para se ligarem

InicializarMotor r Deslocar-se para junto da cabine do avião r Sentar-se no banco do piloto r Tocar no botão “on” para inicializar o motor