在安全性设计中汽车工程师最常犯的逻辑错误就是“我有双芯片、双通道、双电源所以我做到了 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 轨代码。两个完全独立的开发团队物理隔离甚至使用不同的编程语言与编译器。关键洞察故障树分析FTA不是为了证明你的系统有多精密而是为了逼工程师承认系统的脆弱性。共因失效CCF是所有堆砌车规级硬件的 eVTOL 初创公司在面对适航审查时最惨烈的翻车点。在“9个9”的世界里两路完全不同的笨办法永远比三路一模一样的高科技更值得信任。