UDS诊断详解（1）

概述UDSUnified Diagnostic Services统一诊断服务诊断协议是ISO 15765和ISO 14229定义的一种汽车通用诊断协议位于OSI模型中的应用层。这种协议可以在不同的汽车总线如CAN 、LIN、Flexray、Ethernet、K-line等上实现目前已成为汽车领域广泛使用的车载诊断协议标准。UDS诊断服务的主要目的是能够快速、准确地判断车辆或某个控制器的故障及其原因为维修提供可靠的依据。它允许工程师在不拆卸车辆的情况下通过诊断仪连接到汽车的OBD端口读取车况信息从而定位并解决存在的问题。这一功能对于提升车辆维修的效率和准确性至关重要。UDS诊断服务包含多种功能如诊断会话控制、ECU重置、读取故障码、清除故障码、读取数据标识等。诊断会话控制服务用于建立和管理诊断会话包括默认会话、扩展会话、生产商会话等。ECU重置服务则用于将车辆的电子控制单元ECU重置到初始状态。读取和清除故障码服务使得工程师能够方便地获取和清除存储在ECU中的故障信息。读取数据标识服务则用于获取ECU中的实时数据参数如传感器值、状态信息等。UDS诊断服务的优势在于其标准化 和高效性。标准化的诊断技术使得车辆制造商能够将其直接集成到ECU中提高了车辆的性能和效率。同时UDS诊断服务能够快速、准确地完成诊断过程减少误判提高诊断效率。此外通过UDS诊断服务工程师还可以获取车辆的实时数据实时监测车辆的运行状态为优化车辆性能、提高安全性和降低维修成本提供有力支持。一、通信协议架构UDSUnified Diagnostic Services统一诊断服务在OSIOpen Systems Interconnection开放系统互联七层参考模型架构中位于应用层。OSI七层参考模型是网络通信领域的一个基础框架它定义了网络系统中的各个层次及其功能从物理层到应用层逐层封装和解封装数据确保数据在网络中的可靠传输。在OSI七层模型中应用层是最高层它为用户的应用程序提供网络服务。UDS诊断服务作为汽车诊断领域的一种应用层协议其主要职责是提供对车辆电子控制单元ECU的诊断和通信功能。通过UDS诊断仪可以与车辆ECU进行交互发送诊断请求并接收诊断响应从而实现对车辆故障的检测和定位。UDS在应用层的工作涉及多个方面。首先它定义了一套标准化的服务请求和服务响应机制使得诊断仪能够按照预定义的格式发送请求报文并接收ECU返回的响应报文。这些报文包含了诊断所需的各种信息如故障码、传感器数据等。其次UDS还负责处理诊断过程中的安全性和可靠性问题。它采用了加密和认证机制确保诊断数据的机密性和完整性同时通过错误检测和恢复机制UDS能够在诊断过程中发现并纠正潜在的通信错误。在OSI模型中应用层之下是网络层、传输层、数据链路层和物理层。这些底层协议为UDS提供了必要的通信支持。例如数据链路层负责在物理线路上提供可靠的数据传输确保UDS报文能够在车辆网络中正确传输网络层则负责路由选择和报文转发确保UDS报文能够到达目标ECU传输层则提供端到端的可靠传输服务确保UDS报文的完整性和顺序性。二、通信协议网络层关键机制说明流控状态 (FS)帧格式速查在UDS通信协议中单帧、首帧、连续帧和流控帧是四种主要的数据单元N_PDU它们各自扮演着不同的角色共同确保数据的可靠传输。单帧SF是一种简单的传输方式通常用于那些只需要一帧就能完成的数据传输任务如请求或肯定响应等。它的控制信息占用一个字节其中首个字节的前四位用于标识其为单帧后四位则用于表示后续的数据长度。首帧FF是发送的第一帧用于启动多帧传输过程。它的主要任务是告诉接收方有数据需要发送并且这些数据并未发送完毕。首帧的控制信息占用两个字节其中前两个字节的前四位标识其为首帧后十二位则用于表示此次多包传输的数据量。当发送方发送首帧后接收方会回应一个流控帧告知发送方是否可以继续发送以及一次最多能接收的数据量还有发送方接下来发送的连续帧之间的时间间隔要求。连续帧CF用于在多帧传输中发送后续的数据包。每一个连续帧都有一个序列号SN用于标识其在数据序列中的位置。从0到15循环计数当达到15后序列号会重新置为0。通过这种方式接收方能够按照正确的顺序重组数据。流控帧FC则用于控制数据传输的流程。它可以指示发送网络实体是否可以继续进行消息传输或者是否需要暂停或恢复连续帧的传输。流控帧还包含有关接收缓冲区大小的信息以便发送方知道在何时需要停止发送数据以避免缓冲区溢出。此外流控帧还定义了连续帧之间的最小允许时间间隔以确保接收方有足够的时间处理每一个接收到的数据包。准备好Ready此时流控状态参数FS为0表示接收端准备好等待发送端声明的最大连续帧数。这通常意味着接收端有足够的缓冲区空间来接收接下来的数据并期待发送端继续发送连续帧。等待Wait流控状态参数FS为1表示接收端需要发送端等待一个新的流控帧。这可能是因为接收端的缓冲区即将满或者因为其他原因暂时无法接受更多的数据。流控溢出Overflow流控状态参数FS为2表示接收端的流控发生溢出这通常是由于发送端发送数据过快接收端无法及时处理而导致的数据堆积。此时发送端应停止发送数据等待接收端处理完现有数据并发送新的流控帧。发送方发送一帧首帧10 40接收方回复流控帧30 02 0A流控状态为0表示接收方已经准备好接收数据你可以发数据给我了。但是一次我只能接收两帧数据及BS 2并且允许你的连续帧以最小间隔10ms的周期发送给我即stime 0xA10。接下来就是发送方开始以最小间隔10ms周期发送连续帧。这里有一点需要注意每个新的连续帧的SN应设置为1当SN达到15后下一个循环的CF的SN应设置为0而不是1。重要注意事项流控帧 FC 不影响 SN 计数SN 的递增是连续的不受中间插入的 FC 帧影响BS (Block Size) 的作用当 BS ≠ 0 时发送方每发送 BS 个连续帧后必须等待接收方发送新的 FC 帧才能继续STmin 的单位0x0A 10表示 10ms0x00-0x7F 范围单位为 ms最后一个 CF 可以不满 7 字节最后一帧的数据长度可以小于 7 字节不需要填充四种帧类型详解、多帧传输流程详解时间参数及解析完整多帧传输示例场景发送 22 字节数据0x10 0x01 [19字节数据...]三、通信协议应用层参数定义1. P2CAN_Tester / P2CAN_Client2. P2CAN_Tester / P2CAN_Client关键点收到 0x78 后诊断仪必须重置计时器为 P2* 的 5500ms而不是继续使用 P2 的 100ms。3. P2CAN_ECU / P2CAN_ServerECU 必须在 50ms 内响应否则诊断仪可能认为超时。如果 ECU 需要更长时间应先发送 NRC 0x78。4. P2CAN_ECU / P2CAN_Server5. P3CAN_Tester_Phys / P3CAN_Client_Phys6. P3CAN_Tester_Func / P3CAN_Client_Func完整会话时序示例NRC 0x78 的完整机制服务格式物理寻址点对点根据物理地址的不同进行访问只能访问单个ECU节点。功能寻址广播根据功能的不同进行访问可以访问多个ECU节点。