1. 星务计算机状态机与模式管理导论
星务计算机（On-Board Computer，OBC）是航天器电子系统的核心处理单元，承担遥测采集、遥控指令解析、姿态与轨道控制律计算、任务调度、故障检测与恢复、数据存储与下行等职责。它并不等同于地面通用计算机：星务计算机运行在强辐射、宽温、真空、供电受限且长期无人维护的环境中，一旦在轨失效，往往无法人工干预。因此，星务计算机的设计重点不是"跑得快"，而是"在异常条件下仍能可控地运行"。
从系统角色看，星务计算机位于航天器信息流的中心：向下通过总线（如 MIL-STD-1553B、CAN、SpaceWire、RS-422）连接敏感器、执行机构、电源控制器和载荷；向上通过测控链路与地面站交互。它既是"大脑"，也是"调度员"和"安全员"。这种多重角色决定了它必须有一套明确、可验证、可复现的运行逻辑——这正是状态机与模式管理要解决的问题。
为什么需要状态机与模式管理
如果星务计算机只是一段顺序执行的主循环，那么当某个敏感器数据异常、某条指令超时或某次复位发生后，系统行为将难以预测。状态机把航天器的运行划分为有限个"状态"，每个状态对应一组确定的动作、允许的输入和明确的转移条件。这样，无论发生什么事件，系统都处在某个已知状态中，行为可被推理、测试和验证。
模式管理则是在状态机之上的一层"策略层"。状态描述"当前系统处于什么运行阶段"，模式描述"当前采用哪套控制策略或工作配置"。例如，同一"在轨运行状态"下，可以处于"正常模式""安全模式"或"对地定向模式"，它们共享部分状态，但控制律、功耗分配和通信策略不同。状态机保证逻辑完备，模式管理保证策略灵活。
核心概念与关系
理解本节内容，需要先厘清几个关键对象：
- 状态（State）：系统在某一时刻的稳定运行阶段，如"上电初始化""待机""在轨正常""安全模式""故障恢复"。
- 事件（Event）：触发状态转移的外部或内部信号，如遥控指令、定时器到期、看门狗复位、敏感器超限。
- 转移条件（Guard）：事件发生时是否允许转移的布尔判断，如"电池电压 > 26 V 且 姿态角速度 < 0.5 °/s"。
- 动作（Action）：进入、退出或停留在某状态时执行的操作，如打开加热器、切换控制律、启动数据记录。
- 模式（Mode）：一组参数、控制律和资源配置的集合，可在多个状态间复用。
这些对象之间的关系，可以用一张状态—模式关系图来直观表达。下图以某低轨遥感卫星星务计算机为例，展示从加电到在轨运行的主要状态、关键转移事件，以及模式在状态上的叠加关系。图中参数为教学示例，用于说明逻辑，不代表真实型号指标。
从概念到工程：一个可运行的判断逻辑
状态机不是画在纸上的框图，它最终要落到代码和参数上。以"在轨正常 → 安全模式"的转移为例，工程上通常不会只用一个条件，而是用一组带优先级的判断。下面是一段简化的伪代码，展示星务计算机如何周期性地评估是否进入安全模式。参数为教学示例。
// 周期 1 Hz 执行的安全模式评估（示例参数）
if (battery_voltage < 24.0 V) {
enter_safe_mode(REASON_LOW_POWER);
} else if (sensor_fault_count >= 3) {
enter_safe_mode(REASON_SENSOR_FAULT);
} else if (attitude_rate > 2.0 deg/s && gyro_valid == false) {
enter_safe_mode(REASON_ATTITUDE_LOST);
} else if (watchdog_reset_count >= 2) {
enter_safe_mode(REASON_SOFTWARE_FAULT);
}
// 进入安全模式后：关闭载荷、切换对日定向、降低遥测速率
这段逻辑体现了状态机设计的三个要点：条件明确（每个判断都有可测量的输入）、优先级清晰（低电压优先于敏感器故障）、动作可追溯（记录进入原因，便于地面分析）。模式管理则决定进入安全模式后具体采用哪套控制律和功耗配置，而不是把策略硬编码在状态转移里。
课程目标与学习路径
本课程围绕"如何让星务计算机在轨可控运行"展开，目标是让学习者能够：读懂并绘制星务计算机状态机；设计状态、事件、转移条件和动作；用模式管理组织多套工作策略；实现故障检测、恢复与重构逻辑；并对状态机进行测试与验证。
学习路径按"概念—建模—实现—验证—案例"推进：先建立状态与模式的基本语汇，再学习状态图、状态表和转移矩阵等建模工具；随后进入工程实现，包括周期调度、事件队列、看门狗与复位管理；接着讨论测试方法，如状态覆盖、转移覆盖和故障注入；最后通过典型在轨场景（入轨、成像、安全模式、恢复）串联全部知识。后续章节将逐步展开这些内容，本节只需建立整体框架和共同语言。