令行禁止有呼必应综合指挥调度平台建设方案.docx
《令行禁止有呼必应综合指挥调度平台建设方案.docx》由会员分享，可在线阅读，更多相关《令行禁止有呼必应综合指挥调度平台建设方案.docx（81页珍藏版）》请在冰豆网上搜索。
令行禁止有呼必应综合指挥调度平台建设方案
“令行禁止、有呼必应”
综合指挥调度平台
建
设
方
案
2020年12月
1.项目概述
1.1.项目名称
项目名称：
“令行禁止、有呼必应”综合指挥调度平台
1.2.项目背景
为落实构建“令行禁止、有呼必应”党建引领基层共建共治共享治理格局的工作部署，结合政府实施城市精细化品质化治理工作要求，以实现“令行禁止、有呼必应”的功能为目标，按照《“令行禁止、有呼必应”综合平台优化提升工作方案》，建设“令行禁止、有呼必应”综合调度指挥平台，使用信息化手段推进呼应联动专项工作。
1.3.建设目标
以信息化为引领，充分利用并整合我区信息化建设成果，结合目前先进科技手段，立足当前，着眼长远，在合理利用现有信息设施、视频资源的基础上进行布局建设，着力拓展和提升城市指挥平台的实战、实用功能。
通过统一镇街指挥平台建设规范，指导各镇街建设全区一体化、数字化、标准化、业务化的领导决策支撑和指挥系统，构建全区“1+22”融合综合指挥，实现信息通畅、反应灵敏、技术先进、整体融合、运转高效的“智慧城市”综合指挥体系。
（1）建设规模：
建立二级指挥中心，各镇街可通过大屏可视化整个镇街运行情况，可对相关职能部门（公安，工商，政法委，交通，城管等）进行事件分派，相关职能部门完成工作后反馈事件处理结果给到指挥中心，实现运行态势可视、实施预警监测、协同指挥联动、智能决策分析。
（2）建设目标：
通过建设指挥平台，与市级综合指挥平台上下联通，实现各领域内的数据全景可视，对本区域的经济发展、社会治理、政务服务、生态环境等重点领域运行状况进行展现，全面体现本区域运行综合态势，感知城市治理风险和发展趋势，辅助领导及管理部门调整治理方法和政策针对。
1.4.建设依据
本项目软件系统设计和建设严格遵循国家及地方标准规范，以及工信部相关的规范与标准，具体如下：
网络标准：
IEEE802.3，IEEE802.3u，IEEE802.3ab，ANSI/IEEE802.3N，IEEE802.3x，IEEE802.3af，IEEE802.3az,IEEE802.11b/g
1）《信息安全等级保护管理办法》（公通字〔2007〕43号）
2）《信息系统安全等级保护测评要求》GB/T28448GB/T28448—20122012
3）《电子政务工程技术指南》（2003年1月3日签发）
4）《政务信息资源交换体系》（GB/T21062-2007）
5）《电子政务系统总体设计要求》（GB/T21064-2007）
6）《电子政务标准化指南》，国家标准化管理委员会、国务院信息化工作办公室（2002年5月）
7）《涉及国家秘密的信息系统分级保护管理办法》（国保发〔2005〕16号）
8）《电子信息系统机房设计规范》（GB50174-2008）
9）《计算机软件开发规范》（GB8566-88）
10）《计算机软件产品开发文件编制指南》（GB8567-88）
11）《软件工程术语》（GB/T11457—89）
12）《计算机软件配置管理计划规范》（GB/T12260-90）
13）《计算机软件质量保证计划规范》（GB/T12504-90）
14）《计算机软件需求说明编制指南》（GB9385-88）
15）《计算机软件测试文件编制指南》（GB9386-88）
16）《软件维护指南》（GB/T14079-93）
17）《计算机软件可靠性和可维护性管理》（GB/T14394-93）
2.总体设计
2.1.总体目标
采用信息化手段，通过计算机应用软件、3G/4G无线网络技术建设“令行禁止、有呼必应”综合指挥调度平台。
综合指挥调度平台主要建设内容包括定制软件、指挥中心硬件和视频汇聚服务，软件部分包括综合指挥平台（大屏端）、领导决策应用（领导侧）、工作平台（镇街侧）、移动协同应用（业务侧）等。
2.2.设计原则
2.2.1.标准化原则
系统建设充分考虑房管工作的现状，满足房管工作的程序化、规范化要求。
系统建设过程中对房管管理流程进行规范统一，形成本项目的标准规范，结合国家已有的相关标准和技术规范，指导本项目系统设计与应用。
2.2.2.稳定性原则
系统采用成熟和高度商品化的开发平台以及公司多年的技术成果，在系统设计阶段就充分考虑系统的稳定，采用科学的有效的设计方案进行设计。
另外，在系统开发有特定的流程和规范，比如系统开发流程规范，代码编写规范，测试规范，质量保证计划等，系统开发过程中按照已有的规范进行，确保系统的质量。
2.2.3.安全性原则
系统的安全性是用户特别关心的事情，也是系统设计的根本。
系统的安全包括三个方面的内容：
物理安全，逻辑安全和安全管理。
物理安全是系统设备及相关设施受到安全保护，避免破坏和丢失。
安全管理包括各种安全政策和机制，逻辑安全是指系统中的信息安全，主要分为保密性，完整性和可用性。
系统在设计阶段充分考虑信息安全，包括各种安全验证，数据存储的安全，敏感信息的加密，数据传输中的加密，数据访问的验证等确保了系统运行的安全性。
通过各种安全技术手段，保障系统运行的安全。
遵守现行的各项保密制度和规定，尚未公开或不宜公开的数据与信息采取严格的安全保护措施。
用户的商业秘密不得开放给XX的用户。
系统外部安全：
系统的安全性充分考虑网络的高级别、多层次的安全防护措施，包括备份系统、防火墙和权限设置等措施，保证政府部门的数据安全和政府机密；同时考虑系统出现故障时的软硬件恢复等急救措施，以保障网络安全性和处理机安全性。
系统要形成相对独立的安全机制，有效防止系统外部的非法访问。
系统内部安全：
在保证系统外部安全的同时，系统也能确保授权用户的合法使用。
系统本身具有容错功能，包括出错提示、原因，并能自动或通过人工操作，使出错的系统恢复到正常状态。
系统还提供严格的操作控制和存取控制。
系统运行安全：
在逻辑上，系统具有抵御对系统的非法入侵的能力；在物理上，系统保证不存在可能的单点故障，提供资源数据的备份能力。
系统支持定期的自动数据备份和手工进行数据备份，能够在数据毁坏、丢失等情况下将备份数据倒回，实现一定的数据恢复。
2.2.4.先进性原则
在系统总体设计上，借鉴国内己有的相关经验。
在技术上，采用国际上先进、成熟的技术，使得设计更加合理、先进。
在注重系统实用性的前提下，尽可能采用先进的计算机软、硬件环境；在软件开发思想上，严格按照软件工程的标准和面向对象的理论来设计，保证系统的先进性。
2.2.5.易用性原则
易操作性是指用户操作和运行控制软件的难易程度的软件属性。
该特征要求软件的人机界面友好、界面设计科学合理以及操作简单等。
易操作的软件让用户可以直接根据窗口提示上手使用，无需过多的参考使用说明书和参加培训；
各项功能流程设计的很直接，争取在一个窗口完成一套操作；
在一个业务功能中可以关联了解其相关的业务数据，具有层次感；
合理的默认值和可选的预先设定，避免了过多的手工操作；
如果软件某操作将产生严重后果，该功能执行是可逆的，或者程序给出该后果的明显警告并且在执行该命令前要求确认；
如果一旦出现操作失败，及时的信息反馈是非常重要的，没有处理结果或者是处理过程的信息反馈不是一个好系统；
流畅自然的操作感觉，来源于每一次操作都是最合理的。
在页面和流程上浪费用户的鼠标点击，也是在挥霍用户对于软件的好感。
清晰、统一的导航要贯穿系统的始终；操作按扭、快捷键等遵循一致的规范、标准是必须的，不要给操作者额外记忆的负担。
2.2.6.可扩展性原则
系统的扩展性是测量系统设计好坏的一个重要的标准，良好的扩展性可以使系统有健壮的生命力，也为系统的升级和将来的维护打下良好的基础。
系统在需求调研阶段就充分考虑用户的用途以及将来的发展方向，在概要设计阶段充分考虑系统的使用和发展，为系统的可扩展性提供重要保障。
采用面向对象、面向服务的设计思想，按不同的网络、不同的功能、不同的职能划分成各种功能组件，各功能组件既可以独立形成系统又可以组成一个综合系统，方便实现从子系统到综合系统，从综合系统到独立系统的升级过渡，保护用户的投资。
良好的扩充性和可维护性，实现在快速搭建总体框架的基础上分业务，分任务的逐渐充实整个系统，使系统具备可持续升级的基础。
功能扩展：
为了满足用户今后系统扩容和扩大应用范围的需求，系统充分考虑从系统结构、功能设计、管理对象等各方面的功能扩展。
软硬件升级：
系统充分考虑软硬件平台的可扩展性及软、硬件的负载平衡机制。
随着关键软件和硬件的发展以及管理功能的增加，系统具有灵活和平滑的扩展能力。
关键软件和硬件的发展以及管理功能的增加，系统具有灵活和平滑的扩展能力。
2.2.7.可维护性原则
可维护性是在软件交付使用后进行的修改，修改之前必须理解待修改的对象，修改之后进行测试，以保证所做的修改是正确的。
系统在设计时充分考虑可维护，尽量做到系统在尽可能少的维护动作下，完成系统功能修改。
在系统功能文档中做到完全的解释，使用户在理解功能时轻松完成系统的维护。
2.3.总体架构
系统主要由“1个规范、1个数据库、1个系统”构成。
“一个规范”即数据标准规范，根据城市管理治理要求，基于国家、省、市相关技术标准规范编制一套适应城市基层管理建设要求和实际情况的标准规范体系。
；
“一个数据库”即“基础信息资源库”，作为整个项目的基础数据支撑；
“一个系统”面向城市基层管理工作，实现“令行禁止、有呼必应”综合指挥调度平台。
总体架构主要包括感知层、网络层、数据层、服务层、平台层、应用层、政策法规、安全标准等层面。
项目建设基于信息标准，实现信息数据的集中部署，要做到以下五个方面的统一:
●统一数据标准（数据系统架构、数据库结构、数据表）；
●统一基础信息（文字、图片、音视频、虚拟素材等）；
●统一地理信息（位置信息、GPS数据、电子地图）；
●统一交换接口（内部数据交换接口规范、开放数据接口规范）；
●统一技术平台（硬件、软件、网络、安全）。
感知层：
通过各类数据采集和感知技术，如：
RFID、条形码、传感器、摄像头等，实现数据采集和存储，为整个系统治理应用体系提供基础数据的支撑；
网络层：
构建应用级物联、感知、互联、通信、卫星网络，为数据信息的传输流通起到支撑作用；
数据层：
建立以基础地理信息服务、基础设施服务为一体的空间数据服务体系，为平台建设奠定空间信息基础与数据支持；
统一服务平台：
系统业务处理的逻辑平台，它通过对数据核心层的调用访问业务数据，实现不同的功能模块，满足不同的业务需求；所有业务功能在此统一平台上得到良好的封装和定义，以Web、手机终端服务的形式，运作在平台上，为用户提供各类信息服务；
应用层：
对于应用层，提供多样化的界面逻辑，实现对业务逻辑的应用。
2.4.应用架构
“令行禁止、有呼必应”综合指挥调度平台的应用架构主要包括数据采集、平台数据、应用支撑、应用系统等。
用户包括管理人员、监控人员、执法人员等。
平台应用架构如下图所示：
以“集约化”建设为理念，指挥平台由基础设施层、数据资源层、应用支撑层、公共应用层以及数据展示层组成。
●基础设施层
按照省市“数字政府”集约化建设原则，充分利用“智慧城市”数字平台底座，为指挥平台建设提供云服务器资源（计算资源及存储资源）、政务外网等基础设施服务，促进信息资源高效循环利用，提升信息基础设施运行效率和服务能力。
●数据资源层
数据资源层由基础数据库、主题数据库以及专题数据库组成。
基于四标四实、法人库以及自然资源空间地理基础数据，围绕“智慧城市”综合指挥体系涉及如党建、经济、城市管理等业务主题数据库，统一全区基础数据治理，为各指挥平台提供数据资源支撑。
●应用支撑层
以“共建共享共用”为原则，在充分满足指挥平台的运行需求下，充分应用区平台并结省、市“数字政府”公共应用支撑平台，构建“智慧城市”综合指挥体系应用支撑平台，指挥平台建设可快速应用，避免重复建设。
数据共享平台：
建设大数据基础平台为指挥平台的建设提供数据共享服务，便于平台更充分使用已有数据资源，减少数据的重复采集和录入工作，打破部门壁垒，消除信息孤岛，实现信息资源的互联互通。
地理信息平台：
“智慧城市”一期地理信息平台以现有地理数据资源为中心，整合区域时空数据资源，建设集“空间-时间-属性”等多维度数据一体的通用平台，在为指挥平台建设提供通用平台的基础上，针对不同需求建设个性化服务平台，实现通用平台与个性平台的融合，满足全区“一张图”的服务需求。
视频会议平台：
视频会议平台为全区22个镇街、公安局、卫计局等单位提供横纵向联动的全区视频会议系统，实现同时召开三级三场视频联通（区→镇街→移动终端）的会议，以满足指挥平台现代化会商、日常会议、应急指挥等不同业务需求，实现重大事件多部门统一联动指挥、联合调度派遣、移动会商的快速响应和处置。
统一认证平台：
“智慧城市”建设统一的身份管理与访问控制系统，可按需为指挥平台的用户身份信息提供统一存储、统一供应、统一认证及审计管理等功能，并根据统一身份和认证业务的特点配套建设相应的制度和规范，确保指挥平台用户身份和账号安全。
●公共应用层
以“平台统筹，共建共用”为理念，以界面集成、数据集成为切入点，统筹整合公共服务执法平台，为指挥平台提供统一的公共应用平台，构建简约高效的基层治理体制。
统一公共服务平台：
建设全区统一公共服务平台，提供业务办理、事件受理及督办考核等经办服务，解决城市公共服务发展不平衡不充分问题,适应流动性需要,统筹满足经办服务实际需求，构建更加便民快捷的经办服务体系。
统一综合治理平台：
通过强化技术支撑及信息共享能力建设，整合党建、生态保护、市场监督、卫生健康、社区治理、城管等系统的信息资源，健全发现问题、协调联动、研判预警、督查考核等综合指挥工作机制，实现基层治理跨部门、跨层级协同运转。
统一行政执法平台:
依托行政执法信息平台和行政执法监督网络平台，整合城市各类业务系统和资源，强化统一执法和统筹协调能力建设，构建统一综合行政执法机构和执法平台，以规范执法检查、受立案、调查、审查、决定等程序和行为，完善全区行政执法案件移送及协调协作机制，实现执法全程留痕、可追溯、可追责。
●数据展示层
为统筹规范指挥平台的数据展示，减少重复建设，由区政数局统筹建设区综合指挥平台计划统一建设“2+2+1”五大版块，即：
2个“监测预警、指挥调度”主版块，2个“党建引领、有呼必应”共有子版块，1个“辅助决策”可选版块，指挥平台可直接按需部署应用。
同时，可根据所在区域特色业务需求细化或创新功能板块开发。
监测预警板块：
实时监测本区域经济运行、城市治理、生态环境等实时数据情况，包括经济指标、各类事件巡查、整治情况、水资源和空气污染实时数据等指标。
党建引领板块：
以党的政治建设为纲领，全面增强基层党组织政治、组织领导，该板块从党组织结构、工作单位属性、“4+5+1”制度等方面综合呈现本区域党建工作的状况，多维度分析党建工作开展情况，呈现全区基层党建工作运行态势。
有呼必应板块：
该板块对本区域政令任务、呼应工单的处理情况进行统计分析，结合任务监督分析以及事件统计，聚焦基层治理的难点、痛点、堵点，建设“令行禁止，有呼必应”平台，推动全区“政令”、“呼应”两闭环管理建设，实现基层治理“有呼必应，有应必果”，构建共建共治共享社会治理新格局。
辅助决策板块：
通过以海量跨业务部门数据为基础，大数据挖掘分析为手段，以政策制定、决策支撑、发展评估等业务需求为导向，对城市规划、经济运行等各个环节的进行数据分析，辅助领导进行决策分析。
指挥调度板块：
该专题融合音视频、部门上报等数据资源，做到现场情况的可视化管理，并实现日常事件管理、监测监控、预测预警、动态决策、应急响应等功能。
支持跨级、跨区域的协同应用，适应指挥调度的需要。
2.5.数据库设计
2.5.1.历史数据库设计
历史数据库用来存储实时数据库的历史数据。
实时数据库中只有各种设备的当前值（状态），而以前的实时数据要存储在历史数据库中，以备日后查询。
为了可以精确获取每个数据采集仪的任何时候状态，历史数据库中要保存所有节点的全部采样数据。
历史数据库系统采用大型商用关系型数据库。
历史数据库系统是整个应用程序的数据层。
它为各种客户提供所需要的历史数据。
历史数据库系统采用双机备用方式。
历史数据服务库系统的功能包括：
采样历史数据的存储；计算各种分析所需的统计数据；记录变位、SOE等随机性数据；记录用户对应用程序的操作的日信息；存储用户权限等安全信息；提供Web发布所需的各种历史数据。
历史数据库系统的数据源由实时数据库系统提供，在实时数据库系统中，已经对数据质量、数据一致性、完整性作了处理，因此由实时数据库系统提供给历史数据库系统的数据均为有效数据。
实时数据库系统负责定时的将有效数据送给历史数据库系统的代理程序，随机数据在产生的时候送给代理程序，代理程序负责将数据写入历史库中。
同时代理程序负责定时对采样数据进行统计、计算并将结果存入数据库中。
历史数据系统示意图
2.5.2.历史数据
由实时数据库提供的采样数据存储在历史数据库中。
这些数据按类别、时间存储在数据库不同的历史表中。
I数据表命名规则
历史数据表名称按照一定的命名规则：
类型名称+时间。
如：
2001年7月10日的模拟量采样数据表应命名为SmpAna20010710，这张表将存储这一天的所有的模拟量采样数据。
以上设计主要基于对采样数据的查询方式，主要是要某一个量在某一段具体时间内的数据。
数据不存放在一个数据表中，可以大减少检索的次数。
当检索一个数据的时候，是先从系统数据表中检索出这张表的位置，然后定位这张表，再检索需要的数据。
而不必从一个大表中反复的检索、查找和定位。
这种检索方式也近似于字典查找的算法理论。
对于计算、统计数据也采用近似的处理方式。
II数据表索引（Index）
数据库的索引是一个B型树的数据结构。
当写入一记录时，数据库会对记录产生一个索引值，并在系统索引表（Sysindexes）中产生一条索引记录。
在检索一条记录时，从树的根节点到树叶的搜索方式进行，从而对有索引的记录加快检索速度。
但同时也降低了写入的速度。
对于采样数据，主要是记录值，因此可以考虑用没索引的表来表示。
III数据压缩存储
采样数据可能是一些不断重复的量。
重复记录会加大存储的空间和记录的行数。
因此可考虑数据变化时才存储，记录一个状态（值），并记录这个状态（值）重复的次数。
也就是：
数值—变化的压缩方式。
具体设计如下例：
如有一个模拟量，前一次的值如果和本次的值相同，则在记录中的次数计数器加1，否则添加一条记录。
2.5.3.统计数据
历史数据的存储方式同样是将数据按类分散在不同的表中，表要具有统一的命名规则。
数据统计是将各种采样数据计算生成所需要的一些统计数据。
数据统计与采样数据记录是同步进行的。
也就是说，当从实时数据库中取得采样数据并写入到采样记录表中的时候，就会触发一系列的统计和计算工作。
有一系列的中间结果产生出来，当在时间上满足要求的时候，就会将这个中间结果记录到相应的统计数据表中。
统计计算工作用ORACLE的触发器（Trigger）来完成，当采样数据更新时，会触发一系列的事件产生，事件驱动一系列的处理程序来处理是否写入数据库，更新统计数据的中间结果等。
这项工作在ORACLE后台为处理，使用大量的存储过程来加以实现。
2.5.4.临时表
临时表具有与普通表完全一样的属性，所不同的是它存储在Tempdb中而不放在当前数据库中，当用户连接并创建使用时它存在，当用户断开后临时表也会自动删除。
全局性临时表（以##开头作为标识）：
会各所有连接到数据库的用户开放，每一个用户均可以访问，只有当所有的用户都断开后，全局性临时表才会自动删除。
临时表的设计主要是为了考虑提高对报表、查询速度的要求。
通过组态的报表或定制的某个查询，是对固定的一些参数进行数据检索，这些量使用的频率最高。
考虑减少在无关的数据堆中检索的次数，因此想把这些用户最关心的数据量的记录放在一个专门的地方。
由于数据源的记录本来已在数据库中存在，而同样的数据在数据库中不应该重复，所以考虑将这样的数据放在临时表中，且为全局性临时表，为所有的数据连接用户开放。
临时表中的记录是最近一个时间段的数据和最近使用过的数据。
处理临时表中记录的算法应是先进先出的原则和最久不使用原则。
新数据将最老的数据并且最久没有使用过的数据覆盖。
临时表中的数据始终保持最新和最新使用过的数据。
这些数据也是用户使用频率最高的数据，这样可以提高报表、查询的检索数据速度。
2.5.5.数据冗余处理
数据冗余采用磁盘阵列的方式来实现。
数据冗余示意图
2.5.6.数据库安全
数据库安全性问题一直是系统安全的关键。
数据库安全性问题应包括两个部分：
（1）数据库数据的安全
它应能确保当数据库系统DownTime时，当数据库数据存储媒体被破坏时以及当数据库用户误操作时，数据库数据信息不至于丢失。
数据安全的解决，主要有系统双机热备份、数据库的备份和恢复等办法，本系统的数据安全，纳入信息中心的系统安全体系，共享一些硬件设施，实现数据的备份等。
（2）用户角色的管理：
这是保护数据库系统安全的重要手段之一。
它通过建立不同的用户组和用户口令验证，可以有效地防止非法的Oracle用户进入数据库系统，造成不必要的麻烦和损坏；另外在Oracle数据库中，可以通过授权来对Oracle用户的操作进行限制，即允许一些用户可以对Oracle服务器进行访问，也就是说对整个数据库具有读写的权利，而大多数用户只能在同组内进行读写或对整个数据库只具有读的权利。
在此，特别强调对SYS和SYSTEM两个特殊账户的保密管理。
为了保护Oracle服务器的安全，应保证$ORACLE_HOME/bin目录下的所有内容的所有权为Oracle用户所有。
为了加强数据库在网络中的安全性，对于远程用户，应使用加密方式通过密码来访问数据库，加强网络上的DBA权限控制，如拒绝远程的DBA访问等。
2.5.7.数据库管理设计方案
本系统的数据库属于生产数据库，应当将其运行在归档模式下。
各种数据库备份和恢复方案各有优劣，为了保证数据绝对安全，本系统数据库备份和恢复将同时采用多种方案，以应对数据库不同的故障情况：
2.5.7.1.逻辑备份
用exp命令将数据导出为dmp文件，当数据库服务器崩溃时，用imp命令将数据重新导入，实现数据的恢复。
写一个批处理文件（bat）脚本，调用exp命令，利用windows提供的“计划任务”功能，达到定时自动导出的目的，考虑到系统性能，应将自动导出的操作时间设在系统应用的非高峰期，如中午12：
30分，晚上0：
00。
导入工作需要手动完成。
此种方式可以实现定时自动备份和异地备份，备份及恢复操作简单，通过少量培训，可由综合科系统管理人员独立完成；可保证数据安全；备份时间和次数可以随时调整；可以单表恢复。
但是此种方式只能备份某一时点的数据，在两个时点之间数据发生的变化没有记录下来，因而使用这种方法备份的数据文件恢复数据库有可能会丢失数据，逻辑备份间隔越长，可能丢失的数据就越多；逻辑备份仅备份业务数据，不备份软件系统、控制文件，因而只能用来恢复数据，不能用来恢复数据库系统的运行。
逻辑备份适合以下情形：
（一）数据库平台升级；
（二）错误地数据操作导致的逻辑错误，需要很快地对有错误的表进行单独恢复；
（三）磁盘阵列被损坏，不能再使用，但是数据库服务器软件系统基本完好。
2.5.7.2.物理备份
（1）磁带机备份
将表空间数据文件、控制文件、归档日志文件、Oracle软件及操作系统文件通过磁带机复制到磁带介质中。
分为全备份、增量备份和差量备份三种方式。
采取此种备份方式价格相对便宜；技术相对成熟。
但
升级会员 