I. Visão geral
Os serviços definidos pelo UDS estão logicamente divididos em 6 categorias. No artigo anterior, interpretou-se a categoria de diagnóstico e gestão de comunicações, "categoria de transmissão de dados" e "transmissão de dados de armazenamento".
2. Conteúdo do serviço de diagnóstico
O serviços de controle
1. InputOutputControlByIdentifier (0x2F)
$ 2F é um serviço que usa ID para controlar a entrada e saída de ECU e é frequentemente usado na linha de produção para verificar a função das peças. Por exemplo, na fase final de montagem, os trabalhadores precisam verificar se as várias funções do carro estão normais, como se os quatro vidros sobem e descem normalmente. Se eles pressionarem os interruptores um a um, a eficiência é muito baixa.
Por exemplo, se a ECU recebe um sinal de entrada A, podemos usar 2F para atribuir um valor que precisamos a este A; se a ECU controla um atuador B, podemos usar o serviço 2F e adicionar alguns parâmetros específicos para realizar o controle de B, como controle de porta para controlar o levantamento da janela, rebatimento do espelho retrovisor, etc.
A solicitação de serviço de $ 2F consiste em 4 partes
O primeiro byte: SID=0x2F
O segundo e terceiro bytes: dataIdentifier (2 bytes), usado para identificar o objeto IO controlado, por exemplo, o seguinte exemplo 0x9B00 (posição da porta de entrada)
O quarto byte: controlOptionRecord, usado para identificar o tipo de controle, e vários bytes de controlState usados pelo fabricante. O UDS define claramente quatro tipos de controle
0x00 Retorna o controle para a ECU, ou seja, finaliza o controle
0x01 Defina o sinal de entrada, parâmetros internos, sinal de saída, etc. do objeto identificado por DID para o valor padrão
0x02 Congela o sinal de entrada, parâmetros internos, sinal de saída, etc. do objeto identificado por DID
0x03 A configuração do sinal de entrada, parâmetros internos e sinal de saída do objeto identificado pelo DID equivale a iniciar o controle da ECU, este tipo de controle será seguido do quinto byte, que pode representar o valor digital ou analógico do objeto de controle.
por exemplo:
Use 2F para controlar a posição da porta de entrada de ar (posição da porta de entrada de ar) e use DID (identificador) = 0x9B00 para identificar a posição da porta de entrada de ar.
Posição da Porta de Entrada de Ar [%] = decimal(Hex) * 1 [%] , ou seja, use uma porcentagem para representar esta posição.
passo 1:
O testador envia 22 9B 00 para ler a posição atual da porta de entrada de ar, onde 22 é o SID e 0x9B00 é o segundo e o terceiro byte DID.
ECU retorna 62 9B 00 0A, onde 0x0A = 10 (dec), o que significa que a posição atual é 10%
(UDS define que o dataIdentifier usado no serviço 2F pode ser lido pelo serviço 22 e o valor de retorno é a informação de status. A informação de status específica é definida pelo usuário.)
passo 2:
O testador envia 2F 9B 00 03 3C , que significa ajustar a posição da porta de entrada de ar para 60%, e 0x3C = 60 (dec) significa definir o valor analógico do objeto de controle para 60%.
A ECU retorna 6F 9B 00 03 0C, indicando que o controle foi aceito e a posição atual da porta de entrada de ar é de 12%. Porque a ECU responde imediatamente após receber o pedido, e o ajuste da posição da porta demora, então não chegou a 60%.
etapa 3:
Depois de um tempo, o testador envia 22 9B 00 para ler a posição atual da porta de entrada de ar
ECU retorna 62 9B 00 3C , 0x3C = 60 (dec), indicando que a posição atual atingiu 60%
Passo 4:
testador envia 2F 9B 00 00 para retornar o controle para ECU
ECU retorna 6F 9B 00 00 3A, indicando que a solicitação foi aceita e a posição atual é de 58%
passo 5:
O testador envia 2F 9B 00 02 para congelar o estado da posição da porta de entrada de ar representada pelo ID 9B 00
A ECU retorna 6F 9B 00 02 32, indicando que a solicitação foi aceita e a posição atual permanece em 50%
Além disso, há um problema com o serviço 2F (citado do autor de Zhihu "The Flower of the Soul"). Se um determinado valor for modificado por meio do serviço 2F e o controle não for devolvido à ECU, o tempo efetivo dessa modificação continuará? A maneira correta é voltar para a sessão padrão se a sessão estendida expirar. Neste momento, o direito de controle deve ser devolvido à ECU. Afinal, a subfunção 03 de 2F está "assumindo temporariamente o direito de controle".
serviço de controle de rotina
Controle de Rotina (0x31)
O serviço $31 é uma interface para chamar algumas sequências de operação embutidas na ECU. A aplicação deste serviço é muito flexível, pois os fabricantes podem definir diversas operações internas para a ECU de acordo com suas próprias necessidades, e para executar essas operações, basta chamar o serviço 31. Os usos típicos incluem verificar as condições de limite, limpar a memória flash, verificar os dados, verificar as dependências de software e hardware, etc., e até mesmo restaurar as configurações de fábrica, se necessário, e muitas operações relacionadas às próprias funções lógicas da ECU também podem ser definidas.
31 solicitação de serviço consiste em 4 partes
SID=0x31
subfunção, subfunção, iniciar (0x01), parar (0x02), resultado da consulta (0x03)
rotinaIdentifier, o ID da tarefa, usado para identificar a rotina a ser executada
rotinaControlOptionRecord, este é um parâmetro opcional, que serve para identificar os parâmetros necessários para a execução da rotina, podendo cada empresa customizar seu conteúdo
por exemplo:
Suponha que o ID 0x0809 seja usado para representar a rotina que verifica se a ECU atende às condições de flash do software (como a velocidade do veículo e a velocidade de rotação são 0, KL15 está ligado, etc.).
O testador envia 31 01 08 09 para iniciar a rotina 0x0809
Se todas as condições forem atendidas, a ECU retorna 71 01 08 09 como eco. Se as condições não forem atendidas, a ECU retorna 71 01 08 09 XX YY ZZ, e o seguinte XX YY ZZ indica quais condições não foram atendidas e o conteúdo específico é definido pelo fabricante.
Serviços de upload e download
A transmissão dos dados de atualização da ECU é concluída por meio de serviços como 34 (solicitação de download), 36 (transmissão de dados), 37 (solicitação de encerramento da transmissão). Como o tamanho do buffer usado para armazenar em cache os dados do serviço de diagnóstico na ECU automotiva é limitado, quando precisamos ler ou gravar dados que excedam o tamanho do buffer, não podemos simplesmente usar os serviços 2E e 22. Portanto, o UDS define vários serviços que gravam ou leem grandes blocos de dados, ou seja, download e upload de dados.
A unidade funcional Upload Download define um total de 5 serviços de diagnóstico, nomeadamente:
RequestDownload (0x34): O instrumento de diagnóstico solicita que a ECU baixe os dados
RequestUpload (0x35) O instrumento de diagnóstico solicita que a ECU carregue os dados
TransferData (0x36) O instrumento de diagnóstico transmite dados para a ECU (download) ou o servidor transmite dados para o cliente (upload)
RequestTransferExit (0x37) Transferência de dados concluída, solicitação para sair
RequestFileTransfer (0x38) A operação de transferência de arquivos pode ser usada para substituir os serviços de upload e download.
A figura abaixo mostra o processo simplificado de download de dados, são utilizados os três serviços 34, 36 e 37. Se for upload, o serviço 34 é substituído pelo serviço 35, e o sentido de transmissão dos dados é alterado.
passo 1:
O instrumento de diagnóstico transmite o endereço inicial do bloco e as informações de comprimento de dados do bloco por meio de 34 serviços: solicitação de download;
Depois que a ECU recebe a solicitação de download do serviço 34, ela notifica o instrumento de diagnóstico por meio de uma mensagem de resposta positiva 74, quantos bytes de dados devem ser incluídos em cada próxima mensagem de transmissão de dados (serviço 36) do (instrumento de diagnóstico). O instrumento de diagnóstico ajusta sua própria capacidade de envio de acordo com os parâmetros retornados;
passo 2:
O instrumento de diagnóstico transmite os dados deste bloco através de 36 serviços, e a quantidade de dados transmitidos por cada 36 serviços é determinada pelos parâmetros nos 34 serviços (ou seja, SID=0x74) retornados pela ECU, veja abaixo para detalhes.
A ECU retorna uma resposta positiva ao serviço 36;
Os dados são divididos e enviados sequencialmente por 36 serviços, e a ECU responde com uma resposta afirmativa toda vez que o envio de 36 serviços é concluído. Até que o bloco de dados seja todo enviado;
etapa 3:
O instrumento de diagnóstico executa uma solicitação de saída de transmissão enviando 37 serviços;
A ECU faz uma resposta de resposta positiva.
A descrição de cada serviço é a seguinte:
A descrição de cada serviço é a seguinte:
PedidoDownload （0x34）：
O serviço 0x34 é usado para iniciar a transmissão do download, e sua função é informar a ECU que está pronta para aceitar dados, e a ECU informa ao instrumento de diagnóstico se permite a transmissão e quanto pode aceitar através da resposta 0x74.
O formato de solicitação do serviço 0x34 inclui 5 partes
A primeira parte: 1 byte SID=0x34
A segunda parte: dataFormatIdentifier de 1 byte, usado para indicar o método de compactação e criptografia de dados. Entre eles, os bits 7-4 definem o método de compressão; os bits 3-0 definem o método de criptografia. Quando o byte é 0x00, significa que nem o método de compactação nem o método de criptografia são usados. As definições de outros valores diferentes de 0x00 são estipuladas pelas próprias montadoras.
A terceira parte: addressAndLengthFormatIdentifier de 1 byte, que é usado para indicar o número de bytes ocupados pelas duas últimas partes. Neste exemplo, defino esses dois valores para n e m, respectivamente.
A quarta parte: memoryAddress de m bytes, indicado pelos 4 bits inferiores em addressAndLengthFormatIdentifier. O significado é escrever o endereço lógico dos dados na ECU.
A quinta parte: o memorySize de n bytes, indicado pelos 4 bits altos em addressAndLengthFormatIdentifier. O significado é o número de bytes de dados a serem gravados.
Após a ECU receber a solicitação, se a transmissão for permitida, ela dará a seguinte resposta
A primeira parte: 1 byte Response SID=0x74
A segunda parte: 1 byte dataFormatIdentifier como echo
A terceira parte: maxNumberOfBlockLength, o comprimento é variável, indicando a quantidade máxima de dados que podem ser transmitidos de uma só vez através do serviço 0x36.
TransferData（0x36）：
Se o serviço 34 obtiver uma resposta correta, o testador iniciará o processo de transmissão de dados e o serviço 36 será usado. 36 O formato do serviço é o seguinte.
A primeira parte: 1 byte SID=0x36.
A segunda parte: blockSequenceCounter de 1 byte, que identifica o número de blocos de dados que estão sendo transmitidos no momento, ou seja, o número do quadro, ou simplesmente, o número de vezes que o serviço 36 é chamado.
A terceira parte: transferRequestParameterRecord, os dados transferidos. O limite superior da quantidade de dados transmitidos pela primeira vez é o maxNumberOfBlockLength na resposta de serviço 34.
Exemplo: Se a ECU informa ao testador que maxNumberOfBlockLength = 20 (eco do serviço $34), ou seja, o testador só pode enviar no máximo 20 bytes de cada vez pelo serviço 36, incluindo SID e blockSequenceCounter, então, na verdade, a informação de dados que pode ser transmitida a cada vez é de apenas 18 bytes. Se o dado a ser transmitido pelo testador for de 50 bytes, ele precisa ser transmitido três vezes, cada vez transmitindo 18, 18 e 14 bytes respectivamente, ou seja, chamando 36 serviços três vezes.
A resposta de 36 é bem simples, ou seja, um byte de Response SID mais um byte de blockSequenceCounter como echo.
RequestTransferExit（0x37）：
O serviço de $ 37 é usado para interromper o upload e o download. Se os serviços anteriores 34 e 36 forem executados com sucesso, o serviço 37 poderá obter uma resposta positiva da ECU.
O formato é muito simples, a solicitação é 37 e a resposta correta é 77, ambas com um byte.
Se os 36 serviços anteriores não forem executados, veja o exemplo que dei anteriormente, por exemplo, o bloco de dados tem 50 bytes, mas o testador só envia os 36 serviços duas vezes e 36 bytes, então essa transmissão é uma falha para a ECU, então a ECU deve dar NRC 0x7F 37 24, indicando que há um erro na execução da sequência de diagnóstico.
3. Equipamento de aplicação UDS
Entre os produtos de diagnóstico UDS, o cartão CAN mais conhecido e amplamente utilizado VN1630/1640 da German Vector Company, juntamente com seu software CANoe, os produtos Vector têm funções completas e são adequados para o desenvolvimento de ônibus automotivos em nível de sistema e são adotados pela maioria dos fabricantes de automóveis. Normalmente, os engenheiros primeiro usam o CANdela da Vector para desenvolver o arquivo cdd e, em seguida, importam o arquivo cdd para o CANoe.diva para testes funcionais. O link abaixo é um conjunto completo de soluções fornecidas pela Vector, e o CANdesc é um software de geração de código UDS.
Os produtos Vector são fáceis de usar, economizam tempo de desenvolvimento, não abrem API e são caros, portanto, não são adequados para testes automatizados de equipes de desenvolvimento de hardware e linhas de produção. Atualmente, existem muitos fabricantes de CAN no mercado (como Kvaser, ZLG, etc.) que podem fornecer dispositivos com baixo custo, tamanho pequeno, driver simples e API aberta, que são muito adequados para desenvolvimento secundário.
- resumo
Até agora, a atualização do protocolo de diagnóstico UDS foi concluída. O protocolo UDS é obscuro e complicado e requer experiência real para aprofundar a memória e aprofundar a compreensão durante o uso. Bem-vindo a se comunicar a qualquer momento.