2. 星载计算平台与任务剖面
要理解星载计算机的故障容错验证，必须先回答一个前置问题：我们验证的对象究竟运行在什么样的平台上、经历什么样的任务剖面、承受什么样的环境应力。容错需求不是凭空设定的指标，而是从"平台架构—任务模式—空间环境"三者的交汇处推导出来的。本节围绕这条推导链展开，为后续的故障注入、容错机制验证与综合评估建立对象认知。
一、典型星载计算机架构
星载计算机（On-Board Computer, OBC）在功能上通常划分为若干相对独立的层次，各层承担不同的容错职责。以一台典型的平台管理计算机为例，其架构可概括为：
- 敏感器与执行机构接口层：通过1553B总线、CAN总线或SpaceWire连接陀螺、星敏感器、动量轮、推力器等，负责数据采集与指令下发。该层易受单粒子瞬态影响，接口协议芯片常配置看门狗与超时重传。
- 处理核心层：由一颗或多颗处理器构成。高可靠型号常采用双机热备、三模冗余（TMR）或锁步（Lockstep）结构。处理器内部对寄存器、Cache、总线接口分别设置EDAC、奇偶校验或复制比较。
- 存储层：包括程序存储器（PROM/Flash）、数据存储器（SRAM/DRAM）和大容量存储。程序区通常采用三份存储加表决读取，数据区采用EDAC或刷洗（Scrubbing）机制抑制累积翻转。
- 供电与复位管理层：提供多路电源监控、上电复位、看门狗复位和自主复位逻辑，是故障后恢复的最后一道硬件防线。
- 总线与通信层：连接各分系统，承担遥控遥测、星务数据分发，常配置总线控制器冗余与终端故障隔离。
这些层次并非简单堆叠，而是形成"检测—隔离—恢复"的纵深关系。下图给出该架构的层次与容错职责对应关系。
二、在轨任务模式与工作剖面
星载计算机并非始终处于同一工作状态。以遥感卫星为例，一个轨道周期内通常经历以下模式：
- 发射入轨段：计算机执行分离检测、太阳翼展开、姿态捕获，时序密集、实时性要求高，此时若发生复位可能导致任务失败。
- 对日定向/安全模式：姿态稳定后进入低功耗巡航，计算负载低，是进行存储器刷洗和健康检查的窗口。
- 成像/载荷工作段：载荷开机、数据高速写入大容量存储，处理器与存储访问压力最大，单粒子翻转概率随负载上升。
- 数传段：向地面站回传数据，通信链路满负荷，总线与接口层故障影响显著。
- 轨道阴影期：进入地影，温度骤降，供电切换至蓄电池，电源与热环境应力突出。
不同模式下，计算机的负载、温度、供电状态和辐射环境各不相同，容错机制的触发概率与后果也不同。验证时必须按任务剖面分段设计激励，而不是用单一工况覆盖全任务。
三、空间环境约束
空间环境是容错需求的根本来源，主要包含四类应力：
| 环境因素 | 典型效应 | 对计算机的影响 |
|---|---|---|
| 高能质子/重离子 | 单粒子翻转（SEU）、单粒子锁定（SEL） | 存储位翻转、逻辑错误、器件锁定甚至烧毁 |
| 总剂量（TID） | 阈值电压漂移、漏电流增大 | 器件参数退化、时序余量减小、寿命末期失效 |
| 温度循环 | 热应力、焊点疲劳 | 连接失效、接触电阻变化 |
| 真空与辐照 | 材料放气、介质充电 | 绝缘性能下降、静电放电风险 |
其中SEU是最频繁、最需要在验证中反复模拟的故障源。以低地球轨道（LEO）为例，典型SRAM器件的SEU率约为10⁻⁷～10⁻⁶次/位/天量级，一颗含数兆比特存储的计算机每天可能经历数次至数十次翻转。这一数量级决定了：容错验证不能只做单次故障注入，而必须考虑故障的累积与并发。
四、容错需求的来源与推导
综合以上三方面，容错需求可归纳为四条来源：
- 任务成功性要求：关键任务段（如入轨、成像）不允许因单点故障导致任务中断，由此导出冗余与快速恢复指标。
- 环境应力水平：由轨道高度、倾角、太阳活动期决定辐射通量，进而决定EDAC强度、刷洗周期和屏蔽设计。
- 平台资源约束：质量、功耗、体积限制冗余度，需要在可靠性与资源之间折中。
- 可恢复性要求：故障后需在限定时间内恢复至安全模式，导出看门狗超时、复位策略和重构时间指标。
五、对验证工作的直接启示
从上述分析可以提炼出对后续验证工作的三点要求。第一，验证对象必须覆盖架构中的每一层，不能只测处理器而忽略接口与供电层。第二，激励设计必须按任务模式分段，成像段与安全模式的故障注入策略应不同。第三，故障模型必须包含累积效应，例如连续多次SEU导致EDAC纠错能力饱和后的行为。只有把平台架构、任务剖面与环境约束三者结合，容错验证才具备工程意义，而不是停留在单点功能的孤立测试。