第三章：飞控计算机（FCC）软件架构
分区操作系统：VxWorks 653 的硬核世界
说到飞控计算机的软件架构，我第一个想到的就是分区操作系统。说白了，这就是一个「大管家」，负责管理多个应用程序，确保它们互不干扰。
我个人习惯把 VxWorks 653 比作一栋公寓楼。每个应用程序就像一户人家，有自己的房间（分区），有自己的水电表（资源），还有自己的作息时间（时间片）。你想想看，如果楼上楼下可以随便串门，那还得了？
在波音787的项目中，我遇到过一个问题：两个分区同时访问同一个内存地址。嗯，这在普通电脑上可能只是蓝屏，但在飞机上，那就是灾难。VxWorks 653 的核心价值就在这里——它用硬件和软件的双重隔离，确保这种事情永远不会发生。
ARINC 653 分区调度：时间与空间的精确切割
ARINC 653 标准定义了两种分区：空间分区和时间分区。空间分区确保每个应用有自己的内存空间，时间分区则确保每个应用获得固定的 CPU 时间。
我曾经在空客 A350 的架构评审会上，看到过一张调度表，密密麻麻的，像极了地铁时刻表。每个分区在什么时间运行、运行多久，都是精确到微秒的。
这里有个典型的调度配置示例：
// 分区调度表示例
PARTITION_SCHEDULE {
PARTITION_ID = 1, // 飞行控制分区
PERIOD = 100, // 周期 100ms
DURATION = 40, // 运行 40ms
OFFSET = 0 // 起始偏移 0ms
}
PARTITION_SCHEDULE {
PARTITION_ID = 2, // 导航分区
PERIOD = 100,
DURATION = 30,
OFFSET = 40 // 在分区1之后运行
}
PARTITION_SCHEDULE {
PARTITION_ID = 3, // 显示分区
PERIOD = 100,
DURATION = 20,
OFFSET = 70
}你可能会问：为什么不能把所有时间都给飞控分区？因为还有其他系统需要运行啊！导航、显示、通信，每个系统都有自己的任务。而且，这种固定调度还有一个好处：可预测性。我知道飞控分区每 100ms 一定能运行 40ms，这就够了。
健康监控（HM）：系统的「体检医生」
健康监控，说白了就是给飞控计算机做体检。它监控 CPU 使用率、内存占用、任务执行时间、通信链路状态等。一旦发现异常，立即上报。
我记得在波音787的测试中，有一个分区偶尔会超时运行。健康监控模块检测到后，直接触发了分区重启。虽然当时看起来是「故障」，但实际上是系统在保护自己。
健康监控的典型架构包括：
- 本地监控： 每个分区内部的自检
- 全局监控： 操作系统层面的系统级监控
- 交叉监控： 多台计算机之间的相互检查
这里有一个我参与设计的健康监控状态机：
// 健康监控状态机
enum HM_State {
HM_NORMAL, // 正常
HM_WARNING, // 警告（可恢复）
HM_ERROR, // 错误（需切换）
HM_FAILURE // 故障（需重启）
};
void HM_Monitor() {
if (cpu_usage > 90%) {
state = HM_WARNING;
log_event("CPU 使用率过高");
}
if (task_deadline_missed > 3) {
state = HM_ERROR;
trigger_partition_switch();
}
}故障管理：从检测到恢复的完整闭环
故障管理是健康监控的「升级版」。它不仅检测问题，还要处理问题。故障管理的核心流程是：检测 → 隔离 → 恢复 → 记录。
在空客 A350 的飞控计算机中，故障管理分为三个层级：
| 层级 | 故障类型 | 处理方式 |
|---|---|---|
| L1 | 瞬时故障 | 自动重试，无需切换 |
| L2 | 持续故障 | 分区切换或通道切换 |
| L3 | 严重故障 | 整机重启或降级运行 |
我曾经在项目中遇到过一个棘手的故障：两个飞控计算机同时报告对方故障。这就是所谓的「拜占庭故障」。最后我们通过引入第三个投票节点，才解决了这个问题。
故障管理的核心原则是：不要相信任何单一数据源。所有故障判断都需要交叉验证。
知识体系总览
下面这张图展示了本章的核心逻辑关系：
这张图清晰地展示了从底层操作系统到上层应用监控的完整链路。VxWorks 653 提供基础隔离，ARINC 653 定义调度规则，健康监控和故障管理则确保系统在异常情况下依然可靠。
嗯，说到最后，我想强调一点：飞控计算机的软件架构，核心就三个词——隔离、监控、容错。把这三点做好了，系统就稳了。