2. 星载计算机资源分类与耗尽机理
星载计算机与地面通用计算机最大的差别，不在于算力高低，而在于它运行在一个资源封闭、不可现场扩容、不可随意重启的环境中。地面服务器内存吃紧可以加内存条、可以滚动重启；星载计算机一旦发射入轨，CPU 主频、内存容量、存储空间、总线带宽、供电功率乃至每个控制周期的时间预算，全部被固化在硬件与任务书中。因此，理解"资源耗尽"必须先建立一张清晰的资源分类地图，再理解每一类资源被"慢慢吃掉"的典型模式。
一、六类关键资源的边界
星载计算机的资源可以归纳为六类，它们并非彼此独立，而是通过任务调度相互耦合：
- CPU 时间：以任务周期和截止时间衡量。例如姿控任务周期 10 ms、制导任务周期 100 ms，若某任务单次执行从 2 ms 涨到 9 ms，即使总占用率未满，也可能挤占同优先级任务。
- 内存：分为静态分配的代码段/数据段与动态分配的堆区。星载软件通常禁用或严格限制 malloc，但遥测缓存、图像帧缓冲仍会动态申请。
- 存储：包括 NOR/NAND Flash 的程序区、参数区、日志区。日志区写满后若不回收，新日志将无处落盘。
- 总线带宽：1553B、CAN、SpaceWire 等总线的时隙或帧率是固定的，多个分系统争用同一总线时，带宽就是硬约束。
- 功耗：整星功率预算有限，CPU 满载、加热器开启、载荷工作会叠加，超过母线供给能力将触发欠压复位。
- 时间窗口：测控弧段、数传窗口、对日定向窗口都是有限时间片，错过即需等待下一圈，属于"不可存储"的资源。
这六类资源中，CPU、内存、存储、总线属于可计量、可监控的资源；功耗与时间窗口则更接近任务级约束，往往在系统级联调时才暴露。
二、四类典型耗尽模式
资源被耗尽的过程通常不是瞬间的，而是有明确的"病理模式"。工程上最常见的有四种：
泄漏（Leak）：最典型的是内存泄漏与句柄泄漏。例如某遥测打包任务每次执行都申请一块 256 字节缓冲区，正常路径释放，但异常分支（如校验失败）直接 return 而未释放。按 1 Hz 调用、每天 86400 次计算，日泄漏约 21 MB，若堆区仅 8 MB，则数小时内即耗尽。泄漏的隐蔽性在于单次量小、短期无感。
碎片（Fragmentation）：即使总空闲内存足够，若被切成大量不连续小块，仍无法满足一次较大申请。例如堆区剩余 4 MB，但最大连续块仅 64 KB，此时申请 128 KB 帧缓冲必然失败。碎片常由"申请-释放-再申请不同尺寸"的混合模式造成，星载软件中图像与遥测共存时尤其明显。
死锁（Deadlock）：两个或多个任务互相持有对方所需的资源并等待。典型场景是任务 A 持有总线控制权等待内存信号量，任务 B 持有内存信号量等待总线。星载软件中若在中断服务程序里调用可能阻塞的信号量操作，死锁概率会显著上升。
优先级反转（Priority Inversion）：低优先级任务持有高优先级任务所需的互斥量，而中优先级任务抢占 CPU，导致高优先级任务被间接延迟。1997 年火星探路者号就因优先级反转反复复位。星载实时系统中，若互斥量未启用优先级继承协议，该问题几乎必然出现。
三、从"资源"到"模式"的对应关系
把资源与模式交叉起来看，能更准确地定位问题。内存最容易被泄漏和碎片侵蚀；CPU 时间最容易被优先级反转和死锁浪费；存储的典型问题是日志区写满后无回收；总线带宽的典型问题是高优先级突发传输挤占周期消息；功耗与时间窗口则更多表现为"任务叠加超预算"而非单一软件缺陷。
以某低轨遥感卫星的数传任务为例：数传开启后，图像压缩任务占用 CPU 从 30% 升至 75%，同时通过 SpaceWire 向固态存储器写入，总线负载从 20% 升至 85%。此时若遥测任务仍按 1 Hz 抢占总线，就会出现遥测帧延迟。这里的根因不是"内存不够"，而是总线带宽与 CPU 时间被数传任务同时挤压。因此排故时必须先分清是哪一类资源先到边界。
四、一个可操作的资源预算示例
下面给出一份星载计算机资源预算表的示例结构，用于在软件设计阶段就把"边界"写清楚。表中数值为教学示例，实际项目需按任务书与硬件手册填写。
| 资源类型 | 总预算 | 正常占用 | 告警阈值 | 耗尽判据 |
|---|---|---|---|---|
| CPU 时间 | 100%（单核） | ≤ 60% | 75% | 任一任务超截止时间 |
| 堆内存 | 8 MB | ≤ 4 MB | 6 MB | 最大连续块 < 128 KB |
| 日志存储 | 512 MB | ≤ 300 MB | 400 MB | 剩余空间 < 50 MB |
| 1553B 总线 | 1 Mbps 时隙 | ≤ 50% | 70% | 周期消息延迟 > 2 周期 |
| 母线功耗 | 120 W | ≤ 80 W | 100 W | 母线电压 < 26 V |
| 测控窗口 | 每圈 8 min | — | — | 窗口内未完成遥测下传 |
五、为什么必须区分"耗尽"与"过载"
工程中常把两者混为一谈。过载是瞬时需求超过能力，例如某控制周期内突然涌入大量中断，CPU 短时 100%，但下一周期即恢复；耗尽则是资源被持续占用且无法回收，例如内存泄漏导致可用堆单调下降。过载可以通过削峰、降频、丢弃非关键任务缓解；耗尽必须找到泄漏点或碎片源，否则任何调度优化都只是延缓崩溃。
区分方法也很直接：观察资源曲线的时间形态。过载呈尖峰状，耗尽呈单调下降或阶梯下降。星载软件应把 CPU 占用率、堆剩余量、最大连续块、日志剩余空间、总线负载、母线电压这几项作为长期遥测下传，地面通过趋势判断是"偶发过载"还是"正在耗尽"。
理解资源分类与耗尽模式，是后续设计健壮性测试用例的基础。只有先明确"哪类资源、以什么模式、在多长时间尺度上被吃掉"，才能有针对性地构造泄漏注入、碎片制造、死锁触发和优先级反转复现等测试场景。