Implementação de um Sistema de Formação para Mecânicos da Força Aérea Portuguesa

Universidade de Trs-os-Montes e Alto Douro

Implementao de um Sistema de Formao

para Mecnicos da Fora Area Portuguesa

Dissertao de Mestrado em

Engenharia Informtica

Paulo Andr Cardoso Fernandes

Leonel Caseiro Morgado

Hugo Alexandre Paredes Guedes da Silva

Vila Real, 2012


Implementao de um Sistema de Formao

para Mecnicos da Fora Area Portuguesa

Dissertao de Mestrado em

Engenharia Informtica

Paulo Andr Cardoso Fernandes

Leonel Caseiro Morgado

Hugo Alexandre Paredes Guedes da Silva

Composio do Jri:

_______________________________________________

_______________________________________________

_______________________________________________

Vila Real,2012

Orientao Cientfica:

Leonel Morgado

Professor Auxiliar com Agregao

Departamento de Engenharias

Escola de Cincias e Tecnologia - ECT


Hugo Paredes

Professor Auxiliar

Departamento de Engenharias

Escola de Cincias e Tecnologia - ECT


Resumo

A manuteno mecnica dos motores utilizados nas aeronaves F-16 da Fora

Area Portuguesa realizada como um esforo de equipa envolvendo 3 a 4 tcnicos de

motores, devidamente qualificados.

A Universidade de Trs-os-Montes e Alto Douro (UTAD) e a Fora Area

Portuguesa (FAP) selaram um protocolo onde haviam acordado uma colaborao entre

as duas instituies no mbito do qual tem vindo a ser desenvolvido um simulador 3D

para a formao de mecnicos na manuteno de aeronaves F-16.

Este simulador tem como objetivo permitir o treino de tcnicas, num contexto

espacial e visual, e de cooperao, antes da fase de treino com motores fsicos.

Para a implementao deste simulador optou-se pelo uso dos mundos virtuais 3D

de modo a garantir imersividade simulao e garantir que fosse o mais parecido com o

real. So descritos alguns dos mundos virtuais 3D possveis para a realizao deste

projeto assim como aquele pelo o qual se optou para a implementao deste projeto.

Ao longo desta dissertao so apresentadas as vrias etapas do projeto desde o

seu incio, em 2010, sendo descritas mais detalhadamente as etapas realizadas durante

este ltimo ano.

Para o processo de simulao foi desenhada uma arquitetura onde todo o sistema

de deciso e controlo est separado da interface grfica. Desta forma, possvel trocar

de ambiente grfico com menor esforo.

Foi implementado um prottipo funcional e realizados dois testes de campo

efetuados com os utilizadores. So apresentados os testes realizados bem como os seus

resultados.

Palavras-chave: formao, mundos virtuais, OpenSimulator, trabalho cooperativo,

F-16, aprendizagem virtual

Abstract

Mechanical maintenance of the engines used in the F-16 aircraft of the Portuguese

Air Force is carried out as a team effort involving 3 to 4 engine technicians, duly

qualified.

The Universidade de Trs-os-Montes e Alto Douro (UTAD) and Fora Area

Portuguesa (FAP) sealed a protocol where they had agreed a collaboration between the

two institutions in which has been developed a 3D simulator for training in mechanical

maintenance of F-16 aircraft.

This simulator is to allow the training of technical, visual and spatial context, and

cooperation before the training phase motors with physical

For the implementation of this simulator was chosen by the use of 3D virtual

worlds to ensure immersiveness and ensure that the simulation was the closest thing to

the real. We describe some of the possible 3D virtual worlds for the realization of this

project.

Throughout this dissertation presents the various stages of the project since its

inception in 2010, and described in more detail the steps taken during the past year.

For the simulation process was designed an architecture where the whole system

of decision and control is separated from the graphical user interface. Thus, it is

possible to change the graphical environment with less effort.

We have implemented a working prototype and conducted two field tests

performed with users. Presents the tests and their results.

Keywords: virtual words, OpenSimulator, cooperative work, F-16, virtual learning

Agradecimentos

Em primeiro lugar quero agradecer aos meus pais. Sem eles o meu percurso

acadmico era impossvel. Deram-me a educao e carinho que todas as pessoas

deveriam ter e fizeram de mim a pessoa que eu sou hoje. Fizeram enormes sacrifcios

para eu conseguir acabar a licenciatura e sempre me incentivaram a seguir mestrado. A

eles, devo-lhes tudo.

Os meus agradecimentos vo tambm para os meus orientadores, Professor

Doutor Leonel Morgado e Professor Doutor Hugo Paredes e para os restantes

professores que sempre me acompanharam neste projeto desde 2010, Professor Doutor

Benjamin Fonseca e Professor Doutor Paulo Martins. As suas orientaes, as suas ideias

e toda a disponibilidade foram chave para a realizao de todo este trabalho.

Aos militares da Fora Area Portuguesa e em especial aos da BA5, um grande

obrigado! Sempre disponveis para ajudar e sempre com um esprito de camaradagem

acima da mdia.

Agradeo muito ao meu grande amigo e companheiro neste projeto, Andr

Pinheiro. Os teus sbios conselhos e ideias permitiu que juntos enfrentssemos os

obstculos que nos apareceram pela frente. A tua fora de vontade, a tua determinao e

a forma como lutas para superar todas as adversidades so contagiantes.

Agradeo tambm aos meus colegas e amigos que estiveram comigo neste

projeto, Isabel, Libnia, Cesar e Jorge. Tivemos grandes momentos de trabalho e

tambm grandes momentos de amizade.

Quero agradecer do fundo do corao a uma pessoa muito especial, minha

namorada. A tua disponibilidade nesta minha ltima etapa, a tua fora nos momentos

mais difceis, a tua confiana nas minhas capacidades foram determinantes para eu ter

conseguido levar todo este trabalho at ao fim.

Por ltimo, quero agradecer Andreia Dinis. Foi com o teu apoio que ganhei

coragem para ingressar na UTAD e comear o meu percurso acadmico de novo. Foi a

melhor deciso que podia ter tido. Tambm graas a ti eu cheguei a esta fase na minha

vida.

ndice ndice de figuras .......................................................................................................................... 15

ndice de Tabelas ......................................................................................................................... 15

Acrnimos ................................................................................................................................... 16

1 Introduo ............................................................................................................................. 1

1.1 Objetivos ....................................................................................................................... 4

1.2 Metodologia Adotada ................................................................................................... 4

1.3 Contexto ........................................................................................................................ 5

2 Anlise de requisitos ............................................................................................................. 7

3 Escolha da plataforma tecnolgica ..................................................................................... 12

4 Mundos virtuais .................................................................................................................. 13

4.1.1 Open Cobalt ......................................................................................................... 16

4.1.2 Open Wonderland ............................................................................................... 17

4.1.3 Second Life .......................................................................................................... 19

4.1.4 OpenSimulator .................................................................................................... 22

5 Desenvolvimento do prottipo ........................................................................................... 25

5.1 Modelo ........................................................................................................................ 25

5.2 Desenvolvimento do prottipo inicial ......................................................................... 27

5.2.1 Anlise e Especificao ........................................................................................ 27

5.2.2 Modelao 3D ..................................................................................................... 28

5.2.3 Protocolo de Comunicao entre OpenSimulator e Web Service ...................... 30

5.2.4 Prottipo ............................................................................................................. 32

5.3 Desenvolvimento do prottipo final ........................................................................... 32

5.3.1 Ambiente 3D........................................................................................................ 32

5.3.2 Reformulao do sistema de controlo e deciso ................................................ 36

6 Testes .................................................................................................................................. 39

6.1 Teste de utilizao 1 .................................................................................................... 40

6.1.1 Anlise das entrevistas ........................................................................................ 41

6.2 Teste de utilizao 2 .................................................................................................... 45

6.2.1 Anlise das entrevistas ........................................................................................ 45

6.3 Teste de validao do sistema .................................................................................... 47

6.3.1 Possibilidade de uma equipa, em simultneo, treinar o processo de instalao

do motor Pratt & Whitney F100 numa aeronave F-16 ....................................................... 47

6.3.2 A simulao ter de cumprir uma sequncia lgica de passos para a instalao

do motor 47

6.3.3 Possibilidade de colaborao e cooperao no trabalho em equipa em

simultneo ........................................................................................................................... 48

6.3.4 O utilizador ter de usar algumas ferramentas para a realizar algumas tarefas 48

7 Concluses, resultados e trabalho futuro ........................................................................... 49

7.1 Resultados ................................................................................................................... 49

7.2 Concluses................................................................................................................... 50

7.3 Reflexes Finais ........................................................................................................... 50

Bibliografia .................................................................................................................................. 52

Anexos ......................................................................................................................................... 56

ANEXO 1 ...................................................................................................................................... 57

ANEXO 2 .................................................................................................................................. 64

ANEXO 3 ...................................................................................................................................... 66

Anexo 4 .................................................................................................................................... 69

ndice de figuras Figura 1. Ciclos da metodologia Design Science (de Hevner, 2007). ............................................ 5

Figura 2. Imagem associada a parte de uma tarefa descrita nas TO .......................................... 11

Figura 3 - Espao Virtual do Open Cobalt.................................................................................... 16

Figura 4 - Partilha do ambiente de trabalho Open Wonderland ................................................ 19

Figura 5 Projeto VITA no Second Life (UTAD) ........................................................................... 22

Figura 6 - Medicina no Second Life ............................................................................................. 22

Figura 7 - Actividade do projecto Young Europeans for Democracy .......................................... 24

Figura 8. - Arquitetura de estados genrica (Fonseca et al., 2011) ............................................ 26

Figura 9. Diagrama de casos de uso para a tarefa "Elevar Motor" ............................................. 27

Figura 10. Diagrama de estados para a tarefa "Elevar Motor" ................................................... 28

Figura 11. Diagrama de atividades para a tarefa "Elevar Motor" ... Erro! Marcador no definido.

Figura 12. Diagrama de classes para a tarefa "Elevar Motor" .................................................... 28

Figura 13. Ambiente 3D Hangar ............................................................................................... 29

Figura 14. Ambiente 3D Extintor .............................................................................................. 29

Figura 15. Ambiente 3D - Escadas de acesso aeronave ........................................................... 30

Figura 16. Avatares com ferramentas anexadas s mos ........................................................... 33

Figura 17. Controlos fornecidos pelo software cliente ............................................................... 33

Figura 18. HUD que representa as mos direita e esquerda ...................................................... 34

Figura 19. Requisio de permisses para usar o teclado .......................................................... 35

Figura 20. HUD em forma de setas ............................................................................................. 35

Figura 21. Diagrama E-R da base de dados do trabalho base ..................................................... 37

Figura 22. Diagrama E-R da base de dados atual ........................................................................ 37

Figura 23. Primeiro teste de utilizao na BA5 ........................................................................... 40

Figura 24 - Segundo teste de utilizao na BA5 .......................................................................... 47

ndice de Tabelas

Tabela 1 - Mundos Virtuais 3D vs. Games Engines 3D ................................................................ 12

Tabela 2. Protocolo de comunicao WebService OpenSim ................................................... 30

Tabela 3. Protocolo de comunicao OpenSim WebService (Objecto Criado) ........................ 31

Tabela 4. Protocolo de comunicao OpenSim WebService ................................................... 31

Tabela 5. Protocolo de comunicao OpenSim OpenSim ........................................................ 31

Tabela 6 - Novas tarefas surgidas aps o 1. teste ..................................................................... 38

Acrnimos

BA5 Base Area n. 5

CFMTFA Centro de Formao Militar e Tcnica da Fora Area

FAP Fora Area Portuguesa

HUD Head Up Display

LSL Linden Scripting Language

SLOGP Second Life Grid Open Grid Protocol

TO Technical Orders

UTAD Universidade de Trs-os-Montes e Alto Douro

Dissertao de Mestrado em Engenharia Informtica Implementao de um Sistema de Formao para Mecnicos da Fora Area Portuguesa

1

1 Introduo A manuteno mecnica de aeronaves F-161 um processo extremamente

complexo, rigoroso, delicado e exaustivo, que requer uma formao (acompanhada de

treino) com preciso e rigor. Este processo inclui vrias tarefas colaborativas, exigindo

uma equipa de pelo menos 3 mecnicos. Especificamente, h tarefas que, embora

individuais, requerem a validao por outra pessoa, com a preparao adequada; e

outras que so impossveis de concretizar em segurana e com rigor sem a colaborao

de mais do que um elemento.

Para que a formao destes mecnicos possa tambm ser realizada em equipa, de

forma colaborativa, necessrio encontrar disponibilidades comuns de horrio e alguma

homogeneidade de preparao prvia por parte dos mecnicos. Estes constrangimentos

limitam as oportunidades para treino em equipa.

Outro constrangimento que a formao em manuteno mecnica de aeronaves

F-16 passa necessariamente pelo treino das tarefas sobre uma aeronave fsica. Esta

necessidade de uma aeronave fsica para a realizao do treino um constrangimento

adicional da formao, alm de ser uma fase com maior risco de ocorrncia de danos ao

material e mesmo de ocorrncia de leses aos participantes. Dado que o nmero de

aeronaves F-16 em Portugal limitado e a sua disponibilidade essencial para a

execuo das misses da FAP2, importante minimizar estes riscos e ter formas de

realizar o treino com menor constrangimento face disponibilidade das aeronaves.

Neste contexto, a disponibilidade de uma ferramenta que permita uma formao

mais frequente em equipa, por combate a estes constrangimentos uma mais-valia para

os esquadres de manuteno da FAP (Fonseca et al., 2011). Neste sentido, a evoluo

das tecnologias proporcionou o aparecimento de diversas possibilidades tcnicas para

criao de sistemas multiutilizador 3D, que permitem criar um ambiente imersivo

virtual semelhante ao ambiente real, para simular processos, inclusivamente em equipa.

Das plataformas existentes para desenvolvimento de sistemas multiutilizador 3D,

destacam-se os mundos virtuais 3D e os game engines. As tecnologias de mundos

1 http://www.emfa.pt/www/aeronave-18-lockheed-martin-f-16-am 2 http://www.emfa.pt/www/index.php


2

virtuais, mais conhecidas por produtos comerciais de entretenimento com milhes de

utilizadores (World of Warcraft3, Second Life4, FarmVille5, entre outros), permitem o

desenvolvimento de sistemas abstraindo a complexidade da gesto de comunicaes,

sincronizao de estado em rede e outros aspetos similares. O uso destas tecnologias na

rea da formao tem vindo a ganhar relevo nos ltimos anos, inclusivamente na

produo de videojogos designados por serious games. Mesmo a simulao de

atividades da vida real em mundos virtuais considerada um subconjunto dos serious

games (Krause 2009), sendo o caso aqui em anlise (a formao em manuteno

mecnica aeronutica) precisamente uma simulao. J os game engines permitem

igualmente o desenvolvimento de simulaes multiutilizador, at com maior grau de

liberdade quanto s caractersticas de desenvolvimento, mas impondo ao programador

maior complexidade na gesto dos aspetos de baixo nvel acima referidos.

Estas tecnologias permitem interligar utilizadores que se encontrem separados

fisicamente, proporcionando a comunicao entre eles ou mesmo a realizao de aes

de forma colaborativa.

Para colmatar as necessidades sentidas pela FAP, suprarreferidas, estabeleceu-se

um protocolo entre esta e a UTAD, no mbito do qual tem vindo a ser desenvolvido um

simulador 3D para a formao de mecnicos na manuteno de aeronaves F-16.

Este processo tem vindo a focar-se no processo de instalao de um motor Pratt &

Withney F100 na fuselagem de uma aeronave F-16. O desenvolvimento do simulador

iniciou-se em 2010, no contexto de projetos de licenciatura, tendo sido prosseguido em

2011 no mbito de projetos de primeiro ano de mestrado, desembocando por fim no

trabalho de suporte presente dissertao. Em todo este processo, que integrei desde o

seu incio, realizou-se a anlise de requisitos do sistema e a implementao de uma

primeira verso do simulador.

A presente dissertao apresenta os trabalhos prvios como enquadramento,

centrando-se nos aspetos finais, desenvolvidos por mim: correo de erros da anlise

original do processo de instalao do motor, reformulao do sistema de controlo e

3 http://eu.battle.net/wow 4 http://secondlife.com/ 5 http://www.farmville.com


3

deciso, realizao de testes de utilizao junto dos mecnicos da BA5 e reformulao

de etapas realizadas anteriormente no ambiente 3D.

Dado o meu envolvimento em todo o processo, torna-se necessrio expor todo o

contexto na presente dissertao.

Todo este trabalho me trouxe uma enorme motivao. Trabalhar com plataformas

3D era algo que ambicionava, constituindo um enorme desafio, j que antes de me

envolver neste projeto, em 2010, no tinha qualquer conhecimento nem preparao

nesta rea. Foi este ambiente desafiante que me deu ainda mais fora para avanar at

ao estado atual do trabalho. Outra grande motivao foi o facto de este projeto ser em

parceria com a FAP, uma instituio com enormes responsabilidades no pas. Trabalhar

com a FAP seria e foi algo que fiz com enorme orgulho.

A presente dissertao est estruturada da seguinte forma: no captulo 2 so

apresentados os objetivos do trabalho de suporte a esta dissertao. No captulo 3

descrita a metodologia adotada para a elaborao deste trabalho enquadrando as etapas

efetuadas com as metodologias da metodologia. A contextualizao segue-se no

captulo 4, neste apresentado como realizada a formao dos militares da FAP e

quais os problemas encontrados. apresentada tambm a forma como surgiu a

colaborao entre a UTAD e a FAP. A seguir, no captulo 5, so apresentados os

requisitos identificados para a resoluo dos problemas encontrados e como foram

identificados. Perante estes requisitos foi escolhida uma plataforma tecnolgica, que o

foco do captulo 6, onde se comparam alguns aspetos entre duas alternativas de

plataformas existentes. O captulo 7 est dividido em duas seces, onde inicialmente

dada uma viso geral dos mundos virtuais, do ponto de vista do programador, sendo

depois analisados com mais detalhe alguns exemplos de mundos virtuais 3D. No

captulo 8 apresentado o modelo criado e que serviu de suporte a este trabalho,

explicando o seu funcionamento. No captulo 9 apresentado o trabalho desenvolvido

na produo de um prottipo do simulador, descrevendo erros encontrados numa

primeira verso do prottipo (anterior presente dissertao), correes dos mesmos e

novas tarefas. Aps a concluso deste prottipo foram realizados testes de utilizao

descritos no captulo 10. Os resultados destes testes encontram-se descritos de seguida

no captulo 11. Destes resultados foi permitido tirar concluses sobre estes trabalhos


4

que so apresentadas no captulo 12. Por fim, no captulo 13, so apresentadas algumas

reflexes finais e caminhos possveis a seguir.

1.1 Objetivos Nos trabalhos anteriores, conforme se mencionou na introduo, fez-se uma

anlise inicial dos requisitos do sistema e, com base nela, procedeu-se implementao

de uma primeira verso do simulador. Esta primeira verso no fora testada em contexto

de utilizao (apenas apresentada como demonstrao), nem permitia simular o

conjunto integral de tarefas associadas introduo do motor na fuselagem da aeronave.

Desta forma, o objetivo principal do trabalho em que se baseia esta dissertao foi

contribuir para que o nvel de desenvolvimento do simulador permita a sua utilizao

efetiva pela BA5, dando continuidade ao desenvolvimento do simulador. Neste sentido,

era necessrio:

continuar desenvolver um sistema capaz de simular todo o processo da

instalao de um motor na fuselagem de um F-16;

aumentar o conjunto de tarefas simuladas no processo de instalao do

motor na fuselagem;

testar o prottipo em termos funcionais;

testar o prottipo em contexto de utilizao, com utilizadores finais;

colmatar limitaes do funcionamento e corrigir erros identificados.

Face ao conhecimento aprofundado que possua acerca do estado de

desenvolvimento do simulador, em virtude de ter estado ligado s equipas que

efetuaram a sua conceo e desenvolvimento desde o primeiro momento, havia

igualmente conscincia de que, para cumprir as tarefas acima indicadas, seria necessrio

efetuar a correo de alguns erros da anlise original do processo de instalao do

motor. Pretendi tambm reformular o sistema de controlo e deciso, para tornar mais

gil a implementao de correes futuras e com a ambio de poder lev-lo a ser uma

base de partida mais flexvel para outros problemas de simulao.

1.2 Metodologia Adotada Ao longo do processo global de desenvolvimento do simulador, incluindo a parte

de base presente dissertao, optou-se pelo uso da metodologia Design Science.


5

Figura 1. Ciclos da metodologia Design Science (de Hevner, 2007).

Nesta metodologia (Figura 1), segundo Hevner (2007), o foco da investigao

incide em trs ciclos. No ciclo da relevncia analisado o ambiente contextual do

projeto de pesquisa e feita uma ponte para as atividades de design (conceo). O ciclo

do rigor liga as atividades de conceo experiencia e conhecimento de fundamentos

cientficos. O ciclo de conceo alterna entre atividades essenciais de construo e

avaliao dos artefactos produzidos e dos processos de investigao.

Perante esta metodologia, o ciclo de relevncia, que incide sobre o ambiente,

descrito no captulo 4. Os resultados desse ciclo so fundamentalmente os requisitos,

cuja anlise apresentada no captulo 5. Para o ciclo do rigor foram realizadas vrias

pesquisas de artigos cientficos de vrias plataformas possveis para a realizao deste

projeto, descritos no captulo 6 e como se iria estruturar todo o processo, descrito no

capitulo 8. Tudo isto permitiu criar uma ponte para a produo dos artefactos e

processos descritos no captulo 9. Estes artefactos foram sofrendo constantes

avaliaes por parte da equipa de desenvolvimento de modo a detetar e corrigir o maior

nmero de possveis falhas. Com um prottipo j implementado, foram realizados testes

de campo de modo a avaliar todo o processo. Aqui entrou-se novamente no ciclo da

relevncia, onde foram detetados novos problemas e de onde surgiram novos requisitos.

1.3 Contexto A Fora Area Portuguesa utiliza aeronaves F-16, sendo a BA5, na Serra do Porto

de Urso (Monte Real, Leiria), a base area especializada nestas aeronaves. tambm a

nica onde esto situadas e onde realizada toda a sua manuteno.


6

As aeronaves F-16 usam motores Pratt & Whitney F100-PW-220E6, sendo a

recomendao do fabricante terem de ser inspecionados de periodicamente consoante o

nmero de horas de voo. na BA5 que a generalidade desse trabalho feita7. Antes e

depois dos voos h sempre inspees, mas a manuteno programada de um F-16

realizada de 300 em 300 horas. Esta manuteno realizada por mecnicos

especializados da FAP dentro de hangares na BA5.

Estes mecnicos passaram por um processo de formao. Esse processo iniciado

logo aps a seleo da especialidade pelo militar: numa primeira fase a formao

desenvolve-se na base militar da Ota8, no CFMTFA9 (Centro de Formao Militar e

Tcnica da Fora Area); numa segunda fase, nas outras bases areas existentes em

Portugal onde os mecnicos venham a ser colocados, de acordo com a especialidade de

cada uma (Vilela et al., 2012).

Os militares destacados para a seco de operaes da linha da frente, de ataque, e

para a manuteno dos motores que equipam as aeronaves F-16, os j mencionados

Pratt&Whitney F100, tm inicialmente uma formao simples sobre as componentes

gerais da aeronave F-16 e s posteriormente iniciam o curso de formao mais

intensivo, denominado Curso de Motor F100-PW-220E Nvel O. Esta formao

engloba uma parte terica, onde so estudados todos processos descritos nos

documentos tcnicos fornecidos pelo fabricante (designados Technical Orders ou

TO). Engloba tambm uma parte prtica, que requer o uso fsico de materiais, motores e

aeronaves. Este uso fsico faz com que esses materiais, motores e mesmo aeronaves

fiquem indisponveis para qualquer tipo de misses ou emergncias durante todo o

tempo da formao, conferindo a estes momentos de formao um custo elevado. Alm

de tal ocorrer durante bastante tempo (cerca de 6 horas), existem tambm gastos

materiais e envolvimento de formadores especializados, cuja disponibilidade seria de

valor acrescentado noutros servios.

6 http://www.pratt-whitney.com/F100_Engine 7 Informalmente, os mecnicos da BA5 mencionam fazer 80% dos trabalhos associados. Note-se, por exemplo, esta notcia recente, veiculada na comunicao social, que refere a capacidade tcnica da FAP, na BA5. http://www.rtp.pt/noticias/index.php?article=614612&tm=8&layout=122&visual=61 8 http://portugalfotografiaaerea.blogspot.com/2009/08/fotografia-aerea-base-aerea-da-ota.html 9 http://www.emfa.pt/www/unidade-52-centro-de-formacao-militar-e-tecnica-da-forca-aerea


7

A conscincia da existncia e relevncia destes constrangimentos surgiu numa

reunio realizada entre membros militares da BA5 responsveis pela formao e os

membros das equipas de investigao da UTAD, onde se procurava auscultar

oportunidades de cooperao. Dessa circunstncia surgiu a proposta de desenvolver um

sistema de simulao 3D capaz de simular as tarefas de manuteno mecnica dos

motores dos F-16, que permitisse aos formandos treinar as etapas e procedimentos

dessas tarefas, mas tambm praticar aspetos de coordenao e colaborao no trabalho

em equipa. Ao faz-lo num ambiente simulado, a ambio seria que pudessem praticar

vrias vezes, a qualquer hora do dia, no necessitando de envolver peas mecnicas nem

aeronaves fsicas para o fazer, bastando apenas um computador ligado rede da BA5 e

o software necessrio para realizar o treino.

Para dar suporte a esta colaborao, a Universidade de Trs-os-Montes e Alto

Douro (UTAD) e a FAP firmaram um protocolo associado rea do e-learning e

simulaes, ao abrigo do qual se desenvolveram as tarefas subsequentes descritas nesta

dissertao. No existe financiamento associado a este protocolo. As atividades

desenrolam-se no contexto de unidades curriculares de projeto, embora seja possvel

que possam surgir outras formas de colaborao e desenvolvimento das mesmas. de

salientar que sendo essas unidades curriculares fundamentalmente semestrais, a durao

previsvel para o projeto (mdia ou longa) ser superior durao de qualquer unidade

curricular. Consequentemente, expectvel que ocorra regularmente alterao das

pessoas envolvidas no desenvolvimento (ou seja, que os alunos envolvidos variem

medida que se iniciam ou terminam os semestres letivos), aspeto que afeta a anlise de

requisitos, como se expor na seco 6.

2 Anlise de requisitos Para identificar concretamente como seria realizada a colaborao entre a UTAD

e FAP, mais especificamente neste caso a BA5, foram concretizadas vrias reunies na

BA5. Ao longo destas reunies foram encontradas quatro alternativas. Simular o

processo de instalao do motor na fuselagem do F-16, simular o processo de remoo

do motor, simular a desmontagem do motor e simular a montagem do motor.

Destas quatro alternativas a escolhida, por preferncia da equipa de

desenvolvimento, foi a simulao da instalao do motor na fuselagem do F-16.


8

Para esta simulao, em termos de funcionamento, pretende-se que os formandos

se sintam familiarizados com a simulao existente e com o ambiente que vo

encontrar. Pretende-se com isto que os formandos consigam rapidamente identificar

onde devem atuar e de que forma, para que a coordenao do trabalho em equipa

decorra com base no que teriam no local fsico (voz e estado do trabalho), no com

outras indicaes (indicadores de evoluo, monitores informticos, etc.).

Todo este processo deve ser o mais prximo possvel da situao real, um

ambiente imersivo onde seja possvel ao formando ter a noo clara do espao onde est

e de todo o meio envolvente. Isto levou escolha de tecnologia de mundos virtuais 3D,

conforme se detalha no captulo 6.

A obteno de dados e informaes necessrias para definir os requisitos foi

realizada atravs de: reunies na BA5; filmagem ao vivo de todo o processo; e

fotografias. Esta recolha foi complementada atravs de esclarecimento regulares, em

conversas no estruturadas com todos os intervenientes, ao longo do processo.

Todos estes dados foram posteriormente analisados atravs da visualizao dos

vdeos, leitura das TO e visualizao das fotografias recolhidas. Desta anlise, produziu-

se um manual de instalao, clarificando as tarefas dos vrios mecnicos e conjugando

as instrues das TO (Figura 2) com os atos observados no local.

Da anlise destes dados concluiu-se que este sistema iria ser usado por pessoas

que ainda se esto a formar na manuteno de motores e na sua maioria com alguma

experiencia na tica de utilizador no contexto informtico, pois usam o computador

regularmente nas suas tarefas do dia-a-dia.

A manuteno destes motores sempre realizada nos mesmos espaos, idnticos

entre si; e a instalao dos motores num F-16 realizada obrigatoriamente por trs

mecnicos, tendo igualmente de existir um responsvel pela verificao (por vezes, um

dos trs mecnicos pode acumular as funes de mecnico e de verificador; outras

vezes, o verificador um quarto elemento da equipa).

A recolha e anlise dos elementos acima referidos, complementada pelas

conversas informais tidas durante o processo, foram efetuadas por outros colegas de

licenciatura e de mestrado, com a minha colaborao, em trabalhos de projeto de


9

licenciatura e projetos de primeiro ano de mestrado, anteriores ao trabalho de suporte a

esta dissertao (Pinto & Teixeira, 2010a, b). Dessa anlise extraram-se os seguintes

aspetos especficos a considerar:

Cada mecnico tem as suas ferramentas;

Existem procedimentos em que a cooperao, a colaborao e o trabalho em

equipa so obrigatrios;

Os mecnicos comunicam entre si durante todo o processo, usando a

linguagem verbal como principal meio de comunicao;

O processo de instalao exige toda uma sequncia de passos, no sendo

possvel realizar uma determinada tarefa sem que a anterior tenha sido

concluda;

Aps uma primeira fase, em que existe apenas uma sequncia de tarefas e

em que necessria a presena e a colaborao de todos os membros da

equipa, a sequncia original divide-se em trs sequncias de tarefas

paralelas e independentes entre si;

Os mecnicos no tm qualquer limitao de movimentos podendo

caminhar livremente por todo o hangar;

Cada mecnico tem um determinado conjunto de tarefas que s cabe a si

executar, no podendo executar qualquer outra tarefa que pertena a outro

elemento da equipa, a no ser que tal lhe seja solicitado por esse elemento.

As TO podem sofrer alteraes de acordo com ordens do fabricante e as

suas indicaes nem sempre so seguidas na ntegra.

Perante os dados da anlise, extraram-se os seguintes conjuntos de requisitos:

Requisitos no funcionais:


10

Limitaes a nvel de rede, para formao a BA5 no possui boas

ligaes de rede ao exterior, apenas alguns computadores possuem

internet e todos os contedos so filtrados;

Cada mecnico tem um conjunto de aes que apenas ele pode realizar;10

Todo o processo tem etapas onde algumas no podero ser executadas

sem que a etapa anterior esteja concluda.11

Requisitos funcionais:

possibilidade de uma equipa, em simultneo, treinar o processo de

instalao de um motor Pratt & Whitney F100 numa aeronave F-16;

a simulao ter de cumprir uma sequncia lgica de passos para a

instalao do motor;

possibilidade de colaborao e cooperao no trabalho em equipa em

simultneo;

o utilizador ter de usar algumas ferramentas para a realizar algumas tarefas

(aparafusadora, extenso, etc)

10 Consultar Pinto, I. & Teixeira, L. (2010b). 11 Consultar Pinto, I. & Teixeira, L. (2010a).


11

Figura 2. Imagem associada a parte de uma tarefa descrita nas TO


12

3 Escolha da plataforma tecnolgica Face aos requisitos apresentados no captulo 5 e ao contexto descrito no captulo 4

tnhamos presentes dois tipos de plataformas potenciais: mundos virtuais ou game

engines. Esta ponderao advm do requisito de se pretender que os formandos se

sentissem familiarizados com a simulao existente e com o ambiente que iriam

encontrar.

Tabela 1 - Mundos Virtuais 3D vs. Games Engines 3D

Mundos Virtuais 3D Game Engines 3D Apresenta um ambiente 3D

semelhante ao real

Sim Sim

Gesto de Sistema

Multiutilizador

Incorporado No Incorporado

Apoio dos Docentes

(contexto de

desenvolvimento em

unidades curriculares)

Docentes j orientaram

vrios projetos na rea

Docentes orientaram

poucos projetos na rea

Permite criar um ambiente

3D personalizado

Sim Sim

Conforme se mencionou no captulo 4, o contexto de alterao ou potencial

alterao regular dos integrantes das equipas de desenvolvimento. Face a esta situao,

considerou-se necessrio que a plataforma a utilizar fosse uma para a qual os docentes

orientadores pudessem potenciar o know-how existente, no apoio aos alunos que o

iniciariam, e posteriormente integr-lo nas atividades de investigao que venham a dar

seguimento a este trabalho, inclusivamente em caso de reformulao da equipa.

Pretendia-se com este projeto a validao da abordagem de simulao para

formao de manuteno mecnica perante a FAP. Neste sentido, a utilizao de game

engines 3D dificultava este objetivo, na medida em que no permitira prototipar um

contexto multiutilizador num curto espao de tempo, pois as funcionalidades de gesto

multiutilizador nos game engines no esto to desenvolvidas como nas plataformas de

mundos virtuais.

Aps a anlise dos requisitos referidos na tabela 1, a seleo recaiu para o uso de

mundos virtuais 3D para a elaborao do projeto.


13

4 Mundos virtuais O uso dos mundos virtuais multiutilizador, quer por pessoas, quer por empresas,

tem vindo a ser adotado em crescente nos ltimos anos e j foram utilizados por milhes

de utilizadores (Woodcook, 2008). So realidades alternativas onde os utilizadores

conseguem interagir entre si e sobre os elementos neles presentes. O sector dos mundos

virtuais tem crescido fortemente nos ltimos anos. No final do primeiro trimestre de

2012 os mundos virtuais atingiram 1.921 milhes de contas registadas (KZERO, 2012).

Segundo Morgado (2009) os mundos virtuais so um tipo de ambiente virtual.

Para que um ambiente virtual possa ser considerado um mundo virtual existem dois

aspetos essenciais que tm de estar presentes: multiutilizao e imersividade. Ou seja,

um ambiente que possibilite a conexo de vrios utilizadores dentro do mesmo

ambiente e que os mesmos estejam representados no interior desse ambiente.

Morgado (2012) afirma que pode-se pensar os mundos virtuais como trs tipos:

Simulao da realidade, sob a perspectiva de os ver como forma de

enriquecer o contexto em que decorre o ensino, aproximando-o dos

contextos em que se pretende exercer posteriormente o contedo e

competncias desse ensino;

Sociais- espaos de socializao e de criao de comunidades virtuais;

Jogos, Massive Multiplayer Online Role-Playing Games (MMORPG).

O World of Warcraft um dos mais conhecidos jogos comerciais MMORPG.

um mundo virtual com mais de 8,5 milhes de utilizadores registados em todo mundo.

O uso do World of Warcraft ou de outro MMORPG existente para a elaborao

do projeto ao qual se destina esta dissertao invivel pois estes mundos virtuais so

sistemas fechados onde a criao por parte do utilizador no permitida

Segundo Amaral (2008), os mundos virtuais caracterizam-se por serem ambientes

gerados por computao grfica 2D ou 3D, que so partilhados por pessoas

fisicamente e geograficamente distantes e que se conectam via rede. Estes podem ser

classificados, alm os tipos referidos em cima por Morgado (2012), em mais dois tipos:


14

Expresso Poltica servem como fruns de expresso poltica e de

debate;

Treino Militar - espaos criados para aes de simulao de treino

militar.

Estes mundos so mais do que meros ambientes de chat tridimensional: so os

avatares que controlam e podem interagir com objetos e outro tipo de elementos

presentes no mundo, organizam eventos, associaes, atividades diversas. Estas aes

podem ser de natureza imersiva, ou seja, cujo significado se esgota dentro do mundo

virtual, mas podem igualmente ser aumentativas, ou seja, terem impacte na vida real dos

utilizadores, utilizando o mundo virtual como ferramenta de comunicao e expresso.

(Pereira et al., 2008). Existem no entanto mundos virtuais que convergem todas estas

categorias como o caso do Second Life.

O Second Life no de todo um jogo, mas sim um mundo virtual 3D onde os

utilizadores podem, colaborativamente ou sozinhos, construir objetos, atribuir-lhes

comportamentos e usa-los para o contexto que entenderem, ampliando assim o campo

de comunicao e convivncia humana. este tipo de caractersticas que importa para o

fim a que esta dissertao se destina, a simulao da instalao de um motor numa

aeronave F16.

Desde que o Second Life tornou pblico o seu protocolo de comunicao entre os

servidores da plataforma Second Life Grid (cdigo fonte privado) e o software cliente

Second Life (cdigo-fonte aberto) promoveu uma maior rapidez de desenvolvimento de

uma plataforma alternativa que tinha aparecido atravs de retroengenharia, denominada

por OpenSimulator.

Embora o OpenSimulator por enquanto ainda no tenha implementado todas as

funcionalidades existentes do Second Life j se pode considerar como uma forte

alternativa pois uma plataforma de cdigo-fonte aberto, o que permite a toda uma

comunidade existente fazer evoluir a mesma. A implementao do protocolo

facilitada pela existncia da biblioteca libopenmetaverse12, em cdigo-fonte aberto, que

12 Biblioteca cliente/servidor desenvolvida em .Net, que permite aceder e criar mundos virtuais 3D que implementem o protocolo Second Life (http://lib.openmetaverse.org/wiki/Main_Page)


15

permite iniciar sesses de clientes em servidores e aceder s vrias possibilidades do

protocolo a mais alto nvel, de forma simplificada.

Apesar de estes dois mundos virtuais 3D terem plataformas idnticas

(OpenSimulator e Second Life Grid), a implementao das suas plataformas so

diferentes pois a comunidade que trabalha com o OpenSimulator no pretende copiar o

Second Life mas sim diferenciar-se e a criar as suas prprias funcionalidades, exemplo

disso a forma como so armazenados os dados nas duas plataformas, enquanto o

Second Life armazena a informao num servidor de ficheiros o OpenSimulator utiliza

uma base de dados para o mesmo efeito, sendo que esta situao totalmente

transparente para o software-cliente (Sequeira, 2009).

As implementaes subjacentes destas plataformas so diferentes, mas so

habitualmente transparentes do ponto de vista do software-cliente (por exemplo,

enquanto os servidores SecondLife Grid armazenam alguma informao num servidor

de ficheiros o OpenSimulator utiliza uma base de dados para o mesmo efeito, sendo que

esta situao transparente para o software-cliente) (ibid.).

Nos prximos subcaptulos sero analisados alguns exemplos de mundos virtuais

3D, os quais seriam possveis alternativas para a realizao deste projeto bem como as

respetivas plataformas tecnolgicas que lhes servem de suporte; escolhidos devido sua

repercusso social e s possibilidades de trabalho colaborativo.

Das quatro plataformas que de seguida so descritas, apenas o Second Life no

cumpre um dos requisitos. O Second Life uma plataforma que necessita de pagamento

por parte dos utilizadores que queriam criar os seus prprios projetos. Como foi descrito

no captulo 4, este projeto no foi financiado, o que tornou invivel a utilizao do

Second Life, sendo que este mundo virtual exige boas ligaes de rede ao exterior o que

no existe na BA5 como foi mencionado no captulo 5.

Para a elaborao do projeto presente nesta dissertao optou-se pelo uso do

mundo virtual 3D OpenSimulator descrito mais detalhadamente no captulo 6.4.

Escolhido por cumprir todos os requisitos levantados e por ser aquele o qual os docentes

teriam maior conhecimento pois como foi mencionado no captulo 3 expectvel que

ocorra regularmente alterao das pessoas envolvidas no desenvolvimento


16

4.1.1 Open Cobalt

O Open Cobalt13 (Figura 3) derivado do software Croquet, que foi lanado

publicamente sob a licena MIT pela Hewlett-Packard e pelo Consrcio Croquet no

incio de 2007. Tem como objetivo distribuir a todas as pessoas uma plataforma gratuita

e de cdigo-fonte aberto, que permita a criao, acesso e partilha de mundos virtuais

colaborativos, tanto em rede local como pela Internet, sem ter de recorrer a servidores

centralizados. Foi lanado em verso alfa em 2010.

Figura 3 - Espao Virtual do Open Cobalt

[Fonte: http://www.opencobalt.org/]

O Open Cobalt no considerado na sua essncia um mundo virtual, mas sim um

kit de ferramentas que permitem aos utilizadores a criao dos seus prprios mundos

virtuais. Pode-se definir como uma ferramenta que permite criar, aceder e interagir com

mundos virtuais que existam localmente num computador ou em qualquer lugar numa

rede.

Esta tecnologia permite criar ambientes virtuais e espaos de aprendizagem

baseados em jogos, tornando tambm possvel que escolas ou outras organizaes

estabeleam livremente as suas prprias redes, tanto pblicas como privadas em 3D,

chat de voz, chat de texto e acessos a aplicaes de acesso remoto ao ambiente de

trabalho e servios.

13 http://www.opencobalt.org/
http://www.opencobalt.org/


17

O Open Cobalt usa o Squeak14, um sistema gratuito Smalltalk, disponvel para

Windows, Mac e Unix/Linux. Como o sistema Smalltalk, pode ser atualizado mesmo

estando em funcionamento sem precisar de ser reiniciado.

Para correr o Open Cobalt so necessrios os seguintes requisitos:

Ligao internet por cabo ou ADSL;

Processador Pentium III ou superior;

1GB ou mais;

Processadores grficos que cumpram no mnimo com o OpenGL 151.3, para se

usar movimento de avatares, precisa do OpenGL 1.5 ou superior;

Para udio necessita de OpenAL para Linux pois usa o OSS API para gravar a

partir do microfone.

Ao usar a tecnologia peer-to-peer16 permite reduzir a dependncia de servidores

para garantir o apoio bsico de todas as interaes, dividindo a carga pelos utilizadores,

o que permite uma menor exigncia de largura de banda.

Teoricamente, ao usar esta tecnologia deveria permitir obter maior escalabilidade

e suportar um grande nmero de utilizadores em simultneo por servidor. Mas na

prtica, esta plataforma ainda no demonstrou encontrar-se preparada para um grande

nmero de utilizadores em simultneo, uma vez que podem ocorrer erros que obriguem

ao reincio do servidor onde estes ocorrem (Pereira, 2010).

4.1.2 Open Wonderland

Segundo Kaplan & Yankelovich (2011), o Open Wonderland (Open Wonderland,

2012b) um kit de ferramentas que permite construir mundos virtuais 3D. Possui todo o

seu cdigo fonte aberto seguindo a licena da General Public Licence17 (GNU v2),

sendo este inteiramente desenvolvido em Java, pela empresa Sun Microsystems18.

14 http://www.squeak.org/ 15 API livre utilizada na computao grfica, para desenvolvimento de aplicativos grficos, ambientes 3D, jogos, entre outros. http://pt.wikipedia.org/wiki/OpenGL 16 Todos os clientes de software ligados ao sistema partilham recursos entre si para propiciar o resultado final (no h recurso a um servidor central). 17 Designao da licena para software livre. http://www.gnu.org/licenses/gpl.html 18 http://www.oracle.com/us/sun/index.htm


18

Dentro destes mundos virtuais os utilizadores conseguem socializar com outros,

colocar msica, abrir ficheiros no formato PDF, HTML, fazer streaming de vdeo e

tambm partilhar aplicaes do seu ambiente de trabalho ao vivo (Figura 4).

Com o OpenWonderland possvel criar ambientes virtuais 3D para

aprendizagem, ambientes colaborativos e simulaes interativas.

O objetivo do Open Wonderland no criar um mundo virtual 3D pronto a ser

utilizado, mas sim ser utilizado para criar ambientes virtuais personalizados,

incentivando a criao de ambientes colaborativos para empresas, universidades ou

apenas para entretenimento. (Open Wonderland, 2012a)

O Open Wonderland extensvel, designers grficos e programadores podem usar

toda a sua competncia e imaginao para criar mundos virtuais totalmente novos e

personalizados ou at mesmo adicionar novos recursos aos mundos virtuais j

existentes.

uma tecnologia experimental que est ainda numa fase inicial de

desenvolvimento. Atualmente gerido pelo Open Wonderland Foundation, no tem ainda

acesso a testes de controlo de qualidade, documentao, marketing ou outros recursos

tipicamente associados a um grupo de produtos.

Para correr o cliente do Wonderland necessrio um computador no mnimo com

1.5 GHz de processador mais 1GB de memria RAM acelerados por drivers OpenGL

instaladas. Para Solaris e Linux so recomendadas placas grficas Nvidia pois segundo

a Open Wonderland Foundation, so mais estveis e mais completas de recursos que as

restantes. A memria da placa grfica aconselhada de 256MB. (Open Wonderland,

2012)

Os requisitos mnimos para um servidor Wonderland so os mesmos que o

cliente. Se um servidor Wonderland estiver instalado um computador porttil, este

aguenta apenas com um ou dois clientes, caso a inteno seja suportar mais clientes

aconselha-se a instalar num servidor

Uma vez que o Open Wonderland baseado em Java, o cliente pode ser

executado em Windows, Mac OS X, Linux e Solaris.


19

possvel trabalhar com o Firefox, Open Office , NetBeans, GIMP ou outro

qualquer aplicativo que possa ser executado no ambiente grfico X do Linux desde que

o servidor seja executado em Linux ou Solaris.

Para executar a verso cliente do Open Wonderland necessria ter o Java

Runtime Environment v6.

Figura 4 - Partilha do ambiente de trabalho Open Wonderland

Fonte: [http://blogs.openwonderland.org/2011/01/21/comslive-research-results/]

Alm deste servidor, esta tecnologia tambm depende de outros projetos

realizados pela Sun Microsystems, todos eles tambm de cdigo fonte aberto. (Java3D,

Project Looking Class e jVoiceBridge).

4.1.3 Second Life

O SL um mundo virtual 3D que pode ser considerado como uma rede social 3D,

onde todos os avatares presentes so pessoas reais e tudo o que pode ser visto criado

pelos utilizadores, que podem optar por faz-lo sozinhos ou colaborativamente com

outros avatares (Boulos et al, 2007). Foi criado pela empresa Linden Lab em 2003 e


20

recorre ao protocolo Second Life Grid Open Grid Protocol19 (SLGOGP). Desde que se

tornou pblico este protocolo entre servidores Second Life Grid e o software cliente

Second Life, proporcionou-se o aparecimento de plataformas alternativas, como

exemplo, o OpenSimulator.

O SL um ambiente virtual 3D para pessoas com idades acima dos 16 anos, no

entanto educadores que trabalhem com jovens com idades compreendidas entre 13 e 15

anos tm a opo de criar seguros e propriedades privadas, limitando o acesso a

determinados contedos.(Second Life, 2012)

O registo no SL gratuito, no entanto para possuir uma propriedade e poder

construir nela necessrio pagar uma mensalidade. Cada propriedade denominada de

regio e possui medidas de 256x256 metros, onde toda a informao gerada enviada

atravs de streaming implementado sobre UDP20, tolerando desta forma falhas

relacionadas com a perda e chegada fora de ordem de pacotes (Fitzgerald, 2007).

Esta plataforma possibilita a criao de contedo em tempo real e de forma

imersiva, atravs de ferramentas prprias, possibilitando tambm a partilha de texto,

imagens, vdeo, etc.. A comunicao pode ser feita atravs de texto.

Cada regio pertence a um proprietrio que livre de construir e criar o que

entender, cabendo a este a gesto da mesma. Todas as regies existentes no SL esto

organizadas numa grelha bidimensional designada por grid. Todos os avatares so livres

de percorrer qualquer regio existente na grid e interagir com esta, limitando-se sempre

gesto do proprietrio de cada regio por onde passa.

As regies podem conter vrios objetos e avatares, sendo que cada objeto pode

conter inmeros recursos, tais como outros objetos, texturas, formas, scripts, etc. Cada

objeto pode ter um comportamento, que programado atravs de scripts, scripts esses,

baseados em eventos, que so programados em LSL21 (Linden Scripting Language),

uma linguagem da qual a Linden Lab proprietria.

19 http://wiki.secondlife.com/wiki/Open_Grid_Protocol 20 User Data Protocol protocolo que permite a comunicao entre diferentes computadores, sendo esta comunicao sem conexo, no garante a chegada dos pacotes em ordem particular 21 http://wiki.secondlife.com/wiki/LSL_Portal


21

O facto de para possuir uma regio no SL ser necessrio pagar uma mensalidade

empresa Linden Lab, constitui uma enorme desvantagem para a realizao do projeto

que aqui apresentamos, pois um requisito que foi imposto pela FAP: a simulao ter

de ser realizada numa plataforma gratuita. Aps ter uma regio na sua posse o

proprietrio pode construir vrios objetos sem custo, tendo apenas de respeitar o limite

mximo que cada regio permite. No entanto, sempre que pretender importar um objeto

externo construdo em aplicaes mais robustas em termos de design (ex. Blender ou

3DMax) ter de pagar tambm por esse objeto, variando o preo consoante as

caractersticas de cada um. Num projeto complexo como este torna-se bastante

dispendioso o uso desta plataforma.

Para alm disso, o SL est dependente de uma nica empresa onde os servidores

se encontram alojados, a Linden Lab. No caso de existir um problema, ter de ser a

empresa Linden Lab a resolver.

Apesar das desvantagens mencionadas, o SL destaca-se em relao aos restantes

mundos virtuais 3D no uso em reas do ensino e aprendizagem, assim como para

treino.(Vilela et al, 2012) Existem vrias instituies a usar o SL para estas finalidades,

criando variadssimas simulaes de treino como respostas de emergncia (Chen, Y. et

al, 2008), gesto empresarial (Rodrigues, C.,2009), mdica e cenrios de sade (Boulos,

M., 2007) , foras de segurana (Hudson, K., 2009) e educao (Figuras 5 e 6).

Para correr o Second Life necessrio um computador 1.5 GHz de processador

mais 512MB de memria RAM. So recomendadas no mnimo as placas grficas

NVIDIA GeForce 6600, ATI Radeon 9500 ou chipset Intel 945. Quanto conexo com

internet exige no mnimo Cabo ou DSL.


22

Figura 5 Projeto VITA no Second Life (UTAD)

[Fonte: http://vitaproject.blogspot.pt/]

Figura 6 - Medicina no Second Life

Fonte: http://www.healthquotessite.com/blogs/permalinks/11-2007/health-loves-a-second-life.php

4.1.4 OpenSimulator

Tal como foi dito anteriormente, o OpenSimulator (OpenSimulator, 2012a)

surgiu por retroengenharia do Second Life e comeou-se a desenvolver-se mais

rapidamente aps a Linden Lab ter tornado pblico o protocolo SLGOGP de
http://www.healthquotessite.com/blogs/permalinks/11-2007/health-loves-a-second-life.php


23

comunicao entre servidores SL Grid e o software cliente SL, destacando-se do SL por

ser uma plataforma de cdigo-fonte aberto.

Tal como o SL, o OpenSimulator possibilita a criao de contedo em tempo real

e de forma imersiva, atravs de ferramentas prprias, possibilitando tambm a partilha

de texto, imagens, vdeo, etc., sendo que a sua comunicao tambm pode ser realizada

atravs de mensagens escritas. (OpenSimulator, 2012b)

Por ser mais recente, o OpenSimulator ainda no um mundo virtual to robusto

como j o o SL, mas sendo de cdigo-fonte permite que sejam acrescentadas ou

corrigidas quaisquer funes.

Qualquer utilizador poder correr o servidor OpenSimulator no seu computador em

modo standalone, o que permite que o servidor seja totalmente privado.

O projeto OpenSimulator surgiu em 2007, sob a licena BSD, altura em que foi

publicado o cdigo do cliente do SL e se assistiu estabilizao da biblioteca

libopenmetaverse. Esta ltima desenvolvida em paralelo com o OpenSimulator,

fazendo com que este herde dela tipos de dados comuns e as vrias classes de suporte

(Censullo, 2009).

O principal objetivo do OpenSimulator criar um servidor 3D flexvel e modular

compatvel com o cliente SL. Assim, para a comunicao entre o cliente e o servidor foi

adotado o protocolo de alto nvel do SL, que se apoia nos protocolos de mais baixo

nvel: UDP e XML-RPC22, onde as componentes comunicam internamente atravs de

XML-RPC e REST23 (JSON24/HTTP e XML/HTTP). (OpenSimulator, 2012b)

O OpenSimulator escrito em C# e pode ser executado tanto em Windows, com a

framework .NET, como em mquinas Unix, com a framework Mono.

Uma vez que usa o protocolo do SL, o OpenSimulator pode ser usado para

simular ambientes virtuais idnticos a este, no sendo contudo um clone do SL, pois no

22 Protocolo de chamada de procedimento remoto (CPR) que utiliza XML para codificar suas chamadas e HTTP como um mecanismo de transporte 23 Tcnica de engenharia de software para sistemas hipermdia distribudos como a World Wide Web 24 http://www.json.org/


24

tem suporte para muitos dos recursos especficos deste ltimo mas no enquanto

prosseguem outras direes inovadoras de forma a se tornar o esqueleto da Web 3D.

Nesta direo participam um grande nmero de colaboradores que trabalham quer

na deteo e correo de erros, quer no desenvolvimento (Pereira et al., 2010), tornando

o OpenSimulator a cada dia mais estvel, no entanto a sua verso ainda alfa, apesar de

se aproximar da verso 1.0.

Um dos caminhos que o OpenSimulator optou e que divergem do modo como o

SL est implementado, a maneira como so armazenados todos os dados. Enquanto no

OpenSimulator toda a informao armazenada numa base de dados, no SL utilizado

um servidor de ficheiros que gere toda a informao, sendo que isto em ambos os

mundos transparente para o software cliente (Sequeira, 2009).

Entre muitos outros projetos realizados no OpenSimulator pela UTAD, encontra-

se o projecto Young Europeans for Democracy25 (Figura 7). Este projeto teve como

objetivo promover a democracia europeia nos jovens.

Figura 7 - Atividade do projeto Young Europeans for Democracy

O uso do OpenSimulator grtis e no havendo financiamento para este projeto,

tal torna-se uma mais-valia.

25 http://yed.utad.pt/


25

Os requisitos mnimos para correr o OpenSimulator so os mesmos que so

descritos no Second Life, excetuando a conexo. O servidor do OpenSimulator pode ser

alojado pelo cliente, sendo que a largura de banda depende de onde for alojado.

5 Desenvolvimento do prottipo

5.1 Modelo Seguindo os requisitos descritos no captulo 5, as TO nem sempre so seguidas na

ntegra. Desta forma as tarefas do processo de instalao do motor na fuselagem da

aeronave F-16 podem sofrer alteraes.

Para combater este constrangimento optou-se pela construo de uma arquitetura

onde se separasse o sistema de controlo e deciso do sistema de visualizao. Para esta

arquitetura foi implementada uma mquina de estados hierrquica.

A nossa implementao da mquina de estados hierrquica para o treino de

instalao de motores Pratt&Whitney F100 em aeronaves F-16 tem como objetivos

principais (1) garantir a independncia dos mecanismos de coordenao e interao que

esto disponveis no espao virtual 3D, assegurando a separao entre a interface

grfica e o sistema de deciso; (2) permitir que sejam adicionadas mudanas no

processo de instalao do motor na aeronave, mudanas que podem ser introduzidas

tanto pelo fabricante como pelos formadores (introduo de um erro propositado); (3)

ser multiplataforma, definio de um modelo que seja aplicvel no s em

OpenSimulator, mas como em vrios outros mundos virtuais.

A arquitetura de estados foi ento desenhada para corresponder seguinte

sequncia: quando um objeto solicitado (recebe um clique), este comunica ao sistema

de deciso a sua solicitao, este vai consultar a sua base de dados a fim de saber qual o

estado atual do sistema e tomar uma deciso, aps essa tomada de deciso ir enviar

uma mensagem com uma resposta sobre o que o objeto que anteriormente o solicitou

dever fazer, como podemos observar na Figura 8.


26

Figura 8. - Arquitetura de estados genrica (Fonseca et al., 2011)

As aplicaes servidoras tm o poder de trabalhar com outras aplicaes em

tempo real, sendo designadas por prestadores de servios. Um servio especificado

por um conjunto de operaes disponveis para determinadas aplicaes, que descrevem

uma determinada ao ou um conjunto de aes que podem ser executadas. As

operaes de servios podem ser classificadas em quatro categorias: pedido, indicao,

resposta e confirmao (Tanenbaum, 1996).

Para modelar estas aplicaes recorreu-se a mquinas de estados hierrquicas,

onde uma aplicao requer um conjunto sequencial de aes em que uma determinada

ao depende do estado atual da aplicao.

Uma mquina de estados hierrquica qualquer dispositivo que armazena todos

os estados de um sistema num dado momento e capaz de alterar um estado podendo

causar uma determinada ao de entrada ou sada para uma determinada aplicao ou

para a sua base de dados. Segundo Xin et al. (2007), uma mquina de estados

hierrquica deve conter os seguintes elementos:

Um conjunto de estados hierrquico;

Um conjunto de eventos de entrada;

Um conjunto de eventos de sada;

Um conjunto de aes que permita a entrada de inputs no mapa de estados

(Estados de transio)


27

5.2 Desenvolvimento do prottipo inicial

5.2.1 Anlise e Especificao

Aps realizada a anlise de requisitos descrita no captulo 5, procedeu-se anlise

das TO, filmagem de todo o processo e conversas informais com os mecnicos da

BA5.

Do cruzamento destes dados produziu-se um guio de instalao do motor da

fuselagem de um F-16(Pinto & Teixeira, 2010b).

Neste guio so descritos trinta e trs tarefas necessrias para completar todo o

processo de instalao do motor na fuselagem da aeronave F-16.

Cada uma destas tarefas foi analisada e especificada pela equipa de projeto nessa

etapa. Foram criados diagramas de casos de uso , de estados , de atividades e de classes,

para cada uma das tarefas. Nas Figura 9,Figura 10, e Figura 11 so representados os

despectivos diagramas de uma tarefa especfica, a elevao do motor.

Figura 9. Diagrama de casos de uso para a tarefa "Elevar Motor"


28

Figura 10. Diagrama de estados para a tarefa "Elevar Motor"

Figura 11. Diagrama de classes para a tarefa "Elevar Motor"

5.2.2 Modelao 3D

Como mencionado no captulo 5 referente aos requisitos, pretende-se que os

formandos se sintam familiarizados com a simulao existente e com o ambiente que

vo encontrar.

Para cumprir este requisito foi modelado todo o ambiente 3D parecido com o que

se encontra na BA5. Foi modelado um hangar (Figura 12) idntico ao que se pode

encontrar. Alm de objetos essenciais a toda a simulao foram modelados alguns

objetos que podem ser encontrados no local como por exemplo extintores (Figura 13),

sistemas de incndio, escadas de acesso aeronave (Figura 14), etc.


29

Figura 12. Ambiente 3D Hangar

Figura 13. Ambiente 3D Extintor


30

Figura 14. Ambiente 3D - Escadas de acesso aeronave

5.2.3 Protocolo de Comunicao entre OpenSimulator e Web Service

Como foi descrito no captulo 8, foi nosso objetivo garantir a independncia dos

mecanismos de coordenao e interao que esto disponveis no espao virtual 3D,

assegurando a separao entre a interface grfica e o sistema de deciso.

Para integrar as duas plataformas foram criados os seguintes protocolos de

comunicao:

WebService OpenSim; (Tabela 2)

OpenSim WebService (Tabela 3 e Tabela 4), onde vamos ter dois tipos

diferentes de protocolo (um para quando um objeto criado no ambiente 3D

e outro para os restantes eventos);

OpenSim OpenSim. (Tabela 5)

Tabela 2. Protocolo de comunicao WebService OpenSim

Parmetro Tipo Funo

Parmetro 1 Nmero

Inteiro

Corresponde ao nmero de

tarefas que o WebService

envia como resposta

Parmetro 2 Nmero

Inteiro

Corresponde uma tarefa

a realizar, ex: 1-Falar, 2-

Mover

Parmetro 3 Nmero

Inteiro

Corresponde ao nmero de

parmetros que a tarefa vai

ter

Parmetro 4, 5,, n String Corresponde aos


31

parmetros especficos de

uma determinada tarefa

Tabela 3. Protocolo de comunicao OpenSim WebService (Objecto Criado)

Parmetro Tipo Funo

Parmetro 1 String Corresponde nome do

evento que aconteceu,

neste caso Objcriado

Parmetro 2 String Corresponde ao nome do objeto

Parmetro 3 String Contm a key deste objeto

Parmetro 4 String Contm a posio deste objeto, ou seja, as suas

coordenadas

Parmetro 5 String Contm a rotao deste objeto

Tabela 4. Protocolo de comunicao OpenSim WebService

Parmetro Tipo Funo

Parmetro 1 String Corresponde nome do

evento que aconteceu, ex:

tocado, attached

Parmetro 2 String Contm a key deste

objeto

Parmetro 3 String Contm a key do avatar

ou objeto que interagiu

com este

Parmetro 4 String Contm a nova posio

deste objeto, ou seja, as

suas coordenadas

Parmetro 5 String Contm a nova rotao

deste objeto

Tabela 5. Protocolo de comunicao OpenSim OpenSim

Parmetro Tipo Funo

Parmetro 1 Nmero Inteiro Corresponde nmero do

canal pelo qual vamos

comunicar

Parmetro 2 String Contm a key do objeto

que est a comunicar

Parmetro 3 Nmero Inteiro Corresponde um Evento

a realizar, ex: 1-Falar, 2-

Mover, 3-Escrever

Parmetro 4 String Contm a informao a

enviar, ex: se o evento for


32

mudar dever conter as

coordenadas que o objeto

dever assumir

Atravs destes protocolos foi implementado um script nico no OpenSimulator

em LSL, capaz de processar qualquer que seja a resposta dada pelo webservice quando

este solicitado.

5.2.4 Prottipo

A ltima fase deste desenvolvimento foi a implementao de um prottipo

experimental.

Este prottipo simulava todas as tarefas at insero do motor na fuselagem da

aeronave F-16. Foi apresentado na BA5 em Julho de 2011.

Este prottipo demonstrava algumas limitaes assim com alguns erros de

implementao. As ferramentas usadas pelos avatares aps anexadas no podiam ser

desanexadas, os mecnicos teriam de seguir todos a mesma sequncia (no processo real

no) e a sequncia de tarefas no processo de instalao do motor estava incorreto.

5.3 Desenvolvimento do prottipo final Perante o objetivo mencionado no capitulo 2, aumentar o conjunto de tarefas

simuladas no processo de instalao do motor na fuselagem, e face ao conhecimento

aprofundado que possua acerca do estado de desenvolvimento do simulador, pretendi

tambm reformular o sistema de controlo e deciso, para tornar mais gil a

implementao de correes futuras e com a ambio de poder lev-lo a ser uma base

de partida mais flexvel para outros problemas de simulao.

5.3.1 Ambiente 3D

No trabalho que serviu de base a esta dissertao, j continha uma primeira verso

de um prottipo experimental do simulador.

Tendo estado presente e colaborado na produo deste prottipo tinha conscincia

que a plataforma usada, o OpenSimulator, tinha algumas limitaes na implementao

do prottipo tal como este foi idealizado.

Durante o processo de instalao do motor na fuselagem necessrio que os

mecnicos usem determinadas ferramentas para a realizao de determinadas tarefas. A


33

simulao deste processo era realizada atravs da anexao das ferramentas 3D nas

mos do avatar (Figura 15).

Figura 15. Avatares com ferramentas anexadas s mos

Para que esse processo fosse controlado pelo sistema de controlo e deciso, a

anexao teria de ser realizada via scripting e no atravs dos controlos fornecidos pelo

software cliente (como se pode observar na Figura 16).

Figura 16. Controlos fornecidos pelo software cliente

Este processo continha limitaes, pois o uso de ferramentas vai variando ao

longo do processo de instalao e o OpenSimulator no permite de forma fivel

desanexar de objetos via scripting. O comando de scripting para o fazer existe, mas o

servidor OpenSimulator no o executa.


34

Para corrigir esta limitao optou-se pelo uso de dois heads-up diplays (HUD),

um para representar a mo direita e o outro para representar a mo esquerda (Figura 17).

Sempre que o utilizador clicar numa ferramenta aparece no HUD uma imagem

elucidativa da ferramenta que aparentemente teria anexado ao seu avatar. Esta

abordagem facilmente complementada com a anexao do objeto ao avatar assim que

aparea uma nova verso do OpenSimulator com esta limitao corrigida.

Figura 17. HUD que representa as mos direita e esquerda

Durante a simulao da elevao do motor, na primeira verso do prottipo eram

usadas duas teclas do teclado para fazer elevar e baixar o motor e uma terceira tecla para

ordenar a paragem do processo. Para o utilizador puder usar o teclado, necessrio que

o utilizador d permisses. Para dar permisses, o utilizador teria de as aceitar clicando

em OK numa mensagem que o software cliente envia (Figura 18). Todos estes

processos eram constrangedores para o utilizador. Para evitar este constrangimento

optou-se pela mudana da interface do processo. Em vez do uso do teclado, optou-se

pelo uso de mais um HUD em forma de setas (Figura 19). Desta forma, todo o processo

funcional do simulador funcionaria apenas atravs de cliques do rato e com uma

interface mais transparente.


35

Figura 18. Requisio de permisses para usar o teclado

Figura 19. HUD em forma de setas

O processo de instalao do motor na fuselagem exige a colocao de material na

aeronave. Esse material, normalmente, est situado em cima de uma bancada e os

mecnicos vo colocando medida que vo precisando. Esse processo tambm no

estava transparente no primeiro prottipo. As peas estaria colocadas num stio

estratgico e escondidas, programadas para aparecerem quando fossem solicitadas.

Quando o utilizador executava a tarefa que encaixar uma dessas determinadas peas, a

pea reagia deslocando-se para o local correto usando o mtodo de deslocao

(llSetPos). Essa deslocao era visvel a olho nu pelo utilizador dando uma ideia de

movimento. Tornava-se pouco real este procedimento. Para corrigir este processo

optou-se por usar um mtodo existente na linguagem de scripting, mtodo este que faria


36

a pea aparecer o sitio correto sem dar a ideia de que estava em movimento

(llRezObject).

Aps corrigidos estas limitaes e constrangimentos, acrescentou-se mais tarefas

no processo. O primeiro prottipo simulava as tarefas realizadas at a insero do motor

na fuselagem, este segundo prottipo simula alm das anteriores, as tarefas de segurana

do motor na fuselagem e remoo do carrinho e material de apoio insero do motor.

5.3.2 Reformulao do sistema de controlo e deciso

O sistema de controlo e deciso que serviu de base a esta dissertao possua

algumas limitaes para o avano deste projeto.

Todo o sistema de controlo e deciso est baseado, como descrido no captulo 8,

num sistema de estados hierrquico. Este sistema, que apenas permite uma sequncia de

estados, ou seja, estava desenhado para o sistema seguir apenas um nico caminho.

At ao prottipo criado, isto no era um constrangimento, pois at esta fase os

mecnicos tm todos de realizar as tarefas em equipa e em coordenao pois no

poderiam realizar a tarefa seguinte sem a anterior estar concluda, sendo a tarefa anterior

sua ou de um colega de equipa. Mas a partir desta fase, os trs mecnicos seguem

caminhos diferentes, tm de respeitar apenas a sua sequncia de tarefas e no esto

dependentes que o colega termine as suas.

nesta fase que o sistema estava limitado, tanto a nvel de organizao como de

base de dados.

Para resolver esta limitao foi criada uma nova base de dados capaz de organizar

e armazenar informao de diferentes sequncias e no apenas para este processo. A

base de dados foi desenvolvida em Microsoft SQL Server.

A Figura 20 representa o diagrama E-R que apresenta a estrutura definida para base

de dados do trabalho base enquanto a Figura 21 representa o diagrama E-R que apresenta

a estrutura definida para base de dados do projeto a que se destina esta dissertao.


37

Figura 20. Diagrama E-R da base de dados do trabalho base

Figura 21. Diagrama E-R da base de dados atual

Tal como mostra a Figura 21, foi necessria a renovao completa da base de

dados de forma a satisfazer os requisitos do sistema. Desta forma foi criada a tabela

TabelaEstados onde so guardados todos os estados necessrios para todo o processo,

tanto os estados do sistema como os estados dos avatares. A tabela Avatar substituiu a

antiga tabela Estado Avatar onde foi eliminado o atributo estado_actual. Para

relacionar os estados do avatar com a tabela de estados geral foi criada a tabela

AvatarContemEstados.


38

A tabela PostoTrabalho foi criada de modo a solucionar a limitao de os trs

mecnicos poderem seguir caminhos diferentes. Desta forma podemos criar nesta tabela

vrios postos de trabalho, ou seja, vrios caminhos por onde a simulao pode seguir

independentemente. Para relacionar estes postos de trabalho com os estados existentes

foi criado uma tabela de relacionamento PTContemEstado.

Face as mudanas do ambiente 3D descritas no subcaptulo 5.3.1, o sistema de

controlo e deciso teve tambm de ser adaptado. As classes inerentes a estas tarefas

tiveram de ser adaptadas nova interface. Todas estas classes esto organizadas de

forma a estes procedimentos serem independentes, o que facilitou a sua adaptao.

Sempre que o sistema invocado para agir, este tem de se inteirar primeiramente

de todo o estado atual do processo de simulao. Uma que que a base de dados sofreu

alteraes, todo este mtodo teve tambm de ser adaptado.

Ao longo de todo o trabalho e aps a realizao de testes de utilizao descritos

no captulo 10, foram surgindo novos requisitos e falhas na sequncia de tarefas a

realizar (Tabela 6). Mais uma vez, devido a organizao atual do sistema de controlo e

deciso, a sua implementao foi realizada com esforo reduzido.

Tabela 6 - Novas tarefas surgidas aps o 1. teste

Tarefas a realizar no simulador

Tarefas Tempo despendido para a

realizao da tarefa Permitir elevar o motor antes de deslocar

o carrinho

15 Min. (anlise, implementao e teste)

Cavilha metida no motor e no na calha 15 Min. (anlise, implementao e teste)

Implementar a sequncia: aliviar apoio,

prender sapata, prender apoio


No permitir que o motor passe a

aeronave


Alavanca tem de avanar com o motor 25 Min. (anlise, implementao e teste)

Prender apoio superior ao adapter 20 Min. (anlise, implementao e teste)


39

6 Testes Durante este projeto foram realizados dois testes ao prottipo do simulador, na

BA5 com os mecnicos especializados no processo de instalao de um motor com a

inteno de avaliar os conhecimentos dos utilizadores a nvel informtico e a nvel do

prottipo desenvolvido e aferir possveis erros no estado atual do mesmo. Estes testes

de utilizao revelaram-se bastante produtivos pois conseguimos atempadamente detetar

falhas na instalao e erros informticos, assim como perceber o que poderia ser

melhorado para que no final o sistema seja do agrado de todos os intervenientes.

Para estes testes foram construdos os seguintes instrumentos:

Questionrio de caracterizao de perfil26;

Termo de consentimento27;

Entrevista28.

O questionrio de caracterizao de perfil foi elaborado caracterizao dos

mecnicos, aferir o conhecimento dos utilizadores em mundos virtuais e experincias

prvias neste tipo de ambientes.

Uma vez que a recolha de dados seria realizada com recurso a diferentes tcnicas

e instrumentos de recolha, nomeadamente filmagem, entrevista e questionrio, criou-se

um termo de consentimento onde se pedia a autorizao para a captura, anlise e

utilizao dos dados, no mbito do protocolo elaborado entre a UTAD e FAP. Pode-se

observar com maios detalhe no anexo 1, os questionrios e no anexo 2 o termo de

consentimento.

A entrevista enquadrava-se na recolha de dados realizada durante os testes de

utilizao ao simulador 3D do processo de instalao de motores Pratt&Whitney F100

em aeronaves F-16 visando avaliar a satisfao dos utilizadores na utilizao do mesmo,

atravs de diversos aspetos, na tica do utilizador que caracterizam o simulador e outros

mais direcionados para os aspetos pedaggicos que vo de encontro ao objetivo

primordial deste simulador: a formao.

26 Ver Anexo 1. 27 Ver Anexo 2. 28 Ver Anexo 3.


40

Alm de testes pedaggicos foram realizados tambm testes tcnicos, de modo a

averiguar quais os equipamentos disponveis na BA5 para a utilizao do prottipo

produzido e se esses mesmos materiais so suficientes para a operacionalizao do

simulador de formao.

Para a realizao dos testes foram necessrios os seguintes equipamentos:

4 computadores;

1 router com um mnimo de 4 portas;

4 cabos de rede;

1 videoprojector;

6.1 Teste de utilizao 1 O 1. teste foi realizado durante os dias 1 e 2 de maro de 2012.

Para o efeito realizaram-se duas simulaes com seis mecnicos especialistas

divididos em grupos de trs elementos. Os elementos de cada grupo estavam dispostos

numa mesa quadrada, sem que cada um conseguisse visualizar o ecr dos outros.( Figura

22)

Figura 22. Primeiro teste de utilizao na BA5

Dissertao de Mestrado em Engenharia Infor

Implementação de um Sistema de Formação para Mecânicos da Força Aérea Portuguesa

Documents

Transcript of Implementação de um Sistema de Formação para Mecânicos da Força Aérea Portuguesa