CN103533027B - 一种分布式设备及软件版本兼容性维护的方法、系统 - Google Patents

Abstract

本发明公开了一种分布式设备软件版本兼容性维护的方法和系统，涉及分布式设备领域。本发明公开的方法包括：发布复合版本软件包文件，所述复合版本软件包文件中携带分布式设备的主控板卡以及所有业务板卡的软件文件；分布式设备的主控板卡读取所述复合版本软件包文件，升级本分布式设备的主控板卡以及所有业务板卡的软件版本。本发明还公开了一种分布式设备软件版本兼容性维护的系统。本申请技术方案采用统一存储，统一升级，自动同步的方式快速、有效的保证各类型板卡软件版本的兼容性。

Description

一种分布式设备及软件版本兼容性维护的方法、系统

技术领域

本发明涉及分布式设备，特别涉及一种通用高效的软件版本兼容性维护的管理方案。

背景技术

目前市场上的分布式设备主要为机框式设备，由主控板卡与业务板卡组成，业务板的数目较多，并且板卡类型不一致。一般机框式设备都支持不同类型的业务板混插，但是各种类型的业务板卡和主控板卡上不可能使用完全相同的软件版本，故在一个分布式设备适用几十种甚至上百种不同的系统软件（即使是同一种板卡也会适用各种不同版本号的软件版本）。因为主控板承担着对整个设备与各个业务板的配置与管理功能，故要求各个板卡的系统软件间可以正确的通信，也就是各个板卡上的版本要求相互兼容，目前这部分工作需要维护人员自己手动操作完成，当主控板卡和业务板卡不兼容时，通过给主控板卡或者业务板卡升级更新版本来保证，具体采用如下两种方案。

方案1：维护人员手工完成，当发生不兼容时，维护人员通过自己选择可以兼容的软件对主控板卡或者业务板卡升级，从而达到保持设备兼容性的目的。

方案2：通过网管软件将需要升级的各种单板文件（可兼容的）打包成软件包，下载到网络中存在的专用存储单板上，之后通过该专用存储单板对设备进行升级。

很容易看出，采用方案1具有如下缺点：

版本维护需要网管人员人工保证，需要对各个板卡进行多次升级。

而采用方案2则存在如下缺点：

同方案1，打包的文件由网管人员手工打包，各个版本的兼容性需要人工来判断，各种版本数目众多，不易维护，容易出错。

需要一个专用的存储单板，且需要占用分布式设备上槽位，降低设备能力。

综上所述，目前分布式设备存在各种版本数目众多，不易管理，并且版本的兼容性依赖人工观察，容易出错。

发明内容

本发明所要解决的技术问题是，提供一种分布式设备及软件版本兼容性维护的方法、系统，以确保各类型板卡软件版本之间的兼容性。

为了解决上述技术问题，本发明公开了一种分布式设备软件版本兼容性维护的方法，该方法包括：

发布复合版本软件包文件，所述复合版本软件包文件中携带分布式设备的主控板卡以及一个或多个业务板卡的软件文件，其中，所述分布式设备的主控板卡与业务板卡的软件文件之间相互兼容；

分布式设备的主控板卡读取所述复合版本软件包文件，升级本分布式设备的主控板卡以及所有业务板卡的软件版本。

可选地，上述方法中，所述复合版本软件包文件包括软件包文件头和软件包文件体，所述软件包文件体由分布式设备的主控板卡以及携带的业务板卡的软件文件构成。

可选地，上述方法中，所述业务板卡的软件文件包括软件文件头和软件文件体，其中，所述软件文件头包括如下信息：

文件标识，用于标识此文件对应的分布式设备的版本文件；

设备类型，用于标识软件版本文件适用的业务板卡类型；

版本文件类别，用于标识系统软件版本以及软件包版本；

大版本号，用于指示分布式设备中各板卡的软件文件之间的兼容性；

小版本号，规划发布或测试版本的最小粒度。

可选地，上述方法中，所述分布式设备的主控板卡读取所述复合版本软件包文件后，一次性升级本主控板卡和业务板卡的软件版本。

可选地，上述方法中，分布式设备的主控板卡读取所述复合版本软件包文件,升级本分布式设备的主控板卡以及业务板卡的软件版本的过程如下：

所述分布式设备的主控板卡将所述复合版本软件包文件中业务板卡的软件文件进行广播；

所述分布式设备的业务板卡接收所广播的软件文件，根据所述软件文件中的设备类型查找适合自身板卡类型的软件文件，并将查找到的软件文件保存到本地。

可选地，上述方法还包括：

所述分布式设备上业务板卡通过所述复合版本软件包文件中本板卡的软件文件头信息自动检测自身版本和主控板卡的主控版本的兼容性

可选地，分布式设备将所述复合版本软件包文件中业务板卡的软件文件进行广播之前，上述方法还包括：

所述分布式设备的主控板卡发送升级开始报文给业务板卡，该升级开始报文中至少携带待升级文件大小和主控板支持的报文单帧长度；

业务板卡接收到所述升级开始报文后，回复响应报文，该响应报文中携带本业务板卡协商后的报文单帧长度和发送速率信息；

主控板卡接收各个业务板卡的响应报文，从中选择报文单帧长度的最小值以及发送速率的最小值，按照所选择的报文单帧长度的最小值对所述业务板卡的软件文件进行分片，并按照所选择的发送速率的最小值依次广播各分片。

可选地，上述方法中，将所述复合版本软件包文件保存在闪存（CF）卡或者文件传输协议/简单文件传输协议（FTP/TFTP）服务器上；

所述分布式设备的主控板卡从CF卡或者FTP/TFTP服务器上读取所述复合版本软件包文件。

本发明还公开了一种分布式设备，该设备包括一个主控板卡和两个或两个以上的业务板卡，其中：

主控板卡，读取复合版本软件包文件，升级本主控板卡的软件版本，以及将所述复合版本软件包文件中业务板卡的软件文件下发给业务板卡；

业务板卡，根据所述主控板卡下发的软件文件升级本业务板卡的软件版本。

可选地，上述设备中，所述主控板卡，将述复合版本软件包文件中业务板卡的软件文件一次性下发以实现业务板卡的软件版本的升级。

可选地，上述设备中，所述主控板卡，将所述复合版本软件包文件中业务板卡的软件文件进行广播；

所述业务板卡，接收所广播的软件文件，从所述软件文件中查找适合自身板卡类型的软件文件，并将查找到的软件文件保存到本地以实现软件版本的升级。

可选地，上述设备中，所述业务板卡，还通过所述复合版本软件包文件中本板卡的软件文件头信息自动检测自身版本和主控板卡的主控版本的兼容性。

可选地，上述设备中，所述主控板卡，将所述复合版本软件包文件中业务板卡的软件文件进行广播之前，还发送升级开始报文给业务板卡，该升级开始报文中至少携带待升级文件大小和主控板支持的报文单帧长度，以及接收各个业务板卡的响应报文，从中选择报文单帧长度的最小值以及发送速率的最小值，按照所选择的报文单帧长度的最小值对所述业务板卡的软件文件进行分片，并按照所选择的发送速率的最小值依次广播各分片。

所述业务板卡，接收所述升级开始报文，并回复响应报文，该响应报文中携带本业务板卡协商后的报文单帧长度和发送速率信息。

本发明还公开了一种分布式设备软件版本兼容性维护的系统，包括上述的分布式设备，以及：

版本发布单元，发布复合版本软件包文件，所述复合版本软件包文件中携带分布式设备的主控板卡以及一个或多个业务板卡的软件文件，其中，所述分布式设备的主控板卡与业务板卡的软件文件之间相互兼容。

本申请技术方案提出了一种软件版本兼容性维护的管理系统，采用统一存储，统一升级，自动同步的方式快速、有效的保证各类型板卡软件版本的兼容性。

附图说明

图1为本实施例中软件包文件的结构示意图；

图2为本实施例中版本文件结构示意图；

图3为本实施例中设备版本升级流程图；

图4为本实施例中业务板版本自动更新流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文将结合附图对本发明技术方案作进一步详细说明。需要说明的是，在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

实施例1

本案发明人考虑到，分布式设备一般涉及到多种不同类型的业务板卡，每一种类型的业务板卡都有自己适用的软件版本，并且该软件版本随着时间的发展会有许多不同版本发布，一般通过更加细致的小版本号来标识，这样造成分布式设备适用的软件版本众多，不易管理。因此，发明人提出一种新的版本发布方式，采用软件打包的方法，将该分布式设备上所有板卡（包括主控板卡和业务板卡）相关的软件打包为一个整体的复合版本文件，该复合版本文件中的软件版本是相互兼容的，这样的复合版本文件称为复合版本软件包文件。采用软件包版本文件的发布方式可以有效的减少版本的数目，保证软件包内各个业务板卡版本的兼容性。

基于上述思想，本实施例提出一种分布式设备上高效灵活的分布式设备软件版本兼容性维护方法，采用统一存储，统一升级，自动同步的方式来简化分布式设备上版本升级和维护的工作，具体地，该方法包括如下操作：

步骤一，发布复合版本软件包文件，即在软件版本文件发布时候将该分布式设备上所有板卡（包括主控板卡和业务板卡）相关的版本兼容的软件打包为整体发布。需要说明的是，初次发布时需要包括所有板卡的软件打包整体发布，之后如果存在某单板要发布补丁版本，建议使用待发布的补丁版本替换掉上一版复合版本软件包中的该单板的版本，以完成新的发布。

具体地，复合版本软件包文件由软件包文件头和软件包文件体两部分组成，如图1所示。其中，软件包文件体部分由各个板卡（包括主控板卡和业务板卡）的软件文件顺序串接构成。而软件文件如图2所示，包括软件文件头和软件文件体。文件头的长度固定，软件包的文件头与软件文件的文件头结构一致，具体包含如下各类信息。

文件标识：标识此文件是否为该分布式设备的发布版本文件，可设置为固定的字符串。

设备类型：软件版本文件适用的业务板卡类型，软件包的设备类型可填写适用的分布式设备的类型。

版本文件类别：标识系统软件版本，以及标识软件包版本，此信息可扩展。例如：某板卡中存在可升级的固件版本，故可扩展新的枚举值标识该版本文件为固件版本文件。

大版本号：相同的大版本号表示软件架构基本没有发生变化，即各业务板卡的软件文件的大版本号相同时表示复合版本软件包文件中的各软件文件之间相互兼容。一般，软件包的大版本号应与所包含的主控板A板版本的大版本号相同。

小版本号：规划发布或测试版本的最小粒度。软件包的小版本号应与所包含的主控板A板版本的小版本号相同。

其他版本号：更细致的软件版本的划分，可扩展。

年月日：软件版本编译的时间。

文件体长度：不包括文件头，该版本文件剩余的长度，单位为字节。

文件校检码：包括文件头和文件体的校检码，通常采用CRC校验。

步骤二、将复合版本软件包文件保存在CF卡或者FTP/TFTP服务器上；

其中，将复合版本文件保存在CF卡上时，可以将CF卡在主控板卡上以插卡式方式管理，从而保证快速读取和容易更换。

步骤三、主控板卡读取复合版本软件包文件，升级所有板卡（包括主控板卡和业务板卡）的软件版本；

具体地，可一次性升级所有板卡的软件版本，这样可以大大缩短升级时间，且保证各种板卡上软件版本的兼容性。

需要说明的是，分布式设备上所有单板还可以自动检测自身版本和主控版本的兼容性，如果不兼容则主动使用软件包更新自身软件版本。

上述方法中提到的软件版本为各个板卡上支持升级的系统软件版本，下面以主控板卡A，业务板卡B、C、D为例，详细阐述上述分布式设备软件版本兼容性维护的过程，该过程如图3所示。

主控板卡A和业务板卡B、C处于正常和通信状态。

软件包文件通过CF卡提供或者FTP/TFTP服务器提供，主控板卡A可以访问。

主控板卡A某上层应用调用整机设备版本升级函数，整机设备版本升级函数的参数包括：软件包名称、软件包所处位置（如果是CF卡指明设备类型，如果FTP/TFTP服务器则指明IP地址）、用户名、密码等，以保证主控板卡A可以成功访问。

主控板卡A的版本升级任务接受到上层应用的整机升级请求，判断上述参数的合法性，不合法则返回错误给上层应用。参数合法则获取待升级的版本文件的大小。需要指明的是，该大小是指软件包的大小。

主控板卡A的版本升级任务获取到待升级文件大小后发送升级开始报文给所有业务板卡，该升级开始报文携带信息包括：待升级文件大小，主控板A支持的报文单帧长度。

业务板卡B、C接收到升级开始报文后，回复ACK报文，携带协商后的报文单帧长度（自身支持的单帧长度和主控板A支持的单帧长度，选较小值作为协商后的结果），发送速率等信息。

主控板卡A接收到各个板卡的ACK报文，从中选择单帧长度较小，发送速率较慢的值作为本次升级协商后的参数使用。

主控板卡A的版本升级任务按照协商后的参数发送版本文件到各个业务板卡。这个发送过程是广播的过程，版本文件一般都比较大，需要多次传送，采用目前常用的分片方式，完成版本文件的发送。在传送的过程中可以将已传送文件的大小通知上层应用以表示目前升级进度。需要说明的是，如果软件包通过CF卡提供，则主控板卡A自身升级不需要真正的传送版本文件。

版本文件发送完毕后，主控板卡A的版本升级任务发送升级结束报文到业务版，该升级结束报文携带的信息包括：版本文件的校验码，版本文件的总长度，发送版本文件的总帧数。

业务板卡B、C的版本升级任务接收到升级结束报文后，验证自己接收的软件包文件是否合法，不合法则返回错误，合法则从软件包中查找适合自身板卡类型版本文件，如果软件包中不存在适合该板卡的版本文件则返回错误，存在则保存该版本文件到业务板本地，返回成功。查找适合自身板卡类型的版本文件的过程如下：

1，读取文件的指针指向文件开始；

2，如果指针为空，则返回空，非空读取文件头，判断文件头的版本文件类别。如果版本文件类别为软件包，则跳转到3，为版本文件，则跳转到4；

3，版本文件类别为软件包，读取文件指针向下跳转文件头长度，指向下一个文件头的开始，跳转到2；

4，版本文件类别为版本文件，判断文件头中设备类型是否符合自身的板卡类型，如果符合，则跳转到5，不符合，则读取文件指针向下跳转文件头长度加上文件头中的文件体长度，指向下一个文件头的开始，跳转到2；

5，读取文件的指针指向符合设备自身板卡类型的版本文件的开始，返回该指针。

需要说明的是，各个板卡接收到软件包的版本文件可以有两种选择，选择一：待版本文件传输完毕后，判断其合法性和是否存在适合自身板卡类型的版本文件，这样因为软件包较大，故需要板卡自身有较大的内存，可以暂时保存软件包文件；选择二：版本文件传输过程中，只要获取到需要的文件内容，就直接判断是否是适合自身板卡类型的版本文件，不适合的文件直接丢弃不保存，这样可以减少对板卡内存的要求。

主控板卡A的版本升级任务接收到各个板卡升级结束的ACK报文后将各个板卡的升级结果返回给上层应用，本次升级结束。

需要说明的是，上述分布式设备涉及到2种业务板卡，本申请支持使用软件包文件对指定槽位、指定类型的板卡或者对整机全部板卡进行升级。指定槽位和指定类型的板卡升级方式目前大多数设备都支持，本文中不在详细叙述。

另外，在上述方法的基础上，还可能发生版本升级更新的情况，故优选方案提出，分布式设备在引导程序加载完毕检验自身系统软件的版本和软件包版本是否兼容，不兼容则直接发起版本更新功能。更新成功后加载更新后的系统软件，这样当该板插入一个新的分布式设备上，主控板卡启动就可以保证和其他业务板卡版本间的兼容性，简化了版本的维护工作。下面以主控板卡A和业务板卡B为例，详细阐述版本更新的过程，该过程如图4所示。

主控板卡A处于正常运行状态。主控板卡A中的版本文件需保证和软件包中的主控板卡A的版本文件一致。

软件包文件通过CF卡提供或者FTP/TFTP服务器提供，在主控盘上可以访问。

业务板卡B上电启动，开始加载引导程序。

业务板卡B引导程序加载完毕后，则向主控板卡A发送版本协商请求报文，并等待应答，超时无应答则重发。版本协商请求报文携带参数：板卡类型，版本详细信息。版本的详细信息包括版本文件头中的大版本号、小版本号。

主控板卡A接收到版本协商请求后，从软件包中获取适合该业务板卡的版本文件头，获取过程同之上的获取过程，如果获取失败，则返回无相应的版本文件，获取成功则将该版本文件的版本号信息和协商请求报文中的版本号信息相比较，将结果通过协商请求ACK报文返回给业务板卡，协商结果支持三种：一致，不一致，无相应的版本文件，本申请中的兼容性通过是否一致来判断，如果大版本号相同则认为一致，是兼容的。这里的处理是可选的，也可以大版本号和小版本号都相同，才认为是一致，为兼容的。

业务板卡B接收到版本协商请求ACK报文，如果协商结果为一致则退出版本更新流程，直接加载板卡本地的系统软件。如果协商结果不一致则开始版本更新流程，如果无相应的版本文件则退出版本协商过程，直接加载本地的软件版本。

业务板卡B发送版本文件请求报文，并等待应答，超时无应答则认为本次自动更新版本失败，重新进入版本协商过程。版本文件请求报文携带参数：板卡类型，最大支持的单帧长度，已完成的文件长度。

主控板卡A接收到版本文件请求报文，通过已完成的文件长度，从软件包中获取相应位置的版本文件，并按照版本文件请求报文中支持的单帧长度发送ACK报文给业务板卡。ACK报文中携带参数：版本文件数据，版本文件数据长度，是否还有分片标记。

业务板卡B接收到版本文件ACK报文，保存该版本文件，如果还有分片则再次发送版本文件请求报文，如果无分片则表示版本获取完毕。

业务板卡B接收版本文件完毕后，验证该版本文件的合法性，如果不合法则认为本此版本更新失败，重新进入版本协商过程。合法则将该版本文件保存本地。

业务板卡B加载本地保存的版本文件。

如果版本更新3次（更新最大次数）都失败，则不再重新进入版本协商过程，直接加载本地的软件版本。

实施例2

本实施例提供一种分布式设备软件版本兼容性维护的系统，至少包括版本发布单元和分布式设备。

版本发布单元，发布复合版本软件包文件，该复合版本软件包文件中携带分布式设备的主控板卡以及所有业务板卡的软件文件，其中，分布式设备的主控板卡和各个业务板卡的软件文件之间相互兼容。

本实施例中，复合版本软件包文件包括软件包文件头和软件包文件体，所述软件包文件体由分布式设备的主控板卡以及所有业务板卡的软件文件顺序串接构成。而业务板卡的软件文件包括软件文件头和软件文件体，其中，软件文件头至少包括如下信息：

文件标识，用于标识此文件对应的分布式设备的版本文件；

设备类型，用于标识软件版本文件适用的业务板卡类型；

版本文件类别，用于标识系统软件版本以及软件包版本；

大版本号，用于指示分布式设备中各板卡的软件文件之间的兼容性；

小版本号，规划发布或测试版本的最小粒度。

在上述软件文件头所包括的信息的基础上，还可以包括如下信息：

年月日，表示软件版本编译的时间；

文件体长度，表示除文件头以外，该版本文件剩余的长度；

文件校检码，包括文件头和文件体的校检码。

还要说明的是，上述版本发布单元可以将复合版本软件包文件保存在CF卡或者FTP/TFTP服务器上，这样分布式设备的主控板卡从CF卡或者FTP/TFTP服务器上读取复合版本软件包文件即可。

分布式设备，读取版本发布单元所发布的复合版本软件包文件，升级本分布式设备中主控板卡以及所有业务板卡的软件版本。

本实施例中，分布式设备分为一个主控板卡和两个或两个以上的业务板卡。

主控板卡，读取复合版本软件包文件，升级本主控板卡的软件版本，以及将复合版本软件包文件中业务板卡的软件文件下发给业务板卡；

其中，上述主控板卡，将复合版本软件包文件中业务板卡的软件文件进行广播。

业务板卡，根据所述主控板卡下发的软件文件升级本业务板卡的软件版本。

而业务板卡，接收所广播的软件文件后，从软件文件中查找适合自身板卡类型的软件文件，并将查找到的软件文件保存到本地以实现软件版本的升级。

具体地，主控板卡，将复合版本软件包文件中业务板卡的软件文件进行广播之前，还发送升级开始报文给业务板卡，该升级开始报文中至少携带待升级文件大小和主控板支持的报文单帧长度，以及接收各个业务板卡的响应报文，从中选择报文单帧长度的最小值以及发送速率的最小值作为本次升级协商后的参数使用，即按照所选择的报文单帧长度的最小值对所述业务板卡的软件文件进行分片，并按照所选择的发送速率的最小值依次广播各分片。

对应的，业务板卡，接收升级开始报文，并回复响应报文，该响应报文中携带本业务板卡协商后的报文单帧长度和发送速率信息。

另外，业务板卡还可以通过复合版本软件包文件中本板卡的软件文件头信息自动检测自身版本和主控板卡的主控版本的兼容性。

而主控板卡和各业务板卡之间实现软件版本兼升级的具体过程可参见上述实施例1中相应的内容，在此不再赘述。

从上述实施例可以看出，本申请技术方案提出了一种复合版本文件的发布方式，可以有效的减少发布版本的数量，方便了版本文件的存储和管理，并且基于复合版本文件提供整机升级的新功能，可以一次性的升级所有业务板卡（包括主控板卡和所有业务板卡）的软件版本，缩短升级时间，较好的保证了各种板卡上的软件版本的兼容性。另在业务板卡上增加了版本自动更新功能，业务板在启动过程中会自动检测自身板卡和主控版本的兼容性，如果不兼容则主动使用复合版本文件更新自身的软件版本，有效的简化了版本管理的升级和维护工作。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

以上所述，仅为本发明的较佳实例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种分布式设备软件版本兼容性维护的方法，其特征在于，该方法包括：

发布复合版本软件包文件，所述复合版本软件包文件中携带分布式设备的主控板卡以及一个或多个业务板卡的软件文件，其中，所述分布式设备的主控板卡与业务板卡的软件文件之间相互兼容；

分布式设备的主控板卡读取所述复合版本软件包文件，升级本分布式设备的主控板卡以及所有业务板卡的软件版本，具体为：所述分布式设备的主控板卡将所述复合版本软件包文件中业务板卡的软件文件进行广播，所述分布式设备的业务板卡接收所广播的软件文件，根据所述软件文件中的设备类型查找适合自身板卡类型的软件文件，并将查找到的软件文件保存到本地；

所述分布式设备将所述复合版本软件包文件中业务板卡的软件文件进行广播之前，该方法还包括：

所述分布式设备的主控板卡发送升级开始报文给业务板卡，该升级开始报文中至少携带待升级文件大小和主控板支持的报文单帧长度；

业务板卡接收到所述升级开始报文后，回复响应报文，该响应报文中携带本业务板卡协商后的报文单帧长度和发送速率信息；

主控板卡接收各个业务板卡的响应报文，从中选择报文单帧长度的最小值以及发送速率的最小值，按照所选择的报文单帧长度的最小值对所述业务板卡的软件文件进行分片，并按照所选择的发送速率的最小值依次广播各分片。

2.如权利要求1所述的方法，其特征在于，所述复合版本软件包文件包括软件包文件头和软件包文件体，所述软件包文件体由分布式设备的主控板卡以及携带的业务板卡的软件文件构成。

3.如权利要求2所述的方法，其特征在于，所述业务板卡的软件文件包括软件文件头和软件文件体，其中，所述软件文件头包括如下信息：

文件标识，用于标识此文件对应的分布式设备的版本文件；

设备类型，用于标识软件版本文件适用的业务板卡类型；

版本文件类别，用于标识系统软件版本以及软件包版本；

大版本号，用于指示分布式设备中各板卡的软件文件之间的兼容性；

小版本号，规划发布或测试版本的最小粒度。

4.如权利要求1所述的方法，其特征在于，

所述分布式设备的主控板卡读取所述复合版本软件包文件后，一次性升级本主控板卡和业务板卡的软件版本。

5.如权利要求1所述的方法，其特征在于，该方法还包括：

所述分布式设备上业务板卡通过所述复合版本软件包文件中本板卡的软件文件头信息自动检测自身版本和主控板卡的主控版本的兼容性。

6.如权利要求1所述的方法，其特征在于，

将所述复合版本软件包文件保存在闪存卡或者文件传输协议/简单文件传输协议FTP/TFTP服务器上；

所述分布式设备的主控板卡从闪存卡或者FTP/TFTP服务器上读取所述复合版本软件包文件。

7.一种分布式设备，其特征在于，该设备包括一个主控板卡和两个以上的业务板卡，其中：

所述主控板卡，读取复合版本软件包文件，升级本主控板卡的软件版本，以及将所述复合版本软件包文件中业务板卡的软件文件下发给业务板卡；还用于将所述复合版本软件包文件中业务板卡的软件文件进行广播；所述主控板卡将所述复合版本软件包文件中业务板卡的软件文件进行广播之前，还发送升级开始报文给业务板卡，该升级开始报文中至少携带待升级文件大小和主控板支持的报文单帧长度，以及接收各个业务板卡的响应报文，从中选择报文单帧长度的最小值以及发送速率的最小值，按照所选择的报文单帧长度的最小值对所述业务板卡的软件文件进行分片，并按照所选择的发送速率的最小值依次广播各分片；

所述业务板卡，根据所述主控板卡下发的软件文件升级本业务板卡的软件版本；还用于接收所广播的软件文件，从所述软件文件中查找适合自身板卡类型的软件文件，并将查找到的软件文件保存到本地以实现软件版本的升级；还用于接收所述升级开始报文，并回复响应报文，该响应报文中携带本业务板卡协商后的报文单帧长度和发送速率信息。

8.如权利要求7所述的设备，其特征在于，

所述主控板卡，将述复合版本软件包文件中业务板卡的软件文件一次性下发以实现业务板卡的软件版本的升级。

9.如权利要求7所述的设备，其特征在于，

所述业务板卡，还通过所述复合版本软件包文件中本板卡的软件文件头信息自动检测自身版本和主控板卡的主控版本的兼容性。

10.一种分布式设备软件版本兼容性维护的系统，其特征在于，包括如权利要求7至9任一项所述的分布式设备，以及版本发布单元，其中：

版本发布单元，发布复合版本软件包文件，所述复合版本软件包文件中携带分布式设备的主控板卡以及一个或多个业务板卡的软件文件，其中，所述分布式设备的主控板卡与业务板卡的软件文件之间相互兼容；

分布式设备，读取版本发布单元所发布的复合版本软件包文件，升级本分布式设备中主控板卡以及所有业务板卡的软件版本。