1. 课程导入与星载软件故障全景

星载软件与地面软件最大的差别，不在于代码规模，而在于它运行在一个"修不了、换不掉、辐射不停"的环境里。卫星一旦入轨，软件缺陷无法像手机App那样热修复，单粒子翻转可能在任意时刻改写寄存器或存储器内容，而软件又必须持续承担姿态控制、遥测采集、任务调度等关键职责。因此，星载软件的可靠性保障不能只依赖"写对代码"，还必须回答两个问题：故障从哪里来、会怎样扩散、最终造成什么后果。本课程围绕"故障注入"与"传播分析"两条主线，建立一套可操作的分析方法。

学习目标

完成本课程后，读者应能达成以下目标：理解星载软件故障的来源分类与典型表现；掌握故障注入的基本原理、注入层次与常用手段；能够针对给定模块设计一次可复现的注入实验，包括注入点选择、注入时机、观测变量与判据；能够基于注入结果分析故障在数据流、控制流和状态机中的传播路径；能够根据传播分析结论提出加固或容错改进建议。这些目标贯穿后续章节，本章先建立整体认知框架。

星载软件的特殊性

星载软件的特殊性可以从四个维度理解。第一是环境特殊性：空间辐射导致单粒子效应（SEE），包括单粒子翻转（SEU）、单粒子锁定（SEL）、单粒子瞬态（SET）等，其中SEU最常表现为存储位翻转，是故障注入最需要模拟的对象之一。第二是资源特殊性：星载处理器主频通常较低，内存以MB计，且多采用抗辐射加固器件，算力和存储都远不如地面服务器，这限制了容错机制的复杂度。第三是可维护性特殊性：在轨软件更新窗口有限、带宽有限，无法频繁打补丁，因此设计阶段就必须把故障处理逻辑固化进去。第四是任务特殊性：星载软件往往承担实时控制任务，故障若未被及时抑制，可能从数据异常演变为控制失稳，甚至导致整星失效。

故障注入与传播分析的定义

故障注入是指在受控条件下，人为地向系统引入故障，以观察系统响应、评估容错能力的过程。它回答的是"如果这里坏了，系统会怎样"。传播分析则是追踪故障从注入点出发，经过数据流、控制流、状态迁移后，如何影响输出或任务结果的过程。它回答的是"故障为什么会导致这个后果、中间经过了哪些环节"。两者结合，形成"注入—观测—追踪—评估—改进"的闭环。

需要区分三个易混概念：故障（fault）是缺陷的潜在状态，如某个存储位翻转；错误（error）是故障导致的不正确内部状态，如变量值异常；失效（failure）是错误传播到系统边界后导致的功能偏离，如姿态控制输出错误。注入实验通常从故障入手，观测错误，最终判定是否失效。

整体知识框架

本课程的知识框架可概括为"三层两线"。"三层"指注入层、传播层、评估层：注入层解决"在哪里、何时、以什么模型注入"；传播层解决"故障沿什么路径扩散、在哪些节点被屏蔽或放大"；评估层解决"用什么指标衡量危害、如何给出改进建议"。"两线"指数据流线与控制流线，二者往往交织，是传播分析的核心对象。

工程价值

故障注入与传播分析的工程价值体现在三个层面。在设计验证阶段，它能在硬件投产前暴露容错逻辑的薄弱点，例如看门狗是否真的能在规定周期内复位、三模冗余表决器是否会被共因故障击穿。在在轨运维阶段，传播分析结论可用于制定遥测判读阈值和故障预案，当某遥测参数出现特定偏差时，能快速定位可能的故障源。在标准符合性方面，许多航天型号要求提供故障模式与影响分析（FMEA）及容错验证报告，注入实验数据是重要支撑材料。

以一个简化的姿态控制软件为例：若在陀螺数据处理模块注入一个位翻转，使角速度读数偏移0.5°/s，传播分析需要追踪该偏差是否被滤波环节抑制、是否进入姿态解算、是否导致控制力矩输出异常。若系统在解算前设有合理性校验（如角速度超过阈值即判无效），则故障在此被屏蔽，不会形成失效；若校验缺失，偏差将进入控制律，可能引起姿态振荡。这一判断过程正是后续章节要反复训练的核心能力。