UDS服务基础篇之10

前言

在使用汽车UDS诊断服务的过程中,我们会用到一个十分常见的诊断服务$10服务。该服务基本上时执行其他特别任务的前置服务,所以有必要跟大家一起介绍该服务的基本特点,首先,请问大家几个基础问题?

  • 10服务是做什么的呢?
  • 10服务有哪些子服务呢?
  • 10服务的请求格式及响应格式又是如何定义的呢?
  • 执行10服务自身有无前置条件呢?

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

image-20211114211512105


正文

服务功能
功能描述

在《ISO14229-1》ISO标准文档中针对10服务做了十分详细的说明,总结下来其主要体现为以下几点:

  • 10服务是用来使能Server(即ECU)不同诊断会话的一种服务;
  • 不同的诊断会话则规定了Server在相应session可以开启的功能权限;
  • 在不同的诊断会话则应使用对应的数据链路层的时间参数;

其中最为核心的一点就是诊断服务权限控制。如下图1所示,则明确规定了不同的诊断服务在默认会话和非默认会话下的可用性,其中“X”则代表可用,"not applicable"则代表不可用。

image-20211114145757800

图1 10诊断服务权限控制

应用场景

  • 如上图1所示,当执行27或者28等非常规服务时,则需要在非默认会话下执行,在默认会话下则不能够使用;
  • 当需要重新编程Server时,那么此时需进入到编程会话下,这样所有与编程会话相关的诊断服务便可以设定仅允许在该session下运行;
  • 当整车制造商或者零部件供应商需要在自定义的seesion下完成某些特别的操作时,可以采用10服务控制,如产线内部使用的特定服务便可以在其自定义的会话下进行,避免与客户的会话下服务需求起冲突。
10服务请求

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

请求格式

按照14229-1标准所述,如下图2所示:

image-20211114151411084

图2 10服务诊断请求格式

图中各参数解释如下图3所示:

3-诊断请求格式

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

会话类型

由上图3我们提到10服务会话类型,该会话类型可以主要可以分为六种:

  • 默认会话(0x01);
  • 编程会话(0x02);
  • 扩展会话(0x03);
  • 安全诊断会话(0x04);
  • 整车制造商自定义会话(0x40-0x5F);
  • 零部件供应商自定义会话(0x60-0x7E);

如下图4所示,对上述六种会话类型的功能特点做了简要说明。

4-会话功能特点

图4 各诊断会话特点

请求示例

以进入编程会话为例,如下图5所示:

image-20211114160353167

图5 编程会话请求

由上可知,在不考虑特殊场景的前提下,只需发送"10 02"诊断请求便可以让Server进入到编程会话。

suppressPosRspMsgIndicationBit: 为subfunction的Bit 7位。

  • 如果该Bit位为1,则表示抑制正响应,Server不需要给到Client正响应;
  • 如果该Bit位为0,则表示不抑制正响应,Server应该给予Client正响应;

在第2个Byte中特该Bit位为1别提到抑制正响应为False,则表示不抑制正响应,Server正常回复就是。

10服务响应

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

正响应格式

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

image-20211114162137148

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

其中sessionParameterRecord的具体含义如下图7所示,

image-20211114162613242

图7 10诊断正响应时间参数格式

其中关于P2Server以及P2*Server参数均来源于客户诊断需求规范,按照客户需求配置即可。对于UDS所有的时间参数可见我的另一篇干货文章UDS时间参数总结篇,本文将不过多解释。

正响应实例

如下图8所示,针对上述图5所示的编程会话请求所作出的实际响应。

image-20211114163437165

图8 10编程会话请求正响应

由图8可知,P2Server的值为50ms,P2*Server的值为500ms;

负响应NRC支持

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

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

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

image-20211114165111280

图9 10服务NRC支持

例如当进入到编程会话时且当前车速条件不满足,此时Client发送诊断指令"10 02"请求Server进入编程模式时,Server将会回复“7F 10 22”来告诉请求者当前进入编程会话的条件不满足,请再次检查进入编程会话的条件。


更多精彩文章,敬请关注公众号:ADAS与ECU之吾见!

公众号后台回复关键字“加群”,便可免费加入AUTOSAR技术交流群,共同探讨CP,AP,SOA,信息与功能安全等前言热点话题!
在这里插入图片描述

评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

汽车小T

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

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

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

打赏作者

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

抵扣说明:

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

余额充值