结论：Tesla 与 Rivian 都属于电动车，但不能共用一套「电动车插件」：Tesla 是转角控制加选择性原车报文转发，Rivian 是动态扭矩加原车 ACC 状态取消，两者在总线拓扑、原车辅助系统与安全策略上均不同。两品牌的纵向参数读取都受 ALLOW_DEBUG 限制，车型/固件识别是执行前提；未识别、无法确认固件或未接线时保持被动。本文为源码静态分析，没有实车、线束、固件构建或 HIL 验证。
Tesla：转角控制与选择性转发
CarInterface._get_params() 选择 tesla 安全模式和转角控制，并通过指纹识别缺失 DAS_settings、新 3-bit DAS_steeringControlType 固件；Model X 或旧固件条件可标为 dashcamOnly。雷达支持需要特定 Continental 雷达、DBC 与物理接入 bus 1，不能只凭车型名推断。alpha_long 可写纵向安全参数，但固件实际纵向启用受 ALLOW_DEBUG 限制。
CarState.update() 与 update_autopark_state() 从 party 与 autopilot-party 两条总线解析车速、踏板、EPS 手握级别/接管、巡航、Autopark、原车 AEB/LKAS，并保留 DAS_control 副本用于取消报文；状态机只在未巡航的上升沿锁存 Autopark。输出侧，CarController.update() 在 hands_on_level >= 3 时停用横向，每 2 帧按速度和车辆模型限制目标转角并定期发送允许转向报文；纵向启用时发送加速度，否则仅构造符合取消语义的 DAS_control。get_safety_CP() 以 Model Y 参数匹配固件转角限制。
雷达接口读取 40 对 A/B 目标消息，要求索引一致，按状态删除旧目标并报告 CAN、遮挡及传感器故障；无物理雷达/未接线时退回基础接口。tesla_checksum() 实现发送帧校验，但编码器不是发送许可。
| 层 | 关键入口 | 已核对行为 |
|---|---|---|
| 安全 RX | tesla_rx_hook() |
从 EPAS、DI、ESP 采样转角、双车速、油门/制动、巡航与手动接管，识别原车 AEB、LKAS 与 Autopark |
| 安全 TX | tesla_tx_hook() |
Autopark 锁存时拒绝所有候选；转向检查角度/速率/控制类型；原车 LKAS 运行时禁止主机转向 |
| 纵向限制 | tesla_tx_hook() |
禁止主机 AEB 事件；原车 AEB 运行时拒绝纵向/取消帧；非纵向模式只允许无执行量的取消 |
| 原车转发 | tesla_fwd_hook() |
按 Autopark、原车 LKAS、原车 AEB 选择性屏蔽相机/Autopilot 总线的转向与纵向报文 |
| 初始化 | tesla_init() |
构造不同纵向白名单；先假定 Autopark/Summon 激活，直到状态消息澄清 |
需要强调的是，tesla_fwd_hook() 的转发是根据状态选择性屏蔽，不能把「拦截原车控制帧」写成一条恒定规则。tesla_init() 启动先假定 Autopark/Summon 激活，是为降低上电时与原车系统争用而设的保守起点。
Rivian：动态扭矩与原车 ACC 状态取消
CarInterface._get_params() 选择 rivian 模式，以 0x321 消息是否存在区分 Gen2，并配置扭矩控制。本快照设 radarUnavailable=True；Gen2 自控纵向默认不开放，docs 可影响能力字段。即使软件选择纵向，固件白名单也仅在 ALLOW_DEBUG 接受参数。输入侧 CarState.update() 从 PT、相机、ADAS 三路解析车速、踏板、转向、巡航、AEB 和故障；Gen2 缺部分车门/安全带 CAN 信号，源码说明依赖原车 ACC 处理，不能等同软件已观测到这些状态。另外 cruiseState.speed 的注释说明当前是检测到的限速替代值，不是已核对的目标巡航速度。
Rivian 会复制 ACM_lkaHbaCmd、Gen1 触摸方向盘帧，并保留每次 VDM_AdasSts 更新；后者可能一轮收到两帧，所以控制器逐帧重发以保留时序。输出侧，CarController.update() 根据速度插值得到扭矩上限，再按驾驶员扭矩限幅；Gen1 可发送触摸方向盘消息。自控纵向生成加速度帧；原车纵向取消时先发送数帧 available 再发 unavailable 状态，让 ACM 接受切换。
| 层 | 关键入口 | 已核对行为 |
|---|---|---|
| 参数 | _get_params() |
以 0x321 区分 Gen2；本快照设雷达不可用 |
| 编码 | riviancan.py |
create_lka_steering()、create_wheel_touch()、create_longitudinal()、create_adas_status() 复用原车字段并重算校验 |
| 雷达 | RadarInterface.update() |
有目标解析器，但参数层总设不可用，通常走基础接口；只保留 LRR 或 SRR+LRR 模式有效目标 |
| 安全 RX | rivian_rx_hook() |
从 ESP 与 VDM 双车速检查失配；CRC/质量位函数对特定地址独立验证 |
| 安全 TX | rivian_tx_hook() |
转向扭矩设速度相关上限、驾驶员抵消及变化率；纵向加速度另设限值 |
| 模式选择 | rivian_init() |
原车 ACC 与自控纵向使用不同 TX 白名单；纵向选择仅在 ALLOW_DEBUG 编译块读取 |
对硬件与插件化重构的四条约束
- 车型/固件识别是执行前提。Tesla 的 steering-control 字段代际、Rivian Gen1/Gen2、雷达物理接入和发布/调试固件选择必须进入受审计的能力清单；不能把
alphaLongitudinalAvailable直接映射为「允许发送」。 - 原车系统仲裁不能外包给普通插件。Tesla 的 Autopark、原车 LKAS/AEB 转发优先级和 Rivian 的 ACC 状态取消时序应与板级安全门、主机状态机共同验证，在不明状态下不放行控制。
- 传感器数据必须携带来源与有效性。Tesla/Rivian 的双车速、CAN 质量位和雷达模式不是普通数值字段；新硬件要保留总线、时间戳、计数器/校验及故障标志，防止旧值伪装成实时观测。
- 发布固件单独验收。这两个模式本身可在注册表中找到，但纵向参数读取受
ALLOW_DEBUG；不能用调试固件跑通的纵向测试宣称发布版可用。
把两条链路放在一起看，可以发现共性：软件层「能构造帧」与硬件层「允许发送」始终是两件事，而原车辅助系统（Autopark、LKAS、AEB、ACC）的在场状态会随时改变这条边界。跨品牌流程可参考车型协议总览，板级执行可参考 panda 专题。
常见问题
Tesla 与 Rivian 都是电动车，为什么不能共用一套插件？
因为两者控制类型不同：Tesla 采用转角控制并选择性转发原车报文，Rivian 采用动态扭矩并依赖原车 ACC 状态取消。它们的总线拓扑、原车辅助系统与安全策略都不同，源文档明确「不能共用一套电动车插件」，必须按平台分别声明能力。
为什么代码里有纵向控制，实车却不一定能启用？
因为两品牌的纵向参数读取都受 ALLOW_DEBUG 限制：Tesla 的 tesla_longitudinal 仅在 ALLOW_DEBUG 读取安全参数，Rivian 的纵向选择也只在 ALLOW_DEBUG 编译块读取。因此不能用调试固件跑通的纵向测试宣称发布版可用。
Tesla 雷达支持能否只凭车型名判断？
不能。源文档指出雷达支持需要特定 Continental 雷达、DBC 与物理接入 bus 1，不能只凭车型名推断；Rivian 侧参数层在本快照总设 radarUnavailable=True，即使代码有目标解析器，也不会据此宣称实车雷达链已启用。
Rivian 的原车纵向取消为什么要先发 available 再发 unavailable？
源文档说明这是为了让 ACM 接受切换：取消时先发送数帧 available 再发 unavailable 状态。这属于原车系统仲裁时序，应与板级安全门、主机状态机共同验证，而不是当作普通的功能开关。
延伸阅读
- 同一个「转向灯」在三家车厂是三种实现：车辆状态归一化的坑 —— 解释 Tesla 双总线与 Rivian 三路输入为何必须分别建模。
- 车型指纹与固件匹配：识别链上的两道关口 —— 承接两品牌「先识别固件再放行」的执行前提。
- 从使能到车轮：执行链上的八道门，以及它们各自不保证什么 —— 说明编码器通过不等于发送许可。
- Hyundai 控制输出：经典 CAN 与 CAN FD 两条构帧路径与独立安全门 —— 同一「候选帧之后仍由固件复核」的对照案例。
- Ford 与 GM 车型实现：曲率、ASCM 网关与双车速检查 —— 另一个按平台拆分能力与安全门的品牌组。
参考资料
- 项目 02 ——
openpilot-research/TESLA_RIVIAN_DEEP_DIVE.md（取用了 Tesla/Rivian 的参数、输入、输出、安全 RX/TX、转发与初始化行为，以及四条插件化约束）。 - 项目 02 ——
openpilot-research/CAR_PROTOCOL_IMPLEMENTATIONS.md（仅用于确认两品牌目录与跨品牌安全主链路的总体位置）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复