星核火花赛车科技

标签： DBC

  • 2008 款 Impala 的 GM CAN 报文：50 个 ID 与 20 条 opendbc 对照

    结论：2008 款 Chevrolet Impala 的 HS-CAN 可以在 OBD-II 6/14 脚以 500 kbit/s、11 位 ID 直接读取，6 次采集共出现 50 个 ID，其中 20 个能在 opendbc 的 gm_global_a_powertrain.dbc 里找到同名条目。但这份档案的全部采集都在原地怠速下完成，轮速、车速、转向角三类公式只有定义没有实测；转速公式还必须先纠正字节偏移——原来的 b[0]、b[1] 取法是错的。

    采集条件先决定了这份档案能证明什么

    档案由 5 段约 15 秒的针对性采集（制动踏板、换挡、左转向灯、方向盘扫掠、ACC 累积基线）加 1 段约 90 秒的累积基线组成，车辆状态全程为静止、发动机怠速。这个条件直接限定了结论范围：凡是依赖车辆运动的信号，在这份档案里都只能给出公式，不能给出验证。

    仓库侧的量级有两个口径：随附的自定义 DBC 登记 22 条报文、71 条信号，数据 README 则将高置信度信号记为 17 条、自定义 DBC 记为 40 条以上。取哪个数取决于你要的是「报文定义条目」还是「实车核对过的信号」——前者包含大量照搬 opendbc 的定义，后者才是原地工况真正能背书的量。

    已确认的解码与一处必须先纠正的公式

    ID 源模块 信号 公式 单位
    0x0C9 PCM 发动机转速 uint16_BE(b[1], b[2]) / 4 RPM
    0x0C9 PCM 制动踏板标志 b[5] & 0x01 bool
    0x0F1 EBCM 制动压力 b[1]（原始值，估计约 1.3 kPa/单位） kPa
    0x1F5 TCM PRNDL 挡位 b[3]：1=P 2=R 3=N 4=D 枚举
    0x191 PCM 喷油脉宽 uint16_BE(b[0], b[1]) * 4 µs
    0x4C1 PCM 冷却液温度 / 进气温度 b[2] - 40 / b[3] - 40 °C
    0x4D1 PCM 机油温度 b[5] - 40 °C
    0x3C1 / 0x3C9 BCM/TPMS 胎压（前左？/ 前右？） b[1] * 2 kPa
    0x514 / 0x4E1 PCM VIN 分段 1 / 2 ASCII b[0:8] 字符串
    0x1E1 ASCM 方向盘按键 ACC / LKA / 车距 / 驾驶模式 位域
    0x2C3 未知 3 组 uint16 未解，缓慢变化 —

    转速公式的纠正很关键：原始草图用 ((data[0] << 8) | data[1]) / 4 解码，实际 0x0C9 的 b[0] 高 4 位是一个 0–F 循环的滚动计数，不是转速数据。改为 b[1]、b[2] 后，怠速原始值落在 2624–3240，除以 4 得 656–810 RPM，与实车怠速吻合。同理，0x191 的喷油脉宽在怠速解出 0x06AA = 1706，乘 4 µs 得 6824 µs，与 GM 3.9L V6 进气道喷射的怠速脉宽量级一致。

    方向盘扫掠为什么没有解出转向角

    0x19D 曾被认为是转向或悬架模块，但方向盘扫掠采集里没有一个字节出现干净的单调扫掠：b[6] 变化最多（扫掠中出现 221 个不同值），可怠速时同样剧烈变化，因此不能判定为转向角。b[0] 的位 7–5 是一个四态滚动计数（0x20 → 0x60 → 0xA0 → 0xE0）。档案给出的最佳猜测是悬架高度或车身姿态，标注为未确认。

    opendbc 对照带来的四处纠正

    50 个 ID 中有 20 个与 opendbc 的 GM Global A 动力总成定义同名。但 2008 款 Impala 并不是 opendbc 的支持车型（该库面向 2016 年以后的 Volt、Malibu、Bolt、Silverado），因此 ID 一致不等于字节定义一致。对照后纠正了四处先前判断：

    ID 先前判断 opendbc 结论 对使用的影响
    0x4E1 标定 ID 第 1 段 VIN_Part2，VIN 后 8 字符 本车解出 81371876，不是标定号
    0x2F9 BCM 心跳 / 计数器 BRAKE_RELATED_2，用户制动压力为位偏移 47 处的 9 位值 b[0] 的自增是报文内部滚动计数，与 BCM 无关
    0x184 BCM 滚动计数 PSCMStatus，b[1] 为 RollingCounter 归属从车身模块改为转向助力控制模块
    0x1C3 疑似喷油相关 GasAndAcc，油门信号在 b[6] b[0:4] 的 uint16 对本年款含义另需确认
    0x140 未出现 opendbc 定义 BCMTurnSignals（0=None 1=Left 2=Right） 采集的 50 个 ID 里没有 0x140，转向灯状态不可得

    转向灯的缺失有两种解释：2008 款 BCM 用了不同 ID，或者该报文是事件驱动的、只在转向灯激活时才发。区分方法写在档案里：从采集开始前就持续拨住转向灯杆，看基线里是否出现新 ID，并专门盯 0x140。

    证据边界：三类公式没有实车验证

    信号 / 条目 当前状态 还缺什么验证
    0x0F1 制动压力 b[1] 静止 5–9，制动升至约 196；估计 1.3 kPa/单位 未与压力传感器基准对照，比例系数未确认
    0x1E5 转向角 按 opendbc 解 int16_BE(b[0],b[1]) * 0.0625，样本 0x8200 得 −2016°，超出量程 需要带已知转向位置的行驶采集；ID 与模块归属已确认，比例未确认
    0x348 / 0x34A 轮速 ×0.0311 km/h，四轮 + 方向位；采集全零 需要停车场低速蠕行采集确认比例与轮位分配
    0x0C1 / 0x0C5 轮速 110 Hz 成对冗余广播，疑似 uint16_BE(b[0],b[1]) 与 uint16_BE(b[4],b[5]) 单位与轮位均未确认
    0x3E9 车速 uint16_BE(b[0],b[1]) * 0.01 mph，采集全零 需要已知车速的行驶采集
    0x1C7 曲轴计数 b[2:4] 在 4 个相差约 16383 的值间循环 定为曲轴位置编码器或高分辨率点火计时，属推断
    自定义 DBC 一致性 AcceleratorPedalPos 起点在位 48，而报文 BO_ 417 只声明 3 字节 自相矛盾，严格解析器可能直接拒绝该 DBC
    采集与授权 原始采集文件不在受检快照中；仓库未附许可证 只能作离线研究，再分发前须先确认权利

    无解码进展的 ID

    ID 约 Hz 样例载荷 说明
    0x120 <1 00 DA 77 00 00 仅见 3 帧，疑似初始化
    0x134 / 0x138 10 / 1 00 00 10 / 00 00 00 00 0B 近乎常量，不在 opendbc 中
    0x17F / 0x1CD / 0x1F3 / 0x334 / 0x500 10 / 56 / 31 / 33 / 4 全零 五个 ID 载荷恒为零
    0x1F9 33 00 00 00 00 80 00 FF 00 近乎常量，不在 opendbc 中
    0x2C3 20 08 55 06 A0 07 4A 3 个 uint16，缓慢变化
    0x3F1 4 00 CB 56 18 FF FC b[1] 随时间缓慢递增
    0x4E9 1 C1 40 常量，疑似模式标志
    0x771 / 0x772 / 0x773 / 0x77F 1 7 字节，多为零 四个 UDS/KWP 诊断响应节点在总线上存在

    另有 0x3F9 已部分解开：b[1:5] 是一个 32 位值，相邻两次采集之间增量分别约 2280 万与 8080 万，与微秒级运行计时吻合，可作会话时间戳使用。

    档案自己列出的六项补采

    要把上面那些「有公式无验证」的条目推进到可用，档案给出了顺序明确清单：一次已知车速的行驶采集可同时验证 0x3E9、0x348、0x34A 与 0x0C1、0x0C5，并解锁 0x1A1 油门；急加速与急减速用来验证非怠速区间的 0x0C9 转速公式与 0x191 喷油脉宽，同时激发 0x1E9 的横向加速度与横摆率；方向盘全程缓慢扫掠用来确定 0x1E5 的比例系数；持续拨住转向灯杆用来区分 0x140 是事件驱动还是根本不存在；开关暖风或空调用来试探 0x0F9 与 0x4E9；最后一项是 OBD-II 1 脚——部分 2008 款 GM 车型在该脚上有低速 GMLAN，若可接入，能看到 HS-CAN 上看不到的车身功能。

    常见问题

    0x0C9 的发动机转速为什么不能用 b[0] 和 b[1] 计算？

    因为 0x0C9 的 b[0] 高 4 位是一个 0–F 循环的滚动计数，不属于转速数据。正确取法是「data[1] 左移 8 位后与 data[2] 合并，再除以 4」；用它解怠速数据得到 656–810 RPM，与实车怠速一致，而原取法会把滚动计数混进高位。

    转向灯状态为什么在这份档案里找不到？

    opendbc 把 BCMTurnSignals 定义在 0x140，但采集到的 50 个 ID 里没有 0x140，而同一 BCM 的 0x12A 与 0x1F1 都在，说明模块本身在总线上活动。可能是 2008 款用了不同 ID，也可能是该报文事件驱动、只在灯亮时才发，需要一次从采集前就持续拨住灯杆的专项采集来区分。

    50 个 ID 里有 20 个能对上 opendbc，剩下 30 个能直接照搬吗？

    不能。2008 款 Impala 不在 opendbc 的支持车型内，该库主要覆盖 2016 年以后的 GM Global A 车型，ID 同名不代表字节定义相同。档案里就记录了 0x1C3 的分歧：opendbc 认作 GasAndAcc、油门在 b[6]，而本年款在 b[0:4] 出现了喷油量级的 uint16 对。

    0x0F1 的制动压力能用于量化分析吗？

    只能用于相对比较。b[1] 在静止时为 5–9、重踩时升到 186–196，趋势清楚，但 1.3 kPa/单位是由 186 单位约等于 242 kPa 反推的估计值，档案明确标注需要与压力传感器基准对照后才能确认，不能当作绝对压力。

    这份档案能用于行驶中的车速与轮速解析吗？

    不能直接用于。全部采集都在静止怠速下完成，0x348、0x34A、0x3E9 的载荷在所有采集里都是零，0x0C1、0x0C5 也接近零。公式来自 opendbc 定义与字节位置推断，必须先做一次已知车速的低速行驶采集才能确认比例系数与轮位分配。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/can_data/analysis/gm/chevy_impala_2008.md（50 个 ID 的总表、已确认解码、opendbc 对照与无进展 ID）
    • 项目 01 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/SOURCE.md（DBC 的 22 报文 / 71 信号、DBC 一致性问题与授权边界）
    • 项目 01 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/can_data/README.md（采集目录结构、车型覆盖表与高置信度信号计数）

    免责声明

    本文所述解码均为社区逆向工程产物，不代表通用汽车或任何车辆制造商的官方数据。文中所有 ID、公式与数值均来自上述公开仓库的说明文件，未经独立实车验证；不同车型年款、市场与 ECU 版本可能存在差异。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。

    更新记录

    • 2026-10-15 初稿

  • SAM 电动车 CAN 笔记：37 报文、161 信号与一处字节序纠错

    结论：SAM 电动车这份 CAN 资料的价值不在规模，而在它把每一条解码修正的证据来源都写清楚了：37 条 BO_ 报文、161 条 SG_ 信号之外，另有十余处改动被分成「固件确认」「车主确认」「推断未确认」三档。最关键的一条是 0x292 的 FECU 故障寄存器——字节 6 与字节 7 相对标准 Intel 24 位读法是互换的，按错的字节序会把 0x200000 读成 0x00020。二次使用前应先按证据等级过滤，而不是把 DBC 整体当标准答案。

    规模与总线前提：37 条报文是怎么构成的

    这份 DBC 面向单一项目车辆，覆盖电池、电机、充电器、ECU、仪表与故障六类流量，不属于任何厂商车系的通用定义。报文总数 37 条里有一条是 Vector 的零长度独立信号容器，并非实际发送的帧，因此真实可收发的报文比计数少一条。总线速率是 125 kbit/s，但这个数字并不来自 DBC 自身：BS_: 行没有记录波特率，125 kbit/s 是车辆的已知实际设置，在回放工具里作为默认值写入。

    轨迹侧的限制同样需要提前确认。配套解析只支持 PCAN-View 的 .trc v2.0，早期 v1.1 格式（列布局不同、没有 DT 标记）会被解析成零行，表现为「未找到任何 CAN 数据帧」的提示而不是报错崩溃。SAMPlay 记录仪的 .TXT 导出也被接受，且两种格式共用一个加载按钮，靠嗅探首个非空行的内容来分派，而不是看扩展名——后者只有 .txt 后缀，从扩展名上无法与其他文本区分。

    时间轴上的取数模型也值得先明确：加载时每个信号在整段轨迹上完整绘制一次，光标滑块移动的是一条竖线，仪表、指示灯与状态标签按零阶保持重新取值，也就是取「最后一次实际收到的值」而不是插值。播放由 50 毫秒周期的定时器驱动，且每一拍都按起始时刻加实际经过的时间设置光标，而不是按固定步长累加，因此播放速度与墙上时钟一致，不受回调抖动影响。单步前进或后退跳到的是相邻帧自身的时间戳，所以「一步」始终等于一条报文。

    项目 数值 说明
    BO_ 条目 37 含 1 条零长度独立信号容器，非真实发送帧
    SG_ 条目 161 覆盖电池、电机、充电器、ECU、仪表、故障
    总线速率 125 kbit/s DBC 的 BS_: 行未记录，取车辆已知设置
    轨迹格式 .trc v2.0、SAMPlay .TXT v1.1 解析为零行
    电芯数 36 0x406 循环 37 个槽位，第 37 槽恒为 0 mV
    采样模型 零阶保持 刷取取「最后一次实际收到的值」，不做插值

    三档证据：哪些改动能直接用

    这份笔记最值得借鉴的做法，是把修正按可信度分档，而不是统一标注为「已修正」。固件确认档的依据是车辆仪表节点的 STM32 CAN 接收处理代码——代码不会撒谎，因此符号位、报文内容、字节序这类结构性错误一旦被代码确认，就可以当定论用。车主确认档来自车辆使用者的直接说明。推断档则只有数据回归作为支撑，必须保留原始计数并列显示，不能当作标定过的物理单位。

    证据等级 涉及报文与信号 改动内容 判据
    固件确认 BO_912 Motor_speed 无符号改为有符号 此前出现的约 65535 rpm 假尖峰由此而来
    固件确认 BO_658（0x292）FECU_error 字节 6 与字节 7 互换 接收处理以 16 位指针取 RxData[6] 起两字节，再或上 RxData[5] 左移 16 位
    固件确认 BO_448 VoltageLV 系数由 1 改为 0.00625 V/count 固件阈值判断中直接出现该常数，改后读数约 13.8 V
    固件确认 BO_960（0x3C0）Ustopcharge 解码前先屏蔽字节 1 高 2 位 该 ID 在固件中被复用为 3 条子报文，高 2 位是复用标志而非数据
    固件确认 BO_400（0x190） 占位信号名整体替换为 5 个 Skai 状态与故障位 固件对应分支定义了启用、功率模块错误、硬件错误、驱动错误、驱动告警
    车主确认 BO_657 trip_km 系数由 1 改为 0.1 原始值按 100 m 步长存储，车主于 2026-08-05 确认
    推断未确认 BO_401/BO_656 扭矩 系数由 1 改为 0.005 Nm/count 原始值在全部 5 段行驶日志中都精确截幅在正负 10000
    推断未确认 BO_657 加速与刹车踏板 有符号改为无符号 各日志中 28% 至 45% 的帧原始值落在 32768 以上

    为什么 0x292 必须脱离 DBC 单独处理

    故障寄存器不是一个连续字段，而是由三段拼接而成：字节 6 是最低字节，字节 7 是中间字节，字节 5 是最高字节。这种字节置换无法用一条连续的 SG_ 表达，因此该信号在 DBC 里干脆不再有信号行，改由解码函数直接从原始字节重建。后果很直观：按旧的连续小端 24 位读法，5 段行驶日志里每一帧都被解成 0x00020，而按固件正确的字节序是 0x200000——两者相差四个数量级，故障码从「20」变成「200000」。这类错误不会表现为异常，只会表现为一个看起来合理的错误码，所以必须拿固件代码交叉验证，而不是靠肉眼比对数值范围。

    推断档：系数是怎么回归出来的

    推断档的共性是找不到固件依据，只能拿总线上的另一个独立测量做参照。直流母线电压拿 BMS 的包电压做基准，比例稳定在 0.0997 附近，等于精确的一分之一；充电器高压沿用同一族系数，实测比例 0.06211 与十六分之一相差约 0.6%，落在两个独立电压传感器加零阶保持重采样的合理误差内。12 V 侧电流没有独立参照，改用功率平衡交叉验证：13.8 V 乘以换算后的电流，得到的 DCDC 输出功率中位约 160 W、区间 95 至 215 W，与车辆已知典型负载吻合。

    信号 报文 采用系数 回归证据
    skai_DC_Link_Voltage BO_656（0x290） 0.1 V/count 与包电压比值 0.0997 正负 0.002，样本约 36k
    VoltageHV BO_448（0x1C0） 0.0625 V/count 比值 0.06211 正负 0.00001，与包电压同族系数
    DCDC_12V_Current BO_704（0x2C0） 0.0625 A/count 功率平衡后中位约 160 W，区间 95 至 215 W
    DCDC_HV_Current BO_704 0.0625 A/count（仅对称推定） 约 36k 样本恒为 0，无任何非零验证点
    Inside_temp/Outside_temp BO_960（0x3C0） 0.1 摄氏度/count 系数为 1 时读数 280 至 377 度，物理上不可能
    扭矩（指令与实际） BO_401/BO_656 0.005 Nm/count 正负 10000 count 对应实车约正负 50 Nm

    仍以原始计数呈现、未做标定的有四类：DCDC_HV_Current、Voltage_12V、加速与刹车踏板开度、Ustopcharge。它们在界面上带原始计数标记，避免被误读成百分比或电压。

    电芯内阻：两个不能跳过的测量约束

    逐芯内阻估算用的是同一电芯相邻两次读数的电压差与电流差，按过原点拟合，这样未知的开路电压及其 SOC 漂移在差分中抵消。方法上有两条约束是数据逼出来的：电流必须取 10 Hz 的 0x386 而不是 1 Hz 的 0x186；电压相对电流存在约 1 秒滞后，忽略滞后会把相关系数从约 0.96 拉低到约 0.74，并使内阻低估约 25%。

    环节 取值 影响
    电流源 0x386，10 Hz 0x186 仅 1 Hz，只作兜底
    电压滞后 0.95 至 1.0 秒 滞后取 0 时相关性约 0.96 降到约 0.74，内阻低估约 25%
    电芯刷新周期 3.7 秒 0x406 循环 37 槽位，第 37 槽恒为 0 mV
    结果（新 BMS 车） 约 0.67 至 0.70 毫欧/芯 R 方约 0.95，95% 置信区间约正负 0.02 毫欧
    结果（原厂 BMS 车） 约 1.8 至 2.5 毫欧/芯 一致离群：10 号 +28%、19 号 +17%、28 号 +13%、12 号 +10%
    已知干扰 BMS 启动垃圾帧 需按 1500 至 5000 mV、电流绝对值 1000 A 以内的合理窗过滤

    两辆车的差异说明这套方法对 BMS 版本敏感：新 BMS 上报的 0x306 内阻最小、平均、最大三个值都是 1.0，看起来是占位值；原厂 BMS 则给出真实数值。跨车比较前必须先确认 BMS 变体。还有两点需要在使用结果时说明清楚：一是这里得到的是约 1 至 4 秒尺度上的有效内阻，包含快速极化，并不等于电芯规格书上的 1 kHz 交流内阻，而且它随温度变化——新 BMS 轨迹里的电芯温度读数平坦在 21 至 22 摄氏度，因此未做温度修正，只在汇总里显示范围；二是充电轨迹是恒流工况，几乎没有可用的电流变化，此时界面直接说明无法计算，而不是给出一个看起来合理的数字。另外，电芯离群判定默认阈值设在相对中位数高出 15% 及以上，在当前约 4% 的离散度下，逐芯排序在不同行程之间只能部分复现，因此单次结果不足以判定某颗电芯劣化。

    验证步骤与三个真实陷阱

    没有交互式显示环境可用，全部功能通过 matlab -batch 无头验证：以带路径参数的构造函数打开轨迹，再直接驱动返回结构体上的回调来模拟拖动、切页与按钮点击，把仪表、指示灯与状态值逐个对照手工解码的原始字节。回放通道则在 MathWorks 虚拟 CAN 回环上验证——一个通道发、另一个通道收——单步、突发顺序、解除武装、断连四类动作都逐帧比对，只有 USB 驱动层未经实测。另外还有一条一次性检查：确认界面配置里引用的每个信号键都真实存在于 DBC，改任一侧都应重跑。

    陷阱 现象 定位与处理
    SAMPlay 文本解析 FECU_error 在 389 帧里恒为 0 sscanf 的 %2x 只跳空白不跳逗号，遇到首个逗号即停，字节 1 至 7 全为初始 0；改用正则取两位十六进制记号后修复。影响面是所有位于字节 0 之外的信号
    效率中位值大于 1 另一辆车未修正时中位效率 1.20 按「电池功率 = k 乘机械功率 + 损耗」逐格拟合，k 约 0.946（本车）与约 0.71（另一辆），两车控制器参数化不同
    「2 秒后 CAN 上无 BMS」故障位 位 0x00200 在 3 份日志中从未置位 已核对原始字节，非解析缺陷：这些日志里 0x186、0x206、0x286、0x306、0x386、0x406、0x486、0x506、0x705 全部缺失，仅有的 0x205 发送方是仪表 ECU，只能说明仪表在命令接触器，不能证明 BMS 在线
    回放安全 接入实车总线后习惯性点播放 连接本身不发送任何帧，需单独勾选「播放或步进时发送」才武装；BLE 断连、CAN 超时、按键三者任一都会释放

    常见问题

    这份 DBC 能直接用于我的车辆解析吗？

    不能。37 条 BO_ 报文与 161 条 SG_ 信号面向单一项目车辆，覆盖电池、电机、充电器、ECU、仪表与故障流量，既不是厂商车系的通用定义，也不构成车型年款适配承诺。可作为同类电动车报文组织方式与修正记录方法的参考。

    为什么故障码会显示成完全不同的数值？

    因为 0x292 的 FECU_error 不是连续小端 24 位字段，而是字节 6 作最低字节、字节 7 作中间字节、字节 5 作最高字节。按标准字节序读会把 0x200000 读成 0x00020，两者相差四个数量级，因此必须按固件接收处理的方式从原始字节重建。

    推断档的系数能不能当标定值用？

    不能。扭矩的 0.005 Nm/count 只依据原始值在 5 段日志中一致截幅于正负 10000 与实车约 50 Nm 上限推出，没有独立传感器做回归；直流母线电压与充电器高压则有比值证据支撑，可信度更高。界面上保留原始计数并列显示，就是为了让使用者自行判断。

    估算电芯内阻时最容易犯的错误是什么？

    忽略电压相对电流约 1 秒的滞后，以及用 1 Hz 的 0x186 替代 10 Hz 的 0x386 作为电流源。前者会让相关系数从约 0.96 降到约 0.74 并使内阻低估约 25%，后者在零阶保持下会显著放大散点。

    回放轨迹到真实总线上有什么前置条件？

    需要车辆网络工具箱与适配器驱动，且连接并不等于发送：必须单独勾选武装开关才会真正发帧。未检测到适配器时会退回到虚拟通道。官方说明也提示，除驱动层外其余代码路径已在虚拟回环上验证，正式依赖前建议再做一次真实硬件冒烟测试。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/janniksteiner-sam-can/PROJECT_NOTES.md（架构、解码修正的证据分级、推断系数回归依据与已知限制）
    • 项目 01 —— public-can-dbc-datasets/additional/janniksteiner-sam-can/README.md（应用定位、支持的轨迹格式与项目文件构成）
    • 项目 01 —— public-can-dbc-datasets/additional/janniksteiner-sam-can/SOURCE.md（37 条 BO_ 与 161 条 SG_ 的规模、两种 BMS 变体差异与许可证状态说明）

    免责声明

    本文所述的 DBC 与解码修正均为社区逆向工程与研究笔记产物，不代表车辆制造商的官方数据。文中数字均来自上述公开仓库的说明文件，未经独立实车验证；不同车型年款、ECU 固件与 BMS 版本可能存在显著差异，跨车套用字节偏移与系数前必须重新回归。该仓库为 GPL-3.0 许可，二次分发前请自行确认其对底层 DBC 与早期贡献的适用性。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。

    更新记录

    • 2026-10-15 初稿

  • Talaria 电动越野车 CAN 信号：250 kbit/s 下 15 个 ID 与四处证伪

    结论：Talaria 电动越野车的车载 CAN 是一条 250 kbit/s、11 位标准 ID、15 个报文 ID、约 92 帧每秒的总线，用一颗 3.3 V 收发器挂在 ESP32-S3 的 TWAI 控制器上即可只读取数。真正有复用价值的不是那张 14 项信号表，而是表里被明确证伪的四处：0x103[0] 不是电量、0x202[6:8] 不是里程、0x490 不是温度也不是单字段、节流需求偏移随固件而变。把这几条排除后再取数，才不会把「看起来像」当成「就是」。

    总线前提与接入方式

    这条总线在电机控制器处即可挂到 CAN_H 与 CAN_L，硬件侧只需要一个 3.3 V 的 SN65HVD230 收发器：发送脚接 GPIO7、接收脚接 GPIO8，直连而非交叉——这一点与同一块板上的 GPS 串口不同，后者是交叉的。CAN 外设用的是 ESP32-S3 自带的 TWAI 控制器，外部模块只承担物理层。

    两个电气细节必须在上电前处理。第一，模块板上那个标着 121 的 120 欧终端电阻要拆掉：车辆总线两端已经各自终端，跨 CAN_H/CAN_L 量到的是 60 欧，再并一个电阻会掉到 40 欧，波形裕量直接被吃掉。第二，一旦 CAN 双线接入，设备的地就通过降压模块的负极与车辆共地，此时再插 USB 会把车辆电池负极接到保护地，同时 USB 的 5 V 与降压模块的 5 V 在 VUSB 上相撞；拔掉车端连接器可以同时隔离这两个风险，遥测数据改走无线链路读取。

    总线默认是只读取模式：收发器从不驱动总线，甚至不应答，因此即便波特率猜错也不会扰动车辆。这一点是整套方案能从「只读」安全扩展到「可写」的前提。

    参数 取值 备注
    波特率 250 kbit/s 扫描子命令会遍历波特率与标准/扩展 ID 组合
    ID 类型 11 位标准 ID 与整车厂常见的 29 位扩展 ID 不同
    总线报文 ID 数 15 固件当前只解析其中 8 个
    帧率 约 92 帧/秒 全总线合计
    终端电阻 60 欧（熄火状态下测量） 读到 120 欧说明只挂到了单端
    接地 无需单独地线 通过降压模块负极已与车辆共地
    DBC 规模 9 条报文、26 条信号行 每条信号的验证过程写在 CM_ 注释里

    已解码信号与字节定义

    下面这张表是这份研究的核心产出。所有偏移都按小端处理，物理量的缩放因子在最后一列。值得注意的是，电芯最高/最低电压与序号共用同一帧的不同字节组，序号分别落在字节 4 与字节 5。

    信号 帧 ID 字节与位 缩放
    车速 0x303 字节 0–1，小端 0.1 km/h
    电机转速 0x203 字节 0–1，小端 1 rpm
    功率 0x203 字节 2–3，小端 1 W
    电流 0x302 字节 4–5，小端 0.1 A
    电池包电压 0x101 字节 0–1，小端 0.1 V
    电量百分比 0x401 字节 0 1 %
    最高电芯电压与序号 0x201 字节 0–1 小端，序号在字节 4 1 mV
    最低电芯电压与序号 0x201 字节 2–3 小端，序号在字节 5 1 mV
    边撑 0x202 字节 0 第 7 位 1 为放下
    骑行模式 0x202 字节 0 第 5:4 位 1 节能、2 运动
    动能回收等级 0x490 字节 0 第 2:0 位 1 至 4
    骑行模式（仪表指令） 0x490 字节 0 第 5:3 位 1 节能、2 运动
    里程 0x402 字节 2–3，小端 1 km
    转把需求 0x202 字节 3–4，小端 单位未确认

    交叉验证给了两个可信锚点：车速与转速在两次独立骑行中保持 5.887 的固定比值，相关系数 0.999，对车速积分也能还原出合理的骑行距离；最高与最低电芯电压的平均值乘以 16 能复现电池包电压到 0.02 V 以内，这坐实了 16 串的电池包结构。这两条把「解析对了」从感觉变成了可检验的判据。

    遥测包里的 CAN 块与门控位

    解码后的车辆数据占遥测包第 50 至 69 字节，配套一个状态字节：第 0 位表示总线存活，第 1 位是边撑，第 3:2 位是骑行模式，第 6:4 位是回收等级。规则只有一条但必须遵守——超过 2 秒没有收到任何帧时，整个字节块会被清零、存活位同时拉低，因此判空要门控在存活位上，而不能相信「速度为零」。否则一辆停着的车和一根拔掉的线在数据上完全一样。里程字段在第 88 字节，取的就是 0x402[2:4]，读到 0 表示还没见过该帧。

    四处已被证伪的字段

    这份研究最值得照搬的不是结论，而是它把「曾经以为」逐条推翻并留下判据的过程。四条错误里前两条是典型的形状误导，第三条是位域切分错误，第四条是跨设备外推错误。

    被误认的字段 为什么看起来像 证伪判据 正确取法
    0x103[0] 当电量 数值形态像百分比 实际电量在别处变化时它恒为 100，几乎可以确定是健康度 取 0x401 字节 0
    0x202[6:8] 当里程 单调递增，形态极像里程计 与车速的相关系数为负 0.0005，两次骑行的每公里计数相差 34% 取 0x402[2:4]，整公里
    0x490[0] 当温度或单字段 整字节与模式的相关系数 0.99，看起来整字节都是模式 第 5:3 位是模式、第 2:0 位是回收等级；节能模式下第 3 位被置起，回收 1 会读成 0x09 而非 0x01 掩 3 位而不是 4 位
    转把需求偏移固定 同车型同帧 ID，默认偏移可复用 本车在 0x202[3:5]，参考日志里那辆车在 0x202[2:4] 且根本不跟随转把 换车必须重新验证偏移

    里程的发现过程有一条通用经验值得单独记：这份研究曾长期写着「总线上没有找到里程计」，而这个结论是从固件捕获的 8 个帧里得出的，0x402 恰恰属于没人解码的那 7 个。后来是照着车辆仪表自己显示的 400 km 去全总线捕获里找这个数，0x402[2:4] 正好读出 400。由于总线上存在 1200 这类整常数（同时出现在 0x101[4:6] 与 0x302[6:8]），单次对上整数只是提示而非证明，因此它被明确标注为待验证——需要一次实际骑行看它自增。

    从只读到可控：0x490 是命令不是回声

    0x490 长期被当作控制器的回声，直到一次按键对比实验才被推翻：连续五次按键里，0x490[0] 每次都先动，0x202 在 20 至 27 毫秒之后才跟着变，同时带上新的模式位与新的需求下限（运动 1100、节能 750）。在仪表持续以 5 Hz 发运动模式的同时注入节能，控制器在整个注入期间被钉在需求 750 上。结论是仪表与控制器是两个不同节点，控制器服从总线上最近一次 0x490，而且从不锁存。

    这就决定了「覆盖」不能以命令的方式实现，只能以持续争论的方式实现：仪表下一帧在 200 毫秒后就会把单次发送的内容推翻，所以只要覆盖还生效，就必须应答仪表发出的每一个 0x490。实测差距很明显——自由运行在 20 Hz 注入会输掉 24% 的帧，而收到即回则在控制器自己的 297 帧里守住了 297 帧。决定成败的是延迟，不是发送频率。

    机制 行为 后果
    锁存 控制器不锁存，服从最近一帧 覆盖必须持续应答，发一次无效
    注入方式 收到即回，守住 297/297；自由运行 20 Hz 丢失 24% 延迟是机制，频率不是
    释放路径 无线断连、CAN 超时、车把按键任一触发 100 毫秒内回到仪表控制
    可验证性 模式可见，回收等级无法验证 回收不带动总线上任何其他量，功率与电流都是无符号的
    仪表显示 仪表不监听总线 覆盖期间仪表显示与实车状态真实不一致
    回收限制 电量高于约 90% 时车辆自行抑制 指令发出但正确地不产生效果

    另外，喇叭与灯光根本不上总线，它们是车把开关直接控制的 12 V 回路；刹车拉杆在部分车上有信号，改装的无传感器拉杆什么也发不出。这些边界决定了这套数据能覆盖到什么程度。

    嗅探工具与验证命令

    逆向过程被固化成四个子命令，全部跑在主机侧，配合一个串口转 CAN 适配器工作。 scan 负责扫波特率与 ID 类型组合，如果到处都是零帧，最常见的原因是 CAN_H 与 CAN_L 接反——无害，换过来即可；sniff 给出实时表格，包含解码后的物理量、每个 ID 的速率、逐字节变化图；events 先自学哪些字节会自行漂移，然后只打印真正的变化，使用时一次只操作一个控件，就能定位该控件落在哪个字节；log 落盘为 .asc、.blf 或 .csv 供离线分析。

    子命令 用途 典型判据
    scan 扫描波特率与标准/扩展 ID 全组合零帧通常是 CAN_H/CAN_L 反接
    sniff 实时表格：物理量、每 ID 速率、逐字节变化图 用于确认波特率与帧清单
    events 过滤自发漂移，只打印真实变化 一次只动一个控件
    log 录制 .asc/.blf/.csv 供离线回归与跨骑行比对

    配套环境搭建只需两条命令：先建虚拟环境并安装依赖，再用 250000 的波特率参数调用对应子命令，串口设备名按实际枚举结果传入。整个链路不需要改动车辆任何部件，这也是只读取数能长期稳定运行的底气。除了这套主机侧工具，固件侧还有一个专门的 CAN 探测程序，它把解码后的仪表直接输出到屏幕与无线链路上——之所以刻意走无线，是因为车辆与 USB 主机任何时候都不能同时连接。

    最后补一条容易被忽略的经验：总线上的 15 个 ID 与实际解析的 8 个之间的落差，本身就是最大的风险来源。任何「总线上没有某个信号」的结论，只有在完整捕获全部 ID 之后才成立；而车辆仪表已经显示的数值，是验证解码结果最便宜的基准。

    常见问题

    这条总线能直接拿来读取车辆数据吗？

    可以，但必须只读取：收发器不驱动总线也不应答，波特率猜错也不会扰动车辆。前提是先拆掉收发器模块上的 120 欧终端电阻，否则总线的 60 欧会变成 40 欧。另外不要同时接 USB 与车辆，两者会在 VUSB 上相撞并把车辆地接到保护地。

    为什么我读到的电量一直是 100？

    因为取的是 0x103 字节 0，那个字段在真实电量变化时保持不变，几乎可以确定是电池健康度。真实的电量百分比在 0x401 的字节 0，缩放为 1%。

    里程到底在哪个帧？

    在 0x402 的字节 2 至 3，小端，单位 1 公里。曾经被误认为里程的 0x202[6:8] 虽然单调递增，但与车速相关系数只有负 0.0005，两次骑行的每公里计数相差 34%，已被排除。由于总线上存在 1200 这类整常数，该结论仍标注为待一次自增骑行验证。

    能不能通过总线改骑行模式？

    可以，但不能用「发一次命令」的思路。控制器服从最近一次 0x490 且不锁存，仪表每 200 毫秒就会覆盖一次，因此必须持续应答仪表的每一帧；实测收到即回守住 297/297，自由运行 20 Hz 会丢失 24%。同时要注意仪表不监听总线，覆盖期间仪表显示与实车真实状态不一致，而回收等级发出后无法从总线验证。

    换一辆同型号车能直接复用这套偏移吗？

    不能。转把需求在本车位于 0x202[3:5]，在参考日志那辆车上位于 0x202[2:4] 且完全不跟随转把。上游明确提示字节偏移随固件版本变化，换车必须重新验证，且这套解码本身是以另一份公开的 Talaria CAN 日志项目为地基的派生研究，并非独立来源。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/kbirand-talaria-tripper/README.md（总线参数、硬件接入、14 项解码信号表、四个字段证伪过程与覆盖机制实测）
    • 项目 01 —— public-can-dbc-datasets/additional/kbirand-talaria-tripper/SOURCE.md（DBC 的 9 报文 26 信号行规模、里程字段的待验证声明、派生来源与权利状态说明）

    免责声明

    本文所述的总线参数与信号定义均为社区研究报告产物，不代表车辆制造商的官方数据，文中数字均来自上述公开仓库的说明文件，未经独立实车验证。上游明确指出该解码是以另一份公开的骑行日志为地基的派生研究，适用车型、固件版本与其他车辆均未确立，字节偏移随固件变化，换车必须重新验证。该仓库快照中未发现任何许可证或逐文件再分发授权，仅可作私有离线研究副本，再分发或集成前须先行确认权利。涉及写入总线的操作请仅在封闭场地、由具备资质的人员执行，并以官方资料与实际测量为准。

    更新记录

    • 2026-10-15 初稿

  • VTRUX 与 Coda 的 CAN 解码笔记：信号、电芯索引与验证方法

    结论：这份笔记覆盖九份 DBC、合计 238 条报文与 1,066 条信号，分属 Coda 的 B/C/D 三总线、VTRUX 的 OBD/PT 两总线、Bel 逆变器的 J1939 扩展帧，以及一辆 1975 Porsche 914 改装车的自定义 VCU 遥测。它的价值不在清单本身，而在把「反编译出来的标签」和「验证过的信号」分成五档，并如实记录了一次被纠正三次的电芯索引映射与八条被推翻的假设。

    九份 DBC 的量级与定义来源

    仓库统计明确说明：下面的报文 / 信号数来自拷进来的 DBC 文件本身，而不是上游 README 的表格——后者已经过期。Coda 的 B、D 两总线在上游 README 里写的是 35 和 22，实际文件是 34 和 23；914 的 README 还在描述一份 75 报文 / 496 信号的 schema 3.0，而文件已经是 schema 4.2、hash 0x09EB175A。

    DBC 文件 报文 / 信号 总线 定义来源 证据边界
    CODA-B-CAN.dbc 34 / 156 B CAN 原厂 CODACAN LabVIEW 诊断应用 + 实车抓包 上游 README 的 35 为过期值，以文件为准
    CODA-C-CAN-cells.dbc 26 / 104 C CAN 26 帧 0x000–0x019，每帧 4 个 16 位 Motorola 电芯，1 mV/bit 电芯编号自 2026-07-22 起改为 1-based
    CODA-D-CAN.dbc 23 / 44 D CAN LabVIEW 反编译 + 日志 上游 README 的 22 为过期值
    epri-obd-bus.dbc 12 / 18 OBD EPRI Logger iPhone 应用的 Ghidra ARMv7 反编译，再用车辆日志比对修正 字节位置与刻度并非一律正确
    epri-pt-bus.dbc 26 / 101 PT 同上 同上
    vtrux-obd-experimental.dbc 3 / 5 OBD 作者由日志推导的实验性定义 含未解析报文桩
    vtrux-powertrain-experimental.dbc 19 / 26 PT 同上 同上
    BelInverter-v2.dbc 8 / 73 J1939 扩展 ID EPRI 结论 + 一份更早的 DBC 合并 原始作者与部分字节布局未确认
    914-telemetry.dbc 87 / 539 自定义 VCU 遥测 改装 914 的 VCU 映射，非原厂 Porsche 协议 标准 11 位 ID 为真实车辆帧；29 位扩展 ID 为 VCU 串行遥测里的内部合成值

    确认档位：怎么区分「反编译出来的」和「验证过的」

    这份仓库最值得抄的一点是它不给信号打勾，而是打档。反编译只能告诉你应用把哪个字节当什么读，不能告诉你它读对了；日志相关只能告诉你两件事一起动，不能告诉你它们是不是一件事。于是每条信号都落在下面五档之一，档位直接写在验证表里。

    档位 含义
    CONFIRMED 编码与角色都被独立验证过：物理测试、行为日志证据、与已知参考相关、或跨 DBC 比对一致
    CONFIRMED-SYMM 靠与某个 CONFIRMED 信号的结构对称性确认，没有独立测试
    CONFIRMED-DECOMPILE 编码由 Ghidra 确认，角色只是应用自己的标签，没有独立物理或行为检查
    PARTIAL 编码确认，角色或刻度还有一条具体问题挂着
    REMOVED 按 DBC 信号策略删掉 SG_ 条目，原因记在 CM_ 注释里

    档位不是形式主义

    PT 总线上 0x0054 的 GENE_EmergcyStp_flg 是 CONFIRMED-DECOMPILE：Ghidra 里写着 (pbVar15[6] 与 8) 不等于 0，但所有日志里它一次都没触发过，没有行为测试。同理 0x0580 的 tcm_CAN_ERR。这类条目可以读，但不能当成「已经证明这个位是这个意思」来用。

    0x381 与 C CAN 电芯索引：一条被纠正了三次的映射

    C CAN 只在少数几次采集里被同时录下（需要第三个适配器），所以能回答这个问题的只有三份日志。总线识别靠内容而不是总线号：0x000–0x019 的电芯帧是 C CAN，0x381/0x382/0x383/0x390/0x439 是 B CAN，0x308/0x312/0x325/0x330/0x55C 是 D CAN——两次会话给同一条物理总线编的总线号并不一致。

    会话 日志 配对样本 偏移 +1 严格命中率
    2026-07-21 Android 三适配器 coda_20260721_192435_T0..T2、_201109_T0/T1、_202031_T0 660 82–87%
    2026-02 Bonnydoon 行驶 33 min projects/coda/logs/frombonnydoon.log 1,972 80–84%
    2026-07-22 充至 100% coda_20260722_173203_T0..T21 979 100%

    合计 43 万帧以上的 C CAN 电芯帧、8,300 帧以上 0x381、3,600 对以上时间配对样本，且配对时刻 C CAN 数组完整、没有帧旧于 2 秒。充电会话最干净：负荷低而稳，电芯在 B 与 C 两轮扫掠之间几乎不重排，严格测试在 VmaxId（591 样本）与 VminId（706 样本）上都命中 100.0%。

    会话 信号 严格样本数 命中偏移 +1 不同 ID 数 ID 范围
    Android VmaxId 135 82.2% 11 6–104
    Android VminId 146 87.0% 26 1–101
    Bonnydoon VmaxId 225 79.6% 44 6–104
    Bonnydoon VminId 376 84.3% 33 1–104
    充电 07-22 VmaxId 591 100.0% 2 82–95
    充电 07-22 VminId 706 100.0% 1 96

    「严格」的口径是：只保留 C CAN 数组自身的极值恰好等于所报极值、该极值由唯一一只电芯持有、且领先第二名至少 3 mV 的样本。行驶会话里没有任何竞争偏移超过 4%；剩下约 15% 也不是反例——两条总线不是同时采样的，C CAN 扫完 26 帧要约 800 ms，而 0x381 只有约 1.1 Hz，行驶中负荷波动会在两个时刻之间把几乎并列的电芯重排。签名也说明这是偏斜而不是置换：未命中的配对集中在少数几个本来就常年处于极值的 C CAN 索引上（max 侧 81/83/94/102，min 侧 76/80/95），真置换会把它们撒满整个数组。

    三次纠正各纠正了什么

    第一次是编号口径：映射被发现时 C CAN DBC 还是 0-based，关系是「上报 id 等于旧索引加 1」；2026-07-22 改为 1-based 后加 1 消失，两套编号重合。这也推翻了更早那句「id 用的是与 C CAN 位置无关的 BMS 内部编号」——BMS 编号就是 C CAN 的发送顺序（1-based）。

    第二次是字节序。2026-07-15 之前 0x381 的归属是 B0-1=MinCellVoltage、B2-3=MaxCellVoltage、B4-5=AvgCellVoltage、B6=VminId、B7=VmaxId；修正后是 B0-1=Avg、B2-3=Max、B4-5=Min、B6=VmaxId、B7=VminId。当年的错误来自照着 LabVIEW cluster 的名字「VminVmax」排，而不是按 LabVIEW 字段顺序 Vavg、Vmax、Vmin、VmaxId、VminId。重跑严格测试可以量化这两种读法的差距。

    归属方式 Android 样本 / 命中 +1 Bonnydoon 样本 / 命中 +1
    修正后 max — 值 B2-3，id B6 135 / 111（82.2%） 225 / 179（79.6%）
    修正后 min — 值 B4-5，id B7 146 / 127（87.0%） 376 / 317（84.3%）
    旧 max — 值 B2-3，id B7 135 / 0（0.0%） 225 / 1（0.4%）
    旧 min — 值 B0-1，id B6 0 / 0 0 / 0

    两端的失效并不对称。min 侧当时根本没有信号可用：旧的 MinCellVoltage 读 B0-B1，而那其实是包平均值；平均值几乎不可能唯一且带余量地等于某一只电芯，所以两次会话里都是零样本存活，没有东西可相关。min 侧还有第二个错：id 也取自错误的字节（B6 其实是真正的 VmaxId）。max 侧则是「值对、id 错」：B2-B3 在两种读法下都真是最大值，但索引来自 B7（真正的 VminId），于是正确的最大电压配上了最小电芯的编号，噪声里最好的偏移只有 21%——读起来很像「另一套编号约定」，非常容易被误判。

    第三次是对比方式。frombonnydoon.log 同时带 C CAN 与 0x381，它自己的 0x381 报 VminId 95 / VmaxId 84，正是那次笔记已经点名的两只电芯。也就是说这条映射在单份日志内部就可验，而当时的笔记却拿它们去和另一次（充电）会话的 96/76 比，把差距读成了编码差异。结论成了方法：只要两条总线同时在场，就在同一会话内部比。

    还有一条适用范围限制：本节的「+1」只适用于经 DBC 从原始字节解出来的值。从 CODACAN 界面截图上读到的数字（如充电分析里的 VminId=96 / VmaxId=76）来自 LabVIEW cluster，它一直是对的，不受 DBC 错误影响。哨兵值 255 也要单独处理：104 只电芯的包里 255 不可能是索引，它是无效 / 无数据哨兵，不要当成「第 254 只电芯」。

    证据边界：部分解码、未解与已推翻

    「已确认且完整」的信号有其编码摘要，例如 0x275 BMSDriveLimits 的 B0 = 放电限值（uint8 乘 2 得 A）、B1 = 充电限值（乘 2 得 A）、B2-B3 = 包电流（BE uint16 乘 0.1 A，零点 0x8000）、B4-B5 = 包电压（BE uint16，1 V/bit）、B6 = HVAC 限值（乘 2 得 A）、B7 未知（基线 0xDD）。下面列的是还没收口的。

    ID 名称 已知 还缺什么
    0x050 BMSChargerCmd B0-B1 = HVCurrentCmd（BE uint16 乘 0.1 A，R2 = 0.992；基线 0x00DC = 22 A）；B2-B3 = MaxVoltage（乘 0.1 V，R2 = 0.605；基线 0x0FF7 = 408.7 V）；中位帧 00 dc 0f f7 00 01 3e 01 B4-B5 取非基线值会把 Main Current 压到约 6 A，疑似帧校验或滚动计数；B6-B7 未知；需注入测试
    0x270 BMS_FaultStatus B0 为故障字节（0x00 无故障，0x12 = 故障码 18，bit 1 = 0x02 与 bit 4 = 0x10 置位）；比 0x271 早一帧；drop 后 CODACAN 的 BMS Fault Severity 掉下去 B0 内部故障码与严重度的分界未扫；B6-B7 未知
    0x2C1 BMSDrivingRange B0 状态字节（raw = 0x70 时翻转）；B1 / B3 / B5 分别为 Exp / Max / Min，R2 约 0.96–0.97；比例暂定约 1.1 乘 raw 减 19 刻度 / 偏移未精确确认；B2、B4、B6-B7 未扫；单位可能是英里
    0x330 Long_Accel 被抑制时会掉，但与噪声边界模糊；VICD 刻度为有符号字节乘 0.08 m/s² 未确认为模拟量；需要一次含急刹的行驶事件做时序提取
    0x383 BMSBattStatus SoC 在 B0-B1（BE uint16 除以 10 得 %）已确认；同时带 HVBattCharging、ChrgPortOpen、ChargeCableConnected 三个布尔位的确切位号未记录
    0x410 AC_Compressor_Command B2 = compressor_on_off / CASS_on_off / warmup_cycle_cntr_incr；B6 = 目标转速（乘 60 rpm/bit）；B7 = 最大功耗（乘 0.1 kW/bit） B0 的三个布尔位（HVAC FaultRed、FaultYellow、KeepWakeNetworkHVAC）位号未解；也可能是扫描引起的 ECU 响应假象
    0x241 MCM_Thermal 角色已确认：drop-ID 后 Rotor / Stator / IGBT 三个字段归零；DLC = 8 已由日志确认 逐字节归属未确认；偏移假定为减 40 摄氏度；B4 恒为 0x00，疑似哨兵或非温度字段
    0x491 / 0x273 IPK 帧 两者都带 Primary ODO（km）、Interior Illum、Side Light Active、Low Beam Active；0x491 还会点亮 Overview 的 IPK 指示，0x273 不会 ODO 的字节位置与编码（可能是 BE uint24 或 uint32）；灯光的位号

    八条被推翻的早期假设

    这些条目都曾写进笔记或报告，后来被数据推翻。留着不是自曝，而是让下一个人不用再踩一遍。

    早期假设 更正为
    0x212 = EPS_SAM_1（转向角，0.25 deg/count） 0x212 = DLCM Torque Request；转向角在 0x080
    0x210 = Vehicle_Mode 含 VBatt（乘 0.4 V/count） 0x210 B2 = ThrottlePedalPos（乘 0.4 %/count）
    0x271 = Death Counter 的一部分（整数字节计数） 0x271 = GWM 心跳 + VehFaults 的源
    0x55C = VehFaults（3 字节：灯 / 严重度 / 故障字） 0x55C = TCM 心跳
    0x381 = BMSDriveLimits 候选（哨兵 1000.0 A） 0x381 = BMSVminVmax；BMSDriveLimits 在 0x275
    0x382 B0 = 充电阶段计数器（0x8B 到 0x8E 步进） B0 = Cell_T_avg；充电过程中包升温时为 11–14 摄氏度
    0x275 B4 = HV Active 布尔标志 B4-B5 = PackVoltage（BE uint16，1 V/bit）；104 串 LFP 包始终使 uint16 的最高位置位
    BattSentDischargeLimit / ChargeLimit 刻度 = 1 刻度 = 2（uint8 乘 2 得 A）

    常见问题

    反编译出来的 DBC 能直接拿来解日志吗？

    不能直接。反编译只证明应用把某个字节按某种方式读，不证明它读对了。所以这里把信号分成 CONFIRMED、CONFIRMED-SYMM、CONFIRMED-DECOMPILE、PARTIAL、REMOVED 五档，只有前两档带独立验证，第三档只是「应用自己这么命名」。

    电芯编号到底是 0 起还是 1 起？

    C CAN DBC 自 2026-07-22 起改为 1-based（Cell1 到 Cell104），与 BMS 自己的 VmaxId / VminId 直接对应，VmaxId 82 就是 Cell82。此前是 0-based，老 CSV、老图、老导出都要加 1 才能对上，例如旧 Cell94 等于现 Cell95。MinTempId / MaxTempId 是另一套索引，不受影响。

    为什么 0x381 的映射要改字节序？

    因为最初的归属照着 LabVIEW cluster 的名字「VminVmax」排，把 Min 与 Avg、VminId 与 VmaxId 都放反了；按 LabVIEW 字段顺序应是 Vavg、Vmax、Vmin、VmaxId、VminId。重跑严格测试后，旧的 max 读法命中 0.0%，旧的 min 读法零样本存活，修正后分别是 82.2% 与 87.0%。

    偏航率刻度为什么判不出来？

    两种说法分别是 0.0045（转向角 / 轴距运动学模型）与 0.003924（后轮差速几何法），但它们不是两条独立标定：同一几何法随速度窗口与轮距取值会给出 0.00347 到 0.00488。系统误差预算合计 43.4%（左右不对称 34.1%、速度窗口 21.5%、旅程间 16.0%），远大于两者相差的 14.7%，因此只能记为「判不出」。

    这份素材的许可证状况如何？

    被检查的上游快照里没有许可证文件，本文所依据的是一份离线私有研究副本。公开仓库可访问并不等于取得再分发或制作衍生作品的权利，对那些从第三方应用推断出来的定义尤其如此。共享或商用之前应与相关权利人确认。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/nickyivyca-vtrux-coda/SOURCE.md（九份 DBC 的报文 / 信号数与权利边界）
    • 项目 01 —— public-can-dbc-datasets/additional/nickyivyca-vtrux-coda/projects/coda/notes/codacan-signal-decode-notes.md（CODACAN 台架方法、分阶段完成表、模块在位映射与已推翻假设）
    • 项目 01 —— public-can-dbc-datasets/additional/nickyivyca-vtrux-coda/projects/coda/notes/cell-index-mapping.md（0x381 VmaxId/VminId 与 C CAN 电芯数组的三次纠正与严格测试口径）
    • 项目 01 —— public-can-dbc-datasets/additional/nickyivyca-vtrux-coda/projects/vtrux/notes/epri-verification.md（PT 与 OBD 总线的逐信号确认档位与 Gap）

    免责声明

    本文所述信号定义全部来自社区逆向工程，不代表车辆制造商的官方数据。Coda 与 VTRUX 两家整车企业均已退出市场，无原厂文档可核对；VTRUX 的 EPRI 定义最初由一款 iPhone 日志应用的二进制反编译重建，再用车辆日志比对修正，字节位置与比例并非一律正确。上游快照未包含许可证文件，公开仓库可访问不构成再分发或衍生权利。涉及安全相关用途时请仅作参考，并以实际测量为准。

    更新记录

    • 2026-10-15 初稿

  • 用 SavvyCAN 示例数据集复现 CAN 分析流程：三份 DBC 与 12 种格式

    结论：SavvyCAN 自带的 examples/ 目录是最小成本的复现环境：三份示例 DBC 分别是 10 报文 22 信号的动力总线样本、501 报文 548 信号的大规模档案、6 报文 31 信号的部件级总线，量级相差约 80 倍，正好覆盖「小规模逐条核对—大规模过滤检索—部件级拓扑」三类分析动作。采集硬件并非必需，工具能直接读写 12 种日志格式（其中 3 种只读），因此用示例数据就能把整条流程走通。需要注意的是：三份示例都没有独立的年款适配与信号验证记录，且其中一份大规模档案在归档里还有 502 报文 761 信号的后续修订版，两者应按不同来源快照分别留存。

    三份示例 DBC：量级差 80 倍，用途完全不同

    把三份示例放在一张表里看，最直观的不是报文数，而是它们的性质差异：LeafPowertrainBus.dbc 是标注为 Leaf 的动力总线样本，规模小到可以逐条人工核对；ThinkCity.dbc 是 501 条报文的城市车档案，价值在于压测过滤与检索；bms.dbc 只有 6 条报文却命名了 EVTVBMS、GEVCU 与逆变器三类部件，是典型的部件级总线示意。

    示例文件 报文数 信号数 文件性质 证据边界
    LeafPowertrainBus.dbc 10 22 标注 Leaf 的动力总线示例 代数、年款、硬件与信号验证均未记录
    ThinkCity.dbc 501 548 标注 Think City 的大规模档案 并非每条报文都确立了车型年款适用性
    bms.dbc 6 31 部件级示例，含 EVTVBMS、GEVCU、逆变器 通用部件示意，不是某款整车的原厂 DBC
    归档中的 ThinkCity_modified6.dbc 502 761 同名的后续大幅扩充修订版 与上一行是两个来源快照，不可互相覆盖

    第四行值得单独说明：501/548 与 502/761 只差 1 条报文，信号数却差了 213 条。这说明后者的修订主要集中在信号定义而非报文条目扩充。归档时的正确做法是把两者当作独立快照各自留存，而不是用新版本替换旧版本。

    用示例数据复现分析流程：每个文件演示什么

    三份示例对应三种不同的分析动作。小规模样本适合验证「DBC 定义与原始字节是否自洽」，大规模档案适合验证「过滤、分组与检索是否好用」，部件级示例适合验证「多设备报文关系能否被正确建模」。把它们按这个顺序跑一遍，就能在不接硬件的前提下判断工具链是否完整。

    分析动作 推荐示例 可验证的能力 演示不了什么
    逐条核对信号定义 LeafPowertrainBus.dbc 报文清单浏览、信号曲线绘制、缩放与偏移是否自洽 代数与年款适配判定
    大规模检索与过滤 ThinkCity.dbc 按 ID 区间过滤、按报文名搜索、大文件加载与刷新性能 逐条物理值的实测验证
    部件级拓扑建模 bms.dbc 多设备（BMS、整车控制器、逆变器）报文归属与发送关系 整车级网络拓扑与网关行为
    格式往返一致性 任意一份 + 日志导出 导入后再导出，比较 ID 与数据字节是否逐帧一致 时间戳在不同格式间的保真度差异
    来源快照比对 ThinkCity.dbc 与修订版 同名报文在两版之间信号数变化的对比 哪一版更接近原车的判定

    为什么「导入再导出」是最先该跑的一条

    这条流程不需要理解任何信号含义，只需要比对 ID 与 8 个数据字节是否逐帧一致。它能一次性暴露三类问题：格式解析器的边界处理、扩展帧与标准帧的区分、以及多帧时序是否被保留。在这条通过之前，后续任何信号级分析都建立在不可靠的输入上。

    十二种读写格式：九种可写，三种只读

    工具的定位是「加载、保存与采集 CAN 帧」，用于可视化、逆向、调试与抓包。它明确说明采集设备并非必需，因此格式支持清单直接决定了它的离线分析能力边界。清单里前九种可读写，后三种只能读。

    序号 格式 读写能力
    1 BusMaster 日志文件 读 + 写
    2 Microchip 日志文件 读 + 写
    3 CRTD 格式（OVMS 日志格式） 读 + 写
    4 GVRET 原生格式 读 + 写
    5 通用 CSV（ID 加 D0 到 D7） 读 + 写
    6 Vector Trace 文件 读 + 写
    7 IXXAT Minilog 文件 读 + 写
    8 CAN-DO 日志 读 + 写
    9 Vehicle Spy 日志文件 读 + 写
    10 CANDump / Kayak 只读
    11 PCAN Viewer 只读
    12 Wireshark socketcan PCAP 文件 只读

    采集侧则走另一条路：除推荐的 CANDue 板（需运行 GVRET 固件）之外，可以使用任意 Qt SerialBus 驱动，包括 socketcan、Vector、PeakCAN 与 TinyCAN。也就是说，离线分析用文件，实车采集走 SerialBus，两条路径互不影响。

    可复现环境：依赖全部在源码树内

    这份工程不依赖源码树或 Qt 安装器之外的任何东西，绘图库 QCustomPlot 已直接集成进源码，无需单独下载。编译门槛集中在 Qt 版本上：因为依赖 QtSerialBus 及其他新特性，需要 5.14.0 或更高版本。

    环境项 要求 说明
    Qt 版本 5.14.0 或更高 低于此版本缺少 QtSerialBus，无法编译
    屏幕分辨率 至少 1024×768 支持多显示器，4K 显示器可用
    macOS 二进制 至少 macOS 10.15 针对当前二进制构建的要求
    Qt6 支持 QT6WIP 分支，2026-03-11 用 Qt 6.9 测试通过 质量约为 beta，多数功能可用
    绘图依赖 QCustomPlot 已集成 无需外部下载
    Ubuntu 模块缺失 安装 libqt5serialbus5-dev、libqt5serialport5-dev、qtdeclarative5-dev、qttools5-dev 解决「Unknown module(s) in QT」类报错
    调试构建 qmake CONFIG+=debug 后 make 获取更多运行期信息

    标准编译路径是克隆仓库后依次执行 qmake 与 make，再直接运行可执行文件；Linux 上可用 ./install.sh 生成桌面快捷方式。若编译失败，官方给的第一步重试动作是重新 qmake、make clean、make；仍未解决则检查安装 Qt 时是否勾选了 SerialBUS 支持。

    常见问题

    没有采集硬件，能用 SavvyCAN 做分析吗？

    可以。工具明确说明采集设备不是使用前提，它能直接加载并保存 12 种格式，其中 9 种可读可写，CANDump/Kayak、PCAN Viewer 与 Wireshark socketcan PCAP 三种为只读。用 examples/ 下的三份 DBC 配合日志文件即可跑完整条离线流程。

    三份示例里哪份适合作为第一条分析流程？

    建议从 bms.dbc 或 LeafPowertrainBus.dbc 这类小文件起步。LeafPowertrainBus.dbc 有 10 条报文 22 条信号，可以逐条核对缩放与偏移是否自洽；bms.dbc 有 6 条报文 31 条信号，适合看多设备报文归属。501 报文 548 信号的 ThinkCity.dbc 更适合压测检索与过滤性能。

    ThinkCity.dbc 与归档里的另一份 ThinkCity 该怎么取舍？

    不取舍，两份都要留。归档记录显示后者是同名的后续大幅扩充修订版，规模为 502 报文 761 信号，比前者多 1 条报文、多 213 条信号。两者属于不同的来源快照，正确做法是按各自 provenance 分别留存，而不是用新版覆盖旧版。

    bms.dbc 能当整车 DBC 用吗？

    不能。它是部件级示例，6 条报文 31 条信号里命名的是 EVTVBMS、GEVCU 与逆变器等部件，用于展示部件之间的报文关系。它既不是某款命名整车的原厂 DBC，也不包含整车级拓扑与网关行为。

    Qt6 分支现在可以投入日常使用吗？

    需按 beta 质量评估。仓库里的 QT6WIP 分支可配合 Qt6 编译，2026-03-11 用 Qt 6.9 测试通过，官方表述是「多数功能应该可用」，并请求反馈问题。若用于正式分析流程，仍建议以 Qt 5.14.0 或更高的稳定构建为主。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/collin80-savvycan-examples/SOURCE.md（三份示例 DBC 的报文数、信号数、SHA-256 与修订版快照关系）
    • 项目 01 —— public-can-dbc-datasets/additional/collin80-savvycan-examples/README.md（12 种读写格式、Qt 版本与分辨率要求、编译与排错步骤）

    免责声明

    本文所述示例 DBC 均为公开仓库中的演示文件，其代数、年款、硬件适配与信号验证均未在说明文件中确立，不代表车辆制造商的官方数据。文中数字均来自上述公开仓库的说明文件，未经独立实车验证。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。

    更新记录

    • 2026-10-14 初稿

  • 改装 ECU 的 CAN 仿真器：8/90 与 38/159 两份样例 DBC 怎么验

    结论：用桌面 CAN 仿真器验证改装 ECU 的 DBC，最省事的路径是先跑 virtual 接口做单进程自检，再用 vcan 或真实 SocketCAN 做端到端收發比对。这份归档里的两份样例分别是 8 报文 90 信号与 38 报文 159 信号，文件名指向两款常见改装 ECU，但仓库没有给出固件版本、装车适配和物理标定记录——它们能验证的是编码/解码链路本身，不能验证信号物理含义。

    两份样例 DBC 的实际量级

    仿真器自带两个样例库，归档时按 Git blob 与 SHA-256 做了固化。两者的量级差了一个数量级：小的一份 8 条报文却塞了 90 个信号，说明单帧内信号排布非常密；大的一份 38 条报文 159 个信号，更接近一台完整发动机控制器的输出规模。

    文件 报文数 信号数 SHA-256（前 16 位） 推断的 ECU 证据状态
    databases/emu_black.dbc 8 90 61caa4ea47dc0be3 ECUMaster EMU Black 名称推断，固件与装车未记录
    databases/haltech_elite.dbc 38 159 cbe0b8c73c842df1 Haltech Elite 名称推断，固件与装车未记录

    其中 emu_black.dbc 含有遗留的非 UTF-8 单位字节，归档时保持原样未做转换。这一点对工具链有实际影响：按严格 UTF-8 读取单位字段的解析器会报错或产生乱码，需要在加载前明确编码容错策略。另外，这两份文件是部件级协议样例，不是整车网络地图——把它们当成某台车的完整定义来用，从一开始就错了。

    三种接口的适用边界

    工具支持三类接口，选择依据不是「哪个更好」，而是当前验证处在哪个阶段。virtual 接口不需要硬件也不需要 root，但只在同一个 Python 进程内有效；socketcan 能跨进程、可配波特率，但改波特率需要 CAP_NET_ADMIN；slcan 面向 USB 串口适配器，适合接真实硬件。

    接口类型 硬件需求 权限需求 能否跨进程 波特率可配 适用阶段
    virtual 无 无 否，仅同进程 不适用 UI 与编码逻辑快速自检
    socketcan 真实或虚拟 CAN 接口 改波特率需 CAP_NET_ADMIN 是 是 与第三方工具联调
    slcan USB/串口适配器 无特殊权限 是 是 接真实改装 ECU

    SocketCAN 的波特率是网络链路自身的属性，不是应用每次连接时设定的。工具里的「Apply Bitrate」按钮实际执行的是把接口 down 掉、用 ip link 设定位速率、再 up 起来的三步操作，因此必然需要管理员权限；如果失败，可以事先自行配置好接口再启动工具。「Create vcan」按钮同理，它加载 vcan 内核模块并起一个虚拟链路，默认名 vcan0，之后另一个终端用 candump 就能看到流量。

    一条可复用的 DBC 验证流程

    把仿真器当验证工具而不是发帧玩具，核心是让「发什么」和「收回来解出什么」形成闭环。工具本身已经提供了闭环所需的两个能力：展开报文后按 DBC 定义生成控件，以及把总线上收到的每一帧连同解码结果打进日志。

    步骤 操作 判据
    1 加载 载入目标 DBC，观察是否有解析告警 无告警再继续；非 UTF-8 字节需先定编码策略
    2 展开 展开报文，数值信号看滑块量程，枚举信号看下拉项 量程与下拉项应与 DBC 的 range/resolution 和值表一致
    3 编码 拖动滑块，观察实时生成的原始字节 字节随取值单调变化，边界值不溢出
    4 发送 打开 TX 开关按周期发，或用 Send once 单发 周期默认 100 ms；DBC 未指定时以此为准
    5 回收 在日志里核对 RX 帧与解码结果 ID 在 DBC 内则应解码成功；回环数值应与发送值一致
    6 压力 在高负载总线上观察日志 出现 RX overflow 说明日志丢弃，不能据此判定丢帧

    第 5 步是这个流程的关键：只有当发出的值在接收侧被同一个 DBC 解回相同数值时，编码与解码的一致性才算被验证。它验证的是链路，不是物理含义——滑块拉到某个位置对应的字节是否正确，与这个字节在真实 ECU 上代表多少 kPa，是两个问题。

    日志里 RX overflow 不是丢帧证据

    日志面板会打印总线上收到的每一帧，格式形如 RX 0x360 [8] 后面跟数据。在非常繁忙的总线上，多余的帧会被从日志中丢弃并报告为 RX overflow。这是日志侧的丢弃，不是总线侧的丢帧，两者不能混为一谈；要测丢包率应当用独立的计数器，而不是看日志有没有 overflow。

    常见问题

    这两份样例 DBC 能当作某台改装车的完整网络定义吗？

    不能。它们是部件级协议样例，文件名指向两款改装 ECU，但仓库没有记录具体固件版本、装车适配、信号原作者或物理标定。能验证的是编码与解码链路，信号物理含义需要另行标定。

    没有硬件能不能先把验证跑起来？

    可以。virtual 接口是 python-can 的进程内总线，不需要硬件也不需要 root，适合做 UI 与编码逻辑的快速自检；若需要跨进程联调，则用 socketcan 加 vcan 虚拟链路，两个应用打开同一个接口即可互通。

    为什么点了 Apply Bitrate 会失败？

    因为 SocketCAN 的波特率属于网络链路属性，按钮实际执行的是 down、设定位速率、再 up 三步，需要 CAP_NET_ADMIN。权限不足时可以自行提前配置接口，或以足够权限运行工具。

    周期发送的默认周期是多少？

    打开报文的 TX 开关会按该报文的周期时间发送，周期可在界面上编辑；如果 DBC 没有指定周期，则默认取 100 ms。单帧发送则用 Send once。

    日志里的 RX overflow 意味着总线丢帧吗？

    不意味着。它表示繁忙总线上多余的帧被从日志面板丢弃，是日志侧的限流行为，不是总线侧丢帧。判定丢包率要用独立计数器，也可以取消勾选日志头的 Show received frames 来静音接收帧显示。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/candbcemu-aftermarket-ecu/SOURCE.md（两份样例 DBC 的报文/信号数、Git blob 与 SHA-256、非 UTF-8 字节说明与权利状态）
    • 项目 01 —— public-can-dbc-datasets/additional/candbcemu-aftermarket-ecu/README.md（三种接口类型、波特率配置、vcan 创建、TX/RX 行为与项目结构）

    免责声明

    本文所述功能与参数均来自公开仓库的说明文件，未经在真实改装 ECU 上的独立验证。两份样例 DBC 的车型归属为名称推断，固件版本、装车适配与信号物理标定均未由仓库给出。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。

    更新记录

    • 2026-10-14 初稿

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

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