xxxx平台技术方案投标时用.docx
《xxxx平台技术方案投标时用.docx》由会员分享，可在线阅读，更多相关《xxxx平台技术方案投标时用.docx（60页珍藏版）》请在冰点文库上搜索。
xxxx平台技术方案投标时用
XX市数据中心平台暨实战应用平台需求与技术方案
中国XX股份有限公司XX分公司
2013-11
1.概述
1.1.建设背景
XX市位于浙江省中部，XXXXXXXXX。
截至目前XX实有人口已突破达200多万，其中本市人口74万，外来人口达到143.3万人，常驻外商1.3万，每天流动人口达20余万。
XX已经建造好的卡口设备有69台，并且还在不断的增长，但是还没有一个完整的针对卡口设备的实战应用平台。
为满足全国各级XXXXXX部门大范围车辆XXXX和预警拦截、车辆轨迹和交通流量分析研判、XXXX行为甄别查处等业务应用，为预防和减少道路交通事故、打击XX犯罪工作提供技术支撑，因此我们提出了针对现在乃至以后卡口设备所依托的一个实战应用平台。
并且随着设备的不断增多，对于数据存储的压力也会渐渐凸显出来，因此考虑到XX作为一个快速发展中的城市，在经济发展的同时，对于XXXX的数据存储环境也势必经受考验，为适应今后XX越来越庞大的智能XXXX框架，作为底层的数据存储我们也同时提出了数据中心的建设方案。
1.2.建设目标
Ø建设一个面向实战的本地化的XXXX系统
形成一个对于卡口应用大的实战应用平台，使今后电子XX与卡口设备可以通过这个平台成为一体。
而随着对卡口和电子XX的建设，这两类设备的数据将成为XX部门科技化管理中的主要数据来源，因此对于这两种数据的运用与后期处理至关重要，直接影响到XX部门在科技化警务工作中的成效性。
Ø构建一个先进的易于扩展的数据接入、共享和存储管理中心
基于先进的数据总线技术和大数据存储管理技术，构建XX市智能交通信息数据的接入、共享和存储管理中心。
数据中心将整合现有XX市智能交通信息化资源，利用数据总线技术，标准化接入各类交通信息化设施设备的数据，并在数据中心进行存储和管理。
利用大数据存储管理架构，实现数据中心的结构化与非结构化数据存储和访问，并能够易于今后的数据扩展。
最后，数据中心根据各类信息数据对外共享和服务的需要，进行数据的初步处理和整合，提供规范的数据访问和共享接口，完成向上级省市和部委信息化系统的对接。
Ø建设一个面向XX内部和社会公众的信息服务系统
依托数据中心，建设一个面向XX内部的云端文件存储和流转系统，实现远程的文件存储管理，并支撑不同用户间的内部文件流转功能。
同时，利用数据中心接入和汇集的各类交通信息数据，支撑面向社会公众的信息服务。
本项目中，建设基于微信平台的交通信息查询和发布服务系统，实现XXXX、交通警情上报和拥堵上报等功能。
1.3.建设依据
●《XX交通指挥系统建设技术规范》（GAT445-2010）
●《XX交通指挥系统工程建设程序与要求》（GA/T651-2006）
●《中国智能运输系统体系框架》
●XX部《XX计算机信息系统“九五”规划》
●XX部《XXXX信息系统建设框架》
●《道路交通堵塞度及评价方法》（GA/T115）
●《城市道路交通秩序评价方法》（GA/T175）
●《城市警用地理信息系统分类与代码》（GA/T491）
●《城市警用地理信息系统图形符号》（GA/T492）
●《城市警用地理信息系统建设规范》（GA/T493）
●《XX交通指挥系统工程设计制图规范》（GA/T515）
●《计算机信息系统安全保护等级划分准则》（GB17859）
●《信息技术软件包质量要求测试》（GB/T17544）
1.4.设计原则
Ø资源整合
充分利用已有和在建的电子XX与卡口设备，以XX实战业务为核心，兼顾流程化管理，重点满足全国各级XXXXXX部门大范围车辆XXXX和预警拦截、车辆轨迹和交通流量分析研判、XXXX行为甄别查处等业务应用，为预防和减少道路交通事故、打击XX犯罪工作提供技术支撑信息共享。
建立XX市道路XXXX信息的共享交换体系，保证信息资源的全方位、多渠道共享。
Ø兼容扩展
搭建一个标准化的信息平台和开放式的体系框架，确保本次工程实施内容兼容未来的业务应用，具备支持后续信息化工程建设的能力。
Ø技术先进
吸收国内外XX业务管理，信息化及软硬件技术的先进经验，确保数据中心与实战平台的技术先进性。
Ø规范流程
通过本工程的设计及实施，建立一系列从外场设备到内场管理乃至维护考核的评审制度。
Ø开放型
此次加入了针对微信、微博以及手机APP的功能预留，为今后针对智能手机方面推行警务打下基础。
2.实战应用平台建设需求
2.1.建设内容
XX市实战应用平台以外场卡口与电子XX设备为基础，希望构建一个中间支撑平台，成为XX部XXX系统、XX卡口平台以及原有指挥调度平台之间的一个桥梁，并且拥有良好的扩展性，可以应对以后可能会出现的其他平台接入。
2.2.网络现状
现在XX拥有两大网络分布，一个是XX部门内部的XX网，另一个是主要负责运作集成平台等其他平台的物理网。
我们需要将实战平台构建在XX网之内同时可以连接物理网以及对外网的进行信息发布。
2.3.业务功能需求
2.3.1.XXXX系统需求
XXXX系统主要在满足基本XXXX的核心功能以外，还同时可以对数据进行挖掘，产生对XXXX有效的其他数据。
2.3.1.1.XXXX需求
XXXX的主要核心功能应该具有黑名单布控、车辆行踪分析以及联动布控的功能。
2.3.1.2.XX信息处理需求
XX信息处理应该具有对XX数据的前期录入、审核以及告知并且统计的功能。
数据来源主要有XXX系统，应该能够有效的兼容XXX过来的数据，并且对数据有处理能力。
2.3.1.3.交通信息分析需求
交通信息分析应该具有利用已有的电子XX以及卡口设备，对路况进行交通信息分析并得出有效的实时交通路况或者对未来可能出现的交通状况的预判能力，以及最后的对历史记录的统计和分析功能。
2.3.1.4.设备管理需求
设备管理系统应该具有对现有外场设备一些基本参数的实时监控与统计，并且可以对已经损坏或者有问题的设备进行维修报单，可以对整个检修过程进行监控与后期统计。
2.3.2.信息服务系统需求
2.3.2.1.微信平台需求
通过微信平台可以实现实时路况的查询、事故上报以及公共设施故障的上报，也可以对微信关注用户进行宣传标语的推送。
2.3.2.2.微博平台需求
通过微博平台可以实现实时路况的发布以及宣传信息的发布。
（待定）
2.3.2.3.手机APP平台需求
可以通过手机APP进行查询或者上报信息的功能。
（待定）
2.3.3.公文管理系统需求
2.3.3.1.文件存储需求
通过这个系统，用户可以上传各类文件，并进行存储。
2.3.3.2.文件管理需求
用户可以对自己存储的文件，通过可视化的操作，包括上传、复制、删除等管理。
2.3.3.3.文件流转需求
用户之间可以通过收发进行文件流转。
2.3.4.XXXXXX综合应用平台备份库建设
在XX机房信息中心安装配置XXXXXX综合应用平台（简称“XXX平台“）备份库，由支队定期对备份库做同步，XX大队可从本地备份库中获取相应数据，供统计、查询、分析的应用系统使用。
2.3.5.非现场XX处理建设
在XX信息中心独立建设机动车XX处理系统（即非现场XX处理平台）和数据库，该系统包括XX证据的采集、校对、车主信息的获取、XX通知书的形成、处罚文书的打印、处罚结果落实等过程，这一部分的工作效果直接影响到整个道路交通监控系统对交通参与者的威慑力，是“科技强警”战略的重要组成部分。
2.3.6.数据中心建设需求
2.3.6.1.现状
XX市于2012年建设完成XX市交通XXXX，随着业务的推进所产生的平台数据日益增多，仅警情部分数据日均产生警情就达到了400~500条，而XXXX平台将通过电子XX与卡口进行实时与历史数据的分析，并且随着城区监控设备的铺设和智慧城市的推广，未来每天产生的数据处理与历史数据的查询将使现存框架下的存储结构成为瓶颈。
2.3.6.2.总体建设需求
因此针对以上情况，希望拥有一套扩容性好并且能良好应对未来5年内数据膨胀的数据系统，在此基础上，希望这套系统在改善原有平台数据处理的基础上，能够同时缩小实时数据与历史数据的查询时间。
从经济角度考虑，这套系统必须能够同时兼容现有的数据存储，改善它的运行能力，并且针对以后的存储扩容达到便捷和性价比高两点。
2.3.6.3.结构化数据存储需求
在XX的业务中，有大量的结构化数据需要进行存储，这些数据常常包括：
ØXXXX基础数据
Ø交通运行参数（交通流、信号系统配时等）
Ø车牌信息
Ø……
这些信息具有数据内容常常保存为记录的方式，其数据结构严谨的特点，为此我们称为结构化数据，这些数据需要有专门的系统予以存储，以支持快速的检索与统计分析
2.3.6.4.非结构化数据存储需求
在XX的业务中，会出现大量非标准化的文本和图像视频信息，如警情的报警内容、各类预案文字、涉及车辆的图片信息、执法过程的录像信息、录音信息等。
而这些信息又往往与结构化的信息间存在各种关联关系。
对这些信息的存储，目前往往分散在各自独立的系统中，如卡警系统、接处警系统、视频系统等。
这种存储和管理模式造成对数据管理的困难，以及在实战应用中难以进行综合的信息查询和检索。
为此需要利用专门的系统，如大数据平台等，进行存储，以支持在其上的非结构化的数据分析挖掘工作。
2.3.6.5.检索服务需求
XX的业务数据导致需要进行结构化与非结构化数据的存储。
依托这些存储的信息，综合利用结构化数据与非结构化数据，进行统一而关联检索分析可以产生许多新的信息，为此需要有相应的检索服务以支持这些信息的加工处理。
2.3.6.6.信息汇聚与共享的需求
在建立数据中心的过程中，不可避免的需要进行信息的汇聚，即通过多个信息来源以获取信息/数据；同时这些信息及其加工的结果也可以提供其他系统使用，为此需要有相应的系统以支持信息的汇聚与共享。
2.4.集成系统需求
2.4.1.XXXX需求
实战平台的数据结果或者部分内容可以通过现有的XXXX进行展示或者操作，需要能够完美兼容现有的交通XXXX。
2.4.2.XXX系统需求
实战应用平台所产生的数据应该能与XX部XXX系统进行数据对接，最终把数据传输至XX部的XXX系统。
（接口预留）
3.数据中心平台暨实战应用平台软件设计方案
3.1.网络框架设计
根据XX网络现状并且结合实战平台网络实现需求，绘制出如下基本网络数据走向。
网络框架图（略）
3.2.逻辑框架设计
XX市实战应用平台系统建设根据需求，从软件设计角度可以把整个平台分为四个层次：
Ø应用层，包括所有需求内所设计的软件功能，主要是一个数据展示与操作的功能。
Ø支持层，包括构建整个平台的几个最基本的要素，其中由来自于其他平台的信息共享资源，以及基本的用户管理内容和最主要的电子XX和卡口数据。
Ø数据中心，成为支撑起整个平台最底层的存储结构，通过结构化和非结构化数据的不同存储需求分为数据中心和一般的oracle数据库。
Ø接入层，包含所有接入平台的数据来源，有电子XX、卡口设备、XXX系统、集成平台、微信微博手机APP以及未来可能的其他数据。
逻辑结构图（略）
3.3.总体系统框架
总体系统框架图（略）
3.4.软件系统设计
3.4.1.XXXX业务子系统
3.4.1.1.XXXX专题
机动车XXXX系统核心软件包括以下功能：
3.4.1.1.1.黑名单布控功能
黑名单布控是整个XXXX业务子系统的核心部分，而我们也将通过两个方面来提升和优化现有黑名单布控的响应时间：
前端比对布控：
通过把违章车牌上传至前端，然后通过前端卡口或电子XX设备进行布控并返回报警信息的方式，是最理想的实时布控策略，对于时效性和实时性都非常强，但缺点是前端设备公共机的性能直接影响报警响应时间，并且根据XX现实情况外场设备无法与实战平台直连，需要通过设备厂商本身提供的平台，又无形中增加了整个布控报警响应时间的过程。
根据上海、天津等项目的实施经验，在对设备厂商提出2秒内返回报警信息的前提下，我们预计整个实时布控的报警响应时间将会控制在5秒以内。
中心比对布控：
通过利用本次项目中的大数据平台我们可将XX信息录入至数据库，并根据前端传回的车牌进行分析和处理，从而进行报警布控的一种方式。
但是实时性相对前者来说肯定要差强人意，可应用于一些对实时性并不高的其他警种所需的个案布控，能够起到良好的效果。
黑名单布控主要包含以下几个主要功能：
1、布控信息管理：
对布控信息进行管理，包括录入、审核等功能。
2、机动车通行信息比对：
实时比对机动车过车信息，并与布控信息进行比对；
3、布控机动车通行预警：
对比对结果进行预警签收、处理、结果反馈等。
3.4.1.1.2.车辆行踪分析功能
1、单车轨迹查询：
机动车轨迹精确查询，号牌模糊查询；
2、多车轨迹查询：
关联号牌轨迹查询，多号牌轨迹查询；
3、多车轨迹比对：
车辆间轨迹关联性比对，一致性统计；
4、行踪规律分析：
嫌疑车的运行轨迹和出没规律，系统有相应的行车轨迹分析功能。
指定特定嫌疑车辆，可以跟踪实时行车轨迹和对历史图片进行回放。
3.4.1.1.3.联动布控功能
与信号系统、视频系统、警员调度和接处警系统联动，对重要布控车辆的预警采取实施拦截措施。
1、接处警联动：
通过接处警系统，调度周边警力对布控车辆进行拦截；
2、视频系统联动：
根据预案检索周边的视频资源，并提供指挥中心实时监控；
3、信号系统联动：
对周边信号路口的信号灯相位进行锁定，干预布控车辆的行驶，达到截停的目的。
信号系统联动需要信号机联网并支持相应的指令干预。
3.4.1.1.4.系统管理功能
1、卡口系统基础信息备案、审批、与其他信息数据传输交换管理、参数、代码管理等功能模块。
2、信息接口管理。
除XXXX系统与综合应用平台之间的信息传输交换、信息访问等内部信息接口外，供其他系统调用的信息接口包括：
通行文本信息上传、图片信息上传、布控信息比对、预警信息发布、布控信息交换、预警信息交换、卡口信息交换等。
3.4.1.2.XX信息处理专题
3.4.1.2.1.XX后处理系统
XX后处理系统主要针对XX数据进行后期处理以及通报。
3.4.1.2.1.1.XX信息录入功能
录入执勤民警路口罚单信息，系统将保存的XX信息通过XXX系统接口存入XXX平台。
3.4.1.2.1.2.XX信息审核功能
审核动态XX监测系统的XX信息。
检测图片、录像信息、核对记录信息，保存修改记录，系统将保存的记录信息通过XXX接口存入XXX平台。
3.4.1.2.1.3.XXXX告知功能
XX单次或者多次将以各种现有形式通知车主，这里是通过短消息，在XX我们可以对多次XX的车辆通过诱导板进行告知。
功能截图（略）
3.4.1.2.1.4.XX信息查询统计功能
待XX数据聚集一定量后，再行讨论查询的条件、统计的要求和展示等功能。
3.4.1.2.2.特定名单控制与处理功能
通过对特定名单的建立，可以针对特定名单内的车辆，对XX数据进行过滤。
特定名单处理结果也可以通过审核过程，对处理结果进行二次校验。
3.4.1.2.3.XX行为多发路段分析功能
针对卡口数据的一套统计与查询功能模块，其中包括对于卡口一些基础数据的查询以及进行数据挖掘后的统计数据，其中就包括一个XX捕捉率与XX高发路段的分析等。
前者可以直观的对外场设备的有效捕捉率进行统计，后者可以对执法部门对于XX高发路段进行集中整治带来判断依据。
XX捕捉率查询
功能截图（略）
XX多发路段查询
功能截图（略）
3.4.1.3.交通信息分析专题
功能截图（略）
3.4.1.3.1.行车时间功能
根据卡口间过往车辆的通过时间估算出两点，或者由两点推算出的整条路段的平均行车车速与时间，再通过诱导板对外发布，对司机选择合理的行车路线提供帮助，也为缓解繁忙路段高峰时期的拥堵情况提供帮助手段。
3.4.1.3.2.OD分析功能
在设计一个道路网的XXXX系统时，或在一个道路网XXXX系统实时运行中，需要掌握交通流的集散分布规律，按照交通流的集散分布规律采取相应的控制对策。
为了提供决策数据支撑，需要道路交通流OD数据。
有利于管理者掌握道路交通的流向和流量，使得路网交通整体组织更为科学。
同时当管理者对路网交通进行分析时，道路交通流OD数据能更好的帮助管理者了解路网实际交通情况。
功能截图（略）
3.4.1.3.3.集散分析功能
XXXX部门对于道路排堵保畅工作要求，从排堵、治堵、防堵三方面措施的需求着手，分析交通拥堵的成因。
排堵工作需要及时掌握交通拥堵区域微观集散现状，从拥堵区域的上下游断面和道口入手，分流和疏导交通；
治堵工作需要掌握道路路网各断面的通行能力和高峰期间的交通需求，分析并治理道路的交通瓶颈点；
防堵工作需要从交通需求管理的层次出发，掌握交通拥堵区域的交通流集散路径来源和分布结构，实施匝道调控、交通分流等措施从源头抑制过盛的交通需求。
为了提供以上XXXX策略的实施数据支撑，需要道路交通流集散数据。
有利于管理者制定科学的排堵、治堵和防堵措施。
考虑到XX市一年也会举办大大小小不少展会与活动，对展会周边的交通监管会是很大一个工作难度，因此我们沿用世博会的管控方式，来推行对特定区域的集散分析，避免展会周边的可能出现的交通拥堵情况。
系统功能截图（略）
3.4.1.3.4.路况流量分析功能
根据卡口设备提供的车流量数据，我们可两个卡口设备之间的道路、路口或者整条路段进行路况流量的分析，以此作为一个交通采集系统里的一个分支底层数据，最终计算出整条路段的平均车速，饱和度以及最重要的一个数值——拥堵情况的评判。
车流量统计曲线图：
系统功能截图（略）
车流量统计柱状图：
系统功能截图（略）
3.4.1.4.设备管理专题
3.4.1.4.1.设备状态检测功能
设备管理系统主要针对内外场设备以及应用程序进行监视的一个监管系统，结合运维的设备维修单派发可实现发现问题、提交问题到解决问题和汇报问题的一体化流程监管。
3.4.1.4.1.1.设备状态检测功能
设备管理系统主要针对内外场设备以及应用程序进行监视的一个监管系统，结合运维的设备维修单派发可实现发现问题、提交问题到解决问题和汇报问题的一体化流程监管。
3.4.1.4.1.2.识别质量检测功能
可根据抓拍数计算得出每个设备的捕捉率，如果捕捉率过低，设备可能存在问题。
专题还可以通过人工方式测算出检出率、漏检率以及准确率，通过这个专题可以定期监控设备的运营状况，为设备维保提供考察依据。
系统功能截图（略）
3.4.1.4.1.3.图象质量检测功能
可以查看所有设备所抓拍的全景图像，以便实时监测各断面信息。
系统功能截图（略）
3.4.1.4.2.设备状态管理
可提供查询外场设备的当前使用状态内容包括视频状态、机箱温度、箱门状态、磁盘容量、CPU占有率等，需要外场设备提供相应数据接口实现。
3.4.1.4.2.1.外场设备状态查询功能
可提供对外场设备基本状态的查询功能，主要有卡口名称、道路方向、车道编号、车道类型、视频状态、机箱温度、箱门状态、磁盘剩余容量、CPU占有率、车牌设备编号和卡口设备IP地址等。
系统功能截图（略）
3.4.1.4.2.2.未上传数据查询功能
选择所有设备及查询时间范围进行查询，得到该时间段内该设备的所有未上传数据，方便运维人员对该设备的数据进行手动强制补传操作。
3.4.2.信息服务业务子系统
这个系统主要针对向外部系统推送数据与服务，现在主要针对微信平台做功能推广，以后将在微博与手机APP端进行开发。
3.4.2.1.微信平台专题
3.4.2.1.1.主动信息推送功能
可以主动向用户推送诸如宣传信息或者活动信息等内容。
3.4.2.1.2.查询功能
3.4.2.1.2.1.XXXX查询
根据车牌号码查询车辆的XX信息。
3.4.2.1.2.2.路况查询
根据路段名称进行路况的查询。
3.4.2.1.3.上报功能
3.4.2.1.3.1.轻微道路事故上报
用于轻微事故处理，上报时需要进行手机验证，并上传图片、文字与位置信息。
3.4.2.1.3.2.道路设施故障上报
用于对道路设施故障的上报，上传图片、文字与位置信息。
3.4.2.1.3.3.路况上报
用于对路况拥堵情况的上报，上传图片或文字以及位置信息。
3.4.2.1.4.其他功能
3.4.2.1.4.1.手机绑定
手机绑定后无需再对手机进行验证。
3.4.2.1.4.2.民意调查
可进行民意调查。
3.4.2.1.4.3.用户体验反馈
可对使用满意度进行回馈。
3.4.2.2.微博平台专题
能够通过微博平台发送实时路况、封路信息和突发情况等信息。
3.4.2.3.手机APP平台专题
与手机APP建立服务器和客户端的关系，根据用户的选择进行诸如XX查询、路况查询、事故上报以及其他更为多样的查询和互动。
3.4.3.公文管理业务子系统
这个系统主要针对在平台用户之间的文件存储、管理和流转，并且依托于数据中心的海量存储能力，形成一个巨大的电子档案存储中心。
3.4.3.1.文件存储功能
文件通过公文管理系统上传后就会被永远保存在数据中心内，可经由管理员设置每个人的最大存储空间，以及历史文件的最长保存时间，避免垃圾文件占用空间。
3.4.3.2.文件管理功能
存储在数据中心的数据会通过权限管理进行严格管控，只有在权限允许的情况下才可以对文件进行添加、删除或者修改操作。
3.4.3.3.文件流转功能
文件流转功能主要面向点对点或点对多点的文件收发功能。
主要文件收发流程如下：
然后通过查询功能可以查看接收人的操作状态，分为未查看、已查看。
3.5.集成接口设计
3.5.1.与XXXX的接口方案
我们将通过两种方式将实战应用平台与现有的XXXX互相兼容，使两个平台在功能区域划分上相对独立，但是对使用者来说是一个整体。
首先，底层数据方面，我们会将实战平台的数据库与现有指挥调度平台的数据库进行同步，使数据在底层互通和共享。
其次，在此基础上我们也通过对原有XXXX网页嵌入的方式，把诸如轨迹追踪、黑名单显示等功能在GIS地图上显示出来。
同时我们也将保持与XXXX风格一致的嵌入式网页形式，使原有XXXX与实战应用平台之间的切换不会显得突兀。
3.5.2.与XXX系统的接口功能
实战平台将是一个主要负责收集XX市所有电子XX与卡口设备数据，并对此数据做处理的平台，同时我们也将会预留与XX部XXX系统进行数据传输的接口。
4.XXXX信息系统及XXX备份库建设设计方案
4.1.XXX备份库建设方案
1.在XX支队建立XXX分发库，同时在XX大队建立XXX备份库；
2.所有XX大队所需要的数据由XX支队传输到分发库；
3.通过支队现有的oracleDataGuard软件对分发库和XX的备份库定期做同步；
4.XX大队可从本地备份库中获取相应数据，供统计、查询、分析的应用系统使用；
5.对于需要办理的具体业务数据，需通过外挂系统与支队XXX平台的集成交互，跑完整个业务流程，最终完成业务的办理。
4.2.非现场XX处理建设
4.2.1.系统架构
系统架构图（略）
4.2.2.系统功能设计
4.2.2.1.XX证据采集
数据采集是整个系统的基础，XX执法证据采集模块负责将XX证据导入非现场执法系统中，执法证据来源包括超速抓拍、数码
升级会员 