跨越天际：从智能汽车到 eVTOL 的适航与系统级开发8——DAL评级与具体对应

Refhttps://www.leedeo.es/l/levels-of-safety-integrity-asil-dal-and-sil/Levels of safety integrity: ASIL, DAL and SIL在适航审查的考场上DALDesign Assurance Level设计保证等级的评定就是一切软硬件开发的生命线。汽车工程师非常熟悉 ASIL A、B、C、D 的划分但在航空系统工程ARP4754A / ARP4761中DAL A 到 E 的评级逻辑更加冷酷。它不看你是在做飞控、动力还是座舱它只看一件事当这个功能彻底失效或发生错误时飞机上和地面上的人会死得有多惨。3.2 DAL A 到 DAL E 的评级逻辑与失效状态的对应关系很多从车企转行来的工程师会习惯性地认为“飞控和动力肯定是最重要的座舱和通信是次要的。”但在航空适航中这种“按部件论资排辈”的想法是极其危险的。在 ARP4754A 的世界里“功能Function”才是定级的主体而系统只是承载功能的容器。一个看似普通的电子开关如果它的失效会导致降落伞在错误的高空意外弹射那这个开关的硬件开发等级就会被直接顶到最高的 DAL A。局方对失效状态Failure Conditions的严厉程度进行了五个维度的绝对划分。每一个维度都直接锁死了对应的系统级定量失效率目标和软硬件研制保障等级。1. 航空安全矩阵失效状态与 DAL 的铁血映射航空系统安全性评估ARP4761将失效后果、定量概率和设计保证等级DAL进行了严密的矩阵绑定。无论是 CAAC 还是 EASA在审查 eVTOL 时都严格执行以下定级标准失效状态等级物理后果定义人员与飞行器受损情况允许发生概率上限 (每飞行小时)行业术语 / 俗称对应开发等级 (Design Assurance Level)Catastrophic (灾难性)整机坠毁导致机上人员全部遇难或对地面人员造成毁灭性伤亡。 10^{-9}“9个9” / 零容忍DAL A(飞控/核心配电/总动力)Hazardous / Severe-Major (危害性)飞行器结构严重受损乘员受到重伤甚至极少数死亡或导致飞行员工作负荷剧增无法进行准确的操作。 10^{-7}“7个9” / 极度严重DAL B(防撞/备用飞控/部分感知)Major (主要性)飞行器性能明显下降乘员出现显著不适如轻伤飞行员工作负荷显著增加但仍在控制范围内。 10^{-5}“5个9” / 显性故障CDAL C(主通信/气象雷达/主导航)Minor (轻微性)飞行器性能略有下降乘员略感不适如噪音、颠簸飞行员工作负荷轻微增加。 10^{-3}“3个9” / 轻微扰动IDAL D(智能座舱/客舱环境控制)No Safety Effect (无安全影响)对飞行安全、飞行器操作或乘员舒适度没有任何负面影响。无硬性要求QM / 商业级IDAL E(车载娱乐/运营数据上报)2. 五大失效状态的深度解剖与 eVTOL 典型场景映射为了让汽车工程师彻底搞懂这五级划分我们必须脱离抽象的字面定义将其映射到一架分布式电推进DEP的 eVTOL 具体运行工况中【Catastrophic 灾难性 DAL A】工程定义系统一旦失效飞行器完全失去维持安全飞行的物理能力百分之百导致机毁人亡。eVTOL 灾难现场在城市上空 150 米悬停时全机动力母线短路掉电或者三余度飞控计算机由于同一个软件 Bug 导致全机舵面死锁。工程跨越这是汽车 ASIL D 无法覆盖的领域。DAL A 要求软件DO-178C必须进行 100% 的 MC/DC 覆盖率测试硬件DO-254必须进行极端时序和独立性审计。设计目标是即便发生多重故障系统也必须硬扛着把飞机降落到地面。【Hazardous 危害性 DAL B】工程定义虽然没有当场坠毁但飞机受损严重或者飞行员的操控环境恶化到崩溃边缘极大概率发展为灾难性后果。eVTOL 灾难现场多旋翼 eVTOL 的探测与避让系统DAA彻底瞎了且在低空飞行时与另一架物流无人机发生轻微擦碰导致某个副翼变形飞机虽勉强能飞但姿态极度不稳定。工程跨越DAL B 对应的概率是 10^{-7}/小时。在这一级局方对开发过程的独立性要求Independence依然极高不允许开发人员和验证人员是同一个团队。【Major 主要性 DAL C】工程定义飞机还能安全飞行但关键的非控制类功能丢了。飞行员必须在极大的心理压力和工作负荷下被迫改变航线或紧急中止任务。eVTOL 灾难现场用于空管通信的甚高频VHF电台或空地控制链路CNPC全天线烧毁导致飞机与地面控制站GCS彻底断联。此时飞机只能依靠预设的 DAL A 级自主飞控代码自动返航。工程跨越这通常对应汽车的最高安全等级 ASIL D。在航空业DAL C 是一个分水岭。从 DAL C 开始软件测试不再强制要求 MC/DC 覆盖仅要求条件/判定覆盖。很多车规级的高级辅助驾驶ADAS组件在经过环境加固后可以勉强映射到这一级。【Minor 轻微性 DAL D】工程定义完全不影响飞行轨迹和动力只是让飞行员多按几个按钮或者让乘客受点罪。eVTOL 灾难现场在炎热的夏天客舱的空调系统ECS突然停转或者高度计在显示屏上的刷新率从 60Hz 掉到了 10Hz。工程跨越对应汽车的 ASIL B/C。此时的开发允许大量使用商业现货COTS组件软件开发可以适当引入部分敏捷迭代流程适航审查的颗粒度会显著放宽。【No Safety Effect 无影响 DAL E】工程定义这个功能坏不坏和这架飞机能不能飞、安全不安全没有一毛钱关系。eVTOL 灾难现场乘客椅背后面的 4K 娱乐大屏死机了或者用于收集电池健康数据的非实时云端上报模块掉线了。工程跨越对应汽车的 QMQuality Management级别。局方对 DAL E 级别的软硬件几乎采取“闭眼放行”的态度不参与其 DO-178C/254 的流程审计。3. 汽车工程师的致命盲区“功耗与剪裁”的诱惑在智能汽车开发中工程师为了节省算力和功耗经常在不同 ASIL 等级的功能间做“剪裁和降额”。比如当电池电量过低或系统过热时智驾域控会主动关闭行车功能仅保留最基本的转向助力。但在 eVTOL 的 DAL A/B 级系统开发中这种“主动放弃功能以保自身”的思路会被局方直接毙掉。不准自杀DAL A 级的动力或者飞控系统哪怕自身已经烧得只剩最后一口气只要上层没有下达绝对的指令它就必须持续输出动力/算力直到飞机触地。航空业的字典里没有“因为过热所以为了保护硬件而主动关机”的逻辑。严苛的“高等级吞噬低等级”法则如果你的智能座舱本应是 DAL D和你的飞控数据显示必须是 DAL A共用了同一个计算平台且没有做严格的内核级硬件分区隔离Time and Space Partitioning那么对不起整个座舱系统的所有软件和硬件都必须按照 DAL A 的变态标准去走全套适航审定。这正是汽车工程师跨界开发时最容易导致项目预算超支、进度无限延误的“天坑”。核心提示Key Takeaway搞懂 DAL A 到 E 的评级就是搞懂 eVTOL 的“技术账本”。汽车工程师必须克制住把所有功能都写成“高大上自动驾驶”的冲动。把不危及生命的功能果断划归为 DAL C/D把真正会导致坠机的功能用最笨、最非相似冗余的办法顶向 DAL A。这种在边界上的精打细算才是一个资深适航系统工程师的真正功力。