Universidade de Braslia

Instituto de Cincias Exatas Departamento de Cincia da Computao

Telemetria Automotiva via Internet Mvel

Alcides Carlos de Moraes Neto

Braslia 2009

Universidade de Braslia
Instituto de Cincias Exatas Departamento de Cincia da Computao

Telemetria Automotiva via Internet Mvel

Alcides Carlos de Moraes Neto

Monograa apresentada como requisito parcial para concluso do Bacharelado em Cincia da Computao

Orientador Prof. Ricardo Pezzuol Jacobi

Braslia 2009

Universidade de Braslia UnB Instituto de Cincias Exatas Departamento de Cincia da Computao Bacharelado em Cincia da Computao

Coordenador: Prof.a Carla Maria Chagas e Cavalcante Koike

Banca examinadora composta por: Prof. Ricardo Pezzuol Jacobi (Orientador) CIC/UnB Prof. Pedro de Azevedo Berger CIC/UnB Prof.a Carla Maria Chagas e Cavalcante Koike CIC/UnB

CIP Catalogao Internacional na Publicao de Moraes Neto, Alcides Carlos. Telemetria Automotiva via Internet Mvel / Alcides Carlos de Moraes Neto. Braslia : UnB, 2009. 111 p. : il. ; 29,5 cm. Monograa (Graduao) Universidade de Braslia, Braslia, 2009. 1. Sistema embarcado, 2. Sistema automotivo, 3. Telemetria, 4. Internet mvel CDU 004.7

Endereo:

Universidade de Braslia Campus Universitrio Darcy Ribeiro Asa Norte CEP 70910-900 BrasliaDF Brasil

Universidade de Braslia
Instituto de Cincias Exatas Departamento de Cincia da Computao

Telemetria Automotiva via Internet Mvel

Alcides Carlos de Moraes Neto

Monograa apresentada como requisito parcial para concluso do Bacharelado em Cincia da Computao

Prof. Ricardo Pezzuol Jacobi (Orientador) CIC/UnB Prof.a Carla Maria Chagas e Cavalcante Koike CIC/UnB

Prof. Pedro de Azevedo Berger CIC/UnB

Prof.a Carla Maria Chagas e Cavalcante Koike Coordenador do Bacharelado em Cincia da Computao

Braslia, 7 de dezembro de 2009

 Alda, querida av.

Agradecimentos
Agradeo primeiramente ao meu orientador, prof. Ricardo Jacobi por liderar este excelente projeto de pesquisa, me dando a oportunidade de realizar este trabalho que tanto me motivou e satisfez. A toda a equipe envolvida, tanto da UnB quanto da SEA Tecnologia, pelo ambiente de colaborao e discusso, sem o qual este trabalho no seria o mesmo. A todos os professores com quem tive contato durante esta longa jornada pela UnB. Aprendi com todos, no s contedo mas como ser uma pessoa melhor. Em especial, aos professores Marcelo Ladeira, Marco Aurlio e Alba Cristina por terem me tirado o medo de aprender C e pelas aulas engrandecedoras. Aos meus colegas de curso, novos e velhos, com os quais tambm aprendi muito. Ao pessoal do DAA e do DAIA na reitoria, por terem me dado a chance de concluir meu curso. Em especial ao Edson do posto avanado do DAA, por aguentar os telefonemas e sempre fazer o possvel para ajudar. Aos meus amigos pelos momentos de diverso e descontrao, sem os quais no seria possvel manter a sanidade. Vocs me deram bnus no meu will save, IZO! Aos meus pais, minhas irms, meu av xar, e toda minha famlia, pelo apoio, tanto material quanto motivacional, e pacincia durante toda esta jornada. Muito obrigado. A minha linda e amada mulher, Ludmila Araujo. Foi com sua inteligncia e sensibilidade que consegui ser o melhor que eu posso, e que tornou este trabalho possvel. Muito obrigado, por tudo. Te amo mais que tudo na vida.

Resumo
O presente trabalho tem como objetivo estudar a implementao de um sistema embarcado para a telemetria de um automvel via internet mvel para o projeto Karmonitor. So levantadas as tecnologias disponveis para monitoramento e diagnstico em um automvel, como o padro OBD (On-board Diagnostics) e os protocolos mais usados para comunicao das diversas unidades eletrnicas de controle (ECUs) presentes no automvel, como o CAN (Controller Area Network) e o J1850. So tambm estudadas as tecnologias mveis de conexo Internet que esto disponveis hoje e que devero ser usadas pelo sistema embarcado. abordado tambm o ambiente que foi denido pelo projeto Karmonitor onde o sistema ser implementado, os softwares disponveis para apoio e o desenvolvimento dos programas necessrios para a execuo da telemetria. Testes so feitos em alguns diferentes modelos de carros para averiguar o comportamento do sistema Palavras-chave: Sistema embarcado, Sistema automotivo, Telemetria, Internet mvel

vi

Abstract
This work aims to study the implementation of an embedded automotive telemetry system via mobile Internet services for the Karmonitor project. Research is made on the available technologies for automotive diagnoses, like the OBD (On-board Diagnostics) standard and the most used bus protocols for communications of the many ECUs (Electronic Control Units) inside a cars system, like CAN (Controller Area Network) and J1850. Also study is made on mobile Internet connection technologies that are available today that can be used in this embedded system. All this will be done before analysing the environment dened for the Karmonitor system, the software available that can support a telemetry system and the development of programs needed to execute it. Tests are made on some car models in order to observe the systems behaviour. Keywords: Embedded system, Automotive system, Telemetry, Mobile Internet

vii

Lista de Figuras
1.1 Exemplo de arquitetura para telemetria via Internet . . . . . . . . . 1.2 Diagrama de arquitetura de telemetria mvel . . . . . . . . . . . . . . 2.1 2.2 2.3 2.4 Diagrama de um automvel com 3 redes distintas: Quadro de dados do protocolo CAN 2.0A . . . . . . Quadro de dados do protocolo CAN 2.0B . . . . . . Ciclo de comunicao do protocolo FlexRay . . . . 4 5

LIN, CAN e MOST 7 . . . . . . . . . . . 15 . . . . . . . . . . . 15 . . . . . . . . . . . 18 22 23 24 30 31 32 34 37 39 40 45 53 53 54 54 55 55 56 56 57

3.1 Esquema do conector OBD-II . . . . . . . . . . . . . . . . . . . . . . . 3.2 Interface OBD x USB de Alex Sidorenko . . . . . . . . . . . . . . . . . 3.3 Esquema eltrico da interface OBD x USB de Alex Sidorenko . . . . 4.1 Uma rede GSM com ns SMS e GPRS (Junior, 2005) . . . . . . . . . 4.2 Placa PCMCIA da VIVO para acesso a rede GSM 3G . . . . . . . . . 4.3 Interface USB GSM 3G. . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 5.2 5.3 5.4 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 A Beagle Board com seus principais componentes destacados . Fluxograma do programa cliente . . . . . . . . . . . . . . . . . Fluxograma do programa servidor . . . . . . . . . . . . . . . . Diagrama de classes do programa servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exemplo de arquivo de congurao do cliente . . . . . . . . . . . . Notebook Dell utilizado para executar o sistema . . . . . . . . . . . Conector USBxOBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . Celular Nokia N95 com cabo USB para uso como modem 3G/GPRS. Automvel Ford Ka 1.0, ano 2009, exterior. . . . . . . . . . . . . . . Localizao do conector OBD no Ford Ka. . . . . . . . . . . . . . . . Automvel Nissan Livina 1.6, ano 2009, exterior. . . . . . . . . . . . Localizao do conector OBD no Nissan Livina. . . . . . . . . . . . . Automvel Ford Focus 2.0, ano 2009, exterior. . . . . . . . . . . . . . Localizao do conector OBD no Ford Focus. . . . . . . . . . . . . . .

viii

Lista de Tabelas
2.1 Tipos de protocolo J1850 (Riley, 1998) . . . . . . . . . . . . . . . . . . 2.2 Smbolos do protocolo J1850 (Riley, 1998) . . . . . . . . . . . . . . . . 3.1 Dados OBD-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Estrutura da tabela de veculos . . . . . . . . . . . . . . . . . . . . . . 5.2 Estrutura parcial da tabela de dados OBD . . . . . . . . . . . . . . . . 5.3 Comandos que o servidor pode enviar ao cliente . . . . . . . . . . . . 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 Dados OBD suportados pelo Ford Ka. . . . . . . . . . . . . . . . Taxas do sistema observadas durante testes no Ford Ka. . . . . Exemplo de dados levantados para o Ford Ka. . . . . . . . . . . Valores mdios de parmetros levantados para o Ford Ka. . . . Dados OBD suportados pelo Nissan Livina. . . . . . . . . . . . . Taxas do sistema observadas durante testes no Nissan Livina. . Exemplo de dados levantados para o Nissan Livina. . . . . . . . Valores mdios de parmetros levantados para o Nissan Livina. Dados OBD suportados pelo Ford Focus. . . . . . . . . . . . . . . Taxas do sistema observadas durante testes no Ford Focus. . . . Exemplo de dados levantados para o Ford Focus. . . . . . . . . . Valores mdios de parmetros levantados para o Ford Focus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9 25 41 41 42 47 48 48 49 49 50 50 51 51 51 52 52

ix

Sumrio
Lista de Figuras Lista de Tabelas 1 Introduo 1.1 Projeto Karmonitor . . . . . . 1.2 Problema . . . . . . . . . . . . 1.3 Objetivos . . . . . . . . . . . . 1.4 Motivao . . . . . . . . . . . . 1.5 Metodologia . . . . . . . . . . 1.6 Telemetria . . . . . . . . . . . 1.6.1 Anlise da arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii ix 1 1 2 2 3 3 3 4 6 7 7 8 8 8 10 12 12 16 16 17 17 17 17 19 19 19 20 21

2 Tecnologias de barramento automotivas 2.1 Classe A . . . . . . . . . . . . . . . . . . 2.1.1 Local Interconnect Network . . . 2.1.2 TTP/A . . . . . . . . . . . . . . . . 2.2 Classe B . . . . . . . . . . . . . . . . . . 2.2.1 J1850 . . . . . . . . . . . . . . . . 2.2.2 ISO 9141-2 . . . . . . . . . . . . . 2.2.3 ISO 14230-4 . . . . . . . . . . . . 2.2.4 Low-speed CAN . . . . . . . . . . 2.3 Classe C . . . . . . . . . . . . . . . . . . 2.3.1 High-speed CAN . . . . . . . . . . 2.3.2 TTP/C . . . . . . . . . . . . . . . . 2.4 Classe D . . . . . . . . . . . . . . . . . . 2.4.1 MOST . . . . . . . . . . . . . . . . 2.4.2 FlexRay . . . . . . . . . . . . . . . 3 Aquisio de dados 3.1 OBD . . . . . . . . . . . . . . . . . . . 3.1.1 Histria . . . . . . . . . . . . . 3.1.2 Padres OBDBr-1 e OBDBr-2 3.1.3 Padro OBD-II . . . . . . . . . . . . . . . . .

4 Telefonia mvel 4.1 GSM . . . . . . . . . . . . . . . . 4.1.1 SMS . . . . . . . . . . . . 4.1.2 GPRS . . . . . . . . . . . 4.1.3 EDGE e UMTS . . . . . 4.1.4 Acesso Internet Mvel

. . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28 28 29 29 30 31 33 33 33 34 35 35 35 36 38 42 43 43 44 44 45 46 47 47 47 48 48 48 49 49 50 50 50 51 58 60

5 Arquitetura do Sistema 5.1 Hardware . . . . . . . . . . . . . . 5.2 Sistema Operacional . . . . . . . 5.2.1 Linux . . . . . . . . . . . . 5.2.2 Angstrom . . . . . . . . . . 5.3 Software . . . . . . . . . . . . . . 5.3.1 Medio . . . . . . . . . . . 5.3.2 Cliente . . . . . . . . . . . 5.3.3 Servidor . . . . . . . . . . 5.3.4 Protocolo de comunicao

6 Testes e anlises 6.1 Plataforma de testes . . . . . . . . . . . 6.2 Procedimentos . . . . . . . . . . . . . . . 6.2.1 Montagem do ambiente cliente . 6.2.2 Montagem do ambiente servidor 6.3 Clculos . . . . . . . . . . . . . . . . . . . 6.4 Ford Ka 1.0 2009 . . . . . . . . . . . . . 6.4.1 Dados do teste . . . . . . . . . . . 6.4.2 Campos OBD suportados . . . . . 6.4.3 Valores observados . . . . . . . . 6.5 Nissan Livina 1.6 2009 . . . . . . . . . . 6.5.1 Dados do teste . . . . . . . . . . . 6.5.2 Campos OBD suportados . . . . . 6.5.3 Valores observados . . . . . . . . 6.6 Ford Focus 2.0 2009 . . . . . . . . . . . . 6.6.1 Dados do teste . . . . . . . . . . . 6.6.2 Campos OBD suportados . . . . . 6.6.3 Valores observados . . . . . . . . 7 Concluso e desenvolvimentos futuros Referncias I Cdigo-fonte do cliente I.1 clientmain.h . . . . . I.2 clientmain.c . . . . . I.3 database.h . . . . . . I.4 database.c . . . . . . I.5 networking.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

63 63 64 70 71 73

I.6

networking.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75 79 79 81 87 89 91 93 95 95 95

II Cdigo-fonte do servidor II.1 Main.java . . . . . . . . II.2 ServerThread.java . . . II.3 DbConnector.java . . . II.4 ObdDao.java . . . . . . II.5 Vehicle.java . . . . . . . II.6 VehicleDao.java . . . .

III Tabelas do banco de dados do servidor III.1 Tabela VEHICLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III.2 Tabela OBDGPSDATA . . . . . . . . . . . . . . . . . . . . . . . . . . .

xii

Captulo 1 Introduo
Desde o incio dos anos 70, cada vez mais os veculos automotores tm sido equipados com unidades eletrnicas de controle (Electronic Control Units - ECU). Estas ECUs realizam monitoramentos, compartilham informaes atravs de barramentos, fazem ajustes baseados nas informaes disponveis e muitas j so responsveis por funes vitais para o funcionamento dos veculos (por ex: injeo eletrnica). fcil ver o porqu desta tendncia: Equipamentos eletrnicos oferecem muito mais versatilidade, conabilidade e performance do que mquinas estritamente mecnicas. As possibilidades que so disponibilizadas pela tecnologia de software permite a implantao de sistemas complexos que melhoram no s o desempenho do veculo, mas como a segurana e o conforto de seu usurio.

1.1

Projeto Karmonitor

O projeto Karmonitor prope o desenvolvimento de uma plataforma em sistema embarcado para telemonitoramento e telecontrole de veculos baseada em FPGA. Um dos objetivos do projeto permitir que o usurio obtenha informaes sobre o estado do veculo e envie comandos para alter-lo atravs de aplicao executando em telefone celular. Atualmente os servios de telefonia celular apresentam uma rea de cobertura signicativa. Associada a larga difuso dos aparelhos celulares na sociedade, a possibilidade de acessar informaes sobre o estado do veculo, incluindo sua localizao, e enviar comandos para control-lo atravs do celular caracteriza um nicho de mercado ainda no explorado, e uma oportunidade para desenvolvimento de um produto inovador e com forte apelo comercial. Outro objetivo do projeto ser um interpretador de comandos vocais emitidos tanto por celular como do interior do veculo. O controle do estado do veculo atravs de uma interface natural, alm de auxiliar o usurio comum, igualmente de interesse para portadores de necessidades especiais (PNE), pois permite ao motorista realizar tarefas sem a necessidade de retirar as mos do volante.

1.2

Problema

Um dos problemas que o projeto Karmonitor aborda o da medio de dados funcionais de veculos remotamente, de forma automatizada, que ser o foco deste projeto. Os veculos automotivos devem ser submetidos a constantes revises para averiguao do seu funcionamento e performance. Este processo est cada vez mais informatizado, como pode ser visto neste projeto, com o desenvolvimento de protocolos para medio dos dados funcionais do veculo, diminuindo a necessidade de diagnstico mecnico. Mas ainda assim necessrio que o veculo seja retirado de circulao e seja submetido a tcnicos humanos que, mesmo com a crescente informatizao do processo, ainda podem cometer erros. Como essas medies so peridicas, e dependem que o proprietrio do veculo leve-o at a assistncia tcnica, nem elas so realizadas pelos veculos estarem funcionando satisfatoriamente, apesar de estarem desregulados. Uma das consequncias disso um maior consumo de combustvel pelos veculos desregulados, e tambm maior quantidade de poluentes gerados. Apesar de existir legislao que estabelea limites para a emisso de poluentes pelos veculos (Lei 8.723, de 28 de outubro de 1993), ela praticamente nula, visto que no existe forma fcil para medio deste parmetro em larga escala.

1.3

Objetivos

A proposta deste projeto para a soluo do problema um sistema embarcado a bordo do veculo para aquisio e envio dos dados para uma aplicao servidora via Internet, utilizando uma conexo via rede celular. Este sistema de telemetria levantaria periodicamente os dados disponibilizados pelo automvel e enviar-los-ia a um ou mais destinatrios, que podem ser mquinas servidoras dedicadas a receber e processar estes dados ou mesmo o celular do proprietrio. Objetivos especcos: 1. Estudo das tecnologias: (a) Redes digitais intraveiculares e como criar uma interface com elas. (b) Redes celulares e como realizar conexo com a Internet atravs delas. 2. Desenvolvimento da aplicao: (a) Mdulo para aquisio dos dados de um veculo. (b) Mdulo para envio dos dados pela Internet, utilizando rede celular. (c) Programa servidor que far o recebimento e processamento dos dados.

1.4

Motivao

Um sistema que possibilite monitoramento remoto de automveis pode ser aplicado para diversos ns, inclusive: No monitoramento de frota de veculos de uma empresa ou entidade, diminuindo o nmero de vezes que o veculo deve ser retirado de circulao para manuteno. Em estudo estatstico por parte da montadora ao utilizar o sistema em todos seus veculos, obtendo assim uma populao muito signicativa para estudo. Na vericao do nvel de emisso de gases poluentes dos automveis, possibilitando assim a scalizao da legislao vigente, melhorando a qualidade do ar e diminuindo o consumo de combustvel fssil.

1.5

Metodologia

Para chegar a tais objetivos, pode-se destacar os principais passos: 1. Arquitetura do sistema e ambiente de desenvolvimento: necessrio antes de mais nada conhecer o ambiente de desenvolvimento utilizado e qual ser sua arquitetura. 2. Aquisio de dados: necessrio que o sistema consiga acessar os dados funcionais do automvel. necessrio que seja denido o hardware e/ou software necessrio. 3. Processamento dos dados: Depois de recuperar os dados, o sistema dever trat-los e decidir o envio deles. Aqui pode ser feita seleo de qual servidores recebero os dados. Por exemplo pode haver um destino para dados de funcionamento e outro para dados de problema ou defeitos. 4. Envio dos dados: Estudar a tecnologia que ser usada para o envio, considerando a possibilidade de mltiplos protocolos se for possvel e plausvel. Por exemplo, dados ao condutor ou proprietrio do veculo podem ser feitos via SMS. Dados para um servidor na Internet podem ser enviados por GPRS. 5. Arquitetura de um sistema servidor: Levantar as possibilidades para o recebimento destes dados via Internet: Qual o tipo de protocolo e software usar para receber esses dados. Tambm as estatsticas que podem ser levantadas por um servidor.

1.6

Telemetria

Telemetria uma forma de tecnologia muito empregada em diversas reas da cincia, com a medicina (Gutierrez, 2006; Paim, 2005) a biologia (Mantovani and

Figura 1.1: Arquitetura para telemetria via Internet proposta em Khan et al. (2007). Santos, 2001), e at mesmos parques temticos (Walker, 2007). Consiste na medio de dados de interesse de um analisador e consequente envio desses dados para um acumulador para posterior anlise. Tais sistemas diferem entre si tanto pela tecnologia empregada quanto pela arquitetura adequada para resolver suas necessidades. Normalmente so implantados em locais de difcil acesso, as vezes inspitos a seres humanos, possibilitando o monitoramento constante destes sistemas em outro local, possuindo diferentes necessidades de distncia e banda de transmisso. Considerando o local de instalao do projeto, um automvel, e o ambiente urbano em que circula, foi escolhido hardware e interface de comunicao adequados para prover acesso a um acumulador remoto: Acesso Internet via rede celular, presente na grande maioria de cidades brasileiras. Pela Internet ento, possvel acessar um servidor em qualquer lugar do mundo, que servir de acumulador de dados.

1.6.1

Anlise da arquitetura

Sistemas de Telemetria via Internet j existem, como visto em Khan et al. (2007), porm, a arquitetura proposta sugere a conexo remota do medidor ao dispositivo sendo medido, congurando uma arquitetura cliente-servidor onde o servidor quem faz o levantamento dos dados. Esta arquitetura pode ser visualizada na gura 1.1. Analisando esta arquitetura para uma aplicao automotiva, ela no parece a ideal, pelas seguintes razes: Uma conexo mvel no tem endereamento estvel. Ao movimentar-se, um dispositivo celular troca a central de comunicaes com a qual mantm conexo constantemente, mudando assim seu endereamento. Um endereamento dinmico diculta a conexo remota.

Figura 1.2: Diagrama da arquitetura de telemetria mvel proposta em Jenkins (2004). Conexes mveis so instveis, podendo ser perdidas em uma troca de central ou mesmo quando o veculo est fora da rea de cobertura. Esta arquitetura plausvel para sistemas que tm uma conexo estvel e constante com a Internet, o que no o caso. Uma arquitetura para medio de performance de veculos via Internet proposta em Jenkins (2004). A arquitetura proposta considera estas diculdades e estabelece um uxo contrrio, onde a mquina cliente est no veculo, enquanto um servidor remoto recebe os dados enviados pelo veculo constantemente e o armazena em um banco de dados. Mquinas clientes ento se conectam a este servidor intermedirio para fazer consultas. Um diagrama desta arquitetura pode ser visto na gura 1.2. A arquitetura do sistema ser baseada nesta, muito mais plausvel em um ambiente automotivo. A medio constante pelo sistema ser armazenada localmente antes de acontecer a tentativa de envio, evitando com que dados sejam perdidos.

Captulo 2 Tecnologias de barramento automotivas

Com o crescente nmero e complexidade de ECUs nos veculos, tornou-se necessrio que estes componentes trocassem informaes entre si. A princpio a comunicao era feita atravs de ligaes diretas entre os componentes. Mas o crescente nmero destas ECUs tornou esta soluo inecaz, visto que para cada n controladoras, seria necessrio n2 conexes para interligar todos. Dada esta situao, a possibilidade de se conectar um nmero arbitrrio de componentes entre si, com protocolo de comunicao pr-denido por uma interface padro foi o motivador para a criao dos barramentos automotivos. Estudar a tecnologia utilizada no automvel para transmisso de dados entre os ECUs fundamental para a arquitetura de um sistema embarcado, pois atravs dela que ser feita a troca de mensagens entre os componentes do carro e o sistema. Para entender melhor os requisitos do automvel, suas funes so separadas em domnios (Navet et al., 2005) que correspondem a diferentes recursos e restries. Estes domnios so: 1. Sistema de fora: Responsvel pelo controle do motor e transmisso. 2. Chassi: Onde feito o controle de suspenso, volante e freios. 3. Corpo: Recursos de conforto como inclinao de assento e ar condicionado. 4. Telecomunicao: Comunicaes com o mundo externo; sem-o, sistemas de localizao. 5. Multimdia e Interface homem mquina (HMI): Interao com o condutor e passageiros. 6. Segurana: Voltado para a segurana dos ocupantes do veculo. Existem diversas tecnologias usadas para a comunicao dos componentes, cada qual com caractersticas especcas para atender os diferentes domnios (como tempo de resposta, banda, redundncia, deteco de erros, etc.), e normal encontrar mais de um barramento implantado em um veculo (Podemos ver um exemplo de implementao na gura 2.1). Em 1994, a Sociedade de Engenheiros Automotivos dos Estados Unidos (SAE - Society for Automotive Engineers) deniu uma 6

classicao para protocolos de comunicao automotivos baseada na velocidade de transmisso de dados e funes que so distribudas pela rede. Os protocolos foram separados em classes A, B, C e D (Leen and Heffernan, 2002; Leen et al., 1999).

Figura 2.1: Diagrama de um automvel com 3 redes distintas: LIN, CAN e MOST

2.1

Classe A

So redes com taxa de transmisso menor que 10kb/s, usadas para transmitir dados de controle simples, utilizando tecnologias de baixo custo. So principalmente utilizadas no domnio "corpo", que possui somente sistemas no crticos como controle de assento e detector de chuva. Exemplos de redes classe A so LIN e TTP/A.

2.1.1

Local Interconnect Network

LIN, ou Local Interconnect Network, uma evoluo do ISO 9141, uma rede de baixa velocidade e custo. Esta rede normalmente usada para interligar dispositivos simples sem muitas variveis de controle como assentos, espelhos e janelas. Sua arquitetura a mestre-escravo que, alm de no necessitar de diversos nodos com funcionamento complexo, tambm uma medida de segurana, visto que impossvel comprometer outros nodos da rede atravs de um nodo vulnervel. (Por exemplo, abrir a janela do carro atravs do sistema de controle dos vidros retrovisores) (Leen and Heffernan, 2002). um padro aberto (criado pelas empresas Audi, BMW, DaimlerChrysler, Motorola, Volcano, Volvo e Volkswagen) e foi desenvolvido com o intuito de ser integrado com protocolos de maior velocidade como o CAN. 7

2.1.2

TTP/A

Protocolo similar ao LIN, mas de iniciativa acadmica, criado pela Universidade Tcnica de Vienna, ustria; Universidade Tcnica de Munich e Universidade de Stuttgart, Alemanha. Assim como o LIN foi criado para complementar o CAN, o TTP/A foi criado para complementar o TTP/C, de autoria tambm das faculdades citadas (Kopetz and Grunstidl, 1993). TTP signica Time Triggered Protocol, devido a sua principal caracterstica que a estratgia de envio de dados em janelas de tempo especcas para cada nodo (TTA Group, 2004). Os dois protocolos so semelhantes, mas o TTP/A foi desenvolvido com maior nmero de aplicaes em mente, no somente a automobilstica. Comparaes entre o TTP/A e o LIN mostram a superioridade do TTP/A quanto a recursos e performance (Kopetz et al., 2000).

2.2

Classe B

Redes dedicadas conexo de ECUs, de forma a diminuir a necessidade de sensores atravs da troca de informaes. Estas redes operam entre 10 e 125 kb/s. O J1850 e o CAN de baixa velocidade (low-speed CAN) so os principais representantes desta classe. So protocolos desta classe que so usados para diagnstico a bordo (OBD).

2.2.1

J1850

O barramento J1850, adotado pela SAE em 1994 como o padro classe B mas j considerado em declnio em favor do CAN, um barramento usado em aplicaes de diagnstico e compartilhamento de dados em veculos. A GM e a Chrysler adotaram J1850 VPW, denominando-o de Barramento Classe 2 (Class 2 Bus). A Ford utiliza o J1850 PWM, que denido como o Protocolo Corporativo Padro (Standard Corporate Protocol). Caractersticas O J1850 usado de duas formas: A 41.6 Kbps via modulao por largura de pulso (PWM) em cabo duplo, ou a 10.4 Kbps via modulao de pulso varivel (VPW) em cabo simples. Apesar de no serem compatveis na camada fsica, os dois tipos possuem semelhanas na camada de ligao de dados. O protocolo utiliza a estratgia de transmisso CSMA/NDA (Oliver, 2001). A tabela 2.1 mostra as caractersticas dos dois tipos. Rede Taxa Transm. Int. Fsica J1850 VPW 10.4 kbits/s Fio simples (com terra) J1850 PWM 41.6 kbits/s Dois os, sinal balanceado Tabela 2.1: Tipos de protocolo J1850 (Riley, 1998) 8

O padro J1850 dene um conjunto de smbolos e como eles so usados para construir mensagens no barramento. Um smbolo representa uma unidade de informao. Uma lista dos smbolos denidos pode ser vista na tabela 2.2 Smbolo Descrio SOF Comeo do quadro (Start Of Frame) 0 zero lgico 1 um lgico EOD Fim dos dados (End Of Data) NB Bit de Normalizao (somente em VPW) EOF Fim do quadro (End Of Frame) IFS Separao de quadros (Inter-Frame Separation) Break Interrupo do barramento Tabela 2.2: Smbolos do protocolo J1850 (Riley, 1998) O barramento J1850 pode estar em dois estados: ativo e passivo. Nenhum destes estados unicamente usado para passar informaes. Mas o estado do barramento importante para o entendimento da denio dos vrios smbolos. O estado ativo o dominante. No mtodo de transmisso do J1850, que o CSMA/NDA, a disputa pelo barramento no-destrutiva. Mltiplos nodos podem comear a transmisso simultaneamente. A rede dene que o zero lgico dominante. Logo, mensagens que tem prioridade so denidas com identicadores menores. Consequentemente, quando vrios nodos esto transmitindo ao mesmo tempo, somente o nodo que transmitir um zero nal vencer a disputa e continuar sua transmisso. Os outros nodos vericam que perderam prioridade e interrompem seu envio (Riley, 1998). Meio fsico A rede VPW consiste de um nico o, denominado BUS+. Quando o barramento est no modo passivo, BUS+ est prximo de 0 V. Quando est ativo, a linha ca a +7 V. A rede PMW consiste em um par de os, o BUS+ e o BUS-. No modo passivo, a voltagem -5 V (medio de BUS+ em relao a BUS-). Quando ativo, a voltagem +5 V. Com relao ao terra, o barramento passivo tem BUS+ a 0 V e BUS- a 5 V, com as voltagens invertidas no barramento ativo (Riley, 1998). Protocolo Todas as comunicaes no barramento J1850, assim como a grande maioria de outros protocolos, feita atrves de quadros, ou frames. Cada frame construdo de forma semelhante: O frame comea com o smbolo SOF, seguido do bit mais signicante do primeiro byte da mensagem. O ltimo byte transmitido deste segmento um CRC (cyclic redundancy check). Por m, o smbolo EOD indica o m do segmento de dados.

Aps o envio do EOD, um ou mais nodos podem responder a mensagem. Se isto ocorrer, chamdo de In-Frame Response (IFR). Estas respostas so opcionais. Um smbolo EOF transmitido aps o IFR (se houve algum) para indicar que o frame est completo. Transmisso de um prximo frame s pode ser feita depois de um tempo determinado IFS.

2.2.2

ISO 9141-2

O padro ISO 9141, tambm conhecido como padro CARB 9141 (California Air Resources Board). Este padro era referenciado pela regulamentao da CARB que foi a precursora da lei que criou o OBD-II. Mais tarde, a CARB adotou uma verso melhorada da ISO 9141, a ISO 9141-2, com o subttulo de CARB Requirements for Interchange of Digital Information (Riley, 1998). Assim como os outros padres, este padro descreve as camadas fsicas e de ligao de dados (relativas ao modelo de rede OSI). Caractersticas As principais caractersticas da rede ISO 9141-2 so: Meio fsico: Fio duplo (sinal no balanceado) Taxa de transmisso: 10.4 kb/s Tempo de bit: 96.15 s A arquitetura da ISO 9141 se distancia do padro J1850 mencionado anteriormente e, de forma geral, da maioria das estruturas de redes existentes. Uma rede J1850 no possui um nodo central e no h o conceito de direo de sinal ou uxo. Em uma rede J1850, todos os nodos so semelhantes, pois qualquer um pode transmitir e todos recebem as mensagens. De forma semelhante, smbolos e mensagens so independentes de quem est transmitindo ou recebendo. Em uma rede compatvel com ISO 9141-2, direo do uxo de mensagem uma caracterstica importante. A especicao foi escrita levando em conta a conexo de aparelhos de medio externos a rede. A direo das mensagens e questes quanto a temporizao destas so baseadas em quem est "falando" e quem est "ouvindo". Meio fsico Um barramento ISO 9141 consiste de dois os, designados linhas K e L (K-line e L-line). A voltagem dene o estado de cada linha, podendo estar em alta (1 lgico) ou baixa voltagem (0 lgico). Diferente do J1850, as linhas K e L no tm estados ativo ou passivo. Quando um nodo est ligado, ambas as linhas so ligadas alimentao da bateria. Ambas linhas cam ociosas no estado 1. Para um nodo transmitir um 0, ele desvia a linha desejada para o terra e a mantm assim durante um tempo de bit. 10

A linha K bidirecional e compartilhada por todos os nodos assim como o equipamento de teste externo. Todos os nodos ouvem esta linha e transmitem nela. A arquitetura da linha K semelhante a um circuito lgico OU. Isto faz com que o um lgico seja o bit dominante, assim como no J1850. A linha L unidirecional, e somente o equipamento externo pode transmitir nela. Mdulos que suportam diagnstico externo tm que ouvir esta linha (Riley, 1998). Protocolo Uma rede ISO 9141 baseada no UART (Universal Asynchronous Receiver/Transmitter), que encontrado em outros padres de comunicao como o RS-232. So usados bits de incio e parada. A sinalizao de no retorno a zero. Todos os smbolos so transmitidos no tempo de bit xado. O bit de incio o 0 lgico durante um tempo de bit, enquanto o bit de parada o 1 lgico. Todas as mensagens so transmitidas em um ou mais bytes. Cada byte enviado como um pacote de bits, sendo cada byte precedido pelo bit de incio. Oito bits de dados so usados, sendo enviados na ordem do menos ao mais signicativo. O bit de parada anexado ao m. Diferentemente do J1850, no existem smbolos especiais de incio ou m do quadro. O signicado de um byte na mensagem em comparao com outro ou se uma mensagem termina e outra comea estritamente uma funo de tempo. A especicao dene janelas para todos parmetros temporais, um para cada situao. Alguns exemplos de janelas so o tempo entre bytes provindos do equipamento externo ou o tempo do m de uma mensagem do veculo at o incio da prxima mensagem do equipamento externo. Os vrios tempos so denotados como tempos W e P. Pelo menos um deles dinamico e dependente de quando o equipamento est enviando uma mensagem. O tempo W se aplica durante a fase de inicializao e o tempo P se aplica durante as outras fases. Quando um computador conecta-se a uma interface J1850 e envia uma mensagem de requisio OBD-II, como por exemplo a presso do leo (assumindo que o sistema est operando corretamente), o veculo ir responder com uma mensagem com os dados requisitados. Se isto for feito em uma rede ISO 9141-2, no conseguir obter uma resposta. Antes de um equipamento externo poder se comunicar com o computador a bordo, de acordo com a ISO 9141-2, a comunicao deve ser iniciada. A sequncia de iniciao permite que as duas partes, o equipamento externo e o computador de bordo, se reconheam um ao outro e o meio com que eles se comunicaro. Em essncia, assim acontece o bsico da iniciao: 1. O equipamento externo envia o cdigo 51 a 5 bauds em ambas as linhas K e L. Depois, a linha L desabilitada e ca ociosa. 2. Os componentes do veculo acordam se no estiverem ativos, mas somente o computador responsvel pelo diagnstico responde com o cdigo 85 taxa de 10.4 kb/s. Este o byte de sincronizao. 11

3. Todas as comunicaes agora so feitas a 10.4 kb/s. 4. O computador de bordo envia duas palavras chaves, #1 e #2, ambas valores de um byte. 5. O equipamento externo responde enviando uma inverso bit a bit da palavra #2. 6. O veculo responde enviando a inversa do comando de incializao enviada pelo equipamento no primeiro passo. 7. A partir de ento, a comunicao est estabelecida e operacional. Uma vez que a ligao esteja feita, ela deve ser mantida. Se no houver trfego no barramento por 5 segundos, cada computador assume que as comunicaes esto encerradas. A inicializao deve ser repetida para re-estabelecimento das comunicaes. O equipamento pode transmitir periodicamente uma mensagem para manter a ligao ativa (Riley, 1998).

2.2.3

ISO 14230-4

O ISO 14230-4, tambm conhecido como KWP2000 (Keyword Protocol 2000), uma extenso do ISO 9141-2, compartilhando o mesmo meio fsico e outras caractersticas, sendo a principal diferena a capacidade de enviar mensagens muito maiores, 260 bytes no mximo ao contrrio de 11 bytes do protocolo 9141-2 (Dzhelekarski and Alexiev, 2005b). Assim como o 9141-2, usado principalmente na Europa e sia.

2.2.4

Low-speed CAN (Controller Area Network)

O CAN est se tornando o protocolo padro para comunicao entre os componentes eletrnicos nos veculos, j existindo norma norte-americana tornando obrigatria sua aplicao. Histria e aplicaes O Controller Area Network um barramento de comunicaes serial voltado para aplicaes de controle em tempo real; operando a uma taxa de at 1 Mbps, com excelente deteco de erro e recursos de connamento. O CAN foi originalmente desenvolvido por uma empresa alem automobilstica, a Robert Bosch, com o intuito de prover um barramento de comunicao a um custo efetivo para componentes eletrnicos nos veculos e como uma alternativa aos emaranhados de os e conectores que eram caros e no conveis. A indstria automobilstica continua usando o CAN em um crescente nmero de aplicaes, mas pela sua robustez e conabilidade, CAN est tambm sendo usado em muitas outras aplicaes. Este um padro aberto, documentado na ISO 11898 (para aplicaes em alta velocidade) e na ISO 11519 (para conexes em baixa velocidade) (Kvaser AB, 2009; Pazul, 1999; Schoeld, 1996).

12

Diversos controladores CAN e dispositivos de interface esto disponveis venda por muitos dos principais manufaturadores de semicondutores. Existe tambm uma innidade de pacotes de desenvolvimento de sistemas baseados em CAN, placas de interface e kits de desenvolvimento de sistemas (SDKs) que provm as ferramentas necessrias para construir, monitorar, testar e analisar sistemas baseados em CAN. Consequentemente, a maioria dos automveis hoje na Europa, e cada vez mais no resto do mundo, j usam a tecnologia CAN em seus sistemas (Schoeld, 1996). Controladores e interfaces CAN so sicamente pequenos, operando em altas velocidades e em ambientes hostis. Estas propriedades levaram o CAN a ser usado em muitas outras aplicaes alm da automobilstica. Alguns exemplos: Sistemas de controle e navegao naval Sistemas de controle de elevadores Mquinas agrcolas Equipamentos mdicos Meio fsico O CAN usa codicao sem retorno a zero (NRZ) e com bit-stufng (tcnica para diferenciar sequncia de bits de delimitadores) para transmisso de dados em um barramento diferencial em dois os. O uso da codicao NRZ garante mensagens compactas e com alta resistncia a interferncias externas. O barramento em o duplo normalmente feito em par tranado. Par simples tambm pode ser usado mas mais suscetvel a interferncia. Uma das caractersticas do CAN que reforam sua conabilidade uma recomendao da ISO 11898 que recomenda que os chips de interface do barramento sejam feitos de tal forma que a comunicao possa continuar (mas com uma reduzida relao sinal-rudo) mesmo que: Qualquer um dos os do barramento se rompa Qualquer um dos os esteja em curto na fonte Qualquer um dos os esteja em curto no terra Protocolo Um dos princpios do CAN que mensagens transmitidas de qualquer nodo no barramento no contm nenhum endereo, nem de remetente e nem de destino. Ao invs disso, o contedo da mensagem identicado por um identicador que nico atravs da rede. Todos os nodos na rede recebem a mensagem e cada um verica o identicador nico para determinar se o contedo da mensagem de seu interesse. Se a mensagem for de interesse, ela processada; caso contrrio ela ignorada.

13

Esta orientao a contedo das mensagens do CAN tem como consequncia um alto grau de exibilidade na congurao do sistema. Novos nodos que so puramente receptores podem ser adicionados a rede sem necessidade de maiores mudanas ao software e hardware existentes. Para delegao do envio de mensagem, o CAN usa o mtodo conhecido como CSMA/CD, mas com a melhoria de que a deteco de coliso no interrompe o envio da mensagem prioritria. A prioridade da mensagem determinada pelo valor numrico do seu identicador. Este valor denido durante a fase inicial do desenvolvimento do sistema. O identicador com o valor numrico mais baixo tem a maior prioridade. Isto acontece pelo comportamento do barramento, que funciona como uma porta lgica AND, ou seja, enquanto algum nodo transmitir o valor lgico zero, o barramento ter este valor. No momento que o canal est disponvel, os nodos que querem transmitir comeam a transmisso do seu identicador, monitorando o barramento ao mesmo tempo. No momento em que ele envia o valor 1 mas o barramento continua 0, signica que outro nodo est transmitindo uma mensagem prioritria (valor do identicador menor), logo este nodo interrompe sua transmisso, enquanto o nodo prioritrio no precisa interromper sua transmisso. Esta estratgia oferece maior aproveitamento do barramento, baseado na necessidade dos nodos, no havendo interrupes de transmisso por coliso, o que no pode ser conseguido atravs de protocolos de tempo xo como o Token Ring e nem com barramentos de alocao destrutiva como o Ethernet. Mas cuidado deve ser tomado no desenvolvimento da rede, pois nodos prioritrios em excesso podem tomar a rede e no dar chance aos nodos menos prioritrios. Com este comportamento, o CAN permite, por exemplo, que parmetros que mudam mais frequentemente como as rotaes por minuto (RPM) do motor tenham prioridade sobre valores que mudam menos frequentemente, como a temperatura do motor. Em um sistema CAN, assim como em outros procolos de rede, as mensagens so transmitidas em quadros de dados (Message Frames), que contm os dados sendo transmitidos por um nodo, alm de dados de controle e checagem de erro. A ltima especicao do CAN denem duas verses, a verso 2.0A denominada o CAN padro (Standard CAN) e a verso 2.0B, o CAN estendido (Extended CAN). Um esquema do formato do quadro usado pelo CAN 2.0A pode ser visto na gura 2.2. O quadro de dados do CAN padro consiste de sete campos de bits: Start of Frame (SOF): Indica o incio do quadro. nico bit de valor zero. Arbitration eld: O identicador nico, com 11 bits, mais um bit conhecido como Remote Transmission Request (RTR) bit. Este bit serve para diferenciar entre um quadro de envio de dados e um quadro de requisio. Control Field: Contm 6 bits, sendo os 2 primeiros bits reservados para uso futuro e os outros 4 bits so o Data Length Code (DLC) que indica o tamanho em bytes do prximo campo, o Data eld. Data eld: Os dados sendo enviados, podendo conter de 0 a 8 bytes.

14

Figura 2.2: Quadro de dados do protocolo CAN 2.0A CRC eld: Contm um cdigo de vericao de redundncia cclica em 15 bits para vericao de erros no Data eld e mais um bit delimitador. ACKnowledge eld: Campo usado para conrmao de recebimento pelos outros nodos. O primeiro bit enviado como recessivo no barramento mas logo sobrescrito por bit dominante pelos outros nodos para conrmar o recebimento. O outro bit um delimitador recessivo. End of frame eld: ltimo campo, consistindo de 7 bits recessivos, indica o m do quadro. O quadro de dados do CAN 2.0B pode ser visto na gura 2.3. O CAN 2.0B foi criado para prover compatibilidade com outras comunicaes seriais. Para continuar compatvel com o padro 2.0A, o quadro de dados tomou uma forma estendida do quadro 2.0A. As diferenas esto no Arbitration eld: Existem agora 2 identicadores. Um de 11 bits como no 2.0A e outro com 18 bits, formando o total de 29 bits para identicao. Entre estes campos, 2 bits so inseridos. O Substitute Remote Request (SRR) um bit recessivo de forma que mensagens 2.0A que contenham o mesmo identicador de 11 bits tenham prioridade sobre as mensagens 2.0B. O Identier Extension (IDE) o bit que identica uma mensagem 2.0B.

Figura 2.3: Quadro de dados do protocolo CAN 2.0B A maioria dos controladores 2.0A transmitem e recebem somente mensagens de seu formato, mas alguns, conhecidos como 2.0B passivos, recebem mas igno15

ram mensagens 2.0B, possibilitando o funcionamento em conjunto com dispositivos 2.0B. Sincronizao e tempo de bit No existe um sinal de clock para sincronizao dos nodos em uma rede CAN. Ainda assim, este um protocolo que trabalha de forma sncrona. O tempo de transmisso de cada bit controlado internamente em cada nodo. Cada nodo em uma rede CAN deve possuir um oscilador e uma taxa chamada Baud Rate Prescaler (BRP) que programada no momento da instalao do nodo. A taxa do oscilador e o BRP multiplicados resultam numa unidade chamada time quanta. O tempo de bit no CAN dividido em quatro segmentos de tempo, cada qual com seus valores em time quanta: 1. Sync-seg: Segmento para sincronia dos nodos no barramento. (1 time quanta) 2. Prop-Seg: Tempo para compensao de atrasos fsicos. (1 a 8 time quantas) 3. Phase-seg1: um segmento de buffer, que pode ser aumentado para ressincronizao para compensar diferenas positivas na fase dos osciladores. (1 a 8 time quantas) 4. Phase-seg2: um segmento de buffer, que pode ser diminudo para ressincronizao para compensar diferenas negativas na fase dos osciladores. (Igual a Phase-seg1) A sincronia dos sinais ocorre durante a transmisso de cada bit, quando vericado o tempo onde houve a mudana de sinal em Sync-seg. Dependendo do atraso que ocorre, Phase-seg1 e Phase-seg2 so alterados pelos nodos para a sincronia dos sinais.

2.3

Classe C

Para aplicaes que necessitam de comunicao em tempo-real e alta velocidade. Utilizadas principalmente nos primeiros dois domnios. Redes classe C como o CAN de alta velocidade (high-speed CAN) operam na faixa de 125kb/s a 1Mb/s.

2.3.1

High-speed CAN

O protocolo CAN suporta taxas de transmisso entre 40Kbps (Classe B) e 1Mbps (Classe C) dependendo do meio fsico e da distncia entre os nodos. O protocolo funciona de forma semelhante, mudando somente a taxa de transmisso. Desta forma o protocolo pode ser usado transparentemente em ambas as classes (Pazul, 1999; Schoeld, 1996).

16

2.3.2

TTP/C

TTP/C um protocolo determinstico desenvolvido pela Universidade de Vienna, derivado de dois projetos desta univerdade (X-by-write e TTA). Desde a concluso de tais projetos, a especicao do protocolo foi transferida para a empresa TTTech (controlada por um consrcio de outras empresas com a Volkswagen, Audi e Honeywell) (Kopetz and Grunstidl, 1993). TTP/C baseado em intervalos de tempo (TDMA), ao contrrio do CAN, que baseado em eventos (CSMA). Cada nodo sincronizado por um clock comum. Todas transmisses so feitas em pontos especcos de tempo, denidos na fase de especicao do sistema. Como o TTP/C um protocolo TDMA, a latncia determinstica. Nenhum nodo pode monopolizar o meio de comunicao alm do seu intervalo de tempo (TTA Group, 2004).

2.4

Classe D

Estas redes operam em velocidades acima de 1Mbps e so utilizadas para aplicaes multimdia. Exemplos so MOST e FlexRay.

2.4.1

MOST

MOST uma rede orientada a funcionalidades, multimdia e de alta velocidade. O protocolo dene mecanismos para envio tanto de dados em pacotes como em uxos (streaming), alm de prover um completo framework de aplicao para controlar a interao entre os componentes da rede de forma estruturada. MOST suporta tambm diferentes taxas de velocidade e meios fsicos (MOST Cooperation, 2008). Uma rede MOST consiste de at 64 nodos. uma rede sncrona (TDMA), onde h um nodo mestre responsvel pela sincronizao dos demais. Desta forma, a banda alocada para conexes de streaming est sempre disponvel e reservada para que no haja interrupes, colises ou atrasos no envio dos dados, possibilitando alta qualidade de servio e eciente transmisso de udio e vdeo. Trfego da Internet ou informao de sistemas de navegao so tipicamente enviados em pacotes assncronos, e distribudos para diferentes nodos. Para suportar tais sinais, MOST dene ecientes mecanismos para o envio e tratamento de tais pacotes alm dos dados de controle e streaming. Porm, o envio destes dados se d de forma separada dos dados de streaming, de forma que no haja interferncia entre eles. Em suma, MOST uma rede designada para transportar os diversos tipos de dados e sinais que tem origem em sistemas multimdia e de entretenimento.

2.4.2

FlexRay

Flexray um protocolo de comunicao em tempo real composto de partes estticas e dinmicas. Baseado em uma forma estendida de TDMA, o ciclo de comunicao deve ser denido juntamente com sua durao quando a rede congurada. Este

17

elemento fundamental do esquema de acesso mdia consiste de um segmento esttico mandatrio, um segmento dinmico opcional e dois segmentos de protocolo chamados janela de smbolos (symbol window, responsvel pelo envio de mensagens de sistema especiais como emphwake-up e emphstartup.), tambm opcional, seguidos de um tempo de inatividade mandatrio que marca o m do envio de dados (FlexRay Consortium, 2005). Na gura 2.4 podemos ver um esquema do ciclo de comunicao.

Figura 2.4: Ciclo de comunicao do protocolo FlexRay No segmento esttico, o tempo determinstico de comunicao responsvel por requisitos importantes como a latncia, utilizando TDMA com intervalos de tempo de mesmo tamanho, com cada ECU possuindo seu intervalo de tempo exclusivo, certicando-se da transmisso de seus dados sem interrupes. No segmento dinmico onde comunicaes baseadas em eventos so feitas. A estratgia usada uma extenso do TDMA, denominada FTDMA (FlexRay timedivision multiple access), criando um padro de acesso por demanda ainda baseado em tempo para comunicaes dinmicas. A estratgia baseada em miniintervalos de tempo, que basicamente do a chance de algum ECU requisitar um envio. Quando h uma requisio, um mini-intervalo expandido para um intervalo padro para uso do ECU. Caso contrrio, mini-intervalos continuam sendo enviados.

18

Captulo 3 Aquisio de dados

O bsico de um sistema de telemetria a aquisio dos dados. Felizmente os carros hoje possuem diversas ECUs que fazem medies dos parmetros funcionais do veculo. Estas unidades eletrnicas formam o que se chama de sistema de diagnstico a bordo (On-board diagnostics, mais conhecido pela sigla OBD).

3.1

OBD

A sigla OBD vem sido usada h muito tempo, quando comearam a surgir equipamentos de diagnsticos em veculos. Os primeiros sistemas consistiam somente de uma luz indicadora de problema no motor ou painel (MIL - Malfunction indicator light) quando um problema era detectado. Implementaes mais modernas de OBDs usam uma porta padro de comunicao digital para prover informaes em tempo real sobre o funcionamento do veculo. H tambm cdigos padronizados de diagnstico de problemas (DTC - diagnostic trouble codes) que permitem que problemas sejam detectados e resolvidos rapidamente. Um outro motivador para a implantao de um sistema OBD padronizado, como ser observado a seguir, a medio de emisso de poluentes do carro. Um sistema de medio padro torna muito mais fcil e convel a medio da emisso dos veculos.

3.1.1

Histria

1975: Computadores embarcados comeam a aparecer nos veculos civis com o Datsun 280z, motivado principalmente pela necessidade de ajuste em tempo real de sistemas de injeo eletrnica. Com isso, comeam a aparecer as primeiras implementaes de OBD, mas sem um padro denido do qu e como feita a monitorao. 1980: A General Motors implementa um protocolo proprietrio chamado ALDL, que se comunica a 160 baud e monitora poucos sistemas do veculo. 1986: Uma verso melhorada do ALDL criada, que se comunica a 8192 bauds. O protocolo denido no padro GM XDE-5024B. 19

 1987: A California Air Resources Board - CARB, agncia do estado norteamericano que dene polticas em prol da preservao da qualidade do ar, ergue uma norma de que todos os veculos vendidos no estado a partir de 1988 tenham um sistema bsico OBD implantado. No foi denido um padro para conexo nem protocolo de dados. 1988: A sociedade de engenheiros automotivos SAE (Society of Automotive Engineers) recomenda um padro para conectores e sinais de diagnstico (Padro hoje conhecido como OBD-I). 1994: A CARB lana a especicao OBD-II e ergue a norma de que deve ser adotado em todos os carros vendidos na Califrnia a partir de 1996. Os conectores e protocolos sugeridos pela SAE so incorporados nesta especicao. 1996: O OBD-II se torna mandatrio em todos os carros vendidos nos Estados Unidos. 2001: A Unio Europeia especica o EOBD (padro baseado no OBD-II) para todos os veculos vendidos na Unio Europeia. 2004: O Conselho Nacional do Meio Ambiente U CONAMA, inspirado nas normas internacionais estabelecidas, lana a resoluo 354 de 13 de dezembro de 2004, que dene o OBDBr-1 e OBDBr-2, sistema OBD a ser implantado nos veculos brasileiros. A resoluo se apoia nas normas internacionais j publicadas para o conector e dene quais as medies que devero ser feitas em cada verso. 2007: 40% dos carros brasileiros devem implantar o OBDBr-1. 2008: A partir deste ano, todos os carros vendidos nos Estados Unidos devem implentar o padro de sinalizao ISO 15765-4 (baseado no protocolo CAN Controller Area Network). 2009: 100% dos carros brasileiros devem implantar o OBDBr-1.

3.1.2

Padres OBDBr-1 e OBDBr-2

A CONAMA, com a resoluo 354 de 13 de dezembro de 2004, deniu o padro de sistemas de diagnose para os veculos brasileiros. O padro foi baseado no j existente e implantado OBD-II. A principal tarefa da resoluo foi denir os parmetros a serem medidos e prazo para implantao pelas montadoras (CONAMA, 2006). Parmetros do OBDBr-1, implantando em 40% dos automveis em 2007, 60% em 2008 e 100% em 2009: Sensor Presso Absoluta ou Fluxo de Ar Sensor Posio da Borboleta Sensor de Temperatura de Arrefecimento Sensor Temperatura de Ar 20

 Sensor Oxignio (somente o sensor pr-catalisador) Sensor de Velocidade do Veculo Sensor de Posio do Eixo Comando de Vlvulas Sensor de Posio do Virabrequim Sistemas de Re-circulao dos Gases de Escape (EGR) Sensor para Deteco de Detonao Vlvulas Injetoras Sistema de Ignio Mdulo Controle Eletrnico do motor Lmpada Indicadora de Mau Funcionamento (LIM) Outros componentes que o fabricante julgue relevantes para a correta avaliao do funcionamento do veculo e controle de emisses de poluentes. Complementarmente s funes e caractersticas do Sistema OBDBr-1, o sistema OBDBr-2 deve detectar e registrar a existncia de falhas de combusto, deteriorao do(s) sensor(es) de oxignio primrio(s) e ecincia de converso do catalisador que acarretem aumento de emisses, tambm apresentar caractersticas mnimas para a deteco de falhas nos seguintes componentes: Sensores de Oxignio (pr e ps-catalisador) Vlvula de Controle da Purga do Cnister O sistema OBDBr-2 comear a ser implantando em 2010.

3.1.3

Padro OBD-II

O padro difundido para quase a totalidade dos veculos para monitoramento e diagnstico eletrnico o OBD-II. Este padro dene um conector de diagnstico padro e sua pinagem, os protocolos de sinalizao disponveis e o formato das mensagens. H tambm a denio de alguns parmetros que devem ser monitorados e como devem ser codicados, alm dos cdigos de deteco de problemas, os DTCs. Graas a este padro, possvel a construo de dispositivos que sejam capazes de diagnosticar qualquer veculo que o implemente. Conector OBD-II A padro OBD-II especica uma interface de hardware - o conector fmea de 16 pinos (2x8) J1962 (Dzhelekarski and Alexiev, 2005a). Este conector deve aparecer no compartimento de passageiros, perto do console central do veculo, do lado do motorista. A especicao do J1962 feita pela SAE dene as pinagens do conector como:

21

Figura 3.1: Esquema do conector OBD-II 1. 2. Linha de barramento positiva do SAE-J1850 3. Ford DCL positivo 4. Terra da bateria 5. Terra de sinal 6. CAN alta voltagem (ISO 15765-4, SAE J2284) 7. Linha K dos ISO 9141-2, 14230-4 8. 9. 10. Negativo do SAE J1850 11. Ford DCL negativo 12. 13. 14. CAN baixa voltagem 15. Linha L dos ISO 9141-2, 14230-4 16. Alimentao da bateria A implementao dos pinos no especicados est a critrio do fabricante. Protocolos Cinco protocolos so denidos no padro OBD-II, como pode ser notado pela pinagem. Um veculo normalmente implementa somente um deles. Estes protocolos eram e ainda so os mais usados na poca da denio do padro. Logo, o dispositivo que zer a leitura dos dados deve estar preparado para lidar com todos os 5 protocolos se deseja ser totalmente compatvel com OBD-II (Dzhelekarski and Alexiev, 2005b). SAE J1850 PWM 22

 SAE J1850 VPW ISO 9141-2 ISO 14230 KWP2000 (Keyword Protocol 2000) ISO 15765 CAN (Controller Area Network) Estes protocolos so abordados com mais detalhes na seo 2.2. Interface OBD x computador J existem diversas interfaces implementadas para conexo do OBD-II com computadores. Normalmente esta conexo feita pela porta serial RS-232, ou, mais recentemente, a USB. A empresa ELM electronics criou o que hoje conhecido como o estado da arte na interface de computadores com o OBD: O chip ELM 327 (ELM Electronics, 2009). Com este chip conectado a uma interface serial, possvel acessar dados OBD de forma padronizada, sem diferenas no protocolo implementado pelo carro. O chip responsvel por interpretar o protocolo utilizado pelo carro e transformar os dados. A comunicao com o ELM 327 feita atravs de comandos AT, semelhante a um modem, o que facilita a implementao de sistemas para recuperao dos dados necessrios. Hoje j existem verses semelhantes inspiradas no ELM 327, implementando o mesmo padro, de design aberto e fcil construo. Por isto este ser o modelo de conector usado no projeto. Um dos modelos mostrado abaixo, criado por Alex Sidorenko, que disponibilizou o circuito, as peas e o rmware para o microcontrolador PIC18F2455 em seu website (Sidorenko, 2009).

Figura 3.2: Interface OBD x USB de Alex Sidorenko

Dados mensurados O padro OBD denido pela SAE estabelece os dados que podem ser disponibilizados pela porta OBD aos equipamentos de diagnstico. A tabela 3.1 mostra uma lista dos dados, seus cdigos identicadores (PID - Parameter ID) que so utilizados pelas ferramentas de diagnstico para fazer a consulta, nmero de bytes e a unidade de medida que representam. 23

Figura 3.3: Esquema eltrico da interface OBD x USB de Alex Sidorenko

24

Tabela 3.1: Dados OBD-II PID 0 1 2 3 4 5 6 7 8 9 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 Bytes 4 4 8 2 1 1 1 1 1 1 1 1 2 1 1 1 2 1 1 1 2 2 2 2 2 2 2 2 1 1 1 2 4 2 2 2 4 4 4 4 4 Descrio Unidade PIDs supported [01 - 20] Monitor status since DTCs cleared. Freeze DTC Fuel system status Calculated engine load value % Engine coolant temperature C Short term fuel % trim Bank 1 % Long term fuel % trim Bank 1 % Short term fuel % trim Bank 2 % Long term fuel % trim Bank 2 % Fuel pressure kPa (gauge) Intake manifold absolute pressure kPa (absolute) Engine RPM rpm Vehicle speed km/h Timing advance relative to #1 cylinder Intake air temperature C MAF air ow rate g/s Throttle position % Commanded secondary air status Oxygen sensors present Bank 1 Sensor 1: Oxygen sensor Volts % Bank 1 Sensor 2: Oxygen sensor Volts % Bank 1 Sensor 3: Oxygen sensor Volts % Bank 1 Sensor 4: Oxygen sensor Volts % Bank 2 Sensor 1: Oxygen sensor Volts % Bank 2 Sensor 2: Oxygen sensor Volts % Bank 2 Sensor 3: Oxygen sensor Volts % Bank 2 Sensor 4: Oxygen sensor Volts % OBD standards this vehicle conforms to Oxygen sensors present Auxiliary input status Run time since engine start seconds PIDs supported 21-40 Distance traveled with MIL on km Fuel Rail Pressure (relative to manifold vacuum) kPa Fuel Rail Pressure (diesel) kPa (gauge) O2S1_WR_lambda(1): Equivalence Ratio Voltage N/A V O2S2_WR_lambda(1): Equivalence Ratio Voltage N/A V O2S3_WR_lambda(1): Equivalence Ratio Voltage N/A V O2S4_WR_lambda(1): Equivalence Ratio Voltage N/A V O2S5_WR_lambda(1): Equivalence Ratio Voltage N/A V Continua na prxima pgina. . .

25

PID 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 51 52 100 101

Tabela 3.1 continuao Bytes Descrio Unidade 4 O2S6_WR_lambda(1): Equivalence Ratio Voltage N/A V 4 O2S7_WR_lambda(1): Equivalence Ratio Voltage N/A V 4 O2S8_WR_lambda(1): Equivalence Ratio Voltage N/A V 1 Commanded EGR % 1 EGR Error % 1 Commanded evaporative purge % 1 Fuel Level Input % 1 # of warm-ups since codes cleared N/A 2 Distance traveled since codes cleared km 2 Evap. System Vapor Pressure Pa 1 Barometric pressure kPa (Absolute) 4 O2S1_WR_lambda(1): Equivalence Ratio Current N/A mA 4 O2S2_WR_lambda(1): Equivalence Ratio Current N/A mA 4 O2S3_WR_lambda(1): Equivalence Ratio Current N/A mA 4 O2S4_WR_lambda(1): Equivalence Ratio Current N/A mA 4 O2S5_WR_lambda(1): Equivalence Ratio Current N/A mA 4 O2S6_WR_lambda(1): Equivalence Ratio Current N/A mA 4 O2S7_WR_lambda(1): Equivalence Ratio Current N/A mA 4 O2S8_WR_lambda(1): Equivalence Ratio Current N/A mA 2 Catalyst Temperature Bank 1 Sensor 1 C C 2 Catalyst Temperature Bank 2 Sensor 1 2 Catalyst Temperature Bank 1 Sensor 2 C 2 Catalyst Temperature Bank 2 Sensor 2 C 4 PIDs supported 41-60 4 Monitor status this drive cycle 2 Control module voltage V 2 Absolute load value % 2 Command equivalence ratio N/A 1 Relative throttle position % 1 Ambient air temperature C 1 Absolute throttle position B % 1 Absolute throttle position C % 1 Accelerator pedal position D % 1 Accelerator pedal position E % 1 Accelerator pedal position F % 1 Commanded throttle actuator % 2 Time run with MIL on minutes 2 Time since trouble codes cleared minutes 1 Fuel Type 1 Ethanol fuel% % OBD Monitor IDs supported (0120) O2 Sensor Monitor Bank 1 Sensor 1 Volts Continua na prxima pgina. . . 26

Tabela 3.1 continuao PID Bytes Descrio 102 O2 Sensor Monitor Bank 1 Sensor 2 103 O2 Sensor Monitor Bank 1 Sensor 3 104 O2 Sensor Monitor Bank 1 Sensor 4 105 O2 Sensor Monitor Bank 2 Sensor 1 106 O2 Sensor Monitor Bank 2 Sensor 2 107 O2 Sensor Monitor Bank 2 Sensor 3 108 O2 Sensor Monitor Bank 2 Sensor 4 109 O2 Sensor Monitor Bank 3 Sensor 1 010A O2 Sensor Monitor Bank 3 Sensor 2 010B O2 Sensor Monitor Bank 3 Sensor 3 010C O2 Sensor Monitor Bank 3 Sensor 4 010D O2 Sensor Monitor Bank 4 Sensor 1 010E O2 Sensor Monitor Bank 4 Sensor 2 010F O2 Sensor Monitor Bank 4 Sensor 3 110 O2 Sensor Monitor Bank 4 Sensor 4 201 O2 Sensor Monitor Bank 1 Sensor 1 202 O2 Sensor Monitor Bank 1 Sensor 2 203 O2 Sensor Monitor Bank 1 Sensor 3 204 O2 Sensor Monitor Bank 1 Sensor 4 205 O2 Sensor Monitor Bank 2 Sensor 1 206 O2 Sensor Monitor Bank 2 Sensor 2 207 O2 Sensor Monitor Bank 2 Sensor 3 208 O2 Sensor Monitor Bank 2 Sensor 4 209 O2 Sensor Monitor Bank 3 Sensor 1 020A O2 Sensor Monitor Bank 3 Sensor 2 020B O2 Sensor Monitor Bank 3 Sensor 3 020C O2 Sensor Monitor Bank 3 Sensor 4 020D O2 Sensor Monitor Bank 4 Sensor 1 020E O2 Sensor Monitor Bank 4 Sensor 2 020F O2 Sensor Monitor Bank 4 Sensor 3 210 O2 Sensor Monitor Bank 4 Sensor 4 0 4 mode 9 supported PIDs 01 to 20 2 5x5 Vehicle identication number (VIN) 4 varies calibration ID

Unidade Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts Volts

27

Captulo 4 Telefonia mvel

Com o avano da tecnologia de telefonia mvel, cada vez mais os aparelhos portteis cam poderosos, portando sistemas computacionais complexos e capacidades de conectividade cada vez mais rpidas e simples, assim como cresce os recursos eletrnicos nos automveis. Mas ainda existe uma lacuna a ser preenchida que a integrao desses dois mundos, criando recursos e facilidades para o usurio do veculo e de tecnologias mveis. Estudos para a criao de aparelhos de transmisso e recepo por clulas, os aparelhos celulares, comearam a ser feitos em meados de 1950. Antes, a telefonia dependia de conexo direta cabeada dos aparelhos at uma central de comunicao. Coincidentemente, a ideia inicial do uso desta forma de comunicao era para o uso em automveis. A primeira rede de telefonia celular era conhecida como AMPS (Advanced Mobile Phone Server) e foi lanada em 1983. Logo em 1987, estas redes comearam a apresentar grande demanda e consequentemente, congestionamento. Para aumentar a ecincia do servio, novas tecnologias foram implantadas, com o TDMA (Time Division Multiple Access), CDMA (Code Division Multiple Access) e GSM (Global System for Mobile Communications). O fenmeno da tecnologia de telefonia mvel impactou o mundo como poucas tecnologias modernas conseguiram. Hoje, cerca de 81% da populao brasileira possui celular (Anatel, 2009). Por j estar profundamente inserida no cotidiano das pessoas, a telefonia celular tem sido uma plataforma constantemente visada para integrao de servios e recursos. Os bancos, por exemplo, disponibilizam mensagens aos clientes com conrmaes de movimentaes, sistemas para controle da conta por telefone celular, entre outros recursos. Nada mais bvio para um sistema embarcado automotivo tambm fazer uso desta tecnologia, utilizando-a tanto como meio de comunicao como meio de interao com seu proprietrio.

4.1

GSM

Muitos protocolos e padres surgiram durante a criao da telefonia celular, mas nenhum conseguiu a ampla aceitao que hoje tem o GSM, sendo usado em cerca de 80% das operadoras de telefonia celular do mundo (GSM Association, 2009). 28

O GSM foi criado na Europa em 1990, onde antes cada pas tinha o seu prprio sistema analgico de telefonia celular, impedindo a compatibilidade entre as redes e seus aparelhos. A ideia do novo padro era prover interconexo no s entre as redes de diferentes pases, mas prover integrao com outros sistemas. Por isso o padro analgico foi abandonado em favor do padro digital. Esta caracterstica possibilitou a construo de recursos digitais com o SMS e o GPRS (Scourias, 1997).

4.1.1

SMS

Com o SMS (Short Message System), usurios de redes GSM podem trocar mensagens alfanumricas de at 160 caracteres. As mensagens podem ser trocadas entre redes, em qualquer lugar do mundo, e so recebidas em segundos. A idia original era ser um simples sistema de noticao a usurios de uso da operadora, como avisos de recados na caixa de mensagens, mas acabou tornando-se extremamente popular e usado pela maioria dos usurio de telefonia mvel (Peersman and Cvetkovic, 2000). A popularidade do SMS se deve ao fato de que pode ser transmitida a qualquer momento, mesmo quando o destinatrio est indisponvel para a recepo. A operadora espera at o aparelho de destino estiver ligado e em rea de cobertura para fazer o envio. Assim como um e-mail, a mensagem quando enviada ca guardada no destino e pode ser acessada a qualquer momento. Vrios sistemas j fazem uso de SMS em seus servios. Operadoras de carto de crdito enviam conrmaes de compra por SMS, lojas online noticam usurios quando suas compras so enviadas ou quando h algum problema na cobrana, entre muitos outros usos. O SMS implementado em uma rede GSM atravs do uso de MSC (Message Service Center). Seu funcionamento semelhante a uma caixa de correio eletrnico, onde as mensagens so organizadas por destinatrio e so remetidas para a rede de destino. Um exemplo de rede GSM com servidores MSC pode ser vista na gura 4.1.

4.1.2

GPRS

O GPRS (General packet radio service) um protocolo que foi incorporado ao GSM para prover servio de transmisso de pacotes. O GPRS possibilita que aparelhos da rede GSM interajam com outras redes digitais, mais notavelmente a Internet. A taxa de transmisso entre 56 e 114 kbps (Scourias, 1997). Este servio aumentou exponencialmente a quantidade de recursos disponveis nos aparelhos celulares. Telefones agora acessam pginas de Internet, atualizamse e carregam contedos como msicas, jogos, vdeos e imagens. A arquitetura GPRS funciona sobre a GSM, adicionando novos ns na rede chamados GSN (GPRS Support Node) que fazem o roteamento dos pacotes de dados entre as redes interna e externa, de forma muito semelhante arquitetura SMS. Podemos ver esta arquitetura ilustrada, juntamente com a arquitetura SMS, na gura 4.1. Os principais elementos mostrados so: MS (Mobile Station): O dispositivo mvel sendo conectado. 29

Figura 4.1: Uma rede GSM com ns SMS e GPRS (Junior, 2005) BTS (Base Transceiver Station): Transceptores e antenas, responsveis pela transmisso dos sinais de rdio com o MS. BSC (Base Station Controller): Estao de controle das BTS. SGSN (Serving GPRS Support Node): Responsvel pela localizao do dispositivo mvel e roteamento dos pacotes. GGSN (Gateway GPRS Support Node): Interface com outras redes digitais, como a Internet.

4.1.3

EDGE e UMTS

Estas tecnologias so evolues do GPRS. Foram desenvolvidas com a principal nalidade de prover maior taxa de transmisso de dados. O EDGE (Enhanced Data rates for GSM Evolution) prov taxas de transmisso que variam entre 236,8 e 473,6 kbps, quatro vezes maior que o GPRS. O EDGE, tambm chamado de EGPRS (Enhanced GPRS), trabalha de forma similar ao GPRS, podendo coexistir em uma mesma rede. Os GSN devem ser atualizados para incorporar as novas tecnologias de transmisso adotadas pelo EDGE, mas as diferenas se encerram aqui. Logo, a rede pode ser atualizada gradualmente, sem impacto no servio j existente. A tecnologia UMTS (Universal Mobile Telecommunications System), que faz parte das evolues do GSM denominadas 3G (terceira gerao), promete tericos 21 Mbps, mas por enquanto suas implementaes suportam at 7.2 Mbps. A 30

Figura 4.2: Placa PCMCIA da VIVO para acesso a rede GSM 3G migrao para este padro no to transparente quanto a EDGE, necessitando a troca de vrias camadas de comunicao da rede, mas ainda assim os dois modos de transmisso ainda podem coexistir (Richardson, 2000).

4.1.4

Acesso Internet Mvel

A evoluo das tecnologias mveis foi cada vez mais aproximando os aparelhos celulares da Internet. Era s uma questo de tempo at que os aparelhos celulares comeassem a ser usados como porta de entrada a Internet por computadores portteis. No comeo era necessrio o uso de um telefone celular conectado ao computador para acesso Internet. Este acesso era complicado, dependendo de drivers especcos para o telefone e sistema operacional em uso (Junior, 2005). Hoje j esto difundidos aparelhos especcos para esta ligao, os chamados Modens 3G. So aparelho celulares simplicados, com baixo consumo de energia, podendo ser energizados pela porta USB ou interface PCMCIA. Notebooks j esto sendo construdos com esta interface embutida, facilitando ainda mais o acesso. Nas guras 4.2 e 4.3 temos exemplos de equipamentos voltados para este acesso. Este tipo de acesso permite, alm de conexo Internet, tambm o envio de SMS. Estas caractersticas satisfazem as exigncias do sistema de telemetria quanto a telecomunicaes. Considerando a disponibilidade de conexo USB na Beagle Board (Seo 2.2) , esta ser a interface usada para o projeto.

31

Figura 4.3: Interface USB GSM 3G.

32

Captulo 5 Arquitetura do Sistema

Para o desenvolvimento do sistema, necessrio denir sua arquitetura. O projeto Karmonitor dene a plataforma para desenvolvimento dos sistemas embarcados.

5.1

Hardware

Por se tratar de um sistema embarcado de alta complexidade, um hardware poderoso e ao mesmo tempo porttil deve ser usado. A proposta do projeto Karmonitor especicar e construir um hardware customizado que ser o computador a bordo do veculo. Mas como prottipo, a equipe do projeto Karmonitor deniu como plataforma inicial de desenvolvimento do sistema uma placa de design aberto, expansvel, de alta performance e baixo custo que est acolhendo uma crescente comunidade de desenvolvedores interessados, a Beagle Board. A Beagle Board possui um processador ARM da Texas Instrument, o OMAP3530, capaz de rodar a 600MHz com um cache L2 de 256kb e memria RAM de 256Mb. Possui somente funcionalidades de udio e vdeo integrados. O poder da Beagle Board est justamente na sua falta de componentes integrados, que compensada pela sua alta expansibilidade. Possui interface USB, MMC+/SD/SDIO, RS-232 e J-TAG. J existem diversos perifricos testados para expandir as funcionalidades da Beagle Board. Outra caracterstica importante o baixo consumo de energia, podendo ser alimentada pela porta USB ou por uma fonte DC de 5v, o que facilita sua instalao em um veculo.

5.2

Sistema Operacional

O sistema operacional que ser usado na Beagle Board ser uma distribuio de Linux para sistemas embarcados. A escolha deve-se a diversos motivos. Um o fato de ser o sistema operacional mais utilizado em conjunto com a Beagle Board. Logo, j possui amplo suporte e documentao provido pela comunidade. Por ser um sistema de cdigo aberto, possibilita customizaes de acordo com a necessidade do projeto.

33

Figura 5.1: A Beagle Board com seus principais componentes destacados Outras caractersticas do Linux que justicam a escolha sua modularizao, que importante para sistemas embarcados, permitindo que somente os mdulos necessrios sejam carregados no kernel, economizando recursos, e o fato de ser um sistema amplamente usado e divulgado, logo j existe muito software disponvel para o sistema. A distribuio escolhida pela equipe a distribuio Angstrom, especialmente voltada para sistemas embarcados.

5.2.1

Linux

Kernel de cdigo aberto escrito por Linus Torvalds em meados de 1991. A princpio foi desenvolvido somente como um hobby, para ser uma alternativa ao MINIX, escrito por Andrew Tanenbaum em 1987 como projeto acadmico, pois tinha uma licena muito restritiva.

34

O Linux foi desenvolvido como um kernel monoltico, que controla a execuo dos processos, acesso a rede, sistema de arquivos e perifricos. Os drivers dos dispositivos da mquina so integrados ao kernel atravs de mdulos. Acabou se tornado muito popular pela comunidade e com uma equipe constante de desenvolvedores acabou se tornando um kernel muito abrangente, suportando diversas arquiteturas, como laptops e desktops at celulares e supercomputadores. Vrios sistemas operacionais baseados no Linux surgem a cada dia, cada qual com suas caractersticas especcas para atender necessidades diferentes. Estes sistemas so chamados de distribuies Linux, ou distros.

5.2.2

Angstrom

O Angstrom nasceu da colaborao de integrantes de outras distribuies de Linux voltadas para sistemas embarcados, os OpenEmbedded, OpenZaurus e OpenSIMPad. O objetivo desta comunidade criar uma distribuio Linux especialmente voltada para sistemas embarcados baseados em processadores ARM. Sua principal caracterstica a escalabilidade, podendo ocupar meros 4Mb, ou gigas de armazenamento. A escalabilidade alcanada atravs de pacotes de software que permitem que os desenvolvedores acrescentem as funcionalidades a medida que so necessrias. O gerenciador de pacotes utilizado no Angstrom o ipkg (Itsy Package Management System), especialmente voltado para sistemas embarcados por ocupar pouco espao de armazenamento. baseado no gerenciador de pacotes do Debian, o dpkg.

5.3

Software

Para a realizao da telemetria, sero desenvolvidos e/ou empregados softwares para realizar cada etapa do processo.

5.3.1

Medio

A primeira etapa do processo de telemetria, a medio dos dados, deve ser realizada por um software que seja capaz de utilizar a interface serial criada pelo conector USB x OBD, levantar os dados e armazen-los localmente. J existem softwares desenvolvidos com este m, mas a maioria composta de software proprietrio, de cdigo fechado, e dependente de plataforma. Porm, existe um programa que no se encaixa nesta maioria, chamado obdgpslogger, desenvolvido por Gary Briggs (Briggs, 2009). A proposta do obdgpslogger ser um gravador de logs de dados funcionais de automveis juntamente com coordenadas GPS, sendo assim possvel reconstruir o trajeto de um veculo e monitorar seus dados funcionais durante o percurso. O obdgpslogger foi escrito na linguagem C sob a licena GPL, tendo seu cdigo fonte disponibilizado. Foi totalmente escrito para ser compatvel com sistemas POSIX, e desenvolvido em mdulos, separados por funcionalidades. Os seguintes mdulos so os principais para o objetivo deste projeto, entre outros desenvolvidos. 35

 obdgpslogger: O mdulo principal, responsvel pela comunicao serial e gravao dos dados. obdsim: Simulador OBD, que possibilita testes longe de um automvel, simulando uma porta serial ligada ao sistema OBD. obd2csv: Conversor dos dados gravados pelo logger para o formato CSV. O obdgpslogger j foi implementado em diversos sistemas e arquiteturas diferentes, inclusive testes foram feitos no hardware e sistema operacional denidos neste projeto, executando normalmente. Por atender as necessidades do projeto, este software ser usado na medio dos dados OBD do automvel.

5.3.2

Cliente

A parte do cliente ser um software que executar a bordo do veculo, no sistema embarcado. Logo dever ser executado em um ambiente com poucos recursos, devendo acessar os dados gerados pelo obdgpslogger, convert-los e envi-los pela conexo com a Internet mvel. Considerando a arquitetura do sistema, o sucesso da execuo do obdgpslogger e a necessidade de ambos executarem simultaneamente, a parte do cliente ser desenvolvida de forma semelhante, na linguagem C, fazendo chamadas aos mdulos do obdgpslogger quando necessrio. As tarefas do cliente resumem-se a: Vericar e estabelecer a conexo com o servidor. Utilizar o mdulo obd2csv para fazer a converso dos dados e salv-los em arquivos em local apropriado. Envio dos dados ao servidor. Limpeza dos dados medidos anteriormente aps a converso, considerando que este um sistema embarcado com pouco espao para armazenamento. Para o acesso aos dados gerados pelo obdgpslogger, ser usada a mesma API de cdigo aberto, o SQLite, uma API que permite a criao de bancos de dados simples e compactos. Como parte do processo de desenvolvimento, foi desenhado um uxograma para facilitar a visualizao do processo de execuo do cliente (Figura 5.2). O intervalo de cinco minutos entre cada envio foi denido arbitrariamente, sendo necessrios testes para vericar se o acumulo de dados neste intervalo no ser grande demais para fazer o envio, considerando a largura de banda limitada das conexes celulares, ou se esse intervalo de tempo no curto demais, sobrecarregando o servidor com conexes desnecessrias. Estes dados so avaliados no captulo 6. O sistema prev a indisponibilidade de conexo com o servidor, considerando a natureza de sua conexo. O sistema somente far a converso dos dados quando o servidor for contatado. Sendo assim, possvel que haja acmulo excessivo de dados em caso de um perodo muito longo de ausncia de conexo (por exemplo, em 36

Figura 5.2: Fluxograma do programa cliente

37

percursos intermunicipais, longe do servio das redes celulares). Para isso, foi feito clculo, considerando a taxa de medio de dados pelo obdgpslogger, sendo possvel prever o tamanho de armazenamento necessrio para armazenar a quantidade de dados gerados enquanto no se obtm uma conexo com o servidor. Estes dados so levantados no captulo 6.

5.3.3

Servidor

O processo servidor ser um programa executando em alguma mquina conectada a Internet, esperando pela conexo de processos clientes rodando nos veculos monitorados. Este servidor no tem limitaes como o processo cliente, logo pode ser implementado em qualquer tipo de sistema que suporte a tarefa. Considerando a possibilidade de alto nmero de veculos sendo monitorados, um computador de alta capacidade de processamento e armazenamento recomendado. Para obter portabilidade, usou-se a linguagem Java para o desenvolvimento do servidor, e um banco de dados PostgreSQL para o armazenamento dos dados. Programa As tarefas do programa servidor: Receber conexes de um cliente. Validar se o veculo est registrado. Enviar parmetros de conexo/comandos. Receber arquivos CSV compactados e descompact-los. Ler os arquivos e armazenar os dados no banco de dados. A gura 5.3 um uxograma do funcionamento do servidor. Como mostrado, este um programa multithread, ou seja que cria vrias threads que so executadas paralelamente. Isto se deve ao fato de que ele deve ser capaz de tratar diversas conexes simultaneamente. Para o desenvolvimento do servidor foi utilizada, alm das bibliotecas bsicas do Java, a biblioteca OpenCSV (Smith et al., 2009), biblioteca Java de cdigo aberto para manipulao de arquivos CSV. O diagrama de classes para o programa pode ser visto na gura 5.4. No pacote principal esto os processos Main, que somente realiza, a cada conexo, a criao de thread representada pela classe ServerThread, que faz o trabalho de comunicao com o cliente atravs de sockets. No pacote db esto as classes responsveis pelo acesso ao banco de dados, os DAO (Data Access Objects), e no pacote beans est o objeto que representa um veculo. No foi criado objeto para representar os dados OBD pois os dados so transferidos diretamente do arquivo CSV para o procedimento de gravao do banco na classe ObdDao.

38

Figura 5.3: Fluxograma do programa servidor

39

Figura 5.4: Diagrama de classes do programa servidor

40

Coluna id license description

Tipo integer character(7) text

Obs. Campo sequencial, chave primria Placa do carro, chave nica Descrio, texto livre

Tabela 5.1: Estrutura da tabela de veculos Coluna id_vehicle time gps_lat gps_lon gps_alt dtcfrzf fuelsys load_pct temp Tipo integer numeric numeric numeric numeric integer integer numeric(9,6) integer Obs. Chave estrangeira da tabela de veculos, e chave primria. Timestamp do momento da medio, chave primria. Latitude GPS Longitude GPS Altitude GPS

... Tabela 5.2: Estrutura parcial da tabela de dados OBD Banco de dados O banco de dados utilizado para o desenvolvimento o PostgreSQL, mas nada impede que outros bancos que suportem drivers Java JDBC sejam utilizados. O banco composto somente de duas tabelas, dispensando um diagrama entidade relacionamento. As tabelas so a tabela de cadastro de veculos e a tabela de dados OBD. Suas estruturas so mostradas respectivamente nas tabelas 5.1 e 5.2. O script SQL de criao delas pode ser visto no anexo III. A tabela de dados OBD possui campos para descrio de todos os dados possveis de serem monitorados pelo padro OBD, como descrito na tabela 3.1, j convertidos para o valor numrico correspondente. Mas raramente os veculos suportam todos os campos, deixando os campos que no suporta com o valor nulo. Isto acarreta um certo desperdcio de armazenamento, que poderia ser evitado pela criao de tabelas relacionais separadas por cada campo, e uma tabela de registro de campos suportados por cada veculo. Isto, porm, acarretaria em uma maior necessidade de processamento por parte do processo servidor ao receber os dados, e muito mais acessos ao banco de dados, alm de uma quantidade muito maior de tabelas no banco de dados. Considerando a gravao de 300 registros no banco de dados com 10 colunas, ao invs de 300 comandos SQL para gravar as linhas, seriam necessrios 300 10 = 3000 comandos para gravao dos dados. Considerando o custo cada vez menor para armazenamento, a economia em processamento e acesso ao banco tem impacto muito maior do que o desperdcio de armazenamento.

41

Comando CMD_SEND_LICENSE

Objetivo Requisita do cliente o envio da placa do carro CMD_RECV_BUFFERSZ Avisa para o cliente receber inteiro que representa o tamanho do buffer para troca de arquivos (B) CMD_SEND_NUMFILES Requisita do cliente o nmero de arquivos que sero enviados (N ) CMD_SEND_FILES Requisita do cliente o envio dos arquivos

Resposta Cliente envia string de 7 caracteres Cliente recebe inteiro

Cliente envia inteiro

CMD_RECV_SLEEPTM CMD_BYE

Altera tempo de espera do cliente entre as conexes. Informa ao cliente o m da transmisso

Para cada arquivo, enviado seu tamanho (T ), e em seguida T /B pacotes de B bytes Cliente recebe inteiro Conexo fechada

Tabela 5.3: Comandos que o servidor pode enviar ao cliente

5.3.4

Protocolo de comunicao

A conexo estabelecida entre o cliente o servidor feita atravs de Sockets, ou seja, utilizando o protocolo TCP sobre IP, o que signica que as mensagens so recebidas sincronizadamente e com checagem de erro. A comunicao entre os processos se d na forma de comandos enviados pelo servidor. A conexo estabelecida pelo cliente, mas este ento recebe os comandos que so enviados do servidor. Isto permite que alteraes no comportamento do sistema sejam feitos somente pelo servidor, sendo necessrio alterar o cliente somente quando se deseja adicionar uma funcionalidade. Os comandos so nmeros inteiros positivos denidos como constantes nos programas. A tabela 5.3 mostra uma lista dos comandos implementados. Quando algum erro ocorre na comunicao, ela cortada imediatamente. Como a conexo feita constante e periodicamente, no existe a necessidade para tratamento e recuperao de erros. Os dados no enviados so deixados para serem enviados na tentativa seguinte.

42

Captulo 6 Testes e anlises

Para estudar o comportamento do sistema, necessrio executar testes controlados para averiguar as variveis que o inuenciam. Testes foram executados em alguns automveis de diferentes fabricantes, sendo possvel levantar a diferena de dados disponveis para medio em cada modelo. Os automveis foram dirigidos durantes os testes por diferentes percursos e horrios, com o m de testar o impacto da qualidade do sinal para o envio dos dados. Porm, considerando o ambiente urbano, onde existe cobertura de sinal em quase toda rea livre, pouca diferena foi percebida neste quesito. Outra importante considerao que deve ser feita no sistema se o meio de envio dos dados permite uma banda suciente para que no haja acmulo de dados localmente. Considerando o meio instvel de conexo e a alta taxa de medio e a quantidade de dados levantados, esta uma preocupao que considerada nos testes a seguir. Antes de divulgar os resultados, necessrio expor os procedimentos realizados para execuo do sistema, a plataforma utilizada, que no a mesma denida como plataforma nal de execuo do projeto, e os clculos realizados.

6.1

Plataforma de testes

O sistema foi testado utilizando-se plataforma e interfaces diferentes das pretendidas, porm semelhantes, o que no garante um resultado completo, mas uma boa aproximao para estimar o comportamento do sistema em funcionamento. A plataforma de execuo utilizada um notebook Dell Latitude D520 com processador Intel e sistema operacional Ubuntu Linux verso 9.10 (Figura 6.2). A interface com o automvel feita utilizando-se conector OBDxUSB comercial baseado no ELM327 (Figura 6.3). A verso do obdgpslogger utilizada foi a verso 0.10, disponibilizada em outubro de 2009. Para a conexo com a Internet, ao invs de modem 3G dedicado, utilizou-se um telefone celular Nokia N95 com conexo USB. O sistema operacional Ubuntu j possui os drivers necessrios para faz-lo funcionar como um modem 3G/GPRS (Figura 6.4). A operadora de telefonia celular na qual o aparelho usado a Claro.

43

6.2

Procedimentos

Os procedimentos necessrios para a criao do ambiente e realizao dos testes foram os seguintes: Montagem do ambiente cliente Compilao do obdgpslogger. Compilao do cliente de telemetria. Congurao e instalao de drivers necessrios para o conector OBD. Conexo a Internet mvel. Montagem do ambiente servidor Compilao do servidor de telemetria. Instalao e congurao de banco de dados. Abertura de portas necessrias para comunicao.

6.2.1

Montagem do ambiente cliente

Como j dito, o ambiente de execuo dos processos cliente foi feito em um notebook rodando o Ubuntu Linux verso 9.10. Compilao do obdgpslogger Para compilar o fonte do programa disponibilizado em sua pgina da Internet (Briggs, 2009), necessria a ferramenta CMake, que uma ferramenta para facilitar a compilao de programas em diferentes ambientes, possibilitando a congurao do executvel. Atravs do comando CCMake possvel customizar a compilao, removendo mdulos desnecessrios como os mdulos de interface que acompanham o obdgpslogger, alm de alterar alguns valores padres para o programa, como caminho de destino do arquivo de log e porta serial padro do dispositivo OBD. As bibliotecas necessrias para compilao so as pthread e dl, usadas pelo cdigo do SQLite, incluso com o fonte do programa. Para o uso dos recursos GPS do programa, necessria a instalao do gpsd, aplicativo de interface com dispositivos GPS. Compilao do cliente de telemetria O cliente de telemetria pode ser compilado com o uso do GCC, compilador C padro nos sistemas GNU/Linux. Alm das bibliotecas citadas acima para uso do SQLite, necessria a biblioteca libcong para leitura de arquivo de congurao que deve ser gerado em /etc/obdtelemetry.cfg com os parmetros do cliente. Exemplo de arquivo de congurao pode ser visto na gura 6.1. As variveis so: hostname: Nome ou IP do servidor 44

/ # Configuration f i l e f o r o b d t e l e m e t r y c l i e n t / hostname = " hostname . ath . cx " ; v e h i c l e _ i d = "NEW1234 " ; db_path = " / home / a l c i d e s / obdlogs / obd . db " ;

Figura 6.1: Exemplo de arquivo de congurao do cliente vehicle_id: Placa do carro sendo medido db_path: Caminho do arquivo que est sendo gerado pelo obdgpslogger

Instalao de drivers necessrios para o conector OBD A comunicao com as interfaces OBD baseadas no ELM327 feita atravs de porta serial. Se o adaptador usado for de conexo RS-232, no necessrio nenhum driver. Porm, se for utilizada outra interface, como a USB, necessrio que seja feita a instalao do driver do conversor de sinal USBxRS-232 utilizado no conector. Nos testes o conector utilizado possua interface USB serial com chip FTDI. Os drivers j estavam instalados no Ubuntu. Depois que o dispositivo reconhecido pelo sistema, necessrio congurar sua taxa de transmisso (baud rate) para que a comunicao serial ocorra. Esta taxa depende do dispositivo sendo usado e pode no ser detectada automaticamente. No dispositivo usado, a taxa era erroneamente detectada como 9200 bauds sendo que o valor correto era 38400. Conexo a Internet mvel Para conectar o sistema a Internet mvel, necessrio um modem ou telefone com interface para conexo de computadores rede GSM. O telefone utilizado, o Nokia N95, foi detectado automaticamente pelo Ubuntu e foi possvel fazer conexo atravs de sua interface.

6.2.2

Montagem do ambiente servidor

O computador utilizado como servidor nos testes foi um desktop com processador AMD e sistema Windows, mas nada no programa servidor impede que seja usado outra arquitetura, j que ele foi desenvolvido em Java.

45

Compilao do servidor de telemetria Para o desenvolvimento e compilao do programa servidor, foi utilizado o Java SE verso 1.6.0.15. Alm das bibliotecas padres do Java, foi utilizada a biblioteca OpenCSV (Smith et al., 2009) e a biblioteca de conexo com o banco de dados PostgreSQL. Instalao e congurao de banco de dados Para a instalao e congurao do banco de dados foi instalado pacote contendo o banco de dados e ferramentas de administrao conhecido como PostgreSQL EnterpriseDB, disponvel gratuitamente na Internet. Foram criadas duas tabelas no banco, como mostram os scripts SQL no anexo III. Registros de veculos so adicionados manualmente atravs de ferramenta de administrao do banco. Abertura de portas necessrias para comunicao A porta IP denida para comunicao entre os processos a 22490. O servidor deve estar conectado a Internet e com esta porta aberta para que a conexo funcione. Se houver roteamento e NAT, o gateway deve ser congurado para direcionar requisies desta porta para a mquina servidora.

6.3

Clculos

Alguns simples clculos so feitos para averiguar o comportamento e viabilidade do sistema, para assegurar que o acmulo indenido de dados no ocorra facilmente. Variveis medidas durante os testes: Tt (Taxa de Transmisso mdia observada, em kb/s) Tc (Taxa de Crescimento dos dados em kb/s) Tt medido dividindo o tamanho do arquivo enviado pelo tempo de envio. Tc calculado observando-se o tamanho dos arquivos gerados pelo sistema. Vamos denir como o intervalo de tempo, em segundos, entre uma conexo e outra do sistema. A princpio escolhemos = 300. Os arquivos a serem enviados so gerados neste intervalo de tempo. Chamamos de dt o tamanho em kbytes dos dados levantados no intervalo de t segundos. Podemos calcular o valor de Tc atravs de d da seguinte forma: Tc = d

Para vericarmos a viabilidade do sistema, calculamos o tempo necessrio para envio dos dados levantados durante t segundos (Tempo de Esvaziamento em t, t ): t = dt Tc = t Tt Tt 46

Indiscutivelmente, se Tc > Tt , o sistema invivel j que nunca ser possvel enviar mais dados do que so gerados. Se Tc = Tt , a cada erro e falha de conexo haver acmulo de dados que nunca sero enviados. Logo para o sistema ser vivel deve acontecer que Tc < Tt . Mesmo com Tc < Tt , um tempo muito grande sem conexo ou muitas falhas consecutivas poderiam gerar um acmulo de dados que demoraria muito tempo para ser desfeito. Mesmo havendo conectividade, durante o envio ainda haveria acmulo. Porm, como vamos observar nos testes a seguir, Tt Tc , logo t t. Ou seja, qualquer acmulo rapidamente desfeito no momento em que ocorre uma conexo devido a grande diferena entre a taxa de transmisso e de acmulo de dados.

6.4
6.4.1

Ford Ka 1.0 2009

Dados do teste

Data: 23 de Novembro de 2009 Percurso: SQN 214 at Esplanada dos Ministrios, via Setor de Clubes Norte, Braslia. Durao: 13:34 s 14:11 (37 minutos) Quantidade de registros gerados: 2198

6.4.2

Campos OBD suportados

De acordo com a tabela 3.1. Campo load_pct temp shrtft13 longft13 map rpm vss sparkadv iat throttlepos obdsup mil_dist Descrio Calculated LOAD Value Engine Coolant Temperature Short Term Fuel Trim - Bank 1,3 Long Term Fuel Trim - Bank 1,3 Intake Manifold Absolute Pressure Engine RPM Vehicle Speed Sensor Ignition Timing Advance for Cylinder 1 Intake Air Temperature Absolute Throttle Position OBD requirements to which vehicle is designed Distance Travelled While MIL is Activated

Tabela 6.1: Dados OBD suportados pelo Ford Ka.

47

6.4.3

Valores observados

Na tabela 6.2 esto as variveis funcionais calculadas durante os testes. Na tabela 6.3 esto alguns exemplos dos dados levantados. Com os dados levantados foi possvel calcular o valor mdio de alguns dos parmetros, como mostrado na tabela 6.4 Varivel Valor Tt 2,44 kb/s Tc 0,28 kb/s 300 34s 3600 413s Tabela 6.2: Taxas do sistema observadas durante testes no Ford Ka. temp map 93 84 93 86 93 79 93 77 93 86 94 84 94 85 94 33 94 80 94 77 94 34 94 35 94 36 94 36 94 35 94 38 94 58 94 54 94 52 94 57 94 85 rpm vss iat throttlepos time 1274.00 0 54 24.313726 1258990717.951405 1642.00 8 54 37.647060 1258990718.951953 2285.00 13 54 0.000000 1258990719.952505 1646.00 14 54 25.882353 1258990720.953055 1632.00 16 54 33.333332 1258990721.953610 1934.00 20 54 33.725491 1258990722.954153 2192.00 23 54 37.254902 1258990723.954700 1958.00 25 53 5.882353 1258990724.955245 1555.00 25 54 20.784313 1258990725.955788 1674.00 27 54 1.176471 1258990726.956316 1651.00 27 53 0.000000 1258990727.956830 1571.00 26 53 0.000000 1258990728.957370 1529.00 25 54 0.000000 1258990729.957945 1447.00 24 54 0.000000 1258990730.958516 1326.00 22 54 0.000000 1258990731.959079 1197.00 20 54 0.000000 1258990732.959635 937.00 18 54 0.000000 1258990733.960249 993.00 15 54 0.000000 1258990734.960792 981.00 11 54 0.000000 1258990735.961345 927.00 10 54 8.235294 1258990736.961903 1081.00 11 55 29.411764 1258990737.962447

Tabela 6.3: Exemplo de dados levantados para o Ford Ka.

6.5
6.5.1

Nissan Livina 1.6 2009

Dados do teste

Data: 28 de Novembro de 2009 48

Parmetro Mdia temp 91.6 map 59 rpm 1920 vss 39 throttlepos 14.64 Tabela 6.4: Valores mdios de parmetros levantados para o Ford Ka. Percurso: SQS 316 at CLS 207, via Eixo W, Braslia. Durao: 20:32 s 20:40 (8 minutos) Quantidade de registros gerados: 456

6.5.2

Campos OBD suportados

De acordo com a tabela 3.1. Campo load_pct temp shrtft13 longft13 map rpm vss sparkadv iat throttlepos o2sloc o2s11 o2s12 obdsup mil_dist Descrio Calculated LOAD Value Engine Coolant Temperature Short Term Fuel Trim - Bank 1,3 Long Term Fuel Trim - Bank 1,3 Intake Manifold Absolute Pressure Engine RPM Vehicle Speed Sensor Ignition Timing Advance for Cylinder 1 Intake Air Temperature Absolute Throttle Position Location of Oxygen Sensors Bank 1 - Sensor 1/Bank 1 - Sensor 1 Oxygen Sensor Output Voltage / Short Term Fuel Trim Bank 1 - Sensor 2/Bank 1 - Sensor 2 Oxygen Sensor Output Voltage / Short Term Fuel Trim OBD requirements to which vehicle is designed Distance Travelled While MIL is Activated

Tabela 6.5: Dados OBD suportados pelo Nissan Livina.

6.5.3

Valores observados

Na tabela 6.6 esto as variveis funcionais calculadas durante os testes. Na tabela 6.7 esto alguns exemplos dos dados levantados. Com os dados levantados foi possvel calcular o valor mdio de alguns dos parmetros, como mostrado na tabela 6.8 49

Varivel Valor Tt 1,86 kb/s Tc 0,28 kb/s 300 45s 3600 541s Tabela 6.6: Taxas do sistema observadas durante testes no Nissan Livina. temp map 88 31 88 31 88 30 89 31 89 29 89 31 89 29 89 29 89 29 89 29 89 30 89 31 89 31 90 32 89 32 90 32 90 31 90 46 90 44 rpm vss iat throttlepos time 792.00 8 39 11.764706 1259451323.655444 809.00 8 39 11.764706 1259451324.656021 799.00 3 39 11.764706 1259451325.656564 796.00 0 39 11.764706 1259451326.657070 804.00 0 39 12.549020 1259451327.657567 826.00 0 39 11.764706 1259451328.658065 826.00 0 39 11.764706 1259451329.658566 800.00 0 39 11.764706 1259451330.659066 795.00 0 39 11.764706 1259451331.659568 764.00 0 39 11.764706 1259451332.660063 739.00 0 39 11.764706 1259451333.660566 741.00 0 39 11.764706 1259451334.661068 741.00 0 39 11.764706 1259451335.661571 721.00 0 39 11.764706 1259451336.662092 740.00 0 39 11.764706 1259451337.662575 744.00 0 39 11.764706 1259451338.663067 756.00 0 39 15.294118 1259451339.663568 2376.00 2 39 18.823530 1259451340.664068 2321.00 5 39 18.823530 1259451341.664567

Tabela 6.7: Exemplo de dados levantados para o Nissan Livina.

6.6
6.6.1

Ford Focus 2.0 2009

Dados do teste

Data: 25 de Novembro de 2009 Percurso: 214 Norte at 506 Norte, ida via W3, volta via Eixo L. Durao: 22:29 s 23:30 (61 minutos) Quantidade de registros gerados: 3386

6.6.2

Campos OBD suportados

De acordo com a tabela 3.1.

50

Parmetro Mdia temp 88 map 36 rpm 1550 vss 42 throttlepos 14.85 Tabela 6.8: Valores mdios de parmetros levantados para o Nissan Livina. Campo load_pct temp rpm vss obdsup mil_dist aat Descrio Calculated LOAD Value Engine Coolant Temperature Engine RPM Vehicle Speed Sensor OBD requirements to which vehicle is designed Distance Travelled While MIL is Activated Ambient Air Temperature

Tabela 6.9: Dados OBD suportados pelo Ford Focus.

6.6.3

Valores observados

Na tabela 6.10 esto as variveis funcionais calculadas durante os testes. Na tabela 6.11 esto alguns exemplos dos dados levantados. Com os dados levantados foi possvel calcular o valor mdio de alguns dos parmetros, como mostrado na tabela 6.12 Varivel Valor Tt 1,71 kb/s Tc 0,14 kb/s 300 24s 3600 294s Tabela 6.10: Taxas do sistema observadas durante testes no Ford Focus.

51

temp 92 92 92 93 92 92 92 92 92 92 92 92 92 92 92 92 93 93 93 92

rpm vss time 1537.75 7 1259199063.590389 1886.50 13 1259199064.590835 2245.25 19 1259199065.591290 2437.75 24 1259199066.591753 2109.75 29 1259199067.592208 1979.75 32 1259199068.592670 1767.25 32 1259199069.593141 1167.75 32 1259199070.593585 1141.00 30 1259199071.594017 1071.50 28 1259199072.594504 1001.75 26 1259199073.594989 966.25 24 1259199074.595407 904.50 23 1259199075.595919 941.75 22 1259199076.596382 1695.25 22 1259199077.596854 2178.25 25 1259199078.597337 2197.00 28 1259199079.597804 2215.50 30 1259199080.598287 2117.50 32 1259199081.598769 2047.50 32 1259199082.599231

Tabela 6.11: Exemplo de dados levantados para o Ford Focus.

Parmetro Mdia temp 94 rpm 855 vss 14 Tabela 6.12: Valores mdios de parmetros levantados para o Ford Focus.

52

Figura 6.2: Notebook Dell utilizado para executar o sistema

Figura 6.3: Conector USBxOBD

53

Figura 6.4: Celular Nokia N95 com cabo USB para uso como modem 3G/GPRS.

Figura 6.5: Automvel Ford Ka 1.0, ano 2009, exterior.

54

Figura 6.6: Localizao do conector OBD no Ford Ka.

Figura 6.7: Automvel Nissan Livina 1.6, ano 2009, exterior.

55

Figura 6.8: Localizao do conector OBD no Nissan Livina.

Figura 6.9: Automvel Ford Focus 2.0, ano 2009, exterior.

56

Figura 6.10: Localizao do conector OBD no Ford Focus.

57

Captulo 7 Concluso e desenvolvimentos futuros

Atravs deste trabalho foi possvel vericar que a tecnologia existente hoje em dia, tanto em questes de software, como hardware e infra-estrutura em telecomunicaes, permitiram o desenvolvimento de sistema de telemetria para veculos automotores. Todos os objetivos do projeto foram alcanados, porm sua integrao ao sistema Karmonitor ainda necessita de alguns passos. Primeiramente, em questo ao hardware, o conector OBD e os softwares utilizados neste projeto foram testados sob o Angstrom na Beagle Board e funcionaram. Porm no foi possvel realizar os testes de uso neste hardware pois no foi feita ainda a instalao da placa em um automvel. Logo o ambiente de hardware utilizado nos testes foi diferente. Isto pode levar a diferenas com relao a performance do sistema, visto que a Beagle Board um ambiente mais limitado que o notebook utilizado. Para a integrao deste sistema na Beagle Board, necessrio: Compilao dos programas clientes para execuo no Angstrom da Beagle Board (J comprovado ser possvel). Instalao do driver necessrio para a interface USBxSerial utilizada no conector OBD desejado. (O conector utilizado neste projeto j foi testado com sucesso na Beagle). Instalao de drivers e componentes do sistema para conexo Internet pela rede celular. Instalao da Beagle em um automvel. Com relao ao software, como o programa cliente estar executando em um computador a bordo, necessrio que ele e o obdgpslogger sejam congurados para funcionarem como daemons, executando automaticamente com o boot do sistema operacional. Outro aspecto que no foi abordado e que fundamental para o uso do sistema em larga escala a questo da segurana. Os dados devem ser assinados e/ou criptografados para evitar interferncias e interceptaes por terceiros, considerando

58

que estes dados trafegaro em rede pblica, a Internet. Uma simples implementao de criptograa, tanto simtrica como assimtrica, deve ser o suciente para sanar a vulnerabilidade. Uma capacidade do obdgpslogger que no foi explorada a de monitoramento da posio atravs de dispositivo GPS ligado ao computador que executa o cliente. Porm, o cliente j est preparado para enviar os dados, basta que um equipamento compatvel com o programa gpsd esteja conectado. Esta funcionalidade s no foi explorada por falta do hardware adequado para testes. Outra possibilidade para o sistema sua especializao quanto a veculos e fabricantes. Atravs da porta OBD esto sendo somente levantados dados padres que so disponibilizados em diversos carros. Porm, atravs da porta OBD possvel enviar comandos e levantar dados especcos ao modelo de carro e fabricante. Para isso, seria necessrio um dispositivo USB x OBD diferenciado, pois o ELM327 somente suporta os comandos padres. Tambm seria necessrio um patrocnio ou parceria com a fabricante, pois tais comandos e modos de comunicao no so publicados abertamente.

59

Referncias
Anatel (2009). Total de acessos mveis pr-pago e ps-pago por uf. 28 BRASIL (1993). Lei 8.723, de 28 de outubro de 1993. publicada no dirio ocial da unio em 29 de outubro de 1993. 2 Briggs, G. (2009). Obd gps logger. http://icculus.org/obdgpslogger/. Acessado em 11/2009. 35, 44 CONAMA (2006). Instruo normativa n 126, de 24 outubro de 2006. 20 r Dzhelekarski, P. and Alexiev, D. (2005a). Initializing communication to vehicle obdii system. ELECTRONICS05. 21 Dzhelekarski, P. and Alexiev, D. (2005b). Reading and interpreting diagnostic data from vehicle obdii system. ELECTRONICS05. 12, 22 ELM Electronics (2009). ELM327 - OBD to RS232 Interpreter. 23 FlexRay Consortium (2005). FlexRay Protocol Especication, 2.1a edition. 18 GSM Association (2009). Market data summary. 28 Gutierrez, E. M. (2006). Telemetria: Aplicao de rede de sensores biomdicos sem o. Masters thesis, UnB - Universidade de Braslia. 3 Jenkins, W. (2004). Real-time vehicle performance monitoring using wireless networking. Technical report, Human and Systems Engineering, Center for Advanced Vehicular Systems, Mississippi State University, 200 Research Blvd., Mississippi State, Mississippi 39759, USA. 5 Junior, M. H. (2005). Internet mvel, gprs aplicado ao acesso internet. Technical report, Universidade Federal de Santa Catarina. viii, 30, 31 Khan, N., Saleem, Z., and Hoong, C. C. (2007). An experiment on internet based telemetry. Proceedings of the 6th WSEAS Int. Conf. on Electronics, Hardware, Wireless and Optical Communications, pages 6878. 4 Kopetz, H., Elmenreich, W., and Mack, C. (2000). A comparison of lin and ttp/a. Technical report, Institut fr Technische Informatik, Technische Universitt Wien, Austria. 8

60

Kopetz, H. and Grunstidl, G. (1993). Ttp - a time-triggered protocol for faulttolerant real-timesystems. In Fault-Tolerant Computing 1993, Digest of papers., pages 524533. 8, 17 Kvaser AB (2009). The can protocol tour: http://www.kvaser.com/can/ protocol/index.htm, acessado em 04/2009. 12 Leen, G. and Heffernan, D. (2002). Expanding automotive electronic systems. Computer, 35(1):8893. 7 Leen, G., Heffernan, D., and Dunne, A. (1999). Digital networks in the automotive vehicle. Computing and Control Engineering Journal, 10(6):257266. 7 Mantovani, J. E. and Santos, J. E. (2001). Telemetria convencional e via satlite na determinao da rea de vida de trs espcies de carnvoros da regio nordeste do estado de so paulo. Masters thesis, Universidade Federal de Santa Catarina - UFSC. 3 MOST Cooperation (2008). MOST Specication, rev 3.0 edition. 17 Navet, N., Song, Y., Simonot-lion, F., and Wilmert, C. (2005). Trends in automotive communication systems. Proceedings of the IEEE, 93(6):12041223. 6 Oliver, D. J. (2001). Implementing the J1850 Protocol. Intel Corporation. 8 Paim, F. C. A. (2005). Desenvolvimento de um sistema de telemetria para aquisio de sinais siolgicos com aplicao em programas de reabilitao cardaca. Masters thesis, Universidade Federal de Santa Catarina - UFSC. 3 Pazul, K. (1999). Controller area network (can) basics. Technical report, Microchip Technology Inc. 12, 16 Peersman, G. and Cvetkovic, S. (2000). The global system for mobile communications short message service. IEEE Personal Communications. 29 Richardson, K. W. (2000). Umts overview. ELECTRONICS & COMMUNICATION ENGINEERING JOURNAL, pages 93101. 31 Riley, M. (1998). Computer networks take to the road. Evaluation Engineering. ix, 8, 9, 10, 11, 12 Schoeld, M. J. (1996). Controller area network (canbus): mjschofield.com/, acessado em 04/2009. 12, 13, 16 http://www.

Scourias, J. (1997). Overview of the global system for mobile communications. Technical report, University of Waterloo. 29 Sidorenko, A. (2009). Obd2 elm327 compatible allpro adapter with usb http:// obddiag.net acessado em 06/2009. 23 Smith, G., Sullivan, S., and Conway, S. (2009). Opencsv. http://opencsv. sourceforge.net/. Acessado em 11/2009. 38, 46 61

TTA Group (2004). TTP - Easy to read. 8, 17 Walker, B. (2007). Augmenting amusement rides with telemetry. Advancements in Computer Entertainment Technology, pages 115122. 4

62

Anexo I Cdigo-fonte do cliente

I.1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

clientmain.h

/ CLIENTMAIN.H Author : A l c i d e s Carlos de Moraes Neto This f i l e i s part o f o b d t e l e m e t r y c l i e n t / #ifndef _CLIENTMAIN_H #define _CLIENTMAIN_H #define CSV_PATH " / tmp / obdlogs / " //Server commands// #define CMD_SEND_LICENSE 1 #define CMD_RECV_BUFFERSZ 2 #define CMD_SEND_NUMFILES 3 #define CMD_SEND_FILES 4 #define CMD_RECV_SLEEPTM 5 #define CMD_BYE 99 #include <sys / d i r . h> // g e t c u r r e n t time from g e t t i m e o f d a y ( ) double get_curr_time ( ) ; // c a l l obd2csv and g e n e r a t e csv f i l e in CSV_PATH // The f i l e name w i l l be obd + curr_time + . csv . gz int gen_obd_csv ( char db_path , double curr_time ) ; // used in scandir c a l l t o g e t . csv . gz f i l e s only .

63

30 int c s v g z _ f i l t e r ( const struct d i r e n t f i l e ) ; 31 32 #endif / _CLIENTMAIN_H /

I.2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

clientmain.c

/ CLIENTMAIN.C Author : A l c i d e s Carlos de Moraes Neto This f i l e i s part o f o b d t e l e m e t r y c l i e n t / #include " clientmain . h" #include #include #include #include #include #include #include #include #include #include < s t d i o . h> < s t d l i b . h> <unistd . h> <errno . h> < s t r i n g . h> <sys / types . h> <sys / s t a t . h> <sys / d i r . h> <sys / param . h> < l i b c o n f i g . h>

#include " networking . h" #include " database . h" int main ( int argc , char argv [ ] ) { // l i b c o n f i g s t r u c t s config_t conf ; // I n t e r n e t s o c k e t d e s c r i p t o r int sockfd ; //Hostname char hostname ; //Command r e c e i v e d from s e r v e r char cmd ; // V e h i c l e id char c a r _ i d ; // l o g g e r s q l i t e db path char db_path ;

64

37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71

// Current time o f c o n n e c t i o n double curr_time ; //Number o f csv f i l e s generated and not s e n t int f i l e c o u n t ; // L i s t o f f i l e s t o be s e n t struct d i r e n t f i l e s ; // Full path t o a f i l e char f i l e _ p a t h [MAXPATHLEN] ; //FILE being s e n t FILE f ; // Size o f b u f f e r t o use f o r sending f i l e s . Received from s e r v e r . int buflen ; // Time in seconds the program s l e e p s b e f o r e c o n n e c t i n g to server . // This can be changed by the s e r v e r . int sleep_time = 300; // Your everyday FOR counter int i ; i f ( mkdir (CSV_PATH, 0700) && errno != EEXIST) { f p r i n t f ( stderr , " Error : Could not c r e a t e d i r e c t o r y %s \n " , CSV_PATH) ; exit (1) ; } errno =0; //Loading values from c o n f i g f i l e / e t c /o b d t e l e m e t r y . c f g c o n f i g _ i n i t (& c o n f ) ; i f ( c o n f i g _ r e a d _ f i l e (& conf , " / e t c / obdtelemetry . c f g " ) == CONFIG_FALSE) { f p r i n t f ( stderr , " Error , could not read c o n f i g f i l e : % s\n" , c o n f i g _ e r r o r _ t e x t (& c o n f ) ) ; exit (1) ; } i f ( c o n f i g _ l o o k u p _ s t r i n g (& conf , " hostname " , &hostname ) == CONFIG_FALSE) { f p r i n t f ( stderr , " Error , could not read hostname : %s\n " , c o n f i g _ e r r o r _ t e x t (& c o n f ) ) ; exit (1) ; } i f ( c o n f i g _ l o o k u p _ s t r i n g (& conf , " v e h i c l e _ i d " , &c a r _ i d ) == CONFIG_FALSE) {

65

72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107

f p r i n t f ( stderr , " Error , could not read v e h i c l e _ i d : %s \n " , c o n f i g _ e r r o r _ t e x t (& c o n f ) ) ; exit (1) ; } i f ( c o n f i g _ l o o k u p _ s t r i n g (& conf , " db_path " , &db_path ) == CONFIG_FALSE) { f p r i n t f ( stderr , " Error , could not read db_path : %s\n" , c o n f i g _ e r r o r _ t e x t (& c o n f ) ) ; exit (1) ; } do { i f ( ( curr_time = get_curr_time ( ) ) < 0 ) { f p r i n t f ( stderr , " Error : Could not get time o f day . " ) ; c l o s e ( sockfd ) ; exit (1) ; } i f ( gen_obd_csv ( db_path , curr_time ) ) { f p r i n t f ( stderr , " Error : Could not generate csv " ) ; c l o s e ( sockfd ) ; exit (1) ; } i f ( flush_db ( db_path , curr_time ) ) { f p r i n t f ( stderr , " Error : Could not f l u s h database ."); c l o s e ( sockfd ) ; exit (1) ; } f i l e c o u n t = scandir (CSV_PATH, &f i l e s , c s v g z _ f i l t e r , alphasort ) ; i f ( f i l e c o u n t <= 0 ) { f p r i n t f ( stderr , " Error : Could not f i n d csv f i l e ( s) . ") ; c l o s e ( sockfd ) ; continue ; } p r i n t f ( " Connecting t o %s . . . \ n" , hostname ) ;

66

108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146

i f ( c o n n e c ts o c k e t ( hostname , &sockfd ) < 0 ) { p r i n t f ( " Could not c o n t a c t s e r v e r . . . \ n" ) ; continue ; //return 1; // Could not c o n t a c t server } do { // R e c e i v e command from s e r v e r and e x e c u t e // p r i n t f ( " Receiving command . . . " ) ; i f ( recv_chk ( sockfd , &cmd , sizeof ( char ) , 0 ) < 0 ) { c l o s e ( sockfd ) ; continue ; } //cmd = ntohl (cmd) ; p r i n t f ( " r e c e i v e d : %d\n" , cmd ) ; switch ( cmd ) { case CMD_SEND_LICENSE: //send car l i c e n s e i f ( send_chk ( sockfd , car_id , s t r l e n ( car_id ) , 0) < 0) { c l o s e ( sockfd ) ; continue ; } break ; case CMD_RECV_BUFFERSZ: // r e c e i v e b u f f e r s i z e p r i n t f ( " r e c e i v i n g buflen . . . " ) ; i f ( recv_chk ( sockfd , &buflen , sizeof ( int ) , 0) < 0) { c l o s e ( sockfd ) ; continue ; } buflen = ntohl ( buflen ) ; p r i n t f ( " r e c e i v e d : %d\n" , buflen ) ; break ; case CMD_SEND_NUMFILES: //send number o f f i l e s f i l e c o u n t = htonl ( f i l e c o u n t ) ; i f ( send_chk ( sockfd , &f i l e c o u n t , sizeof ( int ) , 0 ) < 0 ) { c l o s e ( sockfd ) ; continue ;

67

147 148 149 150 151 152 153 154 155 156 157 158

159 160 161 162 163 164 165 166 167 168 169 170

171 172 173 174 175 176 177 178 179 180 181 182 183

} f i l e c o u n t = ntohl ( f i l e c o u n t ) ; break ; case CMD_SEND_FILES: for ( i = f i l e c o u n t 1; i >= 0 ; i ) { // Going from newest t o o l d e s t // Newer data i s more important s t r c p y ( f i l e _ p a t h , CSV_PATH) ; s t r c a t ( f i l e _ p a t h , f i l e s [ i ]>d_name ) ; f = fopen ( f i l e _ p a t h , " rb " ) ; i f ( f == NULL) { f p r i n t f ( stderr , " Error : Could not open f i l e %s " , f i l e _ p a t h ) ; c l o s e ( sockfd ) ; exit (1) ; } p r i n t f ( " Sending f i l e %s . . . \ n" , file_path ) ; i f ( s e n d _ f i l e ( f , sockfd , buflen ) ) { // F i l e not s e n t . . . g i v e up and try later fclose ( f ) ; break ; } fclose ( f ) ; i f ( remove ( f i l e _ p a t h ) ) { f p r i n t f ( stderr , " Error : Could not remove f i l e %s " , file_path ) ; c l o s e ( sockfd ) ; exit (1) ; } } break ; case CMD_RECV_SLEEPTM: // r e c e i v e s l e e p _ t i m e p r i n t f ( " r e c e i v i n g sleep_time . . . " ) ; i f ( recv_chk ( sockfd , &sleep_time , sizeof ( int ) , 0 ) < 0 ) { c l o s e ( sockfd ) ; continue ; } sleep_time = ntohl ( sleep_time ) ;

68

184 p r i n t f ( " r e c e i v e d : %d\n" , sleep_time ) ; 185 break ; 186 case CMD_BYE: 187 default : 188 cmd=1; 189 c l o s e ( sockfd ) ; 190 break ; 191 } 192 } while ( cmd > 0 ) ; 193 } while ( ! s l e e p ( sleep_time ) ) ; 194 195 return 0 ; 196 } 197 198 double get_curr_time ( ) { 199 struct timeval currtime ; 200 201 i f ( 0 != gettimeofday (&currtime ,NULL) ) { 202 perror ( " Error on gettimeofday " ) ; 203 return 1; 204 } 205 return ( double ) currtime . t v _ s e c +(double ) currtime . tv_usec /1000000.0 f ; 206 } 207 208 int gen_obd_csv ( char db_path , double curr_time ) { 209 // obd2csv c a l l s t r i n g 210 char o b d 2 c s v _ c a l l [ 5 1 2 ] ; 211 // f i l e name 212 char csv_filename [ 2 8 ] ; 213 214 // F i l e name 215 s p r i n t f ( csv_filename , " obd%11.5 f . csv . gz " , curr_time ) ; 216 //obd2csv c a l l 217 s p r i n t f ( o b d 2 c s v _ c a l l , " obd2csv d %s z o %s%s e %11.5 f " , db_path , CSV_PATH, csv_filename , curr_time ) ; 218 p r i n t f ( " obd2csv c a l l : %s\n" , o b d 2 c s v _ c a l l ) ; 219 220 i f ( system ( o b d 2 c s v _ c a l l ) ) { 221 perror ( " Error on obd2csv c a l l . " ) ; 222 return 1 ; 223 } 224 return 0 ;

69

225 } 226 227 int c s v g z _ f i l t e r ( const struct d i r e n t f i l e ) { 228 return s t r s t r ( f i l e >d_name , " . csv . gz " ) ; 229 } ;

I.3

database.h

1 / Copyright 2009 Gary Briggs 2 3 This f i l e i s part o f obdgpslogger . 4 5 obdgpslogger i s f r e e s o f t w a r e : you can r e d i s t r i b u t e i t and/ or modify 6 i t under the terms o f the GNU General Public L i c e n s e as published by 7 the Free Software Foundation , e i t h e r v e r s i o n 2 o f the License , or 8 ( at your o p t i o n ) any l a t e r v e r s i o n . 9 10 obdgpslogger i s d i s t r i b u t e d in the hope t h a t i t w i l l be useful , 11 but WITHOUT ANY WARRANTY; without even the implied warranty of 12 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 13 GNU General Public L i c e n s e f o r more d e t a i l s . 14 15 You should have r e c e i v e d a copy o f the GNU General Public License 16 along with obdgpslogger . I f not , s e e <h t t p ://www. gnu . org/ l i c e n s e s / >. 17 / 18 19 20 / \ f i l e 21 \ b r i e f Database open and c l o s e f u n c t i o n s 22 / 23 #ifndef __DATABASE_H 24 #define __DATABASE_H 25 26 #include " s q l i t e 3 . h"

70

27 28 29 30 31 32 33 34

/// Open the s q l i t e database s q l i t e 3 opendb ( const char dbfilename ) ; /// Close the s q l i t e database void c l o s e d b ( s q l i t e 3 db ) ;

/// D e l e t e a l l rows in obd , gps and t r i p t a b l e s s t o r e d b e f o r e endtime . 35 int flush_db ( char db_path , const double endtime ) ; 36 37 #endif //__DATABASE_H

I.4

database.c

1 / Copyright 2009 Gary Briggs 2 3 This f i l e i s part o f obdgpslogger . 4 5 obdgpslogger i s f r e e s o f t w a r e : you can r e d i s t r i b u t e i t and/ or modify 6 i t under the terms o f the GNU General Public L i c e n s e as published by 7 the Free Software Foundation , e i t h e r v e r s i o n 2 o f the License , or 8 ( at your o p t i o n ) any l a t e r v e r s i o n . 9 10 obdgpslogger i s d i s t r i b u t e d in the hope t h a t i t w i l l be useful , 11 but WITHOUT ANY WARRANTY; without even the implied warranty of 12 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 13 GNU General Public L i c e n s e f o r more d e t a i l s . 14 15 You should have r e c e i v e d a copy o f the GNU General Public License 16 along with obdgpslogger . I f not , s e e <h t t p ://www. gnu . org/ l i c e n s e s / >. 17 / 18 19

71

20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

/ \ f i l e \ b r i e f database s t u f f / #include " database . h" #include " s q l i t e 3 . h" #include < s t d i o . h> #include < s t d l i b . h> #include < s t r i n g . h>

s q l i t e 3 opendb ( const char dbfilename ) { // s q l i t e database s q l i t e 3 db ; // s q l i t e return s t a t u s int r c ; r c = s q l i t e 3 _ o p e n ( dbfilename , &db ) ; i f ( SQLITE_OK != r c ) { f p r i n t f ( stderr , " Error : Cannot open database %s : %s\n" , dbfilename , s q l i t e 3 _ e r r m s g ( db )); s q l i t e 3 _ c l o s e ( db ) ; return NULL; } // Just a l i t t l e timeout t o g i v e s q l i t e a chance // t o f i x t h i n g s i f someone s scraping the database s q l i t e 3 _ b u s y _ t i m e o u t ( db , 1 ) ; return db ; } void c l o s e d b ( s q l i t e 3 db ) { s q l i t e 3 _ c l o s e ( db ) ; } int flush_db ( char db_path , const double endtime ) { s q l i t e 3 db ; const char c o n s t s q l [ ] = "BEGIN TRANSACTION; " "DELETE FROM obd WHERE time < %11.5 f ; " "DELETE FROM gps WHERE time < %11.5 f ; "

42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

72

61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 }

"DELETE FROM t r i p WHERE end < %11.5 f AND end > 0 ; " "END TRANSACTION; " ; char s q l [ 1 8 7 ] ; char s q l e r r o r ; i f ( ( db = opendb ( db_path ) ) == NULL) { perror ( " Error opening database " ) ; return 1 ; } s p r i n t f ( sql , c o n s t s q l , endtime , endtime , endtime ) ; // p r i n t f ( "SQL: %s\n " , s q l ) ; i f ( s q l i t e 3 _ e x e c ( db , sql , NULL, NULL, &s q l e r r o r ) != SQLITE_OK) { perror ( s q l e r r o r ) ; sqlite3_free ( sqlerror ) ; return 1 ; } c l o s e d b ( db ) ; return 0 ;

I.5
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

networking.h

/ NETWORKING.H Author : A l c i d e s Carlos de Moraes Neto This f i l e i s part o f o b d t e l e m e t r y c l i e n t / #ifndef _NETWORKING_H #define _NETWORKING_H #include #include #include #include #include #include #include < s t d i o . h> < s t d l i b . h> <unistd . h> <errno . h> < s t r i n g . h> <netdb . h> <sys / types . h>

73

17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

#include < n e t i n e t / in . h> #include <sys / s o c k e t . h> #include <arpa / i n e t . h> #define PORT " 22490 " #ifdef __cplusplus extern "C" { #endif // g e t s o c k e t address void get_in_addr ( struct sockaddr sa ) ; // c onnect a new s o c k e t in s o c k f d t o hostname int c o n ne c t s o c ke t ( char hostname , int sockfd ) ; // r e c e i v e data and check i f a l l b y t e s were r e c e i v e d int recv_chk ( int sockfd , void b u f f e r , s s i z e _ t len , int flags ) ;

35 36 // send data and check i f a l l b y t e s were s e n t 37 int send_chk ( int sockfd , const void data , s s i z e _ t len , int flags ) ; 38 39 / send FILE f through s o c k e t sock , in p i e c e s o f s i z e buflen , by t h e s e s t e p s : 40 1 Send f i l e s i z e as i n t 41 2 Send b u f l e n b y t e s o f FILE f 42 3 Recv ACK in the form o f i n t 43 I f i t s the number o f the p i e c e , send the next one 44 I f i t s d i f f e r e n t , i t means t h e r e was an e r r o r . Send the l a s t p i e c e again . 45 / 46 int s e n d _ f i l e ( FILE f , int sock , s i z e _ t buflen ) ; 47 48 # i f d e f _ _ c p l u s p l u s 49 } 50 #endif 51 52 #endif / _NETWORKING_H /

74

I.6
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

networking.c

/ NETWORKING.C Author : A l c i d e s Carlos de Moraes Neto This f i l e i s part o f o b d t e l e m e t r y c l i e n t / #include " networking . h" void get_in_addr ( struct sockaddr sa ) { i f ( sa>sa_family == AF_INET) { return & ( ( ( struct sockaddr_in ) sa )>sin_addr ) ; } return & ( ( ( struct sockaddr_in6 ) sa )>sin6_addr ) ; } int c o n ne c t s o c k et ( char hostname , int sockfd ) { struct addrinfo hints , s e r v i n f o , p ; int rv ; char s [INET6_ADDRSTRLEN ] ; memset(& hints , 0 , sizeof h i n t s ) ; h i n t s . a i _ f a m i l y = AF_UNSPEC; h i n t s . a i _ s o c k t y p e = SOCK_STREAM; i f ( ( rv = g e t a d d r i n f o ( hostname , PORT, &hints , &s e r v i n f o ) ) != 0 ) { f p r i n t f ( stderr , " g e t a d d r i n f o : %s\n" , g a i _ s t r e r r o r ( rv )); return 1; } // loop through a l l the r e s u l t s and connect t o the f i r s t we can for ( p = s e r v i n f o ; p != NULL; p = p>ai_next ) { i f ( ( sockfd = s o c k e t ( p>ai_family , p>ai_socktype , p>a i _ p r o t o c o l ) ) == 1) { perror ( " c l i e n t : s o c k e t " ) ; continue ; }

75

40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

i f ( connect ( sockfd , p>ai_addr , p>ai_addrlen ) == 1) { c l o s e ( sockfd ) ; perror ( " c l i e n t : connect " ) ; continue ; } break ; } i f ( p == NULL) { f p r i n t f ( stderr , " c l i e n t : f a i l e d t o connect\n" ) ; return 1; } i n e t _ n t o p ( p>ai_family , get_in_addr ( ( struct sockaddr ) p >ai_addr ) , s , sizeof s ) ; p r i n t f ( " c l i e n t : connecting t o %s\n" , s ) ;

56 57 58 59 f r e e a d d r i n f o ( s e r v i n f o ) ; // a l l done with t h i s s t r u c t u r e 60 return 0 ; 61 } 62 63 64 int recv_chk ( int sockfd , void b u f f e r , s s i z e _ t len , int flags ) { 65 s s i z e _ t recvd =0; 66 recvd = recv ( sockfd , b u f f e r , len , f l a g s ) ; 67 i f ( recvd < len ) { 68 perror ( " recv returned l e s s than expected " ) ; 69 return 1; 70 } 71 return 0 ; 72 } 73 74 int send_chk ( int sockfd , const void b u f f e r , s s i z e _ t len , int f l a g s ) { 75 s s i z e _ t sent =0; 76 sent = send ( sockfd , b u f f e r , len , f l a g s ) ; 77 i f ( sent < len ) { 78 perror ( " send returned l e s s than expected " ) ; 79 return 1;

76

80 81 82 } 83 84 int 85 { 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122

} return 0 ;

s e n d _ f i l e ( FILE f , int sock , s i z e _ t buflen ) char buf [ buflen ] ; s s i z e _ t len ; long int f i l e l e n ; int ack =0 , i =0; // f i n d i n g out f i l e s i z e f s e e k ( f , 0 , SEEK_END) ; p r i n t f ( " Sending f i l e s i z e : %d . \n" , f t e l l ( f ) ) ; f i l e l e n = htonl ( f t e l l ( f ) ) ; f s e e k ( f , 0 , SEEK_SET) ; // f i r s t thing s e n t i s f i l e s i z e i f ( send_chk ( sock , &f i l e l e n , sizeof ( long int ) , 0 ) < 0 ) { perror ( " Error sending f i l e s i z e . " ) ; return ( 1 ) ; } p r i n t f ( " F i l e s i z e sent . Sending f i l e . . . \ n" ) ; while ( ( len = fread ( buf , sizeof ( char ) , buflen , f ) ) > 0 ) { do { i f ( send ( sock , buf , len , 0 ) < 0 ) { perror ( " Error sending data . " ) ; return ( 1 ) ; } // r e c e i v i n g ACK. I f ack == p i e c e number ( i ) , then proceed . // I f i t s not , send again . recv_chk ( sock , &ack , sizeof ( int ) , 0 ) ; } while ( ntohl ( ack ) != i ) ; i ++; } if ( ferror ( f ) ) { perror ( " Error reading f i l e . " ) ; return ( 1 ) ; } return ( 0 ) ;

77

123 }

78

Anexo II Cdigo-fonte do servidor

II.1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Main.java

/ Main . java Author : A l c i d e s Carlos de Moraes Neto This f i l e i s part o f OBD Telemetry Server / package obdTelemetryServer ; import import import import import import import java . i o . F i l e ; java . i o . FileReader ; java . i o . IOException ; java . net . ServerSocket ; java . u t i l . P r o p e r t i e s ; java . u t i l . l o g g i n g . Level ; java . u t i l . l o g g i n g . Logger ;

/ @author A l c i d e s Carlos de Moraes Neto / public class Main { / @param args the command l i n e arguments / public s t a t i c void main ( String [ ] args ) { ServerSocket srvSock = null ; // Configuration //

79

30 31 32 33 34 35 36 37 38 39 40 41

42 43 44 45 46 47 48 49

50 51 52 53 54 55 56 57 58

59 60 61 62 63 64 65 66 67

// d e f a u l t s int b u f f e r = 1024; int port = 22490; String logsPath = "C:\\ obdlogs\\ " ; // f i l e F i l e f = new F i l e ( " obdtelemetryserver . c f g " ) ; i f ( f . canRead ( ) ) { P r o p e r t i e s c o n f i g = new P r o p e r t i e s ( ) ; try { c o n f i g . load (new FileReader ( f ) ) ; } catch ( IOException ex ) { System . e r r . p r i n t l n ( " Error reading c o n f i g u r a t i o n f i l e : " + ex . getLocalizedMessage ( ) ) ; System . e x i t ( 1 ) ; } String cfgValue = c o n f i g . getProperty ( " b u f f e r " ) ; i f ( cfgValue != null ) { try { b u f f e r = I n t e g e r . parseInt ( cfgValue ) ; } catch ( Exception e ) { System . e r r . p r i n t l n ( " Error reading configuration f i l e : Invalid buffer attribute . " ) ; System . e x i t ( 1 ) ; } } cfgValue = c o n f i g . getProperty ( " port " ) ; i f ( cfgValue != null ) { try { port = I n t e g e r . parseInt ( cfgValue ) ; } catch ( Exception e ) { System . e r r . p r i n t l n ( " Error reading c o n f i g u r a t i o n f i l e : I n v a l i d port attribute . " ) ; System . e x i t ( 1 ) ; } } cfgValue = c o n f i g . getProperty ( " logsPath " ) ; i f ( cfgValue != null ) logsPath = cfgValue ; } try { srvSock = new ServerSocket ( port ) ;

80

68 69 70 71 72 73 74 75 76 77 78

} catch ( IOException ex ) { System . e r r . p r i n t l n ( " Error l i s t e n i n g on port 22490. " ) ; System . e x i t ( 1 ) ; } System . out . p r i n t l n ( " Waiting f o r c o n n e c t i o n s . . . " ) ; while ( ! srvSock . i s C l o s e d ( ) ) { try { new ServerThread ( srvSock . accept ( ) , b u f f e r , logsPath ) . s t a r t ( ) ; } catch ( IOException ex ) { System . e r r . p r i n t l n ( " Error a c c e p t i n g connection : " + ex . getLocalizedMessage ( ) ) ; continue ; } } }

79 80 81 82 83 84 }

II.2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

ServerThread.java

/ ServerThread . java Author : A l c i d e s Carlos de Moraes Neto This f i l e i s part o f OBD Telemetry Server / package obdTelemetryServer ; import import import import import import import import import import au . com . bytecode . opencsv . CSVReader ; java . i o . DataInputStream ; java . i o . F i l e ; java . i o . FileInputStream ; java . i o . FileOutputStream ; java . i o . FileReader ; java . i o . IOException ; java . i o . OutputStream ; java . net . Socket ; java . u t i l . ArrayList ;

81

19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

import import import import import

java . u t i l . Date ; java . u t i l . z i p . GZIPInputStream ; obdTelemetryServer . beans . Vehicle ; obdTelemetryServer . db . ObdDao ; obdTelemetryServer . db . VehicleDao ;

/ @author A l c i d e s Carlos de Moraes Neto / public class ServerThread extends Thread { // CLIENT COMMANDS // private s t a t i c final int private s t a t i c final int private s t a t i c final int private s t a t i c final int private s t a t i c final int private s t a t i c final int

CMD_SEND_LICENSE = 1 ; CMD_RECV_BUFFERSZ = 2 ; CMD_SEND_NUMFILES = 3 ; CMD_SEND_FILES = 4 ; CMD_RECV_SLEEPTM = 5 ; CMD_BYE = 9 9 ;

private final Socket sock ; private final int b u f f e r ; private final String logsPath ; ServerThread ( Socket sock , int b u f f e r , String logsPath ) { this . sock = sock ; this . b u f f e r = b u f f e r ; this . logsPath = logsPath ; } @Override public void run ( ) { i f ( this . sock == null ) { throw new NullPointerException ( " Socket i s n u l l " ) ; } Date now = new Date ( ) ; OutputStream sockOut = null ; DataInputStream sockDataIn = null ; try { System . out . p r i n t l n ( "New connection from " + this . sock . getInetAddress ( ) . getHostAddress ( ) ) ;

82

61 62 63 64 65

//sockOut = new BufferedOutputStream ( t h i s . sock . getOutputStream ( ) ) ; sockOut = this . sock . getOutputStream ( ) ; sockDataIn = new DataInputStream ( this . sock . getInputStream ( ) ) ; //sockStrIn = new BufferedReader ( new InputStreamReader ( t h i s . sock . getInputStream ( ) ) ); System . out . p r i n t ( " Receiving v e h i c l e l i c e n s e . . . " ) ; sockOut . write (CMD_SEND_LICENSE) ; byte l i c e n s e B y t e s [ ] = new byte [ 8 ] ; sockDataIn . read ( l i c e n s e B y t e s ) ; String l i c e n s e = new String ( l i c e n s e B y t e s ) . trim ( ) ; System . out . p r i n t l n ( " done . Value : " + l i c e n s e ) ; Vehicle v = new VehicleDao ( ) . g e t V e h i c l e ( l i c e n s e ) ; i f ( v == null ) { System . out . p r i n t l n ( " Vehicle not r e g i s t e r e d , c l o s i n g connection . " ) ; this . sock . c l o s e ( ) ; return ; } System . out . p r i n t l n ( " Vehicle : " + v . g e t D e s c r i p t i o n ( ) + " ( i d = " + v . getId ( ) + " ) " ) ; System . out . p r i n t ( " Sending b u f f e r s i z e . . . " ) ; sockOut . write (CMD_RECV_BUFFERSZ) ; sockOut . write ( intToByteArray ( b u f f e r ) ) ; System . out . p r i n t l n ( " done . " ) ; System . out . p r i n t ( " Receiving number o f f i l e s . . . " ) ; sockOut . write (CMD_SEND_NUMFILES) ; int f i l e s Q t = sockDataIn . readInt ( ) ; System . out . p r i n t l n ( " done . Value : " + f i l e s Q t ) ; System . out . p r i n t l n ( " Receiving f i l e s . . . " ) ;

66 67 68 69 70 71 72 73 74 75 76 77 78 79 80

81 82 83 84 85 86 87 88 89 90 91 92 93

83

sockOut . write (CMD_SEND_FILES) ; for ( int i =0; i < f i l e s Q t ; i ++) { //R e c e i v e gz ed f i l e , uncompress and d e l e t e it 99 F i l e gz = new F i l e ( logsPath + " obd_ " + l i c e n s e + " _ " + now . getTime ( ) + " _ " + i + " . csv . gz " ) ; 100 System . out . p r i n t l n ( "New gz f i l e : " + gz . getCanonicalPath ( ) ) ; 101 r e c e i v e F i l e ( sockDataIn , sockOut , gz ) ; 102 F i l e f = uncompressFile ( gz ) ; 103 // i f ( ! gz . d e l e t e ( ) ) { 104 // throw new IOException ( " Could not d e l e t e f i l e " + gz . getCanonicalPath ( ) ) ; 105 // } 106 // Add f i l e s t o a l i s t t o be p r o c e s s e d a f t e r sending bye message t o c l i e n t , 107 // because i t can take a while . 108 f i l e s . add ( f ) ; 109 } 110 111 sockOut . write (CMD_BYE) ; 112 113 for ( F i l e f : f i l e s ) { 114 //Save CSV data do DB and d e l e t e the f i l e 115 storeData ( v , f ) ; 116 if ( ! f . delete ( ) ) { 117 throw new IOException ( " Could not d e l e t e f i l e " + f . getCanonicalPath ( ) ) ; 118 } 119 } 120 121 } catch ( IOException ex ) { 122 System . e r r . p r i n t l n ( " Error during s o c k e t or f i l e IO o p e r a t i o n : " + ex . getLocalizedMessage ( ) ) ; 123 ex . printStackTrace ( ) ; 124 return ; 125 } finally { 126 try { 127 i f ( sockOut != null ) sockOut . c l o s e ( ) ; 128 i f ( sockDataIn != null ) sockDataIn . c l o s e ( ) ; 129 this . sock . c l o s e ( ) ;

94 95 96 97 98

ArrayList <Fi le > f i l e s = new ArrayList <F il e > ( ) ;

84

130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167

} catch ( Exception ex ) { } } } private byte [ ] intToByteArray ( int value ) { return new byte [ ] { ( byte ) ( value >>> 24) , ( byte ) ( value >> 16 & 0 x f f ) , ( byte ) ( value >> 8 & 0 x f f ) , ( byte ) ( value & 0 x f f ) }; } private void r e c e i v e F i l e ( DataInputStream sockIn , OutputStream sockOut , F i l e f ) throws IOException { FileOutputStream fOut = null ; try { System . out . p r i n t ( " Receiving f i l e s i z e . . . " ) ; int f i l e S i z e = sockIn . readInt ( ) ; System . out . p r i n t l n ( " done . Value : " + f i l e S i z e ) ; // Calculating f i l e p i e c e s int p i e c e s ; int l a s t P i e c e S i z e ; pieces = f i l e S i z e / buffer ; lastPieceSize = f i l e S i z e % buffer ; fOut = new FileOutputStream ( f ) ; Date s t a r t = new Date ( ) ; for ( int i = 0 ; i < p i e c e s ; i ++) { r e c e i v e F i l e P i e c e ( sockIn , sockOut , fOut , i , buffer ) ; } i f ( lastPieceSize > 0) { r e c e i v e F i l e P i e c e ( sockIn , sockOut , fOut , pi ec es , l a s t P i e c e S i z e ) ; } long time = new Date ( ) . getTime ( ) s t a r t . getTime () ; fOut . c l o s e ( ) ; System . out . p r i n t l n ( " Finished f i l e . Time taken : " + time + "ms" ) ;

85

168 169 170 171 172 173 174 175 176 177 178

System . out . p r i n t l n ( " Transfer r a t e : " + ( ( ( f l o a t ) f i l e S i z e ) / time ) + " b / ms ( kb / s ) " ) ; } catch ( IOException ex ) { i f ( fOut != null ) { fOut . c l o s e ( ) ; f . delete ( ) ; } throw new IOException ( " F i l e or Socket stream IO Error while r e c e i v i n g f i l e . " , ex ) ; } } private void r e c e i v e F i l e P i e c e ( DataInputStream sockIn , OutputStream sockOut , FileOutputStream fOut , int number , int length ) throws IOException { byte [ ] inBuf = new byte [ length ] ; int bytesRead = 0 ; while ( ( bytesRead = sockIn . read ( inBuf ) ) < length ) { i f ( bytesRead == 1) { throw new IOException ( " Unexpected EOF in s o c k e t input stream . " ) ; } sockOut . write ( intToByteArray ( 1) ) ; } fOut . write ( inBuf ) ; sockOut . write ( intToByteArray ( number ) ) ; } private F i l e uncompressFile ( F i l e gz ) throws IOException { GZIPInputStream gzin = new GZIPInputStream (new FileInputStream ( gz ) ) ; // F i l e f = new F i l e ( gz . getCanonicalPath ( ) . r e p l a c e F i r s t ( " . gz " , " " ) ) ; //Remove . gz e x t e n s i o n F i l e f = new F i l e ( gz . getCanonicalPath ( ) . s u b s t r i n g ( 0 , gz . getCanonicalPath ( ) . length ( ) 3) ) ; FileOutputStream f o u t = new FileOutputStream ( f ) ; int data = gzin . read ( ) ; while ( data != 1) { f o u t . write ( data ) ; data = gzin . read ( ) ; } gzin . c l o s e ( ) ;

179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202

86

203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 }

fout . close ( ) ; return f ; } private void storeData ( Vehicle v , F i l e f ) throws IOException { CSVReader c s v r = new CSVReader (new FileReader ( f ) ) ; ObdDao obddao = new ObdDao ( getCsvObdColumns ( c s v r . readNext ( ) ) ) ; String [ ] l i n e = c s v r . readNext ( ) ; while ( l i n e != null ) { i f ( ! obddao . storeCsvLine ( v . getId ( ) , l i n e ) ) { System . e r r . p r i n t l n ( " Error s t o r i n g csv l i n e . " ); } l i n e = c s v r . readNext ( ) ; } csvr . close ( ) ; } // Get obd column names from csv , without the " obd . " prefix . private String [ ] getCsvObdColumns ( String [ ] csvcolumns ) { int len =0; //Counting " obd . " columns while ( len < csvcolumns . length && csvcolumns [ len ] . startsWith ( " obd . " ) ) len ++; String [ ] toReturn = new String [ len ] ; for ( int i = 0 ; i < toReturn . length ; i ++) { toReturn [ i ] = csvcolumns [ i ] . r e p l a c e F i r s t ( " obd . " , "") ; } return toReturn ; }

II.3

DbConnector.java

1 / 2 DbConnector . java 3 Author : A l c i d e s Carlos de Moraes Neto

87

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

This f i l e i s part o f OBD Telemetry Server / package obdTelemetryServer . db ; import import import import import java . s q l . Connection ; java . s q l . DriverManager ; java . s q l . PreparedStatement ; java . s q l . SQLException ; java . s q l . Statement ;

/ @author A l c i d e s Carlos de Moraes Neto / public class DbConnector { private s t a t i c final String Driver " ; private s t a t i c final String l o c a l h o s t / karmonitor " ; private s t a t i c final String private s t a t i c final String private Connection conn ; public DbConnector ( ) throws SQLException { this (DB_DRV, DB_URL, DB_USR, DB_PWD) ; } public DbConnector ( String driver , String url , String user , String passwd ) throws SQLException { try { Class . forName ( d r i v e r ) ; conn = DriverManager . getConnection ( url , user , passwd ) ; conn . setAutoCommit ( false ) ; } catch ( ClassNotFoundException ex ) { throw new RuntimeException ( " Could not load DB d r i v e r " + driver , ex ) ; } } @Override protected void f i n a l i z e ( ) throws Throwable { DB_DRV = " org . p o s t g r e s q l . DB_URL = " j d b c : p o s t g r e s q l : / / DB_USR = " karmonitor " ; DB_PWD = " karmonitor " ;

88

43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 }

conn . r o l l b a c k ( ) ; conn . c l o s e ( ) ; } public void commit ( ) throws SQLException { conn . commit ( ) ; } public Statement createStatement ( ) throws SQLException { return conn . createStatement ( ) ; } public PreparedStatement prepareStatement ( String s q l ) throws SQLException { return conn . prepareStatement ( s q l ) ; } / Execute prepared statement t h a t i s an update . @param s t Prepared statement with a l l f i e l d s s e t @return t r u e i f the statement e x e c u t i o n r e t u r n s an update @throws SQLException / public boolean executePreparedStatementUpdate ( PreparedStatement s t ) throws SQLException { i f ( s t == null ) { throw new NullPointerException ( " PreparedStatement s t i s n u l l . " ) ; } boolean r e s u l t = ! s t . execute ( ) ; st . close ( ) ; return r e s u l t ; }

II.4

ObdDao.java

1 / 2 ObdDao . java 3 Author : A l c i d e s Carlos de Moraes Neto

89

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

This f i l e i s part o f OBD Telemetry Server / package obdTelemetryServer . db ; import java . math . BigDecimal ; import java . s q l . PreparedStatement ; / @author A l c i d e s Carlos de Moraes Neto / public class ObdDao { private String i n s e r t S q l ; private int numObdColumns ; public ObdDao ( String [ ] obdColumns ) { i n s e r t S q l = "INSERT INTO \"OBDGPSDATA\" ( \ " id_vehicle \" , " ; //obd columns from csv i n t o s q l for ( int i = 0 ; i < obdColumns . length ; i ++) { i n s e r t S q l += " \" " + obdColumns [ i ] + " \ " , " ; } i n s e r t S q l += " \" gps_lon \ " , \ " g p s _ l a t \ " , \ " g p s _ a l t \ " ) VALUES ( ? , " ; for ( int i = 0 ; i < obdColumns . length ; i ++) { i n s e r t S q l += " ? , " ; } i n s e r t S q l += " ? , ? , ? ) " ; numObdColumns = obdColumns . length ; System . out . p r i n t l n ( "ObdDao . i n s e r t S q l : " + i n s e r t S q l ) ; } public boolean storeCsvLine ( int v e h i c l e I d , String [ ] l i n e ) { DbConnector db=null ; PreparedStatement s t =null ; try { db = new DbConnector ( ) ; s t = db . prepareStatement ( i n s e r t S q l ) ; st . setInt (1 , vehicleId ) ; // Obd columns are f i r s t in CSV

90

44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 }

for ( int i = 0 ; i < numObdColumns ; i ++) { // s t . s e t F l o a t ( i +2 , Float . parseFloat ( l i n e [ i ] ) ); BigDecimal bd = new BigDecimal ( l i n e [ i ] ) ; s t . setBigDecimal ( i +2 , bd ) ; } //gps and t r i p are the l a s t ones s t . s e t F l o a t ( numObdColumns+2 , Float . parseFloat ( l i n e [ l i n e . length 4]) ) ; //gps . lon s t . s e t F l o a t ( numObdColumns+3 , Float . parseFloat ( l i n e [ l i n e . length 3]) ) ; //gps . l a t s t . s e t F l o a t ( numObdColumns+4 , Float . parseFloat ( l i n e [ l i n e . length 2]) ) ; //gps . a l t boolean r e s u l t = db . executePreparedStatementUpdate ( s t ) ; i f ( r e s u l t ) db . commit ( ) ; return r e s u l t ; } catch ( Exception ex ) { System . e r r . p r i n t l n ( " Error s t o r i n g csv l i n e : " + ex . getLocalizedMessage ( ) ) ; ex . printStackTrace ( ) ; return false ; } }

II.5

Vehicle.java

1 / 2 V e h i c l e . java 3 Author : A l c i d e s Carlos de Moraes Neto 4 This f i l e i s part o f OBD Telemetry Server 5 / 6 7 package obdTelemetryServer . beans ; 8 9 / 10 11 @author A l c i d e s Carlos de Moraes Neto 12 /

91

13 public class Vehicle { 14 15 private int i d ; 16 private String l i c e n s e ; 17 private String d e s c r i p t i o n ; 18 19 / 20 @return the id 21 / 22 public int getId ( ) { 23 return i d ; 24 } 25 26 / 27 @param id the id t o s e t 28 / 29 public void s e t I d ( int i d ) { 30 this . i d = i d ; 31 } 32 33 / 34 @return the l i c e n s e 35 / 36 public String getLicense ( ) { 37 return l i c e n s e ; 38 } 39 40 / 41 @param l i c e n s e the l i c e n s e t o s e t 42 / 43 public void s e t L i c e n s e ( String l i c e n s e ) { 44 this . l i c e n s e = l i c e n s e ; 45 } 46 47 / 48 @return the d e s c r i p t i o n 49 / 50 public String g e t D e s c r i p t i o n ( ) { 51 return d e s c r i p t i o n ; 52 } 53 54 / 55 @param d e s c r i p t i o n the d e s c r i p t i o n t o s e t 56 /

92

57 58 59 60 61 }

public void s e t D e s c r i p t i o n ( String d e s c r i p t i o n ) { this . d e s c r i p t i o n = d e s c r i p t i o n ; }

II.6
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

VehicleDao.java

/ VehicleDao . java Author : A l c i d e s Carlos de Moraes Neto This f i l e i s part o f OBD Telemetry Server / package obdTelemetryServer . db ; import import import import java . s q l . PreparedStatement ; java . s q l . ResultSet ; java . s q l . SQLException ; obdTelemetryServer . beans . Vehicle ;

/ @author A l c i d e s Carlos de Moraes Neto / public class VehicleDao { public Vehicle g e t V e h i c l e ( String l i c e n s e ) { try { String s q l = "SELECT id , d e s c r i p t i o n FROM \" VEHICLE\" " + " WHERE l i c e n s e = ? " ; DbConnector db = new DbConnector ( ) ; PreparedStatement s t = db . prepareStatement ( s q l ) ; st . setString (1 , license ) ; ResultSet rs = s t . executeQuery ( ) ; Vehicle v = null ; i f ( rs . next ( ) ) { v = new Vehicle ( ) ; v . s e t I d ( rs . g e t I n t ( " i d " ) ) ; v . setLicense ( license ) ;

93

33 34 35 36 37 38 39 40 41 42 43 44 }

v . s e t D e s c r i p t i o n ( rs . g e t S t r i n g ( " d e s c r i p t i o n " ) ); } rs . c l o s e ( ) ; st . close ( ) ; return v ; } catch ( SQLException ex ) { System . out . p r i n t l n ( "SQL EXCEPTION: " + ex . getLocalizedMessage ( ) ) ; throw new RuntimeException ( ex ) ; } }

94

Anexo III Tabelas do banco de dados do servidor

Tabelas criadas no banco PostgreSQL, para armazenamento de dados OBD pelo servidor.

III.1
1 2 3 4 5 6 7 8 9 10 11 12

Tabela VEHICLE

CREATE TABLE "VEHICLE" ( i d s e r i a l NOT NULL, l i c e n s e character ( 7 ) NOT NULL, d e s c r i p t i o n text , CONSTRAINT "VEHICLE_pkey" PRIMARY KEY ( i d ) , CONSTRAINT " VEHICLE_license_key " UNIQUE ( l i c e n s e ) ) WITH ( OIDS=FALSE );

III.2

Tabela OBDGPSDATA

1 2 3 CREATE TABLE "OBDGPSDATA" 4 ( 5 i d _ v e h i c l e integer NOT NULL, 6 g p s _ l a t numeric NOT NULL,

95

7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

gps_lon numeric NOT NULL, g p s _ a l t numeric NOT NULL, d t c f r z f integer , DTC t h a t caused r e q u i r e d f r e e z e frame data s t o r a g e f u e l s y s integer , Fuel system 1 and 2 s t a t u s l o a d _ p c t numeric ( 9 , 6 ) , Calculated LOAD Value " temp " integer , Engine Coolant Temperature s h r t f t 1 3 numeric ( 9 , 6 ) , Short Term Fuel Trim Bank 1 ,3 l o n g f t 1 3 numeric ( 9 , 6 ) , Long Term Fuel Trim Bank 1 ,3 s h r t f t 2 4 numeric ( 9 , 6 ) , Short Term Fuel Trim Bank 2 ,4 l o n g f t 2 4 numeric ( 9 , 6 ) , Long Term Fuel Trim Bank 2 ,4 f r p integer , Fuel Rail Pressure ( gauge ) map integer , Intake Manifold Absolute Pressure rpm numeric ( 7 , 2 ) , Engine RPM vss integer , V e h i c l e Speed Sensor sparkadv numeric ( 3 , 1 ) , I g n i t i o n Timing Advance f o r #1 Cylinder i a t integer , Intake Air Temperature maf numeric ( 9 , 6 ) , Air Flow Rate from Mass Air Flow Sensor t h r o t t l e p o s numeric ( 9 , 6 ) , Absolute T h r o t t l e P o s i t i o n a i r _ s t a t integer , Commanded Secondary Air Status o 2 s l o c integer , Location o f Oxygen Sensors o2s11 numeric ( 6 , 3 ) , Bank 1 Sensor 1/Bank 1 Sensor 1 Oxygen Sensor Output Voltage / Short Term Fuel Trim o2s12 numeric ( 6 , 3 ) , Bank 1 Sensor 2/Bank 1 Sensor 2 Oxygen Sensor Output Voltage / Short Term Fuel Trim o2s13 numeric ( 6 , 3 ) , Bank 1 Sensor 3/Bank 2 Sensor 1 Oxygen Sensor Output Voltage / Short Term Fuel Trim o2s14 numeric ( 6 , 3 ) , Bank 1 Sensor 4/Bank 2 Sensor 2 Oxygen Sensor Output Voltage / Short Term Fuel Trim o2s21 numeric ( 6 , 3 ) , Bank 2 Sensor 1/Bank 3 Sensor 1 Oxygen Sensor Output Voltage / Short Term Fuel Trim o2s22 numeric ( 6 , 3 ) , Bank 2 Sensor 2/Bank 3 Sensor 2 Oxygen Sensor Output Voltage / Short Term Fuel Trim o2s23 numeric ( 6 , 3 ) , Bank 2 Sensor 3/Bank 4 Sensor 1 Oxygen Sensor Output Voltage / Short Term Fuel Trim o2s24 numeric ( 6 , 3 ) , Bank 2 Sensor 4/Bank 4 Sensor 2 Oxygen Sensor Output Voltage / Short Term Fuel Trim obdsup integer , OBD requirements t o which v e h i c l e i s designed o 2 s l o c 2 integer , Location o f oxygen s e n s o r s p t o _ s t a t integer , A u x i l i a r y Input Status runtm integer , Time Since Engine S t a r t

96

39 40 41 42

43

44

45

46

47

48

49

50 51 52 53 54 55 56 57 58

m i l _ d i s t integer , Distance T r a v e l l e d While MIL i s Activated f r p r numeric ( 7 , 3 ) , Fuel Rail Pressure r e l a t i v e t o manifold vacuum frpd integer , Fuel Rail Pressure ( d i e s e l ) lambda11 numeric ( 8 , 7 ) , Bank 1 Sensor 1/Bank 1 Sensor 1 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Voltage lambda12 numeric ( 8 , 7 ) , Bank 1 Sensor 2/Bank 1 Sensor 2 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Voltage lambda13 numeric ( 8 , 7 ) , Bank 1 Sensor 3 /Bank 2 Sensor 1 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Voltage lambda14 numeric ( 8 , 7 ) , Bank 1 Sensor 4 /Bank 2 Sensor 2 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Voltage lambda21 numeric ( 8 , 7 ) , Bank 2 Sensor 1 /Bank 3 Sensor 1 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Voltage lambda22 numeric ( 8 , 7 ) , Bank 2 Sensor 2 /Bank 3 Sensor 2 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Voltage lambda23 numeric ( 8 , 7 ) , Bank 2 Sensor 3 /Bank 4 Sensor 1 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Voltage lambda24 numeric ( 8 , 7 ) , Bank 2 Sensor 4 /Bank 4 Sensor 2 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Voltage e g r _ p c t numeric ( 9 , 6 ) , Commanded EGR e g r _ e r r numeric ( 9 , 6 ) , EGR Error evap_pct numeric ( 9 , 6 ) , Commanded Evaporative Purge f l i numeric ( 9 , 6 ) , Fuel Level Input warm_ups smallint , Number o f warmups s i n c e d i a g n o s t i c t r o u b l e codes c l e a r e d c l r _ d i s t integer , Distance s i n c e d i a g n o s t i c t r o u b l e codes c l e a r e d evap_vp numeric ( 6 , 2 ) , Evap System Vapour Pressure baro smallint , Barometric Pressure lambdac11 numeric ( 1 1 , 8 ) , Bank 1 Sensor 1/Bank 1 Sensor 1 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Current

97

59

60

61

62

63

64

65

66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81

lambdac12 numeric ( 1 1 , 8 ) , Bank 1 Sensor 2/Bank 1 Sensor 2 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Current lambdac13 numeric ( 1 1 , 8 ) , Bank 1 Sensor 3/Bank 2 Sensor 1 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Current lambdac14 numeric ( 1 1 , 8 ) , Bank 1 Sensor 4/Bank 2 Sensor 2 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Current lambdac21 numeric ( 1 1 , 8 ) , Bank 2 Sensor 1/Bank 3 Sensor 1 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Current lambdac22 numeric ( 1 1 , 8 ) , Bank 2 Sensor 2/Bank 3 Sensor 2 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Current lambdac23 numeric ( 1 1 , 8 ) , Bank 2 Sensor 3/Bank 4 Sensor 1 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Current lambdac24 numeric ( 1 1 , 8 ) , Bank 2 Sensor 4/Bank 4 Sensor 2 ( wide range O2S) Oxygen Sensors Equivalence Ratio ( lambda ) / Current catemp11 numeric ( 5 , 1 ) , C a t a l y s t Temperature Bank 1 / Sensor 1 catemp21 numeric ( 5 , 1 ) , C a t a l y s t Temperature Bank 2 / Sensor 1 catemp12 numeric ( 5 , 1 ) , C a t a l y s t Temperature Bank 1 / Sensor 2 catemp22 numeric ( 5 , 1 ) , C a t a l y s t Temperature Bank 2 / Sensor 2 vpwr numeric ( 8 , 3 ) , Control module v o l t a g e load_abs numeric ( 9 , 6 ) , Absolute Load Value lambda numeric ( 8 , 7 ) , Fuel/ a i r Commanded Equivalence Ratio tp_r numeric ( 9 , 6 ) , R e l a t i v e T h r o t t l e P o s i t i o n aat smallint , Ambient a i r temperature tp_b numeric ( 9 , 6 ) , Absolute T h r o t t l e P o s i t i o n B tp_c numeric ( 9 , 6 ) , Absolute T h r o t t l e P o s i t i o n C app_d numeric ( 9 , 6 ) , A c c e l e r a t o r Pedal P o s i t i o n D app_e numeric ( 9 , 6 ) , A c c e l e r a t o r Pedal P o s i t i o n E app_f numeric ( 9 , 6 ) , A c c e l e r a t o r Pedal P o s i t i o n F t a c _ p c t numeric ( 9 , 6 ) , Commanded T h r o t t l e Actuator Control mil_time integer , Time run by the engine while MIL activated

98

82 83 84 85 86 87

88 89 90 ) 91 WITH ( 92 OIDS=FALSE 93 ) ;

c l r _ t i m e integer , Time s i n c e d i a g n o s t i c t r o u b l e codes cleared f u e l _ t y p e smallint , Fuel Type a l c h _ p c t numeric ( 9 , 6 ) , Ethanol f u e l % " time " numeric NOT NULL, CONSTRAINT "OBDGPSDATA_pkey" PRIMARY KEY ( i d _ v e h i c l e , " time " ) , CONSTRAINT " OBDGPSDATA_id_vehicle_fkey " FOREIGN KEY ( id_vehicle ) REFERENCES "VEHICLE" ( i d ) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION

99