UDS服务基础篇之2E

UDS诊断服务基础篇之2E

前言

2E服务作为诊断服务中的基础服务，可以简单理解为就是一个用于写入ECU数据的外部接口，可实时获取软件内部的相关的状态信息。

鉴于本文是基础入门介绍，小T还是会问下大家有关2E诊断服务的相关问题？

• 2E服务的实际用途是什么？
• 2E服务的应用场景有哪些呢？
• 2E服务的诊断服务格式如何？

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

正文

服务功能

功能描述

根据ISO14119-1标准中所述，诊断服务2E主要用于Client向Server(ECU)通过DID的方式写入相关的数据。

应用场景

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

• 在整车下线的过程中写入相关配置信息，如常见的VIN码;
• 清除NVM；
• 重置已写入到Flash中的数据；
• 其他需要写入内部相关参数的场合；

上述这些应用场景较为常见，除此以外，当然还有很多面向ECU内部测试的应用场合，这里就不一一列举。

服务请求

服务请求是Client发送给到Server的诊断服务指令。其中Client可以理解为Tester，Server可以理解为ECU节点。

请求格式

按照ISO14229-1标准所述，如下图1所示：

下图2中各参数解释如下：

常见DID总结

根据ISO14229-1规范，定义了诸多只能用于特定场合的DID，也就意味着大家都不能随意乱用DID，在使用DID Number应充分考虑到14229的要求，防止出现跟客户扯皮的现象。

如下图3所示简要列举了较为常见的DID种类及其含义：

请求实例

以写入DID F1 90 （VIN码）为例，其对应的诊断请求实例如下图4所示：

服务响应

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

正响应格式

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

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

• Response ID：该参数固定为SID+0x40 = 0x6E；
• DID：该参数表示某个数据的标识符，回复的DID应与诊断请求的DID保持一致；

正响应实例

如下图7所示，为上述DID(F1 90)请求示例所对应的正响应：

注意：对应2E服务回复正响应时一般应确保此时数据已经被成功写入到NVM中，当然如果是KL30供电也可采取下电保存机制，但是前提需走正常下电休眠流程或者执行1101复位动作。

负响应NRC

NRC Code

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

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

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

• 例如当尝试写入F190的DID值且当前车速条件不满足，此时Client发送诊断指令"2E F1 90"请求Server读取数据，Server将会回复“7F 2E 22”来告诉请求者当前读取数据的条件不满足，请再次检查读取该DID的条件。
• 当发送报文长度或者格式不对时，则Server会回复"7F 2E 13"；
• 当诊断请求DID不存在或者在当前Session中不支持时，则Server就会回复“7F 2E 31”；
• 当Server在发生复位前处于security lock状态，那么此时Server则会回复"7F 2E 33"；
• 当2E服务写入的内存地址错误时，那么此时Server则会回复"**7F 2E 72 **"；

NRC优先级

当诊断请求存在多种条件不满足的情况下，那么哪个NRC应当回复呢？毫无疑问此时就需要引入NRC优先级的概念，以下就是诊断服务2E的NRC优先级，供诸君参考：

更多精彩内容，敬请关注公众号“ADAS与ECU之吾见！”