【AutoSar_UDS服务】0x10服务_诊断会话控制

Gagaaaaaa

已于 2024-07-11 10:16:33 修改

阅读量2k

点赞数 17

分类专栏： #诊断协议栈文章标签：汽车笔记嵌入式硬件车载系统

于 2023-12-26 11:45:01 首次发布

本文链接：https://blog.csdn.net/Gagaaaaaa/article/details/132848511

版权

#诊断协议栈专栏收录该内容

15 篇文章 10 订阅

订阅专栏

诊断会话控制

1 术语解释
- 1.1 英文术语
2 功能简介
3 请求响应定义
4 服务请求实例
5 配置说明
6 参考资料

1 术语解释

1.1 英文术语

英文术语	解释
P2_ServerMax	ECU收到诊断请求后发送诊断响应消息的间隔，e.g 50ms
P2^*_ServerMax	ECU发送NRC 0x78（Pending）之后发送下帧诊断响应的间隔， e.g 5000ms
S3_Client	1. 表示Tester为了保持一个ECU或者多个ECU节点同时保持在非默认会话下的时间间隔 2. 为维持非默认会话而发送0x3E服务的时间间隔 e.g 200ms
S3_Server	ECU未接收到任意诊断报文时维持在非默认会话下的时间 e.g 5000ms

2 功能简介

2.1 功能概述

UDS 0x10服务主要有以下功能：

作为用来切换Server(即ECU)不同诊断会话的一种服务；
不同的诊断会话则规定了Server在相应session可以开启的服务权限；
在不同的诊断会话则应使用对应的数据链路层的时间参数（ P2_ServerMax, P2^*_ServerMax）；
会话状态切换结果会通过Rte，以便恢复通信；

2.2 应用场景

以上功能最为重要的就是不同的诊断会话能够开启响应服务的权限（在服务的配置中体现），如下图明确规定了不同的诊断服务在默认会话和非默认会话下的可用性。
注：其中“X”则代表可用，"not applicable"则代表不可用。
在这里插入图片描述

2.3 服务实现原理

一般地，在ECU中总有一个活动的会话模式，且刚上电后ECU默认进入默认会话下。如果client请求正在运行的会话，那么Dcm会发送肯定响应消息。

无论何时在非默认会话下，当S3_Server内无任何诊断请求并超时，DSL会将会话切换到默认会话并调用Rte Mode Switch接口告知BswM。S3_Server计时器在响应报文完成（接收到Confirmation或错误指示）、没有响应的诊断请求动作结束、多帧请求接收错误时开始；在接收到单帧或首帧请求报文时停止S3_Server计时器。
在这里插入图片描述
如上图所示，当执行27或者28等非常规服务时，则需要在非默认会话下执行，在默认会话下则不能够使用；
当需要重新编程Server时，那么此时需进入到编程会话下，这样所有与编程会话相关的诊断服务便可以设定仅允许在该session下运行(通常是进入Bootloader刷写程序)；
当整车制造商或者零部件供应商需要在自定义的seesion下完成某些特别的操作时，可以采用10服务控制，如产线内部使用的特定服务便可以在其自定义的会话下进行，避免与客户的会话下服务需求起冲突；

切换到新的会话可能需要一些条件的满足：

服务器可能只允许具有特定客户端标识符(客户端诊断地址)的客户端启动特定的新诊断会话(例如，服务器可能要求只有具客户端标识符0xF4的客户端启动extendedDiagnosticSession)
某些安全条件可能需要满足(例如，车辆不得移动或发动机不得运行)

3 请求响应定义

3.1 请求消息格式

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

由上图我们提到10服务会话类型，该会话类型（子服务）可以主要可以分为六种：

会话类型	取值（hex）	解释
默认会话	0x01	ECU启动默认进入的会话，该会话下能够执行大部分常规服务
编程会话	0x02	用于给ECU刷写的时候才会进入该会话，要注意进入该会话时要确保整车处于安全状态，比如车速为0等条件，否则会对行车安全构成威胁
扩展会话	0x03	用于执行非常规的诊断服务的场合，如0x28,0x27等服务
安全诊断会话	0x04	仅用于支持安全相关系统的功能，如安全气囊的部署
整车制造商自定义会话	0x40-0x5F	用于整车制造商指定的session及其对应的诊断功能
零部件供应商自定义会话	0x60-0x7E	用于零部件供应商指定的session及其对应的诊断功能

3.2 肯定响应格式

诊断服务0x10的肯定响应定义如下图：
在这里插入图片描述
其中sessionParameterRecord的具体含义如下图所示，

3.3 否定响应格式

一般情况下，Server针对Client的请求都会给到正响应，但正如之前所提到的进入编程会话前需确保整车处于安全状态，如引擎熄火，车速不能超过3km/h等，或者为了防止不按照诊断请求格式进行请求，那么Server需要通过某种方式来告诉Client执行不成功的原因在哪里以便于便于调查问题直至得到正响应。
因此ISO14229-1针对所有的诊断服务提供了一种统一的诊断负响应的诊断格式：7F +SID + NRC。
其中NRC全称为Negetive Responce Code，每个NRC具有唯一的含义来代表当前诊断请求错误的原因所在。当然每个诊断服务支持的NRC不尽相同，具体支持的NRC需要参考ISO14229-1标准文档，对于10服务而言支持的NRC如下表:
在这里插入图片描述