结论：五菱 Air EV 的这份 CAN 嗅探研究给出了一条可复现的低成本采集链路和 115 个唯一 ID 的规模，但三个主参数的字节映射存在未解决的冲突：README 把油门踏板记在 0x17D 的字节 4 与 6，而随车保留的处理脚本把 0x155 标为踏板，并额外加了一个 0x1E5 电池电压。仓库里既没有 DBC、也没有原始 CSV 抓包和字节级换算公式，因此这些 ID 只能当作候选，不能当作已验证的解码表。
一条 500 kbit/s 的被动采集链路是怎么搭起来的
整套采集是被动的：ESP32 DevKitC 加 MCP2515 收发模块，走 OBD-II 接口的 6 脚（CAN High）与 14 脚（CAN Low），固件以监听模式运行，不做任何主动请求。晶振配置为 8 MHz，CAN 速率设为 500 kbit/s。一次约 49 分钟的道路测试记录下 115 个唯一 CAN ID。
抓下来的原始记录以分号分隔的 CSV 落地，Python 侧用 pandas 读取后，把 Data_Raw 这一列按空格拆成 Byte_1 到 Byte_8 八列，再按 CAN ID 做映射标注，最后导出成一份包含全部 115 个 ID 的 Excel。未被映射表命中的 ID 统一标记为「尚未识别」。
| 环节 | 配置项 | 取值 | 说明 |
|---|---|---|---|
| 控制器 | MCU / 收发器 | ESP32 DevKitC + MCP2515（8 MHz） | 固件使用 mcp_can 库，监听模式 |
| 物理接入 | OBD-II 引脚 | 6 脚 CAN High，14 脚 CAN Low | 直接挂诊断口，无需破线 |
| 总线速率 | 标称波特率 | 500 kbit/s | 由固件按 8 MHz 晶振配置 |
| 采样规模 | 时长与 ID 数 | 约 49 分钟，115 个唯一 ID | 覆盖多种行驶工况 |
| 落盘格式 | CSV 分隔符 | 分号 | 读取时需显式指定分隔符 |
| 后处理 | 字节拆分 | Data_Raw 拆为 Byte_1–Byte_8 | 缺失字节填占位符 |
| 产出 | 汇总文件 | REKAP_TOTAL_PERCOBAAN_DUA.xlsx | 115 个 ID 全部进入汇总表 |
三处冲突：油门到底在哪个 ID
把 README 的结论和保留下来的处理脚本并排看，会发现两套标注并不一致。差异集中在踏板这一项上，另外脚本多出一个电池电压条目，而 README 完全没有字节级换算公式。
| 参数 | README 给出的 ID 与字节 | 处理脚本给出的 ID | 一致性判断 |
|---|---|---|---|
| 加速踏板位置 | 0x17D，字节 4 与字节 6 | 0x155 | 冲突，未解决 |
| 电机转速 | 0x16E，字节 5 与字节 7 | 0x16E | ID 一致，无换算公式 |
| 电池电流 | 0x16C，字节 5 与字节 6 | 0x16C | ID 一致，无换算公式 |
| 电池电压 | 未提及 | 0x1E5 | 脚本独有，无字节定义 |
需要强调的是：脚本里的映射只是一张 ID 到标签的字典，用于给每一行打标注，并不包含缩放因子、偏移量或字节序。也就是说，即便 ID 确定，也无法据此直接得到工程量。README 里那句「字节 4 与 6」是目前唯一出现的字节位置线索，且同样没有给换算规则。
为什么这个冲突不能靠猜来解决
两个 ID 指向同一类信号，在实际解码里是两种完全不同的后果：如果 0x155 才是踏板而 0x17D 是别的量，那么按 README 取数会得到一条看似有变化、实则无关的物理量曲线，而且因为它随工况变化，很容易被误判为「已经解出来了」。判定办法只有一条——同时抓两个 ID 的原始数据，踩踏板做阶跃，看哪个字节随踏板线性跟随。
证据边界：仓库里缺什么
这份材料的定位是学术研究记录，不是可用的解码资产。判断它能用到什么程度，关键看缺失项，而不是看已给出项。
| 缺失项 | 对使用的影响 | 建议处理 |
|---|---|---|
| DBC 文件 | 无法用标准工具直接解码全部 115 个 ID | 自建候选 DBC 时把每个 ID 标为待验证 |
| 原始 CSV 抓包 | 无法复算、无法复核字节位置 | 自行重采，保留原始文件 |
| 字节级换算公式 | ID 确定也得不到工程量 | 用独立参考源做标定后再写公式 |
| 具体配置年款 | 无法判断结果能否迁移到同车型其他批次 | 记录自己的车辆配置，不跨车套用 |
| 独立标定记录 | 三个主参数的精度无从评估 | 用仪表读数或 OBD 标准 PID 交叉验证 |
| 明确的再分发许可 | README 只要求署名，未给出许可证 | 仅作私有离线研究副本，商用前先确认权利 |
仓库里的两份 DOCX 论文和若干绘图图像并未随本次归档保留，因此论文中是否给出了更完整的推导，无从判断。这也是为什么「未解决」比「错误」更准确：现有材料不足以判定谁对。
常见问题
这份研究能给五菱 Air EV 出一份可用的 DBC 吗？
不能。仓库里没有 DBC，也没有原始 CSV 抓包与字节级换算公式，只有 115 个 ID 的规模和三个（实为四个）候选标签。它能提供的是采集方法和候选 ID 清单，DBC 必须由使用者自行采集、标定后重建。
油门踏板到底应该用 0x17D 还是 0x155？
目前无法确定。README 把踏板记在 0x17D 的字节 4 与 6，保留下来的处理脚本却把 0x155 标为踏板，两者冲突且未解决。可靠的判定方式是同时抓这两个 ID，踩踏板做阶跃，看哪个字节随踏板线性跟随。
500 kbit/s 是这个车型 OBD 口的确定波特率吗？
它是这次采集所用的配置值，不是车型的官方标称值。固件按 8 MHz 晶振把 CAN 速率设为 500 kbit/s 并成功收到 115 个 ID，说明该配置在本车可用；其他批次或年款是否一致未做验证。
为什么脚本映射出四个 ID 却没有任何换算公式？
因为脚本里的映射只是一张 ID 到标签的字典，作用是在汇总表里给每行打标注并统计 ID 分布，本身不做物理量解码。字节位置线索只在 README 中出现过一次，同样没有给出缩放因子与偏移量。
这份材料可以再分发或放进产品吗？
不建议直接使用。检查的仓库快照中没有找到任何许可证文件或 SPDX 声明，README 只提出署名要求，而署名要求并不构成明确的再分发许可。目前应按私有离线研究副本处理，商用前须确认权利。
延伸阅读
- 车电接入：为什么 ESP32 的 TWAI 不等于 OBD 接口 —— 同控制器的接入方式与电平边界
- BYD Atto 3 档案：Chassis 与 Private 双总线分工 —— 另一款国产纯电的总线组织方式
- 东风 E70：23 个已验证信号与 7 报文种子 DBC —— 从候选 ID 走到种子 DBC 的对照样例
- 84% 的 PID 没有公开证据：OBD 私有协议解析的现实边界 —— 理解候选标签与已验证信号的差距
- 车型数据库 —— 按车型查阅更多 CAN 档案
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/ilham511-wuling-air-ev/README.md（500 kbit/s 被动采集、115 个 ID、三个主参数的候选 ID 与字节） - 项目 01 ——
public-can-dbc-datasets/additional/ilham511-wuling-air-ev/Processing_Data.py（ID 到标签的映射字典、字节拆分逻辑与汇总导出流程） - 项目 01 ——
public-can-dbc-datasets/additional/ilham511-wuling-air-ev/SOURCE.md（快照版本、许可证状态与证据边界说明）
免责声明
本文所述 CAN ID、字节位置与采集参数均来自公开仓库的说明文件与脚本，未经独立实车验证，且 README 与脚本之间存在未解决的标注冲突。车辆配置年款、市场与 ECU 版本可能导致差异。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。
更新记录
- 2026-10-14 初稿
发表回复