星核火花赛车科技

标签： 车型协议

  • KTM TBI mapswitch：31 条 BO_ 里只有 4 条真实帧

    结论：这份 KTM TBI mapswitch 的 DBC 有 31 条 BO_ 报文与 36 条 SG_ 信号，但其中只有 0x6DA、0x6DB、0x4C0、0x4C1 四条是真正的 CAN 广播或地图按键 / 命令帧；其余 27 条把 UDS 的 DID、IOID、RID 当作伪 CAN ID，用来描述响应载荷。配套的车型矩阵则把 TBI（2024 年起）与两代 TPI 的 27 项能力分成三档。

    31 条报文里只有 4 条是真实总线帧

    这是使用这份 DBC 前必须先看清的一点。归档说明按文件自身的头部描述作了分类：只有四条条目属于 CAN 广播或地图按键 / 命令流量，其余 27 条用的是 UDS 诊断标识符（DID、IOID、RID）充当伪 CAN ID，目的是描述请求之后的响应数据结构。

    条目性质 数量 标识示例 能不能当总线报文监听
    真实 CAN 广播或按键 / 命令帧 4 0x6DA、0x6DB、0x4C0、0x4C1 能，可直接按 ID 过滤与解析
    UDS DID / IOID / RID 伪 ID 27 文件头声明为响应载荷描述 不能，需先发起请求再解析响应

    UDS 传输层本身使用请求 0x7E0、响应 0x7E8。也就是说，那 27 条「报文」在总线上并不会以该 ID 出现；把它们当普通帧去过滤，结果必然是永远收不到。正确用法是先按 0x7E0 发诊断请求，再按 DBC 里对应伪 ID 的定义去解 0x7E8 回来的载荷。

    另外两个兼容性问题也要提前处理：部分伪报文声明的载荷长度超过 8 字节（其中包含 96 字节的条目），而源文件带有 // 注释——严格的 DBC 解析器可能需要预处理才能读入。

    三代车型的 27 项能力分档

    项目面向 KTM、Husqvarna 与 GasGas 三个品牌的摩托车，车型矩阵把能力分成「骑行模式」与「诊断」两大组，横跨 TBI（2024 年起）、TPI（2020–2023）、TPI（2018–2019）三代。这份 DBC 明确以 KTM TBI 的 ECU 命名，来源并未为每个定义确立具体车型、排量或固件版本。

    能力 TBI（2024+） TPI（2020–2023） TPI（2018–2019）
    按键切换地图 支持 不支持 不支持
    按键清除 ECU 故障 支持 支持 支持
    RaceChrono 遥测 支持 支持 支持
    显示当前地图 支持 支持 不支持
    按模式统计摩托小时（油门、转速） 支持 不支持 不支持
    动力阀开度百分比 支持 不支持 不支持
    大气压力（MAP，大气） 支持 支持 不支持
    TPS 电压与开启角度 支持 不支持 不支持
    TPS 开启百分比 不支持 支持 支持
    运输锁状态 / 翻车传感器 / 机油泵回路 支持 不支持 不支持

    把这张表读成决策依据，可以归纳出三条：第一，按键切换地图是 TBI 独有能力，两代 TPI 都做不到；第二，TBI 独有项共 8 项（按键切地图、按模式小时计、动力阀开度、TPS 电压、TPS 角度、运输锁、翻车传感器、机油泵回路），这些是 TBI 平台新增诊断能力的全部；第三，TPI 2018–2019 相比 2020–2023 只少了显示当前地图与大气压力两项。

    还有一处反向差异值得注意：TPS 的表示方式在三代之间不兼容——TBI 给电压与角度，两代 TPI 只给百分比。做跨代统一解析时，TPS 必须按代分别处理。

    三档之外，按键清除故障、冷机指示、过热指示、保养间隔指示、故障灯指示、RaceChrono 遥测、总摩托小时、发动机转速、水温、进气温度、进气压力、点火提前角、电池电压、读取当前与存储故障、清除故障这些项目在三代上全部支持，可以视为这套装置的能力基线。

    把分档结果与项目命名放在一起看，能得出一条实用的选型判断：这套装置以 KTM TBI 命名，而矩阵显示按键切换地图仅在 TBI（2024 年起）这一档可用，两代 TPI 均不支持。因此面对 TPI 车型时，可用能力退化到上述基线加上显示当前地图（仅 2020–2023）、大气压力（仅 2020–2023）与 TPS 百分比，不能照搬 TBI 的功能清单。

    常见问题

    31 条 BO_ 里有多少是真实的总线报文？

    只有 4 条，即 0x6DA、0x6DB、0x4C0 与 0x4C1，属于 CAN 广播或地图按键 / 命令流量。其余 27 条按文件头的声明，是用 UDS 的 DID、IOID、RID 值充当伪 CAN ID 来描述响应载荷，总线上并不会以这些 ID 出现。

    UDS 请求与响应用的是什么 CAN ID？

    请求为 0x7E0、响应为 0x7E8。那 27 条伪 ID 报文描述的正是响应里的数据结构，因此正确流程是先向 0x7E0 发起诊断请求，再按 DBC 中对应伪 ID 的定义解析 0x7E8 返回的内容，而不是直接按伪 ID 去过滤总线。

    TPI 2018–2019 相比 2020–2023 少了什么？

    在 27 项能力矩阵里只少两项：显示当前地图与大气压力（MAP，大气）。其余项目中，按键清除故障、冷机与过热指示、保养间隔、故障灯、RaceChrono 遥测、总小时、转速、水温、进气温度、进气压力、点火提前角、电池电压、TPS 百分比、故障读取与清除等在这两代上均为支持。

    为什么这份 DBC 在严格的解析器里可能报错？

    有两个原因。一是部分伪报文声明的载荷长度超过 8 字节，其中包含 96 字节的条目，超出经典 CAN 单帧能力；二是源文件带有 // 注释。因此严格的 DBC 解析器可能需要先做预处理（剥离注释、处理超长载荷）才能读入。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/psamoilov-ktm-tbi-mapswitch/SOURCE.md（31 条 BO_ 与 36 条 SG_、4 条真实帧与 27 条伪 ID、UDS 0x7E0/0x7E8、超长载荷与注释问题、权利状态）
    • 项目 01 —— public-can-dbc-datasets/additional/psamoilov-ktm-tbi-mapswitch/models.md（TBI 2024+ 与两代 TPI 的 27 项能力矩阵）

    免责声明

    本文内容整理自公开开源项目，属社区逆向工程产物，不代表 KTM、Husqvarna 或 GasGas 的官方数据。来源未为每个定义确立具体车型、排量或固件版本，信号与车型适配未经独立抓包验证。检查的目录树中未找到仓库许可证或逐文件的再分发授权，相关材料应作为私有离线研究副本，在权利确认前不得再分发或集成。

    更新记录

    • 2026-10-14 初稿

  • LiveWire S2 Del Mar：60 报文副总线与 9 个 UDS 模块

    结论：2024 LiveWire S2 Del Mar 的公开 CAN 资料给出了两件东西，用途完全不同：副总线的广播 .dbc（60 条报文、111 个信号）和一份跨 9 个诊断模块的 UDS DID 目录。转速、车速这类实时量直接从广播拿；电池单体电压、ABS 轮速、绝缘电阻这类不广播的数据，必须走 BCM 网关用 0x22 读——把它们混为一谈是初学者最常见的错。

    总线事实：先记这四条

    这份社区资料把前置条件写得非常干净，接入之前四条必须对齐。

    维度 取值 错配后果
    速率与类型 500 kbit/s，classical CAN，11 位标准 ID 按 CAN FD 或扩展帧配置时完全解不出帧
    字节序 big-endian，Motorola 起始位记作 @0 多字节信号反向拼接，数值量级明显偏大
    保护机制 约 36 个 ID 带 E2E 保护（AUTOSAR Profile-1 风格） 自定义解析时未跳过校验字节，信号整体错位
    拓扑 副总线上只有 BCM、IM、TCU、DLC；电机、BMS、ABS 在主总线 在副总线上找电机转速，永远找不到

    第三条 E2E 保护值得单独说：D7 是 6 位 alive counter，D8 是覆盖 D1 到 D7 的 CRC-8 / SAE-J1850（多项式 0x1D，初值与异或输出均为 0xFF）。它的价值不在于安全，而在于充当解码预言机——位对齐一旦算错，CRC 立即失败，不需要等到物理量不合理才发现问题。这是逆向过程中极少数可以机器判定对错的抓手。

    九个模块各管什么

    副总线的广播成员是 BCM（网关）、IM（仪表）、TCU、DLC 四个，其余全部在主总线上，通过 BCM 网关用 ISO-TP 上的 0x22 ReadDataByIdentifier 读取。下面这张表是挑选 UDS 模块时的直接依据。

    模块 请求与响应 ID 角色 能拿到的关键数据
    BCM 0x7E2 → 0x7EA 车身控制器，副总线网关 纵向加速度 ADC 快照、内部 mV 电源轨、时间同步、骑行模式配置表、防盗与钥匙块
    VSC 0x7E4 → 0x7EC 车辆监控控制器，监管 ABS 与 IMU 实时电机转速与驱动状态、扭矩记录、油门位置、电池包端电压、当前骑行模式序号及逐模式标定三元组
    RESS 0x7E6 → 0x7EE 高压电池管理，信息价值最高的模块 逐单体电压阵列、逐单体温度阵列、包电流双传感 A/B、SoC/SoE/SoH、累计安时
    EHCU 0x7E7 → 0x7EF Bosch ABS 液压单元 双路逐轮轮速、前制动压力、制动激活标志、12 V 辅助电源轨、ABS 事件计数器
    OBC / HV 0x7D3 → 0x7DB 车载充电机，交流充电时才活跃 充电器与枪状态、充电电流与功率、充电机散热片温度、母线电压
    TCU 0x7D4 → 0x7DC 远程通信，含 eSIM 与 GPS，隐私敏感 GPS 位置、信号强度、归属网络、固件版本

    表里没有列的还有 LHCM（0x7E3，识别信息与硬件件号，同时携带 VIN）、RHCM（0x7E5，制动激活标志与内部参考电源轨）、以及一个 ID-only ECU（0x7F0 → 0x7F8，只有供应商件号、没有任何实时数据块，属于硬上限）。

    需要注意的是，9 个已映射响应者是下限而不是总数。资料明确提到存在一个未映射的响应方（响应 0x6E6 / 请求 0x6DE）被被动观察到，另有目标地址 0x7F2；并且 IMU 本身没有 UDS 地址，它由 VSC 监管。这意味着你在总线上看到的地址比这张表多，是预期行为。

    读懂它的置信度标注

    这份资料最值得模仿的不是结论，而是它把不确定性强塞进数据结构里：每条信号的行内注释都带四类信息——置信度、标定依据、已撤回的假设与尚未解决的疑问。[CONFIRMED]（两种以上方式交叉验证）、[STRONG]（一次干净抓包且物理一致）、[TENTATIVE]（数据不足）。已撤回的假设会原样保留而不是删除，避免后来者重复尝试同一条死路。

    这套标注的实际用法：写解析代码时，只对 [CONFIRMED] 与 [STRONG] 做断言和告警，[TENTATIVE] 一律只记录不做判断。把三级标注 flatten 成一个 schema，等于把作者的证据强度信息彻底丢弃。

    它的取证方法也相当严格：单人单次动作隔离抓包 + 差分分析；一次相关只构成假设，必须有第二次「专门设计来推翻它」的抓包失败才算成立；未被动作覆盖的字节标记为未解，而不是当作常量写死。这套流程解释了为什么 111 个信号里真正能用作线上判据的比例并不高——大量位置至今没有足够证据。

    三条使用边界

    第一，0x27 SecurityAccess 门禁：BCM、VSC、TCU 上有 16 个 DID 被上锁，种子为 128 位随机数，其内容是按相邻关系推测的，不是读出来的。任何把推测值当成实测值的下游都会出错。第二，隐私：车主 PII 在这份公开副本中被抽掉，VIN、模块序列号、GPS 坐标与 SIM 标识都变成占位符，但结构完整，复现时必须自己填自己的值。第三，版本状态：整体标注为 v0.1 进行中，TENTATIVE 条目可能错误或不完整；并且它只描述如何读取与理解总线，不含任何执行动作的方法。

    常见问题

    电机转速和电池单体电压能不能直接从副总线广播里读？

    不能。副总线上的广播成员只有 BCM、IM、TCU、DLC 四个，电机/逆变器、电池、ABS、充电机、远程通信都在主总线上，需要通过 BCM 网关用 ISO-TP 上的 0x22 ReadDataByIdentifier 主动读取。能直接广播读到的只有广播成员的那些信号。

    E2E 的 CRC 除了校验还有什么用？

    它是逆向时的位对齐预言机。约 36 个 ID 采用 AUTOSAR Profile-1 风格保护，D7 为 6 位 alive counter，D8 为覆盖 D1 到 D7 的 CRC-8 / SAE-J1850，多项式 0x1D、初值与异或输出 0xFF。只要起始位或长度算错，CRC 立即失败，可以在物理量失真之前发现错位。

    已映射的 9 个模块是不是这辆车的全部 ECU？

    不是，作者明确写这是一个下限。被动观察到的还有一个未映射响应方（响应 0x6E6、请求 0x6DE）以及目标地址 0x7F2；IMU 没有自己的 UDS 地址，由 VSC 监管。也就是说实际地址数会多于这 9 个。

    为什么有些 DID 的内容看起来是「猜」出来的？

    因为 BCM、VSC、TCU 上有 16 个 DID 被 0x27 SecurityAccess 上锁，种子是 128 位随机数，作者无法读取其值，只能按相邻关系推测其含义。使用这类字段时必须标注为推测值，不能参与任何判定逻辑。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/inklit-livewire-s2-delmar/README.md（500 kbit/s、11 位 ID、Motorola @0、约 36 个 ID 的 E2E 与 CRC-8 参数、60 报文 111 信号、9 个 UDS 模块、CONFIRMED/STRONG/TENTATIVE 标注体系、取证方法论、CC BY 4.0 授权）
    • 项目 01 —— public-can-dbc-datasets/additional/inklit-livewire-s2-delmar/MODULES.md（九个诊断模块的请求与响应 ID、角色与关键数据；9 为下限的说明、0x27 上锁 16 个 DID、IMU 无 UDS 地址、PII 抽除说明）

    免责声明

    本文所述总线参数、模块地址与信号数量均来自社区公开整理的说明文件，属第三方逆向工程产物，未独立实车验证，也不代表 LiveWire 或任何制造商的官方数据。不同年份、市场与固件版本的 ECU 可能存在差异。涉及 0x27 安全访问的字段为作者推测值。任何改动请以实际测量与官方资料为准，操作在用车存在风险。

    更新记录

    • 2026-10-14 初稿

  • PSA 架构逆向：94 份报文 YAML 与 DBMUXEv 格式

    结论：PSA-RE 不是 DBC 集合，而是一套自研的 DBMUXEv 描述格式：归档快照含 94 份总线报文 YAML、110 份车型映射文件，覆盖 AEE2001（VAN）、AEE2004（第一代 FullCAN）与 AEE2010 三代架构。它不用 DBC 的原因很具体——需要同时描述多个世代，而每个世代又包含多条网络，DBC 这种单网络格式装不下。

    为什么放弃 DBC：单网络格式的边界

    DBMUXE 格式的规范文档写明了动机：现有格式（包括 Vector 的 DBCan）无法满足需求，因为要描述多代设计，而每代设计又包含多条网络。格式名本身也是线索——DBMUX 取自 PSA 内部用于描述多路复用网络的软件名，后缀 ev 在 PSA 语境里常表示某个事物的演进版本。

    维度 DBC（DBCan） DBMUXEv
    组织单位 单一网络上的报文与信号 architecture、variant、network、bus、node 逐层嵌套
    多世代设计 需拆成多份彼此无关的文件 按目录分层；跨架构相同的报文只写一份，其余用符号链接
    诊断数据 不在格式范围内 同级 diag 目录下有 dids、dtcs、resets、routines 四类
    协议覆盖 主要面向 CAN 面向多种车载网络，规范仍列为待完成项的有 LIN、KWP2k、K-lines、PSA2k
    语言 单一语言 按 ISO 两字母码扩展，示例仅设置 en 与 fr
    转出工业格式 即用 规范 TODO 中：需编写生成器解析 YAML 产出 DBC、ODX

    代价也很清楚：这套格式目前没有官方工具链，想把它喂给 SavvyCAN 或 CANoe，要先自己写生成器。仓库 README 的求助清单里，「编写生成器把 YAML 转成 DBC、ODX 等工业标准格式」被列为最需要的贡献之一。

    目录结构即数据模型

    规范给出的目录树基本等同于它的概念模型：architecture 是一组设计模板的名字（如 AEE2004），variant 是其衍生版本；network 是共享节点的一组总线，bus 是节点之间的物理链路（可以是 CAN，也可以是 LIN）；node 是挂在一或多条总线上的控制器；protocol 是在总线上发送数据的协议；message 是总线上的一帧；signal 是帧里的一个数据点。

    路径 存放内容 作用
    architectures.yml 架构定义 整个数据集的顶层索引
    cars/{id}.yml 车型到架构的映射 把具体车型挂到一或多个架构上
    nodes/{architecture}.{variant}.yml 节点定义 描述该架构变体下有哪些 ECU
    buses/{architecture}.{variant}/{network}.{bus}/{message}.yml 单帧报文 一帧一个文件，是快照里 94 份报文文件的所在
    diag/{architecture}.{variant}/{node}/ dids、dtcs、resets、routines 诊断侧数据，与总线报文分列

    命名上用点号 . 作分隔符，需要时嵌套。跨架构复用有一条明确规则：若某条报文在多个架构（及其版本）中完全相同，只在第一个实现它的架构的最相关版本里描述一次，其余位置创建符号链接。这条规则让 94 份报文文件能覆盖远多于 94 个「车型 × 总线」组合。

    车型命名规则：第二位数字是车身

    仓库单独写了一份车型命名说明。规则是：一个字母加一个数字构成基础车型，后面可能跟第二个数字表示车身形式。

    第二位数字 车身形式
    0 3 门
    1 5 门
    2 SW / Break（旅行版）
    3 4 门
    4 休闲车 / MPV / 大型多功能
    5 Coupe
    6 Coupe / Cabriolet（敞篷）
    7 Cabriolet（敞篷）
    8 Monospace / Minispace
    9 （小型）多功能 / 商用

    另外说明提到改款通常（但不总是）把第一个数字加 1。这条规则的价值在于把 110 份车型映射文件变成可推导的体系：看到车型代号就能预判它挂在哪个架构上，而不必逐份打开文件。

    证据边界：覆盖率与安全内容的取舍

    归档说明给出的边界必须先看。上游 README 声称理论上覆盖 1993 年雪铁龙 XM（首款使用 VAN 的车）到 2020 年代初的标致、雪铁龙与 DS，并说明 2022/2023 年起的新架构尚不清楚；但快照里的报文文件实际位于 AEE2001/CONF 与 AEE2004.full 的 HS.IS 或 LS.CONF 之下，也就是说 README 的车型覆盖表述并不能证明每个车型或信号都已收录。

    上游 107 份总线 YAML 中含有防盗或安全访问相关术语的 13 份被刻意剔除，未纳入本次归档。仓库声明 Apache-2.0 并保留 LICENCE，但 README 同时警告数据可能有误，并承认部分材料来自无法追溯的泄露，因此原始数据权利并未完全确立。留存的报文仍需要与被动抓包做独立的适配性与缩放核对。

    常见问题

    PSA-RE 里为什么没有 DBC 文件？

    因为它用的是自研的 DBMUXEv 格式。规范文档写明动机：现有格式（包括 Vector 的 DBCan）无法描述多代设计，而每代设计又包含多条网络。该项目用 YAML 按 architectures、cars、nodes、buses、diag 分层组织，把 YAML 转成 DBC 需要另外编写生成器，这一点被列在仓库的求助清单里。

    94 份报文 YAML 覆盖了哪些架构？

    项目目标是 PSA 的 AEE2001（VAN 架构）、AEE2004（第一代 FullCAN 架构）与 AEE2010（2010 年至约 2020 年的车型）三代。但本快照的报文文件实际位于 AEE2001/CONF 与 AEE2004.full 的 HS.IS 或 LS.CONF 之下，README 中关于覆盖 1993 年至 2020 年代初的宽泛表述并不能证明每个车型或信号都已收录。

    车型文件的命名规则是什么？

    规则是一个字母加一个数字构成基础车型，后面可跟第二个数字表示车身形式：0 为 3 门、1 为 5 门、2 为旅行版、3 为 4 门、4 为休闲车或 MPV、5 为 Coupe、6 为 Coupe 或敞篷、7 为敞篷、8 为 Monospace、9 为小型多功能车。此外改款通常（但不总是）把第一个数字加 1。

    为什么收录时刻意剔除了 13 份报文文件？

    因为上游 107 份总线 YAML 中含有防盗或安全访问相关术语的 13 份被判定为不宜纳入，未进入本次归档。同时仓库 README 警告数据可能有误，并承认部分材料来自无法追溯的泄露，原始数据权利未完全确立，因此留存报文仍需与被动抓包做独立的适配性与缩放核对。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/prototux-psa-re/README.md（项目目标、AEE2001/AEE2004/AEE2010 架构范围、覆盖声明与免责警告）
    • 项目 01 —— public-can-dbc-datasets/additional/prototux-psa-re/dbmuxev/doc/README.md（DBMUXEv v0.1 规范：术语定义、目录结构、符号链接复用规则与待完成项）
    • 项目 01 —— public-can-dbc-datasets/additional/prototux-psa-re/cars/README.md（PSA 车型代号命名规则与车身形式编码）
    • 项目 01 —— public-can-dbc-datasets/additional/prototux-psa-re/SOURCE.md（94 份报文文件、110 份车型映射、13 份剔除说明与权利状态）

    免责声明

    本文内容整理自公开开源仓库，属社区逆向工程成果，不代表标致、雪铁龙或 DS 的官方数据。原仓库明确警告信息可能不正确，且部分材料来源无法追溯，权利未完全确立。留存报文未经独立抓包验证，不同车型、年款与 ECU 版本可能存在差异，应以实际测量与官方资料为准。

    更新记录

    • 2026-10-14 初稿

  • DBC 规范索引：8 段关键字与 7 份可下载文件

    结论：nberlette-canbus 这个仓库的价值不在报文数量，而在它把 DBC 规范拆成 8 个可查段落并挂出 7 份可直接下载的 DBC。真正该先核对的是版本与来源：7 份里两份（Mazda 2017、Lexus RX350）版本栏是「–」，另外五份才有版本号；同目录的 license.md 是许可证文本，不是技术素材。

    DBC 是什么：一份把广播翻译成信号的字典

    CAN 总线上，每个控制器节点把自己所有数据广播出去，由监听节点自行过滤出需要的流量。原始报文对人不可读，因此由 Vector GmbH 发展出一种半标准化格式，把传感器与模块的原始值翻译成带名称和单位的可读量——这就是 .dbc。仓库自述也说明了这类字典的现实来源：各家整车厂都有自己的私有字典（含调整因子、偏移、标签与单位），有时会泄露到网上或被内部人员出售，而大多数情况是爱好者在自己的车上花大量时间逆向出来。

    换句话说，拿到一份 DBC，第一件要做的事不是数它有多少报文，而是确认它属于哪一类来源：官方泄露、社区逆向，还是从其他格式转换而来。这决定了它的可信度等级。

    七份可下载 DBC 的版本与来源

    仓库提供七份文件，混合了自有逆向成果与来自其他项目的转载。下表按「能不能追溯版本」整理，这是判断可维护性的第一层筛选。

    车型 / 用途 文件名 版本 来源性质
    BMW E90 bmw-e90.dbc 2021.6.8 仓库自有逆向，带明确日期版本
    BMW E39 bmw-e39.dbc 2021.6.6 由 .kcd 格式转换而来，非原生 DBC
    Mazda（2017） mazda_2017.dbc — 转载自 opendbc，未标版本
    Lexus RX350 lexus_rx350.dbc — 转载自 opendbc，未标版本
    Tesla Model 3 tesla_model3.dbc 2020.40.1 转载自 onyx-m2 项目的 DBC 仓库
    OBD2（通用） obd2.dbc 0.0.1 转载自 csselectronics.com
    J1939（通用） j1939.dbc 7.6 来源未知，转载自 haskell.org

    版本栏为「–」意味着无法判断这份文件与上游当前状态的距离：opendbc 的 Mazda 与 Lexus 文件在各自仓库里是持续更新的，转载快照一旦脱离上游就会静默过期。带日期版本的两份 BMW 文件虽然量级未必更大，但至少可以判断新旧。

    另一条容易被忽略的信息是 BMW E39 那一份由 .kcd 转换而来。跨格式转换会引入字节序、因子与信号命名的二次解释，因此它的原始证据链比原生 DBC 多一层，核对时应回到 .kcd 源。

    八段规范：从文件头到枚举值

    仓库把 DBC 规范按关键字拆成八节，配 wiki 逐节说明语法、属性与示例。这八节既是写作顺序，也是阅读一份陌生 DBC 的检查顺序。

    关键字 含义 阅读时该看什么
    VERSION 版本 文件头，先确认是否与上游一致
    NS_ 新符号 声明用到的符号集合，缺失会导致部分工具解析失败
    BU_ 节点（Board Units） 定义了哪些 ECU，是判断发送方归属的基础
    BO_ 报文（Messages） ID、DLC 与发送节点，含属性定义
    SG_ 信号（Signals） 起始位、位长、字节序、有无符号、因子与偏移、单位；含复用（Multiplexers）
    BA_ 属性（Attributes） 属性定义与默认值，承载周期一类的元信息
    CM_ 注释（Comments） 全局、节点、报文、信号四个层级的说明，是逆向记录的主要载体
    VAL_ 取值（Values） 枚举值表，把数字映射成文字状态

    其中 SG_ 的复用机制值得单独留意：它解决的是同一条报文在不同场景下承载不同信号的问题。若解析器不支持复用，这类报文会被解成错误的信号组合。

    配套资源：从规范到工具链

    仓库另附两组外部链接。工具与规范类包括 CANpy 的 DBC 规范文档、opendbc 开源 DBC 项目、BMW KCAN / KBUS / IBUS 参考项目、BMW K-CAN 文档站，以及 canmatrix（用于把 DBC 转成其他格式）。参考类包括 PiSnoop 的 DBC 帮助页、Racelogic 面向 VBOXII 与 PRO v4 的 CAN 格式说明、来自 haskell.org 的 J1939 DBC，以及 CANtool 手册。

    这套组合的实用意义在于：读规范解决「字段怎么写」，canmatrix 解决「格式怎么转」，BMW 专项资料则示范了单一品牌多总线（KCAN / KBUS / IBUS）的文档化方式。拿到一份陌生 DBC 时，按八节顺序过一遍也能快速定位问题：先看 VERSION 判断新旧，再看 BU_ 确认节点是否齐全，随后在 BO_ 与 SG_ 上核对 ID、DLC 与字节序，最后读 CM_ 注释寻找作者留下的逆向依据。

    还要留意仓库自述本身把这项工作描述为进行中的状态。因此即便带版本号的文件，也应理解为某一时点的快照，而不是最终结论。

    常见问题

    这个仓库能直接当车型数据库用吗？

    不能。它只提供 7 份可下载的 DBC 文件与规范文档，覆盖 BMW E90、BMW E39、Mazda 2017、Lexus RX350、Tesla Model 3 以及通用的 OBD2 与 J1939，规模远小于整车网络定义。它的主要用途是规范速查与少量可下载样本，车型级数据仍应回到 opendbc 这类专门项目。

    同目录的 license.md 是什么，能当素材读吗？

    它是仓库的许可证文本，不是技术内容，不应作为报文或信号的资料来源。阅读该仓库时应把 readme.md 与 wiki 当作内容，把 license.md 当作使用边界——引用或再分发这 7 份 DBC 前必须先确认各自的许可条款，尤其是转载自 opendbc、csselectronics 与 haskell.org 的那几份。

    BMW E39 的 DBC 是怎么来的？

    它是从 .kcd 格式转换而来的，仓库明确标注了这一点，版本号为 2021.6.6。跨格式转换会引入字节序、因子与命名的二次解释，因此核对信号定义时应回到原始 .kcd 文件，而不是把转换结果当作一手证据。

    DBC 里的 multiplexer（信号复用）解决什么问题？

    它解决同一条报文在不同场景下承载不同信号的问题：报文里用一个复用选择器决定其余位的含义，从而在不增加 CAN ID 的前提下表达更多状态。仓库的规范文档把 Multiplexers 单列为 SG_ 信号一节的子主题。需要注意若解析器不支持复用，这类报文会被解成错误的信号组合。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/nberlette-canbus/readme.md（DBC 格式定义、8 段规范索引、7 份可下载 DBC 的车型与版本、外部资源与参考链接）

    免责声明

    本文内容整理自公开开源仓库的自述文档，所述文件、版本号与来源标注均以该仓库快照为准，未经独立验证。转载类 DBC 可能已与其上游产生差异，使用前请核对上游当前状态与各文件的许可条款。

    更新记录

    • 2026-10-14 初稿

  • Polaris Sportsman 的 J1939 档案：12 个 PGN 与 250 kbit/s

    结论：Polaris Sportsman 的这份 J1939 档案给出 250 kbit/s、29 位扩展 ID 下 12 个 PGN 的信号定义，但它们是 2022 款 Sportsman 570 的逆向结果，工具面向的 2026 车型仍需逐条复验。另外两处硬边界必须知道：仓库未找到许可证文件，且工具导出的 DBC 因多信号 PGN 会重复占用同一 CAN ID，未被作为可用文件归档。

    12 个 PGN 分成两类看

    整车走 J1939，位速率 250 kbps、29 位扩展 ID，硬件链路是 Polaris 8 针诊断口 → GT150 → DB9 → PCAN DSUB9，配合 PEAK PCAN-USB FD 适配器与 PCAN-Basic 驱动，Python 侧通过 python-can 的 pcan 接口调用 PCANBasic.dll。配置集中在 polaris_can/config.py：interface 为 pcan，channel 为 PCAN_USBBUS1，bitrate 为 250000。

    把 12 个 PGN 按性质分类，比按地址排序有用得多：一类是状态枚举（取值是离散码），另一类是数值量（需要字节序与缩放）。

    PGN（含字节位） 信号 取值 / 换算 类别
    0x18F00500[5] 挡位 0x4C = L、0x48 = H、0x4E = N、0x52 = R、0x50 = P 状态枚举
    0x18FEF100[0] 手刹 0x37 = 已拉起、0x33 = 已释放 状态枚举
    0x18FEF1FE[3] 脚刹 0xDF = 踩下、0xCF = 释放 状态枚举
    0x18FF6CFE[1] 安全带 0xF7 = 系好、0xF3 = 解开 状态枚举
    0x18F006FE[1] 差速锁 0xDF = 锁止、0xCF = 打开 状态枚举
    0x18FDDFFE[0] 四驱模式 0xFC = 2WD、0xFD = 4WD 状态枚举
    0x18FEF200[6] 油门 0x19–0xFA 映射为 0–100% 数值量，有量程端点
    0x18FEF100[1:2] 车速 小端 uint16 除以 500，单位 mph 数值量，需字节序
    0x18FF6600[0:1] 发动机转速 小端 uint16 数值量，未给缩放
    0x18FEEEFE[0] 冷却液温度 字节值 + 40°C 偏移 数值量，偏移方向需复核
    0x18FEFC00[1] 油量 0–254 数值量，未给百分比换算
    0x18FEE500[0:1] 发动机小时计 小端 uint16 数值量，未给缩放

    这张表里最值得注意的是最后一列。状态枚举只要码值对得上就能用；而转速、油量、小时计三项只给了类型与字节序，没有给缩放因子，水温那条甚至写成「字节 + 40°C 偏移」——与常见的减 40 相反。这四项在使用前都必须用已知工况反推。

    为什么导出的 DBC 不能直接用

    工具提供了 polaris-can export-dbc，输出 cantools 兼容格式，可导入 SavvyCAN、Cabana、Vector CANoe。但归档说明明确指出：导出函数会为多信号 PGN 创建多个使用同一 CAN ID 的独立报文，因此该输出未被作为经过验证的 DBC 归档。

    这个坑在 J1939 场景下很典型。像 0x18FEF100 这样同时承载手刹与车速的 PGN，在 DBC 里应当是同一条报文下的两个信号；若导出成两条同 ID 报文，解析器要么只认第一条，要么按 ID 覆盖，结果就是丢信号。因此正确做法是把这份 PGN 表当作原始事实，手工建 DBC，而不是依赖自动导出。

    五种模式：哪一种是真正的逆向工具

    工具提供 decode、log、discover、replay、export-dbc 五种模式，其中 discover 才是为新车型定位信号的核心手段。

    模式 命令 输出 适用场景
    实时解码 polaris-can decode 终端仪表盘，10 Hz 刷新，含帧率、总线负载百分比、唯一 ID 计数 已知信号的日常查看，可加 --output 落盘
    记录 polaris-can log session1.log 微秒级时间戳的 candump 兼容日志 外场采集，后续导入 SavvyCAN 等工具
    发现 polaris-can discover --warmup 30 基线冻结后报告新 ID 与变化字节 新车型定位信号：怠速 30 秒建基线，再逐个操作开关
    回放 polaris-can replay session1.log --dashboard 离线回放，可实时或加速 无硬件时开发与验证
    导出 polaris-can export-dbc polaris.dbc DBC 文件 仅作起点，多信号 PGN 需手工修正

    discover 的工作流是：预热阶段（默认 30 秒，可用 --warmup 60 延长）记录基线流量并冻结，随后进入发现阶段，监控新出现的 ID 与发生变化的字节。文档给出的示例输出显示基线里冻结了 47 个 CAN ID，随后报告新 ID 与具体字节的旧值到新值变化。操作要领是预热期间车辆真正处于怠速，之后一次只动一个开关或踏板。

    解码时匹配成功的信号会打印 [KNOWN]，不匹配的被标为需要重新映射的候选——2026 与 2022 的差异正是靠这个标记暴露出来的。

    常见问题

    2022 年的 PGN 表能直接用在 2026 车型上吗？

    不能直接套用。README 明确说明工具面向 2026 款 Sportsman 570 EPS，但内置的 12 个 PGN 定义来自 2022 款 Sportsman 570，属于基线事实，需要在目标车型上逐条验证。若发现不匹配，应用 discover 模式重建：先怠速建立基线，再逐个操作开关与踏板，观察新 ID 与字节变化。

    为什么导出的 DBC 没有被当作可用文件归档？

    因为导出函数对多信号 PGN 会生成多条使用同一 CAN ID 的独立报文。例如 0x18FEF100 同时承载手刹与车速，正确形态应是同一条报文下的两个信号；拆成两条同 ID 报文会导致解析器丢信号。因此该输出未通过验证，未被归档，建议以 PGN 表为事实源手工建库。

    车速 PGN 0x18FEF100 的换算单位是什么？

    原文给出的是小端 uint16 除以 500，单位为 mph。也就是说原始值需要先按小端字节序拼成 16 位无符号整数，再除以 500 得到英里每小时；若系统内部使用 km/h 或 m/s，还要再做一级单位换算。

    没有 PCAN 硬件能不能用这套工具？

    可以。replay 模式支持离线回放日志文件，可实时或加速播放并接入仪表盘，仓库也提供了 tests/sample.log，在硬件未连接时用示例数据即可跑通，单元测试同样不依赖硬件。真正需要硬件的只有 decode、log 与 discover 三种模式。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/marvbull-polaris-sportsman-can/README.md（250 kbit/s J1939 配置、12 个 PGN 的信号定义、五种工具模式与故障排查）
    • 项目 01 —— public-can-dbc-datasets/additional/marvbull-polaris-sportsman-can/SOURCE.md（快照提交、证据边界、PGN_MAP 的 12 个标识符与导出 DBC 的缺陷说明、权利状态）

    免责声明

    本文所述 PGN、码值与换算均来自公开开源仓库的自述与工具代码，属社区逆向工程产物，不代表车辆制造商的官方数据。信号定义来自 2022 款车型，未经独立抓包验证，不同年款、市场与 ECU 版本可能存在差异。仓库未找到许可证文件，相关材料应作为私有离线研究副本，在权利确认前不得再分发或集成。

    更新记录

    • 2026-10-14 初稿

  • VW Grand California 生活舱 CAN：7 个 ID 与 9 条命令

    结论：VW Grand California 的生活舱 CAN 独立于 Crafter 底盘总线，社区已给出 500 kbit/s 的接入方式、7 个 29 位 ID 的功能归属、13 条解码样例与 9 条 cansend 命令。但同一个 ID 在不同字节位上混装多种含义，电流与电压两条规则作者未给出可复核的推导，因此这份表格适合做功能定位与命令复现，不适合直接当计量依据。

    接入：从树莓派到技术柜里的 9、10 针

    项目面向 Grand California 600 与 680 的生活舱总线，作者在免责声明中明确这是教育与研究用途，相关知识产权归属大众集团。硬件用 Raspberry Pi 3B+（作者说明 Pi Zero 2 W 更小巧省电）加一块 Waveshare RS485 CAN HAT（CAN 控制器 MCP2515、485 收发器 SP3485）。软件侧是 can-utils 加 Node-RED 的 node-red-contrib-socketcan 节点，用来搭可在浏览器里打开的仪表盘。

    总线初始化命令为 sudo ip link set can0 up type can bitrate 500000 loopback off listen-only off，监听用 cansniffer can0 -c -t0，发送用 cansend can0 18EF70C9#00.40.00.00.00.00.00.00。物理接入点选在 RGB 灯带控制器（零件号 7C4 947 022）的 9、10 针，该控制器位于 230V 配电盘正下方的技术柜内——这是全篇最省事的一条经验，避免了拆仪表台找线。

    作者还为 SavvyCAN 提供了一份 DBC：VW_GrandCalifornia_J608.dbc。

    七个 ID 的功能归属：一帧多用是常态

    生活舱总线的 ID 全部是 29 位扩展格式（形如 18EFxxxx），且普遍存在「一帧承载多个功能」的情况。下表按作者给出的归属整理，是判断该盯哪一帧的第一层筛选。

    ID 承载功能 备注
    18EF70C9 显示屏开关、卫星（SAT）开关、氛围灯 / 外部灯 / 内部灯 也是文档示例里的发送目标
    18EF70EB 卫星开关、灯光开关、电池剩余时间、车门锁状态 状态回读帧
    18EF71C9 露营模式、WiFi、音响（含蓝牙）、踏板自动 / 伸出 / 收回 命令侧主要目标
    18EF71EB 接收大量内容；露营模式、WiFi、音响状态 作者标注「接收很多东西」
    18EF72EB 灯光开关、230V 输入、电池电流、电压、电量百分比 电池参数集中在这一帧
    18EF73EB 230V 输入、清水与灰水水位 水位需第 1 字节为 01 才有效
    18EF60C9 设置灯带颜色 Y / R / G / B 四组预设值

    注意 18EF72EB 同时承担电流、电压、电量三项：这三项的字节位置完全不同，且分属不同的码制，因此不存在「一个 ID 对应一组语义」的捷径。

    解码规则与位序陷阱

    下表按作者原文的 0 起字节编号整理（原文写作 0ºB、1ºB……）。每行都附了原文给出的样例帧，这是判断规则可信度的关键——有样例的规则可以复现，无样例的只能照抄。

    内容 ID 样例帧 解码规则 可复现性
    清水 / 灰水水位 18EF73EB 00 00 00 00 0B 00 04 00 0 起编号第 4 字节为清水百分比（样例 0x0B）、第 6 字节为灰水（样例 0x04）；首字节为 01 时清水箱为空 高，样例与规则自洽
    电池电流（充电） 18EF72EB 50 00 00 8A 59 00 07 02 0 起编号第 6 字节为电流正值（样例 0x07）；首字节大于 0 表示充电中 中，未给单位换算
    电池电流（放电） 18EF72EB 00 00 00 0A 4C 00 FF 01 0 起编号第 6 字节为负值，FF = −1、FE = −2、FD = −3，按 MOD 2 递推 中，负值为自定义编码
    电池剩余时间 18EF70EB 01 00 3A 26 00 00 00 00 原文称第 2 字节为小时、第 3 字节为分钟，样例对应 0x3A 与 0x26 中，需确认编号起止
    电池电压 18EF72EB 00 00 00 0A 50 00 FF 01 原文称取第 5 字节（样例值 0x50）转十进制，十位加 5 得整数部分、个位为小数部分 低，推导未说明，需实测复核
    电池电量百分比 18EF72EB 00 00 00 0A 50 00 FF 01 原文称取第 4 字节（样例值 0x0A）为百分比除以 10，经 10*10 换算为 100 低，表述与样例存在张力，需复核
    显示屏开 / 关 18EF70C9 00 40 … / 00 00 … 由 I/O 按键触发，0 起编号第 1 字节为 40 时开、00 时关 高
    车门锁 18EF70EB 00 04 3A 26 00 00 00 00 0 起编号第 1 字节为 04，随后回到 00 中，仅给出单帧切片
    灯带颜色 18EF60C9 1E.00.64.2F… / 08.00.64.25… / 7D.00.64.23… / F5.00.64.2F… 四组预设分别对应 Y、R、G、B，0 起编号第 0 与第 3 字节变化 高，可整帧复现

    两条被标为「低」的规则是最该警惕的：电流与电压共用同一帧，且放电电流用 FF / FE / FD 表示负值、按 MOD 2 递推，与电压那条「十位加 5」的规则都不是标准编码。在没有万用表对照之前，这两项只能看趋势。

    字节编号在同一份表里并不统一

    这是使用这份表格时最容易踩的坑。同一份文档里，水位行说「4ºB = 0B」，只有按 0 起编号才能在样例帧 00 00 00 00 0B 00 04 00 里对上；电流行说「6ºB 是安培值」，也只有 0 起编号才能在 50 00 00 8A 59 00 07 02 里取到 0x07。但电压行与电量百分比行的样例值（0x50 与 0x0A）在同一帧里分别位于从 1 起数的第 5 与第 4 个字节。也就是说原文的编号起止在不同行之间不一致。正确做法是先拿样例帧反推真实位置，再写解析规则，不要直接信任编号本身。

    九条可复现的命令

    作者把可发送的命令单独列了一张表，全部基于 cansend，这也是整份资料里最容易验证的部分。

    功能 命令载荷 目标 ID 效果
    露营模式 00.40.00.00.00.00.00.00 18EF71C9 开 / 关切换
    WiFi 00.01.00.00.00.00.00.00 18EF71C9 开 / 关切换
    踏板自动 04.00.00.00.00.00.00.00 18EF71C9 开 / 关切换
    踏板伸出 10.00.00.00.00.00.00.00 18EF71C9 单次动作
    踏板收回 40.00.00.00.00.00.00.00 18EF71C9 单次动作
    氛围灯 04.40.00.00.00.00.00.00 18EF70C9 开 / 关切换
    外部灯 00.41.00.00.00.00.00.00 18EF70C9 开 / 关切换
    内部灯 01.40.00.00.00.00.00.00 18EF70C9 开 / 关切换
    卫星（SAT） 00.50.00.00.00.00.00.00 18EF70C9 开 / 关切换

    这张表的结构是「同一 ID 内按位区分功能」：18EF71C9 上，0 起编号第 1 字节的 40 / 01 / 04 / 10 / 40 分别对应露营模式、WiFi、踏板自动、踏板伸出、踏板收回；18EF70C9 上则靠 0 起编号第 0 与第 1 两个字节的组合区分氛围灯（04 40）、外部灯（00 41）、内部灯（01 40）与卫星（00 50）。做自动化控制时，正确做法是先读回当前状态再发送，而不是按记忆中的固定序列盲发。

    常见问题

    生活舱 CAN 和 Crafter 底盘 CAN 是同一条总线吗？

    不是。项目说明明确指出生活舱 CAN 独立（或几乎独立）于 Crafter 底盘总线，本文涉及的 ID、命令与解码只适用于生活舱部分。想取发动机、变速箱或底盘数据，需要另外接入底盘侧总线，不能指望从这些 ID 里读出来。

    从哪里接入生活舱总线最省事？

    作者最终选择接在 RGB 灯带控制器（零件号 7C4 947 022）的 9、10 针上，该控制器位于 230V 配电盘正下方的技术柜内。原厂接线图上也标注了多个可接入「便利 CAN」的点位，但灯带控制器这个点被作者评价为最方便。

    电池电流的负值为什么用 FF、FE、FD 表示？

    这是作者从样例帧中归纳出的自定义编码：放电时第 6 字节按 FF = −1、FE = −2、FD = −3 的方式递推，原文写作 MOD 2，与充电时的正值编码不是同一套。由于文档未给出单位与系数推导，实际使用前应与钳形表对照测量。

    清水和灰水水位在同一帧里怎么区分？

    靠字节位置区分：样例帧 00 00 00 00 0B 00 04 00 中，0 起编号第 4 字节（0x0B）是清水百分比、第 6 字节（0x04）是灰水百分比。另外原文注明当首字节为 01 时清水箱判定为空，因此解析时必须先看首字节再取水位值。需注意的是原文编号起止在不同行之间并不统一，实际接入应先按样例帧反推。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/mk4001-vw-grand-california/README.md（硬件与软件清单、500 kbit/s 初始化命令、接入点位与免责声明）
    • 项目 01 —— public-can-dbc-datasets/additional/mk4001-vw-grand-california/Table.md（7 个 ID 的功能归属、13 条解码样例与 9 条 cansend 命令）

    免责声明

    本文内容整理自公开开源项目，原作者已声明该项目仅用于教育与研究，相关 CAN 代码与协议的知识产权归属大众集团，不构成对任何专有系统的授权访问或修改许可。文中字节位置与换算规则均为原作者基于自车观察给出的结果，未经独立验证，不同年款与配置可能存在差异。

    更新记录

    • 2026-10-14 初稿

  • Mazda MX-5 NC 的 CAN 笔记：10 个 ID 与 RaceChrono 公式

    结论：Mazda MX-5 NC（2005–2015）的公开 CAN 笔记给出 10 个可用 ID 与配套 RaceChrono 公式，但覆盖面有硬边界：0x081 转向角、0x085 制动压力、0x090 疑似加速度三帧只在带 DSC 模块的车型（2007 年起）上出现；10 秒怠速直方图里 20 个 ID 中只有 8 个达到 100 Hz，真正被写清解码的不超过 10 个。

    先分清哪些 ID 依赖 DSC

    这份笔记面向第三代 MX-5（NC / NCFL / NCFLFL，即 MK3 / MK3.5 / MK3.75），按 CAN ID 组织，每个 ID 给出字节含义表与 RaceChrono 通道公式。使用时第一个判断不是「这个 ID 有没有」，而是「这辆车有没有 DSC 模块」——转向角、制动压力、疑似加速度三组信号都只在配备 DSC 的车型上存在，也就是 2007 年之后的车。

    CAN ID 更新频率 关键字节 公式 前提条件
    0x201 100 Hz 0–1 转速、4–5 车速、6 油门、7 恒为 FF 转速 = bytestouint(raw,0,2)/4.00；车速 = ((bytestoint(raw,4,2)/100.00)−100)/3.6；油门 = bytestoint(raw,6,1)*2.00 全系
    0x4B0 100 Hz 0–1 左前、2–3 右前、4–5 左后、6–7 右后 四角统一为 ((bytestoint(raw,N,2)/100.00)−100)/3.6 全系，独立承担轮速
    0x200 100 Hz 6 制动开关、7 节气门位置 制动 = data[6] 与 0x1 按位与；节气门 = bytestouint(raw,7,1)*100/255.00 全系；byte7 与 0x215 byte6 同源
    0x215 100 Hz 6 节气门位置，其余多为故障码 bytestouint(raw,6,1)*100/255.00 全系；byte0 与 byte2 互为镜像，byte1 与 byte3 互为镜像
    0x231 40 Hz 1 的 bit3 空挡、bit1 离合 空挡 = data[1] 与 0x4 按位与；离合 = data[1] 与 0x2 按位与 手动挡其余字节恒为 FF 或 00
    0x240 10 Hz 0 计算负载、1 水温、4 进气温度 水温 = bytestouint(raw,1,1)−40；进气 = bytestouint(raw,4,1)−40 全系；水温与 0x420 byte0 同源
    0x081 100 Hz 2–3 有符号转向角，仅 4 字节 bytesToInt(raw,2,2)，正值向右 需 DSC 模块，2007 年起
    0x085 100 Hz 0–1 制动压力、2 的 bit0 制动开关 压力 = (3.4518689053*bytesToInt(raw,0,2)−327.27)/1000.00，单位 kPa 需 DSC；系数源自 miata.net 用户数据，作者标注可能错误

    表里最该被记住的不是公式本身，而是最后一列。0x081 与 0x085 一旦用在 2006 年及以前的车上，会表现为「完全没有该 ID」，而不是数值为零。

    车速公式里那两个魔数的来历

    0x201 与 0x4B0 共用同一套换算：原始值以 km/h 为单位但带 100 km/h 偏移，因此先除以 100 再减 100；末尾的 3.6 是把 km/h 换成 m/s，因为 RaceChrono 内部以 m/s 计算，之后由软件按用户选择的单位再乘回去。自己写解析器时若直接用 m/s 之外的单位，就要把这一级换算还原。

    油门通道的公式是 bytestoint(raw,6,1)*2.00，对应 0.5% 的步进；0x201 的 byte2 与 byte3 虽跟随转速变化，但笔记标注它疑似带 0x7fff 偏移且与发动机扭矩无关，属未完成解析项。

    10 秒直方图：用帧数反推频率

    笔记给了一张停车场怠速状态下 10 秒窗口的报文计数直方图，共 20 个 ID。把帧数除以 10 就得到各 ID 的实际频率，这张表可以直接用来判断采样与总线负载。

    10 秒帧数 换算频率 CAN ID（十六进制） 说明
    1000 100 Hz 081、085、090、200、201、211、215、4B0 含全部已解析的动态信号
    500 50 Hz 204、21A 未解析
    400 40 Hz 231、4EC 231 为变速箱，与笔记标注的 40 Hz 一致
    100 10 Hz 212、240、39A、420、430、4FF 240 为发动机数据，与标注的 10 Hz 一致
    10 1 Hz 4F0、4F1 低频，疑似诊断或状态帧

    这张表的实用价值在于排错：如果某台设备上 0x4B0 的计数明显低于 1000，先查总线负载与过滤规则，再去怀疑解码；如果它和 0x240 一起掉，问题多半在总线本身而非解析。

    恒值与未完成项要单独标记

    笔记里有几类条目不能当信号使用。0x211 全为 0xFF；0x212 恒为 80 00 20 40 00 00 00 00，原文用问号表示这只是观察结果；0x090 整帧标记为 WIP，只推测与加速度有关；0x430 的 byte2–7 恒为 0x00，且笔记提示 0x430 在 ND 上才是油量。把它们写进解析配置只会产生恒零通道。

    0x240 这一帧同样混着可用与不可用项：byte0 的计算负载公式为 100*(bytestouint(raw,0,1)/255.00，笔记说明作者在 RaceChrono 的通道列表里找不到对应的 Engine Load 通道；byte3 的节气门位置被标注为绝对开度（计入怠速开度），但作者实测怠速值偏高（约 11%），提示缩放仍需调整；byte2 疑似点火提前角，未给出公式。

    常见问题

    这份 MX-5 NC 的 CAN 笔记覆盖哪些年款？

    笔记标题写明覆盖 2005–2015 的第三代车型（NC / NCFL / NCFLFL，即 MK3 / MK3.5 / MK3.75）。但转向角 0x081、制动压力 0x085 与疑似加速度 0x090 只在带 DSC 模块的车型上存在，也就是 2007 年起；更早的车上这些 ID 根本不会出现。

    0x085 的制动压力公式能直接用吗？

    需谨慎。笔记给出的公式是 (3.4518689053*bytesToInt(raw,0,2)−327.27)/1000.00，单位为 kPa，但作者明确标注系数来自 miata.net 用户数据、可能有误。作为替代，笔记还给出百分比算法 min(0.2*(bytesToInt(raw,0,2)−102),100)，未踩时基准值为 102，松开后短暂降到 99 会出现轻微负值。

    车速公式里为什么既要减 100 又要除以 3.6？

    两级换算是两件事。原始车速以 km/h 为单位但带 100 km/h 偏移，所以先除以 100 再减 100 还原真实 km/h；再除以 3.6 是换成 m/s，因为 RaceChrono 内部以 m/s 计算，最终按用户选择的单位自动乘回。自建解析器时若不需要 m/s，应去掉这一级。

    离合与空挡信号在自动挡车上也能用吗？

    不能直接套用。0x231 的 byte1 中 bit3 表示空挡、bit1 表示离合，笔记说明该字节的解读基于手动挡车：手动挡时 byte0、byte2、byte3 恒为 FF，byte4–byte7 恒为 00。笔记也提到该帧对自动挡车可能有更多有意义的数据，但并未给出自动挡下的解析。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/hatsunearu-mx5-nc-notes/mazda_mx5_nc.md（10 个 CAN ID 的字节表、RaceChrono 公式、更新频率与 10 秒怠速直方图）

    免责声明

    本文内容整理自公开开源笔记，其中公式、系数与频率均为原作者基于自车观察给出的结果，部分条目被作者本人标注为未完成或可能错误，未经独立实车验证。不同年款、市场、ECU 版本与是否带 DSC 模块均会导致差异，请以实际抓包与官方资料为准。

    更新记录

    • 2026-10-14 初稿

  • Suzuki Swift ZC32S 的 CAN 地图：6 条报文与 9 个信号

    结论：Suzuki Swift Sport ZC32S 的公开 CAN 地图只有 6 条报文、9 个信号，且刹车压力仍是无物理单位的裸值、转向角只是近似量。它足够驱动一块 ESP32 + MCP2515 的车载 OLED 仪表，但不能当整车网络定义或标定依据——派生出的 DBC 明确假设 Motorola 字节序、DLC 8 与 Unknown 发送方，全部未经实车抓包复核。

    六条报文能做什么：一份为显示服务的地图

    这份地图来自一个车载显示项目，硬件是 ESP32 WROOM 加 MCP2515 CAN 控制器，输出到 SSD1306 OLED，另有 8 颗 WS2812 组成换挡灯、旋转编码器切换页面、ESP32 内置 BLE 被动接收 4 个原厂 TPMS 传感器。它的目标不是整车解析，而是把七个显示页面需要的数据取出来，因此覆盖面天然很窄：转速、四轮轮速、水温、油门、转向角、刹车压力，加上蓝牙胎压。

    CAN ID 信号 字节位置 换算 证据强度
    0x124 发动机转速 data[1]、data[2] raw 为 data[1] 高字节、data[2] 低字节合成的 16 位值；RPM = raw / 4 高，README 与固件一致
    0x1B8 四轮轮速 FR 0–1、FL 2–3、RR 4–5、RL 6–7 km/h = raw × 0.0276923 高，四角各 16 位
    0x310 冷却液温度 data[1] TempC = data[1] − 40 高，单字节偏移
    0x122 油门踏板 data[1] Pedal% = data[1] × 100.0 / 255.0 高，单字节比例
    0x119 转向角 data[2]、data[3] 居中约 32768，满舵约 ±495°（左约 37792、右约 27808） 中，作者标注为近似
    0x1AF 刹车压力 data[6]、data[7] 无换算，保留有符号裸值 低，未声明物理单位

    真正决定这份地图可用性的不是 ID 数量，而是最后一列。前四行的公式是可以直接搬进固件的；转向角只能用于「左打还是右打」这类定性显示；刹车压力连单位都没有，只能画相对变化趋势。

    TPMS 走的是蓝牙，不是 CAN

    四个原厂胎压传感器通过 BLE 广播被 ESP32 被动接收，按固定 MAC 地址区分左前、右前、左后、右后。压力换算为 ((data[3] << 8 | data[4]) / 10.0 * 0.0689476) - 1.0（单位 bar），温度为有符号字节 data[2]。扫描跑在独立的 FreeRTOS 任务里，以免阻塞 CAN 接收。这意味着胎压与 CAN 数据是两条独立链路，做数据融合时必须各自打时间戳，不能假设同源同周期。

    派生 DBC 的四条假设：用之前必须知道

    归档方从这份公开地图生成了一份派生 DBC（6 条报文、9 个信号），但它同时明确列出了自己做过的假设。这四条假设就是使用边界。

    假设项 取值 为何这样假设 校验方式
    字节序 Motorola（高字节在前） 固件表达式为高字节在前 抓包后按两种字节序分别解码比对
    帧长度 DLC 8 README 未给出实际帧长 抓包读取实际 DLC
    发送方 Unknown，消费者标记 Display 发送 ECU 身份未知 按 ID 反查总线活动与断电隔离
    单位与标定 刹车保持裸值，转向角近似且被固件截断为整数 固件显示公式未声明物理单位 需与制动压力传感器、转角台架对照

    把假设显式写出来，比把不确定项悄悄填成确定值要安全得多。派生文件本身也被声明为独立整理的研究草稿，既不是上游产物也不是原厂 DBC；车型适配、总线段归属、单位与缩放都未经抓包核对。

    100 Hz 与 10 Hz：为什么轮速帧要单独分配缓冲

    这一条是整份文档里最有工程价值的细节。轮速帧 0x1B8 的速率是 100 Hz，水温帧 0x310 是 10 Hz，两者速率相差一个数量级。MCP2515 的硬件滤波器把接收缓冲 RXB0 单独留给水温 ID，避免高频轮速帧把尚未读取的水温帧覆盖掉。

    同一条经验对任何 MCU 方案都成立：当同一总线上混装不同周期的报文时，接收缓冲与中断优先级的分配要按「最慢的那一帧」来设计，而不是按平均速率。否则表现不是报错，而是某个慢信号偶发跳变——这类问题在后期极难定位。

    另外还需注意权利状态：归档说明指出该修订版本未找到仓库许可证，因此派生文件与来源 README 被作为私有离线研究副本保留，在权利确认前不宜再分发或集成。

    常见问题

    这份 ZC32S 的 CAN 地图能直接用于整车网络解析吗？

    不能。它只有 6 条报文、9 个信号，目标是为车载显示取数，不是整车网络定义。派生 DBC 也明确声明车型适配、总线段归属、单位与缩放未经抓包核对，未找到上游许可证，只能作离线研究参考。

    为什么 0x1B8 轮速帧要单独处理接收缓冲？

    因为速率相差一个数量级：轮速帧 0x1B8 为 100 Hz，水温帧 0x310 为 10 Hz。作者用 MCP2515 的硬件滤波器把接收缓冲 RXB0 单独分配给水温 ID，使高频帧无法覆盖尚未读取的低频帧，否则故障表现是水温偶发跳变而非报错。

    转向角 0x119 的 ±495° 能直接当作标定值用吗？

    不能。归档说明指出转向角是近似值，且固件把它截断为整数处理。它只能支持定性显示（居左、居中、居右）与粗略角度趋势，要做转向角的定量分析需要在转角台架上重新标定，并确认左约 37792、右约 27808、居中约 32768 这三个锚点。

    派生 DBC 里刹车压力为什么没有单位？

    因为来源固件的显示公式没有声明物理单位，归档方据此保留了有符号裸值 raw = (data[6] << 8) | data[7]。在获得制动压力传感器的对照测量之前，这个值只能用于观察相对变化，不能换算成 bar 或 MPa，更不能作为制动强度的判断依据。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/8rea-suzuki-swift-zc32s/README.upstream.md（6 个 CAN ID 的字节位置、换算公式、帧率与 MCP2515 缓冲分配）
    • 项目 01 —— public-can-dbc-datasets/additional/8rea-suzuki-swift-zc32s/SOURCE.md（派生 DBC 的 6 报文 9 信号、Motorola 与 DLC 8 假设、权利状态）
    • 项目 01 —— public-can-dbc-datasets/additional/8rea-suzuki-swift-zc32s/README.md（硬件清单、TPMS 蓝牙换算与显示页面结构）

    免责声明

    本文所述 CAN ID、字节位置与换算公式均来自公开开源仓库的说明文件，属社区逆向工程产物，不代表车辆制造商的官方数据，未经独立实车抓包验证。不同车型年款、市场与 ECU 版本可能存在差异。涉及行车安全的改动请以实际测量与官方资料为准。

    更新记录

    • 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 初稿

  • 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 初稿