核心原因不是 0x14 服务本身只能发单帧而是功能寻址是 1:N 广播ISO 15765-2 在功能寻址下不支持流控和多帧传输所以能发的数据被限制在单帧里。1. 功能寻址没有“一对一”的流控协商ISO 15765-2 的多帧传输依赖这套握手FF → First Frame FC → Flow ControlBS / STmin CF → Consecutive Frame但功能寻址是广播诊断仪向0x7DF这类功能地址发请求多个 ECU 都可能收到。如果接收方回 FC就会出现几个问题多个 ECU 可能同时回 FC总线冲突诊断仪不知道这个 FC 是谁回的不同 ECU 的 BS、STmin 可能不同无法统一协商发送方无法按某个 ECU 的节奏继续发 CF。所以标准实现里功能寻址只允许单帧传输不进入 FF/FC/CF 的多帧状态机。2. 0x14 清除 DTC 正好适合单帧0x14 请求格式是14 DTCByte1 DTCByte2 DTCByte3加上 ISO-TP 单帧头通常就是04 14 FF FF FF这只有 5 个字节完全装得下一个 CAN 帧不需要多帧。所以用功能寻址批量清 DTC 时单帧限制并不会影响正常使用。3. 功能寻址下还要注意响应行为功能寻址清 DTC 时ECU 通常不会都回正响应。很多实现会执行清除动作抑制正响应避免多个 ECU 同时回复造成总线拥塞对不支持的服务/子功能/参数也可能不回 NRC。因此功能寻址0x14更适合作为“批量触发”如果需要确认每个 ECU 是否真的清成功还是要回到物理寻址对每个 ECU 单独读0x19 02或0x19 04验证。4. 在 CANoe Trace 里怎么看功能寻址清 DTC 通常只会出现7DF Tx 04 14 FF FF FF 7xx Rx 54 ← 某个 ECU 的正响应可能没有 7xx Rx 7F 14 xx ← 否定响应也可能被抑制不会看到7DF Tx 10 ... ← 功能寻址不应出现 FF 7xx Rx 30 ... ← 不应出现 FC 7DF Tx 21 ... ← 不应出现 CF如果出现 FF/FC/CF说明要么误用了多帧要么当前通道并不是严格的功能寻址单帧场景。一句话记物理寻址是 1:1可以协商 FC所以能多帧功能寻址是 1:N没有稳定 FC 协商所以只能单帧。0x14 清 DTC 正好 4 字节数据天然适合单帧广播。