1. 课程导入与星务计算平台概览

星务计算平台是卫星电子系统的“中枢大脑”，它承担星上遥测采集、遥控指令分发、任务调度、姿态与轨道数据处理、载荷管理、故障检测与自主恢复等核心职责。与地面通用计算机不同，星务计算平台必须在辐射、真空、大温差和单粒子效应等空间环境下长期可靠运行，因此其硬件、软件和验证方法都带有鲜明的航天工程特征。本课程围绕“集成”与“任务验证”两条主线展开，帮助学习者建立从平台组成到系统联调、从功能验证到在轨任务闭环的完整认知。

一、星务计算平台是什么

从系统视角看，星务计算平台并不是一块单板，而是由若干相互约束的层次构成的有机整体。最底层是星务计算机硬件，通常包括处理器模块（如基于 SPARC 或 ARM 架构的抗辐射处理器）、存储器（程序存储区、数据存储区、EDAC 保护内存）、总线接口（如 MIL-STD-1553B、CAN、SpaceWire）、供电与复位管理、看门狗及遥测采集接口。其上是星务操作系统与板级支持包，负责任务调度、中断管理、时间基准、内存管理和设备驱动。再往上是星务应用软件，包括遥测遥控服务、姿态轨道控制、能源管理、热控管理、载荷任务调度和故障诊断。最外层是与卫星其他分系统的接口，如姿轨控分系统、测控分系统、电源分系统和有效载荷。

在卫星系统中的位置可以用一条信号链来理解：地面测控站发出遥控指令，经测控分系统解调后送入星务计算平台；星务平台解析指令、更新任务状态，再通过星上总线向各分系统分发控制命令；各分系统回传的遥测数据由星务平台汇总、打包，经测控分系统下行至地面。因此，星务计算平台既是“指令入口”，也是“数据出口”，更是星上自主决策的执行核心。

二、集成与任务验证的目标

“集成”在星务计算平台语境下，指的是把硬件模块、操作系统、应用软件和外部接口按照接口控制文件（ICD）组合成一个可运行、可测试的整体。集成的核心目标不是“把线接上、把程序烧进去”，而是确保各层次之间的接口在电气特性、协议格式、时序关系和数据语义上完全匹配。例如，1553B 总线的消息格式、RT 地址分配、子地址映射必须与各分系统 ICD 一致；星务软件发出的遥控指令码、参数范围、执行时序必须与姿轨控分系统的预期输入一致。

“任务验证”则是在集成基础上，验证星务计算平台能否在真实或接近真实的任务场景中正确完成预定功能。它通常包括功能验证、性能验证、接口验证、故障注入验证和任务场景验证。功能验证检查遥测采集、指令分发、模式切换等基本功能是否正确；性能验证关注 CPU 占用率、总线响应时间、任务调度周期等指标是否满足要求；接口验证确认与各分系统的数据交互无误；故障注入验证通过模拟单粒子翻转、看门狗超时、总线通信中断等异常，检验平台的容错与恢复能力；任务场景验证则把上述内容放入完整的卫星飞行程序中，检验平台能否按计划完成在轨任务。

三、主要挑战

星务计算平台的集成与验证面临几类典型挑战。第一是资源受限：星上处理器主频通常只有几十到几百兆赫兹，内存以兆字节计，而任务调度、数据处理和通信管理需要共享这些资源，任何一处设计不当都可能造成任务超时。第二是实时性约束：姿轨控闭环、遥控指令响应等任务有明确的截止时间，验证时必须测量最坏情况下的响应时间，而不能只看平均值。第三是空间环境效应：单粒子翻转可能改变内存数据或寄存器状态，总剂量效应可能导致器件参数漂移，验证时需要结合故障注入和冗余设计进行考核。第四是接口复杂性：一颗卫星的星务平台往往要同时与多个分系统交互，接口数量多、协议各异，集成过程中容易出现地址冲突、时序竞争和数据格式不一致等问题。第五是验证覆盖度：在轨故障难以完全复现，地面验证必须通过场景设计、故障注入和边界条件测试尽可能覆盖真实工况。

四、课程路线图

本课程共 30 章，整体按照“认知—设计—集成—验证—任务闭环”的逻辑推进。前几章建立星务计算平台的基本概念、组成结构和接口体系；随后进入硬件选型、操作系统移植、应用软件架构设计等实现环节；中段重点讲解集成方法，包括总线联调、接口匹配、时序分析和故障排查；后段聚焦任务验证，涵盖测试用例设计、故障注入、半物理仿真和任务场景演练；最后以综合案例收束，展示从平台集成到任务验证的完整过程。学习过程中，建议始终抓住“接口—时序—数据—状态”四条线索，把每一章的知识点放回卫星任务闭环中去理解。