1. 先把适航符合性这层窗户纸捅破机载软件适航符合性这个话题圈外人听着像天书圈里人一提起多半也是一脸苦笑——这几个字背后是几十项需要逐一交代清楚的目标、成堆的生命周期数据以及以年计的审定沟通。前阵子在一次行业技术交流上有位做飞控软件的兄弟半开玩笑地说我们写的不是代码是证据。这句话其实把它说透了。这里说的机载软件指的是装上飞机之后会参与飞行控制、航电显示、通信导航、发动机管理等功能的软件它和地面上的普通应用软件完全是两套玩法。适航符合性说白了就是要向适航审定方证明这套软件在预期的运行环境和失效场景下不会带来超出可接受范围的风险。它不是一次性的验收测试而是一整套从需求说起、贯穿开发全过程、最终形成可追溯证据链的活动。适合读这篇的人大致有三类刚进入航空软件领域、被符合性三个字搞得一头雾水的工程师做系统或软硬件接口、需要理解软件侧审查逻辑的人还有准备参与审定沟通、想提前摸清门道的项目管理者。下面我尽量用大白话把底层逻辑讲清楚也会给出一些实操层面的细节和踩坑经验。1.1 机载软件为什么不能像硬件那样直接做实物试验硬件有个天然优势——看得见摸得着能做疲劳试验、能测寿命、能拆解失效件做分析。软件不一样它没有物理磨损你没法通过跑到一定小时数就宣布它可靠。软件的失效几乎全部来自逻辑缺陷需求写漏了、代码写错了、时序设计有漏洞。这些缺陷不会因为多跑几遍就消失反而可能在某个特定输入组合下突然冒头。所以机载软件的符合性从来不是测够了就行而是要在设计阶段就控制缺陷的进入在验证阶段把缺陷尽量找出来还要能证明找的过程本身是可信的。这就是为什么软件符合性强调过程——你没法只靠最终产品判断软件够不够好只能靠过程的可信度来背书。还有一个现实因素软件几乎可以零成本地被修改今天改一行代码明天就可能是另一个产品。正因为变化太容易才需要一套严格的构型管理和更改控制让每一次改动都能追溯到需求、追溯到验证证据。这一点和硬件的改了要重新做试验逻辑是相通的只是软件把它做成了流程约束。1.2 软件符合性的本质拿过程和证据说话很多新手会问飞机上的机载软件到底怎么表明自己符合适航要求答案不是交一份测试报告完事而是构建一条完整的证据链让审定方能够独立判断你的软件是可控的。这条链的每一环都要能回答三个问题这个需求从哪来、它是怎么被实现的、它又是怎么被验证的。换个生活化的类比这就像装修一套房你不是找物业说一句我装好了而是要交出施工图、材料清单、水电改造记录、隐蔽工程照片、验收单让人相信房子住着不会塌。机载软件也一样需求文档是施工图设计是结构图代码是材料测试是验收记录构型管理则保证这些文件从头到尾是同一套、没有被偷偷改过。这里的关键在于可追溯性。从系统级需求拆到软件高层需求再拆到低层需求然后对应到设计、代码、测试用例最后到测试结果这条线必须是通的、闭合的。任何一处断裂在审定眼里都是风险点。我见过不少项目栽在追溯矩阵上需求改了测试用例没同步或者节奏一乱追溯表就成了事后补的东西补出来的表基本经不起追问。2. 定级软件符合性工作量的总开关在聊具体怎么表明符合性之前必须先讲清楚软件等级因为它是决定后面一切工作量的总开关。同一套流程A级软件和D级软件的工作要求可能差出一倍不止。很多项目在起步阶段对定级认识不足后期才发现验证深度要求远超预期返工代价极大。2.1 五个等级从哪来软件等级不是软件团队自己拍脑袋决定的它由系统层面的安全性评估过程分配下来。系统工程师先做功能危害评估分析每个功能的失效会对飞机和人员造成什么后果再依据后果的严重程度给功能定级软件作为功能的实现载体继承相应的等级。这件事属于系统工程范畴软件团队更多是接单方但绝不能当甩手掌柜。等级大致分五档。A级是最严的失效会导致最严重的后果B级次之C级对应较严重的后果D级对应较轻的后果E级则是基本没有安全影响的软件。举例来说直接参与飞行控制的软件通常落在A级或B级而一些仅用于客舱信息显示、出问题也不影响飞行安全的软件可能在C级甚至D级。这里有个常见的误区有人觉得等级越高越安全干脆都按A级做。这种想法在工程上不现实A级的工作量、验证深度、文件要求都是最高的把D级软件按A级做纯属浪费资源还会打乱整个交付节奏。正确做法是尊重系统安全性评估的结论该是哪级就是哪级同时留意等级可能会随系统设计变更而调整。2.2 等级如何影响后面每一步等级的影响是全链条的不是只影响测试。它决定了你要满足哪些目标、验证要做多深、覆盖分析要做到哪一档、工具要不要鉴定、构型管理的严格程度。以结构覆盖为例最高等级会要求做到修正条件判定覆盖也就是常说的 MC/DC往下一级可能只要求判定覆盖再往下可能只要求语句覆盖。这几档的测试用例数量和投入完全不是一个量级。我个人的经验是在项目早期就把等级相关的目标清单拉出来做成一张表逐条标注适用与否这样后面做计划和预算时心里有数。最怕的是做到一半才发现某个目标没覆盖那时候补的成本非常高因为很多证据是过程性的过了那个阶段就再也补不回来。另外等级还影响审定方参与的深度。等级越高越可能需要在早期就提交规划类文件、越需要频繁的沟通和阶段评审。这不是麻烦反而是一种保护——早期把方向对齐总比后期大面积返工要好。3. 表明符合性的骨架过程、目标、证据讲完定级就可以进入正题了。机载软件表明适航符合性国际上有一套成熟的方法论核心逻辑可以概括成三块一套必须执行的软件生命周期过程、一批必须满足的目标、以及用来证明目标已满足的生命周期数据。这三者构成了整个符合性工作的骨架。3.1 三类过程撑起整个框架这套方法论把软件活动划分为三大类过程。第一类是规划过程负责在动手前把怎么做定下来包括软件审定计划、开发计划、验证计划、构型管理计划、质量保证计划等。规划类文件是整个体系的顶层设计它们告诉审定方你打算如何满足要求。第二类是开发过程也就是把需求变成可运行软件的过程涵盖需求定义、架构设计、详细设计、编码和集成。开发过程的核心是各级需求和它们之间的追溯关系。第三类是综合过程包括验证、构型管理、质量保证和审定联络。综合过程不直接生产软件但它保证了软件是被正确地验证、受控地变更、可信地交付的。这三类过程不是并列关系而是交织在一起的。规划过程定规则开发过程产生产品综合过程负责检查和背书。理解这个分工就不会把验证简单等同于最后测一下也不会以为构型管理只是存个档。3.2 目标与符合性矩阵把做到了没变成可查的表这套方法论的精髓在于目标这个概念。它不规定你必须用什么工具、什么方法而是列出一批目标比如高层需求要可追溯低层需求要精确且可验证代码要符合标准结构覆盖要达到规定程度等。你的任务是针对每一个目标说明自己是怎么满足的并附上证据。这就引出了符合性矩阵。它是一张表横轴是各等级对应的目标纵轴是你采用的方法和证据来源。这张表的价值在于把我们做得很规范这种模糊说法变成目标几号用何种活动满足证据在某份文件的某节这种可核查的表述。审定时双方基本就是围绕这张表逐条过。我特别想强调的是目标数量随等级递减。最高等级需要满足的目标最多往下逐级裁剪到最低的安全相关等级只剩二十几项而几乎没有安全影响的等级基本不涉及。具体数目各方资料略有出入做项目时要以标准原文和审定方的确认为准不要凭记忆。3.3 生命周期数据证据的载体被满足的目标要靠生命周期数据来承载。生命周期数据可以理解成软件从生到死产生的所有受控文档和记录大致分为计划类、开发类、验证类、构型管理类、质量保证类和审定联络类。每一份数据都是证据链上的一环。这里有个容易忽视的点生命周期数据本身就是需要被评审和受控的。不是说你写了一份测试报告就完事这份报告要经过评审、纳入构型管理、有版本记录、有批准记录。如果报告是事后补的评审记录和变更记录对不上审定方一眼就能看出来。还有一个关键文件叫软件成就摘要它在项目收尾时把我们满足了哪些目标、还有哪些没满足、为什么可以接受整体交代一遍。这份文件相当于给整个符合性工作做一个自我介绍写得好能省下大量沟通成本写得含糊则可能引发一连串追问。4. 从需求到验证生命周期实操里的关键动作骨架讲完落地到日常干活真正决定成败的是生命周期各阶段的细节执行。这一章我按开发顺序讲几个关键动作重点放在容易踩雷的地方。4.1 需求阶段最容易埋雷的地方软件需求分高层需求和低层需求。高层需求描述软件要做什么通常由系统需求分解而来低层需求描述软件怎么实现往下就对应到代码。需求阶段最大的雷是需求写得不够精确、无法验证。比如需求里出现及时响应尽量稳定这类词验证时根本没法判定通过与否审定方也会直接质疑。我的经验是每一句需求都要能回答我拿什么证明它被满足了。如果一句话说不清楚验证方法那多半是需求本身有问题。另外需求的可追溯性是重中之重每条软件需求都要能追溯到上层的系统需求同时要被至少一个测试用例覆盖。这种向上可追溯、向下被覆盖的双向关系是需求评审最常被盯的地方。还要注意需求的完备性。漏掉一条边界条件的需求可能就漏掉一整组测试用例进而导致覆盖分析不达标。实际项目里需求评审最好拉上验证人员一起做让写测试用例的人提前介入很多不可验证的问题能在早期暴露出来。4.2 设计、编码与可追溯性设计阶段把需求转化成架构和详细设计。这里讲究的是设计与需求的对应关系——每个设计元素都应该服务于某条需求反过来每条需求都应该有设计来落实。编码阶段则要遵守编码标准编码标准的作用不是好看而是规避那些已知容易出错的写法比如隐式类型转换、不可达代码、危险的指针操作等。在规模稍大的项目里代码评审和静态分析是标配。静态分析能在不运行代码的前提下发现一批潜在问题属于低成本的缺陷拦截。但要注意静态分析报告也是证据的一部分报告里的告警要么被修掉要么要给出不修的理由不能直接忽略。可追溯性在这一阶段体现得最具体需求、设计、代码、测试用例四者之间要能对得上。我见过最省心的做法是从项目一开始就用工具管理追溯关系每次变更自动更新关联项。也见过最痛苦的做法是用表格手工维护改一条需求要手动改好几处时间一长必然对不上。工具选型这件事值不值得投入取决于项目规模和变更频率。4.3 验证方法与结构覆盖语句、判定、MC/DC验证是重头戏。常用的验证方法有三类评审、分析和测试。评审靠人来判断文档的正确性分析靠工具或推理证明某些性质测试靠运行软件观察结果。三者各有适用场景不是所有目标都能用测试来满足。结构覆盖则是验证深度的量化指标也是审定时最容易被追问的部分。它衡量的是测试用例对代码结构的覆盖程度从浅到深大致分几档。最浅的是语句覆盖要求每一条可执行语句都被执行过往上一档是判定覆盖要求每个判定的真、假两个分支都被走到最深的是修正条件判定覆盖要求每个判定里的每个条件都能独立影响判定结果。为什么最高等级要求做到这么深因为浅层覆盖会漏掉一类隐蔽缺陷某个条件被短路求值掩盖了导致它的取值变化根本没有影响最终结果表面看测试全过了实际这个条件形同虚设。MC/DC 就是要逼出这种情况让每个条件都被单独验证过。4.4 覆盖分析的实操细节做覆盖分析有几个实操要点。第一覆盖分析要基于测试用例执行的真实结果不能手工标注满足。有些团队为了赶进度人工判定这条分支跑到了这种做法在工具化审定时很容易被识破风险极高。第二达不到的覆盖要能给出合理解释。比如某段防御性代码在正常场景下永远不可达这类死代码要么删掉要么说明其存在理由必要时通过专门的分析手段证明它不会带来风险。不能简单地覆盖不到就算了。第三覆盖工具本身也需要被关注。如果工具的输出被直接用作符合性证据那工具的可信度就成了问题这就引出了下一章要讲的工具鉴定。很多团队第一次做高等级项目时都是在这一环上栽跟头。5. 工具鉴定与参数数据最容易被低估的两块如果说前面的内容是主线那工具鉴定和参数数据就是两条容易被忽视、却又绕不开的支线。它们在最高等级项目里几乎是必答题在其他等级里也常常是加分或减分的分水岭。5.1 工具鉴定等级怎么判先说工具鉴定。软件开发过程中会用到大量工具编译器、需求管理工具、测试工具、覆盖分析工具、静态分析工具等。这些工具如果只是帮人干活人还能复核它的输出那它的可信度就不那么关键但如果工具的输出直接被当作符合性证据而人无法或不去复核那工具本身的缺陷就可能让证据失效。这就是工具鉴定的逻辑依据工具输出是否被直接依赖以及依赖程度判定工具需要做到什么样的可信级别。级别越高对工具的开发过程、验证、配置管理等要求越严做工具鉴定的成本和周期也越可观。反过来如果能让工具的使用方式变得始终有人复核,就可以把工具的鉴定要求降下来。我的实操建议是在规划阶段就把所有工具列出来逐一评估它的输出会不会被直接引用为证据。能通过流程设计降低依赖的就降低依赖确实必须鉴定的提前排期别等验证都做完了才想起来工具还没鉴定。5.2 参数数据项与结构覆盖分析工具的取舍再说参数数据。有一类软件的行为不是靠改代码而是靠改配置参数来调整的。这类参数数据同样会影响软件行为、同样可能有安全问题所以也需要纳入符合性活动比如参数数据的正确性要验证、变更要受控。它容易被漏掉是因为大家习惯性地把它当成配置而非软件。结构覆盖分析工具的取舍也值得单独讲。这类工具能自动算出覆盖结果省下大量人工但它的输出往往直接被引用为证据因此如果用它基本就要面对鉴定问题。有的团队会选择工具算出结果人工抽样复核关键分支以此降低对工具的绝对依赖。这个平衡点怎么找取决于项目等级、规模和团队能力没有标准答案但一定要在早期想清楚。6. 符合性证据的组织与审定配合前面讲了怎么做这一章讲怎么交。证据组织得好不好直接影响审定沟通的效率。很多技术做得很扎实的团队最后卡在证据组织上非常可惜。6.1 生命周期数据清单怎么盘第一步是把生命周期数据清单盘清楚。按计划、开发、验证、构型管理、质量保证、审定联络六大类列出所有受控文件标明版本、状态、评审和批准记录。这张清单要和符合性矩阵对应起来让每个目标都能指向具体的证据文件。盘清单时有个实用技巧按审定方会怎么问来组织而不是按团队内部怎么存来组织。内部文件夹结构往往很乱审定方不会去你的目录里翻所以要专门整理一份面向审定的证据索引。索引要清晰到第几章第几节最好带上页码减少对方来回找的时间。6.2 与审定方打交道的经验沟通这件事我的体会是早、准、实。早指早期就提交规划类文件、早期确认关键假设别憋到最后一次性交出大堆材料。准指问题要问得具体不要泛泛地问这样行不行而是带着方案问我打算这样做是否满足某目标。实指证据要落到实处避免用漂亮话掩盖具体缺失。还有一点审定提出的问题回答要直接别绕。如果某个目标确实没满足就给出不满足的理由、替代措施和风险评估坦诚比含糊更容易获得理解。我见过因为一句含糊表述被追问半年的案例后来发现其实问题并不大只是当时没讲清楚。7. 常见问题与排查技巧实录这一章把实际项目里反复出现的坑整理成快查表方便对照排查。常见问题典型表现排查思路处理建议需求不可验证出现模糊词汇测试用例写不出通过判据逐条需求追问拿什么证明重写需求补充量化边界追溯链断裂需求改了测试用例和设计未同步用追溯矩阵逐项核对双向关系尽量用工具自动维护追溯覆盖不达标某些判定分支长期未覆盖分析是由测试不足还是死代码导致补测试或说明并证明无风险工具未鉴定工具输出直接引用为证据列出所有工具评估输出依赖度降低依赖或提前安排鉴定参数数据遗漏配置改动未纳入受控和验证盘点所有影响软件行为的配置项纳入生命周期数据统一管理证据事后补评审和变更记录对不上检查记录时间线是否合理过程性证据要边做边留等级判断偏差验证深度与等级要求不符与系统安全性评估结论核对早期对齐等级并锁定目标清单除了表里的内容再补几个独家经验。第一边做边留痕是铁律过程性证据一旦错过时间点就补不回来我踩过最大的坑就是验证做完了才想起来评审记录没签。第二把最挑剔的人拉进评审让他提前问刁钻问题比审定当天被问住强得多。第三别迷信工具能解决一切工具能提高效率但不能替你承担符合性责任。最后分享一个我在实际项目中的体会机载软件适航符合性的核心说到底是把不确定变成确定、把隐性的东西变成显性的东西。每一次需求澄清、每一份评审记录、每一行可追溯的测试用例都是在把风险从暗处搬到明处。这个过程确实繁琐但当你真正把证据链理顺了那种心里有底的踏实感是任何捷径都换不来的。这个方向后续还可以往模型化开发和形式化方法延伸等有精力我再单独整理一篇实操笔记。