校园信息发布系统（共10篇）
校园信息发布系统 篇1
现代教育中, 学生不但要接受正规的课堂知识技能教育, 而且需要在业余生活中得到更多的技能培训和知识教育。所以, 作为现代教育的技术手段, 实现网络化、信息化、多媒体化自然有着异常重要的现实意义。
未来的教学必将依托网络来实现全天候的功能, 有网络就有教室的核心思想一定会配合物联网, 智慧校园的思想逐渐深入人心。通过一套网络视频系统将校园内的任一教室、任一办公室、任一宿舍, 甚至有无线网络覆盖的角落都可以成为一个课堂。
1 流媒体分析
1.1 较早的网络视频格式:RM/RMVB (Real Media) 格式
网络视频要能支持在线播放、现场直播, 要能实现边下载边播放, 即通常所说的流媒体, 这是符合网络传输的特点的。但是不可忽视的就是网络带宽, 由于视频文件的体积往往比较大, 网络带宽限制限制了视频数据的实时传输和实时播放, 它是限制网络视频发展的瓶颈。
RM格式是RealNetworks公司开发的一种流式视频文件格式, 可以根据网络数据传输速率的不同制定了不同的压缩比率, 从而实现在低速率的广域网上进行影像数据的实时传送和实时播放。但是由于压缩比较大, 数据源损失也很严重, 图像清晰度受到极大限制, 不适合用作网络课堂教学使用。
1.2 现在应用的FLV格式
以前, flash中的视频文件得导入是一帧一帧变成位图。结果导致文件巨大, 限制了它的应用范围。随着技术革新, Macromedia公司开发了属于自己流式视频格式——FLV。这种格式是在sorenson公司的压缩算法的基础上开发出来的。FLV格式不仅可以轻松的导入Flash中, 压缩比高的同时保证了高度的清晰图象文件, 清晰的1分钟FLV视频大小在1MB左右, CPU占有率低, 适合网络传输。
2 网络发布准备
2.1 WEB点播
视频点播系统可以多种多样, 用简单的树型结构配合框架网页可以较为轻松的实现。缺点是文件数多了以后管理困难, 文档搜索也困难。但是由于实现简单, 可作为新闻类、热点类快速直播节目的载体。
树型菜单闭合状态树型菜单开启状态
2.2 Web播放器
要实现Flv在线播放还需要一个网页播放器。方式有JS嵌入或者影片地址直接传递等。这是一个直接地址传递的应用。
影片地址直接传递实现简单, 将代码写入网页中, 指定一个播放器, 这里主要使用了vcastr*.swf流媒体播放器, 可以较好地实现视频播放。
2.3 视频采集与编辑
采集:使用小高清摄像机, 最高可拍摄1080p, 对场地以及被拍摄人员进行远景, 全景, 中近景, 特写各种景别的拍摄, 并且加上拍摄地部分标志性物品及陈设的空镜头。对现场实施全程同期声录音。
剪辑:1使用录放机与工作站配合将所拍摄磁带采集出avi视频格式;2使用Adobe premier CS5对视频进行剪辑;3对照片及所选背景使用Adobe photoshop进行设计及编辑;4通过Adobe aftereffect及Maya 7.0或3Dmax配合使用设计片头片尾效果;5使用话筒及调音设备对视频新闻进行后期配音解说;6用Adobe Audition进行声音的去噪及剪辑;7通过字幕软件进行同期字幕输入;8使用Adobe premier进行输入成为flv的网络flash视频格式。
3 发布效果
随着互联网, 多媒体编码技术的不断发展, 流媒体技术具有广阔的应用前景, 流媒体技术的应用将对人们的工作和生活带来深远的影响。
4 运行测试
实际制作的视频流分辨率在720*576, 帧频为25fps, 码率是2000Kbps, 在局域网内100用户并发点击, 首次连接下载缓冲时间短, 访问流畅, 播放过程中没有出现停顿、卡壳现象。
参考文献
[1]张生花, 谢水珍.流媒体技术在校园网上的应用[]电脑知识与技术, 2007 (17) .
[2]赵美慧, 陈正东.多媒体素材与采集[M].北京:化学工业出版社, 2005 (8) .
[3]李新.高校图书馆数字视频点播在线资源建设发展之我见[J].云南科技管理, 2009 (6) .
校园信息发布系统 篇2
为能及时、准确、有效地发布学校信息，全面展现我校的整体形象，特制定本制度。
一、发布信息的主要内容
1、学校总体信息：包括介绍学校概况、学校领导、学校机构设置、学科建设、科研机构情况及学校新闻信息等。
2、部门信息：包括部门通知、学校内部机构设置、工作
职责、主要负责人及工作电话，教学工作、科研工作、党建和思想政治工作、学生工作，招生工作的主要内容、进展情况、工作成效等，以及其他需要并适宜于上网公开发布的信息。
二、信息发布的方法与要求
1、各部门要有一名领导分管信息发布工作，并指定熟悉计算机专业知识的固定人员担任信息发布员，在校园网主页上建立Web网页，信息发布员负责本部门信息的收集、整理、制作、发布。
2、各部门必须经常检查并完善各自的网页内容，每月至少更新一次。每月1日至25日为更新网页时间，更新时将文档以办公自动化邮件方式发到网管室，并注明栏目或修改要求(有无更改都需发邮件说明)。
3、根据各部门的需要，可配备学生网管员指导网页的建设和维护工作。
4、各部门更新和上传的内容须保留备份，保存信息应遵循准确、完整、分类保存、便于查阅原则。
5、各部门主页的内容由各部门自行管理，要保证信息的准确性和时效性，避免重复和交叉现象。
6、信息上传需经校长室审核同意，并由部门保留原始记录。
7、涉及下列内容的信息必须经校长室批准后方可上网：
(1)关系学校改革和发展大局的信息；
(2)以学校名义对外发布的信息；
(3)向国际互联网的站点提供或发布的信息；
(4)学校文件、规章制度、校领导讲话等；
(5)其他学校的重要信息。
8、任何单位和个人不得利用校园网网页制作、复制、查阅和传播下列信息：
(1)煽动抗拒、破坏宪法和法律、行政法规实施的；
(2)煽动颠覆国家政权，推翻社会主义制度的；
(3)煽动分裂国家、破坏国家统一的；
(4)煽动民族仇恨、民族歧视，破坏民族团结的；
(5)捏造或者歪曲事实，散布谣言，扰乱社会秩序的；
(6)宣扬封建迷信、淫秽、色情、赌博、暴力、凶杀、恐怖，教唆犯罪的；
(7)公然侮辱他人或者捏造事实诽谤他人的；
(8)损害国家机关信誉的；
(9)其他违反宪法和法律、行政法规的。
9、网页的建设和维护工作将作为各部门的年终考核内容之一。学校将在每年年终进行网页制作总结评比，对优秀的网页和管理员进行表扬，并适当进行奖励。
三、违反管理制度，造成严重后果的，责任自负。
四、本管理制度如与上级的有关管理法规不符，以上级管理法规为准。
五、本管理制度解释权校长室。
校园信息发布系统 篇3
关键词：富互联网应用程序；RIA；Flex技术；航班信息发布
中图分类号：TP311.13
为了将空中交通管制部门掌握的航班信息与航空公司、机场、航空油料公司等部门之间实现共享，研制开发一套航班信息发布系统，为这些航空地面保障单位提供多方位的信息服务，就显得相当重要了。
系统的总体架构采用的是客户端/服务器（C/S）架构，这就引发了一个问题，软件分发不方便。如果客户端应用程序发生变化，维护部门不得不对每一个终端软件进行重装和升级。近些年来，随着Web技术的迅猛发展和富互联网应用（RIA）技术的兴起，使得Web应用程序能够实现类似于客户端应用程序的丰富的功能和快速的响应效果。同时Web应用程序维护方便，升级软件时只需要更新服务器端的Web应用，解决了多年来客户端应用难维护的问题。Flex是Adobe公司推出的新一代的开发工具，允许开发者构建和部署Flash平台上的RIA应用，其具备优秀的动画效果，不仅具有快速显示栅格图片的能力，也有强大的矢量数据绘制与交互能力[1]。本文探讨运用Flex技术将航班信息的动态效果显示在网页上，运用FLEX技术实现航班信息发布系统。
1 系统目标与设计
航班的飞行计划以及实时动态信息存储在空管部门的飞行信息处理系统、雷达数据处理系统中，因此我们可以基于浏览器的方式，采用FLEX设计框架以及Web Service技术，建立一套综合的航班信息发布系统，为机场管理部门、航空公司、航空配餐等民航单位提供一个获取和应用飞行计划动态信息的统一信息集成平台。
从安全方面、层次化方面和统一服务三个方面考虑，本系统采用三层体系架构：数据访问层，业务逻辑层，表现层。数据访问层的数据来源于空中交通管制部门的业务系统，包括航班动态信息、航班计划信息、飞行航线信息、航班停机位、用户信息等数据，存储于多个关系型数据库SQL SERVER 2010中。业务逻辑层采用基于.NET平台的Web Service服务实现业务数据的提取、分析、集成以及用户认证等功能。表现层采用Flex技术，实现体验丰富的、互动性强的网页效果。中间服务层通过把应用和数据隔离，所有的应用通过调用统一的Web Service服务获取数据，来构建灵活的系统，使得系统不会受到数据的物理位置的影响，也不会受到需要存取数据信息的应用个数的影响，这样就实现了系统之间的信息的集成。整个系统通过后台服务程序实时获取航班动态信息、航班计划信息、飞行航线信息、航班停机位、开车时间等业务信息，通过Flex技术开发的界面实现航班动态变化的信息显示，快捷的界面响应，提供通用的用户界面特性，如拖放，以及在线和离线操作能力。系统的总体架构如图1所示。
2 系统功能与实现
2.1 系统功能。本系统发布中南地区航班动态、航班计划，航班信息查询、提供关注的航班设置窗口，提供到港航班和变更航班的提示功能，提供航班加油提示功能。航班计划指航空公司向空管单位申请执行的航班计划，包括次日航班计划和航班时刻表。航班计划包括航班号、起飞降落机场、预计起飞降落时间、机型、机号等。航班动态指飞行计划在实际执行过程中的全程动态变化信息。航班动态包括航班变更信息、航班号、机号、机型、任务、起站、落站、预计起飞时间、预计到达时间、实际起飞时间、实际到达时间、停机位、是否延误，是否取消。
基于Flex的航班信息发布网站调用远程Web Service服务，向服务端发送数据调用请求，Web Service服务根据请求类型，对数据库的数据进行提取、分析、融合等处理，将处理后的数据包括航班动态、航班计划、航班历史、停机位信息、查询结果等数据发送到航班信息发布网站。当数据库中的航班信息有更新时，Web Service將最新更新的数据推送到航班信息发布网站，信息发布网站实时刷新数据显示，并提供航班的变更告、到达告警、加油告警等功能。用户可以选择所关注的航空公司，应用程序在提示窗口中根据用户的选择只提示用户所关注的航空公司的航班。
2.2 航班数据的获取和显示。Flex程序客户端代码通常由MXML和Action Script两部分组成。MXML是一种XML格式的标记语言，其作用是进行界面的描述；Action Script是一种面向对象编程语言[2]。航班数据通过调用远程Web Service服务获取得到。Flex有两种方式可以调用Web服务。一种是基于标签。在标记语言MXML中，Flex提供了
为了更好地实现Flex应用与基于.NET的Web服务的交互，Web服务返回的数据集合采用的是泛型集合类型List，而未采用DataTable。虽然Flex是可以绑定到DataTable类型的数据并通过数据显示控件显示出来的，但是不足有二点，一是速度比较慢，因为要经过复杂的序列化和反序列化处理，二是返回的数据的可操作性差，在客户端获取数据后，还需要对数据进行更改、排序、过滤等操作。DataTable是个.NET自有的对象类型，在Flex中没有对应的数据类型，无法实现进一步的操作。在Flex中数据保存在数组集合ArrayCollection中可以实现更改、排序等操作，而ArrayCollection正好可以与.NET中的泛性集合List对应，在接收数据时可转换为ArrayCollection数据集合，这样就能够顺利获取数据并进行进一步的操作了。ArrayCollection作为数据提供者有多个优势：第一，可以提供数据的排序、过滤、查找等功能；第二，当数据内容发生更改时，更改会立刻反映到所有绑定到它的控件中；第三，作为显示控件的数据源，数据保存在本地的内存中，刷新和排序的速度非常快，比普通页面需要连到Web服务器刷新要快很多。在数据显示前，对航班数据先按照预计到达时间排序，作为数据网格组件的数据源，并且声明为可动态绑定的，用[Bindable]声明。当数据源的数据变化了，网格组件显示的数据也会动态实时刷新了。程序的显示界面如图2：
构建共享对象保存用户的个性化设置。航班信息发布的应用中，程序需要永久保存用户设置的个性化数据，例如用户关注的航班公司，用户关注的航班，在航班变更提示窗口中需要根据关注的航班进行提示。Adobe Flash提供了共享对象SharedObject类来保存客户端的数据，共享对象与Cookie类似，但是功能更强大，数据不仅可以永久保存，还能保存更加复杂的数据结构。正好满足了航班信息发布网站保存用户的特定设置的需求，以实现更丰富更个性化的用户体验。
Flash的本地共享对象是一些可由用户访问的站点在计算机上创建的数据文件。通过ActionScript脚本来编写代码，网站可以将数据作为共享对象保存在用户的机器上，用户退出浏览器时，共享对象的值就会保存在本地文件中。当用户下次访问该网站时，它将加载该信息，从而使终端用户拥有一种更加个性化的体验。用户在选择界面选择关注的航空公司集合，随后航空公司名称和航空公司的二字码数据集保存在类型为ArrayCollection的复合型数组中。构建一个遍历数组的for循环，在循环里，用数组的元素来填写共享对象数组，这样就实现了将复杂的二维数据集保存到共享对象中了。当用户退出网站时，Flash Player自动将共享对象写入磁盘默认路径上一个后缀名为.sol文件中。也可以通过调用共享对象的fulsh（）方法，立即将数据写入磁盘。在用户下一次运行信息服务网站时，通过调用SharedObject类的getLocal（）方法来读取已经保存的后缀名为.sol的文件。最后，构建一个for循环来遍历保存在共享对象中的数据，将结果保存到类型为ArrayCollection的数组中，网页上的表格显示控件绑定數组，将航空公司的信息显示出来，便完成了个性化设置的数据加载的功能。
3 结束语
信息技术的迅猛发展为基于Web方式的应用注入了活力。Flex技术与传统Web技术相比，具有完整的浏览器可移植性，丰富的界面体验、更少的网络流量、更快捷的操作响应等优势。在我国民航事业的飞速发展形势下，航班信息的发布是民航信息化不可缺少的重要组成部分，基于Flex技术的航班信息发布系统提供实时准确的信息，丰富的功能和用户体验，具有易部署、易维护、跨平台的特定，符合民航建立高效信息服务平台的需求。目前该系统已在中南地区空管系统内运行，为航班信息服务提供了稳定高效的平台。
参考文献：
[1]（美）Jeff Tapper，Micael Labriola，Matthew Boles，James Talbot.杨博，杜宏，译.Flex 3权威指南[M].北京：人民邮电出版社，2009.
[2]彭新，刘永伟，叶长春.基于Flex和.NET开发RIA[D].武汉：中国地质大学，2010.
作者简介：李娟（1976-），女，浙江苍南人，工程师，本科，研究方向：航班信息系统应用与开发。
交通信息短信发布系统研发 篇4
交通信息服务系统就是根据从交通数据采集设施采集到的原始数据,如道路交通流量、车速等参数,利用各种交通模型进行综合分析和处理,通过网络终端、手持终端、车载终端等各种手段向道路使用者提供适当的交通信息,来影响出行者对出行路线、出行方式的选择,以疏导交通流,保持最佳通行能力及提高交通安全度,从而最终提高社会与经济效益[1]。交通信息发布方式,主要有网站[2]、诱导屏、车载导航设备[3,4]和广播[5]等。短消息服务以其价格低廉、交互方便、图文并茂的方式,越来越引起公众的重视。一般而言,利用SMS平台进行信息服务,可有如下2种方式:①采取SP(service provider,SP)服务的方式;②使用MODEM模块,即借助MODEM模块实现点到点的服务。由于牵涉到不均衡流量计费的问题,后1种方式适用于规模小、非常发性等特定场合;而前1种方式由于得到通信公司的特批,享受通信优惠,故较为常用。在前1种方式中,根据SP和信息提供方(information provider,IP)是否一体,又可以采取如下2种方式:①SP与IP各自独立,IP借助SP的平台进行信息中转,IP提供信息,SP提供服务,SP仅作为连接IP和通信公司之间通信的桥梁;②SP和IP集于一体。鉴于目前申请SP资质规定严格,且对仅以信息服务为主的用户而言,采取后1种,即与SP合作的方式,是首选方式。
1 系统框架分析及设计
SP端系统功能主要由相应的SP提供商开发完成,且对成熟的SP而言,功能模块基本具备,只需根据通信协议进行代码改进,所以此文所指系统平台主要是指拥有服务信息一方而言,且主要是指与SP的数据交互。
交通信息服务方式主要分为2类,①即时信息查询;②订制信息查询,2类信息交互流程如图1～3所示。
图1～3中,箭头和数字顺序清晰表明了数据交互的上下行关系,在此不再赘述。
2 系统功能
根据系统框架的分析,设计了系统的主要功能模块,如图4所示,各模块描述如下。
2.1 即时查询模块
对应图1,根据用户输入的业务代码及查询内容,经通信服务器解析后,从信息服务器中检索出结果,及时回复给用户,在网络通信畅通情况下,一般响应时间小于10 s。即时查询信息包括(以济南市为研究对象):公交车次信息,公交换乘信息,交通违章信息,客运信息,路况信息等。
2.2 信息订制/注销
对应图2,该模块根据用户发送的订制业务代码及订制内容,响应用户的订制请求,并返回订制/注销成功与否的提示信息。主要包括道路状态信息的订制。
2.3 订制信息轮询发送
对应图3,该模块定时轮询订制用户表中的有效用户,发送其订制类型的信息内容。
2.4 查询信息存储
该模块存储即时查询记录、订制请求记录和订制轮询记录的相关信息,以作统计分析用。系统所用数据库为Oracle10g。
3 关键技术分析
该系统以VS.net2005为开发平台,采用Asp.Net技术,C#语言开发。系统开发中,主要涉及如下关键技术。
3.1 基于Http的通信协议
该系统根据实际需要,采取了“1个通信协议,2种通信机制”的解决方案,即统一的数据通信协议,即时查询通信机制和订制轮询通信机制。
3.1.1 通信协议
通信协议采用Http协议[6],其构成为“业务代码+查询内容”,发送到106288581为即时查询,发送到10628858为订制。如用户编辑“5K51”到“106288581”表示查询K51路公交车次路线信息;编辑“1科院路到大观园”表示查询从“科院路”到“大观园”的换乘公交信息等。
3.1.2 数据获取
中心监听SP的请求,根据请求的不同类别,调用不同的功能模块,获取查询结果,数据获取示例如下:
3.1.3 信息回复
1) 即时查询。
对即时查询而言,是“Web 与Web”之间的数据交互,需当时进行回复,用Response.Write()及时返回查询结果。
2) 轮询发送。
轮询模式是“应用程序与Web应用程序”的数据交互,为非即时数据交互,采用post的方式进行数据传递。示例如下:
3.2 基于存储过程的信息检索接口
为保证数据访问接口的独立性,将信息检索函数单独封装,形成.dll文件,并通过在工程中引用相应的文件名,调用接口函数。该动态类库中的函数又通过调用数据库中的存储过程实现记录的插入和信息的检索。数据库存储过程主要包括订制信息发送存储、订制轮询用户检索、用户订制及状态修改、道路交通状态和即时查询存储。数据库函数主要包括公交零次换乘、1次换乘、统一换乘和返回线路查询结果。
3.3 重复订制/注销的识别
对已经订制/注销的用户,通信公司(如移动)已经进行了过滤处理,如果用户出现了重复操作,通信公司的系统平台会自动进行回复,故在此系统中可以不必考虑此问题。
3.4 冗余检索信息的处理
主要指2类信息冗余:①回复短信字数过多,一般而言1条短信字数不超过70 B,在超过该数目的情况下,借助长度截取函数,进行相应处理。如K51路公交站点查询的记录,由于回复结果过长,处理后的查询结果为“环山小区,环山路,大众日报社宿舍、科院路、山师东路、历山路南口、千佛山、舜耕路、青年东路、省中医、泉城广场、趵突泉东门、共青团路……经二纬三”。②用户请求的信息类别或格式有误。针对此种情况,采取2级过滤分析机制,SP服务器首先判别信息类型是否正确,将正确的信息发送给我方服务器,然后,此系统针对解析后的数据,判别对应类型的信息请求格式是否正确,不正确的返回错误提示。
经反复测验,上述2种判别机制能有效拦截非法信息查询请求。
3.5 外网IP动态映射
由于此系统服务器采用内网IP,在绑定到外网IP时,存在公网IP动态变化的情况,导致SP无法直接用IP识别是否为我方服务器,因此,采用密码替代IP的技术,通过识别协议密码来判断是否为我方服务器。
3.6 交通数据质量控制技术
交通数据质量控制技术主要指的是丢失数据的恢复、错误数据的修正和不精确数据的校正,该方面的研究内容已在其他文章中阐述[7],且有大量学者对此进行了研究[8],在此不再赘述。值得指出的是,从应用角度看,交通数据采集硬件系统的稳定性要比后期的算法控制相对重要[9]。
3.7 道路交通状态判别技术
道路交通状态判别是识别道路交通状态的一种技术,是提供交通信息服务的核心基础技术之一。国内相关学者在此方向已经进行了大量研究[8]。该系统在借鉴前人研究成果的基础上,主要采用了改进的模糊-神经网络算法,以路段平均车速和路口交通流量为主要参数进行道路交通状态的识别[10],实用效果较好。
4 应用实例
4.1 即时查询应用实例
手机编辑短信,编辑内容如图5所示;返回查询结果,如图6所示。
4.2 订制应用实例
编辑订制信息,如图7所示;返回订制结果如图8所示。
4.3 订制轮询发送实例
轮询发送界面,如图9所示;订制信息接收结果,如图10所示。
5 结束语
目前,以济南市为应用背景的上述系统,已经处于试运行阶段,山东省境内的移动用户可根据代码发送相关命令享受相应交通信息的服务,便捷出行。另外,该系统也具有的良好可移植性,可根据实际需求进行业务的扩展。
摘要：为实现交通信息增值服务,提出了基于服务提供商(SP)的交通信息SMS发布系统。叙述了交通信息服务背景和交通信息发布的几种主要方式,并通过分析系统的总体框架,设计了交通信息服务的数据流程和系统的4个基本功能模块,分析了系统开发过程中的关键技术,并给出了1个系统应用实例。
关键词：智能交通,交通信息服务,服务提供商,短消息
参考文献
[1]童梅,吴志周,杨晓光.基于网格技术的交通信息服务平台的设计与实现[J].计算机工程与应用,2007,43(25):188-191
[2]张燕,蔡伯银.城市交通信息发布系统的设计与实现[J].北京交通大学学报,2007,31(5):53-57
[3]郭继孚,温慧敏,高永.北京市动态交通信息服务系统建设及制约因素[J].城市交通,2008,6(2):12-15,28
[4]翁剑成.面向车载导航应用的短时交通预测关键技术研究[D].北京:北京工业大学,2007
[5]张丽,郭莉,张蓉.基于.net的交通信息系统的研究与实现[J].计算机与信息技术,2007(9):93-95
[6]电脑编程技巧与维护杂志社.C#编程技巧典型案例解析[M].北京:中国电力出版社,2005
[7]张立东,王英龙,赵建玉,等.RM在ITS数据恢复中的应用研究[J].计算技术与自动化(增刊),2006,25(4):210-212
[8]姜桂艳.道路交通状态判别技术与应用[M].北京:人民交通出版社,2004
[9]张立东,潘景山,张赞军,等.交通数据质量控制的可靠度理论分析[CD].北京:中国科技论文在线精品论文,2008,1(2):174-177
信息系统变更和发布管理办法 篇5
第一章 总 则
第一条 目的：本管理办法规定了XX银行（以下简称“我行”）信息系统的变更和发布管理，变更和发布管理作业操作流程和控制要点，确保变更需求的受理符合业务的优先需要，并使变更和发布过程规范化，控制变更对银行业务和已投产系统安全运行的不利影响。达到降低信息系统变更和发布风险的目的。保障信息系统的安全稳定运行，特制定本管理办法。
第二条 第三条 第四条(一)目。
(二)生产业务系统：指我行从事金融服务的应用网络系统，包括综合业务系统、国依据：本管理办法根据《XX银行信息安全管理策略》制订。范围：本管理办法适用于我行信息系统变更和发布管理。定义
软件产品：泛指信息技术开发的生产业务系统和管理信息系统等应用软件项际业务系统、支付系统等银行对外营业的各种核心业务系统。
(三)管理信息系统：指我行信息管理的计算机网络系统，具体指OA办公系统、信贷管理、报表系统等用来进行内部管理的应用软件系统。
(四)第五条(五)遵循原则 业务部门：指我行总部相关业务部门。
监督制约原则：针对信息系统变更和发布管理工作中各个环节，建立相应的监督检查机制。
(六)计划性原则：信息系统发布应纳入每年计算机应用计划，确保全行计算机系统资源、应用环境、维护力量、操作技能能满足系统安全、可靠运行的要求。
(七)(八)可行性原则：具有普遍适用性和可操作性。风险控制原则：
若为新项目或新业务功能变更和发布，需进行以下风险分析： 1.备份机建设情况；
2.应用系统投产后的集中监控方案； 3.生产数据备份方案； 4.程序及系统备份方案；
5.数据库建库/建表/建索引方式等； 6.对其他系统的影响。
第二章 组织与管理
第六条(一)职责划分
需求部门：
1.提出需求，并确认《用户需求说明书》；
2.用户测试阶段确认用户测试计划、记录用户测试问题、确认用户测试报告； 3.接受用户培训并提出反馈。(二)科技信息部安全科：
1.在需求阶段审阅和提出IT风险控制、IT合规和IT稽核方面的要求，在项目开发阶段对有关IT风险控制、IT合规和IT稽核方面的测试结果进行审阅；
2.在项目实施后审阅阶段对有关IT风险控制、IT合规和IT稽核要求的实施效果进行审阅。
(三)科技信息部运行维护中心：
1.负责受理所有变更和发布需求，会同IT其他相关部门（IT软件开发中心、安全科等）对变更和发布需求进行评估，并将评估意见向IT部门领导、业务部门领导汇报沟通，获取所需的授权；
2.在详细设计阶段审阅和提出网络、硬件、操作系统和数据库等方面的配置和容量要求；
3.在设计与编程阶段提供网络、硬件、操作系统和数据库的参数配置； 4.在测试阶段配合项目组设立网络、硬件、操作系统和数据库环境；
5.配合项目组对系统进行联合测试，把信息系统版本软件、相关配置文件、标准数据和相关文档提供给测试评估中心；
6.将信息系统发布到使用部门，系统上线时会同项目组搭建生产系统并进行程序移植，组织定期对变更和发布效果进行分析和总结。
7.接收管理和备份软件开发中心提供的源程序、相关标准数据、配置文件、相关文档；(四)科技信息部软件开发中心：
1.负责设计、编程、纠错和开发质量控制，编制《系统设计规格书》；
2.落实项目管理制度和业务操作手册的编制工作，参加制定上线方案制定，编制《上线实施计划》；
3.负责系统切换上线的技术支持工作；
4.负责项目验收资料整理汇总，配合项目验收工作。(五)科技信息部测试评估中心：
1.负责对需要测试评估的软件进行分析测试； 2.负责提交测试分析报告。
第三章 信息系统变更
第七条 信息系统变更，指由于新增信息系统功能、系统逻辑改变、系统错误修正、系统补丁安装及版本更新、系统配置修改及业务参数修改等原因，而对已投产系统进行局部改变的一切活动。已投产系统变更需求主要来源于以下几种情况：
(一)由于业务快速发展，业务部门对现有已投产系统的功能或设置进行变更或通过新增功能来满足需求；
(二)用户在使用过程中发生的一些操作错误，或技术人员、监控管理软件自动发现的故障或事件，需要通过安装程序补丁或修改配置等操作进行修改；(三)厂商定期发布的系统补丁，涉及系统的功能、性能、安全漏洞，需要在已投产系统中进行安装；
(四)由于系统容量扩充或与已投产系统存在数据交换或数据共享的其他已投产系统发生变化后引发的已投产系统变更。
第八条 信息系统变更的提出，必须由申请部门（用户部门或IT部门）填写《已投产系统变更流程单》（附件1）第一部分，申请信息。在申请信息填写阶段的主要工作内容包括：
(一)申请人需选择变更类型；(二)描述变更内容和目的；
(三)是否存在其他措施满足变更需求；
(四)如不实施变更可能对客户、合规、外部利益相关方、内部管理和操作、安全控制、系统可用性和数据准确性的影响；
(五)选择变更的急迫性。
第九条 申请部门主管审批签字后提交IT运行维护中心进行处理。
第十条 IT运行维护中心收到变更申请后，和变更申请部门充分沟通，理解变更需求的合理性，审阅变更的影响和急迫性，并会同IT其他相关部门（IT软件开发中心、安全科等）对可行的变更实施方案和变更对已投产系统的影响做出评估，最终形成建议的变更日期，填写至《已投产系统变更流程单》第二部分，变更需求评估信息，交IT运行维护中心负责人进行审批。
第十一条 IT运行维护中心组织变更需求评估时，应充分考虑系统是否已存在满足变更需求的功能或设置；是否存在其他操作手段，能达到同样的变更需求效果。
第十二条 IT运行维护中心组织变更需求评估时，了解实施变更：
(一)是否需要进行IT开发，以及IT开发的工时；
(二)是否需要进行操作系统、数据库系统、中间件、硬件和网络的变更；(三)是否需要进行后台数据变更；(四)是否存在信息安全控制的考虑因素；
(五)结合IT部门现有的IT资源，统筹安排变更实施时间表；(六)实施相关变更时，可能导致的业务中断或客户服务水平下降。
第十三条 综合对变更需求合理性的评估和变更实施影响的评估，IT运行维护中心在《已投产系统变更流程单》的第二部分提出变更的建议日期，并进行资源协调。在IT运行维护中心负责人进行审批后，通知相关部门：(一)如不建议实施变更，则向变更申请部门说明理由；
(二)如建议实施变更，则告知建议变更的时间及对客户服务和内部操作的影响，要求变更申请部门和相关部门进行准备；
(三)如变更规模超过《XX银行IT项目管理指引》规定的项目受理标准，则依据该指引有关规定执行。
第十四条 对涉及软件开发的需求变更，参照《XX银行IT开发方法指引》的要求执行。
第十五条 对不涉及软件开发的需求变更，IT运行维护中心根据需要，提交IT测试评估中心相关人员负责制定变更的测试步骤，落实测试人员在测试环境中对变更进行测试，测试人员对测试结果进行记录并签字确认。
第十六条 信息安全人员对变更进行上线前审阅，确保系统变更过程中的系统安全。信息安全人员完成上线前审阅后，IT运行维护中心进行上线处理。信息安全人员根据变更的风险程度，进行上线后审阅，确保达到变更目标。
第十七条 为控制已投产系统的变更对客户服务和业务操作带来的影响，确保生产环境的完整性和可靠性，IT部门应制定一系列控制IT变更的策略和制度，严格控制变更的规模、涉及面及信息安全风险。包括：
(一)IT运行维护中心负责人每周对集中的变更工作计划进行审阅，确保充分有效的IT技术资源或系统供应商/开发商技术资源，保证变更的有序进行；
(二)除非是需要立即实施的特急变更，IT运行维护中心应选择非业务繁忙时间，如凌晨、周末或公众假期进行变更上线；
(三)IT运行维护中心进行周密计划，包括制定意外应急措施；(四)分离已投产系统与开发或测试系统的管理职责；
(五)保证已投产系统和开发或者测试系统相分离，禁止开发人员在未经授权的情况下进入已投产系统；
(六)只有在得到管理层批准执行紧急修复任务时，开发人员才能访问已投产系统，所有的紧急修复活动都应立即进行记录和审核；
(七)开发人员对已投产系统进行变更必须经过严格的审批和控制；开发人员访问已投产系统时必须由IT运行维护中心系统管理员对其访问进行监督和记录，并在访问结束后系统管理员及时禁用或删除开发人员在已投产系统中使用的账号；(八)对已投产系统进行变更必须经过严格的授权之后才能进行操作实施，操作实施过程必须受到严格监控。
第十八条 变更实施上线前需进行用户测试，并在变更上线后由变更申请部门负责人对变更进行签字确认。
第十九条 对于上线过程可能导致业务暂时中断或导致业务操作发生重大变化的IT变更，IT运行维护中心必须在上线前以书面方式告知相关业务部门(至少包括行长办公室和客户服务中心)影响的业务范围和时间，并提供相关技术支持。
第二十条 IT变更上线执行的工作内容和相关要求参照《XX银行IT开发方法指引》中对上线的要求和描述。
第二十一条 变更计划与步骤、回退计划与步骤、IT测试步骤与结果、信息安全审阅意见、用户测试确认等变更实施信息记录在《已投产系统变更流程单》第三部分，变更计划和测试接受信息。IT运行维护中心负责人负责对变更实施信息进行审阅。
第二十二条
急变更是指在某些紧急情况下，对已投产系统需要在没有完整的系统测试，或无法完成正式审批流程的情况下进行的变更。如：因系统缺陷需要对已投产系统进行立即修补，或突发的监管要求对已投产系统进行紧急变更（如利率的紧急调整）。
第二十三条 紧急变更应由变更申请部门相关负责人提出，获得IT运行维护中心负责人的审批或者授权方可进行。可以接受的审批方式或者授权是IT运行维护中心负责人的口头授权或邮件授权等，并在紧急变更实施之后，补足相应的《已投产系统变更流程单》并由相关负责人员签字，进行备案。
第二十四条
在紧急变更实施前，须进行测试。紧急变更前未能实现测试的，须事后补足相应的测试及测试文档，并由相关测试人员签字。
第二十五条
紧急变更应记录日志，由IT运行维护中心和变更申请部门共同审核和签字确认，并进行程序和数据备份，以便必要时可以恢复到原来的程序版本和数据版本。
第二十六条
变更实施后，IT运行维护中心组织IT其他相关部门（IT软件开发中心、安全科等）对变更实施的结果进行定期集中评估，主要应从以下几个方面对变更实施的情况进行总结：
(一)(二)(三)(四)施；
(五)变更回退的数量及其原因。
《已投产系统变更流程单》填写完整后由IT运行维护中心进行整变更是否达到预期目标； 变更是否存在负面影响；
一段时期内实施的变更数量（包括总量以及按变更类型分类的数量）； 变更以及变更请求的理由清单和类型分析、以及未来控制变更数量的跟进措第二十七条
理，并由IT部门负责人安排人员进行定期审阅，最终交IT综合科归档。
第四章 软件上线流程和控制要求
第二十八条 上线受理(一)项目开发和测试工作完成后，项目组提交《软件产品上线申请表》附件2和相关业务部门负责人签署意见的《用户测试验收报告》给项目管理科进行审核。
(二)项目管理科审核通过后，将上线申请材料交科技信息部安全科及科技信息部负责人审核。审核后在上线申请书上写明上线意见并签名盖章。
第二十九条(一)上线准备
项目组提交通过审核的上线材料给运行维护中心。运行维护中心配合项目组制定上线实施计划，项目经理提交部门负责人进行审批，上线实施计划的主要内容包括：
1.历史数据、配置参数、应用程序等的备份方案
2.上线环境的搭建（项目经理协调运行中心搭建生产环境）
3.上线执行的内容和步骤、各项工作任务责任人、人员组织和具体时间安排等 4.上线回退计划
5.确定上线时可能出现的问题及解决方案(二)项目组配合业务主管部门编写项目上线后的业务管理办法和操作细则，完成相应的培训工作。对新项目，要求相关业务部门提供相关核算办法、管理办法、下发文件。
(三)项目组向系统应用维护人员提供维护手册；向后台操作人员提供操作手册，并完成相应的培训工作。
(四)项目组提交《软件版本管理表》给版本管理部门，完成上线版本的制作。
第三十条
上线与试运行
系统切换发布按照上线实施计划步骤进行；
(一)安全科负责检查项目的安全性，是否符合国家和上级单位的有关安全规定；(二)生产系统版本管理员在程序正式迁移至主机之前，首先完成生产系统的备份，对上线所涉及的程序进行新老版本比对，同时根据上线步骤所定的时点完成程序的编译，制作新版本，并使新程序生效；
(三)系统管理管理员根据上线步骤所定的时点，负责对数据库进行新增、修改、删除等维护工作；(四)系统管理员根据上线步骤所定的时点，提供所需的系统资源、定义系统参数、定义各类文件；并做好基础资料建档；
(五)网络通讯技术人员根据上线步骤所定的时点，负责网络通讯有关参数的设置，将通讯接口切换到生产系统；并做好基础资料建档；
(六)前台版本管理员根据上线步骤所定的时点，负责下发新的前台版本至各支行、网点，并跟踪各支行、网点的版本安装和生效情况；
(七)前置机系统技术人员根据上线步骤所定的时点，负责变更前置机系统的程序版本、数据库信息等，并负责与主机的交易联动；
(八)项目建设部门、各相关业务部门配合系统切换上线的具体实施；
(九)对于只涉及主机日终批处理程序变更的应用项目，在上线当日及相应关键日期（如月终、结息日等）的批处理时段，批处理技术人员应提供技术支持，并负责跟踪试运行的结果；
(十)对于只涉及前台版本更新的应用项目，在上线后下一个营业日及关键日期（如下一个对公营业日等）的联机时段，前台技术人员负责跟踪试运行的结果；
(十一)对于只涉及主机联机交易变更的应用项目，在上线后下一个营业日及关键日期的联机时段，相关主机技术人员应提供技术支持，并负责跟踪试运行的结果；
(十二)对于同时涉及主机联机交易、前台版本和/或前置机版本改动的应用项目，在上线后下一个营业日及关键日期的联机时段，相关主机技术人员、前台技术人员、主机接口术人员及前置机系统技术人员应提供技术支持，并负责跟踪试运行的结果；
(十三)(十四)试运行中发现问题时通知项目组技术人员对系统进行修改；
系统上线后，项目组还需要在上线后为用户提供一段时间的上线后支持服务，对系统运行状态进行监控，保证系统在使用后能够有一个稳定、良好的状态。在此期间，运行维护中心在项目组的指导下执行系统的日常维护和批处理。
第三十一条 上线运行(一)项目系统上线试运行3个月以后，根据试运行情况，项目组提交项目正式上线验收申请报告；
(二)(三)科技信息部审核并确认验收报告及相关项目资料后，牵头组织验收； 经验收合格后的项目转正式运行，运行维护管理由运行维护中心按《IT运行维护指引》要求进行管理。
第五章 系统发布流程和控制要点
第三十二条
系统发布申请
系统项目组实施和测试工作完成后，项目组提交《系统发布申请表》（附件4）和相关业务部门负责人签署意见的《系统测试验收报告》给项目管理科进行审核。项目管理科审核通过后，将系统申请材料交科技信息部安全科及科技信息部负责人审核。审核后在发布申请书上写明意见并签名盖章。
第三十三条
系统发布准备(一)项目组提交通过审核的发布材料给运行维护中心。运行维护中心配合项目组制定系统发布计划，项目经理提交部门负责人进行审批，发布计划的主要内容包括：
1.所涉及系统的历史数据、配置参数、应用程序等的备份方案；
2.系统发布执行的内容和步骤、各项工作任务责任人、人员组织和具体时间安排等； 3.回退计划；
4.确定发布时可能出现的问题及解决方案；(二)项目组配合业务主管部门编写系统发布后的的系统管理办法和操作细则，完成相应的培训工作。
(三)项目组向系统维护人员提供维护手册；向操作人员提供操作手册，并完成相应的培训工作。
第三十四条
系统发布及试运行
(一)系统更新或者发布按照发布实施计划步骤进行；(二)科技信息部安全科负责检查项目系统的安全性，是否符合国家和上级单位的有关安全规定；
(三)运行维护中心系统管理员首先完成相关系统的数据或配置等备份；
(四)运行维护中心网络管理员根据发布计划所定的时点，负责涉及系统的网络通讯有关参数的设置，将通讯接口切换到发布系统；并做好基础资料建档；
(五)项目建设部门、各相关业务部门配合系统发布及运行的具体实施；(六)运行维护中心在试运行期间中发现问题时通知该系统项目组技术人员对系统涉及的产品进行修改；
(七)系统发布后，项目组还需要在发布后为用户提供一段时间的支持服务，配合运行维护中心人员对系统运行状态进行监控，保证系统在使用后能够有一个稳定、良好的状态。
第三十五条 系统发布运行(一)申请报告；
(二)(三)科技信息部审核并确认验收报告及相关项目资料后，牵头组织验收； 经验收合格后的系统转正式运行，运行维护管理由运行维护中心按《IT运行维系统发布试运行3个月以后，根据试运行情况，系统项目组提交项目正式验收护指引》要求进行管理。
第六章 检查监督
第三十六条 检察监督
(一)科技信息部版本管理员在系统切换发布前对系统切换发布的版本进行检查控制；
(二)科技信息部系统管理员在系统更变和发布前对系统进行检查控制；(三)科技信息部每季度对项目文档的完整性、规范性进行检查监督；(四)科技信息部安全科至少每季度进行一次检查。
第七章 附 则 第三十七条 第三十八条 本管理办法由科技信息部负责解释和修订。
企业信用信息发布系统设计构想 篇6
企业是市场经济活动的主体之一, 是信用信息的最大需求者, 也是信用信息的主要提供者。企业信用信息是企业在与消费者之间、与其他企业之间 (主要涉及赊销、产品质量、供货时间等) 、与银行之间 (主要包括资金信用、企业的偿债能力) 、与政府之间 (主要包括依法纳税、诚实经营等) 的交往过程中产生的。企业的信用活动是影响市场秩序的重要因素, 也是政府部门监管的主要对象。
为了实现对企业信用信息的有效管理, 在全社会建立起守信激励失信惩戒的机制, 为此, 将依托互联网和全省公共信用信息平台, 建立全省企业信用信息发布系统, 将征集到的来自政府部门、社会组织等的企业信用信息进行充分共享, 加强政府各职能部门对企业的有效监管, 向社会公众提供一站式、全方位的企业信用信息发布、查询及其他相关服务, 向社会公开发布企业诚信和失信信息。
二、系统设计的原则
1) 在系统建设的规划阶段, 应该尽可能采纳和共享已有的各种信息资源 (国家电子政务外网等) , 通过合理规划进行整合, 避免重复建设, 节省经济开支。
2) 企业信用信息系统的数据库包含了大量的企业信息资源, 具有十分重要的经济价值。因此, 系统的开发和运维的全过程中必须要贯彻安全性原则, 注重系统本身防御外部攻击的能力, 提高数据传输的安全性。确保信息披露符合相关的保密规范标准, 具有较高的安全保密性、抗病毒能力、查错纠错能力等。
3) 企业信用信息系统应当具备良好的可靠性, 关键设备和部件应当有冗余配置, 同时需建立各种故障的快速恢复机制, 确保系统能够实现7×24小时正常运转。
4) 在规划和设计系统时应当引入当前该领域较为成熟的理念和模型, 旨在建立一个集性能、外观、可用性、可扩展性、易用性于一体的系统架构。
三、系统所采用的关键技术
1) 利用Portal平台实现个性化定制和应用集成。企业信用信息发布系统的用户涉及面广泛, 包括政府部门, 社会组织, 商业银行、企业, 社会公众等多种目标群体, 因此要充分考虑不同用户的个性化需求, 提高操作的便捷性以及服务群体的满意度。为此, 考虑将企业信用信息发布系统建立在Portal平台基础之上, 即基于B/S结构的个性化平台。使用统一入口和接入平台, 提供单点登录、个性化与交互管理、应用集成及内容管理等功能, 并通过基于角色的单一的界面提供给用户。基于LDAP实现分布式管理, 管理不同地域、不同网段的机构资源、应用资源等, 实现统一授权, 统一注册, 统一管理。同时, 系统提供统一的配置工具、部署工具和监视工具, 以方便系统管理员的维护工作。
2) 系统采用信息总线结构。系统的数据采集和整合采用信息总线结构。在信息总线基础上, 各类应用系统被抽象为可插拔的组件, 相互之间通过消息机制通讯和传递信息, 从而实现应用系统跨硬件平台、软件平台、跨越空间地域的交互。根据实际业务的需要, 任何一个系统发生变化时 (被输入了新信息、删除或更改了旧信息) , 都会通过信息总线将变化以消息的形式传播出去。
3) 基于智能报表引擎技术实现自定义查询、统计分析功能。基于应用支撑层的智能报表引擎, 充分利用中心数据库中的数据, 使用数据分析、整合和展现功能, 根据需要对数据进行分类、统计和汇总, 形成可供政府部门和企业用户决策参考的信用信息。在该系统中, 可根据企业信用分析的实际需要, 预先定义在分析中经常会用到的几种报表的模板。此外, 用户还可根据自身需要, 定制信息目录和报表模板, 将数据以用户所熟悉的业务领域术语表达出来。
四、系统的主要功能模块
1) 信用查询功能。信用查询功能是企业信用信息发布系统最为核心的功能, 主要面向社会公众、政府部门、商业银行、企业等社会群体提供企业信用信息查询, 根据用户角色的不同, 分别采用互联网查询和局域网查询两种模式。互联网查询:社会公众可通过登陆互联网查询企业可公开的信用信息。局域网查询:是指通过政务网络、专线接入等方式, 查询企业信用信息, 主要针对政府部门和特许用户 (签订相关协议的社会机构或商业银行) , 该类用户可以查询除企业财务信息之外的所有相关企业信息, 涉及到企业财务信息的, 需要获得被查询企业的许可授权方可进行查询。同时, 查询的设计上要求能按各种条件组合 (与、或关系) 进行, 能进行模糊查询、精确查询和高级筛选功能, 使用搜索引擎。
2) 统计分析功能。对信用信息进行统计可以系统的积累资料, 使统计分析具有可比性, 进而可以研究全省企业信用情况的发展规律, 为政府部门制定各项政策提供进行有效监管提供可靠的依据。统计结果可以报表、饼图、柱状图、折线图、区域图、雷达图等多种方式进行展示。信用基础信息统计可以分为以下类别:按企业申请、变更、注销登记的基本情况进行统计分析, 从而反映企业登记主管机关工作的成效, 企业发展的现状。按行业分类进行统计分析, 可以反映我省企业在各行各业的分布情况, 了解各行业企业的发展状况和在整个经济运行中所占比重。按地区分布进行统计分析, 可以反映我省各个地区企业发展的情况, 了解企业的地区分布疏密情况。按经济性质分类进行统计分析, 可以反映企业的所有制结构, 了解不同所有制企业的发展状况和所占比重。统计企业的从业人员, 可以了解各类企业单位中劳动力的分布情况, 也可以反映企业的规模、效益等。按企业注册资金进行统计, 可以反映企业的规模、经营状况等情况。
3) 失信投诉功能。失信投诉平台主要面向社会公众, 受理相关公共部门权限范围内的投诉事项。社会公众如发现省内的组织机构、个体工商户在生产经营过程中存在制假售价、环境污染、发布虚假广告, 招投标违规、不履行劳动合同拖欠工资、商业贿赂等领域的失信行为, 可通过失信投诉平台进行投诉。投诉受理采用统一受理、归口处理的原则, 公共信用信息中心将收到的信息转交相关的责任部门, 由相应的行政主管部门具体负责予以核实、修正和处理, 并将处理结果反馈给投诉主体, 同时对可以公开的处理信息予以公开。
同步科技综合信息发布系统受关注 篇7
在BIRTV2012上, 同步推出的综合信息发布系统广受关注。该系统是集网络视频、电视接收、媒体播放、字幕新闻以及图文信息为一体, 提供基于“视觉展现”为目标的信息发布解决方案, 主要由信息推送端 (服务器端) 和分布在各处的信息接收端 (机顶盒) 构成。系统中所有需要发布的媒体数据, 包括视频、照片、文字以及其他有关的内容, 在服务器端按照需要的时间顺序进行编排, 制作成播出列表, 以网络广播或网络组播的方式推送到每一个接收的终端, 由接收端将这些分离的信息, 按照在服务器端所指定的播出版式, 合成最终的显示内容, 显示在屏幕上, 供用户观看。
据悉, 综合信息发布系统可以广泛地应用于会议展览、机场、学校、医院、机关单位、购物中心、新闻发布现场、办公大楼等多种场所, 为受众提供全新的信息发布以及展示手段。目前, 该系统已经在清华大学百年校庆、汇文中学140周年校庆、中国国际乐器展览会、中国人民解放军总医院展示、北京科技活动周等活动宣传中发挥了重要的作用。
校园信息发布系统 篇8
1 各要素预警指标的建立
目前, 襄垣县区域自动站仅有温度、降水、风速、风向四要素, 分别分析高温、低温、暴雨、大风、寒潮的预警指标。这里的预警指标是以中国气象局《气象灾害预警信号发布与传播办法》为基础, 但不完全照搬, 而是结合本地气候特点建立的易造成气象灾害的天气预警指标。兰红平提出的预警信号发布时应注意遵守的四个基本原则为:时机得当、发布慎重、应变迅速、减灾为本, 这是以预报为基础的预警原则。这里的预警指标是以天气实况为基础的, 应遵循“既不能发布过频, 也不能将易造成气象灾害的天气漏报”的原则。
1.1 大风预警指标
大风使森林火险等级居高不下, 对农业设施破坏严重。《气象灾害预警信号发布与传播办法》中的最低指标为平均风力在6级以上, 即>10.7 m/s, 与本地情况基本相符。而本系统的大风预警指标的最大风速达到10.7 m/s以上, 因此, 按实际风力发布信息即可。在系统试运行中, 用极大风速 (3 s最大平均风速) 和最大风速 (10 min最大平均风速) 分别试验。2011-11-22T12:00—13:00的极大风速和最大风速 (如表1所示) 相差3.8~7.0 m/s, 8个站中有6个站的极大风速达到了发布标准, 而最大风速无1站达到发布标准。本站得极大风速为14.2 m/s, 体感一般, 随后全县各乡、镇也未有灾情上报。因此, 指标应以最大风速设定。一天中 (以7:00为界) 达到大风指标的天气可能在连续数小时中出现, 只发第一个达标的大风预警。
1.2 降水预警指标
襄垣县的气候特点是:十年九旱、旱中有涝, 降水分布严重不均。每年6—9月的山洪、泥石流、塌陷防灾工作压力较大。考虑到以防汛为目的降水预警发布的时效性, 本系统只发布1 h、2 h、3 h达指标的降水量。
1 h降水预警指标为≥10 mm, 2 h降水预警指标为15 mm, 如表2所示。为了避免出现上时段降水量已≥15 mm、本时段无降水而发布的2 h降水预警等情况, 将指标条件定为“ (R1+R2≥15) , R1>0, R2>0”, 可满足2 h降水预警的实际需要, 且与1 h降水预警指标条件不冲突。
3 h降水预警指标为25 mm, 如表3所示。指标定为“ (R1+R2+R3≥25) , R1>0, R3>0”, 可满足3 h降水预警实际需要, 且与1 h或2 h降水预警指标条件不冲突。
2011-07-29各站均出现较大降水, 降水预警发布情况如表4所示, 预警信息基本能够满足防汛服务要求。
襄垣最大的水库——后湾水库是国家大 (II) 型水库, 防洪抢险应急工作十分重要。水库所在流域的上游主要在沁县区域, 所以加入了沁县的漳源、册村、南泉、故县、杨安、次村6个自动站降水预警。
襄垣属海河流域, 浊漳河的3大干流西源、南源、北源分别从境内的贺家垴、南沟、吴北入境。西源、南源在甘村汇合, 至北底乡合河口与北源汇流, 注入黎城, 流经8个乡、镇。因此, 加进了浊漳河上游武乡县的洪水、蟠龙、监漳3个自动站水预警。
1.3 高温预警指标
夏季, 气温上升到一定程度时, 主要农作物小麦、玉米生长发育会受到不利影响。本地最高气温历史极值为39.1℃, 高温预警指标定为≥35℃。统计近21年的资料, 如表5所示。从每年日最高气温 (从各时段最高气温中挑取) 出现天数分析, 符合“既不能发布过频, 也不能将易造成气象灾害的天气漏报”的原则。一日中达到高温指标的天气可能连续数小时, 只发第一时段最高气温预警。
1.4 低温预警指标
冬季低温预警主要提醒人们及时添衣保暖, 提醒各级领导关注群众的供暖状况。襄垣站最低气温历史极值为-29.1℃。统计近21年的最低气温日数, 如表6所示。因大部分区域站较襄垣站气候偏冷, 上马、王村、西营最低气温较襄垣站低4℃, 低温预警指标定为≤-20℃。
因本地降温突发性不强, 但随着夜间气温的降低容易达到最低气温预警发布指标, 考虑到防御本类灾害不需要夜间提醒的实际需求, 规定仅在6:00—20:00发布预警, 且一日中 (以7:00为界) 达到低温指标的天气可能连续数小时, 只发布第一时段的低温预警。
1.5 寒潮预警指标
寒潮天气对本地的危害极大, 特别是在4月果树开花时节, 需及时提醒果农采取防冻措施;在10月需及时提醒农民收冬白菜。本系统参照《气象灾害预警信号发布与传播办法》, 规定寒潮预警指标为: (1) 最低气温≤4℃, 最大风速>8 m/s (5级) , 48 h降温>8℃; (2) 最低气温≤0℃, 最大风速>10.8 m/s (6级) , 24 h降温大于12℃。
一日中 (以7:00为界) 达到寒潮指标的天气可能连续数小时, 只发第一时段寒潮预警。
2 各要素合法性检验
为了避免因自动站数据异常而误发预警, 对各要素做了合法性检验, 有疑问的可立即发短信与负责测报业务及设备维护的人员联系。合法性检验依襄垣站历年统计极值确定标准, 如表7所示。在实际工作中, 风速、气温非常稳定, 一般不会出现错误。降水出现异常主要有两种情况: (1) 承水器网罩或漏斗堵塞; (2) 人为给承水器灌水。第2种情况会导致误发预警。因此, 除了对1 h、2 h、3 h降水量是否超出历史极值检验外, 根据降水的连续性, 系统对每次达到发布标准的1 h降水, 要检查第一个1 min降水达到5.0 mm的前1 min是否有降水, 如果无降水, 立即发短信与负责测报业务及设备维护的人员联系, 人工排除疑问后再发布预警, 最大限度保证降水量预警不失误。
3 系统的实现
本程序用Visual Basic6.0语言编程, 流程如图1所示。
3.1 数据库的访问
使用ADO数据控件访问市气象台自动站数据库服务器, 在每个整点后的05分05秒对各站完成1次循环, 即进行1次远程查询、合理性审核、是否达到灾害性天气预警发布标准判断、短信发布, 然后追加要素记录和已发短信记录。要素记录、已发短信记录均可以通过菜单“数据库”和“短信记录”查阅。之所以规定在每个整点后的05分05秒开始循环, 是考虑到每个自动站采集器时间快慢的差异, 保证访问数据库在每站资料全部入库后执行。
3.2 系统的初始化
系统用户分为管理员和一般用户, 管理员有权设定的主要参数包括管理员密码、区域自动站站名、区站号和各站对应的服务用户手机号等。
第一次运行或退出程序1 h以上, 重新运行程序, 程序会自动连接远程数据库, 查询各站前24 h各时段降水量、前24 h各时段最低气温和24 h、48 h日最低气温, 补进本地数据库, 不需人工添加, 由程序初始化模块完成。
3.3 短信发布功能的实现
本系统发布短信采用了短信猫 (GSM MODEM, 适用于WAVECOM、西门子、诺基亚、摩托罗拉等) , 支持标准AT指令的GSM短信终端。短信发布格式如表8所示 (ZM$表示站名, FL$、Str$表示对应要素值, LJ$表示降水量级, Phour表示时间) 。另外, 也可以将短信发布给电子显示屏或大喇叭。
3.4 增加了监控和查询功能
加进了自动站运行状况监控功能, 在程序运行中如果发现某站资料未按时入库, 每次测报业务中心和设备维护中心负责人都会收到系统的短信提示 (如表8所示) , 提醒维护人员要及时处理故障 (可能是自动站采集器时间不准等原因造成的) 。
附加了以表格和柱形图查询分钟雨量的功能, 使每次降水过程如自记纸一样直观, 并可生成Excel文档长期保存, 以备以后科技服务查阅和课题研究使用。
3.5 系统的推广
只需要改变本地极值和用户表, 以及区域站名, 即可用于其他县 (市、区) 对本地区域自动站的监控, 易推广、易操作。
4 试运行结果
本系统从2011-12-10开始试运行, 至2012年底, 所有达到大风、降温、高温、强降水发布标准的信息无一漏报。2012-07-31的强降水过程, 共13站达到1 h、2 h或3 h预警发布标准61次, 共发布短信303条。
2012年雨量传感器使用期 (05-01—10-31) 1 h、2 h、3 h降水量仅上马站超出襄垣站历史极值, 合法性检验标准有待随资料积累年限延长进一步调整。
5 结论
本系统自动对区域自动站大风、强降水、高温、低温、寒潮等灾害性天气进行全天候监控, 并可及时将已出现的灾害性天气通知给用户, 值班员不再为有无特殊天气定时查看自动站综合业务处理网络系统应用终端, 节省了人力, 避免了失误, 对于无夜间测报业务、守班任务的一般站更实用。
水库安全关注的是上游降水, 本系统对保障水库安全更有意义。对比靠探头图像监视远距离天气状况的办法, 本系统对获取远距离天气实况定量、定性、方便、快捷, 而且短信接收信息不受时间、地点约束。
本系统仅需要1台计算机、1个短信猫, 投资少、见效快, 性能稳定可靠, 且易于推广。能够有效提高区域自动站投资效益, 发挥科技的力量, 为当地防灾、减灾作出更大贡献。
摘要：根据襄垣县的天气情况, 制订重要天气预警标准和防御指南。通过访问本县及沁县、武乡县部分区域自动站各正点资料数据库, 检索符合发布预警信息的数据, 自动启动短信发布, 将天气实况和防御指南发布给相应用户。系统对所选各区域站灾害性天气24 h不间断监控, 并及时发送灾害性天气信息, 为各级领导指挥部署防灾工作争取了宝贵时间。
基于物联网的公交信息发布系统 篇9
21世纪将是公路交通智能化的世纪, 人们为了解决社会生活中的各种交通不便将要采用智能交通系统, 智能交通的发展将解决一个严重的的交通堵塞问题。所谓的物联网技术, 通过射频识别、红外感应器、全球定位系统、激光扫描器等信息传感设备, 按约定的协议, 把任何物品与互联网连接起来, 进行信息交换和通讯, 以实现智能化识别、定位、跟踪、监控和管理的一种网络[1]。在“十二五”规划之后, 物联网成熟之时, 使用物联网构成智能交通网络, 也必是解决交通问题的最佳途径, 也必然给我们生活带来巨大变化。
2 系统的总体设计
优先发展城市的公共交通系统对缓解城市道路交通压力有着不可或缺的作用, 通过对公交系统的信息化和智能化可以有效提高整个系统的运行效率和服务水平。公交车辆到站时间作为乘客最为关心的公交信息之一, 可以有效减少乘客候车时间, 极少出行过程中浪费的时间, 同时也加强了公交服务水平, 很大程度上提高了人们在出行时选择公交的概率。
在日常生活中, 我们经常可以看到有地铁报时, 轻轨报时, 但是为什么很少有公交报时呢?在此总结几下几点原因: (1) 道路状况复杂, 点对点检测不易; (2) 不一样的时间段道路拥堵情况不一样; (3) 公路突发状况多; (4) 实时性很难把握。在文中, 我们提出了可行性办法, 由于堵车之后无法对公交车进行测速, 换个角度, 我们把注意力转移到了道路的通堵情况的检测, 对路况和距离进行检测。这是公交信息发布系统的可实现关键之处。因此设计了如下方案:
本文采用mega128[2]及飞思卡尔xs128[3]单片机为系统核心, 以红外对管为采集手段, 以12864液晶屏为显示装置, 无线模块则采用Zig Bee和蓝牙, 外加其他系统模块为一体作为系统模型。在每辆交通车辆上安装由红外发射管和两片555定时器构成的车载终端。当行驶车辆依次通过接收管时, 接收管将接收到的每辆车所特有的编码信号转变为与之对应模拟信号, 模拟信号经过滤波放大电路无线传递给CPU (xs128) , 此处的CPU (xs128) 也就相当于系统的主控中心, 在主控中心中, 由于要对众多的道路信息进行采集、计算、分析任务繁重, 计算量大, 因此对于此部分的CPU要求很高, 普通的8位机难以达到要求, 而32位性能高, 可靠性好, 但成本高, 功耗也相对较大, 因此我们采用16位的单片机。CPU (xs128) 应用AD、输入捕捉等功能对接收到的信号进行处理, 然后计算分析进而得出每辆车的行驶速度、到达时间以及道路的交通状况, 这就起到了交通信息中心的作用, CPU (xs128) 把这些得到数据通过无线传输模块传递给CPU (mega128) 即站点终端。CPU (meag128) 通过控制12864液晶显示屏、无线发送模块 (蓝牙、Zig Bee等) 对所接收到的信息进行发布。总设计图如下:
3 模块化设计
3.1 红外通信检测模块
为了更加方便、快速的掌握车辆信息和道路交通拥堵状况, 对各个车辆实时准确定位和跟踪, 并且及时、高效的处理各种突发事件, 这就要求我们能够找到一种可以区分各个车辆信息状况的装置, 以此来了解各项信息。对此我们选择在可视范围内遥控设备、无线传输信息最廉价的方式红外线传输。所以我们选择红外对管和红外接收管[4]。
将接收管安装在每一汽车上, 并通过两片555芯片对其所发射的红外信号进行编码, 构成车载终端。其中一片555产生频率为38K的载波, 另一片555芯片产生频率远低于38K且唯一的信号作为调制信号, 调制好形成每一辆汽车所独有的红外信号。当接收管接收到汽车发射的红外信号时经过滤波放大传递给CPU (xs128) 。由于每辆车所编码出的信号不同, 故CPU (xs128) 可据此判别出每辆车行驶情况, 且可以对车辆进行定位跟踪。
设车辆经过第一个检测点的时间为T1, 进过第二个检测点的时间为T2, 两个检测点的路程距离为S, 则根据
则可算出车辆行驶的平均速度V再有式
就可得到车辆到达每一个站点的大概时间。但由于车辆在行驶中还需考虑红绿灯时间, 站点停留时间等因素, 因此我们必须在原有的大概时间的基础上再增加一个补偿因子t。t为车辆所经道路的所有红灯停留时间t1与站点停留时间t2之和, 即
这样就可以比较精确的计算出车辆抵达目的的时间T
3.2 Zig Bee无线通信模块
Zig Bee网络含3种类型的节点, 即协调器、路由器和终端设备, 支持星状、树状和网状3种网络拓扑结构。从Zig Bee协议特点可以看出, 将Zig Bee无线传感网络用于智能交通[6]控制系统具有以下特点:短距离、小范围传输, 具有成本优势, 并且组网简单可靠;经过合理布局, 在一个市区内能做到无任何通讯盲区, 利用其地理定位的功能, 便于对城市交通进行管理监督[5]。在整个系统控制中, Zig Bee网络的数据通信速率可达到250Kpbs, 完全能够满足我们数据传送的要求。
在论文中站点终端将采集到的车辆信息, 采用译站式网络传输方式通过站点终端Zig Bee从节点发送给位于主控中心的Zig Bee主节点。本文采用Zig Bee自组织网络, 可以不断地对其网络进行刷新, 其中定位引擎是根据无线网络中临近红外信号强度, 计算公交车位置, 根据实际应用环境合理布局, 组成网状拓扑网络[6]。具有卓越的物理性能, 整个网络是免费的频段, 传输方式采用广播的数据传输方式, 它是网络的一个节点向其它节点发送的过程, 一个节点接收到一个广播帧时首先检查帧中的目的地址和自己的设备类型是否相符。不相符则丢弃;相符的话设备从本地广播事务表中查找相应的广播事务记录, 若存在, 则对其进行更新;若不存在, 则检查广播事务表中是否有空的或者过期的广播事务记录项。如果没有, 则丢弃广播帧;若有则添加新的广播事务记录项并将广播帧提交到高层进行处理。具体算法如下:本文采用Zig Bee自组织网络, 可以不断地对其网络进行刷新, 其中定位引擎是根据无线网络中临近红外信号强度, 计算公交车位置, 根据实际应用环境合理布局, 组成网状拓扑网络。在每隔一段距离设立Zig Bee主节点, 在道路周边设立大量的从节点, 而每个主节点最多能控制254个从节点, 每254个中心节点又可以管理254个主节点, 这样在各层之间组成了级网, 以无线的方式从低到高传输的Zig Bee主节点, 再由主节点传输到中心节点, 将所得得到的数据送入数据控制中心经过处理, 然后通过同样的网络传输方式将此数据通过Zig Bee主节点返回到Zig Bee从节点, 站点终端对接收到的数据通过液晶显示屏进行发布。
3.3 Bluetooth无线模块
我们在站点终端同样安装蓝牙装置, 这样人们就可以通过蓝牙连接来获取各种交通信息。互联网发展迅速, 已经与人们的生活密切相关, 人们可以在互联网上查到所需的各种信息, 蓝牙都是他们所必不可少的功能。
在本文中, 每一个站点终端都会实时的通过12864液晶显示屏、蓝牙传输模块不断的发布主控中心传来的各种交通信息, 人们只需要在手机上下载一个专用软件就可在蓝牙的传输范围内查看各种交通信息, 且不需支付任何费用。我们采用微微网来实现蓝牙无线通信。每个微微网只有一个主设备, 一个主设备最多可以同时与七个从设备同时进行通信, 多个蓝牙设备组成微微网, 散射网是多个微微网相互连接所形成的比微微网覆盖范围更大的蓝牙网络, 其特点是不同的微微网之间有互联的蓝牙设备。采取基于BER模式的数据传输算法, 在蓝牙应用的数据传输中采用比特误码率 (Bit Error Rate, BER) 进行描述传输的质量, BER值越大表示通讯过程中误码率越高。当前蓝牙应用中采用的数据传输算法, 为简化蓝牙网的连接管理, 未考虑具体通讯链路中BER的变化, 在整个传输过程中均采用单一链路帧方式, 导致传输效率不高。因此, 我们采用BER参数描述当外界环境变化, 并根据BER参数动态选用不同类型的数据包, 可改善在环境变化剧烈时造成数据传输大幅下降的情况。
4 智能公交信息系统的组成
5 系统制作与调试结果
为了实现系统功能验证试验, 本课题搭建了一个1:150的道路交通沙盘模型, 完成了设计与制作。由于条件所限, 本论文主要通过沙盘模型的方式来进行演示。
5.1 道路通堵状况显示
在道路大量车辆长时间停止不前时, 液晶显示目前道路拥挤, 在道路畅通时, 液晶显示道路畅通。通过无线通信发布公交信息和道路通堵状况。
5.2 蓝牙显示
手机蓝牙演示在站点终端的蓝牙覆盖范围内, 人们可通过手机蓝牙与站点终端蓝牙建立连接, 获取最新的各项公交信息。
摘要：本文致力研究基于物联网的智能公交信息发布系统, 物联网是具有整合感知识别, 传输互联和计算处理功能, 是新一代信息技术的高度集成。本文以ZigBee为无线通信框架, 主要由主控中心, 站点终端, 车载终端组成。以公交到站时间预测为出发点, 对其预算进行深度分析, 以物联网技术为基础, 实现路况的实时预测和显示, 这样会解决城市存在的诸多交通问题。
关键词：物联网,ZigBee,公交信息发布,智能交通系统,系统设计
参考文献
[1]张莉莉, 史鹏飞, 陈剑.物联网在智能交通中的应用研究.中国科技博览, 2010 (25) .
[2]AVR单片机数据手册.
[3]飞思卡尔9x12xs128单片机数据手册.
[4]唐文彦.传感器. (第四版) .机械工业出版社.2007.
[5]zigbee详细技术解析.互联网, 2012-02-13.
基于web的高校信息发布系统 篇10
从功能描述的内容可以看到, 本项目实例可以分成个完整的功能。根据这些功能, 设计出系统的功能模块, 如图1。
在本项目中, 用户有三类, 一个是普通用户, 一个是管理员, 一个是注册用户。其中管理员分为三类, 一个是超级管理员具备所以权限, 一个是普通管理员, 不能修改查看所以管理员信息, 一个是老师, 除了不能修改查看管理员信息外, 还不能删除会员。
2 系统概要设计
本项目是基于jsp+apache+mysql的web应用系统, 采用B/S模式。同时系统采用了MVC设计模式中struts2+spring+hibernate三层架构模式但是由于本人学习这个架构的时间较短, 所以有些地方可能领会不到框架的内涵, 因而使用了非框架的功能。
由于系统中的动作很多, 为了能让读者更清晰地认识系统的架构图, 这里选择了三个动作, 对于登录的动作, 图2中所示的是登录失败的情况, 如果登录成功, 会转到另一个Action, 从而进入留言页面如果是管理员登录动作成功, 则跳转到管理后台主页面。从图2中可以看出JSP没有直接找到Action, 而是通过Spring, 因为Spring容器管理着这些Action。然后通过Hibernate操作数据库, 并将返回到相应的页面。
3 数据库分析与设计
根据需求, 本系统共需要创建七个表, 分别为:管理员表:admin;留言表:message;新闻表:news;新闻分类表:news_sort;回复表:recomment;角色表:role;会员表:user下面是东北电力大学信息在线第四版的数据库表结构的详细介绍:
管理员表设计:管理员表是用来保存管理员的基本信息的, 主要表信息如表1所示。
会员表设计:会员表是用来保存会员的信息如表2所示。
4 系统测试
4.1 集成测试。
集成测试是将软件组装成系统设计要求把通过单元测试的所有模块逐步的组装与测试, 最后组装成一个完整的软件系统的测试过程。因此集成测试又称为组装测试或综合测试。集成测试旨在发现与接口有关的错误。这些错误包括:4.1.1数据通过接口时会丢失。4.1.2一个模块的功能对另一个模块产生了不利影响。4.1.3几个子功能组合起来没有实现主功能。4.1.4全局数据结构出现错误。4.1.5误差的不断积累达到不能接受的程度等。经过逐步的组装与测试并没有出现上述的几个错误。
4.2 功能测试。
功能测试有成为黑盒测试, 是把程序模块看成是一个黑匣子, 即完全不考虑程序的内部结构和处理过程, 测试仅在程序的接口上进行。检查程序是否具有需求规格说明书中所规定的功能、能否适当的接受输入数据并产生正确的结果信息、能否保持数据库或文件等外部信息的完整性。黑盒测试主要是测试软件是否满足功能需求。黑盒测试的主要测试的错误类型有:
4.2.1 不正确或遗漏的功能;4. 2.2接口错误;4. 2.3性能错误;
4.2.4 数据结构或外部数据访问错误;4. 2.5初始化或终止条件错误等错误。
摘要：随着网络技术的发展, 打破了地域限制, 真正的使使信息得以共享, 改变了人们的工作和生活方式。与此同时, 高校的信息发布也要跟上信息化的时代, 作为学校的形象展示之一的信息在线平台就应运而生, 为校内外乃至全球的人们提供关于高校的信息。同时也是高校展示自己的一个网络舞台。本文研究的是基于web的信息发布系统是一个能够在网上实现新闻的网上发布, 实时留言, 文件下载的网上交互系统。它的出现很好地决了高校新闻发布面不够广, 交互性互动性不够强的难题。
关键词：Web,高校信息发布系统,设计
参考文献
[1]张广彬, 孟红蕊, 张永宝.Java课程设计案例精编[M].北京:清华大学出版社, 2007.[1]张广彬, 孟红蕊, 张永宝.Java课程设计案例精编[M].北京:清华大学出版社, 2007.
[2]良葛格.Java学习笔记[M].北京:清华大学出版社, 2006.[2]良葛格.Java学习笔记[M].北京:清华大学出版社, 2006.
[3]王恩波.网络数据库实用教程--SQL Server2000[M].北京:电子工业大学出版, 2003.[3]王恩波.网络数据库实用教程--SQL Server2000[M].北京:电子工业大学出版, 2003.
[4]耿文兰.SQL Server2000数据库管理与开发[M].北京:电子工业出版社, 2003.[4]耿文兰.SQL Server2000数据库管理与开发[M].北京:电子工业出版社, 2003.
【校园信息发布系统】推荐阅读：
校园信息推送系统06-02
校园植物信息系统08-29
校园地理信息系统05-30
校园基建信息管理系统11-06
校园物流管理信息系统12-28
高校校园网信息舆情监控系统的研究12-18
信息发布系统08-08
网页信息发布系统12-23
网络信息发布系统01-04
教务信息发布系统论文05-10