一种雷达数据实时处理系统的解决方案

　　实时系统的开发过程中通常需要解决这样的问题：由于数据的处理需要大量的计算，这势必影响到系统对用户操作的响应。为了解决这一矛盾，多线程是必然的选择。实践证明，实时系统中，开辟与用户操作无关的、专门负责数据处理的线程可以解决这个问题。典型的应用有激光雷达实时处理显示系统、遥测参数的实时判读和传输监控、测震实时数据保护系统。

　　在计算机编程中，一个基本的概念就是同时对多个任务加以控制。许多程序设计问题都要求程序能够停下手头的工作，改为处理其他一些问题，再返回主进程。可以通过多种途径达到这个目的。开始的时候，那些掌握机器低级语言的程序员编写一些“中断服务例程”，主进程的暂停是通过硬件级的中断实现的。尽管这是一种有用的方法，但编出的程序很难移植，由此造成了另一类的代价高昂问题。中断对那些实时性很强的任务来说是很有必要的。但对于其他许多问题，只要求将问题划分进入独立运行的程序片断中，使整个程序能更迅速地响应用户的请求。

　　在开发多普勒天气雷达实时处理系统的过程中，如果系统并发开辟过多的产品处理线程，会造成系统本身甚至操作系统的崩溃，本文采用了并发地处理各雷达站点、串行生成各站点目标产品的折衷策略。考虑到进一步研发雷达产品的必要性以及未来增设雷达站点的可能性，系统的设计采用了一个二维的多线程控制结构。

　　1 多普勒天气雷达实时数据处理系统的设计

　　目前江苏省气象部门拥有5部多普勒天气雷达，另有2部在建，雷达监测网已经建成。如何充分利用该资源是目前气象科研工作者的一项重要工作。除了已有的雷达产品外，科研人员应用雷达基数据研究开发出多种适合于业务使用的雷达产品。目前已自行研发的雷达产品的生成算法先进、稳定、可靠，但在多算法、多数据集成工作上还略显不足，研究成果的业务化效果不够理想。天气雷达间歇性地向空中发射电磁波（称为脉冲式电磁波），它以近于直线的路径和接近光波的速度在大气中传播，在传播的路径上，若遇到了气象目标物，脉冲电磁波被气象目标物散射，其中散射返回雷达的电磁波（称为回波信号，也称为后向散射），在荧光屏上显示出气象目标的空间位置等的特征。

　　系统的硬件结构如图1所示。目前需要处理的数据来自南京、徐州、连云港、苏州与南通5个雷达站点，这些站点的数据通过网络传输到文件服务器上。在雷达探测中，气象目标的空间位置是用雷达天线至目标物的直线距离R（亦称斜距），雷达天线的仰角和方位角来表示。斜距R可根据电磁波在大气中的传播速度Ｃ和探测脉冲与回波信号之间的时间间隔来确定。电磁波在大气中传播速度是略小于它在真空中的传播速度，但对斜距影响不大。

　　系统的总体设计如图2所示。由于目标产品的生成都依赖于雷达数据的读取，需事先监控雷达数据的传输是否已经完成，雷达数据6 min到达，因此必须在6 min之内，即在下一个雷达数据到达之前将所有站点的雷达数据实时处理成多个目标产品。其中包括雨量直方图产品、CAPPI（等高平面位置显示）产品、VIL（垂直累积液态含水量）产品、TREC风场产品、OHP产品、Div产品、雨量预报产品以及与这些产品相关的图片产品。

　　由于各个产品处理线程运用自身已有的方式各取所需，因此对雷达数据的读取可以串行进行，避免了各个产品处理部分之间数据访问的冲突，同时也无需使用其他机制控制数据的访问。如何实现并行处理各雷达站点、串行生成目标产品的策略以及各产品处理线程的执行可视化等系统设计与实现的关键部分都是通过多线程控制结构来实现的。

　　2 多线程控制结构

　　阵列逻辑控制器采用阵列逻辑的方法构成组合逻辑控制电路，一种实现控制器的电路结构是可编程逻辑阵列（PLA）结构，如图3所示，其中对门电路的输入端作了简化表示[7]。阵列中每个交叉点可以像写ROM一样进行设置，这种设置的过程称为编程。

　　线程只是用于分配单个处理器的处理时间的一种工具。但假如操作系统本身支持多个处理器，那么每个线程都可分配给一个不同的处理器，真正进入“并行运算”状态。从程序设计语言的角度看，多线程操作有价值的特性之一就是程序员不必关心到底使用了多少个处理器。程序在逻辑意义上被分割为数个线程；假如机器本身安装了多个处理器，那么程序会运行得更快，毋需作出任何特殊的调校。根据前面的论述，大家可能感觉线程处理非常简单。但必须注意一个问题：共享资源！如果有多个线程同时运行，而且它们试图访问相同的资源，就会遇到一个问题。举个例子来说，两个进程不能将信息同时发送给一台打印机。为解决这个问题，对那些可共享的资源来说（比如打印机），它们在使用期间必须进入锁定状态。所以一个线程可将资源锁定，在完成了它的任务后，再解开（释放）这个锁，使其他线程可以接着使用同样的资源。

　　基于可编程逻辑阵列的启发，本文设计了一个多线程控制结构。可以将这个控制结构看作一个M行N列的二维数组，其中行定义了需要生成的M种雷达产品，列定义了需要监控的N个雷达站点。这里用Control[M][N]表示这个二维数组，Control[i][j]则代表了是否可以开始第j个雷达站点的第i个产品处理过程。需要注意的是第0行代表了雷达站点的数据是否已经传输到了服务器上，只有当第0行为true时才能开始各项目标产品的处理，否则系统中不存在任何产品处理过程。通过图4的多线程控制结构可以很容易地实现并发处理各雷达站点、串行生成目标产品的策略。系统的实际运行情况表明，不同时并发地将所有雷达站点的雷达数据处理成所有的目标产品，而是采用这种并发与串行相结合的方式，有效地控制了系统产品处理线程的数量，减轻了系统运行时对内存和CPU的需求，同时也不影响人机之间的交互。

　　通过多线程控制结构的状态可以准确得到系统在某一时刻开辟了哪些产品处理线程。如果用当前各站点正在处理的产品的索引来表示控制结构的状态，则图5中控制结构的4个状态可以编码为11111、12254、33445、56555。与可编程逻辑通过对图3中的交叉点进行编程设置一样，用户可以对控制结构中交叉点进行设置，即对多线程控制结构进行编码，控制系统生成用户所指定的目标产品。

　　3 产品处理过程

　　系统的主要处理过程包含2个定时器。

　　数据检测定时器：为各个雷达站点开辟各自相应的数据检测线程，每6 min进行数据检测。当检测到雷达站点j的数据已经传输完成，数据检测线程将Control[0][j]设置为true。

　　产品处理定时器：轮询多线程并行控制结构，以便为各个站点开辟目标产品的处理线程。如果站点j的产品i-1已经处理完成，即Control[i-1][j]为true，则说明可以开辟产品i的处理线程；否则需要等待下轮询，直到Control[i-1][j]为true时，才能开始产品i的处理。产品i处理完成之后，自动地将Control[i][j]设置为true，以表明当前产品已经处理完毕，以便进行下一个产品的处理过程。

　　Div散度产品的处理过程中需要耗费巨大的内存，不适合在多个站点之间并发处理，因此将Div散度产品视作一个关键产品，各站点之间串行生成Div散度产品，即使系统中每一时刻多只有一个这样的关键产品处理过程。由于整体上串行处理Div产品，当各个站点都要进行Div产品处理时，将会产生各个站点对Div产品的竞争。开发过程中赋予每个站点一个Div产品的处理权，并在各个站点之间传递这个处理权。

　　为了提高产品生成过程的实时性，一旦站点j完成Div产品的生成，则立刻将Div产品的处理权传递给站点j+1；通过多线程控制结构，站点j+1获知自己已经得到了Div产品的处理权，则立即开始Div产品的处理。这里存在一个潜在的问题，即一旦某个站点的数据传输因为某些原因而暂时中断或停止，则这个站点的Div产品的处理权难以自动传递给下一个站点。为此，每个站点附加了一个计数器，通过这个计数器来指定限制某个站点掌握Div产品处理权的时间。只有当前获得处理权的站点才能进行计数器的计数，一旦计数器超过了预设的上限，则强制其交出处理权。

　　假设当前系统需要将5个雷达站点的数据分别生成6个目标产品，图5所示为从数据处理过程中选取的控制结构的几个状态，其中产品6为一个关键产品。图的底部是为各站点设置的计数器的计数值，这里设置计数器的上限是400。第1个状态代表数据检测线程检测到雷达数据之后，刚刚开始进行各个雷达站点个产品的处理，此时第0个站点拥有对关键产品的处理权。由第2个状态可以看出对各站点数据的并行处理过程是不同步的。对比第3个和第4个状态图可知虽然第4个雷达站点首先将除了关键产品6之外的其他产品处理完毕，但是却不能处理产品6；第4个状态图可以解释为由于站点0的计数器在其处理产品6之前已经超过了设定的阈值，站点0被迫提早将产品6的处理权交给了站点1，因此站点1首先进行产品6的处理。由于系统中每一时刻只有一个站点拥有对关键产品的处理权，假设此时各站点的数据传输正常，且产品6的处理过程将在计数器到达阈值之前结束并传递产品6的处理权给下一个站点。

　　本文结合一个类似可编程阵列控制逻辑的多线程并行控制结构，完成了对江苏省多普勒天气雷达实时数据处理系统的设计与实现。系统在Windows下开发，目前并发处理5个站点雷达数据的时间平均只需1 min～2 min，其中包括16幅雷达产品图片。与此同时，用户可以方便地知道系统当前时刻开辟了哪些产品处理线程，同时可以方便地对各站点所需生成的产品进行控制。系统的实际运行表明，系统运用时，横向上至少可以对10个雷达站点的数据进行综合处理，与此同时纵向上仍可以扩展添加新的雷达产品。