新一代天气雷达在强对流、暴雨等突发灾害性的中小尺度天气系统监测和预警中发挥着重要的作用, 有“千里眼”之称^[1]. 随着现代气象业务和气象服务的不断深化, 雷达系统运行可靠性和稳定性的要求越来越高.

雷达系统含机内自动测试设备(Built-In Test Equipment, BITE), 但是需要近距离监测和集中控制. 业务人员通过雷达发射机机柜上的操控面板来判断发射机各组件工作情况, 通过功能键实现切换发射机的工作模式等操作^[2]. 在雷达处于无人值守的情况下, 业务人员只能从雷达自身的运行软件获得简单的报警文字提示, 很多情况下无法通过远程监控和控制来判断、处理问题, 达不到快速运维、及时保障的要求.

针对雷达监控和维护中存在的不足, 开发了一套无人值守的雷达远程监控系统, 实现运行状态远程监测和控制. 采用ZigBee通信方式实现监控组网通信, 利用语言集成查询LINQ (Language INtegrated Query)技术、Entity Framework技术、多线程技术编写数据采集处理和控制软件.

1 系统设计方案

设计一个软硬件相结合的雷达远程监控系统, 达到智能化实时监控雷达的运行状态和外部环境信息, 同时实现无人在现场即可对雷达进行类似本地控制操纵的目的. 硬件电路主要实现雷达运行状态、报警状态、内部组件和外部电源电压电流、运行环境的温湿度等物理量的采集, 以及配合软件在雷达停机状态下根据远程指令达到控制雷达的目的. 根据收到的指令汇总雷达的内部组件电压电流数据、报警状态、运行状态等原始物理量后, 按需上传给上位机(外部显示接收软件). 外部电源和环境参数数据由各传感器节点根据收到的指令独立上传给上位机.

1.1 系统框架

远程监控系统监控80路故障信号、19路电压电流信号及8路运行状态信号, 另外还有8路输出控制信号, 同时需要对外部供电电源、运行环境参数进行监控. 数据采集硬件电路的设计需要满足快速运算和大量存储的要求, 同时又要避免对雷达原有系统产生干扰. 通过定义一个通信协议将采集到的数据按照指定的通信方式发送到上位机, 上位机软件将接收到的数据解析出来后进行存储、展示, 提供故障报警、远程控制、数据查询分析等功能.

总体系统结构框图如图1所示.

1.2 系统通信方式

可选的监控组网通信主要有LAN、RS232、ZigBee等方式, 实际的硬件电路中预留了这些通信方式. 通过比较它们各自的特点, 根据各站的实际情况选择需要的通信方式, 几种可选通信方式的主要特点如表1.

在实际应用中主要采用ZigBee通信方式^[3], 不仅可以满足系统机房内的通信, 也可满足不同机房或楼层间的可靠通信. ZigBee通信优势在于: 1)可实现自行组网通信, 个别传感器出现异常不影响整个组网通信. 2)稳定性高, 在长时间的连续运行中能满足监测和控制的要求. 3)可扩展性好, 可任意增加相同通信协议的其他采集电路或传感器^[4]. 4)无线通信, 通信方式不需布线, 可有效避免布线带来的问题, 不必改变机房环境和雷达系统结构. 外部电源及温湿度数据采集硬件电路中的每一个电压电流互感器、运行环境温湿度传感器位置分布分散, 因此选择ZigBee这种无线通信方式进行组网优势明显. 宁波雷达远程监控系统采用ZigBee无线通信方式来获取雷达的运行状态, 实时掌握雷达各组件的运行情况, 以及在必要时刻通过该方式控制雷达.

2 硬件数据采集

信息采集硬件电路以单片机为核心, 由电平信号输入接口电路、电压电流信号转换电路、输出控制接口电路、以太网通信接口电路、RS485通信接口电路、RS232通信接口电路、ZigBee无线通信接口电路等电路模块组成.

2.1 数据采集电路

数据采集及运算电路是整个电路的核心部分, 由单片机及附属电路组成. 单片机采用美国德州仪器公司生产的16位单片机 MSP430F5438A. 该单片机包括3个16位定时器、一个高性能12位AD转换模块、多达4个通用串行通信接口(USCI)、一个硬件乘法器、DMA、具有报警功能的RTC 模块和多达87个I/O引脚, 具有外围接口多、程序容量大, 功能强、功耗低等特点^[5]. 其内部集成14个外部通道的12位AD 转换模块可直接用于雷达电压电流等参数的采集. 其中4路串口通信接口可与上位机通信. 其自身所带的FLASH存储器可存储标定参数及其他运行参数, 完全满足采集与运算电路要求.

为了尽量避免对雷达自身电路的影响, 采用DC-DC隔离电源电路设计, 信号采样接口进行光耦隔离, 保证在自身线路出现问题情况下不影响雷达系统正常运行, 平时电路工作中不会对雷达设备本身造成影响^[6].

2.2 通信协议

根据需要采集的物理量设计指令格式, 不同的设备地址分别对应采集和控制雷达系统运行状态, 以及采集雷达外部供电情况和环境参数, 如表2. 采集和控制雷达系统运行状态只有一个采集器, 因此指令格式中的设备地址定义为1个字节, 将0xFF地址作为广播地址. 在实际应用中, 一套雷达远程监控系统对应一部雷达, 不可能用到0xFF这个地址. 采集供电、环境参数等外部物理量的指令格式的设备地址定义为2个字节, 低字节表示传感器地址, 高字节表示节点地址.

无论是节点地址还是传感器地址, 设置范围均为0x00–0xFE, 0xFF为广播地址. 作为约定, 当指令中设备地址低字节为0xFF, 高字节非0xFF时, 则按照一定时延读取指定节点的所有传感器的数据; 当指令中设备地址低字节非0xFF, 高字节为0xFF时, 考虑到实际应用中读取所有节点某一指定传感器的数据意义不大, 则交换高低字节, 仍读取指定节点的所有传感器的数据; 当指令中设备地址低字节和高字节均为0xFF时, 则按照一定时延读取所有指定节点的所有传感器的数据; 当指令中设备地址低字节和高字节均非0xFF时, 则读取指定节点中指定传感器的数据.

3 远程监控软件

远程监控软件实现对雷达运行状态及外部供电的智能化和远程化监控, 实时掌握雷达的运行状态, 迅速采取有效的措施. 上位机的软件主要是下发采集指令采集雷达的运行状态、报警、组件供电的信息和外部供电、运行环境温湿度的信息, 并将数据进行解析、存储和实时报警. 在雷达系统异常时, 可通过软件下发控制指令进行故障信息复位等操作. 监控软件主界面如图2所示.

3.1 软件架构及流程

软件系统采用基于.Net Framework开发平台的C/S架构和Windows Forms技术进行开发, Windows Forms有很多成熟的控件, 可信手拈来, 就算需要重构也易于上手^{[7, 8]}. 以Visual Studio为开发工具, 整个软件系统包括串口通信、数据解析、数据存储、数据显示、阈值报警、远程控制、数据查询等功能模块, 监控系统的软件架构、软件流程如图3、图4所示.

3.2 串口编程

系统开发中由于一次性需要处理的数据量较大, 技术难点之一在于串口通信编程. 微软提供的.Net Framework中自带SerialPort组件, 可以直接使用, 但是该组件有一定缺点和局限性. 自带的SerialPort是窗体控件类型, 内部缺少委托和回调函数, 对多线程的支持不够友好. 另外, 默认情况下下位机发送上来的数据到达缓冲区, 可一次性读取缓冲区中的数据, 或是按照小于缓冲区大小的指定字节长度进行读取, 或是读取到NewLine标志位. 在本文的应用场景中, 有些返回数据包含大量数据信息, 需要分多次上传, 导致缓冲区一有数据就连续上传. 此时进行校验就有可能因每组数据不完整导致校验失败而直接抛弃数据, 所以需要等待数据接收完整后才能进行校验. 因此为了避免线程阻塞和数据接收未完整就校验的问题, 不直接使用开发环境工具箱中自带的SerialPort组件, 而是自行封装一个串口操作类, 包含自定义数据发送和接收处理方法、完整数据接收后委托、回调函数等.

接收数据时, 考虑到下位机响应一次命令所上传的数据量巨大, 当超过串口默认一次能容纳的数据缓冲区大小时, 需要自定义一个二级缓存, 用于读取和存放数据; 同时增加一个定时器, 用于检验在指定时间内数据是否已经全部接收完成; 在向下位机发送获取数据的指令时, 如果短时间内出现大量的请求, 应当抛出异常, 提示上一条数据尚未处理完成, 从而避免牺牲CPU性能, 导致系统卡顿.

串口编程是本系统上位机监控软件的关键, 封装的串口操作类既要完整地接收到下位机每一次发上来的数据, 又要最大化地响应上位机下发的指令, 同时做到不错过每一条请求指令. 在实际应用中, 封装好的串口类很好地达到了预期的目的, 可快速响应每一次数据采集请求, 数据接收准确可靠.

4 关键技术 4.1 Entity Framework和LINQ

数据是雷达远程监控系统的核心, 所有的监控都是针对数据的监控. 本系统的数据持久化采用SQL Server数据库和XML文件形式, 采用Entity Framework技术路线. Entity Framework利用抽象化数据结构的方式, 将每个数据库对象都转换成应用程序对象, 数据字段则转换为属性类型, 关系则转换为结合属性, 便于在开发中使用自己最为熟悉的编程语言来完成数据的访问和存储.

考虑到每个台站配置传感器数量不确定, 其中传感器表中的数据字段采用XML类型数据. XML具有很好的扩充性、弹性和易读性, 而且在数据文件存储时也采用XML文件, 可以很好地和该字段保持一致.

系统开发中充分利用了LINQ特性, 通过LINQ to Entities和LINQ to XML连接对象模型和数据模型. 充分结合LINQ中查询语法、扩展方法以及Lambda表达式实现数据的快速操作, 达到编码快速、代码可读性强、数据访问性能高、后期代码维护方便的目的^[9].

数据查询导出Excel文件版本设定为至少是2007版本以上. 2007版本以上的Excel文件采用Open Office XML文档格式存储, 可以用Zip管理工具打开, Zip包内包含一系列的XML, 因此在实际开发中同样可以采用LINQ to XML对Office文件进行操作^[10].

4.2 多线程编程

在软件多线程开发技术中, 采用了Task和委托的方式. 与Background Worker、Thread、Invoked等方式相比, Task和委托优势明显.

1) Task新增了两个异步关键词async和await, 弥补了很多早期多线程技术上的不足. 在数据接收、处理、存储等多处采用Task的方式对任务进行调度, 确保了程序每一个功能得到高效执行.

2)在跨线程和跨窗体操作的编程中, 还大量采用了委托(delegate)的方式. 通过接口、委托确保线程间和类型安全, 同时保证异步并发. 例如在串口操作类中定义了一个完整数据接收完成后的委托, 一个数据操作回调函数. 在完整数据接收完成后启动一个新线程对数据进行运算处理. 在串口初始化时就将数据处理的子线程事件绑定到串口操作类的数据接收完成的回调函数上.

3)采用SynchronizationContext为UI主线程添加同步上下文, 通过Task开启多线程同时采集不同节点数据, 在数据处理完毕后利用SynchronizationContext的Post方法将数据绑定到相关界面, 从而保证异步并发避免出现未响应的状态.

在使用多线程技术时也要注意“死锁”问题, 确保某些数据的独占访问, 注意区分什么时候用异步什么时候用同步, 避免程序运行时导致数据损坏、程序崩溃.

5 结论

通过设计软硬件结合的雷达远程监控系统, 达到了智能监控、实时预警、及时处理的目的. ZigBee的通信方式使得散落的物理量数据得到便捷有效地归集; 自行封装串口编程解决了大数据情况下线程阻塞和数据不完整接收问题; Entity Framework和LINQ技术的采用达到了数据访问性能高、后期代码维护方便的目的; 多线程开发技术确保程序的每个功能得到高效执行, 确保线程间和类型安全以及异步并发.

系统在宁波市气象雷达站得到应用, 运行期间, 曾多次通过远程监控软件及时发现雷达运行异常, 并得到及时处理. 异常情况涉及雷达设备机房环境温度过高、发射机温度过高、UPS故障、产品数据中断、通信线路故障等. 其中有一次因雷暴天气导致市电突然中断, 而柴油机发电系统的自启动控制模块因电池没电不能自启发电. 远程监控系统及时告警, 提供供电告警信息、故障原因, 问题在第一时间内得到处理. 后续将在报警呈现方式、丰富监控内容方面开展相关工作. 结合网络技术、无线通信技术增加报警的输出方式, 在短信猫或微信订阅号等方面做尝试; 增加雷达性能相关物理量的监控, 实时掌握雷达的性能动态.