在工业控制、机器人、航空电子和实时通信等领域，操作系统选型或升级完成后，项目往往需要进行一轮系统验收。工程团队通常会检查系统能否正常启动、驱动是否工作、应用能否运行，再通过cyclictest等工具测量实时延迟。
这些测试都很重要，但它们并不能单独回答一个更关键的问题：这套操作系统能否在目标硬件、真实业务负载和规定的运行条件下，持续满足应用程序的时间约束？
例如，某个实时 Linux 平台在空载时获得了较低的唤醒延迟，但接入多个伺服轴后，控制算法的执行时间开始变化；某个系统在短时间压力测试中没有出现异常，却在连续运行数小时后发生队列积压；又或者，通信状态始终正常，但控制任务偶尔错过截止时间。
这些情况说明，实时操作系统验收不能只关注一个延迟数字，也不能仅凭设备运行正常就得出结论。验收需要把操作系统配置、硬件与驱动、任务模型、通信链路、压力测试和长期稳定性放在同一套验证框架下。
本文以工业控制、EtherCAT 多轴控制和嵌入式实时系统为主要场景，介绍如何建立一套可执行、可复现、可追踪的实时操作系统验收流程。
一、验收之前先明确需求：系统究竟需要满足什么条件？
实时系统验收中最容易出现的问题之一，是测试已经开始了，却没有事先定义什么结果才算合格。
例如，测试人员测得平均唤醒延迟为 5 μs，就认为系统满足实时要求。但如果实际控制任务要求在 300 μs 内完成，且测试没有测量任务执行时间，那么这项测试就不足以证明应用满足截止时间要求。
因此，验收的第一步不是选择测试工具，而是把业务需求转化为可以测量和判定的指标。
1. 区分周期、执行时间、响应时间和端到端延迟
在周期控制系统中，这几个指标经常被混用，但它们描述的是不同的时间行为。
| 指标 | 含义 | 验收时需要确认的问题 |
|---|---|---|
| 任务周期 | 任务计划释放之间的时间间隔 | 目标周期是多少，是否允许周期变化 |
| 唤醒延迟 | 预期释放时刻到实际开始运行之间的时间差 | 调度是否及时 |
| 执行时间 | 本次任务开始执行到完成之间的时间 | 计算和处理是否超出预算 |
| 响应时间 | 任务释放到任务完成之间的时间 | 是否满足截止时间 |
| 端到端延迟 | 从指定输入事件到指定输出事件之间的时间 | 整条数据与控制链路是否满足时限 |
| 截止时间违约 | 任务完成时刻晚于规定截止时间 | 是否发生不可接受的时间违约 |
例如，一个控制任务的目标周期为 1 ms，并不意味着任务一定可以用完整的 1 ms 进行计算。系统还可能需要完成输入处理、输出更新和其他必要工作，实际允许的执行预算应当由应用的时序设计决定。
同样，cyclictest测量的是周期定时唤醒延迟，不能直接代表控制算法的完整响应时间，更不能直接等同于从输入采样到伺服设备执行输出的端到端延迟。
2. 建立需求与验收指标的对应关系
在实际项目中，建议建立一份需求追踪表，将每项需求对应到具体测试方法和通过条件。
| 需求 | 验收指标 | 验证方法 |
|---|---|---|
| 周期任务按时运行 | 启动迟到、周期误差、违约次数 | 应用埋点、调度追踪 |
| 控制算法及时完成 | 执行时间、响应时间 | 应用时间戳、负载测试 |
| 现场总线数据及时更新 | 数据年龄、通信状态、更新时间 | 主站统计、设备时间戳 |
| 多轴控制满足时序要求 | 各轴数据更新时间、同步误差 | 多轴联调、设备测量 |
| 系统承受目标业务负载 | 延迟分布、资源占用、违约次数 | 组合压力测试 |
| 系统长期运行稳定 | 延迟趋势、资源变化、故障计数 | 长时间运行测试 |
| 异常发生后按预期处理 | 故障检测时间、状态转换、恢复行为 | 故障注入与受控测试 |
通过这种方式，验收就不再是若干互不相关的测试命令，而是对系统需求逐项提供证据。
需要强调的是，表格中的指标和方法只是通用框架。具体阈值必须由项目需求、控制算法、设备特性和适用的规范确定，不能把某个示例值直接套用到所有实时系统。
3. 明确测试边界与验收条件
验收前还需要确认系统的适用范围，包括目标硬件、CPU 核心数量、驱动版本、内核配置、实时线程设置、设备数量和业务负载。
如果系统只在两轴设备上完成测试，就不能直接宣称它已经验证了八轴配置；如果只测试了空载环境，也不能直接推断其在高网络负载或持续日志写入时同样满足要求。
同时，应明确哪些异常属于不可接受的失败，哪些现象允许在限定条件下发生，以及出现故障时系统应该采取什么行为。
对于涉及安全要求的设备，还必须区分普通实时性能验收与功能安全验证。即使系统延迟表现良好，也不能据此证明其已经满足特定的安全完整性要求。
二、验收环境怎么搭建：确保测试结果可复现
如果测试环境不稳定，或者不同测试轮次之间存在大量未记录的差异，那么即使得到一组漂亮的数据，也难以判断结果是否可信。
实时系统验收的第二步，是建立能够复现的测试环境。
1. 固定硬件和软件基线
测试记录应当包括以下信息：
CPU 型号、逻辑 CPU 拓扑、内存及关键外设。
BIOS 或固件版本，以及影响性能的电源管理配置。
内核版本、内核配置、启动参数和实时补丁状态。
设备驱动、EtherCAT 主站及应用程序版本。
线程调度策略、实时优先级与 CPU 亲和性。
IRQ 分布和核心隔离相关配置。
测试工具版本、脚本版本及统计方法。
对于实时 Linux 系统，可以通过以下命令采集部分环境信息：
uname -a lscpu cat /proc/cmdline ps -eLo pid,tid,psr,cls,rtprio,pri,ni,stat,comm cat /proc/interrupts这些命令只能提供部分信息，不能替代完整的配置归档。对于内核配置，还应根据发行版和构建方式检查实际配置文件；并非所有系统都会在相同位置提供内核配置。
如果系统启用了 PREEMPT_RT，也需要记录实际使用的内核版本和配置，而不能仅凭产品名称或内核版本号推断其实时能力。
2. 明确测试工具的能力边界
不同工具适合回答不同的问题。
| 工具或方法 | 适合观察的内容 | 不能单独证明的内容 |
|---|---|---|
cyclictest | 周期定时唤醒延迟 | 实际控制任务的完整响应时间 |
ftrace/trace-cmd | 调度、中断及相关内核事件 | 所有用户态逻辑的根因 |
| 应用程序时间戳 | 任务启动、计算、输出更新时间 | 未布点的内部等待过程 |
/proc/interrupts | 各 CPU 的中断计数变化 | 某个中断是否必然导致延迟 |
| 压力测试工具 | 特定资源负载下的系统行为 | 所有真实业务场景下的表现 |
| 设备侧测量 | 总线、输出或设备响应时序 | 未测量的操作系统内部路径 |
验收时应将这些方法结合使用，而不是依赖单一工具。
例如，cyclictest出现长尾延迟时，可以通过调度追踪观察线程是否被其他任务抢占，再结合 IRQ 事件和应用层时间戳，分析延迟究竟发生在唤醒阶段、任务执行阶段，还是更靠近设备的数据交换环节。
不过，追踪事件与延迟同时出现，并不能直接证明因果关系。仍然需要通过对照测试和可重复实验验证推断。
3. 确保测量方式不会显著改变被测系统
实时系统测试尤其需要注意测量开销。
如果控制线程每个周期都进行同步文件写入，或者使用高频日志输出完整记录，那么测量行为本身就可能改变调度和 I/O 负载。
更合适的做法通常是在关键路径中记录必要的时间戳，并使用预分配的固定容量缓冲区暂存数据，再由后台线程异步处理。对内核追踪，也应当合理选择事件、记录时长和缓冲区大小。
如果需要测量端到端延迟，还必须确认测量起点和终点使用的时间基准是否一致。跨设备测量时，应考虑时钟同步误差、采样分辨率以及测量设备本身的延迟。
只有测量口径明确、环境信息完整、测试过程可重复，验收结果才具有可比性。
三、如何开展性能验收：从基础延迟到真实业务链路
完成测试环境准备后，应当按照由简单到复杂的顺序开展验收。每一阶段都需要有明确的测试目的、测试条件和判定规则。
1. 第一阶段：基础实时能力测试
首先测试系统的基础定时唤醒与调度表现，建立初始基线。
例如，在支持相关工具和配置的 Linux 系统中，可以使用：
sudo cyclictest -m -p 80 -i 1000 -D 60s该命令仅用于说明测试方法，具体参数应根据当前cyclictest版本、测试目标和系统配置进行调整。
基础测试应当记录：
测试线程运行的 CPU。
测试周期与运行时长。
样本数量和统计口径。
平均延迟、P95、P99、P99.9 和最大观测延迟。
是否存在异常长尾样本。
测试时系统的实际负载情况。
如果基础测试已经出现明显异常，应先定位调度、IRQ、系统配置或资源竞争问题，再继续开展整机验收。
需要注意，短时间测试中没有出现异常，并不能证明系统在长期运行时不会出现长尾延迟。
2. 第二阶段：真实控制任务测试
基础唤醒延迟测试通过后，应运行实际控制程序，记录关键时间点。
以周期控制任务为例，可以采集：
预期释放时刻。
实际开始运行时刻。
输入数据处理完成时刻。
控制算法完成时刻。
输出更新时刻。
本次任务完成时刻。
通过这些数据，可以区分调度延迟、算法执行时间和完整响应时间。
如果控制线程启动及时，但算法执行时间偶尔增加，就应进一步分析计算负载、缓存竞争、锁等待和内存操作。如果算法本身执行时间稳定，但输出仍然迟到，则需要检查数据交换、驱动调用、线程同步和设备侧时序。
对于 EtherCAT 应用，还应结合主站周期调用、过程数据更新、从站同步配置和伺服反馈等信息。通信状态正常并不意味着端到端时序一定符合要求。
3. 第三阶段：多轴与组合负载测试
实际项目中，系统通常还要运行上位机通信、数据采集、日志处理和其他业务功能。因此，性能验收不能停留在单任务或空载环境。
建议逐步增加轴数与业务负载，并在每个阶段重新记录关键指标。
测试内容可以包括：
从单轴逐步扩展到目标轴数。
增加控制算法的实际计算负载。
增加上位机通信和网络流量。
增加日志记录与存储负载。
增加数据采集及后台处理任务。
在受控条件下模拟 CPU、内存和 I/O 压力。
组合运行关键业务并持续记录延迟分布。
测试场景应当反映目标设备的实际工作范围，而不是简单追求 CPU 使用率达到某个百分比。
如果系统在组合负载下出现长尾延迟，需要结合任务时间戳、内核调度追踪、IRQ 分布、内存状态和设备通信记录进行定位。
4. 第四阶段：判断是否满足预定指标
验收时应同时观察统计指标和实际任务结果。
| 指标 | 主要用途 |
|---|---|
| 平均延迟 | 观察整体运行水平 |
| P95、P99、P99.9 | 观察延迟分布及尾部变化 |
| 最大观测延迟 | 记录本次测试中最严重的观测值 |
| 任务执行时间 | 验证关键计算是否符合预算 |
| 端到端响应时间 | 验证完整控制链路的时序 |
| 截止时间违约次数 | 识别任务是否未按时完成 |
| 数据过期次数 | 验证输入数据是否满足时效要求 |
| 通信与设备异常 | 确认现场总线和设备状态是否满足要求 |
其中，P99 或 P99.9 不能单独作为硬实时保证，最大观测延迟也不能直接等同于理论最坏延迟。
如果项目规定关键任务不允许出现截止时间违约，就应直接统计违约次数，并结合任务模型和测试覆盖范围进行评估，而不是因为平均延迟较低就忽略少量失败样本。
对于高安全要求的系统，还应根据具体安全需求开展相应的风险分析和验证工作，不能用一般压力测试替代安全验证。
四、长期稳定性与故障处理如何验收？
实时系统在短时间内运行正常，只能说明它在该段测试时间和对应负载下表现正常。长期运行还可能受到内存使用变化、队列积压、温度与频率状态变化、后台任务累积以及低概率事件的影响。
因此，长期稳定性和故障处理应当作为独立的验收内容。
1. 建立长期运行监测
长时间测试应当持续记录关键任务的响应时间、截止时间违约次数、内存使用量、队列长度、CPU 状态和通信异常计数。
例如，可以定期检查：
vmstat 1 cat /proc/meminfo cat /proc/interrupts这些命令能够提供系统状态的部分信息，但不能独立证明某个异常的根因。若延迟在运行数小时后逐渐增加，还应结合应用程序的资源计数、队列积压记录和必要的内核追踪，分析是否存在持续累积的问题。
长期测试的时长应由项目风险、使用场景和验收规范决定。不能因为连续运行了一天没有异常，就绝对保证系统在更长时间内永远不会发生异常。
2. 验证故障检测和降级行为
性能验收不能只测试系统正常工作时的表现，还应验证出现异常后，系统是否按照设计进行处理。
对于工业控制设备，可以在受控测试环境中验证：
通信中断时是否能够正确识别故障。
输入数据过期时是否采取预定策略。
任务超时时是否产生正确的状态记录。
队列满或资源不足时是否进入预定的处理流程。
故障恢复后是否能够按照设计恢复运行。
诊断信息记录是否会反过来影响关键控制路径。
故障注入必须有明确的测试边界、恢复方法和中止条件。对于可能影响人身安全或设备安全的系统，不应在没有安全措施的真实运行环境中随意注入故障。
如果系统要求故障发生后进入安全状态，那么验收重点就不仅是“故障有没有被检测到”，还包括检测时间、状态转换过程以及最终行为是否符合系统安全设计。
3. 验证软件升级后的回归风险
实时系统的性能可能随着内核、驱动、应用程序和系统配置变化而改变。
例如，升级内核后，即使应用代码没有变化，调度行为、设备驱动、中断处理和资源管理路径也可能发生变化。因此，升级前后应使用相同的测试条件进行对照验证。
建议保留：
已验收的软件和系统配置基线。
对应的测试脚本及版本。
测试负载与运行条件。
原始数据和统计结果。
已知异常及其处理记录。
验收通过的配置和限制条件。
这样，后续出现性能回退时，工程团队才能判断变化发生在哪个版本、哪个配置或哪个执行环节。
五、形成正式验收报告：让每一项结论都有证据
一套完整的实时操作系统验收，最终应形成能够追溯到测试条件、原始数据和具体判定规则的验收报告。
报告不应只包含一张延迟曲线或一组平均值，而应当说明测试覆盖了什么、结果证明了什么，以及哪些情况尚未得到验证。
1. 建议采用的验收报告结构
第一部分：验收对象与范围
说明目标硬件、操作系统、内核版本、驱动、应用程序、设备数量和业务场景。
第二部分：需求与判定规则
列出关键任务的周期、截止时间、执行时间预算、端到端延迟要求，以及允许和不允许出现的异常。
第三部分：测试环境与配置
记录 CPU 亲和性、调度策略、IRQ 分布、核心隔离配置、测试工具版本和业务负载。
第四部分：测试方法与结果
分别展示基础唤醒延迟、真实控制任务执行时间、组合压力测试和长期运行结果，并说明样本数量、测试时长和统计口径。
第五部分：异常分析与整改
记录测试过程中发现的异常、分析方法、整改措施以及整改后的复测结果。
第六部分：验收结论与适用范围
说明哪些需求已通过验证、哪些条件尚未覆盖、存在什么限制，以及后续升级或配置变更时需要重新验证的内容。
2. 不要将一次测试结果扩大成普遍性能承诺
假设一份报告显示，在特定硬件、内核版本、驱动配置和测试负载下，系统观测到的最大唤醒延迟为某个数值。这项结论只能用于描述该测试条件下的观测结果。
它不能自动证明其他硬件、其他负载、其他驱动版本或不同应用程序也会获得相同结果。
同样，某项测试通过，也不代表所有实时任务、所有设备和所有异常条件都已经得到验证。
在评估望获OS、PREEMPT_RT 或其他实时 Linux 方案时，都应坚持相同的测试原则：统一硬件、驱动、应用、负载和测量口径，针对目标任务建立完整的验证证据，而不是只比较单一延迟数字。
3. 用验收清单完成最终检查
以下清单可以作为项目验收前的自查工具。
已定义关键任务的周期、截止时间和时间预算。
已区分唤醒延迟、执行时间、响应时间与端到端延迟。
已记录硬件、内核、驱动、启动参数和任务配置。
已完成基础调度测试和真实控制任务测试。
已覆盖目标轴数、目标业务负载和组合压力场景。
已记录平均值、百分位延迟、最大观测延迟和违约次数。
已验证数据新鲜度、通信状态和关键设备时序。
已开展符合项目要求的长期运行测试。
已验证关键异常的检测、降级和恢复行为。
已保存测试脚本、原始数据、配置和异常证据。
已明确测试结论的适用范围和未覆盖的风险。
已制定内核、驱动或应用升级后的回归测试计划。
这份清单并不意味着所有项目都应采用相同的验收阈值。实际通过条件仍然需要由项目需求和适用规范确定。
总结：实时系统验收的核心，是证明它能按时完成任务
实时操作系统验收不是简单地测试系统能否启动，也不是寻找一个足够小的延迟数字。它需要从实际业务需求出发，建立明确的时间约束，再通过基础调度测试、真实任务测试、组合压力测试和长期稳定性验证，判断系统是否满足目标应用的要求。
对于工业控制和机器人系统，验收尤其需要关注完整的数据与控制链路。操作系统唤醒及时，不代表控制算法一定按时完成；EtherCAT 通信没有报错，不代表过程数据一定足够新鲜；CPU 使用率较低，也不代表系统没有长尾延迟。
一套可靠的验收方法，应当把需求、测试环境、统计指标、异常分析和长期回归验证串联起来，并确保每一项结论都有对应的测试证据。
真正有价值的实时系统，不只是某次测试表现良好，而是在明确的工作条件下，能够按照规定的时间约束完成关键任务，并且这种能力可以被持续验证、复现和追踪。
