气象信息业务平台设计（共4篇）
气象信息业务平台设计 篇1
随着20世纪90年代第一台国产字幕机、第一台国产非线性编辑系统、第一套硬盘播出系统的面世, 中国电视台的信息化、数字化、网络化改造就拉开了序幕。在厂家和用户的共同努力下, 信息技术与视频技术的结合, 在短短10年间得到了飞速的发展。涌现了非线性编辑网络、新闻文稿系统、广告编播系统、节目包装网络、硬盘播出系统、媒体资产管理、演播室共享系统、互联互通平台、全台一体化网络系统等一个个网络化的系统, 并应用到节目制作生产工具中, 经历了一个长期、循序渐进的过程。
随着近几年业务的迅速扩展, 气象频道已有各个业务子系统之间需要交换的节目、数据也越来越多, 原有的磁带以及小范围的网络传输交互方式, 已经影响了业务的发展, 需要通过全频道的网络化提高业务系统的生产效率。因此, 对现有系统以及下一步需要建设的业务系统进行整体规划, 建立合理的全频道节目数据交换平台势在必行, 这也是进行中国气象频道综合业务平台设计的出发点。
一面向服务的体系架构设计理念
中国气象频道的综合业务平台的架构体系是构架在JDMA (Jetsen Digital Media Architecture) 上的新一代综合业务服务平台, 它的设计目标就是以面向服务的体系结构 (SOA) 为基础, 构建一个全频道互联互通的一个基础业务服务平台, 将频道所需各个业务处理流程连为一个有机的整体, 充分发挥数字化、网络化的技术优势, 以提高中国气象频道节目制作、生产和内容服务的质量和效率。
作为体系基石的SOA (Service Oriented Architecture) 是一种面向服务的体系架构, 是构造分布式系统的一种方法, 它将一个业务系统或者业务系统内部的一个功能单元定义为一种服务, 通过在这些服务之间定义一个良好的接口规范联系起来, 将业务应用功能以服务的形式提供给最终用户应用或其他服务。这个概念由IBM最早提出, 并逐步为IT业界各大巨头 (如HP、ORACLE、BEA) 所认可, 并在近几年迅速的发展起来。
SOA概念的提出并非偶然, 在当今科技迅猛发展的形势下, 几乎所有的机构、企业在管理经营的各个环节均引入了大量的IT技术应用系统。这些应用系统开始只是各自封闭, 信息难以交换, 或通过原始的磁盘、磁带方式进行。随着网络的飞速发展, 人们开始开发各种应用系统接口, 通过网络进行数据的交互和传递, 将某几个系统应用进行集成, 最终将各个应用系统连接起来。但是, 随着业务的不断增长和不断变化, 这种应用系统之间点对点的连接通讯模式也变得越来越难以适应需求。当一个企业内部拥有十数个甚至数十个应用系统时, 一个应用系统要和其他系统交互, 接口的开发就变得非常的复杂和庞大, 而最致命的是, 当这个应用系统更新的时候, 其他的应用系统也同时受到影响, 接口需要再次开发, 一切的工作都要重新开始。
SOA正是为了解决这些纷繁的应用系统之间的整合工作。它将各个应用系统的功能封装为服务, 并利用企业服务总线 (Enterprise Service Bus) 将所有的应用系统连接起来, 定义统一的接口标准以及服务调用方式, 通过流程服务来对总线上所有的服务进行整合, 以完成企业的具体业务应用。
ESB (Enterprise Service Bus) , 即企业服务总线, 是SOA架构中的基础构件, 是连接应用和服务的一个灵活的集成架构, 能够减少接口的数量, 降低接口的复杂性。ESB完成以下四个主要功能:
●服务的路由 (Routing) :在SOA的架构中, 所有的服务调用都通过ESB进行位置透明性的路由和定位;
●协议的转换 (Converting) :在一个SOA的架构中, 每个应用系统接口采用的标准传输协议不尽相同, ESB支持多种传输协议, 如HTTP、JMS、MQ等, 并负责将各个应用系统的协议进行转换, 换句话说, 就是在几个系统的对话过程中充当翻译的工作;
●格式的转换 (Transforming) :应用系统的消息传递过程中, 消息的格式不完全相同, 因此ESB也需要将消息转换为各应用系统能够认知的格式;
●事件处理 (Handling) :通常来说, ESB还包含一些事件处理的功能, 这里指一些系统通用的事件处理, 如日志记录等。
专为视音频行业应用而开发的EMB企业媒体总线扩展了SOA架构体系中ESB的概念, 成为专用于传输媒体数据的总线。EMB提供下列服务:
●提供数据系统间迁移服务;
●提供数据的归档服务;
●提供格式转换服务;
●提供码流转换及合成服务。
两类总线既紧密结合, 又相互独立。企业服务总线ESB完成系统与系统、应用与应用之间的业务应用层面的互联, 处理元数据信息、控制信息、指令信息, 以小数据量的传输为主。企业媒体总线EMB完成系统与系统、应用与应用之间的业务应用中具体的媒体数据的传输, 包含大规模的海量数据突发性的迁移、格式转换、码流转换。ESB面对的应用层、EMB面对的数据层, 两者密切联系不可分割;企业服务总线ESB只对小数据量的信息进行传递, 基于HTTP、SOAP、MQ、WSDL、J2EE等层面的数据转换、协议转换。企业媒体总线EMB针对海量媒体数据信息进行传递。基于MPEG-2、DV、MPEG-4等协议标准进行格式转换和码流转换, 两类总线在处理数据时彼此相对独立。
二气象频道综合业务平台的设计
气象频道综合业务平台的架构由基础网络平台、系统软件平台、公共服务平台、互联互通平台及节目生产及管理系统平台组成, 组成及结构见图1。其中公共服务平台和互联互通平台的技术方案是平台设计的重点。
公共服务平台包含了全台网中的统一认证、媒体传输/转换、监控管理、业务流程管理等几个公共服务系统。统一认证系统包含有用户认证、用户授权、访问控制等功能, 是全台业务统一访问门户的入口。媒体传输/转换包含有文件迁移、归档迁移、文件转码、打包合成、加密校验。文件迁移负责各个业务子系统之间的数据迁移;归档迁移负责数据归档时在线到近线存储之间的数据迁移;文件转码实现码流格式和编码的相互转换;打包合成实现文件的自动打包合成;加密校验实现在文件传输迁移过程中数据传输安全保证。监控管理包含有设备监控、网络监控、安全监控、业务流程监控、预警处理, 主要包含了IT层面监控管理和业务流程层面的监控管理两方面, 实现全频道统一的监控管理。业务流程管理系统通过工作流管理工具实现业务流程的管理配置;通过任务策略设置定义各个业务网络之间的数据交换共享的策略;通过优先级控制实现各个业务流程优先级控制;通过任务分发实现各个业务系统数据交换共享的任务接收、管理及分发。
互联互通平台利用ESB及EMB两类总线, 为新闻、制作、播出、收录、媒资等各个业务应用系统提供网络互通访问支撑。数据的传输主要分为取、送两种方式, 数据交互模型见图2。各个应用业务系统在取送的过程中都是被动方, 换个说法就是数据迁移的主导都是JASP。如果系统A要向系统B传输数据, 为保证全台网的松耦合结构, 系统间不允许直接进行数据传输, 数据的传输都要通过统一的JASP来实现。
利用FTP及SAN共享两种方式进行数据的传输, FTP方式支持各种操作系统, 安全认证功能强大, 支持授权访问机制, 可以做到没有用户名和口令不能传输, FTP建立在面向中联接的TCP协议之上, 保证数据传输可靠性, 布署比较方便, 在设计方案中, 选用FTP方式实现生产系统、播出系统与中央存储平台的数据传输。SAN共享方式是目前在媒体行业各内部网采用最广泛的一种点对点传输方式, 采用FC通道, 大数据量的传输效率非常高, 在设计方案选用此方式实现中中央存储区和原有媒资系统的数据交换。
三结束语
综上所述, 中国气象频道综合业务平台的设计是一个系统工程, 它的建设和实施需要对现有的业务流程和网络结构进行局部甚至全面的优化重组, 以达到提高改善生产方式、生产效率、降低运营成本等目的。同时也必然会在频道内部的资金配备、人力资源配置变化、技术团队建设、组织机构调整、运行及安全管理制度等方面提出一系列新的要求。由于项目建设带来的各方面变革波及方方面面, 因此更需要从整体的角度进行把握, 才能实现整合内部信息资源, 提高核心竞争力, 提高生产效率, 改善生产方式, 降低管理成本的目标。
摘要：简要介绍了面向SOA面向服务体系架构设计思想, 针对气象频道的业务需求, 详细介绍了综合业务平台的总体设计思路, 系统的组成及结构, 并重点介绍了公共服务平台、互联互通平台、数据交互的技术方案。
关键词：综合业务,互联互通,全台网
气象信息业务平台设计 篇2
1 研究内容
青岛市气象探测业务保障平台需要满足对全市各类探测设备的实时监控、业务值班管理、业务质量统计管理、设备维修维护管理和物资装备管理等多项功能, 满足业务应用和业务管理需求。主要包括:
对各类气象探测装备的探测资料和文档进行研究, 分析其数据结构、字段含义和包含的设备状态信息, 实时监控这些设备的运行状态, 对出现的故障信息 (包括数据缺测、疑误数据等) 及时进行显示, 并通过短信报警发送给维修人员和使用人员进行后续处理。
对装备保障各岗位进行业务分析, 按岗位梳理业务流程, 编写相应的业务模块, 实现对值班日志、业务表格以及装备维护和巡检情况的在线填写和信息化管理。
对纳入业务质量考核的探测设备, 通过对其探测数据接收和传输情况的分析, 实现对设备到报率等信息的统计查询。
优化区域站等探测设备的故障维修流程, 实现故障维修的上下联动和流程化管理。
建立全市装备信息库, 利用条码设备实现装备备件从采购、入库、调拨、维修到报废、出库、列装的动态化管理。
2 系统设计
2.1 系统架构
整个系统体系结构基于微软的.NET开发技术按照三层体系结构进行设计, 采用J A V A语言编写, 后台数据库采用SQLSERVER。系统架构图见图1。
界面层主要提供前台界面, 包括平台的静态信息页面、数据输入页面以及动态交互信息页面。逻辑层响应界面层的应用调用, 通过各类数据处理程序从数据层获取数据, 进行应用的逻辑处理。数据层为业务逻辑层提供访问底层各类探测业务数据库的接口, 响应逻辑层的数据调用, 并返回相应的数据。
2.2 业务结构设计
目前多数市级气象部门建立了探测保障中心并负责全市的探测保障业务, 因此该平台以市级—县级业务模式设计。市级气象部门的探测保障中心负责全市所有探测设备和装备保障工作的管理, 审核并执行县局提交的探测数据查询分析请求、业务质量查询统计请求、设备维修维护信息交互上报。各县局只负责本辖区内探测设备的相关业务。
2.3 软件设计
系统设计采用B/S架构。利用JAVA、.NET语言编程形成动态网页, 提供良好的交互界面。各用户通过局域网访问, 实现基于WEB方式的动态信息录入、检索以及各种交互式操作, 满足不同部门管理人员和技术人员信息查询与分析处理的需要。
3 功能设计与实现
青岛市气象探测业务保障平台主要包括设备监控、数据管理、业务质量管理、值班管理、设备维修管理、气象社会化保障管理、系统管理等模块。功能架构见图2。
3.1 设备运行监控
监控全市范围内各类探测设备目前的运行情况, 快速定位站点故障并作出预警, 提供详细的探测资料查询和对比。对自动站、交通站、雷达、浮标站等实时性和重要性较强的设备, 将其故障和报警信息集成显示在预警信息页面 (见图3) 中, 并通过短信进行报警, 便于值班员快速发现故障并进行处理。设备状态类型分为正常、缺报、要素疑误以及电压异常四类, 分别用绿、红、棕、橙四色图标显示。
3.2 探测数据查询统计
提供各类探测设备的实时和历史数据查询统计, 并根据不同站点、观测要素、时间段等条件生成相应对比图表 (见图4) 。
3.3 值班工作管理
各业务部门可根据岗位不同设置相应的值班流程和工作任务计划。业务人员通过值班登记填写值班日志和各类设备维护记录, 并可进行检索查询。为不同工作设置相应基数, 通过值班员日常选择具体工作从而自动统计出月质量报表, 反映每个人的工作情况。
3.4 维修维护管理
用于自动站等探测设备的维修管理。市局探测中心通过下发故障通知单 (见图5) , 将设备故障信息告知各区市局, 并通过短信提醒。区市局维修人员到现场维修并填写维修记录反馈市局。
3.5 业务质量管理
对区域站、交通站、浮标站等探测设备的到报率等业务质量指标进行统计, 提供按照时间段 (周、月、年) 和按辖区查询全部或单个站点的到报情况, 生成相应的质量统计报表。
3.6 装备库存管理
探测中心和各区市局分别建立本地装备备件库, 采用条码技术对所有采购的物资备件进行信息化库存管理。备件管理使用流程为装备申请→反馈→采购→入库单→入库→管理→调拨→出库单→出库→盘点 (见图6) 。
3.7 系统管理
实现对用户和操作记录的管理。各单位管理员、业务技术人员、管理人员通过注册登记分配不同的访问和使用权限, 所有用户的访问操作情况均被系统在后台自动记录, 从而保障系统安全可靠。
4 总结
青岛市气象探测保障业务平台面向全市气象探测保障的业务和管理部门, 平台功能基本涵盖了目前探测保障方面的业务需求, 实现了对市局和基层台站气象探测保障业务的信息化管理。平台投入业务使用后, 将进一步加强青岛局的探测装备管理能力, 这对提升青岛市气象局的探测业务质量, 满足率先实现气象现代化具有重要意义。
参考文献
[1]中国气象局.第二代自动气象站数据文件格式[M].北京:气象出版社, 2010:1-47.
[2]梁海河, 孟昭林, 张春晖, 等.综合气象观测运行监控系统[J].气象, 2011 (10) :1292-1300.
[3]葛一鸣.JAVA程序性能优化[M].北京:清华大学出版社, 2012.
气象信息业务平台设计 篇3
该项目的完成能够使值班人员的记录变得简单化、科学化, 降低了值班人员的劳动强度;使管理人员对值班员和台站的传报资料统计起来更简便化、数字化, 提高了管理效率;使值班的自动化程度大大增强, 提高了工作效率。
1 系统总体设计
我省气象信息系统已经有完善的监控制度和监控流程, 需要根据现有的制度和流程制定符合我省运行监控特点的电子值班日志, 使值班日志的填写、查询、报表、故障手册功能都能适应我省现有的情况, 并能够根据业务的不断发展进行扩展。
1.1 系统体系结构
本系统要完成的主要功能包括:值班日志的填写、查询、报表形成、故障手册的编写等功能, 不仅供值班员使用, 还需要能够让管理人员查询使用, 同时其维护成本及故障率要尽可能低, 因此系统采用B/S结构。
1.2 系统技术路线
系统使用完全免费的Linux+Apache+Mysql+Php (LAMP) 搭建网页服务器和数据库实现, LAMP具有Web资源丰富、轻量、快速开发、维护简单等特点, 因此无论是性能、质量还是价格都是本系统的首选平台。
2 系统功能与实现
系统的功能实现要根据我省气象信息运行监控值班的特点进行设计, 既要根据现有的值班和业务流程进行设计合适的值班日志系统, 又要根据监控业务的发展和电子值班日志系统的特点增加防篡改、制作报表、故障手册查看等功能, 如图1所示。
2.1 实现无纸化值班
记录包括交接班、日常值班遇到的各种情况处理过程、记录缺报、催报记录等内容, 同时管理人员和值班人员可以随时查询现有值班情况、缺报情况、催报记录等, 方便进行业务总结和管理。该系统能够根据业务的实际发展进行扩展, 适应不断发展的业务需求。
2.2 值班记录防篡改
防止值班员随意篡改值班记录, 管理员修改值班记录的, 也要记录修改内容, 保证最后形成的值班记录是值班情况的真实反映, 更好地帮助管理人员查看真实的值班情况。为实现此功能, 将用户分为值班员、业务管理人员和系统管理员不同级别, 并赋予不同权限, 如表1所示。
2.3 每月形成值班报表
用于业务质量统计和值班情况统计, 管理人员可以根据统计结果查看每月每个值班员的值班情况, 每个站的缺报情况, 可以及时发现值班和传输中存在的问题并解决。
2.4 形成故障处理手册和业务学习手册, 供值班人员学习参考
运行监控的工作比较繁杂, 可能遇到各种问题, 因此需要值班员及时总结并共享值班遇到的问题及有效的处理方法, 通过共同编辑的故障处理手册和业务学习手册, 可以实现问题的及时记录和解决方法的及时总结, 有效的提高故障处理效率, 有利于新上岗人员尽快学习掌握值班要领, 减少学习时间。
3 总结
省级气象业务运行监控电子值班日志系统的设计与实现, 实现了无纸化值班, 能够记录日常值班内容, 实现值班日志的防篡改功能, 保证值班日志的真实性, 加入了值班报表查询和统计功能形成故障处理手册和业务学习手册, 便于管理人员和值班人员可以随时查询值班情况, 及时进行业务总结和管理, 提高了工作效率。
摘要：本系统根据我省气象信息业务运行监控的现状和特点, 实现了适合我省现状的电子值班日志系统, 可以提供我省信息运行监控实况、值班报表和学习手册, 便于气象管理和业务部门进行业务总结和管理。
关键词：电子值班日志,LAMP,信息业务
参考文献
[1]张金鑫, 刘松, 刘兴丽.省级气象报务电子值班日志业务系统的设计与实现[J].黑龙江气象, 2012, (6) .
气象信息业务平台设计 篇4
移动短信服务是以手机短信的方式实现信息的发送和接收。本文把计算机和短信服务平台结合在一起,构建预警信号的服务平台,及时准确地将灾害情况发送给公众,有效地提高了灾害防御以及财产的保护,具有重大的意义。
1 系统简介和结构
整个预警系统采用Windows对界面进行编辑,通过简单的操控和同步信息的发送,就可以实现信息快速到达用户。此系统的功能主要包括不同用户的管理、安全的处理、统计的分析等。此平台还能根据实际的需要提供专用的接口,如不同组件的接口、二次开发的接口以及不同合作的接口。系统框图如图1所示。
从不同的逻辑结构进行划分主要有接口层、数据层、不同数据的支撑层、实际应用层等。其中接口层主要实现电信商与用户的对接,需要特定的协议建立通道;数据层主要是信息的核心内容;数据支撑层主要实现预警内容的发布方式;应用层是指到达客户终端的一系列服务[4,5,6]。系统结构实现框图见图2。
2 预警平台设计
为了使平台提供更好的信息服务,对系统的硬件进行更新配置。服务器采用戴尔R710,其拥有16 GB内存,硬盘是由6块RAID磁盘构成,另外,还有数据库服务器、网络服务器、双电源等。根据上面预警平台的层次,将整个系统分为接入电脑系统、数据支撑系统、界面管理系统。下面对这些系统进行设计[7]。
2.1 数据库的规划
计算机的数据库对性能比较注重,能够很好地评估数据以及内存的分配等。在双机的方案中,不同的网关服务器都需要建立自己的数据库,实现数据的实时更新和同步。整个数据库的设计采用集中的方式进行构建,中心实现对整个数据的概括,然后实现数的分配。数据库主要对权限管理、通道管理、用户管理以及任务管理四个方面进行设计。分布和集中的搭配实现了存储容量的扩大,实现高效率的传送。
业务库的对象主要是业务配置、系统配置等,能够保存设置业务的数据。对于话单库,其能够很好地运用存储系统,客户利用管理系统平台实现信息的及时查询。所有经过系统平台发布的消息,在网关服务器都有备份,系统平台可以保存近3个月的通信记录,一旦中间故障,可以及时查询。另外,运营商可以对短信进行监控和实时跟踪,保证了信息的完整度。
2.2 支撑系统
数据的支撑系统能够完成所有业务的支撑和扩展,其可以把不同的业务引进,不同的用户拥有更多的选择。支撑系统主要针对的是通信层,能够及时与客户进行沟通。整个系统可以从数据和业务两个方面进行完善,支撑整个平台的发展,保证不同数据的更新。
2.3 接口系统
整个系统的接口能够保证与上级网关良好的接入,实现信息的互通。只有在网络连通的情况下,系统的信息才能及时的发送出去。网关的功能除了保证上述的功能外,还具有共享不同技术,实现信息流的畅通无阻,并且可以对日志进行发送和接收的功能。在接口时,对混合接入也有优先等级,发现故障的信息,还能够自动处理,发送故障的报告,进行重新发送[8,9]。
2.4 管理系统
系统的管理主要包括业务、任务、内容、号码等,将这些信息提供给管理者,更好地实现预警信息的管理和维护。
对于号码的管理主要分为不同号段的划分,并对不同区段的功能和属性进行分类。除此之外,还支持很多用户信息及时录入以及系统的打包。管理者就会根据不同的预警信息和设置号码段的属性发送不同的信息。如果用户得不到相应的信息,系统平台支持多种查询方式[10]。
信息平台也对用户提供多种服务,如信息的订购、日志查询、订阅信息等。操作人员根据客户反馈的问题,及时进行处理并对发送的信息进行浏览。整个系统的任务管理主要包括当前的任务、待发以及暂停任务。当前的任务主要指信息的不定期发送,填写相应的信息后,选择所需要的城市情况完成内容的发送。待发和暂停业务可以根据实际的情况对不同状态的报告机制进行维护。系统也能够对不同业务的用户进行统计分析,包括不同时期的用户统计、发展对比等[11,12,13]。
3 同类技术的对比
由于实际气象情况的变化,较短的信息并不能满足要求。普通的70字短信限制了发展的需要,为了解决此类问题,特设计了长短信的技术。
长短信的技术就是指字符量超过70个汉字的短信。不同的用户手机会根据要求使得界面显示收到的多条信息。这些信息使得它们相互隔开,客户不能很好地利用发来的气象信息。长短信协议能很好地运用这种情况满足要求,除了使字体的字数相互分开,在逻辑上也是相通的,不会破坏信息的整体性。在格式上,主要有两个地方不同,也就是UD和UDHI。
网络安全也是保证信息发送的主要因素,主要包括访问、检测、攻击、操作等。设计的网络应满足以下几个功能:
(1)系统网络需具有冗余的能力,关键的网络链路能够应对冗余的问题,实现路由的切换;
(2)网络的系统应能够区分安全的区域,针对不同的业务区设定不同的访问策略,也可以对IP以及端口进行设置;
(3)网络的服务器能够保证系统抵抗非法入侵以及带有病毒的链接。此时的系统能够自动阻断通信,实现整个通信的自定义;
(4)系统的网络服务器能够定期检查安全情况,对检测到的漏洞能及时补救;
(5)保证信息的保密性以及远程的维护。
4 系统实现
根据上面对各个模块的设计要求,对各类的气象信息进行报录和审核。因此,在进行发布时需要建立预报的网络系统。根据数据库SQL 2000进行设计,在气象平台上录入当天的气象。
以四川发布气象信息为研究对象。气象的预报必须经过一定的审核,才能正式发布。当信息正式确定后,整个状态就确定了。当定制信息情况时,首先是预报的录入、审核以及信息的发布。预警信息的录入平台登录,进入管理界面编辑。管理者可以选择不同的运营商、地区,提取想要得到的信息,完成上述要求后,就可以点击提交并完成录入。预报审核图如图3所示。
信息提交后,管理者可以进入预编辑管理,确定内容无误后,开始单个或多个审核,完成审核后系统的界面显示为待发布。
信息审核无误后,可以预发布。预警的信息发送也是有时间限制的,在特定时间点之前是可以修改的,其后是不能进行修改的。当预警信息发送后,就需要对服务的效益进行评估[14,15]。
后台的处理主要是指数据的后台处理,一旦到达指定发布时间,模板信息的内容就会根据合成的内容及时实现信息发送。用户接收到这样的信息后,就及时采取相应的措施。在整个信息的发送过程中,其流程主要是模板的采用、特定任务的生成、气象信息的发送、群发服务器。所谓的群发服务器就是实现天气短信的群发。由于每天的通信量非常巨大,因此要保证信息的快速、高效、安全。当上面的内容完成之后,群发器经过统一的调度实现信息发送。
定制点播功能主要包括上行信息的处理和相关业务的命令。上行信息的功能主要指网关程序与用户之间的关系。当生成定制命令时,系统每天会自动发布;当生成点播命令时,上行就会根据要求发送相对应的信息。预警信息的发布主要根据Web网络系统进行登录和管理,包括权限、角色、群组以及操作员的管理。当完成数据的发送后,可以对历史任务进行查询以及通道的管理。
5 结论