3交通指挥综合信息交换平台.docx
- 文档编号:10948515
- 上传时间:2023-05-28
- 格式:DOCX
- 页数:107
- 大小:2.17MB
3交通指挥综合信息交换平台.docx
《3交通指挥综合信息交换平台.docx》由会员分享,可在线阅读,更多相关《3交通指挥综合信息交换平台.docx(107页珍藏版)》请在冰点文库上搜索。
3交通指挥综合信息交换平台
第3章交通指挥综合信息交换平台
3.1建设综合信息交换平台的必要性
3.1.1综合信息交换平台的建设背景
1)业务背景
随着泉州市经济建设的发展,人民生活水平的不断提高,城市道路和机动车的数量不断增加。
为了更好地对道路交通进行管理,泉州市交警支队陆续建设了各种道路交通管理的信息系统。
各子系统目前基本上孤立运行,各种交通信息资源也没有共享。
如交通信号控制机只是各自独立运行,并未实现交通信号上端监控功能,路口埋设的交通流量检测线圈,以及电子警察系统检测到的城市交通流量宝贵数据没有共享利用等,投入产出比低。
从现代交通组织管理学的角度来分析,在信息采集层、决策指挥层、调度执行层这三个层面上不太协调,从时间及空间上均存在部分脱节现象,直接导致交通组织与管理在某些层面上的被动及滞后。
目前泉州市公安交通指挥中心的大部分业务系统软件都是基于客户/服务器结构的,随着业务的增加,各子系统不断增加功能,需要实现各子系统间越来越多的信息交换。
假如各子系统之间直接实现连接,当某个系统的业务或者表结构改变的时候,与之有信息交换的其它子系统都必须修改相应的有关代码。
这就引起软件没有共享,软件版本升级困难的问题,并且客户端的逻辑变得复杂,要扩展功能也很困难。
这种两层结构的客户端直接与数据库系统交互,因此也存在数据安全性的问题。
综上所述,必须建设一个各子系统可以实现信息共享的平台,它将给指挥中心业务系统带来良好的扩展性、高可靠性、安全性、数据的高处理性能和高稳定性。
2)技术背景和趋势
随着用户需求的变化越来越快,用户的要求也会随之变化,用户对系统的快速交付性、安全性、可靠性、稳定性提出了极高的要求。
因此,负责应用的软件系统遇到了很大的挑战,业务基础软件平台的出现有助于解决这些问题。
与操作系统平台、软件基础架构平台相比,业务基础软件平台和用户的管理及业务相关度比较大,是管理软件开发的通用基础平台。
它的特点如下图所示:
[图3.1.1-1]业务基础软件平台的特点
下面是现在大型复杂应用系统的实现方法,其中的业务基础软件平台和软件基础架构平台就是本系统中的信息交换平台。
软件基础架构平台是中间件一层,业务基础软件平台是以各种核心算法和数据处理为主的各种功能服务。
[图3.1.1-2]大型复杂应用系统的实现方法
后面的章节将介绍各种软件基础架构平台一层的中间件技术,并选择最佳适用于本系统的技术,然后设计业务基础软件的软件平台一层的各功能服务。
3.1.2综合信息交换平台的建设目标
交通指挥综合信息交换平台主要完成信息的共享和交换,信息的集成,完成数据的规范化,提供统一的接口,为各系统的升级提供便利,同时,通过平台,实现数据的综合使用。
如下图所示:
[图3.1.2-1]综合信息交换平台的建设目标
3.2实现综合信息交换平台的技术分析
对综合信息交换平台的设计和技术选型会影响整个系统是否能成功实施,因此在本节将详细分析实现信息交换平台的技术,并选择本设计中所要使用的技术。
综合信息交换平台是泉州市公安交通指挥中心整修升级工程各外场系统、交通信息系统、交通管理系统之间进行信息交换的枢纽,它完成交通信息的采集、处理、发布,以及控制。
为了满足这些功能,信息交换平台应具有如下性能:
跨平台性、大型应用处理能力、高可靠性、高安全性、高稳定性、高速运行业务能力。
下面是本章节选择信息交换平台技术的选择步骤,这个技术必须能够满足上面所述信息交换平台应具有的性能。
步骤1.
实现平台的体系结构选择
三层结构的选择
步骤2.
中间件技术的选择
COM+、WebService、CORBA
3.2.1平台的体系结构
目前泉州市公安交通指挥中心的大部分业务系统软件基于的是两层结构,即客户/服务器结构。
两层结构包括客户端和数据库两层,业务处理一般放在客户端,而数据则放在数据库中。
客户端直接访问数据库,进行数据读写。
这种结构带来的问题有:
Ø不灵活:
客户端和数据库联系太紧密,不容易修改。
Ø数据不容易共享:
客户端和数据库形成一个封闭的系统,不易和外界共享数据。
Ø容易产生性能问题:
在客户端数量大时,数据库的压力大,导致性能降低。
Ø可靠性低:
客户端有可能导致数据库的死锁和崩溃,进而导致整个系统的崩溃。
很明显两层结构满足不了信息交换平台的性能,因此要采用三层结构模型。
三层结构包括用户服务层、应用服务层和数据服务层。
由于这种层次结构模型的架构优越性,它的出现和发展解决了系统开发人员面临的种种问题,而本系统的交通指挥综合信息交换平台就是中间应用服务层的概念。
中间的应用服务层的具体实现是采用中间件技术实现的。
下面是当前比较典型的三层结构图。
客户端不再直接和数据库相连,而是通过应用服务器来访问数据库,并且有应用服务器管理和数据库之间的连接。
当然,现在的应用服务器除了提供数据库的访问功能外,还提供更加广泛的服务,如事务处理、消息、命令、数据加密、安全管理等。
它完全克服了两层结构的缺点。
[图3.2.1-1]三层结构图
三层结构模型具有下列优点:
1、系统灵活性:
由于客户端不再直接和数据库相连,可以通过在应用服务上的修改来更改系统,提高了灵活性。
2、数据共享:
由于通过应用服务器来访问数据库,其它系统也可利用应用服务器提供的功能来访问数据库。
3、提高性能:
由于应用服务器提供了数据库的连接管理以及集群等服务,可以提高整个系统的性能。
4、可靠性高:
应用服务器提供集群及容错处理,可以大大提高系统的可靠性。
5、便于移植和开发:
因为把系统分为表现层、业务处理层、数据层,可以很方便地进行移植及开发。
基于三层结构的以上优点,本系统使用结构为三层结构,三层结构中的中间层用中间件实现。
3.2.2中间件介绍
解决“信息孤岛”问题的关键在于实现异构应用系统的整合和共用数据的共享,而基于分布式对象的中间件技术的位置透明性、语言无关性和平台独立性等特征为上述问题提供了强有力的解决方案。
通过中间件技术的封装,集成软件系统各组成部分可以屏蔽掉来自网络硬件平台、通信协议、数据来源、开发语言、甚至操作系统的差异,进而确保整个系统的开放性、可伸缩性、灵活性、互操作性、可扩展性和易维护性的实现。
中间件是处于应用软件和系统软件之间的一类软件,是独立于硬件或数据库厂商(处于其产品的中间,实现其互连)的一类软件,是客户方与服务方之间的连接件,是位于操作系统和应用软件之间的通用服务。
它的主要作用是用来屏蔽网络硬件平台的差异性和操作系统与网络协议的异构性,使应用软件能够比较平滑地运行于不同平台上。
同时中间件在负载平衡、连接管理和调度方面起了很大的作用,使软件应用的性能得到大幅提升,满足了关键业务的需求。
分布计算是指网络中两个或两个以上的软件相互共享信息资源。
这些软件可以位于同一台计算机中,也可以部署在网络节点的任意位置。
基于分布式模型的软件系统具有均衡运行系统负载、共享网络资源的技术优势。
分布对象又称组件(Component),它是一些独立的代码的封装体,在分布计算的环境下可以是一个简单的对象,但大多数情况下是一组相关的对象复合体,提供一定的服务。
组件是一些灵敏的软件模块,它们可以位置透明、语言独立和平台独立地互相发送消息,实现请求服务。
分布式对象技术主要使用了面向对象技术的封装性,组件可以分布在网络的任何位置。
对外界来说,它所需关心的只是组件的界面,至于内部是如何实现的则无需考虑,远程客户通过调用方法来访问它。
当前主流的分布式中间件技术主要有OMG的CORBACCM(CORBAComponentModel)技术、Sun的EJB(EnterpriseJavaBean)技术、MicrosoftDNA2000的COM/COM+/COM+技术和当前最为流行的WEBSERVICE技术。
它们都是支持服务器端中间件开发的中间件技术,但都有其各自的特点。
COM+是Microsoft的COM(组件对象模型,ComponentObjectModel)的分布式扩展,它在DCERPC的顶端建立了一个对象远程过程调用(ORPC)层来支持远程对象。
COM服务器能创建多对象类的对象实例。
一个COM对象可以支持多个接口,每个接口代表对象的一种不同的视图或行为。
一个接口由一套功能相关的方法组成。
COM的客户程序通过获取指向一个对象接口的一个指针,并通过该指针来调用方法以实现与COM对象之间的互相作用,如同对象驻留在客户程序的地址空间中一样。
COM指定任何接口都必须遵循一个标准的内存规划,这与C++的虚拟函数表相同。
由于该规范是二进制级别的,因此它允许集成可能用不同编程语言如C++、Java和VisualBasic等编写的二进制组件。
CORBA(CommonObjectRequestBrokerArchitecture,公共对象请求代理体系结构)是由OMG(对象管理组织,ObjectManagementGroup)提出的应用软件体系结构和对象技术规范,其核心是一套标准的语言、接口和协议,以支持异构分布应用程序间的互操作性及独立于平台和编程语言的对象重用。
CORBA基于网络的分布式应用环境下实现应用软件的集成,使得面向对象的软件能够在分布、异构环境下实现可重用、可移植和互操作。
EJB的全称是Enterprise java bean。
是JAVA中的商业应用组件技术。
EJB结构中的角色 EJB 组件结构是基于组件的分布式计算结构,是分布式应用系统中的组件。
EJB分布式应用程序是基于对象组件模型的,低层的事务服务采用了API技术。
EJB技术简化了用JAVA语言编写的企业应用系统的开发、配置。
EJB技术定义了一组可重用的组件:
Enterprise Beans。
可以利用这些组件象搭积木一样的建立系统分布式应用程序。
当把代码写好之后,这些组件就被组合到特定的文件中去。
每个文件有一个或多个Enterprise Beans,在加上一些配置参数。
最后,这些Enterprise Beans被配置到一个装了EJB容器的平台上。
客户能够通过这些Beans的home接口,定位到某个beans,并产生这个beans的一个实例。
这样,客户就能够调用Beans的应用方法和远程接口。
上面分别简单介绍了CORBA、EJB和COM+三种分布式中间件技术,他们各自的特性比较如下表所示:
特性比较
CORBA
EJB
COM+
集成性
跨语言性
好
差(限于JAVA)
好
跨平台性
好
好
差(限于WINDOWS)
网络通讯
好
好
好
公共服务构件
好
好
一般
可用性
事务处理
好
一般
一般
消息服务
一般
一般
一般
安全服务
好
好
一般
目录服务
好
一般
一般
容错性
一般
一般
一般
软件开发商支持度
一般
好
好
产品成熟性
一般
一般
好
可扩展性
好
好
好
WEBSERVICE是一种无须专门采购和配置的组件,这种组件是被一次部署到Internet/Intranet中,然后到处可用的一种新型组件,所有应用只需要能够连入Internet/Intranet,就可以使用和集成Web服务。
通过采用Web服务,开发的代价显著降低了,程序员无须与多种平台进行交互,只需要与一种组件进行交互,即Web服务,同时Web服务的调用界面完全采用标准的XML及相关技术,在代码实现上代价也有显著下降。
通过采用Web服务,部署和集成的费用大大降低,流程的更改也无须更改大量代码,甚至通过工具的支持,根本无须更改程序代码。
同时随着新的Web服务技术,WSDL/UDDI/WSFL的大量使用,Web服务可以在运行时态进行动态装配,可以应每个用户的需要而实时装配。
从外部的用户的角度而言,Web服务是一种部署在Web上的对象/组件,它具备以下特征:
Ø完好的封装性,Web服务是一种部署在Web上的对象,具备对象的良好封装性,对于用户而言,能且仅能看到该对象提供的功能列表。
Ø松散耦合,这一特征源于对象/组件技术,当一个Web服务的实现发生变更的时候,用户是不会感到这一点的,对于用户来说,只要Web服务的调用界面不变,Web服务的实现任何变更都是透明的,甚至当Web服务的实现平台从J2EE迁移到了.NET或者是相反的迁移流程,用户都可以对此一无所知。
对于松散耦合而言,需要有一种适合Internet环境的消息交换协议,XML/SOAP正是目前最为适合的消息交换协议。
Ø使用协约的规范性,这一特征从对象而来,但相比一般对象其界面规范更加规范化和易于机器理解。
首先,做为Web服务,对象界面所提供的功能应当使用标准的描述语言来描述(比如WSDL)。
同时使用标准描述语言描述的使用协约不仅仅是服务界面,它还被延伸到Web服务的聚合、跨Web服务的事务、工作流等,而这些又都由服务质量(QoS)的保障。
其次,由于安全机制对于松散耦合的对象环境的重要性,因此需要对诸如授权认证、数据完整性(比如签名机制)、消息源认证以及事务的不可否认性等等运用规范的方法来描述、传输和交换。
最后,在所有层次的处理都应当是可管理的,因此需要对管理协议运用同样的机制。
Ø使用标准协议规范,作为Web服务,其所有公共的协约完全需要使用开放的标准协议进行描述、传输和交换。
这些标准协议具有完全免费的规范,以便由任意方进行实现。
一般而言,绝大多数规范将最终有W3C或OASIS作为最终版本的发布方和维护方。
Ø高度可集成能力。
由于Web服务采取简单的、易理解的标准Web协议做为组件界面描述和协同描述规范,完全屏蔽了不同软件平台的差异,无论是CORBA、COM+还是EJB都可以通过这一种标准的协议进行互操作,实现了在当前环境下最高的可集成性。
选择最适合本工程需求的中间件技术平台从以下几个方面考虑:
1、考虑现有应用系统的操作系统、开发语言、数据库等开发环境。
2、考虑本工程软件系统的性能需求:
高可靠性、高安全性、高稳定性、跨语言、高速运行能力、大型应用处理能力。
3、考虑将来新建子系统的易扩充能力,增加修改功能的易扩展能力,以及维护效率。
本系统的分布式应用支撑采用完全开放的消息传送中间件提供分布信息交换,分布式信息处理通过XML消息解析处理完成,基于XML消息解析的信息交换和处理机制以及安全可靠的透明的消息传送中间件共同构成完全松散耦合的分布应用环境,因此中间件技术在本系统内主要应用于具体业务逻辑处理模块的分布式应用。
在这种情况下,可以根据实际情况结合用户需求灵活选择上述中间件技术实现相应的分布式应用。
3.3综合信息交换平台的功能分析
本节首先分析综合信息交换平台的功能,分别按业务角度、按用户角度、按信息交换平台在整个公安交通指挥中心的作用角度分析,通过这三方面的分析得出信息交换平台的功能。
3.3.1业务角度的功能分析
首先按业务角度分析交通指挥综合信息交换平台的功能,下面是功能导出图:
[图3.3.1-1]平台的功能导出图
从上面的功能导出图中可以得出以下结论:
信息交换平台从交通控制和监控系统中采集各种交通信息,从交通管理系统中采集交通管理信息,因此信息交换平台中需要信息采集功能模块。
采集到的信息经过数据处理才能得出用户可识别的信息,因此信息交换平台需要数据处理功能模块。
通过数据处理的可识别的信息要发布到交通诱导系统、交通信息发布网站等信息系统,因此信息交换平台需要信息发布功能模块。
通过数据处理的信息也要用于信号控制、CCTV控制等,并且还需要现场设施的监控,因此信息交换平台需要交通控制功能模块。
3.3.2用户角度的功能分析
从用户的角度分析泉州市公安交通指挥中心指挥调度系统所实现的作用如下表所示:
类型
提供的服务
服务内容
期待效果
指挥中心值班人员和领导
交通状况监视
交通拥堵状况
交通流量信息
交通现场视频信息
交通信号状态
设备运行状态
能够以实时的方式,准确的获取当前的交通状况信息及各种设备的工作情况,以便及时处理各种可能发生的异常情况
交通事故处理
交通事故警情信息
事故处理指挥调度信息
事故处理结果
及时、有效的处理各种交通事故,并详细的记录事故的处理过程与结果
交通指挥调度
交通指挥警令信息
能够及时、方便的对现场警员下达命令,以便于准确有效的进行各种警力调度。
交通控制
交通信号控制
视频监控云镜控制
治安卡口追逃布控
能够方便的在远程控制各种交通指挥设备和交通监控设备
交通管理
机动车、驾驶员档案
警务情况
交通事故信息
违章信息
简化各种档案数据的管理,能够简单、方便的对各种档案信息进行增加、检查修改、查询的操作
交通诱导
交通诱导信息
停车泊位诱导信息
语音诱导信息
能够方便、准确的发布各种诱导信息
道路使用者
交通诱导
交通诱导信息
语音诱导
准确的获取当前的交通状况,以便有效的选择行驶路线
交通信息查询
交通状况信息
违章处罚信息
交通新闻信息
可以有选择的、方便的获取各种需要的交通信息
其中,对交通状况的监视和服务需要信息交换平台采集各TCSS子系统的交通信息,经过加工处理后生成用户可识别的信息,以信息订阅的形式提供给用户服务层各应用软件,由用户服务层最终实现对用户的交通状况监视服务。
交通事故处理服务需要平台采集来自122接处警系统的交通事故警情信息,并通过消息服务提供给用户服务层,同时,信息交换平台还应对警情信息、处警信息、处警结果等交通事故处理相关信息进行相应的数据处理。
交通指挥调度服务主要由用户服务层的封装业务逻辑,但信息交换平台需要对该服务提供警令上传下达通道以及相应的信息支持服务。
交通控制服务需要平台提供对相应TCSS子系统的控制功能接口。
交通管理服务需要平台提供对各种相关交通管理系统的信息和指挥中心业务范围之内的交通管理信息处理功能。
交通诱导服务和交通信息查询服务需要平台提供对各种可以对外发布的交通信息以及发布途径。
根据上述分析,可以总结出信息交换平台应该具有以下功能服务模块:
信息采集模块、数据处理模块、交通控制模块、消息服务模块和信息发布模块。
3.3.3平台作用的分析
交通指挥综合信息交换平台最主要的功能是整合现有的各子系统,即实现交通控制信息的采集,并且处理采集的信息,生成可发布、可查询的数据用于交通诱导和信息发布,同时生成交通管理用的数据用于交通管理,同时还生成交通控制信息实现交通的实时控制。
具有空间属性的所有信息通过交通地理信息系统电子地图集成作为交通集成指挥调度功能的基础。
整体上实现交通指挥调度综合业务和交通信号的上端控制、交通诱导、信息查询等功能服务。
信息交换平台必须提供消息服务,用来解决各交通业务子系统之间、业务子系统与信息交换平台之间、应用系统与信息交换平台之间和信息交换平台内部各分布式模块之间的信息通信。
此外,信息交换平台还必须提供安全控制和系统管理功能,在软件级保证整个系统的安全稳定运行,并以统一系统管理的方式提供用户方便、简捷的系统维护手段。
通过上述信息交换平台的功能分析,可以归纳出如下8个功能模块。
1)数据采集模块:
负责所有信息的采集,包括常规数据采集、突发数据采集和交通管理信息采集。
其中常规数据采集模块负责采集来自TCSS的各种交通数据,突发数据采集模块负责采集来自EMS的各种突发数据,交通管理信息采集模块负责采集来自交通管理信息系统的各种交通管理信息。
2)设备控制模块:
向应用系统或平台内其他模块提供交通控制功能,接收各种控制信息,然后实施对应的交通控制。
主要包括:
交通信号控制、视频监控系统的云镜控制、治安卡口系统的追逃布控等控制功能。
3)数据处理模块:
处理所有从数据采集模块采集到的信息,根据数据来源和相关描述信息进行对应的加工处理以及入库存储等基本处理。
此外,根据具体情况,对数据进行分析,感知到事件后生成事件消息进行发布;或者对数据进行相关统计分析,将统计分析机构入库存储或发布;也针对特定发布需求进行定制的数据加工,然后对外发布。
4)信息发布模块:
根据不同信息发布需求制定相应发布主题,向发布信息需求系统直接提供各种对应的可用信息,同时也提供对应主题信息的数据查询接口,便于信息发布用户灵活定制相应的数据。
主要的信息发布用户有集成指挥调度系统、交通诱导系统、与非公安信息系统的数据交换平台,以及将来可能扩展的交通信息发布网站、触摸屏查询系统、PDA移动查询系统、手机短信订阅系统等。
5)命令解析模块:
命令解析模块是信息交换平台向应用层提供统一规范的功能接口的基础,它负责接收应用系统向平台发起的各种功能请求,对其进行解析后通知具体实施模块执行应用系统请求的功能。
命令解析模块为平台的功能扩展提供了基础,通过修改命令解析模块的平台功能配置表可以方便地动态扩展平台功能。
6)消息服务模块:
负责向系统的分布式应用提供实时的、高效的、可靠的、跨越不同操作系统、跨越不同网络环境的消息传送服务,实现各交通业务子系统之间、业务子系统与信息交换平台之间、应用系统与信息交换平台之间和信息交换平台内部各分布式模块之间的信息通信。
7)安全控制模块:
安全控制模块是系统安全保障的基础,它提供可靠的用户身份和权限验证模型,确保用户对系统功能访问的合法性。
8)系统管理模块:
系统管理模块提供动态维护系统运行参数的功能,使得应用层可以实现动态检测系统运行状态和修改系统运行参数的系统管理软件,进而减少系统管理的工作量,降低系统维护成本。
平台的层次结构如下图所示:
[图3.3.4-1]综合信息交换平台层次结构图
通过上图可以看到,平台内部的数据采集模块和设备控制模块主要与数据层各业务子系统以及已有的交通管理信息系统通信,采集相关数据和发送控制命令。
数据处理模块从数据采集模块获取数据,进行相应的加工处理,生成用户可识别的信息交付、信息发布模块。
同时,数据处理模块还提供用户权限信息管理、系统配置数据管理、GIS空间数据获取、设备数据管理等基础信息管理服务。
信息发布模块和命令解析模块共同构成应用程序接口,信息发布模块通过灵活的订阅/发布机制向应用层提供由数据处理模块加工生成的用户可识别的各种交通信息及系统信息。
命令解析层则接收来自应用层的各种功能请求信息,对其进行解析后转交给具体功能服务模块:
数据处理模块、设备控制模块、系统管理模块、数据采集模块。
消息服务、安全管理和系统管理三个模块贯串整个平台。
其中,消息服务是整个系统的通信基础,它不仅负责数据层各业务子系统与平台的通信,应用层各应用系统与平台的通信,同时还负责平台内部各功能模块之间的信息通信,才能真正成为整个系统信息交换的枢纽。
安全管理模块主要负责用户身份和权限验证,应用层向平台发起的每一个数据获取和功能执行请求都必须通过安全管理模块的合法性验证,以保证系统的安全稳定。
系统管理模块负责提供对平台内各模块以及业务子系统的运行状态监控以及运行参数动态修改功能,以便系统故障诊断及修复,便于管理员对系统的维护。
3.3.4综合信息交换平台的功能
首先从各业务子系统中采集交通流量信息、外部系统的静态信息、违章信息、事故发生信息等,然后对采集到的各种信息进行相应的数据处理,包括数据存储处理、数据加工处理、统计分析处理、事件感知处理等。
经过数据处理模块的加工处理,生成用户可识别的发布信息,到信息发布模块,提供给各应用系统和交通信息系统。
在发布信息中,所有具有空间属性的信息将集成并显示在集成指挥调度应用系统的GIS电子地图上,用于交通综合态势监视、也用于交通指挥调度和交通管理。
此外,发布信息还主要提供给交通诱导系统和与非公安信息系统,实现交通信息对道路使用者和其他外部信息系统的数据共享。
这些数据也存储到数据库以及数据仓库中,通过数据处理的统计
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 交通 指挥 综合信息 交换 平台