当前位置：首页 > news >正文

跨越天际：从智能汽车到 eVTOL 的适航与系统级开发9——故障树分析（FTA）与共因失效（CCF）

news 2026/6/13 10:07:19

在安全性设计中，汽车工程师最常犯的逻辑错误就是：“我有双芯片、双通道、双电源，所以我做到了 ASIL D，上天就能满足 10^{-9} 的 DAL A。”

但在适航审查专家（DER）的眼里，这种所谓的“完美冗余”往往不堪一击。在多旋翼或分布式电推进（DEP）的 eVTOL 架构中，同质化冗余（Homogeneous Redundancy）是无法用来对抗系统性错误的。如果两路或三路系统采用了相同的芯片、相同的代码、相同的时钟源，那么在某一个特定的电磁脉冲、软件死锁或电源浪涌面前，它们会在同一微秒全部死机。这种现象，就是航空适航竭尽全力要消灭的幽灵——共因失效（CCF, Common Cause Failure）。

3.3 故障树分析（FTA）与共因失效（CCF）在 eVTOL 架构中的应用

在分布式电推进（DEP）的 eVTOL 架构（如 8 轴 8 桨多旋翼）中，表面上看，由于动力点大幅增多，系统天然具备了“容错”能力——坏掉一个电机，其他七个电机可以通过差动推力补上。

但如果我们用故障树分析（FTA, Fault Tree Analysis）这一自上而下的严密数学工具去层层剥离，就会发现隐藏在分布式架构深处的共因失效（CCF）黑洞。

1. 多旋翼 eVTOL 的 FTA 故障树构建：寻找单点失效的入口

故障树（FTA）的顶层事件（Top Event）在 eVTOL 场景下通常定义为：“垂直降落阶段失去对机体的平衡与推力控制（灾难性后果，< 10^{-9}/h）”。

当我们向下画树的分支时，逻辑会分成两条主线，这就是著名的“或门（OR Gate）”与“与门（AND Gate）”的博弈：

【 顶层事件：失去机体控制 (Catastrophic) 】 | [或门] ------------------------------------- | | 【 核心物理执行层失效 (10^-9) 】 【 上层控制与指令链失效 (10^-9) 】 | | [或门] [与门] ------------------ ------------------ | | | | 【过半旋翼停转】 【动力母线过压烧毁】 【 FCC 1 失效 】 【 FCC 2 失效 】 (Orin-X) (Orin-X) \ / \ / 【 共因失效 (CCF) 】 (由于相同芯片/同一代码)

物理执行层的“或门”风险：
你设计了 8 个旋翼，如果 PSSA（初步系统安全性评估）计算表明，同时坏 2 个相邻旋翼就会导致飞机翻转，那么“旋翼 1 坏 AND 旋翼 2 坏”就构成了一个或门的分支。如果 8 个电机的驱动电控（ESC）都连在同一根高压直流母线上，母线一旦发生过压烧毁，那么 8 个电机的冗余在一瞬间清零。此时，高压母线就成了一个单点失效（Single Point Failure），它通过“或门”直通顶层灾难。
控制指令层的“与门”陷阱：
为了保护控制链路，汽车工程师习惯并联两台独立的飞控计算机（FCC 1 和 FCC 2），认为只有当 FCC 1 坏并且（与门）FCC 2 也坏时，才会导致灾难。数学上，如果单台失效率是 10^{-4}，并联后就是 10^{-4} \times 10^{-4} = 10^{-8}。
然而，适航审查会直接无情地推翻这个计算结果。局方会引入贝塔因子（$\beta$-Factor）来修正共因失效。如果两台 FCC 采用了相同的软件和硬件，其共因系数 $\beta$ 往往高达 10%（即有 10% 的概率它们会一起坏）。此时，这个并联系统的真实失效率直接退化为：
原本以为做到了 10^{-8} 的系统，因为共因失效，在数学上直接暴跌回了 10^{-5}，适航取证宣告失败。

2. 共因失效（CCF）的重灾区：车规级技术的隐形地雷

在汽车电子设计中，有一些几乎不被重视的隐形共因源，在航空 10^{-9} 的世界里却是致命的：

同一家供应商的晶振（Clock Source）：如果双路飞控板使用了同一批次的晶振，在经历特定频段的低空机体共振或温度突变时，它们可能会在同一时间发生频率漂移或停振。
编译器的隐性 Bug：使用相同的 C 语言编译器（如 GCC 某个特定版本）去编译两路飞控的代码，编译器优化逻辑中可能潜伏着一个罕见的内存对齐错误，在特定的输入数据流下，两路芯片会同时触发内存越界而死机。
车规 SoC 的物理盲区：高算力的车规芯片（如 NVIDIA Orin、高通 8295）晶体管密度极高。当 eVTOL 飞到几百米高度时，由于大气层变薄，中子辐射强度是地面的数倍到数十倍。高能中子击中芯片内部的 SRAM，会导致单粒子翻转（SEU）。如果双路飞控用的是同一款 SoC，极有可能在一场雷暴或高空辐射脉冲中同时发生状态机锁死。

3. 破局之道：用“非相似性（Dissimilarity）”打破僵局

为了在故障树中把 CCF 这个黑洞堵死，民航客机（如波音 777）确立了非相似余度设计（Dissimilar Redundancy）的铁律。在 eVTOL 的主飞控（FCC）和核心机载设备开发中，必须采取以下四个层面的“全面解耦”：

① 硬件非相似（Hardware Dissimilarity）

绝对不允许在多余度系统中清一色使用同一种处理器。

工程实践：主控制通道（Primary Channel）采用高算力的车规 A 芯片（如 ARM 架构的 SoC，负责跑复杂的控制律和感知融合）；而备用/监视通道（Secondary/Monitor Channel）则必须采用完全不同微架构的 B 芯片（如 PowerPC 架构、TMS570 锁步核、或者是经过航空认证的复杂级 FPGA）。两者的物理流水线、流水线译码、缓存设计完全不同，中子辐射导致同时死机的概率降到可忽略不计。

② 软件非相似（Software Dissimilarity）

同一个团队写出来的两套代码，由于思维定势，往往会犯相同的逻辑错误。

工程实践：主通道和备用通道的代码，必须由两个完全独立的团队进行开发。甚至主通道采用 C 语言在 RTOS（如 VxWorks）上编写，备用通道则采用 Ada 语言或者直接通过 Simulink 模型自动生成代码在裸机（Bare Metal）上运行。两者的变量命名、循环逻辑和时序控制完全解耦。

③ 信号与制式非相似（Signal Dissimilarity）

工程实践：在环境感知和导航（组合导航）中，汽车依赖 RTK-GPS。但在 eVTOL 上，由于存在 GPS 信号被城市楼宇反射干扰（多径效应）或恶意欺骗的风险，系统必须引入非相似信号保底：当多路卫导失效时，系统必须无缝切换到完全不依赖外部信号的航空级光纤惯导（FOG INS）或气象雷达高度计。

非相似冗余架构对照表

为了将这一设计哲学落实到具体的开发规范中，我们可以总结出以下“同质”与“非相似”的红线对照：

架构维度	汽车/低合规做法 (同质化冗余 - 存在 CCF 风险)	适航合规做法 (非相似余度 - 斩断 CCF 证据链)
飞控计算机 (FCC)	2 × NVIDIA Orin-X 芯片，跑同一版 Linux/QNX 系统。	1 × ARM Cortex-A (主通道) + 1 × PowerPC/FPGA (监视通道)，跑不同 OS。
核心电源拓扑	双路 12V 锂电池并联，共用一块车规级 BMS 主控板。	高压电池包通过 A/B 两个物理隔离的配电网络（SSPC）独立供电，BMS 软硬件非相似。
角度/姿态感知	3 个一模一样的六轴 IMU（传感器）贴在同一块 PCB 板上。	3 个不同厂家、不同微机械结构（MEMS vs. 光纤）的 IMU，且在物理位置上空间隔离安装。
代码开发流程	同一个敏捷团队，通过 Git 分支开发 A 轨和 B 轨代码。	两个完全独立的开发团队（物理隔离），甚至使用不同的编程语言与编译器。