DO-178C 的软件生命周期过程，包括软件计划过程、开发过程以及4 个整体支持过程（验证过程、构型管理过程、质量保证过程以及审定联络过程）。以下是我们在工程实践中总结的各个过程的活动内容和关注要点。
1计划过程
机载软件计划过程非常重要，在计划过程创建的软件合格审定计划（PSAC）、软件开发计划（SoftwareDevelopment Plan，SDP）、软件验证计划（Software Verification Plan，SVP）、软件构型管理计划（SoftwareConfiguraiton Management Plan，SCMP）、软件质量保证计划（SoftwareQuality Assurance Plan，SQAP）以及软件需求标准、设计标准和编码标准，将用以指导软件整个研制生命周期过程的活动。DO-178C 附录A 的表A-1 是对软件计划过程中各级别软件的目标和输出的概括。DO-178C 第4 章详细描述了软件计划过程的目标和活动。
简而言之，计划阶段要编制5 份计划和3 个标准，值得注意的是对于不同等级的软件要求有所不同，具体参见DO-178C附录A的A-1表。
1.1机载软件合格审定计划编制指导
软件合格审定计划可以看作与局方讨价还价的一个工具，这份计划通常由项目经理或适航工程师编制，在工程人员完成其他4份计划后，项目经理或适航工程师概述其他几份计划的内容，提出合格审定的一个方法和计划，得到局方认可。这份计划非常重要，类似于合同的角色，并且需要得到局方批准。
然而写一个200 多页的软件合格审定计划（Plan for Software Aspects of Certification，PSAC）是没有必要的，通常30到40页就足够了。系统、架构和软件概述必须包含在PSAC 中。系统描述很重要，因为软件不能脱离于系统进行符合性验证。另外PSAC中还要明确软件架构、编程语言、处理器、分区、完整性检查等方面的内容。需要在PSAC 中定义软件设计保证等级：是A、B、C、D 还是E，并列出确定等级的理由，可以索引到已发布的初步安全性分析文件，用其证明所定的安全等级是正确的。注意在附加说明中，需要说明是否为外场可加载软件、是否使用先前开发的软件、工具鉴定、COTS、用户可选项软件、用户可更改软件等。无论上述情况是否存在，都建议在PSAC 中声明。对于工具鉴定的章节，建议列出所有使用的工具，并列出工具的功能和用途，然后评估这些工具是DO-178C的准则几（3类工具），再按照DO-178C 得出工具是否需要鉴定的结论，最后阐明工具鉴定计划。对于开发工具的鉴定，编制独立的工具鉴定计划（Tool Qualification Plan，TQP），具体工具鉴定过程参见RTCA/DO-330。
PSAC 的编制指导见DO-178C 第11.1 节。按照DO-178C 的指导编制PSAC 的架构，更容易获得DER 或者局方审查代表的批准。
1.2机载软件开发计划编制指导
软件开发计划（SDP）是为了说明软件开发的过程、输入输出、转换阶段、开发工具和软件开发环境。这个计划陈述了软件生命周期过程、如何定义需求、是否要做基于模型的开发、是否要使用结构化的方法、要使用的语言是ADA 还是C、用的工具是什么、什么是需求追溯性、是否用DOORS 来追溯需求，以及是否使用Lynx OS-178 作为实时操作系统等。这些细节都要写到机载软件开发计划中去。机载软件开发计划的编制参见DO-178C 第11.2 节。
1.3机载软件验证计划编制指导
机载软件验证计划（SVP）用以说明软件验证过程的活动、验证方法、检查单以及软件的验证环境等，在这个环境中，评审、验证软件并证明其正确性。验证贯穿整个机载软件生命周期过程，包括如何确认计划、需求、设计和代码、测试以及测试结果的分析等。在机载软件验证计划中还要说明是否使用验证工具完成结构覆盖分析、代码评审、还基于不同层级需求的测试环境以及回归测试的策略、如何验证需求符合需求标准、设计符合设计标准、编码符合编码标准等，这些方面也是机载软件验证计划要考虑的内容。
机载软件验证计划的具体编制参见DO-178C 第11.3 节。
1.4机载软件构型管理计划编制指导
构型管理或配置管理都是对应相同的英文单词“Configuration”，通常对软件开发的具体单位来说，他们惯用的叫法为“配置”，而对于主制造商而言，站在全机的角度来说，就叫“构型”，其实两者只是同一概念在不同领域的不同翻译。
在机载软件构型管理计划（Software Configuration Management Plan，SCMP）中，必须定义对产品、数据项文件和生命周期记录的构型控制，建立这些构型项的标识方法、更改控制和问题 告机制。当前大型的构型管理平台大都基于 络，所以要定义构型管理系统并确定开发人员怎么使用这个系统，建立相关的规则来说明如何建立系统、如何定义访问控制权限，并定义问题 告机制和系统如何追踪问题直到关闭。软件的任何更改应该有更改原因、更改方案，并附上更改授权的记录。数据留存、检索和发布也是当今一个深受关注的问题，这包括系统如何备份数据、如何重建软件、谁来负责构型管理、如何发起一个问题 告以及如何检入/检出数据。所有参与项目的工程师应遵循这份操作指南。
机载软件构型管理计划的具体编制参见DO-178C 第11.4 节。
1.5软件质量保证计划编制指导
机载软件质量保证计划需要详细说明如何保证软件质量，并符合DO-178B。SQAP 要解决整个软件生命周期中的质量和过程保证问题。这包括软件质量保证的活动有哪些、SQA（SoftwareQuality Assurance）人员多久检查一次、是否需要目击测试和评审代码、是否参与计划中的一些过程和活动吗、汇 机制等等。SQA 要监控软件工程活动的进行，这包括软件研制的阶段转换活动，它指的是从软件开发的一个过程进入到另一个过程，在进入下一个过程之前，需要满足进入、退出的准则。SQA 的主要角色就是确保5 个重要的计划和3 个标准是符合DO-178C的，并通过质量保证活动确保整个工程活动遵循了批准的计划和标准。SQA 要具有独立性和权威性，通常由独立的组织的人员担任这一角色。
软件质量保证是一个过程，所以必须要有证据来向局方证明SQA 工作遵循了这个过程。SQA 的主要角色是确保所有的项目过程、计划和标准符合DO-178B，并且每个人都遵循这些过程、计划和标准，并能给出相应的证据，这也是为什么需要检查单和记录的原因。
SQAP 的编制参见DO-178C 第11.5 节，同样建议文件架构按照该章节的指导进行编制，这样在局方或者DER 评审时更容易通过。
1.6机载软件需求、设计和编码标准编制指导
机载软件的需求标准中定义创建软件高级别需求的方法、规则和工具。DO-178C 第11.6 节并没有指定需求标准，而是给出一个概要的指导原则，告诉申请人需求标准应该至少包括哪些方面的内容。至于选择什么样的需求标准，不同的公司会有不同的做法。通常需求标准不是为具体项目编制的文件，而是供应商在很多项目上通用的标准文件。
机载软件设计标准用来定义开发软件架构和软件低级别需求的方法、规则和工具，同样DO-178C 第11.7 节也没有给出具体的设计标准，而是一个指导性原则。不同的供应商选用的设计标准可能不同，通常设计标准也是公司通用文件，不针对具体项目。
机载软件编码标准用来定义编写代码的语言、方法、规则和工具。DO-178B 第11.8 节没有给出具体的编码标准，而是一个指导性原则。但保证安全的设计和编码策略很重要，例如，标准C++语言部分特性会导致机载软件具有不确定性或者不易分析和验证，编码不便使用的特性，如封装性、多态性、动态内存分配等，因此要定义C++的哪些子集是可接受的，并且要在编码标准中明确。
2开发过程
软件开发过程的目标和活动应符合DO-178C 第5.0 章规定。软件开发过程按照软件软件开发计划和系统分配给软件的需求进行。DO-178C 附件A的表A-2是对各个级别的软件在软件开发过程中的目标和输出的概括。软件开发过程包括需求、设计、编码和集成过程，但不同的软件项目其开发过程不尽相同，同一软件项目的不同软件组件也可能采用不同的开发过程的顺序。
图 2 机载软件开发过程
2.1机载软件需求过程
需求过程中利用系统需求和系统架构分解产生软件高级别需求，包括功能、性能、接口及与安全性有关的需求。高级别需求在软件设计过程中进一步得到完善。
2.2机载软件设计过程
在软件设计过程中，通过一次或多次迭代，逐步完善软件高级别需求，以开发软件架构和能用于实现源代码的低级别需求。
2.3机载软件编码过程
在软件的编码过程，根据软件架构和低级别需求编写源代码。
2.4机载软件集成过程
目标计算机、软件编码过程中产生的源代码和目标代码与集成过程中的链接和加载数据一起用于开发出集成的机载系统或设备。集成过程的目的是把可执行目标代码加载到目标硬件中完成软硬件集成。各软件开发商在这一过程中检测到任何不合格或者不正确的输入都要提供给软件需求过程、软件设计过程、软件编码过程或者软件计划过程，作为纠正错误的反馈。
2.5机载软件集成考虑
各系统软件集成过程由软件组件集成和软硬件集成两部分组成。各系统软件集成活动由软件供应商执行。集成过程的输入来自软件设计过程的软件架构、软件编码过程的源码和目标码。软件集成过程中无效代码和软件补丁的考虑按照DO-178C 第5.4.3 节进行。机载设备在研制过程中可能具有多个构型，并不是所有的构型在同一应用环境下被激活。这与DO-178C 第6.4.4.3 节定义的死代码不同。对于未被激活的代码和补丁在软件集成过程中的考虑如下：
a）应该有证据表明未激活代码在不想使用它的环境中是不能被激活的。由于异常的系统状态造成的未激活代码的非预期的行为与激活代码的非预期行为是一样对待的；
b）处理未激活代码的方法应符合软件计划；
c）对于提交给合格审定的航空器或发动机所使用的机载软件，不能使用补丁来实现对需求或架构的更改。补丁的使用是有限制条件的，通常情况下是个案处理，例如，用于解决软件开发环境中已知的缺陷；
d）当使用补丁时，以下因素也要考虑：
1）软件构型管理过程能有效地保证补丁的可追溯性；
2）进行回归分析以证明补丁可满足非补丁方法开发软件的所有目标；
3）在软件完结综述中阐述使用补丁的符合性判断依据。
2.6机载软件开发过程的可追溯性
软件开发过程需要满足的追溯性要求如下：
a）系统需求和软件需求之间应建立追溯性，并能够验证软件开发过程对系统分配的需求实现的完整性，衍生需求要被明确标识出来；
b）低级别需求和高级别需求之间建立追溯性，并能够验证设计过程对高级别需求实现的完整性，衍生需求要被明确标识出来；
c）源代码和低级别需求之间应建立追溯性，并能够验证是否有缺失的源代码以及低级别需求实现的完整性。
注：相比于DO-178B，DO-178C在输出过程中正式增加了Trace Data（追溯性数据）作为一类生命周期过程数据。
3软件验证过程
根据DO-178C 标准，整个生命周期的所有过程的输出都需要验证，甚至对于验证过程本身的输出，还要进行验证，这就是验证的验证，验证的主要手段有评审、分析、测试。这一部分要掌握的要点：
a）评审主要是对生命周期数据
b）分析主要是对验证的结果：如基于需求的测试覆盖分析、结构覆盖分析等
c）测试：基于需求进行！！！！测试用例的选取。
d）结构覆盖分析：语句覆盖、判定覆盖、MC/DC
4构型管理管理过程
这一过程比较容易理解。
略。
5质量保证过程
这一过程比较容易理解。
略。
6合格审定联络过程
需要提交审查方批准的数据：PSAC、SCI 和SAS。审查方批准SAS代表软件最终获得了适航批准。
审查方发阶段、SOI#3验证阶段和SOI#4 最终阶段审查。需要说明的是进行4个阶段的审查介入：SOI#1计划阶段、SOI#2开审查方会根据软件复杂度、申请人的研制及取证经验等综合评估软件审查介入程度，有可能会进行多次SOI#2、SOI#3，也可能几个SOI合并进行。
总结：DO-178C对我国民机软件研发既是挑战，也是机遇。活学活用DO-178C可以帮助我们一方面提高软件开发能力，另一方面提高软件适航取证能力。尤其是后者，总是让大家感到无处下手。通过这两篇文章，我希望能够帮助大家提高对软件适航的认识，为大家更深入理解软件适航的精髓奠定基础，从而更好的提高软件适航取证能力。
·END·
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！