第4章：UDS应用层基础：ISO 14229-1标准概述、UDS服务分类（强制与可选）、诊断会话控制（0x10服务）、安全访问（0x27服务）
各位同学，欢迎来到第四章。今天我们要聊的，是UDS协议里最核心、最基础的部分——应用层。
说实话，ISO 14229-1这个标准，我刚入行那会儿看着它厚厚一本，心里直发怵。但干久了你会发现，它就像一本字典，你不需要背下所有单词，但得知道怎么查，以及哪些词最常用。
4.1 ISO 14229-1标准概述
ISO 14229-1，全称是“道路车辆——统一诊断服务——第1部分：应用层”。
它定义了什么呢？说白了，就是ECU和诊断仪之间，到底该用什么“语言”来对话。这个“语言”包括：
- 服务的格式：请求长什么样？响应长什么样？
- 服务的含义：0x10代表什么？0x27又代表什么？
- 服务的时序：什么时候该发请求？什么时候该等响应？
我个人习惯把ISO 14229-1看作是UDS协议的“宪法”。它规定了所有ECU都必须遵守的基本规则。但注意，它只规定了“应用层”，至于这些数据怎么通过CAN总线、LIN总线或者以太网传出去，那是ISO 15765、ISO 14230这些“交通规则”该管的事。
核心要点： ISO 14229-1只关心“说什么”，不关心“怎么说”。
我在项目中遇到过不少新手，把UDS和CAN诊断混为一谈。其实UDS是应用层协议，CAN只是它常用的一个载体。你完全可以用UDS over LIN，甚至UDS over Ethernet。
4.2 UDS服务分类：强制与可选
ISO 14229-1里定义了一大堆服务，但并不是所有服务ECU都必须支持。标准把服务分成了两类：
- 强制服务（Mandatory）：所有ECU必须实现。这是底线，没得商量。
- 可选服务（Optional）：根据ECU的功能需求，可以选择实现或不实现。
嗯，这里要注意。强制服务其实很少，但它们是整个诊断体系的基石。我列个表，大家看得更清楚：
| 服务ID | 服务名称 | 分类 | 说明 |
|---|---|---|---|
| 0x10 | 诊断会话控制 | 强制 | 所有ECU必须支持，用于切换会话模式 |
| 0x11 | ECU复位 | 强制 | 所有ECU必须支持，用于复位ECU |
| 0x27 | 安全访问 | 可选 | 用于解锁受保护的功能，如刷写、配置 |
| 0x22 | 读取数据标识符 | 可选 | 读取ECU内部数据，如电压、温度 |
| 0x2E | 写入数据标识符 | 可选 | 写入数据到ECU，如配置参数 |
| 0x19 | 读取故障码信息 | 可选 | 读取DTC（诊断故障码） |
| 0x14 | 清除诊断信息 | 可选 | 清除DTC和冻结帧 |
你想想看，为什么0x10和0x11是强制服务？因为如果没有会话控制，ECU就不知道你处于什么模式；如果没有复位，ECU出了问题你连重启都做不到。这是最基本的“保命”功能。
我的经验： 在写ECU诊断规范时，我建议先把强制服务列出来，确保它们都实现了。然后再根据功能需求，去添加可选服务。千万别一上来就想着把所有服务都塞进去，ECU的ROM空间可是很宝贵的。
4.3 诊断会话控制（0x10服务）
0x10服务，全称是“DiagnosticSessionControl”。它的作用，就是让ECU在不同的“会话模式”之间切换。
为什么会需要不同的会话模式？
嗯，这就像你家里的路由器。平时正常上网，是“运行模式”；你要改WiFi密码，得先登录管理后台，这是“配置模式”。ECU也一样，不同的模式，开放不同的功能。
ISO 14229-1定义了三种标准的会话模式：
- 默认会话（Default Session，0x01）：ECU上电后的默认模式。在这个模式下，只能执行一些基本的安全相关的诊断服务，比如读取VIN码、读取故障码。不能刷写软件，也不能做复杂的配置。
- 编程会话（Programming Session，0x02）：用于ECU软件刷写。在这个模式下，ECU会关闭一些非必要的通信和功能，确保刷写过程稳定可靠。
- 扩展诊断会话（Extended Diagnostic Session，0x03）：用于更复杂的诊断和配置。比如读写校准参数、执行特殊功能（如执行器测试）。
请求格式很简单：
请求：0x10 + 会话ID
例如：切换到扩展诊断会话
发送：03 10 03响应格式：
肯定响应：0x50 + 会话ID + 附加信息（如P2定时器值）
例如：03 50 03 00 32 00 0A这里有个细节，响应里的P2定时器值，告诉诊断仪“我处理请求需要多长时间”。这个值在默认会话和扩展会话里可能不一样。我曾经调试过一个ECU，发现它在扩展会话里响应特别慢，查了半天，原来是P2定时器设得太长了。
避坑指南： 我曾经遇到过一个项目，ECU在编程会话里没有正确关闭CAN报文发送，导致刷写过程中总线负载过高，刷写失败。所以，切换会话时，ECU内部一定要做好“状态清理”工作。
4.4 安全访问（0x27服务）
0x27服务，全称是“SecurityAccess”。它的作用，就是给诊断功能加一把“锁”。
你想想看，如果任何人都能通过诊断仪刷写ECU的软件，那岂不是乱套了？所以，对于一些敏感操作，比如刷写、配置、执行特殊功能，ECU会要求你先通过安全访问验证。
安全访问的流程，说白了就是“挑战-应答”机制：
- 请求种子（Seed）：诊断仪发送0x27 + 安全级别，请求一个随机数（种子）。
- 发送种子（Seed）：ECU返回一个随机数（种子）。
- 发送密钥（Key）：诊断仪根据种子，通过一个约定的算法，计算出一个密钥，发送给ECU。
- 验证密钥（Key）：ECU用同样的算法，自己算一遍密钥。如果匹配，就解锁成功。
请求和响应的格式：
步骤1：请求种子
请求：02 27 01
响应：06 67 01 11 22 33 44 // 种子是 0x11223344
步骤2：发送密钥
请求：06 27 02 AA BB CC DD // 密钥是 0xAABBCCDD
响应：02 67 02 // 解锁成功这里的安全级别（0x01、0x02等）是ECU厂商自己定义的。比如，0x01可能用于解锁刷写功能，0x03用于解锁配置功能。不同的级别，可能对应不同的种子和算法。
核心要点： 安全访问的算法是保密的，通常由ECU厂商自己实现。诊断仪需要拿到这个算法，才能计算出正确的密钥。
我在项目中遇到过最头疼的问题，就是安全访问的“防破解”机制。有些ECU会限制尝试次数，比如连续3次输错密钥，ECU就会锁定一段时间，甚至永久锁定。所以，在开发诊断仪时，一定要处理好重试逻辑，别把ECU给锁死了。
我的建议： 在测试阶段，可以跟ECU厂商要一个“测试密钥”或者“调试模式”，绕过安全访问，提高开发效率。但量产时，一定要把安全访问加上，这是保护ECU不被非法篡改的最后一道防线。
好了，这一章的内容就到这里。我们讲了ISO 14229-1的定位，UDS服务的分类，以及两个最基础的服务——0x10和0x27。下一章，我们会深入聊聊0x22和0x2E这两个读写服务，它们在实际项目中用的最多。
记住，诊断协议不是死记硬背，而是理解它的设计思想。为什么要有会话控制？为什么要有安全访问？想通了这些，你就能灵活运用UDS了。