APP下载

城市应急联动平台与应用软件总体架构

2011-06-07深圳市公共安全应急平台关键技术研究开发中心

智能建筑与智慧城市 2011年10期
关键词:组件架构逻辑

文|深圳市公共安全应急平台关键技术研究开发中心 姜 彤

城市应急联动平台是一个城市应急信息的汇聚点和全市应急信息的管理中心,其应用软件是调度与控制城市应急联动平台各类硬件与接入系统的核心设施,必须精心规划。

1 城市应急联动工作平台

城市应急联动平台负责110、119、122、120、非紧急报警(12345)等紧急及非紧急事件的综合接警处置,同时定时向市政府应急指挥平台报送警情及处警情况汇总信息。

当发生需要多部门联合处置的事件时,城市应急联动平台负责进行统一指挥,协调各部门联合参与行动,实现各种应急处置力量和非紧急处理部门的一体化的协同与联动,以应对和协调解决各类突发事件。

1.1 系统结构和组成

联动工作平台逻辑上分为三层:表示层、业务逻辑层、数据服务层。通过业务逻辑层进行业务和数据的融合,并通过接口进行面向外部系统的控制,相互关联,形成一个有机的整体。作为应用系统运行、维护、交互的平台,可以快速创建、组装、部署和管理动态的应用逻辑,并支撑应用正常运行、提供通用组件服务、并支持应用的扩展。联动工作平台三层架构,如图1所示。

1.2 逻辑结构

从集成角度来分析,联动工作平台是以消息交换/业务协同服务集成席位软件为核心,集成了综合接警系统、警务处置系统、非警务处置系统、联动跟踪管理系统、数字录音系统、通信调度系统、GIS系统、计算机网络系统、图像监控和大屏幕显示系统等,这些系统构成了一个运作整体。联动工作平台集成逻辑架构,如图2所示。

1.3 建设思路

城市应急联动指挥中心采取依托城市公安三台合一系统基础上建设的“3+X”模式的指挥调度系统,是符合我国城市管理体系的现状。

目前城市已经建设有公安三台合一指挥中心、119消防指挥中心、120医疗救护中心,每个指挥中心均为独立接处警,相互之间信息资源无法共享。

不同的专业指挥中心有着不同的业务要求,各个专业的指挥中心对各自的业务理解也不同,专业事故的处置需要具备专业的知识。

图1 联动工作平台三层架构

图2 联动工作平台集成逻辑架构

应急联动的业务要求打破现有各专业指挥中心分散指挥的现状,建立统一的接处警平台,在发生公共安全事件时实施统一的指挥调度,不同警种和不同部门之间进行良好的配合和协调,尽可能地减少灾害所造成的损失。

考虑到专业指挥中心已经建设到位的客观现实,以及专业指挥中心对于人员素质的要求,同时又要实现城市应急联动指挥中心“统一接报,分类处置,综合调度,共享信息,快速反应,联合行动”的建设需求,应急联动指挥中心建设采取“两步走”的实施策略。

应急联动指挥中心的建设要打破目前政府某些“条块分割”的现状,一步到位往往比较困难。因此应急联动指挥中心的建设“两步走”的实施策略是:

第一步:首先实现公安内部“三台合一”、120的完全整合,实现四台合一业务的互联互通和联动,如图3所示。

110/122/119/120的业务集成到应急联动指挥中心来,物理位置均设置在应急联动指挥中心内,而报警由接警员统一接警,处置由专业处警员来完成。

电话接入后,报警电话由ACD按一定的策略分配到接警席,如电话为110/119/122/120报警,则接警员询问信息并记录后,分配到相应的处警席处置。接警席接通电话时系统自动显示三字段信息并在地图上GIS定位。接警员受理后填写接警单相关内容,按照事故类型分发到不同类型的处警坐席。处警员借助于辅助决策系统的GIS应用(重大警情调用预案指挥调度系统),快速和准确处警到各个相关一线警力单位,同时根据需要可通过调度无线电台和有线电话进行语音处警。警力出动后,实时通过电台与指挥中心联系,将案件的结果反馈到指挥中心。整个报警事件受理和处置过程全程录音,过程中产生的录音、案件信息以及各种指令均保存在指挥中心的数据库中。

第二步是完成12345非警务处置系统软件的改造。应急联动中心经过一段时间的运行以后,无论是业务还是技术都已经磨合得比较成熟,此时进行12345非警务处置系统改造就水到渠成。

1.4 接处警模式

根据目前城市的紧急及非紧急事件的日均电话呼入量,为确保今后接处警工作顺畅、规范,下达指令快速、准确,紧急及非紧急事件处置及时、有效,联动工作平台接处警模式建议采用“统一接警,接处分开,分级分类处警”的工作模式。

按照这种模式,全市所有报警电话由应急联动指挥中心统一受理,合理分配到接警席,由接警员对报警信息进行辨识、预处理后,按照突发事件的警情,由专业的处警人员进行分类处置。

对于紧急事件,实现公安110、消防119、交警122、急救120的特服号码一体化,并以110作为紧急事件的代表号码。公众只要拨打110或者其他任何一个特服号码,都可以得到一种或多种应急处置力量的响应。

对于非紧急事件,以市长热线“12345”整合政府的市政、环保、安监、工商等政府部门以及水、电、气等公共服务机构的面向公众投诉、咨询和服务的各种号码资源,实现123XX的特服号码一体化。

图3 四台合一业务的互联互通和联动示意图

2 城市应急联动平台应用软件系统

2.1 应用系统软件的三层架构

城市应急联动平台应用系统软件一般采用B/S和C/S相结合模式的三层(N层)架构策略,应急管理、业务系统查询统计等基本功能采取B/S架构实现。语音调度、短信调度、传真收发等对系统稳定性和时效性要求较高的功能应用采取C/S架构实现。如图4所示。

B/S架构无需像C/S模式那样在不同的客户机上安装不同的客户应用程序,只需安装通用的浏览器软件。这样不但可以节省客户机的硬盘空间与内存,而且使安装过程更加简便、网络结构更加灵活。

B/S架构简化了系统的开发和维护。系统的开发者无须再为不同级别的用户设计开发不同的客户应用程序,只需把所有的功能都实现在Web服务器上,并就不同的功能为各个组别的用户设置权限就可以了。各个用户通过HTTP请求在权限范围内调用Web服务器上的不同处理程序,从而完成对数据的查询或修改。

B/S架构的维护具有更大的灵活性。当需求变化时,无须再为每一个现有的客户应用程序升级,只需对Web服务器上的服务处理程序进行修订。这样不但可以提高公司的运作效率,而且省去了维护时协调工作的不少麻烦。尤其在本系统客户机数量较多,并且分布在不同的地点的时候,便于维护将会显得更加重要。

B/S架构使用户的操作变得更简单。采用B/S模式时,客户端只是一个简单易用的浏览器软件。无论是决策层还是操作层的人员都无需培训,就可以直接使用。

2.2 应用软件技术架构

城市应急联动平台应用系统软件一般采用J2EE作为软件技术架构。J2EE是Java 2平台企业版(Java 2 Platform Enterprise Edition)的各词组首字母的缩写。它被定义为应用于设计、开发和部署多层、基于服务器的应用程序的所有方面的标准。

图4 B/S和C/S相结合模式的三层(N层)架构策略图

2.2.1 J2EE 多层模型

J2EE 使用多层的分布式应用模型,应用逻辑按功能划分为组件,各个应用组件根据他们所在的层分布在不同的机器上。事实上,J2EE 的设计初衷正是为了解决两层模式(Client/Server)的弊端,在传统模式中,客户端担当了过多的角色而显得臃肿,在这种模式中,第一次部署的时候比较容易,但难于升级或改进,可伸展性也不理想,而且经常基于某种数据库协议,使得重用业务逻辑和界面逻辑非常困难。现在J2EE 的多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层。J2EE应用程序是由组件构成的,J2EE组件是具有独立功能的软件单元,它们通过相关的类和文件组装成J2EE应用程序,并与其他组件交互。J2EE 典型的四层结构是:

(1)运行在客户端机器上的客户层组件。

(2)运行在J2EE 服务器上的Web 层组件。

(3)运行在J2EE 服务器上的业务逻辑层组件。

(4)运行在EIS 服务器上的企业信息系统层软件。

如图5所示。

图5 J2EE 典型的四层结构图

2.2.2 J2EE各层的组成

(1)客户层

J2EE 应用程序可以基于Web方式,也可以基于传统方式。客户层组件包括应用客户端程序和Applets。

(2)Web层

J2EE Web层组件可以是JavaServer Pages(JSP)或Java Servlet。按照J2EE规范,静态的HTML页面和Applets不算是Web层组件。Web层可包含某些JavaBean对象来处理用户输入,并把输入发送给运行在业务层上的Enterprise Bean来进行处理。

(3)业务逻辑层

业务层代码的逻辑用来满足特殊商务领域的需要,由运行在业务层上的Enterprise JavaBeans(EJB)进行处理。有三种企业级 的 Bean:会 话(Session)Beans、 实体(Entity)Beans和消息驱动(Bmessage-Driven)Beans。会话Bean表示与客户端程序的临时交互。当客户端程序执行完后,会话Bean和相关数据就会消失。相反,实体Bean表示数据库表中一行永久的记录。当客户端程序中止或服务器关闭时,就会有潜在的服务保证实体Bean的数据得以保存。消息驱动Bean结合了会话Bean和JMS的消息监听器的特性,允许一个业务层组件异步接收JMS消息。

(4)信息系统层

信息系统层处理企业信息系统软件包括基础建设系统(例如大型事务处理、数据库系统)和其他的遗留信息系统。例如,J2EE应用组件可能为了数据库连接需要访问信息系统。

2.3 应用软件系统总体架构

应用软件系统的总体架构包括系统内核、业务功能、外部系统和数据中心等四大部分组成,如图6所示。其中系统内核采用C/S和B/S相结合三层(N层)结构系统的模式,包括消息服务、协同服务、系统业务组件、系统通用组件、系统支撑服务、统一接入接口、统一交互接口等组成。外部系统包含了有线无线通信、传真、技防、手机定位、短信、会议系统等。系统内核采用统一接入接口和统一交互接口,实现与外部系统、业务系统的连接和集成。

图6 应用软件系统总体架构

猜你喜欢

组件架构逻辑
基于FPGA的RNN硬件加速架构
刑事印证证明准确达成的逻辑反思
无人机智能巡检在光伏电站组件诊断中的应用
逻辑
创新的逻辑
功能架构在电子电气架构开发中的应用和实践
新型碎边剪刀盘组件
U盾外壳组件注塑模具设计
基于云服务的图书馆IT架构
女人买买买的神逻辑