系列文章目录
文章目录
前言
在车辆中，如果有什么东西坏了，我们需要了解发生了什么或正在发生的事情，以便我们能够提供适当的措施。术语“诊断”是指车辆（ECU）提供服务（输出有关车辆状态的信息），然后我们可以请求这些服务，以了解车辆的状况，症状和问题并进行维修或配置。
诊断协议 UDS 的出现提供了标准方法。在这篇博客中，我们将概述统一诊断服务（UDS），它被汽车行业的大多数OEM统一使用。
1. 诊断和使用
车辆诊断对象：
- 询问ECU的故障
- 更新、校准ECU固件
- 与ECU硬件进行低级交互（例如开/关IO），自检操作 诊断用法
外部测试仪工具用于通过诊断插头/端子连接到车辆ECU，并通过UDS等诊断协议进行通信。诊断服务用于车辆整个生命周期的各种用例：
- 开发测试和验证
- 制造业
- 售后服务
⟹ 对于软件开发，诊断功能主要用于测试和验证。
诊断功能应被验证为符合特定标准（例如，使用Vector CANDiVa创建一致性测试套件并验证目标ECU的诊断功能是否满足ISO14229标准），之后在软件鉴定或系统验证和确认阶段，诊断功能应用作验证其他功能操作的媒介。
除了为外部测试仪工具（OFF Board）提供诊断服务外，车辆在运行过程中（ON Board）也进行自我诊断。
2. 诊断 OSI 模型
UDS协议标准规范由国际标准化组织（ISO）在ISO 14229中定义。共有 8 个部分，但在本介绍中，我们只关注 UDS 应用的第 1 部分：应用层和第 2 部分：会话层服务，其余部分特定于不同类型的传输介质（即 CAN、以太网、Flexray,…）。
- ISO 14229-1：规定了诊断服务的数据链独立要求，允许诊断测试仪（客户端）控制车载电子控制单元（ECU、服务器）中的诊断功能，例如电子燃油喷射、自动变速箱、防抱死制动系统等，连接到嵌入在道路车辆中的串行数据链路。
- ISO 14229-2：指定了通用会话层服务和要求，以提供统一诊断服务（ISO 14229-1）与所有传输协议和网络层服务（e.g. ISO 13400-2 DoIP、ISO 15765-2 DoCAN、FlexRay上的ISO 10681-2通信、ISO 14230-2 DoK-Line和ISO 20794-3 CXPI）之间的独立性。
- ISO 14229-3：规定在道路车辆 （UDSonCAN） 的控制器局域网 （CAN） 上实施一组通用的统一诊断服务 （UDS）。
除此之外，我们还有一些关于 OBD 的规范，其中指定了有关排放相关服务和诊断故障代码定义的信息。
- ISO 15031-5：旨在满足美国和欧洲以及任何其他可能采用类似要求的地区车载诊断 （OBD） 法规的数据报告要求。
- ISO 15031-6：为标准化诊断故障代码 （DTC） 提供统一性，机动车辆的电气/电子车载诊断 （OBD） 系统在检测到故障时必须报告。
在本博客中，我们将提供一些关于CAN诊断的示例，因此还需要考虑有关下层CAN的一些规范：
- ISO 15765-2：指定了为满足 ISO 11898-1 中规定的控制器局域网上基于 CAN 的车辆网络系统的要求而量身定制的传输协议和网络层服务。
- ISO 11898-1：规定了在实现CAN数据链路层的模块之间建立数字信息交换的特征。
3. UDS协议
3.1 Operation
- 客户端：通常称为外部测试设备，使用应用层服务请求在一个或多个服务器中执行诊断功能。客户端也可以是车载中的ECU（车载测试仪），能够向其他ECU执行诊断请求（即网关接收固件更新（FOTA）并向车辆上的其他ECU发送请求）。
- 服务器：通常是一个ECU或车辆功能（在多个ECU中分配），使用应用层服务将请求的诊断服务提供的响应数据发送回客户端。
服务器应始终确认消息传输，这意味着对于从客户端发送的每个服务请求，应有一个或多个从服务器发送的对应响应，无论是正面的还是负面的。
此规则的唯一例外情况是，在少数情况下使用
函数寻址或请求指定不生成响应。
为了避免给系统带来许多不必要的消息负担，在某些情况下，即使服务器未能完成请求的诊断服务，也不会发送否定响应消息。
注意：当请求消息使用功能寻址时，不会传输否定响应代码为 SNS （serviceNotSupported）、SNSIAS （serviceNotSupportedInActiveSession）、SFNS （SubFunctionNotSupported）、SFNSIAS （SubFunctionNotSupportedInActiveSession） 和 ROOR （requestOutOfRange） 的否定响应消息。
3.2 协议数据单元结构
应用层诊断服务格式：
消息类型
诊断：同一网络中的诊断测试器客户端和诊断服务器之间的直接诊断通信（没有可选的 [远程地址] 字段）
远程诊断：来自/到测试器客户端（[源地址]）的诊断服务请求/响应应通过网络网关组件（[目标地址]）（例如车辆网关 ECU）路由到目标诊断服务器（[远程地址]）。
安全诊断：
源地址：发送诊断请求或响应的节点的逻辑地址。
目标地址：接收诊断请求或响应的节点的逻辑地址，可以是功能地址，也可以是物理地址。对于远程诊断类型，此“目标地址”应为与其他网络交互的本地网关节点的地址。
远程地址：节点的逻辑地址，属于将从发送节点接收诊断请求或响应的其他网络。
子功能字节，数据标识符：
DID、PID、RID 是相似的，因为它是非易失性数据 （DID/PID） 或函数（可执行操作 RID）的逻辑表示。
UDS服务的CAN帧示例：
一些 UDS 服务支持子函数 （SF） 来进一步定义 SID
的请求功能 ➢ 例如 ECUReset、会话更改
一些 UDS 服务支持数据标识符 （DID） 通过用于 UDS 通信
的逻辑编号 （DID） 访问数据 ➢ 例如读取和写入数据
CAN TP PCI（协议控制信息）是 CAN 传输层 PDU 报头信息，由 ISO 16572-2 指定。CAN TP在传输和接收过程中帮助分解和重新组装应用层UDS帧，以防应用数据无法通过单个CAN帧发送（即经典CAN物理仅支持8字节有效载荷数据）。
寻址：
示例：车辆PT系统中的EDS ECU应具有：
- 物理地址 = 0x0A，应具有相应的物理诊断请求/响应，其 CAN 报文 ID 值为 0x78A（req）、0x70A（resp）（此 CAN 总线中诊断功能报文的基址为 0x700因此为 0x7XX）
- 2 个附加功能地址：0x22（0x722，用于支持 OBD 相关服务）和 0x3A（0x73A），用于动力总成系统上所有 ECU 的诊断服务操作。
寻址方案：
根据每个项目的不同，有些项目仅支持具有 11 位标识符 （2.0A） 的 CAN 报文，其他 29 位 （2.0B），可以使用不同的报文寻址方案用于诊断源和目标：
| 方案 | 描述 | 例子 |
|---|---|---|
| 正常 | CAN ID包含源地址或目标地址。每个ECU有2个CAN ID（诊断请求/响应）。➢ n*2 消息 ID，用于诊断网络中 n 个 ECU | PHYS 请求：0x78A PHYS 响应：0x70A |
| 扩展 | CAN ID包含源地址，第一个数据（有效载荷）字节包含目标地址。 1 个用于所有ECU诊断请求的CAN ID：基址+源地址（测试仪），特定ECU的目标位于有效载荷数据中。 每个 ECU 有 1 个 CAN ID 用于响应，ECU ID 位于 CAN ID 中，testerID 位于有效载荷数据中。 ➢ n+1 消息 ID，用于诊断网络中 n 个 ECU | 11 位：0xNss，数据：0xtt… 29 位：0xNnNnNnss，数据：0xtt…。 |
| 普通固定（仅限 29 位 CAN ID） | CAN ID包含源地址和目标地址。每个ECU有2个CAN ID（诊断请求/响应）。 | format： 0x03FFttss phys request： 0x03FF0102 phys response： 0x03FF0201 testerID： 0x01， ECU： 0x02 并且 0x03FF 是物理寻址的基础 |
| 混合寻址（仅限 29 位 CAN ID） | 对于不同子网的ECU：CAN ID包含本地地址，其中1个是网关地址;第一个数据字节包含远程地址（另一个子网中的本地地址，也称为地址扩展 AE）。 | 0x0CEAggss，数据：0xtt…（0x0CEA是物理寻址的基础）0x0CDAggss，数据：0xtt…（0x0CDA是功能寻址的基础） |
gg：网关地址
ss：源地址
tt：目标地址
nn：
任何有关寻址方案的详细信息都可以在 ISO 15765-2 中读取。
3.3 消息计时
对于UDS的会话层，除了在通信过程中处理请求/响应的时间外，没有特殊操作。一般来说，我们必须配置以下计时器：
-
⮚ 测试仪：
- P2客户端：客户端在成功传输请求消息后等待到传入响应消息开始的超时值。
- P2Client_max：是 P2Client 的初始/默认值
- P2*Client_max：增强了客户端在收到否定响应消息后等待的超时，否定响应代码 0x78（requestCorrectlyReceived-ResponsePending） 用于下一个传入响应消息的开始。
- S3 客户端时间：诊断客户端 （=tester） 在发送测试人员当前请求之前应等待的时间。
- P2客户端：客户端在成功传输请求消息后等待到传入响应消息开始的超时值。
-
⮚ ECU：
- P2服务器：ECU的性能计时器，加载P2Server_max或 P2*Server_max值。
- P2Server_max：服务器要么处理请求并及时发回响应，要么请求处理仍在进行并且发生 timeout（P2Server_max值），然后服务器发回 NRC=0x78 的否定值，用于“requestCorrectlyReceived-ResponsePending”以通知待处理的最终响应。
- P2Server_max：服务器在传输带有否定响应代码0x78的否定响应消息后启动的性能要求。如果服务器仍然无法在增强的 P2Server_max 中提供请求的信息，则应再次发送带有否定响应代码0x78的进一步（时间取决于配置）否定响应消息。
-
S3 服务器时间：诊断服务器中用于离开非默认会话的超时。
-
P4服务器：是性能要求时间，即从接收请求到开始传输最终响应之间的时间段（可以是正面响应，也可以是否定响应，NRC 不0x78）。
在请求安排定期响应的情况下，表示接受或不接受安排定期响应请求的初始未确认分段数据传输 （USDT） 正面或否定响应应被视为最终响应。
如果 P4Server_max 与 P2Server_max 相同，则表示不允许对该服务或数据使用否定响应代码0x78否定响应- P4Server_max：是 P4Server 的最大值
如果您的项目在开发中使用 Vector 软件工具链，则用于诊断的底层 CAN TP 协议的配置通常可以在 .cdd（CANdela Diagnostic Description） 文件中建立。
4. 服务
4.1 服务清单
4.2 示例 - 诊断会话控制服务操作
一般服务处理：所有服务请求都是必需的，验证步骤如下图所示。根据实施方式的选择，并非所有 NRC 检查都是必需的。
1：无法接受诊断请求，因为另一个诊断任务已经被不同的测试人员客户端
请求并正在进行中 2：参考每个服务的响应行为（支持的负响应代码）
通用服务子功能处理：所有带有 SubFunction 参数的请求服务都是必需的，验证步骤如下图所示。
1：至少 2 个（SID+SubFunction 参数）
2：如果 SubFunction 需要进行序列检查，例如 LinkControl 或 SecurityAccess
3：参考每个服务的响应行为（支持的否定响应代码）
诊断会话控制服务 （0x10） 的特定处理操作：
5. Session
服务器中应始终只有一个处于活动状态的诊断会话。服务器在通电时应始终启动默认诊断会话。如果未启动其他诊断会话，则只要服务器通电，默认诊断会话就应运行。
非默认诊断会话（不包括 programmingSession）中的诊断服务和诊断功能集是 defaultSession 中提供的功能的超集。
在默认的扩展会话中执行诊断服务时，ECU 的正常运行应保留。
-
转换到非默认会话（从默认会话或其他非默认会话）：
- 停止默认会话中由 ResponseOnEvent（0x86） 配置的所有事件。
- 安全应重新锁定，安全访问锁定应重置所有诊断功能，这些功能取决于解锁的安全访问。
- 应保留其他不依赖于安全访问的诊断功能。
-
转换回默认会话：
- ResponseOnEvent（0x86） 的响应式事件。
- defaultSession 中不支持的任何其他活动诊断功能都将终止。
-
S3服务器计时器<超时会话：服务器在不收到任何诊断请求消息的情况下使 defaultSession 以外的诊断会话保持活动状态的时间。
-
更改为非默认会话>启动 S3服务器计时器：S3服务器计时器也会在收到服务器不支持的诊断请求消息/服务完成时重新启动。
6. 安全访问和身份验证
- 服务0x27：测试人员使用种子密钥进程解锁 ECU 访问，>访问受保护的功能，例如与内存修改、编程相关的特定例程。
- 服务0x29（UDS ver2020 的新增功能）：测试人员使用连接/访问 OEM 服务器以获取证书所需的证书基础 PKI >对其角色进行身份验证。
6.1 安全访问操作
-
服务 安全访问 （0x27） 提供了一种访问数据和/或诊断服务的方法，这些服务因安全、排放或安全原因而限制访问。下载到服务器的不正确例程或数据可能会损坏电子设备或其他车辆部件，或危及车辆是否符合排放、安全或安保标准。安全概念使
-
用种子和密钥关系（非对称）。
要记住的另一件事是，使用AUTOSAR，只有一个安全访问级别状态机，与测试人员与ECU的通信方式无关（即，ECU安全访问通过CAN连接打开，然后另一个测试人员可以通过DoIP连接直接进行安全访问，而无需重新请求安全访问）。
“请求种子”SubFunction 参数值：奇数值
‘sendKey’ SubFunction 参数值：equal requestSeed 值 + 1 ⟹ 偶数值
6.2 身份验证
此服务的目的与安全访问服务（0x27）相同，通过用户角色（供应商、开发、售后,…）进行授权，而不是0x27级别，以及身份验证服务（0x29）安全概念，基于以下任何一项：
- PKI证书交换和使用非对称加密（在AUTOSAR 4.4.0中引入）。
- 没有PKI和非对称或对称加密的质询-响应（超出AUTOSAR的范围，需要在DCM中自定义实现）。
- 使用 AUTOSAR，对每个物理连接进行身份验证状态机。
7. 故障 & DTC
7.1 故障记忆
如果在ECU运行过程中发生任何故障，它将存储此故障代码，故障状态，快照数据和一些扩展数据记录，这将有助于诊断工程师轻松了解根本原因并修复车辆。
故障存储器：在ECU运行期间存储故障相关信息的位置，并在OFF Board诊断操作期间由测试人员读取。
应有：
⮚ OBD的所有UDS代码和法定故障的主故障存储器（ECU具有发射相关功能）。
⮚ 附加 UDS 用户定义的故障代码（在开发过程中可选，不用于生产）。
故障代码（诊断故障代码 - DTC）的属性：
DTC 定义映射到诊断事件（DEM 的）的唯一标识符，并且可以稍后由测试人员（通过 DCM）进行查询。
- 第一个字节应解决故障位置，基本上是ECU在车辆中的位置（例如动力总成，车身,…）以及该DTC是由ISO规范还是制造商定义的。
- 第二个字节显示故障组件/系统。
- 最后一个字节显示故障类别和子类型，详细说明了发生的故障类型。
因此，对于每个逻辑 DTC 编号，应将以下数据与其相关联：
DTC 状态字节：
DTC 快照：是与 DTC 关联的特定数据记录 （DID），存储在服务器的内存中。DTC 快照的典型用途是在检测到系统故障时存储数据。DTC 快照将充当系统故障发生时的数据值的快照。
DTC Extended Data：用于存储与 DTC 关联的动态数据（统计）
- DTC B1 故障指示器计数器，用于表示 OBD 系统在故障处于活动状态时运行的时间量（发动机运行小时数）。
- DTC 发生计数器，统计已报告“testFailed”的驾驶周期数。
- DTC 老化计数器，计算自故障最近一次失败以来的驾驶循环数，不包括测试未报告“testPassed”或“testFailed”的驾驶循环。
- OBD 的特定计数器（例如，如果可以在无故障模式下执行驾驶循环，则在“检查发动机”灯关闭之前的剩余驾驶循环次数）。
- 上次发生的时间（等）。
- test failed 计数器，计算报告的“testFailed”的数量，如果验证分几个步骤执行，则可能还有其他计数器。
- 未完成的测试计数器，计算自上次完成测试以来的驾驶循环次数（即自测试报告“testPassed”或“testFailed”以来）。
为了检索 DTC 信息，我们使用 UDS 服务0x19：
7.2. 数据标识符
数据标识符 （DID） 是用于寻址 ECU 存储器中可用的特定数据存储位置的逻辑数字。DID用于各种诊断用例，例如：
- 测量、动态、实时数据
- 存储的数据
- 鉴定
- IO 控制
- ECU配置，变体编码
- 冻结帧/快照数据
- …
通常，某些数据标识符 （DID） 应配置为与特定 DTC 相关，并在记录 DTC 时存储其值的快照。
8.闪烁（重新编程）
在闪存操作中应使用诊断服务列表，以提供定义的序列/接口，以处理软件更新过程（即预编程状态转换、通信接口准备、将接收的数据传输和编程到闪存中）。
应用程序和引导加载程序软件之间的状态转换
诊断软件应支持以下服务：
- 触发从应用程序状态到重新编程状态的转换。
- 从测试人员实体下载更新的软件（拆分为多个数据包）。
- 擦除数据并将其写入闪存。
编程顺序分为两个编程阶段。
编程阶段 1（必修）：用于软件/数据以下的编程
- 引导加载程序软件
- 应用程序
- 应用数据
编程顺序可分为3个部分：预编程、编程执行、后编程
编程阶段 2（可选）：可由 FBL 触发，并在 ECU 启动进入应用时执行，例如：
- 一些额外的ECU识别更新，
- 清除旧诊断故障，
- 和适配，编码数据需要在完成应用软件更新后写入ECU。
下面是在编程操作（阶段 1）期间应调用的诊断服务的示例序列。
9. 配置和校准（适配/编码 DID）
编码 DID 用于打开/关闭 ECU 的特定功能，以使其适应不同的 ECU 特定硬件平台或车辆系列。通常，在生产下线生产期间，应使用安全的变体编码写入顺序配置变体编码 DID，如下所示。
校准 DID 用于调整 ECU 操作，例如，在调整其配置以适应特定操作环境、其他车辆设备（传感器、执行器特性）等周围条件时,…写入校准 DID 序列可能类似于上述变体编码序列。
10. 诊断功能开发
在开发实际ECU项目的诊断功能时，应该如何执行？您可以参考下图。
这只是一个例子，具有不同工具链的不同项目可能会略有不同。但是，您仍然必须拥有：
- OEM诊断规范，项目相关诊断规范⟹要求，并以开放诊断交换（ODX）格式的数据库文件（如.cdd，.pdx，.odx）实现
- 用于查看/修改ODX文件或可能将文件内容解析为相应配置数据的开发工具⟹配置经典AUTOSAR模块，如DEM，DCM，FIM。
- 诊断应用程序 （SWC） 的设计和实现。
- 诊断测试工具，用于解析 ODX 文件以手动或自动化创建验证环境 ⟹ ODX 文件用作 V&V 操作的参考数据。
总结
参考链接（包括但不限于）：
https://nvdungx.github.io/unified-diagnostic-protocol-overview/
题外话
以上就是今天要讲的内容，如果您觉得文章还不错，还请您给个三连加关注，非常感谢！
本文作者：WeSiGJ
欢迎加入技术交流群：
QQ群：701203462
475
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
