1. 功能安全基础：ISO 26262与DO-178C概述、ASIL等级与安全目标定义、飞控系统安全生命周期模型
1.1 为什么飞控系统必须谈功能安全？
说实话，我入行那会儿，大家对「功能安全」的理解还停留在「不出事就行」。直到有一次，我在一个无人机项目中亲眼看到——因为一个软件逻辑的时序错误，飞机在降落前突然翻转，直接砸向地面。幸好当时测试区域没人，不然后果不堪设想。
从那以后，我养成了一个习惯：任何飞控系统的设计，第一件事不是写代码，而是先问自己——如果这个功能失效了，会发生什么？
功能安全，说白了就是一套系统化的方法，用来确保当系统出现故障时，它不会伤害到人、不会损坏设备、不会造成不可接受的损失。对于飞控系统而言，这可不是「锦上添花」，而是「生死攸关」。
1.2 ISO 26262 与 DO-178C：两个标准，一个目标
很多刚接触飞控安全的工程师会问我：「老师，我们到底该用 ISO 26262 还是 DO-178C？」
我的回答是：看你的产品要过谁的认证。
ISO 26262 是汽车行业的功能安全标准，但它对电子电气系统的安全分析方法——比如危害分析与风险评估（HARA）、ASIL 等级划分——已经被大量移植到无人机、eVTOL 等飞控领域。我个人习惯把 ISO 26262 当作「方法论工具箱」，里面的很多工具可以直接拿来用。
DO-178C 则是航空领域的软件安全标准，它更关注软件开发过程的严谨性。如果你做的是有人驾驶的飞行器，或者需要通过民航局适航认证，那 DO-178C 就是绕不开的坎。
我见过不少团队，一开始只盯着 DO-178C 的文档要求，结果开发周期拖了两年。后来他们学聪明了：先用 ISO 26262 的方法做安全分析，再用 DO-178C 的流程做开发验证。两者结合，效率高得多。
核心观点：ISO 26262 教你「怎么分析风险」，DO-178C 教你「怎么证明你做得对」。飞控系统安全，两者缺一不可。
1.3 ASIL 等级与安全目标定义
ASIL（Automotive Safety Integrity Level）是 ISO 26262 中定义的安全完整性等级，分为 A、B、C、D 四个等级，D 级最高。说白了，就是根据失效后果的严重程度，给系统功能「定个罪」。
我在项目中遇到过这样一个案例：一个飞控系统的「姿态解算」功能，如果失效，会导致飞机失控坠毁。按照 ASIL 的评估方法：
- 严重度（Severity）：可能造成人员伤亡 → S3
- 暴露率（Exposure）：飞行过程中持续暴露 → E4
- 可控性（Controllability）：驾驶员几乎无法干预 → C3
最终算下来，这个功能需要达到 ASIL D 等级。这意味着什么呢？意味着你从硬件冗余、软件多样性、故障检测覆盖率等各个方面，都要做到极致。
定义安全目标时，我建议你遵循一个原则：安全目标要具体、可验证、可追溯。比如：
- ❌ 错误写法：「系统要安全」
- ✅ 正确写法：「当 IMU 传感器发生单点故障时，系统必须在 100ms 内切换到冗余传感器，并保持姿态控制精度在 ±2° 以内」
避坑指南：我曾经见过一个团队，把安全目标写成「系统不能坠毁」。结果评审时被专家问：「你怎么证明它不会坠毁？」——安全目标必须可测试、可验证，否则就是一句空话。
1.4 飞控系统安全生命周期模型
安全生命周期，说白了就是「从想法到退役，每一步都要考虑安全」。我把它总结为四个阶段：
- 概念阶段：定义系统功能、识别危害、制定安全目标
- 开发阶段：硬件设计、软件实现、安全机制集成
- 验证阶段：测试、评审、故障注入、安全确认
- 运行阶段：维护、监控、变更管理、退役
你想想看，很多飞控事故其实都出在「变更管理」上。比如某个团队为了提升性能，修改了控制律参数，但没有重新做安全分析——结果就是，一个看似无害的改动，埋下了致命的隐患。
下面这张图是我自己整理的安全生命周期模型，你可以把它当作飞控安全开发的「路线图」：
1.5 安全生命周期中的关键文档
做功能安全，最怕的就是「口说无凭」。我建议你从一开始就建立好文档体系。下面这个表格是我常用的文档清单：
| 阶段 | 关键文档 | 核心内容 |
|---|---|---|
| 概念阶段 | 危害分析与风险评估报告 | 识别所有可能的危害，评估风险等级，定义安全目标 |
| 开发阶段 | 安全计划、安全需求规范 | 明确安全机制、冗余策略、故障检测方法 |
| 验证阶段 | 测试报告、安全确认报告 | 证明安全目标已实现，故障注入结果 |
| 运行阶段 | 变更管理记录、安全审计报告 | 记录所有变更及其安全影响分析 |
⚠️ 重要提醒：千万不要把文档当成「事后补作业」。我见过太多团队，项目做完了才来补安全文档，结果漏洞百出。文档应该是「边做边写」，而不是「做完再编」。
1.6 我的几点经验总结
做了这么多年飞控安全，我最大的体会是：功能安全不是束缚，而是保护。它保护的是用户的生命安全，也是保护你自己的职业生涯。
嗯，这里要注意一点：不要为了追求 ASIL D 等级而过度设计。我见过一个团队，给一个简单的飞控系统做了三冗余 IMU、双冗余 GPS、四路电源备份——结果系统复杂度爆炸，反而引入了更多故障点。安全设计要「恰到好处」，而不是「越多越好」。
最后，送大家一句话：安全不是测试出来的，而是设计出来的。从概念阶段就把安全刻在骨子里，后面会省去无数麻烦。
本章核心要点：
- ISO 26262 提供安全分析方法，DO-178C 提供开发验证流程
- ASIL 等级由严重度、暴露率、可控性共同决定
- 安全目标必须具体、可验证、可追溯
- 安全生命周期覆盖概念、开发、验证、运行四个阶段
- 文档要「边做边写」，安全要「设计出来」
公众号:蓝海资料掘金营，微信deep3321