节点仿真：让虚拟节点参与真实开发与测试

节点仿真让台架能够代替尚未接入的 ECU，与真实被测设备交换报文。本篇介绍如何借助 AI 和 BMCLI 构建这样的通信环境，从一个虚拟节点逐步扩展到残余总线仿真。

设想正在开发的控制器要与发动机、转向助力、气囊等多个 ECU 通信，而实验室没有必要每次都接齐整套实车网络。可以根据通信矩阵与 DBC，让 BMCLI 提供缺席节点的周期报文、信号变化与必要的保护字段。这就是残余总线仿真的常见用途：真实被测节点保留，其余通信伙伴由台架模拟。

AI 负责将节点分工和工况整理为配置，BMCLI 执行相应发送与故障规则。周期报文组合起来比较直接；涉及网络管理、请求应答或状态依赖时，再按项目规范补充行为逻辑，而不是仅把几条帧循环发出。

下面先用一个 VehicleStatus 节点说明基本机制，并用第二路分析仪观察输入。它是构建多节点环境的起点；要评价 ECU 的识别、超时与恢复行为，再接入真实 DUT，并采用项目给出的反馈定义。

残余总线仿真：真实 ECU 的虚拟邻居

图 6-1　缺席节点由台架补齐，被测 ECU 保持真实。工程关系示意。

给 AI 的输入：描述节点与异常实验

本次输入是 vehicle-demo.dbc、演示 counter-sum 规则与双通道隔离台架。任务先验证仿真节点发出了什么；真实 DUT 的识别与降级测试作为后文的进一步扩展。

请使用 BMCLI，根据 vehicle-demo.dbc 仿真 VehicleStatus：周期 50 ms，Speed 在 40～80 km/h 之间以 2 秒周期变化，Gear 为 D，Counter 和 Checksum 使用我提供的演示 counter-sum 规则。台架为 10356/0 到 10357/0 的隔离连接。请先采集 10 秒正常数据，再分别进行丢帧、重复帧和校验错误实验，每轮只启用一种故障，记录规则与实际发生时间。请交付节点配置、原始采集记录和正常/异常对照报告，结束后停止本次任务。本轮以第二路分析仪的帧记录作为判据。

AI 将这些要求写成仿真清单（manifest），先做离线检查，再组织各轮发送与接收。随文 manifest已经包含一个报文任务、四个信号、一个波形源和三个命名故障，可直接作为修改起点。

成品与效果：从正常波形到异常对照

本次交付包括节点配置、正常与异常的采集记录，以及对照报告。下面展示配置及预期报文行为；真实 DUT 的容错测试在扩展部分介绍。

示例 VehicleStatus 每 50 ms 发送一次，Speed 在 40～80 km/h 之间做周期为 2 秒的正弦变化，Gear 保持 D，Counter 和 Checksum 按演示规则更新。

正常运行后，再分别观察三种故障：

场景	发送侧	接收侧的观察重点
正常节点	持续周期发送	波形平滑变化，计数连续
丢一帧	指定候选帧不发送	Counter 跳过一个值
重复一帧	重复指定载荷	相邻帧载荷重复
错误校验	修改指定帧的校验字段	数据可接收，但应用校验不匹配

表中列的是每轮实验的预期表现。将发送侧的触发计数与接收侧的数据并排记录，就能看清故障是否真正到达接收端。

这里使用的 counter-sum 是演示规则。真实项目采用 AUTOSAR E2E 或厂商算法时，可换成对应配置或插件。

实现解析：BMCLI 在成品中承担的工作

下面结合关键调用说明应用的实现方式。AI 生成的程序将这些调用组织成完整流程，并处理返回结果与任务收尾。

波形和故障都由 BMCLI 管理

# 离线检查节点配置，确认任务、信号和故障规则可以被理解。
bmcli simulation validate --file=vehicle-simulation.json --format=json
# 加载节点配置，登记后续启动与观察使用的仿真名称。
bmcli simulation load --file=vehicle-simulation.json `
  --name=tutorial-vehicle-node --format=json
# 启动本轮节点仿真，按配置持续发送到指定通道。
bmcli simulation start tutorial-vehicle-node --channel=10356/0

# 停止本轮仿真发送，为切换故障或结束实验留出明确边界。
bmcli simulation stop tutorial-vehicle-node
# 启用丢帧规则；在重新启动任务前设置，使候选帧窗口落在本轮。
bmcli simulation fault enable drop-one --simulation=tutorial-vehicle-node
# 启动本轮节点仿真，按配置持续发送到指定通道。
bmcli simulation start tutorial-vehicle-node --channel=10356/0
# 查看仿真运行状态与故障触发统计。
bmcli simulation status tutorial-vehicle-node --format=json

# 停止本轮仿真发送，为切换故障或结束实验留出明确边界。
bmcli simulation stop tutorial-vehicle-node
# 关闭本轮故障规则，避免它影响后续实验。
bmcli simulation fault disable drop-one --simulation=tutorial-vehicle-node

BMCLI 根据 DBC 编码信号，维护周期发送、波形源和保护字段。运行中还可以按信号名调整数值：

# 按信号名更新工程值，作为同一组赋值检查并应用。
bmcli simulation signal set --simulation=tutorial-vehicle-node `
  --task=vehicle --signal=Speed=65 --signal=Gear=D

这一组赋值按整体检查和应用，避免只更新了一半信号。AI 生成的脚本主要负责实验顺序、观察与报告，周期发送部分可以直接复用 BMCLI。

把每轮实验安排好

随文故障窗口为 begin=20, count=1，按任务候选帧序号触发。因此，每轮先选好故障，再启动任务，就能让触发窗口落在本轮采集中。运行很久以后才启用同一窗口，通常已经错过了它。

stop/start 会重新开始候选帧编号，但保留信号和保护计数器。若需要每轮都从同一个 Counter 初值开始，可在停止后重新加载本任务配置。

读取当前信号可使用 bmcli simulation signal get Speed --simulation=tutorial-vehicle-node --task=vehicle。写入通过 --signal=Speed=42 指定名称和值；重复该选项可在同一次调用中更新多个信号。

接收侧还可以同时检查 gaps/dropped：它们描述观察链路，业务故障则由 Counter 和校验结果判断。仿真周期任务由主机调度；需要硬件周期发送时，可以结合 txtask 组织实验。

进一步探索：让虚拟节点承担更多工作

这个案例还可以继续完善，也可以延伸到更多工作中。您可以从感兴趣的一项出发，与 AI 讨论下一步的实现。

从一个节点扩展为残余总线环境

先按 DBC 的发送节点将缺席 ECU 分组，再补齐被测 ECU 真正依赖的报文与状态关系，就能从单节点实验走向残余总线环境。可以请 AI 根据 DBC 和工况说明，将相关信号整理为协调变化的节点配置，同时明确各报文周期与保护规则。BMCLI 持续执行发送与信号变化，应用负责选择工况、显示阶段并记录 DUT 响应。后续增加工况时，团队维护的是可读的实验配置，而不是重新编写一套发送循环。

从异常报文走到容错测试

假设项目规范要求：车速报文持续中断超过一定时间后，仪表显示无效状态；计数器或校验异常则按另一套策略处理。用例应同时观察两端：

实验	输入安排	DUT 应观察的结果
通信超时	按要求停止该节点发送一段时间	无效状态是否在规定窗口出现，恢复后是否退出
Alive Counter 异常	重复受保护帧，或按已支持规则改变计数序列	是否识别异常，是否误接受旧数据
校验错误	业务值保持合理，只改变保护结果	是否拒绝异常数据，正常帧能否恢复处理

项目级测试按通信规范设置持续窗口和期望动作。随文的三种帧级实验用于检查注入结果；接入 DUT 后，再结合超时阈值安排持续中断，采集并判定它的降级与恢复响应。

从通信规范生成异常测试组合

超时、Alive Counter 跳变与错误校验，各自对应不同的接收端行为。可以把通信规范交给 AI，请它为每类异常生成独立规则、持续窗口和预期恢复条件，先在接收通道检查实际报文，再接入 DUT 验证。执行器通过 BMCLI 启用相应故障并采集状态反馈，报告同时展示注入内容和接收端反应。将正常工况与异常工况分开保留，就能逐步形成覆盖产品容错要求的回归集合。

参考阅读

以下文档介绍本篇涉及的接口；具体参数可通过本机 JSON Help 查询。

下载本篇配套示例 ZIP