Monitoramento e Controle de Horários de Veículos do
Propaganda
UNIVERSIDADE POSITIVO NÚCLEO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE ENGENHARIA DA COMPUTAÇÃO FELIPE LOPES ESCOTE THALES AUGUSTO PORTO DA SILVA Desenvolvimento de uma Rede Inteligente de Transporte Urbano – Monitoramento e Controle de Horários de Veículos do Transporte Coletivo Trabalho de Conclusão de Curso. Prof. Alessandro Brawerman Orientador Curitiba, dezembro de 2010. UNIVERSIDADE POSITIVO Reitor: Prof. José Pio Martins Vice-Reitor: Prof. Arno Antônio Gnoatto Pró-Reitor de Graduação: Prof. Renato Casagrande Diretor do Núcleo de Ciências Exatas e Tecnológicas: Prof. Marcos José Tozzi Coordenador do Curso de Engenharia da Computação: Prof. Edson Pedro Ferlin AGRADECIMENTOS Aos nossos pais e familiares, por terem acreditado em nós e nos apoiado durante todos esses anos de graduação, para que pudéssemos chegar até o fim do curso. Aos nossos amigos, pela paciência em tolerar nossas ausências em épocas difíceis, como finais de bimestres e semanas de provas. Aos amigos de trabalho que conquistamos durante os estágios e empregos, que muito nos ensinaram, colaborando em nossa evolução profissional e intelectual. Aos colegas do curso, que nos proporcionaram momentos cooperação e descontração, sendo muito importantes para o baixo nível de alteração em nossa sanidade mental durante esses anos de loucura. Aos professores, pelo empenho e paciência nas aulas, pelos conhecimentos a nós fornecidos, pela dedicação, contribuição e preocupação com a nossa formação acadêmica e pessoal. Aos funcionários e colaboradores da Universidade Positivo, pelo respeito, ética e comprometimento na realização das atividades e no relacionamento com os alunos, em especial, aos funcionários e estagiários do laboratório de altodesempenho, por, diversas vezes, irem de sala em sala procurar proprietários de pen-drives esquecidos nos laboratórios do curso. À Universidade Positivo, pela preocupação com a qualidade do ensino e pela excelente infraestrutura que nos foi disponibilizada, possibilitando um ótimo aprendizado. SUMÁRIO LISTA DE ABREVIATURAS E SIGLAS .................................................... 5 LISTA DE FIGURAS ..................................................................................... 7 LISTA DE TABELAS ..................................................................................... 9 RESUMO ....................................................................................................... 10 ABSTRACT ................................................................................................... 11 1. INTRODUÇÃO.................................................................................... 12 2. FUNDAMENTAÇÃO TEÓRICA ...................................................... 14 2.1 Sistemas de Transporte Inteligente ............................................................. 14 2.2 Tecnologias de transmissão de dados em redes de telefonia móvel ......... 15 2.3 Identificação por Radiofrequência ............................................................. 16 2.4 Banco de dados ............................................................................................. 18 3. TRABALHOS RELACIONADOS .................................................... 19 4. ESPECIFICAÇÃO DO PROJETO ................................................... 20 4.1 Características do Projeto de Hardware .................................................... 21 4.1.1 4.1.2 4.1.3 4.1.4 Leitores RFID ................................................................................................................... 21 Etiquetas RFID ................................................................................................................. 22 Terminal Java™ TC65i.................................................................................................... 23 Painel Informativo ............................................................................................................ 26 4.2 Requisitos de Hardware ............................................................................... 28 4.3 Arquitetura ................................................................................................... 28 4.3.1 4.3.2 Descritivo do Hardware ................................................................................................... 29 Descritivo do Software ...................................................................................................... 31 4.4 Algoritmo de cálculo do tempo de espera ................................................... 35 4.5 Recursos necessários .................................................................................... 35 5 VALIDAÇÃO E RESULTADOS........................................................... 37 6 CONCLUSÃO.......................................................................................... 43 REFERÊNCIAS ............................................................................................ 44 ANEXO I - ARTIGO .................................................................................... 46 ANEXO II – CÓDIGOS FONTE................................................................. 54 LISTA DE ABREVIATURAS E SIGLAS A Ampere AD Analógico-Digital ADSL Asymmetric Digital Subscriber Line Auto-ID Identificação Automática b Bit B Byte BD Banco de Dados CMOS Complementary Metal Oxide Semiconductors DA Digital-Analógico DNS Domain Name Service CPU Central Processing Unit FTP File Transfer Protocol G Giga GPIO General Purpose Input/Output GPRS General Packet Radio Service GSM Global System for Mobile Communications Hz Hertz HSDPA High-Speed Downlink Packet Access Id Identificador IMP-NG Information Module Profile - Next Generation IP Internet Protocol ITS Intelligent Transportation Systems JSR Java™ Specification Request K Kilo Km Quilômetro LED Light-Emitting Diode M Mega m Mili MIDP Mobile Information Device Profile RFID Radio-Frequency Identification s Segundo SGBD Sistema Gerenciador de Banco de Dados SINIAV Sistema Nacional de Identificação Automática de Veículos TCP Transmission Control Protocol TTL Transistor-Transistor Logic UML Unified Modeling Language V Volt VCC Volts Corrente Contínua WWW World Wide Web 2G Segunda Geração 3G Terceira Geração LISTA DE FIGURAS Figura 1.1 – Exemplo de utilização do RFID. ...................................................... 13 Figura 2.1 - Leitor e transponder principais componentes dos sistemas RFID. .. 17 Figura 4.1 – Visão geral do Sistema ..................................................................... 20 Figura 4.2 – Esquemático do circuito do RFID.................................................... 22 Figura 4.3 – Etiquetas RFID em formato de disco. .............................................. 23 Figura 4.4 – Módulo Cinterion TC65i. ................................................................. 24 Figura 4.5 – Terminal Java™ TC65i .................................................................... 24 Figura 4.6 – Diagrama em blocos de aplicação exemplo. .................................... 25 Figura 4.7 – Painel Informativo............................................................................ 26 Figura 4.8 – Esquemático do Painel. .................................................................... 27 Figura 4.9 – Circuito do Painel em placa de circuito impresso. ........................... 27 Figura 4.10 – Arquitetura do Sistema................................................................... 29 Figura 4.11 Diagrama de hardware para registro da passagem ........................... 30 Figura 4.12 Diagrama de hardware para obtenção de estimativa. ....................... 30 Figura 4.13 Fluxograma de Firmware.................................................................. 31 Figura 4.14: Fluxograma de software para registro de passagens ........................ 32 Figura 4.15: Fluxograma de software para fornecimento de estimativas ............ 33 Figura 4.16 – Diagrama entidade relacionamento................................................ 34 Figura 5.1 - Emulador Cliente .............................................................................. 37 Figura 5.2 – Disparador de instâncias do emulador. ............................................ 38 Figura 5.3- Estrutura utilizada para os testes. ...................................................... 39 Figura 5.4 – Gráfico de Utilização da CPU.......................................................... 40 Figura 5.5 – Gráfico do tempo necessário para registro....................................... 41 LISTA DE TABELAS Tabela 4.1 – Resumo dos Custos .......................................................................... 36 Tabela 5.1 – Teste de Desempenho e Precisão .................................................... 40 Tabela 5.2 – Precisão de acordo com a tecnologia de comunicação. ................... 42 RESUMO O projeto consiste no desenvolvimento de um sistema, para uso em transporte público, que identifica a passagem de determinados veículos em pontos de embarque/desembarque de passageiros. Com o uso de etiquetas eletrônicas nos veículos e leitores nos pontos de parada, as informações são capturadas e centralizadas em um servidor que armazena e processa os dados recebidos, permitindo que as estações acessem informações sobre a(s) linha(s). Os passageiros recebem por meio de um painel, informações quanto à posição atual do próximo veículo, bem como o tempo estimado para o próximo embarque naquele ponto. Devido à falta de uma rede de comunicação na maioria dos pontos de parada, o sistema realiza a comunicação por meio de modem GPRS, integrado ao terminal da aplicação embarcada. De acordo com a empresa gestora do sistema de transporte da cidade de São Paulo (SPTRANS, 2009), nas ultimas décadas, o controle e monitoração dos veículos de transporte coletivo resumem-se apenas na fiscalização do correto cumprimento das viagens previstas em contrato. Essa gestão passiva do sistema não permite a disponibilização imediata das informações em benefício direto dos passageiros, pois muitas vezes são registradas por fiscais, motoristas e cobradores, em sistemas não informatizados. O objetivo principal desse projeto é criar uma solução de baixo custo e de fácil adaptação, para registrar os horários das passagens dos veículos em seus diversos pontos de parada, a partir da captura de sinais RFID emitidos por etiquetas instaladas nos veículos. Com a automação dos registros podemos melhorar o controle gerencial das frotas pelas operadoras e pelos órgãos que administram o transporte coletivo. Como objetivo secundário, é possível utilizar os registros para calcular uma estimativa de chegada para os veículos, reduzindo o estresse causado pelo desconhecimento do período de espera, aumentando a comodidade do passageiro. Palavras-chave: RFID, GPRS, Java™, transporte urbano, transporte coletivo, ônibus, telefonia móvel, celular, rede de comunicação. ABSTRACT The whole project consists in develop a system, for public transportation, that identify the vehicle when it pass through the bus stop or station. Installing sensors at the vehicles and reader equipment in the bus stop/station, the received information are sent to a server that store and process the received data, and provide to passengers, in a dashboard at the bus stop, useful informs about the system as an actual position of the bus in the line and estimating time for the next bus. Because the lack of communication system installed in the most part of stations, it will be necessary to use a GPRS modem, integrated with the embedded application in the terminal. According SP-TRANS, the company that manage the public transportation system in São Paulo city, in the last ten years the only way used for control and monitoring vehicles, consist in observation of the correct time in the stations. The information is passed to a supervisor or manager by the drivers or company agents normally in paper or another non automatized method. There is no way to provide the information immediately to passengers for their use. The main purpose of the project is create a low cost and easy solution to registry the exactly time of the passage of the bus through the station using installed sensors and readers in the vehicles and bus stops. The information comes from devices via RFID to a server. With the automatic data processing it will be possible for the company and passengers to estimate time, control and avoid the problems caused by the traffic, and manage a number of situations that causes delays and/or stress. Keywords: RFID, GPRS, Java™, dashboard, bus, mobile communication network, public transportation system, mobile phone. 12 1. INTRODUÇÃO O projeto em questão tem a proposta de desenvolver um Sistema para monitorar a passagem de um veículo em seus pontos de embarque/desembarque e gerar uma estimativa da chegada deste nos próximos pontos a serem percorridos. Atualmente, na maioria das cidades, existe a necessidade de fiscalização presencial da pontualidade dos veículos e faltam informações quanto à localização e previsão de suas chegadas a um determinado ponto. O objetivo primário do sistema é facilitar o controle gerencial da operadora quanto aos horários e tempos totais decorridos na viagem, a partir da captura de sinais provindos do veículo ao passar pelos pontos de parada. Como objetivos secundários apresentam-se: • Estimar um tempo para a chegada de um veículo a um determinado ponto de espera, com base nos registros armazenados. • Fornecimento de informações aos usuários, quanto à passagem do veículo por pontos de parada. • Construção de um painel simples e de fácil entendimento para fornecer as informações recebidas sobre o próximo ônibus ao passageiro; • Redução do estresse causado pelo desconhecimento do período de espera para embarque, aumentando assim a comodidade ao passageiro; O projeto é composto por um conjunto de hardware e software. O hardware contém o painel informativo, o terminal Java™ TC65i, o leitor RFID e as etiquetas RFID. O software é desenvolvido em linguagem Java™, e é implementado no servidor e nos terminais Java™ TC65i. Nos terminais, sua função é monitorar a passagem dos veículos e registrá-las no servidor, bem como solicitar ao servidor informações sobre o próximo veículo e enviá-las ao painel. No servidor, o software armazena informações em Banco de Dados e realiza os cálculos das estimativas, trocando essas informações com os terminais. O RFID, como se pode ver na Figura 1.1, é utilizado para detectar e identificar o veículo que passa pelo ponto de ônibus, utilizando sinais de radiofrequência. Nesse artigo, alguns termos são utilizados com um significado específico. Assim, o termo Sistema, sem maiores qualificações, refere-se ao Sistema de Monitoramento e Controle de Horários de Veículos do Transporte Coletivo. O termo Terminal refere-se ao Terminal Java™ TC65i. O termo Pontos refere-se aos pontos de embarque e desembarque de passageiros. 13 Figura 1.1 – Exemplo de utilização do RFID. A ênfase do Sistema em questão é oferecer, às empresas e aos órgãos que administram o transporte urbano, um sistema informatizado de registro e fornecimento de dados precisos acerca dos horários e pontualidade dos veículos das frotas, e que permita emissão de relatórios, estatísticas e consultas em tempo real. O restante deste trabalho está dividido da seguinte forma: o Capítulo 2 apresenta noções importantes para a compreensão do projeto, o Capítulo 3 apresenta alguns trabalhos relacionados utilizados como inspiração e base de pesquisa para a execução do projeto, o Capítulo 4 apresenta a especificação do projeto descrevendo as ferramentas utilizadas para o desenvolvimento tanto do hardware quanto do software, o Capítulo 5 apresenta a validação e resultados do projeto com o objetivo de mostrar seu desempenho e, por fim, o Capítulo 6 apresenta a conclusão sobre o projeto, descrevendo o que foi obtido com este trabalho e possíveis melhorias a serem implementadas. 14 2. FUNDAMENTAÇÃO TEÓRICA Neste capítulo é apresentada a teoria necessária para a compreensão e entendimento do projeto. São abordados os conceitos e recursos tecnológicos necessários para o desenvolvimento e funcionamento do projeto. 2.1 Sistemas de Transporte Inteligente Sistemas de Transporte Inteligente, ou em inglês, Intelligent Transportation Systems (ITS), é a denominação empregada na utilização de tecnologias avançadas, que auxiliem na melhoria e eficiência no controle e gerenciamento dos sistemas de transporte, reduzindo os congestionamentos e a poluição e melhorando a segurança (DRANE/RIZOS, 1998). Os ITS elevam a mobilidade, segurança e produtividade através da integração de tecnologias avançadas de comunicação empregadas na infraestrutura de transportes e nos veículos (US DOT, 2005). A denominação genérica de ITS é empregada para designar um conjunto de tecnologias oriundas das aplicações de telemática nos veículos e nos sistemas de transportes (FERRAZ E TORRES, 2004). Segundo os autores, os exemplos mais comuns de ITS no transporte coletivo urbano são: “rastreamento de veículo por satélite, sistema de bilhetagem inteligente no transporte coletivo urbano, registro da passagem dos coletivos por locais predeterminados, comunicação em tempo real com os usuários, utilizando dizeres em painéis digitais e avisos sonoros em alto-falantes, etc.”. Observam-se nos conceitos apresentados acima, que a implantação de tecnologias de telemática e comunicação no transporte coletivo, por meio de sistemas ITS, traz grandes benefícios aos passageiros e empresas gestoras, por permitir fornecimento de informações em tempo real, e um maior controle da frota, aumentando a eficiência e qualidade dos serviços prestados. O Sistema de Monitoramento e Controle de Horários de Veículos do Transporte Coletivo, proposto nesse projeto, classifica-se como ITS, já que possibilita o registro dos horários de passagem pelos Pontos em tempo real, de forma centralizada, utilizando para isso, a tecnologia de comunicação móvel via internet denominada GPRS (General Packet Radio Service). 15 2.2 Tecnologias de transmissão de dados em redes de telefonia móvel As tecnologias de transmissão de dados em redes de telefonia móvel são elementos essenciais para os ITS, pois permitem a comunicação entre os agentes envolvidos no transporte coletivo, quando é inviável ou impossível utilizar uma infraestrutura cabeada para esse fim. O GSM (Global System for Mobile Communications), visto como um sistema de telefonia de segunda geração (2G) é o padrão de telefonia celular mais popular mundo. Até o final dos anos 90, a difusão da Internet fez a indústria sem fio olhar a transmissão de dados móveis como uma oportunidade de crescimento. Dessa forma, a indústria assumiu a tarefa de definição de sistemas de terceira geração (3G), baseado em dados por pacotes (HALONEN/ROMERO/MELERO, 2003). Com o atraso no lançamento dos sistemas 3G em todo o mundo, foi necessário o desenvolvimento de um serviço intermediário, voltado para transmissão de dados, para o GSM. Esse serviço precisaria atingir certos objetos: Permitir acesso a redes empresariais e a Internet; fornecer velocidade relativamente alta; Acessibilidade contínua para voz e dados; Acesso flexível para otimizar o uso da rede, ou seja, muitos usuários com baixas velocidades, poucos usuários com altas velocidades. O Serviço Geral de Pacotes por Rádio (GPRS) foi o único serviço a atingir todos esses objetivos, e foi concebido como uma extensão ao GSM para a transição entre os sistemas 2G e 3G (SANDERS/THORENS/REISKY/RULIK/ DEYLITZ, 2003). As redes GPRS foram desenvolvidas para suportar os serviços de dados, pois surgiram com o propósito de transmissão por comutação de pacotes, diferentemente das GSM, que utiliza comutação por circuito para voz e dados. No GPRS, os dados são divididos em pedaços (pacotes) e ao chegarem ao receptor são agrupados novamente (JESZENSKY, 2004). Quando o GPRS quebra os dados em pacotes, não bloqueia os recursos da rede, liberando-os para outras transmissões correntes e, portanto, não necessita que a ligação seja cobrada por tempo, mas pelos bits transmitidos. O GPRS provê transparência de suporte ao TCP (Transmission Control Protocol)/IP (Internet Protocol) e isso permite sua integração com a Internet. Protocolo de Internet (IP) é um protocolo usado entre duas máquinas em rede para encaminhamento dos dados. Assim, por meio do GPRS, aplicações do tipo WWW (World Wide Web), FTP (File Transfer Protocol) e e-mail podem ser atendidas por esse serviço (PEREIRA/GUEDES, 2004). Por ser um serviço que agrega funcionalidades e vantagens ao padrão GSM, que é 2G, e também por anteceder aos sistemas 3G, o GPRS é conhecido como geração 2,5. Os sistemas 3G, apesar de estarem se popularizando, ainda carece de cobertura de rede, seus módulos para sistemas embarcados ainda tem custo elevado, e, devido a grande utilização por usuários domésticos, podem ser instáveis, tornando-se inviável para o projeto proposto neste trabalho. 16 O GPRS hoje é largamente utilizado para rastreamento veicular, em máquinas de pagamentos eletrônicos via cartão bancário, em sistemas de segurança e nos sistemas ITS em geral. Neste projeto, é utilizado o GPRS para a comunicação via Internet entre os terminais, localizados nos diversos Pontos, e o servidor central. A tecnologia é escolhida por atender as necessidades de tráfego de dados do sistema, no que se refere à velocidade e ao tempo de resposta, e por atualmente, ter um custo de implantação muito menor que os sistemas 3G. Além disso, o GPRS está disponível em toda a rede GSM das principais operadoras de telefonia móvel no Brasil. São utilizados dois cartões SIM (Subscriber Identity Module) de operadoras diferentes em cada slot do módulo, de forma a oferecer redundância no acesso a Internet. 2.3 Identificação por Radiofrequência Nos últimos anos, procedimentos de identificação automática (Auto-ID) se tornaram muito populares nas empresas de serviços, logística de compra e distribuição, empresas de manufatura e na indústria em geral. Os procedimentos de identificação automática existem para fornecer informações sobre pessoas, animais, mercadorias e produtos em trânsito (FINKENZELLER, 2003). As etiquetas de código de barras causaram uma revolução nos sistemas de identificação nos ultimos anos, e está se tornando obsoleta para um número crescente de casos. Codigos de barras são extremamente baratos, mas a sua grande desvantagem é a baixa capacidade de armazenamento e ao fato de que eles não podem ser reprogramados (FINKENZELLER, 2003). A solução tecnicamente ideal seria o armazenamento de dados em um chip de silício. A forma mais comum de transporte de dados em meio eletrônico presente diariamente em nosas vidas é o cartão inteligente baseado em campo de contato galvânico (cartão telefônico). No entanto, o contato mecânico usado nesses tipos de cartões muitas vezes é impraticável. A transferência de dados sem contato entre o dispositivo de transporte de dados e seu leitor é muito mais flexível. No caso ideal, a energia necessária para operar o dispositivo eletrônico de transporte de dados, também seria transferida a partir do leitor. Por causa dos procedimentos utilizados para a transferência de energia e de dados, sistemas de identificação sem contato são chamados de sistemas RFID (Radio Frequency Identification) (FINKENZELLER, 2003). Os sistemas RFID são semelhantes ao cartão inteligente descrito acima. Os dados são armazenados em um dispositivo eletrônico de transporte de dados: o transponder. No entanto, o fornecimento de energia e o intercâmbio de dados entre o dispositivo de transporte de dados e o leitor são alcançados sem a utilização de contatos galvânicos, e sim utilizando campos magnéticos ou eletromagnéticos (FINKENZELLER, 2003). 17 Na figura 2.1, têm-se os dois componentes que constituem o RFID: • Transponder ou etiqueta: que está localizado no objeto a ser indentificado; • Leitor: Pode ser apenas de leitura, ou de leitura e gravação do dispositivo. O Leitor normalmente possui um módulo de radiofrequência (transmissor e receptor), uma unidade de controle e uma antena. A maioria possui também, uma interface de comunicação para o encaminhamento dos dados recebidos. O Transponder que representa o dispositivo de transporte de dados de um sistema de RFID, normalmente constituída por uma antena e um microchip eletrônico (FINKENZELLER, 2003). Figura 2.1 - Leitor e transponder principais componentes dos sistemas RFID. Os transponders, ou etiquetas RFID, possuem identificação própria, que pode ser predefinida ou personalizável e são capazes de responder a sinais de rádio enviados por uma base emissora. As etiquetas RFID são classificadas em ativas, semi-passivas e passivas. As ativas utilizam baterias ou fonte de alimentação externa e possuem alcance superior a 5 metros. As semi-passivas utilizam tanto a bateria ou fonte de alimentação quanto o campo magnético gerado pelo leitor para gerar corrente elétrica e possuem alcance de 0,5 a 5 metros. As passivas retiram a corrente elétrica necessária para o funcionamento totalmente do campo magnético gerado pelo leitor e possui alcance de até 50 centímetros. No Brasil, a identificação de veículos por RFID já é utilizado para pagamento de pedágios e estacionamentos. Em breve, com a implantação do SINIAV (Sistema Nacional de Identificação Automática de Veículos), seu uso será obrigatório em todos os veículos (DENATRAN, 2010). Neste projeto, utilizamos a tecnologia RFID para a identificação dos veículos, quando os mesmos passam pelos pontos de embarque/desembarque. 18 2.4 Banco de dados Banco de dados é uma coleção de dados relacionados que existe por um longo período de tempo para atender às necessidades de múltiplos usuários dentro de uma ou múltiplas organizações (ALBUQUERQUE, 2000) Os bancos de dados podem ser classificados em: relacional; hierárquico e rede. O modelo relacional usa um conjunto de tabelas para representar tanto os dados quanto a relação entre eles. Um banco de dados hierárquico compõe-se de um conjunto ordenado de árvores, mais precisamente de um conjunto ordenado de ocorrências múltiplas de um tipo único de árvore. Um banco de dados em rede consiste em uma coleção de registros que são concatenados uns aos outros por meio de ligações (ELMASRI/NAVATHE, 2005). Adiciona-se aos tipos citados, o banco de dados orientado a objetos e objetorelacional. O modelo de orientação a objeto está baseado no encapsulamento de código e dados em uma única entidade chamada objeto (SILVA, 2003). O modelo objeto-relacional trata-se de um modelo híbrido, com uma estrutura relacional, adicionando alguns conceitos de orientação a objetos, tais como herança de tabelas, de tipos e a possibilidade de criação de tipos complexos de dados. Um modelo de dados define como os dados são armazenados, organizados e acessados. Existem vários sistemas que realizam o gerenciamento de banco de dados, que são chamados de SGBDs (Sistemas Gerenciadores de Banco de Dados). O SGBD é um software de caráter geral para a manipulação eficiente de grandes coleções de informações estruturadas e armazenadas de uma forma consistente e integrada. Tais sistemas incluem módulos para consulta, atualização e ainda as interfaces entre o sistema e o usuário. O SGBD é constituído por um conjunto de dados associados a um conjunto de programas para acesso a esses dados (SILBERSCHATZ, 2006). No sistema aqui proposto nesse trabalho, utiliza banco de dados para armazenamento das informações dos Pontos, veículos e linhas, para registro dos horários de passagens e para realização de cálculos de estimativas. É utilizado banco de dados com modelo relacional, utilizando o SGDB PostgreSQL. 19 3. TRABALHOS RELACIONADOS Esse capítulo tem como objetivo relatar e exemplificar os trabalhos relacionados que foram usados como base para a execução do projeto desenvolvido. A similaridade que pode ser encontrada nesses trabalhos é a de utilizar-se de tecnologias de monitoramento para controle de trafego, e transmissão de dados via GPRS/GSM. O SOMArt (Sistema de Ônibus Monitorado Automaticamente em Tempo Real), desenvolvido para o sistema de transporte público de Porto Alegre, é um sistema para monitoramento automático dos veículos ao longo do itinerário. O monitoramento é feito através da passagem dos veículos por antenas fixas, espalhadas na malha viária, as quais capturam informações específicas de cada veículo. Estas informações estão gravadas em etiqueta eletrônica, fixadas nos chassis de cada veículo, que são lidas e transmitidas pelas antenas. O SOMArt utiliza 48 estações fixas espalhadas pela cidade de Porto Alegre, que registram as passagens e, a cada 3 minutos, transmites os registros via GPRS para o sistema SOMA (MARIA LADEIRA/FERNANDO MICHEL/SÉRGIO PAVANATTO, 2009). No Sistema proposto neste trabalho, as estações de monitoramento estão localizadas nos pontos de parada, permitindo o uso da mesma estrutura para interação com os passageiros, como por exemplo, o uso de painéis informativos. Por outro lado, necessita-se de um número muito maior de estações. O SISTEMA PONTUAL é desenvolvido pela empresa Geocontrol, especialmente para a Gestão dos transportes públicos, e traz informações precisas e seguras de toda a frota de ônibus da cidade. Com ele, é possível acompanhar todo o sistema do transporte público em tempo real. A secretaria responsável pela gestão, além de receber relatórios imediatos de toda a movimentação da frota, poderá também, aplicar as correções e medidas necessárias. Com isso, se alcança uma interação muito maior com o sistema de transporte e o usuário poderá usufruir de mais segurança, qualidade e pontualidade (GEOCONTROL, 2010). O Sistema da Geocontrol, assim como a maioria dos sistemas utilizados para rastreamento da frota, utiliza o GPS ou Triangulação de Antenas GSM para o posicionamento do veículo e comunicação GPRS para transmitir essas coordenadas para o sistema de gerenciamento. 20 4. ESPECIFICAÇÃO DO PROJETO O Sistema de Monitoramento e Controle de Horários de Veículos do Transporte Coletivo descobre o momento da passagem dos veículos em seus pontos de parada ao longo de sua rota, e com isso, estabelece uma previsão de chegada do próximo veículo, para cada um dos pontos de embarque. Figura 4.1 – Visão geral do Sistema 21 Na Figura 4.1 têm-se a visão geral do Sistema. A descoberta de tempo de passagem é feita com o uso de etiquetas, instaladas nos veículos, e leitores, instados nos pontos de parada. Ao passar por um ponto de parada, o Módulo inicia um processo de comunicação via GPRS, onde é informado ao servidor de aplicação que determinado veículo passou por aquele local naquele momento. O servidor de aplicação recebe os dados, e realiza o registro no Banco de Dados. Com essa centralização, os registros podem ser utilizados para emissão de relatórios, acompanhamento da frota, controle de pontualidade e consultas pontuais. A base de dados fica armazenada no mesmo servidor de aplicação ou em outro servidor que esteja, de preferência, na mesma rede interna. Em paralelo, o Módulo periodicamente faz uma requisição de estimativa de tempo de chegada do próximo veículo, de uma determinada linha, naquele ponto. Assim, inicia-se outro processo de comunicação via GPRS. O servidor recebe a requisição com os dados do ponto e linha, processa as informações, realizando o cálculo, e o repassa ao requerente. Ao receber a resposta com o tempo estimado para a chegada do próximo veículo, o Módulo disponibiliza essa estimativa no painel, para a visualização pelos passageiros. 4.1 Características do Projeto de Hardware O projeto é composto por um conjunto de dispositivos eletrônicos que se comunicam por meio de vários protocolos. As próximas seções detalham o funcionamento de cada um desses dispositivos. 4.1.1 Leitores RFID Para o protótipo, são utilizados os leitores RFID Innovations ID-20. Trata-se de um leitor para etiquetas passivas, de curto alcance, com frequência de operação de 125 kHz, para leitura de cartões inteligentes ou etiquetas RFID compatíveis com o formato EM4001. O leitor citado acima possui saída de dados nos formatos Wiegand 26bit, Magnet Emulation e ASCII. O sistema em questão utiliza o formato ASCII, pois este pode ser convertido para o padrão RS-232, e o terminal possui bibliotecas e métodos que facilitam a operação com esse tipo de padrão. 22 Figura 4.2 – Esquemático do circuito do RFID. Como é visto na Figura 4.1, o componente leitor RFID precisa ser conectado a circuito integrado MAX232, para converter os dados ASCII, que são enviados a nível TTL (Transistor-Transistor Logic) / CMOS (Complementary Metal Oxide Semiconductors), para o nível RS-232. Os leitores RFID ficam estrategicamente posicionados nos pontos de parada, para detectar a presença dos veículos nas proximidades. 4.1.2 Etiquetas RFID São utilizadas etiquetas RFID Akiyama CP/10, com chip GK4001, para a identificação dos veículos. Trata-se de etiquetas passivas com alcance máximo de 10 cm. Esse alcance é o suficiente para o desenvolvimento do protótipo, no entanto, as etiquetas ativas, que possuem alimentação própria, possuem alcance superior a 5 metros. 23 Figura 4.3 – Etiquetas RFID em formato de disco. Como é visto na Figura 4.2, as etiquetas utilizadas possuem as bobinas nas bordas, em forma de disco, com o chip próximo ao centro. Possuem 3 cm de diâmetro e são adesivas. 4.1.3 Terminal Java™ TC65i O Terminal Java™ TC65i é um produto nacional produzido pela DuoDigit, que utiliza a tecnologia do módulo Cinterion TC65i. O módulo Cinterion TC65i, ilustrado na Figura 4.3, possui uma plataforma aberta, de alta performance, com uma poderosa plataforma Java™. A Java™ Virtual Machine™ é executada em hardware embarcado, com o processador ARM9 e memória integrada. A grande vantagem do módulo TC65i, é a combinação da plataforma Java™ e processador, integrado a tecnologia GPRS, com pilha TCP/IP sobre comandos AT(attention), e uma série de interfaces industriais, tais como SPI, barramento I²C, conversor AD (Analógico-Digital) e DA (Digital-Analógico) e GPIOs (General Purpose Input/Output). 24 Figura 4.4 – Módulo Cinterion TC65i. A plataforma Java™ integrada ao módulo TC65i é a JSR(Java™ Specification Request)-228, também conhecida como IMP-NG(Information Module Profile - Next Generation). Essa plataforma é muito parecida com a MIDP (Mobile Information Device Profile) 2.0, porém, não possui o pacote lcdui, pois não permite interface gráfica com o usuário. A plataforma Java™ do módulo, inclui uma biblioteca desenvolvida pela Siemens, para acesso aos recursos de hardware. O Terminal Java TC65i possui o módulo TC65i com vários conectores, dispositivos de controle e slots integrados em uma caixa metálica. Como é visto na Figura 4.4, o terminal possui conectores DB-15, DB-9, USB (Universal Serial Bus), Power e Antena GSM, slots para SIM 1 e 2, botão de reset e LEDs indicadores. Figura 4.5 – Terminal Java™ TC65i 25 O conector DB-9 é uma porta padrão RS-232, denominada ASC0. O conector DB-15 é composto por 4 pinos GPIO de saída Open Colector, 4 pinos GPIO de entrada Pull up, 1 pino com conversor AD, 1 pino com conversor AD ou DA (programável), VCC (Volts Corrente Contínua), Terra e saída RS-232 denominada ASC1. Os slots para 2 SIM Cards permitem redundância para acesso a rede GPRS, podendo ser configurado a alternância entre eles em cada reinicialização. O conector USB é utilizado para debug da aplicação Java™, e assim como o ASC0 e ASC1, pode ser configurado para transmitir a saída (system.out) da aplicação Java™ em execução. Figura 4.6 – Diagrama em blocos de aplicação exemplo. Na Figura 4.5, segue um exemplo de aplicação do Terminal TC65i. Rodando um programa Java™ armazenado na memória Flash, o terminal recebe os estados de um dispositivo pela serial ASC1 e envia os dados de monitoramento a uma base com IP fixo através de conexão GPRS. O Terminal Java TC65i é capaz de se comunicar com todo o restante do sistema, pois possui vários recursos de hardware que permitem conexão com vários tipos de dispositivos de automação. Além disso, permite atualização remota do firmware, emissão de avisos sonoros, envio e recebimento de SMS, utilização dos recursos de chamada por voz, sistema de telefonia para pessoas com deficiência auditiva, entre outros. Isso possibilita a inclusão de novas funcionalidades ao sistema, de forma integrada, sem necessidade de troca de equipamentos ou alteração da arquitetura. 26 4.1.4 Painel Informativo É utilizado um Painel próprio, desenvolvido de acordo com os recursos de saída disponibilizados no Terminal e com as necessidades do Projeto proposto. Como ilustra a Figura 4.7, o painel disponibiliza duas informações, o tempo, em minutos, com dois dígitos, e uma sinalização relacionada à posição do veículo, que indica o ponto, caso o veículo esteja parado em algum ponto, ou indica que o veículo está a caminho (>>) do próximo ponto. Figura 4.7 – Painel Informativo A Figura 4.8 detalha os componentes eletrônicos utilizados no Painel. Como o Módulo disponibiliza uma quantidade limitada de pinos de GPIO, é utilizado um protocolo próprio pra transmissão de dados para o Painel. São utilizados 2 shiftand-store bus registers, serialização de 16 bits, sendo 4 bits para o decodificador do primeiro display, outros 4 bits para o decodificador do segundo display, e os próximos 3 bits são enviados a um demultiplexador, que irá acionar o LED relativo a posição ou estado do veículo. Desta forma, 5 bits não são utilizados, e ficam disponíveis para futuras funcionalidades. Com o uso dos componentes acima descritos, e com o auxílio de um circuito contador para controlar o deslocamento e propagação dos bits nos registradores, é possível controlar os 7 segmentos de cada um dos displays, e mais 8 LEDs, com apenas 2 pinos GPIO, sendo um para dados, e outro para clock. 27 Figura 4.8 – Esquemático do Painel. Na Figura 4.9, temos o Painel montado em uma caixa, com os LEDs e displays colocados na mesma posição do trabalho gráfico especificado na Figura 4.7. É utilizado um conector DB-9 para a alimentação do circuito e recebimento dos dados. Figura 4.9 – Circuito do Painel em placa de circuito impresso. 28 4.2 Requisitos de Hardware • Fonte de alimentação externa, 12 VCC para módulo e 5 VCC para Leitor RFID e Painel. • Rede de celular GSM/GPRS disponível para as áreas onde estão os pontos de parada dos veículos das linhas atendidas pelo Sistema; • Servidor conectado a Internet, com 2 (duas) portas de entrada devidamente direcionadas e liberadas no firewall de rede. Requisitos mínimos do equipamento: Processador Pentium III 800MHZ, 512 MB RAM, 20 GB HD; • Serviço de DNS dinâmico ou conexão de Internet com IP Fixo para o servidor. 4.3 Arquitetura O Sistema consiste em servidor de aplicação e Banco de Dados, dispositivos embarcados, módulos RFID e painéis informativo. A Figura 4.10 exemplifica o sistema de comunicação e hardware. O servidor é responsável pelo SGDB e por executar os softwares de registro de passagens e estimativas. O Módulo se comunica com o servidor via Internet, utilizando tecnologia de comunicação móvel GPRS. O mesmo Módulo recebe dados do Leitor RFID via interface serial RS-232, e também envia as informações para o painel informativo, utilizando duas portas GPIO. 29 Figura 4.10 – Arquitetura do Sistema 4.3.1 Descritivo do Hardware Como pode ser visto na Figura 4.11, o registro do veículo é feito assim que a etiqueta localizada no veículo é detectada pelo Leitor RFID. O Leitor se comunica com o Terminal Java™ TC65i por meio de comunicação serial RS232. Ao receber a identificação do veículo, o módulo Java™ realiza conexão via GPRS com o servidor, enviando o código do veículo e do ponto. O servidor recebe os dados, recupera da base também o código da linha e outras informações, e registra a passagem. O processo de exibir a estimativa no painel é iniciado por uma requisição feita pelo Módulo Java™ ao Servidor, realizada periodicamente, com intervalos de 20 segundos entre o fim de uma requisição e o início de outra. A comunicação também ocorre pelo mesmo meio, o GPRS, só que em portas distintas. A resposta dessa requisição pode ser vista na Figura 4.12, onde o servidor processa e envia os dados ao Terminal Java™, que, por sua vez, controla os LEDs e displays do painel, por meio das portas de GPIO. 30 Figura 4.11 Diagrama de hardware para registro da passagem Figura 4.12 Diagrama de hardware para obtenção de estimativa. O Terminal Java™ TC65i possui firmware que executa tanto o registro das passagens quanto a obtenção e disponibilização de estimativa. Conforme Figura 4.13, é criada uma thread assim que o sistema é iniciado. Essa thread irá aguardar o leitor RFID detectar a passagem de um veículo, e assim que isso ocorrer, irá receber o código do veículo, estabelecer uma conexão socket com o servidor, enviando logo em seguida, a identificação referente ao ponto no qual está localizado e a identificação do veículo para registrar sua passagem. Terminado isso, a conexão é encerrada, e o sistema volta a aguardar nova detecção. Paralelamente, o sistema estabelece outra conexão socket com o servidor, por meio de outra porta, que também pode ser vista na Figura 4.13. Nessa conexão, é 31 solicitada a localização e a estimativa do tempo de chegada do próximo veículo. Os dados são enviados ao painel, e, após 20 segundos, o ciclo se repete. Nesse caso, o objetivo é utilizar a mesma conexão para as próximas consultas, entretanto, sempre que o novo ciclo é iniciado, a conectividade é testada, e se houver algum problema, será estabelecida uma nova conexão, e finalizada a antiga. Figura 4.13 Fluxograma de Firmware 4.3.2 Descritivo do Software O Sistema é composto por um software para registro da passagem dos veículos, e outro para cálculo e fornecimento de estimativa de chegada do próximo veículo. Podemos verificar no fluxograma da Figura 4.14, que o software de registro de passagens cria um socket para escutar determinada porta. Assim que recebe uma requisição de conexão, é disparada uma thread, para voltar a escutar a porta 32 novamente. Isso permite que ele acate novas requisições enquanto processa as anteriores. Ao iniciar a thread e estabelecer uma conexão, ele recebe do cliente (Módulo Java) a identificação do ponto e o código identificador do veículo. Esses dados são registrados no banco de dados por meio de SPs (Stored Procedures) no SGDB (Sistema Gerenciador de Banco de Dados), que irá incluir mais dados no registro, como horário e linha. Figura 4.14: Fluxograma de software para registro de passagens O software que fornece as estimativas é ilustrado pela Figura 4.15. Assim como o software de registro de passagens, ele também cria um socket de escuta, e inicia uma nova thread a cada requisição. 33 Figura 4.15: Fluxograma de software para fornecimento de estimativas Após a conexão ser estabelecida, é recebida a identificação do ponto. O sistema irá verificar sua base, e realizar os cálculos, com base em modelos estabelecidos, para determinar a estimativa de chegada do próximo veículo para aquele ponto. Feito isso, as informações são enviadas e a thread fica na espera de uma nova requisição. Sempre que houver uma nova requisição na mesma conexão, será realizado o cálculo e o envio das informações. Se em algum momento a thread ficar na espera por mais de 45 segundos, o sistema entenderá que houve queda na conexão, e a thread será finalizada. 34 O modelo de dados visto na Figura 4.16 é composto pelas tabelas Pontos, Linhas, Veículos e Registros, que são detalhadas abaixo. Pontos: Utilizada para cadastramento dos Pontos. Possui a coluna nome do Ponto e código da linha. Cada registro vincula o Ponto a uma linha. Para vincular o mesmo Ponto a mais uma linha, deve ser criado um novo registro, mantendo o mesmo nome do Ponto. Veículos: Possui a coluna com o código da etiqueta que identifica o veículo, e código da linha. Cada registro vincula o veículo a uma linha. Para vincular o mesmo veículo a mais uma linha, deve ser criado um novo registro, mantendo o mesmo código da etiqueta. Linhas: Possui apenas a coluna que identifica o nome da linha. Registros: Armazena as informações referente a passagem dos veículos nos Pontos, possui a coluna com o código do Ponto, código da linha, código do veículo e data do registro. Além das colunas citadas acima, cada tabela possui uma chave primária numérica sequencial, referente ao código do registro, que é utilizado para o relacionamento entre as tabelas. Figura 4.16 – Diagrama entidade relacionamento. 35 4.4 Algoritmo de cálculo do tempo de espera Para a determinação do tempo estimado de espera para a chegada do próximo veículo ao ponto, foi criado um procedimento na linguagem de programação Transact-SQL, extensão da linguagem SQL, armazenado no Banco de Dados PostgreeSQL. O software servidor inicia o procedimento no servidor de Banco de Dados, enviando os parâmetros da linha e do ponto do qual deseja a estimativa. O servidor de Banco de Dados executa o procedimento e retorna o tempo de espera estimado. A rotina de cálculo leva em consideração o tempo médio que foi necessário, nas ultimas três viagens anteriores à viagem atual, para percorrer entre os três Pontos anteriores. Após o cálculo dessas médias, o sistema calcula o desempenho da viagem atual, em comparação as anteriores, e com isso, realiza a estimativa de tempo necessário para viagem entre o ponto em questão e o ponto anterior a ele. O tempo estimado é subtraído do tempo já decorrido após a passagem pelo ultimo ponto, e após isso, é retornado ao software servidor. 4.5 Recursos necessários O desenvolvimento do projeto necessita de espaço físico, recursos de laboratório, licenças de software, orientação técnica, entre outros. Os recursos principais, como laboratórios e licenças de softwares são disponibilizados pela Universidade Positivo. Visando estimar o custo total do projeto, estes itens serão listados na Tabela 4.1. A Tabela 4.1 é uma estimativa dos custos do projeto, que inclui, além dos itens citados acima, componentes e recursos eletrônicos, comunicação, material de escritório e impressão. Dentre os equipamentos, o custo mais relevante é referente ao Terminal TC65i, que é o item principal para o desenvolvimento do projeto. 36 Tabela 4.1 – Resumo dos Custos Descritivo Quant. Unid. Valor Unit Valor Total Mão de Obra Coordenador do Curso 80 hora R$ 110,00 R$ 8.800,00 Professor Orientador 160 hora R$ 65,00 R$ 10.400,00 Direta 720 hora R$ 30,00 R$ 21.600,00 Subtotal R$ 40.800,00 Equipamentos e Insumos Laboratório 40 mês R$ 7,00 R$ 280,00 Notebook 1 unidade R$ 1.500,00 R$ 1.500,00 Ferramentas --- --- R$ 540,00 R$ 540,00 Multímetro 1 unidade R$ 30,00 R$ 30,00 Terminal Java TC65i + Acessórios 1 unidade R$ 800,00 R$ 800,00 Frete compras --- --- R$ 25,00 R$ 25,00 Internet Móvel 9 mês R$ 20,00 R$ 180,00 Internet Banda Larga Fixa 9 mês R$ 40,00 R$ 360,00 Componentes eletrônicos diversos --- --- R$ 200,00 R$ 200,00 Subtotal R$ 3.915,00 Documentação Cópias 500 unidade R$ 0,10 R$ 50,00 Encadernação Capa-dura 1 unidade R$ 40,00 R$ 40,00 Encadernação Espiral 3 unidade R$ 3,00 R$ 9,00 Mídia CD/DVD 2 unidade R$ 1,50 R$ 3,00 Subtotal R$ 102,00 Softwares Windows / Project (licença MSDN-AA) Proteus Eclipse / Net Beans / Postgree SQL 9 mês R$ 0,00 R$ 0,00 160 hora R$ 5,70 R$ 912,00 9 mês R$ 0,00 R$ 0,00 Subtotal R$ 912,00 SubTotal R$ 45.729,50 Impostos (37,5%) R$ 17.148,56 Total R$ 62.878,06 37 5 VALIDAÇÃO E RESULTADOS Para validar o Sistema, foi utilizado um emulador desenvolvido em linguagem Java™, com interface gráfica para computador desktop, conforme visto na Figura 5.1, que simula o funcionamento do Painel e o leitor RFID. Os códigos-fonte utilizados no emulador são basicamente os mesmos utilizados no Terminal Java™ TC65i, com exceção da interface gráfica, que não é suportado pelo Terminal. Figura 5.1 - Emulador Cliente No emulador cliente, é possível selecionar os pontos onde são detectadas as passagens dos veículos, ou seja, sempre que um veículo passar pelos pontos selecionados, o processo de registro de passagens é executado. Para ativar ou desativar a detecção, basta clicar nos pontos desejados. Quando botão referente a 38 um determinado Ponto estiver azul, indica que a detecção pelo emulador, daquele ponto, está ativa. É possível determinar a velocidade e código identificador do veículo, além das distâncias entre os pontos. O Emulador também simula o painel, com as estimativas dos tempos para todas as estações. Para iniciar os recursos, basta configurar os parâmetros desejados e iniciar a simulação. Para corrigir algum parâmetro, é necessário parar a simulação, e habilitar a edição dos campos. Têm-se ainda, a opção de utilizar um programa disparador de instâncias do emulador, para execução de testes de esforço, que é mostrado na Figura 5.2. Nele pode-se escolher a quantidade de instâncias paralelas a serem executadas, optando ou não por configurar os parâmetros de forma aleatória e, com isso, possibilitando a conexão automática dessas instâncias e a execução em segundo plano. A opção de gerar relatório permite que seja criado um arquivo de texto, com o tempo levado entre a detecção do sinal do veículo, até o momento de confirmação de gravação, para todos os pedidos de registro. Figura 5.2 – Disparador de instâncias do emulador. Verificar o comportamento do Sistema, simulando uma situação com dezenas de módulos conectados, é importante para avaliar a eficiência da arquitetura e das plataformas utilizadas e bem como o conjunto de hardware utilizado. Os relatórios com os tempos necessários para a comunicação e processamento dos registros, nos permite avaliar a precisão do sistema, no que se refere à exatidão dos horários registrados no banco de dados. Para o tempo de processador, foi utilizado Monitor de Desempenho do Windows 7, que nos fornece uma média de utilização do processador em um intervalo de tempo. 39 Figura 5.3- Estrutura utilizada para os testes. O método e recursos utilizados nos testes são ilustrados na Figura 5.3. É utilizado o módulo, executando a aplicação embarcada, e computadores desktop, executando várias instâncias do simulador do módulo. Tanto o módulo quanto os computadores se comunicaram com o servidor via Internet, sendo que o módulo utiliza comunicação GPRS, aproximadamente 75% das instâncias dos simuladores são conectados com ADSL (Asymmetric Digital Subscriber Line) 2+, e os restantes conectados via tecnologia 3G HSDPA (High-Speed Downlink Packet Access). O Servidor utilizado nos testes também é conectado por ADSL2+ e possui processador de baixo consumo de energia Intel U2700 (1,3GHz), com 3GB de memória RAM. A Tabela 5.1 apresenta os resultados dos testes efetuados. A utilização da CPU (Central Processing Unit) passou de 6%, com 10 clientes, para 10%, com 100 clientes. O atraso na gravação para 100 clientes aumentou 21% em relação ao tempo de atraso para 10 clientes. 40 Tabela 5.1 – Teste de Desempenho e Precisão Clientes % CPU Tempo para registro 10 6% 2,15 segundos 20 7% 2,18 segundos 30 7% 2,29 segundos 40 8% 2,21 segundos 50 8% 2,20 segundos 60 9% 2,24 segundos 70 9% 2,54 segundos 80 9% 2,62 segundos 90 10% 2,58 segundos 100 10% 2,61 segundos Na Figura 5.4 temos um gráfico de utilização da CPU, que ilustra os dados dos testes. Observa-se que, com um aumento em 1000% no número de clientes, o aumento de utilização da CPU foi de 60%. O gráfico segue uma linha vertical com uma pequena inclinação, que mostra o pouco impacto dos clientes na utilização do processador. Utilização CPU 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 10 20 30 40 50 60 70 80 Utilização CPU Figura 5.4 – Gráfico de Utilização da CPU. 90 100 41 Na Figura 5.5, temos a evolução do tempo necessário para o processo de registro. Observa-se que a evolução não é linear, isso se explica pelo fato de existirem outros fatores que atrasam a comunicação entre os equipamentos, como o tráfego das redes das operadoras, interferências, colisão de pacotes, etc.. No entanto, não houve casos em que a variação foi superior a 5 segundos, sendo um atraso totalmente tolerável para esse tipo de Sistema. Tempo para registro 3,00 2,50 2,00 1,50 1,00 0,50 0,00 10 20 30 40 50 60 70 80 90 100 Tempo para registro Figura 5.5 – Gráfico do tempo necessário para registro. Na tabela 5.2, são comparados os atrasos entre os tipos de tecnologias utilizadas para os testes. Nesse quesito, o GPRS ficou muito próximo do 3G HSDPA, com um desempenho de 2% a 8% inferior. Em comparação com o ADSL2+, sua desvantagem foi menor que 1 segundo. Isso mostra que, apesar de ser uma tecnologia mais antiga se comparado ao 3G HSDPA, o GPRS apresenta um ótimo desempenho para aplicações que não dependem de grande tráfego de dados. O ADSL2+ possui desempenho superior devido ao seu meio de transporte ser com cabos, porém, seu custo e dificuldade de manutenção e implantação, não são compensatórios para o Sistema em questão. 42 Tabela 5.2 – Precisão de acordo com a tecnologia de comunicação. Conexão/Tempo 10 Clientes 50 Clientes 100 Clientes ADSL2+ 1,84 1,98 2,48 3G HSDPA 2,70 2,82 2,96 GPRS 2,92 2,97 3,03 O desempenho do Sistema, nos quesitos avaliados acima, ficou acima do esperado, pois mostra que, mesmo com um servidor com recursos de hardware limitados, é possível conectar dezenas de módulos sem perda significativa de desempenho. Para aumentar o desempenho e capacidade do Sistema, pode ser considerado a utilização de um hardware mais robusto e link de Internet via fibra ótica para o servidor. Foram realizadas verificações nas estimativas fornecidas aos passageiros. Os testes verificaram que os cálculos definidos no algoritmo foram capazes de verificar variações na velocidade média dos veículos entre os Pontos, comparálas com as viagens anteriores e, com isso, alterar a previsão. Por ser objetivo secundário desse trabalho, não foi feita uma validação das previsões em um ambiente real, pois isso demandaria muito tempo. 43 6 CONCLUSÃO Este trabalho consiste no desenvolvimento de um Sistema de Registro e Controle da Frota do Transporte Coletivo, para registrar os horários das passagens dos veículos pelos pontos de paradas, tendo como objetivo secundário, fornecer estimativas de chegada dos veículos aos passageiros. É composto por um conjunto de hardware e software. O hardware engloba os leitores e etiquetas RFID, painel informativo e Módulo Java TC65i com comunicação GPRS integrado. O software é dividido em três aplicações, sendo uma no módulo, que interpreta os dados recebidos pelo leitor RFID, e envia informações ao painel, outras duas no servidor, para registro dos dados e fornecimento de estimativas. No final têm-se um sistema completamente automatizado, que realiza todas as ações sem a necessidade de intervenção humana, realizando os registros em tempo real, e, da mesma forma, oferecendo estimativas com base em informações armazenadas em um servidor central. Com este projeto, percebeu-se que a utilização da identificação por rádio frequência pode melhorar o processo de monitoramento do transporte urbano devido o alto grau de automação que ela proporciona, reduzindo custos e erros na fiscalização e aumentando a qualidade do serviço. Nos testes, o Sistema teve desempenho acima do esperado, pois se mostrou bastante eficiente e preciso no registro dos horários das passagens. Com um baixo nível de utilização do processamento do servidor, e baixo atraso no registro das passagens, mesmo utilizando um servidor com recursos de hardware limitados, foi possível conectar dezenas de módulos sem perda significativa de desempenho. O cálculo do tempo estimado foi satisfatório e atendeu as expectativas previstas, porém, necessita de estudos estatísticos para validação e aprimoramento do algoritmo utilizado. Como sugestão para futuros trabalhos, pode-se utilizar Displays de Cristal Líquido (LCD – Liquid Crystal Display) para confecção dos painéis, avisos sonoros, para que a informação possa ser acessível aos deficientes visuais e serviço de consultas via SMS e Web. 44 REFERÊNCIAS ALBUQUERQUE, Fernando. Introdução a Banco de Dados. Brasília: UNB, 2000; ALENCAR, Marcelo Sampaio de. Telefonia Celular Digital. 2. ed. São Paulo: Ética, 2007. DRANE, Chris; RIZOS, Chris. Positioning Systems transportation systems. London: Artech House, 1998. in intelligent ELMASRI, R.; NAVATHE, S. B. Sistemas de Banco de Dados. 4. ed. São Paulo: Pearson, 2005; FERRAZ, Antonio Clovis Pinto; TORRES, Isaac Guilhermo Espinosa. Transporte Público Urbano. 2. ed. São Carlos: Rima, 2004. FINKENZELLER, Klaus. RFID handbook : fundamentals and applications in contactless smart cards and identification. 2. ed. Chichester: John Wiley & Sons Ltd, 2003; GEOCONTROL. Sistema Pontual , Vitória, Abril de 2010. Disponível em: < http://www.geocontrol.com.br/ >. Acesso em Abril de 2010. HALONEN, Timo; ROMERO Javier; MELERO, Juan. GSM, GPRS, and EDGE performance: evolution towards 3G/UMTS. 2. ed. Chichester: John Wiley & Sons Ltd, 2003; JESZENSKY, Paul Jean Etienne. Sistemas Telefônicos. Barueri, SP: Manole, 2004. 45 KANNINEN, B. J. Intelligent transportation systems: an economic and environmental policy assessment. Londres, 1996. PEREIRA, M. M.; GUEDES, L. G. Perspectivas das comunicações móveis no Brasil. Disponível em: <www.UCG.edu.br>. Acesso em: 26 ago. 2010. SANDERS, Geoff; THORENS, Lionel; REISKY, Manfred; RULIK, Oliver; DEYLITZ, Stefan. GPRS Networks. Chichester: John Wiley & Sons Ltd, 2003. SÃO PAULO TRANSPORTE S.A. - SPTRANS. Sistemas Informatizados para a Gestão do Transporte Coletivo do Município de São Paulo. São Paulo, Maio de 2009. Disponível em: < http://www.sptrans.com.br/pdf/biblioteca_ tecnica/sistemas_informatizados_para_a_gestao_do_transporte.pdf >. Acesso em Março de 2010. SILVA, Ardemirio de Barros. Sistemas de informações geo-referenciadas: conceitos e fundamentos. Campinas: UNICAMP, 2003. SUDARSHAN, S.; KORTH, Henry; SILBERSCHATZ, Abraham. Sistema de Banco de Dados. 4. ed. São Paulo: Campus/Elsevier, 2006. U.S. DEPARTAMENT OF TRANSPORTATION - US DOT. Research and Innovative Technology Administration, Washington, Setembro de 2009. Disponível em: < http://www.its.dot.gov/faqs.htm >. Acesso em Abril de 2010. 46 ANEXO I - ARTIGO 47 Desenvolvimento de uma Rede Inteligente de Transporte Urbano – Monitoramento e Controle de Horários de Veículos do Transporte Coletivo Felipe Lopes Escote – [email protected] Thales Augusto Porto da Silva – [email protected] Graduandos do Curso de Engenharia da Computação da Universidade Positivo Endereço para contato: Universidade Positivo Rua Prof. Pedro Viriato Parigot de Souza, 5300 – Campo Comprido 81280-330, Curitiba – PR Tel.: (+55) 41 3317-3270 Fax:(+55) 41 3317-3270 Resumo: Neste artigo, são apresentadas características e funcionalidades do Sistema de Monitoramento e Controle de Horários de Veículos do Transporte Coletivo, desenvolvido como Trabalho de Conclusão de Curso de Engenharia da Computação. São explicados os motivos que levaram ao desenvolvimento do projeto, e seus objetivos. São estudadas várias tecnologias utilizadas no sistema e questão, em especial o Serviço de Rádio de Pacote Geral (GPRS - General Packet Radio Service), utilizado na comunicação, e a Identificação por Radiofrequência (RFID - Radio-Frequency Identification), utilizado na detecção e identificação dos veículos. Palavras-chave: RFID, GPRS, Java, transporte urbano, transporte coletivo, ônibus, telefonia móvel, celular, rede de comunicação. 1 INTRODUÇÃO O projeto em questão tem a proposta de desenvolver um Sistema para monitorar a passagem de um veículo em seus pontos de embarque/desembarque e gerar uma estimativa da chegada deste nos próximos pontos a serem percorridos. Nesse artigo, alguns termos são utilizados com um significado específico. Assim, o termo Sistema, sem maiores qualificações, refere-se ao Sistema de Monitoramento e Controle de Horários de Veículos do Transporte Coletivo. O termo Módulo refere-se ao Módulo Java TC65i. O termo pontos refere-se aos pontos de embarque e desembarque de passageiros. Atualmente, na maioria das cidades, existe a necessidade de fiscalização presencial da pontualidade dos veículos e faltam informações quanto à localização e previsão de suas chegadas a um determinado ponto. O objetivo primário do Sistema é facilitar o controle gerencial da operadora quanto aos horários e tempos totais decorridos na viagem, a partir da captura de sinais provindos do veículo ao passar pelos pontos de espera. Como objetivos secundários apresentam-se: • Estimar um tempo para a chegada de um veículo a um determinado ponto de espera, com base nos registros armazenados. • Fornecimento de informações aos usuários, quanto à passagem do veículo por pontos de espera. • Construção de um painel simples e de fácil entendimento para fornecer as informações recebidas sobre o próximo ônibus ao passageiro; O projeto é composto por um conjunto de hardware e software. O hardware contém o painel informativo, o módulo Java TC65i, o leitor RFID e as etiquetas RFID. O software é desenvolvido em linguagem Java, e é implementado no servidor e nos módulos Java TC65i. Nos módulos, sua função é monitorar a passagem dos veículos e registrá-las no servidor, bem como solicitar ao servidor informações sobre o próximo veículo e enviá-las ao painel. No servidor, o software armazena informações em Banco de Dados e realiza os cálculos das estimativas, trocando essas informações com os módulos. A ênfase do Sistema é oferecer às empresas e aos órgãos que administram o transporte urbano, um sistema informatizado de registro e fornecimento de dados precisos sobre os horários e pontualidade dos veículos da frota, e que permita emissão de relatórios, 48 estatísticas e consultas em tempo real. Nas próximas seções, são apresentadas as tecnologias GPRS e RFID, metodologia utilizada e arquitetura do Sistema, descritivo do hardware e software, algoritmos desenvolvidos, resultados obtidos e ao final, as conclusões. 2 GPRS O GPRS (General Packet Radio Service) é um serviço baseado em dados, que permite o envio e recepção de informações através de uma rede telefônica móvel, provendo transparência de suporte ao Protocolo de Internet (IP – Internet Protocol) e isso permite sua integração com a Internet. IP é um protocolo usado entre duas máquinas em rede para encaminhamento dos dados. Assim, por meio do GPRS, aplicações do tipo TCP (Transmission Control Protocol), FTP (File Transfer Protocol) e e-mail podem ser atendidas (PEREIRA e GUEDES, 2004). O Sistema utiliza como meio de comunicação o GPRS, pois esse serviço está disponível em toda a rede GSM (Global System for Mobile Communications) das principais operadoras de telefonia móvel no Brasil. São utilizados dois cartões SIM (Subscriber Identity Module) de operadoras diferentes em cada módulo, de forma a oferecer redundância no acesso a Internet. 3 RFID RFID é um acrônimo do nome "Radio-Frequency Identification" em inglês que, em português, significa Identificação por Rádio Frequência. Trata-se de um método de identificação automática através de sinais de rádio, recuperando e armazenando dados remotamente através de dispositivos chamados de etiquetas RFID. As etiquetas RFID possuem identificação própria, que pode ser predefinida ou personalizável e são capazes de responder a sinais de rádio enviados por uma base emissora. As etiquetas RFID são classificadas em ativas, semi-passivas e passivas. As ativas utilizam baterias ou fonte de alimentação externa e possuem alcance maior de 5 metros. As semipassivas utilizam tanto a bateria ou fonte de alimentação quanto o campo magnético gerado pelo leitor para gerar corrente elétrica e possuem alcance de 0,5 a 5 metros. As passivas retiram a corrente elétrica necessária para o funcionamento totalmente do campo magnético gerado pelo leitor e possui alcance de até 50 centímetros. No Brasil, a identificação de veículos por RFID já é utilizado para pagamento de pedágios e estacionamentos, e em breve, com a implantação do SINIAV (Sistema Nacional de Identificação Automática de Veículos), seu uso será obrigatório em todos os veículos. Nesse projeto utilizamos a tecnologia RFID para a identificação dos veículos, quando os mesmos passam pelos pontos de embarque/desembarque. 4 METODOLOGIA O Sistema descobre o momento da passagem dos veículos em seus pontos de parada ao longo de sua rota, e com isso, estabelece uma previsão de chegada do próximo veículo, para cada um dos pontos de embarque. A descoberta de tempo é feita com o uso de etiquetas (veículos) e leitores (pontos) RFID e os registros de passagem dos veículos são transmitidos via GPRS, para um servidor central, que os grava em uma base de dados. Sempre que houver uma requisição de estimativa, o servidor processa as informações, realizando o cálculo, que é repassado ao requerente. A requisição da estimativa é feita pelo mesmo módulo que registra as passagens, e que também disponibiliza a estimativa no painel, para a visualização pelos passageiros. 5 ARQUITETURA O Sistema consiste em servidor de aplicação e Banco de Dados, dispositivos 49 embarcados, módulos RFID e painéis informativo. A Figura 1 exemplifica o sistema de comunicação e hardware. O servidor executa os softwares de registro de passagens e estimativas, além do SGDB (Sistema Gerenciador de Banco de Dados). O Módulo se comunica com o servidor via Internet, utilizando tecnologia de comunicação móvel GPRS. O mesmo Módulo recebe dados do Leitor RFID via interface serial RS232, e também envia as informações para o painel informativo, utilizando duas portas GPIO (General Purpose Input Output). Figura 1 - Arquitetura do Sistema 10 DESCRITIVO DO HARDWARE Como é visto na Figura 2, o registro do veículo é feito assim que a etiqueta localizada no veículo é detectada pelo Leitor RFID. O Leitor se comunica com o Módulo por meio de comunicação serial RS-232. Ao receber a identificação do veículo, o Módulo realiza conexão via GPRS com o servidor, e registra a passagem. 50 Figura 2 - Diagrama de hardware para registro da passagem. O processo de exibir a estimativa no painel é iniciado por uma requisição feita pelo Módulo ao Servidor, realizada periodicamente, com intervalos de 20 segundos entre o fim de uma requisição e o início de outra. A comunicação também ocorre pelo mesmo meio, o GPRS, só que em portas distintas. A resposta dessa requisição pode ser vista na Figura 3, onde o servidor processa e envia os dados ao Módulo, que, por sua vez, controla os LEDs e displays do painel, por meio das portas de GPIO. Figura 3 - Diagrama de hardware para obtenção de estimativa. O Módulo possui firmware que executa tanto o registro das passagens, quanto a obtenção e disponibilização de estimativa. Para isso, é criada uma thread assim que o sistema é iniciado. Essa thread irá aguardar o leitor RFID detectar a passagem de um veículo, e assim que isso ocorrer, irá receber o código do veículo, estabelecer uma conexão socket com o servidor, enviando logo em seguida, a identificação referente ao ponto no qual está localizado e a identificação do veículo para registrar sua passagem. Terminado isso, a conexão é encerrada, e o sistema volta a aguardar nova detecção. Paralelamente, o sistema estabelece outra conexão socket com o servidor, por meio de outra porta. Nessa conexão, é solicitada a localização e a estimativa do tempo de chegada do próximo veículo. Os dados são enviados ao painel, e, após 20 segundos, o ciclo se repete. Nesse caso, o objetivo é utilizar a mesma conexão para as próximas consultas, entretanto, sempre que o novo ciclo é iniciado, a conectividade é testada, e se houver algum problema, será estabelecida uma nova conexão, e finalizada a antiga. 51 10 DESCRITIVO DO SOFTWARE O Sistema é composto por um software para registro da passagem dos veículos, e outro para cálculo e fornecimento de estimativa de chegada do próximo veículo. O software de registro de passagens cria um socket para escutar determinada porta. Assim que recebe uma requisição de conexão do Módulo, é disparada uma thread para atender a requisição, e a função principal volta a escutar a porta. Isso permite que ele acate novas requisições enquanto processa as anteriores. Ao iniciar a thread e estabelecer uma conexão, o software recebe do cliente (Módulo) a identificação do ponto e o código identificador do veículo. Esses dados são registrados no banco de dados por meio de SPs (Stored Procedures) no SGDB, que irá incluir mais dados no registro, como horário e linha. Assim como o software de registro de passagens, o software que fornece as estimativas também cria um socket de escuta, e inicia uma nova thread para cada requisição. Após a conexão ser estabelecida, a thread criada recebe do Módulo a identificação do ponto e da linha da qual se deseja a previsão. O software irá calcular e enviar a estimativa ao módulo, e permanecer conectado, aguardando uma nova requisição, que será feita periodicamente pelo módulo, a cada 20 segundos. Se em algum momento a thread ficar na espera por mais de 45 segundos, o sistema entenderá que houve queda na conexão, e a thread será finalizada. 7 ALGORITMO DE CÁLCULO DO TEMPO DE ESPERA Para a determinação do tempo estimado de espera para a chegada do próximo veículo ao ponto, foi criado um procedimento na linguagem de programação Transact-SQL, extensão da linguagem SQL, armazenado no Banco de Dados PostgreeSQL. O software servidor inicia o procedimento no servidor de Banco de Dados, enviando os parâmetros da linha e do ponto do qual deseja a estimativa. O servidor de Banco de Dados executa o procedimento e retorna o tempo de espera estimado. A rotina de cálculo leva em consideração o tempo médio que foi necessário, nas ultimas três viagens anteriores à viagem atual, para percorrer entre os três pontos anteriores. Após o cálculo dessas médias, o sistema calcula o desempenho da viagem atual, em comparação as anteriores, e com isso, realiza a estimativa de tempo necessário para viagem entre o ponto em questão e o ponto anterior a ele. O tempo estimado é subtraído do tempo já decorrido após a passagem pelo ultimo ponto, e após isso, é retornado ao software servidor. 11 RESULTADOS Para validar o Sistema, foi desenvolvido um emulador com interface gráfica para Computador Desktop, simulando quatro pontos de parada, e o leitor RFID. Os códigos e métodos utilizados, com exceção da interface gráfica, foram os mesmos utilizados no Módulo. Como pode ser visto na Figura 4, o emulador exibe o status da conexão e nome do ponto escolhido para emulação, localização do próximo veículo (em amarelo) e o tempo estimado (em minutos) para a chegada do próximo veículo. 52 Figura 4 – Interface Gráfica do Emulador do Painel Em testes realizados durante 1 hora, o Sistema se manteve estável, registrando todas as requisições, com uso de processamento médio inferior a 10%, nas seguintes condições: • Servidor conectado a Link de Internet 4Mbps; • 1 Cliente Módulo conectado via GPRS; • 20 Clientes Emulador conectados por link de Internet 1Mbps (Internet celular 3 Geração); • 60 Clientes Emulador, executando 30 instancias na rede local, e outras 30 instancias em outro computador, utilizando link de Internet 2Mbps. O Sistema se mostrou eficiente e confiável em seu principal objetivo, que é o registro das passagens. A funcionalidade de previsão de chegada do próximo veículo funcionou conforme previsto, porém, necessita ser aprimorada para implantação em um sistema real. Deve-se ser feito um estudo estatístico para validação e aprimoramento do algoritmo aqui utilizado. 12 CONCLUSÃO O projeto consiste em um Sistema de Registro e Controle da Frota do Transporte Coletivo, que registra horários das passagens pelos pontos de paradas e fornece estimativas de chegada dos veículos aos passageiros, sendo composto por um conjunto de hardware e software. O hardware engloba os leitores e etiquetas RFID, painel informativo e Módulo Java TC65i com comunicação GPRS integrado. O software é dividido em três aplicações, sendo uma no módulo, que interpreta os dados recebidos pelo leitor RFID, e envia informações ao painel, outras duas no servidor, para registro dos dados e fornecimento de estimativas. No final têm-se um sistema completamente automatizado, que realiza todas as ações sem a necessidade de intervenção humana, oferecendo de modo instantâneo, estimativas com base em informações armazenadas em um servidor central. Com este projeto, percebeu-se que a utilização da identificação por rádio frequência pode melhorar o processo de monitoramento do transporte urbano devido o alto grau de automação que ela proporciona, reduzindo custos e erros na fiscalização e aumentando a qualidade do serviço. O Sistema mostrou-se bastante eficiente e preciso no registro dos horários das passagens, o cálculo do tempo estimado foi satisfatório, porém, necessita de estudos estatísticos para validação e aprimoramento do algoritmo utilizado. Como sugestão para futuros trabalhos, pode-se utilizar Displays de Cristal Líquido (LCD – Liquid Crystal Display) para confecção dos painéis, avisos sonoros, para que a informação possa ser acessível aos deficientes visuais e serviço de consultas via SMS (Short Message Service) e Web. REFERÊNCIAS 53 ALENCAR, Marcelo Sampaio de. Telefonia Celular Digital. 2. ed. São Paulo: Ética, 2007. DENATRAN - Departamento Nacional de Trânsito. SINIAV: Sistema Nacional de Identificação Automática de Veículos. Disponível em: <http://www.denatran.gov.br/siniav.htm>. Acesso em: 10 ago. 2010 DRANE, Chris; RIZOS, Chris. Positioning systems in intelligent transportation systems. London: Artech House, 1998. FERRAZ, Antonio Clovis Pinto; TORRES, Isaac Guilhermo Espinosa. Transporte Público Urbano. 2. ed. São Carlos: Rima, 2004. IGLESIAS, Fabio and GUNTHER, Hartmut. A espera na vida urbana: uma análise psicossocial das filas. [online]. 2009, vol.14, n.3, pp. 537-545. ISSN 1413-7372. JESZENSKY, Paul Jean Etienne. Sistemas Telefônicos. Barueri, SP: Manole, 2004. PEREIRA, M. M.; GUEDES, L. G. Perspectivas das comunicações móveis no Brasil. Disponível em: <www.UCG.edu.br>. Acesso em: 26 ago. 2010. 54 ANEXO II – CÓDIGOS FONTE 55 Código-fonte do Servidor CGD.java public class CGD { private Connection dbCon; private String Usuario; private String Senha; private String Url; private boolean ConfOK=false; public void LeConf(){ if (!ConfOK) { BufferedReader in = null; try { in = new BufferedReader(new FileReader("./server.dat")); Url = in.readLine(); Usuario = in.readLine(); Senha = in.readLine(); } catch (FileNotFoundException ex) { Logger.getLogger(CGD.class.getName()).log(Level.SEVERE, null, ex); } catch (IOException ex) { Logger.getLogger(CGD.class.getName()).log(Level.SEVERE, null, ex); } ConfOK=true; } } public void conectar() throws SQLException { LeConf(); //Class.forName("org.postgresql.Driver"); dbCon = DriverManager.getConnection("jdbc:postgresql:"+Url, Usuario, Senha); } public void desconectar() throws SQLException { dbCon.close(); } public void alterar() { } public void deletar() { } public void regPassagem( String pontoParada, String idtag ) { try { conectar(); PreparedStatement ps; ps = dbCon.prepareStatement("INSERT INTO movimentos(ponto,idtag,dthrpassagem) VALUES(?,?,?)"); ps.setString(1,pontoParada); ps.setString(2,idtag); ps.setDate(3, new Date(System.currentTimeMillis())); ps.execute(); 56 desconectar(); } catch (SQLException ex) { Logger.getLogger(CGD.class.getName()).log(Level.SEVERE, null, ex); } } public ResultSet relatorio(String placa, String tipoVeic, String Documento, String nome, String motivo,boolean PorData, String dataInic, String dataFinal) throws SQLException{ String where=""; if (Documento.length()>0) where=where.concat(" AND m.cnh='"+Documento+"' "); if (PorData) { if (!dataInic.equals("")) where=where.concat(" AND m.dt_ent>'"+dataInic+" 00:00:00.000' "); if (!dataFinal.equals("")) where=where.concat(" AND m.dt_ent<'"+dataFinal+" 23:59:59.999' "); } ResultSet rs=null; conectar(); PreparedStatement ps = dbCon.prepareStatement("SELECT * FROM movimentos m,veiculos v,condutores c WHERE m.placa=v.placa AND m.cnh=c.cnh AND v.placa like '%"+placa+ "%' AND v.uso like '%"+tipoVeic+"%' AND c.nome like '%"+nome+"%' AND m.motivo like '%"+motivo+"%'"+where+" ORDER BY m.dt_ent"); rs = ps.executeQuery(); desconectar(); return rs; } } ServSocket.java public class ServSocket{ private int PortaSrv = 10010; ServerSocket srv = null; Socket s = null; public ServSocket( ) { try { srv = new ServerSocket(PortaSrv); System.out.println("ServSocket - escutando porta: " + srv.getLocalPort()); while(true){ System.out.println("ServSocket: Aguardando conexao"); s = srv.accept(); System.out.println("ServSocket: Conexao detectada"); new ServSocketThread(s).start(); } } catch (Exception e) { System.out.println("ServSocket: " + e.getMessage()); } } } 57 servSocketThread.java public class ServSocketThread extends Thread{ Socket s = null; DataInputStream dis=null; DataOutputStream dos=null; public ServSocketThread(Socket s) { this.s=s; setDaemon(true); } public void run() { System.out.println("Thread Server: iniciada"); while(!abreSocketIO()) fechaSocketIO(); StringBuffer str = new StringBuffer(); System.out.println("vou ler"); int ch; do{ recebeStringServer(); }while(true); } private boolean abreSocketIO( ){ try { dis = new DataInputStream(s.getInputStream()); dos = new DataOutputStream(s.getOutputStream()); System.out.println("Thread server ASS - conectado: " + s.getInetAddress() + ":" + s.getPort()); return testaComunicServer( ); } catch (Exception e) { System.out.println("Thread server ASS: " + e.getMessage()); return false; } } private boolean testaComunicServer( ){ try { String recebida = recebeStringServer( ); System.out.println("Thread Gprs TCS - recebida: " + recebida ); return recebida.equals(Integer.toString("testeComunic".hashCode())); } catch (Exception e) { System.out.println("Thread Gprs TCS: " + e.getMessage()); return false; } } private String recebeStringServer( ){ StringBuffer str = new StringBuffer(); String strFinal = null; try { int i=0; while (dis.available()<4){ Thread.sleep(500); if (i==10){ return ""; 58 } i++; } int recByte = dis.readInt(); System.out.println("num de caracteres:"+recByte); int j = recByte; for (i=0; i<j; i++){ recByte = dis.read(); str.append((char)recByte); } strFinal = new String(str); enviaStringServer(strFinal); System.out.println("Thread Gprs RSS - recebida: " + strFinal); return strFinal; } catch (Exception e){ System.out.println("Thread Gprs RSS: " + e.getMessage()); return ""; } } private boolean enviaStringServer(String texto){ try { System.out.println("Thread Server ESS - enviando: " + texto); dos.writeInt(texto.length()); dos.write(texto.getBytes()); dos.flush(); return true; } catch (Exception e) { System.out.println("Thread Server ESS: " + e.getMessage()); return false; } } private boolean fechaSocketIO( ) { try { dos.close(); dis.close(); s.close(); System.out.println("Thread server FSS: Socket finalizado"); return true; } catch (Exception e) { System.out.println("Thread server FSS: " + e.getMessage()); return false; } } } 59 Código-fonte do Cliente RFID.java import java.io.*; import javax.microedition.io.*; public class Rfid { CommConnection commConn; InputStream inStream; OutputStream outStream; public Rfid() { System.out.println("Portas disponiveis: " + System.getProperty("microedition.commports")); try { String strCOM = "comm:COM0;baudrate=9600;bitsperchar=8;stopbits=1;parity=none"; commConn = (CommConnection)Connector.open(strCOM); System.out.println("porta" + strCOM + "aberta."); inStream = commConn.openInputStream(); System.out.println("IS aberta"); } catch(IOException e) { System.out.println(e); } } public void letag() { System.out.println("escutando porta serial"); StringBuffer str=new StringBuffer(); try { int ch = -1; int i = 0; while(ch != 'Q') { ch = inStream.read(); if (ch >= 0) { i++; System.out.print(ch + "-"); str.append(ch); } if (i==16){ System.out.print(ch + "\r\n"); break; } } new RfidThread(new String(str)).start(); } catch(IOException e) { System.out.println(e); } } public void pauseApp() { System.out.println("RS232Demo: pauseApp()"); } public void destroyApp(boolean cond) { System.out.println("RS232Demo: destroyApp(" + cond + ")"); try { inStream.close(); 60 outStream.close(); commConn.close(); System.out.println("Streams and connection closed"); } catch(IOException e) { System.out.println(e); } } } mae.java import javax.microedition.midlet.MIDlet; import javax.microedition.midlet.MIDletStateChangeException; public class mae extends MIDlet { protected void destroyApp(boolean arg0) throws MIDletStateChangeException { notifyDestroyed(); } protected void pauseApp() { } protected void startApp() throws MIDletStateChangeException { System.out.println("estou rodando"); Rfid errefid=new Rfid(); try{ while(true){ errefid.letag(); } }catch (Exception e) { destroyApp(true); } destroyApp(true); } } RfidThread.java public class RfidThread extends Thread{ private String idtag = null; public RfidThread(String idtag) { this.idtag=idtag; } public void run(){ SockGprs conecGprs = new SockGprs(10010); conecGprs.enviar(new String(idtag)); } } SockGprs.java import java.io.*; import javax.microedition.io.*; 61 public class SockGprs{ private String destHost = "nomehost.com", destPort = "10010", connProfile "bearer_type=gprs;access_point=tim.br;username=tim;password=tim", connProfile2 "bearer_type=gprs;access_point=zap.vivo.com.br;username=vivo;password=vivo"; SocketConnection sc = null; DataInputStream dis = null; DataOutputStream dos = null; public SockGprs(int destPort) { System.out.println("Thread Gprs SG: construtor" ); this.destPort=Integer.toString(destPort); } public void enviar(String str) { while(!abreGprs( )){ System.out.println("Thread Gprs SG: nao foi possivel estabelecer conexao" ); fechaGprs( ); } System.out.println("Thread Gprs SG: conexao estabelecida" ); while(!enviaStringGprs(str)); { System.out.println("Thread Gprs SG: erro ao enviar tag"); } System.out.println("Thread Gprs SG: tag "+ str + " enviada!"); fechaGprs(); } private boolean abreGprs( ){ try { String openParm = "socket://" + destHost + ":" + destPort+ ";" + connProfile; System.out.println("Thread Gprs AG: Connector open: " + openParm); sc = (SocketConnection) Connector.open(openParm); System.out.println("Thread Gprs AG: conectado com o socket "); dis = new DataInputStream(sc.openInputStream()); dos = new DataOutputStream(sc.openOutputStream()); } catch (Exception e) { String aux = connProfile; connProfile = connProfile2; connProfile2 = aux; System.out.println("Thread Gprs AG: " + e.getMessage()); return false; } return testaComunicGprs( ); } private boolean testaComunicGprs( ){ try { return enviaStringGprs(Integer.toString("testeComunic".hashCode())); } catch (Exception e) { System.out.println("Thread Gprs TCG: " + e.getMessage()); return false; } } private boolean enviaStringGprs(String texto){ boolean verif=false; try { int i=0; System.out.println("Thread Gprs ESG: enviando: " + texto); do{ dos.writeInt(texto.length()); = = 62 dos.write(texto.getBytes()); dos.flush(); i++; verif=recebeStringGprs( ).equals(texto); System.out.println("Thread Gprs ESG - verificacao: " + verif); }while((!verif)&&i<5); return verif; } catch (Exception e) { System.out.println("Thread Gprs ESG: " + e.getMessage()); return false; } } private String recebeStringGprs( ){ StringBuffer str = new StringBuffer(); try { int i=0; while (dis.available()<4){ Thread.sleep(500); if (i==5){ return ""; } i++; } int recByte = dis.readInt(); System.out.println("num de caracteres:"+recByte); int j = recByte; for (i=0; i<j; i++){ System.out.println("entrei no for:" + str); recByte = dis.read(); str.append((char)recByte); } System.out.println("Thread Gprs RSG - recebida:" + new String(str)); } catch (Exception e) { System.out.println("Thread Gprs RSG: " + e.getMessage()); return ""; } return new String(str); } private boolean fechaGprs( ){ try { dis.close(); dos.close(); sc.close(); return true; } catch (Exception e) { System.out.println("Thread Gprs FG: " + e.getMessage()); return false; } } public void pauseApp() { System.out.println("Thread Gprs: pauseApp()"); } public void destroyApp(boolean cond) { System.out.println("Thread Gprs: destroyApp(" + cond + ")"); } }
