2. UDS协议核心概念
UDS（Unified Diagnostic Services）是ISO 14229系列标准定义的统一诊断服务，它并不规定物理层与数据链路层，而是建立在ISO 11898（CAN/CAN FD）、DoIP、LIN等传输层之上，通过一套标准化的服务标识符（SID）与诊断仪（Tester）和ECU之间交换数据。在Continental的量产项目中，UDS既是售后诊断的通用语言，也是产线EOL刷写、Bootloader升级、故障读取与执行器测试的统一入口。理解UDS的核心概念，本质上就是理解"谁在什么状态下、用什么寻址方式、发什么请求、ECU如何响应"这一整套约束关系。
ISO 14229服务模型：SID、子功能与数据参数
ISO 14229-1把诊断服务划分为若干功能单元，每个服务由1字节的服务标识符（SID）唯一标识。SID的最高位隐含了请求/响应方向：0x00–0x3F为请求SID，ECU肯定响应时在请求SID上加0x40，否定响应则统一使用0x7F。例如请求0x10（DiagnosticSessionControl）的肯定响应是0x50，请求0x27（SecurityAccess）的肯定响应是0x67。
许多服务在SID之后紧跟一个子功能字节（Sub-function），其bit 7为抑制肯定响应位（suppressPosRspMsgIndicationBit）。当该位为1时，ECU对成功执行不返回肯定响应，只在实际出错时返回否定响应。这在功能寻址广播场景中非常关键，可以显著降低总线负载。子功能字节之后是服务相关的数据参数，例如0x10服务的子功能0x03表示扩展会话，0x27服务的子功能0x01表示请求种子、0x02表示发送密钥。
否定响应由0x7F + 请求SID + NRC（Negative Response Code）三字节构成。常见NRC包括0x11（服务不支持）、0x12（子功能不支持）、0x13（报文长度或格式错误）、0x22（条件不满足）、0x31（请求超出范围）、0x33（安全访问被拒绝）、0x78（响应挂起，请求已收到正在处理）。0x78是刷写场景中非常常见的中间态，诊断仪必须继续等待而非立即判失败。
请求响应机制：从单帧到多帧的完整链路
在CAN上，UDS报文遵循ISO-TP（ISO 15765-2）传输协议。长度不超过7字节（经典CAN）或62字节（CAN FD）的请求可用单帧（SF）发送；更长的数据（如0x34请求下载、0x36传输数据）需要首帧（FF）+连续帧（CF）的多帧传输，并由流控帧（FC）协调发送节奏。诊断仪发出请求后，ECU在P2时间内返回响应；若无法在P2内完成，则先回NRC 0x78，之后在P2*时间内给出最终响应。P2与P2*是ECU诊断栈的关键时间参数，Continental项目通常在诊断规范（Diagnostic Specification）中明确给出，例如P2=50ms、P2*=5000ms（示例值，实际以项目DBC/CDD为准）。
响应机制还涉及响应挂起、重复请求抑制、以及功能寻址下多ECU同时响应的冲突问题。诊断仪必须根据寻址方式决定是否期待多个响应。
会话与安全状态：诊断访问的两道门
UDS用会话（Session）和安全等级（Security Level）控制ECU的可访问范围。默认会话（0x01）只允许读取基本DTC和部分标识符；编程会话（0x02）用于刷写，通常要求先进入扩展会话（0x03）再切换；扩展会话开放更多读写与例程控制。会话切换通过0x10服务完成，ECU在S3（会话超时，典型5s）内无诊断请求时会自动回落到默认会话。
安全访问通过0x27服务实现"请求种子—发送密钥"的挑战应答机制。ECU用内部算法对种子运算得到期望密钥，诊断仪必须用相同算法生成密钥。种子每次随机变化，防止重放。只有安全解锁后，ECU才允许执行0x2E写数据、0x31例程控制、0x34/0x36/0x37刷写序列等敏感操作。会话与安全状态是叠加关系：即使处于编程会话，未通过安全访问仍不能执行刷写。
寻址方式：物理寻址与功能寻址的本质区别
在CAN上，寻址通过报文ID体现。物理寻址使用点对点ID，例如诊断仪发0x7E0、ECU回0x7E8，一个请求只对应一个ECU，响应也是唯一的。功能寻址使用广播ID 0x7DF，总线上所有支持该服务的ECU都可能响应，因此诊断仪可能收到多个响应帧，需要按ID区分来源。
功能寻址的典型用途是：读取所有ECU的DTC（0x19）、广播会话切换（0x10）、广播通信控制（0x28）。由于是广播，请求中通常置位suppressPosRspMsgIndicationBit，让ECU只在出错时回复，避免总线被大量肯定响应淹没。物理寻址则用于所有需要精确控制、需要读写数据或涉及安全与刷写的场景。
Continental项目中的使用差异
在Continental的量产项目中，物理寻址与功能寻址的分工有明确的工程约定。刷写流程（进入编程会话、安全访问、请求下载0x34、传输数据0x36、退出传输0x37）必须使用物理寻址，因为刷写是点对点、有状态、有顺序的强约束过程，任何广播都可能导致多个ECU同时进入编程状态而无法管理。EOL产线通常通过DoIP或CAN FD物理寻址对单个ECU完成刷写，并在刷写前后用功能寻址广播0x10 0x01让所有ECU回到默认会话。
售后诊断仪读取全车DTC时，一般先用功能寻址0x19 0x02广播，再对未响应的ECU用物理寻址逐个补读。会话切换在产线常用功能寻址广播，但安全访问0x27必须物理寻址，因为种子是每个ECU独立生成的，广播无法完成挑战应答。此外，Continental的诊断规范通常要求：功能寻址请求的响应抑制位必须置1；物理寻址请求的响应抑制位一般置0，以便诊断仪确认执行结果。
一个可复用的判断依据
面对一个诊断任务，可以按以下顺序判断寻址方式：若操作对象是"全部ECU"且只关心是否有ECU报错，用功能寻址并置位响应抑制；若操作对象是"某个具体ECU"、涉及写数据、安全访问、刷写或需要确认执行结果，用物理寻址。会话与安全状态则决定该操作在当前状态下是否被允许：默认会话只能读，扩展会话可读写与例程控制，编程会话用于刷写，而安全访问是执行敏感操作前的必要前置条件。把这三层——寻址方式、会话状态、安全等级——同时纳入判断，才能正确预测ECU的响应行为。