3. 星务计算机的软件架构
星务计算机的软件并不是“把地面程序搬到天上”那么简单。它要在辐射、单粒子翻转、通信时延大、能源受限、且长期无人维护的条件下，稳定完成遥测采集、遥控执行、姿态与轨道相关计算、载荷管理以及星地通信。因此，星务软件通常采用分层架构，把与硬件强耦合的部分、实时调度部分、业务功能部分和系统保障部分分开，使各层职责清晰、接口稳定、便于验证与复用。
一、分层模型：从硬件到应用的纵向切分
典型星务软件自下而上可分为四层。最底层是硬件抽象层（HAL）/板级支持包（BSP），它封装CPU、存储器、看门狗、总线控制器（如CAN、1553B、SpaceWire）和各类接口寄存器，向上提供统一的读写、中断注册和定时器接口。第二层是实时操作系统层（RTOS），负责任务调度、时间管理、任务间通信、内存管理和中断管理。第三层是中间件与服务层，包括遥测遥控服务、时间服务、文件/存储服务、总线通信服务和健康管理服务。最上层是应用层，即具体的星务功能：遥测采集、遥控指令分发、自主健康管理、载荷数据管理等。
分层的价值在于：更换CPU或总线芯片时，只需重写HAL/BSP；更换调度策略时，只影响RTOS配置；新增业务功能时，只扩展应用层。层与层之间通过明确定义的接口调用，禁止跨层直接访问硬件寄存器，这是星务软件可测试性和可维护性的基础。
二、实时操作系统：确定性优先
星务计算机对RTOS的核心要求不是“快”，而是确定性——最坏情况下的响应时间可预测。常用指标包括中断延迟、任务切换时间和调度抖动。以某星务计算机为例，若采用主频100MHz的SPARC处理器，中断延迟通常要求在10μs以内，任务切换时间在5μs以内，周期任务抖动不超过±50μs。这些参数需要在设计阶段通过静态分析和实测共同确认。
星务RTOS通常提供以下机制：基于优先级的抢占式调度、时间片轮转（同优先级）、信号量、消息队列、事件标志组、软件定时器和内存分区管理。其中内存分区尤为重要：每个任务只能访问自己的分区，防止一个任务越界破坏其他任务的数据，这对单粒子翻转环境下的故障隔离非常关键。
三、任务调度框架：周期任务与事件任务并存
星务软件的任务可分为两类：周期任务（如遥测采集、姿态控制周期计算）和事件任务（如遥控指令到达、故障告警触发）。周期任务用时间触发调度，事件任务用优先级抢占调度。一个常见的调度框架是“时间片+优先级”混合模型：将1秒划分为若干时间片，每个时间片内按优先级执行就绪任务，高优先级事件任务可抢占低优先级周期任务。
下面给出一个简化的任务配置示例，用于说明周期、优先级和栈空间的分配关系。参数为教学示例，实际值需根据处理器和任务负载调整。
任务名 周期(ms) 优先级 栈空间(B) 功能
TM_Acq 100 5 2048 遥测采集
TC_Dispatch 事件触发 3 4096 遥控指令分发
AOCS_Ctrl 50 4 8192 姿控周期计算
HK_Monitor 500 6 2048 健康监测
Bus_Service 事件触发 2 4096 总线通信服务
调度器在每个时间片开始时检查就绪队列，选择优先级最高的任务运行。若高优先级任务在运行中被更高优先级事件唤醒，则立即抢占。周期任务若未在截止时间内完成，健康管理模块应记录“超时”并触发降级或复位策略。
四、中间件：让应用与硬件解耦
中间件位于RTOS与应用之间，提供与具体硬件无关的服务接口。星务中间件通常包括：遥测遥控中间件（统一打包/解包、校验、路由）、时间中间件（星上时间同步、时间戳服务）、存储中间件（文件系统、日志、断点续传）、总线中间件（CAN/1553B/SpaceWire统一收发接口）和健康管理中间件（故障检测、隔离、恢复）。
中间件的接口应保持稳定，例如遥控中间件向上提供“注册指令处理函数”和“发送遥测包”两个核心接口，应用层不需要知道底层是1553B还是CAN。这样，当卫星平台更换总线时，应用层代码几乎不需要修改。
五、健康管理：从监测到恢复的闭环
健康管理（Fault Detection, Isolation and Recovery, FDIR）是星务软件可靠性的最后一道防线。它通常分为三层：组件级（看门狗、EDAC、CRC校验）、任务级（任务超时、栈溢出检测、心跳计数）和系统级（模式切换、安全模式进入、整机复位）。
一个典型的健康管理闭环是：监测→判断→隔离→恢复→记录。例如，若HK_Monitor任务连续3次未在500ms内完成，系统判定该任务异常，将其挂起并记录故障码，同时尝试重启该任务；若重启失败，则切换到安全模式，关闭非关键载荷，仅保留遥测和遥控通道。所有故障事件写入非易失存储，供地面分析。
从工程实践看，分层模型解决“结构清晰”的问题，RTOS解决“时间确定”的问题，任务调度框架解决“谁先运行”的问题，中间件解决“硬件解耦”的问题，健康管理解决“出错后怎么办”的问题。五者不是孤立模块，而是相互支撑的整体：调度框架依赖RTOS的优先级机制，健康管理依赖中间件提供的监测接口，而中间件又运行在RTOS之上。设计时应先明确各层接口和任务时序，再逐层实现和验证，避免把业务逻辑直接写进中断服务程序或HAL中。