满足DO-178B标准的目标码验证解决方案-LDRA Testbed

合集下载

基于D0-178B的机载软件开发过程及其监控评审方法

图1软件生命周期过程
(SQAP),三个标准分别为软件需求标准
和软件编码标准。

申请人应就软件合格审定计划(PSAC)与合格审定当局
并获得其批准。

在软件开发过程中,申请人应一致地贯彻已确定的软件计划。

软件开发过程
软件开发过程包括四个子过程:软件需求过程、软件设计过程
件编码过程和集成过程。

其中,软件需求过程是指开发软件的高级别这些高级别需求包括功能、性能、接口和安全性有关的需求
件设计过程是指开发软件架构和能用于实现源代码的软件低级别需这需要一次或多次迭代过程;软件编码过程是指由软件架构和软件低级别需求实现源代码;集成过程是指把可执行目标代码加载到软硬件集成的目标硬件中。

软件开发过程应保持不同层次需求之间的追溯性
了所有预期功能,且没有实现预期功能以外的其它功能
无法追溯至上层需求的需求),必须进行安全性评估
软件整体过程
软件整体过程包括四个过程:软件验证过程、软件构型管理过程软件质量保证过程和合格审定联络过程。

其中,软件验证过程是为了检测和报告软件开发过程中可能已形成的错误。

验证不仅仅是测试分析等。

软件构型管理过程包含构型标识
线确定和软件产品(包括相关的软件生命周期资料)归档活动
量保证过程是指评估软件生命周期过程及其输出,以保证目标得以满故障得以检测、评估、追踪和解决,并保证软件产品和软件生命周期资料符合合格审定要求。

合格审定联络过程是指在整个软件生命周
助理工程师。

Science&Technology Vision
并对其监控评审方法进行了研究,在民用飞机机载软件。

才能为我国城乡建设积累知识。

满足DO-178B要求的软件需求开发方法

（国航空计算技术研究所，陕西西安７０６）中１０８
摘要：为了开发出一份满足适航标准Ｄ１８Ｏ－７Ｂ要求的机载软件需求规格说明书，在介绍ＩＤ１８Ｘ－７Ｂ对机载软件需求的要求和指出机栽软件需求存在问题的基础上，重点讨论了使用结构化激励响应（ＳＳＲ）方法开发软件需求的６个主要步骤。以飞行显示器软件的一个功能点为例，说明了使用ＳＲ方法开发的软件需求单元应该具有的７个主要组成部分以及每部分Ｓ
（ｉａＡｅｏａｔａｍｐｔｇＴｅｈｉｕｓａｃｎｔｕｅＣｈｎｒｎｕｉｌｃＣｏｕｉｃｎｑｅＲｅｅｒｈＩｓｉｔ，Ｘｉａ１０８ｎｔ ’ ｎ７０６，Ｃｈｎ）ｉａ
Ａｂｔａｔｓｒｃ：ＢａｅｎｔｅＤＯ－７Ｂｅｕｓｎｈｒｂｅｎｔｅｓｆｒｅｕｒｍｅｔｈｉｔｐｆｕｉｇｔｅｓｒｃｕｅｓｄｏｈ１８ｒｑｅｔａｄｔｅｐｏｌｍｓｉｈｏｔｗａｅｒｑｉｅｎ，ｔｅｓｘｓｅｓｏｓｎｈｔｕｔｒｄｓｉｌｓｒｓｏｓ（ＳｔｍｕｕｅｐｎｅＳＲ）ｍｅｈｄｔｅｅｏｈｏｔｒｅｕｒｍｅｔａｅｅｐｉｔｄｉｅａｌＯｍｅｔｔｅｒｑｅｔｔｏｏｄｖｌｐｔｅｓｆｗａｅｒｑｉｅｎｒｘｌａｅｄｔｉｔｅｈｅｕｓ．Ｔａｅｅ — ｃｎｋｎａｆａｔｒｎｔｅｆｇｔｉｐａｏｔｒｓａｘｍｐｅｈｅｅｏｏｅｔｎｈｉｍｅｎｎｓｉｈｅｕｒｍｅｔｕｉｏｅｅｐａｎｄｕｅｉｈｌｈｓｌｙｓｆｗａｅａｎｅａｌ，ｔｅｓｖｎｃｍｐｎｎｓａｄｔｅｒａｉｇｎｔｅｒｑｉｅｎｎｔｒｘｌｉｅ．ｉｄＡｅｓｂｅａｒｏｎｏｔｒｅｕｒｍｅｔｄｖｌｐｎｅｈｄｉｐｏｉｅｙｃｍｂｎｎｆａｉｌｉｒｅｓｆｗａｅｒｑｉｅｎｅｅｏｍｅｔｔｏｒｖｄｄｂｏｉｉｇＤＯ－７ＢｎＳｂｍｓ１８ａｄＳＲ．ＫｅｒｓＸ－７Ｂ；ＳＲ；ａｒｏｎｏｔｒ；ｓｆｗａｅｒｑｉｍｅｔｄｖｌｐｎｔｏ；ｄｖｌｐｎｔｐｙｗｏｄ：Ｅ）１８Ｓｉｂｒｅｓｆｗａｅｏｔｒｅｕｒｅｎｅｅｏｍｅｔｍｅｈｄｅｅｏｍｅｔｓｅ

基于DO—178的机载软件结构覆盖分析

基于DO—178的机载软件结构覆盖分析作者：左泽轩薛战东来源：《科技视界》2016年第15期【摘要】随着民用飞机机载软件的应用越来越广泛，软件复杂程度越来越高，按照DO-178设计保证指南进行机载软件开发逐渐成为行业规范。

机载软件测试是验证过程的关键，对测试结果的覆盖分析中的结构覆盖，DO-178仅提出了相关目标的抽象要求，在工程实际验证软件过程中不便理解和实现。

本文结合适机载软件工程实践，浅析对测试覆盖分析过程的理解。

【关键词】DO-178 机载软件结构覆盖 MC/DC【Abstract】With the wider use of airborne software on civil airplane， and its higher complicity， it is gradually becoming a common standard to develop the airborne software according to DO-178 design guidance. Airborne software test is the key method of verification process. But for structural coverage， which is a step of test coverage analysis， only general requirements has been claimed in DO-178， which leads to the inconvenience of understanding and realization for software verification in engineering. In this essay， combined with experience from both suppliers management and communication with airworthiness certification side， test coverage analysis process is explained from engineering side.【Key words】DO-178； Airborne Software； Structural Coverage； MC/DC0 引言随着电子信息技术的发展，机载电子设备和机载软件在民用运输飞机上的应用越来越广泛。

Testbed静态检验测试使用指南

目录1Testbed功能介绍 (1)1.1编程规则验证 (1)1.2数据流分析 (1)1.3控制流分析 (1)1.4表达式分析 (2)1.5接口分析 (2)1.6软件质量度量分析 (2)2使用Testbed 进行编码规则的定制和检查 (3)2.1确定测试需求 (3)2.2建立测试工程 (3)2.3定制代码分析规则 (6)2.4配置Report选项 (7)2.5分析执行及结果查看 (8)3结果分析及测试报告编写 (9)3.1质量度量信息的获取 (9)3.2程序质量度量报告单 (11)3.3静态分析质量报告单 (12)附录A：静态分析推荐规则使用说明 (1)1Testbed功能介绍1.1编程规则验证编程标准验证是高可靠性软件开发不可缺少的软件质量保证方法，使用LDRA Testbed 自动地验证应用软件是否遵循了所选择的编程规则。

编程规则由软件项目管理者根据自身项目的特点并参考现有的成熟的软件编程标准制定，如DERA（欧洲防务标准），MISRA（汽车软件标准），LDRA Testbed依据此规则搜索应用程序，并判断代码是否违反所制定的编程规则。

LDRA Testbed报告所有违反编程规则的代码并以文本方式或图形反标注的方式显示。

测试人员或编程人员可根据显示的信息对违反编程规则的代码进行修改。

1.2数据流分析LDRA Testbed分析软件中全局变量、局域变量及过程参数的使用状况，并以图形显示、HTML或ASCII文本报告方式表示，清晰地识别出变量使用引起的软件错误，此种方法既可使用于单元级，亦可使用于集成级、系统级。

通过Testbed数据流分析功能，可方便地分析出软件中一些可能的程序欠缺，如：1.没使用的函数参数；2.不匹配的参数；3.变量未赋初值就引用；4.代码中有多余变量；5.给值传递参数赋值；6.无返回值的函数路径；7.函数的实参是全局变量。

1.3控制流分析控制流分析检查以下内容：1.不可达代码；2.不合理的循环结构；3.存在浮点相等比较；4.函数存在多个出口；5.函数存在多个入口。

DO-178B

DO-178B 标准中有 6 个目标经我们的定量分析其目标指数为 2。这些目标实现起来具有一定的难度或需要付出一定的代价，然而它们的实施对机载软件的安全性所起的作用却并不是“极其大”。也就是说，如果在一定条件下适当放松了这些目标，对机载软件的安全性不太会带来极其大的影响。这一表述是前面定量分析的结果，而它们的合理性则可以从另外的角度来得到让人放心的诠释。
目标指数
3 代价系数 2
1
贡献系数
3
2
1
3
2
1
3
3
2
3
3
3
严格使用前面定义的贡献系数的文字描述（极其重要、很重要、一般重要）和代价系数的文字描述（很大、比较大、不大），我们可以用自然语言来很方便地解读目标指数的定义，详见下表：
目标指数 3
表示意义指数特征
贡献系数／重点关注代价系数
≥1
自然语言解读（针对军用飞机）这个目标极其重要，或者对安全的贡献极其大，不论实施该目标的代价有多大，都要重点关注这个目标很重要，或者对安全的贡献很大，实施这个目标的工作量却不是很大，我们要重点关注
2. 由于实施 MC/DC 覆盖的难度巨大，认证机构或 DER 在这一点上放松了要求：并不要求对整体机载软件进行 MC/DC 覆盖分析，而只需要对单个独立的功能模块达到这个要求。既然对民用飞机 A 级的适航认证都已经放松了这个要求，那么对于军用飞机的符合性审查又何尝不可呢。
5.3. 目标指数为 2
对于军用飞机来说，不同的国家会应用不同的标准。但是，目前的一个趋势是，许多国家姓“军”项目也逐渐开始走 DO-178B 路线。比较典型的有美国、法国、俄罗斯和中国（具体军机名称不便公开透露，对此有兴趣的朋友可以与我私下交流）。与民机不同的是，军机不需要做严格意义上、要求国际认可的“适航认证”，取而代之的通常是根据 DO-178B 标准做一个符合性（Compliance）审查。

DO-178B_cn

RTCA DO——178B机载系统和设备合格审定中的软件考虑签署和注记签署姓名签名更改历史更改单号发放日期作者更改描述版本号/修订号目录签名和注记 (2)更改历史 (3)1.0 引言 (9)1.1 目的 (9)1.2 范围 (9)1.3 与其他文件的关系 (9)1.4 怎样使用本文件 (9)1.5 文件综述 (10)2.0 与软件开发有关的系统情况 (10)2.1 系统和软件生存周期过程之间的信息流 (12)2.2 失效状态和软件等级 (13)2.3 系统结构考虑 (15)2.4 系统对用户可更改软件、可选择选项软件和商用成品软件的考虑 (16)2.5 系统设计对外场可加载软件的考虑 (16)2.6 系统需求对软件验证的考虑 (17)2.7 系统验证中的软件考虑 (17)3.0 软件生存周期 (17)3.1 软件生存周期过程 (17)3.2 软件生存周期定义 (18)3.3 过程之间的转换准则 (18)4.0 软件计划过程 (19)4.1 软件计划过程目标 (19)4.2 软件计划过程活动 (20)4.3 软件计划 (20)4.4 软件生存周期环境计划 (21)4.5 软件开发标准 (22)4.6 软件计划过程的评审和保证 (22)5.0 软件开发过程 (23)5.1 软件需求过程 (23)5.2 软件设计过程 (24)5.3 软件编码过程 (24)5.4 综合过程 (25)5.5 可追踪性 (26)6.0 软件验证过程 (26)6.1 软件验证过程目标 (27)6.2 软件验证过程活动 (27)6.3 软件评审和分析 (27)6.4 软件测试过程 (30)7.0 软件配置管理过程 (33)7.1 软件配置管理过程目标 (34)7.2 软件配置管理过程活动 (34)7.3 资料控制类 (37)8.0 软件质量保证过程 (37)8.1 软件质量保证过程目标 (38)8.2 软件质量保证过程活动 (38)8.3 软件符合性评审 (38)9.0 合格审定联络过程 (39)9.1 符合性方法和计划 (39)9.2 符合性声明 (39)9.3 提交给合格审定机构的最少软件生存周期资料 (39)9.4 与型号设计有关的软件生存周期资料 (39)10.0航空器和发动机合格审定综述 (40)10.1 合格审定基础 (40)10.2 合格审定的软件方面 (40)10.3 符合性确定 (40)11.0软件生存周期资料 (40)11.1 软件合格审定计划 (41)11.2 软件开发计划 (42)11.3 软件验证计划 (42)11.4 软件配置管理计划 (43)11.5 软件质量保证计划 (43)11.6 软件需求标准 (44)11.7 软件设计标准 (44)11.8 软件编码标准 (44)11.9 软件需求资料 (44)11.10 设计说明 (45)11.11 源代码 (45)11.12 可执行目标代码 (45)11.13 软件验证用例和规程 (45)11.14 软件验证结果 (46)11.15 软件生存周期环境配置索引 (46)11.16 软件配置索引 (46)11.17 问题报告 (46)11.18 软件配置管理记录 (47)11.19 软件质量保证记录 (47)11.20 软件实施概要 (47)12.0 其它考虑 (47)12.1 以前开发软件的使用 (47)12.2 工具鉴定 (49)12.3 替代方法 (52)附件A 按软件等级描述的过程目标和输出 (56)附件B 缩略语和术语汇编 (66)附录A DO—178文件的背景 (72)附录B 委员会全体成员 (75)附录C 术语索引 (76)附录D 改进建议表 (81)图和表的清单图图1—1 文件综述 (11)图2—1 在系统和软件生存周期过程之间与系统安全性有关的信息流 (12)图3—1 使用四种不同开发顺序的软件项目的例子 (19)图6—1 软件测试过程 (30)表表7—1 与CC1和CC2资料有关SCM过程目标 (37)表A—1 软件计划过程 (56)表A—2 软件开发过程 (57)表A—3 软件需求过程输出的验证 (58)表A—4 软件设计过程输出的验证 (59)表A—5 软件编码和综合过程输出的验证 (60)表A—6 综合过程输出的测试 (61)表A—7 验证过程结果的验证 (62)表A—8 软件配置管理过程 (63)表A—9 软件质量保证过程 (64)表A—10 合格审定联络过程 (65)AC 20—115B (82)出版说明RTCA DO—178B《机载系统和设备合格审定中的软件考虑》是美国航空无线电技术委员会为支持含有数字计算机的机载系统和设备的研制工作而开发的软件开发过程中应遵循的准则。

LDRA软件测试套件

T-VEC在适航认证中的成功应用案例分析背景描述：航空某所的某产品要通过适航认证，其中两个核心软件配置项被定级为DO-178B A级，适航当局按照DO-178B标准对软件测试工作提出了明确的要求。

挑战：按照DO-178B对A级软件的要求，其在相关章节对软件的验证过程和目标有明确的要求，其中关于低级需求的测试覆盖，以及测试用例设计是该项目的一个难点。

该项目源代码5万余行，其中有效代码行数2万3千余行，如果采用传统的测试手段，采用人工方式进行测试用例设计，人工方式的测试用例注入执行，人工方式的测试报告整理，该项目预计需要：项目应用情况：在该项目中，根据应用的特点，分别采用TTM和Simulink进行建模，然后导入到T-VEC 的TVGS中自动生成测试向量，再通过相关脚本自动将生成的用例导出为Testbed/TBrun支持的TCF格式，导入到Testbed/TBrun中进行自动回归，确认功能是否满足要求；同时在此基础上进行白盒覆盖率分析，根据覆盖率情况看是否需要追加测试用例。

最终将T-VEC生成的测试向量导出到报告生成系统自动生成word格式的测试用例说明报告；将Testbed/TBrun测试后的结果导出到报告生成系统自动生成word格式的测试报告。

在提交的问题单经过确认，代码经过修改后，使用脚本实现全自动化的回归测试。

项目收益：通过采用该方案，项目组总共花了160个人天，其中：取得了如下收益：项目规划准备20个人天；测试需求建模60个人天；测试执行20个人天；人工完善测试用例20个人天；问题分析提交报告及回归15个人天；测试报告生成及整理15个人天；测试相关自动化脚本编写调试10个人天。

共生成8300多个测试用例；提交经确认的问题报告单20个；全面达到前面列的DO-178B A级的相关要求；最终提交19000多页文档；顺利通过适航当局该阶段的审查；对比采用传统方式预计需要的时间，效率提高了4倍多。

面向适航标准的机载软件测试验证工具综述

2021，57（11）机载软件是安装在航空设备中作为核心控制作用的计算机软件，是一种典型的嵌入式软件。

随着嵌入式技术在航空航天领域的广泛应用，软件所实现的功能比例也越来越高，航电系统80%的功能都依赖于机载软件实现，机载软件已经成为机载设备系统的核心[1]，而因软件故障引起的事故时有发生。

2018年印尼狮航因为飞机搭载的自动防失速系统做出错误判断导致空难。

机载软件具有安全攸关（safety-critical ）的特性，因此所有机载设备软件以及飞机交联的软件系统进行安全认证才能投入使用[2]。

航空领域广泛采用的是美国航空无线电委员会（Radio Technical Commission for Aeronautics ，RTCA ）提出的航空适航认证标准DO-178C [3]及其增补标准。

基于适航认证标准的软件验证能最大程度上发现面向适航标准的机载软件测试验证工具综述刘友林1，2，郑巍1，2，谭莉娟1，2，樊鑫1，2，杨丰玉1，21.南昌航空大学软件学院，南昌3300632.南昌航空大学软件测评中心，南昌330063摘要：机载软件的测试与验证是保障机载软件正确性和可靠性的重要方法。

软件的测试与验证离不开工具的支持，使用工具能够提高效率、降低成本，对机载软件的测试验证工具研究是对其进行充分测试验证的保障。

对机载软件及适航标准进行了简介；按照系列适航标准，从DO-178C 、基于模型的开发与验证（DO-331）和形式化方法（DO-333）三个维度对工具的功能、特性及应用进行了详细介绍，并对其发展现状进行小结；总结机载嵌入式软件测试验证及其工具研发中存在的问题，并对其发展趋势进行了分析。

关键词：机载软件测试验证工具；适航标准；DO-178C ；基于模型；形式化方法文献标志码：A中图分类号：V247.1；TP311.5doi ：10.3778/j.issn.1002-8331.2101-0280Summary of Airborne Software Testing and Verification Tools for Airworthiness StandardsLIU Youlin 1，2,ZHENG Wei 1，2,TAN Lijuan 1，2,FAN Xin 1，2,YANG Fengyu 1，21.School of Software,Nanchang Hangkong University,Nanchang 330063,China2.Software Testing and Evaluation Center,Nanchang Hangkong University,Nanchang 330063,ChinaAbstract ：The testing and verification of airborne software is an important method to ensure the correctness and reliability of airborne software.Software testing and verification are inseparable from the support of tools.The use of tools can improve efficiency and reduce costs.Research on testing and verification tools for airborne software is a guarantee for adequate testing and verification.Firstly,it introduces the airborne software and airworthiness standards.Secondly,in accordance with the series of airworthiness standards,the functions,characteristics,and characteristics of the tools are analyzed from the perspectives of DO-178C,model-based development and verification （DO-331）,formal methods （DO-333）.The application is introduced in detail,and its development status is summarized.Finally,the problems in the testing and verification of airborne embedded software and the development of tools are summarized and the trends are analyzed.Key words ：airborne software testing and verification tools;airworthiness standards;DO-178C;model-based;formal methods⦾热点与综述⦾基金项目：国家自然科学基金（61867004）；江西省教育厅自然科学基金（GJJ180523）。

基于D0-178B的机载软件开发过程及其监控评审方法

基于D0-178B的机载软件开发过程及其监控评审方法作者：饶培峰，章晓春来源：《科技视界》 2015年第27期饶培峰章晓春（上海飞机设计研究院飞控系统设计研究部，中国上海 201210）【摘要】DO-178B自1992年颁发以来，一直作为航空业普遍认可的机载软件设计保证指南，FAA、EASA和CAAC等民航当局在对含软件的机载系统和设备进行适航审定时，都将DO-178B作为可接受的机载软件符合性方法。

本文结合民用飞机机载软件开发和评审的工程经验对相关适航标准和指导性文件进行解读，梳理了基于DO-178B的机载软件开发过程，并对其监控评审方法进行了研究。

【关键词】机载软件；DO-178B；工程评审；适航评审0引言DO-178B是美国航空无线电委员会于1992年颁发的机载软件指南，全称为《机载系统和设备合格审定中对软件的要求》[1]。

DO-178B并不属于民航法律规章，但FAA、EASA、CAAC等民航当局在对含软件的机载系统和设备进行适航审定时，都将DO-178B作为可接受的机载软件符合性方法。

DO-178B是基于对目标的符合性和设计保证等级来衡量软件的开发过程，其本质是一项软件设计保证标准，而不是软件开发标准。

本文介绍的基于DO-178B的机载软件监控评审方法有工程评审和适航评审有两类。

其中，工程评审是申请人对自己（或供应商）的监控评审，而适航评审是合格审定机构（CAAC）对申请人的监控评审。

机载软件工程评审与适航评审是相辅相成的，都是为了监控机载软件的开发过程，确保最终的软件产品符合DO-178B和其它适航要求。

1基于DO-178B的机载软件开发过程1.1与软件开发相关的系统情况在进行机载软件开发前，需考虑系统架构、系统和软件之间的信息流，并根据系统的安全性评估确定软件的研制等级。

DO-178B根据系统安全性评估将机载软件划分为A、B、C、D、E五个软件等级，不同的软件等级对应了不同的目标和为达到目标所需进行的开发活动，其中A级别软件的研制等级最高，所需符合的目标数也最多。

满足DO-178B标准的目标码验证方案

满足DO-178B标准的目标码验证解决方案概述随着软件测试需求的增加，软件测试在不同的行业的之间交叉的趋势呈现出来；公司在寻找最实际的技术和标准时，也会关注除本行业外，相关行业的情况。

例如在汽车和航空电子这两个行业，以前都基于DO-178B标准，随后也采用了MISRA的标准。

采用“行业外”的测试标准成为一种趋势并由此带来新的测试技术的引入。

在这当中，以DO-178B标准的目标码验证要求为例。

目标码验证是许多航空电子程序的一个关键测试要素，但是该技术并没有在行业以外的应用。

然而，许多现代嵌入式控制应用软件的尖端和安全苛刻的提高意味着随着厂商采用DO-178B，目标码验证也成为其中的关键要素，这个关键要素已经就位并正在被注意。

目标码验证什么是目标码验证呢？DO-178B标准（6.4.4.2结构化语言覆盖率分析）相应部分描述的需求如下：“结构化语言的覆盖率分析可以在源代码级进行，但是如果A级软件并且编译器产生的目标代码不能直接追踪到源代码中的语句。

那么，其他的验证要在目标代码中执行，这样来确定产生的代码序列的正确性。

在目标码中检查编译器生成的数组的边界就是目标码不能直接追踪到源代码的一个例子。

”简而言之，目标码的验证关心的是编译器产生的目标码的控制流结构的多少与源代码不一致。

这些不一致产生的原因有许多，如：编译器的解释、优化等。

然而，传统的结构化语言的覆盖率技术使用的是源码级的，尽管在处理器上执行的是目标码。

二者之间控制流结构的不同在测试过程中会产生重大的差距。

DO-178B的要求是：对于A级（安全苛刻性）应用软件的，按照标准的要求软件的开发者必须进行目标码的验证工作。

虽然这只是整个应用系统中的一部分，但是它仍然需要进行大量的测试工作，因此需要相当可观的人力和财力投入。

因此，自动化的，不依赖于编译器的验证过程可以节约大量的经费和时间。

LDRA的目标码验证方案LDRA已经认可并对各个行业部门对目标码验证方案越来越多的需求做出响应，提供了一套完整的结构化语言覆盖率分析方案，包含源代码和目标码，从单元到系统和集成级。

DO-178B标准

RTCA/DO-178B 系统和设备认证中的软件考虑因素机载系统和设备认证中的软件考虑因素RTCA / DO - 178 A由RTCA SC – 167 / EUROCAE WG – 12于1992年12月编制本文件副本可以从RTCA公司获得通信地址：美国华盛顿特区康涅狄格大道1140号电话：202 – 833 9339传真：202 – 833 9334有关价格和订购信息请与RTCA公司联系目录1 简介 (1)1.1 目的 (1)1.2 范围 (1)1.3 与其它文件的关系 (1)1.4 如何使用本文件 (1)1.5 文件概略 (2)2 有关软件开发的系统情况 (4)2.1 系统生命周期和软件生命周期之间的信息流 (4)2.1.1 从系统过程到软件过程的信息流 (5)2.1.2 从软件过程到系统过程的信息流 (5)2.2 失效状态和软件等级 (5)2.2.1 失效状态的分类 (5)2.2.2 软件等级的定义 (6)2.2.3 软件等级的确定 (6)2.3 系统体系结构的考虑因素 (7)2.3.1 分区 (7)2.3.2 多版本不相似软件 (7)2.3.3 安全检测 (8)2.4 系统用户可修改软件、选项可选择软件和商用现有软件的系统考虑因素 (8)2.5 现场可安装软件的系统设计考虑因素 (8)2.6 软件验证的系统要求方面的考虑因素 (9)2.7 系统验证过程中软件方面的考虑因素 (9)3 软件生命周期 (10)3.1 软件生命周期过程 (10)3.2 软件生命周期的定义 (10)3.3 过程之间的转换条件 (11)4 软件规划过程 (12)4.1 软件规划过程目标 (12)4.2 软件规划过程活动 (12)4.3 软件计划 (12)4.4 软件生命周期环境规划 (13)4.4.1 软件开发环境 (13)4.4.2 语言和编译程序方面的考虑因素 (14)4.4.3 软件测试环境 (14)4.5 软件开发标准 (14)4.6 软件规划过程的审核和保证 (15)5 软件开发过程 (16)5.1 软件要求编制过程 (16)5.1.1 软件要求编制过程的目标 (16)5.1.2 软件要求编制过程的各项活动 (16)5.2 软件设计过程 (17)5.2.1 软件设计过程的目标 (17)5.2.2 软件设计过程的各项活动 (17)5.2.3 用户可修改软件 (17)5.3 软件编码过程 (18)5.3.1 软件编码过程的目标 (18)5.3.2 软件编码过程的各项活动 (18)5.4 整合过程 (18)5.4.1 整合过程的目标 (18)5.4.2 整合过程的各项活动 (18)5.4.3 整合考虑因素 (19)5.5 可追溯性 (19)6 软件验证过程 (20)6.1 软件验证过程的目标 (20)6.2 软件验证过程的活动 (20)6.3 软件的审核与分析 (21)6.3.1 高层次要求的审核与分析 (21)6.3.2 低层次要求的审核与分析 (21)6.3.3 软件结构的审核与分析 (22)6.3.4 源代码的审核与分析 (22)6.3.5 整合过程输出信息的审核与分析 (22)6.3.6 校验数据和条件、测试步骤和测试结果的审核与分析 (23)6.4 软件测试过程 (23)6.4.1 测试环境 (24)6.4.2 根据要求确定的校验数据和条件的选择 (24)6.4.2.1 正常范围的校验数据和条件 (24)6.4.2.2 坚固性校验数据和条件 (24)6.4.3 根据要求确定的测试方法 (25)6.4.4 测试覆盖分析 (26)6.4.4.1 根据软件要求规定的测试覆盖分析 (26)6.4.4.2 结构覆盖的分析 (26)6.4.4.3 体系结构有效范围的分析解决 (26)7 软件配置管理过程 (27)7.1 软件配置管理过程目标 (27)7.2 软件配置管理过程活动 (27)7.2.1 软件配置的标识 (27)7.2.2 原始资料和可追溯性 (27)7.2.3 问题报告、跟踪和纠正措施 (28)7.2.4 更改控制 (28)7.2.5 更改审核 (29)7.2.6 配置状态统计 (29)7.2.7 存档、检索和发布 (29)7.2.8 软件加载控制 (29)7.2.9 软件生命周期环境控制 (30)7.3 数据控制类别 (30)8 软件质量保证过程 (31)8.1 软件质量保证过程的目标 (31)8.2 软件质量保证过程的具体活动 (31)8.3 软件符合性审核 (32)9 认证联络过程 (33)9.1 符合性措施及其规划 (33)9.2 符合性证据 (33)9.3 提交给认证主管部门有关软件生命周期数据的最低要求 (33)9.4 与典型设计有关的软件生命周期数据 (33)10 飞机和发动机认证概述 (34)10.1 认证基础 (34)10.2 软件方面的认证 (34)10.3 符合性确认 (34)11 软件生命周期数据 (35)11.1 软件认证计划 (35)11.2 软件开发计划 (36)11.3 软件验证计划 (36)11.4 软件配置管理计划 (37)11.5 软件质量保证计划 (37)11.6 软件要求标准规范 (38)11.7 软件设计标准 (38)11.8 源代码标准 (38)11.9 软件要求数据 (38)11.10 设计说明 (39)11.11 源代码 (39)11.12 可执行的目标代码 (39)11.13 软件验证校验数据和条件 (39)11.14 软件验证结果 (40)11.15 软件生命周期环境配置指标 (40)11.16 软件配置指标 (40)11.17 问题报告的编制 (40)11.18 软件配置管理记录 (41)11.19 软件质量保证记录 (41)11.20 软件完成情况综述 (41)12 一些补充考虑因素 (42)12.1 以前开发软件的使用 (42)12.1.1 以前开发软件的修改 (42)12.1.2 飞机计算机设施的改变 (42)12.1.3 应用或开发环境的改变 (42)12.1.4 原始资料编制过程的升级 (43)12.1.5 软件配置管理方面的考虑因素 (43)12.1.6 软件质量保证方面的考虑因素 (43)12.2 软件工具的质量检验 (43)12.2.1 软件开发工具的质量检验标准 (44)12.2.2 软件验证工具的质量检验标准 (45)12.2.3 软件工具质量检验数据 (45)12.2.3.1 工具质量检验计划 (45)12.2.3.2 软件工具的使用要求 (45)12.2.4 工具质量检验批准 (45)12.3 替代方法 (46)12.3.1 形式方法 (46)12.3.2 完备的输入信息测试 (47)12.3.3 多版本不相似软件验证的考虑因素 (47)12.3.3.1 多版本不相似软件的独立性 (47)12.3.3.2 有关多处理器的验证 (48)12.3.3.3 多版本源代码的验证 (48)12.3.3.4 多版本不相似软件验证的工具质量检验 (48)12.3.3.5 多模拟装置和验证 (48)12.3.4 软件可靠性模型 (48)12.3.5 产品使用史 (49)前言本文件是RTCA公司167专门委员会负责编制的，并于1992年12月经过RTCA公司同意。

DO-178B标准

RTCA/DO-178B 系统和设备认证中的软件考虑因素机载系统和设备认证中的软件考虑因素RTCA / DO - 178 A由RTCA SC – 167 / EUROCAE WG – 12 于1992 年12 月编制本文件副本可以从RTCA 公司获得通信地址：美国华盛顿特区康涅狄格大道1140 号电话：202 – 833 9339传真：202 – 833 9334有关价格和订购信息请与RTCA 公司联系目录1 简介 (1)1.1 目的 (1)1.2 范围 (1)1.3 与其它文件的关系 (1)1.4 如何使用本文件 (1)1.5 文件概略 (2)2 有关软件开发的系统情况 (4)2.1 系统生命周期和软件生命周期之间的信息流 (4)2.1.1 从系统过程到软件过程的信息流 (5)2.1.2 从软件过程到系统过程的信息流 (5)2.2 失效状态和软件等级 (5)2.2.1 失效状态的分类 (5)2.2.2 软件等级的定义 (6)2.2.3 软件等级的确定 (6)2.3 系统体系结构的考虑因素 (7)2.3.1 分区 (7)2.3.2 多版本不相似软件 (7)2.3.3 安全检测 (8)2.4 系统用户可修改软件、选项可选择软件和商用现有软件的系统考虑因素 (8)2.5 现场可安装软件的系统设计考虑因素 (8)2.6 软件验证的系统要求方面的考虑因素 (9)2.7 系统验证过程中软件方面的考虑因素 (9)3 软件生命周期 (10)3.1 软件生命周期过程 (10)3.2 软件生命周期的定义 (10)3.3 过程之间的转换条件 (11)4 软件规划过程 (12)4.1 软件规划过程目标 (12)4.2 软件规划过程活动 (12)4.3 软件计划 (12)4.4 软件生命周期环境规划 (13)4.4.1 软件开发环境 (13)4.4.2 语言和编译程序方面的考虑因素 (14)4.4.3 软件测试环境 (14)4.5 软件开发标准 (14)4.6 软件规划过程的审核和保证 (15)5 软件开发过程 (16)5.1 软件要求编制过程 (16)5.1.1 软件要求编制过程的目标 (16)5.1.2 软件要求编制过程的各项活动 (16)5.2 软件设计过程 (17)5.2.1 软件设计过程的目标 (17)5.2.2 软件设计过程的各项活动 (17)5.2.3 用户可修改软件 (17)5.3 软件编码过程 (18)5.3.1 软件编码过程的目标 (18)5.3.2 软件编码过程的各项活动 (18)5.4 整合过程 (18)5.4.1 整合过程的目标 (18)5.4.2 整合过程的各项活动 (18)5.4.3 整合考虑因素 (19)5.5 可追溯性 (19)6 软件验证过程 (20)6.1 软件验证过程的目标 (20)6.2 软件验证过程的活动 (20)6.3 软件的审核与分析 (21)6.3.1 高层次要求的审核与分析 (21)6.3.2 低层次要求的审核与分析 (21)6.3.3 软件结构的审核与分析 (22)6.3.4 源代码的审核与分析 (22)6.3.5 整合过程输出信息的审核与分析 (22)6.3.6 校验数据和条件、测试步骤和测试结果的审核与分析 (23)6.4 软件测试过程 (23)6.4.1 测试环境 (24)6.4.2 根据要求确定的校验数据和条件的选择 (24)6.4.2.1 正常范围的校验数据和条件 (24)6.4.2.2 坚固性校验数据和条件 (24)6.4.3 根据要求确定的测试方法 (25)6.4.4 测试覆盖分析 (26)6.4.4.1 根据软件要求规定的测试覆盖分析 (26)6.4.4.2 结构覆盖的分析 (26)6.4.4.3 体系结构有效范围的分析解决 (26)7 软件配置管理过程 (27)7.1 软件配置管理过程目标 (27)7.2 软件配置管理过程活动 (27)7.2.1 软件配置的标识 (27)7.2.2 原始资料和可追溯性 (27)7.2.3 问题报告、跟踪和纠正措施 (28)7.2.4 更改控制 (28)7.2.5 更改审核 (29)7.2.6 配置状态统计 (29)7.2.7 存档、检索和发布 (29)7.2.8 软件加载控制 (29)7.2.9 软件生命周期环境控制 (30)7.3 数据控制类别 (30)8 软件质量保证过程 (31)8.1 软件质量保证过程的目标 (31)8.2 软件质量保证过程的具体活动 (31)8.3 软件符合性审核 (32)9 认证联络过程 (33)9.1 符合性措施及其规划 (33)9.2 符合性证据 (33)9.3 提交给认证主管部门有关软件生命周期数据的最低要求 (33)9.4 与典型设计有关的软件生命周期数据 (33)10 飞机和发动机认证概述 (34)10.1 认证基础 (34)10.2 软件方面的认证 (34)10.3 符合性确认 (34)11 软件生命周期数据 (35)11.1 软件认证计划 (35)11.2 软件开发计划 (36)11.3 软件验证计划 (36)11.4 软件配置管理计划 (37)11.5 软件质量保证计划 (37)11.6 软件要求标准规范 (38)11.7 软件设计标准 (38)11.8 源代码标准 (38)11.9 软件要求数据 (38)11.10 设计说明 (39)11.11 源代码 (39)11.12 可执行的目标代码 (39)11.13 软件验证校验数据和条件 (39)11.14 软件验证结果 (40)11.15 软件生命周期环境配置指标 (40)11.16 软件配置指标 (40)11.17 问题报告的编制 (40)11.18 软件配置管理记录 (41)11.19 软件质量保证记录 (41)11.20 软件完成情况综述 (41)12 一些补充考虑因素 (42)12.1 以前开发软件的使用 (42)12.1.1 以前开发软件的修改 (42)12.1.2 飞机计算机设施的改变 (42)12.1.3 应用或开发环境的改变 (42)12.1.4 原始资料编制过程的升级 (43)12.1.5 软件配置管理方面的考虑因素 (43)12.1.6 软件质量保证方面的考虑因素 (43)12.2 软件工具的质量检验 (43)12.2.1 软件开发工具的质量检验标准 (44)12.2.2 软件验证工具的质量检验标准 (45)12.2.3 软件工具质量检验数据 (45)12.2.3.1 工具质量检验计划 (45)12.2.3.2 软件工具的使用要求 (45)12.2.4 工具质量检验批准 (45)12.3 替代方法 (46)12.3.1 形式方法 (46)12.3.2 完备的输入信息测试 (47)12.3.3 多版本不相似软件验证的考虑因素 (47)12.3.3.1 多版本不相似软件的独立性 (47)12.3.3.2 有关多处理器的验证 (48)12.3.3.3 多版本源代码的验证 (48)12.3.3.4 多版本不相似软件验证的工具质量检验 (48)12.3.3.5 多模拟装置和验证 (48)12.3.4 软件可靠性模型 (48)12.3.5 产品使用史 (49)前言本文件是RTCA 公司167 专门委员会负责编制的，并于1992 年12 月经过RTCA 公司同意。

符合DO178B的软硬件集成堆栈验证方法研究

应用研究
符合ＤＯ１７８Ｂ的软硬件集成堆栈验证方法研究
查振羽
（中国商Leabharlann 公司上海飞机设计研究院上海２００２１２）
摘要：由于某些错误只能在软硬件集成环境中才能被发现，且采用越接近真实设备的目标机硬件环境，获得的适航置信度越高，因￣，ＤＯ１７８Ｂ要求，在实际的机栽目标机硬件环境中需要运行相关的测试和验证，其中堆栈错误是软硬件集成中需要检验的重要错误之一。本文对软硬件集成的堆栈验证两类方法进行了研究和对比，总结出满足Ｄ０１７８Ｂ要求的软硬件集成堆栈验证方法。关键词：软硬件集成堆栈方法中图分类号：ＴＰ３１１．５２文献标识ｒａ￣－：Ａ文章编号：１００７－９４１６（２０１５）０７ — ０１０４ — ０１
命周期不定。开发者静态的指定栈内存空间，一般栈向下生长，如果栈空间不足，发生下溢，则栈之下的内存空间被写入，此时如果有内存保护的，则操作系统报异常。对于堆栈溢出的原因主要有以下几个方面：（１）在函数中定义的局部变量过多或数组的定义过长，在函数运
包括如下步骤：（１）对源代码进行编译，生成目标汇编码程序；（２）分析目标汇编码程序，形成各子函数的堆栈统计，包括局部变量、返回地址、调用函数的输入参数，被调用函数的栈帧地址等；（３）建立程序调用关系图：程序调用关系图的构建过程是对汇编码进行遍历，找出所有的子程序，在此基础上建立汇编码之间的调用关系；指令的目的地址即为子程序人口地址，从入口程序开始，分析入口程序后，便形成了最上层的调用关系图，然后依次类推，再逐个分析次层子程序，直至不再有新的子程序产生，并根据记录的信息，形成调用关系图；（４）根据调用关系图，选取若干最深路径，选取计算出最大堆栈占用情况。动态跳转指令使程序的控制流变得不确定，因此应该尽量少用；递归函数的每次递归调用都会使用子程序调用指令，堆栈开销很大；不平衡循环由于对堆栈的影响都循环次数的影响，很容易造成堆栈溢出，在子程序中直接修改ｓＰ时，在不同的地方调用该子程序会对堆栈产生不同的影响，也需要慎用。鉴于上述几种不确定因素对堆栈安全的危害性比较大，因此，可考虑制定编程规范对这几种情况进行约束。

我来说说DO-178B

现在，DO-178B 早就成了国际公认的民用航空机载软件的开发标准。一架民用飞机（相对军用飞机而言）不经过“民航标准体系”的适航认证，是不可以飞行的。而这个“民航标准体系”中，针对机载软件适航认证的，就是 DO-178B 标准。由此可见 DO-178B 的重要性。
四、 DO-178B 标准在中国的快速传播
我们可以简单地把飞机分成二类：军用飞机与民用飞机。许多国家对军用飞机的研制都有自己的标准和质量监督体系；但对于民用飞机说，由于一个国家研制的飞机会飞到其它国家去，这就要求有一套能够被国际普遍认可的标准和质量体系来保证飞机的安全。概括地说，飞机通常需要获得四个证书以后才可以真正投入运营：也即型号合格证（Type Certificate）、生产许可证（Production Certificate）、适航证（Airworthiness Certificate）、运营证（Operational Certificate）。这四个证书所涉及的法规、标准非常多，构成一整套庞大的体系，而 DO-178B 标准则是对机载软件进行适航认证时适用的标准，只是沧海一粟而已。
使得 DO-178B 标准长期稳定的主要原因是它改变了对机载软件开发做安全性保证的指导原则，从原来的“面向开发技术和开发方法”变成了“面向目标”。开发技术和开发方法随
• 第五阶段：应用。可以说，这是最难的一个阶段。标准的应用包括二部份内容：一是实施该标准，也即根据标准的要求来进行机载软件的研制，这主要是研制单位的职责；二是根据标准做适航认证，也即审核研制单位研制的机载软件是否符合 DO-178B 标准，这主要是认证机构的职责。DO-178B 标准的应用是“吃猪肉”的阶段。
值得欣喜的是，中国航空业的高层领导何等英明，当然早就认识到了这一点。他们采取了多方面的措施来提高国人对标准和认识、理解和应用的水平。据悉，相关单位已经多次邀请了国外的专家来做培训，并规划着如何引进外国专家、如何派人到国外学习等等多种手段，以期快速地提高中国人对整个民航标准体系的认知和应用水平。

目标码覆盖率分析在PPC目标环境中的应用

目标码覆盖率分析在PPC目标环境中的应用【摘要】提出了一种对编译器产生的目标代码覆盖率的分析方法。

传统的结构化语言的覆盖技术使用的是源代码级的，无法对编译器产生的代码进行验证，本文介绍了VerOCode软件在PPC目标环境中目标码覆盖率的分析验证。

【关键词】DO-178B；目标码覆盖；VerOCode1.引言目标码覆盖率分析技术是嵌入式软件系统质量保障的重要技术手段，目前在安全领域认可与使用的目标码验证要求来自于美国航空无线电技术委员会（RTCA）和欧洲民用航空设备组织（EUROCAE），为美国联邦航空管理局（FAA）以及欧洲航空管理部门的机载软件适航认证而制定的DO-178B/ED-12B标准。

DO-178B/ED-12B标准将软件安全等级分为A-E级，在DO-178B 6.4.4.2中要求：“覆盖率分析可以在源代码上开展，对于A级软件并且编译器产生的目标代码不能直接追踪到源代码的语句，那么需要对目标码进行额外的验证工作以确保产生的代码序列是正确的。

”这里提到的“基于目标码的额外验证工作”可以由目标码覆盖率分析来实现，即：编译器在编译过程中在目标码中添加了额外的代码，可以通过目标码覆盖率分析发现这部分代码，并且可以建立源代码与目标代码之间的关系。

而源代码覆盖率方法由于进行了代码插装，测试的对象已经改变了，无法对编译器多添加的代码进行验证。

在国外的适航认证经验中，目标码覆盖率分析已经得到广泛的使用，并且被适航认证局所认可。

2.目标码覆盖2.1 目标码覆盖的出处目标码覆盖的概念和要求在RTCA/DO-178B标准中明确提出，相关内容如下：结构覆盖分析的目的是确定在基于需求的测试过程中，哪些代码结构没有被执行。

基于需求的测试用例可能没有完全执行所有的代码结构，因此需要进行结构覆盖分析，并要求进行覆盖分析验证。

结构化语言的覆盖分析可以在源代码级别进行。

但是如果是DO-178B A级软件并且编译器产生的目标代码不能直接追踪到源代码中的语句，那么验证工作就需要采取额外地分析方法，即在目标代码的级别上验证编译器产生的代码序列的正确性。

基于DO-178C机载软件验证过程的研究

基于DO-178C机载软件验证过程的研究发布时间：2023-02-22T02:56:10.592Z 来源：《中国科技信息》2022年19期作者：冯义飞荣华[导读] 本文通过对RTCA DO-178C标准机载软件生命周期过程的研究冯义飞荣华中电科航空电子有限公司四川成都 610000摘要:本文通过对RTCA DO-178C标准机载软件生命周期过程的研究，分析了软件验证过程需要开展的活动，并提出了相应的实施方法，对后续机载软件研制过程中如何开展软件验证提供了参考。

关键字:DO-178C软件生命周期软件验证方法软件验证活动Research on Software Verification Process of DO-178CFengyifei Ronghua(CETC Avionics Co., Ltd., Chengdu, Sichuan 610000)Abstract:With the research of the airbornesoftrware life cycle process which focus on DO-178C standard, this paper analyze the software verification activities and the verification method.It will provide referrence for the software verification in the subsequent onboard software development process.KeyWord:DO-178C software life cycle, software verification method, software verification activies1概述随着我国民机的发展，机载软件的验证也变得越来越重要，为了满足适航标准要求，机载软件验证活动则需要基于DO-178C标准开展。