谭博

(航空工业第一飞机设计研究院 综合航电系统设计研究所，西安 710089)

0 引 言

随着航空电子系统整体架构向着模块化、分布式的方向快速发展，传统的采样和队列数据传输方式已经不能完全满足现代航空电子系统的数据传输需求。随着用户需求和技术手段的更新，航空电子系统数据传输出现了大数据传输需求，这类传输需求通常具有以下两个特点：一是传输数据量大且长度不定，大数据量使得在航空电子系统内完成数据的实时传输非常困难，而且与传统的采样或队列消息传输需求不同，传输的大数据无法在系统设计阶段以系统接口控制文件(Interface Control Document，简称ICD)的方式进行控制，进而对其长度、内容、格式等进行限定，而需要在系统运行时进行动态的适配；二是大数据传输必须在系统在线运行时进行，与系统可在离线状态下加载的数据不同，系统内传输的大数据通常会影响系统功能运行的正确性，因此无法像应用程序或配置表等数据那样，在系统离线状态下以专用设备进行一对一的数据传输。

目前，航空电子系统大数据传输有多种实现思路。徐克等[1]给出了一种利用系统提供的可高速访问的资源，以数据共享的方式在分区间进行大数据传输，应用该方式可在分区间以高速率和高稳定性完成数据传输，但是这种方式仅适用于系统内单个结点内部的数据传输，无法满足系统内各结点之间以及系统间的大数据传输需求，此外，该方式的实现依靠操作系统，限制了其应用范围，不具有普适性；李文涛等[2]给出了一种利用FTP(File Transfer Protocol)协议将大数据存储为文件后进行传输的方式，该方式技术成熟，速率和性能较好，但是使用FTP协议需要操作系统支持，且需要在系统中增加文件服务器结点，这将限制系统内硬件平台和操作系统的选择，并影响航空电子系统的架构，为系统设计引入了额外的成本；志超有等[3]指出，现代机载总线能够提供很高的传输速率，因此，另一种实现思路是直接利用机载总线将大数据通过网络数据分包的方式进行直接传输，但是在实际使用时，因机载网络无法在单次传输中完成大数据的全部数据传输，存在阻塞应用程序的情况，会影响航空电子系统的正常功能和系统安全性。此外，经查阅ARINC653标准[4-6]，发现大数据传输服务并不是标准的服务/接口，以Vxworks操作系统为例，在其操作手册和配置手册[7-8]中，均未针对大数据传输应用场景提供对应的服务或接口。

本文结合工程实际，发现在目前的航空电子系统中存在大数据传输需求的应用场景有限，可以使用网状通讯结构构建满足大数据传输的系统网络架构，并通过流量控制的方式完成大数据的传输；重点研究窗口协议在大数据传输中的应用前景，并给出一种可高效稳定传输大数据的改进窗口协议。

1 航空电子系统大数据传输

首先需对本文大数据传输的概念进行简单定义。因各航空电子系统的网络选型、总线类型、硬件设备等存在差异，所以各系统对大数据的长度定义不尽相同。本文在以下描述中，定义系统大数据传输为：传输数据量超过最小任务调度周期内能够完成传输的最大数据量的数据传输。

一种典型的模块化航空电子系统的架构如图1所示，系统内各节点的应用软件与其分区操作系统(Partition Operating System，简称POS)联合，形成系统中的一个逻辑节点。其中，应用软件负责完成逻辑节点分配的功能，分区操作系统通过应用/执行接口(Application Executive，简称APEX)，向应用程序提供硬件资源操作的接口。逻辑节点可在系统内任意模块进行部署，各逻辑节点之间通过机载网络进行数据传输，完成节点状态和数据的同步。

航空电子系统内，大部分数据以采样数据(例如传感器采集数据、设备状态、引导参数等)或队列消息(例如人机交互指令)的方式进行传输，这两类数据传输的内容、格式和长度都可以在系统的设计阶段明确并限制。但是，随着技术的发展和需求的增加，出现了仅依靠这两类数据所无法完成的应用场景。以某型飞机航空电子系统中飞行管理分系统(以下简称为飞管)为例，该分系统采用模块化架构，由三个运行分区组成，部署于标准的硬件模块上。使用时，航空电子系统对系统内的主从飞管有数据同步的需求，要求在任意飞管完成飞行计划编辑并确认后，将数据同步至另一飞管。在该应用场景中，需要同步的数据依据飞行计划的长度而有所差异，若在每次同步时均指定依据最大长度进行传输，则会导致编辑完成后同步时间过长，严重影响用户使用体验，若指定长度小于实际长度，又会造成数据传输不完整，影响功能的正确性。如何高效稳定地传输这类长度不定的大数据，是本文希望解决的问题。

2 窗口传输协议

为了解决航空电子系统大数据传输的问题，一种有效的思路是依靠系统队列消息传输的能力，引入窗口传输协议，将待传输数据进行分组并以异步传输的方式完成大数据的收发。该思路具有以下优点：

(1) 易于实现。窗口协议的数据分组和窗口收发操作，可以通过队列消息的传递实现。因此，一般航空电子系统都具备通过窗口传输来实现大数据传输的条件。此外，窗口协议传输大数据可以在系统的应用层实现，避免对系统设计方案和架构进行更改。

(2) 易于监控。传输数据最终通过队列消息收发实现，传输过程对于应用层可见可控。

(3) 轻量级。窗口协议传输只实现数据传递的功能，所需的系统资源少。

以下列举三种典型的窗口协议，并对其在航空电子系统中的应用情况进行说明和分析。

2.1 停止等待协议

停止等待协议的发送和接收窗口大小均为1，即每次只传递一个数据分组，其实现容易且能够保证传输数据的正确性，是目前实际中使用的大数据传输方式之一。但该协议网络利用率低，传输耗时随数据量增长明显，难以满足大数据传输的速率要求。

2.2 回退协议

回退协议的发送窗口大小通常为大于1的整数，接收窗口大小为1。发送方将窗口内的数据分组依次发出，接收方在接收到错误数据分组后向发送方反馈，随后从出错的数据分组重新进行传输。应用时，该协议在环境不稳定时进行大量重发，易造成网络通讯拥堵，对机载网络和接收端的性能有较大影响。

2.3 重传协议

重传协议的发送和接收窗口大小相同，通常为大于1的整数。发送方将窗口内的数据分组依次发出，接收方在接收窗口填满或到达最大间隔后，反馈接收状态。发送方依据反馈，将未正确收到的数据进行重传，或继续发送下一窗口。应用时，该协议在环境不稳定时发送速率明显降低。

3 多窗口协议

现有的典型窗口协议在应用时，存在传输效率、稳定性等多方面的不足，为了解决这些问题，本文提出一种多窗口传输协议，与传统的窗口协议相比，在网络环境不稳定时，它同时进行多个窗口传输，在提高传输效率的同时，避免了发送大量冗余数据，具有更好的稳定性和传输效率。

本文方法的核心思路是，在网络环境不稳定时，发送端用未正确接收的数据分组和待发送的数据分组尽量填充发送的逻辑窗口，提高数据发送的效率；接收端在接收到新逻辑窗口的数据分组时，开辟多个数据缓存区，对应接收各逻辑窗口的数据，并在逻辑窗口数据填满或达到设置最大接收时间窗口后，向发送端发送ACK确认，达到减少冗余数据的目的。

本文的多窗口传输协议(如图2所示)的一般过程为：

(1) 设置数据分组大小不超过网络最大传输单元长度，逻辑窗口大小不超过队列长度；

(2) 将待传输数据依据逻辑窗口大小和数据分组大小划分为i个逻辑窗口(W1,W2,…,Wi)；

(3) 发送方将当前逻辑窗口Wa内的数据分组(Pa1,Pa2,…,Paj)依次发送；

(4) 接收方接收到数据后，将接收数据分组(Pa1,Pa2,…,Paj)存入Wa对应的缓存区，并在接收到带有新逻辑窗口编号的数据分组Pbk时，申请新缓存存储Wb的数据分组，启动相应的窗口计时；

(5) 在任意逻辑窗口填满，或任意时间窗口满足后，反馈对应逻辑窗口的接收状态；

(6) 发送方依据接收状态，将逻辑窗口内Wa未被正确接收的数据和之后的逻辑窗口Wb内待发送的数据组成临时窗口发送(Pai,…,Paj,Pbk,…,Pbl)；

(7) 重复执行流程(3)～(6)，直至数据发送完毕或超时退出。

(a) 发送方活动图

(b) 接收方活动图图2 多窗口协议活动图Fig.2 Activity diagram of multiple window protocol

从传输过程可以看出：多窗口传输协议在数据划分时，除数据分组序号外还增加了逻辑窗口序号，以便在多窗口数据分组传输时进行区分。当网络环境稳定时，本协议等同于重传协议，具有与重传协议相同的传输效率；当网络环境不稳定时，与其他窗口协议相比，多窗口协议通过多缓存区的方式同时接收多个逻辑窗口的数据，达到最大化的网络利用率，充分利用传输的时间窗口，提高了传输效率。这一特点也使得多窗口传输协议需要更多的系统资源支持。

此外，多窗口协议采用队列消息异步通讯的方式实现数据传递，避免了收发过程中阻塞应用程序。在应用层中实现的特点，也使得采用多窗口协议不必对原有的系统硬件架构和软件架构进行更改，可以用于方案和架构难以调整的航空电子系统中进行大数据传输。

4 试验过程及结果

以某型飞机航空电子系统的飞管数据同步应用场景为例，任意一侧飞管在编辑完成后，向对侧飞管同步新的当前计划和备份计划，以保证两侧数据的一致性。飞行计划长度依据包含的航线和航路点的数目变化，最长情况下可达到110 496字节，因此，单次传输的最大数据量为220 992字节(当前计划和备份计划均达到最大长度时)，网络传输的最大传输单元为1 204字节，据此设置数据分组大小为1 204字节，其中头信息占4字节，包含逻辑窗口号和窗口内的分组号，传输信息占1 200字节。

参考文献[9]～[13]设计了此次试验的仿真数据总线并建立了试验环境，依据文献[14]～[15]确定通过对传输任务调度周期进行计数的方式分析传输效率和健壮性的方式。最终在航空电子系统试验室中对本文协议及三种典型的窗口协议进行测试，待传输的数据大小为220 992字节，划分为185个分组。测试中，除停止等待协议的逻辑窗口大小为1外，其余协议的逻辑窗口大小均设置为5，航空电子系统试验结果如表1～表4所示，表中各栏计量单位为个，表示传输任务的调度周期和传输的窗口计数。其中，最小传输周期、最大传输周期和平均传输周期为完成单次传输所需的调度周期计数，发送窗口数(平均)、接受窗口数(平均)为完成20次试验中，单次传输过程中收发窗口计数的平均值，丢弃分组数(平均)为完成20次试验中，单次传输过程中丢弃的冗余或无效数据分组计数的平均值。

4.1 传输速率测试

系统正常运行，进行飞行计划同步，同步期间，不进行其他操作。在此条件下进行20次数据同步，以第一组数据分组发出传输完成ACK为止的收发任务调度次数作为传输耗时，统计各窗口协议在网络环境良好情况下的传输速度，统计结果如表1所示。

表1 传输速率测试结果

从表1可以看出：试验过程中，系统中、测试中、运行过程中的周期性数据收发、异常处理等情况无法完全屏蔽，导致每次传输的耗时有部分差别；总体看来，在网络环境良好情况下，协议均以最佳速度进行传输，其中，因停止等待协议每个调度周期只收发一个数据分组，其传输速率明显低于其他三种协议，其他三种协议在网络环境良好时，传输速率基本一致，没有明显差异。

4.2 健壮性测试

实际机载网络环境存在丢失、延迟、重复发送等各类故障情况，因此，健壮性也是应用时必须考虑的因素。通过在测试网络环境中注入故障的方式，对四种窗口协议的健壮性进行测试。

设置网络丢包率为10%，测试结果如表2所示。

表2 丢包情况传输速率测试结果

设置网络乱序发生概率为10%，测试结果如表3所示。

表3 乱序情况传输速率测试结果

设置网络数据重传发生概率为10%，测试结果如表4所示。

表4 重传情况传输速率测试结果

从表2～表4可以看出：在网络故障影响下，多窗口协议受到的影响最小，在四种协议中传输效率和健壮性最好，而且没有多余数据传输，对机载网络和接收端的负载影响小。

4.3 试验总结

综合传输速率和健壮性试验的结果，可得：

(1) 停止等待协议在网络传输丢包故障发生后，仅请求重传丢失的一个数据分组，没有额外的数据分组传输，因此，受丢包故障影响较小，在丢包率为10%的情况下，平均传输时长增长约28.8%。但是，其传输效率明显低于其他几种协议，因此在数据量较大的应用场景中，停止等待协议难以满足数据传输的速率要求。

(2) 回退协议和重传协议的逻辑窗口内包含的数据分组多，因此，在网络存在丢包故障时，窗口发送失败的概率与停止等待协议相比更高，受到的影响更大，在丢包率为10%的情况下，平均发送时长增长约116%。此外，回退协议在数据重发时会将丢失的数据分组及之后的全部数据分组重新传输，造成网络上存在大量的冗余数据，对网络和接收端的影响较大。

(3) 回退协议对数据到达的顺序有要求，数据顺序错误会导致接收端请求重传最后一组有效数据分组及之后的数据分组，使得通讯链路上存在大量的冗余数据，对机载网络和接收端的影响较大。而其他三种协议对数据到达顺序没有要求，因此不受数据顺序错误的影响。

(4) 四种协议的接收方都会丢弃接收到的重复数据分组，因此网络数据重传故障对四种协议的传输效率基本没有影响，仅会略微影响接收端的性能。

(5) 本文提出的多窗口协议受各类网络故障的影响最小，在故障情况下，与重传和回退协议相比，多窗口协议的平均传输周期更短，冗余数据量更少。

5 结 论

本文提出的多窗口数据传输协议，可以在不对系统配置、操作系统或硬件进行修改的前提下，仅对应用程序进行变更，达到为具有队列消息传输能力的航空电子系统提供大数据传输功能支持的目的。这种解决方案相比目前使用的文件传输协议和停止等待传输协议，所需消耗的人力、资源和时间成本更少，且能达到较高的传输速率，具有稳定的传输性能，可为航空电子系统后续功能的扩展和更新提供支持。