[发明专利]一种模块化数据流驱动中多种通信模式的实现方法

说明书

技术领域

本发明属于雷达软件化模块化信号处理领域。

背景技术

传统上，雷达信号处理领域的开发专业性强，通用性差，周期长。模块化的开发思想促使对信号处理流程进行模块化的划分，以得到相对独立的功能模块。在此基础上，进一步实现整个信号处理流程图形化的开发，即通过简单的拖拉模块和连线来搭建信号处理流程，这样就能实现模块的重用，即模块的功能代码只需要开发一次，从而彻底将软件开发人员从繁重的代码编写任务中解放出来。

雷达信号处理具有数据流驱动的特点，即每次处理单个脉冲或单个相参处理间隔(CPI)的数据，脉冲数据或CPI数据以一定的时间间隔输入。这要求信号处理流图中每个模块基本采用“接收上一个模块数据—处理数据—发送数据给下一个模块”的执行逻辑。但是一方面由于雷达信号处理流程的复杂性，用模块与连线搭建好的流图中如果每个模块都按照基本逻辑执行，会导致流图卡住不运行。另一方面，雷达信号处理流程经常需要几个模块共同配合完成特定的数据流动，本发明称之为通信模式。

消息传递接口(MPI)提供了很多基本的通信功能，比如模块收发数据可以使用MPI的接收与发送函数实现。本发明就是要利用MPI的基本通信功能设计实现多种复杂的通信模式。

发明内容

本发明利用MPI的基本通信功能设计实现了雷达模块化信号处理领域的四种常见通信模式，支撑了雷达通用化软件化集成开发工具的实现。本发明的特征在于，基于跨平台应用的消息传递接口，也即多路径接口MPI通信的雷达信号处理系统中依次按以下步骤实现的：

步骤(1)，系统初始化，设有：

选择性发送模块，执行配置有设定标识的选择性发送通信模式，

选择性接收模块，执行配置有设定标识的选择性接收通信模式，

反馈式模块，执行配置有设定的共同标识的下述三种反馈通信模式：

第一种反馈通信模式：第一次从非反馈端口接收数据，以后只从反馈端口接收数据，

第二种反馈通信模式：第一次从非反馈端口接收数据，第二次从反馈端口接收数据，第三次再从非反馈端口接收数据，以后交替进行，

第三种反馈通信模式：第一次从非反馈端口接收数据，以后从所述非反馈端口和反馈端口同时接收数据，

滑窗积累模块，执行配置有设定标识的滑窗积累通信模式，

节拍接收模块，设有两个输入端口，按照设定的节拍有规律地接收数据，执行配置有设定标识的节拍接收通信模式，

通信模式识别模块，按照接收的通信模式识别标识，启动相应的通信模块去执行所标识的通信模式；

步骤(2)，系统依次按以下步骤执行雷达信号处理流程，

步骤(2.1)，根据识别标识判断通信模式：

若：为选择性发送通信模式，执行步骤(2.2.1)，

若：为选择性接收通信模式，执行步骤(2.2.2)，

若：为反馈通信模式，执行步骤(2.2.3)，

若：为滑窗积累通信模式，执行步骤(2.2.4)，

若：为节拍接收通信模式，执行步骤(2.2.5)，

步骤(2.2)，按照识别标识选择性地执行下述各种通信模式中的一种通信模式：

步骤(2.2.1)，实现步骤如下：

步骤(2.2.1.1)，接收进程初始化，

步骤(2.2.1.2)，启动接收进程，并等待数据接收完成，

步骤(2.2.1.3)，处理数据，并按支路编号判断所需选择发送的支路，

步骤(2.2.1.4)，使用C语言的switch()语句，按所述支路编号启动该支路的MPI同步发送功能，

步骤(2.2.1.5)，返回步骤(2.2.1.2)；

步骤(2.2.2)，实现步骤如下：

步骤(2.2.2.1)，接收进程全部初始化，

步骤(2.2.2.2)，启动全部接收进程，通过waitany()等待任何一条支路接收完成，再关闭接收进程，

步骤(2.2.2.3)，处理并发送数据，

步骤(2.2.2.4)，启动被关闭的接收进程，再通过所述waitany()等待某一条支路接收完成，返回步骤(2.2.2.3)；

步骤(2.2.3)，实现步骤如下：

步骤(2.2.3.1)，识别反馈通信模式标识中的子标识，判别属于第n种反馈模式，n值从{1,2,3}中选取：

若：为第一种反馈模式，n=1，执行步骤步骤(2.2.3.2.1)，

若：为第二种反馈模式，n=2，执行步骤步骤(2.2.3.2.2)，