1. 飞行控制软件概述：定义、特点、典型架构及安全关键性等级

各位同学，咱们今天聊聊飞行控制软件。说实话，这个领域我干了快二十年，每次带新人时，第一课我都要讲清楚一个概念——飞控软件不是普通的嵌入式软件。它要是出了岔子，可不是重启一下就能解决的。

1.1 什么是飞行控制软件？

飞行控制软件，说白了就是飞机的「大脑」和「神经系统」。它负责接收飞行员的操作指令，结合传感器采集的飞行状态数据，计算出控制指令，然后驱动执行机构（比如舵面、发动机）让飞机按照期望的轨迹飞行。

我个人习惯把飞控软件比作一个「三环反馈系统」：

• 内环：姿态稳定控制（俯仰、滚转、偏航）
• 中环：轨迹跟踪控制（高度、航向、速度）
• 外环：任务管理与导航（航线规划、自动着陆）

你想想看，这三个环任何一个出问题，后果都不堪设想。我在项目中遇到过一起案例，内环的角速率反馈延迟了50毫秒，结果飞机在试飞时出现了持续振荡——嗯，那次之后我们花了整整三个月重构了调度架构。

1.2 飞控软件的核心特点

飞控软件和普通嵌入式软件有什么不同？我总结了四点，你记一下：

1. 硬实时性：控制周期通常是毫秒级的。比如典型的飞控周期是10ms或20ms，你必须在规定时间内完成采样、计算、输出。超时就是故障。
2. 高可靠性：飞行中不允许出现「蓝屏」或「死机」。我记得有一次评审会上，一个年轻工程师说「概率很低」，我当时就反问了一句——「你愿意坐在这架飞机上吗？」
3. 确定性行为：同样的输入，必须产生同样的输出。不能有随机延迟、不能有动态内存分配（malloc/free在飞控里是禁区）。
4. 容错与余度：单个传感器坏了，系统不能瘫痪。飞控计算机通常采用三余度或双余度架构，投票表决。

1.3 典型架构：飞控计算机、传感器、执行机构

咱们拆开来看。一个典型的飞控系统由三大部分组成：

1.3.1 传感器子系统

传感器就是飞机的「眼睛」和「耳朵」。常见的包括：

• IMU（惯性测量单元）：测量三轴角速率和加速度
• GPS/北斗：提供位置和速度信息
• 大气数据系统：空速、高度、攻角
• 磁力计：提供航向参考

这里有个避坑指南——我曾经在一个项目中，IMU和GPS的数据采样率不一致，导致卡尔曼滤波器发散。后来我们强制要求所有传感器数据必须打上时间戳，并在软件层面做同步处理。

1.3.2 飞控计算机

飞控计算机是核心处理单元。它运行着飞控软件，完成数据融合、控制律计算、故障检测等任务。典型的架构有：

• 单余度：简单无人机用，但民航不用
• 双余度：主备切换，常见于中小型无人机
• 三余度：三机投票，2:1表决，民航客机标配

我个人习惯在设计飞控计算机时，把关键任务（如控制律计算）放在独立的CPU核心上，避免被其他任务干扰。你想想看，如果导航任务占用了太多CPU时间，控制律的周期抖动就会增大——这在飞行中是致命的。

1.3.3 执行机构

执行机构是飞机的「手脚」。包括：

• 舵机/伺服阀：控制副翼、升降舵、方向舵
• 油门执行器：控制发动机推力
• 起落架收放机构：虽然不参与飞行控制，但也是安全关键

执行机构有一个常见问题——死区。舵机在零位附近可能有一段不响应区域。我记得在调试某型无人机时，就是因为舵机死区没补偿，导致飞机在平飞时出现小幅振荡。后来我们在软件里加了死区补偿算法，问题才解决。

1.4 安全关键性等级：DAL A/B/C/D

说到安全等级，这是航空软件认证的核心概念。DO-178C标准把软件的安全关键性分为四个等级：

DAL等级	故障后果	典型功能	我的经验
DAL A	灾难性（坠机）	主飞控、自动驾驶	需要全流程形式化验证
DAL B	危险/严重	导航、告警系统	MC/DC覆盖率必须100%
DAL C	重大	飞行管理、数据链	分支覆盖率达标即可
DAL D	轻微	日志记录、非关键显示	基本测试通过就行

为什么会这样？因为DAL A的故障会导致飞机失控。你想想看，一架载着300人的客机，飞控软件出了bug——这不是闹着玩的。所以DO-178C对DAL A的要求极其严格，包括：

• 100%的MC/DC覆盖率
• 结构覆盖率分析
• 形式化方法验证
• 独立评审团队

而DAL D就宽松多了。比如客舱娱乐系统，就算死机了，飞机照样能飞。所以它的验证要求很低，基本的功能测试就够了。

1.5 小结

好了，这一章的内容就这些。咱们回顾一下：

• 飞控软件是飞机的核心，硬实时、高可靠、确定性、容错
• 典型架构包括传感器、飞控计算机、执行机构三部分
• 安全关键性等级从DAL A到DAL D，要求逐级降低

下一章我会详细讲DO-178C的认证流程。到时候咱们聊聊怎么从零开始做一个通过认证的飞控软件——嗯，那才是真正考验人的地方。