星核火花赛车科技

标签： 车型协议

  • 商用车 DBC 知识包的许可证链：16 条报文与四类来源分级

    结论：拿到一份商用车 DBC 知识包，第一件事不是数报文，而是核对许可证链。这份包的 6 份 heavy-duty OEM DBC 合计只有 16 条报文，只覆盖 6 个制造商的部分 J1939 PGN；真正决定它能否进入产品的，是 21 个已收录来源里 2 个强制署名、3 组 GPL-3.0 与 2 份 CC-BY-SA-4.0 的传染性条款，以及 9 份被明确拦在 curated 目录之外的文件。

    为什么许可证链比报文数更先决定可用性

    DBC 是数据而非代码，但它的来源决定了分发边界。这份知识包的 LICENSES.md 开篇就写明了定位：它不授予任何访问许可，只保留公开来源本身的许可证。也就是说，把别人的 DBC 拷进自己的包，不会让许可证消失，只会把义务继承下来。

    因此合理的处理顺序是：先按许可证把来源分档，再决定哪些能进 curated/、哪些只能留在 raw/、哪些在闭源分发时必须整体剔除。报文数量在这条链里是最后才看的东西——16 条报文和 2000 条报文，合规成本可能完全一样。

    许可证档位 义务 代表来源 分发处理
    MIT / Apache-2.0 保留版权声明 commaai/opendbc（57 静态 + 39 生成器输出）、canboat/canboat、projectgus/kona-ev-dbc 可直接随包分发
    CC-BY-4.0 强制署名 berumiya/CAN_DBC_6thGenMazda（Mazda 6th-gen HSCAN/MSCAN） 分发须带署名串
    CC-BY-SA-4.0 署名 + 相同方式共享 fsfarmscaper/jaguar-xf-x250-can（MS/HS 总线各一份） 闭源分发须剔除
    GPL-3.0-only 传染性，须保留许可证文本 dalathegreat/leaf_can_bus_messages、qwec01/ARCFOX_dbc、gbt27930_2023.dbc 运行期动态加载或整体剔除
    无许可证 / 权利存疑 不可判定 见 DO-NOT-INTEGRATE 列表 停留在 raw/ 作研究记录

    六份商用车 OEM DBC 的实际覆盖面

    目录里的六份 DBC 来自上游 data/dbc/heavy_duty/，合计 16 条报文，按制造商分布为 Mercedes-Benz Actros 3 条、Caterpillar 2 条、Cummins 2 条、Detroit 3 条、Scania 3 条、Volvo 3 条。每份文件只覆盖选定的制造商私有 J1939 PGN，既不是完整的整车网络定义，也不构成车型年款的适配承诺。

    制造商 报文数 性质 证据边界
    Mercedes-Benz Actros 3 制造商私有 J1939 包内自产，非 SAE 标准
    Caterpillar 2 制造商私有 J1939 包内自产，非 SAE 标准
    Cummins 2 制造商私有 J1939 包内自产，非 SAE 标准
    Detroit 3 制造商私有 J1939 包内自产，非 SAE 标准
    Scania 3 制造商私有 J1939 包内自产，非 SAE 标准
    Volvo 3 制造商私有 J1939 包内自产，非 SAE 标准

    这六份文件在上游被描述为「由项目自身的 OEM decoder 定义生成」。这句话本身就是一条重要的证据边界：DBC 文件不确立底层测量方式，也不确立每个字段的校验依据。用它们做离线解码参考可以，拿来做 ASIL 相关功能的信号依据则超出其能力。

    同包内的其他来源量级

    同一个 LICENSES.md 还登记了若干量级明显更大的来源：ISOBUS 数据字典（isobus.net 的 AEF/ISO 11783-11 公开导出）生成出 102 条报文、1341 条信号的 isobus_dd11783.dbc；BogGyver 的 opendbc 分支贡献 28 份已提交 DBC，其中静态 7 份（hyundai_kia_generic、stellantis_dasm、tesla_can_pre1916、vw_golf_mk4、vw_mqb_2010、chrysler_pacifica_2017_hybrid、tesla_radar），生成 21 份（Lexus 6、Honda 6、Toyota 9）。把它们和 16 条报文的商用车部分放在一张表里看，才能判断这份包的重心到底在哪里。

    DO-NOT-INTEGRATE：九份被拦下的文件

    包里专门维护了一张「禁止整合」表，列出 9 个停留在 raw/ 的条目。它们的共同点是许可证状态未解决，因此不能拷进 curated/ 或 data/dbc/。

    风险类型 判定依据 处理动作
    未声明许可证 仓库未给出任何许可证 仅作研究记录，不进 curated
    内容未下载但已知无许可证 上游未标注，权利不可判定 不纳入任何分发包
    格式不兼容 是 Markdown 表格而非 DBC 不作为 DBC 来源整合
    标准组织版权风险 标注 MIT 但内容派生自 SAE J1939 标准，存在版权主张 整条排除，不进 curated

    这张表的价值在于把「不知道」显式化。多数 DBC 收集项目的问题不是抄错了文件，而是把许可证不明的产物直接混进了可分发目录，事后无法追溯。

    SAE 版权风险为什么单独列一档

    表中有一条的判定很典型：它被标注为 MIT，但内容派生自 SAE J1939 官方标准，上游仓库存在公开的版权主张记录。许可证标签与实际权利不一致时，以权利为准。这也是为什么来源表里会出现「标注 MIT 但仍排除」这种看似矛盾的处理。

    copyleft 的隔离方式：运行时数据载荷

    包内对 GPL-3.0 与 CC-BY-SA-4.0 采用了一套明确的隔离策略，核心是让这些 DBC 不构成软件代码的组成部分：

    1. 数据分离：这些文件不静态嵌入、不编译进二进制，而是在运行时由 cantools 以数据载荷方式动态读取。
    2. 闭源分发清理：在严格的商业或闭源分发中，可直接从 data/dbc/ 删除或排除这些文件；核心诊断、J1939、OBD-II 等 MIT/Apache-2.0 授权的 DBC 仍能独立工作。
    3. 合规登记：所有许可证与署名映射统一登记在仓库根目录的 REUSE.toml，符合 REUSE 3.0 / SPDX 规范。

    这套「气隙」设计的意义在于把传染性风险收敛到一个可删除的目录，而不是扩散到整个构建产物。是否需要真正删除，取决于分发形态；能不能删得干净，则取决于前期有没有做隔离。

    常见问题

    这份商用车 DBC 包能直接用于整车网络解析吗？

    不能。六份文件合计 16 条报文，每份只覆盖选定制造商的私有 J1939 PGN，上游明确说明它不是完整整车网络定义，也不保证车型年款适配。它适合作为特定 PGN 的解码参考与比对基准。

    为什么有些来源标注 MIT 却被排除在整合之外？

    因为许可证标签与真实权利可能不一致。DO-NOT-INTEGRATE 表中就有一项虽标注 MIT，但内容派生自 SAE J1939 官方标准，上游存在公开的版权主张记录。遇到这种情况以实际权利为准，整条排除。

    闭源产品里能不能保留 GPL-3.0 的 DBC 文件？

    可以保留但需要隔离：这些文件不得静态嵌入或编译进二进制，只能由 cantools 在运行时作为数据载荷读取，并且分发包要附带 GPL-3.0 许可证文本。若要彻底消除传染性影响，则须从 data/dbc/ 删除这些文件，其余 MIT/Apache-2.0 授权的 DBC 不受影响。

    CC-BY-4.0 与 CC-BY-SA-4.0 的差别在实际处理上是什么？

    CC-BY-4.0 只要求署名，分发时带上指定的署名串即可；CC-BY-SA-4.0 在署名之外还要求相同方式共享，因此在闭源分发中必须整体剔除。本包里前者对应 Mazda 6th-gen 的两份 DBC，后者对应 Jaguar XF X250 的 MS/HS 两份 DBC。

    DBC 里的信号定义能不能当作安全相关功能的依据？

    不能。包内免责声明写明，DBC 内容由社区逆向工程产生，不是车辆制造商的官方数据，在安全相关（ASIL）用途中只能作为参考。上游对这些文件的说明也指出，底层测量方式与各字段校验并未由 DBC 文件确立。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/ucanlab-heavy-duty-oem/SOURCE.md（六份 DBC 的 16 条报文、制造商分布与权利边界）
    • 项目 01 —— public-can-dbc-datasets/additional/ucanlab-heavy-duty-oem/LICENSES.md（21 个来源的许可证映射、copyleft 隔离策略与 DO-NOT-INTEGRATE 表）
    • 项目 01 —— public-can-dbc-datasets/additional/ucanlab-heavy-duty-oem/README.md（上游产品定位、协议覆盖与 data/PROVENANCE.md 的登记机制）

    免责声明

    本文所述的 DBC 内容均为社区逆向工程产物，不代表车辆制造商的官方数据。文中数字均来自上述公开仓库的说明文件，未经独立实车验证；不同车型年款、市场与 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

  • 宝马 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

  • 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

  • 车型协议接入实践：从指纹识别到安全固件的最低契约

    结论：接入一个新车型，最低工作集是走完一条固定骨架：安全板接收 CAN → 主机车况网关 → 指纹与 ECU 固件匹配 → 生成车型参数与安全模式 → DBC 解析出车况 → 控制器生成候选发送帧 → 回包编码 → 主机到板传输 → 板端安全钩子放行。公开资料在固定快照中核对了 17 个车型实现目录，但「实现入口存在」并不等于已完成某品牌全部平台与年款的报文与安全审计。接入的关键判断有三条：未识别 / 模糊匹配默认被动；品牌目录不能代替平台差异验证；含 ALLOW_DEBUG 条件的模式不等于发布固件可启用执行。

    车型实现的共同骨架

    公开资料显示，车型实现的加载与运行是一条固定链路，可按下面顺序理解：

    1. 安全板接收 CAN 帧，交给主机车况网关；
    2. 网关做指纹识别与 ECU 固件匹配，形成车型参数与安全配置；
    3. DBC 解析器把原始帧解析为车型车况；
    4. 控制器消费车况，生成控制意图；
    5. 车型控制器把控制意图编码为候选发送帧；
    6. 候选帧经主机发送线程下发，最终由安全固件的发送钩子决定是否放行。

    两个结构性事实需要注意：其一，车型接口由一份品牌清单静态加载，不是运行时扫描任意插件目录；其二，每个品牌常规包含车型枚举与物理配置、车型参数与安全模式、接收帧到车况、控制意图到候选帧这几组模块，部分品牌另有雷达接口。这些模块的职责边界，就是后续插件化时「能力契约」的划分依据。

    十七个品牌目录与平台差异

    固定快照中核对到的车型实现入口如下。每类的接口、状态、控制器与配置模块均已在目录中确认存在，「雷达接口」表示另有雷达相关模块。此表是开发入口索引，不能替代平台差异验证：

    品牌目录 额外雷达接口 平台/安全差异 当前深度
    body 无 非汽车双轮平台 链路已追踪
    byd 无 仅调试安全模式 单车型转角链路已追踪
    chrysler 有 多车型链 主要链路已追踪
    ford 有 经典 CAN 与 CAN FD 主要链路已追踪
    gm 有 ASC M / 相机若干链路 主要链路已追踪
    honda 有 两套转向实现 主要链路已追踪
    hyundai 有 经典 CAN 与 CAN FD 主要链路已追踪
    mazda 无 扭矩/速度迟滞 主要链路已追踪
    mg 无 仅调试安全模式 扭矩链路已追踪
    mock 无 空发送回退 非实车回退已追踪
    nissan 无 转角 / 车型取消 主要链路已追踪
    psa 无 三总线，仅调试安全模式 转角链路已追踪
    rivian 有 两代硬件 主要链路已追踪
    subaru 无 含 preglobal 分支 主要链路已追踪
    tesla 有 转角 / 原车转发 主要链路已追踪
    toyota 有 逐层样本 已逐层追踪
    volkswagen 有 多平台安全模式 主要链路已追踪

    特别要注意：安全钩子注册表把若干模式（第三方品牌、部分平台）置于 ALLOW_DEBUG 条件下；实现目录与测试存在，并不表示发布固件可启用执行。目标车型还须以具体平台与固件版本逐一核对。

    启动阶段的五道控制门

    车型识别与启动阶段依次经过多道门，每道门都可能让系统停留在「被动」状态：

    入口 行为
    CAN 指纹 在总线上按 CAN 地址与数据长度逐步排除候选；超过限定帧数后停止，不保证未知车型能识别
    指纹确认 优先查询 VIN、ECU 存在性及固件版本，再收集 CAN 指纹；单一固件候选可覆盖结果，环境变量可强制指纹（仅用于受控开发）
    固件匹配 先精确固件匹配，失败再尝试模糊 / 品牌自定义匹配，返回是否精确及候选集
    车型获取 无候选时回退空模型；用候选接口生成车型参数并保留 VIN、固件、指纹来源及模糊匹配标记
    控制就绪 仅在进程初始化、非被动、控制请求存活的路径调用车型编码形成候选发送帧

    这里要分清几种状态：空模型、被动、仅仪表记录互不相等，但都不能作为未知车型开始执行的理由；用户配置或环境变量强制指纹也不构成车辆协议兼容性验证。

    DBC 编解码的函数级语义

    解析与编码是两个方向，公开资料给出的关键语义如下：

    入口 关键含义
    DBC 加载 加载消息、信号、枚举；按 DBC 系列选择校验算法
    取值 按大小端与位提取原始整数；符号、倍率和偏移另行处理
    解析 解码信号、计算校验和与计数器；失败返回失败，不把这一帧的部分值提交
    计数器 错误计数达阈值则拒绝，有效后逐步恢复
    整帧解析 仅接收指定总线与已注册地址，更新值与时间戳，返回成功解析的地址集
    健康位 检查最近成功时间、计数器与缺失次数；总线空窗单独观察
    编码 反向应用倍率/偏移，自动补计数器与校验和；未知信号仅记录错误并跳过
    组帧 返回地址、编码后数据与总线号；未命中消息名时返回空数据

    最常见误用是只看数值而忽略健康位：解析器保存的是最近一次成功值，若忽略有效位与总线健康，就可能把旧值当成当前观测；编码器只是协议编码，不是转向扭矩或加速度安全门。

    样本三层与插件化最低契约

    以样本车型看，三层结构最清楚：

    层 已核对决策
    车型能力 设定安全模式与助力比例；按平台/固件选择扭矩或角度控制、制动地址、加密、原车/自控纵向能力
    ECU 变更 特定实验纵向模式会执行 ECU 通信控制，退出时尝试恢复；属车型专属且需单独台架验证
    输入状态 区分动力、相机总线与平台标志，解析车门、安全带、制动/油门、轮速故障、转角与驾驶员扭矩
    控制器 按驾驶员扭矩与助力限制转向请求；按提醒、纵向能力、车速与加密分支生成候选帧
    固件接收 从指定报文维护扭矩、角度、巡航、油门、刹车及车速样本
    固件发送 检查转向扭矩/角度速率、纵向加速度、AEB 与诊断报文

    从这条样本链可以抽出面向插件化的五条最低契约：

    1. 车型插件声明平台、ECU 固件范围、DBC 版本、总线拓扑、能力位、车型参数与安全模式；未识别 / 模糊匹配默认被动；
    2. 解码插件输出值、时间戳、来源、校验 / 计数器 / 超时状态，不能把上次成功值伪装成当前有效观测；
    3. 控制插件只产生结构化控制请求或候选帧，不能自行改固件白名单、安全模式或绕过车况网关；
    4. 硬件安全控制器独立于应用 CPU 实现收发与转发限制、心跳失效回退与板级故障处理；
    5. 每个目标车型逐一建立解析、编码、固件安全和回放基线；品牌目录索引不是一套通用线束或固件配置规格。

    常见问题

    有了某个品牌的车型目录，就能接这个品牌的全部车型吗？

    不能。品牌目录只证明实现入口存在，不能代替平台差异验证。目标车型须以具体平台与固件版本逐一核对；同一品牌可能同时存在经典 CAN 与 CAN FD 等不同分支。

    未知车型会怎样处理？

    无候选时会回退到空模型；未识别或模糊匹配默认被动。被动、仅仪表记录与空模型互不相等，但都不能作为未知车型开始执行的理由。

    CAN 解析出的值可以直接用吗？

    不能只看数值。解析器保存的是最近一次成功值，必须同时检查有效位、时间戳与总线健康，否则会把旧值误当成当前观测。

    安全模式在调试条件下可用，是否代表能上车执行？

    不代表。若干模式被置于 ALLOW_DEBUG 条件下，实现目录与测试存在并不表示发布固件可启用执行；实际执行还需台架与受控场地验证。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/CAR_PROTOCOL_IMPLEMENTATIONS.md（取用车型实现骨架、17 个品牌目录索引、启动控制门、DBC 编解码语义、样本三层结构与插件化最低契约）。

    说明：本文为对固定源码快照（主仓库提交 c8fb906 及固定的车型协议与安全固件归档）的静态阅读整理，未接入目标车型、线束或安全板，未运行完整测试套件。文中所有入口、状态与目录均出自源文档，样本车型仅为实现链路示例，不是对任何年款或配置的实车适用性声明。

    更新记录

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

  • 菲亚特 Fiorino 的 B-CAN：50 kbps 上的车速、转速与油量

    结论：菲亚特 Fiorino（Fiat Mini 平台）的 B-CAN 是 CAN 2.0B、29 位扩展标识符、ISO 11898-3 低速容错物理层、50 kbps、大端（Motorola，MSB 在前）。文档记录了一个紧凑的帧矩阵：车速、转速、冷却液温度、喷油量、续航、油量等都能从几条固定 ID 上被动读到。这套解码背后有一个现实动机——Fiat Mini 平台的仪表存在一个出厂软件缺陷，总里程一到 399999 公里就永久冻结；作者因此让 ESP32 自行计算并存储里程，且系统随车通过了西班牙官方的 ITV 检验。边界：帧矩阵按平台记录，具体到某一辆车仍需核对，任何改动都应先在台架确认。

    本文整理自该项目的 CAN 矩阵文档与工程说明。文档把帧矩阵定义为「逆向得到的 Fiat Mini 平台 B-CAN 网络」，本文保留这一来源限定。

    车辆与适用范围

    项目以一辆 Fiat Fiorino 为对象，用一块 ESP32 加自定义载板替换原厂中央单色液晶，读 B-CAN 实时遥测并渲染自定义界面。文档提到同类平台的车型（Fiorino、Grande Punto、Alfa Romeo MiTo）共享这套仪表缺陷，因此帧矩阵按 Fiat Mini 平台陈述。

    项 内容
    车型 菲亚特 Fiorino（Fiat Mini 平台；同平台另有 Grande Punto、Alfa Romeo MiTo）
    年款 / 市场版本 源文档未给出具体年款；项目语境为西班牙市场（需通过 ITV 检验）
    ECU / 改装状态 用 ESP32 + 自定义载板替换原厂中央单色液晶；原厂仪表仍作为被替换对象存在
    采集跨度 源文档未给出；随车通过了西班牙官方 ITV 检验
    适用范围 按 Fiat Mini 平台记录的帧矩阵；逐车细节仍需核对

    总线与寻址

    文档把 B-CAN 定义为 CAN 2.0B、29 位扩展标识符，物理层是低速容错 CAN（ISO 11898-3），50 kbps，字节序为大端（Motorola，MSB 先）。接入侧使用 TJA1055T（低速容错 B-CAN 收发器），配合电平转换芯片适配 3.3 V / 5 V。

    项 内容
    物理层 低速容错 CAN（ISO 11898-3），50 kbps
    链路层 CAN 2.0B，29 位扩展标识符
    字节序 大端（Motorola，MSB 在前）
    收发器 TJA1055T 低速容错 B-CAN 收发器 + 电平转换
    CAN FD 源文档未提及

    已解码信号

    下表逐条取自文档帧矩阵。解码式中 B_n 表示第 n 个字节，位移写法保留原文。

    信号 位置（ID / 字节） 解码 证据
    发动机转速 0x04214001 字节 6 Byte[6] × 32（32 转/分/位） 文档帧矩阵
    喷油量 0x04214001 字节 4、5 ((B4 左移 8) 或 B5) ÷ 100.0，单位 mm³/行程 文档帧矩阵
    发动机温度 0x04214001 字节 3 B3 − 40，摄氏度 文档帧矩阵
    燃油消耗（推导） 0x04214001 字节 3 至 6 (raw_iq × RPM × 1.2) ÷ 1e6，升/小时（按 4 缸 4 冲程推导） 文档帧矩阵（派生量）
    总里程 0x0C014003 字节 1 至 3 (B1 左移 16) 或 (B2 左移 8) 或 B3，公里 文档帧矩阵；不采用，见下（399999 公里后冻结）
    续航 0x0C014003 字节 4、5 ((B4 与 0x03) 左移 8) 或 B5（字节 4 需掩码） 文档帧矩阵
    车速 0x04394000 字节 0、1 ((B0 左移 8) 或 B1) × 0.0625，km/h 文档帧矩阵
    燃油液位 0x06214000 字节 5 Byte[5]，直接取百分比 文档帧矩阵

    读取方法与注意事项

    先查 DLC，再取载荷。文档把「提取载荷前必须检查 DLC」列为安全要求，用于防止缓冲区越界读。这一条对 0x04214001 这类大端多字节字段尤其重要。

    0x0C014003 是复用帧。文档说明这一帧同时承载「总里程」和「续航」两组信息（多路复用），解析时要按同一帧内的不同字节段分别取用，不能只当一种含义。

    里程为何要自己算。这是本项目的核心动机：Fiat Mini 平台的仪表存在出厂缺陷，总里程到达 399999 公里后永久冻结、不再记录。文档因此让单片机从 B-CAN 实时遥测独立计算并安全存储总里程，并把它写入外部的 AT24C32 EEPROM（经 I2C，配合 DS3231 实时时钟），以避免磨损 ESP32 内部闪存。文档记录：该车带着这套系统通过了西班牙官方的 ITV 检验，作为可靠性的一次实证。

    两条核对手段。固件提供「被动 CAN ASCII 流式输出」（用一个编译开关打开），按标准 LAWICEL/SLCAN 格式（如 t1238…）把原始 B-CAN 帧输出到串口，便于用任意串口终端或自写脚本记录；界面上还有硬件状态浮层，用于提示 EEPROM 状态、熄火保存与内存损坏错误。

    证据等级与边界

    文档给出的帧矩阵被明确定义为「逆向得到的 Fiat Mini 平台 B-CAN 网络」，属于社区工程结果，而不是厂家规格。其中「燃油消耗」被文档自述为派生量（由喷油量与转速按 4 缸 4 冲程推导），而非总线上直接广播的字段；「总里程」虽可从帧中解出，但文档明确不采用该值，原因是它在 399999 公里后冻结。

    验证层面有两处相对硬的证据：其一，该车带着这套嵌入式方案通过了西班牙官方的 ITV 检验，文档把它作为「可靠且准确」的实证；其二，项目提供了原始 B-CAN 帧的被动流式输出，便于独立复核。但文档未给出逐信号置信度，也未绑定具体年款与配置。

    因此边界是：帧矩阵按 Fiat Mini 平台陈述，同平台车型（Fiorino、Grande Punto、MiTo）可能共享，但具体到某一辆车、某一年的配置仍需逐车核对；更换仪表属对车辆电气系统的改动，任何操作都应在台架或合规前提下进行。

    常见问题

    Fiorino 的 B-CAN 是什么协议和速率？

    文档定义为 CAN 2.0B、29 位扩展标识符、ISO 11898-3 低速容错物理层，速率 50 kbps，字节序为大端（Motorola，MSB 在前）。收发器用的是低速容错型号 TJA1055T。

    为什么不用总线上读到的总里程？

    因为 Fiat Mini 平台的仪表存在出厂缺陷：总里程到达 399999 公里后永久冻结、不再记录。项目因此让 ESP32 从实时遥测独立计算总里程，并写入外部 EEPROM 保存，而不是直接采信被冻结的广播值。

    车速和转速的解码式分别是什么？

    车速在 0x04394000 字节 0、1：((B0 左移 8) 或 B1) × 0.0625 km/h。转速在 0x04214001 字节 6：Byte[6] × 32，分辨率 32 转/分。

    解析时有哪些必须注意的工程细节？

    三点：提取载荷前先检查 DLC，防止越界读；0x0C014003 是复用帧，同时承载总里程与续航，要分段取用；全程按大端解析多字节字段。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/raul-fiat-fiorino-can/docs/Can_Matrix.md（本项目车型档案主来源，取用了总线规格与帧矩阵）。
    • 项目 01 —— public-can-dbc-datasets/additional/raul-fiat-fiorino-can/README.md（取用了 399999 公里冻结背景、硬件选型与 ITV 检验结论）。

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

    更新记录

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

  • Honda 旧版 openpilot 子集：DBC 名与 ECU 固件指纹

    结论：这是一份旧版开源辅助驾驶项目的 Honda 子集档案，它记录的不是「某台车抓到了哪些帧」，而是「怎么认出一台 Honda 是哪款」：用 ISO 15765-4 的 29 位固定寻址（0x18DA<TA>F1）向一串 ECU 读固件版本号，再拿版本号前缀去匹配车型；同时按硬件族（Nidec 与 Bosch A / Bosch B）挑选对应的 DBC 与线束，并为每个车型设定最小转向速度。它覆盖 Civic、Accord、CR-V、Fit、Odyssey、Pilot、Insight、HR-V、Passport、Ridgeline 与 Acura ILX / RDX 等多款车。下述内容只适用源文档记录的这一份车型与固件表。

    车辆与适用范围

    源文档是一份旧版开源项目的静态快照：根文档是项目的通用说明，车型细节集中在 Honda 的车型常量文件里。文件同时保留了大量固件版本号样本，用于把「读到的一组版本号」映射回具体车型。

    项 内容
    车型 Honda：Civic（含 2016-18、2019-21、2022、Hatchback、1.6 柴油）、Accord / Accord Hybrid、CR-V（含 5G、EU、Hybrid）、Fit、Freed、HR-V、Odyssey、Pilot、Passport、Ridgeline、Insight、Honda e；Acura：ILX、RDX（含 3G）
    年款 / 市场版本 以车型常量里的年份区间为准（如 Civic 2016-18 / 2019-21 / 2022）；部分条目注明市场（如 Odyssey CHN、CR-V EU）
    ECU / 改装状态 原厂；按车型使用 Nidec 或 Bosch A / Bosch B 线束
    采集跨度 源文档未给出抓包数；车型常量登记了每个 ECU 的固件版本样本列表
    适用范围 仅限源文档所列车型与固件版本；未列入的版本需自行补录，不能假定兼容

    总线与寻址

    这份档案的寻址方式很规整：对每个 ECU 用 0x18DA<目标地址>F1 的 29 位物理请求（F1 是测试仪地址），读回的固件版本号再按车型分组。DBC 侧则按硬件族命名，并给个别车型挂了单独的 body DBC。

    项 内容
    物理层 双绞线 CAN；经车型线束接到相应总线
    链路层 / 比特率 源文档未在本文件给出比特率
    寻址方式 ISO 15765-4 29 位固定寻址：请求 0x18DA<TA>F1，测试仪地址 F1
    CAN FD 源文档未涉及；按经典 CAN 处理
    硬件族 Nidec 与 Bosch A / Bosch B 三套；DBC 名如 honda_civic_touring_2016_can_generated、honda_accord_2018_can_generated、honda_civic_ex_2022_can_generated

    已解码信号

    主素材的「信号级」内容集中在ECU 的请求地址与固件版本前缀上，因此下表登记每个 ECU 的寻址与版本号前缀形态，并给出代表性车型的版本样本。个别条目源文档标注为「修改版固件」，按原样保留。

    ECU 位置（请求地址） 固件版本前缀（样本） 证据
    发动机 PCM 0x18da10f1 37805-… 车型常量 FW_VERSIONS
    线控换挡 0x18da0bf1 54008-… 车型常量 FW_VERSIONS
    变速箱 TCM 0x18da1ef1 28101-… / 28102-… / 28103-… 车型常量 FW_VERSIONS
    电动制动助力 0x18da2bf1 46114-… / 39494-… 车型常量 FW_VERSIONS
    VSA 车身稳定 0x18da28f1 57114-… 车型常量 FW_VERSIONS
    EPS 电动转向 0x18da30f1 39990-… 车型常量 FW_VERSIONS；个别项标注「修改版固件」
    SRS 安全气囊 0x18da53f1 77959-… 车型常量 FW_VERSIONS
    组合仪表 0x18da60f1 78109-… / 78108-… 车型常量 FW_VERSIONS
    HUD 0x18da61f1 78209-… 车型常量 FW_VERSIONS
    前向毫米波雷达 0x18dab0f1 36802-… 车型常量 FW_VERSIONS
    前视摄像头 0x18dab5f1 36161-… 车型常量 FW_VERSIONS
    网关 0x18daeff1 38897-… 车型常量 FW_VERSIONS

    读取方法与注意事项

    第一，识别是「多 ECU 组合」而不是单点。源文档为每款车登记了若干 ECU 的版本号列表，匹配时是把读到的整组版本号与车型的列表比对；只读到某一个 ECU 的版本不足以定车。

    第二，硬件族决定用哪套 DBC 与线束。源文档把车型分成 Nidec 与 Bosch 两族，Bosch 又细分到需要 Bosch A 或 Bosch B 线束：Civic 2016-18 用 Nidec，Civic 2019-21 与 Hatchback 用 Bosch A，Civic 2022 用 Bosch B。CRC/识别出错时，往往是把车放错了族。

    第三，几个「例外集」是踩坑点。源文档列出：HONDA_NIDEC_ALT_SCM_MESSAGES（一批 Nidec 车用替代 SCM 报文）、HONDA_NIDEC_ALT_PCM_ACCEL（Odyssey）、HONDA_BOSCH_ALT_BRAKE_SIGNAL（Accord、CR-V 5G、Acura RDX 3G 用替代制动信号）、HONDA_BOSCH_RADARLESS（Civic 2022 无雷达）、以及 STEER_THRESHOLD 的两处覆盖（Acura RDX 与 CR-V EU 用 400，默认 1200）。

    第四是最小转向速度：车型信息里为每款车写了 min_steer_speed，从 0（如 Civic 2022、Odyssey）到 25 mph（Acura ILX）不等，且都按 mph 换算。它与硬件族、DBC 一样是车型识别后要一起取用的参数。

    证据等级与边界

    可视为文档级证据的是：每个 ECU 的请求地址、以及各车型登记的固件版本号列表。这些是源文档快照里的明确内容。属于「示例性」的是具体版本号——它们来自项目记录的样本，不代表该车型全部生产版本；未列入的版本不能被假定兼容。

    不能外推的地方有两处。第一，车型与年款是逐条列出的，同一车名不同年款可能属于不同硬件族、用不同 DBC（Civic 三代就是例子），跨年款套用没有依据。第二，源文档是旧版项目的静态快照，后续项目可能已增删车型或改动寻址；本文只反映快照当时的内容。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试。读固件版本属于常规诊断读取；本文不涉及任何写 ECU 或绕过安全机制的操作。

    常见问题

    这台 Honda 到底是哪款、用哪套硬件？

    源文档的做法是向一组 ECU（PCM、TCM、VSA、EPS、仪表、雷达、摄像头、网关等）读固件版本，用整组版本号匹配车型，并据车型决定用 Nidec 还是 Bosch A / Bosch B 线束与对应 DBC。

    Civic 2016-18、2019-21、2022 有什么区别？

    硬件族不同：2016-18 属 Nidec，2019-21 与 Hatchback 属 Bosch A，2022 属 Bosch B；Civic 2022 还被列入无雷达集合，且最小转向速度记为 0。

    为什么有些车要单独列出替代报文集合？

    源文档为若干车设了例外集，例如一批 Nidec 车用替代 SCM 报文、Odyssey 用替代 PCM 加速报文、Accord/CR-V 5G/Acura RDX 3G 用替代制动信号、Civic 2022 无雷达；这些车的报文布局与同族其它车不同。

    固件版本号能当唯一识别码吗？

    不能。源文档登记的是样本列表，用于组合匹配；未列入的版本不在表内，且同一车型不同年款可能落在不同族，不能只凭一个版本号定车。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/blueopenpilot-c3-legacy-subset/README.md（主来源：项目总说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/blueopenpilot-c3-legacy-subset/selfdrive/car/honda/values.py（车型常量、ECU 请求地址、固件版本表与硬件族）。

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

    更新记录

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

  • 比亚迪 BYD 全车系 DBC 档案：7 个候选文件的报文规模

    结论：这份档案记录的不是一台车，而是一组面向比亚迪（BYD）与吉利车型的候选 DBC 文件：来源快照保留 7 个字节互不相同的 DBC，报文数从 4 条到 124 条不等。它的价值在于给「国产新能源整车的报文规模」提供了一份可核对的清单，但来源说明明确指出——项目文档里那张宽泛的车型列表并不能确立每个 DBC 对每种车型的适配，很多字段还用了占位名，且仓库快照里找不到许可文件（README 只有 MIT 徽章）。因此本文只登记文件与规模，不做「某款车某信号」的断言。下述内容仅限源文档记录的这一批候选文件。

    车辆与适用范围

    源文档是一个开源辅助驾驶适配项目的说明。项目自述针对「比亚迪全系与吉利」做适配，并提供了实车 DBC 报文数据库；但来源说明的措辞更谨慎：这些是「候选的逆向定义」，上游 README 的宽泛车型列表不构成逐车型的已核验适配。车型代号在 README 里列得很细（汉 DM/EV、唐 DM-i/DM-p、宋 PLUS/Pro/L、秦 PLUS/L、元 PLUS、海豹、护卫舰、腾势 D9 等），但它们属于文档级声称。

    项 内容
    车型范围 项目自述覆盖比亚迪（汉 / 唐 / 宋 / 秦 / 元 / 海豹 / 驱逐舰 / 腾势）与吉利（缤越）多款车型
    年款 / 市场版本 README 按年款列出代号（如 2020 汉 DM、2022 汉 DM-i、2022 元 PLUS / ATTO 3）；来源说明未确立逐车型适配
    ECU / 改装状态 面向车机端开源辅助驾驶项目；包含 EPS、ADAS、RADAR、CAMERA、BCM、VCU、BMS 等节点的报文
    采集跨度 快照保留 7 个字节互不相同的 DBC；上游还以嵌套目录重复了其中几个，快照已省略重复项
    适用范围 仅限这一批候选文件；跨车型、跨年款适用性未验证，且部分文件用占位名

    总线与寻址

    来源说明没有给出比特率、寻址位数这类总线参数——它登记的对象是 DBC 文件本身，而非一次抓包。因此本文按「文档级」记录：能确定的只有 DBC 这一载体、报文数与文件来源位置；总线物理参数应视为源文档未提供。

    项 内容
    载体 DBC 文件（报文 + 信号的数据库描述），非原始抓包
    物理层 / 比特率 源文档未提供
    寻址方式 源文档未提供 11 位 / 29 位说明
    CAN FD 源文档未提供
    节点覆盖（README 声称） EPS 转向、ADAS 辅助驾驶、RADAR 雷达、CAMERA 前视相机、BCM 车身、VCU 整车控制、BMS 电池

    已解码信号与文件清单

    由于主素材给的是 DBC 文件而非成品信号表，下表按「文件 / 条目」登记规模与来源说明原样保留的注意事项，不代填任何信号名或缩放。

    条目 上游位置 规模 / 内容 证据 / 注意
    byd_han_dmev_2020.dbc BYD_Files/opendbc/dbc/ 16 条报文 与已归档的另一副本不同：改动两个踏板缩放、省去 4 条报文
    byd_generic_pt.dbc byd2/ 19 条报文 通用动力总成候选文件
    byd_tangdm_radar.dbc byd2/ 4 条报文 唐 DM 雷达相关
    byd_generic_pt_v2.dbc 嵌套目录内的 opendbc/dbc/ 19 条报文 与上一份布局大体重叠，但报文明/信号名被混淆成不同写法
    byd_all.dbc byd大全.dbc 124 条报文 头部注明由运行时/导出资源重建，许多字段为占位名
    byd_song.dbc 比亚迪3/Bydsong(1).dbc 89 条报文 同目录 generated(1).dbc 与其字节相同
    byd_tang_dmp_based_on_han.dbc 比亚迪3/唐DMP_based_on_han.dbc 88 条报文 文件名即说明「基于汉架构扩展」
    车型代号表 项目 README 数十个代号 README 声称的适配范围，非逐车型已核验
    横向力矩曲线参数 LAT_SIGLIN_TABLE 项目 README 调参节 示例 [4.867, 1.09, 0.243] 调参说明，非 DBC 内信号
    吉利缤越相关参数 项目 README 50 Hz 控制频次、最大转向力矩 598 README 自述规格

    读取方法与注意事项

    第一，先把「文件」和「已核验适配」分开。来源说明写得很清楚：上游 README 的宽泛车型列表不确立每个 DBC 对每种车型的适配，而 byd_all.dbc 的头部自述是「由运行时/导出资源重建」，因此其中的字段名多为占位名。把这样的文件直接当作某车某信号的权威定义，会混淆「存在」与「正确」。

    第二，同名不同内容要留意。快照里两份 byd_generic_pt 变体布局大体重叠，但报文明和信号名被改写成不同写法；byd_han_dmev_2020.dbc 也与之前归档的副本不同（改了两个踏板缩放、少了 4 条报文）。同名文件的差异本身就是证据链的一部分，不能互相替代。

    第三，权利层面要谨慎。来源说明指出：仓库快照里找不到许可文件，尽管 README 带 MIT 徽章。因此这些文件只适合作为私有研究副本，在对外分发或整合前应先确认原作者与再分发权利。

    第四，README 里的调参项（转向速率上限/回正速率、力矩模式表、离手维持参数）属于控制侧参数，不是 CAN 信号；它们与 DBC 里的报文定义分属两层。

    证据等级与边界

    可视为可核对的是「快照里实际存在这 7 个文件、各自多少条报文」——这来自来源说明的逐条登记。属于未确立的是各文件对应的具体车型适配：来源说明用「候选的逆向定义」来描述它们，并指出部分字段是占位名。

    不能外推的地方有三处。第一，DBC 里有报文不等于该车型在总线上真的以这个布局广播；需要实车抓包核对。第二，混淆/占位名使得信号语义不可靠，不能据此命名功能。第三，不同年款之间的报文集合可能有子集或超集关系，跨年款套用没有证据。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试；本文只整理公开文档登记的文件与规模，不涉及对车辆安全机制的规避，也不涉及任何报文写入操作。

    常见问题

    这些 DBC 能直接说明某款比亚迪车的某个信号定义吗？

    不能。来源说明指出这些是候选的逆向定义，上游 README 的宽泛车型列表不确立逐车型适配，且 byd_all.dbc 的字段多为占位名；要确认某个信号，需要实车抓包核对。

    为什么有两个名字几乎一样的通用 DBC？

    来源说明登记了两份 byd_generic_pt 变体：布局大体重叠，但报文明与信号名被改写成不同写法；它们是同名不同内容，不能互相替代。

    这些文件有开源许可吗？

    来源说明称仓库快照里找不到许可文件，尽管 README 带 MIT 徽章；因此应先确认原作者与再分发权利，仅作私有研究副本使用。

    文件里的报文数加起来代表整车所有报文吗？

    不代表。各文件是不同来源与年份的候选集合，byd_all.dbc 有 124 条、byd_song.dbc 有 89 条、雷达到只有 4 条；它们不是同一辆车的完整报文表。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/yuluoqingcheng-byd-dbc/README.md（主来源：项目自述、车型代号表与调参说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/yuluoqingcheng-byd-dbc/SOURCE.md（快照范围、7 个 DBC 的报文数与许可提示）。

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

    更新记录

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

  • 菲亚特 Grande Punto：29 位 UDS 与 105 个 DID 的读取边界

    结论：在一辆南非市场的菲亚特 Grande Punto（平台 199）1.4 8V（发动机 350A1000，Magneti Marelli IAW 5SF9 发动机 ECU）上，诊断走 29 位标识符、500 kbps 的 C-CAN，应用层是 UDS（ISO 14229），传输层是 ISO 15765-2，采用常规固定寻址（请求 18DAxxF1、应答 18DAF1xx）。这台车最关键的一条工程特性是：发动机 ECU 只接受不填充的帧，数据长度必须等于真实长度，这正是自动协议搜索与多数通用 OBD 应用连不上的原因；标准 OBD-II（模式 01 至 0A）也不应答，属非 EOBD 合规。边界：全部结论出自这一辆车与这份只读研究，不能套到其他校准或车型。

    本文整理自该项目的协议文档与示例结果。文档把每条记录分为「Observed（本车读出）」与「Published（取自公开来源、未在本车确认）」，本文保留这一区分。

    车辆与适用范围

    数据来自一位研究者的这一辆 Grande Punto，用一款 ELM327 兼容蓝牙适配器加一台 Linux 主机接入。工作方式偏保守：先适配器自身，再被动监听，然后标准请求，最后才是有寻址的厂家请求；并且全程只读，不发送清除、写入、执行器测试、安全访问或编程会话。

    项 内容
    车型 菲亚特 Grande Punto（平台 199）1.4 8V，发动机 350A1000，南非市场
    年款 / 市场版本 源文档未给出具体年款；市场为南非
    ECU / 改装状态 发动机 ECU：Magneti Marelli IAW 5SF9，名称 5SF9AG，硬件 IAW5SFHW405，软件 881AW23E，Fiat 件号 51926690
    采集跨度 若干次只读会话；一次怠速分析含 6 段共 5995 帧
    适用范围 仅这一辆车与这一套校准；不得假设其他校准或车型相同

    总线与寻址

    物理层是 OBD 引脚 6 / 14 上的 C-CAN，500 kbps，29 位标识符；传输层为 ISO 15765-2 常规固定寻址（请求 18DA + 目标 + F1，应答 18DAF1 + 目标）。本车一大特性是不能填充，数据长度须等于真实长度；流控帧为三字节 30 00 00，须在首帧后数毫秒内跟上。

    项 内容
    物理层 C-CAN，OBD 引脚 6 / 14，500 kbps
    链路层 29 位标识符；ISO 15765-2（ISO-TP）常规固定寻址
    寻址 请求 18DA + 目标 + F1；应答 18DAF1 + 目标
    帧填充 发动机 ECU 不接受填充，数据长度须等于真实长度
    流控 30 00 00 三字节，须在首帧后数毫秒内
    应用协议 UDS（ISO 14229）；标准 OBD-II 模式 01 至 0A 不应答

    已解码信号

    下表混合数据标识符（DID）与广播帧字段两类。证据一列沿用文档口径：「本车读出」为在本车实测，「公开来源」为取自 Fiat 500 等同平台资料、未在本车独立确认。文档还提示：公开定义里发动机转速位偏移比本车实际晚一个字节，公开偏移应视为起点。

    信号 位置（DID / 帧） 解码 证据
    发动机转速 DID 1000 原始值 ÷ 4，转/分 本车读出；与广播 0618A001 交叉核对
    冷却液温度 DID 1003 原始值 − 40，摄氏度 跟随广播 0A18A001 字节 3；偏移为假设
    电池电压 DID 1004 原始值 ÷ 10，伏 本车读出；与适配器电压表一致
    运行计数 DID 1008 运行时约每分钟 +1，可能是分钟计 本车读出
    启动后计时 DID 1009 约每 15 秒 +1，单位未知 本车读出（刚启动后读数为 1）
    目标怠速 DID 186B 原始值 ÷ 4，转/分（700；开空调 850） 本车读出；转速 1000 随后一拍跟随
    大气压 DID 1956 毫巴 可能（静止且数值符合海拔）
    进气歧管压力 DID 181F 毫巴 可能（随负荷变化）
    电池电压（第二路） DID 197D、197E 原始值 ÷ 10，伏 本车读出；与 1004 一致
    氧传感器电压 DID 1898、189A 毫伏（在稀 / 浓之间摆动） 可能
    发动机转速（广播） 帧 0618A001 字节 2-3（大端） 1 转/分/位；字节 7 为油门踏板 转速与 1000 一致；踏板为公开来源
    冷却液温度（广播） 帧 0A18A001 字节 3 原始值 − 40，摄氏度 跟随 1003；比例为公开来源
    节气门位置（广播） 帧 0628A001 字节 4 怠速时 4 至 7 个计数 公开来源
    备件号 DID F187 文本 51926690 本车读出

    读取方法与注意事项

    先做被动监听。先静默监听确认总线活着，再用最简请求（TesterPresent）扫地址。这台车上，3E 00 得到干净的 7E 00，证明它讲 UDS；而 1A 80 得到 7F 1A 11（服务不支持），说明它不讲 KWP2000。否定应答也是成功，因为它证明寻址与帧格式是对的。

    不填充与流控交给适配器。关键一步是关闭格式化（ATCAF0）并启用可变数据长度（ATV1），由自己写 ISO-TP 长度字节。长应答以首帧发出后需流控；经蓝牙往返太慢时发动机 ECU 会放弃，故让适配器自行发送三字节流控。

    读取成本要知道。一次遍历 105 个标识符约需 14.4 秒，因此比这更快的信号都会被欠采样；模块地址扫描（256 个）约 54 秒，整个 16 位空间约需 3.6 小时。

    只读边界。文档强调这是只读研究：写入、清除、例行程序、安全访问与复位服务从未发送。本文同样不涉及安全访问绕过；源文档未提供此类方法，也不建议尝试。

    证据等级与边界

    文档用「Observed」标记本车读出，用「Published」标记取自 Fiat 500 等同平台资料、未在本车独立确认的内容。因此表中带「公开来源」「可能」「假设」字样的条目尚未在本车成立。

    识别侧证据较硬：F187 备件号、F192 供应商硬件号、F194 供应商软件号、F196 ECU 名称都能读出；发动机 ECU 的 VIN 字段（F190）为空，VIN 由地址 40 的车身电脑返回。应答模块只有四个：10 发动机、28 ABS、30 电动助力转向、40 车身电脑，其余全静默。

    来源说明把范围写得很清楚：只有这一辆南非市场的 Grande Punto 1.4 8V，不要假设其他校准或车型布局相同；这是「诊断 / 信号研究集合，而非 DBC」。据此，本文的 DID 含义、比例与广播偏移不能外推到其他 Grande Punto 或其他 Fiat 车型。

    常见问题

    为什么通用 OBD-II 读不到这台车？

    因为这台发动机 ECU 非 EOBD 合规，标准 OBD-II 模式 01 至 0A 在任何协议上都不应答；加上它只接受不填充的帧，自动协议搜索与多数通用应用都会失败。作者改用 29 位寻址加不填充帧后才得到首个应答（还是否定的 7F 1A 11）。

    为什么这台车要求帧不填充？

    文档实测：发动机 ECU 只接受数据长度等于真实长度的帧，填充帧得不到应答。ISO 15765 允许填充，多数 ECU 两种都收，但这台不收——文档指出，正是这一个细节让自动检测与通用应用全部失败。

    用服务 22 读 DID 需要先进入扩展会话吗？

    不需要。文档记录 22 xxxx（ReadDataByIdentifier）在默认会话即可工作，且进入扩展会话（10 03）并未解锁测试范围内的额外标识符。

    为什么用掩码 FF 读故障码会返回 27 条？

    因为掩码 FF 返回的是 ECU 能够 设置的记录、状态为 40（本周期未完成测试），那是监控项清单而非故障清单。文档建议用具体掩码：08 读已确认、04 读待定、01 读当前正在发生。

    这些 DID 能套到别的 Grande Punto 吗？

    不能。来源说明写明只有这一辆南非市场的 1.4 8V 车，且这是一个研究集合而非 DBC；不同校准或车型的布局可能不同，需逐车复核。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/ryancoxrbc-fiat-grande-punto/docs/protocol.md（本项目车型档案主来源，取用了物理层 / 传输层、DID 表与广播帧表）。
    • 项目 01 —— public-can-dbc-datasets/additional/ryancoxrbc-fiat-grande-punto/docs/example-results.md（取用了怠速捕获统计与读取耗时）。
    • 项目 01 —— public-can-dbc-datasets/additional/ryancoxrbc-fiat-grande-punto/SOURCE.md（取用了「仅此一辆车、研究集合而非 DBC」的边界说明）。

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

    更新记录

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