东风 E70：23 个已验证信号与 7 报文种子 DBC

结论：东风 E70 这个项目的核心落差是数量级的：作为唯一真源的 production/e70_current.dbc 只有 7 条报文、7 行信号定义，而由它生成、也是唯一部署物的 RealDash XML 有 21 个 frame 元素与 46 个 value 元素。46 个值里只有 23 个是作者认证过的 validated，其余 20 个为 plausible、另有 partial、suspect、unverified 各一。把 XML 当作 46 个已验证信号来用，是最容易踩的坑。

采集条件与产物分工

所有数据的来源是 ESP8266 加 MCP2515 组成的 SLCAN 桥，在 500 kbit/s 上做只听抓取。这个硬件前提决定了它的能力边界：MCP2515 是经典 CAN 控制器，这套装置看不到 FD 帧，也不具备任何主动请求能力，因此 UDS 一类的按需数据完全不在范围内。

production/ 目录的原则是「每种只有一个」：当前配置与当前 DBC 各一份，其余全部进 archive/ 且永不删除。这条约定比它看起来重要——看到 archive/xml/ 里还有老的 merged 与 probe XML、archive/dbc/ 里还有自动解码的临时 DBC 时，如果不看这组约定，很容易把过期文件当成候选版本。

而 XML 与 DBC 的关系是单向的：XML 由 DBC 生成，改信号只能改 DBC，绝不能手改 XML。这条规则一旦破掉，DBC 就不再是唯一真源，两份文件会各自漂移。

23 个 validated 与 20 个 plausible 的分界线

作者给出的分级标准非常明确，这也是这份资料最值得学习的地方。

已验证的 23 个信号覆盖面其实相当完整：整车与轮速、制动与加速踏板、挡位、里程、车门与灯光及远近光、转向灯、电子驻车（EPB）、SOC（0x397 与 0x380）、充电状态与握手信号。它们的验证强度来源于「场景确认 + 全部 167 份日志一致性」双重条件，合计约 2400 万条匹配帧（原文记为 ~24M matched frames）。

仍在 plausible 里的则肯定是那些该小心的人：电池包电压（0x0D3）、高压电流（0x0EF）、转向角、若干温度、扭矩与功率。它们的共同特点是「读数落在合理区间」，但没人证明这个换算系数是对的。

而电池相关的锚定之所以卡住，原因写得一清二楚：完整的包电压、SOC、电流缩放系数标定，需要一份从接近空到充满的真实充电抓包，让 SOC 沿单调充电曲线变化才能把 scale 与 offset 钉住。现存的充电日志跨越的 SOC 区间不够宽，钉不住。

自动化评分会误报，这是已知缺陷

这一条必须单独说，否则看到报告里的 PARTIAL 会做出错误判断。凡 RealDash 的 conversion 里用到了位移或按位与的枚举/位域信号，自动评分器可能把它报成 PARTIAL 或 SUSPECT，即便它在 RealDash 里渲染完全正常。

原因是评分器看的是原始字段的分布：只要某一次挡位或充电状态在抓包里从未出现，它就会认为这个枚举缺状态而报警。正确的读法是把 >> 或 & 定义出来的枚举上的 PARTIAL/SUSPECT 理解为「该事件没有被抓到」，而不是「解码坏了」；确认方式是在车上把缺失的状态实际执行一次再抓。

这两条命令的实际用法也值得抄：validate_profile.py 针对单份日志打印每个信号的 min/max/mean 与可用性/量程状态，配合 --expect expects.json 可以做物理量断言，越界即 FAIL；analysis/validate_xml.py 则把整份 XML 对全部日志跑一遍，把逐信号判据表写回 reports/。前者适合改完 DBC 立刻自检，后者适合入库前的整体复核。

权利状态

最后一个必须写在使用之前的约束：归档方在这个修订版上没有找到仓库总体许可证；仓库里那份 .claude/skills/LICENSE 只覆盖随仓库携带的一个 skill，并没有明确延伸到整车研究数据。归档说明因此要求把它作为私有离线研究副本保留，发布或再分发之前先确认权利。

常见问题

那份 RealDash XML 里的 46 个值都是已验证信号吗？

不是。归档保留的验证报告把这 46 个值划分为 23 个 validated、20 个 plausible，以及 partial、suspect、unverified 各 1 个。只有 validated 那 23 个通过了「场景确认且在全部 167 份日志中保持一致」的双重条件，其余不能用于判断。

为什么当前 DBC 只有 7 条报文却有 46 个 XML 值？

因为 DBC 与 XML 承担的角色不同。production/e70_current.dbc 是一份小而规范的种子文件，只有 7 条报文与 7 行信号定义，是所有位、缩放与偏移的唯一真源；XML 是由它生成并扩展配置后的部署物，含 21 个 frame 与 46 个 value。二者不可混为一谈，且改信号只能改 DBC。

报告里的 PARTIAL 一定说明解码有问题吗？

不一定。凡是 conversion 里用位移或与运算定义的枚举或位域，评分器可能报 PARTIAL 或 SUSPECT，即使它在 RealDash 中渲染正常；因为评分器按原始字段分布判断，某个状态在抓包中未出现就会被认为缺状态。应理解为事件未被抓到，补抓确认即可。

电池 SOC 和包电压的缩放系数为什么一直没有定下来？

作者说明：完整的包电压、SOC 与电流缩放标定需要一份从接近空到充满的真实充电抓包，让 SOC 沿单调充电曲线变化才能锚定 scale 与 offset。现有充电日志跨越的 SOC 区间不够宽，因此这三项仍停留在候选状态，不能当作已标定量使用。

延伸阅读

• 公共 CAN/DBC 数据集怎么选：四类来源与三道筛查 —— 识别「XML 规模远大于已验证集合」的常见形态
• BYD Atto 3 档案：Chassis 与 Private 双总线分工 —— 同为国产电动车逆向档案的总线划分方式
• Nissan Leaf ZE0：LBC 块数据与只读遥测 —— 另一套 SOC 相关信号的取值与证据强度
• 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 为什么这 20 个 plausible 值只能看趋势

参考资料

• 项目 01 —— public-can-dbc-datasets/additional/ali-roohy-dongfeng-e70/UPSTREAM_README.md（ESP8266 加 MCP2515 的 SLCAN 桥与 500 kbit/s 只听抓取、production 目录原则与产物分工、RealDash 的 CAN/Custom XML 加载方式、XML 由 DBC 生成且不可手改、23 个 validated 信号清单与 167 份日志约 2400 万条匹配帧、约 20 个 plausible 候选与 SOC 标定等待充电抓包的原因、验证 commands 与 –expect 断言、枚举位运算被误报为 PARTIAL/SUSPECT 的已知缺陷）
• 项目 01 —— public-can-dbc-datasets/additional/ali-roohy-dongfeng-e70/SOURCE.md（production/e70_current.dbc 的 7 报文 7 信号行、XML 的 21 个 frame 与 46 个 value、46 个值的 23/20/1/1/1 分级、三个文件的 blob 与 SHA-256、未找到仓库许可且 skill 许可不覆盖整车数据的说明）

免责声明

本文所述报文 ID、信号数量与分级结果均来自公开开源仓库的说明与归档文件，属第三方逆向工程产物，未经独立实车核验，也不代表车辆制造商的官方数据。不同车型年款、市场与 ECU 版本可能存在差异。该数据当前缺少明确的仓库许可，不宜直接集成或再分发。涉及行车安全的判断请以实际测量与官方资料为准。

更新记录

• 2026-10-14 初稿