DO-254、DO-178C、ARP4754A：三者到底是什么关系

judy 在周二, 06/02/2026 - 08:41 提交

很多 FPGA 工程师刚接触适航开发时，都会把这三份文件拆开来看：

• ARP4754A 是系统工程的事；
• DO-178C 是软件的事；
• DO-254 是硬件的事；
• 我既然是做 FPGA 的，盯住 DO-254 就够了。

这个理解非常常见，也非常危险。

因为一旦你把 DO-254 孤立起来，后面很多事情都会变得解释不通：

• 为什么硬件需求总是“说不完整”？
• 为什么很多 FPGA 行为明明是设计时补出来的，却还要做 justification 和 validation？
• 为什么 verification 做了很多仿真，审查时还是会追着问 traceability？
• 为什么有些需求既像系统需求，又像软件/硬件接口需求，边界总是模糊？

这些问题，单靠 DO-254 本身其实解释不透。因为 DO-254 从来不是一个孤立运作的文件，它是放在更大的系统开发框架里使用的。

先说结论
ARP4754A、DO-178C、DO-254 不是三套平行的独立规则，而是同一条机载系统开发链路上，分别作用于系统、软件、硬件三个层级的设计保证框架。

如果用一句更工程的话说：

ARP4754A 负责把“飞机/系统要实现什么、失效有什么后果、功能怎么分配”讲清楚； DO-254 负责把“分给硬件的这部分功能，怎么通过需求、设计、验证和证据闭环做出来”讲清楚； DO-178C 负责把“分给软件的这部分功能，怎么实现并验证”讲清楚。

而三者真正交汇的地方，不是“都很重要”这么空泛，而是非常具体的两个东西：

• Derived Requirements
• Traceability

也就是说，系统分解到软硬件的过程中，最容易出问题的，恰恰就是：

• 需求有没有真的分干净；
• 新出现的设计决定算不算派生需求；
• 这些需求有没有向上说清楚、向下落实清楚；
• 最终系统、软件、硬件三边是不是还能对上。

对 FPGA 工程师来说，这个视角非常关键。因为 FPGA 在真实系统里，往往不是一个孤立模块，而是处在系统功能、硬件实现、软件接口三者交界的位置。

一、ARP4754A 管的是系统层：先决定“功能从哪里来、分给谁”
先把角色分清楚。

如果没有 ARP4754A 这个系统层视角，DO-254 和 DO-178C 都很容易变成“拿到一堆需求然后自己消化”的局部工程活动。但在适航开发里，事情不是这么开始的。

真正的起点是：

• 飞机级功能是什么；
• 系统要完成什么任务；
• 系统失效会造成什么后果；
• 哪些功能需要冗余、监控、隔离或缓解；
• 这些功能应该分配给硬件、软件，还是系统架构共同承担。

这就是系统层工作的核心。

从工程角度看，ARP4754A 做的是两件大事：

1. 做功能分解和需求分配
它把飞机级/系统级目标逐步往下分解，变成各个系统、设备、软硬件项要承担的要求。

2. 把安全分析和开发分配绑在一起
系统安全评估不是做完就放在那里，而是会直接影响：

• 哪些功能重要；
• 哪些路径不能失效；
• 哪些失效需要监控；
• 哪些功能必须分配到某个特定实现形式；
• 最终软硬件该承担多高的设计保证级别。

这也是为什么前一篇谈 DAL 时，会强调它不是硬件团队自己定的。 DAL 背后本来就是系统安全背景。

对 FPGA 工程师意味着什么？
意味着 FPGA 团队看到的“硬件需求”，本质上大多不是凭空产生的。它们通常来自：

• 系统分配下来的功能需求；
• 系统安全分析衍生出来的约束；
• 与软件、传感器、执行机构、总线接口相关的交互要求；
• 以及一些在系统分解过程中进一步细化出来的实现性需求。

所以如果硬件团队只盯着本地 RTL，而不去理解需求上游来自哪里，后面很容易出现“实现没问题，但系统上下文不对”的情况。

二、DO-254 管的是硬件层：把分配给硬件的功能做成“受控闭环”
理解了系统层，再看 DO-254 就顺了。

DO-254 的角色不是重新做一遍系统工程，而是承接系统分配下来的硬件职责，并把它转化成一个完整的硬件设计保证闭环：

• requirements capture
• conceptual design
• detailed design
• implementation
• validation
• verification
• configuration management
• process assurance
• lifecycle data

它的核心逻辑其实非常明确：

系统把功能分给硬件之后，硬件团队不能只把功能实现出来，而要把“从需求到实现再到验证”的整条证据链建起来。

这里有两个特别值得 FPGA 工程师注意的点。

1. DO-254 强依赖 requirements
硬件设计和 verification 都是围绕 requirements 展开的。如果 requirements 质量差，整个闭环都会被拖垮。

这也是为什么很多人会觉得 DO-254 “很重”，因为它不允许团队长期依赖“设计者自己脑中理解”的隐性共识。

2. DO-254 关注的不只是 test
它把 review、analysis、test 都放进 verification 框架里。换句话说，仿真只是其中一部分，不能替代需求评审、结构分析、时序分析、问题闭环和配置控制。

对 FPGA 项目来说，这个要求非常现实。因为 FPGA 设计里有大量问题，不是等上板才应该暴露的，而应该在更前面通过：

• requirement review
• code/design review
• CDC analysis
• lint/规则检查
• timing analysis
• robustness 验证

提前拦下来。

如果团队已经在尝试把这些活动体系化，那么像 VIGIL-Lint 这类代码规则检查平台，或者 VIGIL-CDC 这类跨时钟域验证平台，就会比较契合 DO-254 这种“前移发现问题、补强 analysis/review 证据”的思路。它们当然不等于合规，但如果使用得当，确实能帮助硬件团队把 verification 从“主要靠 testbench”往更完整的证据闭环推进。

三、DO-178C 管的是软件层：不是硬件版 DO-254，也不能直接套到 FPGA 上
很多做 FPGA 的团队，因为 HDL 长得像代码，很容易不自觉地用软件过程去理解硬件过程。这也是适航项目里一个特别典型的误区。

DO-178C 面向的是软件开发，它的关注点是：

• 软件需求
• 低层/高层需求分解
• 源代码实现
• 软件验证
• 结构覆盖
• 配置管理和质量保证

它和 DO-254 在大框架上有很多相似之处：

• 都依赖过程和设计保证；
• 都使用生命周期管理；
• 都强调 verification；
• 都需要 CM、QA/PA、tool 相关活动。

但它们并不是一回事。

尤其对 FPGA 工程师，最重要的一点是：

不能因为 HDL 看起来像代码，就把 FPGA 开发简单当成软件开发。

硬件和软件在很多细节上差异很大，比如：

• HDL 描述的是并行硬件行为，不是顺序执行程序；
• 硬件验证不仅靠仿真，还要考虑器件级、引脚级、时序级、物理实现后的行为；
• 硬件对环境、器件、老化、物理测试的考虑和软件不同；
• derived requirement 的定义和使用语境也不能简单照搬软件思维。

这一点很关键。如果你用 DO-178C 的思路直接去理解 DO-254，很容易在下面这些地方出错：

• 错把硬件 verification 过度类比成软件测试；
• 错把 derived requirement 理解成“没有上层来源才算派生”；
• 忽视硬件设计中实现形式、物理测试、时序分析、器件行为等独特问题。

所以从系统开发链条上看：

• DO-178C 和 DO-254 是并列的；
• 但它们不是互相替代的；
• 更不是“一个偏软件、一个偏硬件，思想完全一样”。

它们共享的是设计保证哲学，不共享所有细节方法。

四、三者真正交汇的地方：Derived Requirements + Traceability
如果说系统、软件、硬件三份文件之间最容易“断”的地方在哪里，答案通常就是这两个词：

• Derived Requirements
• Traceability

这两个词听起来很抽象，但在项目里非常具体。

1. 为什么会出现 Derived Requirements？
因为系统层分下来的需求，几乎不可能天然就细到足够支撑软件和硬件直接实现。一旦往下做设计，就一定会出现一些新的要求，例如：

• 上电默认值怎么定义；
• reset 释放后第几个周期允许输出有效；
• FIFO 满/空时采取什么保护动作；
• CDC 同步结构选择带来哪些时序约束；
• 软件寄存器访问与硬件状态机的竞争关系怎么处理。

这些要求，很多都不是最初系统需求原封不动写下来的。它们是在软硬件设计过程中逐步显化出来的。

这就是为什么派生需求会成为三者之间的天然交汇点。

2. 为什么 Traceability 这么重要？
因为一旦功能在系统、软件、硬件之间分配，链条就变长了。链条一长，最怕的就是三类问题：

• 需求丢了：系统要的东西，下面没人真正承担；
• 需求变形了：下游实现理解和上游意图不一致；
• 需求自己长出来了：设计者补了很多行为，但没人知道它为什么存在、谁来认可。

Traceability 的价值就在这里：

它不是为了画一张好看的矩阵，而是为了保证系统意图能沿着分解链一路走到实现和验证，并且反过来还能解释清楚。

对 FPGA 团队来说，traceability 最典型的价值体现在：

• 系统需求 → FPGA requirement
• FPGA requirement → RTL / design item
• FPGA requirement → review / analysis / test case
• derived requirement → justification / validation / 上游确认

如果这一条链断了，后面无论仿真做得多漂亮，都很难说设计保证真正闭环。

五、FPGA 在真实项目里，往往正好站在系统和软件之间
这也是为什么 FPGA 工程师比自己想象中更需要理解 ARP4754A 和 DO-178C。

在很多项目里，FPGA 不是“一个纯硬件算法块”那么简单。它经常承担的是系统中的接口和桥梁角色，例如：

• 总线接口控制；
• 传感器数据采集与预处理；
• 与处理器/软件之间的寄存器和中断交互；
• 安全监控、仲裁、门控、切换逻辑；
• 时序协调、通道管理、状态汇聚。

这意味着 FPGA 很多需求天然具有“联合来源”：

• 一部分来自系统功能；
• 一部分来自安全分析；
• 一部分来自和软件之间的接口协议；
• 一部分来自硬件实现约束；
• 还有一部分在设计过程中演化为派生需求。

一个很典型的场景
比如一个 FPGA 负责采集传感器数据、做格式整理，然后通过寄存器和中断机制交给软件读取。

这时你会发现它的需求根本不是单一来源：

• 系统要求采样延迟不能超过多少；
• 安全分析要求在数据异常时必须置标志；
• 软件接口要求某些寄存器位定义必须稳定；
• 硬件实现上又会引入 reset、时钟域、握手时序等额外约束。

如果工程团队没有系统级视角，很容易出两个问题：

1. 硬件觉得“这只是接口细节”，没把它当 requirement 管；
2. 软件觉得“这是硬件内部行为”，也没有明确要求。

最后这些行为就会在 FPGA 里以“设计者默认合理”的形式出现，变成没人真正拥有、却又必须存在的派生需求。

所以很多 FPGA 项目里最危险的，不是功能不会做，而是：

功能的来源、边界和责任归属不清楚。

六、不要把三者理解成“上下级命令链”，它们更像一套协同闭环
很多人会把 ARP4754A、DO-254、DO-178C 理解成一种非常线性的关系：

• 系统写完需求；
• 硬件/软件各自接单；
• 各做各的；
• 最后集成。

这种理解太理想化了。

真实项目里，这三者更像一个不断往返校准的闭环：

• 系统需求往下分；
• 软硬件在实现中暴露出新的细节要求；
• 派生需求再被带回去确认；
• 接口和边界在验证中不断细化；
• 安全分析和架构措施又会反过来影响实现方式。

也就是说，三者之间不是“文件传递关系”，而是“设计保证协同关系”。

这也是为什么高质量项目都会特别重视前端工作：

• 需求分解
• 接口定义
• 派生需求识别
• traceability 建立
• review 与问题闭环

因为这些事情越往后补，代价越大。

如果项目已经进入了更完整的板级/物理验证阶段，那么像 DVS-254 这种面向 DO-254 场景的 FPGA 自动化物理测试方案，也会比较契合这种闭环思路——它关注的不是单次把板子测通，而是把物理测试活动组织成可重复、可回归、可留痕的验证证据。这个话题在后面讲 verification 和 production transition 时会更适合深入展开。

【FPGA项目里的典型场景】
下面几个场景，特别能说明为什么不能孤立理解 DO-254。

场景 1：系统需求写“输出告警”，FPGA 自己补了告警保持策略
系统只说了“异常时输出告警”，但没有明确：

• 告警是脉冲还是电平；
• 保持多久；
• 何时清除；
• 软件是否能读到历史状态。

最后 FPGA 设计者自己定了一个 latch 方案。这时候，这个“保持策略”就很可能已经是派生需求了，不再只是实现细节。

场景 2：软件和 FPGA 对同一个寄存器字段理解不一致
软件认为某状态位是“自动清零”，FPGA 设计实现成“读后清零”，系统文档里又没说清楚。这不是单纯硬件 bug，也不是单纯软件 bug，而是系统分配和接口需求没有闭环。

场景 3：系统要求容错，但没有明确分给谁实现
比如要求“某输入异常时系统保持安全状态”。结果软件以为 FPGA 会做默认保护，FPGA 以为软件会做超时处理。最后谁都做了一半，或者谁都没做完整。

场景 4：traceability 只做到系统到硬件，不做到验证
需求分下来了，硬件也实现了，但 test case、review、analysis 没有按 requirement ID 组织。这时团队会觉得“我们都做过了”，但设计保证视角下，证据链并没有闭环。

小结
这一篇最重要的结论是：

DO-254 不能脱离 ARP4754A 和 DO-178C 单独理解，因为它本来就是系统开发链中的硬件设计保证部分。

再具体一点，可以记住五句话：

1. ARP4754A 负责系统层的功能分解、需求分配和安全背景。
2. DO-254 负责把分配给硬件的功能做成可验证、可追踪、可证明的闭环。
3. DO-178C 负责软件实现和验证，但不能简单拿软件思维套硬件。
4. 三者的真正交汇点，是派生需求和追踪关系。
5. FPGA 经常位于系统、硬件、软件三者交界处，所以特别容易成为需求边界模糊和派生需求高发区。

如果前面三篇解决的是“DO-254 是什么、为什么是 guidance、DAL 为什么重要”，那这一篇真正补上的，就是一个系统级视角：

你做的不是一个孤立 FPGA，而是系统功能链上的一个硬件实现节点。

只有带着这个视角，后面去看 planning、requirements、validation、verification，很多动作才不会变成“为了合规而合规”。

下篇预告
前面四篇，我们一直在搭认知框架。从下一篇开始，系列就会正式进入生命周期主线。

DO-254 为什么不是从编码开始，而是从 Planning 开始
下一篇我们会重点讲清楚：

• 为什么很多项目不是输在 RTL，而是输在一开始没把 planning 做对；
• PHAC、HDP、HVP、HPAP、HCMP 这些计划文件，到底在提前解决什么问题；
• 为什么 DO-254 项目里“先干起来，后面再补”几乎总会付出更高代价。

如果你是做 FPGA 的，这一篇会直接把“为什么 planning 不是形式”这件事讲透。