县智慧城市建设智慧城管平台及城管监控技术方案

县智慧城市建设

智慧城管平台及城管监控

技术方案

目录

1.智慧城管平台设计.....................................5

1.1.总体设计........................................................5

1.1.1,总体设计原则..............................................5

1.1.2.系统总体架构.............................................6

1.1.3.业务流程设计..............................................7

1.1.4.总体技术路线............................................10

1.2.应用软件平台建设方案..........................................18

1.2.1.统一受理分平台..........................................19

1.2.2.业务协同分平台..........................................29

1.2.3.智能管控分平台..........................................63

1.2.4.数据交换分平台..........................................77

1.2.5.地理信息分平台..........................................86

1.2.6.终端应用分平台.........................................101

1.2.7.数据分析分平台.........................................120

1.2.8.智慧环卫分平台.........................................142

1.2.9.xx县与日照市数字城管系统接口..........................144

2.智慧城管监控部分设计...............................149

2.1.现状分析......................................................150

2.2.建设目标.....................................................150

2.3.系统概述......................................................151

2.4.系统原理......................................................152

2.5.系统组成........................................................153

2.5.1.前端抓拍摄像机.........................................153

2.5.2.中心管理平台............................................153

2.5.3.视频存储系统............................................154

2.6.系统特点功能..................................................154

2.6.1.违停自动取证功能.......................................154

2.6.2.车牌自动识别功能.......................................154

2.6.3.多目标处理功能.........................................154

2.6.4.手动取证功能............................................154

2.6.5.支持复杂场景下的抓拍...................................155

2.6.6.超长延时抓拍............................................156

2.6.7.不重复抓拍..............................................156

2.6.8.多场景巡航取证..........................................157

2.6.9.兼具对逆行、压黄线违章检测功能.........................157

2.6.10.其他特点..............................................158

2.7.中心管理平台..................................................159

2.7.1.实时查看违章信息.......................................159

2.7.2.违停报警联动............................................159

2.7.3.历史违章信息查询.......................................160

2.7.4.查看违章录像............................................160

2.7.5.违章数据导出............................................161

2.8.存储设计.....................................................162

2.8.1.基本要求................................................162

2.8.2.图片存储................................................163

2.8.3.视频存储..............................................163

2.9.设备选型......................................................163

2.9.1.违停抓拍高清球机.......................................163

2.9.2.高清视频矩阵............................................169

2.9.3.存储磁盘阵列............................................180

2.9.4.违停管理平台............................................184

1.智慧城管平台设计

1.1.总体设计

总体设计原则

•整体规划、分步实施、重点突破

数字化城市管理系统涉及部门多、事项杂，系统建设内容丰富，应统一规划、

整体设计。在项目实施中应根据原有系统情况和不同部门的状况，划分阶段，先

易后难。

・技术先进、功能使用、扩展性好

在系统设计和建设中尽可能采用先进的技术和设备，保证先进性、安全性、

可靠性和可扩展性。各项功能设计要方便实用，操作简单，便于修改，容易定制,

满足个性化要求。

•借鉴国内已有经验，选用成熟设计

为缩短建设周期，避免项目风险，建设中要借鉴国内同类系统建设经验并有

所创新，在经过使用检验、成熟的设计和软件产品基础上加以改造升级。

•利用、保护原有投资，提升原有系统功能

在项目建设重要充分利用现有信息化资源，包括网络、服务器、信息和审批

业务系统等。在设计方案重要充分注意保护各部门已有的业务系统，在不改变原

有系统业务流程基础上实现系统互联和信息共享。通过系统建设不但要实现统一

管理功能，还要为各部门业务处理增添新的功能带来好处和便利。

•加强身份权限管理，注重系统安全和可靠运行

系统在于个行业部门连接及提取数据是要确保各行业部门的网络与信息安

全，确保本系统内部用户身份的唯一性、可靠性、不可抵赖性。

1.1.2.系统总体架构

总体框技术架图如下:

IA-ms*上中T-

•数据层

通过建立城市基础数据库的设计。建立数字城管系统的数据层，包含各类基

础空间数据库、事件部件数据库、地理编码数据库、人员组织机构数据库、业务

数据库、综合评价数据库以及其他资源的数据库等。

•支撑层

支撑层是系统应用层与数据层之间的桥梁，通过数据交换平台整合数据中心

的所有数据库，形成统一的数据平台，供各应用系统进行方便的调研和管理。

・应用层

建设开发符合需求的各个应用子系统：无线数据采集系统、监督受理子系统、

协同工作子系统、地理编码子系统、监督指挥子系统、综合评价子系统、应用维

护子系统、数据共享与交换子系统、基础数据资源管理子系统、视频监控整合分

析子系统、外勤车辆及外勤人员管理子系统共11个应用系统。

•表现层

表现层分为数据采集和信息展现两部分，为公众、信息员、领导提供多种方

式的展现：

数据采集部分包括城管通采集终端、外网门户、呼叫中心、摄像头等；

信息展现部分采用丰富的表现介质，包括移动终端设备、外网门户、内网办

公桌面、领导办公桌面等。

1.1.3.业务流程设计

数字化城市管理模式的工作流一般包括受理、立案、派遣、处理、督察、核

查和结案等七个环节阶段。由监督中心负责统一受理来自社会公众、监督员、领

导批示等多种来源的城市管理问题，经甄别立案后，由指挥中心进行统一派单处

理。

.信息采集(收集)阶段

信息采集阶段的主要业务流程：相关领导、监督员、市民通过城管通手持终

端、手机、电话、城市管理门户网站等手段向监督中心提交城市管理问题信息。

城市管理问题信息来源主要包括领导批示、市民投诉和监督员巡查采集三种。

(1)领导批示：城市管理相关领导通过政府公务外网或移动督办子系统登

陆数字化城市管理系统，直接对城市管理问题进行批示立案。

(2)市民投诉举报：市民发现问题，通过电话、手机、城市管理门户网站

等多种方式向监管中心举报，监督中心登记公众举报信息，通知监督员核实，监

督员通过城管通手持终端上报监督中心。

（3）监督员巡查采集：监督员在所负责的若干单元网格内发现问题后，通

过城管通手持终端及时上报，上报内容包括发生问题的位置、图像、表单、音频

等信息。

1.1.32案卷建立阶段

案卷建立阶段的主要业务流程；监督中心接收监督员上报问题，审核立案后，

批转到指挥中心。

监督中心首先对获得的问题信息判断其信息来源，对于监督员上报和领导批

示的问题可直接进行立案，对于市民投诉举报的信息，则交给监督员进行现场核

实；对于不属实的信息进行注销，不符合立案条件的信息也进行注销；属实的信

息进行部件/事件判定，将事件信息直接进行立案判断，对部件信息判断其在部

件数据库中是否存在，存在则进行立案判断，不存在则需要添加临时部件，等专

业部门更新数据后，再将临时部件替换成更新后的部件。

任务派遣阶段

任务派遣阶段的主要业务流程：指挥中心接收监督中心批转的案卷，派遣至

相关专业部门处理。

监督中心立案后，由指挥中心根据问题责任部门分派任务，交由责任部门进

行处理，同时对责任部门进行计时考评。

任务派遣遵循“属地原则（即按问题所在区域认定责任主体的原则）”与“属

主原则（即按问题主管部门认定责任主体的原则对于一般案件，由指挥中心

分派专业部门进行处理；对丁重大案件，指挥中心派遣专业部门进行处理同时报

送领导督办。

1.134任务处理阶段

任务处理阶段的主要业务流程：相关专业部门按照指挥中心的指令，处理问

题，将处理结果反馈到指挥中心。

对于一般案件，由专业部门进行处理，并将处理结果反馈到指挥中心；对于

重大案件，由专业部门进行处理，同时主管领导督办。

1.1.35任务反馈阶段

处理反馈阶段的主要业务流程：指挥中心将相关专业部门送达的问题处理结

果反馈到监督中心。

1.136.核查结案阶段

核查结案阶段的主要业务流程：监督中心将问题的处理结果通知监督员进行

核查、上报，核查信息与处理信息一致则进行结案，否则要求专业部门重新处理。

如果核查结果为问题已解决，则进行结案；如果核查结果为问题没有解决，

则将问题信息流转到轴，指挥中心将责成专业部门进一步进行处理或重新进行处

理。

1.1.37综合考评阶段

综合考评阶段的主要业务流程：系统根据预先设置的考评指标、考评指标权

重（分值）、考评周期，结合来自城市管理门户网站的考评数据，对城市管理相

关责任主体进行考评，生成考评结果，并将部分考评结果信息通过发布公共信息

子系统向社会发布。

综合考评主要包拈区域考评、部门考评和岗位考评。

区域考评按一定周期对社区、单元网格不同层面区域进行考评，根据区域考

评模型，由系统自动生成考评结果。

部门考评按一定周期对专业部门和各责任主体进行考评，根据部门考评模型,

由系统自动生成考评结果。

岗位考评按一定周期对监管中心、指挥中心、各岗位和监督员等进行考评，

根据岗位考评模型，由系统自动生成考评结果。

1.14总体技术路线

.采用基于J2EE技术体系结构的整体优势

1、J2EE技术标准:

J2EE是一个基于JAVA的应用系统的运行标准，由于采用JAVA技术开发，

具有JAVA语言固有的开放性和跨平台特性，很多系统平台厂商都对其全力支持,

因此可以选择多种硬件平台、操作系统、数据库、中间件和应用系统，基本做到

只开发一次，就可以在各种环境下运行，构成不同规模的应用解决方案。J2EE

技术采用组件模型，保证组件本身可重用，并规范了组件之间的通讯、交互功能,

通过标准接口实现数据库的隔离，同时提供事务管理.、配置管理等一系列规范。

使用遵循J2EE标准的平台，可以从根本上保证系统具有可扩展、可重用、易管

理等能力。

J2EE网络服务的部署模式如下图所示:

2、安全性:

应用体系结构为三层结构的应用系统，客户机必须通过应用服务器才能访问

数据库服务器，杜绝了客户机直接访问数据库服务器的可能；客户机对服务器的

访问特权可以指定或内置于三层中的每一层，提供三个级别的安全性。

3、稳定性：

应用体系结构为三层结构的应用系统，其业务逻辑层与用户表示层、数据服

务层完全分离，三层之间相对独立，使得其中某一层的改变根本不影响到其他两

层。因而，当用户需求发生变更时，系统维护人员可以很容易地控制变更范围，

系统的稳定性特别高。

4、可适应性：

应用体系结构为三层结构的应用系统，应用服务器（即：业务逻辑层）主要

承载与管理应用系统的全部业务逻辑，每一个业务逻辑被封装成独立的应用组件,

组件与组件之间只通过有限的、指定的接口进行通信，当某一业务逻辑发生变化

时，仅须修改其相应的应用组件即可，对象的结构与交互方式、数据的结构与存

取方式等不须作修改，有效地限制了一处修改而处处牵连的“波动效应”，系统

具有很强的变化适应能力。

5、可移植性：

应用体系结构为三层用纯Java语言来实现的，应用业务逻辑的部署与应用

服务器具体的机型、操作系统无关，应用系统可以任意移植、轻松实现跨平台运

行，更可以支持异构平台之间的互连和紧密衔接。结构的应用系统，业务逻辑层

的应用组件的开发是采纯Java语言来实现的，应用业务逻辑的部署与应用服务

器具体的机型、操作系统无关，应用系统可以任意移植、轻松实现跨平台运行，

更可以支持异构平台之间的互连和紧密衔接。

6、可伸缩性：

应用体系结构为三层结构的应用系统，由于其所有的应用程序（即：应用组

件）全部置于应用服务器中，用户可以根据其系统的规模，来确定应用服务器的

配置与数量，当系统的规模扩大时，仅需升级应用服务器的配置或增添应用服务

器的数量，来满足日益增长的业务需求，系统的可伸缩性极强。

7、易维护性：

应用体系结构为三层结构的应用系统，由于三层之间相对独立，系统的变更

范围容易控制；客户机不需要安装复杂的网络、数据库等连接和驱动程序，其维

护工作和维护成本趋于“零”；应用服务器中的业务逻辑被封装成独立的应用组

件，某一业务逻辑的变化仅仅影响到某一独立的应用组件，系统具有很强的适应

能力；因此，应用体系结构为三层结构的应用系统，其系统的维护工作简单、维

护成本较低。

1.1.42采用B/S构建xx县数字化城市管理核心业务系统

为充分保证系统在安全性、跨平台性、易扩展性、易维护性等方面的要求，

建议采用先进的基于JAVA平台的三层应用体系结构。在这种结构下，用户界面

完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服

务器端实现，形成所谓3-tier结构。用通用浏览器就实现了原来需要夏杂专用

软件才能实现的强大功能，并节约了开发成木，是一种全新的软件系统构造技术,

这种结构已成为当今应用软件的首选体系结构。

三层结构应用系统相对于C/S两层应用系统，具有许多内在的优点。

1、逻辑界限清晰：

中间层允许用户把全部逻辑函数从另外的两个层中移到中间层的一个组件

中去定义实现，这样各层之间相对独立使得其中某一层的改变不影响其他层。因

而，当用户需求发生变化的时候，开发人员可以很容易地控制变更的范围，从而

达到及时修改的目的。

2、资源的优化：

由于一个应用系统的功能被分为三个部分，因此可以根据各层负载情况，将

它们分布到相应的硬件平台上。并可根据业务扩大的需求及时增加，可升级相应

的硬件平台来满足不断增加的负载需求，使得系统具有良好的可扩展性。再行,

可使应用系统较为方便地使用异种数据源。

3、系统的易维护性

由于B/S结构客户端只需要浏览器(InlernetExplorer),既不需要安装复

杂的网络、数据库等连接，更不用安装伴随开发工具的界面控制驱动程序，即便

需要在浏览器中嵌入必要的界面控制内容，浏览器本身也会自动下载及安装，完

全省去了人工干预，其维护工作和维护成本趋于“零”，因此，采用B/S应用体

系结构系统的维护工作简单、维护成本较低，非常有利于“城市模块化管理系统”

这样一个全市、业务应用广泛和需要随时根据需要进行功能方面、界面控制等内

容更新的系统。

4、系统的安全性

整个系统由三个部分组成：客户端、中间层应用服务器、数据库服务器。应

用系统的层次结构划分为：用户表示层、业务逻辑层、数据服务层，在B/S三层

结构应用系统中，由用户表示层向业务逻辑层发出请求，然后业务逻辑层决定使

用哪个数源来满足其请求。通过使用相同的调用接口，业务逻辑层就可以对任何

可用的数据源访问。最后，可以增强和提高信息的安全性。访问特权可以指定和

或内置于三个层次的每一个层次中，以便提供三个级别的安全性。

1.1.43采用基于WebServices技术实现系统对外接口

WebServices技术描述了一些操作的接口，通过标准化的XML消息传递机

制，可以通过网络访问这些操作。WebServices是用标准的、规范的基于XML

的WSDL语言描述的，它隐藏了服务实现的细节，允许独立于硬件或软件平台、

独立于编写服务所用的编程语言方式使用该服务。这使得基于WebServices的

应用程序具备松散耦合、面向组件和跨技术实现的特点。

采用基于WebServices技术实现系统对外接口具备以下特征：

1、完好的封装性

WebServices既然是一种部署在Web上的对象，自然具备对象的良好封装

性。对于使用者而言，它能且仅能看到该对象提供的功能列表。

2、松散耦合性

这一特征也是源于对象/组件技术，当一个WebServices的实现发生变更的

时候，调用者是不会感到这一点的。对于调用者来说，只要WebServices的调

用接M不变，WebServices实现的任何变更对他们来说都是透明的，甚至当Web

Services的实现平台从J2EE迁移到。NET或者反向迁移时，用户都可以对此一

无所知。从前，分布式的应用程序逻辑需要使用分布式的对象模型，诸如

Microsoft的分布式组件对象模型（DCOM）、对象管理集团（0MG）的公用对象请

求代理程序体系结构（CORBA）或SUN的远程方法调用（RMI）o通过使用这种基

本结构，开发人员仍可拥有使用本地模型所提供的丰富资源和精确性，并可将服

务置于远程系统中。这些系统有一个共同的缺陷，那就是它们无法扩展到互联网

上。他们要求服务客户端与系统提供的服务本身之间必须进行紧密耦合，即要求

一个同类基本结构。这样的系统往往十分脆弱：如果一端的执行机制发生变化，

那么另一端便会崩溃。例如，如果服务器应用程序的接口发生更改，那么客户端

便会崩溃。对于松散耦合而言，尤其是在Internet环境下的WebServices而言，

需要有一种适合Internet环境的消息交换协议。而XML/S0AP正是目前最为适合

的消息交换协议。

3、使用协约的规范性

这一特征从对象而来，但相比一般对象，其界面规范更加规范化并易于被机

器理解。首先，作为WebServices,对象界面所提供的功能应当使用标准的描

述语言来描述（比如WSDL）。其次，由标准描述语言描述的服务界面应当是能够

被发现的，因此，这一描述文档需要被存储在私有的或公共的注册库里面。同时,

使用标准描述语言描述的使用协约将不仅仅是服务界面，它将被延伸到Web

Services的聚合、跨呢bServices的事务、工作流等，而这些又都需要服务质

量（QoS）的保障。我们知道安全机制对于松散耦合的对象环境的重要性，因此,

需要对诸如授权认证、数据完整性（比如签名机制）、消息源认证以及事物的不

可否认性等运用规范的方法进行描述、传输和交换。最后，所有层次上的处理都

应当是可管理的，因此，需要对管理协约运用同样的机制。

4、使用标准协议规范

作为WebServices,其所有公共的协约完全需要使用开放的标准协议进行

描述、传输和交换。这些标准协议具有完全免费的规范，以便由任意方进行实现。

一般而言，绝大多数规范将最终有W3c或OASIS作为最终版本的发布方和维护方。

5、高度可集成能力

由于WebServices采取简单的、易理解的标准Web协议作为组件界面描述

和协同描述规范，完全屏蔽了不同软件平台的差异，因此，无论是CORBA,DCOM

还是EJB,都可以通过这一种标准的协议进行互操作，实现了在当前环境下最高

的可集成性。

城管系统涉及了多种集成方式，所以必须拥有一个全面的集成平台才能满足

需求。举例来讲，针对现有的“协同工作系统”及“G1S系统”来讲使用JCA模

式会成为比较合理的集成方式。由于这些系统都已经成为标准的完整应用拥有自

己的逻辑与业务、安全等模式，如果只进行简单的数据集成则需要重新开发大量

的原有系统中的逻辑，为集成带来很多工作量与复杂度。同时该类集成还需要拥

有统一的专用管理界面，以保证集成后的可维护性。而针对同步建设的几个子系

统，由于构建在同一平台下，架构构一致沟通便利，因此更多的利用JMS直接进

行系统间通信将成为理想的集成模式，该方式即能保证集成系统间的独立性又能

保证系统的灵活度与可定制性、可调整性。还有一类集成属于针对外部相关机构

的无关性集成任务，该类集成由于涉及的技术架构，应用体系等都有较大的不确

定性，因此采用WebServices将能够提供更灵活的集成性。借助WebServices

的技术无关性与通信标准性可以保证针对未来的各种符合标准的系统都能够达

到无关性集成，并且其系统间的相关性可以降到最低，使集成任务的工作量更少。

L144.利用XML作为系统接口数据交换标准

XML数据传输是不同系统之间日渐流行的标准数据传输方式，由于与平台和

编程语言的无关性，因此，通过XML可以有效保证对各种异构系统的数据接口需

要，以达到政府各系统数据资源的最优整合。

XML适于异构应用间的数据共享。

XML的灵活性和扩展性使其可.以对不同应用甚至是差异很大的应用间的数据

进行描述，尤其是对于那些专用于记录数据的应用。另外，XML具有自我描述的

特性，结果是数据可以在不同的应用间进行交换与处理而不必要求相应的应用程

序是针对该数据定制的。

用于强大的数据检索

XML属于元标记语言，进一步讲，根据这一特性，用户只要在XML的文档类

型定义文件中定义一系列有意义的标记，这样基于该文档类型定义文件所产生的

XML文档就可以按照任意的条件进行查询和检索，甚至实现计算机自动检索，而

相应的检索引擎可以是通用的而不必局限于具体的应用。

提供多诏种支持

XML规范中提供了对多语种的支持,包括UTF-7、UFT-8、UNICODE、GB2312

（简体中文）、BIG5（繁体中文）等等，这一特点使得XML非常有利于多语种的

应用开发。

1.1.45面向对象（00A）的设计与开发

根据不同的应用类型，采用面向对象或面向过程的系统分析与设计方法。

传统的软件工程以软件的工程化为目标，强调方法论，工具与环境，质量保

证体系，项目管理，配置管理，但基本理念是基于具体需求、从零开始的开发。

这种开发模式显然已经不适合于现代软件系统开发的要求。而面向对象的设计

（00A）以软件的组装式生产为目标，强调各种粒度的软件重用、接口与表示和

实现分离、统一对象模型，继承和发展了传统软件工程。面向对象技术将计算看

成是一个系统的演变过程，系统由对象组成,通过一系列的状态变化来完成计算。

对象具有保持能力和自主计算能力。面向对象设计和实现的重点是多个对象的网

状组织结构和协同计算，而不是过程调用的层次结构，这样就在本质上适应了并

发、分布系统及互联网的计算特征。

1.1.46工作流引擎技术

工作流技术适应于电子政务平台框架下的具体电子政务应用系统中各个政

府职能部门之间的联办互动工作，公文流转，网上审批、信息传递等系统都要用

到工作流技术。采用工作流引擎技术将信任服务、授权服务和工作流等业务流程

有机融合紧密结合在一起，构成安全的工作流业务系统，为不同业务系统集成提

供实现的技术手段。

具体而言，工作流技术要达到以下目标：

支持跨平台、多种语言的接口，使用户的已有应用可以在不做改动或稍做改

动的情况下应用到新的工作流上；

建立流程控制数据库，让适当的人在适当的时间通过适当的方式提醒从而以

适当的手段完成适当的事情；

支持多种工作处理机制，例如工作人员外出时的远程办公机制、授权机制等

等；

与消息中间件之间的有效结合，支持各种灵活的触发和提醒机制，例如界面

提示功能、数据库触发机制和消息的存储转发等等。

在工作流引擎的设计上实现流程、信息和人的分离设计，各司其职，各成体

系。

工作流的设计思想如下图所示。

文科费料人数据库

组织/角色

图工作流引擎设计思想

.基于WebGIS构建地理信息与业务系统结合

海量地图数据的共享应用，对系统运行的网络环境提出非常高的要求，地图

用户的不断增长，也充服务器和网络环境提出更高要求。

GIS技术与Web技术的结合形成的WebGIS技术，使地图数据在网上发布成

为可能，用户可以通过浏览器进行地理信息的各种操作。与C/S结构的GTS应用

系统不同，WebGIS服务器向客户端发送的•般是最终生成的地图影像的图片，

用户无法直接存取地图资源库，从而真正保证了原始地图数据的应用安全。

系统采用空间数据库技术，对空间数据进行有效组织，并通过负载均衡技术,

在多服务器环境中实现最佳的系统运行效率。通过WebGIS技术大大降低了对网

络带宽的运行要求，从而满足政府部门在政务专网上对地图数据应用的要求。

1.2.应用软件平台建设方案

本章节主要介绍本项目各应用软件子系统的功能设计内容。

1.2.1.统一受理分平台

121.1.监督受理子系统

监督受理子系统（即“监督受理子系统”）是为数字化城市管理监督中心设

计，通常设立呼叫中心，使用人员一般为呼叫中心接线员。通过信息传递服务引

擎将无线数据采集系统报送的问题信息传递到接线员的工作平台，接线员通过系

统对各类问题消息接收、处理和反馈，完成信息收集、处理和立案操作，为协同

工作子系统提供数字化城市管理问题的采集和立案服务，保证问题信息能及时准

确地受理并传递到指挥中心。

呼叫中心受理的数字化城市管理问题包括监督员上报、部门上报和社会公众

举报的问题。

该系统应实现的主要功能包括：

＞提供管理问题信息的自动受理功能；

＞提供管理问题信息的手工登记功能；

＞能根据上报管理问题信息中包括的坐标信息，在地图中自动标识出问题

发生位置；

＞通过登记的问题位置描述，能在地图中搜索并定位到问题发生位置；

＞具备向监督员发送问题任务指令功能；

＞具备接收监督员核实、核查信息、结案处置功能；

＞能够与协同工作子系统进行数据交互，向协同工作子系统自动报送任务

数据；

＞具备基础地理信息、地理编码信息、单元网格信息和部件信息等地图显

示、查询功能；

＞具备新问题或任务反馈信息实时提示功能;

＞能够通过电子地图查询某个单元网格当前在岗监督员。

1）监督员上报

受理人员接到监督员上报信息后进行系统录入。系统通过受理人员录入的案

件类别信息自动关联案卷所属类别、所属区县、所属街道、所在万米网格和所负

责的监督员，减少了受理人员信息录入工作量，与地图信息一一对应，实现了智

能化的应用效果，提高了工作效率。

监督员在城管通中处理完成待核实问题采集并提交后，呼叫中心电话坐席人

员自动接收巡查人员充■任务信息的反馈结果，以便电话坐席人员对预立案件的处

理。

呼叫中心电话坐席人员可以对巡查人员发送任务，经过系统处理后发送到巡

查人员的手持终端机上。在城管通中将显示待处理的问题。

在接线员接收公众咨询或投诉的时候，接线员可以调用出G1S地图，并根据

公众的地点描述进行地图的查询，同时能够直接在地图上选定一个点供职能部门

处理时的位置参考。

地图浏览

在地图浏览中可以根据不同图层进行分层选择并显示。同时，根据不同图层

查询该图层的元素属性。

通过输入网格编号或手动点击地图进行定位后，地理编码引擎将•自动进行匹

配，给出详细的位置描述。同时提供了对于关键字和部件的查询。

部件®号1201140209000172

万米网格120114001007

部件损坏

事件描述

武省区杨H僧行缶H伊后。2网格|

位司宙述

附件♦览…

部件取点

地理编码查询

2）公众举报登记

＞记录公众提供的举报信息，由相关人员定期将建议信息进行分类整理，

并分类上报给相应的专业部门。

＞记录用户接收反馈意见的方式、希望得到答复的时限等。

＞将问题或投诉内容进行分类，进行预立案提交到“协同工作系统”流程

等待下一步处理。

3）问题核实立案

对于部分问题需要进行监督员核实的，系统将自动发送通知给相应的监督员,

由监督员进行核实采集。在核实采集的数据可靠的后，监督中心受理员可以根据

相关规定选择建议的处理部门和处理意见，填写完毕后，进行立案操作。立案后

的信息形成正式的案卷将交给协同工作子系统进行案卷的处理过程。

如核实的数据为不存在的信息，监督中心受理员将不对该信息进行立案，可

进行删除操作。

4）核查结案

根据监督员快捷上报的案卷处置问题，系统提供案卷上报核实管理功能。案

卷上报核实管理主要是针对监督员上报的快捷案件进行核实处置，受理员通过案

卷上报核实管理确定监督员上报问题及处置的合理性，对于合理的案卷进行结案

处置，并计入考核管理。

1212问题来源子系统

问题来源子系统为城管监督中心受理员使用，主要提供一下功能。

1）分类汇总统计

根据现有数据进行统计，以图形、表格等方式进行显示，从而可以方便地对

热线系统的运转情况进行分析，并可根据分析结果进行适当地调整，使热线系统

能够更好地满足实际情况的需要。系统提供统计分析功能主要表现在下面几个方

面：

＞来电情况统计：可以统计某个时间段内来电数、语音受理数、人工受理

数、直接回复数、有效反馈数等项目的具体数值以及所占的百分比，并以图形方

式显为IO

＞可以对来电的业务类型进行分类统计，以表格与图形的方式来进行显示,

分月话务量统计：

＞可以按月对各种类型的来电进行统计，形成表格与图形，可以有效地进

行比较。

＞数据采集情况统计：对由接线员辅助进行数据采集情况进行统计。

＞接线员工作统计：对接线员的工作情况（如工作时间、受理电话数、有

效答复数等）进行统计。

2）城市管理问题来源及处理

＞咨询业务处理：

通过热线电话的接线员，能交互式咨询相关事项，例如办事流程、需要做的

准备工作等。

接线员可以使用系统提供的资料查询功能，来准确回答公众的咨询。

接线员无法当场答复的问题，可以通过本系统直接将电话转至具体的委办局

有关人员，由其解答；也可以推迟一定的时间来向用户提供准确的反馈信息。

＞公众建议处理：

记录公众提供的建议信息，由相关人员定期将建议信息进行分类整理，并分

类上报给相应的专业部门。

＞问题投诉处理:

对于常见的并且有解决方案的问题，由接线员直接进行答复。

对于无法现场答复的问题，记录用户接收反馈意见的方式、希望得到答复的

时限等，进行预立案提交到“协同工作系统”流程等待下一步处理。

＞公众举报处理；

记录用户接收反馈意见的方式、希望得到答复的时限等。

将问题或投诉内容进行分类汇总，进行预立案提交到“协同工作系统”流程

等待下一步处理。

3）问题状态分类

汇总所有城市管理监督中心受理的所有问题状态分类为以下四类，并且要做

到实施更新以便能够更有效提高服务效率：

＞待处理

＞处理中

＞已处理

＞已作废

121.3.城管热线子系统

12319作为政府城建面向全社会的服务系统，把政府城建系统各级部门和各

区政府的职能统一到一个服务平台上，统一涵盖政府供水、供气、供暖、市政、

市容、城市交通、园林绿化、城市规划、房管、环卫、路灯、建筑市场、建筑工

程质量和安全监理等多种行业，同时为普通市民提供与其日常生活密切相关的各

种便民、信息服务和社区服务。

随着社会形势的发展，改革的深入，新情况，新问题不断出现，人们对生活

的质量及相关的社会服务提出了越来越高的要求。作为城建体系与市民的有效沟

通渠道，12319热线在解决市民生活中的实际困难的便民工作中发挥着的作用也

越来越大，主要体现在：

12319热线是一个面向全社会的服务系统，将城市供水、公交、燃气、供热、

市政、环境卫生、园林绿化、城建监察等领域内的政策咨询、问题投诉、抢险抢

修接警调度等不同的城建管理服务统一到一个热线语音平台，极大地方便了群众

生活。

城管系统都设立专门机构直接与热线中心联系，即时处理服务中心转来的各

类问题，实现“市民一热线中心一责任单位一市民”的闭路循环，做到受理及时、

反应快速、处理到位，使12319热线成为密切政府与群众关系、创建行业服

务品牌的一项重要举措。

12319建设事业服务热线系统的建立，为城建事业部门和政府管理机构转变

职能，由接收服务到主动提供服务提供了方便的条件、方式和方法。

业务流程:

受理：热绮旨挥中

6.回访，指挥1.

心接受市民通过电话、

中心向市民回

传真、矩信、互联网

访满意程序

等各种方式传递信息

2.分理：根据系统内

5.反馈：联动机构,郃取责分工，分析受

责任单位网旨挥理信息，明确责任里

中心反愦处匿结位

果

3赤单：通过计算机网格、电

4处理:贵任单位、

话、传真等方式向肤动单位下

执行部门派出应急

达指令，并将受理通知单传递

处置队伍，在规定

到相关责任单位

时限内现场处置

图12319业务流程图

按照12319服务热线系统具体办事流程，该系统功能模块分为来电管理、回

访管理和坐标定位。

1）来电管理

＞问题反映

由公众热线或领导批件转来的有关部件、事件问题。这两类问题的案件受理

和立案阶段的处理流程有所不同。

＞事件受理

市民上报的问题通过12319热线上报到服务中心，由服务中心受理处的接线

员进行登记，然后由值班长综合判别并立案受理。

公众举报热线反映的问题和领导批件转来的有关部件、事件问题由服务中心

接线员统一接收，再批转值班长进行判别立案受理。

＞事件分理

根据系统内部职责分工，分析受理信息，明确责任单位。

＞事件派单

服务中心指挥协调处的值班长按照不同事件的不同处理流程，分别对已登记

受理问题进行综合判别并将工作表单派送到各专业部门。

＞事件处理

各专业部门根据相关的要求负责对下发的事件进行处理。

＞事件反馈

联动机构、责任单位向服务中心反馈处理结果。

2）回访管理

＞回访、综合评价

服务中心向市民回访满意度，并生成对各区域、各专业的部门的客观评价。

并由服务中心监督员组织对各级专业管理部门工作人员的工作进行抽查扣分考

评。

3）坐标定位

根据电话热线受理过程中，通过坐标确定某一事件发生位置，能定位到某一

网格区域内，能够根据属性或位置查询城市事件的信息，并自动进行定位。

1214知识库

接线员在接受公众咨询过程中，需要即时查找各种资料，知识库模块为接线

员提供了这样的资源数据库。通过快速收集、便捷查询和智能分析，为接线员提

供便捷的业务和法规支持。知识库所涉及的信息建设是一个持续积累的过程。该

子系统包含的模块：

＞城市管理业务相关知识

＞国家和各省市有关城市管理建设的相应政策以及法规。

＞城市管理经验借鉴

具体的操作功能如下：

＞目录管理

对知识库的内容进行目录化管理，使其便于相关人员进行查阅。

选择父分类.□

U3根节点

e£3女呕丝1

g丽

单哥里纠纷处理

r。厮或分类12

。匕）分数

f匕I3131分咬3

r匕五祠分类6

O匕I4限分类9

cb撕it分类10

ce痂彳分类16

c£3飞洒地方

r匕排序1

V匕分类摔序

关闭

图：基于树的目录管理

＞索引管理

将知识库的内容进行关键字提取，将关键字以索引的形式进行处理，用户可

以通过对索引的检索达到内容的快速浏览。

系统会对经常性查询的索引美键字进行统计，便于相关人员快速内容检索。

＞内容管理

接线员可以通过目录或索引进行快速的知识定位，将所需的内容通过列表显

示，选择其中一条后即可展开详细的信息。

同时可在该模块进行知识库内容的添加、删除和编辑操作，进行基本维护。

图：内容管理列表

＞检索统计

将用户每次检索进行统计，定期将检索次数进行排序显示，以便用户了解,

对管理员及时掌握哪些内容的检索状况。

Q检实次计

的旧n厂“二速

美”肉户

11用户

33网珠

31四g用户

身船坪用户

起弛用户

3国i湖弼户

的#份9弟网广

A■

1iM踢第Q

3IM睡用户

图：检索统计展示

＞评价管理

为了便于知识库内容更好的管理，对所检索到内容进行等级评价，管理员可

以定期对知识库等级进行统计，对评价不好的内容进行整顿处理。

1.2.2.业务协同分平台

1.221.协同工作子系统

数字化城市管理工作涉及多个机构，虽然数字化城市管理工作取得了很大的

进展和成绩，但还存在职能交叉、管理粗放、被动管理、信息滞后、突击式运动

式管理等问题，越来越不适应现代化的都市环境的建设与发展。

政府目前正在积极推进的信息化工程，其目的就是解决上述城管工作的问题,

全面提升本地区数字化城市管理工作的效率、质量和水平。这其中不但涉及一些

比较关键的网络技术、信息技术、通讯技术、安全技术的应用，更重要的是运用

管理学、系统论、协同学等学科的研究成果，仔细分析数字化城市管理工作的现

状和发展趋势，对数字化城市管理工作的主要业务流程进行优化和再造，以达到

在新的数字化城市管理工作流程下统一指挥、合理分工、协调工作、资源整合、

信息共享的工作环境，形成一支分工协作、信息互通、高效运转的数字化城市管

理队伍。因此，协同工作系统是数字化城市管理新模式的核心，是模块化数字化

城市管理信息化的主线。

D-CLIndi数字化城市管理系统

gitai5System

■।二.一,我的第.*f-傥配■aaiJi

图：协同工作系统待办案卷列表

＞为监督中心、指挥中心、专业部门和各级领导多级岗位的协同办公功能;

＞根据数字化城市管理服务信息的业务流程进行流程设计、快速实现的功

能；

＞将城管案件进行任务派遣、任务处理、处理反馈、核查结案等环节的过

程实现；

＞实现监督中心、指挥中心、专业部门之间信息同步、协同工作和协同督

办功能；

＞提供给其他业务系统各类信息资源共享接口的功能；

＞提供案卷信息分类、查询统计等功能；

1）工作流程设计

在系统工作子系统，城管事件信息将在各个不同的岗位、部门之间进行流转。

整个流转过程的总体视图如下所示:

图：数字城管工作流程设计

其中，监督员对事件信息的处理需要在城管通上完成,属于信息采集子系统;

监督中心的接线员通过对来自公众途径得来的事件的录入，在监督受理子系统中

实现；其他各个节点、各个功能，都在协同工作子系统中完成。

2）GIS地理信息协同（地图）

在系统中，用户可以通过直接进入、案卷地图操作、查看位置图等多种方式

访问地图。

1、地图浏览

＞地图浏览工具

地图浏览工具包括地图放大、缩小、漫游、全图显示、地图刷新等内容。

＞快捷图层和背景图层

系统还提供了快速开关图层的功能，该功能与每个人的权限有关。开关图层

后将该快捷图层所属的图层全部打开或关闭。

系统也提供了背景图层功能，如“影像图”和“地形图”，背景图层之间互

斥显示，可以迅速切换。

＞图层控制

图层控制包含地图图层的是否可见，是否显示标注设置。还可以察看不同图

层对应的图例窗口，使图层强制可见，改变图层的显示样式。

2、地图查询统计和定位

为了能迅速查找或切换到要寻找的某一地图位置，系统提供了多种查询和定

位方式，包括地理编码定位，精确查询和定位、模糊查询和定位等等。

地理编码引擎为城市管理、城市部件管理提供快速有效的地理定位引擎。通

过输入自然语义的地址串，系统会自动匹配标准的地址串，并返回该位置的地理

坐标信息。为城市管理监督指挥中心快速锁定万米单元网格内事件发生地点，输

入任意的地址字符串，可以直接定位到地图的万米单元网格某个位置，或提供地

址所在位置的坐标信息。

系统还提供了多种模糊查询和定位方式，如对所有图层查询，地名查询，道

路查询、部件编号、井盖、社区名称、万米单元等等，用户输入以上提到的任何

信息后即可在查询结果列表中直接定位到相应地名、事部件、单位的位置，实现

地图的快速准确定位，这些查询的方法都是可以通过应用维护子系统定制的。

3、空间统计

统计范围可以通过自画点、线、面或选择点、线、面来定义；统计名称根据

系统配置的统计方法来决定；缓冲区在统计范围的基础上以制定数值作缓冲区。

统计结果将会按照设定好的统计方法给出所圈定范围内的各项统计指标。

4、空间分析

＞距离量算

快速量算图上两点的距离。如建筑物距道路之间的距离等；用户以画连续线

的方式连续量算地图距离，并且可以算出距离的多次累加值。

＞面积量算

圈定图上一定范围，窗口右侧显示量算该范围的面积。（操作类似于距离量

算）在起点处单击，将鼠标拖至第二点处单击，再将鼠标拖至第三点处单击，依

次类推。在终点处单击鼠标右键结束操作，窗口左侧列出了量算结果。

＞缓冲区分析和多边形叠加分析

系统提供完善的缓冲区、多边形叠加分析功能，在空间查询、周边查询、空

间统计中都有空间分析的功能。

5、地图打印

提供用户直接打印当前窗口范围地图的功能。在该窗口中的地图为地图操作

窗口所显示在眼前的地图，您可以浏览、调整地图在打印纸上的位置、地图的显

示比例、页面设置等功能。

3）流程主要环节

＞案卷立案

协同工作监督员友上报问题进行核实正确后，给予立案处理，并将立案意见

填写入该案卷。

＞案卷派遣

指挥中心受理员，在其“待派发”列表中，能看到由监督受理子系统转交的

等待其处理的城管事件列表。打开后可以看到城管事件的详细情况，及其在地图

上的位置、处理历史等等。通过选择相应的责任部门，将该案卷派遣至部门，同

时可以指定处理要求和处理的时限。

图：案卷派遣

＞案卷协调

对于需要多部门优,同处理的事件，指挥中心受理员需要协调各个相关部门，

确定事件的处理方法、协作方式，而后在本系统中填写相关内容。

如果属于无法解决的问题，则需要填写非结案申请单，提交指挥中心领导，

由领导进行决策。

＞结果反馈

各街道和职能部门收到处理要求后，根据各自职能范围和处理程序，在规定

的时间内将事件处理完成，并填写处理结果反馈至指挥中心，同时报送给监督中

心。

＞案卷结案

在监督员对已经处理的事件进行了复核，并确认处理结果有效之后，工单将

出现在监督中心考评称的“己复核”事件列表中，点击链接打开工单后，既可填

写“结案意见”进行结案操作。

＞延期申请

在职能部门处理事件的的过程中，如果对要求处理事件的事件、派发的合理

性等因素由疑问，即可点“申请调整”按钮跳转到申请调整页面。

在“申请调整”页面中，只需要填写“调整申请说明”，并单击“申请”按

钮即可。

如果这是个单职能部门处理事件，由指挥中心派遣员派发，则此工单会移交

给立案员，出现在其待处理列表中。如果是多部门协调事件，由协调员派发，则

此工单会出现在协调的的相应列表中。

派遣员对延期申请的处理功能与“事件派发”基本相同。可以对要求处理该

事件的职能部门、要求处理时间进行调整，并填写调整意见后，再次下发。也可

以根据实际情况，转交协调员进行协调处理。

协调员对延期申请的处理与“事件协调”基本相同。

＞非正常结案申请

参见“事件协调”阶段，指挥中心受理员可以发起非正常结案申请。

经指挥中心其他领导填写“领导意见”之后，该工单即交给受理员，由其进

行“非正常结案”操作。

如果指挥中心领导未同意非正常，使得该城管事件能够得到解决，则该工单

的状态被修改为“协调中”，仍有受理人员进行正常的协调派发工作。

＞非正常结案

经指挥中心领导填写“领导意见”之后，该工单即交给协调员，由其进行“非

正常结案”操作。

在协调员的“待结案”列表中，可以看到这些待非正常结案的工单。

此处的功能和操作和“正常结案”基本相同，协调员人员只需要填写“结案

意见”之后，既可完成非正常结案操作。

完成本操作之后，工单将出现在“非正常结案”列表中。

处理历史

提供城管事件处理过程的详细信息。

amM20H07190Q

图：处理历史

4）主要功能设计

＞案卷处理

•案卷存盘

在问题处理页面，当前坐席人员可以随时进行案卷存盘，下次继续处理的时

候将显示保存时的状态。

•案卷回退

当上一工作阶段批转到本部门的案卷并不属于本阶段的受理范围内，或者案

卷的问题信息表和问题处理表单中有信息不完整的地方，可以将其回退给上一工

作阶段

•案卷作废

对于不属于城市管理系统处理范围或可不处理的城市管理问题，可通过此功

能将案卷作废。

•申请缓办

专业部门因为经办人或者问题的特殊原因，希望可以暂缓办理时，可以向有

权限的人员申请缓办。

＞重复案件甄别

在协同工作系统中，每个角色可能会存在多个人员进行操作，如在派遣员派

遣环节，可能会有多个坐席人员同时在线工作，此时就需要系统将所有待派遣的

案卷进行合理分配，确保每个坐席人员的工作量是均等、不重复的。系统可以针

对目前在线的坐席人员案件的受理情况进行平均分配案卷的功能。同时，也可以

通过后台进行手动分配。

|NHiCS

a龟分釐

任先分配

量人人员■总加皿

2Giio»ieooiwnx小函/cvvCMt/Cftte'ctarUitl

20110»19001wnx1b>03MlIMb

2O1IOKWG3waxibaOItftl1«tU1I«»

今立黑偏i01

2ono9nooe得立第elOI

201I092W03份百»1JO1

20H0KW01份以IibtOlUtti«c<i«A

201IO®2W»份空1tbtOI/cvK«>e/C«s«*sttf<Ii><

2OH0KW033ibtdl/cv«g・AC«ib、3tli"«c<i«a

2OHOK6O05wet11划/c«^u«/Cti«*««Us«v«li•(<>«»

g2＞＜s«IT-ffl1MS

图：任务分配记录

＞案卷督办

系统可以在各个环境进行案卷督办，由督办人填写督办意见后，承办人将能

够查阅所有待督办案件。该案卷处理完毕后，反馈处理意见给督办人。

＞计时管理

在指挥中心派发给各个职能部门处理的时候，指挥中心人员可以设定当前案

卷要求处理完成的时间（精确到分）。由派发时刻起开始计时，若职能部门在要求

的时间内完成案卷的处理则为按期处理完毕；若职能部门在超过限定时间仍未完

成案卷处理，则系统自动判定该案卷处理超期。

所有案卷的按期、超期信息都将体现在综合评价系统中，是对各个职能部门

考评的重要依据。

•计时设置

系统可以对案卷各个环节的处理时间进行设亶的功能。比如对立案、派发、

处理、结案等。

•提醒设置

系统可以进行多种提醒规则。

•案卷计时

系统可以记录案卷各个环节的开始时间。比如对立案、派发、处理、结案等。

•案卷提醒

系统可以对各个环节的待处理案卷消息提醒功能。比如系统内部消息、电子

邮件、彩信或者短信等方式进行提醒。

＞案卷查看

提供多种方式、多种条件供用户对城管事件及其处理情况进行查询。

.累费也询

工■触:二工学的■2442

一.玄弁曲1SX*>5[_____________1

所县V陆M▼北与♦&▼期―-♦*»-V

寰件大食一拿卷务一V一余卷#一.上/M—未通。一*-A-▼

立*开喇向］闻3开蝴口____________

工M划0______________目］•方绢勉羯。率口中内向闻州a则0"

上静开间______■!及•开金，司

____g;■开用制出I日

上足网日___________________□脑埠滑培鬻■etawfl]

IHHf由