跨越天际：从智能汽车到 eVTOL 的适航与系统级开发54——附录 A 汽车 ISO 26262 与 航空 ARP4754B 术语与过程工件（Artifacts）深度对照表
本文针对eVTOL适航工程与智能汽车安全标准的跨界融合需求，系统对比分析了ISO26262与ARP4754B两套标准体系的核心差异：1）安全目标上，汽车ASIL-D（10^-8/h）允许驾驶员兜底，而航空DAL-A（10^-9/h）要求全系统冗余；2）方法论层面，航空业额外引入CMA共因分析和100%MCDC覆盖率等严苛要求；3）文档体系上，汽车敏捷开发工件需转化为民航认可的FHA报告、SDD等23类法定证据链。研究提炼出157组术语映射关系，特别指出"安全状态"在三维空间必须升维为"故障在线运转"，为跨产业团队搭建了术语转换桥梁。
在智能汽车工程向 eVTOL 适航工程升维的跨界转型中，两套话语体系的“语言互译”是构建跨产业融合研发团队的关键基石。汽车行业遵循的ISO 26262规范专注于汽车电子电气系统的功能安全（Functional Safety）；而航空业遵循的ARP4754B（通常与ARP4761A、DO-178C、DO-254组合）则覆盖了整机层面的系统开发保证（Development Assurance）。
本附录将两者的核心术语概念、安全性分析方法以及研发各阶段产生的法定过程工件（Artifacts / Evidences）进行了深度的对标映射。
A.1 核心术语与基本概念深度映射表
| 维度 | 🚗 智能汽车阵营（ISO 26262） | ✈️ 航空适航阵营（ARP4754B） | 🛠️ 工程学底层逻辑与升维质变解析 |
| 最高过程框架 | 功能安全生命周期 (Safety Life Cycle) | 系统开发保证过程 (Development Assurance Process) | 汽车强调通过开发流程控制避免电子电气系统失效导致的风险；航空则穿透整机、系统、硬件和软件的全生命周期，强调对所有设计缺陷的“开发保证”。 |
| 安全分级指标 | ASIL (车辆安全完整性等级：ASIL A ~ D) | DAL / FDAL / IDAL (设计保证等级：DAL A ~ E) | 汽车最高级为ASIL D（允许失效概率 $<10^{-8}/h$，默认有驾驶员或地面物理兜底）；航空最高级为DAL A（允许失效概率 $<10^{-9}/h$，无高空退路，Fail-Operational）。 |
| 初始风险评估 | HARA (危害分析与风险评估) | FHA (功能危害评估：分为飞机级 FHA 与系统级 FHA) | HARA 基于严重度（S）、暴露率（E）和可控性（C）定量矩阵；FHA 则直接定性定级，根据最坏情况下的功能丧失或错误输出对机组、乘客和地面第三方的受损程度进行划界。 |
| 安全防护边界 | 安全状态 (Safe State) | 故障在线运转状态 (Fail-Operational State) | 汽车的 Safe State 默认是“切断动力、靠边减速停靠”；eVTOL 在三维低空没有“路边”可停，其 Safe State 必须是“降级维持姿态并在空中继续飞行降落”。 |
| 异常应对能力 | 可控性 (Controllability) | 机组工作负荷/接管 (Crew Workload / Recovery) | 汽车默认普通驾驶员通过本能踩刹车或修正方向盘进行兜底；航空对 DAL A/B 级系统默认不考虑人类瞬态本能挽救，必须依靠全权限飞控系统执行自动脱困。 |
| 变更与追踪管理 | 配置管理 / 变更控制 (CM / Change Control) | 配置管理与基线控制 (Configuration Management / Baseline) | 汽车敏捷开发允许在验证期频繁打补丁和在线重构；航空适航审查实行严格的“阶段基线封卷”，任何一行代码或元件变更均需触发安全性再评估。 |
A.2 安全性分析方法与矩阵对标表
在系统开发流程中，从顶向下的风险分解与底向上的失效实证方法在两个行业中存在高度的同源性，但航空业的交叉互监分析严苛得多：
| 安全分析范式 | 🚗 智能汽车阵营（ISO 26262 / ISO 21448） | ✈️ 航空适航阵营（ARP4761A / ARP4754B） | 💡 跨界应用技术交割要点 |
| 定性/定量从顶向下 | FTA(故障树分析) STPA(基于系统理论的流程分析) | FTA(Fault Tree Analysis) CMA(Common Mode Analysis, 共因分析) | 航空 FTA 的底层概率乘积直接用于实证 $10^{-9}$ 的数理逻辑，且强制引入CMA以从物理、供电、时钟网络上彻底排查单点导致的共因覆灭。 |
| 定性/定量从底向上 | FMEA(失效模式及影响分析) FMEDA(失效模式、影响与诊断分析) | FMEA(Failure Mode and Effects Analysis) PSSA(初步系统安全性评估) | 汽车 FMEDA 深度依赖单芯片的硬件诊断覆盖率（DC）；航空 FMEA 更侧重于机械、电气物理交界处的级联效应，并将其收口至PSSA形成顶层功能需求的再验证。 |
| 非故障类长尾风险 | SOTIF(预期功能安全) 针对环境限制、算法性能不足导致的风险。 | Environmental / ConOps Assessment 针对极限风场、鸟撞、复杂紊流场的安全性保障。 | 汽车 SOTIF 主要解决黑盒 AI 在未知场景下的感知局限；eVTOL 的气动边界防御律（如第 15.1 章所述的涡环与失速拦截）则通过确定性的航空运行限制与硬性算法外壳直接消纳。 |
A.3 研发各阶段法定过程工件（Artifacts / Evidences）深度对照表
在向局方（CAAC/EASA/FAA）申请型号合格证（TC）的过程中，汽车团队必须提交的系统级工程文档必须完成如下转换，才能被民航审查组认定为有效的符合性验证证据：
1. 需求与架构设计阶段
[汽车工件] ──→ 1. TSC (技术安全概念) ──→ 映射转化 ──→ [航空工件] ──→ 1. SDD (系统设计说明书) [汽车工件] ──→ 2. FSR (功能安全需求) ──→ 映射转化 ──→ [航空工件] ──→ 2. HLReq (系统高层需求书) [汽车工件] ──→ 3. SSR (软件安全需求) ──→ 映射转化 ──→ [航空工件] ──→ 3. LLReq (软件底层需求书)汽车 ISO 26262 工件：
Item Definition（相关项定义描述文件）FSR(Functional Safety Requirements，功能安全需求)TSC(Technical Safety Concept，技术安全概念说明书)
航空 ARP4754B 对应工件（用于 TC 审计）：
ConOps(Concept of Operations，系统运行概念说明书)FHA Report(Aircraft/System Functional Hazard Assessment，功能危害评估报告)HLReq / LLReq(High-Level / Low-Level Requirements，系统高/底层需求文档)SDD(System Architecture and Design Description，系统架构与设计说明书)
2. 软件与复杂硬件实现阶段
汽车 ISO 26262 工件：
Software Architecture Design（软件架构设计书）MISRA Compliance Report（静态代码规范扫描报告）Unit Test Report（单元测试报告）
航空 DO-178C / DO-254 对应工件（用于 SOI-1 ~ SOI-4 审计）：
PSAC / PHAC(Plan for Software/Hardware Aspects of Certification，软件/硬件审定计划书)Traceability Matrix(双向绝对可追溯性矩阵，覆盖：需求-设计-代码-用例-结果)MCDC Structural Coverage Report(100% 动态修正条件/判定覆盖率二进制机器码级报告)SAS / HAS(Software/Hardware Accomplishment Summary，软件/硬件完工总结报告)
3. 系统集成与整车/整机验证阶段
汽车 ISO 26262 工件：
HIL Test Report（硬件在环测试报告）Proving Ground Test Log（试验场实车路测日志与数据标定表）Safety Case（最终功能安全档案）
航空 ARP4754B / 局方审定 对应工件（用于 MOC 4 / MOC 8 发证）：
CP(Certification Plan，官方符合性计划主表)Iron Bird Test Procedure & Log(铁鸟台级系统级综合集成与物理故障注入专用测试工件)Flight Test Open Items & Limitations(试飞未决问题单与全包线运行局限强制限制符)SSA Report(System Safety Assessment，整机系统安全性评估终期结案报告)
💡 跨界总工程师生存指南：
汽车跨界工程师在编写 eVTOL 系统的技术方案时，应在团队内部推行术语强对齐机制。在面对民航局审查员时，切忌使用“敏捷打补丁”、“One-Box 降级”等纯汽车或互联网词汇，必须统一转换为“配置项基线控制（DO-178C CM）”、“故障在线运转（Fail-Operational）”及“符合性验证方法（MOC）”等民航法规的标准法理语言。这种语言的精确对齐，不仅是技术严谨性的体现，更是加速通过 TC 型号合格证审查、消解局方抗拒心理的战略性武器。