上一篇我们在（车载网络测试 - 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、进入默认会话会初始化在重置非默认会话下的所有易失性配置