基于时间同步的1553B总线通信协议设计

2021-04-28 08:40张亚航杨培尧杨志刚
航天器工程 2021年2期
关键词:接收端通信协议时序

张亚航 杨培尧 杨志刚

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

美军标MIL-STD-1553B(以下简称1553B)是一种数字式时分制指令/响应型多路传输数据总线,由于它具有双向输出特性、实时性和可靠性高,广泛应用在当代的运输机和相当数量的民航客机以及军用飞机上,航天系统也有广泛的应用[1-3]。MIL-STD-1553B总线标准规定的物理层和链路层协议能够满足构造最大64 Byte的消息交互能力的星载数据总线系统。但是,现有MIL-STD-1553B标准[4-5]没有规定更大数据结构的处理方法和复杂数据流控制方法来支持更高层的通信和同步服务。一般卫星的1553B总线系统[6-8],星载软件应用程序一般直接操作总线控制芯片61580,每次通信发起后,处理器都需等待,直到本次总线通信结束[9-10]。这种方式虽然解决了总线同时访问冲突问题,但是严重制约了对1553B总线的带宽利用;另一方面由于不同卫星不同长度的数据通信时间差异大,难以提供高可靠的时间服务,难以同时满足高性能和高可靠性要求[11],无法满足新一代卫星对总线带宽的需求。

本文在对传统遥感星载数据总线系统和星上通信设备的分析基础上,开发了一种基于时间同步的1553B总线通信协议。在这种基于通信帧时间同步的总线通信框架中,将一个时间同步周期划分成多个通信帧,每个通信帧占用固定时隙/带宽。在这个基础上,通过对通信帧时隙多种利用,设计了固定帧时隙、固定数据传输路径(总线控制端BC到远置终端RT或RT到BC)的无连接静态通信服务;以及基于通信双方握手,面向连接的动态通信服务。以满足1553B总线链路上层多种通信需求。在这种通信协议设计方法中,BC端软件根据时间同步信号统一根据上层应用对总线通信的需求组织1553B总线消息,并操作61580控制芯片启动总线发送,随后本进程挂起,CPU可以执行其他进程任务。当通信结束时,获得总线芯片帧结束中断信号,再启动程序完成总线芯片数据拷贝、校对处理和分发。这种协议设计,解决了多用户通信冲突问题,大幅度提高总线带宽利用率;采用时间同步的方式标准化了各种服务通信,从而能够实现0.1 ms精度的时间同步服务;使得总线通信与具体的通信数据内容无关,便于实现软件的构件化和通用化[4]。

1 时间同步总线通信协议设计

1.1 通信帧总体方案设计

通信同步服务支持总线消息时间同步以及消息序列的确定性,使得消息在总线上传送之前确定。数据总线通信发生的时间段称之为通信帧。数据总线上的每个通信帧以同步消息开始,该同步消息采用带数据字的方式命令进行同步,数据字表示传输帧序号。

BC端的宿主计算机负责准备需要传输的数据、触发序列的开始及在序列末尾(通常以中断的方式通知序列末尾)获取返回的数据或处理错误信息。BC设备根据预先编排的序列(见图1)自动执行底层的1553B总线基本消息的发送或接收操作。按照这种方式,通过在初始化时对BC端消息序列编程从而有效实现总线规划;在运行时设置并接收传输的数据从而有效管理总线规划。如此一来,每一位挂接在总线上的用户的数据吞吐量和最坏延迟都能够得到保证——而无需担心其他远程终端的正常或非正常行为。

图1 时间同步协议分层结构示例Fig.1 Muti-layer Struct of Time Synchronize Communication Protocol

1.2 无连接的数据传输设计

多路数据在单条数据总线上传输,必然导致每次数据传输都有一定的延时。根据不同的时间延迟及频率等要求,对于无连接的数据传输来说,分为预定义内容的带宽分配传输和未定义内容的带宽分配传输。本次设计中,未定义内容的带宽分配方案,主要用于协议内部的管理,不对应用程序开发。

而预定于内容的带宽分配传输方案,用于低延迟或高频率的数据传输需求,(例如关键指令分发,周期性内务数据采集):通信帧时间轴上的每个1553消息总是保留给具备给定属性(如,RT地址、最大数据长度)的既定服务。在这种方式下延迟时间是由调度策略本身决定的(见图2的例子)。

图2 同步访问示例(预分配,已占用)Fig.2 Example of synchronous bus access (pre-allocated, populated)

1.3 面向连接的握手传输设计

面向连接的数据传输,称为数据块传输服务。该服务在发送者的请求下提供传输数据块的能力,并在传输完毕后提供确认。该传输方案提供限定长度数据的同步传输,限定的长度在1 Byte到1024 Byte。在发送端数据块的长度按照1553消息的需求切成数据段,在接收端又被拼接起来。数据块传输服务不对数据结构长度超出最大数据块长度的用户数据提供封装和解封转服务。如果要处理更大的数据块,相关的服务特性将由更高层的协议层,例如包应用标准(PUS)[4]保证,利用这些高层服务的控制结构。BC根据地址进行区分,以对31个RT的数据块传输多路复用或解多路复用。

数据块传输服务在数据发送端和接收端通信链路间使用握手来进行流量控制、接收端的接收确认及防止重复传输。协议层面无流量控制,传输数据块控制域所携带的信息能够用于上层用户的流量控制机制。本服务支持以下两层服务质量:①最大效率模式,此方式传输数据,对数据不进行任何正确性检查;②长度确认模式,此方式下传输数据,接收端检查正确接收到的数据的长度。

虽然面向连接的数据块传输服务能够提供BC和RT两端的逻辑对等通信,即任意一方都可以作为通信的发起方。但是,由于1553B总线的主从结构,总线控制权在BC端。因此,在这种服务中,BC到RT方向握手连接和RT到BC方向握手连接在本协议层的处理流程是不同的,需要分开设计。

1.3.1 BC到RT方向握手连接设计

BC到RT的传输称为数据分发传输,当有BC到RT的数据传输需求时,协议要求BC端向RT端发送分发传输描述请求(Distribute Transfer Description,DTD),该请求应包含终端地址、用户数据、用户数据长度以及请求的服务质量(QoS),该请求导致BC服务提供者将数据块及分发传输描述符发送至被请求RT,发送通过将分发数据块和分发传输描述符写入子地址缓冲区实现,这些信息对于数据是可预见的。

对于RT而言,任何时刻都有可能收到新的分发数据块,RT应该在收到新的DTD(表明有新数据到来)时持续检查数据块到来。RT应在分发传输描述符所在通信帧之后的通信帧结束前处理新的命令数据块,这样的话,用于分发数据块的缓冲区可被释放用于存储下一帧中的下一个数据块。若DTD中要求的Qos为1,则还应对接收到的数据进行长度和正确性确认,并将结果通过数据分发传输确认(Distribute Transfer Conform,DTC)返回。

为了能够维护BC到各RT的数据分发信道,针对每个RT,BC端各维护一个数据分发会话(Session),并采用控制程序依据会话进行操作。为了能够有序管理数据分发信道,本文将Session分为3类状态。

(1)初始化态:系统启动,或接收到上层用户发过来的本Session会话重置指令,一律进入初始化态,根据图3描述的时序(图3中上方表示BC端程序的行为,中间表示总线实际传输行为,下方表示RT端应用程序行为,每个时刻代表一个帧同步周期,后续时序图类同,不再详细说明),BC和RT一起握手完成信道初始化,为此,将初始化态分为未初始化,初始化1、初始化2,初始化3和初始化4等子状态。

图3 BC端BC到RT方向握手协议初始化时序图Fig.3 Init sequence diagram of BC to RT hand-shake protocol on BC

(2)空闲态(Free):仅当本信道Session处于空闲态时,上层数据可以使用该信道发送数据。

(3)发送态(Sending):表示当前信道忙碌,正处于跟RT端数据发送状态。本文对BC到RT发送传输提供两种Qos服务质量,高效传输模式和可靠传输模式。前者接收端(RT)无需对接收的数据进行确认,从而能够减少握手次数提高传输效率。后者接收端(RT)需向发送端(BC)返回接收的数据确认,握手次数增加但传输可靠性高。本文对两种服务质量设计了高效传输模式(图4)或可靠传输模式(图5)两种时序,为此,将发送态再细分为发送态1、发送态2,发送态3,发送态4和发送态5等子状态。

图4 连续两次BC端BC到RT方向握手协议高效模式发送序图Fig.4 Double efficient mode sending data sequence diagram of BC to RT hand-shake protocol on BC

图5 BC端BC到RT方向握手协议可靠模式发送序图Fig.5 Reliable mode sending data sequence diagram of BC to RT hand-shake protocol on BC

由于1553B总线的主从式方式,协议握手过程由BC端应用程序控制。对于BC端RT到BC端握手协议有限状态机转换图如图6所示。

图6 BC端BC到RT方向握手协议有限状态机转换图Fig.6 FSM of BC to RT hand-shake protocol on BC

1.3.2 RT到BC方向握手连接设计

RT到BC称之为数据获取传输(Acquire Transfer),RT端的服务用户表明新数据已准备好以及开始向BC传输数据。BC端的服务用户读取该新数据到来的标识并在下一个通信帧开始从RT发送子地址缓冲区传送数据。该服务在给定时间从每个RT仅支持一次获取传输,若有多次获取传输数据需要发送,则RT应用程序应对在其内部缓冲区的获取数据块进行排序。

RT端的发送者提出获取服务请求(Acquire Transfer Requires,ATR),协议要求1553B总线控制器BC端定期(一般是1~2个协议要求的通信帧周期内)轮询所有RT的ATR。依照RT端请求的服务质量(Qos),BC端服务提供者应检查数据是否完整及正确,BC端服务提供者向RT发送者返回一个获取传输确认字(Acquire Transfer Confirm,ATC)表明数据已经传输。如果RT端的服务用户请求一个传输检查,那么该获取传输确认应表明传输是否成功,RT服务用户应用程序根据应用规范的需求决定传输一个新的数据还是重传数据。

与本文1.3.1节类似,为了能够维护各RT到BC的数据获取信道,针对每个RT,BC端各维护一个数据获取会话Session,并采用控制程序依据会话进行操作。为了能够有序管理数据获取信道,本文将数据获取Session分为3类状态。

(1)初始化态:系统启动,或接收到上层用户发过来的本Session会话重置指令,进入初始化态,BC和RT一起握手完成信道初始化,为此,将初始化态分为未初始化,初始化1、初始化2,初始化3和初始化4等子状态。

(2)空闲态:仅当本信道Session处于空闲态时,上层数据可以使用该信道发送数据。

(3)接收态:表示当前信道忙碌,正处于跟RT端数据发送状态,同样的,本文对RT到BC接收传输提供两种Qos服务质量,即高效模式和可靠模式。前者接收端(BC)无需对接收的数据进行确认,从而能够减少握手次数提高传输效率。后者接收端(BC)需向发送端(RT)返回接收的数据确认,握手次数增加但传输可靠性高。进一步的,本文对两种服务质量设计了高效传输模式和可靠传输模式两种时序,由于篇幅限制,本节不再描述数据获取初始化时序、高效模式数据获取时序和可靠模式数据获取时序,感兴趣的读者,可以根据本文的描述和图6推导出以上3种时序。为此,将接收态再细分为接收态1、接收态2,接收态3,接收态4,接收态5,接收态6,接收态7等子状态。

本文的时序设计方法,可以在维持信道通信效率的同时,减少对中断信号的使用,简化程序设计:BC端程序仅需监听帧同步信号中断和帧结束中断信号;RT端程序仅需监听帧同步中断信号。

由于1553B总线的主从式方式,协议握手过程由BC端应用程序控制。对于BC端RT到BC端握手协议有限状态机转换图如图7所示。

图7 BC端RT到BC方向握手协议有限状态机转换图Fig.7 FSM of RT to BC hand-shake protocol on BC

2 试验结果及分析

对基于时间同步的1553B总线通信协议的应用情况进行试验,并对比传统卫星总线通信的CPU占用率。选取主流航天器星载信息系统硬件运行环境,采用中央处理单元主频为10 MHz,1 Mbit带宽的MIL-STD-1553B总线,61580控制芯片。试验数据如表1所示,其对比如图8所示。。

表1 总线通信量与CPU占用率数据表Table 1 CPUconsume table of different bus traffic

图8 1553B传统总线协议和时间同步通信协议下的CPU占用率对比Fig.8 Compare of CPU consume between traditional protocol and time syn protocol

在这个硬件环境下,由图8可以看出相对传统遥感卫星总线通信协议,基于时间同步总线通信协议的总线传输对处理器机时的占用率降低了五倍左右。

事实上,基于时间同步总线通信协议,其CPU占用率主要取决于处理器对总线控制器RAM的读写速度。当处理器对总线控制器RAM的读写速度进一步提高的情况下,有效总线带宽可以不断接近理论值819.2 Kbit/s(1553B总线带宽为1 Mbit/s,但每16 bit有4 bit校验)。

3 结论与后续工作

基于时间同步的1553B总线通信协议设计,其通信量和通信方式等需求根据具体卫星任务预先规划。根据试验分析认为,相对传统卫星的1553B通信协议,主要带来以下好处。

(1)大幅度提高带宽利用率:经过测试,大约能到600 Kbit/s,相对一般卫星的150~200 Kbit/s,提高了2到3倍。

(2)多种标准化通信服务:总线通信方式和使用与具体的通信数据内容无关,通过软件的构件化设计之后,提高多个卫星任务间,总线处理代码复用程度。

(3)提高数据传输确定性:通过时间同步和总线带宽预分配的方式,让数据传输频率提高到20 Hz(相对传统卫星的最高8~10 Hz),而数据传输时间确定性到达毫秒级,(相对传统卫星精度为±20 ms级)。

目前该协议已经完成星载系统开发和测试,在高分辨率多模式成像卫星等多颗卫星中完成在轨验证,取得了良好的应用效果。后续工作建议重点关注两方面:一是该协议已经完成在轨验证,且同时在十余个航天器中开始应用,但主要集中在遥感和返回领域,将考虑推广至深空探测和载人航天领域;另一方面是由于该协议采用时间同步,划分出预分配的带宽,在此基础上,可以进一步研究整星数据流时隙分配方法,以降低整星数据传输时延,提升数据传输均匀度。

猜你喜欢
接收端通信协议时序
顾及多种弛豫模型的GNSS坐标时序分析软件GTSA
基于光载波携能的制导武器无线携能通信研究
基于扰动观察法的光通信接收端优化策略
清明
基于GEE平台与Sentinel-NDVI时序数据江汉平原种植模式提取
你不能把整个春天都搬到冬天来
手机无线充电收发设计
奖状训练器飞行管理系统研究
基于盲波束形成的MIMO雷达稳健参数估计
基于R8C的汽车OBD通用故障诊断仪设计