CARLOS ALEXANDRE PACHOLOK JHONATAN ZEZAK RODRIGUES Controle de Tráfego do Transporte Coletivo Relatório apresentado à disciplina de Projeto Final II, Curso de graduação em Engª. Elétrica, Setor de Ciências Exatas e Tecnológicas, Pontifícia Universidade Católica do Paraná. Orientador : Profº. Mardson Freitas de Amorim CURITIBA DEZEMBRO / 2007 Controle de tráfego do transporte coletivo PLANO DE PROJETO Equipe: CARLOS ALEXANDRE PACHOLOK JHONATAN ZEZAK RODRIGUES Orientador: ____________________________ Prof.º Mardson Freitas de Amorim Pontifícia Universidade Católica do Paraná Projeto Final II Engenharia Elétrica Professor Responsável: James Alexandre Baraniuk CURITIBA DEZEMBRO / 2007 INDICE RESUMO: .................................................................................................................................... 1 INTRODUÇÃO: ............................................................................................................................ 2 GPS.................................................................................................................................... 5 GSM/GPRS....................................................................................................................... 5 Micro-controlador ............................................................................................................. 5 Servidor ............................................................................................................................. 5 Módulo GPS...................................................................................................................... 7 Módulo Receptor GPS Trimble...................................................................................... 8 Funcionamento do Módulo GPS ................................................................................... 9 Módulo GPRS................................................................................................................. 10 MÓDULO MÓVEL ..................................................................................................................... 12 GPS.................................................................................................................................. 12 GPRS............................................................................................................................... 13 PIC – Micro Controlador (Software)............................................................................ 14 SERVIDOR ................................................................................................................................. 17 Introdução Teórica ao C++ Builder ............................................................................. 17 Introdução Teórica ao Banco de Dados e Tabelas .................................................. 17 DRIVER OBDC .............................................................................................................. 19 FERRAMENTAS DE CONEXÃO C++ BUILDER COM O MySQL ........................ 19 MODELAGEM DE BANCO DE DADOS .................................................................... 22 SERVIDOR DE CONTROLE DE TRAFEGO DO TRANSPORTE COLETIVO.... 25 CONSULTAS DO SISTEMA ........................................................................................ 30 CÁLCULO DO TEMPO ESTIMADO DO PRÓXIMO ÔNIBUS................................ 33 ALGORITMO DO CÁLCULO DO TEMPO ESTIMADO........................................... 35 ARMAZENANDO DADOS NO SERVIDOR:.................................................................................. 40 CONCLUSÃO: ............................................................................................................................ 42 RESUMO: Objetivando uma melhora do transporte coletivo, identificando a localização do ônibus, velocidade e tempo estimado de chegada até próxima estação, este projeto final desenvolveu um protótipo de um sistema de controle e tráfego do transporte coletivo. São utilizados dispositivos de localização via satélite GPS integrados com o sistema de comunicação através do sistema móvel celular com a tecnologia GSM/GPRS, com comunicação em tempo real que são integrados a um micro-controlador. O veículo, assim como cada estação, se comunicará com o servidor na central de controle e operação para o envio e recepção dos dados. No hardware são utilizados os módulos GPS e GSM/GPRS da PUCPR. Para o controle desses dispositivos é utilizado um micro controlador da família PIC adquirido a partir de recursos dos próprios desenvolvedores do projeto. Já o quesito software, é utilizada a linguagem C/C++ tanto na implementação do servidor central, quanto na programação da placa com o micro controlador. 1 INTRODUÇÃO: As grandes cidades sofrem cada vez mais com os congestionamentos que ultrapassam o horário de rush. O problema é antigo e cada vez está em piores condições, gerando grande stress na população. O sistema de transporte público visa atender toda a população no translado casatrabalho, ou casa-escola, enfim, na locomoção dos habitantes. Todavia, o sistema de transporte público coletivo não possui muitos adeptos e, sempre que possível, o usuário utiliza-se de transporte próprio devido à superlotação e horário indeterminado ou com muito atraso. O projeto se destina às empresas de ônibus que almejam melhorar e modernizar o sistema de transporte. Neste caso a URBS da cidade de Curitiba seria o possível cliente. O projeto viabiliza o rastreamento, controle de horários de partida e chegada dos ônibus, assim como a velocidade do mesmo, melhorando assim o sistema de transporte coletivo e facilitando a vida do usuário. O Sistema de Controle e tráfego do transporte coletivo via GPS é um sistema inovador e avançado de coleta de informações de operações da frota do transporte coletivo utilizando módulos com tecnologia GPS e transmissão desses dados através de módulos celulares GSM/GPRS. GPS é a sigla inglesa de Global Positioning System e significa Sistema de Posicionamento Global, um sistema que fornece a posição geográfica de qualquer ponto da terra através de coordenadas geográficas emitidas pelos sistemas de satélites. Os sinais emitidos pelos satélites são recebidos pelo módulo GPS sendo possível determinar com precisão o local e horário em que se encontra um determinado ônibus, além da velocidade desenvolvida naquele momento, a direção e a distância percorrida por ele. Depois de efetuada a leitura da posição geográfica e outros dados decorrentes do módulo GPS, as informações serão enviadas por um módulo celular GSM/GPRS ao um servidor central que processará as informações e re-enviará aos terminais de passageiros. A sigla GRPS vem do inglês General Packet Radio Service, que significa serviço global de transmissão de dados por pacotes. Seu funcionamento se baseia no envio e recepção de informações em uma rede telefônica celular GSM. Essas informações são divididas em pacotes, que percorrem diversos caminhos até o destino final. Na qual são reagrupados e lidos de forma correta. O software utilizará recursos gráficos indicando as posições e o itinerário realizado por todos os ônibus, velocidade atual, tempo esperado até a próxima estação. 2 DETALHAMENTO DO PROBLEMA: Na Curitiba, que possui um sistema de transporte exemplar, invejado, premiado e copiado por muitos lugares e um grande número de usuários satisfeitos (89% segundo a URBS) este sistema é organizado pela URBS (Companhia de Urbanização de Curitiba). Ônibus bi-articulados trafegam em vias exclusivas e terminais de ônibus e estações tubo permitem aos passageiros trocarem de linha pagando apenas uma passagem. Ainda assim, a população foge do serviço mesmo fora dos horários de pico e reclamam da imprecisão dos horários. A alegação é que de ônibus precisam sair 30 minutos antes ou até mais, pois não sabem que horas o ônibus passará. Teoricamente, os ônibus possuem um horário pré-estabelecido, mas esse horário funciona somente em paradas finais e, fora disso, em intervalos de horários. Os ônibus bi-articulados em dia de semana passam de cinco em cinco minutos, sábados de dez em dez minutos e domingos e feriados de quinze em quinze. Contudo, o usuário quer saber quando passará o próximo. Ou ainda, há casos em que o usuário está no terminal e tem duas opções, uma que demora mais e outra menos. O questionamento é: a que demora mais já está no terminal e a que demora menos chega há um minuto, em dois ou somente daqui quinze minutos? Com o intuito de melhorar esse serviço, o projeto propõe localizar e identificar a hora estimada da chegada do próximo ônibus. O sistema identificará a localização do ônibus, sua velocidade e estimará o horário de chegada na próxima estação tubo ou terminal. Esse sistema terá um apelo muito forte ao usuário do transporte coletivo e servirá de incentivo às campanhas de uso do transporte publico. Para os proprietários dos veículos poderá ser utilizado como segurança pelo serviço de rastreamento e para URBS uma otimização dos veículos, horários de pico com mais ônibus e melhor intercalados. Soluções parecidas existem em alguns lugares do Brasil. Contudo, em São Paulo (capital), por exemplo, o sistema que deveria informar o horário de chegada do próximo ônibus está sempre fora do ar. Uma solução barata aplicada em alguns lugares é a utilização de rádio freqüência, onde em cada parada avisa a próxima da que o ônibus está chegando. Porém, esta solução possui, como principal falha, casos em que o ônibus tenha de parar devido a acidentes ou congestionamento o tempo de chegada não se aplicará. Outro problema da solução por rádio freqüência é a distância alcançada. Por GPRS é possível informar a localização do ônibus a qualquer terminal ou estação tubo alvo que esteja dentro da área de cobertura da rede de celulares, o que atualmente nas grandes cidades não é um problema e faz com que a abrangência seja praticamente total. O projeto propõe um sistema que, além de fornecer a facilidade de o passageiro saber o horário de chegada do seu ônibus, fornece facilidades aos proprietários dos veículos, com o sistema de GPS integrado ao GPRS e ao micro-controlador. Assim, é possível adicionar serviços de acordo com as especificações do proprietário. Por exemplo, informações de distância percorrida, informações da bomba de combustível, velocidade média, temperatura do motor, botão de pânico 3 para cobradores em caso de pânico. Para a URBS, que gerencia o sistema, algumas das possíveis informações são: informação do número de passageiros que entraram no ônibus ou na estação tubo, botão de pânico para as estações tubo, certificação do número de ônibus trafegando na rota, além das informações que são de comum interesse da URBS e proprietários de ônibus. Com a implementação do sistema um maior número de cidadãos utilizará o sistema, gerando maior lucro à operadora. Através do rastreamento via GPS, os semáforos poderão ser programados com antecedência a fim de liberar a passagem dos ônibus. Se aplicado, o sincronismo entre ônibus e semáforos, diminuiria muito o tempo da viajem e, com isso, ganhando passageiros. 4 TRABALHO A SER DESENVOLVIDO: O projeto foi dividido em quatro módulos abaixo relacionados: Módulo GPS; Módulo GSM/GPRS; Micro-controlador; Servidor. Figura 1 – Diagrama dos módulos funcionais GPS Nesse primeiro módulo funcional serão verificados quais são os dados enviados, tempo de verificação e envio para serial. Posteriormente, o módulo será colocado para enviar os dados obtidos dos satélites para uma interface de alto nível para o usuário (LabView). Na versão final será feito com que o GPS envie as informações para o módulo GPRS através de pacotes de dados até o servidor. GSM/GPRS Nessa segunda etapa, será verificado o funcionamento do módulo e suas características, enviando dados de teste na rede GPRS. Será verificado como são seus comandos e dados enviados através da porta serial, tempo de envio e etc. Após esses períodos de testes, o módulo GPRS será configurado para receber os dados do GPS e enviá-los através de pacotes IP para o servidor. Micro-controlador O terceiro módulo consiste no software e no hardware do micro-controlador. O software é o código em linguagem C dos procedimentos que o micro-controlador terá que efetuar para interfacear os dados coletados do GPS e enviá-los através do modem GPRS. Já no hardware, será confeccionada uma placa para alojar o micro-controlador. Servidor 5 No quarto e último módulo funcional, o receptor funcionará como um servidor de bancos de dados que receberá os dados enviados do modem GPRS, depois de processados, re-encaminhando para o terminal, na qual terá outro módulo GSM/GPRS integrado com display. No software, implementado em linguagem C/C++, fará o recebimento e processamento das informações enviadas pelos ônibus, consultando seu trajeto atual, velocidade, sincronismo de relógio e calculo aproximado do tempo até próxima estação. 6 TECNOLOGIAS QUE SERÃO UTILIZADAS: Módulo GPS O sistema de GPS fornece uma precisa capacidade de fornecer coordenadas geográficas de um determinado ponto na terra, velocidade e altitude através da navegação tridimensional. Desde os primórdios os homens utilizavam os corpos celestes para a navegação e orientação. A navegação astronômica possui alguns inconvenientes, como a não presença dos astros a qualquer hora (dias nublados, por exemplo) e em qualquer ponto, a pessoa deve ter a capacidade para fazer essa leitura, contudo, tem a vantagem de estar ali, e poder utilizar sem pedir autorização a ninguém. Sistemas de navegação por ondas de rádios também apresentam limitações, como as ondas de rádio de alta freqüência proporcionam navegação precisa, mas são influenciadas pelo relevo. Já as ondas de baixa freqüência são pobres em precisão e os equipamentos não são de fácil acesso para qualquer usuário. Pesquisas realizadas na década de 70 e 80, pela Força Aérea dos Estados unidos levaram ao sistema de navegação por satélites, GPS, cujos principais objetivos foram a radio navegação em três dimensões com alta precisão de posição, navegação em tempo real, imunidade a interferências, cobertura global e inoperabilidade, rápida obtenção dos dados transmitidos pelos satélites. O funcionamento básico de do sistema GPS se baseia no principio de triangularização, segundo o qual o observador conhece a posição de um conjunto de satélites em relação a um referencial inercial e sua posição em relação a este conjunto, obtendo sua própria posição no sistema de referência. O GPS é dividido em três segmentos principais: segmento espacial, constituído pelos satélites; segmento de controle, constituído pelas estações terrestres que controlam o desempenho e o funcionamento do sistema; segmento usuário, constituído pelos usuários do sistema. A mensagem transmitida por cada satélite ao usuário contém: parâmetros para correção do relógio do satélite; efemérides do satélite; almanaque e "saúde" de todos os satélites; dados para correção da propagação ionosférica; parâmetros para correções orbitais; código de identificação. A mensagem referente dos satélites pode chegar de forma incorreta. Essas principais fontes de erro podem ser: 7 erro devido à geometria dos satélites com relação ao observador; desvios dos relógios dos satélites; atraso de propagação e processamento dos sinais pelos pelos circuitos dos satélites; erros devido a trajetórias múltiplas dos sinais; efeitos da atmosfera sobre a velocidade e a trajetória de propagação dos sinais transmitidos; erros devidos à resolução e ruído do receptor do usuário; erro na determinação da d posição dos satélites. Na comunicação com os receptores de GPS são são utilizados dois sinais, chamados de L1 e L2. L1 tem a freqüência de 1575.42 MHz e é utilizado por GPS para uso civil. No passado o governo dos Estados Unidos agregava um ruído ao sinal para para diminuir a exatidão das localizações. Contudo em maio de 2000 essa característica foi eliminada, melhorando a exatidão dos GPS civis. Módulo Receptor GPS Trimble Os módulos de GPS são bastante sensíveis. Porém, devido à extrema atenuação dos sinais, eles es necessitam de um amplificador de RF e de uma antena externa específica. O microprocessador realiza uma série de filtros digitais além de outras técnicas para extrair a informação dos satélites que chegam com ruídos e com grande atenuação. Dessas informações ções é extraída a localização, entre muitas informações disponíveis, e repassado ao mundo externo através da etapa de interfaceamento. Figura 2 - GPS Utilizado 8 Figura 3 - Diagrama de blocos Módulo GPS Trimble Funcionamento do Módulo GPS Ao ser inicializado, o GPS provavelmente não terá nenhuma informação válida. Por isso ele deve executar as seguintes funções: Receber o sinal de conjunto de pontos da órbita prevista + a diferença de clock ou almanaque; Receber sinal dos satélites; Decodificar as informações; Transformar as informações em localização, altitude, velocidade, e sincronismo de relógio; Repassar essas informações ao mundo exterior; Repetir a partir do passo 2. Para efetuar a localização, o sistema sistema GPS necessita de, no mínimo, quatro satélites por um motivo simples: os sinais percorrem cerca de 300 metros em um micro segundo. A estabilidade dos cristais usados nos receptores de GPS está casa de micro segundos, o que torna muito elevado o erro de posição devido à diferença dos relógios. Contudo, ao utilizar um quarto satélite, os receptores do GPS se sincronizam com os relógios atômicos dos satélites. Dessa maneira a estabilidade fica em torno dos nano segundos, diminuindo consideravelmente o erro. er A recepção do almanaque pode ser bem demorada. Dependendo da situação de recepção, podem ser necessários vários minutos. Durante esse tempo o módulo de GPS não é capaz de realizar uma medida de localização. 9 Módulo GPRS A rede de telefonia celular GSM atual teve suas taxas de transferência de dados aumentada devido à tecnologia GPRS. Ela permite o transporte de dados por pacotes por comutação de pacotes, oferecendo assim, elevadas taxas de transferências que as tecnologias anteriores que utilizavam comutação mutação por circuito. A informação é dividida em pacotes relacionados entre si antes de ser transmitida e remontada no destinatário. A comutação por pacotes é estabelecida de forma diferente que a comutação por circuito, pois, a mesma não é estabelecida do do ponto de origem da transferência de dados ao destino. Na comutação por circuito todos os recursos da rede são dedicados por toda a duração da chamada. Com a tecnologia GPRS o serviço este sempre ativo, e os recursos da rede só são utilizados quando o usuário ário for enviar ou receber dados. Pelo fato de estarem sempre conectados e a disponibilidade imediata é uma característica muito importante para aplicações críticas como autorização remota. Com esse sse uso eficiente de recursos, um grande número de usuários G GPRS pode potencialmente compartilhar a mesma largura de banda e serem servidos de uma única célula. O número atual de usuários suportados depende da aplicação em uso e de quanta informação que está sendo transferida. Dada a eficiência do GPRS, há menor necessidade necessidade de investir em recursos que serão somente utilizados em horários de pico. Portanto, GPRS permite que as operadoras maximizem o uso de seus recursos de rede de uma forma dinâmica e flexível. A rede GPRS permite uma funcionalidade completa com a int internet móvel por ter interoperabilidade entre a internet convencional e rede GPRS. Qualquer serviço utilizado na internet está disponível também através da rede móvel celular com GPRS. A navegação na web através da rede GPRS é fácil pelo fato dos protocolos em uso serem os mesmos. As redes GPRS podem ser encaradas como sub-redes redes da Internet e os telefones GPRS-compatíveis GPRS compatíveis podem ser vistos como nós móveis dessa rede. Isso significa que cada terminal GPRS pode potencialmente ter seu próprio endereço IP e ser endereçável ndereçável por isso. Figura 4 - Módulo GPRS Utilizado 10 PROCEDIMENTOS DE TESTES E VALIDAÇÃO DO PROJETO: O projeto será desenvolvido em etapas e principais módulos. Cada módulo será testado separadamente e, finalmente, todos integrados. Para o teste do funcionamento do módulo GPS será utilizado, como referência, o software Google Earth e um aparelho GPS convencional do mercado. Primeiramente, o GPS está ligado a uma interface em software de instrumentação virtual da National Instruments, o Labview. Esta interface foi criada para facilitar a leitura dos dados oriundos do GPS. Como o sistema será utilizado em veículos, serão feitos alguns testes em carro de passeio em locomoção e os valores lidos serão armazenados pelo Labview. Este é o objetivo maior desta interface. Outro passo é o teste do módulo GPRS, onde serão feitos testes de funcionamento e controle do aparelho. Testes de funcionamento, envio de comandos, mensagens SMS, envio e recebimento de pacotes TCP/IP. Antes de concluir os testes com o GPRS, o software para o micro-controlador será desenvolvido e testado juntamente com o GPRS. Também testes de comunicação entre dois módulos GPRS, envio de dados de um para o outro e vice versa. Após conclusão desses testes e comprovado o funcionamento, entrará o GPS em funcionamento novamente. O GPS envia dados para micro-controlador que envia para o GPRS. Este envia para outro módulo GPRS e traduzido em micro-controlador ou um computador convencional. Com os três módulos interagindo, será feito outro ou outros testes em campo. O kit será testado em movimento, com um carro em movimento, e os dados serão armazenados e anotações serão feitas, como por exemplo, a velocidade do carro, trajeto verificado pelo Google Earth e GPS comercial. Outro kit com os três módulos ficará em laboratório simulando uma central que recebe os dados do carro e processa localização e tempo estimado para retorno, sendo que o caminho já foi pré-estabelecido. Este teste validará o projeto, entretanto, um teste final almejado é um teste real em ônibus da rede de transportes urbanos da cidade de Curitiba. O teste realizado com o carro é o parâmetro de sucesso do projeto. O teste consiste em definir uma rota, estabelecer um tempo para o percurso. Na segunda volta, serão criados improvisos e testando assim a capacidade do sistema de atualizar e estimar um novo horário de chegada. 11 MÓDULO MÓVEL O módulo móvel é composto de três equipamentos. GPS – Micro Controlador – GPRS. Eles interagem da seguinte maneira: Figura 5 - Funcionamento Módulo Móvel GPS O GPS recebe o sinal dos satélites e a cada meio segundo transmite pela porta serial (taxa de 4800bps) as informações. Esse modelo da Trimble está configurado para transmitir três mensagens: $GPZDA,122342.44,10,12,2007,,*6F $GPGGA,122342.00,2526.9955,S,04914.9689,W,1,03,2.12,00872,M,-000,M,,*40 $GPVTG,000.0,T,015.8,M,000.0,N,000.0,K,A*2F Essas mensagens seguem o protocolo NMEA 0183 [8] e sempre seguem a mesma ordem de informações. Esse protocolo garante que as mensagens são entregues sempre na mesma ordem e sempre com uma vírgula entre cada informação. A vírgula é um parâmetro importante, pois quando o equipamento não consegue captar as informações do satélite somente as vírgulas são transmitidas. Com isso, o software implementado no PIC (Micro controlador) conta as vírgulas para buscar as informações úteis ao projeto. Informações como altitude, número de satélites foram descartadas. 12 GPRS O GPRS é o link entre o módulo móvel e o servidor, é a interface de saída de dados. A configuração do módulo é feita quando o veículo entra para a rota, ou seja, quando ele sai da garagem (no caso de ônibus) e se encaminha para a linha que ele fará. A configuração consiste em habilitar as mensagens de status do comando. Com isso, depois de cada comando configurado o módulo transmite uma mensagem de OK quando comando recebido com sucesso e ERROR quando o comando recebido não foi interpretado corretamente ou há falha na configuração. Quando o módulo é iniciado ele faz algumas rotinas de testes e transmite mensagens se os testes forem bem sucedidos, logo, o primeiro teste do software é verificar se a rotina de testes do módulo foi bem sucedida (checar porta serial, checar sinal, e outras). Todas as mensagens são enviadas pela porta serial do módulo. A taxa de comunicação é de 115200bps, bastante alta para uma porta serial. !"# $ %&'%()%* ($+ !%*),* +,-+,-*)$* ./)'0$ ,!1 %* #$.%!)$ !8$ %&'%()%* (,-2$-+%*)$* ./)'0$ (,-2$-+%* $34 -. ,!1 %* 2(/5 .$-* #$.%!)$- #$!6 &'(%78$* $34 +,(. !%*$* 2($&(%.%*,* %#,!),*0,)* 1,(.,09$ ,!#,((%* ($+ !% 6. Figura 6 - Fluxograma da Configuração do Módulo GPRS Devido à alta velocidade da porta serial algumas mudanças ocorreram no software para que as mensagens de status fossem recebidas e interpretadas corretamente pelo PIC. 13 A principal mudança do software consiste em habilitar a interrupção da porta serial do software, isso garante que nenhum dado será perdido, mas sim, armazenado em uma variável. PIC – Micro Controlador (Software) O PIC é a interface que gerencia e comanda o GPS e o GPRS. Inicialmente o cristal (clock) era de 4MHz, contudo, devido à alta taxa de comunicação pela porta serial (RS232) com o módulo GPRS (115200bps) o clock foi alterado para um cristal de 20MHz. Essa alteração no cristal fez com que o PIC 16F877A executasse as linhas de comando cinco vezes mais rápido. A idéia do software é bastante simples, abaixo ela é exemplificada: Figura 7 - Fluxograma do Software do PIC O módulo móvel possui uma operação bastante simples para que não dependa do operador (motorista). Com isso, o software precisa gerenciar os erros durante a configuração do GPRS e os demais que podem ocorrer na recepção dos dados do GPS. Nessa filosofia o protótipo ficou com o botão de reinício (reset) e de permanência de rota. O botão de reset deve ser pressionado sempre que houver algum erro, nesse caso um LED vermelho se acenderá. Caso não haja erro algum o LED verde permanecerá aceso e um LED amarelo fica piscando para informar que o programa não está travado. Quando o 14 veículo estiver saindo de linha e voltando para a garagem uma chave deverá ser mudada de posição. Nessa transição da chave, o software inicia o processo de encerramento de socket com o servidor. Esse é um fator importante, pois é através do socket que o servidor verifica se o ônibus está operante ou não. Para informar que o socket foi encerrado e o módulo móvel óvel pode ser desligado todos os LED acendem e permanecem acesos. Testes confirmaram o uso do módulo móvel em baterias de 12V. Para sintetizar o uso, uma placa fonte foi criada e pode ser observada abaixo. Testes em baterias de automóveis ainda serão feitas feitas e necessitarão de um circuito mais preciso e com filtros. A placa fonte possui os LED de indicação e três reguladores de tensão. Um para cada equipamento, ou seja, o GPS, PIC e GPRS. Figura 8 - Placa HexKIT 16F877 e Placa de LEDs LEDs e Alimentação Como o GPRS e GPS utilizam interface serial de comunicação, foi necessário criar outra saída serial para o PIC. O PIC possui uma serial implementada em seu hardware. Logo, a saída encontrada foi utilizar um software que gerencia outra por porta serial. O software utilizado foi baseado no software publicado no livro Microcontroladores PIC - Programação em C [9]. No livro há o programa pronto para a velocidade de 9600bps, no protótipo a velocidade usada é de 4800bps (taxa do GPS), logo, alterações alterações foram feitas para o perfeito funcionamento. A mudança do cristal do PIC trouxe mudanças ao software de gerenciamento do módulo móvel. Primeiramente, o software que gerenciaria as informações oriundas do GPS armazenaria 200Bytes na memória EEPROM do PIC e depois varreria essa memória em busca das informações úteis. Em testes essa lógica era bastante funcional, mas quando ligado ao GPS muitos dados eram perdidos e problemas no software que trata serial 15 apareceram. A mudança do cristal deixou as operações do PIC cinco vezes mais rápida com isso uma nova lógica no programa que trata os dados do GPS pode ser implementada. O gerenciamento dos dados ficou dinâmico, ou seja, a partir que um Byte era recebido ele já era tratado. Essa lógica só pode ser implementada devido à velocidade do clock e alterações no software que gerencia a serial que comunica com o GPS. A transmissão bit a bit foi verificada e alguns parâmetros alterados para que o PIC tivesse tempo hábil de checar os dados recebidos pelo GPS e tomar as decisões necessárias. O PIC está programado a ler os dados do GPS e transmitir o pacote de informações a cada quinze segundos aproximadamente. Para viabilizar o projeto financeiramente, as informações não necessárias ou de redundância foram retiradas, assim, criou-se um protocolo de comunicação e envio de dados cuja mensagem não possui mais que cinqüenta bytes. 16 SERVIDOR Introdução Teórica ao C++ Builder O C++ Builder é um ambiente de desenvolvimento para aplicações cliente/servidor produzido pela Borland, tradicional empresa desenvolvera de compiladores. O C++ Builder utiliza os conceitos de programação visual e dirigida por eventos para proporcionar uma ferramenta RAD (Rapid Application Development) extremamente poderosa, que permite desenvolver aplicações eficientes rapidamente. Algumas de suas características mais marcantes são: Uso de uma biblioteca de componentes visuais, a VCL (Visual Components Library), desenvolvida originalmente para o Delphi, ferramenta produzida pela mesma empresa com características semelhantes ao C++ Builder, só que utilizando a linguagem Object Pascal como linguagem base. Orientação a objetos: o C++ Builder utiliza a linguagem de programação orientada a objetos C++, onde se podem utilizar plenamente os conceitos de POO (Programação Orientada a Objetos) e obter os seus benefícios. Possui um excelente ambiente de desenvolvimento (IDE) com ferramentas de produtividade que auxiliam a programação, além de um ótimo depurador (debugger) !"##$%"&'$()*$#$)+"("&,-.,/%"&'-)"%)"01/*"()+")programadores e controle de versões. Grande escalabilidade no acesso a banco de dados: pode acessar tabelas locais dBase e Paradox, assim como SGBDs como MySQL, Informix, Sybase, Microsoft SQL Server e Interbase. Introdução Teórica ao Banco de Dados e Tabelas O que é um banco de dados? É um arquivo, que permite de maneira fácil e organizada acessar as informações contidas nele. Atualmente, possuímos cerca de 5% das informações do site armazenadas em um banco de dados. Nós utilizamos o melhor banco de dados gratuito do mercado, o MySQL. Sistema de banco de Dados Um sistema de banco de dados é um ambiente de hardware e de software, composto por dados armazenados em um banco de dados (BD), o software de gerência do banco de dados (SGBD) e os programas de aplicação. Dentro dos Bancos de Dados ficam as tabelas (como se fossem as categorias da estrutura dos dados) e nessas tabelas ficam as informações, dentro dessas tabelas é que ficam as informações, é uma ideologia de organização de dados, para facilitar nossa vida. 17 A plataforma do banco de dados utilizado no projeto foi o MySQL, pois e gratuito e de fácil integração com diversos aplicativos ou de softwares de gerenciamento de conexão, é também rápido e flexível o suficiente para permitir armazenar logs e figuras nele. As principais vantagens do MySQL são velocidade, robustez e facilidade de uso, trabalha com diferentes plataformas, Unix, Windows etc. Relacionamentos entre Tabelas Em um banco de dados, precisamos de alguma maneira para representar estes relacionamentos da vida Real, em termos das tabelas e de seus campos. Isto é possível com a utilização de "Relacionamentos entre tabelas", os quais podem ser de três tipos: Um para um; Um para vários; Vários para vários. Relacionamento do Tipo Um para Um: Esta relação existe quando os campos que se relacionam são ambos do tipo Chave Primária, que é um código único que identifica cada registro, em suas respectivas tabelas. Cada um dos campos não apresenta valores repetidos. Cada campo da tabela se relaciona com um único campo contido na outra tabela. Quando fosse necessário buscar as informações tais como nome, endereço, etc, estas podem ser recuperadas através do relacionamento existente entre as duas tabelas, evitando, com isso, que a mesma informação tenha que ser duplicada nas duas tabelas, inclusive aumentando a probabilidade de erros de digitação. Relacionamento do Tipo Um para Vários: Este é, com certeza, o tipo de relacionamento mais comum entre duas tabelas. Uma das tabelas (o lado um do relacionamento) possui um campo que é a Chave Primária e a outra tabela (o lado vários) se relaciona através de um campo cujos valores relacionados podem se repetir várias vezes. Considere o exemplo entre a tabela Clientes e Pedidos. Cada Cliente somente é cadastrado uma única vez na tabela de Clientes (por isso o campo Código do Cliente, na tabela Clientes, é uma chave primária, indicando que não podem ser cadastrados dois clientes com o mesmo código), portanto a tabela Clientes será o lado um do relacionamento. Ao mesmo tempo cada cliente pode fazer diversos pedidos, por isso que o mesmo Código de Cliente poderá aparecer várias vezes na tabela Pedidos: tantas vezes quantos forem os pedidos que o Cliente tiver feito. Por isso que temos um relacionamento do tipo Um para Vários entre a tabela Clientes e Pedidos, através do campo Código do Cliente, indicando que um mesmo Cliente pode realizar diversos (vários) pedidos. Relacionamento do tipo Vários para Vários: 18 Este tipo de relacionamento é utilizado quando temos uma situação onde em ambos os lados do relacionamento os valores poderiam se repetir. Vamos considerar o caso entre Produtos e Pedidos. Posso ter Vários Pedidos nos quais aparecem um determinado produto, além disso, vários Produtos podem aparecer no mesmo Pedido. Esta é uma situação em que temos um Relacionamento do Tipo Vários para Vários. Na prática não é possível implementar um relacionamento deste tipo, devido a uma série de problemas que seriam introduzidos no modelo do banco de dados. Por exemplo, na tabela Pedidos teríamos que repetir o Número do Pedido, Nome do Cliente, Nome do Funcionário, Data do Pedido, etc para cada item do Pedido. Para evitar este tipo de problema é bastante comum "quebrarmos" um relacionamento do tipo vários para vários em dois relacionamentos do tipo Um para Vários. Isso é feito através da criação de uma nova tabela, a qual fica com os lados vários dos relacionamentos. No nosso exemplo vamos criar a tabela Detalhes do Pedido, onde ficam armazenadas as informações sobre os diversos itens de cada pedido, aí ao invés de termos um relacionamento do tipo Vários para Vários, teremos dois relacionamentos do tipo um para vários. DRIVER OBDC Para que o MySQL se conecte com o C++ Builder é necessário a instalação de um Driver OBDC (Open DataBase Connectivity), que é um método de acesso a Banco de Dados desenvolvido pela Microsoft, com a finalidade de tornar possível acessar qualquer dado de qualquer aplicação independentemente do Banco de Dados usado. FERRAMENTAS DE CONEXÃO C++ BUILDER COM O MySQL O C++ Builder oferece uma série de ferramentas e recursos que possibilitam a criação de aplicações de bancos de dados de forma rápida e fácil. O coração das aplicações de bancos de dados do C++ Builder está no Borland Database Engine (BDE), uma camada de software que realiza o acesso a bancos de dados baseados em arquivos como Paradox e dBase ou a servidores de bancos de dados locais ou remotos como MySQL e etc. Os componentes de bancos de dados do C++ Builder oferecem uma forma simplificada, que usa programação visual baseada em PME (Propriedades, Métodos e Eventos), para acessar a API do BDE. Há duas grandes classes de componentes: os componentes de acesso a dados (data-access) e os componentes de controle, visualização e manipulação dos dados (datacontrols), sendo que os componentes de visualização e manipulação de dados são também denominados de componentes data-aware (componentes capazes de mostrar e atualizar os dados armazenados em uma tabela associada). Estes dois grupos de componentes estão 19 localizados, respectivamente, nas páginas Data Access e Data Controls da paleta de componentes do C++ Builder. Os principais componentes do tipo data-access utilizados na criação de aplicações com bancos de dados em C++ Builder são os componentes derivados da classe abstrata TDataSet, que são: Table da classe TTable, Query da classe TQuery e StoredProc da classe TStoredProc. Qualquer um dos componentes derivados da classe TDataSet podem ser referenciados como datasets. Os componentes Query e StoredProc são mais utilizados em aplicações cliente-servidor e serão vistos posteriormente. O componente Table oferece a forma mais simples de se acessar informações em uma tabela de banco de dados do que a Query Um dataset possui um conjunto de estados onde pode se encontrar. Os estados possíveis são: Estado Descrição Inactive Dataset encontra-se fechado Browse Estado no qual o dataset se encontra aberto, permitindo leitura, porem não permitem ser alterados ou inseridos. Edit Permite a edição ou alteração do registro corrente. Insert Permite que uma nova linha ou registro seja inserido. Após a chamada do método Post, uma nova linha é gravada na tabela e o dataset volta ao estado Browse. SetKey O estado no qual o dataset se encontra quando o mesmo é aberto e permanece a maior parte do tempo de seu uso. Registros podem ser lidos, mas não alterados ou inseridos. CalcFields Estado que ocorre quando um campo calculado está sendo atualizado. Uma aplicação pode posicionar um dataset em determinado estado através de uma chamada explícita a um método ou através da ocorrência de um evento que desencadeie uma troca de estado. Há métodos que sempre levam para determinado estado e são chamados métodos correspondentes aos estados. São eles: Edit, Insert, Append e Setkey. Outro conjunto de métodos sempre retorna o dataset para o seu estado de Browse como Delete, Cancel, GotoKey e GotoNearest. Há casos em que o sucesso ou insucesso do método define se o dataset volta ao estado de Browse, como o método Post. O diagrama de estados da Figura 10 mostra os possíveis estados de um dataset e os métodos que causam as trocas de estado para outro. 20 Figura 9 – Diagrama de estados de um dataset O componente Table é a interface entre o Borland Database Engine e os componentes DataSource O componente DataSource por sua vez oferece a interface para os componentes data-aware. que irão compor a interface com o usuário. Trabalhando-se com o componente Table usa-se a propriedade DatabaseName para especificar o banco de dados a ser acessado; a propriedade TableName serve para indicar a tabela a acessar; utiliza-se a propriedade IndexName para definir o uso de um determinado índice com a tabela; configura-se a propriedade Active para True ou chame-se o método Open para abrir o dataset, colocando ele no estado Browse; coloca-se a propriedade Active em False ou chame-se o método Close para fechar o dataset. O componente DataSource é a interface entre um componente dataset e os componentes data-aware nos formulários. O DataSource liga-se a um dataset através da propriedade Dataset. Os componentes Data-aware, como DBEdit e DBGrid, ligam-se ao DataSource através de suas propriedades DataSource. Usualmente há apenas um DataSource para cada dataset, no entanto podem-se conectar a um dataset tantos DataSource quantos forem necessários. Para monitorar-se alterações no estado do dataset associado ao DataSource pode-se associar um método ao evento OnStateChange. Há vários componentes do tipo data-controls no C++ Builder, como DBGrid que permite a visualização, alteração e navegação no conjunto de todos os registros e campos de uma tabela; o DBText que mostra os dados em um campo de uma tabela como um label read-only similar ao componente Label; o DBEdit usado para apresentar e alterar os valores de um campo numa caixa de edição similar a um componente Edit; o DBImage que apresenta gráficos e figuras do tipo bitmap armazenados em um campo do tipo BLOB 21 (Binary Large Object), de forma semelhante ao realizado pelo componente Image; e o DBNavigator que oferece um conjunto de botões para navegar pelas linhas de um dataset, adicionar ou eliminar uma linha, colocar o dataset no estado de edição, confirmar ou cancelar as alterações realizadas no dataset ou recarregar os dados do disco, atualizando o dataset. MODELAGEM DE BANCO DE DADOS Antes da implementação do banco de dados, foram estabelecidas algumas perguntas básicas que seriam utilizadas para consultas do sistema e para obter os dados para o cálculo estimado do próximo ônibus a estação. Primeiramente o banco de dados foi esboçado no Microsoft Excel com tabelas básicas e com alguns campos considerados de suma importância. Com o de correr do projeto, foram feitas análises e questionamentos sobre o relacionamento entre as tabelas e dados contidos nelas para as futuras consultas do sistema e para evitar a duplicidades entre campos e dados das tabelas. Devido a essa maior análise e modelagem do banco de dados, a cada nova idéia o número de tabelas foram aumentando e ficando mais complexas em seus relacionamentos, havendo a necessidade da utilização de um software especifico e apropriado para a modelagem do banco, o DBDesigner, da fabFORCE, que é um software open-source e de uso gratuito. Este software nos fornece uma interface gráfica e de análise do banco de dados assim como a dependência entre as tabelas e seus respectivos campos. Na primeira modelagem, foram construídas seis tabelas, Figura 11, na qual a tabela ônibus que conteria os dados do ônibus como código, tipo e telefone. Tabela estação com informações sobre a estação ou terminal de conexão entre as linhas, tabela linha que definia quais seriam as linhas do sistema de transporte e sua rota, ida ou volta na linha. A tabela tempos que armazenaria os dados referente em todos os ônibus e sua respectiva linha e seu tempo gasto entre as estações. Tabela log na qual ficaria responsável pela status de conexão, online ou off-line, entre o módulo móvel GPRS e o servidor, e tabela aviso que armazenaria os dados transmitidos de todos os ônibus do sistema do sistema em todo seus percurso. 22 Figura 10 – Primeira modelagem do banco de dados A modelagem intermediária do banco surgiu com a necessidade da implementação de algumas consultas do sistema, como a identificação de quais os ônibus de uma respectiva linha, quais os ônibus que estavam off-line, quais estações de uma linha e etc. Então para que essas consultas fossem realizadas foi criado mais tabelas e mais campos que estivessem se relacionando, para evitar assim a duplicação dos dados ou não igualdade em cada cadastro da tabelas, pois com o relacionamento esses dados seriam linkados (ligados) através de um campo identificador único. Nessa segunda modelagem, Figura 12, nenhuma tabela permaneceu igual a da primeira modelagem, a tabela ônibus foi acrescentada o campo de código de linha, na qual se relaciona com a tabela linha através do seu código único de identificação (chave primaria). Na tabela linha foi retirada o código de rota, pois a mesma será relacionada através da tabela rota, pelo sua chave primaria. A tabela estação também teve alguns campos retirados, como as coordenadas obtidas do GPS, pois a tabela irá relacionar com a tabela pontos através do seu código de identificação, evitando assim a inserção de dados diferentes. A tabela pontos possui também o código identificador de rota, obtido do relacionamento da tabela rota. Por último, a tabela dados, que é onde será registrado todo o sinal enviado pelos ônibus da frota, seus campos são de data, hora, código do ônibus, se o ônibus esta com problema, fora de rota, off-line e etc, assim como as coordenadas e velocidade atual; possui duas chave de relacionamento obtidos através da tabela ônibus e da tabela rota. 23 Figura 11 – Segunda modelagem do banco de dados Com o decorrer do projeto, algumas consultas precisaram ser implementadas no sistema, na qual algumas delas seriam de suma importância para o calculo estimado do próximo ônibus em uma estação da linha. Porém para que algumas dessas consultas fossem idealizadas houve uma necessidade de alteração na modelagem do banco de dados devido ao relacionamento entre as tabelas e seus campos, assim como que algumas tabelas serem dinâmicas e estáticas. As tabelas estáticas, ônibus, estação, rota, linha e pontos, teriam seus dados inseridos uma única vez, servindo assim como histórico mesmo se algum registro fosse desativado. Já as tabelas dinâmicas, seriam alimentadas de forma contínua, em que poderiam seus campos poderiam ser alterados ao longo do dia ou período. Com isso o banco sofreu mais algumas mudanças em sua modelagem, conforme a Figura 12, na qual mostra que algumas tabelas como ônibus, estação, rota e linha tem apenas dados básicos de cadastro e sua chave primaria, na qual se relaciona com as outras tabelas tendo uma dependência desses dados. Com isso um ônibus, rota, linha ou estação pode sair de operação mais seus históricos preservados no sistema. 24 Figura 12 – Terceira modelagem do banco de dados SERVIDOR DE CONTROLE DE TRAFEGO DO TRANSPORTE COLETIVO O software do servidor é responsável pelo gerenciamento de todo o sistema de tráfego e controle dos ônibus, é ele que recebe os dados enviados por todos os ônibus, é onde são cadastrados ônibus, rota, linha, estação e demais informações. Sendo também a interface de conexão entre o usuário e o banco de dados MySQL. Funcionamento Lógico Geral A Figura 14 demonstra o funcionamento geral do sistema, que é composto por um banco de dados MySQL, componentes básicos de socktes internet e um software local desenvolvido em C++ Builder. O Software local servirá de interface entre o banco de dados e o usuário do sistema, nas consultas, cadastros, alterações e exclusões de registros de dados do sistema do transporte coletivo. 25 Figura 13 – Fluxograma geral do Servidor Funcionamento do Software O Software é responsável pelo recebimento da mensagem enviada pelo módulo móvel GPRS contido em todos os ônibus da frota, informando seu código, data, hora, velocidade e coordenadas atual. Esses dados são transmitidos na rede celular GSM através do serviço de GPRS pelo padrão TCP/IP, esses dados chega ao servidor através da internet 26 por sockets. Esses sockets são definidos através de uma porta estipulada tanto no módulo móvel, quanto no software servidor, sem isso a conexão não se efetuará como mostra o fluxograma da Figura 15. O C++ Builder possui alguns componentes de criação do servidor socket ou cliente socket. Figura 14 – Fluxograma da conexão socket Após estipulada e ativada essa porta, o servidor fica em modo de espera da conexão, quando ocorre a conexão entre servidor e módulo móvel, é transmitido à mensagem. O servidor recebe essa mensagem através de uma Edit Box e logo em seguida separa em seis novas mensagens. Sendo elas: código do ônibus, hora, data, latitude, 27 longitude e velocidade. Depois de separada essas novas mensagens o sistema chama o banco de dados MySQL e as insere na tabela dados, Figura 16. :;<=> %?@A*<>:ABC>*<>D* .E-F0 -..&$/&$/)!""/.$ 0/"!$1!$2/1&" !"#!$"!$%&'(!$ )&*!+,& DE9 ABC -"#/3!4!)!$ )&*!+,&$)&5$ 0/"! 67'/.1/$1/1&"$ 1&"$20-28# 93#:5$ "#.8*7$ !*(8/1/ -*;'/*#&$*,&$ !*)&*#./.$<=> ABC DE9 2!")/.#/$)/./)#!. -*;'/*#&$*,&$ !*)&*#./.$<?> 2!")/.#/$)/./)#!. DE9 6.5/@!*/$ )/./)#!. 63.!$#/3!4/$2/1&" 6.5/@!*/$ 1/1&"$*/$ #/3!4/ DE9 !"#/$"!$8*"!.8' ABC F!)%/$#/3!4/$ 2/1&" F85 Figura 15 – Fluxograma de inserção de dados à base 28 A tabela dados possui mais informações além das seis mensagens obtidas, como problema e status do ônibus. Esses dois outros campos são obtidos através de uma consulta do último dado enviado ao servidor, se o mesmo estou o tempo de envio da próxima mensagem no caso do campo status e no campo problemas através de consulta se o ônibus esta fora de rota, entre outras. A inserção desses dados no MySQL através do C++ Builder foi desenvolvida utilizando a ferramenta Builder através de alguns componente como o Database que fornece o acesso à base de dados, UpdateSQL responsável pela atualização dos registros da tabela, Query componente que faz a consulta à base de dados, Table permite a consulta e edição de registro na base, e DataSource que é componente de acesso as tabelas. O servidor possui diversos formulários, janela principal, Figura 17, que fornece uma tabela com as dados recebidos de cada módulo móvel, menus de acesso a cadastro e consulta de ônibus, rota, linha estações, e também do acesso as consultas dos sistemas através dos botões. Um formulário de dados, onde são inseridos os componentes de acesso ao banco de dados ao MySQL acima descritos. E demais formulário de cadastro, inserção, alteração, exclusão e consulta como ônibus, rota, linha, estação, pontos e etc. Figura 16 – Formulário principal Nos formulários de cadastro foi utilizado o componente DBEdit da página data controls que é usado para receber dados do usuário e atribuí-los ao campo de um registro de uma tabela, conforme Figura 18. Os campos são verificados se estão corretos e se não estão faltando antes que o comando de inserção ao banco de dados. 29 Figura 17 – Formulário de cadastro e consulta O componente DBGrid também da página data controls, exibe um objeto semelhante a uma planilha do EXCEL que nos permite manipular registros de uma banco de dado, ou seja, de um componente Table ou Query, toda vez que esse formulário é aberto ele carrega os registros do sistema. Informando um erro quando não consegue o acesso a tabela. Nos formulários de consultas existem rotinas em SQL que faz a localização de um determinado registro com informações obtidas através dos Edit Box preenchida pelo usuário do sistema, sempre verificando se houve a conexão com a tabela e informando erro se houver. Os comandos de consultas em SQL são adicionados na string para depois serem executados. Porém, duas consultas não funcionam dessa forma, pois os comandos enviados para criar tabelas temporárias não tiveram êxito. Para contornar esse problema houve a necessidade de fazer outra modelagem no banco de dados do sistema, conforme descrito anteriormente através das tabelas dinâmicas. CONSULTAS DO SISTEMA Foram estabelecidas algumas consultas no sistema para verificar os históricos de informações que ocorreram eu uma determinada data ou situação do ônibus. Essas consultas foram realizadas utilizando a linguagem SQL, Structured Query Language, A SQL é uma linguagem de alto nível. Um aplicativo não diz ao mecanismo de banco de dados como deve executar uma tarefa, mas enuncia o que o resultado deve conter. Uma consulta é uma pergunta que um aplicativo faz a um banco de dados e depois retorna registros. As consultas retornam um conjunto de registros que satisfazem a alguns critérios e contêm informações de campos selecionados. Ao falar sobre consultas, considere toda instrução SQL como uma pergunta. O resultado conseguido é a resposta que o mecanismo de banco de dados dá. Existem 30 algumas instruções SQL que são simplesmente um comando. Para esse comando, você não receberia um resultado. Entretanto, para perguntas ou consultas, um resultado é o conjunto de registros retornados pelo mecanismo de banco de dados. Por serem uma linguagem de alto padrão essas consultas foram pré-determinadas e inseridas dentro do código de programa do servidor, portanto cabe ao usuário somente a inserção de alguns campos determinados para ter o resultado da consulta. Algumas das consultas realizadas são: 1234567- QUAIS ÔNIBUS ESTÃO OFFLINE? QUAL FOI O PROBLEMA NO DIA 00 DO ÔNIBUS X? NA LINHA X EXISTEM QUAIS ÔNIBUS? QUAIS ÔNIBUS PASSAM NA ESTAÇÃO W? QUAIS SÃO AS ESTAÇÕES DA LINHA Y? ONDE ESTÁ O ÔNIBUS X AGORA? QUAL É A COORDENADA DA ESTAÇÃO W? A tabela abaixo mostra as perguntas e os campos que serão fornecidos e os obtidos nas consultas: o N. Pergunta? Dados Fornecidos QUAIS ÔNIBUS ESTÃO OFFLINE? status QUAL FOI O PROBLEMA NO DIA 00 DO data Campo de Resultado data max (curdate) (hora) ônibus status ônibus ônibus problema ÔNIBUS X? NA LINHA X EXISTEM QUAIS ÔNIBUS? data QUAIS ÔNIBUS PASSAM NA ESTAÇÃO data ônibus linha estação rota ônibus linha W? estação QUAIS SÃO AS ESTAÇÕES DA LINHA linha Y? ONDE ESTÁ O ÔNIBUS X AGORA? ônibus data max (curdate) (hora) QUAL É A COORDENADA DA ESTAÇÃO estação onibus coordenada coordenada W? Para cada uma dessas consultas efetuaremos query no banco de dado do MySQL, usando o comando SELECT e ate mesmo tabelas temporárias. A instrução SELECT é usada para recuperar informações de uma tabela. A forma geral da instrução é: SELECT o que mostrar FROM de qual tabela WHERE condições para satisfazer; O que mostrar indica o que você deseja ver. Isto pode ser uma lista de colunas ou * para indicar todas as colunas. De qual tabela indica a tabela de onde você deseja recuperar os dados. A cláusula WHERE é opcional. Se estiver presente, condições para satisfazer especificam as condições que os registros devem satisfazer para fazer parte do resultado. 31 1- QUAIS ÔNIBUS ESTÃO OFFLINE? Para que essa consulta possa ser feita devemos que fornecer o status do ônibus, no caso OFFLINE, data corrente e o ultimo evento enviado pelo ônibus, definido por max (hora). A pesquisa retornará todos os ônibus, cujo estado status for igual à OFFLINE, ordenado de forma crescente pelo código. SELECT onibus_cod_onibus, linha_cod_linha ,max(hora) AS hora FROM dados where status="offline" AND data_ ="CURDATE()" GROUP BY onibus_cod_onibus; 2- QUAL FOI O PROBLEMA NO DIA 00 DO ÔNIBUS X? Nessa consulta, devemos informar a data e qual ônibus, no formato “PL000” ou “*” para todos. Os dados de retorno são código do ônibus, linha, data, hora e o problema encontrado. SELECT onibus_cod_onibus, linha_cod_linha,data_, hora, problema FROM dados where data_="data escolhida" AND cod_onibus=”X” ORDER BY cod_dados; 3- NA LINHA X EXISTEM QUAIS ÔNIBUS? Forneceremos a data e a linha para efetivar esta consulta, retornando o código dos ônibus como resultado. O comando DISTINCT tem como função de listar somente uma única entrada de todos os ônibus. SELECT DISTINCT onibus.onibus_cod_onibus FROM onibus,onliro WHERE data_2="data escolhida" AND onliro.onibus_cod_onibus=dados.onibus_cod_onibus AND onliro.linha_cod-linha="X"; 4- QUAIS ÔNIBUS PASSAM NA ESTAÇÃO W? Para essa consulta precisamos fornecer a estação e data. O resultado da pesquisa será o campo código do ônibus e a linha do mesmo. SELECT DISTINCT onliro.onibus_cod_onibus FROM onliro,esliro,estacao WHERE esliro.linha_cd_linha=onliro.linha_cod_linha AND esliro.estacao_cod_estacao=estacao.nome="estação escolhida"; 5- QUAIS SÃO AS ESTAÇÕES DA LINHA Y? Nessa consulta, é necessário fornecer a linha, retornando como resultado o nome das estações. 32 SELECT DISTINCT estacao.nome FROM estacao,esliro WHERE esliro.estacao_cod_estacao=estacao.cod_estacao AND esliro.linha_cod_linha=”Y”; 6- ONDE ESTÁ O ÔNIBUS X AGORA? Fornecendo o código do ônibus, data corrente (curdate), último dado enviado pelo ônibus, definido pelo parâmetro max(hora). O resultado retornado será o código ônibus, lat_g, lat_m, lat_s, lat_ms, lon_g, lon_m, lon_s, lon_ms, utilizando o parâmetro GROUP BY onibus_cod_onibus para agrupar os dados pelo código do ônibus. SELECT lat_g,lat_m,lat_s,lat_ms,lon_g,lon_m,lon_s,lon_ms FROM dados where (onibus_cod_onibus="ônibus escolhido" AND data_ 2="CURDATE()"); 7- QUAL É A COORDENADA DA ESTAÇÃO W? Essa consulta o campo fornecido é o nome da estação, retornando os campos de lat_g,lat_m,lat_s,lat_ms,lon_g,lon_m,lon_s,lon_ms. SELECT pontos.lat_g,pontos.lat_m,pontos.lat_s,pontos.lat_ms,pontos.lon_g,pontos.lon_m,pontos.lon _s,pontos.lon_ms FROM estacao,espo,pontos espo.pontos_cod_pontos=pontos.cod_pontos WHERE AND espo.estacao_cod_estacao=estacao.cod_estacao AND estacao.nome="nome da estação"; CÁLCULO DO TEMPO ESTIMADO DO PRÓXIMO ÔNIBUS O aplicativo também faz o cálculo do horário estimado da chegada do próximo ônibus em cada estação determinada pela sua linha. Para que o cálculo propriamente seja executado, é preciso primeiramente entrar com o nome da estação, o sistema obtém o último dado enviado pelo ônibus, faz uma consulta SQL procurando a qual linha ele pertence. Depois, o sistema faz uma varredura nos registros de pontos das rotas cadastradas, para determinar a rota do ônibus na sua linha, ida ou volta. Foi estabelecido um algoritmo de valor próximo nos pontos, pois o equipamento de GPS utilizado não tinha uma precisão refinada, então o algoritmo buscava o valor mais próximo e implementava um contador, assim q esse contador fosse incrementado cinco vezes a rota era definida. Após a rota ser determinada, era verificada na tabela distância, a distância entre as duas estações, estação anterior e a próxima estação que o ônibus fará a conexão, tendo 33 esse valor, o calculo do tempo era determinado pela distância entre as estações subtraídas da distancia percorrida da estação anterior ate o ponto atual, dividido pela velocidade média do trajeto. Para que o tempo estimado inicial não fosse tão grande, devido à velocidade média no começo do trajeto ser muito baixa, os primeiros valores da velocidade eram descartados ate que a velocidade obter um valor mais estável, podendo ser verificado a linha lógica de raciocínio através do fluxograma da Figura 19. B*G)8& L!.8K8)/$;'/4$ !"#/M,& 93#:5$H4#85&$1/1&$!*(8/1&$ I!4&"$J*83'"$1/$K.&#/ L!.8K8)/$48*%/$;'!$ J*83'"$I!.#!*)! 63.!$#/3!4/$P&I& L/..!$#/3!4/$P&I&$/#:$ ;'!$)&&.1!*/1/$/#'/4$ )&5$)/1/"#./1/?$"!$ DE9 N.O+85&$.!78"#.& ABC L!.8K8)/$;'/4$/$.&#/ 93#:5$18"#Q*)8/$ !*#.!$!"#/MR!" S/4)'4/$18"#/*)8/$ I!.)&..81/ S/4)'4/$ !5I&T UV18"#W$!*#.!$!"#/MR!"X 18"#W$N!.)&..81/YZ L!4W5:18/ -+83!$#!5I& /I.&+85/1& F85 Figura 18 – Fluxograma para o cálculo do tempo estimado de chegada do próximo ônibus 34 ALGORITMO DO CÁLCULO DO TEMPO ESTIMADO O algoritmo do cálculo do tempo estimado do próximo ônibus necessita da coordenada do ponto anterior transmitido e a da coordenada atual, ele transforma cada ponto desses de graus para radianos, através da Fórmula 1 e 2 abaixo: graus " min utos segundos décimos de segundos " " ! valor em rad 60 3600 216000 (1) Exemplo: Latitude: 25º27`20``64``` !" # % $' " " ) %*''' $% &$%% ($%%% Após transformação das coordenada anterior e da atual para radianos, faz-se o cálculo da distância, em metros, entre esses dois pontos através da Fórmula 2. D ! 1111200 ' ar cos%sen# p1$ ' sen# p 2$ " cos# p1$ ' cos# p 2$ ' cos# p1 ( p 2$&' 180 pi () (2) Para cada coordenada transmitida, o algoritmo fará o cálculo da distância e armazenará em um somatório todas as distâncias da estação anterior até ponto atual. O algoritmo faz o cálculo da velocidade média do trecho através do somatório da distância dividido pelo tempo desde estação anterior até ponto atual. Após obtido o valor da velocidade média, ocorre o cálculo do tempo estimado, obtido através da subtração da distância entre as duas estações pelo somatório da distância percorrida até ponto atual, divididos pela velocidade média, conforme Fórmula 3. tempo estimado ! distância entre estações ( ) distância percorrida velocidade média (3) Cada dado novo transmitido obtém se um valor novo estimado do tempo, devido a um novo valor obtido da distância percorrida e da velocidade média do trecho. Para a verificação e validação do algoritmo foi efetuados em uma planilha de cálculos do Microsoft Excel, inserindo todos as coordenada obtida no percurso da Linha 1 (Portão 1/ Portão 2), conforme tabela a baixo. 35 hora 113706 113710 113714 113718 113722 113726 113730 113734 113738 113742 113746 113750 113754 113758 113802 113806 113810 113814 113818 113822 onibus $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 data 271107 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 lat g 25 27 27 27 27 27 27 27 27 27 27 27 27 27 27 27 27 27 27 27 lat m 27 14 15 16 17 18 18 18 19 19 19 19 19 20 20 20 20 20 20 20 lat s 20 45 47 0 55 66 93 73 16 47 58 78 97 33 43 47 39 55 66 66 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 14 14 14 14 14 14 15 15 15 15 15 15 15 15 15 15 15 15 15 99 99 99 99 98 99 0 2 3 4 5 6 7 8 9 10 10 10 10 lat lon lon lon ms g m s 64 49 15 10 52 19.5 42 10.4 45 17.2 29 23.4 91 16.2 31 15.1 46 21.4 17 20.4 37 18.5 15 13.3 28 19.1 43 20.4 56 17.5 62 14.3 59 14.5 29 07.6 71 06.7 74 00.0 73 00.0 lon ms vel 71 00.0 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 0,4443 lat rad 0,4443 0,8598 0,8598 0,8598 0,8598 0,8598 0,8598 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 lon rad 0,8596 0 5,1E-06 1,1E-06 9,4E-06 5,7E-06 2,2E-06 0,00017 6,6E-06 6,4E-06 2,9E-06 5,6E-06 5,7E-06 5,3E-06 4,9E-06 4,2E-06 2,3E-06 3,3E-06 9,2E-07 7,3E-08 2,2E-07 ! dist(m) 0,0000 0,0000 1,3888 1,3888 0,4651 1,8540 5,8324 7,6864 21,1898 28,8762 14,5406 43,4169 26,5756 69,9925 31,1081 101,1005 33,9953 135,0958 36,2089 171,3047 35,4607 206,7654 18,5490 225,3143 40,4669 265,7812 42,3284 308,1096 1080,7944 1388,9040 13,9001 1402,8042 36,5637 1439,3679 59,6690 1499,0369 6,8370 1505,8739 32,2553 4 4 4 8 4 12 4 16 4 20 4 24 4 28 4 32 4 36 4 40 4 44 4 48 4 52 4 56 4 60 4 64 4 68 4 72 4 76 4 t 19,2266 19,8141 20,8200 21,1672 21,9188 23,1484 5,5020 5,1112 4,6940 4,6992 4,2826 3,7527 3,1594 2,4997 1,8090 1,4438 0,4804 0,1545 0,1736 Vmedia 0,0000 171,52328 168,06528 160,27431 160,46418 156,62968 148,91038 822,9492 894,15008 982,22814 985,09601 1089,2023 1252,6696 1498,6557 1906,584 2649,2151 3329,4297 10050,528 31289,361 27847,861 !" #DIV/0! 2,8587 2,8011 2,6712 2,6744 2,6105 2,4818 13,7158 14,9025 16,3705 16,4183 18,1534 20,8778 24,9776 31,7764 44,1536 55,4905 167,5088 521,4894 464,1310 t_min 113826 113830 113834 113838 113842 113846 113850 113854 113858 113902 113906 113910 113914 113918 113922 113926 113930 113934 113938 113942 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 26 26 26 26 26 26 27 27 27 27 27 27 27 27 27 27 27 27 27 27 96 96 97 97 98 99 0 1 1 1 2 3 4 5 7 9 10 11 11 13 47 32 5 89 64 49 39 6 26 68 52 18 38 85 27 2 36 21 89 16 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 14 14 4 3 3 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0 99 99 17 04.8 44 13.3 6 15.2 55 16.0 94 16.5 36 15.1 3 17.0 94 06.7 95 01.2 96 14.0 89 12.3 82 13.4 74 23.3 61 23.1 50 26.4 40 28.9 28 15.7 9 10.1 95 21.0 67 23.9 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4442 0,4442 0,4442 0,4442 0,4442 0,4442 0,4442 0,4442 0,4442 0,4442 0,4442 0,4442 0,4442 0,4443 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8598 0,8598 2,7E-06 3,8E-06 6,8E-06 3,2E-06 5,6E-06 0,00019 3,1E-06 1,6E-06 3,4E-06 3,6E-06 2,2E-06 6,5E-06 8,7E-06 5,1E-06 7,7E-06 7,6E-06 3,9E-06 0,00018 4,3E-06 7,3E-06 1538,1292 46,3461 1584,4753 27,4748 1611,9501 1128,2565 2740,2067 24,7931 2764,9997 48,7131 2813,7128 49,1278 2862,8407 32,3257 2895,1663 55,4156 2950,5819 41,3526 2991,9346 13,7751 3005,7096 22,8844 3028,5940 21,6271 3050,2211 10,3070 3060,5281 20,0219 3080,5500 1209,9121 4290,4620 35,5455 4326,0075 20,4925 4346,5000 43,5456 4390,0456 24,5073 4414,5529 17,1733 4431,7262 80 4 84 4 88 4 92 4 96 4 100 4 104 4 108 4 112 4 116 4 120 4 124 4 128 4 132 4 136 4 140 4 144 4 148 4 152 4 156 4 160 27,6983 28,2984 28,8819 29,3682 30,0417 30,6462 22,6511 23,1858 23,8299 24,4241 25,0476 25,7925 26,3445 26,8071 27,5273 28,1371 28,8021 29,7849 18,3176 18,8628 14,593501 14,89088 15,438595 16,665663 16,974185 17,799268 77,496944 76,573235 74,936264 73,99838 73,070195 71,4938 71,565624 72,397806 71,677918 71,870462 71,902497 70,362423 176,00496 172,3745 0,2432 0,2482 0,2573 0,2778 0,2829 0,2967 1,2916 1,2762 1,2489 1,2333 1,2178 1,1916 1,1928 1,2066 1,1946 1,1978 1,1984 1,1727 2,9334 2,8729 113946 113950 113954 113958 114002 114006 114010 114014 114018 114022 114026 114030 114034 114038 114042 114046 114050 114054 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 $JC007 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 271107 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 96 96 96 96 97 97 97 97 97 97 97 97 97 97 96 96 96 96 97 97 94 96 11 63 70 67 68 73 64 57 30 5 89 76 66 59 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 16 16 16 16 16 15 15 14 13 12 11 10 9 8 7 6 5 4 16 00.0 16 00.0 8 00.0 8 00.1 14 07.7 96 09.6 26 11.5 23 17.1 5 18.4 12 17.3 1 15.9 28 08.4 53 14.3 55 18.6 38 15.2 41 14.1 67 11.3 94 13.9 0,4444 distancia entre estações 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,4444 0,8597 0,8597 0,8597 0,8597 0,8597 0,8597 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0,8596 0 6,3E-07 1,6E-07 2,1E-06 4,5E-06 5,1E-06 4,6E-06 5,7E-06 3,9E-06 5,2E-06 2,5E-06 3,4E-06 4,7E-06 5,9E-06 4,3E-06 2,6E-06 2,5E-06 5,7E-06 4 164 4 168 4 172 4 176 4 180 4 184 4 188 4 192 4 196 4 200 4 204 4 208 4 212 4 216 4 220 4 224 4 228 4 232 36,3202 4468,0464 15,7568 4483,8033 16,6212 4500,4245 27,3270 4527,7514 37,8637 4565,6151 29,8739 4595,4889 21,3979 4616,8868 15,7565 4632,6434 33,3256 4665,9689 24,7694 4690,7384 36,2592 4726,9976 29,3241 4756,3217 32,7361 4789,0578 28,6571 4817,7149 13,1693 4830,8842 1,0313 4831,9155 4,0257 4835,9412 0,0000 4835,9412 20,8446 21,2103 21,5711 21,9586 22,3042 22,5899 22,8669 23,1716 23,4537 23,8060 24,1284 24,5579 24,9755 25,3645 25,7259 26,1653 26,6893 27,2442 0 0 0,1866255 0,2302982 0,8171666 2,0754157 3,4818649 4,7016098 6,1910446 7,1399029 8,4256831 8,9199121 9,6275322 10,657645 11,979766 12,822986 13,193973 13,503608 0,0000 0,0000 0,0031 0,0038 0,0136 0,0346 0,0580 0,0784 0,1032 0,1190 0,1404 0,1487 0,1605 0,1776 0,1997 0,2137 0,2199 0,2251 Conforme podemos observar na tabela acima, os primeiros valores do tempo estimado obtido é um valor muito alto devido à velocidade média ser próxima a zero. Para contornar esse erro de estimativa, até que a velocidade média adquira um valor constante, foram ignorados os quatorzes primeiros pontos da velocidade média. Com esse contorno, obtivemos um valor próximo do obtido no trajeto. Podemos validar o resultado do cálculo obtido através dos dados transmitidos pelo ônibus, no caso, o horário do GPS do início do trajeto até seu término. Portanto, pelo cálculo obtemos 3 minutos e 48 segundos, e pelos dados do horário do GPS, tem-se 2 minutos e 48 segundos. Embora seja uma diferença de 1 minuto, pode-se levar em conta que o algoritmo do cálculo estimado funciona perfeitamente validando assim o projeto de fim de curso. 39 ARMAZENANDO DADOS NO SERVIDOR: Para preencher o servidor com as rotas dos ônibus, um software foi desenvolvido na interface LabView, Figura 20, da National Instruments. Figura 19 - Software para inserir a rota. O software é de fácil uso. Basta inserir o Código do Ônibus e conectar o GPS a ele. Com isso basta fazer a rota que será inclusa no sistema. Esse programa gera um arquivo padrão TXT de acordo com o protocolo de mensagens desenvolvido e faz aquisição de pontos a cada quatro segundos. A Figura 21 mostra o traçado da rota configurada: 40 Figura 20 - Rota configurada para testes. Com esses pontos em mãos, configura-se a rota no servidor e carrega as informações adquiridas e, assim, estará cadastrando uma nova rota no servidor. Maneira desenvolvida para facilitar as operações de acréscimo de pontos, evitando operação manual ponto a ponto. 41 CONCLUSÃO: O problema de congestionamento nas cidades é grande, campanhas de incentivo ao uso do transporte coletivo não motivam a população que possui automóvel devido a atrasos e horários incertos. Por esse motivo o projeto vem para auxiliar no incentivo ao uso do transporte público, mostrando tempo estimado para a chegada do próximo ônibus. A solução proposta além do objetivo principal traz consigo uma gama de possibilidades que geram benefícios tanto aos usuários, proprietários da frota e agência regulamentadora (como exemplo a URBS de Curitiba Paraná). Para cumprir esse objetivo, são utilizados módulos GPS, GPRS e microcontroladores. A função do GPS é informar a hora exata em todo o sistema, posição do ônibus e velocidade do mesmo. O módulo GPRS faz a comunicação do sistema, interligando os ônibus à central e estações tubos ou terminais. A junção GPS/GPRS/Microcontrolador possibilita muitos outros projetos. Neste projeto é uma solução relativamente barata e seu funcionamento não depende de custos de implementação de redes ou sensores pela cidade, facilitando o uso e operabilidade. A viabilidade financeira do projeto é real e com os custos na comunicação via rede de celular cada vez mais baixa, o sistema apresenta uma relação custo/benefício muito alta. 42 REFERÊNCIAS BIBLIOGRÁFICAS: [1] Fernandes, Carlo Alberto Gonzáles - Tecnologia GPRS; Monografia (Especialização em Telecomunicações) - Pontifícia Universidade Católica do Paraná, 2003. [2] Souza, David José de - Desbravando o PIC; São Paulo: Érica, 2000. [3] Instituto Curitiba de Informática e Secretaria Municipal da Comunicação Social – Prefeitura Municipal de Curitiba - Consultado na Internet em 18/04/207 http://www.curitiba.pr.gov.br/pmc/a_cidade/Solucoes/Transporte/index.html. [4] GASPAR, J. J. (N/D) - Global Positioning System - G.P.S. - Dep. Florestal, Escola Superior Agrária de Coimbra. [5] Axmark, David e Widenius, Michael – Manual de Referencia do MySQL 4.1 Equipe de Documentação da MySQL - http://www.mysql.com/documentation/ [6] Almeida, Rondinely S. de – MySQL Básico - Consultado na Internet em 12/08/2007 - http://www.hospedia.com.br/artigos/5/MySQL.html [7] BCD, Dicas – O portal dos Programadores C++ Builder - Consultado na Internet em 27/10/2007 - http://www.dicasbcb.com.br [8] System Designer Reference Manual, Lassen (TM) LP GPS – Trimble Navigation Limited. [9] Pereira, Fábio. Microcontroladores PIC - Programação em C; Editora Érica, 2003, 6ª Edição. 43