星核火花赛车科技

标签： 车型协议

  • 2014 丰田 Yaris Hybrid XP130 的 CAN 信号地图

    结论：这份档案记录的是 2014 款丰田 Yaris Hybrid（第 3 代 XP130，THS-II NoDSU）的 CAN 信号逆向成果：从车机 28 针连接器的第 9/10 脚（500 kbit/s）被动监听，而不是 OBD-II 口，已确认 12 个与仪表相关的信号（车速、转速、挡位、油门、刹车、转向灯、里程、环境温度、混动电池 SOC、EV 行驶位、CHG/ECO/PWR 指针）。关键结论是混动电池 SOC 与 EV 状态是普通广播，不需要主动诊断轮询。但 HV 电池电流/电压与剩余续航经确认不在总线上。下列结论仅限源文档记录的这一台车，不能外推到其他配置、年款或市场版本。

    车辆与适用范围

    源文档是一个「用逆向出的 CAN 数据驱动自制数字仪表」的项目，主线工作是信号逆向，附带完整的方法学与交叉验证记录。信号只有在两段独立的实车行驶日志上都能复现，才被标记为「confirmed」。

    项 内容
    车型 Toyota Yaris Hybrid（第 3 代 / XP130，THS-II NoDSU），2014 年
    年款 / 市场版本 2014；源文档未给出市场版本
    采集点 原厂车机 28 针连接器（p/n 90980-12555），第 9 脚 CAN-H / 第 10 脚 CAN-L，500 kbit/s，不是 OBD-II 诊断口
    采集跨度 两段独立实车日志：session_0044.log（约 430s）与 session_0047.log（约 440s）
    适用范围 仅限这一台 Yaris Hybrid；源文档说明映射可能不适用于其他配置/市场/年款

    总线与寻址

    文档把车机连接器视为干线高速 CAN（HS-CAN）的同一逻辑总线，理由是它看到的报文集合（SPEED、RPM、GEAR、BRAKE、TURN_SIGNALS、ODOMETER 等）与预期一致。这也正是后装第三方 CAN 盒通常接入的位置。

    项 内容
    物理层 车机连接器 CAN-H/CAN-L 双线，500 kbit/s
    链路层 / 比特率 500 kbit/s（源文档明示）
    寻址方式 报文为 11 位标准 ID（如 0x0B4、0x1C4、0x4A7 等）
    CAN FD 源文档未提及 CAN FD
    读取方式 ESP32 被动监听（TWAI_MODE_LISTEN_ONLY，不发送、不应答）

    已解码信号

    下表合并源文档的两张清单：前 12 行为两段日志都复现的「confirmed」信号，后 5 行为语义成立但精确标度未最终确认的「strong hypotheses」。置信度标注原样保留。

    信号 ID / 字段 解码 证据 / 置信度
    车速 0x0B4 / SPEED (byte5 << 8 | byte6) * 0.01 km/h 两段日志复现；与里程/其他 3 个速度字段一致（≤0.5%）
    发动机转速 0x1C4 / RPM 有符号 16 位 * 0.78125 rpm 两段日志复现（0→60→0 与怠速/轰油）
    挡位 P/R/N/D/B 0x127 / GEAR 4 位枚举，byte5 高半字节 五个状态全部观测到
    油门踏板 0x245 / GAS_PEDAL byte2 * 0.005（0–1 对应 0–100%） 两段日志复现（观测 0–35%）
    ICE 运行位 0x245 / ICE_RUNNING byte3 bit4 与 RPM>50 一致率 98–99%
    刹车按下位 0x230 / BRAKE_PRESSED 单个 bit 与换挡、车速变化对得上
    转向灯 0x614 / TURN_SIGNALS 2 位枚举 + 双闪位 左/右/无三态均观测到
    总里程 0x611 / ODOMETER 20 位，含 km/miles 单位位 确认为总里程（99552→99555 km），非续航
    环境温度 0x442 / AMBIENT_TEMP byte0 – 40 = °C 两天实测 37 °C / 27 °C 对照确认
    混动电池 SOC 0x4A7 / BATTERY_SOC byte2 * 0.5 = % 观测 54.0–71.5%，符合 THS-II NiMH 工作带；标度沿用 Toyota/Techstream 惯例，未与参考工具读数核对
    EV 行驶位 0x498 / EV_DRIVE byte5 bit7 与「行驶中且 ICE 停机」100% 一致
    CHG/ECO/PWR 指针 0x247 / HSI_VALUE + HSI_ZONE byte1 为量程百分比；符号取自 HSI_ZONE zone/value 相关性 n=32779、零例外
    刹车踏板（模拟量） 0x224 / BRAKE_VALUE 16 位，与刹车位强相关 假设：中位 0（松开）对 62（按下）；单位与量程未确认
    冷却液温度 0x618 / TEMP_RAW byte3；猜测量程 * 0.375 假设：暖机曲线合理，无参考温度计标定
    第二温度（机油/CVT/电池包？） 0x3B9 / TEMP2_RAW byte0，约 1 Hz 假设：与时间/冷却液强相关（r≈0.95）；量纲未提
    纵向加速度/扭矩需求 0x320 / ACCEL_DEMAND 有符号 byte4，约 20 Hz 假设：加速正、制动/滑行负、稳态≈0；标度未确认
    燃油消耗计数器 0x3A0 / FUEL_COUNTER_RAW byte7，10 Hz 假设：随 ICE 运行递减，不是油位表；疑为更宽寄存器的低位字节

    读取方法与注意事项

    源文档的全部信号都靠被动监听获得，固件以 TWAI_MODE_LISTEN_ONLY 运行，不向车辆发送任何报文。判定的门槛是「两段独立日志都复现」才算 confirmed；单段日志里的现象只进「假设」或「排除」清单。

    CHG/ECO/PWR 指针有一个容易踩的坑：符号位住在 HSI_ZONE（byte0），不在 HSI_VALUE（byte1）里。CHG 侧 byte1 用二进制补码并在 -100 处钳位，ECO/PWR 侧用无符号幅值且在全油门时会扫过 155，两侧原始范围重叠。早期固件只凭 byte1 判断符号，结果全油门的强 PWR 被误读成强 CHG，上车实测确认后改为按 HSI_ZONE 分支。此外 PWR 侧显示做了对折（PWR% = raw/2），因为 ECO/PWR 分界只是真实量程的中点而非顶点。

    车速不做修正是有意为之：SPEED 是真实车速，里程、GPS 与总线上另外 3 个速度字段都对它。仪表自身的指针读数偏高（含法规性偏置，UNECE R39 要求指示值不得低于真值，上限 10% + 4 km/h），而这个偏置值只在仪表内部计算、不上总线。

    证据等级与边界

    证据分三层。第一层是实车观测：12 个 confirmed 信号来自两段真实行驶日志；速度刻度还用里程绝对锚定（整公里区间积分误差 +0.01%，方法自身不确定度 ±0.82%）。第二层是外部旁证：速度/转速等沿用公开参考 DBC（跨 Prius/Camry/Highlander 变体核对），SOC 的 0.5%/bit 标度沿用已知的 Toyota/Techstream 惯例。第三层是推测：冷却液、第二温度、加速度与燃油计数器的量纲都属猜测。

    两处不能外推。第一，所有映射来自单一车辆，源文档明确「可能不适用于其他配置/市场/年款」；CHG/PWR 的 zone 编码尤其如此——文档记录后来一次实车硬加速还出现了 8、9、14 三个日志中没有的 zone，说明 4/6/12/15 对这批日志穷尽、对整车并不完整。第二，剩余续航与 HV 电池电流/电压/温度经确认不在本总线上，只能靠对电池 ECU 的主动 UDS 请求，源文档未提供任何绕过安全访问的方法，且不建议尝试。

    常见问题

    Yaris Hybrid 的 OBD 口能读到这些信号吗？

    源文档没有用 OBD-II 口，而是从车机 28 针连接器的第 9/10 脚取数。这正是后装 CAN 盒通常接入的位置，文档据此把它当作同一逻辑总线处理。

    混动电池 SOC 是主动问出来的吗？

    不是。SOC 在 0x4A7 的 byte2 上被动广播，EV 行驶位、ICE 运行位同样是广播；仅靠被动监听就能重建后装盒子的能量流显示。HV 电池电流/电压/温度则确认不在总线上。

    车速显示和真实车速差多少？

    源文档记录：在仪表指示 140 时真值约 130，差值约 +10 km/h（单次指针读数，可视为 +5~+15）。这是法规性偏置，不是解码错误；固件有意不做修正。

    为什么全油门时功率条会翻到 CHG？

    因为符号取自 HSI_ZONE 而非 byte1。只凭 byte1 判断时，PWR 侧扫过 155 会被误读成大负值。按 zone 分支后即可修正。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/fellettigiacomo-yaris-xp130/re/docs/signal_findings.md（本项目车型档案主来源：完整方法学与验证证据）。
    • 项目 01 —— public-can-dbc-datasets/additional/fellettigiacomo-yaris-xp130/re/docs/decoded_signals_summary.md（已确认/假设/排除信号的快速参考表）。
    • 项目 01 —— public-can-dbc-datasets/additional/fellettigiacomo-yaris-xp130/README.md（项目背景、硬件与被动监听安全说明）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • Honda Civic FL5：25 个 DID 与 109 个 CAN 信号

    结论：Honda Civic FL5 的数据特征与多数车相反：OBD 口后面存在网关，且总线上几乎抓不到周期性广播帧——必须用 UDS 服务 22（ReadDataByIdentifier）主动向四个模块索取 DID，才能读到 25 个 DID、109 个信号。正因为如此，DBC 不适合做这辆车的主格式。以下所有结论仅限源文档记录的这一台车与其固件版本，不代表同型号其他车辆。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 Honda Civic FL5 的诊断数据整理。项目以 UDS 服务 22 的读取结果为基础，按模块组织成 DID 与信号清单，并对每条信号标注了证据等级。

    项 内容
    车型 Honda Civic FL5
    年款 / 市场版本 源文档未确认
    ECU / 模块 共 4 个：0x10 ECM、0x28 VSA、0x30 EPS、0x60 仪表（组合仪表）
    采集跨度 数据集 25 个 DID、109 个信号；源文档记录版本 1.0.1
    适用范围 仅限源文档记录的这一台车与其固件；DID 布局与信号刻度不保证适用于其他年款或市场版本

    总线与寻址

    这辆车是经典 CAN 加主动诊断读取的典型：总线上没有可供解析的周期广播流，价值的全部来源是「问—答」。因此寻址方式、传输层时序与请求节奏比 DBC 更重要。

    项 内容
    物理层 / 速率 经典 CAN 2.0B，500 kbit/s，无 CAN FD
    接入点 标准 OBD-II（J1962）引脚 6 / 14
    网关 OBD 口后存在网关；源文档实测总线上为零周期性广播帧
    诊断寻址 29 位 ISO 15765 物理寻址：请求 18DA<目标>F1，应答 18DAF1<目标>，诊断仪地址固定为 F1；功能广播为 18DB33F1
    传输层 ISO-TP（ISO 15765-2）：首帧宣告长度，随后连续帧，接收方回 30 00 00 流控帧；数据区 54–63 字节，填充 0xAA
    11 位寻址 在 7E0 / 7E8 上发标准 Mode 01 无应答

    已解码信号

    下表从源文档的信号清单中抽取最具代表性的条目。项目的置信度分为「已确认（研究级）」「中」「低-候选」三档，表中原样保留该标注；标为「中」的条目表示解码方向明确但仍缺独立旁证。

    信号 位置（ID / DID / 字节） 解码 证据
    ENGINE_RPM（发动机转速） DID 0x2610 B6:B8 raw × 0.25 rpm 已确认（研究级）
    MAP_ABS（绝对进气压力） DID 0x2610 B9:B11 raw × 0.0078125 kPa 已确认（研究级）
    ECT（冷却液温度） DID 0x2610 B11 raw − 40 ℃ 已确认（研究级）
    VEHICLE_SPEED（车速） DID 0x2610 B18 raw km/h 已确认（研究级）
    OIL_PRESSURE（机油压力） DID 0x2610 B44:B46 raw kPa 已确认（研究级）
    OIL_TEMP_MODEL（机油温度模型） DID 0x268F B15 raw − 40 ℃ 已确认（研究级）；源文档标注该信号在公开资料中无先例
    BRAKE_PRESSURE（制动压力） DID 0x4005 B7:B9 raw − 25 bar 已确认（研究级）
    STEER_ANGLE（方向盘转角） DID 0x48BD B11:B13 s16 × 0.1° 已确认（研究级）
    WHEEL_SPEED_FL / FR / RL / RR DID 0x48C4 B23:B31 raw × 0.01 km/h 已确认（研究级）
    STEER_MODE（转向模式） DID 0x48AC B1 枚举 中
    FUEL_LEVEL（燃油液位） DID 0x7029 B12:B14 raw × 0.01 L 已确认（研究级）
    AMBIENT_TEMP（环境温度） DID 0x7028 B17 raw ℃ 已确认（研究级）

    读取方法与注意事项

    这辆车读数据必须走 UDS 服务 22。请求用 29 位物理寻址发到 18DA<目标>F1，模块在 18DAF1<目标> 上应答；诊断仪地址固定为 F1，功能广播是 18DB33F1。注意 11 位寻址（7E0 / 7E8）上的标准 Mode 01 在本车上没有应答。

    一旦某个 DID 的应答超过单帧容量，就会落到 ISO-TP 分段传输：模块先发一个首帧（形如 10 29 …）宣告总长度，再发若干连续帧，诊断仪需要及时回一个流控帧 30 00 00 授权它继续。源文档特别指出，流控帧如果晚回几毫秒，ECU 会放弃整笔传输——所以「问得到」不等于「收得全」，接收端的流控时机是硬约束。

    工程上还要考虑读取节奏：同一模块上多个 DID 需要轮流询问，模块之间（ECM / VSA / EPS / 仪表）也要分配请求配额，否则在高频轮询时容易触发超时或让 ECU 返回否定应答。源文档记录了若干次安全访问被拒的情形，未提供绕过方法，也不建议尝试。

    证据等级与边界

    项目的证据等级分「已确认（研究级）」「中」「低-候选」三档。已确认条目既有编码依据也有行为或参考交叉验证；「中」表示解码方向明确但缺少独立旁证；「低-候选」则是尚未闭环的猜测。本文抽取的信号以已确认为主，并原样保留了 STEER_MODE 的「中」标注。

    项目文档中有一节专门列出「已推翻的说法」，条目数量在三十条以上——说明这辆车的诊断数据在公开讨论里存在大量误传。阅读时要把「已推翻」与「已确认」严格分开，不要把早期猜测当作结论使用。

    边界上必须强调：25 个 DID 与 109 个信号全部来自这一台车的这一版固件。不同年款、不同市场版本的 DID 编号、字节偏移与刻度都可能变化；同一 DID 在不同固件下含义也未必一致。任何实车读取都应在目标车上逐条复核。

    常见问题

    为什么这辆车用 DBC 解析不出来东西？

    因为源文档实测其总线上没有周期性广播帧，OBD 口后还有网关。DBC 描述的是「谁在什么时刻广播什么布局的帧」，而这辆车的数据要靠 UDS 服务 22 主动索取，表现形式是「问—答」而非广播，所以 DBC 不适合作主格式。

    读一个 DID 需要满足哪些传输层条件？

    用 29 位寻址发请求到 18DA<目标>F1，模块在 18DAF1<目标> 应答；如果应答超过单帧，模块会先发 ISO-TP 首帧宣告长度，诊断仪必须及时回 30 00 00 流控帧。源文档指出流控晚回几毫秒 ECU 就会放弃整笔传输。

    标准差一点的信号还能用吗？

    要按证据等级区分。标为「已确认（研究级）」的可以直接用；标为「中」的（如 STEER_MODE）解码方向明确但缺独立旁证，使用前应自行验证；「低-候选」的不要作为结论。源文档对每一条都保留了原始标注。

    这些 DID 能套用到别的 Civic 上吗？

    不能。源文档的全部结论限定在这一台车与其固件版本上，且明确 DID 编号、字节偏移与刻度都可能随年款或市场版本变化。换车使用前必须重新读取并复核。

    延伸阅读

    参考资料

    • 项目 02 —— public-can-dbc-datasets/additional/caldis-honda-civic-fl5-dids/README.zh-CN.md（本项目车型档案主来源）
    • 项目 02 —— public-can-dbc-datasets/additional/caldis-honda-civic-fl5-dids/CHANGELOG.md（版本与已推翻说法的变更记录）
    • 项目 02 —— public-can-dbc-datasets/additional/caldis-honda-civic-fl5-dids/SOURCE.md（数据集版本与来源说明）

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • openpilot legacy 支持矩阵：可读车型与低速边界登记表

    结论：这份「车型 CAN 数据档案」记录的不是某一辆车的逐条报文，而是一套多车型支持矩阵：源文档以「原车纵向 / 自控纵向、出厂 ACC 是否被替换、低于多少速度不可用」为列，逐平台登记可读能力，并说明车辆数据由 opendbc 目录下的文件解释。换言之，它回答的是「这台车能否被读取、由谁供给纵向控制、低速边界在哪」，而不是「0x1XX 的第几个字节是什么」。下述结论仅限源文档登记的那份 legacy 支持清单，不能外推到清单之外的车型、年款或市场版本；源文档本身也未提供任何逐信号 DBC 定义。

    车辆与适用范围

    源文档是一份开源驾驶辅助系统的总览说明，覆盖其官方支持与社区维护两级车辆名单。数据来自该项目的公开文档快照，不是对某台实车的采集记录，因此这里不存在「采样了几小时、几万帧」的采集跨度，只有一份能力登记表。

    项 内容
    车型 多品牌多车型的平台集合（Acura、Honda、Hyundai、Lexus、Toyota、Subaru、Volkswagen 等）
    年款 / 市场版本 以「美国市场参照（US Market Reference）」列登记，年款随平台不同；源文档未确认其他市场版本的对应关系
    ECU / 改装状态 分「官方支持」与「社区维护」两级；部分平台需断开驾驶员支持单元（DSU）或加装 ASCM 线束才能由本系统接管纵向
    采集跨度 源文档未提供日志数或事务数，仅提供能力矩阵与目录结构
    适用范围 仅覆盖源文档列出的平台与年款区间；社区维护平台未被上游安全模型验证

    总线与寻址

    源文档不描述物理层细节，只在目录结构中说明 opendbc「展示如何解释来自车辆的数据」，并由 selfdrive/car 承载各车型的状态读取与执行器控制。也就是说，寻址方式、比特率与帧格式都在被引用的 DBC 与车型代码里，本快照未包含这些定义本身。

    项 内容
    物理层 源文档未给出（由各车型 DBC / 适配器决定）
    链路层 / 比特率 源文档未给出
    寻址方式 源文档未给出；仅提及 opendbc 存放「如何解释数据」的文件
    CAN FD 源文档未提供该版本是否包含 CAN FD 车型
    承载硬件 EON DevKit 或 comma two，配合车型线束；实验场景可用带外置摄像头的 Ubuntu 电脑

    已解码信号

    本项目的源文档是一张能力矩阵，而非逐信号解码表。为保持「只抄源文档里有证据的条目」这一原则，下表登记的是源文档逐平台明确给出的可读字段（支持包、ACC 供给方、低速边界），并逐条注明证据页。任何涉及具体字节、DID 或缩放系数的内容，源文档均未提供。

    平台（美国市场参照） 支持包 可读字段（ACC 供给 / 低速边界） 证据
    Acura ILX 2016-19 AcuraWatch Plus ACC 由本系统供给；低于 25mph 不可加速；低于 25mph 无 ALC Supported Cars 表
    Acura RDX 2019-21 All ACC 保留出厂；低于 0mph 不可加速；低于 3mph 无 ALC Supported Cars 表
    Honda Accord 2018-20 All ACC 保留出厂；低于 0mph 不可加速；低于 3mph 无 ALC Supported Cars 表
    Honda Civic Sedan/Coupe 2016-18 Honda Sensing ACC 由本系统供给；低于 0mph 不可加速；低于 12mph 无 ALC Supported Cars 表
    Honda CR-V 2017-20 Honda Sensing ACC 保留出厂；低于 0mph 不可加速；低于 12mph 无 ALC Supported Cars 表
    Hyundai Palisade 2020-21 All ACC 保留出厂；低于 0mph 不可加速；低于 0mph 无 ALC Supported Cars 表
    Lexus ES 2019-21 All ACC 由本系统供给；低于 0mph 不可加速；低于 0mph 无 ALC Supported Cars 表
    Toyota Camry 2018-20 All ACC 保留出厂；低于 0mph 不可加速；低于 0mph 无 ALC Supported Cars 表
    Toyota Corolla 2020-21 All ACC 由本系统供给；低于 0mph 不可加速；低于 0mph 无 ALC Supported Cars 表
    Toyota Rav4 2019-21 All ACC 由本系统供给；低于 0mph 不可加速；低于 0mph 无 ALC Supported Cars 表
    Toyota Prius 2016-20 TSS-P ACC 保留出厂；低于 0mph 不可加速；低于 0mph 无 ALC Supported Cars 表
    Subaru Forester 2019-21 EyeSight ACC 保留出厂；低于 0mph 不可加速；低于 0mph 无 ALC Supported Cars 表
    Volkswagen Golf 2015-19 Driver Assistance ACC 保留出厂；低于 0mph 不可加速；低于 0mph 无 ALC Community Maintained 表

    读取方法与注意事项

    源文档给出的操作条件集中在安装与接入层面：安装时在设备安装向导中输入指定的安装地址，随后按视频说明把设备固定到风挡；设备自带位姿自动标定，轻微的俯仰、偏航安装误差不影响性能。上车前需先确认当地法规是否禁止在风挡上放置物品。

    数据层面，源文档说明系统会记录面向道路的摄像头、CAN、GPS、IMU、磁力计、温度传感器、碰撞与系统日志；面向驾驶员的摄像头仅在设置中显式开启时记录，麦克风不记录。因此从 CAN 侧能拿到什么，取决于各车型的 opendbc 定义与本机车型代码，源文档并未展开。

    能力边界方面，官方支持的车型将被纳入上游安全模型验证；社区维护车型未被验证，需要先在 Settings->Developer->Enable Community Features 中打开开关才能使用，且使用时须格外谨慎。若要把社区平台提升为官方支持，需满足：brand 下至少拥有一辆车、对应线束在售、panda 与本系统均具备完整 ISO 26262 支持、存在纵向控制的推进路径、AEB 仍保持启用、且支持 fingerprinting 2.0。

    证据等级与边界

    本文全部内容属于「文档登记」，既不是实车观测，也不是外部旁证。能力矩阵中的每一行都来自源文档的表格，可核对；但表格只回答「该平台被登记为支持/社区支持」，不保证具体年款、市场版本、配置包与软件版本都能匹配。源文档用「美国市场参照」列明确提示了这一点。

    三处不能外推。第一，低速边界（No ACC accel below、No ALC below）是按平台登记的名义值，不是对某一台实车测得的曲线，同型号不同配置可能不同——例如源文档用脚注说明 2019 Honda Civic 1.6L Diesel Sedan 在 12mph 以下无 ALC，Camry 的 4CYL 部分配置边界为 28mph。第二，断开 DSU 或加装 ASCM 线束会让本系统接管 ACC，但同时关闭 AEB，这是功能取舍而非免费升级。第三，车速相关字段（如 ALC 边界）来自源文档表格，源文档未提供任何原始报文或 DBC 条目作为间接支持。

    关于「安全访问」类问题，源文档未提供任何绕过方法，且不建议尝试；本项目讨论的是公开文档登记的可读能力，不涉及对车辆安全机制的规避。

    常见问题

    这份档案为什么没有逐条 CAN 信号？

    因为主素材是一份多车型支持矩阵与安装说明，只登记「平台 / 支持包 / ACC 供给方 / 低速边界」四类字段，逐信号定义放在被引用但未包含在本快照内的 opendbc 文件中。这是素材本身的边界，不是解析遗漏。

    「ACC 由本系统供给」与「ACC 保留出厂」有什么区别？

    前者的纵向控制由本系统承担，后者仍由原车 ACC 执行、本系统只做横向。源文档同时提示：在部分平台上，需断开驾驶员支持单元（DSU）或加装社区 ASCM 线束才能切换，而这两种做法都会关闭原车 AEB。

    社区维护车型能当官方支持用吗？

    不能。源文档明确社区维护车型未经上游安全模型验证，须在开发者设置中手动开启社区功能，并提示使用时格外谨慎；升级为官方支持还需同时满足拥有车辆、线束在售、完整 ISO 26262、纵向路径、AEB 保持启用、支持 fingerprinting 2.0 等条件。

    低速边界能不能套用到同型号其他车？

    不建议。源文档的边界是按平台以「美国市场参照」登记的名义值，并以脚注给出个别配置的例外（如某柴油版 Civic 与部分 Camry 配置）。把它直接外推到其他年款、市场版本或配置，超出了源文档的证据范围。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/openpilotusers-opkr084-legacy-subset/README.md（本项目车型档案主来源：支持车型与社区维护车型矩阵、安装说明、目录结构）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • Vtrux 与 Coda EV：网关型改装车的 CAN 信号档案

    结论：Vtrux（2014 款 Silverado 1500 的 EREV 改装车）最典型的数据特征是「一车三总线 + 主动网关」：OBD-II 口后面不是一条总线，而是三条独立 CAN，由 VCM 做跨总线网关，并且 VCM 会主动改写 ECM 的发动机数据——真实转速只在 OBD 总线上，Vehicle 总线上是约 800 RPM 的合成值。同仓库记录的 Coda EV 则是「一车四总线 + 网关转发」。以下结论仅限源文档记录的这两辆车及其固件与校准。

    车辆与适用范围

    本文数据来自第三方开源项目对两台实车的逆向记录：一台是 2014 款 Silverado 1500 的 EREV 改装车 Vtrux，另一台是 Coda EV 纯电轿车，两者出自同一仓库。

    项 内容
    车型 Vtrux —— 2014 款 Silverado 1500 的 EREV 改装车；同仓库另记录一台 Coda EV 轿车
    年款 / 市场版本 Vtrux 底车为 2014 款；Coda 年款与市场版本源文档未确认
    动力与改装状态 A123 LFP 电池包 116 节串联，标称约 383 V（约 360 V@10% SoC 至约 422 V 充满）；原 GM 变速箱换成双 Remy 电机配 Dana TM4 CO150 逆变器；Woodward Motohawk 整车控制器（Via Motors VCM）兼作 GM CAN 网关
    采集跨度 源文档为多条实车日志（充电、公路巡航、隔离与互锁故障、过热等场景）加台架回放，未给出统一时长与帧数
    适用范围 仅限源文档记录的这两辆车与所列日志；不适用于量产 Silverado，也不保证适用于同型号其他改装车

    总线与寻址

    两台车都以经典 CAN 与 11 位标准帧为主，源文档未给出这两辆车的总线波特率。Vtrux 的核心特征是「三总线 + 主动网关」，Coda 是「四总线 + 网关转发」。日志通道编号都会随采集器插拔顺序变化，因此必须按报文内容识别总线。

    项 内容
    帧格式 车控主用 11 位标准帧；Bel 充电机/逆变器与 DCDC 使用 29 位 J1939 扩展帧
    Vtrux 三条总线 Powertrain（DLC 引脚 CAN-H 1 / CAN-L 9）、Vehicle（引脚 6 / 14）、OBD（引脚 10 / 2）
    Vtrux 总线识别 含 0x051 即 Powertrain；含 0x1E5 与 0x500 即 Vehicle；含 0x040–0x044 即 OBD。不要用 0x441–0x464 判 OBD，该区间含被网关桥接的 GMLAN 报文
    Coda 四条总线 B CAN（引脚 2 / 3）、D CAN（引脚 10 / 11）、C CAN（引脚 7 / 15，直读单体电压）、Diag CAN（引脚 6 / 14，标准 OBD 引脚）；另有不可经 OBD 访问的私有 Motor CAN（DLCM↔MCM）
    Coda 总线识别 C CAN 恒含 0x000–0x019（104 节单体电压）；B CAN 含 0x1D5、0x48A、0x275、0x381、0x383；D CAN 含 0x308、0x312、0x325、0x330、0x580
    网关 Vtrux 用 VCM 跨三总线选择性桥接并改写 ECM 数据；Coda 用 GWM 把 Diag CAN 路由到 J1962 并选择性转发

    已解码信号

    下表从源文档已标注置信度的条目中抽取。Vtrux 的置信度分级为 CONFIRMED（编码与用途均已独立验证）、CONFIRMED-SYMM（由对称结构推出）、CONFIRMED-DECOMPILE（编码由反编译确认，用途仍为标签）、PARTIAL（编码确认但角色或刻度存疑）与 REMOVED（已按策略移除）。Coda 部分沿用源文档的 CONFIRMED 标注。

    信号 位置（ID / DID / 字节） 解码 证据
    bcm_soc（电池 SoC） 0x0410 B3 raw × 0.5 % CONFIRMED（与 0x411 高分辨率 SoC 相关 r=0.9999）
    bcm_ibat（电池电流） 0x0410 B4:B5（大端 uint16） raw × 0.025 − 1000 A CONFIRMED（raw=40000 对应 0 A，发电机启停处穿越零点）
    bcm_vbat（电池包电压） 0x0410 B6[3:0]:B7（12 位） raw × 0.25 V CONFIRMED（接触器闭合后与 GENE_HighPwr_Volt 差不超过 1.25 V；启动哨兵值 1023.5 V 表示无效）
    bcm_cell_vmax / vmin 0x0430 B0[4:0]:B1 / B2[4:0]:B3（13 位） raw × 0.001 V CONFIRMED（稳定窗口内 r 大于 0.99）
    bcm_cell_tmax / tmin 0x0430 B4 / B5 raw × 0.5 − 40 ℃ CONFIRMED
    bcm_lvbat（12 V 电压） 0x0430 B7 raw × 0.1 V CONFIRMED（140=14.0 V DCDC 工作，127=12.7 V 静置）
    bcm_mainc_stat（主接触器状态） 0x0440 B0[5:2]（4 位，16 态） 状态机枚举 CONFIRMED（充电日志观测到 ALL_OPEN→CLOSE_MAINR→WAIT_PRECHARGE→… 的状态转移）
    bcm_vbus_pos / vbus_neg 0x0440 B4:B5[7:4] / B5[3:0]:B6（12 位） raw × 0.25 V / raw × 0.25 − 500 V CONFIRMED（正、负直流母线对地电压）
    GENE_Mot_Trq（发电机扭矩回馈） 0x0471 B0:B1（小端 uint16） raw × 0.125 − 4096 Nm CONFIRMED（与 0x051 扭矩指令相关 r=0.9984）
    GENE_HighPwr_Volt 0x0482 B1:B2[2:0]（11 位小端） raw × 1 V CONFIRMED（高速巡航稳定在 383–384 V）
    GENE_HighPwr_Curr 0x0482 B3:B4[5:0]（14 位小端） raw × 0.25 − 2048 A CONFIRMED（巡航约 −40 A）
    parkLockState（驻车锁状态） 0x055C B0[2:0]（3 位，7 项） 枚举 CONFIRMED（两车原始日志交叉验证）
    ess_power（电池包功率） 0x0598 B0:B1 （raw − 32768）× 0.01 kW CONFIRMED（线上格式不变；源文档另记录某类商业诊断工具自身解码有偏置，该信号已迁出原 DBC 归入实验 DBC）
    VehicleOdometer（整车里程） 0x0625 B0:B1:B2（24 位大端） raw × 1 km CONFIRMED（日志 raw=95,517 km 与仪表读数一致）
    DLCM_TorqueRequest（Coda 扭矩请求） 0x212 B4[3:0]:B5（12 位 nibble 拆分） raw × 0.244 Nm，零点 raw=2000 CONFIRMED（与 0x1C0 扭矩相关 r=0.999，峰值 293 Nm）

    读取方法与注意事项

    最关键的工程约束是总线识别。两台车的日志通道号都不可信——采集器插拔顺序一变，同一通道对应的总线就变了。做法是用 anchor ID 判定：先用一条稳定广播的专属 ID 认出总线，再做解析。Vtrux 还提醒，0x441–0x464 区间混入了被 VCM 桥接到 Vehicle 总线的 GMLAN 报文，用它判 OBD 会误判。

    第二条是网关的影响。Vtrux 的 VCM 会对转发内容做改写：ECM 的真实转速只出现在 OBD 总线（0x0C9，熄火时为 0，运转时为真实值），而 Vehicle 总线上是约 800 RPM 的合成值。轮速被掩零后，ECM 自行算出零车速并广播 0x3E9，形成级联——这不是 VCM 直接改写车速，而是屏蔽输入后的自然结果。因此同一物理量在不同总线上可能有不同含义。

    第三条是周期与新鲜度。同一 ID 在不同固件上周期可能不同（例如某电池电流报文在一种 BMS 变体上是 1 Hz，另一种上是 10 Hz），源文档做相关分析时对不同周期分别用了零阶保持与线性插值，并指出周期差异会影响标定。解析前应先统计每个 ID 的实测频率。

    证据等级与边界

    源文档对每条信号都给了证据分级。CONFIRMED 表示编码与用途都被独立验证（物理试验、日志相关或与参考交叉匹配）；CONFIRMED-DECOMPILE 只说明编码来自反编译，用途仍是原厂标签；CONFIRMED-SYMM 由已确认信号的对称结构推出，没有独立测试；PARTIAL 表示编码确认但角色或刻度仍有未决问题——例如油压信号 GeneOilPress 的零点偏移未确认，其换算在怠速下会得到物理上不合理的数值。

    还有一类被明确记录为「异常」的条目。0x0451 曾被某类商业诊断工具误标为牵引逆变器扭矩，日志显示它其实是 GMLAN 报文，源文档已把对应条目移除；牵引逆变器热信号的真实 ID 是 0x044A，而非工具里列的 0x0459（后者在所有日志中为零帧）。

    边界上必须强调：以上结论仅来自源文档记录的这一台 Vtrux 与这一台 Coda 及其固件与校准。不同年款、不同 BMS 变体，甚至同一车型换了电池包，位置与刻度都可能变化，实车读取前应先在目标车上复核。

    常见问题

    Vtrux 的 OBD 口能直接抓到全部三条总线吗？

    三条总线在 J1962 口上都有引脚可达（Powertrain 1/9、Vehicle 6/14、OBD 10/2），但日志里的通道号是任意的，必须用 anchor ID 判断当前通道对应哪条总线。另外 VCM 会对桥接内容做过滤与改写，因此「在车上抓到」不等于「拿到原始数据」。

    为什么同一辆车上车速会有两个来源？

    因为 VCM 掩零了发给 ECM 的轮速输入，ECM 于是算出零车速并广播 0x3E9，OBD 总线上的该广播因此恒为零。真实车速在 Vehicle 总线上，由 VCM 用真实轮速生成；标准 OBD PID 0x0D 也返回真实车速，但它由 VCM 自己应答，而不是把请求桥接给 ECM。

    标注 CONFIRMED 的信号可以直接拿来用吗？

    可以用，但要区分级别。CONFIRMED 表示编码与用途都被独立验证；CONFIRMED-DECOMPILE 与 CONFIRMED-SYMM 只解决了「编码是什么」，用途仍是推断或标签，源文档已明确保留这一不确定性。PARTIAL 条目在使用前应先补验证。

    这些解码能套用到别的 Vtrux 或 Coda 上吗？

    不能。源文档的全部结论都限定在被记录的这两辆车及其固件与校准上，并明确指出不同 BMS 变体、不同固件之间字节偏移与周期存在差异。换车使用前必须重新复核。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/nickyivyca-vtrux-coda/projects/vtrux/README.md（Vtrux 总线、网关与模块拓扑主来源）
    • 项目 01 —— public-can-dbc-datasets/additional/nickyivyca-vtrux-coda/projects/vtrux/notes/epri-verification.md（已解码信号的置信度分级与证据）
    • 项目 01 —— public-can-dbc-datasets/additional/nickyivyca-vtrux-coda/projects/coda/README.md（Coda 四总线、anchor ID 与解码条目）

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • 2025 Ford F-150 Gen14 的 HS-CAN3 车身信号接入

    结论：这份档案记录的是一台 2025 款福特 F-150（第 14 代）上的车身 CAN 接入实践：车主没有从 OBD 诊断口取数，而是接到 HS-CAN3（500 kbit/s） 上的 C3154A（音响功放）连接器，用 ESP32 板读取床灯、门锁、变速箱 P 挡与电池状态，并反过来驱动床灯与工具箱继电器。它的价值不在「有多少条解码」，而在于一条不改原厂线束的取数路径：具体车身报文的逐字节定义并不在这份文档里，而是引用自公开的 ford_lincoln_base_pt.dbc。下述结论仅限源文档记录的这一台车，不能外推到其他年款、配置或市场版本。

    车辆与适用范围

    源文档是一位车主对自己车辆的改造记录，属于单台车、单人实验，不是车厂或第三方机构的批量采集。文档明确声明「不提供任何支持」，并反复警告接线错误可能危及生命。

    项 内容
    车型 Ford F-150（Generation 14，2025 款），Lariat V8
    年款 / 市场版本 2025 款；源文档未给出市场版本，仅说明为 501A Mid 配置包（无车内氛围灯、无 Bed Utility Package）
    ECU / 改装状态 原厂未改动线束；作者以尾插（pigtail）转接件接到 C3154A，追求「可完全还原」
    采集跨度 源文档未给出日志数或帧数；固件附带 49 个原生单元测试
    适用范围 仅限这一台 2025 Gen14 F150；不同配置的车身电路差异很大（例：尾门独立锁电路只存在于低配车型）

    总线与寻址

    源文档从原厂维修手册得到各条总线的走向，最终选定 HS-CAN3 作为取数总线。物理接入走 C3154A：HS-CAN3 High 在 1 脚（22ga 绿-蓝线），HS-CAN3 Low 在 11 脚（22ga 白-绿线），连接器为 Molex 34728-0200；相邻的 C3154B 提供常电（SBA40，40 号保险）与接地。

    项 内容
    物理层 双绞线 CAN，HS-CAN3 高/低线；需 120Ω 终端
    链路层 / 比特率 500 kbit/s（源文档明示 HS-CAN3 at 500kbps）
    寻址方式 源文档未给出 11 位 / 29 位说明；报文的逐字节定义引用自外部 DBC
    CAN FD 源文档提到曾用某款双通道 CAN FD HAT 抓包，但未说明车辆是否运行 CAN FD；实际按 500 kbit/s 经典 CAN 处理
    接入硬件 AutoSport Labs ESP32-CAN-X2（ESP32-S3 + 双收发器 + 车规电源），Arduino 框架 + PlatformIO

    已解码信号

    这份主素材没有给出任何逐字节报文 ID，它记录的是「这台车被读取/被控制的功能清单」以及对应的硬件引脚。为守住「只抄源文档里有证据的条目」这条线，下表登记源文档明确写出的功能与位置，涉及具体 ID、字节与缩放的条目一律指向被引用但未包含在本快照内的 DBC。

    信号 / 功能 总线或位置 方向 证据
    床灯（CHMSL bed lights）状态 HS-CAN3 只读 README「Features」
    迎宾灯 / 水坑灯（puddle lamp）状态 HS-CAN3 只读 README「Features」
    车门锁状态 HS-CAN3 只读 README「Features」
    变速箱 P 挡状态 HS-CAN3 只读 README「Features」
    蓄电池状态 HS-CAN3 只读 README「Features」
    床灯继电器输出 GPIO5（BEDLIGHT_PIN） 写 README「Configuration」
    工具箱开启继电器 GPIO4（TOOLBOX_OPENER_PIN） 写 README「Configuration」
    工具箱解锁按钮 GPIO17（TOOLBOX_BUTTON_PIN） 读 README「Configuration」
    系统就绪指示 GPIO18（SYSTEM_READY_PIN） 写 README「Configuration」
    CAN 缓冲溢出计数 MCP2515 / TWAI 诊断 诊断 README「Buffer Overflow Detection」
    TWAI 驱动状态 运行时诊断 诊断 README「can_status」
    RX / TX 错误计数（<128 为健康） 运行时诊断 诊断 README「can_status」

    读取方法与注意事项

    接入顺序在源文档里有明确交代：先在手套箱后方的在线连接器上反探测做初步实验，因为车尾拖车连接器处在车辆未运行时「似乎不广播有用报文」。确定 HS-CAN3 承载所需信号后，才改到 C3154A 做正式取数。取数用尾插转接件，不切断原厂线束；文档强调压接与焊点都要做拉拔测试。

    软件侧，固件通过串口（115200）提供诊断命令：can_status 看驱动状态与错误计数，can_debug 连续 10 秒打印全部报文，can_buffers 看缓冲溢出，can_reset 做恢复。若完全收不到报文，文档建议先把 ENABLE_HARDWARE_CAN_FILTERING 置 0 再编译烧录，以排除过滤配置问题。

    一个明确的工程约束是缓冲深度：源文档指出 MCP2515 的硬件缓冲只有 2 条报文，会丢帧。文档给出的缓解方向包括把主循环延时（当前 10ms）调小、把 MAX_MESSAGES_PER_LOOP（当前 10）调大，或改用 ESP32 的 TWAI 控制器。溢出会表现为「繁忙期报文突然停止」「日志出现 Suspected buffer overflow」「静默后出现突发」等。

    证据等级与边界

    本档案的信号清单属于单车主记录：只有一台 2025 Gen14 F150 Lariat V8（501A Mid）作为样本。总线走向、连接器针脚、GPIO 分配这些属于实车观测与手册交叉，可核对；而「车身报文里门锁、床灯具体是哪个 ID、哪些字节」在本文档里没有答案，它来自作者引用的公开 DBC，属于外部旁证，本项目并未逐条复现。

    三处不能外推。第一，配置差异会改变电路：源文档明确说只有低配车型才为尾门保留独立锁电路，而带电动尾门的高配由尾门内模块控制——同型号不同配置不得套用。第二，接入点与线序是针对这台车枚举出来的，其他年款/市场的 HS-CAN3 连接器编号与针位可能不同。第三，作者本人声明不提供任何支持，并警告可能失去保修、损坏车辆甚至造成人身伤害，因此任何照搬都超出源文档的证据范围。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试；本文只整理公开文档登记的可读/可控功能，不涉及对车辆安全机制的规避。

    常见问题

    2025 F-150 的 OBD 口能直接抓到这些车身信号吗？

    源文档没有走 OBD 诊断口，而是接到 HS-CAN3 的 C3154A（音响功放）连接器。OBD 口在本车是否可读这些车身报文，源文档未给出结论，因此不能据此推断。

    为什么接上后收不到报文？

    文档给出的排查顺序是：先确认 CAN 高低线序与 120Ω 终端，再把 ENABLE_HARDWARE_CAN_FILTERING 置 0 用 can_debug 看总线上是否有任何流量，然后用 can_status 看错误计数，用 can_buffers 看是否溢出。若在车尾拖车连接器处取数，车辆未运行时可能本就没有有用报文。

    床灯和门锁的 CAN 报文 ID 是什么？

    源文档未给出具体 ID。它说明所需报文定义来自公开的 ford_lincoln_base_pt.dbc，本档案不代填字节与 ID。

    这套接入会不会影响保修？

    作者明确警告可能失去保修、烧毁车辆甚至危及生命，并声明不提供任何支持。本档案只是对公开文档的整理，不构成任何实车操作建议。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/jantman-ford-f150-gen14/README.md（本项目车型档案主来源：车辆信息、硬件、接线、固件与诊断说明；本快照仅含此文件）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • Hyundai 与 Honda 车型协议：为什么品牌目录不等于通用协议

    结论：品牌目录不是通用协议。Hyundai 的经典 CAN 可选 hyundai／hyundaiLegacy、CAN FD 用 hyundaiCanfd；Honda 分 Nidec 与 Bosch，Bosch 还要再分雷达版／无雷达版及 CAN FD。它们是不同的能力组合，必须声明精确平台、固件范围与总线拓扑。CarController 的软件限幅不替代 panda 安全钩子，CarState 的解析结果也不替代固件对驾驶员扭矩、制动和巡航状态的独立采样。

    Hyundai：经典 CAN 与 CAN FD

    Hyundai 按 CANFD 分支：用相机和 E-CAN 指纹判别 LKA／LFA、按钮、档位及 SCC 来源，LONG、能源类型和限制参数写入 safetyParam。这里要记住：alphaLongitudinalAvailable 与 openpilotLongitudinalControl 分开，前者不能保证后者启用。

    层 关键入口 已核对的实现
    ECU 生命周期 init()、deinit() 自控纵向且非相机 SCC 时发送 UDS 通信控制，目标地址依平台／转向架构改变；退出尝试恢复。
    输入 CarState.update()、update_canfd() 分别把经典 CAN／CAN FD 的速度、驾驶员输入、巡航、转向、车门等信号映射到统一 CarState。
    输出调度 CarController.update() 经典 CAN 与 CAN FD 分流至 create_can_msgs()／create_canfd_msgs()。
    构帧 hyundaican.py、hyundaicanfd.py 经典 CAN 的 LKAS11／CLU11／SCC 帧与 CAN FD 的转向、取消、ACC、LFA 抑制帧分别构造；CAN FD 的 CanBus 映射 E-CAN、A-CAN、相机总线，不能硬编码单一 bus。
    固件接收／发送 hyundai_rx_hook()、hyundai_tx_hook()、hyundai_canfd_tx_hook() 两条分支检查转向扭矩／请求间隔、加速度及按钮权限，诊断地址仅准许指定 tester-present 载荷。
    模式组装 hyundai_init()、hyundai_legacy_init()、hyundai_canfd_init() Legacy 因旧报文缺计数器／校验而采用不同接收检查，不能视作安全规则全等。

    Honda：Nidec 与 Bosch

    Honda 的 Bosch 用 hondaBosch、Nidec 用 hondaNidec；Bosch 继续区分雷达版、无雷达版及 CAN FD。Bosch CAN FD 在此快照中不开放实验纵向。

    层 关键入口 已核对的实现
    ECU 生命周期 init()、deinit() 有雷达的 Bosch 自控纵向会尝试禁用雷达 ECU 通信，退出时尝试恢复。源码明确警告此操作会禁用原车 AEB。
    输出调度 CarController.update()、compute_gas_brake() 区分 Bosch／Nidec；actuator_hysteresis() 与 brake_pump_hysteresis() 处理 Nidec 制动输出。
    构帧 hondacan.py 按平台总线构帧；CanBus 映射 PT、radar、camera 等总线。
    固件接收 honda_rx_hook() 备用刹车报文 0x1BE 避免把某些车型电脑制动误判为用户踩刹车；Nidec 的原车 AEB 制动与 openpilot 制动比较后决定转发。
    模式与转发 honda_nidec_init()、honda_bosch_init()、honda_nidec_fwd_hook() Nidec 对相机制动帧 0x1FA 进行动态转发；Bosch 实验纵向在固件中受 ALLOW_DEBUG 编译门限制，不能只看 Python 配置推断可用。

    另外两处细节也影响拆分：Hyundai 侧，经典 CAN 可选 hyundai／hyundaiLegacy，CAN FD 转向灯能力还可能涉及额外 ECU；Legacy 因旧报文缺计数器／校验而采用不同接收检查，测试入口覆盖相机 SCC、Legacy、能源类型、纵向、AEB 位、按钮和诊断场景，但不等于覆盖所有实车变种。

    Honda 侧，honda_tx_hook() 对 Nidec 检查制动／HUD，对 Bosch 检查加速度／油门，均阻止主机发送 AEB 执行位；无使能时转向只能为零，Bosch 按钮只能取消，诊断地址仅准许指定 tester-present。备用刹车报文 0x1BE 用于避免把某些车型电脑制动误判为用户踩刹车。

    Hyundai 的固件发送侧还要区分纵向状态：hyundai_canfd_tx_hook() 在非自控纵向时仅允许符合取消语义的 ACC 帧，经典 CAN 则另检查 FCA11／SCC12 的 AEB 执行位。Honda 侧的转发也不对称：honda_nidec_fwd_hook() 对相机制动帧 0x1FA 动态转发，而 Bosch 实验纵向在固件中受 ALLOW_DEBUG 编译门限制，不能只看 Python 配置推断可用。

    为什么必须按能力组合拆分

    同一品牌下，CAN／CAN FD 与 Nidec／Bosch 是不同能力组合，不能互相套用。Honda 的原车 AEB 保留与否依硬件架构和具体纵向方案而变：Nidec 用相机制动帧的动态转发，而 Bosch 雷达禁用方案是另一条路径，不能把 Nidec 转发逻辑套到 Bosch 雷达禁用方案。Hyundai 侧，hyundai_canfd_tx_hook() 中的转向限值还包含驾驶员扭矩抵消、速率与 EPS 转向请求切断容差；这些是固件拒绝候选帧的条件，不应在插件层开放为任意可改配置。

    换句话说，能力组合必须由「平台 + 固件范围 + 总线拓扑 + 传感器架构」共同定义，任何一项缺失都可能把另一套组合的结论错误套用过来；这也解释了为何同品牌不同年款需要各自的证据链。

    车载硬件与插件化含义

    1. 车型插件应声明精确平台、固件范围、总线拓扑、DBC、能力与安全模式参数；同一品牌的 CAN／CAN FD 或 Nidec／Bosch 必须是不同能力组合。不能让插件动态改写 panda 固件的 TX 白名单和物理限制。
    2. ECU 通信控制必须是受控生命周期操作，记录请求、响应、超时及恢复结果。尤其 Honda Bosch 雷达禁用涉及原车 AEB；目标硬件设计应先明确是否允许此工作模式，而不是默认启用。
    3. 硬件网关需要保持总线来源与时间戳、独立看门狗、断电／主机失联回退、板上 RX／TX／转发安全门；E-CAN／PT／camera 总线映射错误是安全风险，不是普通配置瑕疵。
    4. 每个目标车型建立指纹和固件识别、DBC 解析／打包、安全测试、日志回放、断线与错误帧注入、SIL／HIL、封闭场地验证的证据链。未知或模糊匹配保持被动，不以品牌名放行执行。

    常见问题

    为什么同一品牌要按经典 CAN 与 CAN FD 分开？

    因为两者有不同的输入映射、构帧函数与安全模式：Hyundai 的经典 CAN 可选 hyundai／hyundaiLegacy、CAN FD 用 hyundaiCanfd；Legacy 还因旧报文缺计数器／校验而采用不同接收检查。它们是不同能力组合，不能视作同一套安全规则。

    Honda 禁用雷达 ECU 通信有什么代价？

    源码明确警告：有雷达的 Bosch 自控纵向禁用雷达 ECU 通信的操作会禁用原车 AEB。因此不能把它当作无副作用的模式切换，目标硬件设计应先明确是否允许此工作模式。

    Bosch 的实验纵向能在固件里开放吗？

    在固件中受 ALLOW_DEBUG 编译门限制，不能只看 Python 配置推断可用；此外 Bosch CAN FD 在此快照中不开放实验纵向。

    Nidec 的相机制动帧转发能套用到 Bosch 吗？

    不能。Honda 的原车 AEB 保留与否依硬件架构和具体纵向方案而变；Nidec 对相机制动帧 0x1FA 的动态转发与 Bosch 雷达禁用方案是不同路径，不能互相套用。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/HYUNDAI_HONDA_DEEP_DIVE.md（取用了 Hyundai 经典／CAN FD 链路、Honda Nidec／Bosch 链路，以及车载硬件与插件化含义）。
    • 项目 02 —— openpilot-research/HYUNDAI_CANFD_PANDA_SAFETY_DEEP_DIVE.md（仅用于确认 CAN FD 逐模式 RX／TX 总线矩阵与纵向构建门的引用位置）。

    说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • 2330 份 DBC、294 个来源：公开 CAN 数据集的收录与分级

    结论：公开 CAN/DBC 数据集的核心不是「收了多少文件」，而是「每个文件能不能溯源、能不能分级、能不能再分发」。本次整理收录 2,330 个 DBC 文件副本，来自 294 个 DBC 来源集合，收录日期为 2026-10-03 并扩至 2026-10-05；其中相当一部分条目只有「研究用途」而没有明确许可证，只能离线留存，不能当成可直接商用的车型字典。.dbc 只描述 CAN 标识符、位域、缩放、单位与枚举，它不是适配保证书。

    一次整理到底收了多少东西

    这次收录的主体是 DBC 文件：.dbc 与 .DBC 合计 2,330 个副本，分布在 294 个 DBC 来源集合里。之所以把「文件副本数」和「来源集合数」分开记，是因为同一份定义会在不同快照里反复出现；只看文件总数会高估真实覆盖度。

    DBC 之外还附带了一批原始数据，用来在信号定义之外做交叉验证：Renault Mascott 的 6 份 CAN 日志、Mitsubishi Outlander PHEV 的 11 份 CSV 抓包与 8 份 CMU 记录、Fiat Ducato X250 的 5 份 SLCAN 抓包、BMW PHEV BMS 的 7 份 CSV 日志、Volvo V50 的 3 份 CSV 抓包、RAM ProMaster 的 2 份 CAN-B 抓包，以及 Jeep/Dodge 的 3 份 ODS CAN 映射。

    另一部分是 opendbc/ 的本地副本，共 119 个 .dbc，包含 model/platform 定义与品牌级 generator 源文件，随附的许可证是 MIT。来源快照之间存在文件重叠，因此目录被刻意分开保存，而不是合并成一个扁平库——分开保存是为了保住每个文件的来源路径。

    类别 数量 说明
    DBC 文件副本 2,330 .dbc 与 .DBC，来自 294 个来源集合
    opendbc 本地副本 119 相邻工作区快照，含模型/平台与品牌 generator，MIT 许可
    原始 CAN 日志 / 抓包 数十份 Mascott 6、Outlander PHEV 11+8、Ducato X250 5、BMW PHEV BMS 7、Volvo V50 3、ProMaster 2、Jeep/Dodge ODS 3
    分析 / 转换工具 若干 抓包查看、格式转换与信号反推类工具

    为什么同一款车会出现多个 DBC 版本

    整理时最容易被误解的一点是「同车型为什么有好几份 DBC」。原因大多不是数据变多，而是来源重叠：一批 fork 里 77 个上游 DBC 与已归档文件字节完全相同，被直接省略；另一归档省略了 68 个上游重复文件与 1 个 parser 测试夹具；还有若干「仅行尾不同」的副本被判定为重复而不重复收录。

    因此整理用的计数口径是字节不同（byte-distinct），而不是「文件名不同」。真正的版本差异还包括：更新的信号定义、字段增删，甚至只是一处注释错别字。每个来源条目都记录了本地文件、车型覆盖、来源 Git 修订号和许可证，这样后续才能回答「这份 DBC 到底来自哪一次提交」。

    许可证决定「能不能再分发」

    收录不等于可用。公开来源里许可证状态差异很大：有的是 MIT、Apache-2.0、GPL-3.0、CC BY 4.0、CC BY-SA 4.0、CC0，也有大量条目写着「未找到许可证，仅作离线研究副本」。后者可以离线分析，但不代表可以再分发给第三方，更不代表可用于商业产品。

    许可证状态 可否再分发 整理时的处理
    MIT / Apache-2.0 可以 保留版权与署名声明
    GPL-3.0 可以（具传染性） 衍生作品需沿用同协议
    CC BY 4.0 / CC BY-SA 4.0 可以（需署名 / 同协议） 保留原作者署名
    CC0 1.0 可以 无附加限制
    未找到许可证 不可以 仅离线研究，不重分发；部分来源仅保留发现链接

    还有一层坑：上游仓库带 MIT，不代表其中每一份车辆定义都干净。「上游 MIT 但个别车辆定义可能另有来源或第三方权利」是明确写在质量说明里的，需要单独核查。个别来源的 LICENSE 甚至明确禁止复制，整理时只保留发现链接、不归档文件本体。

    DBC 只描述信号，不保证适配

    质量说明里有几条必须原样保留的边界：DBC 解码的是 CAN 标识符、位域、缩放、单位与枚举，它不构成通用适配保证，必须针对目标车辆的年款、市场、动力总成、ECU 与总线拓扑逐一核实；社区推导出的信号名与缩放往往不完整，在拿到只读抓包与独立测量之前，只能当作假设。

    此外，opendbc/ 副本是一份工作区快照，其原始 Git 提交号未被记录，其他下载来源则钉住了具体修订号。整理说明也明确划出红线：本目录不包含绕过防盗器、安全访问或操纵安全关键车辆控制的说明。安全研究类数据集（如带标签注入流量的车联网数据集）虽然也是公开来源，但性质是安全研究数据集而非信号 DBC，必须在隔离、离线的轨迹上实验。

    整理时留下的四条纪律

    1. 目录按来源分开，不按车型合并。来源路径是溯源链，合并即丢失。
    2. 用字节不同计数，不用文件名计数。行尾差异与上游重复要被识别并剔除。
    3. 许可证随文件一起记。没有许可证的只做离线研究，不进入可分发集合。
    4. 信号当假设，不当事实。DBC 与原始抓包并存，等待只读验证。

    常见问题

    有了公开 DBC 就能直接上车解码吗？

    不能直接等同。DBC 只给出标识符、位域、缩放、单位与枚举的解释方式，是否匹配还要按目标车辆的年款、市场、动力总成、ECU 和总线拓扑逐一核对；社区信号在通过只读抓包与独立测量验证前只能视为假设。

    为什么同一车型会出现多个 DBC 版本，哪个才对？

    多数是来源重叠造成的：同一份定义在不同快照里重复出现，或仅行尾不同。整理按「字节不同」计数，并保留每个来源的 Git 修订号；真正的版本差异要看字段增删与信号定义变化，不能只看文件名。

    没有许可证的 DBC 可以商用吗？

    不可以。收录里明确标注「未找到许可证，仅作离线研究副本」的条目，只能离线分析，不能重分发；个别来源的 LICENSE 甚至直接禁止复制，整理时只保留发现链接、不归档文件。

    DBC 数量能当作覆盖度指标吗？

    不能。2,330 个文件副本里存在大量上游重复与行尾差异副本，数量会被重复计数放大；更有意义的指标是「字节不同的定义数」加上「已验证车型 / 总目标车型」的比例。

    延伸阅读

    参考资料

    • 项目 01 —— car-scanner-research/public-can-dbc-datasets/README.md（收录规模、来源清单、许可证与质量说明、其他公开来源）
    • 项目 01 —— car-scanner-research/public-can-dbc-datasets/opendbc/dbc/README.md（opendbc 本地副本的项目说明与生成器结构）

    说明：本文为对固定素材快照的静态整理分析，未逐份打开并验证全部 DBC、未连接车辆、未验证目标车型的真实信号组合。文中所有数量、许可证与来源信息均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • 17 个车型目录与 DBC 编解码：车型指纹为什么不能只看一条报文

    结论：车型识别不是「看到某条报文就认出车」，而是一条固定链路：panda 收帧 → CAN 指纹 → ECU 固件匹配 → 生成 CarParams / safetyConfigs → DBC 编解码 → 车型 CarState/CarController。在固定源码快照里，17 个车型目录只证明「实现入口存在」，不构成对任何年款、平台的适用性声明；未识别或模糊匹配的候选会被降为被动（noOutput），而不是「先跑起来再说」。

    车型实现的共同骨架：五个模块各管一段

    车型能力的加载入口是 load_interfaces()，它由 BRANDS 加载车型 CarInterface，不是运行时扫描任意插件目录。也就是说，能不能被识别，先取决于是否在注册表里，而不是目录里有没有文件。

    每个品牌常规包含四个模块：values.py 负责车型枚举与物理配置；interface.py 负责车型参数与安全模式；carstate.py 把接收帧变成 CarState；carcontroller.py 把 CarControl 变成候选发送帧。部分品牌另有 radar_interface.py。四者职责不能互相替代——这是接口契约，不是风格问题。

    把整条链路摊开看：panda 接收 CAN，交给 card；card 做指纹与 ECU 固件匹配，得到 CarParams 与 safetyConfigs；同一路用 DBC 加 CANParser 解出车型 CarState.update；controlsd 产出 carControl，交回车型 CarController.update；再经 DBC 加 CANPacker 编码为 sendcan，由 pandad 经 USB 发出，最终落在 panda 固件的 safety_tx_hook。主机侧解码和编码只是前段，是否真正上总线由固件独立许可。

    17 个车型目录索引：是入口索引，不是适用性声明

    下表仅证明固定快照中的实现入口存在——每个目录的 interface.py、carstate.py、carcontroller.py、values.py 均已在目录中核对。它不代表已完成 17 个品牌、所有平台和年款的报文与安全审计。

    品牌目录 额外雷达接口 当前深度
    body 无 非汽车双轮平台链路已追踪
    byd 无 Atto 3 转角链路已追踪，仅调试安全模式
    chrysler 有 Pacifica/Ram/CUSW 主要链路已追踪
    ford 有 经典 CAN/CAN FD 主要链路已追踪
    gm 有 ASCM/相机 ACC 主要链路已追踪
    honda 有 Nidec/Bosch 主要链路已追踪
    hyundai 有 经典 CAN/CAN FD 主要链路已追踪
    mazda 无 扭矩/速度迟滞主要链路已追踪
    mg 无 扭矩链路已追踪，仅调试安全模式
    mock 无 非实车空发送回退已追踪
    nissan 无 转角/车型取消主要链路已追踪
    psa 无 三总线转角链路已追踪，仅调试安全模式
    rivian 有 Gen1/Gen2 主要链路已追踪
    subaru 无 Global/Preglobal 主要链路已追踪
    tesla 有 转角/原车转发主要链路已追踪
    toyota 有 本篇样本已逐层追踪
    volkswagen 有 MQB/MEB/MLB/PQ 主要链路已追踪

    这张表不能用同一品牌的安全文件代替平台差异验证。例如 Hyundai 有 CAN FD 分支，Volkswagen 有多种平台安全模式，Subaru 有 preglobal 分支。尤其 set_safety_hooks() 注册表把 MG、PSA、BYD、Subaru Preglobal、Volkswagen MLB/PQ 等模式置于 ALLOW_DEBUG 条件下——实现目录和测试存在，并不表示发布固件可启用执行。

    从 CAN 指纹到 safetyConfigs：启动阶段的门

    识别发生在启动阶段，顺序由若干入口固定。下面每一行的边界都需要单独记住：

    入口 行为与边界
    can_fingerprint() 在总线 0/1 以 CAN 地址及数据长度逐步排除候选；超过限定帧数后停止，不保证未知车型能识别。
    fingerprint() 优先查询 VIN、ECU 存在性及固件版本，再收集 CAN 指纹；单一固件候选可覆盖 CAN 结果；环境变量可强制指纹，仅用于受控开发。
    match_fw_to_car() 先尝试精确固件匹配，失败再尝试模糊或品牌自定义匹配；返回是否精确及候选集。
    get_car() 无候选时回退 MOCK；用候选接口生成 CarParams，并保留 VIN、固件、指纹来源及模糊匹配标记。
    Car.__init__() 发布 CarParams；无控制器、开关关闭或仅仪表记录时设为 passive，安全配置改为 noOutput。
    Car.controls_update() 仅在进程初始化、非被动、carControl 存活的路径调用车型 apply() 形成 sendcan；首次进入时设置 ControlsReady。

    MOCK、passive、dashcamOnly 是不可等同的三种状态，但都不能作为「未知车型可以开始执行」的理由。用户配置或环境变量强制指纹，也不构成车辆协议兼容性验证。

    DBC 编解码的函数级语义

    DBC 层决定「字节怎么变成数、数怎么变成字节」，但它既不负责安全，也不负责身份。以下入口的语义是这张表的核心：

    入口 关键实现与含义
    DBC.__init__() / get_checksum_state() 从生成 DBC 或文件加载消息、信号、枚举；按 DBC 系列选择校验算法。
    get_raw_value() 按大小端与 bit 位提取原始整数；符号、倍率和偏移由 MessageState.parse() 处理。
    MessageState.parse() 解码信号、计算校验和与计数器；失败时返回 False，不把该帧的部分值提交到 vl。
    MessageState.update_counter() 递增错误计数，达到阈值拒绝；有效后逐步恢复。
    CANParser.update() 仅接收指定 bus 和已注册地址，更新 vl、本次所有值和时间戳，返回成功解析的地址集合。
    CANParser.can_valid / bus_timeout 前者检查已注册报文的最近成功时间、计数器及累计缺失次数；后者单独观察整条总线空窗，两者语义不同。
    CANPacker.pack() 反向应用倍率/偏移，编码信号，自动补计数器与校验和；未知信号仅记录错误并跳过，不负责安全许可。

    两个容易踩的边界：CANParser 的 vl 只保存最近一次成功解析值，不能只看数值而忽略 can_valid、时间戳与 bus 健康；can_valid 在读取时也会更新缺失计数，所以调用频率会影响去抖过程，它不是纯无副作用的 getter。另外，CANPacker 是协议编码器，不是转向扭矩或加速度安全门。

    面向插件化的最低契约

    把上面几层抽象成可替换的插件时，有五条底线必须写进契约：

    1. 车型插件声明平台、ECU 固件范围、DBC 版本、总线拓扑、能力位、CarParams 与安全模式；未识别或模糊匹配默认被动。
    2. 解码插件输出值、时间戳、来源与校验/计数器/超时状态；不能把上次成功值伪装成当前有效观测。
    3. 控制插件只产生结构化 CarControl 或候选 CAN 帧；不能自行改固件白名单、安全模式、ControlsReady，或绕过 card/pandad。
    4. 硬件安全控制器独立于应用 CPU，实现 RX/TX/转发限制、心跳失效回退与板级故障处理；新硬件须用故障注入、SIL/HIL 与封闭场地验证。
    5. 每个目标车型逐一建立解析、编码、固件安全和回放基线；17 个品牌目录不是「一套通用线束或固件配置」规格。

    换句话说，能不能读到一条报文，与"这套配置能否在目标车上安全执行"是两个不同层级的问题。把前者当成后者，正是识别与安全最常被混淆的地方。

    常见问题

    为什么不能靠一条 CAN 报文就确定车型？

    因为 can_fingerprint() 是在总线 0/1 上以地址和数据长度逐步排除候选，超过限定帧数后会停止，源文档明确它不保证未知车型能识别；而 fingerprint() 还要结合 VIN、ECU 存在性与固件版本，单一固件候选才可能覆盖 CAN 结果。单条报文只是排除过程的一个输入。

    车型目录里有文件，是否代表这辆车就能用？

    不代表。17 个目录只证明实现入口存在，源文档特别说明它不代表已完成 17 个品牌、所有平台和年款的报文/安全审计；而且 MG、PSA、BYD 等模式被放在 ALLOW_DEBUG 条件下，实现目录和测试存在并不表示发布固件可启用执行。

    DBC 解析成功，是否意味着数据可信？

    不等于。CANParser 的 vl 只保存最近一次成功解析值，必须同时看 can_valid、时间戳与 bus 健康；can_valid 读取时会更新缺失计数，调用频率会影响去抖。数值正确但报文陈旧或总线超时，仍属于不可信输入。

    未识别或模糊匹配时，系统会怎样处理？

    get_car() 在无候选时回退 MOCK；当车型被设为 passive（无控制器、开关关闭或仅仪表记录）时，安全配置改为 noOutput。源文档强调 MOCK、passive、dashcamOnly 不可等同，且都不能作为未知车型开始执行的理由。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/CAR_PROTOCOL_IMPLEMENTATIONS.md（取用了 17 个车型目录索引、启动识别门、DBC 编解码函数语义与插件化最低契约）。
    • 项目 02 —— openpilot-research/CAN_PARSER_HEALTH_DEEP_DIVE.md（仅用于确认 can_valid/bus_timeout 的健康位语义边界，未取用其未公开内容）。

    说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • 17 个品牌参数怎么构建：CarParams 冻结只到顶层，嵌套字典仍可变

    结论：车型参数不是一张静态表，而是「17 个品牌枚举 → PLATFORMS 候选字典 → CarSpecs 尺寸 + PlatformConfig 文档与 DBC → 品牌 _get_params() 覆写」的多段构建结果。冻结（freeze）只作用于配置对象这一层：flags 被锁定后不可改，但嵌套的 dbc_dict 与 car_docs 仍可原地修改，override() 返回的还是未冻结副本。因此「能生成 CarParams」只说明字典装载成功，既不等于该车型被识别，也不等于控制器获准发送。以下为固定源码快照 c8fb906 的静态结构分析。

    参数构建的顺序与产物

    values.py 汇集 17 个品牌的 CAR 枚举，并生成候选名到平台对象的 PLATFORMS 字典。每个平台带着三样东西：描述整车尺寸的 CarSpecs、记录文档与 DBC 映射的 PlatformConfig，以及一组 flags。枚举构造时给配置填 platform_str 并冻结配置对象；CarSpecs 本身是 frozen dataclass。

    真正把参数拼起来的是两段函数。get_std_params() 先写入车型名、横向最大加速度文档值、控制类型、轮速系数、PCM 巡航与纵向缺省；随后 get_params() 复制平台规格并调用品牌 _get_params()。这个钩子可以依据 CAN 指纹、固件、开发/发布模式设置总线、雷达、纵向与控制调参，是品牌策略的主要落点。

    品牌覆写之后，普通汽车会加 STD_CARGO_KG=136 kg，再按以 Civic 为基准的比例公式估计 rotationalInertia 与 tireStiffnessFront/Rear；notCar 跳过载荷。这里要强调：刚度与惯量是启发式缩放，不是本次车辆的在线辨识结果，自制硬件接入车型时这些动力学参数不保证准确。

    阶段 入口 产出或作用
    平台注册 values.py / PLATFORMS 17 个品牌候选名映射到平台对象与 PlatformConfig。
    共同缺省 get_std_params() 写入车型名、控制类型、轮速系数、巡航与纵向缺省。
    品牌覆写 品牌 _get_params() 按指纹/固件/模式设置总线、雷达、纵向、panda 安全配置。
    载荷与动力学 STD_CARGO_KG 与缩放公式 非 notCar 加 136 kg，估计转动惯量与轮胎刚度。

    冻结边界：顶层不可变，嵌套仍可变

    隔离探针确认了一个容易被误读的边界：创建 Platforms 子枚举时，PlatformsType.__new__() 给配置写入平台名并冻结，随后直接改 flags 会抛异常；但 dbc_dict 的条目与 car_docs 列表仍可原地修改。

    更关键的是 override() 的语义。对已冻结配置调用 override(flags=...) 会通过 dataclasses.replace() 产生一个未冻结的新对象，且新旧配置共用同一 dbc_dict 引用；相对地，CarSpecs.override() 返回的新规格仍是 frozen dataclass。也就是说，「冻结的是配置对象属性」不能被误解为整个嵌套对象图都经过不可变性与签名校验。自制插件若用 manifest 描述车型，需把嵌套映射与列表做不可变快照或深拷贝并纳入签名与哈希，不能只依赖顶层 freeze()。

    扭矩数据与横向回调

    横向能力由三份 TOML 与一组回调共同决定。get_torque_params() 读取 substitute.toml、params.toml、override.toml，以 legend 解释三列数值，结果缓存在进程内；同一候选若直接出现在多个 TOML 会抛异常，替代目标则按 override 优先、params 次之取值。configure_torque_tune() 设置 FRICTION、LAT_ACCEL_FACTOR、零 offset 与角度死区。

    缺省前馈 get_steer_feedforward_default() 约为目标转角乘车速平方，GM 等品牌可重写。缺省的 torque_from_lateral_accel_linear() 与 lateral_accel_from_torque_linear() 按 latAccelFactor 正反映射，品牌同样可替换。要注意 MAX_LAT_ACCEL_MEASURED 用于 CarParams.maxLateralAccel，而摩擦与侧向加速度因子进入扭矩调参，三者不能互换。

    源或函数 实际作用 关注点
    get_torque_params() 读取三份 TOML 并缓存结果 同候选出现在多个 TOML 会抛异常；替代目标按 override 优先。
    configure_torque_tune() 设置摩擦、侧向加速度因子、零 offset 与角度死区 数据表与平台覆写共同决定控制器输入，不能假设热改立即生效。
    get_steer_feedforward_default() 缺省前馈约为目标转角乘车速平方 GM 等品牌可重写，不是跨车型通用标定。
    torque_from_lateral_accel_linear() 按 latAccelFactor 正反映射扭矩与侧向加速度 需验证符号、单位、摩擦与零点。

    实例运行契约与基类扩展点

    CarInterfaceBase.__init__() 创建品牌 CarState、其 CANParser 集合与 CarController，并把解析器的 DBC 名传给控制器。update() 更新所有解析器、调用品牌状态函数、汇总 canValid/canTimeout 并处理仪表速度与按键；apply() 委派品牌控制器生成回报与待发 CAN 帧，但它不负责硬件限幅。

    仓储里还有几个常被忽略的基类语义：RadarInterfaceBase.update() 缺省每五次调用返回空雷达数据、其余返回 None；init()/deinit() 供品牌实施 ECU 初始化或恢复，基类为空，且 deinit() 在 card 退出时不保证被调用；get_interface_attr() 动态导入品牌 values/fingerprints 属性，ImportError/OSError 会被静默跳过，因此它并不是可靠的插件装载审计。

    基类接口 职责与边界
    __init__() 创建品牌 CarState、CANParser 与 CarController；DBC 名传给控制器。
    update() 更新解析器、汇总 canValid/canTimeout、处理仪表速度与按键。
    apply() 委派品牌控制器生成回报与待发帧，不负责硬件限幅。
    RadarInterfaceBase.update() 缺省每五次返回空雷达数据，其余返回 None，有雷达平台须覆写。
    init()/deinit() 品牌可实施 ECU 初始化或恢复；deinit() 不保证在 card 退出时被调用。
    get_interface_attr() 动态导入品牌属性，异常静默跳过，非可靠装载审计。

    插件化边界与验证缺口

    面向自制硬件，源文档给出的是一组建议设计而非已实现能力：平台插件以版本化 manifest 声明车型、硬件拓扑、DBC 哈希、固件证据、单位、参数范围与所需安全模式；参数构建拆成纯函数与受限生命周期钩子，_get_params()、init() 不应由普通诊断或 UI 插件获得原始 CAN 发送权；行车期间冻结参数与插件版本，重启后再重新识别与验证。

    同时应区分四个层级的门：「可生成 CarParams」「CANParser 正常」「控制器允许发送」「MCU 允许执行」；任一失败都应退回只读或 noOutput。需要提醒的是，现有测试只覆盖参数基本范围与空 CAN 下的不崩溃行为，不覆盖真实车型识别、DBC 真实性、全部 _get_params() 分支与实车动力学。自研硬件仍需要离线日志、台架与实车的分级验证。

    常见问题

    冻结后的 PlatformConfig 真的完全不能改吗？

    不是。冻结只锁住配置对象属性：flags 不可改会抛异常，但嵌套的 dbc_dict 条目与 car_docs 列表仍可原地修改。override() 还会通过 dataclasses.replace() 生成未冻结新对象，并且新旧配置共用同一 dbc_dict 引用。插件若依赖不可变性，需自行做深拷贝并纳入签名。

    STD_CARGO_KG 是 136 kg 吗，为什么有的车型不加？

    源文档给出 STD_CARGO_KG=136 kg，普通汽车在品牌覆写后加上，notCar 跳过载荷。转动惯量与轮胎刚度也是按以 Civic 为基准的比例公式估计的启发式缩放，不是本次车辆的在线辨识结果。

    get_non_essential_params() 能当作上车参数吗？

    不能。它用空 CAN 指纹、空固件及关闭的特性开关构建参数，自身文档明确警告缺少真实 FW/指纹时控制必需参数可能不完整或错误，适合文档、测试与离线展示，不是上车控制参数的证明。

    同一个候选车型出现在多个扭矩 TOML 会怎样？

    会抛异常。源文档说明：同一候选若直接出现在多个 TOML 会抛异常；被替换的目标则按 override 优先、params 次之取值。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/CAR_PLATFORM_PARAMS_CONTRACT_DEEP_DIVE.md（参数构建顺序、冻结边界、扭矩 TOML 与基类实例契约）。
    • 项目 02 —— openpilot-research/ 同目录探针记录：四项平台配置冻结契约与假平台枚举隔离探针结论。

    说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11