2. 功能安全基础
飞控系统作为航空器或无人机的核心控制中枢，其失效可能导致灾难性后果。功能安全（Functional Safety）并非单纯的产品质量或可靠性问题，而是从系统级视角出发，通过规范化的开发流程、风险识别手段和验证确认活动，将系统性失效和随机硬件失效的风险降低到可接受水平。本章作为课程的第二讲，旨在建立功能安全的统一语言框架：首先厘清功能安全的定义与核心概念，其次剖析安全生命周期的阶段划分与迭代逻辑，最后对比航空与汽车领域三大核心标准（DO-178C、ARP4754A、ISO 26262）的适用范围与内在联系，为后续章节的飞控危害评估与安全分析打下理论基础。
2.1 功能安全的定义与核心概念
2.1.1 核心原理：从“可靠性”到“功能安全”的认知跃迁
传统可靠性工程关注的是“产品不出故障的概率”，而功能安全关注的是“当故障发生时，系统能否将风险控制在可接受范围内”。以飞控系统为例，一个可靠性极高的飞控计算机如果缺乏故障检测与容错机制，一旦发生未预期的失效模式，反而可能比一个可靠性稍低但具备完善监控与降级策略的系统更危险。功能安全的经典定义来自IEC 61508：“不存在由功能异常（E/E/PE系统故障）导致的不合理风险”。这一定义包含三个关键要素：
- 功能异常：不仅包括硬件随机失效，还包括软件系统性缺陷、规格错误、人为操作失误等。
- 不合理风险：风险 = 严重度 × 发生概率 × 可控性，需通过安全目标来量化界定。
- 系统视角：安全不是某个部件的属性，而是整个系统在特定使用场景下的综合表现。
在飞控领域，功能安全通常与“适航安全”紧密关联。例如，民用飞机飞控系统需要满足CCAR-25部或FAR-25部的适航要求，而无人机飞控则需要参考ASTM F3269等特定标准。功能安全的核心输出物是安全目标（Safety Objectives），它规定了系统在特定失效条件下必须达到的行为表现，例如“当俯仰速率传感器失效时，系统必须在100ms内切换至备用传感器并保持可控”。
2.1.2 判断方法：如何界定“安全”与“不安全”
工程实践中，判断一个飞控系统是否“功能安全”需要遵循以下逻辑链条：
- 危害识别（Hazard Identification）：列出所有可能的危害事件，如“飞控指令反向输出”“传感器数据跳变导致姿态发散”等。
- 风险评估（Risk Assessment）：对每个危害事件评估其严重度（灾难性/危险/重大/轻微）和发生概率（频繁/可能/极少/几乎不可能）。
- 安全目标制定：针对不可接受的危害，制定量化的安全目标，例如“发生灾难性失效的概率必须小于10⁻⁹/飞行小时”。
- 安全需求分配：将安全目标逐级分解到系统、子系统、硬件和软件层面，形成可验证的安全需求。
- 验证与确认：通过测试、分析、评审等手段证明安全需求得到满足。
关键判断准则：一个飞控系统是否安全，不取决于它“看起来多可靠”，而取决于它是否具备可证明的、可追溯的、经过验证的安全论证链条。如果无法回答“这个失效模式为什么不会导致灾难性后果”，那么系统就不满足功能安全要求。
2.1.3 案例拆解：无人机飞控的“传感器失效”场景
以某型固定翼无人机飞控系统为例，其IMU（惯性测量单元）包含三轴陀螺仪和加速度计。初始设计仅采用单套IMU，未配置健康监控逻辑。在一次飞行测试中，陀螺仪因温度漂移导致角速度输出偏差超过5°/s，飞控系统未检测到该异常，持续输出错误的舵面指令，最终导致飞机翻滚坠毁。
分析过程：
- 危害识别：IMU输出异常未被检测 → 姿态解算错误 → 舵面指令错误 → 失控坠毁。
- 风险评估：严重度=灾难性（坠毁），发生概率=可能（温度漂移是已知失效模式），风险不可接受。
- 安全目标：当IMU输出偏差超过阈值时，系统必须在50ms内切换至备用传感器或进入安全降级模式。
- 设计改进：增加双余度IMU配置，设计交叉监控逻辑（比较两套IMU输出差值），增加看门狗定时器。
结果对比：改进后系统在实验室注入故障测试中，能够在30ms内检测到传感器偏差并完成切换，满足安全目标要求。该案例说明，功能安全的核心不是“避免故障”，而是“故障发生时系统如何响应”。
2.1.4 常见误区与总结复盘
误区一：认为“通过了所有测试就等于功能安全”。测试只能证明“已覆盖的场景是安全的”，无法覆盖所有未知场景。功能安全要求的是结构化的安全论证，而非单纯的测试通过。
误区二：混淆“可靠性指标”与“安全指标”。MTBF（平均无故障时间）高不代表安全，因为安全关注的是失效后的行为，而非失效本身的发生频率。
误区三：忽视“系统性失效”。软件bug、需求遗漏、配置错误等系统性失效无法通过冗余硬件解决，必须通过过程保证（如DO-178C的软件等级划分）来降低。
总结：功能安全的本质是“风险管理的工程化实现”，它要求工程师从系统设计之初就考虑“如果这里坏了会怎样”，并通过规范化的流程将这种思考固化为可验证的工程证据。
2.2 安全生命周期：从概念到退役的全过程管理
2.2.1 核心原理：V模型与迭代反馈
安全生命周期（Safety Lifecycle）是功能安全方法论的组织框架，它定义了从系统概念设计到最终退役的各个阶段及其输入输出关系。在飞控系统开发中，最常用的是V模型：左侧为自上而下的需求分解与设计，右侧为自下而上的集成验证与确认，底部为编码与实现，顶部为系统验收。安全生命周期并非简单的线性流程，而是包含多个反馈回路：
- 需求变更回路：当验证阶段发现需求不合理时，需返回需求定义阶段进行修订。
- 安全评估回路：每个阶段的安全评估结果可能触发前一阶段的设计调整。
- 运行反馈回路：运营阶段发现的新危害需反馈至设计阶段进行改进。
2.2.2 操作流程：飞控系统安全生命周期的关键阶段
| 阶段 | 主要活动 | 关键输出物 | 飞控系统示例 |
|---|---|---|---|
| 概念阶段 | 定义系统功能、使用场景、初步危害识别 | 初步危害清单、安全目标草案 | 确定飞控系统功能边界（如姿态控制、导航、任务管理） |
| 系统级开发 | 系统架构设计、安全需求分配、系统级FTA/FMEA | 系统安全需求、架构设计文档 | 确定飞控计算机余度架构（双余度/三余度） |
| 硬件/软件级开发 | 硬件详细设计、软件编码、部件级安全分析 | 硬件/软件需求规格、验证计划 | IMU驱动软件实现、传感器数据校验逻辑 |
| 集成验证 | 硬件-软件集成、系统集成测试、安全性验证 | 集成测试报告、安全验证报告 | HIL（硬件在环）测试、故障注入测试 |
| 生产与运行 | 制造、安装、运行监控、维护 | 运行安全报告、维护手册 | 飞控系统在线监控、定期校准 |
| 退役 | 数据清理、系统拆除、经验总结 | 退役安全评估报告 | 无人机退役时清除飞控日志数据 |
2.2.3 实战场景：安全生命周期在飞控升级项目中的应用
某型民用无人机需要将飞控系统从“单GPS导航”升级为“GPS+视觉融合导航”。按照安全生命周期流程：
- 概念阶段：识别新功能带来的危害——视觉传感器在低光照条件下可能失效，导致导航精度下降。
- 系统级开发：设计融合算法架构，定义安全需求——“当视觉传感器置信度低于阈值时，系统自动切换至纯GPS模式并降低飞行速度”。
- 软件级开发：实现视觉-惯性里程计（VIO）算法，编写传感器健康监控模块。
- 集成验证：在仿真环境中注入视觉传感器失效场景，验证切换逻辑的响应时间（要求<200ms，实测180ms）。
- 运行监控：部署后收集1000小时飞行数据，确认无视觉失效导致的异常事件。
复盘经验：升级过程中发现，原安全生命周期文档未覆盖“视觉传感器被遮挡”这一场景，导致验证阶段补充了额外测试。这提醒我们，安全生命周期必须保持“活文档”状态，随项目进展持续更新。
2.2.4 常见误区与总结复盘
误区一：将安全生命周期视为“文档编制流程”，而非“工程决策流程”。文档只是载体，真正的价值在于每个阶段的安全分析决策。
误区二：跳过或压缩概念阶段。飞控系统70%以上的安全缺陷源于需求定义阶段，概念阶段的充分危害识别能显著降低后期返工成本。
误区三：忽视“退役”阶段。飞控系统退役时若未清除敏感数据或未评估剩余风险，可能带来信息安全或安全隐患。
总结：安全生命周期提供了一套“何时做什么、需要什么输入、产生什么输出”的工程管理框架，其核心价值在于将安全活动嵌入到系统开发的每一个环节，而非事后补救。
2.3 相关标准概述：DO-178C、ARP4754A与ISO 26262
2.3.1 核心原理：三大标准的定位与互补关系
飞控功能安全涉及多个标准，它们分别从不同层面提供指导：
- ARP4754A：由SAE发布，针对飞机系统级的开发保证，提供了从飞机级功能到系统级实现的完整流程框架，是飞控系统安全开发的“顶层宪法”。
- DO-178C：由RTCA发布，针对机载软件的开发保证，定义了软件生命周期过程、目标与证据要求，是飞控软件适航认证的直接依据。
- DO-254：与DO-178C配套，针对机载电子硬件（如FPGA、ASIC）的开发保证。
- ISO 26262：由ISO发布，针对道路车辆的电子电气系统功能安全，虽然不直接适用于航空，但其ASIL（汽车安全完整性等级）评估方法、安全文化理念对飞控安全有重要借鉴意义。
这些标准的核心共同点是：基于风险的安全完整性等级划分。航空领域用DAL（设计保证等级）A-E表示，汽车领域用ASIL A-D表示，等级越高，要求的开发严格度和验证充分性越高。
2.3.2 判断方法：如何选择适用的标准
| 项目类型 | 适用标准 | 关键考量 |
|---|---|---|
| 有人驾驶飞机飞控系统 | ARP4754A + DO-178C + DO-254 | 适航审定要求，需与局方（如FAA/EASA/CAAC）协调 |
| 大型无人机（>150kg） | ARP4754A + DO-178C（视情） | 参考有人机标准，但可根据风险等级裁剪 |
| 小型无人机（<25kg） | ASTM F3269 + 制造商内部标准 | 更注重操作风险评估，流程可简化 |
| 汽车自动驾驶域控制器 | ISO 26262 | ASIL等级决定开发严格度 |
2.3.3 案例拆解：DO-178C在飞控软件认证中的应用
某型通航飞机飞控计算机需要获得DO-178C DAL A级认证（最高等级）。项目团队面临以下约束：
- 目标：在18个月内完成软件认证，软件规模约50万行C代码。
- 关键输入：系统安全需求（来自ARP4754A流程）、硬件接口定义、适航审定计划。
- 分析判断：DAL A级要求所有验证目标100%满足，包括语句覆盖、分支覆盖、MC/DC覆盖（修正条件/判定覆盖）。
实际操作步骤：
- 建立软件需求到代码的追溯矩阵，确保每条安全需求都有对应的实现和测试用例。
- 采用基于模型的开发（MBD），使用Simulink生成自动代码，减少手工编码错误。
- 开发专用测试工具，实现MC/DC覆盖率的自动化分析。
- 进行独立验证（IV&V），由第三方团队独立于开发团队执行验证活动。
结果对比：项目最终通过认证，但比计划延期2个月，主要原因是MC/DC覆盖率分析工具初期配置耗时。复盘发现，若在项目启动时即引入覆盖率工具并建立基线，可节省约1个月时间。
经验提醒：DO-178C认证的核心不是“写文档”，而是建立过程证据链。每个开发活动都必须有明确的输入、输出、方法和验证标准，且所有证据需可追溯。
2.3.4 常见误区与总结复盘
误区一：将ISO 26262的ASIL等级直接套用到航空领域。虽然两者逻辑相似，但航空的DAL等级与飞行小时失效概率直接挂钩（如DAL A对应10⁻⁹/飞行小时），而汽车ASIL基于驾驶场景的暴露概率和可控性，不能简单互换。
误区二：认为DO-178C只关注软件编码。实际上，DO-178C覆盖软件需求、设计、编码、集成、验证的全过程，编码只是其中一环。
误区三：忽视ARP4754A与DO-178C的接口。系统级安全需求必须正确传递到软件需求中，否则会出现“系统说一套，软件做一套”的断裂。
总结：三大标准构成了飞控功能安全的完整体系：ARP4754A提供系统级框架，DO-178C/DO-254提供实现级保证，ISO 26262提供跨行业参考。理解它们的定位与接口，是飞控安全工程师的基本功。
本章核心要点回顾：
- 功能安全 = 风险管理的工程化实现，核心是“故障后的行为”而非“故障本身”。
- 安全生命周期是V模型与迭代反馈的结合，每个阶段都有明确的安全活动与输出物。
- ARP4754A（系统）、DO-178C（软件）、DO-254（硬件）、ISO 26262（汽车）共同构成标准体系，需根据项目类型选择适用标准。
- 安全完整性等级（DAL/ASIL）是决定开发严格度的核心参数，等级越高，要求越严。