军用航空机载嵌入式软件第三方测评发展与挑战

2021-05-14 07:47杜百强
测控技术 2021年4期
关键词:嵌入式软件软件测试

杜百强, 孙 雷, 周 巍

(1.海装重大专项装备项目管理中心,北京 100045; 2.赛维航电科技有限公司,北京 101111)

软件测试按照执行主体分为3种模式:① 由最终用户开展的验收测试;② 由研制单位内部开展的自测试;③ 由独立的第三方测评机构开展的第三方测评[1]。军用软件第三方测评机构多成立于2000年左右,通过近20年的发展,基本建立了完整且具备持续改进的第三方测评体系和技术能力。

军用软件第三方测评机构成立时,军用航空器正处于第二代研制末期的升级改进阶段,影响飞行安全的航空机载嵌入式软件开始受到军方的关注,并委托具备GJB 2725A资质的软件第三方测评机构对航空机载嵌入式软件质量进行把关。软件第三方测评机构依据软件研制任务书、软件需求规格说明和软件设计文档开展第三方测评工作,主要工作内容是验证软件实现的正确性。2005年军方为规范软件定型/鉴定要求,出台了软件定型管理要求等法规。自此,软件第三方测评机构承担起对照研制总要求等顶层文件开展产品软件功能/性能考核、出具达标结论的工作。由于软件第三方测评工作对产品质量提升具有明显作用,产品缺陷大幅减少,严重质量事故降低效果显著,军用软件第三方测评机构在军方信任度逐年增长。军方连续发布一系列标准和规范,逐步细化和规范软件第三方测评机构的工作,指导第三方测评机构开展军用软件鉴定/定型测评任务,主要体现在:对申请设计鉴定/定型产品中驻留的软件实施考核、发现缺陷并负责归零验证、测评结论作为支撑产品鉴定/定型的重要依据。

历经10余年发展,国内航空器已发展至第四代,第四代航空机载嵌入式软件采用了综合模块化航电(Integrated Modular Avionics,IMA)系统、高速机载网络、基于模型的系统工程(Model-Based Systems Engineering,MBSE)和人工智能(Artificial Intelligence,AI)等技术,适合于第三代航空机载嵌入式软件的第三方测评技术已无法满足上述新技术的测评要求,形成的这段技术真空期是软件第三方测评需要应对的挑战。相较于技术要求和管理要求较为宽松的软件验收测试和内部测试,承担军用航空机载嵌入式软件质量把关责任的软件第三方测评对技术和质量的要求更加严格。为应对挑战,第三方测评机构需研究与之匹配的测评技术解决方案,并需要在这段技术真空期内通过把握一些测试重点在一定程度上保障软件的质量,直到解决方案技术成熟并完全实施。

本文回顾了军用航空机载嵌入式软件第三方测评发展历程,重点分析了第四代机载嵌入式软件技术的变革给软件第三方测评带来的挑战,提出了解决方案并总结测试重点,最后指出软件第三方测评的发展方向。

1 第三代机载软件第三方测评的发展

第三代航空机载系统研制过程中,以机载航电设备为代表的机载系统取得了突飞猛进的发展。硬件算力和嵌入式机载网络速率的大幅提升、嵌入式实时操作系统调度效能提高、可编程逻辑器件高效并行运算,大幅释放了机载嵌入式软件潜力,软件复杂度大幅提升,以某型飞机举例,其机载软件规模已逼近400万条语句级别。

一般情况下,软件规模的增长和复杂度的提升会导致软件缺陷数量呈指数级增长,依靠管理理念的转变和软件测评技术的发展,机载嵌入式软件缺陷数目整体呈现平稳且略显下降的态势,缺陷平均密度满足CMMI(Capability Maturity Model Integration,能力成熟度模型集成)2级到3级水平。

1.1 管理理念的转变

在第三代航空机载系统研制初期,研制单位依据GJB 2786-1996《武器系统软件开发》和GJB 438A-1997《武器系统软件开发文档》开展软件研发工作,第三方测评机构依据GJB/Z 141-2004《军用软件测试指南》和GJB 2725A-2001《测试实验室和校准实验室通用要求》开展软件第三方测评工作。

到了第三代机载系统研制中后期,软件在机载系统中扮演越来越重要的角色,现行软件法规标准逐渐不满足实际研制需求。2009年,总装备部修订发布了GJB 2786A-2009《军用软件开发通用要求》和GJB 438B-2009《军用软件开发文档通用要求》[2],同时航空军工产品定型委员会分别于2007年和2012年颁布了《航空军工产品配套软件定型管理工作细则》和《航空军用软件定型测评进入条件评估标准》,软件第三方测评机构在法规指导下依据每个飞机型号特点发布型号测评总体方案,更加严格地约束和指导软件第三方测评工作的开展。

在法规标准和管理规定指导下,军方、主机、研制单位和软件第三方测评机构各司其职,建立了完善的管理和工作流程。作为关键环节的研制单位对软件管理理念的转变是软件质量提高的最重要的因素,主要体现在以下三点。

① 软件需求需经过严格的外部评审和基线版本控制。由于早期软件研制人员随意编制和删改软件需求,软件需求存在大量遗漏和错误,导致软件测试不充分,从而引发了严重的事故。软件研制单位从中吸取教训,开始重视软件需求编制的质量和版本的管理。软件需求编制的质量是第三方测评充分性的最基本保证,随着软件需求质量的提高,软件第三方测评质量随之逐步提高。

② 软件第三方测评工作逐步受到软件研制人员的支持和认可。早期软件研制人员反感、抵制第三方测评工作,普遍认为软件第三方测评是额外的负担。但随着一次次可能引发事故的缺陷被发现和软件工程化的推进,逐渐转变了研制人员的观念。当前研制人员与软件第三方测评机构主动沟通、积极配合已成常态,为第三方测评顺利开展提供了有力支撑。

④ 软件研制单位逐步开展软件内部测试能力的建设。软件研制单位认识到软件测试的重要性后,纷纷建立了独立于软件研发团队的软件内部测试团队,通过与第三方测评机构的交流与学习,技术能力得以加强,成为第三方测评开展前第一道质量把关关口,为第三方测评准入条件检查提供了有力的保障。

1.2 软件测评技术的发展

软件第三方测评技术的发展主要体现在测试充分性不断提高、测评质量不断提升、测评能力的突破和创新性评价方法不断涌现这4个方面。

1.2.1 测试充分性不断提高

2000—2014年是我国第三代航空机载系统最主要的研制阶段,在这期间航空装备逐步进入软件定义装备时代。某型机载软件规模从初始型号40万行增长到改款型号370万行,由软件实现战技功能占比由30%提高到70%以上。随着软件功能的增加和管理要求的提高,软件需求类文档在完整性、统一性、准确性和条目化等方面实现了巨大的进步,充分性方面成绩最为明显,需求文档正文平均页数从21页增加到115.7页。

软件需求是制定第三方测试方案的直接依据,随着软件需求日趋完善,测试需求功能项在保证遍历正常流程的基础上,更注重异常流程、数据越界、接口数据丢包、多场景性能指标、安全性和恢复性设计、实战场景模拟等测试,设计的平均测试用例由初期的135.7个增长到1913.8个(上述数据来源于2000—2014年新研改进型号提交第三方测评统计数据)。由此可见,测试充分性得到了大幅提高。第三代机载软件第三方测试发展趋势如图1所示。

图1 第三代机载软件第三方测试发展趋势图

1.2.2 测评质量不断提升

早期软件第三方测评机构的每个测评项目处于相对独立的状态,根据自身经验分析需求、设计用例和开展测试,项目质量寄希望于项目组成员过往经验积累和责任心。测评机构为解决上述问题,逐步通过自研工具平台对大量测评经验和数据凝练整理,指导所有项目组开展工作,使整体测评质量维持在统一、较高的水平[3]。

自研工具平台在提升测评方案的编制水平、测试用例设计水平、文档自动化水平等方面作用明显,有效保证了测评质量,主要体现在以下3个方面。

① 测评方案是第三方测评的灵魂,直接决定测评质量。工具平台将与当前测评项目匹配度最高的前序型号测试经验推送给项目组,有效保证了测评方案的质量。近年来,测评方案编制的质量逐年提升,方案外审不通过情况呈逐年下降趋势。

② 工具平台通过对积累的软件缺陷数据进行整理分析,有针对性地指导测试用例的设计,保证了高缺陷率的软件功能模块验证的充分性。

③ 工具平台的文档自动化生成功能大幅提高了测评文档的编制效率。

第三方测评自身特点决定了绝大多数测评实施依赖实装设备和半物理仿真环境,需要测试人员手工操作实施验证,测评机构尝试研发通用测试平台替代半物理仿真环境,通过脚本仿真模式实现测试自动化,但由于第三方测评项目非连续性的特点和单一项目平台配置时效问题,导致这项技术尚不成熟、应用不广,是测评机构进一步提升测评质量的努力方向。

1.2.3 测评能力的突破

航空机载系统中FPGA和嵌入式软件相互配合共同实现机载系统的战技指标,软件第三方测评已如火如荼开展了10多年,FPGA测评一直处于标准研究、技术探索和项目试点验证阶段。

直到第三代研制末期,GJB 9433-2018《军用可编程逻辑器件软件测试要求》标准颁布,结合GB/T 33783-2017《可编程逻辑器件软件测试指南》和DO-254《机载电子设备硬件设计保证指南》,测评机构纷纷建立了完整、可持续改进的FPGA技术/质量体系,逐步开展FPGA第三方测评工作,测评能力实现突破[4],现某重点型号已全面开展FPGA测评。

1.2.4 创新性的评价方法不断涌现

当前软件第三方测评的评价分别对文档和程序开展评价。其中,文档的评价主要从齐套性、完整性、文文一致、文实一致、签署完整性等方面开展;程序的评价主要从软件缺陷率、注释率、需求功能点实现比率等方面开展。文档和程序评价均比较简单,属于较初级评价。

软件是智力的产物,具有很高的复杂性、不确定性和不可见性,因而增加了软件质量评价的难度[5]。目前并无业界公认的从软件第三方测评视角开展软件质量评价的方法,业内许多计算机专家和质量评价专家都在积极研究符合机载软件特点、科学合理的评价方法,相关学者使用专家咨询法、模糊综合评价法、优序法和层次分析法等评价方法[6]从不同的角度开展了评价研究,其中基于层次分析法更适合从软件第三方测评视角进行软件质量评价,如何进一步精准制定权重和降低评价复杂度是未来的突破方向。

2 第四代机载软件第三方测评的挑战

当航空机载系统从第三代跨越至第四代,机载软件研发技术实现了突破性发展,主要体现在以下4个方面:

① 全数字联合式架构向IMA架构转变;

② 高速机载网络取代多路传输数据总线成为主流;

③ 基于MBSE的软件已得到应用;

④ AI已在非关键、非控制逻辑模块开始应用。

当熟练掌握第三代机载软件测试技术的第三方测评人员仍忙碌在审查人工编写的程序源代码、在半物理仿真环境上根据确定的通过准则判断用例是否通过时,蕴含上述新技术的第四代航空机载系统嵌入式软件测评任务下达时,测试人员发现已有的测试技术已无法适用了,主要体现在以下4个方面:

① 被测设备软件变成了分区应用;

② 接口数据帧变成了网络数据包;

③ 审查的程序源代码变成了模型;

④ 客观判断准则变成了主观判断。

软件技术的代差在开始阶段让第三方测评机构措手不及,但随着不断探索新的测试技术,测试技术适应性问题将得以解决。

2.1 机载系统架构的转变

当前机载系统已从第三代全数字联合式架构全面转变为IMA架构,部署于综合核心处理机(Integrated Core Processor,ICP)上[7]。以某型机载系统举例,IMA体系架构的ICP采用多块通用处理模块(GPP)、通用处理及I/O模块(GPIO)、信号处理模块(SPM)、大容量存储模块(MSM)板卡组合,每块板卡采用多CPU结构,通过在每块CPU搭载的天脉II分区操作系统中驻留各功能域应用软件,实现红外搜索、通信导航、雷达电子战、悬挂物管理、战术任务管理等功能。第三方测评工作的重点和难点来自于各分区功能域应用软件。

2.1.1 IMA架构带来的挑战与解决方案

IMA架构将许多联合式结构的设备供应商转变为各功能域应用软件供应商[8],以某型机载系统为例,应用软件部署在天脉II分区操作系统特定的分区中,一个ICP就驻留了50余项软件配置项,软件规模超过了250万行。当软件第三方测评机构承接鉴定/定型测评任务时,功能性能试验、环境适应性试验、电磁兼容性试验、外场试验排故都在并行开展,ICP平台造价昂贵导致只有主机厂所联试环境可实施软件测评,第三方测评难以得到足够时间,测试环境资源成为最大的挑战。

文献[8]和文献[9]给出了通过构建分布式测试平台的解决方案,但仍需占用主机厂所联合试验环境,在根本上未解决测试环境资源抢占的挑战。笔者认为运用全数字虚拟仿真技术将IMA架构的ICP平台虚拟化,在虚拟仿真环境中运行天脉II操作系统和分区应用软件实施完整测试,再结合主机厂所联合试验环境进行补充验证,是解决IMA架构软件带来的挑战最有效的解决方案。

当前业内全数字虚拟仿真技术[10-12]已突破到PowerPC 555X系列,距离突破到天脉操作系统支持的PowerPC 8548、8640级别的CPU已指日可待。在基于全数字虚拟仿真技术的IMA架构测试平台研发成功且被认可之前,在有限的测评环境和周期内,第三方测评机构应抓住测试重点优先保证测试质量。

2.1.2 IMA架构测试重点

开展分区功能域应用软件第三方软件测评时需要重点关注以下6个方面:

① 测试就绪评审时确定分区蓝图(分区配置表)的状态与系统总体设计应保持一致;

② 分区间通信数据交换匹配性[9],分区软件在最繁忙状态下的通信功能是否正常,有无通信延迟、数据丢失等问题;

③ 分区软件死循环,除零溢出等缺陷都会触发分区操作系统复位,系统复位后是否会影响其他分区的正常工作;

④ 各个分区的存储空间分配是否独立、无重叠、时间分配是否满足CPU周期要求;

⑤ 在满负荷运行状态下分区的存储空间、周期时间余量是否满足分配要求;

⑥ 当多个分区软件进行了更改,回归测试时应做配置项和系统两级更改影响性分析,回归测试的顺序应符合测试策略。

2.2 新一代机载网络兴起

随着机载航电系统综合化、模块化程度的深入,以及数据通信在带宽、实时性、可靠性等方面需求的极大增强,交换式组网技术成为机载网络系统的首选。以光纤通道[13](Fiber Channel,FC)、航空电子全双工交换式以太网[14](Avionics Full Duplex Switch Ethernet,AFDX)和时间触发以太网(Time-Triggered Ethernet,TTE)为代表的新一代航电系统机载网络已经在型号上取得了应用[15]。

2.2.1 新一代机载网络带来的挑战与解决方案

当信号传输速率从HB6096总线100 Kbit/s、GJB 289A总线1 Mbit/s提高到100 Mbit/s的AFDX网络和10 Gbit/s的FC网络,机载网络可传输的数据量极大增加。一般情况下,软件研发人员不会为第三方测评工作专门开发适配接口控制协议(ICD)网络包解析软件。软件第三方测评机构开展接口数据帧遍历测试时,测试数据格式转换和测试用例执行的工作量呈指数级增长,给第三方测评工作带来了巨大挑战。

在项目研制初期与研制单位共同研发网络包解析软件,并结合接口自动化测试工具,是新一代机载网络接口遍历测试最有效的方案,会为测评工作带来极大便利。

2.2.2 新一代机载网络接口测试重点

若在无网络包解析软件和自动化测试工具的情况下,第三方测评工作应利用现有资源,重点关注以下3个方面。

① 与研发人员共同研制简单的网络包解析软件;

② 充分分析接口控制协议,采用等价类划分的方法对接口数据开展等价类划分工作,尽最大可能降低工作量;

③ 除验证帧格式正常测试外,还需关注异常接口测试、帧数据边界测试和帧数据滤波控制,特别是控制类帧命令的异常逻辑。

2.3 基于模型的系统工程的引进

空客A380约800万行代码是由高安全性应用开发环境(Safety-Critical Application Development Environment,SCADE)建模生成的,涉及电源、飞控、显控、导航、发动机等核心系统,极大地提升了软件的安全性和可靠性[16]。国内机载设备研制单位借鉴国际先进技术理念,从传统系统工程(Traditional Systems Engineering,TSE)向基于模型系统工程(MBSE)转变[17],并在民机领域取得了不错的成绩。

民机领域的基于模型的开发(Model-Based Development,MBD)是最先引入军机机载设备研制的技术,以模型的方式表达软件功能(包括软件架构和软件设计),再通过专用的工具直接生成软件源代码。以某型机载系统为例,电传飞行控制系统核心控制律软件、综合显控和平显软件使用SCADE模型工具开发,模型通过验证后,自动生成符合GJB 8114等一系列编码规范的C语言源程序,改变了传统研发模式。

2.3.1 MBSE带来的挑战与解决方案

相较于传统研发模式(采用自然语言描述软件需求和软件设计,人工编写软件源代码),MBSE代码自动生成技术使得第三方测评的静态测试对象由传统的软件源代码变为了模型,人工代码审查方法已不适用,如何证明模型的正确性给测评工作带来了挑战。

在民机适航验证领域,美国航空无线电委员会于2011年发布了DO-331《基于模型的开发与验证指南》和DO-333《DO-178C和DO-278A的形式化方法补充》,其中模型验证理念对基于模型开发的军用软件具有指导作用[18],构建基于模型的软件适航验证体系是最优解决方案。

2.3.2 基于模型验证架构和验证重点

在构建完善基于模型的软件适航验证体系(适航目标的符合性)前,结合当前军用软件管理要求,本文设计了模型验证架构,如图2所示,其中验证重点关注以下5个方面:

图2 模型验证架构图

① 模型评审,针对自然语言描述的需求和设计文档或建模语言的规范模型和设计模型开展充分的评审工作,包括模型与标准的符合性分析和模型的追溯性分析;

② 模型仿真,验证模型符合软件需求和软件设计;

③ 形式化验证,通过对模型安全性分析进行形式化建模,开展形式化验证,保证模型无非预期功能;

④ 目标机动态测试,在目标机上进行测试,与传统测试方法一致;

⑤ 在验证过程中开展需求覆盖分析和模型覆盖分析,需求覆盖分析验证所有的系统需求已经通过模型实现,模型覆盖分析验证模型没有非预期的功能。

针对使用SCADE工具研发模型,验证工作如表1所示。

表1 基于SCADE工具模型验证工作表

2.4 人工智能技术应用

当前,世界科技正酝酿着新突破的发展格局。以人机大战为标志,人工智能发展取得了突破性进展,并加速向军事领域转移,这必将对信息化战争形态产生冲击甚至“颠覆性”的影响[19]。

由于机载系统作战场景具有环境高复杂、博弈强对抗、响应高实时、信息不完整、边界不确定等特征,民用人工智能技术无法直接应用于军事领域[20],当前正处于逐步提升作战应用场景下感知、认知、决策和执行能力科研阶段[21]。

当前的机载系统中人工智能处于窄人工智能阶段,还未达到“类人脑”的通用人工智能,主要用于提升效能和辅助决策。

2.4.1 人工智能带来的挑战与解决方案

某型雷达/电子战系统在辅助决策模块使用人工智能算法去除杂波干扰,采用了深度学习模型中卷积神经网络(Convolutional Neural Networks,CNN)算法,通过对海量标注样本进行训练,使用多层非线性变换方法[22]大幅降低虚假目标检出率,为飞行员提供精确指引。以某型雷达/电子战系统训练的CNN算法为例,该系统具有海量的训练数据、复杂应用场景、单一目标检出的概率性、不断自我学习等特性,给第三测评带来了严峻的考验。

传统的航空机载软件第三方测评根据软件需求设计有限且明确的输入组合、预期结果和通过准则的测试用例,通过半物理仿真环境实施测试,得到测试结论。对该系统进行软件第三方测评时,传统的测试方法无法适用,如何构造具有足够泛化能力的测试样本数据、如何评价算法成熟度等成为软件第三方测评的最大难题。

针对当前应用的非类人脑AI算法,第三方软件测评机构首选外场试验或试飞数据作为测试样本,否则需构造足够大的测试样本数据,再通过查准率和召回率“定量+定性”评价算法模型的成熟度是符合当前技术阶段的解决方案,长远的技术解决方案是构建超级AI自动化测试平台验证AI软件。

2.4.2 人工智能测试重点

在当前技术解决方案下,针对嵌入人工智能算法的软件开展第三方测评时重点关注如下几个方面。

① 通过有无AI算法的两套软件对比验证,给出AI算法有效性评价。

② 设计有效的测试模型,形式化方法是解决途径之一。

③ 构建与训练数据比例合适(可以借鉴七三开模式)且足够大的测试样本数据,其中需包含微小输入变化测试样本,观察输出是否出现较大波动来验证算法的鲁棒性。

④ AI算法具备自身不断自我学习的特点,评价结论需增加时间维度。

⑤ 基于给定的场景开展性能测试。

⑥ 当AI算法测试不满足预期时,应从下述几个方面逐一考虑:测试样本数据是否符合要求、AI算法是否已完成了足够的训练、AI算法参数设计是否需要调整、AI算法本身是否符合实际应用场景。

3 未来发展展望

美空军在《全球地平线》中明确提出:针对“反介入/区域拒止”抵消战略由装备技术差异化转变为以快制慢,是否能快速引入新技术并生成战斗力将决定新“抵消战略”的成败。因此,预计国内为实现国土防卫战略,在未来几年机载系统可能会大规模应用新技术,提高防卫能力,主要表现以下4个方面。

(1) 机载系统架构进一步升级。

机载系统软件将逐步向下一代机载软件环境架构(Future Airborne Capability Environment,FACE)迁移,FACE架构采用分层思想,将功能软件以组件形式实现[23-24]。第三方测评机构应提前开展组件化、分布式部署和动态重构等测试方法的研究,开展基于FACE架构机载系统全数字虚拟仿真环境的研究。

(2) 机载网络迎来新一轮变革。

机载有线光纤网络将向无线航空电子内部通信(Wireless Avionics Intra-Communications,WAIC)网络[25-26]转变。第三方测评机构应预先开展无线网络测试技术和网络安全验证技术的研究。

(3) 民机适航理论在军机领域的推广应用。

随着MBSE在军品型号不断应用,民机适航理论已普遍得到军方科研项目管理部门认可[27-28],机载系统研制与试验过程将采用双流程模式,第一种流程模式是保持当前GJB 5000A/B软件研发体系和GJB 2725A第三方测评体系,第二种流程模式是全面采用DO-178C民机适航体系。第三方测评机构应提前建立软件适航验证体系,主要包含评审、测试和分析3个流程,其中分析流程是当前最大薄弱环节,主要包含:

① 源代码静态分析;

② 需求覆盖分析;

③ 结构覆盖分析;

④ 数据耦合和控制耦合分析;

⑤ 堆栈分析;

⑥ 最坏执行时间分析;

⑦ 运行时错误分析;

⑧ 仿真平台一致性分析;

⑨ 源代码与目标码一致性分析。

(4) 通用人工智能将得到广泛应用。

全场景的感知、认知、决策与执行的“类人脑”机载系统首先会在无人系统中得到广泛应用[29]。届时纯人工测试手段已无法满足测试要求,需大力推进自动化测试技术与人工智能、大数据等技术相结合的研究,实现超级自动化(Hyper-Automation),构建机器人之上的机器人[30],应用AI测试AI。

新技术的应用给软件测试带来了新的机遇和挑战,第三方软件测评机构应迅速反应,掌握新技术的背景知识、建立新技术的测试验证能力,尽可能缩短应用新技术软件研发与测试之间的适应期。

4 结束语

本文详述了机载嵌入式软件第三方测评已取得的发展,分析了当前由于新技术兴起而遇到的挑战,提出了解决方案和测试重点,并展望了机载嵌入式软件第三方测评未来的发展方向。

软件是技术更迭非常迅速的行业,不断涌现新的软件研发技术会牵引着新软件测试技术发展,需要软件测试人员不断学习和研究新测试技术,适应软件研发技术步伐,有效保障机载嵌入式软件的质量和安全。

软件第三方测评在今后的发展中要保证测试技术的先进性,与软件验收测试、内部测试在技术上相互促进,还需在评价方面取得突破,实现真正意义上的测试+评价。

猜你喜欢
嵌入式软件软件测试
禅宗软件
幽默大测试
基于人工智能的模块化嵌入式软件开发研究
“摄问”测试
软件对对碰
“摄问”测试
“摄问”测试
全景相机遥控器嵌入式软件V1.0 相关操作分析
即时通讯软件WhatsApp
基于Eclipse的航天嵌入式软件集成开发环境设计与实现