AUTOSAR UDS诊断-精讲

Service Identifier (SID，服务标识符)
是诊断服务的主标识符，用于指定要执行的 UDS 服务类型（例如 0x22 表示“按标识符读取数据”）
→ 它是整个请求的“入口”，决定了后续可使用的参数结构。
Subfunction (SF，子功能)
由 SID 进一步指定，用于细化该服务的具体行为或选项（例如在 0x19 服务中，SF = 0x01 表示“读取当前故障码”，SF = 0x02 表示“读取历史故障码”）。
→ 并非所有服务都支持子功能（如 0x22 通常无 SF），且 SF 的语义由具体服务定义。
Data Identifier (DID，数据标识符)
由 SID 识别/指向，用于指定具体要操作的数据项（如 0xF186 表示车辆 VIN，0xF190 表示 ECU 硬件序列号）。
→ 主要用于 0x22（读）、0x2E（写）、0x31（例程控制）等需访问具体数据的服务中。

UDS 结构概览

UDS报文结构基于CAN帧封装：CAN ID 定位目标ECU，SID 指明诊断服务（如 0x10 为会话控制），子功能字节（可选）细化操作，后续为具体参数数据。
整个结构清晰分层——底层靠CAN寻址，上层靠SID驱动逻辑，既简洁又具备扩展性。

PCI字段
PCI（Protocol Control Information，协议控制信息）字段本身与UDS请求的内容无关，但当UDS诊断请求通过CAN总线传输时，该字段是必需的。简言之，PCI字段长度为1~3字节，用于描述那些无法在单个CAN帧中完整传输的消息的分段/传输控制信息（如单帧SF、首帧FF、连续帧CF、流控帧FC等）。
SID（Service Identifier，服务标识符）
当需要调用某一特定UDS服务时，UDS请求消息的数据载荷（Data Payload）中必须包含对应的UDS服务标识符（SID）。注意：SID分为请求SID（如 0x22）和响应SID（如 0x62），二者通常为“请求SID + 0x40”关系（例如 0x22 → 0x62）
子功能字节（Sub-Function Byte）
某些UDS请求帧中会使用子功能字节，但并非所有服务都需该字段——例如服务 0x22（Read Data By Identifier）就不使用子功能字节。

一般而言，当测试设备向ECU发送请求后，ECU可能返回肯定响应（Positive Response）或否定响应（Negative Response）。
- 若为肯定响应，测试设备可通过将子功能字节的最高位（Bit 7）置1来抑制该响应（即要求ECU不回复，常用于避免冗余通信）；
- 否定响应不可被抑制（无论Bit 7如何设置，ECU仍必须返回NRC）。
- 剩余7位（Bit 0~6）可用于定义最多128种子功能值。
  例如：使用SID 0x19（Read DTC Information）读取故障码时，子功能字节用于指定报告类型（如 0x01 表示“当前故障”，0x02 表示“历史故障”等）。
请求数据参数（Request Data Parameters）
- 在大多数UDS请求服务中，除SID及可选的子功能字节外，还需额外的请求数据参数以进一步配置请求行为。
- 典型例子是数据标识符（DID, Data Identifier）——例如在服务 0x22 中，后续2字节即为DID，用于指定要读取的具体数据项（如 0xF186 表示车辆VIN）。
  其他服务还可能包含地址、长度、掩码、安全密钥等各类参数。

UDS：服务请求&响应行为

UDS采用严格的“请求-响应”机制：

Tester发送带SID（服务标识符）的请求（如 0x10 ），ECU返回对应SID的正响应（如 0x40 表示 0x10 的响应），或带 0x7F 前缀的负响应（含原SID和错误码）。
这种设计确保了诊断过程可预测、可追溯，是UDS可靠性的核心基础。

正面响应与负面响应

UDS（统一诊断服务）协议定义了ECU如何响应来自诊断设备（如扫描工具或测试系统）的请求。根据请求的成功与否，ECU会返回两种类型的响应之一：正面响应（Positive Response）或负面响应（Negative Response）。

正面响应 (Positive Response)

当ECU成功处理了诊断请求后，它会发送一个正面响应。正面响应的格式通常是：

响应SID (Response SID)：它是对应请求SID加上0x40
数据 (Data)：包含请求所要求的数据。数据的内容和长度取决于具体的请求SID及其参数。

示例：

请求：0x22 F1 90 （读取DID F190 的数据）
成功响应：0x62 F1 90 01 23 45 67 （返回DID F190 的值为01 23 45 67）

负面响应 (Negative Response)

如果ECU无法处理请求（例如，因为请求的服务未被支持、子功能无效、参数错误、条件不满足等），它会发送一个负面响应。负面响应的格式是固定的：

固定SID 0x7F：所有负面响应都以0x7F开头。
请求SID (Request SID)：紧随其后的是引发负面响应的那个原始请求的SID。
否定响应码 (NRC, Negative Response Code)：一个字节，表示失败的具体原因。

常见的否定响应码（NRC）包括但不限于：

NRC	含义 (Meaning)
`0x10`	GeneralReject (通用拒绝)
`0x11`	ServiceNotSupported (服务不支持)
`0x12`	SubFunctionNotSupported (子功能不支持)
`0x13`	IncorrectMessageLengthOrInvalidFormat (消息长度不正确或格式无效)
`0x22`	ConditionsNotCorrectOrRequestSequenceError (条件不正确或请求序列错误)
`0x31`	RequestOutOfRange (请求超出范围)
`0x33`	SecurityAccessDenied (安全访问被拒绝)
`0x78`	RequestCorrectlyReceived-ResponsePending (请求已正确接收，响应待定)

示例：

请求：0x28 01 （启用消息传输，子功能01）
失败响应：0x7F 28 12 （表示服务0x28的子功能01不受支持）

这种区分使得诊断设备能够明确知道请求是否成功，并在失败时了解失败的原因，从而采取相应的措施。

常见服务

0x10: 诊断会话控制

0x27: 安全访问

0x22 : 读 / 0x2E : 写

DTC : 0x19 0x14

UDS 常用服务总结

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

软考中级嵌入式——备考精华

AtomGit开源社区

【论文复现】基于反步法-神经网络控制器、LOS制导和Lyapunov方法的多艘欠驱动水面船舶协调路径跟踪非线性控制Matlab代码

针对海洋环境扰动、模型不确定性及误差约束条件下多艘欠驱动水面船舶的编队协调路径跟踪控制难题，本文以多欠驱动水面船舶系统为研究对象，结合视线（Line‑of‑Sight，LOS）制导策略、反步控制方法、神经网络自适应逼近技术与李雅普诺夫稳定性理论，开展非线性协调路径跟踪控制器设计与稳定性分析。首先针对直线路径、正弦曲线路径、圆形路径及混合路径四类典型航行轨迹，完成 LOS 制导率优化设计；依托图论理

AtomGit开源社区

【顶级EI复现】考虑用户行为基于扩散模型的电动汽车充电场景生成（ Python + PyTorch代码实现）

针对大规模电动汽车无序充电对配电网稳定运行带来的挑战，传统统计建模方法难以刻画用户行为驱动下充电负荷的强随机性、时序依赖性与多维耦合特征，难以生成贴合实际运行规律的充电场景。为此，本文提出一种基于条件去噪扩散概率模型的电动汽车充电场景生成方法。首先，基于充电起始时刻、充电时长、充电功率、用户出行习惯等多维信息，构建用户个体与场站集群两层级行为特征矩阵，搭建多层级充电场景生成框架；