星核火花赛车科技

标签： CAN总线

  • G55/W463 的 CAN-B 故障隔离：三步 A/B/A 对比定位连接器

    结论：这辆 W463 G-Class 的间歇性故障最终定位在后车门控制模块连接器的进水腐蚀上，但真正有复用价值的是诊断方法：先描述物理层特征，再用受控的 A/B/A 对比隔离分支，最后才去拆连接器。关键判据是容错 CAN-B 失去了两根导线之间的互补关系并反复进入类单线故障模式——普通的帧计数监测能描述症状，却解释不了成因。

    三条总线的速率差异决定了故障表现

    这台 2011 年款 G55 AMG（W463）公开了两条 curated DBC：g55-canc.dbc 对应标称 500 kbit/s 的 CAN-C，g55-canb.dbc 对应标称 83.333 kbit/s 的容错 CAN-B。出现故障的是后者。

    总线 标称速率 类型 故障中的表现
    CAN-C 500 kbit/s 高速 CAN 故障期间继续正常工作
    CAN-B 83.333 kbit/s 容错 CAN 有效帧完全中断

    CAN-B 仍能工作而 CAN-C 不受影响，这一对比本身就是一个强信息：它把故障范围从「整车电气问题」收敛到「车身网络分支」，同时排除了供电与接地这类公共成因。

    容错 CAN 为什么不能按高速 CAN 的思路查

    容错 CAN 收发器允许在单根导线故障时继续通信，代价是它的正常状态依赖两根导线之间的互补关系。这次故障中，这个互补关系丢失了，总线反复进入类单线的失效模式，而不是简单地被钳位到某个电平。理解这一点才能解释为什么故障是间歇的、为什么模块会时好时坏。

    三步 A/B/A 隔离法

    整个排查用了三次受控对比，每次只改变一个变量，并且用相同的无损采集方式记录。核心原则是示波器与 CAN 记录仪被视为同一个实验：模拟测量描述线路状态，数字采集确定有效帧是否真的在丢失。

    步骤 配置 观测结果 推论
    A 基线 完整分支全部接上 记录到持续异常 建立物理层特征基线
    B 断开 断开一个可疑分支，重复同样的无损采集 观测窗口内持续异常消失 异常与该分支相关
    A 复现 重新接回该分支 异常复现 排除巧合，确认因果
    细分 分支保持连接，但在模块连接器处分开 异常再次消失 定位到模块/连接器边界，而非主干

    最后一步是整套方法的关键。断开分支能证明「问题在这一支」，但只有「分支保持连接、仅分开模块连接器」才能把故障定位到模块与连接器的交界处，而不是主干线束。少了这一步，结论会停留在「换这个模块」。

    受控对比必须锁定的变量

    对比要成立，三次采集必须保持一致：探针位置、终端电阻、比特率与采集设置都要相同。任何一项变化都会让「异常消失」失去意义——它可能只是采集条件变了。这也是为什么作者强调示波器与记录仪要当成同一个实验来设计。

    可迁移的故障特征

    在多次重复采集中，反复出现的特征有五条。它们构成了判断「这是物理层间歇故障而非协议层问题」的依据。

    特征 表现 为什么重要
    互补性丢失 不是永久性电平钳位 区分容错 CAN 失效与普通短路
    双低与双高状态 占据事件的相当比例 说明两根线被共同驱动
    共模电压偏移 每根线仍会回到正常静止区 说明不是完全断开
    总线级帧中断 CAN-B 有效帧完全中断，CAN-C 继续工作 把范围收敛到车身网络分支
    复现间隔不规则 安静三五分钟不代表系统干净 否定「短时间观察无异常即通过」

    其中「复现间隔不规则」这一条对实际操作影响最大。间歇性故障最容易被误判为已修复，就是因为观察窗口太短。作者明确指出，安静的三五分钟不能作为系统干净的依据。至于具体阈值，则属于仪器配置范畴，不应当作通用限值照搬。

    证据分级与公开边界

    这份案例研究自带一套四级证据标签，并在文末声明了各自的适用范围。

    等级 定义 本案例中的对应内容
    Measured 在采集或物理测量中直接观测到 一台 W463 上重复的无损采集与物理层观测
    Derived 由实测观测推算得出 分支定位，以及互补性丢失与间歇性容错收发器路径之间的关联
    Borrowed 取自已识别的外部来源 来自已识别维修文档的平台拓扑与连接器引脚描述
    Hypothetical 可检验的解释，非既定事实 —

    案例最后明确列出了不主张的范围：不适用于每一台 W463、每一种 CAN-B 收发器、或每一种间歇性车身网络故障。原始采集、车辆身份、维修记录与当前修复状态都不在公开内容之列；公开的 DBC 仅用于被动分析与台架解码，不是发送报文的指南。平台拓扑参照的是 Model 463 车内 CAN 图 PE00.19-U-2300GC（通过 Operation CHARM 镜像查阅），该维修资料本身未在此重新分发。

    常见问题

    为什么帧计数监测查不出这类故障？

    因为帧计数只能描述症状，不能解释成因。这次故障的本质是容错 CAN-B 物理层丢失了两根导线之间的互补关系并反复进入类单线故障模式，必须测量模拟线路状态才能看到；数字侧的帧计数只会显示「有效帧变少了」。

    断开分支后异常消失，为什么还要再接回去？

    为了排除巧合。只做断开一次，无法区分「异常与该分支相关」和「异常恰好没在这段时间出现」。重新接回后异常复现，因果才成立；再进一步保持分支连接、只在模块连接器处分开，才能把故障定位到模块与连接器边界而非主干线束。

    安静三五分钟没出现异常，能算修好了吗？

    不能。案例中明确记录复现间隔是不规则的，因此安静的三五分钟不构成系统干净的证据。判断是否修复需要更长的观察窗口，或按同样的受控对比重新采集。

    这套方法能用到其他车型上吗？

    方法可迁移，结论不能照搬。案例声明不主张适用于每一台 W463、每一种 CAN-B 收发器或每一种间歇性车身网络故障。可复用的是「先测物理层、再做受控分支对比、最后才拆连接器」这个顺序，以及把示波器与 CAN 记录仪视为同一个实验的做法。

    公开的 DBC 能用来修车吗？

    不能作为发送依据。公开文件明确说明它们仅用于被动分析、记录与台架解码，不是向车辆发送或注入报文的操作指引。文中也提醒，DBC 条目不等于出厂规格，须连同注释与配套案例一起读，并区分实测、推导、借用与未验证的事实。

    延伸阅读

    参考资料

    • 项目 08 —— public-can-dbc-datasets/additional/cipher982-g55-w463/can/case-studies/can-b-fault-isolation.md（故障机理、三步隔离法、故障特征清单与证据分级）
    • 项目 08 —— public-can-dbc-datasets/additional/cipher982-g55-w463/can/README.md（CAN-C 500 kbit/s 与 CAN-B 83.333 kbit/s 容错 CAN 的 DBC 与证据标签定义）
    • 项目 08 —— public-can-dbc-datasets/additional/cipher982-g55-w463/can/PROVENANCE.md（三类证据来源、维修文档参照与解释规则）
    • 项目 08 —— public-can-dbc-datasets/additional/cipher982-g55-w463/README.md（公开工作区的范围声明与内容边界）

    免责声明

    本文转述的是公开仓库中的一份诊断案例，其中的观测结果来自单一车辆，作者明确不主张其适用于所有同平台车辆或所有同类故障。文中提到的物理层阈值属于具体仪器配置，不应作为通用限值。公开的 DBC 仅供被动分析与台架解码，不构成向车辆发送或注入报文的操作指引。实际维修请以专业检测与官方维修资料为准。

    更新记录

    • 2026-10-14 初稿

  • Outlander PHEV 的 CAN 日志：双通道同录与三条总线怎么分工

    结论：这份 Outlander PHEV 日志集的价值不在报文清单，而在「双通道同时录 + 视频打时间戳」这个组合。三个总线分两组录制：主线 C 总线（带诊断口那条）与 EV-CAN 同录，EV-CAN 与 BMU-CAN 同录，因此同一个物理事件能在两条总线上互相对齐。BMU 侧 0x3C2 每 100 ms 报一次电池电流，零点在 0x80000000，是天然的时间基准。

    两条录制配置决定了能回答什么问题

    采集者用的是 GVRET 硬件，日志存成 SavvyCAN 可读的 CSV。通道分配是理解整套日志的钥匙：main-ev 目录里通道 0 是主线 C 总线（即带诊断连接器那条），通道 1 是 EV-CAN；ev-bmu 目录里通道 0 是 EV-CAN，通道 1 是 BMU-CAN。

    目录 通道 0 通道 1 能对齐的事件
    main-ev 主线 C 总线（诊断口所在） EV-CAN 车身动作与驱动系统响应
    ev-bmu EV-CAN BMU-CAN 用电设备动作与电池电流变化

    这个配置带来一个直接好处：EV-CAN 在两组里都出现，因此可以把两组日志通过 EV-CAN 上的共同事件接起来，间接得到「车身动作 → 电池电流」的因果链，而不需要三次同时录制。

    时间戳的来源与精度

    每个日志目录下的说明都给出一串 TS 数值，单位是秒，来自 SavvyCAN 文件时间戳，由人工对照视频读出。作者明确说明这些时间戳「不是 100% 准确」。使用时应当把它当作事件排序依据而非精确时延依据——它能告诉你「压缩机启动发生在按下 AC 之后」，但不能告诉你相差了多少毫秒。

    BMU 侧：0x3C2 是整套日志的锚点

    0x3C2 是这堆日志里最有用的报文，因为它同时满足三个条件：高频、物理量连续、与下游事件强相关。它的前 4 字节是一个大端值，表示电流流向；零点为 0x80000000，大于该值表示电流从电池流出（放电），小于该值表示充电电流。第 5 字节在所有状态下都是 C8，作者推测为状态字节。

    字段 位置 取值含义 备注
    电流值 字节 1–4 大端，零点 0x80000000 大于零点为放电，小于为充电
    状态 字节 5 恒为 C8 含义未确认
    周期 — 100 ms 适合做事件对齐

    作者专门提到该总线上大部分报文已在 SimpBMS 项目的解码文档里有说明，因此 BMU 侧的解读工作主要集中在少数几条上。这也是做车型逆向时的常见省力路径：先找社区已有的解码文档，再补自己的缺口。

    EV 侧：0x388 的逐字节观察

    0x388 被判断为空调压缩机状态报文，是这份日志里逐字节记录最完整的一条。它的价值在于提供了一个「状态机 + 设定值」同帧的范例。

    字节 观察行为 推断
    字节 0 压缩机启动后由 01 变 81，停止后变 82 运行状态位
    字节 1 多为 00，字节 0 由 81 变 82 时变为 02 次级状态位
    字节 2–5 数值干净，疑似设定值 可能是传感器输出或目标值
    字节 6 常见（可能恒为）00 未使用
    字节 7 压缩机关为 02，开为 06 压缩机开关指示

    这条报文的可靠性来自交叉验证：作者记录了 EV 模式开空调时 0x388 的首次非零时刻（TS 247.92380 出现第一条 01 00 00 00 00 00 00 06，TS 251.12 字节 2–3 首次非零），并指出 BMU 通道上 0x3C2 的电流尖峰与视频、与 0x388 的取值变化几乎完全吻合。三条独立证据对齐，才把一个「疑似」变成可用结论。

    负向对照的价值

    日志集里有两个刻意做的对照实验。一个是「enable-ac-no-refrigerant」：在冷媒被抽掉之后开空调，TS 669 之后电池电流没有明显变化，因此判断压缩机根本没启动，空调控制器可能检测到低压而拒绝吸合。另一个是「ac-on-no-refrigerant」，在主线 C 总线上重录了一遍。这类「什么都没发生」的日志在逆向里极有价值——它给出了信号在负条件下的基线。

    类似的还有加热器那两段。作者原本想录 EV 模式下的加热器工作，后来发现这辆车根本没有装电加热器，只有暖风水泵在转。这段日志因此被保留为一个明确的反例：报文可能照发，但末端执行器不存在。

    日志清单与使用场景

    整套日志按录制场景命名，覆盖的模式差异决定了各自适合回答什么问题。EV 目录下有 8 组，主线目录下有 3 组。

    场景 适合用来找什么
    normal-mode-gear-selection 挡位切换对应的报文变化（N/D/R/P 反复切换）
    charge-mode 与 long-charge-mode-novideo 充电模式进入与发动机介入/退出的时序
    driving-ev 低速前进后退、B 挡与 4WD Lock 模式下的驱动报文
    ac-on-ev-mode 压缩机启停与 0x388、0x3C2 电流的对应关系
    enable-ac-no-refrigerant 负向对照：无冷媒时电流与状态报文的基线
    heater-attempt-ev-mode 与 ev-heater-mode-maybe-again 反例：无电加热器时的报文行为
    steering-lock-to-lock 方向盘左右打死过程中的转向角报文
    parking-brake 驻车制动反复拉放的单变量对照

    其中 parking-brake 那组是很好的单变量样本：从 TS 370 到 TS 392，驻车制动每隔约 2 秒拉放一次，连续十次，几乎没有其他干扰动作。要定位一个开关量报文，这种设计比长距离行驶高效得多。

    常见问题

    这两组日志为什么不一次录三条总线？

    因为录制设备只有两个通道，作者改为分两组录制并让 EV-CAN 在两组中都出现，从而用 EV-CAN 上的共同事件把两组日志接起来，间接得到主线 C 总线与 BMU-CAN 之间的对应关系，无需三通道硬件。

    日志里的时间戳能用来算精确时延吗？

    不能。TS 数值是从 SavvyCAN 文件时间戳人工对照视频读出的，作者明确说明不是百分之百准确。它适合确定事件先后顺序与大致间隔，不适合作为毫秒级时延测量的依据。

    0x3C2 的电流值怎么判断是充电还是放电？

    以前 4 字节的大端值与零点 0x80000000 比较：大于零点对应电流从电池流出（放电），小于零点对应充电电流。该报文每 100 ms 发送一次，第 5 字节在所有状态下恒为 C8。

    0x388 能确认是空调压缩机状态吗？

    属于强推断而非定论。作者给出了逐字节观察：字节 0 在压缩机启动后由 01 变 81、停止后变 82，字节 7 在压缩机开时为 06、关时为 02；同时 BMU 侧 0x3C2 的电流尖峰与视频记录、与 0x388 取值变化几乎完全吻合。三条证据对齐，但仍应视为高置信度推断。

    为什么还要录「无冷媒」和「没有电加热器」这种日志？

    因为负向对照能给出信号在条件不满足时的基线。无冷媒时 TS 669 之后电池电流无明显变化，说明压缩机未启动，控制器可能因低压拒绝吸合；加热器那两段则证明这辆车未装电加热器，报文可能照发但末端执行器不存在。这类样本能防止把「报文存在」误读成「功能存在」。

    延伸阅读

    参考资料

    • 项目 05 —— public-can-dbc-datasets/additional/projectgus-outlander-phev-logs/README.md（车辆状态、日志格式 GVRET CSV 与三个目录的分工）
    • 项目 05 —— public-can-dbc-datasets/additional/projectgus-outlander-phev-logs/ev-bmu/README.md（通道分配、0x3C2 电流编码、0x388 逐字节观察与各组日志时间戳）
    • 项目 05 —— public-can-dbc-datasets/additional/projectgus-outlander-phev-logs/main-ev/README.md（主线 C 总线三组日志的场景与时间戳）
    • 项目 05 —— public-can-dbc-datasets/additional/projectgus-outlander-phev-logs/cmu/README.md（CMU EEPROM 的 sigrok 逻辑分析仪采集说明）

    免责声明

    本文所述日志来自一辆 2019 年款 Outlander PHEV 事故车的采集记录，车辆状态与配置的代表性有限。文中报文 ID、字节取值与时间戳均为该公开仓库的观测记录，未经独立复现，其中多处标注为推断而非确认。请勿据此对车辆进行任何发送或控制操作，实际工作请以自有采集与官方资料为准。

    更新记录

    • 2026-10-14 初稿

  • 2025 Corolla TSS 3.0 的 0x160：32 字节控制报文与 E2E 校验

    结论：2025 Corolla Hybrid TSS 3.0 的横向与纵向控制都收敛到同一条报文：摄像头发出的 32 字节 CAN FD 帧 0x160，约 40 Hz。加速度是字节 4–5 的 15 位有符号量（0.001 m/s²/count），转向请求是字节 22–23 的大端有符号量（537.7 counts/degree），E2E 保护为对字节 2–31 做 CRC-16/CCITT 并附加小端数据 ID 0x444A。这一条报文也是 Panda 白名单里的唯一入口。

    三条总线上的报文分工

    移植说明把总线关系写得很清楚：动力总成在 Panda bus 1，被中继的 ADAS 报文对在 bus 0，摄像头在 bus 2。控制指令只在 bus 0 上发出，且只有 32 字节这一种形态被接受。网关发出的 0x1A0 属于另一条路径，该分支从不发送它。

    总线 承载内容 在控制链中的角色
    Panda bus 1 动力总成 被观测，不作为指令出口
    Panda bus 0 中继后的 ADAS 报文对 唯一允许发送 32 字节 0x160 的出口
    摄像头 bus 2 摄像头原始 0x160 E2E 计数器与未知字节的来源

    配套的 DBC 规模是 15 条 CAN/CAN FD 报文、120 条信号条目。需要留意的是，DBC 自带的表头写的是「2023 Toyota Corolla」，并标注位位置是从被动日志推断的，而移植目标是 2025 年款。因此它应被当作候选研究定义，而不是已验证的年款网络地图。

    0x160 的字段布局与 E2E 校验

    E2E 保护是这套控制路径里最容易被低估的部分。它不是简单的校验和，而是 AUTOSAR E2E 风格的「计数器 + CRC」组合：字节 2 是摄像头计数器，字节 0–1 是小端 CRC，CRC 覆盖字节 2–31 并附加小端数据 ID 0x444A。

    字节位置 含义 编码 换算
    0–1 E2E CRC 小端 16 位 CRC-16/CCITT，覆盖字节 2–31 + 数据 ID 0x444A
    2 摄像头计数器 8 位 控制器每收到一个新计数器只发一次
    4–5 加速度请求 15 位有符号 0.001 m/s²/count
    22–23 转向请求 大端有符号 16 位 537.7 counts/degree
    其余字节 摄像头未知字段 — 原样保留，不做猜测

    控制器的行为边界也由这张布局决定：它只改已知的加速度与转向字段，保留摄像头的未知字节，重算计数器与 E2E 校验，并且当某个轴不由 openpilot 控制时，原样中继该轴的字段。这意味着「替换控制」不是构造新报文，而是在原报文上做最小改动。

    为什么 537.7 counts/degree 是关键数字

    转向字段的换算系数决定了限幅的实际含义。Panda 侧的转向限幅写的是每接受一帧最多变化 1,500 counts，换算后对应的角度增量才具备物理意义。脱离换算系数去谈限幅是没有意义的——这也是为什么这类移植必须先把 scale 钉死，再谈安全包络。

    安全边界：三层限幅与单一白名单

    TSS3 的 Panda 模式只有在使用 ALLOW_DEBUG 构建时才存在。它的发送白名单里只有一条指令：bus 0 上的 32 字节 0x160。旧款 8 字节 0x160、0x1A0、老款丰田转向报文以及所有无关地址都被拦在白名单外。

    约束项 Panda 侧包络 控制器侧实现
    加速度 -3.5 .. 2.0 m/s²（实测原厂中继包络） 额外夹到 -1.5 .. 1.5 m/s²
    转向变化率 每接受帧最多 1,500 counts 被拒绝的帧不推进限幅基线
    发送地址 仅 bus 0 的 32 字节 0x160 从不发送 0x1A0
    构建开关 需 ALLOW_DEBUG 生产构建会拒绝该输出

    「被拒绝的帧不推进限幅基线」这一条值得单独注意。如果拒绝帧也推进基线，攻击者或故障状态就能通过连续发送被拒帧把限幅额度消耗掉，进而让下一次合法大动作被吞掉。这里的实现避免了这个问题。

    仍然没有闭环的部分

    项目明确列出了几项未解决项：转向灯信号不在三条被接的总线上，因此无法用已验证信号来暂停转向；脱手警告看起来由扭矩超时强制执行，未找到可抑制的 CAN 位，仍需手扶方向盘；0xDA 报文里的四个字段尚未可靠区分驾驶员扭矩与 EPS 扭矩，因此 steeringPressed 保持为 false 而不猜测；驾驶员物理扭矩信号已知在 0x030 上，但可接受的超控阈值未做动态验证。车辆参数目前沿用 E210 Corolla 的 3,060 lb、2.67 m 轴距、13.9 转向比。

    常见问题

    0x160 的 E2E 校验到底覆盖了哪些字节？

    覆盖字节 2 到字节 31，算法为 CRC-16/CCITT，并附加小端序的数据 ID 0x444A。字节 0–1 存放小端序的 CRC 结果，字节 2 是摄像头计数器，这两部分不参与自身校验。

    为什么必须手动选择车型而不是自动指纹识别？

    因为现有的行驶日志无法唯一关联到 2025 年的 F181 身份。已处理的 rlog 在逻辑 bus 1 上有 147 个地址/DLC 对，加上启动段后并集为 152 对，逻辑 bus 0 上有稳定的 22 条报文 ADAS CAN FD 结构；但这一并集与一份 TSS3 Camry 的普查结果重叠，且行驶日志里 carParams 为 MOCK 而非在路上的 F181 响应。自动匹配存在误判车型身份的风险。

    生产版 Panda 能用这套控制吗？

    不能。TSS3 Panda 模式只在以 ALLOW_DEBUG 构建时编译进固件，生产安全构建不会启用这个实验性白名单，因此会拒绝控制器发出的 0x160 输出。这是有意设置的状态，直到剩余的车辆级策略与验证工作完成。

    这份 DBC 能当作 2025 年款的完整网络地图吗？

    不能。DBC 表头写的是 2023 Toyota Corolla，并注明位位置由被动日志推断；移植目标却是 2025 年款。上游也明确把若干字段身份、比例与整车标定列为未解决项，另有不透明的 BYTE* 信号与已解释信号重叠，严格解析器可能报重叠。它是候选研究定义。

    EPS 应用层的比对结论能推到整车 CAN 信号吗？

    不能。证据只支持转移 EPS 应用代码的结论：2025 与 2023 的高应用区从 0x17E00 起逐字节相同，F181 记录为 8965F1208000 与 8A3111213000，MCU 为 R7F701383。这不等于证明每一条整车 CAN 信号与标定都相同。

    延伸阅读

    参考资料

    • 项目 02 —— public-can-dbc-datasets/additional/spanconstant5-corolla-tss3-2025/docs/COROLLA_2025_TSS3_PORT.md（0x160 字段布局、E2E 算法、失败闭合边界与 CAN 普查数据）
    • 项目 02 —— public-can-dbc-datasets/additional/spanconstant5-corolla-tss3-2025/README.md（状态表、安全边界、已知车辆行为与离线检查命令）
    • 项目 02 —— public-can-dbc-datasets/additional/spanconstant5-corolla-tss3-2025/SOURCE.md（DBC 规模 15 报文 / 120 信号、年款偏差与证据边界）

    免责声明

    本文所述控制路径来自公开仓库的移植说明，属于实验性研究成果，未经过独立实车验证。文中涉及的报文 ID、字节偏移、换算系数与安全限幅仅适用于该仓库描述的目标车辆与固件状态，不同年款、市场与 ECU 版本可能存在差异。任何涉及车辆控制的实现都必须以实际测量与合规的安全验证为准，本文不构成发送报文的操作指引。

    更新记录

    • 2026-10-14 初稿

  • Ranger EV 改装的 CarState 规格：五个真信号与一个 vEgo 陷阱

    结论：把一辆 1986 年 Ranger 的 EV 改装车接进 openpilot，真正能被真实信号填满的 carState 字段只有五个：vEgo、gas、brakePressed、gearShifter、standstill。四轮转速是从 vEgo 复制的假值，全部转向字段为零且必须保持为零，巡航状态留到第三阶段。而在进入纵向控制之前，还有一个前置阻塞项：vEgo 目前只在 3 挡正确。

    两条总线与 openpilot 侧的编号映射

    改装车上有两条独立的 250 kbit/s 总线：can0 挂 Thunderstruck MCU/BMS 与 TSM2500 充电机（ZEVCCS 相关 0x351/0x355/0x356），can1 是 X1 / Hyper9 电机的 CANopen TPDO 总线（0x181/0x182/0x183/0x184）。在移植中它们被重新编号为 Hyper9 = bus 0、MCU = bus 1。

    总线 速率 设备 openpilot bus
    can0 250 kbit/s Thunderstruck MCU/BMS + TSM2500 充电机 1
    can1 250 kbit/s X1 / Hyper9 电机控制器 0

    安装时有一处容易踩的坑：Panda 默认是 500 kbit/s，而这辆车的总线是 250 kbit/s，必须先把 Panda 的总线速率改到 250 k，再确认设备能看到 0x181 与 0x183。

    哪些字段有真实来源，哪些是占位

    规格表按「必须有」的驱动信号逐行列出来源与变换。判断标准是：能否在 ranger-dashboard/dbc/*.dbc 里找到对应的报文与信号。

    carState 字段 来源报文 信号与变换 状态
    vEgo / vEgoRaw HYPER9_STATUS 0x181 VEHICLE_SPEED（km/h，有符号 ×0.1），abs(kmh)/3.6 转 m/s 有，但挡位相关
    gas HYPER9_MOTOR 0x183 THROTTLE_REQUEST（-100..100 %），clip(req,0,100)/100 有
    brakePressed HYPER9_STATUS 0x181 SYSTEM_FLAGS bit5（FLAG_PEDAL_BRAKE） 有
    gearShifter HYPER9_MOTOR 0x183 有符号 MOTOR_RPM：大于 20 为 D，小于 -20 为 R，否则 N；FLAG_PARK_BRAKE 置 P 有
    standstill 派生 vEgoRaw 小于 0.1 有
    wheelSpeeds.fl/fr/rl/rr 无 四轮全部等于 vEgoRaw 伪造，无轮速传感器
    steeringAngleDeg / RateDeg / Torque / Pressed 无 全部为 0.0 或 False 缺传感器与 EPS
    cruiseState.available / enabled 无 暂为 False 第三阶段
    doorOpen / seatbeltUnlatched 无 固定 False 无传感器

    转向全为零在只读阶段是可以接受的：openpilot 会照常构建完整的 carState 并完成指纹匹配，只是无法转向。规格里把转向角传感器列为第 1.5 阶段要补的第一件东西——没有它，后续的横向控制就没有反馈闭环。

    vEgo 的挡位依赖问题

    这是进入纵向控制前必须先修掉的问题。X1 报出的 VEHICLE_SPEED 本身是「电机转速 × 一个固定内部速比」，而这辆车用的是 M5OD-R1 五速手动变速箱，速比每换一挡就变一次，因此单一常数的车速只在一个挡位上正确。2026 年 8 月的实测结果是：3 挡基本正确，4 挡读数约为实际值的一半。只读阶段可以容忍，纵向控制绝对不能——错误的 vEgo 会直接破坏速度控制。

    规格给出的修法不是去反推挡位，而是在变速箱下游测速，两个候选来源是 comma 设备自带的 GPS（无需新增布线，巡航准确但低速迟滞）与 M5OD 输出端的尾轴 VSS（真实车速，低速表现好）。拿到挡位无关的真实车速后，显示与日志用的前进挡位反而可以由「电机转速 / 真实车速」对照已知速比四舍五入得到——openpilot 本身只需要 vEgo 与 D/R/N。

    EV 专属信号为什么不进 carState

    openpilot 的 carState 结构里没有电池包电压、SoC、电机温度这类字段。规格明确把这些信号留在仪表盘与 MQTT 上做带外暴露，移植层不处理。

    信号 来源 展示位置
    BATTERY_SOC 0x181 或 MCU 0x355 仪表盘 SoC 表
    DC_BUS_VOLTAGE / CURRENT、power_kw HYPER9_POWER 0x182 仪表盘功率表
    MOTOR_TEMP、INVERTER_TEMP HYPER9_MOTOR 0x183 仪表盘温度
    电池包 V/I/温度、单体极值 MCU 0x356 等 仪表盘与 Home Assistant
    故障等级与系统标志 0x181 或 MCU 0x35a 仪表盘诊断

    如果后续要让这些信号进入 openpilot 内部（比如在 comma 界面显示 SoC，或用电池包故障来门禁接管），规格建议的做法是在 fork 的 carState 上加几个自定义字段，或者走一条旁路的 cereal 消息，而不是硬塞进标准结构。

    分阶段现实阶梯与安全前提

    这份规格把整件事拆成了三级阶梯，并标出了明确的硬件阻塞点。第一阶段只读是这套脚手架当前所处的状态。

    阶段 目标 状态 阻塞项
    1 只读 openpilot 通过 CAN 看到车辆 本脚手架 无
    2 纵向 通过 Hyper9 扭矩/动能回收控速 未开始 safety_ranger.h、vEgo 挡位无关化
    3 横向 转向 被阻塞 车辆无 EPS，需加装转向执行器

    第二阶段的执行路径已经写明：纵向加速度映射到发给 X1 的 MOTOR_TORQUE 命令 RPDO；制动权先由负扭矩/动能回收承担，且需要先实测动能回收的减速度上限。但在这些生效前，必须有 panda 固件里的 safety_ranger.h 钩子逐报文施加限制。第一阶段跑的是 SILENT 安全模式——记录一切，不发送任何东西。

    常见问题

    为什么四个轮速信号要伪造？

    因为这辆车没有独立轮速传感器，规格只能把四个 wheelSpeeds 全部赋成 vEgoRaw。对只读阶段和纵向控制够用，但横向调校最终需要真实的逐轮转速，属于后续要补的硬件。

    vEgo 在 4 挡读数约为实际值的一半，怎么处理？

    不要在总线里反推挡位，改在变速箱下游测速。两个方案：直接用 comma 设备自带的 GPS（无需新增布线，巡航速度准确，低速迟滞），或在 M5OD 输出端装尾轴 VSS（真实车速，低速表现好）。把 carstate.py 的 vEgo 来源从 VEHICLE_SPEED 换成其中之一。

    没有 EPS 是不是就完全做不了 openpilot？

    不是。openpilot 的两件事是转向和控速，这辆车缺的是转向执行器，因此横向被阻塞，但纵向控制不依赖 EPS，仍可在加装转向执行器之前实现。完全脱手的完整功能才需要 EPS 改装这个独立硬件项目。

    EV 的 SoC 和电池温度为什么不在 carState 里？

    因为 openpilot 的 carState 结构本身不建模电池包电压、SoC 与电机温度字段。这些信号保留在仪表盘与 MQTT 上带外暴露。若确实需要在 openpilot 内部使用，规格建议加自定义字段或走旁路 cereal 消息。

    接上 Panda 后第一件事要改什么？

    改总线速率。Panda 默认 500 kbit/s，而这辆改装车的两条总线都是 250 kbit/s，必须先把 Panda 设为 250 k，再确认设备能看到 0x181 与 0x183，之后才进入版本对齐与指纹匹配步骤。

    延伸阅读

    参考资料

    • 项目 03 —— public-can-dbc-datasets/additional/wstewarttennes-ranger-ev-conversion/openpilot-port/spec/ranger_carstate_spec.md（总线映射、逐字段来源与变换、vEgo 挡位依赖与带外 EV 信号清单）
    • 项目 03 —— public-can-dbc-datasets/additional/wstewarttennes-ranger-ev-conversion/openpilot-port/README.md（三阶段阶梯、文件职责、版本对齐步骤与安装流程）
    • 项目 03 —— public-can-dbc-datasets/additional/wstewarttennes-ranger-ev-conversion/README.md（仓库布局与仪表盘仓库关系）

    免责声明

    本文内容来自公开仓库中的自定义移植规格，描述的对象是一辆特定年份的改装车辆，其总线构成、控制器型号与变速箱配置均不具备通用性。文中数字（报文 ID、缩放系数、挡位相关性）来自该仓库的实测记录，未经独立复现。任何涉及车辆控制的改动都应以实际测量与合规验证为准，本文不构成改装或上路操作指引。

    更新记录

    • 2026-10-14 初稿

  • Mirage CAN 节点地图：59 个地址里只有 2 个已解码

    结论：这份 Mirage CAN 节点地图索引了 59 个节点地址，但只有 2 个达到「部分解码并理解」的成熟度：101 发动机状态与 425 外部进入状态；另外 36 个仅采集了样本，21 个只是看见过。没有任何节点达到「完整理解」级别，而 450/451/453/454 这一组被单独拆出成文，因为它们行为高度相似且很可能来自同一个物理模块。

    先读状态图例，再读节点列表

    这份材料最有价值的不是某个字节的含义，而是它自带的一套成熟度分级。作者用四个色块把每个节点区分开：红色表示只是看见过、不再跟进；黄色表示已采集样本数据；绿色表示部分数据已解码并理解；蓝色表示对该节点的报告方式有像样的理解（接近完整）。

    成熟度 含义 节点数 可直接用于解码吗
    已看见 仅记录地址，无样本 21 否，只作地址清单
    已采集样本 有原始字节样本，未解释 36 否，可作比对基线
    部分解码 部分字段已确认含义 2 是，但需自行复核
    理解较完整 报告方式已基本掌握 0 不适用

    把这张表放在最前面看，能避免一个常见误用：把地址清单当成已解码的信号表。这份材料里真正被作者标注为已理解的，只有两个节点。

    两个成熟度为「部分解码」的节点

    101 是单字节的发动机状态，只在车辆处于非「钥匙关闭」的任何状态时出现，报告很慢（约 1 pps）。425 是外部进入状态，八字节，其中车门与锁止两字节已给出取值表，但作者注明「尚未完整映射」。

    节点 字节 取值 含义
    101 字节 1 01 按下 FAST 按钮时短暂出现
    101 字节 1 04 钥匙通电，发动机未运转
    101 字节 1 44 发动机正在起动
    101 字节 1 84 发动机运转中
    425 字节 2 00 / 01 / 03 车门：全关 / 右前 / 左前
    425 字节 3 01 / 02 锁止：已锁 / 未锁

    这两个节点的共同特点是：取值离散、可用外部动作直接触发验证、且重复出现稳定。这也是判断一个 CAN 节点能否从「样本」升级为「解码」的实用判据。

    另一类可用动作验证的字段：315 的灯组

    315 的第 5 字节随转向灯与灯光状态变化，虽然节点本身仍标为「已采集样本」，但这一字节的取值规律已经被梳理出来：全关为 00，示宽灯为 09，近光灯为 11；转向灯在此基础上叠加，左转为 02（叠加后示宽灯态 0B、近光灯态 13），右转为 04（叠加后 0D、15），并在闪烁中交替。这种「基础值 + 增量」的编码在日系车型里很常见，值得单独记下来。

    45x 这一组为什么单独拆文件

    450、451、453、454 四个地址被作者放到单独的 45x.md 里，理由写得很直白：它们行为与报告方式非常相似，很可能相关，甚至是同一个物理模块。这种判断在逆向工程里很关键——连续地址段上的相似帧往往不是四个独立 ECU，而是一个模块的多路复用输出。

    字节序 取值特征 说明
    字节 1 恒为 FD 四者共同
    字节 2 区分地址的关键字节 450 为 11；451 为 13 与 31；453 为 14；454 为 10
    字节 3 恒为 3F 四者共同
    字节 4–8 恒为 FF 四者共同

    四个地址共用相同的常量字节，只有字节 2 不同，且报告速率一致（约 2 pps）。这强化了「同一模块、不同子标识」的假设。注意 451 的字节 2 有两个取值（13 与 31），意味着它可能承载了状态切换而非单纯的标识。

    从常量字节能推出什么

    字节 3–8 全为 FF 而非常见的 00 填充，这一细节本身有信息量：它排除了「未使用字节清零」的默认实现，说明该模块的报文模板是带填充的。对只做解码的人来说，这能避免把 FF 误读为「满量程」之类的物理量。

    使用边界：这不是 DBC，也没有许可证

    材料的来源说明写明了几条硬边界，必须在引用前确认。它覆盖的是 2013 年款之后的 Mirage，但具体观测年款、市场与 ECU 变体均未说明；它自称是占位性质的项目，未做过独立的采集复核或逐信号验证；仓库未找到许可证文件。

    边界项 说明 对使用者的含义
    格式 节点观察笔记，非 DBC 不能直接被 cantools 等工具加载
    车型精度 2013 年款之后，年款/市场/ECU 未说明 跨年款复用前需自行复核
    验证程度 仅两个节点部分解码，无独立复核 其余节点只能作为采样基线
    权利状态 未发现仓库许可证 仅可作为私有离线研究副本

    因此这份材料合理的用法是：作为地址清单与假设来源，配合自己的采集做交叉验证；而不是作为可直接投产的信号定义。

    常见问题

    这份节点地图能直接当 DBC 用吗？

    不能。它是 CAN ID 观察记录与部分字节级解码笔记，不是 DBC 文件，也不能被 cantools 之类的工具直接加载。要使用需要自行把已确认的字段整理成 DBC 或解析规则。

    59 个节点里有多少是可以放心用的？

    只有 2 个达到「部分解码并理解」的级别，即 101 发动机状态与 425 外部进入状态；另有 36 个只有样本数据、21 个仅记录地址。没有任何节点达到作者定义的「理解较完整」级别。

    450、451、453、454 是四个不同的 ECU 吗？

    很可能不是。作者把它们单独拆成 45x.md，理由是四者行为与报告方式高度相似，可能相关甚至就是同一个物理模块。四者共用相同的常量字节（字节 1 为 FD、字节 3 为 3F、字节 4–8 为 FF），只有字节 2 不同，报告速率同为约 2 pps。

    315 节点的转向灯取值是怎么编码的？

    采用基础值加增量的方式。第 5 字节全关为 00，示宽灯为 09，近光灯为 11；左转在此基础上加 02、右转加 04，且与灯光状态叠加：左转在示宽灯态为 0B、近光灯态为 13，右转对应 0D 与 15，取值在闪烁中交替。

    这份材料能用于其他年款的 Mirage 吗？

    不能默认可以。来源说明指出它覆盖 2013 年款之后的车型，但具体观测年款、市场与 ECU 变体均未说明，且未做过独立采集复核。跨年款复用前必须用自己的采集逐信号验证。

    延伸阅读

    参考资料

    • 项目 04 —— public-can-dbc-datasets/additional/phauxcamus-mitsubishi-mirage-can/Nodes/README.md（59 个节点索引、四档状态图例与逐节点观察数据）
    • 项目 04 —— public-can-dbc-datasets/additional/phauxcamus-mitsubishi-mirage-can/Nodes/45x.md（450/451/453/454 的共性观察与字节 2 取值）
    • 项目 04 —— public-can-dbc-datasets/additional/phauxcamus-mitsubishi-mirage-can/SOURCE.md（快照提交、采集日期、覆盖年款与权利状态）

    免责声明

    本文引用的节点数据来自公开仓库的逆向观察笔记，作者本人未做逐信号验证，仓库也未声明适用的具体年款、市场与 ECU 变体，且未发现许可证文件。文中所有字节取值均为该仓库的观测记录，不代表车辆制造商的官方定义。请勿将其用于安全相关用途，复用前请以自有采集独立验证。

    更新记录

    • 2026-10-14 初稿

  • 凯旋 Speed 400 的广播信号图：0x25A 转速与三种车速

    结论：这份档案针对凯旋 Speed 400 与 Scrambler 400 X（Bajaj 生产 398 cc 单缸、Bosch 电喷），是对诊断接插件被动监听得到的广播信号图。总线是 500 kbit/s、11 位标准 ID，钥匙打开即上线（即使发动机不转），总线负载约 1400 帧/秒、约 32 个不同 ID。最有辨识度的发现是三条：转速在 0x25A 上以 1 转/分分辨率给出；车速存在三个彼此不同的值（ECU 值、仪表值、GPS 真值）；而总里程、进气温度、歧管压力不在广播里，只能 OBD 轮询读到。边界：用未端接的 DIY 抽头主动发送可能把控制器推向 bus-off，因此内容全部来自只监听；且克隆板与年款有别，需逐车复核。

    本文整理自该项目的广播信号图与说明。文档用星级给出置信度，本文原样保留。

    车辆与适用范围

    对象是凯旋 Speed 400 与 Scrambler 400 X 两款摩托。采集方式为对诊断接插件被动嗅探：用 ESP32 的 TWAI 控制器设成只监听模式，配一只 SN65HVD230 收发器（去掉 120 Ω 终端），抽头取 OBD 引脚 6（CAN-H）、14（CAN-L）与 12 V / 地。信号是通过刻意激励（刹车、离合、挡位、转向灯）与一次真实骑行确认的。

    项 内容
    车型 凯旋 Speed 400 与 Scrambler 400 X（Bajaj 生产 398 cc 单缸，Bosch EMS）
    年款 / 市场版本 源文档未确认（未绑定具体年款、ECU 版本或跨车适配）
    ECU / 改装状态 原厂 Bosch EMS；采集为非侵入式被动监听，无改装
    采集跨度 含一次真实骑行与多次刻意激励；文档未给出总时长
    适用范围 广播信号图为部分映射；克隆板与年款有别，需逐车复核

    总线与寻址

    文档给出链路层轮廓：500 kbit/s、11 位标准 ID、钥匙打开即上线，总线负载约 1400 帧/秒、约 32 个不同 ID。它是一张广播面的图，不是整车网络或诊断库。

    项 内容
    物理层 诊断接插件抽头（OBD 引脚 6 CAN-H、14 CAN-L）
    链路层 500 kbit/s，11 位标准 ID
    上线时机 钥匙打开（即使发动机不转）
    总线负载 约 1400 帧/秒，约 32 个不同 ID
    CAN FD 源文档未提及

    已解码信号

    下表从文档信号表抽取代表性条目。bN 为第 N 字节，bN:k 为第 N 字节第 k 位（bit 0 最低），bN:bM 为大端 16 位。星级沿用文档：三星为多会话复现或有物理证据、二星为单次会话强证据、一星为候选。

    信号 位置（ID / 字节） 解码 置信度
    发动机转速（细） 0x25A b5:b6（大端） rpm = raw，1 转/分分辨率，验证到 9271 三星
    发动机转速（粗） 0x140 b6 rpm = raw × 40，与 0x25A 一致（r = 1.00） 三星
    节气门（TPS1 / TPS2） 0x142 b0 / b1 % = (raw − 128) × 100 / 96，双线控传感器，基准 0x80 三星
    接合挡位 0x142 b3 0 为空挡，1 至 6 为挡位；按停留判定为「已接合挡」 三星
    车速（ECU 值） 0x296 b3:b4（大端） km/h = raw × 0.01；GPS 标定得 raw = 1.317 × 真值（r = 0.965） 三星
    车速（轮速） 0x102 b1:b2 / b3:b4（大端） km/h = raw × 0.0625（1/16），接近真实地面速度 三星
    冷却液温度（显示） 0x405 b7 °C = raw − 40；这是显示值，非原始传感器 三星
    环境气温 0x147 b3 °C = raw − 40；随天气在约 12 至 28 摄氏度之间 三星
    燃油液位 0x555 b1 raw 0 至 255（非线性）；低油位灯在 raw 约 90 点亮 三星
    电池电压 0x142 b7 V = raw × 0.1（充电 14.2 V，熄火 12.7 V） 三星
    侧撑 0x142 b6.1 该位为 1 表示放下 三星
    刹车 0x146 b1.0 该位为 1 表示正在刹车 二星
    转向灯 0x536 b2.0 该位为 1 表示激活（左 / 右尚未区分） 三星
    水箱风扇 0x405 b5.5 该位为 1 表示风扇开启 三星
    机油压力灯 0x400 b3.7 低有效（为 1 表示正常） 三星
    ABS 状态 0x121 ID 已确认（原厂故障码 U1000），具体字节尚未定位 一星

    读取方法与注意事项

    只监听，别主动发。文档最重的注意事项是：不要用廉价适配器主动轮询——在这个平台上，从未端接的 DIY 抽头发送可能把 CAN 控制器推向 bus-off 并中断接收。不过文档也澄清：用已正确端接的适配器做 OBD 轮询，实测整趟骑行没有 bus-off，因此该风险特定于「DIY 抽头在发送」，而非「合规适配器的轮询」。

    车速有三个，不要混用。文档用 GPS 对齐（r = 0.965）得到三套关系：ECU 值 0x296 × 0.01 = 1.317 × GPS 真值；骑手看到的仪表值 = raw × 0.89（约比 GPS 高 17%）；真正的地面速度 = raw × 0.76。文档另指出轮速 0x102 × 1/16 约等于 0.87 × raw，与结论自洽。

    挡位是「已接合挡」。文档用停留时间来论证：日常巡航时该值能保持数百帧不变（换挡杆输入会松手回中）；另有一个瞬时换挡信号在 0x406 / 0x407 上。

    温度要分清「显示值」与「真实值」。文档通过诊断对照发现：0x405 b7 是显示值（冷车时被钉在约 90 摄氏度，真实传感器冷态只有 28 摄氏度），真实冷车 / 过热应看 OBD 0105；0x147 b3 是环境气温而非进气温度。

    证据等级与边界

    文档星级即硬边界：三星为多会话复现或有物理证据，二星为单次会话强证据，一星为候选。表中二星与一星条目（如刹车、ABS）尚未达到确认级别。

    来源说明还列出几层限制：精确年款、ECU 版本与跨车适配未建立；仓库未附带原始 CAN 采集，无法独立回放；候选字段与尚未解决的左右转向灯区分不应被视为已确认；该 DBC 只是部分广播映射，不是完整的摩托网络或诊断库。文档也说明它是社区逆向成果，不隶属于凯旋或 Bajaj，并建议依赖任何结论前先在你自己的车上验证。

    据此，全部信号含义、比例与「不广播」的结论都不能外推到其他 Speed 400 / Scrambler 400 X 或其他车型，克隆板与年款差异更需逐车核对。

    常见问题

    Speed 400 的广播里能读到哪些量？

    文档记录的有：转速（0x25A 细、0x140 粗）、节气门、已接合挡位、车速与轮速、冷却液显示温度、环境气温、燃油液位、电池电压，以及侧撑、刹车、转向灯、水箱风扇、机油压力灯等开关量。

    为什么这台车的车速有三个不同的值？

    因为 ECU 值、仪表值与真实地面速度是三回事。GPS 标定得 ECU 值 0x296 × 0.01 约等于 1.317 倍真值，仪表显示约为 raw 的 0.89 倍（比 GPS 高约 17%），真实速度约为 raw 的 0.76 倍。

    为什么强调只监听、不主动轮询？

    文档记录：在这个平台上，从未端接的 DIY 抽头发送可能把 CAN 控制器推向 bus-off、中断接收，因此全部信号都靠只监听获得。但用一只正确端接的适配器做 OBD 轮询，实测整趟骑行也没有 bus-off，所以该风险特定于 DIY 抽头在发送。

    总里程、进气温度、歧管压力为什么读不到？

    因为它们不在广播里。文档逐字节、全字节宽、两种字节序地找过，都没匹配；这些量由 Bosch ECU 内部保留，只能通过诊断通道轮询（如 010B、010F、0105）取得。总里程甚至不在模式 01 中，只由仪表显示。

    转向灯的左右能区分吗？

    目前不能。0x536 的 b2.0 只报「激活」，左右之分需要一个带标注「先左后右」的采集才能确定，文档把它列为尚未解决项。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/tbtanmay111-triumph-speed-400/SIGNALS.md（本项目车型档案主来源，取用了逐信号表与置信度星级）。
    • 项目 01 —— public-can-dbc-datasets/additional/tbtanmay111-triumph-speed-400/README.md（取用了总线、采集方式与 OBD 轮询说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/tbtanmay111-triumph-speed-400/SOURCE.md（取用了「未建立年款 / ECU 版本、无原始采集」等边界说明）。

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

    更新记录

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

  • Honda CL250 诊断档案：5 个 DID 与 UDS 轮询

    结论：这份 Honda CL250（摩托车）档案的一个关键事实是：源文档目前没有已知的 CL250 广播报文——它的 cl250.dbc 是零报文、零信号的骨架。可用的数据来自主动 UDS 轮询 5 个 DID：转速、车速、节气门绝对位置、冷却液温度与电池电压，经 ISO 15765-2 单帧传输，主寻址是 29 位 0x18DA10F1（ECU 地址 0x10、测试仪 0xF1），回退到 11 位 0x7E0/0x7E8。工程约束也被写得很细：单请求在飞、基础超时 100 ms、响应挂起（NRC 0x78）翻倍超时、连续 5 次超时跳过该 DID 5 秒。下述内容仅限源文档记录的这一套定义。

    车辆与适用范围

    源文档来自一个摩托车车载平台项目，它把 CL250 的 ECU 定义与一张项目自建 CAN 分开管理。定义文件说明每个数值都从一份旧固件项目提取，而该旧固件自述「已在真实摩托车上验证过 CAN/UDS 通路」；但来源说明同时指出，那份被引用的仓库在核对时已无法公开访问，没有原始抓包被独立检查过，且部分轮询周期与 11 位回退寻址在源文档里明确标注为未验证。

    项 内容
    车型 Honda CL250（摩托车），ECU 记为 CL250_ECU
    年款 / 市场版本 源文档未给出年款与市场版本
    ECU / 改装状态 原厂 ECU；读取侧是一个测试仪节点（rt-core 或连接节点），只读轮询
    采集跨度 源文档未给出日志数；数值来源为一份旧固件项目的提取
    适用范围 仅限本套定义；被引用的旧固件仓库核对时不可公开访问，原始抓包未独立检查

    总线与寻址

    源文档把总线参数标为「已验证」的是经典 CAN 500 kbit/s；主寻址与回退寻址分开列出，并明确回退寻址「ECU 实际应答哪一个未被记录」。此外还列了两个只监视（watch-only）的功能地址，用于探测是否存在第二个测试仪。

    项 内容
    物理层 双绞线 CAN；经典 CAN（classic_can）
    链路层 / 比特率 500 kbit/s（源文档标 verified）
    主寻址 29 位固定寻址：请求 0x18DA10F1、响应 0x18DAF110；ECU 地址 0x10、测试仪 0xF1
    回退寻址 11 位：请求 0x7E0、响应 0x7E8；标为未验证（未记录 ECU 应答哪个）
    只监视地址 功能地址 0x7DF 与 0x18DB33F1，只看不发
    传输层 ISO 15765-2；帧 DLC=8；补齐字节 0xAA；旧固件只处理单帧

    已解码信号

    下表登记 5 个 DID 的解码，以及关键的服务与会话定义。DID 的公式与「已验证」标记按源文档原样保留；轮询周期一行给出旧固件值与平台建议值，并保留「平台值为暂定」的标注。

    信号 / 项目 位置（DID / 命令） 解码 / 说明 证据 / 置信度
    转速 ENGINE_SPEED DID 0xF40C（OBD PID 0x0C） (A×256 + B) / 4 → rpm，量程 0–16383.75 源文档标 verified；旧固件轮询 50 ms，平台建议 110 ms（暂定）
    车速 VEHICLE_SPEED DID 0xF40D（PID 0x0D） A → km/h，量程 0–255 标 verified；优先级 high；平台建议 110 ms（暂定），新鲜度 300 ms
    节气门绝对位置 THROTTLE_POS DID 0xF411（PID 0x11） A × 100 / 255 → %，量程 0–100 标 verified；平台建议 200 ms（暂定）
    冷却液温度 COOLANT_TEMP DID 0xF405（PID 0x05） A − 40 → °C，量程 −40–215 标 verified；平台建议 800 ms
    电池电压 BATTERY_VOLTAGE DID 0xF442（PID 0x42） (A×256 + B) / 1000 → V，量程 0–65.535 标 verified；旧固件的 A/10 启发式未沿用
    诊断会话 请求 0x10 0x03 → 正响应 0x50 扩展会话；未确认前每 2000 ms 重试 标 verified
    TesterPresent 0x3E 0x80 每 1000 ms 无条件发送（抑制正响应） 标 verified
    允许的服务白名单 0x10/0x3E/0x22/0x19/0x01/0x09 只读与会话类；禁止 0x11/0x14/0x27/0x2E/0x2F/0x31/0x34/0x36/0x37，并禁止 0x10 子功能 0x02 平台策略（D-020）
    功能地址监视 0x7DF、0x18DB33F1 只看不发；看到帧即说明存在第二个测试仪 标未验证（标准值，非取自旧固件）
    项目自建总线转发 dbc/platform.dbc 9 条报文、52 条信号；把轮询到的值再发布出去，不是 OEM Honda 库 来源说明

    读取方法与注意事项

    第一是时序预算。源文档记录：同时只有一个请求在飞（IDLE → WAITING → 完成/超时 → IDLE）；基础超时 100 ms；收到 NRC 0x78（响应挂起）时重置并把超时翻倍、上限 2000 ms，且请求仍留在等待态；其它 NRC 则把请求判为完成。连续 5 次超时的 DID 会被跳过 5000 ms。ECU 只要在最近 3000 ms 内有过正响应或任何 NRC，就视为「在线」。

    第二是优先级。DID 被分成 high / normal 两类，在同时到期的请求里先服务所有 high（本例中车速为 high，因为它喂给上游的航向估计），列表顺序只作同类内的平局判定。源文档强调优先级只改顺序、不改内容，且每个到期 DID 仍须在其新鲜度窗口内被服务。

    第三是 ISO-TP 首帧陷阱。旧固件只处理单帧（PCI 高半字节 0x0）；若收到首帧（PCI 0x1X），其 data[1] 是长度字段的一部分、不是 SID，按 SID 解析会破坏状态。旧固件直接丢弃非单帧帧；由于当前所有 DID 都能放进单帧，这只防未来响应变长。源文档据此写明：完整的 ISO-TP 多帧（首帧 + 流控 + 连续帧）需在新实现里从头做。

    第四是总线恢复。进入总线关闭后按指数退避重试：起始 1000 ms、每次翻倍、上限 30000 ms。

    证据等级与边界

    可视为「文档级已验证」的是 5 个 DID 的公式与主寻址，以及会话/超时/退避这些时序常量——它们都带证据引用。属于明确未验证的是：11 位回退寻址（未记录 ECU 应答哪个）、功能地址监视（标准值，非取自旧固件）、以及平台的轮询周期（源文档标注为暂定，与旧固件周期不同）。

    两处不能外推。第一，公式与 DID 只针对 CL250 这一辆车的 ECU 定义；换到其它 Honda 车型需要重新核对。第二，来源说明指出被引用的旧固件仓库在核对时已无法公开访问，原始抓包未被独立检查，因此「已在该车验证」属于源文档的转述，不是本项目的独立复现。

    关于「安全访问」类问题：源文档把 0x27（SecurityAccess）列为禁止服务，且未提供任何绕过方法，不建议尝试；本文只整理公开文档登记的只读轮询，不涉及写 ECU 或绕过安全机制。

    常见问题

    CL250 的报文能不能直接从总线上监听？

    源文档表示目前没有已知的 CL250 广播报文，cl250.dbc 是零报文、零信号的骨架；可用的数据来自主动 UDS 轮询 5 个 DID。

    轮询哪 5 个值？周期是多少？

    转速（0xF40C）、车速（0xF40D）、节气门绝对位置（0xF411）、冷却液温度（0xF405）、电池电压（0xF442）。旧固件周期为转速 50 ms、其余 800 ms；平台建议值为 110/110/200/800/800 ms，并标注为暂定。

    超时和响应挂起怎么处理？

    基础超时 100 ms；收到 NRC 0x78 时重置并把超时翻倍、上限 2000 ms，请求保持等待；其它 NRC 判为完成；连续 5 次超时的 DID 跳过 5000 ms。

    用 11 位还是 29 位地址？

    主寻址是 29 位 0x18DA10F1（响应 0x18DAF110）；11 位 0x7E0/0x7E8 是回退，源文档标注为未验证——未记录 ECU 实际应答哪一个。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/moto-platform-cl250/docs/legacy-telemetry-notes.md（主来源：UDS 状态机、NRC 表、总线恢复与 ISO-TP 陷阱）。
    • 项目 01 —— public-can-dbc-datasets/additional/moto-platform-cl250/uds/vehicle_cl250.yaml（DID 定义、寻址、会话与轮询时序）。
    • 项目 01 —— public-can-dbc-datasets/additional/moto-platform-cl250/README.md（项目结构、平台总线与 CL250 骨架的区分）。

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

    更新记录

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

  • Honda 车型接口：能力参数、雷达静默与恢复边界

    结论：Honda 车型接口把「能力参数」和「能力兑现」分得很清楚：openpilotLongitudinalControl、ControlsReady 与 tester-present 候选都只是软件侧的请求或标记，不是 ECU 行为的回执。雷达静默依赖 disable_ecu()，而它对通信控制请求传入空预期响应前缀、随后无条件打印「ecu disabled」并返回 True，因此至多证明会话得到匹配应答且后续查询没抛异常，不能证明 ECU 已停止发送。没有闭环证据时应保持 noOutput 或只读。

    关键函数与组件

    基线是本地 source/ 归档提交 c8fb906，只分析 Honda interface.py、通用诊断函数及 card/pandad 交接；不代表任何具体年款的线束、ECU 响应或原车 AEB 行为已验证。

    入口 职责
    CarInterfaceBase.get_params() 从平台规格建立基础 CarParams，再交给 Honda _get_params() 补齐能力与参数。
    CarInterface._get_params() 选择 Bosch/Nidec 安全模式、纵向策略、指纹能力、调校和安全参数。
    get_pid_accel_limits() Bosch 给定静态加速度范围；Nidec 的最大值靠近巡航设定速度时下降。
    init() / deinit() 有雷达 Bosch 自控纵向的 UDS 通信控制请求与恢复请求。
    disable_ecu() 扩展会话重试、通信控制发送及布尔结果；注释明确警告禁用原车 AEB。
    IsoTpParallelQuery.get_data() 按预期响应前缀收集结果；空前缀不会验证通信控制的具体正响应码。

    能力与安全配置

    get_params() 先装载车型平台的质量、轴距、转向比和静态 flags，再调用 Honda _get_params()。Bosch 设置 hondaBosch、radarUnavailable=True；alphaLongitudinalAvailable 对 Bosch CAN FD 为假，openpilotLongitudinalControl 还取决于启动时传入的 alpha_long。它们是软件能力/选择位，不等于雷达实际静默。Bosch CAN FD 且 PT 总线编号至少 4 时，安全配置列表前插 noOutput，但并非所有 CAN FD 都无输出。

    Nidec 选择 hondaNidec，同时设置 openpilotLongitudinalControl=True 和 pcmCruise=True，因此不能用 pcmCruise 单独推断执行权由原车 ACC 完全负责。指纹分支检测特定 CR-V BSM 标志、扩展 HUD、混动标志、自动/CVT/手动变速箱以及备用制动帧；EPS 固件版本含逗号时设 dashcamOnly。若 card 判定控制器不可用、用户关闭开关或 dashcamOnly，它会把整组安全配置替换为 noOutput 并标记 passive。

    能力位/标记 含义与边界
    openpilotLongitudinalControl 取决于启动时 alpha_long，是软件选择位，不等于雷达已静默。
    pcmCruise Nidec 同时置真，不能单独推断执行权归属。
    safetyParam 对备用制动、Nidec SCM 变体、Bosch 自控纵向、radarless 和 CAN FD 按位编码；固件还需依自身编译门与白名单解释这些位。
    ControlsReady card 在初始化门满足时立即写，不验证雷达静默结果。

    特别地，Bosch 自控纵向在固件里受 ALLOW_DEBUG 条件编译约束，Python 参数置位本身不足以证明固件允许该模式。此外，多数车型设置 PID 横向参数，部分车型走通用扭矩调校；三处分支直接改写 CarControllerParams.BOSCH_GAS_LOOKUP_V 类属性，不是写入本次 ret 或控制器实例，且函数内没有恢复默认值——同一进程先构建某一车型参数、再构建另一车型时，后者可能继承前者的查表值。

    禁用、保活与恢复链

    只有 BOSCH、非 BOSCH_RADARLESS 且 openpilotLongitudinalControl 时，CarInterface.init() 才调用 disable_ecu()，目标是固定的诊断目标地址与 PT 总线。它先尝试 UDS 扩展会话并要求匹配应答；随后发通信控制请求，子功能带 suppress-response 位。disable_ecu() 对后一步传入空的预期响应前缀并调用 get_data(0)，然后无条件打印「ecu disabled」并返回 True。所以它至多证明前一步会话得到匹配应答且后一步查询没有抛出异常，不能证明 ECU 已停止发送；Honda init() 又没有返回该布尔值。

    card 首次满足初始化门时调用 CI.init()，紧接着写 ControlsReady=True，没有验证雷达静默结果。pandad 在 FirmwareQueryDone 和 ControlsReady 都为真后读取参数、设置安全模式；这两项参数并非 ECU 行为回执。保持发送候选、MCU 接受、ECU 收到以及 ECU 持续静默是四个不同事实。

    CarInterface.deinit() 用通信控制「启用 RX/TX」请求复用 init() 路径，仍不检查恢复应答。当前主 card 运行链只见 init() 调用，未见对 Honda deinit() 的调用；进程退出或异常时不能由这个函数的存在推断原车雷达/AEB 已恢复。恢复行为是否由 ECU 会话超时、断电或其他机制完成，必须在目标车型台架和受控场地验证。

    插件与硬件验收

    将「雷达静默」设计成受信任诊断服务持有的事务能力：记录目标 ECU、物理总线、请求、正/负响应、发送持续性、实际雷达报文消失与恢复证据，并把原车 AEB/FCW 影响作为显式安全决策。没有闭环证据时保持 noOutput 或只读，不能让车型插件以 openpilotLongitudinalControl、ControlsReady 或 tester-present 候选代替验收。多车型参数生成必须隔离/冻结 BOSCH_GAS_LOOKUP_V 等调校状态；至少测试 Civic Bosch、Odyssey MMR、RDX MMR 与普通 Bosch 的不同构建顺序。

    常见问题

    disable_ecu() 返回 True 就代表雷达被禁用了吗？

    不代表。disable_ecu() 对通信控制请求传入空的预期响应前缀并调用 get_data(0)，然后无条件打印「ecu disabled」并返回 True。源码说明它至多证明前一步扩展会话得到匹配应答且后一步查询没有抛出异常，不能证明 ECU 已停止发送；Honda init() 也没有返回该布尔值。

    pcmCruise 为真表示减速完全由原车负责吗？

    不能这样推断。Nidec 选择 hondaNidec 时同时设置 openpilotLongitudinalControl=True 和 pcmCruise=True，源码因此明确指出不能用 pcmCruise 单独推断执行权由原车 ACC 完全负责。

    BOSCH_GAS_LOOKUP_V 为什么会有跨车型风险？

    因为部分调校分支直接改写 CarControllerParams.BOSCH_GAS_LOOKUP_V 类属性，不是写入本次 ret 或控制器实例，且函数内没有恢复默认值。源码可推断：同一 Python 进程先构建某一车型参数、再构建另一车型时，后者可能继承前者的查表值。这需用 Civic Bosch、Odyssey MMR、RDX MMR 等不同构建顺序验证。

    进程退出后原车雷达/AEB 会自动恢复吗？

    不能由源码推断。deinit() 用通信控制「启用 RX/TX」请求复用 init() 路径、仍不检查恢复应答，而当前主 card 运行链只见 init() 调用、未见 Honda deinit() 调用。恢复行为是否由 ECU 会话超时、断电或其他机制完成，必须在目标车型台架和受控场地验证。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/HONDA_INTERFACE_CAPABILITY_RADAR_LIFECYCLE_DEEP_DIVE.md（取用了 Honda 接口函数表、能力与安全配置、禁用/保活/恢复链、插件与硬件验收要求）。
    • 项目 02 —— openpilot-research/HONDA_CARSTATE_SPEED_BRAKE_CRUISE_INPUT_DEEP_DIVE.md（仅用于确认 Honda 输入状态专题的接续关系，未取用其未公开内容）。

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

    更新记录

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

  • Volvo P1 双 CAN 档案：HS 500 kbit/s 与 LS 125 kbit/s

    结论：Volvo P1 平台（V50 / S40 / C30 / C70）不是一张 CAN，而是两张经 CEM 网关相连的网络：高速网（HS）跑 500 kbit/s，承载发动机、助力转向、制动/ABS、方向盘传感器与踏板；低速网（LS）跑 125 kbit/s，承载收音机、车门模块、仪表（DIM）、空调（CCM）与 CEM。所有 ID 都是29 位扩展帧。更关键的一条边界是：较早年款需要先通过 K 线激活诊断继电器，CAN 才会出现在 OBD2 接口上。源文档的 HS 表来自 18 份实车日志（约 94.8 万帧）、LS 表来自另一台 C30，两者都不是全平台验证。下述结论仅限源文档记录的这些车辆与年款。

    车辆与适用范围

    源文档是一份公开研究整理的 CAN 参考表（原文为捷克语），同时给出拓扑、ID 表、若干字节拆分与一个「助力转向泵完整配方」。它自述 HS 表来自某个 V50 项目的 18 份抓包，LS 表来自一台 C30 T5 2011 加另一套 CCM/CEM 仿真。

    项 内容
    车型 Volvo P1 平台：V50 / S40 / C30 / C70
    年款 / 市场版本 HS 表来自一台柴油 V50（未给年款）；LS 表来自一台 C30 T5 2011；汽油版与其他年款未独立确认
    ECU / 改装状态 原厂网络；HS 侧含 ECM、助力转向（PSP）、制动/ABS、方向盘传感器、踏板；LS 侧含收音机、车门模块、DIM、CCM、CEM
    采集跨度 HS：18 份抓包、约 948,000 帧（一台车）；LS：一份 C30 2011 的接收列表 + CEM/CCM 仿真观察
    适用范围 仅限源文档记录的这两台车与其年款；HS DBC 自述「建立在一台具体 V50 的日志上」

    总线与寻址

    源文档把拓扑画得很清楚：两张网经 CEM 网关相连。HS 与 LS 的速率不同，且都是 29 位扩展 ID；生成的 DBC 需要设扩展标志（0x80000000），否则多数工具会当成标准帧。HS 表还给出一条很有用的启发式——每字节的「变化度」列（X 表示变化大、点表示变化小、横线表示恒定），用来判断哪里值得找信号。

    项 内容
    物理层 双绞线 CAN，两张网经 CEM 网关互连
    链路层 / 比特率 HS 500 kbit/s；LS 125 kbit/s
    寻址方式 29 位扩展 ID（DBC 需带 0x80000000 标志）
    CAN FD 否；按经典 CAN 处理
    OBD 可达性 较早年款需先经 K 线激活诊断继电器，CAN 才在 OBD2 接口可用

    已解码信号

    下表抽取 HS 与 LS 的代表性条目，并附一段诊断读数。源文档大量字段标注为「未解码」「仅推测」，这些标注按原样保留；LS 侧尤其如此。

    信号 / 功能 位置（ID / 字节 / 位） 解码 / 说明 证据
    发动机转速 HS 0x00800006 ECM_EngineData，B7 原始值 110 = 0 rpm（原始值口径，未给完整换算） 18 份实车日志
    仪表背光亮度 HS 0x0100082C Dashboard，B0 低半字节 调整亮度 实车日志
    光敏（环境光） HS 0x0100082C，B1 位 7 位 实车日志
    油门/离合器踏板传感器 HS 0x0110483C PedalSensors 源文档未细分到具体位 实车日志
    助力转向速度指令 HS 0x02104136 PSP_SpeedCmd，B6-B7 0x0001 = 满转速；值越大越慢，范围 1–6000 助力转向协议（第三方）
    制动 / 油门 HS 0x0300410E BrakeThrottle 源文档未细分到具体位 实车日志
    方向盘传感器 HS 0x0340412E SteeringWheelSensors 转角 / 角速度（未细分到具体位） 实车日志
    方向盘按键 HS 0x19000026，B7 按键码（已知 0x20） 实车日志
    点火状态 HS 0x19E00006 Ignition，B6 位 6 位 实车日志
    助力转向 keep-alive HS 0x1AE0092C，B1 轮转序列 0x00 → 0x40 → 0x80 → 0xC0；样例帧 00 00 22 E0 41 90 00 00 第三方协议 + 实车日志（周期 2000 ms vs 日志约 420 ms）
    助力转向状态 HS 0x1B200002，12 位 ((B6 & 0x0F) << 8) | B7 1105 初值 / 3953 怠速 / 3955 运转，三值均在实车日志出现 实车日志
    仪表控制（关键） LS 0x09C050B8 GaugeCluster_Ctrl B0 上 nibble 0x40、下 nibble = 背光亮度 0–15；B1 里程增量；B3/B4 转速 16 位；B5 低 nibble 显示消息码 CEM/CCM 仿真字节拆分
    中控按键 LS 0x05704000 B4 位 0-1/2-3/6-7 = EXIT/MENU/POWER；B5 位 6-7 = ENTER；B7 = UP/DOWN/LEFT/RIGHT 仿真字节拆分
    空调设置 LS 0x12404002 B0 右侧温度、B1 左侧温度、B4 常量 0x43 仿真字节拆分
    油量 LS 0x1AD10068 B0 = 油位；B1 = 0x04 仪表运行 / 0x07 熄火 仿真字节拆分

    另有一段诊断读数：源文档描述的一种厂方诊断风格协议，首个字节是长度、第二个是 ECU 地址，形如 [0xC8+字节数][ECU 地址][命令][参数…]；ECM 地址为 0x7A，读数据用 0xA6。已记录的缩放入下：

    标识 含义 缩放
    0x101D 转速 × 40 rpm
    0x1140 车速 × 1.25 km/h
    0x9D 增压压力 × 10 hPa
    0xD8 / 0xCE 冷却液 / 进气温度 × 0.75 − 48 → °C
    0x36 点火提前角 × 191.25 / 255

    读取方法与注意事项

    第一是可达性：源文档说较早年款要先经 K 线激活诊断继电器，CAN 才会出现在 OBD2 接口上；否则在标准诊断口上可能什么都看不到，且这容易被误判为「车不支持」。

    第二是寻址位数：所有 ID 都是 29 位扩展帧。源文档提醒，生成 DBC 时必须设扩展标志 0x80000000，否则多数工具会把 ID 当成标准帧，导致匹配失败。

    第三是「哪些字节值得看」。HS 表为每个 ID 都标了 B0–B7 的变化度（X / 点 / 横线），这是最快的筛选手段——恒定字节不用找信号，变化大的字节优先。未解码报文在 DBC 里只对「日志中确实变化」的字节生成占位信号（<名称>_B0 … _B7），可直接在抓包工具里画图找相关性。

    第四是助力转向泵需要「两条报文同时在线」：keep-alive（0x1AE0092C，只看 B1 的轮转）与速度指令（0x02104136，B6-B7）。源文档记录：没有 CAN 时泵按固定约 75% 功率运行；丢失 keep-alive 后约 5 秒进入失效保护，但保持最后下发的转速。这里只做整理，不建议照此在实车上驱动执行器。

    证据等级与边界

    可视为实车证据的是 HS 表（18 份抓包、约 94.8 万帧）与三条助力转向状态的取值；属于仿真/文档级的是 LS 侧的字节拆分（来自 CCM/CEM 仿真）与部分周期；属于明确未解码的是 HS 与 LS 表里大量标注为「未解码」的 ID。

    不能外推的地方有三处。第一，HS DBC 明确自述「建立在一台具体柴油 V50 的日志上」，汽油版与其他年款可能有 ID 的子集或超集。第二，LS 表来自一台 C30 2011 加仿真，并非 P1 全系；例如遥控电池 ID 在日志里是 0x1E30104A，而 CEM 仿真用 0x1E30106A，源文档自述「其一为笔误，或按年款不同」。第三，源文档保留了「未解码/仅推测」的字段，这些不能当作已确认信号。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试。它列出的厂方诊断风格命令里包含激活类服务，本文不展开，也不建议在实车上执行写入或激活操作。

    常见问题

    为什么在 OBD2 口上抓不到 Volvo P1 的 CAN？

    源文档说明较早年款需要先通过 K 线激活诊断继电器，CAN 才会出现在 OBD2 接口上；否则标准诊断口上可能没有流量。

    HS 和 LS 是一张网吗？

    不是。P1 有两张网经 CEM 网关相连：HS 500 kbit/s（发动机、助力转向、制动、方向盘传感器、踏板）与 LS 125 kbit/s（收音机、车门模块、DIM、CCM、CEM）。

    这些 ID 是 11 位还是 29 位？

    全部是 29 位扩展 ID。源文档提醒生成 DBC 时要设扩展标志 0x80000000，否则会被当成标准帧而匹配失败。

    助力转向泵为什么需要两条报文？

    源文档记录它需要 keep-alive（0x1AE0092C，看 B1 的轮转）与速度指令（0x02104136，B6-B7 的 0x0001 表示满转速）同时在线上；缺 keep-alive 约 5 秒后进入失效保护。本文只整理协议，不建议照此驱动执行器。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/chuck3cz-volvo-p1/UPSTREAM_README.md（主来源：拓扑、HS/LS ID 表、字节拆分与助力转向协议）。
    • 项目 01 —— public-can-dbc-datasets/additional/chuck3cz-volvo-p1/VOLVO_P1_CAN_REFERENCE.md（同内容的参考表）。
    • 项目 01 —— public-can-dbc-datasets/additional/chuck3cz-volvo-p1/SOURCE.md（快照范围、DBC 报文/信号条数与证据边界）。

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

    更新记录

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

  • 宝马 E9X 集成模块：K-CAN、PT-CAN 与 D-CAN 的消息翻译

    结论：这份档案来自一台 2008 年 E92 335i 上自制的 CAN 集成模块，它同时接入了 K-CAN、PT-CAN 与 D-CAN 三条总线。文档给出的速率是 K-CAN 100 kbit/s、模拟的 KCAN2 500 kbit/s；PT-CAN 与 D-CAN 的速率文档未标注。模块的核心工作是把老一代 BN2000 的消息翻译成新主机（NBT）能认的 BN2010 格式，并把一部分消息改走 K-CAN 以绕开网关延迟。边界有三条：代码与消息逻辑是「为这一辆 2008 E92 335i 定制的」；随附的两份 DBC 是该项目参考素材、不是经过验证的整网定义；文档还涉及对 DME 固件的定义修改，本文不复述其地址与字节，也不建议照做。

    本文整理自该项目的 README 与一份 BN2000 至 NBT 的消息翻译清单。文档本身多次强调其车型特定性，本文原样保留这层限定。

    车辆与适用范围

    项目对象是一辆 2008 年 E92 335i。文档在开头就写明：「代码对我这台车相当特定，但很多 CAN 消息逻辑可能有用。」硬件为一块 Teensy 4.0 三路 CAN 板（两路 CAN 2.0B、一路 CAN FD）配额外的一块 CAN 控制器用于主机模拟。

    项 内容
    车型 宝马 E92 335i（E9X 一代）
    年款 / 市场版本 2008（源文档未给出市场版本）
    ECU / 改装状态 自制集成模块，接入 K-CAN / PT-CAN / D-CAN；集成 F 系列主机（NBT / iDrive）
    采集跨度 源文档未给出；以功能清单与消息翻译清单形式记录
    适用范围 仅这一辆车；随附 DBC 为参考素材，非整网定义

    总线与寻址

    模块同时处理三条总线。文档明确的两处速率是：把 CAN 适配器速度设为 100000 对应 K-CAN、设为 500000 对应模拟的 KCAN2。PT-CAN 承载发动机扭矩等数据，D-CAN 用于诊断访问。文档说明消息发送被优化为走最短路径：需要送到仪表（KOMBI）的消息即使原厂走 PT-CAN，也会改发到 K-CAN，以绕开网关延迟。

    项 内容
    K-CAN 100 kbit/s（文档明确）
    KCAN2（模拟） 500 kbit/s（文档明确）
    PT-CAN 存在（承载发动机扭矩等）；速率源文档未给出
    D-CAN 存在（诊断访问）；速率源文档未给出
    寻址 消息以 11 位标准 ID 列出；CAN FD 能力由硬件支持

    已解码信号

    下表取自「BN2000 到 NBT」的消息翻译清单：左列为发往主机（NBT）的帧，右列为它的来源或处理方式。这些条目是该模块主动构造或翻译的消息映射，而不是某台车出厂网络的完整定义。

    帧 / 信号 ID 来源或处理 证据
    车辆状态 0x3C 由 BN2000 0x130 翻译 项目翻译清单
    终端状态 0x12F 由 BN2000 0x130 翻译 项目翻译清单
    道路倾角 0x163 经 0x6F1 取自报警器（SINE） 项目翻译清单
    俯仰角 X_VIEW 0x180 经 0x6F1 取自报警器（SINE） 项目翻译清单
    偏航率（陀螺） 0x19F 由 BN2000 0x1A0 翻译；NBT 硬件 10 及以上需要 项目翻译清单
    车速 0x1A1 由 BN2000 0x1A0 翻译 项目翻译清单
    距离 0x1C4、0x1C5 由 BN2000 0x1A6 翻译 项目翻译清单
    运动显示数据 0x253 运动显示相关 项目翻译清单
    亮度 0x2A5 由 BN2000 0x314 翻译 项目翻译清单
    PDC 状态 0x2C1 由 BN2000 0x3AF 翻译 项目翻译清单
    静止状态 0x2ED 由 BN2000 0x1A0 翻译 项目翻译清单
    转向角 / 有效转向角 0x301、0x302 由 BN2000 0xC8 翻译 项目翻译清单
    驱动模式开关 0x3A7 由 mdrive_status 与 dsc_program_status 适配 项目翻译清单
    MDrive 状态 0x42E 由 BN2000 0x399 翻译 项目翻译清单
    iDrive 音量 / 网关 0x6F1 承载 iDrive 音量与 SVT_70 网关等；检测到 OBD 工具在 D-CAN 通信时该组功能被关闭 项目 README

    读取方法与注意事项

    最短路径发送与队列。文档说明消息发送被优化为走最短路径以尽快到达接收模块，并用 FIFO 队列保证读写不被延迟阻塞。

    诊断访问下的自保。凡用到 0x6F1 的功能（如 iDrive 音量、SVT_70 网关），在检测到某个外部诊断工具于 D-CAN 上通信时会被停用。

    硬件与启动。文档列出的硬件包括 Teensy 4.0、MCP2562 收发器与用于主机模拟的 MCP2515 板；并提示为让部分启动时序敏感功能工作需修改 Teensy 启动代码。USB 类型随用途变化（单口常规、双口状态、三口 CAN USB 接口）。

    关于固件修改。文档提到对发动机 ECU 固件中与 CAN 消息表、CAN 过滤器相关的定义做过修改，并需要重算校验；还提到停用一部分原厂驾驶模式相关逻辑。这类操作属于对发动机 ECU 的固件改动，风险高且与本文主旨无关，本文不复述其地址、字节或步骤，也不建议照做。源文档未提供任何安全访问绕过方法。

    证据等级与边界

    来源说明把两份 DBC 的性质写得很清楚：EXX-BN2000.dbc（131 条消息、552 条信号行）与 FXX-BN2010.dbc（70 条消息、248 条信号行）是该项目的参考素材，不是针对每一款宝马 E / F 车型或年份验证过的整网定义；其中 EXX-BN2000.dbc 还在独立信号块里重复出现 TPCI、TA 等信号名，严格解析器可能拒绝；其他消息布局与 NBT 翻译未在本归档内对照实车核对。

    第二层边界来自项目自述：代码与 CAN 消息逻辑是为这一辆 2008 E92 335i 定制的，很多功能依赖具体选装件。因此文中列出的翻译关系与行为，只能视为「这台车 + 这套模块」的实现记录。

    据此，任何帧含义、来源映射或发送策略都不能外推到其他 E9X 或其他宝马车型；需要真值时应以本车抓包与独立复核为准。

    常见问题

    E9X 上有哪几条 CAN 总线？

    文档涉及三条：K-CAN、PT-CAN 与 D-CAN。其中明确给出速率的是 K-CAN（100 kbit/s）与模拟的 KCAN2（500 kbit/s）；PT-CAN 与 D-CAN 的存在可以确认，但速率源文档未标注。

    为什么要把消息改发到 K-CAN 上？

    为了走最短路径。文档说明：需要送达仪表（KOMBI）的消息，即使原厂会经 PT-CAN，也被改发到 K-CAN，以绕开网关（JBE）带来的延迟。

    随附的 DBC 能当整网定义用吗？

    不能。来源说明写明两份 DBC 是该项目的参考素材，不是针对每一款车型或年份验证过的整网定义；EXX-BN2000.dbc 还存在重复信号名，严格解析器可能拒绝。未在本归档内做实测核对。

    0x6F1 相关的功能什么时候会失效？

    文档记录：当检测到某个外部诊断工具在 D-CAN 上通信时，凡用到 0x6F1 的功能（如 iDrive 音量、SVT_70 网关）会被停用，以避免冲突。

    本文会给出 DME 固件修改的步骤吗？

    不会。文档确实提到对发动机 ECU 固件里 CAN 消息表与过滤器的定义做过修改并需重算校验，但这类操作风险高，本文只作事实提及，不复述地址、字节或步骤，也不建议照做；源文档未提供任何安全访问绕过方法。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/superwofy-bmw-e9x-can/README.md（本项目车型档案主来源，取用了总线、硬件与功能清单）。
    • 项目 01 —— public-can-dbc-datasets/additional/superwofy-bmw-e9x-can/Message translation for NBT.txt（取用了 BN2000 至 NBT 的消息翻译清单）。
    • 项目 01 —— public-can-dbc-datasets/additional/superwofy-bmw-e9x-can/SOURCE.md（取用了两份 DBC 的规模与「非整网定义」边界）。

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

    更新记录

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