气象综合业务运行监控和管理系统软件的开发设计研究

陈凯 吴健 程若虎

摘要：为增强省级气象信息化水平，软件设计开发实现观测网络互联化，全空间无缝使用，改进现有综合业务运行项目分散使用管理的现状。文章全面而简要介绍了该系统软件项目的开发情况，主要包括环境配置，结构设计、架构模式、项目功能、数据库和页面设计，以及开发实施过程中遵守的準则及标准等等。

关键词：气象综合业务;监控管理系统;结构;功能;数据库

中图分类号：TP311.52 文献标识码：A 文章编号：1007-9416（2019）07-0175-02

0 引言

随着气象探测设备类型和数量的不断增加，气象装备的稳定和数据质量的可靠性对现在气象业务有着非常重大的影响，为及时有效地发现装备故障和数据质量异常，设计开发一套气象综合业务运行监控和管理平台，实现故障的实时预警有着非常深刻的意义。开展系统软件的功能开发设计研究工作，要充分满足业务需求，体现软件的实用性、先进性、可扩充性、可靠性和可伸缩性十分必要。

1 软件开发设计的准备工作

针对该系统的目的、要求等情况进行详细的调查收集，并反复推敲梳理，分析研究在系统中实现目标的可行性，从而明确该系统的设计要求，解决管理者和操作者所要获取的信息要求。在此基础上，编写了较为完整和成熟的《气象综合业务运行监控和管理系统》需求方案;并从信息处理的功能需求上提出系统的逻辑模型，为下一阶段进行物理方案设计、确定解决问题的相关运算方法做好铺垫。同时，在开发设计过程中，要充分体现出软件的实用性、先进性、可扩充性、可伸缩性和可靠性。

在系统软件开发设计过程中，遵循的原则有：

（1）执行标准原则。在软件的开发过程中，完全按照《计算机软件开发规范》（GB8566-88）来进行规范和控制。（2）整体性原则。整合集约现有分散的观测数据加工处理系统，充分利用现有资源，优化建设规范统一的观测数据加工处理系统，优化系统管理维护和运行，实现观测业务现代化与气象业务信息化深度融合。（3）集约规范原则。按照综合气象观测质量管理体系和质量保证体系的总体要求，制定气象观测业务标准规范，推动气象观测业务建设标准化、集约化。（4）分散—集中原则。在实现功能的过程中，进行模块化设计，复杂问题分散解决，在考虑系统整体协调原则下，确保系统实现整体工作的稳定性和可靠性。（5）目标优化原则。对简单软件开发设计来说，主要考虑是求最优解;对复杂软件开发设计来说，主要考虑的是求满意解。本系统可以理解为是满意解和最优解的几何体，这里包括对数据的处理速度、操作是否简便，数据大小优化等要求。

这里主要遵循的的是几个主要原则，并非全部原则，实际开发设计中还是用了其他原则，在这里不再详述。

2 软件设计的基本要求

2.1 性能要求

浏览器支持：支持浏览器B/S方式，完全支持IE8、chrome和Safari及以上的，可支持在移动设备上浏览;操作系统支持：系统控件支持32位及64位操作系统，服务器端全部使用64位操作系统开发。

系统接口：系统的数据、界面及计算服务具有可供第三方使用的接口，其它系统可使用不同方式调用。

性能要求：实时监视数据的采集周期不超过60秒，计算数据的刷新周期最多为5秒;页面在局域网条件下加载完成时间小于5秒;界面上显示的画面数量、组态图形数量及动态点数应无限制，且数据刷新率满足要求。高峰时，服务器CPU占用率少于80%（2颗8核至强CPU），内存占用率小于128G;系统至少满足最大100并发用户访问。

2.2 系统适应性和安全性要求

系统具有优化和再配置能力;支持LDAP单点登录，确保用户信息只配置一次，即可全部信息系统共同使用;按照SOA的实施方法论，提供完善的Webservice接口，确保系统架构灵活性。

2.3 系统可靠性要求

系统应具备自动预警和自动数据备份功能，以避免出现影响正常运行的严重事件，例如：系统死锁、资源耗尽、程序崩溃等，能够提供系统日志，满足审查系统和事务处理的要求。

3 系统开发设计及实现

主要开发设计过程包括：系统总体结构设计，软件架构设计、功能设计等。

3.1 软件开发环境

B/S模式是基于WWW技术对传统C/S模式进行改进而形成的一种新型处理模式。该模式是以Web为中心，采用TCP/IP、HTTP为传输协议，前端采用通用浏览器（IE、Netscape、Navigator等）Web 客户软件，客户端可通过Browser（浏览器）访问Web。后端采用Web Server访问数据库，将结果返回浏览器，多级用户的操作均可通过浏览器进行。前后端连接靠HTTP协议，所有开发都在Server上进行。

在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（Browser）实现，但是主要事务逻辑在服务器端（Server）实现，形成所谓三层3-tier结构。相对于C/S结构属于“胖”客户端，需要在使用者电脑上安装相应的操作软件来说，B/S 结构是属于一种“瘦”客户端，大多数或主要的业务逻辑都存在于服务器端，因此，B/S结构（如图1）的系统不需要安装客户端软件，它运行在客户端的浏览器之上，系统升级或维护时只需更新服务器端软件即可，这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本。

采用这种结构，其优势主要体现在，无需专门开发客户端软件，系统在维护和升级的同时，不影响客户端的使用，在保证浏览查询者方便操作的同时，也使系统简单灵活;可跨平台操作，任何机器只要装有ie浏览器，均可做为客户端访问系统;将服务器划分为数据服务器和Web服务器两部分，使数据库端易于维护和升级（如图2）。

3.2 软件构架设计

以基础设施资源与气象大数据体系化模式的思路建立一整套机制，面向业务和应用，以服务为导向，建设全流程、可视化的运维监控管理平台，实现一体化的業务运维管理体系。软件构架主要包括三个层次：监视信息采集层、监视信息处理层和应用展现层（如图3）。

（1）监视信息采集层：监控管理平台实现对基础设施资源池、网络、网络安全及机房和数据全流程等监视信息完整采集。具体有：计算、存储、网络等基础资源以及对运行于基础资源上的数据库、中间件等平台环境的监控;省内高清会商系统，MCU、终端等设备状态及会议效果等信息的采集;网络拓扑管理、网络设备监控、网络链路监控及网络事件管理;网络信息安全威胁统计;集成机房温湿度、配电、空调、消防及门禁、安防等信息;每类气象数据在生成、传输、存储、服务和应用等各环节的关键性能指标状态。（2）监视信息处理层：对实时监视信息的分析加工统计，生成统计分析报表，将监控信息、分析统计结果、告警及反馈等信息规范化存储管理，存储在日志文件、数据库以及语音库中，为其他子系统提供数据源。对滚动日志文件、监控数据库以及临时数据进行定期清除，并实现备份、归档。还将处理通过手机客户端处理的报警反馈结果，并形成存储、数据和报表。（3）应用展现层：设计监控信息查询统计分析与综合展示功能，用于在省级信息业务平台展示业务总体状况。集成应用新技术，增加信息网络业务值班运维手段，研发电话语音通知系统、移动终端处理反馈系统，根据业务流程和应用需求设计告警策略、参数的配置，实现故障自动定位，以及智能化的处理、反馈，提供短信、电话和移动终端APP推送等多种形式的报警提醒。

3.3 软件系统子系统设计规范要求

3.3.1 基础设施资源池监控

充分考虑底层硬件平台和虚拟化平台的差异性和接口开放情况，以及资源管理、运维和第三方软件的接入问题，进行云平台的松耦合架构设计，将异构虚拟化管理与资源统一调度进行有效隔离，确保各个组件的独立运行。

系统支持省级资源池基础设施资源集中监控，实现对计算、存储、网络等基础资源以及对运行于基础资源上的数据库、中间件等平台环境的监控，并应当根据实际本地资源实际情况实现对本地及异构设备的集成对接。

3.3.2 网络、安全及场地监控

网络监视应当具备网络拓扑管理、网络设备监控、网络链路监控及网络事件管理功能。

3.3.3 数据全流程监视

以实时资料（台站数据、接收数据、业务单位数据）为主线，实时监视每类气象数据在采集（生成）、收集、质控评估、入库、分发等各环节的关键性能指标状态。包括上行数据传输实时监视、下行数据传输实时监视、全流程详情查询。

3.3.4 告警与管理平台

应支持监视告警处理规则管理及告警分析处理。

3.4 系统的维护

该系统的运行维护主要体现在纠错性维护、完善性维护和预防性维护这三个方面。据不完全统计，现在大部分的软件产品完善性维护沾所有维护工作总量的40%左右，所有在系统设计研究尽量把需求分析详尽，以减少后勤完善性维护的工作量。

（1）纠错性维护。系统在测试时不可能完全测试出系统中存在的所有错误，当系统运行到一段时间后会暴露出系统内隐藏的错误，这是维护改进就很重要。（2）完善性维护。根据用户在使用过程中不断提出的新要求，来持续扩充原有的系统功能;用户在系统使用一段时间后，会对系统有不同程度的改进要求。（3）预防性维护。维护工作要由被动变主动，来延长系统的使用寿命。

4 结语

本文的系统开发设计研究，目的是加强气象业务的信息化、集约化管理，高效完成安徽全省气象的日常管理工作，致力于气象业务的长远发展，是符合业务发展及信息化规划纲要的根本精神。目前，该系统开发设计的编制，为软件开发提供了指导性的方向，同时，也为单位的业务管理提供了经验。