FAA和EASA同步收紧eVTOL飞控软件认证规则?

近日，一篇题为《间隔仅26天：FAA与EASA同步收紧eVTOL飞控软件认证规则》的文章在行业内传播（下称“网传文章”）。

网传文章称：2026年6月2日，美国联邦航空管理局（FAA）修订了所谓“AC 21.17B附录D”；26天后，欧盟航空安全局（EASA）又修订了所谓“SC-VTOL-026”。两家局方由此统一要求所有eVTOL核心飞控软件达到DO-178C Level A，FAA还要求开发与验证由不同团队完成，EASA则强制采用两套独立飞控计算机构成“双物理通道冗余架构”。

文中表述使用了大量真实的适航术语：DO-178C、Level A、验证独立性、冗余架构、共模失效以及FAA—EASA协调。也正因为如此，它看起来颇具可信度。

由于事关重大，“适航思维”也接到了朋友问询，故就此事进行了核实。

截至2026年7月17日，经逐项检索FAA和EASA官方文件库，网传文章所称的两份文件、其时间线以及主要技术表述，均无法在局方官方文件体系中得到印证。

本文不针对任何发布者，只是借这个话题，把几个经常被混淆的问题放回官方文件里逐项梳理清楚：常见适航文件的编号是如何构成的，软件等级由什么决定，验证独立性到底意味着什么，冗余架构又是不是被“规定”出来的。

还需先澄清文件属性：FAA在AC 21.17-4中明确说明，咨询通告（AC）属于指导性文件，其内容本身不具有独立的法律约束力；EASA的SC-VTOL-02规定适航安全和设计目标，配套符合性方法（MOC）则给出局方可接受的符合性路径。将AC、SC和MOC笼统称为“软件认证规则”，本身就不够严谨。

还需注意，eVTOL是产业和技术语境中的称谓，动力提升航空器（powered-lift）则是FAA法规体系中的航空器类别，两者并非天然一一对应。本文讨论AC 21.17-4时，均以该通告所述的特定powered-lift适用范围为限。

FAA没有所谓“AC 21.17B附录D”

FAA目前针对动力提升航空器（powered-lift）型号合格审定发布的咨询通告是：

AC 21.17-4，Type Certification—Powered-lift

FAA官方咨询通告目录目前将AC 21.17-4列为Active，发布日期为2025年7月18日。该通告的官方目录说明及所链接文件均表明，适用于其所述特定动力提升航空器的适航准则位于Appendix A，即附录A。文件同时说明，附录A所列准则可以作为依据14 CFR §21.17(b)开展特定动力提升航空器型号合格审定的一种可接受方式。

这里很容易发生一次“编号错位”。

在FAA现行咨询通告目录中，21.17主题下列出的文件包括：

• AC 21.17-1A，飞艇；
• AC 21.17-2A，滑翔机及动力滑翔机；
• AC 21.17-3，甚轻型飞机；
• AC 21.17-4，动力提升航空器。

也就是说，该系列采用的是“21.17-序号”的文件编号结构，其中两份已带修订版字母，如AC 21.17-1A和AC 21.17-2A。至于“§21.17(b)”中的“(b)”，则是法规条款的款项标识，不是咨询通告编号的一部分。

因此，把14 CFR §21.17(b)写成“AC 21.17B”，再配上一个并不存在的“附录D”，很可能是把法规条款号、咨询通告编号和文件附录三套概念混在了一起。

截至核查日，FAA官方咨询通告目录中没有“AC 21.17B”，也没有网传文章所称的“2026年6月2日AC 21.17B附录D修订版”。

EASA也没有所谓“SC-VTOL-026”

EASA现行的小型载人VTOL专用条件为：

Special Condition for small-category VTOL-capable aircraft，SC-VTOL-02，Issue 2

其文件封面分别标明：

• Doc. No：SC-VTOL-02；
• Issue：2；
• Date：10 June 2024。

也就是说，“SC-VTOL-02”是文件编号，“Issue 2”是版本状态，两者在官方文件中分别列示。

EASA在“Special Condition for VTOL and Means of Compliance”官方页面同时列出了与该专用条件配套的符合性方法文件，包括：

MOC SC-VTOL——首次发布的符合性方法，官网Reference栏亦标注为MOC-1；以及MOC-2、MOC-3、MOC-4和MOC-5。

其中：

• MOC-4 SC-VTOL Issue 2于2025年7月11日最终发布；
• MOC-5 SC-VTOL Issue 1于2025年7月18日发布征求意见稿；
• 截至核查日，MOC-5在官网仍标识为Proposed，意见征集已结束。

EASA官方Reference栏列出的文件序列中，并没有“SC-VTOL-026”。

从命名逻辑看，EASA官网保留了早期SC-VTOL-01的咨询和意见处理记录，现行专用条件则为SC-VTOL-02。将其写成“SC-VTOL-026”，既无法对应现行文件编号，也无法对应Issue或MOC发布序列。

因此，网传文章所称“EASA在FAA修改文件26天后修订SC-VTOL-026”，没有相应官方文件支持。

2026年EASA确有VTOL相关文件，但与飞控软件无关

为了排除“可能只是文件名称写错了”的情况，还可以反向检查EASA在2026年年中前后究竟发布了什么。

在EASA官网“VTOL Aircraft（>2 lift/thrust units）”产品标签页中，与网传时间窗口最接近的2026年新增项目是：

CM-21.A-P-002，Approval of Flight Conditions for development flights of a new small aircraft type

该文件于2026年3月31日启动征求意见，意见征集于2026年6月3日结束。其内容是澄清新型小型航空器在概念验证、设计改进和型号研制试飞阶段，如何制定并批准特许飞行所需的飞行条件。适用产品可以包括CS-23飞机、小型旋翼航空器、VTOL航空器和轻型无人机，但其主题属于初始适航程序和研制试飞管理，并非飞控软件研制保证要求。

该日期与网传文章时间线中的“6月2日”“26天后”等表述相近，但现有证据不足以说明两者之间是否存在关联，本文不作推断。

可以确认的是：2026年EASA这项与VTOL有关的公开动作，既不是SC-VTOL修订，也没有新增DO-178C Level A或双飞控计算机要求。

是否要求所有eVTOL核心飞控软件达到Level A？

作为一条普遍适用的要求，这一说法并不成立。

FAA AC 21.17-4附录A的PL.2510规定，航空器设备和系统的设计应在失效状态严重程度与平均发生概率之间建立合理的反向关系：

• 灾难性的（catastrophic）失效状态应当极不可能（extremely improbable）；
• 危险的（hazardous）失效状态应当极微小（extremely remote）；
• 较大的（major）失效状态应当微小（remote）。

这是一组航空器和系统级安全目标，不是一张可以脱离系统安全性评估、直接套用到全部软件模块上的等级对照表。

FAA于2018年生效的Order 8110.49A《Software Approval Guidelines（软件批准指南）》明确指出，软件等级应由系统安全性评估确定；软件规模、复杂性、系统功能和新颖性等因素，主要影响局方介入程度，而不是替代安全性评估直接决定软件等级。

EASA的逻辑同样如此。MOC SC-VTOL Issue 2明确规定：

• 研制保证等级（DAL）由系统安全性评估过程确定；
• 功能或项目的研制保证等级，取决于其所参与失效状态的分类；
• 对软件研制保证，EASA接受AMC 20-115及ED-12/DO-178作为符合性方法。

因此，承担灾难性失效相关功能的软件项目，经过功能危险性评估、安全需求分配和系统架构分析后，确实可能需要满足DO-178C Level A。

但这不等于：

• 一架eVTOL上的所有软件都是Level A；
• 所有被企业称为“核心飞控”的软件天然都是Level A；
• 所有飞控分区、监控功能、显示功能、维护功能和支持软件必须采用同一软件等级。

“核心飞控软件”不是一个可以直接决定软件等级的正式适航分类。真正决定等级的是：该软件项目参与了什么功能，其错误可能对哪些失效状态作出贡献，系统架构又如何分配、隔离和缓解这些影响。

“写代码的人和检查代码的人必须属于两个独立团队”吗？

网传文章把DO-178C中的验证独立性，理解成了组织架构上的强制隔离。

这两者并不等价。

FAA于2017年7月21日发布AC 20-115D，认可ED-12C/DO-178C及其相关补充文件。EASA随后通过2017年10月24日的ED Decision 2017/020/R发布AMC 20-115D。两家局方文件基于联合提案，技术路径保持协调。这一体系已实施多年，并非2026年针对eVTOL新增的要求。

DO-178C确实要求，对于相应软件等级下标注为需要独立性的特定验证目标，相关验证活动由具有所需独立性的人员或工具完成。其核心不是划分两个组织，而是让验证责任与被验证成果的相应开发责任相分离，避免“自己证明自己正确”。

FAA发布的《DO-178B/C Differences Tool》给出了一个具体例子：针对低层需求编写的测试用例，不能由编写相应低层需求代码的同一个人完成。

这里的关键限定是“同一个人”和“相关活动”，而不是“必须来自两个完全独立的公司、部门或组织”。

在实际项目中，申请人可以通过职责分工、评审权限、流程控制、验证工具安排、质量保证和配置管理等方式建立所需独立性。对于不同软件等级和不同验证目标，所需独立程度并不完全相同。局方还会结合软件计划、组织安排、过程实施和符合性数据判断该安排是否可以接受。

因此，把DO-178C概括成“写代码的人和检查代码的人不能是同一拨人”，尚可视为一种非常粗略的通俗化解释；进一步写成“开发和验证必须由两个独立团队完成”，则已经超出了公开适航文件能够支持的结论。

EASA是否强制采用“两套独立飞控计算机”？

并不存在这样一刀切的条款。

SC-VTOL-02第VTOL.2510(a)(1)款规定：

每一灾难性失效状态必须极不可能，并且不得由单一失效导致。

此外，结构和总体设计原则中的VTOL.2250(c)还要求，申请人必须防止单一失效对航空器造成灾难性影响。

这些条款规定的是必须达到的安全结果，而不是预先指定的硬件数量。

EASA在《Means of Compliance with the Special Condition VTOL》（MOC SC-VTOL Issue 2）的开篇即说明，SC-VTOL采用安全目标和设计目标导向的方法，以避免通过审定标准预先规定具体设计方案；配套MOC也要为不同系统架构和设计概念保留足够灵活性，申请人可以针对具体设计提出替代符合性方法。

当然，这种灵活性不等于降低要求。

对于电传飞控系统，EASA特别要求关注共模／共因失效和研制错误。MOC 4 VTOL.2300指出，不应仅依靠研制保证和质量保证来缓解可能造成飞控功能完全丧失的共模失效或错误；还应尽实际可行的程度，提供能够形成必要功能独立性或项目研制独立性的架构缓解措施。文件同时提到，指令／监控架构、控制律监控等可以作为相关缓解手段。

这意味着申请人可能采用：

双通道或多通道计算平台、指令／监控架构、异构硬件或软件、独立传感器、电源和执行机构、分区、故障监控、表决、重构或降级控制等不同组合。

具体采用什么架构，取决于航空器构型、功能分配、安全性评估、共模／共因分析以及申请人与局方商定的符合性方法。

“两套独立飞控计算机”可能是某一型号采用的设计方案，却不是EASA为所有eVTOL规定的唯一答案。

“完整可追溯证据包”是真的，但不是2026年的新闻

网传文章还称，EASA新增要求申请人提交从需求到测试全过程的可追溯证据包。

可追溯性本身确实是机载软件研制保证的核心内容，但它不是2026年突然增加的新门槛。

FAA Order 8110.49A列举的软件审查抽样内容包括：

从系统需求到软件需求、软件设计、源代码、目标代码、测试用例和程序，再到测试结果的连续可追溯关系。

DO-178C体系中的软件生命周期数据也长期包括软件计划、需求数据、设计说明、源代码、可执行目标代码、验证用例与程序、验证结果、配置索引、问题报告以及软件完成情况综述等。

换句话说：

可追溯性是真的，“2026年间隔26天突然加码”则找不到依据。

FAA和EASA确实在加强合作，但合作声明不是飞控软件新规

根据EASA发布的会议页面和联合声明，2026年FAA—EASA国际航空安全会议于6月16日至18日在美国弗吉尼亚州尚蒂伊（Chantilly）举行。双方于6月18日发布联合声明，重申在航空安全、信息共享、新技术批准、自动化驾驶舱、运行数据和国际协调等方面深化合作。

声明中确有协调先进航空技术审定路径、减少重复工作和促进安全创新等内容。

但会议声明并没有发布所谓“AC 21.17B附录D”，也没有修改“SC-VTOL-026”，更没有宣布所有eVTOL飞控软件统一为Level A或强制采用双物理通道计算机。

监管合作是真实背景，网传文章所描述的两次具体规则修改则没有相应文件支持。

为什么这类消息容易让人相信？

值得讨论的不是某一篇文章，而是这类信息的共同特征：真实术语与无法核实的“事实”拼接在一起。

DO-178C是真的，Level A是真的，验证独立性是真的，飞控冗余和共模分析也是真的，FAA与EASA正在协调先进航空技术审定同样是真的。

问题往往出在三次概念替换：

第一，把法规条款号替换成了文件编号，将§21.17(b)拼成“AC 21.17B”。

第二，把航空器级安全目标替换成了唯一设计方案，将“灾难性失效不得由单一失效导致”改写成“必须采用两套独立飞控计算机”。

第三，把实施多年的研制保证要求替换成了突发政策变化，将软件等级分配、验证独立性和可追溯性包装成2026年新增门槛。

每一次替换都只挪动了半步，单独看都貌似合理，叠加起来就变成了一场并不存在的“监管地震”。识别它们不需要特别的技巧，只需要把每一个编号放回局方文库里检索一次。

eVTOL飞控审定真正需要关注什么？

澄清网传消息，并不意味着eVTOL飞控软件审定要求宽松。

恰恰相反。EASA对飞控系统的定义包括驾驶员操纵装置、计算机、线路、执行机构、传感器以及控制航空器姿态、速度和航迹所需的全部要素；升力／推力单元在功能上还可能构成飞控系统的执行机构。

对于高度依赖增稳、控制分配和分布式电推进的航空器，真正需要解决的核心问题包括：

• 航空器和系统级功能危险性评估；
• 失效状态分类及FDAL、IDAL分配；
• 单点失效、潜在失效及失效组合；
• 共模／共因分析和级联失效；
• 软件和复杂电子硬件的研制错误；
• 传感器、计算平台、电源和执行机构之间的独立性；
• 飞控系统降级模式及持续安全飞行与着陆能力；
• 需求、设计、实现、验证和配置数据的闭环可追溯性。

EASA在MOC SC-VTOL Issue 2的MOC VTOL.2510“Common mode considerations”中还特别指出，即使项目按IDAL A研制，也不能直接假定其不存在研制错误；同一错误仍可能同时影响多个相同项目，因此必须纳入共模分析。

这些才是eVTOL飞控审定真正困难的地方。

结语：适航，专业看门道

截至2026年7月17日，没有官方文件表明FAA和EASA在2026年6月间隔26天，分别发布了网传文章所称的两份文件。

同样没有文件表明双方新近统一规定：

• 所有eVTOL核心飞控软件一律达到DO-178C Level A；
• 软件开发与验证必须由两个组织上独立的团队完成；
• 所有eVTOL必须采用两套独立飞控计算机。

本文否定的是网传文章所称的统一、普遍且在2026年新增的要求；这并不否定某一具体型号可能基于其审定基础、系统安全性评估及与局方商定的符合性方法，采用Level A软件、独立验证安排或特定冗余架构。

真实情况是，FAA和EASA长期采用基于失效后果、系统安全性评估和研制保证的审定逻辑；双方也一直在推进软件标准和新型航空器审定方法的协调。

但协调不等于一刀切，安全目标不等于指定架构，验证独立性也不等于组织必须分家。

面对所谓“法规突变”“认证门槛突然提高”的消息，至少应核对五项信息：

文件编号、发布机构、版本状态、发布日期、具体条款位置。

适航文件可以复杂，但不会神秘。

一项连正式文件编号都无法在局方文库中找到的“新规”，无论堆叠了多少Level A、冗余、独立验证和可追溯性等专业词汇，都不宜成为企业技术决策、项目计划或投资判断的依据。

欢迎关注和转发

点个赞、点个在看，为你想读的文章投票