3. GNC软件需求分析与架构驱动因素
GNC（制导、导航与控制）实时软件的架构不是凭空设计出来的，它由一组需求“驱动因素”共同塑造。功能需求决定软件必须完成哪些计算与控制动作，非功能需求约束这些动作在什么时间、什么资源、什么精度下完成，安全关键等级决定架构必须提供多强的容错与隔离能力，可重用性影响模块的边界划分与接口抽象，可验证性则反过来约束架构的可观测性与可测试性。理解这五类因素如何“压”在架构上，是做出合理架构决策的前提。
功能需求：决定架构的计算骨架
GNC软件的功能需求通常以“模式—功能—周期”的方式描述。以某近地轨道航天器为例，其核心功能需求可归纳为：
- 导航滤波：以 10 ms 周期接收陀螺、星敏感器、GNSS 数据，输出位置、速度、姿态四元数；
- 制导律计算：以 100 ms 周期根据目标轨道与当前状态计算期望推力方向与大小；
- 控制律计算：以 10 ms 周期根据姿态误差与角速度计算控制力矩指令；
- 执行机构管理：以 10 ms 周期完成力矩分配、喷气脉宽调制与动量轮转速控制；
- 模式管理：根据地面指令与自主判据在安全模式、对地定向、轨道机动等模式间切换。
这些功能需求直接决定了架构中必须存在“周期任务集合”和“模式状态机”两类结构。周期任务集合对应导航、制导、控制、执行机构四条计算链，模式状态机则决定各链在不同模式下的使能、复位与参数切换。架构上通常将每条计算链封装为独立任务或分区，任务间通过共享数据区或消息队列交换状态量，而不是让制导直接调用控制函数——这样模式切换时只需改变任务使能与数据源，不必修改计算逻辑。
非功能需求：决定架构的实时与资源约束
非功能需求中最硬的是实时性。仍以上述航天器为例，控制律从陀螺采样到力矩指令输出的端到端延迟要求不超过 20 ms，导航滤波单次计算不超过 8 ms，制导律不超过 15 ms。这些数字直接约束架构的调度策略：控制任务必须具有最高优先级并可抢占，导航任务次之，制导任务可被前两者抢占。若采用时间分区调度，则需为每个分区分配足够的时间窗口，并保证窗口切换开销不超过周期的 5%。
资源约束同样影响架构。星载处理器通常只有数百 MHz 主频、数十 MB 内存，且不允许动态内存分配。因此架构中数据缓冲区必须在编译期静态确定，任务间通信采用静态分配的环形缓冲或双缓冲，禁止在周期任务中调用 malloc/free。此外，非功能需求还包括功耗、重量、抗辐射等，它们通过限制处理器选型和冗余方式间接影响架构。
安全关键等级：决定架构的容错与隔离强度
安全关键等级通常依据失效后果划分。若 GNC 软件失效可能导致航天器失稳或任务失败，则其安全等级较高，架构必须提供故障检测、隔离与恢复能力。典型做法包括：
- 双机热备或三模冗余：关键计算链在多个处理单元上并行执行，通过表决输出；
- 看门狗与心跳：每个周期任务向监控任务发送心跳，超时则触发安全模式；
- 内存保护：利用 MPU 将各分区隔离，防止一个任务越界写破坏其他任务数据；
- 安全模式入口：一旦检测到不可恢复故障，强制切换至安全模式，仅保留姿态稳定与太阳捕获功能。
安全等级越高，架构中用于容错与隔离的“非功能组件”占比越大，计算链本身反而可能被简化。例如某高安全等级 GNC 软件中，表决与监控代码约占代码总量的 30%，而纯控制律代码不足 20%。
可重用性：决定模块边界与接口抽象
可重用性要求架构将“与具体航天器无关”的算法与“与具体任务相关”的配置分离。例如，姿态控制律中的 PID 参数、滤波系数、力矩分配矩阵应作为配置数据，而不是硬编码在函数中。架构上通常采用“算法库 + 配置表”的方式：算法库提供标准接口，配置表在初始化时加载，运行时只读。这样同一套控制律代码可用于不同型号，只需更换配置表。
可重用性还要求接口稳定。例如导航模块对外只暴露“位置、速度、姿态、时间戳”四个量，内部使用何种滤波算法（EKF、UKF 或互补滤波）对外部不可见。这样更换滤波算法时，制导与控制模块无需修改。
可验证性：决定架构的可观测与可测试性
可验证性要求架构在设计时就考虑“如何证明它满足需求”。这包括：
- 可观测性：关键中间变量（如滤波残差、控制力矩、模式字）必须能被遥测或日志记录，且记录不干扰实时性；
- 可测试性：每个任务应能独立注入测试数据并观察输出，而不必运行整个系统；
- 确定性：相同输入必须产生相同输出，禁止使用随机数或未初始化变量；
- 覆盖率：架构应支持在硬件在环测试中注入故障，验证安全模式切换逻辑。
为满足可验证性，架构中常设置“测试旁路”接口：在非飞行模式下，外部测试设备可通过该接口直接向控制律注入姿态误差，并读取力矩输出，从而在不开全系统的情况下完成单模块验证。
五类驱动因素的相互作用
这五类因素并非独立，而是相互拉扯。提高安全等级会增加冗余与监控，可能挤占实时性预算；提高可重用性要求接口抽象，可能增加一层间接调用而引入延迟；提高可验证性要求记录中间变量，可能增加内存与总线负载。架构设计的本质，就是在这些约束之间找到可接受的平衡点。
上图将五类驱动因素与架构核心的关系集中呈现：功能需求定义计算链，非功能需求约束调度与资源，安全关键等级施加容错与隔离，可重用性塑造模块边界与接口，可验证性要求可观测与测试旁路。同时，图中虚线标出了几组典型冲突——实时性预算与冗余开销、接口抽象与间接调用延迟、安全等级提升与计算链简化、重用性提升与配置复杂度增加。架构师的任务，就是根据具体型号的任务剖面与安全目标，在这些冲突中确定优先级，并据此选择任务划分、调度策略、冗余方式与接口粒度。