结论：这份档案的对象不是整车，而是一台 Bosch iBooster Gen1 制动助力器的 CAN 输出（Tesla 件号 1037123-00-B，清单标注适配 2016–2020 Model S），被装在 1987 年款的一台改装车上只读采集。它的数据特征是两条 500 kbps 总线、全部只读、状态藏在位置报文里：25/16 引脚的「Vehicle CAN」承载 16 位踏板行程 0x39D，18/10 引脚的「YAW CAN」承载 12 位位置 0x38E 与状态字节 0x38F；助力器只要接通 12V、地、点火即自行助力，不需要任何 CAN 输入。所有数值均为该实物单元的台架实测，不外推到其他 iBooster 变体、其他件号或其他车辆。
车辆与适用范围
源文档明确：这里的每一项都在本台实物上测得，不是从社区资料继承的；未验证的内容另列在待验证清单里。以下范围仅对应这一台助力器。
| 项 | 内容 |
|---|---|
| 车型 | Bosch iBooster Gen1，Tesla 件号 1037123-00-B（清单标注适配 2016–2020 Model S）；采集对象是助力器本身，非整车 |
| 年款 / 市场版本 | 件号适配范围由源文档以清单形式标注；具体车辆年款未确认 |
| ECU / 改装状态 | 改装车（1987 年款）上的助力器，只读旁听，永不向助力器发送 |
| 采集跨度 | 多份台架日志：0x38E 46,960 帧 + 0x38F 23,478 帧（合计 70,438 帧，跨四次上电）；0x39D 校验在 2,250 帧上 100% 通过 |
| 适用范围 | 仅本台实物；触点、装配与固件版本变化都可能改变结论 |
总线与寻址
两条独立总线均为 500 kbps、经典 CAN、11 位标识符，助力器对两条总线都不做内部终端。源文档特别强调：总线要靠内容识别，不能靠适配器索引或 USB 顺序。
| 项 | 内容 |
|---|---|
| 物理层 / 比特率 | 两条总线均 500 kbps；无内部终端 |
| 「Vehicle CAN」 | 引脚 25 = CAN-H，16 = CAN-L，静止 36 fps，静止 4 个 ID、踏板活动时 11 个 |
| 「YAW CAN」 | 引脚 18 = CAN-H，10 = CAN-L，静止约 149.5 fps，2 个 ID |
| 寻址 / 帧格式 | 经典 CAN，11 位标识符；0x39D 为 DLC 4，其余多见 DLC 8 |
| CAN FD | 源文档未使用 |
| 供电引脚 | 引脚 1 = 12V，引脚 9 = GND，引脚 20 = 点火 |
已解码信号
下表抽取源文档中最有代表性的条目，位置与解码保留原文写法（含位运算）。证据一列保留源文档的实测口径：有精确帧数、运行次数与相关系数，也有明确标注为「未解析」「受污染不可引用」的项。
| 信号 | 位置（ID / 字节） | 解码 | 证据 |
|---|---|---|---|
| 踏板行程 | 0x39D b2:b3，DLC 4，25.0 Hz |
uint16 小端；静止约 262，最大观测 14070；端位 13606 = 43.4 mm | 双点标定；mm=(counts-3.3)/320.68（合并拟合） |
| 行程校验 | 0x39D b0 |
(b1+b2+b3+0xA0) & 0xFF |
2,250 帧 100% 通过 |
| 存活计数 | 0x39D b1 |
每帧 +1 取模 16，高半字节恒 0 | 实测 |
| 位置（12 位） | 0x38E b3 与 b4 低半字节 |
position = b3 | ((b4 & 0x0F) << 8)；静止 320，满行程约 3052 |
与 0x39D 两次运行 r=0.999627 / 0.999853 |
| 位置换算 mm | 0x38E |
mm = 0.015207 * position - 4.072（静止 320 → 0.79；满 3052 → 42.34） |
偏置为负，为已验证的两种形式之一 |
| 状态枚举 | 0x38E b4 高半字节 |
0=初始化、1=正常、2=故障闭锁 |
断开行程传感器诱导故障确认 |
| 制动标志 | 0x38E b6 |
1 位制动应用标志；上沿 2.18–2.42 mm，下沿 1.72–1.75 mm | 约 0.55 mm 回差；四次上电下沿复现到 2 counts |
| 状态字节 | 0x38F b2 |
bit 0 = 第二个制动标志（1.45–1.66 mm）；bits 5:3 = 行程/健康状态 | 四种状态值实测；释放沿受速率限制、不可引用数值 |
| 消息校验 | 0x38E/0x38F b0 |
CRC-8/SAE-J1850，poly 0x1D、init 0x00、xorout 0x0A，覆盖 b1..b7 |
70,438 帧 100% 通过，两个 ID 参数相同 |
| 峰值行程（事件） | 0x38D b5:b6 |
uint16 小端，129.3 counts/mm | r=0.99975；与标定行程在 34 mm 内吻合 0.66 mm（n=10） |
| 制动持续时长 | 0x37D b0:b1 |
uint16 小端，27.50 ticks/s | r=0.99877；tick 非整数倍，未定（n=10） |
| 运行时长 | 0x31D/0x3AD b0:b1 |
uint16 小端计数，9.99 ticks/s（100 ms） | 四次运行确认；分析中作对照列，防伪相关 |
| 静态身份 | 0x32D（b0 多路复用，0.5 Hz） |
五帧按 b0 轮转，四次上电逐字节相同 | 件号/标定 ID 类数据，与踏板无关 |
| 踩下后事件 | 0x33D |
9.5 Hz，99.8% 时间为全 FF；触发为松开制动后 0.64–2.20 s |
与 0x31D 等构成「踩后突发」组，n=10 |
| 故障哨兵值 | 0x39D 行程 |
故障时钉在 16354（0x3FE2），校验仍有效 |
物理不可达，可按范围直接拒绝 |
读取方法与注意事项
三条工程纪律都来自实测教训。第一，必须在 ACK 模式采集：这是一个两节点总线，若用只听（listen-only）模式，没有人应答会导致错误计数每次尝试 +8、约 32 ms 进入 bus-off 后自动恢复并循环，同一 12 秒窗口下表现为 1006 fps 的单 ID 重传风暴，并且会掩盖四个 ID 中的三个；改用 ACK 模式则为 37 fps、四个 ID。ACK 是链路层比特、不是命令，只读采集仍会应答。
第二，先确认连接可靠。源文档记录：六轮排查（比特率扫描、极性互换、主机供电、ACK 模式）最终发现是助力器端接触不良。要用万用表从适配器接线端子一直通断到助力器引脚，而不是只看夹子「搭在上面」。
第三，别把总线识别挂在索引上。USB 索引会随重新插拔重排，适配器名称跟随适配器而非线束；识别哪块适配器在哪条总线要按内容——看到 0x39D 的就是 25/16。另一条独立现象是：已供电的收发器在 ECU 未运行时也会停在 2.5V，这只能证明收发器有电，不能证明 ECU 在跑。传感器上电后约 1.47 s 才初始化完成，此前的读数应视为无效。台架接线时，助力器两侧都不做终端，适配器一侧 R120 置 ON。
证据等级与边界
本档案是本台实物的台架观测，不是文档推测，也不是外部旁证。最硬的证据是校验与拟合：0x39D 的加和校验在 2,250 帧上 100% 通过；0x38E/0x38F 的 CRC-8 在 70,438 帧上零失败；位置与行程两条独立总线的拟合两次运行在斜率上仅差 0.13%、截距差 0.12%，远紧于它们与标尺的一致度，反过来证明「运行间标定冲突」是测量误差而非传感器问题。
三处必须原样保留的边界。其一，行程标定精度约 ±2 mm，瓶颈在标尺不在数据：单次保持内信号重复到约 ±20 counts = 0.062 mm，而两次运行之间最多相差 4.4 mm；死区（约 3.5 mm 自由行程）既未被确认也未被否证，因为差额被运行间误差淹没。其二，「踩后突发」组的每个结论都建立在 n=10 的事件上，候选字节远多于事件数；两个 0.999 拟合通过了 20,000 次置换检验，但低于 |r|≈0.9 的一律只作线索，且峰值与时长在本次采集里部分混淆（深踩往往也踩得久）。0x37D b5 与 0x34D b5 因与运行时长混淆，源文档明确不得引用。其三，status == 2 表示「助力不可用」，不是「位置无效」：传感器重连后位置恢复更新而状态仍为 2、助力仍关闭；0x38E 这时是唯一的活动位置来源，0x39D 仍钉在哨兵值。故障会闭锁，只有循环点火才能恢复。
不能外推的部分：以上数值只对应本台件号的这台实物；源文档列出的踏板传感器引脚（2、8、22、23）等条目来自其他 iBooster 变体的社区资料，属未验证假设，不能写进固件、DBC 或线束。另一个平台（GM Volt）的制动力命令/状态 ID 也被源文档明确标注「不可用于本机」。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文只描述只读采集。最后须重申：这是制动执行器，本档案的一切都是读取，没有任何一项是向它下命令。
常见问题
为什么不能用只听（listen-only）模式采集？
因为这是两节点总线：没有 ACK 就没有人应答，助力器的错误计数每次尝试上升 8、约 32 ms 进入 bus-off 后自动恢复并循环。同一 12 秒窗口下，只听模式表现为 1006 fps 的单 ID 重传风暴，并掩盖四个 ID 中的三个；ACK 模式则为 37 fps、四个 ID。ACK 是链路层比特而非命令，只读采集仍会应答。
故障状态 2 是不是「位置数据无效」？
不是。它表示「助力不可用」。源文档通过重连实验证明二者不同：传感器重连后位置恢复更新，但状态仍为 2、助力仍关闭，只有循环点火才恢复。因此位置的有效性要按范围单独判断——例如直接拒绝 0x39D 行程大于 13700 的读数。
踩下踏板的峰值行程与持续时长可信吗？
在 n=10 事件下，两者拟合分别为 r=0.99975（129.3 counts/mm）与 r=0.99877，且通过了 20,000 次置换检验，可作结论使用；但峰值与时长在本次采集中部分混淆（深踩往往也久），0x37D b5、0x34D b5 与运行时长混淆、源文档明确不得引用。低于 |r|≈0.9 的只算线索。
12 位位置 0x38E 与 16 位行程 0x39D 该用哪个？
0x39D 分辨率更高（约 0.003 mm/count 对约 0.016 mm/count），但只有 25.0 Hz；0x38E 为 99.7 Hz、快约 4 倍。对速率敏感的场景，频率比分辨率更重要。另须注意 0x38E 的换算偏置是负的：mm = 0.015207 * position - 4.072。
延伸阅读
- 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 对应本文「运行时长伪相关」「位置有效性单独判断」的数据质量主题。
- CAN 报文解析的「健康位」在说什么：校验、计数器与总线空窗 —— 承接
0x39D加和校验、0x38E/0x38FCRC-8 与存活计数。 - 车电接入：为什么 ESP32 的 TWAI 不等于 OBD 接口 —— 与本文「两节点总线必须 ACK」「端点终端」的接线约束互补。
- 同一个「转向灯」在三家车厂是三种实现：车辆状态归一化的坑 —— 本文两条总线上两个不同阈值的制动标志即同类问题。
- 车载传感器的暴露面与 ISP 无关的那部分 —— 用于理解「传感器重连不解除闭锁」的失效语义。
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/pelosim-tesla-ibooster/docs/DECODE.md（本项目车型档案主来源：已确认信号定义、标定与故障信号）。 - 项目 01 ——
public-can-dbc-datasets/additional/pelosim-tesla-ibooster/README.md（只读设计、两条总线的引脚与帧率、采集模式与接线要点）。 - 项目 01 ——
public-can-dbc-datasets/additional/pelosim-tesla-ibooster/docs/PINOUT.md与VERIFY_FIRST.md（引脚实测与未验证条目清单、置信度边界）。
说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复