张 航 曹睿婷 杨帆 杨宏
(中航工业自控所,陕西 西安 710065)
民机机载软硬件过程对比分析及系统设计思考
张 航 曹睿婷 杨帆 杨宏
(中航工业自控所,陕西 西安 710065)
从标准本身出发,选取重点过程,横向比较DO-178B和DO-254 两份标准在设计保证等级C级层面的主要差异点,并对两份标准中的重点差异方面进行分析,最后提出了系统总体设计时应考虑的方面。
民机;机载软硬件;DO-178B;DO-254
近年来,随着可编程逻辑器件等硬件技术的不断发展,在开发成本和研发周期的优势下,硬件技术越来越多地应用于机载系统的开发中。例如,波音公司在B787飞机设计中,将飞控系统伺服监控的部分功能放在了远程电子单元REU的硬件FPGA中进行实现。
其实,上述实例中将软件功能通过硬件逻辑器件实现的现象,实际上是由于民机软硬件的研制指南DO-178B《机载系统设备适航审定的软件考虑》(以下简称DO-178B)和DO-254《机载复杂硬件设计保证指南》(以下简称DO-254)中的要求不一致所造成的,并且已经引起了多方的关注。Honeywell公司早在2001年DO-254颁布不久,就已经组织相关软硬件专家对DO-178B和DO-254 执行过程中的不一致进行分析,并已经指导系统工程师应用于后续的系统架构设计中。同时,欧洲适航局EASA近年来也收到了很多公司和个人有关DO-178B应用的咨询,其中相当大一部分是咨询有关软件开发指南DO-178B和硬件开发指南DO-254相关要求不一致的问题。
在EASA网站公布的问题答疑文件中,“Koch AvionicCert”公司曾咨询:“DO-178B和DO-254工具鉴定的要求不一致。DO-254的 D级硬件没有工具鉴定的要求。基于安全性的考虑,这些差异很难以理解。”就此问题,EASA答复:“EASA已经注意到这些相关的问题,EASA目前并无意愿去更改相关指南。”
在上述背景下,近期EASA也委托AIS宇航国际服务公司,对上述问题进行分析。从标准层面研究能否通过将部分软件功能在硬件平台上实现,也就是使用DO-254的审查方法来替换DO-178B,可以实现审查工作量的减少。
1.1 DO-178B概述
DO-178B的目的是为机载系统和设备的软件制造提供指南。上述指南以下列形式存在:
● 软件生命周期活动的目标;
● 为了满足这些目标而产生的一系列活动的描述和设计考虑;
● 目标被满足的证据的描述。
DO-178B包含了下列6个生命周期过程,具体如下。
● 软件计划过程:涵盖软件合格审定方面和开发/验证/构型管理/质量保证的计划;
● 软件开发过程:涵盖需求、设计、编码和集成部分;
● 软件验证过程:将验证作为评审、分析和测试的组合;
● 软件构型管理过程:涵盖构型项的辨识,基线和追溯性的建立,问题报告和更改评审的完成,软件归档和软件环境管理;
● 软件质量保证过程:确保在生命周期过程中没有偏离;
● 适航联络过程:在整个软件生存周期中在申请人和审定机构之间建立通信和相互了解,以促进合格审定过程。
1.2 DO-254概述
DO-254为复杂电子硬件的生产制造提供指南,目的是在满足适航要求的基础上交付一定置信度等级的复杂电子硬件产品。该指南由硬件生命周期过程的目标,设计考虑和满足该目标的活动描述,以及满足上述目标的证据描述组成。
DO-254适用但不局限于下列硬件:现场可更换单元(LRUs)、电路板组件、通用微代码部件、集成元器件和货架产品部件。
DO-254的组成与DO-178B类似,也包含了类似DO-178B的6个生命周期过程。
2.1 总体比较
从总体上来分析,两份标准都包含了3类基本的过程:计划过程、开发过程和支持过程(包含验证,构型管理,质量保证和适航联络过程)。两份标准的主要共性如下:
● 详细的计划过程;
● 都具有5种不同的开发等级;
● 追溯到详细的上级需求;
● 全面覆盖的测试要求;
● “由不符合到符合”的审查。
其主要不同之处体现在适用范围上,DO-178B的对象为机载设备CPU中运行的软件程序,而DO-254面向硬件可编程逻辑器件(如PLD、ASIC、FPGA)上的硬件语言。
DO-178B与DO-254类似,均是“目标”引导的指南性标准规范。对于两份标准来说,“目标”比“方法”更本质、更稳定。达成目标的方法可能会不尽相同,但是目标本身是不会改变的。因此,两标准强调的是一种目标导向的做法。
● 要求给出明确的功能和性能目标;
● 要求给出验证这些目标的方式;
● 要求给出达成目标的指标及证明。
2.2 差异性分析
为了更深入地比较两份标准的差异,这里将主要以设计保证等级C级的软件和硬件生命周期过程为出发点,从计划过程、开发过程、验证过程、构型管理4个主要方面进行比较和分析。
2.2.1 计划过程差异
计划过程的主要目的是定义满足系统需求和相关适航要求的软件/硬件实现途径。
表1将C级软硬件计划过程目标进行对比,从过程目标数量分析,C级软件计划过程要求比硬件计划过程严格,增加了两个过程目标,同时还要求定义过程的转换标准、内部关系和过程顺序。
表2将C级软硬件计划过程的交付物进行对比,可看出硬件过程比软件过程增加“硬件确认计划”,其主要规划了硬件级衍生需求的确认活动。C级软件过程较之硬件过程还要求编制质量保证计划和软件需求、设计和编码标准。
2.2.2 开发过程对比
开发过程的主要目的是开发满足系统相关需求的软件/硬件部件。
表2同时将C级软硬件开发过程交付物进行对比,可以看出C级软件过程要求比硬件严格,除了各自的需求文档,软件开发过程还需要生成设计描述、源代码和可执行目标代码,且后两份交付物还是1级控制类别(更加复杂的构型管理过程)。
2.2.3 验证过程对比
验证过程的主要目的是确保软硬件部件满足相关设计需求和已生成的验证计划。
将C级软硬件验证过程的目标数量进行对比,得到图1。
图1 C级软硬件验证过程的目标对比
从过程目标角度分析,C级软件验证过程目标数量与硬件过程对比差别悬殊,这主要是由于DO-178B将软件的验证过程分配到了软件设计的4个子过程(需求、设计、编码、集成)。除此之外,DO-178B对于验证过程本身也提出了具体要求。
以DO-178B中对于测试覆盖率的要求为例进行详述,测试覆盖率需满足表3中的具体要求。
(1)D级软件测试要求:需求覆盖
对于D级软件测试来说,需要保证测试基础与测试用例间的追溯性,也就是需要确认测试用例100%的覆盖到设计需求。
(2)C级软件测试要求:语句覆盖
表1 C级软硬件计划过程目标对比
表2 C级软硬件计划过程、开发过程交付物对比
表3 DO-178B中对于测试覆盖率的要求
对于C级软件测试来说,需要达到100%的语句覆盖的要求。以图2左半部分的程序为例,如果把每一行语句作为一个节点,可以生成中间部分的程序流程图,要达到100%的语句覆盖,至少需要图中右下角的两条语句。
图2 语句覆盖的要求
(3)B级软件测试要求:判定覆盖的要求
对于B级软件测试来说,需要达到100%的判定覆盖的要求(Decision Coverage)。判定覆盖是指测试需要覆盖所有可能的输出结果,也就是true (value 1) 或false (value 0)。如果以一条简单的逻辑(A and(B or C))为例,则需要生成如表4的两条用例,才能满足B级软件判定覆盖的要求。
(4)A级软件测试要求:修改条件/判定覆盖 MC/DC
对于A级软件测试来说,需要达到100%的修改条件/判定覆盖的要求(Modified Condition / Decision Coverage)。判定覆盖是指一个程序中,一种输入输出至少出现一次,在程序中每一个条件必须产生所有可能的输出结果至少一次,并且每一个判定中的每一个条件必须能够独立影响一个判定的输出,即在其他条件不变的前提下仅改变这个条件的值,而使判定结果改变。如果以相同的逻辑(A and(B or C))为例,则需要生成如表5的6条用例,才能满足A级软件判定覆盖的要求。
表4 判定覆盖DC的覆盖率要求
然而从DO-254中可以看到,硬件语言还没有形成上述具体分级别的验证覆盖率要求,在许多情况下,它取决于DER(委任工程代表)或者认证机构来决定。目前通常要求需求覆盖和语句覆盖,偶有特别要求做到了判定覆盖。但是,软件和硬件语言是明显不同的,其覆盖率机制和指标也是不尽相同的。
表5 MC/DC的覆盖率要求
2.2.4 构型管理过程对比
构型管理过程的主要目的是确保构型项的更改和管理始终在受控制的状态。DO-178B和DO-254规定了两种构型管理状态:1级构型管理(CC1/ HC1)和2级构型管理(CC2/HC2),其中1级构型管理主要针对受控严格的重要文件,较为复杂。与DO-178B相比,DO-254中的1级构型管理活动缺少“更改评估”和“构型状态记录”两个活动。
更改评估的主要目标是确保所有的问题和更改均已被评估、批准或否决。批准的更改确保执行,且通过问题报告和相关更改控制方法报告受影响的相关过程。构型状态记录的主要目标是为构型管理活动提供关于构型辨识、基线、问题报告、更改历史和更改控制的数据。
2.2.5 C级软硬件总体过程对比
“目标”是DO-178B和DO-254的基础,是必须满足的最低要求。将C级的软硬件过程目标数量进行对比分析,可得表6。
表6 C级软硬件生命周期过程目标数量
从表中可以看到,C级软件的总体目标数量为55个,C级硬件目标数量为31个,同时可以看出,C级软件质量保证过程的两个目标还需要进行独立验证。
经过上述针对DO-178B和DO-254的对比可以发现,民机机载软硬件研制过程在以下几个方面要求有较大的差异。
过程目标数量及要求;
交付物数量;
验证过程要求及复杂程度;
1级构型管理活动。
基于上述差异,建议系统工程师在系统总体设计过程中,尤其是架构分配时考虑如下原则:
同等条件,硬件优先。
在民机系统设计中,在可行性相同的条件下,对于成熟的功能模块,尽量采用硬件实现。
复杂功能,软件复用。
尽量复用已经成熟的、经适航验证和审核过的模块,可大大减少开发、验证、适航认证的成本。
新研功能,模块划分。
对于复杂系统功能设计必须采用软件实现时,应充分考虑今后的可复用性,从系统级就应开始考虑软件的模块化设计。成熟模块可复用至后续型号,减少开发和适航成本,同时将相同设计保证等级的软件模块一同处理考虑,避免了验证和认证的复杂性。
[1] DO-178B. Software Considerations in Airborne Systems and Equipment Certification [S]. Washington, D. C: RTCA. Issued 12-1-92.
[2] DO-254. Design Assurance Guidance for Airborne Electronic Hardware [S]. Washington, D. C.: RTCA. Issued 4-19-00.
[3] EASA. FAQS file for the software certification standard [DB/OL]. CM-SWCEH-002 Issue 1 – Software Aspects of Certification – Comment Response Document. http://www.easa.eu.int/.
[4] DO-178B / DO-254 deliverables templates content summary [DB/OL]. http://www.faaconsultants. com/.
(编辑:雨晴)
V271
C
1003–6660(2014)04–0053–04
10.13237/j.cnki.asq.2014.04.014
[收修订稿日期] 2014-04-02