1553B总线应用层协议可靠性机制设计方法

章生平， 郭晶晶， 肖 轩， 康纪军

(上海卫星工程研究所 上海 200240)

引 言

MIL-STD-1553B［1］协议是20世纪70年代美空军面向总线通讯链路层制定的时分多路串行数据总线协议，由于该协议针对链路层制定了一套故障诊断机制［2］，能够很好地满足空军战斗机舱内数据通讯并且在空军应用反响良好，故后来被移植到航天器产品中，广泛应用于各类卫星、导弹。DDC公司在1553B协议上开发了一系列的集成芯片ACE［3］，封装了总线底层协议、信号驱动，并设计了一套面向应用层协议的数据和控制接口，大大降低了使用者的开发难度，使得用户界面比较友好。目前国内航天产品大量使用DDC公司的1553B总线集成芯片，其他厂商开发的芯片产品也大多兼容DDC公司的总线芯片。

1553B协议制定了一套链路层通讯故障检测机制，如检测消息格式错误、校验错误、消息间隔及响应时间等。DDC芯片对底层链路协议封装后，除了完成硬件电平信号的驱动通讯［4］，还面向应用层用户，增加了多模式配置、堆栈与消息缓存分配、消息控制配置、中断配置，并对消息故障增加了自动化的处理机制，包括故障中断、故障重试等功能，从而为用户提供了一种灵活、开放的使用接口。

鉴于航天型号高可靠的特点，在工程上必然要求总线通讯系统高可靠，除了1553B链路协议及其DDC芯片针对链路层信号的编码特性、消息时序特性采取故障与检测可靠性机制外［5］，我们还需从应用层协议出发，结合航天型号总线数据传输特点及DDC器件特性进行应用层协议的可靠性设计研究［6］，提出一种适合航天器应用特性的可靠性规则和机制，弥补仅依靠链路层协议带来的可靠性不足，真正确保应用总线数据的可靠传输和处理。

1 航天器1553B总线一般可靠性要求

图1 1553B总线架构Fig.1 1553B bus architecture

为了保证航天器产品中1553B总线通讯的可靠性，遵从时分多路、命令控制总线宗旨，总线应用传输采取静态分时的主从式总线控制方式，任何总线通讯由总线控制器BC(Bus Controller)控制器发起组织，其他RT(Remote Terminal)不能获取总线控制权［7，8］。在总线控制时序上，BC按照预定时间周期和策略进行总线通讯的查询和传输执行，不提倡总线控制时序的多进程插入、并发通讯任务，打断既有总线通讯消息次序。图1是1553B总线架构的框图。

航天器总线是面向多终端的系统，系统先在应用层面上对通讯的需求进行统计分析，把各方的信息类型归并为相似的种类。这样系统用户可以按照消息种类进行操作通讯，简化了BC控制端的实现复杂度。图2是以日常生活为例说明航天器总线通讯需求的示意图。

航天器上要求使用统一规格的芯片，尽量采购同一厂家或同一型号产品，当前要求航天器上总线芯片的链路协议遵守DDC公司的ACE规范。只有统一了器件，才能在链路协议的基础上根据型号需要制定应用层的总线协议。DDC公司的ACE芯片支持冗余总线，满足航天器数据高可靠传输的要求。航天器星内总线通讯一般选用双冗余总线架构。

图2 航天器总线通讯需求示意图Fig.2 The schematic diagram of bus communication demand in spacecrafs

2 应用层协议可靠性设计

2.1 静态周期时序控制

航天器内部总线通讯终端数量少则几个，多则数十个，这些终端来自于不同仪器，且各自的任务运行模式不尽相同，如何协调所有终端按照一种可确定、可预计的通讯时序工作，关系到总线通讯系统的稳定和安全。本文采用基于静态分时的主从式总线控制原则，即航天器主控单元BC按照总体需求确定最小工作周期，合理设置总线控制周期内的通讯内容，定时、周期性地组织总线通讯。

每个总线控制周期可以包含多种具体的总线通讯消息类型，但需按照先后次序进行静态排列分配，周期内各消息之间设置固定静态间隔从而保证消息类型的隔离［9］。对于总线通讯的静态周期时序，每一类消息的前后消息类型以及相对周期的起始时间点都是确定的，而且具有周期重复性。在航天器测试中，采取静态周期时序控制方法，对于整星总线时序测试覆盖性比较有利，而且较容易查找与复现问题，工程上也简化了总线通讯功能的需求设计和实现。图3为静态分时通讯情况下总线周期的控制流程。

周期性总线时序控制的常规实现途径是BC控制器软件根据具体周期内的通讯需求条件来确定具体的通讯种类和通讯数量。其中某些通讯的消息类型、通讯的数据量根据实时状态可能存在动态选择、动态配置的要求。这种每个周期帧内具体消息的配置还需控制软件进行参与决策。

另外一种实现途径是利用芯片特性来实现消息帧自动重复(frame auto-repeat)，这种方式的前提是每个周期的通讯消息类型、数量完全确定且相同。DDC公司的ACE芯片支持消息帧自动重复功能，一旦确定帧内消息及时序，那么总线帧启动后按照已确定的总线通讯时序和通讯内容周期性重复通讯传输。这种总线通讯方式需通过内部定时器时间触发或者外部信号的触发方式实现对ACE的一次性配置，从而保证帧周期性执行，主控软件仅参与响应帧正常结束后进行的总线数据的读写更新。软件也可以响应帧自动重复过程中异常错误状态，及时消除错误并重新启动。

图3 静态分时通讯控制流程Fig.3 Static time-division communication control process

2.2 总线BC/RT中断响应及消息隔离机制设计

航天器1553B的总线应用层协议要求各RT采用中断响应机制，及时按照预设定的通讯中断需求进行任务处理，满足通讯实时性操作要求。事实上收发双方终端的硬件和软件在处理时均需要耗时，采用中断响应机制需对消息类型的时序间隔进行设计，满足收发双方的工作时序匹配度［10，11］。为了保证各终端RT对中断的响应和处理有充足时间，总线应用协议规定针对同一个RT的两类不同消息的传输间隔或同一类消息的前后两次传输间隔应保证不小于预定时间(例如5ms)。图4举例说明了中断响应及消息间隔的设计流程。

此外，在工程实践中，某些终端由于自身的任务特性，虽然硬件上采取中断响应方式，但是在其自身的工作任务时序中，某些阶段做不到实时响应。例如对于某些载荷，因在成像期间不能被打断而需要屏蔽总线中断，相应地总线需适应该RT的最长延迟响应时间，放慢消息节拍。当个别RT终端无法实现中断实时响应时，只能采取中断接收查询访问方式。总线应用协议中规定，静态消息周期应大于该RT终端的查询访问周期，否则在一个RT查询周期内可能发生多次BC主控通讯周期，导致同类型消息发生多次通讯，如RT终端接收缓存中的数据在未被取走的情况下被覆盖，或RT终端发送缓存中的数据未更新却被重复传输。

图4 中断响应及消息隔离的设计流程Fig.4 Design process of interrupt response and message isolation

2.3 矢量建立及访问机制的可靠性设计

总线应用层协议需要规定RT传输请求机制，实现RT终端的数据传输请求及传输后处理。1553B标准协议中通过设置矢量位为“1”来表示传输请求，由BC查询后组织相应的数据传输。为了保证数据传输的可靠性，避免同时读写等访问冲突，在应用层协议中规定BC/RT的矢量握手操作流程，主要分成中断响应清除矢量握手和查询响应自动清除矢量握手这两种BC/RT矢量响应机制。图5为矢量访问状态转移图。

2.3.1 中断响应机制的矢量握手

采取中断响应机制，在时序上，主控BC访问矢量字消息后，RT终端立即响应矢量消息并清除矢量字请求信息。主控BC根据访问到的矢量字信息组织对应有需求的总线完成通讯传输。RT终端响应矢量字对应的每一类通讯传输后，再根据自己的工作时序填入更新后的传输数据，重新设置矢量请求，请求下次传输。图6为中断响应机制下的矢量握手流程。

图5 矢量访问状态转移图Fig.5 Vector access state transition diagram

图6 中断响应机制的矢量握手流程Fig.6 Interrupt response mechanism of the vector handshake process

2.3.2 查询响应机制的矢量握手

对于RT终端采取查询方式的通讯，协议上增加一种状态字服务请求操作，即矢量字的每一位数据“或”的结果作为状态字的服务请求位，表示RT终端是否存在矢量服务请求。主控BC在周期时序中先访问RT终端的服务请求，如有服务请求则读取矢量字消息，根据矢量信息中的请求位组织相关消息的传输。RT终端使用状态字服务位请求机制后，需要再配置成RT自动清除状态字服务请求位，当主控BC读取矢量字后，ACE芯片自动清除状态字中服务请求位，即以ACE芯片硬件响应措施来实现RT终端查询机制下终端快速响应握手。即使RT采用定期查询方式的总线通讯，由于状态字服务请求位被清除，主控BC不会再次取矢量字消息内容，也就不会重复传输矢量字对应的消息。需要注意的是，启用状态字服务请求功能时BC端应屏蔽状态字服务请求位的置位引起的重试操作。图7为查询响应机制的矢量握手流程。

图7 查询响应机制的矢量握手流程Fig.7 The query response mechanism of the vector handshake mechanism

在航天器工程上，还需考虑矢量握手机制本身的可靠性。当BC/RT矢量握手在实际通讯中的某个环节出现错误而导致状态条件无法循环时，矢量握手机制将处于死锁。为了解决该问题，要求RT终端在一定时间段内对矢量请求设置进行自检，若矢量请求信息被清除而数据通讯未完成执行，则重新提起矢量请求。

2.4 总线故障重试机制

MIL-STD-1553B链路层协议规定了比较完备的故障检测和诊断机制，协议架构上支持总线采用冗余总线通道以提高链路可靠性。ACE芯片向用户提供一种通讯故障重试机制，由ACE芯片自动检测通讯中的故障消息并自动重试消息通讯。用户只需要将ACE设置为重试允许，并设置重试的次数、总线选择及故障条件类型。ACE芯片协议还可以对重试动作的状态信息进行次数记录，并产生中断便于用户捕获。在制定航天器总线通讯应用层协议中需规定是否启用总线故障重试机制，明确哪些通讯类型采用重试以及重试次数和总线重试通道选择，以便于BC和RT双方理解一致。RT终端则相应配置为支持总线重试，并设置成“允许覆写无效消息”，确保重试消息通讯时缓存指针保持在当前消息存储位置。

总线重试机制依赖于ACE芯片对通讯故障的检测诊断，当消息传输类型为广播时，不能实施总线重试通讯机制。这是因为总线广播通讯方式不指定具体接收终端，不需要终端返回消息状态字，因此BC端不能通过获取状态字对通讯故障进行检测。另外，RT2RT传输类型且采用循环缓存的总线通讯也不能使用总线重试机制，这是由1553B主从式总线特性决定的。RT2RT通讯需BC参与控制，相当于RT-＞BC-＞RT的复合通讯，BC与一个RT通讯故障后发生重试，而另外一个RT状态字反馈正常，那么该RT不认为有重试消息，其循环缓存指针会继续往下走，从而导致收发的数据不一致。

2.5 总线通讯的实时性设计

ACE芯片面向用户提供一种类似实时脉冲同步信号的同步机制，只不过“脉冲信号”是1553B的“系统同步命令”消息。RT终端则需要配置成允许系统同步本地1553时间计时器，并相应地设置RT计时器分辨率。当RT终端接收到系统同步命令后，芯片硬件自动进行本地时间的同步(系统同步命令不带参数则同步计时器从0开始，系统同步命令带参数则同步计时器从接收参数开始计时)。

图8 总线通讯同步处理流程Fig.8 Synchronization process of bus communication

当总线系统需要主控BC与RT终端的时间系统进行校准维护时，可以采取系统同步方式，它能够比较精确地测量出从BC端发送系统同步命令到RT接收处理读命令之间的时间延迟，从而在RT本地时间校准时扣除这一时延量。图8为总线通讯实时性同步处理流程。

需要注意的是，利用系统同步命令的同步控制方受系统同步命令消息的自身传输时延影响，最终实际的时钟精度是有限制的，但能够满足十微秒量级的常规精度要求，若需要更精确的同步还应该设计专门的校时同步电路。

2.6 重要应用数据通讯的检错纠错设计

航天器1553B总线应用的电磁环境比较恶劣，尤其是受到空间辐射影响，导致数据通讯受干扰而发生错误和异常。目前DDC等厂家提供的ACE芯片中缓存为4K/8K×16的SRAM，这些缓存没有相关的抗单粒子翻转EDAC等措施，缓存上的消息命令和数据可能出现单粒子翻转错误。在通讯时，1553B链路层协议的固有可靠性机制无法检测出这种数据源上的错误。用户在总线应用层协议中规定各方使用的重要类型消息(注数、指令、轨道参数等)采取时序握手、信息反馈、校验判断等措施，确保重要数据在最终使用前被检查确认，而且将检查确认的结果下传地面，使得地面能够观察到重要数据在通讯链路上传输的正确性状态。本文初步制定了以下三条原则:

①周期性发送的重要数据和命令，只需检出错误并等待下次正确通讯;

②突发传输的重要数据和命令，接收方需反馈接收成功标志，若不成功则再次组织传输通讯;

③具有时序和发送时机的重要数据命令，收发双方应约定起始点，握手成功后才能继续数据命令的传输通讯。

2.7 总线定期维护可靠性设计要求

1553B总线通讯在航天器上是平台命令与数据交换的核心媒介，由于空间应用环境复杂，总线驱动芯片或者总线电缆介质都可能存在故障，而1553B总线应用数据内容可靠度要求比较高，因此我们需要对总线通讯进行定期故障检测与维护，及时发现通讯故障，采取相应的故障修复措施。根据航天器使用环境和总线芯片特点在总线应用协议上加入故障维护的可靠性设计措施，加强总线通讯可靠性。具体措施有:

①要求RT按照BC同步消息进行本地同步维护，包括缓存指针初始化、ACE配置初始化以及矢量请求设置的一致性检查确认;

②要求RT进行自主守时维护，一定期限内若无总线通讯(或其他周期性类型消息)，则自主进行本地总线ACE初始化维护(器件复位、重新配置RT参数);

③BC定期对各终端进行测试维护通讯，包括协议芯片的自测试和应用层的长抱环测试，要求RT进行应答回复，自测试结果和长抱环测试结果都下传地面;

④BC定期对各终端的收发数据通讯、测试维护通讯结果进行分析，一旦发现与外部所有RT终端通讯异常，则对BC自身ACE器件进行初始化维护(器件复位、重新配置BC状态参数)。

3 结束语

本文结合总线驱动集成芯片协议，在工程应用经验基础上，针对总线应用层协议可靠性设计提炼出一套适应航天使用的规则和措施，有助于航天器总体设计制定一个可靠的1553B总线通讯系统。总线可靠性设计思路来源有两个，一是现有总线产品要满足空间应用环境需求;二是借鉴常规数字通讯系统协议分层原理，在应用层协议中进行可靠性设计。十多颗在轨型号的使用验证表明，对总线系统应用层协议进行可靠性设计行之有效，能够减少通讯错误，及时检测和发现错误，并且解决错误恢复正常。在实际应用过程中，静态分时控制、收发握手、故障重传等可靠性机制，在保证总线通讯可靠性的同时，也在一定程度上造成了总线通讯资源的浪费，降低了总线通讯的传输效率，但由于航天器更关注产品工作可靠性，所以这些代价是值得的。

［1］MIL-STD-1553 Protocol Tutorial［S］.Condor Engineering，Inc.2004.

［2］DDCMIL-STD-1553B Designer SGuide［S］.USA，1998.

［3］DDC BU-65170/65180 and BU-61585［M］.USA，1999.

［4］DDC.Processer-to-ACE Interfaces［M］.USA，1999.

［5］DDC.MIL-STD-1553 Designer's Guide［M］.USA，2003.

［6］DDC.Underdatnding the ACE's Self Test Capabilities［M］.USA，1999.

［7］DDC.Electrical and Layout Considerations for 1553B Terminal Design［M］.USA，1999.

［8］DDC.ACE RTManagement Options［M］.USA，1999.

［9］赵昶宇，颜昌翔，于 平.1553B总线上消息的实时调度［J］.光学精密工程，2010，18(3):732～740.Zhao Changyu，Yan Changxiang，Yu Ping.Real-time Scheduling of Message on 1553B Bus［J］.Optics and Precision Engineering，2010(3):732-740.

［10］代 霜，王 槐，徐抒岩.1553B总线通讯的可靠性设计［J］.光机电信息，2010，27(9):52～58.Dai Shuang，Wang Huai，Xu Shuyan.Communication Software Reliability Design of 1553B Bus［J］.OME Information，2010，27(9):52 ～58.

［11］郭泽仁.1553B总线系统优化及可靠性设计［J］.山东理工大学学报(自然科学版)，2008，22(1):67～70.Guo Zeren.The Optimization and Reliability Design for 1553B Data Bus［J］.Journal of Shandong University of Technology(National Science Edition)，2008，22(1):67 ～70.