空间站系统航天器间1553B总线网络的路由机制研究

陆岚 刘欣 余晟 周波 朱剑冰

(北京空间飞行器总体设计部，北京 100094)

航天器间通过无线或有线链路进行组网，构建空间网络已成为当前空间信息技术发展的重要趋势。为了在空间网络上实现更高效和稳定的数据传输，网络路由技术也已成为研究的关键。我国空间站系统中，多个航天器通过交会对接构建大型航天器组合体后，也需利用航天器间1553B总线网络进行信息交换。

基于1553B总线[1-2]的星内路由技术目前已有一定应用[3-4]；星间网络技术研究一方面主要集中在导航卫星[5]和微小卫星[6]领域，重点关注无线星间链路以及相关的路由算法[7]，不适用于拓扑相对稳定的有线空间网络；另一方面提出了天地一体化网络概念[8]，将空间信息网[9-10]与地面通信网融合[11-13]，但也有协议开销大、网络安全等问题。这些技术成果都不能满足空间站系统航天器间信息交互需求。

在这种背景下，本文提出了一种适用于航天器间1553B总线网络的数据包路由实现机制。该机制简化了传输层和网络层的协议，直接面对应用层的数据包进行集中式静态路由，大大提高了处理器资源和总线资源的使用效率。应用验证表明该机制的传输效率和传输时延均能够满足空间站各类平台关键数据的交互需求。

1 航天器间1553B总线网络描述

图1为空间站系统若干航天器间通过1553B总线网络互联拓扑示意图。图1中实线表示1553B总线物理连接关系，虚线表示虚拟的信息交互关系。各航天器均设置若干条平台1553B总线，用于传输各分系统遥测、遥控、以及其他重要数据。这些平台1553B总线的总线控制器BC作为路由节点。各航天器的路由节点之间也通过1553B总线互连。通过这些1553B总线物理连接关系将所有航天器上接入1553B总线的设备构成一个统一的总线网络，通过若干路由节点的协同工作，可实现网络上任意两个设备间的数据交互。

图1 航天器间1553B总线网络互联拓扑Fig.1 1553B bus network interconnection topology among spacecraft

在总线网络上，以某一个需要在航天器间进行传输的数据包PKi为例，其传输数据流见图2。该数据包的来源设备记为源节点，传输终点记为目的节点。假定源节点是路由节点1主控的某条1553B总线BUS1上的远程终端(remote terminal，RT)，地址为RT1，子地址(sub address，SA)为SA1；目的节点是路由节点3主控的某条1553B总线BUS6上的远程终端，地址为RT6，子地址为SA6。仅以单一数据包PKi为例，该数据包传输途中经过三个路由节点的三次路由描述如下：①路由节点1将PKi从总线BUS1，地址RT1，子地址SA1采集，再发送到总线BUS2，地址RT2，子地址SA2；②路由节点2将PKi从总线BUS3，地址RT3，子地址SA3采集，再发送到总线BUS4，地址RT4，子地址SA4；③路由节点3将PKi从总线BUS5，地址RT5，子地址SA5采集，再发送到总线BUS6，地址RT6，子地址SA6。

图2 航天器间数据包路由Fig.2 Data packets routing among spacecraft

2 数据包路由机制

2.1 应用层协议

空间站信息系统的应用层采用了高级在轨系统(AOS)的包装业务。所有接入1553B总线网络的设备在进行数据发送时，需利用包装业务对各个应用过程产生的数据按一定格式形成包装规约数据单元，简称数据包。

数据包格式中包含重要的逻辑地址信息见表1。主导头16 bit中包含11 bit的包应用标识(APID)信息，与副导头16 bit一起作为逻辑地址。原则是以尽量少的bit定义系统中数据包的逻辑信息，降低路由开销。逻辑地址不同字段分别定义为：目的端航天器标识(3 bit)、目的端分系统标识(4 bit)、目的端设备标识(8 bit)、数据类型标识(4 bit)和源分系统标识(4 bit)。寻址范围包括空间站组合体状态下8个航天器、每个航天器16个分系统、每个分系统256台设备、每台设备接收16种数据类型、每种数据类型16种来源。根据现有空间站信息传输需求，以此方式定义的逻辑地址具备唯一性，可支持空间站系统全网范围内寻址。所有接入空间站总线网络的设备，只需遵循同样格式和字段定义，即可完成数据收发。

表1 数据包逻辑地址

2.2 采集配置

1553B网络需要由总线控制器(BC)发起消息的采集。系统中的路由节点都需按照给定周期发出所有总线上的采集消息，因此每个路由节点配置了一张静态的采集表，其中每个表项对应一个1553B上需要采集的物理地址，主要信息包含采集总线编号、地址、子地址、消息长度、采集周期等。路由节点定期遍历采集表，按照每个表项信息，发出对应的若干个总线消息，并完成所有总线消息的后续处理。

2.3 路由配置

有线1553B网络拓扑相对稳定，数据流也具有周期性特点，因此采用了静态路由方式，即预先分配路由路径地址。路由的过程即静态寻址过程，也就是逻辑地址到物理地址的转化。数据包物理地址定义见图3，分为路由节点内部处理数据包和外部发送数据包：内部包物理地址描述为内部处理进程的编号；外部包物理地址包含目的总线编号、地址、子地址，共计24 bit。

图3 数据包物理地址Fig.3 Physical address of data packet

该寻址方式要求数据包传输时，通过查找路由表，完成路由路径选择。因此，需要路由节点启动时，完成一张静态路由表的配置工作，将系统中各设备的逻辑地址与下一跳的物理地址进行一一对应。路由表存储于各路由节点的内部存储器中，采用哈希表结构。通过哈希算法进行查找可提高查找速度。数据包到达路由节点时，路由节点按照数据包的逻辑地址查找路由表，若找到对应项，则将该数据包从对应项中所指示的下一跳物理地址转发出去。

2.4 路由过程控制

每个路由节点的路由过程控制见图4。由软件实现整个路由控制，主要包含输入控制和输出控制两个模块，其软件流程参见图5。

输入控制模块负责1553B总线上的数据采集。该模块以固定周期启动工作，启动后即遍历采集表，根据每一个采集表项生成若干个总线消息并发送，之后等待总线消息返回。待所有总线消息返回后，该模块完成所有消息处理，将需要进行路由的数据包依次拷贝到一个公共的数据包缓冲区。以图4中的某个采集表项为例，其对应了某数据源给出的位于总线“BUS1，RT1，SA1”的n个数据包序列，记为PK1～PKn。输入控制模块按照这个采集表项发出了m个总线消息，在消息返回后将PK1～PKn全部数据内容(包含导头)从1553B总线存储区拷贝到了公共数据包缓冲区。

图4 数据包路由过程控制Fig.4 Data packets routing process control

图5 软件处理流程图Fig.5 Software process flowchart

输出控制模块也以固定周期启动，启动后遍历数据包缓冲区。针对所有数据包，根据数据包的主导头APID和副导头信息计算出32 bit逻辑地址，并查找路由表信息得到对应表项。先对数据包属性进行判断：如为内部数据包，即路由节点自身为目的节点，则将该数据包发到相应内部进程处理；如为外部数据包，则先从数据包缓冲区中拷贝到一个临时缓冲区，再按照路由表描述的下一跳物理地址生成相应的总线消息队列，最后依次发送这些总线消息。以图4中的数据包序列PK1～PKn为例，输出控制模块遍历到PK1时，根据PK1的主导头APID和副导头信息计算出32 bit逻辑地址，再查找路由表得到物理地址“BUS2，RT2，SA2”，最后将PK1按照该地址发送出去；依次处理PK2～PKn，将PK2发送到“BUS3，RT3，SA3”，最后将PKn发送到“BUS4，RT4，SA4”。

2.5 组播路由

上述路由机制除了前面描述的一对一路由，还可实现组播路由。即一个数据包发送到多个目的节点。这种需求在航天器上多台设备协同工作时非常普遍。传统的处理方法是数据源节点直接发送多份相同数据包到多个目的节点。这种方法显而易见增加了链路开销以及链路上所有路由节点的资源开销，在系统资源有限的空间信息系统内不是最优选择。

本文提出的路由机制采用了附加路由表解决组播路由问题，也就是在前文描述的主路由表之外增加一张附加路由表。附加路由表也由哈希表实现，同一数据包可通过附加路由表映射到多个物理地址，这些地址可通过哈希冲突链表进行查找。如图6所示，PK1可通过附加路由表找到3个物理地址“BUS1，RT1，SA1”、“BUS2，RT2，SA2”和“BUS3，RT3，SA3”。那么PK1从数据包缓冲区拷贝3份，每份分别对应不同的物理地址形成总线消息并发送出去。

图6 附加路由表示意图Fig.6 Illustration of extra route table

附加路由表和主路由表一样，在路由节点启动时完成配置。一对多的拷贝只需在传输路径分叉的路由节点上完成，这种方式可最大程度上节约系统资源，提高传输效率。组播路由方式没有应用限制，空间站系统全网范围的所有数据包均可采用组播路由方式进行一对多路由。

3 应用验证

3.1 系统结构和设计概述

本文提出的数据包路由机制已应用于空间站组合体的信息系统。该组合体由3个可独立运行的航天器组成。信息系统包含3个互联的主干1553B网络。每个主干1553B网络包含6条1553B总线、一个路由节点和数十台接入网络的设备。

3个路由节点均采用了主频100M的3803CPU，以软件实现数据包路由机制，包括所有数据包采集和路由发送。某路由节点内维护的采集表和路由表部分内容如表2和表3所示。该路由节点按照采集表中每一项发出总线上的采集消息，在采集到数据包后查找路由表获得数据包下一跳的物理地址。例如每500 ms为周期，对总线2上RT地址为26的设备A，采集到其子地址17上的62 byte数据包。再根据数据包主导头APID为和副导头信息匹配到路由表第一项，则将数据包发送至总线2上RT地址1的子地址20。当系统中数据路由需求有变化时，可通过数据注入对采集表和路由表的相应表项进行修改。如某设备故障可迅速将该设备输入输出的数据包切换至本舱段备份的设备、甚至其他舱段的同类设备。

表2 某路由节点的采集表

表3 某路由节点的路由表

3.2 测试比对和评估

测试系统包含航天器上3个路由节点的真实软硬件和地面软件。通过地面软件仿真3个主干1553B网络上的数据源节点，模拟总线上各数据包的周期性发送，数据量与真实在轨应用需求一致。

航天器实际在轨应用中某路由节点的数据包交互需求共50项，数据包长度12～892 byte。其中42个数据包为周期性传输，8个数据包为突发性传输。周期性数据包中含6个一对三组播数据包。

实测单一主干1553B网络上的传输量为平均每500 ms有42个数据包，共8107 byte。每个数据包按照协议增加的报头和报尾共10 byte，因此网络上实际用户有效数据传输量为7687 byte，有效数据传输效率达到94%；如果采用地面广泛使用的UDP/IP协议进行路由，网络中协议开销包括各层传输协议所增加的报头和报尾，共32 byte。欲达到同样有效数据传输量，网络上的传输量需达9031 byte，有效数据传输效率仅为85%。可见针对在轨实际应用中数据包长度变化大，特别是短数据包较多的数据传输需求，采用该路由机制能够降低协议开销，提高有效数据传输效率。

实际在轨应用中周期性数据的传输周期要求为最小500 ms，无实时性要求；对于突发性数据包有实时性要求，最小为200 ms。通过实测发现单一主干1553B网络内的周期性数据包路由时间延迟平均为101 ms，在总线消息发送设置优先级调度后，高优先级数据包最小路由延迟可达20 ms。两类数据的传输时延均能满足使用要求并有充分余量。

针对组播路由方式进行评估：每500 ms周期传输6个一对三组播数据包，共228 byte，实测占用总线带宽14 kbit/s。若采用一对一路由方式，总线带宽为21 kbit/s。可见采用一对三组播方式在实际应用中可节约总线带宽30%。测试中发现，组播路由方式的数据传输效率和传输时延与一对一路由基本一致。

综上，实验验证表明该数据包路由机制的数据传输效率高、数据传输时延小，并能对长期在轨航天器的故障维修和系统重构提供有力支持。

4 结束语

本文给出的数据包路由机制已在空间站系统中得到实施，并取得了良好效果。目前空间站三舱路由节点均应用了该机制，实现了单舱内部和两舱、三舱之间的稳定可靠数据传输。

后续与空间站对接的各类飞船和来访航天器均可使用该路由机制，与空间站三舱进行数据包交互。前提是其数据源设备遵循文中所描述的数据包格式和字段定义生成数据包。来访航天器与空间站完成交会对接后，空间站三舱路由节点可通过在轨注入方法更新其采集表和路由表，之后即可实现来访航天器与三舱的数据交换。在地面支持的情况下，系统具有较好的扩展性。