标签: 车型协议

  • Ioniq 5 电池预热的 CAN 报文:两段最小可复用样本

    结论:这份档案记录的是现代 Ioniq 5 / 6 / EV6(E-GMP 第一代)电池预热(preconditioning)手动开关背后的最小可用 CAN 报文集合(MWE)。源文档把 2021–2024 年 E-GMP 车上的「触发预热」与「取消预热」压缩成两份可回放的报文集,其中主触发报文 ID 为 0x4ED,取消报文涉及 0x0C7。要点在于:预热可以只用少数几条报文、靠被动旁听加回放实现,不需要车机越狱。需要注意,随本快照归档的是作者过滤后的回放样例,不是原始全总线抓包,也没有配套 DBC。

    车辆与适用范围

    源文档是一个硬件改装的公开文档仓库,围绕「给 Ioniq 5/6/EV6 增加一个手动预热按钮」展开,CAN 报文逆向是其中一环。

    项 内容
    车型 Hyundai Ioniq 5 / Ioniq 6 / Kia EV6(E-GMP 第一代,带电池 PTC 加热器)
    年款 / 市场版本 源文档讨论 2021–2024 年 E-GMP 车;这两份 CSV 的采集车年款/配置/市场/固件未指定
    ECU / 改装状态 加装微控制器注入 CAN 报文(WiCAN 系硬件)+ 线束;也用 WiCAN 网页远程开关
    采集跨度 两份最小可用样本:MWE_preconditioning.csv(230 行)与 MWE_cancel_preconditioning.csv(5 行)
    适用范围 仅限带 PTC 加热器且已启用预热模式的 E-GMP 车;源文档称必要报文于 2026 年 3 月分离出来

    总线与寻址

    源文档的样本以 SavvyCAN 兼容文本保存(时间戳单位为微秒),列含 ID、扩展帧标志、方向、长度与数据字节。抓取工具为 WiCAN Pro(另一份清单说明还用了 SavvyCAN)。下表按这两份 CSV 可确认的内容填写,未给出的一律标注「源文档未给出」。

    项 内容
    物理层 源文档未给出(经 OBD 形态的 WiCAN 接入)
    链路层 / 比特率 源文档未给出
    寻址方式 样本中报文均为 11 位标准帧(Extended=false)
    CAN FD 样本未包含 CAN FD 帧;文档另提及第二代原型机才有一个 CAN FD 接口
    时间戳单位 微秒(SOURCE 说明)

    已解码信号

    下表登记的是这两份 CSV 里可核对到的报文与字段模式,逐条纹目均给出证据(文件名与行数)。源文档把整份材料定位为「MWE 回放样例」,因此没有更细的位域命名与缩放系数;相关的 DBC 由另一项目维护,不在本快照内。

    条目 位置(ID / 字节) 观测载荷(十六进制) 证据
    触发预热帧 0x4ED(8 字节) 00 00 00 00 00 FF FF 1F MWE_preconditioning.csv(230 行)
    触发帧的充电态变体 0x4ED D6–D8 00 00 00 00 00 09 90 00 同上
    取消预热帧 0x0C7(8 字节) 00 00 00 E0 07 00 00 00 MWE_cancel_preconditioning.csv(5 行)
    取消帧的状态字段 0x0C7 D4–D5 E0 07 同上
    触发日志中的另一变体 0x0C7 D4–D5 40 03 MWE_preconditioning.csv
    空闲/复位帧 0x0C7(全零) 00 00 00 00 00 00 00 00 两份 CSV 首帧
    采样工具 — SavvyCAN + WiCAN Pro README「Contents」
    样本规模 — 触发 230 行 / 取消 5 行 SOURCE 说明表

    读取方法与注意事项

    源文档给出一条很实用的方法论主张:一两份好日志比十份可疑日志更有价值。作者建议把日志采集当成一次科学实验——设计「测试条件」与「对照条件」,例如把导航设到附近的充电桩 vs. 设到附近的学校。若都没把握,就对大范围报文画时间曲线找线索。

    数据清理同样关键:作者提到清洗日志(例如剔除带缓冲数据造成的超范围时间戳)后才取得更好效果。文档还列出成套公开工具(含 SavvyCAN 社区分支、DBC 结构入门、基于 DBC 的绘图库等)。

    工程实现上,这套方案由五部分构成:CAN 报文、注入报文的微控制器、该微控制器的固件、把微控制器接到车的线束、以及触发预热的用户界面。触发方式从「用笔记本」到「用 panda 上的星形按钮」都有演示,当前用户界面支持映射到车上既有按钮,物理按钮仍在开发。作者也提醒:另一条「车机越狱」路线更偏技术、没有恢复出厂设置的兜底,且可能被后续 OTA 封堵。

    证据等级与边界

    本档案的证据层级需要分清。可核对的是文件与行数(230 行、5 行)、报文 ID 与字节(0x4ED、0x0C7 的观测载荷),以及工具链(SavvyCAN、WiCAN Pro)。而「这些报文在另一台车上就能触发预热」属于作者自述、未被本归档独立验证——来源说明明确写道:上游称这些报文能在带 PTC 的 Ioniq 5 上启动/取消预热,但本归档未独立复核解码、回放行为或兼容性。

    三处不能外推。第一,这是作者过滤后的回放样例,不是原始全总线抓包,也不是 DBC,因此不能据此推出整车信号全集。第二,采集车的具体年款/配置/市场/固件未指定,不能默认对所有 E-GMP 车成立。第三,文档提到后续 E-GMP 平台与软件版本可能变化,且越狱路线曾多次被封堵,说明结论有时效性。

    关于「安全访问」类问题:本文只整理公开文档登记的回放样例,未涉及安全访问的绕过;源文档未提供绕过方法,且不建议尝试。

    常见问题

    预热功能是主动问出来的还是被动听到的?

    这份材料记录的是可回放的最小报文集合:两段日志里反复出现的少数几条报文,被整理成可发送的样例。它不涉及对某个 ECU 的主动诊断轮询。

    0x4ED 和 0x0C7 分别是什么?

    按样本,0x4ED 出现在触发预热日志里(230 行,载荷在 FF FF 1F 与 09 90 00 之间切换),0x0C7 出现在取消日志里(5 行,含 E0 07)。本档案只登记观测到的载荷,不代填位域语义。

    能不能套用到其他 E-GMP 车?

    不能默认成立。来源说明指出,这两份 CSV 的采集车年款、配置、市场与固件均未指定,且本归档未独立复核解码与回放行为;要用于其他车辆须自行在实车上验证。

    这套方案需要车机越狱吗?

    不需要。源文档给出的主线是「微控制器 + 线束 + 用户界面」注入报文;文档另提到一条车机越狱路线,但指出它更偏技术、缺少恢复兜底,且可能被后续 OTA 封堵。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/tylerharvey-ioniq5-preconditioning/README.md(本项目车型档案主来源:项目背景、MWE 报文、方法论与工具清单)。
    • 项目 01 —— public-can-dbc-datasets/additional/tylerharvey-ioniq5-preconditioning/SOURCE.md(两份 CSV 的行数、校验值,以及「未独立验证」的边界声明)。
    • 项目 01 —— public-can-dbc-datasets/additional/tylerharvey-ioniq5-preconditioning/preconditioning_messages/MWE_preconditioning.csv(触发预热的最小可用样本)。

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

    更新记录

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

  • Ram ProMaster 2022:三总线与 19 个 UDS 模块

    结论:Ram ProMaster(2022 款,3.6 L Pentastar 配 ZF 948TE 变速箱)是典型的「三总线 + 安全网关」结构:C-CAN / HS-CAN(500 kbit/s,引脚 6/14)、B-CAN / CAN IHS(125 kbit/s,引脚 3/11)、CAN CH(500 kbit/s,引脚 12/13)三条总线速率与用途各不相同,OBD 口后面还有 SGW 安全网关。车速与整车里程在两条不同总线上各有来源,且源文档记录了两者不一致的验证结果。以下所有结论仅限源文档记录的这一台车。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 2022 款 Ram ProMaster 的总线映射与信号分析。项目先用双通道适配器分别接入不同总线,再通过 UDS 读取模块内的数据块,并对同一物理量在不同总线上的表现做交叉验证。

    项 内容
    车型 Ram ProMaster,2022 款
    动力总成 3.6 L Pentastar 发动机(PCM);ZF 948TE 变速箱(TCM)
    采集硬件 双通道 USBCANFD 适配器,两路分别映射到不同总线(源文档记录了通道与总线的对应关系)
    采集跨度 多次行车与静态采集,涵盖车速、里程、挡位与机油寿命等验证
    适用范围 仅限源文档记录的这一台车;不同年款或不同配置的总线拓扑与 UDS 地址都可能不同

    总线与寻址

    这辆车的接入难点在于「多条总线、多个速率,且后面有网关」。只有先确定每个物理接口对应哪条总线,后续的波形才有意义。

    项 内容
    C-CAN / HS-CAN 500 kbit/s,OBD-II 引脚 6 / 14;OBD 口后面存在 SGW(安全网关)
    B-CAN / CAN IHS 125 kbit/s,OBD-II 引脚 3 / 11
    CAN CH 500 kbit/s,OBD-II 引脚 12 / 13
    诊断寻址 29 位 ISO-TP 物理寻址,形如 18DAxxF1;源文档记录了 19 个模块的地址
    网关 SGW 位于 OBD 口之后;源文档中部分内部总线需要物理接入方式才能观察到,本文不复述具体做法,也不建议尝试

    已解码信号

    下表从源文档的行车分析与离线验证记录中抽取。项目对每一条都注明了验证方式(载体验证、相关系数或读取值),本文原样保留;被否决的条目也一并列出,以说明边界。

    信号 位置(ID / DID / 字节) 解码 证据
    车速 C-CAN 0x101 B0:B2 speed_raw = ((B0 & 0x01) << 11) | (B1 << 3) | (B2 >> 5) 已确认(轮速载体验证)
    车速(第二来源) C-CAN 0x0EE 约等于 8 × speed_raw 已确认(相关 r=0.9999919)
    输出轴转速 0x1F7 rpm 标定记录
    涡轮转速 0x1F7 rpm 标定记录
    整车里程 0x760(从位 8 起的 17 位大端) km 标定记录
    整车里程(ICS) B-CAN,UDS 服务 22 / DID 0x2001 u24 大端 × 0.1 km 已确认(与 0x760 交叉对照)
    机油寿命 PCM,UDS 服务 22 / DID 0x2185 百分比读数 已确认(读取值显示 82%)
    帧校验 0x101 B7 CRC-8 / SAE-J1850 标定记录
    变速箱挡位(候选) 0x1F4 内的 nibble 枚举 被否决(源文档否定该位置)

    读取方法与注意事项

    第一条是「先认总线,再看信号」。三条总线的速率分别是 500、125、500 kbit/s,若适配器接错引脚或用错速率,会直接抓不到帧。源文档为此专门记录了双通道适配器的角色映射,把每一路固定到指定总线。

    第二条是同一物理量的多来源问题。车速在 C-CAN 的 0x101 与 0x0EE 上都有表现(后者约为前者的 8 倍,相关系数 0.9999919),整车里程同时在 0x760 与 B-CAN 的 ICS 数据块里出现(后者由 UDS 服务 22 读 DID 0x2001 得到,u24 大端 × 0.1 km)。使用前应确定以哪一路为准,并核对两路是否一致。

    第三条是负向结果同样重要。源文档明确指出,CAN CH 上的七个高速 ID 都没有通过轮速载体验证——也就是说它们看起来像车速信号,但不能被证实。类似地,0x1F4 里被怀疑是挡位的那个 nibble 已被否决。这些「证伪」结论能避免后续误用。

    证据等级与边界

    源文档的验证手段主要有两类:一类用「轮速载体」做参照,把候选信号与已知的轮速做一致性比对;另一类用 UDS 读取模块自身的数据块(如机油寿命、ICS 里程)作为可信基准。通过比对的标为已确认,未通过的明确记为被否决,处于中间状态的则作为候选保留。

    关于网关,需要格外谨慎:OBD 口后的 SGW 会限制可观察范围,源文档记录的部分内部总线访问方式涉及对车辆网络的物理改动,本文不复述具体做法,也不建议尝试——这类改动有损坏车辆网络的风险,且可能不符合当地法规。

    边界上必须强调:以上总线拓扑、UDS 地址与信号刻度都限定在这一台 2022 款 ProMaster 上。不同年款、不同市场版本的模块地址、总线划分与信号位置都可能变化,跨车使用前必须重新验证。

    常见问题

    为什么这辆车要在三条总线上分别接线?

    因为三条总线的速率与用途不同:C-CAN / HS-CAN 是 500 kbit/s(引脚 6/14),B-CAN / CAN IHS 是 125 kbit/s(引脚 3/11),CAN CH 是 500 kbit/s(引脚 12/13)。用单一速率接单一引脚只能看到其中一部分数据,必须按总线分别接入并设置正确速率。

    车速信号有两个来源,该信哪个?

    0x101 与 0x0EE 上的车速高度相关(r=0.9999919,后者约为前者的 8 倍)。理论上两者一致即可互换使用,但源文档并未就此给出统一建议,使用前应自行在本车上核对两路是否始终一致,并确定以哪一路为准。

    被否决的信号还有参考价值吗?

    有。被否决说明「某位置不是挡位」这类边界已被排除,能避免后来者重复踩坑。源文档同时记录了「CAN CH 上七个高速 ID 均未通过轮速载体验证」这样的负向结论,同样缩小了搜索空间。

    这些 UDS 地址能直接用于别的 ProMaster 吗?

    不能。源文档记录的 19 个模块地址限定在这一台车上,不同年款或市场版本的模块地址可能不同。换车使用前必须重新枚举并复核。

    延伸阅读

    参考资料

    • 项目 05 —— public-can-dbc-datasets/additional/jakeiwen-promaster-2022/docs/bus-map.md(本项目车型档案主来源:三总线映射与 UDS 模块地址表)
    • 项目 05 —— public-can-dbc-datasets/additional/jakeiwen-promaster-2022/findings/2026-07-19_ccan_drive_signal_analysis.md(C-CAN 车速信号与 CRC 分析)
    • 项目 05 —— public-can-dbc-datasets/additional/jakeiwen-promaster-2022/findings/2026-09-22_gear_and_oil_life_offline.md(挡位否决与机油寿命读取)

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

    更新记录

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

  • PACMod 线控 v3 平台档案:4.0.0 到 14.1.0 演进

    结论:这份档案的对象是一套线控(drive-by-wire)硬件改装平台 PACMod 的 DBC 定义,适用于硬件版本 3 及以上,而不是某一款量产车型。它的数据特征不在「某条报文的第几字节」,而在协议随版本演进:源文档是一份从 4.0.0 一路记到 14.1.0 的变更日志,逐版列出新增/删除/改名的报文与信号,并记录了对缩放因子、DLC 与枚举值的破坏性修改。因此它的结论是「哪个版本有哪个信号」,而不是「某一辆车的信号地图」;源文档未给出比特率、寻址方式或逐字节定义,也未指定任何具体车型与年款。

    车辆与适用范围

    源文档是一份随线控硬件项目公开的 DBC 变更记录:它描述该平台对外的 CAN 协议面,用于兼容多种被改装的车辆,而非绑定单一车型。

    项 内容
    车型 搭载 PACMod 线控硬件(rev 3 及以上)的被改装车辆;源文档未指定具体车型
    年款 / 市场版本 源文档未确认
    ECU / 改装状态 线控改装平台,协议覆盖转向、制动、油门、变速箱、灯光、雨刮等子系统的命令与回报
    采集跨度 源文档为发布变更日志(记录至 14.1.0),不含实车日志或事务数
    适用范围 仅对应硬件版本 3 及以上的 DBC;版本不匹配时的报文/字段不可直接套用

    总线与寻址

    源文档以变更日志形式呈现,未描述物理层;它在一条沿革记录里提到曾把比特率补进协议说明文档,但本快照未给出该数值。

    项 内容
    物理层 / 比特率 源文档未给出(仅记录「已把比特率加入协议文档」)
    寻址方式 源文档未给出;命令与回报按 0x600–0x6FF 等地址段预留的描述出现过
    帧长度(DLC) 多次变更:如组件回报从 8 改为 4 字节;车速回报从 2 改为 1 字节
    CAN FD 源文档未提供
    命名约束 受 DBC 规范的 32 字符名称上限约束,超长信号名曾被统一缩短

    已解码信号

    下表抽取源文档变更日志中最有代表性的条目。位置列以「报文 / 信号」表示,解码列记录该版本发生的结构性变化(缩放、DLC、枚举、位域),证据列注明出现的版本号。

    信号 所属报文 该版本的变化 / 含义 证据(版本)
    CONTROL_STATUS / CONTROLLING_SYSTEMS / PERFORMANCE_STATUS TIPPER_BODY_RPT_00/01/02 新增状态字节信号 14.1.0
    DBW_WARNING_LEVEL DBW_HEALTH_RPT_00/01 及 COMPONENT_RPT_00–05 新增线控健康告警等级 14.1.0
    SELF_TEST_STATUS DBW_HEALTH_RPT_00/01 新增自检状态 14.1.0
    SELF_TEST_ALLOWED SAFETY_FUNC_RPT_2 新增是否允许自检 14.1.0
    DOOR_ANGLE / BODY_ANGLE TIPPER_BODY_AUX_RPT_00/01/02 由 ROLL_ANGLE/PITCH_ANGLE 改名而来 14.0.0
    VEHICLE_SPEED VEHICLE_SPEED_RPT 移除 VEHICLE_SPEED_VALID,改为 ERROR/NOT_AVAIL 枚举;DLC 由 2 改为 1 14.0.0
    ANGULAR_SPEED BRAKE_MOTOR_RPT_2 / STEERING_MOTOR_RPT_2 缩放因子由 0.1 改为 0.001 14.0.0
    (组件回报结构) COMPONENT_RPT 移除组件类型、系统存在标志、监督信号与 CAN 超时故障;新增本地状态机状态;DLC 由 8 改为 4 14.0.0
    GEAR_CMD / GEAR_RPT GEAR_CMD / GEAR_RPT 新增挡位命令与回报 13.2.0
    ACCEL_PEDAL_POSITION_VOLTAGE_RPT 等四路电压回报 同名回报报文 新增油门/制动/转向的电压型回报 13.2.0
    BRAKE_PRESSURE_2 / BRAKE_PRESSURE_2_AVAIL BRAKE_AUX_RPT / BRAKE_AUX_RPT_2 新增第二路制动压力及其可用位 13.1.0
    STEERING_FLUID_PRESSURE STEERING_AUX_RPT / STEERING_AUX_RPT_2 新增转向油压 13.1.0
    GNSS_TIME — 新增 GNSS 时间 13.1.0
    ACTUAL_GEAR_RATIO / DRIVELINE_ENGAGED / SHIFT_IN_PROGRESS SHIFT_AUX_RPT 新增实际传动比、传动系结合与换挡进行标志 12.2.0
    COUNTER / COMPLEMENT / SANITY_CHECK_REQUIRED GLOBAL_CMD 新增计数器、补码与合理性检查;配套定义全局命令合理性规则 11.1.0

    读取方法与注意事项

    源文档的读取要点可以归纳为一句:先锁版本,再谈解析。多处变更会破坏向后兼容:车速回报的 DLC 由 2 改为 1 字节,同时把原来的 VALID 位改为 ERROR/NOT_AVAIL 枚举;制动与转向电机回报的角度缩放从 0.1 改为 0.001;组件回报的 DLC 从 8 缩减到 4 并删除了若干字段。用错版本的解析器不会报错,只会静默给出量级错误的结果。

    信号语义方面,源文档反复强调三层数据状态的设计:命令类子系统普遍带 MANUAL_INPUT(人工输入)、COMMANDED_VALUE(被命令值)、OUTPUT_VALUE(实际输出值)三个信号,用来区分「人做了什么」「系统要求什么」「设备实际做了什么」;后续版本又为大量信号补上了 ERROR 与 NOT_AVAIL 枚举值,使「无效」与「不可用」可以被显式表达。解析时不能把这三层当成同一个量。

    命名与数值细节也需留意:负数按二进制补码表示(源文档在 13.0.0 明确写入协议说明);名称长度受 32 字符上限约束,因此会出现被缩短的名字;雨刮等子系统的高低中枚举值一度从 253/254/255 挪到 248/249/250,旧的硬编码会失配。此外,源文档把 VIN_RPT、WATCHDOG_RPT、YAW_RATE_RPT 标注为「不用于新开发」,其中 YAW_RATE_RPT 已在 14.0.0 被删除——任何依赖它的解析都应及时迁移。

    证据等级与边界

    本文的证据等级是「发布记录级」:每一条都能在变更日志里按版本号核对,属于源文档直接证据;但源文档没有任何实车观测或逐字节定义,因此本文不给比特位置、缩放公式的完整定义,只记录「发生过的变化」。要落到具体字节,必须回到对应版本的 DBC 文件与协议说明文档(本快照未包含)。

    两点不能外推。第一,本档案对应的是硬件 rev 3 及以上;更早硬件、或不同版本 DBC 之间的字段差异,源文档只以变更形式记录,不能假定向下兼容。第二,源文档未指定车型与年款,把某条信号的存在性外推到具体的被改装车辆上属于超范围推断。关于安全访问,源文档未提供任何绕过方法,且不建议尝试;本文只梳理协议面。

    常见问题

    为什么这份档案不写具体字节位置?

    因为主素材是发布变更日志,只记录各版本「新增/删除/改名/改 DLC/改缩放」的结构性变化,逐字节定义在被引用的 DBC 与协议说明文档里,本快照未包含。给出不存在的位域会违背「只写源文档里有的事实」。

    版本不一致会带来什么后果?

    会静默出错。例如车速回报 DLC 由 2 改 1、角度缩放由 0.1 改 0.001、组件回报 DLC 由 8 改 4,用错版本的解析器不会报错,只会给出量级错误的结果。因此必须先锁定硬件与 DBC 版本。

    MANUAL_INPUT、COMMANDED_VALUE、OUTPUT_VALUE 有什么不同?

    三者分别表示人工输入、系统命令值与设备实际输出值。源文档把这三个信号作为命令类子系统的标准配置,用于区分「人做了什么」「系统要求什么」「设备实际做了什么」,不能当作同一个量读取。

    YAW_RATE_RPT 还能用吗?

    源文档在 11.2.0 把 YAW_RATE_RPT 标注为「不用于新开发」,并在 14.0.0 将其移除。依赖它的解析应迁移到替代信号;继续使用旧字段会与新版协议失配。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/astuff-pacmod-v3/doc/changelog.md(本项目车型档案主来源:从 4.0.0 到 14.1.0 的报文与信号变更记录)。
    • 项目 01 —— public-can-dbc-datasets/additional/astuff-pacmod-v3/README.md(DBC 适用范围为硬件 rev 3 及以上,及对外文档入口)。

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

    更新记录

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

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

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

    车辆与适用范围

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

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

    总线与寻址

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

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

    已解码信号

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

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

    读取方法与注意事项

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

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

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

    证据等级与边界

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

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

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

    常见问题

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

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

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

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

    能不能直接用于实车?

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

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

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

    延伸阅读

    参考资料

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

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

    更新记录

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

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

    结论:这份档案的对象不是整车,而是一台 Bosch iBooster Gen1 制动助力器的 CAN 输出(Tesla 件号 1037123-00-B,清单标注适配 2016–2020 Model S),被装在 1987 年款的一台改装车上只读采集。它的数据特征是两条 500 kbps 总线、全部只读、状态藏在位置报文里:25/16 引脚的「Vehicle CAN」承载 16 位踏板行程 0x39D,18/10 引脚的「YAW CAN」承载 12 位位置 0x38E 与状态字节 0x38F;助力器只要接通 12V、地、点火即自行助力,不需要任何 CAN 输入。所有数值均为该实物单元的台架实测,不外推到其他 iBooster 变体、其他件号或其他车辆。

    车辆与适用范围

    源文档明确:这里的每一项都在本台实物上测得,不是从社区资料继承的;未验证的内容另列在待验证清单里。以下范围仅对应这一台助力器。

    项 内容
    车型 Bosch iBooster Gen1,Tesla 件号 1037123-00-B(清单标注适配 2016–2020 Model S);采集对象是助力器本身,非整车
    年款 / 市场版本 件号适配范围由源文档以清单形式标注;具体车辆年款未确认
    ECU / 改装状态 改装车(1987 年款)上的助力器,只读旁听,永不向助力器发送
    采集跨度 多份台架日志:0x38E 46,960 帧 + 0x38F 23,478 帧(合计 70,438 帧,跨四次上电);0x39D 校验在 2,250 帧上 100% 通过
    适用范围 仅本台实物;触点、装配与固件版本变化都可能改变结论

    总线与寻址

    两条独立总线均为 500 kbps、经典 CAN、11 位标识符,助力器对两条总线都不做内部终端。源文档特别强调:总线要靠内容识别,不能靠适配器索引或 USB 顺序。

    项 内容
    物理层 / 比特率 两条总线均 500 kbps;无内部终端
    「Vehicle CAN」 引脚 25 = CAN-H,16 = CAN-L,静止 36 fps,静止 4 个 ID、踏板活动时 11 个
    「YAW CAN」 引脚 18 = CAN-H,10 = CAN-L,静止约 149.5 fps,2 个 ID
    寻址 / 帧格式 经典 CAN,11 位标识符;0x39D 为 DLC 4,其余多见 DLC 8
    CAN FD 源文档未使用
    供电引脚 引脚 1 = 12V,引脚 9 = GND,引脚 20 = 点火

    已解码信号

    下表抽取源文档中最有代表性的条目,位置与解码保留原文写法(含位运算)。证据一列保留源文档的实测口径:有精确帧数、运行次数与相关系数,也有明确标注为「未解析」「受污染不可引用」的项。

    信号 位置(ID / 字节) 解码 证据
    踏板行程 0x39D b2:b3,DLC 4,25.0 Hz uint16 小端;静止约 262,最大观测 14070;端位 13606 = 43.4 mm 双点标定;mm=(counts-3.3)/320.68(合并拟合)
    行程校验 0x39D b0 (b1+b2+b3+0xA0) & 0xFF 2,250 帧 100% 通过
    存活计数 0x39D b1 每帧 +1 取模 16,高半字节恒 0 实测
    位置(12 位) 0x38E b3 与 b4 低半字节 position = b3 | ((b4 & 0x0F) << 8);静止 320,满行程约 3052 与 0x39D 两次运行 r=0.999627 / 0.999853
    位置换算 mm 0x38E mm = 0.015207 * position - 4.072(静止 320 → 0.79;满 3052 → 42.34) 偏置为负,为已验证的两种形式之一
    状态枚举 0x38E b4 高半字节 0=初始化、1=正常、2=故障闭锁 断开行程传感器诱导故障确认
    制动标志 0x38E b6 1 位制动应用标志;上沿 2.18–2.42 mm,下沿 1.72–1.75 mm 约 0.55 mm 回差;四次上电下沿复现到 2 counts
    状态字节 0x38F b2 bit 0 = 第二个制动标志(1.45–1.66 mm);bits 5:3 = 行程/健康状态 四种状态值实测;释放沿受速率限制、不可引用数值
    消息校验 0x38E/0x38F b0 CRC-8/SAE-J1850,poly 0x1D、init 0x00、xorout 0x0A,覆盖 b1..b7 70,438 帧 100% 通过,两个 ID 参数相同
    峰值行程(事件) 0x38D b5:b6 uint16 小端,129.3 counts/mm r=0.99975;与标定行程在 34 mm 内吻合 0.66 mm(n=10)
    制动持续时长 0x37D b0:b1 uint16 小端,27.50 ticks/s r=0.99877;tick 非整数倍,未定(n=10)
    运行时长 0x31D/0x3AD b0:b1 uint16 小端计数,9.99 ticks/s(100 ms) 四次运行确认;分析中作对照列,防伪相关
    静态身份 0x32D(b0 多路复用,0.5 Hz) 五帧按 b0 轮转,四次上电逐字节相同 件号/标定 ID 类数据,与踏板无关
    踩下后事件 0x33D 9.5 Hz,99.8% 时间为全 FF;触发为松开制动后 0.64–2.20 s 与 0x31D 等构成「踩后突发」组,n=10
    故障哨兵值 0x39D 行程 故障时钉在 16354(0x3FE2),校验仍有效 物理不可达,可按范围直接拒绝

    读取方法与注意事项

    三条工程纪律都来自实测教训。第一,必须在 ACK 模式采集:这是一个两节点总线,若用只听(listen-only)模式,没有人应答会导致错误计数每次尝试 +8、约 32 ms 进入 bus-off 后自动恢复并循环,同一 12 秒窗口下表现为 1006 fps 的单 ID 重传风暴,并且会掩盖四个 ID 中的三个;改用 ACK 模式则为 37 fps、四个 ID。ACK 是链路层比特、不是命令,只读采集仍会应答。

    第二,先确认连接可靠。源文档记录:六轮排查(比特率扫描、极性互换、主机供电、ACK 模式)最终发现是助力器端接触不良。要用万用表从适配器接线端子一直通断到助力器引脚,而不是只看夹子「搭在上面」。

    第三,别把总线识别挂在索引上。USB 索引会随重新插拔重排,适配器名称跟随适配器而非线束;识别哪块适配器在哪条总线要按内容——看到 0x39D 的就是 25/16。另一条独立现象是:已供电的收发器在 ECU 未运行时也会停在 2.5V,这只能证明收发器有电,不能证明 ECU 在跑。传感器上电后约 1.47 s 才初始化完成,此前的读数应视为无效。台架接线时,助力器两侧都不做终端,适配器一侧 R120 置 ON。

    证据等级与边界

    本档案是本台实物的台架观测,不是文档推测,也不是外部旁证。最硬的证据是校验与拟合:0x39D 的加和校验在 2,250 帧上 100% 通过;0x38E/0x38F 的 CRC-8 在 70,438 帧上零失败;位置与行程两条独立总线的拟合两次运行在斜率上仅差 0.13%、截距差 0.12%,远紧于它们与标尺的一致度,反过来证明「运行间标定冲突」是测量误差而非传感器问题。

    三处必须原样保留的边界。其一,行程标定精度约 ±2 mm,瓶颈在标尺不在数据:单次保持内信号重复到约 ±20 counts = 0.062 mm,而两次运行之间最多相差 4.4 mm;死区(约 3.5 mm 自由行程)既未被确认也未被否证,因为差额被运行间误差淹没。其二,「踩后突发」组的每个结论都建立在 n=10 的事件上,候选字节远多于事件数;两个 0.999 拟合通过了 20,000 次置换检验,但低于 |r|≈0.9 的一律只作线索,且峰值与时长在本次采集里部分混淆(深踩往往也踩得久)。0x37D b5 与 0x34D b5 因与运行时长混淆,源文档明确不得引用。其三,status == 2 表示「助力不可用」,不是「位置无效」:传感器重连后位置恢复更新而状态仍为 2、助力仍关闭;0x38E 这时是唯一的活动位置来源,0x39D 仍钉在哨兵值。故障会闭锁,只有循环点火才能恢复。

    不能外推的部分:以上数值只对应本台件号的这台实物;源文档列出的踏板传感器引脚(2、8、22、23)等条目来自其他 iBooster 变体的社区资料,属未验证假设,不能写进固件、DBC 或线束。另一个平台(GM Volt)的制动力命令/状态 ID 也被源文档明确标注「不可用于本机」。关于安全访问,源文档未提供任何绕过方法,且不建议尝试;本文只描述只读采集。最后须重申:这是制动执行器,本档案的一切都是读取,没有任何一项是向它下命令。

    常见问题

    为什么不能用只听(listen-only)模式采集?

    因为这是两节点总线:没有 ACK 就没有人应答,助力器的错误计数每次尝试上升 8、约 32 ms 进入 bus-off 后自动恢复并循环。同一 12 秒窗口下,只听模式表现为 1006 fps 的单 ID 重传风暴,并掩盖四个 ID 中的三个;ACK 模式则为 37 fps、四个 ID。ACK 是链路层比特而非命令,只读采集仍会应答。

    故障状态 2 是不是「位置数据无效」?

    不是。它表示「助力不可用」。源文档通过重连实验证明二者不同:传感器重连后位置恢复更新,但状态仍为 2、助力仍关闭,只有循环点火才恢复。因此位置的有效性要按范围单独判断——例如直接拒绝 0x39D 行程大于 13700 的读数。

    踩下踏板的峰值行程与持续时长可信吗?

    在 n=10 事件下,两者拟合分别为 r=0.99975(129.3 counts/mm)与 r=0.99877,且通过了 20,000 次置换检验,可作结论使用;但峰值与时长在本次采集中部分混淆(深踩往往也久),0x37D b5、0x34D b5 与运行时长混淆、源文档明确不得引用。低于 |r|≈0.9 的只算线索。

    12 位位置 0x38E 与 16 位行程 0x39D 该用哪个?

    0x39D 分辨率更高(约 0.003 mm/count 对约 0.016 mm/count),但只有 25.0 Hz;0x38E 为 99.7 Hz、快约 4 倍。对速率敏感的场景,频率比分辨率更重要。另须注意 0x38E 的换算偏置是负的:mm = 0.015207 * position - 4.072。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/pelosim-tesla-ibooster/docs/DECODE.md(本项目车型档案主来源:已确认信号定义、标定与故障信号)。
    • 项目 01 —— public-can-dbc-datasets/additional/pelosim-tesla-ibooster/README.md(只读设计、两条总线的引脚与帧率、采集模式与接线要点)。
    • 项目 01 —— public-can-dbc-datasets/additional/pelosim-tesla-ibooster/docs/PINOUT.md 与 VERIFY_FIRST.md(引脚实测与未验证条目清单、置信度边界)。

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

    更新记录

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

  • 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