WiBus: Um Sistema de Monitoramento de Transportes Públicos Usando Redes IEEE 802.11 Uma análise de artigo

WiBus: Um Sistema de Monitoramento de Transportes Públicos Usando Redes IEEE 802.11 Uma análise de artigo Jéssica Yumi Kojima* 28 de Junho de 2014 *MAC0463 Computação Móvel Bacharelado em Ciência da Computação Instituto de Matemática e Estatística (IME) Universidade de São Paulo (USP) São Paulo SP Brasil yumioh@usp.br Resumo. Um dos grandes transtornos vivenciados por usuários de transporte público de metrópoles é a falta de confiabilidade nesse sistema. Tanto o tempo de espera inconstante pelo próximo veículo quanto a falta de comodidade que o mesmo proporciona influenciam indivíduos a adotarem meio de transporte particulares para chegar ao seu destino. Contudo essa solução acaba prejudicando-os, pois o número excessivo de veículos circulando no mesmo intervalo de tempo piora o congestionamento, o qual contribui para os atrasos dos ônibus, por exemplo. A fim de incentivar a utilização desse meio de transporte público e tentar diminuir os engarrafamentos, os autores do artigo [da Silva et al., 2014] propuseram um sistema chamado WiBus, que estima os horários de chegada dos ônibus usando redes IEEE 802.11. 1. Introdução Os sistemas de transporte público nas metrópoles brasileiras são pouco confiáveis em relação à pontualidade, fato que é agravado pelos congestionamentos. Esses podem ser gerados por acidentes, por semáforos quebrados, pelo alto volume de veículos em circulação, entre outros motivos. E segundo o DENATRAN (Departamento Nacional de trânsito), houve um crescimento na frota de veículos nos últimos anos. Então, para incentivar o uso dos meio de transporte públicos e possivelmente inverter essa situação, tanto páginas web quanto aplicativos para sistemas embarcados têm sido desenvolvidos, muitos dos quais já estão em uso, como, por exemplo, a página OlhoVivo e o aplicativo Cadê o Ônibus?. Ambos fornecem informações aos usuários, como o tempo estimado de chegada do próximo veículo e detalhes da trajetória a ser percorrida. Um dos grandes desafios em calcular tais estimativas é considerar os fatores que influenciam no tempo gasto pelos veículos para fazer um percurso, como acidentes e congestionamentos por exemplo. Além disso, podem ocorrer mudanças nas trajetórias predeterminadas dos ônibus, fato que dificulta os cálculos do sistema. Desse modo, o conhecimento das posições dos ônibus de forma mais atual possível é essencial para não gerar erros significativos. Dentre as tecnologias utilizadas para isso estão o GPS, as redes de celulares (3G/4G) e as redes IEEE 802.11, popularizadas como redes Wi-fi ou wireless. O GPS é frequentemente utilizado devido a sua alta precisão. Porém, sendo na maioria das vezes apenas receptores, eles requerem o uso de alguma outra tecnologia para divulgar os dados coletados. Já as outras duas alternativas,

apesar de possuírem precisão inferior à da anterior, conseguem fazer ambos sem o auxílio de outra tecnologia, localizando o veículo através do nó da rede ao qual está conectado. Considerando as redes móveis para calcular as previsões, há dois tipos de comunicação predominantes: V2V (Vehicular-to-Vehicular) e V2I (Vehicular-to-Infrastructure). O primeiro envolve somente nós móveis, os quais comportam de maneira auto-organizáveis e auto-gerenciáveis, tornando um desafio o desenvolvimento de protocolos de roteamento para essa comunicação. Já o segundo é composto de bases fixas na infraestrutura da malha viária além de nós móveis presentes em veículos. Assim, o roteamento de pacotes é mais simples, uma vez que a localização de cada base é conhecida [de Mendonça, 2012]. A fim de manter a complexidade do algoritmo mais baixa, em [da Silva et al., 2014] consideraram melhor usar a arquitetura V2I para a rede, pois apesar do seu custo mais elevado, pode oferecer maior conectividade de rede em relação ao V2V. Assim, o trabalho desenvolvido em [da Silva et al., 2014] propôs o WiBus, um sistema para a estimativa da chegada dos ônibus. Ele se adapta a mudanças de trajetória dinamicamente e utiliza a localização por proximidade em relação a roteadores sem fio IEEE 802.11. Os autores optaram por utilizar em seu projeto as redes IEEE 802.11, pois elas são o padrão utilizado em conectividade sem fio para redes locais [Wikipedia, 2014] e, dessa forma, o WiBus permite o uso de apenas um dispositivo para localizar o veículo e para fazer a comunicação entre as entidades do sistema. O sistema também é capaz de se adaptar a mudanças de trajetória dinamicamente, e não possui uma base de dados com informações de localizações antigas. Para a interação com os clientes, foram feitos um aplicativo para smartphones Android e uma página web chamados BuZoom Web e BuZoom, respectivamente. E alguns experimentos foram realizados para testar o sistema. Esta monografia descreve o trabalho apresentado no artigo [da Silva et al., 2014], e está organizada da seguinte forma: a seção 2 contém a descrição da arquitetura do WiBus; a seção 3 fornece alguns detalhes da implementação desse sistema; a seção 4 descreve o cenário dos testes realizados pelos autores; a seção 5 descreve as avaliações feitas pelos autores; a seção 6 contém as conclusões feitas pelos autores; e finalmente, a seção 7 apresenta críticas em relação ao trabalho realizado. 2. Arquitetura do WiBus O sistema WiBus, representado na Figura 1, possui quatro entidades: Central, Unidade de Acostamento (UA), Ônibus e Cliente. A Central é um computador que possui todas as informações necessárias para calcular as estimativas: os mapas criados dinamicamente, a localização de cada veículo e os dados dos tempos entre pontos consecutivos. Além disso, essa entidade é responsável por fazer as previsões de tempo e responder as requisições dos clientes, executando, assim, o programa principal do sistema. Enquanto isso, as Unidades de Acostamento (UAs) são pontos de acesso instalados nos pontos de parada. Elas oferecem redes sem-fio com identificadores (do inglês, Service Set Identifier, ou SSID) fixados previamente para permitir a conexão aos roteadores nos ônibus. Para que esses últimos sejam rastreados, cada ônibus deve possuir um roteador sem-fio IEEE 802.11 que execute alguns dos programas desenvolvidos no projeto. Esses programas têm o propósito de localizar o ônibus em relação às UAs e enviar os dados obtidos à Central através das próprias UAs. Já a entidade Cliente representa um indivíduo que solicita estimativas ao sistema por meio do aplicativo BuZoom ou da página web desenvolvidos. O sistema desenvolvido utiliza a técnica de localização por proximidade em relação às UAs. Ao se aproximar de um ponto de parada, o ônibus se conecta à UA instalada, ocorrendo uma troca de mensagens nas quais o ônibus se identifica à UA e vice-versa. Após feita a conexão, o ônibus envia uma mensagem à Central informando a qual UA ele está conectado. Desse modo, como as UAs são fixas, o sistema possui a localização do ônibus. Mesmo assim, para estimar o horário de

chegada de um ônibus na próxima UA de sua trajetória, é necessário ter um mapa com os percursos de cada linha de ônibus. O WiBus usa esse mapa juntamente com um histórico recente dos tempos que os ônibus levam para percorrer dois pontos consecutivos de sua trajetória. E a abordagem inicial da criação do mapa das linhas de ônibus supõe que o percurso delas não se altera. Porém, essa suposição é falha, uma vez que mudanças temporárias podem ocorrer. Figura 1. Entidades do sistema na arquitetura 3. Implementação do WiBus O sistema WiBus se compõe de seis programas listados a seguir: WiBusUAServer executado continuamente na UA. Quando um ônibus se conecta a uma UA, essa envia uma mensagem para ele com a identificação da própria UA, recebendo, em seguida, uma mensagem com a identificação do ônibus. Essa última é utilizada somente para manter um histórico de contatos na UA. WiBusClientUA executado no Ônibus para o tratamento de mensagens enviadas pelas Uas, contendo a identificação delas, e para o envio de mensagens às UAs, contendo a identificação do ônibus. Esse programa é executado toda vez que o ônibus se conecta a uma UA. WiBusClientCentral executado no Ônibus para o tratamento de mensagens enviadas pela Central e para o envio de mensagens para a Central, contendo dados de localização de rede. Esse programa é executado após o programa WiBusClientUA terminar. WiBusCentralServer executado continuamente na Central para o envio de mensagens aos ônibus e para o tratamento de mensagens enviadas pelos ônibus. A partir das informações recebidas, o mapa das linhas de ônibus é criado e modificado, os ônibus são localizados e as previsões de tempo de chegada dos ônibus são calculadas. Além disso, esse programa recebe e responde requisições de estimativas dos Clientes. BuZoom aplicativo para smartphones Android. Esse programa solicita estimativas de tempo de chegada dos ônibus à Central. BuZoom Web página web que acessa a Central para disponibilizar os dados sobre os ônibus aos Clientes. Resumidamente, o ônibus obtém sua localização na rede através da execução do programa WiBusClientUA. Depois disso, o programa WiBusClientCentral é executado, e enviando uma mensagem à Central com as seguintes informações: a UA a qual o ônibus está conectado, a UA que o ônibus esteve conectado anteriormente, o identificador do ônibus e o identificador da linha desse ônibus. Ao receber essa mensagem, a Central executa o programa WiBusCentralServer para tratá-la.

3.1. Central No WiBus, uma linha de ônibus é caracterizada pelo seu número e sentido, de forma que nenhuma linha é considerada circular pelo sistema. Além disso, cada linha é composta de trechos, onde um trecho é defindo como um par de UAs consecutivas na trajetória das linhas de ônibus. Como a linha de ônibus no sistema é apenas uma sequência de trechos, para estimar o tempo que o ônibus leva para alcançar uma UA, basta somar os tempos estimados para cada um dos trechos localizados entre a posição atual do ônibus e a UA especificada. Além disso, é preciso levar em conta o fato de que um ônibus pode estar no meio de um trecho quando uma requisição de estimativa é realizada. Contudo, esse caso não é citado em [da Silva et al., 2014], então não se sabe se algum tipo de tratamento é feito. A estimativa do tempo que um ônibus leva para percorrer um dado trecho é calculada como a média dos tempos gastos pelos últimos K ônibus que passaram por esse mesmo trecho. Ou seja, é a média móvel simples dos K tempos calculados para esse trecho que são mantidos no mapa associativo da Central. Esse mapa relaciona trechos das linhas de ônibus aos tempos gastos pelos últimos ônibus que passaram por esse trecho. Ele é atualizado quando a Central recebe uma mensagem, e o mesmo ocorre para as posições em que os ônibus se encontram com as UAs especificadas na mensagem. A Central é a responsável por estimar o tempo necessário para que o ônibus mais próximo alcance uma UA da linha desse ônibus. Para isso, calcula-se as estimativas de cada UA dessa linha para todos os ônibus da linha, como é mostrado no Algoritmo 1. A estimativa b armazena a estimativa de um dado ônibus b alcançar o trecho atual a partir de sua posição inicial, e a função estimativatrecho devolve a estimativa de tempo gasto por um dado ônibus b para percorrer somente o trecho atual. Os desenvolvedores do WiBus não descreveram mais detalhes desse algoritmo, e o algoritmo de criação e atualização dos mapas das linhas dos ônibus está descrito na próxima seção. 3.2. Algoritmo de Criação e Manutenção Dinâmica de Trajetórias O WiBus representa as trajetórias dinamicamente para conseguir fazer o tratamento de casos de imprevistos que modificam os percursos dos ônibus, como a ocorrência de desvios. Porém, pode acontecer a situação em que um motorista erra o caminho a ser seguido, então o sistema não pode considerar qualquer mudança sinalizada por um veículo como uma alteração na trajetória da linha de ônibus. Dessa forma, os desenvolvedores do WiBus propuseram um algoritmo que atribui pesos nas variáveis para evitar essas modificações desnecessárias nas trajetórias das linhas. Assim, uma

alteração é confirmada se outros ônibus dessa mesma linha repetirem a mesma trajetória. A trajetória dos ônibus pode ser representada como um grafo, onde os arcos representam os trechos considerados no percurso e os nós representam as UAs. Ambos os arcos e os nós possuem um peso. O do primeiro indica a velocidade em que uma mudança na trajetória é considerada permanente, quanto menor ele for, mais rápida será concretizada a alteração. O valor desse peso deve ser no máximo duas vezes o número de ônibus das linhas, para que os pesos dos arcos alcancem o valor de zero antes do peso da UA no caso de uma mudança no trajetória da linha. Já o peso da UA é usado para a remoção de uma UA de uma trajetória, e determina quando uma UA será excluída. O valor inicial atribuido pelo WiBus a esse peso é igual ao valor máximo permitido: o dobro do produto da quantidade de UAs presentes na linha pela quantidade de ônibus que estão fazendo esse percurso. Como esse peso depende do número de UAs cadastradas, quando uma nova UA é inserida ou uma antiga reaparece na trajetória, os pesos de cada UA é igualado ao novo máximo. Assim, no WiBus, todos os ônibus de uma dada linha precisam percorrer a quantidade de UAs cadastradas pelo menos duas vezes antes que uma delas seja excluída. Ressalta-se que cada UA pode ter uma lista de arcos, pois no caso de uma alteração na trajetória de uma linha, uma UA pode possuir mais de uma possibilidade de próxima UA ou de UA anterior a ela na trajetória. Assim, a atualização dos pesos dos arcos é dada da seguinte forma: subtrai-se uma unidade do peso de todos os arcos da lista de UAs anteriores e próximas, e somam-se duas unidades ao peso do arco usado atualmente. Caso o valor do arco se torne zero, ele é removido, indicando que a UA relacionada a ele não é mais utilizada como anterior ou próxima na trajetória do ônibus. Enquanto isso, a atualização dos pesos das UAs ocorre da seguinte maneira: o peso de todas as UAs da linha é decrementado de uma unidade, e depois o peso da UA atual é igualado para o valor anteriormente especificado, isto é, o dobro do produto da quantidade de UAs na linha de ônibus pela quantidade de ônibus percorrendo a trajetória. Caso o peso da UA se torne zero, ela é eliminada. Figura 2. Exemplo de funcionamento do Algoritmo de Criação e Manutenção

Dinâmica de Trajetórias. Um exemplo de funcionamento dessas atualizações pode ser vista na Figura 2. Nele, considera-se que as UAs 3 e 4 estão defeituosas. Assim, até a Figura 2(b) o ônibus segue normalmente em sua trajetória. Na Figura 2(c) observa-se que novos arcos foram inseridos, e os pesos dos arcos antigos da lista de UAs anteriores e próximas foram decrementados. Na Figura 2(d) dois dos arcos atingem o valor de zero e são excluídos. E na Figura 2(e) o mesmo ocorre para as UAs 3 e 4. O pseudocódigo da criação e atualização dos mapas das linhas de ônibus é mostrado no Algoritmo 2. 3.3. Interface Gráfica Para a interação com o usuário, foram desenvolvidos duas interfaces gráficas: um aplicativo para smarphones, e uma página web chamada BuZoom Web. Segundo os desenvolvedores do WiBus, esse aplicativo, chamado BuZoom, foi disponibilizado para sistemas operacionais Android

2.2 (Froyo) ou versões mais recentes, e pode ser visto na Figura 3. Figura 3. Telas do BuZoom para Android. Nesse aplicativo, a consulta do usuário requere conexão com a Internet, e pode ser feita de duas maneiras: usando um leitor de QRcode, que está diponível no ponto para identificar o ponto de ônibus; ou escolhendo seu ponto a partir de uma lista suspensa. A primeira forma é mais apropriada para usuários que já se encontram no ponto de ônibus, mas não sabem onde ele se localiza. Já a segunda é mais apropriada para usuários que não estão nos pontos, esperando, por exemplo, que o ônibus se aproxime mais antes de ir até o ponto. Após o envio dos dados à Central, a resposta da requisição pode ser visualizada na tela do dispositivo. Segundo os desenvolvedores do WiBus, as ferramentas utilizadas no desenvolvimento do aplicativo BuZoom foram o Android SDK (Software Development Kit) e o JDK (Java Development Kit). Para o reconhecimento do QRcode foi usado o pacote Zxing.integration.android, fazendo uma requisição para um aplicativo auxiliar chamado BarcodeScanner. E a produção dos QRcodes, relacionados aos pontos de ônibus do Campus Ilha do Fundão da UFRJ, foi feita com o aplicativo QRdroid. 4. Rede de Testes realizados pelos autores Os desenvolvedores do WiBus montaram um pequeno protótipo de laboratório para testar o sistema, com as entidades da arquitetura representadas da seguinte maneira: Central: uma computador com sistema operacional Debian, 8 GB de memória RAM e processador Intel Core i7 860. UAs / Ônibus: roteadores sem-fio D-Link, modelo DIR-320. Esse modelo possui processador ARM de 240 MHz e 32 MB de memória RAM. E ainda, possui uma entrada USB que pode ser usada para aumentar a capacidade de armazenamento do roteador (originalmente 4 MB) ou para instalar uma segunda interface de rede sem-fio.

A Central e as UAs foram conectadas através de um roteador D-Link, modelo DIR-320, configurado para funcionar como um comutador. Já a conexão das UAs e da Central com esse comutador foi feita por meio de um cabo Ethernet. E o sistema operacional utilizado nos roteadores é uma distribuição Linux para dispositivos embarcados chamado OpenWRT versão Backfire 10.03.1. Figura 4. Ambiente de testes. 5. Avaliações realizadas pelos autores Foram realizados dois experimentos para testar o WiBus. O primeiro tinha o objetivo de avaliar a quantidade máxima sob a qual o sistema ainda era capaz de operar, rastreando veículos e calculando as estimativas requisitadas. Enquanto o segundo tinha o objetivo de avaliar os erros das estimativas calculadas pelo sistema, e foi realizado com dados reais em um cenário universitário. 5.1. Capacidade de Atendimento de Ônibus Neste teste, os autores em [da Silva et al., 2014] tentaram simular as condições da cidade do Rio de Janeiro. Então foram cadastrados 8.000 ônibus distribuídos uniformemente entre 800 linhas fictícias de ônibus. Esses cadastros foram realizados através de um script não descrito em [da Silva et al., 2014] que emula a passagem dos ônibus pelas UAs, enviando mensagens do ônibus (roteador) à Central. Dado que a quantidade de UAs de cada linha pode variar, os autores consideraram no

experimento variações entre 10 a 100 com incrementos de 10. No teste, cada ônibus percorreu uma trajetória 10 vezes, enviando mensagens para a Central toda vez que mudava de UA. A Central fez o tratamento das mensagens e calculou o tempo gasto nesse tratamento. Isso foi repetido três vezes, e os resultados podem ser vistos na Figura 5. Figura 5. Tempo de tratamento de mensagens. A partir desse gráfico, os autores fizeram a dedução de que, como cada mensagem gasta menos de 7ms para ser tratada, o WiBus conseguiria tratar as mensagens dos 8.000 ônibus, pois com a suposição de que cada ônibus demora ao menos um minuto para percorrer um trecho, a Central conseguiria tratar aproximadamente 8.500 mensagens por minuto. Dessa forma, eles concluíram que o WiBus conseguiria atender as demandas de uma metrópole. 5.2. Experimentos em um Cenário Universitário Nesse experimento os autores mediram nove vezes o tempo gasto em todos os trechos das linhas de ônibus universitários COPPEAD e Estação UFRJ, mostradas na Figura 6. Como as estimativas das linhas dependem do parâmetro K, eles tentaram defini-lo variando o seu valor entre 1 e 8. Na Figura 7 são apresentados os erros absolutos médios por trecho nos casos onde K vale 1, 4, 5 e 8. O valor de K deve ser escolhido de forma a minimizar o erro médio das estimativas de tempo do ônibus de toda a sua trajetória. Pelos gráficos da Figura 8, os valores de K que produzem menor erro absoluto são K = 4 para a linha COPPEAD e K = 3 para a linha Estação UFRJ.

Figura 6. Trajetórias das linhas de ônibus universitárias. Figura 7. Erro absoluto médio para diferentes valores de K. As características das linhas estudadas foram apresentadas nas Tabelas 1 e 2. A partir delas, os autores afirmaram que as linhas com maiores variações, como a linha COPPEAD, tendem a apresentar maior compromisso entre as informações recentes e as de longo prazo, enquanto as linhas com menores variações não apresentam esse comportamento de forma tão nítida, como a linha Estação UFRJ. Essa foi uma conclusão muito abrangente, sendo que só foram testadas duas linhas.

Figura 8. Erro médio de estimativa do ponto inicial até o ponto final para diferentes valores de K. Tabela 1. Linha COPPEAD

Tabela 2. Linha Estação UFRJ E, finalmente, pela Figura 8, os autores observaram que o erro médio absoluto das estimativas não passava de poucos minutos. E a partir disso, concluíram que o WiBus possui grande potencial para usuários de transporte públicos. 6. Conclusões feita pelos autores Os autores em [da Silva et al., 2014] propuseram um sistema para a estimativa dos horários de chegada de ônibus nos pontos em que um cliente se encontra. O WiBus coleta dados a partir de redes IEEE 802.11, cujos dispositivos estão instalados nos ônibus e em certos pontos ao longo das vias. Visando evitar falhas no sistema caso ocorressem mudança nas trajetórias dos ônibus, um algoritmo de criação e manutenção dinâmica de mapas digitais foi proposto e avaliado pelos autores. A estimativa de chegada dos ônibus foi baseada em médias móveis simples de tamanho K, calculado para duas linhas de ônibus que percorrem a cidade universitária da Universidade Federal do Rio de Janeiro (UFRJ). Segundo os autores, o WiBus apresenta erro da ordem de minuto ao longo de todo o percurso das linhas de ônibus avaliadas. Eles também acreditam que o sistema proposto mostrou ser capaz de atender as exigências de metrópoles como o Rio de Janeiro, pois conseguiria tratar mais de 8.500 mensagens por minuto no pior caso. 7. Críticas Diversos pontos do artigo não ficaram claros. Os seis programas apresentados só foram explicados superficialmente, a maioria sem a apresentação de código. E os únicos dois algoritmos apresentados usam funções que não foram descritas ou explicadas explicitamente, como a estimativa do tempo de um trecho, parte essencial da implementação. Supõe-se que a Central mantém armazenado o horário da última mensagem enviada por cada ônibus. Assim, o tempo gasto para percorrer o tempo se daria pela diferença entre o ultimo horário armazenado e o horário da

nova mensagem. E caso um ônibus se encontre no meio de um trecho quando a solicitação de uma estimativa é feita, poderia-se calcular o tempo que o ônibus já gastou a partir do horário atual e daquele enviado pela última mensagem. Porém, como o artigo não menciona explicitamente quais dados são armazenados pelo sistema, não é possível confirmar essa suposição. Além disso, o artigo também não menciona tratamentos relacionados à estimativa de tempo para o caso de ocorrência de desvios. Quando um ônibus muda seu percurso, dado que ele só envia informações sobre sua localização ao se comunicar com uma UA, o sistema estimaria que o ônibus ainda está percorrendo a trajetória definida no mapa, e enviaria informações erradas aos usuários caso houvesse requisições. E mesmo que o sistema obtivesse a informação do desvio no momento em que ele ocorre, a Central não saberia qual seria a próxima UA na trajetória do ônibus até que o mesmo se conecte ela, ou se de algum modo fosse enviada uma mensagem para a Central no momento em que o desvio acontece. Um problema similar ocorre quando o sistema acaba de ser inicializado, pois não existem dados sobre os tempos dos últimos K ônibus que passaram pelos trechos, já que nenhuma das trajetórias foi percorrida ainda. No entanto, os autores do artigo não apresentaram informações relacionadas ao tratamento de casos de inicialização do sistema, então não se sabe o que foi feito. Um dos modos de contornar o problema seria conseguir a localização e a velocidade do ônibus sem a necessidade de se conectar a uma UA, para o caso de um ônibus se encontrar no meio de um trecho quando a requisição de um cliente é realizada. Contudo, para isso seria necessário o uso de alguma outra tecnologia, o que infringiria a ideia dos autores de utilizar somente um tipo de dispositivo para localizar o veículo e fazer a comunicação entre os nós da rede. Outra solução seria obter e armazenar os dados sobre o tempo gasto em cada trecho antes do sistema ser disponibilizado ao público. O script que emula a passagem dos ônibus pelas UAs também não é devidamente descrito no artigo. Só com as informações nele contidas, não se sabe se casos como mensagens incompletas, atrasos no recebimento das mensagens, falhas no sistema foram considerados nas estimativas. E se esse não for caso, os autores não poderiam afirmar que o sistema conseguiria tratar as mensagens de todos os ônibus de uma metrópole no intervalo de um minuto, pois o tempo tratamento da mensagem no mundo real pode ser diferente daquela obtida através das simulações (inferior a 7ms). Só é possível dizer que o WiBus possui certo potencial. Dessa forma, entende-se que o o ambiente de testes foi utópico, apesar dos autores tentarem reproduzir o cenário do Rio de Janeiro. Foram cadastrados um volume razoável de ônibus e linhas fictícias, porém não há indícios de experiências realizadas com vários ônibus circulando por uma única ou mais linhas ao mesmo tempo. E as que foram executadas ficaram restritas a um ambiente universitário, o qual é relativamente pequeno, fechado e não aborda situações do dia-a-dia da mesma maneira que uma metrópole. O número de acidentes, desvios e intensidade de congestionamentos não são da mesma magnitude. Assim, a capacidade de atendimento de ônibus do WiBus e os erros das estimativas feitas pelo mesmo foram deduzidas com estimativas não muito convincentes. Além disso, os gráficos apresentados não possuem a mesma escala, o que pode resultar em uma comparação equivocada entre eles. Os próprios autores cometem esse erro ao citar que o erro médio absoluto das estimativas se mantém abaixo de 80 segundos. Isso é verificado na figura 8b, cuja escala alcança no máximo 80 segundos, mas o mesmo não ocorre na figura 8a, cuja escala vai até 120. Segundo os autores, as estimativas de localização em rede baseada em séries históricas usam dados coletados durante intervalos longos de tempo. Nela, situações fora do padrão como acidentes seriam desconsideradas, pois os cálculos utilizariam uma média pertencente, por exemplo, a um mesmo período de um mesmo dia da semana. Os autores também definem que os métodos de tempo real utilizam apenas informações obtidas no próprio dia, modelando melhor situações imprevistas

em comparação à anterior. E afirmam que usaram a técnica de tempo real em seu projeto, devido ao dados de localização do método utilizado serem esparsos, calculando a média dos tempos gastos pelos K últimos ônibus que passaram pelo trecho. Conforme o artigo, esse método assume que o tempo que um veículo leva em um percurso é o mesmo que a de um veículo anterior, pois o histórico passado é relativamente curto. Porém, as estimativas não usam dados de tempo real propriamente ditos. Os dados provém de um histórico recente, mas esses não foram coletados apenas no momento em que os cálculos são feitos. Então o método utilizado está mais relacionado com séries históricas de curto prazo do que tempo real, uma vez que os intervalos de tempo entre os ônibus podem chegar a 1h, dependendo da situação. E ainda, há referências que não foram citadas corretamente. Na introdução do artigo, os autores afirmaram que os métodos para estimar a localização em [Manolis e Kwstis, 2004] são baseados em séries históricas, desconsiderando situações como acidentes. Porém, esse método só é utilizado quando não há ônibus em um dado trecho para se extrair a velocidade em tempo real. A técnica utilizada assume que o tempo gasto por um veículo em um dado trecho será igual ao de outro que está passando pelo mesmo trecho no instante em que a estimativa é calculada. Sendo assim, o método usa ambas as abordagens de tempo real e de séries históricas. Além disso, os autores também não foram coerentes quanto o valor dos pesos atribuídos para as UAs. Primeiro disseram que esse valor era igual ao dobro do produto da quantidade de UAs na linha de ônibus pela quantidade de ônibus percorrendo a trajetória. Mas depois, o valor foi referido como somente duas vezes a quantidade de UAs na linha de ônibus. Como o exemplo de funcionamento exposto considerava apenas um ônibus realizando o percurso, ambos os valores são iguais, e não é possível saber qual desses valores foi utilizado. Outro ponto importante é que não foi encontrado a página BuZoom Web nem o aplicativo BuZoom descritos no artigo. O apk de um aplicativo chamado BuZoom até foi encontrado em [Fábrica de Aplicativos, 2014], mas, pela imagem da página web, ele não parecia ser aquele ao qual os autores se referiam. Não foi possível instalá-lo e testá-lo para fazer uma verificação. Logo, os autores em [da Silva et al., 2014] deveriam ter detalhado e revisado um pouco mais o conteúdo de seu trabalho. Apesar disso, mostraram que um sistema baseado em redes locais possui um potencial para o monitoramento de ônibus em larga escala. Referências: da Silva, V. B. C., Sciammarella, T, Campista, M. E. M. e Costa, L. H. M. K. (2014). WiBus: Um Sistema de Monitoramento de Transportes Públicos Usando Redes IEEE 802.11. Em Anais do 32 o Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos SBRC 2014. http://sbrc2014.ufsc.br/anais/files/trilha/st21-2.pdf de Mendonça, T. F. (2012). VANETs: Vehicular Ad-Hoc Networks. http://grenoble.ime.usp.br/~gold/cursos/2012/movel/vanets.pdf Fábrica de Aplicativos (2014). BuZoom. http://galeria.fabricadeaplicativos.com.br/buzoom Manolis, K. e Kwstis, D. (2004). Intelligent transportation systems travelers' information systems the case of a medium size city. Em Mechatronics. ICM '04. Proceedings of the IEEE International Conference on, p. 200-204. SPTrans (2014). OlhoVivo. http://olhovivo.sptrans.com.br/ Wikipedia (2014). IEEE 802.11. http://pt.wikipedia.org/wiki/ieee_802.11