为了满足通信业务中变化多端的业务需求，在现有的通信设备中设计出 各种类型的单板来实现相应的功能。对于高端的通信设备，为了达到很高的 性能和容量，一般都采用多业务板架构的系统进行分布式处理。这种多业务 板架构的系统一般包括一块主控板和多块业务板。主控板是一个系统的核心 单板，它主要完成管理工作，用于控制各业务板的工作。主控板的种类或数 量相对比较稳定。业务板又称线路板或接口板，是提供具体业务的单板，分 别与主控板相连接，可以有对外接口也可以没有对外接口，它们通常自带一 个或多个独立的中央处理器(CPU)。为了满足特定的业务需求往往需要更 换不同属性的业务板，例如端口数量、端口类型、连接的速率、接口类型、 使用芯片或者是功能的编号等发生变化，都会需要增加新的单板。因此业务 板一般种类比较多，并且变化比较频繁。
由于每块业务板都分担了一部分工作，整机的性能就能得到很高的提 升。在这种分布式处理的多业务板架构中，为了使每个业务板能与其他业务 板正确地配合工作，一般要求每个业务板都要了解其它业务板的一些属性信 息。所谓属性信息就是与该业务板硬件相关的信息，例如最大端口数、最大 子卡数、子卡类型、最大子卡类型、使用的交换芯片类型和控制芯片类型、 单板端口数量、端口连接方式、交换芯片的连接关系等等。例如需要实现将 数据包从业务板A转发到业务板B，则这两块业务板要知道对方的端口配置 情况、交换芯片连接情况等等，以便能够将数据包发送到正确的端口。
为了能够实现各个业务板都了解本系统中其他业务板的属性信息，通常 在程序中内置了已经存在的每种业务板的属性信息，这样在系统工作时，每 块业务板只需要知道系统配置的其它业务板的类型信息，就能准确获得该业 务板的属性信息，从而与之建立正确的交换连接关系。所谓类型信息就是该 业务板可以实现什么功能，例如实现以太网的接口功能。类型信息和属性信 息可统称为单板的特性信息。
这种方法实现比较简单，但存在如下缺点：由于业务板的类型和属性必 需在程序中预先定义好，如果增加一种类型的业务板，或者对原有类型的业 务板进行升级，造成该类型业务板的属性发生改变，就需要对程序进行重新 编译和升级。如果要在现有已经运行的系统中添加新类型的业务板或更换原 有类型的业务板时，必须重启系统后才能正常工作，这样会中断当前的网络 业务。

有鉴于此，本发明的目的在于，提出一种实现多业务板架构的方法，可 以实现在多业务板架构的系统中增加新业务板或更换不同属性的业务板时， 系统无须重启即可正常工作。该方法包括如下步骤：
A、新业务板向多业务板架构系统的主控板发送携带自身特性信息的注 册请求；
B、主控板根据所述注册请求中的特性信息，更新本地保存的特性信息 库，并通知所述系统中已有的业务板同步更新自身的特性信息库；
C、主控板向新业务板发送携带特性信息库的注册完成确认信息，新业 务板将所收到的确认信息中的特性信息库保存为自身的特性信息库。所述特 性信息包括业务板的硬件属性信息和至少一个功能标识。
所述特性信息库为业务板的板号与功能标识以及属性信息的对应关系 表，步骤B所述主控板根据所述注册请求中的特性信息，更新本地保存的特 性信息库包括：
B1、主控板根据注册信息中包含的板号对所述对应关系表进行检索， 如果检索到相同的板号，执行步骤B2，否则执行步骤B3；
B2、用注册信息中的属性信息和功能标识替换对应关系表中与所述板 号对应的属性信息和功能标识；执行完毕后跳过步骤B3执行后续步骤；
B3、在对应关系表中新建表项，表项中保存注册消息中的板号以及与 所述板号对应的属性信息和功能标识。
步骤B所述通知所述系统中已有的业务板同步更新自身的特性信息库 为如下方式之一：
主控板将新业务板的注册信息转发给各个已有业务板，各个已有业务板 采用与主控板相同的方式更新自身的特性信息库；
主控板将自身的特性信息库的全部内容，或者除去将要发送的业务板所 对应的那部分内容之外的全部内容发送到各个已有的业务板，各个已有的业 务板将所收到的特性信息库作为自身的特性信息库；
主控板将自身特性信息库中更新的部分发送到各个已有业务板，各个已 有业务板进行相应的更新。
该方法进一步包括：所述系统中的业务板根据自身保存的特性信息库中 的特性信息识别所述系统中其它业务板并完成相关业务的处理。
本发明还公开了另一种实现多业务板架构的方法，包括如下步骤：
a、多业务板架构系统的主控板或所述多业务板架构系统之外的设备读 取新业务板的描述文件，根据所述描述文件以及多业务板架构系统已有的设 备配置文件生成更新后的设备配置文件；
b、多业务板架构系统的主控板或所述多业务板架构系统之外的设备将 更新后的设备配置文件刷新到所述系统的主控板和已有的各个业务板中；
c、新业务板插入所述多业务板架构系统并启动后，所述多业务板架构 系统中已有的业务板根据自身保存的设备配置文件识别新业务板并完成与 新业务板的相关业务工作。
所述描述文件中包括业务板的硬件属性信息和至少一个功能标识。
步骤b为：将更新后的设备配置文件刷新到主控板，主控板再通知所述 系统中各个已有业务板更新设备配置文件。
步骤b进一步包括：将更新后的设备配置文件刷新到新业务板中。
本发明的另一目的在于，提出实现多业务板架构的装置，可以实现在多 业务板架构的系统中增加新业务板或更换不同属性的业务板时，系统无须重 启即可正常工作。该装置位于业务板中，包括：
收发模块，用于接收来自主控板的更新特性信息的通知，并将所述通知 中的特性信息发送到特性信息存储模块；所述收发模块进一步包括注册单 元，用于向主控板发送携带本业务板特性信息的注册请求，并接收来自主控 板的注册完成的通知消息；
特性信息存储模块，用于存储多业务板架构系统中其他各个业务板的特 性信息；根据收发模块发送来的特性信息更新所存储的特性信息；
特性信息处理模块，用于读取特性信息存储模块中相应的特性信息生成 业务操作指令。
所述特性信息存储模块进一步用于当更新完成后向收发模块发送更新 完成的确认消息；
则所述收发模块进一步用于当特性信息更新完成时，向主控板发送更新 完成的确认信息。
本发明还提出了一种位于主控板中实现多业务板架构的装置，包括：
收发模块，用于接收新业务板的注册请求，将注册请求中的特性信息发 送到特性信息存储模块；向多业务板架构系统中已有的业务板发送更新特性 信息的通知；接收已有业务板返回的更新完成的确认信息；当所有已有业务 板返回更新完成的确认信息后，向新业务板发送注册完成的通知信息；
特性信息存储模块，用于存储多业务板架构系统中各个业务板的特性信 息，根据收发模块发送来的特性信息更新所存储的特性信息。
该装置进一步包括特性信息处理模块，用于读取特性信息存储模块中相 应的特性信息生成业务操作指令。
本发明的目的还在于，提出一种实现多业务板架构的系统，在系统中增 加新业务板或更换不同属性的业务板时，可以实现无须重启即可正常工作。 该系统包括一块主控板和一块以上的业务板，所述业务板中保存系统中其他 业务板的特性信息，并依据自身保存的特性信息识别系统中其他业务板并完 成相关业务操作；
所述主控板中保存系统中所有业务板的特性信息，当系统中增加新业务 板或将系统中已有的业务板更换为实现相同业务功能但属性信息不同的业 务板时，对所保存的业务板特性信息进行更新，并通知系统中的业务板同步 更新其所保存的特性信息。
所述业务板中包括：
收发模块，用于接收来自主控板的更新特性信息的通知，并将所述通知 中的特性信息发送到特性信息存储模块；当特性信息更新完成时，向主控板 发送更新完成的确认信息；
特性信息存储模块，用于存储系统中其他各个业务板的特性信息；根据 收发模块发送来的特性信息更新所存储的特性信息，更新完成后向收发模块 发送更新完成的确认消息；
特性信息处理模块，用于读取特性信息存储模块中相应的特性信息生成 业务操作指令。
所述收发模块进一步包括注册单元，用于向主控板发送携带本业务板特 性信息的注册请求，并接收来自主控板的注册完成的通知消息。
所述主控板包括：
收发模块，用于接收新业务板的注册请求，将注册请求中的特性信息发 送到特性信息存储模块；向系统中已有的业务板发送更新特性信息的通知， 并接收已有业务板返回的更新完成的确认信息；当所有已有业务板返回更新 完成的确认信息后，向新业务板发送注册完成的通知信息；
特性信息存储模块，用于存储系统中各个业务板的特性信息，根据收发 模块发送来的特性信息更新所存储的特性信息。
所述主控板进一步包括特性信息处理模块，用于读取特性信息存储模块 中相应的特性信息生成业务操作指令。
从以上技术方案可以看出，在业务板中保存系统中其他业务板的特性信 息，这样，业务板可以通过自身保存的特性信息对系统中其他业务板进行识 别，并在此基础上与其他业务板相互协作完成业务功能；相应地，主控板中 保存系统中所有业务板的特性信息，并可以在系统中增加新业务板或更换不 同属性的业务板时通知各个业务板更新其保存的特性信息。这样就可实现系 统无须重启进行在线更新，保证原有业务不会中断。
附图说明
图1为本发明实施例一的信令交换流程图；
图2为本发明实施例二的方法流程图；
图3为本发明实施例的业务板中的装置的结构示意图；
图4为本发明实施例的主控板中的装置的结构示意图。

本发明的核心思想为：在每块业务板上都设置用于保存其他业务板特性 信息的特性信息库；当系统中添加新的业务板时，新业务板的特性信息会更 新到各个业务板的特性信息库中，新业务板中也会有其他已有业务板的特性 信息；程序中不用预先定义全部业务板的特性信息，只需要新开发的单板插 入系统时，将自己特性信息同步到所有单板即可实现业务功能。通过这种方 式，系统无须重启就可实现增加或更换业务板，并且能够正常地工作。所述 新业务板可能是新开发的具有新的业务功能的业务板，或者虽然实现系统中 原有的业务功能，但属性发生变化的业务板。
为实现上述发明思想，首先要对业务板进行基本功能归类。每个业务板 的功能都可根据是否需要与其他单板相互配合，分为本业务板独立完成的功 能和与其他业务板协作完成的功能，为便于描述，不妨分别称为第一类功能 和第二类功能。第一类功能的实现不需要其他单板了解本单板的特性信息， 其实现方式比较简单，且与本发明方案无关；对于第二类功能可进一步细分 为多个基本功能。所谓基本功能就是按照实际需要定义的最小功能。预先定 义由一组基本功能组成的基本功能总集，每一个基本功能对应唯一的功能标 识。系统中所有业务板的第二类功能都可对应该基本功能总集中的一个基本 功能或由一个以上的基本功能组成的集合。对应相同的基本功能或基本功能 集合的业务板，在其他单板上按照相同的方式进行处理。
为使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实 施例对本发明作进一步的详细阐述。
实施例一的新业务板插入系统后的注册流程如图1所示，包括如下步 骤：
步骤101：新业务板向主控板发送携带本业务板特性信息的注册信息。 所述注册信息中包含该系统中所有其它业务板所需要的所述新业务板的硬 件属性信息，包括但不限于单板最大端口数、最大子卡数、子卡类型、最大 子卡类型、使用的交换芯片类型和控制芯片类型、单板端口数量、端口连接 方式、交换芯片的连接关系等；注册信息还包括所述新业务板的类型信息， 在本实施例中，所述类型信息为该业务板的第二类功能对应的一个或一个以 上的功能标识；注册信息中还包括新业务板的板号。所述板号对应该业务板 所插入的主控板的业务插槽的槽号，通常板号和槽号是一致的。
步骤102：主控板收到注册信息后，将新单板的属性信息保存在主控板 的特性信息库中。
本实施例中，特性信息库的具体形式为业务板的板号与功能标识和属性 信息的对应关系表。每个板号对应该业务板的属性信息和功能标识。所述将 新单板的属性信息保存在主控板的特性信息库中包括如下步骤：
步骤102a：根据注册信息中包含的板号对所述对应关系表进行检索， 如果检索到相同的板号，说明该新业务板是替换系统中已有的一块业务板， 执行步骤102b，否则执行步骤102c；
步骤102b：用注册信息中的属性信息和功能标识替换对应关系表中与 所述板号对应的属性信息和功能标识；执行完毕后结束步骤102；
步骤102c：在对应关系表中新建表项，表项中保存注册消息中的属性 信息和功能标识。
特性信息库中可能还有其他相关信息需要进行更新。例如，如果新业务 板的最大端口数、最大子卡数超过原来的数值，则需要更新为新的值；最大 的业务板类型值也需要更新为新值，以保持与系统中实际业务板类型的数目 一致。如果更新后的特性信息库的数据量大于其存储空间，则还要调整其存 储容量以便存储相应的数据等。这些操作为本领域技术人员熟知的内容，故 不再赘述。
步骤103：主控板通知原有的各个业务板同步更新其特性信息库。具体 可能是如下任意一种方式：
主控板将新业务板的注册信息转发给各个已有的业务板，各个已有业务 板采用与主控板相同的方式更新自身的特性信息库；
主控板将自身的特性信息库的全部内容，或者除去将要发送的业务板所 对应的那部分内容之外的全部内容发送到各个已有的业务板，各个已有的业 务板将所收到的特性信息库作为自身的特性信息库；主控板将自身特性信息 库中更新的部分发送到各个已有业务板，各个已有业务板进行相应的更新。
步骤104：已有业务板完成更新自身的特性信息库后，向主控板返回更 新完成的确认信息；
步骤105：主控板收到全部已有业务板的确认信息后，向新业务板发送 注册完成的通知消息。
新业务板上可以预先配置包括系统中各个已有业务板的特性信息的特 性信息库，在这种情况下所述通知信息可不携带任何内容，而仅是一个提示 信息；当然新业务板也可能没有配置特性信息库，则所述通知消息中可以携 带主控板上的特性信息库，新业务板将其保存为自身的特性信息库。
完成以上流程后，系统中任何一块业务板可根据自身特性信息库中的业 务板的功能标识识别其业务功能特性，同时根据与功能标识对应的属性信息 可以准确的完成相关业务的处理，不用重启系统。
实施例一是通过新业务板插入后，由新业务板发起注册流程从而实现各 个业务板以及主控板更新特性信息库。下面的实施例二则是在插入业务板之 前通过加载业务板特性信息描述文件的方式实现相同的目的，与实施例一相 比较，实施例二更为全面和灵活，可以方便地在线更改运行中的业务板的配 置情况，具有更大的适应性。
实施例二中，每个业务板的特性信息用一个特性信息描述文件(以下简 称为描述文件)来描述，所述描述文件中包括该业务板的属性信息和类型信 息，属性信息和类型信息的具体含义可参照实施例一的相关描述。描述文件 可以作为一个独立的文件或者是其他文件的一部分，例如为该业务板驱动程 序文件中的一部分。描述文件可以保存在业务板中或者其他存储介质如光盘 中。
实施例二的实现流程如图2所示，包括如下步骤：
步骤201：读取新业务板的描述文件，根据所述描述文件以及系统已有 的设备配置文件生成包括新业务板以及已有业务板的特性信息的更新后的 设备配置文件。
所述设备配置文件的内容可以为实施例一所描述的特性信息库，生成设 备配置文件的过程可以类似实施例一在主控板中进行，也可在系统之外的设 备中进行。从以上描述可以看出，所谓设备配置文件等同于实施例一所述的 特性信息库，只是表现形式可能有所不同而已。
步骤202：将更新后的设备配置文件刷新到主控板和系统中已有的各个 业务板，通常是先将更新后的设备配置文件刷新到主控板，主控板再通知各 个已有业务板更新设备配置文件。如果新业务板中没有设备配置文件，则也 要刷新到新业务板中。
步骤203：在系统中插入新业务板，新业务板启动后，由于其它业务板 的设备配置信息都已经更新，所以系统能够正确识别该业务板，并与该业务 板进行协调工作。系统或其中任何一块业务板都不用重启。
为了能够实现本发明方法，在业务板中需要增加如图3所示装置，具体 包括如下模块：
收发模块301，用于接收来自主控板的更新特性信息的通知，并将所述 通知中的特性信息发送到特性信息存储模块302；当特性信息更新完成时， 向主控板发送更新完成的确认信息。收发模块301中还可以包括一个注册单 元，当所述业务板作为将要插入系统的新业务板时，所述注册单元用于向主 控板发送携带本业务板特性信息的注册请求，并接收来自主控板的注册完成 的通知消息；
特性信息存储模块302，用于存储系统中其他各个业务板的特性信息， 即存储特性信息库或设备配置文件；根据收发模块301发送来的特性信息更 新所存储的特性信息，更新完成后向收发模块301发送更新完成的确认消 息；
特性信息处理模块303，用于根据业务板实际的业务需要，读取特性信 息存储模块302中相应的特性信息生成业务操作指令。
例如需要实现将数据包从业务板A转发到业务板B，则业务板A上的 特性信息处理模块就读取特性信息存储模块中业务板B的特性信息，得知业 务板B的端口号、交换芯片连接信息等，然后根据这些信息生成正确的转发 数据包的指令；业务板B同时也要执行类似的操作。
相应地，主控板中也要增加如图4所示的装置，包括如下模块：
收发模块401，用于接收新业务板的注册请求，将注册请求中的特性信 息发送到特性信息存储模块402；向系统中已有的业务板发送更新特性信息 的通知，并接收已有业务板返回的更新完成的确认信息；当所有已有业务板 返回更新完成的确认信息后，向新业务板发送注册完成的通知信息；
特性信息存储模块402，用于存储系统中各个业务板的特性信息，根据 收发模块401发送来的特性信息更新所存储的特性信息。
以上所述主控板上的装置是基于如下前提：系统中的各种业务都由业务 板来完成，主控板不承担具体的业务，而只用于管理各个业务板或作为各个 业务板之间的连接。在某些多业务板架构的系统中，主控板可能也具有业务 功能，即相当于主控板上集成了至少一块业务板。在这种情况下，在主控板 上的本发明装置也具有特性信息处理模块，其功能参见前面业务板中该模块 的相关描述。
本领域技术人员应当明白，本发明方案不仅适用于通信设备，对于任何 采用多业务板架构的计算机系统来说，都可采用本发明方案。
对于一个业务特性比较稳定的系统来说，由于芯片厂家变化，或者为了 适合不同场合的需要，会设计很多各种接口的业务板，而这些业务板只是一 些简单的物理特性变化，业务类型几乎不会变化，这样就可以很容易应用本 发明方案。例如，10/100M/1000M/10000M的以太网接口板，只是接口速率 的不同，其它上层特性基本没有变化。另外，还有接口的数量，接口形式(光 纤接口、双绞线接口)发生变化就可以变换出很多不同属性信息的业务板， 它们的上层特性也基本没有变化。通常一个系统的应用初期只会开发一些使 用最广的单板，到后期特性逐步稳定后，会根据市场需求逐步完善业务板种 类。在这种模式下，本发明的意义变得更为突出。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本 发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本 发明的保护范围之内。