前言

• 你知道如果系统产生了DTC，应当如何清除呢？
• 14服务具体的执行流程如何？
• 14服务在使用过程中的常见bug又有哪些？

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

正文

根据ISO14119-1标准中所述，诊断服务14主要用于Client向Server(ECU)请求清除诊断相关信息。

应用场景

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

• ECU被刷写新的软件后，此时需通过14诊断服务清除下DTC，然后读取下DTC查看是否存在异常的DTC，保证系统监控正常；
• 在产线EOL工位或者客户电检工位上都会执行下14服务以便清除下历史DTC，然后查看下是否存在任何当前的DTC；

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

注意事项：

14服务可以指定某个DTC Group组(如Powertrain, Body, Chassis等)进行清除或者指定DTC进行清除。同时除非有特殊说明，否则将会清除所有排放相关或者非排放相关的DTC。

14服务清除DTC原理：

服务请求

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

请求格式

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

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

对于参数"groupOfDTC"按照14229-1标准文档定义取值如下：

其中Powertrain， Chassis，Body Group中的定义可以由各个主机厂自行定义，对于0xFFFF00-0xFFFFFE字段，如FFFF33表示排放相关的DTC Group，FFFFD0则表示Safety Group，其他的DTC group见如下表表格定义：

请求实例

以清除排放相关的DTC Group FF FF 33为例，如下图5所示：

发送14 FF FF 33诊断指令请求清除排放相关的DTC Group。

服务响应

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

正响应格式

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

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

• Response ID：该参数固定为SID+0x40 = 0x54；

正响应实例

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

负响应NRC支持

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

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

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

• 例如当尝试请求清除DTC时且当前车速条件不满足，此时Client发送诊断指令"14 FF FF FF"请求Server发生清除DTC行为，Server将会回复“7F 14 22”来告诉请求者当前执行清除DTC的条件不满足，请再次检查执行清除DTC的条件。
• 当发送报文长度或者格式不对时，则Server会回复"7F 11 13"；
• 当诊断请求的groupOfDTC不在Server支持的范围内时，则Server会回复”7F 11 31“；
• 当Server在执行写入NVM出现错误的时候，那么此时Server则会回复"7F 11 72"；

NRC优先级

有时候输入的诊断指令可能会同时存在多种错误，因此为了区分这些不同种错误的重要性，14229-1标准文档规定了NRC的优先级，针对14服务的NRC优先级如下：

常见bug大揭秘

对于从事过UDS开发的小伙伴可能会发现，其实针对每个服务的Bug都是有迹可循的，万变不离其宗，绝大多数问题都是由于针对需求理解不清晰或者其他人为因素导致的问题。

因此，为了方便大家能够在工作过程中能够快速找到问题症结所在，特将小T了解到的常见14服务Bug分享给到大家，当然具体问题还是要具体分析。

所谓14清除DTC策略就是如下AUTOSAR配置参数"DemClearDTCBehavior"来实现。

更多精彩内容！敬请关注公号: ADAS与ECU之吾见

​