1. 星载计算机长期运行稳定性验证概述

星载计算机是卫星平台与载荷的“大脑”，承担姿态控制、轨道计算、遥测遥控、载荷数据管理与故障处置等关键任务。与地面计算设备不同，它一旦入轨，几乎无法进行人工现场维护，任何一次非预期复位、任务中断或数据丢失，都可能演变为不可逆的整星损失。因此，长期运行稳定性验证不是一次普通的软件测试，而是贯穿方案、研制、集成、在轨全过程的系统性工程活动。本章作为课程开篇，先厘清验证对象、稳定性定义、验证与测试的区别，以及全生命周期验证框架，为后续各章的具体方法奠定概念基础。

课程目标与验证对象界定

本课程的目标是让读者能够独立设计并执行一套面向星载计算机的长期运行稳定性验证方案：明确验证对象与边界，选择合适的加速与注入手段，采集并判读关键指标，最终给出可支撑放行决策的结论。要达成这一目标，第一步是把“验证对象”界定清楚。

星载计算机并非单一软件，而是一个软硬件耦合系统。验证对象通常包括：

• 硬件层：CPU/SoC、存储器（SRAM、SDRAM、NAND/NOR Flash、MRAM）、看门狗、复位电路、电源模块、总线接口（SpaceWire、1553B、CAN、RS-422）及FPGA/ASIC逻辑。
• 软件层：引导程序、实时操作系统或裸机调度器、任务管理、内存管理、文件系统、通信协议栈、故障检测与恢复（FDR）模块。
• 系统层：软硬件交互、任务时序、冗余切换逻辑、在轨可重构能力。

界定对象时需同时明确“不验证什么”。例如，若某型号采用经过飞行验证的商用操作系统内核，验证重点可放在任务级调度与FDR逻辑上，而非内核本身的算法正确性。边界清晰，才能避免验证范围无限扩张或关键路径遗漏。

长期运行稳定性的定义

“长期运行稳定性”指星载计算机在规定任务周期内，在预期环境与工作负载下，持续保持功能正确、时序确定、资源可控且故障可恢复的能力。它包含四个可观测维度：

• 功能正确性：任务输出与预期一致，无静默数据错误。
• 时序确定性：关键任务周期抖动、中断响应时间在允许范围内。
• 资源可控性：内存无泄漏、堆栈不溢出、文件系统不碎片化到失效、句柄与队列不耗尽。
• 故障可恢复性：单粒子翻转、看门狗超时、通信中断等异常后能自动恢复且不累积损伤。

需要强调的是，稳定性不等于“不出错”，而是“出错后仍能回到可控状态”。例如，某星载计算机在连续运行2000小时后出现一次看门狗复位，若复位后任务在30秒内全部恢复且无数据丢失，这仍属于可接受的稳定性表现；反之，若复位后文件系统损坏导致载荷无法工作，则稳定性不达标。

验证与测试的区别

工程实践中，“测试”与“验证”常被混用，但二者目标不同。测试关注“系统在给定输入下输出是否正确”，验证关注“系统是否满足规定的需求与约束”。测试是验证的手段之一，但验证还包括分析、评审、仿真与在轨数据评估。

举例来说，对内存泄漏的验证，不能只靠一次8小时压力测试通过就下结论；还需要结合代码静态分析、内存分配路径评审，以及长时间运行下的趋势数据，才能形成完整验证证据链。

全生命周期验证框架

长期运行稳定性无法在单一阶段完成验证，必须按“需求—设计—实现—集成—在轨”逐级递进，每一阶段输出可追溯的证据。下图给出全生命周期验证框架的核心结构与证据流向。

框架的核心逻辑是“逐级递进、证据可追溯、在轨闭环”。需求阶段必须把“长期稳定”翻译成可量化指标，例如：连续运行时间≥2000小时、看门狗误触发率≤1次/1000小时、内存泄漏率≤0.1%/100小时、单粒子翻转后恢复时间≤30秒。设计阶段通过FMEA与故障树识别薄弱环节，决定冗余与恢复策略。实现阶段用静态分析与单元测试消除确定性缺陷。集成阶段用长时拷机与故障注入暴露时间相关缺陷。在轨阶段用遥测趋势与复位统计验证真实表现，并反向驱动前序阶段迭代。

为什么必须全生命周期验证

长期运行稳定性缺陷具有“时间相关性”：内存泄漏、计数器溢出、文件系统碎片化、看门狗累积误触发等问题，往往在短时测试中不可见，却在数百小时后突然暴露。若只在集成末期做一次长时测试，缺陷发现太晚，修改成本极高；若只依赖在轨数据，则风险不可控。因此，必须把验证活动前移并贯穿全生命周期，让每一阶段都承担明确的稳定性验证责任，形成“早发现、早收敛、在轨可闭环”的工程能力。