2. 星务计算机系统架构与状态管理需求

星务计算机（On-Board Computer，OBC）是卫星电子系统的中枢，它并不只是"一台计算机"，而是由处理器、存储器、总线接口、看门狗、供电监控和若干专用接口电路共同构成的嵌入式控制平台。理解状态机与模式管理，必须先看清这台计算机的硬件骨架、软件分层，以及状态管理在整个星务系统中的位置——否则状态机很容易被误解为"软件里的一段判断逻辑"，而忽略它同时受硬件约束、任务需求和故障安全策略的共同支配。

一、典型星务计算机硬件架构

典型星务计算机采用"处理器 + 存储器 + 总线 + 接口 + 监控"五类资源组织。处理器通常选用抗辐射加固的 SPARC、ARM 或 PowerPC 系列，主频在数十至数百 MHz 量级；程序存储器使用 PROM/EEPROM 存放引导与固化程序，数据存储器使用 SRAM 或 MRAM 保存运行变量，大容量 NAND Flash 用于存储遥测、日志和载荷数据。处理器通过内部总线连接看门狗、复位管理、EDAC 纠错和时钟管理单元，再经外部总线（如 CAN、1553B、SpaceWire、RS-422）与星上其他分系统通信。

硬件层最值得关注的是"监控与保护"资源：独立看门狗（WDT）在软件跑飞时强制复位；电源监控电路检测欠压、过流；EDAC 对存储器单粒子翻转进行纠正与上报；复位管理区分上电复位、看门狗复位和指令复位。这些硬件信号直接构成状态机的输入条件，也是模式切换的物理依据。

二、软件分层结构

星务软件通常划分为四层：底层驱动层、操作系统/调度层、功能服务层和应用任务层。底层驱动直接操作寄存器，封装看门狗喂狗、EDAC 查询、总线收发、AD 采集等动作；操作系统层提供任务调度、时间管理、中断处理和消息队列，常见的有实时操作系统或自研调度内核；功能服务层提供遥测组帧、遥控解析、存储管理、时间同步等公共服务；应用任务层则实现姿态控制、模式管理、载荷操作等具体业务。

状态管理位于功能服务层与应用任务层之间，它既不是纯驱动，也不是纯业务。它向下读取硬件与驱动的状态量（复位原因、看门狗计数、EDAC 计数、总线健康度），向上为应用任务提供"当前处于什么模式、允许做什么、禁止做什么"的统一裁决。这种位置决定了状态机必须与调度周期、遥测采集周期和遥控响应时间对齐。

三、状态管理在星务系统中的位置

从系统视角看，星务计算机的状态管理处于"感知—决策—执行"闭环的中心。感知来自硬件监控、分系统遥测和地面指令；决策由状态机根据当前模式、切换条件和优先级完成；执行则体现为模式切换后对分系统使能、参数加载、任务启停的控制。状态管理不是孤立模块，它与故障检测与恢复（FDR）、自主健康管理、任务规划共同构成卫星自主运行能力。

一个常见的误解是把状态管理等同于"模式枚举"。实际上，状态管理至少包含三件事：状态定义（有哪些模式、每个模式的进入/退出条件）、状态迁移（迁移的触发事件、守卫条件和动作）、状态一致性（遥测下传的模式与真实执行模式必须一致）。缺少任何一项，在轨都会出现"地面以为在安全模式、星上实际仍在正常模式"的危险偏差。

四、需求来源与约束

状态管理需求主要来自四个方面：任务需求、故障安全需求、资源约束和地面操作约束。任务需求规定卫星在各飞行阶段应处于什么模式，例如发射段、入轨段、在轨测试段、正常业务段、机动段和离轨段；故障安全需求规定出现单粒子、欠压、通信中断、姿态失稳时如何降级或进入安全模式；资源约束限制状态机可用的 CPU 时间、存储空间和遥测带宽；地面操作约束则要求模式切换可被地面指令干预、可被遥测确认、可被日志追溯。

这些需求最终会转化为可验证的约束条件。例如：安全模式必须在检测到连续 3 次看门狗未喂狗后 500 ms 内进入；模式切换指令从接收到遥测确认不超过 2 个遥测周期；任何模式切换必须记录切换前模式、切换原因和时间戳。下表给出一个简化的需求—约束映射示例，参数为教学假设值。

五、从架构到状态机的设计启示

硬件架构决定了状态机可用的输入信号和输出动作，软件分层决定了状态机应放在哪一层、与谁交互，需求与约束决定了状态机的切换条件和验证指标。设计时建议先画出"硬件状态量—软件状态量—模式"的对应关系，再定义迁移表和守卫条件，最后用遥测和日志验证一致性。这样得到的状态机才不是纸面枚举，而是能在星上真实运行、可观测、可恢复的控制核心。