干机载软件这行几乎没人能绕开DO-178。我第一次在项目群里看到DO-178 50问这个标题时第一反应是把RTCA那份六百多页的DO-178C标准拆成50个能直接问、直接答的问题这个角度确实聪明。因为DO-178真正的门槛不是它写得有多深而是它写得太散。条款多、表格密、术语绕再加上一堆缩写PSAC、SCMP、SQAP、MC/DC、TQL新人进去很容易看两页就晕老手也经常在这条目标到底对应哪个过程上卡住。50问的意义就是把这些散落的点用提问的方式串成一条线。为什么有软件等级目标和条款有什么区别覆盖率做到多少算够工具为什么还要鉴定这些问号背后恰恰是DO-178体系中最重要的骨架。这篇内容我打算按实际做项目的经验把DO-178的底层逻辑、50个高频疑问背后的答案要点、以及真正上手时容易翻车的细节一次讲透。适合正在做机载软件开发或适航认证支持的工程师、刚接触DO-178的项目经理以及给航空项目做工具或中间件的供应商团队。1. 先搞清楚DO-178到底在管什么1.1 标准名字背后的含义DO-178C的全称是《机载系统和设备合格审定中的软件考虑》由RTCA发布FAA、EASA以及全球多个民航局都接受它作为机载软件适航取证的符合性方法。注意这里用的是软件考虑不是软件开发指南也不是测试规范。这意味着它管的不是你怎么写代码而是你用什么流程、什么证据来证明这个软件在飞机上是安全的。我经常用一个类比来解释这件事汽车要上市要过碰撞测试、排放测试这是对整车的要求飞机上的软件也一样它自己不直接撞但软件一旦故障可能导致系统失效进而影响飞行安全。DO-178就是给软件这个零件设定的符合性门槛——你不需要证明代码没有bug这不可能但你必须证明你已经用一套可控的过程把风险降到可接受的程度。这里有个容易混淆的点DO-178C不是法规本身而是一种被广泛接受的符合性方法。民航局的适航规章不会直接写按DO-178C执行但型号合格审定过程中申请人提交的软件证据如果按DO-178C来做代表了一套业界认可的成熟做法。换句话说你可以不用DO-178但这意味着你得自己证明不用它也等效安全——实操中几乎没人会这么干。1.2 软件等级DAL不是拍脑袋定的DO-178里最常被提到、也最容易被误解的概念就是软件等级英文常叫DALDevelopment Assurance Level研制保证等级。它分A、B、C、D、E几档A级代表软件失效可能造成灾难性后果B级是危险的C级是主要的D级是次要的E级是无安全影响的。关键来了软件等级不是开发团队自己订的也不是客户随便要求的。它来自系统层面的安全性评估。飞机系统在架构设计时会做功能危险分析和系统安全性评估确定某个系统失效状态的严重性分类然后把这个分类分配到软件、硬件等部件上。所以你做DO-178项目接到的第一个任务往往是去找系统安全性报告确认你的软件到底是哪个等级。等级没定对后面所有计划、目标、覆盖率要求全是错的。等级为什么重要因为它直接决定开发过程的严格程度和证据数量。以验证过程为例A级软件几乎每个开发活动都要有对应目标结构覆盖率做到MC/DC级别C级软件只有少量的强制目标很多分析和验证活动可以由开发人员自行完成。同样的软件功能如果等级从A降到C工作量可能差两三倍。早早在计划阶段确认等级是项目启动时最该做的事。1.3 目标、过程和证据DO-178的骨架DO-178C标准的正文里最要紧的不是那些叙述性章节而是从表A-1到表A-10的目标表格。整本标准的逻辑可以概括成三件事过程、目标、证据。过程软件生存周期被划分为计划、开发、验证、配置管理、质量保证、审定联络等若干过程。目标每个过程下定义了若干目标Objectives比如软件需求过程有软件需求被开发并符合系统需求这样的目标。证据满足目标后要产出相应证据软件生命周期数据比如需求文档、设计说明、测试用例、评审记录、追踪矩阵。你去看DO-178项目里那些庞大的文档包本质上是为这些表格里的每一条目标收集证据。满足DO-178不是按标准做一遍开发而是逐条满足目标表格中的要求并且证据可审查。这个设计很巧妙也很折磨人。巧妙在于标准不规定文档长什么样、流程用什么工具它只规定你要达成什么目标达成方式的自由度很高。折磨人在于目标是抽象的怎么证明满足它往往要靠经验。很多团队拿着标准逐句对口型结果写了一堆文档却对不上目标有些团队反着来只做验证测试不做计划和配置管理一样过不了审查。理解了目标-证据这个骨架你才算真正入门DO-178。2. 50问的提问逻辑为什么是问不是背2.1 用问题组织知识最容易上手我见过很多新人学DO-178第一件事就是拿标准从头看到尾看一半就放弃了。原因很简单标准是以过程为线索组织的不是以疑问为线索组织的。比如覆盖率这件事散落在验证过程、软件等级表格、工具鉴定条款里单看某一章根本拼不出全貌。50问的形式就解决了这个问题。我按实际项目经验把DO-178常见疑问大致分成六类每一类都有几个绕不开的代表性问题类别典型问题核心解答要点适航基础什么软件要按DO-178做装载在型号产品上、失效会影响飞机运行安全的软件通常是审定项目的一部分开发流程计划阶段要写哪些文件PSAC、SDP、SCMP、SQAP四个计划加上工具鉴定计划验证与测试测试为什么不能只测功能还需要需求覆盖率、结构覆盖率、鲁棒性测试、独立性验证等配置管理基线怎么建代码、需求、文档、测试用例都要纳入受控基线变更走正式流程质量保证质量保证和测试有什么不同QA做过程审计和产物审计测试做技术验证两个角色不冲突工具与审定工具为什么需要鉴定工具可能在其输出中引入错误必须按可信度等级证明其输出可接受这种分类方式不是标准给出的而是我在项目里总结出来的。标准按过程分读者按疑问分中间这个断层就是50问要补的。你不需要先懂全过程结构才能开始学你只需要从你最困惑的问题切入然后沿着问题附带的相关条目逐步扩展开来。2.2 几个我见过的高频问题先挑几个最常被问到的展开说说我的软件等级是A级还是B级怎么判断——看系统安全性评估结果软件等级来源于系统失效状态的严重性分类不是你的代码有多复杂。A级软件要做MC/DC覆盖率B级不用做那么深的覆盖分析这不是工作量差别是安全风险决定的。什么是衍生需求——这是最容易混淆的概念。系统需求是飞机级或系统级直接分配给软件的需求衍生需求是软件开发过程中为了满足系统需求而产生的更低一层需求比如为了实现某个接口时序软件团队自己定义了一个内部握手协议。衍生需求在DO-178里必须明确标识因为它不直接来源于系统需求需要额外的确认活动证明它不会带来错误。什么叫独立验证——英文叫Independent Verification意思是验证活动不能由写这段代码的人自己包办。审查时经常遇到的情况是开发工程师既写了代码又写了自己的测试用例自己跑完就宣称验证完成。DO-178要求在多个目标上做独立性检查特别是A级和B级需要独立于开发角色的人来执行验证或评审。工具鉴定到底是干什么——你用了代码生成器、覆盖率工具、编译器这些工具如果自身错了会把错误引入软件而且工具产生的错误靠后续人工检查往往发现不了。DO-178不要求所有工具都鉴定只要求工具的输出会影响最终软件安全性判断的工具按DO-330去证明其可信度。后面我会专门展开讲。2.3 怎样把50问变成自己的项目检查单这里我分享一个很实用的方法不要只把50问当学习材料把它当成项目的自检清单。我自己做过一张表四列问题、涉及目标、对应证据、当前状态。每周过一遍每一行如果答不上来或者证据找不到那一列就标红意味着风险点。比如这个配置项的变化是否经过CCB审批对应配置管理过程的目标这条需求对应的测试用例是否闭环对应验证过程的目标。用这种方式项目还没到审查阶段你就已经把一多半的问题提前爆掉了。很多项目组最后集中补文档补到崩溃本质上是没有在日常把问题答过一遍全堆到最后成了历史遗留问题。3. DO-178项目里最难啃的几块硬骨头3.1 覆盖率分析不是打到80%就万事大吉很多人对DO-178的印象就是覆盖率要到多少多少。这其实是误解。覆盖率只是验证活动的一部分而且不同等级要求不同。DO-178C中结构覆盖率主要有几种语句覆盖每条语句至少执行一次、决策覆盖每个判断的真假分支都走到、修正条件/判定覆盖MC/DC每个条件都能独立影响判定结果、数据耦合和控制耦合分析。A级软件的代码覆盖率要求做到MC/DC级别这意味着你设计测试用例时不能只对着需求写几个happy path还要专门构造用例去证明每个条件单独取真、单独取假时都能改变判定结果。实操中很多测试用例跑完后覆盖率工具会报出一堆未覆盖条件一看原因往往是条件之间相互遮蔽——某个条件为假时另一个条件直接决定了结果前面的条件永远无法单独影响判定。这种问题靠肉眼很难发现必须借助成熟的覆盖率分析工具。我做项目时常用VectorCAST或LDRA这类的工具来分析MC/DC但要注意这类工具本身如果要在审计中作为证据使用也要考虑工具鉴定问题。覆盖率分析报告要能追溯到你跑了哪些用例、哪个版本的代码、哪个版本的测试环境这几点缺一不可。另外特别提醒一句需求覆盖率是另一条线指的是每条需求有没有对应的测试用例它不等于结构覆盖率。很多团队拿着代码覆盖率90%说覆盖率达标审查员一问这条需求测了吗就答不上来了。3.2 工具鉴定哪些工具要鉴定哪些不用一听到工具鉴定很多团队就紧张觉得只要是开发中用到的工具都得搞一套鉴定文档。这不对。DO-178C和DO-330里工具是否要鉴定、鉴定到什么级别取决于工具在过程中扮演的角色和它引入错误的能力。简单说分这样几类第一类工具的输出直接成为机载软件的一部分比如代码生成器、高级语言编译器如果它错了错误直接进产品这类工具可信度要求最高往往要按较高的TQL级别鉴定第二类工具的输出被用来减轻其他验证活动比如覆盖率分析工具、测试工具如果它错了可能让验证结果失真也需要鉴定但级别可以低一些第三类工具只是辅助人员做决策比如文本编辑器、代码格式化工具它不改变最终输出的正确性通常不需要鉴定。我在项目里见过最典型的翻车案例团队在计划阶段没把工具鉴定列进去开发过程中用了一个脚本自动生成部分代码工作量确实省了不少但等到审查时才发现这个脚本属于开发工具它的输出直接进入了源代码库必须要做DO-330的工具鉴定最后只能一边补鉴定数据一边担心审查结论。正确的做法是在PSAC阶段就列出所有计划使用的工具按DO-330的分类逻辑逐个判断它出错了会不会影响机载软件会不会掩盖错误会的话就要规划鉴定活动。3.3 需求、设计与代码之间的对账DO-178项目里最耗费体力、也最容易出问题的就是需求、设计、代码、测试之间的追溯性。审查时最经典的问题就是这条需求对应的设计在哪对应的代码在哪对应的测试用例在哪四个环节必须串成一条完整的证据链。这个追溯矩阵很多团队用Excel来维护几百上千条需求一列每次变更就手动改一次改着改着就乱了。我建议尽早引入需求追踪工具像DOORS、Polarion这类功能强弱不重要重要的是它能保证每次变更都被追踪。而且追溯矩阵不是项目后期一次性补的而是在开发过程中逐步同步维护的。每写一条代码就要关联到设计条目每写一个测试用例就要关联到需求条目。另外要留意衍生需求的处理。一条衍生需求不能被简单地挂到系统需求下面它需要单独标识、单独确认、单独验证。我和团队就吃过这个亏一个配置文件里改了采样率参数系统需求文档没提我们以为是新增的参数项没有标注衍生来源。后来审查员问这个参数为什么存在它的来源是什么我们找了一下午才从设计说明里翻出来龙去脉。从那以后所有不在系统需求里的细化需求一律在需求工具里标记衍生需求写明来源和理由。4. 50问变现实战常见问题与避坑经验4.1 高频问题排查表以下这些问题是我在DO-178项目中反复遇到过的列成一张速查表供大家参考常见问题根本原因解决思路计划文档写了A级但没做MC/DC分析计划阶段没把覆盖率要求落到验证策略写SVP时明确等级对应的结构覆盖率类别并选对工具需求追溯矩阵对不上代码改了一版需求没同步更新把追溯维护纳入每次变更流程用工具做自动检查测试覆盖率100%但审查不过只有代码覆盖率缺少需求到测试的映射先检查需求覆盖率再检查结构覆盖率工具用了但没鉴定记录开发过程中临时引入脚本或工具工具清单纳入配置管理引入工具前先做DO-330评估衍生需求没有标识开发人员不清楚系统需求和衍生需求的区别在需求管理规范里明确标识规则独立验证变成了自己人查自己项目人手不足验证角色由开发人员兼任计划阶段就规划独立验证资源按角色划分权限审查时文档版本对不上配置管理基线不完整所有生命周期数据纳入SCMP管理打基线后再送审这张表看起来简单每一条背后都是真金白银的工时。拿测试覆盖率100%但审查不过来说我们在一个项目中测试工程师辛辛苦苦把语句覆盖率跑到96%以为过关了结果审查员看的是需求追踪矩阵有一条安全相关需求压根没有对应的测试用例。代码覆盖率再高也覆盖不了没人测这条需求这个事实。后来补了一轮用例设计才把缺的那条需求补上。所以覆盖率分析一定要两条腿走路需求覆盖率是有没有测到该测的结构覆盖率是有没有测到不该漏的。4.2 四个我踩过的坑第一个坑迷信覆盖率工具的报告。工具报告显示MC/DC 100%但我后来仔细检查用例设计发现有些条件是靠巧合覆盖的——比如两个条件在同一个用例里同时翻转工具判定它们都独立影响结果了实际上并不是。审查员如果深究就会要求你展示每个条件的独立影响证据。这种问题没有捷径只能靠测试用例设计时多下功夫用真值表一个个核对条件组合。第二个坑配置管理只管源代码不管文档和工具配置。DO-178里的软件生命周期数据不只有代码需求文档、设计文档、测试用例、工具配置文件、脚本都在受控范围内。我曾见过一个项目代码库里一切正常但编译配置文件在开发人员的笔记本电脑上改了没入库别人一编译就出问题还找不出原因。在DO-178流程下这类文件必须进配置管理库版本变更走正规流程。第三个坑参数文件被当成普通文本随便改。飞机上有大量参数通过配置文件加载比如控制增益、采样周期、阈值等。这些参数在DO-178里是软件的一部分不是随便改个数字就行的。改一个参数需要走变更请求、影响分析、回归验证流程。我见过一个团队直接在服务器上改了个参数连变更记录都没有最后审查时被开了一个SOI发现项只能补做影响分析。第四个坑和审查方沟通太晚。很多团队习惯闷头开发到快送审时才开始约审查员。DO-178的PSAC软件合格审定计划在项目初期就应该提交与审查方达成共识之后再开展具体开发。我习惯的做法是项目启动就把PSAC草稿、软件等级、计划使用的工具、验证策略整理成一页纸约审查方开个短会先对齐关键假设。这会让你后期省掉大量返工式修改文档的时间。4.3 现场实操小贴士再分享几个特别具体的操作习惯都是我自己试下来特别管用的每个送审文件都带版本记录和审批记录文件封面至少包括版本号、日期、作者、评审人、批准人、变更摘要。审查员翻文件时一眼就能看到这个文件是否受控。按标准目标编号来组织证据文件夹比如表A-5-1对应需求过程目标1所有相关证据放进去。这个习惯能让审查时找证据的速度快10倍。每周跑一次自动追溯检查。如果你用的是DOORS/Polarion这类工具可以设置规则检查未关联测试的需求和未关联需求的测试用例。如果是Excel也可以写个公式做交叉比对。总之别让追溯矩阵长期处于有缺口的状态。工具鉴定文档单独建库不要混在开发文档里。因为工具鉴定有自己的生命周期和软件版本不完全同步混在一起特别容易乱。5. 如何把50问变成团队的学习与自查工具5.1 先从问题地图开始我建议每个刚接触DO-178的团队先做一张自己的问题地图把50问按上面提到的六类问题分好每个问题标注答案要点、对应标准章节、对应的目标编号。这张地图不需要一上来就做得很细但一定要覆盖标准在讲什么这个问题。有了地图新人上手就不再是无头苍蝇而是带着具体问题去查标准。我们团队的做法是入职和转岗的同事先自己过一遍问题地图然后在内部例会上每人讲三到五个问题讲不明白就回去重新看标准。你会发现看得懂和讲得出之间差距很大讲一遍比看三遍都管用。这套方法成本很低但效果远比发一本标准让人自学要好。5.2 从会答到会查50问如果只用来学习价值浪费了一半。它更该被当成验收和审计的抓手。在每个里程碑之前把问题清单拉出来逐项核对这个问题的答案是否成立证据是否完整如果哪个问题答不上来说明对应的过程目标还有缺口立刻安排人员补。这样用下来50问就从一个文档变成了团队的内部审查机制。审查员到来之前你先自己当一遍审查员。我自己做项目时会专门留出一个半天拉上几个核心成员拿50问逐条过遇到模棱两可的当场翻标准定论。说实话每次过都能翻出几个平时没注意到的小疏漏——不是技术难题多是文档版本、签署日期、追溯关系这类细节但这类细节正是DO-178审查里最爱挑的。5.3 可以扩展的方向DO-178C发布之后行业又出了不少配套文件比如DO-331模型开发和模型验证、DO-332面向对象技术的应用、DO-333形式方法的补充还有针对多核处理器的CAST-32A。如果你做的是基于模型的设计、水龙头式代码生成或者IMA综合模块化架构那50问肯定是不够的需要往这些补充文件上延伸。我的经验是先掌握DO-178C的主体逻辑目标、等级、覆盖率、工具鉴定、配置管理、审定联络再按项目特性去扩展对应的补充条款这样最稳。反过来一上来就抓模型开发的那些细节反而容易丢掉整体框架。50问是个起点不是终点这一点越早想清楚越少走弯路。6. 最后分享一点个人体会做DO-178项目这几年我最深的感受是这个标准从来不真的难在技术而是难在体系化的思考和持之以恒的记录。50问的形式本质上是把一个整体系拆成一个个小问题再拼回一张地图。如果你正在准备一个DO-178项目别急着埋头写代码先去搞清楚你的软件是什么等级、对应什么失效状态先把PSAC写好把计划跟审查方和公司内部达成一致再把验证、配置管理、质量保证纳入日常工作流而不是留到送审前补。我个人实操中的一个小技巧是把所有问题按项目阶段整理成一个带状态标记的Excel每个里程碑过一遍状态为未回答或证据缺失的条目就是当下的风险点。把这件事做扎实了你会发现项目一多半风险在审查之前就已经消掉了。这套标准的本质其实就是预防为主、证据闭环。你越早把它当成习惯它就越不吓人。
干机载软件这行几乎没人能绕开DO-178。我第一次在项目群里看到DO-178 50问这个标题时第一反应是把RTCA那份六百多页的DO-178C标准拆成50个能直接问、直接答的问题这个角度确实聪明。因为DO-178真正的门槛不是它写得有多深而是它写得太散。条款多、表格密、术语绕再加上一堆缩写PSAC、SCMP、SQAP、MC/DC、TQL新人进去很容易看两页就晕老手也经常在这条目标到底对应哪个过程上卡住。50问的意义就是把这些散落的点用提问的方式串成一条线。为什么有软件等级目标和条款有什么区别覆盖率做到多少算够工具为什么还要鉴定这些问号背后恰恰是DO-178体系中最重要的骨架。这篇内容我打算按实际做项目的经验把DO-178的底层逻辑、50个高频疑问背后的答案要点、以及真正上手时容易翻车的细节一次讲透。适合正在做机载软件开发或适航认证支持的工程师、刚接触DO-178的项目经理以及给航空项目做工具或中间件的供应商团队。1. 先搞清楚DO-178到底在管什么1.1 标准名字背后的含义DO-178C的全称是《机载系统和设备合格审定中的软件考虑》由RTCA发布FAA、EASA以及全球多个民航局都接受它作为机载软件适航取证的符合性方法。注意这里用的是软件考虑不是软件开发指南也不是测试规范。这意味着它管的不是你怎么写代码而是你用什么流程、什么证据来证明这个软件在飞机上是安全的。我经常用一个类比来解释这件事汽车要上市要过碰撞测试、排放测试这是对整车的要求飞机上的软件也一样它自己不直接撞但软件一旦故障可能导致系统失效进而影响飞行安全。DO-178就是给软件这个零件设定的符合性门槛——你不需要证明代码没有bug这不可能但你必须证明你已经用一套可控的过程把风险降到可接受的程度。这里有个容易混淆的点DO-178C不是法规本身而是一种被广泛接受的符合性方法。民航局的适航规章不会直接写按DO-178C执行但型号合格审定过程中申请人提交的软件证据如果按DO-178C来做代表了一套业界认可的成熟做法。换句话说你可以不用DO-178但这意味着你得自己证明不用它也等效安全——实操中几乎没人会这么干。1.2 软件等级DAL不是拍脑袋定的DO-178里最常被提到、也最容易被误解的概念就是软件等级英文常叫DALDevelopment Assurance Level研制保证等级。它分A、B、C、D、E几档A级代表软件失效可能造成灾难性后果B级是危险的C级是主要的D级是次要的E级是无安全影响的。关键来了软件等级不是开发团队自己订的也不是客户随便要求的。它来自系统层面的安全性评估。飞机系统在架构设计时会做功能危险分析和系统安全性评估确定某个系统失效状态的严重性分类然后把这个分类分配到软件、硬件等部件上。所以你做DO-178项目接到的第一个任务往往是去找系统安全性报告确认你的软件到底是哪个等级。等级没定对后面所有计划、目标、覆盖率要求全是错的。等级为什么重要因为它直接决定开发过程的严格程度和证据数量。以验证过程为例A级软件几乎每个开发活动都要有对应目标结构覆盖率做到MC/DC级别C级软件只有少量的强制目标很多分析和验证活动可以由开发人员自行完成。同样的软件功能如果等级从A降到C工作量可能差两三倍。早早在计划阶段确认等级是项目启动时最该做的事。1.3 目标、过程和证据DO-178的骨架DO-178C标准的正文里最要紧的不是那些叙述性章节而是从表A-1到表A-10的目标表格。整本标准的逻辑可以概括成三件事过程、目标、证据。过程软件生存周期被划分为计划、开发、验证、配置管理、质量保证、审定联络等若干过程。目标每个过程下定义了若干目标Objectives比如软件需求过程有软件需求被开发并符合系统需求这样的目标。证据满足目标后要产出相应证据软件生命周期数据比如需求文档、设计说明、测试用例、评审记录、追踪矩阵。你去看DO-178项目里那些庞大的文档包本质上是为这些表格里的每一条目标收集证据。满足DO-178不是按标准做一遍开发而是逐条满足目标表格中的要求并且证据可审查。这个设计很巧妙也很折磨人。巧妙在于标准不规定文档长什么样、流程用什么工具它只规定你要达成什么目标达成方式的自由度很高。折磨人在于目标是抽象的怎么证明满足它往往要靠经验。很多团队拿着标准逐句对口型结果写了一堆文档却对不上目标有些团队反着来只做验证测试不做计划和配置管理一样过不了审查。理解了目标-证据这个骨架你才算真正入门DO-178。2. 50问的提问逻辑为什么是问不是背2.1 用问题组织知识最容易上手我见过很多新人学DO-178第一件事就是拿标准从头看到尾看一半就放弃了。原因很简单标准是以过程为线索组织的不是以疑问为线索组织的。比如覆盖率这件事散落在验证过程、软件等级表格、工具鉴定条款里单看某一章根本拼不出全貌。50问的形式就解决了这个问题。我按实际项目经验把DO-178常见疑问大致分成六类每一类都有几个绕不开的代表性问题类别典型问题核心解答要点适航基础什么软件要按DO-178做装载在型号产品上、失效会影响飞机运行安全的软件通常是审定项目的一部分开发流程计划阶段要写哪些文件PSAC、SDP、SCMP、SQAP四个计划加上工具鉴定计划验证与测试测试为什么不能只测功能还需要需求覆盖率、结构覆盖率、鲁棒性测试、独立性验证等配置管理基线怎么建代码、需求、文档、测试用例都要纳入受控基线变更走正式流程质量保证质量保证和测试有什么不同QA做过程审计和产物审计测试做技术验证两个角色不冲突工具与审定工具为什么需要鉴定工具可能在其输出中引入错误必须按可信度等级证明其输出可接受这种分类方式不是标准给出的而是我在项目里总结出来的。标准按过程分读者按疑问分中间这个断层就是50问要补的。你不需要先懂全过程结构才能开始学你只需要从你最困惑的问题切入然后沿着问题附带的相关条目逐步扩展开来。2.2 几个我见过的高频问题先挑几个最常被问到的展开说说我的软件等级是A级还是B级怎么判断——看系统安全性评估结果软件等级来源于系统失效状态的严重性分类不是你的代码有多复杂。A级软件要做MC/DC覆盖率B级不用做那么深的覆盖分析这不是工作量差别是安全风险决定的。什么是衍生需求——这是最容易混淆的概念。系统需求是飞机级或系统级直接分配给软件的需求衍生需求是软件开发过程中为了满足系统需求而产生的更低一层需求比如为了实现某个接口时序软件团队自己定义了一个内部握手协议。衍生需求在DO-178里必须明确标识因为它不直接来源于系统需求需要额外的确认活动证明它不会带来错误。什么叫独立验证——英文叫Independent Verification意思是验证活动不能由写这段代码的人自己包办。审查时经常遇到的情况是开发工程师既写了代码又写了自己的测试用例自己跑完就宣称验证完成。DO-178要求在多个目标上做独立性检查特别是A级和B级需要独立于开发角色的人来执行验证或评审。工具鉴定到底是干什么——你用了代码生成器、覆盖率工具、编译器这些工具如果自身错了会把错误引入软件而且工具产生的错误靠后续人工检查往往发现不了。DO-178不要求所有工具都鉴定只要求工具的输出会影响最终软件安全性判断的工具按DO-330去证明其可信度。后面我会专门展开讲。2.3 怎样把50问变成自己的项目检查单这里我分享一个很实用的方法不要只把50问当学习材料把它当成项目的自检清单。我自己做过一张表四列问题、涉及目标、对应证据、当前状态。每周过一遍每一行如果答不上来或者证据找不到那一列就标红意味着风险点。比如这个配置项的变化是否经过CCB审批对应配置管理过程的目标这条需求对应的测试用例是否闭环对应验证过程的目标。用这种方式项目还没到审查阶段你就已经把一多半的问题提前爆掉了。很多项目组最后集中补文档补到崩溃本质上是没有在日常把问题答过一遍全堆到最后成了历史遗留问题。3. DO-178项目里最难啃的几块硬骨头3.1 覆盖率分析不是打到80%就万事大吉很多人对DO-178的印象就是覆盖率要到多少多少。这其实是误解。覆盖率只是验证活动的一部分而且不同等级要求不同。DO-178C中结构覆盖率主要有几种语句覆盖每条语句至少执行一次、决策覆盖每个判断的真假分支都走到、修正条件/判定覆盖MC/DC每个条件都能独立影响判定结果、数据耦合和控制耦合分析。A级软件的代码覆盖率要求做到MC/DC级别这意味着你设计测试用例时不能只对着需求写几个happy path还要专门构造用例去证明每个条件单独取真、单独取假时都能改变判定结果。实操中很多测试用例跑完后覆盖率工具会报出一堆未覆盖条件一看原因往往是条件之间相互遮蔽——某个条件为假时另一个条件直接决定了结果前面的条件永远无法单独影响判定。这种问题靠肉眼很难发现必须借助成熟的覆盖率分析工具。我做项目时常用VectorCAST或LDRA这类的工具来分析MC/DC但要注意这类工具本身如果要在审计中作为证据使用也要考虑工具鉴定问题。覆盖率分析报告要能追溯到你跑了哪些用例、哪个版本的代码、哪个版本的测试环境这几点缺一不可。另外特别提醒一句需求覆盖率是另一条线指的是每条需求有没有对应的测试用例它不等于结构覆盖率。很多团队拿着代码覆盖率90%说覆盖率达标审查员一问这条需求测了吗就答不上来了。3.2 工具鉴定哪些工具要鉴定哪些不用一听到工具鉴定很多团队就紧张觉得只要是开发中用到的工具都得搞一套鉴定文档。这不对。DO-178C和DO-330里工具是否要鉴定、鉴定到什么级别取决于工具在过程中扮演的角色和它引入错误的能力。简单说分这样几类第一类工具的输出直接成为机载软件的一部分比如代码生成器、高级语言编译器如果它错了错误直接进产品这类工具可信度要求最高往往要按较高的TQL级别鉴定第二类工具的输出被用来减轻其他验证活动比如覆盖率分析工具、测试工具如果它错了可能让验证结果失真也需要鉴定但级别可以低一些第三类工具只是辅助人员做决策比如文本编辑器、代码格式化工具它不改变最终输出的正确性通常不需要鉴定。我在项目里见过最典型的翻车案例团队在计划阶段没把工具鉴定列进去开发过程中用了一个脚本自动生成部分代码工作量确实省了不少但等到审查时才发现这个脚本属于开发工具它的输出直接进入了源代码库必须要做DO-330的工具鉴定最后只能一边补鉴定数据一边担心审查结论。正确的做法是在PSAC阶段就列出所有计划使用的工具按DO-330的分类逻辑逐个判断它出错了会不会影响机载软件会不会掩盖错误会的话就要规划鉴定活动。3.3 需求、设计与代码之间的对账DO-178项目里最耗费体力、也最容易出问题的就是需求、设计、代码、测试之间的追溯性。审查时最经典的问题就是这条需求对应的设计在哪对应的代码在哪对应的测试用例在哪四个环节必须串成一条完整的证据链。这个追溯矩阵很多团队用Excel来维护几百上千条需求一列每次变更就手动改一次改着改着就乱了。我建议尽早引入需求追踪工具像DOORS、Polarion这类功能强弱不重要重要的是它能保证每次变更都被追踪。而且追溯矩阵不是项目后期一次性补的而是在开发过程中逐步同步维护的。每写一条代码就要关联到设计条目每写一个测试用例就要关联到需求条目。另外要留意衍生需求的处理。一条衍生需求不能被简单地挂到系统需求下面它需要单独标识、单独确认、单独验证。我和团队就吃过这个亏一个配置文件里改了采样率参数系统需求文档没提我们以为是新增的参数项没有标注衍生来源。后来审查员问这个参数为什么存在它的来源是什么我们找了一下午才从设计说明里翻出来龙去脉。从那以后所有不在系统需求里的细化需求一律在需求工具里标记衍生需求写明来源和理由。4. 50问变现实战常见问题与避坑经验4.1 高频问题排查表以下这些问题是我在DO-178项目中反复遇到过的列成一张速查表供大家参考常见问题根本原因解决思路计划文档写了A级但没做MC/DC分析计划阶段没把覆盖率要求落到验证策略写SVP时明确等级对应的结构覆盖率类别并选对工具需求追溯矩阵对不上代码改了一版需求没同步更新把追溯维护纳入每次变更流程用工具做自动检查测试覆盖率100%但审查不过只有代码覆盖率缺少需求到测试的映射先检查需求覆盖率再检查结构覆盖率工具用了但没鉴定记录开发过程中临时引入脚本或工具工具清单纳入配置管理引入工具前先做DO-330评估衍生需求没有标识开发人员不清楚系统需求和衍生需求的区别在需求管理规范里明确标识规则独立验证变成了自己人查自己项目人手不足验证角色由开发人员兼任计划阶段就规划独立验证资源按角色划分权限审查时文档版本对不上配置管理基线不完整所有生命周期数据纳入SCMP管理打基线后再送审这张表看起来简单每一条背后都是真金白银的工时。拿测试覆盖率100%但审查不过来说我们在一个项目中测试工程师辛辛苦苦把语句覆盖率跑到96%以为过关了结果审查员看的是需求追踪矩阵有一条安全相关需求压根没有对应的测试用例。代码覆盖率再高也覆盖不了没人测这条需求这个事实。后来补了一轮用例设计才把缺的那条需求补上。所以覆盖率分析一定要两条腿走路需求覆盖率是有没有测到该测的结构覆盖率是有没有测到不该漏的。4.2 四个我踩过的坑第一个坑迷信覆盖率工具的报告。工具报告显示MC/DC 100%但我后来仔细检查用例设计发现有些条件是靠巧合覆盖的——比如两个条件在同一个用例里同时翻转工具判定它们都独立影响结果了实际上并不是。审查员如果深究就会要求你展示每个条件的独立影响证据。这种问题没有捷径只能靠测试用例设计时多下功夫用真值表一个个核对条件组合。第二个坑配置管理只管源代码不管文档和工具配置。DO-178里的软件生命周期数据不只有代码需求文档、设计文档、测试用例、工具配置文件、脚本都在受控范围内。我曾见过一个项目代码库里一切正常但编译配置文件在开发人员的笔记本电脑上改了没入库别人一编译就出问题还找不出原因。在DO-178流程下这类文件必须进配置管理库版本变更走正规流程。第三个坑参数文件被当成普通文本随便改。飞机上有大量参数通过配置文件加载比如控制增益、采样周期、阈值等。这些参数在DO-178里是软件的一部分不是随便改个数字就行的。改一个参数需要走变更请求、影响分析、回归验证流程。我见过一个团队直接在服务器上改了个参数连变更记录都没有最后审查时被开了一个SOI发现项只能补做影响分析。第四个坑和审查方沟通太晚。很多团队习惯闷头开发到快送审时才开始约审查员。DO-178的PSAC软件合格审定计划在项目初期就应该提交与审查方达成共识之后再开展具体开发。我习惯的做法是项目启动就把PSAC草稿、软件等级、计划使用的工具、验证策略整理成一页纸约审查方开个短会先对齐关键假设。这会让你后期省掉大量返工式修改文档的时间。4.3 现场实操小贴士再分享几个特别具体的操作习惯都是我自己试下来特别管用的每个送审文件都带版本记录和审批记录文件封面至少包括版本号、日期、作者、评审人、批准人、变更摘要。审查员翻文件时一眼就能看到这个文件是否受控。按标准目标编号来组织证据文件夹比如表A-5-1对应需求过程目标1所有相关证据放进去。这个习惯能让审查时找证据的速度快10倍。每周跑一次自动追溯检查。如果你用的是DOORS/Polarion这类工具可以设置规则检查未关联测试的需求和未关联需求的测试用例。如果是Excel也可以写个公式做交叉比对。总之别让追溯矩阵长期处于有缺口的状态。工具鉴定文档单独建库不要混在开发文档里。因为工具鉴定有自己的生命周期和软件版本不完全同步混在一起特别容易乱。5. 如何把50问变成团队的学习与自查工具5.1 先从问题地图开始我建议每个刚接触DO-178的团队先做一张自己的问题地图把50问按上面提到的六类问题分好每个问题标注答案要点、对应标准章节、对应的目标编号。这张地图不需要一上来就做得很细但一定要覆盖标准在讲什么这个问题。有了地图新人上手就不再是无头苍蝇而是带着具体问题去查标准。我们团队的做法是入职和转岗的同事先自己过一遍问题地图然后在内部例会上每人讲三到五个问题讲不明白就回去重新看标准。你会发现看得懂和讲得出之间差距很大讲一遍比看三遍都管用。这套方法成本很低但效果远比发一本标准让人自学要好。5.2 从会答到会查50问如果只用来学习价值浪费了一半。它更该被当成验收和审计的抓手。在每个里程碑之前把问题清单拉出来逐项核对这个问题的答案是否成立证据是否完整如果哪个问题答不上来说明对应的过程目标还有缺口立刻安排人员补。这样用下来50问就从一个文档变成了团队的内部审查机制。审查员到来之前你先自己当一遍审查员。我自己做项目时会专门留出一个半天拉上几个核心成员拿50问逐条过遇到模棱两可的当场翻标准定论。说实话每次过都能翻出几个平时没注意到的小疏漏——不是技术难题多是文档版本、签署日期、追溯关系这类细节但这类细节正是DO-178审查里最爱挑的。5.3 可以扩展的方向DO-178C发布之后行业又出了不少配套文件比如DO-331模型开发和模型验证、DO-332面向对象技术的应用、DO-333形式方法的补充还有针对多核处理器的CAST-32A。如果你做的是基于模型的设计、水龙头式代码生成或者IMA综合模块化架构那50问肯定是不够的需要往这些补充文件上延伸。我的经验是先掌握DO-178C的主体逻辑目标、等级、覆盖率、工具鉴定、配置管理、审定联络再按项目特性去扩展对应的补充条款这样最稳。反过来一上来就抓模型开发的那些细节反而容易丢掉整体框架。50问是个起点不是终点这一点越早想清楚越少走弯路。6. 最后分享一点个人体会做DO-178项目这几年我最深的感受是这个标准从来不真的难在技术而是难在体系化的思考和持之以恒的记录。50问的形式本质上是把一个整体系拆成一个个小问题再拼回一张地图。如果你正在准备一个DO-178项目别急着埋头写代码先去搞清楚你的软件是什么等级、对应什么失效状态先把PSAC写好把计划跟审查方和公司内部达成一致再把验证、配置管理、质量保证纳入日常工作流而不是留到送审前补。我个人实操中的一个小技巧是把所有问题按项目阶段整理成一个带状态标记的Excel每个里程碑过一遍状态为未回答或证据缺失的条目就是当下的风险点。把这件事做扎实了你会发现项目一多半风险在审查之前就已经消掉了。这套标准的本质其实就是预防为主、证据闭环。你越早把它当成习惯它就越不吓人。
