星核火花赛车科技

标签： CAN总线

  • foxBMS 2 的 CAN 报文：41 条组件级定义与双许可证边界

    结论：foxBMS 2 的 CAN 报文定义是 41 条组件级报文，属于开源电池管理开发平台自身的协议，不是任何量产整车的网络地图。使用它之前有两件事必须先定：一是它的许可证是分裂的——软件走 BSD-3-Clause，硬件与文档走 CC-BY-4.0，两者的义务不同；二是它描述的是一个可自由配置的 BMS 平台，报文语义随配置而变，不能按固定车型档案的方式套用。

    41 条报文的定位：组件级而非整车级

    foxBMS 2 的自我定位是「第一个模块化的开源 BMS 开发平台」，提供硬件与软件的完整开源环境，用于控制各种规模的现代复杂电化学储能系统。它的 CAN 定义文件放在工具链目录下，共 41 条报文，覆盖的是 BMS 这个部件对外发布的量，而不是整车广播网络。

    这两者的差别在接入时非常关键：整车 DBC 里，同一个 ID 的含义由车型年款固定；而 BMS 平台的报文含义取决于使用者怎么配置电池包、从控数量和告警策略。因此把 foxBMS 2 的报文表当作某台车的解码依据，方向就是错的。

    判据维度 组件级 BMS 报文（本例） 整车级广播 DBC
    描述对象 BMS 部件自身对外接口 整车多个 ECU 的广播网络
    报文规模 41 条 常见数十至上百条
    语义决定方 使用者的平台配置 车型年款与制造商
    跨车复用 可在不同储能系统间复用 通常绑定具体车型
    验证途径 按自身配置与实测标定 抓包比对原车行为

    双许可证：软件与硬件文档分开授权

    这个项目采用了罕见的双轨授权，而且分界线非常清楚：软件部分用 BSD 3-Clause，硬件与文档部分用 CC BY 4.0。归档时两份许可证全文都被保留了下来，这本身就是一种可核验的合规姿态。

    授权对象 许可证 SPDX 标识 文本文件 核心义务
    软件 BSD 3-Clause License BSD-3-Clause BSD-3-Clause.txt 保留版权声明，不以作者名义背书
    硬件与文档 Creative Commons Attribution 4.0 International CC-BY-4.0 CC-BY-4.0.txt 署名；允许商用与再分发

    除了法定条款，项目还提出了一个软性请求：在硬件、软件、文档或宣传材料中使用时，建议采用「本产品使用了 foxBMS 的部分」「本产品包含 foxBMS 的部分」或「本产品衍生自 foxBMS」这类表述。这不构成额外义务，但对追溯来源有帮助。项目由 Fraunhofer IISB 维护，并已通过开源硬件协会认证，OSHWA UID 为 DE000128。

    为什么硬件走 CC-BY 而不是 BSD

    电路原理图与布局属于硬件设计成果，用面向代码的许可证去授权会留下大量解释空白。CC-BY-4.0 是面向任意作品的署名型许可，允许商用与再分发，只保留署名一项主要义务，与硬件设计的传播方式更匹配。这也是为什么在引用其 BMS 硬件设计时必须带上署名，而不能只保留软件侧那份 BSD 声明。

    平台能覆盖哪些储能体系

    判断一份 BMS 报文定义是否适用于自己的项目，先看它面向的电化学体系。foxBMS 2 明确列出了已成功应用的储能类型，覆盖范围远超常见的三元/铁锂电池。

    储能类型 备注
    锂离子电池 常规锂电体系
    固态电池 Solid State Batteries
    锂硫电池 Lithium-Sulfur
    钠离子电池 Sodium-Ion
    锂离子电容 LIC
    双电层电容 EDLC，超级电容
    液流电池 RFB，例如全钒液流
    燃料电池 FC

    项目还说明这些体系可以混合组合使用，并应用于多个领域。这一点直接影响报文的使用方式：不同化学体系的单体电压范围、温度窗口与均衡策略都不同，报文里的量纲与告警阈值必然要跟着配置走。

    仓库结构与文档入口

    归档保留了根目录的 README 与许可证说明。从 README 可以还原出仓库的标准目录划分，这对定位 CAN 定义文件与文档很有帮助。

    目录 内容
    仓库根目录 许可证信息、安装说明、变更日志链接、主构建脚本
    cli 与仓库交互的命令行工具
    conf 全部高层配置
    docs 文档源文件
    hardware 硬件原理图与布局信息
    src BMS 嵌入式软件的全部源文件
    tests 嵌入式源码、工具链与脚本的测试
    tools 构建 foxBMS 二进制所需的工具与附加工具

    每个子目录都带一份说明其内容的 README。变更日志位于 docs/general/changelog.rst，文档构建产物由项目方持续发布，最新发布版与历史构建均可查阅。CAN 定义文件本身位于工具链目录下的 dbc 子目录。

    常见问题

    foxBMS 2 的 41 条报文能用来解码某台量产电动车吗？

    不能。这 41 条是 BMS 平台自身部件的对外接口定义，属于组件级数据，不是生产车辆的 DBC。它的报文语义随使用者的平台配置而变，只能用于自建或参照该平台的储能系统。

    软件部分和硬件部分可以只遵守其中一个许可证吗？

    不可以。授权是分裂的：软件走 BSD-3-Clause，硬件与文档走 CC-BY-4.0，两者义务不同。引用硬件设计或文档时必须履行 CC-BY-4.0 的署名义务，不能只用软件侧那份 BSD 声明覆盖全部内容。

    CC-BY-4.0 允许商业使用吗？

    允许。CC BY 4.0 国际许可允许商用与再分发，主要义务是署名。项目另外建议在宣传材料中使用「本产品使用了 foxBMS 的部分」这类表述，这是请求而非强制条款。

    OSHWA UID DE000128 意味着什么？

    它表示 foxBMS 2 已通过开源硬件协会的开源硬件认证，认证编号 DE000128。这是对项目硬件开放程度的第三方确认，不等于对任何具体电池系统的安全认证或性能背书。

    这套 BMS 支持哪些电池化学体系？

    项目列出锂离子、固态、锂硫、钠离子、锂离子电容、双电层电容（超级电容）、液流电池（如全钒液流）以及燃料电池，并说明这些体系可以混合组合使用，覆盖多个应用领域。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/foxbms2/README.md（项目定位、支持的储能体系、仓库目录结构、开源硬件认证与许可证概述）
    • 项目 01 —— public-can-dbc-datasets/additional/foxbms2/LICENSE.md（软件 BSD-3-Clause 与硬件文档 CC-BY-4.0 的分工、SPDX 标识与署名请求）
    • 项目 01 —— public-can-dbc-datasets/additional/foxbms2/CC-BY-4.0.txt（硬件与文档所适用的许可全文）
    • 项目 01 —— public-can-dbc-datasets/additional/foxbms2/BSD-3-Clause.txt（软件所适用的许可全文）

    免责声明

    本文所述报文规模、许可证分工与平台能力均来自公开仓库的说明文件，未经在具体电池系统上的独立验证。报文语义取决于使用者的平台配置，不同电池化学体系、从控数量与告警策略会导致差异。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。

    更新记录

    • 2026-10-14 初稿

  • StreetDrone 自动驾驶平台的 CAN 接口：36 报文与 184 信号

    结论：StreetDrone 的 CAN 接口不是一份车型协议库，而是一条把 CAN 帧翻译成 ROS 话题的解码链。它的核心定义 databases/candatafile.dbc 有 36 条 BO_ 报文与 184 条 SG_ 信号，把平台/客户控制、诊断、GPS 与惯导报文混在同一份文件里；上游没有确立任何量产车型的年款适配，也没有给出独立的信号精度证据。真正决定它能不能进产品的是另外三件事：VERSION 字符串含异常字符、文件里挂着一条长度为 0 却带大量信号的 Vector 伪报文、以及仓库快照中找不到许可证文件。

    ROS 话题里的三层数组：报文名、信号值与单位分开传

    这个 ROS 节点订阅 /received_messages，为每条 CAN 报文在 /sd_state_msgs 上发布一个话题。它不做信号侧的强类型封装，而是把解码结果摊平成三层并行数组：报文层给出 message_names 与 message_ids，信号层在每个 message_data 元素里再给出 signal_names、signal_data 与 signal_units。这种结构的好处是新增报文不需要改消息定义，代价是取用方必须自己做索引对齐。

    层级 字段 类型 取值含义
    帧头 std_msgs/Header header uint32 seq / time stamp / string frame_id 标准 ROS 头，用于对齐时间戳
    报文层 string[] message_names 字符串数组 与 DBC 报文名一一对应
    报文层 uint16[] message_ids 无符号 16 位数组 CAN 报文 ID，索引查找的入口
    报文层 sd_state_msgs/Message_Data[] message_data 结构体数组 与 message_ids 同下标对齐
    信号层 string[] signal_names 字符串数组 单条报文内的信号名
    信号层 float64[] signal_data 双精度数组 已按 DBC 缩放解出的物理值
    信号层 string[] signal_units 字符串数组 信号单位，与信号值同下标

    看清楚这张表才能理解后面所有取数操作：没有 message_data.wheel_speed 这种字段，只有「先按 ID 找到下标，再用下标取三个数组」这一条路。单位随值一起下发，说明物理量换算已经在节点内完成，下游只负责消费。

    36 条报文与 184 条信号：控制、诊断与定位混编

    36 条报文除以 184 条信号，平均每条约 5 条信号，说明这份 DBC 里既有少量高位复用的控制/状态帧，也有信号数很少的稀疏帧。上游 README 明确写到，每个报文的细节都在 candatafile.dbc 里，并给出了大小端帧布局的外部说明链接，但并未逐条给出标定方法。因此把它当作「平台内部的解码契约」是合适的，当作「某款量产车的信号定义」则超出证据范围。

    内容类别 是否在文件内 证据边界
    StreetDrone / 客户控制报文 包含 未给出执行机构分辨率与时延证据
    诊断类报文 包含 未给出会话类型与服务号清单
    GPS 报文 包含 未给出坐标系、更新率与精度
    惯性传感器报文 包含 未给出零偏、量程与标定方法
    量产车型 / 年款适配 不包含 README 未确立任何 make / model / year
    信号精度的独立证据 不包含 README 中没有独立精度验证记录
    常用报文速查表 另有文件 指向 message_index.pdf，不在 DBC 内

    从报文 ID 到信号值：索引查找模型

    上游给出的示例是取轮速报文：在 message_ids 里线性查找等于 280 的下标，命中后用同一个下标去取 message_names 与 message_data，再遍历该元素的三个数组打印信号名、值与单位。这里的 280 是 README 中的十进制写法，换算成十六进制为 0x118。整个模式没有任何 ID 到结构体的映射表，ID 就是唯一的键。

    复现解码链：从 rosbag 回放到话题抽样

    上游给出的运行方式是双终端：一端回放 can-interface/bags 下的 2020-02-28-12-19-00.bag（加 -l 循环播放），另一端构建并启动解码节点。这样无需实车即可验证 DBC 与节点的对齐情况。

    步骤 操作 产物 / 判据
    1 构建 cd can-interface/catkin_ws 后 catkin_make 工作空间编译通过
    2 加载环境 source devel/setup.bash 自定义消息可被 rosmsg 找到
    3 核对结构 rosmsg show sd_state_msgs/SD_State_Msgs 打印出三层数组定义
    4 回放数据 cd can-interface/bags 后 rosbag play -l 2020-02-28-12-19-00.bag 模拟 /received_messages 输入
    5 启动节点 roslaunch sd_state_msgs sd_state_msgs.launch 开始发布 /sd_state_msgs
    6 抽样验证 rostopic echo -n1 /sd_state_msgs 单帧三层数组，检查单位串是否为空
    7 取指定报文 遍历 message_ids 命中 280，取 message_data[i] 轮速信号名、值与单位

    接入自写节点时还要补两处依赖声明：CMakeLists.txt 的 find_package(catkin REQUIRED COMPONENTS ...) 里加入 sd_state_msgs，package.xml 里同时写 build_depend 与 exec_depend。上游对 kinetic 版本的说明还给了排错路径：删掉 devel 与 build，rosdep install --from-paths src --ignore-src 后重新 catkin_make。

    入库前必须核对的三处风险

    这份 DBC 的问题不在信号数量，而在文件本身的规范性。它同时触发了「严格解析器可能直接拒绝」与「分发权利不可判定」两类风险，且两者都不能靠读信号定义发现。

    风险点 具体表现 处理动作
    VERSION 异常字符 版本串含非常规字符，部分解析器在文件头即报错 先用宽松解析器预检，必要时手工规整版本行
    零长度伪报文 存在一条长度为 0 的 Vector 独立信号伪报文，却挂载大量信号 单独剥离该条定义，再校验其余报文的长度一致性
    无许可证文件 检查的仓库快照里没有许可证文件，再分发权利不可判定 仅作离线研究副本，对外分发前先确认权利
    车型适配缺位 未确立量产车型与原厂 CAN 装配关系 只作平台内解码参照，不写进车型协议档案

    常见问题

    这份 DBC 能直接解析量产车型的 CAN 吗？

    不能。上游明确没有确立任何量产 make / model / year，也没有原厂 CAN 装配关系。36 条报文混合了 StreetDrone 与客户的控制报文、诊断报文、GPS 与惯导报文，属于平台自有的解码契约，只能作为同类平台的参照。

    为什么 36 条报文里会混进 GPS 和惯导报文？

    因为这份 DBC 描述的是整套平台状态话题，而不是某个 ECU 的收发矩阵。自动驾驶平台把定位与惯量传感器也挂到同一条解码链上，是常见的工程做法；代价是这份文件不能按「车型总线」口径去切分或复用。

    严格解析器报错时第一步该查什么？

    先查 VERSION 行与零长度伪报文这两处。文件里有一个含非常规字符的版本串，部分解析器在读文件头阶段就会失败；另有一条长度为 0 却挂载大量信号的 Vector 独立信号伪报文，会让长度校验失败。建议先剥离该条定义，再校验其余报文。

    在 ROS 里取轮速报文 280 的信号值要几步？

    核心是两步：先在 message_ids 里线性查找等于 280 的下标（280 是十进制写法，换算为 0x118），再用同一下标取 message_data 元素的 signal_names、signal_data 与 signal_units。前提是已完成 catkin_make、source devel/setup.bash，并在 CMakeLists.txt 与 package.xml 中声明 sd_state_msgs 依赖。

    这份素材可以随产品分发吗？

    不建议在未确认权利前分发。检查的仓库快照里没有找到任何许可证文件，再分发权利不可判定。当前定位是私有离线研究副本，若确需分发，应先向上游确认授权，并保留原始文件用于离线分析。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/hngu97-streetdrone-can/SOURCE.md（36 条 BO_ 与 184 条 SG_、VERSION 异常、零长度伪报文与许可证状态）
    • 项目 01 —— public-can-dbc-datasets/additional/hngu97-streetdrone-can/UPSTREAM_README.md（ROS 消息结构、轮速报文 280 示例、kinetic 运行与排错步骤）

    免责声明

    本文所述 DBC 与解码链均来自公开仓库的说明文件，未经过独立实车验证，不代表车辆制造商或平台方的官方数据。不同车型年款、市场与固件版本可能存在差异。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。

    更新记录

    • 2026-10-14 初稿

  • MX-5 ND2 自定义仪表盘：8 报文 14 信号的取数边界

    结论：MX-5 ND2 做自定义仪表盘时，这份 8 报文 14 信号的 DBC 只能当种子定义，不能当判据。它的价值是给出了转速、车速、油门、挡位/离合、转向、制动压力、轮速以及冷却液/进气温度的分域清单，但重复的属性定义、多处写成 0|0 或 0|1 的物理量范围、以及 0.01 车速比例与另一份 ND 笔记公式不一致这三点，决定了上仪表前必须先做一轮复核。

    仪表盘的取数要先分清楚三种数据源

    这套记录仪分成显示单元与传感器单元两部分，两者之间走 I2C，1.2 米的线缆在做好线材处理后仍有约 0.5% 的通信错误率。显示单元由 Raspberry Pi 4B 加一块 4.3 英寸 DSI 触摸屏构成；传感器单元集成 5V 电源、两片 4 通道 ADC、一个运动追踪模块，以及一块带定制固件的 I2C CAN 控制器。模拟量与车辆 CAN 走的是完全不同的通路，混在一起排查会浪费大量时间。

    系统对 RaceChrono 而言是一个 DIY BLE 设备：一部分选定的 CAN 帧直接透传，采集到的模拟量则被打包成一条额外的 CAN 帧一起送给 RaceChrono 记录。也就是说，仪表上看到的数字至少有车辆原始帧、透传帧、合成帧三种来源。

    数据源 硬件通路 典型信号 证据状态
    车辆 CAN I2C CAN 控制器 + 定制固件 转速、车速、油门、冷却液温度、进气温度 8 报文 DBC，标注在 2019 ND2 AE 上验证
    模拟量采集 两片 4 通道 ADC 机油压力、机油温度、转子温度 作者自建通道，未见独立标定记录
    红外测温 0~1000 °C 工业红外测温仪，4–20 mA 输出 转子温度 硬件选型已定，截至 2023-09-04 尚未装车
    运动追踪 已安装的运动追踪模块 未接入 README 列为后续开发项
    合成帧 BLE 侧自行封装 全部模拟量打包成一条 CAN 帧 仅供 RaceChrono 记录，非原车帧

    8 报文 14 信号覆盖的六个域

    DBC 本体很小：8 条报文、14 个信号，覆盖的全是仪表盘最关心的量。把它按信号域摊开看，才能判断哪些域可以直接用、哪些域需要补枚举或补标定。

    信号域 DBC 覆盖内容 上表盘前的注意
    动力 转速、车速、油门 车速比例与另一份 ND 笔记公式不一致，须对抓包复核
    传动 挡位、离合 状态类信号，先确认枚举值是否齐全再显示
    转向 转向角 需确认零位与左右符号约定
    制动 制动压力 与轮速联合判读才有意义
    轮速 车轮轮速 四轮一致性可反向验证车速公式
    温度 冷却液温度、进气温度 与机油温度分属不同通路，报警阈值不通用

    值得注意的是：机油压力与机油温度并不在这 14 个信号里，它们来自模拟量通道。因此机油压力报警的判据是电压换算后的工程量，而不是 DBC 解码结果——这决定了它的精度取决于 ADC 与传感器标定，与 CAN 侧无关。

    三处必须在上仪表前处理的 DBC 缺陷

    这份归档 DBC 保留了原文件的原样，包括它的瑕疵。三处缺陷都会直接影响解码器的行为，且都不是「看看就好」的级别。

    缺陷类型 具体表现 处理动作
    属性定义重复 同一条属性被重复声明 部分解析器会告警甚至拒绝加载，导入前先跑一遍加载测试
    物理量范围不成立 多处 minimum|maximum 写成 0|0 或 0|1，不描述缩放后的输出 不要用 DBC 上下限做滑块量程或报警阈值
    车速比例分歧 归档 DBC 的车速比例为 0.01，另一份公开 ND 笔记给出的公式不同 拿抓包数据与独立车速参考源比对后再选定
    文件出处不明 DBC 文件名带 BY_TDO 后缀，来源未独立确认 商用复用前先核对第三方信号与表格的出处

    其中第二点最容易被忽略：很多人把 DBC 的 minimum/maximum 直接拿来生成 UI 滑块的上下限或报警门限，而这里的 0|0 和 0|1 并不描述缩放后的物理量，照抄会得到错误区间。

    蜂鸣器报警是双条件触发

    显示单元带一个蜂鸣器，触发条件是机油压力低于阈值且转速高于怠速。两个条件同时成立才响，这是为了避免熄火状态下机油压力为零时误报。这个逻辑也说明：仪表盘的报警判据是跨数据源的，CAN 侧给转速，模拟侧给压力。

    常见问题

    这份 8 报文 DBC 能当 MX-5 ND2 的整车网络定义吗？

    不能。它只有 8 条报文、14 个信号，覆盖动力、传动、转向、制动、轮速与温度六个仪表域；上游并未把它描述为整车网络定义，标注的验证车辆也只有 2019 ND2 AE 一台，其他年款与市场未做确认。

    为什么车速不能直接用 DBC 里的 0.01 比例？

    因为同一车型的另一份公开 ND 信号笔记给出的车速公式与归档 DBC 的 0.01 比例不同，两者来源不同且未做交叉验证。在没有抓包数据和独立车速参考源比对之前，这两套公式不能互换使用。

    仪表盘的报警阈值能不能取 DBC 的物理量上下限？

    不能。这份 DBC 里多处物理量范围写成 0|0 或 0|1，并不描述缩放后的输出值。用它生成滑块量程或报警门限会得到错误区间，阈值应当来自实测标定或官方资料。

    机油压力报警在什么条件下触发？

    机油压力低于设定阈值并且转速高于怠速时，显示单元的蜂鸣器才会响起。两个条件必须同时成立，这样设计是为了避免熄火后机油压力归零导致的误报。

    显示单元和传感器单元之间的 I2C 有什么实测问题？

    两者之间用 1.2 米 I2C 线缆连接，作者说明即使做了仔细的线材处理，通信仍有约 0.5% 的错误率。长距离 I2C 是这个架构的已知短板，做数据完整性校验时要把这个错帧率算进去。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/chrumck-knurdash-mx5-nd/SOURCE.md（8 报文 14 信号 DBC 的覆盖范围、0.01 车速比例分歧与 MIT 许可证提示）
    • 项目 01 —— public-can-dbc-datasets/additional/chrumck-knurdash-mx5-nd/README.md（显示单元与传感器单元的硬件构成、I2C 错误率、蜂鸣器逻辑与装车状态）

    免责声明

    本文所述信号与硬件参数均来自公开仓库的说明文件与源码注释，未经独立实车验证。DBC 标注的验证车辆为 2019 ND2 AE，其他年款、市场与 ECU 版本可能存在差异。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。

    更新记录

    • 2026-10-14 初稿

  • 五菱 Air EV 的 CAN 信号：115 个 ID 与一处未解的字节冲突

    结论：五菱 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 只提出署名要求，而署名要求并不构成明确的再分发许可。目前应按私有离线研究副本处理，商用前须确认权利。

    延伸阅读

    参考资料

    • 项目 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 初稿

  • ADS-DV 2021 的 CAN 架构：7 个 API、8 ms 节流与两套 DBC

    结论：2021 版 FS-AI ADS-DV 接口库把无人方程式赛车的 CAN 交互收敛成 7 个函数加两套 DBC：VCU 与 AI 之间的接口为 16 条报文、97 个信号，随车 PCAN-GPS 传感器定义为 23 条报文、67 个信号。真正的工程约束不在接收侧而在发送侧——内部定时器把帧重发周期限制在不小于约 8 ms，推荐每 10 ms 调用一次发送函数，调用过慢会触发整车 ECU 的 CAN 超时诊断。

    7 个函数构成的调用契约

    库对外只暴露 7 个函数以及配套的数据结构与枚举，方向划分得很干净：初始化一个、VCU 到 AI 一个、AI 到 VCU 一个、IMU 与 GPS 各一个、CAN 统计读写两个。

    函数 方向 调用约束
    fs-ai_api_init(接口名, debug, simulate) 初始化 debug 非 0 时向 stdout 输出调试信息，否则静默；simulate 非 0 时载入仿真值
    fs_ai_api_vcu2ai_get_data() VCU → AI 异步接收，每帧到达即缓冲，取到的总是最新值
    fs_ai_api_ai2vcu_set_data() AI → VCU 须足够频繁以免触发 ECU 的 CAN 超时诊断；内部定时器限制重发周期不小于约 8 ms，每 10 ms 调用最优
    fs_ai_api_imu_get_data() PCAN-GPS → AI 异步接收，逐帧缓冲
    fs_ai_api_gps_get_data() PCAN-GPS → AI 异步接收，逐帧缓冲
    fs_ai_api_get_can_stats() 库内部 用于调试 CAN 接收状况
    fs_ai_api_clear_can_stats() 库内部 清空统计结构

    这里有一个容易被误用的点：simulate 参数载入的仿真数据并不代表车辆运行行为，它只是每次调用 fs_ai_api_vcu2ai_get_data() 时变化一次。它适合验证链路是否连通，不能用于任何算法或控制逻辑的验证。

    两套 DBC 与节点划分

    节点划分可以从两套 DBC 的分工直接读出来：VCU 与 AI 之间是双向控制接口，PCAN-GPS 是单向传感器源，CAN 统计则是库内的调试支路，不占整车网络节点。

    DBC 文件 报文数 信号数 节点角色
    ADSDV_2021_VCU_AI_interface_v2.dbc 16 97 VCU ↔ AI，双向：遥测下行、控制上行
    PCAN-GPS for ADS-DV.dbc 23 67 PCAN-GPS → AI，单向：IMU 与 GPS 传感数据

    值得注意的是报文数与信号量的不对称：传感器侧的报文更多（23 对 16）而信号更少（67 对 97）。这与两类接口的形态一致——VCU 接口把状态与控制量打包进少量高密度报文，GPS/IMU 则按物理量分成多条短报文。库只暴露 2021 赛季 DDT 比赛所必需的那部分接口，完整规范在 ADS-DV_Software_Interface_Specification_v4.0.pdf 中，该文件同时发布在 IMechE 网站上。

    2021 相对 2019 的变化

    这次发布把交付形态从二进制改成了源码，功能上也补上了新赛季新增的执行器能力。

    维度 2019 2021
    交付形态 静态库 libfs-ai_api_amd64.a，供静态链接 MIT 源码，可为任意 Linux 架构编译并按需修改
    制动能力 未包含调制液压制动 更新的 CAN 接口支持调制液压制动
    向后兼容 — 接口向后兼容 2019 车辆
    示例程序 — Console 与 Tester 示例程序得到改进
    版本状态 — release candidate，供车队参考实现车辆接口代码

    对车队来说最有价值的一条是向后兼容：同一份 2021 接口代码可以跑在 2019 车辆上，这意味着制动等执行器能力的差异被吸收在接口层，而不是让每支车队各自维护分支。

    构建、运行与证据边界

    构建路径很直接：进入 FS-AI_API_Tester 或 FS-AI_API_Console 目录执行 make，库会按需自动构建或重建；随后以接口名为参数运行，虚拟总线用 vcan0，实车接口用 can0。仓库内的 setup.sh 给出 Linux 下配置 CAN 接口与创建 can0、vcan0 的具体命令。

    证据边界需要如实标注：素材为固定快照（提交 33bcb61d2519ee1ac4935396d9bf465c6ebc81c1），两份 DBC 均按 Git blob 原样保留；PCAN-GPS 文件可能包含第三方传感器厂商的定义，其独立数据权利并未被确认，再分发前应复核该部分信号来源。仓库为 MIT 许可，许可文件与 README 一并保留。最重要的是，这些文件描述的是赛事用无人方程式车辆，不是量产道路车。

    常见问题

    2021 版接口相对 2019 版改了什么？

    交付形态从静态库 libfs-ai_api_amd64.a 改为 MIT 源码，可为任意 Linux 架构编译并按需要修改；CAN 接口更新以支持新增的调制液压制动能力，同时保持对 2019 车辆的向后兼容；Console 与 Tester 两个示例程序也得到改进。该版本被标注为 release candidate，供车队参考实现车辆接口代码。

    发送函数应该多久调用一次？

    推荐每 10 ms 调用一次 fs_ai_api_ai2vcu_set_data()。调用必须足够频繁，否则会触发整车 ECU 的 CAN 超时诊断；但过于频繁又会占用总线，因此库内置定时器禁止以小于约 8 ms 的周期重发帧。每 10 ms 调用可以在两者之间取得最优平衡，数据更新会以尽可能快的速度下发到车辆。

    simulate 模式的数据可以用来验证算法吗？

    不能。文档明确说明仿真数据不代表车辆运行行为，它只是每次调用 fs_ai_api_vcu2ai_get_data() 时变化一次。它适用于确认链路连通与数据结构正确，任何算法或控制逻辑的验证都必须使用真实车辆数据。

    这两套 DBC 能直接用到量产车上吗？

    不能。它们描述的是 IMechE FS-AI ADS-DV 赛事用无人方程式车辆的 VCU 与 AI 接口以及随车 PCAN-GPS 传感器定义，不是量产道路车的网络定义。此外 PCAN-GPS 文件可能包含第三方传感器厂商定义，其数据权利未独立确认，再分发前应复核来源并保留 MIT 归属。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/fs-ai-ads-dv-2021/README.md（7 个函数的调用契约、8 ms 节流与 10 ms 建议、构建运行方式与规范文档出处）
    • 项目 01 —— public-can-dbc-datasets/additional/fs-ai-ads-dv-2021/SOURCE.md（两套 DBC 的报文与信号数、快照提交、权利与证据边界）

    免责声明

    本文所述内容来自公开开源仓库的说明文件与数据库文件，描述对象为赛事用无人方程式车辆，不代表任何量产道路车的网络定义，也未经实车验证。两份 DBC 均按固定快照原样保留，其中 PCAN-GPS 部分可能包含第三方传感器厂商定义，其独立数据权利并未被确认，再分发前应复核来源并保留 MIT 许可与归属。涉及车辆控制与执行器的改动请在封闭场地、专业人员监督下并遵守赛事规则进行。

    更新记录

    • 2026-10-14 初稿

  • 学生方程式车队的 CAN 调试工具链：10 ms–10 s 周期与 63 报文夹具

    结论：这套面向学生方程式车队的 CAN 调试工具，价值不在界面而在「逐报文可控」：发送侧支持单发与周期发送，周期可在 10 ms 到 10 s 之间逐条设定，每条报文既能单独停止也能整体停止；接收侧按 DBC 自动抽取并解释信号。但它的硬前提是 SocketCAN——必须运行在 Linux 或等效模拟器（如 WSL）上，Windows 虽有预编译包，却绕不过这一层。

    两种模式的能力边界

    工具以 Go 的 Bubble Tea 构建终端界面（TUI），核心是加载并解析 DBC 后同时管理多条报文。发送侧与接收侧的能力并不对称：发送侧提供单发与连续发送两类选项，连续发送按自定义周期运行，周期范围的默认值在源码 internal/ui/types.go 的 rangeMs 中定义，可按需修改；接收侧则由使用者挑选要监听的报文，并依据 DBC 定义自动完成信号抽取与数值解释。

    模式 能力 参数 约束
    发送 单发（single-shot） 单次触发 须先建立 SocketCAN 接口
    发送 连续发送 逐报文独立频率，范围 10 ms – 10 s 范围由 rangeMs 决定，改源码可调
    发送 停止控制 单条停止或全部停止 多条并发时逐条管理
    接收 选择性实时监听 指定要监控的报文 未选中的报文不展开
    接收 信号自动解释 依赖已加载的 DBC 定义 DBC 未覆盖的报文只能看原始字节

    平台与分发物：能装上不等于能跑通

    发布页提供四个预编译包，覆盖 Linux x86_64、macOS Intel、macOS Apple Silicon 与 Windows x86_64。但 README 在需求一节写得很直接：需要 SocketCAN 接口（vcan0 或真实 CAN 接口），因此要有 Linux 或类似 WSL 的模拟器。换句话说，Windows 包只是把二进制带过去，真正的总线层仍然要落在 Linux 内核的 SocketCAN 上。

    平台 分发文件名 说明
    Linux x86_64 can-debug_Linux_x86_64.tar.gz 解压后 chmod +x 即可运行，原生支持 SocketCAN
    macOS Intel can-debug_Darwin_x86_64.tar.gz macOS 无 SocketCAN，需借助 Linux 环境
    macOS Apple Silicon can-debug_Darwin_arm64.tar.gz 同上，总线层依赖外部 Linux 环境
    Windows x86_64 can-debug_Windows_x86_64.zip 需配合 WSL 等模拟器使用
    任意（源码构建） Go 1.19 及以上 go build -o can-debug，可按需改周期范围

    命令行只有三种形态：带接口名启动后用文件选择器挑 DBC、带接口名与 DBC 路径直接加载、以及 -h 或 --help 查看完整帮助。启动前必须先建好 can 或 vcan 网络，这是文档里反复强调的一条。

    测试夹具 MCB.dbc 的量级与证据边界

    随工具提供的样例 DBC 位于 internal/test/MCB.dbc，包含 63 条报文与 300 条信号定义，覆盖电池、显示、IMU 与牵引系统等车队自研部件节点。它足够用来验证工具本身，但不足以当作车辆信号研究成果：上游并未确立这份额外夹具对应的具体车辆、赛季、总线，也没有实车验证记录。

    文件 报文数 信号数 证据边界
    internal/test/MCB.dbc 63 300 样例测试文件，未确立车辆、赛季、总线与实车验证
    同车队另一份已归档 Main_CAN_Bus.dbc 61 293 相关车队数据，但报文与信号定义不同，不可互相替代
    归档库中的既有 DBC — — SHA-256 与已归档的 2258 份 DBC 均不匹配，属新增条目

    这张表给出一个实用的判断方法：两份报文数相近（63 与 61）、信号数只差 7 的 DBC，并不构成互为佐证的关系。源说明特别提示，不能把这份夹具当作独立的车辆信号研究来引用；仓库为 MIT 许可，但其中任何厂商部件信号的原始权利并未被独立确认。

    从 vcan 到实车接口的启动顺序

    快速路径是运行仓库内的 TestVcanSetUp.sh 脚本，一键创建 vcan 接口并启动程序，然后在另一个终端用 candump vcan0 观察程序发出的帧、用 cansend vcan0 123#DEADBEEF 向程序注入一帧；Ctrl+C 结束抓包。手动路径则依次加载 can、can-raw、vcan 模块，安装 can-utils，创建并拉起 vcan0，再用 ip a show vcan0 确认。

    接真实接口时把创建命令换成设置波特率的形式：先用 ip link set 把目标接口设为 CAN 类型并指定 bitrate，再拉起接口，然后用 ip a show 确认状态，最后以接口名（可选带 DBC 路径）启动程序。文档命令中的接口名与波特率均为占位符，需按实际硬件替换。

    常见问题

    这套工具能在 Windows 上直接连实车 CAN 吗？

    不能。README 明确要求 SocketCAN 接口（vcan0 或真实 CAN 接口），也就是需要 Linux 或类似 WSL 的模拟器。Windows 的预编译包只是可执行文件的分发形态，总线层仍需落在 Linux 环境的 SocketCAN 上。

    每条报文的发送周期能设到多少？

    连续发送支持逐报文独立设定频率，默认范围是 10 ms 到 10 s；这个范围由源码 internal/ui/types.go 中的 rangeMs 决定，需要更长或更短周期时修改该值即可。每条报文既能单独停止，也能一次性全部停止。

    随包的 MCB.dbc 能不能当作车队的正式总线定义？

    不能。它是随调试工具提供的样例测试文件，含 63 条报文、300 条信号，覆盖电池、显示、IMU 与牵引系统等节点，但上游未确立其对应的具体车辆、赛季、总线，也没有实车验证记录；同车队的另一份 Main_CAN_Bus.dbc 有 61 条报文、293 条信号，定义并不相同，两者不可互相替代。

    为什么它的 SHA-256 要单独登记？

    因为去重口径依赖哈希：这份 MCB.dbc 的 SHA-256 与已归档的 2258 份 DBC 都不相同，才被判定为新增条目。若只比对文件名或报文数，很容易把 63 条报文的夹具与 61 条报文的同车队文件误判为同一份。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/squadracorsepolito-can-debug/README.md（TUI 能力、发送/接收模式、平台分发物与 vcan/实车接口启动步骤）
    • 项目 01 —— public-can-dbc-datasets/additional/squadracorsepolito-can-debug/SOURCE.md（MCB.dbc 的 63 报文/300 信号、哈希登记与证据边界）

    免责声明

    本文所述内容来自公开开源仓库的说明文件，涉及的报文与信号数量仅为该测试夹具自身的规模，不代表具体车辆、赛季或总线的定义，也未经实车验证。仓库为 MIT 许可，但夹具中任何厂商部件信号的原始权利并未被独立确认。发送类工具一旦接入真实总线即具备主动写入能力，请在隔离环境或虚拟总线上完成验证，并遵守所在赛事与场地的安全规定。

    更新记录

    • 2026-10-14 初稿

  • TrevCAN 树莓派节点：347 条报文定义与 460 种载荷布局

    结论：TrevCAN 的树莓派节点是一个纯发送端：它只读 SocketCAN 原始帧，按 100 ms、最多 500 帧一批推给服务端的 /ingest/can，本身不做任何 DBC 解码，也从不向物理总线发帧。它的仿真模式覆盖 7 份 DBC 里的全部 347 条报文定义、共 460 种载荷布局，但生成的是合成覆盖数据，不是物理自洽的车辆模型。

    车端与服务端的职责切分

    这个项目的设计取舍非常明确：车上那台树莓派上不需要 TREVCAN-Explorer 检出目录里的任何文件。DBC 解码、InfluxDB 写入与前端全部跑在车下的服务器上。车端只剩一个瘦发送器，负责把 SocketCAN 上收到的原始帧打包送走。

    这样切分带来两个直接后果。好处是车端依赖少、故障面小，换 DBC 不必动车上的部署；代价是车端无法做本地语义判断——它不知道自己送走的是电池单压还是转向角，任何与信号含义相关的逻辑都必须放到服务端。

    环节 运行位置 职责 是否接触总线
    SocketCAN 帧读取 树莓派 从 can0 读取原始帧 只收不发
    批处理与 HTTP 上报 树莓派 按 100 ms、最多 500 帧一批推到 /ingest/can 否
    DBC 解码 车下服务器 用已启用且已排序的 DBC 解码收到的帧 否
    InfluxDB 与前端 车下服务器 落库与展示 否

    启动前必须先做的一件事

    按车辆实际波特率配置并拉起 can0，再启动发送器。这一步在文档里被放在显眼位置，而且与另一条约束互为补充：发送器只接收 CAN 流量，不会向物理总线发送。也就是说它天然是只听（listen-only）的，不可能因为软件缺陷把帧打进整车网络——前提是 can0 本身配置正确。

    如果车上用的不是原生 SocketCAN 设备，可用 --interface 与 --channel 选择其它 python-can 接口，无需改动代码。

    仿真模式：347 条报文与 460 种布局

    带 --simulate-rate 启动时，程序不会打开任何 CAN 接口，也绝不在物理总线上发送。它用 cantools 把 trevcan_pi/dbcs/ 里 7 份当前 DBC 的定义编码成原始帧，全部 347 条报文定义都会被覆盖，包括每一个多路复用分支——完整一轮是 460 种载荷布局。

    460 对 347 这个差值本身就是信息：平均每 3 条报文里就有 1 条带多路复用，多出来的 113 种布局全部来自复用分支。如果解码端只按报文 ID 取第一个布局，这部分帧一定会被解错。

    参数 取值 含义
    覆盖报文定义 347 7 份 DBC 的全部报文定义
    每轮载荷布局 460 含每个多路复用分支
    速率语义 总帧率 --simulate-rate 是每秒总帧数，不是每条报文的帧率
    20 Hz 一轮耗时 约 23 秒 460 帧除以 20
    460 Hz 一轮耗时 约 1 秒 不含处理开销

    数值在后续轮次中会变化，但始终落在每个信号在 DBC 内可表示的上下限之内；枚举值则在已定义的值之间轮转。命令与配置类报文只作为网络遥测计入，不代表车辆真的执行了这些命令。

    交付语义：批处理、队列与不保证送达

    这一段是整个项目里最需要在使用前读明白的部分。它把「尽力而为」写得很具体，而不是含糊带过。

    机制 取值 溢出或失败时的行为
    批处理窗口 100 ms 窗口内最多打包 500 帧
    队列容量 10,000 帧 溢出时丢弃最旧的帧，并在日志中计数
    HTTP 批次失败 不重放 失败或不确定的批次不做重放
    中断恢复 自动恢复传输 但中断期间无磁盘积压，也无送达保证
    停止方式 SIGTERM 与 Ctrl-C 未发送的帧可能被丢弃

    把这些数字连起来看，缓冲深度是可以估出来的：批处理窗口为 100 ms、每批上限 500 帧，对应每秒 5000 帧的处理上限；队列 10,000 帧约等于 2 秒的缓冲。总线负载一旦持续超过这个量级，丢的就是最老的数据，而不是最新的——对事后分析来说这个取舍需要提前想清楚。

    安全侧也有明确要求：共享令牌和数据必须用私有网络、VPN 或 HTTPS 保护；INFLUXDB_TOKEN 只留在服务端，不上车。

    开机自启与仿真切换

    车上部署的关键不是写服务文件，而是把秘密与路径分开管理：服务文件里只留用户名与检出路径，令牌与服务端地址放进单独的 env 文件并收紧权限。这样既避免了令牌进版本库，也让同一份服务定义能在不同车上复用。

    步骤 操作 要点
    改服务文件 编辑 systemd/trevcan-pi.service，填入自己的用户名与检出路径 服务文件本身不含令牌
    写环境变量 在 /etc/trevcan-pi.env 写入 CAN_INGEST_TOKEN 与 TREVCAN_SERVER 地址形如 http 加主机名再加 8000 端口
    收紧权限 sudo chmod 600 /etc/trevcan-pi.env 仅 root 可读
    安装并启动 复制到 /etc/systemd/system/，执行 daemon-reload 与 systemctl enable --now trevcan-pi --now 同时完成开机自启与立即启动
    看日志 sudo journalctl -u trevcan-pi -f 队列溢出计数也在这里
    切换仿真 把 ExecStart 里的 --channel can0 换成 --simulate-rate 20 迁移时须先停掉并禁用旧的全栈服务

    两点值得单独记：CAN 接口的配置由系统单独管理，不由这个服务负责；测试用 python -m unittest discover -s tests 即可跑完，测试用 cantools 对每条报文与每个复用布局做编解码往返、校验信号覆盖与取值边界，并 mock HTTP 上报，不需要硬件、InfluxDB 或网络监听。

    归档取舍：保留 2 份、剔除 5 份

    归档最终只保留了两份字节互异的 BMS 与 DAQ 固件 DBC 快照，合计 277 行 BO_ 报文定义与 1,373 行 SG_ 信号定义。其余五份各有各的去向，理由不完全相同。

    文件 处置 理由
    trevcan_pi/dbcs/BMS-Firmware-RTOS-Complete.dbc 保留 与已有归档无重复；Git blob 94d4168a43352804615ae7659ac04475d09c43a8
    trevcan_pi/dbcs/DAQ-Firmware.dbc 保留 与已有归档无重复；Git blob 45ee363c49bdeeea30d0824bc0243529e118bf99
    Baby_MOBO.dbc 剔除 CRLF 归一化后与同批次已有归档中的文件完全相同
    VCU.dbc 剔除 CRLF 归一化后与同批次已有归档中的文件完全相同
    can9-database-01.09.dbc 剔除 CRLF 归一化后与同批次已有归档中的文件完全相同
    Inverter.dbc、hvc.dbc 剔除 已与同批次已有归档中的文件字节完全相同
    examples/simulation.dbc 说明为合成示例 仅用于演示的最小样例

    需要注意：这里被剔除的文件只是不重复归档，不代表它们在工程上被弃用。仿真模式仍然按 7 份当前 DBC 覆盖 347 条报文定义。

    两个 ID 撞车：0xC0

    文档点出了一个原始 CAN 的结构性限制：逆变器的 Command_Message 与 VCU 的 VCU_INV_Command 共用标准 ID 0xC0。两份定义都会被仿真并打印告警，但服务端解码时用的是第一个匹配的已启用 DBC，无法按 ID 区分这两条定义。后果很直接：同一 ID 的帧解出来是命令还是状态，取决于你在服务端启用了哪份 DBC、以及它的排序。测试某个仪表盘前，必须确认启用并排好的是目标那份。

    常见问题

    这个树莓派节点会往车上发 CAN 帧吗？

    不会。文档写明发送器只接收 CAN 流量，不向物理总线发送；仿真模式下更是完全不打开 CAN 接口、绝不在物理总线上发送。启动前还需按车辆实际波特率配置并拉起 can0，配置正确时它对整车网络是只听的。

    仿真生成的 460 种布局能当真实车辆数据用吗？

    不能。它覆盖 7 份 DBC 中全部 347 条报文定义、含每个多路复用分支共 460 种布局，但数值只是在 DBC 可表示范围内变化、枚举按定义值轮转，属合成覆盖数据而非物理自洽的车辆模型。命令与配置类报文也仅作为网络遥测计入。

    为什么 0xC0 这个 ID 会解出两种含义？

    因为原始 CAN 不携带 DBC 身份。逆变器的 Command_Message 与 VCU 的 VCU_INV_Command 共用标准 ID 0xC0，服务端按第一个匹配的已启用 DBC 解码，无法靠 ID 区分。因此要在服务端启用并排好你实际要测的那份 DBC，否则解出来的是另一条定义。

    断网期间采集到的报文会补传吗？

    不会。批处理最多 500 帧、窗口 100 ms；队列容量 10,000 帧，溢出时丢弃最旧帧并在日志计数；失败或不确定的 HTTP 批次不重放。传输会自动恢复，但中断期间没有磁盘积压，也不保证送达；SIGTERM 或 Ctrl-C 停止时未发送的帧同样可能被丢弃。

    归档只留了两份 DBC，其余五份为什么没有？

    原因分两类：Baby_MOBO.dbc、VCU.dbc 与 can9-database-01.09.dbc 在 CRLF 归一化后与同批次已有归档中的文件完全相同；Inverter.dbc 与 hvc.dbc 则已字节完全相同；examples/simulation.dbc 是合成示例。剔除只是避免重复归档，不代表这些文件在工程上被弃用。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/elidresnin-trevcan-pi/UPSTREAM_README.md（纯发送端定位与车端不依赖 Explorer 检出文件、venv 与 requirements 安装流程、CAN_INGEST_TOKEN 与 –server 参数、can0 需按车辆波特率预配置、只收不发、–interface 与 –channel、–simulate-rate 的总帧率语义、347 条报文定义与 460 种布局、0xC0 ID 冲突与服务端按首个匹配 DBC 解码、–dbc 顶层目录扫描规则、systemd 开机自启与 /etc/trevcan-pi.env、500 帧 / 100 ms 批处理与 10,000 帧队列及不保证送达、unittest 测试范围）
    • 项目 01 —— public-can-dbc-datasets/additional/elidresnin-trevcan-pi/SOURCE.md（保留两份 BMS 与 DAQ 固件 DBC 快照、277 行 BO_ 与 1,373 行 SG_ 合计、快照修订 684065b99b79ae2748fe061ccd70aaabf2f94337 与采集日期 2026-10-04、三份文件因 CRLF 归一化重复被剔除、两份已字节相同、examples/simulation.dbc 为合成示例、两份文件各自的 Git blob 与 SHA-256、未找到仓库许可证与原始组件归属故仅作私有离线研究副本）

    免责声明

    本文所述批处理参数、队列容量、报文与布局数量、命令与路径均来自公开开源仓库的说明文档，属第三方工程产物，未经独立实车核验。归档方已声明仿真数据为合成覆盖数据而非物理自洽的车辆模型，硬件适配与信号正确性未经检查，且该快照未找到仓库许可证与原始组件归属，仅应作为私有离线研究副本保留。涉及安全相关用途时请以实际测量与官方资料为准。

    更新记录

    • 2026-10-14 初稿

  • 标致 207 仪表 IPC：4 根线与一份种子 DBC

    结论：这份 Peugeot 207 IPC 资料的价值不在信号清单，而在可复现的最小实验台：一块 STM32G431KB 板、一只零件号 A2C53065549 的仪表、4 根线（14 脚 CAN_H、15 脚 CAN_L、16 脚 12 V、18 脚 GND）即可把收发、抓包、写 DBC 串起来。需要提前说清的是，README 本身没有列出任何 CAN ID 或位定义，逐信号内容只存在于仓库里的 peugeot_207.dbc 种子文件。

    硬件构成与引脚定义

    仪表端只需要接 4 个脚。CAN_H 与 CAN_L 在第 14、15 脚，供电在第 16 脚、接地在第 18 脚。这个排列意味着改制时不需要拆开整个连接器去猜线序，也给实验台留出了一致的接线基准。

    供电这一项有个有用的细节：第 16 脚标称 12 V，但文档注明「works with 9 V」，即 9 V 下也能工作。对台架供电来说这拓宽了电源选择，但同时也意味着在整车电压偏低时仪表未必会立刻掉线，排查供电问题不能只看仪表是否点亮。

    引脚 信号 / 电源 接线要点
    14 CAN_H 与 CAN_L 构成差分对，不可单独引出长线
    15 CAN_L 同上
    16 12 V（9 V 亦可工作） 标称 12 V，实测下限可到 9 V
    18 GND 与收发器、MCU 共地

    拆开仪表可以看到里面的 CAN 收发器是 TJA1054AT，厂商标注为 Philips / NXP，状态为 End of life。同系列里状态为 Active 的是 TJA1055，被描述为 enhanced fault-tolerant CAN transceiver。对台架来说这不是致命问题，但对要长期供货的项目，选型阶段就要考虑换代。

    器件 角色 厂商标注状态
    TJA1054AT（仪表内置） Fault-tolerant CAN transceiver End of life
    TJA1055（换代参考） Enhanced fault-tolerant CAN transceiver Active
    STM32G431KB（MCU 侧） 演示用主控，配合 ST HAL 使用 未标注状态

    为什么偏偏是这只 IPC

    作者在选型理由里把「可获得性」放在了首位，这和多数逆向项目按技术参数选件的思路不同，也更贴近教学场景的实际约束。

    维度 本资料所用变体 Peugeot 207 其他版本 IPC
    零件号 A2C53065549 未给出具体零件号
    显示特征 带挡位模式显示与机油温度表 配置各异
    市场存量 不常见，较难买到 保有量大
    价格 可能偏高 部分低于 10 EUR
    教学可用性 信号更丰富，适合演示 适合批量采购做实验台

    支撑这个选择的是保有量：2007 到 2010 年仅欧洲就售出接近 150 万台 207。庞大的存量意味着二手件价格低、容错空间大——学生焊坏了不心疼，这是实验台能持续运转的前提。

    对教学场景而言，带挡位模式显示与机油温度表这件事本身是有意义的：它比纯转速/车速表多出两类语义不同的信号，一类是离散枚举（挡位模式），一类是连续测量量（油温）。学生在同一块仪表上就能遇到两种完全不同的解码思路，而不必为了示范枚举再去接第二个节点。

    从收发到写 DBC：一条完整的教学路径

    这个仓库定位是 barebone demo，重点不是把仪表功能做全，而是把四件事串成一条可走的路线：发送与接收报文、嗅探总线、创建 DBC 文件，以及由此入门汽车逆向工程。

    工具链的选择也体现了递进关系：先用 Arduino IDE 加 ESP32-S3 入门，再用这个仓库演示 ST 的 HAL 同样易用，下一步是 STM32CubeIDE 与 CCStudio IDE。对已经熟悉 Arduino 生态的人来说，这条路径把「换到 ST 平台」的心理门槛拆成了两步。

    类别 资料 / 工具 在教学链中的作用
    入门硬件 Arduino IDE + ESP32-S3 进入嵌入式世界的第一步
    主控演示 STM32G431KB + ST HAL 证明 ST 的 HAL 同样易用
    后续 IDE STM32CubeIDE、CCStudio IDE 下一步工具环境
    DBC 编辑 SavvyCAN（含 DBC 文件编辑器） 编写与调试 DBC
    参考资料 CSS Electronics DBC 入门与在线编辑器、Kvaser J1939 与 DBC 介绍、Social Ledge DBC Format 理解 DBC 语法与字段含义
    总线工具 Vector CANdb++、Makerbase CANable 2.0、PEAK-System PCAN-USB 与 PCAN-USB FD 专业级网络定义与 USB 转 CAN 适配
    体系资料 PSA CAN bus PSA 平台总线背景

    DBC 种子文件的位置与作用

    仓库在 /Assets/DBC/peugeot_207.dbc 提供了一份示例种子文件，配套的截图展示了它在 SavvyCAN 中加载与编辑的效果。也就是说，CAN ID 与位定义的实际内容在 .dbc 文件里，README 只负责指向它并给出工具与流程。若要做逐字节比对，应以这份种子文件和自己的抓包结果为准。

    四步路径：从收发报文到写出 DBC

    这个仓库的主线不是把仪表驱动做完整，而是让初学者在最短路径上走完一次完整的「看—抓—猜—记」循环。四个环节依次推进，每一步都有可验证的产出，不容易在中间卡死。

    步骤 动作 可验证的产出
    1 发送与接收报文 仪表指针或显示有响应，证明物理层与波特率正确
    2 嗅探总线 抓到一组稳定的 ID 与周期，得到候选报文清单
    3 创建 DBC 文件 把候选 ID 与位段写成可加载的定义，在工具里能解出数值
    4 进入汽车逆向工程 用改动反推含义，形成可复核的信号假设

    这套顺序的关键在于第一步必须先成立。如果波特率或接线不对，后面抓到的只是一堆噪声，很容易让人误判为「协议加密」而放弃。因此台架阶段应优先确认第 16 脚供电正常、第 14 与 15 脚差分连接无误、第 18 脚与 MCU 共地。

    工程文件缺失时的重建方式

    仓库没有随附 /Drivers/ 下的两个目录。文档给出的重建办法是：登录 MyST，按 Alt-K 依据 .ioc 文件生成 /Drivers/CMCIS/ 与 /Drivers/STM32G4xx_HAL_Driver/，几秒后工程即可编译。

    这个约定的意义在于把「生成物」与「源文件」分开：.ioc 是引脚与外设配置的唯一真源，Drivers 目录是可再生的产物。好处是仓库体积小、不会因 HAL 版本漂移而失配；代价是新环境必须先有能生成代码的 IDE，否则工程无法直接构建。对新接手的人来说，第一条要做的不是找缺失文件，而是确认自己有可用的生成工具。

    常见问题

    这份资料里有 Peugeot 207 的完整 CAN ID 与位定义吗？

    README 里没有。文档只给出引脚定义、内置收发器型号与工具链，逐报文、逐信号的内容在仓库的 /Assets/DBC/peugeot_207.dbc 种子文件中，README 仅指向它并展示在 SavvyCAN 中加载与编辑的效果。要做逐字节比对，请以该种子文件与自己的抓包结果为准。

    仪表第 16 脚能不能用 9 V 供电？

    可以。引脚表把第 16 脚标注为 12 V，并注明 9 V 也能工作。这对台架供电是便利，但也意味着整车电压跌到 9 V 时仪表可能仍然正常显示，排查供电故障时不能把「仪表还亮着」当作电压正常的证据。

    为什么资料特别提到 TJA1054AT 已停产？

    因为它是仪表内置的容错 CAN 收发器，厂商（Philips / NXP）标注状态为 End of life，且文档同时给出状态为 Active 的增强型容错收发器 TJA1055 作为换代参考。对教学台架影响不大，但对需要长期供货或做量产适配的项目，选型阶段就应把换代考虑进去。

    仓库缺少 Drivers 目录时该怎么办？

    不需要另外找文件。登录 MyST 后按 Alt-K，依据工程里的 .ioc 文件即可生成 /Drivers/CMCIS/ 与 /Drivers/STM32G4xx_HAL_Driver/，几秒后工程就能构建。这背后的约定是 .ioc 为配置真源、Drivers 为可再生产物，因此新环境必须备有可生成代码的 IDE。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/peugeot-207-ipc/README.md（STM32G431KB barebone demo 定位与零件号 A2C53065549、仪表变体差异与 2007 至 2010 年欧洲近 150 万台的保有量、14/15/16/18 脚的 CAN_H、CAN_L、12 V 与 GND 定义及 9 V 可用、内置 TJA1054AT 容错收发器的 End of life 状态与 TJA1055 换代参考、收发与嗅探及编写 DBC 的教学路径、Arduino IDE 加 ESP32-S3 到 ST HAL 再到 STM32CubeIDE 与 CCStudio 的工具链递进、/Assets/DBC/peugeot_207.dbc 种子文件位置、Drivers 目录缺失时通过 MyST 与 Alt-K 依据 .ioc 重新生成的方式、DBC 工具与 PSA 总线资料清单）

    免责声明

    本文所述引脚定义、器件型号与状态、零件号、工具链与工程约定均来自公开开源仓库的说明文档，属第三方教学与逆向工程产物，未经独立实车核验，也不代表车辆制造商的官方数据。不同车型年款、市场与 ECU 版本可能存在差异，文中未涉及具体 CAN ID 与位定义，相关内容请以仓库内种子文件与实际抓包为准。涉及安全相关用途时请仅作参考。

    更新记录

    • 2026-10-14 初稿

  • Daybreak 与 HighNoon：105 条报文与 493 条信号

    结论：太阳能车队两代车的 CAN 定义是 7 份按功能域切开的 DBC，而非一份整车文件。Daybreak 三份合计 23 条报文、58 条信号，HighNoon 四份合计 82 条报文、435 条信号。决定复用方式的不是总量，而是信号密度：bps.dbc 平均每条报文只挂 1.47 条信号，LightingCAN.dbc 则高达 9.50 条。

    七份 DBC 的目录划分与规模落差

    归档保留了 7 份字节互不相同的 DBC，分别位于上游 can/dbc/Daybreak/ 与 can/dbc/HighNoon/ 两个目录，并随附上游 docs/README.md 与顶层 MIT LICENSE。目录结构本身就是第一条信息：两代车并不共用一份网络定义，而是各自维护一整套，跨代之间没有版本继承关系。

    按单文件看落差极大。最小的两份是 Daybreak/contactor.dbc 与 HighNoon/SteeringCAN.dbc，各只有 2 条报文；最大的 HighNoon/CarCAN.dbc 有 55 条报文、305 条信号，单份就占全部 105 条报文的一半以上、全部 493 条信号的 61.9%。把它当「车队 CAN 数据集」整体引用会严重失真——重心几乎全在一份文件上。

    文件 所属代次 报文数 信号数 平均信号 / 报文
    can/dbc/Daybreak/bps.dbc Daybreak 15 22 1.47
    can/dbc/Daybreak/contactor.dbc Daybreak 2 11 5.50
    can/dbc/Daybreak/controls.dbc Daybreak 6 25 4.17
    can/dbc/HighNoon/CarCAN.dbc HighNoon 55 305 5.55
    can/dbc/HighNoon/BPSCAN.dbc HighNoon 19 63 3.32
    can/dbc/HighNoon/LightingCAN.dbc HighNoon 6 57 9.50
    can/dbc/HighNoon/SteeringCAN.dbc HighNoon 2 10 5.00

    两代车的量级对比

    Daybreak 侧三份共 23 条报文、58 条信号；HighNoon 侧四份共 82 条报文、435 条信号。后者的报文数约为前者的 3.6 倍，信号数约为 7.5 倍。也就是说，代次更替不只是加了几个节点，而是单位报文承载的信号量整体翻了一倍（2.52 对 5.30）。

    代次 保留文件数 报文合计 信号合计 功能域
    Daybreak 3 23 58 电池包（BPS）、接触器、整车控制
    HighNoon 4 82 435 整车（CarCAN）、电池（BPSCAN）、灯光、转向
    合计 7 105 493 七份文件，互不覆盖

    信号密度决定了每份 DBC 的读法

    把信号数除以报文数得到的密度，是这几份文件里最实用的判据。它不需要打开文件就能告诉你：这份定义主要承载的是离散状态位，还是打包好的连续测量量。密度小于 2 的文件基本是「一条报文一个状态」，读数容易但信息量有限；密度大于 9 的文件则几乎必然是位域打包，必须逐位拆解才能用。

    密度档位 平均信号 / 报文 落在档位内的文件 典型形态 使用建议
    稀疏（小于 2） 1.47 Daybreak/bps.dbc 单条报文只承载少量状态或告警位 逐位确认含义，不宜当作连续测量量使用
    中等（3 到 6） 3.32、4.17、5.00、5.50、5.55 HighNoon/BPSCAN.dbc、Daybreak/controls.dbc、HighNoon/SteeringCAN.dbc、Daybreak/contactor.dbc、HighNoon/CarCAN.dbc 状态位与测量量混合 先抓运行日志看取值分布，再定缩放与偏移
    密集（大于 9） 9.50 HighNoon/LightingCAN.dbc 位域打包大量开关与枚举 按位拆解，逐位与实车现象对齐

    需要强调一点：密度是归档方统计出的 BO_ 与 SG_ 行数之比，它反映的是文件的组织方式，不代表信号已被验证。归档说明写得很清楚——具体车辆修订版本、组件固件与信号准确性均未独立核验。

    另一个不该忽略的落差在命名口径上。Daybreak 这一侧按功能块命名（bps、contactor、controls），HighNoon 这一侧则按物理总线命名（CarCAN、BPSCAN、LightingCAN、SteeringCAN）。两套口径不同，意味着不能靠文件名去推断两代车信号的对应关系，跨代比对只能落到逐信号的位与缩放上。

    被拦下的文件与权利边界

    这一批有五类文件没有进入归档，理由分两种，处理方式也不同。区分清楚很重要，因为「内容为空」与「权利未定」在工程上的后果完全不一样：前者是这份定义本来就没有可用信息，后者是信息可能存在但你不能用。

    对象 拦下理由 性质 处理动作
    HighNoon/DAqCAN.dbc 不含任何报文与信号定义 内容为空 不收录
    Prohelion 组件文件 待原始厂商数据权利审查 权利未定 暂缓收录
    TPEE MPPT 组件文件 待原始厂商数据权利审查 权利未定 暂缓收录
    Elcon 组件文件 待原始厂商数据权利审查 权利未定 暂缓收录
    电机控制器组件文件 待原始厂商数据权利审查 权利未定 暂缓收录

    DAqCAN.dbc 值得单独记录：DAQ 这样的名字很容易让人以为它提供采集通道的完整定义，实际上归档时它是空文件。此外，保留下来的 CarCAN.dbc 是一份聚合文件，其中引用了 BPS、MPPT 等组件的信号，但这些信号的原始来源并未独立确认。

    校验值与去重：怎样确认拿到的是同一份文件

    归档为每份 DBC 都登记了 Git blob 与 SHA-256，快照修订为 04d2b3286f50d8f4119d4dc11b7344140f449d15。两者用途不同：Git blob 用于在仓库内部定位文件版本，SHA-256 用于在仓库之外确认取到的字节是否一致。做二次分发或长期存档时，两个值都该留。

    文件 Git blob SHA-256
    Daybreak/bps.dbc 27f2385d0e3d316841e73db2b51631cdaad25637 b84a9d61eb276587241b39d24792c6cb1c42eb3b6efaad3ecfa727d279f8de32
    Daybreak/contactor.dbc 11745daca9b071eb933a59471ed630c79510eaaf 58ae79db80cb0d20e3dd2b585231b72f8a50bf41800fdd0d0f1878200a134672
    Daybreak/controls.dbc db2678346ce5e7ded982f56ecfa1971a87cfc96d 5484aa7a1ea8e4cc3925d5e714d5f37e58bd022569a4a106fa28ce5d1e06ae32
    HighNoon/CarCAN.dbc 175bc244c2a250857d393a27db6ffff1451bb906 fdd068b71ee3c891e3733d716c8ab4b8df211187892f5ed351dfe4f6f3076fbd
    HighNoon/BPSCAN.dbc 56048d7c6f5d0fad5c655be31f00af5516717a6c 4619aa34e75767a5e05557fa092fa883f90045147cb5e875ac352e7d9f95031f
    HighNoon/LightingCAN.dbc bcae89e10bf3dcb9088465061ceaf4eefcfac5de 0a5fdefcc7f4bdbe5fa23161b544561704600e0fb7675360551381872d2d06ed
    HighNoon/SteeringCAN.dbc a6548a3e1ea4e5ba12af333e622be03efd10f121 64e87d4458729fed6b3d9e8866e26d95d20d113be29dc117fe57fd449e37f6cb

    比对时还有一个容易踩的坑：同一份逻辑文件在不同检出环境下可能呈现 CRLF 与 LF 两种字节序，直接按字节比较会把同一份文件误判成两份。归档方在其他项目上正是用 CRLF 归一化来识别重复的，这里同样应当先归一化再比对。

    工程侧：MCU 端口移植的四项硬要求

    随附的上游文档描述的是一套面向定制 STM32 PCB 的共享嵌入式代码仓库，本身不是 CAN 数据集。它与 DBC 的关联在于：DBC 里定义的报文最终由这些 MCU 上的固件收发，端口是否移植完整，直接决定某条报文在车上有没有对应的实现。

    顶层 Makefile 编译 STM32 所需的全部文件，但设计上不打算被直接调用，而应由另一个 Makefile 调用。测试统一放在 test/ 目录，测试文件以 _test.c 结尾，命令形如 make TEST=blinky PROJECT_TARGET=stm32g473xx，烧录用 make flash。CI 侧提供 makeAllTests.py，支持 -v、-t TESTS、-p PORTS、-h 四个选项，默认对所有端口编译全部测试。

    一个合法端口必须齐备的四样东西

    要素 命名规则 文档给出的示例
    端口目录 位于 stm/stm32f4xx、stm/stm32l4xx 或 stm/stm32g4xx 之下，用 MCU 通用名命名 stm32f413、stm32l431
    链接脚本 形如 STM32*_FLASH.ld，须包含处理器全名 STM32F413RHTx_FLASH.ld、STM32L431CBTx_FLASH.ld
    启动汇编 startup_stm32 加四位系列与线别再加 xx，含向量表与基础异常处理（最关键的是 Reset_Handler） startup_stm32f413xx.s
    配置文件 以精确 MCU 名命名，空格分隔列出要禁用的 BSP 模块 stm32l432kcu.cfg，内容 BSP_DISABLE=CAN UART ADC

    文档特别提醒：请核对 MCU 上实际存在的外设再填写 BSP_DISABLE，否则会遇到奇怪的构建错误。对 CAN 相关项目来说这条尤其重要——如果误把 CAN 写进禁用列表，DBC 里定义得再完整，固件侧也发不出对应的帧。

    常见问题

    两代车的 DBC 能不能按文件名直接对齐？

    不能。Daybreak 侧的命名偏功能块（bps、contactor、controls），HighNoon 侧则偏物理总线（CarCAN、BPSCAN、LightingCAN、SteeringCAN），两套命名口径不同。加上 CarCAN.dbc 是聚合文件，其中引用的 BPS、MPPT 等组件信号的原始来源并未独立确认，跨代只能逐信号比对位与缩放，不能靠文件名推导。

    为什么 bps.dbc 有 15 条报文却只有 22 条信号？

    它平均每条报文只挂 1.47 条信号，是 7 份文件里最稀疏的一份。这种密度通常意味着报文主要承载状态或告警位，而不是连续测量量。在拿它做趋势分析之前，需要逐条确认每个位的含义与有效性，不能假定它自带完整的物理量定义。

    DAqCAN.dbc 与四类组件文件为什么没被收录？

    理由不同。DAqCAN.dbc 在归档时不含任何报文与信号定义，属于内容为空，因此不收录；Prohelion、TPEE MPPT、Elcon 与电机控制器这四类组件文件，则是因为原始厂商数据权利尚待审查而暂缓收录，属于权利未定。前者没有可用信息，后者可能有但你不能用。

    CarCAN.dbc 有 305 条信号，能当作整车信号全集吗？

    不能。归档说明指出它是聚合文件，引用了 BPS、MPPT 等组件的信号，而这些信号的原始来源未经独立确认；同时归档方明确写明，车辆修订版本、组件固件与信号准确性均未核验。它适合作为总线结构的索引，不能直接当作已验证的信号全集使用。

    这些 DBC 对应的 MCU 端口移植要准备什么？

    四样东西：一是在 stm/stm32f4xx、stm/stm32l4xx 或 stm/stm32g4xx 下以 MCU 通用名建立端口目录；二是形如 STM32*_FLASH.ld 且含处理器全名的链接脚本；三是 startup_stm32 加四位系列名加 xx 的启动汇编，内含向量表与 Reset_Handler；四是以精确 MCU 名命名的配置文件，用空格分隔列出要禁用的 BSP 模块，例如 BSP_DISABLE=CAN UART ADC。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/lhr-solar-daybreak-highnoon/SOURCE.md（7 份字节互异 DBC 的目录归属、逐文件报文与信号数、各文件 Git blob 与 SHA-256、DAqCAN.dbc 为空故不收录、四类组件文件待厂商数据权利审查、CarCAN.dbc 为聚合文件且信号来源未独立确认、车辆修订与固件未核验的说明）
    • 项目 01 —— public-can-dbc-datasets/additional/lhr-solar-daybreak-highnoon/README.md（顶层 Makefile 需由另一 Makefile 调用、test 目录与 _test.c 命名约定、make TEST 与 PROJECT_TARGET 用法、make flash、makeAllTests.py 的四个 CI 选项、STM32 端口四要素与 BSP_DISABLE 配置格式）

    免责声明

    本文所述报文数、信号数与文件路径均来自公开开源仓库的说明文档，属第三方逆向工程与团队自建产物，未经独立实车核验，也不代表车辆制造商的官方数据。不同车辆修订版本、组件固件与市场可能存在差异。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。

    更新记录

    • 2026-10-14 初稿

  • MARV 无人车的 CAN 集成层：35 报文与 115 信号

    结论：MARV 无人车的 CAN 集成层只有一份 marv.dbc，规模是 35 条 BO_ 报文、115 行 SG_ 信号，平均每条报文 3.29 条信号。它落在 marv_driver 包的 resource/ 目录里，与自定义消息包、场景包、惯导驱动并列。真正限制复用的是三处未核验：平台硬件、DBC 信号校验、以及它并非量产车型定义。

    集成层的落点：一份 DBC 与四个 ROS 包

    归档只保留了一个文件：colcon_ws/src/marv_driver/resource/marv.dbc。把它放在 driver 包的 resource/ 下，说明这个项目把报文定义当作驱动的一部分来管理，而不是外部配置文件。这个位置决定了 DBC 的更新节奏与驱动代码同步，改信号定义等于改驱动包。

    同一工作空间里并列着四个包。理解它们的分工，才能判断一条 CAN 信号从总线到控制回路之间要穿过几层。

    包 上游说明 在集成链中的位置
    marv_driver Basic system functions 归档的 marv.dbc 位于该包 resource/ 目录，是报文定义的落点
    marv_msgs Custom messages package 自定义消息类型定义，说明文档未给出消息清单
    marv_scenarios 用户实现的场景，例如 waypoint_navigation 场景层，说明文档仅举了航点导航一例
    sbg_ros2 The SBG INS driver 惯性导航数据源，与总线信号并行

    规模与统计口径

    35 条报文与 115 行信号是归档方统计 BO_ 与 SG_ 行数得出的。这个口径只说明文件里定义了多少条报文、多少行信号，不代表每一条都已被实车验证。作为对照，同为车队级归档的水冷式方程式项目通常在 50 到 115 条报文的量级，MARV 属于偏小的一侧。

    指标 数值 口径说明
    报文定义（BO_） 35 按 BO_ 行数统计
    信号定义（SG_） 115 按 SG_ 行数统计
    平均信号 / 报文 3.29 由上述两项相除得出
    归档文件数 1 marv_driver/resource/marv.dbc

    归档说明还给出了该文件的完整性校验值：Git blob 182c2fb5f6c02d8ef26c26b2adaa564174f1c2f1，SHA-256 4aab0907c9c43435b11c8729c725c092f98667deb868cc7c6356ed5eb8f3dddc，快照修订为 5b7ed5f6a5547a63407562572b31243f9c5a35a7，采集日期 2026-10-04。

    构建、运行与开机自启

    构建链路相当固定：先在 REACH 车载计算机上按「reach setup」文档装齐依赖，再 source ROS 2 galactic，最后在 colcon_ws 目录内执行 colcon build --symlink-install。这里没有给出依赖清单，意味着环境不可复现——换一台机器时，第一步的「装齐依赖」只能靠文档之外的信息完成。

    运行方式有三套，分别对应调试、常规与部署。测试用途下 ./marv_start.sh 会启动一个 screen 终端会话，适合现场看输出；常规使用则依赖服务在开机时自动拉起，需要人工干预时另有 ./marv_restart、./marv_stop、./marv_start 三个脚本。

    场景 命令 说明
    测试用途 ./marv_start.sh 启动一个 screen 终端会话，便于直接观察节点输出
    常规使用 开机自动启动；./marv_restart、./marv_stop、./marv_start 需先在 reach setup 文档中完成服务配置
    服务管理 sudo systemctl enable marv_package、start、stop、systemctl status marv_package enable 用于开机自启，start 与 stop 用于手动控制，status 查状态
    会话清理 screen -r 重新接入；killall screen 接入后用 ctrl + C、ctrl + D 逐个关闭终端

    读这份文档时有一处需要自己纠正：上游把「禁用服务」的命令也写成了 sudo systemctl enable marv_package，与启用命令完全相同。按字面执行达不到禁用效果，正确做法应是对应的 disable。这类笔误在自维护文档里很常见，抄命令之前先确认语义，不要照单全收。

    日志与仿真这两套机制合起来，覆盖了从录制到回放再到脚本自检的完整链路，但它们的边界都写在文档里而没有含糊处理。使用时最容易犯的错误是把「跑通了」当成「跑对了」。

    两套 rosbag 与 scenario_starter 的仿真边界

    日志侧提供两套 rosbag：一套记录全部 topic，另一套只记录指定 topic（如导航数据），具体 topic 可在 start_specific_ros_bah.sh 脚本中修改。这种「全量 + 定向」的双轨设计很实用——全量用于事后回溯，定向用于长时间跑车时控制数据量。

    仿真侧则由 scenario_starter 这个额外的 ROS 节点承担，用来模拟 MARV 系统其余部分的行为。它模拟 12V Auto 状态，以及 OCU 发出的 start scenario 命令。文档对它的边界写得很克制：它不模拟任何传感器数据，作用只是在正式路试前先在「陆地」上验证场景脚本能否正常启动。

    手段 覆盖 明确不覆盖
    rosbag（全量） 每一个 topic 说明文档未涉及落盘策略与容量限制
    specific rosbag 指定 topic，例如导航数据 其余 topic 不记录；需手工维护脚本内的 topic 列表
    scenario_starter 节点 12V Auto 状态、OCU 的 start scenario 命令 任何传感器数据；只能给出脚本是否启动正确的指示

    把这三行放在一起看，结论很直接：这套工具链能验证「脚本会不会崩」，但不能验证「车会不会开对」。传感器数据必须来自真实车辆或另行搭建的仿真。

    归档快照与权利状态

    归档只保留了一个文件，因此完整性校验相对简单：路径 colcon_ws/src/marv_driver/resource/marv.dbc，Git blob 182c2fb5f6c02d8ef26c26b2adaa564174f1c2f1，SHA-256 4aab0907c9c43435b11c8729c725c092f98667deb868cc7c6356ed5eb8f3dddc，快照修订 5b7ed5f6a5547a63407562572b31243f9c5a35a7，采集日期 2026-10-04。归档方确认保留字节与所钉住的 Git blob 一致，且在本地存档中没有字节相同或经 CRLF 归一化后相同的重复项。

    权利侧的表述需要读仔细：归档保留了仓库的 MIT 许可证与上游 README，同时写明各组件数据的独立来源并未确立。这两句话不矛盾，但含义差别很大——MIT 覆盖的是仓库自身携带的内容，不等于覆盖项目所引用的第三方组件数据。把它并入闭源产品或对外再分发之前，组件部分仍需单独确认。

    常见问题

    marv.dbc 的 35 条报文分别对应哪些硬件？

    归档说明没有给出逐条映射。文件位于 colcon_ws/src/marv_driver/resource/marv.dbc，规模为 35 条 BO_ 报文与 115 行 SG_ 信号；归档方同时写明具体平台硬件与 DBC 信号校验均未独立检查，且这不是量产车型定义。要确定报文与硬件的对应关系，需要结合 marv_driver 的源码自行核对。

    为什么构建步骤要固定 ROS 2 galactic？

    因为构建与运行步骤是按这个发行版写的：构建前需 source ROS2 galactic，相关脚本按 /opt/ros/galactic/setup.bash 的路径组织。换成其他发行版时这些路径与包名需同步调整，而说明文档没有提供其他发行版下的验证记录。

    两套 rosbag 应该怎么选？

    按用途分：一套记录全部 topic，适合事后完整回溯；另一套只记录指定 topic（例如导航数据），适合长时间跑车时压住数据量。定向那套的 topic 列表写在 start_specific_ros_bah.sh 脚本里，改场景时要记得同步维护，否则关键信息不会被记录。

    scenario_starter 能不能代替实车路试？

    不能。它只模拟 12V Auto 状态与 OCU 发出的 start scenario 命令，用于在正式路试前验证场景脚本能否正常启动。上游说明明确指出它不模拟任何传感器数据，因此只能给出「脚本是否启动正确」的指示，无法验证控制行为是否正确。

    这份归档的权利状态如何？

    归档方保留了仓库的 MIT 许可证与上游 README，同时说明各组件数据的独立来源并未确立。MIT 覆盖的是仓库本身携带的内容，不等于覆盖随项目引用的第三方组件数据；再分发前需要单独确认各组件部分的权利。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/case-lab-marv-ros/SOURCE.md（marv.dbc 的路径、35 条 BO_ 报文与 115 行 SG_ 信号、Git blob 与 SHA-256、快照修订与采集日期、平台硬件与信号校验未核验的声明、保留 MIT 许可证与上游 README 的权利说明）
    • 项目 01 —— public-can-dbc-datasets/additional/case-lab-marv-ros/UPSTREAM_README.md（colcon_ws 内四个包的分工、依赖与 galactic 环境下的 colcon build –symlink-install 构建、两套 rosbag 与 start_specific_ros_bah.sh 的 topic 配置、marv_start.sh 与 screen 会话、systemd 服务命令、scenario_starter 节点的仿真覆盖范围与不模拟传感器数据的边界）

    免责声明

    本文所述报文与信号数量、包结构、命令与运行方式均来自公开开源仓库的说明文档，属第三方工程产物，未经独立实车核验。归档方已明确声明平台硬件与 DBC 信号校验未独立检查，且该定义并非量产车型模型。不同平台版本与组件固件可能存在差异。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。

    更新记录

    • 2026-10-14 初稿