1. GNC实时软件架构概述

GNC（Guidance, Navigation and Control，制导、导航与控制）是航天器实现“知道自己在哪里、要去哪里、如何稳定到达”的核心功能链。GNC实时软件则是承载这条功能链的计算中枢，它运行在星载计算机上，周期性采集敏感器数据、估计姿态与轨道状态、计算控制指令并驱动执行机构，同时还要在故障发生时完成重构与安全处置。理解GNC实时软件架构，首先要理解它所处的系统组成、实时性的真实含义，以及航天器任务对软件结构施加的硬约束。

一、GNC系统的组成

从信息流角度看，GNC系统由四类要素构成：敏感器、执行机构、星载计算机与软件、以及被控对象（航天器本体及其动力学环境）。敏感器负责“感知”，典型包括星敏感器、太阳敏感器、陀螺、磁强计、GNSS接收机、加速度计等；执行机构负责“作用”，典型包括动量轮、控制力矩陀螺、磁力矩器、推力器、帆板驱动机构等；星载计算机与软件负责“决策”，完成数据采集、状态估计、控制律计算、模式管理与故障处理；被控对象则是航天器姿态与轨道动力学本身。

这些要素并非简单串联，而是通过总线与接口形成闭环。例如星敏感器通过RS-422或SpaceWire输出姿态四元数，陀螺通过1553B总线输出角速度，计算机在同一个控制周期内融合两类数据，经卡尔曼滤波得到姿态估计，再计算控制力矩，分配给动量轮与磁力矩器。软件架构必须清晰描述这条闭环中每个环节的时序、数据格式、优先级与失效行为。

二、实时软件的定义与真实含义

“实时”并不等于“快”，而是指系统必须在确定的时间约束内给出正确结果。对GNC软件而言，实时性包含三个层次：第一是周期确定性，控制周期必须稳定，例如姿态控制周期固定为100 ms，抖动应控制在毫秒级；第二是截止时间约束，从敏感器采样到执行机构指令输出必须在周期内完成，超时即视为失效；第三是优先级可预测，故障处理与安全模式切换必须能抢占常规控制任务。

因此，GNC实时软件通常采用时间触发与优先级抢占相结合的调度结构。以100 ms控制周期为例，可将周期划分为若干时间片：0~20 ms完成敏感器采集与校验，20~50 ms完成导航滤波，50~80 ms完成控制律与力矩分配，80~100 ms完成指令输出与健康监测。每个时间片有明确的执行预算，超出预算即触发超时计数，连续超时则进入降级模式。这种“预算—执行—监测”的结构，是实时软件架构区别于普通应用软件的关键。

三、架构关注点

GNC实时软件架构需要同时回答“功能如何分解”和“非功能约束如何满足”两类问题。功能维度上，通常划分为采集、导航、制导、控制、模式管理、健康监测与遥测等模块；非功能维度上，则关注以下要点：

• 时间确定性：任务周期、执行时间、抖动与截止时间必须可分析、可测量，避免无界阻塞与动态内存分配。
• 容错与重构：敏感器或执行机构失效时，软件应能隔离故障、切换备份、重构控制分配，并保证切换过程姿态不发散。
• 模式管理：典型模式包括待机、安全、对日定向、对地定向、机动、故障保护等，模式切换条件与切换过程必须显式定义。
• 接口与数据一致性：总线协议、数据格式、时标、单位与坐标系必须统一，避免因参照系不一致导致控制方向错误。
• 可验证性：架构应支持单元测试、时序分析、硬件在环测试与在轨可观测性设计。

四、典型航天器任务对软件架构的约束

不同任务对GNC软件架构的约束差异显著。以三类典型任务为例：

这些约束最终都会落到软件架构的具体决策上：任务如何划分、周期如何设定、优先级如何分配、故障如何传播与阻断、模式如何切换。架构设计不是一次性完成的，而是随着任务剖面、硬件资源与验证结果不断迭代。理解这些约束，是后续学习具体调度策略、容错机制与代码实现的基础。