UDS服务基础篇之36

前言

继小T前不久系统性的总结了一份80多页的<UDS诊断服务宝典>，获得了非常多的小伙伴的认可与支持，如何免费获取见文末说明。

今天小T跟大家介绍剩余部分在刷写过程中常用的36诊断服务。

• 你知道36服务是干什么的吗？
• 36服务是怎样的请求与诊断格式？
• 36服务在使用的过程中需要注意哪些问题？

这篇，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：

---

正文

服务功能

功能描述

根据ISO14119-1标准中所述，诊断服务36服务主要用于实现Client向Server端传输下载的数据或者Server端向Client端上传数据。

36服务的传输方向主要取决于在此之前执行的是34服务(下载传输)还是35服务（上传传输）。如果执行的是34服务，则36服务传输的数据方向则用于Client向Server端下载数据，如果是35服务则36服务的传输方向是从Server端上传数据至Client端。

一般情况下34服务与36服务进行搭配使用以完成软件下载的操作流程，对于34服务的具体介绍可参考《UDS服务基础篇之34》。

下列文中使用到的Client可直接理解为上位机Tester，Server可直接理解为接受Tester诊断请求的ECU。

应用场景

一般而言，对于36诊断服务，主要应用场景为以下场合：

• 在进行软件刷写的过程中，执行完34服务之后便会通过36服务来进行相关数据的传输以便完成软件下载流程；
• 在进行软件上传的过程中，执行完35服务之后便可以通过36服务完成数据上传的操作，实际情况下一般较为少用；

36服务控制基本原理：

如下图1所示，针对36服务的通信控制过程会经过如下几个AUTOSAR BSW模块进行处理，然后完成最终的数据传输控制，具体步骤如下：

• Client 发送诊断指令给到Server，Server接收到指令后通过确认请求block sequence，长度等信息；

• 如果相关诊断请求长度，格式，blocksequence等信息没有问题则回复正响应，否则回复负响应；

• 值得注意的是36服务没有subfunction。

图1 36服务控制流程图

服务请求

服务请求是Client发送给到Server的诊断服务指令。

请求格式

按照ISO14229-1标准所述，如下图2所示为36服务诊断请求格式，即上述36服务控制原理中诊断服务请求格式：

图2 36诊断服务请求格式

上述参数TransferData Request SID，blockSequenceCounter，transferRequestParameterRecord这几个参数较为关键，下图3中各参数解释如下：

图3 36诊断服务请求格式说明

注意事项：

• 如果发送的36诊断服务已被Server端接收并处理但是没有给到Client端正响应，那么Client一般会有超时处理然后重复上次同样的数据传输请求，此时Server端将接收同样的blockSequenceCounter但是同样会给到正响应，只不过不会往Memory中写入重复的值；
• 如果下载数据的请求未能够及时被Server端接收到， 那么Client一般会有超时处理然后重复上次的下载数据请求，Server端收到之后便会认为这是一次新的数据传输请求并给出正响应；
• 如果上传数据的传输请求已被Server端接收到并处理，但是Client端没有收到正响应，那么Client端一般会有超时处理然后重复上次同样的数据传输请求，Server端仍然会继续处理并最终回复正响应；
• 如果上传数据的传输请求未能够被Server端接收到，Server端将不会发送正响应。Client端一般会有超时处理然后重复同样的传输请求，Server端收到后便会继续处理并给出正响应。

请求实例

以如下请求下载请求为例，给大家讲解下下载请求的诊断服务如何组成与发送：

• TransferData Request SID= 0x36， 表示数据传输的Service ID；
• blockSequenceCounter ==0x1，表示这是第一次Block传输；
• transferRequestParameterRecord 表示传输下载的请求数据；

图4 36服务下载请求实例

注意事项：如果是36服务的上传服务，那么transferRequestParameterRecord的值一般为空。

服务响应

服务响应是针对Client对Server诊断请求的响应。

正响应格式

如下图5所示，为36诊断服务的正响应格式：

图5 36诊断服务正响应格式

从上图中可以看出，36诊断服务的正响应由以下三个部分组成：

• TransferData Response SID：表示36服务对应的诊断服务ID，即为0x36+0x40 = 0x76；
• blockSequenceCounter：表示36服务下载的block ID编号，默认是从01开始，取决于36诊断请求中的block ID数值；
• transferResponseParameterRecord：如果是下载服务，那么一般回复的值为Server端接收Client数据的CRC结果或者没有值，不应该与下载请求的数据内容一样，如果是上传服务，那么这部分就是表示待上传至Client端的数据。

正响应实例

如下图6所示，为上述请求下载示例图4所对应的正响应：

• TransferData Response SID：该值为0x76,表示36服务的正响应；
• blockSequenceCounter：该值设定为0x01，与36服务的发送请求一致；

图6 36服务正响应示例

注意事项：对于下载服务，36服务的正响应一般不会包含transferResponseParameterRecord这个参数，但如果是上传服务，那么此时transferResponseParameterRecord就会表示待上传的值。

负响应NRC支持

绝大多数情况下，Server针对Client的请求都会给到正响应，比如发生重启前需确保整车处于安全状态，如引擎熄火，车速不能超过3km/h等，或者为了防止不按照诊断请求格式进行请求，那么Server需要通过某种方式来告诉Client执行不成功的原因在哪里以便于调查问题直至得到正响应。

因此ISO14229-1针对所有的诊断服务提供了一种统一的诊断负响应的诊断格式：7F +SID + NRC。

其中NRC全称为Negetive Responce Code，每个NRC具有唯一的含义来代表当前诊断请求错误的原因所在。当然每个诊断服务支持的NRC不尽相同，具体支持的NRC需要参考ISO14229-1标准文档，对于36服务而言支持的NRC如下图：

图7 36服务NRC支持

• 当发送报文长度或者格式不对时，则Server会回复"7F 36 13"；
• 例如当下载过程发送的Block Sequence Number不连续或者不正确时，Server将会回复“7F 36 24”来告诉请求者检查Block Sequence Counter；
• 当transferRequestParameterRecord包含无效的信息或者传输的Block数目超过34或者35服务的传输请求时规定大小时，则Server会回复**“7F 36 31”**；
• 当传输的数据大小与请求下载服务的Memory Size不一致时，则Server会回复**“7F 36 71”**;
• 当在传输下载数据的过程中出现的Flash相关错误，则Server会回复“7F 36 72”;
• 当在传输过程中如果出现Block Sequence Counter不一致或者不连续的情况，则Server会回复“7F 36 73”，，值得注意的时如果时相同的block sequence counter则是被允许的;
• 如果在下载过程中出现电压过高或者过低时，那么Server会回复“7F 36 92/93, 当然前提是要有ADC检查”;

上述NRC也存在对应的优先级，因此小T将对应的36服务NRC优先级展示如下图8所示：

更多精彩内容，欢迎大家多多关注公众号“ADAS与ECU之吾见”！！！
如需获取UDS学习宝典，公众号后台回复“UDS宝典”关键词即可获取高清原文。