标签: 车型档案

  • 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

  • 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

  • 方程式赛车总线档案: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

  • 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

  • Honda Civic FL5:25 个 DID 与 109 个 CAN 信号

    结论:Honda Civic FL5 的数据特征与多数车相反:OBD 口后面存在网关,且总线上几乎抓不到周期性广播帧——必须用 UDS 服务 22(ReadDataByIdentifier)主动向四个模块索取 DID,才能读到 25 个 DID、109 个信号。正因为如此,DBC 不适合做这辆车的主格式。以下所有结论仅限源文档记录的这一台车与其固件版本,不代表同型号其他车辆。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 Honda Civic FL5 的诊断数据整理。项目以 UDS 服务 22 的读取结果为基础,按模块组织成 DID 与信号清单,并对每条信号标注了证据等级。

    项 内容
    车型 Honda Civic FL5
    年款 / 市场版本 源文档未确认
    ECU / 模块 共 4 个:0x10 ECM、0x28 VSA、0x30 EPS、0x60 仪表(组合仪表)
    采集跨度 数据集 25 个 DID、109 个信号;源文档记录版本 1.0.1
    适用范围 仅限源文档记录的这一台车与其固件;DID 布局与信号刻度不保证适用于其他年款或市场版本

    总线与寻址

    这辆车是经典 CAN 加主动诊断读取的典型:总线上没有可供解析的周期广播流,价值的全部来源是「问—答」。因此寻址方式、传输层时序与请求节奏比 DBC 更重要。

    项 内容
    物理层 / 速率 经典 CAN 2.0B,500 kbit/s,无 CAN FD
    接入点 标准 OBD-II(J1962)引脚 6 / 14
    网关 OBD 口后存在网关;源文档实测总线上为零周期性广播帧
    诊断寻址 29 位 ISO 15765 物理寻址:请求 18DA<目标>F1,应答 18DAF1<目标>,诊断仪地址固定为 F1;功能广播为 18DB33F1
    传输层 ISO-TP(ISO 15765-2):首帧宣告长度,随后连续帧,接收方回 30 00 00 流控帧;数据区 54–63 字节,填充 0xAA
    11 位寻址 在 7E0 / 7E8 上发标准 Mode 01 无应答

    已解码信号

    下表从源文档的信号清单中抽取最具代表性的条目。项目的置信度分为「已确认(研究级)」「中」「低-候选」三档,表中原样保留该标注;标为「中」的条目表示解码方向明确但仍缺独立旁证。

    信号 位置(ID / DID / 字节) 解码 证据
    ENGINE_RPM(发动机转速) DID 0x2610 B6:B8 raw × 0.25 rpm 已确认(研究级)
    MAP_ABS(绝对进气压力) DID 0x2610 B9:B11 raw × 0.0078125 kPa 已确认(研究级)
    ECT(冷却液温度) DID 0x2610 B11 raw − 40 ℃ 已确认(研究级)
    VEHICLE_SPEED(车速) DID 0x2610 B18 raw km/h 已确认(研究级)
    OIL_PRESSURE(机油压力) DID 0x2610 B44:B46 raw kPa 已确认(研究级)
    OIL_TEMP_MODEL(机油温度模型) DID 0x268F B15 raw − 40 ℃ 已确认(研究级);源文档标注该信号在公开资料中无先例
    BRAKE_PRESSURE(制动压力) DID 0x4005 B7:B9 raw − 25 bar 已确认(研究级)
    STEER_ANGLE(方向盘转角) DID 0x48BD B11:B13 s16 × 0.1° 已确认(研究级)
    WHEEL_SPEED_FL / FR / RL / RR DID 0x48C4 B23:B31 raw × 0.01 km/h 已确认(研究级)
    STEER_MODE(转向模式) DID 0x48AC B1 枚举 中
    FUEL_LEVEL(燃油液位) DID 0x7029 B12:B14 raw × 0.01 L 已确认(研究级)
    AMBIENT_TEMP(环境温度) DID 0x7028 B17 raw ℃ 已确认(研究级)

    读取方法与注意事项

    这辆车读数据必须走 UDS 服务 22。请求用 29 位物理寻址发到 18DA<目标>F1,模块在 18DAF1<目标> 上应答;诊断仪地址固定为 F1,功能广播是 18DB33F1。注意 11 位寻址(7E0 / 7E8)上的标准 Mode 01 在本车上没有应答。

    一旦某个 DID 的应答超过单帧容量,就会落到 ISO-TP 分段传输:模块先发一个首帧(形如 10 29 …)宣告总长度,再发若干连续帧,诊断仪需要及时回一个流控帧 30 00 00 授权它继续。源文档特别指出,流控帧如果晚回几毫秒,ECU 会放弃整笔传输——所以「问得到」不等于「收得全」,接收端的流控时机是硬约束。

    工程上还要考虑读取节奏:同一模块上多个 DID 需要轮流询问,模块之间(ECM / VSA / EPS / 仪表)也要分配请求配额,否则在高频轮询时容易触发超时或让 ECU 返回否定应答。源文档记录了若干次安全访问被拒的情形,未提供绕过方法,也不建议尝试。

    证据等级与边界

    项目的证据等级分「已确认(研究级)」「中」「低-候选」三档。已确认条目既有编码依据也有行为或参考交叉验证;「中」表示解码方向明确但缺少独立旁证;「低-候选」则是尚未闭环的猜测。本文抽取的信号以已确认为主,并原样保留了 STEER_MODE 的「中」标注。

    项目文档中有一节专门列出「已推翻的说法」,条目数量在三十条以上——说明这辆车的诊断数据在公开讨论里存在大量误传。阅读时要把「已推翻」与「已确认」严格分开,不要把早期猜测当作结论使用。

    边界上必须强调:25 个 DID 与 109 个信号全部来自这一台车的这一版固件。不同年款、不同市场版本的 DID 编号、字节偏移与刻度都可能变化;同一 DID 在不同固件下含义也未必一致。任何实车读取都应在目标车上逐条复核。

    常见问题

    为什么这辆车用 DBC 解析不出来东西?

    因为源文档实测其总线上没有周期性广播帧,OBD 口后还有网关。DBC 描述的是「谁在什么时刻广播什么布局的帧」,而这辆车的数据要靠 UDS 服务 22 主动索取,表现形式是「问—答」而非广播,所以 DBC 不适合作主格式。

    读一个 DID 需要满足哪些传输层条件?

    用 29 位寻址发请求到 18DA<目标>F1,模块在 18DAF1<目标> 应答;如果应答超过单帧,模块会先发 ISO-TP 首帧宣告长度,诊断仪必须及时回 30 00 00 流控帧。源文档指出流控晚回几毫秒 ECU 就会放弃整笔传输。

    标准差一点的信号还能用吗?

    要按证据等级区分。标为「已确认(研究级)」的可以直接用;标为「中」的(如 STEER_MODE)解码方向明确但缺独立旁证,使用前应自行验证;「低-候选」的不要作为结论。源文档对每一条都保留了原始标注。

    这些 DID 能套用到别的 Civic 上吗?

    不能。源文档的全部结论限定在这一台车与其固件版本上,且明确 DID 编号、字节偏移与刻度都可能随年款或市场版本变化。换车使用前必须重新读取并复核。

    延伸阅读

    参考资料

    • 项目 02 —— public-can-dbc-datasets/additional/caldis-honda-civic-fl5-dids/README.zh-CN.md(本项目车型档案主来源)
    • 项目 02 —— public-can-dbc-datasets/additional/caldis-honda-civic-fl5-dids/CHANGELOG.md(版本与已推翻说法的变更记录)
    • 项目 02 —— public-can-dbc-datasets/additional/caldis-honda-civic-fl5-dids/SOURCE.md(数据集版本与来源说明)

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

    更新记录

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

  • 2025 Ford F-150 Gen14 的 HS-CAN3 车身信号接入

    结论:这份档案记录的是一台 2025 款福特 F-150(第 14 代)上的车身 CAN 接入实践:车主没有从 OBD 诊断口取数,而是接到 HS-CAN3(500 kbit/s) 上的 C3154A(音响功放)连接器,用 ESP32 板读取床灯、门锁、变速箱 P 挡与电池状态,并反过来驱动床灯与工具箱继电器。它的价值不在「有多少条解码」,而在于一条不改原厂线束的取数路径:具体车身报文的逐字节定义并不在这份文档里,而是引用自公开的 ford_lincoln_base_pt.dbc。下述结论仅限源文档记录的这一台车,不能外推到其他年款、配置或市场版本。

    车辆与适用范围

    源文档是一位车主对自己车辆的改造记录,属于单台车、单人实验,不是车厂或第三方机构的批量采集。文档明确声明「不提供任何支持」,并反复警告接线错误可能危及生命。

    项 内容
    车型 Ford F-150(Generation 14,2025 款),Lariat V8
    年款 / 市场版本 2025 款;源文档未给出市场版本,仅说明为 501A Mid 配置包(无车内氛围灯、无 Bed Utility Package)
    ECU / 改装状态 原厂未改动线束;作者以尾插(pigtail)转接件接到 C3154A,追求「可完全还原」
    采集跨度 源文档未给出日志数或帧数;固件附带 49 个原生单元测试
    适用范围 仅限这一台 2025 Gen14 F150;不同配置的车身电路差异很大(例:尾门独立锁电路只存在于低配车型)

    总线与寻址

    源文档从原厂维修手册得到各条总线的走向,最终选定 HS-CAN3 作为取数总线。物理接入走 C3154A:HS-CAN3 High 在 1 脚(22ga 绿-蓝线),HS-CAN3 Low 在 11 脚(22ga 白-绿线),连接器为 Molex 34728-0200;相邻的 C3154B 提供常电(SBA40,40 号保险)与接地。

    项 内容
    物理层 双绞线 CAN,HS-CAN3 高/低线;需 120Ω 终端
    链路层 / 比特率 500 kbit/s(源文档明示 HS-CAN3 at 500kbps)
    寻址方式 源文档未给出 11 位 / 29 位说明;报文的逐字节定义引用自外部 DBC
    CAN FD 源文档提到曾用某款双通道 CAN FD HAT 抓包,但未说明车辆是否运行 CAN FD;实际按 500 kbit/s 经典 CAN 处理
    接入硬件 AutoSport Labs ESP32-CAN-X2(ESP32-S3 + 双收发器 + 车规电源),Arduino 框架 + PlatformIO

    已解码信号

    这份主素材没有给出任何逐字节报文 ID,它记录的是「这台车被读取/被控制的功能清单」以及对应的硬件引脚。为守住「只抄源文档里有证据的条目」这条线,下表登记源文档明确写出的功能与位置,涉及具体 ID、字节与缩放的条目一律指向被引用但未包含在本快照内的 DBC。

    信号 / 功能 总线或位置 方向 证据
    床灯(CHMSL bed lights)状态 HS-CAN3 只读 README「Features」
    迎宾灯 / 水坑灯(puddle lamp)状态 HS-CAN3 只读 README「Features」
    车门锁状态 HS-CAN3 只读 README「Features」
    变速箱 P 挡状态 HS-CAN3 只读 README「Features」
    蓄电池状态 HS-CAN3 只读 README「Features」
    床灯继电器输出 GPIO5(BEDLIGHT_PIN) 写 README「Configuration」
    工具箱开启继电器 GPIO4(TOOLBOX_OPENER_PIN) 写 README「Configuration」
    工具箱解锁按钮 GPIO17(TOOLBOX_BUTTON_PIN) 读 README「Configuration」
    系统就绪指示 GPIO18(SYSTEM_READY_PIN) 写 README「Configuration」
    CAN 缓冲溢出计数 MCP2515 / TWAI 诊断 诊断 README「Buffer Overflow Detection」
    TWAI 驱动状态 运行时诊断 诊断 README「can_status」
    RX / TX 错误计数(<128 为健康) 运行时诊断 诊断 README「can_status」

    读取方法与注意事项

    接入顺序在源文档里有明确交代:先在手套箱后方的在线连接器上反探测做初步实验,因为车尾拖车连接器处在车辆未运行时「似乎不广播有用报文」。确定 HS-CAN3 承载所需信号后,才改到 C3154A 做正式取数。取数用尾插转接件,不切断原厂线束;文档强调压接与焊点都要做拉拔测试。

    软件侧,固件通过串口(115200)提供诊断命令:can_status 看驱动状态与错误计数,can_debug 连续 10 秒打印全部报文,can_buffers 看缓冲溢出,can_reset 做恢复。若完全收不到报文,文档建议先把 ENABLE_HARDWARE_CAN_FILTERING 置 0 再编译烧录,以排除过滤配置问题。

    一个明确的工程约束是缓冲深度:源文档指出 MCP2515 的硬件缓冲只有 2 条报文,会丢帧。文档给出的缓解方向包括把主循环延时(当前 10ms)调小、把 MAX_MESSAGES_PER_LOOP(当前 10)调大,或改用 ESP32 的 TWAI 控制器。溢出会表现为「繁忙期报文突然停止」「日志出现 Suspected buffer overflow」「静默后出现突发」等。

    证据等级与边界

    本档案的信号清单属于单车主记录:只有一台 2025 Gen14 F150 Lariat V8(501A Mid)作为样本。总线走向、连接器针脚、GPIO 分配这些属于实车观测与手册交叉,可核对;而「车身报文里门锁、床灯具体是哪个 ID、哪些字节」在本文档里没有答案,它来自作者引用的公开 DBC,属于外部旁证,本项目并未逐条复现。

    三处不能外推。第一,配置差异会改变电路:源文档明确说只有低配车型才为尾门保留独立锁电路,而带电动尾门的高配由尾门内模块控制——同型号不同配置不得套用。第二,接入点与线序是针对这台车枚举出来的,其他年款/市场的 HS-CAN3 连接器编号与针位可能不同。第三,作者本人声明不提供任何支持,并警告可能失去保修、损坏车辆甚至造成人身伤害,因此任何照搬都超出源文档的证据范围。

    关于「安全访问」类问题:源文档未提供任何绕过方法,且不建议尝试;本文只整理公开文档登记的可读/可控功能,不涉及对车辆安全机制的规避。

    常见问题

    2025 F-150 的 OBD 口能直接抓到这些车身信号吗?

    源文档没有走 OBD 诊断口,而是接到 HS-CAN3 的 C3154A(音响功放)连接器。OBD 口在本车是否可读这些车身报文,源文档未给出结论,因此不能据此推断。

    为什么接上后收不到报文?

    文档给出的排查顺序是:先确认 CAN 高低线序与 120Ω 终端,再把 ENABLE_HARDWARE_CAN_FILTERING 置 0 用 can_debug 看总线上是否有任何流量,然后用 can_status 看错误计数,用 can_buffers 看是否溢出。若在车尾拖车连接器处取数,车辆未运行时可能本就没有有用报文。

    床灯和门锁的 CAN 报文 ID 是什么?

    源文档未给出具体 ID。它说明所需报文定义来自公开的 ford_lincoln_base_pt.dbc,本档案不代填字节与 ID。

    这套接入会不会影响保修?

    作者明确警告可能失去保修、烧毁车辆甚至危及生命,并声明不提供任何支持。本档案只是对公开文档的整理,不构成任何实车操作建议。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/jantman-ford-f150-gen14/README.md(本项目车型档案主来源:车辆信息、硬件、接线、固件与诊断说明;本快照仅含此文件)。

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

    更新记录

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

  • openpilot legacy 支持矩阵:可读车型与低速边界登记表

    结论:这份「车型 CAN 数据档案」记录的不是某一辆车的逐条报文,而是一套多车型支持矩阵:源文档以「原车纵向 / 自控纵向、出厂 ACC 是否被替换、低于多少速度不可用」为列,逐平台登记可读能力,并说明车辆数据由 opendbc 目录下的文件解释。换言之,它回答的是「这台车能否被读取、由谁供给纵向控制、低速边界在哪」,而不是「0x1XX 的第几个字节是什么」。下述结论仅限源文档登记的那份 legacy 支持清单,不能外推到清单之外的车型、年款或市场版本;源文档本身也未提供任何逐信号 DBC 定义。

    车辆与适用范围

    源文档是一份开源驾驶辅助系统的总览说明,覆盖其官方支持与社区维护两级车辆名单。数据来自该项目的公开文档快照,不是对某台实车的采集记录,因此这里不存在「采样了几小时、几万帧」的采集跨度,只有一份能力登记表。

    项 内容
    车型 多品牌多车型的平台集合(Acura、Honda、Hyundai、Lexus、Toyota、Subaru、Volkswagen 等)
    年款 / 市场版本 以「美国市场参照(US Market Reference)」列登记,年款随平台不同;源文档未确认其他市场版本的对应关系
    ECU / 改装状态 分「官方支持」与「社区维护」两级;部分平台需断开驾驶员支持单元(DSU)或加装 ASCM 线束才能由本系统接管纵向
    采集跨度 源文档未提供日志数或事务数,仅提供能力矩阵与目录结构
    适用范围 仅覆盖源文档列出的平台与年款区间;社区维护平台未被上游安全模型验证

    总线与寻址

    源文档不描述物理层细节,只在目录结构中说明 opendbc「展示如何解释来自车辆的数据」,并由 selfdrive/car 承载各车型的状态读取与执行器控制。也就是说,寻址方式、比特率与帧格式都在被引用的 DBC 与车型代码里,本快照未包含这些定义本身。

    项 内容
    物理层 源文档未给出(由各车型 DBC / 适配器决定)
    链路层 / 比特率 源文档未给出
    寻址方式 源文档未给出;仅提及 opendbc 存放「如何解释数据」的文件
    CAN FD 源文档未提供该版本是否包含 CAN FD 车型
    承载硬件 EON DevKit 或 comma two,配合车型线束;实验场景可用带外置摄像头的 Ubuntu 电脑

    已解码信号

    本项目的源文档是一张能力矩阵,而非逐信号解码表。为保持「只抄源文档里有证据的条目」这一原则,下表登记的是源文档逐平台明确给出的可读字段(支持包、ACC 供给方、低速边界),并逐条注明证据页。任何涉及具体字节、DID 或缩放系数的内容,源文档均未提供。

    平台(美国市场参照) 支持包 可读字段(ACC 供给 / 低速边界) 证据
    Acura ILX 2016-19 AcuraWatch Plus ACC 由本系统供给;低于 25mph 不可加速;低于 25mph 无 ALC Supported Cars 表
    Acura RDX 2019-21 All ACC 保留出厂;低于 0mph 不可加速;低于 3mph 无 ALC Supported Cars 表
    Honda Accord 2018-20 All ACC 保留出厂;低于 0mph 不可加速;低于 3mph 无 ALC Supported Cars 表
    Honda Civic Sedan/Coupe 2016-18 Honda Sensing ACC 由本系统供给;低于 0mph 不可加速;低于 12mph 无 ALC Supported Cars 表
    Honda CR-V 2017-20 Honda Sensing ACC 保留出厂;低于 0mph 不可加速;低于 12mph 无 ALC Supported Cars 表
    Hyundai Palisade 2020-21 All ACC 保留出厂;低于 0mph 不可加速;低于 0mph 无 ALC Supported Cars 表
    Lexus ES 2019-21 All ACC 由本系统供给;低于 0mph 不可加速;低于 0mph 无 ALC Supported Cars 表
    Toyota Camry 2018-20 All ACC 保留出厂;低于 0mph 不可加速;低于 0mph 无 ALC Supported Cars 表
    Toyota Corolla 2020-21 All ACC 由本系统供给;低于 0mph 不可加速;低于 0mph 无 ALC Supported Cars 表
    Toyota Rav4 2019-21 All ACC 由本系统供给;低于 0mph 不可加速;低于 0mph 无 ALC Supported Cars 表
    Toyota Prius 2016-20 TSS-P ACC 保留出厂;低于 0mph 不可加速;低于 0mph 无 ALC Supported Cars 表
    Subaru Forester 2019-21 EyeSight ACC 保留出厂;低于 0mph 不可加速;低于 0mph 无 ALC Supported Cars 表
    Volkswagen Golf 2015-19 Driver Assistance ACC 保留出厂;低于 0mph 不可加速;低于 0mph 无 ALC Community Maintained 表

    读取方法与注意事项

    源文档给出的操作条件集中在安装与接入层面:安装时在设备安装向导中输入指定的安装地址,随后按视频说明把设备固定到风挡;设备自带位姿自动标定,轻微的俯仰、偏航安装误差不影响性能。上车前需先确认当地法规是否禁止在风挡上放置物品。

    数据层面,源文档说明系统会记录面向道路的摄像头、CAN、GPS、IMU、磁力计、温度传感器、碰撞与系统日志;面向驾驶员的摄像头仅在设置中显式开启时记录,麦克风不记录。因此从 CAN 侧能拿到什么,取决于各车型的 opendbc 定义与本机车型代码,源文档并未展开。

    能力边界方面,官方支持的车型将被纳入上游安全模型验证;社区维护车型未被验证,需要先在 Settings->Developer->Enable Community Features 中打开开关才能使用,且使用时须格外谨慎。若要把社区平台提升为官方支持,需满足:brand 下至少拥有一辆车、对应线束在售、panda 与本系统均具备完整 ISO 26262 支持、存在纵向控制的推进路径、AEB 仍保持启用、且支持 fingerprinting 2.0。

    证据等级与边界

    本文全部内容属于「文档登记」,既不是实车观测,也不是外部旁证。能力矩阵中的每一行都来自源文档的表格,可核对;但表格只回答「该平台被登记为支持/社区支持」,不保证具体年款、市场版本、配置包与软件版本都能匹配。源文档用「美国市场参照」列明确提示了这一点。

    三处不能外推。第一,低速边界(No ACC accel below、No ALC below)是按平台登记的名义值,不是对某一台实车测得的曲线,同型号不同配置可能不同——例如源文档用脚注说明 2019 Honda Civic 1.6L Diesel Sedan 在 12mph 以下无 ALC,Camry 的 4CYL 部分配置边界为 28mph。第二,断开 DSU 或加装 ASCM 线束会让本系统接管 ACC,但同时关闭 AEB,这是功能取舍而非免费升级。第三,车速相关字段(如 ALC 边界)来自源文档表格,源文档未提供任何原始报文或 DBC 条目作为间接支持。

    关于「安全访问」类问题,源文档未提供任何绕过方法,且不建议尝试;本项目讨论的是公开文档登记的可读能力,不涉及对车辆安全机制的规避。

    常见问题

    这份档案为什么没有逐条 CAN 信号?

    因为主素材是一份多车型支持矩阵与安装说明,只登记「平台 / 支持包 / ACC 供给方 / 低速边界」四类字段,逐信号定义放在被引用但未包含在本快照内的 opendbc 文件中。这是素材本身的边界,不是解析遗漏。

    「ACC 由本系统供给」与「ACC 保留出厂」有什么区别?

    前者的纵向控制由本系统承担,后者仍由原车 ACC 执行、本系统只做横向。源文档同时提示:在部分平台上,需断开驾驶员支持单元(DSU)或加装社区 ASCM 线束才能切换,而这两种做法都会关闭原车 AEB。

    社区维护车型能当官方支持用吗?

    不能。源文档明确社区维护车型未经上游安全模型验证,须在开发者设置中手动开启社区功能,并提示使用时格外谨慎;升级为官方支持还需同时满足拥有车辆、线束在售、完整 ISO 26262、纵向路径、AEB 保持启用、支持 fingerprinting 2.0 等条件。

    低速边界能不能套用到同型号其他车?

    不建议。源文档的边界是按平台以「美国市场参照」登记的名义值,并以脚注给出个别配置的例外(如某柴油版 Civic 与部分 Camry 配置)。把它直接外推到其他年款、市场版本或配置,超出了源文档的证据范围。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/openpilotusers-opkr084-legacy-subset/README.md(本项目车型档案主来源:支持车型与社区维护车型矩阵、安装说明、目录结构)。

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

    更新记录

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

  • Vtrux 与 Coda EV:网关型改装车的 CAN 信号档案

    结论:Vtrux(2014 款 Silverado 1500 的 EREV 改装车)最典型的数据特征是「一车三总线 + 主动网关」:OBD-II 口后面不是一条总线,而是三条独立 CAN,由 VCM 做跨总线网关,并且 VCM 会主动改写 ECM 的发动机数据——真实转速只在 OBD 总线上,Vehicle 总线上是约 800 RPM 的合成值。同仓库记录的 Coda EV 则是「一车四总线 + 网关转发」。以下结论仅限源文档记录的这两辆车及其固件与校准。

    车辆与适用范围

    本文数据来自第三方开源项目对两台实车的逆向记录:一台是 2014 款 Silverado 1500 的 EREV 改装车 Vtrux,另一台是 Coda EV 纯电轿车,两者出自同一仓库。

    项 内容
    车型 Vtrux —— 2014 款 Silverado 1500 的 EREV 改装车;同仓库另记录一台 Coda EV 轿车
    年款 / 市场版本 Vtrux 底车为 2014 款;Coda 年款与市场版本源文档未确认
    动力与改装状态 A123 LFP 电池包 116 节串联,标称约 383 V(约 360 V@10% SoC 至约 422 V 充满);原 GM 变速箱换成双 Remy 电机配 Dana TM4 CO150 逆变器;Woodward Motohawk 整车控制器(Via Motors VCM)兼作 GM CAN 网关
    采集跨度 源文档为多条实车日志(充电、公路巡航、隔离与互锁故障、过热等场景)加台架回放,未给出统一时长与帧数
    适用范围 仅限源文档记录的这两辆车与所列日志;不适用于量产 Silverado,也不保证适用于同型号其他改装车

    总线与寻址

    两台车都以经典 CAN 与 11 位标准帧为主,源文档未给出这两辆车的总线波特率。Vtrux 的核心特征是「三总线 + 主动网关」,Coda 是「四总线 + 网关转发」。日志通道编号都会随采集器插拔顺序变化,因此必须按报文内容识别总线。

    项 内容
    帧格式 车控主用 11 位标准帧;Bel 充电机/逆变器与 DCDC 使用 29 位 J1939 扩展帧
    Vtrux 三条总线 Powertrain(DLC 引脚 CAN-H 1 / CAN-L 9)、Vehicle(引脚 6 / 14)、OBD(引脚 10 / 2)
    Vtrux 总线识别 含 0x051 即 Powertrain;含 0x1E5 与 0x500 即 Vehicle;含 0x040–0x044 即 OBD。不要用 0x441–0x464 判 OBD,该区间含被网关桥接的 GMLAN 报文
    Coda 四条总线 B CAN(引脚 2 / 3)、D CAN(引脚 10 / 11)、C CAN(引脚 7 / 15,直读单体电压)、Diag CAN(引脚 6 / 14,标准 OBD 引脚);另有不可经 OBD 访问的私有 Motor CAN(DLCM↔MCM)
    Coda 总线识别 C CAN 恒含 0x000–0x019(104 节单体电压);B CAN 含 0x1D5、0x48A、0x275、0x381、0x383;D CAN 含 0x308、0x312、0x325、0x330、0x580
    网关 Vtrux 用 VCM 跨三总线选择性桥接并改写 ECM 数据;Coda 用 GWM 把 Diag CAN 路由到 J1962 并选择性转发

    已解码信号

    下表从源文档已标注置信度的条目中抽取。Vtrux 的置信度分级为 CONFIRMED(编码与用途均已独立验证)、CONFIRMED-SYMM(由对称结构推出)、CONFIRMED-DECOMPILE(编码由反编译确认,用途仍为标签)、PARTIAL(编码确认但角色或刻度存疑)与 REMOVED(已按策略移除)。Coda 部分沿用源文档的 CONFIRMED 标注。

    信号 位置(ID / DID / 字节) 解码 证据
    bcm_soc(电池 SoC) 0x0410 B3 raw × 0.5 % CONFIRMED(与 0x411 高分辨率 SoC 相关 r=0.9999)
    bcm_ibat(电池电流) 0x0410 B4:B5(大端 uint16) raw × 0.025 − 1000 A CONFIRMED(raw=40000 对应 0 A,发电机启停处穿越零点)
    bcm_vbat(电池包电压) 0x0410 B6[3:0]:B7(12 位) raw × 0.25 V CONFIRMED(接触器闭合后与 GENE_HighPwr_Volt 差不超过 1.25 V;启动哨兵值 1023.5 V 表示无效)
    bcm_cell_vmax / vmin 0x0430 B0[4:0]:B1 / B2[4:0]:B3(13 位) raw × 0.001 V CONFIRMED(稳定窗口内 r 大于 0.99)
    bcm_cell_tmax / tmin 0x0430 B4 / B5 raw × 0.5 − 40 ℃ CONFIRMED
    bcm_lvbat(12 V 电压) 0x0430 B7 raw × 0.1 V CONFIRMED(140=14.0 V DCDC 工作,127=12.7 V 静置)
    bcm_mainc_stat(主接触器状态) 0x0440 B0[5:2](4 位,16 态) 状态机枚举 CONFIRMED(充电日志观测到 ALL_OPEN→CLOSE_MAINR→WAIT_PRECHARGE→… 的状态转移)
    bcm_vbus_pos / vbus_neg 0x0440 B4:B5[7:4] / B5[3:0]:B6(12 位) raw × 0.25 V / raw × 0.25 − 500 V CONFIRMED(正、负直流母线对地电压)
    GENE_Mot_Trq(发电机扭矩回馈) 0x0471 B0:B1(小端 uint16) raw × 0.125 − 4096 Nm CONFIRMED(与 0x051 扭矩指令相关 r=0.9984)
    GENE_HighPwr_Volt 0x0482 B1:B2[2:0](11 位小端) raw × 1 V CONFIRMED(高速巡航稳定在 383–384 V)
    GENE_HighPwr_Curr 0x0482 B3:B4[5:0](14 位小端) raw × 0.25 − 2048 A CONFIRMED(巡航约 −40 A)
    parkLockState(驻车锁状态) 0x055C B0[2:0](3 位,7 项) 枚举 CONFIRMED(两车原始日志交叉验证)
    ess_power(电池包功率) 0x0598 B0:B1 (raw − 32768)× 0.01 kW CONFIRMED(线上格式不变;源文档另记录某类商业诊断工具自身解码有偏置,该信号已迁出原 DBC 归入实验 DBC)
    VehicleOdometer(整车里程) 0x0625 B0:B1:B2(24 位大端) raw × 1 km CONFIRMED(日志 raw=95,517 km 与仪表读数一致)
    DLCM_TorqueRequest(Coda 扭矩请求) 0x212 B4[3:0]:B5(12 位 nibble 拆分) raw × 0.244 Nm,零点 raw=2000 CONFIRMED(与 0x1C0 扭矩相关 r=0.999,峰值 293 Nm)

    读取方法与注意事项

    最关键的工程约束是总线识别。两台车的日志通道号都不可信——采集器插拔顺序一变,同一通道对应的总线就变了。做法是用 anchor ID 判定:先用一条稳定广播的专属 ID 认出总线,再做解析。Vtrux 还提醒,0x441–0x464 区间混入了被 VCM 桥接到 Vehicle 总线的 GMLAN 报文,用它判 OBD 会误判。

    第二条是网关的影响。Vtrux 的 VCM 会对转发内容做改写:ECM 的真实转速只出现在 OBD 总线(0x0C9,熄火时为 0,运转时为真实值),而 Vehicle 总线上是约 800 RPM 的合成值。轮速被掩零后,ECM 自行算出零车速并广播 0x3E9,形成级联——这不是 VCM 直接改写车速,而是屏蔽输入后的自然结果。因此同一物理量在不同总线上可能有不同含义。

    第三条是周期与新鲜度。同一 ID 在不同固件上周期可能不同(例如某电池电流报文在一种 BMS 变体上是 1 Hz,另一种上是 10 Hz),源文档做相关分析时对不同周期分别用了零阶保持与线性插值,并指出周期差异会影响标定。解析前应先统计每个 ID 的实测频率。

    证据等级与边界

    源文档对每条信号都给了证据分级。CONFIRMED 表示编码与用途都被独立验证(物理试验、日志相关或与参考交叉匹配);CONFIRMED-DECOMPILE 只说明编码来自反编译,用途仍是原厂标签;CONFIRMED-SYMM 由已确认信号的对称结构推出,没有独立测试;PARTIAL 表示编码确认但角色或刻度仍有未决问题——例如油压信号 GeneOilPress 的零点偏移未确认,其换算在怠速下会得到物理上不合理的数值。

    还有一类被明确记录为「异常」的条目。0x0451 曾被某类商业诊断工具误标为牵引逆变器扭矩,日志显示它其实是 GMLAN 报文,源文档已把对应条目移除;牵引逆变器热信号的真实 ID 是 0x044A,而非工具里列的 0x0459(后者在所有日志中为零帧)。

    边界上必须强调:以上结论仅来自源文档记录的这一台 Vtrux 与这一台 Coda 及其固件与校准。不同年款、不同 BMS 变体,甚至同一车型换了电池包,位置与刻度都可能变化,实车读取前应先在目标车上复核。

    常见问题

    Vtrux 的 OBD 口能直接抓到全部三条总线吗?

    三条总线在 J1962 口上都有引脚可达(Powertrain 1/9、Vehicle 6/14、OBD 10/2),但日志里的通道号是任意的,必须用 anchor ID 判断当前通道对应哪条总线。另外 VCM 会对桥接内容做过滤与改写,因此「在车上抓到」不等于「拿到原始数据」。

    为什么同一辆车上车速会有两个来源?

    因为 VCM 掩零了发给 ECM 的轮速输入,ECM 于是算出零车速并广播 0x3E9,OBD 总线上的该广播因此恒为零。真实车速在 Vehicle 总线上,由 VCM 用真实轮速生成;标准 OBD PID 0x0D 也返回真实车速,但它由 VCM 自己应答,而不是把请求桥接给 ECM。

    标注 CONFIRMED 的信号可以直接拿来用吗?

    可以用,但要区分级别。CONFIRMED 表示编码与用途都被独立验证;CONFIRMED-DECOMPILE 与 CONFIRMED-SYMM 只解决了「编码是什么」,用途仍是推断或标签,源文档已明确保留这一不确定性。PARTIAL 条目在使用前应先补验证。

    这些解码能套用到别的 Vtrux 或 Coda 上吗?

    不能。源文档的全部结论都限定在被记录的这两辆车及其固件与校准上,并明确指出不同 BMS 变体、不同固件之间字节偏移与周期存在差异。换车使用前必须重新复核。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/nickyivyca-vtrux-coda/projects/vtrux/README.md(Vtrux 总线、网关与模块拓扑主来源)
    • 项目 01 —— public-can-dbc-datasets/additional/nickyivyca-vtrux-coda/projects/vtrux/notes/epri-verification.md(已解码信号的置信度分级与证据)
    • 项目 01 —— public-can-dbc-datasets/additional/nickyivyca-vtrux-coda/projects/coda/README.md(Coda 四总线、anchor ID 与解码条目)

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

    更新记录

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