敢称“标准”，并非是出自官方的意思。只不过是完全基于DO-178C相关章节要求编写，并经Job Aid检查单检查内容复查，同时结合国内厂商在编写文件时容易犯的错误之后生成的这份模板。内容包含较全，对于较低级别的软件可以适当裁剪。在此仅希望能够给写计划的厂商带来一点便利，减少一点问题。如有不全，望留帖提醒。
1 范围
2 引用文件
略。
补充一下，此处应引用其它计划文件及标准文件，注意带上版本标识，不要写最新版有效。
3 缩略语/术语
略。
4 组织及职责
说明项目级的组织架构和职责。职责应明确到软件生命周期过程的每一个活动。也可以在此处仅描述每个软件生命周期过程所对应的组织，而在第8节描述软件生命周期过程活动时，针对每个活动表明其责任角色。
5 系统概述
5.1 系统架构及功能
简述系统的架构及该系统承担的主要功能点。系统架构应提供架构框图。
5.2 软硬件接口
描述软件与硬件之间的数据接口，如以太 接口、ARINC 429、离散输入输出等。应采用软硬件框图的形式描述软硬件之间的数据收发关系。
5.3 分配给软件的功能
说明系统承担的功能点中，哪些功能由软件来实现。
5.4 处理器
简要说明支持软件运行的处理器型 及本团队在相关型 上的使用经验。采用新的处理器型 可能会引起局方更多的关注。可能的情况下，最好不要采用多核处理器，会造成更高的审查成本，FAA有相关内容的说明，后续抽空再专门说明多核处理器的事项。
5.5 系统安全性
6 软件概述
6.1 软件功能概述
根据4.2节系统分配给软件的功能，进一步描述软件的功能实现，提供软件基本功能列表。
描述软件配置项划分、各配置项的标识和设计保证等级，应同时列出软件编 。如下表所示范例：
6.2 软件安全性
软件所采用的安全性策略，如软件的冗余设计、分区隔离、资源共享、单粒子翻转的处理、错误检测和处理、时间和任务调度等等。在此应尽量详尽描述每种安全策略的目的和实施方法。
7 合格审定相关
7.1 审定基础
范例：
XXX型 的合格审定项目编 为XXXXXX（该编 可向TC申请人索取），确立的合格审定基础为CAAC 25部1301及1309条款。
注：可能的情况下，还应包括局方与TC申请人所确定的使用与软件的咨询通告、会议纪要等。
7.2 符合性方法
范例：
本软件确定的符合性方法为RTCA DO-178C、RTCA DO-330、RTCA DO-331、RTCA DO-332及RTCA DO-333。
注：DO-178C为必选，其它标准为可选，应按照自身情况列举。如软件研制过程中使用的开发或验证工具需要进行工具鉴定，则应增加DO-330；如软件的需求或设计使用了模型技术，应增加DO-331；面向对象技术和形式化方法至今在型 机载软件研制过程中使用者凤毛麟角，索引DO-332和DO-333一般用不到。
7.3 软件设计保证等级的安全性分析
说明软件安全性等级的确定理由，列举能够触发相应失效条件的软件原因，必要时可将细节引用至PSSA（Preliminary System Safety Analysis）或FMEA(Failure Mode Effects Analysis)。
7.4 合格审定联络
范例：
本软件的合格审定联络过程由XXX公司（TC申请人公司名称）负责，本公司为合格审定联络过程提供支持，通过XXX公司向局方提供PSAC、SCI及SAS，同时应局方要求提供审查所需的其它文件或证据资料，以表明本软件的符合性。
7.5 计划的偏离
范例：
计划或标准文档在局方批准之前经由配置管理计划中的问题 告/更改控制流程（见x.x节）对文档进行更改。在计划及标准文档通过局方批准之后，任何与计划或标准的偏离将通过XXX（某种形式如协调单、会议等）告知申请人（XXX公司），与申请人共同决策。若确认需要更改计划或标准，则将更改内容通知局方，以决定是否需要重新批准。供应商内部将进行更改影响分析，以决定哪些受到影响的活动需要重新执行；若确认不需要更改计划或标准，则将偏离内容如实记录，最终写入软件完成综述（SAS::software accomplish summary）中。
注：上述过程最好能使用流程图形式详细定义。
8 软件生命周期过程
8.1 软件生命周期模型
简述项目采用的生命周期模型（建议图形形式描述，如V生命周期模型的图示）。
整体描述整个软件生命周期及各个生命周期过程活动。注意各个过程的详细描述应在对应的计划文档中详述，因此此处仅作概述。能说明各个过程之间的次序关系及主要活动，及如何满足各个过程的目标即可。描述目标的满足情况时，可对照DO-178C附录A每个表格的目标，以检查描述是否覆盖所有目标。可以分章节对各个子过程进行描述。描述每个过程活动时别忘了追踪数据的维护活动（包括系统分配给软件的需求到软件高级需求、软件高级需求到软件低级需求、软件低级需求到源代码、需求到测试用例、测试用例到测试规程及测试规程到）。说明时要说清楚维护追踪数据的方法。建议此处以表格形式列举各个过程活动及输出，以下再分章节进行文字描述。表格范例如下（范例以A级软件的要求为例，低级别软件视情裁剪。范例不全，仅作举例，实际应用前应补完整个生命周期过程活动）：
8.2 软件计划过程
略。
8.3 软件需求过程
略。
8.4 软件设计过程
略。
8.5 软件编码过程
略。
8.6 软件集成过程
略。
8.7 软件验证过程
略。
8.8 软件质量保证过程
略。
8.9 软件配置管理过程
略。
9 软件生命周期数据
本节应列表描述DO-178C第11章所描述的对应数据以及以何种方式让局方可见（直接提交或现场可查）。需注意的是此处所列举的应为对应该软件级别的，且在项目执行过程中会真正产生的数据，有些本项目不存在的可以不用列举（如参数数据项文件）。范例：
10 SOI审查进度计划
范例：
SOI#1软件计划阶段审查 2018年2季度
SOI#2软件开发阶段审查 2018年4季度
SOI#3软件验证阶段审查 2019年3季度
SOI#4软件最终阶段审查 2020年1季度
注：按照项目实际进展情况进行计划，实际审查在实施前两个月会再次进行三方商议，以确定具体审查执行时间。
11 其它考虑
11.1 先前开发软件
先前开发软件是指在其它飞机上已经使用且获得局方批准的软件。如果此次计划直接使用，或经修改后使用的，应在此进行相关说明。若未计划使用先前开发软件，此处写不适用。
对于先前开发软件，需说明的问题包括：
1. 是直接使用（无任何修改）还是修改后使用？安装环境较之前是否发生变化？
2. 如果决定复用，需提供哪些软件生命周期数据，以表明符合性？
3. 该软件有无任何开口问题（open problems）？
11.2 工具鉴定
是否有哪些工具需要通过工具鉴定？此处应列表说明所有软件生命周期过程中使用的工具，给出是否需要鉴定及其理由、需要鉴定的等级及工具的具体版本。范例：
11.3 替代方法
若计划全部或部分不采用DO-178C作为符合性方法，则在此应作说明。建议写不适用。任何不符合DO-178C的方法都很难说明符合性，也很难得到局方的认可。
11.4 选项可选择软件（option-selectable software）
某些软件可能为了灵活性考虑，把一部分参数在不固化在软件中，而是通过后来对选项进行重新选择来确定。如果软件是这种情况，应在此处说明。否则写不适用。
11.5 用户可修改软件
若软件在安装后，可以允许用户进行一定程度的修改，则属于此种情况。否则写不适用。
11.6 商用货架产品（COTS）软件
商用货架产品软件属于外购的市场上比较流行的软件，一般包括操作系统、驱动、第三方函数库等。由于这些软件广泛应用于多个行业，一开始设计时并未按照DO-178C要求的过程来开发，因此可能无法提供DO-178C所提供的生命周期数据，所以此处应说明供应商将计划如何证明其符合性。一般情况下，如果买了COTS软件且对方无法提供完整的软件生命周期资料，可能采用的方法有穷举测试（仅对于简单软件）、逆向工程或产品服务历史。没有的写不适用。
11.7 非激活代码
非激活代码指飞机起飞后不执行的部分代码。比如机载设备上的地面维护代码，或这在某些构型下执行，另一些构型下不执行的代码，有点像在低配车的行车电脑上屏蔽掉的原本只给高配车配备的某些软件功能。不管何种原因，如果有包含非激活代码，应在此处予以说明，需说明的内容包括：
1. 设计非激活代码的原因，及该段非激活代码在何种情况下使用。一般可能的使用场景是本机型的其它构型、本构型的其它安装位置、在飞机地面维护时或者也有可能是在本机型任何构型都不可能使用的，为适应市场需求而专门增加设计的其它功能（也就是说这个功能有些机型上可能会用，提前设计好的话，如果有机型需要这个功能，只需要把它激活即可）。
2. 为保证非激活代码不会被意外激活所采取的屏蔽措施。常见的屏蔽措施有芯片管脚选择控制及硬件分区等。
11.8 现场可加载软件
现场可加载软件能够在不拆卸驻留设备的情况下，直接在外场通过数据线对设备进行软件升级。升级过程可能由软件开发方、第三方维护公司或航空公司受训人员直接操作进行。对于现场可加载软件，应说明以下问题：
1. 说明现场可加载软件的研制过程。一般与普通机载软件相同；
2. 说明现场加载程序。现场加载程序应有专门的文件，计划阶段可能还未完成，但此时应至少说明该文件的编 及主要内容。主要内容应包括加载软件之前对软件版本及完整性的确认、软件加载过程的操作、软件加载完成之后的完整性校验及相关的记录，以及记录表单模板等等。
11.9 参数数据项
有些情况下，为了使软件的应用更灵活，会将某些公共参数提取出来从外部输入。以文件的形式，例如XML结构的文件，将这些参数项进行格式化描述，然后在后期统一进行读取和初始化。这个外部输入文件就被称为参数数据项文件，其中每一项参数就是一个参数数据项。若有这种情况，应说明这些参数的用途及范围，以及参数数据项文件的组织格式。没有的写不适用。
11.10 多版本非相似软件
多版本非相似软件是为了满足安全性要求，减少冗余软件之间可能产生的共因故障，针对两个软件采用不同的人员、不同的硬件基础、不同的环境工具而进行的开发。没有的写不适用。
11.11 补充标准对应的新技术
是否采用了基于模型的技术、面向对象技术或形式化方法。目前机载软件中很少有使用面向对象或形式化方法的，而基于模型的技术比较常用。如果使用了基于模型的技术，则应在第8节相应过程活动中写清楚哪些数据使用模型表示的，以及如何产生的。都没有的写不适用。
11.12 产品服务历史
一般不采用。如果必须使用产品服务历史的方法（一般是COTS）来表明软件的符合性，可参考DO-178C 12.3.4节进行描述。没有采用的写不适用。
12 分包商管控
如果软件承研商将部分或全部工作外包至其它单位。则此处应说明和分包商之间的任务分工、软件生命周期各个过程活动的接口以及软件承研商如何保证分包商开发的部分工作内容能够符合DO-178C的要求。
13 目标符合性映射表
范例：
> >>>（
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！