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,信息与功能安全等前言热点话题!
在这里插入图片描述

### 关于UDS 10服务的信息 #### UDS协议对服务的定义 统一诊断服务(Unified Diagnostic Services, UDS)是一种基于ISO标准的汽车电子控制单元(ECU)通信协议。它规定了一系列的服务来支持车辆诊断功能,其中Service 10被定义为“诊断会话控制”服务[^1]。 此服务的主要目的是允许客户端请求不同的诊断模式或称为“会话”。这些会话可以分为默认会话、编程会话以及扩展会话等多种类型。每种类型的会话都有特定的功能和权限设置,从而满足不同场景下的需求。 ```python # 示例代码展示如何发送一个简单的UDS Service 10命令 def send_diagnostic_session_control(session_type): request_id = 0x10 response = can_bus.send_request(request_id | session_type) return response # 调用函数切换到编程会话 (假设编程会话对应的值为2) response_data = send_diagnostic_session_control(2) print(response_data) ``` 以上是一个简化版的例子,展示了怎样通过调用`send_diagnostic_session_control()`方法向目标设备发出进入某种指定会话类型的指令。 #### 图形化解释Service 10 虽然无法直接在此处绘制图像,但是可以通过文字描述想象一下流程图的样子: - 开始节点 -> 客户端发起Session Change Request -> ECU接收并解析请求 -> 判断是否合法合规 -> 如果成功则返回Positive Response,并改变当前工作状态;如果失败,则反馈Negative Response给源地址。 这种逻辑可以用箭头连接各个阶段形成闭环结构图表表示出来。 #### 手动测试过程概述 对于实际操作中的手动测试而言,技术人员通常借助专用工具如CANoe或者Vector CANalyzer来进行交互式调试验证。他们按照既定脚本逐步执行各项动作步骤直至完成整个周期内的全部项目评估为止。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

汽车小T

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

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

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

打赏作者

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

抵扣说明:

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

余额充值