1. CERS的分析与建模
1.1 CERS
1.1.1 什么是CERS
公共安全和公众服务成为政府部门一项非常富有挑战性的工作。如何高效利用有限的资源,提高政府对紧急事件快速反应和抗风险的能力,并为市民提供更快捷的紧急救助服务,日益成为加强城市管理的主要内容之一。当社会发生犯罪、火灾、爆炸等各种警情,群众医疗急救、煤水电抢修等各种紧急求救事件,地震、火灾、海潮等突发自然灾害,以及社会动乱、战争等各种重大紧急事件时,需要政府统一协调、统一调度相关部门协同工作。随着社会的不断进步,社会发生紧急突发事件的种类更加复杂与多变,传统的应对机制已不能适应日益增多的紧急突发事件处置的需要。当社会发生重大事件时,不是哪一家或哪几家单位能够解决的,这就需要联合多家或所有社会单位共同解决。
社会应急联动系统就是综合各种城市应急服务资源,采用统一的号码,用于公众报告紧急事件和紧急求助,统一接警,统一指挥,联合行动,为市民提供相应的紧急救援服务,为城市的公共安全提供强有力的保障的系统。CERS大大加强了不同警种与联动单位之间的配合与协调,从而对特殊、突发、应急和重要事件做出有序、快速而高效的反应。
1.1.2 为什么需要城市应急联动系统?
随着社会经济文化生活的不断发展和进步,如何高效利用有限的资源,提高政府对紧急事件快速反应和抗风险的能力,并为市民提供更快捷的紧急救助服务,重要性日益凸显。
目前存在多个公众特服号码,比如:公安-110、警情--119、急救-120、交警-122,市民难于记忆。水、电、气等公共服务号码更不为人知晓,因此市民不便于得到相应的服务,救助和保护。由于缺少一个统一的指挥调度平台,不同警种和部门之间无法进行很好的配合与协调,联合行动的实施面临着许多诸如部门分割、利益关系以及技术实现等诸多方面的困难;CERS使得市民的任何报警,求助只需拨打同一个号码,不再需要记忆诸多特服号码(比如:110、122、119、120等),缩短报警时间,大大方便了市民报警,并得到及时的救助和相应的服务。
CERS可使接警和处警都更加准确和快速,为警力的快速反应提供有力的保障,从而大大提高城市对突发、应急、特殊和灾难性事件的快速反应能力,在加大对犯罪的打击力度,维持社会秩序,缩短对市民求助的反应时间,保护生命财产等方面都将起到十分重要的作用。
CERS也打破了现有多个指挥中心间的数字鸿沟,使离散的数据库和信息资源得以互联和共享,发挥更大的作用;
由于采用了统一的指挥调度系统,不同部门、不同警区和不同警种之间得以互通和相互协调、配合,使统一指挥、协调作战成为可能,真正实现了社会服务联合行动。
1.2 应用现状
目前,世界上许多国家都采用不同的三位数字电话号码,作为全国处理紧急呼救的特服号码。例如:美国采用911,英国采用999,比利时采用900。早在1937年,英国就开始使用号码999,用以报告紧急情况的发生。当电话999被拨打时,在英国电信接线员的操作台上会出现闪光,呼叫将立即得到应答并马上被转给适当的单位,例如:警察局、消防局或急救中心。比利时于1964年开始启用900紧急呼叫号码,其报警电话的工作模式是,每个电话局都设有一个紧急电话应答中心。瑞典建立的900,则由一个SOS报警中心负责接收所有居民的报警和求助电话。 日本、法国、德国、加拿大、香港等技术先进的国家和地区都相继建立了以城市为区域中心的区域报警、求助应急处置体系。通过一个特服号码电话报警求助,指挥中心依据报警求助内容,分别调动警察、消防、医疗急救、水电抢险等部门进行紧急处置或联合行动处置。
美国于1967年提议在全国范围内使用一个单一的号码,用于市民报警和求助,打破了多个特服号码共存的状况。美国从上个世纪60年代开始进行城市社会应急联动中心的建设至今,应急联动中心(911中心)已遍布美国的各个州市。美国9ll服务开通以后,各州市有了统一的应急联动中心和通信系统,警察、消防和急救等部门采用现场合署办公的方式处理各类紧急事件。当市民拨打911电话后,由911中心的接警员统一接警,根据事件内容,迅速做出反应,联合各相关部门统一处置。市民在很短时间内便可得到最快速的救援和服务。
南宁市CERS已开通,它模仿美国芝加哥911模式,即“大使馆”制模式。新建指挥中心大楼,指挥大厅内设置了110指挥席位、119消防指挥席位、120医疗急救席位、122交通事故报警急救席位和为民服务网络12345市长公开电话席位。群众拨打统一的“110”电话,根据群众报警内容,分转到110、119、120、122或12345等相应席位,一般事件各席位各尽其职,下达指挥命令,重大事件由指挥长台,协调各警种统一指挥。实现了跨部门、跨警区以及不同警种之间的统一协调指挥,使统一特服号码、统一接警、联合行动成为现实,也使报警和联动出警更加准确、快捷和高效。
此外,北京、上海、天津、深圳、南京、大连、济南、成都等城市的联动系统都已开始建设。城市应急联动系统涉及多个业务领域,是实时性要求很高的分布式系统。
1.3 CERS业务建模
1.3.1 概述
系统分析是系统设计的基础。分析的成果是系统的业务机构模型和业务流程模型。
模型分两个层次:联动层次或应急业务系统层次。应急业务系统指的是各联动单位如110、119、120等。联动层次在此层次之上。
我们对用户的操作方式和目的,以及现有用户的结构进行分析,将系统用户分为五类:
○ 第一类是系统维护用户;
○ 第二类是接警处警用户;
○ 第三类是业务专业用户;
○ 第四类是Internet用户;
○ 第五类是报警用户。
通过对这五类用户的功能需求分析、角色分析,形成了系统的功能设计。其中,接警、处警用户包含受理类、调度类、处置类和移动指挥类用户等;报警方式有有线/无线报警、专业/普通报警网络。
1.3.2 应急联动业务机构模型
![](http://www.echinagov.com/echinagov/redian/images/2006625163.jpg)
CERO(Coalition Emergency Response Organization)的层次结构分为六级。
(1)决策指挥中心
设在市委与市政府,处理紧急重大事件。
(2)应急联动中心
一般设在公安局,职责是统一接警、跨警种或跨区事件的协调处理。
(3)各联动单位的调度中心
负责公安、消防等单一警种的事件调度处理。如原110、119、120、122、电力、地震等的调度中心。
(4)联动单位的分支机构
是设在城市不同区的处置力量的主管分支部门。如:消防支队、交管支队等。
(5)处置力量部门
是实际处置事件的部门。如:消防中队、派出所、急救站等。
(6)处置力量编组
是实际处置事件的编组。如:消防车、巡警车、急救车等。
1.3.3 联动业务流程模型
![](http://www.echinagov.com/echinagov/redian/images/2006625164.jpg)
图1-2 CERS的业务流程示意图1
![](http://www.echinagov.com/echinagov/redian/images/2006625165.jpg)
图1-3 CERS的业务流程示意图2
(1)发现警情报警
公众需要紧急救助时,只需要拨打一个城市应急联动电话号码或采用其它报警方式,即可接通城市应急联动指挥中心。当有警情发生时,由人们通过有线或无线通讯网络向应急联动中心报警,或由自动报警装置通过专线向应急联动中心报警。
(2)接警
应急联动中心的接警员接取警情的事件内容、时间和准确地址等信息,并将事件分派给不同调度中心的调度机进行调度处理。计算机辅助系统自动将打入的报警电话送至空闲的接警员处,该接警员与报警员通话,同时,计算机自动识别报警人的电话号码及其所在位置,终端电脑自动生成并存储标准化的事件记录。
(3)调度
根据接过来的警情,应急联动系统向处置力量部门发出指令派出处置力量编组到现场,并根据现场反馈回来的信息,决定是否增援或归队。事件记录通过局域网被送到相应的处警员终端,处警员通过计算机辅助调度系统查询相关资料,制定反应措施,并向相关联动单位发出具体调度指令。在紧急事件发生时,相应的电子预案会被触发启动。如果发生了重大灾难,险情或特殊的事件,则可以启用城市紧急状态指挥室,由首长进行统一指挥。
联动单位根据调度指令到达现场,采取相应的救援措施。与此同时,有关现场的话音和数据信息可通过无线通讯系统传回指挥中心,形成指挥中心与现场之间的互动反馈。
指挥中心的大屏幕将根据需要显示事件处置的全过程,以便进行实时监控。信息网络及语音记录设备将如实记录下与事件相关的语音的及数据信息,供未来检查索查询。
(4)警情汇总汇报
事件处理完毕后,事件情况和处理情况被汇总汇报到相关部门。城市管理可以定期从城市应急联动系统获得有关各种紧急事件的统计报告,进行趋势分析。
1.3.4 应急业务流和模型(以消防为例)
(1)应急业务系统的层次(以消防业务为例)
应急业务系统有五个层次:
○ 指挥中心层(相当于调度/网络/通讯/监控/数据/发布中心的集合);
○ 机构层(应急各机构);
○ 通讯层(各种有线/无线通讯网络);
○ 警情执行层(应急中/大/支队、应急指挥车、应急其它部门);
○ 应急相关层(报警人、报警单位、气象局、电话部门等)。
各个层面有不同的数据和应用。
![](http://www.echinagov.com/echinagov/redian/images/2006625166.jpg)
图1-4 消防调度指挥系统的层次结构示意图
○ 核心层:系统的指挥中心层是应急指挥中心。一个现代化的指挥中心不仅仅是一个调度中心,而且同时是一个计算机网络中心、通讯中心、监控中心、数据中心、信息制作发布中心。一个指挥中心可以说是系统内各类信息的综合应用点,包括数据库的集成应用、各部门数据的综合应用、实时监控数据及图像的显示、电子地图的应用显示、指挥决策系统的结果输出及发布(包括使用通用通讯工具发布调度指令)等。它的基础设施应包括:完善的计算机网络;畅通的通讯系统;大型的数据可视化设备(组合大屏幕或投影显示系统)。为值班人员配备的工具应包括:灵活的数据挖掘工具;可靠的数据分析工具;快捷方便的数据可视化工具;快捷的地理信息检索工具;强大的空间分析工具;方便调度的数据、语言、图件的通讯工具。
○ 机构层:包含领导及机关各机构。在信息化建设中,作为领导单位,统筹安排,特别是涉及全市范围内的通讯系统、计算机网络、GPS系统、图像监控系统和信息资源(如:电话库)等。一般各机构在一个建筑物中,构成以指挥中心为中心的局域网络。
○ 通讯层:包含各种有/无线通讯手段。如:DDN、PSTN、800M、350M等方式。
○ 警情执行层:各应急支队作为分布式数据库、分布式网络的分中心节点,承上启下,应该保留对辖区机构或个人服务的功能。从系统维护、数据更新的角度来看,作用更明显。各应急支队作为信息的接收者、采集者和调度命令的执行者。移动场所拥有GPS、远程访问设备等。
○ 应急相关层:指报警人、报警单位、气象局、电信部门、电力部门、煤气部门等与应急有关的个人或部门。
(2)应急业务系统的流程(以消防业务为例)
![](http://www.echinagov.com/echinagov/redian/images/2006625167.jpg)
图1-5 消防调度指挥系统的流程示意图
● 接警:当有重大火情爆发时,将警情具体内容:接报时间、报警电话号码、报警人姓名、发警单位名称、发警单位地址、发警单位电话、发警点建筑情况、警情派队情况以及其它与报警类别相关的信息传给指挥中心,中心根据警情情况,在中心系统文字屏上显示相应警情的文字信息,并在图形屏上显示起火点位置周围200米内的详细地图。
● 调度:中心调度员根据负责中队的请求,如果需要出动移动指挥车,发指令给指挥车,并按照与现场的距离列出所有中队。根据责任中队的请求,及中心调度员的决策派遣其它中队的应急车辆。通过中心与中队之间的有线链路下达语言调度命令;此时,中心调度员通过按键盘上的特定功能键,根据接警单上明确的出场中队和车辆,向出动中队发出指令,同时完成接警单的打印和派车单的发送。当中队接收到中心发出的派车单后,中队系统自动发出反馈信号,此时,中心系统文字屏发出声光提示信号。当第一指令下达后,如有多起相同报警同时发生时,那么调度员首先进行发警点选择,并根据了解到的发警实际情况,判定是否需要增援。如需增援,则向相关中队发出语言和文字命令。中心调度员依据警情反馈信息进行必要的信息查询检索,及时通过无线和有线通信系统向作战单位发出调整的语言和文字命令。当警情妥善处理后,作战单位通过无线通信系统向中心发出归队请求。归队后,中队调度员向中心反馈警情发生具体情况。中心调度员通过系统主菜单进入警情登记状态,文字屏显示警情登记表。此时,接警单内容及警情反馈信息一并填入该表中。
如果需要出动移动指挥车,则向指挥车发出指令。移动指挥车与中心之间有数据通信。
2. CERS的设计
根据我们多年来对应急系统业务的深入理解,以及我们多年来在应急系统(如110、122、120、119和环保110等)的成功开发经验,利用面向对象分析以系统化、工程化的技术,提出了基于大中城市的应急系统模型。
2.1 CERS的组成设计
CERS的建设分为五个部分:
○ 应用系统;
○ 数据及数据库;
○ 支撑平台;
○ 标准与接口;
○ 系统安全。
![](http://www.echinagov.com/echinagov/redian/images/2006625168.jpg)
图2-1 CERS的组成示意图1
![](http://www.echinagov.com/echinagov/redian/images/2006625169.jpg)
图2-2 CERS的组成示意图2
2.1.1 应用系统的设计
应用系统采用基于Intranet/Internet结构、C/S模式与B/S模式相结合的体系结构。应用系统由以下5个部分组成:
○ 应急指挥调度系统:该系统采用C/S结构,完成警情处理过程中报警单位、各级指挥中心、移动指挥中心及现场的业务工作,是一个覆盖指挥业务全过程的系统。该系统是实现编制出动方案、下达出动命令、应急处理全过程的语言和数据实时记录、现场图像传输、文字传真以及应急信息的综合管理等方面功能的大型综合性系统。
○ 信息维护系统:管理维护系统包含的主要模块有数据管理维护模块、网络设备管理维护模块、有线/无线通信设备管理维护模块等。
○ 领导辅助决策系统:领导辅助决策系统包括的主要模块有统计分析模块、事件分析模块和现场图形模块等。统计分析模块提供关键区域及要害部位的安全监督动态信息,完成数据汇总统计,生成各种统计汇总报表;事件分析模块可以快捷地估算事件、灾情、爆炸等事件造成的破坏区域和影响范围信息;现场图形模块对重点部位采用现场实地取景,经过三维建模处理,能够非常逼真地反映重点部位现实中的设备布置、管道走向、安全设施等情况,方便调度指挥。
○ 办公自动化系统:办公自动化系统包括的主要模块有行文管理模块、会议计划管理模块、公告牌管理模块、文秘办公业务处理模块和战训管理模块等。
○ 基于WEB GIS的应急信息发布系统: 基于WEBGIS的分布式警务信息发布系统是一个WWW服务器,提供统一的浏览器(Browser)访问界面。可对内对外服务。
一、指挥调度系统
1、指挥调度系统
系统中包括的主要模块有调度处警模块、GPS信息接收模块、通信监控模块、监控控制模块、显示控制模块、数字录音模块、现场图像传输控制模块、处置部门信息通信模块、GIS模块、信息管理及查询模块和模拟演练模块、应急培训模块等。
系统在接到重大警情以后,可以利用电子地图系统快速确定位置,得到周围道路、交通情况等信息,根据警力情况为指挥人员提供该位置的预设方案,并根据警力力量的分布情况计算出车辆的最佳行进路线,供指挥人员进行参考。与此同时还可以通过警力信息数据库系统检索出该位置的详细资料,以便根据实际情况确定相应的措施。方案确定以后,指挥系统可以通过计算机网络(或其他通信手段)将出车命令直接下达到各个警点。
2、移动指挥系统(现场系统)
系统配置的设备主要有无线通信设备、移动警情终端台、现场图像传输设备、现场实况摄像和录像设备、卫星通信设备、GSM通信设备、文字传真设备、辅助设备(天线、电源)等。灾情现场多媒体信息和视频会议多媒体信息是数字化的图像和声音数据,数据量较大,由实时记录子系统负责这些信息的记录和处理,包括:记录的开始、结束控制,记录的格式,对记录后的数据的预处理,多媒体数据的入库与查询播放。灾情现场和视频会议多媒体信息传到指挥中心后,同时送到中心控制与实时记录两个子系统。中心控制子系统负责实时显示控制,实时记录子系统负责记录、处理与查询等。
现场系统由以下子系统组成
○ 指挥中心子系统:由中心信息服务模块、中心信息传输模块(与指挥车通信)、指挥车跟踪及路况显示模块组成。本子系统向指挥车发出调度命令,从数据总库中提取出相关信息,经过网络传输给指挥车,同时监视行车路线,接收指挥车传回的关于现场的文字和图像信息。
○ 通信子系统:现场信息传输的功能:向指挥中心传输现场信息、向市政府传输现场信息、向应急联动中心传输现场信息、向应急部传输现场信息。
○ 指挥车子系统:由出车单接收模块、信息查询模块、指挥车信息传输模块(与中心通信)、GPS接收模块、静态信息更新模块、现场图像显示模块、现场广播系统、现场照明、车载大屏幕、车载手机组成。
3、处置力量部门系统
各处置力量部门终端机接到指挥中心命令时,系统立即自动触发警铃,打印出车单(包括出车类型、现场三级图、推荐行车路线、重点应急单位应急预案等),并回复指挥中心命令接收完成。
二、领导辅助决策系统
主要具有以下功能:
统计分析的功能,提供关键区域及要害部位的安全监督动态信息,完成数据汇总统计,生成各种统计汇总报表,根据不同的统计分析要求,在电子地图上以不同色块(颜色)和统计报表(文字)两种直观的表达方式,多方位多角度地显示出统计分析结果。
事件分析功能,可快捷地估算事件、灾情、爆炸等事件造成的破坏区域和影响范围;在平面布置图上标出危险区、隔离区和警戒区,给出各区域危害程度和防护要求等信息;对危险区、隔离区和警戒区进行分析,列出区域内相关设备;给出应急网络图,列出应急响应队伍的联系电话、联系人、主要职责等信息;提供电子白板功能,可在事件模拟图上根据具体情况现场布置车辆,并可及时反馈到异地。
三、基于Web GIS的信息发布系统
本系统以功能为中心,各个部门、人员根据权限的不同对系统拥有不同的操作及使用权限,也就是说根据应急所有部门的业务功能将整个系统设计成一个统一界面,以功能划分模块,整个系统是由功能模块有机结合而成的,而登录用户按所属部门、职位享有相应的功能模块操作权限。
2.1.2 数据及数据库设计
本系统的数据库是一个以应急指挥中心为核心,以各联动单位调度中心为节点的分布式异构数据库。数据有地图数据库、属性数据库、动态数据库、经验知识库、统计分析库、栅格图像库、文档数据库、模型数据库、方法数据库、数据库字典。其中空间信息数据是重要的组成部分。
一、信息源
信息源的管理是多媒体通信网络业务管理系统的重要组成部分。按照应急系统的要求,以及现有设备及现有信息系统的状况,并考虑到地理状况及高速发展的现实情况,我们做了如下的数据分析:
1、地理信息数据:
辖区的山川、河流、水库、公园、公路、街道、路、巷、建筑物、度假区等社会公共地理信息;固定电话安装信息;重要建筑物、机场、码头等的建筑平面图信息;社区分布、人口密度图及人群成分特点信息。
各应急力量的空间物理位置及地理坐标、辖区范围;
全市各应急设备分布及应急设备工作情况;自然水源的空间物理位置及地理坐标;各重点防火单位及高层建筑的空间物理位置及地理坐标;
重点控制部位有很大一部分在测绘地图上已标注,根据警务工作的要求重新标明或加注。
2、属性信息:各地理信息相对应的属性信息。
3、GPS信息:GPS信号来源于即将开发的专用系统,它是“坐标+信息”形式的数据,其数据在时间上有较好的连续性。
二、数据的分层管理
本系统涉及信息量巨大,合理的分层管理是提高系统响应速度的关键。我们建议将数据分为以下几类,即基础底图数据、道路数据、点位数据、部门特殊需求数据。每一类数据根据详细程度再进行分级,一般为两到三级。根据地图显示的视野,系统能自动选择显示相应级别的数据。尽管在数据库里的图层很多,但要保证系统在任何时候显示的地图图层数量都控制在十层左右,从而有效地降低负载,保证系统的响应速度。
1 基础底图数据
基础底图数据实际上是基础地形图数据,包括行政区域、湖泊、河流、居民区、公共建筑物等,它们主要是面类数据。
2 道路数据
严格来讲,道路数据和点位数据也属于基础底图数据。但为了体现这两类数据在系统中的重要性,故需单独处理。道路数据包括路面数据和路网数据,特别是路网数据,要进行特殊的处理。路面数据是以面的形式所表现的道路,这种方式的优点在于美观和直观,但是不利于分析。对于系统来说更重要的是路网数据,即道路要进行分段处理,形成路网。道路的属性包括道路等级、道路长度、宽度、线形、路面性质、道路编码、路段隔离设施、车道划分、设计车速、容量等。
3 点位数据
点位数据在系统中占有很重要的位置,很多情况下点位数据是很重要的定位参考点。点位数据分为两大类,一类是公共性点位数据,如:党政首脑机关;企事业单位;公共电汽车站点;客货交通类,包括长途汽车站、火车站、航空港、货运站等、大型公共建筑:包括体育场馆、医院、急救站、标志性建筑,包括火车站、机场、天塔、大型商场、大型国家机关等。另一类是特殊点位数据,这些数据可能不显示,但是对系统是重要的定位参考数据。如:门牌号码地址分布点位、电话号码分布点位。这些数据的收集工作量也非常的大,但对于系统来说是必不可少的,故也需要仔细规划。
4 业务数据
警力及其管理辖区、应急水源等。
三、数据库
按照数据功能及其与地理信息的相关特点,数据分为地理数据和属性数据。社会应急联动系统各部门的管理过程中主要有两种数据:属性数据和空间数据。属性数据包括大量的统计数据;空间数据是反映应联系统信息的空间坐标位置的数据(如事发地点、派出所位置等),主要指地图图形。如果把属性数据和空间数据紧密结合在一起,将使得整个社会应急联动信息的管理更加方便快捷和形象直观,并彻底改变社会应急联动规划、建设、实施、管理及资料保存的传统模式,从而实现社会应急联动管理的计算机自动化。
分布式数据库系统是整个系统的数据中心。它将以指挥中心为核心,各联动单位指挥中心和移动指挥中心为节点。
2.1.3 支撑平台设计
支撑平台有计算机网络系统、监控系统、显示系统、GPS系统、有/无线通信系统、图像传输系统、电源及机房、软件支撑平台等。其中,计算机网络系统包括指挥中心、二级指挥中心与移动指挥中心、业务执行机构(如:应急中队、派出所等)之间的三级计算机网络,即指挥中心局域网络、业务机关网络、与分支机关的广域网络、与移动指挥中心的远程访问网络。指挥中心与二级指挥中心、分支机构、移动中心之间有语音通信、数据通信,指挥中心与移动中心有语音通信、数据通信(无线)、现场图像传输;指挥中心与公安其它机构通过拨号网络访问(内网),指挥中心与普通老百姓通过拨号网络访问(外网)。
一、计算机网络
计算机与网络平台系统支撑系统运行的三级计算机网络、计算机和外设。
二、有/无线通讯网络
有线/无线通信系统提供CERS需要的有线/无线通信链路,是系统全部信息的输出/输入载体。包括程控用户交换机、接警座席台及数字录音系统、无线通信网(800M集群系统、350M集群系统)和有线通信网络。
三、监控与图像传输网络
图像监控系统对监控场所(包括市级机关、交通路口、公共场所、金融机构、大型商场、邮电通信枢纽、车站、码头等)进行实时集中监控,对所需的各种视频、音频、计算机文字、图形信息等进行收集、选取、存储,并控制显示在大屏幕、大尺寸视频监视器和首长多媒体终端等显示设备上。
现场图像传输与处理系统将现场的灾情实况视频图像数据进行采集和传输,送到现场指挥车或应急通信指挥中心进行显示和存储。
四、GPS系统
GPS子系统主要用于及时、准确地掌握被控车辆和船舶等移动目标的实时情况和准确位置。采用GPS全球卫星定位技术、GSM全球移动通讯技术、GIS地理信息处理技术和计算机网络通信与数据处理技术,在现有GSM、GPRS通讯系统的基础上开发出的一套社会综合防范和远程监控、通讯、管理、调度系统。利用该系统,可以远程无线监控、调度所有在GSM网覆盖范围内的警用车辆、急救车辆、应急车辆、出租车辆、租赁车辆、民用车辆等移动目标。移动目标GPS数据、其他指令及各类报警数据均由GSM信令信道传送到数据处理中心,并可根据需要自动接通预先设置的号码进行语音通话。
五、大屏显示系统
大屏幕显示系统主要进行应急地理信息显示、应急车辆状态显示、气象显示、应急实力信息显示、灾情受理地点显示、主要交通道口交通状态显示和部分重点保卫目标监控显示。指挥中心实现对指挥系统控制区的各种情况进行动态监管。大屏幕投影系统负责实现直观、完整、准确、清晰、灵活的显示各项信息,包括:各种地理信息、车辆状态显示、气象信息显示、实力显示、受理信息显示。这类信号由计算机相关软件生成,在现场计算机显示器上显示,同时调入所需要的信息在大屏幕作任意大型显示。便于整体统筹,指挥。同时指挥中心计算机与其它会议室(兼指挥室)计算机联网,使其它会议室可通过局域网调用所需信息在会议用投影机上显示。
六、支撑软件
支撑软件平台系统包括计算机操作系统、数据库管理系统、GIS系统和应用软件开发平台系统等。以下是我们的一个实例:
数据库服务器:Oracle .
GIS支撑平台:Mapinfo profession MAPBASIC
OA平台:Lotus Domino
开发平台:DelpHi VC Jbuilder
操作系统:Windows Advance Server
网络协议:TCP/IP
软件平台结构:软件平台采用C/S+B/S结构
2.1.4 标准与接口设计
系统接口:本应用系统是一个复杂的各种技术、各种相关系统、数据的集成系统,因此系统接口设计十分重要。系统接口分为外部接口、内部接口。接口有数据接口、软件接口、硬件接口。
标准的建设是CERS的核心工作。
2.1.5 系统安全的设计
安全设计从系统安全、数据及数据库安全两方面进行了设计。
2.2 CERS的框架设计
采用B/S与C/S相结合的体系结构。
一、Client/Server体系结构
Client/Server是一种目前发展已经非常成熟的计算机体系结构。在此之前,信息系统一般采用文件共享的方式,通过直接访问数据库来达到数据共享的目的。Client/Server体系结构严格地定义了客户端和服务器端对信息数据的处理范围。即客户端要访问服务器端的数据时,一定是以特定的描述语言,将请求信息首先传递给服务器端,由服务器端的相关模块判别并处理客户端的这个请求。请求处理完毕后,服务器端再将处理结果回传给客户端。这样才算一个访问过程的结束。Client/Server体系结构发展到今天已经非常成熟了,它可以把实现友好人机交互界面的任务交给客户端处理,而服务器端只需完成数据的存储和处理。这种体系结构的优点是:系统功能强大、交互能力强、系统运行效率高,并且开发工具和开发手段可选择性强。缺点是:所开发出来的系统相对比较封闭,主要适合于数据管理方式;系统结构复杂,开发周期长;安装和维护比较麻烦。
二、Browser/Web Server体系结构
为了克服Client/Server体系结构所存在的问题,最近几年来,随着Internet技术的飞速发展和日益成熟,特别是瘦客户机概念的提出和发展,提出了以Browser/Web Server体系结构为代表的多层Client/Server体系结构,作为对Client/Server体系结构的补充和发展。Browser/Web Server体系结构将Client/Server体系结构的两层结构发展到三层结构,一般可以认为是在原有的Client层和Server层之间加入了Application Server层(也称为中间件层)。Application Server层承担了原来Client/Server体系结构中Client层和Server层的部分任务,这样使得Client层和Server层所承担的任务相对减轻。Client层变成比较统一的界面,Server层主要处理信息数据的存储和管理任务,Application Server层负责具体数据的处理任务,而且可以根据处理任务的变化而变化。Browser/Web Server体系结构的主要优点是对Client端设备的要求逐步降低,运行维护量下降;Application Server层的中间件软件日益丰富和模块化,降低了系统开发的工作量,缩短了开发周期。主要缺点是Application Server层的中间件软件目前还不够丰富和完善,而且对网络系统的运行环境要求较高。
3. CERS面临的技术挑战与我们的对策
3.1 CERS的分析
CERS实施的核心是要尽量提高事件反应速度,缩短事件反应和扑救的时间。CERS与其它集成系统相比,最大的特点是:
3.1.1 实时性要求高,应急反应要及时
CERS实时性要求高,这就要求实现各个层次的互联互通,如有/无线数字链路、有/无线语音链路、有/无线图像链路的互联互通;实现数据的互操作、软件的互操作与语义的互操作。
3.1.2 具有移动办公的特点
这是CERS最大的特点。系统设计要重点考虑这个特点。
3.1.3 具有分布性、异构性、海量性和动态实时性特点
要实现各个层次的互操作。
一、数据的互操作
解决得不错。
二、软件的互操作
已有成熟的解决方案。
三、语义的互操作
还刚刚起步。
3.2 CERS面临的挑战
1.需要集成多个行业或部门的业务:CERS需要集成公安、消防、交管、120、供电、市政和政府等部门的应急业务。目前的集成大都专注于技术层面的互联互通,并有效地实现了,而集成不仅需要找到、操作并获取信息,还需要理解信息的含义。各应急服务系统间通讯会存在多词一义、一词多义或近义等语义冲突;
2.需要动态实时集成不同业务领域的已有或新建应急服务系统,这些系统是分布的、异构的,集成规模大;
3.集成的业务流程会动态增删修改,如开始可能是110、120、119的联动,随着时间的推移,会有电力抢险、地震救急等业务加入;
4.系统不能理解应急预案,所以不能按预案自动调度;
5.GIS是应急指挥的重要手段,CERS需要实现时空集成。
3.3 我们的对策
3.3.1 采用的技术
XML 及相关技术,如Web Service、Ontology
元数据技术
3.3.2 实施思路:建立集成框架,实现各业务系统的集成
CERS是一个复杂的集成系统,必须坚持“总体设计、分步实施”的原则。本着业务是核心,技术是手段的原则。
深入分析业务流程,建立各联动单位的业务模型、系统模型和功能需求。
深入分析现有业务系统和数据,理清思路。
深入分析各业务系统的接口,建立一系列业务标准和技术规范。
在标准和技术规范的指导下,建立集成框架的编码标准、通讯协议和应用模型。
在集成框架的指导下,进行各系统的开发。
CERS是一个系统集成的项目,需要制定一系列信息交换的数据编码和通讯协议。
一、建立业务模型与系统模型
建立CERS的UML模型是系统设计与实施的基础,应急事件ONTOLOGY模型E2M是信息共享的核心:
E2M提供信息交换的通用模型和词汇表,是各业务达成一致的关键基础和共同理解。每个业务都有各自的领域ontology,与通用模型有映射规则。业务系统收到的共享信息符合通用模型,所以能理解,并按映射规则转成领域模型描述进行处理。发出信息时需按映射规则转成通用模型,其它系统就能理解,从而实现了系统集成。增删一个业务系统时,其它系统不需改动。此外系统能理解用E2M描述的应急预案,实现多业务预案的自动调度;系统对多个部门联合行动的事件的处置内容进行合并,并事后进行事件回放,以便进行事件分析。E2M具有语言/平台/中间件无关性、重用性和可扩充性,E2M将语义从传送机制和应用接口中分离出来,使得集成更强壮,对集成技术的更新有更强的适应性。
二、建立集成框架
基于XML、Web Service、Ontology等技术的集成框架包括集成总线及Adapter Service、元数据库及集成协调器与供二次开发的API及Web Service工具集,它实现了数据互操作,软件互操作与语义互操作。集成总线是一组面向领域的编码标准与通讯协议。与总线标准不符的老系统和其它相关系统只需编写Adapter Service就能被集成。元数据库是集成框架的核心,管理系统中的所有信息与应用服务,屏蔽信息及服务的分布性与异构性。集成协调器用于数据的更新,元数据的管理。Ontology则用于定义描述领域相关元数据的术语。数据交换格式与通讯协议均用XML定义。所有应用通过SOAP协议实现互操作。这一集成框架实现了大规模空间信息及服务的动态集成,能保护已有投资,并能集成网上丰富的商业Web Service,是一个开放的可扩充的框架。
集成几十家不同业务领域的应用以增加(或重组)新的大型业务应用成为当前IT建设的主流。应用集成面临的最大问题是不同业务领域的术语存在一词多义、同词不同义、多词一义等语义冲突。解决语义冲突,实现应用集成是ontology最重要的应用之一,也是目前国际IT界研究的热点。我们提出了“中介抽象ontology法”来解决语义冲突。该方法适合大规模的应用集成,且不需改造原有各应用的ontology。首先分析城市应急联动系统中各业务领域的模型,对这些模型进行抽象,形成应急联动系统模型,并在此基础上建立ontology模型。该模型包含了应急领域的抽象术语,即应急领域的抽象ontolog模型,可作为混合法中的公共ontology。当新的应急业务领域增加时,很容易生成它与抽象ontology间的映射。当一个应用使用另一个应用的术语时,先通过这些映射将一个应用的术语转成抽象ontology中的术 语,再转成另一应用的术语,以实现语义互操作。
三、建立接口标准和技术规范
建立集成总线中的信息编码标准和通讯协议。
3.4 我们已有的研究成果与开发经验
3.4.1 CERS研究与建设的初步成果
已经建立了应急联动系统CERS的业务模型
已经建立了应急联动系统CERS的UML模型
部分建立了应急联动领域的术语表
部分建立了应急联动领域的ontology
已经建立了应急事件的ontology模型E2M
已经建立了大规模空间信息服务集成框架
已经设计了解决多业务集成语义冲突的方法
正在搭建应急联动系统的实验环境,119 120 110三个的联动
3.4.2 应急系统建设的经验
我们对应急联动系统中各联动单位的业务流程有较为深刻的理解和开发实践经验,如应急联动系统的前期设计、多个城市的110、119、120、12369、122。
专家简介:王文俊,男,博士,高级工程师,高级监理工程师,北京大学计算机系。主要研究 领域为GIS、Web服务,研究应用背景是数字海洋、城市应急联动。自1996年起,主持多个城市应急指挥及相关系统(119、110、120) 的分析设计与开发实施,对应急业务有深刻的理解和丰富的研发经验。从2001年起在应急联动系统业务建模、应急事件模型、应急 预案模型,以及在分布式异构环境下实现协同工作的关键软件技术开展了研究工作,并组织实现了某城市的应急联动一期工程(小规模),是多个城市与地区应急联动项目的顾问与专家。
1.1 CERS
1.1.1 什么是CERS
公共安全和公众服务成为政府部门一项非常富有挑战性的工作。如何高效利用有限的资源,提高政府对紧急事件快速反应和抗风险的能力,并为市民提供更快捷的紧急救助服务,日益成为加强城市管理的主要内容之一。当社会发生犯罪、火灾、爆炸等各种警情,群众医疗急救、煤水电抢修等各种紧急求救事件,地震、火灾、海潮等突发自然灾害,以及社会动乱、战争等各种重大紧急事件时,需要政府统一协调、统一调度相关部门协同工作。随着社会的不断进步,社会发生紧急突发事件的种类更加复杂与多变,传统的应对机制已不能适应日益增多的紧急突发事件处置的需要。当社会发生重大事件时,不是哪一家或哪几家单位能够解决的,这就需要联合多家或所有社会单位共同解决。
社会应急联动系统就是综合各种城市应急服务资源,采用统一的号码,用于公众报告紧急事件和紧急求助,统一接警,统一指挥,联合行动,为市民提供相应的紧急救援服务,为城市的公共安全提供强有力的保障的系统。CERS大大加强了不同警种与联动单位之间的配合与协调,从而对特殊、突发、应急和重要事件做出有序、快速而高效的反应。
1.1.2 为什么需要城市应急联动系统?
随着社会经济文化生活的不断发展和进步,如何高效利用有限的资源,提高政府对紧急事件快速反应和抗风险的能力,并为市民提供更快捷的紧急救助服务,重要性日益凸显。
目前存在多个公众特服号码,比如:公安-110、警情--119、急救-120、交警-122,市民难于记忆。水、电、气等公共服务号码更不为人知晓,因此市民不便于得到相应的服务,救助和保护。由于缺少一个统一的指挥调度平台,不同警种和部门之间无法进行很好的配合与协调,联合行动的实施面临着许多诸如部门分割、利益关系以及技术实现等诸多方面的困难;CERS使得市民的任何报警,求助只需拨打同一个号码,不再需要记忆诸多特服号码(比如:110、122、119、120等),缩短报警时间,大大方便了市民报警,并得到及时的救助和相应的服务。
CERS可使接警和处警都更加准确和快速,为警力的快速反应提供有力的保障,从而大大提高城市对突发、应急、特殊和灾难性事件的快速反应能力,在加大对犯罪的打击力度,维持社会秩序,缩短对市民求助的反应时间,保护生命财产等方面都将起到十分重要的作用。
CERS也打破了现有多个指挥中心间的数字鸿沟,使离散的数据库和信息资源得以互联和共享,发挥更大的作用;
由于采用了统一的指挥调度系统,不同部门、不同警区和不同警种之间得以互通和相互协调、配合,使统一指挥、协调作战成为可能,真正实现了社会服务联合行动。
1.2 应用现状
目前,世界上许多国家都采用不同的三位数字电话号码,作为全国处理紧急呼救的特服号码。例如:美国采用911,英国采用999,比利时采用900。早在1937年,英国就开始使用号码999,用以报告紧急情况的发生。当电话999被拨打时,在英国电信接线员的操作台上会出现闪光,呼叫将立即得到应答并马上被转给适当的单位,例如:警察局、消防局或急救中心。比利时于1964年开始启用900紧急呼叫号码,其报警电话的工作模式是,每个电话局都设有一个紧急电话应答中心。瑞典建立的900,则由一个SOS报警中心负责接收所有居民的报警和求助电话。 日本、法国、德国、加拿大、香港等技术先进的国家和地区都相继建立了以城市为区域中心的区域报警、求助应急处置体系。通过一个特服号码电话报警求助,指挥中心依据报警求助内容,分别调动警察、消防、医疗急救、水电抢险等部门进行紧急处置或联合行动处置。
美国于1967年提议在全国范围内使用一个单一的号码,用于市民报警和求助,打破了多个特服号码共存的状况。美国从上个世纪60年代开始进行城市社会应急联动中心的建设至今,应急联动中心(911中心)已遍布美国的各个州市。美国9ll服务开通以后,各州市有了统一的应急联动中心和通信系统,警察、消防和急救等部门采用现场合署办公的方式处理各类紧急事件。当市民拨打911电话后,由911中心的接警员统一接警,根据事件内容,迅速做出反应,联合各相关部门统一处置。市民在很短时间内便可得到最快速的救援和服务。
南宁市CERS已开通,它模仿美国芝加哥911模式,即“大使馆”制模式。新建指挥中心大楼,指挥大厅内设置了110指挥席位、119消防指挥席位、120医疗急救席位、122交通事故报警急救席位和为民服务网络12345市长公开电话席位。群众拨打统一的“110”电话,根据群众报警内容,分转到110、119、120、122或12345等相应席位,一般事件各席位各尽其职,下达指挥命令,重大事件由指挥长台,协调各警种统一指挥。实现了跨部门、跨警区以及不同警种之间的统一协调指挥,使统一特服号码、统一接警、联合行动成为现实,也使报警和联动出警更加准确、快捷和高效。
此外,北京、上海、天津、深圳、南京、大连、济南、成都等城市的联动系统都已开始建设。城市应急联动系统涉及多个业务领域,是实时性要求很高的分布式系统。
1.3 CERS业务建模
1.3.1 概述
系统分析是系统设计的基础。分析的成果是系统的业务机构模型和业务流程模型。
模型分两个层次:联动层次或应急业务系统层次。应急业务系统指的是各联动单位如110、119、120等。联动层次在此层次之上。
我们对用户的操作方式和目的,以及现有用户的结构进行分析,将系统用户分为五类:
○ 第一类是系统维护用户;
○ 第二类是接警处警用户;
○ 第三类是业务专业用户;
○ 第四类是Internet用户;
○ 第五类是报警用户。
通过对这五类用户的功能需求分析、角色分析,形成了系统的功能设计。其中,接警、处警用户包含受理类、调度类、处置类和移动指挥类用户等;报警方式有有线/无线报警、专业/普通报警网络。
1.3.2 应急联动业务机构模型
![](http://www.echinagov.com/echinagov/redian/images/2006625163.jpg)
图1-1 应急联动业务机构模型CERO示意图
CERO(Coalition Emergency Response Organization)的层次结构分为六级。
(1)决策指挥中心
设在市委与市政府,处理紧急重大事件。
(2)应急联动中心
一般设在公安局,职责是统一接警、跨警种或跨区事件的协调处理。
(3)各联动单位的调度中心
负责公安、消防等单一警种的事件调度处理。如原110、119、120、122、电力、地震等的调度中心。
(4)联动单位的分支机构
是设在城市不同区的处置力量的主管分支部门。如:消防支队、交管支队等。
(5)处置力量部门
是实际处置事件的部门。如:消防中队、派出所、急救站等。
(6)处置力量编组
是实际处置事件的编组。如:消防车、巡警车、急救车等。
1.3.3 联动业务流程模型
![](http://www.echinagov.com/echinagov/redian/images/2006625164.jpg)
图1-2 CERS的业务流程示意图1
![](http://www.echinagov.com/echinagov/redian/images/2006625165.jpg)
图1-3 CERS的业务流程示意图2
(1)发现警情报警
公众需要紧急救助时,只需要拨打一个城市应急联动电话号码或采用其它报警方式,即可接通城市应急联动指挥中心。当有警情发生时,由人们通过有线或无线通讯网络向应急联动中心报警,或由自动报警装置通过专线向应急联动中心报警。
(2)接警
应急联动中心的接警员接取警情的事件内容、时间和准确地址等信息,并将事件分派给不同调度中心的调度机进行调度处理。计算机辅助系统自动将打入的报警电话送至空闲的接警员处,该接警员与报警员通话,同时,计算机自动识别报警人的电话号码及其所在位置,终端电脑自动生成并存储标准化的事件记录。
(3)调度
根据接过来的警情,应急联动系统向处置力量部门发出指令派出处置力量编组到现场,并根据现场反馈回来的信息,决定是否增援或归队。事件记录通过局域网被送到相应的处警员终端,处警员通过计算机辅助调度系统查询相关资料,制定反应措施,并向相关联动单位发出具体调度指令。在紧急事件发生时,相应的电子预案会被触发启动。如果发生了重大灾难,险情或特殊的事件,则可以启用城市紧急状态指挥室,由首长进行统一指挥。
联动单位根据调度指令到达现场,采取相应的救援措施。与此同时,有关现场的话音和数据信息可通过无线通讯系统传回指挥中心,形成指挥中心与现场之间的互动反馈。
指挥中心的大屏幕将根据需要显示事件处置的全过程,以便进行实时监控。信息网络及语音记录设备将如实记录下与事件相关的语音的及数据信息,供未来检查索查询。
(4)警情汇总汇报
事件处理完毕后,事件情况和处理情况被汇总汇报到相关部门。城市管理可以定期从城市应急联动系统获得有关各种紧急事件的统计报告,进行趋势分析。
1.3.4 应急业务流和模型(以消防为例)
(1)应急业务系统的层次(以消防业务为例)
应急业务系统有五个层次:
○ 指挥中心层(相当于调度/网络/通讯/监控/数据/发布中心的集合);
○ 机构层(应急各机构);
○ 通讯层(各种有线/无线通讯网络);
○ 警情执行层(应急中/大/支队、应急指挥车、应急其它部门);
○ 应急相关层(报警人、报警单位、气象局、电话部门等)。
各个层面有不同的数据和应用。
![](http://www.echinagov.com/echinagov/redian/images/2006625166.jpg)
图1-4 消防调度指挥系统的层次结构示意图
○ 核心层:系统的指挥中心层是应急指挥中心。一个现代化的指挥中心不仅仅是一个调度中心,而且同时是一个计算机网络中心、通讯中心、监控中心、数据中心、信息制作发布中心。一个指挥中心可以说是系统内各类信息的综合应用点,包括数据库的集成应用、各部门数据的综合应用、实时监控数据及图像的显示、电子地图的应用显示、指挥决策系统的结果输出及发布(包括使用通用通讯工具发布调度指令)等。它的基础设施应包括:完善的计算机网络;畅通的通讯系统;大型的数据可视化设备(组合大屏幕或投影显示系统)。为值班人员配备的工具应包括:灵活的数据挖掘工具;可靠的数据分析工具;快捷方便的数据可视化工具;快捷的地理信息检索工具;强大的空间分析工具;方便调度的数据、语言、图件的通讯工具。
○ 机构层:包含领导及机关各机构。在信息化建设中,作为领导单位,统筹安排,特别是涉及全市范围内的通讯系统、计算机网络、GPS系统、图像监控系统和信息资源(如:电话库)等。一般各机构在一个建筑物中,构成以指挥中心为中心的局域网络。
○ 通讯层:包含各种有/无线通讯手段。如:DDN、PSTN、800M、350M等方式。
○ 警情执行层:各应急支队作为分布式数据库、分布式网络的分中心节点,承上启下,应该保留对辖区机构或个人服务的功能。从系统维护、数据更新的角度来看,作用更明显。各应急支队作为信息的接收者、采集者和调度命令的执行者。移动场所拥有GPS、远程访问设备等。
○ 应急相关层:指报警人、报警单位、气象局、电信部门、电力部门、煤气部门等与应急有关的个人或部门。
(2)应急业务系统的流程(以消防业务为例)
![](http://www.echinagov.com/echinagov/redian/images/2006625167.jpg)
图1-5 消防调度指挥系统的流程示意图
● 接警:当有重大火情爆发时,将警情具体内容:接报时间、报警电话号码、报警人姓名、发警单位名称、发警单位地址、发警单位电话、发警点建筑情况、警情派队情况以及其它与报警类别相关的信息传给指挥中心,中心根据警情情况,在中心系统文字屏上显示相应警情的文字信息,并在图形屏上显示起火点位置周围200米内的详细地图。
● 调度:中心调度员根据负责中队的请求,如果需要出动移动指挥车,发指令给指挥车,并按照与现场的距离列出所有中队。根据责任中队的请求,及中心调度员的决策派遣其它中队的应急车辆。通过中心与中队之间的有线链路下达语言调度命令;此时,中心调度员通过按键盘上的特定功能键,根据接警单上明确的出场中队和车辆,向出动中队发出指令,同时完成接警单的打印和派车单的发送。当中队接收到中心发出的派车单后,中队系统自动发出反馈信号,此时,中心系统文字屏发出声光提示信号。当第一指令下达后,如有多起相同报警同时发生时,那么调度员首先进行发警点选择,并根据了解到的发警实际情况,判定是否需要增援。如需增援,则向相关中队发出语言和文字命令。中心调度员依据警情反馈信息进行必要的信息查询检索,及时通过无线和有线通信系统向作战单位发出调整的语言和文字命令。当警情妥善处理后,作战单位通过无线通信系统向中心发出归队请求。归队后,中队调度员向中心反馈警情发生具体情况。中心调度员通过系统主菜单进入警情登记状态,文字屏显示警情登记表。此时,接警单内容及警情反馈信息一并填入该表中。
如果需要出动移动指挥车,则向指挥车发出指令。移动指挥车与中心之间有数据通信。
2. CERS的设计
根据我们多年来对应急系统业务的深入理解,以及我们多年来在应急系统(如110、122、120、119和环保110等)的成功开发经验,利用面向对象分析以系统化、工程化的技术,提出了基于大中城市的应急系统模型。
2.1 CERS的组成设计
CERS的建设分为五个部分:
○ 应用系统;
○ 数据及数据库;
○ 支撑平台;
○ 标准与接口;
○ 系统安全。
![](http://www.echinagov.com/echinagov/redian/images/2006625168.jpg)
图2-1 CERS的组成示意图1
![](http://www.echinagov.com/echinagov/redian/images/2006625169.jpg)
图2-2 CERS的组成示意图2
2.1.1 应用系统的设计
应用系统采用基于Intranet/Internet结构、C/S模式与B/S模式相结合的体系结构。应用系统由以下5个部分组成:
○ 应急指挥调度系统:该系统采用C/S结构,完成警情处理过程中报警单位、各级指挥中心、移动指挥中心及现场的业务工作,是一个覆盖指挥业务全过程的系统。该系统是实现编制出动方案、下达出动命令、应急处理全过程的语言和数据实时记录、现场图像传输、文字传真以及应急信息的综合管理等方面功能的大型综合性系统。
○ 信息维护系统:管理维护系统包含的主要模块有数据管理维护模块、网络设备管理维护模块、有线/无线通信设备管理维护模块等。
○ 领导辅助决策系统:领导辅助决策系统包括的主要模块有统计分析模块、事件分析模块和现场图形模块等。统计分析模块提供关键区域及要害部位的安全监督动态信息,完成数据汇总统计,生成各种统计汇总报表;事件分析模块可以快捷地估算事件、灾情、爆炸等事件造成的破坏区域和影响范围信息;现场图形模块对重点部位采用现场实地取景,经过三维建模处理,能够非常逼真地反映重点部位现实中的设备布置、管道走向、安全设施等情况,方便调度指挥。
○ 办公自动化系统:办公自动化系统包括的主要模块有行文管理模块、会议计划管理模块、公告牌管理模块、文秘办公业务处理模块和战训管理模块等。
○ 基于WEB GIS的应急信息发布系统: 基于WEBGIS的分布式警务信息发布系统是一个WWW服务器,提供统一的浏览器(Browser)访问界面。可对内对外服务。
一、指挥调度系统
1、指挥调度系统
系统中包括的主要模块有调度处警模块、GPS信息接收模块、通信监控模块、监控控制模块、显示控制模块、数字录音模块、现场图像传输控制模块、处置部门信息通信模块、GIS模块、信息管理及查询模块和模拟演练模块、应急培训模块等。
系统在接到重大警情以后,可以利用电子地图系统快速确定位置,得到周围道路、交通情况等信息,根据警力情况为指挥人员提供该位置的预设方案,并根据警力力量的分布情况计算出车辆的最佳行进路线,供指挥人员进行参考。与此同时还可以通过警力信息数据库系统检索出该位置的详细资料,以便根据实际情况确定相应的措施。方案确定以后,指挥系统可以通过计算机网络(或其他通信手段)将出车命令直接下达到各个警点。
2、移动指挥系统(现场系统)
系统配置的设备主要有无线通信设备、移动警情终端台、现场图像传输设备、现场实况摄像和录像设备、卫星通信设备、GSM通信设备、文字传真设备、辅助设备(天线、电源)等。灾情现场多媒体信息和视频会议多媒体信息是数字化的图像和声音数据,数据量较大,由实时记录子系统负责这些信息的记录和处理,包括:记录的开始、结束控制,记录的格式,对记录后的数据的预处理,多媒体数据的入库与查询播放。灾情现场和视频会议多媒体信息传到指挥中心后,同时送到中心控制与实时记录两个子系统。中心控制子系统负责实时显示控制,实时记录子系统负责记录、处理与查询等。
现场系统由以下子系统组成
○ 指挥中心子系统:由中心信息服务模块、中心信息传输模块(与指挥车通信)、指挥车跟踪及路况显示模块组成。本子系统向指挥车发出调度命令,从数据总库中提取出相关信息,经过网络传输给指挥车,同时监视行车路线,接收指挥车传回的关于现场的文字和图像信息。
○ 通信子系统:现场信息传输的功能:向指挥中心传输现场信息、向市政府传输现场信息、向应急联动中心传输现场信息、向应急部传输现场信息。
○ 指挥车子系统:由出车单接收模块、信息查询模块、指挥车信息传输模块(与中心通信)、GPS接收模块、静态信息更新模块、现场图像显示模块、现场广播系统、现场照明、车载大屏幕、车载手机组成。
3、处置力量部门系统
各处置力量部门终端机接到指挥中心命令时,系统立即自动触发警铃,打印出车单(包括出车类型、现场三级图、推荐行车路线、重点应急单位应急预案等),并回复指挥中心命令接收完成。
二、领导辅助决策系统
主要具有以下功能:
统计分析的功能,提供关键区域及要害部位的安全监督动态信息,完成数据汇总统计,生成各种统计汇总报表,根据不同的统计分析要求,在电子地图上以不同色块(颜色)和统计报表(文字)两种直观的表达方式,多方位多角度地显示出统计分析结果。
事件分析功能,可快捷地估算事件、灾情、爆炸等事件造成的破坏区域和影响范围;在平面布置图上标出危险区、隔离区和警戒区,给出各区域危害程度和防护要求等信息;对危险区、隔离区和警戒区进行分析,列出区域内相关设备;给出应急网络图,列出应急响应队伍的联系电话、联系人、主要职责等信息;提供电子白板功能,可在事件模拟图上根据具体情况现场布置车辆,并可及时反馈到异地。
三、基于Web GIS的信息发布系统
本系统以功能为中心,各个部门、人员根据权限的不同对系统拥有不同的操作及使用权限,也就是说根据应急所有部门的业务功能将整个系统设计成一个统一界面,以功能划分模块,整个系统是由功能模块有机结合而成的,而登录用户按所属部门、职位享有相应的功能模块操作权限。
2.1.2 数据及数据库设计
本系统的数据库是一个以应急指挥中心为核心,以各联动单位调度中心为节点的分布式异构数据库。数据有地图数据库、属性数据库、动态数据库、经验知识库、统计分析库、栅格图像库、文档数据库、模型数据库、方法数据库、数据库字典。其中空间信息数据是重要的组成部分。
一、信息源
信息源的管理是多媒体通信网络业务管理系统的重要组成部分。按照应急系统的要求,以及现有设备及现有信息系统的状况,并考虑到地理状况及高速发展的现实情况,我们做了如下的数据分析:
1、地理信息数据:
辖区的山川、河流、水库、公园、公路、街道、路、巷、建筑物、度假区等社会公共地理信息;固定电话安装信息;重要建筑物、机场、码头等的建筑平面图信息;社区分布、人口密度图及人群成分特点信息。
各应急力量的空间物理位置及地理坐标、辖区范围;
全市各应急设备分布及应急设备工作情况;自然水源的空间物理位置及地理坐标;各重点防火单位及高层建筑的空间物理位置及地理坐标;
重点控制部位有很大一部分在测绘地图上已标注,根据警务工作的要求重新标明或加注。
2、属性信息:各地理信息相对应的属性信息。
3、GPS信息:GPS信号来源于即将开发的专用系统,它是“坐标+信息”形式的数据,其数据在时间上有较好的连续性。
二、数据的分层管理
本系统涉及信息量巨大,合理的分层管理是提高系统响应速度的关键。我们建议将数据分为以下几类,即基础底图数据、道路数据、点位数据、部门特殊需求数据。每一类数据根据详细程度再进行分级,一般为两到三级。根据地图显示的视野,系统能自动选择显示相应级别的数据。尽管在数据库里的图层很多,但要保证系统在任何时候显示的地图图层数量都控制在十层左右,从而有效地降低负载,保证系统的响应速度。
1 基础底图数据
基础底图数据实际上是基础地形图数据,包括行政区域、湖泊、河流、居民区、公共建筑物等,它们主要是面类数据。
2 道路数据
严格来讲,道路数据和点位数据也属于基础底图数据。但为了体现这两类数据在系统中的重要性,故需单独处理。道路数据包括路面数据和路网数据,特别是路网数据,要进行特殊的处理。路面数据是以面的形式所表现的道路,这种方式的优点在于美观和直观,但是不利于分析。对于系统来说更重要的是路网数据,即道路要进行分段处理,形成路网。道路的属性包括道路等级、道路长度、宽度、线形、路面性质、道路编码、路段隔离设施、车道划分、设计车速、容量等。
3 点位数据
点位数据在系统中占有很重要的位置,很多情况下点位数据是很重要的定位参考点。点位数据分为两大类,一类是公共性点位数据,如:党政首脑机关;企事业单位;公共电汽车站点;客货交通类,包括长途汽车站、火车站、航空港、货运站等、大型公共建筑:包括体育场馆、医院、急救站、标志性建筑,包括火车站、机场、天塔、大型商场、大型国家机关等。另一类是特殊点位数据,这些数据可能不显示,但是对系统是重要的定位参考数据。如:门牌号码地址分布点位、电话号码分布点位。这些数据的收集工作量也非常的大,但对于系统来说是必不可少的,故也需要仔细规划。
4 业务数据
警力及其管理辖区、应急水源等。
三、数据库
按照数据功能及其与地理信息的相关特点,数据分为地理数据和属性数据。社会应急联动系统各部门的管理过程中主要有两种数据:属性数据和空间数据。属性数据包括大量的统计数据;空间数据是反映应联系统信息的空间坐标位置的数据(如事发地点、派出所位置等),主要指地图图形。如果把属性数据和空间数据紧密结合在一起,将使得整个社会应急联动信息的管理更加方便快捷和形象直观,并彻底改变社会应急联动规划、建设、实施、管理及资料保存的传统模式,从而实现社会应急联动管理的计算机自动化。
分布式数据库系统是整个系统的数据中心。它将以指挥中心为核心,各联动单位指挥中心和移动指挥中心为节点。
2.1.3 支撑平台设计
支撑平台有计算机网络系统、监控系统、显示系统、GPS系统、有/无线通信系统、图像传输系统、电源及机房、软件支撑平台等。其中,计算机网络系统包括指挥中心、二级指挥中心与移动指挥中心、业务执行机构(如:应急中队、派出所等)之间的三级计算机网络,即指挥中心局域网络、业务机关网络、与分支机关的广域网络、与移动指挥中心的远程访问网络。指挥中心与二级指挥中心、分支机构、移动中心之间有语音通信、数据通信,指挥中心与移动中心有语音通信、数据通信(无线)、现场图像传输;指挥中心与公安其它机构通过拨号网络访问(内网),指挥中心与普通老百姓通过拨号网络访问(外网)。
一、计算机网络
计算机与网络平台系统支撑系统运行的三级计算机网络、计算机和外设。
二、有/无线通讯网络
有线/无线通信系统提供CERS需要的有线/无线通信链路,是系统全部信息的输出/输入载体。包括程控用户交换机、接警座席台及数字录音系统、无线通信网(800M集群系统、350M集群系统)和有线通信网络。
三、监控与图像传输网络
图像监控系统对监控场所(包括市级机关、交通路口、公共场所、金融机构、大型商场、邮电通信枢纽、车站、码头等)进行实时集中监控,对所需的各种视频、音频、计算机文字、图形信息等进行收集、选取、存储,并控制显示在大屏幕、大尺寸视频监视器和首长多媒体终端等显示设备上。
现场图像传输与处理系统将现场的灾情实况视频图像数据进行采集和传输,送到现场指挥车或应急通信指挥中心进行显示和存储。
四、GPS系统
GPS子系统主要用于及时、准确地掌握被控车辆和船舶等移动目标的实时情况和准确位置。采用GPS全球卫星定位技术、GSM全球移动通讯技术、GIS地理信息处理技术和计算机网络通信与数据处理技术,在现有GSM、GPRS通讯系统的基础上开发出的一套社会综合防范和远程监控、通讯、管理、调度系统。利用该系统,可以远程无线监控、调度所有在GSM网覆盖范围内的警用车辆、急救车辆、应急车辆、出租车辆、租赁车辆、民用车辆等移动目标。移动目标GPS数据、其他指令及各类报警数据均由GSM信令信道传送到数据处理中心,并可根据需要自动接通预先设置的号码进行语音通话。
五、大屏显示系统
大屏幕显示系统主要进行应急地理信息显示、应急车辆状态显示、气象显示、应急实力信息显示、灾情受理地点显示、主要交通道口交通状态显示和部分重点保卫目标监控显示。指挥中心实现对指挥系统控制区的各种情况进行动态监管。大屏幕投影系统负责实现直观、完整、准确、清晰、灵活的显示各项信息,包括:各种地理信息、车辆状态显示、气象信息显示、实力显示、受理信息显示。这类信号由计算机相关软件生成,在现场计算机显示器上显示,同时调入所需要的信息在大屏幕作任意大型显示。便于整体统筹,指挥。同时指挥中心计算机与其它会议室(兼指挥室)计算机联网,使其它会议室可通过局域网调用所需信息在会议用投影机上显示。
六、支撑软件
支撑软件平台系统包括计算机操作系统、数据库管理系统、GIS系统和应用软件开发平台系统等。以下是我们的一个实例:
数据库服务器:Oracle .
GIS支撑平台:Mapinfo profession MAPBASIC
OA平台:Lotus Domino
开发平台:DelpHi VC Jbuilder
操作系统:Windows Advance Server
网络协议:TCP/IP
软件平台结构:软件平台采用C/S+B/S结构
2.1.4 标准与接口设计
系统接口:本应用系统是一个复杂的各种技术、各种相关系统、数据的集成系统,因此系统接口设计十分重要。系统接口分为外部接口、内部接口。接口有数据接口、软件接口、硬件接口。
标准的建设是CERS的核心工作。
2.1.5 系统安全的设计
安全设计从系统安全、数据及数据库安全两方面进行了设计。
2.2 CERS的框架设计
采用B/S与C/S相结合的体系结构。
一、Client/Server体系结构
Client/Server是一种目前发展已经非常成熟的计算机体系结构。在此之前,信息系统一般采用文件共享的方式,通过直接访问数据库来达到数据共享的目的。Client/Server体系结构严格地定义了客户端和服务器端对信息数据的处理范围。即客户端要访问服务器端的数据时,一定是以特定的描述语言,将请求信息首先传递给服务器端,由服务器端的相关模块判别并处理客户端的这个请求。请求处理完毕后,服务器端再将处理结果回传给客户端。这样才算一个访问过程的结束。Client/Server体系结构发展到今天已经非常成熟了,它可以把实现友好人机交互界面的任务交给客户端处理,而服务器端只需完成数据的存储和处理。这种体系结构的优点是:系统功能强大、交互能力强、系统运行效率高,并且开发工具和开发手段可选择性强。缺点是:所开发出来的系统相对比较封闭,主要适合于数据管理方式;系统结构复杂,开发周期长;安装和维护比较麻烦。
二、Browser/Web Server体系结构
为了克服Client/Server体系结构所存在的问题,最近几年来,随着Internet技术的飞速发展和日益成熟,特别是瘦客户机概念的提出和发展,提出了以Browser/Web Server体系结构为代表的多层Client/Server体系结构,作为对Client/Server体系结构的补充和发展。Browser/Web Server体系结构将Client/Server体系结构的两层结构发展到三层结构,一般可以认为是在原有的Client层和Server层之间加入了Application Server层(也称为中间件层)。Application Server层承担了原来Client/Server体系结构中Client层和Server层的部分任务,这样使得Client层和Server层所承担的任务相对减轻。Client层变成比较统一的界面,Server层主要处理信息数据的存储和管理任务,Application Server层负责具体数据的处理任务,而且可以根据处理任务的变化而变化。Browser/Web Server体系结构的主要优点是对Client端设备的要求逐步降低,运行维护量下降;Application Server层的中间件软件日益丰富和模块化,降低了系统开发的工作量,缩短了开发周期。主要缺点是Application Server层的中间件软件目前还不够丰富和完善,而且对网络系统的运行环境要求较高。
3. CERS面临的技术挑战与我们的对策
3.1 CERS的分析
CERS实施的核心是要尽量提高事件反应速度,缩短事件反应和扑救的时间。CERS与其它集成系统相比,最大的特点是:
3.1.1 实时性要求高,应急反应要及时
CERS实时性要求高,这就要求实现各个层次的互联互通,如有/无线数字链路、有/无线语音链路、有/无线图像链路的互联互通;实现数据的互操作、软件的互操作与语义的互操作。
3.1.2 具有移动办公的特点
这是CERS最大的特点。系统设计要重点考虑这个特点。
3.1.3 具有分布性、异构性、海量性和动态实时性特点
要实现各个层次的互操作。
一、数据的互操作
解决得不错。
二、软件的互操作
已有成熟的解决方案。
三、语义的互操作
还刚刚起步。
3.2 CERS面临的挑战
1.需要集成多个行业或部门的业务:CERS需要集成公安、消防、交管、120、供电、市政和政府等部门的应急业务。目前的集成大都专注于技术层面的互联互通,并有效地实现了,而集成不仅需要找到、操作并获取信息,还需要理解信息的含义。各应急服务系统间通讯会存在多词一义、一词多义或近义等语义冲突;
2.需要动态实时集成不同业务领域的已有或新建应急服务系统,这些系统是分布的、异构的,集成规模大;
3.集成的业务流程会动态增删修改,如开始可能是110、120、119的联动,随着时间的推移,会有电力抢险、地震救急等业务加入;
4.系统不能理解应急预案,所以不能按预案自动调度;
5.GIS是应急指挥的重要手段,CERS需要实现时空集成。
3.3 我们的对策
3.3.1 采用的技术
XML 及相关技术,如Web Service、Ontology
元数据技术
3.3.2 实施思路:建立集成框架,实现各业务系统的集成
CERS是一个复杂的集成系统,必须坚持“总体设计、分步实施”的原则。本着业务是核心,技术是手段的原则。
深入分析业务流程,建立各联动单位的业务模型、系统模型和功能需求。
深入分析现有业务系统和数据,理清思路。
深入分析各业务系统的接口,建立一系列业务标准和技术规范。
在标准和技术规范的指导下,建立集成框架的编码标准、通讯协议和应用模型。
在集成框架的指导下,进行各系统的开发。
CERS是一个系统集成的项目,需要制定一系列信息交换的数据编码和通讯协议。
一、建立业务模型与系统模型
建立CERS的UML模型是系统设计与实施的基础,应急事件ONTOLOGY模型E2M是信息共享的核心:
E2M提供信息交换的通用模型和词汇表,是各业务达成一致的关键基础和共同理解。每个业务都有各自的领域ontology,与通用模型有映射规则。业务系统收到的共享信息符合通用模型,所以能理解,并按映射规则转成领域模型描述进行处理。发出信息时需按映射规则转成通用模型,其它系统就能理解,从而实现了系统集成。增删一个业务系统时,其它系统不需改动。此外系统能理解用E2M描述的应急预案,实现多业务预案的自动调度;系统对多个部门联合行动的事件的处置内容进行合并,并事后进行事件回放,以便进行事件分析。E2M具有语言/平台/中间件无关性、重用性和可扩充性,E2M将语义从传送机制和应用接口中分离出来,使得集成更强壮,对集成技术的更新有更强的适应性。
二、建立集成框架
基于XML、Web Service、Ontology等技术的集成框架包括集成总线及Adapter Service、元数据库及集成协调器与供二次开发的API及Web Service工具集,它实现了数据互操作,软件互操作与语义互操作。集成总线是一组面向领域的编码标准与通讯协议。与总线标准不符的老系统和其它相关系统只需编写Adapter Service就能被集成。元数据库是集成框架的核心,管理系统中的所有信息与应用服务,屏蔽信息及服务的分布性与异构性。集成协调器用于数据的更新,元数据的管理。Ontology则用于定义描述领域相关元数据的术语。数据交换格式与通讯协议均用XML定义。所有应用通过SOAP协议实现互操作。这一集成框架实现了大规模空间信息及服务的动态集成,能保护已有投资,并能集成网上丰富的商业Web Service,是一个开放的可扩充的框架。
集成几十家不同业务领域的应用以增加(或重组)新的大型业务应用成为当前IT建设的主流。应用集成面临的最大问题是不同业务领域的术语存在一词多义、同词不同义、多词一义等语义冲突。解决语义冲突,实现应用集成是ontology最重要的应用之一,也是目前国际IT界研究的热点。我们提出了“中介抽象ontology法”来解决语义冲突。该方法适合大规模的应用集成,且不需改造原有各应用的ontology。首先分析城市应急联动系统中各业务领域的模型,对这些模型进行抽象,形成应急联动系统模型,并在此基础上建立ontology模型。该模型包含了应急领域的抽象术语,即应急领域的抽象ontolog模型,可作为混合法中的公共ontology。当新的应急业务领域增加时,很容易生成它与抽象ontology间的映射。当一个应用使用另一个应用的术语时,先通过这些映射将一个应用的术语转成抽象ontology中的术 语,再转成另一应用的术语,以实现语义互操作。
三、建立接口标准和技术规范
建立集成总线中的信息编码标准和通讯协议。
3.4 我们已有的研究成果与开发经验
3.4.1 CERS研究与建设的初步成果
已经建立了应急联动系统CERS的业务模型
已经建立了应急联动系统CERS的UML模型
部分建立了应急联动领域的术语表
部分建立了应急联动领域的ontology
已经建立了应急事件的ontology模型E2M
已经建立了大规模空间信息服务集成框架
已经设计了解决多业务集成语义冲突的方法
正在搭建应急联动系统的实验环境,119 120 110三个的联动
3.4.2 应急系统建设的经验
我们对应急联动系统中各联动单位的业务流程有较为深刻的理解和开发实践经验,如应急联动系统的前期设计、多个城市的110、119、120、12369、122。
专家简介:王文俊,男,博士,高级工程师,高级监理工程师,北京大学计算机系。主要研究 领域为GIS、Web服务,研究应用背景是数字海洋、城市应急联动。自1996年起,主持多个城市应急指挥及相关系统(119、110、120) 的分析设计与开发实施,对应急业务有深刻的理解和丰富的研发经验。从2001年起在应急联动系统业务建模、应急事件模型、应急 预案模型,以及在分布式异构环境下实现协同工作的关键软件技术开展了研究工作,并组织实现了某城市的应急联动一期工程(小规模),是多个城市与地区应急联动项目的顾问与专家。