第五章 从零构建 —— uds-lite
代码片段说明：本章各节列出的 C 代码片段旨在展示核心逻辑与设计思路，可能因后续迭代而与
uds-lite/目录下的实际源码存在细微差异。请以uds-lite/目录中的源代码为最终参考。
5.1 uds-lite 项目概述——教学级UDS实现
场景：一万行代码之后的一场下午茶
你合上电脑，揉了揉眼睛。刚刚过去的四个小时里，你逐行阅读了 Arctic Core 的 Dcm.c——一万两千行代码，层层回调，状态机嵌套状态机，宏定义里嵌宏定义。你理解了 0x10 怎么切换会话，也看懂了 0x22 怎么查 DID 表，但你心里有个挥之不去的疑问：如果让我自己写一个 UDS 栈，我能写出来吗？
我的答案是：能。而且一个下午就够了。
不是因为你看过了 Arctic Core。恰恰相反——是因为你需要在脑海里把那一万两千行代码“蒸馏“回最基本的结构。蒸馏之后的 UDS，不过是一千行 C 代码。
这就是 uds-lite 项目的由来。
为什么要从零构建
阅读生产代码是“逆向理解“——你看到的是答案，但要自己想出问题。构建代码是“正向理解“——你从问题出发，每一步设计都有原因。
打个比方：你去医院参观一台 CT 机，看到的是控制台、扫描架、冷却系统、图像重建算法……但如果你要教一个医学生“什么是 CT“，你不需要让他看懂 GE 或 Siemens 的整套系统。你只需要给他一台纸箱做的 pico CT：一个旋转步进电机，一个 PIN 光电二极管，一套简单的反投影算法。能成像了，他就真正理解了 CT 的原理。 至于散热系统、剂量控制、DICOM 协议——那是他在临床时自然会遇到的。
uds-lite 就是那台纸箱 CT。
核心洞察： “看代码“和“写代码“激活的是大脑的两套不同神经回路。看代码时你在建立“识别”——你的大脑在存储模式（pattern）。写代码时你在建立“生成“——你的大脑在推导因果链。只有“生成“能让你在闭上眼睛时，看到从 SID 到 NRC 的完整因果路径。
uds-lite 的架构全景
uds-lite 是一个 C/S 架构的 UDS 诊断系统：
┌─────────────────────────────────────────────────────────┐
│ uds-lite 架构 │
│ │
│ ┌──────────────┐ TCP/13400 ┌──────────────────┐
│ │ │◄═════════════════════════════►│ │
│ │ uds_server │ DoIP-like payload wrap │ uds_client │
│ │ (ECU 端) │ │ (诊断仪端) │
│ │ │ ┌──────────┐ ┌──────────┐ │ │
│ │ · 会话管理 │ │UdsMsg │ │UdsMsg │ │ · 请求构建 │
│ │ · SID 分发 │ │encode() │ │decode() │ │ · 响应解析 │
│ │ · DID 存储 │ │decode() │ │encode() │ │ · NRC 处理 │
│ │ · DTC 存储 │ └──────────┘ └──────────┘ │ · 自动工作流 │
│ │ · 安全锁 │ │ │
│ │ · S3 定时器 │ uds_msg.h / uds_msg.c │ │
│ └──────────────┘ (报文编解码核心) └──────────────────┘
│ │ │
│ │ ┌──────────────────┐ │
│ │ │ │ │
│ └──────────►│ uds_shell │◄────────────────┘
│ │ (交互式终端) │
│ │ │
│ │ session 03 │
│ │ read F190 │
│ │ dtc │
│ │ security unlock │
│ └──────────────────┘
└─────────────────────────────────────────────────────────┘
整个项目由七个文件组成，各自职责明确：
| 文件 | 角色 | 职责 |
|---|---|---|
uds_common.h | 类型与常量定义 | SID枚举、NRC枚举、会话状态枚举、安全等级、UdsMsg结构体 |
uds_msg.h / uds_msg.c | 消息编解码 | UDS报文的正向构建和反向解析，负响应构建 |
uds_server.c | ECU 端 | 监听TCP端口、会话管理、SID分发、DID/DTC读写、安全访问 |
uds_client.c | 诊断仪端 | 连接ECU、构建请求、解析响应、自动处理NRC |
uds_shell.c | 交互式终端 | 人类可读的命令解析，hex展示与NRC解释 |
Makefile | 编译 | 三个可执行目标的构建规则 |
编译后产生三个可执行文件：
uds_server—— ECU 模拟器，运行时在终端监听uds_client—— 自动化诊断工作流，一键执行完整流程uds_shell—— 交互式诊断终端，你可以逐条敲命令
uds-lite 覆盖的服务范围
uds-lite 实现了 ISO 14229-1 中最核心的十三个服务，覆盖了诊断的基本操作闭环：
| SID | 服务名称 | 作用 | 在医院里的类比 |
|---|---|---|---|
| 0x10 | DiagnosticSessionControl | 切换诊断会话（默认/编程/扩展） | 挂号——选择看门诊还是急诊 |
| 0x11 | ECUReset | 复位ECU | 让患者先休息一下，重启再来 |
| 0x3E | TesterPresent | 保持会话活跃 | “我还在，别挂断” |
| 0x27 | SecurityAccess | 安全解锁 | 刷卡进门，获得操作权限 |
| 0x22 | ReadDataByIdentifier | 按标识符读取数据 | 量体温、测血压（读实时数据） |
| 0x2E | WriteDataByIdentifier | 按标识符写入数据 | 给患者打一针（修改参数） |
| 0x14 | ClearDiagnosticInformation | 清除诊断信息 | 把之前的病历清掉 |
| 0x19 | ReadDTCInformation | 读取诊断故障码信息 | 查看患者病历本上的所有诊断 |
| 0x31 | RoutineControl | 例程控制 | 让患者做一套标准化检查 |
| 0x34/36/37 | RequestDownload / TransferData / RequestTransferExit | 固件下载三段式 | 给患者换零件（刷写ECU） |
| 0x85 | ControlDTCSetting | 暂停/恢复DTC记录 | 暂停症状记录，避免刷写时误报 |
这十三个服务的组合，已经可以实现一次完整的诊断闭环：注册（0x10）→ 保活（0x3E）→ 授权（0x27）→ 检查（0x22 + 0x19）→ 治疗（0x2E + 0x31）→ 手术（0x34/36/37 + 0x85）→ 出院（0x11/0x14）。
刻意省略的部分——以及原因
uds-lite 是一个教学项目，不是一个产品。它刻意省略了以下服务：
| 省略的服务 | 原因 |
|---|---|
| 0x28 CommunicationControl | 需要总线管理模型，引入了不必要的抽象层 |
| 0x2F IOControl | 需要实际的 I/O 绑定，在纯软件模拟中无意义 |
| 0x2C DynamicallyDefineDID | 运行时定义 DID 需要复杂的内存管理 |
| 0x86 ResponseOnEvent | 事件驱动的推进式传输需要额外的调度器 |
| 0x87 LinkControl | 需要理解通信链路的拓扑概念，教学价值有限 |
| 0x38 RequestFileTransfer | 文件系统模型在嵌入式裸机中不通用 |
| 0x3D WriteMemoryByAddress | 直接内存写入在教学模拟中可以用 DID 写入替代 |
这里的省略原则是：如果去掉这个服务会让理解主线变得更难，那就保留；如果加上它会让代码量翻倍而教学价值只增加 10%，那就砍掉。
教学简化清单——哪些地方做了“犯规“操作
uds-lite 有意识地违反了若干 AUTOSAR/ISO 14229 的正式要求，目的是让代码可读：
| 简化项 | uds-lite 做法 | 生产代码做法 |
|---|---|---|
| DID 存储 | 静态数组 g_did_table[DID_COUNT] | 与 IO Hardware Abstraction 交互，通过 ECU 信号间接取值 |
| DTC 存储 | 静态数组 g_dtc_table[UDS_MAX_DTC_COUNT] | 与 Dem（Diagnostic Event Manager）模块交互，需要 Debounce 算法 |
| 会话切换 | 直接修改全局变量 g_session | 通过 BswM（模式管理）协调各模块的状态迁移 |
| 安全访问 | 固定的 seed/key 映射表 | 应使用加密算法（RSA/ECDSA），seed 需实时生成 |
| 内存管理 | 栈上的固定大小 buffer | 应使用 MemMap 分区的静态内存池 |
| 通信层 | 原始 TCP socket | 应通过 DoIP（ISO 13400）和 PDU Router |
| 错误处理 | printf | 应通过 DET/DEM 报告，使用开发错误追踪 |
这些简化项的选择标准是：凡是和“理解 UDS 协议本身“不直接相关的东西，都用最简单的替代方案。
比较重要的简化处都添加了注释标记 // TEACHING: ...，这样搜索这个标签就能找到教学简化点。
编译与运行
# 编译全部目标
make
# 终端1：启动ECU模拟器
./build/x86-64/uds_server
# 终端2：运行自动化工作流（或者在另一个终端开交互式 shell）
./build/x86-64/uds_client
# 或者使用交互式终端
./build/x86-64/uds_shell
整个项目无需任何外部依赖。只需要 Linux 系统上的 GCC 和标准 POSIX 库。编译出来三个可执行文件的总大小不到100KB。整个 UDS 协议栈的核心逻辑只有几百行 C 代码。
阅读本章的导航图
本章的六节是精心安排的“渐进式揭示“：
- 5.1（本节） ——你刚读完，知道我们接下来要做什么
- 5.2 报文编解码 ——语言诞生：服务器和客户端如何说同一种话
- 5.3 ECU 端 ——服务器觉醒：字节流进入，决策产生，响应发出
- 5.4 诊断仪端 ——客户端崛起：构建请求，解析响应，自我纠错
- 5.5 交互式终端 ——魔法瞬间：你打字，ECU 回答，UDS 从抽象协议变成真实对话
- 5.6 全线测试 ——大结局：跑一遍完整流程，看每一字节的含义
核心洞察： uds-lite 的价值不在于“它能做什么“——它在任何意义上都不是一个可部署的 ECU 固件。它的价值在于“它让你看到了什么“——当你用一个下午写完 1000 行 UDS 代码后，你再去看任何生产级的 Dcm 实现，看到的将不再是迷宫，而是一张你已经走过一遍的地图。
本篇小结
- 从零构建设计是巩固理解的最高效方式——“看代码“建立识别模式，“写代码“建立因果链
- uds-lite 是 C/S 架构的 TCP-UDS 模拟系统：1 个 ECU 服务器 + 1 个诊断仪客户端
- 覆盖 13 个核心 UDS 服务，形成“注册→授权→检查→治疗→出院“的完整诊断闭环
- 刻意省略 7 个服务，教学简化多个生产实践——每一处都有清晰注释标注原因
- 六个源文件，1000 行 C 代码，无外部依赖，一个下午可读可写可运行
- 医院隐喻贯穿全章：诊断仪=医生，ECU=患者，DTC=症状，DID=检验项目
【下集预告】：现在我们有了项目的蓝图，但在服务器和客户端开始对话之前，它们必须先学会“说同一种话“。下一节我们将深入 uds-lite 的报文编解码层——那几行看似简单的 byte[] 操作代码，其实蕴含着 ISO 14229 最精巧的设计：为什么正响应的 SID 只需要
+0x40？为什么子功能码的 bit7 叫做 suppressPosRsp？为什么第一个负响应字节永远是 0x7F？ 答案就在这些看似随意的字节偏移里——而你要亲手写出它们的 C 代码。