4. 飞控软件架构总体设计
eVTOL（电动垂直起降飞行器）的飞控软件是整机安全的关键中枢，其架构设计直接决定了系统的确定性、容错性与可认证性。与普通无人机不同，eVTOL 在城市密集区运行，面临复杂的低空风切变、障碍物规避和严格的适航审定（如 DO-178C DAL-A 等级）要求。因此，飞控软件架构必须从“功能堆叠”转向“分层解耦”，以清晰的边界管理复杂度，以确定性的调度保障实时性。本章将围绕分层架构、模块划分、数据流/控制流以及实时性设计展开，并结合工程实践给出可落地的方案。
4.1 分层架构的核心原理与设计动机
飞控软件采用“感知-决策-执行”三层架构，并非简单的代码组织方式，而是基于控制论和系统工程学的必然选择。其核心动机在于：隔离变化、控制复杂度、提升可认证性。感知层负责将物理世界的连续信号转换为离散的数字状态；决策层基于状态和任务目标进行逻辑推理与策略选择；执行层将高层指令转换为物理作动。这种分层使得每一层都可以独立开发、测试和替换，例如更换新型激光雷达时，只需修改感知层的驱动和融合算法，决策层和执行层完全不受影响。
4.2 模块划分与职责边界
在分层架构下，每个层次内部进一步细分为高内聚、低耦合的功能模块。模块划分的粒度直接影响开发效率和系统性能。过粗的模块会导致内部逻辑混乱，过细的模块则会增加通信开销和调度负担。以下是eVTOL飞控软件的标准模块划分方案：
| 层次 | 核心模块 | 主要职责 | 关键接口 |
|---|---|---|---|
| 感知层 | 传感器驱动 | IMU、GNSS、气压计、空速管等原始数据采集与预处理 | SPI/I2C/UART/CAN驱动接口 |
| 状态估计 | 扩展卡尔曼滤波（EKF）、互补滤波，输出姿态、位置、速度 | 提供结构化的飞行状态结构体 | |
| 环境感知 | 激光雷达点云处理、视觉目标检测、障碍物跟踪 | 输出障碍物列表及置信度 | |
| 数据融合 | 多传感器冗余管理、故障检测与隔离（FDI） | 输出融合后的可信状态 | |
| 决策层 | 飞行模式管理 | 状态机管理（起飞、巡航、着陆、应急返航） | 模式切换事件接口 |
| 航迹规划 | 全局路径规划、局部避障重规划、速度规划 | 输出航迹点序列 | |
| 控制分配 | 根据当前飞行模式将期望力矩/推力映射到各执行机构 | 输出各电机/舵机的期望值 | |
| 执行层 | 电机控制 | FOC控制、PWM生成、转速闭环 | 电机转速/扭矩指令 |
| 舵机/倾转控制 | 位置闭环、力矩限制、故障保护 | 舵机角度指令 | |
| 健康监控 | 执行器反馈采集、过热/堵转检测、降级策略 | 执行器状态上报 |
4.3 数据流与控制流设计
数据流和控制流是架构的血脉。在eVTOL中，数据流主要呈现单向循环特征：传感器数据向上流动，控制指令向下流动，而反馈信息则通过独立通道回传。设计时需要明确区分同步数据流（如IMU数据，必须严格按时序处理）和异步事件流（如GPS信号丢失告警，可中断处理）。
典型的数据流路径如下：
- 感知数据采集：IMU以200Hz频率产生数据，通过DMA写入内存，驱动层进行零偏校正和坐标系转换。
- 状态估计：EKF模块以100Hz频率融合IMU、GNSS和气压计数据，输出姿态四元数和位置向量。
- 决策计算：控制律模块以50Hz频率读取状态估计结果，结合当前飞行模式计算期望加速度和角速度。
- 控制分配：根据倾转机构当前角度，将期望力矩分配到8个电机和4个舵机。
- 执行输出：执行层以500Hz频率刷新PWM信号，同时采集电机转速作为反馈。
4.4 实时性要求与调度策略
eVTOL的实时性要求比普通无人机严格一个数量级。根据DO-178C和ARP4754A的指导，飞控系统必须满足硬实时约束，即任何任务必须在规定截止时间内完成，否则可能导致灾难性后果。具体指标如下：
- 传感器采样周期：IMU 1-5ms，GNSS 10-20ms，激光雷达 50-100ms。
- 控制律计算周期：内环（角速率环）5-10ms，外环（位置环）20-50ms。
- 执行器响应时间：从指令发出到执行器达到目标位置，必须小于20ms。
- 端到端延迟：从传感器采集到执行器响应，总延迟不超过50ms。
为了满足这些硬实时要求，飞控软件通常采用优先级抢占式调度与时间触发调度相结合的混合策略。高频率、高确定性的任务（如IMU读取、角速率控制）使用时间触发，在固定时间片内执行；低频率、事件驱动的任务（如航迹重规划、故障处理）使用优先级抢占，但必须设置执行时间上限。
// 实时任务调度示例（基于RTOS）
// 时间触发任务：IMU读取 + 姿态控制，周期5ms
void task_imu_control(void) {
while(1) {
imu_read(&raw_data); // 1ms
attitude_ekf(&raw_data, &est); // 2ms
rate_control(&est, &cmd); // 1ms
control_alloc(&cmd, &act); // 1ms
vTaskDelayUntil(&start, 5ms); // 固定5ms周期
}
}
// 优先级抢占任务：故障处理，优先级最高
void task_fault_handle(void) {
while(1) {
if (fault_event_received) {
emergency_landing(); // 执行应急程序
}
vTaskDelay(10ms);
}
}4.5 实战案例：某eVTOL原型机的架构落地与调优
在某型5座eVTOL原型机的飞控开发中，我们遇到了典型的实时性冲突问题。该机采用8电机+4倾转舵机的分布式动力布局，初始架构将所有控制逻辑放在一个500Hz的循环中，导致CPU占用率高达95%，且偶发任务超时。
初始现象：在悬停测试中，电机转速波动超过±150rpm，姿态角偏差达到±3°，远超设计指标。通过日志分析发现，控制循环的最大执行时间达到3.2ms，而设计上限为2ms。
分析过程：通过性能剖析工具（基于ARM CoreSight）定位到瓶颈：倾转舵机的非线性补偿算法占用了40%的CPU时间，且该算法在每次循环中重复计算。进一步分析发现，舵机控制并不需要500Hz的高频率，其机械响应带宽仅为20Hz。
优化措施：
- 将控制循环拆分为两个独立任务：内环（角速率+姿态）保持500Hz，外环（位置+速度）降为100Hz。
- 将倾转舵机控制从内环剥离，单独建立50Hz的任务，并采用查表法替代实时非线性计算。
- 引入DMA中断驱动IMU读取，减少CPU轮询开销。
结果对比：优化后，CPU占用率降至62%，内环最大执行时间稳定在1.8ms以内。悬停测试中，姿态偏差缩小至±0.8°，电机转速波动降至±40rpm。更重要的是，系统在单电机故障注入测试中，故障切换时间从原来的120ms缩短至45ms，满足适航要求。
4.6 常见误区与设计复盘
在飞控软件架构设计中，以下误区需要特别警惕：
- 误区一：过度分层导致延迟增加。虽然分层架构清晰，但每层之间的数据拷贝和通信会引入延迟。解决方案是采用共享内存或零拷贝机制，在保证接口隔离的前提下减少数据搬运。
- 误区二：忽视“感知-决策-执行”之间的反馈闭环。部分设计只关注前向数据流，忽略了执行器状态对感知层的校准作用（如电机转速用于修正振动对IMU的影响）。
- 误区三：将所有任务都设为最高优先级。这会导致低优先级任务饿死，或高优先级任务之间互相干扰。必须建立严格的优先级映射表，并设置看门狗监控任务执行时间。
- 误区四：实时性测试只在真机上进行。真机测试成本高、风险大，且难以复现边界条件。应在开发初期就建立基于Simulink或PX4 SITL的实时性仿真环境，在虚拟环境中注入延迟和抖动，验证架构的鲁棒性。
总结而言，eVTOL飞控软件架构设计的本质是在确定性、可扩展性和可认证性之间寻找平衡。分层架构提供了清晰的逻辑边界，模块划分定义了职责边界，数据流/控制流设计保证了信息传递的效率，而实时性要求则是所有设计的底线约束。在实际项目中，建议采用“架构先行、原型验证、持续度量”的开发策略，确保架构设计能够真正落地并经受住适航审定的考验。