PROVENDO INFORMAÇÕES PARA ATORES DO SISTEMA DE TRANSPORTE PÚBLICO: UM PASSO NA DIREÇÃO DE

SISTEMAS INTELIGENTES DE TRANSPORTE

Patricia Jaques1, Marcia Pasin2, Leonardo D. Chiwiacowsky1,

Ana L. C. Bazzan3, Rodrigo Moraes1, Rodrigo Bastos1 PIPCA/UNISINOS1, UFSM2, UFRGS3

RESUMO O aprimoramento da mobilidade urbana representa hoje um dos principais desafios enfrentados na busca por uma melhor qualidade de vida nas grandes cidades. Para tanto é necessário o investimento em infraestrutura e uso mais eficiente da tecnologia. Este trabalho foca no segundo aspecto, apresentando alternativas de sistemas que empreguem tecnologia de ponta para o fornecimento de informações a passageiros e provedores de transporte público. Para a implantação destes sistemas, algumas condições devem ser atendidas com suporte à demanda elástica do pedido, usabilidade, disponibilidade, tempo de resposta adequado e resultado correto. Sistemas e ferramentas que visam atender a esses requisitos estão sendo desenvolvidos, bem como um instrumento de gestão automática dos servidores empregados para suportar o funcionamento dos sistemas em questão. ABSTRACT The improvement on urban mobility represents, nowadays, one of the main challenges faced to improve quality of life in the big cities. It requires investments in infrastructure and more efficient use of the technology. In this paper we deal with the latter, focusing on systems for the provision of information for travelers and transit operators. Once deployed, the requirements of these systems include support of elastic demand of request, usability, availability, appropriate time response and correct result. In this paper we describe the tools that we are developing that aim at meeting these requirements, as well as an automatic management of servers for them. 1. INTRODUÇÃO Existe um hiato muito grande entre a implementação das infraestruturas de serviços para facilitar a mobilidade urbana e o crescimento da demanda. Por exemplo, a última pesquisa realizada sobre mobilidade para a região metropolitana de São Paulo (RMSP), disponível em http://www.metro.sp.gov.br, mostra que entre 1997 e 2007 houve um crescimento de aproximadamente 7 milhões de viagens diárias na RMSP, incluindo transporte particular, sendo que aproximadamente 50% são no modo coletivo. Este era o número total de viagens em 1967. O futuro não parece muito diferente. Por exemplo, o DETRAN/RS estima que em 2020 a frota gaúcha terá um acréscimo de 3,3 milhões de veículos (http://abetran.org.br). Embora a demanda seja crescente, provimento de infraestrutura é dificultado devido a problemas como atrasos em licitações, carência de recursos, indisponibilidade de espaço para expansão das vias nos grandes centros urbanos, impacto ambiental, entre outros. O sistema de transporte coletivo mostra-se como uma das alternativas para combater este quadro desfavorável. Como exemplos de soluções a essas dificuldades, e visando a proporcionar uma mobilidade urbana sustentável, as Tecnologias da Informação e Comunicação vêm sendo aplicadas, tendo como principal resultado os Sistemas Inteligentes de Transporte (STI). Dentre essas soluções destaca-se o ATIS (Sistema Avançado de Informação ao Viajante, do inglês Advanced Traveller Information System). Atualmente, existe carência de ferramentas, sistemas e informações voltadas ao transporte

público urbano. Para o usuário de transporte público, especificamente, a ausência de ferramentas ligadas ao provimento de informação resulta em dificuldade de planejamento de percurso (empecilho para a mobilidade eficiente). Igualmente, para os demais atores envolvidos (prefeituras, permissionárias, etc.) existe uma carência de mecanismos que facilitem a compreensão adequada do processo de trânsito (situações emergenciais como acidentes, congestionamentos devido a saídas de eventos, horários de pico, etc.). Neste contexto, este artigo descreve um sistema web integrado de informação ao viajante e às empresas permissionárias. Por meio do monitoramento da frota de ônibus por sensores, o sistema fornece tanto informações ao usuário (itinerários e estimativas de duração da viagem e tempo de espera do transporte) quanto informações sobre o status dos veículos às empresas permissionárias. O sistema é chamado Scorpius e é composto por dois módulos: Antares e Sargas. Antares1 é responsável por prover informações aos usuários de transporte público e Sargas é o módulo responsável por oferecer informações para as empresas permissionárias. Uma vez implantados, estes serviços incluem suporte para grande quantidade de usuários, facilidade de uso, disponibilidade, tempo de resposta adequado, e resultado correto. Para garantir tempo de resposta adequado e disponibilidade de serviço, uma infraestrutura de suporte para gerenciamento autonômico de servidores, previamente desenvolvida, também é descrita. Dada as características dos sistemas desenvolvidos, a contribuição deste trabalho é clara, uma vez que há carência de ferramentas e sistemas abertos para provimento de informações (tanto aos passageiros quanto às permissionárias) e que atuem sobre infraestruturas precárias, levando em conta o desafio de se adequar ao cenário nacional. O restante deste artigo está organizado como segue. Trabalhos relacionados são apresentados na seção 2. O sistema integrado para provimento de informações ao usuário de transporte público urbano e às permissionárias é descrito na seção 3. A infraestrutura de servidores que suporta ambos os serviços é descrita na seção 4. Por fim, a seção 5 apresenta conclusões finais e trabalhos futuros. 2. TRABALHOS RELACIONADOS A necessidade de sistemas para provimento de informação sobre transporte público nos grandes centros urbanos é evidente. Enquanto que este processo está se estabelecendo em muitas capitais internacionais, no Brasil, os projetos se encontram em fase inicial de implantação. Uma questão importante, neste contexto, é que muitas soluções adotadas em grandes centros internacionais não são adequadas, por questões financeiras principalmente, para cidades menores e/ou para países em desenvolvimento ou subdesenvolvidos. Entre as diversas ferramentas comerciais existentes, dois principais sistemas de informação ao usuário têm sido amplamente utilizados: Google Transit e HopStop.com. O Google Transit (2011) é uma aplicação web criada pela empresa Google em que a funcionalidade principal é fornecer rotas de itinerários para o transporte coletivo, sendo também disponibilizada como um recurso do Google Maps (2011). A ferramenta permite ao usuário planejar a sua viagem, disponibilizando o itinerário visualmente (por meio de recursos de mapas) e textualmente. O serviço também integra itinerários a pé e transbordo, quando necessários. Os itinerários são ordenados de acordo com o horário de chegada dos carros, no ponto de parada mais próximo ao local de origem sinalizado pelo usuário. Embora o serviço forneça várias opções de rotas,

1 Antares e Sargas são estrelas da constelação do Escorpião (Scorpius).

uma das limitações é não fornecer alternativas de acordo com critérios diferenciados (por exemplo, duração da viagem, menor número de transbordos, menor trecho a pé, compreendendo facilidades de acessibilidade, atratividade do itinerário, entre outros). Uma outra limitação é que as informações relacionadas aos horários dos carros e duração da viagem são baseadas em tabelas fixas de horários. Assim, embora o Google Maps seja um serviço interessante para calcular itinerários, ele nem sempre é eficiente, uma vez que as opções de linhas escolhidas são baseadas em tabelas fixas de horários. Os congestionamentos, estilos de direção do motorista, entre outras variáveis, fazem com que os horários de tabelas nem sempre possam ser respeitados pelas empresas permissionárias. Além disso, as funcionalidades do Google Transit estão disponíveis apenas em algumas capitais brasileiras. O HopStop (2011) é uma aplicação semelhante ao Google Transit, onde o usuário informa endereços de origem e destino e o sistema gera a rota a ser percorrida, incluindo, inclusive, outros meios de transporte como táxi e metrô. É um serviço que está disponível apenas para algumas grandes cidades dos Estados Unidos e do Canadá. Embora HopStop apresente algumas opções a mais que o Google Transit para gerar os itinerários (por exemplo, menor ou maior número de transbordos), os itinerários também são baseados em tabelas fixas de horários, gerando os mesmos inconvenientes relacionados à perda de transferências de linhas. Iniciativas interessantes no Brasil para provimento antecipado de informação ao passageiro de transporte público, fornecidas por prefeituras, são o sistema da EPTC/Porto Alegre (http:// www.eptc.com.br) e o sistema Olho Vivo da prefeitura de São Paulo (http:// olhovivo.sptrans.com.br). No sistema da EPTC, informando destino e origem, obtém-se possibilidades de veículos que cumprem determinado trajeto. O Olho Vivo, que está em fase piloto operando apenas sobre alguns trajetos em São Paulo, permite saber em tempo real, via dispositivo móvel, o horário aproximado que um ônibus alcança uma parada. Quanto ao provimento de informações aos órgãos gestores e/ou empresas permissionárias, existem ferramentas comerciais. Mentor Streets Transit (http://www.mentoreng.com/), FLASHNET (http://www.swarco.com), Fleet Focus Transit (http://www.assetworks.com/ fleet-management-software/), IVU.FLEET (http://www.ivu.com/) são alguns exemplos. Estas ferramentas apresentam características muito úteis, inclusive algumas podem ser usadas tanto em modo standalone, para simulação, por exemplo, ou em modo tempo real. Contudo, são soluções proprietárias e requerem investimento substancial na implantação e na manutenção do serviço, o que é inviável para a realidade de muitas cidades brasileiras. Iniciativas acadêmicas nacionais existem, porém trabalhos são muito iniciais e pontuais (notadamente dissertações de mestrado). No que tange a academia, a ferramenta INITRANS (STAIB & GERLAND, 1999) é um exemplo de sistema que começou no meio acadêmico (na Alemanha) mas tomou status de ferramenta comercial depois de mais de 20 anos de investimentos. No contexto nacional, a EPTC/Porto Alegre tem uma iniciativa pioneira no projeto SOMArt (LADEIRA et al., 2009). O SOMart é um sistema que permite obter informações sobre a frota de transporte público em tempo real, que está sendo implementado e usado desde 1997. De forma geral, existe uma carência de ferramentas, aplicações e sistemas de informação que permitam o entendimento, o monitoramento e o planejamento, por parte das instituições de serviços de transporte público urbano, além do provimento de informação para o usuário. Estas ferramentas e sistemas, se implementados de forma adequada (desempenho eficiente, resultados corretos e em tempo hábil, disponibilidade, e facilidade de uso), podem oferecer suporte interessante para observação, controle, previsão e simulação de diferentes cenários.

3. SCORPIUS: SISTEMA INTEGRADO DE INFORMAÇÃO AO VIAJANTE E ÀS EMPRESAS PERMISSIONÁRIAS Esta seção descreve o sistema Scorpius que está em desenvolvimento pelos grupos de pesquisa das Universidades UNISINOS, UFRGS e UFSM. Scorpius é um serviço web que compreende dois principais módulos de informação, disponibilizadas graficamente e textualmente: (i) um módulo de informação ao usuário; e (ii) um módulo de informação aos órgãos gestores. O primeiro é responsável por disponibilizar aos usuários informações que lhes auxiliem a planejar a sua viagem de forma a reduzir o tempo de transbordo e a duração da mesma. As informações disponibilizadas podem ser de diferentes tipos, destacando-se: opções de itinerários de acordo com critérios diferenciados a serem definidos pelos usuários; horário de chegada dos veículos nos pontos de interesse, e duração da viagem. O segundo módulo possibilita aos órgãos gestores o provimento de informações para o monitoramento e planejamento de serviço de transporte público. Mais especificamente, as informações que este módulo oferece incluem horários de saída e chegada de cada veículo nas paradas, velocidade média dos veículos, posição atual dos veículos, quantidade de passageiros transportados em um dado instante, nível de combustível de cada ônibus em um dado instante, e informações mais elaboradas como, por exemplo, a detecção de comboios e cálculo da quantidade adequada de veículos em cada via. Todas as informações são disponibilizadas via internet, trazendo duas principais vantagens. Primeiramente, o sistema não está suscetível à depredação, como geralmente acontece com os painéis localizados nos pontos de ônibus dos grandes centros urbanos. Em segundo, essa alternativa permite que o usuário possa planejar sua viagem com antecedência e no ambiente que lhe for mais conveniente (casa, trabalho, se locomovendo à estação, etc).

Para as informações relacionadas a horários e duração da viagem, assim como para monitoramento da frota, é necessária uma infraestrutura física que permita a coleta de dados sobre a frota de veículos. Sensores e dispositivos de GPS precisam ser instalados em cada ônibus para obter informações como hora atual, código de identificação e posicionamento do ônibus, e hora de chegada do ônibus em cada parada. Estas informações são enviadas a servidores (e armazenadas em bases de dados) que oferecem suporte para ferramentas e sistemas de informação. Sensores podem ser colocados em ônibus ou em paradas de ônibus. 3.1 Provimento de informações ao usuário O módulo Antares (BASTOS & JAQUES, 2010; FREITAS et al., 2011) tem por objetivo fornecer informações descritivas e visuais sobre trajetos de linhas (de ônibus) e estimativas de tempo de espera e viagem de um trajeto. A partir de endereços (nome da rua e número) de origem e destino, o sistema identifica quais linhas de ônibus o usuário pode utilizar, e também fornece uma estimativa do tempo de espera e duração da viagem. Um diferencial do Antares é o cálculo de conexões visando trajetos mais longos. O sistema pode informar trocas de ônibus quando necessárias, assim como trechos a pé iniciais (da origem até uma primeira parada), finais (da última parada até o endereço de destino) e intermediários (trechos entre duas paradas envolvendo uma conexão). A ferramenta ilustra visualmente deslocamentos a serem percorridos via transporte público (ônibus) por meio de um sistema de mapas geográficos Google Maps. A descrição do deslocamento é também fornecida textualmente na interface. A Figura 1 apresenta a atual interface web do Antares.

48

Figura 35. Exemplo de Trajetória de Ônibus.

Figura 36. Número da parada da trajetória do exemplo da Trajetória de Ônibus.

Caso o usuário tenha escolhido trajetórias a pé e de ônibus, o sistema mostrará a

integração de trajetórias a pé e de ônibus, por isso serão exibidos os pontos de ônibus,

esquinas e pontos turísticos, como pode ser visualizado à direita na Figura 37. A descrição da

trajetória é ilustrada à esquerda na Figura 37.

Figura 1 – Interface web do Antares

3.1.1 Calculando trajetos e conexões Para determinar trajetórias e deslocamentos a serem sugeridos ao usuário, a ferramenta faz uso do algoritmo de busca A*. Atualmente, o sistema calcula para o usuário o melhor trajeto possível (trajeto com a menor distância em metros). A versão atual está sendo estendida para fornecer diversas opções de trajetos para o usuário escolher, com base em diferentes critérios, por exemplo, itinerários com menor tempo de conexão, com menor duração, com menor tempo de espera, ou ainda o itinerário com características mais turísticas. Mais informações sobre o algoritmo de trajetos utilizado no Antares são encontradas em (BASTOS & JAQUES, 2010; FREITAS et al., 2011). 3.1.2 Estimando a duração da viagem Além das informações relacionadas a trajeto, está sendo desenvolvido um módulo de previsão de tempo para o sistema Antares. Informações relativas aos tempos de espera por ônibus, atualmente, são utilizadas em diversos países com o objetivo de promover o transporte público junto aos usuários. Devido às diversas variações do trânsito nas cidades e dos erros nas medições efetuadas pelos equipamentos utilizados, as técnicas computacionais que efetuam a previsão devem ser capazes de se adaptar às alterações do ambiente (sistema de trânsito). No sistema Antares, para efetuar a previsão dos tempos de trajeto nos trechos a serem percorridos, é utilizado o método matemático do Filtro de Kalman. Esta metodologia utiliza um conjunto de fórmulas matemáticas baseadas na dinâmica do processo em estudo e do sistema de medidas, levando em consideração os seus níveis de incerteza e também qualquer informação sobre o estado inicial das variáveis de interesse (MAYBECK, 1979; WELCH & BISHOP, 2006). O desenvolvimento do algoritmo com base no Filtro de Kalman segue as seguintes etapas: modelagem do processo, modelagem de incertezas do processo e das medidas, e execução. A primeira etapa consiste em descrever o processo de previsão de tempos de espera na forma de um sistema linear, baseado na modelagem física do fenômeno considerado. Na segunda

etapa é realizada a modelagem estatística das variações inerentes ao processo de previsão e às medidas empregadas. Neste trabalho as variações são representadas pela variância do tempo estimado de percurso em cada trecho, resultante dos dados históricos gerados a partir do simulador. As medições, por sua vez, têm suas variações estimadas com base no tempo que o ônibus anterior utilizou para percorrer os mesmos trechos. Com isto, agrega-se ao processo de estimação baseado no Filtro de Kalman o estado atual das vias de trânsito. Após as etapas de modelagem, ocorre a etapa de execução do algoritmo propriamente dita. Para a previsão do tempo de espera, o algoritmo considera os trechos existentes entre a localização atual do ônibus e a parada onde o usuário aguarda pelo ônibus. Na previsão do tempo de viagem, são considerados os trechos existentes entre a parada na qual o passageiro se encontra e a parada de destino da viagem. Na versão atual do sistema Antares, as previsões são realizadas também com o uso de uma ferramenta de simulação criada especialmente para o projeto, baseada no simulador SUMO (Simulation of Urban MObility) (http://sumo.sourceforge.net/). O algoritmo baseado no Filtro de Kalman, utilizado no sistema Antares, segue a proposta descrita em (VANAJAKSHI et al., 2009), com algumas importantes modificações que visam aprimorar as estimativas de tempo por meio do emprego dos dados históricos de previsões. Esta informação pode ser utilizada para aprimorar a modelo físico utilizado no processo de previsão, através da inserção de grandezas que modifiquem a estimativa, com base em valores observados no passado e suas respectivas taxas de ocorrência. 3.1.3 Aspectos de implementação Elaborada inicialmente para executar na internet, a ferramenta foi construída com uso da linguagem de programação Java, utilizando como base o padrão de projeto Model View Controller (MVC). Além disto, outras tecnologias foram utilizadas na sua construção, como o framework Java Server Faces (JSF) (http://www.javaserverfaces.org/) na camada de apresentação e o Hibernate (http://www.hibernate.org) na camada de persistência. Os principais desafios encontrados na construção desta ferramenta incluíram a modelagem, a base de dados e o acesso às informações geográficas (ruas, paradas, intersecções) necessárias para a definição das trajetórias. Em (BASTOS & JAQUES, 2010; FREITAS et al., 2011) são descritas avaliações realizadas no serviço de trajetórias do Antares. O sistema foi avaliado em dois aspectos. Primeiramente, a interface foi avaliada pelos usuários segundo aspectos de usabilidade (interface exibe informações de maneira clara e concisa). De maneira geral, a interface web do Antares foi bem avaliada pelos usuários, que sugeriram algumas informações adicionais de trajetos (por exemplo, mostrar várias opções de trajetos ao invés da apenas o trajeto mais curto). A segunda avaliação buscava verificar se o algoritmo A* estava realmente calculando o trajeto ótimo (trajeto com menor custo) para os casos testados. Como o A* é um algoritmo ótimo, um comportamento inesperado nos testes poderia sugerir uma modelagem incorreta dos dados (estados) ou o uso de uma heurística não admissível. O serviço de estimativa de tempo de espera e de duração da viagem foi avaliado com dados provenientes de simulações, uma vez que dados reais não estão disponíveis apesar do grupo ter contactado as empresas permissionárias visando a instalação de aparelhos GPS em sua frota. Atualmente, o grupo trabalha nos aprimoramentos necessários ao algoritmo do Filtro de

Kalman, para previsão de tempo, e na utilização dessas informações de previsão de tempo para fornecer o trajeto com menor duração de percurso e tempo de espera. Além disso, tem sido investigada a possibilidade do emprego de técnicas de paralelismo para aperfeiçoar o desempenho do algoritmo A*. 3.2 Provimento de informações às empresas permissionárias Sargas é o módulo do projeto responsável por prover às empresas permissionárias, prefeituras e demais instituições interessadas, acesso amigável às informações sobre transporte público urbano. O principal objetivo é oferecer informações operacionais e gerenciais para permitir o planejamento e posterior melhoria da qualidade do serviço de transporte oferecido. Mais especificamente, Sargas disponibiliza as seguintes informações às permissionárias: posição atual dos veículos no sistema, quantidade de passageiros transportados diariamente, destaque de trajetos de linha (de ônibus) mais sobrecarregados (ou mais ociosos) ou ainda informação sobre gasto de combustível e estimativa de autonomia dos carros em circulação. Também é importante prover informações de pós-processamento que facilitem o planejamento, tais como aquelas que medem o efeito do nível de serviço das vias (que é função do volume de tráfego). Por exemplo, dado um determinado nível de serviço, permitir uma estimativa do número de carros a serem alocados a uma determinada linha de ônibus. Uma interface gráfica para provimento destas informações foi implementada para o módulo Sargas. O sistema Sargas está sendo implementado em dois componentes distintos descritos a seguir. 3.2.1 Provimento de informações online Características interessantes de uma interface de monitoramento para o sistema de transporte público incluem: (i) monitoramento dinâmico (a partir de dados previamente fornecidos por uma base de dados, a interface gráfica mostra dinamicamente o movimento dos veículos por meio de trajetos previamente definidos), (ii) geração de relatórios e obtenção de dados estatísticos, e (iii) possibilidade de execução de simulações para previsão de cenários futuros. Simulações podem ser efetuadas tomando por base as condições de tráfego atuais e propondo alterações como por exemplo a adição ou remoção de uma parada no trajeto, adição ou remoção de ônibus no trajeto, ou parada de um veículo para simulação de acidente. Além dessas características, assim como no sistema Antares, o sistema Sargas também tem como objetivo prover usabilidade (a ferramenta deve ser simples de usar por não especialistas) e mobilidade (disponibilidade a partir de qualquer computador por meio de um navegador de internet). A partir destas características, foi desenvolvido o sistema Sargas composto pelo módulo de entrada de dados, processamento, visualização, e pós-processamento para simulações. O módulo de entrada de dados é abastecido com informações estáticas sobre os ônibus, paradas e trajetos, previamente armazenadas em tabelas em um banco de dados. Sensores coletariam dados dinâmicos sobre posicionamento de ônibus, velocidade, volume no tanque de combustível e os enviam em tempo real para atualizar a base de dados. Esses dados seriam recuperados a cada intervalo fixo de tempo para visualização na interface. No sistema Sargas, ícones representando ônibus e paradas são dispostos em um mapa real obtido via Google Maps. Existem duas áreas no módulo de visualização: mapa indicando trajetos, ônibus e paradas, e área de interação com o usuário comportando informação textual e/ou botões para permitir a execução de simulações. O usuário pode, a qualquer momento, por exemplo, clicar em um ícone do tipo ônibus e obter informações sobre o ônibus indicado.

Informações computadas pelo módulo de processamento incluem: (i) horários de saída e chegada de cada veículo nas paradas e sua velocidade média, (ii) posição atual de cada ônibus, (iii) número de passageiros por ônibus em um dado instante, (iv) nível de combustível em cada ônibus em um dado instante, e futuramente (v) detecção visual de comboios. 3.2.2 Provimento de informações do pós-processamento O módulo de pós-processamento do sistema Sargas permite a execução de simulações para analisar e, conseqüentemente, melhorar o serviço oferecido pelas empresas permissionárias. A Figura 2 mostra a interface que permite à empresa permissionária simular as situações de interesse. Por exemplo, a empresa pode avaliar o desempenho de determinadas linhas de sua frota dado um nível específico de tráfego/serviço na rede. Este recurso de simulação permite estimar o tamanho da frota, entre outros aspectos de interesse das empresas permissionárias.

Figura 2 - Interface gráfica da ferramenta web para simulação do nível de serviço

3.2.3 Implementação Foi implementado um protótipo do serviço de informação online usando como base a API Google Maps v3 usando linguagem PHP. Entretanto, esta implementação se mostrou insuficiente, com dificuldade para representar vários ícones em movimento no mapa. Uma nova implementação foi inicializada em um ambiente mais dinâmico. Os serviços de provimento de informações sobre ônibus e paradas foram concluídos, no entanto as informações dinâmicas de sensores (volume do tanque e número de passageiros) e localização dos ônibus são simuladas na versão atual do sistema. Isso se deve ao fato do grupo não ter encontrado ainda empresas permissionárias parceiras com aparelhos GPS instalados em ônibus. O serviço de detecção de comboios está implementado. A interface gráfica da ferramenta web para simulação do nível de serviço foi implementada tendo como base o simulador SUMO. Uma vez concluídos todos os serviços disponibilizados pelo sistema Sargas, informações relevantes poderão ser avaliadas estatisticamente. Por exemplo, para fins de cálculo do valor final da passagem, poderá ser feita uma contagem considerando a tipologia dos usuários que utilizam o transporte, isto é, avaliar o número médio de usuários isentos ou com desconto nos valores das passagens. Para tanto, é necessário ter acesso aos perfis dos usuários (previamente armazenados no banco de dados) e aos dados obtidos pela catraca eletrônica (coletados em tempo real). Informações estatísticas como esta não precisam ser computadas em tempo real, mas poderão ser calculadas mais tarde, quando determinado ônibus finalizar um percurso ou ainda no final de uma jornada de trabalho.

4. INFRAESTRUTURA AUTONÔMICA DE SUPORTE De forma geral, as aplicações de internet, devido ao grande número de requisições diárias, precisam ser executadas sobre uma infraestrutura computacional robusta que seja formada por um grupo de servidores (cluster ou rede de computadores). No caso de ATIS, a demanda de serviço sobre esta infraestrutura é elástica e pode oscilar entre ociosa (durante a madrugada) e alta (em horários de pico, saída de eventos esportivos, etc.) ou ainda apresentar um número estável de requisições. A demanda elástica pode tornar o número de servidores, inicialmente previsto para executar uma aplicação, inadequado. Uma alternativa para coordenar uma infraestrutura de servidores que suportam aplicações elásticas é usar uma infraestrutura autonômica de serviços (KEPHART & CHESS, 2003). O uso de computação autonômica para gerenciar servidores não é um assunto novo e alguns sistemas foram recentemente propostos. Entretanto, sistemas existentes são ou demasiadamente gerais (ROBLITZ et al., 2004; BOUCHENAK et al., 2006) ou muito específicos (SALEEM & CHEN, 2008), não focando nas características de ATIS, a serem evidenciadas a seguir. Outra alternativa é aproveitar serviços privados de virtualização e cloud comerciais (Amazon, IBM, HP, etc.) para suportar ATIS. Uma dificuldade, no entanto, é escolher a priori uma configuração de cloud adequada às necessidades da aplicação-alvo. Outro ponto contra o uso de serviços privados é a falta de controle da localização física dos dados e ajuste mais preciso de processamento (consultas de aplicação ATIS são relativamente ágeis e relativas a uma cidade específica, e possuem algum tipo de restrição temporal). É interessante que a infraestrutura do ATIS não apenas suporte demanda elástica de requisições de clientes de forma automática, mas também que ofereça baixo custo de implantação e manutenção. Uso racional de energia é também uma característica importante. Outra característica interessante é a antecipação de mudanças de cenário com a finalidade de prover serviço realmente eficiente. Finalmente, outro desafio é tratar mudanças momentâneas, como picos de carga abruptos e de duração breve, que não justifiquem reconfiguração (adição ou remoção de servidor) na infraestrutura de serviços. 4.1 Serviços da infraestrutura de suporte Com a finalidade de contemplar todas estas características e tendo como sistema-alvo um ATIS, um sistema de auto-gerenciamento foi proposto (PASIN et al., 2012). O sistema é baseado em serviços independentes e distribuídos (portanto robustos a diversos tipos de falhas), que coletam informação da infraestrutura computacional e desencadeiam adaptação dinâmica, como por exemplo reconfiguração de servidores. Mais especificamente, o sistema de auto-gerenciamento destaca as seguintes características: (i) auto-gerenciamento é executado com suporte à decisão de ações futuras não somente com base em métricas atuais, mas com base em dados históricos, (ii) economia de recursos, uma vez que em períodos de ociosidade, servidores excedentes são removidos da infraestrutura e podem ser alocados a outras aplicações ou operar em standby, (iii) suporte estratégico para manutenção de servidores em virtude de picos de carga momentâneos, uma vez que o custo da execução da operação de reconfiguração é relevante e precisa ser levado em consideração, (iv) suporte para a evolução de serviços: como os serviços são implementados independentemente, um serviço pode ser facilmente substituído, sem a necessidade de interromper completamente o funcionamento do sistema, (v) tolerância a falhas para serviços de auto-gerenciamento já que esses serviços podem ser replicados, (vi) estratégia para detecção de conflitos em caso de tomada de ações antagônicas, já que os serviços operam com independência.

O sistema de auto-gerenciamento dispõe de um conjunto de serviços independentes que garantem políticas implementadas por regras pré-definidas, que buscam assegurar as propriedades autonômicas de auto-otimização e auto-cura. De modo geral, auto-otimização significa adaptar o número atual de servidores ativos em face à demanda elástica. Esta propriedade é implementada, principalmente, pelos serviços de reconfiguração e detecção de picos de carga e ociosidade. Auto-cura significa restaurar o serviço em presença de falhas e ataques. Esta propriedade é implementada, principalmente, pelos serviços de detecção de falhas e de reconfiguração. Se um servidor falha, ele não estará disponível para atender às solicitações dos usuários e deve ser excluído logicamente da infraestrutura computacional. 4.2 Arquitetura da infraestrutura de suporte O conjunto de serviços independentes orquestra servidores e respectivos bancos de dados, usando informações previamente armazenadas e informações atuais obtidas por meio de sensores instalados na própria infraestrutura. A arquitetura do sistema de auto-gerenciamento é composta por múltiplas camadas, conforme Figura 3: (i) serviços de auto-gerenciamento propriamente ditos, (ii) suporte de comunicação de grupo, (iii) agentes de software, e (iv) coleta de informação da infraestrutura de servidores por meio do uso de sensores. Cada serviço independente é implementado por um grupo de processos analisadores, que monitora constantemente servidores da infraestrutura por meio de sensores. Comunicação de grupo é usada para facilitar a comunicação entre processos analisadores, distribuídos pela infraestrutura e com o objetivo de prover suporte adequado em presença de falhas.

Figura 3 - Esquema do sistema de gerenciamento automático de servidores

Mais especificamente, os serviços de auto-gerenciamento incluem: balanceamento de carga, detecção de falhas, detecção de picos de carga e ociosidade, reconfiguração, replicação de estado e transferência de estado. O serviço de balanceamento de carga opera na distribuição de requisições entre os servidores operacionais, seguindo uma política pré-estabelecida. O serviço de detecção de falhas detecta falhas de crash em nodos que compõem a infraestrutura, executado com o suporte do serviço de comunicação de grupo. Eventos são detectados por sensores e são avaliados pelos processos analisadores usando re-gras pré-definidas. Eventos são informações extraídas de cada nodo da infraestrutura (taxa de ocupação da CPU, ocorrência de falhas, pico de carga e ociosidade). Cada um desses eventos é coletado por um sensor diferente e é classificado em algumas classes como, por exemplo, avisos ou alertas. Os alertas são manipulados pelos analisadores usando um sistema baseado em regras, e, possivelmente, são combinados com outros eventos dentro de uma janela de

tempo. Regras podem, então, acionar a execução de reação associada, que pode ser executada por atuadores (ou serviços) diferentes. A janela de tempo é implementada pela correlação entre eventos atuais e históricos, em um mecanismo de série temporal. Este mecanismo pode evitar adaptação desnecessária devido a pico momentâneo de carga, por exemplo. Analisadores podem estar replicados para evitar um ponto único de análise, e assim, mesmo em caso de falha, prover alta taxa de disponibilidade. Entretanto, conflitos podem ocorrer em virtude desta replicação, devido aos serviços serem implementados de forma independente. Dessa forma, uma estratégia para detectar e resolver conflitos é necessária. Por exemplo, se duas instâncias do serviço de detecção de picos de carga e ociosidade, que está replicado devido à necessidade de tolerância a falhas, detectam concorrentemente que a carga do sistema é baixa e solicitam, concorrentemente, a remoção de um servidor, então o sistema irá remover dois servidores quando a remoção de apenas um servidor já seria suficiente. Como resultado, o número de servidores operacionais no sistema reduz de forma drástica, o que pode afetar negativamente o desempenho do serviço. Uma estratégia simples para resolução deste tipo de conflito é executar apenas uma ação e, em seguida, avaliar novamente a situação real do sistema antes de decidir sobre a execução de outra ação. Entretanto, a aplicação constante de ações seguidas de avaliações nem sempre garante progresso do sistema. De fato, o que se espera é que a aplicação de um conjunto de uma ou mais ações garantisse sempre o progresso do sistema. Essas ações seriam analisadas globalmente em um contexto específico e poderiam levar em conta dados históricos reportando situações passadas. Neste sentido, o mecanismo de resolução de conflitos atualmente implementado é baseado em votação, e leva em conta a reputação de agentes envolvidos na tomada de decisão.

4.3. Implementação da infraestrutura de suporte Um protótipo em linguagem Java foi construído para avaliar os serviços de auto-gerenciamen-to. A biblioteca JGroups (http://www.jgroups.org/) serviu como suporte para comunicação de grupo. A implementação descreve cada serviço como um módulo independente e inclui detecção de falhas, balanceamento de carga, detecção de picos de carga e ociosidade e reconfiguração, e uma primeira versão do serviço para a resolução de conflitos baseado em votação. Para não onerar o sistema com troca demasiada de mensagens, apenas a taxa de ocupação da CPU foi usada como métrica. Se a carga global atual da CPU atinge o limite superior, um novo servidor é adicionado à infraestrutura computacional. Se a carga total global do sistema atinge o limite inferior, um dos servidores é escolhido aleatoriamente para ser desativado. Quando um servidor é avisado da sua desativação, ele simplesmente abandona o grupo. O servidor não recebe novas chamadas, mas finaliza todas as transações que lhe foram anteriormente delegadas. A taxa de ocupação local e global da CPU é computada por meio de séries temporais, para evitar a inclusão ou remoção de um servidor no grupo devido a picos momentâneos. Isso significa que a carga da CPU atual individual de cada nodo é considerada para a obtenção de um valor de taxa de ocupação de CPU global, que agrega um conjunto de valores de carga de CPU previamente medidos. Testes para avaliar o protótipo em execução são apresentados em (PASIN et al., 2012). O tempo de resposta da infraestrutura demonstrou resultados promissores nos cenários de testes. Igualmente, o mecanismo de séries temporais usado para evitar inclusão ou remoção de servidor da infraestrutura, devido a picos de carga,

demonstrou ser eficiente após calibragem de parâmetros de controle.

5. CONCLUSÕES E TRABALHOS FUTUROS A demanda por mobilidade urbana tem se intensificado continuamente nos últimos anos, e não é novidade que esta demanda somente tende a aumentar. Este fato gera diversos desafios que devem ser abordados em larga escala (tratamento de congestionamentos, redução do impacto ambiental, redução do impacto econômico, provimento de infraestrutura física mais adequada, etc.). A informatização do controle de processos de transporte é uma aliada importante na tentativa de reduzir o esforço humano. Neste artigo, é apresentada uma proposta integrada de sistema de informação do transporte público contemplando duas ferramentas, uma ferramenta para prover informação ao usuário, uma ferramenta para prover informações às empresas permissionárias, assim como uma infraestrutura autonômica de suporte para servidores. Resultados prévios já alcançados incluem o desenvolvimento de protótipos, e testes em cenário restrito (BASTOS & JAQUES, 2010; FREITAS et al., 2011; PASIN et al., 2012). As principais características destes sistemas, quando estiverem totalmente finalizados, são acessibilidade a partir da internet, forte aproximação com o mundo real e possibilidade de obtenção de informações em tempo real. Trabalhos futuros incluem a incorporação de novas funcionalidades às implementações atuais, e testes em cenários mais amplos, envolvendo maior número de trajetos e veículos. Resultados almejados incluem o uso de uma versão mais robusta do sistema em um ambiente real, com dados gerados em tempo real. Agradecimentos Os autores agradecem à FAPERGS/CNPq e à Rede Nacional de Pesquisa pelo apoio por meio dos projetos RS-SOC (10/0049-7) e SIMTUR (CTIC Cidades Inteligentes), respectivamente. REFERÊNCIAS BIBLIOGRÁFICAS Bastos, R.; Jaques, P. (2010) ANTARES: um sistema web de consulta de rotas de ônibus como serviço público.

In: Revista Brasileira Computação Aplicada, v.2, p. 41-56. Bouchenak, S.; Palma, N.; Hagimont, D.; Taton, C. (2006) Autonomic management of clustered applications, In:

Proceedings IEEE International Conference on Cluster Computing (Cluster 2006), Barcelona, Spain. Freitas, F.; Moraes, R. F.; Jaques, P. (2011) Um sistema web de consulta de trajetos de transporte público. In:

IADIS Ibero-Americana WWW/Internet (CIAWI), RJ - Brasil, 2011. IADIS. Google Maps, 2011. Google Maps. Disponível em: http://maps.google.com.br/. Acesso em 12 dez. 2011. Google Transit, 2011. Google Transit. Disponível em: http://www.google.com.br/intl/pt-BR/landing/transit/.

Acesso em 12 dez. 2011. Hopstop, 2011. HopStop.com - Transit Directions and Maps for New York City (NYC). Disponível em:

http://www.hopstop.com/. Acesso em 12 dez. 2011. Kephart, J. O.; Chess, D. M. (2003) The vision of autonomic computing, In: IEEE Computer, 36. p. 41-50. Ladeira, M. C.; Michel, F.D.; Pavannanto, S. A. (2009) Monitoramento da operação ao de transporte público: o

caso de Porto Alegre. In: Anais do Congresso de Pesquisa e Ensino em Transportes (ANPET). Maybech, P.S. (1979) Stochastic models, estimation, and control, Volume 1, Academic Press, New York. Pasin, M.; Perini, F. S.; Bazzan, A. L. C. (2012) Self-management as support to an advanced traveler

information system. In: Anais do Simpósio Brasileiro de Sistemas de Informação (SBSI) 2012. Roblitz, T. et al. (2004) Autonomic management of large clusters and their integration into the grid. In: Journal

of Grid Computing - GRID, vol. 2, no. 3, p. 247--260. Saleem, S. K.; Chen, S.-C. (2008) Towards a self-configurable weather research and forecasting system, In:

Proceedings of the International Conference on Autonomic Computing - ICAC 2008, p. 195-196. Staib, R.; Gerland, H. (1999) Advanced transit fleet management transfer of European systems and solutions into

American environment. In: Proceedings of the 1999 APTA Bus Conference. p. 136-143. Vanajakshi, L.; Subramanian, S C; Sivanandan, R. (2009) Travel time prediction under heterogeneous traffic

conditions using global positioning system data from buses. In: IET Intelligent Transport Systems 3(1): 1. Welch, G.; Bishop, G. (2006) An introduction to the Kalman filter. In: Practice: p. 1-16.