InfoBUS anyWhere - Aplicação móvel para consulta de ... · de apoio à utilização de...

InfoBUS anyWhere - Aplicação móvel para consulta detransportes públicos

André Filipe Ramos Levita

Dissertação para obtenção do Grau de Mestre em

Engenharia Informática e de Computadores

JúriPresidente: Prof. Doutor José Manuel Nunes Salvador TriboletOrientador: Prof. Doutor Ricardo Jorge Feliciano Lopes PereiraCo-orientador: Doutor António Brandão LealVogais: Prof. Doutor Alexandre Paulo Lourenço Francisco

Novembro 2012

Agradecimentos

Quero agradecer ao meu orientador, Professor Ricardo Pereira, por toda a sua orientação, apoio

e disponibilidade prestados durante este último ano. Ao meu co-orientador da Tecmic, Professor

António Brandão Leal, e aos colaboradores da empresa Ricardo Ramos, Luís Pedro, Ricardo

Pedro e João Ribeiro pelo apoio prestado no enquadramento dos produtos da Tecmic e na

utilização de novas tecnologias.

Quero agradecer também à minha família pelo apoio emocional e financeiro prestado não só

durante o desenvolvimento da tese de mestrado mas também durante a realização do curso.

Por fim quero agradecer aos meus amigos que me acompanharam durante a realização da tese,

com um agradecimento em especial aos meus colegas Marta Santos e Diogo Morgado.

i

Abstract

InfoBUS anyWhere extends the Tecmic product XTraN Passenger designed for real-time monito-

ring of a public transportation fleet activity. InfoBUS anyWhere presents the information stored in

XTraN Passenger to a mobile environment. Users can access arrival time prediction of transports

or any kind of information regarding stations, schedules or transport lines. The developed sys-

tem also provides an automated process for planning a trip using only the public transportation

network. This process uses arrival time prediction of transports and some preferences specified

by the user for determine the most suitable plan. Users can then execute the trip plan in the

mobile application and be notified about the plans details and events.

Keywords: public transports, mobility, XTran Passenger, trip planning

iii

Resumo

O produto desenvolvido pela Tecmic, denominado por XTraN Passenger, é um sistema orientado

para a gestão inteligente de frotas, acompanhando em tempo real a atividade de uma frota de

transportes públicos. O XTraN Passenger agrega também informação relativa a paragens, linhas

de transporte, horários e previsões de chegada em tempo real dos autocarros às paragens. No

entanto, toda a informação gerida apenas é acessível através da Web, servindo pedidos sem

noção do contexto do utilizador.

O objetivo deste trabalho é disponibilizar toda a informação em ambiente móvel através do de-

senvolvimento de uma aplicação móvel nativa, que usufrua de funcionalidades do dispositivo mó-

vel, como a sua localização. O sistema desenvolvido, que dá pelo nome de InfoBUS anyWhere,

fará parte da plataforma XTraN Passenger, sendo integrado como um módulo adicional.

É também objetivo deste trabalho, automatizar o processo de planear uma viagem utilizando

a rede de transportes públicos e disponibilizar tal funcionalidade na aplicação móvel. O com-

ponente responsável pela determinação dos planos de viagem, denominado por Simulador de

Viagem, contemplará informação em tempo real, como os atrasos dos autocarros, e outras prefe-

rências do utilizador. Após a obtenção de um plano de viagem na aplicação móvel, esta permitirá

o acompanhamento em tempo real da execução do plano. Notificando o utilizador de diversos

eventos como a chegada do respetivo autocarro à paragem.

Keywords: transportes públicos, mobilidade, XTran Passenger, planeamento de viagem

v

Conteúdo

Agradecimentos i

Abstract iii

Resumo v

1 Introdução 1

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Conceitos Fundamentais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.2 Tecmic - XTraN Passenger . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Trabalho Relacionado 7

2.1 Advanced Public Transportation Systems(APTS) . . . . . . . . . . . . . . . . . . . 7

2.2 Simuladores de viagem nos APTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Algoritmos e modelos de dados do simulador de viagem . . . . . . . . . . . . . . . 15

2.4 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Arquitetura 23

3.1 Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

vii

3.2 XTraN Passenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.2 Servidor de Estimativa de Tempos . . . . . . . . . . . . . . . . . . . . . . . 26

3.3 Componentes do Sistema InfoBUS anyWhere . . . . . . . . . . . . . . . . . . . . . 27

3.3.1 Simulador de Viagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.2 Servidor InfoBUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.3 Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Implementação 35

4.1 XTraN Passenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.1 PassengerDAL(Domain Access Layer) . . . . . . . . . . . . . . . . . . . . . 35

4.1.2 Servidor de Estimativa de Tempos . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Simulador de Viagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.1 Estrutura de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.2 Camada de Apresentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.3 Camada Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.4 Algoritmo dos Melhores Planos de Viagem . . . . . . . . . . . . . . . . . . 40

4.3 Servidor InfoBUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.1 Camada de Apresentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.2 Camada Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4 Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4.1 Estrutura de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4.2 Menus de Interação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5 Avaliação 53

5.1 Algoritmo do Simulador de Viagem . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.1.1 Tempo de Inicialização e Análise dos Dados . . . . . . . . . . . . . . . . . 54

5.1.2 Pedidos ao Simulador de Viagem . . . . . . . . . . . . . . . . . . . . . . . . 54

viii

5.1.3 Planos de Viagem Detalhados . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.4 Conjugação de Resultados com o Servidor de Estimativa de Tempos . . . 57

5.2 Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.1 Testes de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.2 Duração Pedido-Resposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.3 Acompanhamento de Viagem . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6 Conclusão 65

6.1 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Bibliography 69

Appendix 73

A Imagens da Aplicação Móvel 73

B Resultado dos Testes 83

ix

Lista de Tabelas

2.1 Sumário de sistemas Advanced Public Transportation Systems (APTS) com simu-

lador de viagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Sumário dos algoritmos para o simulador de viagem . . . . . . . . . . . . . . . . . 21

5.3 Construção das estruturas de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 55

xi

Lista de Figuras

2.1 MyBus - Estimativas de tempos[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 TAD - Interface da aplicação do dispositivo móvel [2] . . . . . . . . . . . . . . . . . 9

2.3 OneBusAway - Interface da aplicação do dispositivo móvel[3] . . . . . . . . . . . . 12

2.4 PATH2Go - Interface da aplicação do dispositivo móvel[4] . . . . . . . . . . . . . . 14

3.5 Casos de uso - Utilizador do aplicação móvel . . . . . . . . . . . . . . . . . . . . . 25

3.6 XTraN Passenger - Modelo de dados relacional . . . . . . . . . . . . . . . . . . . . 27

3.7 Arquitetura de alto nível . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.8 Arquitetura de lado servidor: Servidor InfoBUS e Simulador de Viagem . . . . . . 30

3.9 Arquitetura da aplicação móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.10 Diagrama de sequência - Interação entre componentes . . . . . . . . . . . . . . . 33

4.11 Estrutura de Dados - Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . 37

4.12 Controladores - Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.13 Estrutura de Dados - Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . 47

4.14 Acompanhamento de Viagem - Máquina de estados . . . . . . . . . . . . . . . . . 52

5.15 Máquina de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.16 100 Pedidos ao Simulador de Viagem . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.17 Resultados dos Testes de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.18 Resultados da Duração Pedido-Resposta . . . . . . . . . . . . . . . . . . . . . . . 61

5.19 Teste do acompanhamento de viagem . . . . . . . . . . . . . . . . . . . . . . . . . 63

A.20 Imagens da Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74


xiii







B.28 Resultados detalhados do Simulador de Viagem (Dados de entrada e 1º plano) . . 84

B.29 Resultados detalhados do Simulador de Viagem (2º e 3º plano) . . . . . . . . . . . 85

xiv

Lista de Acrónimos

API Application Programming Interface

APTS Advanced Public Transportation Systems

ATIS Advanced Traveler Information Systems

AVL Automatic Vehicle Location

FIFO First In First Out

FMS Fleet Management Systems

GIS Geographic Information System

GPS Global Positioning System

GTFS General Transit Feed Specification

HTTP Hypertext Transfer Protocol

JSON JavaScript Object Notation

ORM Object-Relational Mapping

PDA Personal Digital Assistant

REST Representational State Transfer

SOAP Simple Object Access Protocol

SQL Structured Query Language

TAD Travel Assistent Device

URI Uniform Resource Identifier

WAP Wireless Application Protocol

WML Wireless Markup Language

WWW World Wide Web

xv

Capítulo 1

Introdução

1.1 Motivação

A utilização em massa dos transportes públicos em detrimento do transporte através do automó-

vel pessoal, permite uma redução em termos de congestionamento, consumo de combustível e

emissão de gases poluentes [5, 6]. Contudo, tais factos não superam a relutância de uma

parte da população em efetuar a transição em completo para o sistema de transportes públi-

cos, muito devido à complexidade do sistema ou à falta de informação necessária. Por outro

lado, utilizadores regulares dos transportes públicos são confrontados com determinados pro-

blemas provenientes da utilização do sistema. Algumas das agências responsáveis por gerir e

disponibilizar toda a informação do seu negócio, não conseguem abranger todas as paragens

ou lugares críticos de passagem com a informação necessária para qualquer utilizador. Além

disso, a disponibilização da informação em tempo real relativa a atrasos ou cancelamento de

carreiras, encontra-se apenas em sítios estratégicos e de grande tráfego. Esta é disponibilizado

através do uso de painéis eletrónicos, tornando-se assim, economicamente dispendiosa para

abranger todos as paragens e locais de negócio. Ao existir um incumprimento parcial dos horá-

rios definidos para os transportes públicos, surge a necessidade de alertar os seus utilizadores,

independentemente da paragem ou lugar em que se encontram. A utilização da informação em

tempo real poderá traduzir-se numa redução de tempos de espera ou na consideração de alter-

nativas mais rápidas.

Muitos utilizadores são confrontados com a necessidade de se deslocarem entre pontos geográ-

ficos com recurso aos transportes públicos. A tarefa de planear uma viagem deste tipo poderá

tornar-se complicada e demorada devido ao leque de opções existentes e da necessidade de

1

2 CAPÍTULO 1. INTRODUÇÃO

consultar toda a informação relevante. A complexidade do plano aumenta quando é necessá-

rio envolver o uso de mais do que uma linha de transporte. Assim, a consulta de informação

relativa a paragens, pontos de transbordo entre carreiras e horários para traçar um plano de

viagem, traduz-se num processo difícil e com a possibilidade dos resultados serem inadequados

ou pouco eficientes em termos de tempo ou custo total. Para mais, não é possível contemplar

os atrasos em tempo real dos transportes públicos incluídos no plano de viagem traçado.

1.2 Enquadramento

Nesta secção é apresentado o sistema atual de gestão e monitorização dos transportes públicos

desenvolvido pela Tecmic1, o XTraN Passenger. Para compreender este sistema é necessário

introduzir alguns conceitos fundamentais e as técnicas mais usadas nos sistemas de informação

de apoio à utilização de transportes públicos.

1.2.1 Conceitos Fundamentais

Para desenvolver um sistema de informação geográfica Geographic Information System (GIS)

que permita modelar todo o negócio de um sistema de transportes públicos, é necessário recor-

rer ao uso de tecnologias dos sistemas APTS[7, 8]. O principal propósito destas tecnologias é

providenciar aos utilizadores uma quantidade superior de informação, com maior facilidade de

acesso, relativa à rede de transportes públicos. Entre outras categorias dos sistemas APTS,

destacam-se duas:

• Advanced Traveler Information Systems (ATIS): Utilização de tecnologias de informação

para fornecer informações dos transportes públicos aos utilizadores em casa, no trabalho,

na beira da estrada, no próprio transporte, nas paragens, etc. Os utilizadores podem ace-

der em tempo real a horários e informações de congestionamento através de telefones,

painéis de mensagem variável, quiosques ou através da World Wide Web (WWW). O prin-

cipal objetivo é providenciar informação mais completa e de diversas formas para que os

utilizadores, habituais ou ocasionais, possam escolher de forma apoiada o seu transporte.

• Fleet Management Systems (FMS): Gestão e controlo da frota em tempo real recorrendo

ao uso de tecnologias de informação. A tecnologia mais usada para os transportes públicos

é o Automatic Vehicle Location (AVL). Este sistema é constituído por vários terminais a

bordo de cada veículo, que permitem a medição em tempo real da posição utilizado o

1http://www.tecmic.pt (Acedido em Agosto 2012)

1.2. ENQUADRAMENTO 3

sistema Global Positioning System (GPS). Posteriormente, essa informação é transmitida

para um sistema central.

Devido à grande evolução tecnológica que possibilitou o uso de dispositivos móveis como fer-

ramentas para o acesso à Internet e com capacidades de realizar tarefas com alguma carga

computacional, é agora possível aceder a estes sistemas de informação num contexto móvel.

A grande vantagem da utilização de dispositivos móveis, para além da sua mobilidade, advém

da utilização do GPS para identificar a posição do utilizador [9]. Desta forma, o contexto do

utilizador é transmitido para o sistema central facilitando a eliminação de informação irrelevante.

1.2.2 Tecmic - XTraN Passenger

A Tecmic é uma empresa Portuguesa fundada em 1988 que tem como principal objetivo o desen-

volvimento de soluções para a gestão inteligente de frotas. O XTraN Passenger é uma solução

completa e poderosa que permite acompanhar em tempo real toda a atividade da frota de trans-

porte públicos, comunicar por voz e dados com o tripulante, determinar e comunicar a previsão

de chegada dos próximos autocarros às paragens assim como informar o utilizador dos transpor-

tes públicos sobre tempos de espera através de diversos canais. O sistema XTraN Passenger

recorre ao uso de tecnologias FMS como o AVL para obter a localização da sua frota e também

a tecnologias ATIS para providenciar informação da sua frota aos utilizadores sobre diversos

canais.

O XTraN Passenger é constituído por uma plataforma modular da qual fazem parte os seguintes

módulos: Informer, uma plataforma multi-canal que fornece informação de previsões de che-

gada de forma precisa e em tempo real aos passageiros através de mensagens SMS, painéis

eletrónicos ou da WWW; Counter, um sistema inteligente de contagem de passageiros que

utiliza uma inovadora tecnologia de monitorização de movimentos; Eco-driver, que permite o

controlo de eficiência energética da condução tendo em vista a redução do consumo de com-

bustível e o aumento do conforto e segurança dos passageiros; e Infotainer, que providencia

informação dinâmica a bordo do transporte relativa ao serviço, fornecendo entretenimento e

publicidade baseada na localização.

4 CAPÍTULO 1. INTRODUÇÃO

1.3 Objetivos

É necessário um sistema que informe os utilizadores da rede de transportes públicos, em am-

biente móvel, de toda a informação gerida pela empresa Tecmic relativa a paragens, linhas de

transporte, transportes em movimento, horários, atrasos e previsões de chegada dos transpor-

tes às paragens. Para o âmbito deste projeto, apenas serão utilizados os dados colecionados

e geridos para zona do Chapecó, Santa Catarina - Brasil. No entanto deverá ser incorporada

a extensibilidade para outras agências colaboradores da Tecmic como a Carris - Transportes

Públicos de Lisboa1. Este sistema deverá ser incorporado no módulo XTraN Passenger.

Todo o processo para determinar um plano de viagem deverá ser automatizado, apresentando

ao utilizador em ambiente móvel, diversas alternativas para a sua deslocação entre um ponto de

origem e um ponto de destino. Deverão ser considerados dois tipos de deslocação, pedestre e

de autocarro, mas deverá ser incorporada a extensibilidade para outros tipos. Cada plano obtido,

deverá ser constituído por um conjunto de paragens e transportes a utilizar. Para o cálculo dos

planos de viagem, deverão ser considerados fatores como o tempo de viagem, o número de

transbordos e a distância pedestre realizada.

Após a obtenção de um plano de viagem, deverá ser possível um acompanhamento de viagem

em tempo real do mesmo. A aplicação notificará o utilizador, para cada instante, da ocorrência

de eventos como a sua chegada ou a de um autocarro à respetiva paragem pertencente ao plano

de viagem. Deverá também ser apresentada a informação da próxima carreira ou a paragem a

utilizar.

1.4 Solução

A solução apresentada contempla o desenvolvimento do Sistema InfoBUS anyWhere constituído

por três componentes:

• Simulador de Viagem: Responsável pela determinação de planos de viagem que per-

mitam a deslocação do utilizador entre dois pontos geográficos e sob um conjunto de

preferências e restrições.

• Servidor InfoBUS: Disponibiliza toda a informação referente ao XTraN Passenger e ao

Simulador de Viagem.

1http://www.carris.pt (Acedido em Agosto 2012)

1.5. ESTRUTURA DA DISSERTAÇÃO 5

• Aplicação móvel: Desenvolvida para o uso em dispositivos móveis. Permite a apresen-

tação gráfica de toda a informação gerida pela Tecmic em ambiente móvel. Responsável

pela funcionalidade do acompanhamento de viagem em tempo real.

1.5 Estrutura da Dissertação

Este documento contém a pesquisa, implementação e avaliação do sistema InfoBUS anyWhere

no âmbito da Dissertação de Mestrado. Este encontra-se estruturado da seguinte forma:

• Capítulo 2: apresenta o trabalho relacionado na área

• Capítulo 3: apresenta a análise de requisitos e o desenho da arquitetura

• Capítulo 4: apresenta as tecnologias e os detalhes de implementação para cada um dos

componentes desenvolvidos

• Capítulo 5: apresenta a avaliação ao sistema

• Capítulo 6: apresenta as conclusões e o trabalho futuro

Capítulo 2

Trabalho Relacionado

O trabalho relacionado encontra-se dividido em 3 secções. Na primeira secção serão apresenta-

dos alguns sistemas APTS seguindo uma abordagem cronológica. A segunda secção contempla

a introdução de simuladores de viagem nestes sistemas de informação. A abordagem do tra-

balho relacionado será assente numa perspetiva dos dispositivos móveis devido ao âmbito do

trabalho a realizar. Por fim, serão apresentados algoritmos de procura para a obtenção de pos-

síveis planos de viagem considerando fatores como o tempo ou a distância. As duas últimas

secções serão concluídas com uma tabela comparativa entre as diferentes soluções.

2.1 Advanced Public Transportation Systems(APTS)

O Busview [10] é o primeiro sistema universalmente disponível através da WWW que providen-

cia o acesso à localização geográfica de autocarros e a um conjunto de informação relativa aos

mesmos. Através desta aplicação, que pode ser transferida da WWW para ser executada lo-

calmente, os utilizadores podem visualizar a posição dos autocarros num mapa e seguir o seu

progresso com a opção de ser notificado da chegada do autocarro a uma determinada localiza-

ção. Adicionalmente, os utilizadores podem localizar o seu autocarro através da especificação

da linha de transporte ou das paragens abrangentes. Como complemento deste sistema e face

ao interesse em disponibilizar aos utilizadores tempos estimados para a partida ou chegada de

autocarros, foi desenvolvido a aplicação MyBus [1], essencialmente composta por uma interface

de acesso Web. Contudo, tal informação seria bastante mais usável se pudesse ser acedida por

um dispositivo móvel de forma a notificar um utilizador que se encontre, por exemplo, à espera

do seu autocarro.

7

8 CAPÍTULO 2. TRABALHO RELACIONADO

Para o desenvolvimento desta extensão do sistema, foi usado o protocolo Wireless Applica-

tion Protocol (WAP) e a linguagem Wireless Markup Language (WML) como mecanismos para

a entrega e apresentação de informação no dispositivo móvel. Esta extensão, vista como um

subsistema, é constituída pelo dispositivo móvel, pelo WAP Gateway e um servidor Web. O Ga-

teway comunica com o dispositivo móvel através de WAP e WML, traduzindo os seus pedidos

para o servidor Web usando Hypertext Transfer Protocol (HTTP). No dispositivo móvel, a inter-

face gráfica para o utilizador requer a introdução de identificadores únicos dos autocarros ou

paragens, para que seja processado o pedido com a informação desejada. O desconhecimento

do contexto do utilizador, isto é, a sua localização exata, torna este método desconfortável para

o utilizador pois requer a memorização destes identificadores. Para mais, estes não correspon-

dem normalmente a mapeamentos diretos com o nome da paragem ou do autocarro.

Figura 2.1: MyBus - Estimativas de tempos[1]

Apesar das limitações impostas pela rede de acesso e da tecnologia existente, especialmente

nos dispositivos móveis desta altura (2002), o MyBus disponibiliza funcionalidades ao utilizador

que permitem obter previsões de chegada da rede de autocarros (interface representada na Fi-

gura 2.1). Este sistema poderá ser considerado como um ponto de partida para todo o trabalho

desenvolvido nesta área.

Barbeau et al. e Patterson et al. apresentam sistemas com o intuito de ajudar a deslocação

de utilizadores com necessidades especiais na rede de transportes públicos [2, 11]. Estes uti-

lizadores, devido a deficiências físicas ou mentais, sofrem o risco de se perderem ao saírem

numa paragem errada ou de apanharem o autocarro errado durante um determinado percurso.

2.1. ADVANCED PUBLIC TRANSPORTATION SYSTEMS(APTS) 9

A solução para este problema, passa pela utilização de uma aplicação móvel presente no tele-

móvel de cada utilizador. Esta aplicação, através do conhecimento exato da posição do utilizador

e dos autocarros, consegue informar o utilizador se este se encontra no caminho correto. Adici-

onalmente, é possível avisar o utilizador da iminência da chegada a uma paragem que ele deva

utilizar. Esta notificação poderá ser complementada com a fotografia da respetiva paragem para

uma maior facilidade no seu reconhecimento. As restantes informações, como o aviso de atraso

ou chegada do respetivo autocarro, também serão apresentadas ao utilizador.

O sistema Travel Assistent Device (TAD) [2], apresentado por Barbeau et al., contempla três com-

ponentes essenciais: a aplicação presente no telemóvel do utilizador denominada precisamente

de TAD (representado na Figura 2.2), o servidor de informação relativa à rede de transportes

públicos e uma aplicação Web. Através da aplicação Web, é possível que um segundo utiliza-

dor possa controlar e monitorizar o trajeto efetuado pelo utilizador do TAD. Desta forma, não

existe a obrigação de acompanha-lo fisicamente no seu percurso. O TAD, apesar de ter sido

desenvolvido para utilizadores com necessidades especiais, poderá ser utilizado por qualquer

utilizador. Este sistema tem como base a utilização do contexto do utilizador como principal re-

curso para as suas funcionalidades, contudo, apenas é possível utilizar o TAD para efetuar rotas

pré-estabelecidas, limitando assim a sua utilização.

Figura 2.2: TAD - Interface da aplicação do dispositivo móvel [2]

Existem aplicações desenvolvidas com o intuito de proporcionar informação e serviços a todo o

tipo de utilizadores que frequenta a rede de transportes públicos. O sistema apresentado por

Joo-Yen et al. permite o acesso à informação da rede de autocarros em Seoul, Coreia do Sul[12].

Todos os serviços são acedidos através de uma interface gráfica simples e de fácil utilização. As

principais funcionalidades presentes no sistema são:

• Visualização da posição atual do utilizador e das paragens de autocarro que estão perto


da sua posição.

• Pesquisa de linha de autocarro ou de paragens de autocarro através do nome ou identi-

ficador do mesmo. Sendo possível aceder posteriormente a um conjunto de informação

relacionada com paragem ou a linha do autocarro como por exemplo, hora do próximo

autocarro ou conjunto de paragens associadas a uma linha de autocarro.

• Visualização do mapa à volta da respetiva paragem possibilitando uma maior facilidade no

seu reconhecimento.

• Permitir guardar um estado do utilizador com as paragens ou linhas de autocarro preferidas

ou mais utilizadas.

O sistema é constituído pelo dispositivo móvel, correspondente neste caso a um Personal Digital

Assistant (PDA), um servidor que disponibiliza a aplicação e um servidor de base de dados.

A grande desvantagem deste sistema reflete-se no facto de ser necessário transferir todos os

dados do servidor de base de dados para o PDA para poderem ser efetuadas as funcionalidades

descritas. Tal facto poderá ser bastante preocupante tendo em consideração dois aspetos: a

memória disponível nos dispositivos móveis que na maior parte dos casos é bastante limitada;

tempo de transferência ou atualização dos dados entre os diferentes componentes. O sistema

torna-se assim pouco escalável.

2.2 Simuladores de viagem nos APTS

A motivação para a inclusão de simuladores de viagem advém das necessidades dos utilizado-

res em se deslocarem de forma rápida e eficiente de um ponto para outro. A tarefa de planear

uma viagem poderá tornar-se complicada e demorada devido ao leque de opções existentes e

da necessidade de consultar a informação necessária. De tal forma, a existência de um sistema

automatizado que resolva este problema permite ao utilizar achar planos de viagens num me-

nor espaço de tempo e com a informação correta. Normalmente, este tipo de simuladores são

associados à utilização do automóvel pessoal como meio de transporte. Nesta secção serão

apresentados simuladores de viagem dos sistemas APTS, ou seja, sistemas em que o meio de

deslocação associado são os transportes públicos.

O sistema OneBusAway [3] permite o acesso à informação da rede de transportes públicos

e disponibiliza um simulador de viagem de forma a ajudar o utilizador a deslocar-se para o seu

destino. Este sistema apresenta semelhanças ao XTraN Passenger desenvolvido pela Tecmic

2.2. SIMULADORES DE VIAGEM NOS APTS 11

em termos de serviços disponibilizados ao utilizador. No entanto, o seu desenho apresenta al-

gumas diferenças pois a informação respeitante aos transportes públicos não está localizada no

domínio do sistema. Assim, existe a necessidade de aceder a serviços externos como o General

Transit Feed Specification (GTFS)1 que disponibilizem a informação pretendida. As funcionali-

dades do OneBusAway são as seguintes:

• Visualização de mapas: mapas que contêm informação de paragens, linhas de transporte

e posições dos transporte.

• Acesso a informação da rede de transportes: informação em tempo real do cumpri-

mento de horários, permitindo a consulta dos respetivos atrasos. Desta forma, o utilizador

fica com uma perceção do tempo que tem de esperar, se ainda tem tempo para apanhar

o transporte ou se simplesmente o perdeu. Esta informação poderá ser acedida através

de três interfaces: chamada telefónica, mensagem de texto SMS ou interface Web. Todos

estes fatores contribuem para um aumento na satisfação do utilizador, reduzindo o tempo

de espera nas paragens pelo respetivo transporte [13].

• Serviço de alertas: informar o utilizador do acontecimento de incidentes temporários

como acidentes rodoviários, condições atmosféricas adversas, deterioramento de estra-

das ou alteração temporária de rotas, paragens e horários.

• Simulador de viagem: os utilizadores poderão utilizar um serviço que através de um

ponto de origem e um ponto de destino, são apresentadas as possíveis rotas que per-

mitem a deslocação entre esses pontos. Adicionalmente, o utilizador pode especificar

algumas preferências para a viagem como por exemplo, a distância máxima a percorrer,

número de transferências ou distância máxima percorrida a pé. O simulador de viagem

permite também uma alternativa para especificar o ponto de destino referindo por exemplo

a intenção de visitar um restaurante, parque ou biblioteca. O sistema calcula os possíveis

pontos de interesse apresentando o plano de viagem associado.

O OneBusAway pode ser acedido através das interfaces especificadas anteriormente e através

de aplicações móveis nativas como Nokia e iPhone (interface representada na Figura 2.3). Con-

tudo, o uso de um dispositivo móvel traz os maiores benefícios devido ao âmbito da utilização do

sistema. A informação relevante é obtida mais facilmente devido ao conhecimento do contexto

do utilizador, proporcionando uma melhoria nos serviços disponíveis.

1http://code.google.com (Acedido em Agosto 2012)


(a) Localização de paragens e autocarros (b) Tempos de espera

Figura 2.3: OneBusAway - Interface da aplicação do dispositivo móvel[3]

O estudo realizado sobre a utilização do sistema OneBusAway [14, 15] na área de Seattle dos

Estados Unidos da América, demonstra que a informação em tempo real da chegada de trans-

portes e de outros serviços apresentados anteriormente, aumentam consideravelmente a usabi-

lidade do sistema de transportes públicos. Os utilizadores revelam que conseguem gerir melhor

o seu tempo considerando que as funcionalidades no sistema se adequam às suas necessida-

des. O estudo apresentado revela também comparações entre a utilização de aplicações que

usam o contexto do utilizador para determinar a sua posição, como é o caso das aplicações

nativas iPhone, e outras que usam métodos como a especificação da posição através do mapa.

Os resultados revelam que o uso do contexto do utilizador apresenta os melhores tempos de

resposta da aplicação. Destaca-se igualmente a elevada percentagem de utilizadores, cerca de

93%, que reportou passar menos tempo à espera do seu transporte e que, na maior parte dos

casos, considera mais vantajoso mudar para uma paragem alternativa com base na informação

do OneBusAway. Os resultados do estudo realizado apresentam vantagens da utilização de um

dispositivo móvel. No entanto, há que ter em consideração o reduzido número de utilizadores

em que o estudo foi realizado, cerca de 15.

O sistema ENOSIS [16] insere-se no mesmo âmbito que o OneBusAway, no entanto apresenta

algumas funcionalidades suplementares. Através de conclusões de estudos realizados, o sis-

tema integra a funcionalidade de acompanhar o utilizador ao longo dum plano de viagem obtido

pelo simulador, alertando-o de eventuais alterações inesperadas ou da previsão de tempos de

2.2. SIMULADORES DE VIAGEM NOS APTS 13

partida. Contudo, esta funcionalidade não tem conhecimento automático da posição exata do

utilizador nem se ele se encontra efetivamente a executar o plano, é necessário que o utilizador

providencie este tipo de informação. O simulador de viagens, para além de incorporar diversos

meios de transporte, possibilita o planeamento de viagens de longa distância. O ENOSIS pode

ser acedido pela WWW, e-mail e através do dispositivo móvel por mensagens de voz e SMS.

Contrariamente ao OneBusAway, não existe nenhuma aplicação nativa móvel levando assim ao

não aproveitamento do contexto do utilizador.

O PATH2Go [4] é um sistema de informação multi-modal dos transportes públicos com especial

foco no seu simulador de viagem. Através do acesso a dados de entidades externas, é possí-

vel integrar informação em tempo real relativa a diferentes meios de transporte como autocarro,

comboio ou metropolitano num único sistema. Para além destes meios de transporte, é con-

templada a opção do utilizador percorrer parte do percurso com o seu carro. Os três principais

módulos do PATH2Go são:

• Sistema de informação de trânsito: pesquisa de linhas de transporte, paragens ou infor-

mação em tempo real.

• Simulador de viagem multi-modal: usando informação em tempo real e dados geográfi-

cos, são calculados os planos de viagem adequados considerando um conjunto de prefe-

rências do utilizador. É possível também a comparação entre diferentes planos de viagem

em termos de tempos, emissões de poluentes, tempos de espera e tempos de viagem.

• Acompanhamento do plano de viagem: com base na localização do utilizador, ajudá-lo

ao longo do seu percurso.

O sistema está acessível através de uma interface Web e de uma aplicação móvel nativa iPhone

(interface representada na Figura 2.4). Para o acompanhamento do utilizador ao longo da sua

viagem, é necessário identificar qual a atividade que ele se encontra atualmente a realizar (es-

pera, deslocamento, etc.). Para tal, são aplicados algoritmos de correspondência de mapa tendo

em consideração o erro do GPS associado à localização do dispositivo móvel.

Nextbus1 e 5112 são outros sistemas que também disponibilizam simuladores de viagem restri-

tos a uma determinada área de execução. Podem ser acedidos através de interfaces Web e de

aplicações móveis. No entanto, contrariamente ao PATH2Go não incluem um simulador multi-

modal. Apenas é considerado um meio de transporte.

1http://www.nextbus.com (Acedido em Agosto 2012)2http://511.org (Acedido em Agosto 2012)


Figura 2.4: PATH2Go - Interface da aplicação do dispositivo móvel[4]

A existência de outras plataformas como o Trimet1 e o Google Transit2, que apenas disponi-

bilizam o simulador de viagem através de uma interface Web também deverá ser mencionada.

O simulador de viagem Google Transit, desenvolvido pela Google, permite obter um plano de

viagem ótimo considerando os dados submetidos em ficheiros GTFS. Dependendo da região de

viagem, poderá existir mais do que um meio de transporte. Desta forma, caso reduza o tempo

total de viagem, os planos de viagem podem estar sujeitos a transições entre diferentes tipos de

transportes conjugados com distâncias que devem ser percorridas a pé.

Os dados utilizados pelo Google Transit são estáticos e não contemplam atrasos em tempo

real. Do ponto de vista da empresa, para representar a informação de um determinado meio

de transporte, é necessário submeter um conjunto de ficheiros que definem a informação crítica

do negócio, isto é, paragens, linhas, horários, calendários, tarifas, o nome da agência adminis-

trativa, etc. Cada ficheiro deverá respeitar a estrutura do GTFS para ser aceite e incorporado

no sistema. Desta forma, o Google Transit está ao alcance de todas os países e zonas com

transportes públicos, bastando para isso a submissão dos ficheiros GTFS que representam o

funcionamento de cada agência. Já o Trimet apenas disponibiliza serviços para área de Por-

tland, Estados Unidos da América. Contudo, ambos os sistemas incorporam vários meios de

transporte para a determinação dos planos de viagem.

1http://trimet.org (Acedido em Agosto 2012)2http://www.google.com/transit (Acedido em Agosto 2012)

2.3. ALGORITMOS E MODELOS DE DADOS DO SIMULADOR DE VIAGEM 15

Na Tabela 2.1 encontram-se resumidos os diferentes sistemas apresentados nesta secção. Es-

tes serão classificados de acordo com as interfaces de acesso, tipos de informação, funcionali-

dades, meios de transporte do simulador de viagem e âmbito de execução.

2.3 Algoritmos e modelos de dados do simulador de viagem

Qualquer simulador de viagem necessita de um algoritmo para calcular quais as possíveis rotas

que satisfaçam o pedido do utilizador. Para além dos algoritmos típicos de caminho mais curto,

existe a necessidade de introduzir outros fatores que devem influenciar o cálculo da rota. No

âmbito deste sistema, fará sentido ter em conta fatores como o custo total do percurso, o tempo

necessário para executar o percurso, o número de transições de transportes públicos durante

uma viagem ou a distância percorrida a pé. Como suporte ao algoritmo é necessário existir um

modelo de dados onde possa ser extraída a informação relevante para a sua execução.

Chao-Lin Liu et al. propõem um algoritmo com o objetivo de determinar possíveis rotas que per-

mitam a ligação entre dois pontos [17]. A motivação para o seu algoritmo, assenta no facto de os

utilizadores tipicamente preferirem planos de viagem que necessitam de menos transições entre

linhas de transporte, dado que o custo e o tempo aumentam com este tipo de transições. Assim,

o algoritmo de procura opera ao nível das linhas de transporte e não de pontos de paragens.

Os pontos de transição são representados por um conjunto de paragens que podem incorporar

vários modos de transporte. São considerados 3 algoritmos para solucionar o problema:

• Matrizes de adjacências[18]: utilização de matrizes quadradas para representar a conec-

tividade entre vários pontos. As linhas e colunas são indexadas pelo nome do ponto de

transição e o valor da posiçãoMi,j da matriz M é atribuído pelo número de caminhos dire-

tos entre i e j. Demonstrado por indução, a matriz M elevada a n denota a quantidade de

ligações entre os vários pontos considerando n transições. Desta forma, é possível achar

o percurso que permite a deslocação entre dois pontos considerando o menor número de

transições. No entanto, este algoritmo exige um poder computacional elevado, tornando-se

insuficiente para a resolução do problema.

• Matrizes de conectividade: com base no conceito das matrizes de adjacências, as ma-

trizes de conectividade permitem a representação da conectividade entre as linhas de

transporte. As linhas e as colunas são indexadas pela linha de transporte e o valor da


Sistem

aInterfaces

deacesso

Tipode

informação

FuncionalidadesM

eiosde

transportedo

simulador

Âm

bitogeográ-

fico

OneB

usAw

ay[3]W

eb,S

MS

,A

plica-ções

iPhone

eA

n-droid

Dinâm

ica-

tempo

realS

imuladorde

viagem;M

apascom

loca-lização

detransportes;S

erviçode

aler-tas;P

revisõesem

tempo

real

Transportespúblicos,pe-

destreS

eattle,EU

A

EN

OS

IS[16]

Web,

E-m

ail,S

MS

echam

adastelefóni-

cas

Dinâm

ica-

tempo

realS

imulador

deviagem

comescala

mundialconsiderando

deslocaçõesem

aviãoou

barco;A

companham

entodo

planode

viagem

Transportespúblicos

Mundial

PATH2G

o[4]W

ebe

aplicaçãoiP

honeD

inâmica

-tem

poreal

Sim

uladordeviagem

;Mapas

comloca-

lizaçãode

transportes;Serviço

dealer-

tas;Previsões

emtem

poreal;A

compa-

nhamento

doplano

deviagem

Transportepessoal,

transportespúblicos,

pedestre

São

Francisco,E

UA

Nextbus

Web,

SM

S,

Aplica-

çõesiP

hone,Android

eB

lackberries

Dinâm

ica-

tempo

realM

apascom

localizaçãode

transpor-tes;

Serviço

dealertas;

Previsões

emtem

poreal


Washington

DC

,S

ãoFrancisco,

Toronto,etc.511

Web,S

MS

Dinâm

ica-

tempo

realS

imulador

deviagem

;M

apascom

lo-calização

detransportes;P

revisõesem

tempo

real


São

Francisco,E

UA

Trimet

Web,S

MS

Dinâm

ica-

tempo

realS

imuladorde

viagem;M

apascom

loca-lização

detransportes;S

erviçode

aler-tas;P

revisõesem

tempo

real


Portland,EU

A

Google

TransitW

ebE

státicaS

imulador

deviagem

comextensibili-

dadepara

ainclusão

deoutras

agên-cias

atravésde

GTFS

Transportepessoal,

transportespúblicos,

pedestre

Mundial

comtransporte

regio-nal

Tabela2.1:

Sum

áriode

sistemas

AP

TScom

simuladorde

viagem


posição Ti,j da matriz T é atribuído pelo número de paragens em comum entre i e j. Res-

peitando as propriedades das matrizes de adjacências, a matriz T elevada a n denota o

número de paragens em comum considerando n transições. Contudo, a informação repre-

sentada pelas matrizes revela resultados enganadores. Existem restrições que não são

representadas, como a direção da linha de transporte, apenas aplicando este algoritmo. É

necessário juntar algumas condicionantes de implementação para que sejam apresenta-

dos os resultados corretos.

• Algoritmo de planeamento: Com a ajuda das matrizes de conectividade e outras fun-

ções de conectividade de rotas, o algoritmo apresentado apenas considera no máximo

três transferências. Caso a origem e o destino sejam servidos pela mesma linha de trans-

porte, apenas existe a necessidade de verificar se a linha tem o sentido origem-destino.

Caso seja necessário recorrer a dois ou mais pontos de transição, obtido através da matriz

Tn, é necessário verificar a localização dos pontos de transição e se efetivamente existe a

possibilidade de realizar essas transições devido ao sentido da linha de transporte.

O algoritmo apresentado é completo e ótimo para o cálculo do rotas considerando o menor nú-

mero de transferências. No entanto, e apesar de ser referido como uma possível extensão ao

sistema, a aplicação não contempla no seu algoritmo outros fatores como o tempo ou o custo

para determinar os percursos. Por outro lado, como alternativa e adicionando um complemento

ao sistema, foi incorporada a utilização de pontos de transição especiais denominados de “pon-

tos de agregação”. Estes pontos representam uma forte concentração de linhas de transporte,

superior a quinze linhas, tipicamente representando estações multi-modais e são utilizados como

pontos preferenciais para ser efetuada uma transição. Considerando esta implementação, o al-

goritmo mantém-se completo mas não se revela ótimo.

Ao considerar o tempo real como principal fator para a obtenção de um plano de viagem, como

é o caso do algoritmo apresentado por Jeral Jariyasunant [19], surge outro tipo de problema.

Devido à necessidade de aceder à informação de tempos e rotas através de serviços externos,

não é sustentável obter todos os dados de uma só vez para cada pedido do utilizador. Nestas

condições, a duração entre pedido-resposta está sujeita a um grande atraso. A solução passa

por realizar uma pré-computação da informação necessária em duas fases. Na primeira fase

são obtidos os dados de rotas, paragens e localizações através dos ficheiros GTFS da Goo-

gle. Seguidamente é realizado um mapeamento entre as paragens e um serviço externo onde

seja possível obter informação em tempo real das linhas de transporte. Na segunda fase são

construídas três tabelas de procura: tabela de geolocalização onde é armazenada a latitude e a


longitude de cada paragem; tabela de serviços que contempla os horários e períodos de funcio-

namento de todas as linhas de transporte; tabela de caminhos em que são consideradas todas

as paragens como possível origem e são calculadas todas as paragens destino com o máximo

de quatro transições efetuadas. Para os pontos de transição são consideradas paragens de

cruzamento de linhas de transporte e paragens com uma reduzida deslocação pedestre entre

elas. Com esta pré-computação realizada, qualquer pedido do utilizador é traduzido no seguinte

procedimento:

1. Determinar a paragem mais próxima do utilizador através da tabela de geolocalização .

2. Obter através da tabela de caminhos, todos os caminhos possíveis que possibilitem a

deslocação da paragem mais próxima para o destino.

3. Remover caminhos irrelevantes através da tabela de serviços.

4. Obter a informação de tempo real associada a cada paragem e apresentar os cinco resul-

tados com tempos inferiores.

A avaliação do algoritmo revelou resultados positivos com uma média de tempos inferior a três

segundos entre o pedido e a resposta do utilizador. A escalabilidade do sistema revela um au-

mento de ordem polinomial em termos de espaço para a tabela de procura de caminhos. O

algoritmo não é ótimo pois pode excluir paragens no passo 1 que corresponderiam a um cami-

nho mais curto.

Tendo em consideração os vários tipos de transporte existentes, Joel Booth et al. apresentam

um simulador de viagens assente num modelo de dados em grafo onde é possível especificar

os meios de transporte que o utilizador deseja utilizar [20]. Para além de serem considerados

diferentes meios de viagem (automóvel, pedestre, comboio ou metropolitano), existe ainda a

possibilidade de condicionar o plano de viagem através de restrições físicas como a exclusão de

rotas com pontes ou ruas específicas, restrições temporais como a duração máxima da viagem

e restrições que incluam certas instalações ou serviços como bancos e restaurantes na rota

traçada.

O modelo de dados é definido pelo tuplo U = (M,F,L,G) em que: M é o conjunto de meios de

transporte, F o conjunto de instalações ou serviços, L o conjunto de atributos e G um multi-grafo

rotulado e dirigido. Por sua vez, G = (V,E,Ψ) em que V representa os vértices, E os arcos

e Ψ uma função de mapeamento de atributos. Os vértices são pontos geográficos escolhidos

em conformidade com a proximidade de uma instalação, um serviço ou uma paragem de uma

linha de transporte. Os arcos correspondem a linhas dos vários meios de transporte entre os


diferentes vértices.

Baseado em linguagens espaço-temporais[21], a construção da base de dados em grafo é reali-

zada através da declaração de predicados descrevendo os vários componentes descritos ante-

riormente e as suas relações. Consequentemente, o sistema de interrogação à base de dados é

baseado na estrutura da linguagem SQL permitindo assim a obtenção dos planos de viagem de-

sejados. A interrogação a executar poderá conter várias restrições como o meio de transporte,

instalações a parar ou o tempo máximo para realizar a viagem acompanhado de um grau de

probabilidade. Caso o utilizador pretenda minimizar o tempo da viagem, é usada uma versão do

algoritmo de Dijkstra[22] adaptada a um multi-grafo para obter o caminho mais curto.

Zang e Cai propõem um algoritmo dinâmico de caminho mais curto com o objetivo primário

de minimizar o tempo de viagem e como segundo objetivo, minimizar o número de transferên-

cias entre linhas de transporte[23]. Devido ao aumento do ritmo de vida, a grande maioria das

pessoas considera o tempo como o fator principal para a obtenção de um plano de viagem apro-

priado.

O modelo de dados deste sistema é constituído por um grafo onde é representada a rede de

trânsito. De forma a simplificar a rede, paragens que se encontrem separadas por curtas dis-

tâncias são agregadas num único nó. Arcos entre os diferentes nós correspondem a secções

de estrada que permitem a sua ligação. Assim, cada arco poderá estar associado a diferentes

linhas de transporte. Para cada plano, o tempo total da viagem é dado por:

t = twalk + tv + ti + twait + tprice

Onde twalk corresponde ao tempo de deslocação pedestre da origem para a paragem e da pa-

ragem do destino para o destino, tv ao tempo de deslocação no transporte público, ti ao tempo

de transferência entre transportes ou tempo na deslocação pedestre entre paragens, twait ao

tempo de espera pelo transporte e tprice corresponde a uma transformação do preço total da

viagem em tempo. Cada um destes tempos é calculado tendo em consideração fatores que

influenciam diretamente o seu valor. O algoritmo apresentado é ótimo e baseia-se no algoritmo

de Dijkstra[22], no entanto, devido à consideração de tempos complementares como ti ou tprice,

apresenta resultados diferentes para os mesmos dados de entrada.

Li et al. apresentam um simulador de viagem incorporando igualmente vários meios de trans-

porte e informação em tempo real[24]. Para além dos tradicionais meios de transporte, é acres-

centada a possibilidade do utilizador deixar o seu carro num determinado parque de estacio-

namento e posteriormente seguir num transporte público. O desenho do simulador de viagem


permite satisfazer as preferências de diferentes utilizadores apresentando sempre um conjunto

de planos como resposta. Tal necessidade deve-se ao facto de os utilizadores terem opiniões

diferentes sobre como preferem realizar o percurso da origem ao destino. Exemplificando, um

utilizador pode preferir deslocar-se um pouco mais a pé enquanto que outro pode preferir aguar-

dar na paragem.

Para calcular quais os possíveis planos de viagem, o problema é partido em três subproblemas

de caminho mais curto: da origem para paragens ou parques de estacionamento; do destino

para paragens mais próximas; e das paragens ou parques de estacionamento que estão mais

perto da origem para paragens que estão mais perto do destino. Para os dois primeiros, é con-

siderada a aplicação do algoritmo bi-direcional de Dijkstra[22]. Para o terceiro subproblema,

são adaptados os algoritmos GOR1[25] e o algoritmo de Jiminez e Marzal[26] para obter os

caminhos mais curtos considerando a minimização do tempo de viagem como fator principal.

O modelo de dados utilizado é caracterizado por uma rede de trânsito onde existem diferentes

tipos de nós (paragens, parques de estacionamento e pontos de transição) e arcos entre os nós

com atributos temporais que são atualizados periodicamente.

Na Tabela 2.2 encontram-se resumidos os diferentes algoritmos apresentados nesta secção.

Estes serão classificados de acordo com os algoritmos que usam no seu processo, fatores con-

siderados pela sua execução e o modelo de dados utilizado.

2.4 Conclusões

O PATH2Go e o OneBusAway apresentados na secção 2.2 revelam-se os sistemas mais com-

pletos e aproximados ao XTraN Passenger contemplando o uso de aplicações nativas para dis-

positivos móveis. As funcionalidades destas aplicações aproximam estes sistema ao propósito

da aplicação InfoBUS. Para mais, a aplicação móvel do PATH2Go permite o acompanhamento

do utilizador durante um plano de viagem.

Em relação aos algoritmos apresentados na secção 2.3, o proposto por Joel Booth et al.[20]

revela-se o mais abrangente podendo incorporar diversas preferências do utilizador na determi-

nação do plano. Contudo, o uso dos algoritmos baseados em Dijsktra, apresentados por Zang

e Cai[23] ou Li et al.[24], podem satisfazer o pedido da maioria dos utilizadores sem necessitar

de um sistema tão complexo. A ideia apresentada por Jeral Jariyasunant et al.[19] envolve uma

pré-computação dos dados para reduzir tempos de resposta e será utilizada no sistema InfoBUS

anyWhere.

2.4. CONCLUSÕES 21

Aut

ores

Alg

oritm

osFa

ctor

esem

cons

ider

ação

Mod

elos

deda

dos

Cha

o-Li

nLi

uet

al.[1

7]B

asea

doem

mat

rizes

deco

nect

ivid

ade[

18]

Núm

ero

detra

nsiç

ões

Não

espe

cific

ado

Jera

lJar

iyas

unan

teta

l.[19

]A

lgor

itmo

espe

cial

izad

oTe

mpo

devi

agem

enú

mer

ode

tran-

siçõ

esTa

bela

sde

proc

ura

espe

cial

izad

as

Joel

Boo

thet

al.[2

0]E

spaç

o-te

mpo

rais

[21]

eD

ijkst

ra[2

2]Te

mpo

devi

agem

,núm

ero

detra

n-si

ções

,cu

sto,

mei

ode

trans

port

e,po

ntos

dein

tere

sse

Red

ede

trâns

itoem

graf

o

Zang

eC

ai[2

3]B

asea

dono

Dijk

stra

[22]

Tem

pode

viag

em,n

úmer

ode

tran-

siçõ

ese

cust

o,R

ede

detrâ

nsito

emgr

afo

Liet

al.[2

4]D

ijkst

ra[2

2],

GO

R1[

25],

Jim

inez

eM

arza

l[26]

Dis

tânc

iae

tem

poR

ede

detrâ

nsito

emgr

afo

Tabe

la2.

2:S

umár

iodo

sal

gorit

mos

para

osi

mul

ador

devi

agem

Capítulo 3

Arquitetura

Neste capítulo é apresentada a arquitetura do sistema InfoBUS. São levantados os requisi-

tos inerentes ao sistema e são descritos os seus componentes. Por fim, é apresentada a

comunicação de alto nível entre os componentes.

3.1 Análise de Requisitos

Os requisitos funcionais estão fundamentalmente concentrados na aplicação móvel porque ape-

nas neste componente irá existir interação direta com o utilizador, já os requisitos não funcionais

estarão presentes um pouco por todo o sistema. Os requisitos para o sistema InfoBUS são:

• Localização e visualização no mapa de paragens. Possibilidade de consultar informação

detalhada acerca da mesma (nome, morada, linhas de transportes que passam na para-

gem, previsões de chegada dos próximos transportes).

• Localização e visualização no mapa de transportes com atualização em tempo real do seu

estado e informação.

• Acesso a informação relativa a uma determinada linha de transporte.

• Obtenção de horários, previsões de chegada e atrasos dos transportes públicos.

• Acesso a notícias e avisos relativos aos transportes públicos.

• Simulação de viagem através da especificação de:

– Ponto de origem e de destino.

23

24 CAPÍTULO 3. ARQUITETURA

– Data de partida.

– Preferências do utilizador: percurso mais rápido ou com menos transbordos com es-

pecificação do limite máximo à deslocação pedestre.

• Duração máxima de 3 segundos entre o pedido e a resposta relativamente à simulação de

viagem.

• Plano de viagem ótimo para horários pré-estabelecidos e tendo como critério o tempo de

viagem ou o número de transbordos.

• Plano de viagem atualizado com previsões de chegada dos autocarros às paragens

• Interoperabilidade com o módulo XTraN Passenger.

• Visualização e gestão de planos de viagem agendados.

• Acompanhamento em tempo real do plano de viagem obtido pelo simulador através da

localização de transportes e paragens incluídas no plano, informação do plano, posição do

utilizador e tempos de viagem. Exibição de notificações relativas a:

– Chegada de transporte.

– Paragens de entrada e de saída a utilizar.

– Percurso a realizar no transporte público ou a caminhar.

– Chegada ao destino.

Através dos requisitos definidos, o diagrama de casos de uso representado na Figura 3.5 ilustra

todas as ações que o utilizador tem sobre a aplicação móvel. O simulador de viagem calcula os

possíveis planos e permite que o utilizador possa agendar a sua execução imediata ou a prazo.

Os planos agendados são guardados de forma persistente e podem ser geridos pelo utilizador

de forma local.

3.2 XTraN Passenger

No módulo XTraN Passenger desenvolvido pela Tecmic estão presentes todos os dados neces-

sários ao funcionamento do sistema InfoBUS, uma camada de acesso aos dados denominada

de PassengerDAL e ainda o Servidor de Estimativa de Tempos. Através do seu modelo de

dados é possível representar toda a lógica de negócio subjacente a um sistema APTS. Para

simplificar a explicação do modelo de dados e visto que o sistema InfoBUS apenas necessita

3.2. XTRAN PASSENGER 25

Figura 3.5: Casos de uso - Utilizador do aplicação móvel

de aceder a um sub-conjuntos de dados, doravante apenas será explicado e representado uma

parte do modelo de dados do XTraN Passenger, excluindo assim, detalhes e alguma lógica de

negócio que não será necessária para o sistema InfoBUS.

3.2.1 Modelo de Dados

A Figura 3.6 representa o modelo de dados relacional do XTraN Passenger. Cada linha de trans-

porte é representada pela tabela CARREIRA, onde por sua vez poderão existir variações de

rota dessa mesma linha de transporte, representadas na tabela CARREIRAVARIANTE. Por fim,

a tabela CARREIRAVARIANTESENTIDO representa a direção pela qual essas variações são

realizadas. As linhas de transportes são compostas por múltiplos troços (tabela TROCO), cada

troço corresponde a um conjunto de paragens (tabela PTPARAGEM). Estes agrupamentos são


feitos de forma a representar uma linha de transporte com um nível de granularidade superior.

Cada troço contém um conjunto de ligações entre paragens (tabela Connection). Através de

cada item desta tabela, é possível obter dados importantes, como a distância entre paragens.

Como acontece frequentemente no dia a dia, existe a possibilidade de demorar mais tempo a

realizar um percurso a uma determinada hora de um dia útil do que noutro horário. Tal lógica

está representada na tabela ConnectionTime, em que cada item desta tabela, contém informa-

ção sobre a tempo estimado para efetuar uma determinada ligação. A duração está dependente

do dia (tabela DIA), época (tabela EPOCA) e ainda das horas a que ocorre (tabela VARIANTE).

Assim, a relação entre as tabelas Connection e ConnectionTime é de um para muitos.

Os horários de serviço de cada linha de transporte estão representados na tabela Schedule,

estes estão dependentes do tipo de serviço ao qual o transporte se designa e também ao tipo

de dia e de época. Os dias são representados como dia útil, Sábado, feriado ou Domingo e

feriado especial. As épocas como escolar e não escolar. Para fazer a associação entre este tipo

de informação, é necessário recorrer à tabela SERVICOCHAPA. A tabela ED_CALENDARIO

caracteriza cada dia do ano em relação ao seu tipo e época.

O modelo de dados representado contempla ainda dados sobre os veículos (tabela VEICULO),

o seu condutor (tabela CONDUTOR) e ainda a sua atual posição representada pela tabela PO-

SICAO_E. Por fim, todas as partidas são registadas na tabela Departure.

3.2.2 Servidor de Estimativa de Tempos

O Servidor de Estimativa de Tempos tem como objetivo calcular previsões de chegada dos trans-

portes às paragens. Para tal, existem dois casos a ter em consideração: o transporte já se en-

contra em viagem ou caso contrário, ainda não iniciou a viagem. No primeiro caso, a estimativa

é feita utilizando informação da última paragem realizada, a sua posição atual e o tempo pré-

calculado para realizar a ligação entre as paragens durante aquele horário. No segundo caso, a

estimativa é feita usando o histórico das últimas viagens realizadas respeitantes a linha de trans-

porte em questão. O Servidor de Estimativa de Tempos está acessível através de serviços Web

e é essencial para sistema InfoBUS pois permite a conjugação dos resultados obtidos através

de dados estáticos com informação em tempo real relativa aos transportes públicos.

3.3. COMPONENTES DO SISTEMA INFOBUS ANYWHERE 27

Figura 3.6: XTraN Passenger - Modelo de dados relacional

3.3 Componentes do Sistema InfoBUS anyWhere

A solução contempla uma arquitetura cliente-servidor representada na Figura 3.7. Os compo-

nentes desta arquitetura poderão ser separados logicamente pela sua funcionalidade e locali-

zação: lado servidor e lado cliente. No lado do servidor será desenvolvido um módulo InfoBUS

como extensão do sistema XTraN Passenger da Tecmic. Por sua vez, o módulo InfoBUS, será

composto pelo Servidor InfoBUS e pelo Simulador de Viagem. No lado cliente existirá uma

aplicação móvel que acederá, para além do Servidor InfoBUS, a serviços externos como o re-

positório de mapas de estrada. O GPS será usado para facilitar a utilização de algumas funcio-

nalidades por parte do utilizador da aplicação móvel, sendo mesmo indispensável em algumas

atividades.

Toda a informação apresentada pela aplicação móvel será obtida através do servidor InfoBUS.


Por sua vez, este servidor comunicará com a plataforma XTraN Passenger, para obter os da-

dos necessários. Devido a limitações computacionais do dispositivo móvel, a requisitos não

funcionais e também para limitar a transferência de dados entre componentes, a execução do

simulador de viagem estará igualmente integrada no lado do servidor.

Figura 3.7: Arquitetura de alto nível

3.3.1 Simulador de Viagem

O Simulador de Viagem, representado na Figura 3.8, determina planos de viagem com base

na informação fornecida pelo utilizador, i.e., origem, destino e preferências para a determinação

do plano (plano mais rápido ou com menos transbordos e limite à deslocação pedestre). O al-

goritmo para a obtenção dos melhores planos de viagem consiste na aplicação iterativa de um

algoritmo para determinar o caminho mais curto tendo como suporte uma rede de trânsito. Cada

iteração do algoritmo considera uma rede de transito com alterações parciais da rede anterior

permitindo assim obter diferentes caminhos. De notar que os melhores planos de viagem não


correspondem ao caminhos mais curtos pois tal não se adequa ao âmbito dos transportes pú-

blicos. Considerando o seguinte exemplo: O caminho mais curto entre o ponto X e o ponto Y é

composto pelas paragens A, B, C e pela carreira 1 que realiza todas as paragens do percurso.

Existe ainda a carreira 2 que realiza unicamente as paragens B e C mas que não pertence ao

plano obtido. Ao considerar a aplicação de um algoritmo de K caminhos mais curtos, o resultado

na 2ª iteração seria o plano com a carreira 1 para realizar as paragens A e B e a carreira 2 para

realizar as paragens B e C. Tal plano não faz sentido para o utilizador visto que ele é forçado

a abandonar um autocarro que o levaria ao seu destino. Como tal, as iteração posteriores do

algoritmo irão usar redes de trânsito com a omissão de cada carreira pertencente ao plano ante-

rior. Desta forma é garantido que as alternativas para o utilizador são suficientemente diferentes,

o caso descrito neste exemplo não ocorrerá e que são obtidas as alternativas mais rápidas ao

considerar a carreira retirada.

O tempo ou número de transbordos são os critérios usados para a aplicação do algoritmo e a

rede de trânsito tem como suporte os dados fornecidos pelo XTraN Passenger. Após o cálculo

dos melhores planos de viagem, segundo as preferências especificadas e os horários estáticos,

é realizado um acesso ao Servidor de Estimativa de Tempos de forma a obter previsões de che-

gada dos transportes às paragens incluídas nestes planos de viagem. Assim, são garantidos os

melhores planos de viagem na primeira fase do algoritmo, conjugados posteriormente com infor-

mação em tempo real. Caso existam atrasos que alterem o tempo total das viagens simuladas,

é feita uma reordenação dos resultados. Em termos de arquitetura, o Simulador de Viagem está

estruturado em dois camadas:

• Camada de apresentação: desenvolvimento de uma interfaces de acesso aos serviços

disponibilizados pelo Simulador de Viagem através da Web.

• Camada lógica: pré-computação da rede de trânsito que será composta por paragens,

ligações entre paragens, linhas de transporte e pelos horários de serviço. Os dados utili-

zados para a construção da rede de trânsito estão presentes no servidor de base de dados

do XTraN Passenger. A camada lógica contempla ainda a implementação do algoritmo de

procura para obter os melhores planos de viagem e o acesso ao Servidor de Estimativa de

Tempos.

Para evitar constantes acessos ao servidor de base de dados do XTraN Passenger em cada pe-

dido ao Simulador de Viagem, a rede de trânsito é computada com a inicialização da aplicação,

mantida em memória primária de forma a diminuir tempos de acesso e apenas será atualizada

num determinado período T . A frequência de alteração ou inserção de novos dados relativos a

paragens, linhas de transporte ou horários deverá definir o período de atualização T , sendo este


valor configurável pelo administrador da aplicação. A camada de dados é omitida da arquitetura

visto que os dados usados são todos transferidos do XTraN Passenger.

Figura 3.8: Arquitetura de lado servidor: Servidor InfoBUS e Simulador de Viagem

3.3.2 Servidor InfoBUS

O Servidor InfoBUS, representado na Figura 3.8, tem como principal função servir todos os

pedidos provenientes da aplicação móvel, sem manter estado entre os mesmos. É o front end

de todo o sistema que engloba a parte do servidor e disponibiliza uma Application Programming

Interface (API) de acesso aos serviços fornecidos ora pelo módulo XTraN Passenger ora pelo

Simulador de Viagem, através da Web. Este é estruturado em duas camadas:

• Camada de apresentação: desenvolvimento de interfaces de acesso Web aos serviços

disponibilizados pelo sistema.

• Camada lógica: processamento da lógica de negócio, i.e., são decididos quais os servi-

ços a invocar dentro das infraestruturas da Tecmic. O pedido poderá requerer um acesso

ao Servidor de Estimativa de Tempos para a obter previsões de chegada dos transportes

públicos às paragens, ou poderá ser realizado um pedido ao Simulador de Viagem para


determinar uma plano de viagem. Alternativamente, poderá ser efetuado um acesso ao

servidor de base de dados do XTraN Passenger através da camada de dados Passen-

gerDB para obter informações relativas a paragens, linhas de transporte, etc.

3.3.3 Aplicação Móvel

A aplicação móvel é o único componente onde existe interação direta com o utilizador, servindo

assim os propósitos finais de todo o sistema InfoBUS. Através desta aplicação, é possível ace-

der a todas as funcionalidades descritas na secção 3.1. São apresentados os resultados finais

ao utilizador num ambiente móvel relativamente a dados do XTraN Passenger ou do Simulador

de Viagem. Grande parte dos dados obtidos são conjugados com mapas geográficos obtidos

por fontes externas, levando a uma melhor compreensão da informação por parte do utilizador.

Outro serviço essencial para este componente, vulgarmente utilizado num ambiente móvel, é a

utilização do sistema GPS. A aplicação móvel utiliza o GPS de forma a facilitar algumas funcio-

nalidades, como por exemplo a localização de paragens nas imediações. O acompanhamento

de um plano de viagem, previamente obtido pelo Simulador de Viagem, necessita obrigato-

riamente do sistema GPS para comparar a posição atual do utilizador com a rota a realizar.

Adicionalmente, são também efetuados pedidos ao Servidor InfoBUS para obter a posição atual

dos transportes pertencentes ao plano escolhido. A aplicação móvel, representado na Figura

3.9, é constituída por três camadas:

Figura 3.9: Arquitetura da aplicação móvel

• Camada de apresentação: interface gráfica para que o utilizador possa interagir com o

sistema, acedendo às suas funcionalidades e notificando-o durante o acompanhamento

de viagem.

• Camada lógica: elaboração e transmissão dos pedidos para o servidor InfoBUS, obtenção

de mapas do respetivo repositório e acesso ao sistema GPS do dispositivo móvel. Acesso


à camada inferior de dados para obter informação dos planos de viagem agendados ou

em execução. Implementação do algoritmo de acompanhamento de viagem.

• Camada de dados: acesso aos dados referentes a planos de viagem. Cada plano, após

ter sido obtido indiretamente pelo Simulador de Viagem e escolhido pelo utilizador, será

armazenado de forma persistente numa base de dados relacional.

O algoritmo de acompanhamento de viagem traduz-se numa máquina de estados onde cada

estado é referente às condições do utilizador, i.e., em espera pelo transporte, a caminhar para

a paragem ou para o destino e no transporte. Sendo que o estado final será o de chegada

ao destino. As transições entre os diversos estados correspondem a eventos como chegada

à paragem, chegada do transporte ou chegada ao destino. O acompanhamento de viagem é

apenas informativo daquilo que o utilizador deverá realizar e é executado em background.

3.4 Comunicação

Como especificado em 3.3.2, o Servidor InfoBUS disponibiliza uma API para aceder aos seus

serviços através da Web. Todos os pedidos provenientes da aplicação móvel são independentes

e realizados através de serviços Representational State Transfer (REST). Cada pedido é feito

usando unicamente o protocolo HTTP e contém toda a informação necessária para ser proces-

sado através do URI. Esta solução foi adotada de forma a aumentar a flexibilidade e interope-

rabilidade de qualquer sistema remetente. O Servidor de Estimativa de Tempos, desenvolvido

pela Tecmic e utilizado pelo sistema InfoBUS, é acedido através da invocação de WebServices.

Como tal, e por coerência às soluções implementadas, o Simulador de Viagem é igualmente

acedido via WebServices. A figura 3.10 representa a interação entre os diversos componentes

e para simplificar a sua ilustração, foram agrupados todos os pedidos referentes a informação

presente no XTraN Passenger (invocação Obter info). Assim, existem 3 tipos de invocações que

geram interações diferentes entre os componentes do lado servidor. Na invocação Obter info, é

feito um acesso ao servidor de base de dados do XTraN Passenger, são geradas vistas para os

dados obtidos e por fim, estas são retornadas à aplicação móvel. Na invocação Obter previsões,

é realizado um acesso ao Servidor de Estimativa de Tempos. Na invocação Simular viagem,

os dados são reencaminhados para o Simulador de Viagem e por sua vez, este realizará um

acesso ao Servidor de Estimativa de Tempos.

3.4. COMUNICAÇÃO 33

Figura 3.10: Diagrama de sequência - Interação entre componentes

Capítulo 4

Implementação

Neste capítulo são descritos todos os aspetos relativos à implementação dos componentes

enumerados e arquitetados no último capitulo. São apresentadas todas as linguagens,

tecnologias e bibliotecas utilizadas assim como detalhes de implementação. A escolha das tec-

nologias foi fortemente baseada nas tecnologias já utilizadas pela Tecmic na construção dos

seus produtos, em tecnologias Open Source e na experiência obtida previamente no desenvol-

vimento de Software com determinadas linguagens ou arquiteturas.

4.1 XTraN Passenger

Nesta secção são apresentados os componentes do XTraN Passenger usados na implementa-

ção do sistema InfoBUS anyWhere.

4.1.1 PassengerDAL(Domain Access Layer)

Todos os dados estão armazenados numa base de dados relacional Structured Query Lan-

guage (SQL) com recurso à ferramenta Microsoft SQL Server 2008. A camada desenvolvida pela

Tecmic que permite o acesso aos dados, utiliza uma solução Object-Relational Mapping (ORM),

o NHibernate. Esta camada de abstração, denominada por PassengerDAL, será utilizada quer

pelo Simulador de Viagem quer pelo Servidor InfoBUS para aceder aos dados presentes na

base de dados do XTraN Passenger. O PassengerDAL disponibiliza interfaces de acesso para

todos os dados necessários pelo Sistema InfoBUS.

35

36 CAPÍTULO 4. IMPLEMENTAÇÃO

4.1.2 Servidor de Estimativa de Tempos

O Servidor de Estimativa de Tempos disponibiliza uma interface de acesso Web aos seus ser-

viços. A interface é constituída por vários serviços, dos quais apenas dois são utilizados pelo

Sistema InfoBUS:

• GetEstimationByStopPoint(int numberOfEstimations, System.TimeSpan timeSpan,

string stopPointCode): obtenção de numberOfEstimations estimativas para o próximo

intervalo de tempo representado por timeSpan. Filtrado para a paragem identificada por

stopPointCode.

• GetEstimationByRouteAndStopPoint(int numberOfEstimations, System.TimeSpan ti-

meSpan, string routeCode, string stopPointCode): obtenção de numberOfEstimations

estimativas para o próximo intervalo de tempo representado por timeSpan. Filtrado para a

paragem identificada por stopPointCode e pela linha de transporte routeCode.

4.2 Simulador de Viagem

O Simulador de Viagem foi implementado com recurso à linguagem C# e à plataforma da Mi-

crosoft .NET 4.0. A escolha destas tecnologias deve-se ao facto de todos os componentes

desenvolvidos pela Tecmic usarem estas tecnologias, da possibilidade de ser prestado apoio

por membros da Tecmic (em caso de problemas ou dúvidas) e também por experiência pessoal

adquirida previamente em projetos académicos. O ambiente de desenvolvimento escolhido foi

o Microsoft Visual Studio 2010 e o servidor aplicacional embutido Visual Studio Development

Server.

4.2.1 Estrutura de Dados

Os dados utilizados para o Simulador de Viagem são construídos através de informação pre-

sente no servidor de base de dados do XTraN Passenger. Esta informação é acedida pela

camada PassengerDAL. No Simulador de Viagem, todos os acessos a esta camada estão en-

capsulados na classe PassengerDB. A estrutura de dados é traduzida no diagrama de classes

representado na figura 4.11.

A rede de transito é implementada através de um grafo onde cada vértice, representado pela

classe Vertex, constitui uma paragem e as suas principais características como a localização e

4.2. SIMULADOR DE VIAGEM 37

Figura 4.11: Estrutura de Dados - Diagrama de Classes

a sua identificação única. Os arcos do grafo por sua vez, representam ligações entre as para-

gens (representado pela classe Edge). De forma a modelar o facto de cada ligação entre duas

paragens puder ser realizada por diferentes linhas de transporte e/ou por deslocação pedestre,

cada arco é também ele constituído por um subconjunto de conexões, representado pela classe

Connection. Assim, a classe Connection poderá corresponder a uma ligação do tipo pedestre

ou de autocarro. Se a ligação for de autocarro, existe sempre a associação ao identificador da

respetiva linha de transporte. A cada vértice estão ainda associados um conjunto ordenado de

horários (classe OrderedScheduleResumed). Através da utilização de tabelas de hash, cada

horário, representado pela classe ScheduleResumed, é agrupado pela linha de transporte e

também pela hora a que se realiza.

A aplicação do algoritmo para obter os melhores planos gera objetos do tipo DetailedPathResult

que por sua vez são constituídos por um conjunto de objetos do tipo Connection. Esta primeira

classe contém ainda detalhes da viagem completa, como é o caso do número de transbordos, a

distância total, a distância total pedestre, tempo total de viagem e o tempo total de espera. Cada

objeto do tipo Connection contém tipos primitivos que apenas são preenchidos pelo algoritmo e

que detalham a distância, o tempo ou os horários de cada ligação utilizado pelo plano.


4.2.2 Camada de Apresentação

Esta camada disponibiliza a interface de acesso Web aos serviços do Simulador de Viagem.

Esta interface foi implementada exclusivamente como um WebService da plataforma .NET, não

existindo nenhum requisito para qualquer outro tipo de acesso. Assim, os serviços são identifi-

cados por um URI, descritos e definidos usando XML e acedidos através do uso dos protocolos

HTTP e Simple Object Access Protocol (SOAP). O Simulador de Viagem apenas é constituído

por um único serviço:

• SimulateTrip(TripPlannerRequest request): em que os dados necessários para a exe-

cução do simulador são descritos no objeto request do tipo TripPlannerRequest com os

seguintes tipos primitivos:

– sourceLat : latitude da origem.

– sourceLon: longitude da origem.

– destinationLat : latitude do destino.

– destinationLon: longitude do destino.

– sourceName: morada da origem.

– destinationName: morada do destino.

– time: hora e data do início da viagem.

– preference: preferência de viagem (tempo ou transbordos).

– maxPedestrianDistance: distância máxima a caminhar.

O pedido é propagado para a camada inferior onde será executado o algoritmo. Os resultados

obtidos são retornados sob a forma de uma lista de objetos do tipo DetailedPathModel.

4.2.3 Camada Lógica

O ficheiro de configuração Web.config contém a atribuição às seguintes variáveis utilizadas na

construção do grafo e na execução do algoritmo:

• ConnectionMaxPedestrianDistance: distância pedestre máxima entre duas paragens

(em metros).

• GraphUpdatePeriod: período de atualização dos dados (em minutos).

• TimeEstimatorUse: limite máximo para incluir a consulta ao servidor de estimativa de

tempos no algoritmo do Simulador de Viagem (em minutos).


• MaxPaths: limite máximo de alternativas a calcular para cada pedido.

A classe Singleton TripPlanner é o componente base e controlador de todo o processo. É ins-

tanciada com a inicialização da aplicação, sendo desde logo construído o grafo correspondente

à rede de trânsito. Este processo consiste em obter toda a informação necessária do XTraN

Passenger para construir os vértices e os arcos do grafo. Para além das ligações de autocarro já

existentes no XtraN Passenger, são adicionadas ligações do tipo pedestre entre todos os vértices

cuja distância não exceda o limite definido por ConnectionMaxPedestrianDistance. Para calcular

a distância entre duas paragens, é aplicada a distância de Manhattan, também conhecida como

Taxicab geometry1. A distância retilínea entre dois pontos geográficos não representa, na mai-

oria das vezes, a distância necessária que uma pessoa precisa de percorrer para se deslocar

entre esses dois pontos no mundo real. A distância de Manhattan apresenta uma aproximação

suficientemente realista para a simulação pretendida. São também pré-calculados todos os ho-

rários de serviço das carreiras existentes. Estes horários são posteriormente associados a cada

vértice/paragem. Toda este informação é atualizada com uma periodicidade GraphUpdatePe-

riod, i.e., é feita a reconstrução do grafo e de toda a sua informação.

Toda esta pré-computação é realizada antes de qualquer pedido proveniente da Web visto que

se trata de uma estrutura de dados independente e que servirá como recurso para a execução

do algoritmo do Simulador de Viagem. Já no âmbito do processamento de cada pedido proveni-

ente da camada de apresentação, é instanciada uma Thread da classe BestPaths responsável

por aplicar o seguinte processo:

1. Criação de vértices provisórios correspondentes ao ponto de origem e destino.

2. Criação de arcos/ligações provisórias do tipo pedestre entre o vértice origem e destino e

todos os outros vértices pertencentes ao grafo excluindo ligações superiores à distância

máxima a caminhar (maxPedestrianDistance).

3. É aplicado o algoritmo dos melhores planos de viagem entre a origem e o destino (apre-

sentado na próxima secção).

4. Caso a diferença entre a data de início da viagem e a data a que o pedido foi processado

seja inferior a TimeEstimatorUse minutos, são aplicados os seguintes passos adicionais

para cada caminho obtido (acesso ao Servidor de Estimativas de Tempo):

• Para cada ligação realizada por autocarro e na qual a linha de transporte não seja

continuação da anterior, são obtidas previsões de chegada à respetiva paragem. Para1http://wikipedia.org/wiki/Taxicab_geometry (Acedido em Agosto 2012)


cada ligação realizada por autocarro e na qual a linha de transporte seja continuação

da anterior, é simulado o tempo de chegada à paragem com base na duração da

ligação, evitando assim outro acesso ao Servidor de Estimativa de Tempos.

• São atualizados os tempos de chegada e partida para cada vértice/paragem e é veri-

ficado se o plano de viagem se mantém exequível na existência de atrasos.

• Caso existam alterações ao tempo total de viagem, é feito um reordenamento dos

melhores planos de viagem.

5. São removidos os vértices e arcos/ligações provisórios.

6. Com base nos melhores planos de viagem obtidos, são geradas e retornadas as respetivas

vistas à camada de apresentação.

4.2.4 Algoritmo dos Melhores Planos de Viagem

Foi escolhido e adaptado o algoritmo de Dijkstra para ser aplicado durante a execução deste

algoritmo com base em diferentes redes de transito. Para a execução deste algoritmo existem

duas estruturas auxiliares: RT que armazena diferentes redes de transito em forma de fila First

In First Out (FIFO) e que inicialmente é preenchida com a rede de trânsito original; MPV que

armazena os caminhos obtidos em cada iteração do algoritmo de Dijkstra. O algoritmo dos

melhores planos de viagem é constituído por um ciclo principal que é executado enquanto RT

não está vazio e o tamanho de MPV seja menor ou igual ao limite máximo de MaxPaths. Cada

iteração é descrita pelo seguinte processo:

• Aplicação do algoritmo de Dijkstra tendo como rede de transito o primeiro elemento retirado

da fila RT .

• Caso a aplicação do algoritmo de Dijkstra tenha retornado um caminho válido p, este é

guardado na estrutura MPV e são construídas n redes de transito. Cada nova rede de

transito é um ajustamento da rede utilizada pelo caminho p. São removidas todas as co-

nexões (representadas pela estrutura Connection) correspondentes a uma linha de trans-

porte utilizada durante o caminho p, i.e., não será mais utilizada essa linha de transporte

na nova rede de transito. Cada rede de transito obtida por este tarefa é adicionada à fila

RT .

Por fim, é feito uma reordenação sobre a estrutura MPV tendo como critério de ordenação a

preferência especificada pelo utilizador.


Com este processo é garantido que nas diversas iteração do ciclo principal sejam obtidos ca-

minhos consideravelmente diferentes que no limite poderão ser compostos pelas mesmas para-

gens/vértices mas nunca pelas mesmas conexões. Assim sendo, n corresponde ao número de

linhas de transporte existentes no caminho obtido pelo algoritmo de Dijkstra. Esta solução foi

adotada visto que o propósito deste algoritmo é apresentar ao utilizador alternativas compostas

por uma ou mais linhas de transporte diferentes do plano anterior, sempre ordenadas pela pre-

ferência especificada (tempo ou número de transbordos). A remoção da conexões não significa

a remoção dos arcos entre quaisquer dois vértices e desta forma, a ligação continuará a ser

exequível se existir uma outra conexão.

Em cada iteração do ciclo principal é garantido o caminho mais curto com a respetiva rede de

transito mas não são garantidos os K caminhos mais curtos no final deste algoritmo pois a modi-

ficação da rede de transito é feita ao nível das linhas de transporte e não ao nível das paragens.

Contudo, os planos apresentados não deixam de ser aproximações bastante próximas aos ca-

minhos mais curtos e apresentam, dentro do âmbito dos transportes públicos, soluções bastante

lógicas para o utilizador. Contextualizando, um utilizador dos transportes públicos ao considerar

dois planos de viagem que permitem chegar ao seu destino, não vê sentido em considerar a

alternativa ao plano principal, a execução da mesma linha de transporte mas em que se verifi-

que o seu abandono numa paragem antecipada. I.e., uma determinada linha de transporte que

possibilite uma chegada em menor tempo ao destino não deverá ser interrompida de forma a

ser considerada em diferentes planos de viagem.

4.2.4.1 Algoritmo de Dijkstra

A escolha deste algoritmo é justificada pelo facto de se tratar de um algoritmo ótimo com com-

plexidade de O(|E| + |V |log|V |) caso seja utilizada uma fila de prioridades. Para mais, este

algoritmo é considerado como o mais rápido tendo em conta a sua aplicação num grafo dirigido

com pesos de arcos positivos e origem única. De forma concisa e sucinta, o algoritmo de Dijkstra

segue sempre o caminho cuja a distância acumulada até então, seja a mais reduzida. No âmbito

desta aplicação, os arcos utilizados pelo algoritmo serão pesados de acordo com o tempo total

da viagem ou o número de transbordos ocorridos, conforme a preferência do utilizador. O peso

dos arcos apenas pode ser atribuído em tempo de execução do algoritmo pois estes estão de-

pendentes da hora de chegada à respetiva paragem/vértice e/ou da linha de transporte utilizada

anteriormente. O pseudo-código do algoritmo de Dijkstra é dado por:

1 function Dijkstra(Graph, source):

2 for each vertex v in Graph:


3 dist[v] := infinity ;

4 previous[v] := undefined ;

5 connection[v] := undefined;

6 pedestrian[v] := 0;

7 dist[source] := 0 ;

8 Q := the set of all nodes in Graph ;

9 while Q is not empty:

10 u := vertex in Q with smallest distance in dist[] ;

11 if dist[u] = infinity:

12 break ;

13 remove u from Q ;

14 for each neighbor v of u:

15 conn := best_conn_between(u, v) ;

16 alt := dist[u] + conn.dist ;

17 if alt < dist[v]:

18 dist[v] := alt ;

19 previous[v] := u ;

20 connection[v] := conn;

21 if conn = pedestrian:

22 pedestrian[v] := pedestrian[u] + conn.dist;

23 else

24 pedestrian[v] := pedestrian[u];

25 decrease-key v in Q;

A distância, representada pelo vetor dist, é dada pelo tempo total de viagem ou pelo número

de transbordos, até ao vértice/paragem em questão. A estrutura previous permite guardar qual

o vértice/paragem utilizado anteriormente. Para além destas estruturas, imprescindíveis para a

execução do algoritmo, foram acrescentadas mais dois vetores: connections e pedestrian. O

primeiro permite guardar as conexões utilizadas anteriormente e a segundo permite guardar a

distância pedestre realizada até cada vértice/paragem de forma a controlar a distância realizada

a pé pelo utilizador. Para a atribuição do vértice u na linha 10, é mantido uma estrutura ordenada

pela distância implementada através de um SortedDictionary.

Com base no horário previsto de chegada ao vértice u, a função best_conn_between(u, v) deter-

mina qual a melhor conexão que possibilita a deslocação de u para o vértice v. Independente-

mente da preferência de viagem especificada pelo utilizador, é realizado o seguinte processo:

4.3. SERVIDOR INFOBUS 43

se for possível continuar na mesma linha de transporte do que a conexão anterior, é escolhida

a conexão entre u e v que tiver essa mesma linha de transporte, evitando assim um tempo de

espera desnecessário em u. Caso contrário, é escolhida a conexão, pedestre ou de autocarro,

que possibilite o menor horário previsto de chegada ao vértice v. Para tal, é necessário aceder à

informação dos horários de transporte armazenada nas estruturas OrderedScheduleResumed.

Este processo respeita sempre o filtro de horários de acordo com o tipo de dia e a respetiva

época. Por outro lado, a escolha de uma conexão pedestre terá sempre em consideração o

valor presente na estrutura pedestrian. Caso esta variável ultrapasse o valor definido pelo utili-

zador (maxPedestrianDistance), não serão mais utilizadas conexões pedestres.

Após este processo, se não for encontrado nenhum horário ou se não for possível realizar o

respetivo arco de forma pedestre, o peso atribuído ao arco será representado por infinity.

Caso contrário, ao peso do arco será atribuído o tempo de viagem associado a essa conexão

(tempo de deslocação entre paragens mais o tempo de espera) se a preferência for o caminho

mais rápido ou um número real pertencente ao intervalo [0, 1] se a preferência for o menor nú-

mero de transbordos. O valor 1 representa a ocorrência de um transbordo e o valor 0 o caso

oposto.

4.3 Servidor InfoBUS

O Servidor InfoBUS foi implementado com recurso à linguagem C# e à plataforma para o desen-

volvimento de aplicações Web, o ASP.NET. Para separar as tarefas da aplicação, foi utilizado o

padrão de arquitetura Model View Controller (MVC) implementado pelo ASP.NET MVC. Tal como

o Simulador de Viagem, a escolha destas tecnologias deve-se às mesmas razões anteriormente

referidas. Para mais, foi possível adaptar um projeto previamente desenvolvido pela Tecmic,

cujo propósito era bastante similar ao Servidor InfoBUS. Como ambiente de desenvolvimento foi

igualmente escolhido o Microsoft Visual Studio 2010 e o servidor aplicacional embutido Visual

Studio Development Server.

4.3.1 Camada de Apresentação

Com a utilização da tecnologia ASP.NET MVC, é possível disponibilizar uma API para o acesso

Web baseado numa arquitetura REST. Os serviços são identificados por um URI e acedidos atra-

vés do protocolo HTTP. Os dados retornados são unicamente estruturados em objetos JavaScript

Object Notation (JSON). Os serviços disponibilizados estão agrupados pelo tipo de dados a que


se referem. Estes agrupamentos correspondem às seguintes interfaces URI:

• http://ServerAddress/BusStop: informação de paragens.

• http://ServerAddress/BusStopRoute: informação de paragens de uma determinada li-

nha de transporte.

• http://ServerAddress/MobileActualState: informação de transportes em movimento.

• http://ServerAddress/Route: informação de rotas.

• http://ServerAddress/RouteVariantDirection: informação de variações de rotas com o

sentido definido.

• http://ServerAddress/TimeEstimation: previsões em tempo real da chegada dos auto-

carros às paragens.

• http://ServerAddress/TripPlanner: simulação de planos de viagem.

Consequentemente, a cada URI é acrescentado uma String que correspondente à definição de

cada pedido. Por exemplo, o URI http://ServerAddress/BusStop/GetByRVD?10, corresponde

à obtenção de paragens que estejam presentes na linha de transporte identificada pelo número

10. A String GetByRVD identifica a função, com ou sem argumentos, acedida dentro da camada

lógica. Todas as funções desenvolvidas serão listadas na próxima secção.

4.3.2 Camada Lógica

A cada agrupamento identificado está associado um controlador responsável pelo processa-

mento do pedido. Cada controlador é implementado por uma classe cujo nome é uma concate-

nação do nome da interface URI com a String Controller. O diagrama de classes representado

na figura 4.12 contém todos os controladores desenvolvidos assim como a listagens de funções

que podem ser acedidas dentro de cada controlador. Com a exceção dos controladores TimeEs-

timationController e TripPlannerController, a implementação de cada função de cada controlador

limita-se a utilizar a camada de acessos aos dados do XTraN Passenger, o PassengerDAL, para

processar o pedido. No caso dos controladores TimeEstimationController e TripPlannerControl-

ler, são invocados os WebServices na aplicação correspondente. Posteriormente, são construí-

das as vistas relativas aos dados obtidos e devolvidas à camada de apresentação. As vistas

são objetos constituídos unicamente por tipos primitivos que resumem ou filtram a informação

presente em cada objeto do domínio do XTraN Passenger.

4.4. APLICAÇÃO MÓVEL 45

Figura 4.12: Controladores - Diagrama de Classes

4.4 Aplicação Móvel

A Aplicação Móvel foi desenvolvida para o sistema operacional Android e consequentemente

escrita em Java. A escolha desta tecnologia é justificada pelo seu rápido crescimento no mer-

cado, pelo facto de ser Open Source e da experiência de desenvolvimento adquirida em projetos

académicos anteriores. O ambiente de desenvolvidamente utilizado foi o Eclipse com o plugin

AVD.

A camada de apresentação é representada por uma interface gráfica definida em ficheiros XML

correspondentes aos diversos ecrãs. A lógica de negócio foi implementada com recurso a ativi-

dades e serviços fornecidos pelo sistema Android. Por fim, os dados estão armazenados numa

base de dados relacional SQLite e acedidos através duma camada desenvolvida para esse pro-

pósito. De forma a facilitar a compreensão desta secção, após uma descrição da estrutura de

dados utilizada, a implementação deste componente será explicada da seguinte forma: para

cada menu principal de interação com o utilizador, serão apresentadas as atividades/serviços

desenvolvidas, os ficheiros XML usados, imagens da aplicação e outros detalhes de implemen-

tação. Os casos de uso foram associados a diferentes menus de acordo com o seu propósito.


4.4.1 Estrutura de Dados

Todos os dados utilizados pela aplicação são reconstruções dos objetos correspondentes às

vistas retornadas em formato JSON por parte do Servidor InfoBUS reaproveitando toda a sua

lógica de dados. Os dados são assim representados pelas classes ilustradas na figura 4.13. As

classes, BusStopRouteModel e BusStopModel, modelam informação das paragens com ou sem

linha de transporte associada, respetivamente. As classes, RouteModel e RouteVariantDirecti-

onModel, contêm informação de rotas e variações de rota com sentido definido, respetivamente.

A classe TimeEstimationModel traduz as previsões de chegada dos autocarros às paragens.

Para representar o estado de um determinado transporte em movimento é utilizado a classe

MobileActualStateModel. Já as classes, DetailedPathModel e ConnectionModel, encapsulam

dados referentes ao resultado do pedido de simulação de viagem e constituem as únicas enti-

dades persistidas localmente na aplicação móvel.

Foi desenvolvida uma camada de abstração denominada e implementada na classe InfoBUS-

DAL que permite o acesso aos dados persistidos na base de dados relacional SQLite. Foram

também criados métodos para a atualização, inserção ou remoção dos dados armazenados.

4.4.2 Menus de Interação

4.4.2.1 Inicialização - Menu Principal

Com a inicialização da aplicação é lançada a atividade MainMenuGridActivity à qual está as-

sociado o ficheiro XML main_menu_grid. Em termos de interface gráfica, são apresentadas as

4 principais funcionalidades disponibilizadas pela aplicação móvel: Informação/Localização de

Transportes, Avisos e Alertas, Simulador de Viagem e Gestão/Acompanhamento de Viagem.

Adicionalmente, é instanciada a classe RestAPIClient responsável por executar todos os pedi-

dos ao Servidor InfoBUS independentemente da atividade/serviço em execução. A configuração

dos URI acedidos pela aplicação móvel, do porto e do endereço do servidor é definido no ficheiro

config.properties. A interface do menu principal está representada na figura A.20(a).

4.4.2.2 Informação/Localização de Transportes

A atividade principal responsável por esta funcionalidade é TransportInformationActivity à

qual está associado o ficheiro XML transport_info_map. O ecrã desta atividade, representado

na figura A.20(b), é inteiramente ocupado pelo mapa de estradas disponibilizado pelo Google

Maps. As opções acessíveis pela tecla menu desta atividade são: determinar e apresentar a


Figura 4.13: Estrutura de Dados - Diagrama de Classes


posição atual do utilizador no mapa após uma consulta ao sistema GPS do dispositivo móvel;

determinar as paragens nas imediações, funcionalidade ilustrada na figura A.20(c). O procedi-

mento para esta segunda funcionalidade consiste em adquirir as coordenadas geográficas de

dois cantos opostos do mapa, formalizar e enviar o pedido através do objeto RestAPIClient.

Para evitar que a área do mapa seja demasiado grande, i.e., que faça retornar um número

excessivo de paragens, a área é limitada a um determinado nível de zoom. O URI acedido

é http://ServerAddress/BusStop/GetByGeoEnvelope com os respetivas coordenadas como

argumento. As paragens retornadas são utilizadas para serem desenhadas as paragens so-

brepostas ao mapa. Qualquer outro pedido feito ao Servidor InfoBUS é análogo e não será

novamente descrito.

Para qualquer paragem que se encontre desenhada no mapa, desta atividade ou de outra poste-

riormente apresentada, é possível consultar informação detalhada da mesma. Caso seja essa a

ação executada pelo utilizador, é lançada a atividade DetailedBusStopInfoActivity associado

ao ficheiro XML tabhost_info, onde é possível consultar informação generalizada da paragem

como a sua morada, linhas de transporte que passam na paragem e as próximas previsões de

chegada dos transportes. As figuras A.21(a), A.21(b), A.21(c) e A.22(a) ilustram estas funciona-

lidades.

Alternativamente, é possível realizar uma pesquisa avançada através da atividade SearchAc-

tivity à qual está associado o ficheiro XML search_form. O utilizador tem à sua disposição os

seguintes tipos de pesquisa (interface representada na figura A.22(b)):

• Pesquisa da linha de transporte: São obtidas todas as rotas existentes através do Ser-

vidor InfoBUS, dando ao utilizador a possibilidade de selecionar a que deseja e a sua res-

petiva variação. Consequentemente, será mostrado no mapa da atividade TransportInfor-

mationActivity todas as paragens pertencentes a essa rota assim como a posição atual

dos transportes que estão a realizar essa linha de transporte (figuras A.22(c) e A.23(a)). A

posição dos transportes é atualizada periodicamente caso o utilizador assim o deseje. Tal

como cada paragem, é possível consultar informação detalhada de cada transporte (figura

A.23(b)).

• Pesquisa do local: À medida que o utilizador for escrevendo o nome do local, são apre-

sentadas diversas opções para completar o local desejado. Esta funcionalidade foi imple-

mentada com recurso aos serviços do Google Places API com acesso análogo ao Servidor

InfoBUS, i.e., é feito um acesso ao URI correspondente, sendo retornado um objeto JSON

com as sugestões para os caracteres inseridos até ao momento. Após a escolha da opção


correta, o mapa é centrado na morada correspondente.

• Pesquisa pela paragem: Assim que o utilizador concluir a sua escrita, são obtidas e

apresentadas as hipóteses válidas para os caracteres introduzidos através dum pedido

ao Servidor InfoBUS. Após a escolha da opção correta, o mapa é centrado na paragem

correspondente.

4.4.2.3 Avisos e Alertas

Esta funcionalidade não foi implementada pois a Tecmic não possui de momento nenhum com-

ponente do XTraN Passenger que disponibilize esta informação para o âmbito do sistema Info-

BUS.

4.4.2.4 Simulador de Viagem

O objetivo desta funcionalidade é permitir ao utilizador introduzir todos os dados necessários

para que possam ser calculados e apresentados consequentemente os melhores planos de

viagem. Todos os ecrãs desta funcionalidade estão ilustrados nas figuras A.23(c), A.24, A.25,

A.26 e A.27. A atividade lançada inicialmente é a TripPlannerActivity associada ao ficheiro

XML trip_planner. Os campos obrigatórios e que necessitam de ser preenchidos pelo utilizador

são:

• Origem e Destino: O ponto de origem e do destino podem ser determinados de duas

formas: pela posição atual do dispositivo móvel (através do sistema GPS); e pela es-

pecificação de um ponto no mapa. Para a segunda, é lançada uma atividade auxiliar

(SelectPlaceActivity) permitindo ao utilizador escolher diretamente no mapa de estradas,

qual a origem/destino.

• Data de partida: O utilizador poderá escolher a data atual ou especificar uma nova data

superior à data atual.

• Preferência: percurso mais rápido ou percurso com menos transbordos.

Todos os campos são validados antes de ser formalizado o pedido para o Servidor InfoBUS.

Caso a resposta contenha pelo menos um plano de viagem, os resultados são apresenta-

dos resumidamente numa nova atividade (TripPlannerResultsActivity associada ao ficheiro

trip_planner_result). O utilizador poderá executar 3 ações sobre cada plano obtido:


1. Consulta do plano detalhado com especificação dos sub-trajetos a realizar pé e de au-

tocarro, das linhas de transporte a utilizar e de todos os tempos e distâncias em cada

sub-trajeto. Para tal é lançada a atividade TripPlannerDetailedRouteActivity.

2. Visualização do plano no mapa de viagem com identificação de todas as paragens incluí-

das no plano assim como a rota realizada durante o plano através da atividade TripPlan-

nerMapRouteActivity. O plano de viagem obtido apenas contém o conjunto de todas as

paragens ordenadas, não contendo as rotas que fazem a ligação entre as mesmas. De

forma a contornar esta limitação do sistema XTraN Passenger, a ligação entre as paragens

é representada pelo melhor trajeto que permita uni-las. Contudo, pode acontecer o caso

do percurso mostrado não corresponder exatamente ao real mas face ao âmbito para que

está a ser utilizado, tal não se revela um problema visto que a representação é apenas

para o utilizador ter uma ideia por onde os transportes vão passar. Este trajeto é dado pelo

serviço do Google Maps através da formalização de um URI que encapsule o pedido. O

retorno desta invocação é um objeto JSON que será processado pela aplicação móvel.

3. Agendamento do plano de viagem através do armazenamento de forma persistente do

plano de viagem selecionado podendo ser consultado ou executado mais tarde através do

menu Gestão/Acompanhamento de Viagem. Tal ação é realizada com recurso à camada

InfoBUSDAL.

4.4.2.5 Gestão/Acompanhamento de Viagem

Neste menu é possível visualizar e gerir todos os planos de viagem controlados pela aplicação.

A atividade inicial responsável por este menu é a TripManagerActivity. A cada plano de viagem

está associado um estado: agendado; em execução; expirado; e completo. Quando o plano é

agendado pelo utilizador através do Simulador de Viagem, é associado o estado agendado. So-

bre este plano, o utilizador poderá novamente consultar o plano detalhado ou a sua ilustração

no mapa tal como especificado na secção anterior. Adicionalmente, poderá apaga-lo de forma

permanente. Caso o plano se encontre no estado agendado ou em execução, é possível come-

çar ou continuar a tarefa do acompanhamento de viagem.

A funcionalidade do acompanhamento de viagem foi implementada com recurso a um serviço

e a uma atividade. Tal decisão deve-se à necessidade desta tarefa ser executada em segundo

plano, i.e., sem ser necessário a consulta da interface gráfica e da respetiva atividade por parte

do utilizador. Assim, caso o utilizador tenha como atividade topo a TripMonitoringActivity, to-

das as notificações serão demonstradas na interface gráfica dessa atividade. A comunicação


entre o serviço e a atividade é realizada através da declaração de um BroadcastReceiver na

atividade e do envio de Intent por parte do serviço com filtros apropriados. Caso contrário, ou

seja, caso o utilizar se encontre noutra atividade da aplicação ou mesmo fora do contexto da

aplicação, será notificado através do sistema Android e do seu serviço de notificações.

Em termos de implementação, ao lançar a atividade responsável pelo acompanhamento de

viagem (TripMonitoringActivity) é iniciado o serviço TripMonitoringService. Este por sua vez

lança uma Thread (MonitoringTrip) cuja função é acompanhar a deslocação do utilizador ao

longo do plano, detetando os diversos eventos. A lógica desta tarefa foi implementada através

duma máquina de estados representada na figura 4.14. Com o início da viagem existe uma

transição para o estado Caminhar. Através deste estado é possível chegar a um estado final

caso a ligação atual seja a última, i.e., que permita chegar ao destino. Caso contrário, a ligação

terá como destino uma paragem, levando a que seja atualizado o estado para Espera. Para de-

tetar a chegada ao destino ou à paragem, a Thread MonitoringTrip compara a posição atual do

dispositivo móvel com a posição da paragem ou do destino através duma manipulação das co-

ordenadas geográficas. A periodicidade desta comparação está dependente da receção duma

atualização de posição por parte do sistema GPS. Assim que a distância entre os dois pontos

seja inferior a um limite estipulado, existirá uma transição de estados. No estado Espera apenas

existe uma transição possível para o estado Transporte que representa a chegada do transporte

à paragem. Para detetar este evento, é lançada uma Thread auxiliar (BusLocationUpdater)

responsável por interrogar periodicamente o Servidor InfoBUS pela posição atual do respetivo

transporte. Já no estado Transporte existem 3 transições possíveis aquando da chegada a uma

paragem. Caso seja uma paragem de saída e a próxima ligação seja efetuada a caminhar, existe

uma transição para o estado Caminhar. Caso seja uma paragem de saída mas a próxima ligação

seja efetuada noutro transporte, existe uma passagem para o estado Espera. Caso contrário,

trata-se meramente de uma paragem realizada pelo transporte que não deverá ser utilizada pelo

utilizador. A comparação de posições entre os transportes, paragens e o dispositivo móvel é

análoga à descrita anteriormente.

Com a ocorrência de um evento, existe a necessidade de notificar o utilizador da estado atual da

sua viagem ou da transição ocorrida. Foram desenvolvidas as seguintes notificações para esse

propósito:

• Informação do próximo transporte

• Próxima paragem a utilizar

• Caminhar até à próxima paragem


Figura 4.14: Acompanhamento de Viagem - Máquina de estados

• Caminhar até ao destino

• Abandonar o transporte na próxima paragem

• Não abandonar o transporte na próxima paragem

• Chegada ao destino

• Chegada à paragem

• Apanhar o transporte

Qualquer ação não prevista do utilizador, como por exemplo a perca de um transporte, ou o

atraso significativo de um transporte que invalide a execução do plano de viagem, não é atu-

almente detetado pela aplicação móvel. Tais ações ou condicionantes não foram identificadas

como requisitos a implementar numa primeira fase do projeto. No entanto, a solução para estes

problemas passaria por detetar estes casos através de comparações de posição semelhantes

às descritas anteriormente ou por análise a atrasos registados. Seria acrescentando um estado

de erro na máquina de estados e assim que ocorresse uma transição para este novo estado,

seria requisitado um novo plano de viagem ao Servidor InfoBUS com um novo ponto de origem

e uma nova data de partida relativamente ao pedido inicial.

Capítulo 5

Avaliação

Durante o desenvolvimento do sistema foram realizados testes de unidade para garantir a

correta implementação de todos os requisitos e funcionalidades. A integridade e validade

da comunicação entre os diversos componentes foi verificada com testes de integração. Como

avaliação do sistema final foram tiradas métricas relativas a duração de tarefas e de memória

ocupada. Foram verificados todos os casos de uso exercidos pelo utilizador na Aplicação Móvel.

Os testes foram realizados num computador com as características descritas na figura 5.15 e os

dados utilizados do XTraN Passenger são referentes à zona geográfica do Chapecó, Brasil.

(a) Caracteristicas CPU (b) Caracteristicas Memória

Figura 5.15: Máquina de testes

53

54 CAPÍTULO 5. AVALIAÇÃO

5.1 Algoritmo do Simulador de Viagem

5.1.1 Tempo de Inicialização e Análise dos Dados

A aplicação do algoritmo para determinar os planos de viagem necessita de dados referentes à

rede de trânsito. Estes dados são pré-computados antes de qualquer pedido efetuado ao Simu-

lador de Viagem, ou seja, são pré-computados com a inicialização do algoritmo e atualizados

com período definido pelo administrador do sistema. Este processo foi avaliado através da du-

ração desta tarefa e das características do grafo resultante como a memória ou o número de

vértices. Foram realizadas 5 experiências nas quais houve uma variação crescente da quanti-

dade de carreiras como dados de entrada. A base de dados do XTraN Passenger possui no seu

total 350 carreiras. A tabela 5.3 agrega todos os resultados obtidos.

Existe um aumento linear entre o número de carreiras processadas como input e o número de

conexões no grafo resultante. O mesmo se aplica à relação entre número de carreiras e o me-

mória do grafo. Já o número de vértices e de arcos tem uma variação de crescimento menor à

medida que o número de carreiras aumenta. O tempo de construção também aumenta linear-

mente com o número de carreiras processadas como input e o seu valor de grandeza justifica-se

pelo facto de ser necessário aceder aos dados presentes na base de dados do XTraN Passen-

ger de forma a obter as paragens, ligações entre paragens, linhas de transporte e os respetivos

horários. Este processo engloba também o cálculo e adição de ligações pedestres entre as

paragens. A memória ocupada pelo conjunto de dados completo (350 Carreiras) é de 23 MB e

corresponde a um total de 591 vértices/paragens, 1202 arcos/ligações e 8726 conexões. Estes

dados são mantidos em memória principal durante todo o tempo de execução do Simulador de

Viagem.

5.1.2 Pedidos ao Simulador de Viagem

A duração da execução do algoritmo dos melhores planos de viagem é um fator crucial para

a avaliação do Simulador de Viagem. O sucesso deste componente assenta na capacidade

de serem apresentados os melhores planos de viagem, em tempo aceitável para o utilizador,

independentemente da diversidade no valores de entrada. O teste apresentado consiste na

formulação de pedidos ao Simulador de Viagem com dados de entrada gerados aleatoriamente:

ponto de origem e destino (dentro dos limites geográficos da zona do Chapecó, Brasil), data

5.1. ALGORITMO DO SIMULADOR DE VIAGEM 55

Carreiras Tempo (Seg) Vértices/Paragens Arcos Conexões Memória (MB)

70 11,70 383 653 1430 5

140 15,31 524 946 3327 10

210 23,24 543 1006 5330 15

280 31,83 578 1106 7374 19

350 36,18 591 1202 8726 23

Tabela 5.3: Construção das estruturas de dados

de partida (entre as 8 e as 23 horas do dia 21/08/2012) e distância máxima pedestre (valores

entre 500 e 1000). Este teste não contempla a segunda fase do algoritmo, i.e., a conjugação

dos resultados com a previsão de chegada dos autocarros às paragens dada pelo Servidor de

Estimativa de Tempos. Cada pedido foi duplicado para ser processado tendo como preferência

para a viagem o caminho mais rápido e no seu duplicado, o caminho com menos transbordos.

Foram realizados 100 experiências nestas condições. Os gráficos da figura 5.16 apresentam a

duração do algoritmo para cada um dos pedidos respetivamente. Os resultados obtidos revelam

uma média de 74 milissegundos para a execução do algoritmo tendo como heurística o tempo

mínimo e 93 milissegundos para a minimização de transbordos. Existem no entanto alguns

casos em que o tempo de execução atingiu valores máximos de 896 e 1107 milissegundos.

Tais casos podem ser justificados pela necessidade do algoritmo Dijkstra ter executado até ao

fim, i.e., ter processado todos os nós e todas as combinações possíveis de ligações entre os

mesmos e não ter encontrado qualquer plano exequível. O valor da distância pedestre máxima

pode não ter sido suficiente ou não existir efetivamente uma rota entre os pontos especificados.

5.1.3 Planos de Viagem Detalhados

Tão importante como o tempo de execução do algoritmo é o conteúdo dos resultados apresen-

tados. O segundo teste feito ao Simulador de Viagem tem como objetivo detalhar os resultados

obtidos após a execução do algoritmo, verificar as diferenças entre os planos obtidos com dife-

rentes preferências e valida-los manualmente. Os dados de entrada são gerados aleatoriamente

tal como no teste anterior. Existe ainda a variação da preferência para determinar os planos

de viagem: FASTEST - percurso mais rápido; MIN_TRANSHIPMENT - percurso com menos


(a) Resultados - Caminho mais rápido

(b) Resultados - Caminho com menos transbordos

Figura 5.16: 100 Pedidos ao Simulador de Viagem

transbordos. As figuras B.28 e B.29 sumarizam as experiências realizadas nestas condições,

detalhando os dados de entrada e as características dos 3 melhores planos obtidos segundo

o critério especificado. Para cada plano é apresentado o tempo total de viagem, o tempo total

de espera, a distância total, a distância total pedestre e o número de transbordos. No caso da

preferência ser o percurso mais rápido, os resultados são ordenados pelo tempo total. Caso con-

trário, os resultados são ordenados pelo número de transbordos, tornando possível que planos

secundários tenham efetivamente uma duração inferior ao plano principal. A existência dos 3

melhores planos com caraterísticas similares em relação às distâncias não é de estranhar visto

que existem diversas linhas de transporte que executam as mesmas ligações entre paragens.

Com este teste é possível concluir que os planos fazem sentido do ponto de vista do utilizador e

que as alternativas apresentadas são válidas.

5.1. ALGORITMO DO SIMULADOR DE VIAGEM 57

5.1.4 Conjugação de Resultados com o Servidor de Estimativa de Tempos

A conjugação de resultados com o Servidor de Estimativa de Tempos foi excluída dos testes

anteriores visto que é necessário uma atualização em tempo real da posição dos autocarros no

mundo real. Tal não acontece visto que os dados recolhido correspondem a um backup da base

de dados do XTraN Passenger. Logo todos os pedidos ao Servidor de Estimativa de Tempos são

inconsequentes no que diz respeito à atualização de tempos dos planos previamente obtidos.

As previsões retornadas coincidem com os tempos obtidos durante a primeira fase do algoritmo.

De forma a testar a execução do algoritmo completo, esta limitação é contornada pela interceção

de cada chamada ao Servidor de Estimativa de Tempos, retornando um resultado fictício que

provoque a alteração dos planos. Este teste foi realizado sobre os seguintes planos de viagem

obtidos na primeira fase do algoritmo:

1. Plano A: Trajeto constituído pelas ligações: Deslocação pedestre - Carreira 70 (3 para-

gens - Horário na 1ª paragem: 08:40:00) - Carreira 71 (1 paragem - Horário na paragem:

08:50:00) - Deslocação pedestre.

2. Plano B: Trajeto constituído pelas ligações: Deslocação pedestre - Carreira 100 (4 para-

gens - Horário na 1ª paragem: 08:50:00) - Deslocação pedestre.

3. Plano C: Trajeto constituído pelas ligações: Deslocação pedestre - Carreira 82 (4 paragens

- Horário na 1ª paragem: 09:00:00) - Deslocação pedestre.

A previsão de chegada das carreira 70, 100 à respetiva paragem foi atrasada em 15 minutos.

Como resultado desta ação, o plano A tornou-se inválido visto que o horário da carreira 71 não se

atrasou e era necessário a chegada do utilizador à paragem de entrada da carreira 71 até o seu

horário de passagem do autocarro (08:50:00). Já os restantes planos continuaram exequíveis

mas com uma alteração no tempo de viagem no plano B. No entanto, houve uma reordenação

da ordem dos planos, sendo apresentados como resultado final os planos C e B nesta precisa

ordem. De notar que as previsões disponibilizadas pelo servidor de estimativa de tempos são

sempre referente a todos os veículos duma determinada carreira, contemplando assim o facto

de que se existisse uma outra carreira 70 com horário de passagem na 1ª paragem às 08:41:00,

o plano A apenas sofreria uma alteração de tempo de viagem. Através deste teste foi possível

testar todos os casos que poderão acontecer na realidade sendo os resultados os expectáveis.


5.2 Aplicação Móvel

5.2.1 Testes de Usabilidade

Para avaliar a usabilidade da aplicação móvel, foi pedido a 10 utilizadores que nunca tiveram

contacto prévio com a aplicação, que desempenhassem um conjunto de tarefas que corresponde

à execução dos casos de uso definidos. Cada tarefa foi avaliada segundo as seguintes métricas:

tempo, erros cometidos e grau de satisfação (1-Muito Insatisfeito; 2-Insatisfeito; 3-Satisfeito; 4-

Bom; 5-Muito Bom). As tarefas são:

1. Realizar uma pesquisa avançada para ir para o local: Chapecó - Santa Catarina, Brazil.

Obter as paragens nas imediações da área apresentada. Visualizar para uma das para-

gens obtidas pelo processo anterior, a informação dos itinerários e das próximas previsões

de chegada à respetiva paragem.

2. Realizar uma pesquisa avançada para obter informação da linha de transporte: 02-Tomazelli,

Tomazelli. Direcção: Down. Mostrar as viaturas no itinerário e consultar informação para

uma das viaturas ilustradas.

3. Realizar uma simulação de viagem com os seguintes dados: ponto de origem e de des-

tino especificados através do mapa e dentro dos limites de Chapecó; selecionar a data

24/08/2012 às 09:00 horas; percurso mais rápido; e distância máxima a pé de 750 metros.

Obter resultados e consultar o plano detalhado para o primeiro plano de viagem obtido.

Os resultados dos testes é expresso através da figura 5.17. A 1ª tarefa teve uma média de:

duração - 78,2 segundos; erros - 0,6; satisfação - 4,2. A 2ª tarefa teve uma média de: duração

- 83,4 segundos; erros - 0,3; satisfação - 4,2. A 3ª tarefa teve uma média de: duração - 150,5

segundos; erros - 0,2; satisfação - 4,8. Na sua generalidade, os utilizadores conseguiram exe-

cutar as tarefas sem necessitar de qualquer ajuda, compreendendo intuitivamente o que realizar

na aplicação. Em alguns casos, estes cometeram erros que atrasaram a conclusão da tarefa.

Alguns destes erros foram: navegação para o menu errado ou seleção da funcionalidade errada

à primeira tentativa. No caso específico do 5º utilizador da 2ª tarefa, este não encontrou a fun-

cionalidade de mostrar as viaturas no itinerário. Todas as tarefas, na opinião dos utilizadores,

contribuíram para uma satisfação global bastante positiva. A 3ª tarefa, apesar de ser a mais

extensa, foi a menos propensa a erros e com uma média de satisfação mais elevada.


(a) Duração das tarefas

(b) Erros cometidos

(c) Grau de satisfação

Figura 5.17: Resultados dos Testes de Usabilidade


5.2.2 Duração Pedido-Resposta

A duração entre o pedido ao servidor e a sua resposta é um fator critico porque qualquer utili-

zador não deverá esperar um tempo excessivo pela informação que pretende. Caso contrário,

o utilizador fica aborrecido, perdendo o interesse em utilizar as funcionalidades do sistema. O

requisito inicial para esta duração foi estabelecido em 3 segundos e foi avaliada através da for-

malização de 10 pedidos para cada uma das seguintes tarefas disponíveis na aplicação móvel:

obtenção das paragens nas imediações; simulação de viagem. Foram escolhidas estas funcio-

nalidades pois ilustram casos opostos: um pedido simples e um pedido mais complexo, exigindo

uma computação superior no Servidor, inigualável por qualquer outro pedido. Cada pedido foi

duplicado e avaliado segundo dois ambientes de ligação diferente (rede Wifi e rede 3G). A rede

Wifi utilizada foi a do Instituto Superior Técnico, com velocidades máximas de 54 Mbps e a rede

3G da Vodafone com velocidades máximas de 4 Mbps. O Servidor InfoBUS e o Simulador de

Viagem foram colocados numa rede doméstica com velocidades aproximadas de download e

upload de 50 Mbps e 8 Mbps, respetivamente. Os dados de entrada para qualquer pedido foram

gerados aleatoriamente dentro dos limites estipulados.

Os resultados obtidos para a execução dos 10 pedidos referentes à obtenção de paragens nas

imediações, representados na figura 5.18, revelam uma média da duração de 93,3 milissegun-

dos para a rede Wifi e de 251,3 milissegundos para a rede 3G. Já para os 10 pedidos referentes

à simulação de viagem, a média foi de 273,5 milissegundos para a rede Wifi e de 573,6 milisse-

gundos para a rede 3G. Os valores máximos são de 491 milissegundos e de 1333 milissegundos

para cada um diferentes tipos de pedidos, referentes em ambos os casos, à rede 3G. Os resul-

tados obtidos são satisfatórios e cumprem claramente o limite máximo traçada como requisito

inicial - 3 segundos.

5.2.3 Acompanhamento de Viagem

Em ordem de ser testada a funcionalidade do acompanhamento de viagem é necessário a re-

correr a dois tipos de simulação: a posição geográfica do dispositivo móvel e dos transpor-

tes que fazem parte do plano de viagem. Para simular a posição do utilizador foi desenvol-

vido uma aplicação extra em JAVA, denominada por InfoBUSSimulator, com o único propósito

de estabelecer uma ligação Telnet para o emulador do Android, para que sejam enviadas as

coordenadas geográficas. O emulador por sua vez, simula a receção de um sinal GPS no

sistema Android com as coordenadas recebidas anteriormente. Para simular a posição dos

transportes é intercetada a chamada ao servidor que é responsável por esta funcionalidade


(a) Paragens nas imediações

(b) Simulação de viagem

Figura 5.18: Resultados da Duração Pedido-Resposta

(http://ServerAddress/MobileActualState?plate=”plateNumber”), alterando os dados retor-

nados de forma a que exista uma deslocação fictícia dos transportes. Como referido anterior-

mente, a posição dos transportes não é atualizada na base de dados do XTraN Passenger visto

que se trata de um backup sem atualizações em tempo real.

O plano de viagem utilizado neste teste foi reaproveitado de testes anteriores, i.e., o plano cons-

tituído pelas ligações: Deslocação pedestre - Carreira 70 (3 paragens - Horário na 1ª paragem:

08:40:00) - Carreira 71 (1 paragem - Horário na paragem: 08:50:00) - Deslocação pedestre. Este

plano é constituído por ligações pedestres e duas carreiras, possibilitando assim o teste dos dife-

rentes casos de alternação do tipo de transporte: pedestre -> autocarro; autocarro -> autocarro;

autocarro -> pedestre. A figura 5.19 é constituída por imagens da aplicação móvel durante a


execução do plano especificado. O início do plano corresponde à deslocação pedestre até à pri-

meira paragem. Nesta paragem, o utilizador aguarda a chegada da Carreira 70 sendo possível

consultar a sua posição atual no mapa. Após o embarque, a aplicação notifica o utilizador das

paragens que deve ignorar e a paragem que deve utilizar para sair do autocarro. O processo de

espera por um transporte repete-se, neste caso, pela carreira 71 (omitido na imagens). Por fim,

e após a realização de uma ligação a caminhar, o utilizador chega ao seu destino final.


(a) Caminhar para a paragem (b) Chegada à paragem (c) Em espera do autocarro

(d) Chegada do autocarro (e) Em deslocação pelo autocarro (f) Paragem a não utilizar

(g) Paragem a utilizar (h) Caminhar para o destino final (i) Chegada ao destino

Figura 5.19: Teste do acompanhamento de viagem

Capítulo 6

Conclusão

Neste documento foi apresentado o sistema InfoBUS anyWhere. Este permite disponibili-

zar em ambiente móvel, parte da informação gerida pela empresa Tecmic relativa à sua

gestão inteligente de frotas dos transportes públicos, o XTraN Passenger. Incluído igualmente

neste sistema está o Simulador de Viagem que permite que o utilizador se abstraía da tarefa,

por vezes complexa e demorada, de determinar manualmente um plano de deslocação usando

os transportes públicos.

Como trabalho de pesquisa e contextualização face ao propósito deste projeto, foram apresen-

tados vários sistemas de apoio à utilização de transportes públicos, denominados de APTS.

Foram abordadas as funcionalidades de cada sistema, algumas das tecnologias inerentes e as

suas aplicações móveis. Foram também cobertos os sistemas APTS que incluem simuladores

de viagem. Estes assentam em diferentes técnicas, estruturas de dados e algoritmos que per-

mitem a determinação de planos de viagem tendo em consideração fatores como o tempo, o

número de transferências de linha de transporte ou a distância.

O sistema InfoBUS anyWhere é constituído por 3 componentes. Localizado nas infraestrutu-

ras da Tecmic, encontra-se o Simulador de Viagem. Este é responsável pela determinação

dos planos de viagem com base na informação presente no XTraN Passenger. Os dados são

convertidos numa estrutura de dados própria do Simulador de Viagem: um grafo que modela

toda a rede de trânsito, onde cada vértice corresponde a uma paragens e cada arco a uma liga-

ção, pedestre ou de transporte, entre duas paragens. O algoritmo de procura para a obtenção

dos melhores planos de viagem é baseado na aplicação do algoritmo de Dijkstra. A pesagem

de cada arco corresponde ao tempo ou ao número de transbordos total da viagem até então.

Sendo este critério determinado pelo pedido do utilizador, assim como o limite à deslocação

65

66 CAPÍTULO 6. CONCLUSÃO

pedestre. Após a obtenção dos planos de viagem, com base em horários estáticos, é feito uma

conjugação com informação em tempo real relativa aos atrasos dos transportes incluídos no

plano, validando ou reordenando os resultados anteriores.

Também presente nas infraestruturas da Tecmic encontra-se o Servidor InfoBUS cujo princi-

pal propósito é disponibilizar uma API, através da Web e com recurso a serviços REST, para o

acesso a todos os dados do XTraN Passenger e do Simulador de Viagem. O 3º componente

desenvolvido foi uma Aplicação Móvel para Android. Esta é responsável por apresentar gra-

ficamente ao utilizador a informação pretendida por este. Para tal, é feita uma comunicação

com o Servidor InfoBUS, invocando um dos seus serviços (informação de paragens, linhas de

transporte, horários, previsões de chegada, simulação de viagem, localização de veículos, etc.).

A aplicação móvel dispõe igualmente da funcionalidade de ser efetuado um acompanhamento

em tempo real da execução do plano de viagem obtido, alertando o utilizador de eventos como a

chegada do transporte, paragem a utilizar ou simplesmente informando-o do próximo transporte.

Todos os testes realizados ao sistema desenvolvido tiveram resultados satisfatórios. Para o

Simulador de Viagem, foram quantificados os tempos de inicialização e construção de dados,

assim como o desempenho do seu algoritmo de procura para um conjunto diversificado de da-

dos de entrada. Já o protótipo da aplicação móvel, foi sujeita a testes de usabilidade por parte

de diferentes utilizadores. O requisito para a duração entre o pedido e a resposta ser inferior a 3

segundos foi validado para redes Wifi e 3G. A funcionalidade do acompanhamento de viagem foi

também ela validada com recurso a algumas simulações devido ao impedimento de ser testado

em condições reais.

Todos os objetivos foram alcançados com sucesso e todos os requisitos definidos foram im-

plementados e validados. Contudo, existem alguns aspetos que deverão ser reavaliados e que

podem ser melhorados. A distância a pé entre duas paragens é calculada usando a distância de

Manhattan, o que pode levar a resultados enganadores uma vez que poderão haver casos onde

existem vias ou rios que não podem ser atravessados e é necessário percorrer uma distância

bastante superior.

O algoritmo dos melhores planos de viagem não garante os K caminhos mais curtos pois con-

sidera a exclusão de linhas de transporte e não de paragens em cada aplicação do algoritmo

de Dijkstra. Apesar de evitar o retorno de alternativas que não fazem sentido do ponto de vista

do utilizador, poderão existir casos em que a melhor alternativa ao plano principal consiste efe-

tivamente no abandono antecipado de uma determinada linha de transporte, também incluída

no plano principal, para considerar uma percurso diferente e viável. A solução para este pro-

blema passará por considerar a exclusão de caminhos entre as diversas iterações do algoritmo

6.1. TRABALHO FUTURO 67

de Dijkstra ao nível das linhas de transporte e das paragens.

Existe uma limitação da aplicação do algoritmo de Dijkstra face ao limite para a deslocação pe-

destre. Caso este limite seja ultrapassado durante a execução do algoritmo, este não considera

a utilização de mais ligações pedestres. Tal facto pode levar a que não seja encontrado o ca-

minho mais curto. O comportamento exemplar seria tolerar a utilização numa primeira fase de

ligações mais demoradas (sem ser a pé) para mais tarde poder andar a pé.

6.1 Trabalho Futuro

A implementação do algoritmo dos melhores planos de viagem poderá incorporar algum parale-

lismo entre as diversas invocações ao algoritmo de Dijkstra. Podem ser incluídos outro tipo de

preferências para serem determinados os melhores planos de viagem, preferências como preço

das viagens ou restringir o uso de algum tipo de transportes. Podem inclusive ser considerados

outros algoritmos para a determinação do caminho mais curto.

A aplicação móvel encontra-se completamente funcional. No entanto, deverá ser melhorada

em termos de interface gráfica, proporcionando ao utilizador uma experiência mais satisfatória

e agradável em termos de visualização e interação com o dispositivo. Novas funcionalidades,

como a receção de avisos e alertas, também podem ser incluídas. O acompanhamento de vi-

agem poderá ser estendido de forma a incorporar a deteção de incumprimentos do plano de

viagem face a erros do utilizador ou a atrasos dos transportes públicos.

Bibliografia

[1] S. D. Maclean and D. J. Dailey. The use of wireless internet service to access real-time tran-

sit information. In Proceedings of the Nineth Annual World Congress on Intelligent Transport

Systems 2002, 2002.

[2] S.J. Barbeau, P.L. Winters, N.L. Georggi, M.A. Labrador, and R. Perez. Travel assistance

device: utilising global positioning system-enabled mobile phones to aid transit riders with

special needs. volume 4, pages 12–23. 2010.

[3] Brian Ferris, Kari Watkins, and Alan Borning. Onebusaway: A transit traveler information

system. In Mobile Computing, Applications, and Services - First International ICST Con-

ference, MobiCASE 2009, San Diego, CA, USA, October 26-29, 2009, Revised Selected

Papers, volume 35, pages 92–106. Springer, 2009.

[4] Liping Zhang, Jing-Quan Li, Kun Zhou, Somak Gupta, Meng Li, Wei-Bin Zhang, Mark Miller,

and James Misener. Traveler information tool with integrated real-time transit information

and multimodal trip planning. pages 1–10. 2011.

[5] American Public Transit Association. Public transportation facts at a glance. Technical

report, APTA, 2008.

[6] D. Schrank and T.Lomax. 2009 urban mobility report. Technical report, Texas Transportation

Institute, 2009.

[7] Jeffrey L Adler and Victor J Blue. Toward the design of intelligent traveler information sys-

tems. volume 6, pages 157–172. 1998.

[8] Research, Special Programs Administration, and Volpe National Transportation Systems

Center. Advanced public transportation systems : the state of the art : update 2000. Federal

Transit Administration, 2000.

[9] Bharat Rao and Louis Minakakis. Evolution of mobile location-based services. volume 46,

pages 61–65. ACM, New York, NY, USA, 2003.

69

70 BIBLIOGRAFIA

[10] S.D. Maclean and D.J. Dailey. Busview: a graphical transit information system. In Intelligent

Transportation Systems, 2001, pages 1073–1078. IEEE, 2001.

[11] Donald Patterson, Lin Liao, Krzysztof Gajos, Michael Collier, Nik Livic, Katherine Olson,

Shiaokai Wang, Dieter Fox, and Henry Kautz. Opportunity knocks: A system to provide

cognitive assistance with transportation services. In UbiComp 2004: Ubiquitous Computing.

Springer.

[12] Joo-Yen Choi, Ja-Hyun Jung, Sungmi Park, and Byeong-Mo Chang. A location-aware smart

bus guide application for seoul. In Convergence and Hybrid Information Technology, 2008.

ICCIT ’08. Third International Conference on, volume 1, pages 875–880, 2008.

[13] Katrin Dziekan and Karl Kottenhoff. Dynamic at-stop real-time information displays for public

transport: effects on customers. volume 41, pages 489–501. 2007.

[14] Brian Ferris, Kari Watkins, and Alan Borning. Onebusaway: Location-aware tools for impro-

ving public transit usability. 2010.

[15] Brian Ferris, Kari Watkins, and Alan Borning. Onebusaway: results from providing real-time

arrival information for public transit. In Proceedings of the 28th international conference

on Human factors in computing systems, pages 1807–1816, Atlanta, Georgia, USA, 2010.

ACM.

[16] K.G. Zografos, K.N. Androutsopoulos, and V. Spitadakis. Design and assessment of an

online passenger information system for integrated multimodal trip planning. volume 10,

pages 311–323. IEEE, 2009.

[17] Chao-Lin Liu, Tun-Wen Pai, Chun-Tien Chang, and Chang-Ming Hsieh. Path-planning algo-

rithms for public transportation systems. In Intelligent Transportation Systems, 2001, pages

1061–1066. IEEE, 2001.

[18] Ravindra K. Ahuja, Thomas L. Magnanti, and James B. Orlin. Network Flows: Theory,

Algorithms, and Applications. Prentice Hall, 1993.

[19] Jerald Jariyasunant and Eric Mai. Algorithm for finding optimal paths in a public transit

network with real-time data. In Transportation Research Board 90th Annual Meeting, 2010.

[20] Joel Booth, Prasad Sistla, Ouri Wolfson, and Isabel F. Cruz. A data model for trip planning

in multimodal transportation systems. In Proceedings of the 12th International Conference

on Extending Database Technology: Advances in Database Technology, pages 994–1005,

New York, NY, USA, 2009. ACM.

BIBLIOGRAFIA 71

[21] M. Erwig and M. Schneider. Spatio-temporal predicates. volume 14, pages 881–901. IEEE,

2002.

[22] Daniel Delling, Peter Sanders, Dominik Schultes, and Dorothea Wagner. Engineering route

planning algorithms. In Algorithmics of Large and Complex Networks. Lecture notes in

computer science. Springer, 2009.

[23] Zihui Zang and Wenxue Cai. A dynamic shortest path algorithm based on real-time traffic

information in the urban public transit network. In Service Operations and Logistics, and

Informatics, 2008. IEEE International Conference on, volume 2, pages 1500–1504. IEEE,

2008.

[24] L.P. Zhang W.-B. Zhang J.Q. Li, K.Zhou. A multimodal trip planning system incorporating the

park-and-ride mode and real-time traffic/transit information. In ITS World Congress, 2010.

[25] Boris Cherkassky, Andrew V. Goldberg, and Tomasz Radzik. Shortest paths algorithms:

Theory and experimental evaluation. volume 73, pages 129–174. 1993.

[26] Víctor Jiménez and Andrés Marzal. Computing the k shortest paths: A new algorithm and

an experimental comparison. In Jeffrey Vitter and Christos Zaroliagis, editors, Algorithm

Engineering, volume 1668, pages 15–29. Springer, Berlin, 1999.

Apêndice A

Imagens da Aplicação Móvel

73

74 APÊNDICE A. IMAGENS DA APLICAÇÃO MÓVEL

(a)M

enuprincipal

(b)Inform

ação/Localizaçãode

Transportes-O

pções(c)

Paragens

nasim

ediações

FiguraA

.20:Im

agensda

Aplicação

Móvel

75

(a)

Info

rmaç

ãopa

rage

m(b

)In

form

ação

gera

lda

para

gem

(c)

Info

rmaç

ãodo

siti

nerá

rios

que

pass

amna

para

gem

Figu

raA

.21:

Imag

ens

daA

plic

ação

Móv

el


(a)Inform

açãodas

próximas

previsõesde

chegadaà

paragem(b)

Pesquisaavançada

(c)Linha

detransporte

seleccionada

FiguraA

.22:Im

agensda

Aplicação

Móvel

77

(a)

Mos

trarv

iatu

ras

noiti

nerá

rio(b

)In

form

ação

doau

toca

rro

(c)

Sim

ulad

orde

Via

gem

Figu

raA

.23:

Imag

ens

daA

plic

ação

Móv

el


(a)H

ipótesesde

escolhapara

oponto

departida

(b)E

scolhado

pontode

partidaatravés

dom

apa(c)

Selecção

dadata

departida

FiguraA

.24:Im

agensda

Aplicação

Móvel

79

(a)

Sel

ecçã

oda

pref

erên

cia

devi

agem

eda

dist

ânci

am

áxim

ape

dest

re(b

)P

lano

sde

viag

emob

tidos

(c)

Açõ

esso

bre

opl

ano

devi

agem

Figu

raA

.25:

Imag

ens

daA

plic

ação

Móv

el


(a)P

lanode

viagemdetalhado

(b)P

lanode

viagemno

mapa

(c)P

lanoagendado

FiguraA

.26:Im

agensda

Aplicação

Móvel

81

(a)

Ges

tão

dos

plan

osag

enda

dos

Figu

raA

.27:

Imag

ens

daA

plic

ação

Móv

el

Apêndice B

Resultado dos Testes

83

84 APÊNDICE B. RESULTADO DOS TESTES

FiguraB

.28:R

esultadosdetalhados

doS

imuladorde

Viagem

(Dados

deentrada

e1º

plano)

85

Figu

raB

.29:

Res

ulta

dos

deta

lhad

osdo

Sim

ulad

orde

Via

gem

(2º

e3º

plan

o)

InfoBUS anyWhere - Aplicação móvel para consulta de ... · de apoio à utilização de...

Documents

Transcript of InfoBUS anyWhere - Aplicação móvel para consulta de ... · de apoio à utilização de...