分析车灯动作需要带时间和实验条件的日志，只有一张报文截图很难区分因果。
本文使用Linux SocketCAN、can-utils 与隔离台架或 vcan 虚拟总线。CAN（控制器局域网）定义传输与仲裁，不提供通用的车型信号字典。大众尚酷的具体网段、信号位和校验方式必须靠对应资料与验证，本文不把演示标识符当成实车控制报文。
1. 从现象推到机制
SocketCAN 把 CAN 接口接入 Linux 网络栈，can-utils 提供抓取等工具。candump 读取接口，不负责替硬件设置只听模式。日志应记录接口配置、动作时刻与实验编号，避免不同条件混在一起。
图中的四个节点分别表示实验条件、只读采集、动作标注、离线分析。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先在虚拟接口观察命令格式。真实日志仅在确认接入条件后采集，公开分享使用合成数据并删除可识别信息。
1
2
3
candump -L vcan0
# vcan0 是先准备好的虚拟 CAN 接口
# 真实接口只听模式与电气配置需另外核对
默认先分析离线日志或使用 vcan。真实总线观测需确认适配器处于正确只听模式与电气接入条件；主动发送只在独立台架、已确认协议与可停止条件下讨论，不在行驶车辆试错。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 抓取工具正常运行 | 只证明工具进入接收流程 |
| 人工动作未记录时刻 | 难以对齐报文变化 |
| 不同会话混合分析 | 可能误把环境差异当信号 |
对照 1：抓取工具正常运行
只证明工具进入接收流程。观察时记录接口状态与是否实际收到帧。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：人工动作未记录时刻
难以对齐报文变化。观察时记录动作时间与日志时间基准。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：不同会话混合分析
可能误把环境差异当信号。观察时记录实验编号和配置快照。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
日志可见不代表已经理解信号。先构建静止、左灯、右灯和关闭的对照，再分析候选变化，不向真实总线主动重放未知帧。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“不同会话混合分析”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
