一种1553E数据加卸载系统设计与实现

魏雪菲 史岩 薛威

摘要：在航空、航天、兵器、舰船等领域，1553B数据总线应用广泛，但没有统一的设备升级维护方法。传统方式使用专用设备对每个总线设备进行升级维护，但该方式操作不方便且容易引入操作错误。本文提出一种1553B总线的数据加卸载协议，规定一种轻量级的数据加卸载，用于完成1553B总线下的数据上传和下载，实现配置文件、应用软件的在线加载、更新与数据文件的下载。上传和下载操作以文件为单位进行传输，传输文件以 Block为单位进行校验、应答和重传，保证传输正确性和传输效率。支持一次加卸载多个数据文件，从而增强系统可维护性，提高系统维护效率，降低维护成本。最后，基于仿真卡和嵌入式环境下的远程终端（RT）设备，采用软件形式化开发方法，实现！553B总线加卸载软件。

关键词：1553B;升级维护;数据加卸载;Block

中图分类号：TP393.08 文献标识码：A

1553B数据总线广泛应用于航空、航天、舰船及兵器等多个领域，涉及机电系统、飞行控制系统、航电系统和武器系统等多个系统[1]。1553B总线作为机载、车载网络的二级总线，承担了系统的内部互联。近年来，随着海、陆、空一体化作战的发展，机载、车载、舰载系统任务的数据量和复杂度呈几何量级倍增，1553B设备的数量也急剧增长，网络规模随之增大。但1553B总线没有统一的设备升级维护方法，仍采用传统的针对单个机载设备使用专用仿真器设施进行升级的维护方式。这种方式需要将机载、车载、舰载1553B设备逐个拆卸，再连接专用外接设备进行维护升级。设备拆卸工作操作不便，增加了工作量和维护时间，影响机载设备使用寿命，同时增加人工操作失误带来的危险。

1 系统设计

1.1 系统架构

根据1553B总线通信特点，系统包含加载器、加载控制器和被加载器三种角色，连接关系如图1所示。其中BC为1553B总线控制器，承担加载控制器角色;PMAT为具有1553 RT仿真卡的主机，是一种PC机环境下的远程终端，承担加载器角色;RT为1553B远程终端，承担被加载器角色。若PMAT给BC加卸载文件，则BC既承担加载控制器角色，又承担被加载器角色[2，3]。

非加载模式下，总线网络中包含三种角色：BC为1553B总线控制器，RT为1553B远程终端，BBC为备份总线控制器，在BC正常工作时BBC仅用作普通远程终端[4，5];BC在非加载模式下检测PMAT是否在线，若检测到PMAT在线，则切换至加载模式，终止正常通信，执行加卸载功能。

該加卸载协议实现PMAT在用户操作下，向被加载器加卸载配置表、软件以及其他数据文件，实现配置表、软件的统一管理和升级，以及被加载器数据文件到PMAT的下载。

该协议具有以下特点：

（1）网络各节点在正常通信过程中不执行加载操作，仅在系统切换到加载模式，正常通信终止，PMAT连人系统后，才能执行加卸载功能。

（2）为保证传输效率和数据完整性，该加卸载方案将文件划分为若干个Block，以Block为单位进行校验、重传，接收端接收到Block后进行校验，结果正确后，继续下一个Block传输过程。

（3）每个Block包含若干数据帧，数据帧连续发送，不再单独对其进行校验，以保证传输效率。

（4）文件传输完成后，针对整个文件，进行循环冗余校验（CRC），保证文件传输的正确性和完整性，满足安全关键数据的要求。

（5）该方案以Block为单位进行校验、重传，能够支持传输大数据文件，对数据文件大小不做上限要求，但考虑加卸载效率，不建议进行过大文件传输。

1.2 协议架构

该协议架构层次如图2所示，涵盖了1553B模块驱动层和主机应用层[6]。若加卸载文件为配置文件或1553B模块驱动软件，则主机应用接收并存储后，由1553B模块驱动层烧写至 1553B模块FLASH中;若加卸载文件为其他数据文件，则主机应用层仅接收，不进行烧写固化;若数据文件为主机应用软件，则最终烧写在CPU模块的FLASH中。对于PMAT，则所有协议由主机应用层实现。

2 算法流程

加卸载协议包含FIND操作、上传操作和下载操作。

加卸载协议以文件为单位进行传输，为保证传输正确性和传输效率，传输过程中将文件划分为若干个Block，针对单个Block进行校验、应答，若出现错误则以Block为单位进行重传。为保证整个文件的正确性，文件传输完成后对整个文件再进行CRC校验。

经过以Block为单位的累加和校验以及对整个文件的CRC校验，避免了数据传输过程中的误码、丢包等故障造成的数据不完整错误。以Block为单位的累加和校验，保证了大数据文件传输过程中错误的及时发现与更正，保证了传输文件的数据完整性和传输效率。

考虑1553B总线的通信特点，PMAT、RT、BBC之间的数据直接通信，需要由BC进行控制。

2.1 FIND操作

进行文件上传或下载操作前，需要通过FIND操作来查看被加载器是否在线，并通过FIND操作来获取被加载器的软硬件及其版本信息。

2.2 上传操作

上传操作实现加载器到被加载器的文件传输和烧写功能，加载器通过加载控制器与被加载器建立传输连接后，在加载控制器的干预下，完成数据文件到目标机的上传操作。上传操作的流程可分为加载初始化和加载两部分。上传过程中一个文件划分为若干个Block，一个Block大小可通过协商确定，也可根据实际需要确定。

上传操作的流程可分为上传初始化和上传阶段两部分，上传初始化实现被加载器状态查询，确认当前被加载器是否在线、是否允许上传;上传阶段加载器在加载控制器的干预下以Block为单位，逐块向被加载器发送数据文件，直至文件传输完成。一次正常的文件上传流程如图3所示。

2.3 下载操作

下载操作实现被加载器数据文件到加载器的下载功能。下载操作的过程是：加载器通过加载控制器与被加载器建立传输连接后，完成被加载器数据文件的下载操作。下载过程中一个文件划分为若干个Block，一个Block大小可通过协商确定，也可根据实际需要确定。

下载操作的流程可分为下载初始化和下载阶段两部分，下载初始化实现被加载器状态查询，确认当前被加载器是否在线、是否允许下载;下载阶段将文件划分成若干Block进行连续传输，直至文件传输完毕。一次正常的文件下载流程如图4所示。

3 软件设计与实现

软件包含加载器、加载控制器和被加载器三部分，分别驻留在PMaT、嵌入式1553BBC设备和嵌入式1553BRT设备上，这三部分软件通过1553B总线进行通信，完成协议功能。加载器、加载控制器和被加载器软件需求均通过协议进行分析获取，通过形式化方法进行软件开发的分析、设计和实现[7]。

3.1 软件形式化规格

有限状态机是有限计算的基本模型，也是许多形式化规格、验证方法的基础模型。加载器软件通过1553B数据加卸载协议获取需求，用有限状态机对其进行形式化规格描述，有限状态机状态转移图如图5所示。

加载控制器若收到的操作被加载器是自身时，则其有限状态机与被加载端相同;若其收到的操作被加载器为其他RT或BBC时，有限状态机状态转移图如图7所示。

3.2 软件实现

根据加载器、加载控制器和被加载器有限状态机，基于1553B仿真卡和嵌入式平台实现该加卸载协议，加载器仿真卡采用自主研发的1553B PCI仿真卡，主机采用WindowsXP操作系统，Microsoft Visual Studio 2010开发环境。加载控制器和被加載器采用国产1553B SOC芯片，基于PowerPC处理器实现，采用XMC接口与主机中央处理器（CPU）交互、供电。主机采用VxWorks 6.6，使用WorkBench开发环境，SOC芯片使用C*CORE 1DE开发环境。

加载器软件采用分层方式实现，协议软件采用C语言开发，封装成lib库，供上层调用，上层提供用户操作界面，采用C++语言实现。加载控制器和被加载器采用C语言。

经测试，加卸载软件加载并固化32KB文件需要4s，平均速率8kB/s。

4 结束语

本文设计并实现了1553B总线数据加卸载软件，达到了64kB/s的传输速率，1553B总线速率为1MB/s，因此该速率仍有进州步提升空间，需针对加载器、加载控制器和被加载器等待时间进行研究，缩短等待时间开销，提高通信速率。1553B总线加卸载软件的实现，为1553B设备提供了一种在线升级维护方法，在机载、舰载、车载1553B设备中有广泛的应用前景。

参考文献

[1]刘士全，隽扬，蔡洁明，等.1553B总线应用发展研究[J].电子与封装，2013，13（12）：12-15.

[2]ARINC 615A-3-2007 Software data loader using ethernet in-terface[S].ARINC Airlines Electronic Engineering Committee，2007.

[3]ARINC 615-4 Airborne computer high speed data loader[S].ARINC Airlines Electronic Engineering Committee，2002.

[4]MIL-STD-1553 Protocol tutorial[S].Condor EngineeringInc.，2004.

[5]杨卫军，许化龙，訾向勇.基于 1553B总线的嵌入式网络BBC设计与实现[J].微电子学与计算机，2007，24（1）：63-65.

[6]刑秀琴，姚竹亭.基于1553B总线的通信接口及其应用[J].中北大学学报：自然科学版，2007，28（1）：91-94.

[7]古天龙.软件开发的形式化方法[M].北京：高等教育出版社，2005.