kw2000
DESCRIPTION
programador ecuTRANSCRIPT
-
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
APLICAO DO PROTOCOLO KW2000 PARA LEITURA DE DADOS DISPONVEIS NO MDULO DE CONTROLE DO
MOTOR DE UM VECULO POPULAR
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
APLICAO DO PROTOCOLO KW2000 PARA LEITURA DE DADOS DISPONVEIS NO MDULO DE CONTROLE DO
MOTOR DE UM VECULO POPULAR
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.1 Definio do Servio .................................................................................33
3.3.3.2 Tabela de Servio .....................................................................................33
-
3.3.3.3 Procedimento de Servio ..........................................................................34
3.3.3.4 Implementao..........................................................................................34
3.3.4 Servio AccessTimingParameter ...................................................................35
3.3.4.1 Definio do Servio .................................................................................35
3.3.4.2 Tabela de Servio .....................................................................................35
3.3.4.3 Procedimento de Servio ..........................................................................36
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
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 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
3.3.3.1 Definio do Servio
A funo deste servio finalizar a comunicao de diagnstico.
3.3.3.2 Tabela de Servio
Parmetro Classificao
StopCommunication Request M
StopCommunication Positive Response S
StopCommunication Negative Response S
Cdigo de Resposta M
Tabela 13 - Servio StopCommunication
-
34
3.3.3.3 Procedimento de Servio
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.
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 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
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 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
3.3.4.1 Definio do Servio
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.
3.3.4.2 Tabela de Servio
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
3.3.4.3 Procedimento de Servio
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
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 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
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 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.
3.3.5.2 Tabela de Servio
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 :
6, 32.935, --> With address info, physical addressing
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 :
13, 56.577, --> With address info, physical addressing
14, 5.181, --> target address: 11h
15, 5.181, --> source address: F1h
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 :
20, 37.878, --> With address info, physical addressing
21, 0.092, --> target address: F1h
22, 0.093, --> source address: 11h
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
- Fonte igual a 11h, que representa o endereo do mdulo que est respondendo;
- 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 :
121, 55.879, --> With address info, physical addressing
122, 5.182, --> target address: 11h
123, 5.277, --> source address: F1h
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 :
128, 31.856, --> With address info, physical addressing
129, 0.093, --> target address: F1h
-
56
130, 0.093, --> source address: 11h
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;
- Fonte igual a 11h, que representa o endereo do mdulo que est respondendo;
- 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).
Recebe dados na serial
Target Byte recebido =
F1h?
Source Byte recebido =
11h?
SId recebido = 5Ah?
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
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).
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 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).
Recebe dados na serial
Target Byte recebido =
F1h?
Source Byte recebido =
11h?
SId recebido = 61h?
Checksum correto?
Gera mensagem de erro referente ao Target Byte
Gera mensagem de erro referente ao Source Byte
Gera mensagem de erro referente