3. 星载计算机高可靠架构设计需求分析
星载计算机的高可靠架构不是从元器件选型开始的，而是从需求分析开始的。需求分析的核心任务，是把任务书、用户需求、总体约束和标准规范中分散、定性甚至模糊的表述，转化为可量化、可验证、可分解到架构层的设计输入。本节围绕任务剖面、寿命要求、可靠性指标、安全性等级与设计约束五个维度，说明如何系统提取这些输入，并给出可操作的提取方法。
一、任务剖面：把“飞多久、干什么”拆成可量化的阶段
任务剖面描述航天器从发射到寿命终止所经历的全部事件与阶段。对星载计算机而言，任务剖面决定了它在每个阶段的工作模式、负载强度、环境应力和可用性要求。提取时不能只写“在轨运行若干年”，而应拆成可量化的阶段序列。
以某低轨遥感卫星为例，其任务剖面可拆为：发射段（约30分钟，振动、冲击、加速度）、入轨与初始稳定段（约2小时，频繁姿态机动、计算负载高）、在轨成像任务段（每天约20个成像弧段，每弧段8～12分钟，计算与存储负载峰值）、数传与对地通信段（每天约6次，每次10分钟）、轨道维持与安全模式段（不定期，低负载）、寿命末期离轨段（约数天，单机降级运行）。每个阶段应标注持续时间、工作模式、关键负载、环境应力和可用性要求。
任务剖面的输出应形成一张“阶段—模式—负载—环境—可用性”对应表，作为后续可靠性建模和架构分区的输入。例如，成像任务段要求计算机在轨可用性不低于0.999，而安全模式段允许降级运行但必须保持遥测与指令响应。
二、寿命要求：区分设计寿命、工作寿命与存储寿命
寿命要求常被笼统写成“在轨寿命8年”，但架构设计需要区分三类寿命：设计寿命（含地面存储、发射、在轨全过程）、工作寿命（加电工作累计时间）、存储寿命（不加电存放时间）。三者对元器件选择、冗余策略和寿命试验的要求不同。
提取方法：从任务书获取总任务时长，扣除地面测试与发射段时间，得到在轨工作寿命；再根据任务剖面中各阶段加电时间，估算累计加电小时数。例如，8年在轨寿命中，若每天平均加电18小时，则累计加电约52560小时。该数值直接决定器件寿命等级、电解电容选型、闪存擦写次数预算和冗余切换次数上限。
同时要提取寿命末期的性能降级要求。例如，寿命末期CPU主频允许下降不超过10%，存储可用容量不低于初始值的70%，电源输出功率不低于额定值的85%。这些降级边界是架构容错设计的重要约束。
三、可靠性指标：从MTBF到任务可靠度
可靠性指标不能只写“高可靠”，应提取为可计算、可验证的量化指标。常用指标包括：平均故障间隔时间（MTBF）、任务可靠度、单点故障率、冗余切换成功率、故障检测覆盖率与故障恢复时间。
提取时先明确指标口径：MTBF是基本可靠性还是任务可靠性？是否包含地面段？是否按加电小时还是日历小时统计？例如，某星载计算机要求任务可靠度在8年任务期内不低于0.95，单点故障率低于1×10⁻⁶/小时，故障检测覆盖率不低于99%，故障恢复时间不超过200毫秒。
这些指标需要向下分解到架构层。例如，任务可靠度0.95可分解为：双机热备架构下，单机MTBF不低于2×10⁵小时，切换成功率不低于0.999，共因故障概率低于0.01。分解结果直接决定冗余粒度、表决方式和故障检测机制。
四、安全性等级：从失效后果反推独立性要求
安全性等级不是可靠性指标的简单补充，而是从失效后果出发，确定哪些功能必须独立、哪些故障必须被隔离。提取方法是先识别危险源，再评估失效后果的严重程度，最后确定安全关键功能及其独立性要求。
例如，某星载计算机承担姿态控制、载荷管理和遥测遥控三类功能。若姿态控制失效可能导致卫星失控，属于灾难性后果，则姿态控制功能应分配最高安全性等级，要求采用独立双机或三模冗余，且故障隔离不得影响遥测遥控通道。若载荷管理失效仅导致任务数据丢失，属于轻微后果，可采用单机加降级策略。
安全性等级的输出应包括：安全关键功能清单、每个功能的危险等级、失效容限（允许失效次数）、独立性要求（供电独立、时钟独立、总线独立、软件分区独立）以及安全模式触发条件。这些内容直接决定架构分区和隔离设计。
五、设计约束：把边界条件变成架构决策依据
设计约束是需求分析中最容易被忽视、却对架构影响最直接的部分。提取时应逐项量化，并标注来源和优先级。常见约束包括：功耗预算（如整机不超过15W）、质量预算（如不超过3kg）、体积限制（如1U或2U板卡尺寸）、接口类型与速率（如SpaceWire、CAN、1553B）、热耗散与工作温度范围、辐射总剂量与单粒子指标、成本与进度限制。
以功耗约束为例，若整机功耗预算为15W，双机热备架构下每机功耗不得超过7.5W，且需预留20%余量，则单机实际设计功耗应控制在6W以内。这一约束会直接影响CPU选型、存储介质选择和接口速率。再如辐射约束，若总剂量要求为100krad(Si)，则需选择抗辐射加固器件或增加屏蔽，这会反过来影响质量和体积预算。
六、提取结果的组织与验证
五维需求提取完成后，应形成一份“需求—指标—架构约束”追踪矩阵。矩阵的每一行对应一条需求，列出其来源、量化指标、验证方法和对应的架构决策。例如：任务剖面中的成像任务段要求可用性0.999，对应架构决策为双机热备加故障检测覆盖率99%，验证方法为故障注入试验和可靠性预计。
验证时重点检查三项一致性：任务剖面中的最坏工况是否被可靠性指标覆盖；安全性等级中的独立性要求是否与冗余架构匹配；设计约束中的功耗、质量、辐射是否与器件选型一致。若发现冲突，应回到需求源头协商，而不是在架构层强行折中。
需求分析的质量决定了后续架构设计的上限。把任务剖面、寿命、可靠性、安全性和约束五类输入提取清楚，星载计算机的高可靠架构才有可验证的起点，而不是停留在“多备份、选好器件”的经验层面。