KW2000

RODRIGO PVOA

APLICAO DO PROTOCOLO KW2000 PARA LEITURA DE DADOS DISPONVEIS NO MDULO DE CONTROLE DO

MOTOR DE UM VECULO POPULAR

So Paulo

2007

RODRIGO PVOA



Trabalho de Concluso de Curso Apresentado Escola Politcnica da Universidade de So Paulo para obteno do ttulo de Mestre Profissional em Engenharia Automotiva

So Paulo 2007

RODRIGO PVOA



Trabalho de Concluso de Curso Apresentado Escola Politcnica da Universidade de So Paulo para obteno do ttulo de Mestre Profissional em Engenharia Automotiva rea de Concentrao: Engenharia Automotiva Orientador: Prof. Doutor Lucas Antonio Moscato Co-orientador: Prof. Doutor Jun Okamoto Jr.

So Paulo 2007

DEDICATRIA

Primeiramente a Deus por permitir a vida humana na Terra mesmo frente a tanta calamidade causada pelo homem, minha famlia por incentivar-me a lutar na vida e

minha esposa por dividir comigo o jugo desta luta.

RESUMO

Atualmente a programao das ferramentas de diagnstico eletrnico, utilizadas por oficinas e rede de concessionrias de algumas montadoras de veculos do Brasil, executada por mo-de-obra internacional com elevado custo, impactando negativamente o custo estrutural das empresas nacionais que dependem deste servio. Desta forma, surgiu o interesse na nacionalizao desta programao. A proposta de pesquisa deste trabalho teve como objetivo a familiarizao com o protocolo de diagnstico KW2000 (Keyword 2000), que atualmente classificado como o principal protocolo utilizado para leitura de informaes dos mdulos eletrnicos de controle de dispositivos em veculos nacionais, atravs de ferramentas de diagnstico dedicadas ou genricas, utilizadas por toda a rede de concessionrias e oficinas do pas. O projeto foi formado por duas partes principais, a saber, pesquisa dos requerimentos do protocolo por meio de consulta s normas internacionais que padronizam a aplicao deste protocolo e desenvolvimento de uma interface de software atravs do Delphi (linguagem de computao baseada em Pascal), a qual extraiu do mdulo de controle do motor de um veculo popular as informaes existentes relacionadas ao funcionamento do motor e identificao do prprio mdulo, atualizando-as continuamente na tela de um computador que recebe e solicita as informaes atravs da porta serial. Palavras-Chave: Protocolos de Comunicao, Desenvolvimento de Software, Veculos Populares

ABSTRACT

Nowadays the programming of the electronic diagnosis tool, used by workshops and dealers of some Brazilian automobile companies, is performed by foreign labor with high cost, negatively impacting the structural cost of national companies which depend on this kind of service. This way, it encourages the interest in this programming nationalization. The research proposal of this work was getting familiarized with the diagnostic protocol KW2000 (Keyword 2000) which, nowadays, is classified as the main protocol used for information exchange between the vehicle control module and the diagnosis tool in Brazilian market. The project was built in two main parts. The first one consists in a protocol requirements research, consulting the international standardizations which define KW2000 protocol. The second one consists in a software interface development based on Delphi (computer language derived from Pascal), which get information from an economy class vehicle engine control module regarding the engine behavior and the controller identification. This data is updated continuously and shown on the computer screen which receives and requests such information through serial communication port. Keywords: Communication Protocols, Software Development, Economy Class Vehicles.

LISTA DE ILUSTRAES

Figura 1 - Conexo da Ferramenta de Diagnstico ............................................... 11

Figura 2 - Proposta de conexo para aplicao em Delphi ................................. 11

Figura 3 - Topologia ............................................................................................... 14

Figura 4 - Estrutura da mensagem......................................................................... 15

Figura 5 - Tipos de mensagem .............................................................................. 18

Figura 6 - Intervalos de tempo ............................................................................... 20

Figura 7 - Uso dos servios de comunicao......................................................... 23

Figura 8 - Modos de Inicializao........................................................................... 26

Figura 9 - Key Bytes............................................................................................... 27

Figura 10 - Inicializao 5-Baud............................................................................... 29

Figura 11 - Inicializao Fast ................................................................................... 31

Figura 12 - Estrutura da aplicao desenvolvida ..................................................... 44

Figura 13 - Conector de diagnstico ........................................................................ 45

Figura 14 - Ciclo Wake-up........................................................................................ 46

Figura 15 - Tela de leitura dos dados do motor........................................................ 54

Figura 16 - Tela de leitura da identificao do controlador do motor ....................... 59

LISTA DE TABELAS

Tabela 1 - Forma do cabealho da mensagem....................................................... 16

Tabela 2 - Presena do Additional Length Byte ...................................................... 17

Tabela 3 - Descrio dos intervalos de tempo ........................................................ 20

Tabela 4 - Configurao Normal dos Parmetros de Intervalo de Tempo .............. 21

Tabela 5 - Clculo do Parmetro P2max ................................................................ 21

Tabela 6 - Servio StartCommunication ............................................................... 24

Tabela 7 - Significado dos Bits nos Key Bytes........................................................ 27

Tabela 8 - Valores possveis para os Key Bytes..................................................... 28

Tabela 9 - Intervalos para Inicializao 5-Baud ...................................................... 30

Tabela 10 - Intervalos para Inicializao Fast........................................................... 32

Tabela 11 - Mensagem StartCommunicationRequest ............................................ 32

Tabela 12 - Mensagem StartCommunication Positive Response........................... 33

Tabela 13 - Servio StopCommunication ............................................................... 33

Tabela 14 - Mensagem StopCommunication Request ........................................... 34

Tabela 15 - Mensagem StopCommunication Positive Response ........................... 34

Tabela 16 - Mensagem StopCommunication Negative Response ......................... 35

Tabela 17 - Servio AccessTimingParameter......................................................... 35

Tabela 18 - Modo de Seleo ................................................................................... 37

Tabela 19 - Mensagem AccessTimingParameter Request..................................... 38

Tabela 20 - Mensagem AccessTimingParameter Positive Response .................... 38

Tabela 21 - Mensagem AccessTimingParameter Negative Response................... 39

Tabela 22 - Servio SendData................................................................................ 39

LISTA DE ABREVIATURAS E SIGLAS

KWP2000 Keyword Protocol 2000

Fmt Format

Tgt Target

Src Source

Len Length

KB Key Byte

CARB California Air Resources Board

SId Service Identification

CS Checksum

Wup Wake up

Rep Repouso

Inil Inicializao

SUMRIO

1 Introduo............................................................................. 10

2 O Protocolo Keyword 2000 ................................................... 12

3 Especificaes...................................................................... 14

3.1 Topologia fsica................................................................................................14

3.2 Estrutura da Mensagem...................................................................................15

3.2.1 Cabealho........................................................................................................15

3.2.1.1 Format Byte (Fmt) .....................................................................................16

3.2.1.2 Target Byte (Tgt) .......................................................................................16

3.2.1.3 Source Byte (Src)......................................................................................17

3.2.1.4 Additional Length Byte (Len) .....................................................................17

3.2.1.5 Tipos de mensagens.................................................................................17

3.2.2 Bytes de Dados ...............................................................................................19

3.2.3 Verificao (Checksum) ...................................................................................19

3.2.4 Intervalo de Tempo ..........................................................................................19

3.2.4.1 Parmetros ...............................................................................................19

3.2.4.2 Excees ..................................................................................................22

3.3 Estrutura da Mensagem...................................................................................22

3.3.1 Geral................................................................................................................22

3.3.2 Servio StartCommunication .........................................................................23

3.3.2.1 Definio do Servio .................................................................................23

3.3.2.2 Tabela de Servio .....................................................................................24

3.3.2.3 Procedimento de Servio ..........................................................................24

3.3.2.4 Implementao..........................................................................................25

3.3.2.4.1 Key Bytes (KB) .....................................................................................26

3.3.2.4.2 Inicializao com Palavra de Endereo 5-Baud....................................28

3.3.2.4.2.1 Inicializao CARB ........................................................................28

3.3.2.4.2.2 Inicializao 5-Baud .......................................................................29

3.3.2.4.2.3 Inicializao Fast ...........................................................................31

3.3.3 Servio StopCommunication..........................................................................33


3.3.3.2 Tabela de Servio .....................................................................................33


3.3.3.4 Implementao..........................................................................................34

3.3.4 Servio AccessTimingParameter ...................................................................35


3.3.4.2 Tabela de Servio .....................................................................................35


3.3.4.4 Implementao..........................................................................................37

3.3.4.5 Bytes da Mensagem .................................................................................38

3.3.5 Servio SendData..........................................................................................39

3.3.5.1 Definio...................................................................................................39

3.3.5.2 Tabela de Servio .....................................................................................39

3.3.5.3 Procedimento do Servio ..........................................................................40

3.3.6 Manuseando Erros...........................................................................................40

3.3.6.1 Servio StartCommunication...................................................................40

3.3.6.2 Prticas comuns na comunicao.............................................................41

3.3.6.3 Mdulo detecta erros provenientes da ferramenta de diagnstico.............41

3.3.6.4 Ferramenta de diagnstico detecta erro na resposta do veculo ...............42

3.3.6.5 Mdulo detecta erro na resposta do mdulo .............................................42

3.3.6.6 Ferramenta de diagnstico detecta erros de sua prpria transmisso.......42

4 Aplicao do Protocolo KW2000 ........................................ 43

4.1 Introduo........................................................................................................43

4.2 Objetivo ...........................................................................................................44

4.3 Desenvolvimento .............................................................................................44

4.3.1 Taxa de transferncia e nveis dos sinais eltricos ..........................................45

4.3.2 Intervalos de tempo .........................................................................................46

4.3.3 Desenvolvimento do Software..........................................................................47

5 Concluso............................................................................. 66

6 Referncias .......................................................................... 67

10

1 Introduo

O grande interesse na familiarizao com o protocolo KW2000, baseia-se na possibilidade

de nacionalizar a programao de ferramentas de diagnstico eletrnico, utilizadas por

oficinas e rede de concessionrias.

Atualmente algumas empresas do ramo automobilstico pagam pela realizao do

desenvolvimento do software de suas ferramentas de diagnstico em territrio estrangeiro, a

partir de descritivos funcionais adquiridos junto aos fornecedores dos mdulos de controle

dos dispositivos dos veculos que, em muitas oportunidades, esto localizados em nosso

prprio pas. Esta prtica causa um grande impacto no custo estrutural destas empresas

(indicador financeiro considerado de importncia vital para as empresas do ramo hoje em

dia), j que os custos da mo-de-obra de pases europeus ou norte-americanos (detentores

do conhecimento) so excessivamente superiores aos custos da mo-de-obra nacional.

Aliado a isso, ainda h uma despesa adicional relacionada taxa cobrada pelo governo

federal devido importao de servios, a qual est hoje em 49,73% (Fonte: Departamento

de Compras da General Motors do Brasil).

Uma outra desvantagem est no tocante flexibilizao e agilidade no processo de

atualizao do software da ferramenta visando cobrir lanamentos de veculos ou eventuais

bugs em programas desenvolvidos anteriormente, uma vez que os autores destas

atualizaes encontram-se em outros pases.

No h interesse de se criar uma ferramenta de diagnstico como fruto deste projeto. O

interesse realmente a familiarizao com o protocolo para tornar a programao das

ferramentas de diagnstico, que possuem linguagem prpria, mais acessvel. Para tanto,

ser explorado o conceito do protocolo KW2000, a fim de compreender como o protocolo

funciona e, desenvolver-se- uma aplicao em Delphi para visualizar o comportamento do

protocolo em atividade.

A explorao do conceito do protocolo ser realizada, basicamente, atravs da aplicao da

metodologia de levantamento de informaes da ISO 14230 (que define o protocolo

KW2000), bem como das informaes contidas no descritivo funcional para diagnstico do

mdulo de controle do motor de um veculo popular. Adicionalmente, outras literaturas sero

11

Veculo

Veculo

analisadas com o objetivo de enriquecer o detalhamento das informaes referentes ao

protocolo.

Sobre a aplicao em Delphi para anlise do comportamento do protocolo, o diagrama de

blocos a seguir expe a forma de conexo de uma ferramenta de diagnstico eletrnico

genrica a um veculo:

Figura 1 - Conexo da Ferramenta de Diagnstico

A proposta para familiarizao com o protocolo KWP2000 pode ser observada atravs do

seguinte diagrama de blocos:

Figura 2 - Proposta de conexo para aplicao em Delphi

Relacionando em tpicos, o projeto consiste em:

- Levantamento das informaes relacionadas ao protocolo Keyword 2000;

- Obteno de uma Interface Eletrnica (Hardware) para adequao dos sinais eltricos;

- Programao em linguagem Delphi para elaborao de uma interface, com a finalidade

de exibir os dados que sero colhidos, atravs da porta serial RS-232.

A seguir so apresentadas as informaes referentes ao protocolo.

Ferramenta de

Diagnstico

KWP2000

Interface Eletrnica (adequao de

sinais)

PC executando interface

programada em Delphi.

KWP2000 KWP2000

12

2 O Protocolo Keyword 2000

Com a exploso eletrnica no ramo automobilstico no final dos anos 80 e comeo dos anos

90, cada montadora acabou recorrendo a protocolos de comunicao prprios para

obteno de dados de diagnstico eletrnico em veculos automotores. Desta forma,

existiam inmeras vertentes de solues para cada problema encontrado relacionado a esta

atividade.

Em meados dos anos 90, vrias empresas do ramo automotivo se juntaram para criar um

protocolo de comunicao padronizado, que posteriormente foi batizado de Keyword

Protocol 2000. A seguir so apresentadas as empresas que participaram deste processo:

- Adam Opel AG

- AISIN AW CO., Limited Japan

- Audi AG / Volkswagen AG

- BMW AG

- Daimler-Benz AG

- Debis Systemhaus GmbH

- DELCO Electronics Europe

- DSA Daten und Systemtechnik GmbH

- ETAS GmbH & Co. KG

- FEV Motorentechnik GmbH & Co. KG

- GenRad Europe Ltd.

- GM Europe GmbH Service Technology Group Intl Operations

- Hella KG

- Isuzu Motors Ltd.

- Kelsey-Hayes

- LucasVarity

- MAN Nutzfahrzeuge AG

- Mecel AB

- Robert Bosch GmbH

- Saab Automobile AB

- Siemens AG

- Softing GmbH

13

- VDO Adolf Schindling AG

Hoje o protocolo KW2000 amplamente utilizado no desenvolvimento de mdulos

eletrnicos e ferramentas de diagnstico para o setor automobilstico, o que incentivou o

aprofundamento da pesquisa do protocolo atravs deste trabalho.

A seguir sero apresentadas as especificaes deste protocolo.

14

3 Especificaes

3.1 Topologia fsica

O protocolo KW2000 utiliza o conceito bus, tendo como estrutura duas linhas seriais para

transmisso de dados: Linha K, que utilizada para comunicao e inicializao e, Linha L,

que opcional e utilizada apenas para inicializao. A figura a seguir ilustra esta estrutura.

Figura 3 - Topologia

Uma outra estrutura possvel a conexo n-a-n, onde a ferramenta de diagnstico

conectada somente a um mdulo eletrnico e tambm utiliza o conceito bus.

Ferramenta de diagnstico

Mdulo n

Mdulo 1

Mdulo 2

Linha L

Linha K

15

3.2 Estrutura da Mensagem

A mensagem de dados no protocolo KW2000 formada por trs partes:

- cabealho

- bytes de dados

- verificao (Checksum)

A figura a seguir mostra a estrutura da mensagem.

Figura 4 - Estrutura da mensagem

Obs.: Os bytes Tgt, Src e Len so opcionais, dependendo do Format Byte (Fmt) veja

3.2.1.1.

3.2.1 Cabealho

O cabealho formado por no mximo 4 bytes, conforme ilustrado na figura 4. O Format

Byte (Fmt) contm informaes sobre o formato da mensagem. O Target Byte (Tgt) e o

Source Byte (Src) so opcionais para uso em conexes de mltiplos ns. O Additional

Length Byte (Len) tambm opcional e especifica mensagens de at 255 bytes.

Fmt CS Src Len SId .. Dados .. Tgt

Cabealho Bytes de Dados Verificao

max. 4 bytes max. 255 bytes

1 byte

16

3.2.1.1 Format Byte (Fmt)

O Format Byte contm 6 bits que podem ser utilizados para informar quantos bytes de

dados, incluindo o SId (Service Identification) sero enviados na mensagem. Desta forma,

para que a indicao de tamanho da mensagem seja indicada no Format Byte, o nmero

efetivo de bytes de dados (incluindo o Sid) no pode ultrapassar 63 (Tabela 2). Os 2 bits

mais significativos indicam o endereamento da mensagem (existncia e modo).

Os bits A1 e A0 podem assumir os seguintes valores:

A1 A0 Significado

0 0 Sem informao de endereamento

0 1 Modo de exceo (CARB)

1 0 Com informao fsica de endereamento

1 1 Com informao funcional de endereamento

Tabela 1 - Forma do cabealho da mensagem

Obs.: O modo de exceo CARB no objeto de estudo deste trabalho. Informaes sobre

este modo podem ser obtidas atravs das normas ISO 9141-2 e SAE J1979.

3.2.1.2 Target Byte (Tgt)

Este byte especifica o endereo do objetivo da mensagem e sempre usado com o Source

Byte. Quando usado na mensagem de solicitao, ou seja, da ferramenta de diagnstico

para os mdulos eletrnicos, ele pode indicar endereamento fsico ou funcional. J a

mensagem de retorno dos mdulos para a ferramenta de diagnstico, deve sempre indicar o

endereamento fsico. Somente se faz necessrio o seu uso quando se trata de uma

estrutura com mltiplos ns.

Obs.: Para saber o correto endereo a ser utilizado, pode-se consultar as normas ISO

14230-2 e SAE J2178-1.

A1 A0 L5 L4 L3 L2 L1 L0

7 6 5 4 3 2 1 0

17

3.2.1.3 Source Byte (Src)

Este byte utilizado em conjunto com o Target Byte e somente necessrio para estruturas

de mltiplos ns, indicando o endereo do dispositivo que est transmitindo a mensagem.

Deve sempre ser endereamento fsico, que especificado nas normas ISO 14230-2 e SAE

J2178-1.

3.2.1.4 Additional Length Byte (Len)

Este byte utilizado quando os bits de tamanho do Format Byte esto zerados (L0 a L5),

conforme mostrado na Tabela 2. Em geral, sua utilizao ocorre quando os bytes de dados

(incluindo o SId) so superiores a 63 bytes, limitados a 255. Tambm pode ser utilizado para

mensagens com um nmero de bytes de dados inferior a 64, porm o Format Byte capaz

de indicar este tamanho, tornando o Additional Length Byte desnecessrio.

Tamanho indicado no Tamanho

Format Byte Additional Length Byte

< 64 XX00 0000 Presente

< 64 XXLL LLLL No presente

64 XX00 0000 Presente

Tabela 2 - Presena do Additional Length Byte

Obs.: XX: 2 bits com informao sobre o endereamento

LL LLLL: 6 bits com informao sobre o tamanho do byte de dados

3.2.1.5 Tipos de mensagens

Com estas definies possvel definir 4 formas de mensagens, exibidas na figura a seguir:

18

a) Cabealho com informao de modo de endereo, sem o Additional Length Byte

b) Cabealho com informao de endereo, sem o Additional Length Byte

c) Cabealho sem informao de endereo, com o Additional Length Byte

d) Cabealho com informao de endereo, com o Additional Length Byte

Fmt Format Byte

Tgt Target Byte (opcional)

Src Source Byte (opcional)

Len Additional Length Byte (opcional)

SId Service Identification

Dados Dados da Mensagem

CS Checksum

Figura 5 - Tipos de mensagem

Fmt CS SId .. Dados ..

Tamanho

Fmt CS Src SId .. Dados .. Tgt

Tamanho

Fmt CS Src Len SId .. Dados .. Tgt

Tamanho

Fmt CS Len SId .. Dados ..

Tamanho

19

3.2.2 Bytes de Dados

Este campo da mensagem pode conter at 63 bytes ou at 255 bytes, dependendo da

definio do tamanho da mensagem no cabealho (veja 3.2.1 Cabealho). Seu primeiro byte

o Service Identification (SId), que pode ser seguido por parmetros ou dados, dependendo

do servio selecionado. Estes bytes so definidos na ISO 14230-3 no tocante a servios de

diagnstico.

3.2.3 Verificao (Checksum)

O byte de verificao existente no fim da mensagem pode ser definido como uma simples

somatria de todos os bytes da mensagem, excluindo ele prprio e limitando-se a 2

caracteres em hexadecimal.

Como exemplo, suponha que foram recebidos 6 bytes com os seguintes contedos (em

hexadecimal):

- 80h / 11h / F1h / 02h / 21h / 01h

O valor do Checksum dado por: 80h+11h+F1h+02h+21h+01h = 1A6h, que limitado a 2

caracteres igual a A6.

3.2.4 Intervalo de Tempo

3.2.4.1 Parmetros

Durante operao normal, os parmetros de intervalo de tempo se comportam como

ilustrado na figura a seguir:

20

Figura 6 - Intervalos de tempo

Intervalo Descrio

P1 Intervalo de tempo entre os bytes da resposta do mdulo

P2 Intervalo de tempo entre a solicitao da ferramenta de diagnstico e a resposta do mdulo ou o tempo entre duas respostas de mdulos diferentes

P3 Intervalo de tempo entre a ltima resposta dos mdulos e o incio de uma nova solicitao da ferramenta de diagnstico (Exceo 4.2.4.2)

P4 Intervalo de tempo entre os bytes da solicitao da ferramenta de diagnstico

Tabela 3 - Descrio dos intervalos de tempo

Existem duas configuraes padres para os intervalos de tempo:

1 Configurao para comunicao com endereamento fsico e funcional convencional,

onde so necessrios tempos longos para permitir incluso de gerenciamento de

barramento;

2 Configurao restrita para endereamento fsico, permitindo comunicao mais rpida.

A ferramenta de diagnstico informada quanto capacidade de um mdulo atravs de Key

Bytes (veja 3.3.2.4.1 Key Bytes). Os parmetros relacionados aos intervalos de tempo

podem ser modificados com o servio de comunicao AccessTimingParameter (veja 3.3.4

Servio AccessTimingParameter).

importante notar algumas limitaes quanto ao uso dos parmetros de intervalos de

tempo, como seguem:

P3min > P4min

Pimin < Pimax, onde i = 1, 2, 3 ou 4

Para evitar confuses quanto deteco de fim de mensagem por estouro do tempo, as

seguintes regras devem ser respeitadas:

Solicitao da Ferramenta de

Diagnstico

Solicitao da Ferramenta de

Diagnstico Resposta do

Mdulo 1 Resposta do

Mdulo 2

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

P4 P2 P2 P2 P1

P3

21

P2min > P4max

P2min > P1max

Como pode ser observado, a escolha de parmetros apropriados primordial para o bom

funcionamento da comunicao entre a ferramenta de diagnstico e os mdulos eletrnicos.

muito importante respeitar as limitaes dos mdulos e da ferramenta de diagnstico,

definindo os parmetros de intervalo de tempo conforme as caractersticas mais crticas

(piores casos) dos dispositivos que compem a rede de comunicao. As tabelas a seguir

apresentam os valores padres para estes parmetros, apontando os limites e a resoluo

que devem ser usados para configurar um outro valor atravs do servio de comunicao

AccessTimingParameter:

Valores Mnimos Valores Mximos Parmetro Limite

Inferior Padro Resoluo Padro

Limite Superior

Resoluo

P1 0 (ms) 0 (ms) - 20 (ms) 20 (ms) -

P2 0 (ms) 25 (ms) 0,5 (ms) 50 (ms) Veja tabela 4

P3 0 (ms) 55 (ms) 0,5 (ms) 5000 (ms) 250 (ms)

P4 0 (ms) 5 (ms) 0,5 (ms) 20 (ms) 20 (ms) -

Tabela 4 - Configurao Normal dos Parmetros de Intervalo de Tempo

Valor Hex. Resoluo Valor Mximo Mtodo para o Clculo do Valor Mximo

01 a F0 25 (ms) 25 a 6000 (ms) (Valor Hex.) x (Resoluo)

F1 6400 (ms)

F2 12800 (ms)

F3 19200 (ms)

F4 25600 (ms)

F5 32000 (ms)

F6 38400 (ms)

F7 44800 (ms)

F8 51200 (ms)

F9 57600 (ms)

FA 64000 (ms)

FB 70400 (ms)

FC 76800 (ms)

FD 83200 (ms)

FE

Veja a Coluna

Mtodo para o

Clculo do Valor

Mximo

83600 (ms)

(Parte Baixa do Valor Hex.) x 256 x 25

Exemplo: Valor Hex. = FA Parte Baixa = A

(A)16 = 10 10 x 256 x 25 = 64000

FF - No Aplicvel O valor do parmetro deve sempre ser um valor de byte individual no servio AccessTimingParameter. As modificaes dos intervalos devem ser ativadas atravs da implementao do servio AccessTimingParameter.

Tabela 5 - Clculo do Parmetro P2max

22

3.2.4.2 Excees

O intervalo de tempo definido pelo parmetro P2 pode ser estendido para possibilitar que o

servidor responda a uma solicitao em um tempo superior ao limitado por P2. Esta exceo

somente permitida quando ocorre uma ou vrias mensagens de resposta negativa, cujo

cdigo 78h (Request Correctly Received - Response Pending), proveniente do servidor.

Tal cdigo de resposta pode ser usado somente nos casos em que o servidor no conseguir

enviar uma resposta negativa ou positiva, relativa mensagem recebida, durante o intervalo

P2. Este processo caracteriza a incapacidade do servidor de responder ao cliente no

intervalo P2, o que deve fazer com que este parmetro seja ajustado com o mesmo valor do

parmetro P3, permitindo nova tentativa por parte do servidor.

Assim que o servidor finalizar a tarefa solicitada pelo cliente, ele deve enviar um cdigo de

resposta negativa ou positiva (diferente do cdigo 78h), baseado na mensagem recebida.

Quando o cliente recebe a primeira mensagem diferente do cdigo 78h, tanto o servidor

como o cliente devem ajustar o parmetro P2 para o valor anterior primeira resposta

negativa 78h recebida, restaurando o intervalo de tempo padro.

3.3 Estrutura da Mensagem

3.3.1 Geral

Alguns servios so necessrios para manter e estabelecer a comunicao entre os

componentes da rede. Tais servios, semelhante aos de diagnstico, so formalizados na

norma ISO14229, que explica seu significado e o procedimento de aplicao. Seus

parmetros so classificados como:

- Mandatrio = M

- Seleo Possvel = S

- Condicional = C

- Opcional do usurio = U

23

Geralmente, estes servios no so mandatrios. Somente o servio StartCommunication

deve ser implementado. Este servio, assim como o AccessTimingParameter, usado

para iniciar uma comunicao de diagnstico. A figura a seguir ilustra o uso do servio de

comunicao.

Figura 7 - Uso dos servios de comunicao

3.3.2 Servio StartCommunication

3.3.2.1 Definio do Servio

A funo deste servio iniciar a comunicao para a troca de dados de diagnstico.

Servio de diagnstico

solicitado

Comunicao funcionando?

Parmetros de comunicao

corretos?

Iniciar comunicao

Ajuste dos parmetros

Servio de diagnstico

No Sim

No Sim

24

3.3.2.2 Tabela de Servio

A tabela a seguir descreve os parmetros do servio supracitado.

Parmetro Classificao

StartCommunication Request M

Identificador de Modo de Inicializao M

Endereo de Inicializao do Objetivo M

Endereo de Inicializao da Origem C1 StartCommunication Positive Response

Endereo do Objetivo Endereo da Origem Key Bytes

M

C2 C2 M2

1) O caminho da inicializao determinado pelo identificador do modo de inicializao. 2) C1: Endereo da Inicializao da Origem adicionado se o Identificador do Modo de

Inicializao representa uma Inicializao Fast 3) C2: Endereo de Objetivo e Origem so adicionados se a informao do endereo

usada no cabealho.

Tabela 6 - Servio StartCommunication

3.3.2.3 Procedimento de Servio

Uma vez recebida uma indicao inicial de StartCommunication, o mdulo eletrnico deve

verificar se a conexo solicitada pode ser inicializada com as condies do momento. Isto

feito, o mdulo deve executar todas as aes necessrias para iniciar a conexo de

comunicao e enviar uma resposta inicial de StartCommunication com o parmetro

Positive Response selecionado. Caso a conexo no possa ser inicializada por qualquer

motivo, o mdulo deve se manter em operao normal (consulte Servio

StartCommunication na seo 3.3.6 Manuseando Erros).

25

3.3.2.4 Implementao

O servio StartCommunication utilizado para inicializar uma comunicao na linha K.

Existem diferentes possibilidades para fazer isso:

- Inicializao CARB;

- Inicializao 5-Baud;

- Inicializao Fast.

A figura a seguir apresenta as trs possibilidades e o estado do mdulo aps cada tipo de

inicializao. Terminada a inicializao, os mdulos envolvidos ficaro no mesmo estado:

- Todos os parmetros de comunicao so carregados com os valores padres de acordo

com os Key Bytes;

- O mdulo fica aguardando a primeira solicitao da ferramenta de diagnstico por um

perodo equivalente a P3;

- O mdulo fica no modo de diagnstico padro, tendo sua funcionalidade bem definida.

Existem alguns fatores que so comuns para todos os modos de inicializao:

- Antes de qualquer atividade deve haver um intervalo para garantir que no ocorra conflitos

na rede (bus-idle time);

- A ferramenta de diagnstico envia um modelo de inicializao;

- Todas as informaes que so necessrias para estabelecer a comunicao so parte

integrante da resposta do mdulo.

26

Figura 8 - Modos de Inicializao

3.3.2.4.1 Key Bytes (KB)

atravs destes bytes que um mdulo informa a ferramenta de diagnstico sobre o

cabealho, intervalo e tamanho da informao. Assim, um mdulo no tem que suportar

todas as possibilidades destes parmetros. Basta informar ferramenta de diagnstico

quais so suportados. A decodificao dos Key Bytes definida na ISO 9141.

Servio StartCommunication

Modo de Inicializao

= CARB?

Modo de Inicializao =

5-Baud ou Fast?

Intervalo CARB Modo CARB

Intervalo padro Modo padro

Inicializao CARB

Sim No

Inicializao Fast

Inicializao 5-Baud

Fim do servio StartCommunication

5-Baud Fast

27

A figura a seguir mostra a representao grfica dos Key Bytes. O significado de cada um

de seus bits est na tabela 7 e os possveis valores na Tabela 8.

1) Bit de incio

2) Bit menos significativo

3) Bit mais significativo

4) Bit de equalizao

5) Bit de paridade

Figura 9 - Key Bytes

Valor Bit

0 1

AL0 Tamanho da Informao no suportada no Format Byte,

Tamanho da Informao suportada no Format Byte

AL1 Additional Length Byte no suportado Additional Length Byte suportado

HB0 1 Byte de cabealho no suportado 1 Byte de cabealho suportado

HB1 Endereos de Objetivo e Origem no suportados

Endereos de Objetivo e Origem suportados

TP01) Parmetro de intervalo normal selecionado

Parmetro de intervalo estendido selecionado

TP11) Parmetro de intervalo estendido selecionado

Parmetro de intervalo normal selecionado

1) Somente TP0, TP1 = 0, 1 ou 1, 0 so permitidos

Tabela 7 - Significado dos Bits nos Key Bytes

AL0

2)

AL1

HB0

HB1

TP0

TP1

1

3)

P

4)

1

2)

1

1

1

0

0

0

3)

1

4) 1) 1) 5) 5)

Key Byte 1 (parte baixa) Key Byte 2 (parte alta)

Tempo

28

Key Bytes Suportado

Binrio

KB2 KB1 Hex. Dec.

1) Tamanho da Informao

Tipo de Cabealho

Intervalo

1000 1111 1101 0000 $8FD0 2000 2)

1000 1111 1101 0101 $8FD5 2005 Format Byte 1000 1111 1101 0110 $8FD6 2006 Additional Length Byte 1000 1111 0101 0111 $8F57 2007 Ambos os Modos

Sem informao de endereo

1000 1111 1101 1001 $8FD9 2009 Format Byte 1000 1111 1101 1010 $5FDA 2010 Additional Length Byte 1000 1111 0101 1011 $8F5B 2011 Ambos os Modos

Com informao de endereo de Origem/Objetivo

1000 1111 0101 1101 $8F5D 2013 Format Byte 1000 1111 0101 1110 $8F5E 2014 Additional Length Byte 1000 1111 1101 1111 $8FDF 2015 Ambos os Modos

Ambos os Tipos

Estendido

1000 1111 1110 0101 $8FE5 2021 Format Byte 1000 1111 1110 0110 $8FE6 2022 Additional Length Byte 1000 1111 0110 0111 $8F67 2023 Ambos os Modos

Sem informao de endereo

1000 1111 1110 1001 $8FE9 2025 Format Byte 1000 1111 1110 1010 $8FEA 2026 Additional Length Byte 1000 1111 0110 1011 $8F6B 2027 Ambos os Modos

Com informao de endereo de Origem/Objetivo

1000 1111 0110 1101 $8F6D 2029 Format Byte 1000 1111 0110 1110 $8F6E 2030 Additional Length Byte 1000 1111 1110 1111 $8FEF 2031 Ambos os Modos

Ambos os Tipos

Normal

1) Para o clculo do valor decimal, zerar o bit de paridade de cada Key Byte, multiplicar o Key Byte 2 (KB2) por 128 (27) e somar o Key Byte 1 (KB1); 2) Com valor decimal de 2000, o mdulo no fornece informaes sobre quais opes so suportadas. Estas opes se referem ao uso de intervalo padro ou estendido, Additional Length Byte e Cabealho com ou sem informao de endereo; Em caso de Inicializao 5-Baud a ferramenta de diagnstico deve saber quais as opes que esto implementadas. Em caso de Inicializao Fast o uso do Cabealho e do Additional Length Byte ser igual aos casos de resposta positiva do mdulo eletrnico relacionada ao StartCommunicationSession.

Tabela 8 - Valores possveis para os Key Bytes

3.3.2.4.2 Inicializao com Palavra de Endereo 5-Baud

3.3.2.4.2.1 Inicializao CARB

Para o uso de CARB, apenas a inicializao 5-Baud possvel. Esta uma inicializao

funcional onde mensagens so enviadas para todos os mdulos relacionados. Para maiores

detalhes, consultar ISO 9141-2 e ISO 14230-4.

29

3.3.2.4.2.2 Inicializao 5-Baud

3.3.2.4.2.2.1 Geral

A figura a seguir mostra a forma geral da inicializao 5-Baud. O byte de endereo 5-Baud

transferido da ferramenta de diagnstico pelas linhas K e L. Aps enviar o byte de endereo

5-Baud, a ferramenta de diagnstico ir manter a linha L em nvel alto.

Aps receber o byte de endereo 5-Baud, o mdulo eletrnico enviar o modelo de

sincronizao 55h e os dois Key Bytes na taxa de comunicao atual. A ferramenta de

diagnstico envia o Key Bytes 2 com os bits invertidos e o mdulo envia o byte de endereo

com os bits invertidos.

No caso de uma inicializao fsica, o mdulo deve responder como mostra a Figura 10.

Para o caso de inicializao funcional, onde mais de um mdulo inicializado, o fabricante

deve cuidar para que todos os mdulos usem a mesma opo de protocolo. Apenas um

mdulo pode executar a seqncia de inicializao.

Figura 10 - Inicializao 5-Baud

W2

Ferramenta de diagnstico

(Linhas K e L)

Veculo (Linhas K e L)

Byte de Endereo

___ KB2

55h KB1 KB2 ________ Endereo

W5 W1 W3 W4 W4

5-Baud Taxa de transferncia da comunicao

30

A tabela a seguir apresenta os valores e significados dos intervalos da inicializao 5-Baud.

Estes valores so fixos e no podem ser alterados pelo servio

AccessCommunicationParameter.

Valores (ms) Parmetros de Intervalo Min. Max.

Descrio

W1 60 300 Tempo entre o final do byte de endereo e o inicio do modelo de sincronizao

W2 5 20 Tempo entre o final do modelo de sincronizao e o incio do Key Byte 1.

W3 0 20 Tempo entre os Key Bytes 1 e 2

W4 25 50

Tempo entre o Key Byte 2 enviado pelo mdulo e o mesmo byte com os bits invertidos enviado pela ferramenta de diagnstico. Este o mesmo tempo entre o Key Byte 2 invertido pela ferramenta e o endereo com os bits invertidos pelo mdulo.

W5 300 - Tempo mnimo anterior ao envio do byte de endereo por parte da ferramenta de diagnstico.

Tabela 9 - Intervalos para Inicializao 5-Baud

3.3.2.4.2.2.2 Key Bytes

So permitidas taxas de transferncias entre 1200 e 10400 kbps para comunicao. A

ferramenta de diagnstico ir reconhecer a taxa a partir do byte de sincronizao (55h).

3.3.2.4.2.2.3 Inicializao Funcional

O objetivo da inicializao funcional inicializar um grupo de mdulos. Os bytes de

endereo que definem um grupo funcional de mdulos seguem as seguintes regras:

- Endereos com valores inferiores a 80h so reservados para padronizaes futuras;

- Endereos com valores iguais ou superiores a 80h so especificados pela montadora.

Outros endereos funcionais definidos pela montadora em concordncia com a ISO 9141

(paridade mpar) tambm so possveis.

31

Por razes bvias, o endereamento funcional somente possvel quando todos os

mdulos trabalham na mesma taxa de transferncia.

3.3.2.4.2.2.4 Inicializao Fsica

Este procedimento vlido apenas quando a ferramenta de diagnstico estabelece

comunicao com um nico mdulo. O endereamento para inicializao 5-Baud

especificado na ISO 9141. A paridade mpar tambm possvel e os bytes de endereo so

definidos pela montadora.

3.3.2.4.2.3 Inicializao Fast

3.3.2.4.2.3.1 Geral

No caso da Inicializao Fast, todos os mdulos que sero inicializados devem usar taxa de

transferncia de 10400 kbps (tanto para inicializao como para comunicao).

A ferramenta de diagnstico envia um modelo de Wake-up (WuP) nas linhas K e L de

maneira sincronizada. O modelo inicia aps um tempo de repouso na linha K com um curto

tempo de Tinil. Aps o intervalo Twup, a ferramenta de diagnstico envia o primeiro bit do

servio StartCommunication, como mostra a figura a seguir:

Figura 11 - Inicializao Fast

Trep

Tinil

Twup P2

StartCommunication Request

StartCommunication Response

32

Existem trs possibilidades para o intervalo Trep.:

- Primeira transmisso aps acionamento da ferramenta de diagnstico: Trep W5min;

- Aps finalizao do servio StopCommunication: Trep P3min;

- Aps finalizar a comunicao por estouro (timeout) de P3max: Trep 0.

A tabela a seguir traz os valores de Tinil e Twup:

Parmetro Valor Min. (ms) Valor Max. (ms)

Tinil 25 1 ms 24 26 Twup 50 1 ms 49 51

Tabela 10 - Intervalos para Inicializao Fast

Aps o envio de um modelo de Wake-up, a ferramenta de diagnstico envia um

StartCommunicationRequest e aguarda a resposta do mdulo. A primeira mensagem da

Inicializao Fast sempre usa o Cabealho com endereos de Objetivo e Origem sem o

Additional Length Byte. O mdulo que recebe a solicitao pode responder com ou sem

informao de endereo e tamanho, informando estes atravs da indicao de modo

suportado nos Key Bytes.

3.3.2.4.2.3.2 Bytes para Mensagens

As tabelas a seguir descrevem as diferentes mensagens de servios para o

StartComunication:

N do Byte Nome do Parmetro CVT1) Vlr Hex. Mnemonic

1 Format Byte Endereamento fsico Endereamento funcional

M $81 $C1

FMT

2 Target Byte M $XX TGT 3 Source Byte M $XX SRC 4 StartCommunication Request Service Id M $81 SCR 5 Checksum M $XX CS

1) Veja 4.3.1

Tabela 11 - Mensagem StartCommunicationRequest

33


1 Format Byte M $XX FMT 2 Target Byte C2) $XX TGT 3 Source Byte C2) $XX SRC 4 Additional Length Byte C3) $XX LEN 5 StartCommunication Positive Response Service Id S $C1 SCRPR 6 Key Byte 14) M $XX KB1 7 Key Byte 24) M $XX KB2 8 Checksum M $XX CS

1) Veja 4.3.1 2) O Format Byte 10XX XXXX ou 11XX XXXX 3) O Format Byte XX00 0000 4) Veja 4.3.2.4.1 referente ao uso dos Key Bytes

Tabela 12 - Mensagem StartCommunication Positive Response

3.3.3 Servio StopCommunication


A funo deste servio finalizar a comunicao de diagnstico.


Parmetro Classificao

StopCommunication Request M

StopCommunication Positive Response S

StopCommunication Negative Response S

Cdigo de Resposta M

Tabela 13 - Servio StopCommunication

34


Quando recebe uma indicao inicial de StopCommunication, o mdulo deve verificar se

as condies do momento permitem finalizar a comunicao. Neste caso, este deve

executar todas as aes necessrias para finalizar a comunicao.

Sendo possvel finalizar a comunicao, o mdulo deve enviar uma resposta positiva com o

parmetro Positive Response selecionado antes que a comunicao seja terminada.

Caso a comunicao no possa ser finalizada, o mdulo deve enviar uma resposta negativa

com o parmetro Negative Response selecionado.

3.3.3.4 Implementao

A tabela a seguir apresenta as diferentes mensagens de solicitao para o

StopCommunication.


1 Format Byte M $XX FMT 2 Target Byte C2) $XX TGT 3 Source Byte C2) $XX SRC 4 Additional Length Byte C3) $XX LEN 5 StopCommunication Request Service Id M $82 SPR 6 Checksum M $XX CS

1) Veja 4.3.1 2) O Format Byte 10XX XXXX ou 11XX XXXX 3) O Format Byte XX00 0000

Tabela 14 - Mensagem StopCommunication Request


1 Format Byte M $XX FMT 2 Target Byte C2) $XX TGT 3 Source Byte C2) $XX SRC 4 Additional Length Byte C3) $XX LEN 5 StopCommunication Positive Response Service Id M $C2 SPRPR 6 Checksum M $XX CS

1) Veja 4.3.1 2) O Format Byte 10XX XXXX ou 11XX XXXX 3) O Format Byte XX00 0000

Tabela 15 - Mensagem StopCommunication Positive Response

35

N do Byte Nome do Parmetro CVT1)

Vlr Hex. Mnemonic

1 Format Byte M $XX FMT 2 Target Byte C2) $XX TGT 3 Source Byte C2) $XX SRC 4 Additional Length Byte C3) $XX LEN 5 StopCommunication Negative Response Service Id S $C1 SPRNR 6 StopCommunication Request Service Id M $82 SPR 7 Cdigo de Resposta4) = generalReject M $XX=$10 RC 8 Checksum M $XX CS

1) Veja 4.3.1 2) O Format Byte 10XX XXXX ou 11XX XXXX 3) O Format Byte XX00 0000 4) Outros cdigos de resposta so possveis: consulte ISO 14230-3

Tabela 16 - Mensagem StopCommunication Negative Response

3.3.4 Servio AccessTimingParameter


O propsito deste servio ler e alterar os parmetros padres relacionados aos intervalos

de tempo da rotina de comunicao quando esta estiver ativa. considerado um

procedimento complexo, que depende da capacidade e da topologia fsica dos mdulos

eletrnicos envolvidos.


AccessTimingParameter Request Timing Parameter Identifier (TPI) M

P2min C1)

P2max C1) P3min C1) P3max C1) P4min C1)

AccessTimingParameter Positive Response Timing Parameter Identifier (TPI) M

P2min C2) P2max C2) P3min C2) P3max C2) P4min C2)

AccessTimingParameter Negative Response S Response Code M

Timing Parameter Identifier M 1) A condio TPI=Set values

2) A condio TPI=Read limits, read current values

Tabela 17 - Servio AccessTimingParameter

36


Este procedimento tem quarto modos diferentes:

- Ler limites de parmetros possveis de intervalo de tempo;

- Configurar os parmetros de intervalo de tempo como padro;

- Ler os parmetros de intervalo de tempo que estiverem ativos;

- Configurar os parmetros de intervalo de tempo conforme valores dados.

Quando o mdulo receber uma indicao de AccessTimingParameter com TPI=0, este

deve ler os limites do parmetro de intervalo de tempo que ele deve suportar.

Se o acesso de leitura aos parmetros de intervalo de tempo for bem sucedido, o mdulo

deve enviar um AccessTimingParameter com os parmetros Positive Response.

Do contrrio, se o acesso de leitura aos parmetros de intervalo de tempo for mal sucedido,

o mdulo deve enviar um AccessTimingParameter com os parmetros Negative Response.

Quando receber uma indicao de AccessTimingParameter com TPI=1, o mdulo deve

alterar todos os parmetros de intervalo de tempo para valores padres e enviar um

AccesTimingParameter com os parmetros de Positive Response antes que os parmetros

carregados com valores padres se tornem ativos.

Se os parmetros no puderem ser alterados para os valores padres por qualquer razo, o

mdulo deve manter a comunicao e enviar um AccessTimingParameter com os

parmetros de Negative Response.

Aps receber um AccessTimingParameter com TPI=2, o mdulo deve ler os valores atuais

que esto sendo usados nos parmetros de intervalo de tempo.

Se o acesso de leitura aos parmetros de intervalo de tempo for bem sucedido, o mdulo

deve enviar um AccessTimingParameter com os parmetros Positive Response.

37

Mais uma vez, por questes bvias, se o acesso de leitura aos parmetros de intervalo de

tempo for mal sucedido, o mdulo deve enviar um AccessTimingParameter com os

parmetros Negative Response.

Uma vez recebido um AccessTimingParameter com TPI=3, o mdulo deve verificar se os

parmetros de intervalo de tempo podem ser alterados nas condies presentes neste

momento.

Se as condies forem vlidas, o mdulo deve executar todas as aes necessrias para

alterar os parmetros e enviar um AccessTimingParameter com os parmetros Positive

Response antes que os parmetros com os novos valores se tornem ativos.

Como anteriormente, se os parmetros no puderem ser alterados para os valores

desejados por qualquer razo, o mdulo deve manter a comunicao e enviar um

AccessTimingParameter com os parmetros Negative Response.

3.3.4.4 Implementao

A tabela a seguir apresenta a seleo dos modos read, write, current e limits atravs do

Timing Parameter Identifier:

Modo TPI CVT1)

Ler os limites 0000 0000 C2)

Configurar os parmetros para valores padres 0000 0001 Ler os valores atuais 0000 0010 C3) Configurar valores 0000 0011 C2)

1) Veja 5.1 2) Os parmetros de intervalo de tempo so includos na mensagem se TPI=3

3) Os parmetros de intervalo de tempo so includos na mensagem se TPI=0 ou 2

Tabela 18 - Modo de Seleo

38

3.3.4.5 Bytes da Mensagem

As tabelas de 19 a 21 descrevem as diferentes mensagens AccessTimingParameter.

Byte Nome do Parmetro CVT1) Vlrs Hex Mnemonic

1 Format Byte M $XX FMT 2 Target Address Byte C2) $XX TGT 3 Source Address Byte C2) $XX SRC 4 Additional Length Byte C3) $XX LEN 5 AccessTimingParameter Request Service Id S $83 ATP 6 Timing Parameters Identifier M $0X5) TPI 7 P2min C4) $XX P2min 8 P2max C4) $XX P2max 9 P3min C4) $XX P3min

10 P3max C4) $XX P3max 11 P4min C4) $XX P4min 12 Checksum M $XX CS

1) Veja 5.1 2) Format Byte 10XX XXXX ou 11XX XXXX 3) Format Byte XX00 0000 4) Os parmetros de intervalo de tempo so includos na mensagem se TPI=3 5) Onde X pode ser 0 (ler limites), 1 (configurar parmetros com valores padres), 3 (ler parmetros ativos), 4 (configurar parmetros com valores desejados)

Tabela 19 - Mensagem AccessTimingParameter Request


1 Format Byte M $XX FMT 2 Target Address Byte C2) $XX TGT 3 Source Address Byte C2) $XX SRC 4 Additional Length Byte C3) $XX LEN 5 AccessTimingParameter Positive Response

Service Id M $C3 ATPPR

6 Timing Parameters Identifier M $0X5) TPI 7 P2min C4) $XX P2min 8 P2max C4) $XX P2max 9 P3min C4) $XX P3min

10 P3max C4) $XX P3max 11 P4min C4) $XX P4min 12 Checksum M $XX CS

1) Veja 5.1 2) Format Byte 10XX XXXX ou 11XX XXXX 3) Format Byte XX00 0000 4) Os parmetros de intervalo de tempo so includos na mensagem se TPI=0 ou 2 5) Onde X pode ser 0 (ler limites), 1 (configurar parmetros com valores padres), 3 (ler parmetros ativos), 4 (configurar parmetros com valores desejados)

Tabela 20 - Mensagem AccessTimingParameter Positive Response

39


1 Format Byte M $XX FMT 2 Target Address Byte C2) $XX TGT 3 Source Address Byte C2) $XX SRC 4 Additional Length Byte C3) $XX LEN 5 Negative Response Service Id S $7F ATPNR 6 AccessTimingParameter Request Service Id M $10 ATP 7 Response Code4) = generalReject C4) $10 RC 8 Checksum M $XX CS

1) Veja 5.1 2) Format Byte 10XX XXXX ou 11XX XXXX 3) Format Byte XX00 0000 4) Outros Response Codes so possveis. Consulte ISO 14230-3 5) Onde X pode ser 0 (ler limites), 1 (configurar parmetros com valores padres), 3 (ler parmetros ativos), 4 (configurar parmetros com valores desejados)

Tabela 21 - Mensagem AccessTimingParameter Negative Response

3.3.5 Servio SendData

3.3.5.1 Definio

O propsito deste servio transmitir o dado a partir de um servio de solicitao e atravs

de uma conexo para comunicao baseada no protocolo KW2000.


A tabela a seguir ilustra os servios relacionados ao SendData:

SendData Request M

Service Data M SendData Positive Response S SendData Negative Response S

Response Code M

Tabela 22 - Servio SendData

40

3.3.5.3 Procedimento do Servio

Aps uma solicitao SendData de uma aplicao de camada, a respectiva camada de

conexo de dados do transmissor da mensagem ir executar todos os passos necessrios

para transmitir os parmetros da solicitao atravs de uma mensagem KWP2000. Isto

inclui a definio do cabealho (com o Format Byte), os dados da mensagem e o clculo do

Checksum, identificao de modo Idle, a transmisso dos bytes da mensagem e a

determinao do intervalo de tempo.

Uma vez recebida a mensagem pela conexo definida pelo protocolo KW2000, a

respectiva camada de conexo de dados do receptor da mensagem ir executar todas as

aes necessrias para prover camada de aplicao a informao recebida. Isto inclui o

reconhecimento do incio da mensagem, os intervalos de tempo, a recepo dos bytes da

mensagem, a verificao do checksum, segmentao dos dados baseado nas informaes

do Format Byte e entrega dos dados da mensagem camada de aplicao com a indicao

SendData.

Se o servio foi completado com sucesso, ou seja, a mensagem foi transmitida, um

SendData com o parmetro Positive Response selecionado entregue pela camada de

conexo do dispositivo de transmisso respectiva camada de aplicao.

Porm, se o servio no pode ser executado pela camada de conexo do dispositivo de

transmisso, um SendData com o parmetro Negative Response selecionado entregue

respectiva camada de aplicao.

3.3.6 Manuseando Erros

3.3.6.1 Servio StartCommunication

Se a ferramenta de diagnstico identificar um erro no Servio StartCommunication seja

proveniente do intervalo de tempo, seja por erro nos dados, esta deve aguardar por um

perodo de W5 antes de iniciar o processo novamente (atravs do modelo de Wake-up). Se

41

um mdulo detectar um erro proveniente da ferramenta de diagnstico, este deve ser

imediatamente preparado para reconhecer um outro Servio StartCommunication.

Tanto a ferramenta de diagnstico como o mdulo devem estar aptos a reconhecer falhas e

aceitar valores mximos de intervalos de tempo. Valores mnimos de erro de intervalos de

tempo podem ser descartados, mas podero causar erros na identificao dos bits.

3.3.6.2 Prticas comuns na comunicao

permitido, mas no mandatrio que a ferramenta de diagnstico e os mdulos possam

monitorar suas prprias mensagens. Isto normalmente utilizado onde o manuseio de erro

na fase de comunicao deve ser definido.

3.3.6.3 Mdulo detecta erros provenientes da ferramenta de diagnstico.

O mdulo deve verificar cada mensagem recebida atravs do Checksum e nmero de bytes

recebidos antes que o intervalo P2max seja executado. Se ambos estiverem errados, ento

o mdulo no deve enviar resposta alguma e deve ignorar a mensagem completamente.

No mandatrio que o mdulo verifique outros intervalos de tempo, mas isto pode ser feito

se conveniente. Caso um erro seja identificado neste caso, mais uma vez nenhuma

mensagem deve ser enviada.

O mdulo pode detectar outros erros como de formato ou contedo das mensagens, e estes

devem satisfazer as condies de Checksum e tamanho. Neste caso, para que a ferramenta

de diagnstico possa ser informada que no h apenas um simples problema de

comunicao, o mdulo deve responder com a resposta negativa apropriada.

42

3.3.6.4 Ferramenta de diagnstico detecta erro na resposta do veculo

Uma solicitao pode resultar em uma simples resposta de um simples mdulo ou em

mltiplas respostas de mltiplos mdulos. A ferramenta de diagnstico deve certificar que

todas as respostas so corretas em termos de tamanho e Checksum. Em caso de erro ou

falta de resposta durante P2max, ela deve retransmitir a mensagem original duas vezes

(totalizando trs transmisses) antes de considerar que h um erro mais severo ocorrendo.

A camada de aplicao deve ser informada dos erros na conexo de comunicao, o que

permitir ela executar os passos apropriados para cada caso.

3.3.6.5 Mdulo detecta erro na resposta do mdulo

O mdulo pode detectar diferenas entre o que ele transmitiu e o que foi detectado na linha

K. Neste caso ele no deve agir ou deve simplesmente tentar retransmitir a informao

dentro de um perodo P2 aps cessar as atividades no barramento. Isto permite a adaptao

de vrios mtodos de gerenciamento de barramento.

3.3.6.6 Ferramenta de diagnstico detecta erros de sua prpria transmisso

A ferramenta de diagnstico pode detectar diferenas entre o que ela transmitiu e o que foi

detectado na linha K. Neste caso ela deve retransmitir a mensagem inteira e indicar um erro

camada de aplicao. Aps um tempo de P2max, a ferramenta deve retransmitir a

solicitao.

43

4 Aplicao do Protocolo KW2000

Como desfecho do estudo do protocolo KW2000, foi desenvolvido um programa em

Delphi para leitura dos dados do mdulo de controle do motor de um veculo popular que

trabalha com o protocolo KW2000 como padro para troca de dados de diagnstico.

4.1 Introduo

Atravs da observao da ferramenta de diagnstico utilizada em concessionrias, foi

possvel notar que, basicamente, o mdulo de controle do motor do veculo estudado

possua as seguintes funes:

- Leitura e remoo de cdigos de falha;

- Exibio de dados;

- Tomada de Transiente;

- Teste de atuadores;

- Identificao do mdulo eletrnico;

- Exibio do estado do imobilizador;

- Verificao de sobre-giro do motor;

- Programao do VIN;

- Programao do tipo de combustvel.

Para verificar o funcionamento do protocolo no tocante troca de informaes de

diagnstico, duas das funes acima foram selecionadas para implementao de um

software em Delphi. A escolha desta linguagem baseia-se nica e exclusivamente na

afinidade do autor com esta ferramenta devido a experincias anteriores.

- Exibio de dados;

- Identificao do mdulo eletrnico;

44

Veculo

A estratgia para seleo destas duas funes baseou-se no nmero de parmetros

envolvidos em cada uma e a possibilidade de visualizao imediata da alterao dos

parmetros colhidos. No total so mais de 100 bytes de dados, sendo que 55 parmetros

que so parte destes bytes necessitam ser atualizados instantaneamente e mostrados na

tela do computador, propiciando a anlise do comportamento do veculo em funcionamento.

A seguir sero apresentados os passos executados para a concluso deste software.

4.2 Objetivo

O objetivo desta aplicao foi avaliar na prtica o comportamento de dispositivos eletrnicos

trocando informaes atravs do protocolo KW2000. Desta forma foi possvel familiarizar-

se com o protocolo, almejando a nacionalizao do desenvolvimento do software da

ferramenta de diagnstico e a criao de uma referncia sobre o assunto.

4.3 Desenvolvimento

O desenvolvimento desta aplicao foi realizado sobre a seguinte estrutura fsica:

Figura 12 - Estrutura da aplicao desenvolvida

O veculo possui vrios mdulos eletrnicos de controle. Neste trabalho o alvo o mdulo

de controle do motor localizado no compartimento do motor do veculo, cuja linha de

diagnstico est posicionada juntamente com as linhas dos demais mdulos do veculo no

Interface Eletrnica (adequao de

sinais)

PC executando interface

programada em Delphi.

KWP2000 KWP2000

45

conector de diagnstico que pode ser encontrado ao lado da caixa principal de fusveis,

conforme apresentado na figura abaixo.

Figura 13 - Conector de diagnstico

Com esta estrutura definida, foram realizados testes de navegao com a ferramenta de

diagnstico dedicada, utilizada por toda a rede de concessionrias de uma das maiores

montadoras do pas. Estes testes tiveram por finalidade a verificao do funcionamento da

ferramenta existente, bem como a visualizao dos parmetros relacionados ao motor do

veculo.

A partir destes testes, foi desenvolvida a interface em Delphi, conforme segue:

4.3.1 Taxa de transferncia e nveis dos sinais eltricos

Como um dos tpicos relacionados na introduo deste trabalho, estudou-se a

compatibilidade dos nveis de sinais da porta serial do computador com os nveis de sinais

do mdulo de controle do motor, bem como a taxa de transferncia exigida pelo mdulo

(10400 bps enquadrando-se no padro ditado pelo protocolo quando se utiliza inicializao

Fast), que uma taxa fora dos padres. Inicialmente cogitou-se a implementao de uma

interface eletrnica com microcontrolador para adequar os sinais e atingir a taxa de

46

transferncia exigida. Porm, em consulta a profissionais que trabalham diretamente com

programas de desenvolvimento de calibraes de mdulos de controle de motores, foi

possvel notar a utilizao de uma interface simples, confeccionada com transistores para

adequao dos nveis de sinais.

Uma vez descoberta a interface, a taxa de transferncia foi alterada para 10400 bps atravs

das configuraes do Delphi, sendo possvel notar que o mdulo de controle do motor

respondia positivamente aos comandos enviados.

4.3.2 Intervalos de tempo

Relembrando o embasamento terico deste trabalho, para a inicializao Fast (que foi a

escolhida para esta aplicao) o ciclo de Wake-up deve respeitar o seguinte formato:

Figura 14 - Ciclo Wake-up

Embora o Delphi apresente temporizadores com base de contagem de 1 ms, notou-se,

atravs da utilizao de um osciloscpio, que tais temporizadores na verdade possuem suas

bases de tempo limitadas a 10 ms. Isto caracterizou um grande problema, uma vez que o

ciclo de Wake-Up, exigido pelo protocolo, fora dois intervalos de 25 ms antes do envio de

qualquer mensagem de solicitao de servio. Como soluo, recorreu-se aos parmetros

do Microsoft Windows para contagem do tempo exato.

Trep

25 ms

50 ms

P2

StartCommunication Request

StartCommunication Response

47

4.3.3 Desenvolvimento do Software

Seguindo a idia de implementao das funes de Exibio de dados e Identificao do

mdulo eletrnico, levantou-se quais os servios que deveriam ser executados para

solicitao destas informaes ao mdulo de controle do motor. So eles:

- StartCommunication;

- ReadEcuIdentification;

- ReadDataByLocalIdentifier

Atravs do software de Engenharia Carta, foi possvel ler os dados trocados entre o

notebook e o mdulo de controle do motor do veculo avaliado. Este software foi escolhido

devido sua disponibilidade, praticidade da execuo das conexes eltricas para seu

correto funcionamento bem como a clareza com que os dados trocados so exibidos no

mesmo. Para o servio StartCommunication, tivemos a seguinte leitura:

STC StartCommunication :

1, 49.576, --> With address info, physical addressing

2, 5.277, --> target address: 11h

3, 5.181, --> source address: F1h

4, 5.181, --> sid: 81h

5, 5.181, --> calculated checksum: 04h

Os valores acima representam os 5 bytes enviados atravs da porta serial pelo software

desenvolvido. O significado de cada valor apresentado pode ser explicado da seguinte

forma:

Primeira Coluna: Seqncia de acontecimentos. O nmero 1 representa o primeiro byte

enviado, o nmero dois o segundo e assim por diante;

Segunda Coluna: Intervalo de tempo (em ms) entre os bytes. O primeiro valor (49,576 ms)

significa que o primeiro byte (Format Byte) foi enviado 49,576 ms aps a primeira atuao

da porta serial, o que respeita o ciclo total de Wake-up que padronizado como 50 ms ( 1).

48

O segundo valor (5,277 ms) mostra que o Target Byte foi enviado 5,277 ms aps o Format

Byte, o que comprova a observao do intervalo de tempo P4 entre os bytes da mesma

mensagem, que padronizado no intervalo de 5 a 20 ms. Da mesma forma temos os bytes

3, 4 e 5 respeitando os intervalos exigidos pelo protocolo KW2000.

Terceira Coluna: Valor em hexadecimal do byte enviado pelo notebook para o mdulo. O

primeiro byte (Format Byte) possui o valor 81h, que em binrio representa 10000001, cujo

significado pode ser detalhado recorrendo-se ao conceito do Format Byte (Tabela 1), ou

seja:

Format Byte:

Substituindo:

Portanto:

A1 e A0 valem respectivamente 1 e 0. Recorrendo-se Tabela 1, isto caracteriza Com

informao fsica de endereamento, ou seja, os bytes de origem e destino contm

endereamentos fsicos.

L5, L4, L3, L2, L1 e L0 valem respectivamente 0, 0, 0, 0, 0 e 1. Na Tabela 2, vemos que

quando estes bits no esto zerados, eles representam a quantidade de bytes de dados

(incluindo o SId), no sendo necessrio utilizar o byte de tamanho adicional (Additional

Length Byte). Assim, significa que existe apenas um byte de dados: o SId.

Em seguida h a presena do Target Byte, que representa o endereo fsico do mdulo de

controle do motor (11h). Aps ele o Source Byte, apresentando o endereo fsico da

ferramenta de diagnstico (no caso o notebook F1h). Em seguida encontra-se o Service

Identification (SId) que vale 81h, valor este correspondente ao servio StartCommunication

A1 A0 L5 L4 L3 L2 L1 L0

7 6 5 4 3 2 1 0

1 0 0 0 0 0 0 1

7 6 5 4 3 2 1 0

49

(vide Tabela 10). E por fim o Checksum que representa a soma simples de todos os bytes

enviados (excluindo o prprio Checksum) nesta mensagem, limitado a 2 algarismos em

hexadecimal:

81h + 11h + F1h + 81h = 204h, logo o Checksum vale 04h.

Como resposta do mdulo, colheu-se os seguintes dados:

STCPR StartCommunication Positive Response :


7, 0.093, --> target address: F1h

8, 0.094, --> source address: 11h

9, 0.093, --> sid: C1h

10, 0.093, --> Keybyte 1: EFh

11, 0.093, --> Keybyte 2: 8Fh

12, 0.093, --> calculated checksum: C4h

Mais uma vez foi possvel notar o cumprimento dos intervalos de tempo exigidos pelo

protocolo KW2000. O primeiro valor (32,935 ms) representa P2 (limitado entre 25 e 50 ms

vide Tabela 3). Os demais (por volta de 0,093 ms) representam P1 (limitado entre 0 e 20

ms vide Tabela 3).

Quanto aos valores:

- o byte de formato recebido foi 83h, que significa endereamento fsico com 3 bytes de

dados;

- Objetivo igual a F1h, que o endereo do notebook;

- Fonte igual a 11h, que representa o endereo do mdulo que est respondendo;

- Service Identifier igual a C1h, que caracteriza resposta positiva solicitao de incio de

comunicao (StartCommunication vide Tabela 11);

- Key Byte 1 igual a EFh e Key Byte 2 igual a 8Fh, que representa, segundo a Tabela 7:

- Tamanho da Informao suportado: Format Byte e Additional Length Byte (Ambos

os modos);

- Tipo de cabealho suportado: Com e sem informao de endereo (Ambos os

tipos);

- Intervalo: Normal.

- Checksum: 83h + F1h + 11h + C1h + EFh + 8Fh = 3C4h, portanto igual a C4h.

50

Estabelecida a comunicao, enviou-se o servio desejado para leitura dos dados do motor

do veculo (ReadDataByLocalIdentifier) e da identificao do mdulo de controle do motor

(ReadEcuIdentification).

Para executar a leitura dos dados do motor, o software desenvolvido enviou a seguinte

seqncia de bytes:

RDBLI ReadDataByLocalIdentifier :




16, 5.180, --> length byte: 02h

17, 5.181, --> sid: 21h

18, 5.181, ...

19, 5.180, --> calculated checksum: A6h

Neste caso, para verificar a aplicao do byte de tamanho adicional (Additional Length

Byte), o byte de formato foi enviado com apenas informaes sobre o tipo de

endereamento, sendo a quantidade de bytes de dados informada pelo Additional Length

Byte.

Os bytes significam:

- Byte de formato igual a 80h, que indica endereamento fsico. Agora foi a vez do intervalo

P3 ser respeitado (variao permitida entre 55 e 5000 ms) conforme representado na figura

6;

- Objetivo igual a 11h, que o endereo do mdulo controlador;

- Fonte igual a F1h, que representa o endereo do notebook;

- Byte de tamanho adicional igual a 02h, que indica que a mensagem de dados ter 2 bytes.

- SId igual a 21h, que indica o servio solicitado (ReadDataByLocalIdentifier conforme

ISO14230-3);

- Primeiro e nico byte de mensagem igual a 01h. Este byte exigido pelo servio

ReadDataByLocalIdentifier denominado RecordLocalIdentifier (segundo ISO14230-3).

Seu contedo no especificado por norma e sim por cada montadora.

- Soma para Checksum igual a 1A6h, portanto Checksum igual a A6h.

51

Como resposta do mdulo encontrou-se:

RDBLIPR - ReadDataByLocalIdentifier Positive Response :




23, 0.093, --> length byte: 60h

24, 0.093, --> sid: 61h

25, 0.093, ...

26, 0.093, ...

27, 0.093, ...

28, 0.093, ...

29, 0.093,

30, 0.093, ...

31, 0.093, ...

32, 0.093, ...

33, 0.093, ...

34, 0.093, ...

35, 0.093, ...

36, 0.093, ...

37, 0.093, ...

38, 0.093, ...

39, 0.093, ...

40, 0.093, ...

41, 0.093, ...

42, 0.093, ...

43, 0.093, ...

44, 0.093, ...

45, 0.092, ...

46, 0.093, !

47, 0.093, ...

48, 0.093, ...

49, 0.093, ...

50, 0.093, ...

51, 0.093, ...

52, 0.092, ...

52

53, 0.093, ...

54, 0.093, ...

55, 0.093, ...

56, 0.093, ...

57, 0.093, t

58, 0.093, ...

59, 0.093, ...

60, 0.093, g

61, 0.093, ...

62, 0.093, ...

63, 0.093,

64, 0.093, j

65, 0.093, A

66, 0.093, ...

67, 0.093, B

68, 0.092, ...

69, 0.093, ...

70, 0.093, ...

71, 0.093, ...

72, 0.093, ...

73, 0.093, \

74, 0.093, ...

75, 0.093, ...

76, 0.093, ...

77, 0.093, ...

78, 0.093, ...

79, 0.093, ...

70, 0.093, ...

81, 0.093, ...

82, 0.093, ...

83, 0.093, ...

84, 0.093, ...

85, 0.093, ...

86, 0.093, ...

87, 0.093, ...

88, 0.093, ...

89, 0.093, 3

53

90, 0.093, Z

91, 0.093, C

92, 0.093, ...

93, 0.092, 3

94, 0.093,

95, 0.093, ...

96, 0.093, 2

97, 0.093, ...

98, 0.093, ...

99, 0.093, ...

100, 0.093, ...

101, 0.093, ...

102, 0.093, ...

103, 0.093, ...

104, 0.093, ...

105, 0.093, ...

106, 0.093, Q

107, 0.093, Q

108, 0.093,

109, 0.093, ...

110, 0.093, d

111, 0.092, ...

112, 0.093, ...

113, 0.093, ...

114, 0.093, i

115, 0.093, ...

116, 0.093, ...

117, 0.092,

118, 0.093, b

119, 0.093, ...

120, 0.093, --> calculated checksum: 48h

Os bytes representam:

- Byte de formato igual a 80h, indicando endereamento fsico e necessidade da utilizao

do byte de tamanho adicional (conforma descrito na Tabela 2);

- Objetivo igual a F1h, que o endereo estipulado para o notebook;

54


- Byte de tamanho adicional igual a 60h, indicando 96 bytes de dados incluindo o SId;

- SId igual a 61h, indicando resposta positiva do mdulo frente a solicitao

ReadDataByLocalIdentifier (conforme ISO14230-3);

- Bytes de nmero 25 a 119 representam toda a informao dos dados do motor que esto

disponveis neste servio. Itens como rotao do motor, temperatura do lquido de

arrefecimento, posio da borboleta de acelerao, quantidade de combustvel no tanque,

etc. esto neste pacote enviado ao notebook pelo mdulo;

- Checksum calculado igual a 48h.

Desta forma, aplicando-se as equaes necessrias sobre cada byte recebido (conforme

especificao tcnica do mdulo), foi possvel mostrar na tela do notebook os mesmos

dados do motor estudado, lidos atravs da ferramenta de diagnstico nas concessionrias e

oficinas. Esta tela apresentada abaixo:

Figura 15 - Tela de leitura dos dados do motor

Com os dados do motor lidos corretamente, aplicou-se o servio ReadEcuIdentification

para captar os dados referentes identificao do mdulo de controle.

55

Para solicitar este servio, os seguintes bytes foram enviados atravs do software

desenvolvido:

REI - ReadEcuIdentification :




124, 5.181, --> length byte: 02h

125, 5.181, --> sid: 1Ah

126, 5.181, --> IDOPT = 80h reportECUIdentificationDataTable

127, 5.181, --> calculated checksum: 1Eh

Mais uma vez foi utilizado o byte de tamanho adicional para indicar a quantidade de bytes

na mensagem enviada.

A seguir o significado dos bytes:

- Byte de formato igual a 80h, indicando endereamento fsico e o uso do byte de tamanho

adicional;

- Objetivo igual a 11h, que o endereo do mdulo controlador;

- Fonte igual a F1h, que representa o endereo do notebook;

- Byte de Tamanho adicional igual a 02h, indicando a existncia de apenas 2 bytes na

mensagem de dados;

- SId igual a 1Ah, que representa o servio solicitado (ReadEcuIdentification) conforme a

ISO14230-3;

- Primeiro e nico byte de mensagem igual a 80h. Este byte parte integrante do processo

de solicitao do servio ReadEcuIdentification e chamado de IdentificationOption,

sendo seu contedo especificado pela montadora;

- Checksum calculado igual a 1Eh.

Como resposta do mdulo:

REIPR - ReadEcuIdentification Positive Response :



56


131, 0.093, --> length byte: 58h

132, 0.093, --> sid: 5Ah

133, 0.093,

134, 0.093, 8

135, 0.093, B

136, 0.093, G

137, 0.093, R

138, 0.093, M

139, 0.093, 6

140, 0.093, 9

141, 0.093, 9

142, 0.093, 0

143, 0.093, 7

144, 0.093, G

145, 0.093, 1

146, 0.093, 4

147, 0.093, 1

148, 0.093, 3

149, 0.093, 2

150, 0.093, 8

151, 0.092, S

152, 0.093, 0

153, 0.093, 0

154, 0.093, 1

155, 0.093, 0

156, 0.093, 0

157, 0.093, 9

158, 0.093, 6

159, 0.093, 6

160, 0.093, 4

161, 0.093,

162, 0.093, ...

163, 0.093, ...

164, 0.093, ...

165, 0.093, D

166, 0.093, E

57

167, 0.093, L

168, 0.093,

169, 0.093,

170, 0.093, 0

171, 0.093, 1

172, 0.093, 1

173, 0.093, F

174, 0.093, 3

175, 0.093, 1

176, 0.093, 0

177, 0.092, 6

178, 0.093, 3

179, 0.093, 0

180, 0.093, 9

181, 0.093, 4

182, 0.093, 7

183, 0.093, 0

184, 0.093, 2

185, 0.093, 3

186, 0.093, 3

187, 0.093, 1

188, 0.093,

189, 0.093, Z

190, 0.093, C

191, 0.093, F

192, 0.093, F

193, 0.093, R

194, 0.093, K

195, 0.093, ...

196, 0.093, ...

197, 0.093,

198, 0.093,

199, 0.093,

200, 0.093,

201, 0.092,

202, 0.093,

203, 0.093, X

58

204, 0.093, 1

205, 0.093, 0

206, 0.093, Y

207, 0.093, F

208, 0.093, L

209, 0.093, ...

210, 0.093, ...

211, 0.093, d

212, 0.093, P

213, 0.093, B

214, 0.093, R

215, 0.093, 2

216, 0.092, 0

217, 0.093, 0

218, 0.093, 7

219, 0.093,

220, 0.093, --> calculated checksum: 4Bh

O significado de cada byte :

- Byte de tamanho igual a 80h, indicando endereamento fsico e a presena do byte de

tamanho adicional;

- Objetivo igual a F1h, que o endereo do notebook;


- Byte de tamanho adicional igual a 58h, indicando que seriam 88 bytes de dados incluindo o

SId;

- SId igual a 5Ah, caracterizando resposta positiva do mdulo frente a solicitao

ReadEcuIdentification (conforme ISO14230-3);

- Bytes de nmero 133 a 219 representam toda a informao referente identificao do

controlador que esto disponveis neste servio. Itens como nmero de identificao do

veculo (VIN), nmero do software, identificador, tipo de motor, etc. esto neste pacote

enviado pelo mdulo ao notebook. Conforme pode ser observado ao lado direito do

contedo de cada byte, os valores representam caracteres em cdigo ASCII;

- Checksum calculado igual a 4Bh.

59

Desta forma, organizando os bytes recebidos conforme especificao tcnica do mdulo, foi

possvel mostrar na tela do notebook as mesmas informaes sobre identificao do mdulo

controlador do motor, lidas atravs da ferramenta de diagnstico nas concessionrias. Esta

tela apresentada abaixo:

Figura 16 - Tela de leitura da identificao do controlador do motor

Assim, os trs servios propostos foram testados, possibilitando a leitura dos dados do

motor em tempo real e a identificao do mdulo controlador sempre que necessrio.

A seguir apresentado o fluxograma do software desenvolvido:

60

Primeiramente apresentada uma viso macro do funcionamento do software:

Incio

Usurio seleciona o tipo de informao que quer obter.

Usurio deseja sair do

programa?

Fim

Dados do motor

selecionado?

Identificao de mdulo

selecionada?

Estabelece Comunicao e envia solicitao para receber dados

referentes identificao do mdulo.

Estabelece Comunicao e envia solicitao para receber dados

referentes ao motor.

Executa leitura dos dados recebidos atravs da serial.

Executa tratamento dos dados recebidos conforme

especificao tcnica.

Apresenta os resultados na tela do computador.

Sim

No

Sim Sim

No

No

61

Agora apresentado o detalhamento da funo Estabelece Comunicao e envia

solicitao para receber dados referentes identificao do mdulo.:

Incio

Envia a seguinte seqncia na serial: - Ciclo de Wake-up; - 81h e espera 5ms; - 11h e espera 5ms; - F1h e espera 5ms; - 81h e espera 5ms;

- Checksum; (solicitao de incio de comunicao).

Recebe dados na serial

Target Byte recebido =

F1h?

Source Byte recebido =

11h?

SId recebido = C1h?

Checksum correto?

Gera mensagem de erro referente ao Target Byte

Gera mensagem de erro referente ao Source Byte

Gera mensagem de erro referente ao Sid

Gera mensagem de erro referente ao Checksum

1

Sim

Sim

Sim

Sim

No

No

No

No

62

Envia a seguinte seqncia na serial: - Ciclo de Wake-up; - 80 e espera 5ms;

- 11h e espera 5ms; - F1h e espera 5ms; - 02h e espera 5ms; - 1Ah e espera 5ms; - 80h e espera 5ms;

- Checksum; (solicitao de envio dos dados de identificao

do mdulo controlador).



F1h?


11h?

SId recebido = 5Ah?

Checksum correto?





1

Fim

Sim

Sim

Sim

Sim

No

No

No

No

63

Agora apresentado o detalhamento da funo Estabelece Comunicao e envia

solicitao para receber dados referentes ao motor.:

Incio

Envia a seguinte seqncia na serial: - Ciclo de Wake-up; - 81h e espera 5ms; - 11h e espera 5ms; - F1h e espera 5ms; - 81h e espera 5ms;

- Checksum; (solicitao de incio de comunicao).



F1h?


11h?

SId recebido = C1h?

Checksum correto?





1 2

Sim

Sim

Sim

Sim

No

No

No

No

64

Envia a seguinte seqncia na serial: - Ciclo de Wake-up; - 80 e espera 5ms;

- 11h e espera 5ms; - F1h e espera 5ms; - 02h e espera 5ms; - 21h e espera 5ms; - 01h e espera 5ms;

- Checksum; (solicitao de envio dos dados do mdulo controlador referente ao funcionamento do

motor).



F1h?


11h?

SId recebido = 61h?

Checksum correto?



Gera mensagem de erro referente

KW2000

Documents

Transcript of KW2000