真实车辆协议尚未确认时，可以先验证上层状态机与通信封装，避免把软件逻辑错误带到硬件试验。
本文使用Linux SocketCAN、can-utils 与隔离台架或 vcan 虚拟总线。CAN（控制器局域网）定义传输与仲裁，不提供通用的车型信号字典。大众尚酷的具体网段、信号位和校验方式必须靠对应资料与验证，本文不把演示标识符当成实车控制报文。
1. 从现象推到机制
用 OFF、LEFT、RIGHT 和 HAZARD 表达演示状态，状态到字节的映射完全由虚拟协议定义。虚拟帧只能证明软件发送、解析与状态迁移，不能证明大众尚酷真实灯光会接受相同内容。
图中的四个节点分别表示上层意图、虚拟编码、vcan 通道、状态回读。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
准备 vcan0 后，在一端接收合成帧，另一端只向该虚拟接口发送。下列标识符与字节是教学自定义值，严禁解释为车型实测。
1
2
3
4
5
candump vcan0
# 另一个终端：仅向虚拟接口发送合成协议
cansend vcan0 123#0100
cansend vcan0 123#0200
cansend vcan0 123#0000
默认先分析离线日志或使用 vcan。真实总线观测需确认适配器处于正确只听模式与电气接入条件；主动发送只在独立台架、已确认协议与可停止条件下讨论，不在行驶车辆试错。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 虚拟接口收到合成帧 | 说明软件链路可收发该格式 |
| 左右状态快速切换 | 状态机应按定义保留唯一当前状态 |
| 把合成值套到真实车辆 | 没有任何车型控制有效性依据 |
对照 1：虚拟接口收到合成帧
说明软件链路可收发该格式。观察时记录虚拟接口名和原始帧内容。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：左右状态快速切换
状态机应按定义保留唯一当前状态。观察时记录事件顺序与解析结果。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：把合成值套到真实车辆
没有任何车型控制有效性依据。观察时记录协议来源与台架验证范围。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
此实验不包含实车控制结果。协议适配应是可替换模块，真实映射必须单独验证后接入，不能靠修改接口名完成迁移。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“把合成值套到真实车辆”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
