区域自动气象观测站软件设计的研究

吴频频，李长明

(1.洛阳职业技术学院 信息技术与城建学院，河南 洛阳 471000；2.凯迈(洛阳)环测有限公司，河南 洛阳 471000)

0 引言

近年来农业小气候站、公路交通气象站、能见度观测站、大气电场监测站等区域性自动观测站被越来越多的建设和投用，这极大地促进了局地气象观测业务的发展和利用，由此衍生出更加丰富的专业气象服务[1]。区别于组成国家天气监测网的基准站、基本站、一般站，针对这些不同类型的新型自动气象观测站，气象行业并没有统一的设计及开发规范。这些新型自动站大多根据市场需要，灵活配置传感器，配套开发不同功能的应用软件[2-5]。由于软件设计目标不统一，就造成实现功能的千差万别，数据结构的迥异，不同类型的自动站数据无法融合利用，甚至同一厂家的不同类型设备间的数据结构也不相同，无法实现观测资源的整合利用。

随着各类区域气象观测业务的发展，业务部门对软件的需求也不再仅仅是要求能够看到实时数据[6-7]，而是希望能与现有观测业务软件融合，上传至国家数据中心，分享给其他政府部门。这就要求这些应用软件具备更高的集成能力，更强的数据交换功能，更规范的软件架构。

采用软件设计模式，可以共享过去成功的经验，降低解决问题的复杂度，提高软件设计的模块化水平[8-11]。着眼于区域自动气象站的基本业务建设过程中的问题，综合分析业务需求，结合软件设计模式和开发技术，研究了一套规范的通用的应用软件架构。

1 应用软件的基本需求

应用软件具有自动组网和监控管理的功能，主要功能[12-14]要求如下：

1)设置及查询设备的基础信息，如设备编号、通讯参数等。

2)设置资料传输模式，上传间隔和时钟校准。

3)设置观测要素开关，设置遗漏资料补传。

4)接收观测数据，对数据解析和处理。

5)报警功能，如观测数据异常、传感器故障，通讯故障等。

6)数据显示功能，如实时数据、异常状态报警等。

7)数据存储，数据交换。

8)统计分析功能。

2 应用软件的架构设计

软件架构也称为软件体系结构，是一系列相关的抽象模式，用于指导软件系统各个方面的设计[15-17]。首先，可将软件在功能上分层，各层在逻辑上可以保持相对独立，使得整个系统逻辑更加清晰，能提高系统和软件的可维护性和可扩展性。其次，在各层中遵循软件设计的基本原则即信息隐蔽性和模块独立性，设计出独立性比较强的高内聚低耦合的模块。最后，通过使用设计模式，在模块中进行逻辑设计和编码实现。设计模式包括创建型模式、结构型模式和行为型模式三大类几十种模式，常用的模式有模板方法、抽象工厂方法、策略、装饰者、观察者、访问者和组合等模式[11]。抽象工厂模式，是一种面向对象的设计模式，指提供一个创建一系列相关或相互依赖对象的接口，而无需在编码阶段指定具体实现它们的类[18-20]。

本文即以分层及模块化思想为指导，采用抽象工厂设计模式，利用插件控制器等方法实现通用区域自动气象观测站系统的设计和实践应用。按照分层思想，从低往高将软件功能分为基础服务层、业务服务层、用户界面层等3个层次。按照模块化思想，在各个层次中将功能分成功能独立的模块。其中，基础服务层包括设备交互、质控警示、统一存储等3个模块；业务服务层包括统计分析、系统监控、数据交换等3个模块；用户界面层包括统一API、显示发布、文档知识等3个模块。如图1软件整体架构图所示。

图1 软件整体架构图

图1中的层次划分充分考虑了区域站的观测业务需要。基础服务层主要面向观测设备和主程序，是连接设备和主程序的纽带。通过该层主程序可以控制设备，与之交互，接收设备上传的数据。然后对数据进行分析和质控处理，对异常进行警示，然后提供统一的存储方式进行存放。可以看出基础层虽然仅仅实现了设备的交互和数据的处理与存储，但这是整个系统的基础部分，而对数据的进一步加工处理就由业务服务层实现。业务服务层主要完成三个工作：一是对数据加工形成统计分析报表；二是对异常数据及系统异常进行监控；三是将加工后的观测数据及系统异常对第三方进行交换分享。业务服务层立足业务需求，同时起到承上启下的作用，为用户界面层提供数据。用户界面层首先通过统一接口服务(API)，可以为不同的应用类型提供数据支持。如可以是窗口桌面程序(Windows)，也可以是网站应用(WebSite)，还可以是移动应用(APP)，不管哪种应用都可以通过该API进行数据的显示和发布。其次，可以将观测业务常用的小工具、小常识、经验总结等知识，文档化，格式化存储和展示给用户查看。

以上，通过3个逻辑层次实现了从设备接入到基础数据解析再到数据加工和异常监控，最后再通过API的集中控制，实现了包括常见软件类型的观测数据显示和发布功能。

2.1 基础服务层

基础服务层包括设备交互、质控警示和统一存储三大模块，是应用软件的基础模块。

1)设备交互：面向各气象设备，采用有线或无线的方式实现软件与设备的交互，可向设备发送命令，也能接收原始数据，并将数据初步解析和转换为格式化的数据。

2)质控警示：对格式化的观测数据进行气候学阈值检查，缺值处理，异常值人工订正干预，利用业务预警模型对观测值进行分析和发出报警。

3)统一存储：对原始数据、订正后的格式化数据及其它加工后的数据提供统一的管理，主要包括统一数据存储，统一数据访问，统一数据缓存。存储形式可以是文件、关系型数据库等。

在本层还有其它辅助类、公共操作类，方便软件复用。本层可以作为独立程序运行，推荐以服务方式运行，不需要提供界面即能完成气象设备的数据采集和处理及存储功能。其数据流程图如图2基础服务层数据流程图。

图2 基础服务层数据流程图

从数据流程图中可以看出，设备交互模块是系统获取数据的第一入口，担负着数据接收和设备交互的工作，是此类系统的关键模块。为提高系统稳定性、适应性和可扩展性，需要此模块具备各种气象设备数据接收和处理的能力。此处采用抽象工厂模式，将与设备交互的各种方法抽象为一个设备工厂类接口，交互方法主要有建立通讯连接、接收数据，数据格式化操作，发送数据，向设备发送命令等。农业小气候站、能见度站等设备分别继承并实现这个接口，在接口内部分别根据自身数据协议实现相应方法。在软件运行阶段，程序主体即可以根据配置参数实例化不同的工厂子类，从而完成不同类型设备的通讯连接，数据接收，数据格式化及其它交互操作。

抽象工厂模式实现了在编码阶段已经确定的设备类型的接入，采用插件式开发方法，可对未知设备类型的动态接入提供便利。插件式开发方法由一个插件控制器完成，插件控制器可以将系统内部实现了抽象工厂接口的设备类加载编译[21-23]。当系统中增加新的气象设备类型时，如大气电场仪，只需新建大气电场仪类实现抽象工厂接口，在主程序中增加参数配置项，重启主程序后，大气电场仪类就会被插件控制器加载然后动态编译为一个整体类库，抽象工厂实例化时就能选择到大气电场仪设备类型进行后续操作。图3是抽象工厂模式及插件式动态编译示意图。

图3 抽象工厂模式及插件式动态编译示意图

图3中IDeviceFactory为抽象工厂接口，假设已有农业小气候站和能见度观测站，并分别实现了该抽象工厂接口。PlugController为插件控制器，当主程序运行后，会调用插件控制器，该控制器就自动把实现了抽象工厂接口的各种设备工厂类动态编译到主程序中，从而作为主程序的一部分被调用。通过插件控制的方法，可以很方便地将诸如大气电场观测设备(ElectricDevice，如图3中虚线框内所示)等设备的工厂类动态加载到主程序中。

2.2 业务服务层

面向区域气象观测业务实际，提供切实可行的统计分析、系统监控及数据交换功能。主要包括以下三个模块。

1)统计分析：提供小时、日、月极值统计，月报表分析等功能。

2)系统监控：提供系统运行日志、业务日志、硬件运行情况、传感器状态、网络通讯状态等监控功能。

3)数据交换：对外提供统一接入接口，可以快速接入其它外部系统的观测数据或集成设备。对外提供统一访问接口，用通用且规范的方式向外部传输数据。

气象观测业务需求并不完全统一，需要根据实际情况进行开发，此处也是整个系统中变化较多的部分。但是，在系统初始建设阶段，可以考虑依据气象法规，形成标准地面气象观测规范中建议的报表格式。这样后续系统只需对规范外的特殊需求做少许改动即可。

2.3 用户界面层

用户界面层主要面向使用用户，是联系用户与主程序的桥梁，向用户展示软件功能的窗口。在逻辑上分为以下三个部分。

2.3.1 显示发布

即用户看到的最终界面。按照不同的软件技术体系可以有不同的实现方式。目前无外乎桌面应用程序、网站、移动应用及微信公众号等形式。但不管采用哪种表现形式，一般都包含以下功能要求：

1)提供多种监测界面，显示实时数据、状态数据、警示信息及观测时间；

2)可以查询历史数据、历史数据趋势图；

3)可以查询数据统计和分析结果等；

4)通过电脑屏幕、电视墙、手机或者现场显示设备显示数据功能。

2.3.2 统一API

API服务层是一组定义好的功能接口类库，通过该接口类库，可以为不同的应用界面提供功能统一、数据一致、访问规范、安全可控的数据服务。

2.3.3 文档知识：

一个好的软件设计，不仅软件的功能强大，易用性较好，而且软件相关文档的完整性和帮助手册的易用性也要求较高。因此，在业务功能之外，强调文档知识模块很有必要。文档模块包括软件使用手册、常见问题问答。知识模块包括业务观测知识、观测技巧等知识汇总显示。

与之前的基础服务层和业务服务层不同，用户界面层直接面向用户，除了实现用户需求，满足用户要求外，界面是否炫酷，操作是否易用直接影响用户的使用感受和对软件的印象评价。因此，本层除了实现以上三个模块，还采用主题技术、模版技术、开源框架等方式为用户提供风格统一，支持皮肤定制等功能。

3 实验结果与分析

近年来，针对农业生产经营特点设计的区域自动气象监测站(农业小气候站)被越来越多地建设和使用。农业小气候站不仅监测要素齐全，而且还能实现实地监测和远距离数据监测。主要监测传感器有温度、湿度、风向、风速、雨量和气压等6种常规传感器，以及土壤湿度、光照度、叶面湿度和土壤水分等多种专业传感器，另外还会配置显示屏(多为发光二极管LED显示屏)以在实地实时显示采集的数据。在用户界面方面，多以GIS地图方式展示观测数据[24]。

本次实验通过以下步骤和方法进行该系统设计的可行性验证。首先，通过分析农业小气候站的功能需求，确认可以采用上述方法，在该系统上通过增加“农业小气候站”工厂类，实现农业小气候观测数据的接入和分析处理。其次，参照图3，编码实现农业小气候站工厂类(AgricultureDevice)，该类与“能见度站”(VisiDevice)工厂类类似，都继承自接口工厂类(IDeviceFactory)，通过实现接口工厂类中定义的格式化数据方法和命令交互等方法即可对该代码进行编译，形成农业小气候站工厂类静态类库。然后，将编译后的类库放入主程序执行文件夹内，启动主程序后，新增加的农业小气候站工厂类即可被插件控制器自动识别和加载。

当农业小气候站建设完毕，采用无线通讯方式接入到主程序中。在通电后设备会主动向主程序发起连接，主程序通过设备标识，识别出该设备。然后利用工厂实例自动找到农业小气候工厂类进行数据的解析及与设备的交互工作。自此，实现了农业小气候站的数据接入和交互。针对农业小气候站的业务应用，可以直接利用之前的用户界面实现数据的展示等功能。最后，根据前文所述软件设计架构方法，系统软件整体结构图如图4所示。

图4 软件整体结构图

相比图1，图4给出了设备层的概念，其它从低到高依次为基础服务层、业务服务层、用户界面层。提出设备层是为了方便将硬件与软件功能整体展示，设备层不仅可以是不同厂家的农业小气候站，还可以是不同类型的监测设备，可以是一台设备独立监测，也可以多台设备进行组网监测。基础服务层实现农业小气候站的数据接入和交互，然后形成格式统一，质量完整的基础数据，并存入数据库等文件中。业务服务层从数据库中取出基础数据，然后对基础数据加工分析得到统计数据和监控等数据，最后存回数据库中备用。用户界面层利用统一API服务将各种加工后的数据提供给中心站软件、Web客户端网站及移动APP应用等使用。

通过本次实验，仅需增加一个“农业小气候”工厂类，即可快速实现农业小气候观测数据的接入和处理。极大地提高了工作效率，不但降低企业的开发成本，还因为功能高度集成、功能模块化、软件复用等优势，保证了软件的开发质量和软件的稳定性，这将有利于降低软件的维护成本，同时提高企业履约能力和盈利能力。

4 结论

本文依托分层架构设计思想，提炼了区域自动气象站的应用软件设计架构。提出基础服务层、业务服务层、用户界面层共三个层次。通过分层隔离使得层与层之间都是相互独立的，架构中的每一层的变化不会影响其它层。在每层中采用模块化设计，进一步提高内聚降低耦合，保证了系统的健壮性，使得系统更加易维护。针对不同类型的区域自动站，采用抽象工厂模式设计，配合插件式开发，利用动态编译技术，极大地提高了系统的适用性和扩展性。通过农业小气候站的实验应用，可以方便地实现设备的数据接入，提高了工作效率。但是在用户界面层，不同类型设备表现出一致的界面，显得有些呆板，下一步可以考虑在界面层实现时也可以利用插件式开发，实现不同设备类型，提供不同的用户界面。