星核火花赛车科技

标签： Tesla

  • Tesla panda 安全模式：Autopark 优先与选择性转发矩阵

    结论：Tesla panda 安全模式的优先级不是「谁能发」而是「谁优先」：启动时先假定 Autopark/Summon 活跃并拒绝所有主机 Tesla 候选帧；原车 LKAS 锁存时把 0x488 从主机 TX 切回原车透传；原车 AEB 活跃时恢复 0x2B9 透传并拒绝主机取消帧。因此「白名单里有某地址」不等于该地址的每个字段都经过逐信号安全校验。

    RX 完整性：9 类监视帧与校验

    tesla_model3_y_rx_checks 含 9 类帧：相机总线 2 的 0x2B9/0x488，主总线 0 的 DI 速度、ESP 第二车速、EPAS 状态、油门、刹车、DI 巡航/Autopark 和 UI 警告。各自配置地址、长度、名义频率及计数上限；仅 ESP 轮速和刹车未忽略质量位。UI 警告进入通用 RX 健康监控，但 tesla_rx_hook() 并无对应的状态提取分支。

    共享 safety_rx_hook() 先验证校验/计数/质量位，再对命中且有效的帧运行车型钩子；坏 RX 帧不可当作有效的原车 AEB/LKAS 状态更新。校验按地址选择校验字节，计算地址两字节与其它载荷字节的 8 位和。

    函数 责任
    tesla_get_counter() 按地址从不同字节/位域取得 3 或 4 位计数器。
    tesla_get_checksum_byte()、tesla_get_checksum()、tesla_compute_checksum() 按地址选择校验字节，计算地址两字节与其它载荷字节的 8 位和。
    tesla_get_quality_flag_valid() 0x155 ESP 轮速质量位必须为 1；0x145 制动状态不能为未初始化或故障编码。
    tesla_rx_hook() 更新角度/接管、DI/ESP 双车速、踏板、巡航、Autopark、原车 AEB/LKAS 锁存。
    tesla_init() 选择默认或调试纵向 TX 表，重置原车辅助状态，并在启动时先假定 Autopark/Summon 活跃。

    原车状态锁存：Autopark、LKAS 与 AEB 的上升沿

    tesla_rx_hook() 的 DI 主车速与 0x155 ESP 第二车速按不同原始编码解码；后者经 speed_mismatch_check() 比较，差超过 2 m/s 时撤销控制许可。0x370 EPAS 角度进入采样窗口；高等级手握或特定高角速度故障置 steering_disengage，由共享接管逻辑消费。两速度帧及 EPAS 帧异步到达，静态代码不保证共时。

    0x286 的 Autopark 活跃编码包括 3、4、9；只有在原车巡航未接合的上升沿才锁存 tesla_autopark，状态退出时清除。随后的原车巡航状态须再与 !tesla_autopark 合取后送 pcm_cruise_check()。0x488 相机报文仅在自身 LKAS 状态上升沿且 controls_allowed=false 时锁存原车 LKAS；状态消失时清除。0x2B9 相机报文的 AEB 活动位则直接更新 tesla_stock_aeb。插件必须保留三种原车状态的来源、有效性和时间信息，不可只发布合并后的「辅助驾驶占用」布尔量。

    TX 与转发优先级矩阵

    条件 主机 TX 相机总线 2 到主总线 0
    初始化后尚未收到解除 Autopark 的 0x286，或锁存的 Autopark 活跃 tesla_tx_hook() 拒绝所有 Tesla 候选帧 车型动态钩子不阻断 0x488/0x27D/0x2B9，允许原车路径继续。
    普通非 Autopark、原车 LKAS 未锁存 0x488 可在角度/控制类型许可下发送 0x488 与 0x27D 被 tesla_fwd_hook() 阻断。
    原车 LKAS 已锁存 0x488 被车型 TX 钩子拒绝 0x488 透传给主总线。
    默认原车纵向 0x2B9 仅允许无执行量的 ACC_CANCEL_GENERIC_SILENT，且不得宣称 AEB 事件 0x2B9 一直透传；原车 AEB 活跃时主机取消帧也被拒绝。
    ALLOW_DEBUG 且纵向参数位置位 0x2B9 可按加速度限值发送，仍禁止主机 AEB 事件 无原车 AEB 时阻断原车 0x2B9；原车 AEB 活跃时恢复透传并拒绝主机 0x2B9。

    tesla_tx_hook() 对 0x488 只接受控制类型 NONE 或 ANGLE_CONTROL，并用车辆模型参数限制 0.1 度转角及横向动力学；原车 LKAS 锁存时即使数值合规仍拒绝。0x2B9 禁止主机设置任何 AEB 事件；默认模式仅可送加速度上下限均为中性 375 的取消编码。调试纵向模式的原始加速度范围为 288–425，中性为 375；两端都低于中性时额外拒绝，以防静止后倒车风险。

    白名单不等于逐信号校验：0x27D 的边界

    tesla_init() 的两个 TX 表都含 0x488、0x2B9、0x27D/总线 0。0x488 与 0x27D 保留 check_relay=true，但设 disable_static_blocking=true，因此共享 safety_fwd_hook() 不会先把它们恒定阻断，留给 Tesla 的动态钩子选择透传。默认模式的 0x2B9 check_relay=false；纵向模式则为 true 但仍关闭静态阻断。

    关键在于 0x27D 没有 Tesla TX 载荷分支：非 Autopark 时，它只经过通用地址/总线/长度、继电器状态和车型总阻断门，不能据此认定各字段经过逐信号安全校验。

    证据与新硬件边界

    test_tesla.py 包含校验/计数、速度失配、制动质量位、驾驶员接管、Autopark、原车 LKAS/AEB 透传、转角和倒车限制用例；其测试库默认加 ALLOW_DEBUG。新增的本机转发矩阵探针在严格编译和 UBSan 下分别运行 release/debug 变体，两者均通过：核对启动 Autopark 阻断、普通/原车 LKAS 转向透传，以及调试纵向和原车 AEB 的 0x2B9 转发切换。但它只设置隔离状态并检查通用 safety 函数，没有覆盖真实 RX 报文时序、目标编译器、板级继电器或 ECU 接受。

    自制硬件与插件化重构应把固件构建类型、Tesla 平台/转向控制字段代际、CAN 来源、车辆模型参数和安全参数版本绑定。感知/控制插件只能提供候选角度或加速度；Autopark、原车 LKAS/AEB 优先权、双车速、质量位与故障降级仍须由独立受信任安全层执行。

    常见问题

    为什么启动时会拒绝所有主机 Tesla 候选帧？

    因为 tesla_init() 在启动时先假定 Autopark/Summon 活跃，在收到解除 Autopark 的 0x286 之前，tesla_tx_hook() 会拒绝所有 Tesla 候选帧；Autopark 锁存活跃时同样如此。

    原车 LKAS 锁存后，0x488 还能由主机发送吗？

    不能。原车 LKAS 已锁存时 0x488 被车型 TX 钩子拒绝，主总线方向则改为把 0x488 透传给主总线。普通非 Autopark 且原车 LKAS 未锁存时，0x488 才可在角度/控制类型许可下发送。

    0x27D 在白名单里是否代表它经过逐信号校验？

    不代表。0x27D 没有 Tesla TX 载荷分支；非 Autopark 时它只经过通用地址/总线/长度、继电器状态和车型总阻断门，不能据此认定各字段经过逐信号安全校验。

    原车 AEB 活跃时 0x2B9 会怎样处理？

    原车 AEB 活跃时恢复 0x2B9 透传并拒绝主机 0x2B9；默认原车纵向模式下，主机侧 0x2B9 仅允许无执行量的 ACC_CANCEL_GENERIC_SILENT，且不得宣称 AEB 事件。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/TESLA_PANDA_SAFETY_MODE_DEEP_DIVE.md（取用了 RX 监视帧、原车状态锁存、TX 与转发优先级矩阵及证据边界）。
    • 项目 02 —— openpilot-research/FORD_PANDA_SAFETY_MODE_DEEP_DIVE.md（仅用于对照品牌安全模式的通用分发结构）。

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

    更新记录

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

  • Tesla 分总线 DBC 档案：同一 CAN ID 的两种报文

    结论：这份档案的对象是随某类商业诊断工具发布的一套 Tesla 平台 DBC，按「一条总线一份 DBC」拆分，另有一份 _shared 文件承载确实跨多总线的报文。它的数据特征不是某个信号的值，而是「同一个 CAN ID 在不同总线上是不同的报文」：例如 0x3D8 在动力总线上可能是 3 字节的 DC-DC 变换器状态，在底盘总线上却是 8 字节的 GPS 位置——一个编号、两条无关报文。正因如此，源文档给出的定位原则是用发送者（transmitter）字段标注报文属于哪条总线。源文档明确这套 DBC 「仅供参考、不受支持」，且其发布方不逆向信号，因此本文只记录结构与少数示例，不构成完整信号地图。

    车辆与适用范围

    源文档是一份 DBC 仓库说明加许可证。它描述的是数据组织方式与使用约定，而非某一台车的采集记录。

    项 内容
    车型 Tesla 各平台（源文档按「每个平台若干份 DBC」组织，未逐一点名具体车型）
    年款 / 市场版本 源文档未确认；并提示 Tesla 可能在不通知的情况下更新信号
    ECU / 改装状态 无改装；表现为可导入诊断工具的 DBC 定义文件
    采集跨度 源文档未提供日志数或帧数（其致谢提及来自社区提供的总线日志）
    适用范围 仅作参考、不受支持；发布方不逆向信号，用户须自行编辑与维护解码信息

    总线与寻址

    源文档的组织原则是「一个总线一个 DBC」，核心动因就是 ID 复用问题。

    项 内容
    物理层 / 比特率 源文档未给出
    寻址方式 源文档未给出；示例 ID 为 11 位量级（0x102、0x399）
    组织方式 按总线拆分：动力、底盘等各一份，另加一份 _shared 承载真正跨总线的报文
    跨总线识别 约定用发送者字段标识报文所在总线；_shared 内报文不带总线标签，在每个通道上都解码
    CAN FD 源文档未提供
    ID 复用示例 0x3D8：动力总线为 3 字节 DC-DC 状态；底盘总线为 8 字节 GPS 位置

    已解码信号

    源文档是 DBC 的说明文档，只举了少量示例。下表登记源文档实际给出的条目（含两个示例信号、一个 ID 复用示例与两类属性约定），并逐条标注出处；源文档没有提供逐信号清单，这一点在表格之后另有说明。

    条目 位置（ID / 属性） 含义 / 解码 证据
    BMS_packCurrent ID 258（0x102） 高压电池电流；被赋显示名「HV Battery Current」 显示名属性示例
    DAS_autopilotState2 ID 921（0x399） 枚举含 DISABLED/UNAVAILABLE/AVAILABLE/ACTIVE_NOMINAL/ACTIVE_RESTRICTED/ACTIVE_NAV/ACTIVE_FSD/ABORTING/ABORTED/FAULT/SNA 取值配色属性示例
    DC-DC 变换器状态 0x3D8（动力总线） 3 字节报文 ID 复用说明
    GPS 位置 0x3D8（底盘总线） 8 字节报文；与上面同编号但无关 ID 复用说明
    显示名属性 属性名（源文档用到具体属性键） 为信号指定在界面上显示的名称 属性说明
    取值配色属性 属性名（源文档用到具体属性键） 为枚举值指定颜色；合法值含 NONE、BLUE、GREEN、INDIGO、ORANGE、PINK、PURPLE、RED、TEAL、YELLOW、WHITE、BLACK、GRAY，也接受 3 字节十六进制色 属性说明
    _shared 报文 _shared 文件 不带总线标签，在每个通道上都解码 组织说明
    发送者字段 报文属性 按约定标明报文所在总线，导入时须开启「按发送者分配总线」 导入说明
    车辆无关定位 项目说明 工具定位为车无关，授权用户自行编辑并维护解码信息 项目说明

    读取方法与注意事项

    导入流程有一条关键约束：源文档说明在某版本的工具中，要把多份 DBC 导入同一个预设，须使用信号列表上的导入功能，因为主菜单的「打开文件」一次只能打开一份。同时有三个开关需要留意——保留不在该 DBC 内的信号/报文（以保住此前手工创建的内容）、按发送者名称尝试分配总线（必须开启）、以及保留计算信号（避免导入时删除默认预设里的计算信号）。这三项决定了导入结果是否与预期一致。

    由于 ID 复用，解析时不能只按编号索引。正确做法是：先确定当前监听的是哪条总线，再用「总线 + ID」的组合去查报文；对 _shared 中的报文才允许跨通道解码。若只有编号没有总线归属，0x3D8 这类报文会被错误地解码成另一条总线的含义。

    数据性质的提醒同样重要：源文档明确发布方不逆向 CAN 信号，并把它描述为一场「猫鼠游戏」——Tesla 可能不通知就更新信号，也不提供总线报文与信号说明。因此这套 DBC 只应作为起点，任何用于关键判断的信号都应在本车日志上复核；改进与修正通过提交合并请求汇集，可能随工具后续版本一起发布。

    证据等级与边界

    本文的证据等级是「项目说明级」：组织原则、ID 复用示例、两类属性与导入约定都能在源文档逐条核对，属直接证据；但源文档没有逐信号清单、没有比特率，也没有实车日志，因此本文只记录结构与少数示例，不提供完整信号地图。这一点与源文档「仅供参考、不受支持」的定位一致。

    两点不能外推。第一，Tesla 各平台之间的报文与信号可能不同，源文档按平台分别组织 DBC，把某一平台的条目外推到另一平台属于超范围。第二，信号可能随 Tesla 的更新而变化，源文档对此已明确提示；任何跨时间、跨软件版本的外推都缺乏依据。此外须注意许可：设备与设计文件采用 CC BY-SA 4.0（署名—相同方式共享），衍生作品需以相同许可发布，商用前应先核对条款。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文只整理 DBC 的组织与示例。

    常见问题

    为什么这些 DBC 要按总线拆成好几份？

    因为 Tesla 可能在不同总线上复用同一个 CAN 编号。源文档举 0x3D8 为例：动力总线上是 3 字节的 DC-DC 状态，底盘总线上是 8 字节的 GPS 位置，两者无关。按总线拆分并用发送者字段标注归属，才能避免解码串线。

    导入多份 DBC 时要注意什么？

    源文档提示：要在同一预设里导入多份 DBC，须用信号列表上的导入功能（主菜单「打开文件」一次只能开一份）；并按需处理三个开关，其中「按发送者名称尝试分配总线」必须开启，否则总线归属会错。

    这套 DBC 能直接用于关键判断吗？

    不建议。源文档明确发布方不逆向信号，把维护描述为「猫鼠游戏」，Tesla 可能不通知就更新信号，且这套 DBC「仅供参考、不受支持」。用于关键判断的信号应在本车日志上复核，也可通过提交修正参与维护。

    许可上有什么限制？

    该数据集采用 CC BY-SA 4.0（署名—相同方式共享），衍生作品需以相同许可发布；商用或打包分发前应先核对条款。原文中出现的第三方贡献者名单与本档案无关，未予引用。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/teslax-dbc/README.md（本项目车型档案主来源：按总线拆分 DBC 的原则、ID 复用示例、两类属性与导入约定）。
    • 项目 01 —— public-can-dbc-datasets/additional/teslax-dbc/LICENSE.md（CC BY-SA 4.0 许可条款）。

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

    更新记录

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

  • Tesla 与 Rivian 不能共用一套插件：转角控制 vs 动态扭矩的两条链路

    结论：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 编译块读取

    对硬件与插件化重构的四条约束

    1. 车型/固件识别是执行前提。Tesla 的 steering-control 字段代际、Rivian Gen1/Gen2、雷达物理接入和发布/调试固件选择必须进入受审计的能力清单；不能把 alphaLongitudinalAvailable 直接映射为「允许发送」。
    2. 原车系统仲裁不能外包给普通插件。Tesla 的 Autopark、原车 LKAS/AEB 转发优先级和 Rivian 的 ACC 状态取消时序应与板级安全门、主机状态机共同验证，在不明状态下不放行控制。
    3. 传感器数据必须携带来源与有效性。Tesla/Rivian 的双车速、CAN 质量位和雷达模式不是普通数值字段；新硬件要保留总线、时间戳、计数器/校验及故障标志，防止旧值伪装成实时观测。
    4. 发布固件单独验收。这两个模式本身可在注册表中找到，但纵向参数读取受 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 状态。这属于原车系统仲裁时序，应与板级安全门、主机状态机共同验证，而不是当作普通的功能开关。

    延伸阅读

    参考资料

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