filipe andré conceição proença - autenticação · pdf...
TRANSCRIPT
Bus On Demand
Filipe André Conceição Proença
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Júri
Presidente: Professor Doutor Alberto Manuel Rodrigues da Silva
Orientador: Professor Doutor Alberto Manuel Ramos da Cunha
Vogais: Professor Doutor Renato Jorge Caleira Nunes
Outubro, 2010
i
Agradecimentos
Há inúmeras pessoas a quem não poderia deixar de agradecer e que contribuiram para a realização
desta Dissertação e desde já peço desculpa se por alguma razão me esqueci de alguém.
Gostaria de agradecer à Link Consulting por me ter permitido realizar esta dissertação nas suas
instalações, facultando-me todos os meios necessários para o desenvolvimento deste trabalho.
Ao Professor Alberto Manuel Ramos da Cunha, meu Orientador na realização desta Dissertação, pela
orientação, apoio e tempo disponibilizado, assim como pelas sugestões e ideias partilhadas, que
permitiram enriquecer este trabalho.
Ao Engenheiro Marcelino Moreno por todas as sugestões, ideias, acompanhamento, apoio e
conselhos de pesquisa pelos quais me foi guiando.
Aos Engenheiros Nelson Santos e João Severino, que me ajudaram, sempre que puderam, ao longo
da implementação da solução protótipo realizada neste trabalho, permitindo que ultrapassasse com
facilidade algumas dificuldades que me foram surgindo.
A todos os meus amigos, que me apoiaram ao longo de todo tempo, não só enquanto realizei esta
Dissertação mas também ao longo da minha vida académica.
A toda a minha família que sempre se preocupou comigo e puxou por mim para terminar esta
Dissertação, em especial aos meus irmãos, Pedro e Catarina Proença, e à minha avó Eva.
Gostaria também de agradecer ao meu pai e à minha mãe, Acácio e Fernanda, por me terem
permitido frequentar a faculdade e por sempre terem tido confiança no meu sucesso.
Por último, mas não menos importante, à minha namorada, Sara Figueiredo, por me ter aguentado ao
longo desta Dissertação, o que nem sempre foi fácil.
Obrigado a todos!
ii
Resumo
Com a alteração dos padrões de mobilidade, os operadores de serviços de transporte público
necessitam de actualizar a sua oferta de modo a satisfazer estes novos requisitos. É neste âmbito
que se pretende estudar os serviços de Bus on Demand, serviços com itinerários e horários flexíveis,
onde os utilizadores definem a sua origem/destino e uma janela de tempo para a realização da
viagem. Com este trabalho pretende-se desenhar e construir uma solução de gestão de serviços
flexíveis, em tempo real e de forma automática, podendo criar soluções de viagens flexíveis para os
seus utilizadores. Pretende-se também permitir que os utilizadores deste serviço possam realizar os
seus pedidos por vários meios de comunicação e receber informação de retorno aos mesmos pelo
meio previamente utilizado, avisando-os também quando é impossível satisfazer os seus pedidos.
Palavras-chave: Bus on Demand, algoritmo, itinerário, horário, local de embarque, local de
desembarque, janela de tempo, correio electrónico, SMS.
iii
Abstract
With the change in mobility patterns, operators of public transportation services need to upgrade their
offer to meet these new requirements. It is in this context that it is relevant to evaluate Bus on Demand
services, services with flexible routes and schedules, where users define their origin/destination and a
time window for the trip. This work aims to design and build a management solution for flexible
services in real time and automatically, and can create flexible travel solutions for their users. Another
aim is to enable users of this service to make requests by various means of communication and
receive feedback to the previously used mean of communication, warning them also when it is
impossible to fulfill their requests.
Keywords: Bus on Demand, algorithm, itinerary, schedule, boarding place, landing place, time-
window, e-mail, SMS.
iv
Índice
Agradecimentos .........................................................................................................................................i
Resumo .................................................................................................................................................... ii
Abstract.................................................................................................................................................... iii
Lista de Figuras ...................................................................................................................................... vii
Lista de Tabelas .......................................................................................................................................x
Lista de Abreviaturas ............................................................................................................................... xi
1. Introdução ........................................................................................................................................... 1
1.1. Enquadramento .......................................................................................................................... 1
1.2. Motivação e Problema ................................................................................................................ 1
1.3. Objectivos do Trabalho ............................................................................................................... 4
1.4. Organização da Dissertação ...................................................................................................... 5
2. Estado da Arte e Trabalho relacionado .............................................................................................. 6
2.1. Estudos Realizados Sobre a Temática ...................................................................................... 6
2.1.1. The Dial a Ride Problem (DARP) ....................................................................................... 6
2.1.1.1. DARP estático com um único veículo .................................................................... 7
2.1.1.2. DARP dinâmico com um único veículo .................................................................. 7
2.1.1.3. DARP estático com vários veículos ....................................................................... 8
2.1.1.4. DARP dinâmico com múltiplos veículos ................................................................ 8
2.2. Soluções ..................................................................................................................................... 8
2.2.1. Soluções Comerciais .......................................................................................................... 8
2.2.1.1. Trapeze PASS ....................................................................................................... 9
2.2.1.2. MJ SCHEDULING_ROUTING SYSTEM ............................................................. 10
2.2.1.3. GIRO/ACCES ....................................................................................................... 13
2.2.2. Soluções no Domínio da Investigação ............................................................................. 14
2.2.2.1. Sistema Checkpoint DRT ..................................................................................... 14
2.2.2.2. Abordagem descentralizada ................................................................................ 16
2.2.3. Comparação das soluções ............................................................................................... 17
3. Sistema Proposto ............................................................................................................................. 19
4. Implementação da solução de BoD ................................................................................................. 23
4.1. Solução para o cliente .............................................................................................................. 23
4.1.1. Modelo de dados............................................................................................................... 23
4.1.2. Formato das mensagens .................................................................................................. 24
4.1.3. Pedidos via SMS e Correio Electrónico ............................................................................ 25
4.1.4. Tratamento dos pedidos recebidos................................................................................... 25
v
4.1.4.1. Pedido de Reserva ............................................................................................... 26
4.1.4.2. Pedido de Cancelamento ..................................................................................... 27
4.2. Solução para a central .............................................................................................................. 28
4.2.1. Modelo de Dados .............................................................................................................. 29
4.2.2. Gestor de Clientes ............................................................................................................ 31
4.2.2.1. Registo, Procura e Edição de Clientes ................................................................ 32
4.2.2.2. Verificação de Cliente Registado ......................................................................... 34
4.2.3. Gestor de Paragens .......................................................................................................... 35
4.2.3.1. Registo, Procura e Edição de Locais de Paragem .............................................. 36
4.2.3.2. Verificação de Locais de Paragem Existentes..................................................... 38
4.2.4. Gestor de Pedidos ............................................................................................................ 39
4.2.4.1. Inserção de Pedidos ............................................................................................ 41
4.2.4.2. Procura de Pedidos Registados no Sistema ....................................................... 43
4.2.4.3. Edição e Cancelamento de Pedidos .................................................................... 43
4.2.5. Gestor de Serviço ............................................................................................................. 44
4.2.5.1. Cálculo de Itinerários e Horários .......................................................................... 45
4.2.5.2. Algoritmo de Cancelamento de Reserva de Viagem ........................................... 59
4.2.5.3. Viagens Reservadas ............................................................................................ 62
4.3. Integração das soluções ........................................................................................................... 66
4.3.1. Web Service do Sistema da Central ................................................................................. 66
4.3.2. Web Service do Sistema do Cliente ................................................................................. 67
5. Validação da Solução ....................................................................................................................... 69
5.1. Considerações Iniciais .............................................................................................................. 69
5.2. Testes Funcionais ..................................................................................................................... 69
5.2.1. Teste 1 – Pedido de Reserva de Viagem On-demand ..................................................... 69
5.2.1.1. Via Mensagem SMS ............................................................................................ 70
5.2.1.2. Via Correio Electrónico ........................................................................................ 72
5.2.2. Teste 2 – Cancelamento de Reserva de Viagem On-demand ......................................... 74
5.2.2.1. Via Mensagem SMS ............................................................................................ 74
5.2.2.2. Via Correio Electrónico ........................................................................................ 75
5.2.3. Teste 3 – Processamento de vários pedidos on-demand ................................................ 77
6. Conclusões ....................................................................................................................................... 79
6.1. Trabalho Futuro ........................................................................................................................ 80
Referências ........................................................................................................................................... 81
Anexo A – Síntese de Alguns Algoritmos de DaR ................................................................................... I
Anexo B – Contratos WSDL usados na definição dos Web Services .................................................. VII
vi
Anexo C – Dados Inseridos no Sistema Para Realização de Testes .................................................... XI
Anexo D – Número de pedidos realizados por cada viatura ................................................................. XII
vii
Lista de Figuras
Figura 1.Interface Gráfica do Trapeze Pass. .......................................................................................... 9
Figura 2.Interface Web para pedidos de viagem. ................................................................................. 14
Figura 3.Ecrã de reserva efectuada. ..................................................................................................... 14
Figura 4. Apresentação da rota a efectuar por um veículo. .................................................................. 15
Figura 5. Modelo de componentes do sistema. .................................................................................... 15
Figura 6. Diagrama de sequência UML que mostra as interacções entre os agentes do sistema. ...... 16
Figura 7. Arquitectura funcional da solução pretendida. ....................................................................... 20
Figura 8. Arquitectura tecnológica da solução desenvolvida. ............................................................... 21
Figura 9. Modelo de dados usado para guardar os dados das mensagens trocadas no sistema para o
cliente. ................................................................................................................................................... 23
Figura 10. Modelo de dados usado para a implementação da solução da central............................... 30
Figura 11. Modelo de dados para definição de um cliente no sistema. ................................................ 32
Figura 12. Ecrã de registo de um novo cliente. ..................................................................................... 32
Figura 13. Ecrã de cliente registado com sucesso. .............................................................................. 33
Figura 14. Ecrã de pesquisa de clientes. .............................................................................................. 33
Figura 15. Ecrã de visualização do registo do cliente. .......................................................................... 34
Figura 16. Ecrã de edição dos dados de registo de um cliente ............................................................ 34
Figura 17. Modelo de Dados representativo da definição de um local de paragem. ............................ 35
Figura 18. Ecrã de registo de novos locais de paragem. ...................................................................... 37
Figura 19. Ecrã de registo de novo local de paragem com mapa visível. ............................................ 37
Figura 20. Ecrã de procura de locais de paragem inseridos no sistema. ............................................. 38
Figura 21. Ecrã de edição de local de paragem.................................................................................... 38
Figura 22. Modelo de dados representativo de um pedido. .................................................................. 40
Figura 23. Ecrã de registo de novo pedido de reserva BoD. ................................................................ 42
Figura 24. Ecrã de registo efectuado com sucesso. ............................................................................. 42
Figura 25. Ecrã de procura de pedidos de reserva BoD. ...................................................................... 43
Figura 26. Ecrã de visualização de pedido registado. .......................................................................... 44
Figura 27. Ecrã de edição de pedido registado..................................................................................... 44
Figura 28. Ciclo principal do tratamento dos pedidos de reserva de viagens. ..................................... 47
viii
Figura 29. Diagrama representativo da criação de viagem para o pedido que se encontra em
tratamento. ............................................................................................................................................ 48
Figura 30. Diagrama representativo da criação de viagem quando não há serviços de BoD. ............. 49
Figura 31. Diagrama representativo do tratamento de um pedido se existirem serviços de BoD. ...... 51
Figura 32. Diagrama representativo do tratamento do pedido quando já existem serviços BoD com
viagens que têm início no local de embarque pretendido. .................................................................... 53
Figura 33. Diagrama representativo do tratamento do pedido quando já existem serviços BoD com
viagens que têm fim no local de desembarque pretendido. .................................................................. 54
Figura 34. Diagrama representativo do tratamento do pedido tentando inseri-lo no fim dos serviços
BoD já existentes. .................................................................................................................................. 56
Figura 35. Diagrama representativo do tratamento do pedido quando já existem serviços BoD mas
não existem viagens nem com fim nem com início nos locais pretendidos no pedido. ........................ 58
Figura 36. Diagrama representativo da remoção de uma viagem existente num serviço. ................... 61
Figura 37. Ecrã de visualização em diagrama de viagens reservadas num modelo em espinha. ....... 62
Figura 38. Ecrã de visualização em diagrama de viagens reservadas e num modelo em rede. ......... 63
Figura 39. Caixa com informação dos dados de um local de paragem de um itinerário. .................... 64
Figura 40. Ecrã com a lista de entradas/saídas numa paragem........................................................... 64
Figura 41. Ecrã de vista mapa com o itinerário de uma carreira com todo o serviço efectuado e
veículo parado. ...................................................................................................................................... 65
Figura 42. Ecrã de vista mapa com o itinerário de uma carreira com todo o serviço por efectuar e
veículo em movimento. .......................................................................................................................... 65
Figura 43. Balão com os dados de um local de paragem do itinerário que se está a observar. .......... 66
Figura 44. Simulador de envio de mensagens SMS realizando o envio de um pedido de reserva. .... 70
Figura 45. Resposta SMS a um pedido de reserva realizado. .............................................................. 70
Figura 46. Ecrã com os dados do pedido registado. ............................................................................. 71
Figura 47. Resposta SMS confirmando que o serviço irá ser efectuado e quais os seus dados. ........ 71
Figura 48. Ecrã com o itinerário que o veículo terá de efectuar para satisfazer o pedido. ................... 71
Figura 49. Mensagem de pedido de reserva enviada por correio electrónico. ..................................... 72
Figura 50. Mensagem de correio electrónico informando que o pedido de reserva foi guardado....... 72
Figura 51. Mensagem de resposta enviada por correio electrónico comunicando que o serviço foi
criado e quais os dados que o compõem. ............................................................................................. 73
Figura 52. Vista em diagrama do serviço a efectuar após reserva do segundo pedido. ...................... 73
Figura 53. Ecrã mostrando o estado e dados dos pedidos após o seu processamento e respectiva
reserva. .................................................................................................................................................. 73
ix
Figura 54. Simulador de envio de mensagens SMS realizando o envio de um pedido de cancelamento
de reserva. ............................................................................................................................................. 74
Figura 55. Resposta SMS ao pedido de cancelamento efectuado. ...................................................... 74
Figura 56. Ecrã mostrando que o pedido se encontra no estado "Cancelado", ................................... 75
Figura 57. Ecrã com o diagrama da viagem após o cancelamento do pedido de reserva. .................. 75
Figura 58. Mensagem de cancelamento de reserva enviada por correio electrónico. ......................... 75
Figura 59. Mensagem de resposta enviada por correio electrónico comunicando que o cancelamento
do pedido foi realizado com sucesso. ................................................................................................... 76
Figura 60. Ecrã mostrando o estado e dados dos pedidos após o cancelamento. .............................. 76
Figura 61. Vista mapa mostrando que não há serviços a efectuar. ...................................................... 77
Figura 62. Ecrã para simular o funcionamento do sistema. .................................................................. 77
x
Lista de Tabelas
Tabela 1. Comparação das soluções descritas. ................................................................................... 18
Tabela 2. Resultado da execução da simulação sobre os 6169 pedidos. ............................................ 78
Tabela 3. Sumário de alguns algoritmos para o DARP estático e dinâmico com um veículo. ................ I
Tabela 4. Sumário de alguns algoritmos para o DARP estático com vários veículos. ........................... V
Tabela 5. Sumário de alguns algoritmos para o DARP dinâmico com vários veículos. ........................ VI
Tabela 6. Dados dos locais de paragem inseridos no sistema. ............................................................. XI
Tabela 7. Dados de configuração usados. ............................................................................................. XI
Tabela 8. Número de pedidos a satisfazer por cada viatura, após o seu processamento. .................. XII
xi
Lista de Abreviaturas
BoD – Bus on Demand
DaR – Dial a Ride
DaRP – Dial a Ride Problem
DRT – Demand Responsive Transport
HTTP – Hypertext Transfer Protocol
RPC – Remote Procedure Call
URI – Uniform Resource Identifier
URL – Uniform Resource Locator
WSDL – Web Services Description Language
XML – Extensible Markup Language
SIMIP – Sistema Integrado de Mensagens de Informação ao Passageiro
SIGO – Sistema Integrado de Gestão das Operações
1
1. Introdução
1.1. Enquadramento
Esta dissertação foi desenvolvida no âmbito da cadeira Dissertação – Mestrado em Engenharia
Informática e de Computadores do Instituto Superior Técnico da Universidade Técnica de Lisboa.
Trata-se de uma cadeira semestral referente ao 2º Semestre cujo objectivo é o de desenvolver um,
trabalho de investigação e/ou desenvolvimento, de natureza integradora, na área da engenharia
informática, complementado pela escrita de uma dissertação que descreva as e metodologias e
tecnologias usadas, os resultados alcançados e as conclusões retiradas do trabalho desenvolvido1.
O desenvolvimento deste projecto decorreu na empresa Link Consulting SA pertencente ao grupo
AITEC, tendo sido fundada por investigadores do INESC (Instituto de Engenharia de Sistemas e
Computadores). Esta empresa tem como objectivo ser reconhecida como uma das melhores
empresas de TI no país e no estrangeiro.
A solução descrita nesta dissertação foi planeada, desenhada e desenvolvida na unidade
SmartCITIES, a qual é focada na oferta de soluções inteligentes para os transportes públicos. O
desenvolvimento da solução encontra-se integrado com a solução de gestão de operações de
transporte (SIGO) e com a solução de informação ao passageiro (SIMIP), soluções desenvolvidas na
unidade.
1.2. Motivação e Problema
Actualmente, os serviços de transportes públicos de passageiros são, na sua maioria, realizados em
redes com itinerários, paragens e horários fixos. Este tipo de transporte é normalmente denominado
como serviço regular, uma vez que existe um conjunto de veículos que efectuam um determinado
itinerário predefinido, existindo um espaçamento temporal entre a passagem dos mesmos em
determinados pontos de paragem.
Porém, este tipo de serviço começa a ser financeiramente não rentável em meios rurais ou com uma
densidade populacional baixa onde o número de utilizadores não compensa os gastos de manter
autocarros em movimento com alguma periodicidade ao longo do dia. Associado a esta dificuldade,
tem-se verificado que nos últimos anos os padrões de mobilidade das pessoas têm-se vindo a alterar
para movimentos mais irregulares e complexos, diferenciando-se dos movimentos casa – trabalho –
casa. Assim, os serviços de transporte público têm tido dificuldade em acompanhar os requisitos
pretendidos pelos seus utilizadores, não sendo capazes de os satisfazer plenamente.
1 https://fenix.ist.utl.pt/disciplinas/dmeicom2/2010-2011/1-semestre/objectivos
2
Com o objectivo de colmatar as suas restrições, os operadores de serviços públicos começam a
diversificar a sua oferta com serviços mais flexíveis, tais como car-sharing [1] ou bus on demand2 [2].
BoD, também conhecido como Dial a Ride (DaR) [3], encontra-se inserido no contexto de Demand
Responsive Transport3 (DRT). DRT é definido como sendo uma forma avançada de transporte
público de passageiros, orientada ao utilizador. Nesse sentido, DRT é caracterizado por ter uma frota
de veículos de pequena/média dimensão que se deslocam com itinerários e horários flexíveis
operando num modo de partilha da viagem entre um local de origem e um local de destino, tendo
sempre como base as necessidade dos seus passageiros. Os sistemas de DRT adequam-se a um
serviço de transporte público em áreas rurais ou de pouca procura (ex: serviço nocturno), onde o
serviço regular tem dificuldade em responder adequadamente.
Dentro dos serviços flexíveis existem outros tipos de serviços com funções similares. Paratransit4
pretende prestar um serviço semelhante a pessoas com mobilidade reduzida, como é o exemplo de
pessoas idosas ou com problemas motores. Embora este termo se encontre actualmente em uso
para serviços de transporte de pessoas com mobilidade reduzida, inicialmente era usado para definir
DRT.
xTransit5, outro conceito de serviço flexível, tem como objectivo principal conduzir pessoas entre os
arredores dos meios urbanos e para dentro destes, usando veículos com dimensões inferiores a
autocarros, sendo partilhados dinamicamente com outros, e ajudados por comunicações de ponta,
oferecendo mobilidade semelhante à do automóvel.
É nos sistemas de BoD que se centra o tema desta dissertação. Porém, os sistemas de BoD
actualmente existentes, usam como principal meio de realização de pedidos de transporte a chamada
telefónica, tendo a necessidade de ter operadores numa central de atendimento para fazer o registo
do pedido no sistema, assim como comunicar ao cliente se o seu serviço foi ou não satisfeito. A
Internet é também um meio utilizado para fazer esses registos.
A maioria dos serviços de BoD estão implementados em áreas com pouca procura e em sistemas
que não funcionam de uma forma integrada com os serviços já existentes. Normalmente, estes tipos
de serviços são efectuados por empresas privadas que não estão associadas às empresas que
fornecem os serviços fixos, e cujas frotas são constituídas por veículos de dimensões inferiores às
dos autocarros. Por outro lado, normalmente, estes serviços apenas são realizados numa
determinada área, levando a que as pessoas tenham que aguardar um tempo considerável por outro
transporte que as leve a partir do fim da área abrangida por estes serviços, uma vez que a integração
com os serviços fixos, na maioria dos casos, é inexistente, embora já existam soluções que
contemplam estes problemas [4].
São vários os operadores que fornecem este tipo de serviço, como por exemplo:
2 http://www.siddharta-life.it/ 3 http://en.wikipedia.org/wiki/Demand_responsive_transport 4 http://en.wikipedia.org/wiki/Paratransit#Future_of_paratransit 5 http://www.ecoplan.org/general/xtransit.htm
3
Cango6, que opera em Hampshire, no Reino Unido, fornecendo um serviço com um itinerário
flexível, tendo timed stops, paragens obrigatórias num determinado horário, e bookable stops,
paragens reservadas pelos utilizadores onde o autocarro só para quando é realizada uma
reserva.
London Dial-a-Ride7, que opera em Londres, no Reino Unido, fornecendo um serviço porta-a-
porta a pessoas com incapacidades ou problemas de saúde que não lhes permita usar
transportes públicos convencionais.
Yuba-Sutter Transit SRTP Dial-A-Ride8 [5], que opera em Yuba City, Marysville e Linda, nos
EUA. Este serviço é caracterizado por ir recolher/largar os seus passageiros em qualquer
morada dentro da sua área e horário de serviço.
Drinbus9, que opera na zona de Génova-Bolzaneto em Itália. Este serviço serve a população
em geral, tendo paragens fixas, mas com horários e viagens flexíveis. A reserva de viagens
deve ser feita até 30 minutos antes da viagem pretendida, sendo que o serviço é calculado
automaticamente e em tempo real.
SMTUC10 (Serviços Municipalizados de Transportes Urbanos de Coimbra), que opera na
cidade de Coimbra, Portugal, e fornece serviço de transporte a pessoas com problemas ao
nível da mobilidade ou residentes em locais de difícil acesso. Tem um serviço porta-a-porta,
que funciona com base de marcação ou por chamada, para pessoas com menor mobilidade,
e uma frota para uma carreira com itinerário fixo (chamada de linha Azul) que pára em
qualquer local pedido pelo passageiro ao longo do percurso que efectua.
A maioria dos sistemas existentes não usam o paradigma de registo e cálculo de viagens em tempo
real, em que os pedidos vão surgindo ao longo do tempo e é necessário tentar inseri-los nos serviços
que se encontram a decorrer, tendo que, na sua generalidade, ser necessário efectuar os pedidos de
reserva de viagem com, no mínimo, um dia de antecedência.
Outra questão levantada é a de que os sistemas não se encontram integrados com os sistemas do
serviço fixo, não sendo possível conciliar estas duas vertentes: a do serviço dinâmico com a do
serviço fixo, funcionando as duas paralelamente, sem nunca se interceptarem.
Por outro lado, tem-se a situação de que todo o processo não se encontra completamente
automatizado, sendo necessário haver intervenção humana, além da do cliente, para que todas as
fases do processo sejam efectuadas, seja na fase de registo como, por vezes, no próprio cálculo de
inserção dos pedidos numa determinada viagem.
6 http://en.wikipedia.org/wiki/Cango 7 http://en.wikipedia.org/wiki/London_Dial-a-Ride 8 http://www.yubasuttertransit.com/pressreleases/2008/04/2008-Transit-Plan/09-Dial-a-Ride.pdf 9 http://www.siddharta-life.it/ServizioDrinbus.htm 10 http://www.smtuc.pt/avisos/main.php?id=88
4
Finalmente é também importante referir que existem vários tipos de serviços de BoD, tal como pode
ser observado nos serviços prestados pelas empresas acima referidas. Estes serviços podem ser
caracterizados em quatro níveis [2]:
Nível 1: Itinerários fixos. O utilizador pode reservar um serviço que é baseado em itinerários
fixos com paragens predeterminadas mas com horários dinâmicos;
Nível 2: Itinerários fixos com desvios. Os itinerários e os horários estão apenas definidos
parcialmente, havendo a possibilidade de serem alterados em pontos fixos, dependendo dos
pedidos, e serem adicionadas paragens opcionais ao itinerário original;
Nível 3: Itinerários com pontos predefinidos. Os itinerários podem ser predefinidos por locais
de interesse público (tais como parques, estações, etc.), ou podem abranger uma área maior,
tendo horários flexíveis para o transporte para locais de interesse;
Nível 4: Itinerários variáveis. Itinerários sem paragens predefinidas, assim como a origem e o
destino dos passageiros, sendo semelhante ao serviço de táxi mas em veículos com maior
lotação que não servem apenas um grupo restrito.
1.3. Objectivos do Trabalho
Com este trabalho pretende-se prototipar uma solução para a gestão de serviços a pedido de
transportes públicos de passageiros (serviço flexível) em tempo real e de forma automática. Esta
solução deverá suportar todos os níveis de serviços de BoD, e permitir a integração com as soluções
existentes, mas orientada ao suporte de serviços regulares, para permitir a um operador de transporte
público uma gestão centralizada da sua oferta (regular e flexível) e dos respectivos recursos, que são
necessariamente partilhados.
O protótipo deverá permitir que o cliente faça um pedido de transporte, através de diversos canais
electrónicos, transmitindo os locais de início e fim de viagem e uma janela de tempo para a satisfação
dos mesmos, indicando a hora mínima de início de viagem e a hora máxima de chegada ao destino.
Esse pedido deverá ser transmitido a uma central de controlo, a qual deverá verificar de forma
totalmente automática a disponibilidade de viaturas e motoristas para satisfação do mesmo, e, em
caso afirmativo, deverá (re)planear o itinerário e o horário da viatura, e enviar o pedido, o itinerário e
o horário à viatura (motorista) e uma mensagem de confirmação de satisfação de pedido ao cliente.
Em caso negativo, deverá interagir com o sistema e verificar se existem carreiras de serviço fixo que
permitam a satisfação do pedido, e, se tal ocorrer, deverá enviar uma resposta ao cliente na qual
transmita a impossibilidade de satisfação com um serviço flexível e a alternativa em serviço fixo. No
caso de inexistência de serviço fixo para satisfazer o pedido, apenas deverá informar o cliente que
não existe possibilidade de satisfação do seu pedido para a altura pretendida.
A gestão dos pedidos deverá ser realizada em tempo real, permitindo que os pedidos sejam feitos em
qualquer momento, de modo que o cliente tenha uma resposta ao pedido antes da hora de início de
5
viagem por ele indicada. Desta forma, a viatura sairá da garagem com um itinerário e um horário
previstos, os quais poderão variar ao longo da viagem, consoante os pedidos que vão surgindo e
sendo aceites durante a deslocação da viatura.
1.4. Organização da Dissertação
Esta dissertação encontra-se dividida em sete secções, sendo que a primeria secção se destina à
apresentação da dissertação e do trabalho desenvolvido.
Na secção 2 ir-se-á referir o estado-da-arte dos transportes públicos de passageiros rodoviários na
área de BoD assim como algumas soluções nessa área, tanto ao nível de soluções comerciais como
ao nível de soluções no âmbito da investigação.
Na secção 3 descreve-se a solução que se desenhou para implementar o objectivo referido
anteriormente.
Na secção 4 é apresentada a solução implementada, sendo descritas as funcionalidades
implementadas, o seu modo de utilização, o algoritmo criado para cálculo de itinerários e horários e o
modo de comunicação/integração entre as aplicações.
Na secção 5 são descritos os testes realizados para validar a solução implementada.
Na secção 6 são apresentadas as principais conclusões retiradas desta dissertação, salientando o
que há a melhorar e quais as contribuições do trabalho desenvolvido. Serão também sugeridos, nesta
secção, alguns desenvolvimentos futuros que possam trazer contributos para a melhoria da solução
desenvolvida.
6
2. Estado da Arte e Trabalho relacionado
Nesta secção irão ser descritos alguns dos estudos e soluções existentes sobre o tema Bus on
Demand. Esta secção será dividida em duas partes: na primeira (secção 2.1) serão apresentadas
algumas pesquisas já realizadas sobre o tema, e na segunda (secção 2.2) algumas soluções já
existentes.
2.1. Estudos Realizados Sobre a Temática
A temática Bus on Demand (também chamada de Dial a Ride [3]), está enquadrada no contexto de
Demand Responsive Transport e de Transportation on Demand [6], tendo sido alvo de vários estudos,
sendo o primeiro datado de 1971 [3]. Estes estudos têm por base os problemas trazidos na
implementação de uma solução para a satisfação de pedidos de transporte de passageiros, chamado
de Dial-a-Ride Problem [3].
Na subsecção seguinte vai-se definir o que é este problema, e, seguidamente, nas suas subsecções,
vai-se descrever sumariamente os vários modelos deste problema e comparar alguns algoritmos de
cálculo de itinerários, horários e inserção de novos pedidos, para esses modelos.
Uma vez que o âmbito deste trabalho não se prende na criação de algoritmos, foi colocado no Anexo
A uma pequena descrição e comparação, de uma forma superficial, os objectivos e características de
alguns algoritmos existentes sobre este tema.
2.1.1. The Dial a Ride Problem (DARP)
O DARP [6] consiste em calcular rotas e horários de veículos, para um número de utilizadores que
fazem pedidos de transporte de uma origem para um destino (embarque e desembarque) em que,
normalmente, o mesmo passageiro faz dois pedidos no mesmo dia: o de ida e o de volta. Os
utilizadores poderão, também, definir uma janela de tempo, na qual definem a hora mínima a que
pretendem embarcar e a hora máxima a que pretendem chegar ao seu destino. Na versão base deste
problema, o transporte é realizado por um conjunto de veículos com características semelhantes e
que partem da mesma garagem. O objectivo é calcular o custo mínimo de rotas para satisfazer o
máximo de pedidos, com base num conjunto de restrições.
Tendo como base esta definição, pode-se ver que se devem considerar duas questões na resolução
deste problema:
Minimizar os custos relativos à satisfação total dos pedidos;
Maximizar a satisfação de pedidos tendo em conta o número de veículos existentes.
Em ambas as questões deverá estar implícito a minimização da insatisfação do cliente devido a um
excessivo tempo de viagem (ultrapassar o limite da hora de chegada por ele imposto) ou um desvio
7
de tempo de serviço (uma grande diferença entre o tempo real de embarque/desembarque em
relação ao sugerido) [7].
A solução deste problema passa pela definição de heurísticas e algoritmos de cálculo de itinerários e
horários. Por outro lado, existem outros problemas associados ao modo como se pretende
implementar a solução, se dando um limite de tempo para a realização de um pedido (por exemplo,
uma hora antes da saída do veículo da garagem) – modelos estáticos – ou se os pedidos podem ser
realizados em qualquer instante – em que, neste último caso, um dos problemas maiores na sua
implementação poderá passar pela questão de não haver controlo na chegada de pedidos.
A construção de soluções de DARP tem sempre associadas três decisões importantes [8], sendo
elas:
1. Determinação de conjuntos de utilizadores que irão ser servidos pelo mesmo veículo;
2. Colocar sequencialmente os utilizadores no itinerário desse veículo;
3. Agendar actividades de embarque, de desembarque e de condução por cada itinerário.
Nas subsecções seguintes vão-se referir os vários modelos existentes para este problema.
2.1.1.1. DARP estático com um único veículo
Este é o modelo mais simples do DARP. No modelo é considerado que todos os pedidos são
conhecidos de antemão e que não irão ser efectuados mais pedidos no futuro (daí ser estático). Outra
propriedade deste modelo, tal como é indicado no seu nome, é usar um único veículo para servir
todos os pedidos.
Devido à primeira propriedade é possível calcular todos os itinerários antes do tempo estabelecido. A
segunda propriedade torna os algoritmos mais simples, pois, visto que todos os pedidos são servidos
por um único veículo, os pedidos não podem ser decompostos.
Na Tabela 3 (Anexo A) sumariam-se alguns algoritmos existentes para este modelo, fazendo-se
simultaneamente algumas comparações entre os mesmos.
2.1.1.2. DARP dinâmico com um único veículo
Tal como o modelo anterior, neste modelo é considerado que todos os pedidos são servidos por um
único veículo. A diferença está que, neste modelo, os pedidos vão surgindo dinamicamente ao longo
do tempo, mas nenhuma informação se sabe sobre pedidos futuros.
Quando surge um novo pedido para o instante de tempo t, já existe uma solução planeada até esse
tempo, tanto para o itinerário como para o horário. Assim, todos os pedidos agendados para antes de
t já foram processados e já não são relevantes. O problema está na reoptimização da porção da
solução a partir do instante t, onde vai ser inserido o novo pedido.
8
A solução para este problema passa pelo uso da programação dinâmica usada para os algoritmos do
modelo de DARP da secção anterior.
2.1.1.3. DARP estático com vários veículos
A única diferença entre este modelo e o modelo da secção 2.1.1.1 reside no número de veículos
usados para servir os pedidos de transporte. Neste modelo o número de pedidos continua a ser
totalmente conhecido quando se iniciam os cálculos e não contempla o surgimento de novos pedidos.
A dificuldade maior dos algoritmos para este modelo é a existência de vários veículos, o que permite
que os pedidos sejam decompostos.
Na Tabela 4 (Anexo A) apresentam-se alguns algoritmos estudados nesta área, fazendo-se, tal como
na secção anterior, uma comparação entre eles.
2.1.1.4. DARP dinâmico com múltiplos veículos
A diferença deste modelo com o anterior é a forma como vão chegando novos pedidos. Enquanto no
anterior os pedidos são totalmente conhecidos antes de se processar a solução, neste modelo os
pedidos vão surgindo ao longo do tempo.
Uma vez que na vida real não existe dinamismo puro, pois, normalmente, quando se faz o
planeamento já são conhecidos alguns pedidos, e como no caso estático podem existir
cancelamentos que poderão ser ajustados com outros pedidos, a barreira é muito ténue entre os dois
modelos.
A dificuldade neste modelo está em desenhar itinerários semente para os veículos com base nos
pedidos, dando margem de manobra para acomodar pedidos dinâmicos futuros.
Na Tabela 5 (Anexo A) pode-se ver um sumário de alguns algoritmos para este modelo de DARP.
2.2. Soluções
Nesta secção vão-se mostrar algumas soluções. Algumas das soluções são sistemas comerciais, que
se encontram já implementadas e em funcionamento (subsecção 2.2.1) e outras são sistemas que se
encontram no domínio da investigação (subsecção 2.2.2). No final vai-se tentar fazer uma
comparação entre as soluções aqui referidas.
2.2.1. Soluções Comerciais
Existem várias soluções no mercado para a gestão de transporte de passageiros a pedido, porém a
maioria estão relacionados com o transporte de passageiros com dificuldades motoras. Dessa forma,
a maioria trata da gestão de veículos de média/pequena dimensão e com uma frota reduzida.
9
Nas subsecções seguintes vão-se referir dois sistemas já existentes no mercado, porém estes
apenas mostram as funcionalidades que os sistemas do género fornecem, servindo apenas como
exemplos visto o leque ser muito extenso11.
2.2.1.1. Trapeze PASS
Solução da Trapeze [9] para gestão de serviços de pedidos de transporte, transporte comunitário ou
coordenação de serviços.
Figura 1.Interface Gráfica do Trapeze Pass.
O sistema permite gerar horários automaticamente, ver os detalhes de itinerários, incluindo locais de
embarque/desembarque e tempos de viagem, calcular tempos de chegada, fazer monitorização e
ajustar serviços em tempo real, assim como rastrear incidentes, cancelamentos e não aparecimento
de passageiros nos locais de embarque.
Este sistema também permite realizar reservas, tanto para passageiros casuais como regulares,
guardando informação dos passageiros, indicando os tipos de tarifas, múltiplos tipos de factura e
razões da viagem.
Contém mapas integrados, onde é possível ver e definir áreas de serviço, como estradas, limites e
corredores BUS. Permite, também, ver itinerários e deslocação de veículos, transmitindo as
localizações geocode, origens, destinos, clientes, etc. É possível ver a interface gráfica deste sistema
na Figura 1.
Existem várias empresas que têm esta solução implementada. Têm-se, nos Estados Unidos da
América, os casos da Van Tran of Tucson Inc. [10], em Tucson, da Capital Area Rural Transportation
[11], nos arredores de Austin, e, na Europa, do Nexus Call Centre [12], na região de Tyne e Wear em
Inglaterra, e da Middtraffik [13], em Aarhus na Dinamarca.
Apesar de todas as funcionalidades que este sistema fornece, este não é integrável com outras
aplicações, o que leva a uma descentralização e a uma falta de cruzamento automático de dados
11 http://paratransitwatch.blogspot.com/2006/12/scheduling.html
10
dentro de um operador de transportes que forneça outros serviços além do flexível, assim como
possuir outro(s) sistema(s) de informação, no caso de vir a adquirir este sistema. Outra fraqueza
deste sistema está em não oferecer uma solução automática de registo de utilizadores e pedidos,
obrigando a que seja necessário existir alguém da parte do operador a receber e a introduzir os
dados no sistema, assim como não haver comunicação automática com os motoristas para lhes
indicar os pedidos.
2.2.1.2. MJ SCHEDULING_ROUTING SYSTEM
MJ SCHEDULING_ROUTING SYSTEM [14] é um sistema constituído por um conjunto de módulos
que podem ser usados para gerar horários e itinerários para veículos de frotas de transporte. Estes
módulos estão divididos em três ferramentas.
As ferramentas disponibilizadas por este sistema são destinadas, principalmente, para fornecedores
de transportes que já tenham alguns recursos computorizados assim como um sistema de gestão de
frotas, mas ao qual falta a capacidade de gerar automaticamente horários e itinerários.
Todos os módulos podem ser integrados com a maioria dos sistemas existentes de gestão de frotas
ou de expedição de veículos, independentemente da base de dados que usam, do sistema GIS ou da
interface de utilizador, correndo por trás de todo o sistema.
O sistema pode correr em modo manual ou automático.
Em ambos os modos, o sistema faz todos os cálculos associados ao agendamento e itinerário a
efectuar. A diferença reside no modo de expedição de veículos, que no modo automático é feito
automaticamente. No modo manual são apresentados ao operador o resumo dos cálculos
efectuados, a lista dos veículos que poderão efectuar a viagem, os horários estimados para
embarque/desembarque, o impacto que terá no horário já existente e deixa a decisão final para o
operador, tal como o veículo que irá realizar a viagem.
Para fornecedores de transporte com várias frotas, o sistema permite calcular horários combinados e
coordenados para todas as frotas, assim como calcular viagens para veículos específicos de uma ou
mais frotas baseando-se no tipo de viagem e prioridade entre frotas.
É dado ao operador o controlo sobre alguns parâmetros para cálculo dos horários, tais como a
capacidade dos veículos, os tempos dados pelos utilizadores para as viagens, tempo máximo para
transporte de um passageiro, compatibilidades entre passageiros, a permissão para um grupo de
passageiros poder ser dispersa por vários veículos ou ter que ser mantido no mesmo, etc.
O método para cálculo de distâncias pode ser Ponto a Ponto, Triangulação ou encaminhamento real
através da rede de estradas.
11
Na subsecção seguinte vai-se explicar, de uma forma resumida, os módulos deste sistema. Nas
subsecções seguintes, vai-se referir o conjunto de ferramentas que poderão ser implementadas por
este sistema, as quais fazem uso dos módulos referidos na respectiva subsecção.
Como poderá ser observado nas subseccções seguintes, este sistema aparenta ser bastante
completo, pois tem várias ferramentas que permitem satisfazer uma grande variedade dos tipos de
serviço a pedido. A possibilidade de se integrar com outros sistemas e a propriedade de poder
funcionar em background são uma grande vantagem fornecida por este sistema, embora obrigue à
existência de outro(s) sistema(s) para gerir outros serviços fornecidos pelos operadores de
transporte, tal como a gestão de frota.
Embora seja bastante completo, este tem algumas limitações. Uma delas é não fazer gestão de
utilizadores, ou seja, não guarda qualquer informação sobre os utilizadores. Além disso, não permite
o registo automático de pedidos, tendo que ser o operador do sistema a fazer o registo dos mesmos.
Outra limitação reside em a informação gerada sobre os itinerários e horários ser apenas mostrada
ao operador do sistema, tendo que ser este, ou outro sistema, a transmiti-la aos motoristas que irão
efectuar os serviços.
2.2.1.2.1. Módulos
Este sistema é constituído por um conjunto de seis módulos, os quais têm diferentes funcionalidades.
Os quatro primeiros módulos permitem que diferentes expedidores trabalhem simultaneamente no
mesmo horário ou em horários diferentes sem que haja interferência mútua.
Módulo de batch – lê um ficheiro de viagem e um ficheiro de definição de frota e gera o horário e
itinerário (para um ficheiro) para cada veículo sem a intervenção do operador. Pode também
voltar a gerar os horários e rotas devido a cancelamentos por parte dos clientes e/ou avarias de
veículos.
Módulo de inserção – realiza a inserção de uma viagem de uma forma optimizada e rápida para
um ficheiro calculado pelo módulo anterior, enquanto o cliente realiza a sua reserva via telefone.
Essa viagem pode estar endereçada para todos os veículos de uma frota, para um conjunto de
veículos de uma frota ou para um grupo de veículos de várias frotas. Todos os veículos e a sua
localização são avaliados e todas as rotas recalculadas.
Módulo de cancelamento – cancela uma viagem ou um conjunto de viagens de um veículo, a
partir de um ficheiro criado no módulo 1. Todas as viagens que sofram alteração devido ao
cancelamento são recalculadas. As viagens canceladas são colocadas na lista de viagens sem
horário ou na lista de espera desse horário, sendo mantida a informação da viagem mesmo
sendo esta cancelada.
12
Módulo de procura – procura furos no horário onde possam ser colocadas mais viagens,
permitindo negociar com o cliente os locais de origem e destino quando o seu pedido inicial não
pode ser atendido.
Módulo de cálculo de itinerário – calcula o caminho óptimo entre dois pontos de uma rede de
trânsito.
Módulo de planeamento de viagem – calcula o caminho mais curto ou mais rápido entre dois
pontos, combinando informação entre os vários tipos de meios de transporte, que um passageiro
possa seguir tendo em conta uma janela de tempo que este providencia ao módulo.
2.2.1.2.2. Vehicle Scheduling Software Tools and Route Planner12
Estas ferramentas oferecem todas as funções necessárias para adicionar a capacidade de geração
de horários e itinerários para veículos às aplicações já existentes no fornecedor de transportes. São
totalmente independentes de qualquer base de dados ou sistema de informação geográfico, podendo
ser integrado com a maioria das aplicações de gestão de frotas e transporte, sendo apenas
necessário que seja possível criar uma lista de viagens codificadas geograficamente para a carga de
viagens diárias.
2.2.1.2.3. Vehicle Routing Software Tools and Logistics Software13
Estas ferramentas oferecem um modo rápido para calcular o caminho óptimo entre dois pontos de
uma rede de estradas. Tal como as ferramentas da subsecção 2.2.1.2.2, estas ferramentas são
facilmente integráveis com a maioria dos sistemas existentes.
Quando usadas em conjunto com as ferramentas da subsecção anterior tomam em atenção os limites
de velocidade estipuladas para as estradas tomadas no percurso, proibições de sentido nos
cruzamentos e estradas e atrasos devido a congestionamento da rede de tráfego no cálculo de
itinerários e horários.
Se usadas em conjunto com sistemas de informação ao passageiro para redes de trânsito também
usam informação dos horários dos serviços fixos de autocarros, comboio e metro, e atrasos nos
pontos de transferência de passageiros para calcular um itinerário óptimo para o passageiro.
2.2.1.2.4. Trip Planning Software14
Estas ferramentas oferecem um modo rápido para calcular um itinerário óptimo para o passageiro
entre dois pontos numa rede de trânsito multimodal. Tais como as ferramentas das subsecções
anteriores, estas ferramentas são facilmente integráveis com a maioria dos sistemas existentes.
12 http://vaxxine.com/eng_soft/vehsched.html 13 http://vaxxine.com/eng_soft/vehroute.html 14 http://vaxxine.com/eng_soft/tripplan.html
13
Com as ferramentas deste módulo consegue-se calcular o melhor itinerário com o mínimo de pontos
de transferência em redes de transporte multimodais (metro, comboio, barco, etc.), avaliando todas
as combinações possíveis e tempos de viagem.
2.2.1.3. GIRO/ACCES15
GIRO/ACCES [15] é uma solução para gestão de serviços de pedidos de transporte para utilizadores
com dificuldades motoras.
Este sistema permite gerir informação do utilizador, incluindo nome, morada, necessidades do
utilizador, locais de preferência e locais cuja mobilidade não o permite frequentar. Esta informação
pode ser alterada quando se faz uma reserva.
Em relação à frota, permite controlar e monitorizar toda a informação das viagens e horários, assim
como o uso de veículos não pertencentes à frota, tendo sempre como base os que oferecem um
menor custo para efectuar o percurso pretendido. As viagens podem ter um tamanho pré-definido ou
serem criadas dinamicamente conforme a necessidade.
Os itinerários e horários são calculados automaticamente e em tempo real enquanto é feita a
reserva/pedido ou cancelamento de uma reserva efectuada previamente, tendo em conta situações
de congestionamento, restrições de trânsito e direcção da viagem.
O utilizador pode efectuar reservas, cancelamento ou confirmação das mesmas via telefone (falando
com um operador ou via serviço de voz interactivo (automático)) ou via Web, até ao dia em que
pretende realizar a viagem.
Se o sistema GIRO-HASTUS16 [16] estiver também instalado no operador, permite usar a informação
dos itinerários fixos para determinar se o utilizador que pretende usar o serviço necessita mesmo de
um serviço a pedido.
Esta solução encontra-se instalada17, por exemplo, na Sociedade de Transportes de Montreal
(Société de Tranport de Montréal) e na Comissão de Transportes de Toronto (Toronto Transit
Comission), ambas as cidades do Canadá.
Este sistema oferece grandes vantagens na gestão deste tipo de serviços, ao permitir registo
automático dos pedidos, monitorização de frota e ao guardar informação sobre o cliente, que poderá
ajudar a tratar com maior facilidade as necessidades de cada utilizador. Porém, ao estar limitado a
reservas até ao dia de início de viagem, não permitindo fazer reservas depois de a viagem se ter
iniciado, traz-lhe uma grande limitação na satisfação de todos os pedidos de serviço, pois não permite
inserção de pedidos de última hora. Por outro lado, este também não permite integração com outros
sistemas de gestão de serviços que não pertençam à mesma empresa (GIRO), o que leva aos
15 http://www.giro.ca/en/products/giro-acces/index.htm 16 http://www.giro.ca/en/products/hastus/index.htm 17 http://www.giro.ca/en/giro/index.htm
14
operadores, que intencionem utilizar este sistema integrado com outros serviços que forneçam, a
terem que instalar apenas ferramentas disponibilizadas por esta empresa.
2.2.2. Soluções no Domínio da Investigação
2.2.2.1. Sistema Checkpoint DRT
O projecto Checkpoint DRT [17] considera um serviço “híbrido” de transportes de passageiros, ou
seja, o serviço varia entre um modo tradicional de rota fixa e um modo dinâmico entre viagens para a
mesma rota.
O protótipo contempla uma interface de utilizador baseada na Web, pela qual os utilizadores poderão
fazer uma reserva de viagem para o DRT (ver Figura 2), embora esteja preparado para poder ser
implementado um sistema de reservas automático via telefone.
Figura 2.Interface Web para pedidos de viagem.
As reservas dos clientes são colocadas automaticamente no sistema de despacho. Com a informação
dada pelo cliente, o sistema oferece um conjunto de soluções (tanto dinâmicas como fixas) que
satisfaçam o seu pedido, determinando se um pedido dinâmico poderá ser servido, tendo em conta o
número mínimo de passageiros que podem ser servidos numa viagem.
Figura 3.Ecrã de reserva efectuada.
Todas as reservas feitas para o serviço dinâmico após o veículo ter atingido a sua lotação máxima,
são redireccionadas para o serviço fixo mais próximo, em termos de tempo, da reserva pretendida.
Para os pedidos que poderão ser satisfeitos, é pedido ao cliente para introduzir o número de
identificação de um bilhete (que é preparado para o efeito), realizando a reserva (ver Figura 3). Este
sistema não permite efectuar reservas para um veículo que já tenha iniciado a sua viagem.
15
Após o término das reservas para uma viagem dinâmica, ou seja, após as restrições de tempo para
se realizarem reservas de uma viagem ou pouco antes do início da viagem agendada, o sistema
calcula a rota a efectuar nessa viagem (ver Figura 4). Neste ponto é preciso ter em atenção que na
viagem dinâmica não é obrigatório o autocarro parar em todas as paragens, ou seja, apenas precisa
de passar pelas paragens em que existem reservas de viagens, o que lhe permite viajar por atalhos
entre paragens.
O cálculo da rota é simples, uma vez que as paragens da rota estão sequencialmente numeradas e o
autocarro visita cada paragem sempre em ordem ascendente ou descendente.
Antes do início da viagem, o motorista descarrega a informação necessária para a viagem para um
computador de bordo (por exemplo, um PocketPC), via comunicação sem fios. Após o início da
viagem, o sistema de navegação transmite ao motorista as informações de direcção tanto gráfica
como sonora.
Figura 4. Apresentação da rota a efectuar por um veículo.
O modelo de componentes do sistema é apresentado na Figura 5.
Figura 5. Modelo de componentes do sistema.
Esta solução usa, para efeitos de simulação, uma carreira fixa da AC Transit em Fremont, California
nos Estados Unidos da América.
Embora este seja apenas um sistema ao nível da investigação, segue uma óptima abordagem ao
centralizar a gestão de serviços fixos e flexíveis numa mesma aplicação, não sendo necessários
vários sistemas para ter coordenação dos dois tipos de serviços. A comunicação automática entre o
sistema e os motoristas é também uma vantagem, pois poupa tempo e recursos humanos para
comunicar os itinerários, facilitando a realização da viagem. O registo de pedidos automático via Web
é também uma vantagem, porém este ser o único meio de reservar uma viagem torna-o muito
limitado, pois nem todos têm acesso a esse recurso. Outras grandes limitações para o cliente são o
não poder fazer uma reserva após o veículo ter iniciado a viagem e o veículo ter um itinerário semi-
fixo, orientado às paragens.
16
2.2.2.2. Abordagem descentralizada
O sistema de abordagem descentralizada [4] tenta emparelhar utilizadores e veículos com base nas
seguintes restrições:
O cliente deseja
Minimizar o tempo de espera logo que o seu pedido seja aceite;
Chegar ao destino dentro do horário pedido.
Cada veículo tenta
Maximizar a sua taxa de ocupação, alterando um itinerário planeado para servir um novo
pedido;
Lidar com a evolução do trânsito e, especialmente, com incidentes inesperados (ruas
bloqueadas, acidentes, novas estradas) e eventos históricos (o sistema deve estar preparado
para aprender sobre eventos repetitivos para prever eventos similares no futuro);
Negociar com outros veículos de modo a escolher a melhor proposta para servir novos
pedidos.
Tal como se pode ver pela última restrição, o sistema não é centralizado mas emerge da frota de
veículos. O sistema segue uma abordagem orientada ao agente, sendo composto pelos seguintes
agentes: Veículo, Interface e Cliente.
Para se fazer uma reserva, o utilizador comunica os seus locais de partida e chegada e as janelas de
tempo respectivas, utilizando um determinado suporte de comunicação (chamada telefónica, via
Internet), sendo depois instanciado como um agente Cliente, cuja função consiste em representá-lo
no sistema. De seguida, o agente Cliente entra em interacção com o agente Interface e este último
difunde o pedido para todos os agentes Veículo. Os pedidos são processados em tempo real. Na
Figura 6 poder-se-á ver um esquema da interacção entre os diferentes agentes.
Figura 6. Diagrama de sequência UML que mostra as interacções entre os agentes do sistema.
O modelo deste sistema funciona em duas fases simultâneas, a fase de oferta e a fase de escolha.
Após o pedido ter sido realizado, os agentes Veículo negoceiam entre si qual irá aceitar o novo
pedido. Estes calculam o aumento de esforço em aceitarem o novo pedido, difundindo-o por todos os
17
outros agentes. Após a recepção de todas as respostas, compara-as com o seu resultado e retorna o
que tiver menor custo. O que for considerado mais vezes com menor custo irá servir esse pedido.
Este sistema trás uma nova perspectiva aos sistemas actuais de pedidos de serviço de transporte, ao
ter uma abordagem descentralizada onde todo o trabalho de inserção, cálculo de itinerários e horários
é dado à frota de veículos. Desta forma é possível melhorar a performance do cálculo de inserção de
passageiros de novos pedidos numa viagem, pois cada veículo apenas terá que visualizar o seu
custo em aceitar esse novo pedido, transmitindo-o aos restantes veículos da frota. Porém, este não
poderá ser completamente descentralizado na gestão dos pedidos, o que se torna numa
desvantagem, pois terá que continuar a ter um sistema central que irá receber os pedidos e transmiti-
los à frota. Porém, este sistema apenas foi testado com base em simulações sociais.
2.2.3. Comparação das soluções
Na Tabela 1 encontra-se, de uma forma resumida, uma comparação das soluções, comerciais e em
investigação descritas nesta secção. Tal como pode ser observado, existem serviços que são
comuns a todas as soluções.
Porém, tal como pode ser observado, a maioria dos sistemas aqui apresentados obriga a que haja
interacção humana, além da do utilizador cliente, para a inserção de pedidos. Por outro lado, a
maioria das soluções sofrem de falta de facilidade, ou mesmo possibilidade, de integração com outras
soluções já existentes, soluções essas que as empresas poderão já ter instaladas, obrigando a que
estas soluções funcionem à parte das outras soluções, como aquelas que são usadas para a gestão
do serviço fixo, ou que seja utilizado software do mesmo servidor de software para poder gerir estas
duas vertentes.
18
Inserç
ão
de P
ed
ido
s
Manu
al, s
em
limitaçõ
es d
e tem
po.
Manu
al, s
em
limitaçõ
es d
e tem
po.
Mis
to,
até
ao p
rópri
o
dia
.
Auto
mático,
até
à
part
ida d
o v
eíc
ulo
.
Não s
e s
abe
Gestã
o d
e
Pas
sag
eir
os
Sim
Não
Sim
Sim
Não s
e s
abe
Aju
ste
de S
erv
iço
s
em
Tem
po
Re
al
Sim
Sim
Sim
Não
Sim
Mo
nit
ori
zação
de F
rota
Sim
Não
Sim
Sim
Não
Gera
ção
Au
tom
áti
ca
Horá
rios
Sim
Sim
Sim
Sim
Sim
Itin
erá
rios
Sim
Sim
Sim
Sim
Sim
Inte
grá
vel
Não
Sim
Não
Não
18
Não
So
lução
2.2
.1.1
.
2.2
.1.2
.
2.2
.1.3
.
2.2
.2.1
.
2.2
.2.2
.
Tabela 1. Comparação das soluções descritas.
18 O sistema já gere tanto os serviços fixos como flexíveis
19
3. Sistema Proposto
Tal como referido anteriormente, para atingir o objectivo deste trabalho pretende-se desenhar e
implementar um protótipo para gestão de serviços flexíveis, em tempo real e de forma automática,
integrada com soluções de serviço fixo.
Na secção anterior (secção 2), onde é analisado o estado da arte, foi possível verificar que já existem
muitas aplicações e estudos que abordam esta temática. Porém, todas as soluções estudadas
obrigam a que exista uma interacção humana, além da do cliente, na realização de pedidos de
viagem. Por outro lado, todas as soluções estudadas mostram que não existe uma integração entre
os serviços fixos e os serviços flexíveis, o que não permite, quando possível, encaminhar pedidos que
não sejam possíveis de satisfazer em serviço flexível para os serviços fixos.
Devido à abrangência de problemas existentes neste tema, a solução proposta para este trabalho
prende-se apenas em encontrar uma solução que automatize a realização e recepção dos pedidos de
transporte entre dois locais assim como o cálculo dinâmico de viagens e horários relativos aos
pedidos efectuados e a integração do serviço flexível com o serviço fixo.
A arquitectura funcional deste tipo de solução deverá passar por algo como a apresentada na Figura
7. Tal como se pode ver nessa figura, existem três partes distintas pelas quais a solução se divide:
solução para o cliente, solução para a/o viatura/motorista. Cada componente do sistema corresponde
a um bloco, o qual será colorido de verde, laranja ou azul. Os componentes a verde correspondem a
componentes que não existem no sistema e irão ser implementados neste trabalho. Os componentes
a azul correspondem aos que já existem no sistema. Os componentes a laranja, correspondem a
componentes que não existem no sistema mas que seriam aconselháveis existir na solução final,
porém, devido a fugirem ao âmbito proposto neste trabalho, não irão ser implementados.
A solução para o cliente terá de suportar os pedidos de reservas de viagem dos clientes e deverá
responder a esse pedido, tanto afirmativamente como negativamente. Por outro lado, a solução
também deverá permitir que o cliente possa anular o seu pedido de reserva. Esta solução deverá
passar por permitir que o cliente faça a sua reserva ou anulação de reserva via telefone (voz ou
SMS), via internet e via correio electrónico.
O âmbito deste trabalho será apenas prototipar uma solução de gestão de pedidos de transporte,
porém o aconselhável, para a solução internet, seria criar um portal onde os clientes se registariam e,
após o seu registo ter sido aprovado, obteriam um número de cliente com o qual poderiam fazer as
suas reservas. Na solução via telefone seria também interessante a existência de um registo, o qual,
no caso de ainda não estar registado via portal, poderia ser feito via telefone; na situação de pedido
via voz, a solução poderia passar por ter alguém que atendesse o pedido e o registasse, e na
situação de SMS este deveria ser registado automaticamente no sistema.
20
O cliente, para fazer a sua reserva, deverá indicar os locais de embarque e de desembarque
pretendidos, assim como a hora a partir da qual pretende iniciar viagem e uma hora máxima a que
pretende chegar ao seu destino.
Figura 7. Arquitectura funcional da solução pretendida.
21
A solução para a central funcionará como gestor entre cliente e motorista.
O sistema deverá receber um pedido do cliente, calcular a possibilidade de este poder ser satisfeito,
verificando se existe alguma viatura que permita receber esse pedido sem ultrapassar os limites de
tempo dos pedidos que se encontram a ser satisfeitos, assim como se a adição desse pedido é
lucrativo. Esta verificação será feita a partir da informação que os veículos vão enviando à central.
Em caso dessas condições serem satisfeitas, deverá enviar resposta ao cliente informando-o que o
seu pedido será satisfeito e a janela de tempo em que este passará no local de embarque. Em caso
negativo, deverá verificar se existe um serviço fixo que satisfaça quase totalmente o pedido efectuado
para o cliente; se esse for o caso, deverá enviar resposta ao cliente, pedindo desculpas por não
poder satisfazer o seu pedido no horário pretendido mas que existe serviço fixo que poderá satisfazer
o seu pedido, e em caso contrário apenas informá-lo que o seu pedido não pode ser satisfeito
naquele momento.
No caso de poder satisfazer o pedido efectuado pelo cliente, deverá calcular nova rota para o
autocarro onde este vai ser inserido, assim como os novos horários, e enviar esta informação ao
motorista.
Deste modo, a central deverá gerir os pedidos feitos pelos clientes, recebendo-os, calcular a
possibilidade de satisfação dos mesmos e enviar resposta. Deverá, também, ser capaz de gerir a
informação que irá enviar ao motorista sobre os pedidos que este terá que satisfazer.
A implementação desta solução irá seguir a arquitectura tecnológica definida na Figura 8.
Servidor aplicacional
da aplicação da central
Servidor aplicacional
da aplicação do cliente
SMS Gateway Servidor de Correio Electrónico
Solução do Cliente
Solução da Central
Computador de acesso.
Base de dados da
Aplicação do cliente
Base de dados
da aplicação da central
HTTP
HTTP POP
SMTP
Resposta ao pedido
Envio dos dados do pedido
Figura 8. Arquitectura tecnológica da solução desenvolvida.
22
A solução final deverá ter suporte ao motorista, a partir do qual este possa saber o estado dos seus
pedidos em tempo real, tais como locais de embarque e desembarque, número e identificação dos
passageiros que terá que apanhar/largar, horários pretendidos pelos clientes e o melhor itinerário a
percorrer para satisfazer os pedidos.
Esta solução também deverá enviar informação à central para que esta possa saber a localização do
veículo, a lotação do mesmo e faltas de comparência dos utilizadores no local e na hora pedidos por
ele.
Em termos de tecnologia, a solução passará por um sistema PDA ou um computador de bordo, pelo
qual o motorista pede informação à central sobre os pedidos que terá que satisfazer, assim como um
sistema de GPS que o guiará pelo melhor itinerário, de modo a cumprir os horários e passe por todos
os locais de embarque/desembarque.
A solução para o motorista é considerada como trabalho futuro, pois, embora tenha um papel
importante na solução final, não se enquadra na problemática que se pretende resolver, automatizar
o registo e cálculo de horários e percursos e integração com o serviço fixo
23
4. Implementação da solução de BoD
Neste capítulo irão ser descritas as etapas que foram necessárias ao desenvolvimento do protótipo
proposto, falando o que foi efectuado em cada componente referido anteriormente (ver Figura 7).
4.1. Solução para o cliente
A implementação da solução para o cliente foi integrada no sistema SIMIP (Sistema Integrado de
Mensagens de Informação ao Passageiro), sendo para isso criado um novo módulo neste sistema
para suportar as mensagens de pedido e cancelamento de reservas de BoD. O SIMIP é um mediador
entre serviços prestadores de informação, como o caso do sistema de informação de horários de
paragem, e utilizadores clientes. Desta forma, os clientes obtêm informação, transformada e obtida
pelo SIMIP aos prestadores de informação, que é disponibilizada pelo SIMIP através de diferentes
canais, como é o caso do correio electrónico e SMS.
Uma vez que esta solução foi criada como um módulo de uma solução já existente, foi necessário
restringir-se a sua implementação às tecnologias aí usadas. Desta forma, a solução foi implementada
usando a linguagem Java, sobre uma plataforma J2EE e a correr num servidor JBoss.
A solução permite que o cliente faça pedidos de reserva de viagens BoD via SMS e via correio
electrónico. Ambas as situações irão ser descritas nas secções seguintes.
Todas as comunicações realizadas entre este sistema e o sistema da central vão ser explicadas mais
à frente.
4.1.1. Modelo de dados
Como foi referido anteriormente, esta solução foi integrada com o sistema SIMIP. Como tal o seu
modelo de dados foi aproveitado tendo sido apenas adicionado uma nova tabela para poder ser
adaptado aos novos requisitos. Neste ponto apenas se irá referir que alterações foram feitas ao
modelo de dados de recepção e envio de mensagens, tendo sido descartados todos os objectos
relativos a configurações do sistema.
simiprequest
PK timestamp
PK msisdn
PK adapter
PK service
request
response
requesttime
responsetime
processed
extendedservice
sibodresponse
PK,FK1 timestamp
PK,FK1 msisdn
PK,FK1 adapter
PK,FK1 service
PK requestid
response
processed
Legenda:_ Já existente_ Criada
Figura 9. Modelo de dados usado para guardar os dados das mensagens trocadas no sistema para o cliente.
24
Esta nova tabela, à qual se chamou sibodresponse, vai servir para guardar os dados das mensagens
que terão proveniência do sistema para a central após os pedidos de reserva terem sido guardados
nesse sistema. A sua existência prende-se na questão de nos pedidos de reserva serem enviadas
duas respostas ao cliente, uma após o pedido ter sido registado no sistema para a central e outra
após o processamento do mesmo.
Assim, após o pedido ter sido registado no sistema para a central, o número de registo do pedido de
reserva (requestid), conjuntamente com os dados únicos guardados no objecto simiprequest, serão
guardados nesta nova tabela. Desta forma será possível reencaminhar a mensagem de resposta do
processamento do pedido para o cliente, sendo marcado como ainda não tendo sido processado
(processed). Após receber a resposta de processamento, proveniente do sistema para a central, esta
é aqui guardada (response) e o pedido é marcado como processado.
Tal como pode ser observado na Figura 9, o objecto simiprequest é constituído por vários campos. A
sua chave primária é constituída pôr um valor que corresponde ao tempo exacto em que foi efectuado
o registo da mensagem no sistema (timestamp), o número de telemóvel ou endereço de correio
electrónico de onde provém a mensagem (msisdn), o adaptador de onde provém a mensagem
(correio electrónico ou SMS) (adapter) e o código do operador que disponibiliza o serviço (service).
Nesta tabela é também guardado o conteúdo da mensagem enviada pelo cliente (request), a data de
realização do pedido (requesttime), o seu estado de processamento (processed), a resposta enviada
ao cliente (response), a data de envio da resposta (responsetime) e a que serviço foi realizado o
pedido (extendedservice).
4.1.2. Formato das mensagens
As mensagens que o cliente deve enviar têm um formato predefinido, de modo a poderem ser
reconhecidas e processadas pelo sistema.
Assim a mensagem de reserva deve ser constituída pelo seguinte texto: <código do operador> BOD
R <número paragem de embarque> <horário mínimo> <número paragem de desembarque> <horário
máximo>. Cada campo tem um significado e um modo de preenchimento:
<código do operador> – código do operador que disponibiliza o serviço;
BOD – código do serviço, sendo, neste caso, o serviço de BoD;
R – código do tipo de acção pretendida para o serviço de BoD, que neste caso o R
representa “reserva”;
<número paragem de embarque> – número da paragem onde o cliente pretende iniciar a
viagem;
<horário mínimo> – hora mínima a que o cliente pretende iniciar a viagem no local definido no
ponto anterior. Este horário representa que o autocarro apenas deverá apanhar o cliente a
partir da hora pretendida e nunca antes;
25
<número paragem de desembarque> – número da paragem onde o cliente pretende terminar
a viagem;
<horário máximo> – hora máxima a que o cliente pretende terminar a viagem no local definido
no ponto anterior. Este horário representa que o autocarro não deverá chegar ao destino
após a hora pretendida.
O valor que os campos em que se define o número de paragem podem assumir depende das
paragens definidas pelo operador do serviço, devendo ser disponibilizados para consulta.
Os campos que devem ser preenchidos com horários devem estar no formato „aaaammddHHMM‟,
em que „aaaa‟ simboliza o ano, „mm‟ o mês, „dd‟ o dia, „HH‟ a hora, no formato 24 horas, e „MM‟ os
minutos.
Na situação em que o cliente pretende cancelar uma reserva efectuada anteriormente, deverá enviar
o seguinte texto: <código do operador> BOD C <número do pedido>. Os três primeiros campos
representam o mesmo que no tipo de mensagem anterior, embora o terceiro campo seja preenchido
com a letra „C‟ que representa a acção de cancelamento. O quarto campo representa o número do
pedido que é enviado ao cliente quando o pedido entra no sistema, sendo descrito na secção 4.2.2.
de onde provem esse valor.
4.1.3. Pedidos via SMS e Correio Electrónico
Tendo em conta o formato de mensagens definido na secção anterior, o cliente tem duas formas para
fazer o pedido: SMS e correio electrónico.
Quando o cliente pretende fazer um pedido via SMS deverá enviar uma mensagem cujo corpo é
constituído pelo texto definido no ponto anterior. Assim que o cliente envia a mensagem, esta segue
para um gateway SMS que reencaminha a mesma para o sistema, sendo a comunicação realizada
via HTPP. Desta forma, o gateway realiza um HTTP POST ao sistema, sendo o URL constituído
pelos seguintes campos:
http://SimipHTTPServer:<porta>/SMS?MSISDN=<Nº de Telemóvel>&REQUEST=<Texto do Pedido>.
Quando o cliente pretende fazer um pedido via correio electrónico deverá enviar uma mensagem de
correio electrónico cujo campo “assunto” deverá ser constituído pelo mesmo texto definido no ponto
anterior. Assim que o cliente envia a mensagem esta segue para um servidor de correio electrónico.
Como existe implementado no sistema um adaptador de correio electrónico, este vai aceder ao
servidor de correio electrónico via POP3 retirando de lá os pedidos efectuados pelos clientes.
4.1.4. Tratamento dos pedidos recebidos
Após a recepção dos pedidos efectuados por um dos canais descritos anteriormente, o sistema irá
tratar as mensagens recebidas. Em qualquer dos canais pelo qual o sistema recebe o pedido, o
26
processamento vai ser semelhante, sendo apenas diferente a forma como retira a mensagem do
pedido.
No caso do pedido ter sido efectuado por SMS, este é enviado para o sistema via HTTP POST. Desta
forma o sistema vai processar o URL enviado pelo gateway SMS, retirando do URL o ID do pedido
(parâmetro REQUESTID), o número de telemóvel pelo qual foi efectuado o pedido (parâmetro
MSISDN) e a mensagem enviada no pedido (parâmetro REQUEST). No caso do pedido ter sido
enviado via correio electrónico, o sistema, após ter ido buscar a mensagem de correio electrónico ao
servidor, como é descrito na secção anterior, vai retirar a mensagem ao campo “Assunto” da
mensagem e o endereço de correio electrónico ao campo “De”.
Assim que a mensagem chega ao sistema, a primeira tarefa que é realizada é a de dividir a
mensagem em duas partes, o código do operador e os restantes parâmetros. De seguida, o pedido é
guardado na base de dados, onde são guardados o código do operador, o tipo de canal de onde o
pedido provem, o número de telemóvel ou o endereço de correio electrónico, dependendo do canal
de envio, os parâmetros do pedido e a data a que o pedido foi efectuado.
De seguida os parâmetros são retirados da mensagem e é verificado o código de serviço, sendo que,
neste caso em particular, está-se perante o serviço de BoD. Sabendo-se o serviço que se pretende
satisfazer falta saber qual a acção que se pretende realizar neste serviço, correspondente ao terceiro
parâmetro da mensagem.
No âmbito deste trabalho foram apenas considerados dois tipos de acção, a acção de reserva de
viagem e a acção de cancelamento de pedido/viagem. O tratamento destas duas situações vai ser
descrito nos próximos pontos.
4.1.4.1. Pedido de Reserva
A acção do tipo reserva é caracterizada pelo código com a letra “R” na mensagem.
Para poupar pedidos à central, no sistema para o cliente apenas são efectuadas as validações sobre
as datas. Primeiro é verificado se as datas do pedido de reserva são superiores à data actual, sendo
enviada, em caso negativo, uma mensagem ao cliente transmitindo que a data de pedido tem que ser
superior à data actual. Se o resultado da validação for positivo, então o sistema vai validar se a data
do pedido de chegada ao destino é superior à data do pedido de partida da origem. Se o resultado
desta validação for negativo, o sistema enviará uma mensagem ao cliente transmitindo que a data de
chegada tem que ser superior à data de partida. Se o resultado for positivo então o pedido é enviado
para o sistema da central.
Na central vão ser realizadas mais duas validações, a de existência de cliente e a de existência de
paragens. Sendo assim, a resposta ao cliente vai depender se o resultado destas validações for
positivo ou negativo.
27
No caso de o resultado da validação de cliente ser negativo, o sistema da central irá transmitir para
este sistema esse resultado. Ao receber a resposta, o sistema cria uma mensagem de resposta ao
cliente onde transmite que o pedido não pode ser guardado pois não existe nenhum cliente com o
número de telemóvel ou endereço de correio electrónico correspondente ao do pedido.
Se o resultado da validação de paragens for negativo, o sistema da central irá transmitir a este
sistema esse resultado. Tendo conhecimento desse resultado, o sistema irá criar uma mensagem de
resposta ao cliente onde transmite que não existe paragem registada no sistema com o código
pedido.
Por fim, se todas as validações tiverem resultado positivo, o sistema central irá guardar o pedido (ver
secção 4.2.4), enviando para este sistema o número de registo do pedido. Este sistema irá criar uma
mensagem que irá enviar ao cliente onde transmite que o pedido foi guardado com esse número de
registo. Esse número de registo irá permitir ao cliente saber o estado de processamento do seu
pedido e, no caso de assim o pretender, fazer o seu cancelamento.
Após o pedido ter sido processado pelo sistema da central é enviada uma mensagem para este
sistema. No caso de o pedido ter sido reservado num serviço dinâmico essa mensagem irá conter os
valores de datas de embarque e desembarque previstos para satisfação do pedido, os locais de
embarque e desembarque e o veículo em que o cliente se deslocará. Com esta informação irá ser
criada uma mensagem de resposta que irá ser enviada ao cliente.
Se o pedido não tiver sido reservado num serviço dinâmico existem duas possibilidades: ou o pedido
não pode ser satisfeito ou pode ser satisfeito recorrendo aos serviços fixos existentes. No caso de o
pedido ser satisfeito nos serviços fixos, a mensagem de resposta proveniente do sistema da central
trará uma lista de datas de embarque e desembarque, uma lista de locais de embarque e
desembarque e uma lista de veículos em que o cliente se poderá deslocar no caso de optar por esta
solução. Os valores de cada lista encontram-se ordenados por veículo, ou seja, o primeiro valor de
cada lista corresponde ao primeiro veículo da lista de veículos. Com esta informação é criada uma
mensagem para o cliente contendo os serviços fixos possíveis para satisfazer o pedido. Se o pedido
não pode ser satisfeito em nenhum dos serviços, então é criada uma mensagem para o cliente
comunicando-lhe que o pedido não pode ser satisfeito.
4.1.4.2. Pedido de Cancelamento
A acção do tipo cancelamento é caracterizada pelo código com a letra “C” na mensagem.
O tratamento deste tipo de acção é mais simples que o anterior, pois o único parâmetro que é
necessário é o do número de registo. Deste modo, o sistema vai apenas enviar um pedido de
cancelamento do pedido, com o número de registo enviado na mensagem, para o sistema da central.
Após a recepção do pedido de cancelamento no sistema da central, são efectuadas duas validações.
A validação de existência de cliente e a validação da existência do par cliente/número de registo. No
28
caso do resultado das duas validações ser positivo, o registo é cancelado, assim como as viagens a
ele inerentes, no caso de existirem, e é enviada uma resposta de sucesso para este sistema. De
seguida, este sistema prepara uma mensagem de confirmação de registo cancelado e envia-a para o
cliente.
No caso de uma das validações falhar, é enviada uma resposta de insucesso para este sistema,
comunicando qual a falha inerente. Dependendo da falha de validação, este sistema prepara e envia
uma mensagem para o cliente, comunicando que não foi possível fazer o cancelamento da reserva e
a razão dessa impossibilidade. No caso de inexistência de cliente, comunica ao cliente que não existe
cliente registado no sistema com aquele número de telemóvel ou endereço correio electrónico. No
caso de não existir registo de reserva com aquele número, ou par cliente/número de registo de
reserva, cria e envia uma mensagem ao cliente comunicando que não existe nenhum registo de
reserva com aquele número para aquele cliente.
4.2. Solução para a central
Esta solução foi implementada sobre o sistema SIGO (Sistema Integrado de Gestão das Operações),
tendo sido criado um novo módulo para a suportar. O sistema SIGO gere a informação da
organização de forma integrada e em tempo real, garantindo as comunicações com as diferentes
áreas e sistemas centrais da organização. Este sistema está focada nas áreas da manutenção e
exploração, sendo composto por três subsistemas: Sistema de Gestão de Ocorrências, Sistema de
Gestão da Exploração de Serviços e Sistema de Gestão da Manutenção.
Ao criar um novo módulo, é possível transportar a solução para outros sistemas, sendo necessário
um mínimo de esforço para conseguir a sua integração. Foi também aproveitado o modelo de dados
da solução, tendo o mesmo sido estendido para aprovisionar as novas entidades necessárias para a
construção do sistema BoD.
Tendo em conta que o protótipo da solução corre como um módulo do sistema SIGO, e pela mesmas
razões da solução para o cliente, esta foi implementada usando a linguagem Java, sobre uma
plataforma J2EE e a correr num servidor JBoss. Por questões de portabilidade entre sistemas, a
solução foi implementada como uma aplicação baseada na web, o que permite que esta corra em
qualquer ambiente que contenha um web browser.
A solução para a central é o ponto central da solução desenhada. Os pedidos efectuados pelos
clientes serão reencaminhados para esta solução sendo posteriormente tratados, como se poderá ver
nas secções seguintes.
Será neste componente que os pedidos de reserva que sejam efectuados via chamada de voz serão
inseridos no sistema, sendo também aqui que irão ser efectuadas as verificações de existência das
paragens requisitadas pelos clientes e calculadas as rotas e horários dos pedidos efectuados.
29
Nas secções seguintes irão ser descritos o modelo de dados relativo a esta solução, assim como os
componentes que a constituem.
4.2.1. Modelo de Dados
Tal como foi dito anteriormente, a solução implementada encontra-se integrada na solução SIGO.
Como tal, foi aproveitado o seu modelo de dados, tendo o mesmo sido estendido para integrar a
solução BoD. Na Figura 10 pode-se ver o modelo de dados usado nesta solução. Tal como é descrito
na legenda, as entidades que constituem o modelo de dados da solução estão divididas em quatro
cores: a preto encontram-se as entidades usadas e que já se encontravam implementadas, a verde
as entidades criadas para a solução BoD, a azul as entidades já existentes mas que foram alteradas
e a amarelo as entidades criadas mas cuja função não foi utilizada na solução implementada, uma
vez que foram criadas a pensar em trabalho futuro.
Nesta secção ir-se-á explicar de uma forma sucinta o modelo de dados, uma vez que ao longo das
próximas secções as entidades referentes às mesmas irão ser abordadas de uma forma mais
específica.
Todos os pedidos de reserva foram considerados eventos que surgem no sistema, sendo por isso
registados na entidade CORE_EVENT. Para diferenciar estes eventos dos já existentes foi
adicionado um novo tipo de evento, o evento “BoD”, à entidade CORE_EVENTSUBTYPE. Para
considerar os vários estados em que um pedido se pode encontrar foram adicionados quatro novos
estados na entidade CORE_EVENTSTATE: “Registado”, “Em processamento”, “Reservado” e
“Cancelado”.
Como no modelo original não existia a entidade cliente pois não existia a necessidade de clientes
registados no sistema, foi criada a entidade SIGO_CLIENT, que estende da entidade SIGO_ENTITY
onde se encontram os dados gerais e comuns às entidades registadas no sistema, para efectuar o
registo de um cliente no sistema. Tendo em conta que um pedido tem de ter associado um cliente, à
entidade CORE_EVENT foi adicionado o campo ClientID que deverá ser preenchido com o ID do
cliente que efectua o pedido de reserva. As datas de início e fim pretendidas para embarque e
desembarque deverão ser preenchidas nos campos “StarDateTime” e “EndDateTime”,
respectivamente, da entidade CORE_EVENT.
Como cada pedido de reserva tem dois locais associados, um de embarque e outro de desembarque,
foi criada a entidade SIGO_EVENTPLACE que vai guardar os locais de embarque e desembarque
associados ao pedido, sendo que o local de embarque tem associado o número um à sua ordem e o
de desembarque o número dois.
Os locais de paragem encontram-se definidos na entidade CORE_PLACE e podem estar associados
a uma região e a um tipo de serviço. Desta forma é possível definir para o mesmo local várias regiões
(CORE_REGION) e vários tipos de serviço (SIGO_SERVICETYPE). No caso deste sistema, os locais
criados encontram-se todos definidos com um tipo de serviço “BoD” e cada local corresponde a uma
30
região isolada do tipo “ponto” (definido na entidade CORE_REGIONTYPE). Cada região tem
associadas a si coordenadas georreferenciadas (entidade SIGO_COORDENATES), sendo que no
caso de regiões do tipo “ponto” apenas tem definido uma coordenada que corresponde à posição do
local de paragem.
Figura 10. Modelo de dados usado para a implementação da solução da central.
31
Devido à necessidade de se saber as distâncias entre locais foi criada a entidade
SIGO_PLACEDISTANCE a qual guarda a distância que é necessário percorrer entre dois locais e
que mais tarde irá servir para calcular os tempos de viagem programados.
Após o processamento dos pedidos são criadas viagens (CORE_TRIP), que incluiem os tempos de
início e fim da mesma e a relação tempo planeado/tempo real, que se relaciona com a carreira
(SIGO_LINE) e o serviço público de transportes (SIGO_PTSERVICE) correspondentes. A cada
viagem criada estão associados dois locais, o de início e de fim, assim como o número de lugares
livres no veículo após a passagem pelos mesmos (ver a entidade SIGO_TRIPLINE).
A cada carreira é associado um percurso definido por pelo menos um segmento (entidade
CORE_SEGMENT) e esse por pelo menos um local. A ordem com que os locais são dispostos no(s)
segmento(s) é definido pelo atributo OrderNr da entidade relação CORE_SEGMENTPLACE. A junção
de vários segmentos irá formar um itinerário (entidade SIGO_ROUTE). Estas entidades servirão para
o desenho dos itinerários dos veículos na vista em diagrama na secção 4.2.5.3.
Os serviços BoD serão considerados serviços diários (entidade SIGO_DAILYSERVICE), sendo então
possível associar a um pedido o serviço correspondente a partir da entidade relação
SIGO_EVENTVEHICLE onde é também associado um veículo que corresponderá ao veículo que irá
satisfazer o pedido. A cada pedido satisfeito irão também ser associadas as entidades relação
SIGO_TRIPLINE correspondentes aos locais pedidos e respectivas viagens que irão satisfazer o
pedido.
Todos os dados relativos a configurações do sistema, tais como valores constantes, serão inseridos
na entidade CORE_CONFIG.
A pensar em trabalho futuro foram também criadas as entidades marcadas a amarelo de modo a
permitir que no momento da reserva seja possível escolher as características do lugar onde se
pretende ir sentado na realização da viagem.
4.2.2. Gestor de Clientes
O componente de gestão de clientes tem como principal função gerir os clientes registados no serviço
de BoD. Este componente serve para tentar evitar pedidos fraudulentos, ou seja, diminuir a recepção
de pedidos “fantasma”, onde a reserva é efectuada mas ninguém aparece no ponto de embarque
para efectuar a viagem.
Na Figura 11 pode ser observado o modelo de dados que representa o cliente na base de dados.
Como pode ser observado, para representar o cliente na base de dados associou-se à entidade
CORE_ENTITY, a qual já existia no modelo de dados do sistema SIGO, uma nova entidade
(CLIENT). Desta forma é possível ter os dados gerais de uma entidade do sistema armazenados num
mesmo local, enquanto que os dados respectivos de uma entidade de certo tipo, como é o caso do
cliente, se encontram apenas definidos numa tabela específica.
32
De modo a poder-se filtrar a informação respectiva dos clientes na entidade relacional
CORE_ENTITY, foi criado um novo dado na entidade relacional CORE_ENTITYTYPE que representa
o cliente. A entidade relacional CORE_ENTITYCLASS, a qual já estava definida no sistema, tem
como função definir grupos de entidades do sistema, optimizando procuras à base de dados.
Figura 11. Modelo de dados para definição de um cliente no sistema.
Este componente encontra-se dividido em duas partes: registo, procura e edição de clientes e
verificação de cliente registado para efectuar reservas, as quais irão ser explicadas de forma mais
detalhada nas secções seguintes.
4.2.2.1. Registo, Procura e Edição de Clientes
Para se poder proceder à verificação de clientes registados no sistema é necessário poder-se fazer o
seu registo no mesmo. Foi nesse seguimento que foram criadas as funcionalidades de registo, edição
e procura de clientes. Estas funcionalidades do Gestor de Clientes permitem que seja efectuado o
registo de novos clientes no sistema, a sua procura e posterior edição dos seus dados, permitindo
manter os dados sempre actualizados.
Figura 12. Ecrã de registo de um novo cliente.
Para permitir o registo de um novo cliente no sistema foi criado um ecrã com um formulário de registo
onde um utilizador do sistema da central, com permissões para efectuar esta operação, poderá inserir
os dados de um cliente (ver Figura 12). Após o preenchimento dos campos obrigatórios, o utilizador
poderá submeter o formulário que, se no processamento dos dados não surgir qualquer erro, irá
33
reencaminhar o utilizador para um novo ecrã onde surgirá toda a informação do cliente, incluindo o
número de cliente associado, acompanhado de uma mensagem de sucesso (ver Figura 13).
Figura 13. Ecrã de cliente registado com sucesso.
Quando se efectua o registo de um novo cliente no sistema, é preciso ter em conta quais as
condições que são necessárias satisfazer para a sua criação ser possível. Quando um cliente
pretende efectuar pedidos via SMS e correio electrónico necessita ter associado ao seu registo pelo
menos um número de telemóvel e um endereço de correio electrónico. Tendo em conta o modo como
é processada a verificação de clientes, que irá ser explicada na secção seguinte, todos os clientes
que se encontrem registados no sistema têm de ter um número de telemóvel e um endereço de
correio electrónico únicos. No caso de existir um cliente registado no sistema com um número de
telemóvel ou endereço de correio electrónico igual ao inserido no formulário de registo, o sistema irá
retornar para a página de registo acompanhado de uma mensagem de erro informativa.
Figura 14. Ecrã de pesquisa de clientes.
Após a introdução de um cliente no sistema é possível aceder aos seus dados a partir de um ecrã de
pesquisa criado para esse fim (ver Figura 14). A partir deste ecrã é possível pesquisar pelos clientes
34
a partir de um filtro que é preenchido a partir do formulário (ver parte superior da Figura 14). Após a
submissão do formulário é mostrada uma listagem com todos os clientes que correspondem à
filtragem introduzida (ver parte inferior da Figura 14).
Cada linha da listagem corresponde a um cliente. Ao carregar sobre o número de um dado cliente é
aberto um ecrã com os dados desse cliente (ver Figura 15). A partir deste ecrã é possível chegar ao
ecrã de edição de dados do cliente (ver Figura 16), tornando possível actualizar os dados relativos a
um cliente.
Figura 15. Ecrã de visualização do registo do cliente.
Figura 16. Ecrã de edição dos dados de registo de um cliente
No ecrã de edição de cliente, que difere ao de criação devido à existência do número de cliente no
início da página, é possível alterar todos os dados do cliente, à excepção do número de cliente. Desta
forma, sempre que um cliente mudar de residência ou de contactos, quer telefónicos quer de correio
electrónico, é possível alterar essa informação no sistema.
4.2.2.2. Verificação de Cliente Registado
A função principal do Gestor de Clientes no sistema de BoD é a de verificar se um dado pedido
deverá ser processado ou não devido à existência ou não do suposto cliente que acompanha o
pedido.
A verificação do registo de um cliente é realizada automaticamente na recepção/inserção de um
pedido. No caso da inserção de um pedido por um utilizador do sistema, função que irá ser abordada
mais à frente neste documento (secção 4.2.4.1), esta verificação é realizada na submissão do pedido,
verificando se o número de cliente introduzido corresponde ao de um utilizador que esteja registado
no sistema.
Quando o pedido é proveniente de mensagem SMS, uma vez que não é solicitado o número de
cliente no envio da mensagem, o sistema irá procurar se existe algum cliente registado com o número
de telemóvel do qual proveio o pedido.
35
Se o pedido é proveniente de mensagem de correio electrónico, e, tal como acontece no caso de
mensagens SMS, como não é solicitado o número de cliente no seu envio, ao receber o pedido o
sistema irá procurar se existe algum cliente registado no sistema cujo endereço de correio electrónico
coincida com o endereço de correio electrónico de onde a mensagem de pedido é proveniente.
Só após a verificação de existência de cliente ter sido efectuada, e o seu resultado informar que o
cliente existe e está registado no sistema, é que o pedido recebido irá ser introduzido no sistema para
posterior processamento.
4.2.3. Gestor de Paragens
O protótipo desenhado e implementado pretende ir ao encontro do quarto nível de operação dos
serviços on-demand, ou seja, pretende ter itinerários e horários completamente flexíveis. É neste
contexto que aparece o Gestor de Paragens, pois, embora os itinerários e os horários sejam flexíveis,
os locais de paragem possíveis para realização das reservas de viagem encontram-se já
estabelecidos.
Figura 17. Modelo de Dados representativo da definição de um local de paragem.
Tal como pode ser observado na Figura 17, que mostra o modelo de dados utilizado para definir um
local de paragem, foram utilizadas sete entidades para representar um local.
As entidades CORE_COORDENATES, CORE_REGION e CORE_REGIONTYPE foram
reaproveitadas de [18], embora tenham ligeiras diferenças. Este reaproveitamento deveu-se ao facto
de se pretender dar à solução a possibilidade de integração com os serviços fixos de transporte de
passageiros.
A entidade CORE_PLACE simboliza o local de paragem, sendo constituída por um código, que na
solução representa o código utilizado na reserva de viagem, uma descrição, que poderá ser o nome
da paragem, a morada de localização da paragem e um parâmetro (Active) que representa se o local
está activo.
Cada local está associado a uma ou mais regiões (entidade CORE_REGION) que podem ser de
determinado tipo (entidade CORE_REGIONTYPE), permitindo assim que um local seja apenas um
36
ponto, ou pertencer a uma região definida no espaço. A associação entre um local e as regiões é feita
a partir da entidade CORE_PLACEREGION, pois um local poderá apenas ser um ponto como
pertencer a uma região definida, sendo também associado a um tipo de serviço, dando desta forma a
possibilidade de um local poder ser utilizado na definição de um serviço fixo ou de um serviço
dinâmico.
Uma região está delimitada a partir das coordenadas geográficas que a compõe (entidade
CORE_COORDENATE), sendo que uma região definida como um ponto (representando apenas um
local de paragem) apenas terá uma coordenada geográfica a defini-la, enquanto que uma região
delimitada por vários pontos terá várias coordenadas, que estarão ordenadas a partir do parâmetro
OrderNr.
Todos os locais de paragem utilizados no serviço flexível terão de ter a distância aproximada entre
eles definida na entidade SIGO_PLACEDISTANCE. Esta definição é necessária para realizar os
cálculos da duração aproximada da viagem entre dois locais no serviço flexível, sabendo-se, deste
modo, se irá ser possível satisfazer o pedido do cliente.
4.2.3.1. Registo, Procura e Edição de Locais de Paragem
Os pedidos de reserva são efectuados com base entre dois locais de paragem, um de origem e outro
de destino. No sistema concebido foi considerado que os locais de possível paragem estariam
previamente definidos, havendo a possibilidade de se adicionarem novos locais. Deste modo, pode-
se evitar que existam viagens em que os locais de paragem são muito próximos, levando a que a
velocidade média a que os veículos circulam seja menor, e, consequentemente, o tempo de viagem
do cliente seja maior.
De modo a possibilitar a inserção de novas paragens no sistema, foi criado um ecrã para o efeito (ver
Figura 18). Para um utilizador criar uma nova paragem nesse ecrã necessita preencher os campos do
formulário que se encontram marcados com um asterisco (*).
Devido à dificuldade em se saber alguns dos dados, foram criadas opções que facilitam o
preenchimento dos mesmos. No caso de o utilizador não saber as coordenadas de um determinado
local, ao preencher o campo “Morada” é activado o botão “Obter Coordenadas”, que ao carregar irá
abrir o mapa com os pontos correspondentes a essa morada marcados por um pino. Ao seleccionar
um dos pinos os campos das coordenadas desse local ficarão automaticamente preenchidos. Como
pode ocorrer o caso de o pino não se encontrar exactamente sobre o local pretendido, é também
possível deslocar o pino para onde se pretende, e ao carregar sobre ele são actualizados os campos
das coordenadas e da morada.
Porém, se o utilizador souber as coordenadas, ao preenchê-las são activados os botões de “Ver no
Mapa” e “Obter Morada”. Ao carregar sobre o botão “Ver no Mapa” é apresentado um mapa com o
local correspondente a essas coordenadas marcado por um pino. Ao seleccionar o pino, a morada é
automaticamente preenchida. Se se carregar no botão “Obter Morada”, além de mostrar o local no
37
mapa irá também preencher automaticamente o campo “Morada”. Tal como acontece anteriormente,
é sempre possível deslocar o pino para outro ponto, e ao carregar sobre ele são actualizados os
campos das coordenadas e da morada.
Figura 18. Ecrã de registo de novos locais de paragem.
Uma vez que é possível a morada disponibilizada pelo sistema não ser a correcta, sendo meramente
sugestiva, a morada pode sempre ser modificada pelo utilizador. O ecrã com o mapa pode ser visto
na Figura 19.
Figura 19. Ecrã de registo de novo local de paragem com mapa visível.
Foi também criado um ecrã de procura de locais já inseridos no sistema (ver Figura 20), de modo a
permitir saber quais os locais já existentes. Neste ecrã é possível procurar locais pelo seu código de
paragem, nome, morada, coordenadas e locais que se encontram activos ou não, sendo para isso
necessário preencher os campos de filtragem (parte superior da Figura 20). Os resultados da procura
são mostrados numa tabela (ver parte inferior da Figura 20) onde podem ser visualizados o código,
nome, morada de cada paragem e estado.
38
Figura 20. Ecrã de procura de locais de paragem inseridos no sistema.
A partir deste ecrã é possível ir para a página de edição de local de paragem (ver Figura 21). Este
ecrã tem um funcionamento semelhante ao ecrã de registo de nova paragem, sendo diferente apenas
na opção de se poder alterar o número de código de uma paragem, o qual é criado automaticamente
no registo de uma nova paragem.
Figura 21. Ecrã de edição de local de paragem.
4.2.3.2. Verificação de Locais de Paragem Existentes
A razão principal para a criação de um gestor de paragens deveu-se à necessidade de verificar se
determinado código de paragem corresponde a uma paragem que se encontre inserida no sistema.
39
A verificação de existência de local é despoletada automaticamente sempre que é inserido um novo
pedido no sistema, quer este seja inserido automaticamente via sistema do cliente, quer
manualmente via sistema da central (ver secção 4.2.4).
Na inserção manual dos pedidos no sistema da central (ver Figura 23), o sistema lança sugestões
automáticas nos campos de preenchimento de locais, facilitando, dessa forma, a redução de erros.
Essa funcionalidade será descrita mais à frente. Após a submissão do formulário de pedido de
reserva, é feita a verificação da existência de local, sendo os locais submetidos para o gestor de
paragens tanto por meio de código como por meio de nome/descrição.
O gestor irá então fazer uma pesquisa à base de dados utilizando esses valores. No caso do
resultado vir preenchido, significa que o local de paragem seleccionado existe, retornando ao sistema
um objecto correspondente ao mesmo, o qual vai ser utilizado para guardar o pedido. No caso de a
pesquisa não tornar nenhum resultado, é lançada uma excepção de local inexistente, sendo
transmitido ao utilizador uma mensagem de erro comunicando que o código ou nome/descrição dado
como local de paragem não existe registado no sistema.
Quando um pedido provém do sistema do cliente, o funcionamento de verificação de existência de
local de paragem é o mesmo da inserção manual dos pedidos. Porém, a única hipótese de
preenchimento de locais de paragem é por meio do código de paragem, o que leva a que a
verificação seja apenas feita por esse código. No caso de a verificação retornar resultados, implica
que esse local exista, permitindo que o pedido siga o processo de registo. Se não forem retornados
resultados da verificação é lançada uma excepção para o sistema do cliente com a mensagem de
erro de inexistência de local com o código enviado pelo cliente.
4.2.4. Gestor de Pedidos
O gestor de pedidos é o módulo que permite iniciar a satisfação dos pedidos realizados pelos
clientes. É ele que vai receber, processar e dar resposta aos pedidos efectuados pelos clientes, após
todas as validações anteriores terem sido efectuadas e retornado resultados positivos.
Como não faz sentido processar os pedidos por ordem de chegada, pois poderão surgir pedidos que
tenham horas de início e fim mais próximas da hora actual do que pedidos que tenham surgido
anteriormente. Por outro lado, poderá acontecer o caso de surgir um pedido para um dia diferente do
dia corrente, não sendo o mais desejado gastar tempo de processamento a processar um pedido que
não tem tanta prioridade como os que vão surgindo para o dia em questão.
Desta forma os pedidos que vão surgindo vão sendo registados no sistema, ou seja, vão sendo
guardados na base de dados (ver Figura 22), sendo o seu estado actualizado à medida que o seu
processamento vai avançando.
40
CORE_EVENT
PK EventID
FK1 EventSubTypeID
FK2 EventStateID
FK3 ClientID
RegistrationDateTime
StartDateTime
EndDateTime
ClosingDateTime
Subject
Priority
Description
Observations
UserCreationID
UserUpdateID
DateCreation
DateUpdate
Active
UserCloseID
SIGO_EVENTVEHICLE
PK EventVehicleID
FK1 EventID
FK2 VehicleID
FK3 DailyServiceID
Observation
Active
CORE_EVENTSTATE
PK EventStateID
EventStateName
CORE_EVENTSUBTYPE
PK EventSubTypeID
FK1 EventTypeID
EventSubTypeName
Active
CORE_EVENTTYPE
PK EventTypeID
EventTypeName
EventTypeDesc
ImagePath
Active
SIGO_EVENTTRIPS
PK EventTripsID
FK1 EventID
FK2 TripRouteLineID
Active
OrderNr
CORE_PLACE
PK PlaceID
Code
Description
Address
Active
SIGO_TRIPLINE
PK TripLine
FK1 TripID
FK2 SigoLineID
FK3 PlaceID
OrderNr
FreeSeats
Active
SIGO_EVENTPLACE
PK EventPlaceID
FK1 EventID
FK2 PlaceID
OrderNr
Active
SIGO_VEHICLE
PK VehicleID
FK1 TypeID
FK2 CategoryID
FK3 DomainID
FK4 ClassID
FK5 ServiceTypeID
FK6 StateID
Number
Register
DateCreate
DateUpdate
UserCreate
UserUpdate
Active
MovelID
Kms
ParkedBy
Seats
Figura 22. Modelo de dados representativo de um pedido.
Quando o pedido entra no sistema, este é registado na base de dados. Os dados são inicialmente
guardados registando na tabela CORE_EVENT o seu tipo, que neste caso corresponde a BoD, o seu
estado, que no início corresponde a registado, a data de registo do pedido no sistema, a data mínima
de início de viagem, a data máxima de fim de viagem e o ID que define um pedido. O campo Active é
também preenchido, sendo o seu valor positivo.
Após ter sido criado o pedido na tabela CORE_EVENT, são guardados os locais de embarque e
desembarque pedidos, preenchendo a tabela SIGO_EVENTPLACE com dois valores. Primeiro é
registado o local de embarque que acompanha o pedido, com o OrderNr preenchido com o valor um,
o ID do local de embarque e o ID do pedido, estando o campo Active preenchido com um valor
positivo. Seguidamente é registado o segundo local da mesma forma, variando apenas o valor do
campo OrderNr, que irá ser preenchido com o valor dois.
O registo do pedido fica, deste modo, finalizado. É então criada uma resposta para o sistema do
cliente onde é devolvido o valor do ID do pedido. Será este valor que irá ser transmitido ao cliente
para que este o possa usar para saber o estado do seu pedido.
Assim que o pedido começa a ser processado, o seu estado é mudado para “Em processamento”.
Quando é finalizado o processamento o estado do pedido irá mudar. Se não foi possível satisfazer o
41
pedido, o seu estado muda para “Não Reservado”. No caso de ser possível satisfazer o pedido então,
no final do processamento, o seu estado será “Reservado”.
À medida que o pedido vai ser processado vão sendo preenchidos os dados que representam as
viagens em que os pedidos foram inseridos, sendo preenchidos os campos da tabela
SIGO_EVENTTRIPS, em que são registadas as viagens de início e fim correspondentes ao pedido
que se encontra em processamento. Simultaneamente é definido qual o veículo que irá efectuar as
viagens correspondentes ao pedido, ou seja, qual o veículo em que o cliente irá entrar para efectuar a
viagem requisitada. Apenas no caso de o pedido ser satisfeito é que estes dados se encontrarão
preenchidos.
No caso do pedido vir a ser cancelado, o seu estado irá ser alterado para “Cancelado”, e tal como
acontece na situação em que o pedido não é reservado, os campos que poderiam estar preenchidos,
como descrito no parágrafo anterior, serão apagados.
4.2.4.1. Inserção de Pedidos
Embora o sistema tenha sido pensado para o processamento dos pedidos, incluindo a sua inserção
no sistema, ser automatizado, é necessário ter em conta que nem todos os utilizadores poderão ter
acesso às tecnologias necessárias para realizar pedidos de reserva/cancelamento de viagens BoD.
De modo a colmatar essa situação, foram introduzidas no sistema formas de o pedido poder ser
inserido manualmente por um utilizador com permissões para tal. Desta forma o cliente poderá fazer
o seu pedido de reserva/cancelamento numa agência existente para o efeito ou até mesmo via
telefone.
Para permitir a inserção manual de pedidos de reserva BoD foi criado um ecrã para o efeito (ver
Figura 23). No registo manual de um pedido de reserva é necessário inserir o número de cliente, que
deverá ser validado, inicialmente, pelo utilizador que insere o pedido, devendo utilizar para o efeito o
botão de procura de clientes registados no sistema. Ao carregar sobre esse botão é aberto um pop-
up semelhante ao ecrã da Figura 14. No caso de o cliente ainda não se encontrar registado no
sistema, o utilizador poderá carregar sobre o botão “Criar Cliente”, que abrirá um pop-up com um ecrã
semelhante ao da Figura 12, e registar um novo cliente no sistema, que ao finalizar irá devolver o
número do cliente.
Tal como acontece no registo de pedidos de reserva efectuados pelas vias referidas na secção 4.1.3,
será necessário indicar também os locais de partida e chegada assim como as respectivas datas
pretendidas pelo cliente. Tanto o campo do local de partida como o de chegada contêm uma
funcionalidade que à medida que é preenchido o mesmo vai mostrando uma lista de paragens já
registadas no sistema que se assemelham aos valores que já se encontram no campo.
Por sua vez, os campos das datas têm um calendário associado que é aberto ao carregar sobre a
imagem que se encontra à esquerda dos campos de preenchimento (ver Figura 23). Deste modo é
42
facilitado o preenchimento destes campos, pois ao seleccionar a data e horas pretendidas nesse
calendário os campos serão automaticamente preenchidos.
Figura 23. Ecrã de registo de novo pedido de reserva BoD.
No ecrã pode ser vista uma lista de características de lugar que podem ser seleccionadas. A
funcionalidade adjacente a essa lista não se encontra implementada, tendo sido considerada como
trabalho futuro. Porém, é mostrada aqui como incentivo à realização de uma funcionalidade que
permita ao cliente seleccionar determinadas características do lugar onde pretende ficar para a
realização da viagem, quer apenas por conveniência quer por motivos de saúde. É de notar que o
modelo de dados para guardar estes dados num pedido não se encontra implementado e o algoritmo
para cálculo de rotas e horários também não considera estes dados na realização dos seus cálculos.
Após o preenchimento de todos os campos obrigatórios, ao carregar sobre o botão “Registar”, e no
caso de não ser dado nenhum erro, o pedido é registado no sistema e passa-se para um novo ecrã
onde são apresentados todos os dados do pedido acompanhado por uma mensagem de sucesso (ver
Figura 24). No caso de o registo do pedido dar erro, volta-se ao ecrã da Figura 23, porém os campos
aparecem preenchidos com os dados já inseridos e aparecerá uma mensagem de erro na parte
superior e escrita a vermelho, tentando mostrar qual o erro que surgiu.
Figura 24. Ecrã de registo efectuado com sucesso.
43
4.2.4.2. Procura de Pedidos Registados no Sistema
Como o estado dos pedidos vai sendo alterado à medida que estes são processados e é necessário
saber em que estado estes se encontram em cada momento para se transmitir ao cliente essa
informação, foi criado um ecrã para procura de pedidos registados no sistema (ver Figura 25).
Figura 25. Ecrã de procura de pedidos de reserva BoD.
Neste ecrã existe um filtro para procura dos registos (ver parte superior da Figura 25). Os campos
existentes nesse filtro permitem filtrar os pedidos pelo número de pedido, ou seja o número que é
dado ao cliente após o registo do seu pedido de reserva, o número de cliente associado ao(s)
pedido(s) que se pretende(m) encontrar, o dia de registo do(s) mesmo(s), o dia de serviço em que
o(s) pedido(s) irá ser satisfeito, os locais de partida e chegada requisitados no(s) pedido(s) e o estado
em que este(s) se encontra(m).
Após o preenchimento dos campos de filtragem pretendidos, ao carregar sobre o botão “Procurar”, o
pedido de procura é enviado ao sistema retornando uma lista de pedidos de reserva registados no
sistema que satisfaçam a filtragem, sendo os mesmos observados na parte inferior da Figura 25. No
resultado da procura realizada serão apresentados os seguintes dados pela mesma ordem descrita: o
número de registo do pedido, o número de cliente que efectuou o pedido, o estado de processamento
em que se encontra o pedido, a data em que o pedido foi registado no sistema, o local de partida, a
data de partida prevista (no caso do pedido já ter sido processado), a data de partida real (no caso de
o pedido se encontrar satisfeito ou o cliente já ter embarcado no veículo), o local de chegada, a data
de chegada prevista (no caso do pedido já ter sido processado) e a data de chegada real (no caso de
o pedido se encontrar satisfeito).
4.2.4.3. Edição e Cancelamento de Pedidos
No ecrã de procura de pedidos (Figura 25), ao carregar sobre o número de registo de um pedido é
aberto um ecrã (ver Figura 26) onde todos os dados de registo são mostrados. No caso de o pedido
44
se encontrar no estado “Registado” é possível editar os seus dados, tal como os locais de partida e
chegada assim como as datas respectivas, carregando sobre o botão “Editar”, abrindo um ecrã igual
ao da Figura 27. Porém, se o pedido se encontrar no estado “Em processamento” ou “Reservado”, o
botão “Editar” não será mostrado neste ecrã.
Figura 26. Ecrã de visualização de pedido registado.
Figura 27. Ecrã de edição de pedido registado.
Neste ecrã será também possível cancelar o pedido, situação que poderá ser realizada em todos os
estados do pedido, embora seja realizada a verificação se o pedido já foi satisfeito ou não quando se
carrega sobre o botão “Cancelar Serviço”, sendo que no caso de o pedido já estar satisfeito ou em
modo de satisfação (o cliente já entrou no veículo) o pedido não irá ser cancelado.
4.2.5. Gestor de Serviço
O gestor de serviço é o núcleo do sistema da central, pois é ele que vai processar os pedidos que
foram enviados pelos clientes. É este módulo que tem a função de verificar a possibilidade de
satisfazer um pedido e, subjacentemente, calcular os itinerários e os horários que irão servir cada
pedido.
Embora para a realização deste trabalho tenha sido considerado que o sistema para o
veículo/motorista seja trabalho futuro, foi tomado em conta que será este módulo que irá comunicar
com esse sistema. Será função do gestor de serviço comunicar com o sistema para o
veículo/motorista, transmitindo-lhe os itinerários que o veículo terá que seguir, os horários que deverá
cumprir e os clientes que deverá embarcar em cada paragem.
45
Na secção seguinte será mostrado e explicado o algoritmo utilizado para realizar o processamento e
satisfação dos pedidos.
4.2.5.1. Cálculo de Itinerários e Horários
Tal como já foi referido anteriormente, existem muitos estudos realizados sobre esta tarefa. Esta
tarefa é a mais complicada de resolver num sistema deste tipo devido à sua complexidade de
processamento, sendo bastante complicado conseguir dar resposta em tempo útil à medida que o
número de pedidos vai aumentando.
Tendo em conta já existirem muitos estudos sobre esta matéria, o algoritmo criado e usado para
satisfazer este módulo vai ao encontro dos algoritmos usados no DARP dinâmico com múltiplos
veículos. Este algoritmo foi baseado no algoritmo descrito em Coslovich et al. [44], tendo como
objectivo principal minimizar a insatisfação do utilizador.
Na subsecção 4.2.5.1.1 vão ser referidos os pressupostos dos quais se partiu para o
desenvolvimento do algoritmo usado neste módulo, dando uma explicação da razão pela qual se
seguiram esses pressupostos. Posteriormente, na subsecção 4.2.5.1.2 vai-se esquematizar e dar
uma pequena explicação do algoritmo desenvolvido para este módulo.
4.2.5.1.1. Pressupostos
Para o desenvolvimento do algoritmo para este módulo partiu-se de uma série de pressupostos, os
quais vão ser aqui descritos.
Foi considerado que a viagem poderá sofrer um atraso com o valor da diferença entre a hora de
chegada programada e a real, até um máximo de quinze minutos, desde que não ultrapasse a janela
de tempo requisitada. Este valor pode ser alterado, uma vez que faz parte de uma série de valores
configuráveis do sistema. Ao ser introduzido este valor, tem-se uma maior margem de manobra no
cálculo das viagens, sendo possível introduzir mais locais de paragem entre os itinerários já criados.
Outro pressuposto do qual se partiu é o de o tempo de paragem para entrada/saída de passageiros
nos locais de paragem serem desprezáveis para o cálculo do tempo de viagem programada, ou seja,
a hora a que o veículo chega a um local de paragem é a mesma a que este inicia viagem a partir do
mesmo, no caso de esse local não ser o último do serviço calculado até ao momento. Da mesma
forma, o tempo de partida de um autocarro da garagem, assim que um pedido cria um novo serviço
para a hora actual e o autocarro o inicia, é também desprezável.
Partiu-se, também, do pressuposto de que este serviço irá funcionar no horário nocturno (das 22:30 à
1:30). Desta forma, pressupôs-se que, comparativamente ao período diurno, o número de pedidos
neste horário será inferior e a velocidade média de circulação será superior. Este último pressuposto
advém de se considerar que o número de pessoas que circulam na rua durante o período nocturno é
inferior ao número de pessoas que circulam durante o período diurno, tendo, também, como
46
consequência a diminuição do trânsito na via rodoviária. Desta forma foi considerado que a
velocidade média de circulação dos veículos é de 20 Km/h, valor superior ao valor combinado entre o
serviço diurno e o nocturno de uma empresa de transporte rodoviário da área metropolitana de
Lisboa, cujo o valor é de 14,33 Km/h [19]. Tal como acontece com o valor de tempo máximo de atraso
de viagem, este valor também faz parte dos valores de configuração do sistema.
Finalmente, foi considerado que todos os pedidos chegam com pelo menos meia hora de
antecedência relativamente à hora de início de viagem que acompanha o pedido. Este pressuposto é
usado para tentar garantir que a resposta ao pedido é dada antes da hora de início de viagem
pretendida pelo utilizador.
4.2.5.1.2. Algoritmo Para Realização de Reservas
Nesta secção vai ser descrito o algoritmo que foi desenvolvido, usando um diagrama de fluxo do
algoritmo, podendo ser visto, dividido em várias partes, da Figura 28 à Figura 35, acompanhado da
sua descrição.
O algoritmo usa como entrada os dados que acompanham o pedido do utilizador, fazendo parte dele
os locais de embarque e desembarque e os limites mínimo para início da viagem e máximo para fim
da mesma.
Em primeiro lugar foi criado um limite mínimo que os pedidos têm de satisfazer para o seu
processamento ter início, o qual é de duas horas antes do início de viagem pretendida, tal como foi
explicado anteriormente, sendo este valor configurável no sistema.
Para dar início ao processamento dos pedidos, foi criado um scheduler que irá, de minuto a minuto
(embora este valor possa ser configurado), verificar a existência de pedidos registados no sistema
que satisfaçam o requisito anterior (ver Figura 28). A lista de pedidos, retornada por esta pesquisa,
vem ordenada por ordem crescente de data de início de viagem requisitada. Isto sucede devido a
considerar-se que os pedidos devem ser processados pela hora de início de viagem requisitada, em
vez de pela sua hora de registo, pois não se pode deixar um pedido pendente cuja hora de início de
viagem requisitada esteja mais próxima da hora de processamento que um outro pedido que tenha
sido registado no sistema mais cedo.
Se a lista vier vazia, ou seja, se não existirem pedidos que satisfaçam esse requisito no momento do
processamento, o processamento termina até ao minuto seguinte.
47
processRequests()
Procura por todos os pedidos
cuja hora de início se encontre
nas próximas duas horas
Existem
pedidos para
satisfazer?
Não
Termina
Para cada pedido
Sim
createTrip(pedido)
Pedido
realizado
por email ou
sms?
Pedido
satisfeito?
Sim
Não
Prepara mensagem de
resposta
Sim
Envia resposta ao sistema para
o cliente
Há autocarros
para serviços on
Demand?
Sim
Para cada pedido
Prepara mensagem de
resposta negativa!
Envia resposta ao sistema para
o cliente
Ao terminar
Procura se existe serviço fixo
que satisfaça o pedido
Não
Pedido
realizado
por email ou
sms?
Sim
Muda estado do pedido
para “Não Reservado”
Muda estado do pedido
para “Não Reservado”
Pedido no
estado
“Cancelado”?Não
Não
Sim
Muda estado destes pedidos
para “Em Processamento”
Figura 28. Ciclo principal do tratamento dos pedidos de reserva de viagens.
No caso de existirem pedidos para satisfazer, o seu estado vai ser alterado para “Em
Processamento”. De seguida verifica-se se existem autocarros de serviço a pedido disponíveis para
satisfazer o pedido. Se não existirem autocarros para satisfazer o(s) pedido(s), vai-se colocar o
estado do pedido como não satisfeito e comunicar ao Gestor de Pedidos que o pedido não foi
satisfeito, que por sua vez irá enviar uma resposta ao sistema para o cliente, que terá a
responsabilidade de comunicar ao cliente que o seu pedido não foi satisfeito. No final de todas as
respostas terem sido enviadas, o processamento termina.
Se existirem autocarros para satisfazer o(s) pedido(s), tenta-se verificar se é possível satisfazer cada
pedido no serviço dinâmico (ver Figura 29).
48
Há serviços
no horário
pretendido?
Selecciona um autocarro para
efectuar o pedido
createNewTrip(pedido,autocarro)
Marca pedido como satisfeitoMarca pedido como não
satisfeito
return(true)
Não
Viagem criada? SimNão
findOrCreateTrip(pedido)
Sim
createTrip(pedido)
Calcula tempo de viagem entre
a origem e o destino
pretendidos
Calcula hora de chegada
ao destino se arrancar da
origem à hora requisitada no
pedido.
Hora calculada
menor que a hora de
chegada requisitada
no pedido?
Sim
Não
return(false)
Estado do pedido
alterado para
“Cancelado” durante o
processamento?
Não
Estado do pedido
alterado para
“Cancelado” durante o
processamento?
Não
removeTrip(pedido)
Sim
Figura 29. Diagrama representativo da criação de viagem para o pedido que se encontra em
tratamento.
Assim que é verificada a existência de veículos disponíveis para satisfazer pedidos de serviço
dinâmico, é inicializada a verificação de possibilidade de satisfação do pedido enviado pelo cliente. O
primeiro passo que o algoritmo realiza nesta situação é o de calcular qual o tempo de viagem entre os
dois locais de paragem requisitados pelo cliente. A partir desse valor verifica-se se na condição de o
veículo partir do local de embarque requisitado à hora requisitada este consegue chegar ao local de
desembarque antes da hora de chegada requisitada pelo cliente.
49
Ao introduzir este teste no algoritmo é possível optimizar o tempo de processamento dos pedidos,
pois todos os pedidos que não passem esta condição são considerados como pedidos que não
podem ser satisfeitos, não sendo perdido mais tempo de processamento com eles.
No caso de as janelas de tempo requisitadas permitirem a concretização da viagem, vai-se verificar
se já existem serviços dinâmicos. No caso de este ser o primeiro pedido ou nenhum dos pedidos
anteriores tenha criado um novo serviço, então vai ser criado um novo serviço para um autocarro que
esteja disponível (Figura 30).
Figura 30. Diagrama representativo da criação de viagem quando não há serviços de BoD.
A criação de um novo itinerário vai obrigar à criação de um novo serviço. Tal como foi dito
anteriormente um itinerário é constituído por várias viagens. No caso de um pedido que irá criar um
novo serviço, o itinerário criado vai ser constituído por duas viagens: a viagem da garagem, local
onde o autocarro se encontra parado sempre que não tem serviços a realizar, até ao local de origem
requisitado e a viagem entre os locais de origem e destino requisitados.
Para criar uma viagem é necessário calcular os tempos de viagem entre os dois locais que a
constituem. Desse modo são calculados os tempos de viagem para cada uma das viagens
Calcula tempo de viagem entre
o local onde o autocarro está
parado e a origem requisitada
no pedido
Calcula hora de partida do
autocarro da garagem para
chegar ao local de origem à
hora requisitada pelo cliente
Calcula tempo de viagem entre
a origem e o destino
requisitados no pedido
Calcula hora de chegada ao
destino requisitado no pedido
Cria a viagem entre a garagem
e a origem requisitada
Cria viagem entre a origem e o
destino requisitados, colocando
um lugar ocupado.
Viagens
criadas?Não Sim
createNewTrip(pedido,autocarro)
return(true)return(false)
50
necessárias. Com o tempo de viagem calculado entre a garagem e o local de origem de viagem
requisitado é calculada a hora a que o veículo necessita sair da garagem para conseguir chegar ao
local de origem do pedido à hora requisitada pelo cliente. Se a hora resultante for superior à hora
actual, será essa a hora de início de viagem programada, sendo a hora de início da viagem
requisitada a hora de fim de viagem programada desta viagem.
No caso de a hora calculada anteriormente ser inferior à hora actual, a hora de início programada
desta viagem será a hora actual. Tendo em conta esta informação, vai-se então calcular a hora
prevista para chegar ao local de origem, somando à hora actual o tempo de viagem da garagem ao
local de origem requisitado.
De seguida é calculada a hora de chegada programada ao local de destino requisitado, somando à
hora de chegada ao local de origem requisitado o tempo de viagem entre estes dois locais. Se a hora
de chegada calculada for inferior à hora de chegada ao destino requisitada, então é possível
satisfazer o pedido. Desta forma serão criados o novo serviço e as duas viagens calculadas.
O serviço será criado usando como dados o dia em que o serviço vai decorrer, a hora de início do
serviço, correspondente à hora em que o veículo irá sair da garagem, e a hora de fim do serviço,
correspondente à hora de chegada ao local de destino. Relativamente às viagens, estas serão
criadas guardando a hora a que o veículo sairá do local de partida, ou seja, a hora de início de
viagem, e a hora a que o veículo chegará ao local de chegada, ou seja a hora de fim de viagem. A
cada viagem serão associados dois locais, o de partida e o de chegada, sendo associados aos
mesmos o número de pessoas que entram nesse local, se for o local de início de viagem, e o número
de pessoas que irão sair, se for o local de destino da viagem.
Se os horários calculados para as viagens não permitirem que o pedido seja satisfeito nas janelas de
tempo pretendidas pelo cliente, o processamento do pedido irá terminar com o resultado de não
reservado, pois, tendo em conta que não existe nenhum serviço, e a criação de um novo serviço não
permite que o pedido seja satisfeito dentro da janela de tempo requisitada, então será impossível
satisfazê-lo.
Se existirem serviços BoD já calculados e/ou inicializados, então o processamento do pedido irá
seguir outro fluxo (ver Figura 31). Tendo em conta que já existem serviços pendentes ou em
execução, não será rentável criar um novo serviço se houver a possibilidade de inserir esse pedido
dentro de um serviço já existente.
Quando o processamento do pedido entra neste fluxo irá, inicialmente, verificar se existem viagens
nos serviços existentes que tenham início no local de origem pretendido, que satisfaçam a janela de
tempo requisitada no pedido e cuja lotação do veículo que efectua o serviço tenha, nesse momento,
lotação para mais um passageiro.
Se existirem viagens que satisfaçam essas condições, ir-se-á verificar se para cada serviço onde
essas viagens se encontram, e após passagem nesses locais, existem viagens que tenham o mesmo
51
local de destino que o local de destino requisitado no pedido. Assim que, no decorrer do ciclo, se
encontre uma viagem que satisfaça as janelas de tempo e os locais de origem e destino requisitados
e cuja lotação ao longo do itinerário permita inserir mais um passageiro, o processamento do pedido
irá terminar, sendo este reservado com as viagens de início e fim encontradas e actualizada a lotação
do veículo entre essas duas viagens.
Figura 31. Diagrama representativo do tratamento de um pedido se existirem serviços de BoD.
Se após percorrer todas as viagens de origem encontradas não tiver sido possível inserir o pedido
nas viagens posteriores, quer por não existirem viagens com término no local de destino requisitado
quer por não haver lotação para inserir o pedido, passa-se para o próximo passo do algoritmo (ver
Figura 32). Neste passo ir-se-á voltar a percorrer a lista de viagens de origem encontradas, porém,
Procura por todas as viagens
que tenham origem no local de
origem e início dentro da janela
de tempo requisitados
Existem viagens
de origem nessas
condições?
Para cada viagem nessas
condições
Procura por todas as viagens
posteriores, do mesmo serviço,
que tenham destino e hora de
fim no local de destino e na
janela de tempo requisitados
Lotação
permite inserção
de um
passageiro?
Insere pedido nas viagens de
origem e destino, actualizando
a lotação das viagens.
return(true)
Sim
Sim
Não
Não
Procura por todas as viagens
que tenham destino e hora de
fim no local de destino e na
janela de tempo requisitados
Não
Não
Sim
Sim
Procura por todos os serviços
on Demand existentes no
mesmo dia do pedido e que
terminem antes da hora de
chegada requisitada.
Não
Sim
Sim
Sim
NãoSim
createBetterTrip(viagensOrigem,
localDestino, horaChegada)
Ao terminar
createBetterStartTrip(viagensDestino,
localOrigem, horaPartida)
Foi reservada
viagem?
CreateBetterTrips(pedido,
serviçosExistentes)
CheckToInsertTripAtEnd(pedido,
serviçosExistentes)
Não
Procura todos os autocarros de
serviço on Demand sem
serviços para efectuar.
Existem
autocarros
nessas
condições?
Selecciona o primeiro autocarro
da lista
Sim
CreateNewTrip(pedido,autocarro) return(false)
Não
Não
findOrCreateTrip(pedido)
Existem viagens
de destino nessas
condições?
Existem viagens
de destino nessas
condições?
Foi reservada
viagem?
Foi reservada
viagem?
Foi reservada
viagem?
Selecciona a primeira viagem
que satisfaça o pedido.
52
em vez de se ir procurar por viagens que terminem no local de destino pretendido, vai-se tentar inserir
uma nova viagem no itinerário do serviço de modo a ser possível satisfazer o pedido.
Assim, para cada viagem de origem, ir-se-á pesquisar todas as viagens posteriores que se encontrem
dentro da janela de tempo requisitada. A lista de viagens resultantes dessa pesquisa, que virá
ordenada por ordem crescente de tempo, será percorrida verificando-se se, no meio de cada viagem,
é possível inserir duas novas viagens, uma com início no local de origem dessa viagem e fim no local
de destino pretendido e outra com início no local de destino pretendido e fim no local de destino
dessa mesma viagem.
Para ser possível inserir uma nova viagem no itinerário de um serviço existem três requisitos que
devem ser cumpridos. Em primeiro lugar deve-se garantir que a lotação do veículo ao longo do
percurso em que se tenta inserir o pedido nunca é ultrapassada. Seguidamente é necessário garantir
que o tempo de atraso inserido no serviço, devido à inserção de uma nova viagem, não ultrapassa o
tempo de atraso máximo das viagens já existentes no serviço e que serão afectadas por esta
inserção, ou seja, todas as viagens posteriores à viagem inserida. Finalmente, é necessário garantir
que a janela de tempo requisitada não é violada, ou seja, o utilizador não terá que embarcar antes da
hora pretendida nem irá chegar ao seu destino depois da hora de desembarque requisitada.
Tendo em conta estes requisitos, a lista de viagens posteriores, onde se inclui a viagem de origem
com o local de embarque pretendido, vai ser percorrida verificando-se se para cada viagem é
possível inserir uma viagem que termine no destino pretendido cumprindo todos os requisitos. Se os
requisitos forem garantidos, então são criadas duas novas viagens, uma com origem no local de
origem da viagem que se está a visualizar e com local de fim o local de desembarque pretendido e
outra com início no local de desembarque e fim no local de destino da viagem que se está a
visualizar.
Relativamente aos horários, a primeira viagem criada irá ter início na hora já definida para a viagem
que se está a alterar e fim na soma dessa hora com o tempo de viagem entre os dois locais. A
segunda viagem criada terá início na hora de fim da viagem anterior e fim na soma dessa hora com o
tempo de viagem entre os dois locais que a constituem.
Após a criação destas viagens vai ser realizada a actualização dos horários das viagens posteriores
uma vez que elas sofrerão um atraso igual à soma dos tempos de viagem destas duas novas
viagens, com excepção de haver alguma viagem em que o veículo esteja a atrasar numa paragem
para chegar à hora pretendida ao local de embarque, situação em que pode acontecer que o tempo
de atraso que se irá inserir pode ser esgotado ou reduzido nessa viagem não sendo passado para as
restantes viagens.
Se para todas as viagens de origem encontradas não for encontrada solução para inserir o local de
desembarque pretendido então ir-se-á verificar se existem viagens, nos serviços existentes, que
tenham como local de destino o local de desembarque requisitado, que satisfaçam a janela de tempo
53
pretendida e cujo veículo que efectua o serviço tenha, nesse momento, lotação para mais um
passageiro (ver Figura 31).
Figura 32. Diagrama representativo do tratamento do pedido quando já existem serviços BoD
com viagens que têm início no local de embarque pretendido.
Se forem encontradas viagens que satisfaçam estes requisitos, então existe a possibilidade de se
poder inserir uma nova viagem ao longo do serviço que tenha como local de origem o local de
Para cada viagem origem
Procura por todas as viagens
do serviço em que a viagem de
origem se encontra e que se
encontrem dentro da janela de
tempo requisitada
Para cada viagem encontrada
Calcula tempo de viagem ao
desviar para passar pelo
destino
Não
Não
Ao terminar
Cria viagem de desvio para
passar no destino pretendido a
partir desta viagem,
actualizando o horário do
serviço assim como a lotação
do veículo
Lotação
permite inserção
de um
passageiro?
Sim
Não
Tempo de viagem
é inferior ao tempo
de atraso máximo
permitido de todas as
viagens posteriores
incluindo esta?
Hora de chegada
prevista é igual ou
inferior à hora
requisitada?
Sim
return(true)
return(false)
Ao terminar
createBetterTrip(viagensOrigem,
localDestino, horaChegada)
Calcula hora de chegada ao
destino
Sim
54
embarque requisitado no pedido. Esta verificação é realizada percorrendo todas as viagens anteriores
à viagem encontrada, por ordem decrescente de hora (ver Figura 33). À medida que se percorre a
lista de viagens anteriores, vai-se verificando se, para cada viagem, existe lotação para mais um
passageiro. Quando não se verifica esta situação não será possível inserir uma nova viagem no
serviço para terminar na viagem desejada, passando-se a fazer a verificação para a próxima viagem
da lista de viagens com o mesmo destino do requisitado.
Figura 33. Diagrama representativo do tratamento do pedido quando já existem serviços BoD
com viagens que têm fim no local de desembarque pretendido.
Para cada viagem nessas
condições
Procura por todas as viagens
anteriores do serviço que
tenham hora de início dentro da
janela de tempo requisitada,
ordenadas por ordem
descendente de início de
viagem.
Calcula tempo de viagem ao
desviar para passar na origem
Não
Sim
Sim
Não
Não
Ao terminar
Cria viagem de desvio para
passar pela origem pretendida,
actualizando o horário do
serviço assim como a lotação
do veículo.
Sim
Tempo de desvio
permite chegar ao
destino dentro da
janela de tempo
requisitada?
return(true)
return(false)
Ao terminar
createBetterStartTrip(viagensDestino,
localOrigem, horaPartida)
Lotação
permite inserção
de um
passageiro?
Para cada viagem encontrada
Tempo de viagem
é inferior ao tempo
de atraso máximo
permitido de todas as
viagens posteriores
incluindo esta?
55
No caso de existir lugar para mais um passageiro, calcula-se o tempo de atraso que irá ser inserido
no serviço ao ser colocada uma nova viagem entre as viagens existentes. Este atraso é calculado
somando o tempo necessário para fazer o desvio entre o local de início da viagem que se está a
verificar e o local de origem requisitado com o tempo necessário para ir do local de origem requisitado
até ao local de destino dessa mesma viagem.
Se o tempo de atraso não for superior ao tempo de atraso máximo que é possível inserir nas viagens
do serviço posteriores à que se está a verificar, e a inserção desse atraso permite chegar ao local de
destino requisitado dentro da janela de tempo definida, então o pedido irá ser reservado, actualizando
o itinerário do serviço, adicionando esta nova viagem, assim como os seus horários e lotação do
veículo.
Quando é finalizada a verificação da lista de viagens de destino é sinal que também não foi possível
inserir o pedido nos serviços que continham viagens com destino igual ao destino pretendido.
Chegando a este ponto, o pedido encontra-se numa situação em que não foi possível inseri-lo em
serviços cujo seu itinerário tivesse viagens com locais de embarque e desembarque iguais aos
pretendidos ou que tivesse viagens com os mesmos locais de embarque ou desembarque que os
pretendidos.
Tendo em conta que se pretende garantir um atraso mínimo na satisfação dos pedidos já reservados
e com viagens já agendadas, o próximo passo do algoritmo é verificar se é possível inserir viagens no
fim dos serviços existentes cuja hora de término é inferior à hora de destino requisitada (ver Figura
34). Para isso vai-se pesquisar por todos os serviços existentes no dia requisitado no pedido, cuja
hora de término é inferior à hora requisitada no pedido. De seguida ir-se-á percorrer a lista de
serviços e para cada serviço vai-se procurar a última viagem que este tem para realizar ou realizou.
Deste modo ir-se-á descobrir qual o local onde o veículo se encontrará antes de iniciar a viagem para
satisfazer o pedido.
Sabendo-se qual o local de destino da última viagem que o veículo efectuará no serviço, vai-se
verificar se o mesmo corresponde ao local de origem requisitado. Se sim, apenas será necessário
calcular o tempo que o veículo necessita para chegar ao destino pretendido. De seguida é verificado
se a hora de término programada do serviço é inferior à hora de embarque requisitada. Se tal
acontecer é inserida uma nova viagem no final do itinerário do serviço que terá início e fim nos locais
de embarque e desembarque requisitados, com hora de início programada igual à requisitada e hora
de término igual à soma do tempo de viagem entre os dois locais e a hora de início programada.
Caso a hora de fim de serviço seja superior à hora de embarque requisitada, vai-se verificar se a
soma do tempo de viagem com a hora de fim de serviço é inferior à hora de desembarque
requisitada. Se a verificação der um resultado positivo é inserida uma nova viagem no final do
itinerário do serviço que terá início e fim nos locais de embarque e desembarque requisitados, com
hora de início igual à hora de fim de serviço e hora de término igual à calculada. No caso de a
verificação dar um resultado negativo, então não será possível inserir o pedido neste serviço, indo-se
verificar se será possível inseri-lo no final do próximo serviço da lista.
56
No caso de o local de fim do serviço ser diferente do local de embarque requisitado será necessário
efectuar o cálculo do tempo de viagem entre esse local e o local de embarque. De seguida calcula-se
qual a hora prevista de chegada ao local de embarque, partindo à hora de fim de serviço, e verifica-se
se é inferior à hora requisitada. Se a hora de fim de viagem for inferior à hora de embarque
requisitada, então ir-se-á inserir um atraso no início desta viagem, sendo que a hora de início irá ser
igual à hora de embarque requisitada subtraindo-lhe o tempo de viagem calculado, sendo de seguida
criada esta viagem com esta hora de início e hora de fim igual à hora de embarque requisitada.
Figura 34. Diagrama representativo do tratamento do pedido tentando inseri-lo no fim dos
serviços BoD já existentes.
Se a hora de fim de viagem for igual ou superior à hora de embarque requisitada, mas inferior à hora
de desembarque requisitada, estes valores irão ser guardados pois indicam que existe a possibilidade
de inserir o pedido neste serviço. Caso a hora de chegada ao local de embarque ultrapasse a hora de
Para cada serviço existente
Procura a última viagem do
serviço.
Calcula tempo de viagem
desde o destino desta viagem e
a origem requisitada.
Soma o valor retirado
anteriormente com o tempo de
viagem entre a origem e o
destino pretendidos.
Tempo total da
viagem permite a
finalização da mesma
na janela de tempo
requisitada?
Cria viagem como sendo a
última deste serviço,
actualizando a lotação do
veículo.
Não
CheckToInsertTripAtEnd(pedido,
serviçosExistentes)
Ao terminar
return(true)
return(false)
Chegada à origem
antes da hora
pretendida?
Sim
Não
Cria viagem como sendo a
última deste serviço, tendo
como hora de início a hora de
início requisitada.
Sim
57
chegada pretendida, então não é possível inserir o pedido no serviço, passando a realizar este passo
do algoritmo no serviço seguinte da lista de serviços encontrada.
Seguidamente ir-se-á calcular a hora de fim da viagem entre o local de embarque e o local de
desembarque requisitados, que corresponderá à soma da hora de chegada ao local de embarque
com o tempo de viagem entre o local de embarque e desembarque. No caso de se estar a tentar
inserir esta viagem após uma viagem que não tem hora de início igual à requisitada, então é
verificado se a hora de chegada é igual ou inferior à hora de chegada requisitada, e só em caso
afirmativo é possível inserir o pedido neste serviço.
Posteriormente é criada a viagem entre estes dois locais, com hora de início igual à hora de fim da
viagem anterior e hora de fim igual à hora calculada anteriormente. Se se provém do caso em que a
hora de fim de viagem entre o local de fim de serviço e o local de embarque pretendido é superior à
hora de início requisitada, antes de ser criada esta viagem é criada a viagem entre esses dois locais
com os dados guardados.
Se após ter sido percorrida toda a lista de serviços o pedido ainda não tenha sido satisfeito vai-se
tentar alterar o itinerário dos serviços existentes de modo que estes passem pelos locais pretendidos
para se conseguir satisfazer este pedido (ver Figura 35).
Para isso vai-se percorrer a lista de pedidos existentes e, para cada serviço, procurar todas as
viagens que o constituem em que o horário programado para a sua realização se encontre dentro da
janela de tempo dada pelo cliente. As viagens que irão ser retornadas por esta procura, virão por
ordem crescente de data.
Seguidamente é percorrida a lista das viagens resultantes. Para cada viagem é verificado se existe
lotação para inserir mais um passageiro, que se não acontecer indica que não será possível
satisfazer o embarque do cliente a partir do local de origem desta viagem, o que leva a que se passe
para a próxima viagem da lista. No caso de ser possível inserir um passageiro, ir-se-á calcular o
tempo de viagem entre o local de origem desta viagem e o local de embarque pretendido e é
verificado se a hora de chegada ao local de embarque se encontra dentro da janela de tempo
requisitada.
Se a janela de tempo é ultrapassada, não será possível satisfazer o pedido nesta viagem e passa-se
a fazer a verificação para a próxima viagem da lista. Não sendo ultrapassada a janela de tempo, ir-se-
á calcular o tempo total de viagem se se inserir de seguida a viagem para o local de desembarque e
verificar se esse tempo não é superior ao atraso máximo que pode ser inserido em todas as viagens
do serviço posteriores à que se está a verificar. Se for possível inserir esse atraso e a hora de
chegada ao local de desembarque estiver dentro da janela de tempo, então estas viagens são criadas
e inseridas no serviço sendo actualizado o horário do serviço e a lotação do veículo.
No caso de não ser possível inserir de seguida a viagem para o local de desembarque, ir-se-á
percorrer as viagens posteriores da lista e verificar se é possível inserir a viagem para o local de
58
desembarque entre elas, realizando verificações iguais às que se realizaram anteriormente, tendo em
conta que as horas de início e fim de viagem terão um atraso igual ao tempo de viagem calculado
para chegar ao local de embarque.
Figura 35. Diagrama representativo do tratamento do pedido quando já existem serviços BoD
mas não existem viagens nem com fim nem com início nos locais pretendidos no pedido.
No fim das verificações, e caso tenha sido possível satisfazer o pedido, ir-se-á actualizar os horários
das viagens do serviço e a lotação do veículo.
Procura todas as viagens do
serviço com hora de início igual
ou superior à hora de início
requisitada e hora de fim
inferior à hora de chegada
requisitada
Para cada serviço existente
Para cada viagem, menos a
última
Calcula tempo de viagem ao
desviar para passar na origem
Para cada viagem posterior à
observada
Calcula tempo de viagem ao
desviar para passar no destino
Hora de
passagem na
origem inferior
à hora de chegada
requisitada?
Hora de chegada
ao destino inferior à
hora de chegada
requisitada?
Calcula tempo de viagem ao
desviar para passar no destino
se se inserir nova viagem.
Hora de chegada
ao destino inferior
à hora de chegada
requisitada?
∑tempos de viagem
inferior ao tempo de
atraso máximo permitido
de todas as viagens
posteriores incluindo
esta?
Sim
Sim
Sim Sim
Ao terminar
Não
Ao terminar
Cria as viagens necessárias
para satisfazer o pedido,
actualizando o horário e
lotação.
Sim
Lotação permite
inserção de um
passageiro?
Sim
Lotação permite
inserção de um
passageiro?
Não
CreateBetterTrips(pedido,serviçosExistentes)
Ao terminar
Hora de início da
viagem inferior à
hora de chegada
pretendida?
Não
Não
Não
Sim
Não
Não
Não
Sim
return(true)
return(false)
∑tempos de viagem
inferior ao tempo de
atraso máximo permitido
de todas as viagens
posteriores incluindo
esta?
59
Chegando a este ponto, se o pedido não foi satisfeito, então ir-se-á verificar se existem autocarros
sem serviço associado para satisfazer o pedido. Se sim, então é criado um novo serviço, tal como
acontece quando ainda não existem serviços e é recebido um pedido de viagem. Caso contrário não
é possível satisfazer o pedido de viagem.
Terminados todos os passos de tentativa de satisfação do pedido de viagem, é verificado se o pedido
foi satisfeito. Em caso negativo, é verificado se existem serviços fixos que permitam satisfazer o
pedido.
Independentemente do pedido ter sido satisfeito ou não, é sempre verificado, neste passo, qual o
meio de comunicação pelo qual o pedido foi realizado. Se este foi realizado via correio electrónico ou
SMS serão criadas as mensagens de resposta respectivas ao sucesso ou insucesso da operação.
No caso de o pedido ter sido satisfeito, é criada uma mensagem de resposta para o sistema para o
cliente contendo a informação de que o pedido foi satisfeito, o autocarro que irá satisfazer o pedido,
os locais de embarque e desembarque e as horas programadas para embarque e desembarque.
No caso de o pedido não ter sido satisfeito por ter sido cancelado durante o seu processamento, o
sistema não faz nada, continuando a processar os pedidos seguintes. Se o pedido não foi satisfeito
no serviço dinâmico nem cancelado mas foram encontrados serviços fixos que permitam o cliente
embarcar e desembarcar nos locais pretendidos na janela de tempo pretendida, então é enviada uma
mensagem para o sistema do cliente contendo a informação de que o pedido não foi satisfeito no
serviço dinâmico, uma lista de carreiras do serviço fixo que permitem ao cliente fazer a viagem
pretendida, seguido de uma lista com os locais de embarque e desembarque pretendidos para cada
carreira e uma lista com os horários de embarque e desembarque programados para essas carreiras
nos locais pretendidos.
Finalmente, se o pedido não foi satisfeito no serviço dinâmico nem foram encontradas carreiras no
serviço fixo que passem pelos locais de embarque e desembarque pedidos, é enviada uma
mensagem ao sistema para o cliente contendo apenas a informação de que o pedido não foi
satisfeito.
4.2.5.2. Algoritmo de Cancelamento de Reserva de Viagem
Tal como foi referido anteriormente, o cliente além de poder fazer reserva de viagens pode também
cancelar uma reserva que tenha sido anteriormente realizada. Tendo em conta que o cancelamento
da viagem deve ser prioritário relativamente à reserva, pois este deve ser logo realizado e não deve
ficar em lista de espera: assim que o sistema recebe um pedido de cancelamento tenta satisfazê-lo
imediatamente.
Assim que é recebido um pedido de cancelamento é verificado no sistema se existe alguma reserva
com número igual ao número de reserva que acompanha o pedido. Se não existe nenhum pedido de
reserva guardado no sistema com número igual ao que acompanha o pedido, então o cancelamento
60
não pode ser efectuado e, dependendo do meio pelo qual foi realizado o pedido, é enviada uma
mensagem de resposta comunicando que o cancelamento do pedido de reserva com o número
pretendido não foi possível devido à inexistência do mesmo.
Se existir algum pedido de reserva guardado com número igual ao número de reserva que
acompanha o pedido, é necessário verificar se o utilizador que tenta realizar esse cancelamento é o
mesmo que realizou a reserva, pois só esse a poderá cancelar. Esta verificação é realizada com base
no meio de comunicação usado para efectuar o cancelamento, ou seja, se o pedido de cancelamento
for realizado via SMS é verificado se o número de telemóvel pelo qual foi realizado o pedido de
cancelamento corresponde ao número de telemóvel associado ao cliente que realizou o pedido de
reserva; no caso de ter sido realizado via correio electrónico, faz a mesma verificação mas
comparando os endereços de correio electrónico. Tendo em conta que também é possível cancelar
uma reserva a partir do sistema (ver Figura 27), a verificação de permissão para cancelar uma dada
reserva fica nas mãos do utilizador que recebe o pedido.
Dependendo do resultado da verificação anterior, o pedido de cancelamento é processado ou não.
No caso de a verificação falhar, e o pedido ser proveniente do sistema para o cliente, é transmitido a
este sistema que o pedido de cancelamento não pode ser processado acompanhado de uma
mensagem explicando que o número de telemóvel ou endereço de correio electrónico não
corresponde ao número de telemóvel ou endereço de correio electrónico do cliente que efectuou o
pedido de reserva.
Quando todas as verificações derem resultado positivo é possível realizar o cancelamento da reserva.
Assim, o próximo passo do algoritmo é verificar o estado em que o processamento da reserva se
encontra, pois, dependendo do seu estado, o processamento do seu cancelamento é realizado de
forma diferente. Se o pedido de reserva se encontra num dos estados “Registado” ou “Em
Processamento”, ou seja, o seu processamento ainda não foi iniciado ou terminado, é apenas
necessário colocar o seu estado como “Cancelado”.
No caso de este já se encontrar no estado “Reservado”, ou seja, o pedido já foi processado e foi
criada/reservada viagem para satisfazer o pedido, para cancelar um pedido de reserva é necessário
realizar mais algum processamento, pois além de ter de se colocar o estado do pedido como
“Cancelado” é também necessário remover o pedido do itinerário do veículo que o iria satisfazer (ver
Figura 36).
Para isso vão-se buscar as viagens que o veículo realizaria para satisfazer o pedido que se pretende
cancelar. Seguidamente verifica-se se existe mais algum pedido já reservado cuja satisfação passa
pela realização da viagem para o local de embarque deste pedido. Se não existe, então não faz
sentido efectuar esta viagem e tem de se remover do itinerário. A mesma verificação é realizada
relativamente à viagem até ao local de desembarque, sendo realizado o mesmo procedimento.
61
Vai buscar as viagens
associadas ao pedido
Viagem de
embarque tem mais
algum pedido
associado?
Viagem de
desembarque tem
mais algum pedido
associado
Sim
Remove viagem de embarque
do pedido a cancelar
Actualiza o número de lugares
livres no veículo entre as
viagens de embarque e
desembarque do pedido
cancelado.
Sim
Marca o pedido como
cancelado
Termina
Actualiza o serviço, deixando o
autocarro parado no último
destino antes da viagem a
remover até atingir a hora de
partida para que chegue ao
próximo destino no tempo
estipulado
Calcula tempo necessário para
percorrer o caminho entre a
origem desta viagem e a
origem da viagem posterior
Não
Remove viagem de
desembarque do pedido a
cancelar
Actualiza o serviço, deixando o
autocarro parado no último
destino antes da viagem a
remover até atingir a hora de
partida para que chegue ao
próximo destino no tempo
estipulado
Calcula tempo necessário para
percorrer o caminho entre a
origem desta viagem e a
origem da viagem posterior
Não
removeTrip(pedido)
Figura 36. Diagrama representativo da remoção de uma viagem existente num serviço.
Na remoção de uma viagem de um itinerário foi considerado que não se deveria alterar o horário das
viagens, pois, a remoção de uma viagem, traria um avanço do serviço, o que poderia resultar em o
veículo chegar antes da hora programada aos locais do seu itinerário. Para colmatar esta situação,
considerou-se que se iria atrasar a viagem, respeitando o horário do itinerário nas viagens
posteriores.
Para remover uma viagem de um itinerário é necessário calcular o tempo de viagem entre a origem
da viagem que se irá remover e o destino da viagem posterior. De seguida, ir-se-á actualizar a
viagem posterior colocando como local de origem a origem da viagem a remover e como hora de
62
início de viagem a subtracção do tempo de viagem calculado anteriormente à hora de chegada dessa
viagem. Por fim a viagem é removida do itinerário, tendo como resultado o veículo ficar parado no
local de origem da viagem actualizada desde a hora de chegada da viagem anterior até à hora de
início calculada.
Para finalizar o cancelamento de pedidos de reserva com estado “Reservado” é actualizada a lotação
do veículo entre as viagens que foram removidas, ou seja, é adicionado um lugar livre nas viagens
posteriores ao local de embarque relativo ao pedido cancelado.
4.2.5.3. Viagens Reservadas
Após o processamento dos pedidos de reserva, e no caso de estes poderem ser satisfeitos, é
possível visualizar os itinerários que cada veículo “on-demand” irá efectuar. Foram implementados
duas vistas para visualização de itinerários: vista em diagrama e vista no mapa.
Figura 37. Ecrã de visualização em diagrama de viagens reservadas num modelo em espinha.
63
Figura 38. Ecrã de visualização em diagrama de viagens reservadas e num modelo em rede.
Na visualização em diagrama (ver Figura 37), que é a vista por omissão do sistema, existe um filtro
pelo qual se pode filtrar a carreira da qual se pretende ver o itinerário, o modo de visualização dos
itinerários, podendo ser em espinha (Figura 37) ou em rede (Figura 38), a data e janelas de tempo
das viagens que se pretendem observar e se apenas se pretende observar viagens que ainda não
tenham sido satisfeitas/terminadas.
No caso de o filtro de carreiras estar definido para “Todas” (valor por omissão para este ecrã), irão
aparecer todas as carreiras que tenham serviços na data seleccionada. Por omissão, e no caso de
não existir valor para a data, a data considerada para filtrar é a data actual. A ordem pela qual os
serviços são visualizados corresponde à ordem apresentada na lista de carreiras. Cada círculo
apresentado representa uma paragem, sendo que as linhas representam uma viagem entre duas
paragens. As viagens são apresentadas pela ordem em que irão ocorrer.
Ao clicar sobre uma paragem é apresentado uma caixa (Figura 39) onde se podem observar os
dados dessa paragem: o veículo que irá passar por lá, o código e nome da paragem, a hora de
chegada programada, o número de pessoas que irão embarcar nessa paragem e o número de
pessoas que irão desembarcar.
64
Figura 39. Caixa com informação dos dados de um local de paragem de um itinerário.
Tal como pode ser observado na Figura 39, se existir alguém que vá embarcar ou desembarcar na
paragem seleccionada, o número de pessoas irá tornar-se carregável abrindo um novo ecrã onde
aparecerá uma lista dos clientes que irão embarcar ou desembarcar (dependendo do que foi
seleccionado) nessa paragem, assim como os seus dados e os dados do pedido (ver Figura 40).
Figura 40. Ecrã com a lista de entradas/saídas numa paragem.
No filtro deste ecrã pode-se visualizar um botão com o texto “Vista Mapa” que ao ser carregado abre
um ecrã como o da Figura 41, onde é apresentado o itinerário da carreira seleccionada no filtro num
mapa. Se a opção seleccionada for “Todas” o itinerário apresentado será o da primeira carreira da
lista. O filtro deste ecrã é semelhante ao do ecrã anterior, diferenciando-se apenas em não conter o
campo do modelo de visualização.
Este ecrã está desenhado para mostrar de forma distinta as viagens já realizadas das que estão por
realizar. Como se pode ver na Figura 41 a linha de desenho das viagens é verde, o que representa
que as viagens já se encontram realizadas. No caso de as viagens ainda não terem sido realizadas
as linhas encontrar-se-ão desenhadas na cor vermelha, como na Figura 42. Embora não exista
nenhum ecrã demonstrativo, no caso de um serviço ainda se encontrar a decorrer, no mapa as linhas
estarão em ambas as cores, em que as que se encontram a verde simbolizam viagens já terminadas
e a vermelho as que se encontram por satisfazer.
65
Figura 41. Ecrã de vista mapa com o itinerário de uma carreira com todo o serviço efectuado e
veículo parado.
Figura 42. Ecrã de vista mapa com o itinerário de uma carreira com todo o serviço por efectuar
e veículo em movimento.
No mapa as paragens encontram-se simbolizadas pelas bandeiras azul esverdeadas e o veículo pela
bandeira vermelha/verde. Como pode ser observado entre a Figura 41 e a Figura 42, a bandeira do
veículo pode ter as duas cores referidas atrás, sendo que quando a bandeira se encontra a verde
66
significa que o veículo se encontra em deslocação e quando se encontra parado numa paragem a
bandeira encontra-se com cor vermelha.
Neste ecrã é também possível ver a bandeira representativa do veículo a deslocar-se entre as
paragens, representando o movimento do veículo à medida que vai satisfazendo os pedidos. Uma
vez que a solução implementada não contempla a ligação com os veículos, o movimento da bandeira
pelo ecrã, assim como as mudanças de cor da bandeira, são apenas simulados na solução.
Figura 43. Balão com os dados de um local de paragem do itinerário que se está a observar.
Tal como acontece no ecrã anterior, ao carregar sobre uma das bandeiras de paragem é aberto um
balão (ver Figura 43) com a mesma informação da caixa do ecrã de vista em diagrama. As
funcionalidades existentes neste balão são as mesmas da caixa.
4.3. Integração das soluções
Sendo que o sistema para o cliente e o sistema para a central são dois sistemas separados foi
necessário arranjar forma de integrar as duas soluções permitindo que comunicassem entre si.
Devido a se pretender a reutilização das soluções e a integração das mesmas com outras soluções
decidiu-se usar Web Services na comunicação entre as duas soluções descritas.
Tal como já foi referido, o uso de Web Services permite a integração de sistemas e a comunicação
entre aplicações diferentes independentemente das plataformas onde estas foram desenvolvidas.
Deste modo a solução para o cliente ou a solução para a central podem ser implementadas noutras
plataformas e serem soluções diferentes das que são aqui descritas desde que disponibilizem os
serviços aqui transmitidos.
No âmbito das soluções especificadas neste trabalho foram criados dois Web Services para permitir
que ambas as soluções interajam entre si: foi criado um Web Service para o sistema do cliente e
outro para o sistema da central. Ambos os Web Services irão ser especificados nas subsecções
seguintes.
4.3.1. Web Service do Sistema da Central
A partir da secção 4.1 pode-se observar que o sistema do cliente necessita de comunicar com o
sistema da central para realizar pedidos de reserva e cancelamento de viagens. Desta forma será
67
necessário que o sistema da central disponibilize serviços que permitam realizar essas tarefas. Desse
modo foi criado um documento WSDL que servirá de contrato entre as duas aplicações.
O documento WSDL encontra-se transcrito no Anexo B deste documento pode ser visualizado o
contrato WSDL definido para este Web Service.
Como pode ser observado a partir do documento WSDL, o sistema para a central disponibiliza os
dois serviços referidos anteriormente. O serviço para reserva de viagem foi chamado de bookTrip e o
de cancelamento cancelTrip.
O serviço para reserva de viagem deve ser invocado tendo como parâmetros um objecto
(BookTripType) do tipo complexo, composto pelos parâmetros arrivalTime (data de embarque
pretendida), departureTime (data de desembarque pretendida), destination (local de destino), email
(endereço de correio electrónico), mobnumber (número de telemóvel) e origin (local de origem) todos
eles do tipo string, ou seja, são compostos por uma cadeia de caracteres. Os parâmetros email e
mobnumber poderão não se encontrar preenchidos, embora para a validação posterior de existência
de clientes seja obrigatório que pelo menos um deles se encontre preenchido.
A invocação do serviço de reserva de viagem (bookTrip) retorna uma resposta do tipo long, ou seja,
um valor numérico, no caso de o processamento não dar erro. No caso do processamento dar erro a
resposta poderá ser uma das duas mensagens de erro definidas no contrato:
ClientNotFoundException, no caso de não existir cliente com número de telemóvel ou endereço
electrónico igual ao que acompanha o pedido, e PlaceNotFoundException, no caso de o local de
embarque ou o local de desembarque ou ambos não existirem registados no sistema.
Por sua vez, o serviço de cancelamento de reserva de viagem (cancelTrip) deve ser invocado tendo
como parâmetro o objecto CancelTripType que é composto pelos parâmetros email (endereço de
correio electrónico), mobnumber (número de telemóvel) e tripID (número de reserva de viagem),
todos eles do tipo string. Tal como acontece no serviço bookTrip, os parâmetros mobnumber e email
não são de preenchimento obrigatório, embora pelo menos um dos parâmetros deva estar preenchido
para validar a existência de cliente registado no sistema.
A invocação do serviço cancelTrip retorna como resposta, no caso do seu processamento não
retornar qualquer erro, uma mensagem comunicando se o cancelamento do pedido de reserva foi ou
não efectuado. No caso de não existir cliente com número de telemóvel ou endereço electrónico igual
ao que acompanha o pedido então a resposta a este serviço é uma mensagem de erro do tipo
ClientNotFoundException.
4.3.2. Web Service do Sistema do Cliente
Como, no caso de pedidos de reserva, o sistema do cliente não deverá ficar à espera da resposta ao
seu pedido, pois poderá levar muito tempo a obtê-la e o canal ficaria aberto não permitindo a
realização de outros pedidos durante esse período de tempo. De modo a colmatar essa falha, o
68
esquema pedido/resposta foi dividido em duas fases: uma primeira em que é realizado o pedido, este
é registado e é devolvido o número de registo do pedido e uma segunda em que é retornada a
resposta de satisfação ou não do pedido realizado.
Logo após o envio da resposta com o número de registo do pedido, a ligação entre o sistema do
cliente e o sistema da central via Web Service é fechada, o que impossibilita um envio de uma
segunda mensagem por essa ligação. Para devolver a resposta ao pedido foi então criado um Web
Service no sistema para o cliente cuja funcionalidade é a de receber a resposta de satisfação ou não
de um pedido de reserva de viagem.
O contrato WSDL do serviço disponibilizado por este Web Service poderá ser observado Anexo B
deste documento.
Tal como pode ser observado no documento WSDL este Web Service apenas disponibiliza um
serviço com o nome setResponseMessage. Este serviço recebe como parâmetros um objecto do tipo
complexo com o nome BookResponse, o qual é constituído pelos campos begin (data de embarque
prevista), destination (local de desembarque), end (data de desembarque prevista), origin (local de
embarque), processed (se o pedido foi satisfeito ou não), responseId (número de registo de reserva),
regular (se o pedido foi reservado num serviço dinâmico ou encaminhado para um serviço fixo) e
vehicle (veículo que irá satisfazer o pedido).
Como a construção do sistema já pressupõe como trabalho futuro a implementação e integração da
solução com o serviço fixo de transporte de passageiros, os campos begin, end, origin, destination e
vehicle podem não ser valores únicos mas sim uma lista de valores contendo os valores
correspondentes dos serviços fixos que poderão satisfazer o pedido realizado. Todos estes valores
são do tipo string, ou seja, cadeias de caracteres e poderão ter o valor nulo no caso do pedido não ter
sido satisfeito.
Os campos processed e regular são do tipo booleano, ou seja, apenas podem conter os valores
verdadeiro ou falso. Se o campo processed tiver o valor true (verdadeiro) indica que o pedido foi
processado e satisfeito sendo que o valor false (falso) indica o contrário. Por sua vez, o campo
regular ao conter o valor true indica que o pedido não foi satisfeito no serviço dinâmico mas existem
serviços fixos que poderão satisfazer o pedido, enquanto que o valor false indica que não existem
serviços fixos que possam satisfazer o pedido.
69
5. Validação da Solução
Nesta secção vão ser descritos alguns testes realizados à solução que irão permitir validar as
funcionalidades desenvolvidas. Todos os testes serão funcionais, verificando se as funcionalidades
implementadas se comportam como pretendido. Com os testes realizados é possível complementar a
explicação do modo de funcionamento do protótipo aqui desenvolvido assim como mostrar o
resultado da execução de cada uma das funcionalidades.
Irão também ser descritas, na secção 5.1, quais as considerações iniciais para iniciar os testes
realizados sobre a solução.
5.1. Considerações Iniciais
Para validar a solução implementada foram criados os dados de simulação necessários para ser
possível realizar pedidos de reserva de viagens on-demand. Para isso foram inseridos locais de
paragem (Tabela 6) e veículos de serviço flexível no sistema para a central. Foram também definidas
as variáveis necessárias (Tabela 7). Os dados inseridos no sistema podem ser observados no Anexo
B. Para a realização dos testes foi também considerado que inicialmente todos os autocarros se
encontram no mesmo parque, neste caso em Santo Amaro, e é daí que irão partir no início de um
serviço.
Para testar o algoritmo criado para cálculo de horários e itinerários foi criada uma página de
simulação onde são definidos os valores de início e fim de simulação e onde é dado um ficheiro do
tipo “.xls” com os dados pretendidos de reserva de viagem.
Antes da realização dos testes foram inicializados ambos os sistemas desenvolvidos, não sendo, por
essa razão, mencionado na realização dos testes a inicialização dos sistemas. Todos os testes foram
realizados em modo de simulação, o que implica que o sistema da central não proceda ao
processamento dos pedidos de reserva de forma automática.
5.2. Testes Funcionais
5.2.1. Teste 1 – Pedido de Reserva de Viagem On-demand
A execução deste primeiro teste vai ser dividido em duas partes: a realização de pedidos de reserva
de viagem via mensagem SMS e a realização de pedidos de reserva de viagem via correio
electrónico. Para não ser necessário estar à espera que a condição de hora mínima para o pedido ser
processado seja satisfeita, foi criada uma data de simulação na qual o sistema se irá encontrar na
recepção dos pedidos, sendo essa data o dia 6 de Setembro de 2010 pelas 22:30.
70
5.2.1.1. Via Mensagem SMS
Na realização deste teste foi usado um simulador de envio de mensagens SMS que já se encontrava
implementado e o qual comunica directamente com o gateway SMS.
Para realizar este teste iniciou-se o simulador de envio de mensagens SMS, inseriu-se o endereço
URL onde se encontra a correr o Gateway SMS, inseriu-se o número de telemóvel representativo de
um cliente existente no sistema e para o qual se pretende que sejam encaminhadas as respostas e
no campo da mensagem inseriu-se o seguinte texto: “X BOD R 1001 201009062300 1005
201009062330” (ver Figura 44). A mensagem inserida indica que se pretende realizar uma reserva de
viagem BoD entre Alfornelos e Alto dos Moinhos, com uma hora de embarque nunca inferior às 23
horas do dia 6 de Setembro de 2010 e hora de desembarque inferior ou igual às 23:30 do mesmo dia.
Figura 44. Simulador de envio de mensagens SMS realizando o envio de um pedido de reserva.
Após o envio da mensagem é necessário aguardar para que o pedido seja enviado para a central,
registado e envie o número de registo do pedido para o sistema do cliente. Só após esse
processamento é enviada a resposta para o cliente, podendo ser vista a resposta a este pedido na
Figura 45. Acedendo à base de dados da solução para o cliente é possível observar que entre o envio
do pedido e o retorno da resposta passaram dois segundos.
Figura 45. Resposta SMS a um pedido de reserva realizado.
Após a recepção da mensagem de pedido registado, pesquisou-se pelo número de pedido no sistema
da central e visualizaram-se os seus dados de registo. Como pode ser observado na Figura 46, o
pedido foi registado no sistema com os dados inseridos na mensagem às 22:30 do dia 6 de Setembro
de 2010.
71
Figura 46. Ecrã com os dados do pedido registado.
Como os testes foram realizados em modo de simulação, o pedido apenas irá ser processado quando
se iniciar a simulação. Desse modo, ao dar início à simulação o pedido é processado e é enviada
uma mensagem ao sistema do cliente com os dados da reserva, no caso do pedido ser reservado. A
mensagem criada a partir desses dados e que é enviada ao cliente pode ser observada na Figura 47.
Figura 47. Resposta SMS confirmando que o serviço irá ser efectuado e quais os seus dados.
Para exemplificar o resultado do processamento do pedido, na Figura 48 é mostrado o itinerário
criado para satisfazer o pedido, sendo que o ecrã representa a vista mapa do serviço do autocarro
com a carreira 4259.
Figura 48. Ecrã com o itinerário que o veículo terá de efectuar para satisfazer o pedido.
72
5.2.1.2. Via Correio Electrónico
Para a realização deste teste apenas é necessário ter-se um provedor de correio electrónico onde se
tenha uma conta registada para proceder ao envio de correio para o serviço.
Para efectuar este teste criou-se uma nova mensagem de correio electrónico inserindo no campo
“Assunto” o texto “X BOD R 1002 201009062300 1008 201009062330” tendo como destinatário o
endereço do serviço (ver Figura 49). O envio desta mensagem mostra que o utilizador pretende
efectuar uma reserva de viagem BoD entre Pontinha e Praça de Espanha, não podendo o serviço ser
iniciado antes das 23:00 do dia 6 de Setembro de 2010 e não podendo terminar depois das 23:30 do
mesmo dia.
Figura 49. Mensagem de pedido de reserva enviada por correio electrónico.
Como a verificação de pedidos via correio electrónico é também efectuado por um scheduler, o tempo
de resposta ao pedido poderá ser um pouco maior, pois é necessário passar o tempo do scheduler
para que o pedido seja lido. Na Figura 50 pode ser observada a mensagem de correio electrónico que
é enviada ao cliente após o pedido ter sido registado no sistema.
Figura 50. Mensagem de correio electrónico informando que o pedido de reserva foi guardado.
Tal como aconteceu no teste anterior, como se realizam os testes em modo simulação, o pedido
apenas irá ser processado quando se der início à simulação e após o seu processamento é enviada
uma mensagem ao sistema para o cliente com os dados da reserva. Por sua vez, o sistema para o
cliente irá preencher os campos necessários da mensagem de correio e enviar para o cliente a
confirmação de serviço reservado (ver Figura 51).
73
Figura 51. Mensagem de resposta enviada por correio electrónico comunicando que o serviço
foi criado e quais os dados que o compõem.
Como já se realizaram alguns passos no teste anterior, neste teste decidiu-se em mostrar apenas o
itinerário que a reserva deste pedido criou (ver Figura 52). Tal como é mostrado no algoritmo, as
viagens criadas para satisfazer este pedido foram inseridas no fim do serviço criado pela reserva do
pedido anterior, pois, como já foi referido anteriormente, o algoritmo considera como essencial a
satisfação dos pedidos minimizando as diferenças entre os dados da reserva enviada ao cliente e os
dados reais, dando preferência a esta situação do que a uma situação óptima de percurso a efectuar.
Figura 52. Vista em diagrama do serviço a efectuar após reserva do segundo pedido.
Outra forma de se verificar o registo do pedido e o seu estado é procurando no ecrã de pesquisa de
pedidos, inserindo no filtro de pesquisa os dados pelos quais se pretende pesquisar. No caso deste
teste pretende-se visualizar os registos para o dia em que se realizaram as reservas, sendo, neste
caso, o dia 6 de Setembro de 2010. Na Figura 53 pode ser visto este ecrã com os pedidos efectuados
no estado “Reservado”, mostrando os dados das viagens do serviço que os irá satisfazer.
Figura 53. Ecrã mostrando o estado e dados dos pedidos após o seu processamento e
respectiva reserva.
74
5.2.2. Teste 2 – Cancelamento de Reserva de Viagem On-demand
Tal como aconteceu com o teste anterior, a execução deste teste também irá ser dividido em duas
partes: o cancelamento de um pedido de reserva via telemóvel e o cancelamento de um pedido de
reserva via correio electrónico.
5.2.2.1. Via Mensagem SMS
Na realização deste teste foi usado o mesmo simulador de envio de mensagens SMS da do teste em
5.2.1.1.
Para realizar este teste voltou-se a iniciar o simulador de envio de mensagens SMS, inseriu-se o
endereço URL onde se encontra a correr o Gateway SMS, inseriu-se o mesmo número de telemóvel
usado 5.2.1.1, e no campo mensagem escreveu-se X BOD C 55041. Com esta mensagem está-se a
transmitir ao sistema que se pretende cancelar o pedido de reserva 55041, que neste caso
representa o pedido de reserva efectuado em 5.2.1.1. Na Figura 54 pode ser observado o simulador
de envio de mensagens SMS com os dados do pedido de cancelamento de reserva preenchidos.
Figura 54. Simulador de envio de mensagens SMS realizando o envio de um pedido de
cancelamento de reserva.
Após o envio da mensagem, carregando sobre o botão “Send”, a mensagem é enviada para o
sistema do cliente que irá guardar os dados do pedido de cancelamento e transmitir esse pedido ao
sistema da central. Após o cancelamento do pedido, e no caso de não haver problemas no seu
processamento, o sistema da central comunica ao sistema do cliente a satisfação do cancelamento.
Por sua vez o sistema para o cliente envia uma mensagem ao cliente transmitindo que o pedido foi
cancelado (ver Figura 55).
Figura 55. Resposta SMS ao pedido de cancelamento efectuado.
75
Figura 56. Ecrã mostrando que o pedido se encontra no estado "Cancelado",
O resultado do cancelamento do pedido pode ser visto no sistema da central procurando pelo número
de registo do pedido de reserva que foi cancelado, e verificar-se qual o seu estado (Figura 56). Como
no caso actual se sabe que o pedido já se encontrava no estado reservado e se sabe qual o itinerário
que o veículo iria efectuar, pode-se também verificar se as viagens correspondentes ao pedido foram
retiradas do serviço, pesquisando pela carreira que iria efectuar o serviço (ver Figura 57).
Figura 57. Ecrã com o diagrama da viagem após o cancelamento do pedido de reserva.
5.2.2.2. Via Correio Electrónico
O comportamento previsto para a realização deste teste é semelhante ao comportamento verificado
no teste 5.2.2.1, diferenciando-se do mesmo no meio pelo qual o pedido é efectuado. Para efectuar o
teste enviou-se uma mensagem de correio electrónico contendo como assunto “X BOD C 55052” (ver
Figura 58). Com o envio desta mensagem pretende-se que o sistema cancele o pedido de reserva
efectuado em 5.2.1.2, ou seja, o pedido com o número de registo 55052.
Figura 58. Mensagem de cancelamento de reserva enviada por correio electrónico.
76
Figura 59. Mensagem de resposta enviada por correio electrónico comunicando que o
cancelamento do pedido foi realizado com sucesso.
Após o envio da mensagem, aguardou-se que o pedido de cancelamento fosse processado e que se
obtivesse uma resposta. A resposta retornada pode ser observada na Figura 59. Para se confirmar o
cancelamento do pedido no sistema da central, realizou-se uma pesquisa pelos pedidos de reserva
efectuados a 6 de Setembro em 2010 e verificou-se qual o estado do pedido 55052. Na Figura 60
pode-se observar a lista de pedidos efectuados na data referida, e tal como esperado o seu estado é
“Cancelado”.
Figura 60. Ecrã mostrando o estado e dados dos pedidos após o cancelamento.
Como se sabe qual o itinerário que iria ser efectuado para satisfazer o pedido, sabe-se à partida que
o cancelamento deste pedido iria cancelar todo o serviço para a carreira que iria satisfazer o pedido,
e, como era o único serviço que foi criado para a data, não deveriam existir serviços para visualizar. A
procura pelos serviços BoD para a data referida, na vista mapa, não deveria apresentar qualquer
resultado, obtendo-se dessa forma o resultado apresentado na Figura 61.
77
Figura 61. Vista mapa mostrando que não há serviços a efectuar.
5.2.3. Teste 3 – Processamento de vários pedidos on-demand
Para testar o algoritmo criado para cálculo dos itinerários e horários a efectuar para satisfação de
pedidos on-demand, foi criada um ecrã de simulação (ver Figura 62) no qual é necessário preencher
a janela de tempo em que se pretende que o serviço corra, de quanto em quanto tempo se pretende
que seja verificado a existência de novos pedidos (campo “Relação de Tempo”) e onde se pode
carregar um ficheiro “.xls” com pedidos de reserva.
O ficheiro “.xls” é composto por cinco colunas, preenchidas da seguinte forma e pela ordem descrita:
número de cliente, data pretendida para início de viagem, nome do local de embarque pretendido,
data pretendida para fim de viagem, local de desembarque pretendido e hora a que se pretende que
seja efectuado o registo do pedido no sistema.
Figura 62. Ecrã para simular o funcionamento do sistema.
Para implementar o modo de simulação foi utilizada a biblioteca SSJ: Stochastic Simulation in Java19
desenvolvida pela Universidade de Montreal, uma vez que permite programar simulação de eventos
discretos. No caso específico deste trabalho, permitiu programar a inserção dos pedidos no sistema
19 http://www.iro.umontreal.ca/~simardr/ssj/indexe.html
78
por ordem cronológica, a simulação do scheduler que irá efectuar verificações de pedidos de reserva
por processar e marcar viagens como satisfeitas à hora indicada.
Antes de se iniciar a simulação criaram-se 100 viaturas on demand com 50 lugares cada para
satisfazer estes pedidos.
A primeira simulação realizada foi composta pela inserção de 6169 pedidos no sistema com hora de
início entre as 22:30 e 1:30. Como o início dos serviços e satisfação das viagens implicam
directamente com o cálculo dos itinerários e horários, considerou-se que a hora de satisfação
realizada dos pedidos é a mesma da hora de satisfação programada. Na Tabela 2 pode ser
observado o resultado da execução desta simulação. Esta primeira simulação levou 56 horas e 18
minutos a finalizar.
Estado Número de Pedidos
Reservado 1079
Não Reservado 5090
Total 6169
Tabela 2. Resultado da execução da simulação sobre os 6169 pedidos.
Como pode ser observado na Tabela 2 a maioria dos pedidos não foram satisfeitos. Por essa razão e
devido ao tempo de processamento levado, no final desta simulação voltou-se a simular o
processamento de pedidos, mas desta vez apenas se inseriram os pedidos que foram satisfeitos na
alínea anterior. Como previsto, todos eles voltaram a ser reservados e o tempo de processamento foi
de aproximadamente 2 horas e 52 minutos., sendo mais próximo do tempo desejável.
Na Tabela 8 do Anexo D são apresentados o número de pedidos realizados por cada viatura na
satisfação dos pedidos inseridos.
79
6. Conclusões
O estudo e solução realizados neste trabalho proporcionam alguns benefícios para o uso e
automatização de serviços de Bus on Demand.
Embora o trabalho aqui realizado não se centrasse na criação e implementação de um algoritmo de
processamento de pedidos on Demand, uma vez que só o algoritmo em si daria tema para uma
dissertação de tese, foi necessário a implementação de um algoritmo para testar a solução. Tal como
pode ser observado na secção 4.2.5.1, o algoritmo desenhado e implementado não é uma solução
óptima e carece de uma série de validações, tais como a minimização das distâncias efectuadas
pelos veículos. Essas validações não foram implementadas por uma questão de rapidez no
processamento dos pedidos.
Porém, e tal como pode ser observado no teste da secção 5.2.3, mesmo não se considerando essas
validações o processamento de um número elevado de pedidos começa a ser incomportável, não
permitindo dar uma resposta em tempo útil. Em [20] pode-se ver que estas questões têm sido
estudadas e que problemas com mais de 100 pedidos podem ser bastante difíceis de resolver
optimamente, podendo tornar-se complicado dar uma resposta em tempo útil. Ao minimizar o número
de pedidos pode-se reduzir o tempo de processamento.
Os resultados obtido na secção 5.2.3, podem ser justificados com base nas janelas de tempo
apertadas a que os pedidos inseridos estavam sujeitos, o que pode originar que não exista tempo
suficiente para os poder satisfazer. Uma vez que antes dos pedidos serem marcados como não
reservados têm de passar por todos os passos do algoritmo, torna-se compreensível que a partir de
um elevado número de pedidos reservados o número de comparações a efectuar seja muito elevado,
o que obriga um maior tempo de processamento.
O número de pedidos não satisfeitos também pode ser explicado pelo tamanho da frota, uma vez que
quanto mais veículos constituirem a frota mais pedidos poderão ser satisfeitos. Por outro lado, pode-
se também concluir, a partir da Tabela 8, que a lotação dos veículos não necessita de ser tão elevada
como a dos veículos de teste utilizados. Deste modo, poder-se-ão usar veículos de menor dimensão,
o que torna o preço da aquisição da viatura mais baixo assim como o seu consumo de combustível.
Finalmente, com este trabalho mostrou-se a possibilidade de automatizar todo o processo de reserva
de viagens on demand, incluindo o cálculo de itinerários e horários, sendo apenas necessário, para
despoletar o processo, a comunicação do pedido por parte do cliente por um meio de comunicação,
no caso deste trabalho, o telemóvel, ou outro dispositivo, que permita o envio de mensagens SMS, ou
um dispositivo que permita o envio de mensagens de correio electrónico.
Com base no uso destas novas tecnologias de comunicação é possível fazer reservas e
cancelamento das mesmas em qualquer lugar. Por outro lado, ao automatizar todo o processo de
reserva e, consequentemente, a resposta à mesma, assim como o cálculo de itinerários e horários,
evita-se a necessidade de existir alguém que efectue a reserva no sistema após comunicação da
reserva, tornando todo o processo mais rápido e evitando falhas.
80
Embora não tenha tido ênfase na realização deste trabalho, assim como na sua descrição, a
funcionalidade de integração com o serviço fixo, que neste trabalho não passou do uso de interfaces
e não teve implementação concreta, passará pelo uso de web services que permitirão a sua
implementação concreta tal como a sua portabilidade. Desta forma, será possível integrar este tipo de
serviço com os sistemas que os operadores já usam desde que estes disponibilizem o serviço e
métodos necessários. Assim, esta solução diferenciar-se-á de outras pois permite aos dois serviços
funcionarem em simultâneo e de uma forma integrada, partilhando informação entre eles.
6.1. Trabalho Futuro
Embora o trabalho realizado se apresente como um contributo para o estudo do tema Bus on
Demand, principalmente na área da automatização da realização de pedidos e sua satisfação,
existem alguns pontos que podem ser melhorados e algum trabalho que poderá ser desenvolvido
para melhorar a solução. Todos os pontos considerados para melhoria irão ser aqui enumerados:
Criar a funcionalidade de comunicação entre o sistema da central e as viaturas, permitindo
saber qual a sua localização e comunicar quais os serviços e itinerários que estas deverão
seguir;
Estender a funcionalidade de cálculo de possibilidade de satisfação dos pedidos em serviço
fixo, uma vez que na realização deste trabalho foi considerado que nunca existiam serviços
fixos para satisfação dos pedidos;
Melhorar e optimizar o algoritmo de satisfação de pedidos e, consequentemente, o cálculo de
itinerários e horários;
Implementar a funcionalidade de escolha das características que se pretendem no lugar que
se irá ocupar na viatura de transporte aquando da realização dos pedidos, permitindo calcular
disponibilidade de lugares para pessoas com mobilidade reduzida;
Estender a funcionalidade de pedidos de reserva para mais de uma pessoa por pedido;
Criar a funcionalidade de realização de pedidos via Internet;
Melhorar o processo de avaliação da solução com base em dados reais.
81
Referências
[1] Lam, Daniel. "Carris vai alugar automóveis à hora a partir de Setembro". Diário de Notícias. 28 de
Abril de 2008.
[2] Projecto Siddharta. Junho de 2003.
[3] Wilson, N. H. M., et al., et al. "Scheduling algorithms for dial-a-ride systems". Urban Systems
Laboratory Report USL TR-70-13. Massachusetts Institute of Technology, 1971.
[4] Bertelle, C., et al., et al. "A Decentralized Approach for the Transportation on Demand Problem".
2007.
[5] Yuba-Sutter Transit, SRTP. "5.Dial-A-Ride Service". Maio de 2008.
[6] Cordeau, J.F., et al., et al. "Transportation on Demand". 14 de Outubro de 2004.
[7] Cordeau, J.F. e Laporte, G. “The Dial-a-Ride Problem (DARP): Variants, Modeling Issues and
Algorithms.”. 4OR - Quarterly Journal of the Belgian, French and Italian Operations Research
Societies. 2003, Vol. 1, pp. 89-101.
[8] Cordeau, J.F. e Laporte, G. “The dial-a-ride problem: models and algorithms”. Annals of
Operations Research. 2007, Vol. 153, pp. 29-46.
[9] Group Trapeze Software. Trapeze PASS, Copyright ©. 2002.
[10] Trapeze. "Case Study: Van Tran of Tucson Inc.". 2002.
[11] Trapeze. "Case Study: Carts improves service with Trapeze PASS". 2005.
[12] Trapeze. "Case Study: Nexus". 2005.
[13] Trapeze. "Case Study: Midttrafik DRT, Denmark". 2006.
[14] SAPRASOL SA Practical Solutions. MJ SCHEDULING_ROUTING SYSTEM.
[15] GIRO Inc. GIRO-ACCES.
[16] GIRO Inc. GIRO-HASTUS .
[17] Li, Y., et al., et al. “Reservation, Scheduling and Navigation System for a Checkpoint DRT
System”. California PATH Research Report. 2007.
[18] Rodrigues, R. G. Gestão em Tempo Real de Serviços de Transporte de Passageiros. Dissertação
de Mestrado em Engenharia Informática e de Computadores. Novembro de 2008.
[19] Carris. Relatório de Contas de 2009. 2010.
[20] Gendreau, M. e Tarantilis, C.D. “Solving large-scale vehicle routing problems with time
windows: The state-of-the-art". Technical Report CIRRELT. Abril de 2010.
82
[21] Psaraftis, H. N. “A dynamic programming approach to the single-vehicle, many-to-many
immediate request dial-a-ride problem.”. Transportation Science. 1980, Vol. 14, pp. 130-154.
[22] Psaraftis, H. N. “An exact algorithm for the single-vehicle many-to-many dial-a-ride problem
with time windows". Transportation Science. 1983, Vol. 17, pp. 351-357.
[23] Sexton, T. e Bodin, L. D. “Optimizing single vehicle many-to-many operations with desired
delivery times: I. Scheduling. II. Routing”. Transportation Science. 1985, Vol. 19, pp. 378-435.
[24] Desrosiers, J., et al., et al. “An algorithm for mini-clustering in handicapped transport.”. Les
Cahiers du GERAD. 1991, Vol. G, pp. 91-102.
[25] Jaw, JJ, et al., et al. “A heuristic algorithm for the multi-vehicle advance-request dial-a-ride
problem with time windows". Transportation Research Part B: Methodological. June de 1986, Vol. 20,
pp. 243-257.
[26] Bodin, L. D. e Sexton, T. ”The multi-vehicle subscriber dial-a-ride problem”. TIMS Studies in
Management Science. 1986, Vol. 2, pp. 73-86.
[27] Ioachim, I., et al., et al. “A request clustering algorithm for door-to-door handicapped
transportation”. Transportation Science. 1995, Vol. 29, pp. 63-78.
[28] Toth, P. e Vigo, D. “Heuristic algorithms for the handicapped persons transportation problem”.
Transportation Science. 1997, Vol. 31, pp. 60-71.
[29] Borndörfer, R., et al., et al. “Telebus Berlin: vehicle scheduling in a dial-a-ride system”. Technical
Report SC 97-23, Konrad-Zuse-Zentrum für Informationstechnik Berlin. 1997.
[30] Cordeau, J. F. e Laporte, G. “A tabu search heuristic for the static multi-vehicle dial-a-ride
problem”. Transportation Research Part B. 2003, Vol. 37, pp. 579-594.
[31] Aldaihani, M. e Dessouky, M. M. “Hybrid scheduling methods for paratransit operations”.
Computers & Industrial Engineering. 2003, Vol. 45, pp. 75-96.
[32] Diana, M. e Dessouky, M. M. “A new regret insertion heuristic for solving large-scale dial-a-ride
problems with time windows”. Transportation Research Part B. 2004, Vol. 38, pp. 539 – 557.
[33] Rekiek, B., Delchambre, A. e Saleh, H. A. “Handicapped person transportation: an application of
the grouping genetic algorithm”. Engineering Application of Artificial Intelligence. 2006, Vol. 19, pp.
511-520.
[34] Xiang, Z., Chu, C. e Chen, H. “A fast heuristic for solving a large-scale static dial-a-ride problem
under complex constraints”. European Journal of Operational Research. 2006, Vol. 174, pp. 1117-
1139.
[35] Wong, K. I. e Bell, M. G. H. “Solution of the dial-a-ride problem with multi-dimensional capacity
constraints”. International Transactions in Operational Research. 2006, Vol. 13, pp. 195-208.
[36] Calvo, R. Wolfler e Colorni, A. “An effective and fast heuristic for the dial-a-ride problem”. 4OR:
A Quarterly Journal of Operations Research. 2007, Vol. 5, pp. 61-73.
83
[37] Ropke, S., Cordeau, J. F. e Laporte, G. “Models and branch-and-cut algorithms for pickup and
delivery problems with time windows”. Networks. 2007, Vol. 49, pp. 258-272.
[38] Melachrinoudis, E., Ilhan, A. B. e Min, H. “A dial-a-ride problem for client transportation in a
healthcare organization”. Computers & Operations Research. 2007, Vol. 34, pp. 742–759.
[39] Jørgensen, R. M., Larsen, J. e Bergvinsdottir, K. B. ”Solving the dial-a-ride problem using genetic
algorithms”. Journal of the Operational Research Society. 2007.
[40] Madsen, O. B. G., Ravn, H. F. e Rygaard, J. M. “A heuristic algorithm for the a dial-a-ride
problem with time windows, multiple capacities, and multiple objectives”. Annals of Operations
Research. 1995, Vol. 60, pp. 193–208.
[41] Teodorovic, D. e Radivojevic, G. “A fuzzy logic approach to dynamic dial-a-ride problem”. Fuzzy
Sets and Systems. 2000, Vol. 116, pp. 23-33.
[42] Colorni, A. e Righini, G. “Modeling and optimizing dynamic dial-a-ride problems”. International
Transactions in Operational Research. 2001, Vol. 8, pp. 155-166.
[43] Coslovich, L., Pesenti, R. e Ukovich, W. “A two-phase insertion technique of unexpected
customers for a dynamic dial-a-ride problem”. European Journal of Operational Research. 2006, Vol.
175, pp. 1605-1615.
[44] Yuba-Sutter Transit SRTP. Dial-a-Ride Service. Dial-a-Ride. May de 2008.
[45] SIDDHARTA. Smart and Innovattive Demonstration of Demand Handy Responsive. 25 de
Novembro de 2005.
I
Anexo A – Síntese de Alguns Algoritmos de DaR
Alg
ori
tmo
Exacto
.
Pro
gra
mação d
inâm
ica.
Exacto
.
Pro
gra
mação d
inâm
ica.
Com
base n
um
a h
eurí
stica
de inserç
ão.
Itera
entr
e a
fase d
e c
álc
ulo
de r
ota
e a
fase d
e c
álc
ulo
de
horá
rios.
Exacto
.
Pro
gra
mação d
inâm
ica.
Ou
tras R
estr
içõ
es
Capacid
ad
e d
o v
eíc
ulo
.
Posiç
ão
máxim
a d
e
deslo
ca
men
to.
Capacid
ad
e d
o v
eíc
ulo
.
Posiç
ão
máxim
a d
e
deslo
ca
men
to.
Capacid
ad
e d
o v
eíc
ulo
.
Capacid
ad
e d
o v
eíc
ulo
.
Jan
ela
s d
e T
em
po
Não c
on
tem
pla
.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
Lim
ite s
uperi
or
do
tem
po p
ara
em
barq
ue
e p
ara
dese
mbarq
ue.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
Ob
jecti
vo
s
Min
imiz
ar
a c
om
bin
açã
o d
e
pesos e
ntr
e a
dura
ção d
o
itin
erá
rio, o t
em
po d
entr
o d
o
veíc
ulo
e o
tem
po d
e e
sp
era
.
Min
imiz
ar
a d
ura
ção d
o
itin
erá
rio e
a insatisfa
ção d
o
clie
nte
.
Min
imiz
ar
o p
eso d
as s
om
as
das d
ifere
nças e
ntr
e o
te
mpo
actu
al e o
dese
jad
o p
ara
chegad
a a
o local de d
estin
o,
e a
s d
ifere
nças e
ntr
e o
tem
po a
ctu
al e o
tem
po d
o
itin
erá
rio m
ais
ráp
ido
possív
el.
Min
imiz
ar
a d
ura
ção d
o
itin
erá
rio.
Refe
rên
cia
Psa
raft
is [
21]
Psa
raft
is [
22]
Sexto
n a
nd
Bo
din
[23
]
Desro
sie
rs e
t al [2
4]
Tabela 3. Sumário de alguns algoritmos para o DARP estático e dinâmico com um veículo.
II
Alg
ori
tmo
Heurí
stica q
ue
sele
ccio
na o
s
utiliz
ad
ore
s c
om
base n
o t
em
po d
e
em
barq
ue p
ossív
el de s
atisfa
zer
mais
rece
nte
.
Inserç
ões d
e f
orm
a q
ue o
aum
en
to
da fu
nção o
bje
ctivo s
eja
mín
imo.
Com
base e
m h
eurí
stica,
constr
ói
conju
nto
s d
e p
assa
geiros p
ara
sere
m s
erv
idos p
elo
mesm
o v
eíc
ulo
.
De s
egu
ida a
plic
a o
alg
oritm
o
refe
rid
o n
a tab
ela
3 (
Sexto
n a
nd
Bod
in),
pod
end
o fazer
mud
anças
entr
e c
on
junto
s.
Com
base e
m h
eurí
stica
.
Cria m
ini-
conju
nto
s e
agru
pa
-os p
or
gera
ção e
m c
olu
na.
Aplic
a a
fase d
e c
álc
ulo
de
horá
rio
.
Ou
tras R
estr
içõ
es
Capacid
ad
e d
os v
eíc
ulo
s.
O tem
po d
e v
iag
em
actu
al do
passage
iro n
ão p
ode
exce
der
mais
que u
ma
perc
en
tag
em
do te
mpo
mín
imo p
ara
a
via
ge
m.
Capacid
ad
e d
os v
eíc
ulo
s.
Vári
os tip
os d
e v
eíc
ulo
s.
Capacid
ad
e d
os v
eíc
ulo
s.
Dura
ção m
áxim
a d
a v
iage
m.
Jan
ela
s d
e T
em
po
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
Tem
po
máxim
o p
ara
a
via
ge
m d
o p
assag
eiro
.
Lim
ite s
uperi
or
no
tem
po p
ara
em
barq
ue
e p
ara
dese
mbarq
ue.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
Ob
jecti
vo
s
Min
imiz
ar
a c
om
bin
açã
o n
ão
linear
de v
ários t
ipos d
e
inutilid
ades.
Min
imiz
ar
o p
eso d
as s
om
as
das d
ifere
nças e
ntr
e o
te
mpo
actu
al e o
dese
jad
o p
ara
chegad
a a
o local de d
estin
o,
e a
s d
ifere
nças e
ntr
e o
tem
po a
ctu
al e o
tem
po d
o
itin
erá
rio p
ossív
el m
ais
rápid
o.
Min
imiz
ar
o n
úm
ero
de
veíc
ulo
s a
usar
e,
seguid
am
ente
, m
inim
izar
o
tem
po d
e d
ura
çã
o d
a
via
ge
m.
Refe
rên
cia
Jaw
et
al
[25
]
Bo
din
an
d S
exto
n [
26
]
Ioach
im e
t al [2
7]
III
Alg
ori
tmo
Inic
ialm
ente
usa u
ma
he
urí
stica q
ue
consis
te e
m a
trib
uir p
edid
os a
os
iten
ários a
part
ir d
e u
m
pro
cedim
en
to d
e inserç
ão e
m
para
lelo
, seg
uid
o p
or
troca
s d
entr
o e
fora
do
itinerá
rio.
Apro
xim
ação
em
duas f
ase
s:
constr
ói u
m g
rupo d
e u
tiliz
adore
s e
agru
pa
-os p
ara
form
ar
itin
erá
rios
pra
ticáve
is. U
sa u
ma h
eurí
stica,
aju
sta
ndo
a f
orm
ula
ção
part
icio
nad
a
resultan
te d
e u
m a
lgori
tmo t
runcado
de b
ranch
-and-c
ut.
Com
base e
m h
eurí
stica
.
Pro
cura
ta
bu c
om
re
inserç
ões e
m
vért
ex, re
moven
do ite
rativa
mente
os
ped
idos d
e tra
nsport
e, re
inserindo
-
os n
um
itinerá
rio.
Heurí
stica d
ivid
ida e
m d
ua
s p
art
es:
um
a f
ase d
e inserç
ão
- re
inserç
ão
ascenden
te, se
guid
o p
or
pro
cura
tabu.
Ou
tras R
estr
içõ
es
Capacid
ad
e d
os v
eíc
ulo
s.
Dura
ção m
áxim
a d
a v
iage
m
do p
assageir
o lim
ita
da p
or
pro
porç
ão à
dura
ção d
a
via
ge
m d
irecta
.
Vári
os tip
os d
e v
eíc
ulo
s.
Capacid
ad
e d
os v
eíc
ulo
s.
Dura
ção m
áxim
a d
a v
iage
m.
Capacid
ad
e d
os v
eíc
ulo
s.
Dura
ção m
áxim
a d
a v
iage
m
do p
assageir
o.
Dis
tância
máxim
a p
ara
o
itin
erá
rio.
Capacid
ad
e d
os v
eíc
ulo
s.
Jan
ela
s d
e T
em
po
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
No te
mpo d
e c
hega
da
da v
iage
m d
e id
a e
/ou
no te
mpo
de p
art
ida
da v
iage
m d
e
regre
sso.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
Ob
jecti
vo
s
Min
imiz
ar
o c
usto
tota
l do
serv
iço.
Min
imiz
ar
os c
usto
s
opera
cio
na
is (
moto
rista
s e
veíc
ulo
s)
Min
imiz
ar
a d
istâ
ncia
perc
orr
ida n
o itinerá
rio.
Min
imiz
ar
a d
istâ
ncia
tota
l
perc
orr
ida p
elo
s v
eíc
ulo
s e
a d
istâ
ncia
tota
l perc
orr
ida
pelo
s u
tiliz
adore
s.
Refe
rên
cia
To
th a
nd
Vig
o [2
8]
Bö
rnd
orf
er
et
al
[29]
Co
rdeau
e L
ap
ort
e [
30]
Ald
aih
an
i e D
esso
uky
[31]
IV
Alg
ori
tmo
Com
base e
m h
eurí
stica.
Pro
ced
ime
nto
de inserç
ão b
asead
o
em
arr
ep
en
dim
ento
para
lelo
.
Alg
oritm
o g
en
ético c
om
ba
se e
m
heurí
stica p
ara
agru
par.
Mecanis
mo
de inserç
ão p
ara
cá
lculo
do
itin
erá
rio.
Com
base e
m h
eurí
stica.
Inserç
ões e
tro
cas p
ara
fora
do
itin
erá
rio s
ão u
sadas p
ara
calc
ula
r o
itin
erá
rio.
Função o
bje
ctivo s
ecu
ndári
a focad
a
no
s tem
pos s
em
serv
iço p
ara
ofe
recer
div
ers
ific
açã
o.
Pro
ced
ime
nto
de inserç
ão e
m
para
lelo
, com
base e
m h
eu
rística
que c
alc
ula
a inco
nveniê
ncia
em
aceitar
o p
edid
o,
dan
do p
riorida
de
aos a
os p
ed
idos m
ais
difíc
eis
.
Pós-o
ptim
ização c
om
rein
serç
ões
noutr
os itinerá
rios e
tro
cas d
e
via
ge
ns.
Ou
tras R
estr
içõ
es
Capacid
ad
e d
os v
eíc
ulo
s.
Tem
po
máxim
o d
e v
iag
em
do
passage
iro.
Tem
po
máxim
o d
e e
spera
nas
para
gens.
Capacid
ad
e d
os v
eíc
ulo
s.
Vári
os tip
os d
e v
eíc
ulo
s.
Capacid
ad
e d
os v
eíc
ulo
s.
Dura
ção m
áxim
a d
a v
iage
m.
Inte
rvalo
s e
máxim
o te
mpo
de
trabalh
o d
os m
oto
rista
s.
Vári
os tip
os d
e v
eíc
ulo
s.
Capacid
ad
e d
os v
eíc
ulo
s.
Dura
ção m
áxim
a d
a v
iage
m.
Dura
ção m
áxim
a d
a v
iage
m
do p
assageir
o p
roporc
ional à
dura
ção d
a v
iage
m d
irecta
.
Jan
ela
s d
e T
em
po
Lim
ite m
ínim
o n
o
tem
po d
e e
mbarq
ue
e
limite
máxim
o n
o
tem
po d
e
desem
barq
ue
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
Ob
jecti
vo
s
Min
imiz
ar
a c
om
bin
açã
o d
e
pesos d
e d
istâ
ncia
, e
xcesso
de te
mpo
de v
iag
em
rela
tivam
ente
à v
iage
m
directa
e te
mpo
de v
iag
em
sem
passag
eiros.
Min
imiz
ar
o n
úm
ero
de
veíc
ulo
s a
usar.
Min
imiz
ar
a c
om
bin
açã
o
linear
dos c
usto
s fix
os e
variáveis
do v
eíc
ulo
, dos
custo
s d
o m
oto
rista
, te
mp
o
de e
sp
era
e t
em
po d
e
serv
iço.
Min
imiz
ar
a c
om
bin
açã
o
linear
do te
mpo
tota
l de
opera
çã
o, te
mpo
de v
iag
em
do p
assageir
o e
custo
s d
e
táxi p
ara
pe
did
os q
ue n
ão
se c
onsig
am
co
locar
em
veíc
ulo
s p
róprios.
Refe
rên
cia
Dia
na e
Des
so
uky
[32
]
Rekie
k e
t a
l. [
33]
Xia
ng
et
al. [
34]
Wo
ng
e B
ell [
35]
V
Alg
ori
tmo
Com
base e
m h
eurí
stica q
ue r
esolv
e
um
pro
ble
ma
de a
trib
uiç
ão.
De
seguid
a insere
su
b-itinerá
rios d
entr
o
do itin
erá
rio
pri
ncip
al, e
torn
a o
s
itin
erá
rios p
raticáveis
, re
aliz
ando o
sequencia
mento
dos n
ovos v
ért
ices
(para
ge
ns).
Alg
oritm
o e
xacto
de b
ranch
-and-c
ut.
Com
base e
m h
eurí
stica,
realiz
and
o
pro
cura
ta
bu c
om
rein
serç
ões e
m
vért
ices.
Com
base e
m h
eurí
stica,
altern
an
do e
ntr
e c
onstr
ução d
e
conju
nto
s p
or
pro
cura
gen
ética e
constr
ução s
eq
uencia
l do itinerá
rio
atr
avés d
e u
m p
roced
ime
nto
pe
lo
viz
inho
ma
is p
róxim
o.
Ou
tras R
estr
içõ
es
Capacid
ad
e d
os v
eíc
ulo
s.
Capacid
ad
e d
os v
eíc
ulo
s.
Dura
ção m
áxim
a d
a v
iage
m
do p
assageir
o.
Dura
ção m
áxim
a d
a v
iage
m.
Vári
os tip
os d
e v
eíc
ulo
s.
Capacid
ad
e d
os v
eíc
ulo
s.
Capacid
ad
e d
os v
eíc
ulo
s.
Jan
ela
s d
e T
em
po
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
de
sem
barq
ue.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
Ob
jecti
vo
s
Min
imiz
ar
um
a c
om
bin
ação
linear
do n
úm
ero
de
utiliz
ad
ore
s s
erv
idos e
o n
ível
de inconven
iência
desses
utiliz
ad
ore
s (
tem
po d
e e
sp
era
e tem
po d
e v
iage
m
excessiv
o).
Min
imiz
ar
o t
am
an
ho
tota
l do
itin
erá
rio.
Min
imiz
ar
um
a c
om
bin
ação
linear
dos c
usto
s d
e
transport
e e
da
inconve
niê
ncia
do u
tiliz
ado
r.
Min
imiz
ar
um
a c
om
bin
ação
linear
do te
mpo
de t
ransport
e,
tem
po d
e v
iagem
do
passage
iro, excesso d
o te
mpo
máxim
o d
e v
iagem
do
passage
iro, te
mp
o d
e e
spe
ra,
vio
laçã
o d
as ja
ne
las d
e
tem
po, te
mp
o d
e tra
balh
o e
excesso d
o te
mpo
de
trabalh
o.
Refe
rên
cia
Wo
lfle
r C
alv
o e
Co
lorn
i [3
6]
Ro
pke e
t a
l [3
7]
Mela
ch
rin
o-u
dis
et
al. [
38]
Jø
rgen
sen
et
al.
[3
9]
Tabela 4. Sumário de alguns algoritmos para o DARP estático com vários veículos.
VI
Alg
ori
tmo
Heurí
stica d
e c
álc
ulo
de
dific
uld
ade
de inserç
ão d
o n
ovo p
edid
o, send
o
este
poste
riorm
ente
inserid
o n
o
itin
erá
rio (
inserç
ão e
m v
ért
ices).
Inserç
ão s
eq
uencia
l dos u
tiliz
ad
ore
s
nos itinerá
rios d
os v
eíc
ulo
s.
São u
sad
as n
ove r
egra
s p
ara
dar
mais
ou m
enos p
eso a
os v
ários
ele
mento
s d
o o
bje
ctivo
.
Altern
a e
ntr
e a
lgoritm
os d
e g
era
ção
de c
on
jun
tos e
gera
ção
de
itin
erá
rios. A
lgori
tmo d
e b
ranch
-and
-
boun
d a
plic
ado
na c
riação d
e
sequência
s d
e c
on
junto
s d
e
utiliz
ad
ore
s c
uja
s ja
nela
s d
e tem
po
não e
stã
o m
uito lon
ge n
o t
em
po
.
Inserç
ão n
os itinerá
rios a
ctu
ais
.
Reoptim
ização d
e itinerá
rio
s c
om
alg
oritm
o m
od
ific
ado a
part
ir d
e
mecan
ism
o 2
-opt.
Ou
tras R
estr
içõ
es
Vári
os tip
os d
e v
eíc
ulo
s.
Capacid
ad
e d
os v
eíc
ulo
s.
Dura
ção m
áxim
a d
a v
iage
m.
Desvio
máxim
o e
ntr
e o
tem
po
de v
iage
m d
o p
assag
eiro e
o
mín
imo p
ossív
el.
Capacid
ad
e d
os v
eíc
ulo
s.
Capacid
ad
e d
os v
eíc
ulo
s.
Dura
ção m
áxim
a d
a v
iage
m..
Desvio
do te
mpo
de s
erv
iço
deseja
do.
Lim
ite m
áxim
o n
o t
em
po d
e
via
ge
m e
xcessiv
o.
Jan
ela
s d
e T
em
po
No te
mpo p
ara
em
barq
ue o
u n
o
tem
po p
ara
desem
barq
ue.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
No te
mpo p
ara
em
barq
ue e
no te
mpo
para
desem
barq
ue.
Ob
jecti
vo
s
Obje
ctivo
mu
lti-
crité
rios.
Min
imiz
ar
função q
ue
incorp
ora
o t
am
anho
do
itin
erá
rio, te
mp
o d
e v
iag
em
do
passage
iro e
vio
lação d
as
jan
ela
s d
e t
em
po.
Maxim
izar
o n
úm
ero
de
ped
idos d
e s
erv
iço o
u
maxim
izar
o n
ível de s
erv
iço
perc
ebid
o o
u m
inim
izar
a
dis
tância
tota
l perc
orr
ida.
Min
imiz
ar
a insatisfa
ção d
o
utiliz
ad
or.
Refe
rên
cia
Mad
sen
et
al
[40]
Teo
do
rovic
an
d
Rad
ivo
jevic
[41]
Co
lorn
i an
d R
igh
ini
[42]
Co
slo
vic
h e
t al.
[43]
Tabela 5. Sumário de alguns algoritmos para o DARP dinâmico com vários veículos.
VII
Anexo B – Contratos WSDL usados na definição dos Web Services
Nesta secção dos anexos estão definidos os contratos WSDL utilizados na construção dos Web
Services usados para a integração das soluções.
Nas linhas seguintes encontra-se transcrito o contrato WSDL usado no Web Service definido para a
solução da central:
(1) <?xml version="1.0" encoding="UTF-8"?> (2) <definitions name="SIBoDService" targetNamespace="http://sibod.link.com/wsdl"
xmlns:tns="http://sibod.link.com/wsdl" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns2="http://sibod.link.com/types" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
(3) <types> (4) <schema targetNamespace="http://sibod.link.com/types"
xmlns:tns="http://sibod.link.com/types" xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://www.w3.org/2001/XMLSchema">
(5) <complexType name="BookTripType"> (6) <sequence> (7) <element name="arrivalTime" type="string"/> (8) <element name="departureTime" type="string"/> (9) <element name="destination" type="string"/> (10) <element name="email" type="string" nillable="true"/> (11) <element name="mobnumber" type="string" nillable="true"/> (12) <element name="origin" type="string"/> (13) </sequence> (14) </complexType> (15) <complexType name="ClientNotFoundException"> (16) <sequence> (17) <element name="message" type="string" nillable="true"/> (18) </sequence> (19) </complexType> (20) <complexType name="PlaceNotFoundException"> (21) <sequence> (22) <element name="message" type="string" nillable="true"/> (23) </sequence> (24) </complexType> (25) <complexType name="CancelTripType"> (26) <sequence> (27) <element name="email" type="string" nillable="true"/> (28) <element name="mobnumber" type="string" nillable="true"/> (29) <element name="tripID" type="string"/> (30) </sequence> (31) </complexType> (32) <complexType name="CancelTripResponseType"> (33) <sequence> (34) <element name="cancelTripRes" type="string" nillable="true"/> (35) </sequence> (36) </complexType> (37) </schema> (38) </types> (39) <message name="SIBoDPT_bookTrip"> (40) <part name="BookTripType_1" type="ns2:BookTripType"/> (41) </message> (42) <message name="SIBoDPT_bookTripResponse">
VIII
(43) <part name="result" type="xsd:long"/> (44) </message> (45) <message name="ClientNotFoundException"> (46) <part name="ClientNotFoundException" element="ns2:ClientNotFoundException"/> (47) </message> (48) <message name="PlaceNotFoundException"> (49) <part name="PlaceNotFoundException" element="ns2:PlaceNotFoundException"/> (50) </message> (51) <message name="SIBoDPT_cancelTrip"> (52) <part name="CancelTripType_1" type="ns2:CancelTripType"/> (53) </message> (54) <message name="SIBoDPT_cancelTripResponse"> (55) <part name="result" type="ns2:CancelTripResponseType"/> (56) </message> (57) <portType name="SIBoDPT"> (58) <operation name="bookTrip" parameterOrder="BookTripType_1"> (59) <input message="tns:SIBoDPT_bookTrip"/> (60) <output message="tns:SIBoDPT_bookTripResponse"/> (61) <fault name="ClientNotFoundException" message="tns:ClientNotFoundException"/> (62) <fault name="PlaceNotFoundException" message="tns:PlaceNotFoundException"/> (63) </operation> (64) <operation name="cancelTrip" parameterOrder="CancelTripType_1"> (65) <input message="tns:SIBoDPT_cancelTrip"/> (66) <output message="tns:SIBoDPT_cancelTripResponse"/> (67) <fault name="ClientNotFoundException" message="tns:ClientNotFoundException"/> (68) </operation> (69) </portType> (70) <binding name="SIBoDPTBinding" type="tns:SIBoDPT"> (71) <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/> (72) <operation name="bookTrip"> (73) <soap:operation soapAction=""/> (74) <input> (75) <soap:body use="literal" namespace="http://sibod.link.com/wsdl"/> (76) </input> (77) <output> (78) <soap:body use="literal" namespace="http://sibod.link.com/wsdl"/> (79) </output> (80) <fault name="ClientNotFoundException"> (81) <soap:fault name="ClientNotFoundException" use="literal"/> (82) </fault> (83) <fault name="PlaceNotFoundException"> (84) <soap:fault name="PlaceNotFoundException" use="literal"/> (85) </fault> (86) </operation> (87) <operation name="cancelTrip"> (88) <soap:operation soapAction=""/> (89) <input> (90) <soap:body use="literal" namespace="http://sibod.link.com/wsdl"/> (91) </input> (92) <output> (93) <soap:body use="literal" namespace="http://sibod.link.com/wsdl"/> (94) </output> (95) <fault name="ClientNotFoundException"> (96) <soap:fault name="ClientNotFoundException" use="literal"/> (97) </fault> (98) </operation> (99) </binding> (100) <service name="SIBoDService"> (101) <port name="SIBoDPTPort" binding="tns:SIBoDPTBinding"> (102) <soap:address location="http://localhost:8080/sibod/sibod"/>
IX
(103) </port> (104) </service> (105) </definitions>
Nas próximas linhas define-se on contrato WSDL definido para a contrução do Web Service usado na
solução para o cliente:
(1) <?xml version="1.0" encoding="UTF-8"?> (2) <definitions name="SIBoDResponseService"
targetNamespace="http://sibod.simip.link.com/wsdl" xmlns:tns="http://sibod.simip.link.com/wsdl" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:ns2="http://sibod.simip.link.com/types">
(3) <types> (4) <schema targetNamespace="http://sibod.simip.link.com/types"
xmlns:tns="http://sibod.simip.link.com/types" xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://www.w3.org/2001/XMLSchema">
(5) <complexType name="BookResponse"> (6) <sequence> (7) <element name="begin" type="dateTime" nillable="true" minOccurs="0"
maxOccurs="unbounded"/> (8) <element name="destination" type="string" nillable="true" minOccurs="0"
maxOccurs="unbounded"/> (9) <element name="end" type="dateTime" nillable="true" minOccurs="0"
maxOccurs="unbounded"/> (10) <element name="origin" type="string" nillable="true" minOccurs="0"
maxOccurs="unbounded"/> (11) <element name="processed" type="boolean" nillable="false"/> (12) <element name="regular" type="boolean" nillable="false"/> (13) <element name="responseId" type="long" nillable="false"/> (14) <element name="vehicle" type="string" nillable="true" minOccurs="0"
maxOccurs="unbounded"/> (15) </sequence> (16) </complexType> (17) </schema> (18) </types> (19) <message name="SIBoDResponsePT_setResponseMessage"> (20) <part name="BookResponse_1" type="ns2:BookResponse"/> (21) </message> (22) <message name="SIBoDResponsePT_setResponseMessageResponse"/> (23) <portType name="SIBoDResponsePT"> (24) <operation name="setResponseMessage" parameterOrder="BookResponse_1"> (25) <input message="tns:SIBoDResponsePT_setResponseMessage"/> (26) <output message="tns:SIBoDResponsePT_setResponseMessageResponse"/> (27) </operation> (28) </portType> (29) <binding name="SIBoDResponsePTBinding" type="tns:SIBoDResponsePT"> (30) <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/> (31) <operation name="setResponseMessage"> (32) <soap:operation soapAction=""/> (33) <input> (34) <soap:body use="literal" namespace="http://sibod.simip.link.com/wsdl"/> (35) </input> (36) <output> (37) <soap:body use="literal" namespace="http://sibod.simip.link.com/wsdl"/>
X
(38) </output> (39) </operation> (40) </binding> (41) <service name="SIBoDResponseService"> (42) <port name="SIBoDResponsePTPort" binding="tns:SIBoDResponsePTBinding"> (43) <soap:address location="http://localhost:8180/sibodResponse"/> (44) </port> (45) </service> (46) </definitions>
XI
Anexo C – Dados Inseridos no Sistema Para Realização de Testes
PlaceID Code Description Address Active
1001 1001 Alfornelos NULL 1 1002 1002 Pontinha NULL 1 1003 1003 Carnide NULL 1 1004 1004 Colégio Militar/Luz NULL 1 1005 1005 Alto dos Moinhos NULL 1 1006 1006 Laranjeiras NULL 1 1007 1007 Jardim Zoológico NULL 1 1008 1008 Praça de Espanha NULL 1 1009 1009 São Sebastião NULL 1 1010 1010 Parque NULL 1 1011 1011 Marquês de Pombal NULL 1 1012 1012 Avenida NULL 1 1013 1013 Restauradores NULL 1 1014 1014 Baixa Chiado NULL 1 1015 1015 Terreiro do Paço NULL 1 1016 1016 Santa Apolónia NULL 1 1017 1017 Alameda NULL 1 1018 1018 Olaias NULL 1 1019 1019 Bela Vista NULL 1 1020 1020 Chelas NULL 1 1021 1021 Olivais Sul NULL 1 1022 1022 Cabo Ruivo NULL 1 1023 1023 Oriente NULL 1 1024 1024 Rato NULL 1 1025 1025 Picoas NULL 1 1026 1026 Saldanha NULL 1 1027 1027 Campo Pequeno NULL 1 1028 1028 Entrecampos NULL 1 1029 1029 Cidade Universitária NULL 1 1030 1030 Campo Grande NULL 1 1031 1031 Quinta das Conchas NULL 1 1032 1032 Lumiar NULL 1 1033 1033 Ameixoeira NULL 1 1034 1034 Senhor Roubado NULL 1 1035 1035 Odivelas NULL 1 1036 1036 Cais do Sodré NULL 1 1037 1037 Rossio NULL 1 1038 1038 Martim Moniz NULL 1 1039 1039 Intendente NULL 1 1040 1040 Anjos NULL 1 1041 1041 Arroios NULL 1 1042 1042 Areeiro NULL 1 1043 1043 Roma NULL 1 1044 1044 Alvalade NULL 1 1045 1045 Telheiras NULL 1 1046 Park Santo Amaro NULL 1
Tabela 6. Dados dos locais de paragem inseridos no sistema.
ConfigName ConfigValue Description Active System
VEHICLE_MEDIAN_VELOCITY
20 Velocidade Média de Veículo 1 True
SIMIP_SIBOD_WEBSERVER_URL
http://localhost:8180/sibodResponse
URL de ligação ao web server disponibilizado pelo SIMIP
1 True
REQUESTS_SCHEDULER
60000 Tempo entre cada pesquisa por pedidos por processar (segundos)
1 True
Tabela 7. Dados de configuração usados.
XII
Anexo D – Número de pedidos realizados por cada viatura
Viatura Pedidos
Satisfeitos Viatura
Pedidos Satisfeitos
Viatura Pedidos
Satisfeitos
2016 20 2050 10 2084 7
2017 13 2051 10 2085 10
2018 9 2052 9 2086 8
2019 10 2053 9 2087 10
2020 10 2054 12 2088 11
2021 13 2055 11 2089 20
2022 10 2056 10 2090 9
2023 11 2057 11 2091 9
2024 13 2058 10 2092 15
2025 8 2059 9 2093 10
2026 10 2060 8 2094 8
2027 11 2061 11 2095 11
2028 9 2062 15 2096 19
2029 8 2063 11 2097 12
2030 11 2064 10 2098 10
2031 9 2065 13 2099 13
2032 9 2066 9 2100 10
2033 12 2067 12 2101 28
2034 11 2068 11 2102 10
2035 10 2069 13 2103 7
2036 10 2070 11 2104 7
2037 10 2071 7 2105 7
2038 9 2072 11 2106 12
2039 10 2073 13 2107 9
2040 7 2074 10 2108 8
2041 13 2075 10 2109 12
2042 8 2076 10 2110 19
2043 12 2077 11 2111 7
2044 11 2078 8 2112 10
2045 13 2079 11 2113 9
2046 10 2080 15 2114 12
2047 10 2081 10 2115 10
2048 9 2082 9
2049 12 2083 9
Tabela 8. Número de pedidos a satisfazer por cada viatura, após o seu processamento.