结论：车型参数不是一张静态表，而是「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 次之取值。
延伸阅读
- 同一个「转向灯」在三家车厂是三种实现：车辆状态归一化的坑 —— 品牌覆写之后，状态字段还要跨车厂归一。
- 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 参数构建之外的信号新鲜度边界。
- 横向目标曲率到执行器：来源仲裁、时序与限幅 —— 扭矩与侧向加速度因子最终怎么进入横向控制。
- 从使能到车轮：执行链上的八道门，以及它们各自不保证什么 —— 「可生成 CarParams」之后的门还有哪些。
参考资料
- 项目 02 ——
openpilot-research/CAR_PLATFORM_PARAMS_CONTRACT_DEEP_DIVE.md（参数构建顺序、冻结边界、扭矩 TOML 与基类实例契约）。 - 项目 02 ——
openpilot-research/同目录探针记录：四项平台配置冻结契约与假平台枚举隔离探针结论。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复