信息发布系统（通用12篇）
信息发布系统 篇1
交通信息服务系统就是根据从交通数据采集设施采集到的原始数据,如道路交通流量、车速等参数,利用各种交通模型进行综合分析和处理,通过网络终端、手持终端、车载终端等各种手段向道路使用者提供适当的交通信息,来影响出行者对出行路线、出行方式的选择,以疏导交通流,保持最佳通行能力及提高交通安全度,从而最终提高社会与经济效益[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
[10]张立东,王英龙,潘景山,等.基于FANN理论的道路交通状态判别算法研究[C]//张嗣瀛,王福利.控制与决策学术年会论文集.无锡.沈阳:东北大学出版社,2007
信息发布系统 篇2
第一章 总 则
第一条 目的：本管理办法规定了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个月以后，根据试运行情况，系统项目组提交项目正式验收护指引》要求进行管理。
第六章 检查监督
第三十六条 检察监督
(一)科技信息部版本管理员在系统切换发布前对系统切换发布的版本进行检查控制；
(二)科技信息部系统管理员在系统更变和发布前对系统进行检查控制；(三)科技信息部每季度对项目文档的完整性、规范性进行检查监督；(四)科技信息部安全科至少每季度进行一次检查。
第七章 附 则 第三十七条 第三十八条 本管理办法由科技信息部负责解释和修订。
信息发布系统 篇3
关键词：Struts；MVC；UML；信息发布
中图分类号：TP391文献标识码：A文章编号：1009-3044(2007)16-30910-01
Design and Realization of Business Enterprise Information's Releasing System Based on Struts
LU Pei-jun,ZHANG Yong-jun
(College of Computer Science & Technology Nantong University,Nantong 226019,China)
Abstract:This paper discusses Struts system structure. By using the Unified Modeling Language (UML), design the system. And we has designed the whole frame and function structure of the system At last, discuss main technology realization of the System. The realization of this system makes the control over postgraduate’s information more high-efficient and has improved the working efficient.
Key words:Struts;MVC;UML;Information's Releasing System
1 引言
随着企业经济的发展，规模地不断壮大，各部门的职能和制度地不断完善，企业对于物资采购，资源分配与利用，产品流向，人力资源等相关信息的发布需要进行统一的管理，Web技术的产生为企业利用Internet进行企业信息的统一管和发布提供了可能性和实现的方法。Web技术的产生使得企业可以打破传统管理模式在时间、空间上的限制，采用了先进的销售手段和管理方法，并采用操作简便，界面美观，具有较高的扩展性和可维护性的管理系统，来提高企业的运营效率，降低企业成本支出。
2 系统实现原理
2.1 Struts技术
Struts是一个基于J2EE平台的MVC框架，它可以更加快速和容易地建立Web应用程序，其主要是采用Servlet和JSP技术来实现的。MVC是模型—视图—控制器（Model-View-Controller）的简称，它是一种设计模式，它强制性地把应用程序的输入、处理和输出分离。视图，主要负责显示模型状态并接受数据更新请求把用户输入数据传给控制器；模型，主要负责具体的业务流程；控制器，主要负责接受用户的请求调用模型影响用户请求。
2.2 Struts工作机制
在Struts框架中，模型由实现业务逻辑的JavaBean或EJB组件构成，控制器由ActionServlet和Action来实现，视图由一组JSP文件构成。基于Struts实现的MVC框架如图1所示:
图1 STRUTS实现MVC模式
2.2.1视图
在Struts中，视图就是一组JSP文件以及ActionFormBean。在JSP文件中没有业务逻辑，也没有模型信息，只有标签，这些标签可以是标准的JSP标签或Struts自带标签。Struts利用ActionFormBean来进行视图和控制器之间数据的传递。Struts把用户输入的表单数据保存在ActionFormBean中，把它传递给控制器，控制器可以对ActionFormBean中的数据进行修改，JSP文件使用Struts标签读取修改后的ActionFormBean的信息，重新设置HTML表单。
2.2.2控制器
控制器由ActionServlet类和Action类来实现。ActionServlet类是Struts中的核心组件，它在MVC模型中扮演中央控制器的角色。ActionServlet主要负责接收Http请求信息，根据配置文件Struts-config.xml的配置信息，把请求转发给适当的Action对象，如果该Action对象不存在，ActionServlet会先创建这个Action对象。Action类负责调用模型的方法，更新模型的状态，并帮助控制应用程序的流程。
2.2.3模型
在Struts中，模型表示应用程序的状态和业务逻辑。对于一般的中小型应用，一般可以用JavaBean实现业务逻辑。对于大型的分布式应用系统，一般采用EJB封装业务逻辑。
3 系统分析与设计
3.1系统架构
系统结构图如图2所示：在前台用户可以查看最新新闻，公司最新发布的产品。当用户输入正确的用户名和密码后，在后台提供了销售管理、销售查询、用户管理、公告管理，产品管理等模块。
图2 系统的体系结构图
3.2系统主要功能设计
3.2.1用户管理
此模块用于管理系统中的用户。当用户登录通过用户登陆的验证，则可以新建用户，并可以对新建的用户赋予相应的权限修改本店的资料，但是无权修改其他店的资料，而根据设计的权限标识符来判断用户是否具有删除的权限，如果没有删除权限则是普通管理员，只能新建用户，修改资料。
3.2.2公告管理
此模块实现发布新闻，同时提供相应的管理功能，如添加、删除、修改操作。当管理员登录成功以后即可进入后台管理
3.2.3产品管理
此模块主要实现新产品的详细信息和产品图片等信息的管理。前台可以显示相关的产品信息。后台，用户可以添加新产品，或修改以前产品的资料，也可以删除老产品。每个用户只能删除自己的商品，而无权删除他人的产品。
3.2.4留言管理
通过此模块公司提供一个互动的平台让员工可以发表信息，提出意见。客户和普通员工无需登录即可发表自己的意见。系统管理员可以对留言进行管理。
3.3系统UML建模设计
由于篇幅仅以用户管理模块为例对系统流程进行UML建模设计。模块中主要对用户进行管理，并赋于相关权限，其功能流程及相关类如下阐述。
3.3.1用户管理模块顺序图
在用户点击提交action后，首先调用ConnectionHelper类，通过ConnectionHelper类连接数据库，然后根据用户的选择的功能在UserDAO中调用相应的功能函数，如果期间发生错误则报出相应的错误。具体如图3所示：
图3 用户管理模块顺序图
通过用户管理模块顺序图具体设计出以下实现类：
表1 用户管理模块实现类表
3.3.2用户管理模块类图
对于用户的添加、删除、修改。系统首先从Save4UserForm获得表单信息，然后同过用户点击的功能，提交对应的Action，Action根据用户提交的功能，调用相应的数据困操作，而数据库连接由ConnectionHelper实现，具体功能函数是通过UserDao来实现的。具体如图4所示：
图4 用户管理模块类图
4 Struts技术实现
在用户管理模块中，系统视图中以Search4UserListForm实现相应的分页信息；系统模型以相应的ActionForm的派生类实现，主要对客户端表单数据的封装。系统控制器由ActionServlet类和Action类来实现。Action 类负责调用模型的方法，更新模型的状态，并帮助控制应用程序的流程。如下Save4UserAction部分代码阐述系统中的控制：
public class Save4UserAction extends Action implements FinalConstants{
.....................................
Save4UserForm formbean = (Save4UserForm)form;//创建Save4UserForm实例
conn = ConnectionHelper.getConnection();//通过ConnectionHelper连接数据库
conn.setAutoCommit(false);
UserDAO userDAO = new UserDAO(conn);//创建UserDAO类实例
if(formbean.getId() == null || formbean.getId().trim().length() == 0){//判断ID是否为空
……………
系统中的视图，模型与控制器通过struts-config.xml实现的。具体实现配置如下:
5 结束语
以Struts技术实现的企业信息发布系统对于实现企业管理信息化、网络化，提高企业管理效率，具有重要的现实意义。其功能符合用户需求，能够实现用户管理，产品发布、新闻管理、销售管理等功能，对于数据的一致性的问题也通过程序进行了有效的解决，提高了现代企业的办公效率。
参考文献：
[1]叶达峰,四维科技.Eclipse编程技术与实例[M].北京:人民邮电出版社,2002,114-69.
[2]张桂元,贾燕枫.Eclipse开发与入门[M].北京:人民邮电出版社,2006,1-54.
[3]James Turner,Kevin Bedell.Struts[M].北京:电子工业出版社,2004,22-67.
[4]张琴,张千帆.从零开始[M].北京:人民邮电出版社,2005,60-98.
信息发布系统的实现及应用 篇4
关键词：数字电视,信息发布,增值业务
0 引言
有线数字电视在国内得到国家和政府的重视和大力支持,有线数字机顶盒市场增长迅速。随着江苏有线苏州分公司有线电视整体转换工作的完成,在拥有一定规模的数字电视用户后,开始考虑后期增值业务平台的搭建和拓展工作。整体转换时大量发放的是单向机顶盒,在目前的环境下信息发布类的增值应用是可以最快部署、最快见效、最大覆盖的选择。
然而在增值业务开发过程中却遭遇很多问题[1,2,3]:
1)整转期间机顶盒配置大多较低,目前该部分机顶盒正在大量使用,后续高端机顶盒也相继投入市场,导致市场上机顶盒硬件、软件版本存在多样性,增加新业务开发、集成、测试周期和工作量。
2)现行的由机顶盒厂家定制开发的软件架构决定了新业务的推广需要面临全网升级,由于机顶盒型号众多,升级周期至少在半年以上,对应用的任何修改都必须对机顶盒重新进行全网升级,增加了客户服务压力,难以适应快速变换的市场需求。
3)目前的数字电视增值业务主要是以浏览器为技术基础的数据广播业务,存在业务模式单一、页面响应速度慢、资源占用空间大、浏览器技术为私有技术等问题。目前中间件技术得到广泛认可,然而中间件技术的推广应用仍受到一些制约,比如:国内中间件标准尚不明确;中间件对机顶盒硬件资源的要求相对较高,而先期整转机顶盒配置极低;中间件作为平台技术,比较复杂,软件的集成周期长。
为了挖掘现阶段的市场价值,需要寻找一种适应于现在这个过渡时期的盈利模式,基于对目前有线电视平台及需求的分析,信息发布系统是当前的合适选择。
1 系统构架
1.1 系统结构
信息发布系统分为前端系统和终端移植库两部分。
前端系统包括信息发布管理系统、信息播发系统和后台数据库,实现信息业务数据的编辑管理、打包和播出。
终端机顶盒移植信息集成库实现信息数据的接收呈现,屏蔽了机顶盒厂家开发能力不一致引起的功能差异。
信息发布系统划分如图1所示。
信息发布前端系统负责信息上传、信息编排、信息审核、日志查询、权限管理、业务管理等,主要分为后台管理、业务管理、内容管理、播出管理。
信息发布终端系统需要集成信息业务模块,实现信息数据的接收、过滤和呈现。
1.2 前端部分
参照系统功能模块划分,信息发布系统前端包括信息发布管理、信息播发和后台数据库3个模块,实现信息业务数据的编辑管理、打包和播出。
1)信息发布管理由业务调度服务器和客户端组成,完成信息编辑管理及日常操作。
2)信息播出由1台应用播出服务器和若干视频播出服务器组成,完成图文、视频等信息的打包播出。
3)数据库服务器用于各种信息数据的管理存储。
信息发布系统与其他业务系统的接口包含:1)应用播出服务器与复用器通过ASI接口传输;2)视频播出服务器与QAM调制器通过ASI接口传输;3)通过IP接口与BOSS系统进行信息连接;4)信息发布系统与EPG系统没有直接的连接和通信接口,只在EPG的NIT中可以插入一个私有描述符来增强机顶盒模块接收广告数据的速度和灵活性。
信息发布系统前端部分组成与接口如图2所示。
业务操作流程示意图如图3所示。
具体需要播出的图片、字幕内容、样式等由内容制作系统统一制作,该功能独立于信息发布系统。除定向信息发布以外的业务内容制作完毕后,由客户端首先导入,然后进行相应的编辑,通过审核后即可以进行播出。定向信息的内容由BOSS系统针对特定用户群生成相应的数据包后,导入加信息发布系统的数据库。
1.3 终端模块设计
机顶盒终端子系统架构如图4所示。
信息发布系统设计采用如图5所示的基于Java的典型3层架构设计模式。
各层的主要功能如下:
1)表示层的主要职责就是为用户提供信息,以及把用户的指令翻译为业务指令,分为界面外观层和界面规则层。界面外观层提供了与用户交互的界面;界面规则层根据用户指令调用业务接口层相应接口,并将数据传递给业务层。
2)业务逻辑层主要是对用户提交的指令及数据做校验,再加工后将数据存储到数据存储层,或将数据存储层的数据提取后返回给表示层,分为业务接口层、业务规则层、实体层。
业务接口层提供给表示层指令接口,并将指令操作结果返回;业务规则层根据用户指令和数据的不同,将该指令划分给不同的构造器处理,并构造出实体;实体层抽象出数据库对象,如表实体、视图实体、存储过程实体等。
3)资源层主要是对数据库对象进行操作,分为数据访问层和数据存储层。数据访问层具体操作数据库,如连接、查询、插入、更新、删除等;数据存储层主要指的是数据库,当然就包括了表、视图、存储过程、触发器等数据库对象。
采用3层架构设计,可以降低层与层之间的依赖,有利于各层逻辑的复用,便于系统功能扩展,为系统升级、优化、扩容提供了根本性的保障。
1.4 系统扩展性
信息发布系统的架构设计模式决定了系统具有良好的功能扩展性和容量扩展性,而且新功能的引入不会影响原有的功能。
功能扩展性如图6所示。
功能扩展性具有如下特点:1)系统采用模块化结构设计,具有良好的可扩展性。2)新功能的引入不影响原有的功能模块。3)通过增加播出服务器以及播出卡,可以达到线性扩容。
性能扩展性如图7所示。
2 主要技术
2.1 OSD显示
屏上显示(On Screen Display,OSD)的功能主要是在已有的屏幕待显示图像或数据上叠加一些事先定制好的显示内容,如选单、图符、开机画面等。是机顶盒与用户交互的最前端。
OSD是有线数字电视机顶盒系统内数字处理子系统中视频解码器的一部分。数字电视接收系统的解码部分可以通过硬件寄存器——OSD模式寄存器(OSD MODE)使能位的设置,控制OSD功能的使用。如果OSD使能位设置为使能,OSD内容和视频解码内容相混合后,经过编码器DENC编码成为模拟信号,输出到电视机上。
OSD系统把屏幕显示分为4个平面,从上到下分别是Graphic,Video,Image和Background Plane,如图8所示,上面的平面和下面的平面图像混合。除了背景平面外,其他平面都可以通过DCR寄存器设置使能。
OSD功能通过Graphic Plane和Image Plane两个平面实现。视频解码输出在Video Plane。Graphic和Image Plane功能基本一致,输出的图像一个在视频平面之上,一个在其下,和视频进行混合。要使除视频之外的其他图像在屏幕上显示,就要通过这两个平面。
为了使广告业务在电视机屏幕的呈现达到“任意位置,任意时段”的要求,在软件库中实现了对OSD功能的全控制,即掌握了OSD功能的底层驱动,控制屏幕上所有像素点的RGB-alpha数值设置。
由于信息发布终端软件内核和机顶盒系统软件交互并存,所以需要避免终端软件库与机顶盒工作的冲突,尤其是广告显示时按键控制权问题。以porting API的形式与机顶盒做集成,机顶盒仅负责开机时OSD层的初始化工作。
2.2 业务引导
业务引导即在指定入口或用户触发某个按键时,机顶盒自动跳转到预先设置的业务入口。根据实现方式的不同,业务引导主要分为开机引导和泡泡应用两种方式。
开机引导,即在开机进入正常数字电视节目播出前机顶盒自动跳转到规定业务的功能,通过开机引导可使引导目的地用户的到达率达到100%。通过在NIT表中添加开机视频指示描述符,机顶盒在开机流程中检测开机视频指示描述符,开机后自动定向到描述子所指定的节目,界面包括主菜单、指定的直播节目、指定的音频广播等。开机视频指示描述符来确定开机后是全屏播放频道还是显示主菜单及相关显示内容。开机视频指示描述符(First Video Descriptor)出现在NIT表中,用于指定开机后播放的节目。在不变更NIT版本号的前提下,修改和删除开机视频指示描述符不会导致机顶盒频道更新,不会影响EPG的正常服务。
泡泡应用即在正常收看电视的过程中,通过前端控制,推送屏显广告,广告位为屏幕上任意位置,一般设置在屏幕角落,因此也被称为挂角广告。当用户正在观看某频道节目时,电视屏幕弹出链接信息,如某产品广告宣传信息,用户可直接按遥控器确认键进入浏览产品广告图文和视频内容。泡泡应用提供了用户看电视过程中跳转到指定业务(包括数字电视节目、自定义视频甚至数据广播等其他增值业务)的功能,只需将目的业务的入口参数传递到泡泡应用的响应函数即可。
3 实现功能及优势
实现功能及优势为:
1)信息发布系统采用新的信息资讯传播方式,即相对于传统视频而言,利用机顶盒提供的OSD资源实现图文和视频等的信息发布,新媒体业务可实现用户全覆盖,全天24 h运营。
2)支持开展的多种形式增值业务。支持开机广告、转台广告、菜单广告等广告位播发,支持角标广告和字幕广告,支持开机引导及超链接功能,实现点对点信息的准确投放,资讯信息内容表现形式丰富多样,可包括音频、视频、文字和图片等多媒体信息的组合以及各种动画特效。
3)与BOSS系统对接,定义了一套通信方式,信息发布系统与BOSS等外部系统之间进行通信,通信方式采用TCP/IP套接字,实现了点对点信息的发送。
4)强化前端管理,强化了前端管理功能,包括权限管理、客户合同管理、素材编排管理等,提供了日志查询、实时监控、广告预览等多种功能,实现了前期编排制作等的合理化管理。
5)终端机顶盒配置要求低。占用CPU资源少,在高于80 MHz主频的机顶盒上都可正常运行;模块软件总大小不超过250 Kbyte,对Flash要求低;内存空间占用不超过3 Mbyte,适用于目前已经普及使用的16/32 Mbyte机顶盒。
6)终端软件集成难度小、兼容性好,安全机制完善。软件模块以软件库的形式集成到机顶盒业务平台,通过API接口进行通信,集成难度小;模块功能的加入不影响机顶盒其他业务功能的正常开展;终端业务功能可屏蔽,满足了安全播出的要求;支持不同厂家不同型号的机顶盒芯片,已经完成移植的芯片包括ST,ZORAN,富士通等,目前苏州所有型号机顶盒都已经完成软件集成工作。
7)OSD功能主要是在已有的屏幕待显示图像或数据上叠加一些事先定制好的显示内容,如选单、图符、开机画面等。本系统仅控制机顶盒OSD资源,并与机顶盒其他资源采用多线程进行调度,对普通数字电视节目播放无明显影响,前端更新时仅传输关键数据,带宽要求低,系统性能高效。
4 小结
信息发布系统可以挖掘现有单向机顶盒的潜力,覆盖所有终端用户,将各种多媒体资讯信息在指定频道、指定时段、指定终端操作界面、指定终端用户、指定区域定时自动播出并可实时更新替换,通过数字机顶盒终端软件模块实现多媒体资讯信息即时接收和显示。
在该系统的技术基础上,还可实时发布紧急广播、政府公告、便民信息等,并与其他系统配合开展点对点信息发布、运程教育等,为用户提供了新的数字电视体验,节目引导功能为用户提供了更便捷的收视方式,让用户感受到数字电视整转带来的不同收视享受,为广电运营商吸引更多广告投入提供了灵活的技术平台。
参考文献
[1]黄万来.数字电视平台增值业务的发展方向[J].电视技术,2009,33(3):41-43.
[2]胡晓东.基于单双向有线网络的增值业务探索[J].电视技术,2009,33(3):40-41.
招标信息网上发布系统开题报告 篇5
五、主要研究内容、需重点研究的关键问题及解决思路本系统的功能主要是对项目、厂商、产品信息的保存、查阅、修改与删除。由于本系统主要是对这些信息而设计的，所以功能主要集中在信息的阅读与操作方面。
使用者可以通过本系统方便及时地查阅相关信息。具体途径有两种：一种是通过搜索引擎直接输入关键字，系统对数据库进行查找并返回查找结果；另一种是用户直接在信息页面逐级搜索浏览。
本系统主要完成的.功能如下：
1.客户界面部分
1.1产品信息查询
1.2厂商信息查询
1.3项目信息查询
1.4综合查询
2.管理界面部分
2.1项目管理
2.2厂商管理
重点研究关键问题及解决办法：
a)数据库设计的复杂性：在设计数据库时，必须认真分析这些关系，通过数据库的E-R图、各实体属性图等方式来分析实际中的各种逻辑关系，通过对逻辑关系的分析，设计完成数据库的物理设计。
b)业务逻辑层的实现：在程序中，每个类基本都对应着数据库的一个表，但是由于表与表之间的关系复杂，因此在实现过程中，每个类之间也具有一定的关联性，特别是类之间方法的相互调用很多。
c)软件工程思想的掌握：由于系统采用的是面向对象的分析和面向对象的设计。首先，系统根据功能划分成多个实体对象，通过分析每个实体对象，给出实体的属性和方法，这样就形成了系统的数据层。通过对系统的实体对象逻辑关系的分析和系统的需求功能分析，设计完成了本系统的业务逻辑层。因此，软件工程思想对本系统进行分析与设计很重要。
信息发布系统 篇6
【摘 要】通过一套完整的信息收集、处理、汇总及发布系统来实现天气预报产品、灾害预警信息、台风实时位置信息、每十分钟的天气实况信息及各类通知公告等实时气象信息向LED显示屏的分组发布。该系统主要包含用户分级及显示屏管理模块、灾害预警信息录入模块、各类通知公告录入模块、实时气象信息收集汇总模块以及实时气象信息自动发布模块。
【关键词】分组发布 实时气象信息 显示屏 自动
【中图分类号】 P405【文献标识码】 A【文章编号】1672-5158（2013）07-0035-02
实时气象信息包含了天气预报产品、灾害预警信息、台风实时位置信息、每十分钟的天气实况信息及各类通知公告等。其中台风实时位置信息需发布到所有的显示屏上，天气预报产品及灾害预警信息为县级气象部门针对本行政区域的显示屏发布，各类通知公告为各个乡镇或村政府发布的信息，每十分钟的天气实况信息为邻近几个乡镇的区域站实况资料。为让各级用户能依相应的权限发布本区的预警、公告等信息，避免不同区域信息的混乱发布，使指定信息及时准确的发布到指定的显示屏，需要有一套完整的信息收集、处理、汇总及发布系统来实现。本文就LED显示屏实时气象信息分组发布系统做一个简要介绍。
一、发布系统总体框架
LED显示屏实时气象信息分组发布系统包含了用户分级及显示屏管理模块、县级灾害预警信息录入模块、各类通知公告录入模块、实时气象信息收集汇总模块、实时气象信息自动发布模块。发布系统的数据流向如图1所示：
二、显示屏的显示设计
采用单色整屏显示的LED显示屏。显示屏的显示区域分为两个区域：上区由下往上滚动显示天气预报、台风实时信息，以及由各级用户利用互联网在任何地方编辑输入的灾害预警信息、各类通知公告；下区由右向左滚动显示指定的多个观测点的每十分钟天气实况。图2为某款用于发布气象信息的电子显示屏。
三、用户分级及显示屏管理模块
所设计的用户含管理用户（地区级用户）、灾害预警信息发布用户（县级用户）、各类通知公告发布用户（县、乡、镇、村、小区级用户）。为避免信息间的相互覆盖，设计各级用户有一个或多个不同编码的操作信箱（信箱编码定为2位数字）。
管理用户为系统的最高级别用户，权限包含了地理区域的编码管理，显示屏的添加、删除管理，以及发布用户的添加管理。系统设计管理用户只有2位字母暨地区的前两位缩写，如福州为“fz”，泉州为“qz”。
地理区域的编码管理为整个系统最关键的地方，由区域编码我们可以对显示屏进行编码，可以对属于不同区域的显示屏进行分组，可以对不同分组的显示屏进行不同信息的发布。区域编码使用a～z，0～9等36个字符进行编码，总共为12位。前两位为管理用户；3、4位为县级代码；5、6位为县的名字缩写；7、8位为乡镇代码；9，10位为乡镇缩写；11，12位为村、小区代码。 在管理用户生成时，必须同时规定该管理用户可进行编组的3、4位编码范围，如用户“qz”管理“00”～“29”，用户“fz”管理“30”～“59”，理论上总共可以有36*36=1296个的县级用户可以录入预警信息。
显示屏的添加操作包含显示屏的编码，显示屏的分组，并根据分组信息生成该显示屏的操作用户。显示屏添加时先要选择显示屏所在的区域，选择完直接生成15位的显示屏编码，暨区域编码+“3位数字编码”，“3位数字编码”由数据库中本区域内已有显示屏代码自动加1生成。如，数据库中已编了“qz07ax00cx00005”，则下一块屏就为“qz07ax00cx00006”。在对显示屏进行编码时，显示屏能属于的组也确定了，如“qz07ax00cx00006”只能属于 “qz07”、“qz07ax00”、“qz07ax00cx00”、 “qz07ax00cx00006”等四个组，从中选择一个作为显示屏的分组码，并根据分组码生成操作用户。无论选择哪个组，灾害预警信息发布用户——“qz07”为必须生成的（数据库中已存在该用户时不生成，操作信箱为20）。另外还需生成与分组代码相同的用户，用于发布各类通知公告发布，其操作信箱为21。当然，当选择的分组为县级分组，该分组操作信箱就有两个，暨20和21。
四、灾害预警信息录入模块与各类通知公告录入模块
该模块采用B/S架构，各级用户能在任何地方利用互联网，根据自己的级别权限及分配的信箱号发布信息。当点击保存时，系统自动将用户名，信箱号，信息内容存入到数据库中。
五、实时气象信息收集汇总模块
5.1信息收集
该模块自动判断数据库中天气预报产品、灾害预警信息、台风实时位置信息、天气实况信息及各类通知公告的数据表是否有数据更新，如果数据表有更新，则根据规则生成临时文件，天气实况信息文件命名规则为“区域自动站名.txt”，其余文件的命名规则为：“Z用户名N信箱号.TXT”。
5.1.1 天气预报产品
当数据有更新时，根据发布区域编码生成天气预报的文本，如“qz07”所要发布的天气预报产品文件名为“Zqz07N01.TXT”。
5.1.2 台风实时位置信息
当数据有更新时，根据发布区域编码生成台风实时信息的文本，如“qz07”所要发布的台风实时位置信息文件名为“Zqz07N02.TXT”。
5.1.3 灾害预警信息与各类通知公告
当数据有更新时，系统从灾害预警信息与各类通知公告数据表中读取用户名，信箱号，信息内容，并把信息内容输出到TXT文件中，文件命名规则为：“Z用户名N信箱号.TXT”，如用户“qz07”更新数据后系统生成的文件名为“Zqz07N20.txt”， 用户“qz07ax00” 更新数据后系统生成的文件名为“Zqz07ax00N21.txt”。
5.1.4 天气实况
可选择所需要的某个区域自动站的部分气象要素进行实况的组合输出。输出内容包含有时间，地点，组合的要素值。输出内容如下所示：
05月22日16时50分天气实况
（地点：南平政和，每十分钟更新）
气温：26度 风向：东北偏东
风力：2级 风速：3.2m/s
极大风：5.5m/s 极大风：4级
日最高：28.5度 日最低：22.2度
（接上页） 时雨量：0.2mm 日雨量：0.3mm
昨雨量：19.7mm
单个站的天气实况信息保存为“区域自动站名.txt”。
5.2 实时气象信息汇总，应用BAT可执行文件
根据分组生成以下两个文件：1）“A分组号.txt”，文件内容发布到显示屏的上区，2） “B分组号.txt”，文件内容发布到显示屏的下区。无预警信息发布的时候，每5分钟触发实时气象信息自动发布模块，当有灾害预警信息发布时时，直接触发实时气象信息自动发布模块。
六、实时气象信息自动发布模块
当收到实时气象信息收集汇总模块发来的触发指令后，实时气象信息自动发布模块自动搜索文件“A分组号.txt”及“B分组号.txt”，根据分组号找到对应的显示屏，并向这些显示屏发送信息文本。当文本发送完成后，删除目录下的“A分组号.txt”及“B分组号.txt”文件。
七、结束语
本显示屏发布系统可满足用户实时、直观了解所需气象信息的需求，系统功能的整体特点有：
1、实时性强、自动化程度高，整个发布过程无需人工干涉；
2、信息发布的灵活性强，可自由增减发布信息栏目，可选择显示任意的气象要素；
3、发送成本低，以数据流量计费，每月只需50M。
4、组网规模大、扩展性强、安装方便：
同步科技综合信息发布系统受关注 篇7
在BIRTV2012上, 同步推出的综合信息发布系统广受关注。该系统是集网络视频、电视接收、媒体播放、字幕新闻以及图文信息为一体, 提供基于“视觉展现”为目标的信息发布解决方案, 主要由信息推送端 (服务器端) 和分布在各处的信息接收端 (机顶盒) 构成。系统中所有需要发布的媒体数据, 包括视频、照片、文字以及其他有关的内容, 在服务器端按照需要的时间顺序进行编排, 制作成播出列表, 以网络广播或网络组播的方式推送到每一个接收的终端, 由接收端将这些分离的信息, 按照在服务器端所指定的播出版式, 合成最终的显示内容, 显示在屏幕上, 供用户观看。
据悉, 综合信息发布系统可以广泛地应用于会议展览、机场、学校、医院、机关单位、购物中心、新闻发布现场、办公大楼等多种场所, 为受众提供全新的信息发布以及展示手段。目前, 该系统已经在清华大学百年校庆、汇文中学140周年校庆、中国国际乐器展览会、中国人民解放军总医院展示、北京科技活动周等活动宣传中发挥了重要的作用。
航班信息发布接口系统设计与实现 篇8
关键词：数据交互,数据传输,航班信息发布
随着民航事业的发展, 数据与信息的共享需求也随之增大。导致越来越多的单位系统或项目需要引接民航华北空管局综合电报处理系统航班动态和计划数据, 建立一个用于该系统信息发布接口的必要性也随之增强。
航班信息发布接口系统在设计时考虑了四个方面, 分别为软件流程设计、参数功能设计、数据库设计以及传输设计。
1 软件流程设计
航班信息发布接口软件, 使用DELPHI语言编写, 该语言是Windows平台下快速应用程序开发工具 (简称RAD) 。航班信息发布接口软件, 核心功能分为三个部分, 分别为数据引接、数据处理、数据发布。
1.1 数据引接设计
数据引接方面, 航班信息发布接口从综合电报处理系统引接航班时刻表、中长期计划表、核心计划表, 动态更新表等数据。
航班时刻表:此表为由中国民用航空总局空管局统一下发, 一年两次, 分别为冬春、夏秋航班时刻, 此表信息每日8时从综合电报处理系统引接一次, 同步至接口系统。
中长期计划表:临时根据电话、文件或电报内容生成的计划表, 此表实时同步。
核心计划表:此表由航班时刻表、中长期计划表和一些基础信息表, 例如航站信息表、航路信息表共同联合生成, 航班信息全面, 属于航班信息接口系统核心表, 此表实时同步。
动态更新表:为航班AFTN电报更新的核心计划后的表, 同属于航班信息接口系统核心表, 此表实时同步。
接口系统将上述数据进行引接, 组建成航班信息数据源, 存入数据库, 在数据库中根据数据源建立用于数据引接的各类视图, 等待数据接口程序进行处理及发布。
1.2 数据处理及发布
接口软件根据任务参数从数据源视图中索取航班信息, 将信息进行XML生成, 首先存放于本地, 后将信息进行发布。在发布过程中进行数据备份以及发布提示。
数据备份便于同对方系统接收的航班信息核对, 同时存放的历史记录也方便于数据重传, 以支持对方系统故障、瘫痪重新索取航班信息的各类需求。
发布提示主要是监控发布过程是否成功, 当失败时接口程序会进行试探性重传, 当试探两次仍失败后, 将产生告警信息提示维护人员进行检查链路或程序。
简略流程中绿色模块为计划发布接口, 首先根据任务参数生成航班信息组成XML文件, 再通过Ftp协议上传至对端系统FTP接口服务器, 同时对上传数据进行备份。此过程中接口软件会判断传输是否正常, 如不正常则尝试重传, 两次失败后提示告警。
1.3 其他设计
采用DELPHI多线程技术, 支持多任务并发, 设计1个任务对应1个线程, 能够同时提供15项任务传输, 且每项任务支持10种视图的同时发布。
数据量方面, 在网络设备允许的情况下, 最快可支持向单系统发布航班数据10 000条/min, 数据量超过10M/min。
在稳定性方面, 软件在编写过程中加入了数据库死锁、内存溢出、类库冲突等容错机制代码, 并将软件运行中的错误日志进行记录, 为维护人员提供告警。
2 任务参数设计
航班信息接口程序支持多任务同时运行, 各任务可连接不同数据库取所需数据;可向不同FTP服务器进行文件传输;可将本地导出XML的文件备份至不同文件, 单个发布任务对应1个INI任务参数, 每个INI由XT、DATABASE、FTP、XML、TABLE五块参数设置组成, 下面以TABLE参数设计为例进行介绍。
2.1 TABLE参数设计
此参数作为软件调用核心参数, 为数据源获取信息, 包括数据表/视图名称、发布间隔、具体条件等。
2.2参数设置:
参数设置详细说明如表1:
(例如:2=jkv_changelist#ROW_ID>$1341767 orderby row_id#2011-10-27 14:10:00$2011-10-27 14:11:00$5$1#0$2011-07-06 17:05:00#jkv_changelist#)
3 数据库设计
本系统的建设由三模块组成:软件程序设计、数据库设计、FTP服务器设计, 本章将对数据库设计进行介绍。在数据库方面, 系统采用ORACLE 11G数据库, ORACLE11G相比以往版本有对高可用性的增强、新的Flashback能力、支持回滚更新操作;对安全性的增强, 便于管理大量的用户[1];BI方面的增强, 包括改进的SQL能力、分析功能、数据挖掘的能力等;对非关系型数据存储的能力进行了改进;以及支持XML的能力, 降低了管理开销, 提高了后台运算性能[2]。
本系统的数据库建设分为系统层设计、业务层设计、发布层设计三个方面, 其中系统层设计包括ZJ_LOGIN权限管理表、RZ_LIST日志运行表;业务层设计包含DRT_DYNAMIC_HXH_DMZ核心航班计划表、HBT_FLIGHT航班时刻表、CQT_PLAN运管中长期计划表、RZT_HXHUPDATE动态更新记录表、LST_DYNAM-IC_HXH_DMZ核心航班计划历史表;业务层设计包含DRV_DYNAMIC_JCG核心航班计划视图、JKV_DYNAM-IC_CR次日航班计划发布视图、JKV_DYNAMIC_DR当日航班动态发布视图、JKV_DYNAMIC_LS昨日航班计划发布视图、LSV_DYNAMIC_JCG历史航班计划视图、LSV_DYNAMIC_DR历史航班计划发布视图。
3.1 系统层设计
系统层设计主要为程序的管理权限、运行日志记录提供服务。
3.1.1 权限表
该表由软件调用, 包括用户名、密码以及权限记录, 程序通过调用该表实现安全管理。
3.1.2 日志表
该表为软件运行日志信息, 包括记录号、运行错误的步骤、故障导致原因、检查与排除故障方法、故障时间, 在软件运行时记录各流程状态是否正常, 异常时将错误记录至该表, 方便维护人员调阅, 查找故障原因。
3.2 业务层设计
业务层设计主要用于数据引接、整理。
3.2.1 核心计划表
该表为系统核心航班计划动态表, 数据来源于实时同步的综合电报处理系统, 里面记录着航班各类信息, 包括航班号、机型、时刻、性质等, 包含昨日、当日、次日三天数据, 此表为软件系统的核心, 向外发布视图数据均来源于该表。
3.2.2 航班时刻表
该表为航班长期计划表, 数据来源于综合电报处理系统, 每日完成一次同步, 里面记录着航班各类信息, 包括航班号、机型、部分计划时刻、性质等, 一般存放半年计划。
3.3 发布层设计
发布层设计主要用于数据发布, 多采用视图形式, 方便修改。
3.3.1 核心动态视图
该视图数据来源于核心计划表DRT_DYNAM-IC_HXH_DMZ, 将该表中数据进行分段处理拆分后进行呈现, 因8段视图均为重复Sql语句, 故以第一段视图进行展示。
3.3.2 次日计划视图
该视图数据来源于视图DRV_DYNAMIC_JCG, 仅为次日航班计划信息, 用于向其他系统发布此日计划使用。
3.3.3 当日动态视图
该视图数据来源于视图JKV_DYNAMIC_DR, 为当日航班动态信息, 用于向其他系统发布实时航班动态信息使用。
4 信息传输设计
本系统在建设中考虑到信息传输的安全、高效, 采用了FTP传输方式, 将软件生成的XML文档, 通过FTP文件传输协议传送到对端接口服务器, 向用户屏蔽不同主机中各种文件存储系统的细节, 加强了数据传输的可靠性和高效性。但也因此需在对端接口服务器中建立FTP服务, 与大多数Internet服务一样, FTP也是一个客户机/服务器系统。用户通过一个支持FTP协议的客户机程序, 连接到远程主机上的FTP服务器程序。用户通过客户机程序向服务器程序发出命令, 服务器程序执行用户所发出的命令, 并将执行的结果返回到客户机。比如说, 用户发出一条命令, 要求服务器向用户传送某一个文件的一份拷贝, 服务器会响应这条命令, 将指定文件送至用户的机器上[3]。客户机程序代表用户接收到这个文件, 将其存放在用户目录中。
5 结语
本文从软件设计、参数设计、数据库设计、数据传输四个方面向大家介绍了航班信息发布接口系统的设计思想。在整体设计方面, 除了考虑到接口系统安全性、实时性、稳定性以外, 还适当的考虑了接口的规范性、适用性和灵活性, 为今后的业务拓展、信息扩容做前瞻性预见。
参考文献
[1]吕清娇.基于Web技术的Oracle数据库实验平台的研究与实现[D].长沙:中南大学, 2014.
[2]唐志涛.测评系统组件间数据交互的设计与实现[D].西安:西安电子科技大学, 2011.
基于物联网的公交信息发布系统 篇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.
交通信息发布系统中光强度的测定 篇10
整个交通信息发布系统由上位PC机、光强转换和下位单片机及LCD显示三大功能块构成。在测量光强度部分，选用TI公司的可编程光频转换器TSL230来进行光强检测和转化。TSL230属于高性能光频转换芯片，它不但具备可编程的特性，而且还有成本低、分辨率高、动态范围宽等优点，因此可以简化光强的测量，大大降低成本。
TSL230可以直接和单片机连接，也可以与PC机之间通过两线通信实现远距离光强度的测量。它的输入端为多晶硅光电二极管，可将光强信号进行光电转换，把一定光谱的光转换成电流，再由电流频率转换器转换成相应的脉冲频率。输出的方波频率与光强一一对应，因此只要能计算出频率，也就能表示出光强。本系统中将单片机与可编程光频转换器TSL230结合起来就能实现光强度的低成本、高精度测量。由于单片机灵活的编程能力和很强的逻辑判断能力，既可以在线改变光频转换器的测量灵敏度，也可以随时对频率定标。
2 TSL230与MCS-51单片机的接口电路
首先，通过单片机的P1口对光频转换器TSL230的S0、S1、S2、S3进行预编程，先将P1.4～P1.1口的控制参数锁存到74LS174中，然后送入TSL230的S3～S0引脚中。而TSL230的输出波形送入MCS-51单片机的P3.2口，然后单片机测量出输出波形的周期。
3 光强度的测量过程
TSL230采用TTL/CMOS兼容的电平，可以直接和单片机联接。在测量过程中，根据被测量光的强弱应先对TSL230进行预编程，例如，要求测量灵敏度为100×，输出频率采用2分频，则MCS-51P1口的P1.4～P1.1=0111，随后将TSL230的控制数据锁存到74LS174中，P1.0发送锁存脉冲。然后，由单片机对TSL230的输出波形进行频率脉冲计数，等到定时器的定时到，响应中断后测得计数值和实际的定时值，就可以计算出待测周期，通过计算转换为光强值，送出显示后完成一次测量。
单片机的T0和T1口分别工作在定时器和计数器，取2分频后的频率信号作为计数器的输人，它的上升沿启动计数器和定时器，先扩展T1为外部中断源，产生中断时读出TO的定时值，就可测出周期。而定时器的初始值可根据对光强度测量的速率而定。根据测量的光强度判断是否修正TSL230的编程参数，接着开始下一次测量。
确定TSL230编程参数的原则是：如果被测光强较弱时，应该改变S1和S0，选取较高的灵敏度;反之，若光强较强时，或者输出频率已到达上限值时，应该改变S1和S0，选取较低的灵敏度。当被测量光源变化缓慢或不变，要求较高的测量精度时，应该改变S3和S2，选择较高的分频系数;当被测量光源变化较快时，要求快速测量时，应该选择较低的分频系数。多次分频实际上是求光强的平均值，可以得到较高的测量精度，抗干扰能力较强，但测量速率较低。在实际应用时，频率定标要综台考虑测量精度和灵敏性，以求达到最佳的测量效果。
参考文献
[1]何立民.单片机应用系统设计[M].北京:北京航空航天大学出版社,1997.
[2]胡汉才.单片机原理及其接口技术[M].北京:清华大学出版社,1996。
[3]李大友.微型计算机接口技术[M].北京:清华大学出版社,1996.
[4]赵重明.可编程光频转换器TSL230及其应用[J].仪表技术与传感器,2000:30—32
手机端时代的交通信息发布浅析 篇11
【关键词】手机端；信息化；道路交通
随着社会的不断发展，我国的道路交通拥堵的现象越来越严重，这给很多驾驶员带来很大的困扰。在道路拥挤的路段根本无法行驶，严重阻碍了人们的正常出行，随着智能手机的不断发展，交通信息利用手机端的形式向驾驶员发布，就可以使其提前了解路况信息，对改善道路交通的拥堵情况起到了重要的作用。
一、当前道路交通的形势
近几年我国的社会经济发展十分迅速，人们生活水平得到了很大的提高，更多的人们选择自己驾车去旅行、上班，这样的思想虽然促使了汽车产业的发展，但是却给道路交通带来极大的压力，特别是在上班的高峰时段，很多城市的主要路段基本上属于瘫痪的状态。如果遇到天气不好的时候，暴雨、暴雪等天气时，就会加重这种现象，由于很多驾驶员不了解道路的运行情况，所以在出行时还是选择正常的路线，这就使得拥堵的现象更加明显，而且还可能造成安全事故的发生，严重威胁着人们的生命财产安全。所以交通信息的发布对于保证道路的畅通具有重要的作用，但是交通系统在这方面的工作还不是十分到位，更多的工作只是宏观层面上的，并没有做好具体的落实工作，很多对于路况信息的发布都是依托于广播来进行的，而很多驾驶员没有收听广播的习惯，这种方法显然存在着一定的局限，无论是在信息的发不上还是接收的效果上都不是十分理想。道路交通部门在安装信息板时，一般都会选择在公路的两侧进行安装，这种对于路况的提示信息十分准确，但是只有驾驶员经过该路段时才能看到，再调整行车路线就已经来不及了，因此信息板只能起到提示道路状况的作用，并不能起到缓解交通拥堵的作用，还是存在其自身的局限性。
交通部门在利用交通广播进行播报时，虽然能对道路信息进行准确的报道，但是由于路况的信息都是由驾驶员或者交警部门提供的，都是在发生拥堵现象之后进行播报的，而在一些比较偏远的地区，很多驾驶员根本收听不到广播，因此对道路的实际状况就不了解，也无法从根本上改变道路拥堵的现象。
二、信息化时代的到来
随着信息化技术的不断兴起，道路交通部门意识到利用新技术来改变交通状况的重要性，通过部门之间的交流合作，交通部门与气象部门、地质部门等相关的管理部门建立网络系统，可以随时实现资源的共享，对道路信息的问题可以在第一时间掌握，但是在掌握信息的同时，怎样将信息第一时间发布给驾驶员是交通部门必须要思考的问题。信息时代的到来，促使着很多智能手机的出现，而且4G网络在大部门地区也已经全面覆盖，这一网络技术的产生给交通部门带来很大的便利。
（一）流媒体技术 随着信息技术的不断发展，流媒体技术逐渐被人们提及出来，其是依附于新型的数字化视频网络进行的，特别是在近几年流媒体的发展十分迅速，其技术逐渐成熟起来，而且可靠性也得到了很大的提升，很多单位都通过流媒体把信息发射给外网，然后再向大众进行发布，流媒体作为中转站，而大众可以通过下载客户端或者直接通过互联网进行观看，流媒体是通过视频的方式传播给公众，受众可以通过观看实时的路况动态来了解交通的情况。
（二）4G网络时代的到来 随着信息化发展水平的不断深入，4G网络逐渐覆盖在城市的各个角落，这一技术的兴起，使得网络之间可以形成无缝式的互联模式，而且可以在第一时间把信息传播出去，与普通的网络相比，4G网络的传播速度更加快捷，而且对于图片视频的传播质量更高，其最大的特点就是在传播速度上面，而且4G网络在很多区域内实现无线覆盖，对信息的传播更加便捷。
（三）手机端 基于手机端的交通调查及数据管理分析系统分为两大模块：手机端数据采集模块和电脑端数据分析模块。手机端数据采集模块具有交通数据调查功能，并且可以将手机端采集的数据上传至电脑端，在电脑端完成交通数据的处理分析系统，进一步得到交通分析图表近年来，随着智能手机技术的飞速发展，手机终端的价格越来越便宜，已基本实现普及。智能手机搭载的处理器和内存足以运行大型甚至超大型软件，且手机端的软件兼容性很好，可以访问现有的网络服务，手机端的服务端开发也没有太大变化，只需要在现有的服务器上添加一个普通的应用对汇总了最新路况信息的数据库进行访问，就可以让广大的智能手机用户获取到最新的实时路况信息。此外，通过添加手机客户端的消息推送功能，再辅助手机导航系统，可以给了用户最新、最及时的路况信息。充分发挥手机客户端的自媒体属性，可以让用户在无监控或者交通部门无法覆盖的区域，进行自发式实时路沉上报，然后在服务器端进行整理再推送，以完善整个路况的通报。
三、对未来的展望
综上所述，未来新一代基于大数据技术、流媒体技术、互联网服务、4G网络、智能手机技术的信息发布系统，能够将省中心汇总的气象数据、地质数据、摄像机数据存储于数据库中，由中心对数据进行访问和管理。手机用户通过下载客户端访问此类服务和流媒体服务就可以随时随地获取各路段最新的视频、气象、事故等出行信息。通过这种架构，广大司机朋友在出门前就可以通过手机提前获取各路段的路祝信息，规划行程，而在路上的司机朋友可以通过手机客户端的实时提醒，了解当前各路段的路况，对突发性事件、恶劣天气等进行很好的预警和避让。
四、总结
随着经济社会的不断发展，道路交通的拥堵现象会越来越严重，因此在第一时间对交通信息进行发布是有效缓解道路拥堵现象的重要措施，通过手机端的方式对交通信息进行发布，使驾驶员可以在第一时间接收到路况信息，然后根据实际的出行需求对选择的道路进行调整，这种方式对缓解道路拥堵的现象很有帮助，因此交通部门要不断提高对手机端的运用，更好地保证道路交通的顺畅无阻。
参考文献
[1]陈浩岩.城市智能交通中信息化技术的应用[J].科技风，2015（19）.
信息发布系统 篇12
安全稳定控制装置已经成为电力系统控制环节中不可缺少的第2、第3道防线。安全稳定控制装置的管理至关重要,搞好安全稳定控制装置的管理和运行是确保系统稳定运行的重要因素。
稳定控制信息管理系统实现对稳定控制系统的管理、远程维护,提高稳控系统的信息化、智能化水平,提高了电网管理和事故处理的速度和准确性。
随着Internet技术的发展,建立在Internet架构上的跨地区、全行业系统内部信息网已经逐步建立[1],网上应用着各种电力业务及办公系统[2]。因此,稳定控制信息管理系统的Web发布已经成为电网运行人员的日常工作之一。
以往的Web发布系统较多地使用了ActiveX控件,具有较大的安全隐患,而且当控件修改后存在升级的问题。这里介绍的Web发布系统除了波形浏览完成文件传输协议FTP(File Transfer Protocol)下载和显示波形功能外,使用了大量的Web服务器控件。Web客户端只能看到网页标识,使得系统具有较好的安全性[3]。
1 系统架构介绍
根据全国电力二次系统安全防护总体框架及其核心思想,将整个电力二次系统分为2个大区和4个安全工作区。其中,生产控制大区包括安全区Ⅰ(实时控制区)和安全区Ⅱ(非控制生产区)管理信息大区包括安全区Ⅲ(生产管理区)和安全区Ⅳ(管理信息区)[4]。
为了强化安全区之间的隔离,采用不同强度的网络安全设备(如硬件防火墙及正向、反向电力专用安全隔离装置等),使各安全区中的业务系统得到有效的保护[4]。
如图1所示,这里EMS系统在安全区1,稳定控制信息系统在安全区Ⅱ,稳定控制信息管理系统Web服务器在安全区Ⅲ,稳定控制信息管理系统与Web服务器间采用正向隔离装置Syskeeper 2000进行隔离,使得数据单向流动,从物理上保证了系统的安全。
2 软件系统架构介绍
软件系统框架如图2所示。每台计算机都安装相同的软件,然后把各台计算机配置成不同的节点类型,系统启动时根据不同的节点类型启动不同的应用模块。
下面介绍跟Web发布相关的模块。
2.1 Web数据服务器
Web数据服务器在内网和外网端都运行,主要用于通过单向隔离器发送、接收数据。自动/手动发布数据,包括事件数据、历史采样数据、文件数据、保护数据、模型数据等。
2.2 Web管理服务器
Web管理服务器只在外网端运行,用于Web管理,主要包括如下内容:
a.发布名称填入名称,用作IIS Web服务器的名字,默认为WebPub;
b.发布IP地址填入有效的IP地址,用作IIS Web服务器的IP地址,客户端也是通过这个IP地址访问Web发布系统的主页面,如http://198.87.116.24;
c.Web发布路径即网站主目录;
d.画面刷新时间一般为0.5 s;
e.数据库名称指要连接的数据库名,一般有RCS9010、RCS9012等;
f.数据库登录名称、密码连接数据库的SQL Server用户名及密码;
g.HTTP网站端口默认为80,端口被占用时改用非占用端口;
h.FTP网站端口默认为21,端口被占用时改用非占用端口;
i.实时侦听端口默认为9901,端口被占用时改用非占用端口,Web服务器通过该端口建立一个Socket侦听端,向ASP.NET Web发布平台提供数据;
j.接收Web页面的画面请求,收到画面请求后,向画面系统转发画面请求;
k.接收Web页面的保护信息请求,收到保护信息请求以后,读取实时库获得数据以后发回Web服务端。
2.3 DMIS接口
DMIS接口只在外网端运行,用于通过Web Service接口向DMIS提供保护信息数据,包括稳定装置的装置描述、装置参数、保护定值、定值区号、保护测量、保护状态、软压板、硬压板等。
2.4 ASP.NET Web站点模块
ASP.NET Web站点模块只在外网端运行。需要系统预先安装IIS和.NET Framework1.1。在系统开发中采用了VisualStudio.NET2003编程环境和SQL Server2000数据库开发平台,并以VC#.NET作为编程语言。
3 数据单向发布实现介绍
图3所示为内网到外网数据流图。
内网端稳定控制信息管理系统有一个主机节点,配置了Web数据发送功能。在主机和Web服务器上都启动Web数据服务器,内网端数据发生变化时,立即通过Web数据服务器发送到外网。
Web数据单向发布实现如下:
a.首先,外网端Web数据服务模块建立一个Socket监听端,内网端Web数据服务器发起一个与外网连接的Socket客户端,这样数据通道就可以建成了;
b.当内网端接收到数据后,仍先由各模块处理,模块处理完成后将数据打包,然后通过进程通信发送到Web数据服务模块;
c.内网端Web数据服务模块迅速将数据发到外网端;
d.外网端Web数据服务模块收到报文后,解析报文头中的源模块和目标模块,然后通过进程通信发给目标模块。
4 ActiveX控件与Web服务器控件
以往的Web发布系统较多地使用了ActiveX控件,ActiveX控件具有交互性强、反应迅速等优点,但是也具有很大的安全性问题。
ActiveX控件是一种极其危险的提供功能的方法(目前正在被MS逐渐冷落),因为它是一种组建对象模型(COM)的对象,只要电脑的用户可以完成的任务,它都可以完成。例如它可以存取注册表,可以随意访问本地文件系统等[5]。
从用户下载一个ActiveX控件开始,这个控件甚至可能很容易被攻击,因为网络上任何网络程序都可以使用它,无论是出于友好的目的还是恶意的目的。因此,浏览器总是试图弹出一个对话框来告诉你,这个控件可能是不安全的。赛门铁克安全公司在最新发表的半年网络安全报告中称,ActiveX控件占2007年下半年发现的网络浏览器插件安全漏洞的绝大部分。
ASP.NET Web服务器控件是ASP.NET网页上的对象,这些控件在该页被请求时运行并向浏览器呈现标记,在客户端看到的都是HTML标识和脚本[6,7]。其只对虚拟目录拥有读写权限,因此对客户端是相当安全的。而且,其将大量逻辑和内容封装,可维护性也大为提高。
因此,尽量少用ActiveX控件或使用相对安全的ActiveX控件,开发使用结合了XML的Web服务器控件技术是未来Web的一个发展趋势。
5 Web站点发布介绍
Web站点需安装IIS和.NET Framework1.1,包括一个网站站点和FTP站点。站点中使用了microsoft.Web.ui.webcontrols提供的TreeView控件和工具栏控件,同时也自行开发了菜单控件、日期选择控件、进度条控件等控件,使得Web页面表现更为丰富。
主要包括以下6个模块。
5.1 数据库管理模块
数据库管理模块从Web.config文件读取数据库连接字符串信息,封装了OleDb的组件形成Web服务器组件[6],为其他模块提供数据接口。
5.2 用户管理模块[8]
用户组分为超级管理员、管理员和普通用户组。超级管理员只有一个,拥有全部权限。管理员可以由超级管理员赋予权限,同时可以管理增加修改普通用户的权限。普通用户不能修改自己的权限,只能修改自己密码。
除了用户注册信息之外,权限包括如下内容:
a.模块权限配置,对用户是否拥有查看模块内容进行配置;
b.显示画面配置,对用户可以查看的画面选中/不选。
5.3 画面浏览模块
如图4所示,点击提交按钮后,Web页面向Web管理服务器请求生成指定大小的jpg图片,Web管理服务器向画面应用程序请求生成图片。当检测到文件生成后显示图片。在Web发布系统中,只能浏览数据,不能操作数据。
5.4 实时告警模块
Web页面收到请求后,根据报警级别和事件类型调用数据库管理接口获得数据并且显示实时告警数据。
5.5 事件浏览模块
事件浏览与实时告警模块原理相同,其对指定厂站和装置的历史事件和故障事件进行检索查询。
a.事件检索:当选中故障录波事件时,会显示录波波形链接。当点击波形链接后,会显示波形浏览界面。
b.故障检索:主要对故障简报进行检索,当选中某一个故障简报时,会显示相关动作事件和故障录波事件[9]。
5.6 波形浏览模块
如图5所示,ActiveX控件在页面第1次载入时自动下载到客户端,选择波形后,Web服务端从数据库读取波形文件到指定FTP站点,读取完成后调用ActiveX控件从FTP站点下载波形到Web客户端显示波形文件。ActiveX控件可以对波形文件进行放大、缩小等任意操作。
5.7 保护信息模块
如图6所示,首先,Web页面向Web服务端请求保护信息,Web服务端收到请求后,建立与Web管理服务器的Socket连接,发送保护信息的命令报文,Web管理服务器收到命令报文后,解析报文内容,得到厂站编号,装置编号,组号,保护信息类型(包括装置参数、保护区号、保护定值、软压板、硬压板、保护测量、保护状态等)[9],再访问实时库获得数据,组织后形成字符串发到Web服务端,Web服务端形成网页送到客户端。
6 结语
稳定控制信息管理系统与Web服务器间采用正向隔离装置进行隔离,使数据单向流动,从物理上保证了系统安全。本系统基于ASP.NET平台,较少地使用了ActiveX控件,较多地使用了Web服务器控件,同时又从应用程序快速准确获得实时数据。
该稳定控制信息系统和Web发布系统在南方电网、云南电网等稳控系统投入运行后,运行稳定,具有安全可靠、Web响应速度快、服务器及网络负荷小、可维护性强、接口方便等优点。
摘要：为了实现从安全区Ⅱ向安全区Ⅲ单向实时地发布Web数据，设计了稳定控制信息管理系统的Web发布系统。该系统基于ASP．NET平台，使用Visual Studio 2003开发工具开发了大量的Web服务器控件，并通过Web Service接口向DMIS系统提供保护信息数据，发布了用户管理、实时告警、事件浏览、画面浏览、保护信息浏览、波形浏览等信息，具有安全可靠、Web响应速度快、服务器及网络负荷小、可维护性强、Web Service接口方便等优点。
关键词：稳控系统,单向隔离,Web服务器,Web数据服务器,ASP．NET,Web Service
参考文献
[1]龄志渊．动态Web网页技术大全[M]．北京：清华大学出版社，1999．
[2]王楠，律方成，陈志业．等．应用Web技术远程监控变电站在线监测系统[J]．高电压技术，2002．28(9)：29—31．WANG Nan.L(?) Fangcheng,CHEN Zhiye,et al.Application of Web to realize control in on-line monitoring system[J].High Voltage Engineering, 2002,28(9):29-31.
[3]韩小涛．尹项根．张哲，等．嵌入式Web服务器技术及其在电力系统中的应用综述[J]．电网技术．2003．27(5)：58—62．HAN Xiaotao,YIN Xianggen,ZHANG Zhe,et al.Review of embedded Web server technology and its application in power system[J].Power Sys- tem Technology,2003,27 (5):58-62.
[4]朱世顺．林为民．张涛．跨区安全数据传输系统的设计与实现[J]．水利电力机械．2006．28(9)：65—68．ZHU Shishun,LIN Weimin,ZHANG Tao.Design and realization of the across area safety data transroission and its construction[J],Water Convan- cy & Electric Power Machinery,2006,28(9):65-68.
[5]王国容，朱琳杰．王伟，等．Active server pages & Web数据库[M]．北京：人民邮电出版社．2000．
[6]凯际资讯工作室．ASP．NET程序与数据库设计入门及应用实例[M]．北京：清华大学出版社，2004．
[7]廖信彦．Active server pages应用大全[M]．北京：清华大学出版社．2000．
[8]杨军，潘雪莉，张哲，等．基于Web的发变组远程监录系统[J]．电网技术．2004．28(16)：31-34．YANG Jun,PAN Xueli.ZHANG Zhe,et al.Generator-transformer unit remote fault record system based on Web[J].Power System Technolugy, 2004,28(16):31-34.
[9]李艳涛，栗然．赵敏．基于Web的继电保护管理信息系统研究与实现[J]．电力自动化设备．2003，23(11)：41—43．LI Yantao,LI Ran,ZHAO Min.Study and implementation of Web-based relay protection management information system[J].Electric Power Auto marion Equipment,2003,23 (11):41-43.
【信息发布系统】推荐阅读：
教务信息发布系统论文05-10
信息发布系统建设指南07-25
多媒体信息发布系统10-11
国家台网地震速报综合信息发布系统研究08-17
信息发布流程07-25
预警信息发布07-31
信息采集发布08-09
气象信息发布08-20
实时信息发布09-11
农业信息发布11-02