航电需求验证实战：从V模型定位到DO-178C闭环追溯

前阵子和一个做航电系统的老同事吃饭，他正被"需求验证"四个字折腾得够呛：项目快走到适航审查阶段了，核查证据时发现十几条需求的验证证据要么缺、要么追溯链断裂，只能连夜补验证、补记录。这个场景在航电开发里实在太典型了。很多人把需求验证理解成"最后跑一遍测试给审查代表看"，但在真正的工程体系里，需求验证是一条贯穿系统需求、软件需求、硬件需求，直到整机验证的主线。这篇文章我不打算讲学院派理论，就讲我在航电项目里怎么做需求验证：先厘清验证到底验证的是什么，再看验证方法怎么选，接着讲如何把"每条需求都有闭环证据"管理起来，最后聊几个我亲眼见过、也亲手处理过的翻车现场。

1. 先在V模型里找对位置：需求验证究竟是干什么的

1.1 验证与确认：一对爱被混淆的兄弟

英语里Validation和Verification都经常被翻译成"验证"，但在航电开发里这两个概念的差别足以影响整个项目的工作量。

Verification（验证）回答的问题是："我们把需求实现对了吗？"它是针对实现体开展的证明活动——评审、分析、测试，都是为了证明输出的产品确实符合需求规格。Validation（确认）回答的问题是："我们定下的需求本身是对的吗？"它发生在更早的阶段，关注需求的完整性、正确性、一致性和可实现性。

举个例子：某飞控系统需求写着"当空速低于失速速度时触发失速告警"。验证要做的是检查最终代码确实实现了"空速低于失速速度触发告警"；而确认要做的是问问气动团队：这个失速速度怎么定义？在哪些飞行阶段生效？迎角限制是否参与其中？如果需求本身定义错了，验证做得再严谨也是南辕北辙。

在日常中文语境里，"需求验证"往往被宽泛使用，既包含需求本身的确认，也包含对需求实现的验证。我自己的做法是：流程上把这两个动作严格分开——需求确认环节要评审需求是否完整、一致、可实现；需求验证环节再发起针对实现体的评审、分析、测试。两者经常串在一起执行，但证据要能分开，审查代表问到哪一根线都接得上。

1.2 需求验证挂在V模型的哪些层

航电开发里，需求验证不是一个孤立的阶段，它挂在V模型的每一层右侧。

V模型左侧是从上到下的分解过程：飞机/系统级需求 → 系统架构设计 → 软件/硬件需求 → 软件详细设计 → 编码；右侧是从下到上的验证过程：单元测试 → 软件集成测试 → 软硬件集成测试（HIL） → 系统级验证 → 飞机级验证。每一层左侧的"需求"都要对应右侧的"验证活动"，这就是所谓"每一个需求都有回音"。

具体到航电开发遵循的标准族：

• 系统级：ARP4754A（民用飞机与系统研制）定义系统级需求验证与确认活动。
• 机载软件：DO-178C（机载系统和设备合格审定中的软件考虑）定义软件生命周期里的验证过程。
• 机载电子硬件：DO-254（机载电子硬件设计保证指南）定义硬件需求和验证。

这三份标准相互咬合。系统需求下放到软件团队成为软件需求，软件团队按DO-178C做软件层面的验证；系统团队在HIL台架或铁鸟试验台上做软硬件集成的系统级验证。需求验证的活动不是从编码完成后才开始，需求评审本身就是一种验证/确认活动，设计评审也是。

1.3 为什么航电领域尤其较真

很多人不理解航电开发为什么对验证较真到近乎苛刻。因为失效后果不可接受。

航电系统的安全等级按DAL（设计保证等级）从高到低分为A、B、C、D、E五级：DAL A对应灾难性失效（可能导致飞机失事）；DAL B对应危险性失效（可能严重降低飞机能力或给机组造成过大负担）；DAL C对应较大影响；DAL D对应较小影响；DAL E无安全影响。我做过最严格的是一个DAL A模块，它的一条简单告警逻辑，要求验证团队不仅做需求覆盖，还要做MC/DC结构覆盖率，且验证人员必须与开发人员独立。

适航审定环节里，局方审查代表看的就是这些验证证据——需求编号、验证方法、验证环境、执行结果、覆盖报告。他们最常做的动作是随机抽一条需求，让你马上给出对应验证证据。你给不出，整个包件可能被拒收。

2. 验证方法不是拍脑袋选的：四类手段的打法与取舍

DO-178C明确认可的验证手段主要有评审、分析、测试三类，DO-178C还引入形式化方法作为可选手段。除此之外，我在实际项目中大量使用建模与仿真作为辅助验证手段。它们各有适用场景，不能互相替代。

2.1 评审（Review）：入口处的第一道闸口

评审是成本最低、应用范围最广的验证手段，适用于所有产出物：需求规格、设计文档、测试用例、验证结果。

需求层面的评审最该盯的是"可验证性"。我做需求评审时强制要求每一项需求过这条检查：有没有可量化的指标？有没有明确的输入条件？有没有定义容差边界？有没有限定验证环境？如果一条需求写着"系统应在合理时间内完成自检测"，那就是评审不过关的典型——什么叫合理时间内？

需求评审的实操做法：提前把检查单发给评审人员，会上只讨论问题不打太极。评审记录必须留痕：评审日期、评审人员、通过的结论或问题清单。这些本身就是验证证据。我的经验是，把"可验证性"作为强制检查项之后，需求质量明显提升，很多原本要在测试阶段才暴露的问题，在评审阶段就被拦下来了。

2.2 分析（Analysis）：不跑代码也能出证据

分析是通过演绎推理或数学计算来证明需求被满足。它特别适合那些"跑测试跑不全"的需求。

典型场景：

• 性能预算：验证处理器在最坏情况下的负载率不超过某阈值。这种需求靠测试很难覆盖所有最坏情况组合，一般用WCET（最坏执行时间）分析加少量代表性实测。
• 时序需求："系统端到端响应时间不超过50ms"，分析数据流路径上每一级的处理时间，累加并加余量。
• 精度需求：航电系统里常见数据链路的精度分析，浮点误差传播计算。
• 安全性需求：结合FMEA（失效模式与影响分析）、故障树分析，验证安全需求如"单点失效不应导致灾难性后果"。

分析报告的套路要固定：引用需求编号、说明分析方法和输入假设、推演过程、给出结论（满足/不满足/需修改）。写分析报告最忌讳的就是藏着输入假设不写。审查代表特别喜欢问"你的分析假设从哪来"，假设来源说不清，整份报告的可信度就塌了。

2.3 测试（Test）：最被依赖其实最难做对的方法

测试是大家最熟悉、也最容易被做坏的验证方法。DO-178C的核心要求是"基于需求的测试"（Requirements-Based Testing）：每个测试用例必须对应一条或多条需求，测试的目的是判断需求是否被满足，而不是单纯追求覆盖率数字。

测试分三个层级：

• 软件单元测试：针对最底层软件需求，验证单个函数/模块行为。
• 软件集成测试：验证模块之间的接口、时序、数据交互。
• 软硬件集成测试：在目标机上验证软件与硬件协同行为，通常用HIL台架。

单元测试可以在宿主机（PC）上跑，但一旦涉及中断、时序、外设交互，就必须在目标机或等效环境验证。很多团队在这个问题上栽过跟头——见后面第4章的翻车现场三。

测试用例设计的基本功是：正常路径 + 边界值 + 异常路径。航电系统坚决不能只测"好天气"路径。一条需求写着"收到传感器无效数据时不应触发告警且应记录故障标志"，你得专门设计无效数据注入场景，让传感器输出超界、全零、乱码、时序错乱，看系统行为是否符合需求。只测正常数据，等于这条需求没被验证。

2.4 建模与仿真（Modeling/Simulation）：航电特有的加速器

航电开发里建模与仿真是非常常见的辅助手段，按抽象程度从高到低有MIL（模型在环）、SIL（软件在环）、HIL（硬件在环）。

• MIL：需求阶段的逻辑快速验证，直接在被仿真模型上跑场景，适合验证控制逻辑、状态机、告警逻辑。
• SIL：代码编译运行在PC模拟环境，与仿真模型交互，可以大批量跑回归。
• HIL：把真实硬件接到台架上，用仿真器模拟传感器和执行器信号，验证软硬件协同和系统级需求。

我的用法总结：MIL和SIL主要用于需求确认——当评审会上大家为一个逻辑问题争得面红耳赤时，与其吵一小时，不如搭个模型跑两个场景，答案当场见分晓。HIL则偏向系统级需求验证，能在实验室里提供相当接近真实飞机环境的证据。

但要注意边界：仿真结果不能自动等同于正式验证证据。如果要用SIL结果替代目标机测试，必须做测试环境等价性论证，必要时涉及工具鉴定。稳妥做法是：把仿真用于分析、辅助评审、需求确认；把目标机测试用于正式验证证据。哪些证据用仿真、哪些用目标机，必须在验证计划里写清楚。

2.5 方法选择矩阵：不同需求该用哪些手段组合

这个矩阵不是死的，但至少要保证每条需求都有明确的主验证手段。我见过有些项目不愿意填矩阵，总说"到时候都测"，结果到审查阶段发现有些需求根本没法测——比如"系统应具备在失去所有外部电源时保存关键数据的能力"，这种需求不开专项分析，靠常规测试根本验不出来。

3. 让每条需求都有回音：验证闭环的工程化

3.1 先用文件把"验证什么、怎么验"固定下来

工程化的第一步是文件化。DO-178C要求先制定软件验证计划和规程（Software Verification Plan and Procedure），再在项目过程中记录软件验证结果（Software Verification Results）。

验证计划包含：验证对象范围、采用的方法矩阵、验证环境（宿主机/目标机/HIL）、工具清单、人员角色与独立性声明、通过/失败判定准则、交付物清单。

验证结果是逐条需求的验证证据记录，一般以"验证矩阵"为核心呈现。我常年在项目里维护一张核心表——行是需求条目，列是验证方法、验证用例编号、执行状态、结果结论、证据存放位置。

这里有一个血的教训：验证矩阵不是最后补的。正确做法是从需求基线确立那天开始建，每完成一个验证活动立即往里填一行。最后补出来的矩阵一定会被审查代表问出大量细节漏洞：当时用哪个版本代码跑的？执行人是谁？环境配置记录在哪？这些信息当时不记，事后根本补不出来。

3.2 双向追溯：需求链不能被写断

需求验证闭环的核心是追溯性。航电开发里要求双向追溯：

• 正向追溯（Forward Traceability）：高层需求 → 低层需求 → 设计 → 代码 → 测试。用于保证每条需求都被实现并被验证，没有"孤儿需求"。
• 反向追溯（Backward Traceability）：每个测试用例 → 对应需求；每段代码 → 对应需求。用于防止"镀金"（实现了需求之外的无用功能）和"幽灵测试"（没有需求支撑的用例）。

工具方面，大项目常用DOORS、Jama Connect、IBM ELM这类需求管理平台，中小项目用Excel也能做，关键是每条需求必须有唯一ID，且每次需求变更后要重跑一次追溯检查。我见过太多项目，需求改了，设计跟着改了，但测试用例和验证矩阵没同步更新，审查代表一深挖，链条就断在验证这一环。

审查代表最爱做的一件事：随机抽一条需求，让你30秒内给出对应验证证据。你做不到，他就有理由质疑整个验证体系的可信度。这不是吓唬人，是真实发生过的事。

3.3 覆盖率：需求覆盖只是及格线，结构覆盖才是深水区

说到覆盖率，很多非航电领域的人只会想到需求覆盖率——每条需求被至少一个用例覆盖。航电开发除了需求覆盖率，还要求代码结构覆盖率，这是很多人第一次接触DO-178C时被震到的地方。

DO-178C对结构覆盖率的最低要求按DAL等级区分：

MC/DC（修正条件判定覆盖）是DAL A级别的硬骨头。它的含义可以这样理解：每个布尔条件单独翻转时，必须独立地影响整个判定的结果。

举个实际例子：某告警判定是"允许告警 = 传感器有效 AND 超限"。MC/DC要求你的测试用例能让"A从真变假、B不变时，结果从真变假"，也得能让"B从真变假、A不变时，结果改变"。这样每个条件都被证明"自己说了算"，而不是几个条件抱团糊弄过一个组合用例。

结构覆盖率的坑在于：覆盖率工具本身可能需要做工具鉴定（比如DO-330体系下的TQL等级），而且覆盖率数据必须与测试用例版本严格对应。项目后期经常发生的噩梦是：代码改了一行，你重新跑完全部用例，覆盖率报告显示95%，但你根本说不清那5%为什么没覆盖——这5%可能就是新增代码里的关键分支。所以我的习惯是每次回归后都重新收集覆盖率数据，绝不沿用上一次的报告。

3.4 发现问题后怎么关：问题报告、回归与变更验证

验证不是"跑完就绿、记录就完"。验证中发现的任何问题都要进入问题报告流程。

航电项目的问题报告通常包含：缺陷现象、复现步骤、分析过程、根因分类（需求问题/设计问题/代码问题/测试用例问题/验证环境问题）、影响范围评估、修复措施、回归验证结果。

容易被忽视的问题类别是"测试用例自己写错了"。我在多个项目里发现，验证失败里相当一部分不是产品缺陷，而是用例设计错误或测试环境配置错误。这类问题同样要走问题报告流程，但要正确归类，不能糊里糊涂地算成产品缺陷。

变更后的回归策略也要讲究。不是把所有用例从头到尾重跑一遍就叫回归，而是要基于影响分析确定受影响的模块和相关需求，先跑关联用例，再决定是否全量回归。高DAL项目的回归范围和理由要写进验证结果，不能只写"已回归"三个字。

还有一条心态上的底线：验证阶段发现fail是健康的信号。适航文化里，隐瞒失败、篡改证据、为了让用例变绿而修改测试期望值的代价，远超老老实实返工的代价。哪个环节出问题都有解决路径，唯独掩盖问题没有出路。

4. 真实项目里的错题集：需求验证的典型翻车现场

4.1 翻车现场一："需求写得很完整"但每条都不可验证

某航电显示系统项目，需求文档厚厚一摞，评审时测试工程师却苦不堪言。因为里面充斥着这种条目："系统应在合理时间内显示主要飞行参数。"

什么叫合理时间？没有数值，没有统计口径，没有验证方法。测试工程师拿到这种需求根本没法设计用例——无论测出什么结果，开发组都能说"这个时间我认为是合理的"。

修复方案是把这条需求改写成："系统收到有效数据帧后，应在1000ms内完成主飞行显示器所有动态参数更新，在HIL环境下连续测量100次，99%样本满足要求。"量化指标、限定条件、验证环境和统计标准一步到位，测试用例自然就好设计了。

这件事给我的教训是：需求验证的第一道工序在需求书写阶段就已经开始了。可验证性不是评审时的补充要求，而是需求的出生属性。现在我带团队做需求评审，第一条检查项永远是"这条需求的通过/不通过判据客观吗"。

4.2 翻车现场二：测试用例照抄需求措辞，自以为覆盖了

某燃油管理软件有一条需求："当计算的剩余燃油量低于1000磅时，触发低油量警告。"开发团队设计的测试用例是："设置剩余油量500磅，执行任务，确认警告被触发。"

用例执行结果全绿。但审查代表问了三个问题就哑火了：

• 剩余油量正好等于1000磅时触发还是不触发？边界值有没有验？
• 油量传感器信号丢失时应该怎么处理？需求里有没有定义？
• 警告在油量恢复后应该清除还是保持？清除条件是什么？

这个案例是典型的"翻译需求"式测试。基于需求测试不是把需求句子换个格式写进用例，而是理解需求背后的测试意图，再设计出能覆盖正常、边界、异常三种场景的用例。

当时我们补的用例包括：1005磅不触发、1000磅按需求定义的行为触发、995磅触发、传感器无效数据帧触发故障处理逻辑、警告触发后油量恢复至1200磅时警告状态迁移等。一套补下来，才算是真正完成了这条需求的验证。

4.3 翻车现场三：宿主环境全绿，目标机上一跑就花屏

某航电显示控制系统的软件在PC模拟环境里所有单元测试和集成测试全部通过，测试报告漂亮得很。结果拿到目标机上一做软硬件集成测试，字符画面错位、刷新率不足、偶发卡顿。

追究根因，两条：

• 字节序差异和显示缓存对齐方式不同。PC是小端，目标机是大端，数据格式不对齐导致显示数据错误。
• 目标机CPU定时器精度和中断延迟特性与PC不同，导致刷新间隔不稳定。

修复方案不是把全部用例都搬到目标机——那样测试成本太高，而是做测试分层：

• 纯逻辑类需求（计算、状态机、数据变换），在宿主机充分回归。
• 与硬件强相关的需求（中断处理、时序、外设交互、端到端延迟），划到目标机测试或HIL台架验证。
• 不同环境之间做等价性论证，写明比较维度：编译器版本、浮点精度、字节序、存储器布局、定时器来源、外设模拟程度。再抽一条"金标准"用例在两个环境各跑一遍，比对结果。

这件事让我养成了一个习惯：项目计划阶段就给"目标机测试"留足时间预算。宿主测试做得再爽，真机会教做人。硬件台架排期是稀缺资源，早占坑，别等代码写完了才发现台架被别的项目借走了。

4.4 翻车现场四：DAL A的独立性要求差点卡死项目

按DO-178C，DAL A软件的验证要求具备独立性——验证活动不能由参与开发的人员独立完成。这个要求在纸面上很清楚，落地时经常引起组织层面的碰撞。

我之前参与的一个DAL A模块，团队总共不到十个人，既有开发又有验证。要做好独立性，人数和分工就捉襟见肘。项目经理一开始拍板说"先做完再分人补验证记录"，被我在评审会上否了——事后补记录存在真实性风险，一旦审查代表问了执行细节就露馅。

最终方案几经调整：

• 验证工程师独立于开发工程师汇报线，测试设计和结果分析都由验证方主导。
• 验证团队提前介入需求评审，不等到代码完成才"突发检查"。
• 评审和测试记录全部签字留痕，过程数据完整归档。

这样做下来，进度看着慢了，但审查阶段反而顺利。被反复挑战的点恰恰是"验证人员你认识开发人员吗？你们怎么确保独立判断"——有完整的过程记录和决策依据，这些问题都不难答。

供应链场景里的版本更扎心。给OEM（主机厂）做Tier1（一级供应商）交付时，对方要求需求验证证据包完整、可追溯。一次交付中被拒收，原因是几十条需求的验证矩阵里"验证结果"一栏空着，返工了一个多月才补齐。这种问题最好在项目启动的对齐会上就把验证矩阵模板统一好，别等交付前才拉通格式。

5. 想少走弯路，我的需求验证实操清单

做了这么多年航电，我把需求验证的实操经验压缩成五条清单，供同行参考。

1. 需求条目化的第一天就打"可验证性"标签。每条需求必须能回答"怎么判通过"——条件是什么、数值是多少、环境是什么、时限是什么。答不出来就不准入库评审。

2. 验证矩阵当周建、每周更，绝不攒到审查前补。补出来的矩阵会暴露大量细节漏洞：当时用的软件版本号是多少？执行人是谁？环境配置有没有记录？这些信息当时不记，事后补不出来。

3. 测试用例评审时，重点看"覆盖的是意图还是字面"。检查清单里加一项：用例是否包含边界值、异常输入、时序变化三个维度的推演。没有这三类用例的需求验证，基本是无效验证。

4. 给"目标机测试"留足时间预算。宿主环境能解决大部分逻辑验证，但硬件强相关需求必须在目标机或HIL上验。台架和真机资源都是稀缺品，从计划第一天就把排期写进去。

5. 缺陷流程别图省事。问题报告、根因分类、回归理由、关闭条件都写清楚。审查代表最常挑战的就是"验证失败之后你们做了什么"，这部分的记录质量决定了整个验证体系的可信度。

做航电需求验证这些年，我的一个朴素体会是：验证做得好的项目，前期看着慢，后面反而快；验证做得差的项目，前期疯狂赶，后期都在还债。需求验证不是一个收尾动作，它从需求诞生那天就开始了。你现在给每条需求写下的验证判据越实在，后面少加的班就越实在。