星核火花赛车科技

标签： DBC

  • Cabana UI 会话：流生命周期、DBC 编辑与落盘边界

    结论：Cabana 的 UI 是一条以 MainWindow 为中心的生命周期：run() 初始化 GLFW 与 ImGui 后构造主窗口，把流、消息列表、消息详情、视频与图表组成 dock；startStream() 先启动源再加载 DBC 并创建组件，releaseStream() 则先销毁对话框与消费组件再销毁流。它的 DBC 编辑缺少可靠落盘证明：MainWindow::saveFile() 未检查 DBCFile::save() 的失败返回值，所以「File saved」与 clean 状态不能当作文件已可靠写盘的证据。本文为固定源码快照 c8fb906 的静态阅读，未启动 GUI 或连接设备。

    窗口与流的生命周期

    run() 初始化 GLFW、ImGui、主题与布局，然后构造 MainWindow 并进入渲染循环。startStream() 先启动源，再加载 DBC 和创建组件，等待第一批事件合并后关闭等待提示。

    切换流时，releaseStream() 先销毁工具对话框和消费组件，再销毁流，以避免回调持有已释放的全局 can 指针。这个顺序说明「流」与「消费组件」是两类生命周期，不能只按打开顺序反着关。

    主窗口还负责窗口布局的持久化：退出时 saveSessionState() 记录当前 DBC、消息标签和图表 ID，restoreSessionState() 仅在当前加载文件名与记录的 DBC 一致时恢复，且消息标签只恢复仍能在 DBC 找到的项目。保存 UI 会话不包含原始 CAN 帧，流日志是否留存另由输入和设置决定。

    流选择与输入配置

    StreamSelector 提供路段、Panda、Linux SocketCAN 和本地/远端 msgq 入口，并允许同时选择 DBC。每次打开都会重建选择控件，但它只是输入配置，不代表已经连接。Panda 配置允许选择序列号、三路 CAN 速率及适用型号的 CAN-FD 数据速率；选择器构造时即会短暂打开 Panda 判定型号，Panda 构造还会发 USB 通信重置，真正连接时设置 NO_OUTPUT，仍须遵守台架总线接线和速率约束。

    远端路段流程先取设备列表，再按时间范围取路段；401 转登录界面，网络错误会提示。其异步回调带存活弱引用与请求序号，避免旧响应覆盖新列表。登录调用认证并异步取设备与路段，但该账户授权只用于路段可见性，不等于车端网关写权限。

    组件 关键函数 作用与边界
    流选择 StreamSelector::open() / draw() 提供多输入入口并允许选 DBC；仅是配置，不代表已连接
    路段选择 OpenReplayWidget::open() / fetchRoutes() 远端先取设备再按时间取路段；异步回调带弱引用与序号
    Panda 配置 buildConfigForm() / PandaStream::connect() 构造时短暂打开判定型号；连接设 NO_OUTPUT，仍受台架约束
    登录 signIn() / fetchDevices() 账户授权只用于路段可见性，不等于网关写权限
    设置 SettingsDialog::save() 更新主题、缓存分钟、图表高度等；开启直播记录会在本地留存原始数据

    消息详情与 DBC 编辑

    DetailWidget::setMessage() 为 (bus, address) 开标签，联动信号树、位图与历史帧；其 updateWarnings() 对未收到消息、DBC 长度与收到长度不符、信号位重叠给出提示。这些是编辑器的观察性检查，不验证车辆总线发送策略。

    BinaryView 把位图拖拽选择转为新增或调整信号，并展示字节/位翻转热图；binaryViewSignals() 只把当前多路复用分支拥有的 payload 信号送入位图，避免不同分支的位重叠被误画为同时生效。热图表示样本变化，不证明信号语义或大小端定义正确。SignalModel::setData() 从属性表编辑名称、长度、大小端、比例、偏移、单位与取值描述，saveSignal() 检查重名并通过 EditSignalCommand 入撤销栈。

    关键在于：所有编辑都先修改内存 DBC，磁盘写入是单独步骤。由于主窗口的写盘失败返回值未传播，确认保存后仍可能以 clean 状态继续关闭；自制硬件的 DBC 制作流程应以重新打开、哈希校验和版本提交为准。

    文件、会话与错误状态

    FileDialog::accept() 在覆盖已有文件时二次确认，MessageBox::draw() 顺序消费确认与警告队列。remindSaveChanges() 在关闭或切换文件前提示保存或丢弃，但同样受上述返回值未传播的影响。

    设置保存与 DBC 保存不是一回事：Settings::save() 先加文件锁，再写临时 JSON、fsync 文件、rename 并 fsync 父目录，损坏的旧设置会尝试移到 .corrupt。这说明 UI 会话与用户设置本身具备更完整的原子写入路径，而 DBC 保存没有。

    对象 写入/存储方式 边界
    DBC 文件 先改内存，写盘为单独步骤 失败返回值未传播，clean 标志不足以作发布门
    用户设置 cabana.json 锁 + 临时文件 + fsync + rename + 父目录 fsync 损坏旧设置尝试移到 .corrupt
    UI 会话 记录当前 DBC、消息标签、图表 ID 不包含原始 CAN 帧，且需文件名一致才恢复

    对自制硬件与插件平台的约束

    流选择、图表和 DBC 编辑器属于离线或只读工具能力，不应和受信任的车端发送网关共享写权限；Panda 连接即使使用 NO_OUTPUT，也需台架审查波特率与接线。协议文件、用户 UI 设置、路段授权和原始日志应分别管理，DBC 保存必须验证返回值、做原子写入与重新读取，并记录所用源码与车型版本。

    远端路段登录、直播日志与设置目录可能处理敏感车内数据，插件清单应声明读写文件、网络与留存权限，并提供可审计的禁用与清理路径。需要提醒的是，当前 test_cabana_ui.py 只启动 cabana -h 并检查帮助输出，不能据此称菜单、弹窗、持久化或图形交互已通过 UI 自动化。

    常见问题

    Cabana 的「File saved」能证明 DBC 已可靠落盘吗？

    不能。MainWindow::saveFile() 未检查 DBCFile::save() 的失败返回值，因此「File saved」提示与 clean 状态不能作为文件已可靠写盘的证明。自制硬件应以重新打开、哈希校验和版本提交为准。

    打开流选择器会连上 Panda 吗？

    选择器构造时会短暂打开 Panda 判定型号，Panda 构造还会发 USB 通信重置；但真正连接时才设置 NO_OUTPUT。这只是输入配置流程，仍须遵守台架总线接线与速率约束。

    远端路段登录会给车端写权限吗？

    不会。登录调用认证并异步取设备与路段，但该账户授权只用于路段可见性，不等于车端网关写权限。

    保存 UI 会话会把原始 CAN 帧一起存下来吗？

    不会。saveSessionState() 只记录当前 DBC、消息标签和图表 ID；保存 UI 会话不包含原始 CAN 帧，流日志是否留存由输入和设置另行决定。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/CABANA_UI_SESSION_DEEP_DIVE.md（取用了主窗口与流生命周期、流选择与设置组件、DBC 编辑与落盘边界、会话持久化）。
    • 项目 02 —— openpilot-research/CABANA_VISUAL_ANALYSIS_DEEP_DIVE.md（关联的可视分析专题，用于区分 UI 会话与图表视频能力，本文未展开其实现）。

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

    更新记录

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

  • Tesla iBooster Gen1 CAN 档案：两总线与只读踏板信号

    结论：这份档案的对象不是整车，而是一台 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。

    延伸阅读

    参考资料

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

  • Waterloo 2024CAR DBC 档案：115 个报文与 890 条信号

    结论：这份档案记录的是滑铁卢大学电动方程式的整车固件仓库，以及其中归档的一份 2024CAR.dbc：115 条报文、890 条信号，另含一份 Vector 独立信号伪报文与逆变器、绝缘监测（IMD）等第三方部件的报文。它不是某一辆车的逐条解码结果，而是「一支学生车队把整车 CAN 定义放进一个固件 monorepo」的处置样本。需要明确两点边界：本快照只包含 README 与来源说明，DBC 本体未包含在内；且来源方声明车辆赛季、硬件装配、物理标度与原始数据权利均未独立核实。

    车辆与适用范围

    源文档来自一支 Formula Student 电动赛车队（UW Formula Electric）的固件主仓库。这里没有「某台实车采集了多少时长」的信息，只有一份被归档的整车 DBC 与它的来源记录。

    项 内容
    车型 车队 2024 赛季电动方程式赛车（由 2024CAR.dbc 文件名标识）
    年款 / 市场版本 源文档未确认具体赛季；命名为 2024，但「车辆赛季未被独立核实」
    ECU / 改装状态 车队自研整车固件，含车辆/HIL 板固件、电池单体测试固件与固件验证台架
    采集跨度 源文档未给出日志数或帧数；仅给出 DBC 的规模数字
    适用范围 仅限该队列的这份 DBC 快照；源文档明确「硬件装配与物理标度未独立验证」，不得当作通用定义

    总线与寻址

    源文档不描述物理层与寻址方式的细节，只在来源说明里交代 DBC 的规模与内容构成。因此下表大部分项标注为「源文档未给出」，而不是代填。

    项 内容
    物理层 源文档未给出（README 仅指向一份通用 CAN 协议教程）
    链路层 / 比特率 源文档未给出
    寻址方式 源文档未给出
    CAN FD 源文档未提及
    规模 2024CAR.dbc：115 条报文行、890 条信号行
    完整性校验 Git blob 6f64218…；SHA-256 b2901a5c…（源文档给出前段）

    已解码信号

    本快照不包含 DBC 本体，只有 README 与来源说明，因此无法提供逐字节解码。为守住「只抄源文档里有证据的条目」这条线，下表登记来源说明中明确写出的数据资产与部件类别，并逐条注明证据页；任何具体字节、位域与缩放系数，源文档均未提供。

    条目 承载 / 归属 说明 证据
    2024CAR.dbc（整车） — 115 条报文、890 条信号 SOURCE 说明
    Vector 独立信号伪报文 DBC 内 上游工具约定的伪报文，非真实总线流量 SOURCE 说明
    逆变器（inverter）报文 DBC 内 第三方部件流量 SOURCE 说明
    绝缘监测（IMD）报文 DBC 内 第三方部件流量 SOURCE 说明
    ChargerMessages.dbc 仓库内另存 充电机相关，未随本快照复制 SOURCE 说明
    HIL 测试 DBC 仓库内另存 硬件在环测试用，未随本快照复制 SOURCE 说明
    VCU 板固件 make vcu 整车控制单元构建目标 README「Quick start」
    BMU 板固件 make load LOAD_TARGET=bmu 电池管理单元构建/烧录目标 README「Quick start」
    单体测试固件 / 验证台架 仓库内 电池单体测试与固件验证 README 首段

    读取方法与注意事项

    源文档给出的可用操作集中在开发与构建层面：贡献者通过预构建的多架构 dev container 获得统一工具链（ARM GCC、Python 依赖），Windows 走 WSL2 + Dev Containers，构建用 make <board>、make all、make clean，烧录用宿主机的 make load LOAD_TARGET=<board> 或 STM32CubeProgrammer。这一层能保证固件可编译，但不等于能解出实车信号。

    要真正解析这份 DBC，需要把 DBC 文件本身载入基于 DBC 的解析库（README 提到仓库环境使用 cantools，并要求其特定版本）。由于本快照未包含 DBC，本文无法代做任何逐字节解析。标度与物理单位必须以 DBC 文件内容为准，源文档特意提醒「物理标度未独立验证」。

    还有一层法律与合规注意：来源说明指出，在该版本上未找到任何顶级许可证文件或声明的 GitHub 许可证，因此应把它保留为私有离线研究副本，再分发或集成交付前须先确认来源与权利。

    证据等级与边界

    本档案属于项目登记，既不是实车观测，也不是第三方旁证。可以核对的是数字本身（115 条报文、890 条信号、blob 与 SHA-256），以及仓库确是这支车队的固件 monorepo；不能据此认定这些定义能套用到任何一辆实车。

    三处不能外推。第一，「2024CAR」是文件名推断，源文档明确车辆赛季、硬件装配与原始数据的厂商权利均未被独立验证。第二，DBC 里混有第三方部件（逆变器、IMD）与 Vector 伪报文，这些条目代表部件厂商或工具的约定，不是整车厂的车身定义，不能与自研 VCU/BMU 信号混为一谈。第三，快照不完整：ChargerMessages.dbc 与 HIL 测试 DBC 未复制进来，因此不能对整车网络做「全覆盖」结论。

    关于「安全访问」类问题：本文只整理公开文档登记的数据资产，未涉及任何诊断会话或安全访问；源文档未提供绕过方法，且不建议尝试。

    常见问题

    2024CAR.dbc 里有多少报文和信号？

    据来源说明，这份 DBC 有 115 条报文行与 890 条信号行，另含一条 Vector 独立信号伪报文以及逆变器、IMD 等第三方部件报文。

    这份档案为什么没有逐条信号解码？

    因为本快照只包含 README 与来源说明，DBC 本体未包含在内。逐字节、位域与缩放系数都在 DBC 文件里，不在文档中，这是素材边界而非解析遗漏。

    能不能直接用于实车？

    不能。来源方声明车辆赛季、硬件装配与物理标度均未独立核实；同时该版本未声明任何许可证，应仅作为私有离线研究副本，复用前须确认来源与权利。

    这份固件怎么构建和烧录？

    用预构建 dev container 提供统一工具链，构建命令为 make vcu、make all 等；烧录在宿主机用 make load LOAD_TARGET=bmu 或 STM32CubeProgrammer。这只是构建流程，与解析实车信号无关。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/uwaterloo-2024car/README.md（本项目车型档案主来源：固件 monorepo 的结构、构建与烧录流程）。
    • 项目 01 —— public-can-dbc-datasets/additional/uwaterloo-2024car/SOURCE.md（DBC 规模、blob/SHA-256、以及「未独立验证」的边界声明）。

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

    更新记录

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

  • Mazda MX-5 ND2：HS-CAN 开放字段与逐字节标定

    结论：Mazda MX-5 ND2 的 CAN 档案有一个鲜明特征：总线本身是可抓的——HS-CAN、500 kbit/s——但相当一部分字段仍处于「逐字节标定」阶段。源文档对 0x420 这一个 ID 内的不同字节分别拟合出不同刻度（油耗计数、行驶距离、环境温度各一套），并用 `_maybe` 后缀与「负向发现」明确标出哪些结论尚未闭环。以下所有结论仅限源文档记录的这一台车。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 Mazda MX-5 ND2 的运行日志与字段标定记录。项目以第三方整理的 DBC 为起点，再用实测日志逐字段校验，并把未闭环的字段单独列成「开放字段」清单。

    项 内容
    车型 Mazda MX-5（ND2）
    年款 / 市场版本 源文档未确认
    数据来源 源文档为德文运行日志，记录 2026-09-27 至 09-30 的状态；DBC 派生自第三方公开整理的第六代 Mazda CAN 数据库
    采集状态 日志中记录了一次采集通道冲突：某个高频轮询脚本与手机端的采集适配器争用，影响了部分时段的采样
    适用范围 仅限源文档记录的这一台车；ND2 之外的年款、以及同款不同配置，字段位置与刻度都可能不同

    总线与寻址

    这辆车的接入相对直接：HS-CAN 上没有出现「必须主动问」的情形，字段基本来自周期广播或用已知 ID 关联。难点不在能不能抓，而在于抓到之后如何确定每个字节的物理含义。

    项 内容
    总线 HS-CAN
    速率 / 帧格式 500 kbit/s；11 位标准帧
    编解码基础 以第三方整理的 DBC 为起点，字段用实测日志逐条校验
    字段状态标注 未闭环字段加 `_maybe` 后缀；用相关系数与「负向发现」区分「有信号」与「没有该信号」

    已解码信号

    下表从源文档的「开放字段」清单与运行日志中抽取。项目对未闭环条目统一加 `_maybe` 后缀，并给出拟合依据（相关系数、阈值或确认比例），本文原样保留这些标注。

    信号 位置（ID / DID / 字节） 解码 证据
    ReverseGear（倒挡） 0x445 bit7 位标志 99.7% 确认
    DCDC_Voltage 0x08A 位 19|10 0.02 V/LSB 标定记录
    BCM_SupplyVoltage 0x43F 位 19|10 0.016 V/LSB 标定记录
    FuelConsumption_Counter（油耗计数） 0x420 B2 约 4834 步/升 逐字节标定
    Travel_distance_related（行驶距离） 0x420 B1 0.1992 m/步 逐字节标定
    AmbientTemp（环境温度） 0x420 B7 raw ÷ 4 ℃ 逐字节标定
    DistanceToService_related（保养距离） 0x3D1 位 47|14 km 候选
    CruiseActive_Inv（巡航激活，反相） 0x0FD bit61 50 Hz；0 = 巡航中 标定记录
    CRU_CON_SW1（巡航开关） 0x09D B0 bit5 / bit0 / bit3 位标志组 候选
    TCS_Active_maybe（牵引力控制激活） 0x211 bit40 位标志 候选（`_maybe`）
    HighDecel_maybe（大减速度） 0x211 bit43 位标志，阈值约 0.55–0.6 g 候选（`_maybe`）

    读取方法与注意事项

    第一条是「逐字节标定」的必要性。同一个 ID（例如 0x420）内部，不同字节承载的是完全不同的物理量，刻度也各不相同：一个字节对应油耗计数（约 4834 步每升），一个字节对应行驶距离（0.1992 米每步），还有一个字节对应环境温度（raw 除以 4）。把整条帧当作单一信号处理，会得到没有意义的数值。要按字节甚至按位分别标定。

    第二条是采集通道的争用。日志记录了一次冲突：一个高频轮询脚本与手机端采集适配器争用同一个接口，导致部分时段采样不完整。做周期统计或相关分析前，应先确认采集链路不存在争用，否则得到的「频率」其实是硬件带宽被挤占后的结果。

    第三条是位序与位号约定。源文档使用「位 19|10」这类跨字节的位号表示法，含义与常见的「起始位 + 长度」不同，解析时要先统一约定，否则容易把两个相邻字段读成同一个值。

    证据等级与边界

    项目用两类手段区分结论强度。一是「确认比例」，例如倒挡信号给出了 99.7% 确认；二是「负向发现」——源文档明确指出，在这辆车的日志里没有找到垂直加速度、侧倾、俯仰这类信号。负向发现同样是有价值的信息：它说明这些量要么不通过 CAN 广播，要么需要从别的传感器获取。

    未闭环字段一律加 `_maybe` 后缀，例如 TCS_Active_maybe 与 HighDecel_maybe。这表明它们只是「看起来像」某个物理量的候选位，尚未经过独立验证。使用时应把它们当作待验证假设，而不是可用字段。

    边界上必须强调：以上字段位置与刻度都来自这一台车与这一版 DBC。不同年款、不同配置的 MX-5，甚至同一车型的不同固件，都可能让字节偏移或刻度变化。跨车使用前必须重新标定。

    常见问题

    为什么同一个 ID 里的三个字节刻度完全不同？

    因为 CAN 帧是按位打包的字节流，一个 ID 内部的不同字节可以被车厂分配给毫不相干的物理量。源文档对 0x420 就是分别处理的：油耗计数约 4834 步每升、行驶距离 0.1992 米每步、环境温度 raw 除以 4。按整帧处理会得到无意义数值。

    `_maybe` 后缀是什么意思？

    表示该字段尚未闭环验证，只是「看起来像」某个物理量的候选位。例如 TCS_Active_maybe 与 HighDecel_maybe。使用时应把它们当作待验证假设，先自行复核再引用。

    「负向发现」为什么值得记录？

    因为它同样缩小了搜索空间。源文档明确指出这辆车没有找到垂直加速度、侧倾、俯仰信号，说明这些量要么不经 CAN 广播，要么需另求来源——这能避免后来者把时间花在并不存在的信号上。

    这些字段能直接用于别的 MX-5 吗？

    不能。源文档的结论限定在这一台车与这一版 DBC 上，不同年款或配置的字节偏移与刻度都可能变化。换车使用前必须重新标定。

    延伸阅读

    参考资料

    • 项目 04 —— public-can-dbc-datasets/additional/mainbrain-mx5-nd2-can/docs/status/can-open-fields.md（本项目车型档案主来源：开放字段清单与标定依据）
    • 项目 04 —— public-can-dbc-datasets/additional/mainbrain-mx5-nd2-can/docs/status/can-bus.md（运行日志与采集状态）
    • 项目 04 —— public-can-dbc-datasets/additional/mainbrain-mx5-nd2-can/SOURCE.md（DBC 版本与来源说明）

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

    更新记录

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

  • 2022 GR86 / BRZ 的 CAN 数据地图：ASC 与 DCM 口

    结论：这份档案记录的是 2022 款丰田 GR86 / 斯巴鲁 BRZ（第二代）的 CAN 数据地图，最重要的结论是一条接入方式的改变：这一代的 OBD-II 口（驾驶侧脚部空间）不再对外暴露高速 CAN 数据，只回应 OBD-II 请求，想要高频刷新就必须改接隐藏的 DCM 口或 ASC 口。在这两条路径上，源文档逐条列出 18 个 CAN ID 的通道与 RaceChrono 公式，覆盖转速、油门、转向角、横摆角速度、四轮速、加减速度、油水温、油位与胎压。下列结论仅限源文档记录的 2022 款样本，且要区分不同端口的数据完整性。

    车辆与适用范围

    源文档是一份个人车型知识库的 CAN 章节，记录的是逐帧观测与 RaceChrono 公式，不是 DBC 文件。它同时给出两个取数端口与一批候选信号。

    项 内容
    车型 Toyota GR86 / Subaru BRZ / Scion FR-S（第二代，2022 款）
    年款 / 市场版本 2022 款；源文档区分「美国市场 BRZ」与「GR86 / 欧洲市场 BRZ」，端口可用性不同
    取数端口 DCM 连接器（手套箱后，GR86 与欧规 BRZ 有；美规 BRZ 无）或 ASC 端口（美规 BRZ 常用，但缺部分数据）
    采集跨度 源文档未给出日志数或帧数；附一份怠速 10 秒的 CAN ID 直方图
    适用范围 仅限 2022 款；第一代（2013–2020）另有独立文档，公式与系数不同

    总线与寻址

    文档把两个候选端口都视为同一高速 CAN 的入口，但它们暴露的报文并不完全一致：某些 ID 只在其中一个端口可用。源文档未给出比特率，也未说明 11 位/29 位寻址，只给出逐帧十六进制示例与刷新率。

    项 内容
    物理层 DCM 口（手套箱后）或 ASC 口（「假引擎声」母连接器，仪表台右侧）；自布线可用丰田收音机线束中间两针
    链路层 / 比特率 源文档未给出
    寻址方式 源文档未给出；示例均为小端位域取值
    CAN FD 源文档未提及
    可用性差异 例：0x13A 不在接 ASC 单元的 B_CAN 上；0x143、0x2D2 不在 DCM 口；多个 ID 在 ASC 口不可用

    已解码信号

    解码式使用 RaceChrono 方程格式（bytesToIntLe(raw, 起点, 长度) 等），字节按 -- (A)(B)(C)(D)(E)(F)(G)(H) 命名。下表抽取 15 条最有代表性的通道，证据与保留意见原样标注。

    信号 ID / 字段 解码 证据 / 置信度
    发动机转速 0x40（100 Hz，byte2 起 14 位） bitsToUIntLe(raw, 16, 14) 源文档逐帧示例
    空挡状态 0x40 byte D D & 0x80（MT/AT 通用） 源文档标注
    加速踏板位置 0x40 byte E/F/G E / 2.55（同刹车同踩时为 0） 源文档标注
    倒挡 0x228 byte C C & 0x01 源文档标注
    转向角 0x138（50 Hz，byte2 起 2 字节） bytesToIntLe(raw, 2, 2) * -0.1（正值=左转） 源文档标注
    横摆角速度 0x138（byte4 起 2 字节） bytesToIntLe(raw, 4, 2) * -0.2725 对 RaceBox Mini 陀螺仪标定；第一代用 0.286478897
    车速 0x139（50 Hz，byte2 起 13 位） bitsToUIntLe(raw, 16, 13) * 0.015694 建议对 GPS 复核（换轮胎后）
    刹车灯开关 0x139 byte E E & 0x4（4=亮） 源文档标注
    刹车压力 0x139 byte F F * 128 系数取自第一代车，可能需验证
    四轮车速 FL/FR/RL/RR 0x13A（bit12/25/38/51 起 13 位） bitsToUIntLe(raw, n, 13) * 0.015694 与车速同乘数；ASC 口不可用
    横向加速度 0x13B byte6 bytesToIntLe(raw, 6, 1) * 0.2 源文档标注
    纵向加速度 0x13B byte7 bytesToIntLe(raw, 7, 1) * -0.1 源文档标注
    机油温度 / 冷却液温度 0x345（10 Hz，byte D / E） D - 40 / E - 40 源文档标注
    进气/环境温度 0x390（10 Hz，byte E） E / 2 - 40 源文档标注
    油位 0x393（10 Hz） 100 - (bitsToUIntLe(raw, 32, 10) / 10.23) 未滤波/噪声大，公式「开发中」

    读取方法与注意事项

    第一道门槛是端口。源文档明确：这一代的 OBD-II 口不再暴露 CAN 数据（除 OBD-II 请求外），要高频记录就得走 DCM 或 ASC。DCM 口藏在手套箱后方，被胶带固定，可用配套的 DCM/OBD 转接件，也可以用丰田收音机线束中间两针自做线束；ASC 口在仪表台右侧，可买成品转接件保留原功能。

    第二道门槛是端口差异。多个 ID 只在其中一个端口可用：0x13A（四轮速）不在接 ASC 单元的 B_CAN 上，0x143、0x2D2 不在 DCM 口，另有若干低频 ID 只在特定端口出现。选端口前应先按「所需通道」反查可用性，而不是默认两者等价。

    第三是公式的成熟度。文档自己标注了两处不确定：刹车压力系数取自第一代、可能需验证；油位公式噪声大、仍在打磨。轮胎压力（0x6E2，1 Hz）的编码取决于仪表盘使用的单位，文档因此给了 psi、bar、kPa 三套换算式，并说明轮胎顺序与仪表显示一致（已考虑换位）。

    证据等级与边界

    本档案属于文档观测 + 外部标定：多数通道来自逐帧观测，横摆角速度的系数是对外部陀螺仪标定得到的，而刹车压力系数是借用第一代的旁证，未经独立标定。因此「已验证」与「需复核」在表里是分开标的。

    三处不能外推。第一，代际不能混用：第一代与第二代的横摆标定系数不同，第一代的端口与部分公式不能直接搬过来。第二，端口差异不能忽略：在 ASC 口抓不到的 ID，不代表车辆没有产生，而是该端口不广播。第三，单个样本不足以覆盖所有配置——源文档提示换装不同直径轮胎后需对 GPS 复核乘数。

    关于「安全访问」类问题：这是一份被动记录与公式文档，未涉及任何安全访问绕过；源文档未提供绕过方法，且不建议尝试。

    常见问题

    2022 款 GR86 / BRZ 能不能从 OBD 口抓高速 CAN？

    不能。源文档明确这一代的 OBD-II 口只回应 OBD-II 请求，不再暴露 CAN 数据；要高频记录必须改用隐藏的 DCM 口或 ASC 口。

    DCM 口和 ASC 口有什么区别？

    数据完整性不同。DCM 口在 GR86 与欧规 BRZ 上存在、美规 BRZ 没有；ASC 口是美规 BRZ 常用的替代入口，但缺部分数据（例如 0x13A 不在接 ASC 的 B_CAN 上）。应先用端口可用性反查所需通道。

    为什么转向角和横摆角速度要乘负数？

    负数只改变正方向的定义：转向角 * -0.1 定义为「正值=左转」，如需相反方向可自行加负号；横摆角速度 * -0.2725 的系数是对外部陀螺仪标定得到的，与第一代的 0.286478897 不同。

    胎压是怎么解出来的？

    0x6E2（1 Hz）的编码取决于仪表盘的显示单位，因此有三套公式：psi 车 lowPass(D>>1,126) * 6.8948、bar 车 * 10、kPa 车 * 10 / 2，结果都换算成 kPa。轮胎顺序与仪表显示一致。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/timurrrr-ft86-can-maps/can_bus/gen2.md（本项目车型档案主来源：2022 款端口、CAN ID 与 RaceChrono 公式）。
    • 项目 01 —— public-can-dbc-datasets/additional/timurrrr-ft86-can-maps/can_bus/gen1.md（第一代对照，本章的刹车压力系数即借自此处）。
    • 项目 01 —— public-can-dbc-datasets/additional/timurrrr-ft86-can-maps/README.md（车型知识库目录与代际划分）。

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

    更新记录

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

  • 方程式赛车总线档案：53 条报文与多设备 DBC 合并

    结论：这份档案的对象是一支大学生方程式车队的赛车总线，不是量产车：源文档以 11 位标准帧、8 字节为主的 DBC 文本，逐条给出 ECU、变速箱控制、IMU、电源分配、车轮与制动传感器等设备的报文定义。它的数据特征是「多设备 DBC 合并成一份 master」——config.dbc 是自动生成的整车总览（当前 53 条报文），单独设备定义在 devices/ 下，两者按设计存在重叠，不可当作彼此独立的车辆覆盖。源文档未提供比特率、日志数或采集跨度，也未独立验证各供应商组件定义的年份与适用性，因此下述结论只限这份 DBC 快照本身。

    车辆与适用范围

    源文档是一份随车项目公开的 DBC 配置仓库：根目录一份 config.dbc 作为「master calibration」，各设备定义放在 devices/，通过合并脚本汇总。它描述的是车队赛车的整车总线，而非某一款市售车型。

    项 内容
    车型 大学生方程式赛车队的赛车及车上组件（源文档未给出具体车号或平台名）
    年款 / 市场版本 源文档未确认；仓库中同时保留历史 2019-2021/config.dbc
    ECU / 改装状态 赛车总线，含 ECU、变速箱控制（GCM）、IMU、电源分配模块（PDM）、GPS/圈速记录（SDM550）、制动红外测温与车轮力传感器等
    采集跨度 源文档未提供（无日志数、事务数或时长记录）
    适用范围 仅覆盖该 DBC 快照内定义的设备与报文；各供应商组件定义的年款适用性未独立验证

    总线与寻址

    源文档以 DBC 文本形式给出全部报文，未包含物理层描述，因此比特率与终端电阻等条件无法从本档案确认。

    项 内容
    物理层 / 比特率 源文档未给出
    寻址方式 逐条报文均标注 Extended: No，即 11 位标准帧
    帧长度 以 8 字节为主；个别报文 2 / 4 / 6 字节（如 SDM550_LapTrigger 为 2 字节、GCM_Queue 与 GCM_Error 为 4 字节）
    CAN FD 源文档未提供任何 CAN FD 报文
    组织方式 按设备分文件定义，再由脚本合并为 config.dbc 总览
    字节序 同一设备内混用：既有 big_endian 也有 little_endian，须逐信号核对

    已解码信号

    下表从源文档的信号定义中抽取最有代表性的条目（发动机、底盘、IMU、圈速与耗材传感器）。位置一列保留源文档的报文 ID 与字节位/长度写法，解码一列保留其原始缩放与单位；「证据」一列注明该条目出自合并总览还是组件定义。

    信号 位置（ID / 起始位·长度） 解码 证据
    nmot 0x300 / bit 7·16 大端有符号，缩放 1，0–20000 rpm；同一信号亦出现在 0x20、0x3fb config.dbc 及组件定义
    ath 0x300 / bit 23·16 大端有符号，缩放 0.1，0–110 % config.dbc
    lambda 0x300 / bit 39·16 大端有符号，缩放 0.001，0–5 config.dbc
    ub（电压） 0x300 / bit 55·16 大端有符号，缩放 0.01，0–25.5 V config.dbc
    tmot / toil / tint / tfuel 0x301 / 各 8 位 缩放均为 1 °C；tmot 为小端，其余大端 config.dbc
    texh 0x301 / bit 32·16 小端无符号，1 °C，0–1250 °C config.dbc
    poil / pfuel 0x302 / 16 位 大端有符号，缩放 0.001，0–10 bar config.dbc
    gear / pbrake_f / pbrake_r 0x20 / 字节 5–7 区 挡位 -1–12；前后制动压力 0–150 bar config.dbc
    speed（变速箱控制） 0x3fb / bit 0·16 小端无符号，缩放 0.01，0–400 km/h config.dbc
    四轮速 + 车速 0x3aa / 各 8 位 vwheel_fl/fr/rl/rr 与 speed，0–400 km/h config.dbc
    Laptrigger_laptime_dls 0x69a / bit 32·32 小端无符号，缩放 0.01，0–500 s config.dbc
    lapctr / outctr 0x69c / 各 8 位 小端无符号，0–255 config.dbc
    IMU_Yaw_Rate 0x174 / bit 0·16 小端，缩放 0.005，单位 deg/s config.dbc
    IMU_X_Accel 0x178 / bit 32·16 小端，缩放 0.0001274，「g」量纲 config.dbc
    Kistler_S350_Vel 0x7fa / bit 23·16 大端无符号，缩放 0.036，0–400 km/h config.dbc

    读取方法与注意事项

    源文档给出了一条明确的工程纪律：不要直接修改 config.dbc。它的定位是「master calibration」，主要供某类商业诊断工具在接入车辆时总览整条总线；正确的做法是编辑 devices/ 下各设备的 DBC——这样更容易批量重命名信号、整体调整某设备的所有 ID。

    合并流程是：在 devices/ 目录下运行合并脚本 python merge_can.py，把各设备定义汇总生成根目录的 config.dbc。源文档并提示 devices/ 下的隐藏文件 .dbc 并非空占位，而是一份有效的五报文制动红外传感器定义。

    解析时须注意两点。第一，同一逻辑量会在多条报文里重复出现（例如 nmot 同时出现在 0x300、0x20、0x3fb），是否一致、以哪条为准，源文档未给出仲裁规则。第二，字节序在同一设备内混用，大端与小端并存，任何解析器都必须逐信号读取其 Byte Order 字段，不能假定全局一致。

    证据等级与边界

    本档案属于「源码/配置静态记录」：全部信号定义都能在 DBC 文本里逐字核对，属于源文档直接证据；但源文档没有任何实车观测，也没有比特率、节拍或日志作为间接支持。文件层面，源文档说明该快照归档了 21 个字节互不相同的 DBC：当前 config.dbc（53 条报文）、历史 2019-2021/config.dbc（23 条报文）以及 devices/ 下 19 个组件文件。

    两点不能外推。第一，当前 master 与组件定义按设计重叠，把两者相加并不能得到更大的车辆覆盖，只能得到同一辆车的重复描述。第二，源文档明确这些是车队赛车与组件定义、不是量产车型 DBC，且各供应商组件定义的具体年份与适用性未独立验证；把某条信号外推到其他年份的其他车上，超出了源文档证据。此外，该仓库快照未声明也未发现许可证，部分组件名指向第三方供应商、原始权利未核实，源文档要求保留为私有离线研究副本、再分发前先确认权利。

    关于安全访问，源文档未提供任何绕过方法，且不建议尝试。

    常见问题

    config.dbc 为什么不能直接改？

    因为它是自动生成的整车总览，单独设备定义在 devices/ 下。直接改 master 会与组件定义脱节；源文档要求改组件 DBC，再用合并脚本生成 master，这样便于批量重命名与整体改 ID。

    把 master 和组件 DBC 的信号加起来，覆盖会不会更大？

    不会。源文档明确当前 master 与组件定义按设计重叠，两者不是独立的车辆覆盖；相加只是重复描述同一辆车，不能当作更全的信号集。

    这些信号能直接套到其他年份的赛车上吗？

    不能。源文档未确认车辆年份，也未独立验证各供应商组件定义的适用性；同一逻辑量还会在多条报文里重复出现且未给仲裁规则。外推超出源文档证据范围。

    为什么同一设备的字节序会混用？

    源文档如实记录：部分信号为 big_endian、部分为 little_endian（例如 0x301 的 tmot 为小端、toil 为大端）。这是源定义的实际状态，解析器必须逐信号读取字节序字段，不能假定全局一致。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/illini-motorsports-can-configuration/UPSTREAM_README.md（本项目车型档案主来源：config.dbc 与 devices/ 的组织方式及全部报文信号定义）。
    • 项目 01 —— public-can-dbc-datasets/additional/illini-motorsports-can-configuration/SOURCE.md（仓库修订、21 个字节互不相同 DBC 的归档说明、许可证与适用性边界）。

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

    更新记录

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

  • Indian Springfield 2017：J1939 摩托车 CAN 档案

    结论：Indian Springfield（2017 款）是一辆主动用 J1939 广播数据的摩托车：源文档用只监听（listen-only）方式在 4 次采集中抓到 42,365 个变化事件，并按 PGN / SPN / SA 体系拆出 30 个参数组。它有两个特殊之处：采集做了「变更去重」，帧数并不等于发送次数；车厂还在 DM1 故障报文里用 FMI 9（Abnormal Update Rate）间接承认了部分信号的存在。以下所有结论仅限源文档记录的这一台车及其固件。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 Indian Springfield 摩托车的 CAN 日志整理。项目采用只监听模式，不向总线发送任何帧，采集后按 J1939 的参数组、可疑参数与源地址体系做拆分，并对每个参数组标注了是否已发布。

    项 内容
    车型 Indian Springfield，2017 款
    年款 / 市场版本 源文档标注为 2017 款；具体市场版本未确认
    发动机 风冷 V 型双缸；源文档指出该车没有水温传感器，标准参数组里位置原本留给水温的字节，在本车上装的是缸头温度
    采集跨度 4 次采集，累计 42,365 个变化事件，采集日期 2026-08-15
    适用范围 仅限源文档记录的这一台车；不保证适用于其他年款或排量的 Indian 车型

    总线与寻址

    这辆车用的是 J1939 而非「按 ID 广播原始布局」的常见乘用车 CAN。理解它的数据，先要理解 J1939 的三层语义：PGN 是参数组，SPN 是组内的可疑参数，SA 是发送该组的源地址。

    项 内容
    物理层 / 速率 单条 CAN，J1939（29 位扩展帧）；源文档未给出该车波特率
    协议语义 PGN（参数组）+ SPN（可疑参数）+ SA（源地址）
    源地址名册 SA 0 = 发动机；SA 11 = ABS；SA 23 = 仪表；SA 39 = 管理电脑；SA 136 = 第二个仪表（厂商码 146，但源文档记录它从不发数据）
    传输层 TP / BAM（长报文分段传输）
    参数组总数 30 个 PGN，分四组：20 个已发布、4 个传输层、1 个已知不发、5 个未知
    采集方式 只监听（listen-only），硬件为 ESP32-S3 加 MCP2518FD；采集器不对总线做任何应答

    已解码信号

    下表从源文档的参数组与逐字节清单中抽取。项目把未闭环的条目明确标为「候选」或「开放线索」，本文原样保留这些标注，不做拔高。

    信号 位置（ID / DID / 字节） 解码 证据
    缸头温度（标准 SPN 110 位置） PGN 65262 SA0 B0 摄氏度 已发布参数组；源文档注明本车为风冷，该字节实装缸头温度而非水温
    引擎需求扭矩 PGN 61444 SA0 B7 offset −125 已发布参数组
    油门踏板位置 PGN 65266 SA0 B7 SPN 51；源文档记录到两个静止值 开放线索
    相对后轮速 PGN 65215 SA11 B4 与后轮速相关（r=+0.84） 候选
    巡航状态 PGN 65265 SA0 B3[1:0] 位线索 开放线索
    续航里程 PGN 65382 SA0 B3:B4 u16 小端，km 开放线索
    侧撑（standDown） PGN 65381 SA0 B7 bit0 位标志 候选
    熄火开关（killSwitch） PGN 65381 SA0 B4 bit6 位标志 候选
    最忙未解字节 PGN 65382 SA0 B0 共出现 255 个不同取值 未解（源文档列为待解字节）

    读取方法与注意事项

    第一条是采集方式。源文档全程使用只监听模式，硬件不参与总线仲裁、不做应答，因此不会扰乱车辆。这对摩托车尤其重要：摩托车的 CAN 往往只有少数几个节点，任何主动发送都可能被整车当作异常输入。源文档没有描述任何主动请求或写入操作。

    第二条是「变更去重」。项目的采集脚本只记录 payload 发生变化的帧，因此日志里的 42,365 是「变化事件数」，不是「发送次数」。同一个信号静止时不会产生新记录，所以不能拿日志条数反推某个报文的实际周期；要算频率必须回到未去重的原始采集。

    第三条是语义陷阱。J1939 的标准参数组里，某个字节在标准中定义的是 A 参数，在具体车型上可能被车厂改成 B 参数。本车把标准为水温的位置改成了缸头温度，就是典型例子——按标准名直接套用会得到错误结论。

    证据等级与边界

    源文档把结论分成几档：已发布（对应 J1939 标准参数组）、传输层、已知不发、未知。信号层面则以「候选」与「开放线索」标注尚未闭环的推断。本文只把候选条目当作「值得进一步验证的方向」，不作为可直接引用的结论。

    项目有一条很有价值的旁证方法：J1939 的 DM1 故障报文会用 FMI 9（Abnormal Update Rate，更新速率异常）来表示「某个本该定期广播的信号没有按时到达」。源文档列出的 7 条相关记录中有 6 条已落到已发布参数组——换句话说，车厂自己在故障报文里承认了这些信号在总线上被广播。这为「某信号确实存在于该车」提供了来自车厂侧的间接证据。

    边界上必须强调：以上结论全部来自这一台 2017 款 Indian Springfield 与这 4 次采集。不同年款、不同固件、不同排量的车型，参数组布局与源地址分配都可能不同。任何外推前都必须重新采集验证。

    常见问题

    为什么日志里只有 4 万多个「帧」？

    因为项目采用了变更去重采集：只记录 payload 发生变化的帧。42,365 是变化事件数，不是发送次数。要计算某个报文的实际周期，必须使用未去重的原始采集，而不能用日志条数反推。

    怎么知道某个信号真的存在于这辆车上？

    除了日志相关分析，源文档还借助 DM1 故障报文里的 FMI 9（Abnormal Update Rate）：车厂用它表示「某个应定期广播的信号没按时到」。源文档中 7 条 FMI 9 记录有 6 条对应已发布参数组，相当于车厂侧间接承认了这些信号的存在。

    J1939 的标准信号名能直接套用吗？

    不能。标准参数组只规定了「某个位置通常放什么」，车厂可以改。本车把标准里水温的位置改成了缸头温度，若按标准名直接解析就会得到错误结论。必须先在本车上复核。

    只监听会不会漏掉数据？

    不会漏掉「被广播的数据」，但拿不到任何需要主动请求的模块数据。本车的关键信息都是周期广播，因此只监听足以覆盖；如果某辆车存在「要问才答」的模块，只监听就会缺失那部分。

    延伸阅读

    参考资料

    • 项目 03 —— public-can-dbc-datasets/additional/prinsessen-indian-springfield-2017/docs/DECODE-PLAN.md（本项目车型档案主来源：参数组分组、源地址名册与已撤回信号）
    • 项目 03 —— public-can-dbc-datasets/additional/prinsessen-indian-springfield-2017/docs/UNEXPLORED-BYTES.md（逐字节清单与开放线索）
    • 项目 03 —— public-can-dbc-datasets/additional/prinsessen-indian-springfield-2017/README.md（硬件与 listen-only 采集说明）

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

    更新记录

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

  • Honda 车辆输入：四轮混速与 Bosch／Nidec 巡航分支

    结论：Honda 的 CarState 不直接使用基类的四轮均速 helper：它把四轮 WHEEL_SPEEDS 求均并换算为 m/s，再用 1 到 6 m/s 的插值权重，把低速更依赖的 ENGINE_DATA.XMISSION_SPEED 与轮速混合后送入 KF1D 得到 vEgo/aEgo；standstill 另按变速箱速度小于 1e-5 单独判断。刹车开关信号按源码注释可能含单次噪声，非 BOSCH_ALT_BRAKE 车型要求当前与前值连续两样本同为真。本文为固定源码快照 c8fb906 的静态阅读，未做车型回放、CAN FD 台架或实车验证。

    解析器与总线边界

    动力和相机解析器的物理总线由 CanBus(CP) 指定，不能把 Bus.pt 恒等为 0。有雷达的 Bosch 平台把动力放在偏移加 1、雷达放在偏移；无雷达或 CAN FD 的 Bosch 与 Nidec 采用另一组映射。HAS_BSM 仅由特定 CR-V 指纹分支动态设置，状态层为此另建 Bus.body 解析器，物理输入使用 CanBus(CP).radar，源码注释说明 B-CAN 要先经 panda 转发——缺少这条物理路径时，软件支持 BSM 字段不等于盲区信息可用。

    三个解析器创建时都没有显式报文列表，cp.vl[...] 第一次读取才动态注册报文。由于 CarInterfaceBase.update() 已先调用 parser 更新，新注册报文在第一轮的值与时间戳初始为零，本轮此前到达的帧不会被它解析；此后 vl 保存最近成功值，不保证本轮有新样本。接口对已注册报文做 can_valid 全路聚合、对总线空窗做 bus_timeout 聚合，但若新硬件要以刹车、车速或盲区作为安全条件，仍需逐信号检查来源、时间戳与采样年龄。

    入口 作用
    CarState.__init__() 按变速箱／平台选择报文与 DBC 枚举，初始化刹车开关、仪表速度与巡航缓存
    CarState.update() 把动力、相机与条件性车身总线信号归一化为 CarState
    CarState.get_can_parsers() 建动力／相机解析器，BSM 车型额外建 body 解析器
    CanBus.__init__() 区分有雷达 Bosch 的动力／雷达交换、纵向模式下的 LKAS 路由与其他平台总线
    update_speed_kf() 对 Honda 已混合的 vEgoRaw 做 KF1D 速度／加速度估计
    create_button_events() 按本轮／上轮按钮值构造按下与释放事件

    速度混合与仪表值锁存

    Honda 先把四轮 WHEEL_SPEEDS 平均并换成 m/s，再用 1 到 6 m/s 的插值权重把变速箱速度与轮速混合；CP.wheelSpeedFactor 在这段代码里只乘变速箱速度项，高车速主要由轮速项决定。混合值进入 KF1D 形成 vEgo/aEgo，而 standstill 单独按变速箱速度小于 1e-5 判断，不能简单用 vEgo 是否为零替代。轮速与变速箱速度矛盾时的物理可信度尚需目标车型回放验证。

    CAR_SPEED.ROUGH_CAR_SPEED_2 首次大于阈值后 dash_speed_seen 永久锁存，之后每轮都把当前解析器缓存经 kph／mph 转换写入 vEgoCluster；在锁存前，基类接口用 vEgo 回退显示速度。台湾 Odyssey 特例不走该字段。状态侧没有单独的仪表速度年龄判据，若报文停发，解析器健康与显示缓存需要分别解读。

    车身、转向与刹车

    车门可来自四门 DOORS_STATUS、SCM_BUTTONS 驾驶门位或 SCM_FEEDBACK 驾驶门位，安全带用警告灯或未锁扣任一条件。自动／CVT 档位通过 DBC 枚举，手动挡只由倒车灯在倒车与前进之间二选一，无法在这里识别空挡或所有换挡中间态。方向灯调用拨杆型 250 次调用保持器；驾驶员转向直接以 STEER_TORQUE_SENSOR 绝对值对车型阈值比较，不使用基类去抖。STEER_STATUS 的 DBC 数值先转字符串，未知值映射 UNKNOWN，永久与临时故障有独立映射：BOSCH_ALT_RADAR 对预期低速锁定给例外，MDX 4G 的 TJA_LOW_SPEED_LOCKOUT 还单独清除故障位。

    有 BOSCH_ALT_BRAKE 时刹车直接读 BRAKE_MODULE.BRAKE_PRESSED；其他车型把 POWERTRAIN_DATA.BRAKE_PRESSED 与刹车开关并联，只有本轮 vl_all 有开关样本时才更新开关状态，单轮有多样本则用倒数第二条作为前值，要求当前和前值都为真。若没有新开关帧，brake_switch_active 保持上次状态；解析器健康是另一层，不应把保留布尔值当成新鲜采样。

    巡航、原车 ADAS 与下游

    POWERTRAIN_DATA.ACC_STATUS 和选定 SCM 报文主开关决定巡航 enabled／available。Bosch 原车纵向的设定速度读 ACC_HUD.CRUISE_SPEED，遇大于 160 的特殊值就沿用 v_cruise_pcm_prev；源码说明设置时可能脉冲到 254／255，252 又表示 standstill。带动态单位的 Bosch 平台才在英制时使用 mph 转换，其他情况按 kph；Nidec 则读 CRUISE.CRUISE_SPEED_PCM。这些特殊值是软件解码规则，不是一般范围检查。

    原车 AEB／FCW 来源也分 Bosch 与 Nidec：Bosch 有雷达且未启用自控纵向时才从动力 ACC_CONTROL 判定原车 AEB；Nidec 从相机 BRAKE_COMMAND 判 AEB／FCW，并保留 ACC_HUD 与刹车字段供控制器构帧；Bosch 无雷达车型另保存相机 LKAS_HUD。这些字段是 parser 的最近缓存引用，CarState 未给每个字段附单独采样年龄，因此不能把有 HUD 字典当作原车 AEB 仍可用的证明。按钮事件来自 SCM_BUTTONS 的巡航／设置字段当前与上次值，下游再由车辆事件层决定取消、启用和故障告警。

    信号类别 来源与处理 版本分支
    车速 四轮均速 + 变速箱速度按 1~6 m/s 插值权重混合，随后 KF1D 台湾 Odyssey 不锁存仪表速度字段
    刹车 直接读 BRAKE_MODULE，或与刹车开关并联并要求连续两样本 BOSCH_ALT_BRAKE 走直读分支
    巡航设定速度 Bosch 读 ACC_HUD.CRUISE_SPEED，Nidec 读 CRUISE.CRUISE_SPEED_PCM 大于 160 特殊值沿用上轮；252 表示 standstill
    原车 AEB Bosch 读 ACC_CONTROL，Nidec 读相机 BRAKE_COMMAND Bosch 无雷达保存 LKAS_HUD
    盲区 BSM 车型经 B-CAN 转发后由 body 解析器读取 HAS_BSM 由特定 CR-V 指纹动态设置

    硬件插件验收

    车型输入插件应为轮速四路、变速箱速度、刹车开关与压下、EPS 故障、巡航、原车 AEB 与 BSM 分别声明物理总线、DBC、采样时戳、年龄、校验／计数器结果和缺测状态。速度融合参数、仪表速度锁存和刹车连续样本门应按车型版本冻结并在回放中量化。无车测试至少覆盖第一轮动态注册、单轮异常、速度来源矛盾、刹车短脉冲与断流、ACC 特殊速度码、未知 EPS 状态、BSM 路由缺失及 Bosch／Nidec 分支，再与安全钩子的独立 RX 判据对照。

    常见问题

    Honda 的车速为什么不是简单的四轮平均？

    因为低速时四轮均速不够可靠。CarState 先求四轮均速并换算为 m/s，再用 1 到 6 m/s 的插值权重把变速箱速度 XMISSION_SPEED 与轮速混合，混合值才进入 KF1D 形成 vEgo/aEgo；CP.wheelSpeedFactor 只乘变速箱速度项，高车速主要由轮速项决定。

    为什么刹车开关需要连续两个样本？

    源码注释指出开关信号可能有单次噪声，且驻车挡未必有效。非 BOSCH_ALT_BRAKE 车型把 POWERTRAIN_DATA.BRAKE_PRESSED 与刹车开关并联，只有本轮有开关样本时才更新状态，单轮多样本用倒数第二条作为前值，并要求当前和前值都为真。

    巡航设定速度出现 254／255／252 是什么意思？

    这是软件解码规则而非一般范围检查。Bosch 原车纵向读 ACC_HUD.CRUISE_SPEED，遇大于 160 的特殊值就沿用 v_cruise_pcm_prev；源码说明设置时可能脉冲到 254／255，而 252 又表示 standstill，因此不能按普通数值范围直接采信。

    解析器聚合通过就代表每个信号都新鲜吗？

    不代表。接口只对已注册报文做 can_valid 聚合、对总线空窗做 bus_timeout 聚合，而 vl 保存的是最近成功值，不保证本轮有新样本；CarState 也未给原车 HUD 等字段附单独采样年龄，因此仍要逐信号核对来源与年龄。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/HONDA_CARSTATE_SPEED_BRAKE_CRUISE_INPUT_DEEP_DIVE.md（取用了 Honda 速度混合、刹车去噪、Bosch／Nidec 巡航分支、BSM 路由与插件验收清单）。
    • 项目 02 —— openpilot-research/CAN_PARSER_HEALTH_DEEP_DIVE.md（仅用于确认解析器健康聚合与总线空窗的语义位置）。

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

    更新记录

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

  • Tesla Model3 CAN 仿真档案：67 条报文与 5 个锚点信号

    结论：这份「车型 CAN 数据档案」的对象是 Tesla Model3 的一台 CANoe / CAPL 仿真工程，不是一台真实车辆：它用三份逆向得来的 DBC（Battery / Thermal / Drive）和一条「电池异常 → 热管理响应 → 扭矩降额」的因果链，在总线上造出约 67 条报文、其中 8 条为核心周期报文。总线为 500 kBaud 经典 CAN、11 位标准帧，另叠加一条 Ethernet / DoIP 诊断通道，CAN 侧用标准 ISO-TP（CanTp）承载 UDS。关键结论——例如硬切断后扭矩以 kHardCutoffTau=0.4s 衰减、集中式架构下 bmsContactorState 稳定在 80.500s——全部来自仿真，不能当作实车测量，也不能外推到其他 Model3 车或年款。

    车辆与适用范围

    源文档是一套围绕仿真节点搭建的工程：三个业务 ECU（Battery / Thermal / Drive）实现核心因果链，一个独立的 SafetyMonitor 节点只监听总线，外加测试驱动与 DoIP 网关/以太网诊断。以下范围只对应这套仿真的内部设定。

    项 内容
    车型 Tesla Model3（仿真建模对象，非实车采集）
    年款 / 市场版本 源文档未确认；DBC 名称仅区分 Battery / Drive / Thermal 三个域
    ECU / 改装状态 仿真态：Battery_ECU、ThermalCtrl_ECU、DriveInverter_ECU、SafetyMonitor_ECU 四个 CAPL 节点
    采集跨度 约 121.5 分钟的四阶段自动化场景（Phase0 正常基线 / Phase1 冷被动 / Phase2 热被动软限 / Phase3 热主动硬切断）
    适用范围 仅限该仿真工程产出的 .asc 日志与其下游分析；不代表真实 Model3 的任何总线行为

    总线与寻址

    总线侧为经典 CAN，叠加以太网诊断扩展。源文档给出的寻址与帧格式信息如下；需要注意，DBC 本身是逆向产物，其对报文周期的标注并不完整。

    项 内容
    物理层 / 比特率 CAN 500 kBaud；另设一条 Ethernet 通道（DoIP / OSEK_TP 节点层 DLL）
    寻址 / 帧格式 经典 CAN；总线负载按 CAN 2.0A 标准帧 47 位开销计算，即 11 位标识符
    CAN FD 源文档未使用 CAN FD；诊断走 CAN 侧 ISO-TP（CanTp）与以太网 DoIP
    报文规模 三份 DBC 去重后共 67 条报文；CAPL 仿真实际周期发送 8 条核心报文
    周期标注完整性 67 条中 45 条没有 GenMsgCycleTime，为原始逆向 DBC 的数据缺口

    已解码信号

    下表抽取源文档中最有代表性的条目。位置一列尽量保留源文档的 ID 与消息名写法；「证据」一列注明来自 DBC、CAPL 设定还是分析脚本的输出口径。凡源文档标注为「未完全根因」或「数据缺口」的，均原样保留。

    信号 位置（ID / 字节域） 解码 证据
    BMSmaxPackTemperature Battery 域锚点信号 电池包最高温度，跨域因果链的温度锚点 anchor_signals.csv；Phase0 拟合归一化
    BMS_maxDischargePower ID252BMS_powerAvailable（十进制 594） 最大放电功率，驱动域软限跟踪的输入 DBC；CAPL 设定
    VCFRONT_coolantFlowBatActual Thermal 域锚点信号 电池冷却液实际流量 anchor_signals.csv
    CMP_speedRPM ID227CMP_state 压缩机转速档位；三级压缩机转速状态机 CAPL 设定；故障注入用例
    DIR_torqueCommand Drive 域锚点信号 驱动扭矩指令；硬切断后按指数衰减到近零 anchor_signals.csv；kHardCutoffTau=0.4s
    BMS_contactorState Battery 域广播 接触器状态；==1 时 Thermal 冻结全部热信号 CAPL 设定；SafetyMonitor Rule 1/5
    ID312BMSthermal 广播 ID312BMSthermal（十进制 786） 电池热报文；被抑制即触发 SafetyMonitor 通信超时 CAPL 设定；故障注入用例
    gFlowRequest Simulink 信号链（1000 ms 周期） 流量请求；延迟/量化行为最高约 1.92s Simulink 验证；已调查未完全根因
    gCompressorRPM Simulink Drive 分支 随机游走驱动的压缩机转速 Stateflow；随机序列复现问题见边界
    gTorqueCommand Simulink Drive 分支 随机游走驱动的扭矩指令 Stateflow；同上
    targetPower（稳态） Simulink 两架构对照 稳态目标功率，两架构均为 40.0000 Verify_key_metrics.m 校验
    HardCutoff.Opening 时长 状态机（Battery_ECU） 硬切断 OPENING→OPEN 过渡，精确 200ms CAPL 设定；Simulink 复核
    UDS 0x22 ReadDataByIdentifier Battery_ECU 诊断栈 5 个 DID，含两个由其他 ECU 拥有的网关式 DID（被动缓存） CAPL；UDS_DiagnosticsTest 14 个检查点
    UDS 0x19 / 0x14 与 0x7F Battery_ECU 诊断栈 读/清 DTC（子功能 0x02/0x04）；7 种否定响应场景 CAPL；Freeze Frame 用例

    读取方法与注意事项

    解析链以 cantools 为基础。源文档明确：默认采用流式解析以适配大日志，小于 200 MB 时才用 --in-memory；解码后的长表可再重采样到 100ms 均匀网格，但真实逐帧时间戳只在长表里，做周期核验必须用长表而非重采样结果。引用因果滞后结论时，源文档要求只引用 causal_lag_analysis_HIGH_CONFIDENCE_ONLY.csv。

    数据完整性有专门的检查脚本，给出三种判定：CLEAN（可直接使用）、ISOLATED, LIKELY OK（不超过 5 个孤立点，建议抽查）、CORRUPTED（存在大段连续异常，不可直接使用）。源文档建议在 LSTM 训练或引用因果滞后结论之前先跑这一检查，用于识别已知的 CAPL/CANoe 信号解码缺陷是否复现。

    异常检测模块有一处容易踩的坑：训练与评估的 --val-fraction、--block-size、--seed 必须完全一致，否则 Phase0 基线会落在模型已训练过的窗口上，静默低估基线误差。归一化只在 Phase0 上拟合，以避免把异常期统计量泄漏进「正常」基线。总线负载侧，长表须先按 (timestamp_s, frame_id) 去重，否则到达帧会被按信号重复计数，严重高估发送频率。

    时延分析脚本不接收命令行参数，输入文件名固定为 CAN.asc 与 Eth.asc；它以两个文件各自的时间戳相减来定义时延，而不是信任 UDP 载荷内的 Timestamp 字段（后者存在约 0.5ms 的整毫秒截断偏置）。匹配采用精确 RawValue 相等、平分时取最近在前的策略，源文档明确这是尽力而为、不保证唯一的匹配。

    证据等级与边界

    本档案的全部信号都是仿真观测，没有任何实车旁证。DBC 是逆向结果，45/67 条报文缺少周期标注，因此总线负载只能给出「未填充下界」与「+20% 填充上界」两个口径，30%/50% 也只是业界经验阈值、非强制标准。Simulink 侧两架构对照给出确定性结论：集中式架构的 bmsContactorState 在 11 次重复仿真中稳定到达 80.500s（零方差），分布式架构则落在 0–110ms、10ms 栅格的延迟窗内，且在受控变量测试下确认延迟来自接收域自身采样节拍。

    已知缺陷必须原样保留。其一，Battery_ECU.can 内部使用了两个互不同步的 100ms 定时器，CAPL 不定义其相对触发顺序，在窄时序巧合下会令 SafetyMonitor 的 Rule 1 在模拟上电复位后短暂重触发，源文档将其记为未修复的开放问题（低优先级、影响面窄），根因已分析但未获得带时间戳的证据确认。其二，Simulink 中 Stateflow 的随机游走函数在独立 sim() 调用间复现同一随机序列，机制未定位，只影响随机游走驱动信号，不影响上述确定性结论。其三，1000ms 周期的 gFlowRequest 链出现最高约 1.92s 的延迟/量化，与其余信号的 0–110ms 模式不一致，已调查但未完全根因、被降级搁置。

    不能外推的部分：本文所有数值限定在这套仿真的设定与日志；40.0000、200ms、80.500s 等均属工程参数，不构成对任何真实 Model3 的描述。源文档未提供对车辆安全机制的绕过方法，且不建议尝试；本文只讨论仿真工程的公开文档。

    常见问题

    这是不是一台真实 Model3 的数据？

    不是。它是 CANoe/CAPL 仿真工程：三个业务 ECU 加一个独立监听节点，用逆向 DBC 复现「电池异常 → 热响应 → 扭矩降额」的因果链。所有信号与节拍都来自仿真设定，源文档未包含任何实车采集。

    为什么 67 条报文里只有 8 条能算总线负载？

    因为逆向 DBC 中 45 条报文没有 GenMsgCycleTime，且核心 8 条里还有两条在 DBC 里根本没有周期。源文档的做法是以 CAPL 的 setTimer() 调用作为周期的唯一真实来源，并逐行标注对应的 CAPL 源码位置以便追溯。

    引用因果滞后结论时要注意什么？

    源文档要求只引用 HIGH_CONFIDENCE_ONLY 的结果文件，并在引用前先跑数据完整性检查以排除已知的解码缺陷；LSTM 训练/评估的 val-fraction、block-size、seed 必须一致，否则基线会被静默低估。峰值与时长在本数据集中还存在部分混淆。

    SafetyMonitor 的 Rule 1 为什么会误触发？

    因为 Battery_ECU.can 内部两个不同步的 100ms 定时器相对顺序未定义，在窄时序巧合下会在模拟上电复位后短暂重触发。源文档标记为开放且未修复，根因已分析但未经带时间戳的证据确认，影响面窄。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/model3-can-simulation/README.md（本项目车型档案主来源：节点与因果链、DBC 与锚点信号、总线负载、时延分析与 Simulink 对照）。

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

    更新记录

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

  • 2014 丰田 Yaris Hybrid XP130 的 CAN 信号地图

    结论：这份档案记录的是 2014 款丰田 Yaris Hybrid（第 3 代 XP130，THS-II NoDSU）的 CAN 信号逆向成果：从车机 28 针连接器的第 9/10 脚（500 kbit/s）被动监听，而不是 OBD-II 口，已确认 12 个与仪表相关的信号（车速、转速、挡位、油门、刹车、转向灯、里程、环境温度、混动电池 SOC、EV 行驶位、CHG/ECO/PWR 指针）。关键结论是混动电池 SOC 与 EV 状态是普通广播，不需要主动诊断轮询。但 HV 电池电流/电压与剩余续航经确认不在总线上。下列结论仅限源文档记录的这一台车，不能外推到其他配置、年款或市场版本。

    车辆与适用范围

    源文档是一个「用逆向出的 CAN 数据驱动自制数字仪表」的项目，主线工作是信号逆向，附带完整的方法学与交叉验证记录。信号只有在两段独立的实车行驶日志上都能复现，才被标记为「confirmed」。

    项 内容
    车型 Toyota Yaris Hybrid（第 3 代 / XP130，THS-II NoDSU），2014 年
    年款 / 市场版本 2014；源文档未给出市场版本
    采集点 原厂车机 28 针连接器（p/n 90980-12555），第 9 脚 CAN-H / 第 10 脚 CAN-L，500 kbit/s，不是 OBD-II 诊断口
    采集跨度 两段独立实车日志：session_0044.log（约 430s）与 session_0047.log（约 440s）
    适用范围 仅限这一台 Yaris Hybrid；源文档说明映射可能不适用于其他配置/市场/年款

    总线与寻址

    文档把车机连接器视为干线高速 CAN（HS-CAN）的同一逻辑总线，理由是它看到的报文集合（SPEED、RPM、GEAR、BRAKE、TURN_SIGNALS、ODOMETER 等）与预期一致。这也正是后装第三方 CAN 盒通常接入的位置。

    项 内容
    物理层 车机连接器 CAN-H/CAN-L 双线，500 kbit/s
    链路层 / 比特率 500 kbit/s（源文档明示）
    寻址方式 报文为 11 位标准 ID（如 0x0B4、0x1C4、0x4A7 等）
    CAN FD 源文档未提及 CAN FD
    读取方式 ESP32 被动监听（TWAI_MODE_LISTEN_ONLY，不发送、不应答）

    已解码信号

    下表合并源文档的两张清单：前 12 行为两段日志都复现的「confirmed」信号，后 5 行为语义成立但精确标度未最终确认的「strong hypotheses」。置信度标注原样保留。

    信号 ID / 字段 解码 证据 / 置信度
    车速 0x0B4 / SPEED (byte5 << 8 | byte6) * 0.01 km/h 两段日志复现；与里程/其他 3 个速度字段一致（≤0.5%）
    发动机转速 0x1C4 / RPM 有符号 16 位 * 0.78125 rpm 两段日志复现（0→60→0 与怠速/轰油）
    挡位 P/R/N/D/B 0x127 / GEAR 4 位枚举，byte5 高半字节 五个状态全部观测到
    油门踏板 0x245 / GAS_PEDAL byte2 * 0.005（0–1 对应 0–100%） 两段日志复现（观测 0–35%）
    ICE 运行位 0x245 / ICE_RUNNING byte3 bit4 与 RPM>50 一致率 98–99%
    刹车按下位 0x230 / BRAKE_PRESSED 单个 bit 与换挡、车速变化对得上
    转向灯 0x614 / TURN_SIGNALS 2 位枚举 + 双闪位 左/右/无三态均观测到
    总里程 0x611 / ODOMETER 20 位，含 km/miles 单位位 确认为总里程（99552→99555 km），非续航
    环境温度 0x442 / AMBIENT_TEMP byte0 – 40 = °C 两天实测 37 °C / 27 °C 对照确认
    混动电池 SOC 0x4A7 / BATTERY_SOC byte2 * 0.5 = % 观测 54.0–71.5%，符合 THS-II NiMH 工作带；标度沿用 Toyota/Techstream 惯例，未与参考工具读数核对
    EV 行驶位 0x498 / EV_DRIVE byte5 bit7 与「行驶中且 ICE 停机」100% 一致
    CHG/ECO/PWR 指针 0x247 / HSI_VALUE + HSI_ZONE byte1 为量程百分比；符号取自 HSI_ZONE zone/value 相关性 n=32779、零例外
    刹车踏板（模拟量） 0x224 / BRAKE_VALUE 16 位，与刹车位强相关 假设：中位 0（松开）对 62（按下）；单位与量程未确认
    冷却液温度 0x618 / TEMP_RAW byte3；猜测量程 * 0.375 假设：暖机曲线合理，无参考温度计标定
    第二温度（机油/CVT/电池包？） 0x3B9 / TEMP2_RAW byte0，约 1 Hz 假设：与时间/冷却液强相关（r≈0.95）；量纲未提
    纵向加速度/扭矩需求 0x320 / ACCEL_DEMAND 有符号 byte4，约 20 Hz 假设：加速正、制动/滑行负、稳态≈0；标度未确认
    燃油消耗计数器 0x3A0 / FUEL_COUNTER_RAW byte7，10 Hz 假设：随 ICE 运行递减，不是油位表；疑为更宽寄存器的低位字节

    读取方法与注意事项

    源文档的全部信号都靠被动监听获得，固件以 TWAI_MODE_LISTEN_ONLY 运行，不向车辆发送任何报文。判定的门槛是「两段独立日志都复现」才算 confirmed；单段日志里的现象只进「假设」或「排除」清单。

    CHG/ECO/PWR 指针有一个容易踩的坑：符号位住在 HSI_ZONE（byte0），不在 HSI_VALUE（byte1）里。CHG 侧 byte1 用二进制补码并在 -100 处钳位，ECO/PWR 侧用无符号幅值且在全油门时会扫过 155，两侧原始范围重叠。早期固件只凭 byte1 判断符号，结果全油门的强 PWR 被误读成强 CHG，上车实测确认后改为按 HSI_ZONE 分支。此外 PWR 侧显示做了对折（PWR% = raw/2），因为 ECO/PWR 分界只是真实量程的中点而非顶点。

    车速不做修正是有意为之：SPEED 是真实车速，里程、GPS 与总线上另外 3 个速度字段都对它。仪表自身的指针读数偏高（含法规性偏置，UNECE R39 要求指示值不得低于真值，上限 10% + 4 km/h），而这个偏置值只在仪表内部计算、不上总线。

    证据等级与边界

    证据分三层。第一层是实车观测：12 个 confirmed 信号来自两段真实行驶日志；速度刻度还用里程绝对锚定（整公里区间积分误差 +0.01%，方法自身不确定度 ±0.82%）。第二层是外部旁证：速度/转速等沿用公开参考 DBC（跨 Prius/Camry/Highlander 变体核对），SOC 的 0.5%/bit 标度沿用已知的 Toyota/Techstream 惯例。第三层是推测：冷却液、第二温度、加速度与燃油计数器的量纲都属猜测。

    两处不能外推。第一，所有映射来自单一车辆，源文档明确「可能不适用于其他配置/市场/年款」；CHG/PWR 的 zone 编码尤其如此——文档记录后来一次实车硬加速还出现了 8、9、14 三个日志中没有的 zone，说明 4/6/12/15 对这批日志穷尽、对整车并不完整。第二，剩余续航与 HV 电池电流/电压/温度经确认不在本总线上，只能靠对电池 ECU 的主动 UDS 请求，源文档未提供任何绕过安全访问的方法，且不建议尝试。

    常见问题

    Yaris Hybrid 的 OBD 口能读到这些信号吗？

    源文档没有用 OBD-II 口，而是从车机 28 针连接器的第 9/10 脚取数。这正是后装 CAN 盒通常接入的位置，文档据此把它当作同一逻辑总线处理。

    混动电池 SOC 是主动问出来的吗？

    不是。SOC 在 0x4A7 的 byte2 上被动广播，EV 行驶位、ICE 运行位同样是广播；仅靠被动监听就能重建后装盒子的能量流显示。HV 电池电流/电压/温度则确认不在总线上。

    车速显示和真实车速差多少？

    源文档记录：在仪表指示 140 时真值约 130，差值约 +10 km/h（单次指针读数，可视为 +5~+15）。这是法规性偏置，不是解码错误；固件有意不做修正。

    为什么全油门时功率条会翻到 CHG？

    因为符号取自 HSI_ZONE 而非 byte1。只凭 byte1 判断时，PWR 侧扫过 155 会被误读成大负值。按 zone 分支后即可修正。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/fellettigiacomo-yaris-xp130/re/docs/signal_findings.md（本项目车型档案主来源：完整方法学与验证证据）。
    • 项目 01 —— public-can-dbc-datasets/additional/fellettigiacomo-yaris-xp130/re/docs/decoded_signals_summary.md（已确认/假设/排除信号的快速参考表）。
    • 项目 01 —— public-can-dbc-datasets/additional/fellettigiacomo-yaris-xp130/README.md（项目背景、硬件与被动监听安全说明）。

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

    更新记录

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