贵州省GNSS/MET水汽报文自动化处理系统的设计与实现
2022-07-26唐维尧白铁男谭海波金石声
唐维尧,白铁男,谭海波,金石声
(贵州省气象信息中心,贵州 贵阳 550002)
0 引言
水汽是一种温室气体,在大气中的含量较少,但却是变化最为剧烈的一种成分,极强的活跃性与天气变化甚至灾害性天气的产生、发展、演变直接相关。许剑勇等[1]提到水汽条件是影响黄山雾凇形成的关键气象因子,冉仙果等[2]发现贵州铜仁2018年12月29日的暴雪过程与水汽输送关系紧密。因此,准确测量大气中的水汽分布并掌握其时空演变规律,对于研究天气变化具有重要意义[3]。全球导航卫星系统GNSS(Global Navigation Satellite System)包括全球4大导航系统:美国GPS、俄罗斯GLONASS、中国北斗和欧盟Galileo。1992年,Bevis等[4]提出可利用GNSS信号穿过大气层时所发生的折射现象而造成的时间延迟反演大气水汽含量,从此GNSS和气象学(METeorology)建立了联系。20多年来,GNSS反演水汽逐渐业务化,中国气象局综合观测司在2020年3月发布的《气象观测技术试验指南(2020—2025)》中指出:GNSS/MET资料不仅要求观测精度要高,数据服务保障也相当重要。
Zabbix是一个企业级分布式开源监控平台。该平台能够监控众多网络参数和服务器的健康度、完整性,使用灵活的告警机制,允许用户为任何事件配置告警,这样用户可以快速响应服务器问题。白铁男等[5]利用Zabbix对贵州省的某些气象业务进行了有效监控,并得到推广应用。国内也有一些相关的研究[6-8]。
2012年贵州省气象信息中心做出了C#开发的搭载在Windows系统上的水汽中心站系统。
系统需要先通过报文同步程序同步到省级的另一台存储机上,然后再布置2台报文处理系统服务器,分别读取CIMISS-MUISC(China Integrated Meteorological Information Service System-Meteorological Unified Service Interface Community)接口气象数据和不读取接口气象数据。能读取气象数据的情况下直接发送带气象数据的报文,因为CTS(Communication Transmission Systems)核心数据收集与分发系统中会过滤重复报文,所以会优先发送带气象数据的报文。该系统长时间使用中有以下缺点:①常会因为台站发送的错误报文而崩溃;②该系统由于搭建在Windows系统中,维护较为困难;③补发过程需要手动复制报文,过程较为繁琐;④使用的物理机较多,造成资源浪费。
为解决上述问题,本研究拟采用Python语言和Shell脚本语言来开发水汽报文中心站系统,以此来处理GNSS/MET报文,并基于Zabbix-HA(high availability,高可用)搭建报文的监控与告警系统,实现GNSS/MET报文自动化处理与保障。
1 GNSS/MET水汽报文构成
《GPS/MET数据传输规范(试行)》中提到:需要对不自带气象要素观测的国家气象台站的GPS文件进行气象数据匹配工作,并按规定的格式和文件命名要求打包后向国家气象信息中心传输。即省级需要在台站传上来的原始报文中添加气象数据报文,才可作为完整的GNSS/MET水汽报文向中国气象局发送。GNSS/MET报文的详细介绍见下图:
图1中可以看出,GNSS/MET报文中有包括实时气象数据的m文件、N文件(导航文件)、O文件(观测文件)、G文件(GLONASS卫星观测文件,部分站点有),后三者都是由台站上传到省级,不做处理。
图1 GNSS/MET 水汽报文构成
目前,贵州省有1个GNSS/MET水汽资料国家级考核站:毕节威宁(站号56691),2个省级考核站:贵阳站(站号57816),安顺站(站号57806),3个不考核的站点:晴隆(站号57900)、紫云(站号57910)、赤水(站号57609)。根据最新发布的《GPS/MET数据传输规范(试行)》,每个时次都有GNSS/MET资料的观测和收发,且国家气象局对该类资料的及时率考核时间为前20 min。GNSS/MET水汽报文处理系统必须满足上述要求。
2 系统设计与实现
GNSS/MET水汽报文自动化处理系统是在Linux系统中基于Zabbix-HA(high availability)开发的,台站上传后数据共享不通过程序同步,而是直接在Linux系统上挂载Windows系统的共享盘实现同步功能,这种方式不需要登陆和认证台站共享服务器,就可以读取和复制GNSS/MET原始报文。GNSS/MET自动化处理系统处理的GNSS/MET报文将发送到核心数据收集与分发系统CTS中,之后再发送到国家气象信息中心并进行本地入库和分发。此外,该系统还包括了基于Zabbix-HA搭建的GNSS/MET报文监控与补发系统,对报文的缺收及时告警,并实现报文的自动补发。可以看出在处理流程中,最关键部分是GNSS/MET报文处理和报文监控与补发系统的建立,下面将分别介绍。
2.1 GNSS/MET水汽中心站系统
GNSS/MET水汽中心站全都布置在Linux系统中,这样便于与国省气象信息中心的核心数据收集与分发系统CTS进行交互。中心站系统的架构如图2所示:
图2 GNSS/MET报文处理流程图
从图2可以看出,中心站收发报文的过程如下:
①在中心站系统中,在配置文件中写入需要处理的台站简称和站号,系统将根据配置文件对台站报文进行逐个处理;
②通过读取贵州省气象大数据云平台“天擎”MUISC接口数据,申请中国地面分钟数据集,在匹配站点后获取每隔10 min的气压、温度、相对湿度数据,然后将气象数据插入只有文件头的文件中合成m文件,之后将m文件插入原始报文中。
③正常情况下,将处理后的报文按要求改名后再通过自动ftp传到核心数据收集与分发系统CTS,CTS再进行正常分发工作;异常情况下,若没有取到相应的原始报文或者取到的是空报,那么将对该台站不做处理,直接跳到下一个台站处理;若没有获取到气象数据即没有生成m文件,那么将对原始报文直接重新打包改名,发到CTS中进行分发;
④上述的每一个操作都将记录在结果日志中,便于日后查询。
2.2 GNSS/MET报文监控与告警系统
根据《GPS/MET数据传输规范(试行)》中对传输时效的要求,为了能及时发现台站未上传报文或上传空报文的情况,对GNSS/MET报文做出监控很有必要。因此本研究基于Zabbix-HA搭建了GNSS/MET报文监控与告警系统,并通过Zabbix的动作功能,实现报文的自动补传,大大减轻了值班人员的业务压力,实现了资料监控到自动处理的全流程(图3)。
图3 报文监控与告警系统逻辑示意图
首先需要对原始报文目录和报文发送目录进行监控,如果在报文发送目录里发现有考核站的报文缺失,将产生报文缺失的告警;如果在上述情况下,同时在原始报文目录里发现补传的原始报文,则产生水汽需要补发的告警,此告警连接了动作—重启水汽处理程序,这样就实现了报文的自动补传工作。上述操作和结果都将记录在历史记录中。
整个GNSS/MET报文自动化处理系统都搭建在Linux系统中,全是源码方式呈现,无图形化界面。通过crontab定时任务实现每个时次的第6 min对报文进行处理,从台站发送到处理过程结束一般在15 s以内。水汽报文缺失的告警分别配置在相应的主机群中,告警直接分配到台站;水汽需要补发的告警配置在报文处理系统中,不分台站,触发动作后直接重启水汽处理程序,重复的报文核心数据收集与分发系统CTS会直接过滤,不做处理。
表1 GNSS/MET报文及时率对比
3 结果与讨论
测试1个月以来,与之前1个月对比,报文及时率有着明显提升,5月15日—6月11日全省的GNSS/MET报文及时率大概在95%左右,测试的这1个月,6月12日—7月16日全省及时率均在99.5%以上。3个考核站点中威宁站是国家级考核站,可以看出新中心站系统对该站点的及时率提高更加明显,之前有2周只有约92%,中心站系统测试期间,威宁站GNSS/MET报文及时率已达到100%。
4 结论
本研究在Linux系统中基于Zabbix-HA开发了1套全新GNSS/MET水汽报文自动化处理系统,与旧版系统相比,有效提高了报文传输及时率,并节约了计算资源。此外,该系统还包括了报文的实时监控和自动补发,实现了水汽资料的全流程保障,有效减轻了工作人员的值班压力。