UDS服务基础篇之14

前言

  • 你知道如果系统产生了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所示:

在这里插入图片描述

图1 14诊断服务请求格式

下图2中各参数解释如下:
在这里插入图片描述

图2 14请求格式说明

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

在这里插入图片描述

图3 DTC Group定义

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

在这里插入图片描述

在这里插入图片描述

图4 DTC Group标准定义
请求实例

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

在这里插入图片描述

图5 14诊断请求实例

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

服务响应

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

正响应格式

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

在这里插入图片描述

图6 14诊断服务正响应格式

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

  • Response ID:该参数固定为SID+0x40 = 0x54;
正响应实例

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

在这里插入图片描述

图7 14正响应实例
负响应NRC支持

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

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

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

在这里插入图片描述

图8 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优先级如下:

在这里插入图片描述

图9 14服务NRC优先级
常见bug大揭秘

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

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

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

在这里插入图片描述

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

  • 2
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论
UDS(Unified Diagnostic Services)是一种用于车辆诊断的标准协议,它定义了一套诊断服务和通讯机制,可用于汽车电子控制单元(ECU)之间进行通信和诊断。 31. 将要求来自所选控制单元的信息发回给UDS诊断工具或依据请求来在所选控制单元中执行一个操作的服务称为?答案是:Read Data By Identifier(按标识符读取数据)。 Read Data By Identifier是UDS诊断服务中的一种基础服务。它通过在请求中指定一个标识符来读取所选控制单元中的数据,然后将这些数据返回给UDS诊断工具。 在使用Read Data By Identifier服务时,UDS诊断工具会向所选的控制单元发送一个请求,请求中包含要读取的数据的标识符。控制单元根据这个标识符,从自己的存储器中读取相应的数据,并将其返回给UDS诊断工具。这样,UDS诊断工具就可以获得所需的数据,用于诊断和故障排除。 Read Data By Identifier服务的应用场景很广泛。例如,当车辆发生故障时,UDS诊断工具可以使用该服务来获取与故障相关的数据,以帮助诊断工程师分析和解决问题。此外,厂商和技术支持人员还可以通过Read Data By Identifier服务来获取车辆的状态信息、性能参数等。 总之,Read Data By Identifier是UDS诊断服务中的一项重要基础服务,它允许UDS诊断工具从所选控制单元中读取数据,并帮助诊断工程师进行故障诊断和解决问题。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

汽车小T

感谢打赏,我会继续努力奉献精彩

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值