军用与民用机载软件开发标准和流程的对比研究

军用机载软件开发标准主要是GJB 2786A《军用软件开发通用要求》,民用机载软件开发标准主要是DO-178B/C《机载系统和设备合格审定中的软件考虑》。针对这两份标准进行了对比研究和差异分析,对于完善军用软件研发标准体系和流程有一定意义。     

DO—178A《机载设备和系统合格审定中软件要求》的使用说明

1.综 述 1.1.DO-178A《SOFTWARE CONS IDERATION IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICATION》,中文译名为“机载设备和系统合格审定中软件要求”。以下简称“软件要求”。该文件是RTCA(美国航空无线电技术委员会)执行委     

航空嵌入式软件测试环境确认方法研究

通过对国军标与DO-178B对航空嵌入式软件测试环境确认要求的对比与分析,提出了一种满足国军标与DO-178B要求的航空嵌入式软件测试环境确认方法。实际运用表明,方法灵活、高效、可操作性强,可以满足航空嵌入式软件测试环境确认的要求。     

从DO-178C的新变化透视软件适航关注点

深刻理解DO-178C标准对于提升机载软件开发能力具有重要意义。分别从软件生存周期过程活动和过程目标两个维度对比和分析DO-178C与DO-178B的差异,按照计划过程、开发过程、验证过程、配置管理过程、质量保证过程和合格审定联络过程分类,列举了每个过程新增的或变更的考虑内容,并详细分析了过程目标的变化。根据差异分析,从强调以目标为中心、源代码到目标码的映射、参数数据、双向追踪、基于需求的鲁棒性测试和耦合性验证6个方面解析了DO-178C强调的思想,并总结了一些可行的实践。     

RTCA/DO 331标准研究

为推动基于模型的开发和验证技术的发展,同时为了给机载软件基于模型的开发和验证活动提供合格审定指南,美国航空无线电委员会于2011年发布了DO-331《基于模型的开发和验证》标准,作为对DO-178C《机载系统和设备合格审定中的软件考虑》标准的补充。该文主要从DO-331文档的组织架构编排,模型的使用和分类,基于模型研制相关的软件生命周期过程、数据和符合性验证目标几个方面对其进行了提炼和解读,可帮助应用该标准的人员快速理解文档的核心内容,并把握基于模型的开发和验证相关的合格审定关注点,从而在项目实施过程中更好地表明适航符合性。     

民机适航软件工具鉴定考虑

软件工具在航空器研发过程中所起的作用越来越大,为了保证民用飞机的安全性,DO-178B对在民用飞机研发过程中所使用的软件工具提出了鉴定的要求。为了规范工具鉴定过程,伴随着DO-178C的发布,RTCA专门发布了工具鉴定指导文件DO-330。通过对DO-178B、DO-178C、DO-330中有关工具鉴定内容的对比和分析,明确了最新工具鉴定的分级定义、工具鉴定的过程和目标;针对当前广泛使用的COTS工具,描述了工具鉴定应考虑的因素。为按照民机适航要求开展工具鉴定工作提供了指导。     

机载设备软件需求获取过程研究

DO-178B机载设备软件的开发指南,规定了软件生存周期中各个过程的目标以及完成目标的活动和证据;但是DO-178B标准中没有给出软件需求获取的具体过程.针对机载设备软件AE653/Cert的认证过程进行研究,诠释需求获取过程中的建模方法和原则,给出需求获取过程的具体描述及其变更控制和配置管理.最后通过分析验证软件需求获取过程生成的需求和工作产品可以符合DO-178B的目标,为机载软件开发过程的需求获取提供了参考依据.     

机载适航标准DO-178B/C软件开发过程研究

介绍了DO-178B/C标准的发展历程,结合对DO-178B/C标准机载软件生命周期过程的研究,分析了机载软件开发过程需求、设计、编码和集成子过程的关系及输入输出数据,在分析机载软件需求、设计、编码及集成子过程的目标、活动和转换准则的基础上,给出了各子过程的过程模型.展望了DO-178B/C标准的未来研究方向.     

基于DO-254的控制系统电子硬件符合性研究

机载电子硬件设计保证指南（DO-254）是目前航空业认可的用于指导机载电子硬件的文件。本文介绍了基于DO-254的控制系统电子硬件符合性研究,分析了DO-254要求的机载电子硬件主要研制过程,建立了基于DO-254的控制系统电子硬件研制流程,并对比了美国联邦航空局（FAA）和欧洲航空安全局（EASA）在合格审定过程中的考虑因素,总结了控制系统电子硬件的符合性方法,可为未来民用航空发动机控制系统电子硬件的适航取证提供参考。     

数字式机载电子设备软件适航合格审定指导准则RTCA/DO—178A介绍

由美国航空无线电技术委员会(RTOA)于1985年颁布的DO-178A“机载系统和设备合格审定中的软件要求”,是为使用微机技术实现机载设备设计的开发者,安装者和用户制定的软件适航合格审定指导准则。它已成为国际民用航空界公认的机载软件合格审定的指导性文件,并被大多数开发机载系统和设备软件的公司和机构所采用。美国联邦航空局(FAA)直接参与制定并确认了本文件。在FAA的技术标准规定(TSO)中有明确规定,凡是以数字计算机为基础的机载电子设备,其适航合格审     

民机主制造商对MBD软件供应商工程监控过程研究

基于模型的软件开发技术(Model-Based Development,简称MBD)具有可视化建模与仿真、自动生成符合适航要求的代码等特点,已在民用飞机机载设备研发领域被逐渐推广应用。越来越多使用MBD技术开发的机载软件的涌现,给民机机载软件适航符合性工作带来了前所未有的挑战。为解决这一问题,美国航空无线电技术委员会于2011年底发布了DO-178C作为民用航空界认可的机载软件符合性方法,并在此基础上发布了DO-331作为专门针对机载软件MBD技术的适航符合性要求的补充说明。通过对DO-178C和DO-331标准中MBD软件适用目标的研究,结合工程实践,总结归纳了一套民用飞机主制造商对MBD软件供应商的软件研发过程管控要求,用于在向适航当局表明符合性时提高适航置信度,以期对主制造商和供应商在处理MBD软件方面提供参考。     

民用航空产品研发和审定活动中的需求分析与管理问题研究

研究了民用航空产品研发和审定过程中有关需求分析与管理的若干问题。总结了开展需求分析和管理过程的步骤和关键要素。阐明需求分析与管理在民机研发和审定过程中的重要作用。分析了当前我国在民用航空产品研发和审定过程中存在的问题。提出解决我国民用航空产品研发和审定过程需求分析和管理突出矛盾的方案。     

基于模型的大气数据计算机实现

针对无人机用大气数据计算机,为使其满足适航审定要求,提出基于模型的实现方法。首先介绍了大气数据计算机获取适航的方式,并以获取技术标准规定项目批准书(CTSOA)为驱动,按照大气数据计算机CTSO标准提出满足最低性能标准的系统需求,将系统需求进行分解选择合适的传感器及硬件平台。随后对系统功能进行详细设计,并按照DO-178B规范完成大气数据计算机的模型搭建和仿真验证。验证结果表明,基于模型的大气数据计算机满足系统所提各项指标,开发流程符合DO-178B标准。     

基于DO一178B的结构覆盖分析研究

结构覆盖分析（SCA）是基于DO一178B的软件验证的重要组成部分。由于DO一178B仅提出目标活动要求,不提供具体的工程技术方法,如何进行结构覆盖分析是困扰国内航电软件开发和验证的一大难题。通过与国外航电设备厂商的多年的软件国际合作,以及对DO一178B软件结构覆盖分析具体要求的深入研究,提出了一个结构覆盖分析过程和具体的实现方法。在多个软件国际合作项目中的实际应用表明,的研究成果满足DO一178B结构覆盖分析的要求。     

RTCADO-178B标准与相关国军标的对照分析

RTCA的DO-178B标准是国际认可的开发准则,将DO-178B与我国的国标进行了对照分析,给出了异同。     

基于DO-178C的机载软件质量保证与管理

DO-178C 作为机载软件适航可接受的符合性标准,明确要求机载软件综合过程中必须包含软件质量保证（SQA）过程。以机载软件的软件生命周期定义、过程和数据为基础,从目标、活动和符合性评审三个方面分析基于DO-178C 的软件质量保证过程的实施;结合软件项目质量管理技术和工具,从规划软件质量管理、管理软件质量和控制软件质量三个过程研究基于DO-178C 的软件质量管理方法并给出工程实践建议。结果表明：本文将软件质量保证与质量管理紧密结合,形成了适航要求的相关证据,提供了符合需求的民用机载软件,有效保证了机载软件的质量和持续改进措施。     

Independent validation and verification of the TCAS II collisionavoidance subsystem

This paper describes the specification-based testing, analysis tools, and associated processes used to independently validate, verify, and ultimately, provide for certifying safety-critical software developed for the Traffic Alert and Collision Avoidance System (TCAS II) program. These tools and processes comprise an effective and Independent Validation and Verification (IV and V) activity applied to the Collision Avoidance Subsystem (GAS) software development process. A requirements specification language called the Requirements State Machine Language (RSML), originally developed by the University of California, Irvine (UCI), was employed for the specification of GAS. The end result is the next generation of TCAS II collision avoidance logic, referred to as Version 7, that is of a higher quality than its predecessors, meets the certification requirements of DO-178B Level B (Ref. 1), and can be shown to satisfy the new operational requirements it was developed to address