UDS诊断 10服务

简介

10服务，即 Diagnostic Session Control（诊断会话控制）服务用于启用服务器中的不同诊断会话，可以通过会话模式赋予不同诊断服务 不同的执行权限。

诊断会话切换

诊断会话转换以及服务器转换到另一个会话时其应做出哪些反应。

流程序号	会话切换前	会话切换后	描述
1	默认会话	默认会话	服务器处于defaultSession（默认会话）状态时，若客户端要求启动defaultSession（默认会话），则服务器应完全重新初始化defaultSession（默认会话）。 激活的会话期间，服务器应重置所有已激活的／初始化的／更改过的设置／控制。这不包括已编程入非易失性存储器中的长期更改。
2	默认会话	默认会话	服务器从defaultSession（默认会话）转换为defaultSession（默认会话）外的其他会话时，服务器应仅停止已在defaultSession期间通过ResponseOnEvent（基于事件响应）（Ox86）服务在服务器中进行配置的事件（类似于stopResponseOnEvent（停止基于事件响应））。
3	其他会话	相同会话或其他会话	服务器从defaultSession（默认会话）外的诊断会话转换为非defaultSession（默认会话）的其他会话（包括当前有效诊断会话）时，则服务器应（重新）初始化诊断会话，这意味着： i) 应停止通过ResponseOnEvent（基于事件响应）（Ox86）服务在服务器中进行配置的所有事件。 ii) 应重新锁定安全性。注意，锁定安全访问应重置依存于待解锁的安全访问的任何有效诊断功能（例如，DID的有效inputOutputControl（输入输出控制））。 iii) 应维护好新会话中支持的且不依存于安全访问的所有其他有效诊断功能。例如，从一个non-defaultSession（非默认会话）转换为另一个或相同的non-defaultSession时，任何已配置的周期性调度器应保持活动状态，且不得影响CommunicationControl（通信控制）和ControIDTCSetting（控制DTC设置）的状态，这意味着，切换会话时若正常通信为禁用，则其应保持禁用状态。
4	其他会话	默认会话	服务器从非默认会话的任何诊断会话转换为defaultSession（默认会话）时，服务器应停止通过ResponseOnEvent（基于事件响应）（0x86）服务在服务器中已配置的所有事件，且应启用安全性。应终止defaultSession（默认会话）中不支持的任何其他活动的诊断功能。 例如，应禁用任何已配置的周期性调度器或输出控制，且应重置CommunicationControl（通信控制）和ControIDTCSetting（控制DTC设置）服务的状态，这意味着，会话切换为defaultSession（默许会话）时，若正常通信为禁用，则应重新启用正常通信。激活的会话期间，服务器应重置所有已激活的／初始化的／更改过的设置／控制。这不包括已编程入非易失性存储器中的长期更改。

除了发送请求可以使Server 切换会话，如果您进入了一个非默认会话的状态，一个定时器会运转，如果一段时间内没有请求，那么到时间（S3Server）后，诊断退回到默认会话01(最低权限)。当然，我们有一个$3E的服务，可以使诊断保持在非默认的状态。

请求和响应

1、请求

基本格式

归纳起来，诊断的request格式无非以下两种：

<SID> + <Sub-function> + <Parameter>

<SID> + <Parameter>

即有无sub-function的区别。Parameter可以是DID，可以是输入参数，可以是自定义的值，字节数视具体要求而定。

2、子功能

子功能参数定义（1字节数据）：

• Bit7：抑制肯定响应消息指示位 suppressPosRspMsgIndicationBit
  • 0=False：需要肯定响应
  • 1=True：禁止肯定响应
• Bit6-0：子功能参数值（0x00~0x7F）

3、肯定响应

基本格式：

<SID + 0x40> + <Sub-function> + <Parameter>

<SID + 0x40> + <Parameter>

要注意，第一个字节是由SID和0x40的和构成。这里的Parameter项是optional的，具体要看协议规定。

4、否定响应

基本格式:

<0x7F> + <SID> + <NRC>

看起来比较简单，格式比较固定，只要是Negative Response，第一字节就是0x7F，第二字节照抄原来的SID，第三个字节是错误响应码，指示具体错误响应的原因

5、特殊的NRC

这里提一下一个特殊的NRC——0x78，requestCorrectlyReceived-ResponsePending（RCRRP，请求已被正确接收-回复待定）。

这个NRC表明请求消息被正确地接收，请求消息中的所有参数都是有效的，但是要执行的操作还没有完成，Server端还没有准备好接收另一个请求。一旦请求的服务已经完成，服务器应该发送一个积极的响应或消极的响应，响应代码应与此不同。这个NRC的消极响应可以被Server端重复，直到被请求的服务完成并且最终的响应消息被发送。

https://zhuanlan.zhihu.com/p/37310388?utm_source=com.alibaba.android.rimet

为什么划分不同会话

因为权限问题。默认会话权限最小，可操作的服务少；扩展模式通常用于解锁高权限诊断服务，例如写入数据/参数、读写诊断码；编程模式用于解锁bootloader相关的诊断服务，即程序烧录。

题外话，讲个故事。这三个会话模式好比普通项目成员（默认会话）、项目组长（扩展会话）和会计（编程会话）的关系，小职员权限最小，小职员有的权限项目组长全有，项目组长还多了些其他的高端权限（如写数据、例程控制）。会计则不同，它有些自己独有的权限（刷写程序），但项目组的很多权限它没有（读/擦故障码），因为它只干会计相关的事，本身不参与项目。

下图仅供参数：

报文示例

Tx / Rx	Can Data	描述
	Byte 7 - Byte 0
Tx	02 10 02 XX XX XX XX XX	0：单帧 2：2个有效字节长度 10：10服务 02：编程会话 请求切换到编程会话
Rx	06 50 02 00 32 01 F4 XX	0：单帧 6：6个有效字节长度 50：SID + 0x40 00 32：P2server_max = 50ms 01 F4：P2*Server_max = 5000ms 回复肯定响应，并且回复 P2server、P2*Server 时间参数

UDS中常用 NRC

参考

• https://blog.csdn.net/wto9109/article/details/121345955
• https://zhuanlan.zhihu.com/p/37310388?utm_source=com.alibaba.android.rimet
• http://www.360doc.com/content/12/0121/07/30375878_1052846532.shtml