3、飞控软件特点与安全关键性：飞控软件的功能架构、安全关键等级（DAL A-E）、失效条件与安全性评估（FHA/PSSA/SSA）
飞控软件是飞行控制系统的“神经中枢”，其运行结果直接作用于飞行器的舵面、发动机推力等关键执行机构。与普通嵌入式软件不同，飞控软件的任何异常行为——无论是逻辑错误、时序偏差还是资源耗尽——都可能直接导致飞行器失控，进而引发灾难性事故。因此，理解飞控软件的功能架构、安全关键等级划分以及安全性评估方法，是开展DO-178C适航认证工作的前提和基础。本章将系统阐述飞控软件在机载系统中的位置、其安全关键性如何被量化定义，以及贯穿产品生命周期的安全性评估流程（FHA/PSSA/SSA）如何与软件开发活动相互交织。
上图展示了飞控软件安全性评估的完整链路：从飞机级FHA出发，逐级向下分配安全性需求，最终在软件层面通过DAL等级和DO-178C过程保证来落实。值得注意的是，这一过程并非单向瀑布，而是存在大量的迭代与反馈——当软件架构设计无法满足分配的安全性需求时，需要向上反馈并调整系统架构或余度策略。
3.1 飞控软件的功能架构与核心特征
3.1.1 功能架构的分层逻辑
飞控软件通常运行在专用的飞行控制计算机（FCC）中，其功能架构可以按照“感知-决策-执行”的经典控制论模型进行划分。从软件工程视角看，飞控软件一般包含以下几个核心层次：
- 接口层（I/O管理层）：负责与传感器（惯性测量单元IMU、大气数据系统ADS、全球导航卫星系统GNSS）、执行机构（舵机、作动器）以及其它机载系统（起落架、液压系统）进行数据交换。该层需要处理模拟量、数字量、总线通信（ARINC 429、MIL-STD-1553B、CAN等）以及离散量信号。
- 数据处理层（信号调理与融合）：对原始传感器数据进行滤波、校准、故障检测与隔离（FDI），并完成多源数据融合（如GPS/INS组合导航）。该层输出的数据质量直接决定了控制律计算的准确性。
- 控制计算层（核心算法）：包含飞行控制律（如PID、LQR、H∞、动态逆等）、增益调度、指令整形、包线保护等算法模块。该层是飞控软件的“大脑”，其输出为舵面偏转指令或推力指令。
- 执行管理层（输出与监控）：将控制指令转换为具体的伺服指令，并执行余度管理（如双余度、三余度表决）、输出监控和故障重构逻辑。
- 健康管理（BIT与自检测）：包括上电自检（PUBIT）、飞行中自检（IFBIT）和维修自检（MBIT），用于实时监控软硬件健康状态。
这种分层架构的核心优势在于隔离性：当底层硬件更换或传感器类型变化时，只需修改接口层代码，而控制算法层可以保持相对稳定。同时，分层架构也便于进行独立的安全性分析和验证——每一层都有明确的输入输出契约和失效模式。
3.1.2 飞控软件的独特技术特征
与一般嵌入式软件相比，飞控软件具有以下显著特征，这些特征直接影响了其适航认证的难度和重点：
| 特征维度 | 具体表现 | 对适航认证的影响 |
|---|---|---|
| 强实时性 | 控制周期通常为5ms~50ms，任务必须在硬截止时间内完成 | 需进行最坏情况执行时间（WCET）分析，调度表需经过严格验证 |
| 高确定性 | 输入输出关系必须完全可重复，不允许随机行为 | 禁止使用动态内存分配、递归调用等非确定性结构 |
| 余度管理 | 多通道（双/三/四余度）之间的同步、表决、切换逻辑 | 需验证余度管理逻辑的完备性，防止单点故障 |
| 强耦合性 | 与飞机气动特性、结构模态、液压系统等紧密耦合 | 软件验证需结合硬件在环（HIL）和飞行试验 |
| 长生命周期 | 飞机服役期通常20-30年，软件需持续维护升级 | 需建立严格的配置管理和问题报告（PR）流程 |
工程经验：在飞控软件架构设计阶段，应尽早确定“时间-空间分区”策略（如ARINC 653标准）。通过将不同安全等级的功能模块放置在不同的分区中，可以隔离故障传播，同时降低高安全等级模块的验证成本。例如，将DAL A级的控制律计算与DAL C级的健康监测放在不同分区，即使监测功能失效，也不会影响核心控制功能。
3.2 安全关键等级（DAL A-E）的划分与内涵
3.2.1 DAL等级的定义与来源
软件安全关键等级（DAL，Design Assurance Level）源自于系统安全性评估过程。根据SAE ARP4754A和DO-178C，DAL等级由软件所承担的失效条件的严重性决定。具体对应关系如下：
| DAL等级 | 失效条件分类 | 对飞机/乘员的潜在影响 | DO-178C目标数量 |
|---|---|---|---|
| DAL A | 灾难性（Catastrophic） | 飞机失事，机组或乘客死亡 | 71个目标 |
| DAL B | 危险性（Hazardous） | 飞机受损，少量人员伤亡，机组工作负荷过重 | 69个目标 |
| DAL C | 较大的（Major） | 飞机明显降级，乘客不适但无伤亡 | 62个目标 |
| DAL D | 较小的（Minor） | 飞机能力轻微降低，乘客略感不便 | 26个目标 |
| DAL E | 无影响（No Effect） | 对飞机安全性无任何影响 | 无目标要求 |
需要特别强调的是，DAL等级不是由软件开发者自行决定的，而是由系统安全性评估过程（PSSA）自上而下分配而来。飞控软件的核心模块（如控制律、余度管理）通常被分配为DAL A级，这意味着需要满足DO-178C中最为严格的目标集合。
3.2.2 DAL等级对开发过程的约束
DAL等级直接影响软件生命周期的每一个阶段。以DAL A为例，开发者必须：
- 在软件计划阶段（PSAC）中明确所有71个目标的实现方法；
- 使用形式化方法或经过验证的自动代码生成工具（如基于Simulink的Embedded Coder）来减少人为编码错误；
- 进行语句覆盖、分支覆盖、MC/DC（修正条件/判定覆盖）覆盖分析，其中MC/DC覆盖率必须达到100%；
- 建立完整的软件需求追溯性矩阵，确保每条高层需求、低层需求和测试用例之间双向可追溯；
- 执行独立于开发团队的软件验证（SOI#1~#4审计）。
常见误区：许多团队误以为“DAL A就是代码质量要求高”，实际上DAL A的核心是过程保证与证据充分性。即使代码写得再完美，如果缺乏完整的文档、追溯性分析和覆盖分析证据，仍然无法通过适航审查。DO-178C的本质是“用过程可信度替代产品完美性假设”。
3.3 失效条件与安全性评估流程（FHA/PSSA/SSA）
3.3.1 飞机级FHA：识别“什么不能坏”
功能危害评估（FHA，Functional Hazard Assessment）是安全性评估的起点，通常在飞机级和系统级两个层面进行。飞机级FHA的目标是识别飞机各功能（如“提供俯仰控制”、“提供横滚控制”）在失效时的后果，并对其严重性进行分类。
FHA的输出是一张功能失效条件清单，每条记录包含：功能描述、失效模式（功能丧失、功能错误、非指令操作等）、飞行阶段（起飞、巡航、着陆等）、对飞机/乘员的影响、严重性分类（灾难性/危险性/较大/较小/无影响）。例如：
- “在进近着陆阶段，俯仰控制功能完全丧失” → 灾难性（DAL A）；
- “在巡航阶段，飞行指引仪显示错误但自动驾驶仍正常” → 较大的（DAL C）；
- “座舱照明亮度异常” → 无影响（DAL E）。
FHA通常在项目启动阶段进行，由飞机级系统工程师、飞行安全专家和飞行员共同参与。其难点在于如何全面识别失效模式，避免遗漏“组合失效”或“级联失效”场景。
3.3.2 系统级PSSA：将安全性需求“分配下去”
初步系统安全性评估（PSSA，Preliminary System Safety Assessment）在飞机级FHA之后进行，其目标是将飞机级的安全性需求分解为系统级和部件级的安全性需求。对于飞控系统而言，PSSA需要回答以下问题：
- 采用何种系统架构（如三余度、四余度）来满足“俯仰控制功能丧失概率小于10^-9/飞行小时”的需求？
- 每个余度通道的失效率应控制在什么范围内？
- 哪些部件失效会导致系统降级？降级后的功能是否满足最低安全要求？
- 软件和硬件各自承担的安全性需求是什么？
PSSA的常用方法包括故障树分析（FTA）、失效模式与影响分析（FMEA）和马尔可夫分析。PSSA的输出是系统安全性需求文档，其中明确规定了分配给飞控软件的DAL等级以及具体的失效概率预算。
3.3.3 系统级SSA：证明“需求被满足”
系统安全性评估（SSA，System Safety Assessment）是在系统设计完成并经过验证后进行的综合性评估。SSA的目标是提供证据，证明系统在最终架构下满足FHA和PSSA中定义的安全性需求。SSA活动包括：
- 更新FTA和FMEA，使用实际部件的失效率数据（来自可靠性测试或历史数据）；
- 确认软件DAL等级与系统安全性需求的匹配性；
- 评估共因失效（CCF）防护措施的有效性；
- 审查系统验证结果（包括软件验证、硬件验证和系统集成测试）。
SSA不是一次性活动，而是随着设计变更持续更新的“活文档”。任何影响安全性的设计变更（如更换传感器型号、修改控制律参数）都需要触发SSA的重新评估。
3.4 案例拆解：某无人机飞控软件DAL A级认证实践
为帮助读者理解上述理论如何落地，以下以一个中型固定翼无人机的飞控软件适航认证项目为例进行拆解。
背景与约束：该无人机最大起飞重量为150kg，飞行高度3000m，计划在非隔离空域执行任务。适航审定基础要求其飞控软件达到DAL A级。项目团队由12人组成（5名软件工程师、3名验证工程师、2名系统工程师、1名质量保证工程师、1名适航联络员），开发周期为18个月。
初始现象与目标：项目启动时，团队面临的最大挑战是缺乏DO-178C经验，且原型的飞控代码为“科研风格”的C语言代码，存在大量动态内存分配和全局变量耦合。目标是在18个月内完成从原型代码到适航代码的转换，并通过局方SOI#1~#4审计。
关键输入数据与指标：
- 飞机级FHA识别出飞控系统相关失效条件共23项，其中5项为灾难性，8项为危险性；
- PSSA分析确定飞控计算机采用双余度架构（主-备），软件需承担“单通道失效后自动切换且无功能损失”的需求；
- 软件规模约5万行C代码（不含自动生成代码），控制周期为10ms。
分析判断过程：团队首先进行了差距分析，发现原型代码存在三大问题：①使用了malloc/free动态内存分配；②中断服务程序中直接调用控制律函数；③全局变量超过200个，数据流不清晰。针对这些问题，团队决定采用“分层重构+自动代码生成”策略：将控制律算法用Simulink建模并自动生成代码，而I/O驱动和余度管理逻辑采用手写代码，但严格遵循MISRA C:2012标准。
实际操作步骤：
- 第1-3个月：完成软件需求规格（SRS）和软件架构设计（SAD），建立需求追溯矩阵；
- 第4-8个月：完成Simulink模型开发与验证（模型在环MIL测试），生成嵌入式代码；手写代码模块完成静态分析（覆盖率100%的MISRA规则检查）；
- 第9-12个月：进行软件集成，执行处理器在环（PIL）测试和硬件在环（HIL）测试，采集语句覆盖、分支覆盖和MC/DC覆盖数据；
- 第13-15个月：完成结构覆盖分析，对未覆盖的MC/DC分支进行补充测试或代码修改；
- 第16-18个月：准备适航审查资料，包括PSAC、SDP、SCMP、SQAP、软件验证结果、问题报告（PR）闭环记录等。
结果对比与风险代价：最终项目按期通过SOI#1~#4审计，获得局方批准。但过程中也付出了代价：Simulink模型开发比预期多花了2个月，导致HIL测试时间被压缩；MC/DC覆盖率从95%提升到100%的过程中，发现并修复了3个控制律边界条件错误。复盘经验表明，尽早引入适航审查人员参与设计评审（而非等到验证阶段）是缩短认证周期的关键。
经验总结：对于DAL A级飞控软件，建议采用“模型化开发+自动代码生成”作为主路径，手写代码仅用于硬件驱动和底层封装。同时，应在项目初期就建立“覆盖分析工具链”（如Simulink Coverage + VectorCAST），避免后期因工具集成问题导致数据无法采集。
3.5 常见误区与总结复盘
在飞控软件适航认证实践中，以下误区需要特别警惕：
| 误区描述 | 潜在后果 | 正确做法 |
|---|---|---|
| 将DAL A理解为“代码零缺陷” | 过度追求代码完美而忽视过程证据，导致审查不通过 | 将重点放在满足DO-178C目标、建立完整追溯链和覆盖分析上 |
| FHA/PSSA/SSA由系统团队“闭门造车” | 软件团队不了解安全性需求来源，导致设计偏离 | 软件团队应参与PSSA评审，理解DAL分配的合理性 |
| 使用动态内存分配或递归调用 | 违反DO-178C对确定性的要求，无法通过验证 | 采用静态内存池和循环替代递归，确保执行时间可预测 |
| 覆盖分析只关注“代码行” | MC/DC覆盖率不达标，无法证明逻辑正确性 | 对DAL A软件必须完成MC/DC分析，并处理所有“短-circuit”逻辑 |
| 安全性评估与软件开发“两张皮” | SSA报告与软件实际行为不一致，审查时发现重大偏差 | 建立安全性需求到软件需求的追溯关系，定期同步更新 |
总结：飞控软件的安全关键性不是抽象概念，而是通过FHA→PSSA→SSA这一严谨的评估链条，最终量化为具体的DAL等级和DO-178C目标。软件团队必须深刻理解自身工作在整个安全性评估体系中的位置，将“过程保证”与“产品验证”有机结合。下一阶段，我们将深入探讨DO-178C的软件计划阶段（PSAC）如何编写，以及如何定义符合DAL A要求的软件生命周期环境。