车载网络测试 - UDS诊断篇 - 诊断服务$10

上一篇我们在（车载网络测试 - UDS诊断篇 - 诊断数据简析）中 有介绍各个服务的数据的格式，接下来的篇幅就是对各个服务做进一步的介绍，以便大家学习和了解；今天我们说的就是会话控制，有地方也叫会话切换（session control），下面就简单的聊一下这个服务，如有不对，欢迎指正。

一、10服务数据说明

服务请求

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

请求格式

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

A Data byte	Parameter Name	Cvt	Byte value	Mnemonic
#1	DiagnosticSessionControl Request SID	M	1016	DSC
#2	SubFunction = [ diagnosticSessionType ]	M	0016 to FF16	LEV_DS

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

参数名称	值(Hex)	含义
DiagnosticSessionControl Request SID	10	诊断会话控制SID，固定为10
SubFunction = [ diagnosticSessionType ]	00-FF	会话类型，如默认会话01，编程会话02等

10服务诊断请求格式说明

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

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

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

肯定应答:(sessionParameterRecord为各个主机厂定义)

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

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

否定应答：

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

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

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

NRC	Description	Mnemonic
0x12	sub-functionNotSupported This NRC shall be sent if the sub-function parameter is not supported	SFNS
0x13	incorrectMessageLengthOrlnvalidF ormat This NRC shall be sent if the length of the message is wrong	IMLOIF
0x22	conditionsNotCorrect This NRC shall be returned if the criteria for the request DiagnosticSessionControl are not met.	CNC

二、10服务介绍

    众所周知，汽车电子跟我们的消费类电子最大区别就在于安全性，汽车电子的安全性贯穿到整个设计开发流程，以及使用终端。那么其在不同使用者的权限，不同服务的使用权限我们就会对其进行限制。因此会话控制就由此而来，在10服务的会话控制中，主要分为默认会话以及非默认会话，非默认会话又会根据各个主机厂的实际需求进行使用。不过其中有一部分子服务为行业内部已经形成的默契，就是默认会话、扩展会话、编程会话；这些必须对应01子服务、03子服务、02子服务。

三、会话切换

上图为ISO-14229中定义的会话切换图形说明，但在各个公司内部使用的规范还会进一步对非默认会话进行说明；常见的几种规则：

1、任意会话都能直接切换到默认会话

2、任意会话都能切换到自身会话

3、进入默认会话会初始化在重置非默认会话下的所有易失性配置