星核火花赛车科技

标签： DBC

  • BYD Atto 3 档案：Chassis 与 Private 双总线分工

    结论：这份档案的对象是一台 2024 年款、右舵出口版的 BYD Atto 3（元 PLUS EV）。它的数据特征是双总线分工：在 P13 摄像头连接器处接入后，Chassis CAN（引脚 4/8）为 500 kbit/s 经典 CAN、8 字节帧，承载转向、车速、踏板、挡位等整车状态，读与写都在这里；Private CAN（引脚 3/7）为 CAN-FD、数据段近 2 Mbit/s，承载摄像头、前向雷达与约 72 个来源未确认的经典格式 ID。整车消息在发送前需补一个字节校验，纵向与横向命令只允许三条报文。以下所有结论仅来自这一台车，中国国内版本与其他年款可能不同。

    车辆与适用范围

    源文档明确：全部数据来自一辆车——2024 年款右舵出口版 Atto 3；并把「换车前的检查项」单列一节。以下范围只对应这一辆。

    项 内容
    车型 BYD Atto 3 / 元 PLUS EV，2024 年款，右舵出口版（VIN 世界厂商标识 LGX）
    年款 / 市场版本 2024 右舵出口版；中国国内版本与其他年款可能不同（源文档明示）
    ECU / 改装状态 P13 摄像头连接器处旁接；以红熊猫板作 CAN 接口；无原厂设备，因此无 IMU，改用 CAN 桥接
    采集跨度 源文档未给出日志时长或帧数；给出整车质量 1750 kg、轴距 2.72 m、转向比 19.8
    适用范围 仅这一台 2024 右舵出口车；换车须重新测量连接器（BYD 用过两个摄像头供应商，连接器不同）

    总线与寻址

    数据来自 P13 摄像头连接器，共 8 个腔位、6 个接线。两条 CAN_H 同为粉色、两条 CAN_L 同为紫色，源文档要求按引脚位置而非颜色识别总线。

    项 内容
    Chassis CAN 引脚 4/8；经典 CAN，500 kbit/s，8 字节帧；本系统的读与写都在此
    Private CAN 引脚 3/7；CAN-FD，数据段近 2 Mbit/s；承载摄像头、雷达与约 72 个来源未确认的经典格式 ID
    寻址 / 帧格式 整车消息为经典 11 位 ID 格式；私有总线为 FD 帧，含 32 字节与 64 字节两类
    终端 在旁接点处为 Chassis CAN 增加终端，因为接入设备会在摄像头连接器处断开总线
    供电 引脚 1 = 摄像头地，引脚 2 = IG1（受控 12V）；点火状态也可从 CAN 推断

    已解码信号

    下表抽取源文档中带明确报文、缩放或位域的信号。位置与解码保留原文写法；证据一列注明来源，凡源文档标注为「未确认」的均原样保留。

    信号 位置（报文 ID / 字段） 解码 证据
    转向角 STEER_MODULE_2 0x11F / STEER_ANGLE_2 0.1 度 / LSB 源文档状态解码表
    驾驶员力矩 STEERING_TORQUE 0x1FC / DRIVER_TORQUE 0.1 Nm / LSB；用于人工接管判定，阈值 18 Nm 源文档；符号正值为左
    EPS 电机力度 0x1FC / MAIN_TORQUE 电机输出，非驾驶员输入 源文档
    EPS 状态 0x1FC 低半字节（位而非枚举） bit0 LKS_PREPARED、bit1 CRUISE_ACTIVATED、bit3 恒 1；0x318 恒 0xFF 源文档；状态 11 需 0.5 s 去抖
    车速 WHEELSPEED_CLEAN 0x1F0 16 位原始计数，0.0713 km/h 每计数 源文档
    单轮转速 WHEEL_SPEED 0x122 / WHEELSPEED_BR 14 位；bit 62 为有效位 源文档
    挡位 / 点火 DRIVE_STATE 0x242 任意有效挡位即视为点火接通 源文档
    制动状态 DRIVE_STATE 0x242 / BRAKE_PRESSED 已去抖；须与安全模块读同一信号 源文档
    油门 PEDAL 0x342 / GAS_PEDAL 不采用 DRIVE_STATE.RAW_THROTTLE 源文档
    转向灯 STALKS 0x133 — 源文档
    方向盘按钮 PCM_BUTTONS 0x3B0 SET / RES / LKAS / 车距 / ACC 开 源文档
    巡航状态 ACC_HUD_ADAS 0x32D / ACC_STATE 2 可用、3 与 5 已启用、7 错误（摄像头总线） 源文档
    偏航角速度 YAW_RATE 0x222 / YawRate 0|12@1+ × 0.002133 − 2.094 rad/s；另含偏置字段需相减 源文档 IMU 桥接节
    平面加速度 AXAY 0x223 / Ax、Ay 0|12@1+ 与 24|12@1+，× 0.027167 与 × 0.027127 m/s² 源文档；Ay 需反号
    雷达目标 私有总线 0x280–0x289 轨道含 TRACK_ID、LONG_DIST、LAT_DIST、VLEAD 等 源文档；COUNTER12_1/2 字段已修正

    读取方法与注意事项

    接入前先做识别。源文档指出：查询固件版本要用 0xF195（SUPPLIER_SOFTWARE_VERSION），因为 BYD 的 ECU 拒绝本平台默认的 0xF188；总线 0 上有 24 个 ECU 应答 0xF195，其中六个返回固件版本（摄像头、制动/IPB、EPS、前向雷达、驱动单元、安全气囊），版本载荷是 6 个原始字节而非 ASCII。摄像头 ECU 不应答固件查询，须设为非必需。

    发送前必须补校验：Chassis CAN 上被签名的 12 条消息，其校验是最后一字节，data[7] = (~sum(data[0:7])) & 0xFF；本系统只发送三条——转向角命令 0x1E2、HUD 帧 0x316、纵向命令 0x32E。0x1E2 按 50 Hz 发送（每两帧中的一帧为 100 Hz），而原车摄像头是 33 Hz。转向命令须在启用期间持续发送，包括静止时也要发请求位为 0 的空闲帧——出现间隙会让 EPS 进入状态 11 并闭锁，单靠随后发 STEER_REQ = 1 无法解除。

    私有总线的完整性另有一套：每条帧的第 0 字节是校验，形式为 CRC8(poly=0x1D, init=0x00, data[1:32]) XOR K[id]；64 字节 ID 的两半各自独立保护，K 是逐报文常量、并入 init/xorout/DataID，不是 CAN ID 的函数，需从本车日志逐 ID 采集。另需注意：源文档修正了雷达 DBC 中两个字段的解读——COUNTER12_1/COUNTER12_2 并非 12 位计数器，第 0 与第 32 字节是帧校验、计数器是第 1 与第 33 字节的低半字节。

    还有一处几何修正：雷达 LONG_DIST 以后轴中心（ISO 8855 车体坐标系）为原点，而非传感器面，需减去 3.60 m（前悬 885 mm + 轴距 2720 mm）后才是相对车头距离；不修正会让每个前车读数偏远 3.6 m，修正后雷达与视觉在 12 m 内一致到 0.5 m 以内。

    证据等级与边界

    本文属于单台实车观测：报文、缩放与位域都在源文档里按车辆实测列出，并标注了去抖时间、保活与几何修正等工程条件。但证据范围的边界同样清楚：源文档在末尾单列一节强调，全部数据来自一辆 2024 右舵出口版；中国国内版本与其他年款可能不同，BYD 还使用过两个摄像头供应商、连接器不同，换车必须重新测量连接器。此外，若用不带继电器直通的旁接线束，本系统运行时没有硬件回退；源文档建议使用带直通继电器的线束盒。

    一处不确定性必须原样保留：EPS 掉线前的状态字段被某份未合并的草稿 DBC 命名为 TORQUE_TEMP_FAILED（取值 1 "TooLarge"、2 "TooFast"），但源文档明确——没有 BYD 官方文档、没有 EPS 诊断码、也没有其他分支能确认该命名，应视为未确认；文档给出的转角上限结论并不依赖该命名。另据源文档，ABS/ESP 侧的转向限值表现为一个恒定的偏航率：EPS 在乘积约 3155 及以上放弃车道保持，故取 3000 留余量，不要抬高到 3155 或观测均值 3578。

    关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文只整理源文档记录的可读信号与发送约束。

    常见问题

    为什么查询固件版本要用 0xF195 而不是 0xF188？

    因为源文档记录 BYD 的 ECU 会拒绝 0xF188（本平台默认的那个）。改用 0xF195 后，总线 0 上有 24 个 ECU 应答，其中六个返回固件版本；版本载荷是 6 个原始字节而非 ASCII，摄像头的 MPC ECU 不应答、须设为非必需。

    Chassis CAN 上发送报文要注意什么？

    两条硬约束。其一，被签名的 12 条消息必须补末字节校验 data[7] = (~sum(data[0:7])) & 0xFF；其二，本系统只允许发送 0x1E2、0x316、0x32E 三条。转向命令还要 50 Hz 连续发送、静止时发请求位为 0 的空闲帧，避免 EPS 进入状态 11 并闭锁。

    雷达距离为什么要减 3.6 m？

    因为 LONG_DIST 的原点是后轴中心（ISO 8855 车体坐标系），不是传感器面。需减去前悬 885 mm 加轴距 2720 mm 共 3.60 m 才得到相对车头距离；不修正每个前车会偏远 3.6 m，修正后在 12 m 内与视觉一致到 0.5 m 以内。

    TORQUE_TEMP_FAILED 这个信号名可信吗？

    不可信。源文档明确：该命名来自一份未合并的草稿 DBC，没有 BYD 文档、没有 EPS 诊断码、也没有其他分支能确认，应视为未确认。文档给出的转角上限（约 3000 / 车速）并不依赖这个命名。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/shemps-byd-atto3/README.md（本项目车型档案主来源：线束与总线拓扑、指纹、状态解码、校验、横向与纵向控制、雷达与 IMU 桥接、适用性边界）。

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

    更新记录

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

  • Western Formula Racing 的 PECAN 遥测链

    结论：这份档案记录的是 Western Formula Racing（学生方程式车队）的整车遥测链：车辆 CAN 报文由车上的树莓派 + CAN HAT 采集，打包成 UDP/TCP 经无线电发到基站，再经 Redis 广播到 WebSocket，最终在浏览器仪表板（PECAN）上实时显示，并落库到 TimescaleDB 供历史查询。它的价值是一条从总线到仪表盘的完整数据通路，而不是逐条信号解码：CAN 报文的分类由一份可配置清单管理（VCU、BMS、INV、TEST MSG 等），逐条定义放在 DBC 里。需要说明的是，本快照只包含项目 README，DBC 与逐条信号未包含在内。

    车辆与适用范围

    源文档是车队开源的数据采集系统仓库，覆盖车辆侧与基站侧两端软件，以及一台用于无实车测试的仿真器。

    项 内容
    车型 Western Formula Racing 方程式赛车（车队项目 PECAN）
    年款 / 市场版本 源文档未给出具体赛季，仅出现运行数据标识 ECU_25
    ECU / 改装状态 车队自研 VCU、BMS、逆变器等部件，构成车辆 CAN 报文来源
    采集跨度 源文档未给出日志数或帧数；提供 CSV 回放样例与仿真器
    适用范围 仅限该队的这套软硬件；逐条信号定义见其 DBC（公开样例在仿真器内，私有部分在受限子模块）

    总线与寻址

    数据流在源文档里以流程图给出：车辆 CAN → 树莓派 CAN HAT（SPI/CAN）→ 车上树莓派（原生 systemd 服务）→ 射频 UDP/TCP → 基站 → Redis → WebSocket → PECAN 仪表板；基站还可把解码后的 CAN 帧直接写入服务器的 TimescaleDB，由 Grafana 做历史可视化。

    项 内容
    物理层 车辆侧树莓派 CAN HAT（经 SPI 接口）读取 CAN 总线
    链路层 / 比特率 源文档未给出
    寻址方式 支持标准 CAN ID 与扩展 CAN ID 两类
    CAN FD 源文档未提及
    传输端口 UDP 5005、TCP 重传 5006、本地 PECAN WebSocket 9080、基站地址 10.71.1.20

    已解码信号

    本快照只含项目 README，DBC 本体与逐条信号未包含在内。为守住「只抄源文档里有证据的条目」这条线，下表登记 README 明确写出的报文类别与数据资产，并逐条注明证据；任何具体报文 ID、字节与缩放系数，源文档均未提供。

    条目 归属 / 位置 说明 证据
    VCU 报文 车辆 CAN 类别 整车控制单元报文类别 README「CAN Message Categories」
    BMS 报文 车辆 CAN 类别 电池管理系统报文类别 README「CAN Message Categories」
    INV 报文 车辆 CAN 类别 逆变器报文类别 README「CAN Message Categories」
    TEST MSG 车辆 CAN 类别 测试报文类别 README「CAN Message Categories」
    类别配置清单 pecan/src/assets/categories.txt 文本配置即可改分组与配色，无需改代码 README「CAN Message Categories」
    标准 / 扩展 CAN ID WS 后端 广播服务支持两类 ID README「WebSocket Backend」
    蓄能器仿真 WS 后端 内置 accumulator 仿真 README「WebSocket Backend」
    样例 CAN 数据 car-simulate/（CSV） 可回放的录制数据 README「Car Simulator」
    样例 DBC car-simulate/ 报文定义示例文件 README「Car Simulator」
    私有 DBC secret-dbc/ 子模块 受限的私有 DBC 文件 README「Project Structure」
    运行数据标识 ECU_25 Flight Recorder 记录的上传标识 README「Flight Recorder」
    实时遥测包 UDP 5005 车上→基站的实时流 README「Car RPi Deployment」
    重传包 TCP 5006 丢包重传通道 README「Car RPi Deployment」
    本地广播 WebSocket 9080 车载 Pi 上的本地 PECAN 数据源 README「Car RPi Deployment」

    读取方法与注意事项

    车辆侧不用容器：遥测栈以原生 systemd 服务 car-telemetry.service 运行，配置为 ROLE=car、基站地址、UDP 5005、TCP 重传 5006、本地 WebSocket 9080。部署步骤是 uv sync 后在服务文件里填入 git 短哈希，再 systemctl enable/start。这一点值得注意：车上运行时依赖与基站不同，车上没有 Docker 与 Redis。

    基站侧则用 Docker Compose 起整套栈（Redis、WebSocket、状态页、视频中继，可选 TimescaleDB 日志）。在笔记本上有一份现成的 .env.macbook 默认配置可直接拉起；在 Windows 上还需要保留一个 PowerShell UDP 中继窗口，因为 Docker Desktop 不会把局域网 UDP 转发进容器。

    没有实车时，可用仿真器回放 CSV 数据来做开发与自检：car-simulate 提供 CSV 回放、常驻 WebSocket 广播与示例 DBC。另有一条「Flight Recorder」路径，用手机在车辆热点上记录数据到浏览器 IndexedDB，等有网时再通过 POST /api/can-frames/batch 同步到服务器。

    证据等级与边界

    本档案属于项目登记，可核对的是系统架构、端口、部署方式与配置文件名；不能据此推出车辆具体有哪些信号，因为逐条定义在未被本快照收录的 DBC 里。

    三处不能外推。第一，报文类别（VCU/BMS/INV/TEST MSG）是可配置的分组名，不是信号清单——它由 categories.txt 决定，改配置即可变。第二，公开样例 DBC 与私有 DBC 是两回事：公开的仅用于仿真器开发，实际车辆定义在受限子模块 secret-dbc/，本快照未包含。第三，端口（5005/5006/9080）与基站地址是这套部署的默认值，换环境即需调整。

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

    常见问题

    PECAN 能读到哪些信号？

    源文档未给出逐条信号。它说明报文按可配置清单分组（示例为 VCU、BMS、INV、TEST MSG），逐条定义放在 DBC 里；本快照未包含该 DBC。

    车辆侧是怎么读 CAN 的？

    车辆侧树莓派接 CAN HAT，遥测软件以原生 systemd 服务运行，把报文打包成 UDP 5005 发送，另有 TCP 5006 用于重传；车载 Pi 上还有本地 WebSocket 9080。

    没有实车怎么测试？

    用 car-simulate 仿真器：回放 CSV 录制数据、常驻 WebSocket 广播，并附带一份示例 DBC；开发时无需连接真车。

    DBC 在哪里？

    公开样例在仿真器目录内；实际车辆定义位于受限子模块 secret-dbc/。本快照只包含项目 README，未包含任何 DBC 文件。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/western-formula-racing/README.md（本项目车型档案主来源：系统架构、数据流、部署与配置；本快照仅含此文件）。

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

    更新记录

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

  • GM Global-A 档案：Chevrolet Express 广播数据

    结论：这份档案的对象是一台 2007 年款 Chevrolet Express 的 GMLAN High Speed 广播数据，源文档并主张同一份 DBC 可用于多数 2000 年代中期、使用该总线且采用 11 位帧头的通用（GM）车辆。它的数据特征是「只有范围声明，没有信号清单」：主素材是许可证文本，连同项目说明在内，源文档只交代了平台、总线与帧头宽度，未提供任何逐信号解码表、比特率或字节定义。因此本文能确认的只是「这份 DBC 面向哪一类车、哪条总线、哪种帧头、读到的是哪类数据」，具体信号必须回到 DBC 文件本身（本快照未包含）。

    车辆与适用范围

    源文档是一份随公开数据集发布的项目说明与许可证。它描述的是数据的适用范围与许可，而非某一台车的信号地图。

    项 内容
    车型 2007 年款 Chevrolet Express（作为创建该 DBC 的取样车）
    年款 / 市场版本 取样车为 2007 年款；源文档主张适用于「多数使用 GMLAN High Speed 总线的 2000 年代中期 GM 车」——该主张未经独立验证
    ECU / 改装状态 源文档未提供；DBC 的定位是只读读取广播数据
    采集跨度 源文档未提供（无日志数、事务数或时长）
    适用范围 限定于 GM Global-A 平台、采用 GMLAN High Speed 与 11 位帧头的车辆；同平台其他年款是否一致，源文档未给证据

    总线与寻址

    源文档对总线的描述只有寥寥数语，足以定位类别，但不足以直接解析。

    项 内容
    物理层 / 比特率 源文档未给出（仅指明为 GMLAN High Speed 总线）
    寻址 / 帧头 11 位帧头（源文档明确以「11-bit headers」描述）
    总线类型 GMLAN High Speed（GMLAN 高速总线）
    CAN FD 源文档未提供；年代与总线类型均指向经典 CAN
    数据方向 读取车辆广播数据，源文档未提及任何写入用途

    已解码信号

    源文档未提供任何逐信号解码表。为保持「只写源文档里有的事实」这一原则，下表登记的是源文档实际给出的全部可确认条目（平台、总线、帧头、数据性质、许可等），并逐条标注出处；任何涉及 ID、字节与缩放的内容，源文档均未包含。

    字段 出处 取值 / 含义 证据
    取样车型 项目说明 2007 年款 Chevrolet Express 源文档直接陈述
    平台 项目说明 GM Global-A 源文档直接陈述
    总线类型 项目说明 GMLAN High Speed 源文档直接陈述
    帧头宽度 项目说明 11 位 源文档直接陈述
    数据性质 项目说明 车辆广播数据（只读） 源文档直接陈述
    文件形式 项目说明 DBC（CAN 报文定义文件） 源文档直接陈述
    更广适用性主张 项目说明 「多数 2000 年代中期使用该总线的 GM 车」——源文档以「should work」措辞给出 未验证主张，原样保留
    许可证 许可证文件 CC BY-NC-SA 4.0（署名—非商业—相同方式共享） 许可证文本
    格式说明入口 项目说明 源文档另附一个第三方 DBC 格式介绍入口，未在本档案展开 源文档直接陈述

    读取方法与注意事项

    源文档对读取条件没有展开，能确认的只有两点：其一，这份文件的用途是读取广播数据，不涉及写入或诊断会话；其二，它是一份 DBC 定义，需配合能够加载 DBC 的工具使用。至于时序、流控、填充与超时预算等工程细节，源文档均未提供，本档案不臆测。

    需要提示的一点是取证路径：源文档给出的更广适用性来自「在 2007 Express 上创建、应当可用于同期 GM 车」的推断，而不是逐车核验。若要在具体车辆上使用，正确做法是先在该车上确认总线类型与帧头宽度（11 位），再核对 DBC 中的报文是否真的出现，并且逐条检查信号是否落在合理范围——而不是因为平台相同就默认直接可用。

    此外须留意许可证的非商业（NC）限制：这份 DBC 以署名—非商业—相同方式共享 4.0 发布，任何商业用途、或与商业产品打包分发，都需先确认许可是否允许；相同方式共享还要求衍生作品以相同许可发布。这一点对量产或商用项目是硬约束。

    证据等级与边界

    本文的证据等级是「项目说明级」：全部条目都能在项目说明或许可证里逐字核对，属直接证据；但源文档既无逐信号解码，也无实车日志，因此本文不提供任何 ID、字节位置或缩放公式。对比同批其他车型档案，本项目属于素材缺失较明显的一类——主素材是许可证文本，项目说明只有一段话。

    两点不能外推。第一，「多数 2000 年代中期 GM 车可用」是源文档的未验证主张，本文原样保留该不确定性，不做加强；具体车辆是否可用必须实测。第二，取样车为 2007 年款 Chevrolet Express，其 DBC 是否与同年款同平台的其他配置一致，源文档亦未给出证据。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文仅整理只读广播数据的适用范围。

    常见问题

    为什么这份档案没有信号清单？

    因为源文档（项目说明加许可证）只交代平台、总线、帧头与数据性质，没有提供任何逐信号解码表。逐信号定义应当在 DBC 文件本身里，但本快照未包含该文件；本文不臆造 ID 与缩放。

    「适用于多数同期 GM 车」这句话能直接采信吗？

    不能直接采信。源文档用的是「should work」这类推断措辞，属于未验证主张。正确做法是在目标车上先确认总线类型与 11 位帧头，再核对 DBC 报文是否真的出现、信号是否落在合理范围。

    这份 DBC 能商用吗？

    需先确认许可。它采用 CC BY-NC-SA 4.0，其中非商业（NC）限制了商业用途，相同方式共享（SA）要求衍生作品以相同许可发布。任何商用或与商业产品打包分发都应先核对许可条款。

    它能不能用来向车辆写数据？

    源文档的定位是读取广播数据，未提及任何写入用途；本档案也不提供写操作。CAN 与诊断操作存在风险，任何实车操作前请自行复核。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/pddenhar-gm-express/LICENSE.md（本项目车型档案主来源：CC BY-NC-SA 4.0 许可条款）。
    • 项目 01 —— public-can-dbc-datasets/additional/pddenhar-gm-express/README.md（平台、总线类型、11 位帧头与广播数据用途的唯一文字说明）。

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

    更新记录

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

  • VinFast VF8/VF9 诊断档案：7 个 CAN 矩阵与 UDS

    结论：这份档案记录的是 VinFast VF8 / VF9 的诊断侧资料：一个基于 OpenXC 或 ELM327、通过 UDS（ISO 14229）读写故障码的桌面工具，以及七份 CAN 网络矩阵（合计约 1,027 条报文、8,684 条信号）与九份信号转发路由表。要点是两条：诊断 CAN 总线为 500 kbit/s，而 VF8 的多数子系统是藏在 XGW 网关之后的 CAN 节点，必须按逻辑地址寻址、由网关转发；读取故障码在默认会话常可用，但清除故障码往往需要安全访问（0x27）。需要提醒的是，工具里随附的逻辑地址是占位符、不是官方地址。

    车辆与适用范围

    源文档是一个面向 VinFast VF8/VF9 的诊断应用仓库。它把「固件反推得到的事实」与「一次实车观测」分开陈述，这个分层在下文原样保留。

    项 内容
    车型 VinFast VF8 / VF9（BEV）
    年款 / 市场版本 实车观测为 2024 款美规 VF8；VF9 的适配性源文档未确认
    ECU / 改装状态 原车；通过 OpenXC 车辆接口或 ELM327 适配器接入诊断总线
    采集跨度 源文档给出一次实车观测；其余为固件与矩阵文档
    适用范围 仅限源文档记录的 2024 美规 VF8 观测；七份 DBC 与实车捕捉的对应关系未被独立验证

    总线与寻址

    VF8 的诊断总线比特率在出厂脚本里写死为 500 kbit/s。部分子系统位于 XGW 网关之后，需要按逻辑地址寻址、由网关把请求路由到对应 CAN 网络。工具另支持 MS-CAN 的 125 kbit/s 与 250 kbit/s 两档，物理拨档需与所选总线一致。

    项 内容
    物理层 OpenXC 车辆接口（USB 或蓝牙 SPP）或 ELM327 v1.5（USB/蓝牙串口）
    链路层 / 比特率 诊断 CAN 500 kbit/s；MS-CAN 支持 125 kbit/s（ELM 协议 B）与 250 kbit/s
    寻址方式 逻辑地址寻址，网关转发到 CAN；CAN ID 映射默认为 请求 = 0x700 + (addr & 0xFF)、响应 = 请求 + 0x08
    CAN FD 源文档未提及
    地址默认值 测试端源地址默认 0x0E80；功能地址默认 0xE400（占位符，须按实车设置）

    已解码信号

    下表把源文档的固件事实、路由表条目与实车观测分开列，逐条注明证据来源。涉及安全访问的条目只说明「存在该会话要求」与「密钥来源」，不展开任何算法或密钥细节。

    条目 位置（ID / 服务 / DID） 含义 证据
    诊断 CAN 比特率 — 500 kbit/s（出厂脚本设定） 固件事实（init-can.sh）
    读取故障码 UDS 0x19 / 0x02 读取 DTC，默认会话通常可用 README「Features」
    清除故障码 UDS 0x14 会先进入扩展会话，需确认；常需安全访问 README「Features / Realistic expectations」
    诊断会话控制 UDS 0x10 默认/扩展会话切换，配合 TesterPresent 保活 README「Session & security」
    安全访问 UDS 0x27（seed / key） 密钥为「每 ECU / 每安全等级」的机密，不在固件明文，须取自本车 README「Realistic expectations」
    读取身份 / VIN UDS 0x22 / DID F190 读 VIN 等身份信息 README「Per-ECU actions」
    例程结果（只请求不启动） UDS 0x31 03 FFFF 只请求例程结果，绝不启动例程 README「Safe ECU capability research」
    归还 I/O 控制 UDS 0x2F FFFF 00 把 I/O 控制权交回 ECU README「Safe ECU capability research」
    诊断会话计数 UDS 0x19 01 FF 报告故障码数量 README「Safe ECU capability research」
    BCM 诊断响应信号 Diag_CAN 0x601 ← Body_CAN 0x601 车身控制模块诊断响应数据 路由表 ToDiag_v10.7.5.csv
    MHU 诊断响应信号 Diag_CAN 0x604 ← Info_CAN 0x604 车机模块诊断响应数据 路由表 ToDiag_v10.7.5.csv
    AMP 诊断响应信号 Diag_CAN 0x605 ← Info_CAN 0x605 功放模块诊断响应数据 路由表 ToDiag_v10.7.5.csv
    ACM 诊断响应信号 Diag_CAN 0x608 ← Body_CAN 0x608 音响/空调模块诊断响应数据 路由表 ToDiag_v10.7.5.csv
    XGW 隧道候选 0x682（Info-CAN 隧道路径） 首选隧道 ID，仍是候选，未获实车匹配响应 实车观测
    OBD 物理回退 0x7E0 标准 OBD 物理回退地址，同为候选 实车观测

    读取方法与注意事项

    源文档把「安全的能力指纹」做成了默认动作：对已确认可达的 ECU，只发六条只读/归还类服务——0x3E 00（TesterPresent）、0x19 01 FF（报告 DTC 计数）、0x22 F190（读 VIN/身份）、0x31 03 FFFF（只请求例程结果）、0x2F FFFF 00（归还 I/O 控制）、0x83 01（读扩展时序上限）。结果区分「肯定响应」「识别到服务但返回否定码」「明确的服务不支持 0x11」「无响应」四种，每行记录 ECU 地址、会话、请求/响应字节与否定码。这一工作流刻意排除了复位、清除 DTC、写入、安全访问与文件传输等服务。

    实车那一侧的观察需要谨慎解读：在参考的 2024 美规 VF8 上，用 OpenXC 发出 diagnostic_request（总线 1、ID 0x682、UDS 0x22 F190），主机侧确认收到了指令，但 3 秒内没有收到 diagnostic_response。源文档据此只说「电脑到车辆接口的链路工作正常」，并明确这不能证明车辆接口的 CAN 发送、物理 OBD 网络、XGW 唤醒状态，也不能证明 0x682 在连接口可达；超时不等于某个 ECU 不存在。

    关于安全访问，源文档的结论是：密钥不在固件中以明文存在，而是每 ECU、每安全等级各自持有的机密，必须从本车自身的配置数据中取得。源文档未提供任何绕过安全访问的方法，且不建议尝试。

    证据等级与边界

    证据分三层，源文档自己就分开了。固件事实（诊断总线 500 kbit/s、各 UDS 服务的存在）来自对车载 TBOX 根文件系统的反推，可核对。路由表条目（0x601/0x604/0x605/0x608 等）来自随附的九份转发 CSV，是信号转发参考数据，不构成执行器或写流程。实车观测只有一次，且只证明链路连通。

    三处不能外推。第一，源文档明说原始适配器帧不标识自己属于哪个网络，因此为某一帧选用某个 DBC 是一种「解码假设」，不是检测出的总线身份。第二，实车观测既未证明 VF9 装配、也未证明全部网络访问路径，不能把 VF8 的观察推广到 VF9 或其他年款。第三，矩阵文档的 1,027 条报文与 8,684 条信号与实车捕捉的对应关系未被独立验证，且来源说明指出这些矩阵的原始出处与再分发授权均未声明。

    常见问题

    VF8 的故障码能免密清除吗？

    通常不能。源文档指出读取 DTC 在默认会话往往可用，但清除往往需要安全访问（0x27）。密钥不在固件明文里，须从本车自身的配置数据取得；源文档未提供绕过方法，且不建议尝试。

    工具里内置的逻辑地址能直接用吗？

    不能。源文档明确这些 VinFast 逻辑地址是占位符、非官方地址，须用「探测 ECU 地址」逐个试出真正响应的地址后再配置。

    七份 DBC 是按什么划分的？

    按网络划分，分别对应信息、车身、诊断、动力、底盘、电池与一条 ASU 私有车身总线。由于原始帧不携带网络标识，为某帧选用某个 DBC 属于解码假设；路由 CSV 是信号转发参考，不定义执行器或写流程。

    那次实车观测说明了什么？

    只说明电脑到车辆接口的链路可用。3 秒内没有响应不能证明车辆接口的 CAN 发送、物理 OBD 网络或 XGW 唤醒状态，也不能证明 0x682 在连接口可达；超时不等于 ECU 不存在。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/cmarshall108-vinfast-vf8-vf9/README.md（本项目车型档案主来源：UDS 工具说明、固件事实与实车观测）。
    • 项目 01 —— public-can-dbc-datasets/additional/cmarshall108-vinfast-vf8-vf9/SOURCE.md（七份 CAN 矩阵与路由表的规模、校验值，以及「未独立验证」的边界声明）。
    • 项目 01 —— public-can-dbc-datasets/additional/cmarshall108-vinfast-vf8-vf9/assets/can/routing/ToDiag_v10.7.5.csv（诊断网络信号转发条目示例）。

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

    更新记录

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

  • Talaria 电摩 CAN 档案：250 kbit/s 的 15 个 ID

    结论：Talaria 电动摩托的总线是一条 250 kbit/s、11 位标准帧的小型 CAN：源文档记录 15 个 ID、约 92 帧/秒，并把其中的 9 条消息、26 个信号行整理成 DBC。这条总线的价值在于「小而有坑」——源文档明确记录了三处「看起来像但并不是」的误判（电池百分比、里程、温度），还修正了里程字段并标注为临时值。以下所有结论仅限源文档记录的这一台车。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 Talaria 电动摩托的 CAN 解析。项目用只监听方式读车，DBC 基于更早的第三方整理做了修订，并把每个信号的溯源写在注释里。

    项 内容
    车型 Talaria 电动摩托；具体型号源文档未确认
    电池包 16S；源文档由「电芯高/低平均 × 16」与包电压吻合到 0.02 V 推出
    采集硬件 ESP32-S3 加 SN65HVD230 收发器；默认只监听
    采集跨度 多条骑行日志与台架检查；源文档记录总线约 92 帧/秒、15 个 ID
    适用范围 仅限源文档记录的这一台车；源文档另指出另一台参考车上的字节偏移不同

    总线与寻址

    这条总线的规模很小，接入门槛不高，但正因为 ID 少、字段挤，误判的风险反而更高。识别要点是速率、位宽与终端电阻三件事。

    项 内容
    速率 / 帧格式 250 kbit/s；11 位标准帧
    总线规模 15 个 ID，约 92 帧/秒
    终端 车端已两端终端，整对约 60 Ω；采集器若自带 120 Ω 终端应拆除，否则会降到约 40 Ω
    采集方式 只监听（listen-only）；收发器不驱动总线也不应答，因此速率设错也不会干扰车辆
    DBC 规模 9 条消息、26 个信号行；基于第三方先期整理修订

    已解码信号

    下表从源文档的解码清单中抽取。项目对未确认的条目明确标注「单位未确认」或「临时值」，本文原样保留这些标注。

    信号 位置（ID / DID / 字节） 解码 证据
    车速 0x303 B0:B1（小端） 0.1 km/h 已确认（与转速比值恒定 5.887，r=0.999）
    电机转速 0x203 B0:B1（小端） 1 rpm 已确认（同上）
    功率 0x203 B2:B3（小端） 1 W 标定记录
    电流 0x302 B4:B5（小端） 0.1 A 标定记录
    包电压 0x101 B0:B1（小端） 0.1 V 已确认（电芯高低平均 × 16 吻合到 0.02 V）
    电池百分比 0x401 B0 1 % 标定记录
    最高电芯 + 编号 0x201 B0:B1、B4 1 mV 标定记录
    最低电芯 + 编号 0x201 B2:B3、B5 1 mV 标定记录
    侧撑 0x202 B0 bit7 1 = 放下 标定记录
    骑行模式 0x202 B0 bits5:4 1 Eco、2 Sport 标定记录
    回充等级 0x490 B0 bits2:0 1–4 标定记录（须按 3 位掩码）
    骑行模式（仪表指令） 0x490 B0 bits5:3 1 Eco、2 Sport 标定记录
    里程 0x402 B2:B3（小端） 1 km 临时值（源文档要求增量复核）
    油门需求 0x202 B3:B4（小端） 单位未确认 未确认

    读取方法与注意事项

    第一条是终端电阻。车端已经在两端做终端，整对读下来约 60 Ω；如果采集器再挂一个 120 Ω 终端，会把阻抗拉到约 40 Ω，可能影响总线。源文档建议把采集模块自带的终端拆掉。

    第二条是「看起来像但不是」的三处误判。其一，某个字节被当成电池百分比，其实是恒定的 100，源文档判断它更可能是健康状态而非荷电状态；其二，某个字段单调递增，看着像里程，但它与车速的相关系数只有 −0.0005，且每公里计数在两次骑行间相差 34%——真正的里程在另一个 ID 上；其三，某个字节既不是温度也不是单一字段，它同时承载模式位与回充位，必须按 3 位掩码拆开。

    第三条是写入操作的风险边界。源文档记录了对「模式/回充指令所在 ID」是仪表下发还是控制器回显的讨论，并做了注入实验来判断控制权归属。这类对车辆控制总线的写入涉及安全风险，本文不复述具体做法，也不建议尝试。

    证据等级与边界

    项目对已确认信号给出了可复现的依据：车速与转速在两个独立骑行中保持固定比值 5.887（r=0.999），电芯高低平均 × 16 能把包电压还原到 0.02 V。这两条互相独立的证据把「车速、转速、包电压、16S 结构」串成了可信的一组。

    里程是新近发现的字段，源文档明确标注为临时值：它是靠「车自己显示的 400 km」与一次全总线采集里的数值匹配找到的，但只匹配了一次。源文档提醒这条总线上有整数常量（例如某两个 ID 里都出现 1200），所以一次与整数吻合只是「有说服力」，不是证明——必须等到一次骑行里看到它递增才能定案。

    边界上必须强调：以上字段位置与刻度限定在这一台车与这一版固件。源文档已指出另一台参考车上的油门字节偏移就不同（本车在 0x202 的 B3:B4，参考车在 B2:B4 且并不跟随油门）。换车使用前必须重新核对偏移。

    常见问题

    为什么里程字段被标成「临时值」？

    因为它只被匹配到一次：源文档读到车辆自身显示的 400 km，并在一次全总线采集的某个 ID 里找到同样的 400。但这条总线上存在整数常量，单次与整数吻合不能排除巧合，必须等一次骑行里看到该值递增才能确认。

    那个恒定 100 的字节是什么？

    源文档明确它「不是电池百分比」——它在实际电量变化时仍读 100，因此更可能是健康状态之类的字段。不要把它当作荷电状态使用。

    回充等级为什么容易读错？

    因为它与骑行模式共用同一个字节，且只能按低 3 位掩码读。若按整个低半字节（4 位）读，在 Eco 模式下 bit3 会被置位，本该读成 1 的回充等级会读成 9。源文档强调「掩 3 位，不是 4 位」。

    这条总线上有哪些信号是找不到的？

    源文档记录喇叭与灯光不经过总线，它们是来自车把开关的 12 V 通断电路；刹车拉杆只出现在部分车型上，不带传感器的改装拉杆则什么都不产生。因此这些量无法从 CAN 上读到。

    延伸阅读

    参考资料

    • 项目 07 —— public-can-dbc-datasets/additional/kbirand-talaria-tripper/README.md（本项目车型档案主来源：解码清单、陷阱与硬件说明）
    • 项目 07 —— public-can-dbc-datasets/additional/kbirand-talaria-tripper/SOURCE.md（DBC 规模、先期工作与许可证说明）

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

    更新记录

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

  • Opel Astra H 的 LS-CAN 与 MS-CAN 解码档案

    结论：这份档案记录的是欧宝 Astra H 的两条总线：单线的 LS-CAN（即 SW-CAN / GMLAN） 与 MS-CAN。在 LS-CAN 上，源文档把车速、转速、行驶距离、燃油喷射、冷却液温度、燃油液位、系统时间、电压与 TPMS 都逐字节解了出来；例如车速在 0x108 上除以 128、燃油液位是 94 - (值/2) 升。它是一份「按地址逐字节标注」的观测表，而不是厂商规格：大量字段被标为 ?? 或「见过 N 种取值」，这些不确定标记必须原样保留。

    车辆与适用范围

    源文档是一份公开的「车辆 CAN 报文数据库」，按 品牌/型号/代/总线/部件.md 组织。Astra H 这一支同时给出 LS-CAN 与 MS-CAN 两个目录，其中 LS-CAN 以 ALL_TYPES.md 汇总全部观测值。

    项 内容
    车型 Opel Astra H（MS-CAN 文档中点名发动机为 Z16XEP 1.6L）
    年款 / 市场版本 源文档未给出具体年款与市场版本
    ECU / 改装状态 源文档未给出；为车主对原车的观测
    采集跨度 源文档未给出日志数或帧数；部分报文注出周期（如 0x108 约 50ms、0x190/0x440 为 1000ms）
    适用范围 仅限源文档记录的这一台 Astra H；数值标定含多项未确认项

    总线与寻址

    这台车同时有 LS-CAN 与 MS-CAN。LS-CAN 被文档标注为「SW-CAN——单线或 GMLAN」，是单线制总线；MS-CAN 承载车身、信息显示等部件。两条总线都以小写十六进制地址登记（如 0x108、0x530、0x684）。

    项 内容
    物理层 LS-CAN：单线（SW-CAN / GMLAN）；MS-CAN：源文档未给出
    链路层 / 比特率 源文档未给出
    寻址方式 表中地址为小写十六进制（如 100、530），源文档未标注位宽
    CAN FD 源文档未提及
    多帧报文 MS-CAN 的 Info-Display 报文超过 8 字节，使用 ISO-15765-2 分包

    已解码信号

    下表抽取 15 条最有代表性的条目，横跨 LS-CAN 与 MS-CAN。凡源文档标为 ??、「见过 N 种取值」或「计算取决于传感器/有时反向」的，均在证据列保留说明。

    信号 位置（ID / 字节） 解码 证据 / 置信度
    车速 LS-CAN 0x108 byte2+3 值 / 128 = km/h（例 0x2098=65.19） 源文档示例与说明
    发动机转速 LS-CAN 0x108 byte5+6 16 位（例 0x04E5=1253 rpm） 源文档示例；MS-CAN 版本在 0x4E8 上为「RPM/4」
    行驶距离（每驱动轮） LS-CAN 0x110 byte2+3 / byte4+5 一次增量 = 1.5748 cm；16 位满周期约 1032 m 源文档说明
    燃油喷射量 LS-CAN 0x130 byte2+3 一次增量 = 0.03054 ml（1.6L 机）；满周期约 2 升 标定基于作者 1.6L 发动机
    冷却液温度 LS-CAN 0x145 byte4 值 – 40 = °C（例 0x28→-2 °C） 源文档示例
    发动机/点火状态 LS-CAN 0x145 byte1–3、5 多字节状态码（如 0x20=点火开未着、0x00=运行） 源文档逐值说明
    巡航控制状态 LS-CAN 0x145 byte6 0x04=未激活 / 0x06=激活 源文档说明
    转向灯/拨杆状态 LS-CAN 0x175 byte3 0x01～0x04 表示半推/半抬/全推/全抬 源文档说明
    转向灯控制帧 LS-CAN 0x260 三字节组合区分左/右/双闪 源文档逐组合表
    总里程 LS-CAN 0x190 byte3–5 里程量（周期 1000ms） 源文档标注；单位与系数未在本文展开
    燃油液位 LS-CAN 0x375 byte2 94 – (值/2) = 升（例 0xA0→14.0 L） 「计算取决于传感器，有时反向」
    系统时间 LS-CAN 0x440 byte1–3 时 : 分 : 秒÷4 源文档说明
    户外温度 LS-CAN 0x445 byte2 MS-CAN 同义项 0x682 为「值/2 – 40 = °C」 源文档说明
    电压 LS-CAN 0x500 byte2 源文档标注为电压（周期约 1500ms） 源文档标注；换算未在本页给出
    胎压 TPMS LS-CAN 0x530 byte3–6 每轮 值/25 = Bar；byte1/2 为前/后传感器状态 MS-CAN 版本在 0x684 上同式

    读取方法与注意事项

    源文档的记法本身就是方法约束：页首声明斜体值表示「至今只见固定值」，粗体值表示已被单独页面解释，括号中的数字是见过的不同取值个数。也就是说，一个标了 ? (4) 的字节，作者只见过 4 种取值——它可能是枚举状态，也可能是「从未触发的故障位」，文档对后者也如实保留。

    对使用者而言，最实际的两点：其一，MS-CAN 的 Info-Display 报文超过 8 字节，用 ISO-15765-2 打成多帧，数据块结构是「两字节命令 + 一字节负载长度 + 一字节消息类型 + 若干子包（ID + 字符数 + UTF-16 字符）」；文档给了 AC、音频、导航等消息类型与各类型下的行 ID 清单。其二，按位复用的字节必须做位运算（拨杆/方向盘按键就是「函数由位编码」）。

    证据等级与边界

    本档案属于单车观测：所有条目都来自一位车主对一台 Astra H 的记录，没有第三方旁证，也没有反汇编或厂商规格支撑。可核对的是「作者给出的一条条示例」（如 0x108 的 0x2098→65.1875 km/h、0x375 的 0xA0→14.0 L）；不可核对的是这些标定是否适用于其他车。

    三处不能外推。第一，改装的线束、传感器与仪表版本会让个别字节不同，燃油液位文档自己就注明「取决于传感器，有时反向」。第二，作者在页首明说斜体值「可能是从未触发的故障指示」，把「只见固定值」当成「恒为定值」是过度解读。第三，发动机相关标定（燃油喷射的 0.03054 ml）是用作者自己的 1.6L 发动机推出来的，换机型即失效。

    关于「安全访问」类问题：本文只整理被动观测到的广播报文，未涉及任何诊断写入或安全访问绕过；源文档未提供绕过方法，且不建议尝试。

    常见问题

    Astra H 的 LS-CAN 和 MS-CAN 有什么区别？

    LS-CAN 被文档标注为单线的 SW-CAN / GMLAN，承载车速、转速、燃油、里程、TPMS 等；MS-CAN 承载车身与 Info-Display 等。两者的地址与编码各自独立。

    车速是怎么算出来的？

    在 LS-CAN 的 0x108 上取 byte2+3 组成 16 位值，再除以 128。文档示例：0x2098 = 8344，8344 / 128 = 65.1875 km/h。

    燃油液位为什么有时反向？

    文档注明该值「计算取决于传感器，有时反向」，公式为 94 - (值/2) 升。因此同一公式在不同传感器配置下可能得出相反趋势，不能无条件套用。

    Info-Display 的报文为什么超过 8 字节？

    因为它用 ISO-15765-2 把长报文分成多个 CAN 帧（首帧 + 连续帧）。数据块由两字节命令、一字节负载长度、一字节消息类型和若干子包组成，子包再带行 ID、字符数与 UTF-16 字符。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/trueffelwurm-opel-astra-h/Opel/Astra/H/LS-CAN/ALL_TYPES.md（本项目车型档案主来源：LS-CAN 全部观测值与逐条说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/trueffelwurm-opel-astra-h/Opel/Astra/H/MS-CAN/Body.md（MS-CAN 的底盘与发动机条目）。
    • 项目 01 —— public-can-dbc-datasets/additional/trueffelwurm-opel-astra-h/Opel/Astra/H/MS-CAN/Info-Display.md（Info-Display 的 ISO-15765-2 分包与消息类型表）。

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

    更新记录

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

  • SAM 项目车 CAN 档案：125 kbit/s 与 37 条消息

    结论：SAM 项目车是一台 125 kbit/s、11 位标准帧的小型电动车，其 CAN 数据档案的价值不在「抓到多少」，而在「修正了多少」：源文档的 DBC 共 37 条消息、161 个信号，并对早期手工整理的布局逐条做了修正——多处把原本当成无符号的字段改正为有符号，还把两个电压刻度由「1」改为实测拟合值。源文档同时明确区分「该车的总线」与「另一台装原厂 BMS 的车」。以下所有结论仅限源文档记录的车辆。

    车辆与适用范围

    本文数据来自第三方开源项目对 SAM 项目车的 CAN 记录与 DBC 修正。项目用某类商业 CAN 记录仪采集 trace，并开发了一个查看器来浏览器与逐帧回放；DBC 的修正以注释形式叠加在文件内。

    项 内容
    车型 源文档以 SAM 指代的一台项目车；具体量产车型未确认
    年款 / 市场版本 源文档未确认
    电控与改装 车上装有自研仪表（STM32）与自研 BMS；源文档同时对照另一台仍装原厂 BMS 的车（在参考日志中的那台）
    采集跨度 两种记录格式（某类商业 CAN 记录工具导出的 `.trc` v2.0 文件，与 SAM 侧记录器导出的纯文本），覆盖行驶、充电与静置场景
    适用范围 仅限源文档记录的这两台车；两车的 BMS 变体不同，报文与周期存在差异

    总线与寻址

    这是一条相对「干净」的台架总线：速率不高、ID 位宽是标准 11 位，车的电控又是自己开发的，因此信号的字节布局大体可从自身设计反推——但仍有多处需要靠实测数据才能定标。

    项 内容
    速率 / 帧格式 125 kbit/s；11 位标准帧
    DBC 规模 37 条消息（`BO_`）、161 个信号（`SG_`）
    修正方式 修正以 `CM_` 注释形式叠加在 DBC 内，逐条标注依据与是否已确认
    多路复用 存在被多路复用的消息（如充电机信息与仪表时间同步共用同一 ID）
    对照来源 除实车 trace 外，还用车辆仪表的报文处理逻辑做交叉对照

    已解码信号

    下表从源文档的修正记录中抽取。项目把依据分成几类：与仪表固件一致（可认为已确认）、与另一条可信信号比值拟合（已确认）、以及仅从原始数据推断、尚无固件旁证（标注为推断）。本文原样保留这些标注。

    信号 位置（ID / DID / 字节） 解码 证据
    电池电压 0x186（消息 390） 每计数 0.0625 V 已确认
    电池电流 0x386（消息 902） 有符号；10 Hz 已确认（由无符号改为有符号）
    电机转速 0x390（消息 912） 有符号 已确认（由无符号改为有符号）
    电机扭矩（实际，skai_torque） 0x290（消息 656）内的 int16 字段 刻度为推断 非固件确认（源文档明确标注）
    直流母线电压 0x290（消息 656） 因子由 1 改为 0.1 已确认（与电池电压比值 0.0997±0.002）
    12 V 电压 0x291（消息 657） 无符号 已确认（由有符号改为无符号；读数约 13.8 V）
    充电机高压 VoltageHV 0x1C0（消息 448） 因子由 1 改为 0.0625 已确认（比值 0.06211±0.00001）
    充电机温度 / 散热器温度 0x1C0（消息 448） 有符号修正 已确认
    电芯电压 0x406，轮转槽位 mV 标定记录（新 BMS 轮转 37 槽，原 BMS 以 cell 0 作填充）
    电芯温度 0x406 摄氏度 标定记录
    BMS 状态 / 剩余能量 0x306（消息 774） — 标定记录（新 BMS 变体下为占位值，原 BMS 为真实值）
    FECU 故障位掩码 0x292（消息 658）B5:B7 位掩码，需按仪表固件的字节序重建 已确认（与仪表报文处理逻辑交叉核对）
    请求扭矩 requested_torque 0x191（消息 401） — 未固件确认

    读取方法与注意事项

    第一条是字节序与符号位。源文档对若干字段做了符号修正：电池电流、电机转速原本被当成无符号，实际是有符号；而 12 V 电压则相反，原本当成有符号，实际是无符号。这类错误不会让程序报错，只会让数值在某个区间里「看起来合理、其实错位」，所以必须逐字段核对。

    第二条是多路复用。源文档指出有消息在仪表侧被复用于多个子报文，例如充电机信息与仪表时间同步共享同一 ID；解析时必须先按子报文的标志位区分，否则会把时间同步的字节当成充电机参数读。项目对涉及掩码的字段做了专门的屏蔽处理。

    第三条是校验和字节序重建。故障位掩码所在的字段不是简单的 24 位小端，源文档依据仪表固件的处理逻辑做了字节序重建，并用一条实车记录验证了修正前后的差异（修正后的取值与预期一致）。这说明「字段看起来是连续的」并不等于「可以直接按小端读」。

    证据等级与边界

    源文档把修正依据分层：与仪表固件一致、或与另一条可信信号做比值拟合的，标为已确认；仅从原始数据推断、没有固件旁证的，明确标注为推断。例如电机扭矩的刻度就是推断值——虽然原始 int16 字段的位置确定，但「一计数等于多少牛米」尚未被固件证实。

    另一条重要边界是「BMS 变体」。源文档把车分成两类：一台装新开发的 BMS（参照原厂设计但不完全相同），另一台在参考日志里仍装原厂 BMS。两者在若干报文上的行为不同——例如电芯电压轮转的填充槽位、某些报文的周期（1 Hz 与 10 Hz）。因此同一辆车的档案也要先确认 BMS 变体。

    边界上必须强调：以上信号位置与刻度都限定在源文档记录的这些车辆与这一版 DBC。不同 BMS 变体、不同固件之间差异明显，跨车使用前必须重新核对。

    常见问题

    为什么这辆车的 DBC 要反复修正？

    因为早期 DBC 是手工整理的，存在真实错误：多个字段被错判符号（电池电流、电机转速被当成无符号；12 V 电压被当成有符号），两个电压的刻度也不对（由 1 改为实测拟合值）。源文档逐条记录了修正依据，并区分「已确认」与「推断」。

    电机扭矩的刻度为什么只标「推断」？

    因为该字段的位置是确定的原始 int16，但「一计数等于多少牛米」没有得到仪表固件的证实，只能从数据推断。源文档没有把它当作已确认值，使用时应保留这一不确定性。

    同一车系为什么会有两套 BMS 行为？

    因为源文档对照了两台车：一台装新开发的 BMS，另一台仍装原厂 BMS。两者在报文周期与电芯电压轮转的填充方式上都不同（例如新 BMS 轮转 37 槽而原 BMS 以 cell 0 填充）。解析前必须先确认 BMS 变体。

    这些修正能直接套到别的车上吗？

    不能。源文档的结论限定在被记录的车辆与 DBC 版本上，不同 BMS 变体与固件之间的差异已被证实存在。跨车使用前必须重新核对。

    延伸阅读

    参考资料

    • 项目 06 —— public-can-dbc-datasets/additional/janniksteiner-sam-can/PROJECT_NOTES.md（本项目车型档案主来源：DBC 修正项、BMS 变体与效率图方法）
    • 项目 06 —— public-can-dbc-datasets/additional/janniksteiner-sam-can/README.md（查看器与记录格式说明）
    • 项目 06 —— public-can-dbc-datasets/additional/janniksteiner-sam-can/SOURCE.md（DBC 规模与来源说明）

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

    更新记录

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

  • Kia Soul OSCC 档案：归一化命令与 200 ms 保活接口

    结论：这份档案的对象是一套面向 2014 年及以后 Kia Soul（汽油与纯电）的开源车辆控制项目（OSCC），它把「读取车辆状态」和「下发控制命令」拆成 API 与固件两层：固件侧用专门的模块通过转向力矩/油门位置/制动位置传感器与 OBD-II CAN 交互，API 侧用归一化数值下发命令、并通过回调接收回报。它的数据特征是命令归一化 + 200 ms 保活：制动与油门为 [0.0, 1.0]、转向为 [-1.0, 1.0]，且每个发布函数必须至少每 200 ms 调用一次，否则模块判为通信丢失并自行禁用。源文档未给出比特率、寻址方式与逐字节定义，其结论仅限 2014 年起的 Kia Soul 平台。

    车辆与适用范围

    源文档是一个软硬件项目仓库的说明：它描述 API、固件与硬件三部分，以及可扩展的车型头文件机制。数据来自项目文档，不是某台实车的采集记录。

    项 内容
    车型 Kia Soul（2014 年及以后，汽油与纯电）；构建目标另含 Kia Niro
    年款 / 市场版本 源文档以「Kia Soul PS（2014–2018）」指代已整理信息的平台；其他年款与市场版本未确认
    ECU / 改装状态 加装 OSCC 模块：传感器接口板（转向/油门）、整车控制模块（纯电制动）或执行器控制板（汽油制动），外加 CAN 网关
    采集跨度 源文档未提供（无日志数或事务数）
    适用范围 源文档明确「目前仅支持 2014 年起的 Kia Soul」，API 与固件按易扩展设计，但其他车型属未来扩展

    总线与寻址

    源文档把总线分成「车辆 OBD-II CAN」与「OSCC 控制 CAN」两条，固件用 CAN 网关模块在两段之间转发；但未描述物理层与标识符细节。

    项 内容
    物理层 / 比特率 源文档未给出
    总线划分 车辆 OBD-II CAN 网络（读状态、发命令、接收回报）；OSCC 控制 CAN（API 与固件模块之间）
    寻址方式 源文档未给出；API 以「CAN 通道 + 标准化信号名」抽象，不暴露标识符
    CAN FD 源文档未提供
    接口形态 固件以 Arduino + 专用扩展板实现，经 USB 串口烧写与监控

    已解码信号

    下表登记源文档明确给出的接口面（命令、回报与关键参数）。位置列写接口名而非字节偏移，因为源文档只以标准化信号与回调形式暴露它们；「证据」一列注明其出处为 API 说明、固件说明或构建选项。

    信号 / 接口 位置（API / 模块） 取值与含义 证据
    制动位置命令 publish_brake_position() 归一化 [0.0, 1.0]，转发到制动固件模块 API 说明
    转向力矩命令 publish_steering_torque() [-1.0, 1.0]，-1 为逆时针、+1 为顺时针 API 说明
    油门位置命令 publish_throttle_position() 归一化 [0.0, 1.0] API 说明
    制动回报 oscc_brake_report_s 通过 subscribe_to_brake_reports() 回调 API 说明
    转向回报 oscc_steering_report_s 含转向角；通过 subscribe_to_steering_reports() 回调 API 说明
    油门回报 oscc_throttle_report_s 通过 subscribe_to_throttle_reports() 回调 API 说明
    故障回报 oscc_fault_report_s 通过 subscribe_to_fault_reports() 回调 API 说明
    OBD 原始帧 subscribe_to_obd_messages() 转发车辆 OBD-II CAN 上的非 OSCC 帧，按帧 ID 自行解析 API 说明
    轮速 车辆回报（当前控制状态） 源文档以「转向角与轮速」为例说明可回报的车辆控制状态 项目说明
    使能 / 禁用 oscc_enable() / oscc_disable() 只影响是否可发送命令；回报随时可收 API 说明
    通道开关 oscc_open(channel) / oscc_close() 打开/关闭与 OSCC 控制 CAN 的套接字连接 API 说明
    保活超时 三个发布函数 每个须至少每 200 ms 调用一次，否则模块判失联并自禁用 API 说明
    转向过载阈值 TORQUE_DIFFERENCE_OVERRIDE_THRESHOLD 调整转向人工接管灵敏度；过低会误判、过高难接管 构建/配置说明
    电压范围检查 API 内部安全校验 拒绝发送超出车辆预期范围的电压 API 说明

    读取方法与注意事项

    生命周期由三组调用界定：oscc_open(channel) 打开控制 CAN 的套接字，oscc_enable() / oscc_disable() 决定是否允许发送命令，oscc_close() 结束。源文档提示 API 会捕获 CAN 帧到达时的 SIGIO 信号并注册处理器转发有效帧，因此在容易被中断冲突的代码段应临时屏蔽该信号、之后再解除。

    最关键的运行约束是节拍：三个发布函数每个都必须至少每 200 ms 调用一次，否则固件模块会判定与上位机失去通信并自行禁用。也就是说，「不发命令」本身是一种保护动作；程序崩溃或卡顿时会自动退出控制，这是设计意图而非缺陷。

    人工接管方面，源文档默认对所有模块启用接管检测，但明确提示：系统激活时试图抓方向盘可能造成严重伤害，推荐用制动踏板或急停按钮作为转向接管手段；如需关闭转向接管检测，可在构建时传 -DSTEERING_OVERRIDE=OFF。构建还需按车型选择标志（-DVEHICLE=kia_soul、kia_soul_ev 或 kia_niro）；对早于 1.2.0 的执行器控制板，需加 -DBRAKE_STARTUP_TEST=OFF 以跳过与该板不兼容的启动测试。

    证据等级与边界

    本文的证据等级是「项目文档级」：命令取值区间、回调接口、200 ms 保活与构建标志都可在源文档逐条核对，属于直接证据；但源文档没有逐信号解码表，也没有实车日志，因此本文不提供标识符、字节偏移或缩放系数。要落到具体字节，需回到固件与车型头文件（本快照未包含逐字节定义）。

    两点不能外推。第一，源文档明确「目前仅支持 2014 年及以后的 Kia Soul」（汽油与纯电），Kia Niro 为构建目标；把接口面外推到其他起亚车型或其他品牌属于超范围。第二，各模块的板卡版本与固件版本需按源文档的对应表配套使用，混用可能触发已知安全问题的旧版本；源文档特别强调应及时更新。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；项目自述其设计不改变厂方安全用例、不伪造 CAN 消息、不入侵 ADAS 功能，本档案仅描述这一接口面。

    常见问题

    为什么命令必须每 200 ms 发一次？

    因为固件模块以 200 ms 作为与上位机的通信存活判据：任一发布函数连续超过该时间未被调用，模块就判为失联并自行禁用。这是有意的失效保护——程序卡死时会自动退出控制，而不是保持最后一个命令。

    转向接管该怎么做？

    源文档建议用制动踏板或急停按钮，而不是直接抓方向盘——后者在系统激活时可能造成严重伤害。若确实要关闭转向接管检测，可用 -DSTEERING_OVERRIDE=OFF 构建；保留检测时，灵敏度由 TORQUE_DIFFERENCE_OVERRIDE_THRESHOLD 调整，过低会在大扭矩区误判、过高则难以手动接管。

    能从这套系统直接读到车辆的所有信号吗？

    不能仅凭本文判断。API 提供的是结构化回报（制动/转向/油门/故障）与一个 subscribe_to_obd_messages() 回调，后者转发车辆 OBD-II CAN 上的非 OSCC 帧，需要按帧 ID 自行解析。源文档未给出这些帧的逐字节定义。

    这套接口能套用到别的起亚车型吗？

    源文档明确目前仅支持 2014 年起的 Kia Soul（汽油与纯电），Kia Niro 为构建目标；API 与固件按易扩展设计，但新增车型需按车型头文件格式补齐信息。直接外推到其他车型超出源文档证据范围。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/polysync-oscc/README.md（本项目车型档案主来源：API 与固件接口、命令归一化范围、200 ms 保活、构建标志与支持车型）。
    • 项目 01 —— public-can-dbc-datasets/additional/polysync-oscc/LICENSE.md（硬件为 CC BY-SA 4.0、固件与软件为 MIT 的许可划分）。

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

    更新记录

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

  • 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

  • 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