二、安全生命周期：概念阶段、系统阶段、硬件阶段、软件阶段、生产与运维
各位工程师朋友，咱们今天聊聊安全生命周期。说实话，这个概念刚出来的时候，我也觉得有点虚——不就是个流程吗？但干得越久，我越发现，这东西是保命的。
安全生命周期，说白了就是给飞控系统从生到死画一条线。每个阶段该干什么，不该干什么，都写得明明白白。我参与过好几个型号的适航审查，审查员最看重的，就是你有没有按这个生命周期走。
核心观点：安全生命周期不是文档游戏，而是把安全理念嵌入到每个开发环节里。你跳过一个阶段，后面可能要花十倍代价来补。
2.1 概念阶段：把安全需求说清楚
概念阶段做什么？说白了就是回答三个问题：这个飞控系统要干什么？在什么环境下用？万一出事了后果多严重？
我个人习惯，在这个阶段先做 功能危险评估（FHA）。把飞机可能遇到的所有故障场景列出来，比如传感器失效、执行器卡死、通信中断等等。然后给每个场景定一个等级——灾难性的、危险的、重大的、轻微的。
我的经验：概念阶段最容易犯的错，是需求写得太模糊。比如「系统应具有高可靠性」——什么叫高？你得量化。我一般要求写成「系统在连续飞行1000小时内，发生灾难性故障的概率小于10⁻⁹」。
还有一个关键产出物叫 初步安全评估（PSSA）。虽然叫「初步」，但它的结论会直接影响后续所有设计。我记得有个项目，概念阶段没认真做FHA，结果到系统集成测试时才发现某个故障模式没覆盖，最后不得不改架构，那叫一个痛苦。
2.2 系统阶段：搭好安全骨架
系统阶段，就是把概念阶段的安全需求，分配到具体的系统架构里。你想想看，飞控系统通常包含传感器、计算机、伺服机构、通信链路……每个部件承担什么安全角色，得在这个阶段定下来。
我常用的方法是 故障树分析（FTA） 和 失效模式与影响分析（FMEA）。举个例子，如果我们要保证「俯仰通道不会因单点故障而失控」，那故障树就要往下分解：是传感器冗余不够？还是计算机表决逻辑有问题？还是舵机卡死没检测？
| 安全活动 | 目的 | 产出物 |
|---|---|---|
| 系统级FHA | 识别系统级危险 | 危险清单、安全目标 |
| PSSA | 分配安全需求到子系统 | 安全需求规格 |
| FTA | 分析故障传播路径 | 故障树、最小割集 |
| 架构权衡 | 选择冗余/监控方案 | 系统架构文档 |
注意：系统阶段最容易踩的坑，是「过度设计」。我曾经见过一个项目，为了满足安全目标，给每个传感器配了四余度，结果重量和成本都爆了。其实有时候三余度加健康管理就够了。安全不是堆硬件，而是聪明的冗余。
2.3 硬件阶段：把安全做进电路里
硬件阶段，主要针对飞控计算机、传感器接口、伺服驱动这些物理部件。这里要遵循的标准，比如DO-254（机载电子硬件设计保证），要求可不少。
我个人觉得，硬件阶段最核心的是 硬件安全机制。比如看门狗定时器、电压监控、内存ECC、自检电路（BIST）等等。这些机制不是可有可无的，它们是安全需求的物理实现。
举个例子，我在做某型飞控计算机时，要求CPU在每次启动时执行完整的指令集自检。这个自检覆盖了加法、乘法、跳转、中断等所有关键指令。如果自检失败，系统必须进入安全状态——也就是切断输出，让飞机进入备份模式。
// 硬件自检示例（伪代码）
void CPU_SelfTest(void) {
// 1. 算术逻辑单元测试
if (ALU_Test() != PASS) {
Set_SafeState(FAIL_ALU);
return;
}
// 2. 寄存器测试
if (Register_Test() != PASS) {
Set_SafeState(FAIL_REG);
return;
}
// 3. 内存接口测试
if (Memory_Interface_Test() != PASS) {
Set_SafeState(FAIL_MEM);
return;
}
// 全部通过，进入正常运行
Set_OperationalState();
}避坑指南：我曾经遇到过硬件自检覆盖不全的问题。有个看门狗电路，自检时只检查了它能不能复位，却没检查它会不会误复位。结果在飞行中，看门狗因为电源纹波误触发，导致计算机频繁重启。后来我们在自检里加了一条：让看门狗在正常模式下运行100ms，确认没有误触发。
2.4 软件阶段：用代码实现安全逻辑
软件阶段，对应DO-178C标准。飞控软件是典型的 安全关键软件，等级通常是A级（灾难级）或B级（危险级）。这意味着什么？意味着你的代码必须经过严格的验证，覆盖率要达到结构覆盖的MC/DC级别。
我常说，飞控软件工程师要有「强迫症」。每个if-else分支都要想清楚：如果这个条件不成立会怎样？每个循环都要确认：会不会死循环？每个中断都要检查：优先级会不会导致数据竞争？
举个例子，俯仰控制律里有一个限幅函数：
// 俯仰角速率限幅
float Limit_PitchRate(float input) {
const float MAX_RATE = 15.0f; // 度/秒
const float MIN_RATE = -15.0f;
if (input > MAX_RATE) {
return MAX_RATE;
} else if (input < MIN_RATE) {
return MIN_RATE;
} else {
return input;
}
}这段代码看起来简单，但安全审查时会问：如果input是NaN怎么办？如果MAX_RATE被意外改写了怎么办？所以实际工程中，我们还会加输入有效性检查，以及常量保护。
软件安全的关键点：
- 数据流分析：每个变量从哪来，到哪去，有没有未初始化
- 控制流分析：有没有不可达代码，有没有死循环
- 资源管理：堆栈会不会溢出，内存有没有泄漏
- 分区保护：不同安全等级的软件模块要隔离
2.5 生产与运维：安全不是交付就结束
很多人觉得，系统交付了就完事了。其实不是。生产与运维阶段，安全生命周期还在继续。
生产阶段，要关注 制造偏差。比如同一批电阻，实际阻值可能和标称值有5%的误差。如果这个电阻用在安全关键电路里，就要考虑最坏情况分析。我见过一个案例，因为生产批次变更，电容的ESR变了，导致电源滤波效果下降，影响了ADC采样精度。
运维阶段，重点是 持续适航。飞机在天上飞，部件会老化，环境会变化。你需要收集运行数据，分析有没有新的安全隐患。比如某个传感器在高温环境下漂移量变大了，那就要评估是否需要修改维护间隔。
| 阶段 | 安全活动 | 常见问题 |
|---|---|---|
| 生产 | 来料检验、工艺验证、出厂测试 | 元器件批次差异、焊接缺陷 |
| 安装 | 线缆检查、接地测试、功能确认 | 接线错误、屏蔽不良 |
| 运维 | 故障报告、数据分析、改版升级 | 老化失效、环境变化 |
| 退役 | 数据归档、经验总结 | 知识流失 |
特别提醒：运维阶段最容易忽视的是「软件升级」。很多飞控系统交付后，会因为功能增强或bug修复而升级软件。每一次升级，都要重新评估安全影响。我曾经处理过一个案例：升级了通信协议栈，结果导致某个超时参数变了，间接影响了故障检测逻辑。所以，变更管理一定要走安全评估流程。
嗯，安全生命周期就讲到这里。每个阶段都有它的价值，也都有它的坑。我个人最大的体会是：安全不是某个阶段的事，而是贯穿始终的线。你前期偷的懒，后期都会变成债。希望各位在设计飞控系统时，能真正把安全生命周期走扎实。