企业官网建设流程全解析

摘要：原型跑通了，准备交付——然后评审会上有人问了一句"实时性怎么验收"，会议室安静了。这篇文章把机器人实时系统的验收拆成 12 项可执行的测试，每项都给出"测什么、怎么测、合格线在哪"，按时序指标、边界压力、故障注入、时间回归四组组织。文末有一份可领取的验收清单模板。核心观点先说：验收不是"测一次"，是建立一条可重复、可回归的基线。

一、验收会上的沉默

一个很常见的场景：团队花三个月把机器人原型跑通了，演示流畅，指标好看，准备进入小批量交付。评审会上，质量负责人问了一句：

“实时性怎么验收？”

“我们测过，控制环平均延迟 800µs，挺好的。”

“最坏情况呢？”

“……没有专门测过。”

会议室安静了。三个月后，客户现场出现偶发抖动，返修、排查、扯皮，追溯下来发现：从来没有人做过量化的、覆盖最坏情况的实时性验收。早期评审时那个没说出口的"没有"，最终变成了现场的一个个深夜。

这篇不给理论，只给一份可以直接拿去用的验收清单——12 项测试，按四组组织。每一项都有明确的测量方法、合格线和数据口径，团队照着做完，就有了自己的实时性基线。

二、先立三条验收原则

2.1 原则一：只看分位数，不看平均值

平均值是实时性的头号敌人。一个平均 800µs、偶尔 30ms 的控制环，"平均成绩"可以很漂亮，但用户遇到的所有故障都来自那条 30ms 的尾巴。

验收报表的四件套：P50、P99、P99.9、max。平均值可以写，但只能出现在结论的注脚里。

2.2 原则二：真实负载，不是空载

空载跑出来的数据只能说明"闲着的时候很稳"。验收必须在真实负载下做：真实的推理模型、真实的轨迹、真实的通信量、真实的温度。

推论：验收环境要尽量等于客户现场——散热条件、供电条件、通信拓扑，能复现就复现。

2.3 原则三：时长覆盖所有时间尺度

实时系统的故障有三个时间尺度：毫秒级（中断、调度）、分钟级（温升、电源状态）、小时级（内存碎片、句柄泄漏）。对应的验收时长：每项测试 30 分钟起步，关键项（长跑）做到 72 小时。

2.4 验收的四个层次

三条原则之下，验收内容分四个层次，下面的 12 项清单就是按它们组织的：

• 指标层（平时稳不稳）：时序指标的常态值——对应 A 组；
• 压力层（极限在哪）：负载升到边界时，指标从哪开始劣化——对应 B 组；
• 故障层（坏了怎么办）：注入故障，验证降级与安全行为——对应 C 组；
• 时间层（一个月后还稳吗）：长跑、重启、版本回归——对应 D 组。

四个层次缺一个，验收就是不完整的：只有指标层，是"跑分"；加上压力层，知道边界；加上故障层，有了安全证据；加上时间层，才有抵御退化的能力。

三、12 项验收清单

A 组：时序指标（测"平时稳不稳"）

1. 控制周期守时性
测什么：控制线程每个周期实际启动时刻与计划时刻的偏差。
怎么测：在周期任务的入口打时间戳，连续记录，统计分位数。
合格线：P99.9 偏差小于周期的 20%，max 小于周期的 50%。

2. 控制链延迟
测什么：从状态采样到力矩输出的端到端时间（不是单个函数的耗时）。
怎么测：GPIO 打点 + 示波器，或全链路统一时钟打点；至少覆盖 1000 个周期。
合格线：P99.9 在预算内（对应控制周期的分配表），max 不得超过预算的 1.5 倍。

3. 时钟一致性
测什么：全链路时间戳是否同源单调，有没有被 NTP/手动校时污染。
怎么测：检查所有打点用的时钟源；在 NTP 校时事件前后对比时间戳连续性。
合格线：实时路径上 100% 使用单调时钟；存在墙上时钟混用的，整改后重测。

B 组：边界与压力（测"极限在哪"）

4. 负载阶梯测试
测什么：指标随负载变化的拐点——你的系统在多大负载下开始劣化。
怎么测：CPU、总线、内存负载从 50% 阶梯升到 100%，每档稳定运行 10 分钟，记录指标。
合格线：在标称最大负载的 80% 处，各项时序指标仍在合格线内（留 20% 余量）。

5. 满配组合测试
测什么：最坏组合下的表现——最大轴数 + 最高轨迹速度 + 全部传感器 + 全部通信同时开启。
怎么测：按产品规格书的上限配置系统，跑 30 分钟。
合格线：所有时序指标不劣化超过基线的 50%；出现超差项必须定位到具体资源。

6. 温升边界测试
测什么：高温或长时间运行后，指标有没有因热降频劣化。
怎么测：堵住散热或加热至规格上限温度，或先长跑 1 小时再测；记录温度-指标曲线。
合格线：规格书温度范围内，max 延迟劣化不超过 2 倍；超过则需要调整功耗策略。

C 组：故障注入（测"坏了怎么办"）

7. 单点故障注入
测什么：杀进程、拔网线、断开传感器、关掉一路电源，系统是否有确定的降级与安全停机行为。
怎么测：逐项注入，每次记录：检测时间、降级动作、安全状态达成时间、恢复流程。
合格线：每一项故障都有预定义的行为，且安全状态达成时间在规格内；出现"卡死无人管"的，一票否决。

8. 通信扰动测试
测什么：总线丢包、延迟抖动、报文乱序时的控制表现。
怎么测：用总线工具注入干扰（丢包率 0.1%/1%、延迟 +1ms/+10ms），观察控制链与安全逻辑。
合格线：预期内的扰动下，控制环不失控；超出预期时，按设计的兜底策略降级（如减速、保持、停机）。

9. 电源瞬断与恢复
测什么：掉电、瞬断后的状态一致性与恢复时间。
怎么测：模拟掉电（含短时瞬断），记录：安全停机是否执行、重启后状态是否一致、恢复时间。
合格线：任何一次掉电都不产生危险动作；恢复时间符合规格；连续 20 次瞬断无累积异常。

D 组：时间与回归（测"一个月后还稳吗"）

10. 72 小时长跑
测什么：长时运行下的指标漂移——内存、句柄、温度、延迟曲线的变化趋势。
怎么测：全负载连续跑 72 小时，每小时采样一次全套指标。
合格线：max 延迟曲线无上升趋势（趋势斜率为零 或 在噪声内）；内存与句柄无持续增长。

11. 重启一致性
测什么：冷启动的可重复性——每次开机，系统是不是同一个系统。
怎么测：连续冷启动 20 次，每次开机后跑同一套指标测试。
合格线：各项指标波动范围在 ±20% 以内；出现异常样本必须给出解释。

12. 版本回归基线
测什么：每次软件更新后，实时性有没有退化。
怎么测：把前 11 项的关键指标固化成基线数据；每个版本发布前跑回归，与基线对比。
合格线：无指标劣化超过 20%；任何劣化都需要书面说明和接受记录。

四、把验收变成资产，而不是一次性动作

清单跑完一遍，真正的收益才开始——把验收固化成资产，三件事：

第一，验收报告模板固定下来。每份报告必须包含：测试配置（内核版本、隔离参数、电源策略——口径和实时数据一样重要）、原始数据文件、分位数报表、结论与超差项说明。模板化的报告能在半年后救你一次——那时候没人记得测过什么。

第二，测试脚本进 CI。至少让 A 组（时序指标）和 D 组（回归基线）在每次提交后自动跑；B、C 组的压力与故障注入做成可按需触发的流水线。验收自动化的程度，决定了回归成本的高低。

第三，和供应链对齐。如果总线、驱动器、芯片来自外部供应商，把对应的验收项写进采购规格书——供应商交付的是"随附验收报告"，而不是"你自己回去测测看"。

验收中最常见的五个错误

最后把见过的坑列一下，避开它们，验收的含金量能翻倍：

1. 只测空载。实验室里安安静静跑一遍，数据漂亮，现场一上负载就现原形；
2. 只看平均。报表上最大的数字是"平均延迟"，分位数一个没有——这种报告在故障面前毫无辩护力；
3. 测完不存原始数据。只有结论没有数据，半年后想复现、想对比，只能重新测一遍；
4. 基线不更新。验收报告是"这一次"的，"下一次"的基线没人维护，退化了也看不出来；
5. 把验收当一次性动作。做完就归档，从此再没跑过——验收最大的价值，恰恰在于"重复跑"。

五、结论

把这篇压成一句话：

验收不是"测一次"，是建立一条可重复、可分位数、可回归的基线。

12 项清单的价值不在于每一项有多复杂——而在于它们让"实时性合格"从一句形容词，变成一组有数字、有口径、有人签字的证据。客户问起来，你可以打开报告；半年后自己问起来，你可以跑回归。

六、文末福利：验收清单模板

我们把 12 项测试整理成了一页纸的《机器人实时系统验收清单》模板（含各项的测试方法、合格线勾选栏、报告格式）。需要的话，在评论区留言"清单"，或私信本账号"验收清单"，我们会发给你。也欢迎在评论区说说：你们验收时测的是平均值还是 P99？

下一篇是本系列收官：《2027 年的机器人操作系统会长什么样：5 个判断》。