trochometer
Transcrição
trochometer
TRABALHO DE CONCLUSÃO DO CURSO TÉCNICO DE INFORMÁTICA INTEGRADO AO ENSINO MÉDIO TACHOMETER Gabriela Fontanelli D'Angelo Luiz Henrique Montanher Tiago Lucas Bulgarelli Willian Kazuo Koga Onoue Professora Orientadora: Márcia Cristina dos Santos Ferreira São Caetano do Sul / SP 2013 TACHOMETER Trabalho de Conclusão de Curso apresentado como pré-requisito para obtenção do Diploma de Técnico em Informática. São Caetano do Sul / SP 2013 Dedicamos este trabalho a nossos pais por todo carinho e amor dedicado a nós durante todo este tempo e para todos os nossos professores que tanto admiramos. AGRADECIMENTOS Agradecemos primeiramente a nossas famílias por terem nos proporcionado a oportunidade de estudar e de buscar o conhecimento, realizando mais uma conquista. Aos colegas por terem tornado essa jornada mais agradável. A todos os nossos professores que se dedicaram e repassaram todo o seu conhecimento para que aprendêssemos mais a cada dia. A empresa Eletrotécnica Sacch por ter patrocinado este projeto e nos proporcionado a experiência de trabalhar em conjunto, onde aprendemos muito. A todos, nosso muitíssimo obrigado. RESUMO O projeto é composto por um programa em Java para controle de equipamentos para manutenção automotiva, que realiza medidas de diversos componentes de um veículo automotor. Suas principais funções são: medir a tensão da bateria, as rotações do motor, o tempo de injeção de combustível, o sinal da sonda Lambda, e ainda é um voltímetro multifunção. Através desse equipamento o mecânico será capaz de realizar medições com maior facilidade e praticidade, sendo assim, um equipamento de grande valia para o mercado. Palavras-chave: Equipamentos. Medições. Automotivo. ABSTRACT The project consists of a Java program for automotive maintenance equipments control, which performs measures of several components of an automotive vehicle. Its main functions are: to measure the battery voltage, engine speed, the fuel injection time, the voltage of the Lambda sensor, and a multifunction voltmeter. Through this equipment, the mechanic will be able to perform measurements easily and with more practicity, this way, a equipment of large value for the market. Keywords: Equipments. Measurements. Automotive. LISTA DE ILUSTRAÇÕES Figura 1 – Formato do DTC.......................................................................... 16 Figura 2 – Scanner SPCMAX....................................................................... 17 Figura 3 – Voltímetro.....................................................................................18 Figura 4 – Tacômetro.................................................................................... 19 Figura 5 – Osciloscópio................................................................................ 20 Figura 6 – Válvula injetora de combustível................................................... 26 Figura 7 – Tachometer – Tela Inicial............................................................. 50 Figura 8 – Tachometer – Botão Atualiza....................................................... 51 Figura 9 – Tachometer – Botão Conectar..................................................... 52 Figura 10 – Tachometer – Aba Medições (Tensão da Bateria)..................... 53 Figura 11 – Realizando a Medição............................................................... 54 SUMÁRIO Introdução....................................................................................................................... 10 1. A Informatização nos Aparelhos Eletrônicos de Teste.................................................. 12 1.1 O Surgimento dos Equipamentos de Teste......................................................12 1.2 Equipamentos de Teste Elétricos e Eletrônicos............................................... 12 1.3 Equipamentos de Teste Informatizados........................................................... 13 1.4 A Informatização nas Oficinas Mecânicas....................................................... 13 2. Aparelhos de Medição para Motores Automotivos....................................................... 15 2.1 Scanners.......................................................................................................... 16 2.2 Voltímetro......................................................................................................... 17 2.3 Tacômetro........................................................................................................ 18 2.4 Osciloscópio..................................................................................................... 20 3. A Linguagem Java........................................................................................................ 21 3.1 O que é Java?.................................................................................................. 21 3.2 Surgimento do Java......................................................................................... 21 3.3 Java nos Aparelhos Eletrônicos....................................................................... 22 3.4 Por que Escolhemos a Linguagem Java?....................................................... 23 4. O Tachometer............................................................................................................... 24 4.1 Funções do Tachometer................................................................................... 24 4.1.1 Tensão da bateria............................................................................... 25 4.1.2 Medição das rotações do motor (RPM)..............................................25 4.1.3 Voltímetro multifunção........................................................................ 25 4.1.4 Tempo de injeção............................................................................... 26 4.1.5 Sonda Lambda................................................................................... 26 4.2 Descrição da Comunicação Serial................................................................... 29 4.2.1 O que é comunicação de dados?.......................................................29 4.2.2 Canais de comunicação..................................................................... 30 4.2.3 Comunicação serial............................................................................ 31 4.2.4 Taxa de transferência (Baud Rate).....................................................31 4.2.5 Transmissão assíncrona x Transmissão síncrona............................. 32 4.3 Descrição do Protocolo Serial do Tachometer (Versão 1.0)............................ 35 4.4 Como Utilizar o Software do Tachometer......................................................... 50 Conclusão......................................................................................................................... 56 Referências Bibliográficas................................................................................................ 57 Anexos Anexo A – Cronograma......................................................................................... 59 Anexo B – DFD – Diagrama de Contexto.............................................................. 60 Anexo C – DFD Nível 0.......................................................................................... 61 Anexo D – DFD Nível 1 – Processo 1.................................................................... 62 Anexo E – DFD Nível 1 – Processo 2.................................................................... 63 Anexo F – DFD Nível 1 – Processo 3.................................................................... 64 Anexo G – Ata de Reunião nº1....................................................................…...... 65 Anexo H – Ata de Reunião nº2.................................................................... …...... 66 Anexo I – Ata de Reunião nº3................................................................................ 67 Anexo J – Ata de Reunião nº4............................................................................... 68 Anexo K – Ata de Reunião nº5...............................................................................69 10 Introdução O projeto se enquadra nas áreas de informática e mecatrônica para manutenção automotiva, a parte de software do produto realizada pelo grupo compreende a utilização de Java (software livre), SQLite (banco de dados livre) e protocolos de comunicação. O software desenvolvido engloba um programa em Java para controle de equipamento destinado ao reparador de automóveis, que irá realizar medidas de diversos componentes de um veículo automotor. Suas principais funções são medir a tensão da bateria, as rotações do motor, o tempo de injeção de combustível, o sinal da sonda Lambda, e ainda é um voltímetro multifunção. Este software trabalha em conjunto com um hardware desenvolvido pela empresa Eletrotécnica Sacch Ltda. baseado em um microcontrolador da família AVR da Atmel, ou seja, o mesmo utilizado em kits de aprendizagem como o Arduino. Através de pesquisas realizadas na internet e também com reuniões e visitas diretas à empresa patrocinadora, os integrantes do grupo arrecadaram informações para a construção da ideia e desenvolvimento do projeto. Inicialmente foi tido como base equipamentos similares de outras empresas que atuam no mesmo ramo e também protocolos de comunicação de outros equipamentos da própria empresa patrocinadora. O Tachometer é inédito no mercado brasileiro. Atualmente existem equipamentos similares mas de uso industrial e nenhum voltado especificamente à medição de grandezas de motores de veículos. Este produto será de muita utilidade ao reparador de veículos pois auxiliará o mecânico de forma intuitiva a obter dados dos diversos componentes dos motores para um fácil e preciso diagnóstico de possíveis falhas de componentes dos motores, desta maneira agilizando o processo de identificação e correção das mesmas. Os equipamentos similares de aplicação automotiva operam de forma autônoma sem qualquer tipo de conexão a computadores, tablets ou smartphones, sendo que seu hardware oferece poucos recursos gráficos, de banco de dados e de registros de 11 medições. O Tachometer por outro lado permitirá a conexão a computadores, tablets ou smartphones, possibilitando um enorme ganho de recursos visuais e de banco de dados para armazenamento das medições realizadas pelo equipamento e também armazenamento de informações de diversos componentes a serem medidos. Pelo fato do hardware não possuir displays gráficos e por consequencia também não possuir os componentes necessários ao acionamento do display gráfico, seu custo e seu tamanho serão muito reduzidos, o que é uma enorme vantagem competitiva. 12 1. A Informatização nos Aparelhos Eletrônicos de Teste 1.1 O Surgimento dos Equipamentos de Teste Durante os experimentos que cientistas e engenheiros realizavam no início da descoberta da eletricidade, estes precisavam de algum meio para identificar e quantificar os fenômenos elétricos que estavam sendo descobertos, como por exemplo, a tensão, a corrente, a potência, etc. Portanto o estudo destes fenômenos se deu ao mesmo tempo em que aparatos de teste foram sendo desenvolvidos, pois estes eram essenciais para as novas descobertas. 1.2 Equipamentos de Teste Elétricos e Eletrônicos No início os equipamentos de teste eram puramente elétricos, pois ainda não existia eletrônica, mas em 1883, o invetor americano Thomas Edison, tentando aperfeiçoar a lâmpada de filamento que criou, descobriu acidentalmente o efeito termoiônico, também conhecido como efeito Edison. O efeito termoiônico caracteriza-se pela emissão de elétrons pela superfície de um metal aquecido. A aplicação mais importante do efeito termoiônico foi na construção das válvulas eletrônicas, usadas amplamente em aparelhos de rádio, TV e no primeiro computador eletrônico. Isso permitiu que os equipamentos de teste fossem aperfeiçoados com a utilização de válvulas eletrônicas e portanto passaram a ser equipamentos eletrônicos. Isto se deu por muitos anos, até que na década de 1950 começou a ser utilizado o semicondutor de silício e germânio na substituição das válvulas eletrônicas, que permitiu uma miniaturização e consequentemente uma redução no custo dos equipamentos eletrônicos. 13 1.3 Equipamentos de Teste Informatizados Com a utilização do semicondutor a eletrônica ficou mais barata e infinitamente menor em tamanho, o que permitiu que se criassem chips para diversas aplicações. Entre estas aplicações estava o computador que se tornou cada vez mais poderoso e mais barato, com sua consequente popularização. Mais uma vez os equipamentos de teste se desenvolveram passando a fazer uso de computadores para o processamento e armazenamento dos dados obtidos em suas medições. Hoje em dia, os equipamentos de teste fazem uso intensivo de microcontroladores e microprocessadores para o processamento e análise dos dados medidos, desta forma a informática (software) passou a fazer parte dos equipamentos de teste. Com o advento da Internet e das redes, entre elas as redes Wireless, como Wi-fi e Bluetooth, os equipamentos de teste também passaram a se comunicar com outros equipamentos de testes, outros computadores e até com a Internet. 1.4 A Informatização nas Oficinas Mecânicas A informática nos centros automotivos atende não só a exigência do cliente como da própria oficina, desenvolvida sob uma estrutura inteligente, que contribui para evitar o desperdício de tempo e dinheiro nos serviços de reparação e gestão. Hoje em dia é comum que as oficinas tenham como preocupação a excelência no atendimento e a qualidade dos serviços mecânicos prestados, buscando ajuda na tecnologia, como computadores, equipamentos de diagnóstico e instrumentos de medição que ajudam no dia-a-dia do profissional da reparação, na busca pelo serviço mais confiável para o seu cliente. José Palacio, auditor do IQA (Instituto da Qualidade Automotiva), afirma que a principal finalidade das oficinas investirem em informática é ganhar competitividade e, com isso, se livrarem de um receio que a maioria delas tem: fechar as portas. 14 O auditor esclarece ainda que, antes de adquirir um sistema de gestão informatizado, é importante que tanto o dono da empresa quanto o mecânico sejam qualificados com treinamentos voltados para utilização dos softwares. Além disso, ele deixa claro que hoje em dia não dá mais para conviver sem a tecnologia e a informática, já que alguns procedimentos, como diagnóstico de uma avaria ou a regulagem de um motor, são quase inviáveis e imprecisos se realizados manualmente. Daí a necessidade de equipamentos que sejam simples de operar mas que realizem diagnósticos e medições de formas práticas e precisas. O tempo e a agilidade das informações ligadas à tecnologia são os principais motivos pelas constantes atualizações dos softwares, que acontecem conforme a necessidade de cada empresa. Este é um excelente negócio que ajuda oficinas mecânicas a ganharem novos clientes e deixarem os antigos mais satisfeitos com os serviços prestados, afinal não basta ter apenas um computador, é preciso ter estrutura. 15 2. Aparelhos de Medição para Motores Automotivos Os veículos de hoje em dia são muito diferentes de quando foram inventados a mais de cem anos. Hoje as indústrias automotivas são obrigadas a cumprir rígidas normas com relação a emissão de poluentes, que só são atingidas mediante gerenciamento eletrônico do funcionamento dos motores, portanto os motores dos veículos atuais necessitam de uma central de processamento eletrônico (ECU) e diversos sensores e atuadores para as mais diversas finalidades. Isso tornou a manutenção desses motores bastante complexa, pois os mecânicos necessitam além de ter conhecimentos de mecânica, ter conhecimentos de elétrica e eletrônica, e em alguns casos conhecimentos de software. Para auxiliar o mecânico na manutenção desses motores a indústria de equipamentos de teste vem desenvolvendo equipamentos específicos para a manutenção de motores, os quais realizam medições em sensores e simulam sinais para acionamento de atuadores e sensores. Os equipamentos mais modernos possuem microcontroladores os quais executam software para realização de suas medições. Devido à complexidade dos sistemas de gerenciamento eletrônico, as próprias ECU monitoram seu próprio funcionamento, registrando eventuais anomalias de funcionamento. Tais anomalias podem ser devido à falhas de sensores, de atuadores ou ainda devido a combustível adulterado ou fora de espicificação. Existem ainda anomalias devido ao desgaste de diversos componentes que compõem o motor. Estas anomalias são também disponibilizadas para leitura por equipamentos especializados chamados scanners. 16 2.1 Scanners Os scanners são equipamentos que se conectam às ECUs através de um conector de diagnóstico e se comunicam através de protocolos específicos de comunicação. Dentre os padrões existentes a nível de hardware existe o OBDII (entre outros), o qual foi definido pelos fabricantes de veículos como padrão de hardware para a comunicação com a ECU. Além da padronização do hardware existe também uma tentativa de se padronizar o protocolo de comunicação (software), porém este ainda não foi definido em sua totalidade. Atualmente existe o padrão CAN, o qual vem sendo muito adotado pelos fabricantes de veículos, especialmente os mais novos a partir do ano 2000. Existe ainda uma padronização para leitura e apagamento de código de falhas, os quais são conhecidos como DTC (Data Trouble Code). Os DTCs são códigos compostos por uma letra seguida de quatro dígitos numéricos, de acordo com o diagrama abaixo: Figura 1, Formato do DTC. Fonte: (www.marcusfitzhugh.com) 17 Figura 2, Scanner SPCMAX. Fonte: (www.sacch.com.br) 2.2 Voltímetro O voltímetro é um aparelho que realiza medições de tensão elétrica em um circuito. Ele exibe essas medições, geralmente, por meio de um ponteiro móvel ou um mostrador digital, de cristal líquido (LCD) por exemplo. A unidade apresentada geralmente é o volt. Muitos voltímetros, na verdade, não são nada mais do que amperímetros com alta resistência interna. O projeto dos voltímetros é tal que, com sua alta resistência interna, introduzam o mínimo de alterações no circuito que está sendo monitorado. Assim como um amperímetro indica a corrente que passa por ele, um voltímetro indica a tensão entre seus terminais. Para aferir a diferença de tensão entre dois pontos de um circuito, convém colocar o voltímetro em paralelo com a seção do circuito compreendida entre estes dois pontos. 18 Por isso, para as medições serem precisas, é esperado que o voltímetro tenha uma resistência muito grande comparada às do circuito. Voltímetros podem medir tensões contínuas ou tensões alternadas, dependendo das qualidades do aparelho. Figura 3, Voltímetro. Fonte: (www.grupoescolar.com) 2.3 Tacômetro O tacômetro, também conhecido como taquímetro, é um instrumento de medição do número de rotações (geralmente por minuto, RPM) de um motor. Pode ser chamado também de conta-rotações, conta-voltas ou conta-giros. 19 O tacômetro digital eletrônico utilizado para medição de rotação, pode ser utilizado como um tacômetro óptico ou como um tacômetro de contato permitindo a medição de rpm nas mais diversas aplicações. Quando operado como tacômetro de contato, permite o uso como medidor de velocidade linear (metros/segundo). No modo fototacômetro possui uma mira laser que pode ser usada com precisão até 100 cm de distância do ponto de medição de rotação. Por ser um instrumento de última geração dispõe de um indicador de cristal líquido de grande tamanho facilitando a leitura das medições. Este instrumento também dispõe de memória de máximo e mínimo. Figura 4, Tacômetro. Fonte: (www.impac.com.br) 20 2.4 Osciloscópio O osciloscópio é um instrumento de medida eletrônico que cria um gráfico bidimensional visível de uma ou mais diferenças de potencial. O eixo horizontal do ecrã (monitor) normalmente representa o tempo, tornando o instrumento útil para mostrar sinais periódicos. O eixo vertical comumente mostra a tensão. O monitor é constituído por um "ponto" que periodicamente "varre" a tela da esquerda para a direita. Ele pode ser usado para realizar medições de sonda lambda e de tempo de injeção. Figura 5, Osciloscópio. Fonte: (www.kit8051.com.br) 21 3. Linguagem Java 3.1 O que é Java? Java é uma linguagem de programação orientada a objeto desenvolvida na década de 90 por uma equipe de programadores chefiada por James Gosling, na empresa Sun Microsystems. Diferentemente das linguagens convencionais, que são compiladas para código nativo, a linguagem Java é compilada para um bytecode que é executado por uma máquina virtual. A linguagem de programação Java é a linguagem convencional da Plataforma Java, mas não sua única linguagem. 3.2 Surgimento do Java Em 1991, na Sun Microsystems, foi iniciado o Green Project, o berço do Java uma linguagem de programação orientada a objetos. Os mentores do projeto eram Patrick Naughton, Mike Sheridan, e James Gosling. O objetivo do projeto não era a criação de uma nova linguagem de programação, mas antecipar e planejar a “próxima onda” do mundo digital. Eles acreditavam que em algum tempo haveria uma convergência dos computadores com os equipamentos e eletrodomésticos comumente usados pelas pessoas no seu dia-a-dia. Para provar a viabilidade desta idéia, 13 pessoas trabalharam arduamente durante 18 meses. No verão de 1992 eles emergiram de um escritório de Sand Hill Road no Menlo Park com uma demonstração funcional da idéia inicial. O protótipo se chamava *7 (“StarSeven”), um controle remoto com uma interface gráfica touchscreen. O *7 tinha a habilidade de controlar diversos dispositivos e aplicações. James Gosling especificou uma nova linguagem de programação para o *7. Gosling decidiu batizá-la de “Oak”, que quer dizer carvalho, uma árvore que ele podia observar quando olhava pela sua janela. 22 O grupo estava iniciando um projeto chamado Projeto Green, que consistia na criação de tecnologias modernas de software para empresas eletrônicas de consumo. Logo o grupo percebeu que não poderia ficar preso à plataformas, pois os clientes não estavam interessados no tipo de processador que estavam utilizando, e fazer uma versão do projeto para cada tipo de sistema seria inviável. Desenvolveram então o sistema operacional GreenOS, com a linguagem de programação Oak. Como a equipe de desenvolvimento tomava muito café enquanto estava trabalhando, foram ingeridas centenas de xícaras de café até que o projeto estivesse pronto. Finalmente em maio de 1995 a Sun anunciou um ambiente denominado Java, homenagem às xícaras de café, que obteve sucesso graças ao rápido estabelecimento da Internet e a incorporação deste ambiente a browsers populares como o Netscape Navigator e padrões tridimensionais como o VRML (Virtual Reality Modeling Language Linguagem de Modelagem para Realidade Virtual). Além disso, sua natureza portátil e o projeto robusto permitem o desenvolvimento para múltiplas plataformas, em ambientes tão exigentes como os da eletrônica de consumo. 3.3 Java nos Aparelhos Eletrônicos A linguagem Java vem sendo utilizada cada vez mais em equipamentos eletrônicos (embedded) devido a sua portabilidade e operação multiplataforma, exemplos disso são aplicativos para celulares (Android) e computadores (Windows, Linux, MAC). O Java também vem sendo introduzido em microcontroladores e microprocessadores, tais como ARM-CORTEX M, ARM-CORTEX A, entre outros. Além de sua ampla utilização em diversas áreas o Java disponibiliza APIs como jUSB, JavaComm e RXTX (utilizada neste projeto) para comunicação serial possibilitando que aparelhos eletrônicos se comuniquem com computadores ou dispositivos móveis, permitindo integração inclusive com a Internet. 23 3.4 Por que Escolhemos a Linguagem Java? Esta linguagem foi escolhida pelo fato de ser multiplataforma, open source e orientada a objetos. Foi utilizado como ferramenta de desenvolvimento o ambiente de desenvolvimento NetBeans. Todos esses softwares são livres e sem custo de aquisição, o que torna o projeto economicamente viável. Por ser uma linguagem multiplataforma, permite que nosso software possa ser executado em computadores Desktop, Notebook, Netbook e com sistema operacional MAC OS, Windows XP, Windows Vista, Windows7, Windows8 e praticamente todas as distribuições Linux, portanto o programa será de utilização praticamente universal. Como o nosso sistema é desenvolvido em Java que é a base para o desenvolvimento do sistema operacional Android, nosso software poderá facilmente ser portado para este sistema operacional, tornando-se disponível para SmartPhones e Tablets. Também foi levado em consideração o fato de estarmos familiarizados com esta linguagem devido às aulas e devido a grande quantidade de fóruns e material disponível sobre Java na internet. 24 4. O Tachometer 4.1 Funções do Tachometer O projeto reúne diversas funções, que são elas a medição da tensão da bateria, medição das rotações do motor (RPM) através de um sensor de vibração, um voltímetro multifunção, tempo de injeção de combustível, e medição do sinal da sonda Lambda. A injeção eletrônica é um sistema de alimentação de combustível e gerenciamento eletrônico do motor de um automóvel - motor a combustão. Sua utilização em larga escala se deve à necessidade das industrias de automóveis reduzirem o índice de emissão de gases poluentes. Esse sistema permite um controle mais eficaz da mistura admitida pelo motor, mantendo-a mais próxima da mistura estequiométrica (mistura ideal ar / combustível), isso se traduz em maior economia de combustível já que o motor trabalha sempre com a mistura adequada e também melhora o desempenho do motor gerando a menor quantidade possível de poluentes. O sistema faz a leitura de diversos sensores espalhados em pontos estratégicos do motor, examina as informações e com base em outras informações gravadas em sua memória envia comandos para diversos atuadores espalhados em pontos estratégicos do motor também. Esse procedimento é efetuado varias vezes por segundo. Devido a grande quantidade de sensores e atuadores eletrônicos no motor de veículos equipados com injeção eletrônica existe a necessidade de se utilizar equipamentos específicos para a atuação e detecção de falhas em diversos componentes do sistema de injeção eletrônica. 25 4.1.1 Tensão da bateria Esta função é a mais básica de todas, pois se o veículo esta com a tensão abaixo do nível mínimo recomendado, todo o sistema pode parar de funcionar ou pode apresentar falhas intermitentes, portanto antes de se verificar qualquer outro componente é indispensável a verificação da tensão da bateria. 4.1.2 Medição das rotações do motor (RPM) A medição das rotações do motor é muito importante para auxiliar no diagnóstico de problemas relacionados a emissão de poluentes, pois os equipamentos analisadores de gases utilizados na medição de poluentes necessitam saber com precisão qual o RPM (rotações por minuto) do motor no momento da medição. Além disso alguns veículos permitem o ajuste da marcha lenta, sendo que neste caso a leitura do RPM é de extrema importância. 4.1.3 Voltímetro multifunção Esta função é muito útil para determinar se alguns sensores estão em funcionamento, pois medindo a tensão de saída destes sensores pode-se determinar se estão ou não em bom estado. A maioria dos sensores converte uma ação mecânica ou uma grandeza física em um sinal elétrico baseado em tensão, como sensores de temperatura, sensores de rotação, sensor de pressão atmosférica, sensor de vácuo, etc. A função voltímetro também é muito útil para se determinar se atuadores estão sendo alimentados corretamente, pois muitas vezes o problema não está nos sensores mas sim na tensão de alimentação que não chega até eles. 26 4.1.4 Tempo de injeção O tempo de injeção é o tempo que o injetor de combustível fica ligado (on), determinando a quantidade de combustível injetada no motor. Nesta função o equipamento mede os tempos de injetor ligado e injetor desligado (on/off). Esta função é muito importante para se determinar se um injetor está sendo acionado corretamente. Figura 6, Válvula injetora de combustível. Fonte: (www.jalopnik.com.br) 4.1.5 Sonda Lambda Os sensores lambda tem como função detectar o teor de oxigenio nos gases de descarga em comparação ao oxigênio de amostragem que fica dentro do sensor (ar ambiente) e informar a central (U.C.E) em forma de sinal elétrico para que a mesma possa fazer os cálculos estequiométricos. Fator Lambda ( λ ) Para entendermos o funcionamento dos sensores de oxigênio primeiramente temos que conhecer o fator lambda (λ). Neste caso a letra grega lambda (λ) corresponde a razão de equivalência na relação ar-combustível real entre a relação considerada ideal ou estequiométrica para uma mistura. 27 Lambda (λ)= relação real – ar/combustível / relação ideal – ar/combustível Relação Ar/Combustível ideal Gasolina: 14,7:1 ( 14,7 partes de ar para 1 parte de gasolina) Álcool: 9,0:1 ( 9,0 partes de ar para 1 parte de álcool) Diesel: 15,2:1 ( 15,2 partes de ar para 1 parte de Diesel) Dessa forma podemos concluir que quando uma mistura tem mais ar do que o especificado na tabela acima dizemos que λ >1 ou que a mistura esta Pobre. Já quando a quantidade de ar esta abaixo da especificada dizemos que λ<1 ou que a mistura esta Rica. Funcionamento do sensor de oxigênio Os sensores lambda trazem em sua composição um componente muito importante que é o dióxido de zircônio, este material quando atinge uma temperatura superior a 300°C se transforma em um condutor de íons de oxigênio. Com o auxilio deste componente a sonda consegue identificar por meio de uma variação de tensão a quantidade de oxigênio presente nos gases de escape. Esta tensão que pode ser medida em milvolts varia de 0 a 800mv e é enviada para a unidade de comando para que sejam feitos os cálculos usando como base o fator lambda. 28 Localização do Sensor Lambda Por funcionar com perfeição somete acima de 300°C, geralmente este dispositivo é fixado no cano de descarga (escapamento) o mais próximo possível do motor e obrigatoriamente esta peça deve receber os gases provenientes de todos os cilindro para que a leitura seja a melhor possível. Existem sondas de 1, 2, 3 e 4 fios, sendo que a mais eficiente e utilizada no momento é a de 4 fios. Na sonda de 4 fios, 2 fios (GND e Sinal) são utilizados para a transmissão do sinal lambada, (tensão de 0,2 a 0,8 volts) e os outros 2 fios são utilizados para alimentar um resistor de aquecimento, desta forma este tipo de sonda lambda pode trabalhar em regiões mais frias, longe da saída do motor, pois a mesma mantém sua temperatura ideal de trabalho devido ao resistor de aquecimento. A sonda de 4 fios pode até mesmo estar localizada próxima ao catalizador. Para que todas as funções anteriores possam ser mostradas na tela de um computador o equipamento Tachometer deve ser conectado a um computador através de um cabo USB. O hardware do Tachometer possui um componente que emula uma porta serial através da conexão USB, portanto para o computador o equipamento Tachometer possui uma porta de comunicação serial, exemplo COM1, COM2, etc. Esta comunicação serial necessita além do hardware, um software e regras de transmissã e recepção dos dados. Estas regras que definem como devemos enviar e receber os dados ao equipamento Tachometer é denominado Protocolo. No próximo tópico será descrito todo o protocolo de comunicação serial. 29 4.2 Descrição da Comunicação Serial Comunicação serial é o processo de enviar dados, um bit de cada vez, sequencialmente, num canal de comunicação ou barramento. É diferente da comunicação paralela, em que todos os bits de cada símbolo são enviados juntos. A comunicação serial é usada em toda comunicação de longo alcance e na maioria das redes de computadores, onde o custo de cabos e as dificuldades de sincronização tornam a comunicação paralela impraticável. Para curtas distâncias, barramentos seriais estão se tornando cada vez mais comuns devido ao ponto em que as desvantagens dos barramentos paralelos (densidade de interconexão) superam suas vantagens de simplicidade. 4.2.1 O que é comunicação de dados? A distância que um dado sinal percorre em um computador varia de alguns milímetros, como no caso de conexões de um simples CI, até vários centímetros quando a conexão de sinais envolve, por exemplo, uma placa mãe com conectores para diversos circuitos. Para estas distâncias, o dado digital pode ser transmitido diretamente. Exceto em computadores muito rápidos, os projetistas não se preocupam com o formato e espessura dos condutores, ou com as características analógicas dos sinais de transmissão. Frequentemente, no entanto, os dados devem ser enviados para fora dos circuitos que constituem o computador. Nesses casos, as distâncias envolvidas podem ser enormes. Com o aumento das distâncias entre a fonte e o destino aumenta também a dificuldade de estabelecer uma transmissão de dados precisa. Isso é resultado de distorções elétricas dos sinais que trafegam através de condutores longos, e de ruídos adicionados ao sinal que se propagam através do meio de transmissão. 30 Embora alguns cuidados devam ser tomados na troca de dados dentro de um computador, o grande problema ocorre quando dados são transferidos para dispositivos fora dos circuitos do computador. Nesse caso a distorção e o ruído podem tornar-se tão severos que a informação é perdida. A Comunicação de Dados estuda os meios de transmissão de mensagens digitais para dispositivos externos ao circuito originador da mensagem. Dispositivos Externos são geralmente circuitos com fonte de alimentação independente dos circuitos relativos a um computador ou outra fonte de mensagens digitais. Como regra, a taxa de transmissão máxima permissível de uma mensagem é diretamente proporcional a potência do sinal, e inversamente proporcional ao ruído. A função de qualquer sistema de comunicação é fornecer a maior taxa de transmissão possível, com a menor potência e menor ruído possíveis. 4.2.2 Canais de comunicação Um canal de comunicação é um caminho sobre o qual a informação pode trafegar. Ela pode ser definida por uma linha física (fio) que conecta dispositivos de comunicação, por rádio ou outra fonte de energia radiante. Em comunicação digital, a informação é representada por bits de dados individuais, que podem ser encapsulados em mensagens de vários bits. Um byte (conjunto de 8 bits) é um exemplo de uma unidade de mensagem que pode trafegar através de um canal digital de comunicações. Uma coleção de bytes pode ser agrupada em um “frame” ou outra unidade de mensagem de maior nível. Esses múltiplos níveis de encapsulamento facilitam o reconhecimento de mensagens e interconexões de dados complexos. Um canal no qual a direção de transmissão é inalterada é referida como canal simplex, nunca é permitido a transmissão inversa. Um canal half-duplex é um canal físico simples no qual a direção pode ser revertida. As mensagens podem fluir nas duas direções, mas nunca ao mesmo tempo. 31 Um canal full-duplex permite que mensagens sejam trocadas simultaneamente em ambas as direções. Ele pode ser visto como dois canais simplex, um canal direto e um canal reverso, conectados nos mesmos pontos. 4.2.3 Comunicação serial Por não ser prático nem econômico transferir todos os bits de uma mensagem simultaneamente, a mensagem é quebrada em partes menores e transmitida seqüencialmente. A transmissão bit-serial converte a mensagem em um bit por vez através de um canal. Cada bit representa uma parte da mensagem. Os bits individuais são então rearranjados no destino para compor a mensagem original. Em geral, um canal irá passar apenas um bit por vez. A transmissão bit-serial é normalmente chamada de transmissão serial, e é o método de comunicação escolhido por diversos periféricos de computadores. A transmissão byte-serial converte 8 bits por vez através de 8 canais paralelos. Embora a taxa de transferência seja 8 vezes mais rápida que na transmissão bit-serial, são necessários 8 canais, e o custo poderá ser 8 vezes maior para transmitir a mensagem. Quando as distâncias são curtas, é econômico usar canais paralelos como justificativa para as altas taxas de transmissão. 4.2.4 Taxa de transferência (Baud Rate) A taxa de transferência refere-se a velocidade com que os dados são enviados através de um canal e é medido em transições elétricas por segundo. Na norma EIA232, ocorre uma transição de sinal por bit, e a taxa de transferência e a taxa de bit (bit rate) são idênticas. Nesse caso, uma taxa de 9600 bauds corresponde a uma transferência de 9600 dados por segundo, ou um período de aproximadamente, 104 µs (1/9600 s). 32 Outro conceito é a eficiência do canal de comunicação que é definido como o número de bits de informação utilizável (dados) enviados através do canal por segundo. Ele não inclui bits de sincronismo, formatação, e detecção de erro que podem ser adicionados a informação antes da mensagem ser transmitida, e sempre será no máximo igual a um. 4.2.5 Transmissão assíncrona x Transmissão síncrona Geralmente, dados serializados não são enviados de maneira uniforme através de um canal. Ao invés disso, pacotes com informação regulares são enviados seguidos de uma pausa. Os pacotes de dados binários são enviados dessa maneira, possivelmente com comprimentos de pausa variável entre pacotes, até que a mensagem tenha sido totalmente transmitida. O circuito receptor dos dados deve saber o momento apropriado para ler os bits individuais desse canal, saber exatamente quando um pacote começa e quanto tempo decorre entre bits. Quando essa temporização for conhecida, o receptor é dito estar sincronizado com o transmissor, e a transferência de dados precisa torna-se possível. Falhas na manutenção do sincronismo durante a transmissão irão causar a corrupção ou perda de dados. Duas técnicas básicas são empregadas para garantir a sincronização correta. Em sistemas síncronos, canais separados são usados para transmitir dados e informação de tempo. O canal de temporização transmite pulsos de clock para o receptor. Através da recepção de um pulso de clock, o receptor lê o canal de dado e armazena o valor do bit encontrado naquele momento. O canal de dados não é lido novamente até que o próximo pulso de clock chegue. Como o transmissor é responsável pelos pulsos de dados e de temporização, o receptor irá ler o canal de dados apenas quando comandado pelo transmissor, e portanto a sincronização é garantida. 33 8 bits de dados 1 bit de informação Pacote de dados 8 bits de informação Eficiência do canal = 8/1 = 0,73 Existem técnicas que compõem o sinal de clock e de dados em um único canal. Isso é usual quando transmissões síncronas são enviadas através de um modem. Dois métodos no qual os sinais de dados contém informação de tempo são: codificação NRZ (Non-Return-to-Zero) e a codificação Manchester. Em sistemas assíncronos, a informação trafega por um canal único. O transmissor e o receptor devem ser configurados antecipadamente para que a comunicação se estabeleça a contento. Um oscilador preciso no receptor irá gerar um sinal de clock interno que é igual (ou muito próximo) ao do transmissor. Para o protocolo serial mais comum, os dados são enviados em pequenos pacotes de 10 ou 1 bits, dos quais 8 constituem a mensagem. Quando o canal está em repouso, o sinal correspondente no canal tem um nível lógico ‘1’. Um pacote de dados sempre começa com um nível lógico ‘0’ (start bit) para sinalizar ao receptor que um transmissão foi iniciada. O “start bit” inicializa um temporizador interno no receptor avisando que a transmissão começou e que serão necessários pulsos de clocks. Seguido do start bit, 8 bits de dados de mensagem são enviados na taxa de transmissão especificada. O pacote é concluído com os bits de paridade e de parada (“stop bit”). Bit de Paridade checa a precisão da transmissão Start Bit início de transmissão exatamente 8 bits de dados aceitos Stop Bit fim de transmissão e tempo para receptor reiniciar 34 1 Start Bit 8 Bits de Dados 1 Bit de Paridade 1 Stop Bit Tempo Dados Clock O comprimento do pacote de dados é pequeno em sistemas assíncronos para minimizar o risco do oscilador do transmissor e do receptor variar. Quando osciladores a cristal são utilizados, a sincronização pode ser garantida sobre os 1 bits de período. A cada novo pacote enviado, o “start bit” reseta a sincronização, portanto a pausa entre pacotes pode ser longa. Os caracteres enviados através de uma interface serial geralmente seguem o padrão ASCII (American Standard Code for Information Interchange) de 7 bits. 35 4.3 Descrição do Protocolo Serial do Tachometer (Versão 1.0) Protocolo de Comunicação. Antes de detalhar o protocolo de comunicação, vamos definir a nomenclatura utilizada neste documento para que a descrição fique clara e seja bem entendida. Nome Descrição HOST Equipamento onde será instalado o software e que inicia a comunicação, podendo ser desktop, notebook, netbook, tablet ou smartfone. DEVICE Equipamento que recebe os comandos do HOST, executa os comando e responde ao HOST. Neste caso específico é o nosso equipamento de medidas. FRAME Conjunto de bytes que o HOST envia ao DEVICE para que este execute comando ou retorne valores. Para cada FRAME que o HOST envia ao DEVICE, este também retorna um FRAME informando se o comando foi aceito (ACK) ou não aceito (NAK). DID Device IDentification number, byte de identificação de produto, enviado em todos os FRAMES do HOST para o DEVICE. Este é o primeiro byte do FRAME. Em nosso caso o valor do DID em hexadecimal é 02. LB Length Byte, ou número de bytes do FRAME após o DID, exceto o CS. O LB sempre é o segundo byte do FRAME que o HOST envia para o DEVICE e o terceiro byte do FRAME que o DEVICE responde ao HOST. CMD Comando que o HOST envia para o DEVICE. Este é sempre o terceiro byte do FRAME que o HOST envia para o DEVICE e o segundo quando o DEVICE responde ao HOST. DF Data Fields, ou campos de dados. Este são bytes do FRAME que informam valores que alguns comandos CMD necessitam para serem executados. Dependendo do comando CMD podem ser necessários mais de um DF. Para alguns comandos o DEVICE também responde com DF's. Os DF's ocupam as posições de número 4 até a penúltima posição dos FRAMES que o HOST envia ao DEVICE e que o DEVICE responde ao HOST. CS CheckSum, ou checagem da soma é um byte que serve para verificar a integridade do FRAME recebido, tanto pelo DEVICE como pelo HOST. Este byte tem seu valor calculado de acordo com a fórmula abaixo: CS = NOT (DID + LB + CMD + [DF] + … ) + 1 ACK ACKnowledge, ou reconhecimento. Este é o primeiro byte do FRAME que o DEVICE responde ao HOST, quando o DEVICE reconhece ou aceita o comando CMD. O valor ACK em hexadecimal é 06. NAK Not AcKnowledge, ou não reconhecido. Este é o primeiro byte do FRAME que o DEVICE responde ao HOST quando o DEVICE não reconhece ou não aceita o comando CMD. O valor ACK em hexadecimal é 15. EC Error Code, ou código de erro. Este é um byte que o DEVICE envia no FRAME de resposta ao HOST para indicar o tipo de error que houve. 36 Detalhamento do protocolo. O HOST transmite comandos para o DEVICE (equipamento do Projeto K) como uma série de bytes que compõe os FRAMES. Os FRAMES serão detalhados na descrição de cada comando. Após o HOST enviar um FRAME de comando, este aguarda uma resposta do DEVICE, a qual pode ser um FRAME de reconhecimento (ACK), um FRAME de não reconhecimento (NAK) ou uma não resposta, ou seja não responder ao HOST. As respostas do DEVICE (ACK/NAK) são transmitidas dentro de 2 segundos após receber um comando do HOST, a menos que esteja especificado o contrário na descrição do comando. Para a transmissão de dados contínua, o tempo de resposta ACK/NAK aplicase a primeira resposta ACK. O HOST pode transmitir comandos para o DEVICE durante um fluxo contínuo de respostas de dados ACK. A menos que seja especificado, todos os campos de dados são assinados com 2 números complementares. O DEVICE irá sempre responder ás transmissões do HOST da seguinte maneira: Resposta Descrição ACK O comando foi recebido e será realizado. A mensagem está formatada corretamente, o comando é reconhecido, o comando é permitido, o CS (checksum) está correto, e uma condição de erro do sistema não impede a execução do comando. O código ASCII para ACK é $06 (hexadecimal). NAK O comando não pode ser executado. Onde apropriado, a resposta NAK inclui um código de erro especificando porque o comando não pode ser executado. O código ASCII para NAK é $15. SEM RESPOSTA O DEVICE não irá transmitir o FRAME de resposta ao HOST se algum dos seguintes pontos forem verdadeiros: 1 - Nenhum comando foi recebido e os dados contínuos não estão ativados. 2 - Sinais na linha de entrada serial de dados não estão de acordo com o formato RS232. 3 - O comando é recebido enquanto a resposta de um comando anterior está pendente. 4 - O dispositivo de identificação do byte (DID) não é igual a $02. 5 - O byte checksum (CS) estava incorreto. 6 – O DEVICE está rodando um autoteste ou inicializando (0.15 a 1.50 segundos após ligado. 37 Sumário dos comandos: CMD (HEX) Descrição NAK EC Error Code 01 Leitura do número serial. 01, 03 02 Escreve número serial na EEPROM 01, 03 03 Lê variáveis de ajuste. (EEPROM) 01, 03 04 Lê 1 variável da EEPROM no enderêço especificado. 01, 02, 03 05 Escreve 1 variável na EEPROM no endereço especificado. 01, 02, 03 07 Status do equipamento. 08 Seleciona uma função no menu do equipamento. 01, 02, 03 09 Aciona/desaciona a função selecionada. 01, 03, 04 0A Seleciona o número de cilindros na função rotação 01, 02, 03 0B Realiza leitura da função selecionada 01, 03, 05 01, 03 Descrição dos códigos de erro (EC) associados ao NAK EC (HEX) Descrição 01 Formato do comando recebido inválido. 02 Comando recebido com DF fora do range. 03 Comando não reconhecido ou inválido. 04 Comando ON/OFF fora do range. 05 Comando não pode ser executado no momento. 38 Comando: 01 - Leitura do número serial Formato de envio HOST → DEVICE: DID LB CMD CS 02 01 01 FC Formato de retorno ACK - DEVICE → HOST: ACK CMD 06 01 LB DF0 DF1 DF2 DF3 DF4 DF5 04 XX XX XX XX VH DF0 - Serial 1º byte Modelo. DF1 - Serial 2º byte Serie MSB. DF2 - Serial 3º byte Serie LSB. DF3 - Serial 4º byte Mês de produção. DF4 - Versão de hardware df5 - Versão de software Formato de retorno NAK - DEVICE → HOST: Códigos de erro: NAK CMD LB EC CS 15 01 01 XX CALC 01 - Formato do comando inválido. 03 - Comando não reconhecido ou inválido. VF CS CALC 39 Comando: 02 - Gravação do número serial Formato de envio HOST → DEVICE: DID LB CMD DF0 DF1 DF2 DF3 CS 02 05 02 XX XX XX XX CALC DF0 - Serial 1º byte Modelo. DF1 - Serial 2º byte Serie MSB. DF2 - Serial 3º byte Serie LSB. DF3 - Serial 4º byte Semana de produção. Formato de retorno ACK - DEVICE → HOST: ACK CMD LB DF0 DF1 DF2 DF3 CS 06 02 04 XX XX XX XX CALC DF0 - Serial 1º byte Modelo. DF1 - Serial 2º byte Serie MSB. DF2 - Serial 3º byte Serie LSB. DF3 - Serial 4º byte Semana de produção. Formato de retorno NAK - DEVICE → HOST: NAK CMD LB EC CS 15 02 01 XX CALC Códigos de erro EC: 01 - Formato do comando inválido. 03 - Comando não reconhecido ou inválido. 40 Comando: 03 - Leitura de variáveis de configuração da EEPROM. Formato de envio HOST → DEVICE: DID LB CMD CS 02 01 03 FA Formato de retorno ACK - DEVICE → HOST: ACK CMD LB DF0 DF1 DF2 DF3 DF4 CS 06 03 05 XX XX XX XX XX CALC DF0 - Offset ADC canal 0 – Tensão da bateria. DF1 - Offset ADC canal 1 – Voltímetro. DF2 – Multiplicador ADC canal 0 – Tensão da bateria. DF3 – Multiplicador ADC canal 0 – Voltímetro. DF4 – Valor do Oscilador. Formato de retorno NAK - DEVICE → HOST: Códigos de erro: NAK CMD LB EC CS 15 03 01 XX CALC 01 - Formato do comando inválido. 03 - Comando não reconhecido ou inválido. 41 Comando: 04 – Lê valor de variável na EEPROM. Formato de envio HOST → DEVICE: DID LB CMD DF0 DF1 CS 02 03 04 XX XX CALC DF0 - Endereço da EEPROM - MSB. DF1 - Endereço da EEPROM - LSB. Formato de retorno ACK - DEVICE → HOST: ACK CMD LB DF0 DF1 DF2 CS 06 04 03 XX XX XX CALC DF0 - Endereço da EEPROM - MSB. DF1 - Endereço da EEPROM - LSB. DF2 - Valor da EEPROM Formato de retorno NAK - DEVICE → HOST: Códigos de erro: NAK CMD LB EC CS 15 04 01 XX CALC 01 - Formato do comando inválido. 02 – Comando recebido com DF fora do range. 03 - Comando não reconhecido ou inválido. 42 Comando: 05 – Escreve valor de variável na EEPROM. Formato de envio HOST → DEVICE: DID LB CMD DF0 DF1 DF2 CS 02 04 05 XX XX XX FC DF0 - Endereço da EEPROM - MSB. DF1 - Endereço da EEPROM - LSB. DF2 – Valor a gravar na EEPROM no endereço especificado por DF1/DF2. Formato de retorno ACK - DEVICE → HOST: ACK CMD LB DF0 DF1 DF2 CS 06 05 03 XX XX XX CALC DF0 - Endereço da EEPROM - MSB. DF1 - Endereço da EEPROM - LSB. DF2 - Valor da EEPROM Formato de retorno NAK - DEVICE → HOST: Códigos de erro: NAK CMD LB EC CS 15 05 01 XX CALC 01 - Formato do comando inválido. 02 – Comando recebido com DF fora do range. 03 - Comando não reconhecido ou inválido. 43 Comando: 07 – Status do equipamento. Formato de envio HOST → DEVICE: DID LB CMD CS 02 01 07 F7 Formato de retorno ACK - DEVICE → HOST: ACK CMD 06 07 LB DF0 DF1 DF2 CS 02 XX XX XX CALC DF0 - Função selecionada. Possíveis valores 00 – Tensão da bateria. 01 – Rotação. 02 – Voltímetro. 03 – Tempo de Injeção. 04 – Lambada. DF1 – Função ativada(1) ou desativada(0). DF2 - Escala ou número de cilindros(depende da função), habilitado somente para a função 01 - Rotação Formato de retorno NAK - DEVICE → HOST: Códigos de erro: NAK CMD LB EC CS 15 07 01 XX CALC 01 - Formato do comando inválido. 03 - Comando não reconhecido ou inválido. 44 Comando: 08 – Seleciona uma função no menu do equipamento. Formato de envio HOST → DEVICE: DID LB CMD DF0 CS 02 02 08 XX CALC DF0 – Função a selecionar. 00 – Tensão da bateria. 01 – Rotação. 02 – Voltímetro. 03 – Tempo de Injeção. 04 – Lambada. Formato de retorno ACK - DEVICE → HOST: ACK CMD LB DF0 CS 06 08 01 XX CALC DF0 – Função selecionada. 00 – Tensão da bateria. 01 – Rotação. 02 – Voltímetro. 03 – Tempo de Injeção. 04 – Lambada. Formato de retorno NAK - DEVICE → HOST: Códigos de erro: NAK CMD LB EC CS 15 08 01 XX CALC 01 - Formato do comando inválido. 02 - Comando recebido com DF fora do range. 03 - Comando não reconhecido ou inválido. 45 Comando: 09 – Ativa ou desativa a função selecionada. Formato de envio HOST → DEVICE: DID LB CMD DF0 CS 02 02 09 XX CALC DF0 – Ativa ou desativa a função selecionada. 0 – Desativa a função. 1 – Ativa a função. Formato de retorno ACK - DEVICE → HOST: ACK CMD LB DF0 CS 06 09 01 XX CALC DF0 – Retorna status da função. 0 – Função desativada. 1 – Função ativada. Formato de retorno NAK - DEVICE → HOST: Códigos de erro: NAK CMD LB EC CS 15 09 01 XX CALC 01 - Formato do comando inválido. 02 - Comando recebido com DF fora do range. 03 - Comando não reconhecido ou inválido. 46 Comando: 0A – Seleciona o número de cilindros da função rotação. Formato de envio HOST → DEVICE: DID LB CMD DF0 CS 02 02 0A XX CALC DF0 – Seleciona o número de cilindros da função rotação. 0 – 1 cilindro. 1 – 2 cilindros. 2 – 3 cilindros. 3 – 4 cilindros. 4 – 5 cilindros. 5 – 6 cilindros. 6 – 8 cilindros. 7 – 10 cilindros. 8 – 12 cilindros. Formato de retorno ACK - DEVICE → HOST: ACK CMD LB DF0 CS 06 0A 01 XX CALC DF0 – Retorna número de cilindros da função rotação. 0 – 1 cilindro. 1 – 2 cilindros. 2 – 3 cilindros. 3 – 4 cilindros. 4 – 5 cilindros. 5 – 6 cilindros. 6 – 8 cilindros. 7 – 10 cilindros. 8 – 12 cilindros. Formato de retorno NAK - DEVICE → HOST: Códigos de erro: NAK CMD LB EC CS 15 0A 01 XX CALC 01 - Formato do comando inválido. 02 - Comando recebido com DF fora do range. 03 - Comando não reconhecido ou inválido. 47 Comando: 0B - Leitura da função selecionada. Formato de envio HOST → DEVICE: DID LB CMD CS 02 01 0B F2 Formato de retorno ACK - DEVICE → HOST: ACK CMD LB DF0 DF1 DF2 DF3 CS 06 0B 04 XX XX XX XX CALC Os Data Fields dependem da função selecionada. Função Tensão da Bateria: DF0 - Retorna 00. DF1 - Retorna 00. DF2 - Retorna MSB da tensão. DF3 - Retorna LSB da tensão. O inteiro composto por MSB/LSB informa a tensão em milivolts. Exemplo de retorno: 06 0B 04 00 00 36 63 52 O número hexadecimal formado pelos bytes 36 e 63 (3663 hex) e convertido para decimal inteiro significa o número 13923. Este valor representar o valor da tensão em milivolts, o qual representa 13923 milivolts, que é equivalente a 13,923 volts. Função Rotação: DF0 - Retorna MSB do RPM. DF1 - Retorna LSB do RPM. DF2 - Retorna 00. DF3 – Retorna o número de cilindros selecionado. O inteiro composto por MSB/LSB informa a tensão em milivolts. Exemplo de retorno: 06 0B 04 03 E0 00 00 08 O inteiro 03 E1 em decimal representa 992 rotações por minuto, e 00 significa que o número de cilindros selecionado é igual a 1 Função Voltímetro: DF1 - Retorna 00. DF2 - Retorna 00. DF3 - Retorna MSB da tensão. DF4 - Retorna LSB da tensão. 48 A inteiro composto por MSB/LSB informa a tensão em milivolts. Exemplo de retorno: 06 0B 04 00 00 15 EA 52 O inteiro 15 EA em decimal representa 5610 milivolts, que é equivalente a 5,610 volts. Função Tempo de Injeção: DF1 - Retorna MSB do Tempo do injetor ON. DF2 - Retorna LSB do Tempo do injetor ON. DF3 - Retorna MSB do Tempo do injetor OFF. DF4 – Retorna LSB do Tempo do injetor OFF. A inteiro composto por MSB/LSB informa o tempo de injeção em a tensão em milivolts. Exemplo de retorno: 06 0B 04 01 F9 2D 36 8E O inteiro 01 F9 em decimal representa 505 centésimos de milisegundos, que significa 5,05 milisegundos de injetor ON(Ligado). O inteiro 2D 36 em decimal representa 11574 centésimos de milisegundos, que significa 115,74 milisegundos de injetor OFF(Desligado). Função Lambda: DF1 - Retorna 00. DF2 - Retorna 00. DF3 - Retorna MSB da tensão. DF4 - Retorna LSB da tensão. A inteiro composto por MSB/LSB informa a tensão em milivolts. Exemplo de retorno: 06 0B 04 00 00 00 66 85 O inteiro 00 66 em decimal representa 102 milivolts, que é equivalente a 0,102 volts. Formato de retorno NAK - DEVICE → HOST: Códigos de erro: NAK CMD LB EC CS 15 0B 01 XX CALC 01 - Formato do comando inválido. 03 - Comando não reconhecido ou inválido. 05 – Comando não pode ser executado no momento. 49 Comando: 0C – Status da comunicação. Formato de envio HOST → DEVICE: DID LB CMD CS 02 01 0C F7 Formato de retorno ACK - DEVICE → HOST: ACK CMD 06 07 LB DF0 DF1 CS 02 XX XX CALC DF0 - Quantidades de erros de checksum. DF1 - Quantidades de erros de DID. Formato de retorno NAK - DEVICE → HOST: Códigos de erro: NAK CMD LB EC CS 15 0C 01 XX CALC 01 - Formato do comando inválido. 03 - Comando não reconhecido ou inválido. 50 4.4 Como Utilizar o Software do Tachometer Ao rodar o programa será aberta a janela do Tachometer na aba Info. Nesta aba o usuário deve inserir o número de série do equipamento, selecionar a porta de comunicação e acionar o botão Conectar. O borão Conectar só estará habilitado se houver uma porta de comunicação serial disponível. Caso seja adicionada uma porta de comunicação serial será necessário acionar o botão Atualiza, para mostrar todos as portas seriais disponíveis. Assim que o software se conectar ao equipamento, este irá informar a versão de hardware, firmware e software. Figura 7, Tachometer – Tela Inicial. Fonte: (Print Screen) 51 Figura 8, Tachometer – Botão Atualiza. Fonte: (Print Screen) 52 Figura 9, Tachometer – Botão Conectar. Fonte: (Print Screen) 53 Agora que o equipamento Tachometer está devidamente conectado, para que as medições possam ser realizadas deve-se acessar a aba Medições, como padrão a função Tensão da Bateria estará selecionada (em vermelho): Figura 10, Tachometer – Aba Medições (tensão da bateria). Fonte: (Print Screen) 54 Para selecionar outra função, basta clicar em um dos botões azuis, e no caso da função RPM, é possível selecionar o número de cilindros do carro, e na função Tempo de Injeção se é negativo ou positivo. Lembrando que além do botão selecionado estar em vermelho, sempre abaixo do botão Start estará indicada qual função está selecionada. Após a função desejada estar selecionada, para iniciar a medição deve-se clicar no botão Start: Figura 11, Tachometer – Realizando a Medição. Fonte: (Print Screen) 55 Enquanto a medição estiver sendo realizada, os botões ficam desabilitados (cinza), o botão da função selecionada fica rosa claro e o botão Start torna-se Stop. Abaixo do display há uma barra de progressão que varia de acordo com os valores da medição que estão sendo apesentados no display. Para parar a medição deve-se clicar no botão Stop. Na aba Config serão adicionados parâmetros de configuração do equipamento. Estes parâmetros serão opcionais, portanto não estão disponíveis nesta versão. 56 Conclusão O Tachometer é um produto de grande utilidade ao reparador de automóveis por reunir diversas funções antes realizadas por aparelhos distintos num único equipamento prático, de fácil uso e com conexão a computadores, o que permitiu um enorme ganho de recursos visuais e de banco de dados. O desenvolvimento deste projeto nos proporcionou além de um aprofundamento em Java e comunicação serial na área de informática, também conhecimentos introdutórios na área de eletrônica. Esse projeto também nos possibilitou sair do “teórico” e fazer um programa (software) útil, e complexo para um equipamento (hardware) que futuramente ajudará a sociedade de algum modo, o que é muito gratificante para o grupo. 57 Referências Bibliográficas Tecnologia em alta nas oficinas. Disponível em: <http://www.omecanico.com.br/>. Acesso em: 13 de maio de 2013. BIRD, John; Queiroz, Luiz Claudio de; Barroso, Jorge Luiz. CIRCUITOS ELÉTRICOS: TEORIA E TECNOLOGIA. Sonda lambda controlando a mistura ar combustível. Consultório técnico da Best Cars Web Site. Acesso em: 13 de maio de 2013. A história do surgimento da linguagem Java. Disponível em: <http://trabjava.blogspot.com.br/2010/09/historia-do-surgimento-da-linguagem.html >. Acesso em: 29 de julho de 2013. A história da linguagem Java. Encontrado em: <http://www.marcelomoraes.com.br>. Acesso em: 29 de julho de 2013. RAVAGNANI, Válter. Relação do tempo de injeção de combustível (Ti) com o sinal do sensor de oxigênio (sonda lambda). Disponível em: <http://arquivo.oficinabrasil.com.br/noticias/?COD=865 >. Acesso em: 19 de agosto de 2013. Drcarro.ie. Sonda Lambda. Disponível em: <http://blocktotal.blogspot.com.br/2011/04/sonda-lambda_02.html >. Acesso em: 19 de agosto de 2013. Controle de Dispositivos Eletrônicos (Acionamento de dispositivos eletrônicos por meio de uma interface gráfica em Java e um microcontrolador via comunicação serial). Disponível em: <http://www3.iesam-pa.edu.br/ojs/index.php/computacao/article/viewFile/92/87 >. Acesso em: 9 de setembro de 2013. 58 CANZIAN, Edmur. Comunicação Serial - RS232. Disponível em: <http://www.ebah.com.br/content/ABAAABb40AF/comunicacao-serial-rs232 >. Acesso em: 9 de setembro de 2013. CANZIAN, Edmur. Comunicação Serial - RS232. Disponível em: <http://www.cnz.com.br>. Acesso em: 9 de setembro de 2013. ALVES, Mário Ferreira. ABC do Osciloscópio. Disponível em: <http://www.ceset.unicamp.br/~leobravo/TT%20305/O%20Osciloscopio.pdf >. Acesso em: 9 de setembro de 2013. Tacômetro Digital, medição de rotação, rpm DT-2268. Disponível em: <http://www.impac.com.br/Tacometro_medicao_rotacao_rpm_DT2268.htm >. Acesso em: 9 de setembro de 2013. 59 Anexo A – Cronograma Cronograma Inicial de Desenvolvimento de Software do “Tachometer” Dt. Inicial Dt. Final 16/03/13 23/03/13 16/03/13 Tipo Resp. STATUS Definição inicial das funções do equipamento. HW S Concluído 23/03/13 Pesquisa sobre modelos de TCC e comunicação serial com Java (livros e internet). DC G Concluído 16/03/13 23/03/13 Definição inicial das telas do software. DC S Concluído 23/03/13 30/03/13 Definição Inicial do protocolo de comunicação serial (detalhamento). DC S Concluído 23/03/13 30/03/13 Esboço das telas do software. DC G Concluído 30/03/13 06/04/13 Documentação do protocolo de comunicação serial (descrição). DC G Concluído 30/03/13 06/04/13 Montagem de protótipos para teste do protocolo de comunicação. HW/FW S Concluído 06/04/13 20/04/13 Implementação do protocolo de comunicação em Java. SW G Concluído 20/04/13 27/04/13 Codificação inicial do corpo do programa com telas de medições e funções de teste. SW G Concluído 20/04/13 04/05/13 Testes iniciais do programa, realizando medições e testes (protótipos de comunicação). SW G Concluído 20/04/13 04/05/13 Definição do esquemático do hardware, com todas as funções. HW S Concluído 04/05/13 18/05/13 Desenho do layout das placas de circuito impresso. HW S Concluído 18/05/13 08/06/13 Produção dos primeiros protótipos de PCI. HW/FW S Concluído 08/06/13 15/06/13 Montagem dos primeiros protótipos do equipamento e provas de firmware. HW/FW S Concluído 15/06/13 27/07/13 Testes do software com hardware. SW/HW /FW G/S Concluído 27/07/13 17/07/13 Finalização da documentação do TCC, Confecção do manual do equipamento. DC G Concluído 27/07/13 17/08/13 Caso necessário alteração do hardware/firmware. HW/FW S Concluído 17/08/13 31/08/13 Caso necessário produção de novos protótipos de PCI. HW/FW S Concluído 31/08/13 14/09/13 Caso necessário montagem do hardware e modificação de software. SW/HW /FW S/G Concluído 14/09/13 28/09/13 Testes finais, montagem final, teste de campo SW/HW /FW S/G Concluído 28/09/13 16/11/13 Preparação da apresentação, finalização do TCC, ultimos acertos. DC G Concluído Legenda: Descrição Responsável G = Grupo S = Sacch (Patrocinadora) Tipo SW = Software HW = Hardware FW = Firmware DC = Documentação 60 Anexo B – DFD – Diagrama de Contexto 61 Anexo C – DFD Nível 0 62 Anexo D – DFD Nível 1 – Processo 1 63 Anexo E – DFD Nível 1 – Processo 2 64 Anexo F – DFD Nível 1 – Processo 3 65 Anexo G – Ata de Reunião nº1 ATA DE REUNIÕES TCC 2013 PROJETO K 08/03/2013 Nº 1 Reuniram-se na empresa Eletrotécnica SACCH Ltda., patrocinadora do projeto do TCC 2013, os alunos Gabriela F. D'Angelo, Luiz Tiago, Lucas Bulgarelli, William Onoue para discutir a viabilidade do projeto. Nesta data foi decidido o desenvolvimento de um Software para controle de equipamento destinado a manutenção automotiva. Segue abaixo as características do projeto: • Software desenvolvido em Java. Escolhemos esta linguagem por ser multiplataforma e open source. Utilizaremos como ferramenta de desenvolvimento o ambiente de desenvolvimento NetBeans e como banco de dados o software SQLite. Todos esses softwares são livres e sem custo de aquisição, o que torna o nosso projeto economicamente viável. • Software Multiplataforma. Isto permite que nosso software possa ser executado em computadores Desktop, Notebook, Netbook e com sistema operacional MAC OS, Windows XP, Windows Vista, Windows7, Windows8 e praticamente todas as distribuições Linux, portanto nosso programa será de utilização praticamente universal. • Como nosso sistema é desenvolvido em Java que é a base para o desenvolvimento do sistema operacional Android, nosso software poderá facilmente ser portado para este sistema operacional, tornando nosso software disponível para SmartPhones e Tablets. • Para a documentação de toda a monografia de nosso TCC será utilizado o software livre OpenOffice, o qual oferece excelentes recursos de editoração sem custos de aquisição. Como ainda não temos o nome definitivo de nosso TCC chamaremos este projeto de PROJETO K. Os demais integrantes do grupo, Ana Flávia Oliveira, Camila Lima e Juliana Queiroz ficaram incumbidos de pesquisar modelos de monografias de softwares para termos como ponto de partida para confecção de nossa monografia. Visto do professor: ___________________________ Data: __________________ 66 Anexo H – Ata de Reunião nº2 ATA DE REUNIÕES TCC 2013 PROJETO K 29/03/2013 Nº 2 Reuniram-se na empresa Eletrotécnica SACCH Ltda., patrocinadora do projeto do TCC 2013, os alunos Gabriela F. D'Angelo, Luiz Tiago, Lucas Bulgarelli, Willian Onoue para definir detalhes do protocolo de comunicação serial. Nesta data tivemos o primeiro contato com o hardware do equipamento e fizemos pequenas simulações de comunicação entre computador e o equipamento através de cabo USB emulando uma porta serial convencional. Também foi decidida a pesquisa de material sobre comunicação serial para a documentação em nossa monografia. Os demais integrantes do grupo, Ana Flávia Oliveira, Camila Lima e Juliana Queiroz continuaram incumbidos de pesquisar modelos de monografias de softwares para termos como ponto de partida para confecção de nossa monografia. Visto do professor: ___________________________ Data: __________________ 67 Anexo I – Ata de Reunião nº3 ATA DE REUNIÃO TCC 2013 PROJETO K 04/05/2013 Nº 3 Reuníram se na empresa Eletrotécnica Sacch Ltda., patrocinadora do projeto de TCC 2013, a aluna Gabriela Fontanelli D'Angelo e os sócios da empresa para discutir os tópicos abaixo: ● Alteração dos integrantes do grupo de TCC, PROJETO K. Comunicamos aos dirigentes da empresa patrocinadora que devido a problemas de comunicação e interesse em outras áreas as alunas Ana Flávia Oliveira, Camila Lima e Juliana Barbosa de Queiroz decidiram deixar o grupo, portanto a partir desta data o nosso grupo é composto apenas por Gabriela Fontanelli D'Angelo, Lucas Bulgarelli, Luiz Henrique Montanher Tiago e Willian Onoue. ● Alteração do professor orientador de TCC, PROJETO K. Comunicamos a empresa que a partir desta data a professora orientadora de TCC passa a ser a professora Márcia Cristina e não mais o professor Maicon Silva. ● Possibilidade de pesquisa de campo em empresas concorrentes sobre os equipamentos similares oferecidos. Com relação a solicitação da professora Márcia Cristina sobre pesquisa de campo, nesta data em comum acordo com os dirigentes da empresa chegamos a conclusão que uma pesquisa de campo com consulta direta às empresas seria inviável, pois estaríamos alertando a concorrência sobre o lançamento de um produto inédito no mercado. Outro ponto a destacar seria que dificilmente empresas concorrentes concordariam em participar de uma pesquisa onde a patrocinadora de um TCC de alunos da ETEC seria uma empresa concorrente. Como sugestão para uma pesquisa de campo os dirigentes da empresa indicaram diversas publicações (jornais e revistas) específicas da área de reparação automotiva para consulta além de disponibilizar catálogos de empresas concorrentes com produtos similares. Desta forma esperamos realizar esta pesquisa de mercado sem a necessidade de alertar a concorrência para o lançamento do produto da empresa patrocinadora. Não houve necessidade da presença dos demais integrantes do grupo nesta reunião. Visto da professora:_______________________ Márcia Cristina Data:__________________ 68 Anexo J – Ata de Reunião nº4 ATA DE REUNIÃO TCC 2013 TACHOMETER (PROJETO K) 12/07/2013 Nº 4 Reuníram se na empresa Eletrotécnica Sacch Ltda., patrocinadora do projeto de TCC 2013, Gabriela D'Angelo, Lucas Bulgarelli, Luiz Tiago, Willian Onoue e os engenheiros da empresa para discutir os tópicos abaixo: ● Apresentação de um novo layout de tela, inclusão de novas abas e funções de calibração. ● Escolha do nome definitivo do projeto: Tachometer. ● Apresentação de melhorias feitas no protocolo serial. ● Atribuição de tarefas aos integrantes do grupo (elaboração do fluxograma e documentação do protocolo serial). Elaboração de botões personalizados, pesquisa sobre novos elementos (barra de progressão, gráfico) que serão possivelmente integrados à interface gráfica do projeto. ● Visto da professora:_______________________ Márcia Cristina Data:__________________ 69 Anexo K – Ata de Reunião nº5 ATA DE REUNIÃO TCC 2013 TACHOMETER (PROJETO K) 19/07/2013 Nº 5 Reuníram se na empresa Eletrotécnica Sacch Ltda., patrocinadora do projeto de TCC 2013, Gabriela D'Angelo, Lucas Bulgarelli, Luiz Tiago, Willian Onoue junto aos engenheiros da empresa, onde foram realizadas as seguintes tarefas: ● Finalização do layout e configuração das novas abas. ● Implementação de novas funções no projeto. ● Elaboração do manual de instalação do JDK, NetBeans e RXTX. ● Início da elaboração de fluxogramas. ● Inclusão de encriptação simples (XOR) para transmissão e recepção dos dados. Visto da professora:_______________________ Márcia Cristina Data:__________________