在汽车领域，当车辆出现故障时，了解其具体原因和状态至关重要，以便我们能够采取有效的维修措施。术语“诊断”是指车辆电子控制单元（ECU）提供服务（输出车辆的状态信息），然后我们可以请求这些服务来了解车辆的状况、症状和问题并进行维修或配置。诊断协议UDS服务就提供这样的标准方法。本文将简要介绍汽车行业的OEM都使用的UDS服务（Unified Diagnostic Services Protocol，统一诊断服务）。 1 诊断和使用 车辆诊断的主要目标是检测和查询电子控制单元（ECU）的故障，更新ECU软件，与ECU硬件进行交互（如控制IO引脚的开关使能），以及执行自检操作。 外部诊断工具通过诊断插头/端子连接到车辆ECU，并通过UDS等诊断协议进行通信。诊断服务在车辆的整个生命周期内用于各种用例，比如开发测试和验证，产线和售后服务等。对于软件开发，诊断功能主要用于测试和验证。
除了提供外部诊断工具的离线诊断服务外，车辆在运行过程中还会进行在线的自我诊断。
2 诊断OSI模型
UDS协议标准规范由国际标准化组织（ISO）在ISO 14229中定义，共分为8个部分。本文主要关注第1部分（应用层）和第2部分（会话层服务），其余部分特定于不同类型的传输介质（即CAN、以太网、Flexray等）。 ISO 14229-1：规定了诊断服务的独立于数据链的要求，允许诊断测试人员使用诊断仪等设备（客户端）控制ECU（服务端）中的诊断功能，例如诊断仪连接到嵌入道路车辆的串行数据链的电子燃油喷射、自动变速箱和防抱死制动系统等。 ISO 14229-2：规定了通用会话层服务和要求，以提供统一诊断服务（ISO 14229-1）和所有传输协议和网络层服务（例如ISO 13400-2 DoIP、ISO 15765-2 DoCAN、FlexRay上的ISO 10681-2通信、ISO 14230-2 DoK-Line和ISO 20794-3 CXPI）之间的独立性。 ISO 14229-3：规定了在道路车辆的CAN（UDSonCAN）上实施一组通用的UDS服务。 此外，还有一些关于OBD的规范，其指定了排放相关服务和诊断故障码定义的信息。 ISO 15031-5 ：旨在满足美国和欧洲以及可能采用类似要求的任何其他地区的车载诊断（OBD）法规的数据报告要求。ISO 15031-6 ：为标准化诊断故障代码（DTC）提供了统一性，机动车辆的电气/电子车载诊断（OBD）系统在检测到故障时需要报告。OSI 诊断方案模型 3 UDS 协议的 运行机制3.1 客户端和服务端
客户端 ：通常称为外部测试设备，使用应用层服务请求在一个或多个服务端中执行诊断功能。客户端也可以是车辆中的ECU（车载测试仪），它能够向其他ECU执行诊断请求（即网关接收固件更新（FOTA）并请求刷新到车辆上的其他ECU）。服务端 ：通常是ECU或车辆功能（在多个ECU中分配），使用应用层服务将请求的诊断服务提供的响应数据发送回客户端。
协议概念
服务端应始终确认报文传输，这意味着对于客户端发送的每个服务请求，服务端应发送一个或多个相应的响应，无论是肯定的还是否定的。此规则的唯一例外是少数情况下使用，功能寻址或请求指定不应生成响应。
为了不给系统带来许多不必要的报文负载，在少数情况下，即使服务端未能完成请求的诊断服务，也不会发送否定响应消息。
3.2 协议数据单元结构 应用层诊断服务格式： 应用程序协议数据单
报文类型 远程诊断：来自/发送到测试仪客户端（[源地址]）的诊断服务请求/响应应通过网络网关组件（[目标地址]）（例如车辆网关 ECU）路由到目标诊断服务器（[远程地址]）。 源地址：发送诊断请求或响应的节点的逻辑地址。 子功能字节、数据标识符 ：DIDs、PIDs、RIDs是相似的，因为它是非易失性数据 （DID/PID） 或函数（可执行操作 RID）的逻辑表示。
UDS服务的CAN报文结构 一些UDS服务支持子功能（SF）以进一步定义SID的请求功能，比如ECU Reset，一些UDS服务支持数据标识符（DID）,即可通过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位ID（2.0A） 的CAN报文，有些仅支持29位 ID（2.0B）的CAN报文，诊断源和目标可以使用不同的报文寻址方案：
方案 例子 phys 请求：0x78A CAN ID包含源地址，第一个数据（有效载荷）字节包含目标地址。 1个CAN ID用于所有ECU的诊断请求：基址 源地址（tester），特定ECU的目标位于有效载荷数据中。 响应的每个ECU有1个CAN ID，ECU ID 在CAN ID中，tester ID在有效载荷数据中。 11 位：0xNss，数据：0xtt.... 格式：0x03FFttss 对于不同子网的ECU：CAN ID包含本地地址，其中1个是网关地址; 0x0CEAggss，数据：0xtt...（0x0CEA 是物理寻址的基础）
gg：网关地址, ss：源地址, tt：目标地址, Nn：任何。关于寻址方案的详细信息都可以在 ISO 15765-2 中阅读。 3.3 报文计时 对于UDS的会话层，除了在通信期间处理请求/响应的时间外，没有特殊操作。一般来说，必须配置以下定时器： P2客户端 ：客户端在成功传输请求报文后等待直到传入响应报文开始的超时值。 P2Client_max：是 P2Client 的初始/默认值 P2*Client_max：增强了客户端在收到否定响应报文后等待的超时时间，否定响应代码为 0x78（requestCorrectlyReceived-ResponsePending） 以开始下一条传入响应报文。 S3客户端时间 ：诊断客户端（=tester）在发送测试人员存在请求之前应等待的时间。 P2Server_max：服务端处理请求并及时发回响应，或者请求处理仍在进行并且发生超时（P2Server_max值），然后服务端发回一个NRC=0x78的否定值，用于“requestCorrectlyReceived-ResponsePending”，以通知待处理的最终响应。
P2*Server_max：发送负响应代码0x78的负响应报文后，服务端启动的性能要求。如果服务端仍无法在增强的P2*Server_max 中提供所请求的报文，则应再次发送带有否定响应代码0x78的进一步（时间数取决于配置）否定响应报文。
如果请求安排定期响应，则表示接受或不接受安排定期响应请求的初始未确认分段数据传输正面或负面响应应被视为最终响应。如果 P4Server_max 与 P2Server_max相同，则表示该服务或数据不允许使用否定响应代码0x78的否定响应。 P4Server_max：是 P4服务器时间的最大值。
如果在开发中使用Vector软件工具链，则用于诊断的底层CAN TP协议的配置通常可以在 .cdd（CANdela Diagnostic Description）文件中建立，操作如下所示：
关于ECU ID和CAN TP配置，有关这些配置参数的更多信息，请参见 ISO 15765-2 诊断会话层配置：会话计时器、客户端/服务端报文性能/超时计时
CANdela 诊断配置 4 UDS服务 4.1 UDS 服务列表 诊断会话控制服务（0x10） ：用于控制诊断会话的启动和停止。安全访问服务（0x27） ：用于解锁ECU访问，访问受保护的功能。身份验证服务（0x29） ：用于基于证书的PKI验证。读取数据服务（0x22） ：用于读取ECU中的数据。读取故障码服务（0x19） ：用于读取存储在ECU中的故障码。
4.2 举例：诊断会话控制服务操作
1）常规服务处理
对于所有服务请求都是强制性的，其验证步骤如下图所示。根据具体实施的选择，并非所有NRC检查都是必需的。 2）通用服务子功能处理
所有带子功能参数的请求服务都必须处理，其验证步骤如下图所示。 一般服务子功能办理流
1：至少 2个参数（SID和SubFunction） 以诊断会话控制服务 （0x10） 的特定处理操作为例，如下所示： 5 会话管理 服务端中应始终只有一个诊断会话处于活动状态，服务端在通电时应始终启动默认会话。如果未启动其他诊断会话，则只要服务端通电，就运行在默认会话。 非默认诊断会话中的诊断服务和诊断功能集是默认会话提供的功能的超集。
>在默认的扩展会话中执行诊断服务时，应保持ECU的正常运行。 在默认会话中停止ResponseOnEvent（0x86）配置的所有事件。 安全访问应重新锁定，安全访问的锁定应重置所有诊断功能，这些功能取决于解锁的安全访问。 ResponseOnEvent（0x86）的反应式事件。 默认会话中不支持的任何其他主动诊断功能都将被终止。 S3服务器计时器<超时会话：服务端在不接收任何诊断请求报文的情况下保持默认会话以外的诊断会话处于活动状态的时间。 6 安全访问和身份验证 0x27服务 ：客户端使用种子密钥进程解锁ECU访问，访问受保护的功能，比如与内存修改、编程相关的特定例程。 0x29服务 （2020年发布的新功能）：测试人员使用基于证书的PKI验证其角色，可能需要连接/访问OEM服务器以获取证书。 6.1 安全访问操作
0x27服务 提供了一种访问数据/诊断服务的方法，这些服务/诊断服务出于安全、排放或安全原因而限制了访问。不正确的例程或下载到服务器中的数据可能会损坏电子设备或其他车辆组件，或危及车辆符合排放、安全或安保标准。 因此安全访问使用种子和密钥关系（非对称）。要记住的另一件事是：使用AUTOSAR，只有一个安全访问级别状态机，独立于测试端与ECU的通信方式（即ECU安全访问通过 CAN连接打开，然后另一个测试端可以通过 DoIP连接直接进行安全访问，而无需重新请求安全访问）。 6.2 身份验证
0x29服务的目的与0x27服务相同，通过用户角色（供应商、开发、售后,...）而不是 0x27 级别进行授权。0x29 服务的安全概念是基于： PKI证书交换和使用非对称加密（在AUTOSAR 4.4.0中引入）。
无PKI和非对称或对称加密的质询-响应（超出AUTOSAR的范围，需要在DCM中自定义实现）。
使用AUTOSAR时，每个物理连接的身份验证状态机。
7 故障和DTC
如果ECU在运行过程中发生任何故障，它将存储这些故障代码、故障状态、快照数据和一些扩展数据记录，这将有助于诊断工程师轻松了解根本原因并修复车辆。
故障存储：ECU运行期间故障相关信息的存储位置，稍后在OFF Board诊断操作期间由测试人员读取。 故障代码的属性（诊断故障代码 - DTC）：DTC定义映射到诊断事件（DEM）的唯一标识符，稍后可由测试人员（通过 DCM）查询。
第一个字节应表示故障位置，基本上是ECU在车辆中的位置（例如动力总成、车身,..）以及此DTC是否由ISO规范或制造商定义。 最后一个字节表示故障类别和子类型，详细说明发生了哪种故障。 1）DTC状态字节：
2）DTC快照：是与DTC关联的特定数据记录（DID），存储在服务器内存中。DTC快照的典型用途是在检测到系统故障时存储数据，DTC快照将充当系统故障发生时数据值的快照。
3）DTC扩展数据：用于存储与DTC关联的动态数据（统计信息），比如：
DTC B1故障指示器计数器，用于表示在故障处于活动状态时OBD系统运行的时间（发动机运行小时数）。
DTC发生计数器，对报告了 “testFailed” 的驾驶循环次数进行计数。
DTC老化计数器，计算自上次故障失败以来的驾驶循环次数，不包括测试未报告 “testPassed” 或 “testFailed” 的驾驶循环。
OBD的特定计数器（例如，如果可以在无故障模式下执行驾驶循环，则在“检查发动机”灯关闭之前的剩余驾驶循环次数）。
上次出现的时间（等等）。
测试失败计数器，如果分多个步骤执行验证，则对报告的 “testFailed” 和可能的其他计数器进行计数。
未完成测试计数器，对自最近一次完成测试（即自测试报告“testPassed”或“testFailed”）以来的驾驶循环次数进行计数。
Vector CANDelaStudio，故障存储配置
为了检索DTC信息，可以使用UDS 0x19服务 ：
7.2. 数据标识符 数据标识符（DID）是用于寻址ECU内存中可用的特定数据存储位置的逻辑编号。DID用于各种诊断用例，例如： 通常，某些DID应配置为与特定DTC相关，并在记录DTC时存储其值的快照。 8 刷写/烧录 在刷写操作中，应使用诊断服务列表来提供定义的序列/接口，用于处理软件更新过程（即预编程状态转换、通信接口准备、将接收到的数据传输和编程到闪存中）。 应用程序和引导加载程序软件之间的状态转换
触发从Application到Reprogramming状态的转换。 从Tester实体下载更新的软件（分成多个数据包）。 编程序列分为两个编程阶段。 应用程序数据 编程阶段 2（可选）：可由FBL触发，并在ECU启动到应用程序时执行，例如： 适配，在完成应用程序软件更新后，需要将DID写入ECU。 以下是在编程操作（阶段 1）期间应调用的诊断服务的示例序列。 预编程检查：当ECU在应用程序中或FBL检查时触发，控制ECU/车辆的编程条件状态。 编程后检查：当ECU在应用程序或FBL中重新启用正常通信时，可能会触发诊断事件监控。 9 配置和校准（自适应/编码DID） 编码DID用于打开/关 ECU 的特定功能，使其适应不同的ECU特定硬件平台或车辆系列。通常，变体编码DID应在生产线末端生产期间使用安全的变体编码写入序列进行配置，如下所示。 变体编码写入序列示例
标定DID用于调整ECU操作，例如，当其配置适应周围条件时，例如特定的操作环境、其他车辆设备（传感器、执行器特性）,...写入校准 DID 序列可能类似于上述变体编码序列。 10 诊断功能开发 在开发实际 ECU 项目的诊断功能时，应该如何执行？可以参考下图。这只是一个例子，具有不同工具链的不同项目可能略有不同，但仍然必须具备： OEM诊断规范、项目相关诊断规范 ⟹ 要求，并以 .cdd、.pdx、.odx 等开放诊断交换 （ODX）格式数据库文件实现 用于查看/修改ODX文件或可能将文件内容解析为相应配置数据 ⟹ 经典AUTOSAR模块（如 DEM、DCM、FIM）的配置。 诊断测试工具用于解析ODX文件以手动创建验证环境或自动化⟹ ODX文件用作V&V操作的参考数据。 使用 Vector 工具链开发诊断功能的示例
创作不易，欢迎点赞再看收藏关注 ！
汽车研发交流群，有兴趣的朋友请添加群主：prOmiseyes，备注：公司 职务入群。仅限汽车从业人员
子功能字节、数据标识符
