在开发驻留在IMA系统中的UA软件时, 需要对UA本身的人机界面进行定义和设计, 并且开发负责与IDU通信的ARINC 661协议模块以及存储和管理界面控件的模块. 同时负责生成一个符合A661协议的DF文件, 包括了所有UA定义的图形控件, 用于IDU加载, 使得该UA的界面得以显示. UA代码中对图形控件的定义和加载在IDU上的DF文件中的定义必须一致, UA才能提供完善的功能供飞行员使用. DF文件由UA开发人员创建, 却加载在CDS开发人员提供的IDU上. 因此, 对于和DF相关的需求和验证, 就应该由UA开发者和CDS开发者共同承担, 这就是当前国内民机项目研制时, 需要解决的, 且在国外民机项目中所没有的问题. 对于有丰富的民用航空系统研发经验的Rockwell Collins, Honeywell和GE等公司来说, 他们参与的民用飞机项目中, 是将DF文件的所有开发和验证, 全部交由CDS开发者完成. 根据业界的经验总结, 这样的解决方案会出现以下这些普遍性问题:

(1) UA开发者和CDS开发者的沟通不当, 如UA需求的理解或表达不当, 会导致CDS开发者开发的DF文件不能支持UA的功能.

(2) UA功能的频繁更新, 导致DF文件的更新不一致.

(3) CDS开发者更新控件库, UA开发者不能同步修改相关功能以及控件属性.

(4) UA开发者只能等待DF文件开发完成后, 才能进行自己的界面交互功能验证, 在验证执行中, 多以接口(ICD)方式进行验证, 这种验证方式不直观, 不能准确表达飞行员的真实感受.

(5) CDS开发者工作量巨大, 需要完成所有UA的DF文件设计, 并且在等待UA开发者完成开发后, 才能进行DF文件和UA的联调, 开发周期较长.

综上所述, 传统的DF文件开发方式, 容易出现多次的异步同步问题, 导致开发周期延长, 追踪性不完整, 工作协调复杂, 耗费大量人力物力. 因此, 我们在国内民用飞机系统中, 首次尝试由UA开发者承担DF文件的开发任务. UA开发者可以按照软件的需求, 开发满足需求的DF文件, 最后将DF文件交付给CDS开发者, 统一进行集成测试.

由于DF文件并不是可执行代码, 因此, 验证方式与典型的民用航电系统软件方式有所不同. 为了达到DO-178C的要求和CAAC对软件的审定要求, DF文件的验证必须采取分析, 评审和测试的综合方式, 达到最终的验证目的. 民用飞机的研制是一个巨大的系统和工作, 包括波音和空客, 均采用全球供应商模式, 类似于DF文件这样需要多个供应商共同承担验证的情况日益趋多, 本文介绍的仅仅是UA开发者对DF文件的验证方式^[1,2].

1 Definition File

目前, 主流的民用飞机采用的是CDS来进行显示控制. CDS包括多个IDU, 每个IDU提供一个ARINC 661 Server. ARINC 661 Server的主要工作包括:

(1) 定义界面大小, 位置, 形状等公共窗口属性.

(2) 发送握手协议, 与UA建立会话, 维护通信.

(3) 加载DF文件.

(4) 发送保活报文, 监控UA状态, 管理会话和通信.

由于民用飞机航电系统软件的高安全性的特性, C级以上的软件多数都有显示备份, UA可以和两个或两个以上的IDU进行通信. 通信并不表示可以显示, 只是该IDU具备了显示该UA的配置. 一般情况下同一个UA界面可以同时在2个或2个以上的IDU上进行显示. ARINC 661 Server负责管理显示事件, IDU在系统配置时, 获得显示某个UA权限后, 将与UA建立通信, 在收到显示事件后, 加载该UA的DF文件. 需要在IDU上进行显示的UA, 直接和相应的IDU上的ARINC 661 server进行通信. DF文件就是用于UA和IDU进行通信的静态非可执行代码数据. 因此, DF文件必须包含以下内容:

(1) UA页面的架构信息, 页面之间的树形关系.

(2) 每一个页面的控件信息及其属性.

(3) 页面之间的逻辑关系, 页面之间的跳转, 按钮链接的界面信息.

UA开发者使用SCADE DISPLAY工具, 加载由CDS开发者提供的workplace(定义了控件属性), 通过画图的方式, 完成界面设计. SCADE DISPLAY工具自动生成DF文件, 生成的DF文件有三种格式, 分别是Binary, XML和Hexa, 同时生成记录DF文件生成过程的日志文件.

首先需要说明的是, 参照DO-178C的section 2.5.1, “A data set that influences the behavior of software without modifying the Executable Object Code and is managed as a separate configuration item is called Parameter Data Item”. 尽管DF文件是和UA结合开发, 但是并不在UA的目标机上加载, 因此DF文件并不会影响UA的运行, DF文件不是UA的参数数据项. 相反, 部署在IDU上的ARINC 661 Server才会使用DF文件去实施UA界面的显示, ARINC 661 Server通过ARINC 661协议和UA进行通信, 实时显示UA的控制界面, IMA和CDS的部署如图1所示.

驻留在IMA上的UA与相应的ARINC 661 Server进行通信, 通常使用ARINC 664接口(空客称之为“AFDX”接口)传输ARINC 661报文. DF文件预先根据系统配置, 存放在相应的IDU上. 当ARINC 661 Server在收到来自UA的显示事件后, 会加载该UA的DF文件, 对该UA进行显示. 这样的部署, 达到了灵活备份, 减少冗余和快速切换的目的. 比如UA可以在IDU1, IDU3和IDU6上进行显示, 但是同时只能在两个IDU上进行显示. 那么, 这三个IDU将配置该UA的DF文件, 当UA已经在IDU1和IDU3上进行显示时, IDU6将不会加载UA的DF文件, 不允许UA的显示. 当UA在IDU1上的显示失效后, IDU6上将收到UA的显示事件, 加载UA的DF文件, UA将在IDU3和IDU6上进行显示. UA维持所有获得显示权限的A661 Server的通信会话, 只发出允许显示的界面个数的显示事件^[3,4].

2 DF文件的开发和验证 2.1 DF文件的开发流程

DF文件的开发既然是结合UA同时进行, 那么UA开发和验证的所有阶段, 都将对DF文件进行同时开发和验证. 如图2所示,

在系统需求阶段, 需要将DF文件的结构和属性定于在系统需求中. 比如DF文件中所包含的界面的layer ID的定义, 以及layout的定义. 在软件高级需求和设计(低级需求)的开发中, 需要将DF文件中各个控件的具体参数定义. 比如一个控件的属性是button还是data entry, 字体的style set值(用于定于字体的颜色和大小)等. 编写代码的同时, 根据需求和设计, 通过SCADE DISPLAY工具, 完成DF文件的开发. DF文件的开发同样需要满足民机航电系统开发的基本要求:

(1) 自顶向下的开发流程, 从系统需求到高级需求, 再到低级需求和设计.

(2) 双向追踪性, DF文件中的代码数据可以逆向追踪到低级需求的控件的定义.

(3) 覆盖率测试满足DO-178C的要求, 不出现dead code, inactive code等.

(4) 根据相应的软件等级, 满足开发和验证的独立性.

(5) DF文件的开发需要和UA代码同步进行, 同步更新和验证.

2.2 DF文件的开发流程

在系统需求开发阶段, 该阶段的交付物是系统需求文档, 因此在该环节只需要验证DF文件的架构定义和属性定义. 验证人员通过评审的方式, 验证与DF文件相关的需求. 评审DF文件的需求, 需要结合UA软件的系统需求, 必须保证以下三点:

(1) 符合UA软件系统需求对软件显示层次的要求.

(2) 对DF文件的框架属性定义完整, 所有需求和UA的软件高层界面需求一致.

(3) 能够实现UA软件的显示需求.

在高级需求和设计(低级需求)开发阶段, DF文件中的参数定义已经明确, 界面需求已经完善. 该阶段的交付物是高级需求, 设计文档(包括低级需求), 因此, 在该环节需要验证的是DF文件中控件的定义, 逻辑关系以及各种属性参数值. 同样, 该阶段也必须结合UA相应的需求, 必须与UA所定义的界面需求保持一致.

在经过编码阶段后, code和DF文件都已经完善. 验证人员需要结合软件系统需求, 软件高级需求, 软件低级需求和软件设计文档, 对SCADE DISPLAY工具产生的具有可读性的XML格式的DF文件进行评审, XML格式的DF文件内容如图3所示.

依据需求文档, 对XML文件中的控件参数进行review, 查看框架结构(控件对象继承性)和控件参数是否和需求一致. 其次, 需要进行覆盖率验证, XML文件必须覆盖所有需求定义的层次, 结构, 控件和参数, 同时不能有多出需求定义的表达.

在验证UA的代码是否符合UA的高级需求和低级需求的测试中, 会将UA运行在目标机IMA上, SCADE DISPLAY工具产生的BIN文件会加载到IDU上. 在此过程中, 只要IDU能够正确显示UA界面, 并且支持完成所有的UA验证, 我们认为BIN文件通过测试. UA的功能验证和BIN文件验证的环境图, 如图4所示.

通过键盘和鼠标对IDU输入数据, 输入数据通过ARINC 664接口, 封装为ARINC 661协议, 传输至IMA上的UA. UA接收并处理这些数据后, UA做出相应的功能响应, 同时将界面的显示处理反馈至IDU, IDU上的ARINC 661 Server处理该反馈信息后, 更新DF文件的运行数据, 更新界面的显示. IDU上的界面实时显示数据, 通过获取DF文件的运行数据得到, DF文件的运行数据和UA本地存储的界面数据一致, 实现对UA用户界面的实时显示.

但是, 通过加载DF的BIN格式文件, 结合UA的功能测试验证DF文件的验证方式会出现以下问题:

(1) UA开发者并不会购买SCADE DISPLAY的DF文件生成器的认证包(价格相对昂贵), 但又必须验证DF文件的正确性.

(2) 加载的BIN文件不具备可读性, 无法通过评审和分析的形式进行验证.

(3) 无法将DF文件的非可执行代码追踪到相应的需求.

(4) 即使正确支持了UA所有的功能测试, 也不能说明DF文件的开发完全符合需求定义.

(5) 不能对BIN格式的DF文件进行覆盖率测试和静态代码走查

但是, 只要能验证BIN文件和已经通过评审的XML文件信息一致, 就可以说明BIN文件也满足需求定义. 那么便需要对BIN格式的DF文件和XML格式的DF文件进行一致性验证. 由于BIN文件是二进制格式, 而XML文件是可读字符, 二者无法进行直接的验证. 那么, 此时需要应用SCADE DISPLAY产生的HEXA格式的DF文件作为中间件, 验证BIN和XML文件的一致性, 验证文件关系如图5所示.

HEXA文件中包含了XML文件控件的描述, 同时又将该段参数转换成了十六进制的数据, HEXA文件内容如图6所示.

在验证了XML文件和HEXA文件的描述字段和参数一致后, 将HEXA文件的十六进制数据和BIN文件的二进制数据进行匹配, 只要数据一致, 那么一致性便得到了验证.

由于XML文件是根据需求进行评审, BIN文件根据需求进行测试, 测试用例分别基于高级需求和低级需求进行开发, XML文件和BIN文件又通过HEXA文件, 进行了一致性验证, 那么就可以得到如图7所示的追踪关系.

执行高级需求测试用例和低级需求测试用例, 验证BIN文件是否支持UA的功能性测试, DF文件内容定义和UA实现的一致. 根据系统需求, 高级需求和低级需求以及设计文档对XML文件进行评审, 对XML文件进行了验证. 同时, 也完成了DF文件的追踪性验证.

综上所示, UA开发者负责的DF文件的验证具有以下特点:

(1) DF文件验证具有独立性, 同时结合了UA的功能性验证, 保证了双向的数据关系一致.

(2) DF文件的验证具备完善的追踪性, 适航证据完整.

(3) DF文件的验证从系统需求阶段开始, 贯穿了整个软件开发流程.

(4) 通过完善的追踪性, 能够达到UA界面需求跟新, DF文件需求更新, 到DF文件同步更新的目的.

(5) 最终得到的DF文件, 交付至CDS开发者后, CDS开发者只需将其作为ARINC 661 Server的参数项进行验证, 与UA功能无关.

2.3 DF文件的测试规程和结果

在使用SCADE DISPLAY工具后, 产生了XML, HEXA, 和BIN格式的DF文件. 将UA运行在IMA上, BIN文件加载在IDU上, 通过功能测试, 验证IDU显示的界面是否符合需求定义. 例如需求中定义的界面如图8所示.

此时通过IDU显示出来的界面, 如图9所示.

CDS开发者提供的workspace与设计需求文档中的界面, 因为实际使用的画图工具的差别, 会出现细微的差别. 此时, 通过功能验证, 目测界面的颜色字体, 能够符合最终的系统成员规范, 此时的DF文件便可以通过测试.

第二步是根据需求评审XML文件. 例如ATIS界面的一个控件描述, 如图10所示.

在完成XML文件的评审后, 进行HEXA文件和XML文件的一致性验证, 与上图对应的ATIS界面的一个控件的HEXA表达, 如图11所示.

将XML中的表达和HEXA的二进制对应的映射表, 如表1所示.

值得注意的是, 在控件身份表达中, 增加了一个Parent Identity. 它是SCADE DISPLAY给该控件添加的父节点属性, 在XML文件中并没有表达出来, 因为XML文件是按照树结构进行组织的, 树形结构便可以表达出子节点和父节点的继承关系. 而二进制表达式无法显示树形结构, 便添加父节点属性来体现控件对象的继承性. 在对DF文件的覆盖率验证中, 必须说明类似Parent Identity这样的参数存在的原因, 才能通过覆盖率的测试和分析.

如表2所示, 对于Check Button来说, Radio box就是他的父控件, 所以在定义Check Button时, 需要将Radio Box的WidgetIdent 0082赋值给ParentIdent来体现对象的继承性.

验证了XML文件和HEXA的一致性后, 需要验证BIN文件和HEXA文件的一致性. 在BIN文件中找到相应的二进制内容, 如图12所示.

阴影部分, 便是上述控件Check Button的二进制表达.

通过上述验证过程, 将验证结果记录到EXCEL表格中, 形成测试记录, 如图13所示.

XML文件的评审验证了控件参数是否符合需求, BIN文件的加载和UA的功能验证, 验证了控件是否支持UA的操作性功能, BIN文件和XML文件的一致性验证, 完善了DF文件的追踪性验证, 同时进行的覆盖率分析, 全面验证了DF文件, 最后通过形成测试记录, 提供了DF文件的验证证据. 使得DF文件的验证符合了DO-178C的要求, 同时又能通过CAAC的适航审定^[5–10].

3 结论与展望

本文所阐述的基于ARINC 661协议的DF文件的验证, 解决了UA开发者对软件代码以外的附属交付物的验证问题. 在民用航电系统的集成测试中, IMA上集成了几十个大大小小的软件, 并且由多个开发者分别负责一个或多个软件的开发, 对基于ARINC 661协议的DF文件的验证, 是普遍存在的问题. 使用本文的验证方式, 减轻了CDS开发者对来自于不同UA开发者提供的DF文件的验证工作. 按照本文的验证方式验证通过的DF文件, 排除了UA开发者引起的兼容性, 一致性和完整性的错误, CDS开发者直接使用和加载DF文件, 将DF文件视为参数数据项进行验证. 这种DF文件的验证方法规范了UA开发者的DF文件的验证流程, 提高了DF文件的验证质量, 缩减了CDS的开发周期, 同时减少了UA和CDS开发者在购买SCADE DISPLAY的DF生成器上的巨大开销. 在民用航电系统快速发展的时代, 不同开发者, 站在不同角度, 使用不同方式, 共同承担一个产物的开发和验证的模式必将成为大的趋势, 这样的验证方式也将逐步趋于成熟和完善^[11–13].