星核火花赛车科技

标签： 车型协议

  • Chevrolet Impala 2008：怠速采集的 50 个 ID

    结论：Chevrolet Impala（2008 款）是一辆典型的「HS-CAN 直读」车：500 kbps、11 位标准帧，源文档在 6 次采集中识别出 50 个唯一 ID，并把解码整理成 22 条消息、71 个信号的 DBC。但它有一个必须说清的限制：所有采集都在静止怠速下完成，因此车速与轮速的换算公式从未被运动数据验证过。以下所有结论仅限源文档记录的这一台车。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 2008 款 Chevrolet Impala 的 HS-CAN 采集与解码。项目用多次定向采集诱发特定开关动作，再结合公开的 GM 数据库做交叉对照。

    项 内容
    车型 Chevrolet Impala，2008 款
    年款 / 市场版本 2008 款；具体市场版本源文档未确认
    采集构成 5 次约 15 秒的定向采集（用于诱发特定开关），加 1 次约 90 秒的基线采集
    采集状态 全部为静止怠速；源文档明确此时没有轮速与车速数据
    适用范围 仅限源文档记录的这一台车；结论不适用于其他年款或平台

    总线与寻址

    这辆车没有复杂的多总线结构或隐藏网关，接入相对直接。它的问题不在「能不能抓到」，而在「抓到后能证明到哪一步」。

    项 内容
    总线 HS-CAN；OBD-II 引脚 6 / 14
    速率 / 帧格式 500 kbps；11 位标准帧
    唯一 ID 数 50 个（6 次采集合计）
    DBC 22 条消息、71 个信号
    外部交叉引用 与公开的现代 GM Global A 数据库比对，50 个 ID 中有 20 个能匹配
    网关 源文档未记录网关行为；按同年款 GM 车的一般结构为单一 HS-CAN

    已解码信号

    下表从源文档的 Quick-Reference 解码表中抽取。项目对已被运动数据验证过的条目与仅靠怠速数据推出的条目做了区分，本文原样保留「未验证」标注。

    信号 位置（ID / DID / 字节） 解码 证据
    发动机转速 0x0C9 源文档更正：byte 0 是高半字节滚动计数器，不参与 RPM 计算 已确认
    制动开关 0x0C9 位标志 已确认
    制动压力 0x0F1 — 已确认
    挡位 PRNDL 0x1F5 枚举 已确认
    喷油脉宽 0x191 — 已确认
    冷却液温度 / 进气温度 0x4C1 — 已确认
    机油温度 0x4D1 — 已确认
    燃油轨压 0x4F1 — 已确认
    VIN 0x514 / 0x4E1 / 0x52A 多帧拼接为文本 已确认
    方向盘转角 / 角速度 0x1E5 — 已确认
    横加速度 / 横摆率 0x1E9 — 已确认
    电源模式 0x1F1 枚举 已确认
    车门 / 安全带 0x12A 位标志 已确认
    车速 0x3E9 公式存在，但未由运动数据验证 未验证
    轮速 0x348 / 0x34A 公式存在，但未由运动数据验证 未验证

    读取方法与注意事项

    第一条是采集设计。由于全部采集都在静止怠速下完成，任何与「车在动」相关的量都无法闭环：车速与轮速的换算公式虽然在文档里给出了，但没有运动数据能证明它对。若要把这些公式当作可用结论，必须补做一次实际行驶的采集。

    第二条是数据字段的坑。转速信号的 byte 0 曾被当成数据参与计算，源文档更正指出它其实是高半字节滚动计数器——这类「带头字节」的报文在很多车上都存在，把计数器当数据会引入周期性误差。处理多字节数值前，应先确认前导字节是否为计数器或状态位。

    第三条是外部对照的限度。项目把本车的 50 个 ID 与公开的现代 GM Global A 数据库比对，有 20 个能匹配。但这是跨世代的对照，只能作为线索，不能代替在本车上的实测——匹配上了不代表字节位置与刻度在本车上也一致。

    证据等级与边界

    源文档区分了「已确认」与「未验证」两类。已确认的多为怠速下就能观测的开关量、温度与静态值；未验证的集中在与运动强相关的车速与轮速。此外源文档指出，转向灯信号在这辆车的 HS-CAN 上并没有被找到——这是一个负向结论，说明该信号可能在别的总线或不经 CAN 传输。

    还有三处必须如实交代的边界。第一，源文档的 DBC 中，加速踏板位置字段从 bit 48 开始，但该消息被声明为 3 字节，两者不一致，说明这一条布局尚未定稿；第二，声称的原始采集文件并不在项目快照中，因此无法用原始数据复现结论；第三，上游 DBC 文件缺少仓库许可证信息，使用时需自行确认授权。

    适用范围上必须强调：以上 ID、字段与公式都限定在这一台 2008 款 Impala 上，且以怠速数据为主。不同年款、不同平台的车辆，ID 布局与刻度都可能变化；跨车使用前必须重新采集验证。

    常见问题

    为什么车速与轮速被标为「未验证」？

    因为全部 6 次采集都在静止怠速下完成，源文档明确此时没有轮速与车速数据。虽然文档给出了换算公式，但没有任何运动数据能证明它对。要确认这些公式，必须补做一次实际行驶的采集。

    转速信号里为什么要排除 byte 0？

    因为源文档更正指出 byte 0 是高半字节滚动计数器，不参与转速计算。早期把 byte 0 当数据会引入周期性误差。这类「带头字节」在车上很常见，解析多字节数值前应先确认前导字节是否为计数器或状态位。

    和公开 GM 数据库匹配上就代表正确吗？

    不代表。项目只做到 50 个 ID 里有 20 个能匹配现代 GM Global A 数据库，但这是跨世代对照，只能作为线索。匹配成功不等于字节位置与刻度在本车上也一致，仍需在本车实测确认。

    这份 DBC 可以直接拿来做产品吗？

    需谨慎。源文档已指出三处问题：加速踏板字段位置与消息长度声明不一致、原始采集文件不在快照中（无法复现）、上游文件缺少许可证信息。使用前应自行确认授权并补做缺失的验证。

    延伸阅读

    参考资料

    • 项目 09 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/can_data/analysis/gm/chevy_impala_2008.md（本项目车型档案主来源：解码表、ID 清单与置信度）
    • 项目 09 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/can_data/README.md（车辆覆盖与 DBC 文件清单）
    • 项目 09 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/SOURCE.md（采集状态、DBC 规模与已知问题）

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。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

  • 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

  • Nissan Leaf ZE0：LBC 块数据与只读遥测

    结论：Nissan Leaf（ZE0，2011–2012）最反直觉的一点是：它不实现标准 OBD-II PID——连发送 `0100` 都返回 NO DATA。要读电池，必须用 UDS 服务 0x21 向 LBC（锂电池控制器）索取整块数据（如 39 字节一组的电流、电压、SOC、容量）。同时 Car-CAN 上还有一批被动广播帧（档位、转向灯、里程、车门等）可直接监听。源文档的架构默认只读，从不发送会改变车辆状态的指令。以下所有结论仅限源文档记录的这一台车。

    车辆与适用范围

    本文数据来自第三方开源项目为 Nissan Leaf 开发的只读遥测仪表盘。项目通过 ELM327 适配器读取标准与非标准数据，并用离线回放、模拟与 MQTT 等多种无车模式做测试，源码中带有大量离线测试用例。

    项 内容
    车型 Nissan Leaf（ZE0 世代）
    年款 2011–2012
    接入方式 ELM327（BLE 或 USB）；源文档另记录自 2026-10-03 起用 CANable 2 接入 Car-CAN
    采集跨度 两个车辆 profile：Leaf 版 18 项 / 61 个信号 / 33 条历史列；另一台对照车为纯标准 Mode 01（19 项 / 20 个信号）
    适用范围 仅限源文档记录的这台 Leaf；年份、电池版本与固件差异都可能改变可用数据块

    总线与寻址

    这辆车的读取要分两条路走：一条是主动的 UDS 块数据读取，另一条是被动的广播帧监听。两者的传输参数完全不同。

    项 内容
    Car-CAN 500 kbit/s；11 位标准帧；引脚 6 / 14
    EV-CAN 引脚 13 / 12；源文档要求强制只监听
    适配器参数 `ATSP6`（ISO 15765-4，11 位 500 kbit/s）
    UDS 寻址 向 LBC 请求用 `ATSH 79B`，接收用 `ATCRA 7BB`；读取服务为 0x21
    被动监听 必须关闭自动格式化（`ATCAF0`）才能拿到原始帧
    标准 OBD-II 本车不实现标准 PID，发送 `0100` 返回 NO DATA
    实测吞吐 CANable 2 在 Car-CAN 上约 1,692 帧/秒、49 个 ID、0 错误帧

    已解码信号

    下表从源文档的信号清单中抽取。项目的置信度分三档：verified（已确认）、static（静态常量）、tentative（暂定），本文按源文档标注保留。

    信号 位置（ID / DID / 字节） 解码 证据
    高压电流 LBC 数据块 01 s32 ÷ 1024 A verified
    电池包电压 LBC 数据块 01 u16 ÷ 100 V verified
    12 V 电压 LBC 数据块 01 u16 ÷ 1024 V verified
    绝缘电阻 LBC 数据块 01 kΩ verified
    SOC（荷电状态） LBC 数据块 01 u24 ÷ 10000 % verified
    可用容量 LBC 数据块 01 u24 ÷ 10000 Ah verified
    单体电压 LBC 数据块 02 96 × u16，单位 mV，量程 3000–4200 mV verified
    电流（第二通道） LBC 数据块 05 16 位回绕：±32 A 之外按 64 A 折叠 verified（2026-09-03 定案）
    档位 Car-CAN 0x421 枚举 verified
    转向灯 Car-CAN 0x358 位标志 verified
    整车里程 Car-CAN 0x5C5 — verified
    车门 / 锁 / 灯 Car-CAN 0x60D 位标志 verified
    车速 Car-CAN 0x284 — verified
    续航 Car-CAN 0x5A9 — verified

    读取方法与注意事项

    第一条是「不按标准 OBD 走」。多数车用 Mode 01 就能读到车速、转速等，但本车不实现标准 PID：`0100`（查询支持哪些 PID）返回 NO DATA。因此不能指望通用的 OBD 诊断 App 直接读出电池信息，必须走 UDS 服务 0x21 向 LBC 请求数据块。

    第二条是块数据的规模与时序。LBC 的第一个数据块约 39 字节，包含电流、电压、SOC、容量等多个字段；单体电压块则是 96 个 16 位值（对应电池单体），量程约 3000–4200 mV。源文档实测在 CANable 2 上，Car-CAN 约 1,692 帧/秒、49 个 ID、零错误帧，一次完整的 96 节电芯读取约 351 毫秒——这给出了「块读取能不能满足刷新需求」的量化参考。

    第三条是回绕陷阱。数据块 05 的电流是 16 位字段：当真实电流超出 ±32 A 时，读数会按 64 A 折叠回绕。也就是说，读到一个看似很低的电流，可能其实是对应的大电流。源文档在 2026-09-03 把这一行为定案。

    证据等级与边界

    源文档的置信度分三档：verified 表示已在实车或离线回放中确认；static 表示该字段在该车上恒为常量；tentative 表示暂定。表中所列以 verified 为主，原样保留标注。此外项目还保留一台对照车的纯标准 Mode 01 profile，用来区分「Leaf 特有的非标准读取」与「通用 OBD 路径」。

    安全边界方面，源文档明确记录了这套工具会发送与不会发送的内容：只发送 UDS 服务 0x21（只读）、标准 Mode 01/03/07，以及适配器自身的监听模式；从不发送会清除或改写 ECU 的指令。EV-CAN 上强制只监听。这一设计把「读车」与「改车」彻底分开。

    适用范围上必须强调：以上数据块布局、字段刻度与广播 ID 都限定在这一台 2011–2012 年的 ZE0 上。不同年份、不同电池容量版本（如 24/30/40 kWh）的 Leaf，其数据块与可用 PID 都可能不同，跨车使用前必须重新核对。

    常见问题

    为什么普通的 OBD 诊断 App 读不到这辆车的电池？

    因为本车不实现标准 OBD-II PID，发送 `0100` 会返回 NO DATA。通用 App 依赖标准 PID，自然读不到。要读电池必须用 UDS 服务 0x21 向 LBC（用 `ATSH 79B`、`ATCRA 7BB`）索取数据块。

    为什么读到的电流有时明显偏小？

    因为数据块 05 的电流是 16 位字段，真实值超出 ±32 A 时会按 64 A 折叠回绕。看到的低值可能对应实际的大电流，需要按回绕规则还原。源文档在 2026-09-03 确认了这一行为。

    被动监听需要什么特殊设置？

    源文档要求关闭自动格式化（`ATCAF0`），否则适配器会把原始帧「翻译」成标准格式，丢失块数据所需的信息。EV-CAN 上则强制只监听。整轮循环在实测硬件上约 0.58 秒完成。

    这套读取方式安全吗？

    源文档的设计是只读：只发送服务 0x21、标准 Mode 01/03/07 与监听模式，从不发送清除或改写指令，EV-CAN 强制只监听。即便如此，任何实车操作仍应自行复核并遵守当地法规。

    延伸阅读

    参考资料

    • 项目 08 —— public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/README.md（本项目车型档案主来源：只读架构、profile 与安全边界）
    • 项目 08 —— public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/docs/SIGNALS.md（数据块字段、置信度分级与广播帧表）
    • 项目 08 —— public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/docs/CAN_TRANSPORT.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

  • 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

  • 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