基于JSON的雷达报文交换框架

【学术plus】快来试试号内搜索功能！

→输入关键词→一键检索您需要的文章。

今日荐文

今日荐文的作者为中国电子科技集团公司第38研究所方睿，陈雨薇。本篇节选自论文《基于JSON的雷达报文交换框架》，发表于《中国电子科学研究院学报》第12卷第6期。

摘 要：为简化雷达软件系统的接口设计，提出一种基于JSON的雷达报文交换框架。框架首先引入JSON对象作为交换载体，建立了消息抽象层次结构和报文交换流程，并通过两个功能类的设计实现了报文数据内容和结构描述的同时传输，使得通信双方不必受限于协议格式的约束，可以直接进行数据项级的灵活交换。应用测试结果表明，框架可以实现收发独立解耦，而且易于使用和扩展，性能满足实际工程应用需求，能够为雷达软件系统的复用开发和CBB（Common Building Blocks，共用基础模块）设计提供参考。

关键词：雷达报文交换；接口设计；JSON；解耦

引 言

随着雷达体制和功能的不断发展，其系统设计和模块划分也变得日益复杂，这使得雷达内部CSCI（Computer Software Configuration Item，计算机软件配置项）之间的接口数量和需要传递的报文种类大大增加。通常包括10个左右CSCI的雷达软件系统，其内外部报文可达几十种之多，报文在不同软硬件平台之间的传输，不仅需要满足底层通信链路的基本要求，更依赖于通信双方约定的报文协议格式。

定长协议格式是使用最为广泛的一类雷达报文格式，其报文内部的数据项数量、种类和顺序完全固定，虽然它编码解码简单，使用过程直观明了，但缺乏扩展性，无法复用，对于每种报文都需要重新定义。变长协议格式的报文除了数据项外，还包括指示项，指示项某一位的值表明了对应数据项在报文中是否存在，协议通过设定不同指示项的取值实现报文的可变性，具有一定的扩展性，但使用较为复杂，且仍然无法摆脱协议格式对通信双方的约束，灵活性受限。

针对上述情况，本文设计和实现了一种基于JSON的灵活雷达报文交换协议框架，该框架将报文抽象为消息和基本数据类型的组合，并利用JSON作为中间桥梁进行数据交互，降低通信双方的接口耦合，提升开发和联试效率。

1 JSON简介

JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，它语法简易，数据访问和结构描述方便灵活，解析速度快、开发效率高。作为数据包格式传输时，因为不需要有严格的闭合标签，JSON有效数据量与总数据包比大大提升，从而降低了同等数据流量情况下链路的传输压力，更适用于大量数据的交互。

JSON语法是JavaScript对象表示语法的子集，主要具有对象和数组两种形式。

JSON对象（object）是“键/值”对（key/value pair）的无序集合。如图1所示，一个对象以左花括号“{”开始，右花括号“}”结束，键和值之间以冒号“：”连接，“键/值”对之间以逗号“，”分隔。

图1 JSON对象格式

JSON数组（array）是值的有序集合。如图2所示，一个数组以左中括号“[”开始，右中括号“]”结束，值之间以逗号“，”分隔。

图2 JSON数组格式

JSON中键是字符串类型的，而值可以是字符串、数值、布尔值（true/false）、null、对象或者数组，这些结构支持相互嵌套，从而构成所需要的数据结构描述。

2框架设计

2.1 整体流程

依赖于协议格式的报文交换过程传输的实际上只是数据内容，发送方将数据按照协议格式进行排列打包形成报文，接收方必须依据同样的协议格式对数据进行解析，双方对数据结构的描述是通过提前约定的协议格式来实现的。

此外，雷达报文一方面来源、目的、形式各不相同，种类繁多，完全重新设计工作量大、效率低；另一方面，报文内容中存在如日期、时间、惯导信息、工作参数等很多通用数据项，具备复用的条件和可能。

综合上述分析，框架建立的报文交换流程应当不受限于预定的协议格式，且能够对不同层次的数据项进行直接操作和复用。

用JSON对象进行数据交换时，传输的报文不仅包含了数据内容（即JSON的“值”），同时也蕴含了数据结构（即JSON的“键”以及“键/值”对应关系），因此通信双方无需再受协议格式的约束，而且接收方按照需要通过“键”在JSON对象里即可索引得到对应的“值”，框架通信的灵活颗粒度直接达到数据项级别，这使得传输报文的扩展和复用变得简便可行。

图3 框架报文交换流程

如图3所示，框架交换报文的整体流程设计如下：

1) 发送方将需要输出的数据按照“键/值”对填充到JSON对象中；

2) 发送方序列化JSON对象得到字符串；

3) 字符串通过链路传输到接收方；

4) 接收方反序列化字符串得到JSON对象；

5) 接收方从JSON对象里直接提取所需要的数据项。

可以看出，不同于传统方式对整包数据的捆绑式传输，本文框架读写数据项可以不完全一致。

2.2 消息抽象

由于JSON的值支持对象类型的嵌套，这为报文交换提供了便捷，针对这一特点，框架建立如下的“消息”概念。

设K表示JSON键的集合，V表示JSON值的集合，定义消息为如下二元组（代表JSON的“键/值”对）形式：

其中v表示若干二元组的无序集合

设分别有消息m1和m2

定义m1+m2如下

即“+”运算对于集合M是封闭的，可以将一个消息嵌入到另一个消息中。

基于上述理念，不难发现：

1) 任意报文都可以抽象为消息；

2) 消息可以由子消息和基本数据项（对应char、float等基本数据类型）二元组组成；

3) 子消息也是消息，可以继续往下扩展消息层次。

通过消息的层层嵌套，框架支持对任意报文结构的描述。此外，框架既可以进行通常意义上的基本数据项读写，也可以直接进行消息级别的操作，实现了两者面向用户使用的无差别化，这使得数据项的复用变得更加便捷。

图4 框架消息示例

图4是消息的一个简单示例，其中基本数据项二元组“年”、“月”、“日”组成消息“日期”，而“日期”又可以作为子消息，和其他数据项一起构成更高层的消息。

3 框架实现

基于雷达报文交换的需求分析和框架设计理念，通过IMessageJson和IProtocol两个功能类进行具体实现。

IMessageJson类实现对消息的读写和维护等功能，如图5所示，它主要包括设置和获取二元组、设置和获取子消息、序列化和反序列化等方法，其中：

root为JSON值，用于存储消息内容；

MSG_KEY为用户自定义的有效JSON键值，用于索引消息的具体内容；

VARIANT为用于统一框架接口，保证参数形式一致性而设计的结构体，它通过一个包含诸多基本类型的联合体存储数值，其取值通过对应数据类型的强制转换实现。

图5 IMessageJson类图

IProtocol类实现建立通信和交换消息的功能，如图6所示，它主要包括初始化通信链路、创建消息、发送消息和接收消息等方法，其中：

LINK_PARAM为初始化通信链路所需的参数类型；

MSG_TYPE为用户自定义的有效消息种类类型。

图6 IProtocol类图

4 应用测试

测试以机载雷达点迹报文为例，收发双方通过UDP网络进行通信交换。点迹报文包括任务信息、惯导、日期时间、工作参数等，以及若干个点迹的侦查数据。

4.1实验1

实验1以验证框架的功能为目的。接收方认为点迹侦查数据为点迹在机体极坐标系下的位置坐标，即距离（R/ m）、方位（A/ °）和俯仰（E/ °），并按此解析数据。发送方模拟三种不同体制雷达侦查的点迹数据结构：(1)与接收方完全一致；(2)增加径向速度数据项；(3)剔除俯仰数据项。

接收结果如表1所示，其中N/A表示未读取到有效数据。在情形(1)和(2)中，发送的信息量涵盖接收所需要的信息量，报文交换正常，情形(3)中虽然缺少俯仰信息，但传输过去的距离和方位信息仍然能够被正常解析和使用。

对于情形(2)和(3)，在依赖于协议的传统报文交换框架中，接收方进行数据包结构解析时即会报错，交换过程直接失败，整包数据被丢弃，其包含的信息无法得到任何使用。

4.2实验2

实验2以测试框架的性能为目的。

由于框架在交换数据内容的同时还携带了对数据结构的描述，所以需要额外传输一部分信息。对最终传输的字符串大小与真正数据内容部分的比值p，以及报文发送（包括序列化和传输）所消耗的时间t进行统计。

图7 p和t随点迹数量n的变化关系

实验结果如图7所示，其中n为点迹个数，黑色实线为p，红色虚线为t。可以看出，随着点迹数量的增加，p大约收敛于1.7，这表明框架仅额外花费了70%的数据量；t与点迹数量基本呈线性关系，对于500点以内的报文，发送时间约在十几毫秒以内，满足实际项目应用中几十至上百毫秒的时间需求。

作为同样使用结构化方法来标记数据的XML，由于闭合标签的存在，其p超过2.6，传输存在更多冗余数据，加之基于语法的数据解析过程，其t也在几百毫秒以上，相较而言本文采用JSON的框架性能更为优异。

5 结 语

本文基于JSON提出了一种雷达报文交换协议框架，该框架实现了数据项级的灵活传输，易于使用和扩展。应用结果表明，该框架能够消除协议格式对通信双方的完全一致性约束，降低接收和发送的接口耦合，实现收发的相互独立和数据的“即用即取”，性能满足实际应用需求，有助于雷达软件系统的复用开发和CBB设计。

（参考文献略）