这部分正式进入了航空适航体系的核心“方法论”深水区。对于汽车工程师来说ISO 26262 的核心是 HARA危害分析与风险评估而航空业的“圣经”则是基于 SAE ARP4754A系统开发过程与 ARP4761安全性评估过程的双剑合璧。这不仅仅是几份文档的替换而是从“评估概率”到“架构兜底”的灵魂重塑。第二篇适航开发体系与核心标准簇 (The DO-Series)如果说第一篇讲述的是适航的法律边界与生命周期那么从本篇开始我们将真正拿起适航工程师的手术刀解剖一架 eVTOL 的内脏。在航空业没有任何一行代码或一块电路板是凭空出现的它们的诞生必须遵循一套由顶至下的极其严密的逻辑推导。统御这套逻辑的“宪法”就是 SAE ARP4754A民用飞机及系统开发指南与 ARP4761民用机载系统和设备安全性评估指南。它们定义了如何用数学和逻辑去编织一张名为“安全”的大网。第 3 章系统级开发与安全性评估ARP4754A / ARP4761在智能汽车的开发中我们习惯于“先有硬件架构再做功能安全分析”。系统工程师往往先决定使用双 Orin-X 芯片然后再去跑一遍 FMEDA看看能不能凑出 ASIL D 的指标。但在航空业这个顺序是绝对倒置的先有对“灾难”的定义然后才有架构的诞生。这一过程被严密地划分为 FHA、PSSA 和 SSA 三个渐进的审查阶段。3.1 飞行器级功能危害评估FHA与系统安全性评估SSA无论是底盘域控还是智能座舱汽车工程师在做功能安全ISO 26262时起手式必然是 HARAHazard Analysis and Risk Assessment危害分析与风险评估。而在航空业对应的起手式叫做FHAFunctional Hazard Assessment功能危害评估。这两者在名字上看似孪生兄弟但在判定生死的逻辑上却有着天壤之别。1. FHA无视“人类可控度”的残酷审判FHA 发生在项目的最早期概念阶段它的唯一目的是找出飞机可能执行的所有“功能”并假设这些功能在最糟糕的阶段失效然后评定其物理后果。汽车 HARA 的温情汽车 HARA 在评估风险时有一个关键因子叫“可控度Controllability”。比如电子助力转向EPS在直道行驶时突然失效工程师会认为大多数驾驶员只要用力握紧方向盘就能控制住车辆因此将其危害等级降级。航空 FHA 的冷酷无情航空 FHA 彻底剥夺了“人类挽救局势”的权重。对于 eVTOL 而言FHA 会提出这样的假设“如果在 100 米低空处于垂直降落阶段最恶劣飞行剖面飞控系统完全失去对四组旋翼的推力分配控制会发生什么”答案是明确的飞机将立刻翻滚坠毁导致机毁人亡。在 FHA 的定义中这直接被判定为最高等级的Catastrophic灾难性对应飞行器级目标为 10^{-9}/飞行小时。在这里FHA 不关心你用什么硬件不关心软件写得有多好它只定义“如果失效后果多惨”。这个后果将直接决定该功能对应的DAL设计保证等级。2. PSSA初步系统安全性评估架构工程师的“绝望与逢生”当 FHA 定义了“失去推力分配是灾难性的Catastrophic”之后压力就来到了系统架构师这边。如何用真实的硬件和软件去承载这个 10^{-9} 的目标这就是PSSAPreliminary System Safety Assessment的核心工作。PSSA 发生在初步设计阶段PDR。它不仅是安全性评估更是架构设计的指挥棒。DAL 的向下分配Allocation没有任何单点硬件比如一颗车规级 SoC 或单个电机能在物理上达到 10^{-9} 的可靠性。PSSA 会运用故障树分析FTA通过架构的冗余设计将顶层的 DAL A 目标“分解”给下层的子系统。余度与隔离例如架构师在 PSSA 中提出设计方案——采用三套完全独立的飞控计算机FCC。通过马尔可夫链或 FTA 计算如果每套 FCC 能做到 10^{-4} 的可靠性且它们之间实现了绝对的电气隔离与非相似性避免共因失效那么 10^{-4} \times 10^{-4} \times 10^{-4} 10^{-12}这就满足甚至超越了 10^{-9} 的目标。PSSA 的输出PSSA 的最终产物是给下游的软/硬件团队下达死命令“你飞控板硬件团队必须按照 DO-254 DAL A 的标准去画板子你降落伞触发软件团队必须按照 DO-178C DAL B 的标准去写代码。”3. SSA系统安全性评估最终的闭环判决如果说 PSSA 是对未来的“承诺”那么SSASystem Safety Assessment就是在系统完工后交付的“证据”。SSA 发生在详细设计完成、进入适航取证TIA/TC的末期。它是一个自下而上Bottom-Up的验证过程收集证据系统工程师拿着从硬件团队收到的 FMEA失效模式与影响分析、从软件团队收到的结构覆盖率报告、从铁鸟台收到的故障注入测试Fault Insertion Test结果一项一项地填入故障树FTA的最底端节点。算总账将所有真实测得的失效率数据、软件 DO-178C 的合规报告汇总重新向上计算。如果最终整架飞机的灾难性失效概率确实小于等于 10^{-9}并且没有任何单点失效能导致机毁人亡那么 SSA 宣告闭环。适航局方的最终审计局方审查的本质就是核对你的 FHA你承诺不死的底线、PSSA你设计的防死方案和 SSA你证明自己没死的证据是否完美咬合无懈可击。关键洞察从智能汽车的 ASIL 向 eVTOL 的 DAL 跃迁核心在于放弃“硬件堆料即安全”的错觉。车规级芯片算力再高如果不经过 FHA 的严酷审判不通过 PSSA 进行独立性架构分解最后在 SSA 中拿不出系统级隔离的证据它就永远只是一块算力强大的“废铁”。在 ARP4754A 的世界里安全性不是被制造出来的而是被严密的系统工程推导出来的。
跨越天际：从智能汽车到 eVTOL 的适航与系统级开发7——飞行器级功能危害评估（FHA）与系统安全性评估（SSA）
这部分正式进入了航空适航体系的核心“方法论”深水区。对于汽车工程师来说ISO 26262 的核心是 HARA危害分析与风险评估而航空业的“圣经”则是基于 SAE ARP4754A系统开发过程与 ARP4761安全性评估过程的双剑合璧。这不仅仅是几份文档的替换而是从“评估概率”到“架构兜底”的灵魂重塑。第二篇适航开发体系与核心标准簇 (The DO-Series)如果说第一篇讲述的是适航的法律边界与生命周期那么从本篇开始我们将真正拿起适航工程师的手术刀解剖一架 eVTOL 的内脏。在航空业没有任何一行代码或一块电路板是凭空出现的它们的诞生必须遵循一套由顶至下的极其严密的逻辑推导。统御这套逻辑的“宪法”就是 SAE ARP4754A民用飞机及系统开发指南与 ARP4761民用机载系统和设备安全性评估指南。它们定义了如何用数学和逻辑去编织一张名为“安全”的大网。第 3 章系统级开发与安全性评估ARP4754A / ARP4761在智能汽车的开发中我们习惯于“先有硬件架构再做功能安全分析”。系统工程师往往先决定使用双 Orin-X 芯片然后再去跑一遍 FMEDA看看能不能凑出 ASIL D 的指标。但在航空业这个顺序是绝对倒置的先有对“灾难”的定义然后才有架构的诞生。这一过程被严密地划分为 FHA、PSSA 和 SSA 三个渐进的审查阶段。3.1 飞行器级功能危害评估FHA与系统安全性评估SSA无论是底盘域控还是智能座舱汽车工程师在做功能安全ISO 26262时起手式必然是 HARAHazard Analysis and Risk Assessment危害分析与风险评估。而在航空业对应的起手式叫做FHAFunctional Hazard Assessment功能危害评估。这两者在名字上看似孪生兄弟但在判定生死的逻辑上却有着天壤之别。1. FHA无视“人类可控度”的残酷审判FHA 发生在项目的最早期概念阶段它的唯一目的是找出飞机可能执行的所有“功能”并假设这些功能在最糟糕的阶段失效然后评定其物理后果。汽车 HARA 的温情汽车 HARA 在评估风险时有一个关键因子叫“可控度Controllability”。比如电子助力转向EPS在直道行驶时突然失效工程师会认为大多数驾驶员只要用力握紧方向盘就能控制住车辆因此将其危害等级降级。航空 FHA 的冷酷无情航空 FHA 彻底剥夺了“人类挽救局势”的权重。对于 eVTOL 而言FHA 会提出这样的假设“如果在 100 米低空处于垂直降落阶段最恶劣飞行剖面飞控系统完全失去对四组旋翼的推力分配控制会发生什么”答案是明确的飞机将立刻翻滚坠毁导致机毁人亡。在 FHA 的定义中这直接被判定为最高等级的Catastrophic灾难性对应飞行器级目标为 10^{-9}/飞行小时。在这里FHA 不关心你用什么硬件不关心软件写得有多好它只定义“如果失效后果多惨”。这个后果将直接决定该功能对应的DAL设计保证等级。2. PSSA初步系统安全性评估架构工程师的“绝望与逢生”当 FHA 定义了“失去推力分配是灾难性的Catastrophic”之后压力就来到了系统架构师这边。如何用真实的硬件和软件去承载这个 10^{-9} 的目标这就是PSSAPreliminary System Safety Assessment的核心工作。PSSA 发生在初步设计阶段PDR。它不仅是安全性评估更是架构设计的指挥棒。DAL 的向下分配Allocation没有任何单点硬件比如一颗车规级 SoC 或单个电机能在物理上达到 10^{-9} 的可靠性。PSSA 会运用故障树分析FTA通过架构的冗余设计将顶层的 DAL A 目标“分解”给下层的子系统。余度与隔离例如架构师在 PSSA 中提出设计方案——采用三套完全独立的飞控计算机FCC。通过马尔可夫链或 FTA 计算如果每套 FCC 能做到 10^{-4} 的可靠性且它们之间实现了绝对的电气隔离与非相似性避免共因失效那么 10^{-4} \times 10^{-4} \times 10^{-4} 10^{-12}这就满足甚至超越了 10^{-9} 的目标。PSSA 的输出PSSA 的最终产物是给下游的软/硬件团队下达死命令“你飞控板硬件团队必须按照 DO-254 DAL A 的标准去画板子你降落伞触发软件团队必须按照 DO-178C DAL B 的标准去写代码。”3. SSA系统安全性评估最终的闭环判决如果说 PSSA 是对未来的“承诺”那么SSASystem Safety Assessment就是在系统完工后交付的“证据”。SSA 发生在详细设计完成、进入适航取证TIA/TC的末期。它是一个自下而上Bottom-Up的验证过程收集证据系统工程师拿着从硬件团队收到的 FMEA失效模式与影响分析、从软件团队收到的结构覆盖率报告、从铁鸟台收到的故障注入测试Fault Insertion Test结果一项一项地填入故障树FTA的最底端节点。算总账将所有真实测得的失效率数据、软件 DO-178C 的合规报告汇总重新向上计算。如果最终整架飞机的灾难性失效概率确实小于等于 10^{-9}并且没有任何单点失效能导致机毁人亡那么 SSA 宣告闭环。适航局方的最终审计局方审查的本质就是核对你的 FHA你承诺不死的底线、PSSA你设计的防死方案和 SSA你证明自己没死的证据是否完美咬合无懈可击。关键洞察从智能汽车的 ASIL 向 eVTOL 的 DAL 跃迁核心在于放弃“硬件堆料即安全”的错觉。车规级芯片算力再高如果不经过 FHA 的严酷审判不通过 PSSA 进行独立性架构分解最后在 SSA 中拿不出系统级隔离的证据它就永远只是一块算力强大的“废铁”。在 ARP4754A 的世界里安全性不是被制造出来的而是被严密的系统工程推导出来的。
