应用扩展帧的航天器CAN总线应用层协议设计

闫国瑞 苏晨光 林博轩 史简 田帅虎 李军予

(航天东方红卫星有限公司，北京 100094)

现代航天器信息传输多采用总线技术，如1553B总线[1-3]、Spacewire总线[4-5]和CAN总线[6-7]等。CAN总线因具有突出的实时性、灵活性、低成本，在航天领域的应用也越来越广泛。采用CAN总线通信网络可将多台计算机连接起来，形成星上统一信息网络，负责完成航天器的综合信息处理工作。CAN总线包括物理层、数据链路层和应用层3层协议。国际标准化组织(ISO)的ISO 11898[8-9]中只包含了物理层和数据链路层的协议，没有规定应用层协议。针对航天领域CAN总线应用层协议，欧洲航天标准化合作组织(ECSS)的航天CAN总线扩展协议[10]推荐应用层采用CANopen协议，但该协议不支持复杂星载组播信息流设计，且应用复杂，英国萨瑞卫星技术公司也认为CANopen协议栈占用资源较多，不适合其星载通信模式[11]。

国内航天领域，根据国内航天器信息架构及信息流需求，提出了CAN总线应用协议[6-7]。文献[6]中提出的CAN总线应用层协议，在小卫星领域得到了广泛应用。该协议主要针对主从通信方式设计，仲裁场中的站地址规定为：主节点发送数据时，表示目的节点地址；从节点向主节点发送数据时，表示源节点地址，从节点向从节点发送数据时，表示目的节点地址；主节点或从节点发送广播数据时，表示目的节点地址。由于该协议数据帧中没有设计源节点地址，源节点自主发送数据时，接收节点不能有效判别该数据帧来源，导致该协议不支持多主通信方式。随着航天器信息融合和信息综合利用需求的提升，航天器上设备间实时数据交互量和数据交叉应用需求也在不断提升[7]，例如在实际应用中，针对有效载荷实时获取连续姿态数据及全球导航卫星系统(GNSS)定位数据的需求，若采用主从方式，因主节点无法获知姿态数据和GNSS定位数据的更新时刻，不能保证数据及时发送及连续性，导致该协议不能有效支持相关需求。文献[7]中提出了支持多主的协议，但该协议不支持多优先级仲裁，例如不支持遥测、遥控数据优先级仲裁，不支持上述姿态、GNSS定位等数据的优先级仲裁，导致该协议虽然设计了多主，但在工程应用中具有局限性。此外，该协议支持节点和组播数量有限，仅支持5个组播地址，不适应复杂的航天器信息流设计。文献[6-7]的协议均存在下述问题，即：①针对复杂航天器的信息流需求，通过CAN总线屏蔽码已经不能自动过滤非相关信息，需要上层软件编写特殊代码进行数据过滤，造成应用复杂且占用上层软件机时。②仅支持自定义信息数据包传输，且信息数据包传输长度有限(须小于256 byte)，不支持CCSDS空间包[12-13]等数据包的直接传输，不利于信息传输的标准化。③多帧数据的结束帧需要上层软件根据数据包长度进行识别，增加了应用复杂度。

本文提出航天器CAN总线应用层协议，对CAN总线扩展帧29 bit标志符进行了合理划分，以及对数据场的信息数据包传输进行了设计，形成了一套完整的CAN总线应用层协议，解决了上述问题。该协议可支持多优先级、主从、多主、组播、广播等多种通信方式，支持航天器复杂信息流设计，相对传统协议具有功能完善、适用范围广、灵活性高等优点。

1 CAN总线扩展帧结构

CAN总线扩展帧结构见图1，由帧起始(SOF)、仲裁场、控制场、数据场、循环冗余校验场(CRC)、应答场(ACK)、帧结束(EOF)共7个不同的位场组成。

注：N为字节数；ID为标志符；DLC为数据帧长度。

对于扩展帧，替代远程请求(SRR)以及扩展标志符(IDE)均为隐性，远程发送请求(RTR)用于区分数据帧和远程帧，RB1～RB0为保留。上述帧结构中，仲裁场中的标志符、控制场中的数据长度码及数据场应用软件可以进行访问，CRC等其余部分由CAN总线专用芯片生成。航天器CAN总线应用层协议的设计，基于航天数据交互需求，进行协议要素设计，然后对标志符、数据场进行划分与定义，形成适合航天器的通信机制。

2 应用层协议设计

针对文献[6-7]中CAN总线协议存在的不足，以及航天器数据实时交互等信息融合和信息综合应用的需求，本文对CAN总线扩展帧29 bit标志符进行合理划分，设计了一套完整的CAN总线应用层协议。与文献[6-7]的协议要素比对，如表1所示。文献[6]的协议要素包括优先级、站地址、帧类型，该协议主要针对主从通信方式设计，不支持多主通信，在主从通信时因所有数据均按固定时序进行轮询，无数据抢权发生，通常优先级是非必要的；而文献[7]的协议要素包括源节点地址、目的节点地址、帧类型，该协议引入源节点地址的目的是支持多主通信，在多主通信中不同类型的数据进行优先级仲裁通常是所需的，但该协议未设置优先级，导致不支持不同类型的数据进行优先级仲裁。本文协议引入数据优先级标志、源节点地址、目的节点地址，以支持航天器不同类型数据的多优先级、多主通信需求。

表1 协议要素比对

文献[6-7]的协议均设置了帧类型，用来区分单帧数据及多帧数据，但无法识别多帧数据的结束帧，需要上层软件根据数据包长度进行计算识别，或设计特殊帧以表示数据发送结束，增加了应用复杂度。本文协议引入帧序号标志，结合帧序号及数据场中的长度、校验等信息定义，支持CCSDS空间包及其他格式数据包的可靠传输。

本文协议特别引入了组播标志，基于组播标志给出了组播、广播地址分配及屏蔽策略，以满足航天器日益复杂的信息交互需求。点对点通信与组播通信分离设计，能够规避传统CAN应用协议[6-7]信息流设计需要对节点地址、组播地址、验收码、屏蔽码进行不断试探及验证以满足复杂航天器信息交互的需求，以及组播地址不足的问题，简化了航天器信息流设计，并能够通过屏蔽字直接屏蔽不相关信息数据包,降低上层应用软件的复杂度，节省机时。

2.1 标志符典型分配与设计

扩展帧标志符由29 bit的ID28～ID0[8]组成，本文提出的应用层协议标志符典型分配如图2所示，包括数据优先级、源节点地址、组播标志、目的节点地址、帧序号标志、帧序号、帧数据类型。

字节0字节1字节2字节3高5bitID28～ID27ID26～ID21ID20～ID19ID18～ID13ID12～ID11ID10～ID5ID4～ID02bit6bit2bit6bit2bit7bit5bit数据优先级源节点地址组播标志目的节点地址帧序号标志帧序号帧数据类型

(1)数据优先级由ID28～ID27组成，和节点地址一起决定了数据总线仲裁的优先级，根据实时性要求，不同数据包选择不同的优先级，数值越小，优先级越高。在实际应用中，GNSS对时广播可以设置成高优先级，遥控设置成次高优先级，遥测设置成低优先级。

(2)源节点地址由ID26～ID21组成，表示发起数据传输的节点地址，最大支持64个节点。

(3)组播标志由ID20～ID19组成，用于数据广播或组播设计。

(4)目的节点地址由ID18～ID13组成，表示发送目标节点的地址。

(5)帧序号标志为ID12～ID11，用来标志该帧中的用户数据属于信息数据包中的哪一部分，该标志含义如表2所示。

表2 帧序号标志定义

(6)帧序号由ID10～ID5组成，范围0～63，表示数据帧的序号，用于多帧数据的帧连续性判断，可循环计数。当帧序号标志为11b时，帧序号应为0，代表单帧数据。

(7)帧数据类型即功能码，由ID4～ID0组成，表示CAN帧的数据类型，如轮询控制序列、应答控制序列、数据应答、遥控数据等，功能码的定义有利于协议的标准化，定义如表3所示。

表3 帧数据类型定义

2.2 数据场设计

数据场字节编号从0开始，其设计如下。①对于单帧数据，数据场信息数据包数据和单字节校验码。②对于多帧数据起始帧，Byte0～Byte1为信息数据包的长度(即不包含校验字节)，其他为信息数据包数据。③对于多帧数据的中间帧，均为信息数据包数据。④对于多帧数据的结束帧，内容为信息数据包数据和校验码。

信息数据包可以是CCSDS空间包，也可以是其他格式或自定义包格式，用包版本号进行区分。以数据场最多包含8 byte为例，多帧数据的起始帧、中间帧、结束帧分别如图3～5所示。

组成数据位序76543210帧信息1RTR为000DLC为8标志符数据优先级ID28～ID27源节点地址ID26～ID21组播标志ID20～ID19目的节点地址ID18～ID13帧序号标志ID12～ID11为01b帧序号ID10～ID5为0帧数据类型ID4～ID0000数据场信息数据包数据长度L的高8bit信息数据包数据长度L的低8bit信息数据包数据Byte0信息数据包数据Byte1信息数据包数据Byte2信息数据包数据Byte3信息数据包数据Byte4信息数据包数据Byte5

2.3 利用组播标志进行信息流设计

传统CAN应用协议[6-7]信息流设计需要对节点地址、组播地址、验收码、屏蔽码进行试探及验证，以满足复杂航天器的信息流需求，当滤波设计不能有效过滤时，还需要上层应用软件进行特殊处理。本文设计组播标志用于数据广播或组播等信息流，表4给出了组播标志(Gid)、组播地址(Gaddr)、目的节点地址验收码、屏蔽码等设置说明，通过组播标志能够适应航天器复杂信息交互需求，并简化航天器信息流设计。

组成数据位序76543210帧信息1RTR为000DLC为8标志符数据优先级ID28～ID27源节点地址ID26～ID21组播标志ID20～ID19目的节点地址ID18～ID13帧序号标志ID12～ID11为00b帧序号ID10～ID5为1,2,3,…帧数据类型ID4～ID0000数据场信息数据包数据Bytem信息数据包数据Bytem+1信息数据包数据Bytem+2信息数据包数据Bytem+3信息数据包数据Bytem+4信息数据包数据Bytem+3信息数据包数据Bytem+6信息数据包数据Bytem+7

组成数据位序76543210帧信息1RTR为000DLC不大于8标志符数据优先级ID28～ID27源节点地址ID26～ID21组播标志ID20～ID19目的节点地址ID18～ID13帧序号标志ID12～ID11为10b帧序号ID10～ID5帧数据类型ID4～ID0000数据场信息数据包数据ByteL-6信息数据包数据ByteL-5信息数据包数据ByteL-4信息数据包数据ByteL-3信息数据包数据ByteL-2信息数据包数据ByteL-1校验字节

2.3.1 组播地址设计

如表4所示，通过组播标志可以将组播分为3类，每类可以进一步设计多个组播地址，因此本文协议支持复杂信息流需求。其中：0x7F和0xBF为典型的组播地址；0xFF一般用作广播地址。表4所列地址可以满足一般信息流设计的通用需求，此外，每类的组播地址可按式(1)或式(2)进一步分组。其中：x,y为集合约束变量；M,N∈{0,1,2,3,4,5}，分别为第M个和第N个比特；“≪”代表按位左移，“|”代表位或，“∧”代表位异或。式(1)可用于接收广播节点的分组组播地址设置；式(2)用于不接收广播节点的分组组播地址设置。

{Gaddr，MN(x,y)=(Gid≪6)|[0x3F∧((x≪M)|(y≪N))]：x,y∈{0,1}}

(1)

{Gaddr，MN(x,y)=(Gid≪6)|[(x≪M)|(y≪N)]：x,y∈{0,1}}

(2)

根据分组组内的数量需求，式(1)和式(2)可以设置多于或者少于2 bit，在2 bit情况下，对于x,y∈{0,1}，每组可以包含4个子地址，即{Gaddr，MN(0,0),Gaddr，MN(0,1),Gaddr，MN(1,0),Gaddr，MN(1,1)}。

2.3.2 验收码和屏蔽码设计

验收码和屏蔽码的设置方式有多种，可按照表4方式设计，以将第M个比特和第N个比特设计为1组为例，设置为Gaddr，MN(0,0)和(1≪M)|(1≪N)，其中，Gaddr，MN按照式(1)或式(2)计算。设置时也可使用更通用的过滤方式，即直接按组播分类进行验收码和屏蔽码设计，方法如下。①接收单类组播验收码可设置为(Gid≪6)，屏蔽码设置为0x3F。②同时接收组播1类和组播3类验收码可设置为0xC0(11b≪6)，屏蔽码设置为0xBF。③同时接收组播2类和组播3类验收码可设置为0xC0(11b≪6)，屏蔽码设置为0x7F。

表4 组播标志应用说明

3 验证与分析

3.1 信息数据包传输应用

本文协议支持CCSDS空间包[13]、CCSDS封装包[14]等信息数据包传输，可通过版本号识别信息数据包的数据结构，信息数据包数据首字节Byte0的b7～b5用于版本号定义，如表5所示。其中：版本号“000”为CCSDS空间包，空间包主导头为6 byte(含版本号)，空间包可用于组播数据、遥测数据和遥控数据传输。版本号“111”为CCSDS封装包，封装包包头长度1～8 byte可选(含版本号)，对于实时性较高的CAN总线单帧数据，如4 byte间接指令，采用包头长度为2 byte的CCSDS封装包。

表5 信息数据包数据结构

3.2 信息流需求满足验证

图6给出了航天器CAN总线的典型节点及其信息流需求，主要需求说明如下。①时间数据由星务中心计算机或GNSS接收机发出，高精度温控单元、姿态控制计算机、有效载荷1等设备接收时间数据，优先级最高。②GNSS定位数据由GNSS接收机发出，姿态控制计算机、有效载荷1、有效载荷2接收该组播，有数据连续性及实时性需求。③姿态数据由姿态控制计算机发出，有效载荷1及有效载荷2接收该组播，有数据连续性及实时性需求。④控制数据由姿态控制计算机发出，有效载荷2接收该组播，优先级高于GNSS定位数据和姿态数据。

图6 信息流示意

上述4种数据的组播接收及数据优先级说明，如表6所示。根据本文协议GNSS定位数据和姿态数据可设计为组播3类，GNSS定位数据地址可设计为0xCF，记为组播3A，姿态数据地址可设计为0xDF，记为组播3B；控制数据设计为组播2类，地址为0xBF，记为组播2A；时间数据设计为组播1类，地址为0x7F，记为组播1A。因实时性要求，通信方式设计为有限多主通信，4种数据均设计为自主发送，其他的下行遥测数据等采用主从通信。

表6 组播接收及数据优先级说明

组播的滤波方式可按第2.3.2节通用方式滤波，姿态控制计算机、有效载荷1同时接收组播1类和组播3类，目的接收地址验收码可设置为0xC0，屏蔽码设置为0xBF；有效载荷2同时接收组播2类和组播3类，目的接收地址验收码可设置为0xC0，屏蔽码设置为0x7F，配电器等无组播需求的节点采用单滤波方式实现点对点通信。具体设置如表7所示，其中：ACR0/AMR0和ACR2/AMR2分别为滤波器1和滤波器2对源节点地址的验收码和屏蔽码；ACR1/AMR1和ACR3/AMR3分别为滤波器1和滤波器2对目的节点地址的验收码和屏蔽码。

表7 滤波设计示例

可见，本文协议通过组播标志能简化航天器信息流设计，能够通过滤波设计为接收节点有效过滤不相关信息，协议支持多优先级、多主通信，可以满足航天器信息流实时交互需求。

3.3 性能比对及适应性分析

对上述信息流设计，针对文献[6-7]及本文提出的CAN总线应用层协议的时延及适应性进行分析。其中：时间数据8 byte；GNSS定位数据63 byte；姿态数据56 byte；控制数据14 byte。CAN总线码速率为500 kbit/s，CAN总线多帧数据帧尾至帧头的间隔设为0.2 ms。时间数据传输时间约为0.26 ms，GNSS定位数据传输时间约为4.4 ms，姿态数据传输时间约为3.9 ms，控制数据传输时间约为1.2 ms，遥控指令传输时间约为0.26 ms，遥测数据包为205 byte，传输时间约为12.1 ms。

因文献[6]不支持多主，上述所有数据均按照设定好的固定时序进行轮询，星务中心计算机作为主节点，并不知道从节点控制数据、GNSS定位数据、姿态数据的更新时刻，星务中心计算机按照其运行周期1 s查询从节点的上述数据是否更新，因此最大时延为运行周期1 s加上传输时间，并且由于主节点和从节点晶振非同源，不能保证上述数据输出的连续性。

因文献[7]不支持多优先级，按照其协议设计，GNSS定位数据会因遥测数据包、遥控指令的正在传输造成阻塞；时间数据会因遥测数据、遥控指令的正在传输造成阻塞；控制数据、姿态数据会因遥测数据、GNSS定位数据、时间数据、遥控指令的正在传输造成阻塞，并且上述时延会因遥测数据包的长度变化导致时延不同，数据自主发送的过程中不支持遥控指令的优先执行。

本文协议根据应用需求，设时间数据优先级最高，遥控指令、控制数据优先级次高，姿态数据及GNSS定位数据为较低优先级，遥测数据优先级最低。

各种数据最大时延分析如表8所示。结果表明：本文协议数据时延均明显优于其他协议，并支持遥控指令插入。

表8 时延及适应情况分析

本文协议与文献[6-7]的协议适应性比对，如表9所示。本文典型分配能够覆盖现有航天器信息流设计需求，并留有扩展空间，有助于形成统一的航天器CAN总线协议。

表9 协议适应性比对

4 结束语

本文定义了一套完整的CAN总线应用层协议及通信机制，克服了现有协议的不足。协议设置了优先级、源地址、目的地址等字段，支持多优先级、主从、多主等灵活通信方式；设置了组播标志，给出了组播、广播地址分配及屏蔽策略，可根据信息流需求简便的设置组播、广播，简化信息流设计；设置了帧序号标志、帧序号和数据场中的长度、校验等信息定义，支持多帧数据的起始帧、结束帧和中间帧的连续性判断，支持应用层数据包检验，支持CCSDS空间包及其他格式数据包可靠传输；设置了帧数据类型，定义了常用功能代码，给用户使用带来方便。本文协议具有功能完善、适用范围广、灵活性高等优点，可进行推广形成统一的航天器CAN总线协议。