Palisade 只读 CAN 解码器:9 条报文、28 信号与三条边界

作者:

在

结论:这份 Palisade 2020 解码器不是通用 DBC 解析器,而是被压缩到 9 条报文、28 个信号的窄口径只读实现:未知帧静默忽略,已知报文的 payload 长度不符则直接返回错误。决定它可用性的不是那张报文表,而是三条边界——它是 opendbc 的 MIT 授权只读子集、不引入上游任何车辆控制与发送代码、未用实车日志按年款与市场确认前不得把新信号提升为 canonical 状态。

解码授权清单:只有 9 条报文

解码器被固定在 dbc 仓库的 HYUNDAI_PALISADE_2020 provenance manifest 上,只直接解析下表中的报文,其余一律视为未知帧。六条报文在素材里给出了十六进制 ID,另外三条以 DBC 报文名引用。用途分两类:少数信号进入 canonical 状态(车速、转向角、纵向加速度、挡位、轮速、SCC 状态),其余只作为 raw diagnostics 呈现。

DBC 报文 CAN ID 信号 解码后用途
CLU11 未给出 CF_Clu_Vanz、CF_Clu_SPEED_UNIT 仪表车速与单位,canonical
SAS11 未给出 SAS_Angle 转向角,canonical
TCS13 未给出 ACCEL_REF_ACC、DriverOverride 纵向加速度与驾驶员制动状态,canonical
CGW1 0x541 近光、驾驶席车门、前排安全带、雨刮与灯光开关 近光映射为 night_mode,其余为 raw diagnostics
GW_DDM_PE 0x521 四门状态 raw diagnostics
DATC12 0x042 驾驶席/副驾摄氏设定温度 raw diagnostics
LVR12 0x367 CF_Lvr_Gear 换挡杆挡位状态,canonical
WHL_SPD11 0x386 WHL_SPD_FL/FR/RL/RR 四轮轮速,canonical
SCC14 0x389 ACCMode SCC 激活状态,canonical

raw diagnostics:可以读,不能判定

素材明确写明当前没有实车捕获,因此这组信号以 manifest 固定版本的 DBC 所载 message ID、bit 位置与 scale 为唯一依据。数值以 MESSAGE.SIGNAL 为键写入 VehicleState.raw_signals,在 HMI Diagnostics 中只读展示。硬规则是:不得自行解释 DBC 枚举值的含义,也不得把这些值用于车门、安全带、空调的 canonical 状态或任何车辆控制。

raw 键 DBC 物理值 换算
CGW1.CF_Gway_DrvDrSw 驾驶席车门开关 原始枚举,不解释
CGW1.CF_Gway_DrvSeatBeltSw、CGW1.CF_Gway_AstSeatBeltSw 前排安全带开关 原始枚举,不解释
GW_DDM_PE.C_DRVDoorStatus、C_ASTDoorStatus、C_RLDoorStatus、C_RRDoorStatus 四门状态 原始枚举,不解释
DATC12.CR_Datc_DrTempDispC、CR_Datc_PsTempDispC 驾驶席/副驾摄氏设定温度 raw × 0.5 + 14

唯一给出换算式的只有空调温度这一组,其余全部停在「原始枚举」层级。这不是偷懒,而是把「DBC 说有这个信号」和「这个枚举在这个年款上代表开或关」两件事分开——后者只能由实车日志证明。

0x541 近光位的实车验证判据

CF_Gway_HeadLampLow 只表示近光是否点亮,既推断不出自动灯光设置,也推断不出环境照度。因此批准这条映射前,必须在停车、点火 ON 状态下逐条记录,并核对日志 payload 第四个字节的最高位是否与下表一致;不一致就不发布该映射,而是回到 DBC 与车辆年款、配置的核对上。

条件 期望 0x541 bit 31 期望 night_mode
灯光 OFF 0 false
近光 ON 1 true
AUTO 模式 与实际近光点亮状态相同 与实际近光点亮状态相同

采集与回放必须走两条不同的路:设备以 SocketCAN can0 接入后只做接收,用带时间戳的日志记录 0x541;捕获内容绝不向物理 can0 回发,开发环境只在 vcan0 上回放。每次切换条件时单独记录时刻与观察到的灯光状态。回归 fixture 中不得放入车辆识别信息、位置、时间等敏感原始日志,只保留已验证的 0x541 帧与必要的最小状态帧。

三条边界与当前证据状态

把散落在 NOTICE 与源说明里的约束收拢成一张表,才能看清这份解码器能承担什么。

边界 具体要求 落地动作
只读 文件与解码器均为接收专用,上游的车辆控制与发送代码不引入 工程上只允许 candump 侧记录,禁止任何向实车总线的写入
未验证不提升 在车辆年款、市场、配置上用实车日志确认 frame 与 signal 之前,不把新信号加入 canonical state 新增信号先进 raw_signals,验证通过后再提级
权利与适配 派生自 opendbc 的 MIT 授权内容,须保留原始通知;须核对车型年款与市场适配性 分发时保留上游 MIT 声明,逐车型做适配核对

证据状态同样要如实标注:源说明指出实车信号验证仍在进行中,且该 DBC 的 BU_ 列表缺少若干被其报文与信号引用的节点名,严格解析器可能需要先做清理;文件本身按字节原样保留。子集规模为 9 条报文、28 个信号,固定版本的上游修订与 MIT 归属均记录在 NOTICE 中。

常见问题

这份解码器能当作完整 DBC 解析器使用吗?

不能。它是已批准 schema 的窄口径只读实现,只解码 9 条报文、28 个信号;未知帧按正常流程忽略,已知报文的 payload 长度不一致时返回错误。要做全量解析应使用通用 DBC 解析器,而不是这份子集。

raw diagnostics 里的枚举值可以直接当车门或安全带状态用吗?

不可以。素材明确要求不得自行解释 DBC 枚举的含义,也不得把这些值用于车门、安全带、空调的 canonical 状态或车辆控制。它们在 VehicleState.raw_signals 中以 MESSAGE.SIGNAL 为键只供 HMI Diagnostics 只读查看,只有空调温度给出了 raw × 0.5 + 14 的换算。

0x541 的近光位要怎么在实车上确认?

在停车、点火 ON 状态下,对灯光 OFF、近光 ON、AUTO 三种条件分别记录时刻与观察到的灯光状态,并核对日志 payload 第四个字节的最高位是否与判据表一致:OFF 为 0、ON 为 1、AUTO 与实际点亮状态相同。不一致则不得发布该映射,需重新核对 DBC 与车辆年款、配置。

采集到的车辆日志可以回放到车上总线吗?

不可以。素材规定捕获内容不向物理 can0 回发,开发环境只在 vcan0 上回放。回放前需加载 vcan 模块并创建 vcan0 接口,再用日志回放工具把 can0 映射到 vcan0。回归 fixture 中也不得保留车辆识别信息、位置与时间等敏感原始日志。

这份 DBC 子集的权利与适配边界是什么?

它是 opendbc 中 Hyundai CAN DBC 的只读子集,沿用上游 MIT 授权,分发时必须保留原始通知与归属声明;同时源说明要求在使用前核对车型年款、市场与配置适配性。此外该文件的 BU_ 列表缺少若干被引用的节点名,严格解析器可能需要先清理,实车验证也仍在进行中。

延伸阅读

参考资料

  • 项目 01 —— public-can-dbc-datasets/additional/oas-ai-palisade-read-only/decoder-guide.md(9 条报文解码清单、raw diagnostics 目录与 0x541 验证判据)
  • 项目 01 —— public-can-dbc-datasets/additional/oas-ai-palisade-read-only/NOTICE.md(只读子集的上游修订、MIT 归属声明与只读使用限制)
  • 项目 01 —— public-can-dbc-datasets/additional/oas-ai-palisade-read-only/SOURCE.md(9 报文/28 信号的版本固定、BU_ 缺失提示与年款适配提醒)

免责声明

本文所述解码器与 DBC 子集为社区逆向工程与公开派生产物,不代表车辆制造商的官方数据。素材中的使用限制已如实转述:该子集为接收专用,不引入上游车辆控制与发送代码;在按车辆年款、市场、配置用实车日志确认 frame 与 signal 之前,不得将新信号纳入 canonical 状态;分发时须保留上游 MIT 授权通知。文中所有 ID、位定义与换算均来自上述公开文件,未经独立实车验证,不同年款与市场可能存在差异,涉及安全相关用途时仅作参考。

更新记录

  • 2026-10-14 初稿

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注