做机载软件这些年被问得最多的不是“这段代码怎么写”而是“DO-178到底怎么回事”。尤其是新机型、eVTOL、无人机物流这些方向火起来之后大量从消费电子、汽车电子甚至互联网转过来的团队一看到PSAC、MC/DC、TQL、SOI这些缩写就犯怵。DO-178C这个标准本身不复杂复杂的是它逼着整个团队把“安全证据”当成软件产品的一部分来交付。我平时在项目里也常被拉着做内部培训攒了一版“DO-178 50问”。不是把标准条文翻译一遍而是按一个机载软件工程师的理解把从入门到取证最绕不开的概念、文档、验证方法、审核流程拆开讲清楚。想转行做航空软件、刚开始做适航取证、或者只是被DO-178C文档砸得头疼的朋友这篇应该能帮你把框架立起来。家人常说我是“跟标准较劲的人”。做了这么多年我越来越觉得DO-178C真正难的地方不是某个技术点有多深而是把几十个看似孤立的目标串成一条可追溯、可重复、可审查的证据链。下面这50问就是这条证据链上最常踩到的那些地方。1. 认识DO-178C标准的作用范围和出身背景很多人把DO-178C当成一本“文档清单”开始看结果越看越晕。我建议先把它当成一个“安全证据协议”来理解——它管的不是你能写出多好的代码而是你凭什么让审查方相信这套软件在飞机上是安全的。1.1 第1问DO-178C的全称、出身和版本演进DO-178C全称是《机载系统和设备合格审定中的软件考虑》由RTCA的SC-167特别委员会制定欧洲对应版本叫ED-12C由EUROCAE发布。它的版本演进很有意思1982年出DO-1781985年出DO-178A1992年出DO-178B2011年12月发布DO-178C中间还穿插了DO-248系列解释性材料。C版最明显的变化不是把B版条文重新排版而是针对工具鉴定、模型化开发、面向对象技术和形式方法补了四个配套文档DO-330、DO-331、DO-332、DO-333。如果你只用过DO-178B切到C版时最该留意的不是A表变复杂了而是“工具和数据链路的定义方式完全不同了”。1.2 第2问DO-178B和DO-178C到底差在哪B版诞生时编译器、自动代码生成这些还没成为机载软件开发的主力标准对工具的态度比较模糊。C版把“基于目标的认证”讲得更清楚了你要针对每个软件等级去满足目标Objectives用数据和活动证明符合性而不是靠“我们做了很多评审”这种口头描述。另外C版对需求、设计、代码、测试之间的可追踪性要求更严格。B版时代很多项目靠一个Excel大表来回填C版时代这个表不仅是内部工具它本身就是合格审定证据的一部分。可以说C版比B版更强调“证据之间的关系”而不只是“证据的数量”。1.3 第3问DO-178C是法律吗为什么叫“合格审定中的软件考虑”DO-178C本身不是法律但在民用航空适航审定体系里它几乎是事实上的技术标准。FAA、EASA以及不少地区民航当局的审查方都会把DO-178C作为机载软件适航审定的参考标准。名字里的“考虑”两个字容易误导人好像只是建议。其实一旦适航规章引用它它就有很强的实际约束力。所以不要问“我不按DO-178C行不行”要问“我的项目软件等级是什么、适用哪些目标、审查方认什么证据”。这两句话的差别直接决定了你后续文档怎么写。1.4 第4问到底覆盖哪些软件不覆盖哪些DO-178C覆盖的是安装在航空器上的机载软件以及开发这些机载软件时会影响最终行为的工具软件。像地面维护设备软件如果它不影响机载系统的适航符合性通常不在范围内。但有一个例外要小心如果地面设备是用来演示机载功能的比如测试台里面的自动判读软件审查方照样会要求评估它的影响。不覆盖的也有几类纯物理硬件的逻辑实现通常不归DO-178C管没有安全影响、被划为Level E的软件也基本不强制要求。问题是“你以为没影响”和“安全评估证明没影响”是两回事后者才作数。1.5 第5问FPGA、CPLD这类可编程逻辑算软件吗从标准归属上讲FPGA和CPLD的硬件设计通常按DO-254《机载电子硬件合格审定考虑》处理。但HDL代码的思维方式跟软件几乎一模一样尤其当里面的状态机、逻辑门级设计出了错照样会导致系统失效。实践中很多项目会按“可编程逻辑器件”单独管理HDL代码的配置管理、评审、验证也和软件放在一起做。最忌讳的是软硬件边界来回漂移一段逻辑今天说按DO-254明天代码多了又说算软件。边界必须在项目计划阶段定清楚并有系统级理由支撑。1.6 第6问机载软件和普通嵌入式软件的差距不光是“严格”差距主要不在代码风格而在“验证逻辑”。普通嵌入式项目追求功能正确、性能达标出了问题可以发一版补丁机载软件的核心要求是“证据链闭合”。每个需求都要能往上游追溯到系统安全需求往下游追溯到源代码和测试结果任何一处断裂在审查时都是不符合项。另一个差异是“回归心态”。消费电子里常说的“改动小不用全回归”在机载软件里必须有正式的变更影响分析支撑。哪怕只改一行代码也得说清楚这行影响了哪些模块、哪些需求、哪些测试。这种习惯刚开始很烦习惯之后会发现版本质量明显提高。1.7 第7问和ARP4754A、ARP4761怎么配合ARP4754A管飞机级和系统级的研制过程ARP4761管系统安全评估方法。DO-178C的软件等级就是从系统安全评估里来的。系统级会做功能危险评估FHA、初步系统安全评估PSSA、系统安全评估SSA把失效状态和安全性需求分配给软件软件团队才能知道自己该按哪个等级开发。所以一个正常的航空项目启动顺序是先有系统安全评估结论再启动软件的PSAC。要是系统分析还没完软件这边至少要把待定的假设写清楚防止后面安全评估结果一变整个软件计划推倒重来。1.8 第8问刚接触DO-178C怎么读标准最有效别从头到尾啃正文。正确姿势是先翻开附录A的目标表对着目标表再回头看正文的对应章节。正文讲的是“为什么这么要求”附录A才是审查时对照查的清单。我自己的方法是把目标表转成一个Excel或共享表格分为目标编号、适用等级、对应文档、当前证据状态、负责人。每完成一条就贴一个证据样例读到哪做到哪。这样两三个月就能把整个标准的骨架串起来而不是读完了还觉得满脑子术语。2. 软件等级与安全评估先定级别再谈开发软件等级是整个DO-178C应用的起点。等级定错了后面的目标和文档量会跟着一起错。这个环节最需要软件团队和系统安全工程师坐在一起而不是各干各的。2.1 第9问软件等级Level A到E怎么来的软件等级不是软件团队自己拍脑袋定的而是系统安全评估的结果。流程大体是先分析飞机级/系统级某个功能失效后对飞机、机组、乘员、地面人员的影响把失效状态分成灾难性、危险、重大、轻微、无安全影响几类再映射到软件等级。映射关系通常如下系统失效状态软件等级典型示例举例灾难性Level A主飞行控制、自动着陆等危险/严重-重大Level B发动机控制、部分导航重大Level C客舱环境、部分告警轻微Level D少量维护记录功能无安全影响Level E与安全无关的日志/配置这个表格只是帮初学者理解实际项目里每一个等级都必须有正式安全评估文件支撑。2.2 第10问什么软件会落到A级什么落到E级A级软件通常是失效后会直接导致飞机灾难性状态的功能比如主飞行控制系统、自动着陆、反推控制这一类。E级则是不参与任何安全相关功能比如机内娱乐系统里的部分非关键模块、维护日志软件等。但要注意一个系统里往往不是一锅端。同一个飞行管理系统核心飞行包线保护可能是A级而机组告警文本生成可能只是C级。定级的基本单位是“功能/模块”不是整个软件包。2.3 第11问失效状态和软件等级是一一对应吗大体上是一一对应但工程里常出现“加严指派”。比如某个功能失效后系统级判断是“危险的”按表对应是B级但审查方或系统安全工程师可能因为安全裕度、共用资源等原因要求软件按A级开发。还有一种反过来的情况两个功能单独看都是C级但组合起来可能产生B级失效这时候软件等级往往要按B级或更高级别管理。所以别把“安全检查表”当成简单查表游戏它背后有一套组合失效的逻辑。2.4 第12问FHA、PSSA、SSA是什么软件工程师要参与吗这三个都是系统安全评估过程的产出FHA是功能危险评估回答“功能失效会怎样”PSSA是初步系统安全评估回答“系统架构如何满足安全需求”SSA是系统安全评估回答“最终设计是否真的满足安全需求”。软件工程师不需要做全套FHA但一定要能读懂“分配给软件的失效状态与安全需求”。签软件需求时尤其要留意软件需求里是否明确写了对应的安全需求和失效状态类别。如果需求里只有功能描述没有安全属性后面做验证时很容易被审查方挑战。2.5 第13问等级定了之后对项目影响有多大影响非常大直接决定你要满足多少验证目标。一个A级软件几乎要打开全部目标包括MC/DC覆盖、独立验证、数据耦合和控制耦合分析文档和评审量通常是C级的两到三倍。C级以下可以砍掉一批目标独立验证和结构覆盖要求明显放松。这里分享一个经验项目启动时花一周把等级对应的目标矩阵、文档清单、验证活动整理成一张“项目控制表”比中期发现验证活动缺项后再补要省太多成本。很多项目延期根因就是等级相关目标没在计划阶段盘清楚。2.6 第14问安全评估中途变了软件等级能调整吗能但必须走正式变更控制流程。等级调整不是把文档里的数字从C改成B那么简单所有受影响的目标、测试用例、追溯表、工具鉴定等级都要重新审视。我见过最典型的失误是系统安全评估迟迟没定稿软件先按C级走三个月后安全结论变成B级整个验证计划重做。所以PSAC阶段最好把安全评估结论的依赖关系写明并在项目例会上持续跟踪避免“等到最后再统一变”。2.7 第15问软件等级和软件规模、复杂度有关吗无关。等级只由系统安全影响决定不取决于代码行数。一个只有200行但负责发动机燃油调节的A级功能验证成本可能比一个上万行的C级监控模块还高。这一点特别容易让从互联网转行过来的工程师感到困惑他们习惯用代码复杂度衡量工作量和测试力度但在航空语境下首先要问的是“这代码挂了会怎样”。复杂度会影响你用什么技术手段去验证但不影响等级本身。2.8 第16问一个项目可以出现多种软件等级吗可以而且很常见。一个系统里不同的软件配置项Software Configuration Item可以有不同的等级。工程上通常以分区或独立配置项为单位划分每个等级对应自己的一套目标和文档。难点在于等级混用时的资源隔离A级软件跑在同一个CPU上C级软件的异常不能影响A级软件。这就要靠RTOS分区、存储保护、总线调度来证明隔离有效性审查方会非常关注“低等级代码如何不干扰高等级代码”。2.9 第17问E级软件要不要做符合DO-178C通常不需要但必须证明它是E级。证明路径是系统安全评估给出的“无安全影响”结论并且要明确这个软件不参与任何安全相关功能。审查中常见的问题不是“E级软件为什么没做目标”而是“你凭什么说它是E级”。所以哪怕E级软件不做DO-178C目标也要跟系统工程师一起留一份简短有力的安全影响说明。有时候写这份说明花的力气比直接按D级做几个轻量目标还少要求却更严谨。3. 开发与生命周期计划、过程和数据是DO-178C的骨架等级定了之后接下来就是搭生命周期。DO-178C不是让每个人按同一条瀑布流走到底而是给了一套过程框架让你把计划、开发、验证、配置管理、质量保证、适航联络串起来。3.1 第18问DO-178C到底要我们建立哪些过程简单分两类开发过程和综合过程。开发过程包括软件计划、软件需求开发、软件设计、软件编码、软件集成综合过程贯穿始终包括软件验证、软件配置管理、软件质量保证和适航联络。很多人把“验证”当成开发完才做的一步这是不对的。DO-178C里的验证贯穿每个阶段需求要评审、设计要评审、测试要做评审本身就是验证活动。综合过程更像质量红线开发每个阶段都要拿它去卡一卡。3.2 第19问计划类文档有哪些PSAC和SDP的区别核心计划文档大致是这些缩写全称作用PSAC软件合格审定计划面向审定机构的总纲写等级、目标、生命周期、工具清单SDP软件开发计划需求、设计、编码、集成流程怎么执行SVP软件验证计划评审、分析、测试的具体安排SCMP软件配置管理计划基线、变更、版本控制规则SQAP软件质量保证计划过程质量审查安排PSAC是“给审查方看的”SDP是“给开发团队用的”。很多团队把两份文档写成同一份结果工作层面没法落地审查层面又嫌太细。3.3 第20问说DO-178C是“文档驱动”真的吗“文档驱动”这个说法我不太认同我更愿意叫它“证据驱动”。审查时审核员不会只看文档漂不漂亮他们更关心文档和实际过程是否一致。文档只是证据的载体哪怕你把每个目标都写了“已满足”没有对应的测试数据、评审记录、工具配置照样过不了。高效的团队不会把文档量堆得很高但会把每条证据都指向一个目标。反过来最怕的是写了几百页文档里面数据和实际代码版本对不上。这种比少写两份文档还难整改因为审查方会怀疑整套流程的真实性。3.4 第21问软件需求怎么做高层需求和低层需求什么区别高层需求HLR通常来自系统需求分配描述软件要做什么不掺杂实现细节。低层需求LLR在DO-178C语境下包括软件架构/详细设计描述怎么实现并可以直接追溯到源代码。两种需求都要求“无二义性、原子性、可验证性”。写需求尽量用“软件应……”句式一条需求只描述一个行为避免“和/或”这种模糊词。很多覆盖问题追到根上都是因为需求写得太大一条里塞了三四个行为测试用例根本没法一对一证明。3.5 第22问软件架构和数据耦合、控制耦合是什么软件架构要描述模块划分、层次关系、接口、数据流和控制流它是连接低层需求和源代码的桥梁。数据耦合指模块之间通过共享变量、参数传递发生依赖控制耦合指一个模块通过改变执行顺序或状态影响另一个模块。A级和B级软件在验证时要专门做数据耦合和控制耦合分析。原因是单独测每个模块都通过不代表模块拼在一起没问题。审查方会想看到“关键交互点都被测试覆盖到”的证据而不是一个模块一个模块独立盖章。3.6 第23问编码阶段有哪些硬性要求编码标准真需要吗DO-178C没有规定必须用C还是Ada也不限制语言细节但要求编码标准、编程规范和编译器约束形成文档并且要和目标代码建立联系。真正让项目翻车的通常不是语言本身而是未定义行为未初始化变量、栈溢出、整数溢出、隐式类型转换。编码标准的意义是让分析和测试更可重复。你定了规则“不准用递归”评审时就能快速检查你没定规则测试又很难覆盖所有递归路径出了bug还说不清责任。所以编码标准不是形式主义是给验证铺路的。3.7 第24问综合过程integral processes指哪几个DO-178C里综合过程指软件验证、软件配置管理、软件质量保证、适航联络。它们不跟在开发后面而是开发过程中的四条贯穿线。验证过程负责证明每个阶段产出符合目标配置管理负责建立基线、记录变更质量保证独立检查过程是否被遵守适航联络负责把方案和证据递给审定机构。这四个过程如果只在最后冲刺时才启动基本可以断定项目后面要大面积返工。3.8 第25问配置管理在DO-178C里为什么那么重因为适航审定的底层逻辑是“可重复、可追踪”。如果没有基线、没有变更控制、没有受控的源代码和测试环境你拿什么证明这一版软件和这份测试报告对应的是同一个东西配置管理的数据包括版本标识、变更记录、问题报告、回归测试记录。我见过太多项目在“测试环境版本”上吃亏开发环境里改了局部变量测试组还在用旧版本跑用例跑了三天才发现环境串了。SCM做扎实之后这类内耗能减少一大半。3.9 第26问软件生命周期数据都有哪些类别DO-178C把数据分成几大类计划数据、开发数据、验证数据、配置管理数据、质量保证数据和适航联络数据。计划数据回答“怎么做”开发数据回答“做了什么”验证数据回答“是否做对了”配置管理数据回答“这些数据版本可信吗”质量保证数据回答“过程有没有被遵守”适航联络数据负责把上面全部打包给审定机构这些数据不一定要长篇大论但必须完整、一致、可访问。审查时最怕的就是每类数据各存各的改了一处另一处对不上。4. 验证与结构覆盖测试不是堆用例而是逐个拿证据验证环节是DO-178C里内容最多、也最容易被误解的部分。它不是一个“最后阶段”而是一套系统化的证据生成方法包括评审、分析和测试三者缺一不可。4.1 第27问验证和测试有什么区别验证是一大类活动包含评审、分析和测试测试只是其中一种手段。很多关键缺陷是评审和分析先发现的测试只负责证明“需求到实现这条链没有断裂”。比如设计师写了一个覆盖率很高的测试用例评审时发现需求本身理解错了那测试做得再好也没用。DO-178C要求验证活动覆盖到每个目标而不是简单地说一句“我们测过了”。这句话说起来容易做起来需要把每类验证活动和目标对应起来。4.2 第28问评审、分析和测试三种手段怎么分工评审适合检查需求、设计、代码的可追踪性、标准和一致性由人工完成效率取决于评审清单够不够细。分析适合证明时序、吞吐、安全属性等不方便直接测试的属性比如最坏情况执行时间WCET分析、数据耦合分析、失效模式影响分析。测试适合验证功能正确性、鲁棒性和结构覆盖。实际项目通常这样配合先评审和分析排除明显错误再用测试补功能证据和覆盖率。别指望测试能发现所有设计问题也别只做评审不补测试——审查方两者都要看。4.3 第29问什么叫基于需求的测试RBT基于需求的测试要求每个测试用例都能追溯到至少一条软件需求并且测试输入、预期输出、测试前提都明确写进测试说明里。DO-178C特别强调RBT因为脱离了需求的测试即使全部通过也不能证明“你要的功能做了”。反过来说一条需求如果没有对应测试用例审查时就是直接的finding。很多团队习惯“按功能点”写测试而不是“按需求条目”写测试结果测试报告写了一大堆审查方却找不到需求3.2.1到底谁在验证。4.4 第30问测试用例设计和测试覆盖怎么证明一条需求通常要覆盖正常场景、异常场景、边界场景。测试用例至少包括输入、环境/前提、预期结果、执行步骤。证明覆盖的方式是需求追踪矩阵高层需求/低层需求到测试用例加结构覆盖率报告。追踪矩阵不需要每个测试都单独占一行但必须双向可查从需求能查到测试从测试也能查到需求。覆盖率报告则要说明机器指令或源代码的执行覆盖比例。最怕的是覆盖率报告漂漂亮亮拿到测试用例一看很多用例根本没有明确的预期输出。4.5 第31问MC/DC是什么哪些等级必须做MC/DC是修正条件/判定覆盖意思是每个布尔条件都能独立影响整个判定结果。它比判定覆盖更严格更比语句覆盖严格。各等级要求大致如下软件等级结构覆盖要求AMC/DC同时满足语句、判定覆盖以及数据/控制耦合分析B语句覆盖 判定覆盖以及数据/控制耦合分析C语句覆盖D无强制结构覆盖要求通常仍会做语句覆盖做自评估E无要求无安全影响A级项目里MC/DC覆盖往往是最费时的部分。复杂逻辑函数里条件多了构造“独立影响”测试用例非常烧脑。4.6 第32问覆盖率不达标会怎样偏差请求是什么如果某条代码在测试中无法覆盖需要写偏差请求deviation request或问题报告并说明原因。比如代码路径在目标环境中不可达或者需求导致该路径永远不会被执行。这个偏差要提交质量保证和审定机构不是开发自己说不行就算数。只有证明“不覆盖该路径不会降低安全性”才能被接受。个别时候可以通过调整测试方式提高覆盖但如果证明不了就得改需求或改代码。最忌讳的是为了覆盖率硬凑用例比如用一堆断言保证代码走到某行但实际行为没有被验证。4.7 第33问回归测试和变更影响分析怎么做每次需求或代码变更都要先做变更影响分析这次改动影响了哪些模块、哪些需求、哪些测试、哪些覆盖目标然后决定回归测试范围。DO-178C要求变更影响分析记录进入配置管理数据。经验是版本基线一定要清晰变更单要写清“改了什么、为什么改、测了什么、没测什么”。三个月后回看如果看不到这些变更就等于白做。无计划的“全量回归”听上去最安全但成本高得离谱必须有影响分析支撑裁剪。4.8 第34问验证的独立性什么时候必须独立DO-178C对A级软件的大部分验证目标要求独立即验证人员不能是需求/代码的实现者。B级部分目标要求独立C级和D级基本不强制。独立验证的意义是防止开发人员“自己查自己”给错误留下的机会更少。实践中A级项目会让独立测试组和评审组覆盖关键目标而不是只在文档上写一句“独立”。审查方会看人员分工表和组织结构图确认验证链条里没有利益冲突。4.9 第35问结构覆盖和RBT的关系是什么覆盖率再高也不代表安全结构覆盖证明“你执行了哪些代码”RBT证明“你按需求要求的行为测试了”。两者必须配合只有高覆盖率但没有需求对应关系审核员会质疑需求覆盖只有需求覆盖但覆盖率低说明有些路径没测到可能藏着bug。所以覆盖率再高如果需求质量本身很差测试也证明不了安全。DO-178C追求的是“完整证据链”不是某个单一指标。这个观念转变对从普通嵌入式转过来的人尤其重要。5. 工具、模型与自动代码DO-178C身边的三个“新解法”DO-178C时代工具鉴定和模型化开发已经是绕不开的话题。这部分最容易把新人绕晕因为涉及的标准文件不只是DO-178C一本。5.1 第36问工具鉴定的基本逻辑是什么工具鉴定解决的是“工具本身可能有bug但工具输出却被直接当成证据”的问题。如果一个工具的输出是软件产品的一部分比如编译器、代码生成器而且这个输出没有另一道独立验证兜底那就要对这个工具做鉴定。鉴定的目的不是证明“工具没bug”而是通过评估工具开发过程、验证数据和运行环境建立一个置信度把它用于某个目标等级是可以接受的。你可以把工具鉴定理解为“给工具发一个适航户口”只不过这个户口要由项目自己准备材料、自己维护。5.2 第37问TQL等级怎么理解DO-330和DO-178C什么关系TQL是工具鉴定等级DO-330定义了从TQL-1到TQL-5五个等级TQL-1最严格。DO-178C把工具鉴定整体外推到DO-330所以现在做工具鉴定要按DO-330建计划、写操作需求、做验证。实际项目里编译器、代码生成器这类开发工具的鉴定等级往往落在TQL-1或TQL-2单元测试工具、静态分析工具则常见TQL-3到TQL-5。注意TQL等级不是拍脑袋定的要看工具失效对软件目标的影响。5.3 第38问代码自动生成到底怎么办自动生成代码不是绕开DO-178C的捷径而是把验证重心从手写代码挪到了模型和映射关系上。有两条路可选要么把生成器当开发工具做鉴定一般是TQL-1或TQL-2要么对生成的代码做传统完整验证后者成本通常更高。DO-331提供了一条模型化开发的路把模型当作高层/低层需求的一部分验证模型的正确性和生成映射的一致性。无论选哪条都要在项目早期和审定机构沟通清楚不要等代码生成完了再问“这样行不行”。5.4 第39问COTS软件/操作系统/RTOS能直接用吗能但有前提。COTS产品不是“买来就能用”常见路径有两种一是把COTS当成开发出来的软件收集供应商开发数据自己做差异分析二是把它当作曾被确认过的软件做验收测试和运行评估。RTOS尤其要提供分区机制和清白证明说明A/B级功能不会受其他模块干扰。哪怕供应商给了DO-178C符合性声明也要在项目环境里重新做一遍验收测试。“供应商说能飞”和“在我们这个配置上能飞”是两回事。5.5 第40问面向对象、形式方法这些补充技术是什么情况DO-332是面向对象技术指南DO-333是形式方法指南。它们不是必选项但如果你在项目里用了继承、多态、动态绑定或者想用形式化证明替代部分测试就要按照对应补充文档来证明覆盖和验证目标。比如C的继承和多态容易引入动态绑定错误DO-332会要求分析对象生命周期、虚函数解析等错误模式。形式方法则适合做需求一致性证明能替掉一部分穷举测试但前提是你真的写出了可执行的证明脚本而不只是画了几个逻辑图。5.6 第41问多核处理器下的DO-178C有什么新问题多核引入了共享资源竞争、核间干扰、缓存一致性、任务调度不确定性等问题。DO-178C正文没有专门章节行业现在主要参考CAST-32A这个立场文件。多核项目最核心的困难是证明隔离怎么证明某个核上运行的高等级任务不会被相邻核的低等级任务干扰最坏情况执行时间WCET又怎么测多核项目一定要在PSAC阶段就跟审定机构对齐期望和证据形式别把单核验证数据直接改成多核环境用。5.7 第42问HIL/SIL仿真环境也算验证工具吗仿真环境可以作为验证手段但工具评估的逻辑在这里同样适用。如果你的验证结果完全依赖仿真器的行为你需要对仿真器做置信度评估并在测试记录里写明仿真环境的版本、配置、校准数据。SIL适合做大量自动化测试HIL适合验证IO时序和系统集成。但它们都不能替代在目标硬件上做的最终确认测试。很多项目把目标硬件测试放到最后一两个月结果发现时序问题和仿真差异只能手忙脚乱补用例。5.8 第43问开源工具能用吗怎么评估开源工具只要满足工具评估要求也能用难点在于工具开发过程数据往往不齐全。常见办法是围绕工具做额外的运行测试和置信度测试证明它在你的目标环境中行为符合预期并把工具版本、源码配置、生成环境全部记录在案。相比商业工具开源工具需要更多“用户承担鉴定责任”。这让不少团队选择把开源工具定位成验证辅助而非开发工具从而降低评估负担。我的经验是先做完工具差距分析再决定“自己补数据”还是“边界转移”。6. 适航审核与从业经验真正难的是把标准落进日常前面几十问都是技术概念最后这七问更接近“社会工程”怎么跟审查方打交道怎么让体系真正转起来而不是空转。6.1 第44问SOI审核到底看什么怎么准备SOI是适航审定人员的介入阶段审核通常分为SOI#1到SOI#4。SOI#1看计划SOI#2看需求和设计开发SOI#3看验证和实现SOI#4看最终符合性总结。审核员不是来听你讲PPT的他们会对照计划查看证据是否一致。准备要点先自查数据和目标的对应关系确保PSAC里承诺的每条目标都有实际证据再准备现场演示和关键记录清单。最怕的是文档写一套、代码跑另一套审查方抓到的第一个不一致就会怀疑所有材料。6.2 第45问不符合项finding常见都有哪些我见过的常见finding集中在需求标识不一致、追踪矩阵有空缺、测试用例缺少可复现的环境记录、覆盖率偏差没有正式批准、配置管理基线不清晰、工具鉴定证据与实际版本不符。整改思路永远是“先改过程再补文档”。只把文档改对不正根因下一轮审核还会再犯。比如因为追踪矩阵靠手工维护导致空缺那就该引入自动生成报告而不是每次审核前加班补Excel。6.3 第46问小团队/新项目做DO-178C最省力的路径是什么先别急着写所有文档。第一步做等级和适用目标矩阵找审定机构确认哪些可以裁剪第二步把配置管理和需求追踪工具选好别让手工表格控制变量第三步让验证工程师从开发第一天介入而不是等代码写完再补测试。小团队最大的杠杆是减少“计划与执行脱节”。宁可少写一套计划也要保证写了的那套完全被执行。很多小团队一上来就照大团队模板生成一堆文档结果每份文档只写了几页里面都是套话反而比一份“短而真”的计划更难通过审查。6.4 第47问DO-178C最大的成本在哪怎么控制成本大头往往不是文档而是测试与覆盖率的反复打磨以及一次失控变更引发的连锁回归。A级项目里MC/DC覆盖、目标硬件测试、多轮回归都会吞噬大量时间尤其当一个需求在开发后期被改掉时所有相关用例和覆盖都要重跑。控制成本的关键把版本开发周期内的变更集中批次处理减少频繁重新基线把需求写细降低“测完才发现需求理解错了”的概率测试自动化趁早投入特别是在目标环境上能跑的自动化框架。自动化刚开始很费时但后期每轮回归都会回到你身上来。6.5 第48问文档和代码谁更重要如果只能选一个我会选“证据链完整性”文档和代码只是证据链的两端。代码写得再好没有可追踪的需求和测试说明审查方无法判断它是否满足系统安全需求文档写了一大摞但和代码不一致反而比少写更糟。所以成熟团队把文档当作过程记录的一部分而不是事后编故事。好的方式是“边做边留痕”今天评审了什么、结论是什么、谁签的字当天就归档。等软件写完了再补会议纪要补出来的东西连自己都信不过。6.6 第49问新型航空器项目怎么看DO-178C这几年新形态航空器项目越来越多很多从地面行业跨界过来的团队会觉得DO-178C太重。但其实关键不是“要不要做”而是“哪些功能被划入安全相关、对应哪个软件等级”。电动垂直起降、支线无人机物流这些方向核心飞行控制和安全监控通常都逃不开A或B级。最大的挑战是流程文化从“代码能跑就行”切换到“每个决定都可追溯”。如果团队里没有有适航经验的人尽早找一个顾问或工程师进组比后期发现不符合项再返工便宜得多。6.7 第50问给航空航天软件工程师最后几条实操建议第一把附录A目标表打印出来贴工位上每天看一眼项目方向就不会跑偏。第二遇到任何不能一眼解释清楚的测试失败先写问题报告再改代码让问题进入正式跟踪渠道。第三别把“完成度”等同于“验证通过率”还要看“可追踪率”和“覆盖率”。第四跟审定机构沟通时带上具体数据和样例不要只带流程描述。最后一条保持对系统安全分析的敏感。软件研发只是整个适航验证链的一环你写的一段代码背后是一整套系统级安全评估在约束你。理解了这条链DO-178C就不再是一堆术语而是一套每天都在用的工作语言。做这行时间越长我越觉得DO-178C其实是在逼我们把“怎么想、怎么做、怎么证明”三件事对齐。很多团队花大力气做文档却忘了文档背后的目标是让审查方相信这套流程可重复、能追溯。如果你正在上手DO-178C别怕一开始绕不清楚先挑一个小功能走通“需求→设计→编码→测试→覆盖→归档”的完整闭环比读十遍标准都有用。