天津市数字化城市管理全面方案.doc

天津市数字化城市管理 信息系统项目建设需求 应用软件开发项目部分 V4.2V4.2 天津市数字化城管项目建设办公室天津市数字化城管项目建设办公室 二二九年四月九年四月 目目 录录 1 1项目概述项目概述 4 1.1项目建设目标.5 1.2项目建设原则.5 1.3项目建设范围.6 1.4必需应注意满足的要求.7 2 2项目建设总体需求项目建设总体需求 7 2.1系统构建模式需求.7 2.2系统总体架构需求.8 2.3业务需求.9 2.4业务流程.10 2.5网络说明.12 2.6总体技术要求.13 3 3数字化城市管理信息系统软件平台需求数字化城市管理信息系统软件平台需求 15 3.1应用软件系统总体构架设计.16 3.2数字城管基础模块需求.20 3.2.1监管数据无线采集子系统（城管通）需求20 3.2.2呼叫中心受理子系统需求22 3.2.3协同工作子系统需求23 3.2.4大屏幕监督指挥子系统需求25 3.2.5基础数据资源管理子系统需求26 3.2.6应用维护子系统需求27 3.2.7地理编码子系统需求29 3.2.8数据交换子系统功能需求30 3.2.9综合评价子系统功能需求31 3.3数字城管拓展模块需求.32 3.3.1数字城管拓展模块32 3.3.2数字城管考评模块39 3.3.3接口规范要求49 3.3.4培训要求51 3.4同相关系统软件的兼容.52 4 4数字化城市管理信息系统硬件系统简介数字化城市管理信息系统硬件系统简介 .52 5.5. 数据加工要求数据加工要求52 6 6工程承建单位要求工程承建单位要求53 6.1 责任要求 53 6.2 机构和人员 54 6.3 售后服务 54 6.4 对系统工程承建单位的资质需求 55 特别注明：本项目建设范围仅为应用软件开发及相应地 理信息数据加工。其余硬件、系统软件、中间件及网络介绍均 为软件开发单位参考之用，不在本次项目建设范围内。 1 1 项目概述项目概述 随着经济、社会的高速发展，社会各界对城市品位和城市形象 的要求越来越高，城市管理和执法工作的压力越来越大，但城市管 理的手段和措施相对滞后，现代化的设施相对落后，科技含量不高， 已经制约了城管工作的高效运转。 市容委根据市委、市政府的工作部署，也开始了对数字化城管 考核评价体系的研究，建立“以奖代补”的新型考核模式，颁布了 天津市城市管理考核实施意见（试行） 以及天津市城市管理 “以奖代补”办法（试行） 两个重要文件，以此作为城市管理工作 考核的依据，能够充分调动各部门的工作积极性。 根据只升华副市长在 5 月 14 日城市管理研讨会、5 月 27 日市城 市管理工作会议、8 月 16 日城市管理工作推动会上对数字城市管理 系统建设提出的要求及市市容委领导在 6 月 11 日、7 月 3 日、8 月 22 日由各区主管区长和相关单位参加的会议上就如何落实数字城市 管理建设提出的工作部署，市容委成立了专门的项目建设组，对外 地建设数字城管的经验进行了借鉴与学习，并结合天津市本地情况 初步完成了立项和建设的资料、完成了初审，同时制定了天津市建 设数字化城市管理信息系统的工作计划，完成了项目审批立项工作， 现工程进入最终招、投标阶段。经项目办人员反复修改，结合工程 实际需要，本着对项目负责的精神，经专家多方论证，最终形成本 需求。 1.11.1 项目建设目标项目建设目标 利用信息化、数字化手段，建立数字化城市管理信息系统，推 进城市管理资源优化整合，实现城市部件、事件科学分类，实现管 理流程科学再造，实现城市管理机制创新，形成沟通快捷、分工明 确、责任到位、反映迅速、处置及时、运转高效的城市管理机制； 形成系统统一受理、分级处置、监管分离、综合评价的管理体系。 使城市管理从粗放管理变为集约管理，从单一的定性管理变为定性 定量相结合管理，从被动管理变为主动管理，从封闭管理变为开放 管理，从静态管理变为动态管理，从滞后管理变为实时管理，从部 门管理变为综合管理。 1.21.2 项目建设原则项目建设原则 为了保证城市管理工作与其它相关部门的无缝隙沟通，保证数 字化城市管理信息系统与其它电子政务系统的互联互通，必须坚持 以下几个原则: （1）在系统方案设计中，充分体现开放性要求。并向其它部 门和社会开放，形成与其他部门资源和信息的共享。 （2）在应用系统建设的设备选型、标准采纳、指标设定上， 满足系统运行要求，并要有足够的冗余。 （3）天津市数字化城市管理信息系统涉及到各部门之间的数 据管理和交换，必须要有统一的数据采集规范、数据制作规范、数 据库结构规范和质量标准。 （4）天津市数字化城市管理信息系统要具有较高的安全防护要 求，并且需要接入天津市电子政务网，因此，本系统的设计和项目 建设要符合国家制定的相关保密要求。 1.31.3 项目建设范围项目建设范围 本次软件建设范围应必须满足章节 2.2 中所提出的，中心城 区“集中式”及滨海新区“小集中+分布式”的两种架构所涉及的， 覆盖天津市 16 个区、县及功能区的数字城管平台的部署。 本次项目建设基于电子地图技术的符合国家相关行业标准的， 天津市市级网格化城市管理信息平台，建设以数字城管核心业务功 能、数字城管拓展业务功能、数字执法业务功能、电子地图应用功 能、 “城管通”应用、 “考评通”应用、 “执法通”应用、 “指挥通” 应用、市级平台呼叫中心热线等为主要内容的数字化城市管理信息 系统。规范基础信息采集、综合信息受理、部门协同办理、城管热 线等在线业务流程，实现信息双向互动。 从管理制度、软硬件环境等方面采取综合防范措施，保障信息 平台、基础数据和信息内容的整体安全。 组织对系统运行维护专业技术人员、市、区相关职能部门值班 员、信息采集员、市、区管理监督中心、指挥中心管理人员、接线 人员、派遣员、以及城管执法队员进行相关知识培训。 1.41.4 必需应注意满足的要求必需应注意满足的要求 1、本期项目天津市数字化城管信息系统为“集中式”架构系统， 软件必须按“集中式”进行设计，各区级数字化城管平台通过电子 政务网访问系统，共享数据库及应用。软件开发应保障硬件上不单 独设立针对各区级平台服务器，不设立对区级服务器的分发服务器 设备。 2、本项目为交钥匙工程，本项目中标单位即应用软件开发中标 单位为天津市数字化城管信息系统全部项目建设的主体单位，应对 天津市数字化城市管理系统建设所涉及的全部相关工作负总责。 3、需求中涉及的全部软件均应提供原版光碟介质，应有正版授 权及相应的服务。 4、建设单位主要参建人员应为本公司人员，在工程进行期间保 障主要技术人员不得更换，保障三分之二以上工程建设人员不得更 换。投标书内应提供整个项目组的人员名单，并在现场出具该人员 本单位员工的证明（原件） 。 5、需求中凡带“”号的及特别注明的项目为必须响应的项目。 2 2 项目建设总体需求项目建设总体需求 2.12.1 系统构建模式需求系统构建模式需求 天津市数字化城市管理平台建设模式为“两级监督、一级指挥” 。 市级建设数字化城市管理监督平台，区级建设数字化城市管理监督 和指挥平台（区级数字化城市管理监督中心和指挥中心由各区自行 建设，不含在本项目建设范围内） 。 市级平台负责全市城市管理的监督、考核和评价，市监督管理 中心通过市级呼叫平台受理来自领导交办、城管热线及网上举报的 城管信息，并将信息转发至相关区级监督中心进行立案处理，在处 理过程中市级平台同步监督跟踪；对于跨区或跨部门区级监督指挥 中心难以解决的问题，可由区指挥中心提请市监督管理中心进行协 调督办。经过督办延期的案卷信息将作为考核评价相关专业部门依 据之一。 区级平台负责受理区属范围内的部件、事件的处理。业务流程 分为信息采集、案卷建立、任务派遣、案件处理、结果反馈、核查 结案、综合评价等七个环节。 2.22.2 系统总体架构需求系统总体架构需求 市内六区、环城四区建成区及新技术产业园区采用“集中式集中式” 架构，在市级平台建立统一共享的软硬件平台。上述各区通过市电 子政务网络集中共享调用相关数据，实现市、区两级网络互联互通。 滨海新区采用“小集中分布式小集中分布式”的架构，依托经济技术开发 区已经建成的“天津经济技术开发区数字化城市管理平台”拓展建 设“滨海新区数字化城市管理平台” ；塘沽区、汉沽区、大港区、开 发区、保税区采取“小集中”方式统一调用共享滨海新区系统平台 的相关数据。滨海新区系统平台与市级平台采用“分布式”架构， 依托市电子政务网络，实现市级平台与滨海新区平台市区两级网络 的互联互通。 武清区、宝坻区、静海县、宁河县、蓟县等区县采用“分布式分布式” 架构，各自建设独立的软硬件系统平台，独立运行。通过市电子政 务网络与市级平台进行数据交换、信息传递、协同工作，互通互联。 2.32.3 业务需求业务需求 数字化城市管理工作涉及到几个环节：信息的收集环节、案卷 建立环节、任务派遣环节、任务处理环节、处理反馈环节、核查结 案环节。针对这几个环节， “数字化城市管理系统”需要设计开发的 子系统包括：GIS 地理信息子系统、GPS 定位管理子系统、移动执法 子系统、业务短信子系统等。同时为配合上述子系统功能的实现， 需要以下硬件方面支持，如：需要配备城管人员的多种无线手持设 备、中心服务器设备等。 数字化城市管理涉及多条块业务流程，如何和各关联单位联动 是“数字化城市管理信息系统”需要考虑的重要内容，需要建立信 息整合、条块联动的雏形。为此，系统中需要解决各个部门之间协 同工作的问题。 综合评价方面，需要考虑各个事部件状态及案件处理情况，建 立一套科学的评价体系。对综合评价功能的设计要考虑到全面、客 观，同时要辅助一定的表现形式，真正起到监督、约束的功能。 指挥决策方面，需要考虑提炼关键数据，反映整个体系的工作 状态、重点事件的处理情况、评价体系的指标参数等，为领导决策 提供有力支持。在系统设计时，要考虑到领导在市级监督管理中心 现场指挥，以及领导移动指挥的应用需求。 2.42.4 业务流程业务流程 城市管理流程是在“两个轴心”管理体系下的具体办事流程， 这一流程的主要参与者是信息采集员、监督中心（接线员） 、指挥中 心（派遣员）和专业部门（包括街道、社区等） 。流程的业务阶段可 划分为以下六个阶段：信息收集阶段、案卷建立阶段、任务派遣阶 段、任务处理反馈阶段、案件核查、案件结案阶段。 1 1、问题发现及信息收集、问题发现及信息收集 按反映渠道将发现的问题分为两大类，一类是由信息采集员主 动巡查、发现的部件、事件问题；另外一类是公众举报热线和领导 批件转来的有关部件、事件问题。这两类问题的案件受理和立案阶 段的处理流程有所不同。对于信息采集员上报的问题，值班长经过 判断后可直接进行立案；对于公众举报的问题，首先需要现场信息 采集员进行核实操作，值班长根据信息采集员反馈的现场情况决定 是否立案。 2 2、案件建立、案件建立 信息采集员发现的问题通过信息采集终端（“城管通” ）上报至 区级监督中心，由区级监督中心接线员进行登记、综合判别并受理。 公众举报热线反映的问题和领导批件转来的有关部件、事件问 题由区监督中心接线员统一接收，并对这类问题进行登记受理。 3 3、任务派遣、任务派遣 区级监督中心的值班长按照指挥手册的要求，分别对已登 记受理问题进行综合判别后立案，对于一般性案件生成工作表单， 并将工作表单派送到监管单位和承办单位；如遇特殊案件按管理权 限报批。 4 4、任务处理及反馈、任务处理及反馈 监督、管理单位根据指挥手册的要求负责对案件的处理过 程进行督促和管理。 各城市管理承办部门负责对监督中心派遣的城市管理事、部件 问题进行处理，并在问题处理完毕后，将处理结果及时地反馈到区 监督中心。 5 5、案件核查、案件核查 区监督中心在接到承办单位问题处置完毕的反馈信息，应及时 指派信息采集员进行现场核查。 6 6、案件结案、案件结案 在收到信息采集员转发的核查信息后，根据实际情况，区监督 中心对于已经处置完毕的案件，由值班长进行结案处理，并将处理 结果反馈至相应的监管单位；对于没有处置完毕的案件，值班长将 会对案件进行重新指派。 详细流程图如下图所示： 2.52.5 网络网络说明说明 系统用到的网络环境主要包括业务网络、无线网络两部分，其 中业务网络依托天津市政务专网建设，建设城市管理监督中心（市 级） 、各区监督指挥中心、 （市、区）二级城市管理相关部门间的网 络互联。无线网络需单独建设，采用专线接入市数字化城市管理中 心。 2.62.6 总体技术要求总体技术要求 1 1、容量需求：、容量需求： 支持同时 1500 人在线访问查询能力； 存储设备容量不低于 6TB； 2 2、响应速度、响应速度 地图位置查询和定位时间不超过 5s； 监督中心接收监督员上报问题时间不超过 30 s； 监督中心向监督员发送任务时间不超过 10 s。 3 3、其他需求、其他需求 （1）易用性： 提供快速、便捷的输入方式，界面简单易用，菜单安排合理，符 合使用习惯，灵活方便的查询方式。 （2）安全性： 主要从以下几方面保证系统的安全（包括但不限于） 。 系统安全：操作系统安全(漏洞扫描和修补、用户操作权限控制、 病毒和木马等攻击防范)。 网络安全：网络防病毒、防攻击、不同业务和区域的数据隔离、 监控和报警； 数据备份与恢复：信息安全（完善安全的备份归档机制，可靠高 效的恢复机制） 数据库安全：数据库具备用户认证、基于角色或用户组、数据视 图的访问控制功能，并支持关键信息加密。 应用软件安全：提供完善的安全控制机制，包括基于角色的用户 名/口令的验证机制；用户的访问权限控制；对于用户的访问进行日 志记录；数据库操作保证数据的一致性、正确性。 （3）可维护性： 统一的数据维护模式，管理员能够对数据字典、用户信息、统计 参数等信息进行维护，系统部署在服务器端，通过服务器端的升级 实现客户应用升级。数据库系统可以进行远程数据维护。 （4）可伸缩性： 有弹性的整体业务构架，可方便的增加和裁剪。高弹性的网络构 架，根据实际应用的开展，可便捷的扩展或收缩，不需对原有构架 做重大调整。 （5）高可用性： 主干网络和中心机房等关键节点尽可能避免单点故障，实现冗余 架构。网络业务传输上通过 QoS 等机制保证主业务的响应速度，避 免整个网络的拥塞。 3 3 数字化城市管理信息系统软件平台需求数字化城市管理信息系统软件平台需求 数字化城管业务软件系统需能够支持市、区、街道三级指挥派 遣和多部门同时派遣功能，能够最大限度地符合天津市数字化城市 管理的需要，业务功能方面主要应包括以下几个部分：标准功能模标准功能模 块：块：无线数据采集功能、呼叫中心受理功能、协同工作功能、地理 编码功能、监督指挥功能、综合评价考核功能、数字城管业务维护 功能、基础数据资源管理功能、数据交换功能；拓展功能模块：拓展功能模块：考 评采集功能、领导督办功能、业务短信功能、GPS 车辆定位功能、 综合分析功能；执法业务模块（已招标，不在本期建设范围内）执法业务模块（已招标，不在本期建设范围内）系 统还需要具有电子地图应用功能、系统运维管理平台功能，门户网 站功能、以及与外部系统的接口功能。 对于标准功能模块，软件开发商应严格按照国家相关行业标 准以及天津市“两级监督、一级指挥”的业务模式进行开发，拓展 功能模块部分在开发以及试运行过程中，开发商应按甲方的需求进 行随时调整。 应用软件系统的总体性能需求如下： 1、应具有海量数据存储和管理能力，支持 500G 以上的总数据 量及 150G 以上的空间数据量的存储和管理。 2、应具有良好的并发响应能力，整体响应性能在 5s 以内，正 常情况下并发访问量应不小于 500。 3、应具有较强的稳定性，在 6000 个用户并发访问时，系统仍 能稳定运行。 4、应具有完备的信息安全体系，能对登录用户的身份进行认证， 并跟踪用户的操作，进行安全审计。 5、应具有良好的数据安全保障机制，对数据采取集中管理和存 储的模式，数据库结构设计良好，具有迅速的数据检索能力。 6、应具有较强的容错能力和灾难恢复能力，服务器组采用集群 模式。 7、应具有高度的灵活性，能适应日常业务变更的需求。 8、地图查询定位时间不超过 5s，呼叫中心接收信息采集员上 报问题时间不超过 30s，呼叫中心向信息采集员发送任务时间不超 过 10s。 9、要按照天津市数字城管和数字执法业务特色进行软件开发。 10、应用软件必须满足操作系统、数据库、地理信息系统、 中间件等平台软件及硬件升级后的正常使用。 3.13.1 应用软件系统总体构架设计应用软件系统总体构架设计 应用软件系统总体架构设计如图所示： 应用软件系统的总体需求如下： 1) 软件系统采用国际、国家标准的软件开发、软件测试及验收 过程模式，遵循 J2EE 规范开发系统，能提供完整的项目开发、测试 过程记录和文档。 2) 承建单位必须建立并实施完整的软件工程质量保障体系，具 有专职的软件测试组织、人员、工具；并且在项目中强有力的开展 测试工作。 3) 应具有海量数据存储和管理能力，支持存储设备容量的平滑 升级。 4) 应具有良好的并发响应能力，整体响应性能在 5 秒以内，能 满足今后天津市数字城管系统的整体应用需求。 5) 应具有较强的稳定性，MTBF 大于 20000 小时。 6) 应具有完备的信息安全体系，达到国家电子政务系统的安全 性标准要求。 7) 应具有良好的数据安全保障机制，对数据采取集中管理和存 储的模式，数据库结构设计良好，具有迅速的数据检索能力。 8) 文本信息交换的响应时间应控制在 1 秒以内，采用消息中间 件对数据交换进行管理。图片、声音信息交换响应时间控制在 10 秒 以内。 9) 应具有高度的灵活性，能适应日常业务变更的需求，实现 “零代码”方式的系统管理和维护。 10) 地图查询定位时间不超过 5 秒，呼叫中心接收信息采集员 上报问题时间不超过 30 秒，呼叫中心向信息采集员发送任务时间不 超过 10 秒。 11) 系统必须能提供标准化的接口，能提供数字城管系统与其 他电子政务系统的接口。 12) 系统响应速度在非硬件系统问题的情况下，数据量对软件 系统响应速度的速率影响不超过 20%。 13) 软件系统能满足设计的各类国际、国家标准要求。 系统设计标准体系系统设计标准体系 数字城管系统是城市信息化的一个关键部分，要在遵循建设部 相关建设、技术标准的基础上结合天津市的市情建设天津市城管系 统。 建设部相关国家标准： GB/T2260 中华人民共和国行政区划编码 GB/T7929 1：500、1：1000、1：2000 地形图图式 GB 11714 全国组织机构代码编制规则 CJJ100 城市基础地理信息系统技术规范 GB 17733.1 地名标牌 GB/T 18521 地名分类与类别代码编制规则 GBT10114 县以下行政区划代码编码规则 CJJ 103 城市地理空间框架数据标准 CJ/T 213-2005 城市市政综合监管信息系统单元网格划分与编 码规则 CJ/T 214-2007 城市市政综合监管信息系统管理部件和事件分 类、编码及数据要求 CJ/T 215-2005 城市市政综合监管信息系统地理编码 CJJ/T106-2005 城市市政综合监管信息系统建设规范 相关城市部件、事件的分类在建设部编码标准的基础上，结合 天津市的城市特点，完善并不断充实，具备适应今后其它相关系统 的建设标准。 系统功能系统功能 根据建设部相关行业标准和技术规范的要求，天津市数字化城管系统主要 应包括以下几个部分的内容： 数字城管基础模块：无线数据采集子系统、呼叫中心受理子系统、协同工 作子系统、数据交换子系统、地理编码子系统、大屏幕监督指挥子系统、综合 评价子系统、构建与维护子系统、基础数据资源管理子系统； 数字城管拓展模块：领导移动督办子系统、视频监控子系统、业务短信子 系统、环卫车辆定位子系统、综合分析子系统； 数字城管考评模块：考评采集子系统、考评任务管理子系统、离线考评子 系统、考评结果发布子系统； 系统与外部数据的接口。 3.23.2 数字城管基础模块需求数字城管基础模块需求 3.2.13.2.1监管数据无线采集子系统（城管通）监管数据无线采集子系统（城管通）需求需求 监管数据无线采集子系统手持终端提供给城市管理信息员使用， 主要用于实现信息员在自己的管理范围内巡查过程中向中心上报城 市管理问题信息，接受中心的任务指令并反馈。该系统依托移动设 备，采用无线网络传输技术，通过城市部件和事件分类编码体系、 地理编码体系，完成城市管理问题文本、图像、声音和位置信息实 时传递。 无线数据采集子系统由无线数据采集终端软件和无线数据采集服 务端软件两个部分组成。 终端软件功能需求终端软件功能需求 无线数据采集终端软件应实现的主要功能包括： 1) 无线传输功能，利用无线网向监督中心报告城市管理的现场 相关信息； 2) 能接收并回复监督中心发出的问题任务指令； 3) 记录最近上报的问题和任务信息，并标记报送状态； 4) 基础信息、单元网格信息和部件信息等地图显示、查询和标 注； 5) 基础信息、单元网格信息和部件信息等地图数据自动同步； 6) 用户安全管理和考勤管理的能力； 7) 能够利用无线通信网或定位导航系统进行位置定位，能够监 控到城管监督信息员所在位置； 8) 城管通终端手机能够利用无线通信网进行话音通信，数据通 信，短消息通信。 服务端功能需求服务端功能需求 无线采集子系统服务器端实现手机上报问题的接收，实现手机 和呼叫中心受理平台的数据交换，无线采集子系统服务器端软件应 具备的功能包括： 1) 为无线数据采集系统提供各种信息查询服务的支撑； 2) 为无线数据采集系统提供地理编码查询服务； 3) 为无线数据采集系统提供数据同步服务； 4) 为无线数据采集系统提供无线定位服务； 5) 为无线数据采集系统提供数据协同管理和交换服务； 6) 为无线数据采集系统提供通知服务； 使用对象使用对象 该子系统主要提供给城市管理信息员使用，采用 windows 智能 手机，通过无线传输方式，实现业务表单、问题照片的传输；通过 手机 GPS 模块，实现卫星定位功能。 3.2.23.2.2呼叫中心受理子系统需求呼叫中心受理子系统需求 呼叫中心是城市管理监督中心下设的联系内外各部门和社会公 众的窗口。呼叫中心的主要工作是受理来自城市管理监督员和社会 公众的城市管理问题，然后对问题进行审核，记录问题发生位置， 立案后传递给指挥中心。因此，呼叫中心受理子系统的主要功能就 是为呼叫中心接线员提供问题受理、登记、立案、定位和转发等功 能。 呼叫中心受理城市管理问题主要分为两种：社会公众举报和信 息员上报。 系统主要功能需求：系统主要功能需求： 1）业务受理 对于监督员上报的城市管理问题，实现自动受理，并且能根据 城管监督员上报城市管理问题信息中包含的坐标信息，在地图中自 动标识出问题发生位置；对于社会公众举报的问题，能通过手工登 记的问题位置描述，在地图上搜索并定位到问题发生位置。 2）查询定位 为了辅助接线员快速定位，应当具备基础地理信息、地理编码 信息、单元网格信息和部件信息等地图显示、查询功能；能够根据 用户输入的地理信息数据进行模糊查询，可以根据用户的选择自动 定位到地图上。 3）立案及案卷审批 应实现立案管理，对符合条件的案卷给予立案处理，生成案卷 编号等信息；提供立案意见录入表单，能够将案卷信息转发到协同 工作子系统；对于不符合相关规定的案卷销案处理，提供表单供录 入销案相关信息。 4）具备与城管监督员的交互功能 应实现向城管监督员发送核实、核查消息；并且可以接收城管 监督员核实消息反馈、核查信息功能。 5）具备新问题或任务反馈信息实时提示功能 当有新问题上报或任务反馈信息时，可以通过弹出对话框提示， 语音提示等方式实现提醒功能。 6）结案归档管理 应完成对案卷的备案处理；生成综合考评所需的相关数据。 3.2.33.2.3协协同工作子系统同工作子系统需求需求 协同工作子系统实现数字化城市管理办公自动化，图、文、表、 业务管理一体化，实现基于工作流的监督中心、指挥中心、各专业 部门之间协同工作，具有良好的自适应性、良好的可扩展性和免维 护性。 系系统主要功能需求：统主要功能需求： 1）任务分派管理 应能根据案卷信息和相关事件、部件的归属部门自动识别相应 的处理部门，并交由相应权限的人员进行任务的派遣。采取市区两 级协同办理模式，对于责任单位明确的案卷直接转发到专业部门进 行处理。 2）处理部门协同监督 能够将处理结果的审核信息发送给相关专业部门；对专业部门 的处理情况进行监督，对超过指定处理期限的案件发送催办通知。 3）案卷督办管理 应提供案卷的全程追踪功能，对案卷进行督办，提供表单允许 有权限的用户录入督办信息；督办信息能够以实时消息、短信、 Email 等方式通知当前经办人员；并对案卷进行特殊符号显示。 4）记时管理 能够对案卷处理的每个阶段以及任务派遣响应及处理情况进行 记时处理，详细记录案卷办理每个阶段的处理时间；根据不同部门 和区域定制的处理时限，对超过期限的案卷或任务自动进行催办通 知，并对超期案卷报警。 5）案件查询、统计 具备案卷查询功能，用户可以自己设定查询条件对案卷进行查 询或统计；查询类型和统计应可以扩充，根据用户需要由管理员进 行维护。 6）地图操作 基础信息、地理编码信息、单元网格信息、部件信息、问题信 息等地图显示、查询、量算等功能； 3.2.43.2.4大屏幕监督指挥子系统需求大屏幕监督指挥子系统需求 结合城市管理应用要求，大屏幕监督指挥子系统的显示区域分 为三个部分，具体包括地图显示区、案卷滚动信息区和详细信息显 示区。其中地图信息区主要显示全区域整体地图，具体包括行政区 划图、单元网格图、部件分布图、城市管理事件分布图、城管监督 员位置分布图和当前办理的城市管理事件处理情况和评价信息。案 卷滚动信息区能够实时统计反映管理区域内所有网格在办案卷数； 滚动显示正在办理的每个案卷基本信息；详细信息区是指具体到单 个问题案卷、具体人员的详细信息，包括信息员详细信息、单个案 卷详细信息等。 大屏幕监督指挥子系统的软件支撑部分由三部分组成，具体包 括系统管理模块、通讯管理模块和显示控制模块等三部分。系统管 理是系统的控制台，负责对大屏幕显示的内容及相关操作进行控制。 通讯管理模块是负责系统管理模块和显示控制模块之间数据和命令 进行通讯，目的是将控制台发出的命令提交给显示控制模块。显示 控制模块是大屏幕监督指挥系统的显示终端，它最终将按照控制台 的要求将需要显示的内容显示到大屏幕上。 系统主要功能需求：系统主要功能需求： 1）具备案卷信息和地图信息一体化管理功能，并满足大屏幕管 理显示要求； 2）能够定位城市管理问题的地理位置，能够分类显示城市管理 问题的当前状态信息； 3）能够实时显示信息员在岗情况及位置信息，并且可以对历史 轨迹进行回放； 4）具有查询信息员详细信息的功能； 5）具有查询城市管理问题的图片、办理过程等详细信息功能； 6）实现地图与属性信息的互动查询； 7）实现图文一体化的综合评价结果大屏幕展示功能。 3.2.53.2.5基础数据资源管理子系统需求基础数据资源管理子系统需求 基础数据资源管理子系统可以管理地理信息所需的地图数据， 图层分类、图层样式及其所包含的各种地物要素。系统可提供缺省 的适应城市管理需求的地图专题和图层样式，用户也可根据自己的 需要进行定制和扩充。 功能设计功能设计 使用基础数据资源管理子系统可以修改地图专题和图层样式， 避免了使用数据库系统本身工具进行系统维护，极大地提高了效率。 系统管理人员无需了解系统数据库的具体结构和实现，就可以正确 地使用基础数据管理子系统进行日常维护和系统数据扩展。 系统主要功能需求：系统主要功能需求： 1）符号库定义 实现城市管理中相关地图要素的符号样式的定义，主要包括地 形图符号库、城市部件符号库等。 2）图层管理 应实现添加、管理地图数据功能，可以对基础数据、地理编码数据、城市 部件数据等进行添加、删除。 3）地图属性定义 应具备对各个图层属性配置功能，实现对属性字段自定义。 4）显示样式定义 能够维护地图库中包括城市管理部件和事件等要素在内的要素 编码、显示样式，可以定制图层的显示颜色、性状等。 5）地图预览 地图管理中应提供地图预览功能，能够快速查看地图配置效果。 6）快捷图层 能够配置基于单元网格和城市部件地图快捷操作图层。将用户 经常用到的图层进行统计归类，方便用户对地图操作。 3.2.63.2.6应用维护子系统需求应用维护子系统需求 应用维护子系统是系统管理员使用的工作平台，通过该平台， 可以快速搭建、维护城市管理业务，定制业务工作流程，设置组织 机构，并能够方便快捷地完成工作表单内容样式调整、业务流程修 改、人员权限变动、系统数据备份等日常维护工作。该子系统可以 方便地调整，使之适应用户需要，并可以在使用中不断地变更系统 配置，实现用户自维护、自发展、自适应。 系统主要功能需求：系统主要功能需求： 1) 组织机构管理 应实现数字化城市管理系统人员信息的管理，包括人员、部门、 岗位等资料的管理；可以灵活配置人员的查询、统计、地图操作等 权限的管理。 2) 工作流定义功能 应实现工作流过程、阶段、流向中对表单、地图等对应操作的 配置和管理，以适应业务管理过程中工作流程、参与专业部门、问 题管理职责等方面的变化； 具备可视化工具实现工作流的绘制功能； 支持工作流程的并行处理、回退、授权操作等。 3) 工作表单定义功能 应实现工作表单名称、字段、样式等编辑和管理，以适应业务 过程中工作表单的变化要求； 4) 定义统计和查询功能 统计和查询，应具有良好的可扩充性，可以根据用户的需要对 各类统计报表的内容、样式进行编辑和管理； 5) 时限管理 具备不同城市管理部件和事件处理时限的配置管理功能，时限 管理可根据用户的需要定制。 6）人员权限模块 应用维护平台采用分级权限的控制方法，每个业务人员的权限由 该人员所属的部门、所具有的角色一起来确定，为方便系统管理人 员对人员权限的方面管理，特提供专门的人员权限管理功能模块。 通过该模块，可查看系统中所有业务人员所具有的非空间/空间数据 的操作权限，以及该权限的获得来源。 7）城市部件与事件管理 应提供一个便捷的、人性化的操作平台。通过该模块，管理人 员可以对城市部件与事件类型以及事部件对应的责任单位进行增、 删和修改等一系列操作。 3.2.73.2.7地地理编码子系统理编码子系统需求需求 地理编码子系统是数字城管应用的支撑系统，可以将城市现有 的地址进行空间化、数字化和规范化，在地址名称与地址实际空间 位置之间建立起对应关系，实现地址空间的相对定位，可以使城市 中的各种数据资源通过地址信息反映到空间位置上来，提高空间信 息的可读性，在各种空间范围行政区内达到信息的整合。提供了一 种把具有地理位置的信息资源赋予地理坐标，进而可以为计算机提 供计算的方式。通过地理编码技术对城市部件进行分类分项管理， 最终实现城市管理由粗放到精细，由人工管理到信息管理的转变。 系统主要功能需求：系统主要功能需求： 1) 地址串规范化处理 根据用户输入的地址字符串，按照地理编码规则库中的配置， 进行地址串规范化处理。 2) 地理编码检索 地理编码引擎将规划过的地址串进行拆分，通过地理编码索引 库找到一个最匹配的地理编码索引号。 3) 地理编码信息获取 地理编码引擎根据地理编码索引号，在地理编码库中定位到地 理编码，获取地理编码信息。 4) 基础数据信息获取 地理编码信息中包含基础数据库的指向信息。地理编码引擎可 以根据指向信息，通过地图服务引擎在基础数据库中查找该地理编 码所处图层，所对应位置，并生成相应的位置图。 地理编码子系统在地理编码引擎的支撑下，应为用户提供根据 地址串生成位置（包括坐标信息和位置图） 、根据部件号查询位置、 根据位置查询地址串、获得地址串的标准地址等功能。 3.2.83.2.8数据交换子系统功能需求数据交换子系统功能需求 数据交换子系统应实现与上一级数字化城市管理信息系统的数 据交换，交换信息可包括问题信息、业务办理信息、综合评价信息 等。 本系统采用业界成熟的 XML、SOAP、WebService 等信息技术建 立信息交换平台，包括数据交换引擎、远程数据传输、信息交换标 准等核心模块. 随着 XML 的迅速发展，XML 正在逐步成为 Internet 中描述数据 的标准。在将来 XML 文档势必成为数字城管项目中数据传输的主要 载体。 系统主要功能需求：系统主要功能需求： 1) 市区两级平台数据交换 数据交换内容包括案卷数据、综合评价数据和地理信息数据等。 2) 数字城管与视频平台数据交换 数据交换内容包括视频接口控制信息、视频流媒体信息等。 3) 数字城管与无线数据交换 交换内容包括无线分组传输数据以及 GPS 数据。 4) 数字城管与执法平台数据交换 交换内容包括案卷数据、地理信息数据、评价数据以及状态数 据。 3.2.93.2.9综综合评价子系统合评价子系统功能需求功能需求 综合评价子系统通过一整套科学完善的监督评价体系，对城市 管理的各方面进行考核评价。天津市数字化城市管理系统中的综合 评价子系统在标准系统基础上，根据天津市的管理要求，扩展了城 市管理考评体系。因此，子系统包括的两个部分。一是基于信息员 上报信息的基本评价部分；二是基于考评员考评信息的长效机制考 评部分； 基本评价部分：基本评价部分： 1）区域评价 以单元网格、社区、相关街道、行政区等区域为划分标准，按 不同周期统计各单元区域的评价分值，生成评价结果，并在地图中 直观显示； 2）部门评价 对专业部门和各级责任主体，按一定周期统计各部门的评价分 值，生成评价结果，并直观显示； 3）岗位评价 对监督中心、指挥中心各岗位和城管信息员进行岗位评价，按 一定周期统计各岗位的评价分值，生成评价结果，并直观显示。 长效机制考评部分：长效机制考评部分： 根据天津市考评标准要求，考评办对考评对象按照一定周期组 织巡查、抽查、联查和社会监督，形成考评结果并对外公布。 3.33.3 数字城管拓展模块需求数字城管拓展模块需求 3.3.13.3.1数字城管拓展模块数字城管拓展模块 3.3.1.13.3.1.1视频监控子系统视频监控子系统 本项目仅涉及视频监控系统本项目仅涉及视频监控系统应用软件应用软件建设。建设。 视频监控系统是指将日后计划从市公安技防网中整合的多路视 频监控信号以及数字化城管将要建设的视频信号，结合城市管理地 理信息系统，在城市管理信息中心的大屏幕和 PC 终端上显示，实现 对城市部件和事件的全方位、全时段的可视化监控管理，从而对城 管事件作出准确判断并及时响应，对监控范围内的突发性城管事件 录像取证，起到综合治理效果。视频监控系统可以随时选择需要监 控的 8 路视频监控信号。 视频监控系统建设主要包括两部分的内容，即公安视频监控信 号接入系统的建设和城管监控系统的建设。具体要求如下： 1）公安技防网视频监控信号整合系统建设 本期项目暂不接入公安视频监控信号，但应预留必要的接口。 系统计划实现日后将整合的公安多路 DVR 制式模拟视频信号进 行电信号到光信号的转换、模拟到数字信号转换，通过图像的处理、 控制和切换，结合城市管理地理信息系统，在城市管理监督中心的 大屏幕上显示，实现对城市部件和事件的全方位、全时段的可视化 监控管理，从而对城管事件作出准确判断并及时响应，对监控范围 内的突发性城管事件及时发现，起到综合治理效果。由于无须对接 入的公安视频监控信号进行存档、回放、备份，故不采用硬盘录像 的方式。 2）数字化城管监控系统建设 项目将根据天津市建设全市城管监控系统的要求，建设视频监 控探头（不在本项目建设范围） ，通过传输通道，汇集到监督中心机 房，并通过大屏幕展现出来。 视频监控系统是城市管理监督中心了解全市市政、环卫、环保、 交通、治安状况的窗口，是数字化城市管理系统的一个重要组成部 分，建立视频图像监控系统的目的是及时准确地掌握所监视的重点 污染源、路口、路段周围的市政、环卫、交通、治安、网吧、施工 场地、集贸市场等情况，为指挥人员提供迅速直观的信息从而对城 管事件做出准确判断并及时响应，对监控范围内的突发性城市管理 事件录像取证，起到综合治理效果。 系统主要功能需求： 1）视频选择功能，提供三种选择模式： 在地图上添加视频摄像头分布图层，在系统的电子地图上选择 需要调用查看的视频源，针对当前现有的监控视频头，点击监控图 层的摄像头图标时，就播放该视频头对应的视频影像； 根据属性信息选择视频源，城管系统获取并显示每个视频源的 名称、编号、所在位置等属性信息，操作员根据这些信息确定要察 看的 视频信息； 根据案卷的发生位置选择视频源；操作员首先在地图上定位案 卷，然后选择案卷周围的视频源，察看现场的实时信息。 2）视频播放功能，视频播放软件选用通用程序，满足现有的视 频数据压缩格式和将来压缩格式的需要。视频可以在监督中心的大 屏幕和 PC 终端上显示。 3）视频立案功能，系统将抓怕现场图像，进行立案。在视频监 控设备的支持下，在立案的同时系统自动记录探头的拍摄位置，以 便视频立案的问题处置完成后借助同角度的视频画面进行核实、核 查。 4）视频核实功能，借助视频进行问题的核实一方面可以实时对 问题进行核实，并对事发过程进行跟踪。 5）视频核查，需要视频核查的案卷，接线员选择案卷问题位置 附近的视频资源，对现场进行核查。 6）查询统计功能，提供视频立案案件的上报数、立案数、按期 结案率、超期结案率等指标的统计，生成周报表、月报表。 3.3.1.23.3.1.2 指挥移动督办子系统指挥移动督办子系统 天津市“大城管”的格局要求各部门高效运作、全民积极参与、 领导高度关注，为了保证城市管理中存在的重点难点问题、超时处 理问题能够得到及时的解决，因此本子系统设计主要满足领导移动 办公、随时办公、全面关注城市管理状况的需求。 使用移动督办系统，领导可以直接查阅问题的表单信息和多媒 体信息等，并可以通过发送消息指示或拨打电话，对城市管理问题 进行批示。移动督办子系统还可以接受城市管理问题的统计信息， 通过统计信息的查看，领导可以全面了解城市管理问题状况、各区 域、各专业部门处理问题的情况等宏观信息。为领导决策提供实时 依据。 系统主要功能需求： 急要件 对于城市管理当中出现的突发、重大事件（领导关心的事件） ， 定义为急要件。领导可以查看某条急要件案卷的详细信息和办理过 程，对于问题严重的可以填写督办信息，并发送到相关处置部门。 超时件 数字化城市管理中对各部门处理问题的时限进行了限定。各部 门处理的严重超过时限的案卷（超时时间可设定） ，会进入领导的 “督办”列表中。领导可以查看某条案卷的详细信息和办理过程， 对于问题严重的，可以填写督办信息，并发送到相关处置部门。 单键拨号 点击主界面的【单键拨号】图标，可以直接拨打在系统中设置 好的号码。通过单键拨号功能，领导可以对自己发现的问题或者特 别关注的城市管理问题下达口头指令。 特别关注 主要用于从多个角度展示城市管理宏观统计、评价信息。给领 导决策提供一定的量化依据。需要实现不同级别领导的权限不同， 查看的特别关注内容也不尽相同。 3.3.1.33.3.1.3 业务短信子系统业务短信子系统 业务短信子系统是数字化城市管理系统在无线网络上的延伸， 通过业务短信功能与协同办公系统的紧密结合，可以进一步保障数 字化城市管理系统参与人员之间的消息畅通，同时也解决了操作人 员不在电脑旁边，不能立刻获知已经到达的城市管理案卷的问题， 从而提高城市管理问题的处置效率。 系统主要功能需求： 1）案卷到达提醒 当指挥中心将案卷批转至专业部门时，在向专业部门派遣案卷 的同时，会以手机短信的方式向专业部门人员发送一条案卷到达的 提示。这个功能是通过系统设定自动实现的。 2）催办短信 领导和综合部门可对城市管理问题（特殊问题、重大问题、超 时问题）发催办消息。发送催办信息的同时发送手机催办短信。 3）超时提醒 专业部门处理的案卷，超出办理时限后系统会自动亮红灯以示 警告，同时自动向专业部门人员手机发送一条案卷超时的提醒。 4）群发短信功能 群发短信功能，主要是为了方便对专业部门人员和信息员进行 统一管理。相对于以前的文字通知或者电话通知，群发短信功能可 以更快速方便的将重要信息通报所有专业部门人员和信息员。 3.3.1.43.3.1.4 车辆车辆 GPSGPS 定位子系统定位子系统 本系统应依靠平台的 GIS 系统及相关硬件及网络设备，搭建 GPS 系统，配合将来装备的 GPS 车载终端，达到应用效果，提高城 市管理相关车辆的管理力度，以进一步提高车辆使用效率，将车辆 的位置信息实时传递至监督中心，方便调度指挥。 系统主要功能需求：系统主要功能需求： 1）即时定位功能 通过车载 GPS 定位的技术，可以实时获得某个城管车辆位置信息 2）历史轨迹显示功能 通过某种条件可以显示某个城管车辆的历史移动轨迹，并显示在电 子地图上 3）功能计算功能 通过历史移动轨迹的查询，可以进行简单的车辆移动轨迹等方面的 计算，比如移动距离测算、平均每小时移动距离等 4）位置信息中心功能 车载 GPS 的移动设置的位置信息的实时获取和存储，并将基础信息 通过 GPRS 网络平台导入到数字城管协同系统和 GIS 系统中，实现对 执法车辆的动态监控以及智能化调度。 通过调用 GPS/GPRS 定位接口可以实现对城管执法车辆现有位置及历 史位置的追踪，显示车辆的移动轨迹。 3.3.1.53.3.1.5 综合分析子系统综合分析子系统 综合分析子系统是从大量的、不完全的、有噪声的、模糊的、 随机的数据集中识别有效的、新颖的、潜在有用的，以及最终可理 解的模式的非平凡过程。市数字化城市管理系统涵盖面广，系统运 行数据也是纷繁复杂，针对数字化城市管理系统运行数据，从多种 角度提炼用于城市管理决策的数据，可为领导对城市管理所发生的 问题进行分类统计、分析。 系统主要功能需求：系统主要功能需求： 1）问题分布分析 2）问题分布显示 3）趋势分析 4）高发问题分析 3.3.23.3.2 数字城管考评模块数字城管考评模块 数字考评相关流程及介绍参见附件及附件流程图。 3.3.2.13.3.2.1 考评采集子系统考评采集子系统 考评采集子系统是专为天津市城市管理考评要求而研发的移动 办公工具，考评终端能够接收考评办发布的考评样本数据采集任务， 并对采集结果进行记录，并录入到考评系统。 系统主要功能需求： 任务接收任务接收 考评采集子系统能够接收考评办发布的考评数据采集任务，任务的 发布通过道路进行描述，采集的样本一般选择所有相关本底数据。 考评任务反馈考评任务反馈 考评数据采集过程中，如果发现违反考评本底数据要求的内容，通 过考评通进行拍照记录，并通过无