车载诊断框架 --- UDS小白入门篇

我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

所有人的看法和评价都是暂时的，只有自己的经历是伴随一生的，几乎所有的担忧和畏惧，都是来源于自己的想象，只有你真的去做了，才会发现有多快乐。人就应该满脑子都是前途，不再在意别人的看法不再害怕别人讨厌自己，不再畏手畏脚忧心忡忡也不会在睡前反回忆白天的行为，是否让对方产生误解用你那精神内耗的态度去搞学习搞事业搞钱，然后用躺平和摆烂的态度对待人际关系，烦恼能消失一大半。
无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事.而不是让内心的烦躁、焦虑、毁掉你本就不多的热情和定力。

时间不知不觉中，快要来到深秋。国庆假期结束，又开始新的忙碌。成年人的我也不知道去哪里渡自己的灵魂，独自敲击一些文字算是对这段时间做一个记录。

一、UDS很简单却总学不会？

在汽车电子领域，UDS（Unified Diagnostic Services，统一诊断服务）是一项至关重要的技能。然而，许多初学者甚至多年工作经验的老工程师都发现难以精准掌握这一技能。这可能是因为你的学习方法存在问题。为了帮助大家更有效地学习UDS，我们将从三个方面进行深入探讨：UDS是什么、如何发送UDS请求、以及如何在AUTOSAR框架中实现UDS（这部分将在后续文章中讲解）。

搞明白这三个问题，轻松掌握UDS；

是什么？（ISO14229-1）

UDS是基于ISO 14229-1标准的一套诊断服务协议，它定义了汽车电子控制单元（ECU）之间的通信规则。这套协议不仅涵盖了诊断会话控制、安全访问等基本功能，还包括了数据读写、输入/输出控制等高级功能。因此，对于汽车电子开发者来说，理解UDS协议是设计和开发汽车电子系统的基础。

为了深入学习UDS，你需要熟悉ISO 14229-1标准的各个部分，包括其定义的服务、子功能、参数以及相关的诊断会话状态机。同时，你还应该了解UDS协议与其他相关标准（如ISO 15765-2）之间的关联，以便在实际应用中更好地使用UDS。

怎么发？（ISO15765-2）

在汽车电子系统中，UDS请求通常是通过网络（如CAN总线）发送的。ISO 15765-2标准定义了如何在基于CAN的网络中传输诊断数据。这个标准采用了网络传输层协议（N_WL_TP）来确保数据的可靠传输。

为了发送UDS请求，你需要了解ISO 15765-2标准的各个细节，包括数据帧的构成、传输超时机制、错误处理流程等。此外，你还需要掌握如何使用诊断工具（如CANoe、Vector CANalyzer等）来发送和接收UDS请求。这些工具通常提供了图形化的用户界面和丰富的诊断功能，可以帮助你更好地理解和使用UDS协议。

在实际操作中，你可以通过以下步骤来发送UDS请求：

-> 配置诊断工具：选择正确的CAN通道、波特率等参数。

-> 建立诊断会话：发送一个诊断会话控制请求来启动或停止诊断会话。

-> 发送UDS请求：根据ISO 14229-1标准，构建并发送相应的UDS请求。

怎么做？（AUTOSAR Dcm, Dem）

我们主要讨论了UDS协议的基本概念以及如何通过ISO 15765-2标准发送UDS请求。然而，对于软件工程师及对软件感兴趣的朋友来说，如何在AUTOSAR框架中实现UDS同样重要。

在后续的文章中，我们将深入探讨AUTOSAR中的DCM（Diagnostic Communication Manager）和DEM（Diagnostic Event Manager）模块，以及如何使用这些模块来实现UDS协议。我们将从软件架构、模块接口、配置参数等方面进行详细讲解，并提供实际案例来帮助大家更好地理解和应用AUTOSAR中的UDS实现方法

前两问适用于所有汽车电子开发者、管理者等，本篇文章将针对前两个问题展开描述。

第三问适用于软件工程师及对软件感兴趣的朋友，将在后续文章中讲解AUTOSAR中UDS的软件实现方法。

二、 UDS是什么？

UDS (Unified Diagnostic Services) 是一种用于车辆诊断和通信的标准化协议，它是ISO 14229标准的一部分，也被称为UDS协议或UDS服务。UDS协议定义了一系列的服务和子服务，用于在诊断设备和车辆ECU（电子控制单元）之间进行通信，以执行各种诊断任务，如读取和清除故障码、配置ECU参数、请求和设置数据等。

车载诊断非常类似医生与病人的关系。

本质上讲，UDS就是服务于Client与Server之间用于信息交互的标准协议。

什么是Client与Server？

Client：外部诊断设备，如诊断仪、CANoe等

Server：车身电子件（ECU）

诊断的最基本的内容其实就是请求和响应，请求即由Client端发出的数据指令，响应为由Server端返回的数据信息；搞明白UDS，最先需要搞明白请求和响应的通用格式，即做到一通百通。

掌握通用格式，即掌握所有

所有的UDS指令都直接套用如下请求和响应格式

请求格式：

响应格式：

正响应

负响应：

【例子1】：

请求：10 01（“10”为Request SID，“01”为Sub function）

响应（正）：50 01 00 32 01 F4（“50”为Response SID，“01 00 32 01 F4”为data-parameter）

【例子2】：

请求：22 F1 90（“22”为Request SID，“F1 90”为data-parameter）

响应（正）：62 F1 90 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10（“62”为Response SID，“F1 90 00……0E 0F 10”为data-parameter）

具体的服务该怎么看？

理解了如上通用的诊断格式后，非常简单的学习服务的方法，一般情况仅仅需要从字面意思既能了解内涵；本文以10服务为例展开描述，其余服务大家可以自行查阅ISO14229-1。

DiagnosticSessionControl (10 hex) service

10服务的字面意思就是Session控制。

UDS 10服务用于控制ECU（电子控制单元）在不同诊断会话之间的切换。在车辆诊断过程中，诊断仪与ECU之间需要建立通讯会话，以执行各种诊断任务。UDS 10服务允许诊断仪通过发送请求报文来控制这些诊断会话的建立、切换和结束。

它允许诊断仪通过发送请求报文来建立、切换和结束与ECU之间的诊断会话，从而执行各种诊断任务。UDS 10服务支持多种会话类型和控制类型，以满足不同的诊断需求。

DiagnosticSessionControl (10 hex) service请求（来源：ISO14229-1）

10服务，请求长度固定为2个字节，第一个字节为SID 10，第二个字节为子功能；

正响应中除了DataByte#1 为Response SID和 DataByte#2 diagnosticSession外，sessionParamaterRecord的参数格式可以参考客户需求规范。

UDS 10服务支持多种会话类型，较为常用的几个子功能服务为：

默认会话（01 Default Session）：上电/远程ECU初始化后，完成初始化的ECU默认启动默认会话模式。这是基础状态，不需要任何诊断应用程序的在线服务来保持此模式激活。

扩展会话（03 Extended Session）：此状态支持在ECU存储器中进行操作，如#2E写服务、#28通信控制、#31例程等操作。

编程会话（02 Programming Session）：此会话下支持ECU内存编程操作，一般在此会话下执行bootloader操作。

DTC相关内容

DTC（Diagnostic Trouble Code，诊断故障码）是指车辆电子控制单元（ECU）存储的车辆故障代码，它是一种数字编码，用于标识车辆的故障问题。

车辆在运行过程中ECU会持续监控车辆运行状态，检测到故障时，它会记录相应的DTC，并将其存储在车辆的故障存储器中。通过读取故障存储器中的DTC，可以快速确定车辆的故障问题，并采取相应的修复措施。

DTC Status

DTC状态为1个字节，包含8个Bit的状态。基本上可以直接翻译从字面意思即可理解含义；详细的可以参见ISO14229-1附录。

与DTC相关的诊断服务

1. DTC状态更新控制ControlDTCSetting (85 hex) service

UDS 85服务，字面意思为控制诊断故障代码设置服务，是UDS协议中的一个重要部分，该服务用于停止或继续ECU中DTC状态位的更新。

客户端可以指示ECU停止或继续更新DTC状态位。这在某些特殊场景下非常有用，例如在ECU刷写过程中，为了避免因刷写操作导致的DTC误报，可以临时停止DTC状态位的更新。

ControlDTCSetting (85 hex) service（来源：ISO14229-1）

2. DTC信息的读取ReadDTCInformation (19 hex) service

UDS 19服务，字面意思即读取诊断故障代码信息（DTC），是UDS协议中的一个重要组成部分，用于读取诊断故障代码（DTC）相关信息。

UDS 19服务允许诊断仪/上位机从车辆内的任何ECU（电子控制单元）读取故障诊断码（DTC）信息的状态。

在ECU运行过程中如检测到故障，会记录对应的故障码，并根据故障严重及危害程度确定是否需要点亮仪表盘的发动机故障灯。

UDS 19服务包含28个子服务（Sub-Function），每个子服务都有其特定的功能，常用的几个服务如下：

01子服务：读取符合掩码条件的DTC数量。这里的掩码由客户端定义，可以指定读取当前故障、历史故障或全部故障。

02子服务：读取符合掩码条件的DTC列表及其状态。同样，掩码的定义与01子服务相同。

04子服务：读取DTC快照信息，即与DTC关联的已存储数据记录。这些数据可以帮助工程师在ECU出现故障时了解车辆的历史和实时故障信息。

06子服务：读取扩展信息，包括DTC状态、优先级、发生次数、时间戳、里程等。

0A子服务：读取ECU支持的所有DTC列表及其状态，此服务不需要掩码。

3. DTC的清除ClearDiagnosticInformation (14 hex) service

UDS 14服务的字面意思就是清除存储的故障诊断信息，这些信息可以是某一个特定的故障码（DTC），也可以是某个类别的故障诊断码（如动力总成、车身、底盘等），甚至是所有的故障诊断码。

03、UDS怎么发？

我们所常用的CAN/LIN诊断报文消息只有8个Byte长度，而上文描述的请求和响应多则几十个的Byte，本章节将阐述诊断消息如何收发；

CAN诊断由发送端的请求与接收端的响应构成，诊断即为发送端与接收端数据往来。有的诊断一条消息完成，有的诊断需要多条消息完成，毕竟在诊断中，一条CAN消息只包含8个字节长度。对于一条CAN诊断消息的分段发送问题，即为网络层需要讨论的内容。

网络层的作用可以看作是把CAN诊断通信上层需要传输的数据进行封装准备发送的过程，若数据量小于等于7个字节数据（本文只讨论正常地址模式），则用单帧发送，数据量大于7个字节数据（ISO 15765规定最大传输数据量为4095个字节），则用多帧发送。网络层的作用就好比一堆货物准备发货，货物量少，即使用一辆车托运，货物量多，则需要使用多辆车进行托运。

如下图所示，当需要传输的字节小于等于7个字节时，网络层只需将数据封装成一个单帧发送即可；

单帧数据收发（来源：ISO15765-2）

当需要传输的字节大于7个字节时，网络层需要将数据封装成一个首帧加若干个连续帧，然后再发送。

请求10 01

响应 50 01 00 32 00 C8

请求和响应长度都在单帧范围内，则消息Trace中报文序列为：

请求 710：[02] 10 01 [00 00 00 00 00]

响应 720：[06] 50 01 00 32 00 C8 [AA]

请求22 F1 90

响应 62 F1 90 31 32 33 34 37 38 20 20 20 20 20 20 20 20 20 20 20

请求在单帧范围内，响应长度需要使用首帧+连续帧传输，则消息Trace中报文序列为：

请求 710：[03] 22 F1 90 [00 00 00 00]

响应 720：[10 14] 62 F1 90 31 32 33

响应 720：[21] 34 37 38 20 20 20 20

响应 720：[22] 20 20 20 20 20 20 20

04、如何快速学UDS？

4.1推荐的学习技巧

自己尝试编辑诊断调查问券文件，有条件的同学可以编辑CDD文件

使用CANoe（或其余设备）调试诊断请求和响应，观察Trace报文

按照诊断需求，软件改写简单指令，并测试验证

诊断服务列表

DID列表

DTC列表

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者