简介：统一诊断服务（UDS）协议栈的C语言实现源码，面向汽车电子、嵌入式诊断与ECU软件开发者，用于理解并落地ISO 14229诊断协议中的服务定义、传输层分包、诊断会话与安全访问机制。压缩包共十五个文件，总大小二十KB，主要包含四个C源文件、三个头文件，以及生成程序脚本、自动化测试脚本、说明与变更记录等文档，目录组织覆盖源码实现、单元测试与传输层依赖模块，结构紧凑，便于快速定位关键逻辑。目前已有三千九百二十四人学习下载。开发者可通过该工程研读统一诊断服务中读数据、写数据、安全访问、编程会话等服务的请求响应帧格式和负响应错误码处理流程；结合传输层依赖组件可理解控制器局域网上长消息的分包、重组与流控机制。项目附带的测试脚本和构建配置支持直接运行验证，便于按实际诊断场景进行二次开发、功能裁剪或移植到自有工具链，是学习该协议的细节并落地到车载诊断实践的实用参考。

1. UDS（ISO14229）协议源码：诊断协议不是代码拷贝，是时序契约

UDS（ISO14229）协议源码.zip 这个名字，容易让人误以为拿到手就是一个开箱即用的诊断协议栈。但移植过就知道，真正花时间的不是把 .c 文件编进工程，而是搞懂 ISO14229 里那套会话、服务、超时规则：0x10 请求为什么有时候回 0x50、有时候弹 NRC？ECU 的 P2 定时到底该设多少？0x27 安全访问的种子为什么不能写死？这篇笔记从源码包结构讲起，拆服务分发、CAN 收发、定时参数和安全访问的实现位置，最后给出避坑清单和 Python 自动化验证脚本。适合正在做车载 ECU 软件、诊断测试台架或售后工具的工程师。

2. 拆解 ISO14229 源码包：服务层、传输层与配置层的边界在哪

拿到 zip 之后我一般先不急着编译，而是花半小时把目录结构捋一遍。UDS 诊断协议栈源码通常按三层组织：服务层放 0x10、0x22、0x2E、0x27 这些诊断服务的实现，传输层管 ISO-TP 的多帧收发和 CAN 报文封装，配置层放 P2 定时、S3 超时、会话状态表和 NRC 处理策略。先搞清三层边界，后面改代码才知道该动哪一层，而不是在服务文件里翻半天找定时参数。

2.1 三层文件结构，先搞清谁负责什么再动手改

很多源码包的文件命名并不统一，有的叫 uds_serv.c，有的叫 diag.c，但核心职责跑不掉。我见过的最小可跑版本只有三个 .c 文件加一个 uds_cfg.h：uds_services.c 集中放各个服务 ID 的分发函数，uds_transport.c 做 CAN 收发粘合和 ISO-TP 拼装，uds_app.c 留给用户补全读写 DID、掉电存储这些硬件相关回调。uds_cfg.h 则是全局参数开关，几乎所有要调的参数都先来这里。

/* uds_cfg.h - 协议栈配置头文件，移植时第一个要动的文件 */ #ifndef UDS_CFG_H #define UDS_CFG_H /* 最大支持的诊断会话数量（默认会话 + 扩展 + 编程） */ #define UDS_MAX_SESSION 3U /* P2 定时：ECU 响应超时，ISO14229 默认 50ms */ #define UDS_P2_TIMEOUT_MS 50U /* P2* 定时：P2 超时后等待最终响应，默认 5000ms */ #define UDS_P2STAR_TIMEOUT_MS 5000U /* S3 会话保持时间，超过则回默认会话 */ #define UDS_S3_TIMEOUT_MS 5000U /* 物理寻址请求与响应 CAN ID，按整车 CAN 矩阵填写 */ #define UDS_PHYS_REQ_CAN_ID 0x7E0U #define UDS_PHYS_RESP_CAN_ID 0x7E8U #endif

这段配置决定了协议栈的行为边界。UDS_P2_TIMEOUT_MS 表示 ECU 收到诊断请求后必须在 50ms 内给出首帧或 NRC，否则诊断仪会报超时；UDS_S3_TIMEOUT_MS 控制在非默认会话里的驻留时间，刷写流程里经常被标定到 5 秒以上，避免两帧请求间隔稍长就被踢回默认会话。CAN ID 按整车矩阵填，物理寻址通常是 0x7E0/0x7E8，功能寻址是 0x7DF，这个后面避坑章节还会专门提。

2.2 服务分发机制：从 CAN 报文到 UDS 响应的代码路径

UDS 请求帧格式很直接：第一位是服务 ID，后面是服务参数。但 CAN 报文长度受限，超过 8 字节的诊断消息必须走 ISO-TP 多帧传输，所以协议栈收包时先做 CAN 协议报文解析，判断帧类型，再拼接完整诊断消息，最后交给分发函数。这一层的代码质量决定协议栈的稳定性，很多偶发超时问题就出在接收路径上。

/* uds_transport.c - CAN 接收入口，完成帧类型判断与消息拼装 */ void uds_can_rx_handler(uint32_t can_id, uint8_t *data, uint8_t dlc) { uint8_t pci_type = data[0] >> 4; if (pci_type == 0x0U) { /* 单帧：一帧就是完整请求 */ uds_service_dispatch(&data[1], dlc - 1U); } else if (pci_type == 0x1U) { /* 首帧：多帧传输开始 */ uds_isotp_start_reception(data, dlc); } else if (pci_type == 0x2U) { /* 连续帧：继续拼装 */ uds_isotp_continue_reception(data, dlc); } else { /* 0x3 为流控帧，正常只由发送方解析，这里忽略 */ } }

这里的 pci_type 是 ISO-TP 报文解析的关键：高四位 0 是单帧，1 是首帧，2 是连续帧，3 是流控帧。踩坑点在于，有的源码把流控帧也当成诊断数据丢进服务分发，结果协议栈收到一个“不存在的服务 ID”直接回 NRC 0x11。dlc 也要从 CAN 驱动一路透传，不能硬编码成 8，否则收到 CAN FD 或短帧时拼接会错位。

分发函数在服务层里，负责把请求按服务 ID 路由到具体实现。这里的 switch-case 是简化版本，实际工程里还会考虑服务是否在当前会话可用、安全访问是否已解锁。

/* uds_services.c - 服务分发主函数，所有诊断请求的入口 */ uint8_t uds_service_dispatch(uint8_t *req, uint8_t len) { uint8_t nrc = 0x00U; switch (req[0]) { case 0x10U: /* 诊断会话控制 */ nrc = uds_service_session_control(&req[1], len - 1U); break; case 0x22U: /* 按标识符读数据 */ nrc = uds_service_read_data(&req[1], len - 1U); break; case 0x2EU: /* 按标识符写数据 */ nrc = uds_service_write_data(&req[1], len - 1U); break; case 0x27U: /* 安全访问 */ nrc = uds_service_security_access(&req[1], len - 1U); break; default: nrc = 0x11U; /* ServiceNotSupported */ break; } if (nrc != 0x00U) { uds_send_nrc(req[0], nrc); } return nrc; }

分发逻辑本身不难，真正的坑是 NRC 优先级。ISO14229 要求先查会话状态、再查安全级别、最后查参数有效性，同一个请求在不同状态下可能返回不同的 NRC。源码里如果只做 default 兜底、不做会话判断，就会出现诊断仪已经发了 0x10 进入扩展会话、0x22 还是被拒的情况——查下来发现是分发函数根本没把会话状态传进来。

2.3 会话状态机与 NRC 响应策略：源码里最容易看晕的部分

会话状态机是 UDS 诊断原理的核心骨架。ISO14229 定义了默认会话（0x01）、编程会话（0x02）、扩展会话（0x03）三种标准状态，0x10 服务负责在这些状态间切换。源码里一般用 uds_session 全局变量保存当前会话，分发函数在进 case 之前先查会话是否允许该服务。

/* uds_services.c - 0x10 会话控制实现 */ static uint8_t uds_session = 0x01U; /* 当前会话，默认会话 */ uint8_t uds_service_session_control(uint8_t *data, uint8_t len) { uint8_t target_session = data[0]; if (target_session == 0x01U || target_session == 0x02U || target_session == 0x03U) { uds_session = target_session; /* 进入新会话先响应，再重置 S3 定时器 */ uds_send_response(0x10U, 0x50U, &target_session, 1U); uds_reset_s3_timer(); return 0x00U; } return 0x12U; /* SubFunctionNotSupported */ }

这段代码把 0x10 的正响应格式也带出来了：0x50 是 0x10 的正响应（请求服务 ID + 0x40），后面跟一个字节的目标会话。注意 S3 定时器要在状态切换后立刻重置，否则 ECU 刚响完 0x50 就因定时器溢出被踢回默认会话，诊断仪上看到的现象是“进得去但马上被弹出来”。NRC 0x12 对应子功能不支持，0x13 是长度错误，这两个值在会话控制里最容易混淆。

3. 把 UDS 源码移植到 MCU：CAN 驱动挂接与最小服务集裁剪

讲完源码结构，接下来是移植。很多项目初期只需要最基本的诊断服务，不需要把整个协议栈全量编译。移植时最常见的误区是把协议栈文件和 MCU 的 CAN 驱动揉在一起写，我习惯在驱动和应用之间留一层回调接口：CAN 驱动收到报文后调 uds_can_rx_handler，协议栈要发响应时调 uds_can_tx_frame。这样协议栈源码不关心底层是 STM32 的 bxCAN、NXP 的 FlexCAN 还是英飞凌的 MultiCAN。

3.1 CAN 收发接口对接：协议栈文件怎么和驱动解耦

收方向，把 CAN 驱动中断里的接收回调直接指向 uds_can_rx_handler；发方向，把协议栈里所有调用发送的地方集中到一个函数，再由这个函数调用板级 CAN 发送。这样一来，换 MCU 平台时只需要改一个文件，其他诊断逻辑完全不动。

/* uds_app.c - 发送接口封装，板级适配层 */ void uds_send_response(uint8_t service, uint8_t response_id, uint8_t *data, uint8_t len) { uint8_t tx_buf[8]; uint8_t tx_len = len + 2U; tx_buf[0] = response_id; /* 正响应 = 服务ID + 0x40 */ tx_buf[1] = service; memcpy(&tx_buf[2], data, len); can_tx_frame(UDS_PHYS_RESP_CAN_ID, tx_buf, tx_len); }

这里有一个容易翻车的细节：response_id 和 service 的顺序。ISO14229 正响应格式是“响应服务 ID + 正响应参数”，比如 0x10 的正响应首字节是 0x50。如果代码里先塞 service 再塞 response_id，诊断仪解析时会直接当成非法响应，之后会一直重试。tx_buf 后面没清空的字节保持为 0，CAN 驱动会按 DLC 发送，别复用上次的脏数据。

接收方向的代码在上一章已经给出。这里补充一个点：uds_can_rx_handler 要在 CAN FIFO 里尽快执行，不要在中断里做耗时操作。多帧拼装建议放到中断里只缓存原始帧、在主循环里做重组，否则 50ms 的 P2 定时很容易被中断竞争吃掉。

3.2 只保 0x10/0x22/0x2E：裁剪后需要改的五个配置项

裁剪思路是用条件编译把用不到的服务关掉。很多 UDS 源码已经支持功能开关，关键是开关打开后，配套的权限表、会话允许表、DID 读写表也要同步裁剪。

/* uds_cfg.h - 服务裁剪开关 */ #define UDS_ENABLE_SESSION_CONTROL 1U /* 0x10 */ #define UDS_ENABLE_READ_DATA 1U /* 0x22 */ #define UDS_ENABLE_WRITE_DATA 1U /* 0x2E */ #define UDS_ENABLE_SECURITY_ACCESS 0U /* 0x27，后期再加 */ #define UDS_ENABLE_ROUTINE_CONTROL 0U /* 0x31 */

/* uds_services.c - 裁剪后的分发函数 */ switch (req[0]) { #if (UDS_ENABLE_SESSION_CONTROL == 1U) case 0x10U: nrc = uds_service_session_control(&req[1], len - 1U); break; #endif #if (UDS_ENABLE_READ_DATA == 1U) case 0x22U: nrc = uds_service_read_data(&req[1], len - 1U); break; #endif default: nrc = 0x11U; break; }

除了编译开关，还有五个配套项要一起改：服务注册表（有的源码用函数指针数组）、DID 读写权限表、会话状态表中的服务允许列表、NRC 优先级顺序、安全访问级别限制表。这五个不改全，裁剪后会出现“编译过了但功能不完整”的玄学问题。比如把 0x27 关掉，但 DID 权限表里还要求写 DID 前先解锁，结果 0x2E 永远回 NRC 0x33（securityAccessDenied）。

3.3 移植后冒烟测试：三帧请求验证基础通路

移植完先手动发三帧验证，不要直接上全量用例。用 PCAN、CANalyzer 或周立功的 CAN 工具，按下面这张表依次发请求，观察响应。

第一帧验证会话切换和 S3 重置；第二帧验证 0x22 读数据通路；第三帧验证 NRC 通路。如果三帧行为都正确，基础通路就通了。如果第二帧返回 0x7F 0x22 0x31（didNotExist），先查 DID 表里有没有注册 F190；如果第一帧超时，优先查 CAN ID 过滤而不是协议栈逻辑。

4. UDS 定时参数和安全访问：P2/P2*、S3 与 0x27 的实现位置

UDS 诊断联调时，定时参数和安全访问是两大核心。定时参数管着“什么时候算超时”，安全访问管着“谁能解锁”。这两个模块在源码里位置隐蔽，直接搜索 P2、S3 或 SecurityAccess 关键字往往能找到，但理解它们怎么配合工作更重要。汽车 CAN UDS 诊断超时问题十有八九出在这两个地方。

4.1 P2/P2* 超时：Tester 与 ECU 两侧的定时器配置

P2 是 ECU 响应超时，P2* 是“服务执行中”的扩展等待时间。ISO14229 规定 P2 默认 50ms、P2* 默认 5000ms。ECU 侧的实现在定时器回调里，关键逻辑是区分“首帧响应”和“最终响应”：50ms 内能完成的请求直接回正响应；完不成的先回 NRC 0x78（responsePending），告诉诊断仪别急，然后启动 P2*，在 5000ms 内给出最终结果。

/* uds_app.c - P2/P2* 定时器回调，裸机 1ms tick 调用 */ static uint8_t pending_flag = 0U; static uint16_t p2_timer = 0U; static uint16_t p2star_timer = 0U; void uds_timer_1ms_tick(void) { if (pending_flag == 0U) { if (p2_timer > 0U) { p2_timer--; if (p2_timer == 0U) { /* P2 超时：未完成处理，先回 0x78 进入 P2* */ uds_send_nrc(0x78U); pending_flag = 1U; p2star_timer = UDS_P2STAR_TIMEOUT_MS; } } } else { if (p2star_timer > 0U) { p2star_timer--; if (p2star_timer == 0U) { /* P2* 也超时：复位诊断状态 */ uds_reset_session(); } } } }

注意一个细节：回 0x78 之后，pending_flag 要置位，服务完成时再清掉并发送真正的正响应。有的源码只在定时器里减计数，忘了pending管理，结果 P2 超时后每 50ms 回一个 0x78，诊断仪直接晕掉。Tester 侧也有一个响应超时参数，实车联调时 Tester 的 P2 不能设得比 ECU 短，否则 ECU 还没回，诊断仪先报超时。

提示：排查超时问题先分两侧。ECU 用示波器或 CAN 日志看物理响应时间，Tester 看自己配置的 P2/P2*，两边对齐了再动代码。

4.2 0x27 安全访问：种子-密钥流程在源码里的写法与防重放设计

0x27 是解锁诊断服务的门禁。流程是：Tester 发 0x27 01 请求种子，ECU 回种子（通常 4 字节），Tester 按约定算法算出密钥，发 0x27 02 带密钥；ECU 校验通过回 0x67 02，失败回 NRC 0x35（invalidKey）。失败次数过多会回 0x36（exceedAttempts），需要等待一段时间才能重试，回 0x37（requiredTimeNotExpired）。

/* uds_services.c - 0x27 安全访问简化实现 */ static uint8_t seed_buf[4]; static uint8_t try_count = 0U; uint8_t uds_service_security_access(uint8_t *data, uint8_t len) { uint8_t subfunc = data[0]; if (subfunc == 0x01U) { /* 请求种子 */ if (try_count >= 3U) { return 0x36U; /* 尝试次数超限 */ } /* 用真随机源生成种子，不能固定 */ uds_get_random_bytes(seed_buf, 4U); uds_send_response(0x27U, 0x67U, seed_buf, 4U); return 0x00U; } if (subfunc == 0x02U) { /* 发送密钥 */ uint32_t calc_key = uds_calculate_key(seed_buf, 4U); uint32_t recv_key = (uint32_t)data[1] << 24 | (uint32_t)data[2] << 16 | (uint32_t)data[3] << 8 | (uint32_t)data[4]; if (calc_key == recv_key) { try_count = 0U; uds_send_response(0x27U, 0x67U, &data[0], 1U); return 0x00U; } try_count++; return 0x35U; /* InvalidKey */ } return 0x12U; }

踩坑点有三个：种子必须是每次请求重新生成的随机数，不能写死，否则安全访问形同虚设；密钥校验通过后要把种子缓冲清零、计数归零，防止后续请求重放旧密钥；连续失败次数按 ISO14229 要有上限。MCU 上真随机源不好弄，常见做法是用片内 RNG 或 ADC 噪声，别用伪随机数发生器糊弄，测试人员手里有一堆固定种子的样本，一测就穿帮。

4.3 S3 会话保持定时：掉电存储与“非默认会话”的管理

S3 是会话保持定时。进入非默认会话后，S3 定时器开始计时，收到任意诊断请求就重置；定时溢出，ECU 回默认会话。这个定时器在源码里位置很隐蔽，常被放在服务分发的最后一行。掉电时如果正在编程会话，上电后必须回到默认会话，不能保持之前的解锁状态。

/* uds_services.c - 每次收到合法请求都重置 S3 */ void uds_reset_s3_timer(void) { s3_timer = UDS_S3_TIMEOUT_MS; } /* 定时器 1ms tick 中 */ void uds_timer_1ms_tick(void) { /* ... P2/P2* 处理 ... */ if (uds_session != 0x01U) { if (s3_timer > 0U) { s3_timer--; if (s3_timer == 0U) { uds_session = 0x01U; /* 回到默认会话 */ } } } }

注意，S3 定时器要在“收到请求”那一刻重置，不是在“处理完请求”后重置。如果放在处理路径的末尾，对于耗时的服务（比如擦除 Flash），定时器早就溢出了，ECU 被踢回默认会话，刷写流程直接中断。掉电存储这一块，编程会话里改过的标定值，一定要在退出会话前落盘，否则下次上电数据还是旧值——这个问题在实车刷写里查过不止一次。

5. 避坑指南：UDS 源码移植最常见的五个翻车点

5.1 0x10 请求石沉大海：CAN ID 过滤配置错了

现象：诊断仪发 02 10 01，ECU 完全无响应，总线上看不到 7E8 的响应帧。

原因：ECU 的 CAN 硬件过滤或协议栈的 ID 掩码没把 0x7E0（物理请求 ID）包含进来。很多源码默认只配了扩展帧过滤，标准帧请求被直接丢弃；还有的控制器做了 FIFO 过滤，ID 掩码设成了只接收某个固定 ID。

解决：检查接收 ID 过滤列表，确认物理请求 0x7E0 和功能请求 0x7DF 都在范围内。用总线工具先看 CAN 驱动层有没有收到帧，再往上查协议栈。实在查不到就把过滤器全关掉做对比测试，能快速定位是不是过滤的问题。

5.2 0x27 永远返回 NRC 0x35：密钥算法与种子生成不同步

现象：种子能正常拿到，但发送算好的密钥永远是 0x35 invalidKey。

原因：密钥算法通常是一个带移位和异或的查表过程，种子字节顺序和密钥计算时取的顺序不一致。比如种子是 [A B C D]，算法内部按 [D C B A] 算，两边对不上。还有一种是种子生成时用了伪随机数，复位后每次序列都一样，诊断仪那边拿到的种子和 ECU 计算的错位。

解决：在代码里加一个固定的种子测试向量，先用已知种子算出期望密钥，确认算法本身无误，再排查字节序。这个是血泪经验，直接上测试向量能省半天。

5.3 会话被反复踢回默认：S3 定时器的计数基准不对

现象：进入扩展会话后，诊断仪一切正常，但刷写过程中 ECU 中途断开，日志里发现会话已经变回 0x01。

原因：S3 定时器被放在了“服务处理完成后”重置，而不是“收到请求”时重置。擦除 Flash 的耗时超过 S3 值，定时器在服务还没跑完时就溢出，ECU 直接回默认会话，刷写流程中断。

解决：把 uds_reset_s3_timer() 移到 uds_can_rx_handler 里，收到合法请求第一时间重置。同时确认定时器 tick 频率和 UDS_S3_TIMEOUT_MS 的单位一致，别拿 10ms tick 去减一个毫秒单位的计数。

5.4 多帧传输重组失败：DLC 与帧类型标志位被忽略

现象：短 DLC 的 CAN 帧在诊断仪上表现为请求发送成功但 ECU 不回，或者收到的响应内容错乱。

原因：can_rx_handler 里用 data[0] >> 4 判断帧类型没错，但单帧的数据长度取的是 data[0] & 0x0F，有的代码错误地用 dlc - 2 来推数据长度，多帧传输时首帧和连续帧的拼接长度就算不对。CAN FD 的 DLC 编码不是线性长度，需要转换表。

解决：帧类型统一按 (data[0] & 0xF0) 判断，单帧长度用 data[0] & 0x0F，多帧拼装长度按 ISO-TP 规范从首帧的第二字节解析。CAN FD 平台加一个 can_dlc_to_len() 转换函数，别直接拿 DLC 当字节数。

5.5 刷写掉线中断：P2* 参数被当成 P2 用

现象：诊断仪发擦除命令，ECU 回复 NRC 0x78，然后诊断仪在几百毫秒后就报超时，刷写掉线。

原因：Tester 侧配置里的 P2 被改成了 5000ms，P2* 却保持默认 50ms。ECU 回 0x78 后 Tester 按 P2* 等待，50ms 内没收到最终响应就判定超时。这是因为很多诊断仪工具把 P2/P2* 放在同一个菜单里，配置时容易填反。

解决：Tester 侧的 P2 对应“ECU 首帧响应延迟”，P2* 对应“服务执行时间”，必须分别配置。实车联调时先看诊断仪的协议栈配置，别一上来就改 ECU 代码。ECU 侧回 0x78 的时机也要看，如果 P2 还没用完就提前回 0x78，反而会触发 P2* 的短超时。

6. UDS 自动化测试起步：用 Python 脚本验证诊断响应时序

手动用 CAN 工具验证三五帧还行，回归测试就得上脚本。UDS 自动化测试输出测试报告，是量产项目交付的硬性要求。这里给一个最小可用的 Python 脚本，用 python-can 发单帧诊断请求，测量 ECU 的实际响应时间，判断 P2 参数是否达标。

# uds_smoke_test.py - 用 python-can 扫描 UDS 基础服务响应 import can import time bus = can.interface.Bus(channel="can0", interface="socketcan") req_id, resp_id = 0x7E0, 0x7E8 # 进入扩展会话 0x10 01 bus.send(can.Message(arbitration_id=req_id, data=[0x02, 0x10, 0x01])) t0 = time.monotonic() resp = bus.recv(timeout=1.0) dt = (time.monotonic() - t0) * 1000 if resp and resp.arbitration_id == resp_id: print(f"P2 实际响应时间: {dt:.1f} ms") print(f"响应内容: {resp.data.hex()}") else: print("超时：未收到 0x50 响应")

这段脚本里 time.monotonic() 的计时会受操作系统调度影响，只能用来做粗测。真正要验证 ECU 的 P2 时序，建议用支持硬件时间戳的 CAN 卡，比如 PCAN 或 CANoe，时间戳精度到微秒级。另外 python-can 本身不带 ISO-TP，超过 8 字节的请求要用 can-isotp 或 udsoncan 库，单帧请求直接用 socketcan 原始发送就行。

我习惯把这类脚本收集成一个小工具箱，每次改完定时参数或安全访问逻辑，先跑一遍冒烟脚本，再上全量测试用例。之前在一个 BMS 项目里，就是靠这几行脚本抓出了 P2 参数被同事误改成 500ms 的问题，省下了一整天的实车排查时间。希望帮到你。

本文还有配套的精品资源，点击获取