企业官网建设流程全解析

做机载软件这些年，被问得最多的不是“这段代码怎么写”，而是“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-178，1985年出DO-178A，1992年出DO-178B，2011年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）怎么来的？

软件等级不是软件团队自己拍脑袋定的，而是系统安全评估的结果。流程大体是：先分析飞机级/系统级某个功能失效后，对飞机、机组、乘员、地面人员的影响，把失效状态分成灾难性、危险、重大、轻微、无安全影响几类，再映射到软件等级。映射关系通常如下：

这个表格只是帮初学者理解，实际项目里每一个等级都必须有正式安全评估文件支撑。

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是“给开发团队用的”。很多团队把两份文档写成同一份，结果工作层面没法落地，审查层面又嫌太细。

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是修正条件/判定覆盖，意思是每个布尔条件都能独立影响整个判定结果。它比判定覆盖更严格，更比语句覆盖严格。各等级要求大致如下：

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，别怕一开始绕不清楚，先挑一个小功能，走通“需求→设计→编码→测试→覆盖→归档”的完整闭环，比读十遍标准都有用。