控制回路级评测解决方案

客户问题

自主系统和复杂控制系统通常由决策、规划、控制、状态估计、传感器、执行器与被控对象共同组成。各模块由不同团队开发，接口、周期和测试方法各不相同。单元测试能够检查局部函数，却无法回答模块放入闭环后是否稳定；整机测试能够看到最终结果，却很难定位问题来自哪一环。

典型困难包括：

• 模块只能随整套系统测试：上游或下游尚未就绪时，被测模块无法独立进入闭环。
• 测试条件不可重复：真实环境、传感器噪声、网络时延和操作过程不断变化，版本对比缺少相同基线。
• 时间语义不一致：模块使用不同周期、时钟和缓冲策略，数据在接口层看似正确，闭环中却出现延迟、乱序或陈旧状态。
• 信号链难以追踪：输入、估计、决策、轨迹、控制量和对象响应分散在不同日志中，无法还原完整因果链。
• 故障依赖偶然发生：丢帧、漂移、执行器饱和、通信中断和环境突变难以按指定时刻、幅度与持续时间重复注入。
• 判分缺少共同真值：各团队从各自模块指标出发，系统级安全、稳定、约束和任务结果没有统一口径。
• 版本回归覆盖不足：软件、模型、标定或参数更新后，只验证修复用例，难以发现其他控制回路的耦合退化。
• 集成问题发现过晚：接口定义、单位、坐标、周期和异常处理直到联调或现场阶段才集中暴露。

控制回路级评测将整套系统拆为标准角色，并允许每个角色在真实模块、仿真替身和回放信号之间切换，使局部模块和完整系统都能在可控闭环中接受验证。

方案总览

方案把控制回路抽象为七类角色：

1. 决策：依据任务、规则和世界状态选择行为或策略。
2. 规划：把行为意图转化为路径、轨迹、速度或动作序列。
3. 控制：根据目标与估计状态计算执行器指令。
4. 被控对象：描述车辆、飞行器、机器人、设备或工艺过程对控制输入的响应。
5. 传感器：生成对对象与环境的观测，并描述采样、噪声、量程和时延。
6. 估计器：融合观测，输出位姿、速度、姿态、对象状态或系统状态。
7. 环境：提供地形、道路、气象、障碍、规则、外部参与者和扰动。

评测时选择其中一个或多个真实模块作为被测对象，其余角色由仿真模型、回放数据、规则代理或接口适配器补齐。统一时钟驱动各角色按周期执行；信号总线记录全部输入输出；故障引擎在指定条件下注入异常；真值服务提供不受被测估计链影响的参考状态；评测引擎按任务、性能、安全、稳定和时序规则判分。

同一套场景、信号和判分规则可跨版本重复运行，也可供不同部门在模块交付前完成接口验证，在系统集成时复用相同测试资产。

系统架构

系统中的核心对象是“试验规格”。它包含模块拓扑、接口映射、时钟策略、场景版本、初始状态、输入信号、故障计划、判分规则和软件版本。执行器只接受完整且通过接口检查的试验规格，保证每次结果都能关联到确定的测试条件。

核心能力

1. 控制回路角色建模

角色模型明确每个模块的输入、输出、周期、单位、坐标、状态和异常语义：

• 决策输入世界状态、任务和规则，输出行为、模式或策略选择；
• 规划输入行为目标、地图与状态估计，输出路径、轨迹和约束；
• 控制输入参考目标与估计状态，输出执行器命令；
• 被控对象输入执行器命令与外部扰动，输出真实系统状态；
• 传感器从对象和环境状态生成观测；
• 估计器从多源观测生成供决策、规划和控制使用的状态；
• 环境维护外部对象、地形、规则、天气和扰动演化。

角色之间通过带类型、时间戳、坐标和质量状态的信号连接。接口契约在运行前检查字段、单位、更新频率和坐标关系，降低联调阶段的隐式约定。

2. 被测模块替换与上下游仿真替身

任意角色均可在以下实现之间切换：

• 客户真实软件或算法模块；
• 仿真模型；
• 记录数据回放；
• 确定性规则替身；
• 人工设定的固定信号；
• 经适配器接入的外部系统。

例如，评测规划模块时，可使用结构化真值或估计器替身提供上游状态，以控制器和对象模型闭合下游；评测控制器时，可直接输入参考轨迹，由对象模型和传感器、估计器模型反馈状态；评测决策模块时，可固定规划与控制逻辑，让结果集中反映行为选择。

替换不改变试验的场景、时间、故障和判分定义，因此局部测试与系统集成可以共享同一用例。

3. 统一时钟与调度

时间系统统一管理：

• 固定步长、变步长、实时和加速运行模式；
• 不同模块周期与相位；
• 仿真时间、消息时间戳、采样时间和到达时间；
• 传感器曝光、扫描、积分和读出过程；
• 计算时延、通信时延、缓存和超时；
• 暂停、单步、快照、恢复和确定性重放；
• 事件优先级、同一时刻执行顺序和终止条件。

调度器在每个时间点记录哪些模块读取了哪一版输入、何时产生输出以及输出何时生效，使时序问题能够被复现和归因。

4. 信号录制与回放

信号系统记录控制回路中的完整因果链：

• 任务、规则、模式和操作指令；
• 原始传感器数据与传感器状态；
• 融合、定位、姿态和对象估计；
• 决策结果、规划轨迹和约束状态；
• 控制目标、控制量与执行器反馈；
• 被控对象真值、环境状态与外部扰动；
• 模块健康、超时、降级、重置与错误事件。

回放支持全链回放和分段替换。全链回放用于复核历史结果；分段替换可固定某一时刻之前的信号，再接入新模块继续闭环运行，从同一历史状态比较不同版本的后续行为。

5. 故障注入

故障可按时间、事件、状态条件或组合规则触发，并支持持续、间歇、渐变和突发形式：

• 传感器故障：噪声、偏置、漂移、丢帧、冻结、遮挡、饱和、误检和标定偏差；
• 估计故障：状态跳变、协方差失真、初始化偏差和收敛延迟；
• 通信故障：延迟、抖动、乱序、丢包、中断和带宽限制；
• 计算故障：超时、周期抖动、输出陈旧、进程重启和资源受限；
• 执行器故障：饱和、死区、速率限制、卡滞、效率下降和指令不一致；
• 对象故障：参数变化、载荷变化、部件失效和动力学响应异常；
• 环境扰动：风、坡度、附着变化、障碍突入、规则变化和外部参与者异常行为。

每次注入都记录故障定义、触发条件、实际生效时间和影响信号，确保评测报告能够还原故障与系统响应的关系。

6. 真值服务与统一判分

真值服务从仿真对象和环境直接读取参考状态，不经过被测传感器与估计链。可提供对象位姿、速度、加速度、接触、碰撞、距离、环境状态、任务阶段和事件边界。

判分规则按项目配置，覆盖：

• 任务结果：任务完成、阶段完成、终止原因和规则遵循；
• 跟踪与控制：位置、姿态、速度、轨迹误差，控制量、变化率和执行器约束；
• 稳定性：振荡、发散、超调、稳态误差和恢复过程；
• 安全性：碰撞、最小间距、越界、禁入、姿态或载荷限制；
• 时序性：周期、端到端延迟、超时、陈旧数据和截止时间；
• 鲁棒性：参数变化、故障和环境扰动下的性能变化；
• 接口健康：字段、单位、坐标、频率、空值和异常状态处理。

指标结果保留对应时间段、信号片段和场景状态，避免只给出一个总分而缺少失败证据。

7. 版本回归

回归系统把场景、初始条件、故障、信号、判分和软件版本组合成测试矩阵：

• 固定种子与固定历史快照保证版本对比起点一致；
• 基线版本与候选版本在同一试验规格下运行；
• 指标差异自动关联到首次分叉的信号与事件；
• 修复用例、接口用例、边界用例和系统用例分组管理；
• 失败用例进入索引并绑定负责人、模块、版本和证据；
• 通过规则可作为软件发布或系统集成的质量门禁。

回归结果既展示系统最终结果，也展示决策、规划、控制、估计和对象响应的中间差异。

8. 多部门集成验证

方案通过统一角色接口和试验资产连接算法、控制、嵌入式、仿真、测试和系统团队：

• 上游团队按接口契约提供模块与信号样例；
• 下游团队提前使用替身验证输入范围和异常处理；
• 各团队共享场景、时钟、坐标、故障和判分定义；
• 模块交付时先运行接口与角色级用例，再进入组合闭环；
• 系统联调复用相同信号录制、失败索引和回归报告；
• 问题定位以首次信号分叉和角色责任为依据。

这使集成验证从一次集中联调转化为贯穿模块交付过程的标准流程。

业务流程

1. 确定评测对象：选择决策、规划、控制、估计器或完整控制链作为被测范围。
2. 定义角色拓扑：描述七类角色的连接、接口、周期、单位、坐标和状态语义。
3. 配置上下游替身：为未接入模块选择仿真模型、规则代理、回放信号或固定输入。
4. 建立试验规格：绑定场景、初始条件、时钟策略、故障计划、指标和停止条件。
5. 执行基线运行：检查接口、时间同步、信号完整性和闭环稳定性，冻结基线证据。
6. 开展故障与边界扫描：按参数、事件或状态条件运行试验矩阵。
7. 真值判分与归因：输出指标、约束事件、首次信号分叉和失败时间窗。
8. 版本回归：候选版本复用同一场景与试验规格，与基线进行差异比较。
9. 集成交付：通过角色级用例后组合真实模块，逐步替换仿真替身，完成系统级验证。

典型场景

多个小组各自升级，合到一起却打架

一家做无人机的公司，要给已经卖出去的机器做一次固件升级：感知、避障、飞控几个模块分别由不同小组在改。各组自己测都没问题，可一旦装到一起飞，才发现避障的改动和飞控起了冲突，整机差点摔下来，上线只能推迟。

我们把整机拆成感知、避障、飞控等标准角色，哪个小组还没改完，就用仿真替身先顶上，让已经改好的模块在完整的闭环里先“飞”一遍，提前看出模块之间会不会打架。

这样冲突在装机联调之前就暴露出来，不用等整机试飞才发现要返工；大量真机试飞被仿真替代，省下测试成本；几个小组在同一套标准下并行改，上线不再一拖再拖。

调完参数，怕把别处改坏

一家做机器狗的团队，每次调完控制参数都心里没底：“这次改好的地方，会不会把别处弄坏？”真机跑一轮全面回归又贵又慢，只能挑几个用例试试，很多隐患就漏过去了。

我们把一批固定场景、固定干扰做成一套“标准考卷”，新旧版本用同一套考卷各跑一遍，自动指出哪项指标退步了、是从哪一刻开始出的岔子。

回归从“真机挑几个试”变成“批量自动跑一整套”，覆盖更全、成本更低；发布前就能拿到新旧版本的量化对比，心里有底，不用靠猜。

传感器突然出故障，系统还稳吗

一家做自动驾驶的团队想知道：如果激光雷达突然掉几帧、或者相机被强光晃了一下，车还稳不稳。这类故障在真车上很难精确制造，危险的更不敢真试。

我们在仿真里按指定的时刻和程度，给传感器“制造”噪声、延迟、掉帧和标定偏差，再拿一个不受影响的“标准答案”做对照，看这些毛病最后会不会传到刹车和转向上。

危险故障因此可以安全、可控、可重复地测，替代高风险的真车试验；提前找出“传感器一出问题系统就崩”的薄弱环节，把安全隐患挡在上线之前。

交付形式

• 控制回路角色模型、模块拓扑与接口契约；
• 被测模块接入适配器和上下游仿真替身；
• 统一时钟、事件调度、信号总线与录放服务；
• 被控对象、传感器、估计器和环境仿真组件；
• 传感器、通信、计算、执行器、对象与环境故障库；
• 真值服务、项目指标、约束规则和判分引擎；
• 模块级、接口级、故障级和系统级试验用例包；
• 自动化版本回归流水线、差异报告和失败索引；
• 私有部署、API、SDK、模块接入说明与测试规范；
• 面向算法、控制、测试和系统团队的集成验证工作台。

客户价值

• 模块可独立验证：上下游未齐备时也能通过仿真替身闭合控制回路。
• 问题可重复：统一时钟、固定场景、信号回放和故障计划提供一致起点。
• 结果可判定：独立真值与统一规则同时覆盖任务、性能、安全、稳定和时序。
• 退化可定位：从最终失败回溯到首次发生差异的角色、信号和时间窗口。
• 版本可回归：软件、模型、标定和参数更新复用同一试验矩阵。
• 集成风险前移：接口、单位、坐标、周期和异常处理在模块交付阶段接受检查。
• 测试资产可复用：场景、信号、故障、指标和失败用例在模块级与系统级之间共享。
• 跨部门形成共同证据：所有团队围绕同一时间轴、真值和评测报告协作。

参考文档

1. 仿真：具身智能训练的效率引擎与验证底座——任务、闭环、故障与评测矩阵
2. 算法研究场景的仿真需求矩阵
3. 传感器域随机化：相机、LiDAR、IMU 与物理扰动
4. LiDAR 真实感：扫描时序、运动补偿与透明表面处理
5. IAWG 世界生成器：结构化场景、物理稳定与可重放运行