结论：2010 款梅赛德斯-奔驰 E350 轿车（底盘 212.056）的仪表在 20 针连接器上只有 7 个脚需要接：1 脚地、4 与 6 脚 +12 V、12/13 脚 CAN E、17/18 脚 CAN B。用一块 Arduino Mega 2560 加 MCP2515 屏蔽板以 500 kbit/s 只驱动 CAN E，就足以把仪表在预启动与整车上电状态之间反复切换——控制只需一个 ID、一个字节：CAN ID 0x001，字节 0 取 04 为全开、00 为关闭。而这个 ID 并不在随附的 DBC 文件里。
七根线的接线表
仪表背面只有一个连接器且没有任何标注。依据原厂维修文档的电气图，20 个脚里只有 7 个需要关注：1、4、6 三脚是地与电源（其中一路推测为点火触发），剩下四脚分成两组 CAN。
| 仪表引脚 | 连接 |
|---|---|
| 1 | 接地 |
| 4 | +12 V |
| 6 | +12 V |
| 12 | CAN E Low |
| 13 | CAN E High |
| 17 | CAN B Low |
| 18 | CAN B High |
两组 CAN 各自在两端配置 120 Ω 终端电阻，屏蔽板一端与仪表一端各一个。只通电而没有有效报文时，模拟时钟归位到 12:00，屏幕、背光、警告灯与指针全部保持不动——这个现象本身就是有用的基线判据。
本次台架只有一块 Arduino Mega 2560，因此一次只能驱动一条总线，下列结果全部来自 CAN E（12、13 脚），CAN B 未连接。配置参数为：Seeed Studio CAN-BUS Shield V2.0（MCP2515 控制器）、CAN 速率 500 kbit/s、MCP2515 时钟 16 MHz、串口 115200 波特并以换行结束。
DBC 的十进制陷阱与八条报文的实测结果
参考用的 mercedes_benz_e350_2010.dbc 给报文起名字、描述已知信号在载荷里的位置，但它不保证每条定义都完整或正确。这份文件里有一个必须先纠正的坑：报文 ID 用十进制书写，写进 Arduino 程序前必须转成十六进制。
| DBC 报文名 | 十进制 ID | 十六进制 CAN ID | 当前结果 |
|---|---|---|---|
DRIVER_CONTROLS |
69 | 0x045 | 显示屏唤醒与 OK 键控制可用；方向盘其余按键未解 |
IGNITION |
581 | 0x245 | DBC 未给出任何字节或信号定义；静态载荷穷举无可见响应 |
WHEEL_SPEEDS |
515 | 0x203 | 未测试；车速表控制的主要候选 |
DOOR_SENSORS |
643 | 0x283 | 车门开与关状态可用 |
SEATBELT_SENSORS |
885 | 0x375 | 未测试 |
GAS_PEDAL |
261 | 0x105 | 未验证；DBC 含发动机转速字段但定义不完整 |
GEAR_LEVER |
109 | 0x06D | 未测试 |
GEAR_PACKET |
115 | 0x073 | 未测试 |
另一个容易混淆的点：日志里偶尔出现仪表发出的十六进制 ID 0x581，它与十进制 581 不是同一条报文——十进制 581 是 0x245。DBC 帮着确认了 0x045 与 0x283 的可用性，也给出了 0x245 这个点火相关候选，但真正的点火控制最后是在 DBC 之外的 0x001 上找到的。
一个字节的点火状态表
最初的候选载荷带一个七字节后缀 80 CF AD AA 07 10 55，逐一把字节 1 到 7 清零后，四个状态的行为完全不变——字节 0 单独就够用。以 100 ms 周期发送、DLC 为 8：
| 字节 0 | 字节 1–7 | 台架确认行为 | 当前标签 |
|---|---|---|---|
| 00 | 全零 | 回到预启动状态，屏幕随后休眠 | OFF |
| 04 | 全零 | 自行唤醒仪表并产生完整上电响应 | 最小全开 |
| C2 | 全零 | 仅安全带警告灯与 SRS 故障提示，仪表背光不全亮 | 受限 / 类 ACC |
| CC | 全零 | 警告灯全亮、仪表与屏幕背光亮、循环显示缺失系统警告、有提示音 | 备用全开 |
| CF | 全零 | 从全开状态约 1.5 秒后回到预启动 | 延时关闭 |
| 07 | 全零 | 持续保持时约 1.5 秒后回到预启动；保持 450 ms 后切回 CC 则维持全开 | 过渡候选，含义未知 |
最简可靠的开/关对因此是：ON 为 04 00 00 00 00 00 00 00，OFF 为全零。另一个关键结论是 0x001 的点火报文可以自行唤醒仪表——把 0x045 唤醒报文关掉后它依然生效，说明 0x045 只负责屏幕与菜单交互，不是上电响应的必要条件。
0x045 自身的两个载荷也被重新确认过：唤醒用 00 00 00 00 FF 00 00 00，会亮屏并显示「PRE-SAFE Functions Limited」；b[5] 由 00 变为 02 相当于短按方向盘 OK 键，用来清掉这条提示。车门帧 0x283 按 DBC 的交替编码：bit 0/2/4/6 分别为左前、右前、左后、右后「关闭」，bit 1/3/5/7 为对应「开启」，全关是 55 00 00 00 00 00 00 00，左前开是 56 00 00 00 00 00 00 00。
用仪表自己发出的报文做机器可读判据
仪表在运行中会自己发报文，很多 ID 在预启动与全开状态下都在发，所以「某条报文存在」没有判断价值，有价值的是可重复的载荷变化。两条报文成了可靠的状态指示器：
| 仪表状态 | CAN ID 0x015 | CAN ID 0x39D |
|---|---|---|
| 全开 | 3D FE 00 00 |
80 02 FF FF 00 8E 70 XX |
| 关闭 / 预启动 | 00 FE 00 00 |
FF 02 FF FF 00 8E 70 XX |
0x39D 的字节 0 就是状态位：80 为全开、FF 为关闭。该帧最后一个字节按 07, 0F, 17, 1F, 27, 2F, 37, 3F, 47, 4F, 57, 5F, 67, 6F, 77, 7F 循环，很像 alive counter，判断状态时不能当固定值用。
关闭时序也被这两条报文量了出来：命令切到 CF 后，0x015 的字节 0 在约 1.45 秒后由 3D 变为 00，0x39D 的字节 0 在约 1.50 秒后由 80 变为 FF。这是「CF 是有效的延时关闭命令」的直接证据。
| 仪表发出的 ID | 观测到的变化 | 当前解释 |
|---|---|---|
| 0x1C1 | 启动序列中由 00 00 00 00 短暂变为 08 00 00 00 后归零，仪表仍保持点亮 |
启动或警告灯自检标记，不是稳定的点亮判据 |
| 0x19F | 在含 F0 00、FF FF、F0 01、F0 02 等形态间变化 |
内部显示或运行状态，变化慢，不适合做主判据 |
| 0x3E1 | 字节 0 在延时关闭附近短暂由 11 变 10 再回到 11 | 短时过渡事件或确认，未解 |
| 0x39F | 多个字段在点火试验前后持续变化 | 可能含计数器或计时器，而非单个点火标志 |
这些都是仪表的输出，适合用来监控，不应该当成点火命令去回放。
07 的时序试验做了什么
为了判断 07 是不是启动（crank）状态，项目单独写了一个测试：先发 CF 三秒，再用 CC 直到 0x015 等于 3D 且 0x39D 字节 0 等于 80 各被确认三次，继续发 CC 500 ms，然后发 07，请求时长 450000 µs、实测 450432 µs，随后切回 CC 观察 8 秒。脉冲期间所有 0x015 保持 3D FE 00 00、0x39D 字节 0 保持 80、0x1C1 保持全零，没有出现任何独特的可见或可听响应；恢复 CC 后仪表维持全开，8 秒内没有发生延时关闭。
已解与未解清单
| 功能 | 状态 |
|---|---|
| CAN E 电气连接 | 已确认 |
| 屏幕唤醒（0x045） | 已确认 |
| 方向盘 OK 键（0x045） | 已确认 |
| 车门全关 / 左前门开（0x283） | 已确认 |
| 最小全开（0x001 字节 0 = 04） | 已确认 |
| 受限 / 类 ACC（C2）、备用全开（CC）、延时关闭（CF） | 已确认 |
| 450 ms 的 07 脉冲后接 CC 保持全开 | 已确认 |
| 点火期间是否需要 0x045 唤醒 / 0x2F8 | 均不需要（已确认） |
| 机器可读的开/关判据（0x015、0x39D） | 已确认 |
| DBC 中 0x245 的静态载荷搜索 | 无响应 |
| 方向盘其余按键、车速表、转速表、燃油与水温表 | 未解 |
| CAN B 网络 | 未测试 |
全开状态下仪表会循环显示大量缺失系统的警告并发出提示音，原因是台架没有提供 SRS、ESP/ABS、发动机、变速箱、PRE-SAFE、Tele Aid、胎压等系统以及 CAN B 上各模块的报文。这些警告恰恰是「仪表确实进入了完整工作状态」的证据，不代表那些系统已被模拟或解码。
证据边界
| 未决问题 | 现状 |
|---|---|
| 0x001 是否为原厂点火开关报文 | 未证明；只证明它在该台架上可复现地控制状态 |
| 04 / C2 / CC / CF / 07 的原厂含义 | 未从真实车辆录制中确认；标签只描述台架行为 |
| 07 是否为启动状态 | 未证明；也可能只是未通过 1.5 秒关闭延时的非 ON 值 |
| 0x2F8 伴随帧 | 单独发送无变化；与 C2 同发时出现「SOS Tele Aid Inoperative」；与 CC 同发无即时变化，含义未知 |
| DBC 的 0x245 | 64 次单位置位、每字节 12 个候选值、每字节 00–0F 共三轮穷举均无响应；可能仍需计数器、校验、伴随帧或前置状态 |
| 0x1C1 / 0x19F / 0x3E1 / 0x39F | 未完全解码 |
| 单总线测试 | 一次只能驱动一条 CAN，无法复现整车内的全部交互 |
这里有一条方法论上的界线值得单独说明：一条报文即使原厂含义未知，也完全可以在模拟器里好用。标签描述的是台架上看到的行为，不等于它在每一代 W212 上的生产编码。
常见问题
为什么 DBC 里的 581 不是 CAN ID 0x581？
因为该 DBC 用十进制书写报文 ID，581 要转成十六进制才是 0x245。日志里偶尔出现的十六进制 0x581 是仪表发出的另一条报文，与十进制 581 无关。写进 Arduino 程序前必须做这次进制转换，否则发到了完全不同的 ID 上。
只接 CAN E 能不能让仪表完整工作？
不能。仪表同时接收 CAN E 与 CAN B，只接 CAN E 时它拿不到其余系统的信息，因此会循环显示缺失系统的警告并发出提示音。本次台架受限于只有一块单片机，全部结果都来自 CAN E，CAN B 尚未测试。原厂文档也说明仪表需要两路总线输入、电路 15 状态、轮速来计算车速，以及发动机运转信息与转速来驱动转速表。
怎么判断仪表是否真的进入了点火状态？
不要看某条报文是否存在，而要看可重复的载荷变化：0x015 在全开时为 3D FE 00 00、关闭时为 00 FE 00 00；0x39D 的字节 0 在全开时为 80、关闭时为 FF。发 CF 后，两者的切换分别发生在约 1.45 秒与约 1.50 秒。注意 0x39D 的末字节是循环计数，不能当固定值比对。
DBC 里 0x245 的静态穷举没有任何反应，是不是说明这个 ID 无效？
不能这样推断。DBC 只给了 BO_ 581 IGNITION: 8 XXX，没有信号位置、计数器、校验或有效载荷示例。单位置位 64 次、每字节 12 个候选值、每字节 00–0F 共三轮搜索都无可见或可听反馈，但真实报文可能需要多个非零字节、alive counter、校验和、伴随帧或某个前置状态。既然 0x001 已能提供可靠的台架控制，继续盲搜 0x245 的优先级较低。
07 到底是不是启动状态？
还不能确认。已证明的是：由 CC 保持 07 超过约 1.5 秒会让仪表回到预启动；而保持约 450 ms 再切回 CC 则维持全开，脉冲期间 0x015、0x39D、0x1C1 均无变化。这可能是一个真正的启动状态，也可能只是一个没能撑过仪表关闭延时的非 ON 值，需要补一次同样 450 ms 的 CF 对照试验来区分。
延伸阅读
- 标致 207 仪表 IPC：4 根线与一份种子 DBC —— 另一例「DBC 不完整、靠实测补」的仪表台架
- MX-5 ND2 自定义仪表盘：8 报文 14 信号的取数边界 —— 仪表取数时的取舍方法
- G55/W463 的 CAN-B 故障隔离：三步 A/B/A 对比定位连接器 —— 奔驰双总线架构下的排障思路
- 用 SavvyCAN 示例数据集复现 CAN 分析流程：三份 DBC 与 12 种格式 —— 把台架结果整理成可复现流程
- 车型数据库 —— 按车型检索更多 CAN 档案
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/izakulus-w212-cluster-notes/README.md（引脚表、DBC 十进制 ID 对照、0x001 状态表、RX 判据与未决问题清单）
免责声明
本文所述内容为社区逆向工程产物，不代表梅赛德斯-奔驰或任何车辆制造商的官方数据。所有 ID、载荷与时序均来自上述公开仓库的说明文件，其效力仅限于作者自述的个人台架环境，未经真实车辆录制验证；不同年款、市场与配置可能存在差异。文中用于搜索 CAN ID 与字节组合的程序明确只适用于独立的台架环境，不得用于整车。请勿在安全相关用途中引用本文内容。
更新记录
- 2026-10-15 初稿
发表回复