长期以来, 气象观测资料的实时传输与交换是通过气象报文进行的, 而气象报文编码方式主要是字符型编码。由于字符编码表示的局限性, WMO推出了基于表格驱动的BUFR编码方法, 也称之为表格驱动码。由于表格驱动码在自描述性、扩展性、灵活性等方面比字符代码存在优势, 更能满足不断增长的气象数据在种类、数量和质量方面的需求, 因此WMO要求从2005年开始逐步实现地面、探空等资料从字符编码向表格驱动码的过渡, 并要求在2015年前完成全部观测资料的代码过渡。所以表格驱动代码过渡已成为今后几年各个国家必须面对的一项重要工作, 更是中国气象部门需要十分重视的一项任务。
气象代码过渡是一项真正意义上的庞大系统工程, 其涉及面广:从全球各个国家到国内各个观测台站, 从气象观测到数据分发与应用等各个业务环节; 其工作难度大:不仅涉及到许多应用软件的开发与更新, 还涉及到硬件设备的改造与投资; 更为重要的是需要改变长时期形成的某些工作习惯与业务流程。因此气象代码的过渡也是一个较长时期的工作, 在具体实现上必须采取分步实施、逐步推进的方法, 实现从部分过渡到完全过渡的方案。
1 气象观测资料的代码表示气象观测资料需要进行全球交换, 为了全球资料格式的标准化, 也为了减轻通信线路的传输压力, 各种气象资料在传输前要按照规定格式进行编码压缩, 相反, 在业务应用中也要对相应的格式进行解码。这种为适应通信传输的气象数据编码格式即称之为气象代码。目前广泛使用的气象代码中, 对观测资料而言主要是字符代码(又称ASC Ⅱ码), 而数值产品资料已经由原来的GRID码过渡到了GRIB (GRIdded Banary)码。本文所讨论的代码过渡主要是指气象观测资料的代码过渡。
表示气象观测资料的代码除了传统的字符代码外, 另外还有BUFR码和CREX码[2]。
字符代码TAC (Traditional Alphanumeric Codes)即是我们目前气象业务中常见的ASC Ⅱ编码方式, 它是一种人工可直接识别的代码。人们所熟悉的地面(SYNOP (FM 12))、高空(TEMP (FM 35))等报文资料就是这种编码方式。下面是一份字符代码地面报文的例子。
SMCN25 CWAO 181200 RRF
AAXX 18124
71520 46////2606 11144 21165 39470 40159 51009 6///1
333 11001 21144 70000=
BUFR (Binary Universal Form for the Representation of meteorological data)码是世界气象组织(WMO)推荐并正在积极推广应用的一种代码, 它是一种与计算机硬件无关的可压缩二进制数据表示方法。BUFR码难以人工识别, 需要通过解码程序并参照相应的代码表进行解码后才能应用。
BUFR码具有很强的表示能力, 首先是其通用性强, 一套BUFR编码可以用来表示多种不同类型的天气观测资料, 包括这些资料的质量控制信息及其它附加值; 同样, 一套解码程序也可以对所有的BUFR资料进行解码; 其次, BUFR码具有很好的可扩展性, 当新增加一种观测资料时, 只要对相应的代码表进行修改, 而不需要象字符代码那样去重新设计一种代码格式; 第三, 由于BUFR码是具有可压缩性的二进制流数据, 因此可压缩存储空间, 减少数据传输量。由于这些特性, 促使WMO计划用BUFR码取代字符代码。但BUFR码的传输要求有高可靠性的通信线路支持。BUFR码数据的内部结构如表 1所示。
CREX (Character Representation form for data EXchange)码是观测资料的另一种表示方式, 它其实是BUFR码的字符编码映像, 其编码原理与BUFR码相同, 但它是将原始值进行整数化的一种字符编码, 没有进行压缩, 因此也可人工识别。这种代码可作为一种临时过渡码, 主要用于通信线路条件一时尚不具备的国家或地区。下面是CREX码报文的一个例子。
CREX ++
T000101 A000 D07999++
03 075 1 1989 01 09 09 00039 5845-00308 0030 3000 075
240 0130-105 09962 10001 05 0019 015 07 02 075 38 20
10++ 7777=
BUFR码和CERX码由于是通过若干数据表格的参照进行编/解码和数据维护的, 所以这类编码方式又叫表格驱动码TDCF (Table Driven Code Forms)。
2 气象代码过渡计划 2.1 WMO气象代码过渡计划鉴于BUFR码具有通用性强、可扩展性好和可压缩性的特点, 世界气象组织(WMO)计划在全球推行BUFR码以取代现有字符代码。该计划的主要内容是[1]:
(1) 建议在WMO的进度安排内, 各成员国自由、灵活确定其过渡时间表;
(2) 代码过渡应尽可能从数据生产者开始, 但不应被强迫使用表格驱动码(TDCF);
(3) 数据使用者应能接收、解码和使用表格驱动码(TDCF)数据;
(4) 在数据使用者不能接收或处理TDCF数据时, 应进行TDCF和TAC (字符代码)的双重分发;
(5) CREX应作为TAC向BUFR过渡的中间阶段代码;
(6) 从2005年开始, 地面、高空等主要观测资料开始表格驱动码的业务化;
(7) 2015年以前全部完成表格驱动码的业务化过渡。
WMO还建议代码过渡可分为三个阶段进行, 即:
(1) 开始实验阶段(TAC仍为业务运行, TDCFs进行实验);
(2) 开始业务化阶段(TAC和TDFCs同时业务化运行);
(3) 过渡完成阶段(TDFCs业务化运行, TAC终止传输)。
2.2 CMA气象代码过渡设想根据WMO的代码过渡计划, 中国气象局(CMA)已开始组织相关人员进行前期调研并编写代码过渡实施建议草案。建议草案的总体目标是按照WMO表驱码过渡计划的要求, 分阶段建设实施, 最终在全国范围内实现表驱码在观测资料编报、通信传输、数据存储、资料使用等各业务系统中的过渡和广泛应用。其中包括[3]:
(1) 各级气象通信系统均具备TDCF资料的传输和传输监测能力, 并支持TAC、TDCF资料的并行传输;
(2) 各级气象应用系统具备TDCF资料的处理、存储和应用能力, 并实现TAC、TDCF和国内自定义格式的并行存储;
(3) 国内测报系统实现采用BUFR编码格式进行观测资料编报和传输, 并支持TAC、TDCF和国内自定义格式资料的并行传输。
鉴于国内通信系统线路条件基本满足BUFR码传输, 因此可不考虑观测资料使用CREX编码的问题。
中国地域广阔, 气象台站众多, 通讯线路条件和基本技术环境也相差较大, 因此代码过渡必须分步实施, 基本上可以分为以下三个实施阶段。
第一阶段为国家级代码过渡阶段。该阶段的目标是率先并仅在国家中心级的国际通信系统和数据应用系统完成表驱码过渡, 这是整个表驱码过渡工作最主要、最可行和必须实现的任务, 也是我国表驱码过渡的最基本目标。
第二阶段为国内通信系统(下行)及省以下各级应用系统代码过渡。该阶段的目标是实现表驱码数据通过国内通信系统向省以下各级气象部门分发和传输监测; 实现省及以下级单位的国内通信系统对TDCF资料的本地接收和传输监测; 实现省以下各级业务部门数据应用系统对表驱码资料的处理、存储管理和应用。
第三阶段为全国测报系统和国内通信系统(上行)代码过渡。该阶段的目标是使各测报系统实现采用BUFR编码格式进行观测资料编报和传输, 并支持TAC、TDCF和国内自定义格式资料的并行传输; 省及以下数据集中单位测报收集系统实现对BUFR格式数据的收集、编辑、传输监测, 并交付本地国内通信系统; 省及以下单位国内通信系统(上行)实现BUFR资料的传输和传输监测; 国家级国内通信系统(接收)实现对上传BUFR资料的接收和传输监测并向国际通信系统转发。
各个阶段的进度计划可大致划分如图 1所示。
气象代码由字符码过渡到表格驱动码, 将会对通信传输系统、气象测报系统以及有关的应用系统产生重大影响。为适应气象代码的平稳过渡, 各个系统也将面临大量的开发与改造工作。
3.1 通信传输系统首先是北京区域通信枢纽(RTH)要具备接受、传输TDCF的条件。由以往单一的转发字符代码转变为能够对外分发(或转发) BUFR码、CREX码和GRIB资料, 特别是要对观测资料实现双重分发; 而如果要实现国内所有台站的全部代码过渡, 则国内各级通信系统也必须具备接收、传输TDCF的条件。
要实现这一目的, 现有的通信系统软件要进行改造或更换, 使之能满足不同气象代码的同时接收、转发、实时统计与业务监控, 并且实现代码之间的相互转换。
另外从硬件环境的角度看, 部分地区特别是偏远山区, 通信线路的条件以及供电系统还不能满足表驱码传输要求, 也要进行投资改造、升级换代。
3.2 气象测报系统测报系统是指气象资料的数据采集与编报系统, 目前的数据采集是由仪器自动采集与人工观测相结合的方式, 而编报软件也只能编发字符代码。按照WMO的建议, 代码过渡应从数据生产者开始, 也即是从测报系统产生的数据就是BUFR码。
由目前的测报系统向未来新的测报系统过渡必须涉及以下三个方面:
(1) 开发新的编码软件
开发基于BUFR码的编码软件, 在过渡阶段同时编发字符码报文和BUFR码报文, 以满足不同环境的应用需求, 过渡期结束后由BUFR码完全取代字符码。
(2) 设计新的编报平台
在过渡时期气象代码将实行双轨制, 编报平台的控制软件要重新设计与开发, 操作方式也将有所变化。不仅能够同时编发TAC码和BUFR码, 还应该对所编发的BUFR码进行回显和修改。
(3) 观测仪器的改造
气象代码过渡的理想目标是由仪器采集数据后直接形成BUFR码数据向外转发, 但现有的观测设备并不具备这样的功能, 因此必须逐步对已有观测仪器进行改造, 或者设计开发新一代的观测仪器和数据生成软件, 实现从数据采集到BUFR编码的完全自动化过程。
3.3 数据应用系统由字符码过渡到BUFR码, 对数据应用系统特别是日常气象业务将会产生较大影响, 因为数据格式的变化必然导致原有的数据接口程序不可用。
对于那些已经是从数据库获取资料的业务系统, 这种影响会小一些, 因为代码变化的影响可以由数据库系统的开发人员消化掉, 而不直接面向气象业务人员。
而对于那些基于气象报文开发的应用系统(包括科研业务), 代码过渡所带来的影响将会更大, 必须重新开发新的数据接口程序实现对数据格式的转换, 有些业务甚至要重新开发应用处理程序, 因为源代码可能已经丢失, 不可能在原有系统中修改数据接口程序。
4 如何避免或减轻代码过渡的影响代码过渡对气象业务的影响是必然的, 尤其是对数据应用方面的影响涉及面更广, 面临的困难更大, 这也是代码过渡中所面临的最大难题之一。就目前气象业务的现状而言, 首先要解决对气象代码的依赖性问题, 这需要对已有的业务进行清理, 对那些代码依赖性强的业务应用软件重新设计数据接口或者开发新的应用软件, 以适应未来的气象代码过渡; 更为重要的是, 要借此机遇从整体上去考虑业务系统的合理布局, 对现有系统进行改造与整合, 重新设计新的数据流程, 以使其更趋合理和更具应变能力。业务流程的设计应该从以下几个方面去考虑:
(1) 建设公用数据库或数据处理中心
公用数据库或数据处理中心对所有的气象数据进行收集和管理, 进行有关数据格式的转换工作, 并提供数据检索的通用接口, 所有使用数据的用户通过公用接口就能获取满足业务需求的数据, 而无须去关心数据格式的转换问题。
(2) 建立以数据为中心的业务流程
数据应用人员要改变已有的工作习惯, 尽可能避免每一个程序都从原始报文解读数据, 避免每一个用户各自为政去管理数据, 而是应该围绕着数据中心工作, 将所有的业务流程建立在以数据为中心的基础之上。用户从数据中心获取数据, 业务系统所形成的产品也交由数据中心进行管理并存档。
(3) 开发基于数据库的预报平台
目前各级天气预报业务平台大多使用MICAPS系统, 也有本部门自行开发的预报助手或预报辅助系统, 但其数据接口大多是基于气象报文的, 不能适应将来的气象代码变化。因此预报平台的改造与升级是一项十分重要的工作, 或者直接从数据库读取资料, 或者能够直接解读BUFR码数据。当然, 最彻底的方案是从数据库中获取资料, 这样才能从根本上消除因编码格式的变化而造成业务应用系统的不必要的修改。
5 结语中国是一个大国, 又是亚洲区域气象枢纽中心, 在全球气象代码过渡阶段不仅责任重大, 其实现难度也很大, 整个过程要花费巨大的人力和财力。因此尽快了解这一工作的重大意义和所面临的问题, 尽早做好思想准备和开展必要的前期准备工作, 是顺利进行气象代码过渡的基础。
[1] |
WMO. Play for migration to table driven code forms[R]. August 2002. Geneva.
|
[2] |
国家气象信息中心通信台. 表格驱动码编码方法[M]. 北京: 气象出版社, 2005.
|
[3] |
国家气象信息中心通信台. 中国气象局表驱码过渡计划建议书(草案)[R]. 2006.
|